JP2015210769A - 情報処理装置、情報処理方法およびプログラム - Google Patents

Abstract

【課題】 ファームに含まれるプリインストール・アプリケーションのインストール処理時間を削減する必要がある。【解決手段】 アプリケーションデータをインストールする処理する情報処理装置であって、インストール用の前記アプリケーションデータを予め記憶する第１記憶領域と、インストール先の第２記憶領域とを含む記憶手段と、所定のインストール指示に従って、前記アプリケーションデータへのパスを前記第２記憶領域に書き込む書き込み手段と、を備えることを特徴とする情報処理装置。【選択図】 図４

Description

本発明は、インストール制御を実施する情報処理装置、情報処理方法およびプログラムに関する。

電子機器に組み込まれたコンピュータシステムを制御する基幹的なソフトウェアは、ファームウェア（以降ファームと記載する）と呼ばれる。一方で、電子機器にはユーザの必要に応じて追加するソフトウェアであるアプリケーションを追加する仕組みが備わることがある。アプリケーションはパッケージと呼ばれる形式で配布され、インストール処理によって電子機器が実行可能な形式にファイルが展開される。出荷時にインストール済みのアプリケーションはプリインストール・アプリケーションと呼ばれ、それらのパッケージはファームに同梱するように開発することがある。ユーザが購入後速やかにプリインストール用アプリケーションを利用できるように、工場から出荷するまでにインストール処理を終えておくことが望ましい。このため、生産工程を短縮する上では、プリインストール用アプリケーションのインストール処理時間の削減が必要となる。

データ書き込みの処理時間を短縮する方法があった。例えば、ＩＣカードの発行処理をより高速にするために、ＩＣカードの発行時に必要となるファイルやデータを書き込む代わりに、事前に書き換え不可能な不揮発性メモリに初期データを記憶させておく。ＩＣカードの発行時に初期データを書き換え可能な不揮発性メモリにコピーし、コピーした初期データを更新することにより、初期データの書き込みを不要とする方法（特許文献１）がある。また、組み込み機器のシステムプログラム更新の処理時間を削減するために、組み込み機器が更新するシステムプログラム全体を受信しない。システムプログラムの変更部分だけを含む更新オブジェクトファイルを組み込み機器が受信し、組み込み機器上で新規システムプログラムを生成してロードする方法（特許文献２）がある。

特開２００８−１３４９４２号公報 特開２００３−１７３２６０号公報

しかしながら、特許文献１では、事前に書き換え不可能な不揮発性メモリに初期データを記憶しておき、ＩＣカードの発行時に初期データを書き換え可能な不揮発性メモリにコピーし、コピーした初期データを更新する。そのため、事前に初期データを記憶するための処理時間は必要である。

また、特許文献２では、組み込み機器上で新規システムプログラムを生成してロードするので、新規システムプログラムの生成やロードを行うための処理時間は必要である。

プリインストールを行うための処理時間を削減するために、インストール処理の対象であるファイルサイズをさらに小さくすることが必要である。しかし、従来技術では、処理対象のファイルをコピー又は生成するので、処理対象のファイルサイズをさらに小さくすることが困難であるという課題がある。

本発明は上記の課題に鑑みてなされたものであり、ファームに含まれるプリインストール用アプリケーションのインストール処理時間を削減できる情報処理装置を提供することを目的とする。また、その方法、及びプログラムを提供することを目的とする。

アプリケーションデータをインストールする情報処理装置であって、インストール用の前記アプリケーションデータを予め記憶する第１記憶領域と、インストール先の第２記憶領域とを含む記憶手段と、所定のインストール指示に従って、前記アプリケーションデータへのパスを前記第２記憶領域に書き込む書き込み手段と、を備えることを特徴とする情報処理装置。

本発明によれば、アプリケーションデータへのパスをデータ書き込み可能な第２記憶領域に書き込むので、ファームに含まれるプリインストール用アプリケーションのインストール処理時間を削減できる。

情報処理装置のハードウェア構成の一例を示す概略図 情報処理装置上に構築するシステム構成の一例を示す模式図 （ａ）アプリケーションのパッケージのファイル構成を示す模式図、（ｂ）複数のｌｉｂを含むアプリケーションのパッケージのファイル構成を示す模式図、（ｃ）プリインストールされたパッケージのファイル構成を示す模式図、（ｄ）一般的にインストールされたパッケージのファイル構成を示す模式図 アプリケーション管理フレームワーク２０３の構成および情報処理装置が備える記憶装置の領域を示す模式図 インストール処理のフローチャート アップデート処理のフローチャート ファームへのパッケージ組み込み処理のフローチャート （ａ）汎用領域とインストール用領域に書き込まれたファイルを示す模式図、（ｂ）汎用領域とインストール用領域に書き込まれたファイルを示す模式図、（ｃ）汎用領域とインストール用領域に書き込まれたファイルを示す模式図、（ｄ）汎用領域とインストール用領域に書き込まれたファイルを示す模式図 ファームに組み込み前のパッケージとファームに組み込み後のパッケージのファイル構成を示す模式図 ファームに組み込まれたパッケージとインストール後のパッケージのファイル構成を示す模式図 インストール処理のフローチャート インストール処理のフローチャート

以下、添付の図面を参照して、本発明の好適な実施形態を詳細に説明する。

＜実施形態１＞
図１は、一般的な情報処理装置１０１のハードウェア構成の一例を示す図である。図１に示されるように情報処理装置１０１は、ハードウェア構成として、ＣＰＵ１１を含む。

ＣＰＵ１１が、記憶装置１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートに示す各処理を実現する。

