JP6935291B2 - 画像形成装置及びその制御方法 - Google Patents

Description

本発明は、アプリケーションプログラムの管理に関するものである。

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

アプリプラットフォームとしては、組み込み機器向けのＪＡＶＡアプリプラットフォームである、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ）Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（以下、ＯＳＧｉ）がある（非特許文献１）。ＯＳＧｉの仕様には、ホストバンドルとフラグメントバンドルという仕組みがある。ホストバンドルとは、フラグメントバンドルの追加対象としているバンドルを指す。フラグメントバンドルとは、単独では動作せず、ホストバンドルのクラスローダ空間にバンドル自身を追加（アタッチ）する形式のバンドルである。

このフラグメントバンドルを含む各バンドルは、ＪＡＶＡの標準仕様で設けられたパーミッションと呼ばれるセキュリティアクセス権限の仕組みを持つ。このパーミッションは、各バンドル個別に定義することが可能である。

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

ホストバンドルが保持するパーミッション定義ファイルのパーミッションは、セキュリティ上必要最小限に留めておくことが望ましい。一方、フラグメントバンドルの処理に必要なパーミッションは、ホストバンドルのパーミッションに従って処理される。そのため、フラグメントバンドルの処理に必要なパーミッションが不足する可能性がある。フラグメントバンドルの処理に必要なパーミッションが不足する場合、ホストバンドルが保持するパーミッション定義ファイルを都度修正する必要があり、フラグメントバンドルの利便性を損なうものであった。

本発明は、ホストバンドルが保持するパーミッション定義ファイルを修正することなく、フラグメントバンドルの処理に必要なパーミッションを不足させずに実行可能とする技術を提供することを目的とする。

本発明の画像形成装置は、ホストアプリケーションに対応つけられた前記ホストアプリケーションのパーミッションリストを保持する保持手段と、前記ホストアプリケーションに、プラグインアプリケーションを追加する追加手段と、前記プラグインアプリケーションに含まれるパーミッションを、前記ホストアプリケーションのパーミッションリストに追加して更新する更新手段と、前記更新されたパーミッションリストに基づいて、前記ホストアプリケーションおよび前記プラグインアプリケーションにおける処理実行するかを判定する手段を有することを特徴とする。

本発明によれば、ホストバンドルが保持するパーミッション定義ファイルを修正することなく、フラグメントバンドルの処理に必要なパーミッションを不足させずに実行可能とする技術を提供することができる。

画像形成装置のハードウェア構成図 画像形成装置のソフトウェアモジュール階層図 バンドルのインストールする流れを示したブロック図 フラグメントバンドルの概念図 バンドル管理画面、インストール画面のＵＩを示した図 一般的なＪＡＶＡにおけるパーミッションの仕組みについて説明した図 ＯＳＧｉにおけるパーミッションの仕組みについて説明した図 バンドルが抱えるパーミッション定義ファイルについて説明した図 ＯＳＧｉ拡張部がメモリ上で保持するパーミッションリストとパーミッションファイルについて説明した図 バンドルインストール時と画像形成装置の起動時のＯＳＧｉ拡張部のパーミッションに関するフローチャート バンドルから呼び出されたＡＰＩでのパーミッション処理に関するシーケンス図 ＯＳＧｉにおけるホストバンドルとフラグメントバンドルのパーミッションの仕組みについて説明した図 ホストバンドルとフラグメントバンドルのパーミッション定義ファイルについて説明した図 フラグメントバンドルがアタッチされたときに、ホストバンドルが保持するパーミッションリストの変化について説明した図 フラグメントバンドルがホストバンドルへアタッチされるときのＯＳＧｉ拡張部のホストバンドルのパーミッション処理についてのフローチャート フラグメントバンドルがホストバンドルへデタッチされるときのＯＳＧｉ拡張部のホストバンドルへのパーミッション処理についてのフローチャート フラグメントバンドルがデタッチされたときに、ホストバンドルが保持するパーミッションリストの変化について説明した図

以下、本発明を実施するための最良の形態について図面を用いて説明する。

まず、フラグメントバンドルをホストバンドルにアタッチ（追加）するときのＯＳＧｉ拡張部におけるパーミッション処理について述べる。なお、ホストバンドルは、ホストアプリケーション（ホストアプリ）、フラグメントバンドルは、プラグインアプリケーション（プラグインアプリ）と同義である。

図１は、プリント機能やスキャン機能、ネットワーク通信機能などを備える画像形成装置１３０のハードウェア構成図である。

画像形成装置１３０は、スキャナ部１１３やプリンタ部１１４と電気的に接続され、一方でＬＡＮ１１６を介して外部デバイスと接続される。ＣＰＵ１０１は、ＲＯＭ１０２に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御し、またコントローラ内部で行われる各種処理についても統括的に制御する。

ＲＯＭ１０２は読み出し専用の不揮発記憶領域であり、画像形成装置１３０のブートプログラム、ファームウェアなどが格納されている。ＲＡＭ１０３は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ１０３は、記憶した内容を電源ｏｆｆ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源ｏｆｆ後に記憶内容が消去されるＤＲＡＭなどにより構成される。

ＨＤＤ１０４は不揮発記憶領域であり、システムバンドルなどを格納する。図３で説明するインストールするバンドルを含むファームウェアは、ＨＤＤ１０４に格納される。操作部Ｉ／Ｆ１０５は、システムバス１１９と操作部１１８を接続するインタフェース部である。具体的には操作部１１８に表示するデータをシステムバス１１９から受取り表示すると共に、操作部１１８からの入力情報をシステムバス１１９へ出力する。画像形成装置１３０に対するユーザの指示や情報提示は、操作部１１８を介して行う。ネットワークＩ／Ｆ１０６はＬＡＮ１１６、ＷＡＮ１１７及びシステムバス１１９に接続し、外部との情報の入出力を行う。

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

図２は、本発明に関係する画像形成装置１３０のソフトウェアモジュール階層図２００である。

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

次に各ソフトウェアの説明をする。ソフトウェアは、まずオペレーティングシステム（ＯＳ）プラットフォーム２０１を有する。ＵＩ２０２はユーザインタフェースモジュールであり、オペレータが画像形成装置１３０に対する各種操作・設定を行う際に、装置とユーザ操作との仲介を行うモジュールである。このモジュールは、オペレータの操作に従い、各種モジュールに入力情報を転送して処理の依頼、或いはデータの設定変更等を行う。

