(57)【要約】【課題】  コンピュータシステムで分散処理を行う場合に、分散処理の対象とする処理ノードを適切に選択する。【解決手段】  ジョブの分散処理を依頼する管理ノード５０１と、依頼された分散処理を実行して管理ノードに処理結果を送信する処理ノード５０２ａ〜ｄとを含む、ネットワークを介して接続された複数のコンピュータ装置間で、負荷分散処理を行う際に、管理ノードは、各処理ノードにテスト処理を依頼し（１）、各処理ノードから処理結果を受信し（２）、受信したテスト処理の処理結果に応じてデータベース５０３の状態情報を更新し（３）、状態情報を参照して分散処理の対象とする処理ノードを選択する（４）。【選択図】  図５
2006344068.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムであって、
前記複数の情報処理装置が、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して前記管理ノードに処理結果を送信する処理ノードとを含み、
前記管理ノードは、各処理ノードに依頼したテスト処理の処理結果に基づいて分散処理の対象とする処理ノードを選択することを特徴とする情報処理システム。
【請求項２】
各処理ノードについて前記テスト処理の処理結果に関する状態情報を格納する処理ノード状態データベースを更に備えており、
前記管理ノードは、前記テスト処理の処理結果に応じて前記状態情報を更新し、ジョブの分散処理を依頼する際に、前記状態情報を参照して前記分散処理の対象とする処理ノードを選択することを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記テスト処理について基準となる処理結果が既知であり、前記状態情報は、前記テスト処理の処理結果が前記基準となる処理結果と同一であるか否かに対応した情報であることを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記管理ノードは、前記テスト処理の処理結果が前記基準となる処理結果と同一である処理ノードを前記分散処理の対象として選択することを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記テスト処理についての処理結果が未知であり、前記状態情報は、前記テスト処理の処理結果が同一となったグループを識別可能な情報であることを特徴とする請求項２に記載の情報処理システム。
【請求項６】
前記管理ノードは、前記テスト処理の処理結果が同一となった処理ノードのグループのうち、最も処理ノードの数が多いグループを前記分散処理の対象として選択することを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記管理ノードは、前記テスト処理の処理結果が前記管理ノードでの前記テスト処理の処理結果と同一となった処理ノードのグループを前記分散処理の対象として選択することを特徴とする請求項５に記載の情報処理システム。
【請求項８】
前記処理ノード状態データベースは、分散処理の対象となるジョブの種類に対応した複数のテスト処理の結果に関する状態情報を格納することを特徴とする請求項２から７のいずれか１項に記載の情報処理システム。
【請求項９】
各処理ノードで前記テスト処理が実行されていない場合、その旨を示す情報が前記状態情報として格納され、
前記管理ノードは、前記テスト処理が実行されていない処理ノードに対して前記分散処理を依頼する前に前記テスト処理を依頼して前期状態情報を更新することを特徴とする請求項２から８のいずれか１項に記載の情報処理システム。
【請求項１０】
前記管理ノードは、所定期間毎に前記テスト処理を各処理ノードに依頼して、前記状態情報を更新することを特徴とする請求項２から９のいずれか１項に記載の情報処理システム。
【請求項１１】
前記管理ノードは、各処理ノードにジョブを分散して依頼する際に、前記テスト処理を含めて各処理ノードに処理を依頼し、
受信した処理結果に含まれる前記テスト処理の処理結果に基づいて、受信した処理結果を採用するか否かを決定し、
処理結果を採用しないと決定された処理ノードに依頼した処理を、処理結果を採用すると決定した処理ノードに再度依頼することを特徴とする請求項１に記載の情報処理システム。
【請求項１２】
ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して前記管理ノードに処理結果を送信する処理ノードとを含み、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムのジョブの割り当て方法であって、
前記管理ノードから各処理ノードにテスト処理を依頼する工程と、
各処理ノードから受信した前記テスト処理の処理結果を分類する工程と、
前記分類の結果に基づいて分散処理の対象とする処理ノードを選択する工程と、を備えることを特徴とする情報処理システムのジョブ割り当て方法。
【請求項１３】
ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムにおけるジョブの分散処理を依頼する情報処理装置であって、
依頼された分散処理を実行して処理結果を送信する処理ノードに対して、ジョブの分散処理を依頼する依頼手段と、
前記処理ノードから送信されるテスト処理の結果に基づいて分散処理の対象とする処理ノードを選択する選択手段と、を有することを特徴とする情報処理装置。
【請求項１４】
ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムにおけるジョブの分散処理を依頼する情報処理方法であって、
依頼された分散処理を実行して処理結果を送信する処理ノードに対して、ジョブの分散処理を依頼する依頼工程と、
前記処理ノードから送信されるテスト処理の結果に基づいて分散処理の対象とする処理ノードを選択する選択工程と、を有することを特徴とする情報処理方法。
【請求項１５】
請求項１４に記載の情報処理方法を情報処理装置によって実現すべく、各工程に対応したプログラムコードを備えるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、及び該システムにおけるジョブの割り当て方法に関し、より詳細には、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して管理ノードに処理結果を送信する処理ノードとを含み、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムのジョブの割り当てに関するものである。
【背景技術】
【０００２】
近年、ネットワークで接続された複数のコンピュータを一つのシステムのように利用可能とする、グリッドコンピューティング（Grid computing：以下、単に「グリッド」とも称する）が注目されており、様々な分野への適用が試みられている。
【０００３】
図１は、グリッドコンピューティングのアーキテクチャを説明する図である。グリッドには数種類あるが、ここで説明するのはデスクトップグリッドと呼ばれる、デスクトップＰＣなどのＣＰＵの空き時間を利用してジョブを実行するタイプのものである。
【０００４】
図１においてクライアント（Client）１０は、ユーザが要求としてジョブを投入する機器であり、投入されたジョブはタスクマネージャ（Task Manager：以下、ＴＭと略す）２０に渡され、ＴＭ２０はダイナミックジョブスケジューラ（Dynamic Job Scheduler：以下、ＤＪＳと略す）３０にその内容を伝える。
【０００５】
ＤＪＳ３０は、それぞれがブローカ（Broker）４１１とリソースマネージャ（Resource Manager：以下、ＲＭと略す）４１２とを含みリソースとして認識される、複数のホスト機器４１〜４３全体のリソース管理をしており、ジョブを分析して最適なリソースのブローカ４１１を選択してＴＭ２０に通知する。なお、ここでリソースとは利用可能なＣＰＵの空き状態のことを言っている。
【０００６】
ブローカ４１１は、ＲＭ４１２が取得したリソースの情報をＤＪＳ３０に登録し、ＴＭ２０からの要求に応じて最適なリソースにジョブを投入し、ジョブが終了したときにＴＭ２０にジョブの完了を通知する。
【０００７】
ＴＭ２０は、ＤＪＳ３０が選択した最適なブローカ４１１にジョブを投入し、以後そのジョブの進行状況をモニタリングし、完了通知をブローカ４１１から受信するとクライアント１０にその結果を通知する。またリソースに変化や異常が発生したとき（例えば、故障や他のジョブを受け付けた等）、ＲＭ４１２はブローカ４１１に通知する。
【０００８】
このような仕組みで、通常は利用されていないＣＰＵなどのリソースにジョブを配分し、ユーザが意識することなしに複数の機器での分散処理を可能にすることで、デスクトップグリッドコンピューティングが実現されている。
【０００９】
続いてこの技術を画像処理装置のＰＤＬ処理に適用した場合の構成の説明を図２にて行う。図１の説明ではグリッドを構成するそれぞれのモジュールが別個のものとして扱われたが、印刷装置に適用する場合、複数のモジュールが１つの機器の中に存在することが一般的になる。
【００１０】
図２は、グリッドコンピューティングをプリンタのＰＤＬ処理（ページ記述言語のラスターイメージへの展開処理）に適用する場合の構成を示す図である。図１に示した例ではグリッドを構成するそれぞれのモジュールが別個のものとして扱われたが、複合機（ＭＦＰ）やプリンタ等の画像形成装置に適用する場合、複数のモジュールが１つの機器の中に存在する構成が一般的である。
【００１１】
図２の構成では、ユーザは印刷指示等のジョブをクライアントＰＣ１１０から投入し、投入されたジョブはＴＭ及びＤＪＳ機能を有するプリンタ等の画像形成装置１２０によって分析され、それぞれがブローカ及びＲＭを有するＰＣ１（１４１）、ＰＣ２（１４２）、ＰＣ３（１４３）の３台のＰＣのリソースを用いてグリッドコンピューティングによる分散処理が行なわれる。
【００１２】
すなわち、図示した構成では、画像形成装置１２０が、グリッドコンピューティングにおけるホストとしての機能も有している。もちろん、画像形成装置１２０以外の他のＰＣがホストとしての機能を有していてもよい。
【００１３】
クライアントＰＣ１１０からＰＤＬの印刷ジョブが投入されると、ジョブは画像形成装置１２０のＴＭ及びＤＪＳを経由して１４１〜１４３の各ＰＣのリソースに適宜分散される。またこの時、ＰＤＬのイメージ展開処理用のアプリケーションプログラムも同時に画像形成装置１２０から各ＰＣに送信されるようにする。
【００１４】
それぞれのＰＣでＰＤＬを展開して形成されたイメージは、画像形成装置１２０によって収集されまとめた状態で最終的に出力される。
【００１５】
なお、この分散処理の対象となるホスト（リソース）の数には特に制限はなく３台以上であってもよいし、ジョブが投入されるクライアントＰＣ１１０のリソースや画像形成装置１２０のリソースを分散処理の対象にしても良い。
【非特許文献１】ＩＢＭプロフェッショナル論文、「グリッド・コンピューティングの商用システムへの適用性」、インターネット、＜ＵＲＬ：http://www-6.ibm.com/jp/provision/no36/pdf/36_ppr1.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上記のようなグリッドコンピューティングの技術を用いてコンピュータのＣＰＵパワーを集め、高速処理を実現する研究が行われているが、この技術の組み込み機器への適用はあまり行われていない。
【００１７】
このようにＣＰＵパワーを集めて分散処理を行う場合、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理のデータを受信して処理を施し、結果を返信する１台以上の処理ノードとからシステムが構成される。
【００１８】
通常は、複数の処理ノードで得られる処理結果は全て正しいことを前提にシステムが構築されている。組み込み機器でないＰＣ等のコンピュータリソースを用いる場合は、ＣＰＵやＯＳが同等である場合が多いため、どの処理ノードから得られる処理結果も同等となることが多い。
【００１９】
しかしながら、組み込み機器として、例えばＭＦＰのリソース（例えばＣＰＵパワーや画像処理用ＡＳＩＣ）を利用した分散処理システムにおいては、様々な種類のＭＦＰが混在した環境が想定され、機種毎に使用されているＣＰＵや画像処理ＡＳＩＣなどのハードウエアリソースが異なる場合が考えられる。
【００２０】
また、ハードウエアリソースに限らず、ソフトウェアについても、数値演算ライブラリや画像処理演算モジュールなどのバージョンが異なる場合が考えられる。
【００２１】
上述したように様々な種類の複数のＭＦＰを用いて分散処理を行う場合、処理ノードによって、処理結果が異なることが起こりうるため、分散処理結果の信頼性が低下するという問題が生じる。
【００２２】
例えば、ＰＤＬ処理を分散処理する場合を考える。ページ毎、オブジェクト毎に処理を分割して依頼した時に、色処理の解像度などが他の処理ノードと異なる処理ノードが存在すると、該処理ノードが処理したページだけ色味が違ってしまったり、ページ内の該処理ノードが処理したオブジェクトだけが他のオブジェクトと異なる色味になってしまう場合が生じ、処理結果の画質が低下してしまい、分散処理システムの信頼性が低下してしまう。
【００２３】
また、機種やソフトウェア、ハードウェアのバージョンが違っていても、共通のプラットフォームで設計されている場合があり、機種が異なっても同等な処理結果が得られるケースや、分散処理したい処理に関しては、処理結果に影響を与えない程度の違いであるケースも考えられるため、単純に機種名やソフトウェア、ハードウェアのバージョンに基づいて、処理結果が異なるかどうかを判断することは困難である。そのため、これらの情報に基づいて分散処理の依頼先の処理ノードを選択すると、分散処理の対象となる処理ノードの数が少なくなり、分散処理システムとしての効率が悪くなるという別の問題が生じる。
【００２４】
また、コンピュータのＣＰＵパワーを利用した分散処理システムにおいても、各処理ノードのうち、情報の改竄やデータの劣化が行われる処理ノードがあると、分散処理システムの信頼性が低下するという問題が生じる。
【００２５】
本発明は以上のような状況に鑑みてなされたものであり、情報処理システムで分散処理を行う場合に、分散処理の対象とする処理ノードを適切に選択して分散処理システムの信頼性並びに効率を向上させることを目的とする。
【課題を解決するための手段】
【００２６】
上記目的を達成する本発明の一態様としての情報処理システムは、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムであって、
前記複数の情報処理装置が、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して前記管理ノードに処理結果を送信する処理ノードとを含み、
前記管理ノードは、各処理ノードに依頼したテスト処理の処理結果に基づいて分散処理の対象とする処理ノードを選択することを特徴とする。
【００２７】
すなわち、本発明では、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して管理ノードに処理結果を送信する処理ノードとを含み、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムにおいて、管理ノードが、各処理ノードに依頼したテスト処理の処理結果に基づいて分散処理の対象とする処理ノードを選択する。
【００２８】
このようにすると、テスト処理の処理結果から、所望する結果が得られる処理ノードとそうでない処理ノードとを識別することが可能となり、所望する結果が得られる処理ノードのグループを選択して分散処理を依頼することができる。
【００２９】
従って、分散処理の対象とする処理ノードが適切に選択されるので、所望する結果が得られない処理ノードに分散処理を依頼することが防止され、分散処理システムの信頼性並びに効率を向上させることができる。
【００３０】
なお、各処理ノードについてテスト処理の処理結果に関する状態情報を格納する処理ノード状態データベースを更に備え、管理ノードが、テスト処理の処理結果に応じて状態情報を更新し、ジョブの分散処理を依頼する際に、状態情報を参照して分散処理の対象とする処理ノードを選択してもよい。
【００３１】
この場合、テスト処理としては処理結果が既知であっても未知であってもよい。
【００３２】
テスト結果が既知である場合には、基準となる処理結果と同一であるか否かに対応した情報が状態情報として格納され、管理ノードはテスト処理の処理結果が基準となる処理結果と同一の処理ノードを分散処理の対象として選択するのがよい。
【００３３】
一方、テスト処理の処理結果が未知である場合には、テスト処理の処理結果が同一となったグループを識別可能な情報が状態情報として格納され、管理ノードは、処理ノードの数が多いグループ、あるいはテスト処理の処理結果が管理ノードでのテスト処理の処理結果と同一となったグループを分散処理の対象として選択するのがよい。
【００３４】
上記目的を達成する本発明の別の態様としての情報処理システムにおけるジョブの割り当て方法は、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して前記管理ノードに処理結果を送信する処理ノードとを含み、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムのジョブの割り当て方法であって、
前記管理ノードから各処理ノードにテスト処理を依頼する工程と、
各処理ノードから受信した前記テスト処理の処理結果を分類する工程と、
前記分類の結果に基づいて分散処理の対象とする処理ノードを選択する工程と、を備えている。
【００３５】
上記目的を達成する本発明の更に別の態様としての情報処理装置は、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムにおけるジョブの分散処理を依頼する情報処理装置であって、
依頼された分散処理を実行して処理結果を送信する処理ノードに対して、ジョブの分散処理を依頼する依頼手段と、
前記処理ノードから送信されるテスト処理の結果に基づいて分散処理の対象とする処理ノードを選択する選択手段と、を有する。
【００３６】
また、上記の目的は上記の情報処理システムにおけるジョブの割り当て方法を情報処理装置によって実行させるコンピュータプログラム、該プログラムを記憶する記憶媒体によっても達成される。
【発明の効果】
【００３７】
本発明によれば、テスト処理の処理結果から、所望する結果が得られる処理ノードとそうでない処理ノードとを識別することが可能となり、所望する結果が得られる処理ノードのグループを選択して分散処理を依頼することができる。
【００３８】
従って、分散処理の対象とする処理ノードが適切に選択されるので、所望する結果が得られない処理ノードに分散処理を依頼することが防止され、分散処理システムの信頼性並びに効率を向上させることができる。
【発明を実施するための最良の形態】
【００３９】
以下に、添付図面を参照して、本発明の好適な実施の形態を例示的に詳しく説明する。ただし、以下の実施形態に記載されている構成要素はあくまで例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００４０】
＜第１の実施の形態＞
第１の実施形態は、複数台の画像処理装置でグリッドコンピューティングシステムを構成するものである。該システムを構成する各画像処理装置は、相互通信可能なインターフェースを介して互いに接続されている。
【００４１】
本実施形態のシステムでは、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノードとして動作し、他の画像処理装置は分散処理を受信して処理を施して結果を返す処理ノードとして動作する。すなわち、管理ノードとして動作する１台の画像処理装置には、ＴＭ及びＤＪＳがインストールされており、分散処理の対象となる処理ノードとして動作する他の画像処理装置には、ブローカ及びＲＭがインストールされている。
【００４２】
（画像形成装置のハード構成）
図３は、本発明に係るグリッドコンピューティング（以下、単に「グリッド」とも称する）を構成する画像処理装置の実施形態としての画像形成装置の一例の外観を示す図である。本実施形態の画像形成装置は、スキャナ機能、複写機能、及び印刷機能を有する複合機（ＭＦＰ）であり、ネットワークプリンタとも呼ばれる。
【００４３】
画像入力デバイスであるスキャナ２０１は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサ（図示せず）を走査することによって、ラスターイメージデータを生成する。
【００４４】
ユーザが、原稿用紙を原稿フィーダ２０４のトレイ２０３にセットして、操作部２０２において読み取り動作の開始を指示すると、画像形成装置のコントローラＣＰＵがスキャナ２０１に指示を与え、フィーダ２０３は原稿用紙を１枚ずつフィードし、スキャナ２０１は原稿画像の読み取り動作を行う。
【００４５】
操作部２０２はコピー動作時の設定指示や状態表示や、各種動作設定の指定をするためのユーザインタフェースであり、タッチパネル型の操作パネルを備えている。
【００４６】
画像出力デバイスであるプリンタエンジン１０３は、ラスターイメージデータを用紙上に印刷する部分である。その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微小ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。なお、プリント動作は、コントローラＣＰＵからの指示によって起動される。
【００４７】
プリンタエンジン１０３は、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセット２０６、２０７、２０８を備えている。また、排紙トレイ２０５は、印字し終わった用紙を受けるものである。
【００４８】
図４は、本実施形態の画像形成装置の制御構成を示すブロック図である。プリンタコントローラ１０２は、画像入力デバイスであるスキャナ２０１や画像出力デバイスであるプリンタエンジン１０３と接続し、一方ではクライアントＩ／Ｆ３０８経由で、クライアントとの間で印刷データや画像情報やデバイス情報の入出力をする。
【００４９】
ＣＰＵ３０１は、システム全体を制御するコントローラである。ＲＡＭ３０２は、ＣＰＵ３０１が動作するために使用するシステムワークメモリである。また、ＲＡＭ３０２は、画像データを一時記憶するための画像メモリでもある。ＲＯＭ３０３は、ブートＲＯＭであり、システムのブートプログラムが格納されている。ＨＤＤ３０４は、ハードディスクドライブで、システムソフトウェア、画像データを格納する。
【００５０】
操作部Ｉ／Ｆ３０６は、操作部（ＵＩ）２０２との間のインターフェースを司り、操作部２０２に表示する画像データを操作部２０２に対して出力する。また、使用者が操作部２０２を介して入力した情報を、ＣＰＵ３０１に伝える役割を果たす。また操作部２０２からの入力された動作モードなどの環境設定情報は不揮発性のメモリであるNVRAM３１６に記憶される。
【００５１】
クライアントＩ／Ｆ３０８は、各クライアントに対して情報の入出力を行う。以上のデバイスがシステムバス３０７上に配置される。
【００５２】
イメージバスインターフェース（Image Bus Ｉ／Ｆ）３０５は、システムバス３０７と画像データを高速で転送する画像バス３０９とを接続し、データ構造を変換するバスブリッジである。
【００５３】
画像バス３０９には以下のデバイスが配置される。ラスターイメージプロセッサ（ＲＩＰ）３１０は、ネットワークから送信されて来たＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部３１１は、画像入出力デバイスであるスキャナ２０１やプリンタエンジン１０３とプリンタコントローラ１０２とを接続し、画像データの同期系／非同期系の変換を行う。
【００５４】
スキャナ画像処理部３１２は、入力画像データに対し補正、加工、編集を行う。プリンタ画像処理部３１３は、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。画像回転部３１４は画像データの回転を行う。画像圧縮部３１５は、多値画像データに対してはＪＰＥＧ圧縮伸張処理を行い、２値画像データに対してはＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理を行う。
【００５５】
以上のような構成の本実施形態の画像形成装置は、クライアントインターフェース（例えば、Ethernet（登録商標）等の相互通信可能なネットワークインターフェース）３０８を介して互いに接続され、グリッドコンピューティングによる負荷分散処理を行なうコンピュータシステムとして動作する。
【００５６】
（処理ノードの選択方法）
第１の実施形態のコンピュータシステムは、以上のような構成の画像処理装置で構成されており、グリッドコンピューティングを利用して負荷分散処理を依頼する管理ノードは、処理ノード状態データベースに予め登録されている他の画像処理装置の情報や状態に基づいて、負荷分散処理の対象とする処理ノードを選択する。
【００５７】
図５は、本実施形態の構成と処理の順序を概略的に示すブロック図である。図中、５０１は管理ノード、５０２ａ〜ｄは４つの処理ノード１〜４をそれぞれ表している。また、５０３は処理ノードデータベース（ＤＢ）であり、５０３ａ及び５０３ｂは、各状態における処理ノード状態データベース５０３に格納された情報の例を表している。
【００５８】
この処理ノード状態ＤＢは、本実施形態ではグリッドを構成する画像処理装置のいずれか１つに設けられているが、別途独立したコンピュータ装置内に設けられていても良い。
【００５９】
本実施形態では、図中（１）〜（４）で示した処理フローに従って、処理ノード状態ＤＢ５０３の情報に基づいた処理ノードの選択処理が実行される。
【００６０】
（１）管理ノード５０１は、処理ノード状態ＤＢ５０３の各処理ノードが使用可能な状態であるか否かの情報（状態情報とも呼ぶ）を管理する。すなわち、ジョブを依頼する前及び処理結果を受信した後に各処理ノードの状態情報を処理ノード状態ＤＢ５０３に書き込む。５０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード５０１ａ〜ｄの状態情報の例を示している。処理ノード１〜４の状態情報は全て「未確認」となっている。
【００６１】
管理ノード５０１は、予め用意してある処理結果が既知のテスト用の処理を、状態情報が「未確認」となっている処理ノード５０１ａ〜ｄそれぞれに依頼する。ここでは通常の分散処理とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。この場合には４つの処理ノード全てにテスト処理を依頼することになる。このテスト処理は、例えば、処理単位となるデータを含むもので、各処理ノードで短時間に処理できる程度のものであり、負荷を増大させるものではない。
【００６２】
該テスト処理に対しては、負荷分散処理の対象とするか否かの判断基準となる処理結果（以下、単に「基準」とも呼ぶ）も用意しておく。例えば、管理ノード５０１で予めテスト処理を実行して得られた結果をこの基準として用いても良い。
【００６３】
（２）各処理ノード５０２ａ〜ｄは、テスト用の処理を受け取ると処理を施し、処理結果を管理ノード５０１に送信する。
【００６４】
（３）管理ノード５０１は、各処理ノードからの処理結果を受信した後、それぞれを基準と比較し、同じ処理結果を返してきた処理ノードの状態情報を「使用可」に、基準と異なる処理結果を返してきた処理ノードの状態情報を「使用不可」となるように、処理ノード状態ＤＢ５０３の内容を更新する。
【００６５】
本例では、処理ノード３から受信した処理結果が基準と異なっており、処理ノード１、２、４から受信した処理結果は基準と同じであると想定する。この場合、処理ノード状態ＤＢ５０３の状態情報を５０３ｂに示すように、処理ノード３の状態情報を「使用不可」に、その他の処理ノードの状態情報を「使用可」に変更する。
【００６６】
（４）管理ノード５０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ５０３を参照し、状態情報が「使用可」となっている処理ノード（５０２ａ、５０２ｂ、５０２ｄ）を選択して、分散処理を依頼する。
【００６７】
具体的な例を挙げて説明する。処理ノード１、２、３は、機種ＡのＭＦＰであり、処理ノード４は、機種ＢのＭＦＰであったとする。依頼する処理の種類は色処理であり、各処理ノードには色処理用のソフトウェアがそれぞれ実装されていることとする。処理ノード３のＭＦＰは機種Ａであるが、導入時期が処理ノード１及び２のＭＦＰに比べ早かったため、色処理ソフトウェアのバージョンがＣであり、処理ノード１、２、４のＭＦＰは、実装されている色処理ソフトウェアのバージョンがＤであったとする。処理ノード４のＭＦＰは、機種Ｂであり、その他の処理ノードと機種が異なる。
【００６８】
このような場合、ＭＦＰの構成としては、ハードウエアリソース、ソフトウエアリソースとも機種だけに依存せず、共通設計（プラットフォーム）として異なる機種にも同じリソースが導入されている場合も多く考えられる。また、機種が同じであっても、マイナーチェンジ等で、ソフトウェアのバージョンが異なる場合があり、ソフトウェアのバージョンＵＰを行っているか否かによっても処理結果が変わってしまう場合もある。あるいは、ソフトウェアやハードウェアのバージョンが違っていても、依頼するジョブの内容によっては処理結果が同じとなる場合も考えられる。このように機種名やソフトウエアリソース、ハードウエアリソースのバージョン等の情報だけでは、処理結果が同じとなるかどうかを判断できないケースが多々考えられる。
【００６９】
本実施形態では、依頼するジョブと同様な処理を含むテスト処理を各処理ノードで実行させ、その処理結果が基準となる処理結果と同じであった処理ノードを選択することにより、処理結果に対する信頼性を向上させている。更に、実際には分散処理の対象としても問題ない処理ノードを、機種名やリソースの情報に基づいて処理対象から除外することが防止されるので、分散処理システムの効率を向上させることが可能となる。
【００７０】
上記の例では、処理ノード３は、使用する色処理のソフトウェアのバージョンが違うために処理結果が他の処理ノードと異なるため、分散処理の対象から除外される。このため、分散処理によって得られる結果の信頼性が向上している。
【００７１】
機種名だけに基づいて分散処理の対象となる処理ノードを選択する場合では、処理ノード４が分散処理の対象から除外されてしまうが、本実施形態ではこのようなことを防ぐことが可能となっている。例えば、３ページある色変換ジョブを分散処理する場合、機種名に基づいて処理ノードを選択すると、処理ノード１〜３に各ページの色変換処理を依頼することとなるが、この場合、処理ノード３によって処理されたページだけ色味が異なってしまう。これに対して本実施形態では、処理ノード３は分散処理の対象から除外され、代わりに処理ノード４が分散処理の対象となるため、３ページとも同じ色味のページとなる。
【００７２】
なお、本実施形態に係るグリッドの構成としては、上述のように管理ノードとなる画像処理装置が所定の１台だけであってもよいし、各画像処理装置が、分散処理を依頼する管理ノードとしても動作可能であり、かつ分散処理を受信して処理を施して結果を返す処理ノードとしても動作可能で、システム全体の状態に応じて動的に管理ノードが切り替わるような構成であってもよい。
【００７３】
また、上記実施形態においては、テスト処理の結果が基準となる処理結果と同じである処理ノードを、分散処理の対象とするが、分散処理を行うジョブの種類や内容（ジョブに含まれる処理）、あるいは分散処理を依頼するユーザによって、基準となる処理結果との同一性をそれほど要求されない場合もある。
【００７４】
このような場合には、例えば、基準となる処理結果との誤差やずれが所定範囲内、あるいは処理結果の精度や仕様が基準となる処理結果以上である処理ノードの状態情報を「使用可」として、分散処理の対象として選択するようにすればよい。
【００７５】
＜第２の実施の形態＞
以下、本発明に係る第２の実施形態について説明する。第２の実施形態も第１の実施形態と同様な複数の画像形成装置で構成されるコンピュータシステムであり、以下では上記第１の実施形態と同様な部分については説明を省略し、第２の実施形態の特徴的な部分を中心に説明する。
【００７６】
本実施形態のシステムでは、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノード及び分散処理を実行する処理ノードとして動作し、他の画像処理装置は分散処理を実行する処理ノードとして動作する。すなわち、管理ノード及び処理ノードとして動作する１台の画像処理装置には、ＴＭ及びＤＪＳ並びにブローカ及びＲＭがインストールされており、処理ノードとして動作する他の画像処理装置には、ブローカ及びＲＭがインストールされている。
【００７７】
図６は、本実施形態の構成と処理の順序を図５と同様に示すブロック図である。図中６０１は、管理ノードであると同時に分散処理の対象となる処理ノードも兼ね、処理ノード５とも呼ばれる。６０２ａ〜ｄは、処理ノード１、２、３、４をそれぞれを表している。６０３は処理ノードデータベース（ＤＢ）であり、６０３ａ及び６０３ｂは、各状態における処理ノード状態データベース６０３に格納された情報の例を表している。
【００７８】
第１の実施形態と本実施形態とで大きく異なる点としては、本実施形態では、各処理ノードに実行させるテスト用の処理として、結果が未知である処理を用い、各処理ノードから受信した処理結果の比較に基づいて、分散処理の対象とする処理ノードを選択する点である。
【００７９】
本実施形態では、図中（１）〜（４）で示した処理フローに従って、処理ノード状態ＤＢ６０３の情報に基づいた処理ノードの選択処理が実行される。
【００８０】
（１）管理ノード６０１は、処理ノード状態ＤＢ６０３の各処理ノードの状態情報を管理する。すなわち、ジョブを依頼する前及び処理結果を受信した後に、各処理ノードの状態情報を書き込む。６０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード１〜５の状態情報の例を示している。処理ノード１〜５の状態情報は全て「未確認」となっている。
【００８１】
管理ノード６０１は、予め用意してある処理結果が未知のテスト用の処理を、状態情報が「未確認」となっている処理ノード１〜５のそれぞれに依頼する。ここでは通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。本実施形態では管理ノード６０１自体も処理ノードを兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理を依頼することになる。
【００８２】
（２）各処理ノード１〜５は、テスト用の処理を受け取ると処理を施し、処理結果を該管理ノード６０１に送信する。
【００８３】
（３）管理ノード６０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ６０３の状態情報に書き込む。
【００８４】
本例では、処理ノード１、２、４から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３および４から受信した処理結果が同じ（第２の処理結果）であると想定する。この場合、処理ノード１、２、４の状態情報として「処理Ａ」を、処理ノード３及び５の状態情報として「処理Ｂ」を書き込んで処理ノード状態ＤＢを更新する。
【００８５】
（４）管理ノード６０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ６０３を参照し、同じ処理結果となった処理ノードの数が多いグループを分散処理の対象として選択し、投入されたジョブの分散処理を依頼する。
【００８６】
本例では、６０３ｂに示すように、状態情報が「処理Ａ」の処理ノードが３台、状態情報が「処理Ｂ」の処理ノードが２台である。よって、本例では、状態情報が「処理Ａ」の処理ノード１、２、４を分散処理の対象として選択し、分散処理を依頼することになる。ここで、処理ノード５はジョブを投入する管理ノード６０１自身でもあるが、この状態情報は「処理Ｂ」であるため、分散処理の対象として選択されない。これは分散処理の対象となる処理ノードの数が多いグループを選択することにより、分散処理の効率を向上させるためである。
【００８７】
ただし、管理ノード６０１自身も処理を行う方が都合のよいケースも考えられるため、単純に処理ノードの数が多いグループを選択するだけではなく、例えば、処理の内容に応じて、管理ノードと状態情報が同じ処理ノードのグループを分散処理の対象として選択するようにしてもよい。ここで重要なのは、処理結果が同じとなる処理ノードを分散処理の対象として選択するということである。
【００８８】
以上説明したように本実施形態によれば、結果が未知のテスト用の処理を各処理ノードに実行させ、同じ処理結果となった処理ノードが識別できるように処理ノード状態ＤＢに状態情報を書き込み、分散処理の対象としてテスト処理の結果が同じであった処理ノードのグループを選択することで、分散処理システムの信頼性並びに効率を向上させることができる。
【００８９】
＜第３の実施の形態＞
以下、本発明に係る第３の実施形態について説明する。第３の実施形態も第１及び第２の実施形態と同様な複数の画像形成装置で構成されるコンピュータシステムであり、以下では上記第１及び第２の実施形態と同様な部分については説明を省略し、第３の実施形態の特徴的な部分を中心に説明する。
【００９０】
本実施形態のシステムも第２の実施形態と同様に、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノード及び分散処理を実行する処理ノードとして動作し、他の画像処理装置は分散処理を実行する処理ノードとして動作する。
【００９１】
図７は、本実施形態の構成と処理の順序を図５及び図６と同様に示すブロック図である。図中７０１は、管理ノードであると同時に分散処理の対象となる処理ノードも兼ね、処理ノード５とも呼ばれる。７０２ａ〜ｄは、処理ノード１、２、３、４をそれぞれを表している。７０３は処理ノードデータベース（ＤＢ）であり、７０３ａ、７０３ｂ及び７０３ｃは、各状態における処理ノード状態データベース６０３に格納された情報の例を表している。
【００９２】
第１及び第２の実施形態と異なる特徴としては、処理ノード状態ＤＢ７０３が、状態情報として処理の種類に対応した複数の状態情報を格納している点である。以下の説明では、２つの状態情報を有する場合を例にあげて説明するが、状態情報の数は２つ以上であっても構わないし、後から、状態情報を追加するようにしてもよい。
【００９３】
本実施形態で用いるテスト用の処理としては、第１の実施形態のように処理結果が既知であってもよいし、第２の実施形態のように処理結果が未知であっても構わないが、以下の説明では、処理結果が未知である場合を例として説明する。
【００９４】
本実施形態では、図中（１）〜（７）で示した処理フローに従って、処理ノード状態ＤＢ７０３の情報に基づいた処理ノードの選択処理が実行される。
【００９５】
（１）管理ノード７０１は、処理ノード状態ＤＢ７０３の各処理ノードの状態情報をジョブの種類毎に管理する。すなわち、分散処理を行うジョブの種類が複数ある場合、各種類に対応したテスト処理を各処理ノードに実行させ、夫々のテスト処理の結果に基づいて状態情報を書き込む。以下の例では、処理ノード状態ＤＢ７０３が、ＰＤＬ用の色処理に対応したテスト処理である処理１と、コピー用の画像処理に対応したテスト処理である処理２とに対応した２種類の状態情報を有する場合について説明する。
【００９６】
７０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード１〜５の状態情報の例を示している。処理ノード１〜５の状態情報は処理１及び処理２の両方について全て「未確認」となっている。
【００９７】
管理ノード７０１は、予め用意してある処理結果が未知のテスト用の処理１を、対応する状態情報が「未確認」となっている処理ノード１〜５のそれぞれに依頼する。ここでは通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理１は全て同一の処理である。本実施形態では管理ノード７０１自体も処理ノードを兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理を依頼することになる。
【００９８】
（２）各処理ノード１〜５は、テスト用の処理１を受け取ると処理を施し、処理結果を管理ノード７０１に送信する。
【００９９】
（３）管理ノード７０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理１の処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ７０３の処理１に対応した状態１の欄の状態情報に書き込む。
【０１００】
本例では、処理ノード１、２、４から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３および４から受信した処理結果が同じ（第２の処理結果）であると想定する。この場合、処理ノード１、２、４の状態１の状態情報として「処理Ａ」を、処理ノード３及び５の状態１の状態情報として「処理Ｂ」を書き込んで処理ノード状態ＤＢを更新する。このようにして状態１の欄が更新された状態を７０３ｂに示す。
【０１０１】
（４）次に、管理ノード７０１は、状態２の状態情報の欄が「未確認」となっている処理ノードに対して、予め用意してある処理結果が未知のテスト用の処理２を処理ノード１〜５のそれぞれに依頼する。ここでも通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。本実施形態では管理ノード７０１が処理ノード５も兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理２を依頼をすることになる。
【０１０２】
（５）各処理ノードは、テスト用の処理２を受け取ると処理を施し、処理結果を管理ノード７０１に送信する。
【０１０３】
（６）管理ノード７０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理１の処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ７０３の処理２に対応した状態２の欄の状態情報に書き込む。
【０１０４】
本例では、処理ノード１、２、５から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３及び４から受信した処理結果がそれぞれ異なっている（それぞれ第２のの処理結果及び第３の処理結果）と想定する。この場合、処理ノード状態ＤＢの状態２の欄の処理ノード１、２、５に対応する部分に「処理Ａ」を、処理ノード３に対応する部分に「処理Ｂ」を、処理ノード４に対応する部分に「処理Ｃ」を書き込んで処理ノード状態ＤＢ７０３を更新する。このようにして状態２の欄が更新された状態を７０３ｃに示す。
【０１０５】
なお、ここで状態２の欄に書き込む「処理Ａ」、「処理Ｂ」、「処理Ｃ」は、あくまでも状態２に対しての処理結果を識別するための表現（符号）であり、状態１の欄の状態情報である、「処理Ａ」、「処理Ｂ」とは異なるものであることに注意されたい。
【０１０６】
（７）管理ノード７０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ６０３を参照し、そのジョブと同様なテスト処理に関して同じ処理結果となった処理ノードの数が多いグループを分散処理の対象として選択し、投入されたジョブの分散処理を依頼する。
【０１０７】
例えば、ジョブが処理１と同様なＰＤＬ用の色処理であるとき、処理速度（効率）を優先させる場合には、処理ノード１、２、４にジョブを分散させて処理を依頼する。また、管理ノードと同じ処理結果を所望する場合には、処理ノード５、３にジョブを分散させて処理を依頼してもよい。
【０１０８】
一方、ジョブが処理２と同様なコピー用の画像処理であるときには、処理結果が同じ処理ノード１、２、５にジョブを分散させて処理を依頼する。この場合、他の処理ノードを処理結果が異なる処理ノード３、４を除外して分散処理を依頼することにより、処理結果に信頼性を持たせることができる。
【０１０９】
以上説明したように本実施形態によれば、複数の異なる処理に対応したテストを各処理ノードに実行させ、処理ノード状態ＤＢにもそれぞれのテストの結果に基づいた状態情報を格納するようにしたため、分散処理を行うジョブの種類に応じて適切な処理ノードを選択することができるため、分散処理システムの信頼性並びに効率を向上させることが可能となる。
【０１１０】
＜変形例１＞
上記第１から第３の実施形態では、実際に分散処理を依頼するジョブとは別個にテスト処理を各処理ノードに依頼するものであるが、分散処理を依頼するジョブの中にテスト処理を含めるようにしてもよい。
【０１１１】
この場合、システム内の全ての処理ノードが分散処理の対象となるが、得られた処理結果を採用するか否かは、テスト処理の結果に基づいて決定される。同時にテスト処理の結果に対応した状態情報は処理ノード状態ＤＢに格納される。処理結果を採用しないと決定された処理ノードに依頼された処理は、処理結果を採用すると決定された別の処理ノードに再度依頼されるように構成する。
【０１１２】
なお、このようなシステム内の全ての処理ノードを対象とした分散処理は、全てのジョブについて実行するのではなく、所定期間が経過する度に行われるようにしても良い。
【０１１３】
このようにすると、処理ノード状態ＤＢの状態情報を更新した後に、処理ノードに対して状態情報が異なるような作業、例えばソフトウェアやファームウェアのバージョンアップが行われた場合においても、分散処理システムの信頼性並びに効率を向上させることが可能となる。
【０１１４】
＜変形例２＞
上記第１から第３の実施形態では、テスト処理の結果に基づいて処理ノード状態ＤＢの状態情報を書き込んだ後には、状態情報をに応じてジョブの分散処理の対象となる処理ノードを選択する。
【０１１５】
上記の実施形態では、状態情報の更新について特に説明していないが、処理ノードに対して状態情報が異なるような作業、例えばソフトウェアやファームウェアのバージョンアップが行われた場合には、状態情報の更新が必要となる。
【０１１６】
このような状態情報の更新は、例えば、所定期間毎に上記実施形態のテスト処理を自動的に行うようにすればよい。
【０１１７】
このようにすると、例えばソフトウェアやファームウェアのバージョンアップが行われた場合においても、実際のジョブの依頼時の負荷を増やさずに、分散処理システムの信頼性並びに効率を向上させることが可能となる。
【０１１８】
＜他の実施形態＞
以上述べた実施形態では、グリッド用の制御プログラムを画像形成装置にもたせた構成を例にあげて説明したが、グリッド構成する要素はそれぞれ独立させてサーバや他のＰＣに持たせた構成としても良い。
【０１１９】
また、上記の実施形態はグリッドコンピューティング技術を使った例であるが、例えばＭＦＰへＬＡＮ経由で接続したＰＣからのサービスソフトの実施や、ファームウェアのダウンロードなど、他の機器から依頼された処理をバックグランドで実行する場合など、ネットワークで接続された他の装置から依頼された処理を実行可能に構成された装置であれば、本発明は同様に適用できる。
【０１２０】
本発明は、複数の機器から構成されるグリッドコンピューティングシステム（グリッド網）に適用しても良いし、また、グリッド網を構成する一つの機器に適用しても良い。
【０１２１】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（本実施形態では図５から図７に示す処理フローに対応したプログラム）を、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【０１２２】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１２３】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１２４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１２５】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の範囲に含まれるものである。
【０１２６】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１２７】
また、コンピュータ（情報処理装置）が、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１２８】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１２９】
【図１】グリッドコンピューティングの基本的構成を示す図である。
【図２】グリッドコンピューティングをプリンタのＰＤＬ処理に適用する場合の例を示す図である。
【図３】本発明に係る画像形成装置の概観を示す図である。
【図４】図３の画像形成装置の制御構成を示すブロック図である。
【図５】第１の実施形態の構成と処理の順序を概略的に示すブロック図である。
【図６】第２の実施形態の構成と処理の順序を概略的に示すブロック図である。
【図７】第３の実施形態の構成と処理の順序を概略的に示すブロック図である。
【図１】
2006344068.tif 000003
【図２】
2006344068.tif 000004
【図３】
2006344068.tif 000005
【図４】
2006344068.tif 000006
【図５】
2006344068.tif 000007
【図６】
2006344068.tif 000008
【図７】
2006344068.tif 000009