また、ＣＰＵ１１には、バス１０を介して、入力装置１２、記憶装置１３、表示装置１４及び外部接続ＩＦ１５が接続されている。入力装置１２は、情報を入力するキーボード及び／又はマウスである。記憶装置１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等を含み、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示装置１４は、画面等を表示するディスプレイである。外部接続ＩＦ１５は、ネットワークインタフェース、外部機器との各種接続インタフェースである。

尚、ＣＰＵ１１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１１と情報処理装置１０１の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵ１１は分散して処理を実行することが可能である。また、複数のＣＰＵ１１は単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵ１１がプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。

次に、情報処理装置１０１上に構築するシステム構成について、図２を用いて説明する。図２は、情報処理装置１０１のシステム構成の一例を示す図である。

オペレーティングシステム２０１は、システム全体の基盤となるソフトウェアである。アプリケーション実行環境２０２は、例えば仮想マシンのように、オペレーティングシステム２０１上のプロセスでありながら、自身の上でアプリケーションが動作する環境を提供するソフトウェアである。アプリケーション管理フレームワーク２０３は、各アプリケーション２０４の動作状態を管理する機能をもつ。また、フレームワークへの指示を行うシステムアプリケーション２０５が動作することもある。例えば、アプリケーションのインストール・アップデートを指示するユーザインタフェースを備えるシステムアプリケーション２０５が挙げられる。

具体的に、本実施形態におけるアプリケーション実行環境２０２はＪＲＥ（Ｊａｖａ（登録商標） Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ）とする。ＪＲＥとは、Ｊａｖａ（登録商標）言語で開発されたソフトウェアを実行するために必要なソフトウェアのセットである。ＪＲＥは、クラスライブラリ、Ｊａｖａ（登録商標）ＶＭ（Ｊａｖａ（登録商標）言語にて記述されたアプリケーションを実行するためのソフトウェア）、及びＪＲＥを搭載する端末固有のポーティングレイヤを含む。ＪＲＥが実行するアプリケーションは、ＪＡＲ（Ｊａｖａ（登録商標） Ａｒｃｈｉｖｅ）と呼ばれるファイルフォーマットとして扱われることが多い。ＪＡＲファイルは、コンパイルされた複数のＪａｖａ（登録商標）バイトコード及びそれが使用する画像などのリソースを一つにまとめＺＩＰ形式で圧縮されたファイルである。

ＪＲＥはＪＡＲファイルを入力として受け取ると、ＪＡＲファイルから実行に必要なクラスファイル（Ｊａｖａ（登録商標）言語で記述されたソースコードをＪａｖａ（登録商標）コンパイラでコンパイルすることで生成されるプログラムモジュール）を読み込んで、実行する。ＪＡＲファイルとは、クラスファイル及びＪａｖａ（登録商標）アプリ実行過程で使用する様々なリソースファイル（イメージファイル、テキストファイル等）を、ＪＡＲ形式でパッケージ化したファイルである。クラスの読み込みは、クラスローダによって行われる。クラスローダは、クラスパス（クラスが存在するパスを示す情報）を参照して、クラスを探索する。

ＪＡＲファイルＡには他のＪＡＲファイルＢを含めることもできるが、通常のクラスローダではＪＡＲファイルＡ内部のＪＡＲファイルＢを読み込めない。そこで、ＪＡＲファイルＡ内部のＪＡＲファイルＢを、ＪＡＲファイルＡの外部に展開するとともに、クラスパスに展開した場所を加えることで、ＪＡＲファイルＢを通常のクラスローダで読み込ませる方法がある。アプリケーション管理フレームワーク２０３はインストール処理時に、内部のＪＡＲファイルを外部に展開する処理を行う。

本実施形態では、ファームは図２に示すオペレーティングシステム２０１に対応する。ファームに含まれるＪＡＲファイルとして、プリインストール用アプリケーションのパッケージが含まれる。本実施形態はこのプリインストール用アプリケーションのインストール処理時間を削減するための情報処理装置、また、その方法、及びプログラムである。

本実施形態で用いる情報処理装置１０１のハードウェア構成では、記憶装置１３は高速なインストール用領域と、低速な汎用領域と、ファームを格納するファーム用領域とを備える。ファームにはプリインストール用アプリケーションのパッケージが含まれる。パッケージは、各アプリケーションのＪＡＲファイルである。生産工程においてファーム用領域にファーム（プリインストール用アプリケーションのアプリケーションデータ）を書き込んだ後、ファーム用領域は書き込み禁止に設定される。ただし、ファームの更新が必要になった場合は、再度書き込み可能に設定されることもある。即ち、記憶装置１３におけるファーム用領域はデータの書き込みが制限された記憶領域である。

生産工程ではプリインストール用アプリケーションを一括してインストール（一括インストール）する。従来のインストールではファーム用領域からインストール用領域にプリインストール用アプリケーションのＪＡＲファイルのデータ（アプリケーションデータ）の書き込みが行われるから、時間を要する。そこで、書き込むＪＡＲファイルのデータ量を削減し、書き込み時間（インストール処理時間）を削減することが課題となる。

これらの課題を解決するために、アプリケーション管理フレームワーク２０３はプリインストール用アプリケーションのインストールにおいて、ファーム用領域からインストール用領域に全てのアプリケーションデータを書き込むことを行わない。ファーム用領域へのリンクをインストール用領域に作成することでインストール領域に書き込むデータ量を削減する。書き込むデータ量が削減されると、インストールの処理時間を削減できる。以降、プリインストール用アプリケーションを一括してインストールする処理を一括インストールと記す。

初めに、インストール・アップデートの対象となるアプリケーションのパッケージ構成を、図３（ａ）、図３（ｂ）、図３（ｃ）を用いて説明する。図３（ａ）と図３（ｂ）は、パッケージのファイル構成を示す図である。図３（ｃ）はインストール後のプリインストール用アプリケーションのファイル構成を示す図である。

