JP4725964B2 - 分散処理システム、分散処理方法、分散処理に使用されるジョブ・アービタ、およびプログラム - Google Patents

Description

本発明は、画像処理装置を分散処理のクラスタ・ノードとして使用する、分散処理システム、分散処理方法、ジョブ・アービタおよびプログラムに関する。

近年、ネットワーク・インフラ基盤の発展により、膨大な計算をネットワークに接続された情報処理装置に分散させて処理を行う分散処理システム、所謂、グリッド・コンピューティング・システムが注目されている。グリッド・コンピューティング・システムは、単一のサーバまたは汎用大型コンピュータなどでも多大な時間を必要とする計算処理を、計算処理単位（以下、ジョブとして参照する。）に分割し、ネットワークを介して、パーソナル・コンピュータなど、処理能力では劣るクラスタ・ノードに依頼し、最終的に目的とする結果をサーバが取得する。

上述した処理は、通常では、サーバが、目的とする処理を複数のジョブに分割し、ジョブ・リストなどとして登録する。サーバは、ボランティアなどが応募してきた段階で、そのＩＰアドレスを取得し、パスワード、ユーザＩＤなどを設定し、ボランティアが管理するパーソナル・コンピュータをクラスタ・ノードとして登録する。その後、サーバは、ボランティアによるリクエストに応答したジョブ、またはサーバがジョブ・リストから選択したジョブをデータと共にクラスタ・ノードに送付する。クラスタ・ノードは、依頼された処理を実行し、その実行結果をレスポンスとして返すことで、サーバに対して実行結果をアップデートさせている。

図２３には、従来の分散処理システム１４０の概略的な構成を示す。図２３に示されるように、分散処理システム１４０は、処理を依頼するサーバ１４２と、種々のプロトコル変換を実行するＧＷサーバ１４４と、インターネットまたは公衆電話網などの通信インフラ基盤に基づいた公共ネットワーク１５８と、公共ネットワーク１５８に接続された複数のクラスタ・ノード１４６〜１５６とから形成されている。

サーバ１４２と、ＧＷサーバ１４４との間は、企業などのバックボーン・ネットワーク１６０により接続されていて、サーバ１４２からの分散処理依頼は、バックボーン・ネットワーク１６０を介して、クラスタ・ノード１４６〜１５６へと個別的に配布される。クラスタ・ノード１４６〜１５６は、多くの場合、ボランティア的に、また実行結果が得られた場合には懸賞などにより一定のメリットを受けるだけである。このためサーバ１４２は、ユーザからのアクセスを待機し、ユーザからのアクセスがあった段階でクラスタ・ノード１４６〜１５６のユーザからサーバ１４２へと分散処理を行うべきジョブを、ゲット型伝送により伝送する。この場合、サーバ１４２では、処理を依頼したい分散可能なジョブがあるにも拘わらず、ジョブを配送できないという処理上のタイムラグが発生する。

また、せっかくクラスタ・ノード１４６〜１５６が得られても、クラスタ・ノードの増加と、サーバ１４２が処理しなければならないトランザクションの数は概ね比例する。この結果、クラスタ・ノード１４６〜１５６が増加するにつれ、サーバ１４２側のバックボーン・ネットワーク１６０の帯域幅が消費され、特にＧＷサーバ１４４よりも公共ネットワーク１５８側の接続ノードには、バックボーン・ネットワークでのトランザクションが集中する。このため、接続ノードのネットワーク帯域幅がボトルネックとなり、輻輳などの不都合が発生することも想定される。このため、クラスタ・ノードの増加に直接的に対応してトランザクション量を増加させることのない分散処理システムが望ましい。

また、近年、画像処理装置、特に、複合機として参照される画像処理装置は、高画質化・フルカラー化した画像を、画像処理を高速に実行することが必要であるため、その処理能力が向上している。また、近年では多くの場合、画像処理装置は、インターネットなどのネットワークに接続されて、管理センタなどと相互通信する環境とされており、ユーザとの間に保守管理契約に基づいた保守データが収集される場合が多い。管理センタに配置されたサーバは、画像処理装置と相互通信を実行し、その稼働状況、メンテナンス管理などの必要性などを判断して、保守サービスに反映する。

上述した理由から、画像処理装置は、パーソナル・コンピュータやワークステーション程度の処理能力を備えるようになっている。したがって、画像処理装置の中央処理装置（以下、ＣＰＵとして参照する。）、メモリなどのハードウェア資源を有効利用することで、サーバなどの処理負担を軽減し、効率的な処理が可能となるものと考えられる。

一方で、画像処理装置は、サーバから依頼された計算処理だけではなく、本来、複写機、ファクシミリなどの本来の用途として使用されていることを想定しなければならない。画像処理装置が、本来の用途に使用されている、または使用可能な期間にクラスタ・ノードとして機能してしまうと、本来の用途の機能を低下させることにもなる。また、サーバ側でも、手当たり次第にジョブを配布するのではクラスタ・ノードからのリターン・タイムが予測できず、グリッド・コンピューティングなどの分散処理におけるスケーラビリティを確保できないという問題が発生する。加えて、画像処理装置を導入しているユーザから見れば、ユーザが知らないうちにボランティア的に画像処理装置の能力を提供することは好ましいことではない。

すなわち、画像処理装置のハードウェア資源を有効に利用して分散処理を行うためには、分散処理のスケーラビリティを確保でき、また画像処理装置の計算能力が余剰となっている期間を有効に利用することが好ましい。また、画像処理装置のユーザが、画像処理装置の能力提供という観点でメリットを享受することができれば、計算機資源のより有効な活用を行うことができると考えられる。

これまで、画像処理装置に対して分散処理を依頼するためのサーバが提案されている。例えば、特開２００４−３２６４５２号公報（特許文献１）には、コンピュータ資源の余剰部分を効率的に利用するために、サービス要求を行う第１のコンピュータと処理を実行する複数の第２のコンピュータとを含む分散コンピューティング環境を提供するサーバであって、第１のコンピュータからのサービス要求を受付けて、第２のコンピュータの資源に関する情報に基づいて受付けたサービス要求に関する処理を分割した各処理ブロックを割当てる第２のコンピュータを決定する第２の手段と、を備え、決定された第２のコンピュータに、割当てた処理ブロックを配信する第３の手段と、第２のコンピュータからの処理ブロックの処理結果を受信し、その処理結果に基づいてサービス要求に対する処理結果を第１のコンピュータに配信する第４の手段を備える分散処理サービス提供サーバが開示されている。

特許文献１に記載された分散コンピューティング環境も、コンピュータ資源の余剰分を効率的に利用することは可能であるということができる。しかしながら、第１のコンピュータからの要求をサーバが受付け、第２のコンピュータに処理ブロックを渡し、その処理結果をサーバが受信して第１のコンピュータに配信する処理は、すべてのトランザクションが、サーバが使用するバックボーン・ネットワークを通過することになる。このため、サーバの能力は充分にあったとしても、サーバに対して処理を依頼するコンピュータが増加するにつれて、バックボーン・ネットワークの帯域幅がますます消費され、輻輳などの問題が発生し、必ずしも効率的な分散処理を保証することにはならない場合も発生する。また、分散コンピューティング環境の帯域幅を増大させるため、バックボーン・ネットワークのインフラ基盤を整備するのでは、サーバ管理者側におけるコスト負担も無視できず、分散環境全体として必ずしも効率的なものであるとはいえない。
特開２００４−３２６４５２号公報

すなわち、本発明は、クラスタ・ノードの増加が、直接バックボーン・ネットワークの帯域幅の低下を招くことのない、分散処理システム、分散処理方法、ジョブ・アービタおよびプログラムを提供することを目的とする。

また、本発明の他の目的は、サーバとクラスタ・ノードとの間における多重のトランザクションを、公共ネットワークから高速なローカル・エリア・ネットワーク（ＬＡＮ）などのプライベート・インフラ基盤でのトランザクションに移行させることにより、公共ネットワークにおける輻輳発生の可能性を低減させ、同時に画像処理装置の余剰のＣＰＵ能力を有効に利用する、分散処理システム、分散処理方法、ジョブ・アービタおよびプログラムを提供することを目的とする。

さらに、本発明の他の目的は、画像処理装置のユーザが、画像処理装置能力および画像処理装置の利用期間の提供に応じて、画像処理装置の管理コストの低減を受けることを可能とすることにより、画像処理装置の管理者側およびユーザ側双方における計算機資源の効率的利用を促すことができる、分散処理システム、分散処理方法、ジョブ・アービタおよびプログラムを提供することを目的とする。

本発明は、サーバが実行する処理を代入または参照構造の深度に分解し、深度に対応した分割ジョブとして、クラスタ・ノード間でのジョブの配布を仲介するジョブ・アービタに伝送する。サーバは、ジョブ・アービタが管理する画像処理装置のトータル・パフォーマンスを、保守データを使用して管理しており、トータル・パフォーマンスおよび分割ジョブのために使用できる資源量、結果出力の処理時期などに応答してジョブ・アービタを選定する。ジョブ・アービタは、受取った分割ジョブをさらに分割し、自己が管理するクラスタ・ノードに分配し、クラスタ・ノードにジョブの処理を実行させる。クラスタ・ノードは、処理が終了した後、サーバにではなく、ジョブ・アービタに対して実行結果を送る。ジョブ・アービタは、サーバから依頼された分散ジョブがすべて終了するまでジョブを管理し、すべてのジョブが終了した段階で、サーバ装置に依頼された分割ジョブの結果を返す。

サーバは、受取った結果に関連する処理量に応答して、ユーザの画像処理装置の管理コストについての割引料金を決定し、ユーザに通知するか、または請求に管理コストの請求に反映させる。

