JP5885818B2 - 情報処理システム、情報処理システム制御方法、およびそのプログラム - Google Patents

Description

本発明は、情報処理システム、情報処理システム制御方法、およびそのプログラムに関するものである。

インターネット技術を利用したコンテンツ管理システムが普及してきている。ユーザーは、クライアントコンピュータからインターネットを介してサーバーコンピュータが開設しているＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したいコンテンツを選択する。コンテンツ管理システムは、選択されたコンテンツをサーバーコンピュータに送信し、サーバーコンピュータは受信したコンテンツをユーザー側に表示されるよう処理をする。

特許文献１には、ユーザーがクライアントで閲覧したコンテンツをプリンタで印刷する方法が開示されている。この方法は、ユーザーが閲覧したコンテンツをサーバーコンピュータがプリンタで印刷できるようなデータに変換し、変換したデータをプリンタに送信する。プリンタは受信したデータを印刷する。

また、近年、サーバーコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）という技術が利用され始めている。

特開２００２−３０４２７１号公報

しかしながら、クラウド資源の利用に関する適正な規定がないため、クラウド資源が適正に利用されない可能性がある。そのため、次のような課題が発生する。

第１の課題として、複数台のデバイスが接続された場合は、適切なクラウド資源の利用がなされていないことによって、資源の無駄な浪費が多くなってしまう。

第２の課題として、クラウドは従量制であるため、クラウド資源を利用すればするほどクラウドベンダーから料金を要求される。このため、クラウド資源を無駄に利用することによって、無駄な費用が発生するという問題がある。

第３の課題として、クラウド資源を利用しようとするデバイスのデバイス能力が低い場合であっても、クラウド資源を多く割り当ててしまう可能性がある。これにより次のような無駄が発生する。ユーザーは、印刷スピードの遅いプリンタを用いて印刷をしようとしている。ユーザーは、このプリンタに対し数多くのコンテンツの印刷を要求した。結果、プリンタは印刷指示された数多くのコンテンツの画像処理ジョブをクラウドに要求した。クラウドは要求されたコンテンツの画像処理を開始した。クラウドは画像処理が完了したコンテンツからプリンタに送信を行った。プリンタは、受信したコンテンツの印刷を開始し、コンテンツの印刷が終了したら次に印刷すべきコンテンツをクラウドから受信した。しかし、プリンタの印刷スピードが遅いため、クラウド側には画像処理したコンテンツが溜まっていく一方である。このとき、ユーザーがプリンタに印刷のキャンセルを指示したとする。これにより、クラウドが画像処理を行ったコンテンツはプリンタの印刷に利用されなくなる。結果、クラウドが画像処理の際に使用したクラウド資源は無駄となる。

本発明の目的は、上述の課題のうち少なくとも１つの課題を解決する情報処理システム、情報処理システム制御方法、およびそのプログラムを提供することにある。

本発明の１実施形態に係る情報処理システムは、情報処理システムであって、ネットワークを介して外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段と、前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューに格納されている前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行うバックエンド処理手段と、前記キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御手段と、を有し、前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする。

本発明によれば、クラウド資源をより適正に利用することが出来る。

実施例１におけるプリントシステムの図。 （ａ）は画像形成装置１０４の内部構成の図、（ｂ）は情報処理装置１０６の内部構成図。 プリントシステムにおける各装置の機能ブロック図。 サーバーコンピュータ群１０２内の各種機能を示した図。 キューメッセージの一例を示した図。 （ａ）は実施例１におけるキュー管理テーブルの一例を示した図、（ｂ）は処理確認テーブルの一例を示した図。 プリントシステムが行う処理の流れを示した図。 要求受信部４０１１が行う印刷データ生成フローチャート。 印刷サービスが行う印刷データ生成フローチャート。 印刷サービスのインスタンス数を減らす手順を示したフローチャート。 （ａ）はライセンス管理テーブルの一例を示した図、（ｂ）は実施例２におけるキュー管理テーブルの一例を示した図。 登録情報に応じた各種設定処理の流れを示す図 課金を行っていない登録情報に応じたキュー割り当て処理を示す図

以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。始めに、本発明の各実施例で使用される用語の定義について説明する。

ポーリングとは、クライアントがホストに要求をした処理の経過や完了を確認するために、クライアントが一定間隔でホストに処理の経過状況を問い合わせる処理のことである。

印刷データ処理とは、例えば、ユーザーが印刷したいコンテンツを、ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）やプリンタと言った画像形成装置が印刷できるようなデータへ変換する処理のことを指す。

コンテンツとは、例えば、文書データや画像データを組み合わせた電子データを指す。

コンテンツＩＤとは、例えば、各コンテンツを一意に定めるためにコンテンツ毎に割り振られた固有情報を指す。この場合、コンテンツが異なればコンテンツＩＤは異なる。

印刷データとは、例えば、コンテンツを印刷データ処理によって変換処理したデータのことであり、ＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）、ラスタイメージ等がある。

実施例１のプリントシステムを構成している各装置について、図１を参照して詳細に説明する。図１には、プリントシステムを構成している各装置がネットワーク１００を介して接続されている様子が示されている。プリントシステムを構成している各装置とは、サーバーコンピュータ群１０２、文書サーバー１０３、画像形成装置１０４、クライアントコンピュータ１０５である。

ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバーコンピュータ群１０２と文書サーバー１０３が属するネットワーク１００と、画像形成装置１０４とクライアントコンピュータ１０５が属するネットワーク１００とは、ファイアウォールを越えて通信が可能である。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。実施例１の図１において、サーバーコンピュータ群１０２は、１台のサーバーとして示されているが複数台のサーバーコンピュータで構成されている。

次に、図１のプリントシステムを構成している各装置の内部構成について詳細に説明する。始めに、画像形成装置１０４の内部構成について図２（ａ）を用いて説明する。図２（ａ）は、画像形成装置１０４の内部構成を例示するブロック図である。なお、本発明の実施例１のデバイスは、画像形成装置１０４となる。

画像形成装置１０４は、画像処理ユニット１０４１、および印刷ユニット１０４２から構成される。画像処理ユニット１０４１は、ＣＰＵ１０４３、直接記憶部１０４４、間接記憶部１０４５、ユーザーインターフェース１０４７、外部インターフェース１０４８から構成されている。

ＣＰＵ１０４３は、所定のプログラムを実行し、画像処理装置１０４の各種制御を指示するユニットである。ＣＰＵ１０４３は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）により実現される。直接記憶部１０４４は、ＣＰＵ１０４３がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０４３が実行するプログラムは直接記憶部１０４４にロードされる。直接記憶部１０４４は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部１０４５は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部１０４５に記憶されている各種プログラムは、ＣＰＵ１０４３がプログラムを実行する際に直接記憶部１０４４へ移動する。間接記憶部１０４５は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ１０４３はマルチプロセッサでも良い。

ここで、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０２上で実行できる他、画像形成装置１０４の操作画面をカスタマイズすることが可能になる。

プラットフォームの実現方法について説明する。ＣＰＵ１０４３は、間接記憶部１０４５に記憶されたプラットフォームプログラムを直接記憶部１０４４に移動する。移動が完了するとＣＰＵ１０４３は、プラットフォームプログラムを実行することができる状態になる。本発明の実施例１では、ＣＰＵ１０４３がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。

プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例１において、プラットフォーム上には、印刷要求を受け付ける印刷ソフトウェアが動作している。印刷ソフトウェアは、ネットワーク１００、またはインターネット１０１を介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と言った通信プロトコルによって印刷データを受信できる。印刷ソフトウェアは、受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは印刷データの描画処理を開始する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。

アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部１０４５に記憶されたアプリケーションプログラムを直接記憶部１０４４に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例１ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例１で開示するフローチャートの各処理の一部を行うことが可能である。

ユーザーインターフェース１０４７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース１０４８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０４は、ネットワーク１００、およびインターネット１０１を介して、クライアントコンピュータ１０５、サーバーコンピュータ群１０２等と通信可能である。

２番目に、サーバーコンピュータ群１０２、文書サーバー１０３、クライアントコンピュータ１０５を含む情報処理装置の内部構成について図２（ｂ）を用いて説明する。図２（ｂ）は、情報処理装置１０６の内部構成を例示するブロック図である。情報処理装置１０６は、ユーザーインターフェース１０６１、ＣＰＵ１０６２、直接記憶部１０６３、間接記憶部１０６４、外部インターフェース１０６５から構成されている。

