JP5263358B2 - 情報処理装置、プログラム制御方法、及び制御プログラム - Google Patents

Description

本発明は、情報処理装置、プログラム制御方法、及び制御プログラムに関し、特にプログラムを追加可能な情報処理装置、プログラム制御方法、及び制御プログラムに関する。

近年では、主に複合機又は融合機と呼ばれる画像形成装置において、その出荷後に、公開されたＡＰＩ（Application Program Interface）を利用して新たなアプリケーションの開発及びインストールが可能とされているものがある（例えば、特許文献１）。斯かる画像形成装置では、当該画像形成装置のベンダによって開発されたアプリケーションのみならず、他のソフトウェアベンダによって開発されたアプリケーションもインストールされ、利用されるといった状況が生じ得る。

ところで、画像形成装置のような組み込み系の機器の場合、メモリ等のリソースに関する制限は、汎用的なコンピュータに比べて厳しい。したがって、予め、アプリケーションの消費メモリ等、リソースの使用量に関して制限が設けられており、各ソフトウェアベンダは、当該制限（以下、「リソース制限」という。）の範囲内で動作するようなアプリケーションの設計が求められている。

しかしながら、ソフトウェアベンダにしてみれば、より利便性の高い、高機能なアプリケーションを提供したいといった欲求がある。一般的に、高機能になればなるほど、プログラムによるメモリの消費量は増加する傾向にある。したがって、エンドユーザの利便性を考慮するあまり、リソース制限が遵守されない状態でアプリケーションが市場に提供される可能性がある。

また、それぞれのアプリケーションごとにはリソース制限を遵守して作成されている場合であっても、複数のアプリケーションが並列的に利用される場合等、ユーザの利用態様によって、画像形成装置のリソースが枯渇してしまう可能性がある。

リソースが枯渇してしまった場合、アプリケーションの動作が保証されず、エンドユーザにとって不利益が生じるだけでなく、画像形成装置のベンダやアプリケーションの開発ベンダにおいても、原因の究明のための作業負担が生じるといった問題がある。

本発明は、上記の点に鑑みてなされたものであって、プログラムによる不正動作の可能性を低減させることのできる情報処理装置、プログラム制御方法、及び制御プログラムの提供を目的とする。

そこで上記課題を解決するため、本発明は、複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置であって、前記プログラムの状態を遷移させる管理手段と、前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けてメモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段とを有し、前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする。

このような情報処理装置では、プログラムによる不正動作の可能性を低減させることができる。

本発明によれば、プログラムによる不正動作の可能性を低減させることのできる情報処理装置、プログラム制御方法、及び制御プログラムを提供することができる。

本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態における複合機のハードウェア構成例を示す図である。 本発明の実施の形態における複合機のソフトウェア構成例を示す図である。 アプリケーションバンドルやサービスバンドルの状態遷移モデルの実装例を示す図である。 リクエスト経路制御部の主な機能を説明するための図である。 仮起動スクリプト及び仮起動サービスを説明するための図である。 第一の実施の形態における複合機の仮起動に関する処理手順を説明するためのシーケンス図である。 スキャンアプリのアプリケーション管理ファイルに記録されているアプリケーション情報の例を示す図である。 第一の実施の形態におけるメインスクリプトの記述例を示す図である。 第一の実施の形態におけるシナリオスクリプトの記述例を示す図である。 スキャンアプリの操作画面の例を示す図である。 第一の実施の形態における振る舞いスクリプトの記述例を示す図である。 仮起動ログの構文の例を説明するための図である。 仮起動ログの具体例を示す図である。 セキュリティマネージャによるオブジェクトの生成元の識別方法を説明するための図である。 スレッドグループを用いた呼び出し元のアプリケーション名の識別方法を説明するための図である。 複数のアプリケーションを並列して起動した場合のメモリの消費の様子を説明するための図である。 第二の実施の形態におけるメインスクリプトの記述例を示す図である。 第二の実施の形態におけるＳＡＳマネージャによる起動中のアプリケーションの管理処理を説明するためのフローチャートである。 状態遷移の制限によってメモリ消費量が適切に管理される様子を示す図である。 第三の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。 第四の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。

図１は、本発明の実施の形態の概要を説明するための図である。本発明の実施の形態において、複合機１０は、アプリケーションを追加可能な画像形成装置の一例である。図中、複合機１０が上下に二つ記載されているが、これは同一の複合機１０を時間の経過に応じて示したものである。

本実施の形態において、新たに複合機１０にインストールされるアプリケーションについては、まず、仮起動が行われる（Ｓ１１）。仮起動とは、アプリケーションによるリソースの消費量や、アプリケーションが利用する複合機１０内のサービス（機能）等（これらを示す情報を、以下「アプリケーション動作情報」という。）を調査するためにアプリケーションを起動することをいう。本実施の形態において、仮起動されたアプリケーションは、当該アプリケーションの本来の機能をユーザに対して提供することはできない。仮起動の際中、複合機１０は、アプリケーション動作情報を仮起動ログとして出力する（Ｓ１２）。仮起動が終了すると、複合機１０は、仮起動ログに基づいて仮起動の成否を判定する（Ｓ１３）。仮起動の成功とは、仮起動されたアプリケーションの動作が、予め定められた制限（リソースの消費量や、利用する複合機１０内のサービス等に関する制限）の範囲内であることが確認されたことをいう。仮起動の失敗とは、仮起動されたアプリケーションの動作が、予め定められた制限に従っていないことが確認されたことをいう。

仮起動が成功すると、当該アプリケーションは複合機１０にインストールされ、本起動が可能な状態となる。したがって、ユーザから起動指示があった場合は、本起動が行われる（Ｓ１４）。本起動とは、仮起動に対する用語であり、アプリケーション本来の機能を発揮させるためにアプリケーションを起動するこという。すなわち、本起動によって、アプリケーションの通常の使用状態を実現される。本起動の際、複合機１０は、仮起動ログに基づいて、アプリケーションの動作を制御する。例えば、アプリケーションの起動を拒否したり、アプリケーションの起動のタイミングを制限したり、アプリケーションの状態遷移（処理の進行）を制限したり、アプリケーションによる複合機１０のサービスの使用を制限したりする。

以上のように、複合機１０では、新たに追加（インストール）されるアプリケーションについて、予め仮起動を行い、仮起動の際に取得される仮起動ログに基づいて本起動の際の動作を制御することができる。したがって、予め定められたリソースの消費量等に関する制限を遵守していないアプリケーションの動作を制限したり、複数のアプリケーションが同時に（並列的に）起動された際において、各アプリケーションのリソースの消費のタイミングを制御したりすることが可能となる。

以下、具体的に説明する。図２は、本発明の実施の形態における複合機のハードウェア構成例を示す図である。図２において複合機１０は、コントローラ２０１、オペレーションパネル２０２、ファクシミリコントロールユニット（ＦＣＵ）２０３、撮像部１２１、及び印刷部１２２等を備える。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、複合機１０のシステムメモリである。ＭＥＭ−Ｃ２３２は、複合機１０のローカルメモリである。ＨＤＤ２３３は、複合機１０のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが複合機１０に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１０から出力を得るためのハードウェア（表示部）である。

図３は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。図３において、複合機１０のソウトウェアは、ＪＳＤＫアプリ３０、ＪＳＤＫプラットフォーム４０、リクエスト経路制御部５０、及びネイティブサービスレイヤ６０等より構成されている。これらの各ソフトウェアは、メモリカード２３５やその他の記憶装置に記録されたプログラムがＣＰＵ２１１によって処理されることにより機能する。

ネイティブサービスレイヤ６０は、複合機１０のハードウェアやソフトウェアに基づく機能を利用させるためのインタフェースを上位モジュールに対して提供し、当該インタフェースの呼び出し（機能の利用要求）に応じて、当該機能を実現するための制御を行う。例えば、ネイティブサービスレイヤ６０には、ネットワーク通信の制御に関するインタフェースを提供するモジュール、ファクシミリの制御に関するインタフェースを提供するモジュール、蓄積文書（ＨＤＤ２３３に保存されている文書（画像）データ）の配信処理の制御に関するインタフェースを提供するモジュール、撮像部１２１や印刷部１２２の制御に関するインタフェースを提供するモジュール。メモリやＨＤＤ２３３等の制御に関するインタフェースを提供するモジュール、オペレーションパネル２０２の制御に関するインタフェースを提供するモジュール、認証処理や課金処理の制御に関するインタフェースを提供するモジュール、ユーザ情報の管理に関するインタフェースを提供するモジュール等が含まれる。

ＪＳＤＫプラットフォーム４０は、ＪＳＤＫアプリ３０の実行環境を提供するソフトウェアプラットフォームであり、ネイティブサービスレイヤ６０に対するＪａｖａ（登録商標）インタフェースを上位モジュールに対して提供する。ＪＳＤＫプラットフォーム４０は、Ｊａｖａ（登録商標）の標準のクラスや、複合機１０用に拡張されたクラスに関するクラスライブラリ、及びＪａｖａ（登録商標）仮想マシン等を含む。例えば、図中では、ＪＳＤＫプラットフォーム４０の一部として、セキュリティマネージャ４１やロギングサービス４２が示されている。

セキュリティマネージャ４１は、予めポリシーファイルに定義されたアクセス制御情報に基づいて、ＪＳＤＫアプリ３０による、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを制限する。すなわち、ＪＳＤＫプラットフォーム４０は、リソースへのアクセスが発生する際に、セキュリティマネージャ４１に対する呼び出しが発生するように構成されている。セキュリティマネージャ４１は、その呼び出しに応じてリソースへのアクセスの可否を判断する。なお、セキュリティマネージャ４１は、Ｊａｖａ（登録商標）の標準におけるＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスを用いて実現してもよい。

ロギングサービス４２は、ＪＳＤＫアプリ３０の仮起動の際に、仮起動ログ８０を出力する。

なお、ＪＳＤＫプラットフォーム４０は、ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとして実装されている。ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。ＯＳＧｉプラットフォーム上において、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのＪＡＲ（Java ARchive）ファイルによって構成され、それぞれ独立して動的に（装置の再起動を要することなく）インストール可能である。

ＪＳＤＫアプリ３０は、ＪＳＤＫプラットフォーム４０において公開されている専用のＳＤＫ（ソフトウェア開発キット）を使用して作成されたアプリケーション（以下「ＳＤＫアプリ」という。）である。ＳＤＫアプリのうち、特にＪａｖａ（登録商標）を言語を使用して開発されたアプリケーションをＪＳＤＫアプリといい、本実施の形態において仮起動の対象とされる。

