JP4398685B2 - アクセス制御判断システム、アクセス制御判断方法、アクセス制御判断プログラム、及びそのプログラムを記憶したコンピュータ読み取り可能な記憶媒体 - Google Patents

Description

本発明は、情報処理システムに対して組織のセキュリティポリシーを適用可能とし、電子化された文書のみならず紙文書に対する組織のセキュリティを向上することができるアクセス制御判断システムを提供することである。

オフィスでの業務が電子化されるにつれ、機密文書等の電子文書の管理についてその重要性が増大してきている。このような電子文書に対して所定のセキュリティポリシーに従ってアクセス制御することが行われるようになってきた。

企業内にて統一したセキュリティポリシーによって電子文書に対するセキュリティを確保すると言う観点において、セキュリティポリシーの記述方法及びそのセキュリティポリシーを伝送する装置が提案されている（例えば、特許文献１）。また、そのようなセキュリティポリシーを配布する方法、セキュリティポリシーに基づいて動作する装置等がある（例えば、特許文献２）。更に、電子文書の印刷を、電子文書の暗号化及び復号と共にセキュリティポリシーに従って制御する方法及び装置等がある（例えば、特許文献３）。

また、主に音楽データや画像データなどデジタルコンテンツを販売することを目的としたシステムでは企業秘密管理と同じような課題が存在するため、類似の技術を応用することがある（例えば、特許文献４、特許文献５、特許文献６及び特許文献７）。特に、著作権が関わるようなデジタルデータ（音楽データや画像データなどdigital workと呼んでいる）について、それを参照したり印刷したりする際に条件を満たさなければならないようなシステムを提供している。その権限記述文法（usage right grammar）と、権限を行使するための条件が満たされているかどうかを確認するためのプロトコルが開示されている。この技術を用いると、配布された音楽データや画像データなどについて、その参照や印刷に料金を支払うことを条件としたり、料金を支払わずに利用できる期間を制限したり、ということが実現できる。

しかし、これらの発明はオフィスでの企業秘密管理を念頭に置いたものではなく、デジタルコンテンツの販売を目的にしたものであるために、機密文書を印刷した際の印刷物まで含めたアクセス制御が想定されていない。

また、デジタルコンテンツを表示し、印刷時に様々な処理を行うシステムが提案されている（例えば、特許文献８及び特許文献９）。例えば、印刷時にグリフコードを埋め込むことができる。しかし、埋め込む情報を個々の文書ごとに定めなければならない。

更に、ポリシーに従ってアクセス許可又は不許可を判断するポリシー評価モジュールと、許可するための条件が規定されていたときにその条件を執行可能か否かを判断する執行機能検証モジュールと、そして執行モジュールとで構成されるアクセス制御サブシステムが提案されている（例えば、特許文献１０）。
特開２００２−２６７０６５号公報 特開２００２−２５１９２１号公報 特開２００２−２９９７１２号公報 特開平８−２６３４４１号公報 米国特許第５、７１５、４０３号明細書 特開平８−２６３４３８号公報 米国特許第６、２３６、９７１号明細書 特開２０００−１２２９７７号公報 米国特許第６、２３３、６８４号明細書 特開２００１−１８４２６４号公報（図１及び図２）

しかしながら、上記従来技術では、下記のような運用面で柔軟性にかける問題があった。
・ポリシーで「関係者のみ参照可能」と規定される場合、関係者はドキュメント単位で様々に変わるが、ドキュメント単位で関係者を管理できない。
・ポリシーで「印刷する際にはマル秘スタンプを押すこと」と規定される場合、マル秘スタンプ、極秘スタンプ、持ち出し禁止スタンプ等の様々なものに対応できない。
・ポリシーで「利用者に取扱注意の警告をすること」と規定される場合、ドキュメントのタイプに応じて警告する内容（文章）を変えることができない。
・文書を取り扱ってよい「許可ゾーン」を定義して、その範囲内のみの利用として制限することができない。
・紙文書に対するオペレーションを制御するには紙文書が識別できなければならないが、紙文書の識別がうまくできなかった場合の対処の仕方を規定し処理されるようにできない。

また、このような問題を解決したとしても、組織のセキュリティポリシーに従って統一的なアクセス制御を行うためには、ポリシーに従ってアクセス制御の判断を行う部分を様々なアプリケーションシステムから利用できるように完全に分離し、アクセスを実際に執行する部分と分けて構成することが望ましい。

また、組織のセキュリティポリシーのように抽象的な記述に従ってアクセスを制御することができない等の問題があった。

そこで、本発明の課題は、情報処理システムに対して組織のセキュリティポリシーを適用可能とし、紙文書と電子文書のセキュリティを確保するアクセス制御判断システムを提供することである。

上記課題を解決するため、本発明は、請求項１に記載されるように、アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信するアクセス判断要求受信手段と、組織の企業秘密管理規則に従って前記対象情報へのオペレーションを許可するか否かと、該オペレーションを許可する場合に実行させる要件と、該要件を実行するために使用される文字列又は画像データを指定する補足情報とを規定したセキュリティポリシーを記憶しておくセキュリティポリシー記憶領域と、前記アクセス判断要求にて指定される前記対象情報へのアクセスを要求するアクセス要求元を識別する第一の識別情報と、前記アクセスされる対象情報を識別する第二の識別情報とを、対応する各テーブルにマッピングされている組織の企業秘密管理レベルへと変換する抽象度変換手段と、前記第一及び第二の識別情報に各々対応する企業秘密管理レベルの組み合わせに基づいて、前記セキュリティポリシーを参照することによって、前記対象情報への前記アクセス判断要求で指定されるオペレーションに対するアクセス制御を判断するアクセス制御判断手段と、前記アクセス制御判断手段による前記対象情報へのアクセス制御を示す判断結果情報を前記アクセス判断要求を行った要求元へ送信する判断結果送信手段とを有し、前記オペレーションが許可される場合には、前記要件と前記補足情報とが指定された判断結果によって、前記アクセス判断要求を行った要求元に該補足情報を用いて該要件を実行させるように構成される。

このようなアクセス制御判断システムでは、要件を補足情報を用いて実行することによってオペレーションを許可するように規定することができる。

また、本発明は、請求項２に記載されるように、前記セキュリティポリシーにおいて、前記要件として、ラベル印刷、ラベル表示、追跡情報埋め込み、警告の表示、警告の印刷、透かし文字の印刷、電子透かしの埋め込み、浮き出る透かし文字の印刷、複写抑止地紋のうち少なくとも１つを規定するように構成される。

更に、本発明は、請求項３に記載されるように、前記セキュリティポリシーにおいて、前記各要件は、固定画像データ、動的な画像データ、画像の埋め込み位置、警告文字列、ウォーターマークの文字列、電子透かしの文字列、背景文字列、地紋文字列、文字列の埋め込み位置、色の指定のいずれか１つの補足情報を指定するように構成される。

更に、本発明は、請求項１３に記載されるように、上記ルール記述は、上記要件毎に複数の上記補足情報を規定することができる。

組織のセキュリティポリシーに従って紙文書及び電子文書のセキュリティを確保することができる。そして組織のセキュリティポリシーに従ったアクセス制御において許可又は不許可だけでなく要件を規定するようにし、その要件をユーザの情報漏洩抑止力を高めるために利用し、また電子文書の印刷時にセキュリティ処理を強制するために利用することで、電子文書だけでなく紙文書の取り扱いまで一貫して組織のセキュリティポリシーを徹底させる効果を奏する。

以下、本発明の実施の形態を図面に基づいて説明する。

本発明の一実施例に係るアクセス制御判断システムをセキュリティサーバとして適応した本システムは、例えば、図１に示すようなシステムを構成する。図１は、本発明の一実施例に係るシステム構成を示す図である。図１において、電子文書又は紙文書に対するアクセス制御を行うセキュリティサーバ２００は、電子文書を管理する文書管理システム１００と、コピー、ファクス、プリンタ、スキャナなど複数の異なる画像形成機能を搭載したデジタル複合機７０と、電子文書をユーザの端末５１に表示するドキュメントビューア５３とネットワークを介して接続する。

図１において、ドキュメントビューア５３は、端末５１上で動作する所定のアプリケーションである。また、端末５１は、ネットワークを介して、文書管理システム１００に保管されている目的文書へのアクセスを行う。また、ユーザ５２は、持ち込んだ紙文書をデジタル複合機７０でコピー等を行う。図１中、端末５１及びユーザ５２は、夫々複数であっても良い。

文書管理システム１００で管理され、電子文書そのものへのアクセスが制御されているような電子文書を以下、サーバドキュメント６１と言う。デジタル複合機７０で取り扱う紙文書を以下、ペーパードキュメント６２と言う。文書管理システム１００等からダウンロードして端末５１のローカルストレージに保持し、ドキュメントビューア５３で開いて参照する電子文書を以下、ポータブルドキュメント６３と言う。

ユーザ５２が端末５１を用いて、文書管理システム１００に接続し、サーバドキュメント６１に対してアクセスすると、文書管理システム１００は、ユーザ５２から認証情報を取得し、ユーザ管理サーバ３００へユーザ認証の問い合わせを行う。文書管理システム１００は、ユーザ管理サーバ３００からの認証結果に基づいて、セキュリティサーバ２００へアクセス制御の問い合せを行う。文書管理システム１００は、セキュリティサーバ２００から通知されるアクセス制御情報に基づいて、サーバドキュメント６１に対するアクセスを行う。

同様に、ユーザ５２がデジタル複合機７０でペーパードキュメント６２を複写する際、デジタル複合機７０は、ユーザ５２から認証情報を取得し、ユーザ管理サーバ３００へユーザ認証の問い合わせを行う。デジタル複合機７０は、ユーザ管理サーバ３００からの認証結果に基づいて、セキュリティサーバ２００へアクセス制御の問い合せを行う。デジタル複合機７０は、セキュリティサーバ２００から通知されるアクセス制御情報に基づいて、ペーパードキュメント６２の複写を行う。

同様に、ユーザ５２が端末５１にてドキュメントビューア５３を起動して、ポータブルドキュメント６３を表示する際、ドキュメントビューア５３は、ユーザ５２から認証情報を取得し、ユーザ管理サーバ３００へユーザ認証の問い合わせを行う。ドキュメントビューア５３は、ユーザ管理サーバ３００からの認証結果に基づいて、セキュリティサーバ２００へアクセス制御の問い合せを行う。ドキュメントビューア５３は、セキュリティサーバ２００から通知されるアクセス制御情報に基づいて、ポータブルドキュメント６３の表示、又は、表示したポータブルドキュメント６３の出力等を行う。

ユーザ管理サーバ３００は、文書管理システム１００、デジタル複合機７０、又は、ドキュメントビューア５３からユーザ５２の認証情報を受信すると、ユーザ５２毎に認証情報を含むユーザ５２のユーザ情報を管理するユーザ管理テーブル３１０を参照して、ユーザ５２の認証を行う。ユーザ管理サーバ３００は、その認証結果をユーザ認証の問い合わせをした文書管理システム１００、デジタル複合機７０、又は、ドキュメントビューア５３へ送信する。

セキュリティサーバ２００は、組織におけるアクセス制御ルールが記載されたポリシーファイル２４０と、ユーザ５２毎にユーザ権限を管理するユーザ権限管理レベルテーブル２５０と、ドキュメント毎にそのプロファイルを管理するドキュメントプロファイル２６０と、ゾーン毎にアクセス制御を管理するゾーン管理テーブル２７０と、印刷毎に印刷に関する情報を管理するプリントプロファイル管理テーブル２８０とを有する。セキュリティサーバ２００は、ポリシーファイル２４０とこれらテーブル２５０から２８０を用いて、文書管理システム１００、デジタル複合機７０、及び、ドキュメントビューア５３からのアクセス制御の問い合わせに応じる。

ポリシーファイル２４０には「関係者のみアクセス許可」などの規定ができるが、どの文書については誰が関係者なのか、その関係を管理できなければならない。そういったポリシーを補足するテーブルは、ポリシーとは別にセキュリティサーバ内で管理する。ポリシーにそのような関係者を記載してしまうと汎用性に欠けたポリシーになってしまうためである。つまり、組織の企業秘密管理規則のような「ルール」として規定できる部分のみポリシーとして規定し、ドキュメントごと、ユーザごとに様々に設定すべきものはテーブルで管理する。そして、その「ルール」は組織によって様々に異なるため、ポリシーファイル２４０という形にすることによって、入れ替え可能となる。

以下、サーバドキュメント６１、ペーパードキュメント６２、及びポータブルドキュメント６３を総称してドキュメント６０（図２）と言う。

端末５１及びユーザ５２を含め、ドキュメント６０に対してアクセスするものをイニシエータ５０と言う。

また、文書管理システム１００、デジタル複合機７０、ドキュメントビューア５３等を総称してアプリシステム４００と言う。

システム１０００では、セキュリティサーバ２００とユーザ管理サーバ３００とを分けて構成しているが、１つのサーバでセキュリティサーバ２００の機能とユーザ管理サーバ３００の機能とを有するように構成しても良い。

アクセス制御の概要を、ＩＳＯ／ＩＥＣ 10181-3に従って記述したアクセス制御モデルを示す図２を参照しつつ説明する。図２は、アクセス制御モデルを示す図である。

図２において、アプリシステム４００は、イニシエータ５０からドキュメント６０に対してアクセスを要求されると、ユーザ認証後にアクセスを許可するか否かをセキュリティサーバ２００に許可の判断を要求する。特に、ユーザ認証を必要としない場合には、anonymous（匿名）ユーザ又はguest（ゲスト）ユーザとしてアクセス許可を問い合わせるようにしても良い。

セキュリティサーバは、そのユーザがそのドキュメントにアクセスする権限があるかどうかを内部に保持しているセキュリティファイル２４０に記述されるアクセス制御ルール（ポリシー）に従って判断し、許可されているか、禁止されているか、許可されている場合に満たさなければならない要件は何か、を判断結果としてアプリシステムに返す。

アプリシステム４００は、判断結果を受け取り、許可されている場合にはユーザから要求されたアクセスを処理する。その際、判断結果として要件が指定されていれば、その要件を満たすようにドキュメント６０を処理する。禁止されている、要件が満たせない等の場合にはアクセスを拒否する。

次に、セキュリティサーバ２００のハードウェア構成及び機能構成について説明する。図３は、本発明の一実施例に係るセキュリティサーバのハードウェア構成を示す図である。

図３において、セキュリティサーバ２００は、サーバコンピュータであって、ＣＰＵ（中央処理装置）４１と、メモリユニット４２と、表示ユニット４３と、入力ユニット４４と、通信ユニット４５と、記憶装置４６とを有し、各ユニット４１から４６はシステムバスＢ２に接続される。

ＣＰＵ４１は、メモリユニット４２に格納されたプログラムに従ってストレージ２００を制御する。メモリユニット４２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read-Only Memory）等にて構成され、ＣＰＵ４１にて実行されるプログラム、ＣＰＵ４１での処理に必要なデータ、ＣＰＵ４１での処理にて得られたデータ等を格納する。また、メモリユニット４２の一部の領域が、ＣＰＵ４１での処理に利用されるワークエリアとして割り付けられている。

表示ユニット４３は、ＣＰＵ４１の制御のもとに必要な各種情報を表示する。通信ユニット４５は、アプリシステム４００と例えばＬＡＮ（Local Area Network）等で接続される場合に、アプリシステム４００との間で通信制御をするためのユニットである。記憶装置４６は、例えば、ハードディスクユニットにて構成され、ポリシーファイル２４０と、ユーザ権限レベルテーブル２５０、ドキュメントプロファイル管理テーブル２６０、ゾーン管理テーブル２７０、プリントプロファイル管理テーブル２９０等の管理テーブルとを保存する。

セキュリティサーバ２００を制御するプログラムは、予め、記憶装置４６にインストールされている。

図４は、セキュリティサーバの機能構成を示す図である。図４において、セキュリティサーバ２００は、主に、アプリシステム４００から提供される情報等を企業のセキュリティポリシーに対応させるために抽象化を行う抽象化処理部２３１と、抽象化処理部２３１によって抽象化された情報に基づいてアクセス制御を判断するポリシーベースアクセス制御判断部２４１とを有する。

抽象化処理部２３１は、更に、ユーザ権限レベルマッピング部２３２と、ユーザ区分マッピング２３３と、ゾーンマッピング部２３４と、ドキュメントセキュリティ属性マッピング部２３５とを有する。

抽象化処理部２３１において、アプリシステム４００からユーザ識別情報と、アクセス種別情報と、ドキュメント識別情報と、コンテキスト情報とを受信すると、ユーザ権限レベルマッピング部２３２は、ユーザ識別情報に基づいてユーザ権限レベルテーブル２５０を参照して抽象化した権限レベルを取得し（１）、ユーザ区分マッピング２３３は、ユーザ識別情報に基づいてドキュメントプロファイル管理テーブル２６０を参照して抽象化した関係者又は非限定を示す関係者区分を取得し（２）、アクセス種別情報はそのままとし（３）、ゾーンマッピング部２３４は、コンテキスト情報に基づいてドキュメントプロファイル管理テーブル２６０とゾーン管理テーブル２７０とを参照して抽象化したゾーン内又はゾーン外を示すゾーン区分を取得し（４）、ドキュメントセキュリティ属性マッピング部２３５は、ドキュメント識別情報に基づいてドキュメントプロファイル管理テーブル２６０とプリントプロファイル管理テーブル２８０とを参照して抽象化した機密レベルと文書カテゴリとを取得する（５）。

上記において、コンテキスト情報にて時間帯が設定されるように構成し、所定時間内又は所定時間外を示す時間区分を取得するようにしても良い。

マッピング部２３２から２３５の夫々を１つの抽象化処理部として構成しても良い。この場合、１つの抽象化処理部は、１つ以上の管理テーブルを参照する構成となる。

或いは、権限レベルと関係者区分とをユーザセキュリティ属性、機密レベルと文書カテゴリとをドキュメントセキュリティ属性、そして、ゾーン区分をアクセス環境属性等の３種類の属性に分類することができるため、属性毎に抽象化処理部を構成するようにしても良い。この場合、抽象化処理部は、１つ以上のマッピング処理部を有し、各マッピング処理部は、１つ以上のテーブルを参照する構成となる。

ポリシーベースアクセス制御判断部２４１は、抽象化処理部２３１によって抽象化された情報をパラメータとして受信し、ポリシーファイル２４０に記載されたアクセス制御ルール（ポリシー）に従ってアクセス制御を判断する。ポリシーファイル２４０は、外部から設定可能である。従って、企業のセキュリティポリシーに応じて変更が容易となる。

本実施例では、抽象化処理部２３１とポリシーベースアクセス制御判断部２４１との２段階による処理によって、汎用的なセキュリティポリシーに従いながら、また、セキュリティポリシーの変更にも柔軟に対応しつつアクセス制御判断を行うことができる。

また、抽象化処理部２３１を備えることによって、セキュリティポリシーの変更によって、アプリシステム４００が提供する情報の形式を変更する必要がない。セキュリティポリシーの変更に応じたアプリシステム４００側のソフトウェアを変更する必要がないため、メンテナンスが容易となる。

各ドキュメントに対してＡＣＬ（Access Control List）というものを管理して、どのユーザにはどのようなアクセスを許可或いは禁止する、というアクセス制御を行うことは可能である。そして、そのようなＡＣＬをセキュリティポリシーと呼んでいる従来システムもある（米国特許第６、２８９、４５０号）。しかしながら、従来システムでは、ドキュメント毎にポリシーを設定してしまっているようなもので、「マル秘は関係者のみアクセス可能」、いうような「組織」の企業秘密管理規則（ポリシー）通りに適用されているかどうかが分からないという問題がある．
本発明に係るアクセス制御を判断するセキュリティサーバ２００は、アクセス制御のための汎用的な判断ルールと、各ドキュメントの詳細なセキュリティ設定とを分離して、ドキュメントやユーザの属性を抽象的なセキュリティ属性にマッピングした上でアクセス判断をする。また、その汎用的な判断ルールをポリシーファイルとして記述できるようにすることでルールが固定されているのではなく入れ替えが可能である。

