JP6147139B2 - 情報処理装置、その制御方法、及びコンピュータプログラム - Google Patents

Description

本発明は、情報処理装置、その制御方法、及びコンピュータプログラムに関する。

近年、画像形成装置においては、ＪＡＶＡ（登録商標）環境に代表されるようなアプリ動作環境が提供されている。ＪＡＶＡ（登録商標）の持つプログラムの可搬性を利用して、拡張可能なアプリを提供する技術が提案されている。画像形成装置の機能やユーザビィリティの向上を図るために、ＪＡＶＡ（登録商標）環境などの環境下で動作するアプリを作成し、画像形成装置にインストールすることで、当該アプリにより所望の機能を実現できる。

アプリプラットフォームとしては、組み込み機器向けのＪＡＶＡ（登録商標）アプリプラットフォームである、ＯＳＧｉがある（非特許文献１）。ＯＳＧｉは、Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍの略称であり、以下、ＯＳＧｉと記述する。ＯＳＧｉでは、ソフトウェアモジュールの管理単位としてバンドルを定義しており、インストール／開始／停止／更新／アンインストールからなるライフサイクルを管理するための仕様を定義している。ここで、バンドルとは、Ｊａｖａ（登録商標）モジュールのことを指し、本発明においては、アプリと同義である。このようなアプリプラットフォームは、コピー、スキャン、プリント等の組み込み機能をアプリに提供することができる。

またＯＳＧｉの仕様には、ホストバンドルとフラグメントバンドルという仕組みがある。ホストバンドルとは、フラグメントバンドルが追加されるバンドルを指す。フラグメントバンドルとは、単独では動作せず、ホストバンドルのクラスローダ空間にバンドル自身を追加（アタッチ）する形式のバンドルである。アプリの修正または拡張時に、フラグメントバンドルを用いてホストバンドルの機能を修正または拡張することで、インストールするファイルサイズを小さくすることができ効率的にモジュールを配布することが可能となる。現状、ホストバンドルへのフラグメントバンドルのインストールは、ＯＳＧｉの仕様上、特にその数に制限が設けられていない。

「ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ，Ｒｅｌｅａｓｅ４」， ｈｔｔｐ：／／ｗｗｗ．ｏｓｇｉ．ｏｒｇ／Ｄｏｗｎｌｏａｄ／Ｒｅｌｅａｓｅ４Ｖ４０，２００５年１０月

しかしながら、現状のＯＳＧｉの仕様には１つのホストバンドルに対するフラグメントバンドルの追加可能数に制限を加える仕組みがない。例えば、ユーザにそのアプリをお試し版で使わせたい場合、お試し版ではフラグメントバンドルの追加数に一定の制限を設け、正規版アプリとの差別化を図ることができない。本発明は、ホストバンドルに追加できるフラグメントバンドルの数を制限し、アプリ提供サービスの提供形態を改善させる情報処理装置を提供することを目的とする。

本発明の一実施形態の情報処理装置は、特定のサービスを提供するアプリケーションを当該アプリケーションのマニフェストを基に管理するフレームワークを具備する。前記情報処理装置は、ホストアプリケーションを拡張する拡張アプリケーションをインストールする際に、前記ホストアプリケーションを拡張するためにインストールされる前記拡張アプリケーションの数が、前記ホストアプリケーションのマニフェストに記載されている当該ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満の場合にインストールを実行するインストール手段を備える。

本発明の情報処理装置によれば、ホストバンドルに追加できるフラグメントバンドルの数を制限し、アプリ提供サービスの提供形態を改善させることが可能となる。

画像形成装置のハードウェア構成図である。 画像形成装置のソフトウェアモジュール階層図である。 アプリをインストールする流れを示したブロック図である。 フラグメントバンドルの概念図である。 アプリ管理画面、インストール画面のＵＩを示した図である。 フラグメント上限数を指定したマニフェストを説明した図である。 ＯＳＧｉでのアプリ管理状態を示した図である。 実施例１を説明するためのブロック図である。 実施例１の、インストール制御部の処理を示すフローチャートである。 実施例２を説明するためのブロック図である。 実施例２の、インストール制御部の処理を示すフローチャートである。 実施例３を説明するためのブロック図である。 実施例３の、インストール制御部の処理を示すフローチャートである。 実施例４の、用途ごとのフラグメント上限数を指定したマニフェストを説明した図である。 実施例４を説明するためのブロック図である。 実施例４の、インストール制御部の処理を示すフローチャートである。 実施例５を説明するためのブロック図である。 実施例５の、インストーラ制御部の処理を示すフローチャートである。

以下、本発明において使用する言葉の定義を行う。「ホストバンドル」とは、フラグメントバンドルが追加される対象となるバンドルである。「フラグメントバンドル」とは、単独では動作せず、ホストバンドルのクラスローダ空間に自分自身を追加するバンドルである。ホストバンドルへフラグメントバンドルを追加することを、以降「フラグメントバンドルのインストール」と呼ぶ。同様に、ホストバンドルに追加済みのフラグメントバンドルを削除することを、以降「フラグメントバンドルのアンインストール」と呼ぶ。Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍの仕様上、ホストバンドル：フラグメントバンドル＝１：Ｎの関係にあり、フラグメントバンドルは一つのホストバンドルにのみ追加できる。

上述したように、フラグメントバンドルをホストアプリケーションの機能拡張のために拡張アプリケーションとして利用する場合、ホストバンドルに複数のフラグメントバンドルが無制限に追加されると、正規版とお試し版の差別化が図れない。また、ホストバンドルとフラグメントバンドルの組み合わせパターンが増加する。これにより、テストなどを含む開発規模も増加してしまう可能性ある。フラグメントバンドルの追加可能な個数を制限することで、組み合わせ数が抑えられ、開発規模を安定させることが可能となる。

以下では、本発明により解決される課題について説明する。まず、現状のＯＳＧｉの仕様では、フラグメントバンドルの個数制限を考慮するとき、フラグメントバンドルのインストール時に個数を制限できない（課題１）。

また、バージョンアップなどにより、ホストバンドル自体が上書きインストールされるときに、ホストバンドルが保持するフラグメント上限値が変わることによる不整合が発生する（課題２）。

更に、課題１において、ホストバンドルが常時起動タイプのアプリの場合、ホストバンドルが停止できない制約により、再起動時に更新処理を行う予約インストール・アンインストールが考慮されていない（課題３）。

また、課題１において、フラグメントバンドルの用途によって、制限する個数を制御できない課題がある（課題４）。

さらに画像形成装置全体でリソース制限があるため、画像形成装置全体の設定として、フラグメントバンドルの個数の制限を実現できない（課題５）。

