(57)【要約】【課題】  画像形成装置ごとにリソースを割り当てた場合、画像形成装置が使用されていない間もリソースが確保され続け、その間、そのリソースは遊休リソースとなってしまう。また、リソースの処理負荷に応じてリソースの確保量を変えると、リソースの必要量が確保量を上回ってしまうことがある。【解決手段】  画像形成装置へのリソース割り当てを管理する調整装置が、画像形成装置の状態が遷移する際に状態イベントを取得する状態取得手段と、そのイベント内容基づいたリソース調整を行う調整手段を有する。【選択図】  図１３
2012043071.tif 000002
【特許請求の範囲】
【請求項１】
第１の情報処理装置から要求されるジョブを処理する第１のリソースと第２の情報処理装置から要求されるジョブを処理する第２のリソースとを調整する調整装置であって、
前記第１の情報処理装置の状態の遷移を識別するための情報を取得する状態取得手段と、
前記状態取得手段で取得した情報が第１の状態から第２の状態への遷移を識別するための第１の情報であった場合は、前記第１のリソースを減少させ、
前記状態取得手段で取得した情報が前記第２の状態から前記第１の状態への遷移を識別するための第２の情報であった場合は、前記第２のリソースを前記第１のリソースに変更する調整手段と、
を有する調整装置。
【請求項２】
前記調整手段は、
前記状態取得手段で取得した情報が前記第１の情報であった場合、前記第１のリソースを前記第２のリソースに変更することにより、前記第１のリソースを減少させることを特徴とする請求項１に記載の調整装置。
【請求項３】
前記調整手段は、
前記状態取得手段で取得した情報が前記第１の情報であった場合、前記第１のリソースを削除することにより、前記第１のリソースを減少させることを特徴とする請求項１に記載の調整装置。
【請求項４】
前記第１の情報は、前記ジョブの処理を要求する状態から前記ジョブの処理を要求しない状態への遷移を識別するための情報であり、
前記第２の情報は、前記ジョブの処理を要求しない状態から前記ジョブの処理を要求する状態への遷移を識別するための情報であることを特徴とする請求項１乃至３の何れか１項に記載の調整装置。
【請求項５】
前記第１の情報は、印刷ユニットを有する前記第１の情報処理装置からの、前記印刷ユニットの使用可能状態から使用不可状態への遷移を識別するための情報であり、
前記第２の情報は、当該第１の情報処理装置からの、前記印刷ユニットの使用不可状態から使用可能状態への遷移を識別するための情報であることを特徴とする請求項１乃至３の何れか１項に記載の調整装置。
【請求項６】
前記第１の情報は、読み込みユニットを有する前記第１の情報処理装置からの、前記読み込みユニットの使用可能状態から使用不可状態への遷移を識別するための情報であり、
前記第２の情報は、当該第１の情報処理装置からの、前記読み込みユニットの使用不可状態から使用可能状態への遷移を識別するための情報であることを特徴とする請求項１乃至３の何れか１項に記載の調整装置。
【請求項７】
第１の情報処理装置から要求されるジョブを処理する第１のリソースと第２の情報処理装置から要求されるジョブを処理する第２のリソースとを調整する調整方法であって、
状態取得手段が、前記第１の情報処理装置の状態の遷移を識別するための情報を取得する状態取得工程と、
調整手段が、前記状態取得工程で取得した情報が第１の状態から第２の状態への遷移を識別するための第１の情報であった場合は、前記第１のリソースを減少させ、
前記状態取得手段で取得した情報が前記第２の状態から前記第１の状態への遷移を識別するための第２の情報であった場合は、前記第２のリソースを前記第１のリソースに変更する調整工程と、
を有する調整方法。
【請求項８】
請求項１乃至６の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラム。
【請求項９】
ジョブの処理を要求する第１の情報処理装置及び第２の情報処理装置と、
前記第１の情報処理装置から要求されるジョブを処理する第１のリソースと、
前記第２の情報処理装置から要求されるジョブを処理する第２のリソースと、
前記第１のリソース及び第２のリソースを調整する調整装置と、
を有する調整システムであって、
前記第１の情報処理装置は、
当該第１の情報処理装置が第１の状態から第２の状態に遷移した場合は、第１の情報を前記調整装置に通知し、
当該第１の情報処理装置が第２の状態から第１の状態に遷移した場合は、第２の情報を前記調整装置に通知する通知手段を有し、
前記調整装置は、
前記通知手段からの通知される情報を取得する状態取得手段と、
前記状態取得手段で取得した情報が前記第１の情報であった場合は、前記第１のリソースを減少させ、
前記状態取得手段で取得した情報が前記第２の情報であった場合は、前記第２のリソースを前記第１のリソースに変更する調整手段と、を有する
ことを特徴とする調整システム。
【請求項１０】
情報処理装置から要求されるジョブを処理する第１のリソースと、前記情報処理装置と異なる装置から要求されるジョブを処理する第２のリソースとを調整する調整装置とネットワークを介して接続される前記情報処理装置であって、
前記情報処理装置は、
ジョブの処理を要求する処理要求手段と、
前記情報処理装置の状態の遷移を検知する検知手段と、
前記検知手段が検知した状態の遷移を識別するための情報を前記調整装置に通知する通知手段を有し、
前記調整装置は、前記情報処理装置の通知手段から通知される情報が第１の状態から第２の状態への遷移を識別するための情報であった場合は前記第１のリソースを減少させ、前記情報処理装置の通知手段から通知される情報が第１の状態から第２の状態への遷移を識別するための情報であった場合は前記第２のリソースを前記第１のリソースに変更することを特徴とする情報処理装置。
【請求項１１】
前記通知手段は、前記処理要求手段がジョブの処理を要求した場合、前記情報を前記調整装置に通知することを特徴とする請求項１０に記載の情報処理装置。
【請求項１２】
前記通知手段は、前記検知手段が状態の遷移を検知して所定時間の経過後に、前記情報を前記調整装置に通知することを特徴とする請求項１０に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、調整システム、調整装置、調整方法、及びそのプログラムに関するものである。
【背景技術】
【０００２】
サーバーコンピュータの有するリソースを利用して、クライアントコンピュータが要求するジョブを処理するクライアント・サーバーシステムが広く普及している。ここでいうリソースは、ＣＰＵなどのジョブの処理を実行するコンピューティングリソースとＨＤＤなどのデータを記憶するストレージリソースを含んでいる。
【０００３】
また、近年、ネットワークを介してクライアントコンピュータに接続されるサーバーコンピュータ側で各種処理を行う形態として、クラウドコンピューティングやＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）という技術が利用され始めている。クラウドコンピューティングでは、サーバーコンピュータ側の多くのリソースを利用し、クライアントコンピュータの要求するデータ変換やデータ処理などの各種ジョブを分散実行することで、多くのクライアントコンピュータからの要求を同時に処理することが可能となる。
【０００４】
ところで、特定のクライアントコンピュータ（専有クライアント）に対してサーバーコンピュータ側の一群のリソースを専有させる専有リソースモデルと、複数のクライアントコンピュータ（共有クライアント）に対してサーバーコンピュータ側の一群のリソースを共有させる共有リソースモデルとの異なるリソースモデルが混在するクライアント・サーバーシステムが存在する（特許文献１）。このクライアント・サーバーシステムにおける専有リソースモデルでは、専有リソースモデルで利用されるリソースが専有クライアントの要求するジョブを処理する。また、共有リソースモデルでは、共有リソースモデルで利用されるリソースが共有クライアントの要求するジョブを処理する。
【０００５】
クライアント・サーバーシステムにおいて、クライアントコンピュータからジョブの処理が要求されなければ、サーバーコンピュータ側のリソースは遊休リソースとなる。特に、専有リソースモデルを有するクライアント・サーバーシステムにおいては、専有クライアントがジョブの処理を要求しない期間中、専有リソースモデルのリソースは無駄に専有されているだけの遊休リソースとなる。特許文献１には、システム管理サーバーによって専有リソースモデルのリソースの処理負荷を検出して、検出した処理負荷に基づいて専有リソースモデルのリソースの量を調整することで、リソースの利用効率の低下を軽減する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−１１０３４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１が開示する技術では、専有リソースモデルのリソースの量を専有リソースモデルのリソースの処理負荷に基づき調整するため、専有クライアントからのジョブ処理が暫くの間をおいて要求された場合、専有リソースモデルのリソースは要求されたジョブを処理するのに十分な量のリソースが確保されているとは限らない。その結果、ジョブ処理に充分なリソースが確保されるまでの間、専有リソースモデルにおけるジョブの処理効率が低下する。
【０００８】
本発明では、クライアントコンピュータがジョブ処理を要求した場合に、そのジョブを処理するのに十分な量のリソースを前もって確保しながらも、リソースの利用効率の低下を軽減するリソース調整システム、リソース調整装置、リソース調整方法、及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施形態の調整装置は、第１の情報処理装置から要求されるジョブを処理する第１のリソースと第２の情報処理装置から要求されるジョブを処理する第２のリソースとを調整する調整装置であって、前記第１の情報処理装置の状態の遷移を識別するための情報を取得する状態取得手段と、前記状態取得手段で取得した情報が第１の状態から第２の状態への遷移を識別するための第１の情報であった場合は、前記第１のリソースを減少させ、前記状態取得手段で取得した情報が前記第２の状態から前記第１の状態への遷移を識別するための第２の情報であった場合は、前記第２のリソースを前記第１のリソースに変更する調整手段と、を有する。
【発明の効果】
【００１０】
本発明によると、サーバーコンピュータ側のリソースを効率的に確保することができ、また利用効率の低下を軽減することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例におけるネットワークスキャンプリントシステムの構成を示す図である。
【図２】本発明の実施例における画像形成装置の内部構成の詳細を示す図である。
【図３】本発明の実施例における情報処理装置の内部構成の詳細を示す図である。
【図４】本発明の実施例における各装置が有する機能を示す図である。
【図５】本発明の実施例におけるプラットフォームシステムの詳細を示す図である。
【図６】本発明の実施例におけるキューメッセージを示す図である。
【図７】本発明の実施例におけるリソースモデルを示す図である。
【図８】本発明の実施例におけるリソーステーブルを示す図である。
【図９】本発明の実施例におけるブロブストレージ内のデータ配置構造を示す図である。
【図１０】本発明の実施例におけるプリントおよびスキャンの処理の流れを示すシーケンス図である。
【図１１】本発明の実施例におけるプリントアプリケーションによる印刷データ選択画面およびスキャンアプリケーションによる格納先選択画面を示す図である。
【図１２】本発明の実施例におけるバックエンド処理部の構造図である。
【図１３】本発明の実施例１におけるリソース調整の処理の流れを示すシーケンス図である。
【図１４】本発明の実施例３におけるリソース調整の処理の流れを示すシーケンス図である。
【図１５】本発明の実施例２におけるリソース調整の処理の流れを示すシーケンス図である。
【図１６】本発明の実施例におけるリソース調整を開始するために画像形成装置のデバイスタイプを判断するフローチャートである。
【発明を実施するための形態】
【００１２】
（実施例１）
本実施例について、クライアント・サーバーシステムとして、ネットワークを介してスキャン処理やプリント処理を行うシステム（ネットワークスキャンプリントシステム）を用いて説明する。
【００１３】
本実施例におけるネットワークスキャンプリントシステムを構成している各装置について、図１を参照して詳細に説明する。図１には、ネットワークスキャンプリントシステムを構成している各装置がインターネット１０１及びネットワーク１０７、１０８を介して接続されている様子が示されている。ネットワークスキャンプリントシステムを構成している各装置とは、サーバーコンピュータ群１０２、文書サーバー１０３、画像形成装置１０４、ＰＣ端末１０５である。
【００１４】
ネットワーク１０７、１０８は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、画像形成装置１０４とＰＣ端末１０５が属するネットワーク１０８からは、サーバーコンピュータ群１０２などが属するネットワーク１０７と、ファイアウォールを越えて通信が可能である。ネットワーク１０７、１０８、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。図１において、サーバーコンピュータ群１０２は、複数台のサーバーコンピュータで構成されているが、１台のサーバーコンピュータで構成されていても良い。
【００１５】
次に、図１のネットワークスキャンプリントシステムを構成している各装置の内部構成について詳細に説明する。始めに、画像形成装置１０４の内部構成について図２を用いて説明する。図２は、画像形成装置１０４の内部構成を例示するブロック図である。
【００１６】
画像形成装置１０４は、画像処理ユニット２０１、印刷ユニット２０２、および読み込みユニット２０３、消耗品管理ユニット２０９、電源制御ユニット２１０を有する。画像処理ユニット２０１は、ＣＰＵ２０４、直接記憶部２０５、間接記憶部２０６、ユーザーインターフェース２０７、外部インターフェース２０８を有する。
【００１７】
ＣＰＵ２０４は、間接記憶部２０６に記憶されている所定のプログラムを直接記憶部２０５にロードし、このプログラムを実行することで、所定の処理を実行する。直接記憶部２０５はＲＡＭにより実現される。間接記憶部２０６はＳＳＤやＨＤＤなどの記憶媒体により実現され、これらの記憶媒体にアプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境（プラットフォーム）を提供するものである。なお、ＣＰＵ２０４はマルチプロセッサであっても良い。
【００１８】
ここで、プラットフォームプログラムを実行することにより実現される、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションプログラム（以下アプリケーション）を画像形成装置１０４のＣＰＵ２０４で実行できる他、画像形成装置１０４の操作画面をカスタマイズすることが可能になる。
【００１９】
プラットフォームの実現方法について説明する。ＣＰＵ２０４は、間接記憶部２０６に記憶されたプラットフォームプログラムを直接記憶部２０５にロードする。ロードが完了するとＣＰＵ２０４は、プラットフォームプログラムを実行することができる状態になる。本実施例では、ＣＰＵ２０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。
【００２０】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本実施例において、プラットフォーム上で、例えばプリントリクエストを受け付ける印刷ソフトウェアプログラム（以下、印刷ソフトウェア）が動作している。印刷ソフトウェアは、ネットワークを介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）と言った通信プロトコルによって印刷データを受信できる。印刷ソフトウェアは受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは印刷データの処理を開始する。なお、印刷データが処理をせずに印刷できるようなものであれば、ファームウェアは印刷データ処理を省く。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。
【００２１】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部２０６に記憶されたアプリケーションプログラムを直接記憶部２０５にロードする。ロードが完了すると、アプリケーションプログラムがプラットフォーム上で実行可能な状態になる。そして、ＣＰＵ２０４がプラットフォーム上でアプリケーションプログラムを実行する。このように、ＣＰＵ２０４がプラットフォーム上でアプリケーションプログラムを実行し、ソフトウェアサービスを提供できるプラットフォームの機能を、本実施例ではプラットフォームアプリケーションと呼ぶ。
【００２２】
ユーザーインターフェース２０７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。
【００２３】
外部インターフェース２０８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０４は、ネットワーク１０７、１０８及びインターネット１０１を介して、ＰＣ端末１０５、サーバーコンピュータ群１０２等と通信可能である。
【００２４】
印刷ユニット２０２は、印刷データ処理された印刷データを記録媒体に印字する機能を持つ。読み込みユニット２０３は、原稿台の上に置かれた原稿を読み取り、原稿画像を生成する機能を持つ。本実施例における読み込みユニット２０３は、スキャナである。
【００２５】
消耗品管理ユニット２０９は、印刷に必要な消耗品（トナーやインク、用紙など）を格納管理するユニットである。印刷を行うのに必要な消耗品の不足（トナー・インク切れや用紙切れ）を検知すると、消耗品管理ユニット２０９は消耗品切れイベントをプラットフォームアプリケーションに対して発行する。また消耗品を充填して印刷可能な状態となったことを検知すると、消耗品管理ユニット２０９は消耗品充填イベントをプラットフォームアプリケーションに対して発行する。これら消耗品切れイベントや消耗品充填イベントを受信したプラットフォームアプリケーションは、そのイベントに応じた処理を実行する事が可能である。
【００２６】
電源制御ユニット２１０は、画像形成装置１０４の電源を制御するために画像形成装置１０４の状態の変化を検知し、この検知内容に応じた処理の実行をＣＰＵ２０４に指示する。
【００２７】
たとえば、電源制御ユニット２１０が画像形成装置１０４の電源スイッチがユーザーにより押下され電源オンとされたことを検知した場合、画像形成装置１０４を動作可能な通常状態に切りかえる起動処理が実行される。電源制御ユニット２１０はＣＰＵ２０４に対して画像形成装置１０４を起動するために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行するように指示し、画像形成装置１０４が起動される。起動処理のプログラムを実行するＣＰＵ２０４は、定められた起動処理を完了すると、起動イベントをプラットフォームアプリケーションに対して発行する。
【００２８】
また、たとえば、電源制御ユニット２１０が画像形成装置１０４の電源スイッチがユーザーにより押下され電源オフとされたことを検知した場合、画像形成装置１０４を終了状態に切り替えるシャットダウン処理が実行される。電源制御ユニット２１０はＣＰＵ２０４に対して画像形成装置１０４をシャットダウンするために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行するように指示し、画像形成装置１０４がシャットダウンされる。シャットダウン処理のプログラムを実行するＣＰＵ２０４は、定められたシャットダウン処理を開始する時に、シャットダウンイベントをプラットフォームアプリケーションに対して発行する。
【００２９】
また、たとえば、電源制御ユニット２１０が通常状態の画像形成装置１０４の節電スイッチがユーザーにより押下され節電オンとされたことを検知した場合や、画像形成装置１０４が一定期間処理を実行しなかったことを電源制御ユニット２１０が検知した場合、画像形成装置１０４を省電力状態に切り替えるスリープ処理が実行される。電源制御ユニット２１０はＣＰＵ２０４に対して画像形成装置１０４をスリープさせるために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行するように指示し、画像形成装置１０４がスリープする。スリープ処理のプログラムを実行するＣＰＵ２０４は、定められたスリープ処理を開始する時に、スリープイベントをプラットフォームアプリケーションに対して発行する。
【００３０】
また、たとえば、省電力状態の画像形成装置１０４の節電スイッチがユーザーにより押下され節電オフとされたことを検知した場合、画像形成装置１０４を省電力状態から復旧させるスリープ復旧処理が実行される。電源制御ユニット２１０により、画像形成装置１０４を省電力状態から復旧させるスリープ復旧処理が実行される。電源制御ユニット２１０はＣＰＵ２０４に対して画像形成装置１０４を省電力状態から復旧させるために必要なプログラムを間接記憶部２０６から直接記憶部２０５へとロードして実行するように指示し、画像形成装置１０４が省電力状態から復旧する。スリープ復旧処理のプログラムを実行するＣＰＵ２０４は、定められたスリープ復旧処理を完了すると、スリープ復旧イベントをプラットフォームアプリケーションに対して発行する。
【００３１】
これらの起動・シャットダウン・スリープ・スリープ復旧の各イベントは状態イベントとしてプラットフォームアプリケーションで受信する事が可能で、プラットフォームアプリケーションはそのイベントに応じた処理を実行する事が可能である。
【００３２】
次に、サーバーコンピュータ群１０２の各サーバー、文書サーバー１０３、ＰＣ端末１０５のいずれかとして機能する情報処理装置の内部構成について図３を用いて説明する。図３は、情報処理装置１０６の内部構成を例示するブロック図である。情報処理装置１０６は、ＣＰＵ３０１、直接記憶部３０２、間接記憶部３０３、ユーザーインターフェース３０４、外部インターフェース３０５から構成されている。
【００３３】
ユーザーインターフェース３０４は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。
【００３４】
ＣＰＵ３０１は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示する。ＣＰＵ３０１は、ＣＰＵにより実現される。直接記憶部３０２は、ＣＰＵ３０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ３０１が実行するプログラムは直接記憶部３０２にロードされる。直接記憶部３０２は、ＲＡＭで構成されている。間接記憶部３０３は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部３０３に記憶されている各種プログラムは、ＣＰＵ３０１がプログラムを実行する際に直接記憶部３０２へ移動する。間接記憶部３０３は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＳＳＤまたは、ＨＤＤなどで構成されている。外部インターフェース３０５は、ネットワーク１０７、１０８などに接続されており、これらネットワークなどに接続されている他の装置と通信が可能となる。
【００３５】
以上、画像形成装置１０４の説明と情報処理装置１０６を分けて説明したが、情報処理装置１０６が電源制御ユニット２１０を有しても良く、また、画像形成装置１０４は情報処理装置１０６として機能する。
【００３６】
次に、本実施例のネットワークスキャンプリントシステムにおける各装置が持つ機能について図４を参照しながら詳細に説明する。図４は、ネットワークスキャンプリントシステムにおける各装置の機能ブロック図である。
【００３７】
始めに、複数台のサーバーコンピュータで構成されるサーバーコンピュータ群１０２の機能について説明する。本実施例におけるサーバーコンピュータ群１０２は、クラウドコンピューティングシステムの一例である。サーバーコンピュータ群１０２は、要求受信部４０１、テーブルストレージ４０４、ブロブストレージ４０５、キューストレージ４０３、状態受信部（状態取得手段）４１１の機能を有する。サーバーコンピュータ群１０２は、プリント用、スキャン用それぞれのためのバックエンド処理部として、プリント用バックエンド処理部４０２、スキャン用バックエンド処理部４１０の機能を有する。本実施例では、要求受信部４０１を有するサーバーコンピュータが少なくとも１台以上は存在する。また、状態受信部４１１を有するサーバーコンピュータが少なくとも１台以上は存在する。また、プリント用バックエンド処理部４０２を有するサーバーコンピュータが少なくとも１台以上は存在し、スキャン用バックエンド処理部４１０を持つサーバーコンピュータが少なくとも１台以上は存在する。また、テーブルストレージ４０４、ブロブストレージ４０５、キューストレージ４０３の各機能を有するサーバーコンピュータが少なくとも１台存在する。上述の機能が夫々別のサーバーコンピュータ上にあっても問題はない。
【００３８】
要求受信部４０１は、ＰＣ端末１０５、または画像形成装置１０４から送られてきた処理依頼を受け付ける機能を提供する。
【００３９】
プリント用バックエンド処理部４０２は、処理プログラムを用いて処理依頼に対する処理を行う機能を提供する。具体的には、プリント用バックエンド処理部４０２は、プリント用バックエンド処理部４０２を実行しているサーバーコンピュータの直接記憶部に処理プログラムをロードし処理を行う。
【００４０】
スキャン用バックエンド処理部４１０は、処理プログラムを用いて処理依頼に対する処理を行う機能を提供する。具体的には、スキャン用バックエンド処理部４１０は、スキャン用バックエンド処理部４１０を実行しているサーバーコンピュータの直接記憶部に処理プログラムをロードし処理を行う。
【００４１】
状態受信部４１１は、画像形成装置１０４から送られてきた状態情報を受け付ける機能を提供する。
【００４２】
ファブリックコントローラ４１２は、要求受信部４０１、状態受信部４１１、プリント用バックエンド処理部４０２、スキャン用バックエンド処理部４１０を管理する機能を提供する。この機能の詳細については、図５を用いて後述する。
【００４３】
要求受信部４０１は、図３の間接記憶部３０３に保存されている要求受信プログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。
【００４４】
プリント用バックエンド処理部４０２は、図３の間接記憶部３０３に保存されているプリント用バックエンド処理プログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。
【００４５】
スキャン用バックエンド処理部４１０は、図３の間接記憶部３０３に保存されているスキャン用のバックエンド処理プログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。
【００４６】
状態受信部４１１は、図３の間接記憶部３０３に保存されている状態受信プログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。
【００４７】
ファブリックコントローラ４１２は、図３の間接記憶部３０３に保存されているファブリックコントローラプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。
【００４８】
テーブルストレージ４０４は、画像形成装置１０４に対応するリソースの対応表（リソーステーブル）といったデータの格納・参照を行う機能を提供する。テーブルストレージ４０４は、図３の間接記憶部３０３に保存されているテーブルストレージプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。
【００４９】
ブロブストレージ４０５は、プリント用バックエンド処理部４０２により処理された実行結果のデータを始めとする各種データを保存しておく機能を提供する。ブロブストレージ４０５は図３の間接記憶部３０３に保存されているブロブストレージプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。
【００５０】
キューストレージ４０３は、次のような機能を提供する。１つ目は、要求受信部４０１とプリント用バックエンド処理部４０２およびスキャン用バックエンド処理部４１０とが非同期でデータ通信するための機能を提供する。２つ目は、キューに追加されているキューメッセージを不可視、または可視にする機能を提供する。なお、キューとは、キューストレージサービス部４０５により実現される記憶機能であって、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）と呼ばれるリスト構造によって実現される。
【００５１】
１つ目の機能について説明する。要求受信部４０１とプリント用バックエンド処理部４０２およびスキャン用バックエンド処理部４１０は次のような方法で通信する。始めに、ユーザーからの処理依頼を受けた要求受信部４０１は、ユーザーからの処理依頼に応じたキューメッセージと呼ばれるチケットを作成する。キューメッセージは要求受信部４０１によってキューに格納される。プリント用バックエンド処理部４０２もしくはスキャン用バックエンド処理部はキューからキューメッセージを取得する。プリント用バックエンド処理部４０２もしくはスキャン用バックエンド処理部４１０は、キューメッセージを取得し、キューメッセージを参照してユーザーからの処理依頼を処理する。これにより、ユーザーからの処理依頼を実行することになる。このように、キューストレージ４０３を利用することで要求受信部４０１とプリント用バックエンド処理部４０２およびスキャン用バックエンド処理部４１０は非同期で通信を行うことが可能になる。１つ目の機能のさらに詳細な説明と２つ目の機能の説明については後述する。なお、キューストレージ４０３は、図３の間接記憶部３０３に保存されているキューストレージプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。
【００５２】
以上がサーバーコンピュータ群１０２の機能の説明になるが、さらに詳細な説明については後述する。
【００５３】
次に、文書サーバー１０３の機能について説明する。文書サーバー１０３は、文書リポジトリ４０６の機能を持つ。文書リポジトリ４０６は、図３の間接記憶部３０３によって実現される。例えば、文書リポジトリ４０６には、ユーザーがＰＣ端末１０５、または画像形成装置１０４から印刷指示したコンテンツが保存されている。文書リポジトリ４０６に保存されているコンテンツは、予め保存されているコンテンツの他に次のようなコンテンツも保存されている。
【００５４】
そのコンテンツとは、ユーザーがＰＣ端末１０５の有するブラウザ４０７を介してサーバーコンピュータ群１０２上のアプリケーションで作成したコンテンツである。これにより、サーバーコンピュータ群１０２上のアプリケーションを用いて作成したコンテンツであっても、ＰＣ端末１０５にアプリケーションをインストールすることなく容易に印刷できる。なお、上述のサーバーコンピュータ群１０２上のアプリケーションとは、文書作成アプリケーション、画像作成アプリケーション、帳票管理アプリケーション等を始めとする各種アプリケーションのことである。これらのアプリケーションは図３の間接記憶部３０３に保持されており、実行が指示されると直接記憶部３０２にロードされ、ＣＰＵ３０１により実行される。
【００５５】
次に、画像形成装置１０４について詳細に説明する。画像形成装置１０４には、デバイスブラウザ４０９、プラットフォームアプリケーション４０８の機能がある。デバイスブラウザ４０９は、ネットワーク１０８を介して接続されているデバイス内に保存されているデータや情報をユーザーが閲覧することができる機能を持つ。
【００５６】
デバイスブラウザ４０９は、図２の間接記憶部２０６に保存されているデバイスブラウザプログラムが、直接記憶部２０５にロードされ、ＣＰＵ２０４により実行されることで実現される。また、ユーザーは、デバイスブラウザ４０９を用いてコンテンツの印刷指示および紙原稿の読み込み指示を出すことができる。デバイスブラウザ４０９は、例えば、Ｗｅｂブラウザである。
【００５７】
プラットフォームアプリケーション４０８は、各種サービスを提供する機能を持つ。プラットフォームアプリケーション４０８は、プラットフォーム上で動作するアプリケーションプログラムによって実現される。本発明の実施例において、プラットフォームアプリケーション４０８は印刷ソフトウェア、読み込みソフトウェア、状態監視ソフトウェアのサービスを提供する。
【００５８】
印刷ソフトウェアが提供するサービスは、プラットフォームアプリケーション４０８が受信した印刷データをファームウェアに送信しファームウェアに対して印刷ユニットでの印刷を指示する。また、このサービスは要求受信部４０１に対して印刷データの生成が終了したかどうかの確認を行う。その際、このサービスは要求受信部４０１が作成したブロブＵＲＩを基に生成確認を行う。
【００５９】
読み込みソフトウェアが提供するサービスは、ファームウェアに対して読み込みユニットでの原稿読み込み指示を行い、読み込まれた原稿画像を受信する。また、このサービスは受信した原稿画像データを要求受信部４０１に対して送信することができる。
【００６０】
状態監視ソフトウェアが提供するサービスは、画像形成装置１０４内で発生した画像形成装置１０４の状態に関する情報（状態イベント）をキャッチして、その状態イベントの内容と画像形成装置１０４を一意に識別するデバイスＩＤとを状態受信部４１１へ送信する。デバイスＩＤは、間接記憶部２０６に記憶されているものとする。
【００６１】
検知部４１３は、画像形成装置１０４の状態の変化を検知し、検知した情報に基づく状態イベントをプラットフォームアプリケーション４０８へ発行する機能を持つ。本実施例にて、この検知部４１３は、起動処理などのプログラムを実行するＣＰＵ２０４及び電源制御ユニット２１０、並びに、消耗品管理ユニットなどで構成されている。なお、検知部４１３を構成する要素はこれらに限定されない。
【００６２】
次に、ＰＣ端末１０５について詳細に説明する。ＰＣ端末１０５は、ブラウザ４０７の機能を持つ。ブラウザ４０７は、ネットワーク１０８を介して接続されているデバイス内や文書サーバー１０３に保存されているデータや情報をユーザーが閲覧することができる機能を持つ。図３の間接記憶部３０３に保存されているブラウザプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。ブラウザ４０７は、例えば、Ｗｅｂブラウザである。
【００６３】
以上が、本実施例のネットワークスキャンプリントシステムにおける各装置が持つ機能の説明になる。
【００６４】
図５は、サーバーコンピュータ群１０２が提供するプラットフォームシステムの例である。このプラットフォームシステムは、サーバーコンピュータ群１０２を構成する各サーバーのＣＰＵ３０１が、間接記憶部３０３に記憶されている制御プログラムを、直接記憶部３０２を一時記憶領域として使用しながら実行することにより実現される。また、このプラットフォームシステムは、記憶領域としても間接記憶部３０３を利用する。このプラットフォームの利用者は、サーバーコンピュータ群１０２内にある物理ハードウェア・リソースをリソースとして使用できる。
【００６５】
サーバーコンピュータ群１０２のプラットフォームシステムは、次のような機能を持つ。ヴァーチャルマシン５０１、および５０２。ファブリックコントローラ５０３。ロードバランサー５０４。キューストレージ５０５。テーブルストレージ５０６。ブロブストレージ５０７である。
【００６６】
本実施例のサーバーコンピュータ群１０２上で動作するプラットフォームシステムの内部には、ヴァーチャルマシン５０１、５０２が複数存在する。ヴァーチャルマシン５０１は１つであっても良い。ヴァーチャルマシンとは、仮想化技術によって物理的なサーバーコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられ、このインスタンスを増やすことを「ヴァーチャルマシンを起動する」といい、インスタンスを減らすことを「ヴァーチャルマシンをシャットダウンする」という。各インスタンスは夫々固有のインスタンスＩＤを有する。本実施例では、インスタンス数１つ（即ち、ヴァーチャルマシン１台）に対してサーバーコンピュータ群１０２内の１台のサーバーコンピュータが割り当てられるものとするが、複数のインスタンスに対して１台のサーバーコンピュータが割り当てられても良い。
【００６７】
ヴァーチャルマシン５０１は、要求受信部５０９１及び状態受信部５０９２を備える受信部５０９、受信部エージェント５１０を有する。要求受信部５０９１は図４の要求受信部４０１に対応するもので、後述するロードバランサー５０４を介してユーザーからの処理依頼を受信する。また、要求受信部５０９１は、キューストレージ５０５を介してバックエンド処理部へ処理依頼を送信する。状態受信部５０９２は、図４の状態受信部４１１に対応するもので、後述するロードバランサー５０４を介して画像形成装置１０４の状態に関する情報（状態イベント）を受信する。また、状態受信部５０９２は、キューストレージ５０５を介してバックエンド処理部へ受信した状態イベントに基づいた処理依頼を送信する。
【００６８】
受信部５０９の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、ヴァーチャルマシン５０１の外部にあるロードバランサー５０４を通じて行われる。ロードバランサー５０４は、外部ネットワークからの要求を一元的に管理し、受信部５０９と同等な機能を有する複数のヴァーチャルマシンに対し、選択的に要求を転送するものである。受信部エージェント５１０は、ヴァーチャルマシン５０１の使用状況、受信部５０９の稼動状態とエラーを含む各種情報を収集し、ファブリックコントローラ５０３に定期的に送信する。本実施例では、同一のヴァーチャルマシン５０１上に要求受信部５０９１及び状態受信部５０９２の機能を備えたが、別々のヴァーチャルマシン５０１上にこれらの機能を備えても良い。この場合、一方のヴァーチャルマシンは要求受信部５０９１及びそれを監視する受信部エージェント５１０を有し、他方のヴァーチャルマシンは状態受信部５０９２及びそれを監視する受信部エージェント５１０を有するようにしても良い。
【００６９】
本実施例のヴァーチャルマシン５０２は２タイプあり、一方はプリント用バックエンド処理部５１１１及びバックエンド処理部エージェント５１２を有するヴァーチャルマシンであり、他方はスキャン用バックエンド処理部５１１２及びバックエンド処理部エージェント５１２を有するヴァーチャルマシンである。特に指示がなければプリント用バックエンド処理部５１１１及びスキャン用バックエンド処理部５１１２を区別せず、単にバックエンド処理部と呼ぶ。バックエンド処理部は、キューストレージ５０５を介して要求受信部５０９１からの処理依頼を受信する。バックエンド処理部は、キューストレージ５０５を介して要求受信部５０９１から受信した処理依頼を実行する。また、バックエンド処理部は、スケールアウトする。スケールアウトとは、ヴァーチャルマシン５０２が増加し、バックエンド処理部のインスタンスが増加すること指す。バックエンド処理部のインスタンスが増加すると、バックエンド処理部のデータ処理能力が上がる。これにより、ユーザーからの処理依頼に対する結果をより早く返すことができる。バックエンド処理部エージェント５１２は、ヴァーチャルマシン５０２の使用状況、バックエンド処理部の稼動状態、およびバックエンド処理部のエラーを含む各種情報を収集し、ファブリックコントローラ５０３に定期的に送信する。なお、ヴァーチャルマシン５０２上のプリント用バックエンド処理部５１１１、スキャン用バックエンド処理部５１１２は夫々図４で示すプリント用バックエンド処理部４０２、スキャン用バックエンド処理部４１０に対応する。ヴァーチャルマシン５０２は、バックエンド処理プログラムによって実現され、ヴァーチャルマシン５０２の各種機能はバックエンド処理プログラムの制御下にある。なお、本実施例では、別々のヴァーチャルマシン５０２上にプリント用バックエンド処理部５１１１及びスキャン用バックエンド処理部５１１２の機能を備えたが、同一のヴァーチャルマシン５０２上にこれらプリント用バックエンド処理部５１１１及びスキャン用バックエンド処理部５１１２を有するようにしても良い。
【００７０】
ファブリックコントローラ５０３は、図４のファブリックコントローラ４１２に対応している。このファブリックコントローラ５０３は、受信部５０９、バックエンド処理部の各インスタンスを管理している。これにより、各インスタンスの拡張性と可用性が保証される。例えば、受信部５０９、またはバックエンド処理部において、ある特定のインスタンスがサーバーの故障によって停止したとする。この場合、ファブリックコントローラ５０３は、受信部エージェント５１０、またはバックエンド処理部エージェント５１２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ５０３は、新しいインスタンスに処理が委譲されるように新しいヴァーチャルマシンに指示を出す。つまり、新しいヴァーチャルマシンは、故障、もしくはそれに類似する事象によって起動できなくなったヴァーチャルマシンの代替として機能する。結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。また、例えば、バックエンド処理部をスケールアウトさせる場合、ファブリックコントローラ５０３は、受信部５０９からバックエンド処理部のインスタンス数を増加するように指示され、新しいインスタンスを確保してこのインスタンスでバックエンド処理プログラムを実行させることでスケールアウトを実現する。
【００７１】
キューストレージ５０５は、図４のキューストレージ４０３に対応するもので、受信部５０９とバックエンド処理部とが非同期でデータ通信するためのサービスを提供する。受信部５０９及びバックエンド処理部は、キューストレージ５０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。受信部５０９がキューストレージ５０５に対して行う指示とは、キューメッセージ６００の追加指示（挿入）である。バックエンド処理部がキューストレージ５０５に対して行う指示とは、キューメッセージ６００の取得指示、キューメッセージ６００の削除指示である。
【００７２】
受信部５０９とバックエンド処理部が非同期でデータ通信する一連の動作について説明する。受信部５０９は、ユーザーからの処理依頼に応じたキューメッセージ６００を作成し、キューメッセージ６００をキューに追加するようにキューストレージ５０５に追加指示を送信する。追加指示を受信したキューストレージ５０５は、キューにキューメッセージ６００を追加する。バックエンド処理部は、キューメッセージ６００を取得するために、キューストレージ５０５に対しポーリングして取得指示を出す。取得指示を受けたキューストレージ５０５は、キューメッセージ６００と、キューメッセージ６００毎に固有に割り振られたメッセージＩＤとを取得指示に対するレスポンスとしてバックエンド処理部に返す。メッセージＩＤとは、キューメッセージ６００を一意に定めるためにキューメッセージ６００ごとに割り振られた固有の情報であり、処理が終了したバックエンド処理部がキューメッセージ６００を削除指示する際に使用する。バックエンド処理部は、処理依頼を完了すると、メッセージＩＤに対応するキューメッセージの削除指示をキューストレージサービス５０５に対して行う。削除指示を受けたキューストレージ５０５は、バックエンド処理部が指示したメッセージＩＤに対応するキューメッセージ６００をキューから削除する。これにより、削除指示を出したバックエンド処理部以外のバックエンド処理部が同じキューメッセージ６００を処理するという冗長な処理を防ぐことができる。
【００７３】
また、キューストレージ５０５は、キューに追加されているキューメッセージ夫々を個別に不可視、または可視にする機能を持つ。不可視とは、バックエンド処理部がキューに追加されているキューメッセージ６００の取得要求をした場合に、キューストレージ５０５はバックエンド処理部に対してキューメッセージ６００を渡さないことを指す。バックエンド処理部がキューストレージ５０５からキューメッセージ６００を取得すると、取得されたキューメッセージ６００はキュースストレージ５０５によって不可視になる。可視とは、バックエンド処理部がキューストレージに追加されているキューメッセージ６００の取得要求した場合に、キューストレージ５０５がバックエンド処理部に対してキューメッセージ６００を渡すことを指す。バックエンド処理部に取得され不可視になっているキューメッセージ６００は、処理を行っているバックエンド処理部から処理結果が一定時間返ってこない場合にキューストレージ５０５によって可視になる。これにより、バックエンド処理部が異常終了し処理を継続できない場合でも自動的に処理が再実行されることになる。
【００７４】
テーブルストレージ５０６は、図４のテーブルストレージ４０４に対応するもので、データ保存に利用されるストレージである。テーブルストレージ５０６では、データをエンティティと型情報のプロパティを組み合わせた単純な形式でデータを保管する。
【００７５】
ブロブストレージ５０７は、図４のブロブストレージ４０５に対応するもので、データ保存に利用されるストレージである。ブロブストレージ５０７は、バイナリデータの集合を保存する機能を提供する。
【００７６】
次に本実施例におけるリソースモデルについて図７を用いて説明する。本実施例で述べているリソースには、コンピュータリソースとストレージリソースの２種類がある。コンピュータリソースはジョブを処理するリソースのことである。本実施例でいうコンピュータリソースは、プリント用バックエンド４０２やスキャン用バックエンド部４１０を実行しているヴァーチャルマシン５０２のことである。「コンピュータリソースが専有される」とは、そのヴァーチャルマシン５０２が特定の画像形成装置１０４のリクエストしか処理しない状態を指す。また、ストレージリソースとは、ブロブストレージ４０５が保持しているデータおよびデータの保管場所（後述のコンテナ）を指している。本実施例では、単に「リソース」といった場合、コンピュータリソースおよびストレージリソースの両方を含むものとする。
【００７７】
本実施例のクライアント・サーバーシステムにおいては、２種類のリソースモデルが混在する。
【００７８】
一つ目は共有リソースモデルで、複数の画像形成装置で一群のリソースを共有するモデルである。このモデルのリソースを共有リソースと呼ぶ。図７に示すように複数の画像形成装置１０４が存在する場合、それらのリクエストを要求受信部４０１が受け付けるが、その後の処理は画像形成装置１０４に依存せず、共有リソース７０１として確保されている一群のリソースが平等に処理を担うモデルである。本モデルの特徴は使用頻度に波のある画像形成装置１０４からの処理をまとめて処理するため、処理量を平準化することができ、各画像形成装置１０４が夫々必要なリソースを専有して確保した場合に比べて少ないリソースで処理をこなすことができる。ただし、複数の画像形成装置１０４の使用頻度に波があるのが前提なため、多くの画像形成装置１０４が集中して処理を実行しようとすると、処理を行うためのリソース量が不足してしまうため、パフォーマンスが落ちてしまう。
【００７９】
一方、もうひとつのモデルが、専有リソースモデルで、特定の画像形成装置１０４が一群のリソースを専有するモデルである。このモデルのリソースを専有リソースと呼ぶ。図７に示す複数の画像形成装置１０４のうちの一つがこのモデルを採用している場合、そのリクエストを要求受信部４０１が受け付けた後、その後の処理はその画像形成装置１０４に専有されている専有リソース７０２で専有的に処理されるモデルである。専有リソースモデルの特徴は特定の画像形成装置１０４以外の複数の画像形成装置１０４が同時期に処理要求するような場合があっても、特定の画像形成装置１０４からの処理要求に対しては専有するリソースが処理を実行するため、一定のパフォーマンスを維持できる点にある。ただし、その特定の画像形成装置１０４が処理を要求しない場合には、無駄にリソースを専有してしまい遊休リソースが生じる。
【００８０】
次に、本発明の実施例におけるキューメッセージ６００について説明する。図６は、キューメッセージ６００の例を示した図であり、（ａ）はプリント、（ｂ）はスキャン、（ｃ）はコンピュータリソースの割り当て変更、（ｄ）はコンピュータリソースの削除の場合のそれぞれの例である。キューメッセージ６００は、画像形成装置１０４からの処理要求に応じて要求受信部５０９１がバックエンド処理部に依頼する処理の内容を記述したものである。
【００８１】
リクエスト６０１は、キューメッセージを追加するキューストレージ５０５の場所を示している。ヘッダー６０２はキューストレージ５０５へアクセスするための認証情報等を送信する。ここでの認証情報とは、キューストレージ５０５を利用するために必要な文字列のハッシュ値である。キューストレージ５０５はこのヘッダー情報を読み込んで内部に保持している文字列と比較することで認証を行い、ヘッダーを含むキューメッセージ６００を受け入れ可能かどうかを判断する。次に、キューメッセージ６００のメッセージデータコンテンツ部６０３、６０４、６０５、６０６について説明する。メッセージデータコンテンツ部６０３、６０４、６０５、６０６は、ユーザーからの処理依頼や画像形成装置１０４のイベント通知に応じて決定される。
【００８２】
図６（ａ）のメッセージデータコンテンツ部６０３について、＜ＭｅｓｓａｇｅＴｅｘｔ＞は、キューメッセージ６００のメッセージタイプを示す＜Ｔｙｐｅ＞部と、ブロブＵＲＩを示す＜ＢｌｏｂＵＲＩ＞部と、文書ＩＤを示す＜ＤｏｃＩｄ＞部を含んでいる。図６（ａ）の場合、メッセージタイプは”ＰＲＩＮＴ”で、ブロブＵＲＩは“ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｄｅｖｉｃｅ３／ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ”で、文書ＩＤは“ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ”である。ブロブＵＲＩは、ユーザーからの処理依頼に応じて作成される一意な情報である。
【００８３】
図６（ｂ）のメッセージデータコンテンツ部６０４は、＜ＭｅｓｓａｇｅＴｅｘｔ＞は、キューメッセージ６００のメッセージタイプを示す＜Ｔｙｐｅ＞部と、ブロブＵＲＩを示す＜ＢｌｏｂＵＲＩ＞部と、文書名を示す＜ＤｏｃＩｄ＞部分を含んでいる。図６（ｂ）の場合、メッセージタイプは”ＳＣＡＮ”で、ブロブＵＲＩは“ｈｔｔｐ：／／ｓｃａｎ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｄｅｖｉｃｅ３／ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ”で、文書ＩＤは“ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ”である。ブロブＵＲＩは、ユーザーからの処理依頼に応じて作成される一意な情報である。
【００８４】
図６（ｃ）のメッセージデータコンテンツ部６０５は、＜ＭｅｓｓａｇｅＴｅｘｔ＞は、キューメッセージ６００のメッセージタイプを示す＜Ｔｙｐｅ＞部と、キューストレージＵＲＩを示す＜Ｑｕｅｕｅ＞部とを含んでいる。図６（ｃ）の場合、メッセージタイプは”ＭＯＶＥ”で、キューストレージＵＲＩは“ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｑｕｅｕｅ．ｎｅｔ／ｇｌｏｂａｌ／”である。
【００８５】
図６（ｄ）のメッセージデータコンテンツ部６０６は、＜ＭｅｓｓａｇｅＴｅｘｔ＞は、キューメッセージ６００のメッセージタイプを示す＜Ｔｙｐｅ＞部を含んでいる。図６（ｄ）の場合、メッセージタイプは”ＫＩＬＬ”である。
【００８６】
次に、本実施例におけるリソーステーブルについて図８を用いて説明する。リソーステーブル８００では、画像形成装置１０４を一意に識別するデバイスＩＤと、その画像形成装置１０４からのリクエストを処理する際に使用するキューストレージ５０５およびブロブストレージ５０７のアドレスを対応づけて保持する。リソーステーブル８００はテーブルストレージ５０６にて保持される。
【００８７】
図８は、実際に保持されるリソーステーブル８００の一例を示した図である。タグ（ＥＴａｇ）８０１は、バックエンド処理部及び状態受信部４１１がリソーステーブル８００に対して自動的に設定する値で、行データが更新された際に一意の値が書き込まれる。リソーステーブル８００より取得したデータを更新する際に、データ取得時のタグ８０１の値と、データ更新時のタグ８０１の値が異なる場合、他の処理プロセスによりテーブルが更新されたことが識別できる。
【００８８】
パーティションキー（ＰａｒｔｉｔｉｏｎＫｅｙ）８０２とローキー（ＲｏｗＫｅｙ）８０３にてテーブルの行を一意に識別することができる。リソーステーブル８００では、ローキー８０３の値をデバイスＩＤとして管理する。
【００８９】
プリントキューＵＲＩ（Ｐｒｉｎｔ  Ｑｕｅｕｅ  ＵＲＩ）８０４は、プリント用バックエンド処理部４０２がプリントジョブを実行する際に、プリント用バックエンド処理部４０２がキューメッセージ６００を取得するために使用するキューストレージ４０３のＵＲＩが設定される。
【００９０】
スキャンキューＵＲＩ（Ｓｃａｎ  Ｑｕｅｕｅ  ＵＲＩ）８０５は、スキャン用バックエンド処理部４１０がキューメッセージ６００を取得するために使用するキューストレージ４０３のＵＲＩが設定される。
【００９１】
プリントコンテナＵＲＩ（Ｐｒｉｎｔ  Ｃｏｎｔａｉｎｅｒ  ＵＲＩ）８０６は、プリントリクエストを処理する際にプリント用バックエンド処理部４０２から要求受信部４０１へデータを受け渡すのに使用するブロブストレージ４０５内に設けられたコンテナのＵＲＩが設定される。
【００９２】
スキャンコンテナＵＲＩ（Ｓｃａｎ  Ｃｏｎｔａｉｎｅｒ  ＵＲＩ）８０７は、スキャンリクエストを処理する際に要求受信部４０１からスキャン用バックエンド処理部４１０へデータを受け渡すのに使用するブロブストレージ４０５内に設けられたコンテナのＵＲＩが設定される。
【００９３】
デバイスタイプ（Ｄｅｖｉｃｅ  Ｔｙｐｅ）８０８は、ローキー８０３のデバイスＩＤによって識別される画像形成装置１０４に専有リソースモデル、共有リソースモデル、どちらのリソースモデルが適用されているか、を識別するものである。デバイスタイプ８０８の値が「スペシャル（ｓｐｅｃｉａｌ）」である画像形成装置１０４は専有リソースモデルが適用される画像形成装置、「グローバル（ｇｌｏｂａｌ）」であるデバイスは共有リソースモデルが適用される画像形成装置である。
【００９４】
図８の各ＵＲＩ８０４、８０５、８０６、８０７におけるＵＲＩの構造は、ベースアドレス＋ターゲット識別子という形式になっている。たとえば図８のプリントキューＵＲＩ８０４ではベースアドレスは「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｑｕｅｕｅ．ｎｅｔ／」となっている。ターゲット識別子に関しては、グローバル識別子と個別装置識別子があり、グローバル識別子は「ｇｌｏｂａｌ」という文字列、個別装置識別子はデバイスＩＤそのものである。よって、プリントキューＵＲＩ８０４において、グローバルＵＲＩは、「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｑｕｅｕｅ．ｎｅｔ／ｇｌｏｂａｌ／」となり、デバイスＩＤが「ｄｅｖｉｃｅ３」のデバイス固有ＵＲＩは、「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｑｕｅｕｅ．ｎｅｔ／ｄｅｖｉｃｅ３／」となる。グローバルＵＲＩが指定されている画像形成装置１０４は、共有リソースを使用する構成になっている。デバイス固有ＵＲＩが指定されている場合、そのデバイスＩＤが割り当てられている画像形成装置１０４は、専有リソースを使用する構成になっている。
【００９５】
次に本実施例におけるブロブストレージ５０７内のデータ配置構造について図９を用いて説明する。ブロブストレージ５０７内のデータ配置構造は階層構造になっており、最上位要素がルート要素９０１である。
【００９６】
ルート要素９０１には、たとえば「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ」のようなベースＵＲＩが割り当てられている。また、ルート要素９０１の配下には複数のコンテナ９０２を含めることができる。コンテナ９０２のＵＲＩは、上位要素のＵＲＩと、コンテナ名を「／」を介して結合した文字列となる。例えば、ルート要素９０１のベースＵＲＩが「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ」の下にある「ｇｌｏｂａｌ」という名前のコンテナ９０２のＵＲＩは、「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｇｌｏｂａｌ」となる。コンテナ９０２は、複数のブロブ９０３やコンテナ９０２を含めることが可能で、コンテナ９０２を削除すると、配下にあるすべてのブロブ９０３およびコンテナ９０２もまとめて削除される。
【００９７】
ブロブ９０３は、ファイルなどのバイナリデータを表す。ブロブ９０３のＵＲＩは、上位要素のＵＲＩと、コンテナ名を「／」を介して結合した文字列となる。例えば、コンテナ９０２のＵＲＩが「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｇｌｏｂａｌ」の下にある「ｄｏｃｕｍｅｎｔ１．ｄｏｃ」という名前のブロブ９０３のアドレスは、「ｈｔｔｐ：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｇｌｏｂａｌ／ｄｏｃｕｍｅｎｔ１．ｄｏｃ」となる。
【００９８】
次に本実施例におけるプリントリクエスト及びスキャンリクエスト後の処理の流れについて図１０を用いて説明する。
【００９９】
まず、図１０（ａ）を用いて本実施例における印刷処理について説明する。図１０（ａ）は印刷処理の流れを表したシーケンス図である。
【０１００】
ユーザーが画像形成装置１０４のデバイスブラウザ４０９にてプリントリクエストを出すところから一連の処理が行われる。デバイスブラウザ４０９は要求受信部４０１にて動作する印刷アプリケーションと通信し印刷処理を行う。
【０１０１】
図１１の（ａ）は、デバイスブラウザ４０９に表示される印刷画面の一例である。本画面は要求受信部４０１にて動作する印刷アプリケーションにより生成される。
【０１０２】
印刷先の欄１１０１はユーザーが現在操作している画像形成装置１０４のデバイスＩＤが表示される。文書サーバーの欄１１０２はデータを取得する文書サーバーのＵＲＬが表示される。本実施例では要求受信部４０１で動作する印刷アプリケーションのプログラムにこのＵＲＬが組み込まれている。対象文書の欄１１０３は実際に印刷する文書の文書ＩＤがユーザーにより入力される。本図の例では「ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ」という文書を印刷することになる。プリントボタン１１０４はデバイスブラウザ上に表示されるボタンであり、ユーザーが押下すると以下で説明される一連の印刷処理のシーケンスが実行される。
【０１０３】
プリントボタン１１０４が押下されると、デバイスブラウザ４０９は要求受信部４０１に対して、ステップＳ１００１のプリントリクエストを行う。このプリントリクエストには対象文書の欄１１０３に入力された文書ＩＤと印刷先の欄１１０１に表示されたデバイスＩＤがパラメータとして渡される。
【０１０４】
要求を受け付けた要求受信部４０１は、テーブルストレージ４０４のリソーステーブル８００に対して、ステップＳ１００２のリソース情報の取得要求を行う。リソース情報取得要求ではデバイスＩＤをパラメータとして渡す。テーブルストレージ４０４は要求されたデバイスＩＤに対応するリソース情報をステップＳ１００３にて要求受信部４０１に応答する。リソース情報を取得した要求受信部４０１は、ステップＳ１００４にて、プリントコンテナＵＲＩ８０６の情報と文書ＩＤを結合して、ブロブＵＲＩを生成する。要求受信部４０１は、キューストレージ４０３に対してステップＳ１００５のキューメッセージ６００の追加要求を行う。ここでキューメッセージ６００の追加先は、Ｓ１００３で取得したプリントキューＵＲＩである。キューメッセージ６００の追加要求ではステップＳ１００４で生成したブロブＵＲＩとＳ１００１で受信した文書ＩＤ、およびキューメッセージ６００のメッセージタイプとして印刷を示す”ＰＲＩＮＴ”を含むキューメッセージ６００を作成し渡す。キューストレージ４０３はキューメッセージ６００の追加処理を行う。
【０１０５】
要求受信部４０１はステップＳ１００１の要求に対する応答として、Ｓ１００６のブロブＵＲＩ取得をデバイスブラウザ４０９に対して行う。
【０１０６】
次にプラットフォームアプリケーション４０８が印刷データを取得する処理を説明する。
【０１０７】
ステップＳ１００６でブロブＵＲＩを取得したデバイスブラウザ４０９はプラットフォームアプリケーション４０８に対してステップＳ１０２０の監視指示を行う。監視指示ではブロブＵＲＩをパラメータとしてプラットフォームアプリケーション４０８に渡す。プラットフォームアプリケーション４０８はステップＳ１０２１にて要求受信部４０１に対して印刷データ要求を行う。印刷データ要求ではブロブＵＲＩをパラメータとして渡す。
【０１０８】
要求受信部４０１はブロブストレージ４０５に対して、印刷データ取得要求Ｓ１０２２を行う。印刷データ取得要求はＳ１０２１で受け取ったブロブＵＲＩをパラメータとして渡す。ブロブストレージ４０５は指定されたブロブＵＲＩに合致するブロブを探し、要求受信部４０１へ応答する。本実施例ではＳ１０２２で印刷データ取得要求時に指定されたブロブＵＲＩに合致するブロブが存在しないため、要求受信部４０１はＳ１０２２の応答として、Ｓ１０２３で文書なしの応答を受け取る。要求受信部４０１はＳ１０２４でプラットフォームアプリケーション４０８に対して印刷データなしの応答を行う。
【０１０９】
プラットフォームアプリケーション４０８は印刷データが取得できるまで繰り返し要求受信部４０１に対して印刷データ要求を行う。ステップＳ１０２５の印刷データ要求が繰り返しの要求であり、ステップＳ１０２６の印刷データ取得要求の処理、ステップＳ１０２７の印刷データ取得とあわせてステップＳ１０２１、ステップＳ１０２２、ステップＳ１０２３と同様の処理となる。ただし、ステップ１０２６の時点では、指定されたブロブＵＲＩのブロブが作成されているので、ステップ１０２７としてブロブストレージ４０５は、要求受信部４０１に対して印刷データを応答として返す。要求受信部４０１は、Ｓ１０２５の応答として、Ｓ１０２８で印刷データを渡す。印刷データを受け取ったプラットフォームアプリケーション４０８は、Ｓ１０２９で、取得した印刷データを用いて印刷ソフトウェアによる印刷指示を行い、画像形成装置１０４にて印刷が実行される。そして印刷物を得る。
【０１１０】
続いて、プリント用バックエンド処理部４０２が印刷するための文書データを文書サーバー１０３の文書リポジトリ４０６より取得し、印刷データへ変換してブロブストレージ４０５に格納するまでの流れを説明する。
【０１１１】
プリント用バックエンド処理部４０２はキューストレージ４０３に対してポーリングを実行し、定期的にステップＳ１０１０のメッセージ取得要求を行う。ステップＳ１０１１にてキューストレージ４０３からキューメッセージ６００が取得できたら、プリント用バックエンド処理部４０２はキューメッセージ６００のメッセージタイプを取り出す。メッセージタイプがＰＲＩＮＴであれば、＜ＢｌｏｂＵＲＩ＞のブロブＵＲＩと＜ＤｏｃＩｄ＞の文書ＩＤも取り出す。
【０１１２】
プリント用バックエンド処理部４０２は文書リポジトリ４０６に対してステップＳ１０１２の文書取得要求を行う。文書取得要求では文書ＩＤをパラメータとして渡す。本実施例では、文書リポジトリ４０６のＵＲＬは、プリント用バックエンド処理部のプログラムに記載されているものとする。ステップＳ１０１２にて文書取得要求を受けた文書リポジトリ４０６はステップＳ１０１３にて指定された文書ＩＤの文書データを応答する。プリント用バックエンド処理部４０２は、Ｓ１０１３で取得した文書データをＳ１０１４にて印刷データへと変換処理を行う。Ｓ１０１５では、プリント用バックエンド処理部４０２は、Ｓ１０１１で指定されたブロブＵＲＩにＳ１０１４で変換した印刷データを保存する。
【０１１３】
プリント用バックエンド処理部４０２はステップＳ１０１６のメッセージ削除要求にてキューストレージ４０３より処理したキューメッセージ６００を削除する。これにより処理したジョブに対応したキューメッセージ６００がキューストレージ４０３から削除されてタイムアウトによる再実行処理が行われなくなる。
【０１１４】
以上、本実施例における印刷処理について説明を行った。続いて、本実施例における読み取り（スキャン）処理について図１０（ｂ）を用いて説明する。図１０（ｂ）は、本実施例における読み取り処理の流れを表したシーケンス図である。
【０１１５】
ユーザーが画像形成装置１０４のデバイスブラウザ４０９からスキャンリクエスト出すところから一連の処理が行われる。デバイスブラウザ４０９は要求受信部４０１にて動作するスキャンアプリケーションと通信し読み取り処理を行う。
【０１１６】
図１１（ｂ）は、デバイスブラウザ４０９に表示される画面の一例である。本画面は要求受信部４０１にて動作するスキャンアプリケーションにより生成される。
【０１１７】
読み込み元の欄１１１１はユーザーが現在操作している画像形成装置１０４のデバイスＩＤが表示される。文書サーバーの欄１１１２はデータを格納する文書サーバーのＵＲＬが表示される。本実施例では要求受信部４０１で動作するスキャンアプリケーションのプログラムにこのＵＲＬが組み込まれている。文書名の欄１１１３は格納するスキャン画像データの名称（文書ＩＤ）がユーザーにより入力される。本図の例では「ｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃ」という名前で文書を格納することになる。スキャンボタン１１１４はデバイスブラウザ上に表示されるボタンであり、ユーザーが押下すると以下で説明される一連のスキャン処理のシーケンスが実行される。
【０１１８】
図１１（ｂ）にてスキャンボタン１１１４が押下されると、デバイスブラウザ４０９はプラットフォームアプリケーション４０８に対して、ステップＳ１０５０のスキャンリクエストを出す。このスキャンリクエストには文書名１１１３に入力された文書ＩＤと読み込み元の欄１１１１に表示されるデバイスＩＤがパラメータとして渡される。
【０１１９】
スキャンリクエストを受けたプラットフォームアプリケーション４０８は、Ｓ１０５１で画像形成装置１０４に対して原稿読み込み指示を行って、画像形成装置１０４が読み込んだ画像データを受け取る。Ｓ１０５２にてプラットフォームアプリケーション４０８は、Ｓ１０５１で読み込んだ画像データをＳ１０５０で受け取った文書ＩＤ、デバイスＩＤとともに、要求受信部４０１に対して画像送信を行う。画像を受けとった要求受信部４０１は、テーブルストレージ４０４のリソーステーブル８００に対して、ステップＳ１０５３のリソース情報の取得要求を行う。リソース情報要求ではデバイスＩＤをパラメータとして渡す。テーブルストレージ４０４は要求されたデバイスＩＤに対応するリソース情報をステップＳ１０５４にて要求受信部４０１に応答する。リソース情報を取得した要求受信部４０１は、ステップＳ１０５５にて、Ｓｃａｎ  Ｃｏｎｔａｉｎｅｒ  ＵＲＩ８０７の情報と文書ＩＤを結合して、ブロブＵＲＩを生成する。Ｓ１０５６にて要求受信部４０１は、生成したブロブＵＲＩに基づいて画像データをブロブストレージ４０５に格納する。
【０１２０】
続いて要求受信部４０１は、キューストレージ４０３に対してステップＳ１０５７のキューメッセージ６００の追加要求を行う。ここでキューメッセージ６００の追加先は、Ｓ１０５４で取得したスキャンキューＵＲＩである。キューメッセージ６００の追加要求ではステップＳ１０５５で生成したブロブＵＲＩとＳ１０５２で受信した文書ＩＤ、およびキューメッセージ６００のメッセージメッセージタイプとしてスキャンを示す”ＳＣＡＮ”を含むキューメッセージ６００を作成し渡す。キューストレージ４０３はキューメッセージ６００の追加処理を行う。
【０１２１】
次にスキャン用バックエンド処理部４１０が画像データを文書リポジトリ４０６に格納するまでの流れを説明する。
【０１２２】
スキャン用バックエンド処理部４１０はキューストレージ４０３に対してポーリングを実行し、定期的にステップＳ１０６０のキューメッセージ６００の取得要求を行う。ステップＳ１０６１にてキューストレージ４０３よりメッセージが取得できたら、スキャン用バックエンド処理部４１０はキューメッセージ６００のメッセージタイプを取り出す。メッセージタイプがＳＣＡＮであれば、＜ＢｌｏｂＵＲＩ＞からブロブＵＲＩと＜ＤｏｃＩｄ＞から文書ＩＤも取り出す。
【０１２３】
Ｓ１０６２にて、スキャン用バックエンド処理部４１０はＳ１０６１で取得したブロブＵＲＩにアクセスし、画像データを取得する。取得した画像データは、Ｓ１０６３にてスキャン用バックエンド処理部４１０が文書変換を行う。たとえば、ビットマップなどの画像データをＰＤＦなどの形式に変換する。
【０１２４】
次に、Ｓ１０６４にてスキャン用バックエンド処理部４１０は、文書リポジトリ４０６に対して文書を格納する。文書格納時には、パラメータとしてＳ１０６１で取得した文書ＩＤを指定する。文書リポジトリ４０６は、指定された文書ＩＤで指定された文書データを保存する。
【０１２５】
続いて、スキャン用バックエンド処理部４１０はステップＳ１０６５のキューメッセージ６００の削除要求にてキューストレージ４０３より処理したキューメッセージ６００を削除する。これにより処理したジョブに対応したキューメッセージ６００がキューストレージ４０３から削除されタイムアウトによる再実行処理が行われなくなる。
【０１２６】
以上、本実施例のスキャンの処理の流れの説明を行った。
【０１２７】
続いて、図１２（ａ）を用いてプリント用バックエンド処理部４０２と図１２（ｂ）を用いてスキャン用バックエンド処理部４１０の構造を説明する。
【０１２８】
監視先アドレス１２０２は、プリント用バックエンド処理部４０２およびスキャン用バックエンド処理部４１０がキューメッセージ６００を取得すべきキューストレージ４０３のアドレスを保持している。
図１２（ａ）は、プリント用バックエンド処理部４０２の構造を示している。キュー監視部１２０１は、監視先アドレス１２０２で保持されているキューストレージ４０３のアドレスを取得し、キューストレージ４０３に対してキューメッセージ６００の取得要求を繰り返す。取得したキューメッセージ６００のメッセージタイプがＰＲＩＮＴの場合、キュー監視部１２０１で取得したメッセージの内容を元に、文書取得、文書変換、文書書き込みを、それぞれ文書取得部１２０３、文書変換部１２０４、文書書き込み部１２０５が行う。
【０１２９】
図１２（ｂ）は、スキャン用バックエンド処理部４１０の構造を示している。キュー監視部１２０６は、監視先アドレス１２０２で保持されているアドレスを取得し、キューストレージ４０３に対してキューメッセージ６００の取得要求を繰り返す。取得したキューメッセージ６００のメッセージタイプがＳＣＡＮの場合、キュー監視部１２０６で取得したキューメッセージ６００の内容を元に、文書取得、文書変換、文書書き込みを、それぞれ文書取得部１２０７、文書変換部１２０８、文書書き込み部１２０９が行う。
【０１３０】
キュー監視部１２０１および１２０６は、取得したキューメッセージ６００のメッセージタイプがＭＯＶＥの場合、キューメッセージ６００のメッセージデータコンテンツ部６０５の＜Ｑｕｅｕｅ＞から新たに監視すべきキューストレージ４０３のＵＲＩ（アドレス）を取り出し、監視先アドレス１２０２で既に保持しているアドレスを取り出したアドレスに書き換えて保持する。
【０１３１】
以上でプリント用バックエンド処理部４０２とスキャン用バックエンド処理部４１０の構造を図１２（ａ）（ｂ）を用いて説明した。
【０１３２】
以下で、画像形成装置１０４が省電力状態に移行する場合の処理の流れを説明する。
【０１３３】
画像形成装置１０４は省電力状態に移行する際、電源制御ユニット２１０によりスリープ処理が実行され、画像形成装置１０４の状態イベントとしてスリープイベントが発行される。このスリープイベントをプラットフォームアプリケーション４０８が受信する。スリープイベントを受信したプラットフォームアプリケーション４０８は状態受信部４１１にイベント通知を行う。このイベント通知ではデバイスＩＤとイベント内容（ここではスリープイベント）を示す識別子がパラメータとして渡される。
【０１３４】
イベント通知を受信した状態受信部４１１は、図１６に示す判断フローによって、受信したイベント通知に応じた処理を行う。まず、状態受信部４１１は、Ｓ１６０１にてテーブルストレージ４０４のリソーステーブル８００のローキー８０３を参照し、パラメータとして渡されたデバイスＩＤに基づいて、このイベント通知がどの画像形成装置１０４から通知されたものなのかを検索する。そして、この検索により一意に決まったデバイスのデバイスタイプ８０８が「ｓｐｅｃｉａｌ」であるかを判断する（Ｓ１６０１）。この判断の結果、デバイスタイプ８０８が「ｓｐｅｃｉａｌ」であれば、状態受信部４１１は後述するリソース調整の処理を実行し（Ｓ１６０２）、「ｇｌｏｂａｌ」であれば、そのまま処理を終了する。
【０１３５】
以下では、省電力状態に移行する画像形成装置１０４に対応するデバイスタイプが「ｓｐｅｃｉａｌ」、つまり画像形成装置１０４が専有リソースモデルの適用されたものである場合の、リソース調整の処理について図１３を用いて説明する。
【０１３６】
画像形成装置１０４が省電力状態に移行する際、検知部４１３がスリープイベントを発行する。Ｓ１３０１にて、このスリープイベントをプラットフォームアプリケーション４０８が受信する。スリープイベントを受信したプラットフォームアプリケーション４０８はＳ１３０２にて状態受信部４１１にイベント通知を行う。このイベント通知ではデバイスＩＤとイベント内容（ここではスリープイベント）を示す識別子がパラメータとして渡される。
【０１３７】
イベント通知をうけとった状態受信部４１１は、テーブルストレージ４０４のリソーステーブル８００に対して、ステップＳ１３０３のリソース情報の取得要求を行う。リソース情報取得要求ではデバイスＩＤをパラメータとして渡す。テーブルストレージ４０４は要求されたデバイスＩＤに対応するリソース情報をステップＳ１３０４にて状態受信部４１１に応答する。ここで状態受信部４１１は、ステップＳ１３０５でテーブルストレージ４０４のリソーステーブル８００に対し、Ｓ１３０２で取得したデバイスＩＤに対応するリソースのＵＲＩ（プリントキューＵＲＩ８０４，スキャンキューＵＲＩ８０５，プリントコンテナＵＲＩ８０６，スキャンコンテナＵＲＩ８０７）をすべてグローバルＵＲＩに変更するよう要求する。このようにすることで後述するＳ１３２８、Ｓ１３２９でのキューメッセージ６００の追加をグローバルＵＲＩのキューＵＲＩに対して行える。
【０１３８】
次に、Ｓ１３０６及びＳ１３０７で、Ｓ１３０４で取得した更新前のプリントキューＵＲＩ８０４及びスキャンキューＵＲＩ８０５に対して、キューメッセージ６００を追加する。このキューメッセージ６００の内容は、メッセージタイプがＭＯＶＥで、＜Ｑｕｅｕｅ＞部がＳ１３０５にて更新したグローバルＵＲＩとしたものである。
【０１３９】
Ｓ１３０８およびＳ１３０９では、Ｓ１３０４で取得したプリント用及びスキャン用それぞれのブロブストレージ４０５のコンテナＵＲＩを指定して、その領域を削除する。
【０１４０】
次に、プリント用バックエンド処理部４０２のインスタンスは、キューストレージ４０３に対してポーリングを実行して定期的にステップＳ１３１０のキューメッセージ６００の取得要求を行う。Ｓ１３１１にてキューストレージ４０３よりキューメッセージ６００が取得できたら、プリント用バックエンド処理部４０２のインスタンスはメッセージタイプを取り出す。メッセージタイプがＭＯＶＥであれば、Ｓ１３１２にてプリント用バックエンド処理部４０２のインスタンスはキューメッセージ６００の＜Ｑｕｅｕｅ＞部で指定されたポーリング先キューストレージ４０３のＵＲＩを取り出し、監視先アドレス１２０２に保持されている内容を置き換える。
【０１４１】
続いてプリント用バックエンド処理部４０２のインスタンスはステップＳ１３１３のメッセージ削除要求にてキューストレージ４０３より現在処理したキューメッセージ６００を削除する。これにより処理したタスクに対応したキューメッセージ６００がキューストレージ４０３より削除されタイムアウトによる再実行処理が行われなくなる。この置き換えにより、デバイス固有ＵＲＩに対してポーリングしていたプリント用バックエンド処理部４０２のインスタンスがグローバルＵＲＩに対してポーリングを行うようになり、専有リソースであったプリント用バックエンド処理部４０２のインスタンスが共有リソースとして割り当てられる。
【０１４２】
Ｓ１３１４〜Ｓ１３１７に関しては、プリント用バックエンド処理部４０２のインスタンスが実行したＳ１３１０〜Ｓ１３１３までの処理をスキャン用バックエンド処理部４１０のインスタンスが同様に実行する。この置き換えにより、デバイス固有ＵＲＩに対してポーリングしていたスキャン用バックエンド処理部４１０のインスタンスがグローバルＵＲＩに対してポーリングを行うようになり、専有リソースであったスキャン用バックエンド処理部４１０のインスタンスが共有リソースとして割り当てられる。
【０１４３】
以上が、専有リソースモデルの画像形成装置１０４で省電力状態に移行する際の、画像形成装置１０４の専有していた専有リソースの専有解除が行われ、プリント用及びスキャン用バックエンド処理部４０２、４１０のインスタンスが共有リソースとして割り当てられる流れを説明した。
【０１４４】
続いて、専有リソースモデルの画像形成装置１０４が省電力状態から画像形成動作及び画像読み込み動作を実行可能な通常状態に復旧する場合の流れを説明する。図１３のＳ１３１７が実行された段階では、画像形成装置１０４は、省電力状態にあり、プリント用及びスキャン用バックエンド処理部４０２、４１０のインスタンスはこの画像形成装置１０４に対して専有リソースとして割り当てられてはいない構成になっている。
【０１４５】
画像形成装置１０４が省電力状態から画像形成動作及び画像読み込み動作を実行可能な通常状態へ復旧する際、検知部４１３がスリープ復旧イベントを発行する。Ｓ１３２１にて、このスリープ復旧イベントをプラットフォームアプリケーション４０８が受信する。スリープ復旧イベントを受信したプラットフォームアプリケーション４０８はＳ１３２２にて状態受信部４１１にイベント通知を行う。このイベント通知ではデバイスＩＤとイベント内容（ここではスリープ復旧イベント）を示す識別子がパラメータとして渡される。イベント通知をうけとった状態受信部４１１は、テーブルストレージ４０４のリソーステーブル８００に対して、ステップＳ１３２３のリソース情報の取得要求を行う。リソース情報取得要求ではデバイスＩＤをパラメータとして渡す。テーブルストレージ４０４は要求されたデバイスＩＤに対応するリソース情報をステップＳ１３２４にて状態受信部４１１に応答する。ここで状態受信部４１１は、ステップＳ１３２５としてテーブルストレージ４０４のリソーステーブル８００に対し、Ｓ１３２２で取得したデバイスＩＤに対応するリソースのＵＲＩをすべてデバイス固有ＵＲＩに変更するよう要求する。テーブルストレージ４０４は要求された変更を実行する。
【０１４６】
次に、Ｓ１３２６およびＳ１３２７では、Ｓ１３２５で更新したプリント用及びスキャン用それぞれのブロブストレージ４０５のコンテナＵＲＩを指定して、その領域を作成する。
【０１４７】
Ｓ１３２８およびＳ１３２９で、Ｓ１３２４で取得した更新前のプリントキューＵＲＩ８０４及びスキャンキューＵＲＩ８０５に対して、キューメッセージ６００を追加する。このキューメッセージ６００の内容は、メッセージタイプがＭＯＶＥで、＜Ｑｕｅｕｅ＞部で指定するキューストレージのＵＲＩは、Ｓ１３２５で変更したデバイス固有ＵＲＩである。
【０１４８】
次に、プリント用バックエンド処理部４０２のインスタンスは、キューストレージ４０３に対してポーリングを実行して定期的にステップＳ１３３０のキューメッセージ６００の取得要求を行う。Ｓ１３３１にてキューストレージ４０３よりキューメッセージ６００が取得できたら、プリント用バックエンド処理部４０２のインスタンスはメッセージタイプを取り出す。メッセージタイプがＭＯＶＥであれば、Ｓ１３３２にてプリント用バックエンド処理部４０２のインスタンスは＜Ｑｕｅｕｅ＞部で指定されたポーリング先キューストレージ４０３のＵＲＩを取り出し、このＵＲＩで監視先アドレス１２０２に保持されている内容を置き換える。なお、Ｓ１３３２で監視先キューＵＲＩを更新するインスタンスの数は、Ｓ１３０１時点での専有リソースとしていたインスタンスの数と同じである。
【０１４９】
引き続きプリント用バックエンド処理部４０２のインスタンスはステップＳ１３３３のメッセージ削除要求にてキューストレージ４０３より現在処理したキューメッセージ６００を削除する。これにより処理したタスクに対応したキューメッセージ６００がキューストレージ４０３より削除されタイムアウトによる再実行処理が行われなくなる。この置き換えにより、グローバルＵＲＩに対してポーリングしていたプリント用バックエンド処理部４０２のインスタンスは、この画像形成装置１０４由来のキューメッセージ６００が格納されるキューストレージ４０３のデバイス固有のＵＲＩに対してポーリングを行うようになる。
【０１５０】
Ｓ１３３４〜Ｓ１３３７に関しては、プリント用バックエンド処理部４０２のインスタンスが実行したＳ１３３０〜Ｓ１３３３までの処理をスキャン用バックエンド処理部４１０のインスタンスが同様に実行する。この置き換えにより、プリント用バックエンド処理部のインスタンスと同様に、グローバルＵＲＩに対してポーリングしていたスキャン用バックエンド処理部４１０のインスタンスがデバイス固有のＵＲＩに対してポーリングを行うようになる。
【０１５１】
以上が専有リソースモデルが適用されている画像形成装置１０４でスリープ復旧イベントが発行されてから、共有リソースとして割り当てられていたプリント用及びスキャン用バックエンド処理部４０２，４１０の一部インスタンスをこの画像形成装置１０４専用の専有リソースとして割り当てるまでの流れを説明した。
【０１５２】
本実施例により、専有リソースモデルが適用された画像形成装置１０４が省電力状態となり画像形成動作及び画像読み込み動作が実行可能な状態でないにもかかわらずリソースが無駄に専有される状態を防ぎ、リソースの利用効率の低下を低減することができる。また、専有解除したリソースを共有リソースとして割り当てることで共有リソースの処理効率を上げることができる。また、専有リソースモデルが適用された画像形成装置１０４がスリープ復旧の際に、共有リソースのリソースを専有リソースのものとして割り当て直すことで、時間的ロスなく専有リソースを再確保することが可能になる。
【０１５３】
（実施例２）
実施例１で示すリソース調整は、画像形成装置１０４のスリープイベントの通知を状態受信部４１１が受信することによって、専有リソースを共有リソースとして割り当ての変更を行うことで、専有リソースの利用効率の低下を軽減するものであった。
【０１５４】
本実施例では、画像形成装置１０４のスリープイベントの通知を状態受信部４１１が受信することによって、専有リソースを削除する。専有リソースの削除、即ちバックエンド処理部４０２、４１０として機能するヴァーチャルマシン５０２のインスタンス数を減少させることで、画像形成装置１０４が省電力状態となった場合、専有リソースの利用効率の低下を防ぐ。
【０１５５】
図１５を用いて本実施例を説明する。なお、特に説明がない限り、本実施例のネットワークスキャンプリントシステムは実施例１のものと同様のものとする。
【０１５６】
以下では、実施例１の説明と同様に、省電力状態に移行する画像形成装置１０４に対応するデバイスタイプが「ｓｐｅｃｉａｌ」、つまり画像形成装置１０４が専有リソースモデルの適用されたものである場合の、リソース調整の処理について図１５を用いて説明する。
【０１５７】
画像形成装置１０４は省電力状態に移行する際、検知部４１３がスリープイベントを発行する。Ｓ１５０１にて、このスリープイベントをプラットフォームアプリケーション４０８が受信する。スリープイベントを受信したプラットフォームアプリケーション４０８はＳ１５０２にて状態受信部４１１にイベント通知を行う。このイベント通知ではデバイスＩＤとイベント内容（ここではスリープイベント）を示す識別子がパラメータとして渡される。
【０１５８】
イベント通知をうけとった状態受信部４１１は、テーブルストレージ４０４のリソーステーブル８００に対して、ステップＳ１５０３のリソース情報の取得要求を行う。リソース情報取得要求ではデバイスＩＤをパラメータとして渡す。テーブルストレージ４０４は要求されたデバイスＩＤに対応するリソース情報をステップＳ１５０４にて状態受信部４１１に応答する。ここで状態受信部４１１は、ステップＳ１５０５としてテーブルストレージ４０４のリソーステーブル８００に対し、Ｓ１５０２で取得したデバイスＩＤに対応するリソースのＵＲＩ（プリントキューＵＲＩ８０４，スキャンキューＵＲＩ８０５，プリントコンテナＵＲＩ８０６，スキャンコンテナＵＲＩ８０７）をすべてグローバルＵＲＩに変更するよう要求する。
【０１５９】
次に、Ｓ１５０６及びＳ１５０７で、Ｓ１５０４で取得した更新前のプリントキューＵＲＩ８０４及びスキャンキューＵＲＩ８０５に対して、キューメッセージ６００を追加する。このキューメッセージ６００の内容は、メッセージタイプをＫＩＬＬとしたものである。
【０１６０】
Ｓ１５０８およびＳ１５０９では、Ｓ１５０４で取得したプリント用及びスキャン用それぞれのブロブコンテナＵＲＩを指定して、その領域を削除する。
【０１６１】
次に、プリント用バックエンド処理部４０２のインスタンスは、キューストレージ４０３に対してポーリングを実行して定期的にステップＳ１５１０のキューメッセージ６００の取得要求を行う。Ｓ１５１１にてキューストレージ４０３よりキューメッセージ６００が取得できたら、プリント用バックエンド処理部４０２のインスタンスはメッセージタイプを取り出す。メッセージタイプがＫＩＬＬであれば、ステップＳ１５１３にてメッセージ削除要求を出してキューストレージ４０３より処理したキューメッセージ６００を削除する。これにより処理したタスクに対応したキューメッセージ６００がキューストレージ４０３より削除されタイムアウトによる再実行処理が行われなくなる。このメッセージ削除要求後、プリント用バックエンド処理部４０２のインスタンスはファブリックコントローラ４１２に対して、自身のインスタンスＩＤをパラメータとして渡し、自身の削除要求を出す（Ｓ１５１３）。インスタンス削除要求を受けて、ファブリックコントローラ４１２は受信したインスタンスＩＤをもとにこのインスタンスを削除する（Ｓ１５１４）。
【０１６２】
Ｓ１５１５〜Ｓ１５１９に関しては、プリント用バックエンド処理部４０２のインスタンスが実行したＳ１５１０〜Ｓ１５１４までの処理をスキャン用バックエンド処理部４１０のインスタンスが同様に実行し、スキャン用バックエンド処理部のインスタンスは削除される。
【０１６３】
以上で、専有リソースモデルの画像形成装置１０４が省電力状態に移行する際の、専有リソースとされていたプリント用及びスキャン用バックエンド処理部４０２、４１０が削除される流れを説明した。
【０１６４】
専有リソースモデルの画像形成装置１０４が省電力状態から画像形成動作及び画像読み込み動作を実行可能な通常状態に復旧する場合の流れは図１５のＳ１５２１〜Ｓ１５３７のようになる。これは実施例１で説明した図１３のＳ１３２１からＳ１３３７のスリープ復旧イベントが発行されてからの処理の流れと同様であるため、説明を割愛する。
【０１６５】
本実施例では、画像形成装置１０４のスリープ復旧イベントに基づくリソース調整の結果、共有リソースの量が減少するため、共有リソースとなるバックエンド処理部４０２、４１０のインスタンス数を増加するように、スリープ復旧イベントの通知を受信した状態受信部４１１はファブリックコントローラ４１２に指示を出す。
【０１６６】
本実施例で示した様にリソースを削除することにより、専有リソースモデルが適用された画像形成装置１０４が省電力状態となり画像形成動作及び画像読み込み動作が実行可能な状態でないにもかかわらずリソースが無駄に専有される状態を防ぐことができる。本実施例で示したリソース調整は、起動しているヴァーチャルマシンのインスタンス数に応じた課金形態のクラウド環境を利用する際には特に有益である。また、専有リソースモデルが適用された画像形成装置１０４がスリープ復旧の際に、共有リソースのリソースを専有リソースのものとして割り当て直すことで、時間的ロスなく専有リソースを再確保することが可能になる。
【０１６７】
（実施例３）
実施例１、２では、画像形成装置１０４のスリープイベント及びスリープ復旧イベントの通知を状態受信部４１１が受信してリソース調整を行うようにしていた。しかし、このリソース調整を画像形成装置１０４の稼働状態に応じた、スリープイベント及びスリープ復旧イベント以外の状態イベントを状態受信部４１１に通知することによって行ってもよい。
【０１６８】
たとえば、実施例１、２で説明したリソース調整を、画像形成装置１０４が起動した際に発行する起動イベント及び画像形成装置１０４がシャットダウンする際に発行するシャットダウンイベントの通知を状態受信部４１１が受信して行ってもよい。この場合、起動イベントがスリープ復旧イベントに対応し、シャットダウンイベントがスリープイベントに対応する。
【０１６９】
また、画像形成装置１０４がネットワークスキャンプリントシステムに対してログイン及びログアウトする構成をとる場合には、プラットフォームアプリケーション４０８が画像形成装置１０４のログイン状態及びログアウト状態を検知する機能を有し、ログインイベント及びログアウトイベントを状態受信部４１１へと通知することによってリソース調整を行ってもよい。この場合、ログインイベントがスリープ復旧イベントに対応し、ログアウトイベントがスリープイベントに対応する。
【０１７０】
また、画像形成装置１０４の故障・エラーといった状態イベントを状態受信部４１１へ通知することによってリソース調整を行ってもよい。この場合、故障・エラーイベントがスリープイベントに対応し、故障・エラーからの復旧がスリープ復旧イベントに対応する。
【０１７１】
以上で、画像形成装置１０４の省電力状態への移行、省電力状態からの復旧に基づいたイベント以外のイベントの通知によってリソース調整を行っても良い実施例を示した。なお、以上で説明した画像形成装置１０４の状態に基づくイベントは、将来のリソース利用状況を知ることができる状態イベントであることが好ましい。たとえば、画像形成装置１０４のスリープやシャットダウンのイベントは、画像形成装置１０４が暫くの間はジョブの処理要求を出さず、リソースを利用しないと予測でき、スリープ復旧や起動のイベントは、これからリソースを利用すると予測できる。
【０１７２】
本実施例により、画像形成装置１０４は省電力状態への移行・省電力状態からの復旧以外のその他の画像形成装置１０４の状態イベントを状態受信部４１１へ通知することで実施例１、２のようなリソース調整を行えることを示した。
【０１７３】
（実施例４）
実施例１では、画像形成装置１０４の状態に対応した状態イベントに基づいてスキャン用及びプリント用両方のリソースの割り当てを変更した。本実施例では、画像形成装置１０４の状態に対応した状態イベントに基づいて、スキャン用リソース又はプリント用リソースのいずれか一方のリソース調整を行う実施例を説明する。
【０１７４】
スキャン用リソースを操作せずにプリント用リソースの割り当て変更を行う本実施例のリソース調整について図１４を用いて説明する。なお、本実施例のネットワークスキャンプリントシステムは、特に説明のない限り、実施例１で説明したものと同様のものとする。
【０１７５】
実施例１において、画像形成装置１０４が省電力状態への移行する場合及び省電力状態からの復帰する場合に発行される状態イベントに基づいてリソース調整が行われた。本実施例では、画像形成装置１０４の有する消耗品に関連する状態イベントによってリソース調整を行う。消耗品の例として、印刷に使用する紙やインクもしくはトナーなどが考えられる。これらの消耗品がなくなると、画像形成装置１０４はとしては印刷ユニットにより印刷を実行することができない。この場合、専有リソースモデルの適用された画像形成装置１０４にプリント用のリソースが専有的に割り当てられていても利用されないため、リソースの利用効率が低下する。
【０１７６】
以下の説明では、実施例１の説明と同様に、状態イベントを発行する画像形成装置１０４に対応するデバイスタイプが「スペシャル」、つまり画像形成装置１０４が専有リソースモデルの適用されたものである場合の、リソース調整の処理について図１４を用いて説明する。
【０１７７】
図１４は、画像形成装置１０４において消耗品の量が印刷可能でない状態に移行する場合に発行される消耗品切れイベントおよび、印刷可能な量まで消耗品が充填された状態に移行する場合に発行される消耗品充填イベントの通知を状態受信部４１１が受信してリソース割り当てなどのリソース調整を行うフローである。
【０１７８】
図１４の最初では、画像形成装置１０４は、プリント用、スキャン用共に専有リソースを使用する構成になっているものとする。
【０１７９】
ここで、Ｓ１４０１において、検知部４１３が消耗品切れイベントを発行し、プラットフォームアプリケーション４０８がそのイベントを受信する。その後Ｓ１４０２からＳ１４０６までは図１３のＳ１３０２からＳ１３０６までと同様である。図１３では次にＳ１３０７としてスキャン用バックエンド向けメッセージをスキャン用キューのＵＲＩに対して追加するが、図１４ではこれを行わない。これは、消耗品が切れている状態でも画像形成装置１０４は読み込みユニットによるスキャン機能を実行可能であり、消耗品切れイベントの前後で変更の必要がないためである。
【０１８０】
同様の理由によりＳ１４０８にて状態受信部４１１はプリント用領域削除を実行するが、スキャン用領域削除は実行しない。Ｓ１４１０からＳ１４１３までは図１３のＳ１３１０からＳ１３１３までと同様である。
【０１８１】
以上のフローで、専有リソースとして割り当てられていたプリント用及びスキャン用バックエンド処理部のインスタントのうち、プリント用バックエンド処理部４０２のインスタントのみ、共有リソースとして割り当てられる状態となる。
【０１８２】
続いて、画像形成装置１０４に消耗品が充填されると、Ｓ１４２１において、検知部４１３が消耗品充填イベントを発行し、プラットフォームアプリケーション４０８がそのイベントを受信する。その後、Ｓ１４２２からＳ１４２６までは図１３のＳ１３２２からＳ１３２６までと同様である。図１３では次にＳ１３２７としてスキャン用領域確保を行うが、本実施例ではスキャン領域に関してはすでに確保された状態にあるので、これを実行しない。キューに対するＭＯＶＥメッセージの投入もＳ１４２８としてプリント用にだけに実行し、スキャン用には実行しない。Ｓ１４３０からＳ１４３３までは図１３のＳ１３３０からＳ１３３３までと同様である。
【０１８３】
以上のフローで、共有リソースとして割り当てられていたプリント用、スキャン用バックエンド処理部のうち、プリント用バックエンド処理部４０２のみ、専有リソースとして割り当てられる状態となる。
【０１８４】
本実施例により、専有リソースモデルが適用された画像形成装置１０４が消耗品切れ状態となり画像形成動作が実行可能な状態でないにもかかわらずリソースが無駄に専有される状態を防ぎ、リソースの利用効率の低下を低減することができる。さらに、消耗品の状態とは関係のない画像読み込み動作に関するリソースの割り当てをそのままとするリソース調整を行うことで、ユーザーに対してはネットワークスキャンプリントシステムによるスキャンサービスを引き続き提供することができる。
【０１８５】
なお、消耗品の状態に関する状態イベント以外にも、印刷ユニット２０２の故障・エラーといった印刷ユニット２０２の使用の可否に関する状態イベントに基づいて、リソース調整を行っても良い。
【０１８６】
また、本実施例では、画像形成装置１０４の印刷ユニットによる画像形成動作に影響する状態イベントに基づいて、リソース調整を行ったが、画像形成装置１０４の画像読み込み動作に影響する読み込みユニット２０３の故障・エラーなどの読み込みユニット２０３の使用の可否に関する状態イベントに基づいて、プリント用リソースを操作せずに、スキャン用リソースの割り当て変更などのリソース調整を行ってもよい。この場合の処理フローは、印刷ユニット２０２の場合の処理フローと同様である。
【０１８７】
また、本実施例のリソース調整は、実施例１のリソース調整のように専有リソースと共有リソースの間のリソースの割り当て変更のみの調整であったが、実施例２で説明したようなリソースの削減によるリソース調整でもよい。
【０１８８】
（実施例５）
実施例１乃至４では、専有リソースモデルの画像形成装置１０４の状態の遷移を状態イベントとして検知部４１３が検知し、プラットフォームアプリケーション４０８がこの状態イベントを状態受信部４１１へ通知する。そしてこの通知を受信した状態受信部４１１はリソース調整を行う。
【０１８９】
本実施例では、画像形成装置１０４の状態の遷移を検知部４１３が検知するタイミングと、状態受信部４１１がリソース調整を開始するタイミングが異なる実施例を説明する。
【０１９０】
たとえば、画像形成装置１０４が省電力状態から復旧して通常状態へ遷移するスリープ復旧イベントを検知部４１３が発行し、それを受信したプラットフォームアプリケーション４０８は、スリープ復旧イベント、又はそれに準ずるイベントの通知を、検知部４１３のイベント発行から適当な時間の経過後のタイミングで状態受信部４１１へ通知する。そしてリソース調整が開始される。このタイミングとしては、画像形成装置１０４が省電力状態から復旧後、デバイスブラウザ４０９が初めてジョブの処理要求を要求受信部４０１に出すタイミングであっても良いし、省電力状態から復旧後で画像形成装置１０４がジョブの処理要求をしないことが保証もしくは予測される数秒から数分経ってからのタイミングでも良い。このようにすることで、リソースが無駄に専有確保されている期間を短縮し、リソースの利用効率の低下をさらに低減することができる。
【０１９１】
また、たとえば、画像形成装置１０４が省電力状態から復旧して通常状態へ遷移するスリープ復旧イベントを検知部４１３が発行し、それを受信し次第プラットフォームアプリケーション４０８は状態受信部４１１へとスリープ復旧イベントの通知を行い、状態受信部４１１はこのイベント通知を受信して適当な時間の経過後のタイミングでリソース調整を開始しても良い。このタイミングとしては、前述のようなタイミングで良い。
【０１９２】
（実施例６）
本発明の実施例１乃至５では、１台の画像形成装置に一定のリソースを専有させる専有リソースモデルと、複数台の画像形成装置に一定のリソースを共有させる共有リソースモデルの２種が混在したネットワークスキャンプリントシステムにおけるリソース調整について説明した。しかし、本発明は、専有リソース共有リソース間でのリソース調整に限定されるものではなく、異なるリソースモデル間でのリソース調整であれば良い。
【０１９３】
例えば、複数の専有リソースモデルを有するネットワークスキャンプリントシステムにおいて、一方の専有リソースモデルの画像形成装置１０４の状態イベントの通知を状態受信部４１１が受信することで、一方の専有リソースモデルのリソースを、他方の専有リソースモデルのリソースとして利用するように割り当てを変更しても良い。この場合は、例えば実施例１の図１３で示したＳ１３０５でのリソーステーブル８００の変更後ＵＲＩをグローバルＵＲＩではなく他方の専有リソースモデルの画像形成装置１０４固有のリソースのＵＲＩとする。そして、Ｓ１３２８、Ｓ１３２９でのキューメッセージ６００の追加をこの場合のＳ１３０５で変更されたキューＵＲＩ（他方の専有リソースモデルの画像形成装置１０４固有のリソースのキューＵＲＩ）に対して実行すればよい。
【０１９４】
同様にして、複数の共有リソースモデルを有するネットワークスキャンプリントシステムにおいても本発明は適用可能である。
【０１９５】
本発明の実施例１乃至６では、ネットワークスキャンプリントシステムを用いて説明したが、本発明はネットワークスキャンプリントシステムに限定されるものではなく、状態イベントを状態受信部４１１に通知するようなＰＣ端末１０５やその他デバイスをクライアントとしたクライアント・サーバーシステムにも適用できる。また、実施例１乃至６で説明した画像形成装置１０４および情報処理装置１０６の内部構成は一例であって、本発明を実施できるものであれば、他の内部構成を取っていても良い。
【０１９６】
また、本発明の各実施例において、１つのインスタンス（ヴァーチャルマシン）は、１台のサーバーコンピュータ上で動作するものとした。しかし、本発明はこれに限られるものではない。例えば、サーバーコンピュータがマルチコアＣＰＵを搭載するのであれば、１コアに対し１つのインスタンスが実現される方法が考えられる。また、マルチスレッド対応のサーバーコンピュータであれば、１ＣＰＵが少なくとも１台以上（例えば、２台、３台等）のヴァーチャルマシンを実現することも可能である。このように、１つのインスタンスを実現するための方法に限定はなく、適宜変更可能なものである。
【０１９７】
なお、これまでに説明した実施例１乃至６以外にも、例えば、これら実施例を複数組み合わせたものも本発明の一実施形態として認められる。
【０１９８】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。その処理は、上述した実施例の機能を実現させるソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１９９】
１０２  サーバーコンピュータ群
１０３  文書サーバー
１０４  画像形成装置
１０５  ＰＣ端末
４１１  状態受信部
８０４  プリントキューＵＲＩ
８０５  スキャンキューＵＲＩ
８０６  プリントコンテナＵＲＩ
８０７  スキャンコンテナＵＲＩ
８０８  デバイスタイプ
【図１】
2012043071.tif 000003
【図２】
2012043071.tif 000004
【図３】
2012043071.tif 000005
【図４】
2012043071.tif 000006
【図５】
2012043071.tif 000007
【図６】
2012043071.tif 000008
【図７】
2012043071.tif 000009
【図８】
2012043071.tif 000010
【図９】
2012043071.tif 000011
【図１０】
2012043071.tif 000012
【図１１】
2012043071.tif 000013
【図１２】
2012043071.tif 000014
【図１３】
2012043071.tif 000015
【図１４】
2012043071.tif 000016
【図１５】
2012043071.tif 000017
【図１６】
2012043071.tif 000018