図３（ａ）に示すアプリケーション３０１は、ＪＡＲファイルである。このＪＡＲファイルは、実行形式のプログラムであるｂｉｎ（ｂｉｎａｒｙ）３０２を含む。また、アプリケーションの名前、ｉｄ、ベンダー、バージョンなどを記述するｍａｎｉｆｅｓｔ３０３（以降、マニフェストファイルと同義である）を含む。マニフェストファイルに設定情報が含まれることがある。さらに、アプリケーション３０１には、特定機能を実現するｂｉｎ３０２をまとめてＪＡＲファイルにしたものを複数含めることもできる。含まれるＪＡＲファイルは、ｌｉｂ（ｌｉｂｒａｒｙ）３０４である。ｌｉｂ３０４はライブラリである。アプリケーション３０１はｂｉｎ３０２とｍａｎｉｆｅｓｔ３０３を必ず含むが、ライブラリのｌｉｂ３０４を含むとは限らない。ｌｉｂ３０４を含む場合には、展開対象のＪＡＲファイル群を記述するｍａｎｉｆｅｓｔ３０３の項目に、ｌｉｂ３０４のＪＡＲファイルのパスを記載する。このｌｉｂ３０４のＪＡＲファイルのパスは設定情報の一例である。

図３（ｂ）に示すアプリケーション３０７は、複数のＪＡＲファイルを含む。含んでいるライブラリｌｉｂ３１０とｌｉｂ３１１のパスは、ｍａｎｉｆｅｓｔ３０９の項目に記載されている。

図３（ｃ）は、インストール後のアプリケーション３０１のインストール用領域４０２内のファイル構成である。アプリケーション３０１はプリインストール用のため、図３（ａ）に示したファイルの構成でファーム用領域４０１に含まれている。アプリケーション３０１が含むライブラリｌｉｂ３０４は、インストールの過程でＪＡＲファイルの外部に展開され、図３（ｃ）のようにインストール先のインストール用領域４０２に書き込まれている。また、ファーム用領域４０１に記憶されているアプリケーション３０１へのリンクであるリンクファイル３０６が作成されている。リンクファイル３０６の実体はシンボリックリンクであって、アプリケーション３０１のデータへのパス情報を含む。シンボリックリンクは、別ファイルシステム間でもリンクを実現することができる特徴をもつ。また、クラスローダがｌｉｂ３０４を見つけるための情報が、クラスパス情報３０５として保存されている。アプリケーション管理フレームワーク２０３は、リンクファイル３０６を読み込むと共に、クラスパス情報３０５を参照してライブラリｌｉｂ３０４を読み込むことで、アプリケーション３０１を実行できる。

次に、ファーム用領域４０１に含まれずに追加でインストールされる一般のアプリケーションについて、図３（ｄ）を用いてインストール済みのファイル構成を説明する。図３（ｄ）は追加して一般のアプリケーションをインストールした後のファイル構成を示す図である。以降、追加してインストールする一般のアプリケーションを一般用アプリケーションと記す。また、指定されたパッケージをインストールする処理を個別インストールと記す。一般用アプリケーションは個別インストールによって処理される。

インストールする一般用アプリケーションが図３（ｂ）のファイル構成であるアプリケーション３０７とする。個別インストールにおいては、インストールするパッケージがアプリケーション管理フレームワーク２０３に与えられる。すると、アプリケーション管理フレームワーク２０３はパッケージをインストール先のインストール用領域４０２に書き込む。また、図３（ｄ）に示すように、含まれるライブラリｌｉｂ３１０とｌｉｂ３１１は外部に展開される。また、クラスローダがライブラリｌｉｂ３１０とｌｉｂ３１１を見つけるための情報は、クラスパス情報３１２として保存される。

ここまで、インストール・アップデートの対象となるアプリケーションのパッケージ構成について説明した。

次に、アプリケーション管理フレームワーク２０３の動作について、図４を用いて説明する。図４は、アプリケーション管理フレームワーク２０３の構成と情報処理装置１０１が備える記憶装置の領域を示す図である。

ファーム用領域４０１とインストール用領域４０２と汎用領域４０３は、記憶装置１３が備える記憶用領域である。パッケージ展開手段４０４は、書き込み先のパスを指定してデータを書き込むことで、汎用領域４０３とインストール用領域４０２のいずれにも書き込みを行える。

アプリケーション管理フレームワーク２０３に対するインストールの指示は、システムアプリケーション２０５から行われる所定のインストール指示である。本実施形態では、所定のインストール指示の指示内容としては、一括インストールと個別インストールの２種類がある。

一括インストールの指示について説明する。ファーム用領域４０１にはプリインストール用のアプリケーション３０１だけでなく、プリインストール用のアプリケーションの一覧を記載したプリインストール用アプリケーションリスト４０７も配置される。図４の例ではプリインストール用アプリケーションはアプリケーション３０１のみであり、アプリケーション３０１のみがプリインストール用アプリケーションリスト４０７に記載されている。また、システムアプリケーション２０５を用いずとも、アプリケーション管理フレームワーク２０３に読み込ませるための一括インストール指示フラグファイルを配置すれば、一括インストールの指示は可能である。配置する場所は、指示完了後にフラグファイルを削除できる場所である必要があるため、インストール用領域４０２または汎用領域４０３とする。例えば、工場生産時の初回起動ではシステムアプリケーション２０５が未インストールのため、一括インストール指示フラグファイルを用いる。一括インストールの指示は、一括インストール指示受付手段４０５によってアプリケーション管理フレームワーク２０３に与えられる。

