アプリケーション実行装置
【課題】アプリケーションを構成するファイルをパッケージ化する場合、アイコンイメージ等アプリケーション実行時には利用されないファイルも含まれてしまうため、アプリケーション実行に要するメモリに無駄が生じていた。
【解決手段】アプリケーション実行時に使用されないファイルをパッケージ化されたアプリケーションより分離することにより、パッケージ化されたアプリケーションのサイズを縮小し、アプリケーション実行に要するメモリ使用量を削減する。また、分離されたアイコンイメージ等を使用する実行可能アプリケーション一覧表示等の表示処理を高速化する。
【解決手段】アプリケーション実行時に使用されないファイルをパッケージ化されたアプリケーションより分離することにより、パッケージ化されたアプリケーションのサイズを縮小し、アプリケーション実行に要するメモリ使用量を削減する。また、分離されたアイコンイメージ等を使用する実行可能アプリケーション一覧表示等の表示処理を高速化する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モジュールファイル群及びリソースファイル群をパッケージングしたファイル（例えばＪＡＲファイルなど）であるパッケージ化アプリをメモリに記憶し、実行することが可能な情報端末において、パッケージ化アプリの実行に利用されない、または利用頻度の低いファイルをメモリへ記憶する前に分離するアプリケーション実行装置に関する。
【背景技術】
【０００２】
近年、携帯電話に代表される、通信機能を有し、持ち運びが可能な情報端末は、アプリケーションをネットワーク経由にてダウンロードし、保存し、実行する機能が広く採用されている。旧来の情報端末においては、ユーザは情報端末の出荷時に搭載されたアプリケーションのみ利用が可能であったが、本機能により、ユーザはユーザ自身で必要なアプリケーションをインターネット上のダウンロードサイト等にて検索し、ダウンロードし、情報端末へ保存して、実行することが可能となった。
【０００３】
上記情報端末におけるダウンロードアプリケーションの実行環境として、Ｊａｖａ（登録商標）が広く採用されている。Ｊａｖａ（登録商標）採用の理由としては、アプリケーションプログラムの実行環境としてのＪａｖａ（登録商標）の特徴である、プラットフォーム非依存性、豊富なクラスライブラリ、セキュアな実行環境等が挙げられるが、その他の大きな特徴して統一されたアプリケーションの配布形態も挙げられる。
【０００４】
Ｊａｖａ（登録商標）の実行環境であるＪＲＥ（クラスライブラリ、Ｊａｖａ（登録商標）ＶＭ（Ｊａｖａ（登録商標）言語にて記述されたアプリケーションを実行するためのソフトウェア）、及びＪＲＥを搭載する端末固有のポーティングレイヤ、より構成される）は、ＪＡＲファイルを入力として受け取り、これをＪａｖａ（登録商標）ヒープと呼ばれるＲＡＭ上に確保された一時記憶領域へ格納し、格納されたＪＡＲファイルより実行に必要なクラスファイル（Ｊａｖａ（登録商標）言語で記述されたソースコードをＪａｖａ（登録商標）コンパイラでコンパイルすることで生成されるプログラムモジュール）を抽出してＪａｖａ（登録商標）ヒープ上へ格納し、実行することが出来る。ＪＡＲファイルとは、クラスファイル及びＪａｖａ（登録商標）アプリ実行過程で使用する様々なリソースファイル（ＧＩＦイメージファイル、ＭＩＤＩファイル、テキストファイル等）を、ＪＡＲ形式でパッケージ化したファイルである。
【０００５】
このようにＪａｖａ（登録商標）アプリ実行に係るファイル群をパッケージ化するメリットとしては、（Ａ）ネットワーク経由でのＪａｖａ（登録商標）アプリ配布が容易であること、（Ｂ）ネットワーク経由でダウンロードしたＪａｖａ（登録商標）アプリを情報端末にて保持・管理することが容易であること、が挙げられる。特に携帯電話のように通信が課金され、データを格納するための不揮発記憶領域（ＦｌａｓｈＲＯＭ等）のサイズ制限が厳しい情報端末においては、通信回数の削減や、ダウンロード前にＪａｖａ（登録商標）アプリを端末に保存するために要する不揮発記憶領域のサイズを正確に見積もることが可能である点から、本配布形態により享受できるメリットは大きい。
【０００６】
なお、ＪＡＲファイルには、Ｊａｖａ（登録商標）アプリの実行に直接関係しないファイルも含まれることが多い。このようなファイル一例として、アイコンファイルが挙げられる。アイコンファイルは、Ｊａｖａ（登録商標）アプリ実行時ではなく、ユーザがダウンロードしたＪａｖａ（登録商標）アプリ一覧より実行するＪａｖａ（登録商標）アプリを選択するためのＵＩ（以下アプリラウンチャ）をグラフィカル化する目的で使用される。ここでグラフィカル化とは、Ｊａｖａ（登録商標）アプリ一覧表示における各項目の表示内容を、旧来のアプリ名のみから、アプリ名とアイコンの組み合わせとすることを示す。
【０００７】
アイコンの表示を伴う場合、各項目に係るアプリのＪＡＲ形式にパッケージ化されたファイルよりアイコンファイルを読込む必要がある。しかし、ＪＡＲ形式にパッケージ化されたファイルよりクラスファイルやリソースファイルを読込むためには、読込み対象となるファイルの位置を特定し、データの展開（データが圧縮されている場合に限定されるが、ＪＡＲファイルサイズ削減の要請から、圧縮されている場合が多い）を実施する必要があるため、通常のファイル読込みと比較して多くの時間を要する。
【０００８】
このため、処理能力があまり高くない携帯電話のような情報端末においては、ＪＡＲ形式ファイルからのファイル読込みに要する時間が他の処理を圧迫し、結果として、キーレスポンス低下といったユーザビリティに直結するような性能の悪化が生じてしまっていた。
【０００９】
このような問題を改善する技術として、コンテンツよりアイコン情報等を元にインデックス用ファイルを事前に作成しておき、コンテンツ一覧表示時には、本ファイルに基づいて表示処理を高速化する技術（例えば特許文献１参照）、がある。
【特許文献１】特開２００５−１４１５９６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記技術の場合、コンテンツ内に含まれるアイコン情報等と、インデックス用ファイルで同用途のファイルの二重持ちが発生する。ＰＣ等のように不揮発記憶領域（ＨＤＤ）の容量の制限が緩いものについては、特段問題は生じないが、携帯電話等のモバイル機器については、コスト等の要請から不揮発記憶領域であるＦｌａｓｈＲＯＭの使用容量制限が大きく、このようなファイルの二重持ち状態は許容できるものではない。
【００１１】
また、不揮発記憶領域のみならず、ＲＡＭ等の一時記憶領域についても同様に厳しい制限が課せられている。現状Ｊａｖａ（登録商標）アプリの実行エンジンであるＪａｖａ（登録商標）ＶＭは、ＪＡＲファイルを携帯端末の不揮発記憶領域から読込み、Ｊａｖａ（登録商標）ＶＭが専有する一時記憶領域であるＪａｖａ（登録商標）ヒープへコピーする。さらにＪａｖａ（登録商標）ＶＭはアプリの実行に必要となるクラスファイルやイメージ等のリソースファイルをＪＡＲより抽出し、Ｊａｖａ（登録商標）ヒープへコピーして使用する。このようなＪａｖａ（登録商標）ＶＭの実行形態は、アプリ実行中頻繁にアクセスが発生するファイル群からなるＪＡＲファイルを一時記憶領域であるＪａｖａ（登録商標）ヒープへキャッシュしておくこととなるから、処理能力の乏しい携帯電話等の情報端末においては有利なものである。一方、ＪＡＲ内にアプリ実行時に殆ど使用されないファイルが含まれている場合は、Ｊａｖａ（登録商標）ヒープを浪費してしまい、一時記憶領域を使用する他のアプリケーションや、アプリ自身の実行動作へ悪影響を及ぼすこととなる。
【課題を解決するための手段】
【００１２】
本発明のアプリケーション実行装置は、モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能なものであって、前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたものである。
【発明の効果】
【００１３】
本発明のアプリケーション実行装置は、モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能な情報端末において、前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたので、前記パッケージ化アプリを実行するとき、実行中に使用されないファイルはアプリ実行部の一時記憶部に格納されなくなり、一時記憶部の記憶容量を必要以上に圧迫することがなくなる。これは、例えばアプリ実行部が複数のパッケージ化アプリを同時・並列に実行するような場合において非常に有用である。実行中に一時記憶部に占める領域を削減することにより、他のパッケージ化アプリ、ファイルにこの削減により空けることが可能になった一時記憶部の領域を割り当てることが可能となる。これにより、並行して起動できるパッケージ化アプリの最大数を増加できるといった効果が期待できる。
【００１４】
また、前記パッケージ化アプリは、前記モジュールファイル群またはリソースファイル群に含まれる各ファイル対して、前記各ファイルの格納位置、サイズに関するファイルヘッダ情報を含み、前記ファイルヘッダ情報に示された格納位置に基づいて前記モジュールファイル群およびリソースファイル群に含まれる各ファイルが格納されており、前記ファイル分離部により前記パッケージ化アプリからファイルを分離する場合、分離する対象のファイルおよび前記分離する対象のファイルに対応するファイルヘッダ情報を削除し、前記分離対象のファイルの削除により空けられた領域を詰めるように、前記削除したファイルに後続するファイルを再配置するとともに、前記再配置により格納位置が変化したファイルに対応するファイルヘッダ情報に含まれる格納位置を更新することにより、分離したパッケージ化アプリを生成するようにすれば、前記分離されたパッケージ化アプリのサイズを小さくすることができるので、実行するとき、アプリ実行部の一時記憶部に格納されるパッケージ化アプリのサイズを小さくできるので、一時記憶部の記憶容量を必要以上に圧迫することがなくなる。
【００１５】
また、前記ファイル使用情報更新部により作成されるファイル使用情報は、前記パッケージ化アプリを実行した回数と、前記パッケージ化アプリに含まれる各ファイルを特定する情報、前記パッケージ化アプリを実行するために前記特定した各ファイルを、前記一時記憶部に格納できる最大回数と、前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数とを含むものであって、前記ファイル使用情報更新部は、更に前記パッケージ化アプリを実行する毎に、対応するファイル使用情報に含まれる、前記パッケージ化アプリを実行した回数および前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するようにすれば、アプリケーション実行装置は、パッケージ化アプリに含まれるファイルの使用回数を特定できるようになる。
【００１６】
また、前記判定部は、前記パッケージ化アプリを実行した回数が所定の回数となる毎に、前記一時記憶部に実行可能なデータ形式となるようにして格納した回数が所定の回数よりも少ないファイルを前記パッケージ化アプリの実行中に使用されないファイルとみなす判定をし、前記ファイル分離部は、前記実行中に使用されないファイルが分離されたパッケージ化アプリから更に前記使用されないとみなしたファイルを分離するようにすれば、パッケージ化アプリを繰り返し、実行したとき、実行時において利用頻度の少ないファイルを分離できるようになるので、実行時において、アプリ実行部の一時記憶部に格納されるパッケージ化アプリのサイズをより小さくすることが可能となり、一時記憶部の記憶容量を更に圧迫することがなくなる。
【００１７】
また、前記ファイル分離部は、分離したファイルを示す復元情報を生成し、前記データ記憶部に記憶するとともに、前記アプリケーション実行装置は、前記復元情報を用いて分離したファイルを復元する復元部を更に備えるようにすれば、パッケージ化アプリをファイルが分離される前の状態に戻すことが可能となる。例えばファイルが分離されたパッケージ化アプリに異常が発生したとしても、ファイルが分離される前の状態に戻せば、異常の発生を回避することが可能となる場合などには有用である。
【００１８】
また、前記ファイル分離部により生成される復元情報は前記パッケージ化アプリから分離したファイルを特定する情報および前記特定したファイルが格納されている前記データ記憶部の格納位置を示す情報を含み、前記アプリ実行部により実行されるパッケージ化アプリが、既に分離され前記一時記憶部には格納されていないファイルの実行を要求する場合、前記分離されたファイルが格納されている前記データ記憶部の格納位置を示す情報を用いて、前記分離されたファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納するようにすれば、パッケージ化アプリの実行において、既に分離がされ、一時記憶部に格納されていないファイルへのアクセスを要求する場合であっても、該当するファイルを一時記憶部へ格納し、実行可能なデータ形式となるように変換して前記一時記憶部の記憶領域へ展開し、実行することが可能となる。
【００１９】
また、前記アプリ実行部は、前記パッケージ化アプリに含まれる各ファイルが、前記一時記憶部に格納された前記パッケージ化アプリに含まれる各ファイルへのアクセスが前記アプリ実行部により実行されるパッケージ化アプリの実行中になされたかどうかを示すファイルアクセス関しテーブルを保持し、ファイルアクセス関しテーブルに基づいて、前記ファイル使用情報に含まれる該当するファイルについて、実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するよう、前記ファイル使用情報更新部に指示するように構成すれば、各ファイルの使用回数を特定することが可能となる。
【００２０】
また、前記アプリケーション実行装置は、更に前記データ記憶部に記憶したパッケージ化アプリを削除する削除手段を備え、前記削除手段は、前記データ記憶部に記憶したパッケージ化アプリを削除する場合、前記分離したパッケージ化アプリおよび前記分離したファイルを削除するように構成すれば、ファイルの分離がなされたパッケージ化アプリを削除する場合、分離されたファイルをも一括して削除することが可能となり、パッケージ化アプリを利用する利用者は分離されたファイルを意識することなく、パッケージ化アプリの削除を行なうことが可能となるばかりか、パッケージ化アプリを削除した後に、このパッケージ化アプリに関連する分離したファイルが、データ記憶部に削除されることなく残っているという状態を回避できるため、データ記憶部を不必要に圧迫するということがなくなる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明が適用された実施の形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２２】
具体的には、以下では、パッケージ化アプリであるＪＡＲファイルをダウンロードし、ＦｌａｓｈＲＯＭ等の不揮発記憶領域へ保存し、これを実行することが可能なアプリケーション実行装置であるＪＲＥにおける一例を示すが、例えばＢＲＥＷ（Ｒ）のような、他のパッケージ化アプリをダウンロードし、不揮発領域へ保存し、実行することが可能なアプリケーション実行装置についても、本発明は適用可能である。
【００２３】
（実施の形態１）
図１は本実施の形態のアプリケーション実行装置を説明するための図である。
【００２４】
図１において、１０００はアプリケーション実行装置である。アプリケーション実行装置１０００は、アプリファイル管理部１１００、データ記憶部１２００、アプリ実行部１３００、一覧表示処理部１４００、キー入力部１５００を備える。
【００２５】
アプリファイル管理部１１００は、アプリ取得部１１０１、アプリ分離部１１１０、ファイル復元部１１２０、アプリ削除部１１３０を備える。また、アプリ分離部１１１０はファイル使用情報更新部１１１１、ファイル分離判定部１１１２、ファイル分離部１１１３を備える。
【００２６】
データ記憶部１２００は、アプリ記憶部１２１０、分離ファイル情報部１２２０を備える。また、分離ファイル情報部１２２０は更にファイル使用情報部１２２１、分離ファイル部１２２２を備える。
【００２７】
アプリ実行部１３００はアプリ起動処理部１３１０、アプリ実行エンジン１３２０、ファイルアクセス部１３３０、ファイルアクセス監視部１３４０を備える。また、アプリ実行エンジン１３２０は一時記憶部１３２１を備え、一時記憶部１３２１はパッケージ化アプリ部１３２２、アプリ記述ファイル部１３２３、モジュール部１３２４を備える。ファイルアクセス部１３３０は分離ファイル情報アクセス部１３３１を備え分離ファイル情報アクセス部１３３１は更に分離ファイル情報テーブル１３３２を備える。ファイルアクセス監視部１３４０は更にファイルアクセス監視テーブル１３４１を備える。
【００２８】
一覧表示処理部１４００はユーザ入力受付部１４１０、アプリ起動要求部１４２０、一覧表示部１４３０を備える。
【００２９】
図１において、データ記憶部１２００内のアプリ記憶部１２１０に格納されたパッケージ化アプリ及び本パッケージ化アプリに係るアプリ記述ファイルに基づき、アプリ分離部１１１０にてパッケージ化アプリが含むアイコンファイル（アプリ記述ファイルの内容に基づき静的にパッケージ化アプリに係るアプリの実行に利用されない旨を判定可能なファイル）をパッケージ化アプリより分離する際の処理手順について説明する。
【００３０】
なお、アイコンファイルは静的にパッケージ化アプリに係るアプリの実行時に利用されない旨を判定可能なファイルの一例であり、これをアイコンファイルに限定するものではなく、アイコンファイル以外のファイルであってパッケージ化アプリに係るアプリの実行時に利用されないファイルに対しても適用が可能である。
【００３１】
図２は、本実施の形態におけるパッケージ化アプリ及び、アプリ記述ファイルの一例を説明するための図である。
【００３２】
図２において、パッケージ化アプリ２１００は、アプリケーションの実行に必要なプログラムモジュールに関するファイルに係るデータであるファイルエントリ群２１２０及びアプリケーションの実行過程においてプログラムモジュールが利用するリソースファイルに係るデータであるファイルエントリ群２１３０をパッケージ化し、１ファイルとしたものを含む。
【００３３】
図２の説明においては、ファイルエントリ群２１２０はプログラムモジュール１に対応するファイルエントリ１、プログラムモジュール２に対応するファイルエントリ２、プログラムモジュール３に対応するファイルエントリ３、．．．プログラムモジュール（Ｎ−１）に対応するファイルエントリ（Ｎ−１）を有するものする。
【００３４】
また、ファイルエントリ群２１３０はリソースデータ１に対応するファイルエントリＮ、リソースデータ２に対応するファイルエントリＮ＋１、リソースデータ２に対応するファイルエントリＮ＋２、．．．を有するものとする。
【００３５】
なおパッケージ化アプリ２１００には、さらにパッケージ化アプリ内の各ファイルエントリを抽出するためのファイルエントリ管理情報２１４０、及びヘッダ情報２１１０が必要に応じて含まれている。図２においては、パッケージ化アプリ２１００にファイルエントリ管理情報２１４０、及びヘッダ情報２１１０を含んでいるものを例に説明をする。
【００３６】
このファイルエントリ管理情報２１４０とは、パッケージ化アプリ２１００に含まれる各ファイルエントリに対応するファイルエントリファイルヘッダ２１４１の集合である。
【００３７】
ファイルエントリ１に対応するファイルエントリ１ファイルヘッダ２１４１を例にファイルエントリファイルヘッダの構成を説明する。ファイルエントリファイルヘッダは、Ｏｆｆｓｅｔ（２１４２）、Ｌｅｎｇｔｈ（２１４３）、Ｎａｍｅ（２１４４）等の情報を含む。
【００３８】
Ｏｆｆｓｅｔ（２１４２）は、パッケージ化アプリ内におけるファイルエントリ１の位置である。Ｌｅｎｇｔｈ（２１４３）はファイルエントリ１のサイズである。Ｎａｍｅ（２１４４）は、ファイルエントリ１のファイル名である。
【００３９】
Ｏｆｆｓｅｔ（２１４２）には例えばパッケージ化アプリ２１００に含まれる最初のファイル（この例ではヘッダ情報）の先頭位置から数えて何バイト目にあるかに関する情報を格納する。また他のファイルエントリに対応するファイルエントリヘッダ（ファイルエントリ２ファイルヘッダ、ファイルエントリ３ファイルヘッダ、．．．ファイルエントリｉファイルヘッダ（ｉ：整数））については、上述のファイルエントリ１ファイルヘッダ２１４１の説明において、ファイルエントリ１を対応するファイルエントリの番号に読み替えればよく、ファイルエントリ１ファイルヘッダ２１４１と同様のデータ構造を有するものである。
【００４０】
パッケージ化アプリから特定のファイルを抽出する場合は、抽出したいファイルのファイル名と、ファイル名“Ｎａｍｅ”の値が一致するファイルエントリファイルヘッダを探し出し、見つかったファイルエントリファイルヘッダのＯｆｆｓｅｔ及びＬｅｎｇｔｈに基づいてファイルエントリの位置・範囲を特定して、対応するファイルエントリを取り出し、且ファイルエントリが圧縮されている場合は適当な解凍手段（図示せず）によって解凍する、という手順が必要となる。
【００４１】
アプリ記述ファイル２２００は、アプリ実行時に最初に必要となるプログラムモジュールに関する情報２２０１や、アプリラウンチャ等においてアプリ名一覧と共に表示されるアプリの属性情報を記述するためのファイルである。
【００４２】
アプリの属性情報とは、例えばアイコンに関する情報２２０２といったようなものである。なお、アプリラウンチャの詳細については実施の形態６にて後述する。
【００４３】
図３は、図２に示したパッケージ化アプリ２１００、アプリ記述ファイル２２００をより具体的にしたものの一例を示す図であり、アプリケーションをＪａｖａ（登録商標）アプリケーションとしたときのパッケージ化アプリファイルとして、ＪＡＲファイル（この例では、Ｇａｍｅ．ｊａｒ（３１００））及び、ＪＡＲファイルに係るアプリ記述ファイルとしてＡＤＦファイル（この例では、Ｇａｍｅ．ａｄｆ（３２００））の例を示す図である。
【００４４】
ＪＡＲファイルの一例であるＧａｍｅ．ｊａｒ（３１００）は例えば、プログラムモジュールであるクラスファイル（Ｇａｍｅ．ｃｌａｓｓ（３１２１）、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ（３１２２）、Ｍａｉｎ．ｃｌａｓｓ（３１２３）等）、リソースファイルであるＧＩＦファイル（ｇａｍｅ．ｇｉｆ（３１３１）、ｉｃｏｎ．ｇｉｆ（３１３２））、テキストファイル（ｒｅａｄｍｅ．ｔｘｔ（３１３３））等、ヘッダ情報（２１１０）に対応するＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）、及びファイルエントリ管理情報（２１４０）に対応するＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）により構成される。
【００４５】
Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）には、ＪＡＲファイル自体の属性であるファイルサイズ等が格納され、Ｃｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）にはクラスファイル（３１２１、３１２２、３１２３等）や、ＧＩＦファイル（３１３１、３１３２）、テキストファイル３１３３等を取り出すための情報であるファイルヘッダが格納される。
【００４６】
ファイルヘッダ３１４１には、図２において説明したファイルエントリファイルヘッダ２１４１と同様の情報が格納されている。具体例を挙げると、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルヘッダ３１４１には、ＪＡＲファイル３１００の先頭からのＧａｍｅ．ｇｉｆ（３１３１）の位置であるＯｆｆｓｅｔ（３１４２）、Ｇａｍｅ．ｇｉｆ（３１３１）のサイズであるＬｅｎｇｔｈ（３１４３）、Ｇａｍｅ．ｇｉｆ（３１３１）のファイル名であるＮａｍｅ（３１４４）等より構成される。
【００４７】
図３に示す例では、ＪＡＲファイルは、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）、プログラムモジュール（この例では、クラスファイル（Ｇａｍｅ．ｃｌａｓｓ（３１２１）、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ（３１２２）、Ｍａｉｎ．ｃｌａｓｓ（３１２３）等）、リソースファイル（この例では、ＧＩＦファイル（ｇａｍｅ．ｇｉｆ（３１３１）、ｉｃｏｎ．ｇｉｆ（３１３２））、テキストファイル（ｒｅａｄｍｅ．ｔｘｔ（３１３３）等））、ファイルエントリ管理情報部（この例ではプログラムモジュールに含まれる各クラスファイルのファイルヘッダ（Ｇａｍｅ．ｃｌａｓｓファイルヘッダ、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓファイルヘッダ、Ｍａｉｎ．ｃｌａｓｓファイルヘッダ、．．．）、リソースファイルに含まれるファイルのそれぞれに対応するファイルヘッダ（ｇａｍｅ．ｇｉｆファイルヘッダ、ｉｃｏｎ．ｇｉｆファイルヘッダ、ｒｅａｄｍｅ．ｔｘｔファイルヘッダ、．．．）の順に格納されているものとする。
【００４８】
また、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）のファイルサイズはＨｓバイト、クラスファイルを含んだプログラムモジュールのサイズ（プログラムモジュールを構成する各クラスファイルのサイズを総計したもの）はＣｓバイト、リソースファイルに含まれるファイルであるＧａｍｅ．ｇｉｆ（３１３１）のファイルサイズはＲ１ｓバイト、ｉｃｏｎ．ｇｉｆ（３１３２）のファイルサイズはＲ２ｓバイトとする。
【００４９】
このとき、Ｇａｍｅ．ｇｉｆ（３１３１）の前に格納されているＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）およびプログラムモジュールのファイルサイズの総和はＨｓ＋Ｃｓバイト、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルサイズはＲ１ｓバイトであるため、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルヘッダ３１４１のＯｆｆｓｅｔ（３１４２）にはＨｓ＋Ｃｓ、Ｌｅｎｇｔｈ（３１４３）にはＲ１ｓが格納される。
【００５０】
ＡＤＦファイルに対応するＧａｍｅ．ａｄｆ（３２００）は、Ｊａｖａ（登録商標）アプリ実行において最初に実行するメソッドを含むクラスのファイル名を示す情報であるＭａｉｎＣｌａｓｓ（３２０１）及び、アプリラウンチャにおいてアプリ名一覧と共に表示されるアイコンファイルのファイル名を示す情報であるＩｃｏｎＦｉｌｅ（３２０２）等のＡＤＦキーのリストにより構成される。
【００５１】
パッケージ化アプリ及びアプリ記述ファイルは、アプリケーション実行装置１０００のアプリ取得部１１０１によって外部サーバ等よりインターネット等を経由して取得され、データ記憶部１２００内の記憶領域であるアプリ記憶部１２１０に格納される。
【００５２】
図４は、図１に示すデータ記憶部１２００に記憶されるデータの具体的一例を説明するための図である。データ記憶部１２００は、例えばＦｌａｓｈＲＯＭ等の不揮発記憶領域上に構成されたファイルシステムを格納するための記憶領域である。データ記憶部１２００は例えば階層構造を用いてデータを格納しており、この例ではアプリ記憶部１２１０は“ｈｏｍｅ”フォルダの中にある“ｊａｖａ”フォルダの中の“ａｐｐ”フォルダ内（またはルートディレクトリから「／ｈｏｍｅ／ｊａｖａ／ａｐｐ」にて示されるディレクトリの配下）の記憶領域に対応する。
【００５３】
図４においては、アプリ取得部１１０１によって、取得されたＪａｖａ（登録商標）アプリＧａｍｅに対応するＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）は、アプリ記憶部１２１０における“ａｐｐ”フォルダの中にＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）を格納した例を示している。
【００５４】
上記の手順等によってアプリ記憶部１２１０にパッケージ化アプリ、アプリ記述ファイルが格納された後、アプリ分離部１１１０は、ファイル使用情報更新部１１１１、ファイル分離判定部１１１２、ファイル分離部１１１３の協調動作により、アイコンファイル等、当該パッケージ化アプリに含まれるファイル群のうちアプリ実行中に使用されないまたは使用頻度の低いファイルの分離を行う。図５は本ファイルの分離に関する具体的な処理手順を示すフローチャートである。
【００５５】
ここでは、図５のフローチャートを参照しながら、上記Ｇａｍｅ．ｊａｒ（３１００）、及びＧａｍｅ．ａｄｆ（３２００）より構成されるＪａｖａ（登録商標）アプリＧａｍｅを構成するファイルを分離する処理手順の一例を示す。
【００５６】
（１）ファイル使用情報の生成
ファイル使用情報更新部１１１１は、アプリ記憶部１２１０に格納されたパッケージ化アプリ（本実施の形態では、ＪＡＲファイル）及び当該パッケージ化アプリに係るアプリ記述ファイル（本実施の形態では、ＡＤＦファイル）を含むＪａｖａ（登録商標）アプリを用いて、当該パッケージ化アプリに係るファイル使用情報の生成を行う。
【００５７】
具体的には、上記アプリ取得部１１０１は、ＪＡＲファイルに対応するＧａｍｅ．ｊａｒ（３１００）及びＡＤＦファイルに対応するＧａｍｅ．ａｄｆ（３２００）をアプリ記憶部１２１０へ格納後、ファイル使用情報更新部１１１１へファイル使用情報に対応するＧａｍｅ．ｄａｔの生成を要求する。
【００５８】
図６は、ファイル使用情報の一例を説明するための図である。図６において、ファイル使用情報６１００は、パッケージ化アプリの実行過程において、実行過程のパッケージ化アプリを構成する各ファイルに関する情報を含み、共通情報６１１０と、各ファイルに対応する使用情報を有する。
【００５９】
共通情報６１１０には、パッケージ化アプリがアプリ実行エンジン１３２０において起動され、実行された回数であるアプリ起動回数６１１１を有する。パッケージ化アプリに含まれるファイル使用情報には、ファイル名６１２１、アプリ実行時最大使用回数６１２２、及びアプリ実行時使用回数累計６１２３を有する。
【００６０】
使用情報６１２０におけるファイル名６１２１は該当するファイルのファイル名を示す。アプリ実行時最大使用回数６１２２は、当該アプリがそのファイルを最大何度まで使用できるかを示す。具体的には、本値が０であれば、ファイル名６１２１に係るファイルは一度も当該アプリから使用されないことを示すものであり、本値が１であれば、ファイル名６１２１に係るファイルは一度だけ当該アプリから使用されることを示す。アプリ実行時使用回数累計６１２３は、当該アプリがアプリ実行エンジン１３２０における実行過程において、ファイル名６１２１に係るファイルへ実際にアクセスを行った回数の累計を示す。
【００６１】
図６に示す例では、ｉｃｏｎ．ｇｉｆにおけるアプリ実行時最大使用回数６１２２（ＭａｘＣｏｕｎｔ）は０である。これはアプリ実行時においてｉｃｏｎ．ｇｉｆが利用されないことを示す。
【００６２】
次に、ファイル使用情報の生成処理手順の詳細について説明する。図５においてステップ（Ｓ５００１）〜ステップ（Ｓ５００５）までは、主としてファイル使用情報更新部１１１１の動作、ステップ（Ｓ５１０１）〜ステップ（Ｓ５１０２）は主としてファイル分離判定部１１１２による動作、ステップ（Ｓ５２０１）〜ステップ（Ｓ５２０７）は主としてファイル分離部１１１３の動作に相当する。
【００６３】
まず、アプリ取得部１１０１よりファイル使用情報生成要求を受け取ると、ファイル使用情報更新部１１１１は、ファイル使用情報生成の対象のアプリに係るファイル使用情報が既にファイル使用情報部１２２１に格納済みであるかを確認する（Ｓ５００１）。
【００６４】
ステップ（Ｓ５００１）において格納済みでないことを確認した場合（例えば、ダウンロード直後のアプリといったような場合など）、ファイル使用情報更新部１１１１は、当該アプリに係るデフォルトとなるファイル使用情報の生成を試み、データ記憶部へ格納する（Ｓ５００２）。
【００６５】
ステップ（Ｓ５００１）において格納済みであることを確認した場合には、ステップ（Ｓ５００３）へ進む。
【００６６】
ステップ（Ｓ５００３）では、データ記憶部１２００からファイル使用情報を読み込んで取得する。
【００６７】
デフォルトのファイル使用情報は、パッケージ化アプリ及びアプリ記述ファイルに基づいて生成される。
【００６８】
図７は、Ｊａｖａ（登録商標）アプリＧａｍｅに係るＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）を用いてＪａｖａ（登録商標）アプリＧａｍｅ（３１００）に含まれるアプリの実行中に利用することのないファイル（この例では、ｉｃｏｎ．ｇｉｆ）を分離するために生成するファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を説明するための図である。図において、Ｇａｍｅ．ｄａｔ（７３００）は、アプリの起動回数であるＬａｕｎｃｈｅｄＣｏｕｎｔ（７３０１）及び、Ｇａｍｅ．ｊａｒ（３１００）に含まれるファイル毎の使用情報を有する。また各ファイルの使用情報は、ファイル名であるＮａｍｅ、アプリ実行時最大使用回数であるＭａｘＣｏｕｎｔ、アプリ実行時使用回数累計であるＣｏｕｎｔを含む。
【００６９】
例えばファイル“Ｇａｍｅ．ｃｌａｓｓ”の使用情報７３１０の場合、ファイル名であるＮａｍｅ（７３１１）の値には、“Ｇａｍｅ．ｃｌａｓｓ”、アプリ実行時最大使用回数であるＭａｘＣｏｕｎｔ（７３１２）の値には−１、アプリ実行時使用回数累計であるＣｏｕｎｔ（７３１３）の値には０であることを示している。
【００７０】
図７は、Ｇａｍｅ．ｊａｒ（３１００）とＧａｍｅ．ａｄｆ（３２００）を用いてデフォルトのファイル使用情報Ｇａｍｅ．ｄａｔ（７３００）を生成する具体的例を説明するための図である。
【００７１】
（処理１） ファイル使用情報Ｇａｍｅ．ｄａｔ（７３００）に含まれるＬａｕｎｃｈＣｏｕｎｔの値に０が設定される。
【００７２】
（処理２） Ｇａｍｅ．ｊａｒ（３１００）のＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）の先頭のファイルヘッダ（この例ではＧａｍｅ．ｃｌａｓｓファイルヘッダ）から順に１つずつファイルヘッダを取り出し、取り出したファイルヘッダ毎に以下の処理を行う。なお、以下の処理は、Ｃｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）に含まれる全てのファイルヘッダに対して行われる。
【００７３】
（処理３） （処理２）で取り出したファイルヘッダのＮａｍｅ情報と、Ｇａｍｅ．ａｄｆ（３２００）に含まれるファイルのうち、アプリラウンチャにおいてアプリ名一覧と共に表示されるアイコンファイルのファイル名を示す情報（つまりｉｃｏｎ．ｇｉｆ））が一致しない場合は、該当するファイルヘッダに対応するファイルに対する使用情報として、Ｎａｍｅ＝ファイルヘッダに含まれるＮａｍｅ情報、ＭａｘＣｏｕｎｔ＝−１、Ｃｏｕｎｔ＝０を生成し、Ｇａｍｅ．ｄａｔ（７３００）の末尾に追加する。なお、ＭａｘＣｏｕｎｔの値が−１の場合は、使用情報のＮａｍｅの値であるファイル名に該当するファイルについては、使用回数の上限は無いことを示すものとする。本例においては、後述する（処理４）にて示すｉｃｏｎ．ｇｉｆを除く全てのＧａｍｅ．ｊａｒが含むファイルについては、本初期化処理を行うこととなる（例えばＧａｍｅ．ｃｌａｓｓの使用情報７３１０）。
【００７４】
（処理４） （処理２）で取り出したファイルヘッダのＮａｍｅ情報と、Ｇａｍｅ．ａｄｆ（３２００）に含まれるアイコンファイルのファイル名を示す情報（つまりｉｃｏｎ．ｇｉｆ）が一致する場合は、該当するファイルヘッダに対応するファイルに対する使用情報として、Ｎａｍｅ＝ファイルヘッダに含まれるＮａｍｅ情報、ＭａｘＣｏｕｎｔ＝０、Ｃｏｕｎｔ＝０を生成し、Ｇａｍｅ．ｄａｔ（７３００）の末尾に追加する。ＭａｘＣｏｕｎｔの値を０とするのは、当該ファイルがＪａｖａ（登録商標）アプリＧａｍｅの実行過程で一度も使用されないファイルであることを示すためである。アイコンファイルは、アプリ実行時ではなくアプリラウンチャの一覧表示のグラフィカル化を目的として使用されるものであるため、このような処理としている。本実施の形態においては、（処理２）で取り出したファイルヘッダが、ｉｃｏｎ．ｇｉｆファイルヘッダの場合は、（処理４）を行うこととなる。
【００７５】
Ｇａｍｅ．ｊａｒ（３１００）とＧａｍｅ．ａｄｆ（３２００）を用いて、(処理１)〜（処理４）を適用すると、ｉｃｏｎ．ｇｉｆファイルヘッダについてのみ、（処理４）がなされ、ｉｃｏｎ．ｇｉｆファイルヘッダに対応するファイル使用情報７３２０に含まれるＮａｍｅの値は“ｉｃｏｎ．ｇｉｆ”、ＭａｘＣｏｕｎｔの値は０、Ｃｏｕｎｔの値は０となり、ｉｃｏｎ．ｇｉｆファイルヘッダ以外のファイルヘッダには（処理３）が適用される（図７参照）。
【００７６】
なおアイコンファイル以外にも、アプリ実行中に使用しないファイル名をＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））に定義し、定義したファイル名に対し（処理１）〜（処理４）の手順を適用すればアプリ実行中に利用しないファイルについて、ＭａｘＣｏｕｎｔの値を０としたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を生成することが可能となる。
【００７７】
（２）分離対象ファイル名リストの生成
次にファイル使用情報更新部１１１１は、ファイル分離判定部１１１２へパッケージ化アプリ及び当該パッケージ化アプリのアプリ記述ファイルを引数として、ファイル分離の実施を要求する（Ｓ５００５）。
【００７８】
ファイル分離実施の要求を受けたファイル分離判定部１１１２は、ファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を用いて分離対象ファイルを決定し、分離対象ファイルのファイル名リストを生成し（ステップＳ５１０１）、ファイル名リストに列挙するファイルをパッケージ化アプリから分離すため、生成した当該パッケージ化アプリの分離対象ファイル名リストを引数として、ファイル分離部１１１３へファイルの分離を要求する（Ｓ５１０２）。
【００７９】
図８は、ステップ（Ｓ５１０１）において、ファイル使用情報を用いて分離対象ファイルを決定し、分離対象ファイルのファイル名リストを生成する具体例を説明するための図である。
【００８０】
まず、インターバルチェックにより、インターバル定数Ｉに規定の回数（またはその倍数）になった場合には、ファイル分離判定処理を実施し、そうでなければ処理を終了する（Ｓ８００１）。
【００８１】
ファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））のＬａｕｎｃｈｅｄＣｏｕｎｔ（７３０１）の値をインターバル定数であるＩで割り、余りが０の場合のみ、以下の処理（ステップ（Ｓ８００２）〜ステップ（Ｓ８００６））を実行するものとする。ファイル分離判定の要求は、Ｊａｖａ（登録商標）アプリダウンロード時、及びＪａｖａ（登録商標）アプリの実行が終了する度にされるが、ファイル使用情報の内容はＪａｖａ（登録商標）アプリ実行の度に大きく変化するものではないため、Ｊａｖａ（登録商標）アプリダウンロード時、及びインターバル定数Ｉで示されるＪａｖａ（登録商標）アプリ起動回数毎にファイル分離判定を実施するよう、本判定処理を設けている。
【００８２】
本判定処理は、ファイル使用情報に含まれる各ファイルの使用情報ｕｉについて、ファイル分離判定処理を実施する（Ｓ８００２）。
【００８３】
Ｇａｍｅ．ｄａｔ（７３００）に含まれる各ファイルの使用情報を先頭から順に取り出し、取り出したファイルの使用情報ｕｉに含まれるＭａｘｃｏｕｎｔが−１であるか否かを調べ、−１である場合は、後述するステップ（Ｓ８００５）へ進み、そうでない場合は、後述するステップ（Ｓ８００４）へ進む（Ｓ８００３）。
【００８４】
取り出した使用情報に含まれるＣｏｕｎｔの値が取り出した使用情報に対応するファイルの最大使用回数に対応するＭａｘｃｏｕｎｔの値よりも大きいかどうかを調べ（Ｓ８００４）、Ｍａｘｃｏｕｎｔの値以下であれば後述するステップ（Ｓ８００５）へ進み、そうでなければ後述するステップ（Ｓ８００６）へ進む（Ｓ８００４）。
【００８５】
取り出した使用情報に含まれるＣｏｕｎｔの値が所定回数よりも大きいかどうかを調べ（Ｓ８００５）、所定回数以下であれば、後述するステップ（Ｓ８００６）へ進み、所定回数よりも大きければ、次に取り出すべきファイルの使用情報があればこれを取り出して、ステップ（Ｓ８００２）へ戻り、同様の処理を繰り返し、そうでなければ処理を終了する。
【００８６】
ここで、ステップ（Ｓ８００５）においては、所定回数というのを、アプリの起動回数（Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ）に所定定数（分離定数Ｘとも）を乗じた値としている。例えば分離定数Ｘの値を０．１とすると、アプリの起動回数が１０回である場合に、対象となるファイルのアクセス回数が１回以下の（つまり利用頻度の少ないもの）が後述するステップ（Ｓ８００６）へ進むことになる。
【００８７】
次に、ステップ（Ｓ８００４）の判断がＹｅｓ、またはステップ（Ｓ８００５）の判断がＮｏの場合、取り出した使用情報に含まれるＮａｍｅを分離対象ファイル名リストに加えた（ステップＳ８００６）後、次に取り出すべきファイルの使用情報があればこれを取り出して、ステップ（Ｓ８００２）からの処理を繰り返し、次に取り出すべきファイルの使用情報がなければ処理を終了する。
【００８８】
このような処理を行うことにより、分離対象ファイル名リストにはアプリの実行中に利用がなされないファイル、最大使用回数を超えたファイル、利用頻度の低いファイルが加えられるようになる。
【００８９】
この例では、図７に示すファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を用いて分離対象ファイル名リスト９１００を生成した場合、ダウンロード時において図８に示したフローチャートを実行すると、分離対象ファイル名リスト９１００に、ｉｃｏｎ．ｇｉｆのファイル使用情報７３２０に含まれるＮａｍｅ９１０１（ファイル名“ｉｃｏｎ．ｇｉｆ”）が追加され、その後、起動を重ねるに従って、最大使用回数を超えたファイル、利用頻度の低いファイルが加えられるようになる（図９参照）。また、本判定からＭａｘＣｏｕｎｔの値が−１の場合を除いているのは、本値−１は上記の通り、ファイルの最大使用回数を設定しない、すなわちファイルの使用回数の上限がないことを示すものであるためである。
【００９０】
（３）ファイルの分離
分離対象となるパッケージ化アプリ、及び図８（またはステップＳ５１０１）で説明した処理にて生成した当該パッケージ化アプリの分離対象ファイル名リストを引数として、ファイルの分離の要求をファイル分離情報判定部１１１２から受け取ると、ファイル分離部１１１３は、これら引数情報に基づき、分離後のパッケージ化アプリ及び分離されたファイル群より元のパッケージ化アプリを復元するための情報である復元情報を生成する。更に、パッケージ化アプリより当該パッケージ化アプリの分離対象ファイル名リスト９１００で列挙されるファイル名のファイル群を抽出し、パッケージ化アプリより分離対象ファイル名リスト９１００で列挙されるファイル名にて構成されるファイル群のファイルエントリ及びファイルヘッダを削除する。
【００９１】
以下では、図５のシーケンス（特にステップ（Ｓ５２０１）〜ステップ（Ｓ５２０７））に基づき、図１０、図１１、図１２、図１３を用いて上記処理の詳細を説明する。
【００９２】
ファイル分離部１１１３は、ファイル分離情報判定部１１１２からファイル分離の要求を受け取ると、復元情報を生成する（Ｓ５２０１）。
【００９３】
図１０は、パッケージ化アプリに対応するＪＡＲファイル（Ｇａｍｅ．ｊａｒ（３１００））の復元情報の生成を示す。後述の処理を行うことによりＧａｍｅ．ｊａｒ（３１００）からファイルが抽出され、抽出されたファイルに関するファイルエントリがＪＡＲファイルより削除されるが、ＪＡＲファイル（３１００）においては、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）と、抽出されたファイル群があれば元のＪＡＲファイルへの復元可能であることから、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）を含む情報を復元情報とする。
【００９４】
Ｊａｖａ（登録商標）アプリＧａｍｅの復元情報に対応するＧａｍｅ．ｉｎｆｏ（１０２００）は例えば、Ｇａｍｅ．ｊａｒ（３１００）のＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）を取り出し、これらを連結した情報である。
【００９５】
次に、ファイル分離部１１１３は、分離対象ファイル名リストで列挙されたファイル名のファイル群を抽出する（Ｓ５２０２）。
【００９６】
図１１は、ＪＡＲファイルＧａｍｅ．ｊａｒ（３１００）を用いて、ファイル分離判定部１１１２にて生成したＧａｍｅ．ｊａｒ（３１００）の分離対象ファイル名リスト９１００に基づき、分離対象ファイル名リスト９１００に含まれるファイル名９１０１対応するファイルエントリ（図９の例ではｉｃｏｎ．ｇｉｆ（３１３２）等）を抜き出して分離対象ファイル群１１３００を作成し、分離対象ファイル群１１３００を必要に応じて展開して、抽出後ファイル群１１４００を生成する様子を示すものである。ここで展開とは、圧縮化、暗号化されたデータを、解凍、復号することにより、圧縮、暗号化前のデータに復元することである。ＪＡＲファイルにおいては、通常ファイルエントリは、無圧縮、及びＤＥＦＬＡＴＥ圧縮アルゴリズムで圧縮された形態をとる。本実施の形態においては、分離対象ファイル群１１３００のファイルエントリｉｃｏｎ．ｇｉｆ（３１３２）等を、これが無圧縮ならそのまま、ＤＥＦＬＡＴＥ圧縮アルゴリズムにより圧縮されている場合は、そのアルゴリズムに基づいて展開することで、抽出後ファイル群１１４００に含まれるファイルｉｃｏｎ．ｇｉｆ（１１４０１）等を生成することがｉｃｏｎ．ｇｉｆ（１１３０１）等の展開に相当する。なお、ファイルエントリの圧縮形式・暗号化形式は、ＪＡＲのＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに設定されるため、展開はここに設定された圧縮形式・暗号化形式に対応する解凍・復号エンジン（図示せず）によって解凍すればよい。
【００９７】
なお上記抽出されたファイル群をデータ記憶部１２００へ格納する具体的な手段として、図１４では“ｒｅｓｏｕｒｃｅｓ”フォルダの中にファイル毎に格納する手法を例示している。このように構成することにより、アプリラウンチャ等にてパッケージ化アプリに含まれるアイコンを一覧表示する際等において、対応するファイル（“ｒｅｓｏｕｒｃｅｓ”フォルダの中のｉｃｏｎ．ｇｉｆ）の表示処理を高速化することができる。
【００９８】
本実施の形態では、抽出されたファイル群を格納する具体的手段として、上述の記載にのみ限定するものではなく、例えば分離によって生成されたファイル群を連結し１ファイルとして格納することとしてもよい。このような格納手法を採用した場合、ファイルの格納がクラスタ単位で行われるファイルシステムにおいて、データ記憶部１２００（例えばＦｌａｓｈＲＯＭ）の消費量を削減する効果が期待できる。
【００９９】
次に、ファイル分離部１１１３は、分離対象ファイル名リスト９１００を用いて抽出したファイル群及びファイル群に含まれるファイルエントリに対応するファイルヘッダをパッケージ化アプリ（この例ではＧａｍｅ．ｊａｒ（３１００））から削除する（Ｓ５２０３）。
【０１００】
図１２は、Ｇａｍｅ．ｊａｒ（３１００）より、分離対象ファイル名リスト９１００で列挙されるファイル名（ｉｃｏｎ．ｇｉｆ（９１０１）等）に対応するファイルエントリ（ｉｃｏｎ．ｇｉｆ（３１３２））及びこれに対応するファイルヘッダ（ｉｃｏｎ．ｇｉｆファイルヘッダ）を削除し、新たに生成した（または更新した）Ｇａｍｅ．ｊａｒ（１２２００）の一例を示すものである。
【０１０１】
これにより、ステップ（Ｓ５２０３）で抽出されたファイル群、及びファイル群に含まれるファイルエントリに対応するファイルヘッダに関するデータがＪＡＲファイルより削除されるため、ＪＡＲファイルのサイズが縮小される。なお、上記ファイルエントリ１２１０１削除に伴い、更新したパッケージ化アプリに含まれるファイルヘッダに格納するＯｆｆｓｅｔを更新する必要がある。ファイルエントリより後ろに配置されるファイルエントリ群１２１０３に対応するファイルヘッダ１２１０４については、ファイルヘッダの構成情報であるＯｆｆｓｅｔをファイルエントリ削除後の値に更新する必要がある。
【０１０２】
次に、ファイル分離部１１１３は、更新したパッケージ化アプリをアプリ記憶部１２１０へ書き出す前に、復元確認を行う（Ｓ５２０４）。
【０１０３】
更新したパッケージ化アプリをアプリ記憶部１２１０へ書き出すことは、ファイル抽出前のパッケージ化アプリに更新したパッケージ化アプリを上書きすることになるため、その前に復元可能性の確認を行う趣旨による。
【０１０４】
本チェックは、ファイル復元部１１２０によって、パッケージ化アプリや、上記復元情報等を用いて復元を行い、復元後のパッケージ化アプリと元のパッケージ化アプリが完全に一致するかどうかを確認することで実現される。ファイル復元手順の詳細は、実施の形態４を参照願いたい。
【０１０５】
ステップ（Ｓ５２０４）により、ファイル復元可能と判断した場合には、後述するステップ（Ｓ５２０５）〜ステップ（Ｓ５２０７）の処理を実施する。
【０１０６】
まず、データ記憶部１２２０へステップ（Ｓ５２０２）にて、パッケージ化アプリから抽出したファイル群（この例ではｉｃｏｎ．ｇｉｆファイル）を分離ファイル部１２２２（例えば図１４に示す“ｒｅｓｏｕｒｃｅｓ”フォルダ内）の配下に格納する（Ｓ５２０５）。
【０１０７】
次に、ステップ（Ｓ５２０３）にて更新したパッケージ化アプリを更新前のパッケージ化アプリ（例えば図１４に示す“ａｐｐ”フォルダ内）に上書きをする（Ｓ５２０６）。
【０１０８】
次に、パッケージ化アプリより分離されたファイル群を示す分離対象ファイル名リスト９１００に含まれるファイル名より構成される分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））を生成し、分離ファイル部１２２２（例えば図１４に示す“Ｇａｍｅ”フォルダ内）へ書き出す（Ｓ５２０７）。
【０１０９】
なお、既に前回のファイル分離処理実施においてＧａｍｅ．ｌｉｓｔ（１２４００）が生成されている場合、今回の分離処理実施によって新たに分離したファイル群のファイル名を追加し、Ｇａｍｅ．ｌｉｓｔ（１２４００）に上書きすることとする。
【０１１０】
図１３は、本実施の形態にて、Ｊａｖａ（登録商標）アプリＧａｍｅのＪＡＲファイルＧａｍｅ．ｊａｒ（３１００）から更新されたＪａｒファイル（Ｇａｍｅ．ｊａｒ（１２２００））、生成されたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））、生成された復元情報（Ｇａｍｅ．ｉｎｆｏ（１０２００））、生成された分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００）、抽出後ファイル群１１４００の一例を説明するための図である。
【０１１１】
図１４は、上述のファイルを格納するデータ記憶部１２００の一例を示す図である。
【０１１２】
生成されたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））は、ファイル使用情報部１２２１（この例では“ｈｏｍｅ”フォルダの中の“ｊａｖａ”フォルダの中にある“ｉｎｆｏ”フォルダに含まれる“ｕｓｅｉｎｆｏ”フォルダ内（または／ｈｏｍｅ／ｉｎｆｏ／ｕｓｅｉｎｆｏ／配下のデータ領域））に格納される。
【０１１３】
また、生成された復元情報（Ｇａｍｅ．ｉｎｆｏ（１０２００））、は分離ファイル部１２２２（この例では“ｈｏｍｅ”フォルダの中の“ｊａｖａ”フォルダの中にある“ｉｎｆｏ”フォルダに含まれる“ｄａｔ”フォルダ内（または／ｈｏｍｅ／ｉｎｆｏ／ｄａｔ／Ｇａｍｅ 配下のデータ領域））に格納される。
【０１１４】
また、生成された分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））は、分離ファイル部１２２２に格納される。
【０１１５】
また、抽出後ファイル群１１４００（例えばｉｃｏｎ．ｇｉｆ（３１３２）等）は上述の“Ｇａｍｅ”フォルダの中の“ｒｅｓｏｕｒｃｅｓ”フォルダ内に格納される。
【０１１６】
このようなファイル構成とすることにより、アプリラウンチャ等ＪＡＲファイル群よりそのアイコンファイル等を取り出し表示する形態をとるアプリケーションの実行速度を改善することが可能である。これは、アプリラウンチャ等は、ＪＡＲファイルからアイコンファイルを抽出する代わりに、分離ファイル部１２２２へアクセスして既に抽出がなされたアイコンファイルを取得することが可能となるためである。
【０１１７】
また、ＪＡＲファイルから抽出がなされて分離ファイル部１２２２へ書き出したファイル群については、そのファイル群に関するデータがＪＡＲファイルより削除されるため、従来技術において説明をしたようにアイコン情報等と、インデックス用ファイルで同用途のファイルの二重持ちが発生しない。また本実施の形態では、パッケージ化アプリの実行時において、一時記憶部（ＦｌａｓｈＲＯＭ等の不揮発記憶領域）の使用量の削減の効果が期待できる。
【０１１８】
なお上記では、アイコンファイルやテキストファイル等、アプリ実行時には利用されないファイルをパッケージ化アプリより分離する手順について説明したが、本発明はこのようなアプリ実行用途以外のファイルに加え、アプリ実行時に付随して利用されるようなファイルの分離にも適用可能である。例えば、Ｊａｖａ（登録商標）アプリに係るＪＡＲファイル内に共有ライブラリ（ＤＬＬ等）が含まれている場合、本共有ライブラリを分離対象とすることで実施の形態１の場合と同様の効果を得ることが出来る。
【０１１９】
特に共有ライブラリはその性質上、ファイルシステム上へ展開・配置しなければＪａｖａ（登録商標）アプリ等より利用することが出来ないことから、本手順によってあらかじめファイルシステム上へ配置することで、共有ライブラリのオープンに要する時間を短縮することが可能となる。
【０１２０】
（実施の形態２）
本実施の形態では、実施の形態１で説明したアプリケーション実行装置１０００において、所定のファイルを分離し、更新したパッケージ化アプリをアプリ実行エンジン１３２０で実行する場合において、この更新したパッケージ化アプリに係るアプリがパッケージ化アプリより分離されたファイルへのアクセスを要求する場合の処理について説明する。
【０１２１】
なお、以下では実施の形態１にてダウンロードしたＪａｖａ（登録商標）アプリＧａｍｅに含まれるパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（３１００））からアイコンファイルを分離したＧａｍｅ．ｊａｒ（１２２００）に係るＪａｖａ（登録商標）アプリＧａｍｅの起動及び、実行過程を例にとり、図１４、図１５、図１６、図１７、図１８、図１９、図２０を用いて説明を行う。特にデータ記憶部１２００には図１４に示すような構造にてデータが格納されているものとする。
【０１２２】
（１）アプリの起動
アプリ実行部１３００のアプリ起動処理部１３１０は、アプリ起動要求部１４２０等のアプリ起動手段（アプリラウンチャ等）よりアプリの起動要求を受け取ることにより、ファイルアクセス部１３３０へ起動要求アプリに係るパッケージ化アプリ及び、当該パッケージ化アプリに対応するアプリ記述ファイルの読込みを要求し、本読込まれたファイル群をアプリ実行エンジン１３２０へ渡してアプリの実行を開始する。以下、本処理手順の詳細については、図１５に示すフローチャートを用いて説明を行う。
【０１２３】
（１−１）アプリ起動に要するファイルをデータ記億部１２００より取得する
アプリ起動処理部１３１０は、例えばパッケージ化アプリの要求を受け付けると、必要なファイル（起動要求アプリのパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（１２２００））及び当該パッケージ化アプリのアプリ記述ファイル（３２００））をデータ記憶部１２００より取得をすることをファイルアクセス部１３３０へ要求する（Ｓ１５１０１）。
【０１２４】
例えば、Ｊａｖａ（登録商標）アプリＧａｍｅの起動要求を受け付けたアプリ起動処理部１３１０は、ファイルアクセス部１３３０へＪＡＲファイルＧａｍｅ．ｊａｒ（１２２００）及びＡＤＦファイルＧａｍｅ．ａｄｆ（３２００）の読込みを要求する。
【０１２５】
ファイル読込みの要求を受けたファイルアクセス部（１３３０）は、アプリ記憶部（１２１０）より、ＪＡＲファイル（Ｇａｍｅ．ｊａｒ（１２２００））及びＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））の読込みを行う（Ｓ１５２０１）。
【０１２６】
次に、分離ファイル情報アクセス部１３３１は、分離ファイル部１２２２に起動要求アプリに係る情報が格納されているか否かを確認し、これが格納されている場合は、本起動要求アプリに係る情報を元に分離ファイル情報テーブル１３３２を生成する。
【０１２７】
具体的には、分離ファイル部１２２２にＪａｖａ（登録商標）アプリＧａｍｅに関するファイル群（Ｇａｍｅ．ｉｎｆｏ（１０２００）、Ｇａｍｅ．ｌｉｓｔ（１２４００）、ｉｃｏｎ．ｇｉｆ（３１３２））が格納されているかどうかを確認し、これが格納されている場合は、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔ（１２４００）を取得し、本ファイルの内容に基づく分離ファイル情報テーブル１３３２を生成し、分離ファイル情報アクセス部１３３１内に格納する（Ｓ１５２０２）。
【０１２８】
分離ファイル情報テーブル１３３１は、分離抽出処理により、Ｇａｍｅ．ｊａｒより分離されたファイル名の一覧を保持するためのテーブルであり、後述のＪＡＲファイルより分離されたファイルへＪａｖａ（登録商標）アプリがアクセスするための処理を実現するために利用される。
【０１２９】
実施の形態１にて生成したＧａｍｅ．ｌｉｓｔ（１２４００）に基づく場合、ファイル名“ｉｃｏｎ．ｇｉｆ”等の分離対象のファイルを構成要素とするファイル分離情報テーブル（１３３２）を生成し、分離ファイルアクセス部１３３１内に格納されることとなる。
【０１３０】
上記処理の後、ファイルアクセス部１３３０は、アプリ起動処理部１３１０へアプリ記憶部１２１０より取得したパッケージ化アプリ及び当該パッケージ化アプリのアプリ記述ファイルを引き渡す（Ｓ１５２０２）。
【０１３１】
具体的には、ＪＡＲファイル（Ｇａｍｅ．ｊａｒ（１２２００））及びＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））を引き渡す。
【０１３２】
ステップ（Ｓ１５２０２）にて、アプリ起動に要するファイルを引き渡されたアプリ起動処理部１３１０は、取得したファイルを伴った起動要求をアプリ実行エンジン１３２０へ発行する（Ｓ１５１０２）。
【０１３３】
起動要求を受けたアプリ実行エンジン１３２０は、受け取ったパッケージ化アプリ及び当該パッケージ化アプリに係るアプリ記述ファイルを一時記憶部１３２１のパッケージ化アプリ部１３２２、アプリ記述ファイル部１３２３に各々書き出す（Ｓ１５３０１）。
【０１３４】
具体的には、ファイルアクセス部１３３０より、Ｇａｍｅ．ｊａｒ（１２２００）及びＧａｍｅ．ａｄｆ（３２００）を受け取ったアプリ起動処理部は、これら受け取ったファイル群を引数として、アプリ実行エンジン１３２０へＪａｖａ（登録商標）アプリＧａｍｅの起動要求を発行する。
【０１３５】
ＪＡＲファイルＧａｍｅ．ｊａｒ（１２２００）及びＡＤＦファイルＧａｍｅ．ａｄｆ（３２００）を受け取ったアプリ実行エンジン１３２０は、これらファイルの内容を一時記憶部１３２１へ書き出す。図１７はＪａｖａ（登録商標）アプリＧａｍｅ起動時の一時記憶部１３２１の内容を示すものである。Ｇａｍｅ．ｊａｒを一時記憶部１３２１へ書き出し、この記憶領域がパッケージ化アプリ部１３２２に相当し、Ｇａｍｅ．ａｄｆ（３２００）を一時記憶部１３２１へ書き出し、この記憶領域がアプリ記述ファイル部１３２３に相当する。
【０１３６】
次にアプリ実行エンジン１３２０は、一時記憶部１３２１に書き出されたパッケージ化アプリ部１３２２及び、アプリ記述ファイル部１３２３を元に、パッケージ化アプリよりメインモジュールに関するファイルを抽出し、これを一時記憶部１３２１へ書き出し、この記憶領域がメインモジュール部１３２４に相当するものとなる（Ｓ１５３０２）。
【０１３７】
具体的には、アプリ実行エンジン１３２０は、アプリ記述ファイル部１３２３に格納されたＧａｍｅ．ａｄｆ（３２００）の構成要素であるメインクラス名Ｇａｍｅ．ｃｌａｓｓ１７２０１に対応するファイルエントリであるＧａｍｅ．ｊａｒ（１２２００）（パッケージ化アプリ部１３２２に格納されている）のＧａｍｅ．ｃｌａｓｓ（１７１０１）を抽出し、これを一時記憶部１３２１の適当な未使用領域へメインクラスとして書き出し、これがモジュール部１３２４の一部として機能する。
【０１３８】
最後に、アプリ実行エンジン１３２０は、一時記憶部１３２１に書き出されたモジュール部１３２４より、エントリポイントとなる処理部を特定し、その特定された箇所よりアプリの実行を開始する（Ｓ１５３０３）。
【０１３９】
具体的には、上記手順により一時記憶部１３２１に書き出されたメインクラス部のエントリポイントとなるメソッドであるｓｔａｒｔ（）メソッド１７３０１が格納された箇所よりバイトコードの実行を開始する。
【０１４０】
図１８は、本発明の適用による一時記憶部の使用量の削減について、Ｊａｖａ（登録商標）アプリＧａｍｅの例を当てはめたものである。本発明適用後のＧａｍｅ．ｊａｒ１２２００には、本発明適用前のＧａｍｅ．ｊａｒに含まれていたアイコンファイルｉｃｏｎ．ｇｉｆ等が分離対象ファイルとして分離された後、一時記憶部１３２１に書き出されるため、分離されるファイルに相当するデータ量分、一時記憶部１３２１に空き領域とすることができる。この空き領域を他のデータに割り当てることができるようになり、一時記憶部１３２１をより効率よく使用することが可能となる。
【０１４１】
（２）アプリ実行過程におけるアプリに係るパッケージ化アプリより分離されたファイルへのアクセス
ファイルアクセス部１３３０は、アプリ実行エンジン１３２０にて実行中のアプリより、当該アプリに係るパッケージ化アプリより分離されたファイルへのアクセス要求を受け付けた場合、分離ファイル部１２２２よりファイルを読込む。図１９は、本手順の詳細を説明するための図である。図１９においてステップ（Ｓ１９１０１）、ステップ（Ｓ１０１０２）は主としてアプリ実行エンジン１３２０において行われ、ステップ（Ｓ１９２０１）〜ステップ（Ｓ１９２０５）は主としてファイルアクセス部１３３０において行われるものであり、特にステップ（Ｓ１９２０１）〜ステップ（Ｓ１９２０３）は主として分離ファイル情報アクセス部１３３１において行われるものである。
【０１４２】
（２−１）アプリによるファイル読込み要求を発行
アプリ実行エンジン１３２０にて実行中のアプリは、必要に応じてファイルアクセス部１３３０へファイルの読込みを要求する（Ｓ１９１０１）。
【０１４３】
図１９は、Ｊａｖａ（登録商標）アプリの一形態であるｉアプリ（Ｒ）における、当該ｉアプリに係るＪＡＲファイルからファイルを読込む手順を伴うメソッドｓｔａｒｔ（）の実装例を示す。なお、ここでは一例としてｉアプリを挙げているが、このようにＪＡＲファイルからファイルを取得する手順自体はｉアプリに限定されたものではない。ｉアプリ以外のＪａｖａ（登録商標）アプリの形態であるＭｉｄｌｅｔ等においても、ＪＡＲファイルからのファイル読込みに関する手順は用意されており、以下で記述する手順を実施することは可能である。
【０１４４】
ｉアプリは、ＤｏＪａ（Ｒ）仕様に基づいて作成されたＪａｖａ（登録商標）アプリであり、ＤｏＪａライブラリを利用してｉアプリに係るＪＡＲファイルよりファイルを読込むことが可能である。具体的には、ＤｏＪａライブラリＲｅｓｏｕｒｃｅＭａｎａｇｅｒクラスのメソッドｇｅｔＩｍａｇｅ（）等のメソッドを利用して、ＪＡＲファイルが含有するイメージファイル等を取得することが可能である。
【０１４５】
上記メソッドｇｅｔＩｍａｇｅ（）は、引数として与える文字列の内容により、ファイル読込み元を指定することが出来る。図２０におけるｇｅｔＩｍａｇｅ（）メソッド呼出においては、引数として“ｒｅｓｏｕｒｃｅ：／／／ｉｃｏｎ．ｇｉｆ”を指定している（図２０に示す２０１００）。本文字列において“ｒｅｓｏｕｒｃｅ：／／”は、当該ｉアプリに係るＪＡＲファイルをファイルの読込み元として指定するものである。また、“／ｉｃｏｎ．ｇｉｆ”は、当該ｉアプリに係るＪＡＲファイルのルートフォルダに格納されるｉｃｏｎ．ｇｉｆを読込み対象ファイルとして指定するものである。
【０１４６】
（２−２）パッケージ化アプリより分離されたファイルの読込み
分離ファイル情報アクセス部１３３１は、ステップ（Ｓ１９１０１）にて読込みを要求されたファイルの読込み元が実行中アプリに係るパッケージ化アプリであるかどうかを判定し、パッケージ化アプリである場合には、後述するステップ（Ｓ１９２０２）へ進み、パッケージ化アプリでない場合には、後述するステップ（Ｓ１９２０４）へ進む（Ｓ１９２０１）。
【０１４７】
ステップ（Ｓ１９２０１）において、読込み元が実行中アプリに係るパッケージ化アプリであると判定した場合、分離ファイル情報テーブル１３３２に、読込み要求ファイル名が含まれるか否かを判定し（Ｓ１９２０２）、含まれる場合は、分離ファイル部より該当する読込み要求ファイルを読込む（Ｓ１９２０３）。
【０１４８】
具体的には、図２０に示すメソッドｇｅｔＩｍａｇｅ（）２０１００によりファイル読込み要求を受け付けたファイルアクセス部１３３０の分離ファイル情報アクセス部１３３１は、ファイル読込み元がＪＡＲファイルか否かを確認する。メソッドｇｅｔＩｍａｇｅ（）２０１００は、ファイル読込み元としてＪＡＲファイル、ファイル名としてｉｃｏｎ．ｇｉｆを指定するものであるため、本条件を満たす。
【０１４９】
次に分離ファイル情報アクセス部１３３１は、分離ファイル情報テーブル１３３２に、読込み要求ファイル名ｉｃｏｎ．ｇｉｆが含まれるか否かを確認する。上記手順（１）の（１−１）にて示したとおり、ｉｃｏｎ．ｇｉｆは、分離ファイル情報テーブル１３３２に含まれるため、本条件も満たす。以上の要件を満たすため、分離ファイル情報アクセス部１３３１は、「ｉｃｏｎ．ｇｉｆは、ＪＡＲファイル内部には存在せず、分離ファイル部に格納されている」と認識し、分離ファイル部のＪａｖａ（登録商標）アプリＧａｍｅに関する部分（つまり、例えば図１４に示すような“ｒｅｓｏｕｒｃｅｓ”フォルダ内に格納された）ｉｃｏｎ．ｇｉｆを読込む。
【０１５０】
（３）（２）以外のファイルの読込み
ファイル読込み元がパッケージ化アプリ以外、もしくはファイル読込み元はパッケージ化アプリだが、分離されたファイルではない場合は、指定されたファイル読込み元よりファイルの読込みを行う（Ｓ１９２０４）。本ファイル読込み処理は、本発明を実施しない場合においても行うべき通常のファイル読込み処理である。
【０１５１】
（４）読込んだファイルの内容を一時記憶部１３２１への格納
（２）、もしくは（３）の手順で、データ記憶部１２００及び一時記憶部１３２１内のパッケージ化アプリ部１３２２より読込んだファイルの内容を一時記憶部１３２１の空き領域へ格納する（Ｓ１９２０５、Ｓ１９１０２）。本一時記憶部１３２１への格納処理は、本発明を実施しない場合においても行うべき通常のメモリコピー処理である。
【０１５２】
上記一連の手順によって、実行中のアプリが読込みを要求したファイルの内容が一時記憶部１３２１に格納される。上記処理により、実行中のアプリは、読込みを要求したファイルの読込み元がパッケージ化アプリであり、且つ読込みを要求したファイルがパッケージ化アプリより分離されたものであっても、分離されることなくパッケージ化アプリに含まれるファイルへのアクセスと同一の手順でファイルの読込みが可能である。
【０１５３】
（実施の形態３）
本実施の形態では、図１に記載の本発明によるアプリケーション実行装置１０００にて、本実施の形態１の手順によってファイルの分離を行ったパッケージ化アプリに係るアプリをアプリ実行エンジン１３２０で実行する過程において、このパッケージ化アプリに係るアプリが実行中に殆ど利用しないファイルであって当該パッケージ化アプリに含まれるものについては、ファイルの分離対象とすべくファイル使用情報の更新を行い、本ファイル使用情報に従ってファイルの分離する際の処理手順を説明する。
【０１５４】
なお、以下では本実施の形態１にてアイコンファイルを分離したＧａｍｅ．ｊａｒ（１２２００）に係るＪａｖａ（登録商標）アプリＧａｍｅの実行過程、及び実行後のファイル使用情報の更新とファイルの分離を例にとり、図２１、図２２、図２３、図２４、図２５、図２６、図２７を用いて説明を行う。このＧａｍｅ．ｊａｒ（１２２００）が含むファイルエントリｒｅａｄｍｅ．ｔｘｔはＪａｖａ（登録商標）アプリＧａｍｅ実行時に利用されないファイルであるとする（アプリラウンチャにおけるアプリ動作説明に利用されるテキストファイルである）。
【０１５５】
（１）ファイルアクセスの監視
実行中のアプリに係るパッケージ化アプリ含まれるファイルについて、そのファイルがアプリの実行中に殆ど利用されないものであるか否かを判定するために、ファイルアクセス監視部１３４０は、ファイルアクセス部１３３０よりファイルアクセス発生に関する情報を受け取り、受け取った情報に基づいてファイルアクセス監視テーブル１３４１の内容を更新することで、アプリ実行中にアクセスが発生した実行中のアプリにかかるパッケージ化アプリに含有されるファイルを特定可能な情報を構築することが出来る。
【０１５６】
図２１はアプリからのファイル読込み要求発生時における、本ファイルアクセス監視の処理手順を示すものである。図２１において、図１９に示したフローチャートのステップの符号と同一のものは図１９に示したものと同じまたはこれに相当するものであるため、詳細な説明（特にＳ１９１０１、Ｓ１９２０１〜Ｓ１９２０３、Ｓ１９１０２の処理に関する説明）は省略する。
【０１５７】
図２１において、Ｓ１９２０４において、ファイル読込み元がパッケージ化アプリ以外、もしくはファイル読込み元はパッケージ化アプリだが、分離されたファイルではない場合は、指定されたファイル読込み元よりファイルの読込みを行った後、ファイルアクセス部１３３０におけるファイル読込み完了後アプリ実行エンジン１３２０へのファイル内容の返却前に、ファイルアクセス監視部１３４０へのファイルアクセスを実施したことを通知する（Ｓ２１１０１）。
【０１５８】
ファイルアクセスを実施したことの通知を受けたファイルアクセス監視部１３４０は、通知を受けたファイルアクセスがパッケージ化アプリに含まれるファイルへのアクセスであるかどうかをチェックする（Ｓ２１２０１）。
【０１５９】
Ｓ２１２０１において、通知を受けたファイルアクセスがパッケージ化アプリ内のファイルへのアクセスである場合には、後述するＳ２１２０２へ進み、そうでない場合はＳ１９２０５へ進む。
【０１６０】
Ｓ２１２０１において、通知を受けたファイルアクセスがパッケージ化アプリ内のファイルへのアクセスである場合、ファイルアクセス監視部１３４０が具備するファイルアクセス管理テーブル１３４１に、通知を受けたファイルにアクセスが発生した旨の情報を書き込む（Ｓ２１２０２）。
【０１６１】
Ｓ２１２０２において、書き込むが完了した後、Ｓ１９２０５へ進む。
【０１６２】
Ｓ１９２０５については図１９を用いて説明した内容と同じであるので、ここではその詳細な説明を省略する。
【０１６３】
このように構成することにより、アプリ実行中において、アクセスされるファイルを監視することが可能となる。
【０１６４】
ここでは、本実施の形態２にて示したＪａｖａ（登録商標）アプリＧａｍｅ実行中のファイル読込みを例にして、上記処理を具体的に説明する。
【０１６５】
アプリ実行中におけるファイルアクセスは、本実施の形態２にて示したように、明示的にアプリからファイルアクセスを要求する場合に限らず、アプリ実行エンジン１３２０によって内部処理としてファイルアクセスが行われる場合がある。
【０１６６】
Ｊａｖａ（登録商標）におけるクラスファイルのメモリへのロードがその一例である。Ｊａｖａ（登録商標）の場合、アプリ実行エンジン１３２０の具体的な一例であるＪａｖａ（登録商標）ＶＭは、起動するＪａｖａ（登録商標）アプリのメインクラス及びそのメインクラスのエントリポイントであるメソッドの実行に必要最低限のクラスファイルを読込んで一時記憶部１３２１へ格納し、そのＪａｖａ（登録商標）アプリのＪＡＲファイルに含まれるクラスファイルのうち一時記憶部１３２１へ格納しなかったその他のクラスファイルは、必要に応じてＪＡＲファイルから適宜読み出される。
【０１６７】
図２２は、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅに含まれるクラスにおいて、ソースコードの要部の一例を示すものである。
【０１６８】
図２２に示す例では、Ｊａｖａ（登録商標）アプリＧａｍｅのメインクラスであるＧａｍｅクラス２２１００は、エントリポイントであるｓｔａｒｔ（）メソッドを含む。Ｉｎｉｔｉａｌｉｚｅクラス２２２００は、前記ｓｔａｒｔ（）メソッドからのみ特定の条件を満たしたとき利用されるメソッドｉｎｉｔ（）を含む。Ｍａｉｎクラス２２２３０は、Ｊａｖａ（登録商標）アプリＧａｍｅのメイン処理であるｍａｉｎ（）メソッドを含む。
【０１６９】
ここでは、Ｊａｖａ（登録商標）アプリＧａｍｅ起動時の処理内容について上記ソースコード群を用いて説明する。まずＪａｖａ（登録商標）ＶＭよりＧａｍｅクラスのｓｔａｒｔ（）メソッドが呼び出される。ｓｔａｒｔ（）メソッドでは、まずＧａｍｅクラスの内部メソッドｉｓＩｎｉｔｉａｌｉｚｅｄ（）が呼び出される。本メソッドの詳細な内容については割愛するが、Ｊａｖａ（登録商標）アプリＧａｍｅの初期化処理が行われていない場合はｆａｌｓｅ、初期化処理が行われている場合はｔｒｕｅを返すものであるとする。
【０１７０】
その後ＩｓＩｎｉｔｉａｌｉｚｅｄ（）の戻り値によって初期化処理完了かどうかを取得し、初期化処理が未完了（戻り値がｆａｌｓｅ）の場合は、Ｉｎｉｔｉａｌｉｚｅクラスのメソッドｉｎｉｔ（）を、初期化処理が完了（戻り値がｔｒｕｅ）の場合は、Ｍａｉｎクラスのメソッドｍａｉｎ（）を呼び出す。
【０１７１】
ここで、Ｉｎｉｔｉａｌｉｚｅクラスのクラスファイル、Ｍａｉｎクラスのクラスファイルの読み込みは、それぞれＩｎｉｔｉａｌｉｚｅクラスのメソッドｉｎｉｔ（）の呼出、Ｍａｉｎクラスのメソッドｍａｉｎ（）の呼出の直前に行われる。
【０１７２】
すなわち、Ｉｎｉｔｉａｌｉｚｅクラスのクラスファイルの読み込みは、メソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）がｔｒｕｅを返す場合である、初回起動時、もしくは二回目以降の起動時であるが前回以前の起動において初期化処理が失敗した場合のみ行われ、クラスＩｎｉｔｉａｌｉｚｅクラスのクラスファイルの読み込みは行われない。
【０１７３】
一方クラスＭａｉｎについては、Ｊａｖａ（登録商標）アプリ起動時に必ず読込まれる。なお、以下説明の簡略化の為、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅのＪＡＲファイルに含まれる、上記に挙げたもの以外のクラスファイル及びリソースファイル（ｒｅａｄｍｅ．ｔｘｔを除く）については、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅ実行中に最低１度はロードが行われることとする。
【０１７４】
図２３は、例えば上記クラスファイルの読込みにより、ファイルアクセス監視テーブルの状態の変化を説明するための図である。図２３の２３１００は、Ｊａｖａ（登録商標）アプリＧａｍｅ初回起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブル１３４１の一例を示す。初回起動時においては、Ｉｎｉｔｉａｌｉｚｅクラス２３１０１を含め全てのクラスが読込まれるため、クラスファイルについてはすべてアクセス有が設定されている。一方、本実施例の前提部で説明したとおり、ｒｅａｄｍｅ．ｔｘｔ（２３１０２）はＪａｖａ（登録商標）アプリ実行時には使用されないファイルであるため、アクセスなしが設定される。
【０１７５】
Ｊａｖａ（登録商標）アプリＧａｍｅ２回目起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブル１３４１についても、初回起動時とほぼ同じ内容の設定となるが、二回目以降の起動においては、Ｉｎｉｔｉａｌｉｚｅクラスはロードされないため、本クラスに対する設定値はアクセスなしに更新される。Ｊａｖａ（登録商標）アプリＧａｍｅ１０回目起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブルについては、２回目起動時の内容と同一である。
【０１７６】
（２）ファイルの分離
アプリ実行終了時処理において、アプリ実行エンジン１３２０は、アプリ終了に伴う処理（例えばリソースの解放に関する処理などであり、このような処理は本実施の形態に関わらず行われる処理である）を実施する（Ｓ２４１０１）。
【０１７７】
次に、アプリ実行エンジン１３２０は、ファイルアクセス監視部１３４０へ、ファイル使用情報の更新を要求する（Ｓ２４１０２）。
【０１７８】
本要求を受けたファイルアクセス監視部１３４０は、ファイルアクセス監視テーブル１３４１の内容を引数として、ファイル使用情報更新部１１１１へ前記実行を終了したアプリに係るファイル使用情報の更新及び、ファイルの分離の実施を要求する（Ｓ２４２０１）。
【０１７９】
本要求を受け取ったファイル使用情報更新部１１１１は、実施の形態１にて説明した処理手順に基づきファイル使用情報の更新を実施し、その後ファイル分離判定部１１１２によるファイル分離判定、及びファイル分離部１１１３によるファイル分離を適宜実施する。
【０１８０】
ここで、実施の形態１の場合と大きく異なる点が、ファイルアクセス監視テーブル１３４１の内容を引数としてファイル使用情報の更新処理を実施する点である。すなわち実施の形態１において、図５に示したＳ５００４の処理が実施される。
【０１８１】
Ｓ５００４における処理手順についてＪａｖａ（登録商標）アプリの一例であるＧａｍｅにおいて、Ｊａｖａ（登録商標）アプリＧａｍｅの初回実行前のＧａｍｅ．ｄａｔが初回実行後にファイルアクセス監視テーブル７３００によってどのように更新されるのかを図示した一例が、図２５である。
【０１８２】
ファイル使用情報更新部１１１１は、引数として渡されたＪａｖａ（登録商標）アプリの一例であるＧａｍｅの実行過程で生成され、ファイルアクセス監視部１３４０内に保持されたファイルアクセス監視テーブル１３４１に基づき、ファイル使用情報７３００に含まれる情報（この例では各ファイルの“ｃｏｕｎｔ”に対応する値および“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”）を更新する。
【０１８３】
Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅの、初回起動前のファイル使用情報７３００に含まれる“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”に対応する値は０、各ファイルの“Ｃｏｕｎｔ”に対応する値は０である。
【０１８４】
初回起動後、“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”に対応する値に１が加えられる（インクリメントされる）。
【０１８５】
また、ファイルアクセス監視テーブル１３４１において、ファイル毎にアクセスフラグを調べ、アクセスフラグが「アクセス有り」となっているファイル名に対応するファイルについては、ファイル使用情報７３００における該当する使用情報（この例ではＮａｍｅの値が「アクセス有り」となっているアクセスフラグに対応するファイル名と同じ使用情報）の“Ｃｏｕｎｔ”に対応する値に１が加えられる（インクリメントされる）。
【０１８６】
また、アクセスフラグが「アクセスなし」となっているファイル名に対応するファイルについては、該当する使用情報の“Ｃｏｕｎｔ”に対応する値の変更はない。
【０１８７】
図２５に示す例では、アプリ終了時におけるファイルアクセス監視テーブル１３４１において、アクセスフラグが「アクセス有り」となっているファイル名に対応するファイル（例えば、Ｇａｍｅ．ｃｌａｓｓ、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ）について、Ｊａｖａ（登録商標）アプリＧａｍｅの初回起動後の該当する使用情報の“Ｃｏｕｎｔ”に対応する値に１が加えられ（インクリメントされる）、アクセスフラグが「アクセスなし」となっているファイル名に対応するファイル（この例ではｒｅａｄｍｅ．ｔｘｔ）については、該当する使用情報の“Ｃｏｕｎｔ”に対応する値の変更はないことを示している。
【０１８８】
Ｊａｖａ（登録商標）アプリＧａｍｅの二回目の実行終了後においても、二回目の実行終了時のファイルアクセス監視テーブル７３００に基づき、ファイル使用情報７３００を更新する点に変わりはない。しかしながら、Ｊａｖａ（登録商標）アプリＧａｍｅに含まれるＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓは初回の実行において、メソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）がｔｒｕｅを返していた場合、再度の実行は必要ないため、２回目のメソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）はｆａｌｓｅを返す。このため、Ｊａｖａ（登録商標）アプリＧａｍｅの２回目以降の実行において、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓは一時記憶部１３２１へロードされなくなり、結果としてファイルアクセス監視テーブル１３４１のＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓに対応するアクセスフラグは「アクセスなし」となる。
【０１８９】
つまり、ファイル名がＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓに対応するファイル使用情報７３００の使用情報２５５０２については、Ｃｏｕｎｔ（２５５０４）の値の変更はない。
【０１９０】
また、上述したとおり、ｒｅａｄｍｅ．ｔｘｔはＪａｖａ（登録商標）アプリの一例であるＧａｍｅの実行時には使用されないファイルであるため、ファイルアクセス管理テーブル１３４１の該当するアクセスフラグにはアクセスなしが設定される。
【０１９１】
図２７は、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後のファイル使用情報の一例を説明するための図である。図２７においては、Ｎａｍｅの値が“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”の使用情報の“Ｃｏｕｎｔ”の値が１、Ｎａｍｅの値が“ｒｅａｄｍｅ．ｔｘｔ”の使用情報の使用情報の“Ｃｏｕｎｔ”の値が０である。
【０１９２】
図５において説明したように、Ｓ５１０１では、ファイル使用情報７３００に基づき、分離対象のファイルを決定し、決定したファイルに関する情報を分離ファイル名リストへ追加すること、Ｓ５１０１の具体的な処理の一例を示す図８の説明において、Ｓ８００１では“ＬａｕｎｃｈｅｄＣｏｕｎｔ”が周期定数Ｉに定める値（図８で説明した例ではこの値は１０）の倍数毎にＳ８００２〜Ｓ８００６に示すフローが実行されること、Ｓ８００３でＹｅｓ（使用回数の上限を定めていないファイル）かつＳ８００５でＮｏ（アプリの起動回数に分離定数Ｘを乗じた値よりもファイルの使用回数方が少ない）の場合、分離対象ファイル名リスト９１００に対象となるファイルの情報が追加されることを説明した。
【０１９３】
ここでは、図８で説明したフローチャートに示す処理を図２６に例示したファイル使用情報７３００に適用した場合について説明をする。
【０１９４】
まず図２６のファイル使用情報は、上述したとおりＪａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後のファイル使用情報であるので、図８におけるＳ８００１の判断結果はＹｅｓとなる。
【０１９５】
Ｓ８００２は、後述するＳ８００３〜Ｓ８００６をファイル使用情報７３００に含まれる各ファイルの使用情報に対して行なうことを示すものである。
【０１９６】
図８の説明において、分離定数Ｘの値を０．１としたものを例に説明しているので、“ＬａｕｎｃｈｅｄＣｏｕｎｔ”の値が１０のとき、図８のＳ８００５におけるＵの値は０．１×１０＝１となる。
【０１９７】
つまり、Ｓ８００５、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後、ファイル使用情報７３００に含まれる各ファイルの使用情報において、“Ｃｏｕｎｔ”が１回以下の使用情報に対応するファイルに関する情報が分離対象ファイル名リスト９１００に追加される。
【０１９８】
図２７の例では、Ｎａｍｅの値が“ｉｃｏｎ．ｇｉｆ”に対応する使用情報の“Ｃｏｕｎｔ”の値は０、“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”に対応する使用情報の“Ｃｏｕｎｔ”の値は１、“ｒｅａｄｍｅ．ｔｘｔ”に対応する使用情報の“Ｃｏｕｎｔ”の値は０であり、更新された分離対象ファイル名リスト９１００にはこれらのファイル（“Ｃｏｕｎｔ”の値が１以下の使用情報に対応するファイル）に関する情報が含まれるようになる。
【０１９９】
具体的には、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓの使用情報の構成要素Ｃｏｕｎｔが１、ｉｃｏｎ．ｇｉｆの使用情報の構成要素Ｃｏｕｎｔが０、ｒｅａｄｍｅ．ｔｘｔの使用情報の構成要素Ｃｏｕｎｔが１であり、これらは分離対象として、分離対象ファイル名リスト９１００へ加える。
【０２００】
こうして、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ及びｒｅａｄｍｅ．ｔｘｔが新たに分離対象となり、ファイル分離部によってＧａｍｅ．ｊａｒより分離される。
【０２０１】
図２８は、図２７に示された分離対象ファイル名リスト９１００に基づいて分離がなされた後のＪａｖａ（登録商標）アプリの一例であるＧａｍｅ．ｊａｒ、Ｇａｍｅ．ｄａｔ、Ｇａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔ、抽出後ファイル群の一例を示す。分離後のＧａｍｅ．ｊａｒはＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ及びｒｅａｄｍｅ．ｔｘｔなどの使用回数が少ないファイルが分離されたことによってさらにファイルサイズが小さくなる。
【０２０２】
また、今回Ｇａｍｅ．ｊａｒから分離されたＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、及びｒｅａｄｍｅ．ｔｘｔは分離ファイル部１２２２へ格納される。
【０２０３】
なお、上記ファイル分離による効果を得るためには、Ｊａｖａ（登録商標）アプリが図２２で例示したような構成をとることを必要とするところ、図２２のＪａｖａ（登録商標）アプリＧａｍｅで例示した処理は、本例における特別な処理形態ではなく、多くのＪａｖａ（登録商標）アプリが普通に採用する構成である。つまり本発明の効果は、現存する多くのＪａｖａ（登録商標）アプリにおいて得られるといえる。
【０２０４】
これは、多くのＪａｖａ（登録商標）アプリは、そのＪａｖａ（登録商標）アプリの初回起動時のみＨｔｔｐ通信等を行い、Ｊａｖａ（登録商標）アプリ実行に必要なデータを取得してデータ記憶部１２００に例示されるようなＪａｖａ（登録商標）アプリ専用の不揮発記憶領域へ格納する、という処理形態をとることで、二度目以降の起動については、データ記憶部１２００から読み込んで実行することにより、起動処理の高速化及び、通信回数の削減効果が図ることが通例となっているためである。
【０２０５】
多くのＪａｖａ（登録商標）アプリに係るＪＡＲファイルに含まれるクラスは、Ｊａｖａ（登録商標）アプリ起動時にほぼ毎回使用されるクラス、ユーザの特定操作時にのみ使用されるクラス、初回起動時等のタイミングにおいてのみ使用されるクラス等が混在した状態となっている。
【０２０６】
このため、後者で挙げた使用回数が僅少なクラスに係るファイルを分離することで、ＪＡＲファイルのサイズが削減され、結果として一時記憶部１３２１へ使用しないまたは使用頻度の低いファイルをロードすることがなくなり、その分、一時記憶部１３２１の空き容量が増え、他の処理にこの空き容量を利用できるようになるので、アプリ実行時において、一時記憶部１３２１に占めるＪＡＲファイルの領域を削減するとともに、一時記憶部１３２１の利用効率の向上が図れる。
【０２０７】
（実施の形態４）
実施の形態４では、図１に記載の本発明によるアプリケーション実行装置１０００における、実施の形態１や実施の形態３の手順によってファイルの分離を行ったパッケージ化アプリ１３２３を分離前の元のパッケージ化アプリへ復元するための処理手順を説明する。
【０２０８】
なお、以下では図２７に示した分離がなされたＧａｍｅ．ｊａｒを元に復元する処理を例にして説明を行う。
【０２０９】
図２９は本実施の形態のアプリケーション実行装置において、復元処理の一例を説明するためのフローチャートである。
【０２１０】
また、図３０は図２９に示すフローチャートを適用して復元するときのＧａｍｅ．ｊａｒの変化を模式的に示したものである。
【０２１１】
以下に図２８に示したフローチャートを説明する。
【０２１２】
（４−１）復元に必要なファイルを一時記憶部１３２１より読込む
アプリ復元部１１２０は、アプリ記憶部１２１０より復元対象のパッケージ化アプリを、分離ファイル部１２２２より復元対象のパッケージ化アプリに係る復元情報１０２００、分離ファイル一覧１２４００を取得する（Ｓ２８００１）。
【０２１３】
図２７に示すＧａｍｅ．ｊａｒを上述の処理にあてはめて説明すると、Ｓ２８０１は復元情報に対応するＧａｍｅ．ｉｎｆｏ、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔをデータ記憶部１２００より読み込むことに相当する。
【０２１４】
（４−２）元パッケージ化アプリに存在した全てのファイルエントリを生成する
次にファイル復元部１１２０は、（４−１）で取得したパッケージ化アプリに含まれる全ファイルエントリを取り出す（Ｓ２８００２）。また、（４−１）で取得した分離ファイル一覧に基づきパッケージ化アプリより分離された全てのファイルをパッケージ化アプリのファイルエントリ形式に変換する（Ｓ２８００３）。
【０２１５】
図２８に示すＧａｍｅ．ｊａｒを上述の処理にあてはめて説明すると、Ｓ２８００２は、図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるファイルエントリＧａｍｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ等を取り出す処理がこれに相当する。
【０２１６】
なお、図２８に示すＧａｍｅ．ｊａｒに含まれる全ファイルエントリを取り出したものを模式的に示したものが、図３０において、２９４００の符号を付したものである。
【０２１７】
また、Ｓ２８００３は、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔに指定されたファイル名“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”、“ｉｃｏｎ．ｇｉｆ”、“ｒｅａｄｍｅ．ｔｘｔ”等のファイルを分離ファイル部１２２２より読込み（Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、ｉｃｏｎ．ｇｉｆ、ｒｅａｄｍｅ．ｔｘｔ等）、これらをＪＡＲファイルエントリ形式に変換する。
【０２１８】
ここで、ＪＡＲファイルエントリ形式は、実施の形態１にて挙げたとおり無圧縮、及びＤＥＦＬＡＴＥ圧縮アルゴリズム等による圧縮のいずれかである。
【０２１９】
なお、図３０に示す復元前のＧａｍｅ．ｊａｒに対応する分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ）に基づいて、分離されたファイル群２９５００を分離ファイル部１２２２より読込み、ＪＡＲファイルエントリ形式に変換したのを模式的に示したものが、図２９における２９６００の符号を付したものである。
【０２２０】
また、図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるファイルエントリがどのＪＡＲファイルエントリ形式であるかを知るためには、復元前のＧａｍｅ．ｊａｒに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒまたは対応するＧａｍｅ．ｉｎｆｏに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに格納されている情報を参照すればよい。
【０２２１】
また、図３０に示す分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））に基づいて、分離されたファイルがどのＪＡＲファイルエントリ形式であるかを知るためには、図３０に示すＧａｍｅ．ｉｎｆｏに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒまたは図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに格納されている情報を参照すればよい。
【０２２２】
（４−３）元のパッケージ化アプリを組み立てる
次にアプリ復元部１１２０は、Ｓ２８００２、Ｓ２８００３にて生成したファイルエントリと、Ｓ２８００１にて読み込んだ復元情報を利用して、復元情報１０２００（Ｇａｍｅ．ｉｎｆｏ）に含まれるファイルエントリ格納位置・順序に基づき生成したファイルエントリの連結を行う（Ｓ２８００４）。
【０２２３】
その後、復元情報１０２００をＳ２８００４にて連結したファイルエントリに連結する（Ｓ２８００５）。
【０２２４】
次にＳ２８００５において、完成したデータを元のパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（３１００））として、アプリ記憶部１２１０への格納等を行う（Ｓ２８００６）。
【０２２５】
上述の処理にあてはめて説明すると、Ｓ２８００２、Ｓ２８００３にて生成したファイルエントリ（Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、ｉｃｏｎ．ｇｉｆ、ｒｅａｄｍｅ．ｔｘｔ、Ｇａｍｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ等）を復元情報１０２００に含まれるＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙの内容（つまりファイルヘッダ）に基づいて、各ファイルエントリの連結を行なうことがＳ２８００４に相当する。
【０２２６】
また、復元情報１０２００に含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒが先頭となるように連結したファイルエントリに連結するとともに、復元情報１０２００に含まれるＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙを連結したファイルエントリの後ろに連結するのがＳ２８００５に相当する。
【０２２７】
上記手順により、分離されたＪＡＲファイルを元のＪＡＲファイルへ復元することが可能となる。本手順は、ファイル分離前の復元確認処理（Ｓ５２０４）や、ＪＡＲファイルを情報端末外へエクスポートする場合に利用する。
【０２２８】
（実施の形態５）
実施の形態５では、図１に記載の本発明によるアプリケーション実行装置１０００における、実施の形態１や実施の形態３の手順によってファイルの分離を行ったパッケージ化アプリをデータ記憶部１２００より削除する際に、パッケージ化アプリの分離によって生成したファイル群についても一括削除するための処理手順を説明する。
【０２２９】
なお、データ記憶部１２００へのファイルアクセスについては、実施の形態１の結果であるＪａｖａ（登録商標）アプリＧａｍｅのファイル分離実施後のファイル構造を図示した図１３、図１４を用いることとする。
【０２３０】
図１３に示すように、Ｊａｖａ（登録商標）アプリＧａｍｅに対し分離がなされると、アプリ記述ファイル３２００、分離後のパッケージ化アプリ１２２００、ファイル使用情報７３００、復元情報１０２００、分離ファイル一覧１２４００、パッケージ化アプリから分離され抽出された抽出後ファイル群１１４００がデータ記憶部１２００に格納される。
【０２３１】
図１４に示すように分離後のパッケージ化アプリ１２２００、アプリ記述ファイル３２００はデータ記憶部１２００のアプリ記憶部１２１０（より具体的には、図１４に示す“ａｐｐ”フォルダの中）にそれぞれＧａｍｅ．ｊａｒ、Ｇａｍｅ．ａｄｆというファイル名で記憶される。
【０２３２】
ファイル使用情報７３００はデータ記憶部１２００の分離ファイル情報部１２２０内のファイル使用情報部（より具体的には図１４に示す“ｕｓｅｉｎｆｏ”フォルダの中）にＧａｍｅ．ｄａｔというファイル名で記憶される。
【０２３３】
復元情報１０２００、分離ファイル一覧１２４００は、データ記憶部１２００の分離ファイル情報部１２２０内の分離ファイル部１２２２（より具体的には図１４に示す“Ｇａｍｅ”フォルダの中）にそれぞれＧａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔというファイル名で記憶される。
【０２３４】
パッケージ化アプリから分離され抽出された抽出後ファイル群１１４００は、データ記憶部１２００の分離ファイル情報部１２２０内の分離ファイル部１２２２（より具体的には“ｒｅｓｏｕｒｃｅｓ”の配下）に記憶される。図１４に示す例では、抽出後ファイル群１１４００は“ｉｃｏｎ．ｇｉｆ”というファイル名を有するファイル等が記憶されることを示している。
【０２３５】
図３１は、ファイルの分離を行った後のパッケージ化アプリを削除する処理手順の一例を示すものである。この処理手順に従った処理は、専らアプリ削除部１１３０にてなされる。
【０２３６】
アプリ削除部１１３０は、アプリ削除要求を受け取ると、当該削除対象アプリに係るパッケージ化アプリ、及び対応するアプリ記述ファイルをアプリ記憶部１２１０より削除する（Ｓ３０００１）。図１４に示した例では、“ａｐｐ”フォルダの中のＧａｍｅ．ｊａｒ、Ｇａｍｅ．ａｄｆを削除することがＳ３０００１に相当する。
【０２３７】
その後、アプリ削除部１１３０は、当該パッケージ化アプリ分離によって生成されたファイル使用情報、復元情報、分離ファイル一覧の削除及び、分離ファイル一覧に列挙されたファイル群の削除を行う（Ｓ３０００２）。図１４に示した例では、“Ｇａｍｅ”フォルダの中のＧａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔを削除するとともに、“ｒｅｓｏｕｒｃｅｓ”フォルダの中の配下のファイルを削除するＳ３０００１に相当する。
【０２３８】
上述の具体的な削除はファイルを削除の対象としたが、これに限定される必要はなく例えば、フォルダ（ディレクトリ）を削除するような構成としても同様の効果を奏する。例えば、Ｇａｍｅという名称のフォルダ（ディレクトリ）を削除した場合には、その配下のファイル、フォルダも同時に削除される。
【０２３９】
上記手順により、Ｊａｖａ（登録商標）アプリの削除に合わせて、当該Ｊａｖａ（登録商標）アプリに係るＪＡＲファイル及び分離によって生成されたファイル群も連動して削除することが可能となる。
【０２４０】
このように一気に削除を実施しなければ、ファイルシステム上に分離によって生成されたファイルが削除されることなく残ってしまうことになるため、本手順によるファイル群の一括削除はデータ記憶領域の有効活用において重要である。
【０２４１】
（実施の形態６）
実施の形態６では、図１に記載の本発明によるアプリケーション実行装置１０００における、アプリ起動に係るユーザインターフェースのアイコン等情報表示処理について説明する。
【０２４２】
アプリケーション実行装置１０００において、ユーザは、一覧表示処理部１４００の一覧表示部１４０１が表示する起動可能アプリ一覧より、起動したいアプリを選択し、これを起動することができる。
【０２４３】
起動したいアプリの選択は、ユーザのキー入力によって行われる。キー入力はキー入力部１５００によって受け付けられ、キー入力部１５００は、入力されたキー情報をユーザ入力受付部１４０２へ通知する。入力されたキー情報を受け取ったユーザ入力受付部１４０２はキー情報に応じて、起動可能アプリ一覧の更新を一覧表示部１４０１へ要求、もしくはアプリの起動をアプリ起動要求部１４０３へ要求をする。アプリ起動要求を受けたアプリ起動要求部１４０３は、当該起動要求に係るアプリに関する情報を引数として、アプリ起動処理部１３１０へアプリ起動要求を行う。また、起動可能アプリ一覧の更新要求を受けた一覧表示部１４０１は、適宜分離ファイル部よりＪＡＲファイルより分離されたアイコン情報を取得しながら、起動可能アプリ一覧の表示更新を行う。
【０２４４】
図３２は、本起動可能アプリ一覧表示更新処理について、アプリラウンチャの処理を一例として説明するための図である。
【０２４５】
始めに一覧表示部１４０１は、画面に表示可能な個数分に対応するアプリの名前と、アイコンイメージをデータ記憶部１２００に格納された情報等を利用して取得する。前記アプリの名前についてはアプリ記述ファイルから、アイコンイメージはアプリ記述ファイルに記載のアイコンファイル名を元にパッケージ化アプリより抽出することで取得できる。しかし、アイコンイメージを分離し、分離ファイル部１２２２に記憶しているパッケージ化アプリについては、上記パッケージ化アプリからのアイコンイメージ抽出を行うことなく、分離ファイル部１２２２よりアイコンイメージの取得が可能である。
【０２４６】
具体例を挙げて説明すると、一覧表示部は画面３１１００に表示可能なアプリ数（この例では３）分、アプリ名及びそのアプリのアイコンイメージの取得を試みる。始めに一覧表示部は、Ｊａｖａ（登録商標）アプリＧａｍｅに関するアプリ名及びアイコンイメージの取得を試みる。アプリ名については、アプリ記憶部１２１０に格納されたアプリ記述ファイル（ＡＤＦファイル）に記載の情報によって取得可能である。アイコンイメージについては、ＡＤＦファイルに記載されたアイコンイメージのファイル名に基づき、Ｇａｍｅ．ｊａｒより抽出を行う前に、分離ファイル部１２２２に前記ファイル名のファイルが存在するかどうかを確認する。
【０２４７】
ここで存在する場合については、パッケージ化アプリであるＧａｍｅ．ｊａｒからの抽出は行わず、分離ファイル部１２２２より読込みを行い、存在しない場合については、Ｇａｍｅ．ｊａｒからの抽出を行なう。こうして取得したアプリ名及びアイコンイメージが表示される（３１１０１）。上記手順は、他のアプリであるＴｏｏｌ、Ｍｅｍｏに対しても行われ、画面３１１００が構築される。
【０２４８】
なお、アイコンイメージの他アプリの説明文の表示（３１１０２）を行うためにＪＡＲファイルよりテキストファイル（図３に示す例では、“ｒｅａｄｍｅ．ｔｘｔ”など）を読込む機能を有するアプリラウンチャも存在する。このようなアプリラウンチャは、上記手順においてアイコンイメージだけでなく、説明文に係るテキストファイルも合わせて取得することにより実現可能である。
【０２４９】
また、本説明文に係るテキストファイルのファイル名がアイコンイメージ同様ＡＤＦ等に記述可能な場合は、ファイル使用情報更新部においてアイコンイメージだけでなく説明文に係るテキストファイルも分離対象とすることにより、上記アイコンイメージ同様分離ファイル部からの取得が可能となる。
【０２５０】
上記手順により、ＪＡＲファイルよりアイコンイメージを逐次取得する処理形態に比べて起動可能アプリ一覧表示に要する時間を短縮することが可能である。なお、前記と同様の効果を有する技術としてアイコンキャッシュが挙げられるが、アイコンキャッシュでは、ＪＡＲファイルとキャッシュ領域に同一のアイコンイメージを示す情報を保持する必要があるところ、本発明ではアイコンイメージ等の二重持ちが発生しないため、不揮発領域を圧迫しない。この省メモリ性も、本実施の形態が奏する効果である。
【産業上の利用可能性】
【０２５１】
本発明に係るアプリケーション実行装置は、パッケージ化アプリが含有する殆どアプリが使用しないファイルを分離することで、アプリ実行における一時記憶領域の使用量を削減する効果及び、アプリラウンチャの表示処理を高速化する効果を有し、情報端末や携帯電話などに有用である。
【０２５２】
また、本発明に係るアプリケーション実行装置は、通信機能を有したＡＶ機器などにも有用である。
【図面の簡単な説明】
【０２５３】
【図１】本実施の形態のアプリケーション実行装置を説明するための図
【図２】本実施の形態において、パッケージ化アプリファイルとアプリ記述ファイルの一例を示す図
【図３】本実施の形態において、ＪＡＲファイルとＡＤＦファイルの一例を示す図
【図４】本実施の形態において、データ記憶部の一例を示す図
【図５】本実施の形態において、ファイル分離処理の一例を示すフローチャート
【図６】本実施の形態において、ファイル使用情報の一例を示す図
【図７】本実施の形態において、ファイル分離処理の一例を示す図
【図８】本実施の形態において、分離対象ファイル名リスト生成処理の一例を示すフローチャート
【図９】本実施の形態において、分離対象ファイル名リスト生成処理の一例を示す図
【図１０】本実施の形態において、復元情報の生成処理の一例を示す図
【図１１】本実施の形態において、ファイル分離処理の一例を示す図
【図１２】本実施の形態において、ファイル分離処理前のパッケージ化アプリ、およびファイル分離処理後のパッケージ化アプリを説明するためのからのファイル削除処理の一例を示す図
【図１３】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図１４】本実施の形態において、ファイル分離実施後のデータ記憶部の一例を示す図
【図１５】本実施の形態において、アプリのロードと起動処理の一例を示すフローチャート
【図１６】本実施の形態において、分離ファイル情報テーブルの生成の一例を示す図
【図１７】本実施の形態において、アプリ起動直後の一時記憶部に記憶されるデータの一例を示す図
【図１８】本実施の形態において、ファイル分離処理を実施した場合に一時記憶部に記憶されるデータと、ファイル分離処理を実施しない場合に一時記憶部に記憶されるデータとの比較を説明するための図
【図１９】本実施の形態において、アプリ実行過程で分離されたファイルへアクセス処理する一例を示すフローチャート
【図２０】本実施の形態において、分離されたファイルへのアクセス処理を含むプログラムの一例を示す図
【図２１】本実施の形態において、ファイルアクセス監視を伴うアプリ実行過程で分離されたファイルへのアクセス処理の一例を示すフローチャート
【図２２】本実施の形態において、アプリソースコードの一例を示す図
【図２３】本実施の形態において、ファイルアクセス監視テーブルの内容の一例を示す図
【図２４】本実施の形態において、ファイル使用情報の更新処理とファイル分離処理の一例を示すフローチャート
【図２５】本実施の形態において、ファイル使用情報を更新処理する一例を示す図
【図２６】本実施の形態において、ファイル使用情報に基づき分離対象ファイル名リストを生成処理する一例を示す図
【図２７】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図２８】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図２９】本実施の形態において、アプリ復元処理の一例を示すフローチャート
【図３０】本実施の形態において、アプリ復元処理の一例を示す図
【図３１】本実施の形態において、アプリ削除時に分離ファイル群を削除処理する一例を示すフローチャート
【図３２】本実施の形態において、アプリラウンチャの一例を示す図
【符号の説明】
【０２５４】
１０００ アプリケーション実行装置
１１００ アプリファイル管理部
１１０１ アプリ取得部
１１１０ アプリ分離部
１１１１ ファイル使用情報更新部
１１１２ ファイル分離判定部
１１１３ ファイル分離部
１１２０ ファイル復元部
１１３０ アプリ削除部
１２００ データ記憶部
１２１０ アプリ記憶部
１２２０ 分離ファイル情報部
１２２１ ファイル使用情報部
１２２２ 分離ファイル部
１３００ アプリ実行部
１３１０ アプリ起動処理部
１３２０ アプリ実行エンジン
１３２１ 一時記憶部
１３２２ パッケージ化アプリ部
１３２３ アプリ記述ファイル部
１３２４ モジュール部
１３３０ ファイルアクセス部
１３３１ 分離ファイル情報アクセス部
１３３２ 分離ファイル情報テーブル
１３４０ ファイルアクセス監視部
１３４１ ファイルアクセス監視テーブル
１４００ 一覧表示処理部
１４１０ ユーザ入力受付部
１４２０ アプリ起動要求部
１４３０ 一覧表示部
１５００ キー入力部
２１００ パッケージ化アプリ
２１１０ ヘッダ情報
２１２０ プログラムモジュールファイルエントリ群
２１３０ リソースデータファイルエントリ群
２１４０ ファイルエントリ管理情報
２１４１ ファイルエントリファイルヘッダ
２１４２ ファイルエントリのＯｆｆｓｅｔ
２１４３ ファイルエントリのＬｅｎｇｔｈ
２１４４ ファイルエントリのＮａｍｅ
２２００ アプリ記述ファイル
２２０１ 起動プログラムモジュール
２２０２ アイコンリソース
６１００ ファイル使用情報
６１１０ ファイル使用情報の共通情報
６１１１ アプリ起動回数
６１２０ パッケージ化アプリ内ファイル１使用情報
６１２１ パッケージ化アプリ内ファイル１のファイル名
６１２２ パッケージ化アプリ内ファイル１のアプリ実行時最大使用回数
６１２３ パッケージ化アプリ内ファイル１のアプリ実行時使用回数累計
【技術分野】
【０００１】
本発明は、モジュールファイル群及びリソースファイル群をパッケージングしたファイル（例えばＪＡＲファイルなど）であるパッケージ化アプリをメモリに記憶し、実行することが可能な情報端末において、パッケージ化アプリの実行に利用されない、または利用頻度の低いファイルをメモリへ記憶する前に分離するアプリケーション実行装置に関する。
【背景技術】
【０００２】
近年、携帯電話に代表される、通信機能を有し、持ち運びが可能な情報端末は、アプリケーションをネットワーク経由にてダウンロードし、保存し、実行する機能が広く採用されている。旧来の情報端末においては、ユーザは情報端末の出荷時に搭載されたアプリケーションのみ利用が可能であったが、本機能により、ユーザはユーザ自身で必要なアプリケーションをインターネット上のダウンロードサイト等にて検索し、ダウンロードし、情報端末へ保存して、実行することが可能となった。
【０００３】
上記情報端末におけるダウンロードアプリケーションの実行環境として、Ｊａｖａ（登録商標）が広く採用されている。Ｊａｖａ（登録商標）採用の理由としては、アプリケーションプログラムの実行環境としてのＪａｖａ（登録商標）の特徴である、プラットフォーム非依存性、豊富なクラスライブラリ、セキュアな実行環境等が挙げられるが、その他の大きな特徴して統一されたアプリケーションの配布形態も挙げられる。
【０００４】
Ｊａｖａ（登録商標）の実行環境であるＪＲＥ（クラスライブラリ、Ｊａｖａ（登録商標）ＶＭ（Ｊａｖａ（登録商標）言語にて記述されたアプリケーションを実行するためのソフトウェア）、及びＪＲＥを搭載する端末固有のポーティングレイヤ、より構成される）は、ＪＡＲファイルを入力として受け取り、これをＪａｖａ（登録商標）ヒープと呼ばれるＲＡＭ上に確保された一時記憶領域へ格納し、格納されたＪＡＲファイルより実行に必要なクラスファイル（Ｊａｖａ（登録商標）言語で記述されたソースコードをＪａｖａ（登録商標）コンパイラでコンパイルすることで生成されるプログラムモジュール）を抽出してＪａｖａ（登録商標）ヒープ上へ格納し、実行することが出来る。ＪＡＲファイルとは、クラスファイル及びＪａｖａ（登録商標）アプリ実行過程で使用する様々なリソースファイル（ＧＩＦイメージファイル、ＭＩＤＩファイル、テキストファイル等）を、ＪＡＲ形式でパッケージ化したファイルである。
【０００５】
このようにＪａｖａ（登録商標）アプリ実行に係るファイル群をパッケージ化するメリットとしては、（Ａ）ネットワーク経由でのＪａｖａ（登録商標）アプリ配布が容易であること、（Ｂ）ネットワーク経由でダウンロードしたＪａｖａ（登録商標）アプリを情報端末にて保持・管理することが容易であること、が挙げられる。特に携帯電話のように通信が課金され、データを格納するための不揮発記憶領域（ＦｌａｓｈＲＯＭ等）のサイズ制限が厳しい情報端末においては、通信回数の削減や、ダウンロード前にＪａｖａ（登録商標）アプリを端末に保存するために要する不揮発記憶領域のサイズを正確に見積もることが可能である点から、本配布形態により享受できるメリットは大きい。
【０００６】
なお、ＪＡＲファイルには、Ｊａｖａ（登録商標）アプリの実行に直接関係しないファイルも含まれることが多い。このようなファイル一例として、アイコンファイルが挙げられる。アイコンファイルは、Ｊａｖａ（登録商標）アプリ実行時ではなく、ユーザがダウンロードしたＪａｖａ（登録商標）アプリ一覧より実行するＪａｖａ（登録商標）アプリを選択するためのＵＩ（以下アプリラウンチャ）をグラフィカル化する目的で使用される。ここでグラフィカル化とは、Ｊａｖａ（登録商標）アプリ一覧表示における各項目の表示内容を、旧来のアプリ名のみから、アプリ名とアイコンの組み合わせとすることを示す。
【０００７】
アイコンの表示を伴う場合、各項目に係るアプリのＪＡＲ形式にパッケージ化されたファイルよりアイコンファイルを読込む必要がある。しかし、ＪＡＲ形式にパッケージ化されたファイルよりクラスファイルやリソースファイルを読込むためには、読込み対象となるファイルの位置を特定し、データの展開（データが圧縮されている場合に限定されるが、ＪＡＲファイルサイズ削減の要請から、圧縮されている場合が多い）を実施する必要があるため、通常のファイル読込みと比較して多くの時間を要する。
【０００８】
このため、処理能力があまり高くない携帯電話のような情報端末においては、ＪＡＲ形式ファイルからのファイル読込みに要する時間が他の処理を圧迫し、結果として、キーレスポンス低下といったユーザビリティに直結するような性能の悪化が生じてしまっていた。
【０００９】
このような問題を改善する技術として、コンテンツよりアイコン情報等を元にインデックス用ファイルを事前に作成しておき、コンテンツ一覧表示時には、本ファイルに基づいて表示処理を高速化する技術（例えば特許文献１参照）、がある。
【特許文献１】特開２００５−１４１５９６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記技術の場合、コンテンツ内に含まれるアイコン情報等と、インデックス用ファイルで同用途のファイルの二重持ちが発生する。ＰＣ等のように不揮発記憶領域（ＨＤＤ）の容量の制限が緩いものについては、特段問題は生じないが、携帯電話等のモバイル機器については、コスト等の要請から不揮発記憶領域であるＦｌａｓｈＲＯＭの使用容量制限が大きく、このようなファイルの二重持ち状態は許容できるものではない。
【００１１】
また、不揮発記憶領域のみならず、ＲＡＭ等の一時記憶領域についても同様に厳しい制限が課せられている。現状Ｊａｖａ（登録商標）アプリの実行エンジンであるＪａｖａ（登録商標）ＶＭは、ＪＡＲファイルを携帯端末の不揮発記憶領域から読込み、Ｊａｖａ（登録商標）ＶＭが専有する一時記憶領域であるＪａｖａ（登録商標）ヒープへコピーする。さらにＪａｖａ（登録商標）ＶＭはアプリの実行に必要となるクラスファイルやイメージ等のリソースファイルをＪＡＲより抽出し、Ｊａｖａ（登録商標）ヒープへコピーして使用する。このようなＪａｖａ（登録商標）ＶＭの実行形態は、アプリ実行中頻繁にアクセスが発生するファイル群からなるＪＡＲファイルを一時記憶領域であるＪａｖａ（登録商標）ヒープへキャッシュしておくこととなるから、処理能力の乏しい携帯電話等の情報端末においては有利なものである。一方、ＪＡＲ内にアプリ実行時に殆ど使用されないファイルが含まれている場合は、Ｊａｖａ（登録商標）ヒープを浪費してしまい、一時記憶領域を使用する他のアプリケーションや、アプリ自身の実行動作へ悪影響を及ぼすこととなる。
【課題を解決するための手段】
【００１２】
本発明のアプリケーション実行装置は、モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能なものであって、前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたものである。
【発明の効果】
【００１３】
本発明のアプリケーション実行装置は、モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能な情報端末において、前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたので、前記パッケージ化アプリを実行するとき、実行中に使用されないファイルはアプリ実行部の一時記憶部に格納されなくなり、一時記憶部の記憶容量を必要以上に圧迫することがなくなる。これは、例えばアプリ実行部が複数のパッケージ化アプリを同時・並列に実行するような場合において非常に有用である。実行中に一時記憶部に占める領域を削減することにより、他のパッケージ化アプリ、ファイルにこの削減により空けることが可能になった一時記憶部の領域を割り当てることが可能となる。これにより、並行して起動できるパッケージ化アプリの最大数を増加できるといった効果が期待できる。
【００１４】
また、前記パッケージ化アプリは、前記モジュールファイル群またはリソースファイル群に含まれる各ファイル対して、前記各ファイルの格納位置、サイズに関するファイルヘッダ情報を含み、前記ファイルヘッダ情報に示された格納位置に基づいて前記モジュールファイル群およびリソースファイル群に含まれる各ファイルが格納されており、前記ファイル分離部により前記パッケージ化アプリからファイルを分離する場合、分離する対象のファイルおよび前記分離する対象のファイルに対応するファイルヘッダ情報を削除し、前記分離対象のファイルの削除により空けられた領域を詰めるように、前記削除したファイルに後続するファイルを再配置するとともに、前記再配置により格納位置が変化したファイルに対応するファイルヘッダ情報に含まれる格納位置を更新することにより、分離したパッケージ化アプリを生成するようにすれば、前記分離されたパッケージ化アプリのサイズを小さくすることができるので、実行するとき、アプリ実行部の一時記憶部に格納されるパッケージ化アプリのサイズを小さくできるので、一時記憶部の記憶容量を必要以上に圧迫することがなくなる。
【００１５】
また、前記ファイル使用情報更新部により作成されるファイル使用情報は、前記パッケージ化アプリを実行した回数と、前記パッケージ化アプリに含まれる各ファイルを特定する情報、前記パッケージ化アプリを実行するために前記特定した各ファイルを、前記一時記憶部に格納できる最大回数と、前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数とを含むものであって、前記ファイル使用情報更新部は、更に前記パッケージ化アプリを実行する毎に、対応するファイル使用情報に含まれる、前記パッケージ化アプリを実行した回数および前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するようにすれば、アプリケーション実行装置は、パッケージ化アプリに含まれるファイルの使用回数を特定できるようになる。
【００１６】
また、前記判定部は、前記パッケージ化アプリを実行した回数が所定の回数となる毎に、前記一時記憶部に実行可能なデータ形式となるようにして格納した回数が所定の回数よりも少ないファイルを前記パッケージ化アプリの実行中に使用されないファイルとみなす判定をし、前記ファイル分離部は、前記実行中に使用されないファイルが分離されたパッケージ化アプリから更に前記使用されないとみなしたファイルを分離するようにすれば、パッケージ化アプリを繰り返し、実行したとき、実行時において利用頻度の少ないファイルを分離できるようになるので、実行時において、アプリ実行部の一時記憶部に格納されるパッケージ化アプリのサイズをより小さくすることが可能となり、一時記憶部の記憶容量を更に圧迫することがなくなる。
【００１７】
また、前記ファイル分離部は、分離したファイルを示す復元情報を生成し、前記データ記憶部に記憶するとともに、前記アプリケーション実行装置は、前記復元情報を用いて分離したファイルを復元する復元部を更に備えるようにすれば、パッケージ化アプリをファイルが分離される前の状態に戻すことが可能となる。例えばファイルが分離されたパッケージ化アプリに異常が発生したとしても、ファイルが分離される前の状態に戻せば、異常の発生を回避することが可能となる場合などには有用である。
【００１８】
また、前記ファイル分離部により生成される復元情報は前記パッケージ化アプリから分離したファイルを特定する情報および前記特定したファイルが格納されている前記データ記憶部の格納位置を示す情報を含み、前記アプリ実行部により実行されるパッケージ化アプリが、既に分離され前記一時記憶部には格納されていないファイルの実行を要求する場合、前記分離されたファイルが格納されている前記データ記憶部の格納位置を示す情報を用いて、前記分離されたファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納するようにすれば、パッケージ化アプリの実行において、既に分離がされ、一時記憶部に格納されていないファイルへのアクセスを要求する場合であっても、該当するファイルを一時記憶部へ格納し、実行可能なデータ形式となるように変換して前記一時記憶部の記憶領域へ展開し、実行することが可能となる。
【００１９】
また、前記アプリ実行部は、前記パッケージ化アプリに含まれる各ファイルが、前記一時記憶部に格納された前記パッケージ化アプリに含まれる各ファイルへのアクセスが前記アプリ実行部により実行されるパッケージ化アプリの実行中になされたかどうかを示すファイルアクセス関しテーブルを保持し、ファイルアクセス関しテーブルに基づいて、前記ファイル使用情報に含まれる該当するファイルについて、実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するよう、前記ファイル使用情報更新部に指示するように構成すれば、各ファイルの使用回数を特定することが可能となる。
【００２０】
また、前記アプリケーション実行装置は、更に前記データ記憶部に記憶したパッケージ化アプリを削除する削除手段を備え、前記削除手段は、前記データ記憶部に記憶したパッケージ化アプリを削除する場合、前記分離したパッケージ化アプリおよび前記分離したファイルを削除するように構成すれば、ファイルの分離がなされたパッケージ化アプリを削除する場合、分離されたファイルをも一括して削除することが可能となり、パッケージ化アプリを利用する利用者は分離されたファイルを意識することなく、パッケージ化アプリの削除を行なうことが可能となるばかりか、パッケージ化アプリを削除した後に、このパッケージ化アプリに関連する分離したファイルが、データ記憶部に削除されることなく残っているという状態を回避できるため、データ記憶部を不必要に圧迫するということがなくなる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明が適用された実施の形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２２】
具体的には、以下では、パッケージ化アプリであるＪＡＲファイルをダウンロードし、ＦｌａｓｈＲＯＭ等の不揮発記憶領域へ保存し、これを実行することが可能なアプリケーション実行装置であるＪＲＥにおける一例を示すが、例えばＢＲＥＷ（Ｒ）のような、他のパッケージ化アプリをダウンロードし、不揮発領域へ保存し、実行することが可能なアプリケーション実行装置についても、本発明は適用可能である。
【００２３】
（実施の形態１）
図１は本実施の形態のアプリケーション実行装置を説明するための図である。
【００２４】
図１において、１０００はアプリケーション実行装置である。アプリケーション実行装置１０００は、アプリファイル管理部１１００、データ記憶部１２００、アプリ実行部１３００、一覧表示処理部１４００、キー入力部１５００を備える。
【００２５】
アプリファイル管理部１１００は、アプリ取得部１１０１、アプリ分離部１１１０、ファイル復元部１１２０、アプリ削除部１１３０を備える。また、アプリ分離部１１１０はファイル使用情報更新部１１１１、ファイル分離判定部１１１２、ファイル分離部１１１３を備える。
【００２６】
データ記憶部１２００は、アプリ記憶部１２１０、分離ファイル情報部１２２０を備える。また、分離ファイル情報部１２２０は更にファイル使用情報部１２２１、分離ファイル部１２２２を備える。
【００２７】
アプリ実行部１３００はアプリ起動処理部１３１０、アプリ実行エンジン１３２０、ファイルアクセス部１３３０、ファイルアクセス監視部１３４０を備える。また、アプリ実行エンジン１３２０は一時記憶部１３２１を備え、一時記憶部１３２１はパッケージ化アプリ部１３２２、アプリ記述ファイル部１３２３、モジュール部１３２４を備える。ファイルアクセス部１３３０は分離ファイル情報アクセス部１３３１を備え分離ファイル情報アクセス部１３３１は更に分離ファイル情報テーブル１３３２を備える。ファイルアクセス監視部１３４０は更にファイルアクセス監視テーブル１３４１を備える。
【００２８】
一覧表示処理部１４００はユーザ入力受付部１４１０、アプリ起動要求部１４２０、一覧表示部１４３０を備える。
【００２９】
図１において、データ記憶部１２００内のアプリ記憶部１２１０に格納されたパッケージ化アプリ及び本パッケージ化アプリに係るアプリ記述ファイルに基づき、アプリ分離部１１１０にてパッケージ化アプリが含むアイコンファイル（アプリ記述ファイルの内容に基づき静的にパッケージ化アプリに係るアプリの実行に利用されない旨を判定可能なファイル）をパッケージ化アプリより分離する際の処理手順について説明する。
【００３０】
なお、アイコンファイルは静的にパッケージ化アプリに係るアプリの実行時に利用されない旨を判定可能なファイルの一例であり、これをアイコンファイルに限定するものではなく、アイコンファイル以外のファイルであってパッケージ化アプリに係るアプリの実行時に利用されないファイルに対しても適用が可能である。
【００３１】
図２は、本実施の形態におけるパッケージ化アプリ及び、アプリ記述ファイルの一例を説明するための図である。
【００３２】
図２において、パッケージ化アプリ２１００は、アプリケーションの実行に必要なプログラムモジュールに関するファイルに係るデータであるファイルエントリ群２１２０及びアプリケーションの実行過程においてプログラムモジュールが利用するリソースファイルに係るデータであるファイルエントリ群２１３０をパッケージ化し、１ファイルとしたものを含む。
【００３３】
図２の説明においては、ファイルエントリ群２１２０はプログラムモジュール１に対応するファイルエントリ１、プログラムモジュール２に対応するファイルエントリ２、プログラムモジュール３に対応するファイルエントリ３、．．．プログラムモジュール（Ｎ−１）に対応するファイルエントリ（Ｎ−１）を有するものする。
【００３４】
また、ファイルエントリ群２１３０はリソースデータ１に対応するファイルエントリＮ、リソースデータ２に対応するファイルエントリＮ＋１、リソースデータ２に対応するファイルエントリＮ＋２、．．．を有するものとする。
【００３５】
なおパッケージ化アプリ２１００には、さらにパッケージ化アプリ内の各ファイルエントリを抽出するためのファイルエントリ管理情報２１４０、及びヘッダ情報２１１０が必要に応じて含まれている。図２においては、パッケージ化アプリ２１００にファイルエントリ管理情報２１４０、及びヘッダ情報２１１０を含んでいるものを例に説明をする。
【００３６】
このファイルエントリ管理情報２１４０とは、パッケージ化アプリ２１００に含まれる各ファイルエントリに対応するファイルエントリファイルヘッダ２１４１の集合である。
【００３７】
ファイルエントリ１に対応するファイルエントリ１ファイルヘッダ２１４１を例にファイルエントリファイルヘッダの構成を説明する。ファイルエントリファイルヘッダは、Ｏｆｆｓｅｔ（２１４２）、Ｌｅｎｇｔｈ（２１４３）、Ｎａｍｅ（２１４４）等の情報を含む。
【００３８】
Ｏｆｆｓｅｔ（２１４２）は、パッケージ化アプリ内におけるファイルエントリ１の位置である。Ｌｅｎｇｔｈ（２１４３）はファイルエントリ１のサイズである。Ｎａｍｅ（２１４４）は、ファイルエントリ１のファイル名である。
【００３９】
Ｏｆｆｓｅｔ（２１４２）には例えばパッケージ化アプリ２１００に含まれる最初のファイル（この例ではヘッダ情報）の先頭位置から数えて何バイト目にあるかに関する情報を格納する。また他のファイルエントリに対応するファイルエントリヘッダ（ファイルエントリ２ファイルヘッダ、ファイルエントリ３ファイルヘッダ、．．．ファイルエントリｉファイルヘッダ（ｉ：整数））については、上述のファイルエントリ１ファイルヘッダ２１４１の説明において、ファイルエントリ１を対応するファイルエントリの番号に読み替えればよく、ファイルエントリ１ファイルヘッダ２１４１と同様のデータ構造を有するものである。
【００４０】
パッケージ化アプリから特定のファイルを抽出する場合は、抽出したいファイルのファイル名と、ファイル名“Ｎａｍｅ”の値が一致するファイルエントリファイルヘッダを探し出し、見つかったファイルエントリファイルヘッダのＯｆｆｓｅｔ及びＬｅｎｇｔｈに基づいてファイルエントリの位置・範囲を特定して、対応するファイルエントリを取り出し、且ファイルエントリが圧縮されている場合は適当な解凍手段（図示せず）によって解凍する、という手順が必要となる。
【００４１】
アプリ記述ファイル２２００は、アプリ実行時に最初に必要となるプログラムモジュールに関する情報２２０１や、アプリラウンチャ等においてアプリ名一覧と共に表示されるアプリの属性情報を記述するためのファイルである。
【００４２】
アプリの属性情報とは、例えばアイコンに関する情報２２０２といったようなものである。なお、アプリラウンチャの詳細については実施の形態６にて後述する。
【００４３】
図３は、図２に示したパッケージ化アプリ２１００、アプリ記述ファイル２２００をより具体的にしたものの一例を示す図であり、アプリケーションをＪａｖａ（登録商標）アプリケーションとしたときのパッケージ化アプリファイルとして、ＪＡＲファイル（この例では、Ｇａｍｅ．ｊａｒ（３１００））及び、ＪＡＲファイルに係るアプリ記述ファイルとしてＡＤＦファイル（この例では、Ｇａｍｅ．ａｄｆ（３２００））の例を示す図である。
【００４４】
ＪＡＲファイルの一例であるＧａｍｅ．ｊａｒ（３１００）は例えば、プログラムモジュールであるクラスファイル（Ｇａｍｅ．ｃｌａｓｓ（３１２１）、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ（３１２２）、Ｍａｉｎ．ｃｌａｓｓ（３１２３）等）、リソースファイルであるＧＩＦファイル（ｇａｍｅ．ｇｉｆ（３１３１）、ｉｃｏｎ．ｇｉｆ（３１３２））、テキストファイル（ｒｅａｄｍｅ．ｔｘｔ（３１３３））等、ヘッダ情報（２１１０）に対応するＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）、及びファイルエントリ管理情報（２１４０）に対応するＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）により構成される。
【００４５】
Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）には、ＪＡＲファイル自体の属性であるファイルサイズ等が格納され、Ｃｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）にはクラスファイル（３１２１、３１２２、３１２３等）や、ＧＩＦファイル（３１３１、３１３２）、テキストファイル３１３３等を取り出すための情報であるファイルヘッダが格納される。
【００４６】
ファイルヘッダ３１４１には、図２において説明したファイルエントリファイルヘッダ２１４１と同様の情報が格納されている。具体例を挙げると、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルヘッダ３１４１には、ＪＡＲファイル３１００の先頭からのＧａｍｅ．ｇｉｆ（３１３１）の位置であるＯｆｆｓｅｔ（３１４２）、Ｇａｍｅ．ｇｉｆ（３１３１）のサイズであるＬｅｎｇｔｈ（３１４３）、Ｇａｍｅ．ｇｉｆ（３１３１）のファイル名であるＮａｍｅ（３１４４）等より構成される。
【００４７】
図３に示す例では、ＪＡＲファイルは、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）、プログラムモジュール（この例では、クラスファイル（Ｇａｍｅ．ｃｌａｓｓ（３１２１）、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ（３１２２）、Ｍａｉｎ．ｃｌａｓｓ（３１２３）等）、リソースファイル（この例では、ＧＩＦファイル（ｇａｍｅ．ｇｉｆ（３１３１）、ｉｃｏｎ．ｇｉｆ（３１３２））、テキストファイル（ｒｅａｄｍｅ．ｔｘｔ（３１３３）等））、ファイルエントリ管理情報部（この例ではプログラムモジュールに含まれる各クラスファイルのファイルヘッダ（Ｇａｍｅ．ｃｌａｓｓファイルヘッダ、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓファイルヘッダ、Ｍａｉｎ．ｃｌａｓｓファイルヘッダ、．．．）、リソースファイルに含まれるファイルのそれぞれに対応するファイルヘッダ（ｇａｍｅ．ｇｉｆファイルヘッダ、ｉｃｏｎ．ｇｉｆファイルヘッダ、ｒｅａｄｍｅ．ｔｘｔファイルヘッダ、．．．）の順に格納されているものとする。
【００４８】
また、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）のファイルサイズはＨｓバイト、クラスファイルを含んだプログラムモジュールのサイズ（プログラムモジュールを構成する各クラスファイルのサイズを総計したもの）はＣｓバイト、リソースファイルに含まれるファイルであるＧａｍｅ．ｇｉｆ（３１３１）のファイルサイズはＲ１ｓバイト、ｉｃｏｎ．ｇｉｆ（３１３２）のファイルサイズはＲ２ｓバイトとする。
【００４９】
このとき、Ｇａｍｅ．ｇｉｆ（３１３１）の前に格納されているＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）およびプログラムモジュールのファイルサイズの総和はＨｓ＋Ｃｓバイト、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルサイズはＲ１ｓバイトであるため、Ｇａｍｅ．ｇｉｆ（３１３１）のファイルヘッダ３１４１のＯｆｆｓｅｔ（３１４２）にはＨｓ＋Ｃｓ、Ｌｅｎｇｔｈ（３１４３）にはＲ１ｓが格納される。
【００５０】
ＡＤＦファイルに対応するＧａｍｅ．ａｄｆ（３２００）は、Ｊａｖａ（登録商標）アプリ実行において最初に実行するメソッドを含むクラスのファイル名を示す情報であるＭａｉｎＣｌａｓｓ（３２０１）及び、アプリラウンチャにおいてアプリ名一覧と共に表示されるアイコンファイルのファイル名を示す情報であるＩｃｏｎＦｉｌｅ（３２０２）等のＡＤＦキーのリストにより構成される。
【００５１】
パッケージ化アプリ及びアプリ記述ファイルは、アプリケーション実行装置１０００のアプリ取得部１１０１によって外部サーバ等よりインターネット等を経由して取得され、データ記憶部１２００内の記憶領域であるアプリ記憶部１２１０に格納される。
【００５２】
図４は、図１に示すデータ記憶部１２００に記憶されるデータの具体的一例を説明するための図である。データ記憶部１２００は、例えばＦｌａｓｈＲＯＭ等の不揮発記憶領域上に構成されたファイルシステムを格納するための記憶領域である。データ記憶部１２００は例えば階層構造を用いてデータを格納しており、この例ではアプリ記憶部１２１０は“ｈｏｍｅ”フォルダの中にある“ｊａｖａ”フォルダの中の“ａｐｐ”フォルダ内（またはルートディレクトリから「／ｈｏｍｅ／ｊａｖａ／ａｐｐ」にて示されるディレクトリの配下）の記憶領域に対応する。
【００５３】
図４においては、アプリ取得部１１０１によって、取得されたＪａｖａ（登録商標）アプリＧａｍｅに対応するＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）は、アプリ記憶部１２１０における“ａｐｐ”フォルダの中にＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）を格納した例を示している。
【００５４】
上記の手順等によってアプリ記憶部１２１０にパッケージ化アプリ、アプリ記述ファイルが格納された後、アプリ分離部１１１０は、ファイル使用情報更新部１１１１、ファイル分離判定部１１１２、ファイル分離部１１１３の協調動作により、アイコンファイル等、当該パッケージ化アプリに含まれるファイル群のうちアプリ実行中に使用されないまたは使用頻度の低いファイルの分離を行う。図５は本ファイルの分離に関する具体的な処理手順を示すフローチャートである。
【００５５】
ここでは、図５のフローチャートを参照しながら、上記Ｇａｍｅ．ｊａｒ（３１００）、及びＧａｍｅ．ａｄｆ（３２００）より構成されるＪａｖａ（登録商標）アプリＧａｍｅを構成するファイルを分離する処理手順の一例を示す。
【００５６】
（１）ファイル使用情報の生成
ファイル使用情報更新部１１１１は、アプリ記憶部１２１０に格納されたパッケージ化アプリ（本実施の形態では、ＪＡＲファイル）及び当該パッケージ化アプリに係るアプリ記述ファイル（本実施の形態では、ＡＤＦファイル）を含むＪａｖａ（登録商標）アプリを用いて、当該パッケージ化アプリに係るファイル使用情報の生成を行う。
【００５７】
具体的には、上記アプリ取得部１１０１は、ＪＡＲファイルに対応するＧａｍｅ．ｊａｒ（３１００）及びＡＤＦファイルに対応するＧａｍｅ．ａｄｆ（３２００）をアプリ記憶部１２１０へ格納後、ファイル使用情報更新部１１１１へファイル使用情報に対応するＧａｍｅ．ｄａｔの生成を要求する。
【００５８】
図６は、ファイル使用情報の一例を説明するための図である。図６において、ファイル使用情報６１００は、パッケージ化アプリの実行過程において、実行過程のパッケージ化アプリを構成する各ファイルに関する情報を含み、共通情報６１１０と、各ファイルに対応する使用情報を有する。
【００５９】
共通情報６１１０には、パッケージ化アプリがアプリ実行エンジン１３２０において起動され、実行された回数であるアプリ起動回数６１１１を有する。パッケージ化アプリに含まれるファイル使用情報には、ファイル名６１２１、アプリ実行時最大使用回数６１２２、及びアプリ実行時使用回数累計６１２３を有する。
【００６０】
使用情報６１２０におけるファイル名６１２１は該当するファイルのファイル名を示す。アプリ実行時最大使用回数６１２２は、当該アプリがそのファイルを最大何度まで使用できるかを示す。具体的には、本値が０であれば、ファイル名６１２１に係るファイルは一度も当該アプリから使用されないことを示すものであり、本値が１であれば、ファイル名６１２１に係るファイルは一度だけ当該アプリから使用されることを示す。アプリ実行時使用回数累計６１２３は、当該アプリがアプリ実行エンジン１３２０における実行過程において、ファイル名６１２１に係るファイルへ実際にアクセスを行った回数の累計を示す。
【００６１】
図６に示す例では、ｉｃｏｎ．ｇｉｆにおけるアプリ実行時最大使用回数６１２２（ＭａｘＣｏｕｎｔ）は０である。これはアプリ実行時においてｉｃｏｎ．ｇｉｆが利用されないことを示す。
【００６２】
次に、ファイル使用情報の生成処理手順の詳細について説明する。図５においてステップ（Ｓ５００１）〜ステップ（Ｓ５００５）までは、主としてファイル使用情報更新部１１１１の動作、ステップ（Ｓ５１０１）〜ステップ（Ｓ５１０２）は主としてファイル分離判定部１１１２による動作、ステップ（Ｓ５２０１）〜ステップ（Ｓ５２０７）は主としてファイル分離部１１１３の動作に相当する。
【００６３】
まず、アプリ取得部１１０１よりファイル使用情報生成要求を受け取ると、ファイル使用情報更新部１１１１は、ファイル使用情報生成の対象のアプリに係るファイル使用情報が既にファイル使用情報部１２２１に格納済みであるかを確認する（Ｓ５００１）。
【００６４】
ステップ（Ｓ５００１）において格納済みでないことを確認した場合（例えば、ダウンロード直後のアプリといったような場合など）、ファイル使用情報更新部１１１１は、当該アプリに係るデフォルトとなるファイル使用情報の生成を試み、データ記憶部へ格納する（Ｓ５００２）。
【００６５】
ステップ（Ｓ５００１）において格納済みであることを確認した場合には、ステップ（Ｓ５００３）へ進む。
【００６６】
ステップ（Ｓ５００３）では、データ記憶部１２００からファイル使用情報を読み込んで取得する。
【００６７】
デフォルトのファイル使用情報は、パッケージ化アプリ及びアプリ記述ファイルに基づいて生成される。
【００６８】
図７は、Ｊａｖａ（登録商標）アプリＧａｍｅに係るＧａｍｅ．ｊａｒ（３１００）及びＧａｍｅ．ａｄｆ（３２００）を用いてＪａｖａ（登録商標）アプリＧａｍｅ（３１００）に含まれるアプリの実行中に利用することのないファイル（この例では、ｉｃｏｎ．ｇｉｆ）を分離するために生成するファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を説明するための図である。図において、Ｇａｍｅ．ｄａｔ（７３００）は、アプリの起動回数であるＬａｕｎｃｈｅｄＣｏｕｎｔ（７３０１）及び、Ｇａｍｅ．ｊａｒ（３１００）に含まれるファイル毎の使用情報を有する。また各ファイルの使用情報は、ファイル名であるＮａｍｅ、アプリ実行時最大使用回数であるＭａｘＣｏｕｎｔ、アプリ実行時使用回数累計であるＣｏｕｎｔを含む。
【００６９】
例えばファイル“Ｇａｍｅ．ｃｌａｓｓ”の使用情報７３１０の場合、ファイル名であるＮａｍｅ（７３１１）の値には、“Ｇａｍｅ．ｃｌａｓｓ”、アプリ実行時最大使用回数であるＭａｘＣｏｕｎｔ（７３１２）の値には−１、アプリ実行時使用回数累計であるＣｏｕｎｔ（７３１３）の値には０であることを示している。
【００７０】
図７は、Ｇａｍｅ．ｊａｒ（３１００）とＧａｍｅ．ａｄｆ（３２００）を用いてデフォルトのファイル使用情報Ｇａｍｅ．ｄａｔ（７３００）を生成する具体的例を説明するための図である。
【００７１】
（処理１） ファイル使用情報Ｇａｍｅ．ｄａｔ（７３００）に含まれるＬａｕｎｃｈＣｏｕｎｔの値に０が設定される。
【００７２】
（処理２） Ｇａｍｅ．ｊａｒ（３１００）のＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）の先頭のファイルヘッダ（この例ではＧａｍｅ．ｃｌａｓｓファイルヘッダ）から順に１つずつファイルヘッダを取り出し、取り出したファイルヘッダ毎に以下の処理を行う。なお、以下の処理は、Ｃｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）に含まれる全てのファイルヘッダに対して行われる。
【００７３】
（処理３） （処理２）で取り出したファイルヘッダのＮａｍｅ情報と、Ｇａｍｅ．ａｄｆ（３２００）に含まれるファイルのうち、アプリラウンチャにおいてアプリ名一覧と共に表示されるアイコンファイルのファイル名を示す情報（つまりｉｃｏｎ．ｇｉｆ））が一致しない場合は、該当するファイルヘッダに対応するファイルに対する使用情報として、Ｎａｍｅ＝ファイルヘッダに含まれるＮａｍｅ情報、ＭａｘＣｏｕｎｔ＝−１、Ｃｏｕｎｔ＝０を生成し、Ｇａｍｅ．ｄａｔ（７３００）の末尾に追加する。なお、ＭａｘＣｏｕｎｔの値が−１の場合は、使用情報のＮａｍｅの値であるファイル名に該当するファイルについては、使用回数の上限は無いことを示すものとする。本例においては、後述する（処理４）にて示すｉｃｏｎ．ｇｉｆを除く全てのＧａｍｅ．ｊａｒが含むファイルについては、本初期化処理を行うこととなる（例えばＧａｍｅ．ｃｌａｓｓの使用情報７３１０）。
【００７４】
（処理４） （処理２）で取り出したファイルヘッダのＮａｍｅ情報と、Ｇａｍｅ．ａｄｆ（３２００）に含まれるアイコンファイルのファイル名を示す情報（つまりｉｃｏｎ．ｇｉｆ）が一致する場合は、該当するファイルヘッダに対応するファイルに対する使用情報として、Ｎａｍｅ＝ファイルヘッダに含まれるＮａｍｅ情報、ＭａｘＣｏｕｎｔ＝０、Ｃｏｕｎｔ＝０を生成し、Ｇａｍｅ．ｄａｔ（７３００）の末尾に追加する。ＭａｘＣｏｕｎｔの値を０とするのは、当該ファイルがＪａｖａ（登録商標）アプリＧａｍｅの実行過程で一度も使用されないファイルであることを示すためである。アイコンファイルは、アプリ実行時ではなくアプリラウンチャの一覧表示のグラフィカル化を目的として使用されるものであるため、このような処理としている。本実施の形態においては、（処理２）で取り出したファイルヘッダが、ｉｃｏｎ．ｇｉｆファイルヘッダの場合は、（処理４）を行うこととなる。
【００７５】
Ｇａｍｅ．ｊａｒ（３１００）とＧａｍｅ．ａｄｆ（３２００）を用いて、(処理１)〜（処理４）を適用すると、ｉｃｏｎ．ｇｉｆファイルヘッダについてのみ、（処理４）がなされ、ｉｃｏｎ．ｇｉｆファイルヘッダに対応するファイル使用情報７３２０に含まれるＮａｍｅの値は“ｉｃｏｎ．ｇｉｆ”、ＭａｘＣｏｕｎｔの値は０、Ｃｏｕｎｔの値は０となり、ｉｃｏｎ．ｇｉｆファイルヘッダ以外のファイルヘッダには（処理３）が適用される（図７参照）。
【００７６】
なおアイコンファイル以外にも、アプリ実行中に使用しないファイル名をＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））に定義し、定義したファイル名に対し（処理１）〜（処理４）の手順を適用すればアプリ実行中に利用しないファイルについて、ＭａｘＣｏｕｎｔの値を０としたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を生成することが可能となる。
【００７７】
（２）分離対象ファイル名リストの生成
次にファイル使用情報更新部１１１１は、ファイル分離判定部１１１２へパッケージ化アプリ及び当該パッケージ化アプリのアプリ記述ファイルを引数として、ファイル分離の実施を要求する（Ｓ５００５）。
【００７８】
ファイル分離実施の要求を受けたファイル分離判定部１１１２は、ファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を用いて分離対象ファイルを決定し、分離対象ファイルのファイル名リストを生成し（ステップＳ５１０１）、ファイル名リストに列挙するファイルをパッケージ化アプリから分離すため、生成した当該パッケージ化アプリの分離対象ファイル名リストを引数として、ファイル分離部１１１３へファイルの分離を要求する（Ｓ５１０２）。
【００７９】
図８は、ステップ（Ｓ５１０１）において、ファイル使用情報を用いて分離対象ファイルを決定し、分離対象ファイルのファイル名リストを生成する具体例を説明するための図である。
【００８０】
まず、インターバルチェックにより、インターバル定数Ｉに規定の回数（またはその倍数）になった場合には、ファイル分離判定処理を実施し、そうでなければ処理を終了する（Ｓ８００１）。
【００８１】
ファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））のＬａｕｎｃｈｅｄＣｏｕｎｔ（７３０１）の値をインターバル定数であるＩで割り、余りが０の場合のみ、以下の処理（ステップ（Ｓ８００２）〜ステップ（Ｓ８００６））を実行するものとする。ファイル分離判定の要求は、Ｊａｖａ（登録商標）アプリダウンロード時、及びＪａｖａ（登録商標）アプリの実行が終了する度にされるが、ファイル使用情報の内容はＪａｖａ（登録商標）アプリ実行の度に大きく変化するものではないため、Ｊａｖａ（登録商標）アプリダウンロード時、及びインターバル定数Ｉで示されるＪａｖａ（登録商標）アプリ起動回数毎にファイル分離判定を実施するよう、本判定処理を設けている。
【００８２】
本判定処理は、ファイル使用情報に含まれる各ファイルの使用情報ｕｉについて、ファイル分離判定処理を実施する（Ｓ８００２）。
【００８３】
Ｇａｍｅ．ｄａｔ（７３００）に含まれる各ファイルの使用情報を先頭から順に取り出し、取り出したファイルの使用情報ｕｉに含まれるＭａｘｃｏｕｎｔが−１であるか否かを調べ、−１である場合は、後述するステップ（Ｓ８００５）へ進み、そうでない場合は、後述するステップ（Ｓ８００４）へ進む（Ｓ８００３）。
【００８４】
取り出した使用情報に含まれるＣｏｕｎｔの値が取り出した使用情報に対応するファイルの最大使用回数に対応するＭａｘｃｏｕｎｔの値よりも大きいかどうかを調べ（Ｓ８００４）、Ｍａｘｃｏｕｎｔの値以下であれば後述するステップ（Ｓ８００５）へ進み、そうでなければ後述するステップ（Ｓ８００６）へ進む（Ｓ８００４）。
【００８５】
取り出した使用情報に含まれるＣｏｕｎｔの値が所定回数よりも大きいかどうかを調べ（Ｓ８００５）、所定回数以下であれば、後述するステップ（Ｓ８００６）へ進み、所定回数よりも大きければ、次に取り出すべきファイルの使用情報があればこれを取り出して、ステップ（Ｓ８００２）へ戻り、同様の処理を繰り返し、そうでなければ処理を終了する。
【００８６】
ここで、ステップ（Ｓ８００５）においては、所定回数というのを、アプリの起動回数（Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ）に所定定数（分離定数Ｘとも）を乗じた値としている。例えば分離定数Ｘの値を０．１とすると、アプリの起動回数が１０回である場合に、対象となるファイルのアクセス回数が１回以下の（つまり利用頻度の少ないもの）が後述するステップ（Ｓ８００６）へ進むことになる。
【００８７】
次に、ステップ（Ｓ８００４）の判断がＹｅｓ、またはステップ（Ｓ８００５）の判断がＮｏの場合、取り出した使用情報に含まれるＮａｍｅを分離対象ファイル名リストに加えた（ステップＳ８００６）後、次に取り出すべきファイルの使用情報があればこれを取り出して、ステップ（Ｓ８００２）からの処理を繰り返し、次に取り出すべきファイルの使用情報がなければ処理を終了する。
【００８８】
このような処理を行うことにより、分離対象ファイル名リストにはアプリの実行中に利用がなされないファイル、最大使用回数を超えたファイル、利用頻度の低いファイルが加えられるようになる。
【００８９】
この例では、図７に示すファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））を用いて分離対象ファイル名リスト９１００を生成した場合、ダウンロード時において図８に示したフローチャートを実行すると、分離対象ファイル名リスト９１００に、ｉｃｏｎ．ｇｉｆのファイル使用情報７３２０に含まれるＮａｍｅ９１０１（ファイル名“ｉｃｏｎ．ｇｉｆ”）が追加され、その後、起動を重ねるに従って、最大使用回数を超えたファイル、利用頻度の低いファイルが加えられるようになる（図９参照）。また、本判定からＭａｘＣｏｕｎｔの値が−１の場合を除いているのは、本値−１は上記の通り、ファイルの最大使用回数を設定しない、すなわちファイルの使用回数の上限がないことを示すものであるためである。
【００９０】
（３）ファイルの分離
分離対象となるパッケージ化アプリ、及び図８（またはステップＳ５１０１）で説明した処理にて生成した当該パッケージ化アプリの分離対象ファイル名リストを引数として、ファイルの分離の要求をファイル分離情報判定部１１１２から受け取ると、ファイル分離部１１１３は、これら引数情報に基づき、分離後のパッケージ化アプリ及び分離されたファイル群より元のパッケージ化アプリを復元するための情報である復元情報を生成する。更に、パッケージ化アプリより当該パッケージ化アプリの分離対象ファイル名リスト９１００で列挙されるファイル名のファイル群を抽出し、パッケージ化アプリより分離対象ファイル名リスト９１００で列挙されるファイル名にて構成されるファイル群のファイルエントリ及びファイルヘッダを削除する。
【００９１】
以下では、図５のシーケンス（特にステップ（Ｓ５２０１）〜ステップ（Ｓ５２０７））に基づき、図１０、図１１、図１２、図１３を用いて上記処理の詳細を説明する。
【００９２】
ファイル分離部１１１３は、ファイル分離情報判定部１１１２からファイル分離の要求を受け取ると、復元情報を生成する（Ｓ５２０１）。
【００９３】
図１０は、パッケージ化アプリに対応するＪＡＲファイル（Ｇａｍｅ．ｊａｒ（３１００））の復元情報の生成を示す。後述の処理を行うことによりＧａｍｅ．ｊａｒ（３１００）からファイルが抽出され、抽出されたファイルに関するファイルエントリがＪＡＲファイルより削除されるが、ＪＡＲファイル（３１００）においては、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）と、抽出されたファイル群があれば元のＪＡＲファイルへの復元可能であることから、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）を含む情報を復元情報とする。
【００９４】
Ｊａｖａ（登録商標）アプリＧａｍｅの復元情報に対応するＧａｍｅ．ｉｎｆｏ（１０２００）は例えば、Ｇａｍｅ．ｊａｒ（３１００）のＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ（３１１０）及びＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙ（３１４０）を取り出し、これらを連結した情報である。
【００９５】
次に、ファイル分離部１１１３は、分離対象ファイル名リストで列挙されたファイル名のファイル群を抽出する（Ｓ５２０２）。
【００９６】
図１１は、ＪＡＲファイルＧａｍｅ．ｊａｒ（３１００）を用いて、ファイル分離判定部１１１２にて生成したＧａｍｅ．ｊａｒ（３１００）の分離対象ファイル名リスト９１００に基づき、分離対象ファイル名リスト９１００に含まれるファイル名９１０１対応するファイルエントリ（図９の例ではｉｃｏｎ．ｇｉｆ（３１３２）等）を抜き出して分離対象ファイル群１１３００を作成し、分離対象ファイル群１１３００を必要に応じて展開して、抽出後ファイル群１１４００を生成する様子を示すものである。ここで展開とは、圧縮化、暗号化されたデータを、解凍、復号することにより、圧縮、暗号化前のデータに復元することである。ＪＡＲファイルにおいては、通常ファイルエントリは、無圧縮、及びＤＥＦＬＡＴＥ圧縮アルゴリズムで圧縮された形態をとる。本実施の形態においては、分離対象ファイル群１１３００のファイルエントリｉｃｏｎ．ｇｉｆ（３１３２）等を、これが無圧縮ならそのまま、ＤＥＦＬＡＴＥ圧縮アルゴリズムにより圧縮されている場合は、そのアルゴリズムに基づいて展開することで、抽出後ファイル群１１４００に含まれるファイルｉｃｏｎ．ｇｉｆ（１１４０１）等を生成することがｉｃｏｎ．ｇｉｆ（１１３０１）等の展開に相当する。なお、ファイルエントリの圧縮形式・暗号化形式は、ＪＡＲのＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに設定されるため、展開はここに設定された圧縮形式・暗号化形式に対応する解凍・復号エンジン（図示せず）によって解凍すればよい。
【００９７】
なお上記抽出されたファイル群をデータ記憶部１２００へ格納する具体的な手段として、図１４では“ｒｅｓｏｕｒｃｅｓ”フォルダの中にファイル毎に格納する手法を例示している。このように構成することにより、アプリラウンチャ等にてパッケージ化アプリに含まれるアイコンを一覧表示する際等において、対応するファイル（“ｒｅｓｏｕｒｃｅｓ”フォルダの中のｉｃｏｎ．ｇｉｆ）の表示処理を高速化することができる。
【００９８】
本実施の形態では、抽出されたファイル群を格納する具体的手段として、上述の記載にのみ限定するものではなく、例えば分離によって生成されたファイル群を連結し１ファイルとして格納することとしてもよい。このような格納手法を採用した場合、ファイルの格納がクラスタ単位で行われるファイルシステムにおいて、データ記憶部１２００（例えばＦｌａｓｈＲＯＭ）の消費量を削減する効果が期待できる。
【００９９】
次に、ファイル分離部１１１３は、分離対象ファイル名リスト９１００を用いて抽出したファイル群及びファイル群に含まれるファイルエントリに対応するファイルヘッダをパッケージ化アプリ（この例ではＧａｍｅ．ｊａｒ（３１００））から削除する（Ｓ５２０３）。
【０１００】
図１２は、Ｇａｍｅ．ｊａｒ（３１００）より、分離対象ファイル名リスト９１００で列挙されるファイル名（ｉｃｏｎ．ｇｉｆ（９１０１）等）に対応するファイルエントリ（ｉｃｏｎ．ｇｉｆ（３１３２））及びこれに対応するファイルヘッダ（ｉｃｏｎ．ｇｉｆファイルヘッダ）を削除し、新たに生成した（または更新した）Ｇａｍｅ．ｊａｒ（１２２００）の一例を示すものである。
【０１０１】
これにより、ステップ（Ｓ５２０３）で抽出されたファイル群、及びファイル群に含まれるファイルエントリに対応するファイルヘッダに関するデータがＪＡＲファイルより削除されるため、ＪＡＲファイルのサイズが縮小される。なお、上記ファイルエントリ１２１０１削除に伴い、更新したパッケージ化アプリに含まれるファイルヘッダに格納するＯｆｆｓｅｔを更新する必要がある。ファイルエントリより後ろに配置されるファイルエントリ群１２１０３に対応するファイルヘッダ１２１０４については、ファイルヘッダの構成情報であるＯｆｆｓｅｔをファイルエントリ削除後の値に更新する必要がある。
【０１０２】
次に、ファイル分離部１１１３は、更新したパッケージ化アプリをアプリ記憶部１２１０へ書き出す前に、復元確認を行う（Ｓ５２０４）。
【０１０３】
更新したパッケージ化アプリをアプリ記憶部１２１０へ書き出すことは、ファイル抽出前のパッケージ化アプリに更新したパッケージ化アプリを上書きすることになるため、その前に復元可能性の確認を行う趣旨による。
【０１０４】
本チェックは、ファイル復元部１１２０によって、パッケージ化アプリや、上記復元情報等を用いて復元を行い、復元後のパッケージ化アプリと元のパッケージ化アプリが完全に一致するかどうかを確認することで実現される。ファイル復元手順の詳細は、実施の形態４を参照願いたい。
【０１０５】
ステップ（Ｓ５２０４）により、ファイル復元可能と判断した場合には、後述するステップ（Ｓ５２０５）〜ステップ（Ｓ５２０７）の処理を実施する。
【０１０６】
まず、データ記憶部１２２０へステップ（Ｓ５２０２）にて、パッケージ化アプリから抽出したファイル群（この例ではｉｃｏｎ．ｇｉｆファイル）を分離ファイル部１２２２（例えば図１４に示す“ｒｅｓｏｕｒｃｅｓ”フォルダ内）の配下に格納する（Ｓ５２０５）。
【０１０７】
次に、ステップ（Ｓ５２０３）にて更新したパッケージ化アプリを更新前のパッケージ化アプリ（例えば図１４に示す“ａｐｐ”フォルダ内）に上書きをする（Ｓ５２０６）。
【０１０８】
次に、パッケージ化アプリより分離されたファイル群を示す分離対象ファイル名リスト９１００に含まれるファイル名より構成される分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））を生成し、分離ファイル部１２２２（例えば図１４に示す“Ｇａｍｅ”フォルダ内）へ書き出す（Ｓ５２０７）。
【０１０９】
なお、既に前回のファイル分離処理実施においてＧａｍｅ．ｌｉｓｔ（１２４００）が生成されている場合、今回の分離処理実施によって新たに分離したファイル群のファイル名を追加し、Ｇａｍｅ．ｌｉｓｔ（１２４００）に上書きすることとする。
【０１１０】
図１３は、本実施の形態にて、Ｊａｖａ（登録商標）アプリＧａｍｅのＪＡＲファイルＧａｍｅ．ｊａｒ（３１００）から更新されたＪａｒファイル（Ｇａｍｅ．ｊａｒ（１２２００））、生成されたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））、生成された復元情報（Ｇａｍｅ．ｉｎｆｏ（１０２００））、生成された分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００）、抽出後ファイル群１１４００の一例を説明するための図である。
【０１１１】
図１４は、上述のファイルを格納するデータ記憶部１２００の一例を示す図である。
【０１１２】
生成されたファイル使用情報（Ｇａｍｅ．ｄａｔ（７３００））は、ファイル使用情報部１２２１（この例では“ｈｏｍｅ”フォルダの中の“ｊａｖａ”フォルダの中にある“ｉｎｆｏ”フォルダに含まれる“ｕｓｅｉｎｆｏ”フォルダ内（または／ｈｏｍｅ／ｉｎｆｏ／ｕｓｅｉｎｆｏ／配下のデータ領域））に格納される。
【０１１３】
また、生成された復元情報（Ｇａｍｅ．ｉｎｆｏ（１０２００））、は分離ファイル部１２２２（この例では“ｈｏｍｅ”フォルダの中の“ｊａｖａ”フォルダの中にある“ｉｎｆｏ”フォルダに含まれる“ｄａｔ”フォルダ内（または／ｈｏｍｅ／ｉｎｆｏ／ｄａｔ／Ｇａｍｅ 配下のデータ領域））に格納される。
【０１１４】
また、生成された分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））は、分離ファイル部１２２２に格納される。
【０１１５】
また、抽出後ファイル群１１４００（例えばｉｃｏｎ．ｇｉｆ（３１３２）等）は上述の“Ｇａｍｅ”フォルダの中の“ｒｅｓｏｕｒｃｅｓ”フォルダ内に格納される。
【０１１６】
このようなファイル構成とすることにより、アプリラウンチャ等ＪＡＲファイル群よりそのアイコンファイル等を取り出し表示する形態をとるアプリケーションの実行速度を改善することが可能である。これは、アプリラウンチャ等は、ＪＡＲファイルからアイコンファイルを抽出する代わりに、分離ファイル部１２２２へアクセスして既に抽出がなされたアイコンファイルを取得することが可能となるためである。
【０１１７】
また、ＪＡＲファイルから抽出がなされて分離ファイル部１２２２へ書き出したファイル群については、そのファイル群に関するデータがＪＡＲファイルより削除されるため、従来技術において説明をしたようにアイコン情報等と、インデックス用ファイルで同用途のファイルの二重持ちが発生しない。また本実施の形態では、パッケージ化アプリの実行時において、一時記憶部（ＦｌａｓｈＲＯＭ等の不揮発記憶領域）の使用量の削減の効果が期待できる。
【０１１８】
なお上記では、アイコンファイルやテキストファイル等、アプリ実行時には利用されないファイルをパッケージ化アプリより分離する手順について説明したが、本発明はこのようなアプリ実行用途以外のファイルに加え、アプリ実行時に付随して利用されるようなファイルの分離にも適用可能である。例えば、Ｊａｖａ（登録商標）アプリに係るＪＡＲファイル内に共有ライブラリ（ＤＬＬ等）が含まれている場合、本共有ライブラリを分離対象とすることで実施の形態１の場合と同様の効果を得ることが出来る。
【０１１９】
特に共有ライブラリはその性質上、ファイルシステム上へ展開・配置しなければＪａｖａ（登録商標）アプリ等より利用することが出来ないことから、本手順によってあらかじめファイルシステム上へ配置することで、共有ライブラリのオープンに要する時間を短縮することが可能となる。
【０１２０】
（実施の形態２）
本実施の形態では、実施の形態１で説明したアプリケーション実行装置１０００において、所定のファイルを分離し、更新したパッケージ化アプリをアプリ実行エンジン１３２０で実行する場合において、この更新したパッケージ化アプリに係るアプリがパッケージ化アプリより分離されたファイルへのアクセスを要求する場合の処理について説明する。
【０１２１】
なお、以下では実施の形態１にてダウンロードしたＪａｖａ（登録商標）アプリＧａｍｅに含まれるパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（３１００））からアイコンファイルを分離したＧａｍｅ．ｊａｒ（１２２００）に係るＪａｖａ（登録商標）アプリＧａｍｅの起動及び、実行過程を例にとり、図１４、図１５、図１６、図１７、図１８、図１９、図２０を用いて説明を行う。特にデータ記憶部１２００には図１４に示すような構造にてデータが格納されているものとする。
【０１２２】
（１）アプリの起動
アプリ実行部１３００のアプリ起動処理部１３１０は、アプリ起動要求部１４２０等のアプリ起動手段（アプリラウンチャ等）よりアプリの起動要求を受け取ることにより、ファイルアクセス部１３３０へ起動要求アプリに係るパッケージ化アプリ及び、当該パッケージ化アプリに対応するアプリ記述ファイルの読込みを要求し、本読込まれたファイル群をアプリ実行エンジン１３２０へ渡してアプリの実行を開始する。以下、本処理手順の詳細については、図１５に示すフローチャートを用いて説明を行う。
【０１２３】
（１−１）アプリ起動に要するファイルをデータ記億部１２００より取得する
アプリ起動処理部１３１０は、例えばパッケージ化アプリの要求を受け付けると、必要なファイル（起動要求アプリのパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（１２２００））及び当該パッケージ化アプリのアプリ記述ファイル（３２００））をデータ記憶部１２００より取得をすることをファイルアクセス部１３３０へ要求する（Ｓ１５１０１）。
【０１２４】
例えば、Ｊａｖａ（登録商標）アプリＧａｍｅの起動要求を受け付けたアプリ起動処理部１３１０は、ファイルアクセス部１３３０へＪＡＲファイルＧａｍｅ．ｊａｒ（１２２００）及びＡＤＦファイルＧａｍｅ．ａｄｆ（３２００）の読込みを要求する。
【０１２５】
ファイル読込みの要求を受けたファイルアクセス部（１３３０）は、アプリ記憶部（１２１０）より、ＪＡＲファイル（Ｇａｍｅ．ｊａｒ（１２２００））及びＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））の読込みを行う（Ｓ１５２０１）。
【０１２６】
次に、分離ファイル情報アクセス部１３３１は、分離ファイル部１２２２に起動要求アプリに係る情報が格納されているか否かを確認し、これが格納されている場合は、本起動要求アプリに係る情報を元に分離ファイル情報テーブル１３３２を生成する。
【０１２７】
具体的には、分離ファイル部１２２２にＪａｖａ（登録商標）アプリＧａｍｅに関するファイル群（Ｇａｍｅ．ｉｎｆｏ（１０２００）、Ｇａｍｅ．ｌｉｓｔ（１２４００）、ｉｃｏｎ．ｇｉｆ（３１３２））が格納されているかどうかを確認し、これが格納されている場合は、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔ（１２４００）を取得し、本ファイルの内容に基づく分離ファイル情報テーブル１３３２を生成し、分離ファイル情報アクセス部１３３１内に格納する（Ｓ１５２０２）。
【０１２８】
分離ファイル情報テーブル１３３１は、分離抽出処理により、Ｇａｍｅ．ｊａｒより分離されたファイル名の一覧を保持するためのテーブルであり、後述のＪＡＲファイルより分離されたファイルへＪａｖａ（登録商標）アプリがアクセスするための処理を実現するために利用される。
【０１２９】
実施の形態１にて生成したＧａｍｅ．ｌｉｓｔ（１２４００）に基づく場合、ファイル名“ｉｃｏｎ．ｇｉｆ”等の分離対象のファイルを構成要素とするファイル分離情報テーブル（１３３２）を生成し、分離ファイルアクセス部１３３１内に格納されることとなる。
【０１３０】
上記処理の後、ファイルアクセス部１３３０は、アプリ起動処理部１３１０へアプリ記憶部１２１０より取得したパッケージ化アプリ及び当該パッケージ化アプリのアプリ記述ファイルを引き渡す（Ｓ１５２０２）。
【０１３１】
具体的には、ＪＡＲファイル（Ｇａｍｅ．ｊａｒ（１２２００））及びＡＤＦファイル（Ｇａｍｅ．ａｄｆ（３２００））を引き渡す。
【０１３２】
ステップ（Ｓ１５２０２）にて、アプリ起動に要するファイルを引き渡されたアプリ起動処理部１３１０は、取得したファイルを伴った起動要求をアプリ実行エンジン１３２０へ発行する（Ｓ１５１０２）。
【０１３３】
起動要求を受けたアプリ実行エンジン１３２０は、受け取ったパッケージ化アプリ及び当該パッケージ化アプリに係るアプリ記述ファイルを一時記憶部１３２１のパッケージ化アプリ部１３２２、アプリ記述ファイル部１３２３に各々書き出す（Ｓ１５３０１）。
【０１３４】
具体的には、ファイルアクセス部１３３０より、Ｇａｍｅ．ｊａｒ（１２２００）及びＧａｍｅ．ａｄｆ（３２００）を受け取ったアプリ起動処理部は、これら受け取ったファイル群を引数として、アプリ実行エンジン１３２０へＪａｖａ（登録商標）アプリＧａｍｅの起動要求を発行する。
【０１３５】
ＪＡＲファイルＧａｍｅ．ｊａｒ（１２２００）及びＡＤＦファイルＧａｍｅ．ａｄｆ（３２００）を受け取ったアプリ実行エンジン１３２０は、これらファイルの内容を一時記憶部１３２１へ書き出す。図１７はＪａｖａ（登録商標）アプリＧａｍｅ起動時の一時記憶部１３２１の内容を示すものである。Ｇａｍｅ．ｊａｒを一時記憶部１３２１へ書き出し、この記憶領域がパッケージ化アプリ部１３２２に相当し、Ｇａｍｅ．ａｄｆ（３２００）を一時記憶部１３２１へ書き出し、この記憶領域がアプリ記述ファイル部１３２３に相当する。
【０１３６】
次にアプリ実行エンジン１３２０は、一時記憶部１３２１に書き出されたパッケージ化アプリ部１３２２及び、アプリ記述ファイル部１３２３を元に、パッケージ化アプリよりメインモジュールに関するファイルを抽出し、これを一時記憶部１３２１へ書き出し、この記憶領域がメインモジュール部１３２４に相当するものとなる（Ｓ１５３０２）。
【０１３７】
具体的には、アプリ実行エンジン１３２０は、アプリ記述ファイル部１３２３に格納されたＧａｍｅ．ａｄｆ（３２００）の構成要素であるメインクラス名Ｇａｍｅ．ｃｌａｓｓ１７２０１に対応するファイルエントリであるＧａｍｅ．ｊａｒ（１２２００）（パッケージ化アプリ部１３２２に格納されている）のＧａｍｅ．ｃｌａｓｓ（１７１０１）を抽出し、これを一時記憶部１３２１の適当な未使用領域へメインクラスとして書き出し、これがモジュール部１３２４の一部として機能する。
【０１３８】
最後に、アプリ実行エンジン１３２０は、一時記憶部１３２１に書き出されたモジュール部１３２４より、エントリポイントとなる処理部を特定し、その特定された箇所よりアプリの実行を開始する（Ｓ１５３０３）。
【０１３９】
具体的には、上記手順により一時記憶部１３２１に書き出されたメインクラス部のエントリポイントとなるメソッドであるｓｔａｒｔ（）メソッド１７３０１が格納された箇所よりバイトコードの実行を開始する。
【０１４０】
図１８は、本発明の適用による一時記憶部の使用量の削減について、Ｊａｖａ（登録商標）アプリＧａｍｅの例を当てはめたものである。本発明適用後のＧａｍｅ．ｊａｒ１２２００には、本発明適用前のＧａｍｅ．ｊａｒに含まれていたアイコンファイルｉｃｏｎ．ｇｉｆ等が分離対象ファイルとして分離された後、一時記憶部１３２１に書き出されるため、分離されるファイルに相当するデータ量分、一時記憶部１３２１に空き領域とすることができる。この空き領域を他のデータに割り当てることができるようになり、一時記憶部１３２１をより効率よく使用することが可能となる。
【０１４１】
（２）アプリ実行過程におけるアプリに係るパッケージ化アプリより分離されたファイルへのアクセス
ファイルアクセス部１３３０は、アプリ実行エンジン１３２０にて実行中のアプリより、当該アプリに係るパッケージ化アプリより分離されたファイルへのアクセス要求を受け付けた場合、分離ファイル部１２２２よりファイルを読込む。図１９は、本手順の詳細を説明するための図である。図１９においてステップ（Ｓ１９１０１）、ステップ（Ｓ１０１０２）は主としてアプリ実行エンジン１３２０において行われ、ステップ（Ｓ１９２０１）〜ステップ（Ｓ１９２０５）は主としてファイルアクセス部１３３０において行われるものであり、特にステップ（Ｓ１９２０１）〜ステップ（Ｓ１９２０３）は主として分離ファイル情報アクセス部１３３１において行われるものである。
【０１４２】
（２−１）アプリによるファイル読込み要求を発行
アプリ実行エンジン１３２０にて実行中のアプリは、必要に応じてファイルアクセス部１３３０へファイルの読込みを要求する（Ｓ１９１０１）。
【０１４３】
図１９は、Ｊａｖａ（登録商標）アプリの一形態であるｉアプリ（Ｒ）における、当該ｉアプリに係るＪＡＲファイルからファイルを読込む手順を伴うメソッドｓｔａｒｔ（）の実装例を示す。なお、ここでは一例としてｉアプリを挙げているが、このようにＪＡＲファイルからファイルを取得する手順自体はｉアプリに限定されたものではない。ｉアプリ以外のＪａｖａ（登録商標）アプリの形態であるＭｉｄｌｅｔ等においても、ＪＡＲファイルからのファイル読込みに関する手順は用意されており、以下で記述する手順を実施することは可能である。
【０１４４】
ｉアプリは、ＤｏＪａ（Ｒ）仕様に基づいて作成されたＪａｖａ（登録商標）アプリであり、ＤｏＪａライブラリを利用してｉアプリに係るＪＡＲファイルよりファイルを読込むことが可能である。具体的には、ＤｏＪａライブラリＲｅｓｏｕｒｃｅＭａｎａｇｅｒクラスのメソッドｇｅｔＩｍａｇｅ（）等のメソッドを利用して、ＪＡＲファイルが含有するイメージファイル等を取得することが可能である。
【０１４５】
上記メソッドｇｅｔＩｍａｇｅ（）は、引数として与える文字列の内容により、ファイル読込み元を指定することが出来る。図２０におけるｇｅｔＩｍａｇｅ（）メソッド呼出においては、引数として“ｒｅｓｏｕｒｃｅ：／／／ｉｃｏｎ．ｇｉｆ”を指定している（図２０に示す２０１００）。本文字列において“ｒｅｓｏｕｒｃｅ：／／”は、当該ｉアプリに係るＪＡＲファイルをファイルの読込み元として指定するものである。また、“／ｉｃｏｎ．ｇｉｆ”は、当該ｉアプリに係るＪＡＲファイルのルートフォルダに格納されるｉｃｏｎ．ｇｉｆを読込み対象ファイルとして指定するものである。
【０１４６】
（２−２）パッケージ化アプリより分離されたファイルの読込み
分離ファイル情報アクセス部１３３１は、ステップ（Ｓ１９１０１）にて読込みを要求されたファイルの読込み元が実行中アプリに係るパッケージ化アプリであるかどうかを判定し、パッケージ化アプリである場合には、後述するステップ（Ｓ１９２０２）へ進み、パッケージ化アプリでない場合には、後述するステップ（Ｓ１９２０４）へ進む（Ｓ１９２０１）。
【０１４７】
ステップ（Ｓ１９２０１）において、読込み元が実行中アプリに係るパッケージ化アプリであると判定した場合、分離ファイル情報テーブル１３３２に、読込み要求ファイル名が含まれるか否かを判定し（Ｓ１９２０２）、含まれる場合は、分離ファイル部より該当する読込み要求ファイルを読込む（Ｓ１９２０３）。
【０１４８】
具体的には、図２０に示すメソッドｇｅｔＩｍａｇｅ（）２０１００によりファイル読込み要求を受け付けたファイルアクセス部１３３０の分離ファイル情報アクセス部１３３１は、ファイル読込み元がＪＡＲファイルか否かを確認する。メソッドｇｅｔＩｍａｇｅ（）２０１００は、ファイル読込み元としてＪＡＲファイル、ファイル名としてｉｃｏｎ．ｇｉｆを指定するものであるため、本条件を満たす。
【０１４９】
次に分離ファイル情報アクセス部１３３１は、分離ファイル情報テーブル１３３２に、読込み要求ファイル名ｉｃｏｎ．ｇｉｆが含まれるか否かを確認する。上記手順（１）の（１−１）にて示したとおり、ｉｃｏｎ．ｇｉｆは、分離ファイル情報テーブル１３３２に含まれるため、本条件も満たす。以上の要件を満たすため、分離ファイル情報アクセス部１３３１は、「ｉｃｏｎ．ｇｉｆは、ＪＡＲファイル内部には存在せず、分離ファイル部に格納されている」と認識し、分離ファイル部のＪａｖａ（登録商標）アプリＧａｍｅに関する部分（つまり、例えば図１４に示すような“ｒｅｓｏｕｒｃｅｓ”フォルダ内に格納された）ｉｃｏｎ．ｇｉｆを読込む。
【０１５０】
（３）（２）以外のファイルの読込み
ファイル読込み元がパッケージ化アプリ以外、もしくはファイル読込み元はパッケージ化アプリだが、分離されたファイルではない場合は、指定されたファイル読込み元よりファイルの読込みを行う（Ｓ１９２０４）。本ファイル読込み処理は、本発明を実施しない場合においても行うべき通常のファイル読込み処理である。
【０１５１】
（４）読込んだファイルの内容を一時記憶部１３２１への格納
（２）、もしくは（３）の手順で、データ記憶部１２００及び一時記憶部１３２１内のパッケージ化アプリ部１３２２より読込んだファイルの内容を一時記憶部１３２１の空き領域へ格納する（Ｓ１９２０５、Ｓ１９１０２）。本一時記憶部１３２１への格納処理は、本発明を実施しない場合においても行うべき通常のメモリコピー処理である。
【０１５２】
上記一連の手順によって、実行中のアプリが読込みを要求したファイルの内容が一時記憶部１３２１に格納される。上記処理により、実行中のアプリは、読込みを要求したファイルの読込み元がパッケージ化アプリであり、且つ読込みを要求したファイルがパッケージ化アプリより分離されたものであっても、分離されることなくパッケージ化アプリに含まれるファイルへのアクセスと同一の手順でファイルの読込みが可能である。
【０１５３】
（実施の形態３）
本実施の形態では、図１に記載の本発明によるアプリケーション実行装置１０００にて、本実施の形態１の手順によってファイルの分離を行ったパッケージ化アプリに係るアプリをアプリ実行エンジン１３２０で実行する過程において、このパッケージ化アプリに係るアプリが実行中に殆ど利用しないファイルであって当該パッケージ化アプリに含まれるものについては、ファイルの分離対象とすべくファイル使用情報の更新を行い、本ファイル使用情報に従ってファイルの分離する際の処理手順を説明する。
【０１５４】
なお、以下では本実施の形態１にてアイコンファイルを分離したＧａｍｅ．ｊａｒ（１２２００）に係るＪａｖａ（登録商標）アプリＧａｍｅの実行過程、及び実行後のファイル使用情報の更新とファイルの分離を例にとり、図２１、図２２、図２３、図２４、図２５、図２６、図２７を用いて説明を行う。このＧａｍｅ．ｊａｒ（１２２００）が含むファイルエントリｒｅａｄｍｅ．ｔｘｔはＪａｖａ（登録商標）アプリＧａｍｅ実行時に利用されないファイルであるとする（アプリラウンチャにおけるアプリ動作説明に利用されるテキストファイルである）。
【０１５５】
（１）ファイルアクセスの監視
実行中のアプリに係るパッケージ化アプリ含まれるファイルについて、そのファイルがアプリの実行中に殆ど利用されないものであるか否かを判定するために、ファイルアクセス監視部１３４０は、ファイルアクセス部１３３０よりファイルアクセス発生に関する情報を受け取り、受け取った情報に基づいてファイルアクセス監視テーブル１３４１の内容を更新することで、アプリ実行中にアクセスが発生した実行中のアプリにかかるパッケージ化アプリに含有されるファイルを特定可能な情報を構築することが出来る。
【０１５６】
図２１はアプリからのファイル読込み要求発生時における、本ファイルアクセス監視の処理手順を示すものである。図２１において、図１９に示したフローチャートのステップの符号と同一のものは図１９に示したものと同じまたはこれに相当するものであるため、詳細な説明（特にＳ１９１０１、Ｓ１９２０１〜Ｓ１９２０３、Ｓ１９１０２の処理に関する説明）は省略する。
【０１５７】
図２１において、Ｓ１９２０４において、ファイル読込み元がパッケージ化アプリ以外、もしくはファイル読込み元はパッケージ化アプリだが、分離されたファイルではない場合は、指定されたファイル読込み元よりファイルの読込みを行った後、ファイルアクセス部１３３０におけるファイル読込み完了後アプリ実行エンジン１３２０へのファイル内容の返却前に、ファイルアクセス監視部１３４０へのファイルアクセスを実施したことを通知する（Ｓ２１１０１）。
【０１５８】
ファイルアクセスを実施したことの通知を受けたファイルアクセス監視部１３４０は、通知を受けたファイルアクセスがパッケージ化アプリに含まれるファイルへのアクセスであるかどうかをチェックする（Ｓ２１２０１）。
【０１５９】
Ｓ２１２０１において、通知を受けたファイルアクセスがパッケージ化アプリ内のファイルへのアクセスである場合には、後述するＳ２１２０２へ進み、そうでない場合はＳ１９２０５へ進む。
【０１６０】
Ｓ２１２０１において、通知を受けたファイルアクセスがパッケージ化アプリ内のファイルへのアクセスである場合、ファイルアクセス監視部１３４０が具備するファイルアクセス管理テーブル１３４１に、通知を受けたファイルにアクセスが発生した旨の情報を書き込む（Ｓ２１２０２）。
【０１６１】
Ｓ２１２０２において、書き込むが完了した後、Ｓ１９２０５へ進む。
【０１６２】
Ｓ１９２０５については図１９を用いて説明した内容と同じであるので、ここではその詳細な説明を省略する。
【０１６３】
このように構成することにより、アプリ実行中において、アクセスされるファイルを監視することが可能となる。
【０１６４】
ここでは、本実施の形態２にて示したＪａｖａ（登録商標）アプリＧａｍｅ実行中のファイル読込みを例にして、上記処理を具体的に説明する。
【０１６５】
アプリ実行中におけるファイルアクセスは、本実施の形態２にて示したように、明示的にアプリからファイルアクセスを要求する場合に限らず、アプリ実行エンジン１３２０によって内部処理としてファイルアクセスが行われる場合がある。
【０１６６】
Ｊａｖａ（登録商標）におけるクラスファイルのメモリへのロードがその一例である。Ｊａｖａ（登録商標）の場合、アプリ実行エンジン１３２０の具体的な一例であるＪａｖａ（登録商標）ＶＭは、起動するＪａｖａ（登録商標）アプリのメインクラス及びそのメインクラスのエントリポイントであるメソッドの実行に必要最低限のクラスファイルを読込んで一時記憶部１３２１へ格納し、そのＪａｖａ（登録商標）アプリのＪＡＲファイルに含まれるクラスファイルのうち一時記憶部１３２１へ格納しなかったその他のクラスファイルは、必要に応じてＪＡＲファイルから適宜読み出される。
【０１６７】
図２２は、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅに含まれるクラスにおいて、ソースコードの要部の一例を示すものである。
【０１６８】
図２２に示す例では、Ｊａｖａ（登録商標）アプリＧａｍｅのメインクラスであるＧａｍｅクラス２２１００は、エントリポイントであるｓｔａｒｔ（）メソッドを含む。Ｉｎｉｔｉａｌｉｚｅクラス２２２００は、前記ｓｔａｒｔ（）メソッドからのみ特定の条件を満たしたとき利用されるメソッドｉｎｉｔ（）を含む。Ｍａｉｎクラス２２２３０は、Ｊａｖａ（登録商標）アプリＧａｍｅのメイン処理であるｍａｉｎ（）メソッドを含む。
【０１６９】
ここでは、Ｊａｖａ（登録商標）アプリＧａｍｅ起動時の処理内容について上記ソースコード群を用いて説明する。まずＪａｖａ（登録商標）ＶＭよりＧａｍｅクラスのｓｔａｒｔ（）メソッドが呼び出される。ｓｔａｒｔ（）メソッドでは、まずＧａｍｅクラスの内部メソッドｉｓＩｎｉｔｉａｌｉｚｅｄ（）が呼び出される。本メソッドの詳細な内容については割愛するが、Ｊａｖａ（登録商標）アプリＧａｍｅの初期化処理が行われていない場合はｆａｌｓｅ、初期化処理が行われている場合はｔｒｕｅを返すものであるとする。
【０１７０】
その後ＩｓＩｎｉｔｉａｌｉｚｅｄ（）の戻り値によって初期化処理完了かどうかを取得し、初期化処理が未完了（戻り値がｆａｌｓｅ）の場合は、Ｉｎｉｔｉａｌｉｚｅクラスのメソッドｉｎｉｔ（）を、初期化処理が完了（戻り値がｔｒｕｅ）の場合は、Ｍａｉｎクラスのメソッドｍａｉｎ（）を呼び出す。
【０１７１】
ここで、Ｉｎｉｔｉａｌｉｚｅクラスのクラスファイル、Ｍａｉｎクラスのクラスファイルの読み込みは、それぞれＩｎｉｔｉａｌｉｚｅクラスのメソッドｉｎｉｔ（）の呼出、Ｍａｉｎクラスのメソッドｍａｉｎ（）の呼出の直前に行われる。
【０１７２】
すなわち、Ｉｎｉｔｉａｌｉｚｅクラスのクラスファイルの読み込みは、メソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）がｔｒｕｅを返す場合である、初回起動時、もしくは二回目以降の起動時であるが前回以前の起動において初期化処理が失敗した場合のみ行われ、クラスＩｎｉｔｉａｌｉｚｅクラスのクラスファイルの読み込みは行われない。
【０１７３】
一方クラスＭａｉｎについては、Ｊａｖａ（登録商標）アプリ起動時に必ず読込まれる。なお、以下説明の簡略化の為、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅのＪＡＲファイルに含まれる、上記に挙げたもの以外のクラスファイル及びリソースファイル（ｒｅａｄｍｅ．ｔｘｔを除く）については、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅ実行中に最低１度はロードが行われることとする。
【０１７４】
図２３は、例えば上記クラスファイルの読込みにより、ファイルアクセス監視テーブルの状態の変化を説明するための図である。図２３の２３１００は、Ｊａｖａ（登録商標）アプリＧａｍｅ初回起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブル１３４１の一例を示す。初回起動時においては、Ｉｎｉｔｉａｌｉｚｅクラス２３１０１を含め全てのクラスが読込まれるため、クラスファイルについてはすべてアクセス有が設定されている。一方、本実施例の前提部で説明したとおり、ｒｅａｄｍｅ．ｔｘｔ（２３１０２）はＪａｖａ（登録商標）アプリ実行時には使用されないファイルであるため、アクセスなしが設定される。
【０１７５】
Ｊａｖａ（登録商標）アプリＧａｍｅ２回目起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブル１３４１についても、初回起動時とほぼ同じ内容の設定となるが、二回目以降の起動においては、Ｉｎｉｔｉａｌｉｚｅクラスはロードされないため、本クラスに対する設定値はアクセスなしに更新される。Ｊａｖａ（登録商標）アプリＧａｍｅ１０回目起動時におけるＪａｖａ（登録商標）アプリ終了直後のファイルアクセス監視テーブルについては、２回目起動時の内容と同一である。
【０１７６】
（２）ファイルの分離
アプリ実行終了時処理において、アプリ実行エンジン１３２０は、アプリ終了に伴う処理（例えばリソースの解放に関する処理などであり、このような処理は本実施の形態に関わらず行われる処理である）を実施する（Ｓ２４１０１）。
【０１７７】
次に、アプリ実行エンジン１３２０は、ファイルアクセス監視部１３４０へ、ファイル使用情報の更新を要求する（Ｓ２４１０２）。
【０１７８】
本要求を受けたファイルアクセス監視部１３４０は、ファイルアクセス監視テーブル１３４１の内容を引数として、ファイル使用情報更新部１１１１へ前記実行を終了したアプリに係るファイル使用情報の更新及び、ファイルの分離の実施を要求する（Ｓ２４２０１）。
【０１７９】
本要求を受け取ったファイル使用情報更新部１１１１は、実施の形態１にて説明した処理手順に基づきファイル使用情報の更新を実施し、その後ファイル分離判定部１１１２によるファイル分離判定、及びファイル分離部１１１３によるファイル分離を適宜実施する。
【０１８０】
ここで、実施の形態１の場合と大きく異なる点が、ファイルアクセス監視テーブル１３４１の内容を引数としてファイル使用情報の更新処理を実施する点である。すなわち実施の形態１において、図５に示したＳ５００４の処理が実施される。
【０１８１】
Ｓ５００４における処理手順についてＪａｖａ（登録商標）アプリの一例であるＧａｍｅにおいて、Ｊａｖａ（登録商標）アプリＧａｍｅの初回実行前のＧａｍｅ．ｄａｔが初回実行後にファイルアクセス監視テーブル７３００によってどのように更新されるのかを図示した一例が、図２５である。
【０１８２】
ファイル使用情報更新部１１１１は、引数として渡されたＪａｖａ（登録商標）アプリの一例であるＧａｍｅの実行過程で生成され、ファイルアクセス監視部１３４０内に保持されたファイルアクセス監視テーブル１３４１に基づき、ファイル使用情報７３００に含まれる情報（この例では各ファイルの“ｃｏｕｎｔ”に対応する値および“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”）を更新する。
【０１８３】
Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅの、初回起動前のファイル使用情報７３００に含まれる“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”に対応する値は０、各ファイルの“Ｃｏｕｎｔ”に対応する値は０である。
【０１８４】
初回起動後、“Ｌｏｕｎｃｈｅｄ Ｃｏｕｎｔ”に対応する値に１が加えられる（インクリメントされる）。
【０１８５】
また、ファイルアクセス監視テーブル１３４１において、ファイル毎にアクセスフラグを調べ、アクセスフラグが「アクセス有り」となっているファイル名に対応するファイルについては、ファイル使用情報７３００における該当する使用情報（この例ではＮａｍｅの値が「アクセス有り」となっているアクセスフラグに対応するファイル名と同じ使用情報）の“Ｃｏｕｎｔ”に対応する値に１が加えられる（インクリメントされる）。
【０１８６】
また、アクセスフラグが「アクセスなし」となっているファイル名に対応するファイルについては、該当する使用情報の“Ｃｏｕｎｔ”に対応する値の変更はない。
【０１８７】
図２５に示す例では、アプリ終了時におけるファイルアクセス監視テーブル１３４１において、アクセスフラグが「アクセス有り」となっているファイル名に対応するファイル（例えば、Ｇａｍｅ．ｃｌａｓｓ、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ）について、Ｊａｖａ（登録商標）アプリＧａｍｅの初回起動後の該当する使用情報の“Ｃｏｕｎｔ”に対応する値に１が加えられ（インクリメントされる）、アクセスフラグが「アクセスなし」となっているファイル名に対応するファイル（この例ではｒｅａｄｍｅ．ｔｘｔ）については、該当する使用情報の“Ｃｏｕｎｔ”に対応する値の変更はないことを示している。
【０１８８】
Ｊａｖａ（登録商標）アプリＧａｍｅの二回目の実行終了後においても、二回目の実行終了時のファイルアクセス監視テーブル７３００に基づき、ファイル使用情報７３００を更新する点に変わりはない。しかしながら、Ｊａｖａ（登録商標）アプリＧａｍｅに含まれるＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓは初回の実行において、メソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）がｔｒｕｅを返していた場合、再度の実行は必要ないため、２回目のメソッドＩｓＩｎｉｔｉａｌｉｚｅｄ（）はｆａｌｓｅを返す。このため、Ｊａｖａ（登録商標）アプリＧａｍｅの２回目以降の実行において、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓは一時記憶部１３２１へロードされなくなり、結果としてファイルアクセス監視テーブル１３４１のＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓに対応するアクセスフラグは「アクセスなし」となる。
【０１８９】
つまり、ファイル名がＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓに対応するファイル使用情報７３００の使用情報２５５０２については、Ｃｏｕｎｔ（２５５０４）の値の変更はない。
【０１９０】
また、上述したとおり、ｒｅａｄｍｅ．ｔｘｔはＪａｖａ（登録商標）アプリの一例であるＧａｍｅの実行時には使用されないファイルであるため、ファイルアクセス管理テーブル１３４１の該当するアクセスフラグにはアクセスなしが設定される。
【０１９１】
図２７は、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後のファイル使用情報の一例を説明するための図である。図２７においては、Ｎａｍｅの値が“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”の使用情報の“Ｃｏｕｎｔ”の値が１、Ｎａｍｅの値が“ｒｅａｄｍｅ．ｔｘｔ”の使用情報の使用情報の“Ｃｏｕｎｔ”の値が０である。
【０１９２】
図５において説明したように、Ｓ５１０１では、ファイル使用情報７３００に基づき、分離対象のファイルを決定し、決定したファイルに関する情報を分離ファイル名リストへ追加すること、Ｓ５１０１の具体的な処理の一例を示す図８の説明において、Ｓ８００１では“ＬａｕｎｃｈｅｄＣｏｕｎｔ”が周期定数Ｉに定める値（図８で説明した例ではこの値は１０）の倍数毎にＳ８００２〜Ｓ８００６に示すフローが実行されること、Ｓ８００３でＹｅｓ（使用回数の上限を定めていないファイル）かつＳ８００５でＮｏ（アプリの起動回数に分離定数Ｘを乗じた値よりもファイルの使用回数方が少ない）の場合、分離対象ファイル名リスト９１００に対象となるファイルの情報が追加されることを説明した。
【０１９３】
ここでは、図８で説明したフローチャートに示す処理を図２６に例示したファイル使用情報７３００に適用した場合について説明をする。
【０１９４】
まず図２６のファイル使用情報は、上述したとおりＪａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後のファイル使用情報であるので、図８におけるＳ８００１の判断結果はＹｅｓとなる。
【０１９５】
Ｓ８００２は、後述するＳ８００３〜Ｓ８００６をファイル使用情報７３００に含まれる各ファイルの使用情報に対して行なうことを示すものである。
【０１９６】
図８の説明において、分離定数Ｘの値を０．１としたものを例に説明しているので、“ＬａｕｎｃｈｅｄＣｏｕｎｔ”の値が１０のとき、図８のＳ８００５におけるＵの値は０．１×１０＝１となる。
【０１９７】
つまり、Ｓ８００５、Ｊａｖａ（登録商標）アプリの一例であるＧａｍｅを１０回起動した後、ファイル使用情報７３００に含まれる各ファイルの使用情報において、“Ｃｏｕｎｔ”が１回以下の使用情報に対応するファイルに関する情報が分離対象ファイル名リスト９１００に追加される。
【０１９８】
図２７の例では、Ｎａｍｅの値が“ｉｃｏｎ．ｇｉｆ”に対応する使用情報の“Ｃｏｕｎｔ”の値は０、“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”に対応する使用情報の“Ｃｏｕｎｔ”の値は１、“ｒｅａｄｍｅ．ｔｘｔ”に対応する使用情報の“Ｃｏｕｎｔ”の値は０であり、更新された分離対象ファイル名リスト９１００にはこれらのファイル（“Ｃｏｕｎｔ”の値が１以下の使用情報に対応するファイル）に関する情報が含まれるようになる。
【０１９９】
具体的には、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓの使用情報の構成要素Ｃｏｕｎｔが１、ｉｃｏｎ．ｇｉｆの使用情報の構成要素Ｃｏｕｎｔが０、ｒｅａｄｍｅ．ｔｘｔの使用情報の構成要素Ｃｏｕｎｔが１であり、これらは分離対象として、分離対象ファイル名リスト９１００へ加える。
【０２００】
こうして、Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ及びｒｅａｄｍｅ．ｔｘｔが新たに分離対象となり、ファイル分離部によってＧａｍｅ．ｊａｒより分離される。
【０２０１】
図２８は、図２７に示された分離対象ファイル名リスト９１００に基づいて分離がなされた後のＪａｖａ（登録商標）アプリの一例であるＧａｍｅ．ｊａｒ、Ｇａｍｅ．ｄａｔ、Ｇａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔ、抽出後ファイル群の一例を示す。分離後のＧａｍｅ．ｊａｒはＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ及びｒｅａｄｍｅ．ｔｘｔなどの使用回数が少ないファイルが分離されたことによってさらにファイルサイズが小さくなる。
【０２０２】
また、今回Ｇａｍｅ．ｊａｒから分離されたＩｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、及びｒｅａｄｍｅ．ｔｘｔは分離ファイル部１２２２へ格納される。
【０２０３】
なお、上記ファイル分離による効果を得るためには、Ｊａｖａ（登録商標）アプリが図２２で例示したような構成をとることを必要とするところ、図２２のＪａｖａ（登録商標）アプリＧａｍｅで例示した処理は、本例における特別な処理形態ではなく、多くのＪａｖａ（登録商標）アプリが普通に採用する構成である。つまり本発明の効果は、現存する多くのＪａｖａ（登録商標）アプリにおいて得られるといえる。
【０２０４】
これは、多くのＪａｖａ（登録商標）アプリは、そのＪａｖａ（登録商標）アプリの初回起動時のみＨｔｔｐ通信等を行い、Ｊａｖａ（登録商標）アプリ実行に必要なデータを取得してデータ記憶部１２００に例示されるようなＪａｖａ（登録商標）アプリ専用の不揮発記憶領域へ格納する、という処理形態をとることで、二度目以降の起動については、データ記憶部１２００から読み込んで実行することにより、起動処理の高速化及び、通信回数の削減効果が図ることが通例となっているためである。
【０２０５】
多くのＪａｖａ（登録商標）アプリに係るＪＡＲファイルに含まれるクラスは、Ｊａｖａ（登録商標）アプリ起動時にほぼ毎回使用されるクラス、ユーザの特定操作時にのみ使用されるクラス、初回起動時等のタイミングにおいてのみ使用されるクラス等が混在した状態となっている。
【０２０６】
このため、後者で挙げた使用回数が僅少なクラスに係るファイルを分離することで、ＪＡＲファイルのサイズが削減され、結果として一時記憶部１３２１へ使用しないまたは使用頻度の低いファイルをロードすることがなくなり、その分、一時記憶部１３２１の空き容量が増え、他の処理にこの空き容量を利用できるようになるので、アプリ実行時において、一時記憶部１３２１に占めるＪＡＲファイルの領域を削減するとともに、一時記憶部１３２１の利用効率の向上が図れる。
【０２０７】
（実施の形態４）
実施の形態４では、図１に記載の本発明によるアプリケーション実行装置１０００における、実施の形態１や実施の形態３の手順によってファイルの分離を行ったパッケージ化アプリ１３２３を分離前の元のパッケージ化アプリへ復元するための処理手順を説明する。
【０２０８】
なお、以下では図２７に示した分離がなされたＧａｍｅ．ｊａｒを元に復元する処理を例にして説明を行う。
【０２０９】
図２９は本実施の形態のアプリケーション実行装置において、復元処理の一例を説明するためのフローチャートである。
【０２１０】
また、図３０は図２９に示すフローチャートを適用して復元するときのＧａｍｅ．ｊａｒの変化を模式的に示したものである。
【０２１１】
以下に図２８に示したフローチャートを説明する。
【０２１２】
（４−１）復元に必要なファイルを一時記憶部１３２１より読込む
アプリ復元部１１２０は、アプリ記憶部１２１０より復元対象のパッケージ化アプリを、分離ファイル部１２２２より復元対象のパッケージ化アプリに係る復元情報１０２００、分離ファイル一覧１２４００を取得する（Ｓ２８００１）。
【０２１３】
図２７に示すＧａｍｅ．ｊａｒを上述の処理にあてはめて説明すると、Ｓ２８０１は復元情報に対応するＧａｍｅ．ｉｎｆｏ、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔをデータ記憶部１２００より読み込むことに相当する。
【０２１４】
（４−２）元パッケージ化アプリに存在した全てのファイルエントリを生成する
次にファイル復元部１１２０は、（４−１）で取得したパッケージ化アプリに含まれる全ファイルエントリを取り出す（Ｓ２８００２）。また、（４−１）で取得した分離ファイル一覧に基づきパッケージ化アプリより分離された全てのファイルをパッケージ化アプリのファイルエントリ形式に変換する（Ｓ２８００３）。
【０２１５】
図２８に示すＧａｍｅ．ｊａｒを上述の処理にあてはめて説明すると、Ｓ２８００２は、図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるファイルエントリＧａｍｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ等を取り出す処理がこれに相当する。
【０２１６】
なお、図２８に示すＧａｍｅ．ｊａｒに含まれる全ファイルエントリを取り出したものを模式的に示したものが、図３０において、２９４００の符号を付したものである。
【０２１７】
また、Ｓ２８００３は、分離ファイル一覧に対応するＧａｍｅ．ｌｉｓｔに指定されたファイル名“Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ”、“ｉｃｏｎ．ｇｉｆ”、“ｒｅａｄｍｅ．ｔｘｔ”等のファイルを分離ファイル部１２２２より読込み（Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、ｉｃｏｎ．ｇｉｆ、ｒｅａｄｍｅ．ｔｘｔ等）、これらをＪＡＲファイルエントリ形式に変換する。
【０２１８】
ここで、ＪＡＲファイルエントリ形式は、実施の形態１にて挙げたとおり無圧縮、及びＤＥＦＬＡＴＥ圧縮アルゴリズム等による圧縮のいずれかである。
【０２１９】
なお、図３０に示す復元前のＧａｍｅ．ｊａｒに対応する分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ）に基づいて、分離されたファイル群２９５００を分離ファイル部１２２２より読込み、ＪＡＲファイルエントリ形式に変換したのを模式的に示したものが、図２９における２９６００の符号を付したものである。
【０２２０】
また、図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるファイルエントリがどのＪＡＲファイルエントリ形式であるかを知るためには、復元前のＧａｍｅ．ｊａｒに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒまたは対応するＧａｍｅ．ｉｎｆｏに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに格納されている情報を参照すればよい。
【０２２１】
また、図３０に示す分離ファイル一覧（Ｇａｍｅ．ｌｉｓｔ（１２４００））に基づいて、分離されたファイルがどのＪＡＲファイルエントリ形式であるかを知るためには、図３０に示すＧａｍｅ．ｉｎｆｏに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒまたは図３０に示す復元前のＧａｍｅ．ｊａｒに含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒに格納されている情報を参照すればよい。
【０２２２】
（４−３）元のパッケージ化アプリを組み立てる
次にアプリ復元部１１２０は、Ｓ２８００２、Ｓ２８００３にて生成したファイルエントリと、Ｓ２８００１にて読み込んだ復元情報を利用して、復元情報１０２００（Ｇａｍｅ．ｉｎｆｏ）に含まれるファイルエントリ格納位置・順序に基づき生成したファイルエントリの連結を行う（Ｓ２８００４）。
【０２２３】
その後、復元情報１０２００をＳ２８００４にて連結したファイルエントリに連結する（Ｓ２８００５）。
【０２２４】
次にＳ２８００５において、完成したデータを元のパッケージ化アプリ（Ｇａｍｅ．ｊａｒ（３１００））として、アプリ記憶部１２１０への格納等を行う（Ｓ２８００６）。
【０２２５】
上述の処理にあてはめて説明すると、Ｓ２８００２、Ｓ２８００３にて生成したファイルエントリ（Ｉｎｉｔｉａｌｉｚｅ．ｃｌａｓｓ、ｉｃｏｎ．ｇｉｆ、ｒｅａｄｍｅ．ｔｘｔ、Ｇａｍｅ．ｃｌａｓｓ、Ｍａｉｎ．ｃｌａｓｓ、ｇａｍｅ．ｇｉｆ等）を復元情報１０２００に含まれるＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙの内容（つまりファイルヘッダ）に基づいて、各ファイルエントリの連結を行なうことがＳ２８００４に相当する。
【０２２６】
また、復元情報１０２００に含まれるＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒが先頭となるように連結したファイルエントリに連結するとともに、復元情報１０２００に含まれるＣｅｎｔｒａｌ Ｄｉｒｅｃｔｏｒｙを連結したファイルエントリの後ろに連結するのがＳ２８００５に相当する。
【０２２７】
上記手順により、分離されたＪＡＲファイルを元のＪＡＲファイルへ復元することが可能となる。本手順は、ファイル分離前の復元確認処理（Ｓ５２０４）や、ＪＡＲファイルを情報端末外へエクスポートする場合に利用する。
【０２２８】
（実施の形態５）
実施の形態５では、図１に記載の本発明によるアプリケーション実行装置１０００における、実施の形態１や実施の形態３の手順によってファイルの分離を行ったパッケージ化アプリをデータ記憶部１２００より削除する際に、パッケージ化アプリの分離によって生成したファイル群についても一括削除するための処理手順を説明する。
【０２２９】
なお、データ記憶部１２００へのファイルアクセスについては、実施の形態１の結果であるＪａｖａ（登録商標）アプリＧａｍｅのファイル分離実施後のファイル構造を図示した図１３、図１４を用いることとする。
【０２３０】
図１３に示すように、Ｊａｖａ（登録商標）アプリＧａｍｅに対し分離がなされると、アプリ記述ファイル３２００、分離後のパッケージ化アプリ１２２００、ファイル使用情報７３００、復元情報１０２００、分離ファイル一覧１２４００、パッケージ化アプリから分離され抽出された抽出後ファイル群１１４００がデータ記憶部１２００に格納される。
【０２３１】
図１４に示すように分離後のパッケージ化アプリ１２２００、アプリ記述ファイル３２００はデータ記憶部１２００のアプリ記憶部１２１０（より具体的には、図１４に示す“ａｐｐ”フォルダの中）にそれぞれＧａｍｅ．ｊａｒ、Ｇａｍｅ．ａｄｆというファイル名で記憶される。
【０２３２】
ファイル使用情報７３００はデータ記憶部１２００の分離ファイル情報部１２２０内のファイル使用情報部（より具体的には図１４に示す“ｕｓｅｉｎｆｏ”フォルダの中）にＧａｍｅ．ｄａｔというファイル名で記憶される。
【０２３３】
復元情報１０２００、分離ファイル一覧１２４００は、データ記憶部１２００の分離ファイル情報部１２２０内の分離ファイル部１２２２（より具体的には図１４に示す“Ｇａｍｅ”フォルダの中）にそれぞれＧａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔというファイル名で記憶される。
【０２３４】
パッケージ化アプリから分離され抽出された抽出後ファイル群１１４００は、データ記憶部１２００の分離ファイル情報部１２２０内の分離ファイル部１２２２（より具体的には“ｒｅｓｏｕｒｃｅｓ”の配下）に記憶される。図１４に示す例では、抽出後ファイル群１１４００は“ｉｃｏｎ．ｇｉｆ”というファイル名を有するファイル等が記憶されることを示している。
【０２３５】
図３１は、ファイルの分離を行った後のパッケージ化アプリを削除する処理手順の一例を示すものである。この処理手順に従った処理は、専らアプリ削除部１１３０にてなされる。
【０２３６】
アプリ削除部１１３０は、アプリ削除要求を受け取ると、当該削除対象アプリに係るパッケージ化アプリ、及び対応するアプリ記述ファイルをアプリ記憶部１２１０より削除する（Ｓ３０００１）。図１４に示した例では、“ａｐｐ”フォルダの中のＧａｍｅ．ｊａｒ、Ｇａｍｅ．ａｄｆを削除することがＳ３０００１に相当する。
【０２３７】
その後、アプリ削除部１１３０は、当該パッケージ化アプリ分離によって生成されたファイル使用情報、復元情報、分離ファイル一覧の削除及び、分離ファイル一覧に列挙されたファイル群の削除を行う（Ｓ３０００２）。図１４に示した例では、“Ｇａｍｅ”フォルダの中のＧａｍｅ．ｉｎｆｏ、Ｇａｍｅ．ｌｉｓｔを削除するとともに、“ｒｅｓｏｕｒｃｅｓ”フォルダの中の配下のファイルを削除するＳ３０００１に相当する。
【０２３８】
上述の具体的な削除はファイルを削除の対象としたが、これに限定される必要はなく例えば、フォルダ（ディレクトリ）を削除するような構成としても同様の効果を奏する。例えば、Ｇａｍｅという名称のフォルダ（ディレクトリ）を削除した場合には、その配下のファイル、フォルダも同時に削除される。
【０２３９】
上記手順により、Ｊａｖａ（登録商標）アプリの削除に合わせて、当該Ｊａｖａ（登録商標）アプリに係るＪＡＲファイル及び分離によって生成されたファイル群も連動して削除することが可能となる。
【０２４０】
このように一気に削除を実施しなければ、ファイルシステム上に分離によって生成されたファイルが削除されることなく残ってしまうことになるため、本手順によるファイル群の一括削除はデータ記憶領域の有効活用において重要である。
【０２４１】
（実施の形態６）
実施の形態６では、図１に記載の本発明によるアプリケーション実行装置１０００における、アプリ起動に係るユーザインターフェースのアイコン等情報表示処理について説明する。
【０２４２】
アプリケーション実行装置１０００において、ユーザは、一覧表示処理部１４００の一覧表示部１４０１が表示する起動可能アプリ一覧より、起動したいアプリを選択し、これを起動することができる。
【０２４３】
起動したいアプリの選択は、ユーザのキー入力によって行われる。キー入力はキー入力部１５００によって受け付けられ、キー入力部１５００は、入力されたキー情報をユーザ入力受付部１４０２へ通知する。入力されたキー情報を受け取ったユーザ入力受付部１４０２はキー情報に応じて、起動可能アプリ一覧の更新を一覧表示部１４０１へ要求、もしくはアプリの起動をアプリ起動要求部１４０３へ要求をする。アプリ起動要求を受けたアプリ起動要求部１４０３は、当該起動要求に係るアプリに関する情報を引数として、アプリ起動処理部１３１０へアプリ起動要求を行う。また、起動可能アプリ一覧の更新要求を受けた一覧表示部１４０１は、適宜分離ファイル部よりＪＡＲファイルより分離されたアイコン情報を取得しながら、起動可能アプリ一覧の表示更新を行う。
【０２４４】
図３２は、本起動可能アプリ一覧表示更新処理について、アプリラウンチャの処理を一例として説明するための図である。
【０２４５】
始めに一覧表示部１４０１は、画面に表示可能な個数分に対応するアプリの名前と、アイコンイメージをデータ記憶部１２００に格納された情報等を利用して取得する。前記アプリの名前についてはアプリ記述ファイルから、アイコンイメージはアプリ記述ファイルに記載のアイコンファイル名を元にパッケージ化アプリより抽出することで取得できる。しかし、アイコンイメージを分離し、分離ファイル部１２２２に記憶しているパッケージ化アプリについては、上記パッケージ化アプリからのアイコンイメージ抽出を行うことなく、分離ファイル部１２２２よりアイコンイメージの取得が可能である。
【０２４６】
具体例を挙げて説明すると、一覧表示部は画面３１１００に表示可能なアプリ数（この例では３）分、アプリ名及びそのアプリのアイコンイメージの取得を試みる。始めに一覧表示部は、Ｊａｖａ（登録商標）アプリＧａｍｅに関するアプリ名及びアイコンイメージの取得を試みる。アプリ名については、アプリ記憶部１２１０に格納されたアプリ記述ファイル（ＡＤＦファイル）に記載の情報によって取得可能である。アイコンイメージについては、ＡＤＦファイルに記載されたアイコンイメージのファイル名に基づき、Ｇａｍｅ．ｊａｒより抽出を行う前に、分離ファイル部１２２２に前記ファイル名のファイルが存在するかどうかを確認する。
【０２４７】
ここで存在する場合については、パッケージ化アプリであるＧａｍｅ．ｊａｒからの抽出は行わず、分離ファイル部１２２２より読込みを行い、存在しない場合については、Ｇａｍｅ．ｊａｒからの抽出を行なう。こうして取得したアプリ名及びアイコンイメージが表示される（３１１０１）。上記手順は、他のアプリであるＴｏｏｌ、Ｍｅｍｏに対しても行われ、画面３１１００が構築される。
【０２４８】
なお、アイコンイメージの他アプリの説明文の表示（３１１０２）を行うためにＪＡＲファイルよりテキストファイル（図３に示す例では、“ｒｅａｄｍｅ．ｔｘｔ”など）を読込む機能を有するアプリラウンチャも存在する。このようなアプリラウンチャは、上記手順においてアイコンイメージだけでなく、説明文に係るテキストファイルも合わせて取得することにより実現可能である。
【０２４９】
また、本説明文に係るテキストファイルのファイル名がアイコンイメージ同様ＡＤＦ等に記述可能な場合は、ファイル使用情報更新部においてアイコンイメージだけでなく説明文に係るテキストファイルも分離対象とすることにより、上記アイコンイメージ同様分離ファイル部からの取得が可能となる。
【０２５０】
上記手順により、ＪＡＲファイルよりアイコンイメージを逐次取得する処理形態に比べて起動可能アプリ一覧表示に要する時間を短縮することが可能である。なお、前記と同様の効果を有する技術としてアイコンキャッシュが挙げられるが、アイコンキャッシュでは、ＪＡＲファイルとキャッシュ領域に同一のアイコンイメージを示す情報を保持する必要があるところ、本発明ではアイコンイメージ等の二重持ちが発生しないため、不揮発領域を圧迫しない。この省メモリ性も、本実施の形態が奏する効果である。
【産業上の利用可能性】
【０２５１】
本発明に係るアプリケーション実行装置は、パッケージ化アプリが含有する殆どアプリが使用しないファイルを分離することで、アプリ実行における一時記憶領域の使用量を削減する効果及び、アプリラウンチャの表示処理を高速化する効果を有し、情報端末や携帯電話などに有用である。
【０２５２】
また、本発明に係るアプリケーション実行装置は、通信機能を有したＡＶ機器などにも有用である。
【図面の簡単な説明】
【０２５３】
【図１】本実施の形態のアプリケーション実行装置を説明するための図
【図２】本実施の形態において、パッケージ化アプリファイルとアプリ記述ファイルの一例を示す図
【図３】本実施の形態において、ＪＡＲファイルとＡＤＦファイルの一例を示す図
【図４】本実施の形態において、データ記憶部の一例を示す図
【図５】本実施の形態において、ファイル分離処理の一例を示すフローチャート
【図６】本実施の形態において、ファイル使用情報の一例を示す図
【図７】本実施の形態において、ファイル分離処理の一例を示す図
【図８】本実施の形態において、分離対象ファイル名リスト生成処理の一例を示すフローチャート
【図９】本実施の形態において、分離対象ファイル名リスト生成処理の一例を示す図
【図１０】本実施の形態において、復元情報の生成処理の一例を示す図
【図１１】本実施の形態において、ファイル分離処理の一例を示す図
【図１２】本実施の形態において、ファイル分離処理前のパッケージ化アプリ、およびファイル分離処理後のパッケージ化アプリを説明するためのからのファイル削除処理の一例を示す図
【図１３】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図１４】本実施の形態において、ファイル分離実施後のデータ記憶部の一例を示す図
【図１５】本実施の形態において、アプリのロードと起動処理の一例を示すフローチャート
【図１６】本実施の形態において、分離ファイル情報テーブルの生成の一例を示す図
【図１７】本実施の形態において、アプリ起動直後の一時記憶部に記憶されるデータの一例を示す図
【図１８】本実施の形態において、ファイル分離処理を実施した場合に一時記憶部に記憶されるデータと、ファイル分離処理を実施しない場合に一時記憶部に記憶されるデータとの比較を説明するための図
【図１９】本実施の形態において、アプリ実行過程で分離されたファイルへアクセス処理する一例を示すフローチャート
【図２０】本実施の形態において、分離されたファイルへのアクセス処理を含むプログラムの一例を示す図
【図２１】本実施の形態において、ファイルアクセス監視を伴うアプリ実行過程で分離されたファイルへのアクセス処理の一例を示すフローチャート
【図２２】本実施の形態において、アプリソースコードの一例を示す図
【図２３】本実施の形態において、ファイルアクセス監視テーブルの内容の一例を示す図
【図２４】本実施の形態において、ファイル使用情報の更新処理とファイル分離処理の一例を示すフローチャート
【図２５】本実施の形態において、ファイル使用情報を更新処理する一例を示す図
【図２６】本実施の形態において、ファイル使用情報に基づき分離対象ファイル名リストを生成処理する一例を示す図
【図２７】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図２８】本実施の形態において、ファイル分離後に生成されるファイル群の一例を示す図
【図２９】本実施の形態において、アプリ復元処理の一例を示すフローチャート
【図３０】本実施の形態において、アプリ復元処理の一例を示す図
【図３１】本実施の形態において、アプリ削除時に分離ファイル群を削除処理する一例を示すフローチャート
【図３２】本実施の形態において、アプリラウンチャの一例を示す図
【符号の説明】
【０２５４】
１０００ アプリケーション実行装置
１１００ アプリファイル管理部
１１０１ アプリ取得部
１１１０ アプリ分離部
１１１１ ファイル使用情報更新部
１１１２ ファイル分離判定部
１１１３ ファイル分離部
１１２０ ファイル復元部
１１３０ アプリ削除部
１２００ データ記憶部
１２１０ アプリ記憶部
１２２０ 分離ファイル情報部
１２２１ ファイル使用情報部
１２２２ 分離ファイル部
１３００ アプリ実行部
１３１０ アプリ起動処理部
１３２０ アプリ実行エンジン
１３２１ 一時記憶部
１３２２ パッケージ化アプリ部
１３２３ アプリ記述ファイル部
１３２４ モジュール部
１３３０ ファイルアクセス部
１３３１ 分離ファイル情報アクセス部
１３３２ 分離ファイル情報テーブル
１３４０ ファイルアクセス監視部
１３４１ ファイルアクセス監視テーブル
１４００ 一覧表示処理部
１４１０ ユーザ入力受付部
１４２０ アプリ起動要求部
１４３０ 一覧表示部
１５００ キー入力部
２１００ パッケージ化アプリ
２１１０ ヘッダ情報
２１２０ プログラムモジュールファイルエントリ群
２１３０ リソースデータファイルエントリ群
２１４０ ファイルエントリ管理情報
２１４１ ファイルエントリファイルヘッダ
２１４２ ファイルエントリのＯｆｆｓｅｔ
２１４３ ファイルエントリのＬｅｎｇｔｈ
２１４４ ファイルエントリのＮａｍｅ
２２００ アプリ記述ファイル
２２０１ 起動プログラムモジュール
２２０２ アイコンリソース
６１００ ファイル使用情報
６１１０ ファイル使用情報の共通情報
６１１１ アプリ起動回数
６１２０ パッケージ化アプリ内ファイル１使用情報
６１２１ パッケージ化アプリ内ファイル１のファイル名
６１２２ パッケージ化アプリ内ファイル１のアプリ実行時最大使用回数
６１２３ パッケージ化アプリ内ファイル１のアプリ実行時使用回数累計
【特許請求の範囲】
【請求項１】
モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能なものであって、
前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、
前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、
前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、
前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、
前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたアプリケーション実行装置。
【請求項２】
前記パッケージ化アプリは、前記モジュールファイル群またはリソースファイル群に含まれる各ファイル対して、前記各ファイルの格納位置、サイズに関するファイルヘッダ情報を含み、前記ファイルヘッダ情報に示された格納位置に基づいて前記モジュールファイル群およびリソースファイル群に含まれる各ファイルが格納されており、
前記ファイル分離部により前記パッケージ化アプリからファイルを分離する場合、分離する対象のファイルおよび前記分離する対象のファイルに対応するファイルヘッダ情報を削除し、前記分離対象のファイルの削除により空けられた領域を詰めるように、前記削除したファイルに後続するファイルを再配置するとともに、前記再配置により格納位置が変化したファイルに対応するファイルヘッダ情報に含まれる格納位置を更新することにより、分離したパッケージ化アプリを生成する請求項１記載のアプリケーション実行装置。
【請求項３】
前記ファイル使用情報更新部により作成されるファイル使用情報は、前記パッケージ化アプリを実行した回数と、前記パッケージ化アプリに含まれる各ファイルを特定する情報、前記パッケージ化アプリを実行するために前記特定した各ファイルを、前記一時記憶部に格納できる最大回数と、前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数とを含むものであって、
前記ファイル使用情報更新部は、更に前記パッケージ化アプリを実行する毎に、対応するファイル使用情報に含まれる、前記パッケージ化アプリを実行した回数および前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するようにした請求項１または２のいずれかに記載のアプリケーション実行装置。
【請求項４】
前記判定部は、前記パッケージ化アプリを実行した回数が所定の回数となる毎に、前記一時記憶部に実行可能なデータ形式となるようにして格納した回数が所定の回数よりも少ないファイルを前記パッケージ化アプリの実行中に使用されないファイルとみなす判定をし、
前記ファイル分離部は、前記実行中に使用されないファイルが分離されたパッケージ化アプリから更に前記使用されないとみなしたファイルを分離するようにした請求項３に記載のアプリケーション実行装置。
【請求項５】
前記ファイル分離部は、分離したファイルを示す復元情報を生成し、前記データ記憶部に記憶するとともに、
前記アプリケーション実行装置は、前記復元情報を用いて分離したファイルを復元する復元部を更に備えることを特徴とする請求項１記載のアプリケーション実行装置。
【請求項６】
前記ファイル分離部により生成される復元情報は前記パッケージ化アプリから分離したファイルを特定する情報および前記特定したファイルが格納されている前記データ記憶部の格納位置を示す情報を含み、
前記アプリ実行部により実行されるパッケージ化アプリが、既に分離され前記一時記憶部には格納されていないファイルの実行を要求する場合、前記分離されたファイルが格納されている前記データ記憶部の格納位置を示す情報を用いて、前記分離されたファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納するようにした請求項５に記載のアプリケーション実行装置。
【請求項７】
前記アプリ実行部は、前記パッケージ化アプリに含まれる各ファイルが、前記一時記憶部に格納された前記パッケージ化アプリに含まれる各ファイルへのアクセスが前記アプリ実行部により実行されるパッケージ化アプリの実行中になされたかどうかを示すファイルアクセス関しテーブルを保持し、ファイルアクセス関しテーブルに基づいて、前記ファイル使用情報に含まれる該当するファイルについて、実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するよう、前記ファイル使用情報更新部に指示するように構成した請求項３記載のアプリケーション実行装置。
【請求項８】
前記アプリケーション実行装置は、更に
前記データ記憶部に記憶したパッケージ化アプリを削除する削除手段を備え、
前記削除手段は、前記データ記憶部に記憶したパッケージ化アプリを削除する場合、前記分離したパッケージ化アプリおよび前記分離したファイルを削除するように構成した請求項２に記載のアプリケーション実行装置。
【請求項１】
モジュールファイル群及びリソースファイル群をパッケージングしたファイルであるパッケージ化アプリを記憶し、実行することが可能なものであって、
前記パッケージ化アプリ及び前記パッケージ化アプリに含まれるファイルに関連する情報を記述する記述ファイルを記憶するデータ記憶部と、
前記データ記憶部に記憶されたパッケージ化アプリを初めて実行する場合、前記記述ファイルに含まれる情報に基づいて、前記パッケージ化アプリに含まれるファイルおよび前記パッケージ化アプリの実行中に前記ファイルが使用されるか否かを示す情報を含むファイル使用情報を作成するファイル使用情報更新部と、
前記ファイル使用情報更新部により得られるファイル使用情報に基づいて、前記パッケージ化アプリに含まれるファイルのうち、前記パッケージ化アプリの実行中に使用されないファイルを判定する判定部と、
前記判定部により判定されたファイルを前記パッケージ化アプリから分離し、前記分離したファイルと、前記ファイルを分離されたパッケージ化アプリを前記データ記憶部に記憶するファイル分離部と、
前記ファイル分離部によりファイルが分離されたパッケージ化アプリを一時的に格納する一時記憶部および、前記一時記憶部に格納された前記パッケージ化アプリを実行可能なデータ形式となるようにして前記一時記憶部の記憶領域へ展開し、実行するアプリ実行エンジンを有するアプリ実行部とを備えたアプリケーション実行装置。
【請求項２】
前記パッケージ化アプリは、前記モジュールファイル群またはリソースファイル群に含まれる各ファイル対して、前記各ファイルの格納位置、サイズに関するファイルヘッダ情報を含み、前記ファイルヘッダ情報に示された格納位置に基づいて前記モジュールファイル群およびリソースファイル群に含まれる各ファイルが格納されており、
前記ファイル分離部により前記パッケージ化アプリからファイルを分離する場合、分離する対象のファイルおよび前記分離する対象のファイルに対応するファイルヘッダ情報を削除し、前記分離対象のファイルの削除により空けられた領域を詰めるように、前記削除したファイルに後続するファイルを再配置するとともに、前記再配置により格納位置が変化したファイルに対応するファイルヘッダ情報に含まれる格納位置を更新することにより、分離したパッケージ化アプリを生成する請求項１記載のアプリケーション実行装置。
【請求項３】
前記ファイル使用情報更新部により作成されるファイル使用情報は、前記パッケージ化アプリを実行した回数と、前記パッケージ化アプリに含まれる各ファイルを特定する情報、前記パッケージ化アプリを実行するために前記特定した各ファイルを、前記一時記憶部に格納できる最大回数と、前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数とを含むものであって、
前記ファイル使用情報更新部は、更に前記パッケージ化アプリを実行する毎に、対応するファイル使用情報に含まれる、前記パッケージ化アプリを実行した回数および前記特定した各ファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するようにした請求項１または２のいずれかに記載のアプリケーション実行装置。
【請求項４】
前記判定部は、前記パッケージ化アプリを実行した回数が所定の回数となる毎に、前記一時記憶部に実行可能なデータ形式となるようにして格納した回数が所定の回数よりも少ないファイルを前記パッケージ化アプリの実行中に使用されないファイルとみなす判定をし、
前記ファイル分離部は、前記実行中に使用されないファイルが分離されたパッケージ化アプリから更に前記使用されないとみなしたファイルを分離するようにした請求項３に記載のアプリケーション実行装置。
【請求項５】
前記ファイル分離部は、分離したファイルを示す復元情報を生成し、前記データ記憶部に記憶するとともに、
前記アプリケーション実行装置は、前記復元情報を用いて分離したファイルを復元する復元部を更に備えることを特徴とする請求項１記載のアプリケーション実行装置。
【請求項６】
前記ファイル分離部により生成される復元情報は前記パッケージ化アプリから分離したファイルを特定する情報および前記特定したファイルが格納されている前記データ記憶部の格納位置を示す情報を含み、
前記アプリ実行部により実行されるパッケージ化アプリが、既に分離され前記一時記憶部には格納されていないファイルの実行を要求する場合、前記分離されたファイルが格納されている前記データ記憶部の格納位置を示す情報を用いて、前記分離されたファイルを実行可能なデータ形式となるようにして前記一時記憶部に格納するようにした請求項５に記載のアプリケーション実行装置。
【請求項７】
前記アプリ実行部は、前記パッケージ化アプリに含まれる各ファイルが、前記一時記憶部に格納された前記パッケージ化アプリに含まれる各ファイルへのアクセスが前記アプリ実行部により実行されるパッケージ化アプリの実行中になされたかどうかを示すファイルアクセス関しテーブルを保持し、ファイルアクセス関しテーブルに基づいて、前記ファイル使用情報に含まれる該当するファイルについて、実行可能なデータ形式となるようにして前記一時記憶部に格納した回数を更新するよう、前記ファイル使用情報更新部に指示するように構成した請求項３記載のアプリケーション実行装置。
【請求項８】
前記アプリケーション実行装置は、更に
前記データ記憶部に記憶したパッケージ化アプリを削除する削除手段を備え、
前記削除手段は、前記データ記憶部に記憶したパッケージ化アプリを削除する場合、前記分離したパッケージ化アプリおよび前記分離したファイルを削除するように構成した請求項２に記載のアプリケーション実行装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【公開番号】特開２０１０−６６８７２（Ｐ２０１０−６６８７２Ａ）
【公開日】平成２２年３月２５日（２０１０．３．２５）
【国際特許分類】
【出願番号】特願２００８−２３０７６８（Ｐ２００８−２３０７６８）
【出願日】平成２０年９月９日（２００８．９．９）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年３月２５日（２０１０．３．２５）
【国際特許分類】
【出願日】平成２０年９月９日（２００８．９．９）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]