ユーザーインターフェース１０６１は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。

ＣＰＵ１０６２は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示するユニットである。ＣＰＵ１０６２は、ＣＰＵにより実現される。直接記憶部１０６３は、ＣＰＵ１０６２がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０６２が実行するプログラムは直接記憶部１０６３にロードされる。直接記憶部１０６３は、ＲＡＭで構成されている。間接記憶部１０６４は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部１０６４に記憶されている各種プログラムは、ＣＰＵ１０６２がプログラムを実行する際に直接記憶部１０６３へ移動する。間接記憶部１０６４は、ＲＯＭ、または、ＨＤＤで構成されている。外部インターフェース１０６５は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。

次に、実施例１のプリントシステムにおける各装置が持つ機能について図３を参照しながら詳細に説明する。図３は、プリントシステムにおける各装置の機能ブロック図である。

始めに、サーバーコンピュータ群１０２の機能について説明する。サーバーコンピュータ群１０２には、要求受信部４０１１、バックエンド処理部４０２１、キューサービス４０５、ストレージ４０６の機能がある。本発明の実施例１では、要求受信部４０１１を持つサーバーコンピュータが少なくとも１台以上は存在する。また、バックエンド処理部４０２１を持つサーバーコンピュータが少なくとも１台以上は存在する。また、キューサービス４０５とストレージ４０６の両方の機能を持つサーバーコンピュータが少なくとも１台存在する。なお、サーバーコンピュータ群１０２を情報処理システムと呼び、本発明の各実施例は情報処理システム制御方法の実施例でもある。

要求受信部４０１１は、クライアントコンピュータ１０５、または画像形成装置１０４から送られてきた処理依頼を受け付ける機能を持つ。バックエンド処理部４０２１は、処理プログラムを用いて処理依頼に対する処理を行う機能を持つ。具体的には、バックエンド処理部４０２１は、バックエンド処理部４０２１を実行しているサーバーコンピュータのメモリに処理プログラムをロードし処理を行う。要求受信部４０１１、およびバックエンド処理部４０２１は、図２（ｂ）の間接記憶部１０６４に保存されている要求受信プログラム、またはバックエンド処理プログラムが、直接記憶部１０６３にロードされて、ＣＰＵ１０６２により実行されることで実現される。

キューサービス４０５は、次のような機能を持つ。１つ目は、要求受信部４０１１とバックエンド処理部４０２１とが非同期でデータ通信するための機能を持つ。２つ目は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。

１つ目の機能について説明する。要求受信部４０１１とバックエンド処理部４０２１は次のような方法で通信する。始めに、ユーザーからの処理依頼を受けた要求受信部４０１１は、ユーザーからの処理依頼に応じたキューメッセージと呼ばれるチケットを作成する。この際、キューメッセージに対応した受付ＩＤも作成する。なお、キューメッセージと受付ＩＤについては後述する。キューメッセージは要求受信部４０１１によってキューに格納される。バックエンド処理部４０２１はキューからキューメッセージを取得する。バックエンド処理部４０２１は、キューメッセージを取得し、キューメッセージを参照してユーザーからの処理依頼を処理する。これにより、ユーザーからの処理依頼を解決することになる。このように、キューサービス４０５を利用することで要求受信部４０１１とバックエンド処理部４０２１は非同期で通信を行うことが可能になる。１つ目の機能のさらに詳細な説明と２つ目の機能の説明については後述する。なお、キューサービス４０５は、図２（ｂ）の間接記憶部１０６４に保存されているキューサービスプログラムが、直接記憶部１０６３にロードされて、ＣＰＵ１０６２により実行されることで実現される。また、キューは間接記憶部１０６４によって実現される。

ストレージ４０６は、バックエンド処理部４０２１により処理された実行結果のデータを始めとする各種データを保存しておく機能を持つ。ストレージ４０６は図２（ｂ）の間接記憶部１０４６によって実現される。以上がサーバーコンピュータ群１０２の機能の説明になるが、さらに詳細な説明については後述する。

次に、文書サーバー１０３の機能について説明する。文書サーバー１０３は、文書リポジトリ３０１の機能を持つ。文書リポジトリ３０１は、図２（ｂ）の間接記憶部１０４６によって実現される。例えば、文書リポジトリ３０１には、ユーザーがクライアントコンピュータ１０５、または画像形成装置１０４から印刷指示したコンテンツが保存されている。文書リポジトリ３０１に保存されているコンテンツは、予め保存されているコンテンツの他に次のようなコンテンツも保存されている。

そのコンテンツとは、ユーザーが後述するブラウザ３０４を介してサーバーコンピュータ群１０２上のアプリケーションで作成したコンテンツである。これにより、サーバーコンピュータ群１０２上のアプリケーションを用いて作成したコンテンツであっても、画像形成装置１０４、またはクライアントコンピュータ１０５にアプリケーションをインストールすることなく容易に印刷できる。なお、上述のサーバーコンピュータ群１０２上のアプリケーションとは、文書作成アプリケーション、画像作成アプリケーション、帳票管理アプリケーション等を始めとする各種アプリケーションのことである。これらのアプリケーションは図２（ｂ）の間接記憶部１０６４に保持されており、実行が指示されると直接記憶部１０６３にロードされ、ＣＰＵ１０６２により実行される。

次に、画像形成装置１０４について詳細に説明する。画像形成装置１０４には、デバイスブラウザ３０２、プラットフォームアプリケーション３０３の機能がある。デバイスブラウザ３０２は、ネットワーク１００を介して接続されているデバイス内に保存されているデータや情報をユーザーが閲覧することができる機能を持つ。デバイスブラウザ３０２は、図２（ａ）の直接記憶部１０４５に保存されているデバイスブラウザプログラムが、間接記憶部１０４５にロードされ、ＣＰＵ１０４３により実行されることで実現される。また、ユーザーは、デバイスブラウザ３０２を用いてコンテンツの印刷指示を出すことができる。デバイスブラウザ３０２は、例えば、Ｗｅｂブラウザである。

プラットフォームアプリケーション３０３は、各種サービスを提供する機能を持つ。プラットフォームアプリケーション３０３は、プラットフォーム上で動作するアプリケーションプログラムによって実現される。本発明の実施例１において、プラットフォームアプリケーション３０３は印刷ソフトウェアのサービスを提供する。上述の様に、このサービスは受信した印刷データをファームウェアに送信することができる。また、このサービスは要求受信部４０１１に対して印刷データの生成が終了したかどうかの確認を行う。その際、このサービスは要求受信部４０１１が作成した受付ＩＤを基に生成確認を行う。

最後に、クライアントコンピュータ１０５について詳細に説明する。クライアントコンピュータ１０５は、ブラウザ３０４の機能を持つ。ブラウザ３０４は、ネットワーク１００を介して接続されているデバイス内に保存されているデータや情報をユーザーが閲覧することができる機能を持つ。図２（ｂ）の間接記憶部１０６４に保存されているブラウザプログラムが、直接記憶部１０６３にロードされて、ＣＰＵ１０６２により実行されることで実現される。ブラウザ３０４は、例えば、Ｗｅｂブラウザである。以上が、実施例１のプリントシステムにおける各装置が持つ機能の説明になる。

次に、サーバーコンピュータ群１０２のプラットフォームシステムについて図４を参照しながら詳細に説明する。図４は、サーバーコンピュータ群１０２内の各種機能を示した図である。図４において、サーバーコンピュータ群１０２内にある物理ハードウェア・リソースは、サーバーコンピュータ群１０２のプラットフォームシステムに使用される。サーバーコンピュータ群１０２のプラットフォームシステム利用者は、このサーバーコンピュータ群１０２内にある物理ハードウェア・リソースをコンピューティング・リソースとして使用できる。

サーバーコンピュータ群１０２のプラットフォームシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、次のような機能を持つ。ヴァーチャルマシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ）４０１、および４０２。ファブリックコントローラ（Ｆａｂｒｉｃ Ｃｏｎｔｒｏｌｌｅｒ）４０３。ロードバランサー（Ｌｏａｄ Ｂａｌａｎｃｅｒ）４０４。キューサービス（Ｑｕｅｕｅ）４０５。ストレージ（Ｓｔｏｒａｇｅ）４０６。管理ヴァーチャルマシン４０７である。

