(57)【要約】【課題】クラウドコンピューティングシステムにおいても、要求を受け付けた順番で処理を行うことを目的とする。【解決手段】要求受信部がネットワークプルプリント要求を画像形成装置から受け付け、要求に応じて発行されたキューメッセージを取得し、画像形成装置の状態に応じて取得したキューメッセージの優先度を決定し、キューメッセージを要求管理データに登録する登録手段と、登録手段により登録されたキューメッセージの中から優先度が高いキューメッセージを取得し、記憶サービスに取得した優先度が高いキューメッセージを格納するよう指示する指示手段と、を有することによって課題を解決する。【選択図】図６
2012083845.tif 000002
【特許請求の範囲】
【請求項１】
画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するキューメッセージを記憶サービスに格納させる、要求受信プログラムを実行することにより実現される要求受信部と、
前記記憶サービスに対し前記キューメッセージの取得要求を定期的に行い、前記記憶サービスから前記キューメッセージを取得した場合は、該取得したキューメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部と、
を有するクラウドコンピューティングシステムであって、
前記要求受信部がネットワークプルプリント要求を画像形成装置から受け付け、該要求に応じて発行されたキューメッセージを取得し、前記画像形成装置の状態に応じて該取得したキューメッセージの優先度を決定し、該キューメッセージを要求管理データに登録する登録手段と、
前記登録手段により登録されたキューメッセージの中から優先度が高いキューメッセージを取得し、前記記憶サービスに該取得した優先度が高いキューメッセージを格納するよう指示する指示手段と、
を有するクラウドコンピューティングシステム。
【請求項２】
複数の画像形成装置とネットワークを介して通信可能な、複数のサーバーコンピュータから構成されるクラウドコンピューティングシステムであって、
画像形成装置からネットワークプルプリント要求を受け付けると、受付順番を登録した、ネットワークプルプリント要求のキューメッセージを、要求受信キューに通知する受信手段と、
要求受信キューよりキューメッセージを取得し、取得したキューメッセージに登録されている受付順番に基づいて、受付順番が若い程、優先度が高くなるよう前記キューメッセージの優先度を決定し、前記決定した優先度に基づいて、前記キューメッセージを、要求管理データに登録し、処理依頼キューの状況が定められた条件を満たしていた場合、前記要求管理データから最も優先度が高い前記キューメッセージを取得し、前記処理依頼キューに追加するスケジュール手段と、
前記処理依頼キューからキューメッセージを取得し、取得したキューメッセージで指定されたドキュメントを取得する処理と取得したドキュメントを画像形成装置が印刷可能なデータフォーマットへ変換する処理とを行うネットワークプルプリント処理手段と、
を有するクラウドコンピューティングシステム。
【請求項３】
前記要求管理データは、複数のキューメッセージを束ねたデータ一覧を優先度に応じて保持する構成を有し、
前記スケジュール手段は、前記キューメッセージを、前記決定した優先度に基づいて、前記要求管理データのデータ一覧に登録し、前記処理依頼キューの状況が定められた条件を満たしていた場合、前記要求管理データから最も優先度が高いデータ一覧を取得し、取得したデータ一覧に含まれるキューメッセージを、前記処理依頼キューに追加する請求項２記載のクラウドコンピューティングシステム。
【請求項４】
前記受信手段は、画像形成装置からネットワークプルプリント要求と、画像形成装置情報と、を受け付けると、受付順番と、前記画像形成装置情報と、を登録した、ネットワークプルプリント要求のキューメッセージを、前記要求受信キューに通知し、
前記スケジュール手段は、要求受信キューよりキューメッセージを取得し、取得したキューメッセージに登録されている受付順番と、前記画像形成装置情報と、に基づいて、前記キューメッセージの優先度を決定する請求項２又は３記載のクラウドコンピューティングシステム。
【請求項５】
前記画像形成装置情報とは、画像形成装置の印刷部の状態を表わす情報であり、
前記スケジュール手段は、取得したキューメッセージに登録されている前記画像形成装置情報が、印刷部が印刷出来ることを表わしている場合、印刷部が印刷出来ないことを表わしている場合よりも優先度を高く決定する請求項４記載のクラウドコンピューティングシステム。
【請求項６】
前記受信手段は、画像形成装置から受付順番を含む状態変更通知を受け取ると、前記状態変更通知のキューメッセージを、前記要求受信キューに通知し、
前記スケジュール手段は、前記要求受信キューよりキューメッセージを取得し、取得したキューメッセージが前記状態変更通知のキューメッセージであった場合、前記状態変更通知に含まれる受付順番に基づいて、前記要求管理データより該当するキューメッセージを検索し、該当するキューメッセージが存在した場合、前記状態変更通知の内容に応じて、前記キューメッセージの優先度を変更する請求項４又は５記載のクラウドコンピューティングシステム。
【請求項７】
複数の画像形成装置とネットワークを介して通信可能な、複数のサーバーコンピュータから構成されるクラウドコンピューティングシステムが実行する情報処理方法であって、
画像形成装置からネットワークプルプリント要求を受け付けると、受付順番を登録した、ネットワークプルプリント要求のキューメッセージを、要求受信キューに通知する受信ステップと、
要求受信キューよりキューメッセージを取得し、取得したキューメッセージに登録されている受付順番に基づいて、受付順番が若い程、優先度が高くなるよう前記キューメッセージの優先度を決定し、前記決定した優先度に基づいて、前記キューメッセージを、要求管理データに登録し、処理依頼キューの状況が定められた条件を満たしていた場合、前記要求管理データから最も優先度が高い前記キューメッセージを取得し、前記処理依頼キューに追加するスケジュールステップと、
前記処理依頼キューからキューメッセージを取得し、取得したキューメッセージで指定されたドキュメントを取得する処理と取得したドキュメントを画像形成装置が印刷可能なデータフォーマットへ変換する処理とを行うネットワークプルプリント処理ステップと、
を含む情報処理方法。
【請求項８】
複数の画像形成装置とネットワークを介して通信可能な、複数のサーバーコンピュータから構成されるクラウドコンピューティングシステムのコンピュータに、
画像形成装置からネットワークプルプリント要求を受け付けると、受付順番を登録した、ネットワークプルプリント要求のキューメッセージを、要求受信キューに通知する受信ステップと、
要求受信キューよりキューメッセージを取得し、取得したキューメッセージに登録されている受付順番に基づいて、受付順番が若い程、優先度が高くなるよう前記キューメッセージの優先度を決定し、前記決定した優先度に基づいて、前記キューメッセージを、要求管理データに登録し、処理依頼キューの状況が定められた条件を満たしていた場合、前記要求管理データから最も優先度が高い前記キューメッセージを取得し、前記処理依頼キューに追加するスケジュールステップと、
前記処理依頼キューからキューメッセージを取得し、取得したキューメッセージで指定されたドキュメントを取得する処理と取得したドキュメントを画像形成装置が印刷可能なデータフォーマットへ変換する処理とを行うネットワークプルプリント処理ステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティングシステム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、サーバーコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）という技術が利用され始めている。
クラウドコンピューティングでは、多くのクラウドリソース（コンピューティング・リソース、ストレージ・リソース）を利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。
このようなクラウドコンピューティングシステムでは、スケーラビリティを重要視するため、ブリュワーのＣＡＰ定理における「可用性（Ａｖａｉｌａｂｉｌｉｔｙ）」、「分割耐性（Ｐａｒｔｉｔｉｏｎ  Ｔｏｌｅｒａｎｃｅ）」を採用し、「一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）」を犠牲にしたシステムとなっている。
例えば、Ｗｉｎｄｏｗｓ（登録商標）  Ａｚｕｒｅにおいても一貫性は保証されていない。より具体的には、Ｗｉｎｄｏｗｓ  Ａｚｕｒｅは、参考文献１のように、クラウドコンピューティングにおけるキューでは、ファーストイン／ファーストアウト方式ではなく、処理する順番は、決まっていない。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】"ＷＩＮＤＯＷＳ  ＡＺＵＲＥ  の紹介"、ＭＩＣＲＯＳＯＦＴ  ＣＯＲＰＯＲＡＴＩＯＮ、２００９年  １２月、Ｐ２３  キュー
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このようなクラウドコンピューティングシステム上に画像形成装置から指定されたドキュメントデータを取得し、そのドキュメントデータを印刷可能なデータ形式に変換するネットワークプルプリントサービスを構築した場合を想定する。
このようなネットワークプルプリントサービスに対して、多くの画像形成装置からプルプリント要求が行われると、その要求は、クラウドコンピューティングにおけるキューで管理されるため、どの順番で要求を処理するかは、保証されない。その結果、後から依頼したユーザのプリントが最初にプリントを依頼したユーザより先に処理される可能性がある。このような場合、最初にプリントを依頼したユーザは、長時間、プリントを待たされてしまう問題があった。
本発明はこのような問題点に鑑みなされたもので、クラウドコンピューティングシステムにおいても、要求を受け付けた順番で処理を行うことを可能にすることを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明のクラウドコンピューティングシステムは、画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶サービスに格納させる、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶サービスに対し前記メッセージの取得要求を定期的に行い、前記記憶サービスから前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部と、を有するクラウドコンピューティングシステムであって、前記要求受信部がネットワークプルプリント要求を画像形成装置から受け付け、該要求に応じて発行されたキューメッセージを取得し、前記画像形成装置の状態に応じて該取得したキューメッセージの優先度を決定し、該キューメッセージを要求管理データに登録する登録手段と、前記登録手段により登録されたキューメッセージの中から優先度が高いキューメッセージを取得し、前記記憶サービスに該取得した優先度が高いキューメッセージを格納するよう指示する指示手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、クラウドコンピューティングシステムにおいても、要求を受け付けた順番で処理を行うことを可能にすることができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態のシステム全体の構成の一例を示す図である。
【図２】本実施形態の画像形成装置のハードウェア構成の一例を示す図である。
【図３】本実施形態の情報処理装置のハードウェア構成の一例を示す図である。
【図４】従来のシステム等を説明するための図である。
【図５】従来のネットワークプルプリントシステムの処理依頼キューを説明するための図である。
【図６】本実施形態のシステム全体の機能構成の一例を示す図である。
【図７】本実施形態のネットワークプルプリントシステムの詳細を説明するための図である。
【図８Ａ】キューメッセージ管理テーブルの一例を示す図（その１）である。
【図８Ｂ】キューメッセージ管理テーブルの一例を示す図（その２）である。
【図８Ｃ】キューメッセージ管理テーブルの一例を示す図（その３）である。
【図８Ｄ】キューメッセージ管理テーブルの一例を示す図（その４）である。
【図９】画像形成装置の処理の一例を示すフローチャートである。
【図１０】ネットワークプルプリント要求・クライアント情報受信部の処理の一例を示すフローチャートである。
【図１１Ａ】キューメッセージスケジューラーの処理の一例を示すフローチャート（その１）である。
【図１１Ｂ】キューメッセージスケジューラーの処理の一例を示すフローチャート（その２）である。
【図１１Ｃ】キューメッセージスケジューラーの処理の一例を示すフローチャート（その３）である。
【図１２】本実施形態のシステム全体の処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
【０００９】
＜実施形態１＞
ネットワークプルプリントサービスを構成している各装置について、図１を参照して説明する。図１は、システム全体の構成の一例を示す図である。図１には、ネットワークプルプリントサービスを構成している各装置がネットワーク１００を介して接続されている様子が示されている。ネットワークシステムを構成している各装置とは、ネットワークプルプリントシステム１０２、文書サーバー１０３、画像形成装置１０４である。
ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、画像形成装置１０４が属するネットワーク１００からは、ネットワークプルプリントシステム１０２等が属するネットワーク１００と、ファイアウォールを越えて通信することができる。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコル等をサポートする通信回線網であり、有線・無線は問わない。図１において、ネットワークプルプリントシステム１０２は、１台のサーバーとして示されているが複数台のサーバーコンピュータで構成されている。
【００１０】
次に、図１のネットワークプルプリントサービスを構成している各装置の内部構成について説明する。始めに、画像形成装置１０４のハードウェア構成について図２を用いて説明する。図２は、画像形成装置１０４のハードウェア構成の一例を示す図である。
画像形成装置１０４は、画像処理ユニット２０１、印刷ユニット２０２、及び読み込みユニット２０３から構成される。画像処理ユニット２０１は、ＣＰＵ２０４、直接記憶部２０５、間接記憶部２０６、ユーザインターフェース２０７、外部インターフェース２０８、消耗品管理ユニット２０９から構成されている。
ＣＰＵ２０４は、所定のプログラムを実行し、画像形成装置１０４の各種制御を指示するユニットである。ＣＰＵ２０４は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）により実現される。直接記憶部２０５は、ＣＰＵ２０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０４が実行するプログラムは、直接記憶部２０５にロードされる。直接記憶部２０５は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）により実現される。間接記憶部２０６は、アプリケーションプログラム、及びプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部２０６に記憶されている各種プログラムは、ＣＰＵ２０４がプログラムを実行する際に直接記憶部２０５へ移動される。間接記憶部２０６は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、又は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２０４は、マルチプロセッサでもよい。
【００１１】
ここで、プラットフォームについて説明する。プラットフォームの実現により、ユーザが独自に開発した新しいアプリケーションを画像形成装置１０４上で実行できる他、画像形成装置１０４の操作画面をカスタマイズすることが可能になる。
プラットフォームの実現方法について説明する。ＣＰＵ２０４は、間接記憶部２０６に記憶されたプラットフォームプログラムを直接記憶部２０５に移動する。移動が完了するとＣＰＵ２０４は、プラットフォームプログラムを実行することができる状態になる。本実施形態では、ＣＰＵ２０４がプラットフォームプログラムを実行することを、プラットフォームを起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
プラットフォーム上でアプリケーションプログラムを実行する方法について説明する。本実施形態において、プラットフォーム上には、印刷要求を受け付ける印刷ソフトウェアが動作している。印刷ソフトウェアは、ネットワークを介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等の通信プロトコルによって印刷データを受信することができる。印刷ソフトウェアは、受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは、印刷データ処理を開始する。なお、印刷データが処理をせずに印刷できるようなものであれば、ファームウェアは、印刷データ処理を省く。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部２０６に記憶されたアプリケーションプログラムを直接記憶部２０５に移動する。移動が完了すると、プラットフォームは、アプリケーションプログラムを実行することができる状態になる。そして、プラットフォームは、アプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本実施形態では、プラットフォームアプリケーションと呼ぶ。更に、プラットフォームは、本実施形態で開示するフローチャートの各処理の一部を行うことができる。
【００１２】
ユーザインターフェース２０７は、ユーザからの処理依頼を受け付けるために必要なユニットである。例えば、ユーザインターフェース２０７は、キーボード、マウス等を通してユーザが入力した指示に応じた信号を受け付ける。外部インターフェース２０８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、又は、ネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０４は、ネットワーク１００、及びインターネット１０１を介してネットワークプルプリントシステム１０２等と通信可能である。
消耗品管理ユニット２０９は、印刷に必要な消耗品（トナーやインク、用紙等）を格納管理するユニットである。印刷を行うのに必要な消耗品がなくなる（トナー・インク切れや用紙切れ）と、消耗品管理ユニット２０９は、消耗品欠如イベントを発行する。また、欠如した消耗品を充填して印刷可能な状態になると、消耗品管理ユニット２０９は、消耗品充填イベントを発行する。これら消耗品欠如イベントや消耗品充填イベントは、プラットフォームアプリケーションにて検知する事が可能で、そのイベントに応じたプログラムを実行する事が可能である。
【００１３】
起動制御ユニット２１０は、画像形成装置１０４の起動・終了を切り替える手段を有する。起動制御ユニット２１０により、画像形成装置１０４が起動状態に切り替えられると、ＣＰＵ２０４は、起動状態にするために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行し、画像形成装置１０４を動作可能な状態にする。この起動状態にするために必要なプログラムは、定められた起動処理を完了すると、起動イベントを発行する。また、起動制御ユニット２１０により、画像形成装置１０４が終了状態に切り替えられると、ＣＰＵ２０４は、終了状態にするために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行し、画像形成装置１０４を動作しない状態にする。この起動状態にするために必要なプログラムは、定められた起動処理を完了すると、終了イベントを発行する。前記起動イベント及び終了イベントは、プラットフォームアプリケーションにて検知する事が可能で、そのイベントに応じたプログラムを実行する事が可能である。
【００１４】
次に、ネットワークプルプリントシステム１０２、文書サーバー１０３を含む情報処理装置のハードウェア構成について図３を用いて説明する。図３は、情報処理装置１０６のハードウェア構成の一例を示す図である。情報処理装置１０６は、ＣＰＵ３０１、直接記憶部３０２、間接記憶部３０３、ユーザインターフェース３０４、外部インターフェース３０５から構成されている。
ユーザインターフェース３０４は、ユーザからの処理依頼を受け付けるために必要なユニットである。例えば、ユーザインターフェース３０４は、キーボード、マウス等を通してユーザが入力した指示に応じた信号を受け付ける。
ＣＰＵ３０１は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示するユニットである。ＣＰＵ３０１は、ＣＰＵにより実現される。直接記憶部３０２は、ＣＰＵ３０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ３０１が実行するプログラムは、直接記憶部３０２にロードされる。直接記憶部３０２は、ＲＡＭで構成されている。間接記憶部３０３は、アプリケーションプログラム、及びＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部３０３に記憶されている各種プログラムは、ＣＰＵ３０１がプログラムを実行する際に直接記憶部３０２へ移動する。間接記憶部３０３は、ＲＯＭ、又は、ＨＤＤで構成されている。外部インターフェース３０５は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。
次に、文書サーバー１０３の機能について説明する。文書サーバー１０３は、文書リポジトリ４０３の機能を持つ。文書リポジトリ４０３は、図３の間接記憶部３０３によって実現される。例えば、文書リポジトリ４０３には、ユーザが画像形成装置１０４から印刷指示したコンテンツが保存されている。
【００１５】
次に、従来の画像形成装置１０４について図４を参照しながら説明する。図４は、従来のシステム等を説明するための図である。画像形成装置１０４には、デバイスブラウザ４０１、プルプリントアプリケーション４０２の機能がある。デバイスブラウザ４０１は、ネットワーク１００を介して接続されているデバイス内に保存されているデータや情報をユーザが閲覧することができる機能を有する。デバイスブラウザ４０１は、図２の間接記憶部２０６に保存されているデバイスブラウザプログラムが、直接記憶部２０５にロードされ、ＣＰＵ２０４により実行されることで実現される。また、ユーザは、デバイスブラウザ４０１を用いてコンテンツの印刷指示を出すことができる。デバイスブラウザ４０１は、例えば、Ｗｅｂブラウザである。
プルプリントアプリケーション４０２は、ネットワークプルプリント要求受信部４０４が作成した印刷データ取得ＵＲＩに対して、定期的に印刷データ生成確認を行う。印刷データが生成されている場合は、プルプリントアプリケーション４０２は、印刷データの取得と印刷とを行う。
以上が、実施形態のネットワークプルプリントサービスにおける各装置が持つ機能の説明になる。
【００１６】
次に、従来のネットワークプルプリントサービスを構成しているネットワークプルプリントシステム１０２のプラットフォームシステムについて図４を参照しながら説明する。ネットワークプルプリント要求受信部４０４は、画像形成装置１０４からのネットワークプルプリント要求を受け付けるモジュールである。ネットワークプルプリント要求受信部４０４は、画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶サービスに格納させる、要求受信プログラムを実行することにより実現される要求受信部に相当する。
ネットワークプルプリント要求受信部４０４は、処理依頼キュー４０７を介してネットワークプルプリント処理部４０６への処理依頼を送信する。処理依頼キュー４０７は、ネットワークプルプリント要求受信部４０４とネットワークプルプリント処理部４０６とが非同期でデータ通信するためのサービスを提供するものである。処理依頼キュー４０７は、記憶サービスに相当する。ネットワークプルプリント要求受信部４０４、及びネットワークプルプリント処理部４０６は、処理依頼キュー４０７に対し各種指示を出すことで、非同期でデータ通信する。ネットワークプルプリント処理部４０６は、前記記憶サービスに対し前記メッセージの取得要求を定期的に行う。また、記憶サービスから前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部に相当する。
ネットワークプルプリント処理部４０６は、処理依頼キュー４０７からキューメッセージを取得し、指定されたドキュメントの取得と、画像形成装置が印刷可能なデータフォーマットへの変換と、を行う。ネットワークプルプリント処理部４０６は、生成された画像形成装置が印刷可能なデータを、印刷データ格納部４０８に、印刷データを取得するための印刷データ取得ＵＲＩと関連付けて保存する。これらの処理が完了すると、ネットワークプルプリント処理部４０６は、受取ＩＤに対応するキューメッセージの削除指示を処理依頼キュー４０７に対して行う。削除指示を受けた処理依頼キュー４０７は、ネットワークプルプリント処理部４０６が指示した受取ＩＤに対応するキュースメッセージをキューから削除する。印刷データ取得要求受信部４０５は、画像形成装置１０４から印刷データ取得要求を受け付けるモジュールである。印刷データ取得要求受信部４０５は、画像形成装置１０４が要望した印刷データ取得ＵＲＩに対して、印刷データの存在を確認する。
印刷データ格納部４０８に指定されたＵＲＩの印刷データが存在する場合、印刷データ取得要求受信部４０５は、印刷データ格納部４０８に保存された該当データを画像形成装置に対して送信する。
【００１７】
従来のネットワークプルプリントサービスを構成しているネットワークプルプリントシステム１０２のプラットフォームシステムの処理依頼キュー４０７について、図５を用いてより具体的に説明する。処理依頼キュー４０７は、例えば、クラウド環境におけるキューと同義である。
ネットワークプルプリント要求受信部４０４は、処理依頼キュー４０７に対してキューメッセージの追加指示を行う。一方、ネットワークプルプリント処理部４０６は、処理依頼キュー４０７に対してキューメッセージの取得指示とキューメッセージの削除指示とを行う。キューメッセージの取得指示とは、キューに登録されたキューメッセージを取得するオペレーションであり、キューメッセージの削除指示とは、指定したキューメッセージをキューから削除するオペレーションである。クラウド環境におけるキューとは、キューメッセージの取得だけでは、キューの情報は、削除されず、キューメッセージの処理が完了した後にキューメッセージの削除を行う必要がある。
ネットワークプルプリント要求受信部４０４は、ユーザから指定された情報をキューメッセージとして作成し、キューメッセージをキューに追加するように処理依頼キュー４０７に追加指示を送信する。追加指示を受信した処理依頼キュー４０７は、内部のキューにキューメッセージを追加する。このキューメッセージの追加は、処理依頼キュー４０７の内部に保持するキューで空き領域に追加される。
【００１８】
一方、ネットワークプルプリント処理部４０６は、キューメッセージを取得するために、処理依頼キュー４０７に取得指示を出す。取得指示を受けた処理依頼キュー４０７は、処理依頼キューの任意の場所からキューメッセージを取得する。この取得処理は、ＦＩＦＯではなく、任意の場所からキューメッセージが取得される。即ち、最初にシステムの処理依頼キュー４０７に追加されたキューメッセージが後続のキューメッセージよりも後で処理されることが発生する。
ネットワークプルプリント処理部４０６の処理が短時間であれば、このような順番の逆転は、大きな問題ではないが、ネットワークプルプリント処理部４０６の処理時間が長くなれば長くなるほど、このようなキューシステムによる不都合が目立ってしまう。例えば、要求処理に１分間かかる要求が１０個たまった状態を考える。この状態で新規の要求を行うと、運が良ければ、最初に処理されるためそのユーザの待ち時間は、自身の要求処理時間の１分だけである。しかし、このようなことが頻発すると、先行して依頼していたキューメッセージが処理されず、そのユーザの処理待ち時間が非常に長くなってしまう。
【００１９】
次に、本実施形態のネットワークプルプリントサービスを構成しているネットワークプルプリントシステム１０２のプラットフォームシステムについて図６を参照しながら説明する。
ネットワークプルプリント要求・クライアント情報受信部４１０は、画像形成装置１０４からのネットワークプルプリント要求と画像形成装置１０４の情報とを受け付けるモジュールである。画像形成装置１０４の情報とは、例えば画像形成装置の印刷部（印刷ユニット）のステータス（状態）であり、ｉｄｌｅ（印刷可能）、ｐｒｏｃｅｓｓｉｎｇ（印刷中）、ｅｒｒｏｒ（印刷できず）、である。或いは、画像形成装置１０４の情報とは、現在印刷要求が行われている全印刷ジョブの総処理時間を示し、要求した印刷データが何分後に印刷できるかという情報であってもよいし、画像形成装置能力であってもよい。なお、画像形成装置１０４の情報は、画像形成装置情報の一例である。
本実施形態では、特に言及しない限り、画像形成装置１０４の情報として、印刷部の状態を用いて説明を行う。また、印刷部の状態も説明を判り易く行うために、印刷不可能（ｅｒｒｏｒ）と印刷可能（ｒｅａｄｙ）との２つの状態を用いて説明を行う。但し、このことは本実施形態を制限するものではない。
なお、以下、本明細書中では説明の簡略化のため、ネットワークプルプリント要求・クライアント情報受信部４１０を単に、受信部４１０という。
受信部４１０は、ネットワークプルプリント要求と、画像形成装置１０４の状態と、を受信すると、要求・状態変更受信キュー４１１に対して依頼・状態変更を通知する。要求・状態変更受信キュー４１１は、要求受信キューの一例である。受信部４１０は、受け付けた順序に応じて、キューメッセージに受付順番を付与する。例えば、後述する図７等に示される依頼「××」ｒｅａｄｙの「××」の部分が受付順番に対応する。
【００２０】
キューメッセージスケジューラー４１２は、要求・状態変更受信キュー４１１からキューメッセージを取得して画像形成装置１０４から受信したメッセージが印刷要求か、リクエスタ情報通知であるかを確認し、そのメッセージに応じた処理を行う。キューメッセージスケジューラー４１２は、スケジュール手段の一例である。
キューメッセージスケジューラー４１２は、処理依頼キュー４１４の状態を確認し、処理依頼キュー４１４のジョブ状況に応じて、キューメッセージ管理テーブル４１３に保持されたキューメッセージを処理依頼キュー４１４に登録する。キューメッセージ管理テーブル４１３は、要求管理データの一例である。また、キューメッセージスケジューラー４１２は、処理依頼キューの未処理状況のジョブが一定数より少なくなったことを検知すると、キューメッセージ管理テーブル４１３から再も優先度が高いキューメッセージリストを取得する。そして、キューメッセージスケジューラー４１２は、キューメッセージリストに登録されたキューメッセージを処理依頼キュー４１４に登録する。キューメッセージスケジューラー４１２は、登録したキューメッセージを、キューメッセージ管理テーブル４１３から削除する。
ネットワークプルプリント処理部４０６は、処理依頼キュー４１４からキューメッセージを取得し、指定されたドキュメントの取得と画像形成装置が印刷可能なデータフォーマットへの変換とを行う。ネットワークプルプリント処理部４０６は、生成された画像形成装置が印刷可能なデータを、印刷データ格納部４０８に、印刷データを取得するための印刷データ取得ＵＲＩと関連付けて印刷データ格納部４０８に保存する。
これらの処理が完了すると、ネットワークプルプリント処理部４０６は、受取ＩＤに対応するキューメッセージの削除指示を処理依頼キュー４１４に対して行う。削除指示を受けた処理依頼キュー４１４は、ネットワークプルプリント処理部４０６が指示した受取ＩＤに対応するキュースメッセージをキューから削除する。
印刷データ取得要求受信部４０５は、画像形成装置１０４から印刷データ取得要求を受け付けるモジュールである。印刷データ取得要求受信部４０５は、画像形成装置１０４が要望した印刷データ取得ＵＲＩに対して、印刷データの存在を確認する。
印刷データ格納部４０８に指定されたＵＲＩの印刷データが存在する場合、印刷データ取得要求受信部４０５は、印刷データ格納部４０８に保存された該当データを画像形成装置に対して送信する。
【００２１】
ネットワークプルプリントシステム１０２のプラットフォームシステムの要求・状態変更受信キュー４１１、キューメッセージスケジューラー４１２、キューメッセージ管理テーブル４１３、処理依頼キュー４１４について図７を用いてより具体的に説明する。要求・状態変更受信キュー４１１、処理依頼キュー４１４は、共にクラウド環境におけるキューと同義である。
受信部４１０は、要求・状態変更受信キュー４１１に対しキューメッセージの追加指示を行う。
一方、キューメッセージスケジューラー４１２は、要求・状態変更受信キュー４１１に対しキューメッセージの取得指示と、キューメッセージの削除指示と、を行う。キューメッセージの取得指示とは、キューに登録されたキューメッセージを取得するオペレーションであり、キューメッセージの削除指示とは、指定したキューメッセージをキューから削除するオペレーションである。クラウド環境におけるキューとは、キューメッセージの取得だけでは、キューの情報は、削除されず、キューメッセージの処理が完了した後にキューメッセージの削除を行う必要がある。
受信部４１０は、ユーザから指定された情報をキューメッセージとして作成する。ユーザから指定された情報とは、ネットワークプルプリントの依頼か、デバイスの状況変更通知である。そして、受信部４１０は、要求・状態変更受信キュー４１１にキューメッセージの追加指示を送信する。
【００２２】
追加指示を受信した要求・状態変更受信キュー４１１は、内部のキューにキューメッセージを追加する。このキューメッセージの追加は、要求・状態変更受信キュー４１１の内部に保持するキューで空き領域に追加される。
キューメッセージスケジューラー４１２は、キューメッセージを取得するために、要求・状態変更受信キュー４１１に取得指示を出す。取得指示を受けた要求・状態変更受信キュー４１１は、処理依頼キューの任意の場所からキューメッセージを取得する。
要求・状態変更受信キュー４１１によるキューメッセージの取得は、ＦＩＦＯではないため、最初に要求・状態変更受信キュー４１１に追加されたキューメッセージが後続のキューメッセージよりも後で処理されることが発生する。
キューメッセージスケジューラー４１２は、要求・状態変更受信キュー４１１から取得したキューメッセージの種別が依頼か、状態変更かを確認してそれぞれの処理を行う。
キューメッセージが印刷要求の場合、キューメッセージスケジューラー４１２は、キューメッセージに登録された受付順番及び画像形成装置１０４の情報を確認する。キューメッセージスケジューラー４１２は、キューメッセージに登録された受付順番及び画像形成装置１０４の情報から優先度を決定し、その優先度に基づいてキューメッセージ管理テーブル４１３にキューメッセージを登録する。
【００２３】
キューメッセージ管理テーブル４１３とは、受信したキューメッセージに対して優先度を付けたものを管理するテーブルである。管理テーブルには、優先度に応じて複数のキューメッセージを束ねたリストが存在する。リストは、データ一覧の一例である。
キューメッセージスケジューラー４１２は、処理依頼キュー４１４に対して、この優先度毎のキューメッセージリスト単位でキューメッセージの登録を行う。これによって、クライアント（画像形成装置）から受信したキューメッセージの処理順番がランダムであっても、受付順番が守られることになる。また、受付順番だけでなく、このようなシステムで処理優先度を用いて処理順番を決定したい場合でも本仕組みを用いて実現することができる。なお、以下では説明の簡略化のため、特に言及しない限り、キューメッセージスケジューラー４１２は、画像形成装置１０４の情報に基づいて、優先度を決定するものとして説明を行う。
キューメッセージスケジューラー４１２は、処理依頼キュー４１４の未処理件数を取得し、その件数が一定数より減少した場合、キューメッセージ管理テーブル４１３から最も優先度が高いキューメッセージリストを処理依頼キュー４１４に追加する。キューメッセージスケジューラー４１２は、処理依頼キューに登録したキューメッセージを、キューメッセージ管理テーブル４１３から削除して、最優先リストも変更する。
なお、図７に示されるように、クラウドコンピューティングシステムにおいては、ネットワークプルプリント処理部４０６、キューメッセージスケジューラー４１２、受信部４１０は、処理を分散実行するため、複数のタスクが動作している。
【００２４】
キューメッセージスケジューラー４１２とキューメッセージ管理テーブル４１３におけるキューメッセージの管理方法とについて、図８を用いて説明する。
ここでは、例としてキューメッセージは、２つの優先度に分けられているものとする。Ｐ１は、優先度が高く、Ｐｅｎｄｉｎｇは、優先度が低いキューメッセージを示す。
キューメッセージ管理テーブルは、この２つの優先度に応じて、それぞれキューメッセージを管理する複数のリストを保有する。例えば、キューメッセージ管理テーブルは、優先度Ｐ１のキューメッセージを管理するリストＬ１００、Ｌ１０１、Ｌ１０２・・・を保有し、優先度Ｐｅｎｄｉｎｇのキューメッセージを管理するリストＬ２００、Ｌ２０１、Ｌ２０２・・・を保有する。これらのキューメッセージリストは、ＦＩＦＯ構造であり、Ｐ１リストは、Ｌ１００、Ｌ１０１、Ｌ１０２という順番で利用される。
より具体的な例を挙げて説明する。画像形成装置の情報として印刷部の状態を通知しており、状態は、「印刷不可能（ｅｒｒｏｒ）」と「印刷可能（ｒｅａｄｙ）」との２つの状態があるとする。このとき、クライアントから取得した状態がｒｅａｄｙ（印刷出来る）の場合、キューメッセージ管理テーブルは、Ｐ１としてキューメッセージを管理する。クライアントの状態がｅｒｒｏｒ（印刷出来ない）の場合、キューメッセージ管理テーブルは、Ｐｅｎｄｉｎｇとしてキューメッセージを管理する。
このような管理状況において、図８Ａの状態で新規に画像形成装置の情報がｒｅａｄｙである受付順番３０の依頼があったとする。この場合、キューメッセージスケジューラー４１２は、画像形成装置の情報がｒｅａｄｙであるため、キューメッセージ管理テーブル４１３に対してＰ１として登録を行う。このときＰ１のリストは、リストＬ１００、リストＬ１０１に空きエントリがないため、リストＬ１０２に登録されることになる。
【００２５】
次に、図８Ｂの状態でキューメッセージ８を依頼した画像形成装置からｒｅａｄｙへの状態変更通知があったとする。この場合、キューメッセージスケジューラー４１２は、キューメッセージ管理テーブル４１３から受付順番８のキューメッセージを検索する。検索した結果、受付順番８のキューメッセージが見つかると、キューメッセージスケジューラー４１２は、そのキューメッセージの優先度を通知されたｒｅａｄｙに相当するＰ１キューメッセージリストに移動させる。このとき、Ｐ１リストは、リストＬ１００、リストＬ１０１に空きエントリがないため、リストＬ１０２に登録されることになる。例えば、画像形成装置が故障から復帰した場合等、このように、画像形成装置から、Ｅｒｒｏｒからｒｅａｄｙへの状態変更通知がなされ、状態が、Ｅｒｒｏｒからｒｅａｄｙへ変更され、前記画像形成層のキューメッセージの優先度が上がる。
最後に、図８Ｃの状態でキューメッセージスケジューラー４１２が、キューメッセージ管理テーブル４１３に登録されたキューメッセージから処理するキューメッセージを選択する場合の処理について、図８Ｃ、Ｄを用いてより具体的に説明する。
キューメッセージスケジューラー４１２が、処理依頼キュー４１４に処理を依頼する場合、キューメッセージ管理テーブル４１３から優先度の高い要求リストを取得する。図８Ｃの例では、リストＬ１００が優先度の最も高い要求リストとなる。キューメッセージスケジューラー４１２が、リストＬ１１０を取得すると、そのリストに登録された受付順番１２、Ｎｏ２４、Ｎｏ１６、Ｎｏ１１、Ｎｏ１５を処理依頼キュー４１４に登録する。そして、キューメッセージスケジューラー４１２は、処理依頼キュー４１４に登録したキューメッセージをキューメッセージ管理テーブル４１３から削除する。その結果、Ｐ１キューメッセージとしては、図８ＣのＬ１０１が最優先処理リストとなり、キューメッセージ管理テーブル４１３の内部は、図８Ｄのようになる。
【００２６】
次に、ネットワークプルプリントのクライアントである画像形成装置１０４の処理を図９のフローチャートを用いて説明する。
画像形成装置１０４は、デバイスブラウザ４０１が備えるユーザインターフェース３０４からプルプリントの指示を実行されると（Ｓ１００）、画像形成装置の情報を取得する（Ｓ１０１）。画像形成装置の情報とは、ネットワークプルプリントシステムがキューメッセージの優先度を判断するための情報である。例えば画像形成装置の印刷部の状態であったり、本キューメッセージが画像形成装置で処理される予測時間であったり、画像形成装置の印刷能力や製品名であったりする。
デバイスブラウザ４０１は、これらの情報を取得すると、プルプリント・デバイス情報送信アプリケーション４０９を利用して、ネットワークプルプリントシステム１０２の受信部４１０に印刷ドキュメント情報と、クライアント情報と、を通知する（Ｓ１０２）。
なお、以下、本明細書中では説明の簡略化のため、プルプリント・デバイス情報送信アプリケーション４０９を単に、送信アプリケーション４０９という。
送信アプリケーション４０９は、送信した要求に対する応答を受信すると（Ｓ１０３）、レスポンスとして受け取ったデータ取得ＵＲＬに対して、印刷データの生成確認を行う（Ｓ１０４）。この確認の結果、印刷データが生成済みであると、画像形成装置１０４は、印刷データの取得を行い（Ｓ１０５）、印刷を実行する（Ｓ１０６）。
【００２７】
一方、未生成であった場合、送信アプリケーション４０９は、印刷データ生成確認（Ｓ１０４）で印刷データの生成が取得完了するまでネットワークプルプリントシステム１０２に送信したクライアント情報に変更が発生していないかを確認する（Ｓ１０７）。クライアント情報に変更がない場合、再度印刷データの生成が完了しているかどうかを確認する処理（Ｓ１０４）に移行する。クライアント情報の変更を検知した場合（Ｓ１０７）、送信アプリケーション４０９は、ネットワークプルプリントシステム１０２の受信部４１０に対して変更情報を通知する（Ｓ１０８）。
送信するクライアント変更情報とは、例えば要求送信時には、画像形成装置の印刷処理部は、正常に動作していたが、トナーやインク切れ、用紙詰まりや、用紙切れが発生したことによって、印刷が中断された場合にエラーを送信知ることである。又は、他のジョブの割り込み等が発生したことによって、印刷可能時間が当初通知した時間から変更になった等である。
【００２８】
次に、ネットワークプルプリントシステム１０２の受信部４１０の処理を図１０のフローチャートを用いて説明する。
受信部４１０は、ネットワークプルプリントのクライアントである画像形成装置１０４からの要求の受け付け待ちを行う（Ｓ２００）。新規に接続を受け付けると、受信部４１０は、送信要求を受信して（Ｓ２０１）、要求・状態変更受信キュー４１１に対して、要求内容情報を登録したキューメッセージを登録する（Ｓ２０２）。キューメッセージの登録が完了すると、受信部４１０は、ネットワークプルプリントクライアントである画像形成装置１０４に対して、処理結果、印刷データ取得要求ＵＲＬ、印刷要求の受付順番等を応答する（Ｓ２０３）。
【００２９】
次に、ネットワークプルプリントシステム１０２のキューメッセージスケジューラー４１２の処理を図１１Ａ、図１１Ｂ、図１１Ｃのフローチャートを用いて説明する。
キューメッセージスケジューラー４１２は、要求・状態変更受信キュー４１１に関する処理Ｓ３１０と、処理依頼キュー（４１４）の処理Ｓ３２０と、を交互に行う。
図１１Ｂを用いてネットワークプルプリントシステム１０２のキューメッセージスケジューラー４１２の要求・状態変更受信キュー４１１に関する処理を説明する。キューメッセージスケジューラー４１２は、要求・状態変更受信キュー４１１に未処理のキューメッセージが存在するかを確認する（Ｓ３１１）。確認した結果、未処理のキューメッセージが存在しない場合、キューメッセージスケジューラー４１２は、新規要求は存在しないため、処理を何もしない。
一方、キューメッセージが存在する場合、キューメッセージスケジューラー４１２は、キューからメッセージを取得し、そのメッセージに記された処理要求種別を判断する（Ｓ３１２）。この処理要求種別とは、印刷を行うネットワークプルプリント要求か、クライアントの状態変更通知か、の何れかである。
処理要求種別がプリント要求である場合、キューメッセージスケジューラー４１２は、キューメッセージから画像形成装置１０４の情報を取得し、プリント要求を処理する優先度を決定する（Ｓ３１６）。
プリント要求の優先度の決定方法について、例をあげて説明する。例えば、画像形成装置１０４の情報として画像形成装置の状態を利用する場合で、優先度が２段階である場合を説明する。このとき、キューメッセージスケジューラー４１２は、画像形成装置が印刷可能な場合は、優先度は、一番高く設定する。一方、キューメッセージスケジューラー４１２は、画像形成装置が印刷できない状況である場合は、優先度は、一番低く設定する。
また、画像形成装置１０４の情報として画像形成装置の印刷要求ジョブの出力予定時間を利用する場合を説明する。この場合、キューメッセージスケジューラー４１２は、出力予定時間を０分、５分以内、１０分以内、１５分以内・・・と５分毎に優先度を設定する。例えば、キューメッセージスケジューラー４１２は、出力予定時間０分のものを優先度１、５分以内のものを優先度２、１５分以内のものを優先度３・・・と５分毎に優先度を設定する。
【００３０】
プリント要求を処理する優先度が決定すると、キューメッセージスケジューラー４１２は、その優先度に応じてキューメッセージ管理テーブル４１３にキューメッセージを登録する（Ｓ３１７）。
キューメッセージ管理テーブル４１３では、キューメッセージの優先度に応じてキューメッセージリストを保有している。キューメッセージリストは、一定のキューメッセージのみを保存可能である。キューメッセージスケジューラー４１２は、処理依頼キュー４１４に対しては、キューメッセージ管理テーブル４１３のキューメッセージリスト単位で依頼を行う。優先度に応じてキューメッセージ管理テーブル４１３にキューメッセージを登録する際に、希望するキューメッセージのリストに登録できない場合、キューメッセージスケジューラー４１２は、優先度を下げたリストに登録する。
メッセージに記された処理要求種別を判断（Ｓ３１２）した結果、処理要求種別が状態変更通知である場合、キューメッセージスケジューラー４１２は、キューメッセージからリクエスタ情報及び受付順番を取得する。そして、キューメッセージスケジューラー４１２は、受付順番に基づき、キューメッセージ管理テーブル４１３から該当するキューメッセージを検索する（Ｓ３１３）。検索した結果、該当するキューメッセージが存在した場合（Ｓ３１４において存在）、キューメッセージスケジューラー４１２は、キューメッセージ管理テーブル４１３に登録されたキューメッセージの優先度を変更する（Ｓ３１５）。該当のキューメッセージが存在しない場合、キューメッセージスケジューラー４１２は、何もしないで処理を終了する。
【００３１】
図１１Ｃを用いてネットワークプルプリントシステム１０２のキューメッセージスケジューラー４１２の処理依頼キュー４１４に関する処理を説明する。
キューメッセージスケジューラー４１２は、キューメッセージ管理テーブル４１３に未処理の要求が存在するかを確認する（Ｓ３２１）。確認した結果未処理の要求が存在しない場合、キューメッセージスケジューラー４１２は、新規要求は存在しないため、処理を何もしない。未処理の要求が存在する場合、キューメッセージスケジューラー４１２は、処理依頼キューの状況を確認する（Ｓ３２２）。処理依頼キューの状況とは、例えば、処理依頼キューに未処理要求が何件存在するか等である。処理依頼キューを確認した結果、キューメッセージスケジューラー４１２は、処理依頼キューの状況が定められた条件を満たしているか否か、例えば未処理件数が一定数以上存在するか否か、を確認する（Ｓ３２３）。
確認した結果、一定数存在する場合、キューメッセージスケジューラー４１２は、処理依頼キュー４１４への操作を何も行わない。理由は、未処理件数が一定数残っているにもかかわらず、次の要求を登録すると先行して投入した要求よりも後から追加した要求が処理されてしまう可能性が高くなるためである。一定数以上存在するかを確認した結果（Ｓ３２３）、一定数存在しない場合、キューメッセージスケジューラー４１２は、キューメッセージ管理テーブル４１３に登録されたキューメッセージリストから優先度が最優先のリストを取得する。そして、キューメッセージスケジューラー４１２は、このリストに登録されたキューメッセージを処理依頼キュー４１４に登録する。そして、キューメッセージスケジューラー４１２は、キューメッセージ管理テーブル４１３から取得したキューメッセージリストを、削除（Ｓ３２５）して処理を終了する。
図１２は、本実施形態のシステムにおけるネットワークプルプリント処理の流れを表したシーケンス図である。画像形成装置１０４がユーザからネットワークプルプリント要求を受けてから、印刷が完了するまでの処理の流れを記している。
【００３２】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００３３】
以上、上述した各実施形態によれば、クラウドコンピューティングシステムのキューのように、受付順番通りに要求が処理されないシステムであっても、要求を受け付けた順番で処理を行うことが可能となる。
更に、同時に複数のクライアントからの要求を受け付けた場合、クライアントの状況に応じてサーバー側でのクライアントからの要求処理の優先度を自動で決定することで、クライアントの待ち時間を最小化することができる。
【００３４】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
例えば、上述した実施形態１では、キューメッセージスケジューラー４１２は、受付順番と、画像形成装置１０４の情報と、に基づいて、優先度を決定する例を説明した。しかしながら、キューメッセージスケジューラー４１２は、受付順番だけに基づいて、優先度を決定するようにしてもよい。この様にすることによって、クラウドコンピューティングシステムのキューのように、受付順番通りに要求が処理されないシステムであっても、要求を受け付けた順番で処理を行うことが可能となる。
また、キューメッセージスケジューラー４１２が、受付順番と、画像形成装置１０４の情報と、に基づいて、優先度を決定する。このようにすることによって、同時に複数のクライアント（画像形成装置）からの要求を受け付けた場合、クライアントの状況に応じてネットワークプルプリントシステム１０２側で、クライアントからの要求処理の優先度を自動で決定することができる。その結果、ユーザの待ち時間を最小化することができる。
【図１】
2012083845.tif 000003
【図２】
2012083845.tif 000004
【図３】
2012083845.tif 000005
【図４】
2012083845.tif 000006
【図５】
2012083845.tif 000007
【図６】
2012083845.tif 000008
【図７】
2012083845.tif 000009
【図８Ａ】
2012083845.tif 000010
【図８Ｂ】
2012083845.tif 000011
【図８Ｃ】
2012083845.tif 000012
【図８Ｄ】
2012083845.tif 000013
【図９】
2012083845.tif 000014
【図１０】
2012083845.tif 000015
【図１１Ａ】
2012083845.tif 000016
【図１１Ｂ】
2012083845.tif 000017
【図１１Ｃ】
2012083845.tif 000018
【図１２】
2012083845.tif 000019