JP5046818B2 - 画像形成装置、画像形成装置内のデータ処理方法、及びデータ処理プログラム - Google Patents

Description

本発明は、当該画像形成装置が有する複数の機能のうち、第１の機能と、第１の機能から所定の処理が要求される第２の機能との間でプロセス間通信を行う画像形成装置、画像形成装置内のデータ処理方法、及びデータ処理プログラムに関するものである。

コピー、ファックス、プリンタ、スキャナなどの複数の機能を有する画像形成装置として、複合機が一般的に知られている。

このような複数の機能が動作する画像形成装置では、例えば、ＵＮＩＸ（登録商標）などのマルチタスクＯＳ（Operating System）が実装されており、このＯＳ上に多数のプロセスを起動し、起動したプロセスで各機能モジュールを動作させることで、多数の処理を並列処理している。

このような複数のプロセスが動作するマルチプロセス環境では、プロセス間において双方向のデータ通信を行っている。

例えば、画像形成装置が有する機能に、外部機器が当該画像形成装置を自動検出するために情報提供を行う機器情報提供部と、プリンタやスキャナなどの各アプリケーションを管理するアプリケーション管理部とがある。これら２つの機能は、マルチプロセス環境において、それぞれ異なるプロセスで動作している。そのため、機器情報提供部が外部機器へ情報提供を行うときに、アプリケーション管理部から各アプリケーションに関する情報を取得しなければならない。このとき、画像形成装置では、機器情報提供部が動作するプロセスからアプリケーション管理部が動作するプロセスへ情報取得要求のメッセージが送信され、その結果、アプリケーション管理部が動作するプロセスから機器情報提供部が動作するプロセスへ要求した情報が送信される。

このように、マルチプロセス環境における画像形成装置では、装置内部のデータ処理の１つとしてプロセス間通信が行われている。

例えば、特許文献１には、「ハードウェア資源とプログラムとを有する画像形成装置であって、一又は複数のサービス要求を含むエージェントを受信し、エージェントのサービス要求ごとに１又は複数のコントロールサービスを選定して、選定されたコントロールサービスに対してサービス要求を行うエージェント処理手段を備えたことにより、可変性のあるアーキテクチャ及びタス多様な機能を実現する」という画像形成装置が開示されている。
特開２００７―１２０５７号公報

しかしながら、特許文献１に開示された従来の画像形成装置では、プロセス間通信を行うモジュールと要求に応じた処理を行うモジュールとが一体となっている。そのため、それぞれのプロセスで動作する通信用モジュールを、送受信側で行う処理内容やその通信目的などの取り決めに応じて設計し実装しなければならず、送受信側の機能拡張などの作業は、開発者にとって煩雑なものであった。

このように、従来の画像形成装置内のデータ処理機能は、プロセス間通信を行う機能部の独立性が低いため（プロセス間通信を行う機能部が送受信側の取り決めに依存しているため）、送受信側の機能拡張が困難なものとなっていた。

本発明では、上記従来技術の問題点に鑑み、画像形成装置内のデータ処理において、プロセス間通信を行う機能部の独立性が高く、送受信側の機能を容易に拡張することができる画像形成装置、画像形成装置内のデータ処理方法、及びデータ処理プログラムを提供することを目的とする。

上記目的を達成するため、本発明の画像形成装置は、第１の機能が動作する第１のプロセスと、前記第１のプロセスから所定の処理の実行が要求される第２の機能が動作する第２のプロセスとを有する画像形成装置であって、前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手段と、前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段と、前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて実行される前記ソフトウェア部品により特定された、前記要求メッセージにより要求される処理を前記第２のプロセスで実行する実行手段と、を有し、受信側の前記通信制御手段は、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、送信側の前記通信制御手段は、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、受信側の前記通信制御手段は、前記第１のプロセスから前記要求メッセージを受信すると、前記要求メッセージにより要求される処理の実行を前記実行手段に指示することを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記通信制御手段において、前記要求メッセージにより要求され、前記第２のプロセスで実行された前記所定の処理の実行結果に基づいて、要求に対応する応答メッセージを、前記第１のプロセスに送信することを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記通信制御手段において、前記要求メッセージの送信を指示する送信指示手段と、前記要求メッセージの送信と要求に応じた前記応答メッセージの受信待ちを指示する応答受信指示手段と、前記要求メッセージの受信待ちを指示する要求待ち指示手段と、前記ソフトウェア部品の格納先情報の設定を指示する格納先情報設定指示手段とを有することを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記要求メッセージが、前記要求メッセージにより実行される処理を示す機能名と、前記処理を行うときに用いるパラメータ値と、前記パラメータ値の数を示すパラメータ数とから構成されることを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記ソフトウェア部品が、前記第２のプロセスで受信された前記要求メッセージの前記機能名に基づいて、前記要求メッセージにより要求される処理を特定することを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記実行手段において、前記第２のプロセスで受信された前記要求メッセージの前記パラメータ値に基づいて、前記ソフトウェア部品により特定された、前記要求メッセージにより要求される処理を行うことを特徴とする。

また、上記目的を達成するため、本発明の画像形成装置は、前記第２のプロセスで受信された前記要求メッセージの前記パラメータ値の数が、前期要求メッセージの前記パラメータ数と一致するか否かを判定し、前記要求メッセージのデータを検証するデータ検証手段を有することを特徴とする。

これによって、本発明の画像形成装置は、プロセス間通信を行う機能部と送受信側の主要機能部とを別のプログラムで構成し、所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、要求メッセージにより要求される処理を特定し処理を実行するプログラムを送受信側の主要機能部が有し、このプログラムを、予めプロセス間通信を行う機能に登録可能な構成とすることにより、プロセス間通信を行うときの送受信側の取り決めなどに依存する処理が送受信側の機能に統合され、プロセス間通信を行う機能側に、送受信側の取り決めに依存するプログラムコードやデータが含まれることがないため、画像形成装置内のデータ処理において、プロセス間通信を行う機能部の独立性が高く、送受信側の機能を容易に拡張することができる。

上記目的を達成するため、本発明の画像形成装置内のデータ処理方法は、第１の機能が動作する第１のプロセスと、前記第１のプロセスから所定の処理の実行が要求される第２の機能が動作する第２のプロセスと、前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段とを有する画像形成装置内のデータ処理方法であって、前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手順と、前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて前記ソフトウェア部品を実行し、前記ソフトウェア部品の実行により、前記要求メッセージにより要求される処理を特定し、特定された前記処理を前記第２のプロセスで実行する実行手順と、を有し、受信側の前記通信制御手順により、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、送信側の前記通信制御手順により、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、受信側の前記通信制御手順により、前記第１のプロセスから前記要求メッセージを受信すると、前記実行手順を実行し、前記実行手順により、前記要求メッセージにより要求される処理を実行することを特徴とする。

これによって、本発明のデータ通信方法は、送受信側の主要機能部が有する、所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、要求メッセージにより要求される処理を特定し処理を実行するプログラムを、予めプロセス間通信を行う機能部に登録しておき、受信側のプロセス間通信を行う機能部により要求メッセージを受信すると、登録されているプログラムを実行することにより、プロセス間通信を行うときの送受信側の取り決めなどに依存する処理が送受信側の機能部に統合され、プロセス間通信を行う機能部側に、送受信側の取り決めに依存するプログラムコードやデータが含まれることがないため、画像形成装置内のデータ処理において、プロセス間通信を行う機能部の独立性が高く、送受信側の機能を容易に拡張することができる。

上記目的を達成するため、本発明の画像形成装置内のデータ処理プログラムは、第１の機能が動作する第１のプロセスと、前記第１のプロセスに対して所定の処理を要求する第２の機能が動作する第２のプロセスと、前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段とを有する画像形成装置内のデータ処理プログラムであって、コンピュータを、前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手段と、前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて前記ソフトウェア部品を実行し、前記ソフトウェア部品の実行により、前記要求メッセージにより要求される処理を特定し、特定された前記処理を前記第２のプロセスで実行する実行手段として機能させ、受信側の前記通信制御手段が、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、送信側の前記通信制御手段が、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、受信側の前記通信制御手段が、前記第１のプロセスから前記要求メッセージを受信すると、前記要求メッセージにより要求される処理の実行を前記実行手段に指示するように動作させる。

これによって、本発明の画像形成装置内のデータ処理プログラムは、コンピュータを、予め登録しておいた、送受信側の主要機能部が有する、所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、要求メッセージにより要求される処理を特定し処理を実行するプログラムを、受信側のプロセス間通信を行う機能部により要求メッセージを受信したときに実行するように機能させることができる。

よって、本発明の画像形成装置内のデータ処理方法プログラムは、プロセス間通信を行うときの送受信側の取り決めなどに依存する処理が送受信側の機能部に統合され、プロセス間通信を行う機能部側に、送受信側の取り決めに依存するプログラムコードやデータが含まれることがないため、画像形成装置内のデータ処理において、プロセス間通信を行う機能部の独立性が高く、送受信側の機能を容易に拡張する「画像形成装置内のデータ処理機能」を実現することができる。