サーバーコンピュータ群１０２上で動作するプラットフォームシステムの内部には、ヴァーチャルマシン４０１、４０２が複数存在する。ヴァーチャルマシンとは、仮想化技術によって物理的なサーバーコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本発明の実施例１では、インスタンス数１つに対し、サーバーコンピュータ群１０２内の１台のサーバーコンピュータ上で動作する。

ヴァーチャルマシン４０１は、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０１１、要求受信部エージェント（Ａｇｅｎｔ）４０１２で構成される。要求受信部４０１１は、後述するロードバランサ−４０４を介してユーザーからの処理依頼を受信する。また、要求受信部４０１１は、キューサービス４０５を介してバックエンド処理部４０２への処理依頼を送信する。

要求受信部４０１１の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、ヴァーチャルマシン４０１の外部にあるロードバランサー４０４を通じて行われる。ロードバランサー４０４は、外部ネットワークからの要求を一元的に管理し、要求受信部を有する複数のヴァーチャルマシンに対し、選択的に要求を転送するものである。これにより、要求受信部により確実に処理依頼が送信される。要求受信部エージェント４０１２は、ヴァーチャルマシン４０１の使用状況、要求受信部４０１１の稼動状態、ヴァーチャルマシン４０１のリソースの使用状況、および要求受信部４０１１のエラーを含む各種情報を収集する。要求受信部エージェント４０１２は、収集した各種情報をファブリックコントローラ４０３に定期的に送信する。

要求受信部４０１１、バックエンド処理部４０２１の各インスタンスは、ファブリックコントローラ４０３によって管理されている。そのため、各インスタンスの拡張性と可用性が保証される。例えば、要求受信部４０１１、またはバックエンド処理部４０２１において、ある特定のインスタンスがサーバーの故障によって停止したとする。この場合、ファブリックコントローラ４０３は、要求受信部エージェント４０１２、またはバックエンド処理部エージェント４０２２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ４０３は、新しいインスタンスに処理が委譲されるようにヴァーチャルマシンに指示を出す。結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。

ヴァーチャルマシン４０２は、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０２１、バックエンド処理部エージェント（Ａｇｅｎｔ）４０２２で構成される。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１からの処理依頼を受信する。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１から受信した処理依頼を実行する。また、バックエンド処理部４０２１は、スケールアウトする。スケールアウトとは、ヴァーチャルマシン４０２が増加し、バックエンド処理部４０２１のインスタンスが増加すること指す。バックエンド処理部４０２１のインスタンスが増加すると、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザーからの処理依頼に対する結果をより早く返すことができる。

キューサービス４０５は、要求受信部４０１１とバックエンド処理部４０２１とが非同期でデータ通信するためのサービスを提供する。要求受信部４０１１、およびバックエンド処理部４０２１は、キューサービス４０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。要求受信部４０１１がキューサービス４０５に対して行う指示とは、キューメッセージの追加指示である。バックエンド処理部４０２１がキューサービス４０５に対して行う指示とは、キューメッセージの取得指示、キューメッセージの削除指示である。

要求受信部４０１１とバックエンド処理部４０２１が非同期でデータ通信する一連の動作について説明する。要求受信部４０１１は、ユーザーからの処理依頼に応じたキューメッセージを作成し、キューメッセージをキューに追加するようにキューサービス４０５に追加指示を送信する。追加指示を受信したキューサービス４０５は、キューにキューメッセージを追加する。バックエンド処理部４０２１は、キューメッセージを取得するために、キューサービス４０５に取得指示を出す。取得指示を受けたキューサービス４０５は、キューメッセージと、キューメッセージ毎に固有に割り振られたメッセージＩＤと、受取ＩＤとを取得指示に対するレスポンスとしてバックエンド処理部４０２１に返す。メッセージＩＤとは、キューメッセージを一意に定めるためにキューメッセージごとに割り振られた固有の情報である。受取ＩＤは、処理が終了したバックエンド処理部４０２１がキューメッセージを削除指示する際に使用する。キューメッセージと、メッセージＩＤと、受取ＩＤは、関連付けされて保存されることになる。バックエンド処理部４０２１は、処理依頼を完了すると、受取ＩＤに対応するキューメッセージの削除指示をキューサービス４０５に対して行う。削除指示を受けたキューサービス４０５は、バックエンド処理部４０２１が指示した受取ＩＤに対応するキューメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部４０２１以外のバックエンド処理部４０２１が同じキューメッセージを処理するという冗長な処理を防ぐことができる。

また、キューサービス４０５は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。不可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求をした場合に、キューサービス４０５はバックエンド処理部４０２１に対してキューメッセージを渡さないことを指す。バックエンド処理部４０２１がキューからキューメッセージを取得すると、取得されたキューメッセージはキューサービス４０５によって不可視になる。可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求した場合に、キューサービス４０５がバックエンド処理部４０２１に対してキューメッセージを渡すことを指す。バックエンド処理部４０２１に取得され不可視になっているキューメッセージは、処理を行っているバックエンド処理部４０２１から処理結果が一定時間返ってこない場合にキューサービス４０５によって可視になる。

ストレージ４０６は、データ保存に利用されるストレージを提供する。バイナリデータの集合を保存する機能を提供する。また、後述する処理確認テーブル、およびキュー管理テーブルを保持する機能も提供する。

ヴァーチャルマシン４０７は、要求受信部４０１１、要求受信部エージェント４０１２で構成される。ヴァーチャルマシン４０１との違いは、管理ユーザーのみが利用できる要求受信部４０１１のインスタンスを持つヴァーチャルマシンということである。このヴァーチャルマシンの要求受信部４０１１により管理ユーザーは、キュー管理テーブルを操作することができる。

次に、本発明の実施例１におけるキューメッセージについて説明する。図５は、キューメッセージの一例を示した図である。キューメッセージは、要求受信部４０１１がバックエンド処理部４０２１に依頼する処理の内容を記述したものである。

５０１は、キューメッセージを追加するキューの場所を示している。５０２は、タイムアウト時間を示している。５０２のＶｉｓｉｂｉｌｉｔｙ Ｔｉｍｅｏｕｔ＝３０と言うのは、次のような意味がある。バックエンド処理部４０２１がキューメッセージを取得してから３０秒を経過しても、キューメッセージを取得したバックエンド処理部４０２１からレスポンスがない場合に、キューサービス４０５がキューメッセージを不可視から可視にする。５０３のｍｅｓｓａｇｅｔｔｌ＝３６００と言うのは、次のような意味がある。３６００秒経過してもバックエンド処理部４０２１がキューメッセージの削除指示を出していない場合に、キューメッセージがバックエンド処理部４０２１に処理されていなくてもキューサービス４０５がそのキューメッセージを削除する。５０４は、キューメッセージが作成された日付を意味する。

次に、キューメッセージのメッセージデータコンテンツ部分について説明する。メッセージデータコンテンツ部分は、ユーザーからの処理依頼に応じて決定される。５０５は、受付ＩＤを示している。図５の場合、受付ＩＤは０００１である。受付ＩＤは、ユーザーからの処理依頼に応じて作成される一意な情報である。５０６は、コンテンツＩＤを示している。図５の場合、コンテンツＩＤはｄ＿００００１である。５０７は、文書リポジトリ３０１に保存されているコンテンツの格納場所を示している。なお、５０８に関しては後述する。

次に、各種テーブルについて図６を参照しながら説明する。図６（ａ）はキュー管理テーブルを示しており、図６（ｂ）は処理確認テーブルを示している。

始めに、キュー管理テーブルについて図６（ａ）を参照しながら説明する。６０１のＱｕｅｕｅ ＩＤはキューの固有情報を示しており、６０２のＤｅｖｉｃｅ ＩＤは識別情報を示している。識別情報とは、各デバイスを一意に定めるためにデバイス毎に割り振られた固有情報である。デバイスが異なれば識別情報は異なる。本発明の実施例１において、Ｑｕｅｕｅ ＩＤとＤｅｖｉｃｅ ＩＤは一対一対応である。即ち、画像形成装置１台に対してキューが１つ割り当てられている。

