(57)【特許請求の範囲】
【請求項１】
複数の項目より構成される情報に関する操作の許否を判定する情報処理装置であって、
前記項目のカテゴリ分けが定義された分類情報を記憶する分類情報記憶手段と、
前記カテゴリと操作との組み合わせごとに、当該カテゴリに対する当該操作の権限を示す権限名を記憶する権限名記憶手段と、
前記各情報に対して、操作主体ごとに前記権限名の一覧が設定された制御情報を記憶する制御情報記憶手段と、
操作の対象とされた項目が属するカテゴリを前記分類情報に基づいて判定するカテゴリ判定手段と、
操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記権限名の一覧に、前記カテゴリ判定手段によって判定されたカテゴリと当該操作との組み合わせに対して前記権限名記憶手段が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定する許否判定手段とを有することを特徴とする情報処理装置。
【請求項２】
前記権限名の一覧ごとに当該一覧に対する識別名を記憶する一覧識別名記憶手段を有し、
前記制御情報には、前記各情報に対して操作主体ごとに前記識別名が設定され、
前記許否判定手段は、操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記識別名に対して前記一覧識別名記憶手段が記憶する前記権限名の一覧に、前記カテゴリ判定手段によって判定されたカテゴリと当該操作との組み合わせに対して前記権限名記憶手段が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記権限名記憶手段は、前記項目又は前記カテゴリと操作との組み合わせごとに、当該項目又は当該カテゴリに対する当該操作の権限を示す前記権限名を記憶し、
前記許否判定手段は、前記カテゴリ判定手段によって、操作の対象とされた項目が属するカテゴリが存在しないと判定される場合は、当該操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記権限名の一覧に、当該操作の対象とされた項目と当該操作との組み合わせに対して前記権限名記憶部が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定することを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
前記分類情報には、前記カテゴリが再帰的に定義されていることを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
【請求項５】
前記分類情報は、前記カテゴリの再帰的な関係が展開されて定義されていることを特徴とする請求項４記載の情報処理装置。
【請求項６】
情報処理装置が複数の項目より構成される情報に関する操作の許否を判定する情報処理方法であって、
前記項目のカテゴリ分けが定義された分類情報を記憶する分類情報記憶手段と、
前記カテゴリと操作との組み合わせごとに、当該カテゴリに対する当該操作の権限を示す権限名を記憶する権限名記憶手段と、
前記各情報に対して、操作主体ごとに前記権限名の一覧が設定された制御情報を記憶する制御情報記憶手段とを用いて、
操作の対象とされた項目が属するカテゴリを前記分類情報に基づいて判定するカテゴリ判定手順と、
操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記権限名の一覧に、前記カテゴリ判定手順において判定されたカテゴリと当該操作との組み合わせに対して前記権限名記憶手段が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定する許否判定手順とを前記情報処理装置が実行することを特徴とする情報処理方法。
【請求項７】
前記権限名の一覧ごとに当該一覧に対する識別名を記憶する一覧識別名記憶手段を更に用いて、
前記制御情報には、前記各情報に対して操作主体ごとに前記識別名が設定され、
前記許否判定手順は、操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記識別名に対して前記一覧識別名記憶手段が記憶する前記権限名の一覧に、前記カテゴリ判定手順において判定されたカテゴリと当該操作との組み合わせに対して前記権限名記憶手段が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定することを特徴とする請求項６記載の情報処理方法。
【請求項８】
前記権限名記憶手段は、前記項目又は前記カテゴリと操作との組み合わせごとに、当該項目又は当該カテゴリに対する当該操作の権限を示す前記権限名を記憶し、
前記許否判定手順は、前記カテゴリ判定手順において、操作の対象とされた項目が属するカテゴリが存在しないと判定される場合は、当該操作の対象とされた前記情報に対する前記制御情報において当該情報に対する操作主体に対して設定されている前記権限名の一覧に、当該操作の対象とされた項目と当該操作との組み合わせに対して前記権限名記憶部が記憶する前記権限名が含まれているか否かに基づいて、当該操作の許否を判定することを特徴とする請求項６又は７記載の情報処理方法。
【請求項９】
前記分類情報には、前記カテゴリが再帰的に定義されていることを特徴とする請求項６乃至８いずれか一項記載の情報処理方法。
【請求項１０】
前記分類情報は、前記カテゴリの再帰的な関係が展開されて定義されていることを特徴とする請求項９記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理方法に関し、特に複数の項目より構成される情報に関する操作の許否を判定する情報処理装置及び情報処理方法に関する。
【背景技術】
【０００２】
従来、文書管理システム等のコンピュータシステムにおいて管理されている情報について、ＡＣＬ（Access Control List）等のアクセス制御情報を用いてアクセス制御が行われている。例えば、ＡＣＬは、資源ごとに関連付けられており、関連付けられている資源についてユーザごとにアクセス権が設定されている。この場合、アクセス制御の単位は資源単位となる。したがって、文書Ａについて、ユーザＡに対して参照権限が認められた場合、ユーザＡは、文書Ａの全ての属性情報を参照することができる。
【０００３】
また、より細かなアクセス制御を実現するため、属性情報を構成する各項目（フィールド）ごとにアクセス権の設定が可能とされているシステムも存在する。この場合、文書Ａの文書名の参照はできるが、実データの参照はできないといったアクセス制御が可能となる。
【特許文献１】特開２００５−０３８３７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、フィールドごとにアクセス権の設定が可能な場合、フィールドの数が多くなるとアクセス権の設定作業は非常に煩雑になるという問題がある。また、アクセス制御情報の情報量も増加し、記憶装置の消費量を増加させるという問題もある。
【０００５】
本発明は、上記の点に鑑みてなされたものであって、情報を構成する項目に対するアクセス制御を効率的に行うことのできる情報処理装置及び情報処理方法の提供を目的とする。
【課題を解決するための手段】
【０００６】
そこで上記課題を解決するため、本発明は、複数の項目より構成される情報に関する操作の許否を判定する情報処理装置であって、前記項目のカテゴリ分けが定義された分類情報を管理する分類情報管理手段と、前記カテゴリを単位として操作主体に付与する操作権限が設定された操作権限情報を管理する操作権限情報管理手段と操作の対象とされた項目が属するカテゴリを前記分類情報に基づいて判定するカテゴリ判定手段と、前記カテゴリ判定手段によって判定されたカテゴリと前記操作権限情報とに基づいて操作の許否を判定する許否判定手段とを有することを特徴とする。
【０００７】
このような情報処理装置では、情報を構成する項目に対するアクセス制御を効率的に行うことができる。
【発明の効果】
【０００８】
本発明によれば、情報を構成する項目に対するアクセス制御を効率的に行うことのできる情報処理装置及び情報処理方法を提供することができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本実施の形態における情報処理装置による情報の管理形態の概要を説明するための図である。図１では、文書データ（文書情報）が管理対象とされている例が示されている。同図では、１つの文書データ（レコード）を構成するフィールド（属性項目）として、文書名５０１ｂ、作成日５０２ａ、期限５０２ｂ、フォーマット５０４ａ、ページ数５０５ａ、原稿サイズ５０６ａ、カラーモード５０７ａ、パスワード５０８ｂ、サムネイル画像５０９ｃ、実画像データ５１０ｄ、及びＡＣＥ（Access Control Entry）５１１ｅ等が例示されている。
【００１０】
本実施の形態では、アクセス制御において同じように扱われるフィールド同士を同一のグループ（以下「属性カテゴリ」という。）に分類し、属性カテゴリごとのアクセス権限（操作権限）の設定を可能とする。図１では、各フィールドに付されている参照番号の末尾のアルファベット（ａ〜ｅ）の異同によって属性カテゴリの異同が示されている。すなわち、参照番号の末尾が「ａ」のフィールドは、「プロパティ」という名前の属性カテゴリに分類される。参照番号の末尾が「ｂ」のフィールドは、「アノテーション」という名前の属性カテゴリに分類される。参照番号の末尾が「ｃ」のフィールドは、「サムネイル画像」という名前の属性カテゴリに分類される。参照番号の末尾が「ｄ」のフィールドは、「画像」という名前の属性カテゴリに分類される。参照番号の末尾が「ｅ」のフィールドは、「ＡＣＥ」という名前の属性カテゴリに分類される。
【００１１】
各フィールドに対するアクセス権限を属性カテゴリごとに設定可能とすることで、アクセス権限の設定作業等を簡便化し、アクセス権限情報を記録するための記憶領域の消費量を減少させることができる。
【００１２】
以下、具体的に説明する。以下の説明では、画像形成装置を情報処理装置の具体例として説明する。図２は、本発明の実施の形態における画像形成装置のハードウェア構成の一例を示す図である。図２では、画像形成装置の具体例として、プリンタ、コピー、スキャナ、又は、ファクス等の複数の機能を一台の筐体において実現する複合機１のハードウェア構成が示されている。
【００１３】
複合機１のハードウェアとしては、コントローラ６０１と、オペレーションパネル６０２と、ファクシミリコントロールユニット（ＦＣＵ）６０３と、撮像部６０４と、印刷部６０５が存在する。
【００１４】
コントローラ６０１は、ＣＰＵ６１１、ＡＳＩＣ６１２、ＮＢ６２１、ＳＢ６２２、ＭＥＭ−Ｐ６３１、ＭＥＭ−Ｃ６３２、ＨＤＤ（ハードディスクドライブ）６３３、メモリカードスロット６３４、ＮＩＣ（ネットワークインタフェースコントローラ）６４１、ＵＳＢデバイス６４２、ＩＥＥＥ１３９４デバイス６４３、セントロニクスデバイス６４４により構成される。
【００１５】
ＣＰＵ６１１は、種々の情報処理用のＩＣである。ＡＳＩＣ６１２は、種々の画像処理用のＩＣである。ＮＢ６２１は、コントローラ６０１のノースブリッジである。ＳＢ６２２は、コントローラ６０１のサウスブリッジである。ＭＥＭ−Ｐ６３１は、複合機１のシステムメモリである。ＭＥＭ−Ｃ６３２は、複合機１のローカルメモリである。ＨＤＤ６３３は、複合機１のストレージである。メモリカードスロット６３４は、メモリカード６３５をセットするためのスロットである。ＮＩＣ６４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス６４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス６４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス６４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル６０２は、オペレータが複合機１に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１から出力を得るためのハードウェア（表示部）である。撮像部６０４は、原稿から画像（画像データ）を読み取るためのハードウェア（スキャナ）である。印刷部６０５は、画像（画像データ）を印刷用紙に印刷するためのハードウェア（プリンタ）である。
【００１６】
図３は、第一の実施の形態における画像形成装置のソフトウェア構成の一例を示す図である。図３において、複合機１におけるソフトウェアは、ＯＳ１０、アプリケーション共有サービス２０、アプリケーション３０、アプリケーションコントローラ４０、ユーザインタフェース部５０、及び共通メカニズム６０等より構成される。
【００１７】
ＯＳ１０は、一般的なＯＳである。アプリケーション共有サービス２０は、各種のアプリケーションに対して共通にサービスを提供するソフトウェアが実装された部分であり、図３では、データベース２１、属性カテゴリテーブル２２、権限名定義テーブル２３、及び権限セット定義テーブル２４等を含む。
【００１８】
データベース２１は、いわゆるデータベースであり、第一の実施の形態では文書データ等を管理する。データベース２１には、更に、文書データごとにＡＣＬ（Access Control List）２１１が登録されている。
【００１９】
図４は、一つの文書データに対するＡＣＬの定義例を示す図である。図４に示されるように、ＡＣＬ２１１には、ユーザごとに権限（操作権限）が設定されている。同図の例では、対応する（関連付けられている）文書データについて、鈴木さんには「公開情報読み取り」権限が付与され、佐藤さんには「フルコントロール」権限が付与された例が示されている。このように、ＡＣＬ２１１は、対応する文書データについて、ユーザ（操作主体）ごとに付与された操作権限が設定されているデータであり、例えば、ＨＤＤ６３３に記録されている。なお、「公開情報読み取り」及び「フルコントロール」は、後述される権限セット定義テーブル２４において権限セット名として定義されているものである。
【００２０】
図５は、属性カテゴリテーブルの構成例を示す図である。図５に示されるように、属性カテゴリテーブル２２は、文書データを構成する各フィールドがいずれの属性カテゴリに属するか（各フィールドのカテゴリ分け）が登録されたテーブルであり、例えば、ＨＤＤ６３３に記録されている。同図の例では、文書名のフィールドは、アノテーションの属性カテゴリに属し、保管機器名及びパス名のフィールドはプロパティの属性カテゴリに属することが示されている。
【００２１】
図６は、権限名定義テーブの構成例を示す図である。図６に示されるように、権限名定義テーブル２３は、各属性カゴリに対する各操作の権限を識別するための名前（権限名）が登録されたテーブルであり、例えば、ＨＤＤ６３３に記録されている。同図の例では、全属性カテゴリに対して共通にＤｅｌｅｔｅ（削除）を認める権限の権限名は「全Ｄ」とされている。また、プロパティの属性カテゴリに対してＲｅｆｅｒ（参照）を認める権限の権限名は「プＲ」であり、Ｕｐｄａｔｅ（更新）を認める権限の権限名は「プＵ」とされている。また、アノテーションの属性カテゴリに対してＲｅｆｅｒを認める権限の権限名は「アＲ」であり、Ｕｐｄａｔｅを認める権限の権限名は「アＵ」とされている。
【００２２】
図７は、権限セット定義テーブルの構成例を示す図である。図７に示されるように、ＡＣＬ２１１において権限として設定される単位（権限セット）ごとに、許可される権限の権限名の一覧が定義されたテーブルであり、例えば、ＨＤＤ６３３に記録されている。例えば、「公開情報」という権限セットは、プＲ、及びアＲ等の権限が許可される。ＡＣＬ２１１において設定される権限の組み合わせ（パターン）を予め権限セットとして登録しておくことで、ＡＣＬ２１１の設定作業を簡略化することができる。
【００２３】
アプリケーション３０は、オペレーションパネル６０２を介してユーザが直接操作可能なアプリケーションである。図３では、文書データ操作アプリ３１及びＦＡＸアプリ３２がアプリケーション３０として例示されている。なお、アプリケーション３０は、プラグインとして追加可能とされている。
【００２４】
アプリケーションコントローラ４０は、オペレーションパネル６０２に対する入力を解釈し、当該入力に応じてアプリケーション３０の制御等を行う。
【００２５】
ユーザインタフェース部５０は、各種の操作画面をオペレーションパネル６０２に表示させたり、操作画面に対する入力をアプリケーションコントローラ４０に通知したりする。
【００２６】
共通メカニズム６０は、他の各部より共通に利用されるソフトウェアが実装された部分であり、図３では、プラグイン管理部６１、ユーザ認証部６２、及びアクセス権限判断部６３が含まれる。
【００２７】
プラグイン管理部６１は、プラグインとして追加されるアプリケーション３０に関する情報を管理する。ユーザ認証部６２は、ログイン時にユーザの認証処理を行うと共に、現在操作中のユーザを認識する。アクセス権限判断部６３は、アプリケーション３０を介したユーザによる複合機１における各種資源に対するアクセス（操作）の許否を判断する。ここでいう資源には、文書データのフィールドも含まれる。
【００２８】
図３に示されるソフトウェアの中で、本実施の形態では、特に、アプリケーション３０、データベース２１、及びアクセス権限判断部６３の動作について注目する。図８は、第一の実施の形態において注目されるソフトウェアの関係を示す図である。
【００２９】
図８において、アプリケーション３０（文書データ操作アプリ３１、ＦＡＸアプリ３２）は、ユーザによる要求に応じてデータベース２１に管理されている文書データのフィールドを操作する。データベース３０は、アクセス権限判断部６３に対して操作対象とされたフィールドの操作の許否を問い合わせ、許可される場合に当該フィールドの操作を実行する。
【００３０】
以下、図８における関係に基づいて実行される処理手順について説明する。図９は、第一の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。
【００３１】
例えば、ユーザからの入力指示に基づいて、文書データ操作アプリ３１は、文書データのフィールドの操作をデータベース２１に対して要求（Ｓ１１０）。当該操作要求では、操作の種別、操作主体の識別情報（主体情報）、及び操作対象となる資源（フィールド）の識別情報（資源情報）等が指定される。図９の例では、操作の種別は「Ｕｐｄａｔｅ（更新）」、主体情報は「佐藤」、資源情報は「文書ＩＤ０００１の文書名」とされている。なお、操作の種別がＵｐｄａｔｅの場合、更新後の値（ここでは、「業務日誌Ｒ」）も指定される。すなわちステップＳ１１０において要求されている操作は、「佐藤さんによる文書ＩＤが０００１の文書データの文書名の"業務日誌"への更新」に相当する。
【００３２】
操作要求を受けたデータベースは、主体情報（佐藤）、資源情報（文書ＩＤ０００１の文書名）、及び操作種別（Ｕｐｄａｔｅ）を伴って、当該操作の権限確認をアクセス権限判断部６３に要求する（Ｓ１２０）。アクセス権限判断部６３は、資源情報において指定されている操作対象のフィールド（文書名）が属する属性カテゴリをデータベース２１に問い合わせる（Ｓ１３０）。データベース２１は、属性カテゴリテーブル２２（図５参照）を用いて当該フィールドが属する属性カテゴリ名を判定し、判定された属性カテゴリ名（アノテーション）をアクセス権限判断部６３に返却する（Ｓ１４０）。これにより、権限の判断対象とされる操作は、「佐藤さんによるアノテーションの更新」となる。
【００３３】
続いて、アクセス権限判断部６３は、文書ＩＤが０００１の文書データのＡＣＬ２１１（図４参照）をデータベース２１より取得する（Ｓ１５０、Ｓ１６０）。続いて、アクセス権限判断部６３は、ＡＣＬ２１１において佐藤さんのエントリに設定されている権限（フルコントロール）を権限セット定義テーブル２４（図７参照）に当てはめることにより、権限名一覧を取得し、取得された権限名一覧（プＲ、プＵ、アＲ、アＵ、・・・）と要求されている操作（アノテーションの更新＝アＵ）とを照合することにより、当該操作の許否を判定する（Ｓ１７０）。ここでは、要求されている操作（アＵ）は権限名一覧に含まれているため、当該操作は許可される。一方、要求されている操作が権限名一覧に含まれていない場合、当該操作は許可されない。
【００３４】
続いて、アクセス権限判断部６３は、許否判定の結果をデータベース２１に返却する（Ｓ１８０）。許否判定の結果において要求されている操作が許可されている場合、データベース２１は、当該操作を実現するための処理を実行する（Ｓ１９０）。
【００３５】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及しない点については第一の実施の形態と同様でよい。
【００３６】
図１０は、第二の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。図１０中、図９と同一ステップには同一ステップ番号を付している。
【００３７】
図１０において、データベース２１は、操作要求（Ｓ１１０）を受けると、権限の確認要求を行う前に、属性カテゴリテーブル２２を用いてフィールド名（文書名）を属性カテゴリ名（アノテーション）に変換する（Ｓ１１５）。続いて、データベース２１は、資源情報に属性カテゴリ名（アノテーション）を指定して権限の確認要求を行う（Ｓ１２０ａ）。したがって、アクセス権限判断部６３は、操作対象とされているフィールドが属する属性カテゴリの問い合わせを行う必要はなく、続けてステップＳ１５０以降を実行する。
【００３８】
図１０に示される処理手順によれば、アクセス権限判断部６３は、フィールド名の属性カテゴリ名への変換を意識する必要はない。したがって、例えば、管理対象とされている情報の各フィールドが属性カテゴリに分類されていないデータベースからの問い合わせに対しても、アクセス権限判断部６３は、各フィールドがカテゴリ分類されているデータベースと同様の振る舞いによって操作の許否判定を行うことができる。この点について、図１１のシーケンス図を用いて具体的に説明する。
【００３９】
図１１は、フィールドがカテゴリに分類されていない場合のフィールドの操作時の処理手順を説明するためのシーケンス図である。図１１中、図９又は図１０と同一ステップには同一ステップ番号を付している。
【００４０】
図１１において、データベース２１ａは、管理対象とされている情報の各フィールドがカテゴリに分類されていない（すなわち、属性カテゴリテーブル２２が定義されていない。）データベースである。この場合、権限名定義テーブル２３には、各フィールドに対する各操作の権限を識別するための権限名（以下、「フィールド権限名」という。）が定義されており、権限セット定義テーブル２４には、フィールド権限名の一覧によって権限セット名が定義されている。
【００４１】
したがって、データベース２１ａは、権限の確認をアクセス権限判断部６３に要求する際、資源情報には、フィールド名（文書名）を指定する（Ｓ１２０）。アクセス権限判断部６３は、資源情報に指定された値が属性カテゴリ名であるかフィールド名であるかを意識することなくステップＳ１５０以降の処理を実行することにより、要求された操作の許否判定を行う。
【００４２】
図１０と図１１とを比較すると、アクセス権限判断部６３とデータベース２１との間のやりとりと、アクセス権限判断部６３とデータベース２１ａとの間のやりとりは、権限確認の際に資源情報として指定される値が属性カテゴリ名であるかフィールド名であるかを除き同じである。ここで、アクセス権限判断部６３は、資源情報として指定されている値が属性カテゴリ名であるかフィールド名であるかを意識する必要は無い。アクセス権限判断部６３は、資源情報として渡された属性カテゴリ名又はフィールド名を、単なる文字列として扱えばよいからである。
【００４３】
このことは、フィールド名が属性カテゴリに分類されているか否かに依存することなく、アクセス権限判断６３のＡＰＩが統一されることを意味する。したがって、データベース２１とデータベース２１ａとが混在する環境であっても、アクセス権限判断部６３は、双方のデータベースに対する操作の許否判定を同じ振る舞いによって実現することができる。
【００４４】
次に、第三の実施の形態について説明する。図１２は、第三の実施の形態において注目されるソフトウェアの関係を示す図である。図１２中、図８と同一部分には同一符号を付し、その説明は省略する。
【００４５】
図１２では、文書データ管理部２５及びアカウントデータ管理部２６がアプリケーション共有サービス２０の構成要素として追加されている。文書データ管理部２５は、データベース２１において管理されている文書データの意味（構成）を解釈するためのロジックが実装されたソフトウェア部品である。また、アカウントデータ管理部２６は、データベース２１に管理されているアカウントデータ（アカウント情報）の意味を解釈するためのロジックが実装されたソフトウェア部品である。
【００４６】
すなわち、第一及び第二の実施の形態における構成の場合、データベース２１において管理されているデータの意味を解釈するためのロジックは、データベース２１又はアプリケーション３０に実装されている必要がある。データベース２１に当該ロジックが実装される場合、管理するデータの種類（意味論）が増加するたびに、データベース２１のソースコードの修正が必要とされる問題がある。一方、アプリケーション３０に当該ロジックが実装される場合、当該ロジックは各アプリケーションに実装される必要があり、実装形態が冗長になるという問題がある。
【００４７】
そこで、第三の実施の形態では、データベース２１に管理されているデータを解釈する部分（意味論データベース）が意味論ごとにソフトウェア部品として実装されるように構成されている。これにより、データベース２１又はアプリケーション３０においてデータの意味を解釈するための基本的なロジックの実装は不要となる。また、新たな意味論におけるデータがデータベース２１に追加される場合、当該意味論に対応した意味論データベースをプラグインとして追加すればよく、管理対象とする意味論の増加に応じた拡張性を向上させることができる。
【００４８】
なお、属性カテゴリテーブル２２、権限名定義テーブル２３、及び権限セット定義テーブル２４は、意味論データベースごとに管理される。図１２では、文書データ管理部２５は、属性カテゴリテーブル２２ａ、権限名定義テーブル２３ａ、及び権限セット定義テーブル２４ａを管理し、アカウントデータ管理部２６は、属性カテゴリテーブル２２ｂ、権限名定義テーブル２３ｂ、及び権限セット定義テーブル２４ｂを管理する例が示されている。それぞれの属性カテゴリテーブル２２、権限名定義テーブル２３、及び権限セット定義テーブル２４には、それぞれの意味論において必要な情報が登録されていればよい。
【００４９】
以下、図１２に示される構成に基づいて実行される処理手順について説明する。図１３は、第三の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。
【００５０】
例えば、ユーザからの入力指示に基づいて、文書データ操作アプリ３１は、文書データのフィールドの操作を文書データ管理部２５に要求する（Ｓ２０１）。第三の実施の形態では、データベース２１へのアクセスは意味論データベースを介して行われるため、操作の要求先は文書データ管理部２５となる。なお、当該操作要求において指定されるパラメータは、ステップＳ１１０と同様でよい。
【００５１】
続いて、文書データ管理部２５は、属性カテゴリテーブル２２ａを用いてフィールド名（文書名）を属性カテゴリ名（アノテーション）に変換する（Ｓ２０２）。続いて、文書データ管理部２５は、資源情報に属性カテゴリ名（アノテーション）を指定してアクセス権限判定部６３に対して権限の確認要求を行う（Ｓ２０３）。
【００５２】
続いて、アクセス権限判断部６３は、ステップＳ１５０〜Ｓ１７０において説明した処理手順と同様の処理手順によって、要求されている操作の許否を判定し（Ｓ２０４〜Ｓ２０６）、その判定結果を文書データ管理部２５に返却する（Ｓ２０７）。操作が許可された場合、文書データ管理部２５は、要求された操作の実行をデータベース２１に対して指示する（Ｓ２０８）。データベース２１は、文書データ管理部２５による指示に従い、当該操作を実現するための処理を実行する（Ｓ２０９）。
【００５３】
上述したように、第三の実施の形態によれば、意味論データベース（文書データ管理部２５）によって、アクセス権限判断部６３による操作の許否判定の結果に基づいて操作の実行の是非が判断される。そして、データベース２１は、操作の許否をアクセス権限判断部６３に問い合わせることなく、意味論データベースからの指示に従って操作を実行する。したがって、操作対象とされたデータに関する意味論に特有のアクセス制御の仕様を実現するためのロジックを意味論データベースに実装することで、当該意味論に特有のアクセス制御の仕組みを意味論データベースのプラグイン・アウトによって、追加又は削除することができる。
【００５４】
具体的な例として、文書データが、フォルダによる階層構造を有しており、フォルダに対して削除権限があれば、そのフォルダ以下の文書については各文書に対する権限を問わず削除可能であるというアクセス制御を実現する場合について考える。この場合、文書データ管理部２５は、削除の対象とされたフォルダに対する削除権限をアクセス権限判断部６３に問い合わせ。削除が許可されれば、当該フォルダ以下の全ての文書の削除をデータベース２１に要求すればよい。
【００５５】
次に、第四の実施の形態について説明する。第四の実施の形態では、フィールドと属性カテゴリとを抽象化した概念（以下「権限設定要素」という。）を定義し、権限設定要素単位で操作権限の設定を可能とする。
【００５６】
図１４は、第四の実施の形態における属性カテゴリとフィールドとの関係を説明するための図である。同図において（Ａ）は、第一から第三の実施の形態における属性カテゴリとフィールドとの関係を示す。図示されるように、属性カテゴリはフィールドを集約する関係にある。一方、（Ｂ）は、第四の実施の形態における属性カテゴリとフィールドとの関係を示す。図示されるように、属性カテゴリとフィールドとは権限設定要素という概念によって抽象化（汎化）されている。
【００５７】
このことは、具体的には、権限名定義テーブル２３において、属性カテゴリのみならずフィールドについても各操作に対する権限名が定義されることを意味する。図１５は、第四の実施の形態における権限名定義テーブルの構成例を示す図である。
【００５８】
図１５に示されるように、第四の実施の形態における権限名定義テーブル２３ｃは、各権限設定要素（属性カテゴリ又はフィールド）について権限名の登録が可能とされている。したがって、属性カテゴリ単位に限定されず、フィールド単位での操作権限についても権限名の登録が可能である。同図の例では、「省略文書名」がフィールド名に相当する。省略文書名のフィールドに対してＲｅｆｅｒを認める権限の権限名は「省Ｒ」であり、Ｕｐｄａｔｅを認める権限の権限名は「省Ｕ」とされている。
【００５９】
この場合、権限セット定義テーブル２４の登録内容は、次のようになる。図１６は、第四の実施の形態における権限セット定義テーブルの構成例を示す図である。図１６に示されるように、第四の実施の形態における権限セット定義テーブル２４ｃには、権限セットに対する権限名一覧の中に、フィールド単位に係る権限名（省Ｒ）が登録されうる。
【００６０】
なお、第四の実施の形態における処理手順は、基本的に上述した処理手順と同様でよい。但し、属性カテゴリテーブル２２に基づいてフィールド名を属性カテゴリ名に変換する際、当該フィールド名に対応する属性カテゴリが存在しない場合は、権限名定義テーブル２３において当該フィールド名に関して登録されている権限名が、ＡＣＬ２１１において、操作の主体であるユーザに設定されている権限（権限セット）に含まれているか否かに基づいて、操作の許否を判定すればよい。
【００６１】
上述したように、第四の実施の形態によれば、属性カテゴリとフィールドとを混在させた操作権限の設定が可能である。したがって、一つのフィールドしか属さない属性カテゴリを定義する必要はない。よって、アクセス権限情報を記録するための記憶領域の消費量を減少させることができる。
【００６２】
次に、第五の実施の形態について説明する。図１７は、第五の実施の形態における属性カテゴリとフィールドとの関係を説明するための図である。同図に示されるように、第五の実施の形態では、属性カテゴリが権限設定要素を集約する関係にある。このことは、属性カテゴリの中に属性カテゴリを定義するといった入れ子構造（再帰的な関係）の定義が可能であることを意味する。また、二以上の属性カテゴリを含む属性カテゴリ、及び一以上の属性カテゴリと一以上のフィールドとを含む属性カテゴリを定義可能であることを意味する。なお、図１７の関係は、図１４の関係を拡張したものであるため、第四の実施の形態において実現可能なことは、第五の実施の形態でも実現可能である。
【００６３】
属性カテゴリとフィールドとの関係が図１７に示されるように定義される場合、属性カテゴリテーブル２２は、次のように構成される。図１８は、第五の実施の形態における属性カテゴリテーブルの構成例を示す図である。
【００６４】
図１８に示されるように第五の実施の形態における属性カテゴリテーブル２２ｄには、各権限設定要素（フィールド、属性カテゴリ）ごとに、いずれの属性カテゴリに属するかが登録される。同図において、例えば、保管機器名及び作成日というフィールドは、「弱プロパティ」という属性カテゴリに属する。また、弱プロパティは、プロパティという属性カテゴリに属する。プロパティは、弱プロパティのみならず、パス名というフィールドも含む。
【００６５】
また、図１９は、第五の実施の形態における権限名定義テーブの構成例を示す図である。図１９に示されるように、第五の実施の形態における権限名定義テーブル２３ｄは、第四の実施の形態と同様に、各権限設定要素（属性カテゴリ又はフィールド）について権限名の登録が可能とされている。したがって、他の属性カテゴリの属する属性カテゴリ（族プロパティ）にもついても権限名（弱Ｒ、弱Ｕ）が登録される。
【００６６】
また、図２０は、第五の実施の形態における権限セット定義テーブルの構成例を示す図である。図２０に示されるように、第五の実施の形態における権限セット定義テーブル２４ｄには、権限セット名に対する権限名一覧の中に、他の属性カテゴリに属する属性カテゴリに係る権限名（弱Ｒ）が登録されうる。
【００６７】
なお、第五の実施の形態における処理手順は、上述した処理手順と基本的に同様でよい。但し、第五の実施の形態では、操作対象とされたフィールドの属性カテゴリは、再帰的に複数取得されうる。また、再帰的に複数取得された各属性カテゴリに関する権限名が、権限セットに対する権限名一覧に含まれているか否かを確認することにより、操作の許否が判定される。
【００６８】
上述したように、第五の実施の形態によれば、属性カテゴリを再帰的に定義することにより、再帰的な関係に基づく包含関係に対応させて、操作権限を認めるフィールドの範囲を効率的に設定することができる。具体的には、図１８において、弱プロパティは、プロパティに包含される関係にある。ここで、ユーザＡには弱プロパティに対する操作権限を与え、ユーザＢにはプロパティに対する権限を与えることで、ユーザＡとユーザＢとの間で権限範囲の異なる権限設定を効率的に（簡便に）行うことができる。
【００６９】
なお、第五の実施の形態において、属性カテゴリテーブル２２ｄに登録されている属性カテゴリの再帰的な関係について、既に展開されたものについては、展開された状態をメモリ上、又は属性カテゴリテーブル２２ｄに保持しておくようにしてもよい。そうすることにより、次回、同じ属性カテゴリに属するフィールドが属する属性カテゴリを検索する際の処理効率を向上させることができる。
【００７０】
また、属性カテゴリの再帰的な関係は、複合機１の起動時において展開しておいてもよい。また、予め再帰的な関係が展開された状態で属性カテゴテーブル２２ｄが作成されてもよい。
【００７１】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【００７２】
【図１】本実施の形態における情報処理装置による情報の管理形態の概要を説明するための図である。
【図２】本発明の実施の形態における画像形成装置のハードウェア構成の一例を示す図である。
【図３】第一の実施の形態における画像形成装置のソフトウェア構成の一例を示す図である。
【図４】一つの文書データに対するＡＣＬの定義例を示す図である。
【図５】属性カテゴリテーブルの構成例を示す図である。
【図６】権限名定義テーブの構成例を示す図である。
【図７】権限セット定義テーブルの構成例を示す図である。
【図８】第一の実施の形態において注目されるソフトウェアの関係を示す図である。
【図９】第一の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。
【図１０】第二の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。
【図１１】フィールドがカテゴリに分類されていない場合のフィールドの操作時の処理手順を説明するためのシーケンス図である。
【図１２】第三の実施の形態において注目されるソフトウェアの関係を示す図である。
【図１３】第三の実施の形態におけるフィールドの操作時の処理手順を説明するためのシーケンス図である。
【図１４】第四の実施の形態における属性カテゴリとフィールドとの関係を説明するための図である。
【図１５】第四の実施の形態における権限名定義テーブルの構成例を示す図である。
【図１６】第四の実施の形態における権限セット定義テーブルの構成例を示す図である。
【図１７】第五の実施の形態における属性カテゴリとフィールドとの関係を説明するための図である。
【図１８】第五の実施の形態における属性カテゴリテーブルの構成例を示す図である。
【図１９】第五の実施の形態における権限名定義テーブの構成例を示す図である。
【図２０】第五の実施の形態における権限セット定義テーブルの構成例を示す図である。
【符号の説明】
【００７３】
１          複合機
１０        ＯＳ
２０        アプリケーション共有サービス
２１        データベース
２２        属性カテゴリテーブル
２３        権限名定義テーブ
２４        権限セット定義テーブル
２５      文書データ管理部
２６      アカウントデータ管理部
３０        アプリケーション
３１        文書データ操作アプリ
３２        ＦＡＸアプリ
４０        アプリケーションコントローラ
５０        ユーザインタフェース部
６０        共通
６１        プラグイン管理部
６２        ユーザ認証部
６３        アクセス権限判断部
２１１      ＡＣＬ
６０１      コントローラ
６０２      オペレーションパネル６０２
６０３      ファクシミリコントロールユニット
６０４      撮像部
６０５      印刷部
６１１      ＣＰＵ
６１２      ＡＳＩＣ
６２１      ＮＢ
６２２      ＳＢ
６３１      ＭＥＭ−Ｐ
６３２      ＭＥＭ−Ｃ
６３３      ＨＤＤ
６３４      メモリカードスロット
６３５      メモリカード
６４１      ＮＩＣ
６４２      ＵＳＢデバイス
６４３      ＩＥＥＥ１３９４デバイス
６４４      セントロニクスデバイス
【図１】
0004980840.tif 000002
【図２】
0004980840.tif 000003
【図３】
0004980840.tif 000004
【図４】
0004980840.tif 000005
【図５】
0004980840.tif 000006
【図６】
0004980840.tif 000007
【図７】
0004980840.tif 000008
【図８】
0004980840.tif 000009
【図９】
0004980840.tif 000010
【図１０】
0004980840.tif 000011
【図１１】
0004980840.tif 000012
【図１２】
0004980840.tif 000013
【図１３】
0004980840.tif 000014
【図１４】
0004980840.tif 000015
【図１５】
0004980840.tif 000016
【図１６】
0004980840.tif 000017
【図１７】
0004980840.tif 000018
【図１８】
0004980840.tif 000019
【図１９】
0004980840.tif 000020
【図２０】
0004980840.tif 000021