クラウドコンピューティングシステム、その制御方法、およびそのプログラム
【課題】画像形成装置のファームウェア配信前に、ユーザーのデータや機器の設定を反映した形で機能テスト及びパフォーマンステストをできるようにする。
【解決手段】クラウドコンピューティングシステムは、ファームウェアの配信を受けようとする画像形成装置の各種パラメータ（ＣＰＵ、メモリー、ストレージ、アプリケーション種類、ユーザー情報、ユーザー設定）を受信する（５０１）と仮想マシンを起動し（５０５）、受信したパラメータに応じた仮想デバイスを自動的に用意し、仮想ＭＦＰ上でファームウェアの機能テスト（５１０）及びパフォーマンステスト（５１２）を実行し、問題があればエラーメッセージを作成し（５１６）、問題がなければファームウェアを画像形成装置にダウンロードする（５１９）。
【解決手段】クラウドコンピューティングシステムは、ファームウェアの配信を受けようとする画像形成装置の各種パラメータ（ＣＰＵ、メモリー、ストレージ、アプリケーション種類、ユーザー情報、ユーザー設定）を受信する（５０１）と仮想マシンを起動し（５０５）、受信したパラメータに応じた仮想デバイスを自動的に用意し、仮想ＭＦＰ上でファームウェアの機能テスト（５１０）及びパフォーマンステスト（５１２）を実行し、問題があればエラーメッセージを作成し（５１６）、問題がなければファームウェアを画像形成装置にダウンロードする（５１９）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンを有するクラウドコンピューティングシステム、その制御方法、およびそのプログラムに関する。
【背景技術】
【０００２】
従来のソフトウェア、ファームウェア配信管理システムには、ネットワークを介して複数の非汎用コンピュータデバイスのソフトウェア機能を動的に管理する方法がある。（例えば、特許文献１参照）
特許文献１には、非汎用コンピュータデバイスの夫々から状態表示を受信し、修正パッケージの送信を遅延させることが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１２３５１８（Ｐ２００８−１２３５１８Ａ） 株式会社リコー
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし従来のソフトウェア、ファームウェア配信管理システムでは、ファームウェア配信前に事前にユーザーのデータや、機器の設定を反映した形で機能テスト、パフォーマンステストをするような機能はなかった。
基本的に、ファームウェア、およびファーム上で動作するアプリケーションなど、デバイス上で動作するソフトウェアはメーカーにより動作保障が行われる。ＰＣなどの高度に互換性を保障されたデバイス群や、ゲーム機、スマートフォンなどプラットフォームが固定されたデバイスについては事前のテストによる保障などは有効と考えられる。しかし一般に、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）などプラットフォームの設計が比較的変わる可能性のあるデバイスにおいては、過去機種の設定において現行機種全てが動作することを保障するのは困難な場合がある。そのような場合、クラウド上にさまざまな機種の仮想環境を用意して事前にテストできるようにすると、実機買い替え前、ファームウェア配信前に動作保障、パフォーマンス検証が可能となる。
【０００５】
（例１）ずっと以前の機種から最新の廉価版機種に乗り換える場合、システムリソースの問題から同時起動できるアプリの件数が減ってしまっていた
（例２）障害対策の新ファームをリリースしたが、顧客の特殊なアプリ（開発、品保で事前入手が困難）が動作しなくなってしまった。
【０００６】
また、ユーザーが既存ＭＦＰを新機種に置き換える場合、同じ機能を持つ新機種でも、システムリソース（ＣＰＵ、メモリー、ストレージ、ＯＳ設定（スレッド数など））の異なる場合がある。そのとき、置き換えた新機種上でのファームウェア機能のパフォーマンスや、ＭＦＰ上で動作するアプリケーションのパフォーマンス、動作を予め検証できない、という課題がある。
【課題を解決するための手段】
【０００７】
本発明の一実施系に係るクラウドコンピューティングシステムは、画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信手段と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示する、バックエンド処理プログラムを実行することにより実現される指示手段と、前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現する、バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段と、を有し、前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせないためにエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とする。
【発明の効果】
【０００８】
新ファームウェアは、一連のバックエンド処理により実際のユーザーデータ、設定を使ったテストで正常動作が確認され、ユーザーデータが既にインポートされた状態となっている。したがって、前記画像形成装置１０４に前記新ファームウェアがインストールされると、ユーザーデータやデバイス設定がファームウェア更新以前と同様にされた状態でシステムを起動することができる。また、事前に前記サーバーコンピューター群１０２上で機能テストをしているので、ファームウェアアップデートに伴う機能エラー等を防止することができる。また、事前に前記サーバーコンピューター群１０２上でパフォーマンステストをおこなっているので、旧ファームウェアとの処理速度の比較ができることも特徴である。
【図面の簡単な説明】
【０００９】
【図１】全体構成を示す図である
【図２】画像形成装置の内部構成を示す図である
【図３】情報処理装置の内部構成を示す図である
【図４】サーバーコンピューター群のプラットフォームシステムを示す図である
【図５】バックエンド処理部における処理を示すフローチャートである
【図６】ファームウェアアップデート処理を示したフローチャートである
【図７】要求受信部のリクエスト受付処理を示すフローチャートである
【図８】画像形成装置のリクエスト内容の一部である
【図９】リクエスト処理部が作成したキューメッセージ内容である
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１１】
［全体構成］
実施例１のプリントシステムを構成している各装置について、図１を参照して詳細に説明する。図１には、プリントシステムを構成している各装置がネットワーク１００を介して接続されている様子が示されている。プリントシステムを構成している各装置とは、サーバーコンピュータ群１０２、文書サーバー１０３、画像形成装置１０４、クライアントコンピュータ１０５である。サーバーコンピュータ群１０２は、クラウドコンピューティングシステムに相当する。
【００１２】
ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバーコンピュータ群１０２と文書サーバー１０３が属するネットワーク１００と、画像形成装置１０４とクライアントコンピュータ１０５が属するネットワーク１００とは、ファイアウォールを越えて通信が可能である。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。実施例１の図１において、サーバーコンピュータ群１０２は、１台のサーバーとして示されているが複数台のサーバーコンピュータで構成されている。
【００１３】
［画像形成装置の説明］
次に、図１のプリントシステムを構成している各装置の内部構成について詳細に説明する。始めに、画像形成装置１０４の内部構成について図２を用いて説明する。図２は、画像形成装置１０４の内部構成を例示するブロック図である。
画像形成装置１０４は、画像処理ユニット１０４１、および印刷ユニット１０４２から構成される。画像処理ユニット１０４１は、ＣＰＵ１０４３、直接記憶部１０４４、間接記憶部１０４５、ユーザーインターフェース１０４７、外部インターフェース１０４８から構成されている。
【００１４】
ＣＰＵ１０４３は、所定のプログラムを実行し、画像処理装置１０４の各種制御を指示するユニットである。ＣＰＵ１０４３は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）により実現される。直接記憶部１０４４は、ＣＰＵ１０４３がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０４３が実行するプログラムは直接記憶部１０４４にロードされる。直接記憶部１０４４は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部１０４５は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。また関節記憶部１０４５にはデバイスの設定やアプリケーションの設定、後述するプラットフォームアプリケーションの設定等が組み込みデータベースのストレージファイルとして保存されている。間接記憶部１０４５に記憶されている各種プログラムは、ＣＰＵ１０４３がプログラムを実行する際に直接記憶部１０４４へ移動する。間接記憶部１０４５は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ１０４３はマルチプロセッサでも良い。
【００１５】
ここで、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０２上で実行できる他、画像形成装置１０２の操作画面をカスタマイズすることが可能になる。
プラットフォームの実現方法について説明する。ＣＰＵ１０４３は、間接記憶部１０４５に記憶されたプラットフォームプログラムを直接記憶部１０４４に移動する。移動が完了するとＣＰＵ１０４３は、プラットフォームプログラムを実行することができる状態になる。本発明の実施例１では、ＣＰＵ１０４３がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００１６】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例１において、プラットフォーム上には、印刷要求を受け付ける印刷ソフトウェアが動作している。印刷ソフトウェアは、ネットワークを介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と言った通信プロトコルによって印刷データを受信できる。印刷ソフトウェアは、受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは印刷データ処理を開始する。なお、印刷データが処理をせずに印刷できるようなものであれば、ファームウェアは印刷データ処理を省く。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。例えば、スキャナユニットを制御する他、プリントユニットを制御することが可能になる。
【００１７】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部１０４５に記憶されたアプリケーションプログラムを直接記憶部１０４４に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例１ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例１で開示するフローチャートの各処理の一部を行うことが可能である。
【００１８】
ユーザーインターフェース１０４７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース１０４８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０２は、ネットワーク１００、およびインターネット１０１を介して、クライアントコンピュータ１０５、サーバーコンピュータ群１０２等と通信可能である。
２番目に、サーバーコンピュータ群１０２、文書サーバー１０３、クライアントコンピュータ１０５を含む情報処理装置の内部構成について図３を用いて説明する。図３は、情報処理装置１０６の内部構成を例示するブロック図である。情報処理装置１０６は、ユーザーインターフェース１０６１、ＣＰＵ１０６２、直接記憶部１０６３、間接記憶部１０６４、外部インターフェース１０６５から構成されている。
ユーザーインターフェース１０６１は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。
ＣＰＵ１０６２は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示するユニットである。ＣＰＵ１０６２は、ＣＰＵにより実現される。直接記憶部１０６３は、ＣＰＵ１０６２がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０６２が実行するプログラムは直接記憶部１０６３にロードされる。直接記憶部１０６３は、ＲＡＭで構成されている。間接記憶部１０６４は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部１０６４に記憶されている各種プログラムは、ＣＰＵ１０６２がプログラムを実行する際に直接記憶部１０６３へ移動する。間接記憶部１０６４は、ＲＯＭ、または、ＨＤＤで構成されている。外部インターフェース１０６５は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。
【００１９】
［仮想マシンの説明］
次に、サーバーコンピュータ群１０２のプラットフォームシステムについて図４を参照しながら詳細に説明する。図４は、サーバーコンピュータ群１０２内の各種機能を示した図である。図４において、サーバーコンピュータ群１０２内にある物理ハードウェア・リソースは、サーバーコンピュータ群１０２のプラットフォームに使用される。サーバーコンピュータ群１０２のプラットフォーム利用者は、このサーバーコンピュータ群１０２内にある物理ハードウェア・リソースをコンピューティング・リソースとして使用できる。
サーバーコンピュータ群１０２のプラットフォームシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、次のような機能を持つ。仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ）４０１、および４０２。ファブリックコントローラ（Ｆａｂｒｉｃ Ｃｏｎｔｒｏｌｌｅｒ）４０３。ロードバランサー（Ｌｏａｄ Ｂａｌａｎｃｅｒ）４０４。キューサービス（Ｑｕｅｕｅ）４０５。ストレージ（Ｓｔｏｒａｇｅ）４０６。管理仮想マシン４０７である。
サーバーコンピュータ群１０２上で動作するプラットフォームシステムの内部には、仮想マシン４０１、４０２が複数存在する。仮想マシンとは、仮想化技術によって物理的なサーバーコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本発明の実施例１では、インスタンス数１つに対し、サーバーコンピュータ群１０２内の１台のサーバーコンピュータ上で動作する。
【００２０】
仮想マシン４０１は、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０１１、要求受信部エージェント（Ａｇｅｎｔ）４０１２で構成される。要求受信部４０１１は、後述するロードバランサ−４０４を介してユーザーからの処理依頼を受信する。また、要求受信部４０１１は、キューサービス４０５を介してバックエンド処理部４０２への処理依頼を送信する。
要求受信部４０１１の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、仮想マシン４０１の外部にあるロードバランサー４０４を通じて行われる。ロードバランサー４０４は、外部ネットワークからの要求を一元的に管理し、同等な要求受信部の機能を有する複数の仮想マシンに対し、選択的に要求を転送するものである。要求受信部エージェント４０１２は、仮想マシン４０１の使用状況、要求受信部４０１１の稼動状態、仮想マシン４０１のリソースの使用状況、および要求受信部４０１１のエラーを含む各種情報を収集し、ファブリックコントローラ４０３に定期的に送信する。
要求受信部４０１１、バックエンド処理部４０２１の各インスタンスは、ファブリックコントローラ４０３によって管理されている。そのため、各インスタンスの拡張性と可用性が保証される。例えば、要求受信部４０１１、またはバックエンド処理部４０２１において、ある特定のインスタンスがサーバーの故障によって停止したとする。この場合、ファブリックコントローラ４０３は、要求受信部エージェント４０１２、またはバックエンド処理部エージェント４０２２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ４０３は、新しいインスタンスに処理が委譲されるように仮想マシンに指示を出す。結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。
【００２１】
仮想マシン４０２は、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０２１、バックエンド処理部エージェント（Ａｇｅｎｔ）４０２２で構成される。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１からの処理依頼を受信する。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１から受信した処理依頼を実行する。また、バックエンド処理部４０２１は、スケールアウトする。スケールアウトとは、仮想マシン４０２が増加し、バックエンド処理部４０２１のインスタンスが増加すること指す。バックエンド処理部４０２１のインスタンスが増加すると、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザーからの処理依頼に対する結果をより早く返すことができる。なお、要求受信部４０１１は仮想マシンが要求受信プログラムを実行することで実現され、バックエンド処理プログラムは仮想マシンがバックエンド処理プログラムを実行することで実現可能となる。
キューサービス４０５は、要求受信部４０１１とバックエンド処理部４０２１とが非同期でデータ通信するためのサービスを提供する。要求受信部４０１１、およびバックエンド処理部４０２１は、キューサービス４０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。要求受信部４０１１がキューサービス４０５に対して行う指示とは、キューメッセージの追加指示である。バックエンド処理部４０２１がキューサービス４０５に対して行う指示とは、キューメッセージの取得指示、キューメッセージの削除指示である。
【００２２】
要求受信部４０１１とバックエンド処理部４０２１が非同期でデータ通信する一連の動作について説明する。要求受信部４０１１は、ユーザーからの処理依頼に応じたキューメッセージを作成し、キューメッセージをキューに追加するようにキューサービス４０５に追加指示を送信する。追加指示を受信したキューサービス４０５は、キューにキューメッセージを追加する。バックエンド処理部４０２１は、キューメッセージを取得するために、キューサービス４０５に取得指示を出す。取得指示を受けたキューサービス４０５は、キューメッセージと、キューメッセージ毎に固有に割り振られたメッセージＩＤと、受取ＩＤとを取得指示に対するレスポンスとしてバックエンド処理部４０２１に返す。メッセージＩＤとは、キューメッセージを一意に定めるためにキューメッセージごとに割り振られた固有の情報である。受取ＩＤは、処理が終了したバックエンド処理部４０２１がキューメッセージを削除指示する際に使用する。キューメッセージと、メッセージＩＤと、受取ＩＤは、関連付けされて保存されることになる。バックエンド処理部４０２１は、処理依頼を完了すると、受取ＩＤに対応するキューメッセージの削除指示をキューサービス４０５に対して行う。削除指示を受けたキューサービス４０５は、バックエンド処理部４０２１が指示した受取ＩＤに対応するキューメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部４０２１以外のバックエンド処理部４０２１が同じキューメッセージを処理するという冗長な処理を防ぐことができる。
【００２３】
また、キューサービス４０５は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。不可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求をした場合に、キューサービス４０５はバックエンド処理部４０２１に対してキューメッセージを渡さないことを指す。バックエンド処理部４０２１がキューからキューメッセージを取得すると、取得されたキューメッセージはキューサービス４０５によって不可視になる。可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求した場合に、キューサービス４０５がバックエンド処理部４０２１に対してキューメッセージを渡すことを指す。バックエンド処理部４０２１に取得され不可視になっているキューメッセージは、処理を行っているバックエンド処理部４０２１から処理結果が一定時間返ってこない場合にキューサービス４０５によって可視になる。
【００２４】
ストレージサービス４０６は、データ保存に利用されるストレージを提供する。バイナリデータの集合を保存する機能を提供する。また、後述する処理確認テーブル、およびキュー管理テーブルを保持する機能も提供する。
仮想マシン４０７は、要求受信部４０１１、要求受信部エージェント４０１２で構成される。仮想マシン４０１との違いは、管理ユーザーのみが利用できる要求受信部４０１１のインスタンスを持つ仮想マシンということである。この仮想マシンの要求受信部４０１１により管理ユーザーは、キュー管理テーブルを操作することができる。
【００２５】
本実施例においては、前記仮想マシン４０２に画像形成装置１０４のメインコントローラーと同等の状況を実現させる。画像形成装置１０４には処理能力、機能の違いに応じて様々なタイプがある。サーバーコンピュータ群１０２においては、バックエンド処理部４０２１が前記キューサービス４０５を経由して前記画像形成装置１０４からの要求を受け付ける。前記バックエンド処理部４０２１は、後述するパラメータに沿って前記画像形成装置１０４の処理能力、機能に応じ、前記複数タイプの仮想マシン４０２のイメージから最適なものを選択し、新たなファームウェアが実行される画像形成装置１０４を擬態した仮想マシン４０２の実態を生成する（後述）。
【００２６】
［要求受信部処理］
図７は、本実施例の仮想マシン４０１における、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０１１の、リクエスト受付処理を示したフローチャートである。要求受信部４０１１が、画像形成装置１０４からのリクエストを受信することから本フローチャートは開始する（ステップ７０１）。画像形成装置のリクエストを、図８に示す。図８は画像形成装置１０４のリクエスト内容の一部である。リクエストは画像形成装置１０４がＨＴＴＰプロトコルで送信し、要求受信部４０１１が受け取る。本リクエストは、図８のデバイスに関する情報のＸＭＬ文書と、前記画像形成装置１０４の各種ユーザーデータを含む組込みデータベースをエクスポートしたバイナリデータを圧縮した部分と、前記画像形成装置にインストールされたプラットフォームアプリケーション群から成る。
【００２７】
デバイスに関する情報は画像形成装置１０４を表す＜ｄｅｖｉｃｅ＞要素の子要素として、機種名を示す＜ｎａｍｅ＞要素、インストールされているファームウェアのバージョンを示す＜ｆｉｒｍｖｅｒ＞要素、デバイスシリアル番号を示す＜ｓｅｒｉａｌｎｏ＞要素を含む。また前記画像形成装置１０４のハードウェア情報、即ちリソース情報を表す＜ｈａｒｄｗａｒｅ−ｉｎｆｏ＞要素の子要素として、＜ｃｐｕ＞要素、＜ｍｅｍｏｒｙ＞要素、＜ｓｔｏｒａｇｅ＞要素がある。
前記＜ｃｐｕ＞要素は画像形成装置１０４のＣＰＵ１０４３の属性を表す。前記＜ｃｐｕ＞要素には子要素として、該ＣＰＵ１０４３のコア数を示す＜ｖｃｐｕ＞要素と、該ＣＰＵ１０４３のアーキテクチャを示す＜ｔｙｐｅ＞要素と、該ＣＰＵ１０４３のクロックをＭＨｚで示す＜ｃｌｏｃｋ＞要素がある。前記＜ｍｅｍｏｒｙ＞要素は前記画像形成装置１０４のメインコントローラーボードに搭載された直接記憶部１０４４のメモリ容量をメガバイト単位で表す。前記＜ｓｔｏｒａｇｅ＞要素は前記画像形成装置１０４のメインコントローラーボードに搭載された間接記憶部１０４５であるＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）の容量をギガバイト単位で表す。
【００２８】
また図８の＜ａｐｐｌｉｃａｔｉｏｎｓ＞要素は、ファームウェアとは別に画像形成装置１０４に後からインストールしたプラットフォームアプリケーション群を示す、プラットフォームに関する情報である。前記＜ａｐｐｌｉｃａｔｉｏｎｓ＞要素の子要素として、インストールされたプラットフォームアプリケーションの各々を示す＜ａｐｐｌｉｃａｔｉｏｎ＞要素がある。前記＜ａｐｐｌｉｃａｔｉｏｎ＞要素には、子要素としてプラットフォームアプリケーション名を示す＜ｎａｍｅ＞要素と、該プラットフォームアプリケーションの識別子を示す
＜ｕｕｉｄ＞要素と、該プラットフォームアプリケーションのバージョンを示す＜ｖｅｒｓｉｏｎ＞要素がある。
本実施例図８の場合、Ａｐｐｌｉｃａｔｉｏｎ＿Ａ（バージョン１．０．０）、Ａｐｐｌｉｃａｔｉｏｎ＿Ｃ（バージョン２．０．１）、Ａｐｐｌｉｃａｔｉｏｎ＿Ｆ（バージョン１．７．２）の３つのプラットフォームアプリケーションがインストールされていることを示す。
図８に示されるリクエストを受信した（ステップ７０１）要求受信部４０１１は、次に、リクエストに含まれるユーザーデータをストレージサービス４０６に格納する（ステップ７０２）。格納先は、要求受信部４０１１が前記リクエストに含まれるデバイスデータからデバイス名とデバイスシリアル番号を読み取り、以下のように／ｖａｒ／ｄａｔａ の下のデバイス名、デバイスシリアル番号の下となる。
【００２９】
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／ｕｓｅｒ．ｄｂ
図８に示されるリクエストを受信した（ステップ７０１）要求受信部４０１１は、次に、リクエストにバイナリを添付した形で含まれるプラットフォームアプリケーションをストレージサービス４０６に格納する（ステップ７０３）。格納先は、要求受信部４０１１が前記リクエストに含まれるデバイスデータからデバイス名とデバイスシリアル番号を読み取り、以下のように／ｖａｒ／ｄａｔａ の下のデバイス名、デバイスシリアル番号の下となる。
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ａ
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ｃ
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ｆ
要求受信部４０１１は次に、キューサービス４０５の参照を取得し（ステップ７０４）、キューメッセージを作成する（ステップ７０５）。該キューメッセージは図９のように作成される。
【００３０】
図９は、要求受信部４０１１が該リクエストを受信し作成したキューメッセージである。図８に示した画像形成装置１０４のリクエスト内容に、各＜ａｐｐｌｉｃａｔｉｏｎ＞要素の子要素として、前記ストレージサービス４０６にプラットフォームアプリケーションを格納した際の格納先パスである＜ｐａｔｈ＞要素を加える。また、前記ユーザーデータを表す＜ｕｓｅｒｄａｔａ＞要素を加える。＜ｕｓｅｒｄａｔａ＞要素の子要素には前記ストレージサービス４０６に格納した際の格納先パスである＜ｐａｔｈ＞要素が含まれる。要求受信部４０１１は、上記キューメッセージを作成すると、前記キューサービス４０５に前記キューメッセージを挿入し（ステップ７０６）、処理を終える。
【００３１】
［バックエンド処理］
図５は、本実施例の前記バックエンド処理部４０２１における処理を示したフローチャートである。
前記バックエンド処理部４０２１は、前記キューサービス４０５から前記画像形成装置１０４のリクエストを受け付ける（ステップ５０１）。本リクエストは図９に示したキューメッセージから成る。バックエンド処理部４０２１は受信した前記リクエストを解析し、ＸＭＬ文書の要素で示された各パラメーターが後述する仮想マシンのインストールイメージと合致するかどうか確認する。また、バックエンド処理部４０２１は、ユーザーデータがストレージサービス４０６の指定のパスに格納されているかどうか確認する（ステップ５０２）。
【００３２】
もし受信した前記キューメッセージ（図９）が後述する仮想マシンに合致しない、あるいはユーザーデータがストレージサービス４０６の指定のパスに存在しないのであれば（ステップ５０３）、リクエストパラメーター異常、あるいはユーザーデータ異常のエラーメッセージを作成し（ステップ５１６）、メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。もしキューメッセージに問題がなければ（ステップ５０３）、該キューメッセージから＜ｈａｒｄｗａｒｅ−ｉｎｆｏ＞要素以下の子要素の各々を取り出し（ステップ５０４）、仮想マシンを作成、実態生成する（ステップ５０５）。この仮想マシンは、画像形成装置１０４のリソース状況、および画像形成装置のプラットフォームに関連する状況を再現する。
【００３３】
［仮想マシンイメージの作成、実態生成］
本実施例においては、仮想マシン４０２の制御にオープンソースの仮想マシン制御 ＡＰＩを用いる。仮想マシン制御 ＡＰＩは仮想マシンの制御を抽象化したライブラリで、Ｘｅｎ、ＫＶＭ、ＱＥＭＵなどの仮想マシンをサポートしている。またＣＰＵとしてｘ８６、ｘ８６?６４、ＩＡ６４、Ｐｏｗｅｒなどをサポートしており、ビット（３２／６４）およびエンディアンを問わない、事実上の標準となっているＡＰＩである。
本実施例の場合、仮想マシンイメージは、画像形成装置１０４の種類に応じて以下の３種類である。もちろん本仮想マシンイメージは、サーバーコンピュータ群の能力と、画像形成装置１０４の他のタイプに応じてパラメータを変更することによりさらに多くのパターンを作り出すことができる。
【００３４】
インストールイメージ（１）
割当てるＣＰＵ数：１
メモリサイズ：５１２ＭＢ
ディスクサイズ：４ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖｅｒｓｉｏｎ／ＸＸ３０００．ｉｍｇ
仮想マシン名：ＸＸ３０００
インストールイメージ（２）
割当てるＣＰＵ数：２
メモリサイズ：１ＧＢ
ディスクサイズ：２０ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ４０００／Ｖｅｒｓｉｏｎ／ＸＸ４０００．ｉｍｇ
仮想マシン名：ＸＸ４０００
インストールイメージ（３）
割当てるＣＰＵ数：４
メモリサイズ：２ＧＢ
ディスクサイズ：８０ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ５０００／Ｖｅｒｓｉｏｎ／ＸＸ５０００．ｉｍｇ
仮想マシン名：ＸＸ５０００
各々のディスクパスに収められるイメージは、以下のように作成する。各機種（本実施例の場合上記１，２，３）向け新ファームウェアがリリースされると、ストレージサービス４０６の所定のパスにアップロードされる。例えば（１）の場合でファームウェアバージョン１．１．２がリリースされた場合、以下パスにファームウェア一式のインストールイメージがアップロードされる。
【００３５】
／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＸＸ３０００．ｉｍｇ
上記インストールイメージは、オペレーティングシステム、各種ライブラリ、各種アプリケーションモジュールをファームウェアとして構成し、ｄｄ コマンド等で起動可能イメージを作成したものである。前記インストールイメージは、ｌｉｂｖｉｒｔ ＡＰＩを実装したコマンドより次のように起動され、仮想マシンの実態が生成される。以下は前記インストールイメージ（１）を起動する場合のコマンド例である。
【００３６】
ｖｉｒｔ−ｉｎｓｔａｌｌ −−ａｃｃｅｌｅｒａｔｅ −−ｈｖｍ −−ｃｏｎｎｅｃｔ ｑｅｍｕ：／／／ｓｙｓｔｅｍ −−ｎｅｔｗｏｒｋ
ｎｅｔｗｏｒｋ：ｄｅｆａｕｌｔ −−ｎａｍｅ ＸＸ３０００ −−ｒａｍ＝５１２ −−ｏｓ−ｔｙｐｅ＝Ｌｉｎｕｘ
−−ｏｓ−ｖａｒｉａｎｔ＝ｕｎｉｘ −−ｆｉｌｅ＝／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＸＸ３０００．ｉｍｇ
−−ｆｉｌｅ−ｓｉｚｅ＝４
バックエンド処理部４０２１は、画像形成装置１０４からのリクエストを受信し、リクエスト内容（後述）に応じて上記コマンドを実行し、新たな仮想マシン４０２を生成する（ステップ５０５）。もし前記仮想マシン４０２が正常に起動しなかったら（ステップ５０６）、仮想マシン起動失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
【００３７】
前記仮想マシン４０２が正常に起動したら（ステップ５０６）、次にバックエンド処理部４０２１は、ステップ５０４にて前記キューメッセージから取り出した＜ｕｓｅｒｄａｔａ＞要素の子要素である＜ｐａｔｈ＞要素に指定されたストレージサービス４０６のディレクトリ下にあるユーザーデータのデータベースファイルを、前記仮想マシン４０２にインポートする（ステップ５０７）。本実施例の場合、組み込みデータベース（ＳＱＬｉｔｅ）の ．ｉｍｐｏｒｔ コマンドを用いてデータベースをインポートする。
【００３８】
もし前記仮想マシン４０２へのデータベースのインポートに失敗したら、（ステップ５０９）、ユーザーデータインポート失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
もし前記仮想マシン４０２へのデータベースのインポートに成功したら、（ステップ５０９）、次にバックエンド処理部４０２１は、ステップ５０４にて前記キューメッセージから取り出した＜ａｐｐｌｉｃａｔｉｏｎ＞要素の子要素である＜ｐａｔｈ＞要素に指定されたストレージサービス４０６のディレクトリ下にあるプラットフォームアプリケーションを、前記仮想マシン４０２にインストールする（ステップ５１７）。本実施例の場合、前記仮想マシン４０２のアプリケーションディレクトリへの、前記プラットフォームアプリケーションのコピーによりインストールを行う。
もし前記仮想マシン４０２へのプラットフォームアプリケーションのインストールに失敗したら、（ステップ５０９）、プラットフォームアプリケーションインストール失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
もし前記仮想マシン４０２へのプラットフォームアプリケーションのインストールに成功したら、前記仮想マシン４０２は、新ファームウェアにユーザーデータをインポートし、プラットフォームアプリケーションをインストールした状態となる。これは前記リクエスト元の画像形成装置１０４に新ファームウェアをインストールし、ユーザーデータをインポートしてプラットフォームアプリケーションをインストールした状態を、サーバー上に仮想的に作り上げた状態である。この状態で、次に前記仮想マシン４０２は、本仮想マシン４０２の機能テストを行う（ステップ５１０）。
【００３９】
機能テストは、次のように行う。本実施例の画像形成装置１０４におけるファームウェアは、ｓｙｓｌｏｇ ライブラリによるログ出力を行う。ファームウェアの各ライブラリ、アプリケーションは、ｓｙｓｌｏｇ の ｉｎｆｏ レベルで各関数の呼び出し開始、終了を出力する。通常、画像形成装置１０４上で実行するファームウェアのログ出力レベルは、ログ出力量、パフォーマンスを考慮してｗａｒｎレベルまでの出力となる。
【００４０】
しかし前記仮想マシン４０２の機能テストを行う場合、バックエンド処理部４０２１は、ｓｙｓｌｏｇｄ のログ出力レベルプライオリティを ｄｅｂｕｇ レベルまで出力するように設定してテストを行う。ここで前記仮想マシン４０２のファームウェアをテストすると、ｉｎｆｏレベルのログが出力され、関数レベルでの動作を確認することができる。テスト項目は、ファームウェア開発時の各種結合テストを行う。例えばＰＤＦファイル生成機能の場合、本機能テストは、ストレージサービス４０６に予め用意されたスキャンデータを、前記仮想マシン４０２のＰＤＦ生成機能関数に入力し、ログをログ出力ファイルに記録する。
【００４１】
ここでバックエンド処理部４０２１がログ出力ファイルを確認し、もしｓｙｓｌｏｇ 出力にエラーや例外が出力されていたら、機能テスト失敗のエラーメッセージを作成し、メッセージを前記画像形成装置１０４に送信し（ステップ５１５）処理を終える。ここでバックエンド処理部４０２１が前記ログ出力ファイルを確認し、もしｓｙｓｌｏｇ 出力にエラーや例外が出力されていなければ（ステップ５１１）、次にパフォーマンステストを行う（ステップ５１２）。
【００４２】
パフォーマンステストは、次のように行う。バックエンド処理部４０２１は、受信した前記キューメッセージ（図９）に含まれる＜ｄｅｖｉｃｅ＞要素の子要素である＜ｆｉｒｍｖｅｒ＞要素から、画像形成装置１０４のファームウェアバージョンを取得する。そしてそのファームウェアバージョンから、過去のファームウェアインストールイメージを検索して、ファームウェアアップデート前の画像形成装置１０４に相当する仮想マシン４０２を生成する。
【００４３】
過去のファームウェアも、新規ファームウェア同様に、ストレージサービス４０６の所定のパスにアップロードされている。本実施例の場合、以下パスにファームウェア一式のインストールイメージがアップロードされている。
／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．１／ＸＸ３０００．ｉｍｇ
上記インストールイメージは、オペレーティングシステム、各種ライブラリ、各種アプリケーションモジュールをファームウェアとして構成し、ｄｄ コマンド等で起動可能イメージを作成したものである。
前記インストールイメージは、ｌｉｂｖｉｒｔ ＡＰＩを実装したコマンドより次のように起動され、仮想マシンの実態が生成される。以下は前記インストールイメージを起動する場合のコマンド例である。
【００４４】
ｖｉｒｔ−ｉｎｓｔａｌｌ −−ａｃｃｅｌｅｒａｔｅ −−ｈｖｍ −−ｃｏｎｎｅｃｔ ｑｅｍｕ：／／／ｓｙｓｔｅｍ −−ｎｅｔｗｏｒｋ
ｎｅｔｗｏｒｋ：ｄｅｆａｕｌｔ −−ｎａｍｅ ＸＸ３０００ −−ｒａｍ＝５１２ −−ｏｓ−ｔｙｐｅ＝Ｌｉｎｕｘ
−−ｏｓ−ｖａｒｉａｎｔ＝ｕｎｉｘ −−ｆｉｌｅ＝／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．１／ＸＸ３０００．ｉｍｇ
−−ｆｉｌｅ−ｓｉｚｅ＝４
バックエンド処理部４０２１は上記コマンドを実行し、新たな仮想マシン４０２を生成する。ここでバックエンド処理部４０２１は、前記ステップ５０７、５１７、５１０と同様に、前記仮想マシン４０２に対してユーザーデータをインポートし、プラットフォームアプリケーションをインストールし、機能テストを行う。
【００４５】
上記機能テストが終了したら、新旧ファームウェアのｓｙｓｌｏｇ 出力を比較して相対的なパフォーマンスを評価する。例えばＰＤＦ生成機能の場合、バックエンド処理部４０２１は、新ファームウェア上のｓｙｓｌｏｇ出力から関数の開始時間から終了時間までを計算し、旧ファームウェア上のｓｙｓｌｏｇ 出力からも同様の計算を行なって、相対速度を計算する。
【００４６】
ここでもしパフォーマンステストの結果、ｓｙｓｌｏｇ 出力にエラーや例外が出力されていたら（ステップ５１３）、パフォーマンステスト失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
ここでもしパフォーマンステストの結果、ｓｙｓｌｏｇ 出力にエラーや例外が出力されていなければ（ステップ５１３）、バックエンド処理部４０２１は、次にテスト結果を作成する（ステップ５１４）。
【００４７】
この時点でバックエンド処理部４０２１は、新バージョンのファームウェアで動作する前記仮想マシンのｓｙｓｌｏｇｄ のログ出力レベルプライオリティを ｗａｒｎレベルに再設定する。通常、画像形成装置１０４上で実行するファームウェアのログ出力レベルは、ログ出力量、パフォーマンスを考慮してｗａｒｎレベルまでの出力である。バックエンド処理部４０２１はさらに、前記仮想マシンのイメージを ｄｄ コマンドで作成し、ストレージサービス４０６の、画像形成装置がアクセス可能なダウンロード可能ディレクトリにコピーする（ステップ５１９）。
本実施例の場合、上記ダウンロード可能ディレクトリにコピーされたファームウェアイメージは以下のようである。
【００４８】
／ｖａｒ／ｌｉｂ／ｄｏｗｎｌｏａｄａｂｌｅ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＡＡＡ１２３４５／ＸＸ３０００．ｉｍｇ
この後バックエンド処理部４０２１は、ステップ５１４で作成したメッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
【００４９】
［画像形成装置処理］
図６は、画像形成装置１０４のファームウェアアップデート処理を示したフローチャートである。本実施例で画像形成装置１０４のファームウェアアップデートがあった場合、前記サーバーコンピュータ群１０２の前記仮想マシン４０１の前記要求受信部４０１１に、アップデートした新規ファームウェア情報を掲載する。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、前記サーバーコンピュータ群１０２の前記ファームウェアアップデート情報を掲載する仮想マシン４０１の前記要求受信部４０１１を定期的に監視することで行う。
【００５０】
画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションがサーバーコンピュータ群１０２と通信し、ファームウェアアップデートを検知した場合にその情報を受信することで本フローチャートは開始する（ステップ６０１）。画像形成装置１０４において、ファームウェアアップデート用プラットフォームアプリケーションは、間接記憶部１０４５に記憶されたデバイスの設定やアプリケーションの設定、プラットフォームアプリケーションの設定等が組み込みデータベースのストレージファイルを取得する。また、デバイス情報取得手段により、デバイスのハードウェア情報を取得し、図８の画像形成装置１０４のファームウェアアップデートリクエスト内容のＸＭＬ文書を作成する（ステップ６０２）。ファームウェアアップデートプラットフォームアプリケーションは、データベースファイルとリクエスト内容のＸＭＬ文書を、サーバーコンピュータ群のファームウェアアップデート要求を受け付ける要求受信部４０１１に送信する（ステップ６０３）。
【００５１】
ここでもしデータベースファイルとリクエスト内容のＸＭＬ文書の送信に失敗したら（ステップ６０４）、ファームウェアアップデートプラットフォームアプリケーションは、送信失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでデータベースファイルとリクエスト内容のＸＭＬ文書の送信に成功した場合（ステップ６０４）、次の様な処理を行う。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、前記サーバーコンピュータ群１０２のバックエンド処理部４０２１からの機能パフォーマンステスト結果の通知を待ち受ける。前記通知の待ち受けは、前記画像形成装置１０４の前記ファームウェアアップデート用プラットフォームアプリケーションが前記サーバーコンピュータ群１０２の所定の仮想マシン４０１の要求受信部４０１１を定期的に監視することで行ってもよい。
【００５２】
前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションがステップ６０３、６０４にて前記画像形成装置１０４のファームウェアアップデート情報を送信した場合、次の様な処理を行う。図５のフローチャートで示したバックエンド処理のステップ５１５の処理完了、結果通知を待ち受け（ステップ６０５）、該メッセージを前記画像形成装置１０４に表示する（ステップ６０６）。
【００５３】
ここでもし前記図５のフローチャートで示したバックエンド処理のステップ５１５の処理が失敗であったら（ステップ６０７）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、ファームウェアアップデートテスト失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでもし前記図５のフローチャートで示したバックエンド処理のステップ５１５の処理が成功した場合（ステップ６０７）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、ストレージサービス４０６の、画像形成装置がアクセス可能なダウンロード可能ディレクトリにコピーされた新ファームウェアをダウンロードする（ステップ６０８）。
【００５４】
ここでもしステップ６０８の新ファームウェアダウンロードの処理が失敗したら（ステップ６０９）、次の様な処理を行う。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアダウンロード失敗のエラーメッセージを作成し、該メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）即ち、ファームウェアを画像形成装置１０４へ送信することなく処理を終える。
【００５５】
ここでもしステップ６０８の新ファームウェアダウンロードの処理が成功したら（ステップ６０９）、画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアをアップデートする（ステップ６１０）。ファームウェアアップデートは、前記ダウンロードした新ファームウェアをファームウェアアップデート用領域にコピーし、次回再起動時に新ファームウェアを展開して実行することにより実現する。
【００５６】
ここでもしステップ６１０の新ファームウェアアップデートの処理が失敗したら（ステップ６１１）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアダウンロード失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでもしステップ６１０の新ファームウェアアップデートの処理が成功したら（ステップ６１１）、画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは処理を終える。
【００５７】
新ファームウェアは、図５のフローチャートで示した一連のバックエンド処理により実際のユーザーデータ、設定を使ったテストで正常動作が確認され、ユーザーデータが既にインポートされた状態となっている。したがって、画像形成装置１０４に新ファームウェアがインストールされると、ユーザーデータやデバイス設定がファームウェア更新以前と同様にされた状態でシステムを起動することができる。
【００５８】
従来ファームウェアアップデート時に必要であった、ファームウェアインストール後の設定更新作業や、ユーザーデータの事前のエクスポート、ファーム更新事後のインポート作業などの処理を省くことができ、利便性を高めることができる。また事前にサーバーコンピュータ群１０２上で機能テストをしているので、ファームウェアアップデートに伴う機能エラー等を防止することができる。また事前に前記サーバーコンピュータ群１０２上でパフォーマンステストをおこなっているので、旧ファームウェアとの処理速度の比較ができることも特徴である。
【符号の説明】
【００５９】
１０２ 本実施例における、サーバーコンピュータ群である
１０４ 本実施例における、画像形成装置である
４０１ 本実施例における、要求受信部の仮想マシンである
４０１１ 本実施例における、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）である
４０２ 本実施例における、バックエンド処理部の仮想マシンである
４０２１ 本実施例における、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）である
【技術分野】
【０００１】
本発明は、仮想マシンを有するクラウドコンピューティングシステム、その制御方法、およびそのプログラムに関する。
【背景技術】
【０００２】
従来のソフトウェア、ファームウェア配信管理システムには、ネットワークを介して複数の非汎用コンピュータデバイスのソフトウェア機能を動的に管理する方法がある。（例えば、特許文献１参照）
特許文献１には、非汎用コンピュータデバイスの夫々から状態表示を受信し、修正パッケージの送信を遅延させることが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１２３５１８（Ｐ２００８−１２３５１８Ａ） 株式会社リコー
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし従来のソフトウェア、ファームウェア配信管理システムでは、ファームウェア配信前に事前にユーザーのデータや、機器の設定を反映した形で機能テスト、パフォーマンステストをするような機能はなかった。
基本的に、ファームウェア、およびファーム上で動作するアプリケーションなど、デバイス上で動作するソフトウェアはメーカーにより動作保障が行われる。ＰＣなどの高度に互換性を保障されたデバイス群や、ゲーム機、スマートフォンなどプラットフォームが固定されたデバイスについては事前のテストによる保障などは有効と考えられる。しかし一般に、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）などプラットフォームの設計が比較的変わる可能性のあるデバイスにおいては、過去機種の設定において現行機種全てが動作することを保障するのは困難な場合がある。そのような場合、クラウド上にさまざまな機種の仮想環境を用意して事前にテストできるようにすると、実機買い替え前、ファームウェア配信前に動作保障、パフォーマンス検証が可能となる。
【０００５】
（例１）ずっと以前の機種から最新の廉価版機種に乗り換える場合、システムリソースの問題から同時起動できるアプリの件数が減ってしまっていた
（例２）障害対策の新ファームをリリースしたが、顧客の特殊なアプリ（開発、品保で事前入手が困難）が動作しなくなってしまった。
【０００６】
また、ユーザーが既存ＭＦＰを新機種に置き換える場合、同じ機能を持つ新機種でも、システムリソース（ＣＰＵ、メモリー、ストレージ、ＯＳ設定（スレッド数など））の異なる場合がある。そのとき、置き換えた新機種上でのファームウェア機能のパフォーマンスや、ＭＦＰ上で動作するアプリケーションのパフォーマンス、動作を予め検証できない、という課題がある。
【課題を解決するための手段】
【０００７】
本発明の一実施系に係るクラウドコンピューティングシステムは、画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信手段と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示する、バックエンド処理プログラムを実行することにより実現される指示手段と、前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現する、バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段と、を有し、前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせないためにエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とする。
【発明の効果】
【０００８】
新ファームウェアは、一連のバックエンド処理により実際のユーザーデータ、設定を使ったテストで正常動作が確認され、ユーザーデータが既にインポートされた状態となっている。したがって、前記画像形成装置１０４に前記新ファームウェアがインストールされると、ユーザーデータやデバイス設定がファームウェア更新以前と同様にされた状態でシステムを起動することができる。また、事前に前記サーバーコンピューター群１０２上で機能テストをしているので、ファームウェアアップデートに伴う機能エラー等を防止することができる。また、事前に前記サーバーコンピューター群１０２上でパフォーマンステストをおこなっているので、旧ファームウェアとの処理速度の比較ができることも特徴である。
【図面の簡単な説明】
【０００９】
【図１】全体構成を示す図である
【図２】画像形成装置の内部構成を示す図である
【図３】情報処理装置の内部構成を示す図である
【図４】サーバーコンピューター群のプラットフォームシステムを示す図である
【図５】バックエンド処理部における処理を示すフローチャートである
【図６】ファームウェアアップデート処理を示したフローチャートである
【図７】要求受信部のリクエスト受付処理を示すフローチャートである
【図８】画像形成装置のリクエスト内容の一部である
【図９】リクエスト処理部が作成したキューメッセージ内容である
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１１】
［全体構成］
実施例１のプリントシステムを構成している各装置について、図１を参照して詳細に説明する。図１には、プリントシステムを構成している各装置がネットワーク１００を介して接続されている様子が示されている。プリントシステムを構成している各装置とは、サーバーコンピュータ群１０２、文書サーバー１０３、画像形成装置１０４、クライアントコンピュータ１０５である。サーバーコンピュータ群１０２は、クラウドコンピューティングシステムに相当する。
【００１２】
ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバーコンピュータ群１０２と文書サーバー１０３が属するネットワーク１００と、画像形成装置１０４とクライアントコンピュータ１０５が属するネットワーク１００とは、ファイアウォールを越えて通信が可能である。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。実施例１の図１において、サーバーコンピュータ群１０２は、１台のサーバーとして示されているが複数台のサーバーコンピュータで構成されている。
【００１３】
［画像形成装置の説明］
次に、図１のプリントシステムを構成している各装置の内部構成について詳細に説明する。始めに、画像形成装置１０４の内部構成について図２を用いて説明する。図２は、画像形成装置１０４の内部構成を例示するブロック図である。
画像形成装置１０４は、画像処理ユニット１０４１、および印刷ユニット１０４２から構成される。画像処理ユニット１０４１は、ＣＰＵ１０４３、直接記憶部１０４４、間接記憶部１０４５、ユーザーインターフェース１０４７、外部インターフェース１０４８から構成されている。
【００１４】
ＣＰＵ１０４３は、所定のプログラムを実行し、画像処理装置１０４の各種制御を指示するユニットである。ＣＰＵ１０４３は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）により実現される。直接記憶部１０４４は、ＣＰＵ１０４３がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０４３が実行するプログラムは直接記憶部１０４４にロードされる。直接記憶部１０４４は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部１０４５は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。また関節記憶部１０４５にはデバイスの設定やアプリケーションの設定、後述するプラットフォームアプリケーションの設定等が組み込みデータベースのストレージファイルとして保存されている。間接記憶部１０４５に記憶されている各種プログラムは、ＣＰＵ１０４３がプログラムを実行する際に直接記憶部１０４４へ移動する。間接記憶部１０４５は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ１０４３はマルチプロセッサでも良い。
【００１５】
ここで、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０２上で実行できる他、画像形成装置１０２の操作画面をカスタマイズすることが可能になる。
プラットフォームの実現方法について説明する。ＣＰＵ１０４３は、間接記憶部１０４５に記憶されたプラットフォームプログラムを直接記憶部１０４４に移動する。移動が完了するとＣＰＵ１０４３は、プラットフォームプログラムを実行することができる状態になる。本発明の実施例１では、ＣＰＵ１０４３がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００１６】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例１において、プラットフォーム上には、印刷要求を受け付ける印刷ソフトウェアが動作している。印刷ソフトウェアは、ネットワークを介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と言った通信プロトコルによって印刷データを受信できる。印刷ソフトウェアは、受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは印刷データ処理を開始する。なお、印刷データが処理をせずに印刷できるようなものであれば、ファームウェアは印刷データ処理を省く。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。例えば、スキャナユニットを制御する他、プリントユニットを制御することが可能になる。
【００１７】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部１０４５に記憶されたアプリケーションプログラムを直接記憶部１０４４に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本発明の実施例１ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例１で開示するフローチャートの各処理の一部を行うことが可能である。
【００１８】
ユーザーインターフェース１０４７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース１０４８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０２は、ネットワーク１００、およびインターネット１０１を介して、クライアントコンピュータ１０５、サーバーコンピュータ群１０２等と通信可能である。
２番目に、サーバーコンピュータ群１０２、文書サーバー１０３、クライアントコンピュータ１０５を含む情報処理装置の内部構成について図３を用いて説明する。図３は、情報処理装置１０６の内部構成を例示するブロック図である。情報処理装置１０６は、ユーザーインターフェース１０６１、ＣＰＵ１０６２、直接記憶部１０６３、間接記憶部１０６４、外部インターフェース１０６５から構成されている。
ユーザーインターフェース１０６１は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。
ＣＰＵ１０６２は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示するユニットである。ＣＰＵ１０６２は、ＣＰＵにより実現される。直接記憶部１０６３は、ＣＰＵ１０６２がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ１０６２が実行するプログラムは直接記憶部１０６３にロードされる。直接記憶部１０６３は、ＲＡＭで構成されている。間接記憶部１０６４は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部１０６４に記憶されている各種プログラムは、ＣＰＵ１０６２がプログラムを実行する際に直接記憶部１０６３へ移動する。間接記憶部１０６４は、ＲＯＭ、または、ＨＤＤで構成されている。外部インターフェース１０６５は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。
【００１９】
［仮想マシンの説明］
次に、サーバーコンピュータ群１０２のプラットフォームシステムについて図４を参照しながら詳細に説明する。図４は、サーバーコンピュータ群１０２内の各種機能を示した図である。図４において、サーバーコンピュータ群１０２内にある物理ハードウェア・リソースは、サーバーコンピュータ群１０２のプラットフォームに使用される。サーバーコンピュータ群１０２のプラットフォーム利用者は、このサーバーコンピュータ群１０２内にある物理ハードウェア・リソースをコンピューティング・リソースとして使用できる。
サーバーコンピュータ群１０２のプラットフォームシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、次のような機能を持つ。仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ）４０１、および４０２。ファブリックコントローラ（Ｆａｂｒｉｃ Ｃｏｎｔｒｏｌｌｅｒ）４０３。ロードバランサー（Ｌｏａｄ Ｂａｌａｎｃｅｒ）４０４。キューサービス（Ｑｕｅｕｅ）４０５。ストレージ（Ｓｔｏｒａｇｅ）４０６。管理仮想マシン４０７である。
サーバーコンピュータ群１０２上で動作するプラットフォームシステムの内部には、仮想マシン４０１、４０２が複数存在する。仮想マシンとは、仮想化技術によって物理的なサーバーコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本発明の実施例１では、インスタンス数１つに対し、サーバーコンピュータ群１０２内の１台のサーバーコンピュータ上で動作する。
【００２０】
仮想マシン４０１は、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０１１、要求受信部エージェント（Ａｇｅｎｔ）４０１２で構成される。要求受信部４０１１は、後述するロードバランサ−４０４を介してユーザーからの処理依頼を受信する。また、要求受信部４０１１は、キューサービス４０５を介してバックエンド処理部４０２への処理依頼を送信する。
要求受信部４０１１の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、仮想マシン４０１の外部にあるロードバランサー４０４を通じて行われる。ロードバランサー４０４は、外部ネットワークからの要求を一元的に管理し、同等な要求受信部の機能を有する複数の仮想マシンに対し、選択的に要求を転送するものである。要求受信部エージェント４０１２は、仮想マシン４０１の使用状況、要求受信部４０１１の稼動状態、仮想マシン４０１のリソースの使用状況、および要求受信部４０１１のエラーを含む各種情報を収集し、ファブリックコントローラ４０３に定期的に送信する。
要求受信部４０１１、バックエンド処理部４０２１の各インスタンスは、ファブリックコントローラ４０３によって管理されている。そのため、各インスタンスの拡張性と可用性が保証される。例えば、要求受信部４０１１、またはバックエンド処理部４０２１において、ある特定のインスタンスがサーバーの故障によって停止したとする。この場合、ファブリックコントローラ４０３は、要求受信部エージェント４０１２、またはバックエンド処理部エージェント４０２２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ４０３は、新しいインスタンスに処理が委譲されるように仮想マシンに指示を出す。結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。
【００２１】
仮想マシン４０２は、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０２１、バックエンド処理部エージェント（Ａｇｅｎｔ）４０２２で構成される。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１からの処理依頼を受信する。バックエンド処理部４０２１は、キューサービス４０５を介して要求受信部４０１１から受信した処理依頼を実行する。また、バックエンド処理部４０２１は、スケールアウトする。スケールアウトとは、仮想マシン４０２が増加し、バックエンド処理部４０２１のインスタンスが増加すること指す。バックエンド処理部４０２１のインスタンスが増加すると、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザーからの処理依頼に対する結果をより早く返すことができる。なお、要求受信部４０１１は仮想マシンが要求受信プログラムを実行することで実現され、バックエンド処理プログラムは仮想マシンがバックエンド処理プログラムを実行することで実現可能となる。
キューサービス４０５は、要求受信部４０１１とバックエンド処理部４０２１とが非同期でデータ通信するためのサービスを提供する。要求受信部４０１１、およびバックエンド処理部４０２１は、キューサービス４０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。要求受信部４０１１がキューサービス４０５に対して行う指示とは、キューメッセージの追加指示である。バックエンド処理部４０２１がキューサービス４０５に対して行う指示とは、キューメッセージの取得指示、キューメッセージの削除指示である。
【００２２】
要求受信部４０１１とバックエンド処理部４０２１が非同期でデータ通信する一連の動作について説明する。要求受信部４０１１は、ユーザーからの処理依頼に応じたキューメッセージを作成し、キューメッセージをキューに追加するようにキューサービス４０５に追加指示を送信する。追加指示を受信したキューサービス４０５は、キューにキューメッセージを追加する。バックエンド処理部４０２１は、キューメッセージを取得するために、キューサービス４０５に取得指示を出す。取得指示を受けたキューサービス４０５は、キューメッセージと、キューメッセージ毎に固有に割り振られたメッセージＩＤと、受取ＩＤとを取得指示に対するレスポンスとしてバックエンド処理部４０２１に返す。メッセージＩＤとは、キューメッセージを一意に定めるためにキューメッセージごとに割り振られた固有の情報である。受取ＩＤは、処理が終了したバックエンド処理部４０２１がキューメッセージを削除指示する際に使用する。キューメッセージと、メッセージＩＤと、受取ＩＤは、関連付けされて保存されることになる。バックエンド処理部４０２１は、処理依頼を完了すると、受取ＩＤに対応するキューメッセージの削除指示をキューサービス４０５に対して行う。削除指示を受けたキューサービス４０５は、バックエンド処理部４０２１が指示した受取ＩＤに対応するキューメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部４０２１以外のバックエンド処理部４０２１が同じキューメッセージを処理するという冗長な処理を防ぐことができる。
【００２３】
また、キューサービス４０５は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。不可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求をした場合に、キューサービス４０５はバックエンド処理部４０２１に対してキューメッセージを渡さないことを指す。バックエンド処理部４０２１がキューからキューメッセージを取得すると、取得されたキューメッセージはキューサービス４０５によって不可視になる。可視とは、バックエンド処理部４０２１がキューに追加されているキューメッセージの取得要求した場合に、キューサービス４０５がバックエンド処理部４０２１に対してキューメッセージを渡すことを指す。バックエンド処理部４０２１に取得され不可視になっているキューメッセージは、処理を行っているバックエンド処理部４０２１から処理結果が一定時間返ってこない場合にキューサービス４０５によって可視になる。
【００２４】
ストレージサービス４０６は、データ保存に利用されるストレージを提供する。バイナリデータの集合を保存する機能を提供する。また、後述する処理確認テーブル、およびキュー管理テーブルを保持する機能も提供する。
仮想マシン４０７は、要求受信部４０１１、要求受信部エージェント４０１２で構成される。仮想マシン４０１との違いは、管理ユーザーのみが利用できる要求受信部４０１１のインスタンスを持つ仮想マシンということである。この仮想マシンの要求受信部４０１１により管理ユーザーは、キュー管理テーブルを操作することができる。
【００２５】
本実施例においては、前記仮想マシン４０２に画像形成装置１０４のメインコントローラーと同等の状況を実現させる。画像形成装置１０４には処理能力、機能の違いに応じて様々なタイプがある。サーバーコンピュータ群１０２においては、バックエンド処理部４０２１が前記キューサービス４０５を経由して前記画像形成装置１０４からの要求を受け付ける。前記バックエンド処理部４０２１は、後述するパラメータに沿って前記画像形成装置１０４の処理能力、機能に応じ、前記複数タイプの仮想マシン４０２のイメージから最適なものを選択し、新たなファームウェアが実行される画像形成装置１０４を擬態した仮想マシン４０２の実態を生成する（後述）。
【００２６】
［要求受信部処理］
図７は、本実施例の仮想マシン４０１における、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）４０１１の、リクエスト受付処理を示したフローチャートである。要求受信部４０１１が、画像形成装置１０４からのリクエストを受信することから本フローチャートは開始する（ステップ７０１）。画像形成装置のリクエストを、図８に示す。図８は画像形成装置１０４のリクエスト内容の一部である。リクエストは画像形成装置１０４がＨＴＴＰプロトコルで送信し、要求受信部４０１１が受け取る。本リクエストは、図８のデバイスに関する情報のＸＭＬ文書と、前記画像形成装置１０４の各種ユーザーデータを含む組込みデータベースをエクスポートしたバイナリデータを圧縮した部分と、前記画像形成装置にインストールされたプラットフォームアプリケーション群から成る。
【００２７】
デバイスに関する情報は画像形成装置１０４を表す＜ｄｅｖｉｃｅ＞要素の子要素として、機種名を示す＜ｎａｍｅ＞要素、インストールされているファームウェアのバージョンを示す＜ｆｉｒｍｖｅｒ＞要素、デバイスシリアル番号を示す＜ｓｅｒｉａｌｎｏ＞要素を含む。また前記画像形成装置１０４のハードウェア情報、即ちリソース情報を表す＜ｈａｒｄｗａｒｅ−ｉｎｆｏ＞要素の子要素として、＜ｃｐｕ＞要素、＜ｍｅｍｏｒｙ＞要素、＜ｓｔｏｒａｇｅ＞要素がある。
前記＜ｃｐｕ＞要素は画像形成装置１０４のＣＰＵ１０４３の属性を表す。前記＜ｃｐｕ＞要素には子要素として、該ＣＰＵ１０４３のコア数を示す＜ｖｃｐｕ＞要素と、該ＣＰＵ１０４３のアーキテクチャを示す＜ｔｙｐｅ＞要素と、該ＣＰＵ１０４３のクロックをＭＨｚで示す＜ｃｌｏｃｋ＞要素がある。前記＜ｍｅｍｏｒｙ＞要素は前記画像形成装置１０４のメインコントローラーボードに搭載された直接記憶部１０４４のメモリ容量をメガバイト単位で表す。前記＜ｓｔｏｒａｇｅ＞要素は前記画像形成装置１０４のメインコントローラーボードに搭載された間接記憶部１０４５であるＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）の容量をギガバイト単位で表す。
【００２８】
また図８の＜ａｐｐｌｉｃａｔｉｏｎｓ＞要素は、ファームウェアとは別に画像形成装置１０４に後からインストールしたプラットフォームアプリケーション群を示す、プラットフォームに関する情報である。前記＜ａｐｐｌｉｃａｔｉｏｎｓ＞要素の子要素として、インストールされたプラットフォームアプリケーションの各々を示す＜ａｐｐｌｉｃａｔｉｏｎ＞要素がある。前記＜ａｐｐｌｉｃａｔｉｏｎ＞要素には、子要素としてプラットフォームアプリケーション名を示す＜ｎａｍｅ＞要素と、該プラットフォームアプリケーションの識別子を示す
＜ｕｕｉｄ＞要素と、該プラットフォームアプリケーションのバージョンを示す＜ｖｅｒｓｉｏｎ＞要素がある。
本実施例図８の場合、Ａｐｐｌｉｃａｔｉｏｎ＿Ａ（バージョン１．０．０）、Ａｐｐｌｉｃａｔｉｏｎ＿Ｃ（バージョン２．０．１）、Ａｐｐｌｉｃａｔｉｏｎ＿Ｆ（バージョン１．７．２）の３つのプラットフォームアプリケーションがインストールされていることを示す。
図８に示されるリクエストを受信した（ステップ７０１）要求受信部４０１１は、次に、リクエストに含まれるユーザーデータをストレージサービス４０６に格納する（ステップ７０２）。格納先は、要求受信部４０１１が前記リクエストに含まれるデバイスデータからデバイス名とデバイスシリアル番号を読み取り、以下のように／ｖａｒ／ｄａｔａ の下のデバイス名、デバイスシリアル番号の下となる。
【００２９】
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／ｕｓｅｒ．ｄｂ
図８に示されるリクエストを受信した（ステップ７０１）要求受信部４０１１は、次に、リクエストにバイナリを添付した形で含まれるプラットフォームアプリケーションをストレージサービス４０６に格納する（ステップ７０３）。格納先は、要求受信部４０１１が前記リクエストに含まれるデバイスデータからデバイス名とデバイスシリアル番号を読み取り、以下のように／ｖａｒ／ｄａｔａ の下のデバイス名、デバイスシリアル番号の下となる。
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ａ
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ｃ
／ｖａｒ／ｄａｔａ／ＸＸ３０００／ＡＢＣ１２３４５／Ａｐｐｌｉｃａｔｉｏｎ＿Ｆ
要求受信部４０１１は次に、キューサービス４０５の参照を取得し（ステップ７０４）、キューメッセージを作成する（ステップ７０５）。該キューメッセージは図９のように作成される。
【００３０】
図９は、要求受信部４０１１が該リクエストを受信し作成したキューメッセージである。図８に示した画像形成装置１０４のリクエスト内容に、各＜ａｐｐｌｉｃａｔｉｏｎ＞要素の子要素として、前記ストレージサービス４０６にプラットフォームアプリケーションを格納した際の格納先パスである＜ｐａｔｈ＞要素を加える。また、前記ユーザーデータを表す＜ｕｓｅｒｄａｔａ＞要素を加える。＜ｕｓｅｒｄａｔａ＞要素の子要素には前記ストレージサービス４０６に格納した際の格納先パスである＜ｐａｔｈ＞要素が含まれる。要求受信部４０１１は、上記キューメッセージを作成すると、前記キューサービス４０５に前記キューメッセージを挿入し（ステップ７０６）、処理を終える。
【００３１】
［バックエンド処理］
図５は、本実施例の前記バックエンド処理部４０２１における処理を示したフローチャートである。
前記バックエンド処理部４０２１は、前記キューサービス４０５から前記画像形成装置１０４のリクエストを受け付ける（ステップ５０１）。本リクエストは図９に示したキューメッセージから成る。バックエンド処理部４０２１は受信した前記リクエストを解析し、ＸＭＬ文書の要素で示された各パラメーターが後述する仮想マシンのインストールイメージと合致するかどうか確認する。また、バックエンド処理部４０２１は、ユーザーデータがストレージサービス４０６の指定のパスに格納されているかどうか確認する（ステップ５０２）。
【００３２】
もし受信した前記キューメッセージ（図９）が後述する仮想マシンに合致しない、あるいはユーザーデータがストレージサービス４０６の指定のパスに存在しないのであれば（ステップ５０３）、リクエストパラメーター異常、あるいはユーザーデータ異常のエラーメッセージを作成し（ステップ５１６）、メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。もしキューメッセージに問題がなければ（ステップ５０３）、該キューメッセージから＜ｈａｒｄｗａｒｅ−ｉｎｆｏ＞要素以下の子要素の各々を取り出し（ステップ５０４）、仮想マシンを作成、実態生成する（ステップ５０５）。この仮想マシンは、画像形成装置１０４のリソース状況、および画像形成装置のプラットフォームに関連する状況を再現する。
【００３３】
［仮想マシンイメージの作成、実態生成］
本実施例においては、仮想マシン４０２の制御にオープンソースの仮想マシン制御 ＡＰＩを用いる。仮想マシン制御 ＡＰＩは仮想マシンの制御を抽象化したライブラリで、Ｘｅｎ、ＫＶＭ、ＱＥＭＵなどの仮想マシンをサポートしている。またＣＰＵとしてｘ８６、ｘ８６?６４、ＩＡ６４、Ｐｏｗｅｒなどをサポートしており、ビット（３２／６４）およびエンディアンを問わない、事実上の標準となっているＡＰＩである。
本実施例の場合、仮想マシンイメージは、画像形成装置１０４の種類に応じて以下の３種類である。もちろん本仮想マシンイメージは、サーバーコンピュータ群の能力と、画像形成装置１０４の他のタイプに応じてパラメータを変更することによりさらに多くのパターンを作り出すことができる。
【００３４】
インストールイメージ（１）
割当てるＣＰＵ数：１
メモリサイズ：５１２ＭＢ
ディスクサイズ：４ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖｅｒｓｉｏｎ／ＸＸ３０００．ｉｍｇ
仮想マシン名：ＸＸ３０００
インストールイメージ（２）
割当てるＣＰＵ数：２
メモリサイズ：１ＧＢ
ディスクサイズ：２０ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ４０００／Ｖｅｒｓｉｏｎ／ＸＸ４０００．ｉｍｇ
仮想マシン名：ＸＸ４０００
インストールイメージ（３）
割当てるＣＰＵ数：４
メモリサイズ：２ＧＢ
ディスクサイズ：８０ＧＢ
ディスクパス： ／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ５０００／Ｖｅｒｓｉｏｎ／ＸＸ５０００．ｉｍｇ
仮想マシン名：ＸＸ５０００
各々のディスクパスに収められるイメージは、以下のように作成する。各機種（本実施例の場合上記１，２，３）向け新ファームウェアがリリースされると、ストレージサービス４０６の所定のパスにアップロードされる。例えば（１）の場合でファームウェアバージョン１．１．２がリリースされた場合、以下パスにファームウェア一式のインストールイメージがアップロードされる。
【００３５】
／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＸＸ３０００．ｉｍｇ
上記インストールイメージは、オペレーティングシステム、各種ライブラリ、各種アプリケーションモジュールをファームウェアとして構成し、ｄｄ コマンド等で起動可能イメージを作成したものである。前記インストールイメージは、ｌｉｂｖｉｒｔ ＡＰＩを実装したコマンドより次のように起動され、仮想マシンの実態が生成される。以下は前記インストールイメージ（１）を起動する場合のコマンド例である。
【００３６】
ｖｉｒｔ−ｉｎｓｔａｌｌ −−ａｃｃｅｌｅｒａｔｅ −−ｈｖｍ −−ｃｏｎｎｅｃｔ ｑｅｍｕ：／／／ｓｙｓｔｅｍ −−ｎｅｔｗｏｒｋ
ｎｅｔｗｏｒｋ：ｄｅｆａｕｌｔ −−ｎａｍｅ ＸＸ３０００ −−ｒａｍ＝５１２ −−ｏｓ−ｔｙｐｅ＝Ｌｉｎｕｘ
−−ｏｓ−ｖａｒｉａｎｔ＝ｕｎｉｘ −−ｆｉｌｅ＝／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＸＸ３０００．ｉｍｇ
−−ｆｉｌｅ−ｓｉｚｅ＝４
バックエンド処理部４０２１は、画像形成装置１０４からのリクエストを受信し、リクエスト内容（後述）に応じて上記コマンドを実行し、新たな仮想マシン４０２を生成する（ステップ５０５）。もし前記仮想マシン４０２が正常に起動しなかったら（ステップ５０６）、仮想マシン起動失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
【００３７】
前記仮想マシン４０２が正常に起動したら（ステップ５０６）、次にバックエンド処理部４０２１は、ステップ５０４にて前記キューメッセージから取り出した＜ｕｓｅｒｄａｔａ＞要素の子要素である＜ｐａｔｈ＞要素に指定されたストレージサービス４０６のディレクトリ下にあるユーザーデータのデータベースファイルを、前記仮想マシン４０２にインポートする（ステップ５０７）。本実施例の場合、組み込みデータベース（ＳＱＬｉｔｅ）の ．ｉｍｐｏｒｔ コマンドを用いてデータベースをインポートする。
【００３８】
もし前記仮想マシン４０２へのデータベースのインポートに失敗したら、（ステップ５０９）、ユーザーデータインポート失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
もし前記仮想マシン４０２へのデータベースのインポートに成功したら、（ステップ５０９）、次にバックエンド処理部４０２１は、ステップ５０４にて前記キューメッセージから取り出した＜ａｐｐｌｉｃａｔｉｏｎ＞要素の子要素である＜ｐａｔｈ＞要素に指定されたストレージサービス４０６のディレクトリ下にあるプラットフォームアプリケーションを、前記仮想マシン４０２にインストールする（ステップ５１７）。本実施例の場合、前記仮想マシン４０２のアプリケーションディレクトリへの、前記プラットフォームアプリケーションのコピーによりインストールを行う。
もし前記仮想マシン４０２へのプラットフォームアプリケーションのインストールに失敗したら、（ステップ５０９）、プラットフォームアプリケーションインストール失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
もし前記仮想マシン４０２へのプラットフォームアプリケーションのインストールに成功したら、前記仮想マシン４０２は、新ファームウェアにユーザーデータをインポートし、プラットフォームアプリケーションをインストールした状態となる。これは前記リクエスト元の画像形成装置１０４に新ファームウェアをインストールし、ユーザーデータをインポートしてプラットフォームアプリケーションをインストールした状態を、サーバー上に仮想的に作り上げた状態である。この状態で、次に前記仮想マシン４０２は、本仮想マシン４０２の機能テストを行う（ステップ５１０）。
【００３９】
機能テストは、次のように行う。本実施例の画像形成装置１０４におけるファームウェアは、ｓｙｓｌｏｇ ライブラリによるログ出力を行う。ファームウェアの各ライブラリ、アプリケーションは、ｓｙｓｌｏｇ の ｉｎｆｏ レベルで各関数の呼び出し開始、終了を出力する。通常、画像形成装置１０４上で実行するファームウェアのログ出力レベルは、ログ出力量、パフォーマンスを考慮してｗａｒｎレベルまでの出力となる。
【００４０】
しかし前記仮想マシン４０２の機能テストを行う場合、バックエンド処理部４０２１は、ｓｙｓｌｏｇｄ のログ出力レベルプライオリティを ｄｅｂｕｇ レベルまで出力するように設定してテストを行う。ここで前記仮想マシン４０２のファームウェアをテストすると、ｉｎｆｏレベルのログが出力され、関数レベルでの動作を確認することができる。テスト項目は、ファームウェア開発時の各種結合テストを行う。例えばＰＤＦファイル生成機能の場合、本機能テストは、ストレージサービス４０６に予め用意されたスキャンデータを、前記仮想マシン４０２のＰＤＦ生成機能関数に入力し、ログをログ出力ファイルに記録する。
【００４１】
ここでバックエンド処理部４０２１がログ出力ファイルを確認し、もしｓｙｓｌｏｇ 出力にエラーや例外が出力されていたら、機能テスト失敗のエラーメッセージを作成し、メッセージを前記画像形成装置１０４に送信し（ステップ５１５）処理を終える。ここでバックエンド処理部４０２１が前記ログ出力ファイルを確認し、もしｓｙｓｌｏｇ 出力にエラーや例外が出力されていなければ（ステップ５１１）、次にパフォーマンステストを行う（ステップ５１２）。
【００４２】
パフォーマンステストは、次のように行う。バックエンド処理部４０２１は、受信した前記キューメッセージ（図９）に含まれる＜ｄｅｖｉｃｅ＞要素の子要素である＜ｆｉｒｍｖｅｒ＞要素から、画像形成装置１０４のファームウェアバージョンを取得する。そしてそのファームウェアバージョンから、過去のファームウェアインストールイメージを検索して、ファームウェアアップデート前の画像形成装置１０４に相当する仮想マシン４０２を生成する。
【００４３】
過去のファームウェアも、新規ファームウェア同様に、ストレージサービス４０６の所定のパスにアップロードされている。本実施例の場合、以下パスにファームウェア一式のインストールイメージがアップロードされている。
／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．１／ＸＸ３０００．ｉｍｇ
上記インストールイメージは、オペレーティングシステム、各種ライブラリ、各種アプリケーションモジュールをファームウェアとして構成し、ｄｄ コマンド等で起動可能イメージを作成したものである。
前記インストールイメージは、ｌｉｂｖｉｒｔ ＡＰＩを実装したコマンドより次のように起動され、仮想マシンの実態が生成される。以下は前記インストールイメージを起動する場合のコマンド例である。
【００４４】
ｖｉｒｔ−ｉｎｓｔａｌｌ −−ａｃｃｅｌｅｒａｔｅ −−ｈｖｍ −−ｃｏｎｎｅｃｔ ｑｅｍｕ：／／／ｓｙｓｔｅｍ −−ｎｅｔｗｏｒｋ
ｎｅｔｗｏｒｋ：ｄｅｆａｕｌｔ −−ｎａｍｅ ＸＸ３０００ −−ｒａｍ＝５１２ −−ｏｓ−ｔｙｐｅ＝Ｌｉｎｕｘ
−−ｏｓ−ｖａｒｉａｎｔ＝ｕｎｉｘ −−ｆｉｌｅ＝／ｖａｒ／ｌｉｂ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．１／ＸＸ３０００．ｉｍｇ
−−ｆｉｌｅ−ｓｉｚｅ＝４
バックエンド処理部４０２１は上記コマンドを実行し、新たな仮想マシン４０２を生成する。ここでバックエンド処理部４０２１は、前記ステップ５０７、５１７、５１０と同様に、前記仮想マシン４０２に対してユーザーデータをインポートし、プラットフォームアプリケーションをインストールし、機能テストを行う。
【００４５】
上記機能テストが終了したら、新旧ファームウェアのｓｙｓｌｏｇ 出力を比較して相対的なパフォーマンスを評価する。例えばＰＤＦ生成機能の場合、バックエンド処理部４０２１は、新ファームウェア上のｓｙｓｌｏｇ出力から関数の開始時間から終了時間までを計算し、旧ファームウェア上のｓｙｓｌｏｇ 出力からも同様の計算を行なって、相対速度を計算する。
【００４６】
ここでもしパフォーマンステストの結果、ｓｙｓｌｏｇ 出力にエラーや例外が出力されていたら（ステップ５１３）、パフォーマンステスト失敗のエラーメッセージを作成し（ステップ５１６）、該メッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
ここでもしパフォーマンステストの結果、ｓｙｓｌｏｇ 出力にエラーや例外が出力されていなければ（ステップ５１３）、バックエンド処理部４０２１は、次にテスト結果を作成する（ステップ５１４）。
【００４７】
この時点でバックエンド処理部４０２１は、新バージョンのファームウェアで動作する前記仮想マシンのｓｙｓｌｏｇｄ のログ出力レベルプライオリティを ｗａｒｎレベルに再設定する。通常、画像形成装置１０４上で実行するファームウェアのログ出力レベルは、ログ出力量、パフォーマンスを考慮してｗａｒｎレベルまでの出力である。バックエンド処理部４０２１はさらに、前記仮想マシンのイメージを ｄｄ コマンドで作成し、ストレージサービス４０６の、画像形成装置がアクセス可能なダウンロード可能ディレクトリにコピーする（ステップ５１９）。
本実施例の場合、上記ダウンロード可能ディレクトリにコピーされたファームウェアイメージは以下のようである。
【００４８】
／ｖａｒ／ｌｉｂ／ｄｏｗｎｌｏａｄａｂｌｅ／ｆｉｒｍ＿ｉｍａｇｅｓ／ＸＸ３０００／Ｖ１．１．２／ＡＡＡ１２３４５／ＸＸ３０００．ｉｍｇ
この後バックエンド処理部４０２１は、ステップ５１４で作成したメッセージを前記画像形成装置１０４に送信して（ステップ５１５）処理を終える。
【００４９】
［画像形成装置処理］
図６は、画像形成装置１０４のファームウェアアップデート処理を示したフローチャートである。本実施例で画像形成装置１０４のファームウェアアップデートがあった場合、前記サーバーコンピュータ群１０２の前記仮想マシン４０１の前記要求受信部４０１１に、アップデートした新規ファームウェア情報を掲載する。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、前記サーバーコンピュータ群１０２の前記ファームウェアアップデート情報を掲載する仮想マシン４０１の前記要求受信部４０１１を定期的に監視することで行う。
【００５０】
画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションがサーバーコンピュータ群１０２と通信し、ファームウェアアップデートを検知した場合にその情報を受信することで本フローチャートは開始する（ステップ６０１）。画像形成装置１０４において、ファームウェアアップデート用プラットフォームアプリケーションは、間接記憶部１０４５に記憶されたデバイスの設定やアプリケーションの設定、プラットフォームアプリケーションの設定等が組み込みデータベースのストレージファイルを取得する。また、デバイス情報取得手段により、デバイスのハードウェア情報を取得し、図８の画像形成装置１０４のファームウェアアップデートリクエスト内容のＸＭＬ文書を作成する（ステップ６０２）。ファームウェアアップデートプラットフォームアプリケーションは、データベースファイルとリクエスト内容のＸＭＬ文書を、サーバーコンピュータ群のファームウェアアップデート要求を受け付ける要求受信部４０１１に送信する（ステップ６０３）。
【００５１】
ここでもしデータベースファイルとリクエスト内容のＸＭＬ文書の送信に失敗したら（ステップ６０４）、ファームウェアアップデートプラットフォームアプリケーションは、送信失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでデータベースファイルとリクエスト内容のＸＭＬ文書の送信に成功した場合（ステップ６０４）、次の様な処理を行う。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、前記サーバーコンピュータ群１０２のバックエンド処理部４０２１からの機能パフォーマンステスト結果の通知を待ち受ける。前記通知の待ち受けは、前記画像形成装置１０４の前記ファームウェアアップデート用プラットフォームアプリケーションが前記サーバーコンピュータ群１０２の所定の仮想マシン４０１の要求受信部４０１１を定期的に監視することで行ってもよい。
【００５２】
前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションがステップ６０３、６０４にて前記画像形成装置１０４のファームウェアアップデート情報を送信した場合、次の様な処理を行う。図５のフローチャートで示したバックエンド処理のステップ５１５の処理完了、結果通知を待ち受け（ステップ６０５）、該メッセージを前記画像形成装置１０４に表示する（ステップ６０６）。
【００５３】
ここでもし前記図５のフローチャートで示したバックエンド処理のステップ５１５の処理が失敗であったら（ステップ６０７）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、ファームウェアアップデートテスト失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでもし前記図５のフローチャートで示したバックエンド処理のステップ５１５の処理が成功した場合（ステップ６０７）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、ストレージサービス４０６の、画像形成装置がアクセス可能なダウンロード可能ディレクトリにコピーされた新ファームウェアをダウンロードする（ステップ６０８）。
【００５４】
ここでもしステップ６０８の新ファームウェアダウンロードの処理が失敗したら（ステップ６０９）、次の様な処理を行う。前記画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアダウンロード失敗のエラーメッセージを作成し、該メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）即ち、ファームウェアを画像形成装置１０４へ送信することなく処理を終える。
【００５５】
ここでもしステップ６０８の新ファームウェアダウンロードの処理が成功したら（ステップ６０９）、画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアをアップデートする（ステップ６１０）。ファームウェアアップデートは、前記ダウンロードした新ファームウェアをファームウェアアップデート用領域にコピーし、次回再起動時に新ファームウェアを展開して実行することにより実現する。
【００５６】
ここでもしステップ６１０の新ファームウェアアップデートの処理が失敗したら（ステップ６１１）、次の様な処理を行う。画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは、新ファームウェアダウンロード失敗のエラーメッセージを作成し、メッセージを画像形成装置１０４に表示して（ステップ６１２）処理を終える。（図示せず）
ここでもしステップ６１０の新ファームウェアアップデートの処理が成功したら（ステップ６１１）、画像形成装置１０４上のファームウェアアップデートプラットフォームアプリケーションは処理を終える。
【００５７】
新ファームウェアは、図５のフローチャートで示した一連のバックエンド処理により実際のユーザーデータ、設定を使ったテストで正常動作が確認され、ユーザーデータが既にインポートされた状態となっている。したがって、画像形成装置１０４に新ファームウェアがインストールされると、ユーザーデータやデバイス設定がファームウェア更新以前と同様にされた状態でシステムを起動することができる。
【００５８】
従来ファームウェアアップデート時に必要であった、ファームウェアインストール後の設定更新作業や、ユーザーデータの事前のエクスポート、ファーム更新事後のインポート作業などの処理を省くことができ、利便性を高めることができる。また事前にサーバーコンピュータ群１０２上で機能テストをしているので、ファームウェアアップデートに伴う機能エラー等を防止することができる。また事前に前記サーバーコンピュータ群１０２上でパフォーマンステストをおこなっているので、旧ファームウェアとの処理速度の比較ができることも特徴である。
【符号の説明】
【００５９】
１０２ 本実施例における、サーバーコンピュータ群である
１０４ 本実施例における、画像形成装置である
４０１ 本実施例における、要求受信部の仮想マシンである
４０１１ 本実施例における、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）である
４０２ 本実施例における、バックエンド処理部の仮想マシンである
４０２１ 本実施例における、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）である
【特許請求の範囲】
【請求項１】
画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信手段と、
前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示する、バックエンド処理プログラムを実行することにより実現される指示手段と、
前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現する、バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段と、を有し、
前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、
ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置に送信することなくエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とするクラウドコンピューティングシステム。
【請求項２】
リソース情報は、ＣＰＵ数、ＣＰＵの処理能力、メモリサイズ、およびディスクサイズの内、少なくとも１つの情報を含み、前記プラットフォームに関する情報は、前記プラットフォームで動作するアプリケーション名、前記プラットフォームで動作するアプリケーションの識別子、および前記プラットフォームのアプリケーションのバージョンの内、少なくとも１つの情報を含み、前記プラットフォームで動作するアプリケーションは前記画像形成装置のスキャナユニット、またはプリントユニットを制御することを特徴とする請求項１に記載のクラウドコンピューティングシステム。
【請求項３】
要求受信プログラムを実行することにより実現される要求受信手段は、画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納し、
バックエンド処理プログラムを実行することにより実現される指示手段は、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示し、
バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段は、前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現することを特徴とし、
更に、前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、
ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせないためにエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とするクラウドコンピューティングシステムを制御する制御方法。
【請求項４】
請求項３に記載の制御方法をクラウドコンピューティングシステムで実行させるためのプログラム。
【請求項１】
画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信手段と、
前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示する、バックエンド処理プログラムを実行することにより実現される指示手段と、
前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現する、バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段と、を有し、
前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、
ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置に送信することなくエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とするクラウドコンピューティングシステム。
【請求項２】
リソース情報は、ＣＰＵ数、ＣＰＵの処理能力、メモリサイズ、およびディスクサイズの内、少なくとも１つの情報を含み、前記プラットフォームに関する情報は、前記プラットフォームで動作するアプリケーション名、前記プラットフォームで動作するアプリケーションの識別子、および前記プラットフォームのアプリケーションのバージョンの内、少なくとも１つの情報を含み、前記プラットフォームで動作するアプリケーションは前記画像形成装置のスキャナユニット、またはプリントユニットを制御することを特徴とする請求項１に記載のクラウドコンピューティングシステム。
【請求項３】
要求受信プログラムを実行することにより実現される要求受信手段は、画像形成装置から、前記画像形成装置のリソース情報、および前記画像形成装置のＯＳとは異なるプラットフォームに関する情報とを受信したことに応じて、前記情報に対応するメッセージを記憶手段に格納し、
バックエンド処理プログラムを実行することにより実現される指示手段は、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は仮想マシンの生成を指示し、
バックエンド処理プログラムを実行することにより実現されるバックエンド処理手段は、前記指示手段により生成された仮想マシンであって、前記指示手段によりインポートされた情報を基に、前記画像形成装置のリソース状況、および前記画像形成装置のプラットフォームに関連する状況を再現することを特徴とし、
更に、前記バックエンド処理手段は、前記画像形成装置に関連するファームウェアのアップデートを検知したことに応じて、アップデートされたファームウェアを実行し、
ファームウェアを正常に実行できなかった場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせないためにエラーメッセージを前記画像形成装置へ送信し、ファームウェアを正常にできた場合は、前記アップデートされたファームウェアを前記画像形成装置にインストールさせるために前記アップデートされたファームウェアを前記画像形成装置へ送信することを特徴とするクラウドコンピューティングシステムを制御する制御方法。
【請求項４】
請求項３に記載の制御方法をクラウドコンピューティングシステムで実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１７４１９６（Ｐ２０１２−１７４１９６Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３８４４０（Ｐ２０１１−３８４４０）
【出願日】平成２３年２月２４日（２０１１．２．２４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月２４日（２０１１．２．２４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]