判断ルールをソフトウェアのロジックとしてプログラミングしている例は他にもあるであろうが、その判断ルールを組織のセキュリティポリシーに応じて様々に定義して設定できるようにしている例はない．
セキュリティサーバ２００によって管理されるテーブルのデータ構造について説明する。

図５は、ユーザ権限レベルテーブルのデータ構造を示す図である。図５において、ユーザ権限レベルテーブル２５０のデータ構造２５１は、「UserMapList{userMap[] userMap;};」を示すコード２５２により、ユーザ毎にユーザの権限を示すｕｓｅｒＭａｐを配列によって管理して複数のユーザを管理するＵｓｅｒＭａｐＬｉｓｔで構成される。

このｕｓｅｒＭａｐは、「String principalId;」を示すコード２５３−１により文字列で示されるユーザＩＤ又はグループＩＤと、「String entryType;」を示すコード２５３−２によりユーザ又はグループ等の文字列で示されるエントリのタイプと、「String leveleId;」を示すコード２５３−３により文字列で示される権限レベルとで構成される。

アプリシステム４００を利用するユーザ５２毎にｕｓｅｒＭａｐのエントリをＵｓｅｒＭａｐＬｉｓｔに作成して、ユーザ５２を登録する。

図６は、ドキュメントプロファイル管理テーブルのデータ構造を示す図である。図６において、ドキュメントプロファイル管理テーブル２６０のデータ構造２６１は、「DocProfileTable{DocProfile[] docProfiles;};」を示すコード２６２により、電子文書毎にその電子文書に対するセキュリティポリシーを示すｄｏｃＰｒｏｆｉｌｅを配列によって管理して複数の電子文書を管理するＤｏｃＰｒｏｆｉｌｅＴａｂｌｅで構成される。

このｄｏｃＰｒｏｆｉｌｅは、「String docId;」を示すコード２６３−１により文字列で示される電子文書と、「String DocCategory;」を示すコード２６３−２により文字列で示される文書カテゴリと、「String docLevel;」を示すコード２６３−３により文字列で示される機密レベルと、「String[] relatedPersons;」を示すコード２６３−４により文字列で示される関係者の配列によって構成される複数の関係者のリストと、「String[] zones;」を示すコード２６３−５により文字列で示されるゾーンＩＤの配列によって構成される複数のゾーンＩＤのリストと、「Date nondisclosure;」を示すコード２６３−６により日付で示される秘密保持期間と、「Date retention;」を示すコード２６３−７により日付で示される保存期限と、「Date validity;」を示すコード２６３−８により日付で示される有効期限とで構成される。

アクセス制御する電子文書毎にＤｏｃＰｒｏｆｉｌｅのエントリをＤｏｃＰｒｏｆｉｌｅＴａｂｌｅに作成して、電子文書を登録する。文書ＩＤは、電子文書毎に一意に示される識別情報である。文書カテゴリ及び機密レベルはセキュリティポリシーによって使用される文書カテゴリ及び機密レベルの識別情報を指定する。

関係者リストには、その電子文書の関係者のユーザID又はグループIDが列挙される。ゾーンには、その電子文書へのアクセスが許可されるゾーンを特定するゾーンＩＤのリストが指定される。

図７は、ゾーン管理テーブルのデータ構造を示す図である。図７において、ゾーン管理テーブル２７０のデータ構造２７１は、「ZoneInfo Table{ZoneInfo[] zones};」を示すコード２７２により、ゾーン毎にゾーンを特定する情報を示すＺｏｎｅＩｎｆｏを配列によって管理して複数のゾーンを管理するＺｏｎｅＩｎｆｏＴａｂｌｅで構成される。

このＺｏｎｅＩｎｆｏは、「String id;」を示すコード２７３−１により文字列で示されるゾーンＩＤと、「String name;」を示すコード２７３−２により文字列で示されるゾーン名と、「AddressInfo[] addresses;」を示すコード２７３−３によりAddressInfo[]の配列によって示されるゾーンのアドレスとで構成される。

コード２７３−３によって記述されるＡｄｄｒｅｓｓＩｎｆｏのデータ構造は、「String address;」を示すコード２７５−１により文字列で示されるＩＰアドレス又はＭＡＣアドレスと、「String addressType;」を示すコード２７５−２により文字列で示される「ＩＰ」又は「ＭＡＣ」と、「String netmask;」を示すコード２７５−３によりＩＰアドレスの場合に「255.255.255.0」等の文字列で示されるサブネットマスクとで構成される。

ゾーン管理テーブル２７０は、アクセスを許可するゾーンをアドレスのリストによって管理するテーブルである。一つのゾーンＩＤに対して複数のＩＰアドレス又はＭＡＣアドレスを列挙して割り当てて管理する。

図８は、プリントプロファイル管理テーブルのデータ構造を示す図である。図８において、プリントプロファイル管理テーブル２８０のデータ構造２８１は、「PrintProfileTable{PrintProfile[] printprofiles;};」を示すコード２８１により、プリント毎にプリントに関するプロファイルを示すＰｒｉｎｔＰｒｏｆｉｌｅを配列によって管理して複数のプリントプロファイルを管理するＰｒｉｎｔＰｒｏｆｉｌｅＴａｂｌｅで構成される。

ＰｒｉｎｔＰｒｏｆｉｌｅは、「String printId;」を示すコード２８３−１により文字列で示されるプリントＩＤと、「String docId;」を示すコード２８３−２により文字列で示される電子文書の文書ＩＤと、「Date printedDate;」を示すコード２８３−３により日付で示されるプリント日時と、「String printedUserId;」を示すコード２８３−４により文字列で示されるプリントユーザＩＤと、「String printedUserName;」を示す２８３−５により文字列で示されるプリントユーザ名とで構成される。

アクセス制御されている電子文書がプリントされる毎に、ＰｒｉｎｔＰｒｏｆｉｌｅのエントリをＰｒｉｎｔＰｒｏｆｉｌｅＴａｂｌｅに作成することによって登録する。プリントＩＤは、プリント毎に一意に特定される識別情報である。文書ＩＤは、プリントした文書の文書ＩＤである。

以下に具体的なアクセス制御のシーケンスを説明する。文書管理システム１００、デジタル複合機７０、ドキュメントビューア５３の夫々について説明する。
［文書管理システムでのアクセス制御］
文書管理システム１００でのアクセス制御について、図９を参照しつつ図１０で説明する。

図９は、文書管理システムでのアクセス制御シーケンスを示す図である。図１０は、文書管理システムでのアクセス制御処理を説明するためのフローチャート図である。図９及び図１０中、図９に示すアクセス制御シーケンスにおける各処理と、図１０の各処理の説明と同一符号によって対応付けられる。

図９及び図１０において、文書管理システム１００は、端末５１からユーザ５２のログインの要求と共に、ユーザＩＤとパスワードとを受け取る（Ｓ１００１）。

文書管理システム１００は、受け取ったユーザＩＤとパスワードとをユーザ管理サーバ３００に送信して認証要求を行う（Ｓ１００２）。ユーザ管理サーバ３００は、受け取ったユーザＩＤとパスワードとで認証処理を行う（Ｓ１００３）。ユーザ管理サーバ３００は、認証の成功又は失敗を示す認証結果情報を文書管理システム１００に返す（Ｓ１００４）。認証結果情報では、ユーザを識別するユーザ識別情報と、認証の成功又は失敗を示す情報とが含まれる。

文書管理システム１００は、認証結果情報に応じた処理を行う（Ｓ１００５）。認証結果情報が認証の成功を示す場合、文書管理システム１００は、ユーザ管理サーバ３００から受け取った認証結果情報を端末５１へ送信し、Ｓ１００６へ進む。一方、認証結果情報が認証の失敗を示す場合、文書管理システム１００は、アクセス制御処理を終了する。

端末５１は、文書管理システム１００に保管されているサーバドキュメント６１に対する文書読込要求を文書ＩＤを指定することによって、文書管理システム１００に対して行う（Ｓ１００６）。

文書管理システム１００は、そのユーザ５２の認証結果情報とサーバドキュメント６１の文書ＩＤ、アクセス種別、クライアントのコンテキスト情報をセキュリティサーバ２００に送信して、サーバドキュメント６１に対するアクセス制御を問い合わせる（Ｓ１００７）。アクセス種別には、例えば、文書読込要求に応じた読込アクセスが指定される。

セキュリティサーバ２００は、受け取った情報に基づいてアクセスを許可するか否かを判断する（Ｓ１００８）。

セキュリティサーバ２００は、判断結果を文書管理システム１００に返す（Ｓ１００９）。文書管理システム１００は、セキュリティサーバ２００から受信した判断結果に応じた処理を行う（Ｓ１００９）。判断結果が「許可」を示す場合、文書管理システム１００は、判断結果で指定される要件を処理し、Ｓ１０１１へ進む。一方、判断結果が「禁止」を示す場合、アクセスは禁止され、アクセス制御処理を終了する。

文書管理システム１００は、端末５１から要求されたアクセス要求に応じた処理を行い、サーバドキュメント６１を端末５１に送信し、アクセス制御処理を正常に終了する（Ｓ１０１１）。

Ｓ１００２でのユーザ認証の問い合わせをセキュリティサーバ２００を経由して行っても良い。ユーザ５２を認証する方法は、ユーザＩＤとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。

次に、ユーザ管理サーバ３００で行われる認証処理について図１１で説明する。図１１は、ユーザ管理サーバでの認証処理を説明する図である。図１１において、ユーザ管理サーバ３００は、文書管理システム１００から受け取ったユーザＩＤとパスワードとをユーザ管理３１０と照合してユーザ５２に対する認証を行う（Ｌ００１１）。

ユーザ５２の認証が成功したか否かを判断する（Ｌ００１２）。ユーザ５２の認証が成功した場合、ユーザ管理サーバ３００は、そのユーザ５２が所属しているグループＩＤのリストを取得して（Ｌ００１３）、ユーザＩＤと、ユーザ名と、所属するグループＩＤのリストとによって認証結果情報を作成する（Ｌ００１４）。認証結果情報には、ユーザを識別するユーザ識別情報と、認証の成功を示す情報とが含まれる。

ユーザ管理サーバ３００は、作成した認証結果情報を文書管理システム１００へ返し（Ｌ００１５）、ユーザ５２の認証が成功した場合の処理を終了する（Ｌ００１６）。そして、認証処理を終了する（Ｌ００２０）。

一方、ユーザ５２の認証が失敗した場合（Ｌ００１７）、ユーザ管理サーバ３００は、認証の失敗を示す認証結果情報を作成し文書管理システム１００へ返し（Ｌ００１８）、ユーザ５２の認証が失敗した場合の処理を終了すると共に（Ｌ００１９）、認証処理を終了する（Ｌ００２０）。

図１２は、認証結果情報のデータ構造を示す図である。図１２において、認証結果情報のデータ構造５０１は、例えば、構造体ＡｕｔｈＩｎｆｏで定義され、「String userId;」を示すコード５０２−１により文字列で示されるユーザＩＤと、「String username;」を示すコード５０２−２により文字列で示されるユーザ名と、「String[] groups;」を示すコード５０２−３により文字列で示されるユーザ５２が所属するグループのグループＩＤの配列によって構成される複数のグループＩＤのリストとで構成される。

次に、Ｓ１００８でのセキュリティサーバ２００によって行われる許可処理について図１３、図１４及び図１５で説明する。図１３、図１４及び図１５は、文書管理システムからの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。

図１３、図１４及び図１５では、端末５１で文書管理システム１００のサーバドキュメント６１を読み込むオペレーションがユーザ５２によって行われたことによって、端末５１から文書読込要求が文書管理システム１００へ送信された場合の処理を例示している。端末５１での他のオペレーションとして、例えば、プロパティ参照、オリジナル参照、改訂、削除、保存等があり、夫々、プロパティ参照要求、オリジナル参照要求、改訂要求、削除要求、保存要求等として文書管理システム１００からセキュリティサーバ１００へ送信される。

オリジナル参照のオペレーションは、文書管理システム１００に管理されているオリジナルのサーバドキュメント６１を取得するアクセスである。また、例示される文書読込のオペレーションは、オリジナルのサーバドキュメント６１を特別なドキュメントビューア５３でしか開くことができないように変換したサーバドキュメント６１を取得するアクセスである。

また、夫々の要求に対するセキュリティサーバ１００での許可処理は同様である。

図１３において、セキュリティサーバ２００は、認証結果情報、文書ID、アクセス種別、コンテキスト情報を判断要求をした文書管理システム１００から受け取る（Ｌ００３１）。例えば、アクセス種別には、「サーバドキュメントに対する文書読込」が指定される。アクセス種別によって、ドキュメント６０の種別（つまり、サーバドキュメント６１）と、オペレーションの種別（つまり、文書読込）とが特定される。

セキュリティサーバ２００は、文書管理システム１００から受け取った文書ＩＤ（docid）に該当するドキュメントプロファイル（docProfile）をドキュメントプロファイル管理テーブル２６０から取得する（Ｌ００３２）。

セキュリティサーバ２００は、ドキュメントプロファイル（docProfile）を参照して文書カテゴリ（docCategory）と機密レベル（docLevel）とを取得する（Ｌ００３３）。

セキュリティサーバ２００は、ドキュメントプロファイル（docProfile）を参照して関係者リスト（relatedPersons）を取得する（Ｌ００３４）。

セキュリティサーバ２００は、関係者リスト（relatedPersons）に認証結果情報（authInfo）のユーザID（userId）または所属グループ（groups）が含まれているか否かを判別する（Ｌ００３５）。

含まれている場合、セキュリティサーバ２００は、ユーザカテゴリ（userCategory）に 関係者（RELATED_PERSONS）を設定する（Ｌ００３６）。一方、含まれていない場合、セキュリティサーバ２００は、ユーザカテゴリ（userCategory）に非限定（ANY）を設定する（Ｌ００３７）。

セキュリティサーバ２００は、ユーザ権限レベルテーブル（UserMapTable）を参照して、 ユーザＩＤ又はグループＩＤ（principalId）に対応するレベルを権限レベル（userLevel）に格納する（Ｌ００３８）。

セキュリティサーバ２００は、ドキュメントプロファイル（docProfile）を参照してゾーンIDリスト（zones）を取得する（Ｌ００３９）。

セキュリティサーバ２００は、ゾーン管理テーブル（ZoneInfoTable）を参照してゾーンIDリスト（zones）に対応するIPアドレス及びMACアドレスを取得して、許可アドレスリストを作成する（Ｌ００４０）。

セキュリティサーバ２００は、コンテキスト情報に含まれているアドレスが、作成した許可アドレスリストに含まれるか否かを判別する（Ｌ００４１）。

含まれている場合、セキュリティサーバ２００は、ゾーン（zone）に限定（RESTRICTED）を設定する（Ｌ００４２）。一方、含まれていない場合、セキュリティサーバ２００は、ゾーン（zone）に非限定（ANY）を設定する（Ｌ００４３）。

セキュリティサーバ２００は、セキュリティポリシーファイルをメモリにロードしてアクセス制限ルール（rule）の配列を取得する（Ｌ００４４）。

セキュリティサーバ２００は、個々のアクセス制御ルール（rule）について、以下のＬ００４６からＬ００７１までの処理を繰り返す（Ｌ００４５）。

セキュリティサーバ２００は、アクセス制御ルール（rule）の文書カテゴリ（docCategory）が非限定（ANY）又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール（rule）の文書レベル（docLevel）が非限定（ANY）又は文書レベル（docLevel）と一致するか否かを判断する（Ｌ００４６）。アクセス制御ルール（rule）の文書カテゴリ（docCategory）が非限定（ANY）又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール（rule）の文書レベル（docLevel）が非限定（ANY）又は文書レベル（docLevel）と一致する場合、セキュリティサーバ２００は、更にそのアクセス制御ルール（rule）の各アクセス制御リスト（Ace）について、以下のL００４９からL００６４までの処理を繰り返す（Ｌ００４８）。

一方、一致しない場合（Ｌ００７０及びＬ００７１）、セキュリティサーバ２００は、Ｌ００４５に戻り、次のアクセス制御ルール（rule）について上記処理を繰り返す。

セキュリティサーバ２００は、一致する場合に、アクセス制御リスト（Ace）のユーザカテゴリ（userCategory）が非限定（ANY）又はユーザカテゴリ（userCategory）と一致し、且つ、アクセス制御リスト（Ace）のユーザレベル（UserLevel）が非限定（ANY）又はユーザレベル（userLevel）と一致し、且つ、アクセス制御リスト（Ace）のゾーン（Zone）が非限定（ANY）又はゾーン（zone）と一致するか否かを判断する（Ｌ００４９、Ｌ００５０及びＬ００５１）。アクセス制御リスト（Ace）のユーザカテゴリ（userCategory）が非限定（ANY）又はユーザカテゴリ（userCategory）と一致し、且つ、アクセス制御リスト（Ace）のユーザレベル（UserLevel）が非限定（ANY）又はユーザレベル（userLevel）と一致し、且つ、アクセス制御リスト（Ace）のゾーン（Zone）が非限定（ANY）又はソーン（zone）と一致する場合、セキュリティサーバ２００は、アクセス制御リスト（Ace）の各オペレーション（Operation）について、以下のＬ００５３からＬ００５８を繰り返す（Ｌ００５２）。

一方、一致しない場合（Ｌ００６４及びＬ００６５）、セキュリティサーバ２００は、Ｌ００４８に戻り、アクセス制御ルール（rule）の次のアクセス制御リスト（Ace）について上記処理を繰り返す。

セキュリティサーバ２００は、Ｌ００４９、Ｌ００５０及びＬ００５１での判断において一致すると判断した場合に、そのオペレーションのＩＤ（Operation.Id）がオペレーション（operation）と一致するか否かを判断する（L００５３）。一致する場合、判断結果情報（decisionInfo）の許可（allowed）に許可（true）を格納する（Ｌ００５４）。また、セキュリティサーバ２００は、そのオペレーション（operation）に指定されている要件（requirement）を全て判断結果情報に格納し（L００５５）、Ｌ００７２へと進む（L００５６）。

一方、一致しない場合（Ｌ００５８及びＬ００５９）、セキュリティサーバ２００は、Ｌ００５２に戻り、アクセス制御リスト（Ace）の次の各オペレーション（Operation）について上記処理を繰り返す。

アクセス制御リスト（Ace）の各オペレーション（Operation）に対する処理が終了すると、セキュリティサーバ２００は、該当するオペレーション（Operation）がなかったか否かを判断する（Ｌ００６０）。なかった場合、セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）に不許可（false）を格納し（Ｌ００６１）、Ｌ００７２へと進む（L００６３）。

一方、あった場合、セキュリティサーバ２００は、そのままＬ００７２へと進む（L００６３）。

Ｌ００４８におけるアクセス制御ルール（rule）の各アクセス制御リスト（Ace）に対する処理が終了すると、
セキュリティサーバ２００は、該当する各アクセス制御リスト（Ace）がなかったか否かを判断する（Ｌ００６６）。なかった場合、セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）に不許可（false）を格納し（Ｌ００６７）、Ｌ００７２へと進む（L００６３）。

一方、あった場合、セキュリティサーバ２００は、そのままＬ００７２へと進む（L００６９）。

Ｌ００４５において、個々のアクセス制御ルール（rule）に対する処理が終了すると、セキュリティサーバ２００は、該当するアクセス制御ルール（rule）があったか否かを判断する（Ｌ００７２）。なかった場合、セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）に不許可（false）を格納し（Ｌ００７３）、Ｌ００７５へと進む。一方、あった場合、セキュリティサーバ２００は、そのままＬ００７５へと進む。

セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）であるか否かを判断する（Ｌ００７５）。判断結果情報（decisionInfo）の許可（allowed）が不許可（false）である場合、その判断結果情報（decisionInfo）を判断要求をした文書管理システム１００に返し（Ｌ００７６）、許可処理を終了する（Ｌ００８２）。

一方、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）でない場合（Ｌ００７８）、その判断結果（decisionInfo）に含まれる要件（requirement）の補正処理を行い（Ｌ００７９）、その判断結果情報（decisionInfo）を判断要求をした文書管理システム１００に返し（Ｌ００８０）、許可処理を終了する（Ｌ００８２）。

文書管理システム１００からセキュリティサーバ２００へ送信されるコンテキスト情報のデータ構造について図１６で説明する。図１６は、コンテキスト情報のデータ構造を示す図である。

図１６において、コンテキスト情報は、ユーザ５２が使用している端末５１のアドレスを示す情報であって、コンテキスト情報のデータ構造５１１は、例えば、構造体ＣｏｎｔｅｘｔＩｎｆｏで定義され、「String ipAddress;」を示すコード５１３−１により文字列で示されるＩＰアドレスと、「String macAddress;」を示すコード５１３−２により文字列で示されるＭＡＣアドレスとで構成される。

セキュリティサーバ２００から文書管理システム１００へ送信される判断結果情報（decisionInfo）について図１７で説明する。図１７は、判断結果情報のデータ構造を示す図である。

図１７において、判断結果情報は、アクセス制御の判断結果を示す情報であって、判断結果情報のデータ構造５２１は、例えば、構造体ＤｅｃｉｓｉｏｎＩｎｆｏで定義され、「Boolean allowed;」を示すコード５２３−１により真偽で示される許可情報と、「Requirement[] requirements;」を示すコード５２３−２により要件の配列によって構成される複数の要件とで構成される。

更に、個々の要件は、構造体Ｒｅｑｕｉｒｅｍｅｎｔで定義され、「String requirement;」を示すコード５２５−１により文字列で示される要件を識別する要件ＩＤと、「Property[] supplements;」を示すコード５２５−２により補足情報の配列によって構成される複数の補足情報と、「byte[] data;」を示すコード５２５−３によりバイトの配列によって構成される補足データと、「Requirement[] alternatives;」を示すコード５２５−４により要件の配列によって構成される複数の代替要件とで構成される。

補足情報は、構造体Ｐｒｏｐｅｒｔｙで定義され、「String name;」を示すコード５２７−１により文字列で示される名前と、「String value;」を示すコード５２７−２により文字列で示される値とを構成される。

次に文書管理システム１００での要件の補正処理について図１８で説明する。図１８は、文書管理システムでの用件の補正処理を説明するためのフローチャート図である。

図１８において、文書管理システム１００は、判断結果情報（decisionInfo）の要件（requirement）に含まれる各補足情報（supplement）について、Ｌ１１０２からＬ１１１０まで繰り返す（Ｌ１１０１）。

文書管理システム１００は、補足情報のプロパティ（Property）の名前（name）に固定画像（static_image）が指定されているか否かを判断する（Ｌ１１０２）。固定画像（static_image）が指定されている場合、文書管理システム１００は、補足情報のプロパティ（Property）の値（value）に指定されているスタンプ画像ファイルのデータをローカルハードディスクから読み出して要件（requirement）の補足データ（data）に格納し（Ｌ１１０３）、Ｌ１１０５へ進む。

一方、固定画像（static_image）が指定されていない場合、文書管理システム１００は、そのままＬ１１０５へ進む。

ここで、固定画像とは、例えば、スタンプ画像等である。

文書管理システム１００は、補足情報のプロパティ（Property）の名前（name）に動的画像（dynamic_image）が指定され、 且つ 、オペレーション（operation）が”プリント”であるか否かを判断する（Ｌ１１０５）。補足情報のプロパティ（Property）の名前（name）に動的画像（dynamic_image）が指定され、 且つ 、オペレーション（operation）が”プリント”である場合、新しいプリントプロファイル（printProfile）を作成する（Ｌ１１０６）。また、文書管理システム１００は、プリントプロファイル（printProfile）のプリントＩＤ（printId）を識別画像データにエンコードして（Ｌ１１０７）、識別画像データを要件（requirement）の補足データ（data）に格納する（Ｌ１１０８）。そして、文書管理システム１００は、要件の補正処理を終了する。

一方、補足情報のプロパティ（Property）の名前（name）に動的画像（dynamic_image）が指定されていない、又は 、オペレーション（operation）が”プリント”でない場合、文書管理システム１００は、そのまま要件の補正処理を終了する。

ここで、動的画像とは、バーコード画像又は識別パターン画像等である。

次に、文書管理システム１００での要件処理について図１９及び図２０で説明する。図１９及び図２０は、文書管理システムでの要件処理を説明するためのフローチャート図である。

図１９において、文書管理システム１００は、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）を示しているか否かを判断する（Ｌ１１２１）。不許可を示している場合、文書管理システム１００は、アクセスを拒否して要件処理を終了する（Ｌ１１２２）。

一方、不許可を示していない場合、判断結果情報（decisionInfo）の各要件（requirement）について、Ｌ１１２５からL１１６０までを繰り返す（Ｌ１１２４）。

文書管理システム１００は、文書管理システム１００がサポートしていない要件（requirement）が指定されているか否かを判断する（Ｌ１１２５）。文書管理システム１００がサポートしていない要件（requirement）が指定されていない場合、文書管理システム１００は、Ｌ１１３１へ進む。

一方、文書管理システム１００がサポートしていない要件（requirement）が指定されている場合、文書管理システム１００は、更に、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されているか否かを判断する（Ｌ１１２６）。要件（requirement）の代替要件（alternative）にサポートしていないものが指定されている場合、文書管理システム１００は、アクセスを拒否して要件処理を終了する（Ｌ１１２７）。

一方、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されていない場合、文書管理システム１００は、要件（requirement）の代替要件（alternative）を処理する。

続けて、文書管理システム１００は、要件（requirement）にログの記録（record_andit_data）が指定されているか否かを判断する（Ｌ１１３１）。ログの記録（record_andit_data）が指定されている場合、文書管理システム１００は、ユーザＩＤ（userid）と、文書ＩＤ（docid）と、オペレーション（operation）と、日時と、コンテキスト情報（contextInfo）とを含むログデータを生成する（Ｌ１１３２）。

そして、文書管理システム１００は、ログデータをセキュリティサーバに送信する（Ｌ１１３３）。文書管理システム１００は、ログデータの送信に失敗したか否かを判断する（Ｌ１１３４）。ログデータの送信に失敗した場合、文書管理システム１００は、アクセスを拒否して要件処理を終了する（Ｌ１１３５）。一方、ログデータの送信に成功した場合、文書管理システム１００は、そのままL１１３８へ進む。

更に、文書管理システム１００は、要件（requirement）に暗号化（encryption）が指定されているか否かを判断する（L１１３８）。暗号化（encryption）が指定されている場合、文書管理システム１００は、保存しているドキュメントを暗号化する（L１１３９）。一方、暗号化（encryption）が指定されていない場合、文書管理システム１００は、そのままL１１４１へ進む。

続けて、文書管理システム１００は、要件（requirement）に電子文書の原本性の確保（integrity_protection）が指定されているか否かを判断する（L１１４１）。電子文書の原本性の確保（integrity_protection）が指定されている場合、文書管理システム１００は、ドキュメントを原本性確保支援システムに転送して保存する。原本性確保支援システムは、例えば、特開２０００−２８５０２４号で開示されているようなシステムであれば良い。また、文書管理システム１００内にこのような原本性確保支援システムを構成しても良い。

一方、要件（requirement）に電子文書の原本性の確保（integrity_protection）が指定されていない場合、文書管理システム１００は、そのままL１１４４へ進む。

更に、文書管理システム１００は、要件（requirement）に電子文書へのアクセスに多段階認証を認めること（multi_authentication）が指定されているか否かを判断する（Ｌ１１４４）。指定されていない場合、文書管理システム１００は、そのままＬ１１５０へ進む。

一方、指定されている場合、文書管理システム１００は、端末５２を使用しているユーザ５２に厳密なユーザ認証（指紋認証など）を要求する（Ｌ１１４５）。厳密なユーザ認証後、文書管理システム１００は、厳密な認証に失敗したか否かを判断する（Ｌ１１４６）。失敗した場合、文書管理システム１００は、アクセスを拒否して要件処理を終了する（Ｌ１１４７）。一方、失敗でない場合、文書管理システム１００は、そのまあＬ１１５０へ進む。

続けて、文書管理システム１００は、要件（requirement）に電子文書のバーション管理（versioning）が指定されているか否かを判断する（Ｌ１１５０）。指定されている場合、文書管理システム１００は、改訂されたドキュメントを新しい版として保存して（Ｌ１１５１）、L１１５３へ進む。一方、指定されていない場合、文書管理システム１００は、そのままL１１５３へ進む。

更に、文書管理システム１００は、要件（requirement）に電子文書の完全削除（complete_deletion）が指定されているか否かを判断する（Ｌ１１５３）。指定されている場合、文書管理システム１００は、削除したドキュメントに対して完全削除処理を実行して（Ｌ１１５４）、Ｌ１１５６へ進む。一方、指定されていない場合、文書管理システム１００は、そのままＬ１１５６へ進む。

続けて、文書管理システム１００は、要件（requirement）に警告の表示（show_alarm）が指定されているか否かを判断する（Ｌ１１５６）。指定されている場合、文書管理システム１００は、要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで警告文字列を作成し（Ｌ１１５７）、警告文字列をダイアログボックスでユーザ５２に表示する（Ｌ１１６８）。そして、次の要件（requirement）に付いて上記同様の処理を繰り返すため、Ｌ１１２４へ戻る。一方、指定されていない場合、文書管理システム１００は、そのままＬ１１２４へ戻る。

全ての要件（requirement）について上記処理が行われた後、文書管理システム１００は、端末５１から要求されたアクセス処理を行い（Ｌ１１６１）、要件処理を終了する（Ｌ１１６２）。

図１９及び図２０での説明において、判断結果情報（decisionInfo）の要件（requirement）について並列に処理しているが、対応しなければならない要件（requirement）はオペレーション（operation）毎に決まっているので上記のようにすべての要件（requirement）のパターンに対する処理を行わなくても良い。例えば、電子文書の完全削除（complete_deletion）が要件（requirement）として指定されるのはサーバドキュメント６１に対してなされるときだけである。説明を簡単にするために上記のような処理例とした。文書管理システム１００は、代替要件の処理についても上記と同様の処理を実行する。

このように、文書管理システム１００はセキュリティサーバ２００に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理及び代替要件の処理を盛り込むことで柔軟な処理が可能となる。
［デジタル複合機でのアクセス制御］
デジタル複合機７０でのアクセス制御について、図２１を参照しつつ図２２で説明する。

図２１は、デジタル複合機でのアクセス制御シーケンスを示す図である。図２２は、デジタル複合機でのアクセス制御処理を説明するためのフローチャート図である。図２１及び図２２中、図２１に示すアクセス制御シーケンスにおける各処理と、図２２の各処理の説明とが同一符号によって対応付けられる。

図２１及び図２２において、デジタル複合機７０は、ユーザ５２のログインの要求と共に、ユーザＩＤとパスワードとを受け取る（Ｓ２００１）。

デジタル複合機７０は、受け取ったユーザＩＤとパスワードとをユーザ管理サーバ３００に送信して認証要求を行う（Ｓ２００２）。ユーザ管理サーバ３００は、受け取ったユーザＩＤとパスワードとで認証処理を行う（Ｓ２００３）。ユーザ管理サーバ３００は、認証の成功又は失敗を示す認証結果情報をデジタル複合機７０に返す（Ｓ２００４）。

デジタル複合機７０は、認証結果情報に応じた処理を行う（Ｓ２００５）。認証結果情報が認証の成功を示す場合、デジタル複合機７０は、ユーザ管理サーバ３００から受け取った認証結果情報を端末５１へ送信し、Ｓ２００６へ進む。一方、認証結果情報が認証の失敗を示す場合、デジタル複合機７０は、アクセス制御処理を終了する。

ユーザ５２がデジタル複合機７０で紙原稿の複写を要求する（Ｓ２００６）。

デジタル複合機７０は、紙原稿の複写の要求を受信すると、紙原稿を識別するために、紙原稿をスキャンした画像データから識別用の領域を切り出す（Ｓ２００７）。

そのユーザ５２の認証情報と、切り出し画像と、アクセス種別と、コンテキスト情報とをセキュリティサーバ２００に送って、アクセス制御を問い合わせる（Ｓ２００８）。アクセス種別には、例えば、複写要求に応じた複写アクセスが指定される。

セキュリティサーバ２００は受け取った情報に基づいて、アクセスを許可するか否かを判断する（Ｓ２００９）。セキュリティサーバ２００は、判断結果をデジタル複合機に返す（Ｓ２０１０）。

デジタル複合機７０は、セキュリティサーバ２００から受信した判断結果に応じた処理を行う（Ｓ２０１１）。判断結果が「許可」を示す場合、デジタル複合機７０は、判断結果に含まれる要件を処理する。一方、判断結果が「禁止」を示す場合、デジタル複合機７０は、アクセスを行わずアクセス制御処理を終了する。

デジタル複合機７０は、ユーザに要求されたにアクセス要求（複写要求）を処理して、複写した紙を出力し、アクセス制御処理を終了する（Ｓ２０１２）。

上記例では、アクセス要求が複写要求である場合について説明したが、スキャン要求、ファックス送信要求等についても同様の処理を行い、例えば、アクセス要求がスキャン要求である場合、スキャンした画像データを所定の記憶領域に格納し、アクセス要求がファックス送信要求である場合、ユーザ５２によって指定された相手先へスキャンした画像データをファックス送信する。

Ｓ２００２でのユーザ認証の問い合わせをセキュリティサーバ２００を経由して行っても良い。ユーザを認証する方法は、ユーザＩＤとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。

Ｓ２００３でのユーザ管理サーバ３００による認証処理は、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。また、認証結果情報のデータ構造についても、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。

Ｓ２００９でのセキュリティサーバ２００によって行われる許可処理について図２３、図２４及び図２５で説明する。図２３、図２４及び図２５は、デジタル複合機からの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。

図２３、図２４及び図２５では、ユーザ５２がデジタル複合機７０でペーパードキュメント６２を複写する複写要求を行った場合の処理を例示している。デジタル複合機７０での他のオペレーションとして、例えば、ファックス送信、スキャン等があり、夫々、ファックス送信要求、スキャン要求等としてデジタル複合機７０からセキュリティサーバ１００へ送信される。

ファックス送信のオペレーションは、デジタル複合機７０でスキャンしたペーパードキュメント６２をユーザ５２が指定した宛先へファックス送信するアクセスである。また、スキャンのオペレーションは、ペーパードキュメント６２をスキャンし、所定の記憶領域に画像データを格納するオペレーションである。

また、夫々の要求に対するセキュリティサーバ１００での許可処理は同様である。

図２３において、セキュリティサーバ２００は、認証結果情報と、文書IDと、アクセス種別と、コンテキスト情報とを判断要求をした文書管理システム１００から受け取る（Ｌ２０３１）。例えば、アクセス種別には、「ペーパードキュメントに対する複写」が指定される。アクセス種別によって、ドキュメント６０の種別（つまり、ペーパードキュメント６２）と、オペレーションの種別（つまり、複写）とが特定される。

セキュリティサーバ２００は、受け取った切り出し画像をデコードしてプリントＩＤ（printId）を得る（Ｌ２０３２）。

セキュリティサーバ２００は、デコードできないか否かを判断する（Ｌ２０３３）。デコードできない場合、セキュリティサーバ２００は、文書カテゴリ（docCategory）に不明（UNKNOWN）を設定し（Ｌ２０３４）、文書レベル（docLevel）に不明（UNKNOWN）を設定し（Ｌ２０３５）、ユーザカテゴリ（userCategory）に非限定（ANY）を設定し（Ｌ２０３６）、ゾーン（zone）に非限定（ANY）を設定する（Ｌ２０３７）。

一方、デコードできた場合、セキュリティサーバ２００は、プリントプロファイル管理テーブルを参照してプリントＩＤ（printId）に該当するプリントプロファイル（printProfile）を取得する（Ｌ２０４０）。

そして、セキュリティサーバ２００は、該当するプリントプロファイルが存在しないか否かを判断する（Ｌ２０４１）。存在しない場合、セキュリティサーバ２００は、文書カテゴリ（docCategory）に不明（UNKNOWN）を設定し（Ｌ２０４２）、文書レベル（docLevel）に不明（UNKNOWN）を設定し（Ｌ２０４３）、ユーザカテゴリ（userCategory）に非限定（ANY）を設定し（Ｌ２０４４）、ゾーン（zone）に非限定（ANY）を設定する（Ｌ２０４５）。

一方、該当するプリントプロファイルが存在する場合（Ｌ２０４７）、セキュリティサーバ２００は、プリントプロファイル（printProfile）から文書ID（docid）を取得し（Ｌ２０４８）、ドキュメントプロファイル管理テーブルを参照して文書ID（docid）に該当するドキュメントプロファイル（docProfile）を取得し（Ｌ２０４９）、ドキュメントプロファイル（docProfile）を参照して文書カテゴリ（docCategory）と機密レベル（docLevel）とを取得し（Ｌ２０５０）、ドキュメントプロファイル（docProfile）を参照して関係者リスト（relatedPersons）を取得する（Ｌ２０５１）。

セキュリティサーバ２００は、更に、関係者（relatedPersons）に認証情報のユーザID（userId）又は所属グループ（groups）が含まれているか否かを判別する（Ｌ２０５２）。含まれている場合、セキュリティサーバ２００は、ユーザカテゴリ（userCategory）に関係者（RELATED_PERSONS）に設定し（Ｌ２０５３）、Ｌ２０５５へ進む。一方、含まれていない場合、セキュリティサーバ２００は、ユーザカテゴリ（userCategory）に非限定（ANY）を設定し（Ｌ２０５４）、Ｌ２０５５へ進む。

セキュリティサーバ２００は、ドキュメントプロファイル（docProfile）を参照してゾーンIDリスト（zones）を取得する（Ｌ２０５５）。セキュリティサーバ２００は、ゾーン管理テーブル（ZoneInfoTable）を参照してゾーンIDリストに該当するIPアドレス、MACアドレスを取得する（許可アドレスリスト）（Ｌ２０５６）。

セキュリティサーバ２００は、コンテキスト情報に含まれているアドレスが、上記許可アドレスリストに含まれるか否かを判別する（Ｌ２０５７）。含まれる場合、セキュリティサーバ２００は、ゾーン（zone）に限定（RESTRICTED）を設定し（Ｌ２０５８）、Ｌ２０６２へ進む。一方、含まない場合、セキュリティサーバ２００は、ゾーン（zone）に非限定（ANY）を設定する（Ｌ２０５９）し、Ｌ２０６２へ進む。

セキュリティサーバ２００は、ユーザ権限レベルテーブル（UserMapTable）を参照して、ユーザID（userId）又は所属グループ（groups）が該当するレベルをユーザレベル（userLevel）に格納する（Ｌ２０６２）。

セキュリティサーバ２００は、セキュリティポリシーファイルをメモリにロードしてアクセス制御ルール（rule）の配列を取得する（Ｌ２０６3）。

セキュリティサーバ２００は、個々のアクセス制御ルール（rule）について以下のＬ２０６５からＬ２０６８までの処理を繰り返す（Ｌ００６４）。