６０３のＤｅｖｉｃｅ ｍｏｄｅｌは、デバイスの製造メーカーと機種を示している。以降、この情報をデバイス情報と呼称する。同じ種類に分類される画像形成装置同士は、デバイス情報の値が同じになる。なお、デバイス情報には、メーカー名と機種モデル名が記載されている。よって、デバイス情報から分かる情報は、どこのメーカーであるのか、ということと、どの機種であるのかという２つの情報である。詳細を説明する。図６（ａ）のデバイス情報が“１”のテーブルのＤｅｖｉｃｅ＿ｉｄは“ａｂｃ＿０００１”と記載されている。“ａｂｃ”という部分がメーカー名を表している。“０００１”という部分が機種モデル名を表している。

６０４のＮｕｍｂｅｒ ｏｆ Ｉｎｓｔａｎｃｅは、Ｑｕｅｕｅ ＩＤ毎に設定されているインスタンスの利用上限値を示しおり、キューに設定されている印刷サービスの所定値である。これについて詳細に説明する。上述したように、複数のヴァーチャルマシン上で複数のバックエンド処理部４０２１が稼動しており、このヴァーチャルマシンは、スケールアウトと呼ばれる技術を使うことでインスタンス数を増加させることができる。しかし、無闇にスケールアウトを行えばサーバーコンピュータ群１０２に負担がかかる。そこで、デバイスに合わせてバックエンド処理部４０２１のインスタンス数を決定する。これにより、デバイスの能力に合った処理が行われる。このように、夫々のキューにはＮｕｍｂｅｒ ｏｆ Ｉｎｓｔａｎｃｅと呼ばれる値が設定されている。

６０５のＱｕｅｕｅ Ｌｅｎｇｔｈは、キューに格納するキューメッセージの数の所定値を示しており、キューに設定されているキューメッセージの所定値である。キューに格納されているキューメッセージの数がＱｕｅｕｅ Ｌｅｎｇｔｈの値を超えた場合に、要求受信部４０１１はスケールアウトを指示するか否かの判断を行う。なぜなら、キューに格納されているキューメッセージの数が、そのキューの所定値であるＱｕｅｕｅ Ｌｅｎｇｔｈの値を超えた場合、バックエンド処理部４０２１の処理が遅れていることを意味するからである。このように、夫々のキューにはＱｕｅｕｅ Ｌｅｎｇｔｈと呼ばれる値が設定されている。

ここで、キュー管理テーブルの設定について詳細に説明する。プリントシステムの管理者は、管理者用の要求受信部４０１１にクライアントコンピュータ１０５からアクセスする。管理者は、管理者情報を入力し認証を行う。要求受信部４０１１は、管理者情報が正規であることに応じて管理者用の操作画面をクライアントコンピュータ１０５に送信する。管理者は、上述の操作画面を用いてキュー管理テーブルの設定を行う。管理者から設定された情報を基に、管理者用ヴァーチャルマシン４０７の要求受信部４０１１はキュー管理テーブルを更新する。

ここで、管理者が行うキューテーブルの設定の一例を示す。例えば、管理者は印刷速度の低い画像形成装置にＮｕｍｂｅｒ ｏｆ Ｉｎｓｔａｎｃｅの値を低く設定する。なぜなら、印刷速度の低い画像形成装置に対する処理依頼を早く処理したとしても、印刷速度が遅いため印刷データがストレージに溜まっていってしまうからである。これにより、サーバーコンピュータ群１０２のストレージを圧迫する可能性がある。また、キューテーブルの設定のその他の例として、管理者は印刷速度の速い画像形成装置に対しＱｕｅｕｅ Ｌｅｎｇｔｈの値を低く設定する。なぜなら、印刷速度の速い画像形成装置は印刷が早いため多くの印刷データを処理することができるからである。ゆえに、印刷速度の速い画像形成装置に対応するキューに追加されるキューメッセージは、より多くのインスタンス数を持つバックエンド処理部４０２１に処理される方が良い。Ｑｕｅｕｅ Ｌｅｎｇｔｈの値を低くすることで、要求受信部４０１１によるスケールアウトを行うかどうかの判断のタイミングをより早めることができる。結果、プリントシステムの印刷処理の高速化を図ることができる。ただし、いずれの設定もこの効果を望まないのであれば上述のように設定しなくても良いことは言うまでもない。

次に、処理確認テーブルについて図６（ｂ）を参照しながら説明する。処理確認テーブルは、処理依頼が完了したかを確認するために用いるものである。６０６のｒｅｑｕｅｓｔ ＩＤは、受付ＩＤを示している。６０７ｄｏｃｕｍｅｎｔ ＩＤは、コンテンツＩＤを示している。６０８のｒｅｓｕｌｔ＿ｓｔｏｒｅｄＵＲＩは、バックエンド処理部４０２１が処理した結果が格納されている場所を示している。

ここで、処理依頼が完了したかを確認する方法の一例を示す。画像形成装置１０４のプラットフォームアプリケーション３０３が確認を行う。このプラットフォームアプリケーション３０３は、要求受信部４０１１に処理依頼をした際に、処理依頼に対応する受付ＩＤを要求受信部４０１１から受信する。プラットフォームアプリケーション３０３は、受付ＩＤに対応した処理が終了したかどうかを要求受信部４０１１に対してポーリングで問い合わせる。問い合わせを受けた要求受信部４０１１は、ストレージ４０６に保存されている処理確認テーブルの受付ＩＤを確認する。具体的には、問い合わせを受けた要求受信部４０１１は、問い合わせを受けた受付ＩＤに対応するｒｅｓｕｌｔ＿ｓｔｏｒｅｄＵＲＩの欄に格納場所が記載されているかどうかを確認する。記載されている場合、要求受信部４０１１は処理結果の確認を行っているプラットフォームアプリケーション３０３に格納場所を送信する。記載されていない場合、要求受信部４０１１はプラットフォームアプリケーション３０３に終了していない旨を送信する。これにより、プラットフォームアプリケーション３０３は処理結果の確認を行うことができる。

なお、処理確認テーブルのエントリーは次の２つのタイミングで加えられる。キューメッセージをキューサービス４０５に追加指示する際、要求受信部４０１１はストレージ４０６に保存されている処理確認テーブルに受付ＩＤと識別情報を新たに加える。一例としては、図６（ｂ）の６０６の受付ＩＤ０００１と６０７の識別情報ｄ＿００００１である。処理依頼を処理し終えたバックエンド処理部４０２１は、処理した受付ＩＤに対応する６０８の欄に格納場所を加える。一例としては、６０８の欄のｈｔｔｐ：：／／ｐｒｉｎｔ−ｓｖ．ｂｌｏｂ．ｎｅｔ／ｄｅｖ＿０００１／ｐｒｉｎｔｄａｔａ／ｐｄｌ＿０００１である。

次に、本発明の実施例１におけるプリントシステムを用いた印刷の手順について、図７を参照しながら詳細に説明する。図７は、本発明の実施例１におけるプリントシステムが行う処理の流れを示している。また、本発明の実施例１のバックエンド処理部４０２１は印刷データ処理を行う。なお、印刷データ処理を行うバックエンド処理部４０２１の一例を印刷サービスと呼称する。

始めに、ユーザーは、デバイスブラウザを用いてコンテンツの印刷要求を指示する。デバイスブラウザは、印刷指示されたコンテンツのコンテンツＩＤ、および識別情報、および印刷要求を要求受信部４０１１に送信する（Ｓ７００１）。Ｓ７００１において、コンテンツＩＤ、および識別情報、および印刷要求を受信した要求受信部４０１１は、印刷要求に対するキューメッセージと受付ＩＤを作成し、作成した受付ＩＤをデバイスブラウザ３０２へ送信する。また、要求受信部４０１１は、受信したコンテンツＩＤに対応したコンテンツの取得を文書リポジトリ３０１に要求する（Ｓ７００２）。