まず、以下で記載する各実施例に共通な構成を説明する。図１は、印刷機能やスキャン機能、ネットワーク通信機能などを備える画像形成装置１３０のハードウェア構成図である。以下では、画像形成装置１３０を情報処理装置の例として説明するが、本発明はＰＣや形態端末などにも適用可能である。図１に示す画像形成装置１３０は、コントローラ１００を備える。コントローラ１００は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＨＤＤ１０４、操作部Ｉ／Ｆ１０５、ネットワークＩ／Ｆ１０６、スキャナＩ／Ｆ１０８、画像形成部１０９、プリンタＩ／Ｆ１１０を備える。また、画像形成装置１３０は、スキャナ部１１３、プリンタ部１１４、操作部１１８を備える。なお、ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。コントローラ１００はスキャナ部１１３やプリンタ部１１４と電気的に接続され、一方でＬＡＮ１１６を介して外部デバイスと接続される。

ＣＰＵ１０１は、ＲＯＭ１０２に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御し、またコントローラ内部で行われる各種処理についても統括的に制御する。ＲＯＭ１０２は読み出し専用の不揮発記憶領域であり、画像形成装置１３０のブートプログラムなどが格納されている。ＲＡＭ１０３は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ１０３は、記憶した内容を電源ｏｆｆ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源ｏｆｆ後に記憶内容が消去されるＤＲＡＭなどにより構成される。ＨＤＤ１０４は不揮発記憶領域であり、システムアプリなどを格納する。図３で説明するインストールするアプリを含むファームウェアは、ＨＤＤ１０４に格納される。

操作部Ｉ／Ｆ１０５は、システムバス１１９と操作部１１８を接続するインタフェース部である。具体的には操作部１１８に表示するデータをシステムバス１１９から受取り表示すると共に、操作部１１８からの入力情報をシステムバス１１９へ出力する。画像形成装置１３０に対するユーザの指示や情報提示は、操作部１１８を介して行われる。ネットワークＩ／Ｆ１０６はＬＡＮ１１６、ＷＡＮ１１７及びシステムバス１１９に接続し、外部との情報の入出力を行う。本実施形態では、画像形成装置１３０は、ネットワークＩ／Ｆ１０６を介して図３に示すＰＣ３００からアプリケーションをインストールする。

スキャナＩ／Ｆ１０８は、システムバス１１９とスキャナ部１１３を接続するインタフェース部である。スキャナＩ／Ｆ１０８は、スキャナ部１１３から受取った画像データに対して、補正、加工、及び編集を行う。画像形成部１０９は、画像データの方向変換、画像圧縮、伸張部などを行う。プリンタＩ／Ｆ１１０は、画像形成部１０９から送られた画像データを受取り、画像形成後にプリンタ部１１４にて印刷する。

図２は、画像形成装置１３０のソフトウェアモジュール階層図である。なお図２以降に示す各ソフトウェアはＲＯＭ１０２、またはＨＤＤ１０４に保存され、ＣＰＵ１０１にて実行される。また、実行時に使用する各種情報はＲＡＭ１０３もしくはＨＤＤ１０４に保持してソフトウェア機能間での各種情報のやりとりを行う。さらに外部機器との通信は、ネットワークＩ／Ｆ１０６を用いて行われる。

次に、画像形成装置１３０が備える各ソフトウェアを説明する。ソフトウェアは、まずオペレーティングシステム（ＯＳ）プラットフォーム２０１を有し、ＯＳ２０１上にソフトウェアプラットフォーム２０２が構成されている。ソフトウェアプラットフォーム２０２は、Ｊａｖａ（登録商標）ＶＭ２０３のランタイム環境として構成されており、インタプリタとしてＪＡＶＡ（登録商標）ＶＭ２０３、フレームワーク群２０４、ライブラリ２０５を備える。また、ソフトウェアプラットフォーム２０２は、アプリ管理部２０７、インストール制御部２０８、ログインアプリ２０９、一般アプリ２１０を備える。ライブラリ２０５は、標準のＡＰＩライブラリから構成されている。フレームワーク群２０４は、ＯＳＧｉ２０６から構成され、このＯＳＧｉ２０６は、単一のＪａｖａ（登録商標）ＶＭ２０３上に複数のアプリを動作させることができる。

更に、ＯＳＧｉ２０６はＯＳＧｉ拡張部２１１を備え、ＯＳＧｉ拡張部２１１により、ＯＳＧｉ２０６に対し必要に応じて機能を拡張可能である。ＯＳＧｉ２０６は、アプリのライフサイクルの管理やアプリ間通信機能などを提供する。このＯＳＧｉ２０６上には、複数のシステムサービスを行うソフトウェアがプリインストールされている。システムサービスとして、アプリ管理部２０７は複数のアプリ群を管理し、新たなアプリの追加、更新、削除をする。アプリ管理部２０７は、インストール制御部２０８を利用して、アプリの追加、更新、削除を行う。画像形成装置１３０の起動時に、ＯＳＧｉ２０６は、ＨＤＤ１０４に保存されたサービス起動順リストに従い、後述するログインアプリ２０９、インストール制御部２０８、アプリ管理部２０７などのシステムサービスを実行するソフトウェアを起動していく。

一般アプリ２１０は、画像形成装置１３０において各種処理をユーザに提供する。例えば、一般アプリ２１０は、画像の加工や圧縮アプリ、印刷制限などの部門管理を行うアプリなどがある。一方、ログインユーザを管理するログインアプリ２０９などがある。ログインアプリ２０９は、アプリのログイン中に任意のアプリから任意のタイミングでログイン情報の問い合わせの可能性があるため、停止できない特性を持つアプリである。仮にログインアプリが停止していた場合、ログイン情報の取得ができなくなるため、例えば、ログイン情報に紐づくデータを利用しているようなアプリがあった場合、データの取得に失敗し、その動作に支障が生じる。ここで、ログイン情報とは、現在画像形成装置１３０にログインしているユーザのログイン名やメールアドレスなどの情報を指す。上述の特性を持つため、画像形成装置１３０が起動中の場合、このログインアプリ２０９は必ず１つが動作する。

各種機能を実現する一般アプリ２１０は、このアプリ管理部２０７の管理下で動作する。アプリ管理部２０７は、管理下に追加されたアプリのバージョンを含むアプリ情報、ライセンス情報などを保持している。さらに画像形成装置１３０内のアプリのアンインストール指示に応答し、アプリ管理部２０７は一般アプリ２１０を管理対象から外す。一般アプリ２１０、あるいは、ログインアプリ２０９は、図４で述べるようなホストバンドルとフラグメントバンドルという形態で、提供することが可能である。