本発明によれば、画像形成装置内のデータ処理において、プロセス間通信を行う機能部の独立性が高く、送受信側の機能を容易に拡張することができる画像形成装置、画像形成装置内のデータ処理方法、及びデータ処理プログラムを提供することができる。

以下、本発明の好適な実施の形態（以下、「実施形態」という。）について、図面を用いて詳細に説明する。

［第１の実施形態］
＜ハードウェア構成＞
では、本実施形態に係る画像形成装置１００のハードウェア構成について、図１を用いて説明する。図１は、本発明の第１の実施形態に係る画像形成装置１００のハードウェア構成の一例を示す図である。

本実施形態に係る画像形成装置１００は、操作パネル１１と、記憶メディアＩ／Ｆ１２と、コントローラ１３と、データ通信Ｉ／Ｆ１４と、ＨＤＤ（Hard Disk Drive）１７と、スキャナ１５と、プロッタ１６とから構成され、それぞれ相互に接続されている。

操作パネル１１は、入力装置１１aと表示装置１１bとを有しており、入力装置１１aは、ハードウェアキーなどで構成され、画像形成装置１００に各操作信号を入力するのに用いられる。また、表示装置１１bは、ディスプレイなどで構成され、例えば画像形成動作に関する各種情報を表示する。データ通信Ｉ／Ｆ１４は、インタフェース装置１４aを有しており、画像形成装置１００をネットワークなどのデータ伝送路に接続するインタフェースである。ＨＤＤ１７は、画像形成装置１００で取り扱われる受信文書データや読み取り画像データなどの各種データを格納している。また、ＨＤＤ１７は、これらの各種データを、所定のファイルシステムやＤＢ（Data Base）により管理している。

上記ＨＤＤ１７に格納される各種データの中には、例えば、デジタルカメラなどの外部機器によって記録された電子データも含まれる。このような場合には、メモリカードなどの記録媒体１２bによって画像形成装置１００に提供されるか、データ伝送路であるネットワークなどを通じてアップロードされる。記録媒体１２bは、記憶メディアＩ／Ｆ１２が有するドライブ装置１２aにセットされ各種データが記録媒体１２bからドライブ装置１２aを介してＨＤＤ１７に格納される。

コントローラ１３は、ＲＯＭ（Read Only Memory）１３a、ＲＡＭ（Random Access Memory）１３b、及びＣＰＵ（Central Processing Unit）１３cとを有しており、ＲＯＭ１３aは、画像形成装置１００が起動されるときに実行されるプログラムや各種データを格納している。また、ＲＡＭ１３bは、ＲＯＭ１３aやＨＤＤ１７から読み出された各種プログラムやデータを一時保持する。更に、ＣＰＵ１３cは、ＲＡＭ１３bが一時保持しているプログラムを実行する。コントローラ１３は、例えば、データ通信Ｉ／Ｆ１４を介して印刷データを受信した場合に、ＲＯＭ１３aからＲＡＭ１３b上に読み出された、ＰＤＬ（Page Description Language）を解釈可能なプログラム（ＰＤＬパーサ）をＣＰＵ１３cにより実行し、印刷データを解釈してビットマップイメージを生成する。

スキャナ１５は、画像読取装置１５aを有しており、読み取り面に配置された原稿を光学的に読み取り画像データを生成する。プロッタ１６は、印刷装置１６aを有しており、例えば、電子写真プロセス方式によってビットマップイメージを記録紙に印刷する。

このように、本実施形態に係る画像形成装置１００では、上記ハードウェア構成により、コピー、プリンタ、ファクシミリ、スキャナなどの複数の機能を実現している。

＜ソフトウェア構成＞
次に、本実施形態に係る画像形成装置１００のソフトウェア構成について、図２を用いて説明する。図２は、本発明の第１の実施形態に係る画像形成装置１００のソフトウェア構成の一例を示す図である。

＜＜画像形成装置＞＞
本実施形態に係る画像形成装置１００は、図１に示したプロッタ１６と、スキャナ１５と、ファクシミリやＨＤＤ１７などのハードウェアリソース１０１などを有するとともに、起動部１４０によって起動されるプラットホーム１２０とアプリケーション１３０とから構成されるソフトウェア群１１０とを備えている。

プラットホーム１２０は、アプリケーション１３０からの処理要求を解釈してハードウェアリソースの獲得要求を発生させるコントロールサービス１５０と、１つ以上のハードウェアリソースの管理を行い、コントロールサービス１５０からの獲得要求を調停するＳＲＭ（System Resource Manager）１２３と、ＯＳ（Operating System）１２１とを有する。

コントロールサービス１５０は、複数のサービスモジュールから形成され、ＳＣＳ（System Control Service）１２２と、ＥＣＳ（Engine Control Service）１２４と、ＭＣＳ（Memory Control Service）１２５と、ＯＣＳ（Operation panel Control Service）１２６と、ＦＣＳ（FAX Control Service）１２７と、ＮＣＳ（Network Control Service）１２８とから構成される。

なお、このプラットホーム１２０は、予め定義されたメソッドによりアプリケーション１３０から処理要求を受信可能とするＡＰＩ（Application Program Interface）１０３と、プロッタ１６やスキャナ１５、またその他のハードウェアリソース１０１などを、ハードウェアリソースを利用する上位層からの要求に従ってＯＳ１２１を介して制御するときのインタフェースであるエンジンＩ／Ｆ１０２を有する。

ＯＳ１２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。

ＳＲＭ１２３は、ＳＣＳ１２２とともにシステムの制御およびリソースの管理を行うものであり、プロッタ１６やスキャナ１５などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（例えば、セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４ Ｉ／Ｆ、ＲＳ２３２Ｃ Ｉ／Ｆなど。）のハードウェアリソースを利用する上位層からの要求に従って調停を行い、実行制御する。

具体的には、このＳＲＭ１２３は、要求されたハードウェアリソースが利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェアリソースが利用可能である旨を上位層に伝える。また、ＳＲＭ１２３は、上位層からの要求に対してハードウェアリソースの利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など。）を直接実施している。

ＳＣＳ１２２は、アプリ管理、操作部制御、システム画面表示、ＬＥＤ（Light Emitting Diode）表示、リソース管理、割り込みアプリ制御を行うものである。ＥＣＳ１２４は、プロッタ１６、スキャナ１５などから構成されるハードウェアリソースのエンジンを制御するものである。

ＭＣＳ１２５は、画像メモリの取得および解放、ＨＤＤの利用、画像データの圧縮および伸張などを行うものである。ＯＣＳ１２６は、オペレータと本体制御間の情報伝達手段となる操作パネル１１を制御するモジュールである。

ＦＣＳ１２７は、システムコントローラの各アプリ層からＰＳＴＮ（Public Switched Telephone Networks）／ＩＳＤＮ（Integrated Services Digital Network）を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ：Static Random Access Memory）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供するものである。ＦＣＳ１２７には、そのサブプロセスであるＦＣＵハンドラ（ＦＣＵＨ）が起動される。このＦＣＵＨは、ＦＣＳ１２７からの指令によりファクシミリ送受信のときにファクシミリエンジンのデバイスドライバを制御するものである。

ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーション１３０に対して共通に利用できるサービスを提供するためのモジュール群である。

本実施形態に係るデータ処理機能は、ＮＣＳ１２８が有している。ＮＣＳ１２８を構成する具体的なソフトウェア部品（プログラム）については、以降に示す図３を用いて説明する。

アプリケーション１３０は、ＰＣＬやポストスクリプト（ＰＳ）などのページ記述言語（ＰＤＬ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、工程検査用アプリケーションである工程検査アプリ１１６と、配信用のアプリケーションである配信アプリ１１７とを有している。

これらの各コントロールサービスとＳＲＭ１２３と各アプリケーション１３０とは、1つ以上のメソッドを有するオブジェクトであり、このオブジェクトを起動することによりそれぞれプロセスとしてＯＳ１２１上に生成されて実行される。そして、各プロセス内部には、複数のスレッドが起動され、ＯＳ１２１の管理下でこれらのスレッドのＣＰＵ占有時間を切り替えることにより並列実行が実現されている。このため、プロセス切り替えによる並列実行と比較して、並列実行時の処理速度の向上が図られている。

各アプリプロセスと各コントロールサービスプロセスとは、メソッドの実行によるプロセス間通信によってメッセージの送受信が行われる。

＜＜ＮＣＳ＞＞
ここからは、本実施形態に係るデータ処理機能を有するＮＣＳ１２８について、図３及び図４を用いて説明する。
（ソフトウェア構成の概要）
図３は、本発明の第１の実施形態に係るＮＣＳ１２８のソフトウェア構成の一例を示す図である。

本実施形態に係るＮＣＳ１２８のソフトウェア構成は、主に、各プロトコルによって受信したデータを各アプリケーション１３０に振り分けたり、アプリケーション１３０からデータをネットワーク側に送信する際の仲介を行うモジュール群で構成される。そのモジュール群の中に、本実施形態に係るＷＳ−ＭＦＰモジュール群２０がある。

