情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体
【課題】プログラムに対するアクセス制御の柔軟性を向上させることのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体の提供を目的とする。
【解決手段】プログラムを有する情報処理装置であってプログラムのアクセス権限情報を管理するアクセス権限情報管理手段とプログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する。
【解決手段】プログラムを有する情報処理装置であってプログラムのアクセス権限情報を管理するアクセス権限情報管理手段とプログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
近年では、主に複合機又は融合機と呼ばれる画像形成装置において、その出荷後に、公開されたＡＰＩ（Application Program Interface）を利用してＣ言語又はＪａｖａ（登録商標）言語等の汎用的なプログラミング言語による新たなアプリケーションの開発及びインストールが可能とされているものがある（例えば、特許文献１）。斯かる画像形成装置では、当該画像形成装置のベンダによって開発されたアプリケーションのみならず、他のソフトウェアベンダによって開発されたアプリケーションもインストールされ、利用されるといった状況が生じ得る。このような状況の中で、各アプリケーションに対して無条件に画像形成装置のリソース（プログラムやデータ等）に対するアクセスを許可してしまっては機密情報の漏洩や画像形成装置の不正動作等、不測の事態を招きかねない。したがって、各アプリケーションについて適切なセキュリティ管理（アクセス制御）が必要とされる。
【０００３】
Ｊａｖａ（登録商標）アプリケーションについては、Ｊａｖａ（登録商標）の実行環境が標準で備えるセキュリティ機構によってコードベースのアクセス制御を行うことができる。具体的には、ポリシーと呼ばれるデータ内において、プログラムの所在又はプログラムに対する署名者に応じてアクセス権限を設定することが可能である。但し、アプリケーションごと（プログラムごと）に、それぞれポリシーを定義するのは管理者による作業を煩雑化すると同時にポリシーの情報量を肥大化させ性能の劣化を招きかねない。
【０００４】
そこで、例えば、アプリケーションをその信頼度に応じてグループに分類し（レベル分けし）、ポリシー内ではグループ単位で（レベルごとに）アクセス権限を設定することが行われている。この場合、グループの粒度（レベルの段階）が細かすぎるとグループ分けの意味が没却されてしまう。したがって、或る程度大きなくくりによってグループ分けすること（レベルの段階を少なくすること）が効果的である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、或るアプリケーションがその機能を実現するために必要なアクセス権限の範囲の一部が、当該アプリケーションが属するグループに対して許可されるアクセス権限の範囲を超えてしまう場合がある（すなわち、当該一部の権限が認められないと当該アプリケーションの機能を実現できない場合がある。）。但し、当該アプリケーションが属するグループをより大きな範囲でアクセス権限が許可されるグループに変更してしまうと、当該アプリケーションに対する信頼度に対して、与えられる権限が大きすぎてしまうという問題がある。したがって、或る特定のアプリケーションに限って、当該アプリケーションが属するグループには許可されていないアクセス権限を例外的に認めることができる仕組みが必要とされる。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、プログラムに対するアクセス制御の柔軟性を向上させることのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、本発明は、プログラムを有する情報処理装置であってプログラムのアクセス権限情報を管理するアクセス権限情報管理手段とプログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する。
【発明の効果】
【０００８】
本発明によれば、プログラムに対するアクセス制御の柔軟性を向上させることのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態における複合機のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における複合機のソフトウェア構成例を示す図である。
【図３】本実施の形態におけるＪＳＤＫアプリの構成例を示す図である。
【図４】本実施の形態におけるポリシー設定ファイルの定義例を示す図である。
【図５】保護ドメインを説明するための図である。
【図６】セキュリティパッチの書式の例を示す図である。
【図７】ＣａｌｌｅｄＢｙフィールドの記述例を示す図である。
【図８】Ｓｔａｔｅフィールドの第一の記述例を示す図である。
【図９】Ｓｔａｔｅフィールドの第二の記述例を示す図である。
【図１０】ＪＳＤＫアプリ実行時の処理手順を説明するための図である。
【図１１】アプリケーション管理ファイルの定義例を示す図である。
【図１２】アプリ設定画面の表示例を示す図である。
【図１３】ＪＳＤＫアプリの起動処理を説明するための図である。
【図１４】オブジェクトとしてロードされたポリシーの例を示す図である。
【図１５】ポリシーの動的な変更をＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎの状態遷移として示す図である。
【図１６】ポリシーが動的に変更される際の処理手順を説明するためのシーケンス図である。
【図１７】ＪＳＤＫアプリの開発から運用までの手順の一例を説明するための図である。
【図１８】アプリ開発申請書の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における複合機のハードウェア構成例を示す図である。図１において複合機１０は、コントローラ２０１、オペレーションパネル２０２、ファクシミリコントロールユニット（ＦＣＵ）２０３、撮像部２０４、及び印刷部２０５等を備える。
【００１１】
コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。
【００１２】
ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、複合機１０のシステムメモリである。ＭＥＭ−Ｃ２３２は、複合機１０のローカルメモリである。ＨＤＤ２３３は、複合機１０のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。
【００１３】
オペレーションパネル２０２は、オペレータが複合機１０に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１０から出力を得るためのハードウェア（表示部）である。
【００１４】
図２は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。図２において、複合機１０のソウトウェアは、ＪＳＤＫアプリ３０、ＪＳＤＫプラットフォーム４０、及びネイティブサービスレイヤ５０等より構成されている。これらの各ソフトウェアは、それぞれに実装された処理手順をＣＰＵ２１１に実行させることによりその機能を実現する。
【００１５】
ネイティブサービスレイヤ５０は、複合機１０のハードウェアやソフトウェアに基づく機能を利用させるためのインタフェースを上位モジュールに対して提供し、当該インタフェースの呼び出し（機能の利用要求）に応じて、当該機能を実現するための制御を行う。例えば、ネイティブサービスレイヤ５０には、ネットワーク通信の制御に関するインタフェースを提供するモジュール、ファクシミリの制御に関するインタフェースを提供するモジュール、蓄積文書（ＨＤＤ２３３に保存されている文書（画像）データ）の配信処理の制御に関するインタフェースを提供するモジュール、撮像部２０４や印刷部２０５の制御に関するインタフェースを提供するモジュール。メモリやＨＤＤ２３３等の制御に関するインタフェースを提供するモジュール、オペレーションパネル２０２の制御に関するインタフェースを提供するモジュール、認証処理や課金処理の制御に関するインタフェースを提供するモジュール、ユーザ情報の管理に関するインタフェースを提供するモジュール等が含まれる。
【００１６】
ＪＳＤＫプラットフォーム４０は、ＪＳＤＫアプリ３０の実行環境を提供するソフトウェアプラットフォームであり、ネイティブサービスレイヤ５０に対するＪａｖａ（登録商標）インタフェースを上位モジュールに対して提供する。ＪＳＤＫプラットフォーム４０は、Ｊａｖａ（登録商標）の標準のクラスや、複合機１０用に拡張されたクラスに関するクラスライブラリ、及びＪａｖａ（登録商標）仮想マシン（ＶＭ４１）等を含む。
【００１７】
ＶＭ４１は、Ｊａｖａ（登録商標）バイトコードを逐次解釈しながらＪＳＤＫアプリ３０の実行を制御する。当該制御の一部として、ＶＭ４１は、ポリシー設定ファイル（ｐｏｌｉｃｙ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｉｌｅ）７０に予め定義されたポリシーに基づいて、ＪＳＤＫアプリ３０による、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを制限する。すなわち、ＶＭ４１は、Ｊａｖａ（登録商標）標準の仕組みとして、リソースへのアクセスが発生する際に、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスのインスタンス（ＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト）に対する通知が行われるように構成されている。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトは、その呼び出しに応じてポリシー設定ファイル７０に基づいてリソースへのアクセスの可否を判断する。
【００１８】
ところで、ＪＳＤＫプラットフォーム４０は、ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとして実装されている。ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。ＯＳＧｉプラットフォーム上において、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのＪＡＲ（Java ARchive）ファイルによって構成され、それぞれ独立して動的に（装置の再起動を要することなく）インストール可能である。
【００１９】
ＪＳＤＫアプリ３０は、ＪＳＤＫプラットフォーム４０において公開されている専用のＳＤＫ（ソフトウェア開発キット）を使用して作成されたアプリケーション（以下「ＳＤＫアプリ」という。）である。ＳＤＫアプリのうち、特にＪａｖａ（登録商標）言語を使用して開発されたアプリケーションをＪＳＤＫアプリという。
【００２０】
図中では、ＪＳＤＫアプリ３０の例として、ＳＡＳ（SDK Application Service）マネージャ３１、アプリケーションバンドル３２０、及びサービスバンドル３３０等が存在する。ＳＡＳマネージャ３１０は、他のＪＳＤＫアプリ３０（アプリケーションバンドル３２０やサービスバンドル３３０等）のインストール（追加）、アンインストール（削除）、起動、及び起動解除等の制御を行う。
【００２１】
アプリケーションバンドル３２０は、オペレーションパネル２０２に操作画面を表示させ、当該操作画面を介してエンドユーザから直接利用（操作）されるＪＳＤＫアプリ３０としてのバンドルである。図中では、アプリケーションバンドル３２０の一例としてスキャンアプリ３２１が示されている。スキャンアプリ３２１は、撮像部２０４による原稿からの画像の読み取りを実現するアプリケーションである。
【００２２】
サービスバンドル３３０は、アプリケーションバンドル３２０等に対してサービスを提供するためのＪＳＤＫアプリ３０としてのバンドルである。すなわち、サービスバンドル３３０は、アプリケーションバンドル３２０等からの呼び出しに応じて各サービスバンドル３３０に応じた処理を実行し、その処理結果をアプリケーションバンドル３２０等に返却する。図中では、サービスバンドル３３０の一例として、スキャンサービス３３１、及びパネルサービス３３２等が示されている。
【００２３】
スキャンサービス３３１は、画像の読み取り機能に関するサービスを提供する。パネルサービス３３２は、オペレーションパネル２０２の表示制御に関するサービスを提供する。
【００２４】
次に、複合機１０における、ＪＳＤＫアプリ３０に関するセキュリティの管理について説明する。上記したように、ＪＳＤＫアプリ３０は、ＪＳＤＫプラットフォーム４０において効果されているＳＤＫを用いて開発されるＪａｖａ（登録商標）アプリケーションである。したがって、複合機１の出荷後にサードベンダ等によって作成されるアプリケーション等もＪＳＤＫアプリ３０として複合機１にインストールされうる。
【００２５】
そこで、複合機１では、複合機１のリソースに対するアクセス権限の範囲をレベル分け（グループに分類）し（当該レベルを以下「セキュリティレベル」という。）、ＪＳＤＫアプリ３０ごとに、その信頼度に応じたセキュリティレベルを付与することによりコードベースのアクセス制御を実現している。セキュリティレベルは、各ＪＳＤＫアプリ３０に付された署名（電子署名）によって識別可能とされている。
【００２６】
図３は、本実施の形態におけるＪＳＤＫアプリの構成例を示す図である。同図に示されるように、各ＪＳＤＫアプリ３０は、ＪＡＲファイル３１及びアプリケーション管理ファイル５１等のファイルを含む。ここで、ＪＡＲファイル３１に付されている（関連付けられている）署名３３が、セキュリティレベルを識別するための署名に相当する。署名３３は、例えば、ＪＡＲファイル３１のハッシュ値を暗号化したものであり、当該暗号化に用いられた暗号鍵によってセキュリティレベルが識別される。署名３３は、セキュリティレベルの識別の他、ＪＳＤＫアプリ３０の改ざんの有無のチェックにも用いられる。なお、本実施の形態において、セキュリティレベルは、レベル１（Ｌｖ１）、レベル２（Ｌｖ２）、及びレベル３（Ｌｖ３）の３段階の値を有することとする。Ｌｖ１が最もアクセス権限が大きく、Ｌｖ３が最もアクセス権限が小さい。
【００２７】
セキュリティレベルごとのアクセス権限については、Ｊａｖａ（登録商標）標準の仕様に基づいてポリシー設定ファイル７０において定義されている。
【００２８】
図４は、本実施の形態におけるポリシー設定ファイルの定義例を示す図である。同図においてポリシー設定ファイル７０の書式は、Ｊａｖａ（登録商標）標準の仕様に従っているため、書式に関する詳細な説明については省略する。
【００２９】
同図では、３つのｇｒａｎｔエントリが示されている。ｇｒａｎｔエントリ７１のｓｉｎｅｄＢｙフィールドには、Ｌｖ１が指定されている。したがって、ｇｒａｎｔエントリ７１の定義は、セキュリティレベルの値がＬｖ１の署名３３が付されたＪＳＤＫアプリ３０に適用される。同様に、ｇｒａｎｔエントリ７２はＬｖ２の署名３３が付されたＪＳＤＫアプリ３０に、ｇｒａｎｔエントリ７３はＬｖ３の署名３３が付されａｔＪＳＤＫアプリ３０に適用される。
【００３０】
なお、ｇｒａｎｔエントリ７１において、（ａ）では、実行時（Ｌｖ１のＪＳＤＫアプリ３０の実行時）には（ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ）、全てのパッケージ（ａｃｃｅｓｓＣｌａｓｓＩｎＰａｃｋａｇｅ．＊）にアクセス可能であることが設定されている。また、（ｂ）では、全てのライブラリへの動的リンクが可能であることが設定されている。また、（ｃ）では、ファイルシステム上の全てのファイルに対して、読み取り（ｒｅａｄ）及び書き込み（ｗｒｉｔｅ）が可能であることが設定されている。
【００３１】
このように、ポリシー設定ファイル７０内では、セキュリティレベルに対応させてアクセス権限が定義されている。したがって、複合機１では、各ＪＳＤＫアプリ３０に付与された署名３３に対応するセキュリティレベルに応じて、当該ＪＳＤＫアプリ３０のアクセス権限が決定される。
【００３２】
ところで、各セキュリティレベル（Ｌｖ１、Ｌｖ２、Ｌｖ３）は、それぞれＪａｖａ（登録商標）でいうところの保護ドメイン（ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ）を形成する。 図５は、保護ドメインを説明するための図である。保護ドメインとは、ある主体（ここでは、ＪＳＤＫアプリ３０又はＪＳＤＫアプリ３０に含まれるクラスのインスタンス）が現在直接にアクセスできるオブジェクトのセット（すなわち、アクセス権限の集合）であると考えることができる。同図では、ａ．ｃｌａｓｓ及びｂ．ｂ．ｌａｓｓに対しては、保護ドメインＸが適用され、ｃ．ｃｌａｓｓ及びｄ．ｃｌａｓｓに対しては保護ドメインＹが適用される例が示されている。すなわち、ａ．ｃｌａｓｓ及びｂ．ｃｌａｓｓには保護ドメインＸに属する同じアクセス権限が与えられる。また、ｃ．ｃｌａｓｓ及びｄ．ｃｌａｓｓには保護ドメインＹに属する同じアクセス権限が与えられる。なお、同図において、一つの「アクセス権限」は、ポリシー設定ファイル７０における一つのＰｅｒｍｉｓｓｉｏｎエントリと考えればよい。また、一つの「保護ドメイン」は、一つのｇｒａｎｔエントリに対応するものと考えればよい。したがって、本実施の形態における複合機１０では、Ｌｖ１に対応する保護ドメイン、Ｌｖ２に対応する保護ドメイン、及びＬｖ３に対応する保護ドメインが形成される。
【００３３】
図３に戻る、アプリケーション管理ファイル５１は、当該ＪＳＤＫアプリ３０の構成要素やインストール、起動等に必要な情報、及びその他の管理情報等が定義されているファイルであり、例えば、ファイル名によってＪａｒファイル３１に関連付けられている。本実施の形態において、アプリケーション管理ファイル５１は、セキュリティパッチ５２３を含む。セキュリティパッチ５２３は、ポリシー設定ファイル７０内において、静的に設定されているポリシーの定義に対するパッチ（変更情報又は差分情報）である。複合機１０は、ＪＳＤＫアプリ３０の実行に際し、当該ＪＳＤＫアプリ３０に関連付けられているセキュリティパッチ５２３を適用することにより、ポリシー設定ファイル７０の定義を動的に変更させる（以下、斯かる機能を「ポリシー動的変更機能」という。）。
【００３４】
図６は、セキュリティパッチの書式の例を示す図である。同図に示されるように、セキュリティパッチ５２３の書式は、基本的にＪａｖａ（登録商標）標準のポリシーの書式に従う。但し、本実施の形態では、破線で囲まれた部分が拡張されている。すなわち、ｇｒａｎｔエントリ及びｐｅｒｍｉｓｓｉｏｎエントリに対して、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドの付加が可能とされている。
【００３５】
ＣａｌｌｅｄＢｙフィールドでは、当該ＣａｌｌｅｄＢｙフィールドが付与されたエントリ（ｇｒａｎｔエントリ又はｐｅｒｍｉｓｓｉｏｎエントリ）が有効となるタイミングが指定される。当該タイミングは、メソッドの呼び出しによって特定される。ＣａｌｌｅｄＢｙフィールドは、「ＣａｌｌｅｄＢｙ "ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅ．ｔｏ＿ｃｌａｓｓ＿ｎａｍｅ"」の書式で記述される。ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅは、＜呼び出し元のクラス名＞：＜メソッド名＞の書式で記述され、ｔｏ＿ｃｌａｓｓ＿ｎａｍｅは、＜呼び出し先のクラス名＞：＜メソッド名＞の書式で記述される。但し、メソッド名及び呼び出し元のクラス名は省略可能である。
【００３６】
「ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅ．ｔｏ＿ｃｌａｓｓ＿ｎａｍｅ」の書式例と、その意味を以下に示す。
（１）"Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"
この場合、ＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときに当該エントリが有効とされる（ポリシーが変更される）。
（２）"Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄ．Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"
この場合、Ａｐｌｉ１クラスのｄｉｓｐＰａｓｓＷｏｒｄメソッドからＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときに当該エントリが有効とされる。
（３）"Ｐａｓｓｗｏｒｄ"
この場合、Ｐａｓｓｗｏｒｄクラスの全てのメソッドを実行されたときにポリシー変更を行う。
【００３７】
例えば、図７は、ＣａｌｌｅｄＢｙフィールドの記述例を示す図である。同図において、（Ａ）及び（Ｂ）は、実質的に同じことが定義されている。すなわち、ＣａｌｌｅｄＢｙフィールド（図中破線で囲まれた部分）によって、ＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄが呼び出されたときに、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。但し、（Ａ）では、ＣａｌｌｅｄＢｙフィールドはｇｒａｎｔエントリに付与されているため、当該ｇｒａｎｔエントリに他のｐｅｒｍｉｓｓｉｏｎエントリが含まれている場合は、それらにもＣａｌｌｅｄＢｙフィールドの効力が及ぶ。
【００３８】
また、Ｓｔａｔｅフィールドは、当該Ｓｔａｔｅフィールドが付与されたエントリが有効となる複合機１０の状態が指定される。Ｓｔａｔｅフィールドは、「Ｓｔａｔｅ "Ｓｔａｔｅ＿ｎａｍｅ」の書式で記述される。Ｓｔａｔｅ＿ｎａｍｅには、状態を特定する文字列又は数値が記載される。
【００３９】
例えば、状態を識別するためのパラメータが固定的に決められている場合は、以下のように記述することができる。
【００４０】
図８は、Ｓｔａｔｅフィールドの第一の記述例を示す図である。同図において、（Ａ）及び（Ｂ）は、実質的に同じことが定義されている。すなわち、Ｓｔａｔｅフィールド（図中破線で囲まれた部分）によって、予め決められているパラメータの値が「１」である場合は、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。但し、（Ａ）では、Ｓｔａｔｅフィールドはｇｒａｎｔエントリに付与されているため、当該ｇｒａｎｔエントリに他のｐｅｒｍｉｓｓｉｏｎエントリが含まれている場合は、それらにもＳｔａｔｅフィールドの効力が及ぶ。
【００４１】
また、状態を識別するためのパラメータをＳｔａｔｅフィールドの記述において特定したい場合は、以下のように記述してもよい。
【００４２】
図９は、Ｓｔａｔｅフィールドの第二の記述例を示す図である。同図において、Ｓｔａｔｅフィールドは、「Ｓｔａｔｅ Ｃｏｕｎｔｅｒ．Ａ＝＝０」と記述されている。これは、Ｃｏｕｎｔｔｅｒ．Ａというパラメータが０である状態を特定している。すなわち、同図の（Ａ）及び（Ｂ）では、Ｃｏｕｎｔｔｅｒ．Ａというパラメータが０である場合は、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。
【００４３】
なお、本実施の形態では、ＣａｌｌｅｄＢｙフィールドとＳｔａｔｅフィールドとが同一のエントリに対して定義された場合、二つのフィールドのＡＮＤ条件によって当該エントリの有効性が判定されることとする。但し、ＯＲ条件によって判定するようにしてもよい。
【００４４】
以下、複合機１０によって実行される処理手順について説明する。図１０は、ＪＳＤＫアプリ実行時の処理手順を説明するための図である。
【００４５】
ユーザ（例えば、管理者）によって、起動可能なＪＳＤＫアプリ３０（以下、単に「アプリ」という。）の一覧の表示要求がオペレーションパネル２０２を介して入力されると（Ｓ１０１）、ＳＡＳマネージャ３１０は、複合機１０にインストールされ、起動可能な状態にある各アプリに関連付けられているアプリケーション管理ファイル５１を読み込み（Ｓ１０２）、その定義情報に基づいてアプリ一覧画面をオペレーションパネル２０２に表示させる（Ｓ１０３）。
【００４６】
図１１は、アプリケーション管理ファイルの定義例を示す図である。図１１に示される定義例は、ＸＭＬ（eXtensible Markup Language）形式をベースとしたＪＮＬＰ（Java Network Launching Protocol（ＪＳＲ−５６仕様））を拡張した形式によって表現されている。
【００４７】
同図において、アプリケーション管理ファイル５１の定義情報は、＜ｉｎｆｏｒｍａｔｉｏｎ＞タグで囲まれたｉｎｆｏｒｍａｔｉｏｎ要素５１０、及び＜ｒｓｏｕｒｃｅ＞タグで囲まれたｒｅｓｏｕｒｃｅ要素５２０等を含む。
【００４８】
ｉｎｆｏｒｍａｔｉｏｎ要素５１０には、主に、アプリ及び当該アプリの作成者を識別するための情報が記述されている。すなわち、ｔｉｔｌｅ要素５１１には、アプリのタイトル（アプリ名）が記述されている。ｖｅｎｄｏｒ要素５１２、ｔｅｌｅｐｈｏｎｅ要素５１３、ｆａｘ要素５１４、ｅｍａｉｌ要素５１５には、アプリのベンダの名前（ベンダ名）、電話番号、ＦＡＸ番号、メールアドレスが記述されている。また、ｐｒｏｄｕｃｔ−ｉｄ要素５１６、ｄｅｓｃｒｉｐｔｉｏｎ要素５１７、ｉｃｏｎ要素５１８には、アプリのプロダクトＩＤ、アプリに関する説明文、アプリのアイコンファイル名が記述されている。
【００４９】
一方、ｒｅｓｏｕｒｃｅ要素５２０には、アプリの実行に必要なリソースに関する情報が記述されている。例えば、ｊａｒ要素のｈｒｅｆ属性５２１の値として、アプリのＪＡＲファイルのファイル名（パス名）が記述されている。また、ｖｅｒｓｉｏｎ属性５２２の値として、アプリのバージョンが記述されている。
【００５０】
更に、ｓｅｃｕｒｉｔｙ．ｐａｔｃｈ要素の値としてセキュリティパッチ５２３が記述されている。また、ｓｅｃｕｒｉｔｙ．ｐａｔｃｈ要素のｃｏｍｍｅｎｔ属性５２４の値として、セキュリティパッチ５２３に関するコメントが記述されている。なお、セキュリティパッチ５２３の定義内容の詳細については後述する。
【００５１】
ステップＳ１０３では、上記のようなアプリケーション管理ファイル５１のｔｉｔｌｅ要素５１１及びｉｃｏｎ要素５１８に基づいて起動可能な各アプリのアプリ名及びアイコンの一覧がアプリ一覧画面に表示される。
【００５２】
続いて、アプリ一覧画面に表示されたアプリの中から起動対象とされるアプリがユーザによって選択されると（Ｓ１０４）、ＳＡＳマネージャ３１０は、選択されたアプリ（以下、「カレントアプリ」という。）に関連付けられているアプリケーション管理ファイル５１等に基づいてカレントアプリのアプリ設定画面を生成し、オペレーションパネル２０２に表示させる（Ｓ１０５）。
【００５３】
図１２は、アプリ設定画面の表示例を示す図である。同図のアプリ設定画面６１０において、アプリ名、説明、バージョン、プロダクトＩＤ、及び連絡先（電話、Ｆａｘ、ｅｍａｉｌ）の項目については、アプリケーション管理ファイル５１に記述されていた情報がそのまま表示される。
【００５４】
セキュリティ項目６１１及びパフォーマンス項目６１３には、セキュリティレベル及びセキュリティパッチ５２３に関係又は影響する情報（すなわち、カレントアプリのアクセス権限に関する情報）が表示される。同図において、セキュリティ項目６１１には、カレントアプリのセキュリティレベル（レベル３）が表示され、また、パスワードファイルの参照の可否を選択させるチェックボタン６１２が「パスワードファイルを参照」というメッセージと共に表示されている。すなわち、カレントアプリはパスワードファイルを参照する必要があるところ、その許否はチェックボタン６１２によってユーザの判断で選択可能とされている。なお、カレントアプリがレベル３であることは、ＳＡＳマネージャ３１０がカレントアプリの署名３３に基づいて判別する。また、「パスワードファイルを参照」という文字列は、アプリケーション管理ファイル５１のｃｏｍｍｅｎｔ属性５２４に基づいて表示される。また、パスワードファイルは、複合機１０のユーザのアカウント情報が記録されたファイルであり、ポリシー設定ファイル７０においてはレベル３のアプリには読み込み権限は与えられていないリソースの例示である。
【００５５】
また、パフォーマンス項目６１３では、ラジオボタン６１４により、カレントアプリの動作について、セキュリティ優先、最適、及びパフォーマンス優先のいずれかを選択することができる。この選択は、ポリシー設定ファイル７０に定義されているポリシーをカレントアプリにどれだけ忠実に遵守させるかの選択に相当する。セキュリティ優先→最適→パフォーマンス優先の順で、ポリシーに対する忠実度は低下する。但し、そのトレードオフとして性能は向上する。
【００５６】
ユーザによってセキュリティ項目６１１及びパフォーマンス項目６１３に対する設定が行われ、ＯＫボタン６１５がクリックされると（Ｓ１０６）、ＳＡＳマネージャ３１０は、設定内容を複合機１０のメモリ又はＨＤＤ２３３上に保持される所定のパラメータに記録する（Ｓ１０７）。より詳しくは、チェックボタン６１２に対する設定については、パスワードファイルフラグ変数（ｐａｓｓｗｄＦｌａｇ）の値とし記録される。例えば、チェックボタン６１２がチェックされなかった場合（パスワードファイルの参照が許可されない場合）は「０」が、チェックボタン６１２がチェックされた場合（パスワードファイルの参照が許可される場合）は「１」が、パスワードファイルフラグ変数に記録される。また、ラジオボタン６１４に対する設定については、パフォーマンスフラグ変数（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値として記録される。例えば、セキュリティ優先の場合は「１」が、最適の場合は「２」が、パフォーマンス優先の場合は「３」がパフォーマンスフラグ変数に記録される。続いて、ＳＡＳマネージャ３１０からの要求に応じ、ＪＳＤＫプラットフォーム４０のＶＭ４１は、カレントアプリを起動させる（Ｓ１０８）。
【００５７】
続いて、ステップＳ１０８の内容を詳細に説明する。図１３は、ＪＳＤＫアプリの起動処理を説明するための図である。
【００５８】
ステップＳ１０８１において、ＶＭ４１は、カレントアプリのＪＡＲファイル３１をメモリ上に読み込む。この際、ＪＡＲファイル３１に対する署名３３の検証も行われる。すなわち、正当な署名３３であること及びＪＡＲファイル３１が改ざんされていないこと等が検証される。したがって、署名３３が無い場合若しくは不正なものである場合、又はＪＡＲファイル３１が改ざんされていることが検出された場合は、当該ＪＳＤＫアプリ３０の起動は中止される。
【００５９】
続いて、ＶＭ４１は、ポリシー設定ファイル７０よりカレントアプリのセキュリティレベルに対応するポリシー（例えば、Ｌｖ３に対応するｇｒａｎｔエントリ）をオブジェクトとしてロードする（Ｓ１０８２）。
【００６０】
図１４は、オブジェクトとしてロードされたポリシーの例を示す図である。同図において、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、上記した保護ドメインに対応するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎクラスのインスタンスである。ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、ポリシー設定ファイル７０において、カレントアプリのセキュリティレベルに対応するｇｒａｎｔエントリごとにインスタンス化される。
【００６１】
ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２は、その名の通り、Ｐｅｒｍｉｓｓｉｏｎオブジェクトの集合を管理するＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎクラスのインスタンスである。Ｐｅｒｍｉｓｓｉｏｎオブジェクトは、ポリシー設定ファイル７０におけるｐｅｒｍｉｓｓｉｏｎエントリごとに当該エントリによって許可されるアクセス権限に応じた具象クラスに基づいてインスタンス化される。図中では、ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎオブジェクト及びＦｉｌｅＰｅｒｍｉｓｓｉｏｎオブジェクトが例示されている。
【００６２】
同図に示されるように、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１とＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２との間にはポリシー設定ファイル７０における関係に対応した関連が形成される。
【００６３】
続いて、ＶＭ４１は、カレントアプリのＪＡＲファイル３３に含まれるクラス定義をメモリ上に展開し（S１０８３）、当該クラス定義に基づいてカレントアプリをインスタンス化する（Ｓ１０８４）。続いて、ＶＭ４１は、インスタンス化されたカレントアプリを実行する（Ｓ１０８５）。
【００６４】
続いて、図１０及び図１３の処理を経て実行されるアプリについて、セキュリティパッチ５２３が適用されてポリシーが動的に変更される際の処理手順について説明する。
【００６５】
ここで、改めて図１１のアプリケーション管理ファイル５１に含まれているセキュリティパッチ５２３を参照する。当該セキュリティパッチ５２３には、３つのｐｅｒｍｉｓｓｉｏｎエントリが含まれている。
【００６６】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３１の定義は、「permission java.io.FilePermission "Password.txt", "read" ,CalledBy "Password:getPassWord", State passwdFlag==1」というものである。これは、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって当該読み込み権限が許可されるのは、Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときであって、かつ、パスワードフラグ（ｐａｓｓｗｄＦｌａｇ）の値が１である場合（すなわち、アプリ設定画面６１０のチェックボタン６１２がチェックされた場合）であるとされている。
【００６７】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３２の定義は、「permission java.security.AllPermission State performanceFlag==2 , CalledBy "Apli1:init"」というものである。これは、全権限（ＡｌｌＰｅｒｍｉｓｓｉｏｎ）を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって、全権限が許可されるのは、Ａｐｌｉ１：ｉｎｉｔメソッドが呼び出された際であって、かつ、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が２である場合（すなわち、アプリ設定画面６１０のラジオボタン６１３において「最適」が選択された場合）であるとされている。
【００６８】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３３の定義は、「permission java.security.AllPermission State performanceFlag==3 , CalledBy " Apli1:dispPassWord"」というものである。これは、全権限（ＡｌｌＰｅｒｍｉｓｓｉｏｎ）を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって全権限が許可されるのは、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄメソッドが呼び出されたときであって、かつ、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が２である場合（すなわち、アプリ設定画面６１０のラジオボタン６１３において「パフォーマンス優先」が選択された場合）であるとされている。
【００６９】
このように、セキュリティパッチ５２３には、パスワードフラグ及びパフォーマンスフラグといった、アプリ設定画面６１０において設定されるパラメータに対応させて定義がなされている。したがって、ＳＡＳマネージャ３１０は、アプリ設定画面６１０の表示内容を、セキュリティパッチ５２３の記述に基づいて決定するようにしてもよい。
【００７０】
斯かるセキュリティパッチ５２３によるポリシーの動的な変更は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１の状態遷移として把握することができる。図１５は、ポリシーの動的な変更をＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎの状態遷移として示す図である。同図では、アプリ３２に対するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１とＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２とが示されている。アプリ３２は、カレントアプリのインスタンスを示す。
【００７１】
同図において、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｌｖ３、状態ＰＤ＿Ｌｖ３＋、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅ、及び状態ＰＤ＿Ｐｅｒｆｏｒｍａｎｃｅの４つの状態を有する。
【００７２】
状態ＰＤ＿Ｌｖ３はポリシーがセキュリティパッチ５２３によって動的に変更される前の状態である。この場合、通常のＬｖ３に対するアクセス権限が与えられる。
【００７３】
状態ＰＤ＿Ｌｖ３＋は、Ｌｖ３のアクセス権限に加えてパスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられる状態である。この状態への遷移条件は、セキュリティパッチ５２３（図１１）のｐｅｒｍｉｓｓｉｏｎエントリ５２３１に基づいて、Ｐａｓｓｗｏｒｄ．ｇｅｔＰａｓｓｗｏｒｄメソッドが実行中であることである。但し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１におけるＳｔａｔｅエントリによってパスワードファイルフラグが１であることがガード条件となる。
【００７４】
状態ＰＤ＿Ｏｐｔｉｍａｉｚｅは、全アクセス権限が与えられる状態である。この状態への遷移条件は、ｐｅｒｍｉｓｓｉｏｎエントリ５２３２に基づいて、パフォーマンスフラグ（ｐｅｆｏｒｍａｎｃｅＦｌａｇ）が「２」に設定されている状態において、Ａｐｌｉ１：ｉｎｉｔメソッドが実行中であることである。
【００７５】
状態ＰＤ＿Ｐｅｒｆｏｒｍａｎｃｅも全アクセス権限が与えられる状態である。この状態への遷移条件は、ｐｅｒｍｉｓｓｉｏｎエントリ５２３３に基づいて、パフォーマンスフラグ（ｐｅｆｏｒｍａｎｃｅＦｌａｇ）が「３」に設定されている状態において、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄが実行中であることである。
【００７６】
以下、更に具体的に説明する。図１６は、ポリシーが動的に変更される際の処理手順を説明するためのシーケンス図である。同図では、アプリ３２が、パスワードファイルの参照を要求した場合の処理手順について説明する。
【００７７】
同図において、「ａｐｌｉ１：Ａｐｌｉ１」は、カレントアプリ３２のクラス名（Ａｐｌｉ１）及びインスタンの識別名（ａｐｌｉ１）を示す。カレントアプリ３２は、Ｌｖ３の保護ドメインに対するアクセス権限を有する（すなわち、Ｌｖ３のセキュリティレベルが与えられている）。また、Ｐａｓｓｗｏｒｄ４１１及びＰａｓｓＷｏｒｄＡｃｃｅｓｓ４１２は、本実施の形態においてＪＳＤＫプラットフォーム４０に実装されている、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）にアクセスするためのＰａｓｓｗｏｒｄクラス、ＰａｓｓＷｏｒｄＡｃｃｅｓｓクラスのインスタンスである。ＰａｓｓｗｏｒｄクラスはＬｖ２の保護ドメインに対するアクセス権限を有する。ＰａｓｓＷｏｒｄＡｃｃｅｓｓクラスはＬｖ１の保護ドメインに対するアクセス権限を有する。また、ｓｍ：ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、Ｊａｖａ（登録商標）標準のＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスを本実施の形態のために拡張したクラスのインスタンスである。
【００７８】
なお、図示される通り、ポリシー設定ファイル７０の定義において、パスワードファイルに対するアクセス権限としては、Ｌｖ１に対しては読み込み及び書き込み権限が、Ｌｖ２に対しては読み込み権限が許可されている。一方、Ｌｖ３については読み込み及び書き込み権限のいずれも許可されていない。
【００７９】
例えば、カレントアプリ３２のｄｉｓｐＰａｓｓＷｏｒｄメソッドが呼び出されると、
１）当該メソッド内から複合機１０内の記憶装置に記録されているパスワード情報を取得するため、カレントアプリ３２は、Ｐａｓｓｗｏｒｄ４２１のｇｅｔＰａｓｓＷｏｒｄメソッドを呼び出す（Ｓ２０１）。続いて、Ｐａｓｓｗｏｒｄ４２１のｇｅｔＰａｓｓＷｏｒｄメソッド内において、ＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２のｒｅａｄメソッド（パスワードファイルの参照要求）が呼び出される（Ｓ２０２）。ＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２は、パスワードファイルに対して直接アクセスするクラスであるため、ｒｅａｄメソッドの中でｓｍ：ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ４１３のｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎメソッドを呼び出すことにより、パスワードファイルに対する読み込み権限の有無を問い合わせる（Ｓ２０３）。
【００８０】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、カレントアプリ３２に対応するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１をカレントアプリ３２より取得する（Ｓ２０４）。なお、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、スタック情報をトレースすることにより、パスワードファイルにアクセスしようとするカレントアプリ３２（のクラス名）を判別することができる。
【００８１】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、スタック情報をトレースし、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対して、Ａｐｌｉ１：ｄｉｓｐＰａｓｓｗｏｒｄメソッドやＰａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄメソッドが呼び出されたことを通知する（Ｓ２０５）。当該通知に応じて、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、カレントアプリ３２のセキュリティパッチ５２３（図１１参照）に基づいて状態の遷移の要否を判定する。
【００８２】
ここで、セキュリティパッチ５２３のｐｅｒｍｉｓｓｉｏｎエントリ５２３１には、ＣａｌｌｅｄＢｙフィールド（「ＣａｌｌｅｄＢｙ "Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"」）が付与されており、ステップＳ２０５における通知は、当該ＣａｌｌｅｄＢｙフィールドの条件に当てはまる。したがって、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、パスワードファイルフラグ（ｐａｓｓｗｄｆｌａｇ）の値が「１」であれば、自らの状態をＰＤ＿Ｌｖ３から状態ＰＤ＿Ｌｖ３＋へ遷移させ、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１を有効とする。当該状態の遷移は、具体的には、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１に対応するＦｉｌｅＰｅｒｍｉｓｓｉｏｎオブジェクトをＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加することが相当する（Ｓ２０６）。
【００８３】
但し、現在は、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄメソッドの実行中でもある。したがって、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が「３」である場合は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅへ遷移し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３３を有効とする。この場合、ＡｌｌＰｅｒｍｉｓｓｉｏｎオブジェクトがＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加される。
【００８４】
なお、仮に、現在実行中のメソッド（例えば、ステップＳ２０１で呼び出されたメソッド）が「Ａｐｌｉ１：ｉｎｉｔ」であり、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が「２」である場合、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅへ遷移し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３２を有効とする。この場合、ＡｌｌＰｅｒｍｉｓｓｉｏｎオブジェクトがＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加される。
【００８５】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１よりＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２を取得する（Ｓ２０７）。続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に対して、パスワードファイルに対する読み込み権限の有無を問い合わせる（Ｓ２０８）。ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２は、パスワードファイルに対する読み込み権限に対応するＰｅｒｍｉｓｓｉｏｉｎオブジェクトが自らに含まれているか否かを確認することにより、当該読み込み権限の有無を判定する。ここでは、ステップＳ２０６において当該Ｐｅｒｍｉｓｓｉｏｎオブジェクトが追加されている。したがって、当該読み込み権限は有ることを判定結果として応答する（Ｓ２０９）。
【００８６】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対して「Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄ」から退出することを通知する（Ｓ２１０）。当該通知に応じ、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、自らの状態を元（ＰＤ＿Ｌｖ）に戻す（遷移させる）。厳密には、このタイミングでは、「Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄ」から退出していないが、本実施の形態では、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対するイベントはｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３が発行することとしているため、このタイミングで退出が通知される。
【００８７】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、アクセス権限（読み込み権限）が有ることをＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２に通知する（Ｓ２１１）。当該通知に応じ、パスワードファイルが読み込まれる。なお、Ｓ２０９においてアクセスが許可されない旨が返却された場合、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、例外を発行する。当該例外は、カレントアプリ３２に通知される。
【００８８】
なお、上記では、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対するイベントは、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３が発行する例を示しているが、斯かるイベントは、カレントアプリ３２によって発行されてもよい。
【００８９】
上述したように、本実施の形態における複合機１０によれば、ポリシー設定ファイル７０において静的に定義されているポリシーをセキュリティパッチ５２３に基づいて動的に変化させることができる。したがって、プログラムによるアクセス制御の柔軟性を適切に向上させることができる。
【００９０】
なお、本実施の形態では、ＣａｌｌｅｄＢｙフィールドやＳｔａｔｅフィールドによって、当該フィールドが付加されたエントリが有効となる（すなわち、当該エントリに係る権限が与えられる）例について説明した。しかし、ＣａｌｌｅｄＢｙフィールドやＳｔａｔｅフィールドによって当該フィールドが付加されたエントリを無効とする（すなわち、当該エントリに係る権限が剥奪される）ようにしてもよい。この場合、特定の場合に限って、当初与えられていた権限よりも狭い権限しか認められないようにすることができる。
【００９１】
ところで、上記において説明したＪＳＤＫアプリ３０に対するセキュリティ機能又は機構は、ＪＳＤＫアプリ３０の開発から運用までの手順が適切に履行されることにより、より効果的に機能する。そこで、以下において、ＪＳＤＫアプリ３０の開発から運用までの手順（ビジネスモデル）の一例について説明する。
【００９２】
図１７は、ＪＳＤＫアプリの開発から運用までの手順の一例を説明するための図である。
【００９３】
まず、複合機ベンダ（複合機１０のメーカ又は複合機１０の販売及び保守等を行う業者）によってＪＳＤＫプラットフォーム４０と基本機能を実現するためのＪＳＤＫアプリ３０とを含むパッケージ（以下、「ＪＳＤＫパッケージ」という。）が販売される（Ｓ５０１）。なお、ＪＳＤＫパッケージに含まれるＪＳＤＫアプリ３０等には、予め複合機ベンダによって署名３３が付される。ＪＳＤＫパッケージに含まれるＪＳＤＫアプリ３０は、複合機ベンダ自身によって開発されたものであり、信頼度も高いためＬｖ１又はＬｖ２のセキュリティレベルが付与される。
【００９４】
複合機１０のユーザは、ＪＳＤＫパッケージを購入し（Ｓ５０２）、自らの複合機１０に対してＪＳＤＫプラットフォーム４０等のインストール（Ｓ５０３）を行い、必要に応じてＪＳＤＫプラットフォーム４０及びＪＳＤＫアプリ３０等を起動させる（利用する）（Ｓ５０４）。
【００９５】
一方、機能拡張のためのＪＳＤＫアプリ３０を開発するアプリ開発ベンダは、開発用のプラットフォームとしてＪＳＤＫプラットフォーム３０を入手（購入）し、当該ＪＳＤＫプラットフォーム３０上において新たなＪＳＤＫアプリ３０を開発する（Ｓ５０５）。続いて、アプリ開発ベンダは、アプリ開発申請書を作成し（Ｓ５０６）、開発したＪＳＤＫアプリ３０のＪＡＲファイルと共にアプリ開発申請書を複合機ベンダに送付することにより、当該ＪＳＤＫアプリ３０の販売に対する承認の申請を行う（Ｓ５０７）。
【００９６】
図１８は、アプリ開発申請書の一例を示す図である。同図において、アプリ開発申請書は、サービスバンドル、セキュリティレベル、セキュリティパッチ、セキュリティパッチ理由、及びパフォーマンス等の項目を有する。
【００９７】
サービスバンドルは、申請対象のＪＳＤＫアプリ３０（以下、「申請対象アプリ」という。）が利用するサービスバンドル３３０の名前が記載される。セキュリティレベルには、申請対象アプリに対して要求するセキュリティレベルが記載される。セキュリティパッチには、必要に応じて、図６において説明した書式に従ってセキュリティパッチ５２４が記載される。セキュリティパッチ理由は、セキュリティパッチ５２４が必要な理由が記載される。パフォーマンスには、申請対象アプリのパフォーマンスと安全性とのトレードオフを申請する。具体的にはパフォーマンスと安全性との関係を段階分けして、その段階ごとに、セキュリティチェック（アクセス権限のチェック）を無効とするメソッドが記載される。同図では、ａ）安全優先、ｂ）最適、ｃ）パフォーマンス優先の３段階に分けられて記載されている。
【００９８】
複合機ベンダは、承認の申請を受け付けると（Ｓ５０８）、申請対象アプリの評価（テスト）を行う（Ｓ５０９）。当該評価では、申請対象アプリによるリソースの消費量が制限内であるか、また、セキュリティ違反がないか（セキュリティパッチの妥当性等）等が検証される。評価に合格すると、複合機ベンダは申請アプリについて配布用パッケージを作成する（Ｓ５１０）。配布用パッケージは、申請対象アプリのＪＡＲファイルの他にアプリケーション管理ファイル５１等も含まれる。また、当該ＪＡＲファイルには申請されたセキュリティレベルに応じた署名３３が付与される。なお、署名３３及びアプリケーション管理ファイル５１はアプリ開発申請書に基づいて複合機ベンダによって作成される。続いて、複合機ベンダは、配布用パッケージをアプリ開発ベンダに提供する（Ｓ５１１）
アプリ開発ベンダは、配布用パッケージを受理し（Ｓ５１２）、当該配布用パッケージをユーザに販売する（Ｓ５１３）。ユーザは、配布用パッケージを購入すると（Ｓ５１４）、当該配布用パッケージに含まれているＪＳＤＫアプリ３０を複合機１０にインストールし（Ｓ５１５）、起動（Ｓ５１６）、及び操作（Ｓ５１７）を行う。
【００９９】
以上のような手順によれば、アプリ開発ベンダによって開発されるＪＳＤＫアプリ３０は、複合機ベンダの管理下においてセキュリティレベルが付与され、またセキュリティパッチ５２４の適用が許可される。したがって、不正なアプリケーションの実行をより効果的に防止することができる。
【０１００】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１０１】
１０ 複合機
３０ ＪＳＤＫアプリ
４０ ＪＳＤＫプラットフォーム
４１ ＶＭ
５０ ネイティブサービスレイヤ
７０ ポリシー設定ファイル
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２０４ 撮像部
２０５ 印刷部
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３１０ ＳＡＳマネージャ
３２０ アプリケーションバンドル
３２１ スキャンアプリ
３３０ サービスバンドル
３３１ スキャンサービス
３３２ パネルサービス
【先行技術文献】
【特許文献】
【０１０２】
【特許文献１】特開２００５−２６９６１９号公報
【技術分野】
【０００１】
本発明は、情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
近年では、主に複合機又は融合機と呼ばれる画像形成装置において、その出荷後に、公開されたＡＰＩ（Application Program Interface）を利用してＣ言語又はＪａｖａ（登録商標）言語等の汎用的なプログラミング言語による新たなアプリケーションの開発及びインストールが可能とされているものがある（例えば、特許文献１）。斯かる画像形成装置では、当該画像形成装置のベンダによって開発されたアプリケーションのみならず、他のソフトウェアベンダによって開発されたアプリケーションもインストールされ、利用されるといった状況が生じ得る。このような状況の中で、各アプリケーションに対して無条件に画像形成装置のリソース（プログラムやデータ等）に対するアクセスを許可してしまっては機密情報の漏洩や画像形成装置の不正動作等、不測の事態を招きかねない。したがって、各アプリケーションについて適切なセキュリティ管理（アクセス制御）が必要とされる。
【０００３】
Ｊａｖａ（登録商標）アプリケーションについては、Ｊａｖａ（登録商標）の実行環境が標準で備えるセキュリティ機構によってコードベースのアクセス制御を行うことができる。具体的には、ポリシーと呼ばれるデータ内において、プログラムの所在又はプログラムに対する署名者に応じてアクセス権限を設定することが可能である。但し、アプリケーションごと（プログラムごと）に、それぞれポリシーを定義するのは管理者による作業を煩雑化すると同時にポリシーの情報量を肥大化させ性能の劣化を招きかねない。
【０００４】
そこで、例えば、アプリケーションをその信頼度に応じてグループに分類し（レベル分けし）、ポリシー内ではグループ単位で（レベルごとに）アクセス権限を設定することが行われている。この場合、グループの粒度（レベルの段階）が細かすぎるとグループ分けの意味が没却されてしまう。したがって、或る程度大きなくくりによってグループ分けすること（レベルの段階を少なくすること）が効果的である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、或るアプリケーションがその機能を実現するために必要なアクセス権限の範囲の一部が、当該アプリケーションが属するグループに対して許可されるアクセス権限の範囲を超えてしまう場合がある（すなわち、当該一部の権限が認められないと当該アプリケーションの機能を実現できない場合がある。）。但し、当該アプリケーションが属するグループをより大きな範囲でアクセス権限が許可されるグループに変更してしまうと、当該アプリケーションに対する信頼度に対して、与えられる権限が大きすぎてしまうという問題がある。したがって、或る特定のアプリケーションに限って、当該アプリケーションが属するグループには許可されていないアクセス権限を例外的に認めることができる仕組みが必要とされる。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、プログラムに対するアクセス制御の柔軟性を向上させることのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、本発明は、プログラムを有する情報処理装置であってプログラムのアクセス権限情報を管理するアクセス権限情報管理手段とプログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する。
【発明の効果】
【０００８】
本発明によれば、プログラムに対するアクセス制御の柔軟性を向上させることのできる情報処理装置、アクセス制御方法、アクセス制御プログラム、及び記録媒体を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態における複合機のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における複合機のソフトウェア構成例を示す図である。
【図３】本実施の形態におけるＪＳＤＫアプリの構成例を示す図である。
【図４】本実施の形態におけるポリシー設定ファイルの定義例を示す図である。
【図５】保護ドメインを説明するための図である。
【図６】セキュリティパッチの書式の例を示す図である。
【図７】ＣａｌｌｅｄＢｙフィールドの記述例を示す図である。
【図８】Ｓｔａｔｅフィールドの第一の記述例を示す図である。
【図９】Ｓｔａｔｅフィールドの第二の記述例を示す図である。
【図１０】ＪＳＤＫアプリ実行時の処理手順を説明するための図である。
【図１１】アプリケーション管理ファイルの定義例を示す図である。
【図１２】アプリ設定画面の表示例を示す図である。
【図１３】ＪＳＤＫアプリの起動処理を説明するための図である。
【図１４】オブジェクトとしてロードされたポリシーの例を示す図である。
【図１５】ポリシーの動的な変更をＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎの状態遷移として示す図である。
【図１６】ポリシーが動的に変更される際の処理手順を説明するためのシーケンス図である。
【図１７】ＪＳＤＫアプリの開発から運用までの手順の一例を説明するための図である。
【図１８】アプリ開発申請書の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における複合機のハードウェア構成例を示す図である。図１において複合機１０は、コントローラ２０１、オペレーションパネル２０２、ファクシミリコントロールユニット（ＦＣＵ）２０３、撮像部２０４、及び印刷部２０５等を備える。
【００１１】
コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。
【００１２】
ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、複合機１０のシステムメモリである。ＭＥＭ−Ｃ２３２は、複合機１０のローカルメモリである。ＨＤＤ２３３は、複合機１０のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。
【００１３】
オペレーションパネル２０２は、オペレータが複合機１０に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１０から出力を得るためのハードウェア（表示部）である。
【００１４】
図２は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。図２において、複合機１０のソウトウェアは、ＪＳＤＫアプリ３０、ＪＳＤＫプラットフォーム４０、及びネイティブサービスレイヤ５０等より構成されている。これらの各ソフトウェアは、それぞれに実装された処理手順をＣＰＵ２１１に実行させることによりその機能を実現する。
【００１５】
ネイティブサービスレイヤ５０は、複合機１０のハードウェアやソフトウェアに基づく機能を利用させるためのインタフェースを上位モジュールに対して提供し、当該インタフェースの呼び出し（機能の利用要求）に応じて、当該機能を実現するための制御を行う。例えば、ネイティブサービスレイヤ５０には、ネットワーク通信の制御に関するインタフェースを提供するモジュール、ファクシミリの制御に関するインタフェースを提供するモジュール、蓄積文書（ＨＤＤ２３３に保存されている文書（画像）データ）の配信処理の制御に関するインタフェースを提供するモジュール、撮像部２０４や印刷部２０５の制御に関するインタフェースを提供するモジュール。メモリやＨＤＤ２３３等の制御に関するインタフェースを提供するモジュール、オペレーションパネル２０２の制御に関するインタフェースを提供するモジュール、認証処理や課金処理の制御に関するインタフェースを提供するモジュール、ユーザ情報の管理に関するインタフェースを提供するモジュール等が含まれる。
【００１６】
ＪＳＤＫプラットフォーム４０は、ＪＳＤＫアプリ３０の実行環境を提供するソフトウェアプラットフォームであり、ネイティブサービスレイヤ５０に対するＪａｖａ（登録商標）インタフェースを上位モジュールに対して提供する。ＪＳＤＫプラットフォーム４０は、Ｊａｖａ（登録商標）の標準のクラスや、複合機１０用に拡張されたクラスに関するクラスライブラリ、及びＪａｖａ（登録商標）仮想マシン（ＶＭ４１）等を含む。
【００１７】
ＶＭ４１は、Ｊａｖａ（登録商標）バイトコードを逐次解釈しながらＪＳＤＫアプリ３０の実行を制御する。当該制御の一部として、ＶＭ４１は、ポリシー設定ファイル（ｐｏｌｉｃｙ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｉｌｅ）７０に予め定義されたポリシーに基づいて、ＪＳＤＫアプリ３０による、ファイル、ネットワークソケット、及びプリンタ等のリソースへのアクセスを制限する。すなわち、ＶＭ４１は、Ｊａｖａ（登録商標）標準の仕組みとして、リソースへのアクセスが発生する際に、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスのインスタンス（ＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクト）に対する通知が行われるように構成されている。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒオブジェクトは、その呼び出しに応じてポリシー設定ファイル７０に基づいてリソースへのアクセスの可否を判断する。
【００１８】
ところで、ＪＳＤＫプラットフォーム４０は、ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとして実装されている。ＯＳＧｉ（Open Service Gateway initiative）プラットフォームとは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。ＯＳＧｉプラットフォーム上において、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのＪＡＲ（Java ARchive）ファイルによって構成され、それぞれ独立して動的に（装置の再起動を要することなく）インストール可能である。
【００１９】
ＪＳＤＫアプリ３０は、ＪＳＤＫプラットフォーム４０において公開されている専用のＳＤＫ（ソフトウェア開発キット）を使用して作成されたアプリケーション（以下「ＳＤＫアプリ」という。）である。ＳＤＫアプリのうち、特にＪａｖａ（登録商標）言語を使用して開発されたアプリケーションをＪＳＤＫアプリという。
【００２０】
図中では、ＪＳＤＫアプリ３０の例として、ＳＡＳ（SDK Application Service）マネージャ３１、アプリケーションバンドル３２０、及びサービスバンドル３３０等が存在する。ＳＡＳマネージャ３１０は、他のＪＳＤＫアプリ３０（アプリケーションバンドル３２０やサービスバンドル３３０等）のインストール（追加）、アンインストール（削除）、起動、及び起動解除等の制御を行う。
【００２１】
アプリケーションバンドル３２０は、オペレーションパネル２０２に操作画面を表示させ、当該操作画面を介してエンドユーザから直接利用（操作）されるＪＳＤＫアプリ３０としてのバンドルである。図中では、アプリケーションバンドル３２０の一例としてスキャンアプリ３２１が示されている。スキャンアプリ３２１は、撮像部２０４による原稿からの画像の読み取りを実現するアプリケーションである。
【００２２】
サービスバンドル３３０は、アプリケーションバンドル３２０等に対してサービスを提供するためのＪＳＤＫアプリ３０としてのバンドルである。すなわち、サービスバンドル３３０は、アプリケーションバンドル３２０等からの呼び出しに応じて各サービスバンドル３３０に応じた処理を実行し、その処理結果をアプリケーションバンドル３２０等に返却する。図中では、サービスバンドル３３０の一例として、スキャンサービス３３１、及びパネルサービス３３２等が示されている。
【００２３】
スキャンサービス３３１は、画像の読み取り機能に関するサービスを提供する。パネルサービス３３２は、オペレーションパネル２０２の表示制御に関するサービスを提供する。
【００２４】
次に、複合機１０における、ＪＳＤＫアプリ３０に関するセキュリティの管理について説明する。上記したように、ＪＳＤＫアプリ３０は、ＪＳＤＫプラットフォーム４０において効果されているＳＤＫを用いて開発されるＪａｖａ（登録商標）アプリケーションである。したがって、複合機１の出荷後にサードベンダ等によって作成されるアプリケーション等もＪＳＤＫアプリ３０として複合機１にインストールされうる。
【００２５】
そこで、複合機１では、複合機１のリソースに対するアクセス権限の範囲をレベル分け（グループに分類）し（当該レベルを以下「セキュリティレベル」という。）、ＪＳＤＫアプリ３０ごとに、その信頼度に応じたセキュリティレベルを付与することによりコードベースのアクセス制御を実現している。セキュリティレベルは、各ＪＳＤＫアプリ３０に付された署名（電子署名）によって識別可能とされている。
【００２６】
図３は、本実施の形態におけるＪＳＤＫアプリの構成例を示す図である。同図に示されるように、各ＪＳＤＫアプリ３０は、ＪＡＲファイル３１及びアプリケーション管理ファイル５１等のファイルを含む。ここで、ＪＡＲファイル３１に付されている（関連付けられている）署名３３が、セキュリティレベルを識別するための署名に相当する。署名３３は、例えば、ＪＡＲファイル３１のハッシュ値を暗号化したものであり、当該暗号化に用いられた暗号鍵によってセキュリティレベルが識別される。署名３３は、セキュリティレベルの識別の他、ＪＳＤＫアプリ３０の改ざんの有無のチェックにも用いられる。なお、本実施の形態において、セキュリティレベルは、レベル１（Ｌｖ１）、レベル２（Ｌｖ２）、及びレベル３（Ｌｖ３）の３段階の値を有することとする。Ｌｖ１が最もアクセス権限が大きく、Ｌｖ３が最もアクセス権限が小さい。
【００２７】
セキュリティレベルごとのアクセス権限については、Ｊａｖａ（登録商標）標準の仕様に基づいてポリシー設定ファイル７０において定義されている。
【００２８】
図４は、本実施の形態におけるポリシー設定ファイルの定義例を示す図である。同図においてポリシー設定ファイル７０の書式は、Ｊａｖａ（登録商標）標準の仕様に従っているため、書式に関する詳細な説明については省略する。
【００２９】
同図では、３つのｇｒａｎｔエントリが示されている。ｇｒａｎｔエントリ７１のｓｉｎｅｄＢｙフィールドには、Ｌｖ１が指定されている。したがって、ｇｒａｎｔエントリ７１の定義は、セキュリティレベルの値がＬｖ１の署名３３が付されたＪＳＤＫアプリ３０に適用される。同様に、ｇｒａｎｔエントリ７２はＬｖ２の署名３３が付されたＪＳＤＫアプリ３０に、ｇｒａｎｔエントリ７３はＬｖ３の署名３３が付されａｔＪＳＤＫアプリ３０に適用される。
【００３０】
なお、ｇｒａｎｔエントリ７１において、（ａ）では、実行時（Ｌｖ１のＪＳＤＫアプリ３０の実行時）には（ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ）、全てのパッケージ（ａｃｃｅｓｓＣｌａｓｓＩｎＰａｃｋａｇｅ．＊）にアクセス可能であることが設定されている。また、（ｂ）では、全てのライブラリへの動的リンクが可能であることが設定されている。また、（ｃ）では、ファイルシステム上の全てのファイルに対して、読み取り（ｒｅａｄ）及び書き込み（ｗｒｉｔｅ）が可能であることが設定されている。
【００３１】
このように、ポリシー設定ファイル７０内では、セキュリティレベルに対応させてアクセス権限が定義されている。したがって、複合機１では、各ＪＳＤＫアプリ３０に付与された署名３３に対応するセキュリティレベルに応じて、当該ＪＳＤＫアプリ３０のアクセス権限が決定される。
【００３２】
ところで、各セキュリティレベル（Ｌｖ１、Ｌｖ２、Ｌｖ３）は、それぞれＪａｖａ（登録商標）でいうところの保護ドメイン（ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ）を形成する。 図５は、保護ドメインを説明するための図である。保護ドメインとは、ある主体（ここでは、ＪＳＤＫアプリ３０又はＪＳＤＫアプリ３０に含まれるクラスのインスタンス）が現在直接にアクセスできるオブジェクトのセット（すなわち、アクセス権限の集合）であると考えることができる。同図では、ａ．ｃｌａｓｓ及びｂ．ｂ．ｌａｓｓに対しては、保護ドメインＸが適用され、ｃ．ｃｌａｓｓ及びｄ．ｃｌａｓｓに対しては保護ドメインＹが適用される例が示されている。すなわち、ａ．ｃｌａｓｓ及びｂ．ｃｌａｓｓには保護ドメインＸに属する同じアクセス権限が与えられる。また、ｃ．ｃｌａｓｓ及びｄ．ｃｌａｓｓには保護ドメインＹに属する同じアクセス権限が与えられる。なお、同図において、一つの「アクセス権限」は、ポリシー設定ファイル７０における一つのＰｅｒｍｉｓｓｉｏｎエントリと考えればよい。また、一つの「保護ドメイン」は、一つのｇｒａｎｔエントリに対応するものと考えればよい。したがって、本実施の形態における複合機１０では、Ｌｖ１に対応する保護ドメイン、Ｌｖ２に対応する保護ドメイン、及びＬｖ３に対応する保護ドメインが形成される。
【００３３】
図３に戻る、アプリケーション管理ファイル５１は、当該ＪＳＤＫアプリ３０の構成要素やインストール、起動等に必要な情報、及びその他の管理情報等が定義されているファイルであり、例えば、ファイル名によってＪａｒファイル３１に関連付けられている。本実施の形態において、アプリケーション管理ファイル５１は、セキュリティパッチ５２３を含む。セキュリティパッチ５２３は、ポリシー設定ファイル７０内において、静的に設定されているポリシーの定義に対するパッチ（変更情報又は差分情報）である。複合機１０は、ＪＳＤＫアプリ３０の実行に際し、当該ＪＳＤＫアプリ３０に関連付けられているセキュリティパッチ５２３を適用することにより、ポリシー設定ファイル７０の定義を動的に変更させる（以下、斯かる機能を「ポリシー動的変更機能」という。）。
【００３４】
図６は、セキュリティパッチの書式の例を示す図である。同図に示されるように、セキュリティパッチ５２３の書式は、基本的にＪａｖａ（登録商標）標準のポリシーの書式に従う。但し、本実施の形態では、破線で囲まれた部分が拡張されている。すなわち、ｇｒａｎｔエントリ及びｐｅｒｍｉｓｓｉｏｎエントリに対して、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドの付加が可能とされている。
【００３５】
ＣａｌｌｅｄＢｙフィールドでは、当該ＣａｌｌｅｄＢｙフィールドが付与されたエントリ（ｇｒａｎｔエントリ又はｐｅｒｍｉｓｓｉｏｎエントリ）が有効となるタイミングが指定される。当該タイミングは、メソッドの呼び出しによって特定される。ＣａｌｌｅｄＢｙフィールドは、「ＣａｌｌｅｄＢｙ "ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅ．ｔｏ＿ｃｌａｓｓ＿ｎａｍｅ"」の書式で記述される。ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅは、＜呼び出し元のクラス名＞：＜メソッド名＞の書式で記述され、ｔｏ＿ｃｌａｓｓ＿ｎａｍｅは、＜呼び出し先のクラス名＞：＜メソッド名＞の書式で記述される。但し、メソッド名及び呼び出し元のクラス名は省略可能である。
【００３６】
「ｆｒｏｍ＿ｃｌａｓｓ＿ｎａｍｅ．ｔｏ＿ｃｌａｓｓ＿ｎａｍｅ」の書式例と、その意味を以下に示す。
（１）"Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"
この場合、ＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときに当該エントリが有効とされる（ポリシーが変更される）。
（２）"Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄ．Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"
この場合、Ａｐｌｉ１クラスのｄｉｓｐＰａｓｓＷｏｒｄメソッドからＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときに当該エントリが有効とされる。
（３）"Ｐａｓｓｗｏｒｄ"
この場合、Ｐａｓｓｗｏｒｄクラスの全てのメソッドを実行されたときにポリシー変更を行う。
【００３７】
例えば、図７は、ＣａｌｌｅｄＢｙフィールドの記述例を示す図である。同図において、（Ａ）及び（Ｂ）は、実質的に同じことが定義されている。すなわち、ＣａｌｌｅｄＢｙフィールド（図中破線で囲まれた部分）によって、ＰａｓｓｗｏｒｄクラスのｇｅｔＰａｓｓＷｏｒｄが呼び出されたときに、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。但し、（Ａ）では、ＣａｌｌｅｄＢｙフィールドはｇｒａｎｔエントリに付与されているため、当該ｇｒａｎｔエントリに他のｐｅｒｍｉｓｓｉｏｎエントリが含まれている場合は、それらにもＣａｌｌｅｄＢｙフィールドの効力が及ぶ。
【００３８】
また、Ｓｔａｔｅフィールドは、当該Ｓｔａｔｅフィールドが付与されたエントリが有効となる複合機１０の状態が指定される。Ｓｔａｔｅフィールドは、「Ｓｔａｔｅ "Ｓｔａｔｅ＿ｎａｍｅ」の書式で記述される。Ｓｔａｔｅ＿ｎａｍｅには、状態を特定する文字列又は数値が記載される。
【００３９】
例えば、状態を識別するためのパラメータが固定的に決められている場合は、以下のように記述することができる。
【００４０】
図８は、Ｓｔａｔｅフィールドの第一の記述例を示す図である。同図において、（Ａ）及び（Ｂ）は、実質的に同じことが定義されている。すなわち、Ｓｔａｔｅフィールド（図中破線で囲まれた部分）によって、予め決められているパラメータの値が「１」である場合は、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。但し、（Ａ）では、Ｓｔａｔｅフィールドはｇｒａｎｔエントリに付与されているため、当該ｇｒａｎｔエントリに他のｐｅｒｍｉｓｓｉｏｎエントリが含まれている場合は、それらにもＳｔａｔｅフィールドの効力が及ぶ。
【００４１】
また、状態を識別するためのパラメータをＳｔａｔｅフィールドの記述において特定したい場合は、以下のように記述してもよい。
【００４２】
図９は、Ｓｔａｔｅフィールドの第二の記述例を示す図である。同図において、Ｓｔａｔｅフィールドは、「Ｓｔａｔｅ Ｃｏｕｎｔｅｒ．Ａ＝＝０」と記述されている。これは、Ｃｏｕｎｔｔｅｒ．Ａというパラメータが０である状態を特定している。すなわち、同図の（Ａ）及び（Ｂ）では、Ｃｏｕｎｔｔｅｒ．Ａというパラメータが０である場合は、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられることが定義されている。
【００４３】
なお、本実施の形態では、ＣａｌｌｅｄＢｙフィールドとＳｔａｔｅフィールドとが同一のエントリに対して定義された場合、二つのフィールドのＡＮＤ条件によって当該エントリの有効性が判定されることとする。但し、ＯＲ条件によって判定するようにしてもよい。
【００４４】
以下、複合機１０によって実行される処理手順について説明する。図１０は、ＪＳＤＫアプリ実行時の処理手順を説明するための図である。
【００４５】
ユーザ（例えば、管理者）によって、起動可能なＪＳＤＫアプリ３０（以下、単に「アプリ」という。）の一覧の表示要求がオペレーションパネル２０２を介して入力されると（Ｓ１０１）、ＳＡＳマネージャ３１０は、複合機１０にインストールされ、起動可能な状態にある各アプリに関連付けられているアプリケーション管理ファイル５１を読み込み（Ｓ１０２）、その定義情報に基づいてアプリ一覧画面をオペレーションパネル２０２に表示させる（Ｓ１０３）。
【００４６】
図１１は、アプリケーション管理ファイルの定義例を示す図である。図１１に示される定義例は、ＸＭＬ（eXtensible Markup Language）形式をベースとしたＪＮＬＰ（Java Network Launching Protocol（ＪＳＲ−５６仕様））を拡張した形式によって表現されている。
【００４７】
同図において、アプリケーション管理ファイル５１の定義情報は、＜ｉｎｆｏｒｍａｔｉｏｎ＞タグで囲まれたｉｎｆｏｒｍａｔｉｏｎ要素５１０、及び＜ｒｓｏｕｒｃｅ＞タグで囲まれたｒｅｓｏｕｒｃｅ要素５２０等を含む。
【００４８】
ｉｎｆｏｒｍａｔｉｏｎ要素５１０には、主に、アプリ及び当該アプリの作成者を識別するための情報が記述されている。すなわち、ｔｉｔｌｅ要素５１１には、アプリのタイトル（アプリ名）が記述されている。ｖｅｎｄｏｒ要素５１２、ｔｅｌｅｐｈｏｎｅ要素５１３、ｆａｘ要素５１４、ｅｍａｉｌ要素５１５には、アプリのベンダの名前（ベンダ名）、電話番号、ＦＡＸ番号、メールアドレスが記述されている。また、ｐｒｏｄｕｃｔ−ｉｄ要素５１６、ｄｅｓｃｒｉｐｔｉｏｎ要素５１７、ｉｃｏｎ要素５１８には、アプリのプロダクトＩＤ、アプリに関する説明文、アプリのアイコンファイル名が記述されている。
【００４９】
一方、ｒｅｓｏｕｒｃｅ要素５２０には、アプリの実行に必要なリソースに関する情報が記述されている。例えば、ｊａｒ要素のｈｒｅｆ属性５２１の値として、アプリのＪＡＲファイルのファイル名（パス名）が記述されている。また、ｖｅｒｓｉｏｎ属性５２２の値として、アプリのバージョンが記述されている。
【００５０】
更に、ｓｅｃｕｒｉｔｙ．ｐａｔｃｈ要素の値としてセキュリティパッチ５２３が記述されている。また、ｓｅｃｕｒｉｔｙ．ｐａｔｃｈ要素のｃｏｍｍｅｎｔ属性５２４の値として、セキュリティパッチ５２３に関するコメントが記述されている。なお、セキュリティパッチ５２３の定義内容の詳細については後述する。
【００５１】
ステップＳ１０３では、上記のようなアプリケーション管理ファイル５１のｔｉｔｌｅ要素５１１及びｉｃｏｎ要素５１８に基づいて起動可能な各アプリのアプリ名及びアイコンの一覧がアプリ一覧画面に表示される。
【００５２】
続いて、アプリ一覧画面に表示されたアプリの中から起動対象とされるアプリがユーザによって選択されると（Ｓ１０４）、ＳＡＳマネージャ３１０は、選択されたアプリ（以下、「カレントアプリ」という。）に関連付けられているアプリケーション管理ファイル５１等に基づいてカレントアプリのアプリ設定画面を生成し、オペレーションパネル２０２に表示させる（Ｓ１０５）。
【００５３】
図１２は、アプリ設定画面の表示例を示す図である。同図のアプリ設定画面６１０において、アプリ名、説明、バージョン、プロダクトＩＤ、及び連絡先（電話、Ｆａｘ、ｅｍａｉｌ）の項目については、アプリケーション管理ファイル５１に記述されていた情報がそのまま表示される。
【００５４】
セキュリティ項目６１１及びパフォーマンス項目６１３には、セキュリティレベル及びセキュリティパッチ５２３に関係又は影響する情報（すなわち、カレントアプリのアクセス権限に関する情報）が表示される。同図において、セキュリティ項目６１１には、カレントアプリのセキュリティレベル（レベル３）が表示され、また、パスワードファイルの参照の可否を選択させるチェックボタン６１２が「パスワードファイルを参照」というメッセージと共に表示されている。すなわち、カレントアプリはパスワードファイルを参照する必要があるところ、その許否はチェックボタン６１２によってユーザの判断で選択可能とされている。なお、カレントアプリがレベル３であることは、ＳＡＳマネージャ３１０がカレントアプリの署名３３に基づいて判別する。また、「パスワードファイルを参照」という文字列は、アプリケーション管理ファイル５１のｃｏｍｍｅｎｔ属性５２４に基づいて表示される。また、パスワードファイルは、複合機１０のユーザのアカウント情報が記録されたファイルであり、ポリシー設定ファイル７０においてはレベル３のアプリには読み込み権限は与えられていないリソースの例示である。
【００５５】
また、パフォーマンス項目６１３では、ラジオボタン６１４により、カレントアプリの動作について、セキュリティ優先、最適、及びパフォーマンス優先のいずれかを選択することができる。この選択は、ポリシー設定ファイル７０に定義されているポリシーをカレントアプリにどれだけ忠実に遵守させるかの選択に相当する。セキュリティ優先→最適→パフォーマンス優先の順で、ポリシーに対する忠実度は低下する。但し、そのトレードオフとして性能は向上する。
【００５６】
ユーザによってセキュリティ項目６１１及びパフォーマンス項目６１３に対する設定が行われ、ＯＫボタン６１５がクリックされると（Ｓ１０６）、ＳＡＳマネージャ３１０は、設定内容を複合機１０のメモリ又はＨＤＤ２３３上に保持される所定のパラメータに記録する（Ｓ１０７）。より詳しくは、チェックボタン６１２に対する設定については、パスワードファイルフラグ変数（ｐａｓｓｗｄＦｌａｇ）の値とし記録される。例えば、チェックボタン６１２がチェックされなかった場合（パスワードファイルの参照が許可されない場合）は「０」が、チェックボタン６１２がチェックされた場合（パスワードファイルの参照が許可される場合）は「１」が、パスワードファイルフラグ変数に記録される。また、ラジオボタン６１４に対する設定については、パフォーマンスフラグ変数（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値として記録される。例えば、セキュリティ優先の場合は「１」が、最適の場合は「２」が、パフォーマンス優先の場合は「３」がパフォーマンスフラグ変数に記録される。続いて、ＳＡＳマネージャ３１０からの要求に応じ、ＪＳＤＫプラットフォーム４０のＶＭ４１は、カレントアプリを起動させる（Ｓ１０８）。
【００５７】
続いて、ステップＳ１０８の内容を詳細に説明する。図１３は、ＪＳＤＫアプリの起動処理を説明するための図である。
【００５８】
ステップＳ１０８１において、ＶＭ４１は、カレントアプリのＪＡＲファイル３１をメモリ上に読み込む。この際、ＪＡＲファイル３１に対する署名３３の検証も行われる。すなわち、正当な署名３３であること及びＪＡＲファイル３１が改ざんされていないこと等が検証される。したがって、署名３３が無い場合若しくは不正なものである場合、又はＪＡＲファイル３１が改ざんされていることが検出された場合は、当該ＪＳＤＫアプリ３０の起動は中止される。
【００５９】
続いて、ＶＭ４１は、ポリシー設定ファイル７０よりカレントアプリのセキュリティレベルに対応するポリシー（例えば、Ｌｖ３に対応するｇｒａｎｔエントリ）をオブジェクトとしてロードする（Ｓ１０８２）。
【００６０】
図１４は、オブジェクトとしてロードされたポリシーの例を示す図である。同図において、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、上記した保護ドメインに対応するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎクラスのインスタンスである。ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、ポリシー設定ファイル７０において、カレントアプリのセキュリティレベルに対応するｇｒａｎｔエントリごとにインスタンス化される。
【００６１】
ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２は、その名の通り、Ｐｅｒｍｉｓｓｉｏｎオブジェクトの集合を管理するＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎクラスのインスタンスである。Ｐｅｒｍｉｓｓｉｏｎオブジェクトは、ポリシー設定ファイル７０におけるｐｅｒｍｉｓｓｉｏｎエントリごとに当該エントリによって許可されるアクセス権限に応じた具象クラスに基づいてインスタンス化される。図中では、ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎオブジェクト及びＦｉｌｅＰｅｒｍｉｓｓｉｏｎオブジェクトが例示されている。
【００６２】
同図に示されるように、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１とＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２との間にはポリシー設定ファイル７０における関係に対応した関連が形成される。
【００６３】
続いて、ＶＭ４１は、カレントアプリのＪＡＲファイル３３に含まれるクラス定義をメモリ上に展開し（S１０８３）、当該クラス定義に基づいてカレントアプリをインスタンス化する（Ｓ１０８４）。続いて、ＶＭ４１は、インスタンス化されたカレントアプリを実行する（Ｓ１０８５）。
【００６４】
続いて、図１０及び図１３の処理を経て実行されるアプリについて、セキュリティパッチ５２３が適用されてポリシーが動的に変更される際の処理手順について説明する。
【００６５】
ここで、改めて図１１のアプリケーション管理ファイル５１に含まれているセキュリティパッチ５２３を参照する。当該セキュリティパッチ５２３には、３つのｐｅｒｍｉｓｓｉｏｎエントリが含まれている。
【００６６】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３１の定義は、「permission java.io.FilePermission "Password.txt", "read" ,CalledBy "Password:getPassWord", State passwdFlag==1」というものである。これは、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって当該読み込み権限が許可されるのは、Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄメソッドが呼び出されたときであって、かつ、パスワードフラグ（ｐａｓｓｗｄＦｌａｇ）の値が１である場合（すなわち、アプリ設定画面６１０のチェックボタン６１２がチェックされた場合）であるとされている。
【００６７】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３２の定義は、「permission java.security.AllPermission State performanceFlag==2 , CalledBy "Apli1:init"」というものである。これは、全権限（ＡｌｌＰｅｒｍｉｓｓｉｏｎ）を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって、全権限が許可されるのは、Ａｐｌｉ１：ｉｎｉｔメソッドが呼び出された際であって、かつ、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が２である場合（すなわち、アプリ設定画面６１０のラジオボタン６１３において「最適」が選択された場合）であるとされている。
【００６８】
ｐｅｒｍｉｓｓｉｏｎエントリ５２３３の定義は、「permission java.security.AllPermission State performanceFlag==3 , CalledBy " Apli1:dispPassWord"」というものである。これは、全権限（ＡｌｌＰｅｒｍｉｓｓｉｏｎ）を許可する定義に相当する。但し、ＣａｌｌｅｄＢｙフィールド及びＳｔａｔｅフィールドによって全権限が許可されるのは、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄメソッドが呼び出されたときであって、かつ、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が２である場合（すなわち、アプリ設定画面６１０のラジオボタン６１３において「パフォーマンス優先」が選択された場合）であるとされている。
【００６９】
このように、セキュリティパッチ５２３には、パスワードフラグ及びパフォーマンスフラグといった、アプリ設定画面６１０において設定されるパラメータに対応させて定義がなされている。したがって、ＳＡＳマネージャ３１０は、アプリ設定画面６１０の表示内容を、セキュリティパッチ５２３の記述に基づいて決定するようにしてもよい。
【００７０】
斯かるセキュリティパッチ５２３によるポリシーの動的な変更は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１の状態遷移として把握することができる。図１５は、ポリシーの動的な変更をＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎの状態遷移として示す図である。同図では、アプリ３２に対するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１とＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２とが示されている。アプリ３２は、カレントアプリのインスタンスを示す。
【００７１】
同図において、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｌｖ３、状態ＰＤ＿Ｌｖ３＋、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅ、及び状態ＰＤ＿Ｐｅｒｆｏｒｍａｎｃｅの４つの状態を有する。
【００７２】
状態ＰＤ＿Ｌｖ３はポリシーがセキュリティパッチ５２３によって動的に変更される前の状態である。この場合、通常のＬｖ３に対するアクセス権限が与えられる。
【００７３】
状態ＰＤ＿Ｌｖ３＋は、Ｌｖ３のアクセス権限に加えてパスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）の読み込み権限が与えられる状態である。この状態への遷移条件は、セキュリティパッチ５２３（図１１）のｐｅｒｍｉｓｓｉｏｎエントリ５２３１に基づいて、Ｐａｓｓｗｏｒｄ．ｇｅｔＰａｓｓｗｏｒｄメソッドが実行中であることである。但し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１におけるＳｔａｔｅエントリによってパスワードファイルフラグが１であることがガード条件となる。
【００７４】
状態ＰＤ＿Ｏｐｔｉｍａｉｚｅは、全アクセス権限が与えられる状態である。この状態への遷移条件は、ｐｅｒｍｉｓｓｉｏｎエントリ５２３２に基づいて、パフォーマンスフラグ（ｐｅｆｏｒｍａｎｃｅＦｌａｇ）が「２」に設定されている状態において、Ａｐｌｉ１：ｉｎｉｔメソッドが実行中であることである。
【００７５】
状態ＰＤ＿Ｐｅｒｆｏｒｍａｎｃｅも全アクセス権限が与えられる状態である。この状態への遷移条件は、ｐｅｒｍｉｓｓｉｏｎエントリ５２３３に基づいて、パフォーマンスフラグ（ｐｅｆｏｒｍａｎｃｅＦｌａｇ）が「３」に設定されている状態において、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄが実行中であることである。
【００７６】
以下、更に具体的に説明する。図１６は、ポリシーが動的に変更される際の処理手順を説明するためのシーケンス図である。同図では、アプリ３２が、パスワードファイルの参照を要求した場合の処理手順について説明する。
【００７７】
同図において、「ａｐｌｉ１：Ａｐｌｉ１」は、カレントアプリ３２のクラス名（Ａｐｌｉ１）及びインスタンの識別名（ａｐｌｉ１）を示す。カレントアプリ３２は、Ｌｖ３の保護ドメインに対するアクセス権限を有する（すなわち、Ｌｖ３のセキュリティレベルが与えられている）。また、Ｐａｓｓｗｏｒｄ４１１及びＰａｓｓＷｏｒｄＡｃｃｅｓｓ４１２は、本実施の形態においてＪＳＤＫプラットフォーム４０に実装されている、パスワードファイル（Ｐａｓｓｗｏｒｄ．ｔｘｔ）にアクセスするためのＰａｓｓｗｏｒｄクラス、ＰａｓｓＷｏｒｄＡｃｃｅｓｓクラスのインスタンスである。ＰａｓｓｗｏｒｄクラスはＬｖ２の保護ドメインに対するアクセス権限を有する。ＰａｓｓＷｏｒｄＡｃｃｅｓｓクラスはＬｖ１の保護ドメインに対するアクセス権限を有する。また、ｓｍ：ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、Ｊａｖａ（登録商標）標準のＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスを本実施の形態のために拡張したクラスのインスタンスである。
【００７８】
なお、図示される通り、ポリシー設定ファイル７０の定義において、パスワードファイルに対するアクセス権限としては、Ｌｖ１に対しては読み込み及び書き込み権限が、Ｌｖ２に対しては読み込み権限が許可されている。一方、Ｌｖ３については読み込み及び書き込み権限のいずれも許可されていない。
【００７９】
例えば、カレントアプリ３２のｄｉｓｐＰａｓｓＷｏｒｄメソッドが呼び出されると、
１）当該メソッド内から複合機１０内の記憶装置に記録されているパスワード情報を取得するため、カレントアプリ３２は、Ｐａｓｓｗｏｒｄ４２１のｇｅｔＰａｓｓＷｏｒｄメソッドを呼び出す（Ｓ２０１）。続いて、Ｐａｓｓｗｏｒｄ４２１のｇｅｔＰａｓｓＷｏｒｄメソッド内において、ＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２のｒｅａｄメソッド（パスワードファイルの参照要求）が呼び出される（Ｓ２０２）。ＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２は、パスワードファイルに対して直接アクセスするクラスであるため、ｒｅａｄメソッドの中でｓｍ：ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ４１３のｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎメソッドを呼び出すことにより、パスワードファイルに対する読み込み権限の有無を問い合わせる（Ｓ２０３）。
【００８０】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、カレントアプリ３２に対応するＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１をカレントアプリ３２より取得する（Ｓ２０４）。なお、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、スタック情報をトレースすることにより、パスワードファイルにアクセスしようとするカレントアプリ３２（のクラス名）を判別することができる。
【００８１】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、スタック情報をトレースし、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対して、Ａｐｌｉ１：ｄｉｓｐＰａｓｓｗｏｒｄメソッドやＰａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄメソッドが呼び出されたことを通知する（Ｓ２０５）。当該通知に応じて、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、カレントアプリ３２のセキュリティパッチ５２３（図１１参照）に基づいて状態の遷移の要否を判定する。
【００８２】
ここで、セキュリティパッチ５２３のｐｅｒｍｉｓｓｉｏｎエントリ５２３１には、ＣａｌｌｅｄＢｙフィールド（「ＣａｌｌｅｄＢｙ "Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓＷｏｒｄ"」）が付与されており、ステップＳ２０５における通知は、当該ＣａｌｌｅｄＢｙフィールドの条件に当てはまる。したがって、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、パスワードファイルフラグ（ｐａｓｓｗｄｆｌａｇ）の値が「１」であれば、自らの状態をＰＤ＿Ｌｖ３から状態ＰＤ＿Ｌｖ３＋へ遷移させ、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１を有効とする。当該状態の遷移は、具体的には、ｐｅｒｍｉｓｓｉｏｎエントリ５２３１に対応するＦｉｌｅＰｅｒｍｉｓｓｉｏｎオブジェクトをＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加することが相当する（Ｓ２０６）。
【００８３】
但し、現在は、Ａｐｌｉ１：ｄｉｓｐＰａｓｓＷｏｒｄメソッドの実行中でもある。したがって、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が「３」である場合は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅへ遷移し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３３を有効とする。この場合、ＡｌｌＰｅｒｍｉｓｓｉｏｎオブジェクトがＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加される。
【００８４】
なお、仮に、現在実行中のメソッド（例えば、ステップＳ２０１で呼び出されたメソッド）が「Ａｐｌｉ１：ｉｎｉｔ」であり、パフォーマンスフラグ（ｐｅｒｆｏｒｍａｎｃｅＦｌａｇ）の値が「２」である場合、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、状態ＰＤ＿Ｏｐｔｉｍａｉｚｅへ遷移し、ｐｅｒｍｉｓｓｉｏｎエントリ５２３２を有効とする。この場合、ＡｌｌＰｅｒｍｉｓｓｉｏｎオブジェクトがＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に追加される。
【００８５】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１よりＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２を取得する（Ｓ２０７）。続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２に対して、パスワードファイルに対する読み込み権限の有無を問い合わせる（Ｓ２０８）。ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ４１２は、パスワードファイルに対する読み込み権限に対応するＰｅｒｍｉｓｓｉｏｉｎオブジェクトが自らに含まれているか否かを確認することにより、当該読み込み権限の有無を判定する。ここでは、ステップＳ２０６において当該Ｐｅｒｍｉｓｓｉｏｎオブジェクトが追加されている。したがって、当該読み込み権限は有ることを判定結果として応答する（Ｓ２０９）。
【００８６】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対して「Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄ」から退出することを通知する（Ｓ２１０）。当該通知に応じ、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１は、自らの状態を元（ＰＤ＿Ｌｖ）に戻す（遷移させる）。厳密には、このタイミングでは、「Ｐａｓｓｗｏｒｄ：ｇｅｔＰａｓｓｗｏｒｄ」から退出していないが、本実施の形態では、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対するイベントはｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３が発行することとしているため、このタイミングで退出が通知される。
【００８７】
続いて、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、アクセス権限（読み込み権限）が有ることをＰａｓｓｗｏｒｄＡｃｃｅｓｓ４２２に通知する（Ｓ２１１）。当該通知に応じ、パスワードファイルが読み込まれる。なお、Ｓ２０９においてアクセスが許可されない旨が返却された場合、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３は、例外を発行する。当該例外は、カレントアプリ３２に通知される。
【００８８】
なお、上記では、ＰｒｏｔｅｃｔｉｏｎＤｏｍａｉｎ４１１に対するイベントは、ｓｍ：ＳｅｃｃｕｒｉｔｙＭａｎａｇｅｒ４１３が発行する例を示しているが、斯かるイベントは、カレントアプリ３２によって発行されてもよい。
【００８９】
上述したように、本実施の形態における複合機１０によれば、ポリシー設定ファイル７０において静的に定義されているポリシーをセキュリティパッチ５２３に基づいて動的に変化させることができる。したがって、プログラムによるアクセス制御の柔軟性を適切に向上させることができる。
【００９０】
なお、本実施の形態では、ＣａｌｌｅｄＢｙフィールドやＳｔａｔｅフィールドによって、当該フィールドが付加されたエントリが有効となる（すなわち、当該エントリに係る権限が与えられる）例について説明した。しかし、ＣａｌｌｅｄＢｙフィールドやＳｔａｔｅフィールドによって当該フィールドが付加されたエントリを無効とする（すなわち、当該エントリに係る権限が剥奪される）ようにしてもよい。この場合、特定の場合に限って、当初与えられていた権限よりも狭い権限しか認められないようにすることができる。
【００９１】
ところで、上記において説明したＪＳＤＫアプリ３０に対するセキュリティ機能又は機構は、ＪＳＤＫアプリ３０の開発から運用までの手順が適切に履行されることにより、より効果的に機能する。そこで、以下において、ＪＳＤＫアプリ３０の開発から運用までの手順（ビジネスモデル）の一例について説明する。
【００９２】
図１７は、ＪＳＤＫアプリの開発から運用までの手順の一例を説明するための図である。
【００９３】
まず、複合機ベンダ（複合機１０のメーカ又は複合機１０の販売及び保守等を行う業者）によってＪＳＤＫプラットフォーム４０と基本機能を実現するためのＪＳＤＫアプリ３０とを含むパッケージ（以下、「ＪＳＤＫパッケージ」という。）が販売される（Ｓ５０１）。なお、ＪＳＤＫパッケージに含まれるＪＳＤＫアプリ３０等には、予め複合機ベンダによって署名３３が付される。ＪＳＤＫパッケージに含まれるＪＳＤＫアプリ３０は、複合機ベンダ自身によって開発されたものであり、信頼度も高いためＬｖ１又はＬｖ２のセキュリティレベルが付与される。
【００９４】
複合機１０のユーザは、ＪＳＤＫパッケージを購入し（Ｓ５０２）、自らの複合機１０に対してＪＳＤＫプラットフォーム４０等のインストール（Ｓ５０３）を行い、必要に応じてＪＳＤＫプラットフォーム４０及びＪＳＤＫアプリ３０等を起動させる（利用する）（Ｓ５０４）。
【００９５】
一方、機能拡張のためのＪＳＤＫアプリ３０を開発するアプリ開発ベンダは、開発用のプラットフォームとしてＪＳＤＫプラットフォーム３０を入手（購入）し、当該ＪＳＤＫプラットフォーム３０上において新たなＪＳＤＫアプリ３０を開発する（Ｓ５０５）。続いて、アプリ開発ベンダは、アプリ開発申請書を作成し（Ｓ５０６）、開発したＪＳＤＫアプリ３０のＪＡＲファイルと共にアプリ開発申請書を複合機ベンダに送付することにより、当該ＪＳＤＫアプリ３０の販売に対する承認の申請を行う（Ｓ５０７）。
【００９６】
図１８は、アプリ開発申請書の一例を示す図である。同図において、アプリ開発申請書は、サービスバンドル、セキュリティレベル、セキュリティパッチ、セキュリティパッチ理由、及びパフォーマンス等の項目を有する。
【００９７】
サービスバンドルは、申請対象のＪＳＤＫアプリ３０（以下、「申請対象アプリ」という。）が利用するサービスバンドル３３０の名前が記載される。セキュリティレベルには、申請対象アプリに対して要求するセキュリティレベルが記載される。セキュリティパッチには、必要に応じて、図６において説明した書式に従ってセキュリティパッチ５２４が記載される。セキュリティパッチ理由は、セキュリティパッチ５２４が必要な理由が記載される。パフォーマンスには、申請対象アプリのパフォーマンスと安全性とのトレードオフを申請する。具体的にはパフォーマンスと安全性との関係を段階分けして、その段階ごとに、セキュリティチェック（アクセス権限のチェック）を無効とするメソッドが記載される。同図では、ａ）安全優先、ｂ）最適、ｃ）パフォーマンス優先の３段階に分けられて記載されている。
【００９８】
複合機ベンダは、承認の申請を受け付けると（Ｓ５０８）、申請対象アプリの評価（テスト）を行う（Ｓ５０９）。当該評価では、申請対象アプリによるリソースの消費量が制限内であるか、また、セキュリティ違反がないか（セキュリティパッチの妥当性等）等が検証される。評価に合格すると、複合機ベンダは申請アプリについて配布用パッケージを作成する（Ｓ５１０）。配布用パッケージは、申請対象アプリのＪＡＲファイルの他にアプリケーション管理ファイル５１等も含まれる。また、当該ＪＡＲファイルには申請されたセキュリティレベルに応じた署名３３が付与される。なお、署名３３及びアプリケーション管理ファイル５１はアプリ開発申請書に基づいて複合機ベンダによって作成される。続いて、複合機ベンダは、配布用パッケージをアプリ開発ベンダに提供する（Ｓ５１１）
アプリ開発ベンダは、配布用パッケージを受理し（Ｓ５１２）、当該配布用パッケージをユーザに販売する（Ｓ５１３）。ユーザは、配布用パッケージを購入すると（Ｓ５１４）、当該配布用パッケージに含まれているＪＳＤＫアプリ３０を複合機１０にインストールし（Ｓ５１５）、起動（Ｓ５１６）、及び操作（Ｓ５１７）を行う。
【００９９】
以上のような手順によれば、アプリ開発ベンダによって開発されるＪＳＤＫアプリ３０は、複合機ベンダの管理下においてセキュリティレベルが付与され、またセキュリティパッチ５２４の適用が許可される。したがって、不正なアプリケーションの実行をより効果的に防止することができる。
【０１００】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１０１】
１０ 複合機
３０ ＪＳＤＫアプリ
４０ ＪＳＤＫプラットフォーム
４１ ＶＭ
５０ ネイティブサービスレイヤ
７０ ポリシー設定ファイル
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２０４ 撮像部
２０５ 印刷部
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３１０ ＳＡＳマネージャ
３２０ アプリケーションバンドル
３２１ スキャンアプリ
３３０ サービスバンドル
３３１ スキャンサービス
３３２ パネルサービス
【先行技術文献】
【特許文献】
【０１０２】
【特許文献１】特開２００５−２６９６１９号公報
【特許請求の範囲】
【請求項１】
プログラムを有する情報処理装置であって、
プログラムのアクセス権限情報を管理するアクセス権限情報管理手段と、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する情報処理装置。
【請求項２】
前記アクセス権限変更手段は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項１記載の情報処理装置。
【請求項３】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項２記載の情報処理装置。
【請求項４】
プログラムを有する情報処理装置が実行するアクセス制御方法であって、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手順と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報が定義されたアクセス権限変更情報に基づいて、当該情報処理装置が有するアクセス権限情報管理手段が管理する、プログラムのアクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手順とを有するアクセス制御方法。
【請求項５】
前記アクセス権限変更手順は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項４記載のアクセス制御方法。
【請求項６】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項５記載のアクセス制御方法。
【請求項７】
プログラムを有する情報処理装置に、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手順と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報が定義されたアクセス権限変更情報に基づいて、当該情報処理装置が有するアクセス権限情報管理手段が管理する、プログラムのアクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手順とを実行させるためのアクセス制御プログラム。
【請求項８】
前記アクセス権限変更手順は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項７記載のアクセス制御プログラム。
【請求項９】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項８記載のアクセス制御プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載のアクセス制御プログラムを記録したコンピュータ読取可能な記録媒体。
【請求項１】
プログラムを有する情報処理装置であって、
プログラムのアクセス権限情報を管理するアクセス権限情報管理手段と、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手段と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報に基づいて、前記アクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手段とを有する情報処理装置。
【請求項２】
前記アクセス権限変更手段は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項１記載の情報処理装置。
【請求項３】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項２記載の情報処理装置。
【請求項４】
プログラムを有する情報処理装置が実行するアクセス制御方法であって、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手順と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報が定義されたアクセス権限変更情報に基づいて、当該情報処理装置が有するアクセス権限情報管理手段が管理する、プログラムのアクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手順とを有するアクセス制御方法。
【請求項５】
前記アクセス権限変更手順は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項４記載のアクセス制御方法。
【請求項６】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項５記載のアクセス制御方法。
【請求項７】
プログラムを有する情報処理装置に、
プログラムのアクセス権限に関する設定を行うための設定画面を表示させる設定画面表示手順と、
前記設定画面を介して受け付けた設定内容に対応したアクセス権限の変更情報が定義されたアクセス権限変更情報に基づいて、当該情報処理装置が有するアクセス権限情報管理手段が管理する、プログラムのアクセス権限情報で許可されているアクセス権限の範囲を変更するアクセス権限変更手順とを実行させるためのアクセス制御プログラム。
【請求項８】
前記アクセス権限変更手順は、所定のタイミングで、前記アクセス権限情報で許可されているアクセス権限の範囲を変更する請求項７記載のアクセス制御プログラム。
【請求項９】
前記所定のタイミングは、前記プログラムの起動若しくは実行時、又は当該情報処理装置の状態に応じて定まる請求項８記載のアクセス制御プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載のアクセス制御プログラムを記録したコンピュータ読取可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−２２６７６５（Ｐ２０１２−２２６７６５Ａ）
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願番号】特願２０１２−１５０７７３（Ｐ２０１２−１５０７７３）
【出願日】平成２４年７月４日（２０１２．７．４）
【分割の表示】特願２００８−１１８６１９（Ｐ２００８−１１８６１９）の分割
【原出願日】平成２０年４月３０日（２００８．４．３０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願日】平成２４年７月４日（２０１２．７．４）
【分割の表示】特願２００８−１１８６１９（Ｐ２００８−１１８６１９）の分割
【原出願日】平成２０年４月３０日（２００８．４．３０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]