JP7262269B2

JP7262269B2 - 情報処理装置、及び情報処理装置の制御方法、プログラム

Info

Publication number: JP7262269B2
Application number: JP2019061358A
Authority: JP
Inventors: 極長谷川
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-03-27
Filing date: 2019-03-27
Publication date: 2023-04-21
Anticipated expiration: 2039-03-27
Also published as: JP2020160946A; US11586723B2; US20200311253A1

Description

本発明は、例えば、複数のプログラムが依存関係にある場合であってもそれらプログラムのセキュリティを維持する情報処理装置及び情報処理方法、プログラムに関する。

一般に、ユーザがアプリケーションプログラム(以降ではアプリ)をシステムにインストール、もしくは開始しようとした際に、システムはそのアプリが信頼できるアプリか否かを判断してから開始処理を行うことができる。そして、もし信頼できないアプリであった場合、システム全体がシステムダウンもしくは、ハングアップにつながるリスクもあるため、そのアプリを開始しないようにすることができる。例えば、アプリの実行に必要となる情報が改ざんされていないこと、もしくは破損していないことをシステムが判定し、情報が改ざんされたアプリ、もしくは破損したアプリであった場合には、警告画面を表示し、開始処理を中断するシステムがある。アプリの実行に必要となる情報として、アプリのプログラムファイル、アプリの情報を記述しているアプリマニフェストファイルが例として該当する。破損検知の機能として、ファイルの破損を検知した際に、ファイルの復旧を行う技術もある（特許文献１）。

また一般に、アプリの実行環境の中には、アプリが自身のプログラムの一部を公開し、他のアプリがその公開されているプログラムを参照し、実行することができるものがある。以降では、他のアプリに対してプログラムの一部を公開可能状態とすることをエクスポートと呼び、他のアプリのプログラムを参照可能状態にすることをインポートと呼ぶ。この際、エクスポートを行っているアプリは、アプリ実行環境上で開始処理が実行されている必要はない。

特開２０１４－１０９８２１号公報

二つのアプリがインストールされ、かつ第一のアプリがエクスポート、第二のアプリが第一のアプリのプログラムをインポートするような環境において、第二のアプリが、信頼できない第一のアプリのプログラムを実行してしまうリスクがある。

例えば、第一のアプリ、第二のアプリが画像処理装置のような組み込み機器内にインストールされた状態で、攻撃者が第一のアプリのプログラムコードを改ざんしたとする。その場合、システムが第一のアプリを開始する際に、システムは第一のアプリを検証して信頼できないアプリと判断する。一方、システムが第二のアプリを開始する際は、システムは第二のアプリを検証して信頼できるアプリと判断する。しかし、第二のアプリは第一のアプリのプログラムの一部を実行することができ、その場合には第一のアプリのプログラムコードについて検証が行われない。そのため、第一のアプリの改ざんされたプログラムコードが実行される可能性があり、セキュリティ上のリスクとなる。

特許文献１では、画像形成装置内にアプリをインストール際に署名確認を行うため、画像形成装置にインストールされた後のアプリが信頼できるものかを判断することはできない。すなわちインストール後の改ざんや破損については対応できない。

本発明は上記従来例に鑑みてなされたもので、依存関係にある複数のプログラムについても、それらのセキュリティを維持することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。
本発明によれば、複数のアプリケーションが動作する情報処理装置であって、
アプリケーションの信頼性を検証する検証手段と、
前記アプリケーションを制御する制御手段とを有し、
前記制御手段は、ユーザの指示に応じて実行される第１のアプリケーションの実行中に、前記第１のアプリケーションが動的にインポートする第２のアプリケーションを、該第２のアプリケーションのロードの前に前記検証手段に検証させ、
アプリケーションがインストールされた際と、前記情報処理装置の起動の際とに、前記アプリケーションが他のアプリケーションを動的にインポートするか判定し、動的にインポートする場合には動的にインポートされるアプリケーションの第１のリストを生成し、
前記制御手段は、前記検証手段に、前記第１のリストに基づいて前記第２のアプリケーションを検証させる
ことを特徴とする情報処理装置が提供される。

本発明によれば、依存関係にある複数のプログラムについても、それらのセキュリティを維持することができる。

全体構成図画像形成装置のハードウェア構成図システム構成図記憶装置内を模式的に表した図各アプリのマニフェストファイルを表した図アプリ管理フレームワークが管理するリストを表した図操作画面を模式的に表した図アプリをインストールする時のフロー図アプリを開始する時のフロー図アプリを実行する時のフロー図アプリを実行する時のフロー図画像形成装置を起動する時のフロー図

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

●システム構成
図１に掲げるのは本発明のシステム全体の構成を示す図である。画像形成装置１００は本実施例にかかる機能を実装した情報処理装置の一例であり、例えばデジタル多機能複写機（ＭＦＰ）などである。情報処理装置１０１は、画像形成装置（１００）を管理する。情報処理装置１０１は例えば汎用のコンピュータである。ネットワーク１２０は、画像形成装置１００と情報処理装置１０１を接続する。情報処理装置１０１は画像形成装置１００にネットワーク（１２０）経由でアクセスし、利用する。

●画像形成装置
図２は画像形成装置１００のハードウェア構成を図式化したものである。コア部２００は画像形成装置２００全体及びその各部を制御する制御部であり、例えばプロセッサとメモリとを含み、プログラムを実行することでその機能を遂行する。ユーザインターフェース部２０１は操作部と表示部とを含み、操作者による操作と操作者に対する表示が行われる。以降では、ユーザインターフェース部として、操作画面の例を用いて説明する。記憶装置２０２は、プログラムファイルやデータファイルなどを記憶する。ネットワークインターフェース部２０３はネットワーク１２０に接続するためのインターフェースである。スキャナー部２０４は、原稿画像を光学的に走査してデジタルデータに変換する。プリンター部２０５は、スキャナー部２０４によりスキャンされた原稿画像を印刷出力したりや、情報処理装置１０１から入力された印刷ジョブに応じた印刷出力を行う。２０６はフィニッシャー部であり、プリンター部２０５から出力された印刷物を対象として、ステイプルや折り、製本などの後処理を実行する。

図３は本実施例における画像形成装置１００の上でアプリケーションプログラム(以降、アプリ)を実行するためのシステム構成図である。本実施例においては、Ｊａｖａ（登録商標）実行環境で複数のアプリを動作させるものとする。ここで、Ｊａｖａ実行環境で動作するアプリはＪａｖａで記述され、また、複数のアプリを管理するためのフレームワーク（以降ではアプリ管理フレームワーク）もＪａｖａで記述されている。

ユーザが画像形成装置１００の電源を入れると、Ｊａｖａ実行環境３０１が動き出し、アプリを実行可能にするために必要な、アプリ管理フレームワーク３０２を起動する。またＪａｖａ実行環境３０１には、システムのプログラムをメモリ内に読み込むための、システムクラスローダ３０１０がある。一般に、Ｊａｖａ実行環境３０１は、記憶装置２０２に置かれたプログラムファイルをメモリ内に読み込ませることで、プログラムの実行を行うことができる。プログラムファイルは、各プログラムをクラス単位で記載したクラスファイルが用いられる。そして、このクラスファイルをメモリ内に読み込むことをクラスのロード（もしくはロード、プログラムのロード）と呼ぶ。アプリ管理フレームワーク３０２はアプリのインストールおよびアンインストール、開始と停止を管理する。