図中では、ＪＳＤＫアプリ３０の例として、ＳＡＳ（SDK Application Service）マネージャ３１、アプリケーションバンドル３２、及びサービスバンドル３３等が存在する。ＳＡＳマネージャ３１は、他のＪＳＤＫアプリ３０（アプリケーションバンドル３２やサービスバンドル３３等）のインストール（追加）、アンインストール（削除）、起動、及び起動解除等の制御を行う。

アプリケーションバンドル３２は、オペレーションパネル２０２に操作画面を表示させ、当該操作画面を介してエンドユーザから直接利用（操作）されるＪＳＤＫアプリ３０としてのバンドルである。図中では、アプリケーションバンドル３２の一例としてスキャンアプリ３２１が示されている。スキャンアプリ３２１は、撮像部１２１による原稿からの画像の読み取りを実現するアプリケーションである。

サービスバンドル３３は、アプリケーションバンドル３２等に対してサービスを提供するためのＪＳＤＫアプリ３０としてのバンドルである。すなわち、サービスバンドル３３は、アプリケーションバンドル３２等からの呼び出しに応じて各サービスバンドル３３に応じた処理を実行し、その処理結果をアプリケーションバンドル３２等に返却する。図中では、サービスバンドル３３の一例として、スキャンサービス３３１、パネルサービス３３２、及び仮起動サービス３３３等が示されている。

スキャンサービス３３１は、画像の読み取り機能に関するサービスを提供する。パネルサービス３３２は、オペレーションパネル２０２の表示制御に関するサービスを提供する。仮起動サービス３３３は、仮起動スクリプト７０の記述内容に基づいて仮起動の処理制御に関するサービスを提供する。仮起動スクリプト７０の詳細については後述する。

なお、本実施の形態において、アプリケーションバンドル３２やサービスバンドル３３等のアプリケーションは、ｉｎｉｔ状態→ｐａｕｓｅ状態→ａｃｔｉｖｅ状態→ｄｅｓｔｒｏｙ状態の順で状態が遷移する（処理が進行する）状態遷移モデルに従って動作する。ｉｎｉｔ状態は、初期状態であり、初期処理等が行われる。起動直後のアプリケーションは、まず、ｉｎｉｔ状態に遷移する。ｐａｕｓｅ状態は、待機状態である。ｐａｕｓｅ状態のアプリケーションは、実行可能となるまで待機する。ａｃｔｉｖｅ状態は、アプリケーション本来の機能が実行される状態である。ｄｅｓｔｒｏｙ状態は、終了状態である。終了するアプリケーションは、ｄｅｓｔｒｏｙ状態に遷移し、終了化処理（リソースの開放等）を行った後、終了する。

斯かる状態遷移モデルを実現するため、アプリケーションバンドル３２やサービスバンドル３３は、次のように構成される。図４は、アプリケーションバンドルやサービスバンドルの状態遷移モデルの実装例を示す図である。図４に示されるように、アプリケーションバンドル３２やサービスバンドル３３（図４の説明においては、「アプリケーションバンドル３２等」という。）は、状態ごとにインスタンス化されたオブジェクトによって構成される。すなわち、ｉｎｉｔ状態、ｐａｕｓｅ状態、ａｃｔｉｖｅ状態、ｄｅｓｔｒｏｙ状態に対応させて、ｉｎｉｔ状態オブジェクト３４１、ｐａｕｓｅ状態オブジェクト３４２、ａｃｔｉｖｅ状態オブジェクト３４３、ｄｅｓｔｒｏｙ状態オブジェクト３４４がインスタンス化される。

アプリケーションバンドル３２等は、状態遷移を発生させるイベント（メッセージ）を受けると、遷移元のオブジェクトから遷移先のオブジェクトへと処理の制御（当該アプリケーションの制御）を移動させる。例えば、ｉｎｉｔ状態オブジェクト３４１からｐａｕｓｅ状態オブジェクト３４２への処理の制御が移動する。この制御の移動によって状態の遷移が実現される。

なお、アプリケーションバンドル３２等が状態遷移モデルに従って動作することは、本発明を適用するために、アプリケーションが或る状態遷移モデルに従って実装されなければならないことを意図するものではない。

リクエスト経路制御部５０は、ＪＳＤＫアプリ３０によるネイティブサービスレイヤ６０に対する要求（所定の機能の利用要求）を監視し、当該要求の発行元のＪＳＤＫアプリ３０が、仮起動中であるか否かに応じて、当該要求の通知経路を制御する。すなわち、仮起動中であるＪＳＤＫアプリ３０からの要求については、仮起動サービス３３３に通知し、仮起動中でない（本起動中）のＪＳＤＫアプリ３０からの要求については、ネイティブサービスレイヤ６０に通知する。

図５は、リクエスト経路制御部の主な機能を説明するための図である。図５中、図３と同一部分には同一符号を付している。図５において、アプリＡ３２２は、本起動されているアプリケーションバンドル３２である。アプリＢ３２３は、仮起動されているアプリケーションバンドル３２である。図中に示されるように、リクエスト経路制御部５０は、本起動されているアプリＡ３２２に関しては、ＪＳＤＫプラットフォーム４０を介して行われるネイティブサービスレイヤ６０に対する呼び出しを通過させる（Ｓ２１）。したがって、この場合、ネイティブサービスレイヤ６０による制御により、複合機１０が実際に動作する。

一方、リクエスト経路制御部５０は、仮起動されているアプリＢ３２３に関しては、ＪＳＤＫプラットフォーム４０を介して行われるネイティブサービスレイヤ６０に対する呼び出しをネイティブサービスレイヤ６０には通知せず、仮起動サービス３３３に対して通知する（Ｓ２２）。この場合、仮起動サービス３３３は、擬似的にネイティブサービスレイヤ６０のように振る舞い、その結果をアプリＢ３２３に対してネイティブサービスレイヤ６０と同じ形式で応答する。したがって、アプリＢ３２３からは、ネイティブサービスレイヤ６０が正常に呼び出され、その機能が実行されたように見える。このように、仮起動の際は、リクエスト経路制御部５０によってネイティブサービスレイヤ６０以下を機能させずに（すなわち、実際に複合機１０を動作させずに）、ＪＳＤＫアプリ３０の検証が行われる。

次に、仮起動スクリプト７０及び仮起動サービス３３３の詳細について説明する。図６は、仮起動スクリプト及び仮起動サービスを説明するための図である。

図６に示されるように、仮起動スクリプト７０は、メインスクリプト７１、シナリオスクリプト７２、及び振る舞いスクリプト７３の三つのスクリプトファイルより構成される。メインスクリプト７１には、仮起動に使用するシナリオスクリプト７２及び振る舞いスクリプト７３の特定や仮起動の成否の判断基準等が定義される。シナリオスクリプト７２には、仮起動のシナリオが定義される。シナリオとは、仮起動されるアプリケーションに対するオペレーションパネル２０２を介した操作手順をいう。振る舞いスクリプト７３には、リクエスト経路制御部５０によって仮起動サービス３３３に通知されたネイティブサービスレイヤ６０の呼び出しに対する振る舞い（エミュレーションの内容）が定義される。

メインスクリプト７１は、仮起動サービス３３３によって解釈される。したがって、仮起動サービス３３３は、メインスクリプト７１に従って仮起動を制御する。仮起動サービス３３３は、シナリオスクリプト７２を解釈するためのスレッド（シナリオサービス３３４）と、振る舞いスクリプト７３を解釈するためのスレッド（振る舞いサービス３３５）を生成する。

シナリオサービス３３４は、シナリオスクリプト７２に従って、仮起動中のアプリケーションに対する操作指示を入力する擬似的な操作者として機能する。シナリオサービス３３４の操作指示に応じて発生する当該アプリケーションに基づくネイティブサービスレイヤ６０の呼び出しは、リクエスト経路制御部５０によって振る舞いサービス３３５に通知される。振る舞いサービス３３５は、振る舞いスクリプト７３の定義に従って、通知された呼び出しに対するエミュレーションを行い、その結果として、ネイティブサービスレイヤ６０と同じ形式の応答を行う。ネイティブサービスレイヤ６０と同じ形式の応答が行われることで、アプリケーションからは、ネイティブサービスレイヤ６０が呼び出されたように見える。

以下、複合機１０の処理手順について説明する。図７は、第一の実施の形態における複合機の仮起動に関する処理手順を説明するためのシーケンス図である。

アプリケーションのインストールが指示されると、ＳＡＳマネージャ３１は、複合機１０本体のメモリカードスロット２３４に挿入されているＳＤカードに記録されているアプリケーション管理ファイルを検索し、検索された全てのアプリケーション管理ファイルをＳＤカード内より取り出す（Ｓ１０１）。ここで、アプリケーション管理ファイルとは、アプリケーションの構成要素やインストール等に必要な情報、及びその他の管理情報等（以下、「アプリケーション情報」という。）が記録されているファイルである。アプリケーション管理ファイルは、アプリケーションごとに添付されている。したがって、ＳＤカード内に複数のＪＳＤＫアプリ３０が記録されている場合は、複数のアプリケーション管理ファイルが取り出される。

例えば、図８は、スキャンアプリのアプリケーション管理ファイルに記録されているアプリケーション情報の例を示す図である。図８に示されるアプリケーション情報４１０は、ＸＭＬ（eXtensible Markup Language）形式をベースとしたＪＮＬＰ（Java Network Launching Protocol（ＪＳＲ−５６仕様））を拡張した形式によって表現されている。

アプリケーション情報４１０は、主に、＜ｉｎｆｏｒｍａｔｉｏｎ＞タグで囲まれたｉｎｆｏｒｍａｔｉｏｎ要素４１１、＜ｒｓｏｕｒｃｅ＞タグで囲まれたｒｅｓｏｕｒｃｅ要素４１２、＜ｐｓｅｕｄｏ−ｂｏｏｔ＞タグで囲まれたｐｓｅｕｄｏ−ｂｏｏｔ要素４１３、＜ｘｌｅｔ−ｄｅｓｃ＞タグで囲まれたｘｌｅｔ要素４１４等より構成される。