ここで上記の「ＷＳ」とは、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）のワーキンググループ（ＷＧ）により進められているＸＭＬ（Extensible Markup Language）をベースとした標準化Ｗｅｂサービスの意味である。「ＷＳ」については、その詳細が開示されている公開文献「Devices Profile for Web Services」を開示し、ここでの説明を省略する。公開文献の入手先ＵＲＬは、"http://specs.xmlsoap.org/ws/2006/02/devprof/devicesprofile.pdf"である。また、以降の説明の中で、「ＷＳ」がつく機能名やモジュール名は、この標準化Ｗｅｂサービスに準拠して設計された機能やモジュールである。例えば、ＷＳ−ＭＦＰモジュール群２０は、標準化Ｗｅｂサービスに準拠して設計された複合機用のモジュール群を示している。

図３に示すＷＳ−ＭＦＰモジュール群２０は、外部機器と画像形成装置１００が有するプリンタアプリ１１１との間でプリンタ関連のデータを取り扱うＷＳ−Ｐｒｉｎｔｅｒ２１pや、外部機器と画像形成装置１００が有するスキャナアプリ１１４との間でスキャナ関連のデータを取り扱うＷＳ−Ｓｃａｎｎｅｒ２１sと、外部機器と画像形成装置１００との間で機器関連のデータを取り扱うＤＦＭモジュール２２とから構成され、上記各ソフトウェア部品は、それぞれ別のプロセスで起動され動作するように実装される。

例えば、ＷＳ−Ｐｒｉｎｔｅｒ２１pは、ＤＦＭモジュール２２からのプリンタアプリ１１１に関する情報の取得要求に応答したり、外部機器からの印刷要求をプリンタアプリ１１１に通知したりする機能である。ＤＦＭモジュール２２は、ＷＳ−Ｐｒｉｎｔｅｒ２１pやＷＳ−Ｓｃａｎｎｅｒ２１sなどからプリンタアプリ１１１やスキャナアプリ１１４などのアプリケーション情報を取得し、取得した情報を基に外部機器に対して、画像形成装置１００が提供可能な標準化Ｗｅｂサービスに関する情報を含む機器情報を送信する。

このように、本実施形態に係る画像形成装置１００は、上記構成によるＮＣＳ１２８を有することにより、外部機器と画像形成装置１００との間でデータの送受信を行うことができる。

上記において、ＤＦＭモジュール２２からＷＳ−Ｐｒｉｎｔｅｒ２１pが保有するプリンタ関連の情報を取得する場合について説明を行ったが、互いに別のプロセスによって動作しているため、プロセス間通信によりデータの送受信を行う。
（ソフトウェア構成の詳細）
図４は、本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群２０内部のプロセス間通信の構成の一例を示す図である。

図４に示すように、本実施形態に係るＷＳ−ＭＦＰモジュール群２０は、ＤＦＭモジュール２２、ＷＳ−Ｐｒｉｎｔｅｒ２１p及びＷＳ−Ｓｃａｎｎｅｒ２１sとから構成され、上記各ソフトウェア部品は、それぞれ別のプロセスで起動され動作するように実装される。また、上記各ソフトウェア部品には、プロセス間通信機能を有するＩＭＣ（Internal Message Communication）５１のライブラリがリンクされている。

以下に、ＤＦＭモジュール２２、ＷＳ−Ｐｒｉｎｔｅｒ２１p、及びＷＳ−Ｓｃａｎｎｅｒ２１sそれぞれを構成する主なソフトウェア部品について説明する。

ＷＳ−Ｐｒｉｎｔｅｒ２１pは、ＰｒｉｎｔｅｒＤＣＰ４１pとＷＳ−Ｅｖｅｎｔｉｎｇ４２pとから構成される。

ＰｒｉｎｔｅｒＤＣＰ４１pは、プリンタ機能を利用する外部機器が有する機能（例えばプリンタドライバなど）と画像形成装置１００が有するプリンタアプリ１１１との間で、プリンタ関連のデータを送受信する。また、ＷＳ−Ｅｖｅｎｔｉｎｇ４２pは、プリンタ機能を利用する外部機器が有する機能から送信された印刷要求などの処理要求イベントを画像形成装置１００が有するプリンタアプリ１１１に通知する。

ＷＳ−Ｐｒｉｎｔｅｒ２１pは、上記機能構成により、例えば、外部機器からの印刷要求に従って、画像形成装置１００が有するプリンタアプリ１１１により、受信した画像データの印刷を行い、印刷が完了した旨を外部機器へ通知する処理を実現する。

ＷＳ−Ｓｃａｎｎｅｒ２１sは、ＳｃａｎｎｅｒＤＣＰ４１sとＷＳ−Ｅｖｅｎｔｉｎｇ４２sとから構成される。ＳｃａｎｎｅｒＤＣＰ４１sは、スキャナ機能を利用する外部機器が有する機能（例えば文書管理ソフトウェアなど）と画像形成装置１００が有するスキャナアプリ１１４との間で、スキャナ関連のデータを送受信する。また、ＷＳ−Ｅｖｅｎｔｉｎｇ４２sは、スキャナ機能を利用する外部機器が有する機能から送信された画像読み取り要求などの処理要求イベントを画像形成装置１００が有するスキャナアプリ１１４に通知する。

ＷＳ−Ｓｃａｎｎｅｒ２１sは、上記機能構成により、例えば、外部機器からの画像読み取り要求に従って、画像形成装置１００が有するスキャナアプリ１１４により、原稿の読み取りを行い、読み取りが完了した旨を外部機器へ通知する処理を実現する。

ＤＦＭモジュール２２は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ３１と、ＷＳ−Ｔｒａｎｓｆｅｒ３２と、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈｅｎｇｅ３３と、ＷＳＤ−Ｍａｎａｇｅｒ３４とから構成される。

ＷＳ−Ｄｉｓｃｏｖｅｒｙ３１は、標準化Ｗｅｂサービスにより、搭載するアプリケーション機能を提供可能な装置（ＷＳ−Ｄｅｖｉｃｅ）がネットワークに参加したことを、外部機器が有する機能が検知するためのメッセージを、外部機器と画像形成装置１００との間で送受信する。

ＷＳ−Ｔｒａｎｓｆｅｒ３２は、画像形成装置１００が提供可能な標準化Ｗｅｂサービスに関する情報（機器情報）を通知するメッセージを、外部機器と画像形成装置１００との間で送受信する。また、ＷＳ−Ｔｒａｎｓｆｅｒ３２は、ＵＤＰ（User Datagram Protocol）により、外部機器に対して、画像形成装置１００がネットワークに参加した旨を知らせる（例えば「Hello」コマンドをネットワークに接続される全ての外部機器に対してマルチキャストする）。

ＷＳ−ＭｅｔａｄａｔａＥｘｃｈｅｎｇｅ３３は、ＩＭＣ５１が有するプロセス間通信機能によりＷＳ−Ｐｒｉｎｔｅｒ２１p及びＷＳ−Ｓｃａｎｎｅｒ２１sから取得した各アプリケーションに関する情報などを基に、画像形成装置１００が提供可能な標準化Ｗｅｂサービスに関する情報のデータを生成する。

ＷＳＤ−Ｍａｎａｇｅｒ３４は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ３１、ＷＳ−Ｔｒａｎｓｆｅｒ３２、及びＷＳ−ＭｅｔａｄａｔａＥｘｃｈｅｎｇｅ３３、並びに、ＷＳ−Ｐｒｉｎｔｅｒ２１p及びＷＳ−Ｓｃａｎｎｅｒ２１sが有する各ＤＣＰ４１p及び４１sなどの動作制御・管理を行う。

ＤＦＭモジュール２２は、上記機能構成により、例えば、標準化Ｗｅｂサービスにより、搭載するアプリケーション機能を提供可能な画像形成装置１００の自動検知機能を実現している。

ＩＭＣ５１は、プロセス間通信機能を有しており、他のＤＦＭモジュール２２、ＷＳ−Ｐｒｉｎｔｅｒ２１p、及びＷＳ−Ｓｃａｎｎｅｒ２１sなどのように、ソフトウェア部品として単独で機能するものではなく、単独で機能するソフトウェア部品に対して、プロセス間でデータの送受信などを行うためのプロセス間通信プログラム群が１つにまとめられたファイル、すなわちライブラリとして提供される。

以下に、ライブラリとして提供されるＩＭＣ５１のプロセス間通信プログラム群について、図５を用いて説明する。図５は、本発明の第１の実施形態に係るＩＭＣ５１のソフトウェア構成の一例を示す図である。

（ＩＭＣライブラリのソフトウェア構成）
本実施形態において実装されるＩＭＣ５１のソフトウェア構成は、図５（a）に示すように３つのレイヤで構成され、各レイヤがプロセス間通信を行うための複数のプログラムを有している。

［ＩＭＣＩ／Ｆレイヤ］
ＩＭＣＩ／Ｆレイヤ６１は、プロセス間通信機能を利用するソフトウェア部品（送受信側の機能を実現するモジュール）のプログラムコードから実際にコールすることが可能な関数６１a〜d（以下に示す４つの関数）がまとめられたレイヤである。
（a）PutMsg()６１a（送信指示手段に対応する機能を実現するプログラム）
要求メッセージの送信を指示する関数。
（b）SendReceive()６１b（応答受信指示手段に対応する機能を実現するプログラム）
要求メッセージを送信後、要求に応じた応答メッセージの受信待ちを指示する関数。
（c）GetMsg()６１c（要求待ち指示手段に対応する機能を実現するプログラム）
要求メッセージの受信待ちを指示する関数。
（d）registAPI()６１d（格納先情報設定指示手段に対応する機能を実現するプログラム）
要求メッセージに応じて、画像形成装置１００で実行可能な処理の中から、要求メッセージにより要求される処理を特定し処理を実行するソフトウェア部品（以下、「コールバック関数」という。）の格納先情報（以下、「コールバック関数へのポインタ」という。）の設定を指示する関数（コールバック関数の登録を指示する関数）。