アプリ３１０は画像形成装置１００上で動作し、エクスポート（Ｅｘｐｏｒｔ）するプログラムを示すアプリケーションＡ（以降、アプリＡとも呼ぶ）である。アプリ３１１は、画像形成装置１００上で動作するアプリであり、アプリ３１０がエクスポートしているプログラムをインポート（Ｉｍｐｏｒｔ）するアプリケーションＢ（以降、アプリＢとも呼ぶ）である。アプリ３１２は、画像形成装置（１００）上で動作するアプリであり、アプリ３１２（以降、アプリＣとも呼ぶ）の実行中に、アプリＡ３１０のプログラムが必要になった場合に動的にインポートするプログラムを示すアプリＣである。なお、動的なインポートに対して動的ではないインポートを静的なインポートと呼ぶことがある。以降では、動的に他のアプリのプログラムをインポートすることを動的インポートまたはダイナミックインポート（ＤｙｎａｍｉｃＩｍｐｏｒｔ）と呼ぶ。ここではアプリ３１１が、アプリＡ３１０のエクスポートしているプログラムをインポートし、そのプログラムを実行することができる例を示す。また、アプリＣ３１２が、アプリＡ３１０のプログラムを動的インポートし、アプリＡ３１０がエクスポートしているプログラムを実行することができる例を示す。画像形成装置１００では一つ、あるいは複数のアプリを動作させることが可能である。ここではアプリを三つ例示していが、エクスポートとインポートとを行う、といった複数の条件を持ったアプリや、いずれも行っていないアプリでも、画像形成装置１００上で動作することが可能である。アプリのライフサイクルには、インストール、開始、停止、アンインストール、アップデートといったイベントがある。ユーザ管理者は、情報処理装置１０１からネットワーク１２０経由で、アプリのライフサイクルを管理することができる。

例えば、ユーザ管理者からアプリＡ３１０のインストール指示を受け付けると、アプリ管理フレームワーク３０２はアプリＡ３１０のプログラムファイルを記憶装置２０２に記憶する。この状態では、プログラムファイルが画像形成装置１００に記憶されただけの状態になるため、インストールされたアプリＡ３１０はユーザ操作を直接受け付けることはできない。その後、ユーザ管理者からインストールされたアプリＡ３１０に対して開始指示を受け付けると、アプリ管理フレームワーク３０２はアプリ３１０の開始処理を行う。開始処理が完了すると、アプリＡ３１０は開始状態となり、ユーザインターフェース部２０１である操作画面にアプリＡ３１０のアイコンを表示する。そして、ユーザ管理者から操作画面に表示したアプリＡ３１０のアイコンの選択を受け付けると、アプリＡ３１０はユーザ操作を受け付け、Ｊａｖａ実行環境３０１上でアプリＡ３１０のプログラムが実行される。この例では、アプリＡ３１０が、ユーザ操作を受け付けて、アプリ３１０のプログラムを実行したことになる。一方で、アプリＡ３１０はプログラムをエクスポートしているため、アプリＡ３１０がインストールされただけの状態でも、他の開始されたアプリ（例えば、操作画面にアイコンが表示されたアプリＢ３１１がユーザ操作を受け付けて、アプリＡ３１０のプログラムを実行することもできる。

アプリクラスローダ群３３１は、各アプリのプログラムをクラスロードするためのアプリクラスローダの集まりである。アプリクラスローダ群３３１は、アプリ管理フレームワーク３０２のプログラムの一部である。アプリ管理フレームワーク３０２は、アプリを記憶装置２０２に記憶すると、インストールしたアプリ用のアプリクラスローダを生成する。そのため、アプリクラスローダとアプリは１対１の関係となっていて、アプリクラスローダからはどのアプリに対応するかがわかるようになっている。アプリクラスローダ３３１０、３３１１、３３１２はそれぞれ、アプリＡ３１０、アプリＢ３１１、アプリＣ３１２に対応したアプリクラスローダである。サポートライブラリ３４０は、アプリによる利用に供すべく、画像形成装置１００のさまざまな機能を提供するためのライブラリである。

セキュリティモジュール３５０は、アプリを信頼できるか否かを判定するプログラムモジュールである。セキュリティモジュール３５０は、アプリのプログラムファイルや、マニフェストファイルが信頼できるファイルかを検証し、アプリが信頼できるものか否かを判定している。セキュリティモジュール３５０は、例えば、破損や改ざんによりプログラムファイルが一部変更されていた場合は、信頼できないアプリとして判断する。本実施例では、信頼できるか否かを検証する方法として、ファイルのハッシュ値を比較する方法を行う。この方法では、準備として、ファイルを信頼できるタイミングでそのファイルのハッシュ値（以降、正解値）を計算し、あらかじめ記憶しておく。そして、例えばファイルを使用するタイミングで、同じファイルのハッシュ値を再度計算し、記憶しておいた正解値と比較して、差がないかを確認する方法である。この方法では、ハッシュ値の比較を行った時に、記憶された正解値と再計算したハッシュ値とに差があった場合に、信頼できないと判断する。そのため、セキュリティモジュール３５０は、あらかじめ正解値の作成も行う。

なお、Ｊａｖａ実行環境３０１やアプリ管理フレームワーク３０２、サポートライブラリ３４０、セキュリティモジュール３５０は画像形成装置１００のシステムに含まれるプログラムである。システムに含まれるプログラムとは、画像形成装置１００を管理し制御するために製造時にインストールされた基本的なプログラムであり、アプリケーションプログラムに対する環境を構成する。

ユーザ管理者から、アプリのインストール指示を受け付けると、アプリ管理フレームワーク３０２は、アプリを画像形成装置１００にインストールすると同時に、インストールしたアプリの正解値（すなわち基準となるハッシュ値）の生成をセキュリティモジュール３５０に依頼する。セキュリティモジュール３５０は、正解値生成の依頼を受けると、対象となるアプリのプログラムファイル、およびマニフェストファイルに対するそれぞれのハッシュ値を計算し、計算したハッシュ値を正解値として記憶装置２０２に記憶する。正解値が紐づけられて初めてそのアプリは実行可能とされる。ユーザ管理者から、アプリの開始指示を受け付けると、アプリ管理フレームワーク３０２は、アプリが信頼できるアプリか否かの検証を、セキュリティモジュール３５０に依頼する。セキュリティモジュール３５０は、信頼確認（すなわち検証）の依頼を受けると、アプリのプログラムファイル、およびマニフェストファイルに対するそれぞれのハッシュ値を計算し、あらかじめ記憶したそれぞれの正解値と比較を行う。セキュリティモジュール３５０は、プログラムファイルおよびマニフェストファイルの両方について、ここで計算したハッシュ値と正解値に差がなければ、懸賞の対象であるアプリを信頼できるアプリと判定する。一方、いずれかに差があれば信頼できないアプリと判定する。アプリ管理フレームワーク３０２は、セキュリティモジュール３５０から検証結果を受け取り、開始指示を受けたアプリが信頼できるアプリであった場合に、アプリの開始処理を続ける。信頼できないアプリであった場合は、アプリの開始処理を中断し、情報処理装置１０１を介して、ユーザ管理者に信頼できないアプリである旨の警告を行う。なお検証方法に関して、ここではハッシュ値の比較による検証方法について例を示したが、信頼できるか否かを検証できる方法であれば他の方法であっても良い。

●アプリのファイル構造
図４は、記憶装置２０２にインストールされた各アプリを模式的に表した例である。ユーザ管理者からアプリのインストール指示を受け付けると、アプリ管理フレームワーク３０２は、インストールリクエストのあったアプリのディレクトリを記憶装置２０２の中に作成する。ここでは例として、／ＨＤＤ／ｉｎＳｔａｌｌ＿ａｐｐというディレクトリパスの下に、アプリのディレクトリを作成している。そして、アプリがデータを格納しておくためのデータディレクトリ４０１、アプリを管理するために利用するアプリ管理ファイルも作成する。アプリ管理ファイルは、アプリの状態、例えば「インストール済み」「開始済み」といったアプリの情報の記載を行うためのファイルである。そして、インストール指示のあったアプリのマニフェストファイル４０２、プログラムファイル４０３もこのアプリのディレクトリ内に配置する。元々マニフェストファイル４０２と、プログラムファイル４０３とは、アプリの内部に保持されており、ユーザ管理者からアプリインストールを受け付けた際に、情報処理装置１０１を介して、アプリ管理フレームワーク３０２に渡される。そして、アプリ管理フレームワーク３０２は、渡されたマニフェストファイル４０２、プログラムファイルを、それぞれマニフェストファイル４０２、プログラムファイル４０３として記憶装置２０２に記憶する。Ｊａｖａのプログラムは名前空間で管理されており、各プログラムファイルも名前空間に従って配置する。さらに、各プログラムファイルはｃｌａｓｓ拡張子の形式でアプリ内に用意されており、各ｃｌａＳＳ拡張子のプログラムファイルを、１つもしくは複数のｊａｒ拡張子のファイル形式に圧縮してある。ここでは例として、アプリＡ３１０のディレクトリ構成を表しているが、アプリＢ３１１、アプリＣ３１２も同様のディレクトリ構成となる。ただし、マニフェストファイルに記載されている内容や、プログラムの内容は各アプリによって異なる。