図３は、ユーザが、ＰＣ３００から画像形成装置１３０へ、アプリをインストールする流れを示したブロック図である。ＰＣ３００のＷＥＢブラウザ（不図示）に図５のインストール画面５２０に示すＷＥＢページで構成されたアプリのインストールＵＩ３０１を表示し、ユーザは、このインストールＵＩ３０１からインストールしたいアプリを指定し、インストールを行う。インストールＵＩ３０１で指定されたアプリを受信したアプリ管理部２０７は、それをインストール制御部２０８に渡す。アプリファイルを受信したインストール制御部２０８は、インストールを許可すると判断した場合はインストールしたアプリファイルをＯＳＧｉ２０６に渡す。ＯＳＧｉ２０６は、受け取ったアプリファイルを実行する。なお、インストールされたアプリは、アプリ管理部２０７によって管理される。なおＰＣはＷｅｂブラウザが動作するものであればよく、ハードウェアおよびソフトウェア構成の説明は省略する。

図４は、フラグメントバンドルの概念を説明する図である。ここでは、ホストバンドル４００に対して、言語ローカライズリソースをもつフラグメントバンドル４０１と４０２がインストールされる例を示す。ホストバンドルにフラグメントバンドルをインストールするためには、以下のマニフェスト、及びバンドルパーミッションの指定が必要となる。なお、マニフェストとは、ｊａｒファイルの説明が記載されたファイルである。ｊａｒファイルとは、複数のクラスファイルをアーカイブとして１つにまとめたものである。
・ホストバンドルのマニフェスト４０３
Ｂｕｎｄｌｅ−ＭａｎｉｆｅｓｔＶｅｒｓｉｏｎに２が指定される。Ｂｕｎｄｌｅ−ＳｙｍｂｏｌｉｃＮａｍｅには、フレームワーク内で一意な名前が付される。
・フラグメントバンドルのマニフェスト４０５
Ｂｕｎｄｌｅ−ＭａｎｉｆｅｓｔＶｅｒｓｉｏｎに２が指定される。Ｆｒａｇｍｅｎｔ−Ｈｏｓｔには、ホストバンドルのマニフェスト４０３に記載の＜ホストのバンドルシンボリック名＞が指定される。本値が一致することでホストバンドルとフラグメントバンドルが同一アプリの構成要素であることを示すものとなる。
・ホストバンドルのパーミッション４０４
ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ［バンドルシンボリック名， ＨＯＳＴ］
・フラグメントバンドルのパーミッション４０６
ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ［バンドルシンボリック名， ＦＲＡＧＭＥＮＴ］

上記条件を満足する状態で、フラグメントバンドルをインストールすると、ＯＳＧｉ２０６がフラグメントバンドルのマニフェスト情報からホストバンドルを特定し、ホストバンドルのクラスパスにフラグメントバンドル自身のクラスパスを追加する。ここで「クラスパス」とは、ＪＡＶＡ（登録商標）アプリ実行するときに、ＪＡＶＡ（登録商標）ＶＭがどの場所からクラスファイルを読み込めばよいかを、指定するためのものである。

更に、ホストバンドルのクラスローダによって、フラグメントバンドル内の全てのクラスとリソースがロードされる。ここで、「クラスローダ」とは、クラスのロードやリソースの検索を担当するオブジェクトであり、全てのクラスはクラスローダによってＪＡＶＡ（登録商標）ＶＭにロードされアプリとして利用可能となる。このホストバンドルのクラスローダのロードの実行は、ホストバンドル起動時に行われるため、必ずホストバンドルを一度停止し、クラスパスを追加したうえでロードする必要がある。よって、ホストバンドルが停止していないときは、インストールに失敗する。フラグメントバンドルがインストールされた後は、ホストバンドルの一部として利用可能となる。

図４に示す例では、フラグメントバンドルとして日本語リソース４０１、中国語リソース４０２が本体であるホストバンドル４００にインストールされる。その後、ホストバンドル４００が、これらの日本語、中国語リソースを利用して、言語リソースの切り替えが可能となる。つまり、ホストバンドルのＵＩ上の表示は英語であるが、ホストバンドル上でリソースを切替えることで、日本語表示や中国語表示にするようにホストバンドルを作ることが可能である。

リソースとしては、ここで示したような言語リソースだけでなくて、イメージリソースの切替えも可能である。よって、標準では英語表示のイメージを利用していたが、前記ホストバンドルを上でリソースを切替ることで、日本語、または中国語表示のイメージを指定することが可能である。このような目的のフラグメントバンドルをリソース用フラグメントバンドルと呼ぶ。

更に、このようなリソースの追加だけでなく、ホストアプリの機能を拡張することも可能である。例えば、標準機能として提供されたＵＩを、フラグメントバンドルを追加することで、よりリッチなＵＩになるように作ることが可能である。このような目的のフラグメントバンドルを機能拡張用フラグメントバンドルと呼ぶ。

更に、ホストバンドルのある機能に不具合があった場合、その不具合を修正するクラスファイルをフラグメントバンドルで提供することで、ホストバンドルの修正パッチとして機能させることも可能である。このような目的のフラグメントを修正パッチ用フラグメントバンドルと呼ぶ。

なお、フラグメントバンドルのアンインストールも同様にホストバンドルのクラスパスにフラグメントバンドル自身のクラスパスの削除を行い、更に、ホストバンドルのクラスローダによって、再度ホストバンドルに必要なクラスをロードする必要がある。そのため、同様にフラグメントバンドルのアンインストールは、必ずホストバンドルが停止した状態で行う必要がある。

図５は、アプリ管理部２０７が管理する、一般アプリの管理画面５００とインストール画面５２０を示す。本画面はＰＣ３００上に表示されるが、Ｗｅｂ画面を表示できるのであれば、画像形成装置１３０の操作部１１８が表示してもよい。ここでは、一般アプリの管理画面で説明するが、ログインアプリの管理画面についても同様の画面となる。まず、一般アプリの管理画面５００から説明する。

アプリケーション名５０１には、管理されている一般アプリ名が表示される。この例の場合、アプリケーションＡ５０７とアプリケーションＢ５１０の２つが管理されている。更に、このアプリケーションＡをホストバンドルとして、フラグメントバンドルＡ５０８、フラグメントバンドルＢ５０９が管理されている。この場合、そのホストバンドルに紐づいていることがわかるように、アプリケーションＡ５０７と関連付けて表示される。

インストール日５０２は、各アプリがインストールされた日付である。アプリケーションＩＤ５０３は、各アプリに一意に割り振られたアプリケーションＩＤを表示している。状態５０４は、各アプリの状態を示している。アプリが開始中であれば開始、停止中であれば停止と表示される。開始／停止ボタン５０５は、アプリの開始停止を切り替える指示ボタンである。開始状態のアプリの場合、停止ボタンと表示され、停止状態のアプリの場合、開始ボタンと表示される。開始状態のアプリ（本例では、「アプリケーションＡ５０７」）の停止ボタン５０５を押下すると、その状態５０４は停止に変更される。一方、停止状態のアプリ（本例では、「アプリケーションＢ５１０」）の開始ボタン５０５を押下すると、その状態５０４は開始に変更される。アンインストールボタン５０６は、各アプリをアンインストールする指示ボタンである。