Ｓ７００２において、受付ＩＤを受信したデバイスブラウザ３０２は、受付ＩＤをプラットフォームアプリケーション３０３に送信する。また、文書リポジトリ３０１にコンテンツの取得を要求した要求受信部４０１１は、文書リポジトリ３０１からコンテンツを取得する（Ｓ７００３）。Ｓ７００３以降、プラットフォームアプリケーション３０３は受信した受付ＩＤに対応する印刷データ処理が完了するのを確認するまで要求受信部４０１１に対してポーリングを行う。Ｓ７００３において、コンテンツを取得した要求受信部４０１１は、コンテンツをストレージ４０６に格納する（Ｓ７００４）。

Ｓ７００４において、コンテンツをストレージ４０６に格納した要求受信部４０１１は、コンテンツが格納されている場所を記載したキューメッセージをキューに追加するようキューサービス４０５に追加指示を出す（Ｓ７００５）。印刷サービスは自身が処理を担当しているキューにキューメッセージが存在するかどうかをポーリングにより確認している。要求受信部４０１１によりキューにキューメッセージが追加された場合、印刷サービスはキューサービス４０５に取得指示を出す（Ｓ７００６）。Ｓ７００６において、取得指示を出してキューメッセージを取得した印刷サービスは、キューメッセージに記述されているコンテンツの格納場所を基にストレージ４０６からコンテンツを取得する（Ｓ７００７）。

Ｓ７００７において、コンテンツを取得した印刷サービスは、取得したコンテンツを印刷データへ変換する印刷データ処理を実行する。この際、印刷サービスはドライバプログラムをメモリにロードして印刷データ処理を実行する。印刷データ処理を実行した印刷サービスは、実行結果である印刷データをストレージ４０６に格納する（Ｓ７００８）。Ｓ７００８において、印刷データを格納した印刷サービスは、印刷データの格納場所が受付ＩＤと関連付くように処理確認テーブルに記載する。なお、印刷サービスは取得したキューメッセージから受付ＩＤを確認できる。印刷サービスは、処理を行ったキューメッセージの削除指示をキューサービスへ出す（Ｓ７００９）。

プラットフォームアプリケーション３０３は、Ｓ７００９において印刷データの格納場所が追記された処理確認テーブルに対し受付ＩＤを基に要求受信部４０１１を介して確認する（Ｓ７０１０）。Ｓ７０１０において、印刷データの格納場所を確認したプラットフォームアプリケーション３０３は、ストレージ３０６から印刷データを取得する（Ｓ７０１１）。Ｓ７０１１において、印刷データを取得したプラットフォームアプリケーション３０３は、画像形成装置１０４が印刷データの印刷が行えるよう処理を行う（Ｓ７０１２）。以上が、本発明の実施例１におけるプリントシステムを用いた印刷の手順になる。

次に、本発明の実施例１におけるサーバーコンピュータ群１０２の動作について図８、図９を参照しながら詳細に説明する。図８は、要求受信部４０１１の印刷データ生成フローチャートを示している。図９は、印刷サービスの印刷データ生成フローチャートを示している。なお、ジョブとはユーザーからの処理依頼を基に作成されるキューメッセージのことを指しており、本発明の実施例１における処理依頼は印刷要求である。また、本説明における印刷サービスと図７の印刷サービスとは同じである。

始めに、図８を参照しながら要求受信部４０１１の印刷データ生成手順について説明する。なお、この要求受信部４０１１は管理者用のヴァーチャルマシンの要求受信部４０１１ではない。要求受信部は、ユーザーから印刷要求されたコンテンツのコンテンツＩＤと、識別情報を受信する（Ｓ８００１）。

Ｓ８００１において、コンテンツＩＤと識別情報を受信した要求受信部は、文書リポジトリからコンテンツＩＤに対応するコンテンツを取得する（Ｓ８００２）。

Ｓ８００２において、コンテンツを取得した要求受信部は、ストレージにコンテンツを保存する（Ｓ８００３）。

Ｓ８００３において、コンテンツを保存した要求受信部は、受信した識別情報に割り当てられているキューを特定し、特定したキューに格納されているキューメッセージの数を取得する（Ｓ８００４）。

Ｓ８００４において、キューに格納されているキューメッセージの数を取得した要求受信部は、受信した識別情報に合致する識別情報がキュー管理テーブルに存在するかどうか検索する（Ｓ８００５）。検索した結果、識別情報が存在していない場合、Ｓ８００６へ処理を進める。検索した結果、識別情報が存在している場合、Ｓ８００７へ処理を進める。

Ｓ８００６において、要求受信部はエラー処理を行う。エラー処理としては、要求受信部がデバイスブラウザ３０２に対してエラーである旨を送信する処理である。エラーである旨を受信したデバイスブラウザ３０２は処理を中止する。一方、エラー処理を行った場合、受信要求部は“Ａ”へ処理を進める。“Ａ”へ処理を進めた場合、プリントシステムの処理を停止させる。

Ｓ８００７において、要求受信部は、受信した識別情報に対応するキューに格納されるキューメッセージの所定値をキュー管理テーブルから確認する。そして、要求受信部は、取得したキューに格納されているキューメッセージの数が、特定したキューに設定されているキューメッセージの所定値以上かどうかを判断する（Ｓ８００７）。判断の結果、取得したキューに格納されているキューメッセージの数の方が大きい場合、要求受信部はＳ８００８へ処理を進める。取得したキューに格納されているキューメッセージの数の方が小さい場合、要求受信部はＳ８０１０へ処理を進める。
Ｓ８００８へ処理を進めた要求受信部は、受信した識別情報に対応するキューに対し、幾つ印刷サービスが設定されているか（割り当てられているか）を確認する。確認した数とキュー管理テーブルにおいて設定されている印刷サービスを使用できる所定値とを比較する。比較の結果、確認した数の方が所定値よりも少なかった場合、要求受信部は、Ｓ８００９へ処理を進める。確認した数の方が所定値よりも多かった場合、要求受信部は、Ｓ８０１０へ処理を進める。
Ｓ８００９において、要求受信部は、印刷サービスに対しインスタンスの数を１つ増加するよう指示をする。即ち、要求受信部４０１１は、印刷サービスの数を調整する。

Ｓ８０１０において、要求受信部は、ジョブに応じたキューメッセージを作成する。

Ｓ８０１０において、キューメッセージを作成した要求受信部は、キューサービス４０５にキューメッセージを追加するよう指示する（Ｓ８０１１）。Ｓ８０１１において、キューメッセージ追加を指示した要求受信部は、追加したキューメッセージに対応するコンテンツのコンテンツＩＤを、ストレージ３０６に保存されている処理確認テーブルに追加する（Ｓ８０１２）。以上が要求受信部の印刷データ生成手順の説明となる。

次に、図９を参照しながら印刷サービスの印刷データ生成手順について説明する。

印刷サービスは、キューサービス４０５に取得指示を出す（Ｓ９００１）。Ｓ９００１において、キューメッセージの取得指示を出した印刷サービスは、キューメッセージがあるかどうかを確認する（Ｓ９００２）。Ｓ９００２において、キューメッセージがないと確認された場合、キューにキューメッセージがあるかどうかを再度確認する（ポーリング）。キューにキューメッセージがあると確認された場合、印刷サービスはＳ９００３へと処理を進める。なお、Ｓ９００３に処理を進めた場合、キューサービス４０５は取得指示されたキューメッセージを不可視にする。

Ｓ９００３において、Ｓ９００２で確認したキューメッセージを、キューメッセージを取得した印刷サービス以外の印刷サービスが参照できないようにする。この処理は、印刷サービスではなくキューサービス４０５が行う（Ｓ９００３）。

Ｓ９００２において、キューメッセージを確認した印刷サービスは、キューメッセージの解読を行う（Ｓ９００４）。キューサービス４０５は、キューメッセージの解読を行うことでコンテンツの保存場所を特定する。

Ｓ９００４において、コンテンツの保存場所を特定した印刷サービスは、ストレージ内の保存場所からコンテンツを取得する（Ｓ９００５）。Ｓ９００５において、コンテンツを取得した印刷サービスは、取得したコンテンツに対し印刷データ処理を行う（Ｓ９００６）。

この際、キューサービス４０５は、キューメッセージに記載されていたＶｉｓｉｂｉｌｉｔｙ Ｔｉｍｅｏｕｔに設定されているタイムアウト期間内に印刷データ処理が完了できたかどうかを確認している（Ｓ９００７）。完了できなかった場合、“Ｂ”へ処理を進め、完了できた場合、Ｓ９００８へ処理を進める。“Ｂ”へ処理を進めた場合、Ｓ９０１１の手前のＢから処理を実行する。