次に、ＪＡＶＡ側の構成について述べる。

ＪＡＶＡ側のソフトウェアプラットフォームは、ＪａｖａＶＭ２０７のランタイム環境として構成されており、インタプリタとしてのＪａｖａＶＭ２０７、ライブラリ２０８、フレームワーク群２０９で構成される。ライブラリ２０８は、標準のＡＰＩライブラリを含んで構成される。フレームワーク群２０９は、ＯＳＧｉ２１０を含んで構成され、このＯＳＧｉ２１０は、単一のＪａｖａＶＭ２０７に複数のバンドルを動作させる。

ＯＳＧｉでは、ソフトウェアモジュールの管理単位としてバンドルを定義しており、インストール／開始／停止／更新／アンインストールからなるライフサイクルを管理するための仕様を定義している。ここで、バンドルとは、ＪＡＶＡモジュールのことを指し、本発明においては、アプリと同義である。そのため、以後アプリのことをバンドルと表記する。このようなアプリプラットフォームでは、コピー、スキャン、プリント等の組み込み機能をバンドルが提供することができる。

更に、ＯＳＧｉ拡張部２１１は、インテーフェース仕様であるＯＳＧｉ２１０に対する実装部分を担うモジュールである。ＯＳＧｉ拡張部２１１は、ＯＳＧｉ２１０の仕様を満たす範囲で必要に応じて機能を拡張可能であることを示す。このＯＳＧｉ２１０、及びＯＳＧｉ拡張部２１１は、バンドルのライフサイクルの管理やバンドル間通信機能などを提供する。

このＯＳＧｉ２１０上には、複数のシステムバンドル群２１２がある。システムバンドル群２１２としては、複数のバンドルを管理し、新たなバンドルの追加、更新、削除をするためのバンドル管理サービス２１４がある。バンドル管理サービス２１４は、ＰＣからのインストール指示を受信する受け口でもある。インストール指示を受診したバンドル管理サービス２１４は、インストール制御サービス２１３を利用して、バンドルの追加、更新を行う。

更に、システムバンドル群２１２の中には、画像形成装置１３０の認証機能を担う認証バンドル２１５がある。認証バンドル２１５は、ユーザが画像形成装置に認証中に任意のバンドルから任意のタイミングで認証情報の問い合わせがあるため、停止できない特性を持つバンドルである。

一方で、後からインストールするタイプの後入れバンドル群２１７がある。バンドルのインストールについては、図３で示す。後入れバンドル群２１７として、後入れバンドル２１９は、画像形成装置１３０において各種処理をユーザに提供する。例えば、画像の加工や圧縮バンドル、印刷制限などの部門管理を行うバンドルなどがある。各種機能を実現する後入れバンドル２１９は、バンドル管理サービス２１４の管理下で動作する。バンドル管理サービス２１４は、管理下に追加されたバンドルのバージョンを含むバンドル情報、ライセンス情報などを保持している。

図３は、ユーザが、ＰＣ３００から画像形成装置１３０へ、後入れバンドル２１９をインストールする流れを示したブロック図である。

市販された後入れバンドル２１９は、改ざん防止の為、デジタル署名が付与され、そのうえで暗号化されている。また、後入れバンドル２１９は、パーミッション定義ファイル３０１を抱えている。このパーミッション定義ファイル３０１は、後入れバンドル２１９がインストール後に様々な機能を使用する上で利用可能なパーミッションを示す。ここで、パーミッションとは、ＪＡＶＡの標準仕様で設けられたセキュリティアクセス権限の仕組みである。パーミッション定義ファイル３０１は、必要がなければ、保持しなくても構わない。このパーミッションは、通常以下のように、パーミッション名とｎａｍｅとａｃｔｉｏｎという形式で定義される。ｎａｍｅとａｃｔｉｏｎに取りうる値は、パーミッションの種類によって異なる。また、＊を指定することで、ワイルドカード指定が可能である。
（ＸＸＸＰｅｒｍｉｓｓｉｏｎ， “ｎａｍｅ”， “ａｃｔｉｏｎ”）

ＰＣ３００のＷＥＢブラウザにバンドルインストールＵＩ３０２を表示し、このバンドルインストールＵＩ３０２からインストールしたい後入れバンドル２１９を指定し、インストールを行う。バンドルインストールＵＩ３０２で指定されたバンドルを受信したバンドル管理サービス２１４は、それをインストール制御サービス２１３に渡す。バンドルファイルを受信したインストール制御サービス２１３は、受信した後入れバンドル２１９の復号化処理や正当性を示すデジタル署名をもつかの確認処理を行った上で、確認に問題がない場合は、最終的にＯＳＧｉ拡張部２１１にインストールを依頼する。ＯＳＧｉ拡張部２１１は、インストールする際に、バンドルがもつパーミッション管理を行うためのパーミッションリスト３０３を、バンドルごとにメモリ上に作成する。これは、ＪａｖａＶＭ２０７からバンドルが保持しているパーミッションの問い合わせに答えるために、作成される。パーミッションリスト３０３の詳細は、図７で説明する。また、こうしたインストール時だけでなく、画像形成装置の起動時に画像形成装置に含まれる全てのバンドルのパーミッションをパーミッションリスト３０３に読み戻す必要がある。そのため、全てのバンドルのパーミッション情報が含まれたパーミッションファイル３０４を作成する。こうしたパーミッションの管理は、ＯＳＧｉ２１０の規定に含まれる。パーミッションファイル３０４の詳細は、図９で説明する。

図４は、フラグメントバンドルの概念を説明する図である。

ここでは、ホストバンドル４００に対して、言語ローカライズリソースをもつフラグメントバンドル４０１と４０２がアタッチされる例を示している。

ホストバンドルにフラグメントバンドルをアタッチするためには、ＯＳＧｉ２１０の規約上、以下のマニフェスト、及びパーミッション定義ファイルにおいてバンドルパーミッションの指定が必要となる。
■ホストバンドルのマニフェスト４０３
Ｂｕｎｄｌｅ−ＭａｎｉｆｅｓｔＶｅｒｓｉｏｎに、２と指定する。
Ｂｕｎｄｌｅ−ＳｙｍｂｏｌｉｃＮａｍｅには、フレームワーク内で一意な名前を付ける。
■フラグメントバンドルのマニフェスト４０５
Ｂｕｎｄｌｅ−ＭａｎｉｆｅｓｔＶｅｒｓｉｏｎに、２と指定する。
Ｆｒａｇｍｅｎｔ−Ｈｏｓｔには、ホストバンドルのマニフェスト４０３に記載の＜ホストのバンドルシンボリック名＞を指定する。本値が一致することでホストバンドルとフラグメントバンドルが同一バンドルの構成要素であることを示すものとなる。
■ホストバンドルのパーミッション４０４
ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ［バンドルシンボリック名， ＨＯＳＴ］
■フラグメントバンドルのパーミッション４０６
ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ［バンドルシンボリック名， ＦＲＡＧＭＥＮＴ］