フラグメントバンドルのアンインストールはフラグメントバンドルのみが対象となる。例えば、フラグメントバンドルＡのアンインストールボタン５１１が押下されると、フラウメントバンドルＡだけがアンインストールされる。一方、ホストバンドルである、アプリケーションＡ５０７のアンインストールボタン５０６を押下時は、全てのフラグメントバンドルがアンインストールされる。ここでは、アプリケーションＡ５０７に紐づいたフラグメントバンドルＡ５０８とフラグメントバンドルＢ５０９が同時にアンインストールされる。

次に、インストール画面５２０について説明する。参照ボタン５２３は、ファイルパスを選択する画面を表示する。その画面でアプリファイルを指定すると、アプリケーションファイルのパス５２１にアプリファイルへのパスが入力される。アプリは、セキュリティやビジネス上の観点からインストール処理において、アプリを復号するためのライセンスファイルが必要となる場合がある。その場合、ユーザが参照ボタン５２４を押下すると、ファイルパスを選択する画面が表示される。ユーザがアプリ指定と同様にライセンスファイルを指定すると、ライセンスファイルのパス５２２にライセンスファイルへのパスが入力される。ユーザがインストールボタン５２５を押下すると、アプリケーションファイルのパス５２１で指定したアプリのインストールが開始される。

図６は、ホストバンドル４００におけるマニフェストファイル６００を示した図である。マニフェストファイルには、バージョンや、ｊａｒファイルのプロパティ値が記述される。また、マニフェストファイルには、マニフェスト項目と該項目に対する値が記述される。フラグメント個数の上限値（Ｆｒａｇｍｅｎｔ−ＭａｘＣｏｕｎｔ）６０１は、マニフェスト項目の中の一つであり、そのホストバンドルにインストール可能なフラグメントバンドルの個数の上限値（以降フラグメント上限値）を意味する。この例では、フラグメント上限値１が指定されている。よって、ホストバンドルにインストール可能なフラグメントバンドルは１以下、即ち１個のみとなる。上限値６０１が３であれば、３個のフラグメントバンドルがインストール可能ということになる。なお、マニフェストに記載するフラグメント上限値は、記載した数未満で運用する形式であっても良い。例えば、上限値６０１が３であれば、２個のフラグメントバンドルがインストール可能と言うことになる。この形式の注意点としては、上限値６０１に１という数字を記載した場合、フラグメントバンドルが１個もインストールできないことになると言う点である。この点を考慮した運用が必要となる。また、特別な値として＊が指定されている場合、上限値に制限がない状態を示す。マニフェスト項目は、ホストバンドルにしか意味がないため、ホストバンドルでない通常アプリ、及びフラグメントバンドルのマニフェストファイルには記述されることはない。

図７は、ＯＳＧｉ２０６によるアプリとマニフェスト値のメモリ上での管理状態７０８の一例を示す。まず、画像形成装置１３０にインストールされＯＳＧｉ２０６によって管理されているアプリの全体像を説明する。この例では、ホストバンドルである一般アプリＡ７００のマニフェストには、フラグメント上限値７０１として２が記述されている。また、フラグメントバンドルであるフラグメントＸ７０２、及びフラグメントＹ７０３が一般アプリＡ７００にインストールされている。

同様に、ホストバンドルである一般アプリＢ７０４のマニフェストには、フラグメント上限値７０５として１が記述されている。また、フラグメントバンドルであるフラグメントＺ７０６が一般アプリＢ７０４にインストールされている。更に、ホストバンドルでもフラグメントバンドルでもない通常アプリである一般アプリＣ７０７がインストールされている。

ＯＳＧｉ２０６は、管理状態７０８で示すように、アプリがホストバンドルであるのかどうか、及びそのアプリのマニフェストに記述されたフラグメント上限値をＲＯＭ１０２、またはＨＤＤ１０４などのメモリ上に保持している。また、ＯＳＧｉ２０６は、アプリがホストバンドルである場合、アプリに紐づいているフラグメントとの関連性をもメモリ上に保持している。これらは、対象とするアプリ名と、マニフェスト項目値などをキーとし、キーを指定することでそれに紐づいた値を取得できる。対象とするアプリ名、及びその状態は、ＯＳＧｉの管理情報から取得可能である。

インストール制御部２０８は、ＯＳＧｉ２０６に問い合わせることにより、そのホストバンドルとフラグメントバンドルの関連性、フラグメント上限値、フラグメントバンドルの数などを取得することが可能となる。取得方法としては、この例でいうと、一般アプリＡとホストバンドルをキーと指定することで、一般アプリＡがホストバンドルか否かを示す情報が取得可能である。また、一般アプリＡとフラグメント上限値をキーとして指定することで、上限値２を取得可能である。一般アプリＡとフラグメントバンドルをキーとして指定することで、一般アプリＡに紐づくフラグメントＸとフラグメントＹ、及びその数が２である情報を取得可能である。

（実施例１）
本実施形態では、一般アプリに対するフラグメントバンドルのインストールにおける上限値制御の実施例を示す。なお本実施例１は、上述の課題１を解決する例となる。

図８は、課題１を説明するブロック図である。ホストバンドルである一般アプリＡ８００のマニフェストには、フラグメント上限値８０１として１が記述されている。また、フラグメントバンドルであるフラグメントＸ８０２がインストールされている。このときのＯＳＧｉ２０６のメモリ上での管理状態を８０４に示す。

この状態で一般アプリＡ８００をホストバンドルとしているフラグメントバンドルであるフラグメントＹ８０３をインストールすることを考える。インストール制御部２０８は、ＯＳＧｉ２０６に一般アプリＡ８００のフラグメント上限値を問い合わせる。この場合、フラグメント上限値として１が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在の一般アプリＡ８００のフラグメント数を問い合わせる。この場合、フラグメント数として１が取得される。この結果、これからインストールしようとしているフラグメントＹ８０３をインストールするとフラグメント上限値を超えてしまうために、インストール制御部２０８は、フラグメントＹ８０３のインストールを許可しない。

図９は、図８で示した状況における、インストール制御部２０８のフラグメントバンドルインストール時の制御を示すフローチャートである。インストール制御部２０８は、アプリ管理部２０７からの指示によって、フラグメントバンドルのインストール処理を開始する。Ｓ９００において、インストール制御部２０８がインストールを開始する。

Ｓ９０１において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルのフラグメント上限値（ＦＭＣ）を取得する。ここでＦＭＣは、インストール対象のホストバンドルである一般アプリＡとフラグメント上限値をキーとして取得される。Ｓ９０２において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルにインストール済みのフラグメント数（ＦＣ）を取得する。ここでＦＣは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドルをキーとして取得される。