セキュリティサーバ２００は、アクセス制御ルール（rule）の文書カテゴリ（docCategory）が非限定（ANY）又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール（rule）の文書レベル（docLevel）が非限定（ANY）又は文書レベル（docLevel）と一致するか否かを判断する（Ｌ００６５及びＬ２０６６）。一致する場合、セキュリティサーバ２００は、更に、そのアクセス制御ルール（rule）の各アクセス制御リスト（Ace）について、以下のL２０６８からL２０８３までの処理を繰り返す（Ｌ２０６７）。

一方、一致しない場合（Ｌ２０８８及びＬ２０８９）、セキュリティサーバ２００は、Ｌ２０６４に戻り、次のアクセス制御ルール（rule）について上記処理を繰り返す。

セキュリティサーバ２００は、Ｌ００６５及びＬ２０６６において一致する場合に、アクセス制御リスト（Ace）のユーザカテゴリ（userCategory）が非限定（ANY）又はユーザカテゴリ（userCategory）と一致し、且つ、アクセス制御リスト（Ace）のユーザレベル（UserLevel）が非限定（ANY）又はユーザレベル（userLevel）と一致し、且つ、アクセス制御リスト（Ace）のソーン（Zone）が非限定（ANY）又はゾーン（zone）と一致するか否かを判断する（Ｌ２０６８、Ｌ２０６９及びＬ２０７０）。アクセス制御リスト（Ace）のユーザカテゴリ（userCategory）が非限定（ANY）又はユーザカテゴリ（userCategory）と一致し、且つ、アクセス制御リスト（Ace）のユーザレベル（UserLevel）が非限定（ANY）又はユーザレベル（userLevel）と一致し、且つ、アクセス制御リスト（Ace）のソーン（Zone）が非限定（ANY）又はソーン（zone）と一致する場合、セキュリティサーバ２００は、アクセス制御リスト（Ace）の各オペレーション（Operation）について、以下のＬ２０７２からＬ２０７７を繰り返す（Ｌ２０７１）。

一方、一致しない場合（Ｌ００８２及びＬ００８３）、セキュリティサーバ２００は、Ｌ２０６７に戻り、アクセス制御ルール（rule）の次のアクセス制御リスト（Ace）について上記処理を繰り返す。

セキュリティサーバ２００は、Ｌ２０６８、Ｌ２０６９及びＬ２０７０での判断において一致すると判断した場合に、そのオペレーションのＩＤ（Operation.Id）がオペレーション（operation）と一致するか否かを判断する（L２０７２）。一致する場合、判断結果情報（decisionInfo）の許可（allowed）に許可（true）を格納する（Ｌ２０７３）。また、セキュリティサーバ２００は、そのオペレーション（operation）に指定されている要件（requirement）を全て判断結果情報に格納し（L２０７４）、Ｌ２０９８へと進む（L２０８１）。

一方、一致しない場合（Ｌ２０７６及びＬ２０７７）、セキュリティサーバ２００は、Ｌ２０７１に戻り、アクセス制御リスト（Ace）の次の各オペレーション（Operation）について上記処理を繰り返す。

Ｌ２０７１において、アクセス制御リスト（Ace）の各オペレーション（Operation）に対する処理が終了すると、セキュリティサーバ２００は、該当するオペレーション（Operation）がなかったか否かを判断する（Ｌ２０７８）。なかった場合、セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）に不許可（false）を格納し（Ｌ２０７９）、Ｌ２０９０へと進む（L２０８１）。

一方、あった場合、セキュリティサーバ２００は、そのままＬ２０９０へと進む（L２０８１）。

Ｌ２０６７において、個々のアクセス制御ルール（rule）に対する処理が終了すると、セキュリティサーバ２００は、該当するアクセス制御ルール（rule）があったか否かを判断する（Ｌ２０９０）。なかった場合、セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）に不許可（false）を格納し（Ｌ２０９１）、Ｌ２０９３へと進む。一方、あった場合、セキュリティサーバ２００は、そのままＬ２０９３へと進む。

セキュリティサーバ２００は、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）であるか否かを判断する（Ｌ２０９３）。判断結果情報（decisionInfo）の許可（allowed）が不許可（false）である場合、その判断結果情報（decisionInfo）を判断要求をしたデジタル複合機７０に返し（Ｌ２０９４）、許可処理を終了する（Ｌ２１００）。

一方、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）でない場合（Ｌ２０９６）、その判断結果（decisionInfo）に含まれる要件（requirement）の補正処理を行い（Ｌ２０９７）、その判断結果情報（decisionInfo）を判断要求をした文書管理システム１００に返し（Ｌ２０９８）、許可処理を終了する（Ｌ２１００）。

デジタル複合機７０からセキュリティサーバ２００へ送信されるコンテキスト情報のデータ構造は、文書管理システム１００からセキュリティサーバ２００へ送信されるコンテキスト情報のデータ構造と同様であるので、その説明を省略する。

セキュリティサーバ２００からデジタル複合機７０からへ送信される判断結果情報のデータ構造は、セキュリティサーバ２００から文書管理システム１００へ送信される判断結果情報のデータ構造と同様であるので、その説明を省略する。

デジタル複合機７０での要件の補正処理は、文書管理システム１００での要件の補正処理と同様であるので、その説明を省略する。

次に、デジタル複合機７０での要件処理について図２６、図２７及び図２８で説明する。図２６、図２７及び図２８は、デジタル複合機での要件処理を説明するためのフローチャート図である。

図２６において、デジタル複合機７０は、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）を示しているか否かを判断する（Ｌ２１２１）。不許可を示している場合、アクセスを拒否して終了する（Ｌ２１２２）。

一方、不許可を示していない場合、判断結果情報（decisionInfo）の各要件（requirement）について、Ｌ２１２５からL２１７８までを繰り返す（Ｌ２１２４）。

デジタル複合機７０は、デジタル複合機７０がサポートしていない要件（requirement）が指定されているか否かを判断する（Ｌ２１２５）。デジタル複合機７０がサポートしていない要件（requirement）が指定されていない場合、デジタル複合機７０は、Ｌ２１３１へ進む。

一方、デジタル複合機７０がサポートしていない要件（requirement）が指定されている場合、デジタル複合機７０は、更に、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されているか否かを判断する（Ｌ２１２６）。要件（requirement）の代替要件（alternative）にサポートしていないものが指定されている場合、デジタル複合機７０は、アクセスを拒否して要件処理を終了する（Ｌ２１２７）。

一方、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されていない場合、デジタル複合機７０は、要件（requirement）の代替要件（alternative）を処理する（Ｌ２１２８）。

続けて、デジタル複合機７０は、要件（requirement）にログの記録（record_andit_data）が指定されているか否かを判断する（Ｌ２１３１）。ログの記録（record_andit_data）が指定されている場合、デジタル複合機７０は、ユーザＩＤ（userid）と、文書ＩＤ（docid）と、オペレーション（operation）と、日時と、コンテキスト情報（contextInfo）とを含むログデータを生成する（Ｌ２１３２）。

そして、デジタル複合機７０は、ログデータをセキュリティサーバ２００に送信する（Ｌ２１３３）。デジタル複合機７０は、ログデータの送信に失敗したか否かを判断する（Ｌ２１３４）。ログデータの送信に失敗した場合、デジタル複合機７０は、アクセスを拒否して要件処理を終了する（Ｌ２１３５）。一方、ログデータの送信に成功した場合、デジタル複合機７０は、そのままL２１３８へ進む。

更に、デジタル複合機７０は、ラベルの印刷（show_label）が指定されているか否かを判断する（L２１３８）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されているスタンプ画像をドキュメントに印字して埋め込む（L２１３９）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１４１へ進む。

続けて、デジタル複合機７０は、ユーザ名の印刷（show_operator）が指定されているか否かを判断する（L２１４１）。指定されている場合、デジタル複合機７０は、ドキュメントに操作者名（operator）を印字して埋め込む（L２１４２）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１４４へ進む。

更に、デジタル複合機７０は、イメージログの記録（record_image_data）が指定されているか否かを判断する（L２１４４）。指定されている場合、デジタル複合機７０は、ユーザＩＤ（userid）と、文書ＩＤ（docid）と、オペレーション（operation）と、日時と、コンテキスト情報（contextInfo）と、ドキュメントデータ（スキャンデータ）とを含むイメージログデータを生成する（L２１４５）。続けて、デジタル複合機７０は、イメージログデータをデジタル複合機の内部ハードディスクに保存する（L２１４６）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１４８へ進む。

続けて、デジタル複合機７０は、警告の表示（show_alarm）が指定されているか否かを判断する（L２１４８）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで警告文字列を作成し（L２１４９）、警告文字列をオペパネ上でユーザに表示する（L２１５０）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１５２へ進む。

更に、デジタル複合機７０は、警告の印刷（print_alarm）が指定されているか否かを判断する（L２１５２）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで警告文字列を作成し（L２１５３）、警告文字列をドキュメントに印字して埋め込む（L２１５４）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１５６へ進む。

続けて、デジタル複合機７０は、ファックス送信の宛先制限（address_restriction）が指定されているか否かを判断する（L２１５６）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されている宛先条件で、ユーザが指定した宛先をチェックする（L２１５７）。更に、デジタル複合機７０は、宛先条件にマッチしないか否かを判断する（L２１５８）。マッチしない場合、デジタル複合機７０は、宛先が条件にマッチしないことをオペパネ上でユーザに通知して（L２１５９）、アクセスを拒否して終了する（L２１６０）。一方、マッチする場合、デジタル複合機７０は、そのままL２１６２へ進む。

L２１５６での判断によって指定されていないと判断した場合、デジタル複合機７０は、そのままL２１６２へ進む。

更に、デジタル複合機７０は、親展送信モードの使用（private_send）が指定されているか否かを判断する（L２１６３）。指定されている場合、デジタル複合機７０は、送信条件を親展送信モードに設定する（L２１６４）。そして、デジタル複合機７０は、親展送信モードに設定できないかを判断する（L２１６５）。設定できない場合、デジタル複合機７０は、相手が親展送信を受け付けられないことをオペパネ上でユーザに通知して（L２１６６）、アクセスを拒否して要件処理終了する（L２１６７）。一方、設定できる場合、デジタル複合機７０は、そのままL２１７０へ進む。

L２１６３での判断によって指定されていないと判断した場合、デジタル複合機７０は、そのままL２１７０へ進む。

続けて、デジタル複合機７０は、目に見える透かし文字の印刷（visible_watermark）が指定されているか否かを判断する（L２１７０）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで文字列を作成し（L２１７１）、その文字列をウォーターマークとしてドキュメントに埋め込む（L２１７２）。一方、指定されていない場合、デジタル複合機７０は、そのままL２１７４へ進む。

更に、デジタル複合機７０は、電子透かしの埋め込み（digital_watermark）が指定されているか否かを判断する（L２１７４）。指定されている場合、デジタル複合機７０は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで文字列を作成し（L２１７５）、その文字列を電子透かしとしてスキャンしたデータに埋め込む（L２１７６）。そして、次の要件（requirement）について上記同様の処理を繰り返すため、Ｌ２１２４へ戻る。一方、指定されていない場合、デジタル複合機７０は、そのままＬ２１２４へ戻る。

全ての要件（requirement）について上記処理が行われた後、デジタル複合機７０は、端末５１から要求されたアクセス処理を行い（Ｌ２１７９）、要件処理を終了する（Ｌ２１８０）。

上記より、デジタル複合機７０はセキュリティサーバ２００に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理や、代替要件の処理を盛り込むことで柔軟な処理が可能となる。

ペーパードキュメント６２の識別は１００％完全であるわけではないため、識別エラーが発生することもある。デジタル複合機７０で紙文書を複写する際にその紙文書が識別できなかった場合、基本的にはセキュリティ保護されていない一般の紙文書として複写できなければならない。そのような事情があるため、識別できなかったときにも何らかのセキュリティ処理を働かせられるようにする必要がある。そのようなケースも考え、識別できなかった原稿（UNKNOWNという文書カテゴリになる）の処理もポリシーに従って実行できるようにしている。
［ドキュメントビューアでのアクセス制御］
ドキュメントビューア５３でのアクセス制御について、図２９を参照しつつ図３０及び図３１で説明する。

図２９は、ドキュメントビューアでのアクセス制御シーケンスを示す図である。図３０及び図３１は、ドキュメントビューアでのアクセス制御処理を説明するためのフローチャート図である。図２９、図３０及び図３１中、図２９に示すアクセス制御シーケンスにおける各処理と、図３０及び図３１の各処理の説明と同一符号によって対応付けられる。

図２９及び図３０において、ドキュメントビューア５３は、ユーザ５２からファイル（ポータブルドキュメント６３）をオープンするオープン要求を受け取る（Ｓ３００１）。

ドキュメントビューア５３は、ポータブルドキュメント６３がセキュリティで保護されているかどうか確認する（Ｓ３００２）。ドキュメントビューア５３は、ポータブルドキュメント６３に対する保護の有無に応じた処理を行う（Ｓ３００３）。ポータブルドキュメント６３が保護されていない場合、ドキュメントビューア５３は、ポータブルドキュメント６３の内容を表示して、アクセス制御処理を終了する。一方、ポータブルドキュメント６３が保護されている場合、ドキュメントビューア５３は、そのままＳ３００４へ進む。

ドキュメントビューア５３は、ユーザにユーザＩＤとパスワードとの入力を求めて、それらを受け取る（Ｓ３００４）。

ドキュメントビューア５３は、受け取ったユーザＩＤとパスワードとをユーザ管理サーバに送信してユーザ認証を行う（Ｓ３００５）。

ユーザ管理サーバ３００は、受け取ったユーザＩＤとパスワードでユーザ認証処理を行い（Ｓ３００６）、認証結果情報をドキュメントビューア５３に返す（Ｓ３００７）。

ドキュメントビューア５３は、ユーザ管理サーバ３００から認証結果情報を受信すると、認証結果情報に応じた処理を行う（Ｓ３００８）。認証が失敗した場合、ドキュメントビューア５３は、ユーザ５２に認証エラーを通知して、アクセス制御処理を終了する。認証が成功した場合、ドキュメントビューア５３は、そのままＳ３００９へ進む。

ドキュメントビューア５３は、ポータブルドキュメント６３の中から文書ＩＤを取り出す（Ｓ３００９）。そして、ドキュメントビューア５３は、認証結果情報、文書ＩＤ、アクセス種別、ドキュメントビューア５３が動作している端末５２のコンテキスト情報をセキュリティサーバ２００に送信して、アクセス制御を問い合わせる（Ｓ３０１０）。アクセス種別は、例えば、オープン要求に応じた読込アクセスが指定される。

セキュリティサーバ２００は、受け取った情報に基づいてアクセスを許可するかどうか判断する（Ｓ３０１１）。セキュリティサーバ２００は、判断結果をドキュメントビューア５３に返す（Ｓ３０１２）。

判断結果が「許可」を示す場合、ドキュメントビューア５３は、判断結果に含まれる要件を処理する（Ｓ３０１３）。判断結果が「禁止」を示す場合は、アクセスは禁止され、アクセス制御処理を終了する。

ドキュメントビューア５３は、ユーザ５２に要求されたアクセス（ファイルオープン）を処理して、ポータブルドキュメント６３の内容を表示する（Ｓ３０１４）。

ドキュメントビューア５３は、ユーザ５２からポータブルドキュメント６３の印刷要求を受け取る（Ｓ３０１５）。

ドキュメントビューア５３は、認証結果情報、文書ＩＤ、アクセス種別、ドキュメントビューアが動作している端末のコンテキスト情報をセキュリティサーバに送信して、アクセス制御を問い合わせる（Ｓ３０１６）。アクセス種別は、例えば、印刷要求に応じた印刷アクセスが指定される。

セキュリティサーバ２００は、受け取った情報に基づいてアクセスを許可するかどうか判断し（Ｓ３０１７）、判断結果をドキュメントビューアに返す（Ｓ３０１８）。

判断結果が「許可」を示す場合、ドキュメントビューア５３は。判断結果に含まれる要件を処理する（Ｓ３０１９）。判断結果が「禁止」を示す場合は、アクセスは禁止され、アクセス制御処理を終了する。

ドキュメントビューア５３は、ユーザに要求されたアクセス（印刷）を処理して、ポータブルドキュメント６３の内容を印刷出力する（Ｓ３０２０）。

Ｓ３００５でのユーザ認証の問い合わせをセキュリティサーバ２００を経由して行っても良い。ユーザ５２を認証する方法は、ユーザＩＤとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。

Ｓ３００６でのユーザ管理サーバ３００による認証処理は、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。また、認証結果情報のデータ構造についても、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。

Ｓ３０１１及びＳ３０１７でのセキュリティサーバ２００によって行われる許可処理は、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。また、判断結果情報のデータ構造についても、文書管理システム１００におけるアクセス制御の場合と同様であるので、その説明を省略する。

ドキュメントビューア５３での要件の補正処理は、文書管理システム１００での要件の補正処理と同様であるので、その説明を省略する。

次に、ドキュメントビューア５３での要件処理について図３２から図３６で説明する。図３２から図３６は、ドキュメントビューアでの要件処理を説明するためのフローチャート図である。

図３２において、ドキュメントビューア５３は、判断結果情報（decisionInfo）の許可（allowed）が不許可（false）を示しているか否かを判断する（Ｌ３１２１）。不許可を示している場合、アクセスを拒否して終了する（Ｌ３１２２）。

一方、不許可を示していない場合、判断結果情報（decisionInfo）の各要件（requirement）について、Ｌ３１２５からL３２４３までを繰り返す（Ｌ３１２４）。

ドキュメントビューア５３は、ドキュメントビューア５３がサポートしていない要件（requirement）が指定されているか否かを判断する（Ｌ３１２５）。ドキュメントビューア５３がサポートしていない要件（requirement）が指定されていない場合、ドキュメントビューア５３は、Ｌ３１３１へ進む。

一方、ドキュメントビューア５３がサポートしていない要件（requirement）が指定されている場合、ドキュメントビューア５３は、更に、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されているか否かを判断する（Ｌ３１２６）。要件（requirement）の代替要件（alternative）にサポートしていないものが指定されている場合、ドキュメントビューア５３は、アクセスを拒否して要件処理を終了する（Ｌ３１２７）。

一方、要件（requirement）の代替要件（alternative）にサポートしていないものが指定されていない場合、ドキュメントビューア５３は、要件（requirement）の代替要件（alternative）を処理する（Ｌ３１２８）。

続けて、ドキュメントビューア５３は、要件（requirement）にログの記録（record_andit_data）が指定されているか否かを判断する（Ｌ３１３１）。ログの記録（record_andit_data）が指定されている場合、ドキュメントビューア５３は、ユーザＩＤ（userid）と、文書ＩＤ（docid）と、オペレーション（operation）と、日時と、コンテキスト情報（contextInfo）とを含むログデータを生成する（Ｌ３１３２）。

そして、ドキュメントビューア５３は、ログデータをセキュリティサーバ２００に送信する（Ｌ３１３３）。ドキュメントビューア５３は、ログデータの送信に失敗したか否かを判断する（Ｌ３１３４）。ログデータの送信に失敗した場合、ドキュメントビューア５３は、アクセスを拒否して要件処理を終了する（Ｌ３１３５）。一方、ログデータの送信に成功した場合、ドキュメントビューア５３は、そのままL３１３８へ進む。

更に、ドキュメントビューア５３は、電子文書へのアクセスに多段階認証を認めること（multi_authentication）が指定されているか否かを判断する（L３１３８）。指定されている場合、ドキュメントビューア５３は、ユーザ５２に厳密なユーザ認証（指紋認証など）を要求する（L３１３９）。ドキュメントビューア５３は、更に、厳密な認証に失敗したか否かを判断する（L３１４０）。失敗した場合、アクセスを拒否して終了する（L３１４１）。一方、多段階認証が指定されていない場合及び厳密な認証に成功した場合、ドキュメントビューア５３は、そのままL３１４４へ進む。

