"複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置であって、前記プログラムの状態を遷移させる管理手段と、前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けてメモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段とを有し、前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする情報処理装置。前記プログラムによるメモリの消費を検知する検知手段と、インストール後に初めて起動された前記プログラムに関して、前記管理手段からの状態の遷移の通知に応じ、当該状態の識別情報を記憶手段に記録し、前記検知手段からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手段とを有することを特徴とする請求項1記載の情報処理装置。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値以下であるかを判定する判定手段を有し、前記制御手段は、メモリの消費量の最大値が前記制限値以下であると判定されたプログラムについて、2回目以降の起動を実行することを特徴とする請求項2記載の情報処理装置。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値を超えるときは、該プログラムについて2回目以降の起動を実行しないことを特徴とする請求項2又は3記載の情報処理装置。複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置が実行するプログラム制御方法であって、前記プログラムの状態を遷移させる管理手順と、前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けてメモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手順とを有し、前記制御手順は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とするプログラム制御方法。前記プログラムによるメモリの消費を検知する検知手順と、インストール後に初めて起動された前記プログラムに関して、前記管理手順からの状態の遷移の通知に応じ、当該状態の識別情報を記憶手段に記録し、前記検知手順からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手順とを有することを特徴とする請求項5記載のプログラム制御方法。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値以下であるかを判定する判定手順を有し、前記判定手順において、メモリの消費量の最大値が前記制限値以下であると判定されたプログラムについて、2回目以降の起動を実行することを特徴とする請求項6記載のプログラム制御方法。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値を超えるときは、該プログラムについて2回目以降の起動を実行しないことを特徴とする請求項6又は7記載のプログラム制御方法。複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置を、前記プログラムの状態を遷移させる管理手段と、前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けてメモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段として機能させ、前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする制御プログラム。前記プログラムによるメモリの消費を検知する検知手段と、インストール後に初めて起動された前記プログラムに関して、前記管理手段からの状態の遷移の通知に応じ、当該状態の識別情報を記憶手段に記録し、前記検知手段からの前記メモリの消費の通知に応じ、当該プログラムによるメモリの消費量を前記記憶手段に記録する記録手段として前記情報処理装置を機能させることを特徴とする請求項9記載の情報処理装置。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値以下であるかを判定する判定手段として前記情報処理装置を機能させ、前記判定手段によって、メモリの消費量の最大値が前記制限値以下であると判定されたプログラムについて、2回目以降の起動を実行させることを特徴とする請求項10記載の制御プログラム。インストール後に初めて起動された前記プログラムに関して前記記憶手段に記録されたメモリの消費量の最大値が、予め設定された制限値を超えるときは、該プログラムについて2回目以降の起動を実行させないことを特徴とする請求項10又は11記載の制御プログラム。しかしながら、ソフトウェアベンダにしてみれば、より利便性の高い、高機能なアプリケーションを提供したいといった欲求がある。一般的に、高機能になればなるほど、プログラムによるメモリの消費量は増加する傾向にある。したがって、エンドユーザの利便性を考慮するあまり、リソース制限が遵守されない状態でアプリケーションが市場に提供される可能性がある。また、それぞれのアプリケーションごとにはリソース制限を遵守して作成されている場合であっても、複数のアプリケーションが並列的に利用される場合等、ユーザの利用態様によって、画像形成装置のリソースが枯渇してしまう可能性がある。リソースが枯渇してしまった場合、アプリケーションの動作が保証されず、エンドユーザにとって不利益が生じるだけでなく、画像形成装置のベンダやアプリケーションの開発ベンダにおいても、原因の究明のための作業負担が生じるといった問題がある。本発明は、上記の点に鑑みてなされたものであって、プログラムによる不正動作の可能性を低減させることのできる情報処理装置、プログラム制御方法、及び制御プログラムの提供を目的とする。そこで上記課題を解決するため、本発明は、複数の状態を有し、前記状態ごとに当該状態に応じた処理を実行させるプログラムを追加可能な情報処理装置であって、前記プログラムの状態を遷移させる管理手段と、前記プログラムからの状態の遷移の通知に応じ、当該プログラムの遷移先の状態に対するメモリの消費量を、前記状態に関連付けてメモリの消費量を記憶する記憶手段より取得し、他のプログラムの現在の状態に対するメモリの消費量を前記記憶手段より取得し、取得されたメモリの消費量の合計が予め設定された制限値を超える場合に、当該状態の遷移を当該プログラムに待機させる制御手段とを有し、前記制御手段は、いずれかの前記プログラムからの状態の遷移の通知に応じ、状態の遷移を待機させている前記プログラムの遷移先の状態に対するメモリの消費量と、他のプログラムの現在の状態に対するメモリの消費量との合計が前記制限値以下である場合は、状態の遷移を待機させている前記プログラムの状態を遷移させることを特徴とする。このような情報処理装置では、プログラムによる不正動作の可能性を低減させることができる。本発明によれば、プログラムによる不正動作の可能性を低減させることのできる情報処理装置、プログラム制御方法、及び制御プログラムを提供することができる。図1は、本発明の実施の形態の概要を説明するための図である。本発明の実施の形態において、複合機10は、アプリケーションを追加可能な画像形成装置の一例である。図中、複合機10が上下に二つ記載されているが、これは同一の複合機10を時間の経過に応じて示したものである。本実施の形態において、新たに複合機10にインストールされるアプリケーションについては、まず、仮起動が行われるS11。仮起動とは、アプリケーションによるリソースの消費量や、アプリケーションが利用する複合機10内のサービス機能等これらを示す情報を、以下アプリケーション動作情報という。を調査するためにアプリケーションを起動することをいう。本実施の形態において、仮起動されたアプリケーションは、当該アプリケーションの本来の機能をユーザに対して提供することはできない。仮起動の際中、複合機10は、アプリケーション動作情報を仮起動ログとして出力するS12。仮起動が終了すると、複合機10は、仮起動ログに基づいて仮起動の成否を判定するS13。仮起動の成功とは、仮起動されたアプリケーションの動作が、予め定められた制限リソースの消費量や、利用する複合機10内のサービス等に関する制限の範囲内であることが確認されたことをいう。仮起動の失敗とは、仮起動されたアプリケーションの動作が、予め定められた制限に従っていないことが確認されたことをいう。仮起動が成功すると、当該アプリケーションは複合機10にインストールされ、本起動が可能な状態となる。したがって、ユーザから起動指示があった場合は、本起動が行われるS14。本起動とは、仮起動に対する用語であり、アプリケーション本来の機能を発揮させるためにアプリケーションを起動するこという。すなわち、本起動によって、アプリケーションの通常の使用状態を実現される。本起動の際、複合機10は、仮起動ログに基づいて、アプリケーションの動作を制御する。例えば、アプリケーションの起動を拒否したり、アプリケーションの起動のタイミングを制限したり、アプリケーションの状態遷移処理の進行を制限したり、アプリケーションによる複合機10のサービスの使用を制限したりする。以上のように、複合機10では、新たに追加インストールされるアプリケーションについて、予め仮起動を行い、仮起動の際に取得される仮起動ログに基づいて本起動の際の動作を制御することができる。したがって、予め定められたリソースの消費量等に関する制限を遵守していないアプリケーションの動作を制限したり、複数のアプリケーションが同時に並列的に起動された際において、各アプリケーションのリソースの消費のタイミングを制御したりすることが可能となる。以下、具体的に説明する。図2は、本発明の実施の形態における複合機のハードウェア構成例を示す図である。図2において複合機10は、コントローラ201、オペレーションパネル202、ファクシミリコントロールユニットFCU203、撮像部121、及び印刷部122等を備える。コントローラ201は、CPU211、ASIC212、NB221、SB222、MEM-P231、MEM-C232、HDDハードディスクドライブ233、メモリカードスロット234、NICネットワークインタフェースコントローラ241、USBデバイス242、IEEE1394デバイス243、セントロニクスデバイス244により構成される。CPU211は、種々の情報処理用のICである。ASIC212は、種々の画像処理用のICである。NB221は、コントローラ201のノースブリッジである。SB222は、コントローラ201のサウスブリッジである。MEM-P231は、複合機10のシステムメモリである。MEM-C232は、複合機10のローカルメモリである。HDD233は、複合機10のストレージである。メモリカードスロット234は、メモリカード235をセットするためのスロットである。NIC241は、MACアドレスによるネットワーク通信用のコントローラである。USBデバイス242は、USB規格の接続端子を提供するためのデバイスである。IEEE1394デバイス243は、IEEE1394規格の接続端子を提供するためのデバイスである。セントロニクスデバイス244は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル202は、オペレータが複合機10に入力を行うためのハードウェア操作部であると共に、オペレータが複合機10から出力を得るためのハードウェア表示部である。図3は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。図3において、複合機10のソウトウェアは、JSDKアプリ30、JSDKプラットフォーム40、リクエスト経路制御部50、及びネイティブサービスレイヤ60等より構成されている。これらの各ソフトウェアは、メモリカード235やその他の記憶装置に記録されたプログラムがCPU211によって処理されることにより機能する。ネイティブサービスレイヤ60は、複合機10のハードウェアやソフトウェアに基づく機能を利用させるためのインタフェースを上位モジュールに対して提供し、当該インタフェースの呼び出し機能の利用要求に応じて、当該機能を実現するための制御を行う。例えば、ネイティブサービスレイヤ60には、ネットワーク通信の制御に関するインタフェースを提供するモジュール、ファクシミリの制御に関するインタフェースを提供するモジュール、蓄積文書HDD233に保存されている文書画像データの配信処理の制御に関するインタフェースを提供するモジュール、撮像部121や印刷部122の制御に関するインタフェースを提供するモジュール。メモリやHDD233等の制御に関するインタフェースを提供するモジュール、オペレーションパネル202の制御に関するインタフェースを提供するモジュール、認証処理や課金処理の制御に関するインタフェースを提供するモジュール、ユーザ情報の管理に関するインタフェースを提供するモジュール等が含まれる。JSDKプラットフォーム40は、JSDKアプリ30の実行環境を提供するソフトウェアプラットフォームであり、ネイティブサービスレイヤ60に対するJava登録商標インタフェースを上位モジュールに対して提供する。JSDKプラットフォーム40は、Java登録商標の標準のクラスや、複合機10用に拡張されたクラスに関するクラスライブラリ、及びJava登録商標仮想マシン等を含む。例えば、図中では、JSDKプラットフォーム40の一部として、セキュリティマネージャ41やロギングサービス42が示されている。セキュリティマネージャ41は、予めポリシーファイルに定義されたアクセス制御情報に基づいて、JSDKアプリ30による、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを制限する。すなわち、JSDKプラットフォーム40は、リソースへのアクセスが発生する際に、セキュリティマネージャ41に対する呼び出しが発生するように構成されている。セキュリティマネージャ41は、その呼び出しに応じてリソースへのアクセスの可否を判断する。なお、セキュリティマネージャ41は、Java登録商標の標準におけるSecurityManagerクラスを用いて実現してもよい。ロギングサービス42は、JSDKアプリ30の仮起動の際に、仮起動ログ80を出力する。なお、JSDKプラットフォーム40は、OSGiOpenServiceGatewayinitiativeプラットフォームとして実装されている。OSGiOpenServiceGatewayinitiativeプラットフォームとは、OSGiアライアンスによる標準化技術であり、Java登録商標言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。OSGiプラットフォーム上において、Java登録商標言語のソフトウェアはバンドルと呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのJARJavaARchiveファイルによって構成され、それぞれ独立して動的に装置の再起動を要することなくインストール可能である。JSDKアプリ30は、JSDKプラットフォーム40において公開されている専用のSDKソフトウェア開発キットを使用して作成されたアプリケーション以下SDKアプリという。である。SDKアプリのうち、特にJava登録商標を言語を使用して開発されたアプリケーションをJSDKアプリといい、本実施の形態において仮起動の対象とされる。図中では、JSDKアプリ30の例として、SASSDKApplicationServiceマネージャ31、アプリケーションバンドル32、及びサービスバンドル33等が存在する。SASマネージャ31は、他のJSDKアプリ30アプリケーションバンドル32やサービスバンドル33等のインストール追加、アンインストール削除、起動、及び起動解除等の制御を行う。アプリケーションバンドル32は、オペレーションパネル202に操作画面を表示させ、当該操作画面を介してエンドユーザから直接利用操作されるJSDKアプリ30としてのバンドルである。図中では、アプリケーションバンドル32の一例としてスキャンアプリ321が示されている。スキャンアプリ321は、撮像部121による原稿からの画像の読み取りを実現するアプリケーションである。サービスバンドル33は、アプリケーションバンドル32等に対してサービスを提供するためのJSDKアプリ30としてのバンドルである。すなわち、サービスバンドル33は、アプリケーションバンドル32等からの呼び出しに応じて各サービスバンドル33に応じた処理を実行し、その処理結果をアプリケーションバンドル32等に返却する。図中では、サービスバンドル33の一例として、スキャンサービス331、パネルサービス332、及び仮起動サービス333等が示されている。スキャンサービス331は、画像の読み取り機能に関するサービスを提供する。パネルサービス332は、オペレーションパネル202の表示制御に関するサービスを提供する。仮起動サービス333は、仮起動スクリプト70の記述内容に基づいて仮起動の処理制御に関するサービスを提供する。仮起動スクリプト70の詳細については後述する。なお、本実施の形態において、アプリケーションバンドル32やサービスバンドル33等のアプリケーションは、init状態→pause状態→active状態→destroy状態の順で状態が遷移する処理が進行する状態遷移モデルに従って動作する。init状態は、初期状態であり、初期処理等が行われる。起動直後のアプリケーションは、まず、init状態に遷移する。pause状態は、待機状態である。pause状態のアプリケーションは、実行可能となるまで待機する。active状態は、アプリケーション本来の機能が実行される状態である。destroy状態は、終了状態である。終了するアプリケーションは、destroy状態に遷移し、終了化処理リソースの開放等を行った後、終了する。斯かる状態遷移モデルを実現するため、アプリケーションバンドル32やサービスバンドル33は、次のように構成される。図4は、アプリケーションバンドルやサービスバンドルの状態遷移モデルの実装例を示す図である。図4に示されるように、アプリケーションバンドル32やサービスバンドル33図4の説明においては、アプリケーションバンドル32等という。は、状態ごとにインスタンス化されたオブジェクトによって構成される。すなわち、init状態、pause状態、active状態、destroy状態に対応させて、init状態オブジェクト341、pause状態オブジェクト342、active状態オブジェクト343、destroy状態オブジェクト344がインスタンス化される。アプリケーションバンドル32等は、状態遷移を発生させるイベントメッセージを受けると、遷移元のオブジェクトから遷移先のオブジェクトへと処理の制御当該アプリケーションの制御を移動させる。例えば、init状態オブジェクト341からpause状態オブジェクト342への処理の制御が移動する。この制御の移動によって状態の遷移が実現される。なお、アプリケーションバンドル32等が状態遷移モデルに従って動作することは、本発明を適用するために、アプリケーションが或る状態遷移モデルに従って実装されなければならないことを意図するものではない。リクエスト経路制御部50は、JSDKアプリ30によるネイティブサービスレイヤ60に対する要求所定の機能の利用要求を監視し、当該要求の発行元のJSDKアプリ30が、仮起動中であるか否かに応じて、当該要求の通知経路を制御する。すなわち、仮起動中であるJSDKアプリ30からの要求については、仮起動サービス333に通知し、仮起動中でない本起動中のJSDKアプリ30からの要求については、ネイティブサービスレイヤ60に通知する。図5は、リクエスト経路制御部の主な機能を説明するための図である。図5中、図3と同一部分には同一符号を付している。図5において、アプリA322は、本起動されているアプリケーションバンドル32である。アプリB323は、仮起動されているアプリケーションバンドル32である。図中に示されるように、リクエスト経路制御部50は、本起動されているアプリA322に関しては、JSDKプラットフォーム40を介して行われるネイティブサービスレイヤ60に対する呼び出しを通過させるS21。したがって、この場合、ネイティブサービスレイヤ60による制御により、複合機10が実際に動作する。一方、リクエスト経路制御部50は、仮起動されているアプリB323に関しては、JSDKプラットフォーム40を介して行われるネイティブサービスレイヤ60に対する呼び出しをネイティブサービスレイヤ60には通知せず、仮起動サービス333に対して通知するS22。この場合、仮起動サービス333は、擬似的にネイティブサービスレイヤ60のように振る舞い、その結果をアプリB323に対してネイティブサービスレイヤ60と同じ形式で応答する。したがって、アプリB323からは、ネイティブサービスレイヤ60が正常に呼び出され、その機能が実行されたように見える。このように、仮起動の際は、リクエスト経路制御部50によってネイティブサービスレイヤ60以下を機能させずにすなわち、実際に複合機10を動作させずに、JSDKアプリ30の検証が行われる。次に、仮起動スクリプト70及び仮起動サービス333の詳細について説明する。図6は、仮起動スクリプト及び仮起動サービスを説明するための図である。図6に示されるように、仮起動スクリプト70は、メインスクリプト71、シナリオスクリプト72、及び振る舞いスクリプト73の三つのスクリプトファイルより構成される。メインスクリプト71には、仮起動に使用するシナリオスクリプト72及び振る舞いスクリプト73の特定や仮起動の成否の判断基準等が定義される。シナリオスクリプト72には、仮起動のシナリオが定義される。シナリオとは、仮起動されるアプリケーションに対するオペレーションパネル202を介した操作手順をいう。振る舞いスクリプト73には、リクエスト経路制御部50によって仮起動サービス333に通知されたネイティブサービスレイヤ60の呼び出しに対する振る舞いエミュレーションの内容が定義される。メインスクリプト71は、仮起動サービス333によって解釈される。したがって、仮起動サービス333は、メインスクリプト71に従って仮起動を制御する。仮起動サービス333は、シナリオスクリプト72を解釈するためのスレッドシナリオサービス334と、振る舞いスクリプト73を解釈するためのスレッド振る舞いサービス335を生成する。シナリオサービス334は、シナリオスクリプト72に従って、仮起動中のアプリケーションに対する操作指示を入力する擬似的な操作者として機能する。シナリオサービス334の操作指示に応じて発生する当該アプリケーションに基づくネイティブサービスレイヤ60の呼び出しは、リクエスト経路制御部50によって振る舞いサービス335に通知される。振る舞いサービス335は、振る舞いスクリプト73の定義に従って、通知された呼び出しに対するエミュレーションを行い、その結果として、ネイティブサービスレイヤ60と同じ形式の応答を行う。ネイティブサービスレイヤ60と同じ形式の応答が行われることで、アプリケーションからは、ネイティブサービスレイヤ60が呼び出されたように見える。以下、複合機10の処理手順について説明する。図7は、第一の実施の形態における複合機の仮起動に関する処理手順を説明するためのシーケンス図である。アプリケーションのインストールが指示されると、SASマネージャ31は、複合機10本体のメモリカードスロット234に挿入されているSDカードに記録されているアプリケーション管理ファイルを検索し、検索された全てのアプリケーション管理ファイルをSDカード内より取り出すS101。ここで、アプリケーション管理ファイルとは、アプリケーションの構成要素やインストール等に必要な情報、及びその他の管理情報等以下、アプリケーション情報という。が記録されているファイルである。アプリケーション管理ファイルは、アプリケーションごとに添付されている。したがって、SDカード内に複数のJSDKアプリ30が記録されている場合は、複数のアプリケーション管理ファイルが取り出される。例えば、図8は、スキャンアプリのアプリケーション管理ファイルに記録されているアプリケーション情報の例を示す図である。図8に示されるアプリケーション情報410は、XMLeXtensibleMarkupLanguage形式をベースとしたJNLPJavaNetworkLaunchingProtocolJSR-56仕様を拡張した形式によって表現されている。アプリケーション情報410は、主に、<information>タグで囲まれたinformation要素411、<rsource>タグで囲まれたresource要素412、<pseudo-boot>タグで囲まれたpseudo-boot要素413、<xlet-desc>タグで囲まれたxlet要素414等より構成される。information要素411には、主に、アプリケーションスキャンアプリ321を識別するための情報が記録されている。例えば、product-id要素4111にはスキャンアプリ321のプロダクトIDが、title要素4112にはスキャンアプリ321のタイトルアプリケーション名が、vendor要素4113にはスキャンアプリ321の開発ベンダ名記述4113が記録されている。resource要素412には、スキャンアプリ321の実行に必要なリソースに関する情報が記録されている。例えば、jar要素4121のhref属性の値として、スキャンアプリ321のJARファイルのファイル名パス名が記録されている。pseudo-boot要素413には仮起動に関する情報が定義されている。例えば、pseudo-boot要素413のtrigger属性4131の値には、仮起動を実行するタイミングが指定されている。図中の例ではinstallとされている。これは、スキャンアプリ321のインストール時に仮起動を実行することを示す。また、platform属性4132の値には、仮起動を行うプラットフォームが指定されている。図中の例ではsameとされている。これは、本起動と同一のプラットフォーム上で仮起動が実行されることを示す。また、pb要素4133のhref属性の値として、スキャンアプリ321の仮起動スクリプト70のメインスクリプト71のファイル名ScanApp.pbが指定されている。なお、pseudo-boot要素413は、仮起動が必要とされる場合に記録されている。したがって、pseudo-boot要素413の有無に応じて、仮起動の要否を判断することができる。xlet要素414のvisible属性4141の値には、スキャンアプリ321がオペレーションパネル202に画面表示を行うか否かが記録されている。図中の例ではvisibleとされている。これは、スキャンアプリ321が画面表示を行うことを意味する。なお、図8は、スキャンアプリ321のアプリケーション情報の例を示すものであるが、他のアプリケーションについても、同様の形式によってアプリケーション情報が定義される。続いて、SASマネージャ31は、取得されたアプリケーション管理ファイルに基づいて、複合機10にインストール可能なアプリケーションを判定し、インストール可能とされたアプリケーションの一覧例えば、アプリケーション名の一覧をオペレーションパネル202に表示させるS102、S103。操作者は、オペレーションパネル202に表示されたアプリケーションの一覧の中から、インストールを行うアプリケーションを選択する。ここでは、スキャンアプリ321が選択されたこととする。スキャンアプリ321が選択されることにより、スキャンアプリ321のインストールの開始要求がSASマネージャ31に通知されるS104。SASマネージャ31は、インストールの開始要求に応じ、スキャンアプリ321のアプリケーション管理ファイルの内容アプリケーション情報410に従って、スキャンアプリ321のインストールをJSDKプラットフォーム40に要求するS105。JSDKプラットフォーム40は、スキャンアプリ321をバンドルとしてインストールするS106。続いて、SASマネージャ31は、アプリケーション情報410に仮起動の指示pseudo-boot要素413が記録されているか否かを確認し、当該指示が記録されている場合は、スキャンアプリ321の仮起動を開始するS107。仮起動サービス333が起動されていない場合、SASマネージャ31は、仮起動サービス333の起動を開始するS108。まず、SASマネージャ31が、JSDKプラットフォーム40に対して仮起動サービス333のインストール要求を行うとS109、JSDKプラットフォーム40は、仮起動サービス333をインストールするS110。続いて、SASマネージャ31が、JSDKプラットフォーム40に対して仮起動サービス333の起動要求を行うとS111、JSDKプラットフォーム40は、仮起動サービス333を起動するS112。仮起動サービス333は、起動されると自ら仮起動サービス333が提供できるサービスのインタフェース情報をJSDKプラットフォーム40に登録するS113。続いて、仮起動サービス333は、リクエスト経路制御部50のインタフェース情報をJSDKプラットフォーム333より取得するS114。ここで、インタフェース情報とは、リクエスト経路制御部50を呼び出すために必要とされる情報をいう。なお、リクエスト経路制御部50は、複合機10の起動時等において起動され、その際にインタフェース情報がJSDKプラットフォーム40に登録されている。続いて、SASマネージャ31は、JSDKプラットフォーム40より仮起動サービス333のインタフェース情報を取得するS115。続いて、SASマネージャ31は、アプリケーション情報410のpb要素4133を参照し、pb要素4133にそのファイル名ScanApp.pbが指定されているメインスクリプト71を取得する。SASマネージャ31は、メインスクリプト71とスキャンアプリ321のアプリケーション名とを仮起動サービス333に転送することにより、スキャンアプリ321の仮起動の制御を仮起動サービス333に要求するS116。図9は、第一の実施の形態におけるメインスクリプトの定義例を示す図である。図9に記述されたメインスクリプト71の各記述の内容は、当該記述が実行されるステップにおいて説明する。なお、本実施の形態において、メインスクリプト71や、シナリオスクリプト72及び振る舞いスクリプト73は、対象とするアプリケーションと同じSDカード内に記録されている。仮起動サービス333は、仮起動の対象とされたスキャンアプリ321のアプリケーション名をリクエスト経路制御部50に通知し、スキャンアプリ321からのネイティブサービスレイヤ60に対する呼び出し要求メッセージを仮起動サービス333に通知するように、リクエスト経路制御部50に要求するS117。リクエスト経路制御部50は、ここで通知されるアプリケーション名を保持しておき、仮起動の対象とされているアプリケーションを識別する。続いて、仮起動サービス333は、メインスクリプト71の記述711を実行する。記述711には、ファイル名がScanApp.sであるシナリオスクリプト72と、ファイル名がScanApp.bである振る舞いスクリプト73とを使用して仮起動を実行することが定義されている。したがって、仮起動サービス333は、シナリオサービス334を起動生成し、シナリオサービス334に対してシナリオスクリプト72ScanApp.sを転送するS118。また、仮起動サービス333は、振る舞いサービス335を起動生成し、振る舞いサービス335に対して振る舞いスクリプト73ScanApp.bを転送するS119。図10は、第一の実施の形態におけるシナリオスクリプトの定義例を示す図である。図10に記述されたシナリオスクリプト72には、スキャンアプリ321の操作画面の表示後、3秒経過してからスタートボタンを押下し、操作画面にCompleteという文字の表示が確認できたらシナリオ通り動作したと判断することが定義されている。斯かる定義は、スキャンアプリ321の操作画面が以下のようなものであることが前提とされている。図11は、スキャンアプリの操作画面の例を示す図である。図11には、二つの操作画面が表示されている。左側の操作画面510aは、初期状態操作画面の表示直後の状態を示す。右側の操作画面510bは、スキャンアプリ321の正常終了時の状態を示す。なお、以下において双方を区別しない場合、操作画面510という。本実施の形態において、操作画面510は、対象がスキャンアプリ321であることを示すラベル511と、スタートボタン512と、Resultラベル513とより構成される。スタートボタン512は、スキャンアプリ321の実行の開始指示をユーザに入力させるためのボタンである。Resultラベル513は、スキャンアプリ321の処理結果が表示されるラベルであり、正常終了した場合スキャンに成功した場合、操作画面510bに示されるように、Completeという文字列が表示され、異常終了した場合スキャンに失敗した場合、例えば、Errorという文字列が表示される。なお、操作画面510aに示されるように、初期状態では、Resultラベル513には何も表示されない。また、図12は、第一の実施の形態における振る舞いスクリプトの定義例を示す図である。振る舞いスクリプト73における各記述は、ステップごとに実行される定義ではなく、振る舞いサービス335に対する設定情報としての意味を持つ。すなわち、記述731では、スキャンサービスネイティブサービスレイヤ60においてスキャナ撮像部121に関するサービスを提供するモジュールに関する要求等に関しては、正常動作をしたように振る舞うエミュレートすることが設定されている。また、記述732では、パネルサービスネイティブサービスレイヤ60においてオペレーションパネル202に関するサービスを提供するモジュールに関する要求等に関しては、正常動作したように振る舞うエミュレートすることが設定されている。続いて、SASマネージャ31は、JSDKプラットフォーム40に対してスキャンアプリ321の起動要求を行うS120。但し、スキャンアプリ321は仮起動サービス333によって、仮起動となる。JSDKプラットフォーム40は、スキャンアプリ321の起動要求に応じ、スキャンアプリ321の状態をinit状態へ遷移させ、スキャンアプリ321がinit状態に遷移したことをロギングサービス42に通知するS121。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。仮起動ログ80は、例えば、以下のような構文によってファイルに記録される。図13は、仮起動ログの構文の例を説明するための図である。図13では、一行分一回の記録分の仮起動ログの構文がツリー形式によって記載されている。ツリーの各ノードは、仮起動ログを構成する項目を示す。図示されるように、仮起動ログ80には、第1項目として番号、第2項目として日付、第3項目として時刻、第4項目としてアプリ名が記録される。番号は、ログの記録順を示す番号である。日付及び時刻は、当該ログが記録された日時である。アプリ名は、仮起動されているアプリケーションのアプリケーション名である。但し、プロダクトIDでもよい。続いて、第5項目には、ログの記録内容の種別が記録される。種別としては、Bundle、Memory、Scan、Panel、又はhddが記録される。Bundleは、バンドルアプリケーションの状態遷移に関するログであることを示す。この場合、第6項目には、遷移後のバンドルの状態として、例えば、initState又はactiveStateが記録される。initStateは、init状態を示す。activeStateは、active状態を示す。Memoryは、メモリの確保又は開放に関するログであることを示す。この場合、第6項目には、当該アプリケーションによるヒープメモリの消費量の合計値がHeap=<Size>の形式で記録される。第7項目には、当該アプリケーションによるスタック領域の消費量の合計値がStack=<Size>の形式で記録される。第8項目には、新たにメモリが確保された対象の種別として、例えば、Objectが記録される。Objectは、オブジェクトを示す。第9項目には、新たにメモリが確保された対象の型又はクラス名とそのサイズが記録される。なお、図中では、Heap、Stack、及びObjectが選択的な関係であるかのように記載されているが、上記のように、各項目が直列的に記録される。Scanは、スキャナ撮像部121の操作に関するログであることを示す。この場合、第6項目として、スキャナに関する操作の種別として、例えば、setup、start、又はcompleteが記録される。setupは、スキャナのセットアップを示す。startは、スキャンの開始を示す。completeは、スキャンの成功を示す。setupの場合、第6項目として、属性設定を意味する値attributeが記録され、第7項目として、モノクロスキャンmonoであるのか、カラースキャンcolorであるのかが記録される。Panelは、オペレーションパネル202の操作に関するログであることを示す。この場合、第6項目には、オペレーションパネル202の操作の種別として、例えば、showが記録される。showは、オペレーションパネル202に対する情報画面又はメッセージ等の表示を示す。hddは、HDD233の操作に関するログであることを示す。この場合、第6項目には、操作の種別として、例えばread又はwriteが記録される。readは情報の読み取りを示す。writeは情報の書き込みを示す。図14は、仮起動ログの具体例を示す図である。図14に示される仮起動ログ80は、図13において説明した構文に従って記録された例である。図14では、各項目の値がカンマによって区切られたCSVCommaSeparatedValues形式によって記録された例が示されている。図中、1行目は、ステップS121の通知に応じて記録されるログの例を示す。すなわち、0001は、番号を示し、2007.05.10は、日付を示し、11:30:24:04は時刻を示し、ScanAppは、スキャンアプリ321のアプリケーション名を示す。また、第5項目がBundleであり、第6項目がinitStateであることから、1行目のログは、スキャンアプリ321がinit状態に遷移したことを記録したものであることが分かる。図7に戻る。ステップS121に続いて、JSDKプラットフォーム40は、スキャンアプリ321の起動要求に応じ、スキャンアプリ321の状態をactive状態へ遷移させ、スキャンアプリ321がactive状態に遷移したことをロギングサービス42に通知するS122。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の2行目に相当する。なお、図7では、便宜上、スキャンアプリ321のpause状態への遷移は省略されている。続いて、JSDKプラットフォーム40は、スキャンアプリ321のバンドルを起動するS123。スキャンアプリ321は、起動されると、スキャンアプリ321自身が使用するサービスバンドル33のインタフェース情報をJSDKプラットフォーム40より取得するS124。ここでは、スキャンサービス331及びパネルサービス332のインタフェース情報が取得される。なお、スキャンサービス331及びパネルサービス332は、複合機10の起動時等において起動され、その際にインタフェース情報がJSDKプラットフォーム40に登録されている。続いて、スキャンアプリ321は、スキャンサービス331のインタフェース情報に基づいて、スキャンサービス331を利用するために必要とされるスキャンサービス331のオブジェクトScanServiceクラスのインスタンスを生成する。以降、スキャンアプリ321からスキャンサービス331への要求の通知は、厳密には当該オブジェクトを介して行われる。スキャンサービス331等のサービスバンドル33のオブジェクトの生成は、セキュリティマネージャ41によるアクセス制御の対象とされる。したがって、スキャンサービス331のオブジェクトの生成は、当該オブジェクトのコンストラクタにおいてセキュリティマネージャ41に通知されるS125。セキュリティマネージャ41は、当該通知に応じて、オブジェクトの生成元スキャンアプリ321のクラス名を識別し、スキャンアプリ321によってメモリが消費されたことを、そのクラス名及びオブジェクトのサイズと共にロギングサービス42に通知するS126。オブジェクトのサイズは、クラス名に基づいて判定することができる。なお、セキュリティマネージャ41が、オブジェクトの生成元をどのように識別するかについては後述する。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の3行目に相当する。図14の3行目には、Memory,Heap=2MB,Stack=100KB,Object,ScanService=1MBと記録されている。これは、スキャンアプリ321によるヒープメモリの現在の総消費量は2MB、スタック領域の現在の総消費量は100KBで、ScanServiceクラスのオブジェクトが生成され、そのサイズは1MBであることを示す。続いて、スキャンアプリ321は、スキャンサービス331のインタフェース情報に基づいて、スキャンアプリ321の振る舞いに対応したスキャン処理を構築するための初期設定すなわち、モノクロスキャンの初期設定をスキャンサービス331に対して行うS127。スキャンサービス331は、スキャンアプリ321からの初期設定要求をリクエスト経路制御部50を介してネイティブサービスレイヤ60に通知しようとするS128。但し、初期設定の要求元のスキャンアプリ321は仮起動中であるため、リクエスト経路制御部50は、初期設定要求をネイティブサービスレイヤ60へは通知せず、振る舞サービス335に通知するS129。なお、リクエスト経路制御部50が、呼び出し元ここでは、初期設定の要求元が仮起動中であるか否かをどのように判定するかについては後述する。振る舞いサービス335は、スキャナの初期設定のエミュレーションを行い、その処理結果をリクエスト経路制御部50経由で要求元スキャンアプリ321へ通知する。ここでは、振る舞いスクリプト73の記述731における設定に従って、正常に初期設定が行われたことが通知される。したがって、スキャンアプリ321は、スキャンの初期設定は正常に行われたものと判断する。なお、スキャンアプリ321が仮起動中でなければ本起動中であれば、リクエスト経路制御部50に通知された要求は、ネイティブサービスレイヤ60に通知され、実際に初期設定が行われる。続いて、振る舞いサービス335は、モノクロスキャンの初期設定が要求されたことをロギングサービス42に通知するS130。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の4行目に相当する。振る舞いサービス335は、また、モノクロスキャンの初期設定のエミュレーションが完了したことをシナリオサービス334に通知するS131。シナリオサービス334は、アプリケーションの擬似的な操作者として機能するサービスである。したがって、オペレーションパネル202に、アプリケーションの操作画面510aが表示されるまでは機能することができない。よって、シナリオサービス334は、オペレーションパネル202への操作画面510aの描画表示の完了が通知されるまでは、シナリオスクリプト72の定義内容の実行は開始せずに、振る舞いサービス335からの通知は無視する。なお、振る舞いサービス335による、ロギングサービス42及びシナリオサービス334への通知は、振る舞いサービス335に予め組み込まれているロジックによって実行される処理である振る舞いスクリプト73に基づいて実行される処理ではない。。すなわち、振る舞いスクリプト335は、リクエスト経路制御部50によって経路変更されたサービス要求が通知されたときは、当該サービス要求を受けたことをロギングサービス42に通知すると共に、該サービス要求に応じて振る舞いサービス335がエミュレーションした結果をシナリオサービス42に通知するように実装されている。続いて、スキャンアプリ321は、パネルサービス332のインタフェース情報に基づいて、パネルサービス332を利用するために必要とされるパネルサービス332のオブジェクトPanelServiceクラスのインスタンスを生成する。以降、スキャンアプリ321からパネルサービス332への要求の通知は、厳密には当該オブジェクトを介して行われる。パネルサービス332のオブジェクトの生成は、当該オブジェクトのコンストラクタにおいてセキュリティマネージャ41に通知されるS132。セキュリティマネージャ41は、当該通知に応じて、オブジェクトの生成元スキャンアプリ321のクラス名を識別し、スキャンアプリ321によってメモリが消費されたことを、そのクラス名及びオブジェクトのサイズと共にロギングサービス42に通知するS133。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の5行目に相当する。図14の5行目には、Memory,Heap=3MB,Stack=300KB,Object,PanelService=1MBと記録されている。これは、スキャンアプリ321によるヒープメモリの現在の総消費量は3MB、スタック領域の現在の総消費量は300KBで、PanelServiceクラスのオブジェクトが生成され、そのサイズは1MBであることを示す。続いて、スキャンアプリ321は、パネルサービス332のインタフェース情報を用いて、スキャンアプリ321の操作画面510aのオペレーションパネル202の描画要求をパネルサービス332に通知するS134。続いて、パネルサービス332は、スキャナアプリ321の操作画面510aをオペレーションパネル202に描画させるためにネイティブサービスレイヤ60に通知すべき画面情報を構築生成し、当該画面情報に基づく操作画面510aの描画要求をリクエスト経路制御部50を介してネイティブサービスレイヤ60に通知しようとするS135。但し、操作画面510aの描画の要求元のスキャンアプリ321は仮起動中であるため、リクエスト経路制御部50は、描画要求をネイティブサービスレイヤ60へは通知せず、画面情報と共に振る舞いサービス335に通知するS136。振る舞いサービス335は、画面情報に基づく操作画面510aの描画のエミュレーションを行う。その結果、仮想的に操作画面510aの描画が行われる。ここで仮想的にとは、実際には、オペレーションパネル202には操作画面510aが表示されないことをいう。但し、振る舞いサービス335内において、操作画面510aの画面情報は保持される。続いて、振る舞いサービス335は、操作画面510aの描画のエミュレーションの結果をリクエスト経路制御部50経由で要求元スキャンアプリ321へ通知する。ここでは、振る舞いスクリプト73の記述732における設定に従って、正常に描画が行われたことが通知される。続いて、振る舞いサービス335は、操作画面510aの描画が要求されたことをロギングサービス42に通知するS137。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の6行目に相当する。振る舞いサービス335は、また、操作画面510aの描画のエミュレーションが完了したことをシナリオサービス334に通知するS138。操作画面510aの描画の完了の通知に応じ、シナリオサービス334は、シナリオスクリプト72の定義内容に応じた処理を開始する。まず、図10の記述721に基づいて、操作画面510a図11におけるスタートボタン512のオブジェクト以下、スタートボタンオブジェクトという。を取得する。スタートボタンオブジェククトは、操作画面510の画面情報を構成するオブジェクト群の一つであり、記述721に記載される関数の呼び出しに応じて、振る舞いサービス335より取得される。続いて、記述722に記載された関数に基づいて、当該関数の引数に指定された時間3秒間待機する。続いて、記述723に基づいて、スタートボタン512が押下されたことを示すメッセージをリクエスト経路制御部50に通知するS139。なお、スタートボタン512の押下の通知を行うまでに3秒間待機するのは、シナリオサービス334による擬似的な操作入力を、実際のユーザによる操作入力により近いものとするためである。すなわち、実際のユーザは、操作画面510aの表示直後にスタートボタン512を押下することはなく、だいたい3秒くらいたってから、操作入力を開始するからである。続いて、シナリオサービス334は、シナリオスクリプト72の記述724に基づいて、操作画面510のResultラベル513のオブジェクト以下Resultラベルオブジェクトという。を取得する。Resultラベルオブジェクトは、操作画面510の画面情報を構成するオブジェクト群の一つであり、記述724に記載される関数の呼び出しに応じて、振る舞いサービス335より取得される。続いて、シナリオサービス334は、シナリオスクリプト72の記述725に基づいて、Resultラベル513が更新されるまで待機状態となる。したがって、記述726以降の処理は、この段階では実行されない。一方、ステップS139において、シナリオサービス334よりスタートボタン512の押下の通知するメッセージを受けたリクエスト経路制御部50は、当該メッセージをパネルサービス332に通知するS140。パネルサービス332は、スタートボタン512の押下の通知を受けて、スキャンアプリ321に対して、スタートボタン512が押下されたことを通知するS141。スキャンアプリ321は、スタートボタン512の押下の通知を受けて、スキャンサービス331に対してスキャンの開始を要求するS142。スキャンサービス331は、スキャンアプリ321からのスキャン開始要求をリクエスト経路制御部50を介してネイティブサービスレイヤ60に通知しようとするS143。但し、スキャン開始の要求元のスキャンアプリ321は仮起動中であるため、リクエスト経路制御部50は、スキャン開始要求をネイティブサービスレイヤ60へは通知せず、振る舞サービス335に通知するS144。続いて、振る舞いサービス335は、スキャンの開始が要求されたことをロギングサービス42に通知するS145。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の7行目に相当する。振る舞いサービス335は、また、スキャンが開始されることをシナリオサービス334に通知するS146。ここで、シナリオサービス334は、Resultラベル513の更新待ち状態であるため、何も行わない。続いて、振る舞いサービス335は、スキャンのエミュレーションを行い、その処理結果をリクエスト経路制御部50へ通知するS147。ここでは、振る舞いスクリプト73の記述731における設定に従って、正常にスキャンが行われたこと正常終了を示すメッセージが通知される。振る舞いサービス335は、また、スキャンの正常終了をロギングサービス42及びシナリオサービス334に通知するS148、S149。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の8行目に相当する。また、シナリオサービス334は、Resultラベル513の更新待ち状態であるため、スキャンの正常終了の通知に応じて何も行わない。一方、ステップS147において、振る舞いサービス335よりスキャンの正常終了を通知するメッセージを受けたリクエスト経路制御部50は、当該メッセージをスキャンサービス331に通知するS150。スキャンサービス331は、スキャン開始の要求元であるスキャンアプリ321にスキャンの正常終了を通知するS151。スキャンアプリ321は、スキャンの正常終了の通知を受けて、操作画面510のResultラベル513に文字列Completeを表示させるようにパネルサービス332に対して要求するS152。パネルサービス332は、スキャンアプリ321からの要求を受けて、文字列Completeの表示要求をリクエスト経路制御部50を介してネイティブサービスレイヤ60に通知しようとするS153。但し、文字列Completeの表示要求の要求元のスキャンアプリ321は仮起動中であるため、リクエスト経路制御部50は、文字列Completeの表示要求をネイティブサービスレイヤ60へは通知せず、振る舞サービス335に通知するS154。振る舞いサービス335は、仮想的に、Resultラベル513に文字列Completeを表示させる。具体的には、保持している画面情報におけるResultラベルオブジェクトに対して、文字列Completeをセットすることにより、文字列Completeの表示処理のエミュレーションを行う。続いて、振る舞いサービス335は、エミュレーションの結果をリクエスト経路制御部50経由で要求元スキャンアプリ321へ通知する。ここでは、振る舞いスクリプト73の記述732における設定に従って、正常に文字列Completeの表示が行われたことが通知される。続いて、振る舞いサービス335は、操作画面510の更新が要求されたことをロギングサービス42に通知するS155。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の9行目に相当する。振る舞いサービス335は、また、Resultラベル513に文字列Completeが表示されたことをシナリオサービス334に通知するS156。シナリオサービス334は、当該通知に応じて、Resultラベル513が更新されるまでの待機状態から復帰し、シナリオスクリプト72図10の記述726に基づいて、Resultラベル513に表示された文字列が、Completeであるか否かを判定する。Resultラベル513に表示された文字列が、Completeである場合、シナリオサービス334は、記述727に基づいて、仮起動の対象とされているアプリケーションスキャンアプリ321はシナリオ通り動作たことシナリオの成功を仮起動サービス333に通知するS157。一方、Resultラベル513に表示された文字列が、Completeでない場合、シナリオサービス334は、記述728に基づいて、仮起動の対象とされているアプリケーションはシナリオ通り動作しなかったことシナリオの失敗を仮起動サービス333に通知する。仮起動サービス333は、シナリオの成功の通知を受けると、メインスクリプト71図9の記述712に基づいて、アプリケーション名がScanAppのアプリケーションスキャンアプリ321の仮起動ログの検索をロギングサービス42に要求する。ロギングサービス42は、アプリケーション名に基づいて、仮起動ログ80よりスキャンアプリ321の仮起動ログを検索し、その検索結果を仮起動サービス333に通知するS159。図14の仮起動ログ80には、スキャンアプリ321のログ情報のみが記録された例が示されている。したがって、ここでは、図14に示される仮起動ログ80の9行目までの内容がそのまま仮起動サービス333に通知される。続いて、仮起動サービス333は、メインスクリプト71図9の記述713に基づいて、仮起動の成否の判定を行う。記述713では、消費メモリが5MB以下であること、HDD233への書き込みが無いこと、及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって、仮起動サービス333は、仮起動ログ80内おいて、Memory,Heap=×××MBという形式で記録されているヒープメモリの消費量のログの中で最大値を検索し、当該最大値が5MB以下であるか否かを確認する。また、仮起動サービス333は、仮起動ログ80内において、hdd,writeといった記述を検索し、HDD233への書き込みの有無を確認する。更に、仮起動サービス333は、仮起動ログ80内において、Scan,setup,attribute,monoといった記述を検索し、スキャンモードがモノクロであるか否かを確認する。本実施の形態における仮起動ログ80によれば、ヒープメモリの消費量の最大値は5行目より3MBであり、5MB以下である。また、hdd,writeといった記述は存在せず、HDD233への書き込みは行われていない。更に、4行目にScan,setup,attribute,monoといった記述が存在し、スキャンモードはモノクロである。したがって、仮起動の成功条件は満たされている。そこで、仮起動サービス333は、メインスクリプト71の記述714に基づいて、仮起動は成功したことをSASマネージャ31に通知するS160。SASマネージャ31は、仮起動の成功通知を受けて、仮起動中のスキャンアプリ321を終了させるようにJSDKプラットフォーム40に要求するS161。JSDKプラットフォーム40は、スキャンアプリ321をdestroy状態へ遷移させることをロギングサービス42に通知するS162。ロギングサービス42は、通知された情報を仮起動ログ80として記録する。ここで、記録されるログは、図14の10行目に相当する。続いて、JSDKプラットフォーム40は、スキャンアプリ321を終了させるS163。一方、SASマネージャ31は、ステップS161においてスキャンアプリ321の終了を要求した後、スキャンアプリ321のインストールが完了したことをオペレーションパネル202に表示させるS164。当該表示によって、操作者は、スキャンアプリ321が正常にインストールされたことを認識するS165。そこで、操作者は、スキャンアプリ321を利用するため、スキャンアプリ321の本起動の指示をオペレーションパネル202を介して入力するS166。スキャンアプリ321の本起動の指示は、SASマネージャ31に通知されるS167。SASマネージャ31は、JSDKプラットフォーム40に対して、スキャンアプリ321の本起動を要求するS168。JSDKプラットフォーム40は、スキャンアプリ321を本起動させるS169。以降、本起動されたスキャンアプリ321にからの要求は、リクエスト経路制御部50によって経路変更されずにネイティブサービスレイヤ60に通知される。したがって、実際に、操作画面の表示が行われ、操作画面を介した操作者からの入力に応じ、スキャンが実行される。なお、仮起動に失敗した場合、例えば、仮起動されたスキャンアプリ321がシナリオ通りに動作しなかった場合、又は、仮起動の成功の条件メインスクリプト71の記述713が満たされなかった場合は、ステップS160において、仮起動サービス333は、メインスクリプト71図9の記述715に基づいて、仮起動の失敗をSASマネージャ31に通知する。当該通知に応じ、SASマネージャ31は、スキャンアプリ321のインストールに失敗したことをオペレーションパネル202に表示させ、スキャンアプリ321のインストールを無効とする。したがって、操作者はスキャンアプリ321を本起動させること実際に利用することはできない。次に、ステップS126等において、セキュリティマネージャ41が、オブジェクトの生成元をどのように識別するかについて説明する。図15は、セキュリティマネージャによるオブジェクトの生成元の識別方法を説明するための図である。図15では、スキャンアプリ321によってスキャンサービス331のオブジェクトが生成される場合を例としている。したがって、図7におけるステップS125及びS126に対応する。図中、ScanAppは、スキャンアプリ321のクラス名である。ScanServiceは、スキャンサービス331のクラス名である。a:ScanAppは、ScanAppクラスのオブジェクトaすなわち、インスタンス化されたスキャンアプリ321を示す。また、b:ScanServiceは、ScanServiceクラスのオブジェクトbすなわち、インスタンス化されたスキャンサービス331を示す。オブジェクトaが、ScanServiceクラスのコンストラクタを呼び出してオブジェクトbを生成するとS21、オブジェクトaのクラス名ScanAppがスタックに格納されるS22。オブジェクトbが、そのコンストラクタ内でセキュリティマネージャ41を呼び出すとS23、オブジェクトbのクラス名ScanServiceがスタックに格納されるS24。セキュリティマネージャ41は、オブジェクトbからの呼び出しに応じ、スタック内をトレースすることで、呼び出し元のクラス名がScanAppであること、すなわち、オブジェクトbの生成元がスキャンアプリ321であることを識別することができるS25。次に、ステップS129等において、リクエスト経路制御部50が、ネイティブサービスレイヤ60の呼び出し要求元のアプリケーションが仮起動中であるが否かをどのように判定するかについて説明する。まず、前提として、リクエスト経路制御部50には、仮起動の対象とされているアプリケーションが予め登録される例えば、ステップS116。したがって、リクエスト経路制御部50内において、呼び出し要求元のアプリケーション名を識別することができれば、当該アプリケーションが仮起動中であるか否かを判定することができる。本実施の形態では、JSDKアプリ30であるアプリケーションバンドル32が仮起動の対象とされている。ここで、JSDKアプリ30は、Java登録商標アプリケーションである。したがって、例えば、Java登録商標の標準クラスであるスレッドグループThreadGroupを用いて、アプリケーションを識別することができる。スレッドグループとは、スレッドThreadやスレッドグループの集合であり、一つ以上のThreadをTreadGroupに関連付けることができる。また、スレッドグループには、名前スレッドグループ名を付加することができる。そして、各スレッド内では、当該スレッドが属するスレッドグループを識別することができる。なお、本実施の形態において、アプリケーションバンドル32及びサービスバンドル33は、バンドルとして実装されているが、バンドルとは、動的リンク可能なライブラリ関数又はクラスの集合である。また、リクエスト経路制御部50もライブラリ関数又はクラスの集合したがって、いずれもプロセスとして起動されるものではなく、呼び出された側は、呼び出し元のスレッド上で動作する。斯かる仕組みに基づけば、リクエスト経路制御部50では、以下のように呼び出し元のアプリケーション名を識別することができる。図16は、スレッドグループを用いた呼び出し元のアプリケーション名の識別方法を説明するための図である。図16では、便宜上、各モジュールの上下関係が図3と異なっている。図中、GPxxはa~cは、スレッドグループを示す。thxxは、a~dは、スレッドを示す。図16の例では、スキャンアプリ321には、スレッドグループGPbが関連付けられており、スレッドグループ名としてスキャンアプリ321のアプリケーション名が付加されている。また、スキャンサービス331にはスレッドグループGPcが関連付けられている。スキャンアプリ321には、メソッドAを実行中のスレッドthaと、メソッドBを実行中のスレッドthbとが存在する。ここで、スレッドthaとスレッドthbとは、スレッドグループGPbに属する。例えば、スキャンアプリ321のメソッドB内より、スキャンサービス331のメソッドCが呼び出された場合、メソッドCは、スレッドthb上で動作する。更に、メソッドCよりリクエスト経路制御部50の関数Dが呼び出された場合、関数Dは、スレッドthb上で動作する。したがって、関数D内で、現在のスレッドを確認するとスレッドthbが特定され、更にスレッドthbが属するスレッドグループを確認するとスレッドグループGPbが特定される。そこで、関数B内で、スレッドグループGPbのスレッドグループ名を取得することにより、関数Bすなわち、リクエスト経路制御部50の呼び出し元のアプリケーション名が取得される。更に、取得されたアプリケーション名スレッドグループ名と、予め登録されている仮起動中のアプリケーション名とを比較することにより、関数Bの呼び出し元が仮起動中であるか否かを判定することができる。但し、呼び出し元のアプリケーションの識別方法は、必ずしもスレッドグループを用いなくてもよい。例えば、各メソッドや各関数の引数によって呼び出し元のアプリケーション名を引き継ぐようにしてもよい。上述したように、第一の実施の形態における複合機10によれば、実際にアプリケーションが利用される前に、当該アプリケーションについて仮起動を実行し、その振る舞いに関するログ仮起動ログ80を記録しておく。そして、仮起動ログ80に基づいて、予め設定された制限が満たされているか否かを各アプリケーションについて確認することができる。したがって、予め設定された制限を満たしていないアプリケーションの動作を防止することができ、アプリケーションによる不正動作の可能性を低減させることができる。また、仮起動の成否の判断基準や、仮起動時のアプリケーションに対する操作内容、仮起動時の振る舞いサービス335の振る舞いは、プログラムからは分離されたファイルである仮起動スクリプト70メインスクリプト71、シナリオスクリプト72、振る舞いスクリプト73に定義されている。したがって、各アプリケーションや複合機10の資源の変化例えば、メモリの増設等に合わせて、これらの情報判断基準、操作内容、振る舞い等を容易に変更することができる。特に、本実施の形態のように、テキスト形式のファイルであれば、その変更は容易である。また、振る舞いサービス335が、ネイティブサービスレイヤ60としてネイティブサービスレイヤ60と同様の形式でアプリケーションに対する応答を行うため、アプリケーションは、仮起動であるか否かを意識する必要はない。したがって、仮起動を実現するために、各アプリケーションに改めて実装を行う必要はない。なお、仮起動中は、ネイティブサービスレイヤ60は呼び出されず、複合機10に特有のハードウェア例えば、画像処理を行うためのハードウェアは利用されない。したがって、仮起動は、一般的なPCPersonalComputer等のコンピュータにおいて行ってもよい。この場合、当該コンピュータにでは、図3において、ネイティブサービスレイヤ60以外のソフトウェアが動作可能であればよい。次に第二の実施の形態について説明する。第一の実施の形態では、仮起動ログ80に基づいて、アプリケーションごとに消費メモリが制限値5MB以内であるか否かが判定されていた。しかし、複数のアプリケーションが並列的に起動される場合、第一の実施の形態における判定だけでは不十分な場合がある。図17は、複数のアプリケーションを並列して起動した場合のメモリの消費の様子を説明するための図である。図17において、Aは、或るアプリケーションバンドル32以下アプリAという。による、時間の経過アプリケーションの状態遷移とヒープメモリの消費量の最大値との関係を示したものである。図示されるように、アプリAは、init状態、pause状態、active状態の各状態において、それぞれ、最大で3MB、1MB、4MBのヒープメモリを消費する。この場合、全状態を通して、アプリAのヒープメモリの最大の消費量は4MBであり、第一の実施の形態における制限である5MBを満たしている。したがって、アプリAについては、仮起動は成功であると判定され、本起動が可能となる。図中Bは、アプリAとは別のアプリケーションバンドル32以下アプリBという。による、時間の経過アプリケーションの状態遷移とヒープメモリの消費量の最大値との関係を示したものである。図示されるように、アプリBは、init状態、pause状態、active状態の各状態において、それぞれ最大で3MB、1MB、1MBのヒープメモリを消費する。この場合、全状態を通して、アプリBのヒープメモリの最大の消費量は3MBであり、第一の実施の形態における制限である5MBを満たしている。したがって、アプリBについても、仮起動は成功であると判定され、本起動が可能となる。図中Cは、アプリAとアプリBとが同時に起動された場合の時間の経過とヒープメモリの消費量の最大値との関係を示したものである。すなわち、本起動が許可された二つのアプリケーションが同時に起動され、同じタイミングで状態遷移が行われた場合、二つのアプリケーションによって、init状態、pause状態、active状態の各状態において、それぞれ最大で、33=6MB、11=2MB、14=5MBのヒープメモリが消費される。そうすると、init状態において、制限値である5MBを超えてしまい、アプリケーションが正常に動作しない可能性がある。そこで、第二の実施の形態では、斯かる課題を解決した例について説明する。なお、第二の実施の形態は、第一の実施の形態との差分についてのみ説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。第二の実施の形態において、メインスクリプト71は、次のように定義される。図18は、第二の実施の形態におけるメインスクリプトの記述例を示す図である。図18中、図9と同一部分には同一符号を付し、その説明は省略する。なお、第二の実施の形態において、メインスクリプト71は、メインスクリプト71aとして説明する。メインスクリプト71aは、第一の実施の形態と比較して記述716が異なる。すなわち、記述716では、スクリプト関数pbCase1のインタフェースが定義されているが、第二の実施の形態では、仮起動ログを格納する変数PseudoBootLoglogが、参照渡しのOUT型の引数として定義されている。当該引数の値は、記述712において格納される。第二の実施の形態における、複合機10の仮起動に関する処理手順は、図7とほぼ同様である。但し、メインスクリプト71aにおける記述716に基づいて、ステップS160において、仮起動サービス333は、仮起動の成否を示す情報と共に、仮起動ログ80の内容をSASマネージャ31に通知する。SASマネージャ31は、通知された仮起動ログ80を仮起動の対象とされていたアプリケーションバンドル32図7の例ではスキャンアプリ321と関連付けて、例えば、HDD233に保存し、管理する。関連付けは、例えば、仮起動ログ80のファイル名を、当該アプリケーションバンドル32のアプリケーション名とすることにより行ってもよい。第二の実施の形態では、また、ステップS167においてアプリケーションの起動要求を受けた際におけるSASマネージャ31による、起動中起動開始時も含むのアプリケーションの管理に関する処理が異なる。図19は、第二の実施の形態におけるSASマネージャによる起動中のアプリケーションの管理処理を説明するためのフローチャートである。なお、図19の処理は、本起動のアプリケーションすなわち、仮起動が成功したアプリケーションに関して行われる。複合機10において、状態遷移起動によるinit状態への遷移も含むの必要なアプリケーション以下、アプリAという。が発生するとS201でYes、SASマネージャ31は、アプリAの遷移先の状態のメモリ消費量の最大値と、現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値例えば、5MB以下であるか否かを判定するS202。なお、SASマネージャ31は、アプリAの遷移先の状態のメモリ消費量の最大値や、各アプリケーションの現在の状態のメモリ消費量の最大値をそれぞれのアプリケーションに関連付けられている仮起動ログ80に基づいて判定する。また、SASマネージャ31は、状態遷移するアプリケーションの発生を、当該アプリケーションからの通知によって検知する。メモリ消費量の最大値の合計が制限値以下である場合S202でYes、SASマネージャ31は、アプリAの状態遷移を許可する。その結果、アプリAは、状態遷移を行うS203。一方、メモリ消費量の合計が制限値を超えている場合S202でNo、SASマネージャ31は、アプリAの状態遷移を待機させ、アプリAの状態遷移を待機させていることを示す情報以下、待機情報という。を状態遷移待機キューに登録する。待機情報は、例えば、アプリAの識別情報及び遷移先の状態の識別情報等より構成される。但し、遷移先の状態の識別情報の代わりに遷移先の状態のメモリ消費量の最大値を待機情報に含めても良い。そうすることにより、アプリAの遷移先の状態のメモリ消費量について改めて仮起動ログ80を参照する処理を省くことができる。また、状態遷移待機キューは、待機情報のキュー又はリストである。すなわち、状態遷移待機キューによって、状態遷移待ちであるアプリケーションの一覧が把握され得る。ステップS203において、アプリAの状態遷移が行われた場合、アプリAの状態の遷移によって、各アプリのそれぞれの状態のメモリ消費量の最大値の合計が変化する。したがって、状態遷移待ちアプリの状態遷移を許可できる可能性がある。そこで、SASマネージャ31は、ステップS205以降の処理を実行する。すなわち、SASマネージャ31は、状態遷移待機キューにおける待機情報の有無を確認することにより、状態遷移待ちのアプリケーションの有無を判定するS205。状態遷移待ちのアプリケーションが存在しない場合状態遷移待機キューが空の場合S205でNo、ステップS201に戻る。一方、状態遷移待ちのアプリケーションが存在する場合S205でYes、SASマネージャ31は、状態遷移待機キューより一つの待機情報を取り出すS206。状態遷移待機キューからの待機情報の取り出す順序は、FIFOFirstInFirstOut又はLRULeastRecentlyUsedに従ってもよいし、アプリケーションに優先順位を付け、その優先順位に従ってもよい。当該優先順位は、HDD233等に予め記録しておけばよい。続いて、SASマネージャ31は、取り出された待機情報以下、カレント待機情報という。に係るアプリケーションの遷移先の状態のメモリ消費量の最大値と他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値以下であるか否かを判定するS207。メモリ消費量の最大値の合計が制限値以下であり場合S207でYes、SASマネージャ31は、カレント待機情報を状態遷移待機キューより削除しS208、状態遷移待ちだったアプリケーションの状態を遷移させるS203。なお、当該アプリケーションの状態の遷移に応じて、更に、他の状態遷移待ちのアプリケーションの状態遷移の可否を判定するため、続いて、ステップS205以降の処理が実行される。一方、ステップS207において、メモリ消費量の最大値の合計が制限値を超える場合S207でNo、ステップS201に戻る。但し、ステップS206に戻るようにしてもよい。この場合、状態遷移待機キューにその待機情報が登録されているアプリケーションの中で、制限値内で遷移可能なアプリケーションの状態遷移が優先的に実行される。以上、図19において説明したように、アプリケーションの状態遷移を制限することにより、図17において説明したような状況の発生を回避することがでる。図17の例に関しては、次のように改善される。図20は、状態遷移の制限によってメモリ消費量が適切に管理される様子を示す図である。図20では、アプリAのinit状態とアプリBのinit状態が重なると、制限値5MBを超えてしまうため、アプリAのinit状態への遷移は、アプリBのpause状態への遷移後に行われている。そうすることにより、アプリAとアプリBとの消費メモリの合計値が、全過程を通して、制限値内に抑制されている。上述したように、第二の実施の形態における複合機10によれば、複数のアプリケーションが並列的に動作する場合であっても、各アプリケーションの仮起動中に記録された仮起動ログ80に記録された情報に基づいて、アプリケーションの振る舞い挙動を変化させることができる。すなわち、複数のアプリケーションによるメモリ消費量の合計値が、予め設定された制限値以下に維持されるようにすることができる。したがって、アプリケーションによる不正動作の可能性を低減させることができる。なお、第二の実施の形態では、仮起動時に、全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示したメインスクリプト71a図18の記述713参照。したがって、当該制限を満たしたアプリケーションのみが、本起動の対象とされる前提で、図19の処理手順を説明した。しかし、アプリケーションが本起動されるときに、SASマネージャ31が、当該アプリケーションの仮起動ログ80を参照して、全状態を通したメモリの消費量の最大値を判定し、その最大値が制限値を超える場合は、当該アプリケーションの本起動を拒否するようにしてもよい。この場合、必ずしも仮起動時にメモリの消費量の最大値のチェックを行わなくても良い。すなわち、メインスクリプト71aの記述713におけるlog.Maxmem<5MBという記述を削除してもよい。また、図19の処理は、JSDKプラットフォーム40が行うようにしてもよい。ところで、上記においては、仮起動をアプリケーションの適否の事前チェックのための手段として用いる例について説明した。しかし、仮起動の用途は、これだけに限られない。例えば、アプリケーションの本起動中に発生した障害の原因解析のための手段としても利用することができる。以下、仮起動を障害の原因解析に適用した例を、第三及び第四の実施の形態として説明する。図21は、第三の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。図21において、障害対応サーバ20は、インターネット等のネットワークを介して複合機10と接続され、複合機10を遠隔より監視するコンピュータである。障害対応サーバ20は、例えば、複合機10のベンダによって運用される。操作者による指示に応じ、複合機10のSASマネージャ31は、アプリケーション例えば、スキャンアプリ321を本起動させるS301。アプリケーションの本起動中に障害が発生すると、パネルサービス332は、オペレーションパネル202に障害が発生したことを通知する警告画面を表示させるS302。続いて、SASマネージャ31は、障害対応サーバ20に障害内容を示す情報例えば、エラーコード等を送信するS303。障害対応サーバ20は、障害内容を示す情報に基づいて、障害の原因を調査するために適切な仮起動スクリプト70を複合機10に送信するS304。例えば、障害対応サーバ20の記憶装置には、アプリケーションごと、かつ、障害内容ごとに、当該障害内容の原因を調査するために適切な仮起動スクリプト70が予め保存されている。障害内容の原因を調査するために適切な仮起動スクリプト70とは、その障害を解析するために適切なシナリオが定義されたシナリオスクリプト72や、その障害を解析するための適切なエミュレーションの内容が定義された振る舞いスクリプト73を含む仮起動スクリプト70をいう。複合機10は、受信した仮起動スクリプト70を利用して、障害が発生したアプリケーションを仮起動するS305。この際の処理手順は、図7において説明した通りである。その結果、仮起動ログ80が生成される。そこで、複合機10のSASマネージャ31は、仮起動ログ80を障害対応サーバ20に送信するS306。障害対応サーバ20は、仮起動ログ80を解析し、原因の特定を行う。原因の特定は、自動的に行われても良いし、人的に行われてもよい。原因が特定されると、操作者に障害の解析結果について報告が行われるS307。当該報告は、電子メール等によって自動的に行われても良い。また、アプリケーションのバグであった場合、障害対応サーバ20から修正版を複合機10にリモートインストールするようにしてもよい。なお、障害内容ごとの仮起動スクリプト70を複合機10に予め保存しておき、複合機10の傍で、原因の解析を行っても良い。この場合、障害対応サーバ20は、必ずしも必要ではない。次に、第四の実施の形態について説明する。第四の実施の形態における仮起動を用いた障害解析の方法を説明するための図である。図22中、図21と同一部分には同一符号を付し、その説明は省略する。なお、第四の実施の形態では、障害対応サーバ20に、JSDKアプリ30、JSDKプラットフォーム40、及びリクエスト経路制御部50等が実装されていることとする。図22において、ステップS401~S403は、図21のステップS301~S303と同様である。続いて、障害対応サーバ20は、障害内容を示す情報に基づいて、障害の原因を調査するために適切な仮起動スクリプト70を記憶装置の中から選択するS404。続いて、障害対応サーバ20は、仮起動スクリプト70を利用して、障害が発生したアプリケーションを仮起動し、その結果生成される仮起動ログ80を解析し、原因の特定を行う。原因が特定されると、障害対応サーバ20は、操作者に障害の解析結果について報告を行うS406。アプリケーションのバグであった場合、障害対応サーバ20から修正板を複合機10にリモートインストールするようにしてもよい。上述したように、障害に対応した仮起動スクリプト70に基づいてアプリケーションの仮起動を実行することにより、その結果生成される仮起動ログ80に基づいて、適切に原因の解析を行うことができる。以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。"