JP2009519511A

JP2009519511A - 文書データセキュリティ管理方法及びそのシステム

Info

Publication number: JP2009519511A
Application number: JP2008543635A
Authority: JP
Inventors: ドングリンワン，; シュグオ，; チャンウェイリウ，; カイホンゾウ，
Original assignee: サーセンコーポレイション
Priority date: 2005-12-05
Filing date: 2006-12-05
Publication date: 2009-05-14
Also published as: WO2007065354A1; US20090320141A1; EP1965327A4; EP1965327A1

Abstract

本発明は、文書データセキュリティ管理方法を開示している。該方法は、汎用文書モデルに適合する文書又は文書ベースを管理する文書ベースシステムに応用され、前記文書ベース又は文書のロールを作成する過程と、前記ロールに権限を配分する過程と、ロールで前記文書又は文書ベースにログインする過程と、前記文書ベースシステムを介して前記文書又は文書ベースにアクセスする際、ログインしたロールの権限を検査する過程とを含む。また、本発明は、文書データセキュリティ管理システムと文書ベースシステムを開示している。本発明を採用することで、文書データのセキュリティが向上できる。
【選択図】図１１

Description

本発明は文書データ処理技術に関し、特に、文書データセキュリティ管理方法及びそのシステム、並びに文書ベースシステムに関する。

現在、情報は構造化データと非構造化データに大別される。構造化データの構造は、即ち２次元の表の構造であり、比較的に簡単である。構造化データの処理技術は、主にデータベースシステムを利用して処理することである。一方、テキスト文書及びストリーミングメディアを主とする非構造化データは固定のデータ構造がないため、非構造化データに対する処理が非常に複雑である。

現在、各種の非構造化文書処理アプリケーションは既に普及しており、さまざまな文書フォーマットが並存している状況になっている。例えば、文書編集については、現在、Ｍｉｃｒｏｓｏｆｔ（登録商標）のｗｏｒｄ、ＷＰＳ、永中科技有限公司のＯｆｆｉｃｅ、ＲｅｄのＯｆｆｉｃｅなどが存在している。通常、１つの内容管理アプリケーションは２００、３００種もの文書フォーマットに対して処理することがあり、そして、これらのフォーマットが絶えずに更新されているため、アプリケーションの開発者に多大な困難をもたらす。文書の汎用性、デジタル内容の抽出、フォーマットの互換性がますます業界の焦点になり、下記の問題を解決すべきである。

１）文書が汎用できない。
基本的に、異なるユーザは、同じアプリケーションで処理された文書だけ交換でき、異なるアプリケーションで処理された文書を交換できないため、情報の閉鎖につながる。

２）アクセスインターフェースが不統一で、データの互換性の代価が高すぎる。
異なる文書処理アプリケーションの間で、文書フォーマットは互いに互換できず、処理中においては、相手のフォーマットに対して、相手のコンポーネントを利用して解析し（相手から相応インターフェースの提供を前提とする）、又は、自分で研究開発の力を投入して最初から最後まで解析する必要がある。

３）情報セキュリティが悪い。
現在、テキスト文書に対する権限制御手段は単一で、主にデータ暗号化とパスワード認証とを含む。毎年、情報漏えいで会社が巨大な損失を食う事件は次々に発生する。

４）単一文書のみに対する処理であり、マルチ文書管理手段が乏しい。
各人のコンピュータに大量な文書があるが、複数の文書の間では、有効な組織管理が乏しく、且つリソースの共有が難しい。例えば、フォント・書体ファイルや全文データ検索などである。

５）ページの階層化の技術が不整備。
現在、Ａｄｏｂｅ（登録商標）のｐｈｏｔｏｓｈｏｐやＭｉｃｒｏｓｏｆｔのｗｏｒｄのようなアプリケーションには層という概念が多少あったが、その層は、機能がまだ単純で、管理手段が比較的に簡単で、応用ニーズを満たすことができない。

６）検索手段が豊富でない。
情報の大量化に伴い、どのキーワードで検索しても膨大な検索結果になってしまう。全文検索技術により再現率の課題がほぼ解決されているが、適合率が速やかに最も重要な課題になっている。従来技術では、適合率の課題の解決に全ての情報を十分に利用していない。例えば、各字の書体や文字サイズが、この字の重要性判断にまったく使用可能であるが、検索時に無視されてしまった。

現在、各大手会社は全部、自社特有の文書フォーマットを市場の標準規格に発展させるように努力しており、各標準化団体も汎用文書フォーマット規格の制定に力を尽くしている。しかし、専有の文書フォーマット（例えば．ｄｏｃ）やオープンな文書フォーマット（例えばＰＤＦ）にかかわらず、文書フォーマットを規格とする限り、下記の問題が避けられない。

ａ）重複開発、効果の不統一
同一文書フォーマット標準規格を使用する異なるアプリケーションがこのフォーマットの文書の解釈・生成を自分で行う必要があることにより、大量の重複開発をもたらす。また、各アプリケーションの解釈プログラムは異り、例えば、整備なものもあるし、相対的に簡単なものもあり、新バージョンをサポートするものもあるし、旧バージョンのみをサポートするものもある。そのため、同一文書は異なるアプリケーションによって異なるページレイアウトで表示され、ひいては、解釈エラーが発生して文書を開けくことができないこともある。

ｂ）革新に妨害
ソフトウェア産業は絶えずに革新している産業であるが、新機能を追加するたびにこの機能の記述情報を追加する必要があり、且つ、新たなフォーマットの追加が標準規格の修正時まで待つしかできないため、記憶フォーマットの固定は技術革新の競争を妨害する。

ｃ）検索性能に影響
大量の情報に対して、検索性能を向上するため、大量の検索情報を追加する必要があるが、固定の記憶フォーマットについては検索情報の追加が難しい。

ｄ）可搬性と拡張性に影響
異なるシステム環境下で、異なる応用ニーズにより異なる記憶要求がありうる。例えば、ハードディスクに記憶する場合、性能を向上するようにディスクヘッドのシーク回数を如何に減少するかを考慮する必要がある。一方、組込式応用では、データがメモリに記憶されるものに相当するため、上記問題はない。例えば、同一メーカーのデータベースアプリケーションは、異なるプラットフォームで異なる記憶フォーマットを使用する可能性がある。そのため、文書記憶標準規格の設定はシステムの可搬性と拡張性に影響を及ぼす。

従来技術で最もオープンな、互換性の最も優れた文書がＡｄｏｂｅＡｃｒｏｂａｔのＰＤＦである。しかし、ＰＤＦは既にグローバルの文書配布・交換の事実上の標準規格になったにもかかわらず、異なるアプリケーションの間でＰＤＦ文書の交換は実現できなく、つまり、ＰＤＦ文書の相互運用性を実現できない。そして、ＡｃｒｏｂａｔやＯｆｆｉｃｅにかかわらず、単一文書しか処理できず、マルチ文書に対する管理機能が乏しく、文書ベースへの操作機能を有しない。

一方、従来技術は文書情報セキュリティの面にも多くの欠陥がある。ＷｏｒｄとＰＤＦのような応用の最も幅広い文書では、全部、データ暗号化又はパスワード認証などを採用してデータセキュリティ制御を行うが、体系的な身分認証メカニズムを提供せず、権限制御は、文書全体の範囲で行われ、文書内の任意領域まで精細化できず、ロジックデータに対する暗号化と署名の指定が制限され、任意のロジックデータに対して暗号化と署名を設定できない。内容管理システムでは、良い身分認証メカニズムを提供できるが、内容管理システムが文書処理システムと分離しており、コア層に組み入れられることができないため、文書レベルの管理粒度しか実現できないばかりでなく、文書が使用中に内容管理システムのセキュリティ制御から離れ、必要なセキュリティ管理を実行しにくい。通常の場合、従来のセキュリティメカニズムと文書処理がそれぞれ単独のモジュールで実現されるため、セキュリティ欠陥が発生しやすい。

以下、従来のセキュリティ管理技術と概念を紹介する。

現在のセキュリティ管理技術では、通常、公開鍵基盤（ＰｕｂｌｉｃＫｅｙＩｎｆｒａｓｔｒｕｃｔｕｒｅ，ＰＫＩ）アルゴリズムとも呼ばれる非対称鍵暗号アルゴリズムが採用される。そのアルゴリズムとは、主に暗号化鍵と復号化鍵が異なり、且つ両者の間で導出関係がないものであるため、ユーザによりそのうちの一方の鍵が公開されても、もう一方の鍵が漏洩することはない。このように、他人は公開鍵を用いて送信情報を暗号化してユーザに安全に伝送し、その後、ユーザは自分の秘密鍵を用いて復号化することができる。ＰＫＩ技術により、鍵の発行と管理の問題が解決されている。ＰＫＩ技術は現在常用の暗号技術である。ＰＫＩ技術を利用することで、データ通信の双方が相手の身分の確認と鍵の公開を安全に行うことができ、通信の認証性が提供されている。現在、ＰＫＩアルゴリズムとして、楕円曲線暗号（ＥＣＣ：ＥｌｌｉｐｔｉｃＣｕｒｖｅｓＣｒｙｐｔｏｇｒａｐｈｙ）の暗号化アルゴリズム、ＲＳＡ暗号化アルゴリズム（ＲｏｎＲｉｖｅｓｔ，ＡｄｉＳｈａｍｉｒ，ＬｅｎＡｄｌｅｍａｎ公開鍵アルゴリズム）などが常に利用される。以下、ＲＳＡ暗号化アルゴリズムと楕円曲線暗号の暗号化アルゴリズムをそれぞれ簡単に説明する。

１、ＲＳＡアルゴリズム
公開鍵：ｎ＝ｐｑ（ｐ、ｑは非常に大きな２つの異なる素数であり、ｐとｑを秘密にしなければならない） φ（ｎ）＝（ｐ−１）×（ｑ−１）
φ（ｎ）と互いに素な整数ｅ（１＜ｅ＜φ（ｎ））を選択し、
秘密鍵：ｄ＝ｅ−１ｍｏｄφ（ｎ）、即ち、式ｄｅ＝１ｍｏｄφ（ｎ）を満たすように、数ｄを算出し、
暗号化：ｃ＝ｍｃ（ｍｏｄｎ）
復号化：ｍ＝ｃｄ（ｍｏｄｎ）
ここで、ｍは平文であり、ｃは暗号文である。

２、楕円曲線暗号（ＥＣＣ）の暗号化アルゴリズム
楕円曲線暗号の暗号化アルゴリズムは、もう１つの非対称鍵暗号アルゴリズムであり、楕円曲線を暗号アルゴリズムに利用するものである。このアルゴリズムが現れて以来、暗号解読法の研究対象となっている。現在、ビジネス向けと政府向けの用途において、楕円曲線暗号システム（ＥＣＣ）が安全であると考えられる。既知の暗号解読法の知識によって、伝統の暗号システムに比べて、楕円曲線暗号システムがより高い安全性を提供している。

下記のように、ＥＣＣ暗号化アルゴリズムを説明する。

大きな素数の領域上の楕円曲線について、同型写像を通して、一般の曲線の方程式を非常に簡単な形式ｙ２＝ｘ３＋ａｘ＋ｂに変換することができる。ここで、曲線のパラメータａ、ｂ∈Ｆｐ、且つ４ａ３＋２７ｂ２≠０（ｍｏｄｐ）を満たす。

そのため、下記の方程式を満たす全ての点（ｘ，ｙ）、及び無限遠点Ｏ∞によって、大きな素数領域Ｆｐで定義される楕円曲線を構成する。
Ｙ２＝ｘ３＋ａｘ＋ｂ（ｍｏｄｐ）

ここで、ｘ、ｙは０〜ｐ−１の大きな素数であり、この楕円曲線をＥｐ（ａ，ｂ）と表記する。

等式Ｋ＝ｋＧ（Ｋ、ＧはＥｐ（ａ，ｂ）上の点であり、ｋはｎ（ｎは点Ｇのオーダー）より小さい整数である）を考えると、ｋとＧが与えられる場合、加算法によってＫを算出するのは容易であるが、ＫとＧが与えられる場合、ｋを求めるのはかなり困難であるということを発見しやすい。

これが、楕円曲線暗号システムの基となる数学の難題である。点Ｇは基点（ｂａｓｅｐｏｉｎｔ）と呼ばれ、ｋ（ｋ＜ｎ、ｎは基点Ｇのオーダー）は秘密鍵（ｐｒｉｖａｔｅｋｅｙ）と呼ばれ、Ｋは公開鍵（ｐｕｂｌｉｃｋｅｙ）と呼ばれる。

暗号化アルゴリズムは公知の対称アルゴリズムを含むようにしてもよい。対称アルゴリズムとは、暗号化と復号化に同じ鍵が使用されるものである。例えば、ＡＥＳアルゴリズムが、政府情報セキュリティを保証できる新たな符号アルゴリズムを開発することを目的とする。いろいろの評価を経て、１５種類のアルゴリズムから、最終的にＡＥＳ標準アルゴリズムとしてＲｉｊｎｄａｅｌアルゴリズムが選定された。ＡＥＳアルゴリズムは、対称暗号化の繰り返しブロック暗号を提供する。ＡＥＳアルゴリズムでは、データブロックがビット配列に分けられ、各暗号操作がビット指向である。Ｒｉｊｎｄａｅｌアルゴリズムは４層を含む。第１層は８×８ビット置換（即ち、８ビットの入力、８ビットの出力）を含み、第２層及び第３層は線形混合層（配列の行シフト、列ミックス）を含み、第４層は拡大鍵と配列とのビットごとの排他的論理和を含む。

ＡＥＳは、ブロック長が１２８ビットであり、鍵長が１２８／１９２／２５６ビットであり、対応のラウンド数ｒが１０／１２／１４である。相応の暗号化方式は、暗号化の過程において、ｒ＋１個の拡大鍵が必要であり、４（ｒ＋１）個の３２ビットワードを構造する必要がある。シード鍵が１２８又は１９２ビットである場合、４（ｒ＋１）個の３２ビットワードを構造する過程は同じであるが、シード鍵が２５６ビットである場合、４（ｒ＋１）個の３２ビットワードを構造する過程は異なっている。

また、ハッシュ（ＨＡＳＨ）もセキュリティ情報管理分野で常用の概念である。それはハッシング、メッセージダイジェスト又はデジタルダイジェストとも呼ばれる。一方向ＨＡＳＨ関数を情報に応用することにより、任意の長さのデータブロックを、該データのＨＡＳＨ値と呼ばれる固定長の不可逆なデータに変換する。理論上から言うと、いかなるＨＡＳＨアルゴリズムでは、衝突が起こる（即ち、異なるデータは同じＨＡＳＨ値を持つ）のは必然である。ＨＡＳＨアルゴリズムの安全性には意味が２つある。１つは、ＨＡＳＨ値から元のデータを推測できない。２つは、理論上に可能であるにもかかわらず、計算上には、同じＨＡＳＨ値を持つ２つの異なるデータを構造することは不可能である。現在、ＭＤ５、ＳＨＡ１及びＳＨＡ２５６が比較的に安全なＨＡＳＨアルゴリズムと認められる。一方、ＨＡＳＨ関数の計算は普通比較的に速くて、相対的に簡単である。

本発明は、上記の文書処理技術のセキュリティ欠陥を解決するように、文書データセキュリティ管理方法及びそのシステム、並びに文書ベースシステムを提供している。本発明は、強い組み込み情報セキュリティ機能を備え、コア層において情報セキュリティ技術と密接に結合し、文書に最大の安全性を提供する。

本発明の目的を実現するため、本発明において、下記の解決手段が開示されている。

本発明は、文書データセキュリティ管理方法を開示している。該方法は、汎用文書モデルに適合する文書又は文書ベースを管理する文書ベースシステムに応用され、
前記文書ベース又は文書のロールを作成する過程と、
前記ロールに権限を配分する過程と、
ロールで前記文書又は文書ベースにログインする過程と、
前記文書ベースシステムを介して前記文書又は文書ベースにアクセスする際、ログインしたロールの権限を検査する過程とを含む。

上記の解決手段において、前記ロールに権限を配分する過程は、前記汎用文書モデルにおける一部又は全部のオブジェクトに対する権限をロールに配分する過程を含むようにしてよい。前記汎用文書モデルにおける一部又は全部のオブジェクトは、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、及びレイアウトオブジェクトのいずれか１つ又は任意の組合せを含むようにしてよい。

上記の解決手段において、前記ロールに権限を配分する過程は、アプリケーションが、目標オブジェクトに対して目標ロールに目標権限を配分することを要求するための権限付与要求を送信する過程と、該アプリケーションの全てのログインしたロールの、該目標オブジェクトに対する権限の和集合を計算し、該和集合が該目標権限のスーパーセットであり且つ権限再付与の権限を含む場合、該目標権限を該目標ロールの権限に追加する過程とを含む。

上記の解決手段において、該目標権限を該目標ロールの権限に追加した後に、該目標権限にリード権限が含まれる場合、目標オブジェクトを暗号化方式で記憶し、その復号化鍵を目標ロールに記憶する過程をさらに含むようにしてよい。

上記の解決手段において、該目標権限を該目標ロールの権限に追加した後に、該目標権限にライト権限が含まれる場合、目標オブジェクトを暗号化方式で記憶し、その暗号化鍵を目標ロールに記憶する過程をさらに含むようにしてよい。

上記の解決手段において、前記復号化鍵を目標ロールに記憶する過程は、ロールに対応する鍵を用いて該復号化鍵を暗号化して、得られた該復号化鍵の暗号文を記憶する過程を含むようにしてよい。

上記の解決手段において、前記暗号化鍵を目標ロールに記憶する過程は、ロールに対応する鍵を用いて該暗号化鍵を暗号化して、得られた該暗号化鍵の暗号文を記憶する過程を含むようにしてよい。

上記の解決手段において、前記目標オブジェクトを暗号化方式で記憶する過程は、ランダムの対称鍵とランダムのＰＫＩ鍵ペアを生成する過程と、該対称鍵を用いて該目標オブジェクトを暗号化する過程と、該ＰＫＩ鍵ペアの暗号化鍵を用いて該対称鍵を暗号化して、得られた該対称鍵の暗号文を記憶し、該目標オブジェクトに対して署名を行う過程とを含むようにしてよい。

上記の解決手段において、文書又は文書ベース内のオブジェクトに対してデジタル署名を行う過程をさらに含むようにしてよい。

上記の解決手段において、前記オブジェクトに対してデジタル署名を行う過程は、該オブジェクトに対して正規化を行い、正規化結果のＨＡＳＨ値を算出して、ＨＡＳＨ値をアプリケーションに送信する過程と、アプリケーションが全てのログインしたロールの秘密鍵を用いて該ＨＡＳＨ値を暗号化し、署名結果を返信する過程とを含むようにしてよい。

また、本発明は正規化方法を開示している。該方法は、ツリー構造に対して正規化を行うことに用いられ、所定の走査順序に従って、該ツリー構造の各ノードの正規化結果を算出して結合し、該ツリー構造の正規化結果を得る過程を含む。

上記の解決手段において、前記各ノードの正規化結果を算出する過程は、該ノードのサブノード数、類型、及び各属性の、元の値又は変換値を、所定の順序に従って結合して、結合結果の元の値又は変換値を該ノードの正規化結果とする過程を含むようにしてよい。

上記の解決手段において、前記各ノードの正規化結果を算出する過程は、該ノードのサブノード数、類型、及び各属性の、元の値又は変換値、並びに、サブノード数、類型、及び各属性の、長さの元の値又は変換値のいずれか１つ又は任意の組合せを、所定の順序に従って結合して、結合結果の元の値又は変換値を該ノードの正規化結果とする過程を含むようにしてよい。

また、本発明は文書ベースシステムを開示している。該システムは、汎用文書モデルに適合する文書又は文書ベースへのセキュリティ管理に用いられ、
前記文書又は文書ベースのロールを作成し、前記ロールに権限を配分するロール管理手段と、
ロールが前記文書又は文書ベースにログインする際、前記ロール管理手段を介して該ロールの身分を認証する身分認証手段と、
該文書又は文書ベースにアクセスする際、前記ロール管理手段と身分認証手段を介して、ログインしたロールの権限を検査するアクセス制御手段とを含む。

上記システムにおいて、ロール管理手段が、さらに、前記汎用文書モデルにおける一部又は全部のオブジェクトに対する権限をロールに配分するために用いられる。