次に、個別インストールの指示について説明する。個別インストールは、プリインストール用アプリケーションではない一般用アプリケーションのインストールに用いられる。ユーザが情報処理装置１０１にアプリケーション３０７をインストールしたい場合には、システムアプリケーション２０５を経由してアプリケーション３０７のパッケージを指定する。すると、システムアプリケーション２０５は図４に示すように、汎用領域４０３にアプリケーション３０７を配置する。そして、個別インストールの指示がシステムアプリケーション２０５から個別インストール指示受付手段４０６に与えられる。

ここから、インストールの指示を受けたときのアプリケーション管理フレームワーク２０３の動作について、図５を用いて説明する。図５はアプリケーションのインストール処理の手順を示すフローチャートである。

アプリケーション管理フレームワーク２０３は、インストール指示が個別インストールの指示かどうかを判定する（ステップＳ５０１）。個別インストールでない場合、一括インストール指示受付手段４０５がファーム用領域４０１からプリインストール用アプリケーションリスト４０７を読み込み（ステップＳ５０７）、リスト内のアプリケーションを全て処理したかを確認する（ステップＳ５０８）。

ステップＳ５０８で未処理のアプリケーションがあれば、そのアプリケーションのパッケージを参照する（ステップＳ５０９）。ここでは、図４のアプリケーション３０１を参照したものとする。そして、アプリケーション管理フレームワーク２０３はパッケージ展開手段４０４を用いて、インストール用領域４０２内にパッケージの展開を行う。パッケージ展開手段４０４は、まず参照しているパッケージであるアプリケーション３０１へのシンボリックリンクであるリンクファイル３０６を生成する（ステップＳ５１０）。そして、ｍａｎｉｆｅｓｔ３０３を読み込み、ライブラリｌｉｂ３０４をインストール先のインストール用領域４０２に展開する（ステップＳ５１１）。

そして、ここまでの処理で例外が発生したかを確認し（ステップＳ５１２）、例外が発生していればインストール用領域４０２に書き込んだリンクファイル３０６とｌｉｂ３０４を削除する（ステップＳ５１４）。例外が発生していなければ、リンクファイル３０６とｌｉｂ３０４のパスをクラスパス情報３０５として保存する（ステップＳ５１３）。例外が発生するのは、インストール用領域４０２の空き容量不足や、参照しているパッケージが破損している場合である。

ステップＳ５１３あるいはステップＳ５１４が完了すると、ステップＳ５０８を再度実行する。そして、ステップＳ５０８で未処理のアプリケーションがなければ、一括インストール処理を終了する。

ステップＳ５０１で個別インストールを指示されていた場合、システムアプリケーション２０５は図４に示すように、汎用領域４０３にアプリケーション３０７を配置している。配置されたアプリケーション３０７は個別インストール指示受付手段４０６によって読み込まれ、パッケージ展開手段４０４に与えられる。パッケージ展開手段４０４は与えられたアプリケーション３０７をインストール先のインストール用領域４０２に書き込む（ステップＳ５０２）。そしてステップＳ５１１と同様にライブラリｌｉｂ３１０、ｌｉｂ３１１を展開する（ステップＳ５０３）。

そして、ここまでの処理で例外が発生したかを確認し（ステップＳ５０４）、例外が発生していればインストール用領域４０２に書き込んだアプリケーション３０７とライブラリｌｉｂ３１０とｌｉｂ３１１を削除する（ステップＳ５０６）。例外が発生していなければ、アプリケーション３０７とライブラリｌｉｂ３１０とｌｉｂ３１１のパスをクラスパス情報として保存し（ステップＳ５０５）、個別インストール処理は終了する。

以上、アプリケーション管理フレームワーク２０３がインストール処理を行う場合の実施形態を説明した。アプリケーション管理フレームワーク２０３は、ファーム用領域４０１へのリンクファイルを作成することでインストール先のインストール用領域４０２に書き込むデータ量を削減している。

本実施形態の一括インストールでは、ファーム用領域４０１に記憶してあるアプリケーション３０１のパッケージをインストール先のインストール用領域４０２に書き込むことを行わない。アプリケーション３０１のパッケージへのリンクファイルをインストール用領域４０２に生成して書き込む。これにより、インストール用領域４０２に書き込むデータ量を削減したため、データ書き込み時間が短くなり、より早くインストール処理を行うことができる。

＜実施形態２＞
次に、アプリケーション管理フレームワーク２０３のアップデートの処理手順について、図６を用いて説明する。図６は、アプリケーション管理フレームワーク２０３がアップデートで行う処理の手順を示すフローチャートである。

アップデートの指示方法は、実施形態１に記載したインストールの指示方法と同様である。アプリケーション管理フレームワーク２０３は、アップデート対象の新規パッケージに該当するアプリケーションのインストール済みパッケージを、マニフェスト（マニフェストファイル）に記載されるアプリケーションＩＤによって特定する。該当するインストール済みパッケージが存在しなければ、新規インストールとして扱う。

なお、通常利用時にはファーム用領域４０１は書き込みできない状態である。しかし、ファームの更新が必要になった場合は、書き込み許可設定を行うなどして、ファーム用領域４０１を更新する。ファームを更新すると、インストール用領域４０２に展開済みのｌｉｂ３０４やリンクファイル３０６が、ファーム用領域４０１内の更新されたアプリケーション３０１と整合性がとれなくなる。そのため、ファームの更新後に一括インストール指示受付手段４０５から、プリインストール用アプリケーションを一括してアップデートする一括アップデート指示がアプリケーション管理フレームワーク２０３に与えられる。

初めに、図６を用いて一括アップデートの処理手順について説明する。ステップＳ６０１、ステップＳ６０９、ステップＳ６１０、ステップＳ６１１は、それぞれ一括インストールの処理手順であるステップＳ５０１、ステップＳ５０７、ステップＳ５０８、ステップＳ５０９と同様である。