上記条件を満足する状態で、フラグメントバンドルをアタッチすると、ＯＳＧｉ２１０がフラグメントバンドルのマニフェスト情報からホストバンドルを特定し、ホストバンドルのクラスパスにフラグメントバンドル自身のクラスパスの追加を行う。ここで「クラスパス」とは、ＪＡＶＡアプリケーションを実行するときに、ＪＡＶＡＶＭがどの場所からクラスファイルを読み込めばよいかを、指定するためのものである。更に、ホストバンドルのクラスローダによって、フラグメントバンドル内の全てのクラスとリソースがロードされる。ここで、「クラスローダ」とは、クラスのロードやリソースの検索を担当するオブジェクトであり、全てのクラスはクラスローダによってＪＡＶＡＶＭにロードされアプリケーションから利用可能となる。このホストバンドルのクラスローダのロードの実行は、ホストバンドル起動時に行われるため、必ずホストバンドルを一度停止し、クラスパスを追加したうえでロードする必要がある。

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

一般的にＯＳＧｉの規定上、フラグメントバンドルは、ホストバンドルのパーミッションの指定に従う。つまり、フラグメントバンドルから呼び出される機能は、ホストバンドルのパーミッションに従って処理されることになる。また、ＯＳＧｉの規定上、このアタッチ、デタッチの切り替え時に、ホストバンドルのパーミッションが変わることはない。

なお、アプリの修正または拡張時に、フラグメントバンドルを用いてホストバンドルの機能を修正または拡張することで、インストールするファイルサイズが小さくでき効率的にモジュールの配布が可能である。

図５は、バンドル管理サービス２１４における、バンドルの管理画面５００とインストール画面５３０を示した図である。

まず、バンドルの管理画面５００から説明する。

バンドル名５０１は、管理されているバンドル名を表示する。この例の場合、バンドルＡ５０５とバンドルＢ５０６の２つが管理されている。更に、このバンドルＡをホストバンドルとして、フラグメントバンドルＡ５０７、フラグメントバンドルＢ５０８が管理されている。この場合、ホストバンドルとフラグメントバンドルが紐づいている（対応づいている）ことがわかるように、バンドルＡ５０５と関連付けて表示される。インストール日５０２は、各バンドルがインストールされた日付である。バンドルＩＤ５０３は、各バンドルに一意に割り振られたバンドルＩＤを表示している。バンドルＩＤは、バンドルを識別するための識別情報である。状態５０４は、各バンドルの状態を示している。バンドルが開始であれば開始、停止であれば停止と表示される。また、フラグメントバンドルの場合、ホストバンドルにアタッチされている場合は、有効と表示される。このフラグメントバンドルがアタッチされている状態を有効状態という。フラグメントバンドルにアタッチされていない、つまりデタッチされている場合は、無効と表示される。このフラグメントバンドルがデタッチされている状態を無効状態という。無効状態の場合、ホストバンドルとのつながりはないが、ＨＤＤ１０４上にｊａｒの実体は残っている。そのため、この無効状態から有効化を実行すれば、改めてｊａｒを指定しなくとも有効状態に遷移することができる。開始ボタン５１６／停止ボタン５１３は、バンドルの開始停止を切り替える指示ボタン（受付ボタン）である。開始状態のバンドルの場合、停止ボタンとなり、停止状態のバンドルの場合、開始ボタンと表示される。有効化ボタン５１５／無効化ボタン５１４は、フラグメントバンドルの有効無効を切り替える指示ボタンである。有効状態のバンドル（本例では、「フラグメントバンドルＡ５０７」）の無効化ボタン５１４を押下すると、その状態５０４は無効に変更される。一方、無効状態のバンドル（本例では、「フラグメントバンドルＢ５０８」）の有効化ボタン５１５を押下すると、その状態５０４は有効に変更される。アンインストールボタン５１７〜５２０は、各バンドルをアンインストールする指示ボタンである。アンインストールが指示された場合、ＨＤＤ１０４上に残っているｊａｒの実体が削除される。

次に、インストール画面５３０について説明する。参照ボタン５３３は、ファイルパスを選択する画面を表示する。その画面でバンドルファイルを指定すると、バンドルファイルのパス５３１にバンドルファイルへのパスが入力される。バンドルは、セキュリティやビジネス上の観点から暗号化されており、インストール処理において、バンドルを復号する必要がある。そのための鍵を保持するライセンスファイルが必要となる場合がある。その場合、参照ボタン５３４を押下すると、ファイルパスを選択する画面を表示する。そこでバンドル指定と同様にライセンスファイルを指定すると、ライセンスファイルのパス５３２にライセンスファイルへのパスが入力される。インストールボタン５３５が押下されると、バンドルファイルのパス５３１で指定したバンドルのインストールが開始される。フラグメントバンドルがインストールに指定された場合、フラグメントバンドルは、一旦無効状態でインストールされる。

図６は、ＪＡＶＡにおけるパーミッションの仕組みについて説明した図である。

ＪＡＶＡのアプリケーション環境のポリシーは、さまざまなソースを出所とするコードがどのようなアクセス権を使用できるかを指定することできる。このコードがどのようなアクセス権を使用できるかを指定できるファイルをポリシーファイル６０１と呼ぶ。

ＪａｖａＶＭ２０７は、ポリシーファイル６０１が指定されているとする。このポリシーファイル６０１は、／ｊａｖａ＿ｈｏｍｅ／ｌｉｂ／ｅｘｔ／＊”の配下にあるｊａｒファイルは、
「ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ”／ｄａｔａ／ｆｏｏ．ｄａｔ” “ｒｅａｄ，ｗｒｉｔｅ”」
というパーミッションを保持していることを示している。このパーミッションは、／ｌｏｇ／ｆｏｏ．ｄａｔというファイルに対して、読み書きのパーミッションを持つことを意味している。