関数６１a〜dは、図５（b）に示す要求メッセージを送受信する場合に想定される４つの動作指示に対応付けられている。例えば、受信側からの処理要求に応じた応答メッセージを必要とせず、受信側に行わせる処理を要求する要求メッセージのみを送信したい場合（図中に示す（１）の場合）には、プログラムコードから関数PutMsg()６１aをコールすればよい。また、送信側から送信される要求メッセージの受信を待ち受ける状態へ移行したい場合（図中に示す（３）の場合）には、プログラムコードから関数GetMsg()６１cをコールすればよい。

このように、ＩＭＣＩ／Ｆレイヤ６１は、独立性の高いプロセス間通信機能を実現するため、送受信側の処理内容や通信目的などの取り決めに依存しない基本的な動作のみを指示するインタフェースを提供している。

［ＡＰＩ内部処理レイヤ］
ＡＰＩ内部処理レイヤ６２は、ＩＭＣＩ／Ｆレイヤ６１の各関数に対応して実際の処理（内部処理）を行う関数６２a〜e（以下に示す５つの関数）がまとめられたレイヤである。
（e）Send()６２a
上位レイヤに位置する関数PutMsg()６１aからコールされ、要求メッセージの送信のみを行う関数。
（f）RequestResponse()６２b
上位レイヤに位置する関数SendReceive()６１bからコールされ、要求メッセージの送信から応答メッセージの受信までの処理を行う関数。
（g）Receive()６２c
上位レイヤに位置する関数GetMsg()６１cからコールされ、要求メッセージの受信待ち受け状態への前処理を行う関数。関数Receive()６２cは、以下に挙げる関数を内部的に実行する。
・bind()
関数socket()により生成されたソケットに「ＩＰアドレス」や「ポート番号」を指定してソケットを特定する関数。
・listen()
関数connect()からのコネクションの確立要求を待つ関数。
・accept()
関数connect()からの確立要求を受け取り、実際にデータ回線を確立するための新しいソケットを生成する関数。
（h）ProcessReceivedMsg()６２d
関数Receive()６２c実行後の要求メッセージの受信待ち受け状態において、要求メッセージの受信から応答メッセージの送信までの処理を行う関数。
（i）Register()６２e
上位レイヤに位置する関数registAPI()６１dからコールされ、要求メッセージにより要求される処理を特定するソフトウェア部品（コールバック関数）の格納先情報（関数へのポインタ）を設定する関数、すなわち、登録指示を受けコールバック関数を登録する関数である。

［送受信処理実行レイヤ］
送受信処理実行レイヤ６３は、ＡＰＩ内部処理レイヤ６２の各関数からコールされ、プロセス間でのデータの送受信処理を行う関数６３a〜c（以下に示す３つの関数：通信制御手段）がまとめられたレイヤである。
（j）Connect()６３a
上位レイヤに位置する関数Send()６２a及び関数RequestResponse()６２bからコールされ、関数connect()を実行し、コネクションの確立要求を行う関数。
（k）SendMsg()６３b
上位レイヤに位置する関数Send()６２a、関数RequestResponse()６２b、及びProcessReceivedMsg()６２dからコールされ、関数send()を実行し、データ送信を行う関数。
（l）Recv()６３c
上位レイヤに位置する関数RequestResponse()６２b及びProcessReceivedMsg()６２dからコールされ、関数recv()を実行し、データ受信を行う関数。

［その他（コールバック関数）］
（m）callCB()６４（実行手段に対応する機能を実現するプログラム）
上位レイヤに位置する関数Register()６２eにより、要求メッセージにより要求される処理を特定し処理を実行する関数（registAPI()６１dをコールすることで登録された関数）。

関数callCB()６４は、受信側のＩＭＣ５１が要求メッセージを受信すると、上位レイヤに位置する関数ProcessReceivedMsg()６２dによって、設定されている関数callCB６４へのポインタに基づいてコールされ実行される。また、関数callCB()６４は、例えば、受信側のＤＦＭモジュール２２に含まれており、受信側のＩＭＣ５１には、設定されたポインタの値を基に関数callCB()６４をコールバックする関数（以下、「呼び出し先関数」という。）が定義されている。このような関数callCB()６４をコールバック関数という。

このように、本実施形態に係る画像形成装置１００では、異なるプロセスで動作するＤＦＭモジュール２２と、ＷＳ−Ｐｒｉｎｔｅｒ２１p又はＷＳ−Ｓｃａｎｎｅｒ２１sとの間で行うプロセス間通信を、ＩＭＣ５１のプロセス間通信プログラムを実行することで実現している。また、本実施形態では、ＤＦＭモジュール２２、ＷＳ−Ｐｒｉｎｔｅｒ２１p、及びＷＳ−Ｓｃａｎｎｅｒ２１sそれぞれのソフトウェア部品が、ＩＭＣ５１のプロセス間通信プログラムを用いることができるように、各ソフトウェア部品にＩＭＣ５１のライブラリをリンクし実装する。

＜プロセス間通信におけるデータ処理機能＞
次に、これまで説明を行ってきたハードウェア及びソフトウェア構成を踏まえ、本実施形態に係る画像形成装置１００が有する「プロセス間通信におけるデータ処理機能」について、図６を用いて説明する。図６は、本発明の第１の実施形態に係る画像形成装置１００内のデータ処理機能の機能構成の一例を示す図である。

＜＜機能構成の概要＞＞
本実施形態に係る画像形成装置１００は、主に、送信側からの要求に応じて処理を行う受信側の機能部７１と、受信側に処理を要求する送信側の機能部７２と、送信側の機能部７１と受信側の機能部７２との間のプロセス間通信を行うプロセス間通信部７３とから構成される。

また、上記各機能部は、図４において説明を行ったＷＳ−ＭＦＰモジュール群２０のソフトウェア部品が、画像形成装置１００が有するコントローラ１３に配置されたＲＯＭ１３aからＲＡＭ１３b上に読み出され、ＣＰＵ１３cで実行されることで実現される機能である。

例えば、「外部機器に要求に応じてＤＦＭモジュール２２がＷＰ−Ｐｒｉｎｔｅｒ２１pやＷＳ−Ｓｃａｎｎｅｒ２１sなどから提供可能なサービスに関する情報を取得するとき」に行われる、ＤＦＭモジュール２２が動作するプロセスと、ＷＰ−Ｐｒｉｎｔｅｒ２１p又はＷＳ−Ｓｃａｎｎｅｒ２１sが動作するプロセスとのプロセス間通信では、送信側の機能部７１がＤＭＦモジュール２２にあたり、受信側の機能部７２がＷＳ−Ｐｒｉｎｔｅｒ２１p又はＷＳ−Ｓｃａｎｎｅｒ２１sにあたり、プロセス間通信部７３がＩＭＣ５１にあたる。このように、各ソフトウェア部品によって上記機能が実現されている。

＜＜各機能部の概要＞＞
上記に挙げた主要な各機能部の概要について説明する。

受信側の機能部７１は、初期化部７１aと内容解釈部７１bを有している。

初期化部７１aは、受信側の機能部７１が起動されたときの動作前の処理を行う。その中で、初期化部７１aは、受信側の前処理として、要求メッセージにより要求される処理を特定し処理を実行するコールバック関数６４の関数へのポインタを、受信側のプロセス間通信部７３に設定する。すなわち、受信側の機能部７１が有するコールバック関数６４を、受信側のプロセス間通信部７３に登録する。

内容解釈部７１bは、送信側の機能部７２から送信された要求メッセージに応じて、画像形成装置１００で実行可能な処理の中から、要求メッセージにより要求される処理を特定するという、受信した要求メッセージの内容に応じて、受信側の機能部７１で行う処理を切り換えるディスパッチ機能を有している。内容解釈部７１bは、初期化部７１aにより前処理の段階で登録されるコールバック関数６４が実行されることで実現する機能である。

送信側の機能部７２は、メッセージ設定部７２mを有しており、メッセージ設定部７２mは、受信側の機能部７１に要求する処理内容に応じて、送信側の機能部７２から送信する要求メッセージを設定する。メッセージ設定部７２mは、プロセス間通信部７３が提供するＩ／Ｆ関数６１a〜dを用いて要求メッセージを設定する。

プロセス間通信部７３は、送信部７４と、受信部７５と、手続き登録部７６と、登録手続き実行部７７とを有している。

送信部７４は、受信側の機能部７１が動作するプロセスに対して、メッセージ設定部７２mからの設定に基づいて発行された要求メッセージを送信する。また、受信部７５は、送信側の機能部７２が有する送信部７４により送信された要求メッセージを受信する。