ｉｎｆｏｒｍａｔｉｏｎ要素４１１には、主に、アプリケーション（スキャンアプリ３２１）を識別するための情報が記録されている。例えば、ｐｒｏｄｕｃｔ−ｉｄ要素４１１１にはスキャンアプリ３２１のプロダクトＩＤが、ｔｉｔｌｅ要素４１１２にはスキャンアプリ３２１のタイトル（アプリケーション名）が、ｖｅｎｄｏｒ要素４１１３にはスキャンアプリ３２１の開発ベンダ名（記述４１１３）が記録されている。

ｒｅｓｏｕｒｃｅ要素４１２には、スキャンアプリ３２１の実行に必要なリソースに関する情報が記録されている。例えば、ｊａｒ要素４１２１のｈｒｅｆ属性の値として、スキャンアプリ３２１のＪＡＲファイルのファイル名（パス名）が記録されている。

ｐｓｅｕｄｏ−ｂｏｏｔ要素４１３には仮起動に関する情報が定義されている。例えば、ｐｓｅｕｄｏ−ｂｏｏｔ要素４１３のｔｒｉｇｇｅｒ属性４１３１の値には、仮起動を実行するタイミングが指定されている。図中の例では「ｉｎｓｔａｌｌ」とされている。これは、スキャンアプリ３２１のインストール時に仮起動を実行することを示す。また、ｐｌａｔｆｏｒｍ属性４１３２の値には、仮起動を行うプラットフォームが指定されている。図中の例では「ｓａｍｅ」とされている。これは、本起動と同一のプラットフォーム上で仮起動が実行されることを示す。また、ｐｂ要素４１３３のｈｒｅｆ属性の値として、スキャンアプリ３２１の仮起動スクリプト７０のメインスクリプト７１のファイル名（「ＳｃａｎＡｐｐ．ｐｂ」）が指定されている。なお、ｐｓｅｕｄｏ−ｂｏｏｔ要素４１３は、仮起動が必要とされる場合に記録されている。したがって、ｐｓｅｕｄｏ−ｂｏｏｔ要素４１３の有無に応じて、仮起動の要否を判断することができる。

ｘｌｅｔ要素４１４のｖｉｓｉｂｌｅ属性４１４１の値には、スキャンアプリ３２１がオペレーションパネル２０２に画面表示を行うか否かが記録されている。図中の例では「ｖｉｓｉｂｌｅ」とされている。これは、スキャンアプリ３２１が画面表示を行うことを意味する。

なお、図８は、スキャンアプリ３２１のアプリケーション情報の例を示すものであるが、他のアプリケーションについても、同様の形式によってアプリケーション情報が定義される。

続いて、ＳＡＳマネージャ３１は、取得されたアプリケーション管理ファイルに基づいて、複合機１０にインストール可能なアプリケーションを判定し、インストール可能とされたアプリケーションの一覧（例えば、アプリケーション名の一覧）をオペレーションパネル２０２に表示させる（Ｓ１０２、Ｓ１０３）。

操作者は、オペレーションパネル２０２に表示されたアプリケーションの一覧の中から、インストールを行うアプリケーションを選択する。ここでは、スキャンアプリ３２１が選択されたこととする。スキャンアプリ３２１が選択されることにより、スキャンアプリ３２１のインストールの開始要求がＳＡＳマネージャ３１に通知される（Ｓ１０４）。

ＳＡＳマネージャ３１は、インストールの開始要求に応じ、スキャンアプリ３２１のアプリケーション管理ファイルの内容（アプリケーション情報４１０）に従って、スキャンアプリ３２１のインストールをＪＳＤＫプラットフォーム４０に要求する（Ｓ１０５）。ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１をバンドルとしてインストールする（Ｓ１０６）。

続いて、ＳＡＳマネージャ３１は、アプリケーション情報４１０に仮起動の指示（ｐｓｅｕｄｏ−ｂｏｏｔ要素４１３）が記録されているか否かを確認し、当該指示が記録されている場合は、スキャンアプリ３２１の仮起動を開始する（Ｓ１０７）。仮起動サービス３３３が起動されていない場合、ＳＡＳマネージャ３１は、仮起動サービス３３３の起動を開始する（Ｓ１０８）。まず、ＳＡＳマネージャ３１が、ＪＳＤＫプラットフォーム４０に対して仮起動サービス３３３のインストール要求を行うと（Ｓ１０９）、ＪＳＤＫプラットフォーム４０は、仮起動サービス３３３をインストールする（Ｓ１１０）。続いて、ＳＡＳマネージャ３１が、ＪＳＤＫプラットフォーム４０に対して仮起動サービス３３３の起動要求を行うと（Ｓ１１１）、ＪＳＤＫプラットフォーム４０は、仮起動サービス３３３を起動する（Ｓ１１２）。

仮起動サービス３３３は、起動されると自ら（仮起動サービス３３３）が提供できるサービスのインタフェース情報をＪＳＤＫプラットフォーム４０に登録する（Ｓ１１３）。続いて、仮起動サービス３３３は、リクエスト経路制御部５０のインタフェース情報をＪＳＤＫプラットフォーム３３３より取得する（Ｓ１１４）。ここで、インタフェース情報とは、リクエスト経路制御部５０を呼び出すために必要とされる情報をいう。なお、リクエスト経路制御部５０は、複合機１０の起動時等において起動され、その際にインタフェース情報がＪＳＤＫプラットフォーム４０に登録されている。

続いて、ＳＡＳマネージャ３１は、ＪＳＤＫプラットフォーム４０より仮起動サービス３３３のインタフェース情報を取得する（Ｓ１１５）。続いて、ＳＡＳマネージャ３１は、アプリケーション情報４１０のｐｂ要素４１３３を参照し、ｐｂ要素４１３３にそのファイル名（「ＳｃａｎＡｐｐ．ｐｂ」）が指定されているメインスクリプト７１を取得する。ＳＡＳマネージャ３１は、メインスクリプト７１とスキャンアプリ３２１のアプリケーション名とを仮起動サービス３３３に転送することにより、スキャンアプリ３２１の仮起動の制御を仮起動サービス３３３に要求する（Ｓ１１６）。

図９は、第一の実施の形態におけるメインスクリプトの定義例を示す図である。図９に記述されたメインスクリプト７１の各記述の内容は、当該記述が実行されるステップにおいて説明する。なお、本実施の形態において、メインスクリプト７１や、シナリオスクリプト７２及び振る舞いスクリプト７３は、対象とするアプリケーションと同じＳＤカード内に記録されている。

仮起動サービス３３３は、仮起動の対象とされたスキャンアプリ３２１のアプリケーション名をリクエスト経路制御部５０に通知し、スキャンアプリ３２１からのネイティブサービスレイヤ６０に対する呼び出し要求（メッセージ）を仮起動サービス３３３に通知するように、リクエスト経路制御部５０に要求する（Ｓ１１７）。リクエスト経路制御部５０は、ここで通知されるアプリケーション名を保持しておき、仮起動の対象とされているアプリケーションを識別する。

続いて、仮起動サービス３３３は、メインスクリプト７１の記述７１１を実行する。記述７１１には、ファイル名が「ＳｃａｎＡｐｐ．ｓ」であるシナリオスクリプト７２と、ファイル名が「ＳｃａｎＡｐｐ．ｂ」である振る舞いスクリプト７３とを使用して仮起動を実行することが定義されている。したがって、仮起動サービス３３３は、シナリオサービス３３４を起動（生成）し、シナリオサービス３３４に対してシナリオスクリプト７２（ＳｃａｎＡｐｐ．ｓ）を転送する（Ｓ１１８）。また、仮起動サービス３３３は、振る舞いサービス３３５を起動（生成）し、振る舞いサービス３３５に対して振る舞いスクリプト７３（ＳｃａｎＡｐｐ．ｂ）を転送する（Ｓ１１９）。

図１０は、第一の実施の形態におけるシナリオスクリプトの定義例を示す図である。図１０に記述されたシナリオスクリプト７２には、スキャンアプリ３２１の操作画面の表示後、３秒経過してからスタートボタンを押下し、操作画面に「Ｃｏｍｐｌｅｔｅ」という文字の表示が確認できたらシナリオ通り動作したと判断することが定義されている。斯かる定義は、スキャンアプリ３２１の操作画面が以下のようなものであることが前提とされている。

図１１は、スキャンアプリの操作画面の例を示す図である。図１１には、二つの操作画面が表示されている。左側の操作画面５１０ａは、初期状態（操作画面の表示直後の状態）を示す。右側の操作画面５１０ｂは、スキャンアプリ３２１の正常終了時の状態を示す。なお、以下において双方を区別しない場合、「操作画面５１０」という。

本実施の形態において、操作画面５１０は、対象がスキャンアプリ３２１であることを示すラベル５１１と、スタートボタン５１２と、Ｒｅｓｕｌｔラベル５１３とより構成される。スタートボタン５１２は、スキャンアプリ３２１の実行の開始指示をユーザに入力させるためのボタンである。Ｒｅｓｕｌｔラベル５１３は、スキャンアプリ３２１の処理結果が表示されるラベルであり、正常終了した場合（スキャンに成功した場合）、操作画面５１０ｂに示されるように、「Ｃｏｍｐｌｅｔｅ」という文字列が表示され、異常終了した場合（スキャンに失敗した場合）、例えば、「Ｅｒｒｏｒ」という文字列が表示される。なお、操作画面５１０ａに示されるように、初期状態では、Ｒｅｓｕｌｔラベル５１３には何も表示されない。

また、図１２は、第一の実施の形態における振る舞いスクリプトの定義例を示す図である。振る舞いスクリプト７３における各記述は、ステップごとに実行される定義ではなく、振る舞いサービス３３５に対する設定情報としての意味を持つ。すなわち、記述７３１では、スキャンサービス（ネイティブサービスレイヤ６０においてスキャナ（撮像部１２１）に関するサービスを提供するモジュール）に関する要求等に関しては、正常動作をしたように振る舞う（エミュレートする）ことが設定されている。また、記述７３２では、パネルサービス（ネイティブサービスレイヤ６０においてオペレーションパネル２０２に関するサービスを提供するモジュール）に関する要求等に関しては、正常動作したように振る舞う（エミュレートする）ことが設定されている。

続いて、ＳＡＳマネージャ３１は、ＪＳＤＫプラットフォーム４０に対してスキャンアプリ３２１の起動要求を行う（Ｓ１２０）。但し、スキャンアプリ３２１は仮起動サービス３３３によって、仮起動となる。ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１の起動要求に応じ、スキャンアプリ３２１の状態をｉｎｉｔ状態へ遷移させ、スキャンアプリ３２１がｉｎｉｔ状態に遷移したことをロギングサービス４２に通知する（Ｓ１２１）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。