そのため、／ｊａｖａ＿ｈｏｍｅ／ｌｉｂ／ｅｘｔ／６０２配下にあるＳａｍｐｌｅ１．ｊａｒ６０３とＳａｍｐｌｅ２．ｊａｒ６０４は、このパーミッションを持つことになる。一方、／ｊａｖａ＿ｈｏｍｅ／ｅｔｃ６０５の配下にあるＳａｍｐｌｅ３．ｊａｒ６０６は、パーミッションを持たないことになる。

ＪａｖａＶＭ２０７は、ＡＰＩが権限チェックを望んでいる場合、デフォルトのポリシーファイル６０１を参照する。そして、呼び出し元バンドルが保持しているパーミッションとＡＰＩがチェックしたいパーミッションを参照して、呼び出し元バンドルがパーミッションを保持しているかどうかを判断している。パーミッションを保持していない場合、そのＡＰＩは利用不可ということで、処理を中断しエラーを返す。

例えば、あるｊａｒからＪＡＶＡ標準ライブラリのｊａｖａ．ｉｏ．Ｆｉｌｅ．ｃｒｅａｔｅＮｅｗＦｉｌｅ６００という新規にファイルを作成するＡＰＩを利用し、「／ｄａｔａ／ｆｏｏ．ｄａｔ」というファイルを作成する場合を考える。このｃｒｅａｔｅＮｅｗＦｉｌｅ６００というＡＰＩは、指定されたパスへの書き込みパーミッションを持っているバンドルにしか、書き込み処理を行わない仕様である。そのため、このファイルに対する読み書きのパーミッションを持つＳａｍｐｌｅ１．ｊａｒ６０３とＳａｍｐｌｅ２．ｊａｒ６０４からのコール（６１０，６１１）の場合は、エラーになることはない。一方、Ｓａｍｐｌｅ３．ｊａｒ６０６からのコール（６１２）の場合は、書き込みのパーミッションがないというエラーが返ることになる。

図７は、ＯＳＧｉにおけるパーミッションの仕組みについて説明した図である。

これは、図６で示したＪＡＶＡのパーミッション管理の仕組みを基本として、ＪａｖａＶＭ２０７が参照する呼び出し元バンドルが保持しているパーミッションをＯＳＧｉ拡張部２１１が管理する構成となっている。

ＯＳＧｉ拡張部２１１は、各バンドルが保持するパーミッションをパーミッションリスト７０５としてメモリ上で管理している。ＪａｖａＶＭ２０７は、呼び出しバンドルが保持しているパーミッションが何か取得するときにこのパーミッションリスト７０５を参照する。

デフォルトポリシーファイル７００は、／ｊａｖａ＿ｈｏｍｅ／ｌｉｂ／ｅｘｔ／＊”の配下にあるｊａｒファイルは、３つのパーミッションを保持していることを示している。尚、デフォルトポリシーファイルは、すべてのバンドルに共通に与えられるパーミッションである。

更に、／ｊａｖａ／ｂｕｎｄｌｅｓ／７０１の配下にあるＢｕｎｄｌｅ１．ｊａｒ７０２は、パーミッション定義ファイル７０４を保持している。一方、Ｂｕｎｄｌｅ２．ｊａｒ７０３は、バンドル定義ファイルを保持していないとする。Ｂｕｎｄｌｅ１．ｊａｒ７０２は、デフォルトポリシーファイルにあるパーミッションにパーミッション定義ファイルにあるパーミッションを加えたパーミッションに従って動作する。Ｂｕｎｄｌｅ２．ｊａｒ７０３は、バンドル定義ファイルを保持していないので、デフォルトポリシーファイルにあるパーミッションに従って動作する。

ここで、図８でバンドルが抱えるパーミッション定義ファイルについて説明する。

図８（ａ）は、バンドルが抱えるパーミッション定義ファイルについて説明した図である。バンドルｊａｒファイル８００は、マニフェストファイル８０１と同様にパーミッション定義ファイル８０２を保持することができる。

図８（ｂ）は、Ｂｕｎｄｌｅ１．ｊａｒ７０２のパーミッション定義ファイル７０４を示している。具体的には、
（ｊａｖａ．ｌａｎｇ．ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ “＊” “ＸＸＸ”）
（ｊａｖａ．ｓｅｃｕｒｉｔｙ．ＳｅｃｕｒｉｔｙＰｅｒｍｉｓｓｉｏｎ “＊” “ＹＹＹ”）
（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ “／ｌｏｇ／ｆｏｏ．ｌｏｇ” “ｒｅａｄ，ｗｒｉｔｅ”）
の３つのパーミッションが定義されている。

図７の説明に戻り、Ｂｕｎｄｌｅ１．ｊａｒ７０２が、保持しているパーミッションについて説明する。ＯＳＧｉ拡張部２１１は、バンドルの最初のインストール時に、デフォルトポリシーファイル７００とバンドル定義ファイル７０４を合算したものをメモリ上にパーミッションリスト７０５として管理する。このときのパーミッションリスト７０５の状態について、図９で説明する。また、このときのＯＳＧｉ拡張部２１１がバンドルリスト７０５を作成するフローは、図１０で示す。

図９は、ＯＳＧｉ拡張部が、ＲＡＭ１０３のメモリ上で保持するパーミッションリスト９００、９０１と、ＯＳＧｉ拡張部が、ＨＤＤ１０４に出力するパーミッションファイル９０２について説明した図である。

Ｂｕｎｄｌｅ１．ｊａｒ７０２のパーミッション９００は、デフォルトポリシーファイル７００のパーミッション９１０とバンドル定義ファイル７０４のパーミッション９１１を合算したものとなる。

Ｂｕｎｄｌｅ２．ｊａｒ７０３のパーミッション９０１は、デフォルトポリシーファイル７００のパーミッション９１０のみとなる。

これら、バンドルごとに保持しているパーミッションリスト９００、９０１の内容をまとめてパーミッションファイル９０２に出力する。パーミッションファイル９０２には、画像形成装置にインストールされているすべてのバンドルのパーミッションがバンドルごとに出力されている。９２０で示すのは、Ｂｕｎｄｌｅ１．ｊａｒ７０２が保持するパーミッションとなっており、これはパーミッションリスト９００の内容と同じものである。ＢｕｎｄｌｅＩＤ９２１は、Ｂｕｎｄｌｅ１．ｊａｒ７０２に割り振られたユニークなＩＤである。また、９２２で示すのは、Ｂｕｎｄｌｅ２．ｊａｒ７０３が保持するパーミッションとなっており、これはパーミッションリスト９０１の内容と同じものである。ＢｕｎｄｌｅＩＤ９２３は、Ｂｕｎｄｌｅ２．ｊａｒ７０３に割り振られたユニークなＩＤである。