上記のシステムにおいて、前記汎用文書モデルにおける一部又は全部のオブジェクトは、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、及びレイアウトオブジェクトのいずれか１つ又は任意の組合せを含むようにしてよい。

また、本発明は文書データセキュリティ管理システムを開示している。該システムは、文書のセキュリティ管理に用いられ、
前記文書のロールを作成し、文書オブジェクト、ページオブジェクト、又はページオブジェクトのサブオブジェクトに対する権限を前記ロールに配分するロール管理手段と、
ロールが前記文書にログインする際、前記ロール管理手段を介して該ロールの身分を認証する身分認証手段と、
文書にアクセスする際、前記ロール管理手段と身分認証手段を介して、ログインしたロールの権限を検査するアクセス制御手段とを含む。

本発明によれば、アプリケーション層とデータ処理層との分離に基づく文書処理技術は、情報セキュリティを文書処理のコア層に組み入れることができ、セキュリティ欠陥を消滅できる。また、セキュリティメカニズムと文書操作が、分離可能な２つのモジュールではなく、密接に一体化されるとともに、セキュリティ管理技術の配置空間がもっと多くなり、関連コードがもっと深く隠蔽されることができ、不法攻撃を有効に防げ、セキュリティ信頼性が向上でき、もっと多くの権限類別や、もっと小さい管理ユニットのような細粒度のセキュリティ管理手段も提供できる。また、本発明は汎用文書セキュリティモデルを提供している。この汎用文書セキュリティモデルが各アプリケーションによる文書セキュリティへのニーズに適合することで、異なるアプリケーションが同一のインターフェース部を介して文書に対するセキュリティ制御を実現するようになっている。

本発明の有益効果は、下記の通りである。文書データセキュリティ管理システムに身分認証メカニズムを組み入れることによって、任意のロジックデータに対してアクセス制御権限を指定でき、任意のロジックデータを暗号化することもできる。そして、このような暗号化が身分認証に関連しているので、任意に指定された１つ又は複数のロールに関連付けられることができる。また、本発明に係るシステムによれば、任意のロジックデータに対して署名を行うことができ、マルチセキュリティ特性を備える文書データセキュリティ管理を達成し、文書データが破壊されないように保証する。

以下、図面及び実施形態を参照しながら、本発明について更に詳しく説明する。ここで述べた具体的な実施形態は、本発明を解釈するのみに用いられ、本発明を限定するものではないと解されるべきである。

本発明に係るセキュリティ管理方法及びそのシステムは、主に以下のような文書処理システムに適用される。

従来の文書処理アプリケーションの悪い汎用性や、文書情報の抽出の困難、アクセスインターフェースの不統一、データの互換性の困難又は高すぎる代価、悪い可搬性と拡張性、ページの階層化の技術の不整備、単一な検索手段などの問題を解決するために、本発明は、ユーザインターフェースから文書記憶までを１つのアプリケーションによって実現する現状を変えている。本発明では、文書処理をアプリケーション層と文書ベースシステム層に区分し、且つ両層間のやり取りを規範したインターフェース標準を定義する。このインターフェース標準に適合するインターフェース層を更に構築してもよい。文書ベースシステムは各種の文書操作機能を備える汎用技術プラットフォームであり、アプリケーションが文書を操作しようとするとき、該インターフェース層を介して文書ベースシステムへ相応の指令を送信し、文書ベースシステムがこの指令に基づいて相応の操作を実行する。このように、各アプリケーションと各文書ベースシステムが同様の標準に従う限り、異なるアプリケーションは同一文書ベースシステムを介して同一文書を操作することができ、即ち文書の相互運用性を実現できる。同様に、同一アプリケーションは、各種の文書フォーマットに応じてそれぞれに開発することなく、異なる文書ベースシステムを介して異なる文書を操作することもできる。

また、本発明は汎用文書モデルも含み、このモデルが各アプリケーションの処理必要な文書にも適合することができる。インターフェース標準が該文書モデルに基づいて決定されたものであるため、異なるアプリケーションがインターフェース層を介して文書を操作できることが実現できる。この汎用文書モデルが各種の文書フォーマットにも適用できるため、同一アプリケーションがインターフェース層を介して異なるフォーマットの文書を操作することができる。ここで、インターフェース標準には、該汎用文書モデルに基づいて文書を操作するための各種の指令、及びアプリケーションから文書ベースシステムへの指令送信の方式が定義されている。文書ベースシステムは、アプリケーションからのこれらの指令を実現する機能を備える。また、該汎用文書モデルには、複数の文書からなる文書セット、文書ベース及び文書ウェアハウスなどの階層が含まれ、インターフェース標準にも、マルチ文書の組織管理、問い合わせ検索、及びセキュリティ制御などの指令が含まれる。また、該汎用モデルには、上下の順序を有する層からなるページが含まれ、インターフェース標準にも、層に対する各種の操作指令、及び文書のある層に対応するソースファイルの記憶と取り出しが含まれる。また、文書ベースシステムは、ロールに基づく細粒度の権限管理のような文書の情報セキュリティ管理制御機能を備え、且つインターフェース標準には関連の操作指令が定義されている。

本発明によれば、アプリケーション層とデータ処理層を分離させることになる。このように、アプリケーションが具体的な文書フォーマットと直接な関係なく、文書も特定のアプリケーションとバインドされず、同一文書が、異なるアプリケーション間で汎用でき、同一アプリケーションも、異なる文書を操作できるようになって、文書の相互運用性が実現されている。文書処理システム全体は、単一文書処理に限られず、マルチ文書処理機能も備える。ページを複数の層に分けると、異なる層に対して異なる管理と制御を行うことが実現でき、異なるアプリケーションによる同一ページに対する操作（異なるアプリケーションによる異なる層への管理・維持と設計してよい）が更に便利になる。これは、ソースファイル方式で編集することに便利で、履歴保存のよい方式でもある。

以下、図１〜１０を参照しながら、本発明に係るセキュリティ管理方法及びそのシステムが応用された文書処理システムを説明する。

図１に示すように、本発明による文書処理システムは主にアプリケーションと、インターフェース層と、文書ベースシステムと、記憶装置と、を含む。

ここでのアプリケーションは、従来の文書処理と内容管理のいかなるアプリケーションを含む。これらのアプリケーションは、文書処理システムのアプリケーション層に位置し、インターフェース標準に適合する指令の送信により文書を操作する。前記操作は全部、汎用文書モデルに適合する文書に対して行うものであり、具体的な記憶フォーマットと関係ない。

ここでのインターフェース層は、アプリケーション層と文書ベースシステムとの間のやり取りを規範したインターフェース標準に適合する。前記アプリケーション層は、インターフェース層を介して、文書ベースシステムに標準指令を送信し、前記文書ベースシステムは、インターフェース層を介して、アプリケーション層に実行結果を返信する。上記からわかるように、アプリケーションが皆インターフェース層を介して標準指令を送信し、汎用文書モデルに適合する文書を操作できるため、異なるアプリケーションは同一文書ベースシステムを介して同一文書を操作でき、同一アプリケーションは異なる文書ベースシステムを介して異なるフォーマットの文書も操作できる。

好ましくは、インターフェース層に上インターフェースユニットと下インターフェースユニットが含まれてよい。アプリケーションは上インターフェースユニットを介して標準指令を下インターフェースユニットに送信し、文書ベースシステムは下インターフェースユニットを介して標準指令を受信し、下インターフェースユニットはまた上インターフェースユニットを介して文書ベースシステムの実行結果をアプリケーションに返信する。実現には、上インターフェースユニットはアプリケーション層に位置してよく、下インターフェースユニットは文書ベースシステムに位置してよい。

ここでの文書ベースシステムは、文書処理システムのコア層であり、アプリケーションからインターフェース層を介して送信された標準指令に基づいて、具体的な文書処理操作を実行する。

ここでの記憶装置は、文書処理システムの記憶層であり、通常、ハードディスク又はメモリを含み、コンパクトディスク、フラッシュメモリ、フロッピーディスク、テープ、又はリモート記憶装置を含んでもよく、つまりデータ記憶能力さえあればよい。記憶装置には複数の文書が記憶されるが、アプリケーションにとって文書の具体的な記憶方式に注目する必要はない。

上記からわかるように、本発明によれば、アプリケーション層とデータ処理層を確実に分離させ、文書が特定のアプリケーションとバインドされず、アプリケーションが具体的な文書フォーマットと直接な関係なく、異なるアプリケーションで汎用文書モデルに適合する同一文書を編集でき、異なるアプリケーションの間で文書の優れた相互運用性を有するようになった。

以下、本発明が応用された文書処理システムの具体的な実施形態を説明する。

汎用文書モデル
紙の特性を参考して前記汎用文書モデルを定義してよい。これは、紙を文書情報の記録手段とすることが今まで通用している標準方法であり、紙の全ての機能さえあれば、仕事や生活などの実際の応用ニーズを満たすことができるためである。

文書内の１ページを１枚の紙と見なして、紙に書かれることができるいかなるものを記録すれば、この汎用文書モデルはページ上の全ての可視内容を記述できる。従来技術のページ記述言語（例えばＰｏｓｔＳｃｒｉｐｔ）が紙に印刷可能な全ての情報を記述できるため、この部分について詳しい説明を省略する。一般的に、ページ上の可視内容は最終的にテキスト、図形、及び画像の３種類に分かれてよい。

文書が特定書体又は特殊文字に係る場合、各コンピュータでの同じ効果を確保するために、文書に相応のフォントを組み込む必要がある。記憶効率を向上するために、フォントリソースを共有すべきである。このようにして、複数の箇所に同じ文字を使用しても、１つだけのフォントを組み込めばよい。画像も複数の箇所に出る可能性があり、例えば、各ページで共通の背景画像又はいつも出てくる会社のロゴである。この場合にも、これらの画像を共有したほうがよい。

もちろん、より先進的な情報処理ツールとしては、紙の特性を模擬するだけでなく、メタデータ、ナビゲーション、スレッド、サムネイルイメージのような強化されたデジタル特性を追加する必要がある。メタデータは、データを記述するためのデータを含む。例えば、図書のメタデータは、著者、出版社、出版日付、ＩＳＢＮ番号などを含む。メタデータが業界内の共通用語であるため、ここで説明を省略する。ナビゲーションは図書の目次のような情報を含み、それも業界内の共通用語である。スレッド情報が文書の所在領域と閲読の順序を記述するため、読者が、あるスクリーンを読んだ後、次のスクリーンに表示すべきものは該情報に基づいて自動的に判断されることができる。また、スレッド情報によっては、読者が手動で位置を指定することなく、自動改段や自動改ページも実現できる。サムネイルイメージは、事前に生成した、各ページの縮小図を含む。読者はサムネイルイメージを調べることによってどのページを閲読するかを指定できる。

図２は本発明の好ましい実施形態に係る汎用文書モデルである。図２に示すように、この汎用文書モデルには、文書ウェアハウス、文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、レイアウトオブジェクトなどの複数の階層が含まれる。

ここで、文書ウェアハウスは１つ又は複数の文書ベースからなる。文書ベースの下位階層間の関係と比べて、文書ベース間の関係が比較的に緩く、文書ベース自身のデータを修正することなく、文書ベース同士が簡単に組合せ・解体されることができる。この複数の文書ベースの間は統一インデックス（特に全文インデックス）が作成されていない場合が多いため、文書ウェアハウスに対する多くの検索操作については、普通、使用可能な統一的なインデックスがなく、各文書ベースのインデックスを走査する必要がある。各文書ベースはそれぞれ１つ又は複数の文書セットからなる。各文書セットはそれぞれ、１つ又は複数の文書からなり、任意数のサブ文書セットも含んでよい。ここで言われた文書は、現在の普通の文書ファイル（例えばＤＯＣ文書）を含む。汎用文書モデルでは、１つの文書が１つの文書セットのみに属することを規定してもよいが、１つの文書が複数の文書セットに属することを許してもよい。文書ベースは、複数の文書の簡単な組合せではなく、複数の文書を密接に組織してできたものである。特に、文書内容のために各種の統一検索インデックスを作成すると、より大きな利便性をもたらす。

各文書はそれぞれ、１ページ、又は一定の順序（例えば前後の順序）を有する複数のページからなる。各ページの版面は異なってよく、且つ、版面は、必ずしも矩形ではなく、任意の形状であってよく、１本又は複数本の閉曲線で表すことができる。

各ページはそれぞれ、１層、又は一定の順序（例えば上下の順序）を有する複数の層からなる。各層間は重なり合うガラス板のような関係である。層は任意数のレイアウトオブジェクトとオブジェクトグループからなる。レイアウトオブジェクトは、ステータス（例えば、書体、文字サイズ、色、ＲＯＰなど）、テキスト（符号を含む）、図形（例えば、直線、曲線、指定の色で塗りつぶされた閉領域、グラデーション色など）、画像（例えば、ＴＩＦ、ＪＰＥＧ、ＢＭＰ、ＪＢＩＧなど）、セマンティック情報（例えば、タイトル開始、タイトル終了、改行など）、ソースファイル、スクリプト、プラグイン、組込式オブジェクト、ブックマーク、ハイパーリンク、ストリーミングメディア、２値化データストリームなどを含む。１つ又は複数のレイアウトオブジェクトが１つのオブジェクトグループに構成されてよい。オブジェクトグループに任意数のサブオブジェクトグループが含まれてもよい。

文書ベース、文書セット、文書、ページ、層には、メタデータ（例えば、名称、最後の修正時間などであり、その類型は応用ニーズによって設定できる）及び／又は履歴がさらに含まれてよい。文書には、ナビゲーション情報、スレッド情報、サムネイルイメージがさらに含まれてよい。サムネイルイメージをページ又は層のレベルに置いてもよい。文書ベース、文書セット、文書、ページ、層、オブジェクトグループには、デジタル署名がさらに含まれてよい。セマンティック情報はレイアウト情報に従ったほうがよい。これによって、データの冗長を避けることができ、且つレイアウトとの対応関係の確立が比較的に容易になる。文書ベース、文書には、フォントや画像などの共有リソースが含まれてもよい。

また、この汎用文書モデルでは、１つ又は複数のロールを定義して、各ロールに一定の権限を配分してもよい。文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、メタデータをユニットとして権限を配分し、各ロールに対して、該ユニットへのリード可否、ライト可否、コピー可否、印刷可否などを定義する。

この汎用文書モデルは、単一文書が単一ファイルに対応する従来の方式を超えるものである。文書ベースには複数の文書セットが含まれ、文書セットには複数の文書が含まれる。文書ベース内の文書内容に対して細粒度のアクセスとセキュリティ制御を採用していることで、従来の文書管理システムがファイル名レベルしかアクセスできないことと違って、文書ベース内のある文字又は矩形まで具体的にアクセスできる。

図３〜図９は本発明の好ましい実施形態に係る汎用文書モデルに関する各オブジェクトの構成を示す図である。前記各オブジェクトの構成はツリー構造であり、層ごとに展開、細分化される。

文書ウェアハウスオブジェクトは１つ又は複数の文書ベースオブジェクト（図示せず）からなる。

図３に示すように、文書ベースオブジェクトには、１つ又は複数の文書セットオブジェクト、任意数の文書ベース補助オブジェクト、及び任意数の文書ベース共有オブジェクトが含まれる。

図４に示すように、前記文書ベース補助オブジェクトには、メタデータオブジェクト、ロールオブジェクト、権限オブジェクト、プラグインオブジェクト、インデックス情報オブジェクト、スクリプトオブジェクト、デジタル署名オブジェクト、履歴オブジェクトなどが含まれる。文書ベース共有オブジェクトには、文書ベース内の異なる文書で共有可能なオブジェクト、例えばフォントオブジェクトや画像オブジェクトなどが含まれる。

図５に示すように、各文書セットオブジェクトにはそれぞれ、１つ又は複数の文書オブジェクト、任意数の文書セットオブジェクト、及び任意数の文書セット補助オブジェクトが含まれる。文書セット補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。文書セットオブジェクトに複数の文書セットオブジェクトが含まれる場合は、エクスプローラにおいて１つのフォルダに複数のフォルダが含まれる形式と類似している。

図６に示すように、各文書オブジェクトにはそれぞれ、１つ又は複数のページオブジェクト、任意数の文書補助オブジェクト、及び任意数の文書共有オブジェクトが含まれる。文書補助オブジェクトには、メタデータオブジェクト、フォントオブジェクト、ナビゲーション情報オブジェクト、スレッド情報オブジェクト、サムネイルイメージオブジェクト、デジタル署名オブジェクト、履歴オブジェクトなどが含まれる。文書共有オブジェクトには、文書内の異なるページに共通使用可能なオブジェクト、例えば画像オブジェクトや印章オブジェクトなどが含まれる。

図７に示すように、各ページオブジェクトにはそれぞれ、１つ又は複数の層オブジェクト、及び任意数のページ補助オブジェクトが含まれる。ページ補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。

図８に示すように、各層オブジェクトにはそれぞれ、１つ又は複数のレイアウトオブジェクト、任意数のオブジェクトグループ、及び任意数の層補助オブジェクトが含まれる。層補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。オブジェクトグループには、任意数のレイアウトオブジェクト、任意数のオブジェクトグループ、及び選択可能なデジタル署名オブジェクトが含まれる。オブジェクトグループに複数のオブジェクトグループが含まれる場合は、エクスプローラにおいて１つのフォルダに複数のフォルダが含まれる形式と類似している。

図９に示すように、レイアウトオブジェクトには、ステータスオブジェクト、テキストオブジェクト、直線オブジェクト、曲線オブジェクト、円弧オブジェクト、パスオブジェクト、グラデーション色オブジェクト、画像オブジェクト、ストリーミングメディアオブジェクト、メタデータオブジェクト、コメントオブジェクト、セマンティック情報オブジェクト、ソースファイルオブジェクト、スクリプトオブジェクト、プラグインオブジェクト、２値化データストリームオブジェクト、ブックマークオブジェクト、及びハイパーリンクオブジェクトが含まれる。

ここで、ステータスオブジェクトには、任意数の、文字セットオブジェクト、書体オブジェクト、文字サイズオブジェクト、文字色オブジェクト、ラスター操作オブジェクト、背景色オブジェクト、線色オブジェクト、塗りつぶし色オブジェクト、線種（ｌｉｎｅｔｙｐｅ）オブジェクト、線幅（ｌｉｎｅｗｉｄｔｈ）オブジェクト、継ぎ目オブジェクト、ブラシオブジェクト、陰影オブジェクト、陰影色オブジェクト、回転オブジェクト、袋文字オブジェクト、縁取り文字オブジェクト、透明オブジェクト、及びレンダリングモードオブジェクトが含まれる。

具体的な実施過程において、上記汎用文書モデルの上でさらに強化又は簡略化してよい。簡略化モデルに文書セットオブジェクトが省略される場合、文書ベースオブジェクトは文書オブジェクトを直接に含み、簡略化モデルに層オブジェクトが省略される場合、ページオブジェクトはレイアウトオブジェクトを直接に含む。

最も簡略化された汎用文書モデルには、文書オブジェクト、ページオブジェクト、及びレイアウトオブジェクトのみが含まれることが理解できる。ここで、レイアウトオブジェクトには、テキストオブジェクト、直線オブジェクト、及び画像オブジェクトのみが含まれる。完全モデルと最も簡略化されたモデルとの間の各種の中間モデルは、この好ましい実施形態の変形である。

各種の応用による文書セキュリティへのニーズを満すために、汎用文書セキュリティモデルを定義する必要がある。さらに、従来のアプリケーションを含み且つ超える汎用文書セキュリティモデルを得る。該汎用文書セキュリティモデルの定義は下記のようなことを含む。

１．ロールオブジェクト
文書ベースにおいて若干のロールを定義して、ロールオブジェクトを形成する。通常、ロールオブジェクトは文書ベースオブジェクトのサブオブジェクトである。対応の汎用文書モデルには文書ベースオブジェクトがない場合、ロールは文書において定義され、即ちロールオブジェクトは文書オブジェクトのサブオブジェクトである。この場合、本汎用文書セキュリティモデルに言われた文書ベースは全て文書により代替されるべきである。

２．ロールのアクセス権限の指定
任意ロールによる任意オブジェクト（例えば、文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、レイアウトオブジェクトなど）へのアクセス権限を指定できる。あるロールによるあるオブジェクトへのアクセス権限を指定すると、この権限は該オブジェクトの全てのサブオブジェクトに適用する。