仮起動ログ８０は、例えば、以下のような構文によってファイルに記録される。図１３は、仮起動ログの構文の例を説明するための図である。図１３では、一行分（一回の記録分）の仮起動ログの構文がツリー形式によって記載されている。ツリーの各ノードは、仮起動ログを構成する項目を示す。

図示されるように、仮起動ログ８０には、第１項目として番号、第２項目として日付、第３項目として時刻、第４項目としてアプリ名が記録される。番号は、ログの記録順を示す番号である。日付及び時刻は、当該ログが記録された日時である。アプリ名は、仮起動されているアプリケーションのアプリケーション名である。但し、プロダクトＩＤでもよい。続いて、第５項目には、ログの記録内容の種別が記録される。種別としては、「Ｂｕｎｄｌｅ」、「Ｍｅｍｏｒｙ」、「Ｓｃａｎ」、「Ｐａｎｅｌ」、又は「ｈｄｄ」が記録される。

「Ｂｕｎｄｌｅ」は、バンドル（アプリケーション）の状態遷移に関するログであることを示す。この場合、第６項目には、遷移後のバンドルの状態として、例えば、「ｉｎｉｔＳｔａｔｅ」又は「ａｃｔｉｖｅＳｔａｔｅ」が記録される。「ｉｎｉｔＳｔａｔｅ」は、ｉｎｉｔ状態を示す。「ａｃｔｉｖｅＳｔａｔｅ」は、ａｃｔｉｖｅ状態を示す。

「Ｍｅｍｏｒｙ」は、メモリの確保又は開放に関するログであることを示す。この場合、第６項目には、当該アプリケーションによるヒープメモリの消費量の合計値が「Ｈｅａｐ＝＜Ｓｉｚｅ＞」の形式で記録される。第７項目には、当該アプリケーションによるスタック領域の消費量の合計値が「Ｓｔａｃｋ＝＜Ｓｉｚｅ＞」の形式で記録される。第８項目には、新たにメモリが確保された対象の種別として、例えば、「Ｏｂｊｅｃｔ」が記録される。「Ｏｂｊｅｃｔ」は、オブジェクトを示す。第９項目には、新たにメモリが確保された対象の型又はクラス名とそのサイズが記録される。なお、図中では、「Ｈｅａｐ」、「Ｓｔａｃｋ」、及び「Ｏｂｊｅｃｔ」が選択的な関係であるかのように記載されているが、上記のように、各項目が直列的に記録される。

「Ｓｃａｎ」は、スキャナ（撮像部１２１）の操作に関するログであることを示す。この場合、第６項目として、スキャナに関する操作の種別として、例えば、「ｓｅｔｕｐ」、「ｓｔａｒｔ」、又は「ｃｏｍｐｌｅｔｅ」が記録される。「ｓｅｔｕｐ」は、スキャナのセットアップを示す。「ｓｔａｒｔ」は、スキャンの開始を示す。「ｃｏｍｐｌｅｔｅ」は、スキャンの成功を示す。「ｓｅｔｕｐ」の場合、第６項目として、属性設定を意味する値（「ａｔｔｒｉｂｕｔｅ」）が記録され、第７項目として、モノクロスキャン（「ｍｏｎｏ」）であるのか、カラースキャン（「ｃｏｌｏｒ」）であるのかが記録される。

「Ｐａｎｅｌ」は、オペレーションパネル２０２の操作に関するログであることを示す。この場合、第６項目には、オペレーションパネル２０２の操作の種別として、例えば、「ｓｈｏｗ」が記録される。「ｓｈｏｗ」は、オペレーションパネル２０２に対する情報（画面又はメッセージ等）の表示を示す。

「ｈｄｄ」は、ＨＤＤ２３３の操作に関するログであることを示す。この場合、第６項目には、操作の種別として、例えば「ｒｅａｄ」又は「ｗｒｉｔｅ」が記録される。「ｒｅａｄ」は情報の読み取りを示す。「ｗｒｉｔｅ」は情報の書き込みを示す。

図１４は、仮起動ログの具体例を示す図である。図１４に示される仮起動ログ８０は、図１３において説明した構文に従って記録された例である。図１４では、各項目の値がカンマによって区切られたＣＳＶ（Comma Separated Values）形式によって記録された例が示されている。図中、１行目は、ステップＳ１２１の通知に応じて記録されるログの例を示す。すなわち、「０００１」は、番号を示し、「２００７．０５．１０」は、日付を示し、「１１：３０：２４：０４」は時刻を示し、「ＳｃａｎＡｐｐ」は、スキャンアプリ３２１のアプリケーション名を示す。また、第５項目が「Ｂｕｎｄｌｅ」であり、第６項目が「ｉｎｉｔＳｔａｔｅ」であることから、１行目のログは、スキャンアプリ３２１がｉｎｉｔ状態に遷移したことを記録したものであることが分かる。

図７に戻る。ステップＳ１２１に続いて、ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１の起動要求に応じ、スキャンアプリ３２１の状態をａｃｔｉｖｅ状態へ遷移させ、スキャンアプリ３２１がａｃｔｉｖｅ状態に遷移したことをロギングサービス４２に通知する（Ｓ１２２）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の２行目に相当する。なお、図７では、便宜上、スキャンアプリ３２１のｐａｕｓｅ状態への遷移は省略されている。

続いて、ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１のバンドルを起動する（Ｓ１２３）。スキャンアプリ３２１は、起動されると、スキャンアプリ３２１自身が使用するサービスバンドル３３のインタフェース情報をＪＳＤＫプラットフォーム４０より取得する（Ｓ１２４）。ここでは、スキャンサービス３３１及びパネルサービス３３２のインタフェース情報が取得される。なお、スキャンサービス３３１及びパネルサービス３３２は、複合機１０の起動時等において起動され、その際にインタフェース情報がＪＳＤＫプラットフォーム４０に登録されている。

続いて、スキャンアプリ３２１は、スキャンサービス３３１のインタフェース情報に基づいて、スキャンサービス３３１を利用するために必要とされるスキャンサービス３３１のオブジェクト（ＳｃａｎＳｅｒｖｉｃｅクラスのインスタンス）を生成する。以降、スキャンアプリ３２１からスキャンサービス３３１への要求の通知は、厳密には当該オブジェクトを介して行われる。スキャンサービス３３１等のサービスバンドル３３のオブジェクトの生成は、セキュリティマネージャ４１によるアクセス制御の対象とされる。したがって、スキャンサービス３３１のオブジェクトの生成は、当該オブジェクトのコンストラクタにおいてセキュリティマネージャ４１に通知される（Ｓ１２５）。セキュリティマネージャ４１は、当該通知に応じて、オブジェクトの生成元（スキャンアプリ３２１）のクラス名を識別し、スキャンアプリ３２１によってメモリが消費されたことを、そのクラス名及びオブジェクトのサイズと共にロギングサービス４２に通知する（Ｓ１２６）。オブジェクトのサイズは、クラス名に基づいて判定することができる。なお、セキュリティマネージャ４１が、オブジェクトの生成元をどのように識別するかについては後述する。

ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の３行目に相当する。図１４の３行目には、「Ｍｅｍｏｒｙ，Ｈｅａｐ＝２ＭＢ，Ｓｔａｃｋ＝１００ＫＢ，Ｏｂｊｅｃｔ，ＳｃａｎＳｅｒｖｉｃｅ＝１ＭＢ」と記録されている。これは、スキャンアプリ３２１によるヒープメモリの現在の総消費量は２ＭＢ、スタック領域の現在の総消費量は１００ＫＢで、ＳｃａｎＳｅｒｖｉｃｅクラスのオブジェクトが生成され、そのサイズは１ＭＢであることを示す。

続いて、スキャンアプリ３２１は、スキャンサービス３３１のインタフェース情報に基づいて、スキャンアプリ３２１の振る舞いに対応したスキャン処理を構築するための初期設定（すなわち、モノクロスキャンの初期設定）をスキャンサービス３３１に対して行う（Ｓ１２７）。スキャンサービス３３１は、スキャンアプリ３２１からの初期設定要求をリクエスト経路制御部５０を介してネイティブサービスレイヤ６０に通知しようとする（Ｓ１２８）。但し、初期設定の要求元のスキャンアプリ３２１は仮起動中であるため、リクエスト経路制御部５０は、初期設定要求をネイティブサービスレイヤ６０へは通知せず、振る舞サービス３３５に通知する（Ｓ１２９）。なお、リクエスト経路制御部５０が、呼び出し元（ここでは、初期設定の要求元）が仮起動中であるか否かをどのように判定するかについては後述する。

振る舞いサービス３３５は、スキャナの初期設定のエミュレーションを行い、その処理結果をリクエスト経路制御部５０経由で要求元（スキャンアプリ３２１）へ通知する。ここでは、振る舞いスクリプト７３の記述７３１における設定に従って、正常に初期設定が行われたことが通知される。したがって、スキャンアプリ３２１は、スキャンの初期設定は正常に行われたものと判断する。なお、スキャンアプリ３２１が仮起動中でなければ（本起動中であれば）、リクエスト経路制御部５０に通知された要求は、ネイティブサービスレイヤ６０に通知され、実際に初期設定が行われる。

続いて、振る舞いサービス３３５は、モノクロスキャンの初期設定が要求されたことをロギングサービス４２に通知する（Ｓ１３０）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の４行目に相当する。振る舞いサービス３３５は、また、モノクロスキャンの初期設定（のエミュレーション）が完了したことをシナリオサービス３３４に通知する（Ｓ１３１）。シナリオサービス３３４は、アプリケーションの擬似的な操作者として機能するサービスである。したがって、オペレーションパネル２０２に、アプリケーションの操作画面５１０ａが表示されるまでは機能することができない。よって、シナリオサービス３３４は、オペレーションパネル２０２への操作画面５１０ａの描画（表示）の完了が通知されるまでは、シナリオスクリプト７２の定義内容の実行は開始せずに、振る舞いサービス３３５からの通知は無視する。