●マニフェストファイル
図５は、各アプリが内部に保持しているマニフェストファイルを模式的に表した例である。マニフェストファイル４０２はアプリＡ３１０のマニフェストファイルである。アプリＡ３１０のアプリ開発者は、マニフェストファイルに、アプリ管理フレームワーク３０２が各アプリを識別するための"Ａｐｐ－ＩＤ"を記載する。他にも、アプリ開発者は、アプリのどのプログラムをエクスポートするかを"Ｅｘｐｏｒｔ－Ｐａｃｋａｇｅ："の後に記載することができる。同様に、他のアプリのどのプログラムをインポートするかを"Ｉｍｐｏｒｔ－Ｐａｃｋａｇｅ："の後に、他のアプリのどのプログラムを動的インポートするかを"Ｄｙｎａｍｉｃ－Ｉｍｐｏｒｔ："の後に記載する。このようにマニフェストファイルにパッケージのインポートやエクスポート等を宣言しておくことができる。なおパッケージとはクラスファイルの集まりということができる。アプリ管理フレームワーク３０２は、アプリのマニフェストファイルを参照して、各アプリがどのプログラムのエクスポート、またはインポート、または動的インポートを行うかを判断することができる。アプリがエクスポート、インポート、動的インポートのいずれも行わない場合、アプリ開発者はマニフェストファイルの該当する項目を空欄にしておく。

アプリＡ３１０はエクスポートを行うアプリのため、アプリＡのマニフェストファイル４０２には、"Ｅｘｐｏｒｔ－Ｐａｃｋａｇｅ"に、公開するプログラム名が記載されている。ここでは、"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"という名前空間が指定されている。アプリＡ３１０のマニフェストファイル４０２の記載の場合、アプリＡ３１０のプログラムのうち、名前空間が"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"で始まるプログラムを、他のアプリに対して公開すると宣言することになる。図４で図示されたアプリＡ３１０のプログラムでは、ｐｒｏｇｒａｍＡ１．ｃｌａｓｓを他のアプリに対して公開している。

マニフェストファイル４０４はアプリＢ３１１のマニフェストファイルである。アプリＢ３１１のマニフェストファイル４０４には"Ｉｍｐｏｒｔ－Ｐａｃｋａｇｅ"に、アプリＢ３１１が参照したい他のアプリのプログラム名が記載されている。ここでは、"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"という名前空間が指定されている。アプリＢ３１１は、他のアプリがエクスポートしているプログラムのうち、名前空間が"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"で始まるプログラムを、他のアプリから参照すると宣言することになる。アプリＢ３１１の開始時に、アプリＢ３１１が"Ｉｍｐｏｒｔ－Ｐａｃｋａｇｅ"で宣言しているプログラムを、他のどのアプリもエクスポートしていない場合、アプリ管理フレームワーク３０２は、アプリＢ３１１の開始処理を中断する。

マニフェストファイル４０５はアプリＣ３１２のマニフェストファイルである。アプリＣ３１２のマニフェストファイル４０５には"ＤｙｎａｍｉｃＩｍｐｏｒｔ－Ｐａｃｋａｇｅ"に、アプリＣ３１２が参照したい他のアプリのプログラム名が記載されている。ここでは、"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"という名前空間が指定されている。アプリＣ３１２は、他のアプリがエクスポートしているプログラムのうち、名前空間が"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"で始まるプログラムを、参照すると宣言することになる。アプリＢ３１１と異なり、アプリＣ３１２は、他のアプリのプログラムを動的インポートすることができる。そのため、アプリＣ３１２の開始時に、"ＤｙｎａｍｉｃＩｍｐｏｒｔ－Ｐａｃｋａｇｅ"で宣言しているプログラムを、他のどのアプリがエクスポートしていない場合でも、アプリ管理フレームワーク３０２は、アプリＢ３１１を開始する。そのため、一般に、アプリＣ３１２のアプリ開発者は、宣言した他のアプリのプログラムがないことも想定して、アプリＣ３１２を開発する。

●インポート／エクスポート／動的インポート
図６は、アプリ管理フレームワーク３０２が、メモリ内で記憶するエクスポートパッケージ、インポートパッケージ、動的インポートパッケージを模式的に表した例である。ここでは各情報をリストで管理している例を表す。このリストは、画像形成装置１００により、後述する図１２の手順で作成される。
図６（ａ）はアプリ管理フレームワーク３０２が管理するエクスポートパッケージリスト６０１である。エクスポートパッケージスト６０１は、アプリケーションＩＤ（Ａｐｐ－ＩＤ）"ＡｐｐＡ"とエクスポートパッケージ名（Ｅｘｐｏｒｔ－Ｐａｃｋａｇｅ）"ａｐｐＡｐａｃｋａｇｅ．ｐｕｂｌｉｃ"の対になっており、アプリ管理フレームワーク３０２は、どのアプリがどのプログラムをエクスポートしているかを管理している。

図６（ｂ）は、アプリ管理フレームワーク３０２が管理するアプリ毎のパッケージリスト６０２、６０５、６０８、６１１である。エクスポートパッケージリスト６０１は１つのリストで全アプリの情報を管理していたのに対し、図６（ｂ）のパッケージリストは、アプリ毎のパッケージ情報をリストとして管理している。パッケージリストには、各アプリが宣言しているインポートパッケージ、および動的インポートパッケージｅをそれぞれリストとして管理している。アプリ管理フレームワーク３０２は、アプリを開始する際に、アプリが宣言しているインポートパッケージ、動的インポートパッケージの情報を取得し、開始するアプリに関するパッケージリストを記憶する。その際にインポートパッケージに関して、アプリ管理フレームワーク３０２は、エクスポートパッケージリスト６０１からアプリを特定し、エクスポートしているアプリと合わせて、インポートパッケージリストを管理する。そのためインポートパッケージリストは、各アプリが宣言しているインポートパッケージ情報と、そのパッケージをエクスポートしているアプリ（"Ａｐｐ－ＩＤ"）の対として、管理されている。

パッケージリスト６０２は、アプリ管理フレームワーク３０２が持つアプリＡ３１０のパッケージリストである。パッケージリスト６０２には、アプリＡ３１０に関するインポートパッケージリスト６０３、動的インポートパッケージリスト６０４がある。図５に示す通り、アプリＡ３１０は、インポートパッケージ、動的インポートパッケージをともに宣言していない為、各パッケージリスト６０３、６０４は空となる。

パッケージリスト６０５は、アプリ管理フレームワーク３０２が持つアプリＢ３１１のパッケージリストである。パッケージリスト６０５には、アプリＢ３１１に関するインポートパッケージリスト６０６、動的インポートパッケージリスト６０７がある。図５に示す通り、アプリＢ３１１は、インポートパッケージに、アプリＡ３１０の"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"を宣言しているため、その情報がインポートパッケージリスト６０６として管理されている。アプリＢ３１１は動的インポートパッケージを宣言していない為、動的インポートパッケージリスト６０７は空となる。