図１０（ａ）は、バンドルのインストール時に、ＯＳＧｉ拡張部２１１がバンドルリスト７０５を作成するフローチャートである。尚、図１０（ａ）で説明する「バンドル」は、フラグメントバンドルは含まず、ホストバンドルに相当する。

Ｓ１０００において、バンドルのインストール処理におけるパーミッション処理を開始する。ここで、バンドルは、図３で示したようにバンドルインストールＵＩ３０２からインストールされる。

Ｓ１００１において、デフォルトポリシーファイル７００を読み込み、ここに記載のデフォルトパーミッションをバンドルのパーミッションリストに追加する。

Ｓ１００２において、インストールしようとしているバンドルが、パーミッション定義ファイルを保持するかどうかを確認する。保持している場合は、Ｓ１００３に進む。保持していない場合は、Ｓ１００４に進む。

Ｓ１００３において、パーミッション定義ファイル７０４のパーミッション読み込み、ここに記載のパーミッションをバンドルのパーミッションリストに追加して、更新する。尚、ホストバンドルのパーミッション定義ファイルに記載されたパーミッションで、すでに、パーミッションリストに含まれるパーミッションについては、重複させずに、追加しない。

Ｓ１００４において、バンドルのパーミッションリストをパーミッションファイル９０２として出力する。

Ｓ１００５において、インストール時のパーミッションの処理を終了する。

次に、図１０（ｂ）は、画像形成装置の起動時に、Ｓ１００５において出力されたパーミッションファイルが、どのように利用されるかを示す。

Ｓ１０１０において、画像形成装置起動時のＯＳＧｉ拡張部２１１によるパーミッションの処理が開始される。

Ｓ１０１１において、パーミッションファイル９０２からバンドルＩＤ９２１をもとに、バンドルごとのパーミッションリストを作成する。図９でいうと、Ｂｕｎｄｌｅ１．ｊａｒ７０２のパーミッション９２０から、Ｂｕｎｄｌｅ１．ｊａｒのパーミッションリスト９００を作成する。また、Ｂｕｎｄｌｅ２．ｊａｒ７０３のパーミッション９２２から、Ｂｕｎｄｌｅ２．ｊａｒのパーミッションリスト９０１を作成する。

Ｓ１０１２において、起動時のパーミッションの処理を終了する。

こうして、起動後は、各バンドルのパーミッションリストがメモリ上に展開され、ＪａｖａＶＭ２０７からのバンドルが保持するパーミッションの問い合わせ時に、参照可能となる。

図１１は、図７で示したＢｕｎｄｌｅ１．ｊａｒ７０２、Ｂｕｎｄｌｅ２．ｊａｒ７０３からｃｒｅａｔｅＮｅｗＦｉｌｅ６００を呼び出した時のパーミッション処理に関するシーケンス図を示しものである。

バンドル（例としては、Ｂｕｎｄｌｅ１．ｊａｒ７０２、もしくはＢｕｎｄｌｅ２．ｊａｒ７０３が呼び出されたケースを示す）は、Ｓ１１００において、ｃｒｅａｔｅＮｅｗＦｉｌｅ６００を利用して”／ｌｏｇ／ｆｏｏ．ｌｏｇ”にログを出力するものとする。尚、例として、ログ出力処理を行うバンドルの例で説明するが、他の処理を行うバンドルであっても構わない。どのようなバンドルであっても、Ｓ１１０１からＳ１１０５、Ｓ１１０６、Ｓ１１０８は同様である。また、例として、バンドルは、フラグメントバンドルと含まない、つまり、バンドル（ホストバンドルに相当）の例で説明する。が、フラグメントバンドルを含むバンドル、つまり、ホストバンドルとフラグメントバンドルからなるバンドルであっても、同様のパーミッション処理を行う。

ｃｒｅａｔｅＮｅｗＦｉｌｅ６００は、Ｓ１１０１において、パーミッションチェックを行う。このとき呼び出し元が、必要なパーミッションを保持しているかどうかをＪａｖａＶＭ２０７に問い合わせる。ＪａｖａＶＭ２０７は、Ｓ１１０２において、本スレッドのスタックを遡り、パーミッションをチェックするべきバンドルのバンドルＩＤリストを取得する。ここで、チェックするべきバンドルとは、本処理でロードされたクラスを保持するバンドルを指す。本例では、チェックするべきバンドルは、Ｂｕｎｄｌｅ１．ｊａｒ７０２、もしくはＢｕｎｄｌｅ２．ｊａｒ７０３と１つである。が、Ｂｕｎｄｌｅ１．ｊａｒ７０２、もしくはＢｕｎｄｌｅ２．ｊａｒ７０３が他のバンドルから呼び出されていた場合、これらを呼び出したバンドルも含まれる。次にＳ１１０３において、ＪａｖａＶＭ２０７は、Ｓ１１０２で取得したリストの全てのバンドルに対してのパーミッションチェックを行う。ＪａｖａＶＭ２０７は、Ｓ１１０４において、バンドルＩＤを基にＯＳＧｉ拡張部２１１にバンドルが保持しているパーミッションを問い合わせる。ＯＳＧｉ拡張部２１１は、Ｓ１１０５において、ＪａｖａＶＭ２０７から問い合わせのあったバンドル（Ｂｕｎｄｌｅ１．ｊａｒ７０２、もしくはＢｕｎｄｌｅ２．ｊａｒ７０３）のパーミッションリストのパーミッション一覧を返却する。ＪａｖａＶＭ２０７は、Ｓ１１０６において、ｃｒｅａｔｅＮｅｗＦｉｌｅ６００が必要としているパーミッションが、ＯＳＧｉ拡張部２１１から返却されたパーミッション一覧に含まれるかどうかを判定する。Ｓ１１０３においては、全てのバンドルに対してチェックを行う。

Ｓ１１０３の結果、必要なパーミッションが全てのバンドルに含まれる場合は、ＪａｖａＶＭ２０７は、Ｓ１１０７において、ＯＫの戻り値を返す。一方、１つでも含まれないバンドルがあった場合は、ＮＧの戻り値を返す。