なお、振る舞いサービス３３５による、ロギングサービス４２及びシナリオサービス３３４への通知は、振る舞いサービス３３５に予め組み込まれているロジックによって実行される処理である（振る舞いスクリプト７３に基づいて実行される処理ではない。）。すなわち、振る舞いスクリプト３３５は、リクエスト経路制御部５０によって経路変更されたサービス要求が通知されたときは、当該サービス要求を受けたことをロギングサービス４２に通知すると共に、該サービス要求に応じて振る舞いサービス３３５がエミュレーションした結果をシナリオサービス４２に通知するように実装されている。

続いて、スキャンアプリ３２１は、パネルサービス３３２のインタフェース情報に基づいて、パネルサービス３３２を利用するために必要とされるパネルサービス３３２のオブジェクト（ＰａｎｅｌＳｅｒｖｉｃｅクラスのインスタンス）を生成する。以降、スキャンアプリ３２１からパネルサービス３３２への要求の通知は、厳密には当該オブジェクトを介して行われる。パネルサービス３３２のオブジェクトの生成は、当該オブジェクトのコンストラクタにおいてセキュリティマネージャ４１に通知される（Ｓ１３２）。セキュリティマネージャ４１は、当該通知に応じて、オブジェクトの生成元（スキャンアプリ３２１）のクラス名を識別し、スキャンアプリ３２１によってメモリが消費されたことを、そのクラス名及びオブジェクトのサイズと共にロギングサービス４２に通知する（Ｓ１３３）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の５行目に相当する。図１４の５行目には、「Ｍｅｍｏｒｙ，Ｈｅａｐ＝３ＭＢ，Ｓｔａｃｋ＝３００ＫＢ，Ｏｂｊｅｃｔ，ＰａｎｅｌＳｅｒｖｉｃｅ＝１ＭＢ」と記録されている。これは、スキャンアプリ３２１によるヒープメモリの現在の総消費量は３ＭＢ、スタック領域の現在の総消費量は３００ＫＢで、ＰａｎｅｌＳｅｒｖｉｃｅクラスのオブジェクトが生成され、そのサイズは１ＭＢであることを示す。

続いて、スキャンアプリ３２１は、パネルサービス３３２のインタフェース情報を用いて、スキャンアプリ３２１の操作画面５１０ａのオペレーションパネル２０２の描画要求をパネルサービス３３２に通知する（Ｓ１３４）。

続いて、パネルサービス３３２は、スキャナアプリ３２１の操作画面５１０ａをオペレーションパネル２０２に描画させるためにネイティブサービスレイヤ６０に通知すべき画面情報を構築（生成）し、当該画面情報に基づく操作画面５１０ａの描画要求をリクエスト経路制御部５０を介してネイティブサービスレイヤ６０に通知しようとする（Ｓ１３５）。但し、操作画面５１０ａの描画の要求元のスキャンアプリ３２１は仮起動中であるため、リクエスト経路制御部５０は、描画要求をネイティブサービスレイヤ６０へは通知せず、画面情報と共に振る舞いサービス３３５に通知する（Ｓ１３６）。

振る舞いサービス３３５は、画面情報に基づく操作画面５１０ａの描画のエミュレーションを行う。その結果、仮想的に操作画面５１０ａの描画が行われる。ここで「仮想的に」とは、実際には、オペレーションパネル２０２には操作画面５１０ａが表示されないことをいう。但し、振る舞いサービス３３５内において、操作画面５１０ａの画面情報は保持される。続いて、振る舞いサービス３３５は、操作画面５１０ａの描画のエミュレーションの結果をリクエスト経路制御部５０経由で要求元（スキャンアプリ３２１）へ通知する。ここでは、振る舞いスクリプト７３の記述７３２における設定に従って、正常に描画が行われたことが通知される。

続いて、振る舞いサービス３３５は、操作画面５１０ａの描画が要求されたことをロギングサービス４２に通知する（Ｓ１３７）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の６行目に相当する。振る舞いサービス３３５は、また、操作画面５１０ａの描画（のエミュレーション）が完了したことをシナリオサービス３３４に通知する（Ｓ１３８）。

操作画面５１０ａの描画の完了の通知に応じ、シナリオサービス３３４は、シナリオスクリプト７２の定義内容に応じた処理を開始する。まず、図１０の記述７２１に基づいて、操作画面５１０ａ（図１１）におけるスタートボタン５１２のオブジェクト（以下、「スタートボタンオブジェクト」という。）を取得する。スタートボタンオブジェククトは、操作画面５１０の画面情報を構成するオブジェクト群の一つであり、記述７２１に記載される関数の呼び出しに応じて、振る舞いサービス３３５より取得される。続いて、記述７２２に記載された関数に基づいて、当該関数の引数に指定された時間（３秒間）待機する。続いて、記述７２３に基づいて、スタートボタン５１２が押下されたことを示すメッセージをリクエスト経路制御部５０に通知する（Ｓ１３９）。なお、スタートボタン５１２の押下の通知を行うまでに３秒間待機するのは、シナリオサービス３３４による擬似的な操作入力を、実際のユーザによる操作入力により近いものとするためである。すなわち、実際のユーザは、操作画面５１０ａの表示直後にスタートボタン５１２を押下することはなく、だいたい３秒くらいたってから、操作入力を開始するからである。

続いて、シナリオサービス３３４は、シナリオスクリプト７２の記述７２４に基づいて、操作画面５１０のＲｅｓｕｌｔラベル５１３のオブジェクト（以下「Ｒｅｓｕｌｔラベルオブジェクト」という。）を取得する。Ｒｅｓｕｌｔラベルオブジェクトは、操作画面５１０の画面情報を構成するオブジェクト群の一つであり、記述７２４に記載される関数の呼び出しに応じて、振る舞いサービス３３５より取得される。

続いて、シナリオサービス３３４は、シナリオスクリプト７２の記述７２５に基づいて、Ｒｅｓｕｌｔラベル５１３が更新されるまで待機状態となる。したがって、記述７２６以降の処理は、この段階では実行されない。

一方、ステップＳ１３９において、シナリオサービス３３４よりスタートボタン５１２の押下の通知するメッセージを受けたリクエスト経路制御部５０は、当該メッセージをパネルサービス３３２に通知する（Ｓ１４０）。

パネルサービス３３２は、スタートボタン５１２の押下の通知を受けて、スキャンアプリ３２１に対して、スタートボタン５１２が押下されたことを通知する（Ｓ１４１）。スキャンアプリ３２１は、スタートボタン５１２の押下の通知を受けて、スキャンサービス３３１に対してスキャンの開始を要求する（Ｓ１４２）。スキャンサービス３３１は、スキャンアプリ３２１からのスキャン開始要求をリクエスト経路制御部５０を介してネイティブサービスレイヤ６０に通知しようとする（Ｓ１４３）。但し、スキャン開始の要求元のスキャンアプリ３２１は仮起動中であるため、リクエスト経路制御部５０は、スキャン開始要求をネイティブサービスレイヤ６０へは通知せず、振る舞サービス３３５に通知する（Ｓ１４４）。

続いて、振る舞いサービス３３５は、スキャンの開始が要求されたことをロギングサービス４２に通知する（Ｓ１４５）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の７行目に相当する。振る舞いサービス３３５は、また、スキャンが開始されることをシナリオサービス３３４に通知する（Ｓ１４６）。ここで、シナリオサービス３３４は、Ｒｅｓｕｌｔラベル５１３の更新待ち状態であるため、何も行わない。

続いて、振る舞いサービス３３５は、スキャンのエミュレーションを行い、その処理結果をリクエスト経路制御部５０へ通知する（Ｓ１４７）。ここでは、振る舞いスクリプト７３の記述７３１における設定に従って、正常にスキャンが行われたこと（正常終了）を示すメッセージが通知される。振る舞いサービス３３５は、また、スキャンの正常終了をロギングサービス４２及びシナリオサービス３３４に通知する（Ｓ１４８、Ｓ１４９）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の８行目に相当する。また、シナリオサービス３３４は、Ｒｅｓｕｌｔラベル５１３の更新待ち状態であるため、スキャンの正常終了の通知に応じて何も行わない。

一方、ステップＳ１４７において、振る舞いサービス３３５よりスキャンの正常終了を通知するメッセージを受けたリクエスト経路制御部５０は、当該メッセージをスキャンサービス３３１に通知する（Ｓ１５０）。スキャンサービス３３１は、スキャン開始の要求元であるスキャンアプリ３２１にスキャンの正常終了を通知する（Ｓ１５１）。

スキャンアプリ３２１は、スキャンの正常終了の通知を受けて、操作画面５１０のＲｅｓｕｌｔラベル５１３に文字列「Ｃｏｍｐｌｅｔｅ」を表示させるようにパネルサービス３３２に対して要求する（Ｓ１５２）。パネルサービス３３２は、スキャンアプリ３２１からの要求を受けて、文字列「Ｃｏｍｐｌｅｔｅ」の表示要求をリクエスト経路制御部５０を介してネイティブサービスレイヤ６０に通知しようとする（Ｓ１５３）。但し、文字列「Ｃｏｍｐｌｅｔｅ」の表示要求の要求元のスキャンアプリ３２１は仮起動中であるため、リクエスト経路制御部５０は、文字列「Ｃｏｍｐｌｅｔｅ」の表示要求をネイティブサービスレイヤ６０へは通知せず、振る舞サービス３３５に通知する（Ｓ１５４）。

振る舞いサービス３３５は、仮想的に、Ｒｅｓｕｌｔラベル５１３に文字列「Ｃｏｍｐｌｅｔｅ」を表示させる。具体的には、保持している画面情報におけるＲｅｓｕｌｔラベルオブジェクトに対して、文字列「Ｃｏｍｐｌｅｔｅ」をセットすることにより、文字列「Ｃｏｍｐｌｅｔｅ」の表示処理のエミュレーションを行う。続いて、振る舞いサービス３３５は、エミュレーションの結果をリクエスト経路制御部５０経由で要求元（スキャンアプリ３２１）へ通知する。ここでは、振る舞いスクリプト７３の記述７３２における設定に従って、正常に文字列「Ｃｏｍｐｌｅｔｅ」の表示が行われたことが通知される。

続いて、振る舞いサービス３３５は、操作画面５１０の更新が要求されたことをロギングサービス４２に通知する（Ｓ１５５）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の９行目に相当する。振る舞いサービス３３５は、また、Ｒｅｓｕｌｔラベル５１３に文字列「Ｃｏｍｐｌｅｔｅ」が表示されたことをシナリオサービス３３４に通知する（Ｓ１５６）。