ステップＳ６１１において、パッケージのマニフェスト（マニフェストファイル）を参照することで、アップデートすべきインストール済みパッケージが特定される。特定されたパッケージのリンクファイル３０６、およびｌｉｂ３０４は、ファーム用領域４０１内のアプリケーション３０１と整合性がとれていない状態である。そこで、インストール用領域４０２のインストール済みパッケージのｌｉｂ３０４とリンクファイル３０６は、パッケージ展開手段４０４によって削除される（ステップＳ６１２）。そして、ステップＳ５１０と同様にリンクファイルを生成し（ステップＳ６１３）、ステップＳ５１１と同様にマニフェスト（マニフェストファイル）を読み込んでｌｉｂを展開する（ステップＳ６１４）。

そして、ステップＳ５１２と同様にここまでの処理で例外が発生したか確認し（ステップＳ６１５）、例外が発生していなければステップＳ５１３と同様の処理を行う（ステップＳ６１６）。

ステップＳ６１５において例外が発生していた場合、アップデートに失敗したアプリケーション３０１は実行できなくなる。そこで、アプリケーション管理フレームワーク２０３はアップデートに失敗したアプリケーション３０１が実行できなくなったという警告メッセージを表示する（ステップＳ６１７）。表示方法はコンソールに直接表示する方法や、ログファイルとして記録しておく方法が考えられるが、特に制限はない。また、警告メッセージの内容も上記に限る必要はない。

ステップＳ６１６、ステップＳ６１７のいずれかが終了すると再度ステップＳ６１０を実行する。ステップＳ６１０においてプリインストール用アプリケーションリスト４０７に記載されるアプリケーションを全て処理した場合、一括アップデート処理は終了する。

次に、個別アップデートの処理手順について、図８（ａ）、図８（ｂ）、図８（ｃ）、図８（ｄ）を用いて説明する。図８（ａ）、図８（ｂ）、図８（ｃ）、図８（ｄ）は、アプリケーション管理フレームワーク２０３による一般用アプリケーションのアップデートの各処理において、汎用領域４０３とインストール用領域４０２に書き込まれたファイルを示した図である。インストール済みアプリケーション８０１がアプリケーション８０６によって個別アップデートされる例で説明する。

アプリケーション８０６はアプリケーション８０１のバージョンアップ版であり、ｍａｎｉｆｅｓｔ８０３とｍａｎｉｆｅｓｔ８０８において、アプリケーションの名前とｉｄは同一である。アップデート開始時点における汎用領域４０３とインストール用領域４０２の状態は、図８（ａ）である。

ステップＳ６０１で個別アップデートと判定された場合、パッケージ展開手段４０４はインストール用領域４０２内のアプリケーション８０１、ｌｉｂ８０４を汎用領域４０３に退避する（ステップＳ６０２）。退避処理は、汎用領域４０３へのコピーとインストール用領域４０２からの削除によって行う。退避処理は、アップデートに失敗した場合にアップデート前のアプリケーション８０１が使用出来る状態に復旧するために行う。退避後、汎用領域４０３とインストール用領域４０２の状態は、図８（ｂ）となる。

そして、ステップＳ５０２、ステップＳ５０３、ステップＳ５０５、ステップＳ５０５と同様の処理をステップＳ６０３、ステップＳ６０４、ステップＳ６０５、ステップＳ６０６で行い、新しいパッケージにアップデートする。ステップＳ６０６終了後、汎用領域４０３とインストール用領域４０２の状態は、図８（ｃ）となる。

ステップＳ６０５において例外が発生していた場合、インストール用領域４０２に新規に書き込んだファイルを削除し、退避したアプリケーション８０１、ｌｉｂ８０４をインストール用領域４０２に戻す（ステップＳ６０７）。想定される例外として、インストール用領域４０２の空き領域不足による書き込み例外がある。例えば、アップデート前とアップデート後でパッケージのサイズが増加する場合に、空き領域不足の例外が起こりえる。また、ステップＳ６０２の退避を行わずに新しいパッケージをステップＳ６０３、ステップＳ６０４で書き込んでしまうと、インストール用領域４０２の空き領域不足が起きやすくなる。また、退避を行わずに上書きで書き込んでしまうと、アップデートが失敗した時にステップＳ６１０のようにアップデート前の状態に戻せない。

ステップＳ６０６、ステップＳ６０７のいずれかが完了すると、汎用領域に配置されているパッケージは削除され（ステップＳ６０８）、アップデートの処理は終了する。ステップＳ６０５において例外が発生しなかった場合、ステップＳ６０８後の汎用領域４０３とインストール用領域４０２の状態は、図８（ｄ）となる。

ただし、退避処理は省略することもできる。インストール用領域４０２に十分な空き容量があれば、退避処理を行う必要はない。アップデート処理中はアプリケーション８０１とアプリケーション８０６を共にインストール用領域４０２に配置し、アップデート処理の最後にアプリケーション８０６のパッケージを削除することもできる。こうすると退避処理にともなう書き込み処理がなくなるため、より高速にアップデートの処理が可能となる。

なお、一括インストールされたアプリケーションを個別アップデートによってアップデートするときも、本実施形態は問題なく動作する。個別インストールされたアプリケーションが一括アップデート対象となる場合も問題なく動作する。

以上、アプリケーション管理フレームワーク２０３がアップデート処理を行う場合の実施形態を説明した。

本実施形態では、一括インストールされたアプリケーションのアップデートは、実施形態１と同様である。ファーム用領域４０１に格納してある更新後のアプリケーション３０１に対して、インストール用領域４０２においてリンクファイルを生成して書き込むので、データ書き込み時間が短くなり、早くアップデート処理を行うことができる。