Ｓ９０３において、インストール制御部２０８は、ＦＭＣ＞ＦＣ、あるいは、ＦＭＣの値が＊を満たすかを判定する。例えば、フラグメント上限値が２であり、インストール対象のホストバンドルに追加されているフラグメント数が１であれば、判定はＹＥＳとなる。判定がＹＥＳの場合、インストール制御部２０８はＳ９０４に処理を進め、フラグメントバンドルのインストールを許可する。一方、Ｓ９０３における判定がＮＯの場合、Ｓ９０５に処理を進め、フラグメントバンドルのインストールを許可しない。Ｓ９０６において、インストール制御部２０８は判断フローを終了する。

以上、本実施例１にて示したように、マニフェストに記述されているフラグメントバンドルの数が上限数未満の場合にインストールを実行するように制御することが可能となる。なお、Ｓ９０３における判定処理は、インストール対象のホストバンドルに追加されているフラグメント数がフラグメント上限値未満であればフラグメントバンドルがインストールされる形態である。しかし、以下の判定処理の形態が代替処理として適用されてよい。つまり、ホストバンドルに追加予定のフラグメントの数がフラグメント上限値未満または以下であればフラグメントバンドルがインストールされる。従って、Ｓ９０３の判定処理において、ホストバンドルを拡張するためにインストールされるフラグメントバンドルの数（ＦＣ）は、ホストバンドルに既に紐付いているフラグメントの数であってもよく、追加予定のフラグメントの数であってもよい。そして、いずれかのフラグメントの数がホストバンドルが保持可能な拡張アプリケーションの上限数未満または以下の場合にインストールが実行される。また、追加予定のフラグメントの数を基準として判定処理を行う場合、Ｓ９０３の処理においてＦＭＣ−ＦＣ（既に紐付いているフラグメントの数）＞ＦＣ（追加予定のフラグメントの数）を満たすか否かを判定すればよい。

（実施例２）
本実施形態では、実施例１で示した状況において、ホストバンドルが上書きインストールされるときの実施例を示す。なお本実施例２は、上述の課題２を解決する例となる。

図１０は、課題２を説明するブロック図である。ホストバンドルである一般アプリＡ（Ｖ１）１０００は、フラグメント上限値１００１として２がマニフェストに記述されている。また、フラグメントバンドルであるフラグメントＸ１００２、及び、フラグメントＹ１００３がインストールされている。このときのＯＳＧｉ２０６のメモリ上での管理状態を１００６に示す。

この状態で一般アプリＡ（Ｖ１）１０００のバージョンアップ版である、バージョンアップ用ホストアプリケーション（一般アプリＡ（Ｖ２）１０４）を上書きインストールすることを考える。この一般アプリＡ（Ｖ２）１１０４について、マニフェストには、フラグメント上限値１００５として１が記述されている。インストール制御部２０８は、インストールしようとしている一般アプリＡ（Ｖ２）１００４のフラグメント上限値を、直接マニフェストを参照することにより取得する。この場合、フラグメント上限値として１が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在の一般アプリＡ（Ｖ１）１０００のフラグメント数を問い合わせる。この場合、フラグメント数として２が取得される。この結果、これからインストールしようとしている一般アプリＡ（Ｖ２）１００４を上書きインストールすると、フラグメント上限値１００５が、現状紐づいているフラグメント数に足りないことになる。そのために、インストール制御部２０８は、一般アプリＡ（Ｖ２）１００４のインストールを許可しない。

図１１は、図１０で示した状況における、インストール制御部２０８のホストバンドルを上書きインストールする時の制御を示すフローチャートである。インストール制御部２０８は、アプリ管理部２０７からの指示によって、ホストバンドルの上書きインストール処理を開始する。

Ｓ１１００において、インストール制御部２０８がインストールを開始する。Ｓ１１０１において、インストール制御部２０８は、上書きインストールするホストバンドルのマニフェストからフラグメント上限値（ＦＭＣ）を取得する。ここでＦＭＣは、インストール対象のホストバンドルである一般アプリＡとフラグメント上限値をキーとして取得される。

Ｓ１１０２において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルに追加されているフラグメント数（ＦＣ）を取得する。ここでＦＣは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドルをキーとして取得される。

Ｓ１１０３において、ＦＭＣ＞＝ＦＣ、あるいは、ＦＭＣの値が＊を満たすかを判定する。その判定がＹＥＳの場合、インストール制御部２０８はＳ１１０４に処理を進め、フラグメントバンドルのインストールを許可する。一方、Ｓ１１０３における判定がＮＯの場合、Ｓ１１０５に処理を進め、ホストバンドルの上書きインストールを許可しない。Ｓ１１０６において、インストール制御部２０８は判断フローを終了する。

以上、本実施例２にて示したようにホストバンドルの上書きインストールにおいても、フラグメント上限値とホストバンドルに追加されているフラグメントバンドル数との間の整合性を保つことが可能となる。

（実施例３）
本実施形態では、実施例１で示した状況において、ホストバンドルがログインアプリであり、かつ後述する予約インストール／アンインストールされているときの実施例を示す。なお本実施例３は、上述の課題３を解決する例となる。

まず、ログインアプリの予約インストール／アンインストールについて説明する。ログインアプリ２０９は、ログイン中に任意のアプリから任意のタイミングでログイン情報の問い合わせの可能性がある為、他のログインアプリに切り替える以外に停止することができない。一方で、図４で示したように、フラグメントバンドルのインストール／アンインストールは、ホストバンドルを停止させておく必要がある。

これらの理由により、ホストバンドルが開始され実行中のログインアプリであり、そのログインアプリのフラグメントバンドルをインストールする場合、以下の方法が考えられる。つまり、インストール制御部２０８は、インストールしたフラグメントバンドルとインストールされたことを示す指示ファイルをＲＯＭ１０２、またはＨＤＤ１０４などのストレージに仮保存する。そして、再起動時にインストール制御部２０８がその指示ファイルに従って、フラグメントバンドルをインストールするという方法が考えられる。これを、ログインアプリのフラグメントバンドルの予約インストールと呼ぶ。予約インストールが実施されても、デバイスが再起動されるまで、そのフラグメントは未インストール状態である。

同様の理由で、インストール制御部２０８は、開始中のログインアプリに対して、フラグメントバンドルをアンインストールするときに、アンインストールされたことを示す指示ファイルをストレージに保存する。そして、再起動時にインストール制御部２０８がその指示ファイルに従って、フラグメントバンドルをアンインストールするという方法が考えられる。これを、ログインアプリのフラグメントバンドルの予約アンインストールと呼ぶ。予約アンインストールが実施されても、デバイスが再起動されるまで、そのフラグメントはインストール済みの状態である。

図１２は、課題３を説明するブロック図である。ホストバンドルであるログインアプリＡ１２００のマニフェストには、フラグメント上限値１２０１として１が記述されている。このログインアプリＡ１２００は開始中である。また、フラグメントバンドルであるフラグメントＸ１２０２がインストールされている。この状態で、フラグメントＸ１２０２がアンインストールされたとする。ただし、ログインアプリＡ１２００が開始中であるため、アンインストール対象、つまり予約アンインストールとなる。よって、フラグメントＸ１２０２は、再起動後にアンインストールされることになる。このときのＯＳＧｉ２０６のメモリ上での管理状態を１２０４に示す。