すなわち、本発明によれば、画像処理装置にネットワークを介して処理を実行させる分散処理システムであって、前記システムは、
画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録し、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークに送出するサーバと、
前記サーバから前記分割ジョブを前記ネットワークを介して受信し、第２のネットワークに接続され、ジョブを配付できる画像処理装置を監視し、前記画像処理装置に対し、受信した前記分割ジョブの少なくとも一部のジョブを伝送するジョブ・アービタと、
前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行し、実行結果を前記ジョブ・アービタに返信する画像処理装置と
を備え、
前記サーバは、前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録し、同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定するシステムが提供される。

本発明の第２の構成によれば、画像処理装置にネットワークを介して処理を実行させる分散処理システムであって、前記システムは、
画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録し、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出するサーバと、
前記サーバに対して分割ジョブ・リクエストを定期的にポーリングし、前記ポーリングに応答して前記分割ジョブを前記ネットワークを介して受信し、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送するジョブ・アービタと、
前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行し、実行結果を前記ジョブ・アービタに返信する画像処理装置と
を備え、
前記サーバは、前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録し、同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の提供可能資源データについての前記保守データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定する、システムが提供される。

本発明では、前記サーバは、前記分割ジョブを、電子証明書またはＳＳＬによる暗号化されたＦＴＰパケットとして送出する送出手段を備えることができる。本発明では、前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択する選択手段を含むことができる。本発明では、前記選択手段は、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択することができる。本発明では、前記サーバは、前記ジョブ・アービタが提供した提供資源量に応答して前記保守管理契約に対する割引料金を決定する割引料金決定手段を含むことができる。

本発明の第３の構成によれば、画像処理装置に対してネットワークを介して処理を実行させる分散処理方法であって、前記方法は、
サーバが、
ジョブ・アービタに対し、分割ジョブ・リクエストを前記サーバに定期的にポーリングさせるステップと、
画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録させ、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出させるステップと、
前記ジョブ・アービタに対し、前記分割ジョブを前記ネットワークを介して受信させ、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送させるステップと、
画像処理装置に対し、前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行させ、実行結果を前記ジョブ・アービタに返信させるステップと
を含み、
前記サーバが、さらに
前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録するステップと、
同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定するステップとを実行する方法が提供される。

本発明の前記送出させるステップは、前記分割ジョブを、電子証明書またはＳＳＬによる暗号化されたＦＴＰパケットとして送出させるステップを含むことができる。本発明では、前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択するステップを実行することができる。本発明の前記選択するステップは、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択するステップを含むことができる。本発明の前記サーバは、前記ジョブ・アービタが提供した提供資源量に応答して前記保守管理契約に対する割引料金を決定するステップを実行することができる。

本発明の第４の構成によれば、画像処理装置に対してネットワークを介して分散処理を実行させるジョブ・アービタであって、前記ジョブ・アービタは、
前記分散処理に対するリクエストを前記ネットワークへと定期的にポーリングする手段と、
前記ポーリングに応答して前記ジョブ・アービタの所定期間についての処理能力以下として生成された分割ジョブを前記ネットワークを介してサーバから受信する手段と、
前記分割ジョブの少なくとも一部を第２のネットワークを介して前記画像処理装置へと送出し、前記画像処理装置の実行結果を受取り、前記実行結果を前記ネットワークを介して前記サーバに送出する送出手段と、
を備え、
前記ジョブ・アービタは、前記サーバが同一の階層に登録された前記分割ジョブのサブツリーの数に応じて前記ジョブ・アービタが管理する画像形成装置の保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して前記分割ジョブを送付する宛先が決定され、前記サーバから前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記階層構造の深度に応じた前記分割ジョブのサブツリーとして受信する、ジョブ・アービタが提供される。

本発明の前記送出手段は、前記実行結果をＦＴＰプロトコルへと変換する手段を含むことができる。本発明では、前記送出手段は、前記ネットワークへの送出プロトコルと、前記第２のネットワークへの送出プロトコルとを変えて送出を行うことができる。本発明の前記送出手段は、前記分割ジョブに対して電子証明書またはＳＳＬを使用して暗号化または復号化されたデータを生成する手段を含むことができる。

本発明の第５の構成によれば、画像処理装置に対してネットワークを介して分散処理を実行させるジョブ・アービタとして情報処理装置を機能させるプログラムであって、前記プログラムは、前記情報処理装置が、
前記分散処理に対するリクエストを前記ネットワークへと定期的にポーリングするステップ、
前記ポーリングに応答して前記ジョブ・アービタの所定期間についての処理能力以下として生成された分割ジョブを前記ネットワークを介してサーバから受信するステップ、
前記分割ジョブの少なくとも一部を第２のネットワークを介して前記画像処理装置へと送出し、前記画像処理装置の実行結果を受取り、前記実行結果を前記ネットワークを介して前記サーバに送出する送出ステップ、
を実行し、
前記ジョブ・アービタは、前記サーバが同一の階層に登録された前記分割ジョブのサブツリーの数に応じて前記ジョブ・アービタが管理する画像形成装置の保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して前記分割ジョブを送付する宛先が決定され、前記サーバから前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記階層構造の深度に応じた前記分割ジョブのサブツリーとして受信する、情報処理装置実行可能なプログラムが提供される。本発明では、前記送出ステップは、前記実行結果をＦＴＰプロトコルへと変換するステップを含むことができる。本発明では、前記送出ステップは、前記ネットワークへの送出プロトコルと、前記第２のネットワークへの送出プロトコルとを変えるステップを含むことができる。本発明では、前記分割ジョブに対して電子証明書またはＳＳＬを使用して暗号化または復号化されたデータを生成するステップを含むことができる。

本発明によれば、画像処理装置に対してネットワークを介して処理を実行させるため、情報処理装置をサーバとして機能させるための情報処理装置実行可能なプログラムであって、前記プログラムは、前記情報処置装置を、
ジョブ・アービタに対し、分割ジョブ・リクエストを前記サーバに定期的にポーリングさせる手段、
画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録させ、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出させる手段、
前記ジョブ・アービタに対し、前記分割ジョブを前記ネットワークを介して受信させ、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送させる手段、
画像処理装置に対し、前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行させ、実行結果を前記ジョブ・アービタに返信させる手段
として機能させ、
さらに、前記情報処理装置を、
前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録する手段、
同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定する手段
として機能させる、プログラムが提供される。前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択する選択手段を含むことができる。さらに、前記選択手段は、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択することができる。

以下、本発明を、図面に示した実施の形態をもって説明する。図１は、本発明の分散処理システムの実施の形態を示した図である。本発明の分散処理システム１０は、所謂、グリッド・コンピューティング・システムとしても機能し、サーバ１２と、サーバ１２から処理を依頼される複数の画像処理装置（２８、３０、３２）とを含んで構成されている。なお、本発明では、特に画像処理装置の性能に関連して本発明を説明する以外、画像処理装置とは、複合機、複写機、プリンタ、ファクシミリなどの画像処理装置すべてを含む意味で使用する。

サーバ１２は、本発明の実施の形態では、画像処理装置（２８、３０、３２）の状態管理、消耗品管理などを行うための管理センタに設置されている。管理センタでは、画像処理装置を遠隔的にモニタして動作チェック、コピー・カウンタに応じたメンテナンス管理のスケジューリングを行っている。また、サーバ１２は、コピー・カウンタに応答した課金処理などを行い、当該ユーザに対しての請求を取りまとめる処理を行っている。また、サーバ１２は、本発明にしたがい、分散処理の要求を受付け、分散処理のために必要なソフトウェア資源およびデータを、要求下に配布している。

これらの処理を実行するため、サーバ１２は、ワイド・エリア・ネットワーク（ＷＡＮ）、ＬＡＮなどのバックボーン・ネットワーク１６を介してゲートウェイ・サーバ（ＧＷサーバ）１４に接続されている。ＧＷサーバ１４は、各種のネットワークを介して送受信される、転送データ、メール、ＨＴＴＰリクエストなどのプロトコルを相互に変換して、サーバ１２や、バックボーン・ネットワーク１６に接続されたコンピュータ（図示せず）との間のデータ伝送を管理している。また、ＧＷサーバ１４は、図示しないルータおよびファイアウォール１８を介してインターネットや、公衆電話網などの公共ネットワーク２０に接続されている。

ユーザ側のプライベート・ネットワークは、ファイアウォール２２およびルータ２４を介して公共ネットワーク２０に接続されている。ルータ２４は、ＯＳＩ参照モデルなどにおいて参照されるネットワーク層／トランスポート層レベルでのネットワーク制御を行っている。公共ネットワーク２０は、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなどの適切なプロトコルによるＩＳＤＮ、ＡＤＳＬ、光通信などの通信インフラ基盤を使用して構築されており、多くの場合、６４ｋｂｐｓ〜１００Ｍｂｐｓ程度の通信ビットレートを提供している。

また、ユーザは、オフィス・フロア内に複数の機能を備えた複合機２８、複写機能を備える複写機３０、プリンタ３２などを使用している。これらの画像処理装置は、本発明の特定の実施の形態では、さらに他のスイッチなどを使用して構成されるＬＡＮ／ＶＬＡＮなどの他のネットワーク３６を含んで形成することができるＷＡＮ／ＬＡＮなどとして構成され、プライベート・ネットワークである第２のネットワーク３８に接続されている。画像処理装置は、画像形成などの画像処理を実行する他、同時に本発明のクラスタ・ノードとして機能する。また、第２のネットワーク３８には、本発明のジョブ・アービタ２６が、スイッチ３４を介して複合機２８、複写機３０、およびプリンタ３２に接続されている。

第２のネットワーク３８は、例えば、ＩＥＥＥ８０２．３ｕなどに規定される１００Ｂａｓｅ−ＴＸ、またはＩＥＥＥ８０２．３ｚに規定される１０００Ｂａｓｅ−ＥＸ、１０００Ｂａｓｅ−ＳＸ、１０００Ｂａｓｅ−ＬＸなどの規格のイーサネット（登録商標）によるトランザクションを行う。ま本発明におけるユーザは、第２のネットワークをスイッチ３４により形成される単位で形成することもできるし、また、プライベートＩＰアドレスなどを動的に割当てて構築されるＩＰアドレス・ベースでネットワーク制御を行う単位として構築することができる。