手続き登録部７６は、受信側の機能部７１が有する初期化部７１aにより設定されたコールバック関数６４の関数へのポインタを、所定の記憶領域に保持する（保持手段に対応する機能）。そのため、手続き登録部７６は、受信側の機能部７１が起動したときに、ＲＡＭ１３bの記憶領域の中から所定の記憶領域を確保しておく。また、登録手続き実行部７７は、手続き登録部７６により保持されているコールバック関数６４の関数へのポインタに基づいて、要求メッセージにより要求される処理を特定し処理を実行するコールバック関数６４に実行を指示する。その結果、処理の実行制御が、受信側のプロセス間通信部７３から受信側の機能部７１へ移行し、コールバック関数６４によって、特定された処理が実行される。登録手続き実行部７７は、受信側のプロセス間通信部７３が有する呼び出し先関数が実行されることで実現する機能である。

＜＜動作概要＞＞
次に、上記各機能部による本実施形態に係る「プロセス間通信におけるデータ処理機能」の動作について説明する。

（１）要求メッセージ受信待ち受け（前処理）：受信側
まず、受信側の機能部７１は、動作するプロセスが起動されると、初期化部７１aにより予め決められた初期化処理を行う。まず、初期化部７１aは、ＩＭＣ５１が提供する関数registAPI()６１dをコールし、要求メッセージにより要求される処理を特定し処理を実行するコールバック関数（関数callCB）６４の関数へのポインタを、受信側のプロセス間通信部７３に設定する（関数callCB６４を登録する）。その結果、設定された関数へのポインタは、受信側のプロセス間通信部７３が有する手続き登録部７６により保持される。その後、初期化部６１dは、ＩＭＣ５１が提供する関数GetMsg()６１cをコールし、送信側からの要求メッセージの受信待ち受け状態へ移行する。

（２）要求メッセージの設定・送信：送信側
送信側の機能部７２は、メッセージ設定部７２mにより要求メッセージの設定を行う。メッセージ設定部７２mは、受信側の機能部７１に要求する処理内容に応じて、ＩＭＣ５１が提供する関数PutMsg()６１a又は関数SendReceive()６１bをコールし、要求メッセージの設定を行う。その後に、送信側のプロセス間通信部７３は、メッセージ設定部７２mによる設定を基に発行された要求メッセージを、送信側のプロセス間通信部７３が有する送信部７４に渡し、受信側の機能部７１へ送信する。送信部７４は、関数PutMsg()６１a又は関数SendReceive()６１bの内部でコールされる関数Send()６２a又は関数RequestResponse()６２bにより実行される。

（３）要求メッセージの受信・内容解釈：受信側
受信側のプロセス間通信部７３は、受信部７５により要求メッセージを受信する。受信部７５は、関数GetMsg()６１cの内部でコールされる関数Receive()６２c及び関数ProcessReceivedMsg()６２dにより実行される。

（４）要求メッセージの内容解釈機能を起動：受信側
受信側のプロセス間通信部７３は、要求メッセージを受信すると、登録手続き実行部７７によって、手続き登録部７６により保持している関数へのポインタ（関数callCB()６４へのポインタ）に基づいてコールバック関数６４を実行する（関数callCB()６４をコールバックする）。このとき、受信した要求メッセージは、呼び出し先関数を介してコールバック関数６４の引数として渡される。このようにして、受信側の機能部７１が有する内容解釈部７１bを起動する。

（５）要求される処理の実行：受信側
受信側の機能部７１は、内容解釈部７１bにより、要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、要求メッセージにより要求される処理を特定し、特定された処理を受信側の機能部７１で実行する。内容解釈部７１bは、受信側のプロセス間通信部７３から渡された要求メッセージの所定の情報に基づいて、要求メッセージにより要求される処理を特定する。

（６）応答メッセージの送信：受信側
受信側の機能部７１は、送信側の機能部７２に要求に応じた応答メッセージを送信する場合に、内容解釈部７１bにより特定され実行された処理結果を、受信側のプロセス間通信部７３が有する送信部７４に渡し、送信側の機能部７２へ送信する。送信部７４は、関数PutMsg()６１aの内部でコールされる関数Send()６２aにより実行される。

＜プロセス間通信におけるデータ処理機能の詳細＞
本実施形態に係る「プロセス間通信におけるデータ処理機能」において、上記動作の中で行われている（１）〜（６）までの処理を、より詳しく説明する。

＜＜内容解釈処理（ディスパッチャ）の事前登録＞＞
受信側の機能部１７が有する初期化部７１aは、ＩＭＣ５１が提供する関数registAPI()６１dをコールし、要求メッセージにより要求される処理を特定し処理を実行する内容解釈部７１bの機能を実現するコールバック関数６４の関数へのポインタを、受信側のプロセス間通信部７３に設定し手続き登録部７６に保持する（コールバック関数６４を登録する）。すなわち、初期化部７１aは、受信側の機能部１７が有する内容解釈部７１bの機能を実現する関数callCB()６４へのポインタを、受信側のプロセス間通信部７３が有する呼び出し先関数のポインタに代入することで設定する。但し、この方法以外にもコールバック関数６４の関数へのポインタを呼び出し先関数の引数を介して渡す方法などがあり、本実施形態は、この方法に限定されるものではない。

よって、初期化部７１aが行う上記処理は、コールバック関数６４として内容解釈部７１bの機能を実現するプログラムを設定することから、受信側の機能部７１が起動したときなどに、受信側が送信側からの要求メッセージを受信する前の段階で行っておく必要がある。

これによって、本実施形態に係るデータ処理機能では、呼び出し先関数からコールバック関数６４を実行させることで、呼び出し先関数からコールバック関数６４に実行制御を移すことができる。すなわち、送受信側の処理内容や通信目的などの取り決めに依存する要求メッセージの内容解釈機能をプロセス間通信部７３の機能から分離して処理することができ（プロセス間通信部７３から受信側の機能部７１へ実行制御を移すことができ）、プロセス間通信を行う機能部の独立性が高くなる。

＜＜要求メッセージの設定＞＞
送信側の機能部７２が有するメッセージ設定部７２mは、受信側の機能部７１に要求する処理内容に応じて、ＩＭＣ５１が提供する関数PutMsg()６１a又は関数SendReceive()６１bをコールし、関数の引数を介して要求メッセージの設定を行う。このとき、関数PutMsg()６１a又は関数SendReceive()６１bには、以下に説明を行う要求メッセージのデータ仕様に基づいて関数の引数が設定される。

図７は、本発明の第１の実施形態に係る要求メッセージ８１のデータ仕様の一例を示す図である。図７には、本実施形態に係るＷＳ−Ｐｒｉｎｔｅｒ２１pが送信側の機能部７２である場合の例が示されている。

本実施形態に係る要求メッセージ８１のデータ仕様は、図７に示すように、要求メッセージ８１により実行される処理を示す「機能名」と、処理を行うときに用いるパラメータ値の数を示す「データ個数」と、処理を行うときに用いるパラメータ値である「データ」とが、「プロセス間通信の目的」ごとに構成される。

上記データ仕様は、各プロセス間でやり取りしたい「プロセス間通信の目的」と「目的ごとの受信側の処理」とを基に、予め送信側と受信側との間で決めておき、上記データ仕様に従って所定の形式によりデータ化しておく。

送信側の機能部７２が有するメッセージ設定部７２mは、送信側の機能部７２を実現するプログラムコードの中で、関数の引数に上記データ仕様の「機能名」、「データ数」、及び「データ」を設定したＩＭＣＩ／Ｆレイヤ６１が提供する関数PutMsg()６１a又は関数SendReceive()６１bをコールし、発行される要求メッセージ８１の設定を行う。

例えば、送信側の機能部７２が処理の中で、ＷＳ−Ｐｒｉｎｔｅｒ２１pの処理終了を受信側の機能部７１に通知した場合には、メッセージ設定部７２mによって、引数に「機能名＝DCP2DFM_Unregister」、「データ数＝１」、及び「データ＝（InstanceIDの値）」を設定した関数PutMsg()６１a又は関数SendReceive()６１bをコールすることで、ＷＳ−Ｐｒｉｎｔｅｒ２１p処理終了通知メッセージが設定される。その結果、送信側のプロセス間通信部７３が有する送信部７４が、発行された要求メッセージ８１を受信側の機能部７１へ送信する。

このように、本実施形態に係るデータ処理機能では、ＩＭＣＩ／Ｆレイヤ６１が提供するメッセージ送信を行う関数PutMsg()６１a又は関数SendReceive()６１bが、プロセス間通信の目的に対応する機能を決定するものではない。

これによって、本実施形態に係るデータ処理機能では、送受信側の処理内容や通信目的などの取り決めに依存する要求メッセージ設定機能を、プロセス間通信部７３の機能から分離して処理することができ、プロセス間通信を行う機能部の独立性が高くなる。

＜＜要求メッセージの内容解釈（ディスパッチ）＞＞
受信側の機能部７１が有する内容解釈部７２bは、受信側のプロセス間通信部７３が有する登録手続き実行部７７によって実行を指示される。