ここで、文書ベースシステムで実現されたアクセス権限には、リード可否、ライト可否、権限再付与（即ち、他のロールに自分の部分又は全部の権限を与える）可否、権限解除（即ち、他のロールの部分又は全部の権限を解除する）可否、及び上記の任意の組合せが含まれる。ここで、本発明におけるアクセス権限は上記に限定されず、印刷不可のような、更なる多くの権限も定義できる。

３．ロールの身分でのオブジェクト署名
あるロールの身分で各オブジェクトに対して署名できる。あるオブジェクトに対する署名範囲は、該オブジェクトのサブオブジェクト、及び該オブジェクトで引用されたオブジェクトを含む。

４．ロールの作成
ロールオブジェクト作成指令の応答として、後で該ロール身分でログインするための鍵が返信される。この鍵は、通常、ＰＫＩの秘密鍵であり、アプリケーションによって適切に保管される必要がある。この鍵はログインパスワードであってもよい。好ましくは、いかなるアプリケーションが、いかなる権限もない新たなロールの作成権限を有する。再付与権限のあるロールを用いて新たなロールに一定の権限を付与することが可能である。

５．ロール身分のログイン
アプリケーションが、あるロールの身分でログインする場合、「挑戦／応答」メカニズムが採用できる。即ち、文書ベースシステムが、保存しているロールの公開鍵を用いてランダムデータブロックを暗号化して、アプリケーションに送信し、アプリケーションが、そのデータブロックを復号化してから文書ベースシステムに返信し、復号化が正しい場合は、アプリケーションがこのロールに対応する秘密鍵を確実に有することを表す（念のため、この認証プロセスが何回も繰り返されることが可能である）。「挑戦／応答」メカニズムは下記の方式で実現することもできる。即ち、文書ベースシステムがランダムデータブロックをアプリケーションに送信し、アプリケーションが秘密鍵を用いてそれを暗号化してから文書ベースシステムに返信し、文書ベースシステムが、保存しているロールの公開鍵を用いて、その暗号化されたものを復号化し、復号化が正しい場合は、アプリケーションがこのロールに対応する秘密鍵を確実に有することを表す。「挑戦／応答」メカニズムを用いることで、秘密鍵のセキュリティをよりよく保護できる。ロールの鍵がログインパスワードである場合、ユーザが正しいログインパスワードを入力しなければならない。

また、アプリケーションは同時に複数のロールの身分でログインしてもよく、この時、このアプリケーションの有している権限はそれらの複数のロールの権限の和集合である。

６．デフォルトロール
特殊のデフォルトロールが作成できる。デフォルトロールが存在する場合、いかなるロールでもログインしなくても、デフォルトロールの身分で文書ベースを操作できる。好ましくは、文書ベースの初期作成時に、全ての権限を有するデフォルトロールを自動的に作成する。

具体的な実施過程において、上記の汎用文書セキュリティモデルの上でステップをさらに強化、簡略化、又は合併してよい。それらの変更後の汎用文書セキュリティモデルはいずれも本実施形態の変形である。

インターフェース層の具体的な実現
前記インターフェース層の統一インターフェース標準は、汎用文書モデル、汎用文書セキュリティモデル及び常用の文書操作に基づいて定義されてよく、汎用文書モデル内の各オブジェクトに対する操作指令を送信することに用いられる。前記汎用文書モデル内の各オブジェクトに対する操作指令はインターフェース標準に適合し、各種のアプリケーションはインターフェース層を介して標準指令を送信できる。

以下、インターフェース標準の実現方式を紹介する。インターフェース標準を実現するために、上インターフェースユニットが、予め定義された標準フォーマットに従って、例えば「＜ＵＯＭＬ＿ＩＮＳＥＲＴ（ＯＢＪ＝ＰＡＧＥ，ＰＡＲＥＮＴ＝１２３．４５６．７８９，ＰＯＳ＝３）／＞」のような命令列を生成し、この命令列を下インターフェースユニットに送信し、下インターフェースユニットを介して、文書ベースシステムから、該命令に対する実行結果又は他のフィードバック情報を受信するようにしてよい。又は、インターフェース標準を実現するために、下インターフェースユニットが、標準名称とパラメータを有する、例えば「ＢＯＯＬＵＯＩ＿ＩｎｓｅｒｔＰａｇｅ（ＵＯＩ＿Ｄｏｃ＊ｐＤｏｃ，ｉｎｔｎＰａｇｅ）」のようなインターフェース関数を若干提供し、上インターフェースユニットがこれらの標準関数を呼び出し、呼び出し操作自身は上インターフェースユニットが標準指令を送信することと意味するようにしてよい。又は、インターフェース標準を実現するために、上記方法を組合せてよい。

インターフェース標準が「操作動作＋操作オブジェクト」の方式で実現されると、インターフェース標準の勉強と理解に便利で、インターフェース標準の安定性維持にも便利である。例えば、２０種類の異なるオブジェクトに対して１０種類の操作を行う場合、２０×１０＝２００種類の指令を定義してもよいし、２０種類のオブジェクトと１０種類の動作を定義してもよい。しかし、後者の方式では、記憶負担が大いに軽減するのが明らかで、且つ今後インターフェース標準を拡張する時、オブジェクト又は動作の追加も簡単である。前記操作オブジェクトは、汎用文書モデルに含まれるオブジェクトである。

例えば、以下の７種類の操作動作を定義する。
オープン：文書ベースを作成又はオープンする。
クローズ：セッションハンドルや文書ベースをクローズする。
取得：オブジェクトリスト、オブジェクトの関連属性及びデータを取得する。
設定：オブジェクトデータを設定・修正する。
挿入：指定のオブジェクト又はデータを挿入する。
削除：オブジェクトのあるサブオブジェクトを削除する。
検索問い合わせ：定義された条件によって文書において条件に適合する内容を検索する。これらの条件は、正確な情報であってもよいし、不正確な情報であってもよい。即ち、曖昧検索がサポートされる。

文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、テキスト、画像、図形、パス（順に接続された図形からなるグループであり、ここでの図形は開図形又は閉図形であってもよい）、ソースファイル、スクリプト、プラグイン、オーディオ、ビデオ、ロールなどのようなオブジェクトを定義する。

オブジェクトには、背景色、線色、塗りつぶし色、線種、線幅、ＲＯＰ、ブラシ、陰影、陰影色、文字高さ、文字幅、回転、透明、レンダリングモードなどのステータスオブジェクトも含まれる。

「操作動作＋操作オブジェクト」の方式でインターフェース標準を実現する場合、各オブジェクトと各動作の全ての組合せは必ず実際の意味のある操作指令を構成できると自動的に認識すべきでなく、一部の組合せは意味がない、ということが理解できる。

「操作動作＋操作オブジェクト」以外の関数方式でインターフェース標準を定義するようにしてもよい。例えば、各オブジェクトの各種の操作ごとに１つのインターフェース関数を定義すると、各種の操作指令は、上インターフェースユニットから下インターフェースユニットのインターフェース関数を呼び出すことで文書ベースシステムに送信される。

各オブジェクトをカプセル化して、例えば文書ベースクラスのようなクラスを形成し、該オブジェクトの実行可能な操作を該クラスのメソッドとして定義するようにしてもよい。

特に、インターフェース標準ではページビットマップの取得指令が定義されると、レイアウトの一致性、及び文書の相互運用性の保障に肝心な役割を果たす。

ページビットマップの取得指令によって、アプリケーションは、自分で各レイアウトオブジェクトを解釈して処理することなく、指定ページの指定ビットマップフォーマットのページビットマップ、即ちビットマップ方式で表されるこのページの表示効果を直接に取得できる。つまり、アプリケーションは、文書の表示・印刷のための正確なページビットマップを直接に取得できるが、自分でページの各層の各レイアウトオブジェクトを逐一読み取って該オブジェクトの意味を解釈してレイアウトに反映することが不要となる。アプリケーションが自分でオブジェクトの解釈を行えば、あるアプリケーションによる解釈が比較的に完備且つ正確で、あるアプリケーションによる解釈が不完備又は不正確であることが生じざるを得ないため、同一文書が異なるアプリケーションによって異なる効果で表示・印刷され、文書相互運用性面のユーザ体験に影響を及ぼす。文書ベースシステムでページビットマップを統一的に生成する方式によって、レイアウト一致性保持のキーポイントは、アプリケーションから文書ベースシステムに移行した。これにより、異なるアプリケーションで同一文書をオープンするとき、同様のレイアウト効果が出ることが可能になる。その原因の１つとして、各レイアウトオブジェクトを完全且つ正確に解釈して処理することが、統一的な基礎技術プラットフォームである文書ベースシステムにとっては可能であるが、アプリケーションにとってはあまり可能ではない。その他の原因として、表示・印刷効果の一致性をさらに確保できるように、異なるアプリケーションを同一文書ベースシステムと組合せて使用できる。簡単に言うと、アプリケーション間の一致性保持はあまり可能ではなく、文書ベースシステム間の一致性保持は可能で、同一文書ベースシステム内の一致性保持は更に問題がない。従って、異なるアプリケーション間で同一文書のレイアウト一致性を保持するため、関連責任をアプリケーションから文書ベースシステムに移行させることが必要となる。文書ベースシステムでページビットマップを統一的に生成するのが、そのうち１つの簡易な方法である。

さらに、ページの１つの領域のみを表示したりするように、ページビットマップの取得指令ではページの１つの領域を指定してもよい。例えば、ページがスクリーンより大きい場合、ページを全部表示する必要なく、ページをスクロールする場合も、スクロールされた領域を再描画するだけでよい。該指令では、特定の層からなるページビットマップの取得を指定すること、特に特定の層及び該層の全ての下位層からなるページビットマップの取得を指定することが許可される場合、履歴をよく表現でき、即ち最近の層を追加する前又はもっと以前のレイアウト効果を見ることができる。必要に応じて、どの層をビットマップの生成に使用するか、どの層を使用しないかを具体的に指定してもよい。

以下は「操作動作＋操作オブジェクト」の方式でインターフェース標準を実現する実施形態である。該実施形態において、インターフェースは、非構造化操作マークアップ言語（ＵＯＭＬ）と呼ばれ、拡張可能なマークアップ言語（ＸＭＬ）で記述する一連の命令である。上インターフェースユニットは、ＵＯＭＬフォーマットに適合する文字列を生成して、この文字列を下インターフェースユニットに送信することで、相応の操作指令を文書ベースシステムに送信する。文書ベースシステムがこれらの命令を実行した後、下インターフェースユニットは、実行結果に対してもＵＯＭＬフォーマットに適合する文字列を生成して、上インターフェースユニットに返信することで、アプリケーションに操作の実行結果を知らせる。

全ての実行結果はＵＯＭＬ＿ＲＥＴで表される。ＵＯＭＬ＿ＲＥＴは以下のように定義される。
属性
ＳＵＣＣＥＳＳ：値が真（ｔｒｕｅ）の場合は操作成功、それ以外の場合は操作失敗、を表す。
子要素
ＥＲＲ＿ＩＮＦＯ：選択可能なものであり、操作失敗の場合だけ出現し、相応のエラー情報を記述する。
他の子要素：具体的な命令によって決定され、各命令に対する説明を参照してよい。

ＵＯＭＬの動作は以下のものを含む。
１．ＵＯＭＬ＿ＯＰＥＮ（文書ベースの作成又はオープン）
１．１属性
１．１．１Ｃｒｅａｔｅ：ｔｒｕｅの場合は作成し、それ以外の場合は既存の文書ベースをオープンすることを表す。
１．２子要素
１．２．１Ｐａｔｈ：文書ベースのパス。それは、ディスクファイル名、ＵＲＬ、メモリポインタ、ネットワークパス、文書ベースのロジック名称、又は文書ベースを指定できる他の表現方式であってよい。
１．３戻り値
成功の場合、ハンドルを記録するための子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
２．ＵＯＭＬ＿ＣＬＯＳＥ（クローズ）
３．１属性：なし。
２．２子要素
２．２．１ｈａｎｄｌｅ：文字列で表される、オブジェクトへの引用ポインタであるオブジェクトハンドル。
２．２．２ｄｂ＿ｈａｎｄｌｅ：文字列で表される、文書ベースへの引用ポインタである文書ベースハンドル。
２．３戻り値：なし。
３．ＵＯＭＬ＿ＧＥＴ（取得）
３．１属性
ｕｓａｇｅ：用途であり、「ＧｅｔＨａｎｄｌｅ」（指定オブジェクトハンドル取得）、「ＧｅｔＯｂｊ」（指定オブジェクトデータ取得）、「ＧｅｔＰａｇｅＢｍｐ」（ページビットマップ取得）のうち１つ。
３．２子要素
３．２．１ｐａｒｅｎｔ：親オブジェクトハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合に使用する。
３．２．２ｐｏｓ：位置順番であり、ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合に使用する。
３．２．３ｈａｎｄｌｅ：指定オブジェクトのハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＯｂｊ」の場合に使用する。
３．２．４Ｐａｇｅ：表示必要なページのハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．２．５ｉｎｐｕｔ：入力ページに対する要求を記述し、例えば、１層又は複数層の内容の表示を指定でき（表示可能な層は必ず現在のロールにアクセス権限がある層である）、Ｃｌｉｐ領域の指定によって表示領域の大きさも指定できる。ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．２．６ｏｕｔｐｕｔ：ページビットマップの出力方式を記述し、ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．３戻り値
３．３．１ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合、実行成功のとき、ｐａｒｅｎｔの第ｐｏｓ個のサブオブジェクトのハンドルを記録するための子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
３．３．２ｕｓａｇｅ属性が「ＧｅｔＯｂｊ」の場合、実行成功のとき、ｈａｎｄｌｅオブジェクトデータのｘｍｌ表現を含む子要素「ｘｏｂｊ」をＵＯＭＬ＿ＲＥＴに追加する。
３．３．３ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合、実行成功のとき、子要素「ｏｕｔｐｕｔ」で指定された位置にページビットマップを出力する。
４．ＵＯＭＬ＿ＳＥＴ（設定）
４．１属性：なし。
４．２子要素
４．２．１Ｈａｎｄｌｅ：オブジェクトのハンドルを設定する。
４．２．２ｘｏｂｊ：オブジェクトの記述。
４．３戻り値：なし。
５．ＵＯＭＬ＿ＩＮＳＥＲＴ（挿入）
５．１属性：なし。
５．２子要素
５．２．１ｐａｒｅｎｔ：親オブジェクトハンドル。
５．２．２ｘｏｂｊ：オブジェクトの記述。
５．２．３ｐｏｓ：挿入位置。
５．３戻り値：実行成功の場合、パラメータ「ｘｏｂｊ」で表されるオブジェクトを、ｐａｒｅｎｔの第ｐｏｓ個のサブオブジェクトとしてｐａｒｅｎｔに挿入し、新たに挿入されたオブジェクトのハンドルを表す子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
６．ＵＯＭＬ＿ＤＥＬＥＴＥ（削除）
６．１属性：なし。
６．２子要素
６．２．１ｈａｎｄｌｅ：削除必要なオブジェクトのハンドル。
６．３戻り値：なし。
７．ＵＯＭＬ＿ＱＵＥＲＹ（検索問い合わせ）
７．１属性：なし。
７．２子要素
７．２．１ｈａｎｄｌｅ：問い合わせ必要な文書ベースハンドル。
７．２．２ｃｏｎｄｉｔｉｏｎ：問い合わせ条件。
７．３戻り値：成功の場合、問い合わせ結果のハンドルを表す子要素「ｈａｎｄｌｅ」、及び問い合わせ結果の数を表す子要素「ｎｕｍｂｅｒ」をＵＯＭＬ＿ＲＥＴに追加する。ＵＯＭＬ＿ＧＥＴで各問い合わせ結果を取得できる。

ＵＯＭＬオブジェクトは、
文書ベース（ＵＯＭＬ＿ＤＯＣＢＡＳＥ）、文書セット（ＵＯＭＬ＿ＤＯＣＳＥＴ）、文書（ＵＯＭＬ＿ＤＯＣ）、ページ（ＵＯＭＬ＿ＰＡＧＥ）、層（ＵＯＭＬ＿ＬＡＹＥＲ）、オブジェクトグループ（ＵＯＭＬ＿ＯＢＪＧＲＯＵＰ）、テキスト（ＵＯＭＬ＿ＴＥＸＴ）、画像（ＵＯＭＬ＿ＩＭＡＧＥ）、直線（ＵＯＭＬ＿ＬＩＮＥ）、曲線（ＵＯＭＬ＿ＢＥＩＺＥＲ）、円弧（ＵＯＭＬ＿ＡＲＣ）、パス（ＵＯＭＬ＿ＰＡＴＨ）、ソースファイル（ＵＯＭＬ＿ＳＲＣＦＩＬＥ）、背景色（ＵＯＭＬ＿ＢＡＣＫＣＯＬＯＲ）、前景色（ＵＯＭＬ＿ＣＯＬＯＲ）、ＲＯＰ（ＵＯＭＬ＿ＲＯＰ）、文字サイズ（ＵＯＭＬ＿ＣＨＡＲＳＩＺＥ）、及び書体（ＵＯＭＬ＿ＴＹＰＥＦＡＣＥ）を含む。

下記は一部のオブジェクトを例としてその定義方式を説明する。
１ＵＯＭＬ＿ＤＯＣ
１．１属性：なし
１．２子要素
１．２．１ｍｅｔａｄａｔａ：メタデータ
１．２．２ｐａｇｅｓｅｔ：各ページ
１．２．３ｆｏｎｔｉｎｆｏ：組み込みフォント
１．２．４ｎａｖｉｇａｔｉｏｎ：ナビゲーション情報
１．２．５ｔｈｒｅａｄ：スレッド情報
１．２．６ｍｉｎｉｐａｇｅ：サムネイルイメージ
１．２．７ｓｉｇｎｉｔｕｒｅ：デジタル署名
１．２．８ｌｏｇ：履歴
１．２．９ｓｈａｒｅｏｂｊ：文書共有オブジェクト
２ＵＯＭＬ＿ＰＡＧＥ
２．１属性
２．１．１ｒｅｓｏｌｕｔｉｏｎ：ロジック分解能
２．１．２ｓｉｚｅ：幅と高さで表される版面のサイズ
２．１．３ｒｏｔａｉｏｎ：回転角度
２．１．４ｌｏｇ：履歴
２．２子要素
２．２．１ＧＳ：初期図形ステータスであり、文字スタイル（ｃｈａｒｓｔｙｌｅ）、線スタイル（ｌｉｎｅｓｔｙｌｅ）、線の端のスタイル（ｌｉｎｅｃａｐ）、継ぎ目のスタイル（ｌｉｎｅｊｏｉｎｔ）、線幅（ｌｉｎｅｗｉｄｔｈ）、塗りつぶし規則（ｆｉｌｌｒｕｌｅ）、文字間隔（ｃｈａｒｓｐａｃｅ）、行間隔（ｌｉｎｅｓｐａｃｅ）、文字回転角度（ｃｈａｒｒｏａｔｅ）、文字傾斜方向（ｃｈａｒｓｌａｎｔ）、文字の太さ（ｃｈａｒｗｅｉｇｈｔ）、文字方向（ｃｈａｒｄｉｒｅｃｔ）、テキスト方向（ｔｅｘｔｄｉｒｅｃｔ）、陰影幅（ｓｈａｄｏｗｗｉｄｔｈ）、陰影方向（ｓｈａｄｏｗｄｉｒｅｃｔ）、陰影の枠線の幅（ｓｈａｄｏｗｂｏｄｅｒｗｉｄｔｈ）、輪郭線の幅（ｏｕｔｌｉｎｅｗｉｄｔｈ）、輪郭の枠線の幅（ｏｕｔｌｉｎｅｂｏｄｅｒｗｉｄｔｈ）、線色（ｌｉｎｅｃｏｌｏｒ）、塗りつぶし色（ｆｉｌｌｃｏｌｏｒ）、背景色（ｂａｃｋｃｏｌｏｒ）、文字色（ｔｅｘｔｃｏｌｏｒ）、陰影色（ｓｈａｄｏｗｃｏｌｏｒ）、輪郭線色（ｏｕｔｌｉｎｅｃｏｌｏｒ）、変換行列（ｍａｔｒｉｘ）、クリップ領域（ｃｌｉｐａｒｅａ）を含む。
２．２．２ｍｅｔａｄａｔａ：メタデータ
２．２．３ｌａｙｅｒｓｅｔ：該ページに属する各層
２．２．４ｓｉｇｎｉｔｕｒｅ：デジタル署名
２．２．５ｌｏｇ：履歴
３ＵＯＭＬ＿ＴＥＸＴ
３．１属性
３．１．１Ｅｎｃｏｄｉｎｇ：テキスト符号化方式
３．２子要素
３．２．１ＴｅｘｔＤａｔａ：テキスト内容。
３．２．２ＣｈａｒＳｐａｃｉｎｇＬｉｓｔ：非等間隔の場合の文字間隔リスト。
３．２．３ＳｔａｒｔＰｏｓ：開始位置。
４ＵＯＭＬ＿ＣＨＡＲＳＩＺＥ
４．１属性
４．１．１ｗｉｄｔｈ：文字幅
４．１．２ｈｅｉｇｈｔ：文字高さ
４．２子要素：なし
５ＵＯＭＬ＿ＬＩＮＥ
５．１属性
５．１．１ＬｉｎｅＳｔｙｌｅ：線スタイル
５．１．２ＬｉｎｅＣａｐ：線の端のスタイル
５．２子要素
５．２．１ＳｔａｒｔＰｏｉｎｔ：線の起点座標
５．２．２ＥｎｄＰｏｉｎｔ：線の終点座標
６ＵＯＭＬ＿ＢＥＩＺＥＲ
６．１属性
６．１．１ＬｉｎｅＳｔｙｌｅ：線スタイル
６．２子要素
６．２．１ＳｔａｒｔＰｏｉｎｔ：ベジェ曲線の起点座標
６．２．２Ｃｏｎｔｒｏｌ１＿Ｐｏｉｎｔ：ベジェ曲線の第１制御点
６．２．３Ｃｏｎｔｒｏｌ２＿Ｐｏｉｎｔ：ベジェ曲線の第２制御点
６．２．４ＥｎｄＰｏｉｎｔ：ベジェ曲線の終点座標
７ＵＯＭＬ＿ＡＲＣ
７．１属性
７．１．１ＣｌｏｃｋＷｉｓｅ：弧の方向
７．２子要素
７．２．１ＳｔａｒｔＰｏｉｎｔ：弧の起点座標
７．２．２ＥｎｄＰｏｉｎｔ：弧の終点座標
７．２．３Ｃｅｎｔｅｒ：弧の円心座標
８ＵＯＭＬ＿ＣＯＬＯＲ
８．１属性
８．１．１Ｔｙｐｅ：色の類型、ＲＧＢ又はＣＭＹＫ
８．２子要素
ＲＧＢモード
８．２．１Ｒｅｄ：赤色
８．２．２Ｇｒｅｅｎ：緑色
８．２．３Ｂｌｕｅ：青色
８．２．４Ａｌｐｈａ：透明度
ＣＭＹＫモード
８．２．５Ｃｙａｎ：青緑色
８．２．６Ｍａｇｅｎｔａ：赤紫色
８．２．７Ｙｅｌｌｏｗ：黄色
８．２．８Ｂｌａｃｋ＿ｉｎｋ：黒色