パッケージリスト６０８は、アプリ開始時の、アプリ管理フレームワーク３０２が持つアプリＣ３１２のパッケージリストである。パッケージリスト６０８には、アプリＣ３１２に関するインポートパッケージリスト６０９、動的インポートパッケージリスト６１０がある。図５に示す通り、アプリＣ３１２は、インポートパッケージを宣言していない為、インポートパッケージリスト６０９は空となる。一方で、アプリＣ３１２は、動的インポートパッケージに、アプリＡ３１０の"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"を宣言しているため、その情報が動的インポートパッケージリスト６１０として管理されている。アプリＣ３１２を開始した後、アプリＣ３１２が"ａｐｐＡ．ｐａｃｋａｇｅ．ｐｕｂｌｉｃ"のプログラムを初めて実行すると、アプリ管理フレームワーク３０２は、アプリＣ３１２の動的インポートを行う。

パッケージリスト６１１は、動的インポートを行った後のアプリＣ３１２のパッケージ情報である。動的インポートの際、アプリ管理フレームワーク３０２は、動的インポートパッケージリスト６１０にあるパッケージをエクスポートしているアプリをエクスポートパッケージリスト６０１から特定する。そして、インポートパッケージリスト６０９に、動的インポートを行ったパッケージ情報と、そのパッケージをエクスポートしているアプリの情報を追加する。追加後、アプリ管理フレームワーク３０２は、動的インポートを行ったパッケージ情報を、動的インポートパッケージリスト６１０から削除する。

なお、本実施例では、エクスポートパッケージリスト６、パッケージリスト、インポートパッケージリスト、動的インポートパッケージリストをメモリ上に生成する例を示す。しかし、メモリ上以外の場所に生成しても良く、例えば記憶装置２０２上で生成し、管理しても良い。

●操作画面例
図７は、ユーザインターフェース部２０１である操作画面を模式的に示した図である。ユーザが画像形成装置１００を利用する際、ユーザインターフェース部２０１の操作画面には始め、実行が開始されている各アプリのアイコンを並べたメインメニューが表示される。ユーザがメインメニューに表示されたアイコンを選択すると、操作画面がアプリの画面に遷移し、そこでユーザはアプリの機能を実行することができるようになる。ここでは、例として、アプリＡ３１０が記憶装置２０２にドキュメントデータを保存するドキュメント保存機能を持ち、その機能を実行するためのプログラムをエクスポートしているとする。

またアプリＢ３１１は、スキャナー部２０４でドキュメントをスキャンするスキャン機能と、スキャンしたドキュメントを記憶装置２０２に保存する機能を持つとする。さらにアプリＢ３１１は、ドキュメント保存機能を、他のアプリのプログラムを実行することで実現する。ここでは、アプリＡ３１０がドキュメントを保存するためのプログラムをエクスポートしているため、アプリＢ３１１の開始処理の中で、アプリＢ３１１がアプリＡのプログラムをインポートする。そして、ユーザが操作画面で、開始完了後のアプリＢ３１１のアイコンを選択すると、アプリＢ３１１はスキャン機能を実行し、その後、アプリＡ３１０のドキュメント保存機能を実行する。もし、アプリＡ３１０が画像形成装置にインストールされていない場合、アプリＢ３１１の開始処理でアプリＡ３１０のプログラムをインポートができなくなるため、アプリ管理フレームワーク３０２は、アプリＢ３１１の開始処理を中断する。

アプリＣ３１２は、スキャナー部２０４でドキュメントをスキャンするスキャン機能と、スキャンしたドキュメントの保存を記憶装置２０２か外部サーバ（例えば情報処理装置１０１の記憶部）にするかをユーザが選択できる保存先選択機能を持つとする。ユーザが記憶装置２０２への保存を選択した場合、アプリＣ３１２は、アプリＢ３１１と同様に、アプリＡ３１０のプログラムを実行することで実現する。一方、ユーザが外部サーバ（例えば情報処理装置１０１の記憶部）への保存を選択した場合、アプリＣ３１２はアプリＣ３１２自身のプログラムを実行して、外部サーバへの保存機能を実現するとする。ここでアプリＣ３１２は、アプリＢ３１１と同様、アプリＡ３１０がインストールされていないと記憶装置２０２へのドキュメント保存機能を実行できなくなる。これにより、アプリ管理フレームワーク３０２は、アプリＢ３１１とは異なり、アプリ開始処理中ではなく、アプリＣ３１２が初めて動的インポートするプログラムを実行したタイミングでアプリＣ３１２がインポートを行うようになる。その制約として、アプリＣのアプリ開発者は、動的インポートするプログラムがエクスポートされていないケースも考慮して、アプリＣ３１２を開発する。アプリ開発者は、もし動的インポートするプログラムがエクスポートされていない状態で、そのプログラムの実行を試みられた場合でも、アプリＣ３１２が適切なエラーハンドリングを行い、正常動作できるように、アプリＣ３１２を開発する必要がある。これにより、もしアプリＡ３１０がインストールされていない状態でも、ユーザは画像形成装置１００で、アプリＣ３１２の一部機能を利用することができるようになる。

図７（ａ）は、アプリＡ３１０、アプリＢ３１１、アプリＣ３１２のインストール後に、アプリＢ３１１、アプリＣ３１２が開始された際の、操作画面に表示されるメインメニューを示している。アプリＡ３１０はインストールされただけの状態であり、開始されていないため、アイコンが表示されていない。対して、アプリＢ３１１、アプリＣ３１２に関して、開始処理が完了した後の画面が示されているため、アプリＢ３１１、アプリＣ３１２のそれぞれのアイコン７０１、７０２がメインメニューに表示されている。ユーザは、アイコン７０１を選択することで、アプリＢ３１１の機能を利用することができる。同様に、ユーザはアイコン７０２を選択することで、アプリＣ３１２の機能を利用することができる。

図７（ｂ）は、図７（ａ）の状態でユーザがアイコン７０１を選択して、さらにユーザがスキャン機能を利用した後、操作画面に表示されるアプリＢ３１１の画面を模式的に示している。アプリＢは、ドキュメント保存機能をアプリＡ３１０のプログラムを実行して実現している。そのため、操作画面上にはアプリＢ３１１の画面が表示されているが、その中でアプリＢ３１１は、アプリＡ３１０の画面７０４を表示している。ユーザが、画面７０４の操作を行うと、アプリＢ３１１はアプリＡ３１０のプログラムを実行して、ドキュメント保存機能を実現する。

図７（ｃ）は、図７（ａ）の状態でユーザがアイコン７０２を選択して、さらにユーザがスキャン機能を利用した後、操作画面に表示されるアプリＣ３１２の画面を模式的に示している。アプリＣ３１２の画面には、スキャンしたドキュメントの保存先をユーザに選択してもらう画面が表示されている。アイコン７０５は、それが選択された時に、スキャンしたドキュメントを記憶装置２０２に保存する機能を実行するためのアイコンである。アイコン７０６は、それが選択された時に、スキャンしたドキュメントを外部サーバ（例えば情報処理装置１０１の記憶部）に保存する機能を実行するためのアイコンである。ユーザがアイコン７０５を選択するとアプリＣ３１２はアプリＡ３１０のプログラムを実行して保存機能を実現する。この時、初めてアプリＣ３１２がアプリＡ３１０のプログラムを実行する場合、アプリＣ３１２がアプリＡ３１０のプログラムをインポートする。その後で、アプリＣ３１２がアプリＡ３１０のプログラムを実行する。ユーザがアイコン７０６を選択するとアプリＣ３１２はアプリＣ３１２自身のプログラムのみで保存機能を実現する。