続けて、ドキュメントビューア５３は、警告の表示（show_alarm）が指定されているか否かを判断する（L３１４４）。指定されている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで警告文字列を作成し（L３１４５）、警告文字列をオペパネ上でユーザに表示する（L３１４６）。一方、指定されていない場合、ドキュメントビューア５３は、そのままＬ３１４８へ進む。

更に、ドキュメントビューア５３は、機密印刷モード（private_access）が指定されているか否かを判断する（L３１４８）。指定されていない場合、ドキュメントビューア５３は、そのままＬ３１６０へ進む。

一方、指定されている場合、ドキュメントビューア５３は、印刷先プリンタが機密印刷をサポートしていないか否かを判断する（L３１４９）。サポートしていない場合、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３１５０）。そして、ドキュメントビューア５３は、代替要件（alternative）が処理できなかったか否かを判断する（L３１５１）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して終了する（L３１５２）。一方、代替要件（alternative）が処理できた場合、ドキュメントビューア５３は、そのままＬ３１６０へ進む。

一方、機密印刷をサポートしている場合（L３１５５）、ドキュメントビューア５３は、ユーザ５２にパスワードを入力するダイアログを表示し（L３１５６）、ユーザ５２から入力されたパスワードをプリンタドライバにセットして機密印刷モードにする（L３１５７）。そして、ドキュメントビューア５３は、Ｌ３１６０へ進む。

続けて、ドキュメントビューア５３は、イメージログの記録（record_image_data）が指定されているか否かを判断する（L３１６０）。指定されている場合、ドキュメントビューア５３は、更に、印刷先プリンタがイメージログ記録をサポートしていないか否かを判断する（L３１６１）。サポートしていない場合、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３１６２）。そして、ドキュメントビューア５３は、代替要件（alternative）が処理できなかったか否かを判断する（L３１６３）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して終了する（L３１６４）。一方、代替要件（alternative）が処理できた場合、ドキュメントビューア５３は、そのままＬ３１７３へ進む。

一方、イメージログ記録をサポートしている場合（L３１６７）、ドキュメントビューア５３は、ユーザＩＤ（userid）と、文書ＩＤ（docid）と、オペレーション（operation）と、日時と、コンテキスト情報（contextInfo）とを含むログデータを生成する（L３１６８）。ドキュメントビューア５３は、イメージログ書誌事項をプリンタドライバに設定し（L３１６９）、イメージログ記録モードをプリンタドライバに設定する（L３１７０）。そして、ドキュメントビューア５３は、Ｌ３１７３へ進む。

更に、ドキュメントビューア５３は、追跡情報の埋め込み（embed_trace_info）が指定されているか否かを判断する（L３１７３）。指定されていない場合、ドキュメントビューア５３は、そのままＬ３１８７へ進む。

追跡情報の埋め込みが指定されている場合、ドキュメントビューア５３は、更に、印刷先プリンタのドライバがスタンプ印字をサポートしているか否かを判断する（L３１７４）。サポートしている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されているバーコード画像をプリンタドライバにセットしてスタンプ印字モードにする（L３１７５）。そして、ドキュメントビューア５３は、L３１８７へ進む。

一方、印刷先プリンタのドライバがスタンプ印字をサポートしていない場合、ドキュメントビューア５３は、更に、ドキュメントビューア５３がドキュメント編集をサポートしているか否かを判断する（L３１７７）。指定されている場合、ドキュメントビューア５３は、ドキュメントを編集してその要件（requirement）の補足情報（supplement）に指定されているバーコード画像を印刷する各ページに埋め込む（L３１７８）。一方、指定されている場合（L３１８０）、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３１８１）。ドキュメントビューア５３は、代替要件（alternative）が処理できなかった否かを判断する（L３１８２）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して、要件処理を終了する（L３１８３）。処理できた場合、ドキュメントビューア５３は、そのままＬ３１８７へ進む。

続けて、ドキュメントビューア５３は、ラベルをスタンプとして印刷すること（show_label）が指定されているか否かを判断する（L３１８７）。指定されていない場合、ドキュメントビューア５３は、そのままＬ３２０１へ進む。指定されている場合、ドキュメントビューア５３は、更に、印刷先プリンタのドライバがスタンプ印字をサポートしているか否かを判断する（L３１８８）。スタンプ印字をサポートしている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されているスタンプ画像をプリンタドライバにセットしてスタンプ印字モードにする（埋め込み位置はその要件（requirement）の補足情報（supplement）に指定されている「埋め込み位置」）（L３１８９）。そして、ドキュメントビューア５３は、Ｌ３２０１へ進む。

一方、スタンプ印字をサポートしていない場合（L３１９１）、ドキュメントビューア５３は、ドキュメントビューア５３がドキュメント編集をサポートしているか否かを判断する（L３１９１）。ドキュメント編集をサポートしている場合、ドキュメントビューア５３は、ドキュメントを編集してその要件（requirement）の補足情報（supplement）に指定されているスタンプ画像を印刷する各ページに埋め込む（埋め込み位置はその要件（requirement）の補足情報（supplement）に指定されている「埋め込み位置」）（L３１９２）。

一方、ドキュメント編集をサポートしていない場合、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３１９５）。そして、ドキュメントビューア５３は、代替要件（alternative）が処理できなかったか否かを判断する（L３１９６）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して要件処理を終了する（L３１９７）。一方、処理できた場合、ドキュメントビューア５３は、そのままＬ３２０１へ進む。

更に、ドキュメントビューア５３は、目に見える透かし文字の印刷（visible_watermark）が指定されているか否かを判断する（L３２０１）。指定されていない場合、ドキュメントビューア５３は、そのままＬ３２１６へ進む。

一方、指定されている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで背景文字列を作成する（L３２０２）。そして、ドキュメントビューア５３は、更に、印刷先プリンタのドライバが合成印刷をサポートしているか否かを判断する（L３２０３）。サポートしている場合、ドキュメントビューア５３は、その背景文字列を合成文字列としてプリンタドライバにセットする（L３２０４）。そして、ドキュメントビューア５３は、L３２１６へ進む。

一方、印刷先プリンタのドライバが合成印刷をサポートしていない場合、ドキュメントビューア５３は、ドキュメントビューア５３がドキュメント編集をサポートしているか否かを判断する（L３２０６）。サポートしている場合、ドキュメントを編集してその背景文字列をドキュメントの背景に埋め込む（L３２０７）。そして、ドキュメントビューア５３は、Ｌ３２１６へ進む。

一方、ドキュメント編集をサポートしていない場合、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）処理する（L３２００）。そして、ドキュメントビューア５３は、更に、代替要件（alternative）が処理できないか否かを判断する（L３２１１）。ドキュメントビューア５３は、アクセスを拒否して、要件処理を終了する（L３２１２）。

続けて、ドキュメントビューア５３は、浮き出る透かし文字の印刷（anti_copy_watermark）が指定されているか否かを判断する（L３２１６）。指定されていない場合、ドキュメントビューア５３は、Ｌ３２３２へ進む。

一方、指定されている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで地紋文字列を作成する（L３２１７）。ドキュメントビューア５３は、更に、印刷先プリンタのドライバが地紋印刷をサポートしているか否かを判断する（L３２１８）。サポートしている場合、ドキュメントビューア５３は、その地紋文字列をプリンタドライバにセットする（L３２１９）。そして、ドキュメントビューア５３は、Ｌ３２３２へ進む。

一方、地紋印刷をサポートしていない場合、ドキュメントビューア５３は、ドキュメントビューア５３がドキュメント編集をサポートしているか否かを判断する（L３２２１）。サポートしている場合、ドキュメントビューア５３は、地紋文字列に基づいて地紋画像を生成し（L３２２２）、ドキュメントを編集してその地紋画像をドキュメントの背景に埋め込む（L３２２３）。

一方、ドキュメント編集をサポートしていない場合（L３２２５）、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３２２６）。そして、ドキュメントビューア５３は、代替要件（alternative）が処理できないか否かを判断する（L３２２７）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して、要件処理を終了する（L３２２８）。一方、処理できた場合、ドキュメントビューア５３は、そのままＬ３２３２へ進む。

更に、ドキュメントビューア５３は、識別パターンの印刷（identifiable_bg_pattern）が指定されているか否かを判断する（L３２３２）。指定されていない場合、ドキュメントビューア５３は、Ｌ３２４７へ進む。

識別パターンの印刷が指定されている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている識別パターン画像で地紋文字列を作成する（L３２３３）。そして、ドキュメントビューア５３は、更に、印刷先プリンタのドライバが繰り返しスタンプ印刷をサポートしているか否かを判断する（L３２３４）。サポートしている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている識別パターン画像をプリンタドライバにセットして繰り返しスタンプ印刷モードにする（L３２３５）。そして、ドキュメントビューア５３は、Ｌ３２４７へ進む。

一方、繰り返しスタンプ印刷をサポートしていない場合（L３２３７）、ドキュメントビューア５３は、更に、ドキュメントビューアがドキュメント編集をサポートしているか否かを判断する（L３２３７）。サポートしている場合、ドキュメントビューア５３は、ドキュメントを編集して、その要件（requirement）の補足情報（supplement）に指定されている識別パターン画像をドキュメントの背景に繰り返し埋め込む（L３２３８）。そして、ドキュメントビューア５３は、Ｌ３２４７へ進む。

一方、ドキュメント編集をサポートしていない場合（L３２４０）、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（L３２４１）。そして、ドキュメントビューア５３は、代替要件（alternative）が処理できないか否かを判断する（L３２４２）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して要件処理を終了する（L３２４３）。一方、処理できた場合、ドキュメントビューア５３は、Ｌ３２４７へ進む。

続けて、ドキュメントビューア５３は、警告の印刷（print_alarm）が指定されているか否かを判断する（L３２４７）。指定されていない場合、ドキュメントビューア５３は、そのままＬ３１２４へ戻る。

一方、指定されている場合、ドキュメントビューア５３は、その要件（requirement）の補足情報（supplement）に指定されている文字列フォーマットで警告文字列を作成する（Ｌ３２４８）。そして、ドキュメントビューア５３は、更に、印刷先プリンタのドライバがヘッダー／フッター印刷をサポートしているか否かを判断する（L３２４９）。サポートしている場合、ドキュメントビューア５３は、その警告文字列をプリンタドライバにヘッダー／フッターとしてセットする（Ｌ３２５０）。

一方、ヘッダー／フッター印刷をサポートしていない場合、ドキュメントビューア５３は、更に、ドキュメントビューア５３がドキュメント編集をサポートしているか否かを判断する（L３２５２）。サポートしている場合、ドキュメントビューア５３は、警告文字列をドキュメントのヘッダー／フッターに埋め込む（Ｌ３２５３）。

一方、ドキュメント編集をサポートしていない場合（Ｌ３２５５）、ドキュメントビューア５３は、その要件（requirement）の代替要件（alternative）を処理する（Ｌ３２５６）。そして、ドキュメントビューア５３は、更に、代替要件（alternative）が処理できなかったか否かを判断する（L３２５７）。処理できなかった場合、ドキュメントビューア５３は、アクセスを拒否して、要件処理を終了する（Ｌ３２５８）。

一方、代替要件の処理ができた場合、ドキュメントビューア５３は、次の要件（requirement）について上記同様の処理を繰り返すため、Ｌ２１２４へ戻る。

全ての要件（requirement）について上記処理が行われた後、ドキュメントビューア５３は、ユーザ５２から要求されたアクセス処理を行い（Ｌ３２６３）、要件処理を終了する（Ｌ３２６４）。

上記より、ドキュメントビューア５３はセキュリティサーバ２００に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理や、代替要件の処理を盛り込むことで柔軟な処理が可能となる。

上記において、ドキュメントビューア５３が編集機能をサポートしているか否かの判断が行われる要件処理では、指定されている要件が実現できない場合においても、ポータブルドキュメント６３の内容を一時的に編集して必要な情報をポータブルドキュメント６３中に埋め込んだ上で処理を行うことができる。

上記のようなアクセス制御を実現するドキュメントビューア５３でしかポータブルドキュメント６３を開くことができないように、ポータブルドキュメント６３は暗号化しておく必要がある。

暗号化／復号に使用する鍵は、上記アクセス制御を実現できる特殊なドキュメントビューア５３に組み込んでおいても良いし、アクセス制御を執行できる特殊なドキュメントビューア５３であることが確認できた場合にだけ、セキュリティサーバ２００側からドキュメントビューア５３側に復号鍵を転送するようにしても良い。

そのようにしておくことでアクセス制御を実現することのできない一般のドキュメントビューア５３でポータブルドキュメント６３を開かれてしまうのを防ぐことができる．
上記のようにセキュリティポリシーに基づいて、印刷要求に対するアクセス制御が行われる場合に、ドキュメントビューア５３を表示している端末５１に表示される画面例を図３７から図４１で説明する。ユーザ５２は、以下に説明されるような画面にてどのような要件が処理されるのかを知ることができる。

図３７は、要件として警告の印刷が指定された場合の画面例を示す図である。図３７（Ａ）は、警告の印刷のための設定がなされている画面例を示す図である。図３７（Ｂ）は、警告の印刷のための詳細が設定されている画面例を示す図である。

図３７（Ａ）において、画面６００は、要件として警告の印刷が指定された場合の画面であって、画面６００の設定域６０１は、本来、ユーザ５２によってヘッダー又はフッターに印字するための設定域である。警告の印刷がユーザ６２の印刷要求を実行するための要件として処理される場合、ドキュメントビューア５３による要件処理によって強制的にヘッダー又はフッターへの印字が設定されると共に、グレー表示され、ユーザ５２によってその設定を変更することができないように制御される。

ユーザ５２が、設定域６０１内の詳細ボタンをクリックすると図３７（Ｂ）のような画面が表示される。

図３７（Ｂ）において、画面６０５は、要件として警告の印刷が指定された場合の詳細な設定を示す画面であって、画面６０５の設定域６０６は、本来、ユーザ５２によってヘッダー又はフッターに印字するための文字列の配置位置及び書式を設定するための設定域である。警告の印刷がユーザ６２の印刷要求を実行するための要件として処理される場合、ドキュメントビューア５３による要件処理によって強制的に文字列の配置位置及び書式が設定されると共に、グレー表示され、ユーザ５２によってその設定を変更することができないように制御される。

ユーザ５２は、設定を変更することは禁止されるが、警告の印刷が要件であることを印刷する前に確認することができる。この確認によって、ユーザ５２は、実際に印刷を実行するかキャンセルするかを判断することもできる。

図３８は、要件として機密印刷が指定された場合の画面例を示す図である。図３８（Ａ）は、機密印刷のための設定がなされている画面例を示す図である。図３８（Ｂ）は、機密印刷のための認証情報を設定するための画面例を示す図である。

図３８（Ａ）において、画面６１０は、要件として機密印刷が指定された場合の画面であって、画面６１０の印刷方法を選択する選択域６１１は、本来、ユーザ５２によって選択される選択域である。機密印刷がユーザ６２の印刷要求を実行するための要件として処理される場合、ドキュメントビューア５３による要件処理によって強制的に機密印刷が
選択されると共に、グレー表示され、ユーザ５２によってその選択を変更することができないように制御される。

ユーザ５２によってその設定を変更することができないように制御される。ユーザ５２が、設定域６１１内の詳細ボタンをクリックすると図３８（Ｂ）のような画面が表示される。

図３８（Ｂ）において、画面６１３は、要件として機密印刷が指定された場合の詳細な設定を示す画面であって、画面６１３の入力域６１４及び６１５は、本来、ユーザ５２によって認証情報を設定するための入力域である。入力域６１４は、ユーザ５２がユーザＩＤを入力する領域で、入力域６１５は、ユーザ５２がパスワードを入力する領域である。ユーザ５２は、プリンタとしてのデジタル複合機７０にて、この画面６１３で入力したユーザID及びパスワードを入力することによって、印刷されたポータブルドキュメント６３をデジタル複合機７０から出力させることができる。

ユーザ５２は、機密印刷によってポータブルドキュメント６３が印刷されることを知ることができる。

図３９は、要件としてラベルをスタンプとして印刷することが指定された場合の画面例を示す図である。図３９において、画面６２０は、要件としてラベルをスタンプとして印刷することが指定された場合の画面であって、画面６２０の設定域６２１は、本来、ユーザ５２によってスタンプを設定するための設定域である。ラベルをスタンプとして印刷することがユーザ６２の印刷要求を実行するための要件として処理される場合、ドキュメントビューア５３による要件処理によって強制的にスタンプの印字が設定されると共に、グレー表示され、ユーザ５２によってその設定を変更することができないように制御される。

ユーザ５２は、設定を変更することは禁止されるが、スタンプの印字が要件であることを印刷する前に確認することができる。この確認によって、ユーザ５２は、実際に印刷を実行するかキャンセルするかを判断することもできる。

図４０は、要件として目に見える透かし文字の印刷が指定された場合の画面例を示す図である。図４０において、画面６３０は、要件として目に見える透かし文字の印刷が指定された場合の画面であって、画面６３０の設定域６３１は、本来、ユーザ５２によって目に見える透かし文字の印刷を設定するための設定域である。目に見える透かし文字の印刷がユーザ６２の印刷要求を実行するための要件として処理される場合、ドキュメントビューア５３による要件処理によって強制的に目に見える透かし文字の印刷が設定されると共に、グレー表示され、ユーザ５２によってその設定を変更することができないように制御される。

ユーザ５２は、設定を変更することは禁止されるが、目に見える透かし文字の印刷が要件であることを印刷する前に確認することができる。この確認によって、ユーザ５２は、実際に印刷を実行するかキャンセルするかを判断することもできる。

ユーザ５２が、表示された画面６３０の設定域６３１のイメージスタンプの詳細を示すボタン６３２をクリックすると、図４１で示されるような画面が表示される。

図４１は、要件として識別パターンの印刷が指定された場合の画面例を示す図である。図４１（Ａ）は、要件として識別パターンの印刷が指定された場合の詳細を表示する画面例を示す図である。

図４１（Ａ）において、画面６４０の表示域６４１には識別パターンが印刷された場合のイメージ図が表示される。ユーザ５２は、画面６４０での設定を変更することは禁止されるが、識別パターンの印刷要件であることを印刷する前に確認することができる。この確認によって、ユーザ５２は、実際に印刷を実行するかキャンセルするかを判断することもできる。

識別パターンは、例えば、図４１（Ｂ）に示すようなドットで印字される。図４１（Ｂ）は、識別パターンを拡大した例を示す図である。図４１（Ｂ）において、識別パターン６４６は、例えば、縦１２ドット、横８ドットを間隔３ドット（つまり画像サイズは４８ｐｉｘｅｌ × ３２ｐｉｘｅｌ）の識別画像データである。

上下左右を識別するために右１列と下１行はすべてドットを打っておき、その他の１１×７＝７７ドットに７７ビットのコードをエンコードするようにすれば良い。ビットの値が１であればドットを打ち、０であればドットを打たないという単純なルールでこれを実現することができる。

図４１（Ｃ）は、図４１（Ｂ）に示す識別パターンのエンコードの例を示す図である。図４１（Ｃ）において、図４１（Ｂ）に示す識別パターン６４６は、上記エンコードによってビットパターン６４７となる。ドットが乱れたときに識別エラーが発生するため、誤り訂正符号を入れるようにしても良い。

例えば、ユーザ５２がデジタル複合機７０のプリンタ機能を利用して、ドキュメントビューア５３からポータブルドキュメントを印刷する場合に、印刷の要件として機密印刷モードが指定される場合の図２９のＳ３０１９での要件処理のシーケンスについて図４２で詳細に説明する。図４２は、機密印刷モードの要件処理シーケンスを示す図である。