上記に準じて類推すると、同様の方法で全てのＵＯＭＬオブジェクトを記述できる。アプリケーションにより文書ベースを操作する場合、上記ＵＯＭＬ動作及びＵＯＭＬオブジェクトによりＸＭＬシンタックスに従って相応のＵＯＭＬ命令を生成し、このＵＯＭＬ命令を文書ベースシステムに送信し、即ちアプリケーションが文書ベースシステムに操作指令を送信することを表す。

例えば、文書ベースの作成操作について、以下の命令で完成できる。
＜ＵＯＭＬ＿ＯＰＥＮｃｒｅａｔｅ＝ｔｒｕｅ＞
＜ｐａｔｈｖａｌ＝ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ／＞
＜／ＵＯＭＬ＿ＯＰＥＮ＞

文書セットの作成操作について、以下の命令で完成できる。
＜ＵＯＭＬ＿ＩＮＳＥＲＴ＞
＜ｐａｒｅｎｔｖａｌ＝１２３．４５６．７８９／＞
＜ｐｏｓｖａｌ＝１／＞
＜ｘｏｂｊ＞
＜ｄｏｃｓｅｔ／＞
＜／ｘｏｂｊ＞
＜／ＵＯＭＬ＿ＩＮＳＥＲＴ＞

説明すべきものとして、ＵＯＭＬがＸＭＬで定義されるものであるが、さらに簡潔そうに見えるために、「＜？ｘｍｌｖｅｒｓｉｏｎ＝１．０ｅｎｃｏｄｉｎｇ＝ＵＴＦ−８？＞」、及び「ｘｍｌｎｓ：ｘｓｉ＝ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ」のような通常のＸＭＬフォーマットが先頭に省略されており、ＸＭＬシンタックスに詳しい実施者であれば、自らそれを補完できる。

ＸＭＬ以外の方式で命令列を定義してもよい。例えば、ＰｏｓｔＳｃｒｉｐｔのような方式を用いて、上記の例が以下のように変化する。
１，ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ，／Ｏｐｅｎ
／ｄｏｃｓｅｔ，１， “１２３．４５６．７８９” ，／Ｉｎｓｅｒｔ

同様の考え方によって、他の類型の命令列のフォーマットを定義でき、テキスト方式ではなく、２値化方式で命令列を定義することまでもできる。

「動作＋オブジェクト」の方式以外に、他の方式で命令列を定義してもよい。例えば、各オブジェクトの各操作ごとに１つの命令で表し、即ち、「ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ」で文書セットの挿入を表し、「ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＰＡＧＥ」でページの挿入を表し、下記のような方式で各命令を定義する。
ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ：文書ベースに文書セットの作成を指示
属性：なし
子要素：
ｐａｒｅｎｔ：文書ベースハンドル
ｐｏｓ：挿入位置
戻り値：実行成功の場合、新たに挿入された文書セットのハンドルを表す子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。

このように、上記の命令が以下のフォーマットに変化する。
＜ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ＞
＜ｐａｒｅｎｔｖａｌ＝１２３．４５６．７８９／＞
＜ｐｏｓｖａｌ＝１／＞
＜／ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ＞

このような方法で命令フォーマットを定義するには、各オブジェクトの正当な各操作ごとにそれぞれ１つの命令を定義する必要があるため、煩雑である。

また、関数呼び出しの方式でインターフェース標準を実現するようにしてよい。即ち、上インターフェースから下インターフェースのインターフェース関数を呼び出す方式で、操作指令を文書ベースシステムに送信する。以下、非構造化操作インターフェース（ＵＯＩ）と呼ばれるインターフェースの実施形態について、Ｃ＋＋言語を例として説明する。

１．ＵＯＩ戻り値の構造を定義する。
ｓｔｒｕｃｔＵＯＩ＿Ｒｅｔ｛
ＢＯＯＬｍ＿ｂＳｕｃｃｅｓｓ；／／操作成功又は失敗
ＣＳｔｒｉｎｇｍ＿ＥｒｒＩｎｆｏ；／／操作失敗の場合、エラー情報を示す
｝；
そして、全てのＵＯＩオブジェクトの基本クラスを定義する。
ｃｌａｓｓＵＯＩ＿Ｏｂｊｅｃｔ｛
ｐｕｂｌｉｃ：
ｅｎｕｍＴｙｐｅ｛
ＴＹＰＥ＿ＤＯＣＢＡＳＥ，
ＴＹＰＥ＿ＤＯＣＳＥＴ，
ＴＹＰＥ＿ＤＯＣ，
ＴＹＰＥ＿ＰＡＧＥ，
ＴＹＰＥ＿ＬＡＹＥＲ，
ＴＹＰＥ＿ＴＥＸＴ，
ＴＹＰＥ＿ＣＨＡＲＳＩＺＥ，
……汎用文書モデルに定義された他のオブジェクトの類型の定義が上記と類似するため、以下は省略する。
｝；
Ｔｙｐｅｍ＿Ｔｙｐｅ；
ＵＯＩ＿Ｏｂｊｅｃｔ（）；
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｏｂｊｅｃｔ（）；
ｓｔａｔｉｃＵＯＩ＿Ｏｂｊｅｃｔ＊Ｃｒｅａｔｅ（ＴｙｐｅｏｂｊＴｙｐｅ）；／／指定類型に基づいて相応のオブジェクトを作成する
｝；

２．第１実施形態におけるいくつかのＵＯＭＬ動作に対応して、下記のいくつかのＵＯＩ関数を定義する。

文書ベースをオープン又は作成し、成功の場合、そのハンドルをｐＨａｎｄｌｅに戻す：
ＵＯＩ＿ＲＥＴＵＯＩ＿Ｏｐｅｎ（ｃｈａｒ＊ｐａｔｈ，ＢＯＯＬｂＣｒｅａｔｅ，ＨＡＮＤＬＥ＊ｐＨａｎｄｌｅ）；
ｄｂ＿ｈａｎｄｌｅ文書ベースのｈａｎｄｌｅハンドルをクローズし、ｈａｎｄｌｅがＮＵＬＬである場合、文書ベース全体をクローズする：
ＵＯＩ＿ＲＥＴＵＯＩ＿Ｃｌｏｓｅ（ＨＡＮＤＬＥｈａｎｄｌｅ，ＨＡＮＤＬＥｄｂ＿ｈａｎｄｌｅ）；
指定のサブオブジェクトのハンドルを取得する：
ＵＯＩ＿ＲＥＴＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ＨＡＮＤＬＥｈＰａｒｅｎｔ，ｉｎｔｎＰｏｓ，ＨＡＮＤＬＥ＊ｐＨａｎｄｌｅ）；
ハンドルに関連付けられたオブジェクトの類型を取得する：
ＵＯＩ＿ＲＥＴＵＯＩ＿ＧｅｔＯｂｊＴｙｐｅ（ＨＡＮＤＬＥｈａｎｄｌｅ，ＵＯＩ＿Ｏｂｊｅｃｔ：：Ｔｙｐｅ＊ｐＴｙｐｅ）；
ハンドルに関連付けられたオブジェクトのデータを取得する：
ＵＯＩ＿ＲＥＴＵＯＩ＿ＧｅｔＯｂｊ（ＨＡＮＤＬＥｈａｎｄｌｅ，ＵＯＩ＿Ｏｂｊｅｃｔ＊ｐＯｂｊ）；
ページビットマップを取得する：
ＵＯＩ＿ＲＥＴＵＯＩ＿ＧｅｔＰａｇｅＢｍｐ（ＨＡＮＤＬＥｈＰａｇｅ，ＲＥＣＴｒｅｃｔ，ｖｏｉｄ＊ｐＢｕｆ）；
オブジェクトを設定する：
ＵＯＩ＿ＲＥＴＵＯＩ＿ＳｅｔＯｂｊ（ＨＡＮＤＬＥｈａｎｄｌｅ，ＵＯＩ＿Ｏｂｊｅｃｔ＊ｐＯｂｊ）；
オブジェクトを挿入する：
ＵＯＩ＿ＲＥＴＵＯＩ＿Ｉｎｓｅｒｔ（ＨＡＮＤＬＥｈＰａｒｅｎｔ，ｉｎｔｎＰｏｓ，ＵＯＩ＿Ｏｂｊｅｃｔ＊ｐＯｂｊ，ＨＡＮＤＬＥ＊ｐＨａｎｄｌｅ＝ＮＵＬＬ）；
オブジェクトを削除する：
ＵＯＩ＿ＲＥＴＵＯＩ＿Ｄｅｌｅｔｅ（ＨＡＮＤＬＥｈａｎｄｌｅ）；
検索問い合わせし、検索結果の数をｐＲｅｓｕｌｔＣｏｕｎｔで、検索結果リストのハンドルをｐｈＲｅｓｕｌｔに戻す：
ＵＯＩ＿ＲＥＴＵＯＩ＿Ｑｕｅｒｙ（ＨＡＮＤＬＥｈＤｏｃｂａｓｅ，ｃｏｎｓｔｃｈａｒ＊ｓｔｒＣｏｎｄｉｔｉｏｎ，ＨＡＮＤＬＥ＊ｐｈＲｅｓｕｌｔ，ｉｎｔ＊ｐＲｅｓｕｌｔＣｏｕｎｔ）；

３．各ＵＯＩオブジェクトを定義する。依然としてＵＯＩ＿Ｄｏｃ、ＵＯＩ＿Ｔｅｘｔ及びＵＯＭＬ＿ＣｈａｒＳｉｚｅを例として説明する。
ｃｌａｓｓＵＯＩ＿Ｄｏｃ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊｅｃｔ｛
ｐｕｂｌｉｃ：
ＵＯＩ＿ＭｅｔａＤａｔａｍ＿ＭｅｔａＤａｔａ；
ｉｎｔｍ＿ｎＰａｇｅｓ；
ＵＯＩ＿Ｐａｇｅ＊＊ｍ＿ｐＰａｇｅｓ；
ｉｎｔｍ＿ｎＦｏｎｔｓ；
ＵＯＩ＿Ｆｏｎｔ＊＊ｍ＿ｐＦｏｎｔｓ；
ＵＯＩ＿Ｎａｖｉｇａｔｉｏｎｍ＿Ｎａｖｉｇａｔｉｏｎ；
ＵＯＩ＿Ｔｈｒｅａｄｍ＿Ｔｈｒｅａｄ；
ＵＯＩ＿ＭｉｎｉＰａｇｅ＊ｍ＿ｐＭｉｎｉＰａｇｅｓ；
ＵＯＩ＿Ｓｉｇｎａｔｕｒｅｍ＿Ｓｉｇｎａｔｕｒｅ；
ｉｎｔｍ＿ｎＳｈａｒｅｄ；
ＵＯＩ＿Ｏｂｊ＊ｍ＿ｐＳｈａｒｅｄ；

ＵＯＩ＿Ｄｏｃ（）；
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｄｏｃ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｔｅｘｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊｅｃｔ｛
ｐｕｂｌｉｃ：
ｅｎｕｍＥｎｃｏｄｉｎｇ｛
ＥＮＣＯＤＥ＿ＡＳＣＩＩ，
ＥＮＣＯＤＥ＿ＧＢ１３０００，
ＥＮＣＯＤＥ＿ＵＮＩＣＯＤＥ，
．．．．．．
｝；
Ｅｎｃｏｄｉｎｇｍ＿Ｅｎｃｏｄｉｎｇ；
ｃｈａｒ＊ｍ＿ｐＴｅｘｔ；
Ｐｏｉｎｔｍ＿Ｓｔａｒｔ；
ｉｎｔ＊ｍ＿ＣｈａｒＳｐａｃｅ；

ＵＯＩ＿Ｔｅｘｔ（）；
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｔｅｘｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＣｈａｒＳｉｚｅ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊｅｃｔ｛
ｐｕｂｌｉｃ：
ｉｎｔｍ＿Ｗｉｄｔｈ；
ｉｎｔｍ＿Ｈｅｉｇｈｔ；

ＵＯＩ＿ＣｈａｒＳｉｚｅ（）；
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＣｈａｒＳｉｚｅ（）；
｝；

以下、例を挙げてＵＯＩの使用方法を説明する。まず、文書ベースを作成する。
ｒｅｔ＝ＵＯＩ＿Ｏｐｅｎ（ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ，ＴＲＵＥ，＆ｈＤｏｃＢａｓｅ）；

４．新たなオブジェクトを作成するための関数を構築する。
ＨＡＮＤＬＥＩｎｓｅｒｔＮｅｗＯｂｊ（ＨＡＮＤＬＥｈＰａｒｅｎｔ，ｉｎｔｎＰｏｓ，ＵＯＩ＿Ｏｂｊｅｃｔ：：Ｔｙｐｅｔｙｐｅ）
｛
ＵＯＩ＿Ｒｅｔｒｅｔ；
ＨＡＤＮＬＥｈａｎｄｌｅ；
ＵＯＩ＿Ｏｂｊ＊ｐＮｅｗＯｂｊ＝ＵＯＩ＿Ｏｂｊ：：Ｃｒｅａｔｅ（ｔｙｐｅ）；
ｉｆ（ｐＮｅｗＯｂｊ＝＝ＮＵＬＬ）
ｒｅｔｕｒｎＮＵＬＬ；
ｒｅｔ＝ＵＯＩ＿Ｉｎｓｅｒｔ（ｈＰａｒｅｎｔ，ｎＰｏｓ，ｐＮｅｗＯｂｊ，＆ｈａｎｄｌｅ）；
ｄｅｌｅｔｅｐＮｅｗＯｂｊ；
ｒｅｔｕｒｎｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ？ｈａｎｄｌｅ：ＮＵＬＬ；
｝

５．オブジェクトを直接に取得するための関数を構築する。
ＵＯＩ＿Ｏｂｊ＊ＧｅｔＯｂｊ（ＨＡＮＤＬＥｈａｎｄｌｅ）
｛
ＵＯＩ＿Ｒｅｔｒｅｔ；
ＵＯＩ＿Ｏｂｊｅｃｔ：：Ｔｙｐｅｔｙｐｅ；
ＵＯＩ＿Ｏｂｊ＊ｐＯｂｊ；
ｒｅｔ＝ＵＯＩ＿ＧｅｔＯｂｊＴｙｐｅ（ｈａｎｄｌｅ，＆ｔｙｐｅ）；
ｉｆ（！ｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ）
ｒｅｔｕｒｎＮＵＬＬ；
ｐＯｂｊ＝ＵＯＩ＿Ｏｂｊ：：Ｃｒｅａｔｅ（ｔｙｐｅ）；
ｉｆ（ｐＯｂｊ＝＝ＮＵＬＬ）
ｒｅｔｕｒｎＮＵＬＬ；
ｒｅｔ＝ＵＯＩ＿ＧｅｔＯｂｊ（ｈａｎｄｌｅ，ｐＯｂｊ）；
ｉｆ（！ｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ）｛
ｄｅｌｅｔｅｐＯｂｊ；
ｒｅｔｕｒｎＮＵＬＬ；
｝
ｒｅｔｕｒｎｐＯｂｊ；
｝

また、「動作＋オブジェクト」以外の関数方式でインターフェース標準を定義するようにしてもよい。例えば、各オブジェクトの各種の操作ごとに１つのインターフェース関数を定義すると、文書セット挿入の操作指令は、上インターフェースから下記の方式で下インターフェースのインターフェース関数を呼び出すことによって、文書ベースシステムに送信される。
ＵＯＩ＿ＩｎｓｅｒｔＤｏｃｓｅｔ（ｐＤｏｃｂａｓｅ，０）；

また、各オブジェクトクラス（例えば文書ベースクラス）をカプセル化して、該オブジェクトの実行可能な操作を該クラスのメソッドとして定義するようにしてもよい。例えば、
ｃｌａｓｓＵＯＩ＿ＤｏｃＢａｓｅ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／＊！
＊ \ｂｒｉｅｆ文書ベースの作成
＊ \ｐａｒａｍｓｚＰａｔｈ：文書ベースのフルパス
＊ \ｐａｒａｍｂＯｖｅｒｒｉｄｅ：元のファイルをオーバーライトするかどうか
＊ \ｒｅｔｕｒｎＵＯＩ＿ＤｏｃＢａｓｅオブジェクト
＊／
ＢＯＯＬＣｒｅａｔｅ（ｃｏｎｓｔｃｈａｒ＊ｓｚＰａｔｈ，ｂｏｏｌｂＯｖｅｒｒｉｄｅ＝ｆａｌｓｅ）；
／＊！
＊ \ｂｒｉｅｆ文書ベースのオープン
＊ \ｐａｒａｍｓｚＰａｔｈ：文書ベースのフルパス
＊ \ｒｅｔｕｒｎＵＯＩ＿ＤｏｃＢａｓｅオブジェクト
＊／
ＢＯＯＬＯｐｅｎ（ｃｏｎｓｔｃｈａｒ＊ｓｚＰａｔｈ）；
／＊！
＊ \ｂｒｉｅｆ文書ベースのクローズ
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎなし
＊／
ｖｏｉｄＣｌｏｓｅ（）；
／＊！
＊ \ｂｒｉｅｆロールリストの取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎＵＯＩ＿ＲｏｌｅＬｉｓｔオブジェクト
＊ \ｓａＵＯＩ＿ＲｏｌｅＬｉｓｔ
＊／
ＵＯＩ＿ＲｏｌｅＬｉｓｔＧｅｔＲｏｌｅＬｉｓｔ（）；
／＊！
＊ \ｂｒｉｅｆ文書ベースの記憶
＊ \ｐａｒａｍｓｚＰａｔｈ：記憶しようとする文書ベースのフルパス
＊ \ｒｅｔｕｒｎなし
＊／
ｖｏｉｄＳａｖｅ（ｃｈａｒ＊ｓｚＰａｔｈ＝０）；