図２は、本発明で使用するサーバ１２の詳細な構成を示した図である。サーバ１２は、ワークステーションまたは汎用大型コンピュータなどから構成されており、ユーザ・サイトに設置された画像処理装置の保守管理を行うと共に、分散処理の管理を行っている。サーバ１２は、画像処理装置の管理、分散処理の管理を行うソフトウェアを含むアプリケーション層４０と、ユニックス（登録商標）、リナックス（登録商標）、ＷＩＮＤＯＷＳ（登録商標）２００ＸＳＥＲＶＥＲなどのＯＳを含むＯＳ層４４と、ＯＳ層４４とアプリケーション層４０との間でデータ変換などを実行するＡＰＩ（Application Programming Interface)層４２とを備えている。サーバ１２は、上述した構成のもとで、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）などのオブジェクト指向プログラムで記述されたアプリケーションを実行する。なお、本発明では、アプリケーションは、上述したプログラミング言語以外にも、例えば、ＦＯＲＴＲＡＮ、ＰＡＳＣＡＬ、ＣＯＢＯＬなどのプログラミング言語で記述されていても良い。また、ＯＳ層４４の下層には、ＩＤＥ、ＮＩＣ、ＵＳＢ、ＶＧＡなどの外部装置との間の入出力を可能とするインタフェースおよびドライバを含む、Ｉ／Ｏ層４６が構成されている。

サーバ１２には、Ｉ／Ｏ層４６を介して、それぞれ、ハードディスクといった記憶装置４８と、ＬＡＮ、ＷＡＮなどのプライベート・ネットワークである第２のネットワーク３８と、キーボード５２、マウス５４、およびディスプレイ装置５０とが接続されていて、サーバ１２に対するオペレータによる入力操作を可能としている。記憶装置４８には、本発明のジョブ・アービタが管理する画像処理装置の能力などをユーザごとに記録したユーザ管理データと、画像処理装置ごとの能力を登録した画像処理装置データと、分散処理のためにクラスタ・ノードに配布されるジョブを登録したジョブ・リストと、ジョブ・アービタからのレスポンス・メッセージを管理して、配布したジョブの状況を登録する、ジョブ管理データとが格納されている。各アプリケーションは、ランタイム処理に必要なデータを、記憶装置４８からシステム・メモリまたはＲＡＭ（図示せず）に読込ませ、処理を実行する。

図３は、本発明で使用する画像処理装置の例示的構成を示した図である。図３に示した画像処理装置は、図１の複合機２８が備える構成に相当する。複合機２８は、ＡＤＦ（オート・ドキュメント・フィーダ）を備え、複写機、ファクシミリ、プリンタ、メーラなどの複合的な機能を備えている。複合機２８は、各種機能を提供するためのアプリケーションを登録したアプリケーション層６０と、汎用オペレーション・システム（ＯＳ）の下で、各種制御を実行する、制御モジュール層６２と、白黒プリンタ、カラー・プリンタ、ネットワーク接続機能、ハードディスクなどの記憶装置への書込み・読出しを制御するデバイス層６４とから構成されている。また、複合機２８は、外部コンピュータからの入力に応答してプリンタやファクシミリとしても機能する。

汎用ＯＳは、例えば、ユニックス（登録商標）、リナックス（登録商標）などとすることができ、汎用ＯＳの下で機能する、Ｃ、Ｃ＋＋などの手続き型またはオブジェクト指向プログラミング言語による機能制御を可能とする。また、複合機２８は、処理のためのシステム・ライブラリやダイナミック・リンク・ライブラリ（ＤＬＬ）なども必要に応じて備えており、ソース・コードをコンパイルし、ライブラリにリンクさせ、実行ファイルを作成し、必要に応じてＤＬＬを動的リンクして処理を実行する。

また、アプリケーション層６０と制御モジュール層６２とは、ＡＰＩによりインタフェースされ、また、制御モジュール層６２とデバイス層６４との間は、デバイスＩ／Ｆによりインタフェースされている。複合機２８は、ＲＡＭ６６を備えており、ＲＡＭ６６を使用して、複数のジョブを先入れ・先出し式に管理するジョブ・キューを構成している。複合機２８は、さらに図示しないタッチパネル、入力キーなどといった操作パネルまたはディスプレイ装置を含む、ＵＩ（ユーザ・インタフェース）装置６８を備えている。ＵＩ装置６８は、それぞれのインタフェース群を介して複合機２８へとユーザ要求を入力させ、ファクシミリ、モノクロ・コピー、フルカラー・コピーなどの各種の機能をユーザに対して提供している。

複合機２８は、固有の物理アドレス（ＭＡＣアドレス）が付されたＮＩＣを介して、ＬＡＮ内においてデータリンク層レベルでの通信を行う他、例えば図示しないＤＨＣＰサーバ(Dynamic Host Configuration Protocol Server)などにより割当てられたＩＰアドレスまたは固定的に設定されたＩＰアドレスを保有しており、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰなどのネットワーク／トランスポート層プロトコルを使用したトランザクションが可能とされている。また、複合機２８は、ＩＴＵ−Ｕ勧告Ｔ．４、Ｔ．６などの規格で公衆電話網を介し、通信プロトコルＴ．３０、Ｔ．３８、Ｔ．７０などを使用してファクシミリ通信を行う。なお、複合機２８以外の複写機３０、プリンタ３２などについては、複合機２８対応する機能部分を、コストおよび処理能力に応じて備えた構成とされている。

図４は、本発明において、サーバ１２から送付された分散ジョブを仲介し、画像処理装置に配分するジョブ・アービタ２６の機能ブロック図を示す。ジョブ・アービタ２６は、概ね、パーソナル・コンピュータなどを使用して形成することができる。ジョブ・アービタ２６は、例えば、ＰＥＮＴＩＵＭ（登録商標）シリーズ、ＰＥＮＴＩＵＭ（登録商標）互換ＣＰＵなどの復号命令セットコンピュータ、ＰＯＷＥＲＰＣ、ＭＩＰＳなどの縮小命令セットコンピュータなどから選択されるＣＰＵ、システム・メモリ、ＲＡＭ、ＤＲＡＭなどのハードウェアを備えており、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ、ＭａｃＯＳなどのＯＳ上で機能するアプリケーション・プログラムを搭載する。ジョブ・アービタ２６は、本発明の処理を実行するため、アプリケーション・プログラムとして、ＦＴＰクライアント処理部７０と、ジョブ管理部７２と、装置モニタ７４とが実装されている。

ＦＴＰクライアント処理部７０は、ＲＦＣ９５９に規定されたＦＴＰファイル伝送プロトコルにしたがって、サーバとのデータ伝送を処理する。同時に、ＦＴＰクライアント処理部７０は、ＦＴＰプロトコルと、ジョブ・アービタ２６が第２のネットワーク３８を介して通信するファイルとの間のフォーマット変換処理を行って、データまたはリクエスト／レスポンスを処理している。さらに、本発明の別の実施の形態では、ＦＴＰクライアント処理部７０は、電子証明書を使用した認証処理またはＳＳＬ暗号化／複合化処理を行う手段を備え、サーバ１２から受信した分割ジョブを復号し、以後の処理を実行する。

また、サーバ１２に対して実行結果を送信する場合には、ＦＴＰクライアント処理部７０は、サーバ１２に対して送信する実行結果を暗号化して送信する処理を実行する。なお、本発明では、サーバ−ジョブ・アービタ間の暗号化処理としては、これまで知られたいかなる方式でも使用することができ、公開鍵／秘密鍵を使用する暗号化方式、共有鍵方式などを使用することができる。本発明のジョブ・アービタ２６は、ＦＴＰクライアント処理部７０が定期的にサーバ１２に対し、ジョブ引受けが可能であることを示すＦＴＰリクエストを定期的にポーリングして、サーバ１２からのジョブ依頼を待機する。

ジョブ管理部７２は、サーバ１２から渡された分割ジョブの画像処理装置による処理の管理を行う。ジョブ管理部７２は、サーバ１２からジョブを渡されると、第２のネットワーク３８に接続された複合機２８などの画像処理装置へと処理を依頼して、その処理状態を監視する。ジョブ・アービタ２６は、画像処理装置からの実行結果が返されると、実行結果に応答して、さらにジョブを渡したり、サーバに結果を伝送したりする処理を行っている。

また、装置モニタ７４は、第２のネットワーク３８に接続された画像処理装置の状態を監視して、ジョブを配布できるかどうかを判断する。この際、装置モニタ７４による画像処理装置の監視は、例えば、ＰＩＮＧ／ＩＣＭＰプロトコルを使用して行うことができる。さらに、ジョブ・アービタ２６は、インタフェース７６を含んでおり、それぞれのインタフェース／ドライバを介して記憶装置７８、第２のネットワーク３８、キーボード８２、マウス８４、ディスプレイ装置８０との間で入力および出力を可能としている。

ジョブ・アービタ２６と複合機２８などの画像処理装置との間の通信は、種々のプロトコルで行うことができ、例えば、ジョブ管理部７２と画像処理装置との間は、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなどのプロトコル・スイートにしたがったsocket通信とすることができる。また、本発明では、ジョブ・アービタ２６と画像処理装置との間のトランザクションは、ＬＡＮといったプライベート・ネットワーク内でのローカル・トランザクションなので、コネクションレス型のファイル転送プロトコルであるＴＦＴＰを使用し、ＵＤＰベースでの簡易ファイル伝送プロトコルを使用することもできる。さらに、本発明では、ＨＤＬＣ、ＰＰＰなどのフレーム・ベースでのデータリンク・レベルのプロトコルを使用したデータ伝送を使用することもできる。