この状態でログインアプリＡ１２００をホストバンドルとしているフラグメントバンドルであるフラグメントＹ１２０３をインストールすることを考える。ただし、ログインアプリＡ１２００が開始中であるため、予約インストールとなる。インストール制御部２０８は、ＯＳＧｉ２０６にログインアプリＡ１２００のフラグメント上限値を問い合わせる。

この場合、フラグメント上限値として１が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在のログインアプリＡ１２００のフラグメント数を問い合わせる。この場合、フラグメント数として１が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在のログインアプリＡ１２００で予約アンインストールされているフラグメント数を問い合わせる。

この場合、予約アンインストールされているフラグメント数として１が取得される。この結果、これからインストールしようとしているフラグメントＹ１２０３をインストールしても予約アンインストールされるフラグメントＸ１２０２のことを考慮すると、フラグメント上限値１２０１を超えない。従って、インストール制御部２０８は、フラグメントＹ１２０３の予約インストールを許可する。

図１３は、図１２で示した状況における、インストール制御部２０８のフラグメントバンドルインストール時の制御を示すフローチャートである。インストール制御部２０８は、アプリ管理部２０７からの指示によって、フラグメントバンドルのインストール処理を開始する。

Ｓ１３００において、インストール制御部２０８がインストールを開始する。Ｓ１３０１において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルのフラグメント上限値（ＦＭＣ）を取得する。ここでＦＭＣは、インストール対象のホストバンドルであるログインアプリＡとフラグメント上限値をキーとして取得される。

Ｓ１３０２において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルに追加されているフラグメント数（ＦＣ）を取得する。ここでＦＣは、インストール対象のホストバンドルであるログインアプリＡとフラグメントバンドルをキーとして取得される。

Ｓ１３０３において、インストール制御部２０８は、フラグメントバンドルの対象ホストバンドルがログインアプリであり、かつ、開始中であるかを判断する。その判定がＮＯであれば、インストール制御部２０８はＳ１３０５に処理を進める。これ以降は、実施例１と同じである。Ｓ１３０５において、ＦＭＣ＞＝ＦＣ、あるいは、ＦＭＣの値が＊を満たすかを判定する。その判定がＹＥＳの場合、インストール制御部２０８はＳ１３０８に処理を進める。Ｓ１３０５における判定がＮＯの場合、Ｓ１３０９に処理を進める。

Ｓ１３０３における判定がＹＥＳであれば、インストール制御部２０８はＳ１３０４に処理を進める。更に、インストール制御部２０８は、ＯＳＧｉから対象ホストバンドルに追加されているフラグメントバンドルが予約アンインストールされているかどうかを判断する。その判定がＮＯである場合、インストール制御部２０８はＳ１３０５に処理を進める。Ｓ１３０４における判定がＹＥＳの場合、Ｓ１３０６に処理を進める。Ｓ１３０６において、インストール制御部２０８はＯＳＧｉから予約アンインストールされているフラグメントバンドル数（ＵＦＣ）を取得し、Ｓ１３０７に処理を進める。ここでＵＦＣの数は、インストール対象のホストバンドルであるログインアプリＡとフラグメントバンドルをキーとして取得されたフラグメントＸが、予約アンインストール状態であることに基づいて取得される。

Ｓ１３０７において、インストール制御部２０８は、ＦＭＣ＞＝ＦＣ―ＵＦＣ、あるいは、ＦＭＣの値が＊を満たすかを判定する。その判定がＹＥＳの場合、インストール制御部２０８はＳ１３０８に処理を進め、フラグメントバンドルのインストールを許可する。Ｓ１３０７における判定がＮＯの場合、Ｓ１３０９に処理を進め、フラグメントバンドルのインストールを許可しない。Ｓ１３１０において、インストール制御部２０８は判断フローを終了する。

以上、本実施例３にて示したように、予約インストール／アンインストールを考慮した上で、フラグメントバンドルの上限数を制御したインストールが可能となる。なお、上述の処理は、一つ一つフラグメントバンドルを追加インストールすることを想定している。従って、追加しようとしているフラグメントバンドルが複数存在する場合は、フラグメントバンドル毎に図１３に示す処理が実行されることとなる。これに代えて、複数のフラグメントバンドルのインストール許可／不許可が同時に判定されてもよい。その場合、Ｓ１３０７の処理では、ＦＭＣ＞＝ＦＣ（ホストバンドルに紐付いているフラグメントの数）―ＵＦＣ＋インストール対象のフラグメントの数（ＦＣ）、あるいは、ＦＭＣの値が＊を満たすかを判定すればよい。

（実施例４）
本実施形態では、フラグメントバンドルの用途に応じて上限値を変えたい場合のインストール制御の実施例を示す。なお本実施例４は、上述の課題４を解決する例となる。

フラグメントバンドルの用途としては、図４で説明したように、リソース用、機能拡張用、修正パッチ用などのアプリが考えられる。そこで、それぞれの用途に応じて、アプリの種類毎に個数制限を変えたいということが考えられる。例えば、お試し版アプリとして、言語は５個まで、機能拡張は１個までと制限付きだが、修正パッチ用アプリとしては無制限に許可するサービス提供の形態が考えられる。

図１４は、ホストバンドル４００におけるマニフェストファイル１４００と、フラグメントバンドル４０１のマニフェストファイル１４０２を示した図である。マニフェストファイル１４００について説明する。マニフェスト項目１４０１として、リソース用のフラグメントバンドルの個数の上限値（Ｆｒａｇｍｅｎｔ−ＭａｘＣｏｕｎｔ−Ｒｅｓｏｕｒｅｃｅ）が記述されている。また、機能拡張用のフラグメントバンドルの個数の上限値（Ｆｒａｇｍｅｎｔ−ＭａｘＣｏｕｎｔ−Ｆｕｎｃｔｉｏｎ）が記述されている。また、修正パッチ用のフラグメントバンドルの個数の上限値（Ｆｒａｇｍｅｎｔ−ＭａｘＣｏｕｎｔ−Ｐａｔｃｈ）も記述されている。それぞれの上限値は、５、１、＊（無制限）が指定されている。このマニフェスト項目は、ホストバンドルでしか意味がないため、ホストバンドルでない通常アプリ、及びフラグメントバンドルでは記述されることはない。

次にマニフェストファイル１４０２について説明する。マニフェスト項目１４０３として、フラグメントバンドルの用途に応じたフラグメントバンドルタイプ（Ｆｒａｇｍｅｎｔ−Ｔｙｐｅ）が記述される。タイプとしては、リソース用として、Ｒｅｓｏｕｒｃｅ、機能拡張用として、Ｆｕｎｃｔｉｏｎ、修正パッチ用として、Ｐａｔｃｈが指定される。これらは、一つのフラグメントバンドルの中で一つだけ指定されてもよく、複数指定してもよい。