図７（ｄ）は、アプリＡ３１０を画像形成装置１００にインストールしていない状態のアプリＣ３１２の画面を示している。アプリＡ３１０がインストールされていない状態でも、アプリ管理フレームワーク３０２はアプリＣ３１２の開始処理を完了させるため、操作画面のメインメニューにアプリＣ３１２のアイコン７０２が表示される。その状態でユーザがアイコン７０２を選択して、さらにユーザがスキャン機能を利用した後、操作画面に表示されるアプリＣ３１２の画面を模式的に示している。アイコン７０７は、アイコン７０５と同様、選択された時に、スキャンしたドキュメントを記憶装置２０２に保存する機能を実行するためのアイコンである。しかし、アプリＡ３１０のプログラムを実行できない状態であるため、選択できないことを示す網掛け表示になっている。アプリＣ３１２は、選択機能の画面表示時に動的インポートしているプログラムを実行して、エクスポートされたプログラムがないことを確認した後に、アイコン７０７を表示にする。もしくは、アプリＣ３１２は、初めはアイコン７０５を表示し、ユーザがアイコン７０５を選択した後、エクスポートされているプログラムがなかった場合に、アイコン７０７を表示するようにしても良い。これにより、画像形成装置１００にアプリＡ３１０がインストールされていなくても、ユーザは、アイコン７０６を選択することで、アプリＣの一部機能を利用することができる。

なお、ここでは、スキャンドキュメントの保存機能を実現するアプリや画面遷移、網掛け表示による動的インポートのエラーハンドリングを例として示したが、他の機能を持つアプリ、画面遷移、エラーハンドリングを行っても良い。

●アプリのインストール処理
図８は、アプリ管理フレームワーク３０２がアプリをインストールするときの処理のフローを示している。ユーザ管理者から、情報処理装置１０１を介して、画像形成装置１００にアプリのインストール指示を受け付けると、アプリ管理フレームワーク３０２がアプリのインストール処理を開始する。ユーザからインストール指示を受け付けると、情報処理装置１０１を介して、アプリのプログラムファイル、マニフェストファイルを、アプリ管理フレームワーク３０２は渡される。図８の処理は、ハードウェア上は、例えば画像形成装置１００のコア部２００、特にそのプロセッサにより実行される。

Ｓ８０１で、アプリ管理フレームワーク３０２は、渡されたプログラムファイル、およびマニフェストファイルを記憶装置２０２内に保存する。記憶装置２０２への保存の仕方の一例は図４で示した通りである。

そして、Ｓ８０２で、アプリ管理フレームワーク３０２は、インストールするアプリ用のアプリクラスローダをメモリ上に生成する。同時に、インストールするアプリ用のパッケージリストを生成する。Ｓ８０２の後、Ｓ８０３で、アプリ管理フレームワーク３０２は、インストールするアプリの信頼性検証（すなわち改ざんや破損がないことの検証）を行うときに必要な正解値の生成をセキュリティモジュール３５０に依頼し、生成された正解値を受け取る。正解値の生成が完了するとＳ８０４へ処理を進める。Ｓ８０４で、アプリ管理フレームワーク３０２は、記憶装置２０２に保存したマニフェストファイルの記載内容からアプリケーションＩＤ（Ａｐｐ－ＩＤ）情報、およびエクスポート情報、動的インポート情報を取得する。

そしてＳ８０５で、アプリ管理フレームワーク３０２はＳ８０４で取得したマニフェスト記載情報の中に動的インポートするプログラムの情報があったかを判定する。そして、情報があった場合はＳ８０６に処理を進め、記載がなかった場合はＳ８０７に処理を進める。

Ｓ８０６で、アプリ管理フレームワーク３０２は、インストールするアプリの動的インポートパッケージリストに、Ｓ８０４で取得した動的インポートするプログラムの情報を全て追加する。

そして、Ｓ８０７に処理を進める。Ｓ８０７で、アプリ管理フレームワーク３０２はＳ８０４で取得したマニフェスト記載情報の中にエクスポートするプログラムの情報があったかを判定する。

情報があった場合は、Ｓ８０８に処理を進め、記載がなかった場合はアプリのインストール処理を終了する。Ｓ８０８で、アプリ管理フレームワークはエクスポートパッケージリスト６０１に、Ｓ８０４で取得したＡｐｐ－ＩＤ情報、およびエクスポートするプログラムの情報を全て追加する。エクスポートパッケージリストへの追加が終わると、インストールするアプリがプログラムのエクスポートを行ったことになる。そして、アプリ管理フレームワーク３０２が、アプリ管理ファイルのアプリの状態をインストール済みに更新した後、アプリインストールの処理を終了する。

図８に示すフローを行うことで、アプリをインストールするとともに、図６に示したエクスポートパッケージリスト６０１の更新、インストールしたアプリのパッケージリストおよび動的インポートパッケージリストが生成することができる。

●アプリの実行開始
図９は、アプリ管理フレームワーク３０２がアプリの実行を開始するときの処理のフローを示している。ユーザ管理者が、情報処理装置１０１を介して、画像形成装置１００にアプリの開始指示を行うと、アプリ管理フレームワーク３０２がアプリの開始処理を行う。図９の処理は、画像形成装置が起動された際の、後述する図１２の手順の中で実行される。図９の処理も、ハードウェア上は、例えば画像形成装置１００のコア部２００、特にそのプロセッサにより実行される。

開始処理を始めると、まずＳ９０１で、アプリ管理フレームワーク３０２は、開始するアプリの信頼性検証をセキュリティモジュール３５０に依頼する。信頼できないと判定された場合はＳ９０２に処理を進め、信頼できるアプリと判定された場合はＳ９０４に処理を進める。
Ｓ９０２で、アプリ管理フレームワーク３０２は、アプリの開始中断処理を行い、ユーザインターフェース部２０１もしくは、情報処理装置１０１を介して、ユーザに、実行しようとしているアプリが信頼できない旨の警告を通知する。
そしてＳ９０３で、アプリ管理フレームワーク３０２は、信頼できないと判定されたアプリがエクスポートしているプログラムを、エクスポートパッケージリスト６０１から削除する。
Ｓ９０４で、アプリ管理フレームワーク３０２は、インポート処理済みであるか判定する。すなわち、開始するアプリのインポートパッケージリストがあるか否かを判定する。インポートパッケージリストがなければ、開始するアプリのインポートパッケージリストを作成し、Ｓ９０５へ処理を進め、すでにあればＳ９１２へ処理を進める。

Ｓ９０５で、アプリ管理フレームワーク３０２は、記憶装置２０２に保存したマニフェストファイルの記載内容からインポート情報を取得する。
そしてＳ９０６で、アプリ管理フレームワーク３０２はＳ９０５で取得したマニフェスト記載情報の中にインポートするプログラムの情報があったかを判定する。そして、情報があった場合はＳ９０７に処理を進め、記載がなかった場合はＳ９１２に処理を進める。
Ｓ９０７で開始するアプリがインポートするプログラムの数だけ、インポートする各プログラムに順次着目して、Ｓ９０８～Ｓ９１０の反復処理を行う。なおこの反復は、後述のＳ９０９からＳ９１０へと分岐したなら中断してよい。
Ｓ９０８で、アプリ管理フレームワーク３０２は、インポートする着目プログラムをエクスポートしているアプリを特定する。アプリ管理フレームワーク３０２は、インポートパッケージリストのプログラムがエクスポートパッケージリスト６０１にあるかを順に検索し、検索で見つかった場合はそのＡｐｐ－ＩＤを取得することでアプリを特定する。

Ｓ９０９で、もしエクスポートパッケージリスト６０１に着目プログラムがなくアプリを特定できなかった場合は、Ｓ９１０へ処理を進め、着目プログラムをエクスポートするアプリを特定できた場合はＳ９１１へ処理を進める。
Ｓ９１０で、アプリ管理フレームワーク３０２は、アプリの開始中断処理を行い、ユーザインターフェース部２０１もしくは、情報処理装置１０１を介して、ユーザにインポートするプログラムがない旨の警告を通知する。
Ｓ９１１で、アプリ管理フレームワークはインポートパッケージリストに、インポートする着目プログラムの情報と、Ｓ９０８で特定したアプリの情報を追加する。追加が終わると、開始するアプリが、エクスポートを行っているアプリのインポート処理を行ったことになる。インポートするプログラムのうち未処理のものがあればその一つに着目してＳ９０８から繰り返す。なければＳ９１２に処理を進める。