図５は、本発明の処理および処理を構成するジョブの構成を示す。なお、本発明で「処理」とは、サーバ側がクラスタ・ノードに対して依頼を行う、サーバで必要とする値を返す処理全体を意味する。「ジョブ」とは、処理を構成するオブジェクト、外部関数など、独立して返り値を生成することができる処理単位を意味する。また、「分割ジョブ」とは、互いに代入・参照関係にある複数のジョブからなる処理単位を意味する。

図５では、本発明によりサーバ１２が、クラスタ・ノードに依頼する処理を、複数のジョブ単位として、その階層構造を示す。最終的な結果を得たい処理は、Ｆ（）であり、処理Ｆ（）は、ジョブＧ（）、Ｈ（）、Ｉ（）〜Ｌ（）の複数のジョブから構成されている。ジョブＩ（）〜Ｌ（）は、データＡ〜Ｄを使用して結果を生成し、それぞれ上位階層のジョブＧ（）、Ｈ（）に結果を渡す。また、ジョブＧ（）、Ｈ（）は、渡された結果を使用して結果Ｘ、Ｙを生成し、ジョブＦ（）へと、結果Ｘ、Ｙを渡して目的とする値Ｚを生成する。すなわち、図５に示した処理は、代入／値参照構造から見た深度が、３階層となっているということができる。なお、図５では、各ジョブの階層構造は、各ジョブの深度に応答して深度１ジョブ・レベル、深度２ジョブ・レベル、深度３ジョブ・レベルとして降順にランク付けして示している。下記式（１）には、本発明における処理の実施を構成するジョブの形態を示す。

本発明では、上述した処理Ｆ（）のソース・コードは、例えばＣ、Ｃ＋＋、ＪＡＶＡ（登録商標）などを使用して記述することができる。サーバ１２は、ソース・コードが入力された段階で、テキスト・パーサなどを使用して処理Ｆ（）の構文解析を実行し、コンパイル処理を実行する前にその参照・代入構造を判断し、図５に示した木構造を生成する。なお、この処理のためには、これまで知られたいかなるテキスト・パーサでも使用することができる。テキスト・パーサにより生成された木構造は、例えば、下記式（２）に示すデータ構造として、サーバの適切なメモリ領域に格納される。

上記式（２）中、{}内に含まれるジョブが処理を構成し、１〜３がジョブ階層を示し、（）内が同一深度レベルにあるジョブを示し、「｜」は、ジョブおよびデータの独立性を示す識別値として使用されている。また、サーバは、これらのジョブがどの単位ででも処理依頼できるような形式とされたソース・コードとして、適切な記憶領域に生成されたジョブ・リストに当該ジョブのジョブ識別値job_idと共に格納している。なお、本発明では、階層構造を記述することができるデータ・フォーマットである限り、木構造を記述するためにいかなるフォーマットでも使用することができる。また、上述したジョブは、サーバ内では、クラスタ・ノードにおいて実行形式の実行ファイルを生成することができる形式として、それぞれ別個の単位のソース・コードとして記述されて、ジョブ・リストに登録することもできるが、それぞれ分割コンパイルされた形式で格納しておくこともできる。この場合には、ジョブ・アービタおよび画像処理装置のコード互換性に応答して、ジョブ・アービタまたは画像処理側で、リンクを実行し、実行形式ファイルを生成し、実行する。

テキスト・パーサは、分割ジョブを決定する場合、上記式（２）の左手側（ファイル先頭に相当するものとする。）から順次、ジョブ識別値を呼出し、木構造のトップ・ノードであることを識別し、記号「（」が見出された段階で第２階層には並列関係にあるジョブが存在し、それらがＧ、Ｈであることを判断し、順次同様の関係で木構造を認識して行く。その後、以下に説明するサブツリーのトップ・ノードとして選択されるべき階層のジョブを取得し、サブツリーの木構造に対応するジョブ識別値を順次ファイルに書出して、サブツリー・データ構造を作成する。例えば、本発明の特定の実施の形態において、分割ジョブをＧ以下およびＨ以下として定めるべき場合には、サブツリー・データ構造は、下記式（３）として与えられる。

本発明では、サーバ１２は、ジョブ・アービタ２６からのリクエストに応じて上記式（３）により定義される分割ジョブを決定し、ジョブ・アービタ２６へと伝送する。この場合、サーバ１２が保有するジョブ・リストには、各ジョブ単位にソース・コードを登録しておき、分割ジョブのレベルが決定された時点で、送信バッファ内に分割ジョブとして蓄積して、ジョブ・アービタに伝送することができる。

また、本発明の熱の実施の形態では、各ジョブのソース・コードとは別に、ジョブ・リスト内には、最終的な処理Ｆ（）と分割ジョブとをソース・コードのセットとして保持させておくこともできる。

図６には、上述したジョブを登録したジョブ・リストを示す。図６に（ａ）示す特定の実施の形態では、ジョブ・リスト８８は、処理の木構造を、ジョブ単位に識別し、最上層のジョブを基点として上層レベルから下層レベルへと登録が行われている。ジョブ・リストは、ジョブに付されたジョブ識別値job_idと、対応するソース・コード識別値source_idと、分割ジョブを指定する識別値job_set_idをリストしている。ジョブ識別値job_idは、サーバ１２がソース・コードなどを送付する際のアドレスなどを識別するために使用され、ソース・コード識別値source_idは、当該ソース・コードが格納されているメモリまたはハードディスクのアドレスを識別するために使用される。また、分割ジョブを指定する識別値job_set_idは、分割ジョブとして識別されたジョブ・セットを同一のジョブ・アービタに伝送するための識別値として機能する。

また、図６（ｂ）に示したジョブ・リスト８８は、処理Ｆ（）と、分割ジョブＧ（）、Ｈ（）とがjob_idにリストされており、ソース・コード識別値のフィールドには、その中に含まれるソース・コードを識別するための複数のソース・コード識別値のセットが記述されている。図６に示した実施の形態の場合、処理Ｆ（）と分割ジョブＧ（）、Ｈ（）とがリストされているだけなので、job_set_idは、特に必要ではない。なお、本発明の他の実施の形態では、上述した処理は、サーバのオペレータがソース・コードを分析してコンピュータに登録することができる。

図６（ａ）に示した実施の形態では、サーバ１２は、ジョブ識別子job_idに対応して登録されたそのソース・コードを格納するアドレス範囲を参照してジョブとそれに対応するソース・コードとを対応づける。また、識別値job_set_idは、分割ジョブを構成するジョブからなるサブツリーのグループを識別する。サーバは、分割ジョブを画像処理装置に送信する場合、サブツリーを構成するジョブおよびデータを選択し、順次送信バッファに伝送して送信パケットを生成し、必要に応じて電子証明書またはＳＳＬによる暗号化処理を施した後、ＦＴＰパケットとして画像処理装置へと送出する。

また、図６（ｂ）に示した実施の形態では、配布するべきジョブ・アービタ２６が決定された後、当該ジョブ・アービタ２６の宛先に宛てて、分割ジョブを構成するソース・コードとジョブ属性とを識別して、まとめて送信バッファに書込み、宛先に宛てて送信する処理を実行する。

図７は、サーバ１２が含むジョブ管理データ９０の実施の形態を示した図である。サーバ１２は、記憶装置４８およびジョブの配布処理を実行している間には、ＲＡＭなどの実行メモリ内に、配布したジョブの状態を反映させたジョブ管理データ９０を読出し、ジョブ・アービタからのレスポンスを管理する。図７に示したジョブ管理データ９０は、深度１レベル・ジョブ９２、深度２レベル・ジョブ１００、深度３レベル・ジョブ１０２をリストするフィールドを有しており、それぞれ、ジョブＦ、ジョブＧ、ジョブＨ、ジョブＩ〜Ｌがエントリされている。また、ジョブ管理データ９０は、依頼先ジョブ・アービタに対し分割ジョブがすでに割当てられているか否かを示す資源利用可能識別値９６と分割ジョブが割当られる依頼先ジョブ・アービタ識別値９８とをリストする。

なお、図７に示した実施の形態では、未だジョブ・アービタへの分割ジョブの割当が行われていない状態を示しているので、ジョブだけが登録された状態とされ、他のエントリは、ブランクとされている。本発明で使用するサーバ１２は、以下に説明した処理に基づいて、図７に示したジョブ管理テーブルのエントリに各値を登録する処理を実行する。

図８は、本発明において、サーバ１２が配布先を決定する処理を示したフローチャートである。図８に示した処理は、ステップＳ１００から開始し、サーバ１２が、各ジョブについてのジョブ属性を登録する。図９には、ジョブ属性１１０を示す。ジョブ属性１１０は、当該ジョブが要求する使用資源量、処理のために使用するライブラリなど規定する処理種類、処理納期、納期前にジョブの終了を指令するためのジョブ終了条件、画像処理装置の資源を利用したことに応答した割引率などをリストした要求資源１１２と、それらの内容を記述したデータ・リスト１１４とを含んでいる。サーバ１２は、これらの登録が終了すると、ステップＳ１０１において、ジョブ・アービタの提供可能資源データと使用資源量とを計算し、ジョブを配布できるジョブ・アービタを選択する処理を実行する。

この処理では、サーバ１２は、画像処理装置データと、ユーザ管理データとを使用する。図１０には、画像処理装置データを示し、図１１は、ユーザ管理データの実施の形態を示す。なお、本発明において参照する「使用資源量」とは、対象となるジョブの要求する計算量の見積もり値を意味する。使用資源量は、プログラムの行数、四則演算の数、分岐判断の数、指数・対数演算の数などについてソース・コードをスコアリングし、ジョブについて総和したものを使用することができるし、また、ビックオー記法により与えられるオーダを、使用するデータ量などを考慮してソース・コードごとに割当てた値を使用することができる。