Ｓ９００７へ処理を進めた印刷サービスは、ストレージ４０６に印刷データを保存する（Ｓ９００８）。Ｓ９００８において、ストレージ４０６に印刷データを保存した印刷サービスは、印刷データを格納したストレージ４０６内の保存場所を、ストレージ４０６内の処理確認テーブルに追加する（Ｓ９００９）。

Ｓ９００９において、印刷データの保存場所を処理確認テーブルに追加した印刷サービスは、正常に印刷処理が完了したかどうかを確認する（Ｓ９０１０）。Ｓ９０１０において、正常に印刷処理が完了したと判断された場合、印刷サービスはキューサービス４０５に対しキューメッセージの削除指示を出す（Ｓ９０１１）。正常に印刷処理が完了したと判断されなかった場合、キューサービス４０５はキューメッセージを可視にする（Ｓ９０１２）。可視にすることで、印刷サービスは再度キューからキューメッセージを取得し、取得したキューメッセージに対応するコンテンツの印刷データ処理が行えるようになる。

次に、図１０を参照しながら印刷サービスのインスタンス数を減らす手順について説明する。図１０は、要求受信部４０１１が行う処理である。なお、本説明における印刷サービスと図７の印刷サービスとは同じである。また、この処理は、プラットフォームアプリケーション３０３が処理依頼の確認をポーリングで問い合わせている状態から開始される。

要求受信部は、印刷データが生成されたかどうかを、受付ＩＤを基にストレージ４０６内の処理確認テーブルから確認する（Ｓ１０００１）。Ｓ１０００１において、印刷データの生成確認をした要求受信部は、ストレージ４０６内に印刷データがあるかどうかを判定する（Ｓ１０００２）。Ｓ１０００２において、印刷データがあると判断された場合、Ｓ１０００３に処理を進める。印刷データがないと判断された場合、Ｓ１０００１から再び処理を開始する。

Ｓ１０００３に処理を進めた要求受信部は、処理確認テーブルに記載されている印刷データ格納場所を画像形成装置１０４へ送信する。Ｓ１０００３において、印刷データ格納場所を送信した要求受信部は、印刷データの格納場所を送信したデバイスに対応するキューに格納されているキューメッセージの数を取得する（Ｓ１０００４）。Ｓ１０００４において、キューに格納されているキューメッセージの数を取得した要求受信部は、受信した識別情報に対応するキューに設定されているキューメッセージの所定値をキュー管理テーブルから確認する。そして、要求受信部は、取得したキューに格納されているキューメッセージの数が特定したキューに設定されているキューメッセージの所定値以下かどうかを判断する（Ｓ１０００５）。判断の結果、取得したキューに格納されているキューメッセージ（ジョブ）の数の方が小さい場合、要求受信部は、Ｓ１０００６へ処理を進める。取得したキューに格納されているキューメッセージの数の方が大きい場合、要求受信部は、処理を終了する。

Ｓ１０００６へ処理を進めた要求受信部は、印刷データの格納場所を送信したデバイスに対応するキューに対し、幾つ印刷サービスが設定されているか（割り当てられているか）を確認する。確認した数とキュー管理テーブルにおいて設定されている印刷サービスを使用できる所定値とを比較する。比較の結果、確認した数の方が所定値よりも多かった場合、要求受信部は、Ｓ１０００７へ処理を進める。確認した数の方が所定値よりも少なかった場合、要求受信部は処理を終了する。Ｓ１０００７へ処理を進めた要求受信部は、印刷サービスのインスタンス数を１つ減少させるよう指示する。即ち、要求受信部４０１１は、印刷サービスの数を調整する。

以上、説明した方法により、サーバーコンピュータ群１０２の資源を適正に利用できる。

次に、本発明の実施例２では、プリントシステムを用いた印刷において、本発明の実施例１とは別の手法を説明する。本発明の実施例２では、ユーザーはプリントシステムを利用する前に事前に登録を行わなくてはならない。そして、その登録した内容に応じてサーバーコンピュータ群１０２の資源を利用できる度合いが変わるというものである。始めに、本発明の実施例１とは異なる部分について説明する。

本発明の実施例２における識別情報は、画像形成装置毎に割り振られた固有なものではない。本発明の実施例２における識別情報は、登録情報と呼ばれる情報である。登録情報について説明する。本発明の実施例２では、プリントシステムを利用する際に登録が必要になる。登録の内容の一例としては、プリントシステム利用者のＩＤ、そのＩＤに対応するパスワード、ライセンス等がある。ユーザーは、例えば、デバイスブラウザ３０２を用いて登録内容を入力する。なお、ライセンスの詳細に関しては後述する。登録は、ユーザーがプリントシステムを利用する前に行われ、登録が行われると入力された情報を基に登録情報が作成される。登録情報の作成は、管理用ヴァーチャルマシン４０７により行われる。ユーザーはこの登録情報を基にサーバーコンピュータ群１０２に認証を行い、プリントシステムを利用することになる。なお、後述するが登録されていない登録情報に対応するユーザーからアクセスがあった場合は、エラーとして処理される。また、１つの登録情報に対して複数のプリントシステム利用者のＩＤを登録することもでき、グループ単位で登録情報を一元化することもできる。

登録情報の登場により、キュー管理テーブルは図１１（ａ）のように変わる。Ｄｅｖｉｃｅ ｉｄとＤｅｖｉｃｅ ｍｏｄｅｌが削除される。さらに、ストレージ４０６にライセンス管理テーブルが保存される。なお、キュー管理テーブルの６１４は６０１と同じＱｕｅｕｅ ＩＤである。６１５は６０４と同じＮｕｍｂｅｒ ｏｆ Ｉｎｓｔａｎｃｅである。６１６は６０５と同じＱｕｅｕｅ Ｌｅｎｇｔｈである。

ライセンス管理テーブルについて図１１（ｂ）を参照しながら説明する。６１２のＲｅｇｉｓｔｅｒは、登録情報を示している。６１３のＬｉｃｅｎｓｅは、ライセンスを示している。ここで、ライセンスについて説明する。

登録の際に、ユーザーはプリントシステムの利用に課金を行うかどうかを設定できる。これにより、例えば、次のような設定を行うことができる。課金を多く行ったユーザーは、サーバーコンピュータ群１０２の資源をより多く利用できる。課金を少なく行ったユーザーは、課金を多く行ったユーザーよりもサーバーコンピュータ１０２の資源を多く使えない。また、課金を行わなかったユーザーは、課金を少なく行ったユーザーよりもさらにサーバーコンピュータ１０２の資源を使えない。課金のレベル、有無を判断する指標として上述のライセンスが存在する。

本発明の実施例２では、ライセンスを次のように定めている。６１３のＬｉｃｅｎｓｅが“Ａ”というのは、課金を多く行ったユーザーに与えられる。６１３のＬｉｃｅｎｓｅが“Ｂ”というのは、課金を少なく行ったユーザーに与えられる。６１３のＬｉｃｅｎｓｅが“Ｎｏ”というのは、課金を行わなかったユーザーに与えられる。

キュー管理テーブルとライセンス管理テーブルの関係について説明する。登録情報を取得した要求受信部４０１１は、ライセンス管理テーブルを参照し、取得した登録情報が存在するかどうかを判断する。存在していると判断した場合、要求受信部４０１１は、ライセンス管理テーブルに登録されているライセンスを確認する。要求受信部４０１１は、ライセンスに対応したキューＩＤを特定する。一例を用いて具体的に説明する。図１１（ｂ）の６１２のＲｅｇｉｓｔｅｒの値が“ｕｓｅｒ＿ａ”の登録情報は、６１３のＬｉｃｅｎｓｅの値が“Ａ”である。６１３のＬｉｃｅｎｓｅの値が“Ａ”である場合、６０９のＱｕｅｕｅ ＩＤの値が“１”のキューが割り当てられる。同様に、図１１（ｂ）の６１２のＲｅｇｉｓｔｅｒの値が“ｕｓｅｒ＿ｂ”の登録情報は、６１３のＬｉｃｅｎｓｅの値が“Ｂ”である。６１３のＬｉｃｅｎｓｅの値が“Ｂ”である場合、６０９のＱｕｅｕｅ ＩＤの値が“２”のキューが割り当てられる。また、６１３のＬｉｃｅｎｓｅの値が“Ｎｏ”の登録情報に対しては、６０９のＱｕｅｕｅ ＩＤの値が“１００”から“１０３”の間のキューが１つ割り当てられる。どのキューが割り当てられるかについては後述する。