Ｓ９１２で、開始するアプリのインポートパッケージリストにプログラムが追加されていれば、Ｓ９１３へ処理を進め、プログラムが無ければＳ９１９へ処理を進める。
Ｓ９１３で、開始するアプリがインポートパッケージリストのプログラム数だけ、インポートする各プログラムに順次着目して、Ｓ９１４～Ｓ９１６の反復処理を行う。なおこの反復は、後述のＳ９１６からＳ９１７へと分岐したなら中断してよい。
Ｓ９１４で、アプリ管理フレームワーク３０２は、インポートする着目プログラムをエクスポートしているアプリを特定する。すでに、Ｓ９０８でアプリを特定しているため、アプリ管理フレームワーク３０２はインポートパッケージリストにあるアプリ情報を参照することでアプリを特定できる。
Ｓ９１５で、アプリ管理フレームワーク３０２は、特定したアプリの信頼性検証をセキュリティモジュール３５０に依頼する。
Ｓ９１６で、検証の結果、信頼できないと判定された場合は、Ｓ９１７に処理を進め、信頼できるアプリと判定された場合はＳ９１４、もしくはＳ９１９に処理を進める。処理すべきアプリが残っていればＳ９１４、なければＳ９１９である。またＳ９１７に分岐した場合にはＳ９１３から始まるループを終了してよい。

Ｓ９１７で、アプリ管理フレームワーク３０２は、アプリの開始中断処理を行い、ユーザインターフェース部２０１もしくは、情報処理装置１０１を介して、ユーザに警告を通知する。
そしてＳ９１８で、アプリ管理フレームワーク３０２は、信頼できないと判定されたアプリがエクスポートしているプログラムを、エクスポートパッケージリスト６０１から削除する。そして、開始を中断したアプリのインポートパッケージリストを削除し、アプリの開始処理を終了する。
Ｓ９１９は、インポートするプログラムがない場合、またはインポートするプログラムの検証がすべて成功した場合に実行される。Ｓ９１９で、アプリ管理フレームワーク３０２は、開始するアプリのアイコンをユーザインターフェース２０１である操作画面に表示し、アプリ管理ファイルのアプリの状態を開始済みに更新した後、アプリの開始処理を完了する。

図９に示すフローの処理を行うことで、システムは、アプリを開始する場合に、そのアプリの検証を行うことができる。さらに、アプリのインポート情報を基に、Ｓ９１５で、開始しようとするアプリが実行する可能性のある他のアプリ（インポートしているアプリ）のリスト（インポートリスト）を作成し、そのアプリの検証も行うことができる。そして、信頼できないアプリがあった場合は、システムが適切なエラーハンドリングを行うことができる。例えば、システムがアプリＢ３１１の開始指示を受け付けた時に、アプリＡ３１０のプログラムが攻撃者によって改ざんされていた場合、Ｓ９１５、Ｓ９１６の処理により、システムはアプリＢが信頼できないアプリであると判断することができる。そして、アプリＢにアプリＡのプログラムを実行させないために、アプリ管理フレームワーク３０２は、アプリＡの開始処理を中断することができる。

●アプリの実行
図１０、図１１は、アプリ管理フレームワーク３０２がアプリの開始処理を完了したあとに、ユーザがアプリの実行を指示した時の処理のフローを示している。アプリはそのプログラムコードを実行するエンジンモジュール（不図示）により実行される、エンジンモジュールは、ハードウェア上は、画像形成装置１００のコア部２００、特にそのプロセッサにより実行される。エンジンモジュールは、本例ではＪａｖａ実行環境３０１に含まれたＪａｖａ仮想マシン（ＪＶＭ）であり、それによりアプリやサポートライブラリ３４０が実行される、なおアプリがコア部２００により実行可能なネイティブコードで記述されている場合には、コア部２００が直接アプリを実行してよい。なお図10、図１１ではソフトウェア上の実行主体は、Ｊａｖａ実行環境３０１内のＪＶＭやシステムクラスローダ３０１０であったり、アプリクラスローダであったりするが、その切り換えは例えばＡＰＩなどを介して行われてよい。それについては以下の説明では特に言及しない。

ユーザがアプリの実行を指示すると、Ｊａｖａ実行環境３０１により、図１０の処理が開始される。まずそのアプリのアプリクラスローダが、プログラムをメモリ内にロードしたか否かを判定する（Ｓ１００１）。もし、実行したプログラムがまだメモリ内にロードされていないのであれば、Ｓ１００１からＳ１００２に処理を進め、すでにロード済みであればＳ１００３へ処理を進める。Ｓ１００２で、ロードしようとするアプリのアプリクラスローダがプログラムのロードを行う。この処理の流れは図１１に示す。なおこのとき、ロード対象のプログラムを引数として指定し、Ｓ１００２を実行してもよい。

クラスロードが完了したかをＳ１００３で判定し、成功したならＳ１００４へ処理を進め、クラスロードに失敗するとＳ１００５へ処理を進める。Ｓ１００４では、エンジンモジュールが、メモリ内にロードされたプログラムを実行する。なお、Ｓ１００１～Ｓ１００４の処理は、アプリ３１１～３１２に限らず、システムのプログラムでも同様の処理を行っても良い。例えば、アプリから呼び出されて実行されたシステムのプログラムが、さらに他のシステムのプログラムを実行したケースが該当する。Ｓ１００５で、アプリの処理がまだ終了していないのであれば、Ｓ１００１へ進み、処理が終了したのであれば、図１０のフローを終了する。アプリの処理がまだ終了していないとは例えば、Ｓ１００４でアプリを１ステップごとに実行した場合、各ステップの完了ごとに行う判定である。Ｓ１００４で１ステップごとに実行していない場合には、未ロードのプログラムを実行しようとしたときに、いったんＳ１００５の判定を行う。Ｓ１００２では、図１１で説明するように、システムプログラム、実行するアプリの未ロードのプログラム、インポートするプログラム、動的インポートするプログラムといったプログラムの種類に応じて、プログラムをロードする。それをループにより繰り返し行うことで、ロードすべきプログラムを、その都度動的にロードする。

図１１は、図１０のＳ１００２でアプリクラスローダが未ロードのプログラムをロードする処理のフローを示す。Ｓ１１０１で、アプリクラスローダはまず、未ロードのプログラムをロードするようにシステムクラスローダ３０１０へ依頼する。もし未ロードのプログラムにシステムプログラムが含まれている場合は、システムクラスローダ３０１０が該当するシステムプログラムをロードする。
Ｓ１１０２で、システムクラスローダ３０１０がプログラムを成功裏にロードできたか判定する。できなかった場合は、Ｓ１１０３へ処理を進める。できた場合には処理を終了してＳ１００３へ戻る。またシステムプログラムをロード済みの場合には、ロードできなかったと判定してＳ１１０３へ分岐する。

Ｓ１１０３では、実行対象のアプリのアプリクラスローダは、アプリクラスローダ自身が対応するアプリのインポートパッケージリストに、未ロードのプログラムとそれをエクスポートするアプリの情報があるかを判定する。Ｓ１１０３で情報があると判定した場合、Ｓ１１０４へ処理を進め、情報がないと判定した場合、Ｓ１１０６へ処理を進める。Ｓ１１０４で、アプリクラスローダは、インポートパッケージリストにあるアプリ（すなわちエクスポートを行っているアプリでもある）に対応した別のアプリクラスローダに、プログラムのロードを依頼する。
Ｓ１１０５で、エクスポートを行っているアプリクラスローダが、エクスポートされているアプリのロードに成功したか判定する。成功したなら、プログラムのロード処理を終了する。ロードに成功しなかった場合は、Ｓ１１０６へ処理を進める。インポート対象のプログラムを既にロード済みの場合にはロードできなかったと判定してＳ１１０６へ分岐する。
Ｓ１１０６で、アプリクラスローダは未ロードのプログラムを、アプリクラスローダ自身に対応するアプリが持つプログラムからロードしようとする。
Ｓ１１０７で、プログラムのロードが成功したか判定する。もしアプリが未ロードのプログラムを持っていた場合は、プログラムのロードに成功し、プログラムのロード処理を終了する。プログラムのロードに失敗した場合、Ｓ１１０８へ処理を進める。アプリのプログラムをロード済みの場合にもロードできなかったと判定してＳ１１０８へ分岐する。