／＊！
＊ \ｂｒｉｅｆ文書セットの挿入
＊ \ｐａｒａｍｎＰｏｓ：文書セットの挿入位置
＊ \ｒｅｔｕｒｎＵＯＩ＿ＤｏｃＳｅｔオブジェクト
＊ \ｓａＵＯＩ＿ＤｏｃＳｅｔ
＊／
ＵＯＩ＿ＤｏｃＳｅｔＩｎｓｅｒｔＤｏｃＳｅｔ（ｉｎｔｎＰｏｓ）；
／＊！
＊ \ｂｒｉｅｆ指定インデックスの文書セットの取得
＊ \ｐａｒａｍｎＩｎｄｅｘ：文書リストのインデックス番号
＊ \ｒｅｔｕｒｎＵＯＩ＿ＤｏｃＳｅｔオブジェクト
＊ \ｓａＵＯＩ＿ＤｏｃＳｅｔ
＊／
ＵＯＩ＿ＤｏｃＳｅｔＧｅｔＤｏｃＳｅｔ（ｉｎｔｎＩｎｄｅｘ）；
／＊！
＊ \ｂｒｉｅｆ文書セットの総数の取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎ文書セットの数
＊／
ｉｎｔＧｅｔＤｏｃＳｅｔＣｏｕｎｔ（）；
／＊！
＊ \ｂｒｉｅｆ文書ベース名称の設定
＊ \ｐａｒａｍｎＬｅｎ：文書ベース名称の長さ
＊ \ｐａｒａｍｓｚＮａｍｅ：文書ベース名称
＊ \ｒｅｔｕｒｎなし
＊／
ｖｏｉｄＳｅｔＮａｍｅ（ｉｎｔｎＬｅｎ，ｃｏｎｓｔｃｈａｒ＊ｓｚＮａｍｅ）；
／＊！
＊ \ｂｒｉｅｆ文書ベース名称の長さの取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎ長さ
＊／
ｉｎｔＧｅｔＮａｍｅＬｅｎ（）；
／＊！
＊ \ｂｒｉｅｆ文書ベース名称の取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎ文書ベース名称
＊／
ｃｏｎｓｔｃｈａｒ＊ＧｅｔＮａｍｅ（）；
／＊！
＊ \ｂｒｉｅｆ文書ベースｉｄの長さの取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎ長さ
＊／
ｉｎｔＧｅｔＩＤＬｅｎ（）；
／＊！
＊ \ｂｒｉｅｆ文書ベースｉｄの取得
＊ \ｐａｒａｍなし
＊ \ｒｅｔｕｒｎｉｄ
＊／
ｃｏｎｓｔｃｈａｒ＊ＧｅｔＩＤ（）；

／／！コンストラクタ関数
ＵＯＩ＿ＤｏｃＢａｓｅ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＤｏｃＢａｓｅ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｔｅｘｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿Ｔｅｘｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｔｅｘｔ（）；
／／！テキストの符号化方式の列挙型を表す
ｅｎｕｍＵＯＩ＿ＴｅｘｔＥｎｃｏｄｉｎｇ
｛
ＣＨＡＲＳＥＴ＿ＡＳＣＩＩ，
ＣＨＡＲＳＥＴ＿ＧＢ１３０００，
ＣＨＡＲＳＥＴ＿ＵＮＩＣＯＤＥ，
｝；

／／！テキストの符号化方式の取得
ＵＯＩ＿ＴｅｘｔＥｎｃｏｄｉｎｇＧｅｔＥｎｃｏｄｉｎｇ（）；
／／！テキストの符号化方式の設定
ｖｏｉｄＳｅｔＥｎｃｏｄｉｎｇ（ＵＯＩ＿ＴｅｘｔＥｎｃｏｄｉｎｇｎＥｎｃｏｄｉｎｇ）；
／／！テキストのデータの取得
ｃｏｎｓｔｃｈａｒ＊ＧｅｔＴｅｘｔＤａｔａ（）；
／／！テキストのデータ長さの取得
ｉｎｔＧｅｔＴｅｘｔＤａｔａＬｅｎ（）；
／／！テキストのデータの設定
／＊！
\ｐａｒａｍｐＤａｔａテキストデータ
\ｐａｒａｍｎＬｅｎデータ長さ
＊／
ｖｏｉｄＳｅｔＴｅｘｔＤａｔａ（ｃｏｎｓｔｃｈａｒ＊ｐＤａｔａ，ｉｎｔｎＬｅｎ）；
／／！起点位置の取得
ＰｏｉｎｔＧｅｔＳｔａｒｔＰｏｉｎｔ（）；
／／！起点位置の設定
ｖｏｉｄＳｅｔＳｔａｒｔＰｏｉｎｔ（ＰｏｉｎｔｓｔａｒｔＰｏｉｎｔ）；
／／！文字間隔リストの大きさの取得
ｉｎｔＧｅｔＣｈａｒＳｐａｃｉｎｇＣｏｕｎｔ（）；
／／！文字間隔リスト内の指定位置の文字間隔の取得
ｆｌｏａｔＧｅｔＣｈａｒＳｐａｃｉｎｇ（ｉｎｔｎＩｎｄｅｘ）；
／／！文字間隔リストの大きさの設定
ｂｏｏｌＳｅｔＣｈａｒＳｐａｃｉｎｇＣｏｕｎｔ（ｉｎｔｎＬｅｎ）；
／／！文字間隔の設定
ｂｏｏｌＳｅｔＣｈａｒＳｐａｃｉｎｇ（ｉｎｔｎＩｎｄｅｘ，ｆｌｏａｔｃｈａｒＳｐａｃｅ）；
／／！テキストの外枠の取得
ＵＯＩ＿ＲｅｃｔＧｅｔＥｘｔｅｎｔＡｒｅａ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＲｏｌｅＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！リスト内のロール数の取得
ｉｎｔＧｅｔＲｏｌｅＣｏｕｎｔ（）；
／／！指定インデックスに従って、ロールを取得する
ＵＯＩ＿Ｒｏｌｅ＊ＧｅｔＲｏｌｅ（ｉｎｔｎＩｎｄｅｘ）；
／／！ロールの作成
／＊！
\ｐａｒａｍｐＰｒｉｖＫｅｙ秘密鍵のバッファー
\ｐａｒａｍｐｎＫｅｙＬｅｎ戻される実際の秘密鍵の長さ
\ｒｅｔｕｒｎ新規作成のロール
＊／
ＵＯＩ＿ＲｏｌｅＡｄｄＲｏｌｅ（ｕｎｓｉｇｎｅｄｃｈａｒ＊ｐＰｒｉｖＫｅｙ，ｉｎｔ＊ｐｎＫｅｙＬｅｎ）；
／／！コンストラクタ関数
ＵＯＩ＿ＲｏｌｅＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＲｏｌｅＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｒｏｌｅ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿Ｒｏｌｅ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｒｏｌｅ（）；

／／！ロールＩＤの取得
ｉｎｔＧｅｔＲｏｌｅＩＤ（）；
／／！ロールＩＤの設定
／＊！
\ｐａｒａｍｎＩＤロールＩＤ
＊／
ｖｏｉｄＳｅｔＲｏｌｅＩＤ（ｉｎｔｎＩＤ）；
／／！ロール名称の取得
ｃｏｎｓｔｃｈａｒ＊ＧｅｔＲｏｌｅＮａｍｅ（）；
／／！ロール名称の設定
／＊！
\ｐａｒａｍｓｚＮａｍｅロール名称
＊／
ｖｏｉｄＳｅｔＲｏｌｅＮａｍｅ（ｃｏｎｓｔｃｈａｒ＊ｓｚＮａｍｅ）；
｝；

ｃｌａｓｓＵＯＩ＿ＰｒｉｖＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ／／権限リスト
｛
ｐｕｂｌｉｃ：
／／！指定ロールに対応する権限の取得
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ＧｅｔＲｏｌｅＰｒｉｖ（ＵＯＩ＿Ｒｏｌｅ＊ｐＲｏｌｅ）；
／／！あるロールの権限項目の新規作成
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ｐＰｒｉｖＡｄｄＲｏｌｅ（）；
／／！リスト内のロールの権限項目数の取得
ｉｎｔＧｅｔＲｏｌｅＰｒｉｖＣｏｕｎｔ（）；
／／！インデックス値に従って、ロールの権限項目を取得する
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ＧｅｔＲｏｌｅＰｒｉｖ（ｉｎｔｎＩｎｄｅｘ）；
／／！コンストラクタ関数
ＵＯＩ＿ＰｒｉｖＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＰｒｉｖＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＲｏｌｅＰｒｉｖ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ／／あるロールの全ての権限に対応する
｛
ｐｕｂｌｉｃ：
／／！ロールの取得
ＵＯＩ＿Ｒｏｌｅ＊ＧｅｔＲｏｌｅ（）；
／／！あるオブジェクトに対する権限を設定する。権限が該ロールの該オブジェクトに対する現在の権限を越える場合、権限付与になり、権限が該ロールの該オブジェクトに対する現在の権限より小さい場合、権限解除になる。現在ログインしたロールは相応の権限再付与又は権限解除の権限を持たなければならない。
ｂｏｏｌＳｅｔＰｒｉｖ（ＵＯＩ＿Ｏｂｊ＊ｐＯｂｊ，ＵＯＩ＿Ｐｒｉｖ＊ｐＰｒｉｖ）；
／／！設定された権限の数の取得
ｉｎｔＧｅｔＰｒｉｖＣｏｕｎｔ（）；
／／！インデックス値に対応する権限が設定されたオブジェクトの取得
ＵＯＩ＿Ｏｂｊ＊ＧｅｔＯｂｊ（ｉｎｔｎＩｎｄｅｘ）；
／／！インデックス値に対応する権限で設定された権限の取得
ＵＯＩ＿Ｐｒｉｖ＊ＧｅｔＰｒｉｖ（ｉｎｔｎＩｎｄｅｘ）；
／／！あるオブジェクトに対応する権限の取得
ＵＯＩ＿Ｐｒｉｖ＊ＧｅｔＰｒｉｖ（ＵＯＩ＿Ｏｂｊ＊ｐＯｂｊ）；
／／！コンストラクタ関数
ＵＯＩ＿ＲｏｌｅＰｒｉｖ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＲｏｌｅＰｒｉｖ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｐｒｉｖ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
ｅｎｕｍＰｒｉｖＴｙｐｅ｛／／各権限類型の定義
ＰＲＩＶ＿ＲＥＡＤ，／／リード権限
ＰＲＩＶ＿ＷＲＩＴＥ，／／ライト権限
ＰＲＩＶ＿ＲＥＬＩＣＥＮＳＥ，／／権限再付与の権限
ＰＲＩＶ＿ＢＥＲＥＡＶＥ，／／権限解除の権限
ＰＲＩＶ＿ＰＲＩＮＴ，／／印刷権限
他の権限の定義
｝
／／！相応の権限の有無
ｂｏｏｌＧｅｔＰｒｉｖ（ＰｒｉｖＴｙｐｅｐｒｉｖＴｙｐｅ）；
／／！相応の権限の設定
ｖｏｉｄＳｅｔＰｒｉｖ（ＰｒｉｖＴｙｐｅｐｒｉｖＴｙｐｅ，ｂｏｏｌｂＰｒｉｖ）；
／／！コンストラクタ関数
ＵＯＩ＿Ｐｒｉｖ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｐｒｉｖ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＳｉｇｎＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿ＳｉｇｎＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＳｉｇｎＬｉｓｔ（）；

／／！新たなノード署名を追加し、そのインデックス値を戻す
ｉｎｔＡｄｄＳｉｇｎ（ＵＯＩ＿Ｓｉｇｎ＊ｐＳｉｇｎ）；
／／！指定のインデックス値に従って、ノード署名を取得する
ＵＯＩ＿ＳｉｇｎＧｅｔＳｉｇｎ（ｉｎｔｉｎｄｅｘ）；
／／！指定のインデックス値に従って、ノード署名を削除する
ｖｏｉｄＤｅｌＳｉｇｎ（ｉｎｔｉｎｄｅｘ）；
／／！リスト内のノード署名の数の取得
ｉｎｔＧｅｔＳｉｇｎＣｏｕｎｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｓｉｇｎ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿Ｓｉｇｎ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｓｉｇｎ（）；

／／！署名の実行
／＊！
\ｐａｒａｍｐＤｅｐＬｉｓｔ署名の依存リスト
\ｐａｒａｍｐＲｏｌｅ署名するロール
\ｐａｒａｍｐＯｂｊ署名されるオブジェクト
＊／
ｖｏｉｄＳｉｇｎ（ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔｐＤｅｐＬｉｓｔ，ＵＯＩ＿ＲｏｌｅｐＲｏｌｅ，ＵＯＩ＿ＯｂｊｐＯｂｊ）；
／／！署名の検証
ｂｏｏｌＶｅｒｉｆｙ（）；
／／！署名の依存リストの取得
ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔＧｅｔＤｅｐＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ（）；

／／！依存項目の追加
ｖｏｉｄＩｎｓｅｒｔＳｉｇｎＤｅｐ（ＵＯＩ＿Ｓｉｇｎ＊ｐＳｉｇｎ）；
／／！依存項目数の取得
ｉｎｔＧｅｔＤｅｐＳｉｇｎＣｏｕｎｔ（）；
／／！指定のインデックス値に従って、依存項目を取得する
ＵＯＩ＿Ｓｉｇｎ＊ＧｅｔＤｅｐＳｉｇｎ（ｉｎｔｎＩｎｄｅｘ）；
｝；

このように、文書セット挿入の操作指令は、上インターフェースから下記の方式で下インターフェースのインターフェース関数を呼び出すことによって、文書ベースシステムに送信される。
ｐＤｏｃＢａｓｅ．ＩｎｓｅｒｔＤｏｃｓｅｔ（０）；

同様の方法によっては、Ｊａｖａ（登録商標）、Ｃ＃、ＶＢ、Ｄｅｌｐｈｉなどの各種のプログラミング言語で開発されたアプリケーションに対して、異種類のインターフェース標準を設計するようにしてもよい。

インターフェース標準には、特定のオペレーションシステム（例えばＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）／ＬＩＮＵＸ（登録商標）、ＭＡＣ（登録商標）ＯＳ、ＳＹＭＢＩＡＮ（登録商標））又は特定のハードウェアプラットフォーム（例えばｘ８６ＣＰＵ、ＭＩＰＳ、ＰＯＷＥＲＰＣなど）に関連する特徴が含まれなければ、このインターフェース標準がクロスプラットフォーム性を備え、異なるプラットフォームで運行しているアプリケーション及び文書ベースシステムは、同様のインターフェース標準を統一的に使用できるようになって、特にあるプラットフォームで運行しているアプリケーションから、他のプラットフォームで運行している文書ベースシステムを呼び出して、相応の操作を実行できるようになる。例えば、アプリケーションは、ＰＣ及びＷｉｎｄｏｗｓオペレーションシステムを使用しているクライアント側に配置され、文書ベースシステムは、大型機及びＬＩＮＵＸオペレーションシステムを使用しているサーバ側に配置されるが、アプリケーションから依然として、ローカル文書ベースシステムへの呼び出しと同様に、サーバにおける文書ベースシステムを呼び出して、相応の文書操作を実行することができる。

インターフェース標準には、特定のプログラミング言語に関連する特徴が含まれない場合、このインターフェース標準がプログラミング言語と関係ないことも可能である。上記からわかるように、命令列の方式では、プラットフォーム及びプログラミング言語と関係ないインターフェース標準を容易に構築でき、汎用性も高くなる。特に、ＸＭＬで命令列を構成すると、現在、各種の異なるプラットフォーム、異なるプログラミング言語にも、取得しやすいＸＭＬ生成解析ツールがあるため、このインターフェース標準は、優れたクロスプラットフォーム性、及びプログラミング言語との無関係性があるだけでなく、エンジニアによる上インターフェースユニット及び下インターフェースユニットへの開発にも非常に便利である。

上記には複数のインターフェース標準の実現方法が挙げられており、類似の考え方によって更なる多くのインターフェース標準を設計することは難しくない。

インターフェース標準では、同様の考え方によって上記実施形態の上で操作指令を追加、又は簡略化してもよい。特に汎用文書モデルが簡略化される場合、操作指令も相応に簡略化される。一番簡略化された場合は、文書の作成、ページの作成、各レイアウトオブジェクトの作成のいくつかの操作指令だけある。

図１に戻り、本発明が応用された文書処理システムの動作のプロセスを引き続き説明する。

アプリケーションは、インターフェース標準に適合する上インターフェースユニットを備える任意のアプリケーション、例えば、Ｏｆｆｉｃｅアプリケーション、内容管理やリソース収集などのアプリケーションであってよい。いずれかのアプリケーションが文書を操作しようとする場合、前記方法に従って指令を文書ベースシステムに伝送し、文書ベースシステムが指令に基づいて具体的な操作プロセスを完成する。

文書ベースシステムは、文書ベースデータに対して、記憶及び組織を自由に行うことができる。例えば、１つの文書ベースの全ての文書を１つのディスクファイルに記憶するようにしてよく、１つの文書を１つのディスクファイルに対応させ、オペレーションシステムのファイルシステム機能を利用してマルチ文書組織を実現するようにしてよく、１ページを１つのディスクファイルに対応させてもよく、オペレーションシステムを完全に利用しなくて、ディスクに領域を残して、ディスクトラック、セクタを直接に管理するようにしてもよい。文書ベースデータの記憶フォーマットについて、２値化フォーマット、ＸＭＬ、又は２値化ＸＭＬで保存してよい。ページ記述言語（ページ上のテキスト、図形、画像などのオブジェクトを定義する方法）について、ＰｏｓｔＳｃｒｉｐｔ、ＰＤＦ、又はＳＰＤなどのページ記述言語を採用してよく、もちろん、カスタマイズのページ記述言語を採用してもよい。つまり、インターフェース標準に定義された機能を実現できれば、いかなる実現方式を採用してもよい。

例えば、ＸＭＬで文書ベースデータを記述してよい。文書モデルが階層型である場合、それと完全に対照して相応のＸＭＬツリーを確立できる。作成操作の実行時にＸＭＬツリーにノードを追加し、削除操作の実行時に相応ノードを削除し、設定操作の実行時に相応ノードの属性を設定し、取得操作の実行時に相応ノードの属性を取り出してアプリケーションに返信し、問い合わせ操作の実行時に関連ノードを走査して検索する。以下、上記の実施形態を更に説明する。

１．ＸＭＬで各オブジェクトを記述する。つまり、各オブジェクトごとに対応のＸＭＬツリーを確立する。属性が比較的に簡単なオブジェクトについて、対応のＸＭＬツリーにルートノードだけあり、属性が比較的に複雑なオブジェクトについて、対応のＸＭＬツリーにルートノードの以外にサブノードもある。具体的な記述方法について、上記のＸＭＬで操作オブジェクトを定義する説明を参照してよい。

２．文書ベースが新規作成される場合、ルートノードが文書ベースオブジェクトであるＸＭＬファイルを新規作成する。

３．文書ベースにオブジェクト（例えば、テキストオブジェクト）が挿入されるたびに、このオブジェクトに対応するＸＭＬツリーをその親ノード（例えば層）の下に挿入する。このように、文書ベースの各オブジェクトはそれぞれ、文書ベースがルートノードであるＸＭＬツリーにおける対応ノードを有する。

４．オブジェクトが削除される場合、このオブジェクトに対応するノード、及び該ノードの全てのサブノードを削除する。削除プロセスでは、リーフノードから始めた走査を下から上まで行う。

５．オブジェクト属性が設定される場合、このオブジェクトに対応するノードの属性を該属性に設定する。この属性がサブノードの属性で表される場合、対応のサブノードの属性を設定する。

６．オブジェクト属性が取得される場合、このオブジェクトに対応するノードにアクセスし、このノードの属性及びサブノードによって該オブジェクトの属性を取得する。

７．オブジェクトのハンドルが取得される場合、このオブジェクトに対応するノードのＸＭＬパスを戻す。