受信側のプロセス間通信部７３の受信部７５が要求メッセージ８１を受信すると、登録手続き実行部７７によって、手続き登録部７６により保持している関数callCB()６４へのポインタに基づいて、要求メッセージ８１により要求される処理を特定する関数callCB()６４をコールバックする。このとき、受信した要求メッセージ８１は、関数callCB()６４の引数として渡される。このようにして、受信側の機能部７１が有する内容解釈部７１bを起動する。

内容解釈部７２bは、引数を介して受け取った要求メッセージ８１のデータを解釈し、データ内の「機能名」、「データ個数」、及び「データ」を解釈する。その結果、内容解釈部７２bは、解釈して得た「機能名」に基づいて、画像形成装置１００で実行可能な処理の中から、要求メッセージ８１により要求される処理を特定する。すなわち、受信した要求メッセージ８１の内容に応じて、受信側の機能部７１で行う処理をディスパッチする。

内容解釈部７２bの機能を実現する関数callCB()６４は、受信側の機能部７１が有する関数であり、送受信側の処理内容や通信目的などの取り決めに従って設計されているため、図７において説明を行った要求メッセージ８１のデータ仕様から、引数を介して受け取った要求メッセージ８１の「機能名」に基づいて、予め処理手続きがプログラムコード化された「機能名」に対応する処理が特定される。

＜＜要求処理の実行＞＞
受信側の機能部７１は、要求メッセージ８１を解釈して得た「データ」を基に、内容解釈部７１bにより特定された処理を実行する。このとき、受信側の機能部７１は、解釈して得た「データ個数」に基づいて、受信した要求メッセージ８１のデータが正しいデータであるかを検証する（データ検証手段に対応する機能）。より具体的には、解釈して得た「データ個数」と、「データ」として受信したデータ数とが一致しているか否かを判定する。その結果、一致している場合には、要求処理を実行する。また、一致していない場合には、要求メッセージ８１のデータが誤っていると判断し、要求処理を実行しない。

これによって、本実施形態に係るデータ処理機能では、プロセス間通信を行うときの送受信側の処理内容や通信目的などの取り決めに依存する処理が、受信側の機能部７１のプログラム群（コールバック関数６４を含む）に統合され、プロセス間通信部７３に、送受信側の取り決めに依存するプログラムコードやデータが含まれないため、画像形成装置１００のデータ処理において、プロセス間通信部７３の独立性が高く、送受信側の機能部７１及び７２を容易に拡張することができる。言い換えれば、例えば、ＷＳ−Ｐｒｉｎｔｅｒ２１pやＷＳ−Ｓｃａｎｎｅｒ２１sなどのような機能拡張の頻度が比較的高い機能に対しても、柔軟に対応することができ、容易に機能実装が行うことができる。

＜＜応答メッセージの送信＞＞
受信側の機能部７１は、送信側の機能部７２に要求に応じた応答メッセージを送信するか否かを判断し、送信側の機能部７２へ応答メッセージを送信する。このときに行われる応答メッセージの送信判定は、要求処理の実行結果があるか否かによって判定する。より具体的には、内容解釈部７２bの機能を実現するコールバック関数６４が、登録手続き実行部７７によって実行され、コールバック関数６４からの戻り値（return値）があるか否か（値が"NULL"か否か）を、受信側のプロセス間通信部７３により判定する。その結果、戻り値がある場合には、その値を基に送信部７４により応答メッセージを、受信側の機能部７１へ送信する。また、戻り値がない場合（値が"NULL"の場合）には、応答する必要がないと判断する。

これによって、本実施形態に係るデータ処理機能では、要求に対して応答を必要としない要求の要求メッセージ８１の送信と、応答を必要とする要求メッセージ８１の送信との両方に対応することができる。

本実施形態に係る画像形成装置１００は、上記に説明を行った各機能部による構成により、要求メッセージ８１に応じて、画像形成装置１００で実行可能な処理の中から、要求メッセージ８１により要求される処理を特定する機能を実現するコールバック関数６４を、予め受信側のプロセス間通信部７３に登録しておき、受信側のプロセス間通信部７３により要求メッセージ８１を受信すると、登録されているコールバック関数６４をコールして実行する。

その結果、画像形成装置１００は、プロセス間通信を行うときの送受信側の処理内容や通信目的などの取り決めに依存する処理が、受信側の機能部７１のプログラム群（コールバック関数６４を含む）に統合され、プロセス間通信部７３に、送受信側の取り決めに依存するプログラムコードやデータが含まれることがないため、画像形成装置１００のデータ処理において、プロセス間通信部７３の独立性が高く、送受信側の機能を容易に拡張することができる「画像形成装置１００内のデータ処理機能」を実現している。

＜処理手順＞
上記に説明を行った本実施形態に係る「データ処理機能」の具体的な処理手順について図８〜１１を用いて説明する。図８及び図９では、プロセス間通信を介した送信側と受信側の基本的なデータ処理手順の例を示している。

＜＜基本処理手順＞＞
図８は、本発明の第１の実施形態に係る画像形成装置１００内のデータ処理機能の基本処理手順の一例（その１）を示すシーケンス図である。図８では、送信側の機能部７２からの要求に対して受信側の機能部７１が応答しない場合の処理手順について説明する。

受信側の機能部７１は、前処理として、初期化部７１aにより、プロセス間通信部７３の関数registAPI()６１dをコールし（ステップＳ１０１）、要求メッセージ８１により要求される処理を特定するコールバック関数６４を、受信側のプロセス間通信部７３が有する手続き登録部７６に登録する（ステップＳ１０２）。

受信側のプロセス間通信部７３は、コールバック関数６４が登録されると、登録が完了した旨を受信側の機能部７１に返す（ステップＳ１０３）。

次で、受信側の機能部７１は、初期化部７１aにより、受信側のプロセス間通信部７３の関数GetMsg()６１cをコールし（ステップＳ１０４）、受信側のプロセス間通信部７３に、要求メッセージ８１の受信待ち受けの開始を指示する。

上記の処理手順によって、受信側の機能部７１は、送信側からの要求メッセージ８１を受信可能な状態となる。

送信側の機能部７２は、メッセージ設定部７２aにより、要求メッセージ８１のデータ仕様に基づいて、発行する要求メッセージ８１に応じた「機能名」、「データ個数」、及び「データ」を、送信側のプロセス間通信部７３の関数PutMsg()６１aの引数に設定した後、関数PutMsg６１aをコールする（ステップＳ２０１）。

送信側のプロセス間通信部７３は、送信部７４により、引数の値に基づいて発行された要求メッセージ８１を受信側のプロセス間通信部７３へ送信し（ステップＳ２０２）、送信が完了した旨を送信側の機能部７２に返す（ステップＳ２０３）。

受信側のプロセス間通信部７３は、受信部７５により、送信側から送信された要求メッセージ８１を受信し、手続き登録部７６に登録されたコールバック関数６４を、受信した要求メッセージ８１を引数に、登録手続き実行部７７（呼び出し先関数）によりコールバックし、受信側の機能部７１に実行制御を移行する（ステップＳ２０４）。

実行制御が移行した受信側の機能部７１では、コールバック関数６４がコールされたことで、内容解釈部７１bが機能し、要求メッセージ８１を解釈し、解釈して得た「機能名」から、要求に対応する処理を特定し実行する（ステップＳ２０５）。

内容解釈部７１bは、対応処理が終了すると、処理が終了した旨を受信側のプロセス間通信部７３へ返す（ステップＳ２０６）。

図９は、本発明の第１の実施形態に係る画像形成装置１００内のデータ処理機能の基本処理手順の一例（その２）を示すシーケンス図である。図９では、送信側の機能部７２からの要求に対して受信側の機能部７１が応答する場合の処理手順について説明する。

図９と図８で異なる処理手順は、送信側の機能部７２が要求メッセージ８１を受信側の機能部７１へ送信するステップＳ３０１以降の処理である。よって、図９に示すステップＳ３０１より前の処理手順については、図８をもって説明を省略する。

送信側の機能部７２は、メッセージ設定部７２aにより、要求メッセージ８１のデータ仕様に基づいて、発行する要求メッセージ８１に応じた「機能名」、「データ個数」、及び「データ」を、送信側のプロセス間通信部７３の関数SendReceive()６１bの引数に設定した後、関数SendReceive()６１bをコールする（ステップＳ３０１）。

送信側のプロセス間通信部７３は、送信部７４により、引数の値に基づいて発行された要求メッセージ８１を受信側のプロセス間通信部７３へ送信する（ステップＳ３０２）。

受信側のプロセス間通信部７３は、受信部７５により、送信側から送信された要求メッセージ８１を受信し、手続き登録部７６に登録されたコールバック関数６４を、受信した要求メッセージ８１を引数に、登録手続き実行部７７によりコールバックし、受信側の機能部７１に実行制御を移行する（ステップＳ３０３）。

実行制御が移行した受信側の機能部７１では、コールバック関数６４がコールされたことで、内容解釈部７１bが機能し、要求メッセージ８１を解釈し、解釈して得た「機能名」から、要求に対応する処理を特定し実行する（ステップＳ３０４）。

内容解釈部７１bは、対応処理が終了すると、コールバック関数６４の戻り値を受信側のプロセス間通信部７３へ返す（ステップＳ３０５）。