図４２において、ユーザ５２がドキュメントビューア５３に表示したポータブルドキュメント６３に対して印刷要求をすると、ドキュメントビューア５３は、ユーザ５２に対してパスワードを要求する（Ｓ４００１）。ユーザ５２がパスワードを入力すると（Ｓ４００２）、ドキュメントビューア５３は、ユーザ５２の端末５１にインストールされているプリンタドライバ５４に機密印刷モード及びパスワードを設定する（Ｓ４００３）。そして、ドキュメントビューア５３は、プリンタドライバ５４に印刷指示を行う（Ｓ４００４）。

プリンタドライバ５４は、ドキュメントビューア５３による印刷指示に応じて、ＰＤＬ（Page Description Language）を生成して（Ｓ４００５）、ＰＤＬ（例えば、ＲＰＣＳ又はポストスクリプト）と、機密印刷モードと、パスワードとがデジタル複合機７０へ送信する（Ｓ４００６）。その後、プリンタドライバ５４は、ドキュメントビューア５３に対して印刷終了を通知する（Ｓ４００７）。

一方、デジタル複合機７０は、プリンタドライバ５４から受信したＰＤＬと、機密印刷モードと、パスワードとを一時的に内部のハードディスクに保存し（Ｓ４００８）、ユーザ５２によるパスワードの入力を待つ。

ユーザ５２は、ポータブルドキュメント６３をデジタル複合機７０から出力させるために、デジタル複合機７０にパスワードを入力する（Ｓ４００９）。

デジタル複合機７０は、ユーザ５２から入力されたパスワードとプリンタドライバ５４から受信したパスワードとを照合して、一致した場合に印刷処理を実行する（Ｓ４０１０）。一致しない場合、デジタル複合機７０は、印刷処理を行わない。印刷処理の実行によって、ポータブルドキュメント６３が印刷されたペーパードキュメント６２が、デジタル複合機７０から出力される（Ｓ４０１１）。

このような機密印刷モードの処理シーケンスによって、ユーザ５２以外の他のユーザに、デジタル複合機７０にて出力されたペーパードキュメント６２を見られること、また、持って行かれることを防止することができる。

また、ユーザ５２がデジタル複合機７０のプリンタ機能を利用して、ドキュメントビューア５３からポータブルドキュメントを印刷する場合に、印刷の要件として地紋印刷モードが指定される場合の図２９のＳ３０１９での要件処理のシーケンスについて図４２で詳細に説明する。図４３は、地紋印刷モードの要件処理シーケンスを示す図である。

図４３において、ドキュメントユーア５３は、ユーザ５２の端末５１にインストールされているプリンタドライバ５４に地紋印刷が可能か否かを確認する（Ｓ５００１）。確認後、ドキュメントユーア５３は、プリンタドライバ５４に対して、地紋印刷モードと指定文字列とを送信し（Ｓ５００２）、そして、印刷指示を行う（Ｓ５００３）。

プリンタドライバ５４は、地紋印刷モードと指定文字列とを受信し、印刷指示をドキュメントビューア５３から受信すると、指定文字列に従った地紋入りＰＤＬを生成する（Ｓ５００４）。そして、プリンタドライバ５４は、デジタル複合機７０へ地紋入りのＰＤＬを送信する（Ｓ５００５）。

以下、セキュリティサーバ２００によってアプリシステム４００から提供される情報を企業のセキュリティポリシーに対応させる抽象化処理について詳述する。
[セキュリティサーバによる抽象化処理]
セキュリティサーバ２００による抽象化処理を説明するために、各テーブル２５０から２７０は、図４４から図４８に示すようなデータを管理していると仮定する。

図４４は、ユーザ権限レベルテーブルで管理されるデータ例を示す図である。図４４において、ユーザ権限レベルテーブル２５０は、図５に示す構造体ＵｓｅｒＭａｐに従ってデータを管理する。例えば、「principalId」としての「GroupLeaders/Sales/Com」は、「entryType」が「group」であり、「levelId」が「manager」であることが示される。このように、他のデータについても同様に示される。

このようなユーザ管理レベルテーブル２５０は、例えば、ＸＭＬ（eXtensible Markup Language）で記述することによって、図４５に示すようなＸＭＬファイルでデータを管理しても良い。図４５は、ユーザ権限レベルテーブルのＸＭＬファイルを示す図である。

図４５において、ユーザ権限レベルテーブル２５０は、図５に示すデータ構造２５１に従って、データ構造２５１に示す構造体名及び要素名がタグで示された階層的なデータ構造でユーザ権限レベルテーブル２５０のデータが記述される。例えば、<UserMapList>タグの下位層には、並列に<UserMap>タグによって複数のユーザに関するデータが記述され、各<UserMap>タグの下位層には、< principalId>タグと、<EntryType>タグと、<LevelId>タグとによって要素に対応させたデータが記述される。

図４６は、ドキュメントプロファイル管理テーブルで管理されるデータ例を示す図である。図４６において、ドキュメントプロファイル管理テーブル２６０は、図６に示す構造体データ２６１に従って、データ構造２６１に示す構造体名及び要素名がタグで示された階層的なデータ構造でドキュメントプロファイル管理テーブル２６０のデータが記述される。例えば、「docId」としての「0000000001」は、「docCategory」が「development」であり、「docLevel」が「secret」であり、「relatedPersons」が「Members/Dev/Com」であり、「zones」が「ANY」であり、「nondisclosure」が「2005/04/01」であり、「retention」が「2010/04/01」であり、「validity」が空欄であることが示される。このように、他のデータについても同様に示される。

このようなドキュメントプロファイル管理テーブル２６は、ユーザ管理レベルテーブル２５０のようにＸＭＬファイルとすることができるが、ドキュメント毎にテーブルのエントリを作成するため、テーブルの規模が大きくなるため、データベースで管理する方が良い。

図４７は、ゾーン管理テーブルで管理されるデータ例を示す図である。図４７において、ゾーン管理テーブル２７０は、図７に示す構造体データ２７１に従って、データ構造２７１に示す構造体名及び要素名がタグで示された階層的なデータ構造でゾーン管理テーブル２７０のデータが記述される。例えば、「id」としての「saleszone01」は、「name」が「Sales (Yokohama)」であり、「addressInfo」の「address」が「192.207.138.1」であり、「addressesInfo」の「addressType」が「IP」であり、「addressesInfo」の「netmask」が「255.255.255.0」であることが示される。更に、１つに「id」に対して複数の「addressInfo」を管理することができるため、「saleszone01」に対して更に、addressInfo」の「address」が「192.207.139.1」であり、「addressesInfo」の「addressType」が「IP」であり、「addressesInfo」の「netmask」が「255.255.255.0」であることが示される。このように、他のデータについても同様に示される。

このようなゾーン管理テーブル２７０は、例えば、ＸＭＬで記述することによって、図４８に示すようなＸＭＬファイルでデータを管理しても良い。図４８は、ゾーン管理テーブルのＸＭＬファイルを示す図である。

図４８において、ゾーン管理テーブル２７０は、図７に示すデータ構造２７１に従って、データ構造２７１に示す構造体名及び要素名がタグで示された階層的なゾーン管理テーブル２７０のデータが記述される。例えば、<ZoneInfoTable>タグの下位層には、並列に<ZoneInfo>タグによって複数のゾーンに関するデータが記述され、各<ZoneInfo>タグの下位層には、<Id>タグと、<Name>タグと、<AddressInfo>タグとによって要素に対応させたデータが記述される。<AddressInfo>タグでは、更に、下位層を構成し、<Address>タグと、<AddressType>タグと、<Netmask>タグとによって要素に対応させたデータが記述される。<AddressInfo>タグは、<AddressInfo>タグの配下に複数構成しても良い。

そして、例えば、ポリシーファイル２４０には、図４９及び図５０に示されるようにアクセス制御ルールが記述される。図４９及び図５０は、ポリシーファイルに記述されるアクセス制御ルールを示す図である。

図４９及び図５０において、ポリシーファイル２４０では、<Policy>タグの記述７０１から</Policy>タグの記述７０２までにドキュメント毎にアクセス制御ルールが規定される。例えば、ポリシーファイル２４０では、<Rule>タグの記述７０３から</Rule>タグの記述７０４で文書属性に応じたルール1が示され、他<Rule>タグから</Rule>タグによって他の文書属性に応じたルール２及びルール３が示される。

ルール１の記述について説明し、ルール２及びルール３は、同様の記述方法であるためその説明を省略する。

ルール１は、<DocCategory>sales</DocCategory>及び<DocLevel>topsecret</DocLevel>の記述７０５は、文書カテゴリが「sales（販売部門）」であって、かつ、文書レベルが「topsecret（極秘文書）」である文書属性に対するアクセス制御ルールが規定されていることを示している。次に、記述７０５による文書属性において、<Ace>タグから</Ace>タグまでの記述７１０及び７２０において、ユーザ属性に応じたアクセス制御ルールが複数記述される。

記述７１０では、<UserCategory>RELATED_PERSON</UserCategory>、 <UserLevel>manager</UserLevel>及び<Zone>RESTRICTED</Zone>の記述７１１は、ユーザカテゴリが「RELATED_PERSON（関係者）」であって、かつ、ユーザレベルが「manager（管理者）」であって、かつ、ゾーンが「RESTRICTED（制限される）」であるユーザ属性に対するアクセス制御ルールが記述される。更に、記述７２０では、<UserCategory>RELATED_PERSON</UserCategory>及び<UserLevel>ANY</UserLevel>の記述７２１は、ユーザカテゴリが「RELATED_PERSON（関係者）」であって、かつ、ユーザレベルが「ANY（非限定）」であるユーザ属性に対するアクセス制御ルールが記述される。記述７２１ではゾーンは特に指定されない。このように、１つの文書属性に対して、複数のユーザ属性毎にアクセス制御ルールが記述される。

記述７１０では、<Operation>から</Operation>の記述７１２及び７１３は、アクセス制御ルールが適応されるオペレーションが示される。

記述７１２では、<id>read</id>の記述により、記述７０５に属するドキュメントが、記述７１１に属するユーザ５２に対してそのドキュメントの読込（read）を許可することを示している。

また、記述７１３では、<id>print</id>の記述により、記述７０５に属するドキュメントが、記述７１１に属するユーザ５２に対してそのドキュメントの印刷（print）を続いて記述される要件を処理することによって許可することを示している。

この記述７１３では、ドキュメントの印刷（print）時の要件として３つの要件が指定されている。<Requirement>、<id>private_access</id>及び</Requirement>の記述７１４により、印刷時の要件として「private_access（機密印刷モード）」が指定される。

また、<Requirement>、<id>print_alarm</id>及び<Supplement>"Printed by %u"</Supplement>の記述７１５により、印刷時の要件として、「print_alarm（警告の印刷）」が「Printed by %u」で指定される文字フォーマットによる警告文字で行われることが指定される。

更に、<id>identifiable_bg_pattern</id>及び<Supplement>dynamic_image</Supplement> の記述７１６により、印刷時の要件として、「identifiable_bg_pattern（識別パターンの印刷）」が「dynamic_image（動的画像）」で指定される識別パターン画像で地紋文字列によって行われることが指定される。

さて、上記したようなデータを前提として、例えば、「Com」会社の「Sales」部門の「Marketing」グループのリーダである「Taro Yamada」がIPアドレス「192.207.138.64」のＰＣから文書IDが「0000000003」の文書を印刷する場合、例えば、図５１に示すような認証結果情報が、ユーザ管理サーバ３００によってアプリシステム４００に対して提供される。図５１は、認証結果情報の一例を示す図である。

図５１において、認証結果情報は、図１２に示すデータ構造５０１に従って、例えば、「userId」として「Taro Yamada/Sales/Com」、「userName」として「Taro Yamada」、「groups」として「Members/Sales/Com」、「Marketing/Sales/Com」、「Employee/Com」、そして「GroupLeaders/Sales/Com」が示される。

「Taro Yamda」はこのような認証結果情報によって特定され、セキュリティサーバ２００は許可処理を実行する。セキュリティサーバ２００において、ユーザ権限レベルマッピング部２３２は、認証結果情報の「Taro Yamda」と、図４４に示すユーザ権限レベルテーブル２５０とを照合する。「userId」又は「groups」の中で「GroupLeaders/Sales/Com」が最初に一致し、「manager」にマッピングされる（図４の（１））。

そして、ユーザ区分マッピング部２３３は、図４６に示すドキュメントプロファイル管理テーブル２６０を参照して、「0000000003」の文書の「relatedPersons」の「Members/Sales/Com」と照らし合わせて関係者か否かを判定する。ユーザ区分マッピング部２３３は、「Taro Yamada」は「Members/Sales/Com」に所属しているため、関係者であると判定する（図４の（２））。

アクセス種別は、印刷（print）である（図４の（３））。

ゾーンマッピング部２３４は、例えば、図５２に示すようなコンテキスト情報を受信する。図５２は、コンテキスト情報の一例を示す図である。図５２において、コンテキスト情報には、「ipAddress」として「192.207.138.64」、及び、「macAddress」として「02-36-55-22-78-01」が指定される。

ゾーンマッピング部２３４は、ドキュメントプロファイル管理テーブル１６０を参照して、「0000000003」の文書の「zones」として「saleszone01」と「saleszone02」を取得する。ゾーンマッピング部２３４は、更に、ゾーン管理テーブル２７０を参照して、「saleszone01」と「saleszone02」とに含まれるIPアドレス及びMACアドレスのリストを取得する。図５２に示すコンテキスト情報のIPアドレス「192.207.138.64」が「saleszone01」に含まれるため、ゾーン内と判定する（図４の（４））。

ドキュメントセキュリティ属性マッピング部２３５は、例えば、図５３に示すようなドキュメント識別情報を受信する。図５３は、ドキュメント識別情報の一例を示す図である。図５３において、ドキュメント識別情報には、「docId」として「0000000003」が指定される。この場合、「printId」及び「image」は指定されない。

ドキュメントセキュリティ属性マッピング部２３５は、ドキュメントプロファイル管理テーブル２６０を参照して、「0000000003」の文書の文書カテゴリが「sales」で、機密レベルが「topsecret」であると判定する（図４の（５））。

上記のような各マッピング部２３２、２３３及び２３４でのマッピング処理によって、ユーザ権限レベルとして「manager」、関係者区分として「関係者」、アクセス種別として「print」、ゾーン区分として「ゾーン内」、文書カテゴリとして「sales」、機密レベルとして「topsecret」という抽象的なパラメータにマッピングすることができる。

この抽象的なパラメータに基づいて、ポリシーベースアクセス制御判断部２４１が、図４９に示されるポリシーファイル２４０で記述されるアクセス制御ルール（ポリシー）に従って、許可されるか否かを判定すると、記述７１１及び７１３により、「sales」の「topsecret」は関係者の「manager」クラスに「print」を許可している。ただし、「private_access（機密印刷モード）」と、「print_alarm（警告の印刷）」と、「identifiable_bg_pattern（識別パターンの印刷）」とが要件として規定されているため、図５４に示すようなアクセス制御判断結果を返す。

図５４は、判断結果情報の一例を示す図である。図５４において、判断結果情報では、「allowed」として「true（許可）」が設定され、「requirements」には、「requirement」として「private_access（機密印刷モード）」が指定され、この要件に対する「supplements（補足情報）」、「data」及び「alternatives」は指定されない。また、「requirement」として「print_alarm（警告の印刷）」が指定され、この要件に対する「supplements（補足情報）」として「“Printed by Taro Yamda”」が指定され、「data」及び「alternatives」は指定されない。更に、「requirement」として「identifiable_bg_pattern（識別パターンの印刷）」が指定され、この要件に対する「supplements（補足情報）」として「dynamic_image（動的画像）」及び「data」として[binary image data]（バイナリデータによる実際の動的画像）が指定され、「alternatives」は指定されない。

ここで、ポリシーファイル２４０のアクセス制御ルールでは、「Printed by %u」と記述されているが、補正処理により%uの部分がTaro Yamadaに置き換えられる。

また、ポリシーファイル２４０のアクセス制御ルールにおいて「dynamic_image」と記述されていて、アクセス種別が「print」の場合には、図５５に示すようなプリントプロファイル管理テーブル２８０に新しいプリントプロファイルのエントリを作成する。図５５は、プリントプロファイル管理テーブルの一例を示す図である。図５５において、新しいプリントプロファイルのエントリを作成することによって、「printId」を取得する。そして、その「printId」をエンコードして識別画像データにする．その識別画像データを上記の「data」に[binary image data]として格納する。

識別画像データは、例えば、印刷時に紙面に重ねて印刷され、後で識別したり追跡したりするために利用することができる。図５６は、印刷された識別パターンの例を示す図である。図５６に示すように、例えば、図４１（Ｂ）に示されるような識別パターン６４６が重ねられて印刷される。

もしも同じ文書に同じ端末５１から別のユーザ５２、例えば、図５７に示すような認証結果情報によって特定される「Hanako Satoh」が印刷を要求した場合について説明する。図５７は、認証結果情報のその他の例を示す図である。

図５７において、認証結果情報は、図１２に示すデータ構造５０１に従って、例えば、「userId」として「Hanako Satoh/Sales/Com」、「userName」として「Hanako Satoh」、「groups」として「Members/Sales/Com」、「Marketing/Sales/Com」、そして「Employee/Com」が示される。

「Hanako Satoh」はこのような認証結果情報によって特定され、セキュリティサーバ２００は許可処理を実行する。許可処理の実行によって、ユーザ権限レベルは「regular」、関係者区分は「関係者」、アクセス種別は「print」、ゾーン区分は「ゾーン内」、文書カテゴリは「sales」、機密レベルは「topsecret」となり、図４９に示されるポリシーファイル２４０で記述されるアクセス制御ルール（ポリシー）に従って判定すると、アクセス制御判断結果は、許可されないことになる。

また、もしも「Taro Yamada」が「0000000001」の文書を参照（read）しようとしたとすると、該当するポリシーが規定されておらず、アクセス制御判断結果は、許可されないことになる。

また、先に「Taro Yamada」が印刷した紙をデジタル複合機７０で複写する場合、デジタル複合機７０は、紙面をスキャンした画像データに基づいて、セキュリティサーバ２００に対してアクセス制御の問い合わせを行う。

セキュリティサーバ２００は、デジタル複合機７０から図５８（Ａ）又は図５８（Ｂ）に示すようなドキュメント識別情報を受信する。

図５８は、ドキュメント識別情報の例を示す図である。図５８（Ａ）は、画像データそのものをセキュリティサーバへ送信する場合のドキュメント識別情報の一例を示す図である。図５８（Ａ）において、「docId」及び「printId」は指定されず、「image」に画像データがバイナリ（[binary image data]）が設定される。

図５８（Ｂ）は、画像データをデコードしてセキュリティサーバへ送信する場合のドキュメント識別情報の一例を示す図である。図５８（Ｂ）において、「docId」及び「image」は指定されず、「printId」にデジタル複合機７０でエンコードされたバイナリの画像データ（[binary image data]）が設定される。

セキュリティサーバ２００は、図５８（Ａ）に示すようなバイナリの画像データをデジタル複合機７０から受信した場合、「printId」として「p000000001」を取得する。その「printId」に基づいて、プリントプロファイルを参照して、「docId」として「0000000003」を取得する。そして、セキュリティサーバ２００は、「Taro Yamada」による「print」の場合と同様に、アクセス種別が「copy」を示す場合のポリシーに従ってアクセス制御判断を行う。

本発明によれば、例えば、ポータブルドキュメント６３を印刷する際に、印刷したユーザ５２の名前を印字することを要件とするようなポリシーの記述において、つまり、その印刷というオペレーションを行うことによって、ポータブルドキュメント６３がドキュメントビューア５３の管理下から紙への出力されてしまう際に、その出力後も印刷しようとするユーザ５２に対して情報漏洩の抑止効果を高めるように規定することによりポータブルドキュメント６３のセキュリティを維持することができる。