＜実施形態３＞
実施形態１、２では、ファーム用領域４０１にアプリケーションのパッケージが一般的なＪＡＲファイルの形式で格納される例を説明した。しかし、ファームは一般的に特定のデバイスや特定の機種向けに作成される。ファームにアプリケーションのパッケージを含めるときに、アプリケーション管理フレームワーク２０３によるインストール処理に適した形式に変更しておけば、インストールに要する時間と記憶領域の使用量を削減できる。

実施形態１では、アプリケーション３０１のパッケージをインストール用領域４０２に書き込まずに、リンクファイル３０６を作成することで書き込むデータ量を削減した。しかし、アプリケーション３０１に含まれるｌｉｂ３０４は、通常のクラスローダが読み込めるようにインストール用領域４０２に書き込んでいた。もし、ｌｉｂ３０４がファーム用領域４０１内かつアプリケーション３０１の外部に記憶されていれば、ｌｉｂ３０４をインストール用領域４０２に書き込まずにリンクファイルを作成するだけでインストール処理を完了できる。

また、プリインストール用アプリケーションが複数ある場合に、それらのアプリケーションが同一のｌｉｂを含むことがある。例えば、通信機能を実現するｌｉｂは多くのアプリケーションで共通である。また、ファームとプリインストール用アプリケーション間で同一のｌｉｂを共有することもある。同一のｌｉｂをファーム用領域４０１に重複して格納しないようにすれば、ファーム用領域４０１が消費する領域量を削減することができるので、インストールに要する時間を削減できる。

ファームに含めるアプリケーションのパッケージをアプリケーション管理フレームワーク２０３によるインストール処理に適した形式に変更する実施形態を、図７を用いて説明する。図７は、パッケージを改変又は変更してファームに組み込む処理の手順を示すフローチャートである。

初めに、ファームにパッケージを改変又は変更して組み込む手順について説明する。ファームの改変作業は、スクリプトを用いて自動実行するものとする。スクリプトを実行するコンピュータ又は変更装置を情報処理装置１０１と異なる、外部のコンピュータ又は変更装置とする。

スクリプトは、一般的なＪＡＲファイルの形式であるアプリケーションのパッケージ群を、オリジナルパッケージ群として参照可能とする。スクリプトは、プリインストールするパッケージの一覧を作成する（ステップＳ７０１）。一覧には、各ＪＡＲファイルのファイル名を記載する。

そして、一覧のパッケージが全てファームに組み込み済みかを確認する（ステップＳ７０２）。まだ組み込まれていないパッケージがあれば、パッケージを一つ取得する（ステップＳ７０３）。

そして、取得したパッケージのマニフェスト（マニフェストファイル）を参照し、展開対象のｌｉｂを取得する（ステップＳ７０４）。

そして、展開対象のｌｉｂと同一のｌｉｂが全てファームに組み込まれているかを確認する（ステップＳ７０５）。ｌｉｂが同一であるかの判定は、Ｌｉｎｕｘ（登録商標）環境等で使用出来るｄｉｆｆコマンドを用いて行える。また、ｌｉｂもＪＡＲファイルであるため、マニフェストを含んでいる。ｌｉｂのマニフェストに記載されているＩＤとバージョンを比較することでも、同一であるかを判定することができる。バージョンが異なる場合は、同一ではない可能性があるため同一でないと判定する。

ステップＳ７０５で展開対象のｌｉｂにファームに組み込まれていないものがあれば、組み込まれていないｌｉｂをファームに組み込む（ステップＳ７０６）。ファームに組み込み時には、ｌｉｂのファイル名は一意のものにリネームする。リネームは、複数のパッケージで異なるｌｉｂが同一の名前で使われている場合に、異なるｌｉｂで組み込み済みのｌｉｂを上書きしないために行う。

ステップＳ７０５で展開対象のｌｉｂが全てファームに組み込まれている、あるいはステップＳ７０６が完了すると、展開対象のｌｉｂを取得したパッケージから削除する（ステップＳ７０７）。

そして、取得したパッケージのマニフェストに記載されている展開対象のｌｉｂのパスを、ファームに組み込み済みの展開対象と同一のｌｉｂのパスに改変又は変更する（ステップＳ７０８）。

以上の変更を行うと、スクリプトはパッケージをファームに組み込む（ステップＳ７０９）。そして、再度ステップＳ７０２を行う。

ステップＳ７０２でプリインストールパッケージが全てファームに組み込み済みの場合、ファームの作成は終了する。

ただし、ステップＳ７０５において展開対象のｌｉｂを全てファームに組み込まなくてもよい。パッケージ内に残したいｌｉｂがあれば、ステップＳ７０７においてｌｉｂを削除せず、ステップＳ７０８のマニフェスト改変でパスの変更を行わなければよい。パッケージ内に残したいｌｉｂの例としては、パッケージ固有のｌｉｂなどが挙げられる。

また、情報処理装置１０１上でスクリプトを実行する構成も可能である。生産工程において、ファーム用領域４０１、またはインストール用領域４０２、または汎用領域４０３に一度オリジナルパッケージ群を格納し、スクリプトを実行して前述と同様の処理を行う。そして、スクリプトは改変又は変更したパッケージをファーム用領域４０１に書き込み、オリジナルパッケージ群を削除する。

ここまで、ファームを作成する手順について説明した。この手順を実施する前のパッケージとファームに組み込み後のパッケージのファイルの構成を図９に示す。図９は、一般的なＪＡＲファイル形式であるオリジナルのパッケージのファイル構成と、ファームに組み込み後のパッケージのファイル構成を示す図である。

図９では、アプリケーション９０７とアプリケーション９１１をファームに組み込む例を示している。アプリケーション９０７とアプリケーション９１１には、ｌｉｂ９１０が共通して含まれている。アプリケーション９１１とアプリケーション９０７は、図９のファーム用領域４０１に示すファイルのように組み込まれる。