シナリオサービス３３４は、当該通知に応じて、Ｒｅｓｕｌｔラベル５１３が更新されるまでの待機状態から復帰し、シナリオスクリプト７２（図１０）の記述７２６に基づいて、Ｒｅｓｕｌｔラベル５１３に表示された文字列が、「Ｃｏｍｐｌｅｔｅ」であるか否かを判定する。Ｒｅｓｕｌｔラベル５１３に表示された文字列が、「Ｃｏｍｐｌｅｔｅ」である場合、シナリオサービス３３４は、記述７２７に基づいて、仮起動の対象とされているアプリケーション（スキャンアプリ３２１）はシナリオ通り動作たこと（シナリオの成功）を仮起動サービス３３３に通知する（Ｓ１５７）。一方、Ｒｅｓｕｌｔラベル５１３に表示された文字列が、「Ｃｏｍｐｌｅｔｅ」でない場合、シナリオサービス３３４は、記述７２８に基づいて、仮起動の対象とされているアプリケーションはシナリオ通り動作しなかったこと（シナリオの失敗）を仮起動サービス３３３に通知する。

仮起動サービス３３３は、シナリオの成功の通知を受けると、メインスクリプト７１（図９）の記述７１２に基づいて、アプリケーション名が「ＳｃａｎＡｐｐ」のアプリケーション（スキャンアプリ３２１）の仮起動ログの検索をロギングサービス４２に要求する。ロギングサービス４２は、アプリケーション名に基づいて、仮起動ログ８０よりスキャンアプリ３２１の仮起動ログを検索し、その検索結果を仮起動サービス３３３に通知する（Ｓ１５９）。図１４の仮起動ログ８０には、スキャンアプリ３２１のログ情報のみが記録された例が示されている。したがって、ここでは、図１４に示される仮起動ログ８０の９行目までの内容がそのまま仮起動サービス３３３に通知される。

続いて、仮起動サービス３３３は、メインスクリプト７１（図９）の記述７１３に基づいて、仮起動の成否の判定を行う。記述７１３では、消費メモリが５ＭＢ以下であること、ＨＤＤ２３３への書き込みが無いこと、及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって、仮起動サービス３３３は、仮起動ログ８０内おいて、「Ｍｅｍｏｒｙ，Ｈｅａｐ＝×××ＭＢ」という形式で記録されているヒープメモリの消費量のログの中で最大値を検索し、当該最大値が５ＭＢ以下であるか否かを確認する。また、仮起動サービス３３３は、仮起動ログ８０内において、「ｈｄｄ，ｗｒｉｔｅ」といった記述を検索し、ＨＤＤ２３３への書き込みの有無を確認する。更に、仮起動サービス３３３は、仮起動ログ８０内において、「Ｓｃａｎ，ｓｅｔｕｐ，ａｔｔｒｉｂｕｔｅ，ｍｏｎｏ」といった記述を検索し、スキャンモードがモノクロであるか否かを確認する。

本実施の形態における仮起動ログ８０によれば、ヒープメモリの消費量の最大値は５行目より３ＭＢであり、５ＭＢ以下である。また、「ｈｄｄ，ｗｒｉｔｅ」といった記述は存在せず、ＨＤＤ２３３への書き込みは行われていない。更に、４行目に「Ｓｃａｎ，ｓｅｔｕｐ，ａｔｔｒｉｂｕｔｅ，ｍｏｎｏ」といった記述が存在し、スキャンモードはモノクロである。したがって、仮起動の成功条件は満たされている。そこで、仮起動サービス３３３は、メインスクリプト７１の記述７１４に基づいて、仮起動は成功したことをＳＡＳマネージャ３１に通知する（Ｓ１６０）。

ＳＡＳマネージャ３１は、仮起動の成功通知を受けて、仮起動中のスキャンアプリ３２１を終了させるようにＪＳＤＫプラットフォーム４０に要求する（Ｓ１６１）。ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１をｄｅｓｔｒｏｙ状態へ遷移させることをロギングサービス４２に通知する（Ｓ１６２）。ロギングサービス４２は、通知された情報を仮起動ログ８０として記録する。ここで、記録されるログは、図１４の１０行目に相当する。続いて、ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１を終了させる（Ｓ１６３）。

一方、ＳＡＳマネージャ３１は、ステップＳ１６１においてスキャンアプリ３２１の終了を要求した後、スキャンアプリ３２１のインストールが完了したことをオペレーションパネル２０２に表示させる（Ｓ１６４）。当該表示によって、操作者は、スキャンアプリ３２１が正常にインストールされたことを認識する（Ｓ１６５）。そこで、操作者は、スキャンアプリ３２１を利用するため、スキャンアプリ３２１の本起動の指示をオペレーションパネル２０２を介して入力する（Ｓ１６６）。スキャンアプリ３２１の本起動の指示は、ＳＡＳマネージャ３１に通知される（Ｓ１６７）。ＳＡＳマネージャ３１は、ＪＳＤＫプラットフォーム４０に対して、スキャンアプリ３２１の本起動を要求する（Ｓ１６８）。ＪＳＤＫプラットフォーム４０は、スキャンアプリ３２１を本起動させる（Ｓ１６９）。

以降、本起動されたスキャンアプリ３２１にからの要求は、リクエスト経路制御部５０によって経路変更されずにネイティブサービスレイヤ６０に通知される。したがって、実際に、操作画面の表示が行われ、操作画面を介した操作者からの入力に応じ、スキャンが実行される。

なお、仮起動に失敗した場合、例えば、仮起動されたスキャンアプリ３２１がシナリオ通りに動作しなかった場合、又は、仮起動の成功の条件（メインスクリプト７１の記述７１３）が満たされなかった場合は、ステップＳ１６０において、仮起動サービス３３３は、メインスクリプト７１（図９）の記述７１５に基づいて、仮起動の失敗をＳＡＳマネージャ３１に通知する。当該通知に応じ、ＳＡＳマネージャ３１は、スキャンアプリ３２１のインストールに失敗したことをオペレーションパネル２０２に表示させ、スキャンアプリ３２１のインストールを無効とする。したがって、操作者はスキャンアプリ３２１を本起動させること（実際に利用すること）はできない。

次に、ステップＳ１２６等において、セキュリティマネージャ４１が、オブジェクトの生成元をどのように識別するかについて説明する。図１５は、セキュリティマネージャによるオブジェクトの生成元の識別方法を説明するための図である。図１５では、スキャンアプリ３２１によってスキャンサービス３３１のオブジェクトが生成される場合を例としている。したがって、図７におけるステップＳ１２５及びＳ１２６に対応する。

図中、「ＳｃａｎＡｐｐ」は、スキャンアプリ３２１のクラス名である。「ＳｃａｎＳｅｒｖｉｃｅ」は、スキャンサービス３３１のクラス名である。「ａ：ＳｃａｎＡｐｐ」は、ＳｃａｎＡｐｐクラスのオブジェクトａ（すなわち、インスタンス化されたスキャンアプリ３２１）を示す。また、「ｂ：ＳｃａｎＳｅｒｖｉｃｅ」は、ＳｃａｎＳｅｒｖｉｃｅクラスのオブジェクトｂ（すなわち、インスタンス化されたスキャンサービス３３１）を示す。

オブジェクトａが、ＳｃａｎＳｅｒｖｉｃｅクラスのコンストラクタを呼び出してオブジェクトｂを生成すると（Ｓ２１）、オブジェクトａのクラス名（「ＳｃａｎＡｐｐ」）がスタックに格納される（Ｓ２２）。オブジェクトｂが、そのコンストラクタ内でセキュリティマネージャ４１を呼び出すと（Ｓ２３）、オブジェクトｂのクラス名（「ＳｃａｎＳｅｒｖｉｃｅ」）がスタックに格納される（Ｓ２４）。セキュリティマネージャ４１は、オブジェクトｂからの呼び出しに応じ、スタック内をトレースすることで、呼び出し元のクラス名が「ＳｃａｎＡｐｐ」であること、すなわち、オブジェクトｂの生成元がスキャンアプリ３２１であることを識別することができる（Ｓ２５）。

次に、ステップＳ１２９等において、リクエスト経路制御部５０が、ネイティブサービスレイヤ６０の呼び出し要求元のアプリケーションが仮起動中であるが否かをどのように判定するかについて説明する。まず、前提として、リクエスト経路制御部５０には、仮起動の対象とされているアプリケーションが予め登録される（例えば、ステップＳ１１６）。したがって、リクエスト経路制御部５０内において、呼び出し要求元のアプリケーション名を識別することができれば、当該アプリケーションが仮起動中であるか否かを判定することができる。

本実施の形態では、ＪＳＤＫアプリ３０であるアプリケーションバンドル３２が仮起動の対象とされている。ここで、ＪＳＤＫアプリ３０は、Ｊａｖａ（登録商標）アプリケーションである。したがって、例えば、Ｊａｖａ（登録商標）の標準クラスであるスレッドグループ（ＴｈｒｅａｄＧｒｏｕｐ）を用いて、アプリケーションを識別することができる。スレッドグループとは、スレッド（Ｔｈｒｅａｄ）やスレッドグループの集合であり、一つ以上のＴｈｒｅａｄをＴｒｅａｄＧｒｏｕｐに関連付けることができる。また、スレッドグループには、名前（スレッドグループ名）を付加することができる。そして、各スレッド内では、当該スレッドが属するスレッドグループを識別することができる。なお、本実施の形態において、アプリケーションバンドル３２及びサービスバンドル３３は、「バンドル」として実装されているが、バンドルとは、動的リンク可能なライブラリ（関数又はクラスの集合）である。また、リクエスト経路制御部５０もライブラリ（関数又はクラスの集合）したがって、いずれもプロセスとして起動されるものではなく、呼び出された側は、呼び出し元のスレッド上で動作する。

斯かる仕組みに基づけば、リクエスト経路制御部５０では、以下のように呼び出し元のアプリケーション名を識別することができる。図１６は、スレッドグループを用いた呼び出し元のアプリケーション名の識別方法を説明するための図である。図１６では、便宜上、各モジュールの上下関係が図３と異なっている。

図中、ＧＰｘ（ｘはａ〜ｃ）は、スレッドグループを示す。ｔｈｘ（ｘは、ａ〜ｄ）は、スレッドを示す。図１６の例では、スキャンアプリ３２１には、スレッドグループＧＰｂが関連付けられており、スレッドグループ名としてスキャンアプリ３２１のアプリケーション名が付加されている。また、スキャンサービス３３１にはスレッドグループＧＰｃが関連付けられている。