Ｓ１１０８で、アプリクラスローダは、アプリクラスローダ自身が対応するアプリの動的インポートパッケージリストに、未ロードのプログラムの情報があるかを判定する。情報がある場合Ｓ１１０９へ処理を進め、ない場合はＳ１１１０へ処理を進める。
Ｓ１１０９で、アプリクラスローダは未ロードの動的インポート対象のプログラムがエクスポートパッケージリスト６０１にあるかを判定する。該当するプログラムがある場合Ｓ１１１１へ処理を進め、なかった場合はＳ１１１０へ処理を進める。
Ｓ１１１０で、未ロードのプログラムをロードできなかった際のエラー出力を行い、未ロードのプログラムを実行しようとしたアプリもしくはシステムに、エラーを返す。Ｓ１１１０への分岐するのは、Ｓ１１０６でロードが失敗した場合、Ｓ１１０８でインポート対象のプログラムがなかった場合、Ｓ１１０９で、インポート対象のプログラムがえくｓぽーとされていなかった場合の３通りある。このうちＳ１１０８からの分岐はエラーとしなくともよいので、正常終了してもよい。また他の場合にもそれぞれの場合に応じたエラーの理由を出力してもよい。
Ｓ１１１１で、アプリクラスローダは、エクスポートパッケージリスト６０１から、未ロードのプログラムをエクスポートしているアプリを特定する。

そしてＳ１１１２で、Ｓ１１１１で特定したエクスポートを行っているアプリの信頼性検証をセキュリティモジュール３５０に依頼する。
Ｓ１１１３で、エクスポートを行っているアプリの検証が成功し、信頼できるアプリであった場合はＳ１１１６へ処理を進め、懸賞が失敗して信頼できないアプリと判定した場合はＳ１１１４へ処理を進める。
Ｓ１１１４で、アプリクラスローダは、未ロードのプログラムのロード処理を中断し、ユーザインターフェース部２０１もしくは、情報処理装置１０１を介して、ユーザに、動的インポート対象のプログラムが改ざんされているか、または破損していることの警告を通知する。
そしてＳ１１１５で、アプリクラスローダは、信頼できないと判定されたアプリがエクスポートしているプログラムを、エクスポートパッケージリスト６０１から削除する。そして、アプリクラスローダは未ロードのプログラムをロードしないまま、図１１の処理を終了する。

Ｓ１１１３での検証が成功した場合、Ｓ１１１６で、アプリクラスローダは、アプリクラスローダ自身が対応するアプリの動的インポートパッケージリストから、ロードを行おうとしているプログラムの情報を削除する。
そしてアプリクラスローダは、Ｓ１１１７で、削除したプログラムの情報をアプリクラスローダ自身が対応するアプリのインポートパッケージリストへ追加する。追加が終わると、エクスポートしているアプリのプログラムを動的にインポートしたことになる。
Ｓ１１１８で、アプリクラスローダは、Ｓ１１１１で特定したアプリに対応する別のアプリクラスローダに、プログラムのロードを依頼する。
Ｓ１１１９で、プログラムのロードが成功したか判定する。エクスポートを行っているアプリが持つプログラムのロードに成功した場合には、プログラムのロード処理を終了する。ロードに成功しなかった場合は、Ｓ１１２０へ処理を進める。
Ｓ１１２０で、未ロードのプログラムをロードできなかった際のエラー出力を行い、未ロードのプログラムを実行しようとしたアプリもしくはシステムに、エラーを返す。

図１０、図１１に示した処理のフローを行うことで、アプリクラスローダが未ロードの動的インポートされているプログラムをロードして、アプリもしくはシステムがプログラムを実行できるようになる。例えば、アプリＡ３１０のプログラムが攻撃者によって攻撃されていた場合を考える。その場合、アプリＣ３１２が、動的インポートしているアプリＡ３１０のプログラムを初めて実行した時に、Ｓ１１１２、Ｓ１１１３の処理で、システムはアプリＡ３１０が信頼できないアプリであると判断する。そして、アプリＣ３１２にアプリＡ３１０のプログラムを実行させないために、アプリＡ３１０のプログラムのロードを中断することができる。

ここで、図１０では、Ｓ１００５からＳ１００１へと戻るループにより、すべてのロード対象のプログラムそれぞれに対してＳ１００２を繰り返し実行することでプログラムのロードを行う。これにより、ループの繰り返しに従って、Ｓ１００２すなわち図１１では、アプリクラスローダが、システムのプログラム、インポートしているプログラム、プログラムを実行するアプリ自身のプログラム、動的インポートするプログラムの順にロード処理を行っている。この順序は図に示した以外の別の順序でも良い。例えば最優先でアプリ自身のプログラムからロード処理を行い、失敗した場合はシステムのプログラム、インポートしているプログラム、動的インポートするプログラムの順でも良い。

また、図１０、図１１の例では、アプリの開始時に、開始するアプリ、開始するアプリがインポートするプログラムをエクスポートするアプリ、の信頼性検証を行っているが、図１１で各クラスローダがロードを行うタイミングで、信頼性検証を実施しても良い。本実施例の構成では、システムのプログラムはシステムクラスローダ３０１０が、各アプリのプログラムは各アプリクラスローダがロードしている。このような構成でも、図１０、図１１で示す処理のフローを行えば、ロードのためのモジュールが異なっていても、他のクラスローダがロードしようとするプログラムの信頼性検証を行うことができる。

●画像形成装置によるアプリ起動手順
図１２は、画像形成装置１００の起動を行う際の、アプリ管理フレームワーク３０２の処理のフローを示している。ユーザが画像形成装置１００の電源を入れると、ｊａｖａ実行環境３０１がアプリ管理フレームワーク３０２の起動処理を呼び出し、アプリ管理フレームワーク３０２がＳ１２０１の処理を行う。

Ｓ１２０１で、アプリ管理フレームワーク３０２は、画像形成装置１００にインストールされているアプリを調べる。アプリ管理フレームワーク３０２は、記憶装置２０２にあるアプリがインストールされているアプリと判断し、その判断結果を基にどのアプリがインストールされているかの情報を取得する。なおインストールされているアプリが、オペレーティングシステムが資源を管理するためのデータベース（たとえばデポジトリ）に登録されているのであれば、それを参照することで知ることができる。
Ｓ１２０２で、アプリ管理フレームワーク３０２は、画像形成装置１００にインストールされているアプリの数だけ、インストールされたアプリに関する、Ｓ１２０３～Ｓ１２０８の反復処理を行う。

Ｓ１２０３で、アプリ管理フレームワーク３０２は、インストールされているアプリに対応するアプリクラスローダを生成する。同時に、エクスポートパッケージリスト６０１、およびインストールされた各アプリに対応するパッケージリスト（図６（ｂ）参照）も生成する。アプリインストール時とは異なり、信頼性検証に必要な正解値の生成はここでは行わない。アプリをインストールしたときのアプリの状態を正解値として保存しておき、以降では、その正解値を利用し続ける。

Ｓ１２０３の後、Ｓ１２０４で、アプリ管理フレームワーク３０２は、記憶装置２０２にある各アプリのマニフェストファイルの記載内容からＡｐｐ－ＩＤ情報、およびエクスポート、動的インポート情報を取得する。さらに、アプリ管理フレームワーク３０２は、各アプリのアプリ管理ファイルからアプリの状態を取得する。
そしてＳ１２０５で、アプリ管理フレームワーク３０２はＳ１２０４で取得したマニフェスト記載情報の中に動的インポートするプログラムの情報があったかを判定する。そして、情報があった場合はＳ１２０６に処理を進め、記載がなかった場合はＳ１２０７に処理を進める。