図１０を参照すると、画像処理装置データ１１６は、画像処理装置の識別値１１８と、処理能力１２０とを含んで構成されている。識別値１１８には、画像処理装置の形式などを示す識別値がエントリされ、また、処理能力１２０には、画像処理装置の識別値に対応した処理能力がエントリされている。処理能力は、例えば、画像処理装置が搭載するＣＰＵのクロックレート、キャッシュ・メモリ容量、ＲＡＭ容量、インタフェース・グレードなどの値を使用し、処理能力の高い装置に対して高い値を設定することができる限り、いかなる指標を使用して設定することができる。なお、図１０に示した処理能力は、上述の値を使用して算出された絶対値を、適切な定数で単位時間あたりに規格化して表した値である。

図１１には、ステップＳ１０１の処理において使用するユーザ管理データ１２２の実施の形態を示す。図１１に示すようにユーザ管理データ１２２は、ユーザ識別値１２４と、ジョブ・アービタ識別値１２６と、提供可能資源データ１２８とをエントリしている。本発明の特定の実施の形態では、ユーザＡＡＡは、ジョブ・アービタＲＣ−ＧＡＴＥ−０１を管理しており、ジョブ・アービタＲＣ−ＧＡＴＥ−０１が提供できる総資源量を示した提供可能資源データの値は、提供可能資源データ１２８にエントリされている。

図１１に示した提供可能資源データ１２８の値は、サーバ１２がまず、ジョブ・アービタＲＣ−ＧＡＴＥ−０１が管理する画像処理装置種別フィールドに対応する処理能力を、図１０に示す画像処理装置データをルックアップして取得する。さらに、サーバ１２は、保守データから当該画像処理装置が画像処理などに使用されていない時間を取得して、１日あたりの装置遊休時間の値を取得し、遊休時間フィールド１３２にエントリする。さらにサーバ１２は、提供可能資源データ１２８を、画像処理装置データの値と遊休時間フィールドにエントリされた値とを乗算し、画像処理装置について合計した値として生成する。本発明では、装置遊休時間の値は、保守データを使用して、例えば、週間平均、または月平均などに基づき随時更新することができ、ユーザの画像処理装置の使用状況に応答し、特定の配布先が常に固定した配布先として設定されないように、ジョブの配分を設定することができる。下記式（４）に、提供可能資源データの算出式の実施の形態を示す。

上記式（４）中、画像処理装置∈ジョブ・アービタの記号は、ジョブ・アービタが管理する画像処理装置全体について総和することを意味する。なお、本発明では、上記式（４）以外のいかなる尺度を使用して提供可能資源データを算出することができる。図１０および図１１に示したデータを使用して得られた提供可能資源データ１２８は、ステップＳ１０２において、図９に示したジョブ属性にエントリされた処理納期データと共に、ジョブを当該ジョブ・アービタに配布できるかどうかの判断に使用される。このためには、ジョブ属性として登録した使用資源量が、処理納期といった所定期間内に当該ジョブ・アービタにより提供されるか否か、およびユーザがその提供を認めているか否かを判定することが必要となる。この判定のため、本発明の特定の実施の形態では、下記式（５）を使用して、処理納期内に提供可能な資源量とジョブ属性の使用資源量とを比較する。

上記式（５）による比較により、利用可能なジョブ・アービタが選定される。使用可能なジョブ・アービタが存在する場合（ｙｅｓ）には、ジョブ・アービタの識別値を取得し、適切なメモリに形成したリストにエントリして、ステップＳ１０３の処理を実行する。また、使用可能なジョブ・アービタが存在しない場合（ｎｏ）には、ステップＳ１０６で納期の延長などを行うか否かを判断し、納期変更により対応する場合（ｙｅｓ）には、ステップＳ１００に処理を分岐させ、ジョブ属性の処理納期データを延長して再度処理を実行する。また、納期延長では対応できない場合には、ジョブ・アービタの選定・登録処理を終了する。

ステップＳ１０３では、サーバは、ジョブ・アービタのユーザごとに、ユーザとの取決めにより設定された提供資源量とそれに対応する割引料金とを登録したルックアップ・テーブルを検索する。図１２は、本発明で使用する保守契約に含まれる資源提供データの部分を使用して、ルックアップ・テーブルとして与えられ、割引料金テーブルとしてサーバが管理するデータである。図１２に示すように、ルックアップ・テーブル１３６には、ユーザと、提供資源量と、提供資源量ごとに定めた割引率が登録されている。提供資源量は、分割ジョブのために使用したＣＰＵ時間abc、def、ghi、などに対応して割引料金が定められている。サーバ１２は、ジョブの使用資源量または実際に提供された提供資源量とユーザとを検索キーとして、ユーザがジョブの要求する提供資源量の契約を行っているか否かの検索を実行する。

ステップＳ１０４では、検索結果に応答して、処理対象となるジョブが、処理依頼契約がなされた範囲であるか否かを判断する。処理依頼契約がなされた範囲にある場合（ｙｅｓ）には、一次処理納期をジョブ属性に設定された値とし、ステップＳ１０５で当該ジョブ・アービタを、分割ジョブが配布可能であるものとしてリストに登録する。また、処理依頼契約がなされた範囲にない場合（ｎｏ）には、登録処理を終了し、他のジョブ・アービタについての検索を実行させる。この場合、使用されるルックアップ・テーブルには、処理提供上限量、納期下限時間、割引料金設定範囲などを登録しておくことができる。また、本発明における特定の用途において、これら以外の値が必要な場合には、適宜ルックアップ・テーブルに追加することができる。

この段階で、サーバ１２には、ジョブを配布する可能性のあるジョブ・アービタのリストが保有される。その後、サーバ１２は、図７に示したジョブ管理テーブルに対して、所定のフィールドにエントリするデータを生成し、各フィールドにてエントリして行く。図１３は、ジョブ管理テーブルを更新する更新処理のフローチャートを示す。図１３に示した更新処理は、ステップＳ２００から開始し、分割処理する処理と、その深度とを取得し、処理の木構造の分割判定を行う。

ステップＳ２０１で図１１の処理で生成されたリストをルックアップして、使用可能なジョブ・アービタの台数をカウントし、カウント値が０を超えるか否かを判断する。ステップＳ２０１の判断において、使用できるジョブ・アービタの台数が０である場合（ｎｏ）には、ステップＳ２０７へと処理を分岐させて、ジョブ・アービタが利用可能になるまで、処理を中断または待機させる。以下の説明では、説明の便宜上、その時点で使用できるジョブ・アービタの台数は、２台であるものとして説明を行う。

使用できるジョブ・アービタの台数が１以上の場合（ｙｅｓ）には、ステップＳ２０２へと進み、処理を構成するジョブの深度が１または２であるかを判断する。深度が２よりも深い場合（ｎｏ）には、まず、ステップＳ２０８へと進み、もっとも深い深度まで下りジョブをカウントアップする。本発明の特定の実施の形態では、式（２）で示されるデータ構造の深度指標＝３のジョブをカウントし、使用できるジョブ・アービタの台数と比較し、使用できるジョブ・アービタの数が分割ジョブ数以上か否かを判断する。ステップＳ２０９の判断で、待機しているジョブ・アービタの台数が分割ジョブ数よりも少ない場合（ｎｏ）には、ステップＳ２１１で深度を１レベル上げて同一深度のジョブ数をカウントし、再度処理をステップＳ２０９の判断に分岐させる。

また、本発明の説明している実施の形態では、深度２レベルは、Ｇ、Ｈの２ジョブとなるのでステップＳ２０９の判断が肯定的な値を返し（ｙｅｓ）、ステップＳ２１０へと処理を分岐させ、当該レベルのジョブを分割ジョブのサブツリーのうちの、トップ・ノードとして選択する。なお、本発明では、上述した処理を、使用可能なジョブ・アービタの数以下となるまで繰返し、できるだけ多くのジョブ・アービタに処理を依頼できるようにサブツリーを決定する。その後、サブツリーのトップ・ノード以下のジョブを、分割ジョブを構成するジョブであるとして、式（３）のサブツリー・データを生成し、図６（ａ）の実施の形態では、ジョブ・リスト８８のjob_set_idにエントリする。また、図６（ｂ）に示した実施の形態では、ジョブ・リストにエントリするべき分割ジョブを決定する。一方、サブツリーのトップ・ノードよりも高いレベルのジョブについては、サブツリーの返り値が得られない限り実行できないので、ステップＳ２１０において、ジョブ管理テーブルの該当するジョブに待機フラグを設定し、処理をステップＳ２０３に分岐させる。

ステップＳ２０３では、図１１の処理で生成したリストから利用可能なジョブ・アービタの値を検索し、分割ジョブの合計資源使用量と、当該ジョブ・アービタの処理納期までに提供できる提供可能な資源量とを比較して、ジョブ・アービタの資源提供能力を超えないジョブ・アービタを選定する。その後、サーバ１２は、ジョブ管理データ９０の依頼先ジョブ・アービタ識別値に当該選択された識別値をエントリする。さらに、その後、サーバ１２は、サブツリー・データにエントリされたソース・コードおよびデータを順次出力バッファに書込み、選定されたジョブ・アービタを宛先としてＦＴＰプロトコルを使用して伝送する。

同時に、サーバ１２は、ジョブ管理テーブルの該当するジョブ・アービタの資源利用可能識別値のステータスについて、使用中を示す値「０」に設定する。なお、ステップＳ２０３の処理において分割ジョブのサブツリーをジョブ・アービタに割当てる場合には、分割ジョブ全体の使用資源量を計算し、使用資源量の多いサブツリー順に、提供可能な資源量の多いジョブ・アービタへと配布する処理を採用することで、ジョブ・アービタの処理能力に対して均等にジョブを配布することが可能となる。その後、サーバは、ステップＳ２０４へと処理を分岐させ、ジョブ・アービタからの実行結果を受取る。