スキャンアプリ３２１には、メソッドＡを実行中のスレッドｔｈａと、メソッドＢを実行中のスレッドｔｈｂとが存在する。ここで、スレッドｔｈａとスレッドｔｈｂとは、スレッドグループＧＰｂに属する。例えば、スキャンアプリ３２１のメソッドＢ内より、スキャンサービス３３１のメソッドＣが呼び出された場合、メソッドＣは、スレッドｔｈｂ上で動作する。更に、メソッドＣよりリクエスト経路制御部５０の関数Ｄが呼び出された場合、関数Ｄは、スレッドｔｈｂ上で動作する。したがって、関数Ｄ内で、現在のスレッドを確認するとスレッドｔｈｂが特定され、更にスレッドｔｈｂが属するスレッドグループを確認するとスレッドグループＧＰｂが特定される。そこで、関数Ｂ内で、スレッドグループＧＰｂのスレッドグループ名を取得することにより、関数Ｂ（すなわち、リクエスト経路制御部５０）の呼び出し元のアプリケーション名が取得される。更に、取得されたアプリケーション名（スレッドグループ名）と、予め登録されている仮起動中のアプリケーション名とを比較することにより、関数Ｂの呼び出し元が仮起動中であるか否かを判定することができる。

但し、呼び出し元のアプリケーションの識別方法は、必ずしもスレッドグループを用いなくてもよい。例えば、各メソッドや各関数の引数によって呼び出し元のアプリケーション名を引き継ぐようにしてもよい。

上述したように、第一の実施の形態における複合機１０によれば、実際にアプリケーションが利用される前に、当該アプリケーションについて仮起動を実行し、その振る舞いに関するログ（仮起動ログ８０）を記録しておく。そして、仮起動ログ８０に基づいて、予め設定された制限が満たされているか否かを各アプリケーションについて確認することができる。したがって、予め設定された制限を満たしていないアプリケーションの動作を防止することができ、アプリケーションによる不正動作の可能性を低減させることができる。

また、仮起動の成否の判断基準や、仮起動時のアプリケーションに対する操作内容、仮起動時の振る舞いサービス３３５の振る舞いは、プログラムからは分離されたファイルである仮起動スクリプト７０（メインスクリプト７１、シナリオスクリプト７２、振る舞いスクリプト７３）に定義されている。したがって、各アプリケーションや複合機１０の資源の変化（例えば、メモリの増設等）に合わせて、これらの情報（判断基準、操作内容、振る舞い等）を容易に変更することができる。特に、本実施の形態のように、テキスト形式のファイルであれば、その変更は容易である。

また、振る舞いサービス３３５が、ネイティブサービスレイヤ６０として（ネイティブサービスレイヤ６０と同様の形式で）アプリケーションに対する応答を行うため、アプリケーションは、仮起動であるか否かを意識する必要はない。したがって、仮起動を実現するために、各アプリケーションに改めて実装を行う必要はない。

なお、仮起動中は、ネイティブサービスレイヤ６０は呼び出されず、複合機１０に特有のハードウェア（例えば、画像処理を行うためのハードウェア）は利用されない。したがって、仮起動は、一般的なＰＣ（Personal Computer）等のコンピュータにおいて行ってもよい。この場合、当該コンピュータにでは、図３において、ネイティブサービスレイヤ６０以外のソフトウェアが動作可能であればよい。

次に第二の実施の形態について説明する。第一の実施の形態では、仮起動ログ８０に基づいて、アプリケーションごとに消費メモリが制限値（５ＭＢ）以内であるか否かが判定されていた。しかし、複数のアプリケーションが並列的に起動される場合、第一の実施の形態における判定だけでは不十分な場合がある。

図１７は、複数のアプリケーションを並列して起動した場合のメモリの消費の様子を説明するための図である。

図１７において、（Ａ）は、或るアプリケーションバンドル３２（以下「アプリＡ」という。）による、時間の経過（アプリケーションの状態遷移）とヒープメモリの消費量の最大値との関係を示したものである。図示されるように、アプリＡは、ｉｎｉｔ状態、ｐａｕｓｅ状態、ａｃｔｉｖｅ状態の各状態において、それぞれ、最大で３ＭＢ、１ＭＢ、４ＭＢのヒープメモリを消費する。この場合、全状態を通して、アプリＡのヒープメモリの最大の消費量は４ＭＢであり、第一の実施の形態における制限である５ＭＢを満たしている。したがって、アプリＡについては、仮起動は成功であると判定され、本起動が可能となる。

図中（Ｂ）は、アプリＡとは別のアプリケーションバンドル３２（以下「アプリＢ」という。）による、時間の経過（アプリケーションの状態遷移）とヒープメモリの消費量の最大値との関係を示したものである。図示されるように、アプリＢは、ｉｎｉｔ状態、ｐａｕｓｅ状態、ａｃｔｉｖｅ状態の各状態において、それぞれ最大で３ＭＢ、１ＭＢ、１ＭＢのヒープメモリを消費する。この場合、全状態を通して、アプリＢのヒープメモリの最大の消費量は３ＭＢであり、第一の実施の形態における制限である５ＭＢを満たしている。したがって、アプリＢについても、仮起動は成功であると判定され、本起動が可能となる。

図中（Ｃ）は、アプリＡとアプリＢとが同時に起動された場合の時間の経過とヒープメモリの消費量の最大値との関係を示したものである。すなわち、本起動が許可された二つのアプリケーションが同時に起動され、同じタイミングで状態遷移が行われた場合、二つのアプリケーションによって、ｉｎｉｔ状態、ｐａｕｓｅ状態、ａｃｔｉｖｅ状態の各状態において、それぞれ最大で、３＋３＝６ＭＢ、１＋１＝２ＭＢ、１＋４＝５ＭＢのヒープメモリが消費される。そうすると、ｉｎｉｔ状態において、制限値である５ＭＢを超えてしまい、アプリケーションが正常に動作しない可能性がある。

そこで、第二の実施の形態では、斯かる課題を解決した例について説明する。なお、第二の実施の形態は、第一の実施の形態との差分についてのみ説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。

第二の実施の形態において、メインスクリプト７１は、次のように定義される。図１８は、第二の実施の形態におけるメインスクリプトの記述例を示す図である。図１８中、図９と同一部分には同一符号を付し、その説明は省略する。なお、第二の実施の形態において、メインスクリプト７１は、メインスクリプト７１ａとして説明する。

メインスクリプト７１ａは、第一の実施の形態と比較して記述７１６が異なる。すなわち、記述７１６では、スクリプト関数ｐｂＣａｓｅ１のインタフェースが定義されているが、第二の実施の形態では、仮起動ログを格納する変数（ＰｓｅｕｄｏＢｏｏｔＬｏｇ ｌｏｇ）が、参照渡しのＯＵＴ型の引数として定義されている。当該引数の値は、記述７１２において格納される。

第二の実施の形態における、複合機１０の仮起動に関する処理手順は、図７とほぼ同様である。但し、メインスクリプト７１ａにおける記述７１６に基づいて、ステップＳ１６０において、仮起動サービス３３３は、仮起動の成否を示す情報と共に、仮起動ログ８０の内容をＳＡＳマネージャ３１に通知する。ＳＡＳマネージャ３１は、通知された仮起動ログ８０を仮起動の対象とされていたアプリケーションバンドル３２（図７の例ではスキャンアプリ３２１）と関連付けて、例えば、ＨＤＤ２３３に保存し、管理する。関連付けは、例えば、仮起動ログ８０のファイル名を、当該アプリケーションバンドル３２のアプリケーション名とすることにより行ってもよい。

第二の実施の形態では、また、ステップＳ１６７においてアプリケーションの起動要求を受けた際におけるＳＡＳマネージャ３１による、起動中（起動開始時も含む）のアプリケーションの管理に関する処理が異なる。

図１９は、第二の実施の形態におけるＳＡＳマネージャによる起動中のアプリケーションの管理処理を説明するためのフローチャートである。なお、図１９の処理は、本起動のアプリケーション（すなわち、仮起動が成功したアプリケーション）に関して行われる。

複合機１０において、状態遷移（起動によるｉｎｉｔ状態への遷移も含む）の必要なアプリケーション（以下、「アプリＡ」という。）が発生すると（Ｓ２０１でＹｅｓ）、ＳＡＳマネージャ３１は、アプリＡの遷移先の状態のメモリ消費量の最大値と、現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値（例えば、５ＭＢ）以下であるか否かを判定する（Ｓ２０２）。

なお、ＳＡＳマネージャ３１は、アプリＡの遷移先の状態のメモリ消費量の最大値や、各アプリケーションの現在の状態のメモリ消費量の最大値をそれぞれのアプリケーションに関連付けられている仮起動ログ８０に基づいて判定する。また、ＳＡＳマネージャ３１は、状態遷移するアプリケーションの発生を、当該アプリケーションからの通知によって検知する。

メモリ消費量の最大値の合計が制限値以下である場合（Ｓ２０２でＹｅｓ）、ＳＡＳマネージャ３１は、アプリＡの状態遷移を許可する。その結果、アプリＡは、状態遷移を行う（Ｓ２０３）。一方、メモリ消費量の合計が制限値を超えている場合（Ｓ２０２でＮｏ）、ＳＡＳマネージャ３１は、アプリＡの状態遷移を待機させ、アプリＡの状態遷移を待機させていることを示す情報（以下、「待機情報」という。）を状態遷移待機キューに登録する。待機情報は、例えば、アプリＡの識別情報及び遷移先の状態の識別情報等より構成される。但し、遷移先の状態の識別情報の代わりに遷移先の状態のメモリ消費量の最大値を待機情報に含めても良い。そうすることにより、アプリＡの遷移先の状態のメモリ消費量について改めて仮起動ログ８０を参照する処理を省くことができる。また、状態遷移待機キューは、待機情報のキュー又はリストである。すなわち、状態遷移待機キューによって、状態遷移待ちであるアプリケーションの一覧が把握され得る。

ステップＳ２０３において、アプリＡの状態遷移が行われた場合、アプリＡの状態の遷移によって、各アプリのそれぞれの状態のメモリ消費量の最大値の合計が変化する。したがって、状態遷移待ちアプリの状態遷移を許可できる可能性がある。そこで、ＳＡＳマネージャ３１は、ステップＳ２０５以降の処理を実行する。