８．オブジェクト（例えばページ）が指定位置にコピーされる場合、このオブジェクトに対応するノードから始めるサブツリー全体を、目標位置に対応する親ノード（例えば文書）の下にコピーする。オブジェクトが他の文書ベースにコピーされる場合、このサブツリーで引用されたオブジェクト（例えば組込みフォント）も一緒にコピーする必要がある。

９．レイアウト情報の取得指令が実行される場合、まず、サイズが指定領域と同じである指定ビットマップフォーマットの空白ビットマップを生成し、その後、指定ページの全てのレイアウトオブジェクトを走査し、指定領域内に位置するレイアウトオブジェクト（一部分のみ該領域内にあるものも含む）であれば、その意味を解釈して、レイアウトへ相応に反映する。具体的なプロセスが比較的に複雑で専門的であるが、従来のＲＩＰ技術の範囲に属するので、ここで説明を省略する。

１０．ロールオブジェクトの作成時に、ランダムのＰＫＩ鍵ペア（例えば５１２ｂｉｔのＲＳＡ鍵）を生成し、公開鍵をロールオブジェクトに記憶し、秘密鍵をアプリケーションに戻す。

１１．アプリケーションのログイン時に、ランダムデータブロック（例えば１２８バイト）を生成し、相応のロールオブジェクトの公開鍵で該データを暗号化してアプリケーションに送信する。アプリケーションがそれを復号化してから比較検証し、正しい場合、該ロールに対応する秘密鍵をアプリケーションが確実に有することを表し、ログイン成功になる。念のため、この認証プロセスを３回繰り返してよく、３回とも通過した場合のみ、ログイン成功になる。

１２．ある目標オブジェクトに対して署名を行うことは、即ちその対応ノードから始めるサブツリーに対して署名を行うことである。具体的な物理記憶方式による影響を署名に及ぼさないために、予め正規化を行うことにより、論理的に等価な変化（例えば、記憶位置の変化が相応ポインタの変化につながる）が署名の有効性を影響しないようにする必要がある。正規化の方法は、目標オブジェクトをルートノードとするサブツリーの各ノード（即ち目標オブジェクト及びその各サブオブジェクト）を深さ優先で走査し、走査順序に従って各ノードの正規化結果を順次算出して結合することを含む。

ここで、サブツリーのあるノードの正規化結果を算出する方法は、まず、このノードのサブノード数のＨＡＳＨ値を算出し、次に、このノード類型及びその各属性のＨＡＳＨ値を順次算出して、順序に従って該ノードのサブノード数のＨＡＳＨ値の次に結合し、その後、この結合結果のＨＡＳＨ値を算出して、該ノードの正規化結果を得ることを含む。サブツリーのあるノードで引用されたオブジェクトに対しても署名を一緒に行う必要がある場合、該ノードで引用されたオブジェクトも該ノードのサブノードとして、上記と同様の方法で処理するようにしてよい。

正規化してから、ＨＡＳＨ値を算出してロールの秘密鍵で署名する処理が従来技術を採用して行われることができるため、ここで説明を省略する。

上記正規化プロセスにおいて、ノードの正規化結果を算出する方法は、このノードのサブノード数、類型及びその各属性を順序に従ってセパレーターで結合し、この結合結果のＨＡＳＨ値を算出して、該ノードの正規化結果を得ることを含むようにしてよい。ノードの正規化結果を算出する方法は、このノードのサブノード数、類型及びその各属性の長さを順序に従ってセパレーターで結合して、またサブノード数、類型、各属性と結合して、該ノードの正規化結果を得ることを含むようにしてもよい。つまり、ノードの正規化結果を算出する方法は、ツリーのあるノードに対して、そのサブノード数、類型、各属性、及びサブノード数・類型・各属性の長さ（選択可能）の元の値又は特定変換（例えば、ＨＡＳＨ、圧縮）後の値を、所定の順序に従って結合する（直接に結合又はセパレーターで結合）ことを含む。

上記所定の順序は、サブノード数の長さ、類型の長さ、各属性の長さ、サブノード数、類型、各属性の任意の所定の並べ順序を含む。

また、サブツリーの各ノードの走査について、深さ優先走査、幅優先走査のいずれかを採用してもよい。

ここで、上記方案の各種の変形を提供することが難しくない。例えば、各ノードのサブノード数を深さ優先の順序に従ってセパレーターで結合して、また各ノードの他のデータの正規化結果と結合する。つまり、該サブツリーの全てのノードのサブノード数、類型及び各属性を所定の方法によって並べる限り、本実施形態の変形に属する。

１３．あるオブジェクトに対する権限設定について、最も簡単な実現方式は、各ロールの該オブジェクト（及びそのサブオブジェクト）に対する権限を簡単に記録して、且つ今後各ロールでのアクセス時に比較し、権限に適合する場合、相応の操作を許し、権限に適合しない場合、エラー情報を報告して戻すことを含む。更に好ましい実現方式は、相応のデータを暗号化して、鍵で権限を制御することを含む。該ロールには相応の鍵がなければ対応の権限もない。このような方式は攻撃耐性が更に強い。具体的な方案は以下の通りである。

ａ）保護されたデータ領域（通常はサブツリーであり、あるオブジェクト及びその全てのサブオブジェクトに対応する）に対応するＰＫＩ鍵ペアがあり、そのうちの暗号化鍵を用いてこのデータ領域を暗号化する。

ｂ）リード権限のあるロールに復号化鍵を与え、該ロールがこの鍵を用いてこのデータ領域を復号化して、これらのデータを正確に読み出すことができる。

ｃ）ライト権限のあるロールに暗号化鍵を与え、該ロールがこの鍵を用いて修正後のデータを暗号化して、該領域のデータを正確に書き込むことができる。

ｄ）ＰＫＩの暗号化・復号化の効率が比較的に低いため、運行効率を向上させるように、対称鍵を利用してデータ領域を暗号化してもよい。暗号化鍵でこの対称鍵を暗号化し、暗号化された鍵データを復号化鍵で復号化することで、正確な対称鍵を取得する。リード権限だけあるロールが対称鍵を取得した後にそれを利用してデータを修正することを防止するために、暗号化鍵を用いて該データ領域に対してデジタル署名を行うようにしてよい。ライト権限のあるロールが該データ領域を修正するたびに改めて署名を行うことによって、データがライト権限のないロールに改竄されないことを確保する。

ｅ）あるロールに暗号化鍵又は復号化鍵を与える場合、このロールの公開鍵を用いて該暗号化鍵又は復号化鍵を暗号化してから記憶するようにしてよい。これにより、該ロールの秘密鍵を持たなければ、該暗号化鍵又は復号化鍵を取り出すことができない。

本実施形態では、上記の文書ベースシステムに対して、本発明に係る文書データセキュリティ管理システム及びその方法を説明したが、本発明は上記以外のいかなるシステムにも同様に適用できる。

以下、まず、本発明に係る文書データセキュリティ管理システムを詳しく説明する。

本発明に係る文書データセキュリティ管理システムは、ロール管理手段と、セキュリティセッションチャンネル手段と、身分認証手段と、アクセス制御手段と、署名手段とを含む。ここで、ロール管理手段は、少なくとも１つのロールを管理し、ロールの作成、各ロールの権限付与、権限解除などの機能を備える。ロールは少なくとも１つの一意のＩＤ番号と少なくとも１ペアの一意のＰＫＩ鍵で表されてよいが、ロールオブジェクトにはそのＩＤ番号と公開鍵だけが記憶され、秘密鍵はアプリケーションによって持たれる。ロールは１つの一意のＩＤ番号とログインパスワードで表されてもよく、ロールオブジェクトにはそのＩＤ番号と暗号化されたログインパスワードだけが記憶される。ＩＤ番号は任意の番号又は文字列であってよく、異なるロールに異なるＩＤを配分するだけでよい。ＰＫＩアルゴリズムはＥＣＣ、又はＲＳＡであってよい。

文書ベースにおいて若干のロールが定義される。ロールオブジェクトは文書ベースオブジェクトのサブオブジェクトである。対応の汎用文書モデルには文書ベースオブジェクトがない場合、ロールは文書において定義され、即ち、ロールオブジェクトは文書オブジェクトのサブオブジェクトである。この場合、本文書データセキュリティ管理システムに言われた文書ベースは全て文書により代替されるべきである。

好ましくは、いかなるアプリケーションが、いかなる権限もない新たなロールの作成権限を有する。再付与権限のあるロールを用いて新たなロールに一定の権限を付与することが可能である。

ロールオブジェクト作成指令で戻された鍵は、今後該ロール身分でログインする依拠とされ、アプリケーションによって適切に保管される必要がある。この鍵は、通常、ＰＫＩの秘密鍵であるが、ログインパスワードであってもよい。

該文書データセキュリティ管理システムにおいて、特殊のデフォルトロールが作成できる。デフォルトロールが存在する場合、いかなるロールでもログインしなくても、デフォルトロールの身分で文書ベースを操作できる。好ましくは、文書ベースの初期作成時に、全ての権限を有するデフォルトロールを自動的に作成する。

アプリケーションのあるロール（又は複数のロール）でのログインから、一連の操作の実行後、最後のログアウトまでのプロセス全体は、セッションと呼ばれる。セッションは、セッション識別子やログインロールリストなどで表されることができる。セッションは、セキュリティセッションチャンネル手段のセキュリティセッションチャンネルを介して行われることができる。セキュリティセッションチャンネル手段は、少なくとも１つのセッション鍵を保存し、セッション鍵を用いてセキュリティセッションチャンネルの間で伝送されるデータを暗号化する。該セッション鍵は非対称鍵、又は効率のより高い常用の対称鍵であってよい。

身分認証手段は、ロールがログインする時、ログインの身分に対して認証を行う。ここで、身分認証の単位はロールであり、デフォルトロール以外に、あるロールの鍵を持たなければ、このロールの身分でログインできない。ログインする時に、該ロールの鍵がＰＫＩ鍵である場合、身分認証手段はログインロールのＩＤに基づいて、ロールオブジェクトに記憶されたロールの公開鍵を取り出して、前記の「挑戦―応答」メカニズムによって認証を行う。該ロールの鍵がログインパスワードである場合、身分認証手段はログインロールのＩＤに基づいて、ロールオブジェクトに記憶されたログインパスワードを取り出して、比較認証を行う。

アプリケーションは同時に複数のロールでログインしてよく、この時、このアプリケーションの有している権限はそれらの複数のロールの権限の和集合である。

アクセス制御手段は、文書データに対してアクセス制御権限を設定する。ロールは自分のアクセス制御権限以外に文書データにアクセスできない。さらに権限データを全てアクセス制御手段によって管理してもよく、このように、他人の権限を取得できるロールもあるが、取得できないロールもある。しかし、権限再付与又は権限解除の権限を有するロールだけが、正常の権限再付与又は権限解除の方式によってロールの権限を変更できるが、権限データを直接に書き込むことが許可されない。

ここで、任意ロールによる任意オブジェクト（例えば、文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、レイアウトオブジェクトなど）へのアクセス権限を指定できる。あるオブジェクトへのアクセス権限を指定すると、この権限は該オブジェクトの全てのサブオブジェクトに適用する。

ここで、アクセス権限には、リード権限（リード可否を示す）、ライト権限（ライト可否を示す）、権限再付与の権限（権限再付与、即ち、他のロールに自分の部分又は全部の権限を与えることの可否を示す）、権限解除の権限（権限解除、即ち、他のロールの部分又は全部の権限を解除することの可否を示す）、印刷権限（印刷可否を示す）、及び上記の任意の組合せが含まれ、本発明はこれに限定されない。好ましくは、文書ベースの初期作成時に、全ての権限を有するデフォルトロールを自動的に作成することによって、文書ベースの初期作成者に該文書ベースに対する全ての権限を持たせるようになる。

署名手段は、文書データセキュリティ管理システムにおいて、文書データの任意指定のロジックデータに対して署名を行う。秘密鍵を利用して該署名手段を通してロール署名を行うことができ、公開鍵を利用してロジックデータにおけるロール署名の合法性を検証することもできる。

あるロールの身分で各オブジェクトに対して署名できる。あるオブジェクトに対する署名範囲は、該オブジェクトのサブオブジェクト、及び該オブジェクトで引用されたオブジェクトを含む。

以下、上記のセキュリティ管理システムを参照しながら、本発明に係る文書データセキュリティ管理方法を更に詳しく説明する。

図１１に示すように、本発明に係る文書データセキュリティ管理方法は、以下のような操作ステップを含む。

１．文書ベースを新規作成する際に、ロール管理手段は、該文書ベースのデフォルトロールの権限を、全てのオブジェクトへのリード、ライト、権限再付与及び権限解除の権限を含む全ての権限に、自動的に設定する。

２．セキュリティセッションチャンネル手段は、アプリケーションと文書ベースシステムとの間のセキュリティセッションチャンネルを確立し、セッションを開始する。
ａ）セッション識別子に基づいて、セッションが既に開始したかどうかを判断し、既に開始した場合、セキュリティセッションチャンネルの確立プロセスを終了し、開始していない場合、セキュリティセッションチャンネルの確立プロセスを継続する。
ｂ）アプリケーションと文書ベースとのうちの一方はランダムＰＫＩ鍵ペアを生成する。
ｃ）ランダムＰＫＩ鍵ペアの生成側は公開鍵を相手側に送信する。
ｄ）相手側はセッション鍵としてランダム対称鍵を生成して、該公開鍵を用いてセッション鍵を暗号化してから、ランダムＰＫＩ鍵ペアの生成側に返信する。
ｅ）ランダムＰＫＩ鍵ペアの生成側は秘密鍵を用いてセッション鍵を復号化する。
ｆ）セッション識別子を設定する。
ｇ）ログインロールリストをデフォルトロールに設定する。

３．ロールがログインする。
ａ）アプリケーションは、ログインしようとするロールのＩＤと、ログイン先の文書ベースとを提供する。
ｂ）身分認証手段は、セッションのログインロールリストを検査し、該ロールが既にログインした場合（デフォルトロールを含む）、本ステップが完成し、該ロールがログインしていない場合、本ステップを継続する。
ｃ）該ロールの鍵がＰＫＩ鍵である場合、身分認証手段はロールオブジェクトに記憶されたロールの公開鍵を取り出し、該ロールの鍵がログインパスワードである場合、ステップｈ）を実行する。
ｄ）身分認証手段はランダムデータブロックを生成し、該ロールの公開鍵を用いて該データブロックを暗号化する。
ｅ）身分認証手段は、暗号化されたデータブロックをアプリケーションに送信する。
ｆ）アプリケーションは該ロールの秘密鍵で復号化して、復号化されたデータを身分認証手段に送信する。
ｇ）身分認証手段は、返信されたデータが正しいかどうかを判断し、正しくない場合、ログイン失敗になり、正しい場合、ステップｉ）を実行する。
ｈ）アプリケーションがログインパスワードを提供し、身分認証手段は、ロールオブジェクトに記憶されたログインパスワードと、アプリケーションから提供されたログインパスワードとを比較し、正しい場合、ログイン成功になり、後続のステップを継続に実行し、正しくない場合、ログイン失敗になる。
ｉ）セッションのログインロールリストに該ロールを追加する。

４．新たなロールを作成する。
ａ）アプリケーションは新たなロールを作成するための指令を送信する。
ｂ）ロール管理手段は一意のロールＩＤ番号を生成する。
ｃ）該指令で要求された作成しようとするロールの鍵がＰＫＩ鍵である場合、ロール管理手段はランダムＰＫＩ鍵ペアを生成し、該指令で要求された作成しようとするロールの鍵がログインパスワードである場合、該ロールのログインパスワードは該指令により指定されたログインパスワードであり、又は、該ロールのログインパスワードはロール管理手段によりランダムに生成されてもよい。
ｅ）ロール管理手段は文書ベースにおいてロールオブジェクトを作成し、ロールオブジェクトに上記ＩＤ番号と鍵（前記公開鍵又はログインパスワード）を記憶する。該ロールは、権限がヌルであり、即ち、いかなるオブジェクトに対してもいかなる権限も有しない。
ｆ）ＩＤ番号と鍵（前記秘密鍵又はログインパスワード）をアプリケーションに返信する。

５．オブジェクトＯに対する権限ＰをロールＲに付与する。
あるオブジェクトに対する権限設定について、最も簡単な実現方式は、各ロールの該オブジェクト（及びそのサブオブジェクト）に対する権限を簡単に記録して、且つ今後各ロールでのアクセス時に比較し、権限に適合する場合、相応の操作を許し、権限に適合しない場合、エラー情報を報告して戻すことを含む。更に好ましい実現方式は、相応のデータを暗号化して、鍵で権限を制御することを含む。該ロールには相応の鍵がなければ対応の権限もない。このような方式は攻撃耐性が更に強い。
ａ）アプリケーションは権利付与の要求を送信する。
ｂ）ロール管理手段は、ログインロールリスト内の全てのロールの、オブジェクトＯに対する権限の和集合を算出し、この和集合が権限Ｐのスーパーセット（ｓｕｐｅｒｓｅｔ）であり且つ権限再付与の権限を含むということが成立するかどうかを判断する。成立しない場合、権限付与失敗になる（この時、全てのロールの権限においても、権限付与に必要な権限が含まれない）。成立する場合、プロセスを継続する。
ｃ）ロール管理手段は、オブジェクトＯに対する権限ＰをロールＲの権限リストに追加する。権限Ｐにはリード又はライトの権限が含まれない場合、権限付与が完成し、権限Ｐにはリード又はライトの権限が含まれる場合、プロセスを継続する。
ｄ）アクセス制御手段は、オブジェクトＯに対してリード/ライトのアクセス制御権限が既に設定されたかどうかを検査する。設定されていない場合、以下のようなステップを実行する。
ｉ．ランダム対称鍵とランダムＰＫＩ鍵を生成する。
ii．対称鍵を用いてオブジェクトＯを暗号化する。オブジェクトＯのあるサブオブジェクトに対してリード/ライトのアクセス制御権限が既に設定された場合、該サブオブジェクトは変更されない。
保護されたデータ領域（通常はサブツリーであり、あるオブジェクト及びその全てのサブオブジェクトに対応する）に対応するＰＫＩ鍵ペアがあり、そのうちの暗号化鍵を用いてこのデータ領域を暗号化する。
iii．ＰＫＩ暗号化鍵を用いて対称鍵を暗号化して、得られた暗号文を記憶し、オブジェクトＯに対して署名を行う。
iv．文書ベース内の全てのロールを検査し、オブジェクトＯに対してリード権限を有するロールでさえあれば（この時、オブジェクトＯは、該ロールがリード権限を有するあるオブジェクトのサブオブジェクトである）、該ロールの公開鍵を用いて復号化鍵を暗号化して、得られた暗号文を該ロールの権限リストに記憶する。オブジェクトＯに対してライト権限を有するロールでさえあれば（この時、オブジェクトＯは、該ロールがライト権限を有するあるオブジェクトのサブオブジェクトである）、該ロールの公開鍵を用いて暗号化鍵を暗号化して、得られた暗号文を該ロールの権限リストに記憶する。
ｖ．ステップｈを実行する。
ｅ）現在ログインしたロールから、オブジェクトＯに対して相応の権限を有するロールを選択する。
ｆ）該ロールの権限リスト内のオブジェクトＯの対応の鍵（リード権限が復号化鍵に対応し、ライト権限が暗号化鍵に対応し、リード/ライト権限がその２つの鍵に対応する）の暗号文を取り出し、該ロールの鍵がＰＫＩ鍵である場合、該暗号文をアプリケーションに送信して、ステップｇ）に進み、該ロールの鍵がログインパスワードである場合、アクセス制御手段は該暗号文を復号化してから、ステップｈ）に進む。
リード権限のあるロールに復号化鍵を与え、該ロールはこの鍵を用いて該データ領域を復号化して、これらのデータを正確に読み取ることができる。ライト権限のあるロールに暗号化鍵を与え、該ロールはこの鍵を用いて修正後のデータを暗号化して、該領域のデータを正確に書き込むことができる。
ｇ）アプリケーションは該ロールの秘密鍵を用いて鍵を復号化して、アクセス制御手段に返信する。
ｈ）アクセス制御手段は権限Ｐの設定に基づいて、相応の鍵を暗号化し、対応の暗号文を生成して、ロールＲの権限リストに記憶する。
あるロールに暗号化鍵又は復号化鍵を与える場合、このロールの公開鍵を用いて該暗号化鍵又は復号化鍵を暗号化してから記憶するようにしてよい。これにより、該ロールの秘密鍵を持たなければ、該暗号化鍵又は復号化鍵を取り出すことができない。
ＰＫＩの暗号化・復号化の効率が比較的に低いため、運行効率を向上させるように、対称鍵を利用して該データ領域を暗号化してもよい。暗号化鍵でこの対称鍵を暗号化し、暗号化された鍵データを復号化鍵で復号化することで、正確な対称鍵を取得する。リード権限だけあるロールが対称鍵を取得した後にそれを利用してデータを修正することを防止するために、暗号化鍵を用いて該データ領域に対してデジタル署名を行うようにしてよい。ライト権限のあるロールが該データ領域を修正するたびに改めて署名を行うことによって、データがライト権限のないロールに改竄されないことを確保する。