また、ポリシーの記述において、紙を複写する際に、複写しようとするユーザ５２のユーザ名を印字するという要件を規定することができるため、複写したユーザ５２のユーザ名を紙に入れることによりデジタル複合機７０から出力されてしまう複製されたペーパードキュメント６２のセキュリティを維持することができる。

また、ポリシーの記述において、サーバドキュメント６１を文書管理システム１００から読み出す際にログを記録するような要件を規定できるため、読み出した記録を残すことができる。従って、読み出したユーザ５２に対して情報漏洩の抑止をしてセキュリティを維持することができる。

このようなオペレーションを許可するための要件として、ポリシーの記述において、そのオペレーションを行った後もセキュリティの維持を可能とするような処理を行わせるように規定することができるため、ドキュメント６０に対するオペレーションの前後で一貫したセキュリティの確保を実現できる。

従来のドキュメント６０に対するセキュリティでは、ドキュメント６０に対してオペレーションを行った後では、セキュリティの維持をすることができなかった。

しかしながら、本発明によれば、ドキュメント６０に対してオペレーションを行った後においても、セキュリティを一貫して維持することができる。

以下に、ポリシーファイル２４０で規定されるアクセス制御ルールにおけるオペレーション、要件、補足情報について詳述する。
［オペレーション、要件、補足情報に関する詳細］
［１ オペレーション詳細］
サーバドキュメント６１、ペーパードキュメント６２、ポータブルドキュメント６３について同じ名称のオペレーションが存在することがあるため、オペレーション識別子の先頭には以下のプレフィックスをつけて区別するようにする。
・サーバドキュメント６１のオペレーション： sdOpe_xxxx
・ペーパードキュメント６２のオペレーション： ppOpe_xxxx
・ポータブルドキュメント６３のオペレーション： pdOpe_xxxx
xxxxはオペレーションの意味をあらわす英単語とする。以下、各節のタイトルはオペレーションの識別子である。
[１−１ sdOpe_store]
例えば、文書管理サーバ１００へのドキュメントの保存を要求するオペレーションである。文書管理サーバ１００、デジタル複合機７０等のドキュメントボックスなど、ドキュメントファイルのセキュリティ管理が可能なリポジトリ（格納庫）にドキュメントを保存するオペレーションである（新規作成又は新規登録と呼ばれることもある）。

適用可能な要件として record_audit_data、 explicit_authorization、 encryption、 integrity_protection、 show_alarm等がある。各要件の詳細は後述される。
［１−２ sdOpe_prop_read］
例えば、文書管理サーバ１００に保存されているドキュメントのプロパティ参照を要求するオペレーションである。ドキュメントのコンテンツを参照（取得）するのではなく、ドキュメントのファイルサイズや作成日時、所有者といった属性情報を参照するオペレーションである。このオペレーションが許可されない場合、ドキュメントの存在そのものを知ることができない。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
［１−３ sdOpe_read］
例えば、文書管理サーバ１００に保存されているドキュメントの参照（読み取り）を要求するオペレーションである。文書管理サーバ１００のドキュメントファイルのコンテンツを参照（ダウンロード）するオペレーションである。プロテクトされたドキュメントファイルをダウンロードすることに相当する。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。

このオペレーションに対して以下を補足する。

ダウンロードされたドキュメントファイルのことをポータブルドキュメント６３と呼ぶ。ポータブルドキュメント６３へのアクセスをコントロールする必要があるため、sdOpe_readというオペレーションでダウンロードされるポータブルドキュメント６３は、
プロテクトされたドキュメントファイルとなる。
［１−４ sdOpe_get_org］
例えば、文書管理サーバ１００に保存されているドキュメントのオリジナルファイルの参照（読み取り）を要求するオペレーションである。sdOpe_readはプロテクトされたドキュメントファイルのダウンロードに相当し、このsdOpe_get_orgはプロテクトされていないオリジナルのドキュメントファイルのダウンロードに相当する。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
［１−５ sdOpe_revise］
例えば、文書管理サーバ１００に保存されているドキュメントの改訂を要求するオペレーションである。文書管理サーバ１００に保存されているドキュメントをエディタで開いて編集し改訂するオペレーションや、文書管理サーバ１００に保存されているドキュメントを差し替える（保存しなおす）オペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 versioning、 show_alarm等がある。各要件の詳細は後述される。
［１−６ sdOpe_delete］
例えば、文書管理サーバ１００に保存されているドキュメントの削除を要求するオペレーションである。文書管理サーバ１００に保存されているドキュメントを削除するオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 complete_deletion、 show_alarm等がある。各要件の詳細は後述される。
［１−７ pdOpe_read］
ポータブルドキュメント６３の参照（オープン）を要求するオペレーションである。ポータブルドキュメント６３のファイルを開くオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
［１−８ pdOpe_print］
ポータブルドキュメント６３の印刷を要求するオペレーションである。ファイルの内容を印刷するオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 private_access、 record_image_data、 embed_trace_info、 show_label、 visible_watermark、 anti_copy_watermark、 trusted_bg_pattern、 identifiable_bg_pattern、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
［１−９ pdOpe_send_fax］
ポータブルドキュメントのファクス送信を要求するオペレーションである。ファイルの内容を直接ファクスで送信するオペレーションである。ファクスに対応するプリンタオブジェクトで印刷する処理に相当する．
適用可能な要件としてrecord_audit_data、 explicit_authorization、 address_restriction、 private_send、 record_image_data、 show_label、 visible_watermark、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
［１−１０ ppOpe_copy］
ペーパードキュメントの複写を要求するオペレーションである。紙のドキュメントを複写機で複写するオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 show_label、 show_operator、 owner_only、 record_image_data、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
［１−１１ ppOpe_send_fax］
ペーパードキュメントのファクス送信を要求するオペレーションである。紙のドキュメントをファクスで送信するオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 address_restriction、 private_send、 record_image_data、 show_label、 visible_watermark、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
［１−１２ ppOpe_scan］
ペーパードキュメントのスキャンを要求するオペレーションである。紙のドキュメントをスキャナで読み取り、電子ファイル化するオペレーションである。

適用可能な要件としてrecord_audit_data、 explicit_authorization、 record_image_data、 digital_watermark等がある。各要件の詳細は後述される。
［２ 要件詳細］
以下に各要件について説明する。各節のタイトルは要件の識別子である。
要件によって処理の仕方が異なる。要件の処理は、アプリシステム４００が行うことになる。
［２−１ record_audit_data］
ログを記録する。例えば、デジタル複合機７０でコピーをする際にページごとにログを記録するようにしてもよいし、コピーした原稿についてセキュリティIDごとにまとめてログを記録するようにしてもよい。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−２ explicit_authorization］
文書管理責任者による許可を必要とする。この要件がポリシーで規定されている場合、このオペレーションに対する明示的な許可がセキュリティサーバ２００に対して行われていなければ「不許可」となる。セキュリティサーバ２００は、許可処理の処理中に取得した判断結果にこの要件が規定されていることを識別したら、許可証が発行されているか否かを確認し、発行されていれば要件の中からexplicit_authorizationを取り除いて、allowed = trueと他の要件を判断結果としてアプリシステム４００に返す。許可証が発行されていなければ、allowed = falseをアプリシステム４００に返す。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−３ encryption］
電子文書を暗号化する。この要件がポリシーで規定されている場合、サーバ管理者にその電子文書の内容を読まれては困るということを意味している。したがって、アプリシステム４００はサーバ管理者でも解読できないように暗号化しなければならない。つまり、暗号を解く復号鍵はアプリシステム４００のサーバ管理者に利用されないように格納しなければならない。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−４ integrity_protection］
電子文書の完全性を確保する（原本性を保障する）。この要件がポリシーで規定されている場合、アプリシステム４００は、電子文書の原本が改ざんされないように保護しなければならない。アプリシステム４００が独自に文書保護領域に保存してもよいが、セキュリティサーバ２００に原本の保存を任せるようにしても良い。

セキュリティサーバ２００は、受け取った原本（PDFに変換する前のファイル）と変換した保護PDFファイルを文書保護領域へ保存する。保存した原本IDは、ドキュメントプロファイル管理テーブル２６０のアプリデータとして記録しておく。

セキュリティサーバ２００に文書保護領域がセットアップされていない場合、文書保護領域への保存はエラーとなる。セキュリティサーバ２００は、深刻なエラーが発生したとして、セキュリティレベルの高いログを記録する。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。

要件の処理では、アプリシステム４００が文書保護領域への保存をセキュリティサーバ２００に要求する。セキュリティサーバ２００は、要求されたら文書保護領域へ保存する。
［２−５ multi_authentication］
電子文書へのアクセスに多段階認証を求める。
この要件がポリシーで規定されている場合、アプリシステム４００は通常のユーザ認証に加えて、例えば指紋認証や虹彩認証などの、多段階のユーザ認証を行わなければならない。どのような認証方式を用いるかはアプリシステム４００に任せられる。あらかじめもう一段の認証をパスしていなければアクセス不許可とするか、もしくはこの要件が返されたらもう一段の認証をユーザに求めるようにするか、タイミングはどちらでも良い。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−６ versioning］
電子文書のバージョン管理を行う。
この要件がポリシーで規定されている場合、アプリシステム４００は電子文書を改訂する際に上書き保存はせず、バージョン（版）管理を行わなければならない。アプリシステム４００がバージョン管理の機能を提供していない場合には要件が満たせないものとして文書の改訂を行ってはならない。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−７ complete_deletion］
電子文書の完全削除を行う。
この要件がポリシーで規定されている場合、アプリシステム４００は電子文書のエントリをただ単に削除するだけでなく、その電子文書が記録されていたディスク領域にランダムなデータを上書きするなどして完全消去処理を行わなければならない。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−８ private_access］
機密印刷モードを使用する。
印刷出力された紙を他人に持ち去られないよう、印刷した本人であることをプリンタのオペパネで確認した上で印刷出力する。
この要件がポリシーで規定されている場合、アプリシステム４００は機密印刷モードを使用して印刷しなければならない。機密印刷モードをサポートしていないプリンタが相手の場合には印刷させない。
機密印刷モードをサポートしていないプリンタでも、他人に印刷文書が持ち去られる可能性が低い環境では印刷できるようにしたいと考えるかもしれない。そのようなポリシーにしたい場合にはprivate_accessの代替要件としてshow_alarmを指定するようにして、警告だけした上で印刷させるようにすると良い。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−９ record_image_data］
イメージログの記録を行う。
印刷イメージ、複写イメージをそのまま記録して保持する。
この要件が印刷の要件としてポリシーで規定されている場合、アプリシステム４００はイメージデータの記録を印刷出力先のプリンタアダプタに指示して印刷する。
複写の要件としてポリシーで規定されている場合、複写した原稿のイメージをデジタル複合機７０内のハードディスク（ドキュメントボックス）に格納する。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−１０ embed_trace_info］
追跡情報を埋め込んで印刷する。印刷する際に、その印刷物の識別情報を紙面に埋め込んで出力する。追跡情報としては、現状は二次元バーコードを利用する。

この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理でembed_trace_infoの要件とともに追跡情報を動的に生成しなければならないことを示す補足情報（supplement）を返す。つまり、dynamic_imageを指定する補足情報（supplement）を返す。セキュリティサーバ２００は、このdynamic_imageの補足情報が指定されていることを識別すると、ドキュメントプロファイル管理テーブル２６０から埋め込み用イメージを取得し、セキュリティサーバ２００の許可処理の戻り値で、embed_trace_infoの要件とともに、その埋め込みイメージを補足情報（supplement）として返す。補足情報のdynamic_imageの節を参照のこと。
アプリシステム４００は受け取った埋め込みイメージを印刷紙面上に埋め込む。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。

要件の処理では、セキュリティサーバ２００がドキュメントプロファイル管理テーブル２６０から埋め込みイメージを取得し、アプリシステム４００が実際に埋め込みイメージを印刷時に埋め込む。
［２−１１ show_label］
「秘」などのラベルをスタンプとして印刷する。この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理の戻り値でshow_labelの要件とともにラベルスタンプのビットマップデータを補足情報（supplement）として返す。どういうドキュメントにはどのようなスタンプを印刷するのか、セキュリティサーバ２００にあらかじめ設定しておかなければならない。ポリシーにはラベルスタンプのID、スタンプを押す位置、に関する情報が要件の補足情報（supplement）として規定されており、そのIDに対応するビットマップファイルがセキュリティサーバ２００のローカルハードディスクに保存されている。セキュリティサーバ２００はビットマップファイルを読み出してバイト配列の補足情報（supplement）にして上位に渡す。

ポリシーに規定されているラベルスタンプIDに対応するビットマップファイルが存在しない場合には、ラベルIDのみ要件の補足情報（supplement）に含め、ビットマップデータなしで要件が返される。補足情報のstatic_imageの節を参照のこと。

スタンプイメージは動的に生成されることを想定していない。セキュリティサーバ２００は受け取った要件と補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は、受け取ったスタンプイメージを重ねて印刷する。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。

要件の処理では、スタンプイメージをセキュリティサーバ２００が提供し、アプリシステム４００（デジタル複合機７０）が紙にラベルスタンプを押す。
［２−１２ visible_watermark］
紙面の背景に目に見える形で透かし文字を印刷する。この要件がポリシーで規定されて
いる場合、セキュリティサーバ２００は許可処理の戻り値でvisible_watermarkの要件とともに透かしとして印刷する文字列フォーマットを補足情報（supplement）として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。セキュリティサーバ２００は受け取った要件、補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は受け取った文字列フォーマットに従って透かし文字列を生成し、印刷する。補足情報のstring_formatの節を参照のこと。

必要な補足情報は、 string_format、colorである。

同時に指定できない要件（競合する要件）は、 anti_copy_watermark、 trusted_bg_pattern、 identifiable_bg_patternである。

要件の処理では、文字列フォーマットをセキュリティサーバ２００が提供し、アプリシステム４００（デジタル複合機７０）が紙に文字列を印字する。
［２−１３ anti_copy_watermark］
紙面の背景に複写すると浮き出る形で透かし文字を印刷する。この要件がポリシーで規
定されている場合、セキュリティサーバ２００は許可処理の戻り値でanti_copy_watermarkの要件とともに透かしとして印刷する文字列フォーマットを補足情報（supplement）として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。セキュリティサーバ２００は受け取った要件、補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は受け取った文字列フォーマットに従って透かし文字列を生成し、印刷する。補足情報のstring_formatの節を参照のこと。

必要な補足情報は string_format、colorである。

同時に指定できない要件（競合する要件）は、 visible_watermark、 trusted_bg_pattern、 identifiable_bg_patternである。

要件の処理では、文字列フォーマットをセキュリティサーバ２００が提供し、アプリシステム４００が紙に文字列を印字する。
［２−１４ trusted_bg_pattern］
改ざん検出用背景パターンを印刷する。
［２−１５ identifiable_bg_pattern］
紙面の背景に識別パターンを印刷する。識別パターンは開発中の背景ドットパターンを想定している。

この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理でidentifiable_bg_patternの要件と補足情報として動的に情報を生成しなければならないという情報を返す。セキュリティサーバ２００は動的イメージ生成（補足情報 dynamic_image）が指定されていることを識別すると、ドキュメントプロファイル管理テーブル２６０から識別パターンを取得し、許可処理の戻り値で、identifiable_bg_patternの要件とともに、その識別パターンを補足情報（supplement）として返す。補足情報のdynamic_imageの節を参照のこと。

アプリシステム４００は受け取った識別パターンを印刷紙面上に背景として印刷する。

必要な補足情報はdynamic_imageである。

同時に指定できない要件（競合する要件）は、visible_watermark、anti_copy_watermark、 trusted_bg_patternである。

要件の処理では、セキュリティサーバ２００がドキュメントプロファイル管理テーブル２６０から識別パターンを取得し、アプリシステム４００が実際に識別パターンを印刷時に背景に入れる。
［２−１６ show_alarm］
警告を表示する。「極秘文書のため取り扱いに注意すること」というような警告を表示してユーザに意識付けをする。この要件はディスプレイやオペパネに表示することを意図している。印刷する紙の上に表示する場合には別の要件print_alarmを使用する。どういうドキュメントにはどのような文字列を表示するのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。セキュリティサーバ２００は、受け取った要件及び補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は受け取った文字列フォーマットに従って文字列を生成し、表示する。

必要な補足情報は、 string_formatである。

同時に指定できない要件（競合する要件）はない。

要件の処理では、セキュリティサーバ２００が表示する文字列フォーマットを提供し、アプリシステム４００が表示する。
［２−１７ print_alarm］
警告を印刷する。「RRR Internal Use Only」というような警告を印刷してユーザに意識
付けをする。この要件は紙に印刷することを意図している。ディスプレイやオペパネに表示する場合には別の要件show_alarmを使用する。

どういうドキュメントにはどのような文字列を印刷するのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。が表示する文字列フォーマットを提供し、アプリシステム４００が表示する。は受け取った要件、補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は受け取った文字列フォーマットに従って文字列を生成し、印刷する。

必要な補足情報は、 string_format、 string_positionである。
同時に指定できない要件（競合する要件）はない。

要件の処理では、セキュリティサーバ２００が印刷する文字列フォーマットを提供し、アプリシステム４００が印刷する。
［２−１８ private_send］
親展送信モードを使用する。ファクスで送信した紙を他人に持ち去られないよう、ファクスの親展送信モードを使用する。親展モードをサポートしていないファクスに対しては送信処理を行わない。

親展モードをサポートしていないファクスでも、他人にファクス文書が持ち去られる可能性が低い環境では送信できるようにしたいと考えるかもしれない。そのようなポリシーにしたい場合にはprivate_receiveの代替要件としてshow_alarmを指定するようにして、警告だけした上で送信させるようにすると良い。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。
［２−１９ address_restriction］
ファクスで送信できる宛先を制限する。
［identifiable_bg_pattern］
［２−２０ show_operator］
［identifiable_bg_pattern］
複写したユーザ名を複写した紙の余白に印字する。この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理の戻り値でshow_operatorの要件とともに印字する文字列フォーマットを補足情報（supplement）として返す。どういうドキュメントにはどのような文字列を印字するのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。

セキュリティサーバ２００は、受け取った要件と補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は、受け取った文字列フォーマットに従って文字列を生成し、複写した紙に印字する。

必要な補足情報は、string_formatである。

同時に指定できない要件（競合する要件）はない。

要件の処理では、印字文字列フォーマットはポリシーに規定されているものをセキュリティサーバ２００が提供し、アプリシステム４００がそのフォーマットに従って複写時に印字する。
［２−２１ owner_only］
印刷した本人のみ複写可能にする。この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理の戻り値でowner_onlyの要件を返す。セキュリティサーバ２００は、この要件を識別すると、複写原稿を印刷したユーザのIDをドキュメントプロファイル管理テーブル２６０から取得し、複写しようとしているユーザと印刷したユーザとが一致しているかどうか確認する。一致していれば、owner_onlyの要件を取り除いてセキュリティサーバ２００の許可処理の結果として返す。一致していない場合にはセキュリティサーバ２００の許可処理の結果としてallowed = falseを返す。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない。

要件の処理では、セキュリティサーバ２００によって本人でなければ「不許可」が返される。
［２−２２ unreadable_mask］
読めないようにマスクする。複写したときに、その紙が複写してはならないものであったことを利用者に気づかせるために、読めないように全面にグレーでマスクして複写出力する要件。

必要な補足情報はない。