図１４は、本発明の上記処理が完了した段階でのジョブ管理テーブルの実施の形態を示す。図１４に示した実施の形態では、深度１レベル・ジョブは、深度２レベル・ジョブの返り値がない限り処理ができないので、待機フラグとしては、待機フラグ＝１の値が設定されている。また、深度１レベル・ジョブは、その処理をクラスタ・ノードに配布していないので資源利用可能識別値９６、依頼先ジョブ・アービタ識別値９８、深度２ランク・ジョブ１００、深度３ランク・ジョブ１０２は、ｂｌａｎｋのままとされる。

一方、深度２ランクのジョブＧ、Ｈは、図１３に説明した処理によって配布先のジョブ・アービタが選択され、分割ジョブを送信単位として、該当するジョブ・アービタに配布される。資源利用可能識別値９６には、配布に対応して、当該ジョブ・アービタが処理引受け中であることを示す識別値である「０」が記入され、同時に、依頼先ジョブ・アービタ識別値９８にジョブ・アービタの識別値が記入される。この段階で、サーバ１２は、図１３のフローチャートにおけるステップＳ２０４において配布した分割ジョブの実行結果を待機している。

実行結果が戻されると、サーバは、当該処理の処理結果を判断し、処理成功を示す値が戻された場合には、資源利用可能識別値、依頼先ジョブ・アービタ識別値、深度２ランク・ジョブ深度３ランク・ジョブの値をｂｌａｎｋにリセットし、後続する処理を実行する。また、ジョブ属性に指定した処理納期内に処理成功を示す値が戻されない場合には、再度依頼を行うか、または当該ジョブ・アービタに対する処理依頼をキャンセルし、他の遊休ジョブ・アービタを検索し、分割ジョブを依頼する処理を実行する。また、ジョブ・アービタ２６は、それまでに画像処理装置の提供した提供資源量を例えばＣＰＵ占有時間などの値としてサーバへと返し、割引量を決定することができる。

再度、図１３について説明すると、サーバ１２は、ステップＳ２０５で、待機フラグが設定された待機ジョブがあるか否かを判断する。説明している実施の形態では、深度１ランク・ジョブは、この段階で待機フラグが設定されたままである。このため、サーバ１２は、ステップＳ２０５で待機ジョブがあると判断し（ｙｅｓ）、ステップＳ２１３へと処理を分岐させ、待機解除条件を満足するか否かを判断する。本発明では、待機解除条件とは、待機ジョブの直下のサブツリーのトップ・ノードの返り値がすべて与えられていることを意味する。ステップＳ２１３の判断が肯定的な値を返す場合（ｙｅｓ）、ステップＳ２１２へと進み待機フラグを非待機状態である値「０」に設定し、ステップＳ２０３へと処理を戻し、待機ジョブをジョブ・アービタに配布し、処理を依頼する。また、ステップＳ２０５の判断が否定的な値を返す場合（ｎｏ）には、目的とする処理Ｆ（）を含めて処理全体の返り値が戻されているので、ステップＳ２０６へと進んで、サーバ側の処理を終了する。

図１５は、本発明のジョブ・アービタ２６の実行する処理のフローチャートを示す。ジョブ・アービタ２６は、ステップＳ３００でサーバからの分割ジョブを、分割ジョブを構成するジョブのジョブ属性と共に受取る。分割ジョブは、少なくともジョブＧまたはジョブＨなどの処理が実行できるジョブ（Ｉ、Ｊ）、データ（Ａ、Ｂ）、またはジョブ（Ｋ、Ｌ）、データ（Ｃ、Ｄ）というセットとして、ＦＴＰリプライのフォーマットで各ジョブ・アービタ２６に送付される。ジョブ・アービタ２６は、プロトコル変換、および必要に応じて電子証明書またはＳＳＬによる復号処理を実行して各ジョブのデータを取得する。

その後、ステップＳ３０１で、取得したジョブ属性データから処理納期を参照して処理納期が満了していないかどうかを判断し、処理納期が満了した場合（ｙｅｓ）には、ステップＳ３０７へと処理を分岐させ、処理中の画像処理装置に対して処理中止指令を発行する。また、処理納期が満了していないと判断された場合（ｎｏ）には、ステップＳ３０２へと処理を進め、当該ジョブ・アービタが管理する画像処理装置にジョブを配布して処理を開始させ、画像処理装置からのリプライを待機する。ステップＳ３０３では、ジョブ・アービタ２６は、画像処理装置からのジョブの処理結果を受取り、ステップＳ３０４でジョブ終了条件を満たすか否かを判断し、ジョブ終了条件を満たす場合（ｙｅｓ）には、処理中の画像処理装置に中止命令を発行し、処理を中断させる。

ステップＳ３０４の判断がジョブ終了条件を満たさない場合には、正当な処理結果が返されているので、ステップＳ３０５で当該処理結果を使用して処理を進める未処理ジョブが存在するか否かを判断する。未処理ジョブが存在しない場合（ｎｏ）には、処理は、ステップＳ３０８に分岐し、画像処理装置からの処理結果を所定のフォーマットとし、ステップＳ３０９で、ＦＴＰレスポンスとしてサーバに送信する。納期前であれば、それまでのＣＰＵ占有時間の総和などの提供資源量を示す値などと共に実行結果を返す。このとき、本発明の特定の実施の形態では、電子証明書またはＳＳＬによる暗号化処理を行った後にサーバに対して送信を行う。一方、ステップＳ３０５の判断で未処理ジョブがあると判断された場合、ステップＳ３０１へと処理を分岐させ、処理納期が満了しているか否かを判断し、その判断に応答して未処理ジョブの画像処理装置による処理、またはサーバに対して中間結果を送付する処理を実行させる。

また、ステップＳ３０６は、サーバ１２が、例えば、中間納期を設定しておき、中間納期までに成功を示す実行結果が得られない場合に、処理を中止させる指令を行う実施の形態である。ステップＳ３０６で中止指令を受取ると、ジョブ・アービタは、画像処理装置による処理を強制的に終了させ、その時点までの中間結果を、例えば、サーバがその状態を認識できるように構成した一時ファイルなどの形式として、ステップＳ３０８、ステップＳ３０９の処理を経てサーバに送信し、その後の処理の実行依頼を待機する。

図１６は、図１５の処理のステップＳ３０２の詳細を示すフローチャートである。ジョブ・アービタは、ステップＳ４００で分割ジョブを最小単位に分割し、ステップＳ４０１で分割したジョブの処理ストリームから待機させることが必要なジョブを検索し、待機フラグを設定する。ステップＳ４０２では、管理対象である画像処理装置のステータスを、ＰＩＮＧ／ＩＣＭＰエコーのＲＴＴ（ラウンド・トリップ・タイム）など、または、図３で示したジョブ・キューにエントリされた他のジョブの状態を監視して、画像処理装置のステータス情報を取得する。

ステップＳ４０３では、ステップＳ４０２で取得したステータス・データを使用してジョブ配布が可能な画像処理装置の数をカウントし、カウンタ＞０であるか否かを判断する。ステップＳ４０３の判断が否定的な値を返す場合（ｎｏ）には、ステップＳ４０８で配布処理を中止するか、またはカウンタ＞０の値となるまで、Ｓ４０２に処理を戻す。

ステップＳ４０３の判断が肯定的な値を返す場合（ｙｅｓ）には、処理をステップＳ４０４へと分岐させ、画像処理装置に待機ジョブを除くジョブを転送し、ステータスに、「処理中」を示すフラグを設定する。図１７には、ジョブ・アービタが管理する管理テーブル１３８を示す。ジョブ・アービタが管理する管理テーブル１３８には、画像処理装置に処理を依頼するジョブジョブの識別値と、処理フラグと、待機フラグと、各ジョブの終了を示す終了フラグとがエントリされている。ジョブ・アービタが処理を画像処理装置に依頼すると、処理フラグは、処理中を示す値「１」に設定され、それ以外のジョブについては、処理終了および未依頼のジョブを含め処理中ではないフラグ「０」が設定される。また、すでに処理が終了して返り値が戻されている場合には、例えば、ジョブI（）の結果については、終了フラグが「１」として設定されているので処理が終了したものと判断される。また、ジョブＪ（）については、処理は開始されているものの、実行結果が未だ得られていないことが示されている。さらに、ジョブＧ（）は、まだ処理が開始されておらず、また待機中であると判断される。

ステップＳ４０５では、画像処理装置からのジョブの結果を受取り、ステップＳ４０６の判断を実行する。ステップＳ４０６では、待機ジョブがあるか否かを、待機フラグを検索して判断し、待機ジョブがある場合（ｙｅｓ）には、ステップＳ４１０で待機ジョブが使用する返り値があるか否かを判断し、待機ジョブが使用する返り値がすべて揃うまでステップＳ４０５、ステップＳ４０６の処理を実行する。また、ステップＳ４１０で待機ジョブが使用する返り値がすべて揃った（ｙｅｓ）との判断に応答して、ステップＳ４０９に処理を分岐させ、待機フラグを解除して、再度、ステップＳ４０２〜ステップＳ４０６の処理を実行させ、待機ジョブがなくなった時点で、ステップＳ４０７において図１５のステップＳ３０８へと処理を渡す。

図１８は、本発明の分散処理システムにおけるサーバ−ジョブ・アービタ間のトランザクションのシーケンスを示した図である。図１８では、ジョブ・アービタ１は、画像処理装置α、βを管理しており、ジョブ・アービタ２は、画像処理装置ε、δを管理しているものとして以下、説明を行う。ジョブ・アービタ１およびジョブ・アービタ２は、サーバ１２から分割ジョブの依頼を受けていない限り、定期的にサーバに対してＦＴＰリクエストjob_inquiryをポーリングする。サーバ１２は、当該ポーリングを受付けると分割ジョブをＦＴＰレスポンスとして伝送する。この際、ジョブ・アービタは、ユーザ識別値およびパスワードなどの識別・認証データを予め伝送し、その正当性をサーバに対して証明する。