図１５は、課題４を説明するブロック図である。ホストバンドルである一般アプリＡ１５００のマニフェストファイル１５０１には、リソース用の上限値として５、機能拡張用の上限値として１、修正パッチ用の上限値として＊が記述されている。また、一般アプリＡ１５００には、フラグメントバンドルであるフラグメントＸ１５０２がインストールされている。フラグメントＸ１５０２のマニフェストファイル１５０３には、フラグメントバンドルタイプとして、Ｆｕｎｃｔｉｏｎ（機能拡張用）が記述されている。このときのＯＳＧｉ２０６のメモリ上での管理状態を１５０６に示す。

この状態でログインアプリＡ１５００をホストバンドルとしているフラグメントバンドルであるフラグメントＹ１５０４をインストールすることを考える。フラグメントＹ１５０４のマニフェストファイル１５０５には、フラグメントバンドルタイプとして、Ｒｅｓｏｕｒｃｅ（リソース用）／Ｆｕｎｃｔｉｏｎ（機能拡張用）が記述されている。インストール制御部２０８は、ＯＳＧｉ２０６に一般アプリＡ１５００のフラグメント上限値を用途ごとに問い合わせる。

この場合、フラグメント上限値としてリソース用として５、機能拡張用として１、修正パッチ用として無制限が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在の一般アプリＡ１５００の用途ごとのフラグメント数を問い合わせる。この場合、リソース用フラグメント数として０、機能拡張用フラグメント数として１、修正パッチ用フラグメント数として０が取得される。この結果、これからインストールしようとしているフラグメントＹ１５０４は、リソース用、かつ機能拡張用タイプであるため、これをインストールすると、機能拡張用のフラグメント上限数を超えてしまう。そのため、インストール制御部２０８は、フラグメントＹ１５０４のインストールを許可しない。

図１６は、図１５で示した状況における、インストール制御部２０８のフラグメントバンドルインストール時の制御を示すフローチャートである。インストール制御部２０８は、アプリ管理部２０７からの指示によって、フラグメントバンドルのインストール処理を開始する。

Ｓ１６００において、インストール制御部２０８がインストールを開始する。Ｓ１６０１において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルのタイプ毎のフラグメント上限値を取得する。リソースタイプの上限値をＦＭＣＲとする。機能拡張タイプの上限値をＦＭＣＦとする。修正パッチタイプの上限値をＦＭＣＰとする。ここでＦＭＣＲは、インストール対象のホストバンドルである一般アプリＡとフラグメント上限値（Ｒｅｓｏｕｒｃｅ）をキーとして取得される。ここでＦＭＣＦは、インストール対象のホストバンドルである一般アプリＡとフラグメント上限値（Ｆｕｎｃｔｉｏｎ）をキーとして取得される。ここでＦＭＣＰは、インストール対象のホストバンドルである一般アプリＡとフラグメント上限値（Ｐａｔｃｈ）をキーとして取得される。

Ｓ１６０２において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルに追加されているタイプ毎のフラグメント数を取得する。まず、Ｓ１６０３において、リソースタイプのフラグメント数（ＦＣＲ）を取得する。ここでＦＣＲは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドル、更にＲｅｓｏｕｒｃｅをキーとして取得される。

Ｓ１６０４において、機能拡張タイプのフラグメント数（ＦＣＦ）を取得する。ここでＦＣＦは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドル、更にＦｕｎｃｔｉｏｎをキーとして取得される。

Ｓ１６０５において、修正パッチタイプのフラグメント数（ＦＣＰ）を取得する。ここでＦＣＰは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドル、更にＰａｔｃｈをキーとして取得される。

Ｓ１６０６において、インストール制御部２０８は、（ＦＭＣＲ＞ＦＣＲ ｏｒ ＦＭＣＲ＝＊）かつ（ＦＭＣＦ＞ＦＣＦ ｏｒ ＦＭＣＦ＝※）かつ（ＦＭＣＰ＞ＦＣＰ ｏｒ ＦＭＣＰ＝＊）を満たすかどうかを判定する。その判定がＹＥＳの場合、インストール制御部２０８はＳ１６０７に処理を進め、フラグメントバンドルのインストールを許可する。一方、Ｓ１６０６における判定がＮＯの場合、Ｓ１６０８に処理を進め、フラグメントバンドルのインストールを許可しない。Ｓ１６０９において、インストール制御部の判断フローを終了する。

以上、本実施例４にて示したように、用途ごとのフラグメントバンドルの上限数を制御したインストールが可能となる。なお、実施例１で説明したように、Ｓ１６０６の判定処理において用いられるフラグメントバンドルの数（ＦＣ）は、ホストバンドルに既に紐付いているフラグメントの数であってもよく、追加予定のフラグメントの数であってもよい。そして、いずれかのフラグメントの数が各ホストバンドルが保持可能な種類毎の拡張アプリケーションの上限数未満または以下の場合にインストールが実行される。

（実施例５）
本実施形態では、実施例１〜４のようなホストバンドル毎の上限値指定をするのではなく、デバイス全体でのリソースに応じてデバイス全体の設定として上限値を指定したい場合のインストール制御の実施例を示す。なお本実施例５は、前述の課題５を解決する例となる。

図１７は、課題５を説明するブロック図である。ホストバンドルである一般アプリＡ１７００には、フラグメントバンドルであるフラグメントＸ１７０１、及び、フラグメントＹ１７０２がインストールされている。更に、ホストバンドルである一般アプリＢ１７０３には、フラグメントバンドルであるフラグメントＺ１７０４がインストールされている。

また、デバイスのリソース量に応じて、デバイス全体のフラグメント数の上限値、及び１バンドルあたりのフラグメントバンドル数の値が、デバイスの設定値データベース１７０７に保持されている。このデータベースに保持されている値は、デバイス起動時にＯＳＧｉによって読み込まれ、メモリ上に保持される。このときのＯＳＧｉ２０６のメモリ上での管理状態を１７０８に示す。この値は、デバイス全体のフラグメント上限値、及び１バンドルあたりのフラグメントバンドル数をキーとして取得可能である。

この状態で、一般アプリＡ１７００をインストール先としているフラグメントバンドルであるフラグメントＵ１７０５をインストールすることを考える。インストール制御部２０８は、ＯＳＧｉ２０６にデバイス全体のフラグメント上限値を問い合わせる。この場合、フラグメント上限値として４が取得される。インストール制御部２０８は、ＯＳＧｉ２０６に１バンドルあたりのフラグメント上限値を問い合わせる。この場合、フラグメント上限値として２が取得される。

一方、インストール制御部２０８は、ＯＳＧｉ２０６にデバイス全体のフラグメント数を問い合わせる。この場合、全体のフラグメント数として３が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在の一般アプリＡ１７００のフラグメント数を問い合わせる。