図９左側に示したアプリケーション９０７のｌｉｂ９１０のファイル名を、“ｌｉｂ＿ｅｎｇｌｉｓｈ”とする。このとき、ｍａｎｉｆｅｓｔ９０９にはｌｉｂ９１０のパスが“．／ｌｉｂ＿ｅｎｇｌｉｓｈ”として記載されている。ファームに組み込み後、ｌｉｂ９１０、ｌｉｂ９１４がファーム用領域４０１の“ｃｏｍｍｏｎｌｉｂ”という名前のフォルダに格納され、ｃｏｍｍｏｎｌｉｂフォルダは情報処理装置１０１上で、“／ａｐｐ／ｃｏｍｍｏｎｌｉｂ”というパスにマウントされるとする。また、ステップＳ７０５におけるリネーム処理によって、ｌｉｂ９１０は“ｌｉｂ００１”にリネームされたとする。このとき改変マニフェスト９１５には、“／ａｐｐ／ｃｏｍｍｏｎｌｉｂ／ｌｉｂ００１”のようにパスが記載される。

ここまで、ファームの作成手順と作成したファームのファイル構成について説明した。ここから、作成したファームに含まれるプリインストール用アプリケーションのインストール手順について、図１０と図１１を用いて説明する。図１０は、ファーム用領域４０１のパッケージをインストール用領域４０２にインストール後のファイル構成を示す図である。図１１はインストール処理の手順を示すフローチャートである。

図１０のように、ファーム用領域４０１にアプリケーション９０７とアプリケーション９１１が含まれる例で説明する。プリインストール用アプリケーションリスト４０７には、アプリケーション９０７とアプリケーション９１１が記載されているものとする。

図１１のステップＳ１１０１では、ステップＳ５０１と同様にアプリケーション管理フレームワーク２０３はインストールの指示が個別インストールであるかどうかを判定する。個別インストールであると判定した場合、個別インストールの処理手順であるステップＳ１１０２、Ｓ１１０３、Ｓ１１０４、Ｓ１１０５、Ｓ１１０６は、それぞれＳ５０２、Ｓ５０３、Ｓ５０４、Ｓ５０５、Ｓ５０６と同様である。

ステップＳ１１０１にて個別インストールではないと判定した場合、つまり一括インストール処理の処理手順であるステップＳ１１０７、Ｓ１１０８、Ｓ１１０９は、それぞれステップＳ５０７、Ｓ５０８、Ｓ５０９と同様の処理である。

図１１のステップＳ１１０９で参照したパッケージが図１０のファーム用領域４０１内のアプリケーション９０７であるとする。このとき、パッケージ展開手段４０４は参照パッケージのリンクファイル１００１を生成する（ステップＳ１１１０）。

実施形態１ではｌｉｂを展開してインストール用領域４０２に書き込んだ一方、本実施形態では展開済みのｌｉｂ９１０がファーム用領域４０１に含まれている。そのため、パッケージ展開手段４０４は改変マニフェスト９１５を読み込んでｌｉｂ９１０へのリンクであるリンクファイル１００２を生成する（ステップＳ１１１１）。

そして、改変マニフェスト９１５に参照パッケージが含むｌｉｂの記載があるかを確認し（ステップＳ１１１２）、記載があればそのｌｉｂをステップＳ５１１と同様に展開する（ステップＳ１１１６）。

ステップＳ１１１２で記載がない場合、またはステップＳ１１１６が完了すると、ここまでの処理で例外が発生したかを確認する（ステップＳ１１１３）。例外が発生していなければ、リンクファイル１００１とリンクファイル１００２のパスをクラスパス情報１００３として保存する（ステップＳ１１１４）。ステップＳ１１１３で例外が発生していれば、インストール用領域に生成されたリンクファイル１００１、リンクファイル１００２を削除する（ステップＳ１１１５）。

ステップＳ１１１４、またはステップＳ１１１５が完了すると、再度ステップＳ１１０８を実行する。そして、アプリケーション９０７と同様にアプリケーション９１１についても、ステップＳ１１０９を実行して、Ｓ１１１０によってリンクファイル１００４を作成する。そして、ステップＳ１１１１を実行してｌｉｂ９１０へのリンクファイル１００５とｌｉｂ９１４へのリンクファイル１００６を作成する。そしてステップＳ１１１２、Ｓ１１１３を実行し、ステップＳ１１１４においてリンクファイル１００４、リンクファイル１００５、リンクファイル１００６のパスをクラスパス情報１００７として保存する。そして、再度ステップＳ１１０８を実行する。

そして、ステップＳ１１０８で全てのアプリケーションを処理したと判定し、一括インストールの処理は終了する。

以上、アプリケーション管理フレームワーク２０３によるインストール処理に適した形式に変更したパッケージをファームに含めてインストールする手順について説明した。

本実施形態では、インストール処理に適した形式にパッケージを変更したので、実施形態１よりもデータ書き込み時間が短くなり、高速にインストールを行うことができる。

＜実施形態４＞
実施形態３では、リンクファイルを用いて、アプリケーションを読み込むようにして、書き込むデータ量を削減した。しかし、記憶装置１３を管理するファイルシステムによっては、書き込むデータ量が小さい空のファイルの作成ですら、時間を要する場合がある。このような場合には、アプリケーション２０４のインストール処理においてアプリケーション管理フレームワーク２０３が作成するファイル数を削減することで、情報処理装置１０１のパフォーマンスを向上させることが要求される。