サーバ１２は、分割ジョブをjob_response {X(), G(), I(), J(), A, B}およびジョブ属性を含むパケットとしてジョブ・アービタ１へと伝送する。本発明の説明している実施の形態では、job_responseを、特に暗号処理を施すことなくそのまま伝送することができる。また、本発明の別の実施の形態では、予めユーザが取得しておいた電子証明書を、サーバ側で登録し、電子証明書の認証ができた場合に、サーバが暗号化処理を施して分割ジョブを伝送することもできる。この場合、ジョブ・アービタ詐称によるデータの不正取得を防止することができる。また、本発明のさらに他の実施の形態では、サーバ側で、ＲＦＣ２２４６として規定されているＳＳＬ(Server
Socket Layer)プロトコルを使用して暗号化処理を行った後、伝送することができる。本発明では、ジョブ・アービタは、セッション層およびトランスポート層の境界を通過する際に復号処理を実行し、アプリケーション側には負担をかけずにデータ・セキュリティを保証することができる。

ジョブ・アービタ１およびジョブ・アービタ２は、図１４〜図１７において説明した処理を画像処理装置に実行させた後、その処理結果をＦＴＰリプライ・パケットcomplete_ack:X、complete_ack:Yなどとしてサーバ１２に伝送する。サーバ１２は、当該ＦＴＰリプライ・パケットの内容を判断し、それまで待機していたジョブＦ（）を、取得したそれぞれの返り値Ｘ、Ｙと共に、適切なジョブ・アービタ、例えば、ジョブ・アービタ１に伝送する。その後、ジョブ・アービタ１は、ジョブＦ（）の結果をcomplete_ack:Fなどのパケットとして戻し、サーバ１２が最終的な処理Ｚの値を取得する。

図１９は、本発明のジョブ・アービタ１と画像処理装置α、βとの間のトランザクションのシーケンスを示した図である。ジョブ・アービタ１は、図１６に示した処理が終了した段階で、画像処理装置αに対してＴＣＰ／ＩＰまたはＵＤＰ／ＩＰレベルのソケットjob_request: I(), Aを伝送する。同時に、画像処理装置βに対してソケットjob_request: J(), Bを伝送する。画像処理装置αは、当該ソケットを受信して、ジョブＩ（）から実行形式ファイルを作成しオブジェクトを起動して処理を開始する。ジョブＩ（）の処理が終了した段階で、その結果Ｓをソケットjob_response:Sとしてジョブ・アービタ１に返す。また、本発明では、ジョブ・アービタと画像処理装置との間においては、ＴＦＴＰ等のプロトコルを使用してトランザクションを行うことも可能であるし、パケットではなく、フレームを使用し、ＰＰＰなどのデータリンク層レベルでのセッション・プロトコルに基づき、レイヤ２レベル・スイッチ内でローカライズしたトランザクションを確立させることもできる。

また、画像処理装置βは、job_request: J(), Bを受信すると、同様の処理を実行して、オブジェクトＪ（）を起動し、処理完了後、ソケットjob_response:
Tをジョブ・アービタ１に伝送する。ジョブ・アービタ１は、それぞれの結果の正当性を判断し、待機させていたジョブＧ（）を、その使用する返り値Ｓ、Ｔ
と共に画像処理装置αに伝送する。画像処理装置αは、オブジェクトＧ（）を起動して処理を実行し、その結果をソケットjob_response:Xとしてジョブ・アービタ１に伝送し、画像処理装置α、βとのトランザクションを終了させる。その後、ジョブ・アービタ１は、ＦＴＰリプライ・パケットcomplete_ack:Xを生成してサーバ１２に対して伝送する。

図２０は、ジョブ・アービタ２と画像処理装置ε、δとの間のトランザクションのシーケンスを示した図である。ジョブ・アービタ２は、サーバ１２から、分割ジョブＨ（）、Ｋ（）、Ｌ（）が伝送されており、それぞれについて、図１７において説明した処理を終了させた後、画像処理装置ε、δにジョブを配布する。画像処理装置ε、δは、それぞれ処理を実行し、それぞれの実行結果をjob_response:W, :Vとして返す。ジョブ・アービタ２は、各画像処理装置からの結果を受取って処理を実行し、complete_ack:Yを作成してサーバ１２に伝送する。サーバ１２では、complete_ack:Xおよびcomplete_ack:Yの両方のパケットを受信した段階で、ジョブＦ（）の待機フラグを解除し、図１６で説明した通りにＦ（）、Ｘ、ＹをＦＴＰレスポンス・パケットとして適切なジョブ・アービタに伝送する。この場合、ジョブ・アービタの選択は、使用資源量およびジョブ・アービタの提供可能な資源量に応答して適切なジョブ・アービタ、説明している実施の形態では、ジョブ・アービタ１を選択して伝送する。

図２１は、ジョブ・アービタからの処理を受取った後のサーバ側における処理のフローチャートを示す。サーバ１２は、ステップＳ５００でジョブ・アービタからcomplete_ackパケット、またはジョブ・アービタからのジョブ終了条件満了を通知するstopped_ackを受信すると、該当するジョブ・アービタの資源利用可能識別値を使用可能に対応する値「１」に設定し、ステップＳ５０１でサーバが管理する未処理のジョブのうち、待機フラグが設定されていないジョブが存在するか否かを判断する。その後、未処理ジョブがある場合（ｙｅｓ）、ステップＳ５０２でジョブ終了条件を満たしたことによる終了であるか否かを判断し、例外終了ではない場合（ｎｏ）には、ステップＳ５０３で未処理のジョブを適切なジョブ・アービタに伝送し、処理を開始させる。

また、ステップＳ５０２の判断でジョブ終了条件であると判断された場合（ｙｅｓ）、ステップＳ５０４へと処理を分岐させ、処理残量を見積もり、新たな処理納期を設定し、新たにジョブ・アービタ（同一でも異なっていても良い）に該当する処理を依頼し、処理が完了するまでステップＳ５００〜ステップＳ５０４の処理を繰り返す。

一方、ステップＳ５０１の判断で未処理のジョブがないと判断された場合（ｎｏ）には、ステップＳ５０５へと処理を分岐させ、処理結果をメモリに格納し、サーバ側での使用に備えると共に、資源提供に応答した割引料金を決定する。ステップＳ５０６では、決定された割引料金を処理登録者に送信し、次回以降の画像処理装置管理／保守費用から割り引くことを通知する。

図２２は、本発明の分散処理システムの実施の形態を示した図である。サーバ１２は、本発明にしたがい処理を分割ジョブとしてジョブ・アービタ２６ａ、２６ｂへと伝送する。この場合、伝送プロトコルとしては、ＦＴＰプロトコルを使用することもできるし、グリッド用に規定が検討されているＧｒｉｄＦＴＰなどを使用することができる。一方、ジョブ・アービタ２６ａ、２６ｂは、それぞれ３台の画像処理装置２８などを管理し、合計６台の画像処理装置がクラスタ・ノードとして機能している。

本発明によれば、サーバ１２では、ジョブ・アービタ２６ａ、２６ｂに対してだけＦＴＰパケットを伝送し、受信するだけで済むので、ＧＷサーバ１４からインターネットまたは公衆電話網などのネットワーク２０へのボトルネックとなるバックボーン・ネットワーク１６の伝送経路の帯域幅をクラスタ・ノードの増加にともなって増加させることなく、処理することができる。すなわち、他の処理のために使用する帯域幅を最大限に確保しながら、画像処理装置の効率的管理処理およびサーバの負担軽減を行うことができる。また、主要なデータ・トランザクションを、ジョブ・アービタが帰属される高速イーサネット（登録商標）などに分散でき、サーバ側およびネットワーク２０で処理せずに済むため、ネットワーク資源の効率的な使用を可能とする。

また、ジョブ・アービタ２６ａ、２６ｂを管理するユーザにおいては、画像処理装置の遊休時間を有効に使用して計算機資源として画像処理装置を提供し、また提供資源量に応答してメンテナンスなどの割引を受けることができるので、計算機資源としての提供がボランティアとなることなく、画像処理装置の効率的な稼働を行うことができる。

本発明の上記機能は、ＦＯＲＴＲＡＮ、Ｃなどの手続き型プログラミング言語、ＶｉｓｕａｌＢａｓｉｃ、Ｃ＋＋、ＶｉｓｕａｌＣ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向ブログラミング言語などで記述された、装置実行可能なプログラムにより実現でき、当該プログラムは、装置可読な記録媒体に格納して頒布することができる。

これまで本発明を図面に示した実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、他の実施の形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

本発明の分散処理システムの実施の形態を示した図。 本発明で使用するサーバの詳細な構成を示した図。 本発明で使用する画像処理装置の例示的構成を示した図。 サーバから送付されたジョブを仲介し、画像処理装置に配分するジョブ・アービタの機能ブロック図。 本発明の処理および処理を構成するジョブ構成を示した図。 本発明でジョブを登録したジョブ・リストを示した図。 サーバが含むジョブ管理データの実施の形態を示した図。 サーバが配布先を決定する処理を示したフローチャート。 ジョブの要求する特性をリストしたジョブ属性を示した図。 画像処理装置データをリストしたルックアップ・テーブル。 ユーザ管理データの実施の形態を示した図。 保守契約に含まれる資源提供データの部分を使用してルックアップ・テーブルとして与えられる、割引料金テーブルを示した図。 ジョブ管理テーブルを更新する更新処理のフローチャートを示した図。 本発明により更新されたジョブ管理テーブルの実施の形態を示した図。 ジョブ・アービタの実行する処理のフローチャートを示した図。 図１５のステップＳ３０２の処理の詳細を示すフローチャートを示した図。 ジョブ・アービタが管理する画像処理装置のジョブ管理のための管理テーブルを示した図。 本発明の分散処理システムにおけるサーバ−ジョブ・アービタ間のトランザクションのシーケンスを示した図。 本発明のジョブ・アービタ１と画像処理装置α、βとの間のトランザクションのシーケンスを示した図。 本発明のジョブ・アービタ２と画像処理装置ε、δとの間のトランザクションのシーケンスを示した図。 ジョブ・アービタからの処理を受取った後のサーバ側における処理のフローチャートを示した図。 本発明の分散処理システムの実施の形態を示した図。 従来の分散処理システムの実施の形態を示した図。