すなわち、ＳＡＳマネージャ３１は、状態遷移待機キューにおける待機情報の有無を確認することにより、状態遷移待ちのアプリケーションの有無を判定する（Ｓ２０５）。状態遷移待ちのアプリケーションが存在しない場合（状態遷移待機キューが空の場合）（Ｓ２０５でＮｏ）、ステップＳ２０１に戻る。

一方、状態遷移待ちのアプリケーションが存在する場合（Ｓ２０５でＹｅｓ）、ＳＡＳマネージャ３１は、状態遷移待機キューより一つの待機情報を取り出す（Ｓ２０６）。状態遷移待機キューからの待機情報の取り出す順序は、ＦＩＦＯ（First-In First-Out）又はＬＲＵ（Least Recently Used）に従ってもよいし、アプリケーションに優先順位を付け、その優先順位に従ってもよい。当該優先順位は、ＨＤＤ２３３等に予め記録しておけばよい。

続いて、ＳＡＳマネージャ３１は、取り出された待機情報（以下、「カレント待機情報」という。）に係るアプリケーションの遷移先の状態のメモリ消費量の最大値と他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値以下であるか否かを判定する（Ｓ２０７）。

メモリ消費量の最大値の合計が制限値以下であり場合（Ｓ２０７でＹｅｓ）、ＳＡＳマネージャ３１は、カレント待機情報を状態遷移待機キューより削除し（Ｓ２０８）、状態遷移待ちだったアプリケーションの状態を遷移させる（Ｓ２０３）。なお、当該アプリケーションの状態の遷移に応じて、更に、他の状態遷移待ちのアプリケーションの状態遷移の可否を判定するため、続いて、ステップＳ２０５以降の処理が実行される。

一方、ステップＳ２０７において、メモリ消費量の最大値の合計が制限値を超える場合（Ｓ２０７でＮｏ）、ステップＳ２０１に戻る。但し、ステップＳ２０６に戻るようにしてもよい。この場合、状態遷移待機キューにその待機情報が登録されているアプリケーションの中で、制限値内で遷移可能なアプリケーションの状態遷移が優先的に実行される。

以上、図１９において説明したように、アプリケーションの状態遷移を制限することにより、図１７において説明したような状況の発生を回避することがでる。図１７の例に関しては、次のように改善される。図２０は、状態遷移の制限によってメモリ消費量が適切に管理される様子を示す図である。

図２０では、アプリＡのｉｎｉｔ状態とアプリＢのｉｎｉｔ状態が重なると、制限値（５ＭＢ）を超えてしまうため、アプリＡのｉｎｉｔ状態への遷移は、アプリＢのｐａｕｓｅ状態への遷移後に行われている。そうすることにより、アプリＡとアプリＢとの消費メモリの合計値が、全過程を通して、制限値内に抑制されている。

上述したように、第二の実施の形態における複合機１０によれば、複数のアプリケーションが並列的に動作する場合であっても、各アプリケーションの仮起動中に記録された仮起動ログ８０に記録された情報に基づいて、アプリケーションの振る舞い（挙動）を変化させることができる。すなわち、複数のアプリケーションによるメモリ消費量の合計値が、予め設定された制限値以下に維持されるようにすることができる。したがって、アプリケーションによる不正動作の可能性を低減させることができる。

なお、第二の実施の形態では、仮起動時に、全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示した（メインスクリプト７１ａ（図１８）の記述７１３参照）。したがって、当該制限を満たしたアプリケーションのみが、本起動の対象とされる前提で、図１９の処理手順を説明した。しかし、アプリケーションが本起動されるときに、ＳＡＳマネージャ３１が、当該アプリケーションの仮起動ログ８０を参照して、全状態を通したメモリの消費量の最大値を判定し、その最大値が制限値を超える場合は、当該アプリケーションの本起動を拒否するようにしてもよい。この場合、必ずしも仮起動時にメモリの消費量の最大値のチェックを行わなくても良い。すなわち、メインスクリプト７１ａの記述７１３における「ｌｏｇ．Ｍａｘｍｅｍ＜５ＭＢ」という記述を削除してもよい。

また、図１９の処理は、ＪＳＤＫプラットフォーム４０が行うようにしてもよい。

ところで、上記においては、仮起動をアプリケーションの適否の事前チェックのための手段として用いる例について説明した。しかし、仮起動の用途は、これだけに限られない。例えば、アプリケーションの本起動中に発生した障害の原因解析のための手段としても利用することができる。以下、仮起動を障害の原因解析に適用した例を、第三及び第四の実施の形態として説明する。

図２１は、第三の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。図２１において、障害対応サーバ２０は、インターネット等のネットワークを介して複合機１０と接続され、複合機１０を遠隔より監視するコンピュータである。障害対応サーバ２０は、例えば、複合機１０のベンダによって運用される。

操作者による指示に応じ、複合機１０のＳＡＳマネージャ３１は、アプリケーション（例えば、スキャンアプリ３２１）を本起動させる（Ｓ３０１）。アプリケーションの本起動中に障害が発生すると、パネルサービス３３２は、オペレーションパネル２０２に障害が発生したことを通知する警告画面を表示させる（Ｓ３０２）。続いて、ＳＡＳマネージャ３１は、障害対応サーバ２０に障害内容を示す情報（例えば、エラーコード等）を送信する（Ｓ３０３）。

障害対応サーバ２０は、障害内容を示す情報に基づいて、障害の原因を調査するために適切な仮起動スクリプト７０を複合機１０に送信する（Ｓ３０４）。例えば、障害対応サーバ２０の記憶装置には、アプリケーションごと、かつ、障害内容ごとに、当該障害内容の原因を調査するために適切な仮起動スクリプト７０が予め保存されている。障害内容の原因を調査するために適切な仮起動スクリプト７０とは、その障害を解析するために適切なシナリオが定義されたシナリオスクリプト７２や、その障害を解析するための適切なエミュレーションの内容が定義された振る舞いスクリプト７３を含む仮起動スクリプト７０をいう。

複合機１０は、受信した仮起動スクリプト７０を利用して、障害が発生したアプリケーションを仮起動する（Ｓ３０５）。この際の処理手順は、図７において説明した通りである。その結果、仮起動ログ８０が生成される。そこで、複合機１０のＳＡＳマネージャ３１は、仮起動ログ８０を障害対応サーバ２０に送信する（Ｓ３０６）。

障害対応サーバ２０は、仮起動ログ８０を解析し、原因の特定を行う。原因の特定は、自動的に行われても良いし、人的に行われてもよい。原因が特定されると、操作者に障害の解析結果について報告が行われる（Ｓ３０７）。当該報告は、電子メール等によって自動的に行われても良い。また、アプリケーションのバグであった場合、障害対応サーバ２０から修正版を複合機１０にリモートインストールするようにしてもよい。

なお、障害内容ごとの仮起動スクリプト７０を複合機１０に予め保存しておき、複合機１０の傍で、原因の解析を行っても良い。この場合、障害対応サーバ２０は、必ずしも必要ではない。

次に、第四の実施の形態について説明する。第四の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。図２２中、図２１と同一部分には同一符号を付し、その説明は省略する。なお、第四の実施の形態では、障害対応サーバ２０に、ＪＳＤＫアプリ３０、ＪＳＤＫプラットフォーム４０、及びリクエスト経路制御部５０等が実装されていることとする。

図２２において、ステップＳ４０１〜Ｓ４０３は、図２１のステップＳ３０１〜Ｓ３０３と同様である。

続いて、障害対応サーバ２０は、障害内容を示す情報に基づいて、障害の原因を調査するために適切な仮起動スクリプト７０を記憶装置の中から選択する（Ｓ４０４）。続いて、障害対応サーバ２０は、仮起動スクリプト７０を利用して、障害が発生したアプリケーションを仮起動し、その結果生成される仮起動ログ８０を解析し、原因の特定を行う。原因が特定されると、障害対応サーバ２０は、操作者に障害の解析結果について報告を行う（Ｓ４０６）。アプリケーションのバグであった場合、障害対応サーバ２０から修正板を複合機１０にリモートインストールするようにしてもよい。

上述したように、障害に対応した仮起動スクリプト７０に基づいてアプリケーションの仮起動を実行することにより、その結果生成される仮起動ログ８０に基づいて、適切に原因の解析を行うことができる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 複合機
３０ ＪＳＤＫアプリ
３１ ＳＡＳマネージャ
３２ アプリケーションバンドル
３３ サービスバンドル
４０ ＪＳＤＫプラットフォーム
５０ リクエスト経路制御部
６０ ネイティブサービスレイヤ
７０ 仮起動スクリプト
８０ 仮起動ログ
１２１ 撮像部
１２２ 印刷部
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３２１ スキャンアプリ
３３１ スキャンサービス
３３２ パネルサービス
３３３ 仮起動サービス

特開２００５−２６９６１９号公報

Claims (6)

1. 複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置であって、
   前記プログラムの状態を遷移させる管理手段と、
   前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けて、メモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段とを有し、
   前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする情報処理装置。
2. 前記プログラムによるメモリの消費を検知する検知手段と、
   インストール後に初めて起動された前記プログラムに関して、前記管理手段からの状態の遷移の通知に応じ、当該状態の識別情報を前記記憶手段に記録し、前記検知手段からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手段とを有することを特徴とする請求項１記載の情報処理装置。
3. 複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置が実行するプログラム制御方法であって、
   前記プログラムの状態を遷移させる管理手順と、
   前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けて、メモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手順とを有し、
   前記制御手順は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とするプログラム制御方法。
4. 前記プログラムによるメモリの消費を検知する検知手順と、
   インストール後に初めて起動された前記プログラムに関して、前記管理手順からの状態の遷移の通知に応じ、当該状態の識別情報を前記記憶手段に記録し、前記検知手順からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手順とを有することを特徴とする請求項３記載のプログラム制御方法。
5. 複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置を、
   前記プログラムの状態を遷移させる管理手段と、
   前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けて、メモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段として機能させ、
   前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする制御プログラム。
6. 前記プログラムによるメモリの消費を検知する検知手段と、
   インストール後に初めて起動された前記プログラムに関して、前記管理手段からの状態の遷移の通知に応じ、当該状態の識別情報を前記記憶手段に記録し、前記検知手段からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手段として前記情報処理装置を機能させることを特徴とする請求項５記載の制御プログラム。
   

Images