受信側のプロセス間通信部７３は、処理結果である戻り値を基に応答メッセージの有無を判定し（ステップＳ３０６）、判定結果から応答が必要と判断された場合に、送信部６４により処理結果を基に発行された応答メッセージを送信側の機能部７１へ送信する（ステップＳ３０７）。

送信側のプロセス間通信部７３は、受信部７５により受信した応答メッセージを、受信側の機能部７１へ転送する（ステップＳ３０８）。

このように、本実施形態に係るデータ処理プログラムは、本実施形態に係る画像形成装置１００において、予め登録しておいた、要求メッセージ８１に応じて、画像形成装置１００で実行可能な処理の中から、要求メッセージ８１により要求される処理を特定し処理を実行するコールバック関数６４を、受信側のプロセス間通信部７３により要求メッセージ８１を受信したときに実行するように機能させることができる。

＜＜ＷＳ−ＭＦＰモジュール群２０での処理手順＞＞
図１０及び図１１では、プロセス間通信を介したＤＦＭモジュール２２とＷＳ−Ｐｒｉｎｔｅｒ２１pとの間のデータ処理手順の例が示されている。

図１０は、本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群２０のデータ処理機能の処理手順の一例（その１）を示すシーケンス図である。図１０では、送信側のＷＳ−Ｐｒｉｎｔｅｒ２１pからの要求に対して受信側のＤＦＭモジュール２２が応答しない場合の処理手順について説明する。

受信側のＤＦＭモジュール２２は、前処理として、初期化部７１aにより、プロセス間通信部７３の関数registAPI()６１dをコールし（ステップＳ４０１）、要求メッセージ８１により要求される処理を特定するコールバック関数６４を、受信側のＩＭＣ５１が有する手続き登録部７６に登録する（ステップＳ４０２）。

受信側のＩＭＣ５１は、コールバック関数６４が登録されると、登録が完了した旨を受信側の機能部７１に返す（ステップＳ４０３）。

次で、受信側のＤＦＭモジュール２２は、初期化部７１aにより、受信側のＩＭＣ５１の関数GetMsg()６１cをコールし（ステップＳ４０４）、受信側のＩＭＣ５１に、要求メッセージ８１の受信待ち受けの開始を指示する。

上記の処理手順によって、受信側のＤＦＭモジュール２２は、送信側からの要求メッセージ８１を受信可能な状態となる。

送信側のＷＳ−Ｐｒｉｎｔｅｒ２１pは、メッセージ設定部７２aにより、要求メッセージ８１のデータ仕様に基づいて、発行する「ＤＦＭモジュール２２への提供サービス登録」要求メッセージに応じた「機能名＝DCP2DFM_Register」、「データ個数＝8」、及び「データ＝（InstanceID）、（EPR）・・・（Device Category）」を、プロセス間通信部７３の関数PutMsg()６１aの引数に設定した後、関数PutMsg６１aをコールする（ステップＳ５０１）。

送信側のＩＭＣ５１は、送信部７４により、引数の値に基づいて発行された要求メッセージ８１を受信側のＩＭＣ５１へ送信し（ステップＳ５０２）、送信が完了した旨を送信側の機能部７２に返す（ステップＳ５０３）。

受信側のＩＭＣ５１は、受信部７５により、送信側から送信された要求メッセージ８１を受信し、手続き登録部７６に登録されたコールバック関数６４を、受信した要求メッセージ８１を引数に、登録手続き実行部７７によりコールバックし、受信側の機能部７１に実行制御を移行する（ステップＳ５０４）。

実行制御が移行した受信側の機能部７１では、コールバック関数６４がコールされたことで、内容解釈部７１bが機能し、要求メッセージ８１を解釈し、解釈して得た「機能名」から、「ＤＦＭモジュール２２への提供サービス登録」要求に対応する処理を特定（メッセージをディスパッチ処理）する（ステップＳ５０５）。次いで、特定した（ディスパッチした）ＤＣＰ登録処理を実行する（ステップＳ５０６）。

受信側のＤＦＭモジュール２２は、内容解釈部７１bにより対応処理が終了すると、クライアント端末などの外部機器に対して、自動検知コマンド「Hello」をＵＤＰによりマルチキャストし（ステップＳ５０７）、更に、処理が終了した旨を受信側のＩＭＣ５１へ返す（ステップＳ５０８）。

図１１は、本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群２０のデータ処理機能の処理手順の一例（その２）を示すシーケンス図である。図１１では、送信側のＷＳ−Ｐｒｉｎｔｅｒ２１pからの要求に対して受信側のＤＦＭモジュール２２が応答する場合の処理手順について説明する。

図９と図８で異なる処理手順は、送信側の機能部７２が要求メッセージ８１を受信側の機能部７１へ送信するステップＳ３０１以降の処理である。よって、図９に示すステップＳ３０１より前の処理手順については、図８をもって説明を省略する。

送信側のＷＳ−Ｐｒｉｎｔｅｒ２１pは、メッセージ設定部７２aにより、要求メッセージ８１のデータ仕様に基づいて、発行する「ＩＰアドレスの取得」要求メッセージに応じた「機能名＝DCP2DFM_SetMetadata」、「データ個数＝5」、及び「データ＝（InstanceID）、（Dialect）・・・（Metadata）」を、プロセス間通信部７３の関数PutMsg()６１aの引数に設定した後、関数PutMsg６１aをコールする（ステップＳ６０１）。

送信側のＩＭＣ５１は、送信部７４により、引数の値に基づいて発行された要求メッセージ８１を受信側のＩＭＣ５１へ送信する（ステップＳ６０２）。

受信側のＩＭＣ５１は、受信部７５により、送信側から送信された要求メッセージ８１を受信し、手続き登録部７６に登録されたコールバック関数６４を、受信した要求メッセージ８１を引数に、登録手続き実行部７７によりコールバックし、受信側の機能部７１に実行制御を移行する（ステップＳ６０３）。

実行制御が移行した受信側の機能部７１では、コールバック関数６４がコールされたことで、内容解釈部７１bが機能し、要求メッセージ８１を解釈し、解釈して得た「機能名」から、「ＩＰアドレスの取得」要求に対応する処理を特定（メッセージをディスパッチ処理）する（ステップＳ６０４）。次いで、特定した（ディスパッチした）ＩＰアドレス取得処理を実行する（ステップＳ６０５）。

受信側のＤＦＭモジュール２２は、内容解釈部７１bにより対応処理が終了すると、コールバック関数６４の戻り値（ＩＰアドレス）を受信側のＩＭＣ５１へ返す（ステップＳ６０６）。

受信側のプロセス間通信部７３は、処理結果である戻り値を基に応答メッセージの有無を判定し（ステップＳ６０７）、判定結果から応答が必要と判断された場合に、送信部６４により処理結果を基に発行された応答メッセージを送信側の機能部７１へ送信する（ステップＳ６０８）。

送信側のＩＭＣ５１は、受信部７５により受信した応答メッセージを、受信側の機能部７１へ転送する（ステップＳ６０９）。

＜まとめ＞
以上のように、本発明の第１の実施形態によれば、本実施形態に係る画像形成装置１００は、プロセス間通信部７３と送受信側の機能部７１及び７２とを別のモジュールで構成し、所定の処理を要求する要求メッセージ８１に応じて、画像形成装置１００で実行可能な処理の中から、要求メッセージ８１により要求される処理を特定し処理を実行するコールバック関数６４を受信側の機能部７１が有し、この関数６４を、予め受信側のプロセス間通信部７３に登録しておき、受信側のプロセス間通信部７３により要求メッセージ８１を受信すると、登録されている関数６４をコールバックする。

これによって、本実施形態に係る画像形成装置１００は、プロセス間通信を行うときの送受信側の処理内容や通信目的などの取り決めに依存する処理が、受信側の機能に統合され、プロセス間通信部７３に、送受信側の取り決めに依存するプログラムコードやデータが含まれることがないため、画像形成装置１００内のデータ処理において、プロセス間通信部７３の独立性が高く、送受信側の機能を容易に拡張することができる「データ処理機能」を提供することができる。

ここまで、上記第１の実施形態に基づき本発明の説明を行ってきたが、本発明の実施形態に係る画像形成装置１００が有する「データ処理機能」は、図８〜１１に示した処理手順を含む本実施形態に係るデータ処理プログラムを、画像形成装置１００が有するコントローラ１３に配置されたＣＰＵ１３cで実行することで実現することができる。よって、本発明の各実施形態に係る画像形成装置１００が有するデータ処理プログラムは、画像形成装置１００が読み取り可能な記憶媒体１２bに格納することができる。

各実施形態に係るデータ処理プログラムは、フロッピー（登録商標）ディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）などの記録媒体１２bに記憶させることによって、これらの記憶媒体１２bを読み取り可能なドライブ装置１２aを有する記憶メディアＩ／Ｆ１２を介して、記録媒体１２bから画像形成装置１００にインストールすることができる。また、画像形成装置１００は、インタフェース装置１４aを有するデータ通信Ｉ／Ｆ１４を備えていることから、インターネットなどの電気通信回線を用いてデータ通信プログラムをダウンロードし、インストールすることも可能である。

