(57)【要約】【課題】  アプリケーション実行時に必要とされるファイルが、インストール・アップデートの処理によってパッケージ外に展開後もパッケージ内に残り続け、ディスク使用量が増加することを防ぐ。【解決手段】  ライブラリと設定情報とを含むアプリケーションのパッケージを受信し、設定情報が展開対象に指定する展開対象ライブラリを記憶装置に展開して書き込み、展開対象ライブラリを含まないパッケージを記憶装置に書き込むことにより、展開されたライブラリをパッケージ内に重複して残さないようにし、ディスク使用量を抑制する。【選択図】  図３
2014146277.tif 000002
【特許請求の範囲】
【請求項１】
ライブラリと設定情報とを含むアプリケーションのパッケージを処理するアプリケーション処理装置であって、
前記アプリケーションのパッケージを受信する受信手段と、
前記設定情報が展開対象に指定する展開対象ライブラリを記憶装置に展開して書き込み、前記展開対象ライブラリを含まないパッケージを前記記憶装置に書き込む書き込み手段と、
を備えることを特徴とするアプリケーション処理装置。
【請求項２】
前記記憶装置は第１の記憶領域と第２の記憶領域とを備え、
前記書き込み手段はインストール処理の際に前記受信手段で受信したパッケージを前記第２の記憶領域に書き込み、前記設定情報が展開対象に指定する展開対象ライブラリを前記第１の記憶領域に展開して書き込み、前記展開対象ライブラリを含まないパッケージを前記第１の記憶領域に書き込むことを特徴とする請求項１に記載のアプリケーション処理装置。
【請求項３】
前記受信手段は、新たなアプリケーションのパッケージを受信し、
前記書き込み手段は、インストール済みのアプリケーションのパッケージと展開済みライブラリと前記受信手段で受信された新たなアプリケーションのパッケージとを第２の記憶領域に書き込み、前記新たなパッケージの設定情報が展開対象に指定する展開対象ライブラリを前記第１の記憶手段に展開して書き込み、前記展開対象ライブラリを含まない新たなパッケージを前記第１の記憶領域に書き込み、
更に、第２の記憶領域に書き込まれたインストール済みのアプリケーションのパッケージと展開済みライブラリと新たなアプリケーションのパッケージとを削除する削除手段を備えることを特徴とする請求項２に記載のアプリケーション処理装置。
【請求項４】
インストール処理の際に前記展開対象ライブラリを含まないパッケージと前記展開対象ライブラリを含むパッケージのいずれを前記記憶装置に書き込むかの指示を判定する縮小処理判定手段を更に備え、
前記書き込み手段は、前記縮小処理判定手段の結果に基づいてパッケージを書き込むことを特徴とする請求項１乃至３に記載のアプリケーション処理装置。
【請求項５】
前記受信手段はストリーム形式でパッケージを受信し、前記記憶装置に前記ストリーム形式のパッケージをファイルとして書き込み、前記ファイルを読み込むことで前記設定情報を取得することを特徴とする請求項１記載のアプリケーション処理装置。
【請求項６】
前記設定情報はマニフェストファイルであることを特徴とする請求項１記載のアプリケーション処理装置。
【請求項７】
前記アプリケーション処理装置は、アプリケーション管理フレームワークであることを特徴とする請求項１記載のアプリケーション処理装置。
【請求項８】
前記受信手段では、インストール対象のアプリケーションのパッケージを受信することを特徴とする請求項１記載のアプリケーション処理装置。
【請求項９】
前記第１の記憶領域はインストール用領域、前記第２の記憶領域は汎用領域であることを特徴とする請求項２記載のアプリケーション処理装置。
【請求項１０】
前記新たなアプリケーションによりインストール済みのアプリケーションをアップデートすることを特徴とする請求項３記載のアプリケーション処理装置。
【請求項１１】
ライブラリと設定情報とを含むアプリケーションのパッケージを処理するアプリケーション処理方法であって、
前記アプリケーションのパッケージを受信する受信工程と、
前記設定情報が展開対象に指定する展開対象ライブラリを記憶装置に展開して書き込み、
前記展開対象ライブラリを含まないパッケージを前記記憶装置に書き込む書き込み工程を備えることを特徴とするアプリケーション管理方法。
【請求項１２】
コンピュータを
ライブラリと設定情報とを含むアプリケーションのパッケージを受信する受信手段と、
前記設定情報が展開対象に指定する展開対象ライブラリを記憶装置に展開して書き込み、前記展開対象ライブラリを含まないパッケージを前記記憶装置に書き込む書き込み手段と、として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションのパッケージを処理するアプリケーション処理装置、方法及びプログラムに関する。
【背景技術】
【０００２】
アプリケーションの実行環境として、Ｊａｖａ（登録商標）が広く採用されている。Ｊａｖａ（登録商標）採用の理由としては、プラットフォーム非依存性、豊富なクラスライブラリ、セキュアな実行環境等が挙げられる。また、その他の大きな特徴として、統一されたアプリケーションの配布形態も挙げられる。
【０００３】
Ｊａｖａ（登録商標）の実行環境であるＪＲＥ（Ｊａｖａ（登録商標）  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｎｍｅｎｔ）は、クラスライブラリ、Ｊａｖａ（登録商標）ＶＭ（Ｊａｖａ（登録商標）言語にて記述されたアプリケーションを実行するためのソフトウェア）、及びＪＲＥを搭載する端末固有のポーティングレイヤより構成される。実行環境はＪＡＲ（Ｊａｖａ（登録商標）  Ａｒｃｈｉｖｅ）ファイルを入力として受け取ると、ＪＡＲファイルより実行に必要なクラスファイル（Ｊａｖａ（登録商標）言語で記述されたソースコードをＪａｖａ（登録商標）コンパイラでコンパイルすることで生成されるプログラムモジュール）を読み込んで、実行する。ＪＡＲファイルとは、クラスファイル及びＪａｖａ（登録商標）アプリ実行過程で使用する様々なリソースファイル（イメージファイル、テキストファイル等）を、ＪＡＲ形式でパッケージ化したファイルである。クラスの読み込みは、クラスローダによって行われる。クラスローダは、クラスパス（クラスが存在するパスを示す情報）を参照して、ＪＡＲ形式でパッケージ化されたクラスファイルのクラスを探索する。
【０００４】
ＪＡＲファイルＡには他のＪＡＲ形式のファイルであるＪＡＲファイルＢを含めることもできるが、通常のクラスローダではＪＡＲファイルＡ内部のＪＡＲファイルＢを読み込めない。そこで、ＪＡＲファイルＡ内部のＪＡＲファイルＢを、ＪＡＲファイルＡの外部に展開するとともに、ＪＡＲファイルＡ実行時に実行環境に設定するクラスパスあるいはＪＡＲファイルＡを読み込むクラスローダに設定するクラスパスに、展開した場所を加えることで、ＪＡＲファイルＢを通常のクラスローダで読み込ませる方法がある。
【０００５】
通常ＪＡＲファイル内部に存在するＪＡＲファイルを、クラスローダは読み込めない。つまり、上記の例ではＪＡＲファイルＡ内部のＪＡＲファイルＢは、クラスローダから読み込み対象として認識されず読み込まれない。このように、ＪＡＲファイルを展開と合わせて削除を行わないと、同一ファイルが複数存在した状態になる。この状態では展開元のＪＡＲファイルにはプログラムの実行時に読み込まれないファイルが含まれるため、ストレージ領域が少ないデバイスでは問題となる。
【０００６】
このような問題を解決する技術として、例えばＪＡＲファイルのプログラムを一度実行して、実行時に不要となるファイルを特定してＪＡＲファイルから削除する技術（例えば特許文献１、２、３参照）がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−６６８７２
【特許文献２】特開２０１２−１２３６１９
【特許文献３】ＷＯ０２／０７５５２５
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１では、ＪＡＲファイルに含まれるアイコンイメージファイルを削除し、ＪＡＲファイルのサイズを縮小する。しかしながら、削除するファイルを特定するためには、最低一回はＪＡＲファイルのプログラムを実行しなくてはならない。
【０００９】
特許文献２では、アプリケーションに含まれる不要機能を削除することで、リソース消費量を削減する。しかしながら、各機能の実行履歴にもとづいて不要機能を判定するため、最低一回はプログラムを実行しなくてはならない。不要機能に関するファイルは、不要機能と判定されて削除されるまで、ストレージを専有し続ける。
【００１０】
特許文献３では、アプリケーションをアップデートする際に、アップデート後に不要となるファイルを削除する。しかし、削除の対象はアップデートで発生する差分ファイルのみである。
【００１１】
デバイスのストレージ容量に余裕がない環境では、インストール・アップデートの処理において、ＪＡＲファイルのサイズを速やかに縮小する必要がある。
【００１２】
本発明は上記の課題に鑑みてなされたものであり、ＪＡＲパッケージファイルのサイズを速やかに縮小し、デバイスのストレージ容量を省くアプリケーション処理装置を提供することを目的とする。また、その方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明のアプリケーション処理装置は、以下の構成を備える。即ち、ライブラリと設定情報とを含むアプリケーションのパッケージを処理するアプリケーション処理装置であって、前記アプリケーションのパッケージを受信する受信手段と、前記設定情報が展開対象に指定する展開対象ライブラリを記憶装置に展開して書き込み、前記展開対象ライブラリを含まないパッケージを前記記憶装置に書き込む書き込み手段。
【発明の効果】
【００１４】
本発明によれば、アプリケーションのパッケージ外部に展開されたライブラリファイルをアプリケーションのパッケージ内部に含まないので、アプリケーションのサイズを縮小することが出来る。
【図面の簡単な説明】
【００１５】
【図１】情報管理装置のハードウェア構成の一例を示す図
【図２】情報管理装置上に構築するシステム構成の一例を示す図
【図３】アプリケーションのパッケージのファイル構成を示す図
【図４】実施形態１にかかるアプリケーション管理フレームワーク２０３の構成および情報管理装置が備える記憶装置の領域を示す図
【図５】実施形態１にかかるインストール処理のフローチャート
【図６】実施形態２にかかるアップデート処理のフローチャート
【図７】（ａ）実施形態２にかかる汎用領域とインストール用領域に書き込まれたファイルを示す図（ｂ）実施形態２にかかる汎用領域とインストール用領域に書き込まれたファイルを示す図（ｃ）実施形態２にかかる汎用領域とインストール用領域に書き込まれたファイルを示す図（ｄ）実施形態２にかかる汎用領域とインストール用領域に書き込まれたファイルを示す図
【図８】実施形態３にかかるアプリケーション管理フレームワーク２０３の構成を示す図
【図９】実施形態３にかかるインストールしたアプリケーションのインストール済みパッケージのファイル構成を示す図
【図１０】実施形態３にかかるインストール処理のフローチャート
【図１１】実施形態４にかかるアップデート処理のフローチャート
【図１２】実施形態３にかかるインストールするアプリケーションの一覧を記載したテキストファイル
【図１３】実施形態５にかかるインストール処理のフローチャート
【図１４】実施形態６にかかるインストール済みアプリケーションの縮小処理のフローチャート
【図１５】実施形態６にかかるアプリケーション管理フレームワーク２０３の構成を示す図
【発明を実施するための形態】
【００１６】
以下、添付の図面を参照して、本発明の好適な実施形態を詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１７】
＜実施形態１＞
図１は、一般的な情報管理装置１０１のハードウェア構成の一例を示す図である。図１に示されるように情報管理装置１０１は、ハードウェア構成として、ＣＰＵ１１を含む。
【００１８】
ＣＰＵ１１が、記憶装置１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートを実現する。
【００１９】
また、ＣＰＵ１１には、バス１０を介して、入力装置１２、記憶装置１３、表示装置１４及び外部接続ＩＦ１５が接続されている。入力装置１２は、情報を入力するキーボード及び／又はマウスである。記憶装置１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示装置１４は、画面等を表示するディスプレイである。外部接続ＩＦ１５は、ネットワークインタフェース、外部機器との各種接続インタフェースである。
【００２０】
尚、ＣＰＵ１１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１１と情報管理装置の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵ１１は分散して処理を実行することが可能である。また、複数のＣＰＵ１１は単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵ１１がプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。
【００２１】
次に、情報管理装置１０１上に構築するシステム構成について、図２を用いて説明する。図２は、情報管理装置１０１のシステム構成の一例を示す図である。
【００２２】
オペレーティングシステム２０１は、システム全体の基盤となるソフトウェアである。アプリケーション実行環境２０２は、例えば仮想マシンのように、オペレーティングシステム２０１上のプロセスでありながら、自身の上でアプリケーションが動作する環境を提供するソフトウェアである。アプリケーション管理フレームワーク２０３は、各アプリケーション２０４の動作状態を管理する機能をもつ。また、アプリケーション管理フレームワーク２０３への指示を行うシステムアプリケーション２０５が動作することもある。例えば、アプリケーションのインストール・アップデートを指示するユーザインタフェースを備えるシステムアプリケーション２０５が挙げられる。
【００２３】
本実施形態で用いる情報管理装置１０１のハードウェア構成では、記憶装置１３は高速なインストール用領域と、低速な汎用領域を備える。インストール用領域の容量は比較的少ないため、アプリケーションの実行に不要なファイルの保存を抑制することが課題となる。
【００２４】
本実施形態は、これらの課題を解決するために、アプリケーション管理フレームワーク２０３が汎用ディスク領域とインストール用ディスク領域を使い分けつつ、インストール済みアプリケーションが記憶装置を占めるサイズを縮小できる仕組みを実現する。
【００２５】
初めに、インストール・アップデートの対象となるアプリケーションのパッケージ構成を、図３（ａ）、図３（ｂ）を用いて説明する。図３（ａ）は、パッケージのファイル構成を示す図である。図３（ｂ）はインストール済みパッケージのファイル構成を示す図である。
【００２６】
図３（ａ）に示すアプリケーション３０１は、ＪＡＲファイルである。このＪＡＲファイルは、実行形式のプログラムであるｂｉｎ３０２を含む。また、アプリケーションの名前、ｉｄ、ベンダー、などを記述するｍａｎｉｆｅｓｔ３０３（以降、マニフェストファイルと同義である）を含む。さらに、アプリケーション３０１には、特定機能を実現するｂｉｎ３０２をまとめてＪＡＲファイルにしたものを複数含めることもできる。含まれるＪＡＲファイル群は、ｌｉｂ３０４（ライブラリ）である。アプリケーション３０１はｂｉｎ３０２とｍａｎｉｆｅｓｔ３０３を必ず含むが、ｌｉｂ３０４を含むとは限らない。ｌｉｂ３０４を含む場合には、展開対象のＪＡＲファイル群を記述するｍａｎｉｆｅｓｔ３０３の項目に、ｌｉｂ３０４の要素である各ＪＡＲファイルのパスを記載する。
【００２７】
図３（ｂ）に示すアプリケーション３０１は、インストール用領域４０２にインストール済みのファイル構成である。ｌｉｂ３０４はＪＡＲファイル３０１の外部に展開され、ＪＡＲファイル３０１内には無い。また、クラスローダがｌｉｂ３０４を見つけるための情報が、クラスパス情報３０５として保存されている。
【００２８】
次に、アプリケーション管理フレームワーク２０３の動作について、図４、図５を用いて説明する。図４は、アプリケーション管理フレームワーク２０３の構成と情報管理装置１０１が備える記憶装置の領域を示す図である。図５はアプリケーション管理フレームワーク２０３がアプリケーション３０１をインストールする処理の手順を示すフローチャートである。
【００２９】
汎用領域４０１とインストール用領域４０２は、記憶装置１３が備える記憶用領域である。領域書き込み部４０４は、書き込み先のパスを指定してデータを書き込むことで、汎用領域４０１とインストール用領域４０２のいずれにも書き込みを行える。
【００３０】
アプリケーション管理フレームワーク２０３は、インストール・アップデート対象となるアプリケーション３０１のデータを、パッケージ受信部４０３によって受信する（ステップＳ５０１）。受け取るデータは、データストリームとして与えられ、アプリケーション管理フレームワーク２０３は対象となるアプリケーションのｍａｎｉｆｅｓｔ３０３を読み込むために、データストリームをファイル形式に変換する必要がある。そのため、アプリケーション管理フレームワーク２０３は、領域書き込み部４０４によって、汎用領域４０１にパッケージのストリームを一時的なファイルとして書き込む（ステップＳ５０２）。汎用領域４０１に書き込むのは、インストール用領域４０２に一時的なファイルを配置しないためである。もしインストール用領域４０２に一時的なファイルを配置すると、後述のステップＳ５０４にインストール用領域４０２に書き込む際に、インストール用領域４０２の空き領域が少なくなってしまい、書き込みが失敗することがあるからである。具体例として、インストール用領域４０２が容量１０ＭＢであり、６ＭＢのアプリケーション３０１をインストールするとする。ここで、一時的なファイルをインストール用領域４０２に配置すると、インストール処理中に１２ＭＢの容量が必要となるため、書き込みが失敗する。
【００３１】
汎用領域４０１にアプリケーション３０１を書き込むと、アプリケーション管理フレームワーク２０３は設定情報取得部４０５によって、マニフェスト（ｍａｎｉｆｅｓｔ３０３）を読み込む（ステップＳ５０３）。
【００３２】
そして、アプリケーション管理フレームワーク２０３は、マニフェストに展開対象のファイル（ｌｉｂ３０４）が記載されているかを確認する（ステップＳ５０４）。記載されている場合、パッケージ展開部４０６は領域書き込み部４０４を用いて、インストール用領域４０２にｌｉｂ３０４を書き込むことで展開する（Ｓ５０６）。
【００３３】
ステップＳ５０４、またはステップＳ５０６が完了すると、アプリケーション管理フレームワーク２０３はマニフェストに記載されている展開対象のＪＡＲファイル（ｌｉｂ３０４）以外のファイルを、インストール用領域４０２に書き込む（ステップＳ５０５）。書き込みにおいては、汎用領域４０１のＪＡＲファイル３０１を開き、必要なファイル（ｂｉｎ３０２とｍａｎｉｆｅｓｔ３０３）をインストール用領域４０２のファイルに対して開いたデータストリームに書き込んでいく。こうすることで、インストール用領域４０２に一時ファイルを書き込むことなく、インストール用領域４０２に、ｌｉｂ３０４が無い状態のアプリケーション３０１のＪＡＲファイルが書き込まれる。
【００３４】
次に、アプリケーション管理フレームワーク２０３はクラスパス情報３０５をインストール用領域４０２に保存する（ステップＳ５０７）。クラスパス情報３０５は、インストール用領域４０２に書き込んだアプリケーション３０１のパスと、ｌｉｂ３０４のパスである。
【００３５】
クラスパス情報３０５を保存すると、汎用領域４０１に書き込んだパッケージを削除して（ステップＳ５０８）、インストール処理は終了する。以上、アプリケーション管理フレームワーク２０３がインストール処理を行う場合の実施形態を説明した。インストール対象のパッケージを一度汎用領域に配置し、必要なファイルのみを含むパッケージをインストール用領域に書き込むことで、インストール済みアプリケーションのパッケージサイズを縮小することができる。インストール用領域４０２にｌｉｂ３０４ファイルを重複して書きこまないので、パッケージサイズが縮小している。
【００３６】
＜実施形態２＞
次に、アプリケーション管理フレームワーク２０３が行うアプリケーションのアップデートの処理手順について、図６，図７（ａ）、図７（ｂ）、図７（ｃ）、図７（ｄ）を用いて説明する。図６は、アプリケーション管理フレームワーク２０３が行う処理の手順を示すフローチャートである。図７（ａ）、図７（ｂ）、図７（ｃ）、図７（ｄ）は、アプリケーション管理フレームワーク２０３のアップデートの各処理において、汎用領域４０１とインストール用領域４０２に書き込まれたファイルを示した図である。
【００３７】
インストール済みアプリケーション３０１を、アプリケーション７０１でアップデートする例で説明する。アプリケーション７０１はアプリケーション３０１のバージョンアップ版であり、ｍａｎｉｆｅｓｔ３０３とｍａｎｉｆｅｓｔ７０３において、アプリケーションの名前とｉｄは同一である。
【００３８】
ステップＳ６０１、Ｓ６０２は、それぞれステップＳ５０１，Ｓ５０２と同様である。ステップＳ６０２終了後、汎用領域４０１とインストール用領域４０２は、図７（ａ）の状態となる。
【００３９】
次に、アプリケーション管理フレームワーク２０３はインストール済みのパッケージ（インストール用領域４０２内のアプリケーション３０１のＪＡＲファイル）とアプリケーション３０１のｌｉｂ３０４を、汎用領域４０１に退避する（Ｓ６０３）。退避処理は、汎用領域４０１にアプリケーション３０１のパッケージとｌｉｂ３０４とをコピー後に、インストール用領域４０２からアプリケーション３０１のパッケージとｌｉｂ３０４とを削除することで行う。このとき、汎用領域４０１とインストール用領域４０２の状態は図７（ｂ）となる。
【００４０】
次に、アプリケーション管理フレームワーク２０３はステップＳ５０３と同様にマニフェストを読み込み（ステップＳ６０４）、ステップＳ５０４、Ｓ５０６と同様の処理を行う（Ｓ６０５，Ｓ６０７）。そして、ステップＳ５０５と同様にアプリケーション７０１のパッケージとｌｉｂ７０４とをｌｉｂ７０４が重複しないようにインストール用領域４０２に書き込む（Ｓ６０６）。
【００４１】
ステップＳ６０６が完了すると、ここまでの処理で例外が発生したかを確認する（ステップＳ６０８）。想定される例外として、インストール用領域４０２の空き領域不足による書き込み例外がある。例えば、アップデート前とアップデート後でパッケージのサイズが増加する場合に、空き領域不足の例外が起き得る。また、ステップＳ６０３の退避を行わずに新しいパッケージをステップＳ６０５で書き込んでしまうと、インストール用領域４０２の空き領域不足が起きやすくなる。また、退避を行わずに上書きで書き込んでしまうと、アップデートが失敗した時にステップＳ６１０のようにアップデート前の状態に戻せない。
【００４２】
例外が発生していなければ新しいクラスパスの情報をクラスパス情報７０５として保存する（ステップＳ６０９）。このとき、汎用領域４０１とインストール用領域４０２の状態は図７（ｃ）となる。例外が発生していれば、インストール用領域４０２に書き込んだファイル（アプリケーション７０１、ｌｉｂ７０４）を削除する。そして、退避したパッケージ（アプリケーション３０１，ｌｉｂ３０４）をインストール用領域４０２に戻して、元の状態に復旧する（ステップＳ６１０）。
【００４３】
次に、アプリケーション管理フレームワーク２０３は汎用領域に書き込んだパッケージ３０１と７０１とｌｉｂ３０４とを削除し（Ｓ６１１）、処理は終了する。ステップＳ６０８でエラーが起きていなければ、このときの汎用領域４０１とインストール用領域４０２の状態は図７（ｄ）となる。
【００４４】
なお、ステップＳ６０３の処理はステップＳ６０６、Ｓ６０７より前ならば、いずれのタイミングで行なってもよい。
【００４５】
以上、アプリケーション管理フレームワーク２０３がアプリケーションのアップデート処理を行う場合の実施形態を説明した。
【００４６】
＜実施形態３＞
実施形態１では、ｌｉｂ３０４が無い状態のサイズを縮小したパッケージをインストール用領域４０２に書き込む処理を行った。この縮小処理で、インストール用領域に一時的なファイルを配置すると、インストール用領域を十分に活用することができないことが起こりえる。一時的なファイルをインストール用領域に置くには、インストール用領域の空き領域がインストール対象アプリケーションの２倍必要になってしまう。そこで、実施形態１では、インストール処理で受信したストリームを汎用領域４０１にファイルとして書き込んでから、インストール用領域４０２にファイルを書き込んだ。
【００４７】
一方、アプリケーション３０１がｌｉｂ３０４を含まない場合、ストリームを直接インストール用領域４０２に書き込むことで、インストール処理をより高速に行うことができる。また、ｌｉｂ３０４のサイズが小さい場合、サイズの縮小よりもインストール処理の高速化を優先したい場合もある。このようなケースに対応するには、パッケージの縮小処理を行うかどうかを予め指示・設定しておき、その指示を参照して縮小処理をするかしないか判定する機能をアプリケーション管理フレームワーク２０３が備える必要がある。
【００４８】
そこで、パッケージの縮小処理を判定する機能を備える実施形態を、図８を用いて、実施形態３として説明する。図８はパッケージの縮小処理判定部を備えるアプリケーション管理フレームワーク２０３の構成を示す図である。
【００４９】
縮小処理判定部８０１は、アプリケーション管理フレームワーク２０３が縮小処理を行うかどうかを判定する。判定方法としては、縮小処理をするインストール用ＡＰＩと縮小処理をしないＡＰＩの２種類をアプリケーション管理フレームワーク２０３に備え、システムアプリケーション２０５がいずれのＡＰＩを実行したかに応じて縮小処理をするかしないか判定することが考えられる。
【００５０】
この場合、システムアプリケーション２０５として、ユーザによるインストール指示を受け付けるＵＩを備えるシステムアプリケーションが存在する。ユーザは縮小処理をする、しないを選択して、システムアプリケーション２０５のＵＩからアプリケーション２０４のインストールを指示する。システムアプリケーション２０５はユーザの選択に応じて、上記２つのＡＰＩを使い分ける。
【００５１】
また、インストール用のＡＰＩは一つとし、別途縮小処理をする、しないを設定するＡＰＩを備えることも考えられる。この場合、システムアプリケーション２０５のＵＩは縮小処理を指示するチェックボックスを備え、ユーザによるチェックボックスの選択状態に応じて、アプリケーション管理フレームワーク２０３を設定する。事前に設定することで、ユーザはインストールの指示時に縮小処理の選択を省略し、縮小処理判定部８０１は設定を参照して判定を行う。複数のアプリケーションインストール時に、毎回ユーザに確認するのを省略することができる。
【００５２】
また、ファームアップデートで複数のアプリケーション２０４をインストールする場合に、ユーザが各アプリケーション２０４のインストール操作を行うと効率が悪い。そこで、インストールするアプリケーションの一覧をテキストファイルに記載し、アプリケーション管理フレームワーク２０３がファームアップデート直後にテキストファイルを読み込んで自動でインストールを行う方法がある。テキストファイルにはアプリケーションごとに、縮小処理を実施する、しないが記載される。テキストファイルは、ファーム作成者が手動で作成し、ファームに含める。テキストファイルの記述例としては、図１２が挙げられる。図１２は、自動でインストールするアプリケーション２０４の一覧を記したテキストファイルである。このとき、縮小効果が見込まれるアプリケーション（ａｐｐＢ．ｊａｒ）だけを縮小処理してインストールすることで、自動インストールに要する時間を最も短くすることができる。そこで、テキストファイルにはインストールするアプリケーションごとに、縮小処理を行うかどうかの記載（Ｒｅｄｕｃｔｉｏｎ項目）も記載する。アプリケーション管理フレームワーク２０３は、図１２のテキストファイルを読み込むと、ａｐｐＡ．ｊａｒをファームから読み込んでパッケージ受信部４０３に与える。そして、縮小処理判定部８０１は“Ｒｅｄｕｃｔｉｏｎ＝ｆａｌｓｅ”の記載を参照し、縮小処理を行わないと判定する。ａｐｐＡ．ｊａｒのインストールが終わると、同様に順次ａｐｐＢ．ｊａｒ、ａｐｐＣ．ｊａｒのインストールも行い、自動アップデートは完了する。
【００５３】
以上、想定される縮小処理判定部８０１の具体例について説明した。ここから、インストールの処理の流れについて図９，図１０を用いて説明する。
【００５４】
図９はパッケージの縮小処理をしてインストールしたアプリケーション７０１と、縮小処理をせずにインストールしたアプリケーション９０１のそれぞれのインストール済みパッケージの構成を示す図である。図１０は、アプリケーション管理フレームワーク２０３のインストールの処理の手順を示すフローチャートである。
【００５５】
ステップＳ１００１は、ステップＳ５０１と同様である。インストールの指示を受けると、アプリケーション管理フレームワーク２０３は縮小処理判定部８０１によって縮小処理が必要かを判定する（ステップＳ１００２）。
【００５６】
縮小処理が必要でなければ、インストール用領域４０２にパッケージのストリームをファイルとして書き込み（ステップＳ１００３）、マニフェストを読み込む（ステップ１００４）。そして、マニフェストに展開するｌｉｂが記載されているかを確認し（ステップＳ１００５）、記載されていれば、ステップＳ５０６と同様にｌｉｂを展開する（ステップＳ１００６）。
【００５７】
一方、縮小処理が必要であれば、ステップＳ５０２と同様に、汎用領域４０１に書き込み（ステップＳ１００７）、マニフェストを読み込む（ステップＳ１００８）。そして、マニフェストに展開するｌｉｂが記載されているかを確認し（ステップＳ１００９）、記載されていればステップＳ５０６と同様にｌｉｂを展開する（Ｓ１０１１）。マニフェストにｌｉｂが記載されていない、あるいはステップＳ１０１１が完了すると、ステップＳ５０５と同様にインストール用領域４０２にパッケージを書き込む（ステップＳ１０１０）。
【００５８】
次に、ステップＳ５０７と同様にクラスパス情報を保存する（ステップＳ１０１２）。このときのインストール用領域４０２に書き込まれたファイルは、縮小処理が必要と判定された場合には図９のアプリケーション７０１のようになる。縮小処理が必要と判定されなかった場合には、図９のアプリケーション９０１のようになる。
【００５９】
最後に、ステップＳ５０８と同様に汎用領域４０１のパッケージを削除して（ステップＳ１０１３）、処理は終了する。ただし、縮小処理が必要と判定されなかった場合は、汎用領域４０１には何も書き込まれていないため、ステップＳ１０１３では何も削除しない。
【００６０】
以上、縮小処理判定部８０１を備えるアプリケーション管理フレームワーク２０３のインストール処理について説明した。
【００６１】
＜実施形態４＞
次に、縮小処理判定部８０１を備えるアプリケーション管理フレームワーク２０３が行うアプリケーションのアップデート処理について、図１１を用いて説明する。
【００６２】
アップデート処理が始まるとステップＳ６０１と同様にアップデートするパッケージを受信し（ステップＳ１１０１）する。そして、ステップＳ６０３と同様にインストール済みのパッケージとｌｉｂを汎用領域に退避する（ステップＳ１１０２）。そして、パッケージ縮小処理が必要かを判定する（ステップＳ１１０３）。
【００６３】
縮小処理の必要がないと判定した場合、インストール用領域４０２にパッケージのストリームをファイルとして書き込み（ステップＳ１１０４）、マニフェストを読み込む（ステップ１１０５）。そして、マニフェストに展開するｌｉｂが記載されているかを確認し（ステップＳ１１０６）、記載されていれば、ステップＳ６０７と同様にｌｉｂを展開する（ステップＳ１１０７）。
【００６４】
一方、縮小処理の必要があると判定した場合、ステップＳ６０２と同様に、汎用領域４０１に書き込み（ステップＳ１１０８）、マニフェストを読み込む（ステップＳ１１０９）。そして、マニフェストに展開するｌｉｂが記載されているかを確認し（ステップＳ１１１０）、記載されていれば、ステップＳ６０７と同様にｌｉｂを展開する（ステップＳ１１１２）。ｌｉｂが記載されていない、あるいはステップＳ１１１２で展開が完了すると、ステップＳ６０６と同様に、インストール用領域にパッケージを書き込む（ステップＳ１１１１）。
【００６５】
次に、ステップＳ６０８と同様に、ここまでの処理で例外が発生したかを確認する（ステップＳ１１１３）。そして、例外が発生していなければステップＳ６０９と同様にクラスパス情報を保存する（ステップＳ１１１４）。例外が発生していればステップＳ６１０と同様に退避したパッケージをインストール用領域４０２に戻す（ステップＳ１１１５）。
【００６６】
最後に、ステップＳ６１１と同様に汎用領域のパッケージを削除して（ステップＳ１１１６）、処理は終了する。
【００６７】
以上、縮小処理判定部８０１を備えるアプリケーション管理フレームワーク２０３のアップデート処理について説明した。
【００６８】
＜実施形態５＞
実施形態１において、インストール用領域４０２の空き容量が十分にある場合には、汎用領域４０１を使わずに、インストール用領域４０２に一時ファイルを書き込んでもよい。記憶装置１３がインストール用領域のみを備える場合でも、本発明は実施可能である。記憶装置１３がひとつの領域のみを備える場合のアプリケーション管理フレームワーク２０３の動作について、図１３を用いて説明する。図１３はアプリケーション管理フレームワーク２０３のインストール処理のフローを示す図である。
【００６９】
はじめに、ステップＳ５０１と同様にインストールするパッケージのデータを受信する（ステップＳ１３０１）。そして、ステップＳ５０２と同様に、記憶装置１３にパッケージを書き込む（ステップＳ１３０２）。
【００７０】
ステップＳ１３０３、Ｓ１３０４、Ｓ１３０５、Ｓ１３０６、Ｓ１３０７は、それぞれステップＳ５０３，Ｓ５０４，Ｓ５０５，Ｓ５０６、Ｓ５０７と同様である。
【００７１】
最後に、記憶装置１３に一時ファイルとして書き込んだパッケージを削除し（ステップＳ１３０８）、処理は終了する。
【００７２】
以上、記憶装置１３がひとつの領域のみを備える場合のインストール処理について説明した。
【００７３】
＜実施形態６＞
実施形態１では、ｌｉｂ３０４を重複して保持しないようにしサイズを縮小したパッケージをインストール用領域４０２に書き込む処理を行った。この処理を、縮小処理と称した。
【００７４】
ところで、情報管理装置１０１上に構築するシステム構成は、ファームの更新によって変化する。例えば、縮小処理に未対応の古いアプリケーション管理フレームワーク２０３が搭載された情報管理装置１０１において、アプリケーションＡがインストールされたとする。その後、ファームの更新によって縮小処理に対応した新しいアプリケーション管理フレームワーク２０３が情報管理装置１０１に導入された場合に、インストール済みのアプリケーションＡのサイズは、アップデート・再インストールしないと縮小されない。
【００７５】
このように、縮小処理が未実施のアプリケーションがインストール済みの環境において、縮小処理のみを実施する機能をアプリケーション管理フレームワーク２０３が備えるとする。すると、アプリケーションＡのアップデート・再インストールを行わずにインストール済みアプリケーションのサイズを縮小できる。
【００７６】
アプリケーション管理フレームワーク２０３がインストール済みアプリケーションのサイズを縮小する機能について、図１４、図１５を用いて説明する。図１４はアプリケーション管理フレームワーク２０３が行う縮小処理の手順を示すフローチャートである。図１５は、パッケージの縮小処理指示受信部を備えるアプリケーション管理フレームワーク２０３の構成を示す図である。
【００７７】
システムアプリケーション２０５がアプリケーション管理フレームワーク２０３に縮小対象のアプリケーションを指示し、アプリケーション管理フレームワーク２０３が備える縮小処理指示受信部１５０１が指示を受け取る事で、縮小処理は開始される。ｌｉｂファイルの有無を確認する、ｌｉｂファイルのサイズが一定値を超えているかを確認することで縮小対象のアプリケーションを確認する。縮小処理を指示するＡＰＩをアプリケーション管理フレームワーク２０３が備え、システムアプリケーション２０５が実行する例があげられる。また、縮小処理対象のアプリケーション２０４のリストをシステムアプリケーション２０５が縮小指示ファイルとして作成し、アプリケーション管理フレームワーク２０３が起動時に縮小指示ファイルを読み込む例もありえる。
【００７８】
縮小処理を未実施の場合、インストール済みのアプリケーション９０１は、図９に示したようにインストール済みパッケージ９０１、および展開済みのｌｉｂ９０４として保持されている。
【００７９】
初めに、アプリケーション管理フレームワーク２０３は、縮小対象のインストール済みパッケージ９０１のマニフェスト９０３を読み込む（ステップＳ１４０１）。そしてマニフェスト９０３に展開するｌｉｂ９０４が記載されているかを確認する（ステップＳ１４０２）。記載されていなければ、処理は終了する。
【００８０】
マニフェストに展開するｌｉｂ９０４が記載されていれば、ｌｉｂ９０４がインストール済みパッケージ９０１に含まれているかを確認する（ステップＳ１４０３）。含まれていなければ、処理は終了する。
【００８１】
ｌｉｂ９０４がインストール済みパッケージ９０１に含まれていれば、汎用領域４０１にインストール済みパッケージ９０１を移動（Ｓ１４０４）する。そして、移動したパッケージを参照して、ｌｉｂ９０４が除かれたパッケージとしてインストール用領域４０２に書き込み（Ｓ１４０５）、処理は終了する。
【００８２】
以上、縮小処理に未対応のアプリケーション管理フレームワーク２０３が搭載されていた情報管理装置１０１がファームのアップデートによって縮小処理に対応するようになった場合のための、縮小処理実行手順について説明した。
【００８３】
＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００８４】
また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコード（コンピュータプログラム）を記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。係る記憶媒体は言うまでもなく、コンピュータ読み取り可能な記憶媒体である。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【図１】
2014146277.tif 000003
【図２】
2014146277.tif 000004
【図３】
2014146277.tif 000005
【図４】
2014146277.tif 000006
【図５】
2014146277.tif 000007
【図６】
2014146277.tif 000008
【図７】
2014146277.tif 000009
【図８】
2014146277.tif 000010
【図９】
2014146277.tif 000011
【図１０】
2014146277.tif 000012
【図１１】
2014146277.tif 000013
【図１２】
2014146277.tif 000014
【図１３】
2014146277.tif 000015
【図１４】
2014146277.tif 000016
【図１５】
2014146277.tif 000017