(第1実施形態)
*画像形成装置1
図1は本発明に係るパッケージング装置を実施し得る画像形成装置の構成を示すブロック図である。
画像形成装置1は、印刷装置11及び画像処理装置12からなる。
画像処理装置12は、制御装置及び演算装置としてのCPU121と、主記憶としての直接記憶部122(例、RAM)と、二次記憶としての間接記憶部123(例、ROMやHDD)を備える。さらに、入力装置としてのユーザインターフェース124と、入出力装置としての外部インターフェース125を備える。
直接記憶部122は、CPU121と直接データをやり取りする記憶部であり、間接記憶部123は直接記憶部122を介してCPU121とデータをやり取りする記憶部である。直接記憶部122には、種々のアプリケーションプログラム及びプラットフォームプログラムが記憶されている。
ユーザインターフェース124は、キーボード、マウス、ディスプレイ等からなり、ユーザからの指示の受付け、データ(画面データ)の表示をすることができる。
外部インターフェース125は、外部装置からのデータの受信や外部装置へのデータの送信が可能である。例えば、外部装置としては、外付けHDDやUSBメモリ等の外付け記憶装置や、ネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。
*プラットフォーム部13
CPU121は、間接記憶部123に記憶されたプラットフォームプログラムを直接記憶部122に移動する(記憶させる)ことができる。移動が完了すると、CPU121がプラットフォームプログラムを実行することができる状態になる。
CPU121と、直接記憶部122のうちプラットフォームプログラムを記憶した領域と、CPU121がプラットフォームプログラムを処理して得た情報(計算結果等)を記憶する領域との組み合わせをプラットフォーム部13と称する。後者の領域は直接記憶部122及び間接記憶部123に含まれる。本実施形態では、上記の様に「CPU121がプラットフォームプログラムを実行することができる状態になること」を、プラットフォーム部13が起動すると称する。
*アプリケーションプログラム
プラットフォーム部13は、間接記憶部123に記憶された第一のアプリケーションプログラムを直接記憶部122に移動する(記憶させる)ことができる。移動が完了すると、プラットフォーム部13が第一のアプリケーションプログラムを実行することができる状態になる。本実施形態ではこのことを、プラットフォーム部13が第一のアプリケーションプログラムを起動すると称する。
逆に、プラットフォーム部13は、直接記憶部122に記憶された第一のアプリケーションプログラムを削除することができる。本実施形態ではこのことを、プラットフォーム部13が第一のアプリケーションプログラムを停止すると称する。
プラットフォーム部13は、外部インターフェース125を介して第一のアプリケーションプログラムであるデータを受信し記憶することができる。このときプラットフォーム部13は、第一のアプリケーションプログラムの存在を記憶し、自己の管理下に収める。本実施形態ではこのことを、プラットフォーム部13に第一のアプリケーションプログラムをインストールすると称する。
逆に、プラットフォーム部13は、(プラットフォーム部13の内部にある)間接記憶部123に記憶された第一のアプリケーションプログラムを削除することができる。本実施形態ではこのことを、プラットフォーム部13が第一のアプリケーションプログラムをアンインストールすると呼称する。尚、プラットフォーム部13が第一のアプリケーションプログラムをアンインストールする際に、第一のアプリケーションプログラムが起動している場合には、これを停止した後にアンインストールを行う。
また、以上の説明は第一のアプリケーションプログラムを例に行ったが、他のアプリケーションプログラム(例、第二のアプリケーションプログラム)であっても同様であることは当業者には自明であろう。
*パッケージング装置(アプリケーションパッケージング装置)2
図2は本発明の第1実施形態に係るパッケージング装置の構成を示すブロック図である。
パッケージング装置2は、受信手段21、送信手段22、パッケージライセンス生成手段23、アプリケーションパッケージ生成手段24を備える。パッケージライセンス生成手段23及びアプリケーションパッケージ生成手段24の詳細については後述する。
パッケージング装置2は、CPU、主記憶装置、二次記憶装置、入力装置、出力装置を備えた装置で実現でき、これらを備えた図1の画像処理装置12を含んだ画像形成装置1の他、PCやワークステーション等のコンピュータで実現できる。二次記憶装置にはオペレーティングシステム(OS)や各種プログラムが格納されている。主記憶装置に二次記憶装置から読み込まれたOSや各種プログラムがロードされ、CPUによって実行される。
尚、本明細書においては、上記各種プログラムにパッケージングプログラムが含まれているものとする。そして、このパッケージングプログラムを主記憶にロードした画像形成装置1が、その内容に基づき、上記各手段を備えたパッケージング装置2を実現する。
*アプリケーション3
図3は本発明の第1実施形態に係るアプリケーションの構成を示す構成図である。
アプリケーション3は、非暗号化領域31と暗号化領域32から構成される。また、非暗号化領域31内の特定のディレクトリ(MANIFESTという名称のディレクトリ)には、アプリケーションの情報を設定するファイルである、後述するアプリケーション定義311が格納されている。また、暗号化領域32内の特定のディレクトリ(EULAという名称のディレクトリ)には、後述する使用許諾契約書321及び上述したアプリケーションプログラム322が格納されている。
暗号化領域32は、後述するライセンスが正当な場合のみ復号可能なよう構成されればよく、暗号化方式は問わない。正当なライセンスが、暗号化領域32を復号するための情報(例、鍵)を格納しているということである。
*アプリケーション定義311
図4は本発明の第1実施形態に係るアプリケーション定義の構成を表す。
アプリケーション定義311は、アプリケーションID41、製品バージョン42、アプリケーション名43、インストール可能プラットフォーム44、消費リソースサイズ45で構成される。アプリケーションID41は、アプリケーション3が複数のアプリケーションのうちの、どのアプリケーションであるかを一意に識別するための識別子である。さらに製品バージョン42を組み合わせることで、アプリケーション3のうちの、どのバージョンのアプリケーションであるかを特定することが可能となる。また、アプリケーション名43はアプリケーションの呼称を示す文字列である。
インストール可能プラットフォーム44は、アプリケーション3がインストールすることが出来るプラットフォームプログラムである。インストール可能プラットフォーム44は、例えば、プラットフォームプログラムの種別やバージョン、機器の固有ID、プラットフォームプログラムが有すべき機能を示すID等を示す。
消費リソースサイズ45は、アプリケーション3をインストールする際、もしくはインストールした後で実行する際に必要なリソースサイズが定義されている。例えば間接記憶123の消費サイズや直接記憶122の消費サイズが、リソースサイズとして考えられる。
*ライセンス5
図5は本発明の第1実施形態に係るライセンスの構成を示す構成図である。
ライセンス5は、ライセンスID51、アプリケーションID52、ライセンス情報53で構成される。ライセンスID51はライセンス5を識別するためのユニークなIDである。アプリケーションID52には、ライセンスを設定した対象であるアプリケーション3のアプリケーションID41の情報が格納される。ライセンス情報53には、ライセンス5のライセンスとしての定義(例えばライセンス有効期限やライセンス可能回数)や、アプリケーション3の暗号化領域32を復号するための情報等が格納される。
*アプリケーションパッケージ6
図6は本実施形態に係るアプリケーションパッケージの構成を示す構成図である。
アプリケーションパッケージ6は、アプリケーションパッケージ生成手段24によって生成されたアプリケーションパッケージである。アプリケーションパッケージ6は、複数のアプリケーション611〜613及び対応する複数のアプリケーションの使用許諾契約書621〜623によって構成される。アプリケーションパッケージ生成手段24によるアプリケーションパッケージ6の生成処理については後述する。
*パッケージライセンス7
図7は本実施形態に係るパッケージライセンスの構成を示す構成図である。
パッケージライセンス7はパッケージライセンス生成手段23によって生成される複数のライセンス(71、72、73等)を一つにまとめて得られたパッケージライセンスである。パッケージライセンス7は、複数のライセンス71〜73によって構成される。
*アプリケーションパッケージ6の生成処理
図8のフローチャートを元にアプリケーションパッケージ生成手段24におけるアプリケーションパッケージ6の生成処理(S802〜S809)及びステップS801、S811について説明する。
尚、本実施形態においては、ステップS802〜S809の処理は全て自動で行われ、ユーザからの指示に依らないものとする。即ち、ステップS802の復号処理からステップS809の一つにまとめてアプリケーションパッケージを得る処理までの間にユーザからの指示は受けない。このことは、他の実施形態においても同様である(図14のステップS1402〜S1410における処理が全て自動で行われる)。
アプリケーションパッケージ生成手段24は、パッケージライセンス生成手段23より、パッケージング対象となる複数のアプリケーション3を受信する。併せて、それらのアプリケーション3の夫々に対応する各ライセンス5のパッケージライセンス7を受信する(S801)。
次に、アプリケーションパッケージ生成手段24は、受信した複数のアプリケーション3の夫々を復号する(S802)。
次に、アプリケーションパッケージ生成手段24は、復号済みの複数のアプリケーション3のうちの一つを選択する。そして、当該選択された一つのアプリケーション3が使用許諾契約書321を保有しているかを確認し(S803)、保有している場合はステップS804の処理を行う。使用許諾契約書321は、アプリケーション内で特定のディレクトリ(例えば、EULAという名称のディレクトリ)に格納されているため、保有しているかの確認処理は、アプリケーションパッケージ生成手段24が特定のディレクトリを検索することで実行される。また、使用許諾契約書321のファイル名においても形式が決まっていることが好ましい。
ステップS804においてアプリケーションパッケージ生成手段24は、復号済みアプリケーション3が保有している使用許諾契約書321を複製する。次に、複製した使用許諾契約書321のファイル名に、使用許諾契約書321を一意に特定する識別子としてアプリケーションID41を付与する(S805)。この付与されたアプリケーションID41は、複製元のアプリケーション3を特定するために使用される。また、使用許諾契約書321を、1つのアプリケーション3が複数所持している構成もあり得る(例えば多くの言語に対応している場合)ので、その場合は全ての使用許諾契約書321について複製及びIDの付与(S804及びS805)を実行する。
アプリケーションパッケージ生成手段24は次に、ステップS801で受信した全てのアプリケーション3に対し上記処理を行う(S807)。アプリケーションパッケージ生成手段24は次にステップS809で、ステップS802で復号を行う前の全アプリケーション3と、ステップS804〜S805にて複製、ID付与が行われた複数の使用許諾契約書321とを一つにまとめる。これにより、アプリケーションパッケージ6が得られる。
最後にステップS811において、アプリケーションパッケージ生成手段24は、生成したアプリケーションパッケージ6とパッケージライセンス7を送信手段22に送信する。
尚、ステップS802及びS809で、アプリケーションパッケージ生成手段24は、暗号化されている各アプリケーションの中に含まれていた使用許諾契約書を、当該各アプリケーションの外に出す。そして、外に出した使用許諾契約書と、各アプリケーションとを含むアプリケーションパッケージ6を得るということが行われる。
換言すると、ステップS802とS809で、暗号化されている各アプリケーションの中に含まれていた使用許諾契約書を復号前の複数のアプリケーションとは別の領域に含むアプリケーションパッケージを、アプリケーションパッケージ生成手段24が生成する。
*インストール管理テーブル900
図9はインストール管理テーブル900の構成を表す。
インストール管理テーブル900は、後述するプラットフォーム部13におけるインストール処理の際に使われるテーブルであり、インストール処理終了後は破棄される。インストール管理テーブル900は、アプリケーションID901、製品バージョン902、アプリケーション名903を構成として含む。これらは各アプリケーション3のアプリケーション定義311を元に設定される。インストール管理テーブル900は、さらに、インストール条件確認結果904、使用許諾同意結果905を構成として含む。これらの詳細については後述する。インストール管理テーブル900は、さらに、アプリケーション906とライセンス907を構成として含む。これらは各アプリケーション3と対応するライセンス5への参照である。
*アプリケーションパッケージ6のインストール処理
図10のフローチャートを元にプラットフォーム部13におけるアプリケーションパッケージ6のインストール処理について説明する。
尚、本明細書の以下の記述において、インストール処理とは、アプリケーションプログラムのインストールと、そのインストールに伴う処理を含む処理を言う。本実施形態においては、ステップS1031を除いた処理がアプリケーションプログラムのインストール処理であり、そのうちのステップS1014がアプリケーションプログラムのインストールである。即ち、アプリケーションプログラムのインストール処理が行われる中で、アプリケーションプログラムのインストールが行われる。
プラットフォーム部13は、外部インターフェース125からアプリケーションパッケージ6及びパッケージライセンス7を取得する(S1001)。換言すると、外部インターフェース125を介してアプリケーションパッケージ6及びパッケージライセンス7を受信する。この時に同時に、外部インターフェース125を介して接続される装置を使用するユーザから、アプリケーションパッケージ6をインストール処理して欲しい旨の指示が送信されてくる。
次に、プラットフォーム部13はステップS1002において以下の処理を行う。取得したアプリケーションパッケージ6に含まれる全てのアプリケーション3から、夫々のアプリケーション定義311を取得する。取得したパッケージライセンス7から各アプリケーションに対応するライセンス5を取得する。そして、取得した夫々のアプリケーション3、アプリケーション定義311、ライセンス5の情報を元にインストール管理テーブル900を作成する。具体的には、インストール管理テーブル900のインストール条件確認結果904、使用許諾同意結果905以外の情報(アプリケーション定義311、ライセンス5の情報)を格納したインストール管理テーブル900を作成する。
次に、プラットフォーム部13は、作成したインストール管理テーブル900の登録順に以下の処理を行う。
まずプラットフォーム部13は、対象となるアプリケーションの非暗号化領域31からアプリケーション定義311を、取得したライセンス5からライセンス情報53を取得する(S1003)。次に、取得したアプリケーション定義311、ライセンス情報53の情報を元に、ライセンス確認及び後述するインストール条件の確認処理を行う(S1004,S1017)。その結果、インストール可能であった場合は、インストール管理テーブル900のインストール条件確認結果904を、インストール可能を示す情報で更新する(S1005)。一方、インストール不可能であった場合は、外部インターフェース125へインストール出来ない旨を通知し、外部I/F125を介したユーザからの指示を要求する(S1018)。
その後、外部インターフェース125を介したユーザからの指示を確認(インストール処理を継続するかを確認)する(S1019)。そして、継続する場合(継続する指示であると確認した場合)はインストール管理テーブル900のインストール条件確認結果904を、インストール不可を示す情報で更新する(S1005)。また、継続しない場合(継続しない指示であると確認した場合)はインストール処理を中断する(S1031)。
そして、プラットフォーム部13は、インストール管理テーブル900に登録されているアプリケーション3の個数分、上記処理(S1003〜S1005,S1017〜S1019)を繰り返す(S1006)。
次に、プラットフォーム部13は、作成したインストール管理テーブル900に登録されているアプリケーションのうち、インストール条件確認結果904がインストール可能を示す情報となったアプリケーションのみを対象として以下の処理を行う。
プラットフォーム部13はアプリケーションパッケージ6が、対象のアプリケーション3の使用許諾契約書321の複製を対象のアプリケーション3の外に保持しているかを確認し、保持している場合は取得する(S1007,S1008)。保持していない場合はインストール管理テーブル900の使用許諾同意結果905を、関係しないことを示す情報で更新する(S1010)。保持している場合は、取得した使用許諾契約書321を外部インターフェース125へ通知する(S1026)。
そして、通知した使用許諾契約書321に対して同意であるか、もしくは同意しない旨を、外部インターフェース125を介してユーザから受信する(S1018)。その結果、同意の場合は、インストール管理テーブル900の使用許諾同意結果905を、同意を示す情報で更新する(S1010)。即ち、外部インターフェース125を介して、当該取得した使用許諾契約書に対する同意をユーザから取り付けた場合に、使用許諾同意結果905を、同意を示す情報で更新する。この更新により、ステップS1012、S1013を経て、対象とするアプリケーションがインストールされることになる。
一方、ステップS1027において使用許諾契約書321に同意しない場合は、インストール処理をこのまま継続するかを外部インターフェース125を介してユーザに確認する(S1028、S1029)。そして、継続する場合はインストール管理テーブル900の使用許諾同意結果905を、同意しないことを示す情報で更新する(S1010)。一方、継続しない場合はインストール処理を中断する(S1031)。
そして、プラットフォーム部13は、インストール管理テーブル900に登録されているアプリケーションのうち、「インストール条件確認結果904がインストール可能を示す情報となっているアプリケーション。」のみを対象に、その個数分、上記処理(S1007〜S1008,S1026〜S1029,S1010)を繰り返す(S1011)。最後に、プラットフォーム部13は、インストール管理テーブル900に登録されているアプリケーションのうち、「インストール条件確認結果904がインストール可能を示す。」であって、かつ、「条件確認結果904が関係しないか、もしくは同意」であるアプリケーションを取得する(S1012)。取得したアプリケーションに対して以下の処理を行う。
まず、プラットフォーム部13は、暗号化されているアプリケーションを復号する(S1013)。次に、アプリケーション3に含まれるアプリケーションプログラム322をインストールする(S1014)。対象の全てのアプリケーション3のアプリケーションプログラム322のインストールを実行するまで処理を繰り返し(S1015)、インストール処理を終了する。
以下では、ステップS1014における処理(アプリケーションプログラムのインストール)を詳細に記述する。
まず、「S1010で使用許諾同意結果が同意を示す情報に更新されたアプリケーション」に含まれるアプリケーションプログラムをインストールする。また、「S1010で使用許諾同意結果が同意を示す情報に更新されていないアプリケーション」に含まれるアプリケーションプログラムはインストールしない。
加えて、ステップS1013での複数のアプリケーションの復号により得られた夫々の使用許諾同意書については、ステップS1014では無視する。使用許諾契約については、使用許諾契約書の複製を用いてステップS1010、S1011で確認済だからである。
*インストール条件確認方法
プラットフォーム部13のインストール処理のうち、インストール条件確認の方法について説明する。
プラットフォーム部13は、アプリケーション定義311にて定義されている情報と機器の情報(プラットフォーム部13、画像処理装置12)を付き合わせて比較することでインストール条件を確認する。特に、アプリケーション定義311にて定義されている情報のうち、インストール可能プラットフォーム44及び消費リソースサイズ45の情報を用いる。
例えば、プラットフォームプログラムのバージョンが2であって、画像処理装置12の間接記憶部123の残りサイズが100MBの場合は、以下の様に判断される。
プラットフォーム部13は、対象のアプリケーション3のインストール可能プラットフォーム44のプラットフォームプログラムのバージョンが1の場合、インストール出来ないと判断する。即ち、アプリケーションがインストール可能なプラットフォームのバージョンをプラットフォームプログラムが備えているか否かで、インストール可否を判断する。
また、プラットフォーム部13は、対象のアプリケーション3の消費リソースサイズ45の間接記憶123の消費サイズが120MBの場合、インストール出来ないと判断する。つまり、アプリケーションが消費するリソースを機器が残りリソースとして備えているか否かで、インストール可否を判断する。
一方、、固有IDが“#####0000000000”であって、備える機能の固有IDが“印刷機能のバージョン1、かつ、ユーザインターフェース124のディスプレイサイズはSVGA”であることを示す場合は、以下の様に判断される。
プラットフォーム部13は、対象のアプリケーション3のインストール可能プラットフォーム44の機器の固有IDが“#####0000000001”の場合、インストール出来ないと判断する。つまり、アプリケーションがインストール可能な機器の固有IDを機器が保持しているか否かで、インストール可否を判断する。
また、プラットフォーム部13は、対象のアプリケーション3のインストール可能プラットフォーム44の機能の固有IDが“印刷機能のバージョン2”を示す場合、インストール出来ないと判断する。つまり、アプリケーションがインストール可能な機器の機能を機器が備えているか否かで、インストール可否を判断する。
本実施形態ではアプリケーションパッケージ6は暗号化されていないとして説明している。しかし、アプリケーションパッケージ内に、アプリケーション3のように暗号化領域を設け、複製により得られた複数の使用許諾契約書(621〜623)や、既に暗号化されている複数のアプリケーション(611〜613)を格納するよう構成しても良い。この場合、ステップS809とS811の間に、複製した使用許諾契約書をアプリケーション生成手段が暗号化する処理が行われる。同様に、既に暗号化されている複数のアプリケーションも、ステップS809とS811の間でアプリケーション生成手段により暗号化される。つまり、アプリケーションは二重に暗号化される。このように、二重に暗号化されたアプリケーション及び暗号化された複製の使用許諾契約書を暗号化領域に格納することにより、使用許諾契約書の改竄をも防ぐことができる。
尚、ステップS809とS811の間で暗号化される場合は、ステップS801で取得したパッケージライセンスに、復号するための情報(例、鍵)を格納することになる。
このように、本実施形態によればアプリケーションパッケージのインストール時に、全てのアプリケーションに対するインストール条件の確認やライセンスの確認、及び使用許諾契約への同意等の作業を、インストール処理の最初にまとめて行うことができる。したがって、インストール処理中に使用許諾契約書への同意やインストール処理の継続等の指示の入力作業を行う必要が生じてインストール処理が煩雑になることが防止される。
(第2実施形態)
本実施形態において第1実施形態と同一の構成及び構成要素には同一の符号を用い、それらの説明は適宜省略し、異なる点を詳しく説明する。
まず、第1実施形態におけるアプリケーションパッケージにはアプリケーションパッケージ定義が含まれていなかった(図6)のに対し、本実施形態におけるアプリケーションパッケージにはアプリケーションパッケージ定義(図11)が含まれる。これにより、本実施形態では、複数のアプリケーション定義を夫々確認すること(S1017の判断処理)なくアプリケーションパッケージ定義のみを確認(S1517の判断処理)すればよい。
また、本実施形態においては、アプリケーションパッケージ定義を含むアプリケーションパッケージを作成するにあたって、アプリケーション定義中の情報の種類に応じた各種演算を行っている。このような演算は、アプリケーションパッケージ定義を作らない第1実施形態では行っていない。
*アプリケーションパッケージ1100
図11は本実施形態に係るアプリケーションパッケージの構成を示す構成図である。
アプリケーションパッケージ1100は、後述のアプリケーションパッケージ生成手段24によって生成されるアプリケーションパッケージである。アプリケーションパッケージ1100は、非暗号化領域1101と暗号化領域1102から構成される。また非暗号化領域1101内の特定のディレクトリ(MANIFESTという名称のディレクトリ)には、後述するアプリケーションパッケージ定義1103に格納されている。また、暗号化領域1102には、複数のアプリケーション1111〜1113及び対応する複数の使用許諾契約書1121〜1123が格納されている。
暗号化領域1102は、後述するパッケージライセンスが正当な場合のみ復号可能なよう構成されるべきであり、暗号化方式は問わない。正当なパッケージライセンスが、暗号化領域を復号するための情報(例、鍵)を格納しているということである。
*アプリケーションパッケージ定義1103
図12は本実施形態に係るアプリケーションパッケージ定義の構成を表す。
アプリケーションパッケージ定義1103は、アプリケーションパッケージID1201、製品バージョン1202、アプリケーションパッケージ名1203、インストール可能プラットフォーム1204、消費リソースサイズ1205で構成される。そして、アプリケーションパッケージ1100が含む全てのアプリケーションの夫々のアプリケーション定義311を、アプリケーション定義1206〜1208として含む。
アプリケーションパッケージID1201は、アプリケーションパッケージ1100が複数のアプリケーションパッケージのうちの、どのアプリケーションパッケージであるかを一意に識別するための識別子である。さらに製品バージョン1202を組み合わせることで、アプリケーションパッケージ1100のうちの、どのバージョンのアプリケーションパッケージであるかを特定することが可能となる。また、アプリケーションパッケージ名1203はアプリケーションパッケージの呼称を示す文字列である。
インストール可能プラットフォーム1204は、アプリケーションパッケージ1100に含まれる全てのアプリケーション3がインストール出来るプラットフォームプログラムを示す。インストール可能プラットフォーム1204は、例えば、プラットフォームプログラムの種別やバージョン、機器の固有ID、プラットフォームプログラムが有すべき機能を示すID等を示す。消費リソースサイズ1205には、アプリケーションパッケージ1100に含まれる全てのアプリケーションをインストールする際、もしくはインストールした後で実行する際に必要なリソースサイズが定義されている。例えば間接記憶123の消費サイズや直接記憶122の消費サイズが、リソースサイズとして考えられる。
*パッケージライセンス1300
図13は本実施形態に係るパッケージライセンスの構成を示す構成図である。
パッケージライセンス1300は、パッケージライセンス生成手段23によって生成される複数のライセンス5(1304、1305、1306等)を一つにまとめて得られたたパッケージライセンスである。パッケージライセンス1300は、パッケージライセンスID1301、アプリケーションパッケージID1302、パッケージライセンス情報1303、及び複数のライセンス1304〜1306によって構成される。
パッケージライセンスID1301は、パッケージライセンス1300を識別するためのユニークなIDである。アプリケーションパッケージID1302には、ライセンスを設定した対象であるアプリケーションパッケージ1100のアプリケーションパッケージID1201の情報が格納される。パッケージライセンス情報1303には、パッケージライセンス1300のパッケージライセンスとしての定義や、アプリケーションパッケージ1100の暗号化領域1102を復号するための情報等が格納される。このパッケージライセンスとしての定義には、例えば、パッケージライセンス有効期限やライセンス可能回数が含まれる。
*アプリケーションパッケージ1100の生成処理
図14のフローチャートを元にアプリケーションパッケージ生成手段24におけるアプリケーションパッケージ1100の生成処理(S1402〜S1410)及びステップS1401,S1411について説明する。
アプリケーションパッケージ生成手段24はパッケージライセンス生成手段23より、パッケージング対象の複数のアプリケーション3と、それらアプリケーション3の夫々に対応する各ライセンス5のパッケージライセンス1300を受信する(S1401)。続くステップS1402〜S1405においては、図8に示したステップS802〜S805における処理と同様の処理を行う。
ステップS1405に続いてアプリケーションパッケージ生成手段24は、アプリケーションが保有しているアプリケーション定義311を取得する(S1406)。
そして、アプリケーションパッケージ生成手段24は、ステップS1401で受信した全てのアプリケーション3に対してステップS1402〜S1406の処理を行う(S1407)。その後に、後述する取得した全てのアプリケーション定義311からアプリケーションパッケージ定義1103を作成する(S1408)。
次に、アプリケーションパッケージ生成手段24は、ステップS1409の処理を行う。即ち、ステップS1402で復号する前の全アプリケーション3とステップS1404、ステップS1405にて複製、ID付与が行われた使用許諾契約書321、及び、ステップS1408で作成したアプリケーションパッケージ定義1103を一つにまとめる。これにより、アプリケーションパッケージ1100が得られる。
次に、アプリケーションパッケージ生成手段24は、得られたアプリケーションパッケージ1100を暗号化する(S1410)。
最後に、アプリケーションパッケージ生成手段24は、生成したアプリケーションパッケージ1100とパッケージライセンス1300を送信手段22に送信する(S1411)。
尚、ステップS1402及びS1409で、アプリケーションパッケージ生成手段24は、暗号化されている各アプリケーションの中に含まれていた使用許諾契約書を、当該各アプリケーションの外に出す。
また、ステップS1406とS1408とS1409とで、アプリケーションパッケージ生成手段24は、夫々のアプリケーション毎に含まれていたアプリケーション定義を合算し、一つのアプリケーションパッケージ定義を生成する。
そして、その外に出した使用許諾契約書と、生成した一つのアプリケーションパッケージ定義と、各アプリケーションとを含むアプリケーションパッケージ1100が得られる。
つまり、ステップS1402及びS1409で、暗号化されている各アプリケーションの中に含まれていた使用許諾契約書を復号前の複数のアプリケーションとは別の領域に含むアプリケーションパッケージを、アプリケーションパッケージ生成手段24が生成する。
さらに、ステップS1406とS1408とS1409とで、アプリケーションパッケージ定義を複数のアプリケーションとは別の領域に含むアプリケーションパッケージを、アプリケーションパッケージ生成手段24が生成する。尚、上述した様に、アプリケーションパッケージ定義とは、夫々のアプリケーション毎に定義されていたアプリケーション定義を合算したものである。
本明細書において上記「合算する」とは、アプリケーション定義内の情報の種類に応じて各種論理/算術演算を行ってアプリケーションパッケージ内の全アプリケーションのインストールに必要なアプリケーションパッケージ定義の各構成要素を決定することを言う。上記「合算する」は、同時提出の特許請求の範囲においても同様の意味で用いられる。
本実施形態では、複製した使用許諾契約書321の保有元であるアプリケーション3を特定するために、使用許諾契約書321のファイル名にアプリケーション3のアプリケーションID41を付与する方法を説明した。しかし、使用許諾契約書321の複製元のアプリケーション3が特定されるのであれば方法は問わない。例えば、アプリケーション3と使用許諾契約書321の複製を対応付ける表を作成し、アプリケーションパッケージ1100内のアプリケーションパッケージ定義1103に格納する方法も考えられる。
*アプリケーションパッケージ定義1103作成方法
アプリケーションパッケージ生成手段24は、アプリケーション定義311にて定義されている情報を夫々合算することで、アプリケーションパッケージ定義1103を作成する。特にアプリケーション定義311にて定義されている情報のうち、インストール可能プラットフォーム44及び消費リソースサイズ45の情報に関して夫々合算する。
例えば、一つのアプリケーションのアプリケーション定義311が以下の様な場合を考える。インストール可能なプラットフォームプログラムのバージョンが2である。消費する間接記憶部123のサイズが100MBである。インストール可能な機器の固有IDが“#####0000000000,####0000000001”である。必要な機能の固有IDは“印刷機能のバージョンが2、かつ、ユーザインターフェース124のディスプレイサイズがSVGAもしくはVGA”である。尚、“#####0000000000,####0000000001”という表記は、“#####0000000000、または、####0000000001”であることを示す。
さらに、もう一つのアプリケーションのアプリケーション定義311が以下の様な場合を考える。インストール可能なプラットフォームプログラムのバージョンが1もしくは2である。消費する間接記憶部123のサイズが120MBである。インストール可能な機器の固有IDが“#####0000000000”である。必要な機能の固有IDは“印刷機能のバージョンが1”である。
アプリケーション定義311が上記の様な場合は、以下の様にして各構成要素を決定し、アプリケーションパッケージ定義1103が作成される。すなわち、アプリケーション定義内の情報の種類に応じてどのような演算を用いるかを決定し、決定した演算を行う。
具体的には、バージョンの場合には論理積演算を用いてアンドをとると決定する。インストール可能な間接記憶部123のサイズの場合には算術和を用いて総和を求めると決定する。インストール可能な機器の固有IDの場合には論理積演算を用いると決定する。インストールするために必要な機能の固有IDの場合には論理和演算を用いると決定する。
アプリケーションパッケージに含まれる全てのアプリケーションがインストール可能なプラットフォームプログラムのバージョンは、論理積演算によりバージョン2が得られる。
アプリケーションパッケージに含まれる全てのアプリケーションがインストール可能な間接記憶部123のサイズは220MB以上である。これは数値の算術和(総和)によって得られる。つまり、120MB+100MB=220MBより得られる。
そして、アプリケーションパッケージに含まれる全てのアプリケーションがインストール可能な機器の固有IDは“#####0000000000”である。これも論理積によって得られる。即ち、“#####0000000000”と、“#####0000000000,####0000000001”との論理積演算によりアンドをとり“#####0000000000”が得られる。
そして、アプリケーションパッケージに含まれる全てのアプリケーションがインストールするために必要な機能の固有IDは“印刷機能のバージョンが2、かつ、ユーザインターフェース124のディスプレイサイズがSVGAもしくはVGA”となる。これは論理和演算(オア)によって得られる。
このように、アプリケーションパッケージ生成手段24は、アプリケーション定義311にて定義されている情報の夫々を、その情報の種類に応じて異なった算術演算または論理演算により合算することでアプリケーションパッケージ定義1103を作成する。
*アプリケーションパッケージ1100のインストール処理
図15のフローチャートを元にプラットフォーム部13におけるアプリケーションパッケージ1100のインストール処理について説明する。
本実施形態においては、ステップS1531を除いた処理がアプリケーションパッケージのインストール処理であり、そのうちのステップS1513がアプリケーションプログラムのインストールである。即ち、アプリケーションパッケージのインストール処理が行われる中で、アプリケーションプログラムのインストールが行われる。
プラットフォーム部13は、外部インターフェース125からインストール対象となるアプリケーションパッケージ1100及びパッケージライセンス1300を取得する(S1501)。
次に、プラットフォーム部13はステップS1502において以下の処理を行う。取得したアプリケーションパッケージ1100に含まれるアプリケーションパッケージ定義1103と、パッケージライセンス1300に含まれるパッケージライセンス情報1303とを取得する。そして、取得したアプリケーションパッケージ定義1103及びパッケージライセンス情報1303の情報を元にインストール管理テーブル900を作成する。具体的には、インストール管理テーブル900のインストール条件確認結果904、使用許諾同意結果905以外の情報(アプリケーション定義311、ライセンス5の情報)を格納したインストール管理テーブル900を作成する。
次に、プラットフォーム部13は、アプリケーションパッケージ定義1103及びパッケージライセンス情報1303の情報を元に後述するパッケージライセンス及びパッケージインストール条件確認を行う(S1503,S1517)。そしてライセンス及びインストール条件の確認の結果、全てインストール可能であった場合、同テーブル900の全てのアプリケーションに対するインストール条件確認結果904を、インストール可能を示す情報で更新する(S1504)。また、インストール条件確認の結果が一つでもインストール不可の場合は、外部インターフェース125へインストール出来ない旨を通知し、外部I/F125を介したユーザからの指示を要求する(S1518)。
その後、外部インターフェース125を介したユーザからの指示を確認(インストール処理をこのまま継続するかを確認)する(S1519)。その結果、継続する場合はインストール管理テーブル900のうちインストール不可のアプリケーションに対するインストール条件確認結果904を、インストール不可を示す情報で更新する(S1504)。もちろん、インストール条件確認の結果がインストール可能であったアプリケーションがあった場合、そのアプリケーションに対するインストール条件確認結果904を、インストール可能を示す情報で更新する(S1504)。また、継続しない場合はインストール処理を中断する(S1531)。
インストール条件確認結果904の更新に続き、プラットフォーム部13は、アプリケーションパッケージを復号する(S1505)。
次に、プラットフォーム部13は、作成したインストール管理テーブル900に登録されているアプリケーションのうち、インストール条件確認結果904がインストール可能を示す情報となったアプリケーションのみを対象として以下の処理を行う。
プラットフォーム部13は、アプリケーションパッケージ1100が、対象のアプリケーション3の使用許諾契約書321の複製を対象のアプリケーション3の外に保持しているかを確認する(S1506,S1507)。
上記確認結果に応じて、図10に示したステップS1026以降の処理と同様のステップS1526以降の処理、または、ステップS1010以降の処理と同様のステップS1509以降の処理を行う。後者の処理が含むステップS1513におけるアプリケーションプログラムのインストールは、図10に示したステップS1014のアプリケーションプログラムのインストールと同様に行われる。
*パッケージインストール条件確認方法
プラットフォーム部13のインストール処理のうち、パッケージインストール条件確認の方法について説明する。
プラットフォーム部13は、アプリケーションパッケージ定義1103の情報とプラットフォーム部13、画像処理装置12の情報を比較することでインストール条件を確認する。特にアプリケーションパッケージ定義1103にて定義されている情報のうち、インストール可能プラットフォーム1204、及び消費リソースサイズ1205を用いる。
例えば、プラットフォームプログラムのバージョンが2であって、画像処理装置12の間接記憶部123の残りサイズが100MBの場合は、以下の様に判断される。さらに、固有IDが“#####0000000000”であって、備える機能の固有IDが“印刷機能のバージョン1かつスキャン機能はバージョン1もしくはバージョン2”を示す場合も同様に以下の様に判断される。
プラットフォーム部13は、アプリケーションパッケージ1100のインストール可能なプラットフォームプログラムのバージョンが1の場合、アプリケーションパッケージ1100に含まれるアプリケーションの全てはインストール出来ないと判断する。つまり、アプリケーションがインストール可能なプラットフォームのバージョンを、プラットフォームプログラムが備えているか否かで、インストール可否を判断する。
また、プラットフォーム部13は、対象のアプリケーションパッケージ1100の間接記憶123の消費サイズが120MBの場合、アプリケーションパッケージ1100に含まれるアプリケーション3の全てはインストール出来ないと判断する。つまり、アプリケーションが消費するリソースを機器が残りリソースとして備えているか否かで、インストール可否を判断する。
また、プラットフォーム部13は、対象のアプリケーションパッケージ1100の機器の固有IDが“#####0000000001”の場合は、アプリケーションパッケージ1100に含まれるアプリケーション3の全てはインストール出来ないと判断する。つまり、アプリケーションがインストール可能な機器の固有IDを機器が保持しているか否かで、インストール可否を判断する。
また、同部13は、対象のアプリケーションパッケージ1100の機能の固有IDが“印刷機能のバージョン2”を示す場合に、アプリケーションパッケージ1100に含まれるアプリケーション3の全てをインストールすることは出来ないと判断する。つまり、アプリケーションがインストール可能な機器の機能を機器が備えているか否かで、インストール可否を判断する。
また、プラットフォーム部13はアプリケーションパッケージ1100に含まれるアプリケーション3の全てをインストールすることが出来ないと判断した場合は、続けて以下の判断を行う。即ち、アプリケーションパッケージ1100に含まれる各アプリケーションについて、アプリケーションパッケージ定義1103に含まれる個別アプリケーション定義311を用いて個別にインストール可否を判断する。
このように、プラットフォーム部13はアプリケーションパッケージ定義1103にて定義されている情報と機器の情報を付き合わせることによってインストール可能であるか否かを判断する。
このように、本実施形態によればアプリケーションパッケージのインストール処理時に、全アプリケーションに対するインストール条件の確認やライセンスの確認及び使用許諾契約への同意等の作業を、インストール処理の最初に纏めて行うことが可能となる。さらに、アプリケーションパッケージ定義、パッケージライセンス情報を生成することにより、インストール条件の確認やライセンスの確認処理のパフォーマンスを向上することが出来る。これにより、インストール処理中に使用許諾契約書への同意やインストール処理の継続等の入力作業を行う必要が生じてインストール処理が煩雑になることを防止でき、インストール処理のパフォーマンスを向上することができる。
また、上述した第1及び第2実施形態によれば、暗号化された複数のアプリケーションの中に夫々存在する使用許諾契約書を、それらのアプリケーションの外に出している。このため、暗号化された複数のアプリケーションの復号化を待たずに使用許諾契約書の同意をユーザから取り付けることができる。即ち、インストール処理の前半にて使用許諾契約書の同意をユーザから取り付けることができ、インストール処理をスムーズに行える。
これにより、暗号化された複数のアプリケーションを含むアプリケーションパッケージのインストール処理中に何度も使用許諾契約書への同意の要求が発生する煩雑さを解消できる。また、インストール処理の中盤以降に上記要求が発生することもないので、ユーザは面倒な同意入力のためのオペレーションをするために、インストール処理を開始してから終了するまで待っている必要がなくなり、インストール処理を簡単に行える。
(第3実施形態)
以下の2つの実施形態は、上記各実施形態におけるインストールが特殊なインストール(再インストール)であった場合である。本実施形態において第1実施形態と同一の構成及び構成要素には同一の符号を用い、それらの説明は適宜省略し、異なる点を詳しく説明する。以下の説明の理解のために、これより参照する図16以降の図に加えて、図1を含む既出の図面を併せて参照すべきである。
*アプリケーション1603
図16は本発明の第3実施形態に係るアプリケーションの構成を示すブロック図である。
アプリケーション1603内にある、特定のディレクトリ(MANIFESTという名称のディレクトリ)には、後述するアプリケーション定義1611が格納されている。また、アプリケーション1603内の別の特定のディレクトリ(EULAという名称のディレクトリ)には、後述する使用許諾契約書1621及び上述したアプリケーションプログラム1622が格納されている。
*アプリケーション定義1611
図17は本発明の第3実施形態に係るアプリケーション定義の構成を表す。
アプリケーション定義1611は、図4に示した要素41〜45と同様の要素1741〜1745、インストールパス1746、データ保存パス1747を含む。インストールパス1746は、アプリケーション1603をインストールする際の、インストールパス(場所)情報が定義されている。データ保存パス1747は、アプリケーション1603が、インストールされた後に使用するデータの保存パス(場所)情報が定義されている。
*アプリケーションパッケージ1800
図18は本実施形態に係るアプリケーションパッケージの構成を示すブロック図である。
アプリケーションパッケージ1800内の特定のディレクトリ(MANIFESTという名称のディレクトリ)には、後述するアプリケーションパッケージ定義1803が格納されている。また、アプリケーションパッケージ1800には、複数のアプリケーション1811〜1813及び対応する複数のアプリケーションの使用許諾契約書1821〜1823が格納されている。本発明においては、プラットフォーム部13におけるアプリケーションのインストールは、アプリケーションパッケージ1800の単位で行われるものとする。アプリケーションパッケージのインストールに伴い、後述するアプリケーションパッケージ定義1803もインストール時にプラットフォーム部13に保存されている。
*アプリケーション移動パッケージ500
図19は本発明の第3実施形態に係るアプリケーション移動パッケージの構成を示すブロック図である。
アプリケーション移動パッケージ1900内にある、特定のディレクトリ(MANIFESTという名称のディレクトリ)には、後述するアプリケーションパッケージ定義1803が格納されている。また、アプリケーション移動パッケージ1900には、複数のアプリケーション1811〜1813及び対応する複数のアプリケーションの使用許諾契約書1821〜1823、及び対応する複数のアプリケーション移動データ1901〜1903が格納されている。アプリケーション移動データに関しては、後述する。
*アプリケーションパッケージ定義1803
図20は本実施形態に係るアプリケーションパッケージ定義の構成を表す。
アプリケーションパッケージ定義1803は、図12に示したアプリケーションパッケージ定義1103と図示の上では同様に構成される。以下、相違点を説明する。
アプリケーションパッケージ定義1803は、アプリケーションパッケージ1800及びアプリケーション移動パッケージ1900が含む全てのアプリケーションの夫々のアプリケーション定義1611を、アプリケーション定義2006〜2008として含む。
インストール可能プラットフォーム2004は、アプリケーションパッケージ1800及びアプリケーション移動パッケージ1900に含まれる全てのアプリケーション1603がインストール出来るプラットフォームプログラムを示す。消費リソースサイズ2005は、アプリケーションパッケージ1800及びアプリケーション移動パッケージ1900に含まれる全アプリケーション1603をインストールする際、もしくはインストールした後で実行する際に必要なリソースサイズが定義されている。
*アプリケーション移動データ
図21は本実施形態に係るアプリケーション移動データの構成を示すブロック図である。
アプリケーション移動データ2100は、アプリケーションのConfig2101、アプリケーションのPreference2102、アプリケーションのユーザデータ2103で構成される。アプリケーション移動データ2100は、前述したアプリケーション移動データ1901〜1903に対応する。
アプリケーションのConfig2101は、アプリケーション1603の単位で持つ設定情報を指す。アプリケーションのPreference2102は、アプリケーション1603それぞれにおいて、ユーザの単位で持つ設定情報を指す。アプリケーションのユーザデータ2103は、アプリケーション1603それぞれが生成し、保存したデータ(例えばアプリケーション1603によって保存された文書ファイル)を指す。
*インストール管理テーブル
図22は本実施形態に係るインストール管理テーブル2200の構成を表す。
後述するプラットフォーム部13におけるインストール処理の際に使われるインストール管理テーブル2200は、図9に示したインストール管理テーブル900が含む要素901〜905と同様の要素2201〜2205を含む。インストール管理テーブル2200は、さらに、アプリケーション2206を構成として含む。これらは各アプリケーション1603への参照である。
*アプリケーションパッケージ移動指示UI
図23は本発明の第3実施形態に係るアプリケーションパッケージの移動指示を行うUIの例を表す。
アプリケーションパッケージ選択領域2301、実行ボタン2302で構成されるアプリケーションパッケージ移動指示UI2300がユーザI/F124のディスプレイに表示され、ユーザからの指示を受け付ける。
アプリケーションパッケージ選択領域2301には、プラットフォーム部13にインストールされているアプリケーションパッケージの一覧2311〜2313が表示される。アプリケーションパッケージ選択領域2301では、ユーザによる、移動したいアプリケーションパッケージを一つ選択可能となる。
実行ボタン2302は、アプリケーションパッケージ選択領域2301で選択されたアプリケーションパッケージの、アプリケーション移動パッケージ1900の生成指示をプラットフォーム部13に対して行う。実行ボタン2302がユーザによって指示されると、プラットフォーム部13は、当該アプリケーションパッケージに対応するアプリケーション移動パッケージ1900の生成処理を開始する。この処理に関しては後述する。
*アプリケーション移動パッケージ生成処理
図24のフローチャートを元にプラットフォーム部13におけるアプリケーション移動パッケージ1900の生成処理(再パッケージ化)について説明する。
この処理は、アプリケーションパッケージ移動指示UI2300において、ユーザによるアプリケーション移動パッケージ生成指示(実行ボタン2302の指示)をプラットフォーム部13がユーザI/F124のディスプレイ経由で受信し、開始する。
プラットフォーム部13は、アプリケーション移動パッケージ生成指示を受信し、対応するアプリケーションパッケージIDを持つアプリケーションパッケージ定義1803を取得し、読み出す(S2401)。
同部13は、ステップS2401で読み出したアプリケーションパッケージ定義1803に含まれるアプリケーション定義1611への参照情報(アプリケーションID)を読み出し、対応するアプリケーション定義1611を読み出す(S2402)。
プラットフォーム部13は、ステップS2402で読み出したアプリケーション定義1611のインストールパス1746に書かれている場所から、アプリケーションプログラム1622、使用許諾契約書1621をコピーする。コピーしたアプリケーションプログラム1622、使用許諾契約書1621、及び、ステップS2402で読み出したアプリケーション定義1611は、アプリケーション1603として図16で説明した通りのディレクトリに格納する。さらに、プラットフォーム部13は、使用許諾契約書1621をコピーしておく(S2403)。上記処理が、アプリケーション1603の再構成である。
同部13は、ステップS2402で読み出したアプリケーション定義のインストールパス1746に書かれている場所に、該当するアプリケーション1603に対応する、アプリケーション単位の設定情報が格納されているかどうかを判定する(S2404)。該判定結果がYesの場合は、プラットフォーム部13は、該当するアプリケーション1603のアプリケーション単位の設定情報をアプリケーションのConfig2101としてコピー抽出し(S2405)、ステップS2413に進む。該判定結果がNoの場合は、処理は行わずにステップS2413に進む。
プラットフォーム部13は、上記の場所に、該当するアプリケーション1603に対応するユーザ単位の設定情報が格納されているかどうか判定する(S2407)。該判定結果がYesの場合は、プラットフォーム部13は、該当アプリケーション1603のユーザ単位の設定情報(ユーザ設定情報)をアプリケーションのPreference2102としてコピーし(S2408)、ステップS2413に進む。該判定結果がNoの場合は、処理は行わずにステップS2413に進む。
プラットフォーム部13は、ステップS2402で読み出したアプリケーション定義1611のデータ保存パス1747に書かれている場所に、該当するアプリケーション1603が生成し、保存したデータが格納されているかどうかを判定する(S2410)。該判定結果がYesの場合は、プラットフォーム部13は、該当するアプリケーション1603が生成し、保存したデータをアプリケーションのユーザデータ2103としてコピーし(S2411)、ステップS2413に進む。該判定結果がNoの場合は、処理は行わずにステップS2413に進む。
ステップS2413では、ステップS2405、S2408,S2411でコピーしたアプリケーションのConfig2101、Preference2102、及び、ユーザデータ2103が、アプリケーション移動データ2100として保存される。コピーをアプリケーションプログラムに関連付けるこの処理は、プラットフォーム部13が行う。ステップS2413では、プラットフォーム部13は、アプリケーション移動データ2100を、当該アプリケーション1603との対応を保持するために、アプリケーションIDを付加して命名する。
プラットフォーム部13は、ステップS2401で読み出したアプリケーションパッケージ定義1803に含まれるアプリケーション定義への参照情報に対応するアプリケーション定義1611を全て確認したかどうかを判定する(S2414)。該判定結果がNoの場合は、未確認のアプリケーションがあることになるので、ステップS2402に戻る。
該判定結果がYesの場合は、プラットフォーム部13はアプリケーション移動パッケージ1900を生成し、保存する。該パッケージは、ステップS2401で取得したアプリケーションパッケージ定義1803、ステップS2403で再生成したアプリケーション1603、使用許諾契約書1621、ステップS2413で保存したアプリケーション移動データ2100で生成される。同パッケージ1900の保存先は間接記憶部123とすることができる(S2415)。或いは、外部インターフェース125を介して接続された外付けHDDやUSBメモリ等の外付け記憶装置や、ネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置に保存してもよい。アプリケーションパッケージ定義1803と、再生成したアプリケーション1603、使用許諾契約書1621と、アプリケーション移動データ2100は、図19で説明した通りのディレクトリに格納される。アプリケーション1603、使用許諾契約書1621、アプリケーション移動データ2100は、アプリケーションパッケージ定義1803に参照情報があるアプリケーション定義1611の数だけ存在する。
プラットフォーム部13は、ステップS2401で読み出したアプリケーションパッケージ定義1803に含まれるアプリケーション1603をアンインストールする(S2416)。この処理は、同部13がアプリケーションパッケージ定義1803に参照情報がある全てのアプリケーション定義1611を読み出し、インストールパス1746に書かれた場所からアプリケーションプログラム、使用許諾契約書を削除することを意味する。
これらの処理が終了すると、プラットフォーム部13は、ユーザインターフェース124を介してアプリケーション移動パッケージの生成が終了したことを通知する。
*アプリケーション移動パッケージを使った再インストール処理
図25のフローチャートを元にプラットフォーム部13におけるアプリケーション移動パッケージ1900のインストール処理について説明する。
本実施形態においては、ステップS2531を除いた処理がアプリケーション移動パッケージのインストール処理であり、そのうちのステップS1511がアプリケーションプログラムのインストールである。即ち、アプリケーション移動パッケージのインストール処理が行われる中で、アプリケーションプログラムのインストールが行われることになる。
プラットフォーム部13は、外部インターフェース125からインストール対象となるアプリケーション移動パッケージ1900を取得する(S2501)。
次に、プラットフォーム部13はステップS2502において以下の処理を行う。取得したアプリケーション移動パッケージ1900に含まれるアプリケーションパッケージ定義1803を取得する。そして、取得したアプリケーションパッケージ定義1803の情報を元にインストール管理テーブル2200を作成する。具体的には、インストール管理テーブル2200のインストール条件確認結果2204、使用許諾同意結果2205以外の情報(アプリケーション定義1611の情報)を格納したインストール管理テーブル2200を作成する。
次に、プラットフォーム部13は、アプリケーションパッケージ定義1803の情報を元に後述するパッケージインストール条件確認を行う(S2503)。そして、確認の結果、インストール可能であった場合は、インストール管理テーブル2200の全てのアプリケーションに対するインストール条件確認結果2204を、インストール可能を示す情報で更新する(S2504,S2517)。また、インストール条件確認の結果が一つでもインストール不可の場合は、外部インターフェース125へインストール出来ない旨を通知し、外部I/F125を介したユーザからの指示を要求する(S2517,S2518)。その後、外部インターフェース125を介したユーザからの指示を確認(インストール処理をこのまま継続するかを確認)する(S2518)。その結果、継続する指示の場合はインストール管理テーブル2200のうちインストール不可のアプリケーションに対するインストール条件確認結果2204を、インストール不可を示す情報で更新する(S2519,S2504)。もちろん、インストール条件確認の結果がインストール可能であったアプリケーションがあった場合、そのアプリケーションに対するインストール条件確認結果2204は、インストール可能を示す情報で更新する(S2504)。また、継続しない指示の場合はインストール処理を中断する(S2531)。
次に、プラットフォーム部13は、作成したインストール管理テーブル2200に登録済みのアプリケーションのうち、インストール条件確認結果2204がインストール可能を示す情報となったアプリケーションのみを対象として処理を行う(S2505)。
プラットフォーム部13は、アプリケーション移動パッケージ1900が、対象のアプリケーション1603の使用許諾契約書1621の複製を対象のアプリケーション1603の外に保持しているかを確認する(S2506,S2507)。
上記確認結果に応じて、図10に示したステップS1026以降の処理と同様のステップS2526以降の処理、または、ステップS1010以降の処理と同様のステップS2508以降の処理を行う。但し、アプリケーションの復号処理(ステップS1013)は行わない。後者の処理が含むステップS1511におけるアプリケーションプログラムのインストールは、図10に示したステップS1014のアプリケーションプログラムのインストールと同様に行われる。
*パッケージインストール条件確認方法
プラットフォーム部13のインストール処理のうち、パッケージインストール条件確認の方法について説明する。
プラットフォーム部13は、アプリケーションパッケージ定義1803で定義されている情報と機器の情報(プラットフォーム部13、画像処理装置12)を付き合わせて比較することでインストール条件を確認する。特にアプリケーション定義1611で定義されている情報のうち、インストール可能プラットフォーム1744及び消費リソースサイズ1745を用いて、第1実施形態においてインストール条件確認方法について説明したのと同様の判断がされる。すなわち、アプリケーションがインストール可能なプラットフォームのバージョンをプラットフォームプログラムが備えているか否かで、また、アプリケーションが消費するリソースを機器が残りリソースとして備えているか否かでインストール可否を判断する。さらに、アプリケーションがインストール可能な機器の固有IDを機器が保持しているか否かで、また、アプリケーションがインストール可能な機器の機能を機器が備えているか否かで、インストール可否を判断する。
本実施形態では、また、プラットフォーム部13はアプリケーション移動パッケージ1900に含まれるアプリケーション1603の全てをインストールすることが出来ないと判断した場合は、続けて以下の判断を行う。アプリケーション移動パッケージ1900に含まれる各アプリケーションについて、アプリケーションパッケージ定義1803に含まれる個別アプリケーション定義1611を用いて個別にインストール可否を判断する。
本実施形態によれば、複数のアプリケーションの元の使用環境、つまりアプリケーションの設定やユーザのデータを含めた環境を容易に再現(再インストール)できるアプリケーション移動パッケージの生成手段が提供される。これにより、アプリケーションパッケージのインストール処理時に、全てのアプリケーションに対するインストール条件の確認及び使用許諾契約への同意等の作業を、インストール処理の最初にまとめて行うことが可能となる。さらに、アプリケーションパッケージ定義を用いることにより、インストール条件の確認のパフォーマンスを向上出来る。これにより、インストール処理中に使用許諾契約書への同意やインストール処理の継続等の入力作業を行う必要が生じてインストール処理が煩雑になることを防止でき、インストール処理のパフォーマンスを向上できる。
(第4実施形態)
本実施形態において第1実施形態と同一の構成及び構成要素には同一の符号を用い、それらの説明は適宜省略し、異なる点を詳しく説明する。
異なっている点は、本実施形態におけるアプリケーション移動パッケージは、アプリケーションの選択が可能である点である(図27)。つまり、第1実施形態では、アプリケーション移動パッケージ1900の生成は、プラットフォーム部13にインストールされたアプリケーションパッケージ単位での選択であり、アプリケーションパッケージ内のアプリケーションを選択することは含まれない。
また、本実施形態は、アプリケーション移動パッケージ1900の保存先の環境が、当該アプリケーションをインストール可能なプラットフォームである場合に、アプリケーション移動パッケージ1900に当該アプリケーションを含めるという点が異なる。
また、本実施形態では、アプリケーションパッケージ定義を含むアプリケーション移動パッケージを作成するにあたり、アプリケーション定義中の情報の種類に応じた演算(和算、積算)を第2実施形態と同様に行っている。このような演算は、インストールされているアプリケーションパッケージ定義をそのまま複製する第3実施形態では行わない。
*アプリケーションパッケージ移動選択UI
図26は本実施形態に係るアプリケーションパッケージの移動選択を行うUIの例である。
アプリケーションパッケージ選択領域2601、遷移ボタン2602で構成されるアプリケーションパッケージ移動選択UI200がユーザI/F124のディスプレイに表示され、ユーザからの指示を受け付ける。
アプリケーションパッケージ選択領域2601には、プラットフォーム部13にインストールされているアプリケーションパッケージの一覧2611〜2613が表示される。アプリケーションパッケージ選択領域2601では、ユーザによる、移動したいアプリケーションパッケージを一つ選択することが可能となる。
遷移ボタン2602は、アプリケーションパッケージ選択領域2601で選択されたアプリケーションパッケージのうち、どのアプリケーションを移動するかを選択するアプリケーション選択UI2700(図27)に遷移する。同UIについて次に述べる。
*アプリケーション選択UI
図27は本実施形態に係るアプリケーションの移動選択及びアプリケーション移動パッケージの生成指示を行うUIの例である。
アプリケーション選択領域2701、実行ボタン2702、戻るボタン2703で構成されるアプリケーション選択UI2700がユーザI/F124のディスプレイに表示され、ユーザからの指示を受け付ける。
アプリケーション選択領域2701に、アプリケーションパッケージ移動選択UI2600のアプリケーションパッケージ選択領域2601で選択されたアプリケーションパッケージに含まれるアプリケーション1603の一覧2711〜2713が表示される。つまり同UI2600でアプリケーションパッケージ(1)を選択してアプリケーション選択UI2700に遷移した場合、アプリケーション選択領域2701に、アプリケーションパッケージ(1)が含むアプリケーションの一覧が表示される。また、アプリケーション選択領域2701では、ユーザによる、移動したいアプリケーションを複数選択できる。
実行ボタン2702は、ユーザが、アプリケーション移動パッケージ1900の生成指示をプラットフォーム部13に対して行うためのボタンである。実行ボタン2702がユーザによって押下されると、プラットフォーム部13は、選択されたアプリケーションに対応するアプリケーション移動パッケージ1900の生成処理を開始する。この処理に関しては後述する。
ユーザが戻るボタン2703を押下すると、プラットフォーム部13が、アプリケーション選択UI2700をユーザインターフェース124のディスプレイから消去し、アプリケーションパッケージ移動選択UI2600の表示に戻る。
*アプリケーション選択によるアプリケーション移動パッケージ生成処理
図28のフローチャートを元にプラットフォーム部13におけるアプリケーション移動パッケージ1900の生成処理(再パッケージ化)について説明する。
この処理は、前述したアプリケーション選択UI2700において、ユーザによるアプリケーション移動パッケージ生成指示(実行ボタン2702による指示)をユーザI/F124のディスプレイを介してプラットフォーム部13が受信し、開始する。プラットフォーム部13が受信した指示情報には、アプリケーション選択UI2700で選択されたアプリケーションパッケージのID及びアプリケーションのIDが含まれる。これらの情報を元に、アプリケーション移動パッケージの生成を開始する。
プラットフォーム部13は、アプリケーション移動パッケージ生成指示を受信し、アプリケーションパッケージIDに対応したアプリケーションパッケージ定義1803を取得する。さらに、同部13は、取得した同定義1803にあるアプリケーション定義への参照情報から、選択されたアプリケーションに対応するアプリケーションIDを持つ、全てのアプリケーション定義1611を取得し、リスト化する(S2801)。
プラットフォーム部13は、ステップS2801で取得したアプリケーション定義1611のリストから一つを読み出す(S2802)。
プラットフォーム部13は、アプリケーション移動パッケージ1900の保存先が画像形成装置かを確認する。具体的には、外部インターフェース125を解して接続された別体の画像形成装置か否かを判定する(S2803)。該判定結果がNoの場合、プラットフォーム部13は、間接記憶部123だけでなく、外部インターフェース125を介して接続された外付けHDDやUSBメモリ等の外付け記憶装置が保存先であるとみなし、ステップS2805に進む。該判定結果がYesの場合、プラットフォーム部13は、別体の画像形成装置が保存先であるとみなし、当該アプリケーションがインストール可能なプラットフォームであるか否かを判定する。つまり、ステップS2802で読み出したアプリケーション定義1611にあるインストール可能プラットフォーム1744の情報と、保存先のプラットフォームの情報(バージョン等)を比較し、合致するか否かを判定する(S2804)。該判定結果がYesの場合、プラットフォーム部13は、当該アプリケーションの保存先でのインストールが可能であるとみなし、ステップS2805に進む。該判定結果がNoの場合、同部13は、当該アプリケーションの保存先でのインストールが不可であるとみなし、当該アプリケーションを同部13からアンインストールせずに残すかをユーザI/F124を介してユーザに確認する(S2831)。該確認結果がアンインストールしない(Yesの)場合は、プラットフォーム部13は、ステップS2801でリスト化されたアプリケーション定義のリストから当該アプリケーションの定義(アプリケーションID)を削除する(S2832)。アプリケーションIDを削除する理由は、当該アプリケーションはプラットフォーム部13からアンインストールしないためである。ステップS2832でアンインストール対象から外すとステップS2816に進む。該確認結果がNoの場合は、処理は行わずにステップS2816に進む。
ステップS2803でNo判定、ステップS2804でYes判定の場合、ステップS2805においてプラットフォーム部13はアプリケーション1603の再生成を行う。すなちわち、ステップS2802で読み出したアプリケーション定義1611のインストールパス1746に書かれている場所から、アプリケーションプログラム1622、使用許諾契約書1621をコピーする。コピーしたアプリケーションプログラム1622、使用許諾契約書1621、及び、ステップS2802で読み出したアプリケーション定義1611は、アプリケーション1603として図16で説明した通りのディレクトリに格納する。さらに、プラットフォーム部13は、外付けHDDやUSBメモリ等の外付け記憶装置が保存先であるとみなした場合と当該アプリケーションの保存先でのインストールが可能であるとみなした場合、使用許諾契約書1621をコピーする。
プラットフォーム部13は、ステップS2802で読み出したアプリケーション定義のインストールパス1746に書かれている場所に、該当のアプリケーション1603に対応する、アプリケーション単位の設定情報が格納されているか判定する(S2806)。該判定結果がYesの場合は、プラットフォーム部13は、該当するアプリケーション1603のアプリケーション単位の設定情報をアプリケーションのConfig2101としてコピーし(S2807)、ステップS2809に進む。該判定結果がNoの場合は、処理は行わずにステップS2809に進む。
ステップS2809において同部13は、ステップS2802で読み出したアプリケーション定義1611のインストールパス1746に書かれている場所に、該当するアプリケーション1603に対応するユーザ単位の設定情報が格納されているか否か判定する。該判定結果がYesの場合は、プラットフォーム部13は、該当するアプリケーション1603のユーザ単位の設定情報をアプリケーションのPreference2102としてコピーし(S2810)、ステップS2812に進む。該判定結果がNoの場合は、処理は行わずにステップS2812に進む。
ステップS2812においてプラットフォーム部13は、ステップS2402で読み出したアプリケーション定義1611のデータ保存パス1747に書かれている場所に、該当のアプリケーション1603が生成し、保存したデータが格納されているか判定する。該判定結果がYesの場合は、プラットフォーム部13は、該当するアプリケーション1603が生成し、保存したデータをアプリケーションのユーザデータ2103としてコピーし(S2813)、ステップS2815に進む。該判定結果がNoの場合は、処理は行わずにステップS2815に進む。
ステップS2815では、ステップS2807、S2810,S2813でコピーしたアプリケーションのConfig2101、Preference2102、及び、ユーザデータ2103が、アプリケーション移動データ2100として保存される。コピーをアプリケーションプログラムに関連付けるこの処理は、プラットフォーム部13が行う。ステップS2815では、プラットフォーム部13は、アプリケーション移動データ2100を、当該アプリケーション1603との対応を保持するために、アプリケーションIDを付加して命名する。
ステップS2815またはS2832に続き或いはステップS2831でNo判定の場合、プラットフォーム部13はステップS2816において、ステップS2801でリスト化したアプリケーション定義1611を全て確認したかどうか判定する。該判定結果がNoの場合は未確認のアプリケーションがあるので、ステップS2802に戻る。
該判定結果がYesの場合は、プラットフォーム部13は、本処理で生成するアプリケーション移動パッケージ1900のアプリケーションパッケージ定義1803の作成を行う(S2817)。プラットフォーム部13は、アプリケーション移動パッケージ1900に含めるアプリケーション定義1611で定義されている情報を夫々合算することでアプリケーションパッケージ定義1803を作成する。特にアプリケーション定義1611にて定義されている情報のうち、インストール可能プラットフォーム1744及び消費リソースサイズ1745の情報に関して夫々合算する。アプリケーションパッケージ定義1803を作成するための具体的な合算の仕方は第2実施形態においてアプリケーションパッケージ定義1103作成方法について説明した仕方と同じで良い。
プラットフォーム部13は、アプリケーション移動パッケージ1900を生成し、ステップS2803で確認した場所に保存する(S2818)。パッケージ1900は、ステップS2817で作成のアプリケーションパッケージ定義1803、ステップS2805で再生成のアプリケーション1603、使用許諾契約書1621、ステップS2815で保存のアプリケーション移動データ2100で生成される。アプリケーションパッケージ定義1803と、再生成したアプリケーション1603、使用許諾契約書1621と、アプリケーション移動データ2100は、図19で説明した通りのディレクトリに格納される。アプリケーション1603、使用許諾契約書1621、アプリケーション移動データ2100は、アプリケーションパッケージ定義1803に参照情報があるアプリケーション定義1611の数だけ存在する。
プラットフォーム部13は、ステップS2801でリスト化されたアプリケーション定義のリストに含まれるアプリケーション1603をアンインストールする(S2819)。尚、ステップS2832でアンインストールしないとされたものは、リストから削除されているため、アンインストールされない。この処理は、同部13がS2801でリスト化されたアプリケーション定義のリストに含まれるアプリケーション定義1611全てを読み出し、インストールパス1746に記載の場所からアプリケーションプログラム、使用許諾契約書を削除することを意味する。
本実施形態によれば、複数のアプリケーションをユーザが選択し、元の使用環境、つまりアプリケーションの設定やユーザのデータを含めた環境を容易に再現(再インストール)できるアプリケーション移動パッケージの生成手段が提供される。これにより、アプリケーションパッケージのインストール処理時に、全てのアプリケーションに対するインストール条件の確認及び使用許諾契約への同意等の作業を、インストール処理の最初にまとめて行うことが可能となる。さらに、アプリケーションパッケージ定義を用いることでインストール条件の確認のパフォーマンスを向上出来る。これにより、インストール処理中に使用許諾契約書への同意やインストール処理の継続等の入力作業を行う必要が生じてインストール処理が煩雑になることを防げ、インストール処理のパフォーマンスを向上できる。
尚、本明細書では、「アプリケーション内のアプリケーションプログラムをインストールするにあたってインターフェースを介してユーザに指示を要求することに繋がるデータ」の例として、使用許諾契約書やアプリケーション定義について取り上げた。しかし、これらはあくまで一例である。添付の各フローチャートは、これらに限られず、他の「アプリケーション内のアプリケーションプログラムをインストールするにあたってインターフェースを介してユーザに指示を要求することに繋がるデータ」にも適用可能である。
使用許諾契約書は、アプリケーション内のアプリケーションプログラムをインストールする前にインターフェースを介してユーザに同意を要求するためのデータである。従って、使用許諾契約書は、「アプリケーション内のアプリケーションプログラムをインストールするにあたってインターフェースを介してユーザに指示を要求することに繋がるデータ」であると言える。
また、アプリケーション定義は、インストール条件確認の結果がインストール不可かどうかを判定することに用いられる。この判定結果でインストール不可となった場合には、インターフェースを介したユーザからの指示が要求される(S1018、S1518、S2518)。従って、アプリケーション定義は、アプリケーション内のアプリケーションプログラムをインストールするにあたってインターフェースを介してユーザに指示を要求すべきか否か、を決定する際に必要なデータである。よって、アプリケーション定義も、「アプリケーション内のアプリケーションプログラムをインストールするにあたってインターフェースを介してユーザに指示を要求することに繋がるデータ」であると言える。
(本発明の他の実施形態)
前述した実施形態の機能を実現するように前述した実施形態の構成を動作させるプログラムを記憶媒体に記憶させ、該記憶媒体に記憶されたプログラムをコードとして読み出し、コンピュータにおいて実行する処理方法も上述の実施形態の範疇に含まれる。また、前述のプログラムが記憶された記憶媒体はもちろんそのプログラム自体も上述の実施形態に含まれる。