Ｓ１２０６で、アプリ管理フレームワーク３０２は、インストールするアプリの動的インポートパッケージリストに、Ｓ１２０４で取得した動的インポートするプログラムの情報を全て追加する。そして、Ｓ１２０７に処理を進める。Ｓ１２０７で、アプリ管理フレームワーク３０２はＳ１２０４で取得したマニフェスト記載情報の中にエクスポートするプログラムの情報があったかを判定する。情報があった場合は、Ｓ１２０８に処理を進め、記載がなかった場合はＳ１２０９へ処理を進める。
Ｓ１２０８で、アプリ管理フレームワークはエクスポートパッケージリスト６０１に、Ｓ１２０４で取得したＡｐｐ－ＩＤ情報、およびエクスポートするプログラムの情報を全て追加する。エクスポートパッケージリストへの追加が終わると、インストールするアプリがプログラムのエクスポートを行ったことになる。
そして、Ｓ１２０９へ処理を進める。Ｓ１２０９で、アプリ管理フレームワーク３０２は、Ｓ１２０４で取得したアプリの状態のうち開始済みアプリの数だけＳ１２１０の反復処理を行う。Ｓ１２１０で、アプリ管理フレームワークは図９に示す、アプリの開始処理を行う。インポートパッケージリストについては、図９の手順の中で、エクスポートされるプログラムと照合したうえで作成される。なお、開始するアプリは、ユーザインターフェースから利用者に指定されたものでよい。

図１２の処理のフローを行うことで、画像形成装置１００の電源を切った際に消失するシステムの情報があっても、再び電源が入った際に、画像形成装置は、電源を切る前と同様のシステム、およびアプリの動作をすることができる。例えば、電源を切る前に各アプリクラスローダはメモリ上で生成されているため、電源を再び入れ直した後はメモリの情報がクリアされ、全てのアプリクラスローダを消失してしまう。そこで、Ｓ１２０３の処理を行うことで、再度各アプリに対応するアプリクラスローダを生成することができる。同様に、電源を切ることでエクスポートパッケージリスト６１０、各アプリのパッケージリスト、動的インポートパッケージリストが消失しても、Ｓ１２０３，Ｓ１２０６，Ｓ１２０８の処理を行うことで再度リストを生成することができる。なお、電源を切ることでインポートパッケージリストが消失してもＳ１２１０の、Ｓ９０５で再度リストを生成することができる。これらの処理により、一度画像形成装置１００の電源を切り、再び電源を入れても、システムが各アプリクラスローダや、各リストを再度生成できるため、システムやアプリは電源を切る前と同様の動作をすることができる。

●実施形態の効果
以上のように、本発明の実施例では、アプリの開始時に、実行対象のアプリおよびそのアプリがインポートするプログラムをエクスポートしているアプリの信頼性検証を行う。さらに、動的インポートを行う際に、アプリの実行中に動的にインポートするプログラムをエクスポートしているアプリの信頼性検証を行う。これにより、プログラムをエクスポートする信頼できない第一のアプリ、第一のアプリプログラムをインポートもしくは動的インポートする第二のアプリがインストールされた構成でも、セキュリティ上のリスクが伴うことがなくなる、例えば、第二のアプリが第一のアプリのプログラムを実行するような構成であっても、第二のアプリの開始時にシステムが第一のアプリの信頼性検証することができる。もしくは、第二のアプリが第一のアプリのプログラムを動的インポートするタイミングで、システムが第一のアプリの信頼性検証することができる。信頼性検証を行った結果、信頼できない第一のアプリのプログラムを実行しないように、例えば第二のアプリの開始処理を失敗させて、エラーハンドリングを行うことができる。

［その他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

さらに、プログラムによる処理をハードウェア回路によって実現することもできる。一般にプログラムによる処理はハードウェア回路としても実装することが可能であり、その回路としては、たとえばＦＰＧＡ等のプログラム可能な回路を用いることもできる。さらにプログラムにより実現されている処理の一部をハードウェア回路で代替することも可能である。

１００画像形成装置、１０１情報処理装置、３０１Ｊａｖａ実行環境、３０２アプリ管理フレームワーク

Claims

複数のアプリケーションが動作する情報処理装置であって、
アプリケーションの信頼性を検証する検証手段と、
前記アプリケーションを制御する制御手段とを有し、
前記制御手段は、ユーザの指示に応じて実行される第１のアプリケーションの実行中に、前記第１のアプリケーションが動的にインポートする第２のアプリケーションを、該第２のアプリケーションのロードの前に前記検証手段により検証させ、
アプリケーションがインストールされた際と、前記情報処理装置の起動の際とに、前記アプリケーションが他のアプリケーションを動的にインポートするか判定し、動的にインポートする場合には動的にインポートされるアプリケーションの第１のリストを生成し、
前記制御手段は、前記検証手段に、前記第１のリストに基づいて前記第２のアプリケーションを検証させる
ことを特徴とする情報処理装置。
請求項１に記載の情報処理装置であって、
前記制御手段はさらに、前記第１のアプリケーションを実行する前に、前記第１のアプリケーションと、前記第１のアプリケーションが静的にインポートする第３のアプリケーションとを前記検証手段に検証させる
ことを特徴とする情報処理装置。
請求項１または２に記載の情報処理装置であって、
前記検証手段は、前記アプリケーションが、インストールされたときから変わっていないことを検証する
ことを特徴とする情報処理装置。
請求項１乃至３のいずれか一項に記載の情報処理装置であって、
前記アプリケーションがインストールされた際と、前記情報処理装置の起動の際とに、他のアプリケーションに対してエクスポートされるアプリケーションを特定し、エクスポートされる場合にはエクスポートされるアプリケーションの第２のリストを生成し、
前記制御手段は、前記第２のアプリケーションが、前記第１のリストと前記第２のリストの両方に含まれている場合に、前記検証手段に前記第２のアプリケーションを検証させる
ことを特徴とする情報処理装置。
請求項１乃至４のいずれか一項に記載の情報処理装置であって、
前記制御手段は、前記検証手段による前記第２のアプリケーションの検証が失敗した場合には、検証が失敗したことを示す情報を出力して、前記第１のアプリケーションの実行を停止する
ことを特徴とする情報処理装置。
請求項５に記載の情報処理装置であって、
ユーザインターフェース手段をさらに有し、
前記制御手段は、前記第２のアプリケーションの検証が失敗したことを示す情報を、前記ユーザインターフェース手段により表示する
ことを特徴とする情報処理装置。
請求項１乃至６のいずれか一項に記載の情報処理装置であって、
画像をスキャンするスキャン手段と、
画像を印刷する印刷手段とをさらに有し、
前記アプリケーションは、前記スキャン手段または前記印刷手段いずれかの機能を利用する
ことを特徴とする情報処理装置。
請求項１乃至７のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
複数のアプリケーションが動作する情報処理装置の制御方法であって、
前記情報処理装置は、アプリケーションの信頼性を検証する検証手段と、前記アプリケーションを制御する制御手段とを有し、
前記制御手段が、ユーザの指示に応じて実行される第１のアプリケーションの実行中に、前記第１のアプリケーションが動的にインポートする第２のアプリケーションを、該第２のアプリケーションのロードの前に前記検証手段に検証させ、
アプリケーションがインストールされた際と、前記情報処理装置の起動の際とに、前記アプリケーションが他のアプリケーションを動的にインポートするか判定し、動的にインポートする場合には動的にインポートされるアプリケーションの第１のリストを生成し、
前記制御手段が、前記検証手段に、前記第１のリストに基づいて前記第２のアプリケーションを検証させる
ことを特徴とする情報処理装置の制御方法。