６．ロールＲのオブジェクトＯに対する権限Ｐを解除する。
ａ）アプリケーションは権限解除の要求を送信する。
ｂ）ロール管理手段は、ログインロールリスト内の全てのロールから、オブジェクトＯに対して権限解除の権限を有するロールを検索し、権限解除の権限を有するロールがない場合、権限解除失敗になり、権限解除の権限を有するロールがある場合、プロセスを継続する。
ｃ）ロールＲのオブジェクトＯに対する権限から権限Ｐを除去する。
ｄ）権限Ｐにはリード又はライト権限が含まれる場合、オブジェクトＯに対応する復号化鍵及び／又は暗号化鍵をロールＲの権限リストから削除する。

７．オブジェクトＯを読み取る。
ａ）アプリケーションはオブジェクトＯを読み取るための操作指令を送信する。
ｂ）アクセス制御手段はログインロールリスト内の全てのロールのオブジェクトＯに対する権限を検査して、オブジェクトＯへのリード権限を有するロールが少なくとも１つあるかどうかを確認する。１つもない場合、失敗になり、少なくとも１つある場合、プロセスを継続する。
ｃ）オブジェクトＯに対してリード/ライトのアクセス制御権限が既に設定されたかどうかを検査し、設定されていない場合、その親オブジェクトを検査し、親オブジェクトに対しても設定されていない場合、リード/ライトアクセス制御権限が設定されたオブジェクトを見つけるまで、該親オブジェクトの親オブジェクトを更に検査する。
ｄ）該オブジェクトに対してリード権限を有するロールを１つ選択する。
ｅ）該ロールの権限リストに記憶された該オブジェクトの復号化鍵の暗号文を取り出し、該ロールの鍵がＰＫＩ鍵である場合、該暗号文をアプリケーションに送信してステップｆ）に進み、該ロールの鍵がログインパスワードである場合、アクセス制御手段は該暗号文を復号化してステップｇ）に進む。
ｆ）アプリケーションは該ロールの秘密鍵を用いて復号化鍵を復号化して、アクセス制御手段に返信する。
ｇ）アクセス制御手段は該復号化鍵を用いて該オブジェクトの対称鍵を復号化する。
ｈ）該対称鍵を用いてオブジェクトＯのデータを復号化する。
ｉ）復号化されたデータをアプリケーションに返信する。

８．オブジェクトＯを書き込む。
ａ）アプリケーションはオブジェクトＯを修正するための操作指令を送信する。
ｂ）アクセス制御手段はログインロールリスト内の全てのロールのオブジェクトＯに対する権限を検査し、オブジェクトＯへのライト権限を有するロールが少なくとも１つあるかどうかを確認する。１つもない場合、失敗になり、少なくとも１つある場合、プロセスを継続する。
ｃ）オブジェクトＯに対してリード/ライトのアクセス制御権限が既に設定されたかどうかを検査し、設定されていない場合、その親オブジェクトを検査し、親オブジェクトに対しても設定されていない場合、リード/ライトアクセス制御権限が設定されたオブジェクトＯ１を見つけるまで、該親オブジェクトの親オブジェクトを更に検査する。
ｄ）オブジェクトＯ１に対してライト権限を有するロールを１つ選択する。
ｅ）該ロールの権限リストに記憶されたオブジェクトＯ１の暗号化鍵の暗号文を取り出し、該ロールの鍵がＰＫＩ鍵である場合、該暗号文をアプリケーションに送信してステップｆ）に進み、該ロールの鍵がログインパスワードである場合、アクセス制御手段は該暗号文を復号化してステップｇ）に進む。
ｆ）アプリケーションは該ロールの秘密鍵を用いてオブジェクトＯ１の暗号化鍵を復号化して、アクセス制御手段に返信する。
ｇ）該暗号化鍵をを用いてオブジェクトＯの新たなデータを暗号化する（オブジェクトＯのあるサブオブジェクトに対してリード/ライトアクセス制御権限が既に設定された場合、依然としてその鍵を用いて該サブオブジェクトを暗号化する）。
ｈ）暗号化されたデータで元のデータをオーバーライトし、書き込むプロセスを完成する。

９．オブジェクトＯに対して署名を行う。
ａ）アプリケーションはオブジェクトＯに対して署名を行うための指令を送信する。
ｂ）アクセス制御手段はオブジェクトＯのデータに対して正規化を行う。
あるオブジェクトに対して署名を行うことは、即ちその対応ノードから始めるサブツリーに対して署名を行うことである。具体的な物理記憶方式による影響を署名に及ぼさないために、予め正規化を行うことにより、論理的に等価な変化（例えば、記憶位置の変化が相応ポインタの変化につながる）が署名の有効性を影響しないようにする必要がある。正規化の方法は上述した通りである。
ｃ）正規化結果のＨＡＳＨ値を算出する。
ｄ）ＨＡＳＨ値をアプリケーションに送信する。
ｅ）ログインロールリスト内のロール鍵がＰＫＩ鍵である全てのロールに対して、アプリケーションは前記ロールの秘密鍵を用いて該ＨＡＳＨ値を暗号化（即ち署名）する。
ｆ）アプリケーションは署名結果をアクセス制御手段に返信する。
ｇ）アクセス制御手段は署名結果をデジタル署名オブジェクトに記憶する。

１０．ログインしたロールをログアウトする。
ａ）アプリケーションはあるログインロールをログアウトするための指令を送信する。
ｂ）ログインロールリストに該ロールが存在している場合、セキュリティセッションチャンネル手段はログインロールリストから該ロールを除去する。

１１．セッションを終了する。
ａ）アプリケーションと文書ベースシステムのうちの一方はセッション終了要求を送信する。
ｂ）セキュリティセッションチャンネル手段は現在のセッションに関連する全てのスレッドを終了し、セッション識別子を削除し、ログインロールリストを削除する。

以下は、本発明に係る文書データセキュリティ管理方法がコンピューターにより実現される例である。
ｃｌａｓｓＵＯＩ＿ＲｏｌｅＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！リスト内のロール数の取得
ｉｎｔＧｅｔＲｏｌｅＣｏｕｎｔ（）；
／／！指定のインデックスに従って、ロールを取得する
ＵＯＩ＿Ｒｏｌｅ＊ＧｅｔＲｏｌｅ（ｉｎｔｎＩｎｄｅｘ）；
／／！ロールの作成
／＊！
\ｐａｒａｍｐＰｒｉｖＫｅｙ秘密鍵のバッファー
\ｐａｒａｍｐｎＫｅｙＬｅｎ戻される実際の秘密鍵の長さ
\ｒｅｔｕｒｎ新規作成のロール
＊／
ＵＯＩ＿ＲｏｌｅＡｄｄＲｏｌｅ（ｕｎｓｉｇｎｅｄｃｈａｒ＊ｐＰｒｉｖＫｅｙ，ｉｎｔ＊ｐｎＫｅｙＬｅｎ）；
／／！コンストラクタ関数
ＵＯＩ＿ＲｏｌｅＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＲｏｌｅＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｒｏｌｅ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿Ｒｏｌｅ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｒｏｌｅ（）；
／／！ロールＩＤの取得
ｉｎｔＧｅｔＲｏｌｅＩＤ（）；
／／！ロールＩＤの設定
／＊！
\ｐａｒａｍｎＩＤロールＩＤ
＊／
ｖｏｉｄＳｅｔＲｏｌｅＩＤ（ｉｎｔｎＩＤ）；
／／！ロール名称の取得
ｃｏｎｓｔｃｈａｒ＊ＧｅｔＲｏｌｅＮａｍｅ（）；
／／！ロール名称の設定
／＊！
\ｐａｒａｍｓｚＮａｍｅロール名称
＊／
ｖｏｉｄＳｅｔＲｏｌｅＮａｍｅ（ｃｏｎｓｔｃｈａｒ＊ｓｚＮａｍｅ）；
｝；

ｃｌａｓｓＵＯＩ＿ＰｒｉｖＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ／／権限リスト
｛
ｐｕｂｌｉｃ：
／／！指定ロールに対応する権限の取得
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ＧｅｔＲｏｌｅＰｒｉｖ（ＵＯＩ＿Ｒｏｌｅ＊ｐＲｏｌｅ）；
／／！あるロールの権限項目の新規作成
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ｐＰｒｉｖＡｄｄＲｏｌｅ（）；
／／！リスト内のロールの権限項目数の取得
ｉｎｔＧｅｔＲｏｌｅＰｒｉｖＣｏｕｎｔ（）；
／／！インデックス値に従って、ロールの権限項目を取得する
ＵＯＩ＿ＲｏｌｅＰｒｉｖ＊ＧｅｔＲｏｌｅＰｒｉｖ（ｉｎｔｎＩｎｄｅｘ）；
／／！コンストラクタ関数
ＵＯＩ＿ＰｒｉｖＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＰｒｉｖＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＲｏｌｅＰｒｉｖ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ／／あるロールの全ての権限に対応する
｛
ｐｕｂｌｉｃ：
／／！ロールの取得
ＵＯＩ＿Ｒｏｌｅ＊ＧｅｔＲｏｌｅ（）；
／／！あるオブジェクトに対する権限を設定する。権限が該ロールの該オブジェクトに対する現在の権限を越える場合、権限付与になり、権限が該ロールの該オブジェクトに対する現在の権限より小さい場合、権限解除になる。現在ログインしたロールは相応の権限再付与又は権限解除の権限を持たなければならない。
ｂｏｏｌＳｅｔＰｒｉｖ（ＵＯＩ＿Ｏｂｊ＊ｐＯｂｊ，ＵＯＩ＿Ｐｒｉｖ＊ｐＰｒｉｖ）；
／／！設定された権限の数の取得
ｉｎｔＧｅｔＰｒｉｖＣｏｕｎｔ（）；
／／！インデックス値に対応する権限が設定されたオブジェクトの取得
ＵＯＩ＿Ｏｂｊ＊ＧｅｔＯｂｊ（ｉｎｔｎＩｎｄｅｘ）；
／／！インデックス値に対応する権限で設定された権限の取得
ＵＯＩ＿Ｐｒｉｖ＊ＧｅｔＰｒｉｖ（ｉｎｔｎＩｎｄｅｘ）；
／／！あるオブジェクトに対応する権限の取得
ＵＯＩ＿Ｐｒｉｖ＊ＧｅｔＰｒｉｖ（ＵＯＩ＿Ｏｂｊ＊ｐＯｂｊ）；
／／！コンストラクタ関数
ＵＯＩ＿ＲｏｌｅＰｒｉｖ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＲｏｌｅＰｒｉｖ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｐｒｉｖ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
ｅｎｕｍＰｒｉｖＴｙｐｅ｛／／各権限類型の定義
ＰＲＩＶ＿ＲＥＡＤ，／／リード権限
ＰＲＩＶ＿ＷＲＩＴＥ，／／ライト権限
ＰＲＩＶ＿ＲＥＬＩＣＥＮＳＥ，／／権限再付与の権限
ＰＲＩＶ＿ＢＥＲＥＡＶＥ，／／権限解除の権限
ＰＲＩＶ＿ＰＲＩＮＴ，／／印刷権限
他の権限の定義
｝
／／！相応の権限の有無
ｂｏｏｌＧｅｔＰｒｉｖ（ＰｒｉｖＴｙｐｅｐｒｉｖＴｙｐｅ）；
／／！相応の権限の設定
ｖｏｉｄＳｅｔＰｒｉｖ（ＰｒｉｖＴｙｐｅｐｒｉｖＴｙｐｅ，ｂｏｏｌｂＰｒｉｖ）；
／／！コンストラクタ関数
ＵＯＩ＿Ｐｒｉｖ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｐｒｉｖ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＳｉｇｎＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿ＳｉｇｎＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＳｉｇｎＬｉｓｔ（）；

／／！新たなノード署名を追加し、そのインデックス値を戻す
ｉｎｔＡｄｄＳｉｇｎ（ＵＯＩ＿Ｓｉｇｎ＊ｐＳｉｇｎ）；
／／！指定のインデックス値に従って、ノード署名を取得する
ＵＯＩ＿ＳｉｇｎＧｅｔＳｉｇｎ（ｉｎｔｉｎｄｅｘ）；
／／！指定のインデックス値に従って、ノード署名を削除する
ｖｏｉｄＤｅｌＳｉｇｎ（ｉｎｔｉｎｄｅｘ）；
／／！リスト内のノード署名の数の取得
ｉｎｔＧｅｔＳｉｇｎＣｏｕｎｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿Ｓｉｇｎ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿Ｓｉｇｎ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿Ｓｉｇｎ（）；

／／！署名の実行
／＊！
\ｐａｒａｍｐＤｅｐＬｉｓｔ署名の依存リスト
\ｐａｒａｍｐＲｏｌｅ署名するロール
\ｐａｒａｍｐＯｂｊ署名されるオブジェクト
＊／
ｖｏｉｄＳｉｇｎ（ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔｐＤｅｐＬｉｓｔ，ＵＯＩ＿ＲｏｌｅｐＲｏｌｅ，ＵＯＩ＿ＯｂｊｐＯｂｊ）；
／／！署名の検証
ｂｏｏｌＶｅｒｉｆｙ（）；
／／！署名の依存リストの取得
ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔＧｅｔＤｅｐＬｉｓｔ（）；
｝；

ｃｌａｓｓＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ：ｐｕｂｌｉｃＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
／／！コンストラクタ関数
ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ（）；
／／！デストラクタ関数
ｖｉｒｔｕａｌ〜ＵＯＩ＿ＳｉｇｎＤｅｐＬｉｓｔ（）；

／／！依存項目の追加
ｖｏｉｄＩｎｓｅｒｔＳｉｇｎＤｅｐ（ＵＯＩ＿Ｓｉｇｎ＊ｐＳｉｇｎ）；
／／！依存項目数の取得
ｉｎｔＧｅｔＤｅｐＳｉｇｎＣｏｕｎｔ（）；
／／！指定のインデックス値に従って、依存項目を取得する
ＵＯＩ＿Ｓｉｇｎ＊ＧｅｔＤｅｐＳｉｇｎ（ｉｎｔｎＩｎｄｅｘ）；
｝；

作業効率を向上させるために、実施時、上記のステップを強化又は簡略化してよい。例えば、各ロールの秘密鍵を毎回もアプリケーションに送信して復号化することなく、各ロールの秘密鍵をセッションデータにバッファーしたり（セッション終了後に削除）、又はセキュリティ措置を一部省略したり、機能を一部減少したりする。つまり、上記方法に対するいかなる簡略化方法も本実施形態の変形である。

本実施形態はツリー構造の文書管理構造によってセキュリティ管理システムを提供している。ロールで身分認証を行い、セキュリティ認証に関するセキュリティセッションにおいて、複数のロールのログインが許可される。異なるロールを利用して身分認証、権限制御、又は署名及び署名検証を行う。アクセス制御によって、いかなるサブツリーの文書データに対してセキュリティ制御の権限を指定でき、権限がロールによって付与される。現在のセキュリティセッションにおいて、ある特定のサブツリーの文書データに対する権限は、全てのロールの権限の和集合である。セキュリティセッションにおいて、文書データのセキュリティ制御権限に対して権限付与と権限解除を行うことができる。このような権限付与と権限解除はロールによって提供されてよい。アクセス制御は暗号化によって行われ、暗号化はいかなるサブツリーの文書データに対しても行うことができる。同時に、いかなるサブツリーのデータに対しても署名と署名検証を行うことができる。署名は、セキュリティセッション中において、あるロールの秘密鍵で行われる。署名を行うための秘密鍵は、ロールリスト手段内のあるロールの秘密鍵であってよい。ツリー構造の文書データに対して署名を行う前に、各ノード間のデジタル署名が異なることを確保するように正規化してもよい。

本発明は文書データセキュリティ管理システムを提供している。このシステムでは、身分認証メカニズム、アクセス制御メカニズム、及び署名検証メカニズムが組み入れられており、文書データに対する身分認証、アクセス制御、署名が、特定の文書データに制限されず、システム内の可能な全ての文書データに対して、セキュリティ制御、即ち認証、アクセス制御、署名及び署名検証が行われることができる。

本発明に説明された文書セキュリティ技術、例えば、ロールに基づく権限管理、セキュリティセッションチャンネル、ロールの認証方式、マルチロールログイン、ツリー構造に対する正規化技術、細粒度の権限管理手段、暗号化に基づく権限設定などは、本発明に記載された文書処理システムのみに適用することではなく、他の環境にも適用される。本発明はこれを限定しない。

本発明が応用された文書処理システムにおいて、文書処理システムで紙の特性をよく模擬できるように、「追加のみ修正せず」という技術案を提供している。つまり、各アプリケーションは、現在の文書内容の上に新たな内容を追加するだけで、既存内容を修正・削除しない。これにより、文書のページが紙のようになり、異なる人が異なるペンを用いて紙に書くことができるが、だれでも既存内容を修正・削除できない。具体的な方法は以下の通りである。各アプリケーションは、他のアプリケーションで生成された文書を編集する場合、現在の文書の上に１層を新たに追加し、本アプリケーションで新たに編集された全ての内容をこの層に置き、前の各層の内容を修正・削除しない。このように、各文書の各層ごとに１つだけのアプリケーションによって管理・維持されるが、他のアプリケーションで該層を編集できなくなる。現在の社会が紙に基づいて運営されるため、文書処理システムは、紙の特性に適合する限り、現在の応用ニーズを満たすことができ、十分の実用価値がある。

各層の内容が生成された後、修正・削除されないことを確保するために、各層のデジタル署名オブジェクトを利用してよい。デジタル署名は、本層の内容に対して署名してよい。好ましくは、本層及び本層の前に生成された全ての層の内容に対して一緒に署名する。署名後にも、文書に対するコメントなどの更なる編集が妨害されない。新たな内容が新たな層に位置し、署名時に既存の各層が修正・破壊されない限り、署名は依然として有効であるが、署名者が署名前の内容のみに対して責任を負い、署名後の内容に対して責任を負わない。これは応用ニーズに非常に適合する技術案であり、かなり実用価値がある。これに比べて、従来の他の技術では、署名後の編集が許されなかったり、編集後（「追加のみ修正せず」の編集にもかかわらず）に署名が破壊されたりする。

前記技術案では、文書の既存内容の修正が許されなく、紙の特性との互換性及びデジタル署名問題を考慮しなくても、修正必要の場合にレイアウトレベルの編集しかできない。即ち、各レイアウトオブジェクトに対する編集（追加、削除、修正）は、他のレイアウトオブジェクトに影響を及ぼさない。ユーザが文書の既存内容を元の方式で編集しようとする場合、以下の技術案でこの応用ニーズをよく満たすことができる。該方案について、アプリケーションが初期編集を完成すると、１層を新規作成して現在の編集内容を保存する以外に、またソースファイル（各オブジェクト間の完全な関係がアプリケーション自分のフォーマットで記録されているファイル、例えば．ｄｏｃファイル）を文書に組み込む。今回引き続き編集する必要がある場合、文書からこのソースファイルを取り出して、該ソースファイルを使用して引き続き編集する。編集が完成された後、該アプリケーションで管理された層を消去し、該層の内容を改めて生成し、且つ新たに修正されたソースファイルを引き続き文書に組み込む。