実施形態３では、アプリケーション９０７のインストールにおいて、リンクファイル１００１とリンクファイル１００２とクラスパス情報１００３を作成した。しかし、クラスパス情報１００３の内容はリンクファイル１００１とリンクファイル１００２のパスである。クラスパス情報１００３の内容を、ファーム用領域４０１内のアプリケーション９０７のｊａｒのパスと、アプリケーション９０７が必要とするｌｉｂ９１０のパスにすることで、リンクファイル１００１とリンクファイル１００２を作成する必要はなくなる。

リンクファイルを作成せずにインストール処理を高速に行う実施形態を、図１２を用いて説明する。図１２は、実施形態４にかかるインストール処理のフローチャートである。

ステップＳ１２０１、ステップＳ１２０２、ステップＳ１２０３、ステップＳ１２０４、ステップＳ１２０５、ステップＳ１２０６は、それぞれステップＳ１１０１、ステップＳ１１０２、ステップＳ１１０３、ステップＳ１１０４、ステップＳ１１０５、ステップＳ１１０６と同様である。

また、ステップＳ１２０７、ステップＳ１２０８、ステップＳ１２０９は、ステップＳ１１０７、ステップＳ１１０８、ステップＳ１１０９と同様である。

図１１のステップＳ１１０９で参照したパッケージが図１０のファーム用領域４０１内のアプリケーション９０７であるとする。このとき、パッケージ展開手段４０４は参照パッケージのパスを、クラスパス情報として保持する（ステップＳ１２１０）。保持の方法としては、プログラム中の変数への格納などがある。

そして、パッケージ展開手段４０４は改変マニフェスト９１５を読み込んでｌｉｂ９１０のパスを、クラスパス情報に追加して保持する（ステップＳ１２１１）。

そして、ステップＳ１１１２、ステップＳ１１１６と同様の処理を行う（ステップＳ１２１２、ステップＳ１２１５）。

そして、ステップＳ１１１３と同様にここまでの処理で例外が発生したかを確認し（ステップＳ１２１３）、例外が発生していなければ、ステップＳ１１１４と同様の処理を行う（ステップＳ１２１４）。ステップＳ１２１３で例外が発生していても、実施形態４ではリンクファイルを作成していないため、削除すべきファイルは存在しない。

本実施形態は、リンクファイルを作成せずに高速にインストールを行うことができる。

＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコード（コンピュータプログラム）を記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。係る記憶媒体は言うまでもなく、コンピュータ読み取り可能な記憶媒体である。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

１０１ 情報処理装置
３０１ アプリケーション
３０６ リンクファイル
４０１ ファーム用領域
４０２ インストール用領域
４０４ パッケージ展開手段

Claims (12)

1. アプリケーションデータをインストールする情報処理装置であって、
   インストール用の前記アプリケーションデータを予め記憶する第１記憶領域と、インストール先の第２記憶領域とを含む記憶手段と、
   所定のインストール指示に従って、前記アプリケーションデータへのパスを前記第２記憶領域に書き込む書き込み手段と、
   を備えることを特徴とする情報処理装置。
2. 前記アプリケーションのパッケージにライブラリが含まれる場合、前記書き込み手段は、前記アプリケーションデータへのパスと前記ライブラリを前記第２記憶領域に書き込むことを特徴とする請求項１に記載の情報処理装置。
3. 前記アプリケーションのパッケージにライブラリが含まれ、前記アプリケーションのパッケージの外部の前記第１記憶領域に前記ライブラリが記憶された場合、前記書き込み手段は、前記アプリケーションデータへのパスと前記アプリケーションのパッケージの外部に記憶された前記ライブラリへのパスを、前記第２記憶領域に書き込むことを特徴とする請求項１に記載の情報処理装置。
4. 前記アプリケーションのパッケージ内の前記ライブラリを削除し、前記アプリケーションのパッケージに含まれる設定情報における、前記アプリケーションのパッケージ内の前記ライブラリへのパスを前記アプリケーションのパッケージの外部に展開された前記ライブラリへのパスに変更する変更手段をさらに備えることを特徴とする請求項３に記載の情報処理装置。
5. 前記設定情報はマニフェストファイルであることを特徴とする請求項４に記載の情報処理装置。
6. 前記書き込み手段は、前記アプリケーションのパッケージへのパスと前記ライブラリへのパスとを含む一つのファイルを前記第２記憶領域に書き込むことを特徴とする請求項３乃至５の何れか１項に記載の情報処理装置。
7. 前記アプリケーションのパッケージへのパスと前記ライブラリへのパスはそれぞれシンボリックリンクであることを特徴とする請求項３乃至５の何れか１に記載の情報処理装置。
8. 前記アプリケーションは、プリインストール用のアプリケーションであることを特徴とする請求項１乃至７の何れか１に記載の情報処理装置。
9. プリインストール用の前記アプリケーションは複数ある場合、複数の前記アプリケーションを記載したリストを用いて、複数の前記アプリケーションを一括インストールすることを特徴とする請求項８記載の情報処理装置。
10. 前記第１記憶領域に記憶された前記アプリケーションデータが更新された場合、前記書き込み手段は、前記第２記憶領域に書き込まれた前記パスを削除し、更新された前記アプリケーションデータへのパスを前記第２記憶領域に書き込むことを特徴とする請求項１記載の情報処理装置。
11. アプリケーションデータをインストールする情報処理方法であって、
    インストール用の前記アプリケーションデータを第１記憶領域に予め記憶する記憶工程と、
    所定のインストール指示に従って、前記アプリケーションデータへのパスをインストール先の第２記憶領域に書き込む書き込み工程と、
    を備えることを特徴とする情報処理方法。
12. コンピュータに、
    インストール用のアプリケーションデータを第１記憶領域に記憶させる記憶手順と、
    所定のインストール指示に従って、前記アプリケーションデータへのパスを第２記憶領域に書き込ませる書き込み手順と、
    を実行させるためのプログラム。

Images