この場合、フラグメント数として２が取得される。この結果、これからインストールしようとしているフラグメントＵ１７０５をインストールした場合、デバイス全体のフラグメントバンドル数は４となり、デバイス全体のフラグメント上限値４を超えない。しかし、一般アプリＡ１７００に追加されるフラグメントバンドル数が３となり、１バンドルあたりのフラグメント上限値２を超えてしまうため、インストール制御部２０８は、フラグメントＵ１７０５のインストールを許可しない。

更に、この状態で一般アプリＢ１７０３をホストバンドルとしているフラグメントバンドルであるフラグメントＶ１７０６をインストールすることを考える。一方、インストール制御部２０８は、ＯＳＧｉ２０６にデバイス全体のフラグメント数を問い合わせる。この場合、全体のフラグメント数として３が取得される。また、インストール制御部２０８は、ＯＳＧｉ２０６に現在の一般アプリＢ１７０３のフラグメント数を問い合わせる。この場合、フラグメント数として１が取得される。

この結果、これからインストールしようとしているフラグメントＶ１７０６をインストールした場合、デバイス全体のフラグメント数は４となり、デバイス全体のフラグメント上限値４を超えない。また、一般アプリＢ１７０３に追加されるフラグメントバンドル数も２となり、１バンドルあたりのフラグメント上限値２を超えない。よって、インストール制御部２０８は、フラグメントＶ１７０６のインストールを許可する。

図１８は、図８で示した状況における、インストール制御部２０８のフラグメントバンドルインストール時の制御を示すフローチャートである。インストール制御部２０８は、アプリ管理部２０７からの指示によって、フラグメントバンドルのインストール処理を開始する。

Ｓ１８００において、インストール制御部２０８がインストールを開始する。Ｓ１８０１において、インストール制御部２０８は、ＯＳＧｉ２０６からデバイス全体でのフラグメント上限値（ＦＭＣＴ）を取得する。ここでＦＭＣＴは、デバイス全体のフラグメント上限値をキーとして取得される。

Ｓ１８０２において、インストール制御部２０８は、ＯＳＧｉ２０６から１バンドルあたりのフラグメント上限値（ＦＭＰＢ）を取得する。ＦＭＰＢは、１バンドルあたりのフラグメントバンドル数がキーとして取得される。Ｓ１８０３において、インストール制御部２０８は、ＯＳＧｉ２０６からデバイス全体のフラグメント数（ＦＣＴ）を取得する。取得されるＦＣＴは、デバイス全体のホストバンドルである一般アプリＡと一般アプリＢ、及びフラグメント上限値がキーとして取得される。

Ｓ１８０４において、インストール制御部２０８は、ＯＳＧｉ２０６からインストール対象のホストバンドルに追加されているフラグメント数（ＦＣ）を取得する。ＦＣは、インストール対象のホストバンドルである一般アプリＡとフラグメントバンドルがキーとして取得される。

Ｓ１８０５において、インストール制御部２０８は、ＦＭＣＴ＞ＦＣＴ かつ ＦＭＰＢ＞ＦＣを満たすかどうかを判定する。その判定がＹＥＳの場合、インストール制御部２０８はＳ１８０６に処理を進め、フラグメントバンドルのインストールを許可する。一方、Ｓ１８０５における判定がＮＯの場合、Ｓ１８０７に処理を進め、フラグメントバンドルのインストールを許可しない。Ｓ１８０８において、インストール制御部２０８は判断フローを終了する。

以上、本実施例５にて示したように、デバイス全体の設定としてフラグメントバンドルの上限数を制御したインストールが可能となる。なお、実施例１で説明したように、Ｓ１８０５の判定処理において用いられるフラグメントバンドルの数（ＦＣ）は、ホストバンドルに既に紐付いているフラグメントの数であってもよく、追加予定のフラグメントの数であってもよい。そして、いずれかのフラグメントの数が各ホストバンドルが保持可能な拡張アプリケーションの上限数未満または以下の場合にインストールが実行される。

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

Claims (8)

1. 特定のサービスを提供するアプリケーションを当該アプリケーションのマニフェストを基に管理するフレームワークを具備した情報処理装置であって、
   ホストアプリケーションを拡張する拡張アプリケーションをインストールする際に、前記ホストアプリケーションを拡張するためにインストールされる前記拡張アプリケーションの数が、前記ホストアプリケーションのマニフェストに記載されている当該ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満または以下の場合にインストールを実行するインストール手段を備える
   ことを特徴とする情報処理装置。
2. 前記インストール手段は、前記ホストアプリケーションをバージョンアップする際に、当該ホストアプリケーションにインストール済みの前記拡張アプリケーションの数が、バージョンアップ用ホストアプリケーションのマニフェストに記載されている当該バージョンアップ用ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満または以下の場合にバージョンアップを実行する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記インストール手段は、前記拡張アプリケーションをインストールする際に、前記ホストアプリケーションが実行中か否かを判断し、前記ホストアプリケーションが実行中であり、かつ、前記ホストアプリケーションにインストール済みの前記拡張アプリケーションの内いずれか一つの拡張アプリケーションが再起動時にアンインストールされる場合に、当該ホストアプリケーションにインストール済みの前記拡張アプリケーションの数からアンインストール対象の拡張アプリケーションを差し引いた数が、前記ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満または以下の場合、再起動時にインストールを実行する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記マニフェストには、前記拡張アプリケーションの種類毎に当該ホストアプリケーションが保持可能な拡張アプリケーションの上限数が記載されており、
   前記インストール手段は、前記拡張アプリケーションをインストールする際に当該拡張アプリケーションの種類を特定し、前記ホストアプリケーションにインストール済みであって、特定された種類の拡張アプリケーションの数が当該特定された種類の拡張アプリケーションの上限数未満または以下の場合にインストールを実行する
   ことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記インストール手段は、前記拡張アプリケーションをインストールする際に、自装置にインストール済みの前記拡張アプリケーションの数が、前記自装置が保持可能な拡張アプリケーションの上限数未満であり、かつ前記拡張アプリケーションのインストール先のホストアプリケーションにインストール済みの前記拡張アプリケーションの数が、各ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満または以下である場合にインストールを実行する
   ことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
6. 前記各アプリケーションのプラットフォームは、Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍである
   ことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 特定のサービスを提供するアプリケーションを当該アプリケーションのマニフェストを基に管理するフレームワークを具備した情報処理装置の制御方法であって、
   ホストアプリケーションを拡張する拡張アプリケーションをインストールする際に、前記ホストアプリケーションを拡張するためにインストールされる前記拡張アプリケーションの数が、前記ホストアプリケーションのマニフェストに記載されている当該ホストアプリケーションが保持可能な拡張アプリケーションの上限数未満または以下の場合にインストールを実行するインストール工程を備える
   ことを特徴とする制御方法。
8. 請求項７に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。

Images