符号の説明

１０…分散処理システム、１２…サーバ、１４…ゲートウェイ・サーバ、１６…バックボーン・ネットワーク、１８…ファイアウォール、２０…公共ネットワーク（インターネット、公衆電話網）、２２…ファイアウォール、２４…ルータ、２６…ジョブ・アービタ、２８…複合機、３０…複写機、３２…プリンタ、３４…スイッチ、３６…他のネットワーク、３８…第２のネットワーク、４０…アプリケーション層、４２…ＡＰＩ層、４４…ＯＳ層、４６…Ｉ／Ｏ層、４８…記憶装置、５０…ディスプレイ装置、５２…キーボード、５４…マウス、６０…アプリケーション層、６２…制御モジュール層、６４…デバイス層、６６…ＲＡＭ（ジョブ・キュー）、６８…ＵＩ装置、７０…ＦＴＰクライアント処理部、７２…ジョブ管理部、７４…装置モニタ、７６…インタフェース、７８…記憶装置、８０…ディスプレイ装置、８２…キーボード、８４…マウス

Claims (22)

1. 画像処理装置にネットワークを介して処理を実行させる分散処理システムであって、前記システムは、
   画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録し、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークに送出するサーバと、
   前記サーバから前記分割ジョブを前記ネットワークを介して受信し、第２のネットワークに接続され、ジョブを配付できる画像処理装置を監視し、前記画像処理装置に対し、受信した前記分割ジョブの少なくとも一部のジョブを伝送するジョブ・アービタと、
   前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行し、実行結果を前記ジョブ・アービタに返信する画像処理装置と
   を備え、
   前記サーバは、前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録し、同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定する、システム。
2. 画像処理装置にネットワークを介して処理を実行させる分散処理システムであって、前記システムは、
   画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録し、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出するサーバと、
   前記サーバに対して分割ジョブ・リクエストを定期的にポーリングし、前記ポーリングに応答して前記分割ジョブを前記ネットワークを介して受信し、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送するジョブ・アービタと、
   前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行し、実行結果を前記ジョブ・アービタに返信する画像処理装置と
   を備え、
   前記サーバは、前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録し、同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の提供可能資源データについての前記保守データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定する、システム。
3. 前記サーバは、前記分割ジョブを、電子証明書またはＳＳＬによる暗号化されたＦＴＰパケットとして送出する送出手段を備える、請求項１または２に記載のシステム。
4. 前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択する選択手段を含む、請求項１〜３のいずれか１項に記載のシステム。
5. 前記選択手段は、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択する、請求項４に記載のシステム。
6. 前記サーバは、前記ジョブ・アービタが提供した提供資源量に応答して前記保守管理契約に対する割引料金を決定する割引料金決定手段を含む、請求項１〜５のいずれか１項に記載のシステム。
7. 画像処理装置に対してネットワークを介して処理を実行させる分散処理方法であって、前記方法は、
   サーバが、
   ジョブ・アービタから分割ジョブ・リクエストを前記サーバに定期的にポーリングを受取るステップと、
   画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録させ、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出するステップと、
   前記ジョブ・アービタに対し、前記分割ジョブを前記ネットワークを介して受信させ、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送させるステップと、
   画像処理装置に対し、前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行させ、実行結果を前記ジョブ・アービタに返信させるステップと
   を含み、
   前記サーバが、さらに
   前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録するステップと、
   同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定するステップとを実行する
   方法。
8. 前記送出させるステップは、前記分割ジョブを、電子証明書またはＳＳＬによる暗号化されたＦＴＰパケットとして送出させるステップを含む、請求項７に記載の方法。
9. 前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択するステップを実行する、請求項７または８のいずれか１項に記載の方法。
10. 前記選択するステップは、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択するステップを含む、請求項７〜９のいずれか１項に記載の方法。
11. 前記サーバは、前記ジョブ・アービタが提供した提供資源量に応答して前記保守管理契約に対する割引料金を決定するステップを実行する、請求項７〜１０のいずれか１項に記載の方法。
12. 画像処理装置に対してネットワークを介して分散処理を実行させるジョブ・アービタであって、前記ジョブ・アービタは、
    前記分散処理に対するリクエストを前記ネットワークへと定期的にポーリングする手段と、
    前記ポーリングに応答して前記ジョブ・アービタの所定期間についての処理能力以下として生成された分割ジョブを前記ネットワークを介してサーバから受信する手段と、
    前記分割ジョブの少なくとも一部を第２のネットワークを介して前記画像処理装置へと送出し、前記画像処理装置の実行結果を受取り、前記実行結果を前記ネットワークを介して前記サーバに送出する送出手段と、
    を備え、
    前記ジョブ・アービタは、前記サーバが同一の階層に登録された前記分割ジョブのサブツリーの数に応じて前記ジョブ・アービタが管理する画像形成装置の保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して前記分割ジョブを送付する宛先が決定され、前記サーバから前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記階層構造の深度に応じた前記分割ジョブのサブツリーとして受信する、ジョブ・アービタ。
13. 前記送出手段は、前記実行結果をＦＴＰプロトコルへと変換する手段を備える、請求項１２のジョブ・アービタ。
14. 前記送出手段は、前記ネットワークへの送出プロトコルと、前記第２のネットワークへの送出プロトコルとを変えて送出を行う、請求項１２または１３に記載のジョブ・アービタ。
15. 前記送出手段は、前記分割ジョブに対して電子証明書またはＳＳＬを使用して暗号化または復号化されたデータを生成する手段を備える、請求項１２〜１４のいずれか１項に記載のジョブ・アービタ。
16. 画像処理装置に対してネットワークを介して分散処理を実行させるジョブ・アービタとして情報処理装置を機能させるプログラムであって、前記プログラムは、前記情報処理装置が、
    前記分散処理に対するリクエストを前記ネットワークへと定期的にポーリングするステップ、
    前記ポーリングに応答して前記ジョブ・アービタの所定期間についての処理能力以下として生成された分割ジョブを前記ネットワークを介してサーバから受信するステップ、
    前記分割ジョブの少なくとも一部を第２のネットワークを介して前記画像処理装置へと送出し、前記画像処理装置の実行結果を受取り、前記実行結果を前記ネットワークを介して前記サーバに送出する送出ステップ、
    を実行し、
    前記ジョブ・アービタは、前記サーバが同一の階層に登録された前記分割ジョブのサブツリーの数に応じて前記ジョブ・アービタが管理する画像形成装置の保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して前記分割ジョブを送付する宛先が決定され、前記サーバから前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記階層構造の深度に応じた前記分割ジョブのサブツリーとして受信する、
    情報処理装置実行可能なプログラム。
17. 前記送出ステップは、前記処理結果をＦＴＰプロトコルへと変換するステップを含む、請求項１６のプログラム。
18. 前記送出ステップは、前記ネットワークへの送出プロトコルと、前記第２のネットワークへの送出プロトコルとを変えるステップを含む、請求項１６または１７に記載のプログラム。
19. 前記分割ジョブに対して電子証明書またはＳＳＬを使用して暗号化または復号化されたデータを生成するステップを含む、請求項１６〜１８のいずれか１項に記載のプログラム。
20. 画像処理装置に対してネットワークを介して処理を実行させるため、情報処理装置をサーバとして機能させるための情報処理装置実行可能なプログラムであって、前記プログラムは、前記情報処置装置を、
    ジョブ・アービタから分割ジョブ・リクエストを前記サーバに定期的にポーリングを受信する手段、
    画像処理装置の保守を行うと共に前記処理を複数の分割ジョブとして登録させ、前記画像処理装置の性能データおよび前記画像処理装置の遠隔監視により収集した保守データに応答して決定された宛先に宛てて前記分割ジョブを前記ネットワークにプッシュ型伝送により送出する手段、
    前記ジョブ・アービタに対し、前記分割ジョブを前記ネットワークを介して受信させ、第２のネットワークに前記分割ジョブの少なくとも一部のジョブを伝送させる手段、
    画像処理装置に対し、前記ジョブを前記第２のネットワークを介して受信して前記ジョブを実行させ、実行結果を前記ジョブ・アービタに返信させる手段
    として機能させ、
    さらに、前記情報処理装置を、
    前記処理を、データ・レベルを最下位階層とし、分割ジョブの返り値が渡される順に高階層とした階層構造として前記複数の分割ジョブを登録する手段、
    同一の階層に登録された前記分割ジョブのサブツリーの数と使用できるジョブ・アービタの台数とを比較して前記階層構造の深度に応じて前記分割ジョブを送信するべき前記ジョブ・アービタを、前記ジョブ・アービタが管理する画像形成装置の前記保守データから得た提供可能資源データに基づいて利用可能なジョブ・アービタを登録したリストから選択して決定する手段
    として機能させる、プログラム。
21. 前記サーバは、前記保守データを使用して前記ジョブ・アービタの提供可能資源データを生成し、前記提供可能資源データに応答して前記分割ジョブの配布先を選択する選択手段を含む、請求項２０に記載のプログラム。
22. 前記選択手段は、前記画像処理装置の資源提供契約の登録ユーザが管理する前記ジョブ・アービタから前記ジョブ・アービタの処理能力に応答して前記ジョブ・アービタを選択する、請求項２１に記載のプログラム。

Images