また、６１３のＬｉｃｅｎｓｅの値が“Ａ”である登録情報が“ｕｓｅｒ＿ａ”以外にさらに存在する場合、Ｑｕｅｕｅ ｉｄが“１”と同様のインスタンスの所定値と所定値を持つ別のキューを割り当てることが一例として考えられる。これにより、課金を行っている登録情報を用いた印刷には、登録情報毎にキューが割り当てられる。課金を行っていない登録情報を用いた印刷には、登録情報毎にキューが割り当てられず、特定のグループ毎に共通で使用されるキューが割り当てられるというサービスの違いをつけられる。なお、登録情報ごとに割り当てられるキューを固有キュー、特定のグループ毎に共通で使用されるキューを共通キューと呼ぶ。

なお、本発明の実施例１と同様に、キュー管理テーブルは管理用ヴァーチャルマシン４０７を用いて操作可能である。また、ライセンス管理テーブルも管理用ヴァーチャルマシン４０７を用いて操作可能である。その他説明をしなかった部分については、本発明の実施例１と同じである。具体的には、プリントシステムの構成、各装置の内部構成等である。

次に、登録情報のライセンスに応じて、登録情報に割り当てるキューを変更する処理について図１２、図１３を参照しながら説明する。図１２は、登録情報に応じた各種設定処理の流れを示す図である。図１３は、課金を行っていない登録情報に応じたキュー割り当て処理を示す図である。

始めに、ユーザーは画像形成装置１０４のデバイスブラウザを介して、登録内容を管理者用ヴァーチャルマシン４０７に送信する。管理者用ヴァーチャルマシン４０７はユーザーが入力した登録内容に応じた登録情報を作成し、ユーザーに登録情報を送信する。管理者は管理者用ヴァーチャルマシン４０７を用いて、登録内容に応じてキュー管理テーブルを更新する。なお、管理者が手動で更新するのではなく、管理者用ヴァーチャルマシン４０７が自動で更新しても良い。

プリントシステムを利用して印刷を行いたいユーザーは、この登録情報を管理者用ではないヴァーチャルマシン４０１に送信する。この際、画像形成装置１０４はデバイス情報も送信する。また、ユーザーは登録情報と共にプリントシステム利用者のＩＤとパスワードも送信するようにしても良い。これにより、送信した登録情報を使用しているユーザーが正規なユーザーであるかを、プリントシステム利用者のＩＤとそのＩＤに対応するパスワードによってより保証することができる。

要求受信部４０１１は、デバイス情報と登録情報を取得する（Ｓ１２０１）。Ｓ１２０１において、デバイス情報と登録情報を取得した要求受信部４０１１は、ライセンス管理テーブルに取得した登録情報と同じ登録情報が存在するか判断する（Ｓ１２０２）。Ｓ１２０２において、存在しないと判断された場合、Ｓ１２０３へ処理を進めエラー処理を行い処理を中止する。Ｓ１２０２において、存在すると判断された場合、Ｓ１２０４へ処理を進める。Ｓ１２０４において、要求受信部４０１１はライセンス管理テーブルを基に、取得した登録情報は課金されているかどうかを判断する。即ち、登録情報が課金対象であるかどうかを判断する。課金されていない場合、“Ｃ“へ処理を進める。課金されている場合、Ｓ１２０５へ処理を進める。

ここで、“Ｃ”へ処理を進めた要求受信部４０１１の処理について説明する。要求受信部４０１１は、デバイス情報を基に画像形成装置１０４がカラー対応しているかどうかを判断する（Ｓ１３０１）。これは、デバイス情報に記載の製造メーカー名と機種モデル名から判断することになる。Ｓ１３０１において、カラーであると判断された場合、Ｓ１３０２へ処理を進める。カラーでないと判断された場合、Ｓ１３０５へ処理を進める。

Ｓ１３０２へ処理を進めた要求受信部４０１１は、デバイス情報を基に画像形成装置１０４がＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）であるかどうかを判断する。ＭＦＰであると判断された場合、Ｓ１３０３の処理を実行する。即ち、取得した登録情報に対しカラーＭＦＰのキューを割り当てる（Ｓ１３０３）。カラーＭＦＰのキューとは図１１（ａ）のＱｕｅｕｅ ＩＤが“１００”のテーブルのキューである。ＭＦＰでないと判断された場合、カラーＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）のキューを割り当てる（Ｓ１３０４）。カラーＳＦＰのキューとは図１１（ａ）のＱｕｅｕｅ ＩＤが“１０１”のテーブルのキューである。

Ｓ１３０５へ処理を進めた要求受信部４０１１は、デバイス情報を基に画像形成装置がＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）であるかどうかを判断する。ＭＦＰであると判断された場合、Ｓ１３０６の処理を実行する。即ち、取得した登録情報に対しモノクロＭＦＰのキューを割り当てる（Ｓ１３０６）。モノクロＭＦＰのキューとは図１１（ａ）のＱｕｅｕｅ ＩＤが“１０２”のテーブルのキューである。ＭＦＰでないと判断された場合、モノクロＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）のキューを割り当てる（Ｓ１３０７）。モノクロＳＦＰのキューとは図１１（ａ）のＱｕｅｕｅ ＩＤが“１０３”のテーブルのキューである。Ｓ１３０３、Ｓ１３０４、Ｓ１３０６、Ｓ１３０７の処理を終えた要求受信部４０１１は、“Ｄ”へ処理を進め、Ｓ１２０６から処理を実行する。

Ｓ１２０５へ処理を進めた要求受信部４０１１は、登録情報に応じた所定のキューを、登録情報に割り当てる。このキューは、所定のキュー以外のキューであるカラーＭＦＰのキューやモノクロＳＦＰのキュー等とは異なり、登録情報固有のキューである。次に、要求受信部４０１１は、Ｓ１２０６へ処理を進める。

Ｓ１２０６において、要求受信部４０１１はデバイス情報を基に所定のメーカーであるかどうかを判断する。所定のメーカーというのは、管理者が予め定めたメーカーである。管理者が所定のメーカーを指定する理由は、印刷させようとしている画像形成装置１０４が十分な品質で印刷できるかどうかを判定する必要があるからである。所定のメーカーであると判定された場合、要求受信部４０１１はバックエンド処理部４０２１に所定のドライバとして固有ドライバプログラムをロードするように指示を出す（Ｓ１２０７）。所定のメーカーでないと判定された場合、要求受信部４０１１はバックエンド処理部４０２１に所定のドライバ以外のドライバとして共通ドライバプログラムをロードするように指示を出す（Ｓ１２０８）。

ここで、固有ドライバプログラムと共通ドライバプログラムについて説明する。固有ドライバプログラムは、指定された印刷設定を十分に満たすことができるドライバプログラムである。一方、共通プログラムドライバは、一部の印刷設定のみしか満たすことの出来ないドライバプログラムである。例えば、共通ドライバは、用紙サイズ、または、印刷用紙の給紙口の設定は可能であるが、ステイプルやパンチと言った仕上げ設定、または、製本印刷等の面付け設定は出来ない。

このように所定の画像形成装置に応じて差別化するのには、次のような理由がある。それは、機能を保証することができない画像形成装置に対して、保証できないサービスをクラウドが提供した場合、ユーザーは自分の意図する印刷が出来ない可能性があるからである。結果、ユーザーとしてみれば、印刷のやり直しの手間がかかり、また、印刷代を支払っているのであれば印刷代、および画像形成装置の消耗品の無駄となる。また、クラウドサービスを提供している側としてみれば、クラウド資源を無駄に消費したことになる。そこで、上述の様に、例えば、メーカーに応じて提供するサービスを変更するという処置を取る。なお、本発明の実施例２では、メーカーで判断を行ったが、機種モデル名も考慮して判断を行っても良い。または、機種モデル名のみで判断を行っても良い。