同時に指定できない要件（競合する要件）はない（ただし指定してもshow_labelなど無意味になることがある）。
［２−２３ digital_watermark］
画像データに電子透かしを入れる。この要件がポリシーで規定されている場合、セキュリティサーバ２００は許可処理の戻り値でdigital_watermarkの要件とともに電子透かしとして埋め込む文字列フォーマットを補足情報（supplement）として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報（supplement）として規定しておかなければならない。セキュリティサーバ２００は補足情報（supplement）をそのままアプリシステム４００に渡す。アプリシステム４００は受け取った文字列フォーマットに従って埋め込む文字列を生成し、電子透かしとしてドキュメントの画像データに印刷する。

補足情報のstring_format、watermark_typeの節を参照のこと。

必要な補足情報は string_format, watermark_typeである。

同時に指定できない要件（競合する要件）は anti_copy_watermark, trusted_bg_pattern, identifiable_bg_patternである。

要件の処理では、文字列フォーマットをセキュリティサーバ２００が提供し、アプリシステム４００がそのフォーマットに従って電子透かしを埋め込む。
［３ 補足情報詳細］
要件には補足情報が必要となることがある。補足情報の指定の仕方を以下に定義する。各節のタイトルは補足情報の識別子である。
［３−１ static_image］
補足情報として固定画像データを指定する場合に使用する。固定画像データとしては例えばラベル表示要件（"show_label"）に使用するスタンプ画像などがある。
データそのものはポリシーファイル２４０に格納されないため、固定画像データファイルを特定する識別ラベルをポリシーファイル２４０内で指定する。識別ラベルの指定は先頭に"ref:"をつける。

補足情報の書式はref:[file_id]である。

例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>show_label</Id>
<Supplement>
<Id>static_image</Id>
<Data>ref:STAMP_IMAGE_01</Data>
</Supplement>
上記のようにポリシーファイル２４０で指定されているとき、セキュリティサーバ２００の許可処理メソッドでポリシー判定結果を返す際には以下のようにして返す。
DecisionInfo.requirements[x].requirement = "show_label";
DecisionInfo.requirements[x].supplements[y].name = "static_image";
DecisionInfo.requirements[x].supplements[y].value = "z";
DecisionInfo.requirements[x].dataz = STAMP_IMAGE_01に対応する画像データ（バイナリデータ）;
ただしx、y、zは数字である。

上記のように、セキュリティサーバ２００は補足情報として"ref:"が指定されると、そこに記載されている識別ラベルに対応するファイルを読み出してバイナリデータとして補足情報として組み込む処理を行う。
［３−２ dynamic_image］
補足情報として動的な画像データを指定する場合に使用する。動的に生成される画像データとしては例えば追跡情報埋め込み要件（"embed_trace_info"）に使用するバーコード画像や、識別パターン要件（"identifiable_bg_pattern"）に使用する識別パターン画像などがある。

これらは対象となっている文書によって動的に画像データが生成されるため、ポリシーファイル２４０の中でその内容を記述することはできない。ポリシーファイル２４０では補足情報として動的に生成する情報のタイプ（例えば文書ID、ユーザIDといった情報のタイプ）を指定する。

補足情報の書式は dyn:[info_type]である。info_typeには"SecId"のみ指定可能である。

例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>embed_trace_info</Id>
<Supplement>
<Id>dynamic_image</Id>
<Data>dyn:SecId</Data>
</Supplement>
上記のようにポリシーファイル２４０で指定されているとき、セキュリティサーバ２００の許可処理メソッドでポリシー判定結果を返す際には何も処理せず、以下のようにして返す。
DecisionInfo.requirements[x].requirement = "embed_trace_info";
DecisionInfo.requirements[x].supplements[y].name = "dynamic_image";
DecisionInfo.requirements[x].supplements[y].value = "dyn:SecId";
ただしx、yは数字である。

そして、判断結果情報を受け取ったセキュリティサーバ２００は、必要な画像データを動的に生成し、セキュリティサーバ２００の許可処理の結果として以下を返す。
DecisionInfo.requirements[x].requirement = "embed_trace_info";
DecisionInfo.requirements[x].supplements[y].name = "dynamic_image";
DecisionInfo.requirements[x].supplements[y].value = "z";
DecisionInfo.requirements[x].dataz = 動的に生成した画像データ（バイナリデータ）;
ただしx、y、zは数字である。
［３−３ image_position］
補足情報として画像の埋め込み位置を指定する場合に使用する。画像を全面に埋め込むのではなく、一部に埋め込む要件（"show_label"など）で指定する。全面に埋め込む場合（タイル形式で埋め込む場合）は要件が異なる（"identifiable_bg_pattern"など）ものとなる。

ポリシーファイル２４０では埋め込み位置を識別ラベルで指定する。

補足情報の書式は [position_id]である。position_idはupper_right、lower_right、upper_left、lower_left、centerの5種類である。

例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>show_label</Id>
<Supplement>
<Id>image_position</Id>
<Data>upper_right</Data>
</Supplement>
セキュリティサーバ２００は、この補足情報をそのまま判断結果情報に格納して返す。
［３−４ string_format］
補足情報として文字列の書式を指定する場合に使用する。ウォーターマーク（"visible_watermark"）などの要件で指定する。
ポリシーファイル２４０内では書式を以下のようにして指定する。
補足情報の書式： ["format_string"]
format_stringは以下の組み合わせと任意の文字列で指定する。
"%da" IPアドレス（10進数表記 133.139.208.69等）
"%ha" IPアドレス（16進数表記 BEAC143F等）
"%8u" ユーザ名（アカウント名）、数字で桁数を指定することができる（数字は無指定でも良い）。
"%d1" 日時（YYMMDD）
"%d2" 日時（YYMMDD HH:mm）
"%d3" 日時（YYMMDD HH:mm:ss）
"%id" 文書ID（未サポート）
"%lv" 機密レベルID（未サポート）
"%ca" 文書カテゴリID（未サポート）
例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>visible_watermark</Id>
<Supplement>
<Id>string_format</Id>
<Data>%8u %d2 DO NOT COPY</Data>
</Supplement>
セキュリティサーバ２００は、この補足情報をそのまま判断結果情報に格納して返す。
要件によっては最大文字数に制限がある（例えばvisible_watermarkは32文字）。最大文字数を超えた分の文字は使用されない。
［３−５ string_position］
補足情報として文字列の埋め込み位置を指定する場合に使用する。文字列を背景に埋め込むのではなく、一部に埋め込む要件（"print_alarm"など）で指定する。背景に埋め込む場合は要件が異なるもの（"visible_watermark"など）となる。
ポリシーファイル２４０内では埋め込み位置を識別ラベルで指定する。

補足情報の書式は [position_id]である。position_idは upper_right、lower_right、upper_left、lower_left、upper_center、 lower_center、 upper_lower_centerの６種類である。

例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>print_alarm</Id>
<Supplement>
<Id>string_position</Id>
<Data>upper_lower_center</Data>
</Supplement>
セキュリティサーバ２００は、この補足情報をそのまま判断結果情報に格納して返す。
［３−６ color］
補足情報として色の指定をする場合に使用する。複写抑止地紋（"anti_copy_watermark"）などの要件で指定する。

ポリシーファイル２４０内では以下のようにして指定する。

補足情報の書式は [color_id]である。color_idは cyan、magentaのいずれかを指定する。

例えば、ポリシーファイル２４０内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>anti_copy_watermark</Id>
<Supplement>
<Id>color</Id>
<Data>cyan</Data>
</Supplement>
セキュリティサーバ２００は、この補足情報をそのまま判断結果情報に格納して返す。
［３−７ watermark_type］
補足情報として透かしの種別の指定をする場合に使用する。電子透かし（"digital_watermark"）などの要件で指定する。

ポリシーファイル２４０内では以下のようにして指定する。

補足情報の書式は、 [watermak_type_id]である。watermark_type_idは、traceability、 integrity、 steganographyを指定する。traceabilityは追跡目的での電子透かしを指定し、integrityは改ざん検出目的での電子透かしを指定し、steganographyは情報を伝達する目的での電子透かしを指定する。

例えば、ポリシーファイル２４０内では以下のように指定する。
<DspAce>
<DspOperation>
<Id>pp_scan</Id>
<DspRequirement>
<Id>digital_watermark</Id>
<DspSupplement>
<Id>string_format</Id>
<Data>%u %d</Data>
</DspSupplement>
<DspSupplement>
<Id>watermark_type</Id>
<Data>traceability</Data>
</DspSupplement>
セキュリティサーバ２００は、この補足情報をそのまま判断結果情報に設定して返す。

上記より、本発明によれば、セキュリティサーバ２００がアプリシステム４００から提供される情報等を企業のセキュリティポリシーに対応させるために抽象化することができる。つまり、アプリシステム４００から提供される抽象度の低い情報を抽象度の高いセキュリティポリシーに対応させるために抽象度を上げることができる。従って、組織のセキュリティポリシーに従って、電子文書のみならず紙文書のセキュリティを確保することができる。

文書管理サーバとドキュメントビューア５３とが、サーバドキュメント６１及びポータブルドキュメント等の電子文書に対するアクセス制御を組織のセキュリティポリシーに従って行い、ドキュメントユーバ５３からポータブルドキュメント６３を印刷する際に、ポリシーに従ってセキュリティ処理を行うことで、印刷者本人に印刷された紙文書をポリシーに従って適切に扱わせることができる。

また、印刷されたペーパードキュメント６２をデジタル複合機７０で複写する際にもポリシーに従って、その処理をコントロールすることができる。

従って、一般オフィスにおいて、紙文書と電子文書のセキュリティを十分確保可能となる。

本発明の一実施例に係るシステム構成を示す図である。 アクセス制御モデルを示す図である。 本発明の一実施例に係るセキュリティサーバのハードウェア構成を示す図である。 セキュリティサーバの機能構成を示す図である。 ユーザ権限レベルテーブルのデータ構造を示す図である。 ドキュメントプロファイル管理テーブルのデータ構造を示す図である。 ゾーン管理テーブルのデータ構造を示す図である。 プリントプロファイル管理テーブルのデータ構造を示す図である。 文書管理システムでのアクセス制御シーケンスを示す図である。 文書管理システムでのアクセス制御処理を説明するためのフローチャート図である。 ユーザ管理サーバでの認証処理を説明する図である。 認証結果情報のデータ構造を示す図である。 文書管理システムからの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 文書管理システムからの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 文書管理システムからの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 コンテキスト情報のデータ構造を示す図である。 判断結果情報のデータ構造を示す図である。 文書管理システムでの用件の補正処理を説明するためのフローチャート図である。 文書管理システムでの要件処理を説明するためのフローチャート図である。 文書管理システムでの要件処理を説明するためのフローチャート図である。 デジタル複合機でのアクセス制御シーケンスを示す図である。 デジタル複合機でのアクセス制御処理を説明するためのフローチャート図である。 デジタル複合機からの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 デジタル複合機からの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 デジタル複合機からの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。 デジタル複合機での要件処理を説明するためのフローチャート図である。 デジタル複合機での要件処理を説明するためのフローチャート図である。 デジタル複合機での要件処理を説明するためのフローチャート図である。 ドキュメントビューアでのアクセス制御シーケンスを示す図である。 ドキュメントビューアでのアクセス制御処理を説明するためのフローチャート図である。 ドキュメントビューアでのアクセス制御処理を説明するためのフローチャート図である。 ドキュメントビューアでの要件処理を説明するためのフローチャート図である。 ドキュメントビューアでの要件処理を説明するためのフローチャート図である。 ドキュメントビューアでの要件処理を説明するためのフローチャート図である。 ドキュメントビューアでの要件処理を説明するためのフローチャート図である。 ドキュメントビューアでの要件処理を説明するためのフローチャート図である。 要件として警告の印刷が指定された場合の画面例を示す図である。 要件として機密印刷が指定された場合の画面例を示す図である。 要件としてラベルをスタンプとして印刷することが指定された場合の画面例を示す図である。 要件として目に見える透かし文字の印刷が指定された場合の画面例を示す図である。 要件として識別パターンの印刷が指定された場合の画面例を示す図である。 機密印刷モードの要件処理シーケンスを示す図である。 地紋印刷モードの要件処理シーケンスを示す図である。 ユーザ権限レベルテーブルで管理されるデータ例を示す図である。 ユーザ権限レベルテーブルのＸＭＬファイルを示す図である。 ドキュメントプロファイル管理テーブルで管理されるデータ例を示す図である。 ゾーン管理テーブルで管理されるデータ例を示す図である。 ゾーン管理テーブルのＸＭＬファイルを示す図である。 ポリシーファイルに記述されるアクセス制御ルールを示す図である。 ポリシーファイルに記述されるアクセス制御ルールを示す図である。 認証結果情報の一例を示す図である。 コンテキスト情報の一例を示す図である。 ドキュメント識別情報の一例を示す図である。 判断結果情報の一例を示す図である。 プリントプロファイル管理テーブルの一例を示す図である。 印刷された識別パターンの例を示す図である。 認証結果情報のその他の例を示す図である。 ドキュメント識別情報の例を示す図である。

符号の説明

５０ イニシエータ
５１ 端末
５２ ユーザ
５３ ドキュメントビューア
６１ サーバドキュメント
６２ ペーパードキュメント
６３ ポータブルドキュメント
７０ デジタル複合機
１００ 文書管理システム
２００ セキュリティサーバ
２４０ ポリシーファイル
２５０ ユーザ権限レベルテーブル
２６０ ドキュメントプロファイル管理テーブル
２７０ ゾーン管理テーブル２７０
２８０ プリントプロファイル管理テーブル
３００ ユーザ管理サーバ
３１０ ユーザ管理テーブル
４００ アプリシステム

Claims (6)

1. アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信するアクセス判断要求受信手段と、
   組織の企業秘密管理規則に従って前記対象情報へのオペレーションを許可するか否かと、該オペレーションを許可する場合に実行させる要件と、該要件を実行するために使用される文字列又は画像データを指定する補足情報とを規定したセキュリティポリシーを記憶しておくセキュリティポリシー記憶領域と、
   前記アクセス判断要求にて指定される前記対象情報へのアクセスを要求するアクセス要求元を識別する第一の識別情報と、前記アクセスされる対象情報を識別する第二の識別情報とを、対応する各テーブルにマッピングされている組織の企業秘密管理レベルへと変換する抽象度変換手段と、
   前記第一及び第二の識別情報に各々対応する企業秘密管理レベルの組み合わせに基づいて、前記セキュリティポリシーを参照することによって、前記対象情報への前記アクセス判断要求で指定されるオペレーションに対するアクセス制御を判断するアクセス制御判断手段と、
   前記アクセス制御判断手段による前記対象情報へのアクセス制御を示す判断結果情報を前記アクセス判断要求を行った要求元へ送信する判断結果送信手段とを有し、
   前記オペレーションが許可される場合には、前記要件と前記補足情報とが指定された判断結果によって、前記アクセス判断要求を行った要求元に該補足情報を用いて該要件を実行させるようにしたことを特徴とするアクセス制御判断システム。
2. 前記セキュリティポリシーにおいて、前記要件として、ラベル印刷、ラベル表示、追跡情報埋め込み、警告の表示、警告の印刷、透かし文字の印刷、電子透かしの埋め込み、浮き出る透かし文字の印刷、複写抑止地紋のうち少なくとも１つを規定していることを特徴とする請求項１記載のアクセス制御判断システム。
3. 前記セキュリティポリシーにおいて、前記各要件は、固定画像データ、動的な画像データ、画像の埋め込み位置、警告文字列、ウォーターマークの文字列、電子透かしの文字列、背景文字列、地紋文字列、文字列の埋め込み位置、色の指定のいずれか１つの補足情報を指定していることを特徴とする請求項２記載のアクセス制御判断システム。
4. アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信して、アクセス制御を判断し、判断結果情報を前記アクセス判断要求を行った要求元へ送信するコンピュータにおけるアクセス制御判断方法において、前記コンピュータが、
   アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信するステップと、
   組織の企業秘密管理規則に従って前記対象情報へのオペレーションを許可するか否かと、該オペレーションを許可する場合に実行させる要件と、該要件を実行するために使用される文字列又は画像データを指定する補足情報とを規定したセキュリティポリシーを記憶領域に記憶しておくステップと、
   前記アクセス判断要求にて指定される前記対象情報へのアクセスを要求するアクセス要求元を識別する第一の識別情報と、前記アクセスされる対象情報を識別する第二の識別情報とを、対応する各テーブルにマッピングされている組織の企業秘密管理レベルへと変換するステップと、
   前記第一及び第二の識別情報に各々対応する企業秘密管理レベルの組み合わせに基づいて、前記セキュリティポリシーを参照することによって、前記対象情報への前記アクセス判断要求で指定されるオペレーションに対するアクセス制御を判断するステップと、
   前記アクセス制御判断手順による前記対象情報へのアクセス制御を示す判断結果情報を前記アクセス判断要求を行った要求元へ送信するステップとを実行し、
   前記オペレーションが許可される場合には、前記要件と前記補足情報とが指定された判断結果によって、前記アクセス判断要求を行った要求元に該補足情報を用いて該要件を実行させるようにしたことを特徴とするアクセス制御判断方法。
5. アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信するステップと、
   組織の企業秘密管理規則に従って前記対象情報へのオペレーションを許可するか否かと、該オペレーションを許可する場合に実行させる要件と、該要件を実行するために使用される文字列又は画像データを指定する補足情報とを規定したセキュリティポリシーを記憶領域に記憶しておくステップと、
   前記アクセス判断要求にて指定される前記対象情報へのアクセスを要求するアクセス要求元を識別する第一の識別情報と、前記アクセスされる対象情報を識別する第二の識別情報とを、対応する各テーブルにマッピングされている組織の企業秘密管理レベルへと変換するステップと、
   前記第一及び第二の識別情報に各々対応する企業秘密管理レベルの組み合わせに基づいて、前記セキュリティポリシーを参照することによって、前記対象情報への前記アクセス判断要求で指定されるオペレーションに対するアクセス制御を判断するステップと、
   前記アクセス制御判断手順による前記対象情報へのアクセス制御を示す判断結果情報を前記アクセス判断要求を行った要求元へ送信するステップとをコンピュータに実行させ、
   前記オペレーションが許可される場合には、前記要件と前記補足情報とが指定された判断結果によって、前記アクセス判断要求を行った要求元に該補足情報を用いて該要件を実行させるようにしたことを特徴とするコンピュータ実行可能なアクセス制御判断プログラム。
6. アクセスされる対象情報へのアクセス制御の判断を要求するアクセス判断要求を受信するステップと、
   組織の企業秘密管理規則に従って前記対象情報へのオペレーションを許可するか否かと、該オペレーションを許可する場合に実行させる要件と、該要件を実行するために使用される文字列又は画像データを指定する補足情報とを規定したセキュリティポリシーを記憶領域に記憶しておくステップと、
   前記アクセス判断要求にて指定される前記対象情報へのアクセスを要求するアクセス要求元を識別する第一の識別情報と、前記アクセスされる対象情報を識別する第二の識別情報とを、対応する各テーブルにマッピングされている組織の企業秘密管理レベルへと変換するステップと、
   前記第一及び第二の識別情報に各々対応する企業秘密管理レベルの組み合わせに基づいて、前記セキュリティポリシーを参照することによって、前記対象情報への前記アクセス判断要求で指定されるオペレーションに対するアクセス制御を判断するステップと、
   前記アクセス制御判断手順による前記対象情報へのアクセス制御を示す判断結果情報を前記アクセス判断要求を行った要求元へ送信するステップとをコンピュータに実行させ、
   前記オペレーションが許可される場合には、前記要件と前記補足情報とが指定された判断結果によって、前記アクセス判断要求を行った要求元に該補足情報を用いて該要件を実行させるようにしたことを特徴とするアクセス制御判断プログラムを記憶したコンピュータ読み取り可能な記憶媒体。