ここで、戻り値がＮＧだった場合、Ｓ１１０８にいて、ｃｒｅａｔｅＮｅｗＦｉｌｅ６００は、ＮＧの戻り値をバンドルに返す。一方、戻り値がＯＫだった場合、ｃｒｅａｔｅＮｅｗＦｉｌｅ６００は、Ｓ１１０９において、ファイル作成処理を実行する。その後、Ｓ１１１０において、ＯＫの戻り値をバンドルに返す。

バンドルが、Ｂｕｎｄｌｅ１．ｊａｒ７０２の場合、／ｌｏｇ／ｆｏｏ．ｌｏｇへの書き込みパーミッションを意味する
（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ “／ｌｏｇ／ｆｏｏ．ｌｏｇ” “ｒｅａｄ，ｗｒｉｔｅ”）
を含むので、Ｓ１１０７において、パーミッション保持ＯＫの判断となり、ファイルは作成される。

一方、バンドルが、Ｂｕｎｄｌｅ２．ｊａｒ７０３の場合、／ｌｏｇ／ｆｏｏ．ｌｏｇへの書き込みパーミッションを含まないので、Ｓ１１０７において、パーミッション保持ＮＧの判断となり、ファイル作成に失敗する。

以上、ＯＳＧｉで管理されているバンドルのパーミッションに関する動きについて説明してきた。さらに、ＯＳＧｉの機能であるフラグメントバンドルを含んだときについて説明する。

図１２は、ＯＳＧｉにおけるホストバンドルとフラグメントバンドルのパーミッションの仕組みについて説明した図である。

ＪａｖａＶＭ２０７、ｃｒｅａｔｅＮｅｗＦｉｌｅ６００、ＯＳＧｉ拡張部２１１、ポリシーファイル７００は図７と同じ役割の為、ここでの説明は省略する。

／ｊａｖａ／ｂｕｎｄｌｅｓ／７０１の配下にある、Ｈｏｓｔ．ｊａｒ１２００は、ホストバンドルである。また、Ｆｒａｇｍｅｎｔ１．ｊａｒとＦｒａｇｍｅｎｔ２．ｊａｒは、Ｈｏｓｔ．ｊａｒ１２００のフラグメントバンドルである。Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２とＦｒａｇｍｅｎｔ２．ｊａｒ１２０３は、バンドル定義ファイル１２０４、１２０５を保持している。

次に、図１３で各バンドルが抱えるパーミッション定義ファイルについて説明する。

図１３は、バンドルが抱えるパーミッション定義ファイルについて説明した図である。Ｈｏｓｔ．ｊａｒ１２００のパーミッション定義ファイル１２０１には、
（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ “４ｄ０６ｄ２８２−ｄｅｂ４−４６２ｅ−ｂｄ４８−７１１６７ｃ１７７” “ＨＯＳＴ”）
の記載がある。

Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２のパーミッション定義ファイル１２０４には、
（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ “４ｄ０６ｄ２８２−ｄｅｂ４−４６２ｅ−ｂｄ４８−７１１６７ｃ１７７” “ＦＲＡＧＭＥＮＴ”）
（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ “／ｌｏｇ／ｆｏｏ１．ｌｏｇ” “ｒｅａｄ，ｗｒｉｔｅ”）
２つのパーミッションが記載されている。

Ｆｒａｇｍｅｎｔ２．ｊａｒ１２０３のパーミッション定義ファイル１２０５には、
（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ “４ｄ０６ｄ２８２−ｄｅｂ４−４６２ｅ−ｂｄ４８−７１１６７ｃ１７７” “ＦＲＡＧＭＥＮＴ”）
（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ “／ｌｏｇ／ｆｏｏ２ｚｕ．ｌｏｇ” “ｒｅａｄ，ｗｒｉｔｅ”）
２つのパーミッションが記載されている。

図１２の説明に戻り、Ｈｏｓｔ．ｊａｒ１２００が、保持しているパーミッションについて説明する。ＯＳＧｉ拡張部２１１は、バンドルの最初のインストール時に、デフォルトポリシーファイル７００とバンドル定義ファイル１２０１を合算したものをメモリ上にパーミッションリスト１２０６として管理する。このときの状態を状態（１）とする。さらに、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２が、Ｈｏｓｔ．ｊａｒ１２００にアタッチされる際に、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２が保持しているバンドル定義ファイル１２０４のパーミッションをパーミッションリスト１２０６に追加して管理する。同様に、Ｆｒａｇｍｅｎｔ２．ｊａｒ１２０３が、Ｈｏｓｔ．ｊａｒ１２００にアタッチされる際に、Ｆｒａｇｍｅｎｔ２．ｊａｒ１２０３が保持しているバンドル定義ファイル１２０５のパーミッションをパーミッションリスト１２０６に追加して管理する（このときの状態を状態（２）とする）。

このときのパーミッションリスト１２０６の状態について、図１４で説明する。また、このときのＯＳＧｉ拡張部２１１がバンドルリスト１２０６を作成するフローは、図１５で示す。

図１４は、フラグメントバンドルがアタッチされたときに、ホストバンドルが保持するパーミッションリストの変化について説明した図である。

パーミッションリスト１４００は、状態（１）のときのパーミッションを示している。

パーミッションリスト１４０１は、状態（２）のときのパーミッションを示している。このうち１４１０で示すパーミッションは、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２とＦｒａｇｍｅｎｔ２．ｊａｒ１２０３が保持しているパーミッション定義ファイル１２０４、１２０５に記載されたパーミッションである。ただし、重複している同じパーミッションは、重複してリストには含まない。

これらのホストバンドルに保持しているパーミッションリスト１４０１の内容をパーミッションファイル１４０２に出力する。パーミッションファイル１４０２には、画像形成装置にインストールされているすべてのバンドルのパーミッションがバンドルごとに出力されている。１４２０で示すのは、Ｈｏｓｔ．ｊａｒ１２００が保持するパーミッションとなっており、これはパーミッションリスト１４０１の内容と同じものである。ＢｕｎｄｌｅＩＤ１４２１は、Ｈｏｓｔ．ｊａｒ１２００に割り振られたユニークなＩＤである。

図１５（ａ）は、フラグメントバンドルがホストバンドルへアタッチされるときのＯＳＧｉ拡張部２１１のパーミッション処理についてのフローチャートである。

Ｓ１５００において、フラグメントバンドルのホストバンドルへのアタッチ処理を開始する。ここで、フラグメントバンドルは、図５で示したように、有効化ボタン５１５を押下することで、ホストバンドルへアタッチされる。