次に、実施例１の要求受信部４０１１が処理する図８の処理と異なる部分について説明する。図８のＳ８００１において、要求受信部４０１１はデバイスＩＤを取得しない。Ｓ８００４において、要求受信部４０１１がキューに格納されているキューメッセージの数を取得する際は、要求受信部４０１１は登録情報を基にキューを特定し格納されているキューメッセージの数を取得する。Ｓ８００５、およびＳ８００６の処理は行われない。Ｓ８００７、およびＳ８００８において、キュー管理テーブルを参照しキューを特定する際には、要求受信部４０１１は登録情報を基にキューを特定する。

以上、説明した方法により、サーバーコンピュータ群１０２の資源を適正に利用できる。

（その他の実施例）
また、本発明の各実施例では、画像形成装置１０４、およびクライアントコンピュータ１０５は、夫々１台ずつであった。しかし、各装置とも複数台の構成であっても構わない。

また、本発明の各実施例では、サーバーコンピュータ群１０２が印刷データ処理をしてプリンタへ送るものであった。しかし、サーバーコンピュータ群１０２が印刷データ処理以外に、印刷データをラスタイメージへと変換する処理を行っても良い。

また、本発明の各実施例では、サーバーコンピュータ群１０２上のアプリケーションソフトウェアで作成されたコンテンツは、文書リポジトリに一旦保存されるものであった。しかし、文書リポジトリに一旦保存されなくても良い。この場合、プリントシステムを利用した印刷は次のようになる。ユーザーはデバイスブラウザを通じて、アプリケーションソフトウェアに印刷指示を送る。アプリケーションソフトウェアは、作成されたコンテンツをサーバーコンピュータ群１０２内の何れかのハードウェア・リソースに格納する。

また、本発明の各実施例では、１つのインスタンスに対し、１台のサーバーコンピュータで動作するものであった。しかし、複数のインスタンスが１台のサーバーコンピュータ上で動作していても良い。例えば、マルチコアのＣＰＵにおいて、ＣＰＵ内の１つのコアに対して１つのインスタンスを割り当てても良く、または２つのコアに対して１つのインスタンスを割り当てても良い。このように、１つのインスタンスの割り当て方に特に制限はない。

また、本発明の各実施例では、サーバーコンピュータ群１０２の持つ機能を次のように分離した。要求受信部４０１１の機能を持つサーバーコンピュータ、バックエンド処理部４０２１の機能を持つサーバーコンピュータ、キューサービス４０５とストレージ４０６の両方の機能を持つサーバーコンピュータである。しかし、サーバーコンピュータが持つ機能を上述の様な組み合わせにしなくても良い。例えば、要求受信部４０１１とバックエンド処理部４０２１の両方の機能を持つサーバーコンピュータ、キューサービス４０５とストレージ４０６の両方の機能を持つサーバーコンピュータのようにしても良い。または、要求受信部４０１１とキューサービス４０５の機能を持つサーバーコンピュータ、バックエンド処理部４０２１とストレージ４０６の機能を持つサーバーコンピュータのようにしても良い。このように、各機能を実現するために、どのサーバーコンピュータに機能を実現するかについて制限はない。

また、本発明の各実施例では、ユーザーからの処理依頼を画像形成装置１０４のデバイスブラウザから行った。しかし、クライアントコンピュータ１０５のデバイスブラウザから処理依頼を送っても良い。この場合、クライアントコンピュータ１０５は、画像形成装置１０４を指定する形態が考えられる。クライアントコンピュータ１０５は、画像形成装置１０４に対し、要求受信部４０１１にポーリングするように指示を行う。

また、本発明の各実施例では、インスタンス数を増減する際に、インスタンスを１つずつ増減させた。しかし、１つずつではなく複数個ずつインスタンス数を増減させても良い（例えば、１回の処理で２個ずつ増やし、１回の処理で３個ずつ減らす）。

また、本発明の各実施例では、図５のキューメッセージで示されている５０８を利用しなかった。しかし、これを利用した方法も考えられる。この場合、処理確認テーブルは不要になる。要求受信部４０１１は、キューメッセージを作成する際に、バックエンド処理部４０２１が処理した結果を格納する場所を指定する。バックエンド処理部４０２１は、キューメッセージを確認して、処理した結果を指定された場所へ保存することになる。

また、本発明の各実施例では、１つのヴァーチャルマシンに対し、要求受信部４０１１、バックエンド処理部４０２１は夫々１つずつ割り当てられていた。しかし、１つのヴァーチャルマシンに対し、要求受信部４０１１、バックエンド処理部４０２１は複数存在していても良い。例えば、ヴァーチャルマシン４０７に要求受信部４０１１が２つ存在している状態である。

１０２ サーバーコンピュータ群
１０６２ ＣＰＵ
１０６３ 直接記憶部
１０６４ 間接記憶部
４０１１ 要求受信部
４０２１ バックエンド処理部
４０５ キューサービス
４０６ ストレージ

Claims (7)

1. 情報処理システムであって、
   ネットワークを介して外部装置から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段と、
   前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューに格納されている前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行うバックエンド処理手段と、
   前記キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御手段と、を有し、前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする情報処理システム。
2. 前記制御手段は、前記キューに格納されているキューメッセージの数を確認し、前記キューに格納されているキューメッセージの数が規定値以下であると確認された場合に前記バックエンド処理手段の数が減少するように制御することを特徴とする請求項１に記載の情報処理システム。
3. 前記キューサービスは、前記バックエンド処理手段が前記キューに格納されている前記キューメッセージを取得したことに応じて、取得された前記キューメッセージが前記バックエンド処理手段とは異なる別のバックエンド処理手段により取得されないように前記キューメッセージを不可視状態にし、取得された前記キューメッセージが前記バックエンド処理手段により処理されたことが確認されたことに応じて、前記キューメッセージを前記キューから削除することを特徴とする請求項１または２に記載の情報処理システム。
4. ユーザーからの指示を受け付ける外部装置と、情報処理システムと、を含むシステムであって、
   ユーザーからの指示を受け付けたことに応じて処理要求を送信する送信手段と、
   ネットワークを介して前記送信手段から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理手段と、
   前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行うバックエンド処理手段と、
   前記キューサービスに格納されているキューメッセージの数を確認し、前記キューサービスに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御手段と、を有し、前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする情報処理システム。
5. 情報処理システムを制御する制御方法であって、
   要求処理手段は、ネットワークを介して外部から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示し、
   バックエンド処理手段は、前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行い、
   制御手段は、前記キューサービスに記憶されているキューメッセージの数を確認し、前記キューサービスに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御し、
   更に、前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする制御方法。
6. 情報処理システムに制御方法を実行させるためのプログラムであって、
   仮想サーバにて実現される要求処理手段が、ネットワークを介して外部から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示する要求処理ステップと、
   前記仮想サーバとは異なる仮想サーバにて実現されるバックエンド処理手段が、前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューメッセージを取得したことに応じて、取得して前記キューメッセージに基づく処理を行うバックエンド処理ステップと、
   制御手段が、前記キューサービスに記憶されているキューメッセージの数を確認し、前記キューサービスに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御する制御ステップと、を含むことを特徴とするプログラム。
7. ユーザーからの指示を受け付ける外部装置と、情報処理システムと、を含むシステムにより実行される制御方法であって、
   送信手段は、ユーザーからの指示を受け付けたことに応じて処理要求を送信し、
   要求処理手段は、ネットワークを介して前記送信手段から処理要求を受信し、受信した処理要求に対応するキューメッセージをキューに格納するようキューサービスへ指示し、
   バックエンド処理手段は、前記キューサービスに対し前記キューメッセージの取得要求を定期的に行い、前記キューメッセージを取得したことに応じて、取得した前記キューメッセージに基づく処理を行い、
   制御手段は、前記キューサービスに格納されているキューメッセージの数を確認し、前記キューサービスに格納されているキューメッセージの数が規定値以上であると確認された場合に前記バックエンド処理手段の数が増加するように制御し、
   更に、前記要求処理手段および前記バックエンド処理手段は夫々異なる仮想サーバにて実現される機能であることを特徴とする制御方法。

Images