(57)【特許請求の範囲】
【請求項１】
当該画像処理装置の標準機能と前記標準機能を利用した拡張機能とが異なる第１及び第２仮想マシン上で動作する画像処理装置であって、
前記標準機能として表示画面の表示制御を実現する複数の動作モジュールと、
各仮想マシン上で動作し、前記複数の動作モジュールに対して共通の仮想マシン間通信を行う通信インタフェース部と、を有し、
前記拡張機能が動作する前記第２仮想マシン側の通信インタフェース部が、
前記拡張機能を実現するアプリケーションからの画面更新要求に応じて、前記アプリケーションの表示画面を制御する、表示制御コマンドを用いた表示制御データを生成する生成手段と、
前記生成手段により生成した表示制御データを、前記標準機能が動作する前記第１仮想マシンに送信するデータ送信手段と、を有し、
前記第１仮想マシン側の通信インタフェース部が、
前記第２仮想マシンから前記表示制御データを受信するデータ受信手段と、
前記データ受信手段により受信した表示制御データに従った表示制御の実行を、前記動作モジュールのうち、画面制御を行う画面制御モジュールに要求する要求手段と、を有し、
前記生成手段は、
前記表示画面を構成する表示部品の削除、追加、及び変更の各表示制御を指示する表示制御コマンドと、階層構造により表示画面を構成する表示部品を指定する表示部品識別子と、階層構造で親にあたる表示部品と子にあたる表示部品とを指定するためのセパレータとを含む、表示制御データを生成することを特徴とする画像処理装置。
【請求項２】
前記第２仮想マシン側の通信インタフェース部が、
前記アプリケーションから、画面更新要求に応じた表示画面を構成する表示部品の属性情報を取得する取得手段を有し、
前記生成手段は、
前記取得手段により取得した前記表示部品の属性情報に基づき、表示制御コマンドを用いた表示制御データを生成することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記第１及び第２仮想マシンが共有する画像データの記憶領域を有し、
該記憶領域には、前記表示部品の画像データを保持していることを特徴とする請求項１又は２に記載の画像処理装置。
【請求項４】
前記生成手段は、
階層構造で構成される複数の表示部品のうち、前記階層構造に基づく親子関係に従って、制御対象である表示部品を指定する表示部品識別子を含む、表示制御データを生成することを特徴とする請求項３に記載の画像処理装置。
【請求項５】
前記画面制御モジュールは、
前記表示制御データに含む表示制御コマンドにより、表示部品を削除する表示制御が指定されていた場合に、
前記階層構造に従って、制御対象である表示部品の子にあたる１又は複数の表示部品を、制御対象である表示部品とともに削除することを特徴とする請求項２ないし４のいずれか一項に記載の画像処理装置。
【請求項６】
前記第２仮想マシン側の通信インタフェース部が、
前記アプリケーションからの画面生成要求に応じて、前記画面制御モジュールが表示画面を生成するのに必要な、前記アプリケーションを識別するアプリ識別情報を含む画面生成情報を、前記第１仮想マシンに送信する画面生成情報送信手段を有し、
前記第１仮想マシン側の通信インタフェース部が、
前記第２仮想マシンから前記画面生成情報を受信する画面生成情報受信手段を有することを特徴とする請求項１ないし５のいずれか一項に記載の画像処理装置。
【請求項７】
前記第１仮想マシン側の通信インタフェース部が、
入力操作により受け付けたボタン押下のイベント情報を第２仮想マシンに送信するイベント情報送信手段を有し、
前記第２仮想マシン側の通信インタフェース部が、
前記第１仮想マシンから前記イベント情報を受信するイベント情報受信手段を有し、
前記イベント情報受信手段は、
受信したイベント情報に基づき、前記アプリケーションにボタン押下時の処理を要求することを特徴とする請求項１ないし６のいずれか一項に記載の画像処理装置。
【請求項８】
当該画像処理装置は、
ブラウザが動作する表示装置を備え、
前記画面制御モジュールとしてサーブレットを有し、
前記データ受信手段により受信したＪａｖａＳｃｒｉｐｔで記述される表示制御データに従った表示制御の実行を、前記要求手段により前記サーブレットに要求し、
前記サーブレットが、前記ブラウザを介して前記表示画面を描画することを特徴とする請求項７に記載の画像処理装置。
【請求項９】
当該画像処理装置は、
前記ブラウザで受け付けた入力操作によるボタン押下のイベント情報を、前記イベント情報送信手段により前記第２仮想マシンに送信し、
前記ブラウザで前記ＪａｖａＳｃｒｉｐｔを実行し、前記表示画面をボタン押下に応じて更新することを特徴とする請求項８に記載の画像処理装置。
【請求項１０】
画像処理装置の標準機能と前記標準機能を利用した拡張機能とが異なる第１及び第２仮想マシン上で動作する環境において、前記標準機能として表示画面の表示制御を実現する複数の動作モジュールと、各仮想マシン上で動作し、前記複数の動作モジュールに対して共通の仮想マシン間通信を行う通信インタフェース部と、を有する画像処理装置における表示制御方法であって、
前記拡張機能が動作する前記第２仮想マシン側の通信インタフェース部において、
前記拡張機能を実現するアプリケーションからの画面更新要求に応じて、前記アプリケーションの表示画面を制御する、表示制御コマンドを用いた表示制御データを生成する生成手順と、
前記生成手順により生成した表示制御データを、前記標準機能が動作する前記第１仮想マシンに送信するデータ送信手順と、を有し、
前記第１仮想マシン側の通信インタフェース部において、
前記第２仮想マシンから前記表示制御データを受信するデータ受信手順と、
前記データ受信手順により受信した表示制御データに従った表示制御の実行を、前記動作モジュールのうち、画面制御を行う画面制御モジュールに要求する要求手順と、を有し、
前記生成手順は、
前記表示画面を構成する表示部品の削除、追加、及び変更の各表示制御を指示する表示制御コマンドと、階層構造により表示画面を構成する表示部品を指定する表示部品識別子と、階層構造で親にあたる表示部品と子にあたる表示部品とを指定するためのセパレータとを含む、表示制御データを生成することを特徴とする表示制御方法。
【請求項１１】
画像処理装置の標準機能と前記標準機能を利用した拡張機能とが異なる第１及び第２仮想マシン上で動作する環境において、前記標準機能として表示画面の表示制御を実現する複数の動作モジュールと、各仮想マシン上で動作し、前記複数の動作モジュールに対して共通の仮想マシン間通信を行う通信インタフェース部と、を有する画像処理装置における表示制御プログラムであって、
前記拡張機能が動作する前記第２仮想マシン側で通信インタフェース部を動作させることにより、
コンピュータを、
前記拡張機能を実現するアプリケーションからの画面更新要求に応じて、前記アプリケーションの表示画面を制御する、表示制御コマンドを用いた表示制御データを生成する生成手段と、
前記生成手段により生成した表示制御データを、前記標準機能が動作する前記第１仮想マシンに送信するデータ送信手段として機能させ、
さらに、前記第１仮想マシン側の通信インタフェース部を動作させることにより、
コンピュータを、
前記第２仮想マシンから前記表示制御データを受信するデータ受信手段と、
前記データ受信手段により受信した表示制御データに従った表示制御の実行を、前記動作モジュールのうち、画面制御を行う画面制御モジュールに要求する要求手段として機能させ、
前記生成手段は、
前記表示画面を構成する表示部品の削除、追加、及び変更の各表示制御を指示する表示制御コマンドと、階層構造により表示画面を構成する表示部品を指定する表示部品識別子と、階層構造で親にあたる表示部品と子にあたる表示部品とを指定するためのセパレータとを含む、表示制御データを生成する表示制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の仮想マシンが動作可能な画像処理装置に関し、特に、当該画像処理装置が備える表示装置の表示制御を行う技術に関するものである。
【背景技術】
【０００２】
１台の物理コンピュータ上に、あたかもコンピュータが複数稼働しているかのような疑似システムを構築する仮想化技術は既に知られている。このような仮想化技術により実現される擬似的な情報処理システム環境（論理コンピュータ）を、仮想マシン（ＶＭ：Virtual Machine）と言う（例えば「特許文献１」参照）。
【０００３】
上記仮想化技術は、近年、ＰＣ（Personal Computer）環境だけでなく、複合機（ＭＦＰ：Multifunction Peripheral）などの画像処理装置にも、動作環境の１つとして採用されている。例えば、次のような動作環境が構築されている。画像処理装置では、２つの仮想マシン環境が動作し、第１仮想マシン上で画像処理の主要機能を実行する。一方、第２仮想マシン上ではカスタマイズ機能を含む拡張機能を実行する。
【０００４】
このように、画像処理装置に仮想化技術を採用する理由には、画像処理に係る主要機能のロバストネス性を確保する点がある。
【０００５】
拡張機能を実現するソフトウェアには、サードベンダなどの他社が開発したものが含まれ、主要機能と異なり、他のソフトウェアとの協働など、何らかの原因で障害が発生する可能性がある。また、障害が発生しても、メーカが対応することができないため、障害対応に時間がかかってしまう恐れがある。このようなことから、画像処理装置では、主要機能と拡張機能とを異なる仮想マシン上で動作させることで、万が一、拡張機能に障害が発生した場合であっても、その障害が主要機能の処理に影響を及ぼすことがない動作環境の提供が望まれる。
【０００６】
ところで、近年の画像処理装置では、大画面の表示パネルに豊富な情報を表示することができる。例えば特許文献２には、ブラウザを用いて表示制御を行う画像処理装置が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の画像処理装置では、画面表示を行う際に、仮想マシン間の通信データ量や通信回数が多くなり、画面表示の遅延など、ユーザの使用感に悪影響を及ぼすことが考えられる。
【０００８】
複数の仮想マシンが構築された画像処理装置では、第１仮想マシンと第２仮想マシンとの間で通信を行い、あたかも単一の仮想マシンで動作しているかのように機能を実現している。このような環境下において画像処理装置では、画面更新などの表示制御を行う場合、仮想マシン間で更新情報を含むデータがやり取りされる。この更新情報は、情報量が多くなることがある。その結果、画像処理装置では、表示制御において仮想マシン間の通信データ量や通信回数の増大に繋がる。
【０００９】
本発明は上記従来技術の問題点を鑑み提案されたものであり、その目的とするところは、複数の仮想マシンが構築されたシステムにおいて、画面表示を高速化できる画像処理装置、表示制御方法、及び表示制御プログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明に係る画像処理装置は、当該画像処理装置の標準機能と前記標準機能を利用した拡張機能とが異なる第１及び第２仮想マシン上で動作する画像処理装置であって、
前記標準機能として表示画面の表示制御を実現する複数の動作モジュールと、
各仮想マシン上で動作し、前記複数の動作モジュールに対して共通の仮想マシン間通信を行う通信インタフェース部と、を有し、
前記拡張機能が動作する前記第２仮想マシン側の通信インタフェース部が、
前記拡張機能を実現するアプリケーションからの画面更新要求に応じて、前記アプリケーションの表示画面を制御する、表示制御コマンドを用いた表示制御データを生成する生成手段と、
前記生成手段により生成した表示制御データを、前記標準機能が動作する前記第１仮想マシンに送信するデータ送信手段と、を有し、
前記第１仮想マシン側の通信インタフェース部が、
前記第２仮想マシンから前記表示制御データを受信するデータ受信手段と、
前記データ受信手段により受信した表示制御データに従った表示制御の実行を、前記動作モジュールのうち、画面制御を行う画面制御モジュールに要求する要求手段と、を有し、
前記生成手段は、
前記表示画面を構成する表示部品の削除、追加、及び変更の各表示制御を指示する表示制御コマンドと、階層構造により表示画面を構成する表示部品を指定する表示部品識別子と、階層構造で親にあたる表示部品と子にあたる表示部品とを指定するためのセパレータとを含む、表示制御データを生成するように構成することができる。
【００１１】
このような構成によって、本発明に係る画像処理装置は、第２仮想マシン側において、画面更新要求に応じた表示画面を構成する表示部品の属性情報を取得し、取得した属性情報に基づき、表示制御用の独自コマンドを用いた表示制御データを生成する。画像処理装置は、生成した表示制御データを、表示画面を制御する画面制御モジュールが動作する第１仮想マシンに送信する。その結果、画像処理装置は、第１仮想マシン側において、画面制御モジュールを実行し、受信データに従った表示制御を行う。
【００１２】
これによって、本発明に係る画像処理装置は、表示制御における仮想マシン間の通信データ量を削減することができる。その結果、ユーザへの提供情報やＧＵＩ（Graphic User Interface）を高速表示できる（画面表示の高速化が図れる）。
【００１３】
上記目的を達成するため、本発明に係る表示制御方法は、画像処理装置の標準機能と前記標準機能を利用した拡張機能とが異なる第１及び第２仮想マシン上で動作する環境において、前記標準機能として表示画面の表示制御を実現する複数の動作モジュールと、各仮想マシン上で動作し、前記複数の動作モジュールに対して共通の仮想マシン間通信を行う通信インタフェース部と、を有する画像処理装置における表示制御方法であって、
前記拡張機能が動作する前記第２仮想マシン側の通信インタフェース部において、
前記拡張機能を実現するアプリケーションからの画面更新要求に応じて、前記アプリケーションの表示画面を制御する、表示制御コマンドを用いた表示制御データを生成する生成手順と、
前記生成手順により生成した表示制御データを、前記標準機能が動作する前記第１仮想マシンに送信するデータ送信手順と、を有し、
前記第１仮想マシン側の通信インタフェース部において、
前記第２仮想マシンから前記表示制御データを受信するデータ受信手順と、
前記データ受信手順により受信した表示制御データに従った表示制御の実行を、前記動作モジュールのうち、画面制御を行う画面制御モジュールに要求する要求手順と、を有し、
前記生成手順は、
前記表示画面を構成する表示部品の削除、追加、及び変更の各表示制御を指示する表示制御コマンドと、階層構造により表示画面を構成する表示部品を指定する表示部品識別子と、階層構造で親にあたる表示部品と子にあたる表示部品とを指定するためのセパレータとを含む、表示制御データを生成するように構成することができる。
【００１４】
このような手順によって、本発明に係る表示制御方法は、第２仮想マシン側で、表示画面を構成する表示部品の取得属性情報に基づき、表示制御データを生成し、表示制御データを、画面制御モジュールが動作する第１仮想マシンに送信し、第１仮想マシン側で画面制御モジュールを実行し、受信データに従った表示制御を行うと言う動作を実現する。
【００１５】
これによって、本発明に係る表示制御方法は、ユーザへの提供情報やＧＵＩの高速表示が可能な環境を提供できる。
【発明の効果】
【００１６】
本発明によれば、表示制御用の独自コマンドを用いて生成した表示制御データを、第２仮想マシンから第１仮想マシンに送信し、表示制御を要求することで、表示制御における仮想マシン間の通信データ量を削減し、複数の仮想マシンが構築されたシステムにおいて、高速な画面表示が可能な画像処理装置、表示制御信方法、及び表示制御プログラムを提供することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１の実施形態に係る画像処理装置のハードウェア構成例を示す図である。
【図２】本発明の第１の実施形態に係る複数の仮想マシンが構築されたシステム構成例を示す図である。
【図３】本発明の第１の実施形態に係る複数の仮想マシンが構築されたシステムのソフトウェア構成例を示す図である。
【図４】本発明の第１の実施形態に係るサブセットモジュールの機能構成例を示す図である。
【図５】本発明の第１の実施形態に係る表示部品の階層化例を示す図である。
【図６】本発明の第１の実施形態に係る表示制御のデータ例を示す図である。
【図７】本発明の第１の実施形態に係る表示制御を行う処理手順例（その１）を示すシーケンス図である。
【図８】本発明の第１の実施形態に係る表示制御を行う処理手順例（その２）を示すシーケンス図である。
【図９】本発明の第２の実施形態に係る複数の仮想マシンが構築されたシステムのソフトウェア構成例を示す図である。
【図１０】本発明の第２の実施形態に係るボタン画面の状態遷移を示す図である。
【図１１】本発明の第２の実施形態に係る表示制御を行う処理手順例（その１）を示すシーケンス図である。
【図１２】本発明の第２の実施形態に係る表示制御のデータ構造例を示す図である。
【図１３】本発明の第２の実施形態に係る表示部品情報のデータ例（その１）を示す図である。
【図１４】本発明の第２の実施形態に係る表示部品情報のデータ例（その２）を示す図である。
【図１５】本発明の第２の実施形態に係る表示部品情報のデータ例（その３）を示す図である。
【図１６】本発明の第２の実施形態に係る表示制御を行う処理手順例（その２）を示すシーケンス図である。
【図１７】本発明の変形例に係る複数の仮想マシンが構築されたシステムのソフトウェア構成例を示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明の好適な実施の形態（以下「実施形態」と言う）について、図面を用いて詳細に説明する。
【００１９】
［第１の実施形態］
＜ハードウェア構成＞
図１は、本実施形態に係る画像処理装置１００のハードウェア構成例を示す図である。
図１に示すように、画像処理装置１００は、コントローラ１１０、表示装置１２０、プロッタ１３０、及びスキャナ１４０などを備え、それぞれが相互にバスＢで接続されている。
【００２０】
表示装置１２０は、表示部に加えてタッチパネルなどの入力部を備えており、機器情報などの各種情報をユーザに提供したり、動作設定や動作指示などの各種ユーザ操作を受け付けたりする。プロッタ１３０は、画像形成部を備えており、用紙に出力画像を形成する。例えば出力画像を形成する方式には、電子写真方式やインクジェット方式などがある。スキャナ１４０は、原稿を光学的に読み取り、読み取り画像を生成する。
【００２１】
コントローラ１１０は、ＣＰＵ（Central Processing Unit）１１１、記憶装置１１２、ネットワークＩ／Ｆ１１３、及び外部記憶Ｉ／Ｆ１１４などを備えており、それぞれが相互にバスＢで接続されている。
【００２２】
ＣＰＵ１１１は、プログラムを実行することにより各種機能の実現や装置全体を制御する。また記憶装置１１２は、上記プログラムや各種データ（例えば「画像データ」）を格納し保持する。例えば記憶装置１１２には、揮発性のメモリであるＲＡＭ（Random Access Memory）、不揮発性のメモリであるＲＯＭ（Read Only Memory）、及び大容量の記憶領域を備えたＨＤＤ（Hard Disk Drive）などがある。ＲＡＭは、ＣＰＵ１１１のワークエリア（プログラムやデータが一時的に読み出される記憶エリア）として機能する。ＲＯＭやＨＤＤは、プログラムや各種データの格納先として用いられる。これにより、画像処理装置１００では、ＣＰＵ１１１がＲＯＭに格納されたプログラムをＲＡＭ上に読み出し、プログラムを実行する。
【００２３】
ネットワークＩ／Ｆ１１３は、画像処理装置１００をネットワークなどの所定のデータ伝送路に接続するためのインタフェースである。外部記憶Ｉ／Ｆ１１４は、外部記憶装置にあたる記録媒体１１４ａを接続するためのインタフェースである。例えば外部記憶装置には、ＳＤメモリカード（SD Memory Card）やＵＳＢ（Universal Serial Bus）メモリなどがある。これにより、画像処理装置１００は、外部記憶Ｉ／Ｆ１１４を介して、記録媒体１１４ａに格納されたプログラムやデータを読み取る。
【００２４】
画像処理装置１００では、上記ハードウェア構成により、例えばＨＤＤからＲＡＭ上に読み出したプログラムをＣＰＵ１１１により実行することで、１又は複数の仮想マシン環境を動作させることができる。
【００２５】
＜システム及びソフトウェア構成＞
図２は、本実施形態に係る複数の仮想マシンが構築されたシステム構成例を示す図である。
図２に示すように、画像処理装置１００では、表示装置１２０とコントローラ１１０とで異なるソフトウェアを有している。なお本実施形態では、表示装置１２０とコントローラ１１０とが異なる制御部（ＣＰＵ）を備えるハードウェア環境を想定している。
【００２６】
《表示装置》
表示装置１２０では、ＯＳ（Operating System）１０上でブラウザ１１、ＦｌａｓｈＰｌａｙｅｒ１２、及びソフトキーボード１３などの画面表示に係るアプリケーションが動作する。ＯＳ１０は、組み込み系の基本ソフトウェアであり、例えばＬｉｎｕｘ（登録商標：以下略）などがある。ブラウザ１１は、ＨＴＭＬ（HyperText Markup Language）などで記述されたＷｅｂコンテンツを閲覧するソフトウェアである。Ｆｌａｓｈ（商標：以下略）Ｐｌａｙｅｒ１２は、Ｗｅｂコンテンツの提供を可能にするクロスプラットフォーム対応のブラウザプラグインである。ソフトキーボード１３は、画面上からの文字入力などを支援するＧＵＩ（Graphical User Interface）ソフトウェアである。
【００２７】
以上のように、表示装置１２０では、上記ソフトウェア構成により、ユーザへの提供情報やＧＵＩを表示することができる。
【００２８】
《コントローラ》
図２には、画像処理装置１００が備えるコントローラ１１０（１台の物理コンピュータ）上に２つの仮想マシンが動作するシステム構成が示されている。
【００２９】
図２に示すように、仮想マシン環境は、ＯＳ２０上で仮想マシン環境を実現するプログラムを動作させることで実現される。本実施形態では、組み込み系システムの開発環境として使用頻度の高いＪａｖａ（登録商標：以下略）ＶＭ（Java Virtual Machine）２１を動作させることで実現している。なおＯＳ２０は、上記ＯＳ１０と同様に、組み込み系の基本ソフトウェアである。
【００３０】
複数の仮想マシン環境は、ＯＳ２０上で複数のＪａｖａＶＭ２１を動作させることで実現できる。本実施形態では、ＪａｖａＶＭ２１１及び２１２（２つのＪａｖａＶＭ２１）を動作させることで、第１及び第２仮想マシン環境（２つの仮想マシン環境）を実現している。以降では、ＪａｖａＶＭ２１１及び２１２を「第１仮想マシン２１１及び第２仮想マシン２１２」に置き換え説明する。また、第１仮想マシン２１１及び第２仮想マシン２１２を総称する際には、「仮想マシン２１」とする。同様に、各仮想マシン２１上で動作するソフトウェア（例えば「プログラム」や「データ」）及び使用される記憶領域についても、同じソフトウェア名や記憶領域名を総称する際には、共通する名称と参照符号を用いることとする。
【００３１】
仮想マシン２１は、仮想マシン２１上でＪａｖａコンポーネント２２を動作させるためのヒープメモリ２１１を有している。ヒープメモリ２１１は、仮想マシン２１上で動作するアプリケーションが自由に確保できるメモリ領域である。このように、複数の仮想マシン２１が構築されたシステムでは、仮想マシン２１ごとに独立したヒープメモリ２１１を有することから、処理停止などの障害が発生しても、互いのシステムに影響を及ぼすことがない。
【００３２】
仮想マシン２１上で動作するＪａｖａコンポーネント２２には、プラットフォーム及びアプリケーション（図中のＪａｖａプラットフォーム２２１及びＪａｖａアプリケーション２２２）の各機能を実現するための複数のＪａｖａプログラムが含まれる。Ｊａｖａプラットフォーム２２１は、仮想マシン２１が実現するシステム（動作環境）の標準機能として動作する。またＪａｖａアプリケーション２２２は、上記基本機能を利用し、例えばユーザが実行したい作業を実施する機能（仮想マシン環境におけるユーザ提供機能）として動作する。Ｊａｖａアプリケーション２２２は、提供する機能構成に応じてインストール／アンインストールが可能である。
【００３３】
以上のように、本実施形態に係る画像処理装置１００には、複数の仮想マシン２１が動作する環境を構築することができる。
【００３４】
次に、上記システムにおける詳細なソフトウェア構成について説明する。
図３は、本実施形態に係る複数の仮想マシン２１が構築されたシステムのソフトウェア構成例を示す図である。
【００３５】
例えば、上記システムが構築された画像処理装置１００が、ＭＦＰ（Multifunction Peripheral）であった場合、次のようなシステム構築が考えられる。
【００３６】
第１仮想マシン２１１では、プリンタ、スキャナ、ＦＡＸ（ファクシミリ）などの標準機能を動作させる。
【００３７】
第１仮想マシン２１１上で動作するＪａｖａコンポーネント２２１が有するＪａｖａアプリケーション２２２１は、標準アプリケーション２２２ａ１及びＳＤＫ（Software Development Kit）アプリケーション２２２ｂ１を含む。またＪａｖａプラットフォーム２２１１は、Ｊａｖａモジュール群（動作モジュール群）２２１ａ１及びＳＤＫ  ＡＰＩ（Application Program Interface）２２１ｂ１を含む。
【００３８】
標準アプリケーション２２２ａ１は、ＭＦＰ搭載の標準機能を利用したユーザ提供機能を実現するソフトウェアである。標準アプリケーション２２２ａ１は、標準機能として、プラットフォームが有するＪａｖａモジュール群２２１ａ１の動作モジュールを利用する。例えばＪａｖａモジュール群２２１ａ１には、プリンタ、スキャナ、及びＦＡＸなどの標準機能を実現する動作モジュール（非図示）が含まれる。これにより、例えば標準アプリケーション２２２ａ１は、Ｊａｖａモジュール群２２１ａ１のプリンタ及びスキャナの各動作モジュールを利用してコピー機能（コピーアプリ）を実現する。
【００３９】
またＪａｖａモジュール群２２１ａ１には、表示制御に係る標準機能を実現する動作モジュールとして、画面制御モジュール４２、ハードキーイベント配信モジュール４３、及びＬＥＤ（Light Emitting Diode）点灯モジュール４４が含まれる。画面制御モジュール４２は、画面生成や画面更新などの画面制御機能を実現する動作モジュールである。ハードキーイベント配信モジュール４３は、画像処理装置１００が備えるテンキー（非図示）などのハードキーから検出されたイベント（例えば「スタートキー押下時のイベント」）の配信機能を実現する動作モジュールである。なお配信機能とは、検出されたイベントを、イベントに従って動作する各種機能に通知するものである。ＬＥＤ点灯モジュール４４は、画像処理装置１００が備えるＬＥＤの点灯制御機能を実現する動作モジュールである。
【００４０】
このように、画像処理装置１００では、第１仮想マシン２１１側において、画面生成、画面更新、ハードキーイベント配信、ＬＥＤ点灯制御などの表示制御に係る各種機能が動作する。
【００４１】
ＳＤＫアプリケーション２２２ｂ１は、ソフトウェアを開発する際に使用できる命令や関数の集合であるＳＤＫ  ＡＰＩ２２１ｂ１を用いて開発され、ユーザへの個別対応機能（カスタマイズ機能）などを実現するソフトウェアである。ＳＤＫアプリケーション２２２ｂ１は、ＳＤＫ  ＡＰＩ２２１ｂ１を介して、プラットフォームが有するＪａｖａモジュール群２２１ａ１の動作モジュールを利用する。これにより、例えばＳＤＫアプリケーション２２２ｂ１は、ＳＤＫ  ＡＰＩ２２１ｂ１を介して、Ｊａｖａモジュール群２２１ａ１のプリンタモジュールを利用し、機能拡張による認証モジュールと合わせて印刷の利用認証機能（セキュアプリントアプリ）を実現する。
【００４２】
これに対して第２仮想マシン２１２では、標準機能を利用する拡張機能（例えば「サードベンダ提供機能」）を動作させる。
【００４３】
第２仮想マシン２１２上で動作するＪａｖａコンポーネント２２２が有するＪａｖａアプリケーション２２２２は、ＳＤＫアプリケーション２２２ｂ２を含み、Ｊａｖａプラットフォーム２２１２は、ＳＤＫ  ＡＰＩ２２１ｂ２を含む。
【００４４】
上述したように、ＳＤＫアプリケーション２２２ｂ２は、プラットフォームが有するＳＤＫ  ＡＰＩ２２１ｂ２を用いれば独自に開発できる。特に拡張機能を実現するＳＤＫアプリケーション２２２ｂ２は、サードベンダにより開発され提供されるソフトウェアである。サードベンダにより開発されたソフトウェアは、どのように設計・プログラミングされ、かつどのような工程を経て動作テストされ、提供されたものなのかを、知ることができない。そのため、動作中のメモリリークなど、予期せぬエラー（障害）が発生する恐れがある。
【００４５】
このような場合、ＳＤＫアプリケーション２２２ｂ２（拡張機能）を、標準アプリケーション２２２ａ１（標準機能）と同じ仮想マシン２１（第１仮想マシン２１１）上で動作させると、障害発生の影響からシステム全体を停止（システムダウン）させてしまう可能性がある。そのため、本実施形態では、ＭＦＰ搭載の標準機能と拡張機能とを異なる仮想マシン２１上で動作させることにより、たとえ拡張機能に何らかの障害が発生したとしても、ユーザに対して、標準機能のサービス提供を継続して行うことができる。
【００４６】
しかしこのようなシステム構成の場合、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２は、第１仮想マシン２１１上で動作するＪａｖａモジュール群２２１ａ１の動作モジュールとデータ通信（仮想マシン間通信）を行う必要がある。なぜなら、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２は、第１仮想マシン２１１上で動作する動作モジュール（標準機能を実現するモジュール）を利用して機能（拡張機能）を実現しているからである。
【００４７】
仮想マシン間通信への対応方法には、第２仮想マシン２１２上で、各動作モジュールに対応する通信モジュールを動作させる方法（動作モジュール単位で対応する方法）がある。しかし、システム規模が大きく、かつシステム内で多くの動作モジュールが協働する場合には、多くの通信モジュールを用意する必要があり、現実的な対応方法ではない。また、たとえ通信モジュールが用意できたとしても、障害が発生した場合など、その後のシステム管理・保守が煩雑となる。さらに、仮想マシン２１上で多くの通信モジュールを動作させなければならず、リソースを無駄に消費することとなる。
【００４８】
そこで本実施形態では、各仮想マシン２１に、仮想マシン２１間のデータ通信機能（仮想マシン間通信機能）を有するシステム全体のインタフェース部が設けられている。このインタフェース部が、各仮想マシン２１上で動作するＪａｖａプラットフォーム２２１が有するＪａｖａモジュール群２２１ａのサブセットモジュール（通信インタフェース部）４１である。各仮想マシン２１上では、１つのサブセットモジュール４１が動作する。
【００４９】
サブセットモジュール４１は、ＳＤＫアプリケーション２２２ｂから受け付けた機能実行要求に基づき、機能を実現するために連係する動作モジュールに対して処理の実行を要求する。またサブセットモジュール４１は、他の仮想マシンと機能実行要求を送受信し、他の仮想マシン上で動作する動作モジュールの実行を制御する。
【００５０】
このように、サブセットモジュール４１は、複数の動作モジュールに対して共通の通信インタフェースとして機能する。
【００５１】
第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２に係る表示制御処理には、第２仮想マシン２１２から第１仮想マシン２１１に処理を委譲する必要がある。
【００５２】
委譲が必要な処理には、画面生成、画面更新、ハードキーイベント配信、ＬＥＤ点灯制御などがある。上述したように、これらの処理は、表示制御に係る標準機能であり、第１仮想マシン２１１上で動作する。よって、画面生成、画面更新、ＬＥＤ点灯制御の場合には、第２仮想マシン２１２から第１仮想マシン２１１に対して制御要求を行う必要がある。またハードキーイベント配信の場合には、第１仮想マシン２１１から第２仮想マシン２１２に対して配信を行う必要がある。
【００５３】
具体的な表示制御処理の委譲は、次のように行われる。例えば、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２が、アプリ画面の更新を要求する場合の動作例を示す。ＳＤＫアプリケーション２２２ｂ２は、第２仮想マシン２１２側のサブセットモジュール４１２を介して、第１仮想マシン２１１側のサブセットモジュール４１１に対し、画面更新要求を行う。第１仮想マシン２１１側のサブセットモジュール４１１は、受け付けた画面更新要求に基づき、指定された画面制御モジュール４２に対して処理の実行を要求する。
【００５４】
このように、画像処理装置１００では、通信インタフェースであるサブセットモジュール４１を介して仮想マシン間通信を行い、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２からの表示制御処理を実行している。
【００５５】
なお、第２仮想マシン２１２側のサブセットモジュール４１２は、第２仮想マシン２１２上で動作するＪａｖａアプリケーション２２２がＳＤＫアプリケーション２２２ｂ２のみであることから、ＳＤＫ  ＡＰＩ２２１ｂ２のインスタンス（実値）及びＳＤＫアプリケーション２２２ｂ２の固有データを有している。
【００５６】
また図３に示すように、画像処理装置１００では、画面表示に係る各種画像データを保持するイメージリソース３１を有している。イメージリソース３１は、第１仮想マシン２１１及び第２仮想マシン２１２において、共通する画像データの記憶領域である。
【００５７】
ユーザに対して提供されるＧＵＩでは、ＷｉｎｄｏｗやＢｕｔｔｏｎなどの表示部品に画像データを用いる場合が多い。例えば、第２仮想マシン２１２上（第２仮想マシンが有する記憶領域）に、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２に係る表示部品の画像データを保持する構成としたとする。このような構成では、上記サブセットモジュール４１を介した表示制御処理を行うと、表示画面を構成するのに必要な画像データを、第２仮想マシン２１２から第１仮想マシン２１１に送信することとなる。そのため、仮想マシン間の通信データ量が多く、画面表示に係る時間（処理時間）の遅延につながり、ユーザの使用感に悪影響を及ぼすことが考えられる。
【００５８】
そこで、本実施形態では、表示部品として用いる画像データを展開（ロード）し、保持（キャッシュ）しておく、上記イメージリソース３１を有し、画面表示の高速化を図る。つまり、画像処理装置１００では、上記表示制御処理を行うときに、仮想マシン間における画像データの送受信を行わない構成とし、画面表示に係る時間の遅延を防ぐ。
【００５９】
イメージリソース３１は、例えば画像処理装置１００が備える記憶装置１１２（例えば「ＨＤＤ」）の所定の記憶領域である。画像データは、ＳＤＫアプリケーション２２２ｂがインストールされたときに、アプリ名称や製造番号ごとに展開され保持される。
【００６０】
これにより、画像処理装置１００では、第１仮想マシン２１１上で動作する画面制御モジュール４２が、イメージリソース３１にアクセスし、アプリ名称や製造番号などのＳＤＫアプリケーション２２２ｂを識別するアプリ識別情報に基づき、取得した画像データを用いてアプリ画面を表示する。
【００６１】
＜表示制御機能＞
ここからは、本実施形態に係る表示制御機能について説明する。
【００６２】
本実施形態に係る画像処理装置１００では、第２仮想マシン２１２側において、画面更新要求に応じた表示画面を構成する表示部品の属性情報を取得し、取得した属性情報に基づき、表示制御用の独自コマンド（以下「表示制御コマンド」と言う）を用いた表示制御データを生成する。画像処理装置１００は、生成した表示制御データを、表示画面を制御する画面制御モジュール４２が動作する第１仮想マシン２１１に送信する。その結果、画像処理装置１００は、第１仮想マシン２１１側において、画面制御モジュール４２を実行し、受信データに従った表示制御を行う。画像処理装置１００では、このような表示制御機能を有している。本実施形態に係る表示制御機能は、サブセットモジュール４１が仮想マシン２１上で動作することで実現される機能である。
【００６３】
上述したように、第２仮想マシン２１２から第１仮想マシン２１１に委譲する表示制御処理には、画面生成、画面更新、ハードキーイベント配信、及びＬＥＤ点灯制御などがある。
【００６４】
この中で、ハードキーイベント配信やＬＥＤ点灯制御の処理では、仮想マシン間において、配信時のハードキー情報や点灯要求時の指定ＬＥＤ情報が、第２仮想マシン２１２から第１仮想マシン２１１に送信されるだけであり、送受信されるデータ量は少ない。また画面生成の処理でも、生成要求時のアプリ識別情報が、第２仮想マシン２１２から第１仮想マシン２１１に送信されるだけであり、送受信されるデータ量は少ない。
【００６５】
しかし、画面更新の処理では、例えば表示画面全体の切り替え処理など、仮想マシン間において、多くの表示部品情報が、第２仮想マシン２１２から第１仮想マシン２１１に送信されることになる。また仮想マシン間通信には、例えばＲＭＩ（Remote Method Invocation API）通信があるが、ＲＭＩ通信では、Ｊａｖａのインスタンス（実値）が送受信される場合が多く、画面制御に不必要なデータが含まれる。さらに、画面更新の処理は、上記画面生成、ハードキーイベント配信、ＬＥＤ点灯制御の各処理に比べて、実行頻度が高い。
【００６６】
そのため、通常の仮想マシン間通信では、通信データ量が多く、画面表示に係る時間（処理時間）の遅延につながる。
【００６７】
そこで、本実施形態に係る画像処理装置１００では、画面更新時の通信データ量を削減することを目的とした表示制御用の独自コマンドを用いて表示制御データを生成し、第２仮想マシン２１２から第１仮想マシン２１１に送信することで、表示制御を要求する。
【００６８】
これによって、画像処理装置１００では、表示制御における仮想マシン間の通信データ量を削減することができる。その結果、ユーザへの提供情報やＧＵＩを高速表示できる（画面表示の高速化が図れる）。
【００６９】
以下に、上記表示制御機能の構成とその動作について説明する。なお以降では、サブセットモジュール４１が有する各機能部（表示制御機能を実現する機能部）について、同じ機能部名を総称する際には、共通する名称と参照符号を用いることとする。
図４は、本実施形態に係るサブセットモジュール４１の機能構成例を示す図である。（Ａ）には、第１仮想マシン２１１上で動作するサブセットモジュール４１１の機能構成、また（Ｂ）には、第２仮想マシン２１２上で動作するサブセットモジュール４１２の機能構成例が示されている。
【００７０】
まず、図４に示すように、サブセットモジュール４１は、第１仮想マシン２１１及び第２仮想マシン２１２において、共通する通信部５１を有している。
【００７１】
通信部５１は、仮想マシン間通信を行う機能部である。よって、通信部５１は、仮想マシン間でデータを送信する送信部５１１、及び仮想マシン間でデータを受信する受信部５１２を有している。
【００７２】
例えば第１仮想マシン２１１側の送信部５１１１は、第１仮想マシン２１１側で動作するハードキーイベント配信モジュール４３からハードキー押下時のイベント通知を受け付けると、イベント通知に基づき、ハードキー情報を第２仮想マシン２１２に対して送信する。送信されたハードキー情報は、第２仮想マシン２１２側の受信部５１２２により受信される。これにより、画像処理装置１００では、第１仮想マシン２１１から第２仮想マシン２１２に、ハードキーイベント配信処理を委譲する。
【００７３】
一方、第２仮想マシン２１２側の送信部５１１２は、第２仮想マシン２１２側でＳＤＫアプリケーション２２２ｂ２からのＬＥＤの点灯要求を受け付けると、要求に基づき、指定ＬＥＤ情報を第１仮想マシン２１１に対して送信する。送信された指定ＬＥＤ情報は、第１仮想マシン２１１側の受信部５１２１により受信される。これにより、画像処理装置１００では、第２仮想マシン２１２から第１仮想マシン２１１に、ＬＥＤ点灯処理を委譲する。
【００７４】
また送信部５１１２は、第２仮想マシン２１２側でＳＤＫアプリケーション２２２ｂ２からのアプリ画面の生成要求を受け付けると、要求に基づき、アプリ識別情報を第１仮想マシン２１１に対して送信する。送信されたアプリ識別情報は、第１仮想マシン２１１側の受信部５１２１により受信される。これにより、画像処理装置１００では、第２仮想マシン２１２から第１仮想マシン２１１に、画面生成処理を委譲する。
【００７５】
また送信部５１１２は、アプリ画面の更新要求に従って後述する表示制御データ生成部５３２により画面更新を指示する表示制御データが生成されると、生成された表示制御データを第１仮想マシン２１１に対して送信する。送信された表示制御データは、第１仮想マシン２１１側の受信部５１２１により受信される。これにより、画像処理装置１００では、第２仮想マシン２１２から第１仮想マシン２１１に、画面更新処理を委譲する。
【００７６】
次に、図４（Ａ）に示すように、第１仮想マシン２１１上で動作するサブセットモジュール４１１は、処理要求部５２１を有している。
【００７７】
処理要求部５２１は、第１仮想マシン２１１上で動作する動作モジュールに対して、処理の実行を要求する機能部である。処理要求部５２１は、受信部５１２１で受信した処理要求に従って処理の実行を要求する。
【００７８】
例えば受信部５１２１で、ＬＥＤの点灯要求を受け付けた場合、処理要求部５２１は、第１仮想マシン２１１上で動作するＬＥＤ点灯モジュール４４に対して、要求時の指定ＬＥＤ情報に基づくＬＥＤ点灯処理の実行を要求する。また受信部５１２１で、アプリ画面の生成要求を受け付けた場合、処理要求部５２１は、第１仮想マシン２１１上で動作する画面制御モジュール４２に対して、要求時のアプリ識別情報に基づく画面生成処理の実行を要求する。また受信部５１２１で、アプリ画面の更新要求を受け付けた場合、処理要求部５２１は、第１仮想マシン２１１上で動作する画面制御モジュール４２に対して、要求時の表示制御データに基づく画面更新処理の実行を要求する。
【００７９】
次に、図４（Ｂ）に示すように、第２仮想マシン２１２上で動作するサブセットモジュール４１２は、表示制御データ生成部５３２及び情報取得部５４２を有している。
【００８０】
表示制御データ生成部５３２は、通信データ量を削減することを目的とした表示制御用の独自コマンドを用いて表示制御データを生成する機能部である。表示制御データ生成部５３２は、画面更新要求に応じたアプリ画面を構成する表示部品の属性情報に基づき、表示制御データを生成する。
【００８１】
情報取得部５４２は、ＳＤＫアプリケーション２２２ｂ２から、アプリ画面を構成する表示部品の属性情報を取得する機能部である。表示部品の属性情報には、例えば配置位置（配置座標）、見た目（例えば「色」や「大きさ」）、及び動作（例えば「クリックアクション」）
などがある。
【００８２】
ＳＤＫアプリケーション２２２ｂ２は、イベント通知を受け付けたときなど、アプリ画面を更新する必要がある。そこで、通信部５１２では、第１仮想マシン２１１から委譲された表示制御処理に応じて、ＳＤＫアプリケーション２２２ｂ２のアプリ画面を更新する必要があるか否かを判断する。本実施形態では、ハードキーイベント配信処理が委譲された場合、ハードキー情報を基にアプリ画面更新の要否を判断している。アプリ画面更新の要否判定は、ハードキー情報の他にも、ブラウザ１１やソフトキーボード１３を介した各種入力操作イベントなど操作イベント情報を基に行ってもよい。
【００８３】
通信部５１２は、アプリ画面の更新が必要と判断すると、情報取得部５４２に、表示部品に係る属性情報の取得を要求する。情報取得部５４２は、取得した属性情報を表示制御データ生成部５３２へと渡し、表示制御データの生成を要求する。
【００８４】
以下に、表示制御データ生成部５３２により生成される表示制御データについて説明する。
【００８５】
図５は、本実施形態に係る表示部品Ｐの階層化例を示す図である。
ここで、表示画面を構成する表示部品Ｐの構成について説明する。表示画面は、ＳＤＫアプリケーション２２２ｂがＳＤＫ  ＡＰＩ２２１ｂを用いて形成する。図５に示すように、形成された表示画面は、複数種の表示部品Ｐ１〜Ｐ８により構成される。よって、ＳＤＫアプリケーション２２２ｂは、これらの表示部品Ｐを所定のレイアウトに従って、背面から最前面に向かって順に重畳することで、アプリ画面を形成する。本実施形態に係る表示部品Ｐは、表示画面形成の特性に基づき、階層構造を有している。
【００８６】
図５には、背面に位置する表示部品Ｐの階層を第１階層とし、最前面に位置する表示部品Ｐの階層を第４階層とする階層化例が示されている。例えば、このような階層構造の場合、ＦｒａｍｅＰ１上に、ＬａｂｅｌＰ２、ＩｃｏｎＰ３、ＷｉｎｄｏｗＰ４をレイアウトできる。またＷｉｎｄｏｗＰ４上には、ＬａｂｅｌＡｒｅａＰ５及びＤｉａｌｏｇＰ６をレイアウトできる。さらにＤｉａｌｏｇＰ６上には、ＢｕｔｔｏｎＰ７及びＰａｔｔｅｒｎＰ８をレイアウトできる。つまり、階層構造上、親にあたる表示部品Ｐには、子にあたる１又は複数の表示部品Ｐをレイアウトすることができる。
【００８７】
このように、本実施形態は、上記階層構造により、表示画面を構成する表示部品Ｐを互いに関連付けることができる。
【００８８】
図６は、本実施形態に係る表示制御のデータ例を示す図である。
表示制御データ生成部５３２は、図６に示すような表示制御データ６０を生成する。表示制御データ６０は、「削除」、「追加」、及び「変更」と言った表示制御を指示する表示制御コマンドと、制御対象である表示部品Ｐの表示部品データとを含む。また表示部品データでは、所定のセパレータ「＠＃」及び「＃＠」を用いて、階層構造で親にあたる表示部品Ｐと、子にあたる１又は複数の表示部品Ｐを指定できる。
【００８９】
例えば、画面更新時における表示部品Ｐの「削除」、「追加」、及び「変更」を制御するデータ例は、以下の通りである。
●表示部品を削除する場合
delete ＠＃sep＃＠［親の表示部品識別子］＠＃sep＃＠［削除する表示部品識別子］
●表示部品を追加する場合
add ＠＃sep＃＠［親の表示部品識別子］＠＃sep＃＠［追加する表示部品識別子］＠＃sep＃＠［追加する表示部品の内容］
●表示部品を変更する場合
change ＠＃sep＃＠［親の表示部品識別子］＠＃sep＃＠［変更する表示部品識別子］＠＃sep＃＠［変更する表示部品の内容］
上記表示部品識別子とは、ＳＤＫアプリケーション２２２ｂ２がアプリ画面を形成するときに割り当てられる、各表示部品Ｐを一意に特定可能な識別情報（ＩＤ）である。
【００９０】
また上記追加・変更する表示部品の内容とは、図６に示す追加・変更時の表示制御データ例のように、追加・変更する表示部品Ｐの配置位置、見た目、及び動作などを含む詳細情報である。
【００９１】
このように、本実施形態では、画面更新時の仮想マシン間における通信データ量を削減するために、表示制御データ６０を表示制御に最低限必要なデータで構成する。
【００９２】
また、本実施形態では、制御対象の表示部品Ｐを、階層構造上の親子関係により指定する。これにより、次のような表示制御処理が可能になる。
【００９３】
例えば表示部品Ｐを削除する場合には、削除対象の表示部品Ｐ上にレイアウトされた複数の表示部品Ｐ（子にあたる表示部品）を１つずつ削除指定する必要がない。表示制御コマンド６０により、削除対象の表示部品Ｐを指定するだけで、親子関係により、子にあたる全ての表示部品Ｐも削除できる。
【００９４】
さらに、表示制御データ６０では、所定のセパレータ「；＿；」を用いて表示制御コマンドを区切り、複数の画面更新の要求を可能としている。
【００９５】
例えば、画面更新時における表示部品Ｐの「削除」及び「追加」を制御するデータ例は、以下の通りである。
●表示部品を削除後に新たに追加する場合
delete ＠＃sep＃＠…＠＃sep＃＠…;_;add ＠＃sep＃＠…＠＃sep＃＠…
このように、本実施形態では、画面更新時に係る表示制御処理要求を一括して行うために、表示制御データ６０内に複数個の表示制御コマンドを含むデータで構成する。
【００９６】
表示制御データ生成部５３２は、画面更新内容に応じて、表示制御データ６０内で用いる表示制御コマンドを決定する。次に表示制御データ生成部５３２は、上記階層構造に基づき、所定のセパレータを用いて制御対象の表示部品Ｐ及び親にあたる表示部品Ｐそれぞれの表示部品識別子を指定する。このとき表示制御データ生成部５３２は、画面更新時の表示制御に「追加」又は「変更」が指定されている場合、情報取得部５４２によりＳＤＫアプリケーション２２２ｂ２から取得した表示部品Ｐの属性情報に基づき、制御対象の表示部品Ｐの内容（詳細情報）を付加する。表示制御データ生成部５３２は、このようにして上記データ構成の表示制御データ６０を生成する。
【００９７】
以上のように、本実施形態に係る表示制御機能は、上記各機能部が連係動作することにより実現される。
【００９８】
次に、表示制御機能の詳細な動作（機能部群の連係動作）について、処理手順を示すシーケンス図を用いて説明する。
【００９９】
表示制御機能は、画像処理装置１００に搭載（インストール）される表示制御プログラムが、ＣＰＵ１１１により、格納先（例えば「ＲＯＭ」）からＲＡＭ上に読み出され、以下の処理が実行されることで実現される。なお以降には、表示制御処理の中でも、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面を生成する処理（処理１）、及びボタン押下時におけるＳＤＫアプリケーション２２２ｂ２のアプリ画面を更新する処理（処理２）を例に説明する。
【０１００】
《処理１》
図７は、本実施形態に係る表示制御を行う処理手順例（その１）を示すシーケンス図である。
【０１０１】
図７に示すように、画像処理装置１００では、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面を生成する場合、以下の表示制御処理が実行される。
【０１０２】
第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２は、ＳＤＫ  ＡＰＩ２２１ｂ２を用いてアプリ画面を生成する（ステップＳ１０１）。
【０１０３】
ＳＤＫ  ＡＰＩ２２１ｂ２は、同仮想マシン２１２上で動作するサブセットモジュール４１２にアプリ画面生成要求を通知する（ステップＳ１０２）。このとき、ＳＤＫ  ＡＰＩ２２１ｂ２は、生成要求時にＳＤＫアプリケーション２２２ｂ２から指定されたアプリ識別情報を含む各種パラメータ（以下「画面生成情報」と言う）をサブセットモジュール４１２に渡す。
【０１０４】
サブセットモジュール４１２は、アプリ画面生成要求通知を受け付けると、通信部５１２により、第１仮想マシン２１１上で動作するサブセットモジュール４１１と仮想マシン間通信を行い、アプリ画面の生成処理を第１仮想マシン２１１側に委譲する（ステップＳ１０３）。このとき、サブセットモジュール４１２は、通信部５１２が有する送信部５１１２により、画面生成情報を、アプリ画面の生成処理を行う画面制御モジュール４２に指定可能な値に変換し、送信する。これにより、第２仮想マシン２１２からアプリ画面の生成処理を要求する。その結果、サブセットモジュール４１１は、第２仮想マシン２１２上で動作するサブセットモジュール４１２から送信された変換後の画面生成情報を、通信部５１１が有する受信部５１２１により受信する。これにより、第１仮想マシン２１１でアプリ画面生成要求を受け付ける。
【０１０５】
サブセットモジュール４１１は、アプリ画面生成要求を受け付けると、通信部５１１が有する受信部５１２１から処理要求部５２１に、アプリ画面の描画要求が通知される（ステップＳ２０１）。このとき、受信部５１２１は、生成要求時の変換後の画面生成情報を処理要求部５２１に渡す。
【０１０６】
処理要求部５２１は、変換後の画面生成情報に基づくアプリ画面生成処理の実行（アプリ画面の描画）を、画面制御モジュール４２に要求する（ステップＳ２０２）。このとき、処理要求部５２１は、アプリ識別情報を含む変換後の各種パラメータ（画面生成情報）を、画面制御モジュール４２の実行パラメータとして設定し、アプリ画面生成処理の実行を要求する。
【０１０７】
画面制御モジュール４２は、設定されたパラメータに基づき、画像処理装置１００が備える表示装置１２０の表示画面に対して、アプリ画面の生成処理（アプリ画面の描画）を実行する（ステップＳ２０３）。アプリ画面生成処理では、もしアプリ画面を構成する表示部品Ｐに画像データを用いる場合、イメージリソース３１にアクセスし、アプリ識別情報に基づき、該当画像データを取得する。
【０１０８】
表示装置１２０では、このようにしてアプリ画面が描画される（ステップＳ２０４）。また表示装置１２０からは、アプリ画面生成処理の実行結果が、画面制御モジュール４２を介して処理要求部５２１へと応答される。
【０１０９】
以上のように、画像処理装置１００では、サブセットモジュール４１を用いた仮想マシン間通信により、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面生成処理を第１仮想マシン２１１へと委譲し、表示画面を生成する。
【０１１０】
《処理２》
図８は、本実施形態に係る表示制御を行う処理手順例（その２）を示すシーケンス図である。
【０１１１】
図８に示すように、画像処理装置１００では、ボタン押下時におけるＳＤＫアプリケーション２２２ｂ２のアプリ画面を更新する場合、以下の表示制御処理が実行される。
【０１１２】
表示装置１２０では、ハードキーのボタン押下が検出される（ステップＳ３０１）。検出されたボタン押下の検出信号は、第１仮想マシン２１１上で動作するハードキーイベント配信モジュール４３に渡され、ハードキーイベント配信モジュール４３からハードキーイベントがサブセットモジュール４１１に通知される（ステップＳ３０２）。このとき、ハードキーイベント配信モジュール４３は、検出信号に基づき、ハードキー情報や操作イベント情報を発行し、サブセットモジュール４１１に通知する。サブセットモジュール４１１は、通信部５１１により、これらの情報をイベント通知として受け取る。
【０１１３】
サブセットモジュール４１１は、イベント通知を受け取ると、通信部５１１により、第２仮想マシン２１２上で動作するサブセットモジュール４１２と仮想マシン間通信を行い、ボタン押下時の処理を第２仮想マシン２１２側に委譲する（ステップＳ３０３）。このとき、サブセットモジュール４１１は、通信部５１１が有する送信部５１１１により、ハードキー情報や操作イベント情報を送信する。これにより、第１仮想マシン２１１からボタン押下時の処理を要求する。その結果、サブセットモジュール４１２は、第１仮想マシン２１１上で動作するサブセットモジュール４１１から送信された、ハードキー情報や操作イベント情報を、通信部５１２が有する受信部５１２２により受信する。これにより、第２仮想マシン２１２でボタン押下処理要求を受け付ける。
【０１１４】
サブセットモジュール４１２は、ボタン押下処理要求を受け付けると、通信部５１２が有する受信部５１２２からＳＤＫ  ＡＰＩ２２１ｂ２に、ボタン押下時の処理要求が通知される（ステップＳ４０１）。このとき、受信部５１２２は、処理要求時のハードキー情報や操作イベント情報をＳＤＫ  ＡＰＩ２２１ｂ２に渡す。
【０１１５】
ＳＤＫ  ＡＰＩ２２１ｂ２は、ボタン押下処理の実行を、ＳＤＫアプリケーション２２２ｂ２に要求する（ステップＳ４０２）。このとき、ＳＤＫ  ＡＰＩ２２１ｂ２は、ハードキー情報や操作イベント情報を、ＳＤＫアプリケーション２２２ｂ２に渡し、ボタン押下処理の実行を要求する。
【０１１６】
ＳＤＫアプリケーション２２２ｂ２では、このようにしてボタン押下処理が実行される（ステップＳ４０３）。またＳＤＫアプリケーション２２２ｂ２からは、ボタン押下処理の実行結果が、ＳＤＫ  ＡＰＩ２２１ｂ２へと応答される。
【０１１７】
またサブセットモジュール４１２は、ボタン押下処理要求を受け付けると、通信部５１２が有する受信部５１２２から情報取得部５４２に、ボタン押下による画面更新後のアプリ画面を構成する表示部品Ｐに係る属性情報の取得が要求される（ステップＳ４０４）。
【０１１８】
情報取得部５４２は、属性情報取得要求を受け付けると、ＳＤＫ  ＡＰＩ２２１ｂ２を介して、ＳＤＫアプリケーション２２２ｂ２から表示部品Ｐに係る属性情報を取得する（ステップＳ４０５〜Ｓ４０７）。
【０１１９】
情報取得部５４２は、画面更新における表示制御データ６０の生成を、サブセットモジュール４１２が有する表示制御データ生成部５３２に要求する（ステップＳ４０８）。このとき、情報取得部５４２は、取得した属性情報を表示制御データ生成部５３２に渡し、表示制御データ６０の生成を要求する。
【０１２０】
表示制御データ生成部５３２は、データ生成要求を受け付けると、表示部品Ｐに係る属性情報及び画面更新内容に基づき、表示制御データ６０を生成する（ステップＳ４０９）。このとき、表示制御データ生成部５３２は、画面更新内容に応じて、表示制御コマンドを決定し、制御対象の表示部品Ｐの表示部品識別子を指定する。さらに、表示制御データ生成部５３２は、画面更新時の表示制御に「追加」又は「変更」が指定されている場合、表示部品Ｐの属性情報に基づき、制御対象の表示部品Ｐの内容を付加する。
【０１２１】
表示制御データ生成部５３２は、同仮想マシン２１２上で動作するサブセットモジュール４１２に、生成した表示制御データ６０の送信要求を通知する（ステップＳ４１０）。このとき、表示制御データ生成部５３２は、生成した表示制御データ６０をサブセットモジュール４１２に渡す。
【０１２２】
サブセットモジュール４１２は、表示制御データ送信要求通知を受け付けると、通信部５１２により、第１仮想マシン２１１上で動作するサブセットモジュール４１１と仮想マシン間通信を行い、アプリ画面の更新処理を第１仮想マシン２１１側に委譲する（ステップＳ４１１）。このとき、サブセットモジュール４１２は、通信部５１２が有する送信部５１１２により、表示制御データ６０を送信する。これにより、第２仮想マシン２１２からアプリ画面の更新処理を要求する。その結果、サブセットモジュール４１１は、第２仮想マシン２１２上で動作するサブセットモジュール４１２から送信された、表示制御データ６０を、通信部５１１が有する受信部５１２１により受信する。これにより、第１仮想マシン２１１でアプリ画面更新要求を受け付ける。
【０１２３】
サブセットモジュール４１１は、アプリ画面更新要求を受け付けると、通信部５１１が有する受信部５１２１から処理要求部５２１に、アプリ画面の描画要求が通知される（ステップＳ５０１）。このとき、受信部５１２１は、更新要求時の表示制御データ６０を処理要求部５２１に渡す。
【０１２４】
処理要求部５２１は、表示制御データ６０に基づくアプリ画面更新処理の実行（アプリ画面の再描画）を、画面制御モジュール４２に要求する（ステップＳ５０２）。このとき、処理要求部５２１は、表示制御データ６０のデータ解析結果に基づき、画面制御モジュール４２の実行パラメータを設定し、アプリ画面更新処理の実行を要求する。
【０１２５】
画面制御モジュール４２は、設定されたパラメータに基づき、画像処理装置１００が備える表示装置１２０の表示画面に対して、アプリ画面の更新処理（アプリ画面の再描画）を実行する（ステップＳ５０３）。
【０１２６】
表示装置１２０では、このようにしてアプリ画面が再描画され更新される（ステップＳ５０４）。また表示装置１２０からは、アプリ画面更新処理の実行結果が、画面制御モジュール４２を介して処理要求部５２１へと応答される。
【０１２７】
以上のように、画像処理装置１００では、サブセットモジュール４１を用いた仮想マシン間通信により、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面更新処理を第１仮想マシン２１１へと委譲し、表示画面を更新する。
【０１２８】
＜まとめ＞
以上のように、本実施形態に係る画像処理装置１００によれば、第２仮想マシン２１２側において、画面更新要求に応じた表示画面を構成する表示部品Ｐの属性情報を取得し、取得した属性情報に基づき、表示制御用の独自コマンド（表示制御コマンド）を用いた表示制御データ６０を生成する。画像処理装置１００は、生成した表示制御データ６０を、表示画面を制御する画面制御モジュール４２が動作する第１仮想マシン２１１に送信する。その結果、画像処理装置１００は、第１仮想マシン２１１側において、画面制御モジュール４２を実行し、受信データに従った表示制御を行う。
【０１２９】
これによって、画像処理装置１００は、表示制御における仮想マシン間の通信データ量を削減することができる。その結果、ユーザへの提供情報やＧＵＩを高速表示できる（画面表示の高速化が図れる）。
【０１３０】
［第２の実施形態］
本実施形態では、表示画面を制御する画面制御モジュールにサーブレットを用いる。これにより、上記実施形態と同様、表示制御における仮想マシン間の通信データ量を削減する。なお本実施形態の説明では、上記実施形態と同様の点に対し、同一の参照符号を付し、その説明を省略する。
【０１３１】
＜ソフトウェア構成＞
図９は、本実施形態に係る複数の仮想マシンが構築されたシステムのソフトウェア構成例を示す図である。
【０１３２】
図９に示すように、本実施形態では、画像制御モジュール４２にサーブレット４５を用いる構成例が示されている。サーブレット４５とは、ＨＴＭＬ文書などのＷｅｂコンテンツを動的に生成するプログラム（Ｊａｖａクラス）である。サーブレット４５は、Ｗｅｂサーバ上で動作し、ブラウザ１１からＨＴＴＰリクエストにより要求されると、Ｗｅｂコンテンツを動的に生成し応答する。
【０１３３】
このように、本実施形態では、サーブレット４５により、ブラウザ１１を介して表示画面を提供する。具体的には、ＡＷＴ（Abstract Windowing Tools）互換の形式でＪａｖａのＧＵＩ作成インタフェースを提供するプラットフォームにおいて、アプレット（Applet）などを用いずに、表示部品ＰをＨＴＭＬ形式に変換してブラウザ１１で表示する。なお上記ＡＷＴとは、ＪａｖａでＧＵＩを実装するために用いられるクラスライブラリの名称である。
【０１３４】
表示画面の提供にブラウザ１１を用いるメリットは、次の通りである。
例えば、第１の実施形態で示した表示制御データ６０では、表示部品Ｐに係る詳細情報としてＨＴＭＬデータを用いている。従来のＡＷＴ形式で表示画面の描画を行う場合では、画面描画を行う第１仮想マシン２１１に、ＡＷＴ形式の表示部品Ｐのインスタンス（実値）を複製する必要があり、画面表示に係るデータが冗長となる。また、仮想マシン間通信で送受信されるデータも、ＡＷＴ形式のオブジェクトとなるため、通信データ量が多くなってしまう。
【０１３５】
これに対して、ブラウザ１１では、画面表示に係るデータとしてＨＴＭＬデータを用いることから、画面表示のために扱うデータ量を削減できる。
【０１３６】
また、近年では、ブラウザ１１で用いる技術としてＡｊａｘ（Asynchronous JavaScript + XML）が知られている。Ａｊａｘは、ブラウザ１１内で非同期通信とインタフェースの構築などを行う技術であり、特に、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔでの非同期通信（メッセージ交換）を特徴としている。そのため、Ａｊａｘを用いれば、仮想マシン間での表示制御データ６０を、ブラウザ１１に対して非同期で送受信することができ、表示制御処理では、表示画面を部分的に更新するだけでよい。その結果、さらなる画面表示の高速化を図ることができる。
【０１３７】
さらに本実施形態では、上記ソフトウェア構成により、例えば表示画面上のボタンが押下されたときの表示制御処理（ボタン画像の更新処理）を、ブラウザ１１上で動作するＪａｖａスクリプトで実現することができる。つまり、ボタン押下時の表示制御処理では、仮想マシン間で通信を行わなくてもよい。その結果、表示制御における通信回数を削減することができる。
【０１３８】
具体的には、次の通りである。なお、以下の説明では、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面に、ボタンがレイアウトされている場合を例に説明する。
【０１３９】
ＳＤＫアプリケーション２２２ｂ２がアプリ画面の生成を要求する場合には、第２仮想マシン２１２から第１仮想マシン２１１に、サブセットモジュール４１を介して、画面生成要求用の表示制御データが送信される。第１仮想マシン２１１上で動作するサブセットモジュール４１１は、表示制御データを受信し、サーブレット４５を介して、受信データに基づきブラウザ１１にアプリ画面を表示する。
【０１４０】
そこで、本実施形態では、第２仮想マシン２１２から第１仮想マシン２１１に送信される表示制御データとして、予め、以下の情報を有するＪａｖａスクリプトがＨＴＭＬデータと共に送信される。
・カーソルがボタン上にないときのボタン画像を描画する手続き
・カーソルがボタン上にあるときのボタン画像を描画する手続き
・ボタン押下時のボタン画像を描画する手続き
・ボタン押下時にサーブレットにイベントを通知する手続き
図１０は、本実施形態に係るボタン画面の状態遷移を示す図である。
図１０に示すように、ｎｏｒｍａｌ  Ｂｕｔｔｏｎは、カーソルがボタン上にない状態である（ＳＴ１）。また、Ｂｕｔｔｏｎ  ｄｏｗｎは、カーソルがボタン上にあるときの状態である（ＳＴ２）。また、Ｂｕｔｔｏｎ  ｏｎは、ボタンが押下されたときの状態である（ＳＴ３）。ＳＴ１からＳＴ３への状態遷移では、上記Ｊａｖａスクリプト（描画手続き）により、ボタン画像の変換を行う。
【０１４１】
また、ｅｖｅｎｔ  ｒｅｓｐｏｎｓｅは、ボタンが押下されたとき（Ｏｎｃｌｉｃｋ）の状態である（ＳＴ４）。ＳＴ２からＳＴ４への状態遷移では、上記Ｊａｖａスクリプトにより、ボタン画像の変更とサーブレット４５へのイベント通知（ＯｎＥｖｅｎｔ）が行われる。図１０には、ボタン押下時に画面遷移することにより、サーブレット４５に対して画面描画を命令する例が示されているが、この限りでない。ボタン画像の更新については、逐次、サーブレット４５にＨＴＭＬデータ要求などの命令を送信する必要はない。
【０１４２】
＜表示制御機能＞
ここからは、本実施形態に係る表示制御機能について説明する。
【０１４３】
本実施形態に係る画像処理装置１００が有する表示制御機能は、サブセットモジュール４１が仮想マシン２１上で動作することで実現される機能であり、第１の実施形態において説明を行った構成である。よって、機能構成の詳細については説明を省略し、表示制御機能の詳細な動作（機能部群の連係動作）について、処理手順を示すシーケンス図を用いて説明する。
【０１４４】
表示制御機能は、画像処理装置１００に搭載（インストール）される表示制御プログラムが、ＣＰＵ１１１により、格納先（例えば「ＲＯＭ」）からＲＡＭ上に読み出され、以下の処理が実行されることで実現される。なお以降には、表示制御処理の中でも、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面を生成する処理（処理１）、及びボタン押下時におけるＳＤＫアプリケーション２２２ｂ２のアプリ画面を更新する処理（処理２）を例に説明する。
【０１４５】
《処理１》
図１１は、本実施形態に係る表示制御を行う処理手順例（その１）を示すシーケンス図である。
【０１４６】
図１１に示すように、画像処理装置１００では、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面を生成する場合、以下の表示制御処理が実行される。
【０１４７】
第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２は、ＳＤＫ  ＡＰＩ２２１ｂ２を用いてアプリ画面を生成する（ステップＳ６０１）。
【０１４８】
ＳＤＫ  ＡＰＩ２２１ｂ２は、同仮想マシン２１２上で動作するサブセットモジュール４１２にアプリ画面生成要求を通知する（ステップＳ６０２）。このとき、ＳＤＫ  ＡＰＩ２２１ｂ２は、生成要求時にＳＤＫアプリケーション２２２ｂ２から受け取った、アプリ画面を構成する表示部品Ｐに係る属性情報をサブセットモジュール４１２に渡す。
【０１４９】
サブセットモジュール４１２は、アプリ画面生成要求通知を受け付けると、通信部５１２が、画面生成における表示制御データ６０の生成を、サブセットモジュール４１２が有する表示制御データ生成部５３２に要求する（ステップＳ６０３）。このとき、通信部５１２は、受け取った属性情報を表示制御データ生成部５３２に渡し、表示制御データ６０の生成を要求する。
【０１５０】
表示制御データ生成部５３２は、データ生成要求を受け付けると、表示部品Ｐに係る属性情報及び画面生成内容に基づき、表示制御データ６０を生成する（ステップＳ６０４）。このとき、表示制御データ生成部５３２は、表示制御データ６０として、表示制御処理を実行するＪａｖａスクリプトを含む、表示画面のレイアウトが定義されるＨＴＭＬデータを生成する。
【０１５１】
ここで、本実施形態に係る表示制御データ生成部５３２が生成する表示制御データ６０について説明する。上述したように、本実施形態では、Ａｊａｘを用いている。そのため、表示制御データ生成部５３２は、表示制御データ６０をＤＯＭ（Document Object Model）を用いて生成する。ＤＯＭとは、Ｗ３Ｃ（World Wide Web Consortium）から勧告されているＨＴＭＬ文書やＸＭＬ（Extensible Markup Language）文書などをアプリケーションから利用するためのＡＰＩである。表示制御データ生成部５３２は、表示制御データ６０（ＨＴＭＬデータ）の生成・更新（表示画面を構成する表示部品Ｐの生成、追加、及び削除）を、上記ＤＯＭを用いて行う。
【０１５２】
例えば、表示制御データ生成部５３２は、表示部品Ｐを生成する場合、document.createElement()により、表示制御データ６０をＤＯＭ上のオブジェクトとして生成する。また表示制御データ生成部５３２は、表示部品Ｐを追加する場合、appendChild()により追加し、表示部品Ｐを削除する場合、removeChild()により削除する。表示制御データ生成部５３２は、このようにして表示制御データ６０を生成・更新する。
【０１５３】
図１２は、本実施形態に係る表示制御のデータ構造例を示す図である。図１２には、ＨＴＭＬ形式のＤＩＶタグを用いて、表示画面を構成する表示部品Ｐが定義されるデータ例が示されている。表示制御データ６０には、１つの表示部品Ｐは、１組のＤＩＶタグを用いて定義可能であり、ＤＯＭ上のオブジェクトにあたる。また表示制御データ６０には、表示部品Ｐの階層構造（親子関係）に従ったＤＩＶタグが記述される。
【０１５４】
ＤＩＶタグには、表示部品Ｐを識別する表示部品識別子（ＩＤ）が定義されている。表示制御データ６０では、この表示部品識別子により、表示画面上の制御対象となる表示部品Ｐを特定することができる。
【０１５５】
またＤＩＶタグ内には、例えば図１３〜図１５に示すような、表示部品Ｐの属性を含む情報（表示部品情報）が定義できる。表示部品情報には、表示部品Ｐの配置位置（配置座標）、見た目（例えば「色」、「大きさ」、「付加文字」）、及び格納先（例えば「イメージリソース３１のパス」）などがある。
【０１５６】
図１３，１４，１５は、本実施形態に係る表示部品情報のデータ例（その１からその３）を示す図である。
【０１５７】
図１３（Ａ）には、表示部品ＷｉｎｄｏｗＰ４の表示部品情報７０ｗのデータ例が示されている。表示部品情報７０ｗには、例えばウィンドウの見た目が定義されている。また図１３（Ｂ）には、表示部品ＤｉａｌｏｇＰ６の表示部品情報７０ｄのデータ例が示されている。表示部品情報７０ｄには、例えばダイアログの背景色や見た目が定義されている。また図１３（Ｃ）には、表示部品ＦｒａｍｅＰ１の表示部品情報７０ｆのデータ例が示されている。表示部品情報７０ｆには、例えばフレームの見た目が定義されている。
【０１５８】
図１４（Ａ）には、表示部品ＢｕｔｔｏｎＰ７の表示部品情報７０ｂのデータ例が示されている。表示部品情報７０ｂには、例えばボタンの見た目、ボタン画像の配置位置、切り出し領域とサイズ、ボタン画像の格納先、ボタン上の文字が定義されている。また図１４（Ｂ）には、表示部品ＬａｂｅｌＰ２の表示部品情報７０ｌのデータ例が示されている。表示部品情報７０ｌには、例えばラベルの外枠やラベル上の文字が定義されている。
【０１５９】
図１５（Ａ）には、表示部品ＬａｂｅｌＡｒｅａＰ５の表示部品情報７０ｌａのデータ例が示されている。表示部品情報７０ｌａには、例えばラベルエリアの外枠やラベルエリア上の文字が定義されている。また図１５（Ｂ）には、表示部品ＩｃｏｎＰ３の表示部品情報７０ｉのデータ例が示されている。表示部品情報７０ｉには、例えばアイコンの背景、アイコン画像の配置位置、切り出し領域とサイズ、及びアイコン画像の格納先が定義されている。また図１５（Ｃ）には、表示部品ＰａｔｔｅｒｎＰ８の表示部品情報７０ｐのデータ例が示されている。
【０１６０】
また表示制御データ生成部５３２は、上記ＤＩＶタグを含むＨＴＭＬ形式の表示制御データ６０を生成するために、表示部品Ｐの生成処理を実現する共通インタフェースを介して行う。これにより、表示制御データ生成部５３２は、複数種の表示部品Ｐに対して共通した生成処理を実行できる。また、複数の表示部品Ｐがレイアウトされる表示部品Ｐの生成処理では、共通インタフェースを再帰的に呼び出すことで、階層構造（親子関係）に従った表示制御データ６０を生成できる。
【０１６１】
表示制御を行う処理手順の説明に戻る。
表示制御データ生成部５３２は、同仮想マシン２１２上で動作するサブセットモジュール４１２に、生成した表示制御データ６０の送信要求を通知する（ステップＳ６０５）。このとき、表示制御データ生成部５３２は、生成した表示制御データ６０をサブセットモジュール４１２に渡す。
【０１６２】
サブセットモジュール４１２は、表示制御データ送信要求通知を受け付けると、通信部５１２により、第１仮想マシン２１１上で動作するサブセットモジュール４１１と仮想マシン間通信を行い、アプリ画面の生成処理を第１仮想マシン２１１側に委譲する（ステップＳ６０６）。このとき、サブセットモジュール４１２は、通信部５１２が有する送信部５１１２により、表示制御データ６０を送信する。これにより、第２仮想マシン２１２からアプリ画面の生成処理を要求する。その結果、サブセットモジュール４１１は、第２仮想マシン２１２上で動作するサブセットモジュール４１２から送信された、表示制御データ６０を、通信部５１１が有する受信部５１２１により受信する。これにより、第１仮想マシン２１１でアプリ画面生成要求を受け付ける。
【０１６３】
サブセットモジュール４１１は、アプリ画面生成要求を受け付けると、通信部５１１が有する受信部５１２１から処理要求部５２１に、アプリ画面の描画要求が通知される（ステップＳ７０１）。このとき、受信部５１２１は、更新要求時の表示制御データ６０を処理要求部５２１に渡す。
【０１６４】
処理要求部５２１は、表示制御データ６０に基づくアプリ画面生成処理の実行（アプリ画面の描画）を、サーブレット４５に要求する（ステップＳ７０２）。このとき、処理要求部５２１は、表示制御データ６０をサーブレット４５に渡し、アプリ画面生成処理の実行を要求する。
【０１６５】
サーブレット４５は、受け取った表示制御データ６０に従って、画像処理装置１００が備える表示装置１２０上で動作するブラウザ１１に対して、アプリ画面の生成処理（アプリ画面の描画）を実行する（ステップＳ７０３）。
【０１６６】
表示装置１２０では、このようにしてブラウザ１１にアプリ画面が描画され生成される（ステップＳ７０４）。また表示装置１２０からは、ブラウザ１１によるアプリ画面生成処理の実行結果が、サーブレット４５を介して処理要求部５２１へと応答される。
【０１６７】
以上のように、画像処理装置１００では、サブセットモジュール４１を用いた仮想マシン間通信により、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面生成処理を第１仮想マシン２１１へと委譲し、表示画面を生成する。
【０１６８】
《処理２》
図１６は、本実施形態に係る表示制御を行う処理手順例（その２）を示すシーケンス図である。
【０１６９】
図１６に示すように、画像処理装置１００では、ボタン押下時におけるＳＤＫアプリケーション２２２ｂ２のアプリ画面を更新する場合、以下の表示制御処理が実行される。
【０１７０】
表示装置１２０では、ハードキーのボタン押下が検出される（ステップＳ８０１）。検出されたボタン押下の検出信号は、第１仮想マシン２１１上で動作するハードキーイベント配信モジュール４３に渡され、ハードキーイベント配信モジュール４３からハードキーイベントがサブセットモジュール４１１に通知される（ステップＳ８０２）。このとき、ハードキーイベント配信モジュール４３は、検出信号に基づき、ハードキー情報や操作イベント情報を発行し、サブセットモジュール４１１に通知する。サブセットモジュール４１１は、通信部５１１により、これらの情報をイベント通知として受け取る。
【０１７１】
また表示装置１２０上で動作するブラウザ１１がＧＵＩのボタン押下を受け付けた場合には、その操作イベントが、サーブレット４５を介してサブセットモジュール４１１に通知される。
【０１７２】
サブセットモジュール４１１は、イベント通知を受け取ると、通信部５１１により、第２仮想マシン２１２上で動作するサブセットモジュール４１２と仮想マシン間通信を行い、ボタン押下時の処理を第２仮想マシン２１２側に委譲する（ステップＳ８０３）。このとき、サブセットモジュール４１１は、通信部５１１が有する送信部５１１１により、ハードキー情報や操作イベント情報を送信する。これにより、第１仮想マシン２１１からボタン押下時の処理を要求する。その結果、サブセットモジュール４１２は、第１仮想マシン２１１上で動作するサブセットモジュール４１１から送信された、ハードキー情報や操作イベント情報を、通信部５１２が有する受信部５１２２により受信する。これにより、第２仮想マシン２１２でボタン押下処理要求を受け付ける。
【０１７３】
サブセットモジュール４１２は、ボタン押下処理要求を受け付けると、通信部５１２が有する受信部５１２２からＳＤＫ  ＡＰＩ２２１ｂ２に、ボタン押下時の処理要求が通知される（ステップＳ９０１）。このとき、受信部５１２２は、処理要求時のハードキー情報や操作イベント情報をＳＤＫ  ＡＰＩ２２１ｂ２に渡す。
【０１７４】
ＳＤＫ  ＡＰＩ２２１ｂ２は、ボタン押下処理の実行を、ＳＤＫアプリケーション２２２ｂ２に要求する（ステップＳ９０２）。このとき、ＳＤＫ  ＡＰＩ２２１ｂ２は、ハードキー情報や操作イベント情報を、ＳＤＫアプリケーション２２２ｂ２に渡し、ボタン押下処理の実行を要求する。
【０１７５】
ＳＤＫアプリケーション２２２ｂ２では、このようにしてボタン押下処理が実行される（ステップＳ９０３）。またＳＤＫアプリケーション２２２ｂ２からは、ボタン押下処理の実行結果が、ＳＤＫ  ＡＰＩ２２１ｂ２へと応答される。
【０１７６】
表示装置１２０では、第２仮想マシン２１２で実行される上記Ｓ９０１〜Ｓ９０３の処理と非同期に、ブラウザ１１上でＪａｖａスクリプトを実行することで、ボタン押下時のアプリ画面の更新処理（アプリ画面の再描画）が行われる。この処理がステップＳ１００１にあたる。
【０１７７】
ブラウザ１１には、画面生成要求時に受け取ったＨＴＭＬ形式の表示制御データ６０に従ってアプリ画面が表示されている。また画面生成要求時には、ＨＴＭＬデータと共にＪａｖａスクリプトを受け取っている。
【０１７８】
これにより、ブラウザ１１では、ＧＵＩ上のボタンが押下された場合、Ｊａｖａスクリプトが実行されアプリ画面の更新が行われる。このとき、受け付けた操作イベントに対応する表示部品Ｐに対して、状態変化に応じた更新処理が行われる。
【０１７９】
具体的には、次の通りである。ブラウザ１１では、押下された表示部品Ｐの表示部品識別子に基づき、表示制御データ６０から更新対象に該当する表示部品情報７０を特定する。ブラウザ１１は、特定した表示部品情報７０、すなわちＤＩＶタグで定義されたデータを更新する。上述したように、表示制御データ６０は、ＤＯＭのオブジェクトとして生成されており、表示制御データ６０内の表示部品情報７０は、ＤＯＭを用いて生成・更新できる。よって、ブラウザ１１では、ＤＯＭを用いて該当データを更新し、アプリ画面の更新処理（アプリ画面の再描画）が実行される。表示装置１２０では、このようにしてアプリ画面が再描画され更新される。
【０１８０】
以上のように、画像処理装置１００では、サブセットモジュール４１を用いた仮想マシン間通信により、第２仮想マシン２１２上で動作するＳＤＫアプリケーション２２２ｂ２のアプリ画面更新処理を第１仮想マシン２１１へと委譲し、表示画面を更新する。
【０１８１】
＜変形例＞
図１７は、上記実施形態の変形例に係る複数の仮想マシンが構築されたシステムのソフトウェア構成例を示す図である。
【０１８２】
図９に示すように、本実施形態では、第１仮想マシン２１１側のみでサーブレット４５を動作させる構成例を示したが、この限りでない。
【０１８３】
例えば図１７に示すように、第２仮想マシン２１２側でもサーブレット４５が動作する構成であってもよい。
【０１８４】
変形例で示すソフトウェア構成は、第１仮想マシン２１１側のみでサーブレット４５を動作させる構成に比べて、さらに仮想マシン間の通信回数を削減できる。仮想マシン間通信は、ハードキーイベント配信やＬＥＤ点灯制御などの場合、サブセットモジュール４１を用いて行う必要があるが、表示画面の生成・更新の場合、仮想マシン間通信を行う必要がなくなる。なぜなら、上記表示画面の生成・更新処理の全ては、ブラウザ１１及びサーブレット４５で実現可能な機能として完結させることができるからである。なお、第１仮想マシン２１１と第２仮想マシン２１２とで、サーブレット４５を動作させるためには、ＨＴＴＰ（HyperText Transfer Protocol）通信で用いるポート番号と、サーブレット４５に登録するＵＲＬ（Uniform Resource Locator）の２点について互いに競合を起こさないように実装する必要がある。つまり、第１仮想マシン２１１上で動作するＷｅｂサーバと、第１仮想マシン２１１上で動作するＷｅｂサーバとでは、ブラウザ１１に対して異なるポート番号及びＵＲＬを用意する必要がある。
【０１８５】
＜まとめ＞
以上のように、本実施形態に係る画像処理装置１００によれば、第２仮想マシン２１２側において、表示画面を構成する表示部品Ｐの属性を含む詳細情報（表示部品情報）と、要求に応じて表示部品Ｐの生成・更新を行うプログラム（手続き）と、を含む表示制御データ６０を生成する。画像処理装置１００は、生成した表示制御データ６０を、表示画面を制御するサーブレット４５（Ｗｅｂサーバ）が動作する第１仮想マシン２１１に送信する。その結果、画像処理装置１００では、第１仮想マシン２１１側において、サーブレット４５により表示制御データ６０を処理し、表示装置１２０上で動作するブラウザ１１で表示画面の生成・更新の表示制御が行える。
【０１８６】
これによって、画像処理装置１００は、表示制御における仮想マシン間の通信データ量及び通信回数を削減することができる。その結果、ユーザへの提供情報やＧＵＩを高速表示できる（画面表示の高速化が図れる）。
【０１８７】
また本実施形態では、表示画面の生成・更新を、ブラウザ１１及びサーブレット４５により実現することから、複数の仮想マシン環境において安定した動作を実現することができる。
【０１８８】
ここまで、上記実施形態の説明を行ってきたが、実施形態に係る画像処理装置１００が有する「表示制御機能」は、図を用いて説明を行った各処理手順を動作環境（プラットフォーム）にあったプログラミング言語でコード化したプログラムが、ＣＰＵ１１１により実行されることで実現される。
【０１８９】
上記プログラムは、コンピュータが読み取り可能な記録媒体１１４ａに格納することができる。上記記録媒体１１４ａには、例えばＳＤメモリカード及びＵＳＢメモリなどがある。
【０１９０】
よって、上記プログラムは、上記記録媒体１１４ａに記憶させることで、記録媒体１１４ａを読み取り可能な外部記憶Ｉ／Ｆ１１４などを介して画像処理装置１００にインストールすることができる。また画像処理装置１００は、ネットワークＩ／Ｆ１１３を備えていることから、インターネットなどの電気通信回線を用いて上記プログラムをダウンロードし、インストールすることもできる。
【０１９１】
最後に、上記実施形態に挙げた形状や構成に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。
【符号の説明】
【０１９２】
１０      ＯＳ（表示装置側）
１１      ブラウザ
１２      Ｆｌａｓｈ  Ｐｌａｙｅｒ
１３      ソフトキーボード
２０      ＯＳ（画像処理装置側）
２１      ＪａｖａＶＭ（１：第１仮想マシン側、２：第２仮想マシン側）
２１１    ヒープメモリ
２２      Ｊａｖａコンポーネント
２２１    Ｊａｖａプラットフォーム
２２１ａ  Ｊａｖａモジュール群
２２１ｂ  ＳＤＫ  ＡＰＩ
２２２    Ｊａｖａアプリケーション
２２２ａ  標準アプリケーション（１：第１仮想マシン側）
２２２ｂ  ＳＤＫアプリケーション
３１      イメージリソース（画像データの記憶領域）
４１      サブセットモジュール
４２      画面制御モジュール
４３      ハードキーイベント配信モジュール
４４      ＬＥＤ点灯モジュール
４５      サーブレット
５１      通信部
５１１    送信部
５１２    受信部
５２      処理要求部（１：第１仮想マシン側）
５３      表示制御データ生成部（２：第２仮想マシン側）
５４      情報取得部（２：第２仮想マシン側）
６０      表示制御データ
７０      表示部品情報
１００  画像処理装置
１１０  コントローラ
１１１  ＣＰＵ（中央処理装置）
１１２  記憶装置
１１３  ネットワークＩ／Ｆ
１１４  外部記憶Ｉ／Ｆ（ａ：記録媒体）
１２０  表示装置
１３０  プロッタ（画像形成部）
１４０  スキャナ（読み取り部）
Ｐ      表示部品
【先行技術文献】
【特許文献】
【０１９３】
【特許文献１】国際公開ＷＯ０１／０８４３０３号公報
【特許文献２】特開２００６−３１４６６４号公報
【図１】
0005458708.tif 000002
【図２】
0005458708.tif 000003
【図３】
0005458708.tif 000004
【図４】
0005458708.tif 000005
【図５】
0005458708.tif 000006
【図６】
0005458708.tif 000007
【図７】
0005458708.tif 000008
【図８】
0005458708.tif 000009
【図９】
0005458708.tif 000010
【図１０】
0005458708.tif 000011
【図１１】
0005458708.tif 000012
【図１２】
0005458708.tif 000013
【図１３】
0005458708.tif 000014
【図１４】
0005458708.tif 000015
【図１５】
0005458708.tif 000016
【図１６】
0005458708.tif 000017
【図１７】
0005458708.tif 000018