Ｓ１５０１において、アタッチしようとしているフラグメントバンドルが、パーミッション定義ファイルを保持するかどうかを確認する。保持している場合は、Ｓ１５０２に進む。保持していない場合は、Ｓ１５０３に進む。

Ｓ１５０２において、パーミッション定義ファイル１２０４／１２０５のパーミッションを読み込み、記載されたパーミッションをバンドルのパーミッションリスト１２０６に追加する。ただし、既にパーミッションリスト１２０６に重複している同じパーミッションがある場合は、重複してリストには追加しない。

Ｓ１５０３において、バンドルのパーミッションリストをパーミッションファイル１４０２として出力する。

Ｓ１５０４において、フラグメントバンドルのアタッチ時のパーミッションの処理を終了する。

次に、図１５（ｂ）は、画像形成装置の起動時に、Ｓ１５０３において出力されたパーミッションファイル１４０３が、どのように利用されるかを示す。

Ｓ１５１０において、画像形成装置起動時のＯＳＧｉ拡張部２１１によるホストバンドルにおけるパーミッションの処理が開始される。

Ｓ１５１１において、パーミッションファイル１４０２からバンドルＩＤ１４２１をもとに、バンドルごとのパーミッションリストを作成する。図１４でいうと、Ｈｏｓｔ．ｊａｒ１２００のパーミッション１４２０から、Ｈｏｓｔ．ｊａｒのパーミッションリスト１４０１を作成する。

Ｓ１５１２において、起動時のパーミッションの処理を終了する。

こうして、起動後は、フラグメントバンドルが保持しているパーミッション定義ファイルの内容が、ホストバンドルのパーミッションリスト１２０６がメモリ上に展開される。そして、ＪａｖａＶＭ２０７からのバンドルが保持するパーミッションの問い合わせ時に、参照可能となる。

尚、フラグメントバンドルを含むバンドルを呼び出した時のパーミッション処理に関するシーケンス図は、図１１と同様である。図１１のバンドル７０２／７０３が、フラグメントバンドルとホストバンドルを含むバンドルに相当する。

以上、説明したように、フラグメントバンドルのアタッチのタイミングでホストバンドルのパーミッションリストにフラグメントバンドルが保持するパーミッション定義ファイルの内容を追加する。これにより、一般的なバンドル同様の仕組みで、フラグメントバンドルが必要としているパーミッションを利用可能となるという効果が得られる。

次に、ホストバンドルにアタッチされたフラグメントバンドルを逆にホストバンドルからデタッチ（削除）するときのＯＳＧｉ拡張部によるパーミッション処理について述べる。

図１６は、フラグメントバンドルがホストバンドルへデタッチされるときのＯＳＧｉ拡張部２１１のホストバンドルのパーミッション処理についてのフローチャートである。

具体的には、図１２で示したように、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２とＦｒａｇｍｅｎｔ２．ｊａｒ１２０３がＨｏｓｔ．ｊａｒ１２００にアタッチされている状態からＦｒａｇｍｅｎｔ１．ｊａｒ１２０２をデタッチするケースを考える。

Ｓ１６００において、フラグメントバンドルのホストバンドルからのデタッチ処理を開始する。ここで、フラグメントバンドルは、図５で示したように、無効化ボタン５１４を押下することで、ホストバンドルからデタッチされる。

Ｓ１６０１において、デタッチしようとしているフラグメントバンドルが、パーミッション定義ファイルを保持するかどうかを確認する。保持している場合は、Ｓ１６０２に進む。保持していない場合は、Ｓ１６０７に進む。

Ｓ１６０２において、パーミッション定義ファイル１２０４のパーミッション読み込み、ここに記載のパーミッションをバンドルのパーミッションリスト１２０６から削除する。

Ｓ１６０３において、デタッチされたホストバンドルに紐づくフラグメントバンドルが残っているかどうかを判断する。残っている場合、Ｓ１６０４に進む。残っていない場合、Ｓ１６０５に進む。

Ｓ１６０４において、残っているフラグメントバンドルのパーミッション定義ファイルを読み込み、記載されたパーミッションをバンドルのパーミッションリスト１２０６に追加する。尚、フラグメントバンドルのパーミッション定義ファイルに記載されたパーミッションで、すでに、パーミッションリストに含まれるパーミッションについては、重複させずに、追加しない。

具体例で説明すると、残っているフラグメントバンドルＦｒａｇｍｅｎｔ２．ｊａｒ１２０３のパーミッション定義ファイル１２０５を読み込み、ここに記載のパーミッションをバンドルのパーミッションリスト１２０６に追加する。これは、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２のパーミッション定義ファイル１２０４で重複したパーミッションである
（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＢｕｎｄｌｅＰｅｒｍｉｓｓｉｏｎ “４ｄ０６ｄ２８２−ｄｅｂ４−４６２ｅ−ｂｄ４８−７１１６７ｃ１７７” “ＦＲＡＧＭＥＮＴ”）
が、Ｓ１６０２において削除されているので、ここで改めて追加するために行う。

Ｓ１６０５において、ホストバンドルのパーミッション定義ファイルを読み込み、記載されたパーミッションをバンドルのパーミッションリスト１２０６に追加する。尚、ホストバンドルのパーミッション定義ファイルに記載されたパーミッションで、すでに、パーミッションリストに含まれるパーミッションについては、重複させずに、追加しない。

Ｓ１６０６において、バンドルのパーミッションリストをパーミッションファイル１４０２として出力する。

Ｓ１６０７において、フラグメントバンドルのデタッチ時のパーミッションの処理を終了する。

尚、Ｓ１６０４、Ｓ１６０５において、それぞれのステップで、すでに、パーミッションリストに含まれるパーミッションについては、重複させずに、追加しないようにした。しかし、フラグメントバンドルのパーミッション定義ファイルに記載されたパーミッションと、ホストバンドルのパーミッション定義ファイルに記載されたパーミッションをそれぞれ、追加した後に、重複したパーミッションについては削除するようにしてもよい。

図１７は、フラグメントバンドルがデタッチされたときに、ホストバンドルが保持するパーミッションリストの変化について説明した図である。

ホストバンドルのパーミッションリスト１７００は、Ｆｒａｇｍｅｎｔ１．ｊａｒ１２０２とＦｒａｇｍｅｎｔ２．ｊａｒ１２０３がＨｏｓｔ．ｊａｒ１２００にアタッチされている状態の１４０１と同じ状態である。