具体的な方法は以下のステップを含む。
１．アプリケーションは、文書を初めて処理するとき、１層を新規作成し、新たな編集内容に対応するレイアウトオブジェクトを新規作成の層に挿入するとともに、自分のフォーマットで新たな編集内容（即ちソースファイル）を別途記憶する。
２．文書オブジェクトのサブオブジェクトとしてソースファイルオブジェクトを新規作成する。該ソースファイルオブジェクトは、ソースファイルを組み込み（例えば、２値化データの方式で全体組み込む）、どの層が該ソースファイルオブジェクトに対応するかを記録することに用いられる。
３．同じアプリケーションを用いて該文書を再度編集するとき、対応のソースファイルオブジェクトから対応のソースファイルを取り出す。
４．該ソースファイルを使用して該層の内容を引き続き編集する。このソースファイルのフォーマットが該アプリケーション自分のフォーマットであるため、該アプリケーション自分の機能によって該層の内容を引き続き編集できる。
５．再度編集が終了した後、新たに編集後の結果によって該層の内容を更新する（例えば、全部消去後改めて生成する方式で）とともに、新たに修正後のソースファイルを改めて文書オブジェクトに組み込む。
６．このように繰り返して、元のアプリケーションを用いて元の方式で文書の既存内容を編集できる。

上記技術案を採用することで、文書の相互運用性を最大限に実現できる。十分のセキュリティ権限がある前提で、アプリケーション及び文書は本発明の技術を採用すると、以下の機能を実現できる。
１．いかなる文書について、いかなるアプリケーションでも、正確にオープン・表示・印刷できる。
２．いかなる文書について、いかなるアプリケーションでも、いかなる内容を追加でき、且つ文書の既存署名が破壊されない。
３．いかなる文書について、文書の既存署名を考慮する必要がない（署名なし、又は署名あるが破壊を許す）前提で、いかなるアプリケーションでも、文書の既存内容に対してレイアウトレベルの編集を行うことができる。
４．いかなる文書について、文書の既存内容の元の編集アプリケーションで、この内容を正常に編集できる。

上記からわかるように、本発明の層に対する管理によって、文書の管理、相互運用性、セキュリティ設定に極めて大きな便利をもたらす。

以下、図１０を参照して、本発明による文書処理システムで操作を実行する実施形態を説明する。この実施形態では、アプリケーションが統一的なインターフェース標準（例えば、ＵＯＭＬインターフェース）を介して、文書に対する操作を要求する。文書ベースシステムに異なるメーカーからの異なるタイプがあり得るが、アプリケーションの開発メーカーにとって同じインターフェース標準に向くため、異なるメーカーからの異なるタイプの各文書ベースシステムがアプリケーションとあわせて使用できる。ＲｅｄＯｆｆｉｃｅ、ＯＣＲ、ウェブページ生成アプリケーション、楽譜編集アプリケーション、書生リーダー、Ｏｆｆｉｃｅ編集アプリケーション、その他のリーダーなどが、ＵＯＭＬインターフェースを介して文書ベースシステムに操作を指示する。文書ベースシステムが複数であってもよく、図１０に文書ベースシステム１、文書ベースシステム２及び文書ベースシステム３が示される。文書ベースシステムがＵＯＭＬからの統一標準指令によって、汎用文書モデルに適合した文書を操作し、例えば、文書を作成・保存・表示・表現する。本発明において、異なるアプリケーションは同時又は異時に同一文書ベースシステムを呼び出すことができ、同一アプリケーションは同時又は異時に異なる文書ベースシステムを呼び出すことができる。

本発明によれば、優れたセキュリティメカニズムが提供され、マルチロールを設定でき、各ロールの権限を細粒度に設定できる。ここでの細粒度には意味が２つあり、文書全体又は文書の微小な所に対して権限設定を行うことができる一方、伝統的なリード・ライト・アクセス不可の３段の権限だけでなく、多種類の権限を設定できる。

本発明によれば、性能の最適化が便利になり、もっと優れた可搬性と拡張性が提供されている。いかなる性能を持ついかなるプラットフォームでも、同様の呼び出しインターフェースに従うことができるため、インターフェース標準を変えずに、性能を絶えず最適化でき、且つ異なるプラットフォームに移行できる。

上記は、本発明の好ましい実施形態にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等切替、改善などは全て本発明の保護範囲内に含まれるべきである。

文書処理システムの構成を示すブロック図である。本発明の好ましい実施形態による汎用文書モデルの構成を示す図である。図２の汎用文書モデルにおける文書ベースオブジェクトの構成を示す図である。図３の文書ベースオブジェクトにおける文書ベース補助オブジェクトの構成を示す図である。図３の文書ベースオブジェクトにおける文書セットオブジェクトの構成を示す図である。図５の文書セットオブジェクトにおける文書オブジェクトの構成を示す図である。図６の文書オブジェクトにおけるページオブジェクトの構成を示す図である。図７のページオブジェクトにおける層オブジェクトの構成を示す図である。図８の層オブジェクトにおけるレイアウトオブジェクトの構成を示す図である。ＵＯＭＬインターフェースを例とする文書処理システムを示す図である。本発明に係る文書データセキュリティ管理方法のフローチャートである。

Claims

文書データセキュリティ管理方法であって、
汎用文書モデルに適合する文書又は文書ベースを管理する文書ベースシステムに応用され、
前記文書ベース又は文書のロールを作成する過程と、
前記ロールに権限を配分する過程と、
ロールで前記文書又は文書ベースにログインする過程と、
前記文書ベースシステムを介して前記文書又は文書ベースにアクセスする際、ログインしたロールの権限を検査する過程と、
を含むことを特徴とする方法。
前記文書ベース又は文書のロールを作成する過程は、アプリケーションが前記文書ベースシステムを介して文書又は文書ベースのロールを作成する過程を含み、
前記ロールで前記文書又は文書ベースにログインする過程は、アプリケーションが前記文書ベースシステムを介して前記文書又は文書ベースにログインする過程を含むことを特徴とする請求項１に記載の方法。
アプリケーションが文書又は文書ベースにログインする前に、該アプリケーションと該文書ベースシステムとの間でセキュリティセッションを確立する過程をさらに含むことを特徴とする請求項２に記載の方法。
前記該アプリケーションと該文書ベースシステムとの間でセキュリティセッションを確立する過程が、
該アプリケーションと該文書ベースシステムのうちの一方が、公開鍵と秘密鍵とを含むランダムのＰＫＩ鍵ペアを生成し、該公開鍵を相手側に送信する過程と、
公開鍵の受信側が、セッション鍵としてランダムの対称鍵を生成し、該公開鍵を用いて該セッション鍵を暗号化して、相手側に返信する過程と、
暗号化して返信されたセッション鍵の受信側が、前記ＰＫＩ鍵ペアの秘密鍵で復号化して、セッション鍵を得る過程と、
を含むことを特徴とする請求項３に記載の方法。
前記ロールに権限を配分する過程が、
前記汎用文書モデルにおける一部又は全部のオブジェクトに対する権限をロールに配分する過程を含むことを特徴とする請求項１に記載の方法。
前記汎用文書モデルにおける一部又は全部のオブジェクトが、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、及びレイアウトオブジェクトのいずれか１つ又は任意の組合せを含むことを特徴とする請求項５に記載の方法。
前記ロールに権限を配分する過程が、
アプリケーションが、目標オブジェクトに対して目標ロールに目標権限を配分することを要求するための権限付与要求を送信する過程と、
該アプリケーションの全てのログインしたロールの、該目標オブジェクトに対する権限の和集合を計算し、該和集合が該目標権限のスーパーセットであり且つ権限再付与の権限を含む場合、該目標権限を該目標ロールの権限に追加する過程と、
を含むことを特徴とする請求項５に記載の方法。
該目標権限を該目標ロールの権限に追加した後に、該目標権限にリード権限が含まれる場合、目標オブジェクトを暗号化方式で記憶し、その復号化鍵を目標ロールに記憶する過程をさらに含むことを特徴とする請求項７に記載の方法。
該目標権限を該目標ロールの権限に追加した後に、該目標権限にライト権限が含まれる場合、目標オブジェクトを暗号化方式で記憶し、その暗号化鍵を目標ロールに記憶する過程をさらに含むことを特徴とする請求項７に記載の方法。
前記復号化鍵を目標ロールに記憶する過程が、ロールに対応する鍵を用いて該復号化鍵を暗号化して、得られた該復号化鍵の暗号文を記憶する過程を含むことを特徴とする請求項８に記載の方法。
前記暗号化鍵を目標ロールに記憶する過程が、ロールに対応する鍵を用いて該暗号化鍵を暗号化して、得られた該暗号化鍵の暗号文を記憶する過程を含むことを特徴とする請求項９に記載の方法。
前記目標オブジェクトを暗号化方式で記憶する過程が、
ランダムの対称鍵とランダムのＰＫＩ鍵ペアを生成する過程と、
該対称鍵を用いて該目標オブジェクトを暗号化する過程と、
該ＰＫＩ鍵ペアの暗号化鍵を用いて該対称鍵を暗号化して、得られた該対称鍵の暗号文を記憶し、該目標オブジェクトに対して署名を行う過程と、
を含むことを特徴とする請求項８〜１１のいずれか１項に記載の方法。
文書ベース又は文書を作成する際に、該文書ベースオブジェクト又は文書オブジェクト自身、及びその全てのサブオブジェクトに対する全ての権限を有するデフォルトロールを自動的に作成する過程をさらに含むことを特徴とする請求項１に記載の方法。
前記権限が、リード権限、ライト権限、権限再付与の権限、及び権限解除の権限のうち１つ又は複数の任意の組合せを含むことを特徴とする請求項５〜１３のいずれか１項に記載の方法。
前記文書ベース又は文書のロールを作成する過程が、
アプリケーションが、目標文書ベースオブジェクト又は文書オブジェクトの新たなロールの作成を要求する過程と、
文書ベースシステムが、該新たなロールのロールオブジェクトを作成する過程と、
を含むことを特徴とする請求項１に記載の方法。
前記文書ベースシステムが、該新たなロールのロールオブジェクトを作成する過程が、
一意のロールＩＤ番号と一意のロール鍵を生成し、文書ベースシステムを介して該新たなロールのロールオブジェクトを作成し、該ロールオブジェクトに前記ロールＩＤ番号とロール鍵を記憶し、該ロールオブジェクトのロールＩＤ番号とロール鍵をアプリケーションに返信する過程を含むことを特徴とする請求項１５に記載の方法。
該新規作成のロールの権限を、いかなるオブジェクトに対しても権限がないように設定することを特徴とする請求項１６に記載の方法。
前記ロールで文書又は文書ベースにログインする過程が、
アプリケーションが、ログインしようとするロールのＩＤ番号を提供する過程と、
文書ベースシステムが、該ロールのロールオブジェクトに記憶された鍵を用いて、該ロールに対して身分認証を行う過程と、
身分認証が通過した場合、ログイン成功になる過程と、
を含むことを特徴とする請求項１６に記載の方法。
前記ロールオブジェクトに記憶された鍵が、ランダムに生成したＰＫＩ公開鍵であり、前記該ロールのロールオブジェクトに記憶された鍵を用いて、該ロールに対して身分認証を行う過程が、「挑戦／応答」の方式でロールに対して身分認証を行う過程を含み、又は、
前記ロールオブジェクトに記憶された鍵がログインパスワードであり、前記該ロールのロールオブジェクトに記憶された鍵を用いて、ロールに対して身分認証を行う過程が、該ロールのロールオブジェクトに記憶されたログインパスワードと、アプリケーションによって提供されたログインパスワードとが一致するかどうかを比較する過程を含む、
ことを特徴とする請求項１８に記載の方法。
ロールの目標オブジェクトに対する権限を解除する過程をさらに含むことを特徴とする請求項１に記載の方法。
前記ロールの目標オブジェクトに対する権限を解除する過程が、
アプリケーションが、目標ロールの目標オブジェクトに対する目標権限の解除を要求するための権限解除要求を送信する過程と、
該アプリケーションの全てのログインしたロールから、該目標オブジェクトに対して権限解除の権限を有するロールを検索する過程と、
目標ロールの該目標オブジェクトに対する権限から該目標権限を削除する過程と、
を含むことを特徴とする請求項２０に記載の方法。
前記目標ロールの該目標オブジェクトに対する権限から該目標権限を削除する過程が、該目標権限にリード及び／又はライト権限が含まれる場合、該目標オブジェクトに対する目標権限に対応する復号化鍵及び／又は暗号化鍵を、目標ロールの権限から削除する過程をさらに含むことを特徴とする請求項２１に記載の方法。
前記文書又は文書ベースにアクセスすることが、該文書又は文書ベース内のオブジェクトの読み取りである場合、前記アクセスが、
アプリケーションが、目標オブジェクトの読み取りを要求するためのオブジェクト読み取り指令を送信する過程と、
該アプリケーションの全てのログインしたロールの、該目標オブジェクトに対する権限を検査し、少なくとも１つのロールが該目標オブジェクトに対してリード権限を有する場合、
該目標オブジェクトに対してリード/ライトのアクセス制御権限が既に設定されたかどうかを検査し、設定されていないとき、ステップ１２）を実行し、設定されたとき、ステップ１３）を実行するステップ１１）と、
該目標オブジェクトの各親オブジェクトから、リード/ライトのアクセス制御権限が既に設定されたオブジェクトを検索するステップ１２）と、
リード/ライトのアクセス制御権限が既に設定された該オブジェクトに対してリード権限を有するロールを選択し、選択されたロールの権限に記憶された該オブジェクトの復号化鍵の暗号文をアプリケーションに送信するステップ１３）と、
アプリケーションが、選択されたロールの秘密鍵で復号化して、復号化鍵を得て返信するステップ１４）と、
返信された該復号化鍵で復号化して、リード/ライトのアクセス制御権限が既に設定された該オブジェクトの対称鍵を得、該対称鍵で復号化して、リード/ライトのアクセス制御権限が既に設定された該オブジェクトのデータを得、復号化されたデータをアプリケーションに返信するステップ１５）とを実行する過程と、
を含むことを特徴とする請求項１に記載の方法。
前記文書又は文書ベースにアクセスすることが、文書又は文書ベース内のオブジェクトの書き込みである場合、該アクセスが、
アプリケーションが、目標オブジェクトの書き込みを要求するためのオブジェクト修正指令を送信する過程と、
該アプリケーションの全てのログインしたロールの、該目標オブジェクトに対する権限を検査し、少なくとも１つのロールが該目標オブジェクトに対してライト権限を有する場合、
該目標オブジェクトに対して、リード/ライトのアクセス制御権限が既に設定されたかどうかを検査し、設定されていないとき、ステップ２２）を実行し、設定されたとき、ステップ２３）を実行するステップ２１）と、
該目標オブジェクトの各親オブジェクトから、リード/ライトのアクセス制御権限が既に設定されたオブジェクトを検索するステップ２２）と、
リード/ライトのアクセス制御権限が既に設定された該オブジェクトに対してライト権限を有するロールを選択し、選択されたロールの権限に記憶された該オブジェクトの暗号化鍵の暗号文をアプリケーションに送信するステップ２３）と、
アプリケーションが、選択されたロールの秘密鍵で復号化して、暗号化鍵を得て返信するステップ２４）と、
返信された該暗号化鍵で暗号化して、リード/ライトのアクセス制御権限が既に設定された該オブジェクトの新たなデータを得、暗号化された該新たなデータで元のデータをオーバーライトするステップ２５）とを実行する過程と、
を含むことを特徴とする請求項１に記載の方法。
文書又は文書ベース内のオブジェクトに対してデジタル署名を行う過程をさらに含むことを特徴とする請求項１に記載の方法。
前記オブジェクトに対してデジタル署名を行う過程が、
該オブジェクトに対して正規化を行い、正規化結果のＨＡＳＨ値を算出して、ＨＡＳＨ値をアプリケーションに送信する過程と、
アプリケーションが全てのログインしたロールの秘密鍵を用いて該ＨＡＳＨ値を暗号化し、署名結果を返信する過程と、
を含むことを特徴とする請求項２５に記載の方法。
前記オブジェクト自身及びその各サブオブジェクトがサブツリーに対応し、
前記正規化が、所定の走査順序に従って、該サブツリーの各ノードの正規化結果を算出して結合し、該オブジェクトの正規化結果を得る過程を含むことを特徴とする請求項２６に記載の方法。
正規化方法であって、
ツリー構造に対して正規化を行うことに用いられ、
所定の走査順序に従って、該ツリー構造の各ノードの正規化結果を算出して結合し、該ツリー構造の正規化結果を得る過程を含むことを特徴とする方法。
前記走査が深さ優先走査又は幅優先走査を含むことを特徴とする請求項２８に記載の方法。
ツリー構造において、あるノードが他のノードを引用した場合、引用されたノードを該引用ノードのサブノードとして、正規化結果を算出するための走査に参加させる過程をさらに含むことを特徴とする請求項２８に記載の方法。
前記各ノードの正規化結果を算出する過程が、
該ノードのサブノード数、類型、及び各属性の、元の値又は変換値を、所定の順序に従って結合して、結合結果の元の値又は変換値を該ノードの正規化結果とする過程を含むことを特徴とする請求項２８に記載の方法。
前記各ノードの正規化結果を算出する過程が、
該ノードのサブノード数、類型、及び各属性の、元の値又は変換値、並びに、サブノード数、類型、及び各属性の、長さの元の値又は変換値のいずれか１つ又は任意の組合せを、所定の順序に従って結合して、結合結果の元の値又は変換値を該ノードの正規化結果とする過程を含むことを特徴とする請求項３１に記載の方法。
前記結合が、直接の結合又はセパレーターでの結合を含むことを特徴とする請求項３１又は３２に記載の方法。
前記変換値がＨＡＳＨ値を含むことを特徴とする請求項３１又は３２に記載の方法。
文書ベースシステムであって、
汎用文書モデルに適合する文書又は文書ベースへのセキュリティ管理に用いられ、
前記文書又は文書ベースのロールを作成し、前記ロールに権限を配分するロール管理手段と、
ロールが前記文書又は文書ベースにログインする際、前記ロール管理手段を介して該ロールの身分を認証する身分認証手段と、
該文書又は文書ベースにアクセスする際、前記ロール管理手段と身分認証手段を介して、ログインしたロールの権限を検査するアクセス制御手段と、
を含むことを特徴とするシステム。
アプリケーションと自身だけで持たれるランダムに生成されたセッション鍵を用いて、アプリケーションとの間のセキュリティセッションを確立するセキュリティセッションチャンネル手段をさらに含むことを特徴とする請求項３５に記載のシステム。
前記ロール管理手段が、さらに、既にロールに付与した権限を解除することを特徴とする請求項３５に記載のシステム。
前記ロール管理手段が、さらに、前記汎用文書モデルにおける一部又は全部のオブジェクトに対する権限をロールに配分することを特徴とする請求項３５に記載のシステム。
前記汎用文書モデルにおける一部又は全部のオブジェクトが、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、及びレイアウトオブジェクトのいずれか１つ又は任意の組合せを含むことを特徴とする請求項３８に記載のシステム。
文書又は文書ベース内のオブジェクトを読み取る際、
前記アクセス制御手段が、さらに、全てのログインしたロールの、該オブジェクトに対する権限を検査し、少なくとも１つのロールが該オブジェクトに対してリード権限を有する場合、該オブジェクトの復号化鍵を取得し、該復号化鍵を用いて該オブジェクトのデータを復号化することを特徴とする請求項３５に記載のシステム。
文書又は文書ベース内のオブジェクトを書き込む際、
前記アクセス制御手段が、さらに、全てのログインしたロールの、該オブジェクトに対する権限を検査し、少なくとも１つのロールが該オブジェクトに対してライト権限を有する場合、該オブジェクトの暗号化鍵を取得し、該暗号化鍵で暗号化して得られた新たなデータで元のデータをオーバーライトすることを特徴とする請求項３５に記載のシステム。
前記アクセス制御手段が、さらに、文書ベースオブジェクト又は文書オブジェクトに対して正規化を行い、正規化結果のＨＡＳＨ値を算出し、ログインしたロールの秘密鍵を前記ロール管理手段から取り出し、得られたＨＡＳＨ値を該秘密鍵で暗号化して、署名結果を得ることを特徴とする請求項３５に記載のシステム。
文書データセキュリティ管理システムであって、
文書のセキュリティ管理に用いられ、
前記文書のロールを作成し、文書オブジェクト、ページオブジェクト、又はページオブジェクトのサブオブジェクトに対する権限を前記ロールに配分するロール管理手段と、
ロールが前記文書にログインする際、前記ロール管理手段を介して該ロールの身分を認証する身分認証手段と、
文書にアクセスする際、前記ロール管理手段と身分認証手段を介して、ログインしたロールの権限を検査するアクセス制御手段と、
を含むことを特徴とするシステム。