(57)【要約】【課題】  画像処理ジョブ単位に自由度をもたせることで、Ｇｒｉｄジョブの効果を有効活用でき、Ｇｒｉｄジョブの使用状況に応じたライセンス料の課金が可能となる。【解決手段】  グリッドコンピューティング技術のフレームワークを使用して、ネットワーク上に接続されたＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ−Ｐｅｒｉｐｈｅｒａｌ）やプリンタを有効活用し、かつ、リソース活用のライセンス料を課金するための画像形成システム。【選択図】        図１
2006155497.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続された画像形成システムであって、
印刷ジョブを投入する第１の投入手段、機器の動作状況を管理する管理手段、第１の投入手段によって投入されたジョブを分割する分割手段、分割したジョブを複数の画像形成リソースに分配投入する分配手段を有し、
前記分配手段は、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、前記分配数の上限を超えて、印刷ジョブを分配することを特徴とする画像形成システム。
【請求項２】
ネットワーク接続された画像形成システムであって、
印刷ジョブを投入する第１の投入手段、機器の動作状況を管理する管理手段、第１の投入手段によって投入されたジョブを分割する分割手段、分割したジョブを複数の画像形成リソースに分配投入する分配手段を有し、
前記分配手段は、ライセンスとして、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、リソースが上限に達しない場合を考慮して、ライセンス料を算出することを特徴とした画像形成システム。
【請求項３】
ネットワーク接続された画像形成システムであって、
印刷ジョブを投入する第１の投入手段、機器の動作状況を管理する管理手段、第１の投入手段によって投入されたジョブを分割する分割手段、分割したジョブを複数の画像形成リソースに分配投入する分配手段を有し、
前記分配手段は、ライセンスとして、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、前記分配数の上限を超えて、印刷ジョブを分配し、総リソースが上限に達しない場合を考慮して、ライセンス料を算出することを特徴とした画像形成システム。
【請求項４】
請求項１〜３のいずれかに記載の画像形成システムにおいて、前記画像形成システムは、ネットワーク接続された、一つ以上のホストコンピュータと二つ以上の画像形成装置によって構成され、前記画像形成リソースは、前記画像形成装置であることを特徴とする画像形成システム。
【請求項５】
請求項１〜４のいずれかに記載の画像形成システムにおいて、前記画像形成装置は、Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ−Ｐｅｒｉｐｈｅｒａｌであることを特徴とする画像形成システム。
【請求項６】
請求項１〜４のいずれかに記載の画像形成システムにおいて、前記画像形成装置は、プリンタであることを特徴とする画像形成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グリッドコンピューティング技術のフレームワークを使用して、ネットワーク上に接続されたＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ−Ｐｅｒｉｐｈｅｒａｌ）やプリンタを有効活用し、かつ、リソース活用のライセンス料を課金するための画像形成システムに関するものである。
【背景技術】
【０００２】
近年、ネットワーク環境の普及とともに、ネットワーク環境に複数の画像形成装置（例えばＭＦＰやプリンタ）が接続される環境が一般的である。最近では、こうした環境においてネットワークで相互接続された画像形成装置を連携活用することによって、画像形成システム全体の処理能力を有効活用する分散印刷も提案されつつあり、例えば、ジョブ毎の履歴によって、次ジョブは先行処理したジョブと素性、属性が類似したジョブの処理実績から分散対象を検索する技術も提案されている（例えば、特許文献１参照）。
【０００３】
一方、複数処理資源を活用して仮想的な処理装置を提供するための技術としてグリッドコンピューティング技術に関する研究と提案が盛んである。
【０００４】
図９は本発明に適用されるグリッドコンピューティングのアーキテクチャを説明する図である。グリッドには数種類あるが、ここで説明するのはデスクトップグリッドと呼ばれる、デスクトップＰＣなどのＣＰＵ空き時間を利用してジョブを実行するタイプのものである。
【０００５】
同図のＣｌｉｅｎｔはジョブを投入するユーザでありその要求（ジョブ）はタスクマネージャ（Ｔａｓｋ  Ｍａｎａｇｅｒ：以下ＴＭと略す）に渡されダイナミックジョブスケジューラ（Ｄｙｎａｍｉｃ  Ｊｏｂ  Ｓｃｈｅｄｕｌｅｒ：以下ＤＪＳと略す）にその内容を伝える。
【０００６】
ＤＪＳは全体のリソース管理をしていて最適なリソースのブローカ（Ｂｒｏｋｅｒ）を選択しＴＭに通知する（このリソースとはここではＣＰＵの空き状態のことを言っている）。
【０００７】
Ｂｒｏｋｅｒはリソースマネージャ（Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒ：以下ＲＭと略す）の吸い上げたリソースの情報をＤＪＳに登録し、ＴＭからの要求で最適なリソースにジョブを投入し、完了通知をＴＭに対しておこなう。
【０００８】
ＴＭはＤＪＳが選択した最適なＢｒｏｋｅｒにジョブを投入し、以後そのジョブの進行状況のモニタリングを実施し、完了通知をＢｒｏｋｅｒから受けるとユーザにその結果を通知する。またリソースに変化・異常があれば（例  故障、他のジョブを受け付けた等）ＲＭはＢｒｏｋｅｒに通知する。
【０００９】
このような仕組みで最適な（通常は利用されていない）ＣＰＵなどのリソースにジョブを配分することで分散処理を可能にするのがデスクトップグリッドコンピューティングの実現形である。
【特許文献１】特開２００３−６０８３２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来提案されている分散印刷の多くは、ジョブ単位に最適な装置を選択するものであって、当該ジョブを最も高速出力する用途には適しているが、システム全体の稼働率を向上させる効果が薄い場合が多い。さらに、リソースを複数使用するにあたり、ライセンス料が発生するが、該当ジョブが必ずしも、ライセンスされた数だけ確保されない場合もあり、ライセンス料に見合った処理が行われない場合もある。
【００１１】
本発明は、以上の点に着目して成されたもので、Ｇｒｉｄジョブの効果を有効活用でき、Ｇｒｉｄジョブの使用状況に応じたライセンス料の課金が可能となる画像形成システムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明に係る発明は、ネットワーク接続された画像形成システムであって、印刷ジョブを投入する第１の投入手段、機器の動作状況を管理する管理手段、第１の投入手段によって投入されたジョブを分割する分割手段、分割したジョブを複数の画像形成リソースに分配投入する分配手段を有し、前記分配手段は、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、前記分配数の上限を超えて、印刷ジョブを分配することを特徴とする。
【００１３】
また、前記分配手段は、ライセンスとして、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、リソースが上限に達しない場合を考慮して、ライセンス料を算出する。さらに、前記分配手段は、ライセンスとして、分配数の上限を持ち、過去の印刷ジョブの分配されたリソース状況から、前記分配数の上限を超えて、印刷ジョブを分配し、総リソースが上限に達しない場合を考慮して、ライセンス料を算出することを特徴とする。
【発明の効果】
【００１４】
本発明によって、ジョブ単位に自由度をもたせることで、Ｇｒｉｄジョブの効果を有効活用でき、Ｇｒｉｄジョブの使用状況に応じたライセンス料の課金が可能となる。
【発明を実施するための最良の形態】
【００１５】
以下本発明を実施するための最良の形態を、実施例により詳しく説明する。
【実施例１】
【００１６】
本発明における第１の実施例を説明する。
【００１７】
◆図１
図１は、本実施例の画像形成システムの構成を示す図である。
【００１８】
同図において、１、２、３はレーザビームプリンタ（以降「プリンタ」と称する）であり、１０、１１、１２はパソコン等の情報処理装置（以下、「ＰＣ」と称する）であり、２０は周知プロトコルで動作するネットワークである。
【００１９】
ネットワーク２０を介して、プリンタ１、プリンタ２、プリンタ３、ＰＣ１０、ＰＣ１１、ＰＣ１２を接続して画像形成システムを形成する。
【００２０】
ＰＣ１０、１１、１２は、プリントデータ及び制御コードから成る印刷データをプリンタ１、プリンタ２、プリンタ３に出力する。
【００２１】
◆図２
図２は、本実施例のＰＣ１０の構成を示す図である。
【００２２】
本実施例においては、ＰＣ１１、ＰＣ１２も同様の構成である。
【００２３】
ＰＣ１０は、入力装置としてのキーボード３０６やマウス３０７と、表示装置であるディスプレイ・モニタ３０５とが接続された一つのコンピュータ・システムとして構成されている。ＰＣ１０は、Ｗｉｎｄｏｗｓ（登録商標）などの基本ソフト（ＯＳ）によって動作しているものとする。
【００２４】
ＰＣ１０について、本発明に関する部分にのみ注目して機能的に大きく分類すると、アプリケーションソフトウェア３０１、グラフィック・サブ・システム３０２、スプールファイル３０３１および印刷装置との通信インターフェース３０３２を含むスプーラ３０３に大別される。
【００２５】
アプリケーションソフトウェア３０１は、例えば、ワープロや表計算などのＯＳ上で動作する応用ソフトウェアである。グラフィック・サブ・システム３０２は、ＯＳの機能の一部であるＧｒａｐｈｉｃｓ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ（以後、ＧＤＩと記す）３０２１とＧＤＩ３０２１から動的にリンクされるデバイスドライバであるプリンタドライバ３０２２、バンドスプーラ３０２３及び積算データ３０２４によって構成されている。
【００２６】
プリンタドライバ３０２２は、ＧＤＩ３０２１からＤＤＩ（Ｄｅｖｉｃｅ  Ｄｒｉｖｅｒ  Ｉｎｔｅｒｆａｃｅ）というインターフェースを介してコールされ、印刷装置に応じた処理を描画オブジェクト毎に行う。本実施形態に係るＰＣ１０では、ＤＤＩ関数に渡された情報をプリンタで高速に処理可能な印刷命令データ（ＰＤＬ）形式に変換し、直接スプーラ３０３に送出する場合と、生成した印刷命令データをバンド単位に分割してバンドスプーラ３０２３に第１バンドから順に１ページ分保持し、ページの最後にまとめてスプーラ３０３に送出する場合の二通りの処理が存在する。
【００２７】
スプーラ３０３は、ＯＳが管理しているスプールファイルシステムであり、設定により１ページ単位、またはジョブ単位で印刷データをスプールファイル３０３１として格納し、Ｉ／Ｆ３０３２を介してさらに、ネットワークプロトコルを実現するネットワークインターフェース３０４を介してプリンタ１，２，３に送出する。
【００２８】
ＯＳによって、上述した各部の名称や機能的な枠組みが若干異なる場合もあるが、これら名称や枠組みの相違は本発明の本質には影響しない。例えば、本発明でスプーラやスプールファイルと呼ぶモジュールは、別のＯＳにおいてプリント・キューと呼ばれるモジュールを用いて実現可能である。
【００２９】
なお一般的に、これらの各機能モジュールを含むＰＣ１０は、中央演算処理装置（ＣＰＵ）、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、各種入出力制御部（Ｉ／Ｏ）などのハードウェアのもとで、基本ソフト（ＯＳ）と呼ばれるソフトウェアがその制御を司り、その基本ソフトの元で、それぞれの応用ソフト、サブ・システム・プロセスが機能モジュールとして動作する。
【００３０】
◆図３
図３は、プリンタドライバ３０２２の処理概要を模式的に説明した図である。
【００３１】
代表して、ＰＣ１０においてプリンタ１を選択して印刷した場合を説明するが、ＰＣ１０，１１，１２のいずれからプリンタ１，２，３のいずれへの印刷であれば本説明と同様である。
【００３２】
４００１は一般的なドキュメント作成アプリケーションを使って作成したドキュメントとして、グラフィックス、文字、イメージが含まれているものとする。
【００３３】
このようなドキュメントを印刷する際、まずＯＳにインストールされているプリンタドライバ３０２２に対して、ＯＳを介して描画命令（４００２，４００３）が渡される。プリンタドライバ３０２２は、初期状態は通常のＰＤＬモード系ドライバと同様に、描画命令毎に印刷命令（ＰＤＬ）を生成し、システムスプーラ３０３に書き込みを実施する。この際に、プリンタドライバ３０２２は、コマンド数やコマンドの種類に応じた所定の計算式で計算したデータサイズを積算データ３０２４として積算していく。積算データ３０２４は例えばホストコンピュータの有するＲＡＭの所定領域に格納される。なお、ＯＳを介してプリンタドライバ３０２２が受け取る描画命令（ＤＤＩ関数）は、描画オブジェクト重なりの下レイヤーから順に出力される仕様になっている。
【００３４】
１ページ分のデータ全てをシステムスプーラ３０３に書き込めたときは、スプーラ３０３にスプールファイル３０３１として蓄えられた印刷命令（ＰＤＬ）を、印刷装置１００に送出し、積算データ３０２４をクリアする。一方、積算データ３０２４の値が、予め定めたデータサイズ、コマンド数等を超えた時は、以下のように処理を切り替える。
【００３５】
図３の４０１０は、４００２で示される「矩形描画（イメージの背景）４０２１、イメージ描画命令４０２２及びイメージの実体４０２３」までがシステムスプーラ３０３に格納された様子を示している。本実施形態ではイメージデータ４０２３をスプーラ３０３に出力した時点で、積算データ３０２４が予め定めたデータサイズの閾値を超えたことを契機に処理が切り替えられたものとする。
【００３６】
プリンタドライバ３０２２は、イメージデータ４０２３以降の描画命令４００３に対する印刷命令を生成し、初期化処理時に例えばＲＡＭの所定領域として確保しておいたバンドスプーラ３０２３にプリンタ１で処理を行うバンド領域毎に分けて描画順に格納し、管理する（４００６）。ＯＳから渡される描画命令４０３（ＤＤＩ関数）は、印刷装置の印字方向とは無関係に出力されてくるため、本実施形態のようにページの途中からバンド処理に切り替わった場合にも、第１バンドから第Ｎバンドまでページ内のすべてのバンドに対する格納処理が行われる。
【００３７】
格納処理は、プリンタドライバ内のＤＤＩ関数がコールされる度に行う。バンド領域内に格納領域に格納できなくなった時は、新たにＲＡＭの領域を確保することで対処する。第１バンドから第Ｎバンドまでの１ページ分の残りの描画データ格納が終了したら、印刷装置で処理するバンド順にデータをシステムスプーラ３０３に書き出す（４００９）。
【００３８】
各バンドデータの先頭には、以降に送出するバンド情報４０１１をつけることで、プリンタ１側で印刷データがページ単位からバンド単位に移行したことを認識可能とする。１ページ分の印刷データをシステムスプーラ３０３にスプールしたら、プリンタ１に送出する（４０１２）。
【００３９】
◆図４
図４は、プリンタ１の構成を示す図である。
【００４０】
本実施例においては、プリンタ２、プリンタ３も同様の構成である。
【００４１】
３１１は、イメージデータ（２値または多値データ）に基づいて、周知の電子写真プロセスによって感光ドラム上に潜像を形成し、用紙に転写して定着し印字を行うエンジン部、３１０は、エンジン部３１１に接続され、ＰＣ１０，１１，１２から送られるコードデータ（ＥＳＣコード、各種ＰＤＬ等）を受け、このコードデータに基づいてドットデータからなるページ情報を生成しエンジン部３１１に対して所定のインターフェース手段によってイメージデータを送信するコントローラ部、３１２は、ユーザ（操作者）とのインターフェースを行うパネル部３１２であり、不図示のタッチセンサを有する液晶パネルと、キーボードで構成される。ユーザは、パネル部３１２を操作することによって、プリンタ１に所定の動作を指示することができる。
【００４２】
コントローラ部３１０に関して説明する。コントローラ部３１０は、ＰＣ１０，１１，１２との接続手段であるインターフェース（Ｉ／Ｆとも表記する）部３１０１と、受信データ等を一時的に保持管理するための受信バッファ３１０３、送信データ等を一時的に保持管理するための送信バッファ３１０４、印刷データの解析を司るコマンド解析部３１０７、印刷制御処理実行部３１０９、描画処理実行部３１０５、ページメモリ３１０６より構成されている。
【００４３】
インターフェース部３１０１は、ＰＣ１０との印刷データの送受信を行う通信手段である。
【００４４】
インターフェース部３１０１を通して受信した印刷データは、そのデータを一時的に保持する記憶手段である受信バッファ３１０３に逐次蓄積され、必要に応じてコマンド解析部３１０７または描画処理実行部３１０５によって読み出され処理される。コマンド解析部３１０７は、印刷命令体系や印刷ジョブ制御言語に準じた制御プログラムにより構成されており、文字印字、図形、イメージなどの描画に関する印刷データの解析結果は、描画処理実行部３１０５に指示を与えて処理し、給紙選択やリセット命令などの描画以外のコマンドは、印刷制御処理実行部３１０９に指示を出し処理する。
【００４５】
描画処理実行部３１０５は、文字やイメージの各描画オブジェクトをページメモリ３１０６内のバンドメモリに逐次展開して行くＹＭＣＫレンダラである。
【００４６】
例えば、カラーＬＢＰエンジンに対しては、ＭＣＹＫの順番でデバイス依存ビットマップデータを送出する必要があるが、標準状態では、そのために必要なメモリをすべて確保するわけではなく、１プレーン（１，２又は４ｂｉｔ／ｐｉｘｅｌ）の数分の１のメモリ領域がバンドメモリ領域としてページメモリ３１０６内に確保される。そして、バンドメモリ領域を繰り返し用い、プリンタエンジン３１１０の処理に同期して描画処理するように構成されている。
【００４７】
通常はこのように、描画処理実行部３１０５による展開処理をプリンタエンジン３１１０へのビデオ信号のシッピング処理が追いかけるバンディング制御によってページメモリ３１０６は管理されているが、十分なメモリがある場合は１ページ分が展開可能なメモリ領域を確保しても良い。
【００４８】
なお、コントローラ部３１０は、中央演算処理装置（ＣＰＵ）、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）などを用いたコンピュータ・システムによって構成されている。また、コントローラ部３１０内の各部の処理は、マルチタスクモニタ（リアルタイムＯＳ）のもとでタイムシェアリングに処理される構成であっても良いし、機能毎に専用のコントローラ・ハードウェアを用意して独立して処理される構成であってもかまわない。
【００４９】
出力制御部３１０８は、バンドメモリ（ページメモリ）３１０６の内容をビデオ信号に変換処理し、プリンタエンジン３１１０へ転送する。
【００５０】
◆図５
図５は、本実施例におけるグリッドフレームワーク活用を説明するための図である。
【００５１】
同図は、グリッドフレームワークを画像形成装置のＰＤＬ処理に適用した場合の構成説明である。
【００５２】
本実施例におけるＴＭ４００，ＤＪＳ４０１はＰＣ１２において動作し、本実施例の画像形成システム全体のリソースを管理するものとする。またＢｒｏｋｅｒ４１０，４１１，４１２は各々プリンタ１，２，３において動作する。さらにＲＭ４２０，４２１，４２２は各々プリンタ１，２，３において動作する。
【００５３】
本図の動作説明は、後述のフローチャートを用いて行う。
【００５４】
◆図６
図６は、本実施例における情報表示に関する説明のための図である。
【００５５】
本実施例では、ＤＪＳ４０１において、ＲＭ４２０，４２１，４２２からの状態変化を履歴として蓄積管理し、タスクスケジューリングの際の参照情報と、および、リソースの使用情報からライセンス料として課金するための計算とに使用する。また、ユーザは前述の履歴情報を参照することが可能である。参照方法は、ディスプレイ・モニタ３０５もしくは、プリンタ１，２，３からの印刷物がある。
【００５６】
同図は、ディスプレイ・モニタ３０５に表示される情報を示すと同時に管理情報の種類を説明している。
【００５７】
５０１，５１１は、「オーナー名」であってシステムを構成するＰＣ１０，１１，１２の名称である。５０２，５１２は、「ライセンス数」であって、オーナーが同時に使用可能なリソース数である。５０３は、「ＪＯＢ名称」であって、ＰＣ１０から投入されたＪＯＢの名称である。５０４は、「日時」であって、ＰＣ１０からジョブが投入され、実行終了した日時である。５０５は、「状態」であって、ジョブ処理の終了が正常終了なら、「ＯＫ」を表示し、実行中なら「実行中」を、異常終了なら、「ＮＧ」を表示する。
【００５８】
５０６は、「使用リソース」であって、ＰＣ１０のライセンス数は、２リソースであるが、実際に使用されたリソースを表示する。Ｊｏｂ５０１１は、プリンタ１，３を使用し、Ｊｏｂ５０１２は、プリンタ２，３が使用中のため、プリンタ１のみ使用したことになる。５０７は、「実績」であって、累積のリソース使用状態を表示している。Ｊｏｂ５０１２は、２台のプリンタを使用できなかったため、「−１」となり、Ｊｏｂ５０１３も同様プリンタ１のみの使用のため、「−２」となる。Ｊｏｂ５０１４では、プリンタ１，２，３とも使用可能であり、実績では、ライセンスを十分に使用していない（−２）状態であるので、本来、ライセンスとしては、２台のプリンタしか使用できないが、過去の未使用分を１台分多く使用して、プリンタ１，２，３とも使用した。そのため実績では、「−１」になる。
【００５９】
５１３は、トータルのＪｏｂ数であり、それぞれのオーナーが印刷したジョブ数である。５１４は、トータルＪｏｂ数とライセンス数を掛け合わせた「使用予定リソース数」である。５１５は実際にＪｏｂを処理したときに使用された「実使用リソース数」である。５１６は、（実使用リソース数からトータルＪｏｂ数を引いた）ものを、（使用予定リソース数からトータルＪｏｂ数を引いたもの）で割ったものに１００をかけた「使用率」である。Ｊｏｂは、最低でも１台のプリンタを使用することから、この図のＰＣ１２では、１度も２台以上のプリンタを使用できなかったことになる。すなわち、グリッドコンピューティング技術のフレームワークを有効活用できていないので、使用率は、０％になる。
【００６０】
◆図７
図７は、本実施例のシステムにおいて履歴情報を蓄積保管する形態を説明するための図である。
【００６１】
履歴情報は、リソースリスト６０１にリンクされたリソース管理テーブル６０２に格納される。リソースリスト６０１とリソース管理テーブル６０２は共にＤＪＳ４０２によって管理され、実体はＰＣ１２の所定の不揮発メモリ（ＨＤＤを含む）に格納される。
【００６２】
リソース管理テーブル６０２は、管理情報、状態情報、履歴に分かれており、デバイス名称が前述のオーナー名に、時刻実績が現在時刻における過去履歴としての扱いに、期間実績が履歴保存期間に渡る過去履歴としての扱いに、システム活用率がシステム全体の活用率の計算に使用される。
【００６３】
時刻実績は、装置毎に所定時刻単位毎に実績を記録している。この履歴を参照することで、実際に使用できなかった原因を探ることが可能となる。
【００６４】
◆図８
図８は、本実施例の処理フローを説明するためのフローチャートである。
【００６５】
ＰＣ１０からのプリンタ１に対してジョブ（プリント処理依頼）が投入されると（Ｓ１０１）、ＴＭ４００，ＤＪＳ４０１を介して、Ｂｒｏｋｅｒ４１０，４１１，４１２のなかで、使用可能なリソースと、５０２，５１２の「ライセンス数」および５０７の「実績」により算出される可能な使用リソース数により、サブジョブに分割される。分割単位は前述のようなバンド単位、あるいはページ単位、ジョブ単位のいずれかがＴＭ４００によって選択される。またＤＪＳ４０１は、前述の「時刻実績」に基づいてサブジョブ分割を行う（Ｓ１０２）。
【００６６】
各サブジョブはＢｒｏｋｅｒ４１０，４１１，４１２，ＲＭ４２０，４２１，４２２を経由してプリンタ１，２，３で処理される。例えばＲＭ４２１は、リソースの情報（プリンタ２の空き状況）をＢｒｏｋｅｒ４１１に通知し、Ｂｒｏｋｅｒ４１１からの指示によりリソース（プリンタ２）にサブジョブを投入する（Ｓ１０３）。
【００６７】
更にＲＭ４２１は、定期的にリソース（プリンタ２）の状態を吸い上げ、異常があればＢｒｏｋｅｒ４１１へ通知する。異常状態とは、プリンタ２の本業（ＰＣからプリンタ２指定でジョブが投入された場合等）を含むものであって、サブジョブ処理の継続ができなくなる場合である。
【００６８】
ＲＭ４２１からＤＪＳ４０１に異常状態が通知されると（Ｓ１０４）、ＤＪＳ４０１は、その内容と発生時刻を履歴として保存し（Ｓ１１０）、当該サブジョブの処理対象を再度判定する（Ｓ１０２）。
【００６９】
サブジョブを割り当てられた全ＲＭから完了通知を受けると、ＤＪＳ４０２とＴＭ４００は指定のリソース（プリンタ１）において、処理済みのサブジョブを結合して処理済みジョブを生成指示し（Ｓ１０６）、プリンタ１において印刷実行して（Ｓ１０７）処理が終了する（Ｓ１０８）。最終的にジョブが終了した時点で、サブジョブを正常実行したリソースが５０６の「使用リソース」となり、処理途中で異常があり、サブジョブを正常実行できなかった場合は、５０６の「使用リソース」の対象とはならない。
【００７０】
以上のように構成することによって、Ｇｒｉｄコンピューティング技術を用いて処理を分散する画像処理装置において、ジョブ単位に自由度をもたせることで、Ｇｒｉｄジョブの効果を有効活用でき、Ｇｒｉｄジョブの使用状況に応じたライセンス料の課金が可能となる。
【実施例２】
【００７１】
本発明は、前述の第１の実施例に限られるものではない。
【００７２】
実施例１で示したＰＣとプリンタによるシステムは一例であって、複数のＭＦＰやプリンタが接続されているネットワーク環境においても同様に適用される。
【００７３】
実施例１で示したシステムは、ＰＣ３台、プリンタ３台であるが、台数についても本発明の適用に影響するものでは無い。
【００７４】
実施例１で示したシステムは、ＴＭ４００，ＤＪＳ４０１はＰＣ１２において動作したが、ＴＭ４００，ＤＪＳ４０１は、ＰＣ１０，１１，１２、プリンタ１，２，３のいずれで動作するものであっても本発明の適用に影響するものでは無い。
【図面の簡単な説明】
【００７５】
【図１】画像形成システムの全体構成を示すブロック図である。
【図２】ＰＣ１０の構成説明図である。
【図３】ＰＣ１０の制御説明図である。
【図４】プリンタ１の構成説明図である。
【図５】コントローラ部３１０の制御説明図である。
【図６】本実施例の特徴を説明するための図である。
【図７】本実施例の特徴を説明するための図である。
【図８】本実施例の制御フローを説明するための図である。
【図９】従来例を説明するための図である。
【符号の説明】
【００７６】
１    プリンタ
２    プリンタ
３    プリンタ
１０  ＰＣ
１１  ＰＣ
１２  ＰＣ
２０  ネットワーク
【図１】
2006155497.tif 000003
【図２】
2006155497.tif 000004
【図３】
2006155497.tif 000005
【図４】
2006155497.tif 000006
【図５】
2006155497.tif 000007
【図６】
2006155497.tif 000008
【図７】
2006155497.tif 000009
【図８】
2006155497.tif 000010
【図９】
2006155497.tif 000011