この状態からＦｒａｇｍｅｎｔ１．ｊａｒ１２０２がデタッチされた場合、最終的には、１７０１で示すパーミッションがホストバンドルのパーミッションリスト１２０６となる。ここで、１７０２は、デフォルトポリシーのパーミッション、１７０３は、Ｈｏｓｔ．ｊａｒに定義されたパーミッション、１７０４は、Ｆｒａｇｍｅｎｔ２．ｊａｒ１２０３で定義されたパーミッションとなる。

以上、説明したように、フラグメントバンドルのデタッチのタイミングでホストバンドルのパーミッションリストからデタッチするフラグメントバンドルが保持するパーミッション定義ファイルの内容を削除する。これにより、ホストバンドルのパーミッションリストの内容が、必要なパーミッションが残る状態に更新され、セキュリティ上望ましい状態となるという効果が得られる。

以上、説明したように、本実施形態によれば、フラグメントバンドルのアタッチ、デタッチのライフサイクルとパーミッション追加、削除のライフサイクルを同期させる。これにより、フラグメントバンドルの利用可能なパーミッションが、必要なときに必要な分だけ利用可能となる。

また、ホストバンドルは、自身が必要な分だけのパーミッションを保持しておけばよい。

本実施形態の効果を、以下で、具体的に説明する。

バンドルが管理者権限のような強いパーミッションをもつことで、画像形成装置内に悪影響を与えることができる。そのため、セキュリティ的にアプリに必要以上の権限を与えたくないというのが、一般的である。このため、ホストバンドルがもつパーミッションは、ホストバンドルが実装している範囲で必要十分なだけのパーミッションだけを持つことが推奨される。

一方、フラグメントバンドルは、ホストバンドルの機能を追加、差し替えるために利用されるものである。そのため、当然、必要なパーミッションが変わってくる。このとき、フラグメントバンドルで追加、差し替えた機能は、ホストバンドルで定義されたパーミッションに従って処理を行う。そのため、フラグメントバンドルが必要なパーミッションを、予め、ホストバンドルにｊａｖａ．ｓｅｃｕｒｉｔｙ．ＡｌｌＰｅｒｍｉｓｓｉｏｎという全てのパーミッションをもつことを意味するパーミッションを保持しておくことが考えられる。しかし、これだと必要最小限のパーミッションを持つべきという推奨ルールに反する。

また、フラグメントバンドルの追加に合わせて、ホストバンドルが保持するパーミッション定義を変えることも考えられる。しかし、これだと、フラグメントバンドルに合わせてホストバンドルを再作成する必要があり、フラグメントバンドルのみで機能が拡張できるフラグメントバンドルの特徴が損なわれることになる。

これらの課題に対して、本実施形態によれば、フラグメントバンドルのホストバンドルへのアタッチおよびデタッチに合わせて、適宜パーミッションを管理する仕組みが提供できる。

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

Claims (13)

1. ホストアプリケーションに対応つけられた前記ホストアプリケーションのパーミッションリストを保持する保持手段と、
   前記ホストアプリケーションに、プラグインアプリケーションを追加する追加手段と、
   前記プラグインアプリケーションに含まれるパーミッションを、前記ホストアプリケーションのパーミッションリストに追加して更新する更新手段と、
   前記更新されたパーミッションリストに基づいて、前記ホストアプリケーションおよび前記プラグインアプリケーションにおける処理を実行するかを判定する判定手段を有することを特徴とする画像形成装置。
2. 前記プラグインアプリケーションは、前記プラグインアプリケーションのパーミッションを含むパーミッション定義ファイルを保持することを特徴とする請求項１に記載の画像形成装置。
3. 前記ホストアプリケーションのパーミッションリストは、前記ホストアプリケーションを識別するための識別情報を含むことを特徴とする請求項１または請求項２に記載の画像形成装置。
4. 前記ホストアプリケーションに、前記プラグインアプリケーションを追加する指示を受け付ける第１の受付手段を有し、
   前記第１の受付手段が受け付けた指示に基づいて、前記追加手段は、前記ホストアプリケーションに、前記プラグインアプリケーションを追加することを特徴とする請求項１乃至３の何れか１項に記載の画像形成装置。
5. 前記ホストアプリケーションから、前記プラグインアプリケーションを削除する削除手段を有する請求項１乃至４の何れか１項に記載の画像形成装置。
6. 前記ホストアプリケーションから、前記プラグインアプリケーションを削除する指示を受け付ける第２の受付手段を有する請求項５に記載の画像形成装置。
7. 前記第２の受付手段が受け付けた指示に基づいて、前記削除手段は、前記ホストアプリケーションから、前記プラグインアプリケーションを削除する請求項６に記載の画像形成装置。
8. 前記第２の受付手段が受け付けた指示に基づいて、前記更新されたパーミッションリストから、前記プラグインアプリケーションに含まれるパーミッションを削除する削除手段をさらに有することを特徴とする請求項６または請求項７に記載の画像形成装置。
9. 前記削除手段は、前記更新されたパーミッションリストから、前記プラグインアプリケーションに含まれるパーミッションを削除し、さらに、前記ホストアプリケーションに含まれるパーミッションを追加することを特徴とする請求項８に記載の画像形成装置。
10. 画像形成装置の制御方法であって、
    ホストアプリケーションに、プラグインアプリケーションを追加する追加工程と、
    前記プラグインアプリケーションに含まれるパーミッションを、ホストアプリケーションに対応つけられたホストアプリケーションのパーミッションリストに追加して更新する更新工程と、
    前記更新されたパーミッションリストに基づいて、前記ホストアプリケーションおよび前記プラグインアプリケーションにおける処理を実行するかを判定する判定工程を有することを特徴とする画像形成装置の制御方法。
11. 前記プラグインアプリケーションは、前記プラグインアプリケーションのパーミッションを含むパーミッション定義ファイルを保持することを特徴とする請求項１０に記載の画像形成装置の制御方法。
12. 前記ホストアプリケーションのパーミッションリストは、前記ホストアプリケーションを識別するための識別情報を含むことを特徴とする請求項１０または請求項１１に記載の画像形成装置の制御方法。
13. 請求項１乃至９の何れか１項に記載の画像形成装置としてコンピュータを機能させるための該コンピュータで読み取り可能なプログラム。

Images