最後に、上記実施形態に挙げた形状に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

本発明の第１の実施形態に係る画像形成装置のハードウェア構成の一例を示す図である。 本発明の第１の実施形態に係る画像形成装置のソフトウェア構成の一例を示す図である。 本発明の第１の実施形態に係るＮＣＳのソフトウェア構成の一例を示す図である。 本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群内部のプロセス間通信の構成の一例を示す図である。 本発明の第１の実施形態に係るＩＭＣのソフトウェア構成の一例を示す図である。 本発明の第１の実施形態に係る画像形成装置内のデータ処理機能の機能構成の一例を示す図である。 本発明の第１の実施形態に係る要求メッセージのデータ仕様の一例を示す図である。 本発明の第１の実施形態に係る画像形成装置内のデータ処理機能の基本処理手順の一例（その１）を示すシーケンス図である。 本発明の第１の実施形態に係る画像形成装置内のデータ処理機能の基本処理手順の一例（その２）を示すシーケンス図である。 本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群のデータ処理機能の処理手順の一例（その１）を示すシーケンス図である。 本発明の第１の実施形態に係るＷＳ−ＭＦＰモジュール群のデータ処理機能の処理手順の一例（その２）を示すシーケンス図である。

符号の説明

１１ 操作パネル
１１a 入力装置
１１b 表示装置
１２ 記憶メディアＩ／Ｆ
１２a ドライブ装置
１２b 記録媒体
１３ コントローラ
１３a ＲＯＭ
１３b ＲＡＭ
１３c ＣＰＵ
１４ データ通信Ｉ／Ｆ
１４a インタフェース装置
１５ スキャナ
１５a 画像読取装置
１６ プロッタ
１６a 印刷装置
１７ ＨＤＤ
２０ ＷＳ−ＭＦＰモジュール群
２１p ＷＳ−Ｐｒｉｎｔｅｒ
２１s ＷＳ−Ｓｃａｎｎｅｒ
２２ ＤＦＭモジュール
３１ ＷＳ−Ｄｉｓｃｏｖｅｒｙ
３２ ＷＳ−Ｔｒａｎｓｆｅｒ
３３ ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ
３４ ＷＳＤ−Ｍａｎａｇｅｒ
４１p ＰｒｉｎｔｅｒＤＣＰ
４１s ＳｃａｎｎｎｅｒＤＣＰ
４２ ＷＳ−Ｅｖｅｎｔｉｎｇ
５１ ＩＭＣ
６１ ＩＭＣＩ／Ｆレイヤ
６２ ＡＰＩ内部処理レイヤ
６３ 送受信処理実行レイヤ
６４ コールバック関数（格納先情報から呼び出されるソフトウェア部品）
７１ 受信側の機能部（例えばＤＦＭモジュール）
７１a 初期化部
７１b 内容解釈部（ディスパッチャ）
７２ 送信側の機能部（例えばＷＳ−ＰｒｉｎｔｅｒやＷＳ−Ｓｃａｎｎｅｒなど）
７２a 機能Ａ（例えばＷＳ−Ｐｒｉｎｔｅｒ）
７２b 機能Ｂ（例えばＷＳ−Ｓｃａｎｎｅｒ）
７２m メッセージ設定部
７３ プロセス間通信部（例えばＩＭＣ）
７４ 送信部
７５ 受信部
７６ 手続き登録部
７７ 登録手続き実行部
８１ 要求メッセージ
１００ 画像形成装置
１０１ ハードウェアリソース
１０２ エンジンＩ／Ｆ
１０３ ＡＰＩ
１１０ ソフトウェア群
１１１ プリンタアプリ
１１２ コピーアプリ
１１３ ファクスアプリ
１１４ スキャナアプリ
１１５ ネットファイルアプリ
１１６ 工程検査アプリ
１１７ 配信アプリ
１２０ プラットフォーム
１２１ ＯＳ
１２２ ＳＣＳ
１２３ ＳＲＭ
１２４ ＥＣＳ
１２５ ＭＣＳ
１２６ ＯＣＳ
１２７ ＦＣＳ
１２８ ＮＣＳ
１２９ ＩＭＨ
１３０ アプリケーション
１４０ 起動部
１５０ コントロールサービス

Claims (9)

1. 第１の機能が動作する第１のプロセスと、前記第１のプロセスから所定の処理の実行が要求される第２の機能が動作する第２のプロセスとを有する画像形成装置であって、
   前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手段と、
   前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段と、
   前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて実行される前記ソフトウェア部品により特定された、前記要求メッセージにより要求される処理を前記第２のプロセスで実行する実行手段と、を有し、
   受信側の前記通信制御手段は、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、
   送信側の前記通信制御手段は、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、
   受信側の前記通信制御手段は、前記第１のプロセスから前記要求メッセージを受信すると、前記要求メッセージにより要求される処理の実行を前記実行手段に指示することを特徴とする画像形成装置。
2. 前記通信制御手段は、
   前記要求メッセージにより要求され、前記第２のプロセスで実行された前記所定の処理の実行結果に基づいて、要求に対応する応答メッセージを、前記第１のプロセスに送信することを特徴とする請求項１に記載の画像形成装置。
3. 前記通信制御手段は、
   前記要求メッセージの送信を指示する送信指示手段と、
   前記要求メッセージの送信と要求に応じた前記応答メッセージの受信待ちを指示する応答受信指示手段と、
   前記要求メッセージの受信待ちを指示する要求待ち指示手段と、
   前記ソフトウェア部品の格納先情報の設定を指示する格納先情報設定指示手段とを有することを特徴とする請求項２に記載の画像形成装置。
4. 前記要求メッセージは、
   前記要求メッセージにより実行される処理を示す機能名と、
   前記処理を行うときに用いるパラメータ値と、
   前記パラメータ値の数を示すパラメータ数とから構成されることを特徴とする請求項１ないし３のいずれか一項に記載の画像形成装置。
5. 前記ソフトウェア部品は、
   前記第２のプロセスで受信された前記要求メッセージの前記機能名に基づいて、前記要求メッセージにより要求される処理を特定することを特徴とする請求項１ないし４のいずれか一項に記載の画像形成装置。
6. 前記実行手段は、
   前記第２のプロセスで受信された前記要求メッセージの前記パラメータ値に基づいて、前記ソフトウェア部品により特定された、前記要求メッセージにより要求される処理を行うことを特徴とする請求項１ないし５のいずれか一項に記載の画像形成装置。
7. 当該画像形成装置は、
   前記第２のプロセスで受信された前記要求メッセージの前記パラメータ値の数が、前記要求メッセージの前記パラメータ数と一致するか否かを判定し、受信された前記要求メッセージのデータを検証するデータ検証手段を有することを特徴とする請求項１ないし６のいずれか一項に記載の画像形成装置。
8. 第１の機能が動作する第１のプロセスと、前記第１のプロセスから所定の処理の実行が要求される第２の機能が動作する第２のプロセスと、前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段とを有する画像形成装置内のデータ処理方法であって、
   前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手順と、
   前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて前記ソフトウェア部品を実行し、前記ソフトウェア部品の実行により、前記要求メッセージにより要求される処理を特定し、特定された前記処理を前記第２のプロセスで実行する実行手順と、を有し、
   受信側の前記通信制御手順により、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、
   送信側の前記通信制御手順により、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、
   受信側の前記通信制御手順により、前記第１のプロセスから前記要求メッセージを受信すると、前記実行手順を実行し、
   前記実行手順により、前記要求メッセージにより要求される処理を実行することを特徴とする画像形成装置内のデータ処理方法。
9. 第１の機能が動作する第１のプロセスと、前記第１のプロセスに対して所定の処理を要求する第２の機能が動作する第２のプロセスと、前記第１のプロセスから送信された、前記所定の処理を要求する要求メッセージに応じて、当該画像形成装置で実行可能な処理の中から、前記要求メッセージにより要求される処理を特定するソフトウェア部品の格納先情報を保持している保持手段とを有する画像形成装置内のデータ処理プログラムであって、
   コンピュータを、
   前記第１の機能及び前記第２の機能に共通する通信制御用インタフェースを備え、プロセス間においてデータの送受信を行う通信制御手段と、
   前記第１のプロセスから送信された前記要求メッセージを、前記第２のプロセスで受信したときに、前記保持手段により保持された前記格納先情報に基づいて前記ソフトウェア部品を実行し、前記ソフトウェア部品の実行により、前記要求メッセージにより要求される処理を特定し、特定された前記処理を前記第２のプロセスで実行する実行手段として機能させ、
   受信側の前記通信制御手段が、前記第２のプロセスからの指示に従って、前記ソフトウェア部品の格納先情報を前記保持手段に登録し、前記第１のプロセスから送信される前記要求メッセージの受信待ちを開始し、
   送信側の前記通信制御手段が、前記第１のプロセスからの指示に従って、前記第２のプロセスに前記要求メッセージを送信し、
   受信側の前記通信制御手段が、前記第１のプロセスから前記要求メッセージを受信すると、前記要求メッセージにより要求される処理の実行を前記実行手段に指示するように動作させる画像形成装置内のデータ処理プログラム。

Images