JP2005141746A - 文書制御システムにおけるオフラインアクセス - Google Patents

Abstract

【課題】文書制御システムにおいてオフラインアクセスを与えるシステム及び技術を提供する。
【解決手段】一般的に、１つの実現例においては、本発明は、クライエントからのリクエストを受取り、且つそのリクエストに応答してクライエントを事前認可して複数のユーザからなるグループに関連する第一鍵であって電子文書内の第二鍵を解読することにより電子文書へアクセスすることをクライエントにおいて使用可能とさせる第一鍵を包含するオフラインアクセス情報をクライエントへ送ることによりそのグループのメンバーとしてユーザによるアクションを可能とさせる、ことを包含している。リクエストを受取る場合に、第二文書に関するアクションを取るためにクライエントからのリクエストを受取ることを関与させることが可能である。
【選択図】 図１

Description

本発明は、例えば、文書制御システムにおけるオフラインアクセス制御等の文書制御に関するシステム及び技術に関するものである。

従来の文書制御システムは、該システムにより確保された文書に対する暗号化鍵を格納し且つ管理するサーバーを包含しており、確保されている文書を開くことが可能となる前に該サーバーへコンタクトすることを必要とすることにより文書に対する永続的な保護を与えている。このようなシステムは、又、その文書が最初にオンライン中に開かれたものである場合には、そのユーザがオフラインにある場合に制限された時間の間クライエントが文書を開くことを可能とするためにクライエント上に暗号文書鍵をキャッシュすることによりオフライン能力を提供している。このようなシステムは、又、文書アクセスを監査する場合に使用するために、オフライン中におけるログ情報をキャッシュすることを包含する文書アクセス情報をログすることが可能なものであった。

従来の文書管理システムは、複数の個人の異なるグループが異なる許可を持つことを可能とする文書に関連する文書許可情報を包含しており、且つ従来の文書ビューイングソフトウエアアプリケーションは、又、文書管理システムフォーマットからソフトウエアアプリケーション、即ち文書管理システムとの各統合に対して必要とされる別個のソフトウエアプラグインによって使用されるフォーマットへ文書許可情報を翻訳すべく設計されているソフトウエアプラグインを包含していた。更に、エクステンシブル・ライツ・マークアップ・ランゲージ（ＸｒＭＬ（商標））が、ＸｒＭＬ規則に準拠する任意のシステムからの資源及び許可を文書ビューイングアプリケーションが理解することを理論的に可能とすべく定義されつつある。

文書を確保するために多数の異なる暗号化技術が使用されている。これらは、個人個人が個々的な文書に対するパスワードを記憶していることを必要とする文書毎に基づく対称的暗号化、及びユーザの単一のパスワードに基づいて複数の文書を解読する能力を提供する結合型非対称的・対称的暗号化技術（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ（ＰＧＰ（商標））暗号化）を包含していた。ネットワークマルチキャスト／ブロードキャストの文脈において、クライエント上に暗号化鍵をキャッシュする種々の暗号化プロトコルも使用されている。多くのソフトウエアプロダクトは、既存のエンタプライズ認証システム（例えば、Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と直接的に統合する。更に、種々のシステムは、又、配布した文書の最も最近のバージョンをユーザが見つけ出すことを可能とするための機能性を提供しており、例えばＴｕｍｂｌｅｗｅｅｄ Ｍｅｓｓａｇｉｎｇ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（商標）があり、それは、電子メールシステムを確保し且つ添付した文書のオリジナルのバージョンがアップデートされる場合に添付文書を有する電子メールの受取人に対して電子メール通知を送ることが可能であり、その場合の電子メール通知は現在の文書へ戻るＵＲＬ（ユニバーサルリソースロケーター）を有している。

本発明は、以上の点に鑑みなされたものであって、上述した如き従来技術の欠点を解消し、例えば、文書制御システムにおけるオフラインアクセス制御等の文書制御に関する改良した技術を提供することを目的とする。

一般的に、１つの側面においては、本発明は、クライエントからのリクエスト（要求）を受取り、且つ複数のユーザからなるグループと関連する第一鍵を包含するオフラインアクセス情報を前記クライエントに送ることにより前記グループのメンバーとしてユーザによるアクションを可能とさせるために前記リクエストに応答して前記クライエントを事前認可するオペレーション（動作）を特徴としており、該第一鍵は電子文書内の第二鍵を解読することにより前記電子文書へアクセスするために該クライエントにおいて使用可能である。クライエントを事前認可する場合に、最後に記録されているクライエント・同期の時間とそのユーザに対するユーザ・グループ情報における最後の変化の時間と比較することが可能である。クライエントを事前認可する場合に、そのユーザに対する現在のユーザ・グループ情報を該クライエントからのそのユーザに対する受取ったユーザ・グループ情報と比較することが可能である。

クライエントは、電子文書内に存在する文書・許可情報に基づいて電子文書に関するアクションを可能とさせることが可能である。オフラインアクセス情報は該電子文書を包含する複数の文書と関連する文書・許可情報を包含することが可能であり、且つクライエントはこれらの文書・許可情報に基づいて電子文書に関するアクションを可能とさせることが可能である。

リクエストを受取る場合に、第二文書に関するアクションを取るためのクライエントからのリクエストを受取ることが可能である。該オペレーションは、又、該クライエントにおけるユーザを認証されたユーザとして検証することを包含することが可能であり、且つ該オフラインアクセス情報は少なくとも１個のユーザ特定鍵、該第一鍵を包含する少なくとも１個のグループ特定鍵、複数の文書と関連する少なくとも１組の文書・許可情報、文書失効リストを包含することが可能である。該少なくとも１組の文書・許可情報は、該第二文書と関連する１つ又はそれ以上のポリシーとすることが可能である。該オフラインアクセス情報は同期優先順位付け情報に基づいて選択された特定の文書と関連する少なくとも１組の文書・許可情報を包含することが可能である。該オペレーションは、又、該クライエントからオフライン監査ログを受取ることを包含することが可能である。

別の側面によれば、本発明は、文書制御サーバーの複数のユーザからなるグループと関連する第一鍵を包含するオフラインアクセス情報を、オンラインである場合に、該文書制御サーバーから受取り、且つ制御サーバーから受取り、且つ、電子文書内の第二鍵を解読するために該第一鍵を使用し且つ該電子文書と関連する文書・許可情報に基づいて該電子文書に関するアクションを支配することを包含するオペレーションを実施することにより、オフラインにある場合に、該電子文書へのアクセスを可能とさせることを包含しているオペレーションを特徴としている。電子文書に関するアクションを支配する場合に、該電子文書から該文書・許可情報を獲得することが可能である。該電子文書に関するアクションを支配する場合に、該電子文書内のポリシー参照を識別し、且つ該文書ポリシー参照に基づいて局所的に維持されている文書・許可情報を獲得することが可能である。

該オペレーションは、又、現在の時間と該オフラインアクセス情報の受取時間との間の差異がサーバー・同期・周波数パラメータを超える場合には、オフラインにある場合に、該文書へのアクセスを阻止することが可能である。該サーバー・同期・周波数パラメータは該文書に対して特定的なものとすることが可能である。該オペレーションは、又、オフライン監査ログを維持し、且つオンラインにある場合に該オフライン監査ログをアップロードすることを包含することが可能である。

別の側面によれば、本発明は、電子文書を暗号化し、且つ該暗号化した電子文書内に文書制御サーバーのアドレスと、文書・許可情報と、該暗号化した電子文書を解読する場合に使用可能な暗号化鍵とを組込むことを包含するオペレーションを特徴としており、該暗号化鍵は該文書制御サーバーにより発生され且つ該文書制御サーバーの複数ユーザのグループと関連している鍵で暗号化される。該暗号化鍵は、該文書制御サーバーにより発生されるセッション鍵とすることが可能であり、且つ該電子文書の暗号化は、文書鍵を使用して該電子文書を暗号化することが可能である。

組込む場合に、該文書鍵及び該文書・許可情報を包含する文書セキュリティペイロードを該暗号化した電子文書内に組込むことが可能であり、該文書セキュリティペイロードは該セッション鍵を使用して暗号化される。該文書セキュリティペイロードは、又、該文書制御サーバーにより割当てられる文書識別子を包含することが可能であり、且つ組込む場合に、該文書制御サーバーと関連する公開鍵を使用して暗号化した該セッション鍵のコピーを該暗号化した電子文書内に組込むことが可能である。更に、該文書・許可情報は、該電子文書自身より小さな粒度のレベルにおいてアクセス許可を特定することが可能である。

別の側面によれば、システムがクライエントリクエストに応答してオフラインアクセス情報をクライエントと同期させる文書制御サーバーを包含しており、該オフラインアクセス情報は１つのグループと関連する第一鍵を包含しており、該第一鍵は電子文書内の第二鍵を解読することにより該電子文書へアクセスするために該クライエントにおいて使用可能である。本システムはそのグループの一人のメンバーとしてユーザによるオフラインにある場合の該電子文書へのアクセスを可能とさせるクライエントを包含しており、該第一鍵を使用して該電子文書内の該第二鍵を解読し且つ該電子文書と関連する文書・許可情報に基づいて該電子文書に関するアクションを支配する。該クライエントはオフラインアクセス情報を同期させるために該文書制御サーバーと周期的にコンタクトするエージェントを包含することが可能である。

該サーバーは、コンフィギュレーション及びロギングコンポーネント、動的にロードされる方法にわたって機能性を提供する内部サービスコンポーネント、及び１つ又はそれ以上のアクセス制御サービスプロバイダーを包含する動的にロードされる外部サービスプロバイダーを具備するサーバーコアを包含することが可能である。本システムは、又、該文書制御サーバーを包含する複数の文書制御サーバーからなるクラスターを具備するビジネスロジック層、及びビュアクライエントと、セキュアリングクライエントと、管理クライエントとを包含するクライエントを具備するアプリケーション層、及びクライエントのリクエストを該文書制御サーバーへ経路付けするロードバランサー（ｌｏａｄ ｂａｌａｎｃｅｒ）を包含することが可能である。

クライエントリクエストは第二文書に関するアクションを取るためのクライエントからのリクエストとすることが可能である。該文書制御サーバーは、翻訳コンポーネントを包含する許可・ブローカーサーバーとすることが可能である。該第二文書は、許可・ブローカーサーバーにより以前に確保された文書とすることが可能であり、且つ該翻訳コンポーネントは、クライエントから受取られるリクエストに応答して、第一許可・定義フォーマットにおける第一文書・許可情報を第二許可・定義フォーマットにおける第二文書・許可情報へ翻訳すべく動作可能である。

該サーバーは、該リクエストに応答して該第二文書と関連する情報を識別すべく動作可能な許可・ブローカーサーバーとすること可能である。該関連する情報は、該サーバーにおいて維持することが可能であり且つ該第二文書と異なるものであり且つそれと関連する第三電子文書を表示することが可能である。該サーバーは、取られるべきアクションを容易なものとさせるために、該第三電子文書に関する情報を該クライエントへ関係付けるべく動作可能なものとすることが可能である。

該サーバーは、該リクエストに応答して、１つ又はそれ以上のデータ処理装置をして認証手順を行わせるオペレーションを実施させるべく動作可能な命令を有するソフトウエアプログラムを獲得し且つ送信すべく動作可能な許可・ブローカーサーバーとすることが可能である。該クライエントは、現在のユーザを識別し且つ該第二文書に関連する現在のユーザ及び文書・許可情報に基づいて該第二文書に関するアクションを制御するために該認証プログラムを使用することが可能である。

本発明は、以下の利点のうちの１つ又はそれ以上を実現するために実行することが可能である。文書制御システムは、例えば文書管理システム、格納システム、認証及びアクセス制御メカニズム等の既存のエンタプライズインフラストラクチャと容易に且つ緊密に統合させることが可能である。該文書制御システムのユーザは、殆どわずらわしさ無しに認可されたアクションを実施することが可能なものとさせることが可能である。クライエントのインストールを最小とさせることが可能であり、且つサーバーにより開始されトランスペアレントなクライエントカスタム化を実施することが可能であり、それによりエンタプライズソリューションを配備するプロセスを容易なものとさせる。更に、該文書制御システムは、複数のプラットフォーム上に配備することが可能であり且つ特定のプラットフォームに対して緊密に結合させるものでないものとすることが可能である。

クライエントの機能性をサーバー上へ押し込むことが可能であり、クライエントアプリケーションの寸法及び複雑性を最小とすることにより簡単化した管理及び配備を可能とさせる。クライエントのオペレーション即ち動作に影響を与える新たな機能性は、複雑なクライエントアップデートを必要とすること無しにサーバーにおいて実現することが可能である。認証システムは、必要に応じて、認証プロセスをクライエント内へプラグインさせることを許容することを可能とする。認証システムは後に開発された認証メカニズムを包含する複数の異なる認証メカニズムと統合させることが可能である。認証システムは、例えば、ある時間期間にわたりログオンチケットをキャッシュすることにより、又はトランスペアレント即ち透過的に再認証することにより、トランスペアレントな認証をサポートすることが可能である。該認証システムはデプロイメント即ち配備を容易化することが可能である。サーバーアドミニストレーターは、ユーザ認証を新たにデプロイされた即ち配備された認証プロセスでコンフィギュア即ち形態特定することが可能であり、且つ該新たな認証プロセスは、認証が行われる場合に、クライエント内へ自動的にプラグインさせることが可能である。該認証プロセスは文書許可及びアクションとは独立的なものとすることが可能であり、従って、既存の文書の配布の性質を考慮する必要性無しに、アクション間において認証を行うことが可能である。

文書制御システムは、制御されるべき文書に対して使用される文書・許可情報の全てを表わすことが不可能な場合のある文書・許可情報のそれ自身の表現で既存のクライエントアプリケーションを使用することが可能である。サーバープラグインは、文書・許可情報タイプ間で翻訳することが可能であり、例えばエンタプライズシステムにおいて存在する場合があるような付加的な文書保護概念を既存のクライエントアプリケーションと共に使用することを可能とする。許可ブローカーサーバーにおける文書・許可情報の動的翻訳及び特定は、高度に多様性があり且つ容易にアップグレード可能な文書制御システムを形成することが可能である。該システムは、容易に後方互換性のものとすることが可能である。何故ならば、該システムは、必要である場合に、全く異なる文書を提供するのみならず許可の古いフォーマットへ翻訳即ち変換することが可能だからである。

文書へアクセスする最初にユーザがオフラインであることが可能なオフラインアクセスモデルを提供することが可能である。ユーザは、単にオフラインにあるという理由でユーザがアクセスに対する許可を有している文書へアクセスすることが阻止されることは必要ではなく、同時に、ユーザは、オンラインにある間にアクセスが拒否された文書へアクセスすることからオフラインにおいて阻止することが可能である。失効が発生される時と該システム内の全てのクライエントに関してそれが効果を発揮する時との間に有界時間を与えることが可能である。更に、ポリシーが修正された時と全てのクライエントがその修正されたポリシーを使用する時との間に有界な時間を与えることが可能である。

アクセスすべき文書の異なるバージョンに関する情報を自動的に送る文書情報デリバリー技術を与えることが可能である。文書は記述されるように文書制御システムへ繋ぐことが可能であり、且つその文書が開かれる場合に、該システムは、その代わりにアクセスされるべき異なる文書に関する情報を関連付けることが可能である。種々のワークフローを定義することが可能である。このようなワークフローは、ユーザが、常に文書の最新版を有することを確保することが可能であり、又はカスタム化したユーザに依存する文書デリバリを提供することが可能である。異なる文書のビューイング即ち見ることをユーザへ提案するか又は強制することが可能であり、又はその文書に依存して両方とすることが可能である。

以下に説明するシステム及び技術は、文書管理に関連してエンタプライズにより使用される場合があるような文書制御システムを実現するために使用することが可能である。本文書制御システムはスタンドアローンシステムとして、又は別のシステムの１つのコンポーネントとして動作することが可能である。本文書制御システムは、文書が何処にあるかに拘わらず、誰が文書を見ることが可能であるか且つその文書について何を行うことが可能であるかを制御することにより永続的な文書のセキュリティを提供することが可能である。本明細書においては、「文書」及び「電子文書」という用語はファイルに格納されている電子的データ及びネットワークを介して受取られる電子的データの両方を包含する１組の電子的データのことを意味しており、それはオペレーティングシステム（ＯＳ）又はソフトウエアアプリケーションのグラフィカルユーザインターフェースにおける単一の文書アイコンとして表わすことが可能である。電子文書は必ずしもファイルに対応するものではない。１個の文書は、その問題の文書の専用の単一のファイル内において、又は１組の関連するファイルにおいて、他の複数の文書を保持する１個のファイルの一部に格納することが可能である。更に、本明細書においては、「周期的」という用語は、時折繰り返されることを意味するものであり、規則的な間隔を必要とするものではない。

説明するシステム及び技術は、例えばポータブルドキュメントフォーマット（ＰＤＦ（商標））文書を包含する多くの異なるタイプの文書と共に使用することが可能である。ＰＤＦ文書はカリフォルニア州サンノゼのアドビシステムズインコーポレイテッドによって始められたフォーマットにある。ＰＤＦ文書は、電子文書の様相を定義することが可能なプラットフォーム独立型文書フォーマットにおける電子文書の１つの例である。この文書フォーマットは、グラフィック、アニメーション、サウンドを包含する多くの異なるタイプのデータを格納することが可能なプラットフォーム独立型格納フォーマットとすることが可能であり、且つ定義された様相は複数のタイプの表示装置に対して定義することが可能であり、最終的なデスティネーションの装置に拘わらずに、その文書の見え方及び感じに関しての制御を文書の発生源に与える。このタイプのフォーマットにある文書をここに説明する技術と共に使用する場合には、結果的に得られるシステムに対して付加的な利点を発生することが可能である。例えば、文書制御システムは特定のソフトウエア開発プラットフォームに結合されていないアーキテクチャを有することが可能であり（例えば、本システムはＪａｖａ及び．ＮＥＴの情報の上でランすべく設計することが可能）、且つ例えばＰＤＦ文書等のプラットフォーム独立型文書を使用することが可能である。従って、本文書制御システムは幾つかのプラットフォームにわたり容易に機能することが可能である。

図１は文書制御システムに対する動作環境を例示したブロック図である。ネットワーク１００が１つ又はそれ以上のクライエント１１０、１つ又はそれ以上のサーバー１２０、且つ１つ又はそれ以上のエンタプライズシステム１３０の間に通信リンクを与える。ネットワーク１００はローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、エンタプライズネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）、及び／又はインターネットを包含する１つ又はそれ以上のネットワーク用プロトコルを使用して通信することが可能なマシンをリンクする任意の通信ネットワークとすることが可能である。クライエント１１０はネットワーク１００を介してサーバー１２０と通信することが可能な任意のマシン又はプロセスとすることが可能であり、且つサーバー１２０はネットワーク１００を介してエンタプライズシステム１３０と通信を行うことが可能な任意のマシン又はプロセスとすることが可能である。更に、クライエント１１０もエンタプライズシステム１３０と通信を行うことが可能である。

エンタプライズシステム１３０は格納システム、認証システム、通信システム、及び／又は文書管理システムとすることが可能である。サーバー１２０は既存エンタプライズシステム１３０及びレバレッジ既存エンタプライズインフラストラクチャと緊密に統合すべく設計することが可能である。例えば、サーバー１２０は、最近合併したばかりの大きな会社において一般的であるように、エンタプライズにおけるユーザ及びグループ情報に対して豊富なサポートを提供することが可能であり、尚このような情報は複数の供給源から来る場合がある。サーバー１２０は押しつけがましさを最小としながら文書セキュリティを提供することが可能であり、本システムを使用することをより容易とし、従って効果的にデプロイ即ち配備させることをより容易なものとさせる。例えば、サーバー１２０は以下に説明するように、例えユーザがオンライン中にその文書を前もってビュー即ち見なかった場合であっても、ユーザがオフライン中に文書をビュー即ち見ることを可能とさせる洗練されたオフラインアクセスメカニズムを提供する文書制御システムを実現することが可能である。従って、本文書制御システムは通常動作期間中に控えめな状態を維持することが可能であり、文書セキュリティの存在をより目立たないものとし、従ってより使用可能なものとさせる。

図２は文書制御サーバー２００の１例を例示したブロック図である。文書制御サーバー２００はコンフィギュレーション及びロギングコンポーネント２２０，２３０を具備するサーバーコア２１０を包含することが可能である。サーバーコア２１０はサーバー２００とコンタクトするクライエントに対してリモートプロシジャーコール（ＲＰＣ）インターフェースを提供することが可能である。内部サービスコンポーネント２４０はメッソド（ｍｅｔｈｏｄ）２５０にわたり機能性を与えることが可能である。メッソド２５０及び外部サービスプロバイダー２６０を包含するサーバー２００のその他のコンポーネントは、コンフィギュレーションコンポーネント２２０により与えられる情報に基づいて動的にロードさせることが可能である。メッソド２５０は、サーバー２００がクライエントに対してエクスポートする機能性を特定することが可能である（例えば、文書の確保、監査クエリーの実行等）。外部サービスプロバイダー２６０はメッソド２５０に対して使用可能な外部ファシリティ（施設）を特定することが可能である（例えば、データの格納、ユーザの認証等）。

コンフィギュレーションコンポーネント２２０はコンフィギュレーションオブジェクトに対するインターフェースを画定することが可能であり、且つロギングコンポーネント２３０は多様な情報をログ即ち記録するためにサーバー２００により使用されるロギングオブジェクトに対するインターフェースを画定することが可能である。コンフィギュレーションオブジェクトはサーバーコンフィギュレーションファイル（例えば、サーバー２００により読み取られる「．ｉｎｉ」ファイル）とすることが可能であり、且つロギングオブジェクトはログファイル（例えば、テキストファイル）とすることが可能である。一方、コンフィギュレーションオブジェクト及びロギングオブジェクトは標準化されたインターフェース（例えば、ジャバスタンダードＪＭＸ（ジャバ管理拡張）及びｌｏｇ４ｊ）を使用して画定されるローカル又はリモートのオブジェクトとすることが可能である。

サーバーコア２１０により与えられるＲＰＣインターフェースは、クライエントに対するメッソドインターフェースを提供するために使用することが可能であり、クライエントはＲＰＣを各名前付けメッソドとすることが可能であり且つ適宜の組の引数を提供することが可能である。サーバー２００はサーバーメッソドインターフェースをエクスポートし且つサーバー２００がクライエントに対して使用可能とさせるメッソドを画定する１組のメッソドクラスを読取ることによりそれ自身初期化することが可能である。内部サービス２４０はメッソド２５０の全てにわたり使用されるサーバーの内部コンポーネントとすることが可能である。これらは静的に画定することが可能であり及び／又はメッソドの従属関係として動的にロードさせることが可能である。内部サービス２４０は暗号コンポーネント、文書セキュアラー（ｓｅｃｕｒｅｒ）プロセス、及びアクセス制御評価及び作成インフラストラクチャを包含することが可能である。

サーバー２００がクライントへエクスポートするメッソドは、エンタプライズシステム環境のバックエンドインフラストラクチャに依存する実現の場合に付加的なサービスに依存する場合がある。外部サービスプロバイダー２６０はメッソド２５０とそれらの実行環境との間の接続を特定する１組のサービスプロバイダーインターフェースを画定することが可能である。初期化されると、サーバー２００はこの環境に対して必要とされる１組のサービスプロバイダーをロードし且つ初期化することが可能である。外部サービスプロバイダー２６０はデフォルトの実現例を包含することが可能であり且つ付加的な実現がなされる時間にわたり付加させることが可能であり、包含されたサービスプロバイダーインターフェースを使用して、異なるバックエンドインフラストラクチャに対して調整することが可能である。

例示的なサービスプロバイダーについて以下に説明するが、付加的な又は代替的なサービスプロバイダーも可能である。サービスプロバイダーの定義は、サービスプロバイダーが実現するインターフェースにより与えられる。これらのインターフェースは、それらが多様なシステムにわたり実現することが可能であるように包括的に定義することが可能である。従って、システムの境界を横断する情報は、種々のシステムに関する実現においてより大きな柔軟性を与えるために単純な用語で定義することが可能である。

認証サービスプロバイダーはユーザを認証するために使用することが可能である。コンピュータセキュリティの文脈において、認証は、プログラム可能なマシンが別のマシン、及び／又はそれから通信が受取られている他のマシンの現在のユーザの同一性を確認する手順である。認証を使用することが可能な多くのタイプのシステムが存在しており、且つ特定の実現例の必要性に依存して認証プロセスをトリガすることが可能な多くのタイプのイベントが存在している。本明細書に記載する認証システム及び技術は、説明した文書制御システムにおいて、又はその他のシステムにおいて使用することが可能である。

図３は認証システムにおけるワークフローを例示したブロック図である。クライエント３１０はネットワーク３００を介してブローカーサーバー３２０と通信的に結合させることが可能である。クライエント３１０が認証されたユーザを有することに依存するアクションを取ることが必要である場合には、クライエント３１０はブローカーサーバー３２０へリクエスト３５０を送ることが可能である。例えば、クライエント３１０が文書３０５に関してアクションを取ることが必要である場合には、クライエント３１０はリクエスト３５０を送ることが可能である。リクエスト３５０は、サーバー３２０に対して、そのアクションに関連して使用するために、現在認められている認証プロセスに関するアップデートがクライエント３１０により期待されていることを表示することが可能である。リクエスト３５０はそのアクション及び／又はクライエント３１０に対して局所的な位置内に既に存在する１つ又はそれ以上の認証プロセスを表示する情報を包含することが可能であり、且つサーバー３２０は、受取った情報に基づいて、クライエント３１０により使用するための認証プロセスを送ることによりクライエントのリクエストに応答するか否かを決定することが可能である。

更に、リクエスト３５０はクライエント３１０とサーバー３２０との間の複数の通信を表わす場合がある。クライエント３１０は、最初に、そのアクションがリクエストされたことをサーバー３２０へ通信することが可能であり、且つクライエントは認証が実施されるべきか否か、且つそうである場合には、どのようにして認証が実施されるかを知ることをリクエストする。サーバー３２０及び文書３０５を識別する情報は文書自身の中に包含させることが可能であり、且つサーバー３２０は、文書３０５及びリクエストされたアクションの性質を識別する情報に基づいて、ユーザ認証が必要であるか否かを決定することが可能である。サーバー３２０は、認証が必要であるか否か、且つそうである場合には、クライエント３１０がどれを使用するかを選択することが可能な潜在的に複数のタイプの許容可能な認証メカニズムを包含する使用すべき認証のタイプに関して応答することが可能である。クライエント３１０が、既に、特定した認証機能性を有するものでない場合には、クライエント３１０は対応する認証アップデートをリクエストすることが可能である。

サーバー３２０は専用の認証ブローカーサーバーとすることが可能であり、又はサーバー３２０はその他の資源を提供することが可能である。例えば、サーバー３２０は本明細書に記載したような文書制御サーバーとすることが可能であり、且つ種々のクライエントにより開始されるオペレーション（例えば、文書ビューイング、リボーキング（ｒｅｖｏｋｉｎｇ）及びセキュアリング）は、又、これらのオペレーションの完了がサーバーとコンタクトすることを必要とする場合のあるサーバーに基づくオペレーションとすることが可能であり、このようなクライエントにより開始されるサーバーに基づくオペレーションは、又、動的にデリバーされる認証プロセスを使用して認証をトリガすることが可能である。

サーバー３２０は、認証プロセス３１５を獲得し且つ認証プロセス３１５をクライエント３１０へ送ることによりリクエスト３５０に応答することが可能である。認証プロセス３１５はサーバー３２０によるか又は別のサーバー（例えば、エンタプライズシステム内のサーバー）により格納することが可能である。従って、認証コンポーネントは、サーバー３２０上、及び、オプションとして、別個の認証サーバー上のクライエント３１０において常駐することが可能である。認証は、既存のエンタプライズ認証メカニズム（例えば、パスワードに基づく認証）を使用するため、又は後にデプロイ即ち配備される場合のあるカスタム認証メカニズム（例えば、バイオメトリック認証、又は新たなスマートカードシステム）を実現するためにサーバー３２０を形態特定することを可能とするサービスプロバイダーインターフェースを介して取り扱うことが可能である。認証サービスプロバイダーインターフェースは、サーバー３２０がユーザを認証するために使用するメッソドを定義即ち画定することが可能であり、且つ認証サービスプロバイダーはウインドウズ及びＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）認証用、及び、又、例えばカリフォルニア州プレザントンのデキュメンタムインコーポレイテッドにより提供されているドキュメンタム（Ｄｏｃｕｍｅｎｔｕｍ）（商標）コンテント管理システムにおけるドキュメンタムログインマネージャを使用する認証のような１つ又はそれ以上の文書管理システム用に実現することが可能である。

認証プロセス３１５は、マシンをして認証手順を行わせるオペレーションを実行させるべく動作可能な命令を有するソフトウエアプログラムを表わしている。認証プロセス３１５は受取られるとクライエント３１０の１つのコンポーネントとなることが可能であり、又はスタンドアローンで且つクライエント３１０と通信することが可能である。認証プロセス３１５はカリフォルニア州サンノゼのアドビシステムズインコーポレイテッドにより提供されている例えばアドビアクロバット（商標）ソフトウエア等の文書ビューイングアプリケーションに対するプラグインとすることが可能である。該認証プロセスはサーバー３２０へ認証情報を通信するためにクライエント３１０により提供される既存のインターフェースを使用することが可能である（例えば、文書ビューイングアプリケーションは、以下に更に説明するような認証プロセス３１５と通信を行うセキュリティハンドラーコンポーネント３１０を包含することが可能である）。認証プロセス３１５はクライエント認証ライブラリ（例えば、ダイナミックリンクライブラリ（ＤＬＬ））又はサーバーサービスプロバイダーとすることが可能である。

従って、クライエント３１０はリクエスト３５０をサーバー３２０へ送ることの結果として、新たな認証プロセスでトランスペアレントにアップデートさせることが可能である。従って、認証の特定のメカニズムはコンフィギャラブル即ち形態特定可能であり、且つ認証コンポーネントのエンド・ツー・エンドデリバリはユーザがアップデートに気が付くこと無しに実施することが可能である。アドミニストレーターがある文書に対して使用すべき認証手順を変えると、その文書に関して特定された認証を必要とするアクションを実施せんとする全てのクライエントは新たに特定されたメカニズムを使用して認証することが可能であるように自動的に且つトランスペアレントにアップデートさせることが可能である。認証手順はある文書に関するシーケンシャルなアクションの間で変えることも可能であり、従って、新たなリクエスト３５０は既にデリバーされた文書に関して実施されるべき同一のアクションに対して新たな認証プロセス３１５をデリバーさせることが可能である。

認証プロセス３１５は任意のローカルなハードウエアを必要に応じてインターフェースし且つ制御する（例えば、バイオメトリック認証手順はバイオメトリック読取装置を使用する）クライエント３１０の位置において認証手順を実現することが可能であり、且つ認証プロセス３１５はサーバー３２０に対して認証情報を通信するためにクライエント３１０により提供されるインターフェースを使用することが可能である。認証プロセス３１５は試みられるアクションに依存してマルチレベル及び／又はマルチファクタの認証を包含する多様な異なる認証手順を実現することが可能である。認証プロセス３１５は各リクエストに応答して動的にデリバーさせることが可能であるので、組織体は容易に認証手順を変えることが可能であり、必要に応じて文書制御システムに対して新たなセキュリティ特徴を付加させる。

認証プロセス３１５は入力（例えば、テキスト、バイオメトリックデータ等）についてクライエント３１０におけるユーザにクエリー即ち質問することが可能であり、受取った入力をエンコードし、且つエンコードした入力をサーバー３２０上の認証プロバイダーへ返すことが可能である（例えば、エンコードした入力をクライエント３１０内のセキュリティハンドラー３１７へ送り、それがその情報をサーバー３２０へ転送する）。サーバー３２０は直接的に又は認証サーバー３３０と関連して認証を取り扱うことが可能である。このパススルー認証メカニズムにおいては、クライエント３１０はサーバー３２０に対してクリデンシャル即ち身分証明書を与えることが可能であり、且つサーバー３２０は例えばユーザを認証するためのＬＤＡＰ又はＲＡＤＩＵＳ等のサードパーティ認証システムと共に作業することが可能である。認証が成功すると、認証サービスプロバイダーは認証されたユーザネームを返すことが可能である。

更に、サーバー３２０はクライエント認証情報を直接的に解釈することが可能であることは必要ではない。クライエント３１０がサーバー３２０に対して直接的にクリデンシャル即ち身分証明書を与える代わりに、クライエント３１０は、最初に、認証を行い、次いで、何等かの結果的に得られる情報をサーバー３２０へ供給して、クライエント３１０が前に認証したことをサーバー３２０が再度検証することを可能とさせる。例えば、認証プロセス３１５はユーザを直接的に認証するために認証サーバー３３０とコンタクトすることが可能であり、且つ認証の受領はサーバー３２０へ返すことが可能である。サーバー３２０はその受領を認証サーバー３３０へパスすることが可能であり、且つ実際に認証が成功したことを検証することが可能である。従って、クライエント３１０は別の認証システムへ直接的にクリデンシャル即ち身分証明書を提供することが可能であり、次いで、認証されたトークンをサーバー３２０へ供給することが可能であり、それは別の認証システムでのユーザの同一性即ち識別を検証するために使用することが可能である。

サーバー３２０は複数の認証サービスプロバイダーを使用することが可能である。サーバー３２０は、以下に説明するインターフェースを使用して、必要に応じ、１つ又はそれ以上の認証プロセス３１５をクライエント３１０へ動的にデリバー即ち配達することが可能である。このような認証プロセス３１５はクライエント３１０へ確実にデリバーさせることが可能であり、且つソースコードライブラリローディングに関連して以下に説明するように、スプーフィング即ちなりすましを防止することが可能である。クライエント３１０は、又、例えばユーザネーム・パスワードテキストエントリをキャプチャすることが可能な認証ライブラリのような既に使用可能な１つ又はそれ以上のデフォルトの認証プロセスを有することが可能である。このようなデフォルト認証プロセスは認証サービスプロバイダー内のこの情報を抽出するためのユーザインターフェース（ＵＩ）カスタム化及びスタンダードフォーマットに対するサポートを包含することが可能である。更に、クライエント３１０は、ユーザがオペレーションを実施する度にログオンする必要性がないようにある時間期間の間クリデンシャル即ち身分証明書を維持することが可能である。このようなオフラインアクセスをサポートするためにクライエントのクリデンシャル即ち身分証明書を維持することの１つの例は図１１−１４に関連して後に更に説明する。

セキュアコード（ｓｅｃｕｒｅ ｃｏｄｅ）ライブラリローディングは、これらの認証ライブラリがクライエントに関してスプーフィングされること（例えば、トロージャンホースプログラムにより）を防止しながら、ユーザの側で何等のアクション（又は知識）を必要とすることなしに、アップデートを与えるか又はクライエントをカスタム化するためにクライエントに対して１つ又はそれ以上の認証ライブラリ（例えば、ＤＬＬ、ジャババイトコード、ジャバスクリプト等）をプッシュするために全てのサーバー３２０に対して実現することが可能である。サーバー３２０からダウンロードされた認証ライブラリの真正性を検証するためにあるメカニズムを設けることが可能である。サーバー３２０が認証ライブラリをクライエントへプッシュする場合に、サーバー３２０はそのライブラリのハッシュを計算し且つこのハッシュをクライエント３１０へ送ることが可能であり、及び／又はサーバー３２０はそれをクライエントへ送る前にその認証ライブラリに署名することが可能である。そのハッシュはクライエントにおいて局所的に維持することが可能であり、且つクライエント３１０はその認証ライブラリのハッシュを計算し且つロード時間においてそれを維持されている値に対して検証させることによりその認証ライブラリが有効なものであることを確かめることが可能である。更に、選択された組のライブラリをプロバイダーにより署名させることが可能であり、又は全てのライブラリをプロバイダーにより署名させることが可能であり、且つプロバイダーの公開鍵をクライエント３１０において維持することが可能である（例えば、ＤＬＬは、アドビ公開鍵が包含された状態で、クライエント３１０がアドビアクロバットソフトウエアである場合に、アドビにより署名することが可能である）。

図４はサーバーにより使用される認証技術を例示したフローチャートである。ある文書に関してアクションを取るためのリクエストが４００において受取られる。このリクエストに応答して、認証プロセスが４１０において獲得される。その認証プロセスは４２０においてクライエントへ送られ、現在のユーザを識別し且つ該電子文書に関連する現在のユーザ及び文書・許可情報に基づいてその電子文書に関するアクションを制御する場合に使用される。従って、該認証メカニズムはサーバー上で特定することが可能であり、且つ適宜のコードをクライエントに対してトランスペアレントな態様で、必要に応じて、動的にクライエントへダウンロードさせることが可能である。

認証インターフェースはテキストに基づいたユーザネーム・パスワード記述化又は単一認証ライブラリのいずれかを与えることが可能である。このことは、認証用の２つのタイプのメッソドを使用して実現することが可能である。第一のメッソドはユーザネームのみならず不透明なトークン（例えば、途切れのないバイトストリング）を取ることが可能であるが、その実現例はいずれかを無視すべく選択することが可能である。第二のメッソドは、ユーザネーム、パスワード、及び、オプションとして、所望により「ドメイン」又は「接続ストリング」を特定することが可能な第三引数を取ることが可能である。認証プロバイダーはブルートフォースアタックに対しそれ自身の防御を実現することが可能であり、且つ正しいクリデンシャル即ち身分証明書が定義される場合であっても認証を拒否するオプションを有することが可能である。

実現例は、又、ユーザの認証が成功したか（検証された）否かを特定する認証応答を返すことが可能である。検証が誤りである場合には、何故それが検証されなかったかを表わす付加的なエラーメッセージ（例えば、このようなユーザは存在しない）を返すことが可能であり、このエラーメッセージはクライエントへ返すことは必要ではないが、サーバー上にログ即ち記録させることが可能である（認証システムを破壊するために使用することが可能な有用な情報をクライエントへ与えることがないように）。将来の認証試みにおいて使用すべきトークンも返すことが可能であるが、サーバーはこれを無視することが可能である。サーバーが誰が認証したかを理解することが可能であるように検証された試みに対してユーザネームも返されるべきである。アクセス制御リスト（ＡＣＬ）サービスプロバイダーはこのユーザネームを取り且つそれをカノニカライズ即ち正規化することが可能であるべきである。ユーザネームの正規化形態はワークフローにわたり一貫性を持って使用することが可能であり、且つ該システム内の正規化形態を支配する定義はインプリメンテーション即ち実現例と共に変化することが可能である。

クライエントは複数のメッソド即ち方法を介して認証することが可能であるので、サーバーはデフォルトによりどのようにしてクライエントが認証すべく試みるべきであるか、又は認証が失敗した場合には次にどのメッソドで試みるべきかを記述することが可能であるべきである。認証サービスプロバイダーはどのようにして認証を行うべきであるか、例えば、特定のコードライブラリを介して、又はユーザに対して表示されている基本的なテキストエントリダイアログを介して行うべきであるかを記述することが可能である。コードライブラリを使用するべき場合には、サーバーはそのコードライブラリに関するメタデータをクライエントへ通信することが可能である（例えば、ＤＬＬの名前、寸法等）。基本テキストエントリダイアログを使用する場合には、サーバーは、そのＵＩがユーザに対してどのように見えるかを特定することが可能であり、例えば、タイトルは「あなたの会社のＬＤＡＰパスワードをエンターして下さい」というべきであり、その場合には、２個のフィールド「ユーザネーム」及び「パスワード」が必要とされるに過ぎない。

説明した認証システム及び技術に加えて、文書制御システム及び技術を提供することが可能である。これらは説明した認証と結合することが可能であり又は別々に使用することが可能である。

図５は文書制御システムにおけるワークフローを例示したブロック図である。クライエント５１０はネットワーク５００を介して許可・ブローカーサーバー５２０と通信的に結合させることが可能である。文書供給源５３０もネットワーク５００を介して許可・ブローカーサーバー５２０と通信的に結合させることが可能である。文書供給源５３０は文書レポジトリー（例えば、文書管理システム又はファイルシステム）及び／又は文書ハンドリング（取り扱い）システム（例えば、電子メールシステム）とすることが可能である。一般的に、文書供給源５３０は２つのタイプのうちの１つと考えることが可能であり、それら２つのタイプとは、（１）文書５４０が維持され且つ将来アクセス可能であることが予定されている文書供給源、及び（２）文書５４０が維持され且つ将来アクセス可能であることが予定されていない文書供給源（然しながら、実際的にはアクセス可能な場合がある）の２つである。

文書供給源５３０が第一のタイプのものである場合には、文書・許可情報５５０を文書供給源５３０において維持することが可能であり且つ必要である場合に許可・ブローカーサーバー５２０へ送ることが可能である。従って、文書・許可情報５５０は許可・ブローカーサーバー５２０において維持することは必要ではない（然しながら、このような情報はサーバー５２０に対して特定された許可・定義フォーマットにおいてサーバー５２０において維持することが可能である）。文書供給源５３０が第二のタイプのものである場合には、文書・許可情報５５０は、文書５４０が確保された文書５４５を作成するために確保される場合に、文書供給源５３０において、許可・ブローカーサーバー５２０において、又はクライエント５１０において発生することが可能であり、且つ文書・許可情報５５０は許可・ブローカーサーバー５２０において維持することが可能である。文書・許可情報５５０は、文書５４０に対して認可されているアクションのタイプを定義するＡＣＬとすることが可能である。更に、文書・許可情報はその文書自身より小さな粒度のレベルにおいてアクセス許可を特定することが可能である（例えば、該文書内の特定の頁、パラグラフ及び／又は単語へのアクセスを制御する）。

セキュアされた即ち確保された文書５４５は許可・ブローカーサーバー５２０により発生される暗号化鍵を使用して暗号化させることが可能であり、且つ確保された文書５４５はサーバー５２０及び文書５４５を識別する即ち同定する情報を包含することが可能である（例えば、サーバー５２０へのリンク及びサーバー５２０のコンテキスト内において一意的な文書識別子）。確保された文書５４５は任意の態様でクライエント５１０へデリバー即ち送ることが可能であり（例えば、電子メール、文書レポジトリーからダウンロード、コンパクトディスク上での受取り）、且つ確保された文書５４５は別の確保された文書（例えば、別の供給源から転送された電子メールへのアタッチメント即ち添付物）のコピーとすることが可能である。

クライエント５１０が確保された文書５４５に関してアクションを取ることが必要である場合には、クライエント５１０は、文書５４５がセキュア即ち確保されていることを判別し、サーバー５２０及び文書５４５を識別即ち同定する情報を抽出し、且つそのアクションに対応し且つ文書識別情報を包含するサーバー５２０へのリクエスト５１５を送ることが可能である。このリクエストに応答して、許可・ブローカーサーバー５２０は文書・許可情報５５０を第二の文書・許可情報５５５へ翻訳即ち変換することが可能である。この第二の文書・許可情報５５５はクライエント５１０における文書５４５に関してのアクションを支配するためにクライエント５１０へ送ることが可能である。クライエント５１０はカリフォルニア州サンノゼのアドビシステムズインコーポレイテッドにより提供されているアドビアクロバット（ＡＤＯＢＥ ＡＣＲＯＢＡＴ（商標））ソフトウエアのような文書ビューイングアプリケーションとすることが可能であり、且つ文書５４５はＰＤＦ（商標）文書とすることが可能である。

図６は許可・ブローカーサーバーにより使用される文書制御技術を例示したフローチャートである。電子文書に関してアクションと取るためのクライエントからのリクエスト即ち要求が６００において受取られる。このリクエストに応答して、その電子文書に関連する第一文書・許可情報が６１０において識別される。この第一文書・許可情報は第一許可・定義フォーマットにおけるものとすることが可能である。その識別された第一文書・許可情報は６２０において第二許可・定義フォーマットにおける第二文書・許可情報へ翻訳即ち変換される。この第二文書・許可情報は６３０においてクライエントにおける電子文書に関するアクションを支配するためにクライエントへ送られる。

再度図５を参照すると、第一文書・許可情報５５０は第二文書・許可情報５５５において使用される第二許可・定義フォーマットにおいて完全に定義することが可能な少なくとも１つのタイプの許可情報を包含する第一許可・定義フォーマットにおけるものとすることが可能であり、且つこれら２つの組の情報５５０，５５５の間の翻訳即ち変換は、リクエスト５１５と関連する付加的な情報に基づく翻訳即ち変換が関与する場合がある。例えば、第一情報５５０は第二情報５５５において完全に定義することが可能な時間依存性許可情報を包含することが可能である。何故ならば、許可・定義フォーマットは時間の概念を包含するものではないからである。この時間従属性許可情報はそのリクエストの時間を考慮に入れることにより現在のリクエストの制限された目的のために第二文書・許可情報５５５において定義することが可能である。第一文書・許可情報５５５が、リクエスト５１５の時間に関連して、そのリクエストされたアクションが認可されるものであることを表わす場合には、このことは第二文書・許可情報５５５において表現することが可能であり、且つ同様に、第一文書・許可情報５５０が、リクエスト５１５の時間に関連して、そのリクエストされたアクションが認可されるものでないことを表わす場合には、このことは、第二文書・許可情報５５５において表現することが可能である。その後のアクションがリクエストされると、再度その後のリクエストの時間に基づいて翻訳即ち変換を実施することが可能である。

別の例として、第一情報５５０は第二文書・許可情報５５５において完全に定義することが不可能なユーザ依存性許可情報を包含することが可能である。何故ならば、その許可・定義フォーマットはユーザの概念を包含するものではないからである。このユーザ依存性許可情報はユーザ及びグループの両方に基づいた文書制御情報を包含することが可能であり且つクライエント５１０を介して得られたユーザ・識別情報を考慮に入れることにより現在のリクエストの制限された目的のために第二文書・許可情報５５５において定義することが可能である。このユーザ・識別情報は、本明細書の他の箇所において説明した認証システム及び技術を使用して獲得することが可能である。その後のアクションがリクエストされると、新たに得られたユーザ・識別情報に基づいて再度翻訳即ち変換を実施することが可能である。更に、許可・ブローカーサーバー５２０により受取られた複数のリクエストは、サーバー５２０をして文書５４５に関してクライエント５１０において取られたアクションに関連する情報５２５を格納させることが可能である。これらのアクションはユーザネームと関連付けることが可能であり、又、クライエントと関連するネットワークアドレス（例えば、インターネットプロトコル（ＩＰ）アドレス）と関連付けることが可能である（両方共クライエントにより報告されるように且つサーバーにより報告されるように）。リクエストされたアクションは、又、取られたアクションと考えることが可能であり、且つ格納された情報５２５は、以下に更に説明するように、文書５４５と関連する格納されたアクション−取られた情報の監査を発生するためにサーバー５２０により使用することが可能である。格納された情報５２５は、又、サーバー５２０か又は文書供給源５３０のいずれかにおいて実施され及び／又はリクエストされたアクションを包含することが可能であり（例えば、ファイルシステム、文書管理システム等において実施されるアクション）、且つ発生された監査はこの情報を包含することが可能である。

図７は文書レポジトリー７００と統合された文書制御システムにおけるワークフローを例示したブロック図である。許可・ブローカーサーバー７３０はバッチモードにおいて（例えば、サーバー７３０が最初にインストールされる場合）及び／又はコンテントマネージメントシステム（ＣＭＳ）ワークフローにおける１つのステップとしてレポジトリー７００における文書をセキュア即ち確保するために使用することが可能である。セキュアリング即ち確保を行うクライエント７２０はレポジトリー７００から文書７１０を検索することが可能である。文書識別子７１５も検索し且つサーバー７３０へパスすることが可能である。文書識別子７１５はコンテントに関するアクションを制御するためにサーバー７３０により内部的に使用することが可能である。レポジトリー７００がＣＭＳである場合には、文書識別子７１５はＣＭＳ７００において使用される文書識別子とすることが可能であり、且つレポジトリー７００がファイルシステムである場合には、文書識別子７１５はその文書のＵＲＬ（ユニバーサルリソースロケーター）とすることが可能である。

サーバー７３０は、文書・許可情報７４０（例えば、ＣＭＳからのＡＣＬ又はファイルシステムからのファイル許可情報）を獲得するために文書識別子７１５を使用してレポジトリー７００と通信を行うことが可能である。文書許可情報７４０は文書７１０に対して特定的なものとすることが可能であり又は複数文書に対する許可を定義することが可能である（例えば、文書管理システムにより維持されているポリシー、又はファイルシステムにより維持されている１組のファイル許可）。獲得された文書・許可情報７４０は文書７１０に対する初期的ＡＣＬを発生するためにサーバー７３０により使用することが可能である。初期的ＡＣＬ、文書識別子７１５、サーバー７３０により発生された鍵を包含することが可能な１組のデータ７５０は、セキュアリング即ち確保を行うクライエント７２０へ送り戻すことが可能である。クライエント７２０はその１組のデータ７５０を使用して確保された文書７６０を作成することが可能であり、それは文書７１０の暗号化されたバージョンである。この確保された文書７６０は初期的ＡＣＬ、文書識別子７１５、文書７６０の一部としてパッケージ化した鍵を包含することが可能である。

クライエントが第二文書７６０に関してアクションを試みる場合（例えば、文書７６０又はこの文書のいずれかのコピーを開こうと試みる）、文書識別子７１５を該文書から検索し、サーバー７３０へ送り、且つ文書７６０に対する現在のＡＣＬを獲得するために使用することが可能であり、尚、現在のＡＣＬはレポジトリー７００内のその文書の現在の状態を反映する。従って、セキュアされた即ち確保された文書に関して取られるアクションは、文書レポジトリー７００内の供給源文書に対する現在の許可を定義する文書・許可情報に基づいて制御することが可能である。この供給源文書は最初に確保した文書７６０とすることが可能であり、又は、確保された文書がレポジトリー７００へ送り戻されない場合には、その供給源文書はオリジナルの文書７１０とすることが可能である。サーバー７３０は文書・許可情報を格納することが必要ではない。何故ならば、この情報はレポジトリー７００から検索することが可能であり且つ文書７６０へのアクセスが要求される場合に翻訳することが可能だからであるが、サーバー７３０は他の目的のためにその文書・許可情報を格納する場合がある。

図８は電子メールクライエント８００と統合された文書制御システムにおけるワークフローを例示したブロック図である。電子メールクライエント８００は電子メージシステムに対するプラグインとすることが可能であり且つ電子メールに対するアタッチメント８１０を確保するために使用することが可能である。ユーザが電子メールアタッチメント８１０をセキュア即ち確保することを選択する場合に、電子メールクライエント８００はユーザがそのアタッチメントに対して適用することを所望する規則をユーザに対してプロンプト表示することが可能であり及び／又はその規則はその電子メールに対する受取人リストに基づいて自動的に発生させることが可能である。その規則はセキュアリング即ち確保を行うクライエント８２０においてＡＣＬ８３０へ変換させることが可能であり且つ許可・ブローカーサーバー８４０へ送ることが可能である。サーバー８４０はそのＡＣＬを格納し且つ上述した如くに１組のデータ８５０をリターン即ち返すことが可能である。このデータ８５０はセキュア即ち安全なアタッチメント（添付物）８６０を作成するために使用することが可能であり、そのアタッチメントはサーバー８４０において発生させ且つ格納することがコーティングとが可能な文書識別子と、初期的ＡＣＬと、暗号化鍵とを包含している。

クライエントが確保された文書８６０に関するアクションを試みる場合（例えば、文書８６０又はこの文書のいずれかのコピーを開こうと試みる）、該文書識別子は該文書から検索し、サーバー８４０へ送り、且つ文書８６０に対する現在のＡＣＬを獲得するために使用することが可能であり、尚現在のＡＣＬはサーバー８４０内に格納されている文書ＡＣＬの現在の状態を反映する。該電子メールの送信者は、該電子メールを送った後においても、文書８６０に対する現在のＡＣＬを変換させるためにサーバー８４０と相互作用を行うことが可能である。従って、確保された文書に関して取られるアクションを制御することが可能であり、且つ確保された文書が配信された後においても、その文書に関するセキュリティの性質を修正することが可能である。

図５乃至８は文書制御システムにおいて実現することが可能であるようなアクセス制御インフラストラクチャを例示している。図２に関連して説明したサーバーの文脈において、アクセスサービスプロバイダーを実現することが可能であり、その場合に、アクセス制御はアクセス制御リスト（ＡＣＬ）により定義することが可能である。ＡＣＬは本人（例えば、ユーザ及びグループ）に対する許可（例えば、印刷することが可能、見ることが可能等）をマップすることが可能であり、且つその逆に又真である。アクセス制御プロバイダーインターフェースは、これらの本人をワークフローにわたって一貫して使用することが可能な正規形態へマップするためにサーバーにより使用されるメッソドを定義することが可能である。アクセス制御サービスプロバイダーは例えばＮＩＳ（ネットワークインフォメーションサービス）、ＬＤＡＰ、電子メールシステム（例えば、インターネットメーリングリストを取り扱うために主にＵＮＩＸマシン上で稼動する公的なソフトウエアプログラムであるＭａｊｏｒｄｏｍｏ）等の種々のシステムに対して実現することが可能である。更に、このアクセス制御インフラストラクチャは共用ＡＣＬをサポートすることが可能である（例えば、複数の文書間で共用されるべき１個のＡＣＬ、このような共用ＡＣＬはポリシーと呼称される場合がある）。

図９は図２の例に対応する文書制御サーバー９００を例示したブロック図である。サーバー９００は多様な基本的な特徴をサポートすることが可能であり、例えば、（１）アクセス制御−誰が文書にアクセスすることが可能であるか且つどのような許可を有しているかを制御する能力、（２）リボケーション即ち失効−それを最早見ることが出来ないように文書を失効させる能力、（３）満期及び／又は有効期間−その前後においてその文書を見ることが不可能な時間を特定する能力、（４）文書シュレッディング−その文書の暗号化鍵を破壊することによりその文書の満期により文書制御サーバーに関して文書を回復不可能とさせる能力、（５）監査−文書に関して実施されるアクションを監査する能力（例えば、ビューイング、試みられたビューイング等）、（６）オフラインアクセス−オフラインである場合に文書へアクセスする能力、を包含している。更に、アーキテクチャを変化させること無しに特徴を容易に付加させることが可能である。

認証サービスプロバイダー９１０は、本明細書の他の箇所において説明したように実現することが可能であり、且つアクセス制御サービスプロバイダー９３０は説明したアクセス制御インフラストラクチャに影響を与えることが可能である。ＡＣＬは１組のアクセス制御エントリ（ＡＣＥ）及び１組のプロパティを包含することが可能である。ＡＣＬプロパティはＡＣＬ全体（例えば、満期日）へ適用することが可能である。ＡＣＥは本人を規則に対してマッピングすることが可能であり且つ本人、規則、ＡＣＥに対する有効期間を包含することが可能である。ＡＣＬが評価される場合に、それらの有効期間内に存在するＡＣＥのみを考慮することが必要であるに過ぎない。有効期間は異なるユーザ及びグループが異なる時間に文書をビュー即ち見ることが許可されることを可能とする。例えば、ＡＣＥは、「渉外担当職員のみがその公開日前に文書を見ることが出来るに過ぎず、その後には誰でもその文書を見ることが出来る」を特定することが可能である。

規則は１組のプロパティ及び認められた及び拒否された許可を包含することが可能である。これらの許可は定義されたビューイングクライエントアプリケーション（例えば、アドビアクロバット（商標）ソフトウエア）及び／又はサーバーに対して特定的なものとすることが可能である。更に、プロパティのように許可は拡張可能なものとすることが可能であり、従って、ＡＣＬを変化すること無しに新たなものを付加することが可能である。

サーバー９００は何等の外部的なＡＣＬメカニズムを使用すること無しに、セキュアリングクライエント（Ｓｅｃｕｒｉｎｇ Ｃｌｉｅｎｔ）インターフェースを使用してアクセス制御リストをユーザが特定することを可能とするそれ自身の簡単なメカニズムを有することが可能である。更に、サードパーティＡＣＬ／権利仕様はサーバー９００によって使用される内部的なＡＣＬフォーマットへ翻訳即ち変換させることが可能である。サーバー９００は他のシステムのアクセス制御ファシリティ（例えば、文書管理システム、データベースシステム、ファイルシステム等）と統合することが可能であり、これらのシステムにおける機能性にレバレッジを与える。

サーバー９００は不完全な情報を包含する場合のある多様なユーザ及びグループレポジトリーと統合することをサポートすることが可能であり、且つサーバー９００はカノニカル（正規）ユーザ中心的な態様でこの情報へ効率的にアクセスすることを可能とさせることが可能である。サーバー９００及びクライエント９８０の両方の上でＡＣＬを操作するためのファシリティ即ち設備を設けることが可能である。サーバー９００は、サーバーを基礎にした文書セキュアラー（ｓｅｃｕｒｅｒ）９６０か又はクライエントを基礎とした文書セキュアラー９９０のいずれかを使用して、文書がセキュア即ち安全確保される前にＡＣＬが有効なものであることを確保するためにＡＣＬを検証することが可能である。ＡＣＬは拡張可能なものとすることが可能であり且つ不透明なサードパーティ許可を許すことが可能である。更に、文書のセキュアリング即ち安全確保はサーバー９００へ接続されてオンライン態様で行うことが可能である。何故ならば、サーバーはＡＣＬを検証することが可能だからである。

サーバー９００はどの本人（例えば、ユーザ及びグループ）がある文書に対してどの許可を有しているかを特定するためにＡＣＬを文書と関連づけることが可能である。本人は複数の名前を有することが可能であるが、本人は、又、区別されたカノニカル（正規）名前を有するべきである。サーバー９００のタスクのうちの１つは、ある本人の種々の名前をそのカノニカル（正規）名前へ変換することが可能なことである。許可及びプロパティの両方が認可されたオペレーションを記述することが可能であるが、許可はブール型の値とすることが可能であり且つプロパティは多様なタイプのものとすることが可能である。許可は、明示的に認められており且つ明示的に否定されていない場合に認めることが可能であり、宣言されていない許可は暗示的に否定することが可能である。

各文書は単一のＡＣＬと関連付けることが可能である。典型的に、この関係は１：１とすることが可能であるが、ポリシーの場合にはこの関係はＮ：１とすることが可能であり、その場合には、複数の文書が同一のＡＣＬを共有する。電子文書ファイルはセキュアリング即ち安全確保の時までのＡＣＬの不変のスナップショットを包含することが可能である。サーバー９００は、又、最も最近のＡＣＬのコピーを維持することが可能であり、それは認可された個人により修正することが可能である。サーバー９００はＡＣＬが使用される前にそれらを正規化することが可能である（例えば、全ての本人の名前をそれらのカノニカル即ち正規形態へ変換する）。このことは、ＡＣＬが作成されるか又は修正される場合には何時でも行うことが可能である（例えば、セキュアリング即ち安全確保の時において、又はＡＣＬ定義が変化される場合）。ＡＣＬがカノニカル即ち正規形態になると、それはクライエント９８０及びサーバー９００の両方に関するＡＣＬを評価することを一層簡単なものとすることが可能である。何故ならばグループ内のメンバーであることの決定及び特定の認可されたユーザに対する関連する権限の決定は基本的なストリングマッチングを介して行うことが可能だからである。

特定の時刻における特定のユーザに対するＡＣＬのサーバー側評価（例えば、オンラインビューイング、失効、文書監査検索等のため）はサーバー９００内において直接的に実行することが可能である。サーバー９００は、現在有効であり且つ認可されたユーザ又は彼女又は彼がメンバーであるグループのいずれかを包含するＡＣＥを探すことによりＡＣＬを検査し、次いで、許可及びプロパティを抽出することが可能である。サーバー９００内の正規化を取り扱うためのサーバーインフラストラクチャは３つの層を有することが可能である。第一層は非正規化本人をそれらの正規化形態へマッピングするサーバー９００内のメモリ内キャッシュとすることが可能である。第二の永続的なキャッシュは正規化マッピング及びグループ内ユーザ情報を格納することが可能であり、このキャッシュは潜在的に複数のサーバー９００にわたり使用することが可能である。第三層はアクセス制御サービスプロバイダー９３０とすることが可能である。

アクセス制御サービスプロバイダー９３０は何等かの組の非正規化ストリングの正規化形態を与える１組の主要なモジュールを包含することが可能である。それらの主要なモジュールは、正規化形態が正規化グループ又は正規化ユーザに対応するか否かを特定することが可能である。然しながら、そのアーキテクチャは、特定の主要なモジュールが一般的に全ての答えを知っていること、又は特定の非正規化ストリングに関して完全な答えを与えることが可能であることを仮定することは必要ではない。ユーザ及びグループレポジトリーのコンテキスト即ち文脈内において複数の専門分野をサポートするために、各主要なモジュールはその分野に関してそれがオーソリティである分野を公表することが可能である。サーバー９００内において直接的に実行することが可能な正規化プロセスは非正規化形態を取り且つリターンされる値が正規化であることを宣言するまでオーソリティを有するモジュールにクエリー即ち質問することによりそれを反復的に洗練させることが可能である。

サーバー９００におけるメッソド９７０は認証されたユーザ中心的なものとすることが可能である。何故ならば、典型的な筋書きは、サーバー９００が、彼女又は彼がどのグループにいるかを考慮しながら特定のユーザがあるオペレーション即ち動作を実施するための許可を有しているか否かを決定することが関与するからである。多くのサードパーティグループメカニズムは「あるグループのメンバーは誰か？」によってアクセス可能なグループメンバーシップを組織化するものであり、「どのグループが特定のユーザを包含するか？」によるものではない。更に、多くの場合に、グループは非正規化形態のユーザを包含している場合がある。従って、グループレポジトリーの出力はサーバー９００により直接的に使用可能なものでない場合があり、且つ中間の翻訳即ち変換を使用することが可能である。

グループプロバイダーに対して非常に低い共通点を仮定することが可能である。グループプロバイダーは既知の正規化グループのリストを提供することが可能であるものと予測することが可能である。従って、有効なグループはグループモジュールにより特定された既知のグループの集合内にあるものとすることが可能である。グループモジュールは、又、グループ中心的態様で組織化されたメンバーシップ情報を提供することが可能でありそれは多数の既存のレポジトリーの実現が与えられる場合に効率的なアプローチである場合がある。

サーバー９００はシステム内で後に使用するためにグループ情報をバッチ予備処理する能力を有することが可能である。例えば、１つのグループのサーバー内における１つのサーバーは日毎にこのようなバッチオペレーションを稼動することが可能である。このことはサーバーコアにおいて実行することが可能であり且つ全てのグループの列挙、メンバーの正規化、グループネスティングの検査及び閉包の計算を関与させることが可能である。閉包計算の殆どは格納プロバイダー９２０内とすることが可能である。何故ならば、それはデータベースシステムを使用してこれらのタイプのオペレーションを実施するのに自然だからである。

本人はユーザか又はグループのいずれかとすることが可能である。本人はストリングとして表現することが可能である。グループは本人を包含することが可能である。本人は、評価し且つ主要な正規形態へ還元させることが可能な多数のエイリアス表現を有することが可能である。ユーザ及びグループは複数のドメイン即ち分野のものとすることが可能である。例え文書制御システム統合が電子メールに基づくものでない場合であっても電子メールアドレスにおいて使用されるｎａｍｅ＠ｓｕｂ．ｄｏｍａｉｎ．ｃｏｍフォーマットが関与する表記法を採用することが可能である。更に、正規化形態はどのようなものとすべきかの仕様は一般的なシステムにおいて未定義のものとすることが可能である。何故ならば、この仕様は統合依存性の場合があるからである。特定の統合コンテキスト（文脈）における例は次のような場合がある。「ｈｅｒｂａｃｈ＠ｃｏｍｐａｎｙ．ｃｏｍ」は「ｊｏｎａｔｈａｎ ｈｅｒｂａｃｈ＠ｃｏｒｐ．ｃｏｍｐａｎｙ．ｃｏｍ」及び「ｊｈｅｒｂａｃｈ＠ｃｏｍｐａｎｙ．ｃｏｍ」を包含する多数のストリングに対する正規化形態であり、同様に、「ａｔｇ＠ｃｏｍｐａｎｙ．ｃｏｍ」は「ａｔｅ＠ｓｅａ．ｃｏｍｐａｎｙ．ｃｏｍ」に対する正規化形態である。

アクセス制御サービスプロバイダーインターフェースは２つのサブタイプに分割することが可能な本人プロバイダーを包含することが可能であり、これら２つのサブタイプとはユーザモジュール及びグループモジュールである。これらのモジュールの目標は、正規化情報及びグループメンバーシップ情報を提供することが可能なことである。本人プロバイダーは、本人を出来る限り正規化形態へ翻訳即ち変換することが可能である。本人プロバイダーは、リターンされた値が正規化形態にあるか否か、それがグループ又はユーザとして知られているか否か、及びリターンされた結果が何時までキャッシュ内において有効なものと考えることが可能であるかを表示することが可能である。本人プロバイダーは１組の通常表現定義として特定されたオーソリティ分野を有することが可能であり、且つグループプロバイダーはそのオーソリティ分野内においてそれが知っている全てのグループを列挙することが可能である。

種々のサーバーメッソド９７０をサポートするためにユーザ及びグループ情報を論理的に供給することが可能である。何故ならば、このような情報の複数の供給源が存在する場合があるからである。従って、幾つかのユーザモジュール及び幾つかのグループモジュールが存在する場合がある。ハイレベルから、各自を異なって形態特定することが可能であり、異なるバックエンドシステムとインターフェースとすることが可能であり、且つ多分複数の分野にわたるオーソリティとすることが可能である。更に、異なるモジュールをドメイン（分野）オーソリティとして定義することはエクストラネットのサポートを与えることを助けることが可能である。

本人モジュールのコンフィギュレーション即ち形態特定は、適宜のクラスファイルを記述することが可能である。各モジュールは、又、オーソリティとは何かをコンフィギュア即ち形態特定するためのインフラストラクチャのみならず、例えばコネクトストリングズ（ｃｏｎｎｅｃｔ ｓｔｒｉｎｇｓ）及びプリフェレンシズ（ｐｒｅｆｅｒｅｎｃｅｓ）等の何等かのモジュール依存性コンフィギュレーション情報を有することが可能である。異なる実現例は、又、システムの残部との統合を容易化するために事前処理及び後処理を支配する規則を有することが可能である。

ＡＣＬマネージャ９４０は任意の数の本人プロバイダーをローディングすることに関連するコードを包含することが可能である。図１０は図９からのサーバーの詳細の例を例示したブロック図である。該サーバーはグループメンバーシップ又は正規化マッピング用のＡＣＬマネージャ１０１０により取り扱われる主要なメモリ内キャッシュを有することが可能である。ユーザは一般的なリクエストに対してサービスプロバイダーがコール即ち発呼されることが必要でないようにメモリ内に最近の正規化マッピングを格納することが可能である。

ＡＣＬマネージャ１０１０は、又、クロスメソッド（ｃｒｏｓｓ−ｍｅｔｈｏｄ）コードを包含することが可能であり、且つＡＣＬサービスプロバイダーマネージャ１０２０は格納レベル（例えば、クロスサーバー）キャッシュシングに対してトランスペアレントなインターフェースとすることが可能である。ＡＣＬサービスプロバイダーマネージャ１０２０へのクエリーは、最初に、格納プロバイダー１０３０が必要な情報を有しているか否かをチェックするようにし、且つそれをリターンすることが可能である。そうでない場合には、ＡＣＬサービスプロバイダーマネージャ１０２０はユーザ及びグループモジュール１０４０に対してクエリーを発行し且つ格納レイヤーへ出来るだけ多くの情報を持続することを試みることが可能である。キャッシュエントリはリターンされた正規化結果と関連する満期毎に削除することが可能である（例えば、格納プロバイダーか又は本人モジュールのいずれかにより特定される如く）。

再度図９を参照すると、格納サービスプロバイダー９２０は、永続的な格納部においてデータを作成し且つ検索するために使用するモジュールの集合を記述するインターフェースを提供することが可能である。このインターフェースはシステム内の最大のサービスプロバイダーインターフェースである場合があり且つ文書制御システム内に新たな統合及び特徴が実現される場合に更に成長する場合がある。格納サービスプロバイダー９２０は以下のエリアにおいてメッソドを提供することが可能である。即ち、（１）文書チケットの割当て−サーバー上に確保されている各文書はＧＵＩＤ（グローバルユニークアイデンティファイア）を具備するチケットが与えられる場合がある、（２）文書失効の記録、（３）ユーザ、グループ、文書、ルートサーバー鍵に対する暗号化鍵の保存、（４）ユーザエイリアス及びグループメンバーシップデータのキャッシュ、（５）ユーザアクセス及びセキュアリングの監査、（６）名前付きＡＣＬ又はポリシーの管理及び格納、（７）文書に対する現在のＡＣＬの格納及び検索、（８）文書に対する初期的ＡＣＬの作成等である。

格納プロバイダーインターフェースは、多様なバックエンドシステムにわたり複数の実現例を可能とさせるべく設計することが可能である。このことは、ＯＤＢＣ及びＪＤＢＣの両方と共に作業を行うことが可能な汎用リレーショナルデータベース実現例を使用して行うことが可能である。更に、格納プロバイダーインターフェースは、Ｄｏｃｕｍｅｎｔｕｍ（商標）システム等のコンテント管理システムに対する実現例をサポートすべく設計することが可能である。チケット発生は簡単明瞭なものである場合がある。例えば、このことは、各予約毎にインクリメントされるデータベース内の整数を有することにより実現することが可能である。文書失効は、そのチケットに基づいてある文書を失効させ且つ与えられたチケットと関連する文書が失効されか否かを別にクエリー即ち質問する能力として定義することが可能である。格納プロバイダーは、又、名前により任意のバイトアレイとすることが可能な鍵を格納し且つ検索することが可能である。

格納プロバイダーは、又、ユーザエイリアス及びグループメンバーシップデータに対する格納を提供することが可能である。エイリアス及びメンバーチップ情報は、アクセス制御リストを評価するために使用することが可能であり、格納プロバイダー９２０は、例えアクセス制御サービスプロバイダー９３０がこの情報への効率的なアクセスを提供することが可能でない場合であっても、妥当な性能を確保することを助けるためのキャッシュとして使用することが可能である。例えば、制限的な場合において、アクセス制御情報は所要のデータを与えるフラットファイルから来る場合がある。ユーザ及びグループエイリアス情報をキャッシュする場合に、格納プロバイダーは、ユーザ及びグループプロバイダーのように、本人に基づいてクエリーの検索を実施することが可能である。リターンされるデータは同一のフォーマットのものとすべきであり、又有効性の評価を与える。その目標は、サーバーがユーザエイリアス又はグループメンバーシップデータを使用する場合には、提供されたデータが実時間であるか又はキャッシュされたバージョンであるかをサーバーが区別すべきものではないようにすることとする場合がある。

与えられたユーザ又はグループに対して、そのユーザ又はグループの正規名を得ることが可能である。ユーザの場合には、このユーザが属するグループの全てを得ることが可能である。エイリアスデータに対する変化はすぐさま見ることが可能なものとすることが可能である。グループメンバーシップキャッシュに対する変化は、閉包計算のためにより複雑なものとなる場合がある（グループを包含するグループのグループメンバーシップ）。そのために、グループコンテント変化は、サーバーが現在のところグループの閉包を計算している場合にはすぐさま見ることが可能なものでない場合がある。

文書セキュアリングオペレーション及び文書アクセス試み（成功したか否か）は格納プロバイダー９２０の監査メッソドを介して監査することが可能である。セキュアリング即ち安全確保及びアクセスイベントを記録するためのメッソドを定義することに加えて、該インターフェースは、又、監査履歴に関する２，３のクエリーメッソドを定義することが可能である−文書チケットによる及びユーザによるクエリー。格納プロバイダーは、又、ＡＣＬの作成及び修正を可能とさせるメッソドを実現することが可能である。これらのメッソドは監査履歴情報を維持するために使用することが可能である。格納サービスプロバイダー９２０の複数の実現例を必要に応じて実現することが可能であり、リレーショナルデータベースを使用すること及び／又は監査ログの既存の文書管理システム概念を使用すること（例えば、Ｄｏｃｕｍｅｎｔｕｍ（商標）監査トレールオブジェクト）を包含している。

格納プロバイダー９２０は名前によりＡＣＬを格納及び検索することが可能である。ＡＣＬはプライベートＡＣＬ（例えば、特定のユーザに対して）又はパブリックＡＣＬとすることが可能である。パブリックＡＣＬは種々のユーザによりセキュア即ち確保される複数の文書にわたり共有されることが意図されているポリシーを表わす。ＡＣＬの格納されている表現は格納プロバイダーにとってのみ関心がある場合がある。何故ならば、そのプロバイダー実現例は単にＡＣＬを引数として取り且つＡＣＬを結果としてリターンすべく設計することが可能だからである。ＡＣＬはアクセス制御リストインターフェースにより記述することが可能である。

格納プロバイダーはＡＣＬを作成し、アップデートし、削除し、検索するための１組のメッソドを有することが可能である。これらのメッソドは名前付きＡＣＬ又はポリシー（例えば、パブリックＡＣＬ）のいずれかを記述する引数を取ることが可能である。格納されているＡＣＬを与えられた文書と関連付ける（チケットＧＵＩＤを介し）するためのメッソドも存在することが可能である。与えられた文書をＡＣＬと関連付ける場合に、チケットデータも格納することが可能である。このチケットデータは特定の文書に対して特定的とすることが可能であり且つどの本人がその文書をセキュア即ち確保したかということのみならず何時その文書がセキュアされたかの日付のような文書に特定的な情報を格納するために使用することが可能である。文書間において共有されるＡＣＬは、又、セキュアリングの時間又はその文書をセキュア即ち確保した人に関する制御を特定することが可能である。チケットデータは、又、サービスプロバイダーに対応する情報を提供するためにセキュアリングクライエントにより使用することが可能である。例えば、Ｄｏｃｕｍｅｎｔｕｍ（商標）システム統合においては、チケットデータは供給源文書に対しＤｏｃｕｍｅｎｔｕｍ（商標）ＧＵＩＤを提供することが可能である。サービスプロバイダー情報は、又、サービスプロバイダーに対応するその文書の適宜の情報的側面をキャプチャする１組の名前／値の対を包含するサービスプロバイダーから受取られるバイトシーケンスとすることが可能である。

それらの名前によりＡＣＬを検索するための能力に加えて、該サーバーは、又、特定の文書に対するＡＣＬを検索することが可能である。使用するためにＡＣＬを検索する場合に、該サーバーは、オプションとして、パラメータとして本人（主体）を提供することが可能である。このことはヒントを与え、最適化させた格納プロバイダーがその特定の本人に対して関連性のあるＡＣＬのサブセットをリターンすることを可能とさせる。

ＡＣＬを作成し且つ格納する場合に、セキュアリングクライエントに対して提供されたサービスプロバイダー特定データをパススルーする機会も存在している。このことはどの特定のＡＣＬをこの文書が参照するかに関するヒントをサービスプロバイダーへ与えるためのエンド・ツー・エンドメカニズムを与えることが可能である。このことはチケットデータに関連して上に説明した能力と類似しているが、文書ではなくＡＣＬに対して特定的なものとすることが可能である。

格納プロバイダーはＡＣＬを解釈することは必要ではない。格納プロバイダーは何等解釈を行うこと無しに単純にＡＣＬを格納し且つ検索することが可能である。ある文書が作成されると、それは初期的なＡＣＬを与えることが可能であり、それは該文書内に格納し且つその文書に対するその他のＡＣＬが該クライエントにおいて局所的に存在しない場合にオフラインアクセス制御のために使用することが可能である。格納インターフェースは、これらの現在及び初期的なＡＣＬがサーバーのセキュアリング又はビューイングコンポーネントへ送り戻されるメッソドを提供することが可能である。一般的に、２つの主要な場合が存在しており、即ち（１）セキュア即ち確保されるコンテントが文書制御システム外において何等別のアイデンティティ即ち識別性を有するものでない場合（例えば、そのコンテントが電子メールのアタッチメントである場合）、（２）そのコンテントが文書制御システム外においてアイデンティティ即ち識別性を有している場合（例えば、そのコンテントがＤｏｃｕｍｅｎｔｕｍ（商標）レポジトリー内部の文書のＰＤＦ（商標）レンディションである場合）である。後者の場合においては、サービスプロバイダーはそのコンテントが派生されたオブジェクトに対してレポジトリーが適用する現在の規則によりそのコンテントに対して動的にアクセスを制御することが可能なものとすべきである。更に、ＡＣＬが保存されると、それは所有者により、又はポリシーの場合におけるシステムアドミニストレーターにより修正することが可能である。

初期的な及び現在のＡＣＬの両方が格納サービスプロバイダーにより発生させることが可能であり、且つそのコンテントに対するアクセス制御は、その基礎となるオブジェクトに関するアクセス制御により仲介させることが可能である。そうでない場合には、そのコンテントの管理はオンライン及びオフラインの両方の場合において精密に同一のものである場合がある。更に、ブール型サポートプロバイダーメッソドを提供することが可能であり、その場合にクライエントはどのサービスがサービスプロバイダーによりサポートされているかを判別するために使用することが可能である。従って、クライエントはどのサービスプロバイダーを使用することが可能であるかの期待を有することが可能であり、且つこのサービスが実際にこの文書制御サーバーコンフィギュレーションによりサポートされるかどうかをサポートプロバイダーメッソドから判別することが可能である（例えば、これは、どの組の名前／値の対がチケットデータ内のサービスプロバイダー情報内に合法的に包含させることが可能であるかを判別する）。もしもｓｕｐｐｏｒｔｓＰｒｏｖｉｄｅｒ（）即ちサポートプロバイダーメッソドがあるサービスに対して真である場合には、そのインターフェースの残部を実現すべきである。従って、顧客は文書レポジトリー内のコンテントを保護するため及び電子メールアタッチメントを保護するための両方のために同一のサーバーを使用することが可能である。

サーバー９００は、又、暗号コンポーネント９５０を包含することが可能であり、それは種々の生来的な暗号化コンポーネント（例えば、Ｊａｖａ暗号拡張又は．Ｎｅｔ暗号コンポーネント）を利用する二重の実現例を有することが可能である。一般的に、文書制御サーバーは幾つかの暗号プリミティブを使用する。これらの暗号プリミティブ実現例は一般的なインターフェースの背後に配置させることが可能であり、例えばセキュリティ特徴を付加させること及び／又は特定のエンタプライズの必要性に対処すること等の必要に応じてそのインプリメンテーション即ち実現例を変化させることを可能とさせる（例えば、鍵寸法の変化等）。更に、これらの暗号プリミティブの実現例はカスタムオペレーションのみならず標準的な暗号オペレーションを使用することが可能である。

暗号コンポーネント９５０のインターフェースは以下のプリミティブに対するサポートを提供することが可能であり、即ち、（１）対称的暗号化及び復号化（暗号解読）（例えば、１２８ビットＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）及び／又は１２８ビットＲＣ４（Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ ４））、（２）公開鍵暗号化及び復号化＋署名及び検証（例えば、１０２４ビットＲＳＡ）、（３）文書のインテグリティを与えるために使用されるメッセージ認証コード（ＭＡＣ）（例えば、１２８ビット鍵を有する一方向ＨＭＡＣＳＨＡ１ハッシュ関数）、（４）同一の値（例えば、ＳＨＡ１）へハッシュする２つのメッセージを見つけることは計算的に実現不可能であるセキュアハッシュ関数、（５）暗号鍵を作成し且つメッセージ内にランダム性を導入するために使用される乱数発生（例えば、．Ｎｅｔ実現例に対する．Ｎｅｔフレームワークで与えられるセキュア乱数発生器及びＪａｖａ実現例における乱数発生用のｊａｖａ．ＳｅｃｕｒｅＲａｎｄｏｍクラス）である。これらの暗号プリミティブは、ジャバ暗号拡張（ＪＣＥ）メカニズムを使用してジャバ（Ｊａｖａ）において及び．Ｎｅｔサービスプロバイダーメカニズムを使用して．Ｎｅｔ言語のうちの１つで実現することが可能である。この暗号インターフェース及び暗号インプリメンテーション（実現例）もクライエント上で使用すべきである。というのは、文書制御システムにおけるクライエント及びサーバーの両方がこれらの暗号記述を使用して文書をセキュア即ち確保し且つアクセスすることが可能だからである。暗号インターフェースは、又、Ｃ＋＋で書かれたクライエント上で使用される任意の暗号オペレーションに対してＣ＋＋でインプリメント即ち実現することが可能である。

図１１は文書制御システムにおいて使用することが可能なオフライン文書アクセスモデルを例示したブロック図である。クライエント１１１０はネットワーク１１００を介して文書制御サーバー１１２０と通信的に結合させることが可能である。文書制御サーバー１１２０はマルチオフライン利用モデルを提供することが可能であり、文書が最初にアクセスされる場合にユーザがオンラインでなければならず且つその後に特定した時間期間の間、即ちリース期間の間その文書をオフラインでアクセスすることが可能な従来のオフラインアクセスモデルに類似したリースモデルを包含している。更に、文書制御サーバー１１２０は初期的アクセスモデルを提供することが可能であり、その場合には、ユーザはその文書が最初にアクセスされる場合にオフラインとすることが可能である。本明細書において使用されているように、「オンライン」という用語は、クライエント１１１０がサーバー１１２０と通信することが可能であることを意味しており、従って、クライエント１１１０がオンラインである場合には、クライエント１１１０はネットワーク１１００と接続されており、且つサーバー１１２０が動作可能状態である。

一般的に、クライエント１１１０及び文書制御サーバー１１２０はクライエント１１１０において維持されているオフラインアクセス情報に対する何等かの変化をアップデートさせるために周期的に同期し、その場合にこのオフラインアクセス情報は、クライエント１１１０がネットワーク１１００へ接続されている間に未だにアクセスされていないセキュア即ち確保された文書に関するアクションを可能とさせるためにクライエントを効果的に事前認可することが可能である（例えば、電子メールを介してクライエントにおいて受取られているが未だに開かれていないセキュア即ち確保された文書）。クライエント１１１０はリクエスト１１３０を文書制御サーバー１１２０へ送ることが可能である。リクエスト１１３０はそのオフラインアクセス情報に対するアップデートのためのものとすることが可能である。例えば、サーバー１１２０へ周期的に接続し且つオフラインアクセス情報をダウンロードするクライエント１１１０をエージェントに設けることが可能であり、この同期オペレーションは、クライエント１１１０のユーザがそのアップデートに気が付くこと無しに、バックグラウンドにおいて静かに行うことが可能であり、次回にユーザが文書を開こうと試みると、そのダウンロードされたオフラインアクセス情報はオフラインにある間に将来のアクセスのためにクライエントにより使用することが可能である。

リクエスト１１３０は周期的にサーバー１１２０へ送られる任意のタイプのリクエスト（要求）とすることが可能であり、例えば文書１１３５に間してアクションを取るためのクライエント１１１０からのリクエストとすることが可能であり、その文書はクライエント１１１０又はその他の箇所に位置されているものとすることが可能であり且つセキュア即ち確保された文書かそうでないものとすることが可能である。サーバー１１２０はリクエスト１１３０に関連してクライエント１１１０における認証されたユーザを検証することが可能であり、且つこの認証されたユーザの検証は同期オペレーションを開始させることが可能である。例えば、サーバー１１２０は上述したいずれかのようなサーバーとすることが可能であり、且つ同期オペレーションは認証を使用するその他のオペレーションを利用することが可能である（例えば、ユーザがオンラインにある間に文書へアクセスするか又はセキュア即ち確保すべく試みる場合）。一方、同期は事前の認証無しで発生することが可能であり、サーバー１１２０はそのユーザのみが解読することが可能であるようにそのユーザの公開鍵を使用してオフラインアクセス情報を暗号化することが可能であり、その暗号化されたオフラインアクセス情報はクライエント１１１０により維持させることが可能であり、且つそのユーザが次に文書を開こうと試みる場合に、その維持されている情報を解読し且つ使用して以下に更に詳細に説明するようにそのクライエントのセキュア即ち安全な局所的データベースをアップデートさせることが可能である。

クライエント１１１０がサーバー１１２０と同期する場合に、サーバー１１２０はその現在のユーザが属する複数のユーザからなるグループと関連している鍵１１４５を包含するオフラインアクセス情報１１４０を送ることが可能である（図面中においては１個又はそれ以上の暗号鍵を表わすために１個の鍵の１つの絵が模式的に使用されている）。この鍵１１４５は、電子文書１１５０内の第二鍵１１５５を解読することによりオフライン中にセキュア即ち確保されている電子文書１１５０へアクセスするために使用することが可能である。電子文書１１５０は鍵１１５５で暗号化されているコンテントを包含することが可能であり、且つ電子文書１１５０は鍵１１４５で暗号化されている鍵１１５５を包含することが可能である。一方、この鍵暗号関係において１つ又はそれ以上のレベルの間接化が存在する場合がある。例えば、鍵１１４５は鍵１１５５を暗号解読するために使用することが可能であり、鍵１１５５は文書１１５０のコンテントを解読するために使用される別の鍵を暗号解読するために使用することが可能である。間接化レベルの数及び使用される鍵の数に拘わらずに、複数のユーザからなるグループと関連している鍵１１４５は、電子文書１１５０内の第二鍵１５５を暗号解読することにより、オフライン中に、セキュア即ち確保されている電子文書１１５０へアクセスするために使用することが可能である。更に、オフラインアクセス情報１１４０はその他のグループ特定鍵、１個又はそれ以上のユーザ特定鍵、複数の文書（例えば、上述したようなポリシー）と関連する少なくとも１組の文書・許可情報、及び文書失効リストを包含することが可能である。

同期オペレーションは、又、オフライン中にクライエントにより実施されるオペレーションのオフライン監査ログ１１６０をサーバー１１２０へクライエント１１１０が送り戻すことを関与させることが可能である。従って、クライエントは局所的に維持されている監査ログメッセージをアップロードし且つ最も最近の失効リスト及び何等かのポリシーに対するアップデートをダウンロードするために周期的にサーバーと同期することが可能である。上述したようなＡＣＬを使用するシステムにおいては、そのシステムにおけるＡＣＬの数が大きくなる蓋然性のために、全ての新たなＡＣＬは各同期と共にダウンロードさせることは必要ではない。文書制御システムはデータの新らしさに関して制約された組の保証を与えることが可能である。使用される保証は以下のようなものとすることが可能であり、即ち（１）各文書特定ＡＣＬ及びポリシーがオフライン有効性の期間を特定する（例えば、サーバーとの別の同期が必要とされる前に文書特定ＡＣＬが有効である時間数又は日数であって、その後においては、その文書は同期無しでオフラインにおいて見ることは不可能である）、（２）各同期において、全ての失効及びポリシーのアップデートがクライエントと同期される。従って、ポリシー又は失効リストは、せいぜい、特定の文書に関し日のうちの特定した数の時間単位とすることが可能である。更に、同期は、又、オフライン中にアクセスされる任意の文書に対する現在のＡＣＬを送ることが可能である。

図１２はサーバーにより実施される同期オペレーションを例示したフローチャートである。リクエストが１２００において受取られる。このリクエストに応答して、サーバーは、１２１０においてアップデートが必要とされるか否かを判別する。例えば、サーバーは最後に記録されているクライエント同期の時間をそのユーザに対するユーザグループ情報における最後の変化の時間と比較することが可能であり、又はサーバーはそのユーザに対する現在のユーザグループ情報をそのクライエントからそのユーザに対して受取ったユーザグループ情報と比較することが可能である（例えば、クライエントはその現在維持されているユーザ及びグループ鍵をサーバーに対して識別することが可能であり、且つサーバーはそのクライエントの維持されている鍵に対する何等かの変化が必要とされるか否かに基づいて応答することが可能である）。

アップデートが必要とされる場合には、サーバーは１２２０においてオフラインアクセス情報を送る。このことは、サーバーが、局所的に、除去すべき鍵及び付加すべき鍵のリストをクライエントに送ることを関与させることが可能である。アップデートが必要とされない場合には、サーバーは１２３０において現在のユーザグループ情報のバリレーション即ち妥当性確認を送る。このことは、現在のオフラインアクセス情報が有効であることをクライエントに対して表示し、且つクライエント及びサーバーは現在の時間で同期される。更に、サーバーが１２２０においてオフラインアクセス情報を送るか又は１２３０においてクライエントのオフラインアクセス情報を再度妥当性確認を行う場合には、サーバーは、クライエントにおいて記録され且つクライエント・サーバー同期が将来再度必要とされる時を決定する場合に使用すべくサーバー・参照時間を送ることが可能である。最後に、サーバーは１２４０においてクライエントからオフライン監査ログを受取る。従って、サーバーは上述したように監査を発生することが可能であり、それはオフライン中に文書に関して取られるアクションに関する情報を包含している。

図１３はクライエントにより実施される同期オペレーションを例示したフローチャートである。第一鍵を包含するオフラインアクセス情報が受取られ、且つクライエントが１３００においてネットワークへ接続される場合にオフライン監査ログがサーバーへアップロードされる。クライエントは１３１０においてオフラインアクセス情報を維持する。暗号鍵及びその他の機密情報は、アタッカーがこのような情報に対して容易にアクセスを獲得することが出来ないような安全な態様でユーザのマシン上に局所的に維持させることが可能である。

ニューヨーク州アーモンクのインターナショナルビジネスマシンコーポレイションにより供給される幾つかのラップトップと共に配送されるような例えばスマートカード又は埋込型セキュリティチップ等の改竄防止ハードウエア内に格納される暗号化鍵でファイルを暗号化することによりセキュリティを与えることが可能である。ハードウエアの改竄防止格納装置が使用可能でない場合には、ある程度のセキュリティを与えるためにソフトウエア難読化技術を使用することが可能である。クライエントにおいて維持されているデータはユーザ及びグループのプライベート鍵、文書失効リスト、ポリシーに対するアップデートされたＡＣＬ、オンライン中にクライエントがアクセスした文書に対するアップデートされたＡＣＬ及びセキュリティデータ、オフライン中にクライエントにより実施されたオペレーションのオフライン監査ログを包含することが可能である。

１３３０において、クライエントがネットワークへ接続されていない場合に、文書へのアクセスするためのリクエストが受取られる。判定１３４０において最近のサーバー同期が発生したか否かを判別するためのチェックが行われる。例えば、現在時間とオフラインアクセス情報の受取時間との間の差異がサーバー・同期・周波数パラメータを超えているか否かをクライエントがチェックすることが可能である。サーバー・同期・周波数パラメータはアクセスされるべき文書に対して特定的なものとすることが可能である。更に、現在時間を決定する場合に、最後の既知の同期時間とローカルシステムクロックとの間の比較を関与させることが可能である。

サーバーとの同期が充分最近に発生したものでない場合には、クライエントは１３５０においてその文書へのアクセスを阻止する。充分最近に同期が発生した場合には、１３６０において第一鍵を使用してその文書内の第二鍵を解読する。電子文書に関するアクションは、１３７０においてその電子文書と関連する文書・許可情報に基づいて支配することが可能である。電子文書に関するアクションを支配する場合に、その文書自身から文書・許可情報を得ることを関与させることが可能である。電子文書に関するアクションを支配する場合に、その電子文書における文書ポリシー参照を識別すること、及びその文書ポリシー参照に基づいて、局所的に維持されている文書・許可情報を獲得することを関与させることが可能である。更に、文書アクセス及び試みられた文書アクセスの両方を記録することが可能なオフライン監査ログを１３８０において維持することが可能である。

図１４はセキュア即ち確保された文書１４００のコンポーネントを例示したブロック図である。セキュア即ち確保された文書１４００内には暗号化辞書１４５０を包含させることが可能である。この暗号化辞書１４０５は文書１４００のコンテント即ち内容へアクセスするために使用することが可能な暗号化された鍵、及びオンラインにある場合にコンタクトすべきサーバーのアドレス（例えば、ホスト名、ポート番号、接続プロトコル）を包含することが可能である。この暗号化辞書１４０５はその文書を暗号化するために使用した（即ち、その文書のコンテントを暗号化するために使用した）文書鍵により暗号化されていない位置においてその暗号化された文書１４００内に埋込むことが可能である。

例示的な暗号化辞書１４１０は文書許可情報１４２０（例えば、上述した初期的ＡＣＬ）及び１個又はそれ以上の暗号化した文書鍵１４３０を包含している。文書１４００のコンテントを暗号化するために使用した文書鍵は、グループ鍵及びユーザ鍵を使用して複数回暗号化させることが可能であり、これらの暗号化した文書鍵１４３０はセキュア即ち確保した文書１４００内の暗号化辞書１４０５内に包含させることが可能である。文書制御サーバーは文書制御システムにおけるユーザ及びグループに対してユーザ及びグループ鍵を動的に発生し且つ維持することが可能である。暗号化された文書鍵１４３０及び文書・許可情報１４２０を文書１４００内に包含させることにより、上述した同期オペレーションを使用してクライエントに対して適宜のユーザ及びグループ鍵を与えることによりオフラインアクセスをサポートすることが可能である。

別の例示的な暗号化辞書１４４０は文書鍵１４５０、ＡＣＬ１４６０、文書チケット１４７０、バージョン情報１４８０（例えば、フォーマットバージョンストリング）、暗号化したセッション鍵１４９０を包含している。文書鍵１４５０は文書制御サーバーにより発生され且つその文書のコンテントを暗号化（例えば、ＲＣ４又はＡＥＳ暗号化を使用）してランダムな１２８ビットの鍵とすることが可能である。暗号化辞書１４４０の一部は発生されたセッション鍵を使用して暗号化させることが可能であり、且つ暗号化辞書の修正を検知するためにＭＡＣを使用することが可能である。暗号化されたセッション鍵１４９０はグループ鍵及びユーザ鍵を使用して複数回暗号化したセッション鍵とすることが可能である。更に、セッション鍵はサーバーの公開鍵で暗号化させることが可能である。

ユーザがオフラインで文書を開こうと試みる場合に、その文書に対するセッション鍵がユーザ鍵又はそのユーザがメンバーであるグループのグループ鍵で暗号化されているか否かを判別するためにクライエントがチェックを行うことが可能である。クライエントは、サーバーとの同期期間中に、ユーザの鍵及びそのユーザがメンバーである全てのグループに対する鍵を獲得することが可能である。次いで、適宜の鍵を使用してその文書の暗号化辞書における情報を解読する。次いで、クライエントはサーバー上でＡＣＬが評価されたのと同一の態様でＡＣＬを評価してどのような許可をそのユーザが有しているかを決定することが可能である。クライエントの失効リストをチェックすることが可能であり、且つその文書が失効されておらず且つ満期を過ぎていない場合には、その文書を開くことが可能であり且つその文書に対するユーザのアクセスを局所的に監査することが可能である。

この初期的アクセスモデルは、文書へ最初にアクセスする場合にユーザがオフラインにいることを許容する。文書１４００がセキュア即ち確保されると、その文書に対する初期的ＡＣＬをその文書内に埋込み不変のものとさせることが可能である。ユーザがその文書を開こうと試みる場合に、その埋め込まれているＡＣＬを使用してそのユーザがアクセスを有するか否かを判別することが可能である。文書１４００は、初期的ＡＣＬが文書内に維持されているものであっても、いまだに失効させるか又は満期を過ぎることが可能である。更に、他の箇所に維持されている文書１４００に対する現在のＡＣＬをアップデートさせることが可能であり、且つ上述したように、クライエントがオンラインである場合には、このＡＣＬを使用することが可能である。

ユーザがオンラインで文書にアクセスする場合には、サーバー上に格納することが可能なＡＣＬをクライエント上に維持し且つそのアクセスのために使用することが可能である。維持されているＡＣＬはその文書に対する将来のオフラインアクセスのために使用することが可能である。クライエントがサーバーからアップデートされたＡＣＬを獲得すると、クライエントはその文書にアクセスすることが可能な各ユーザ及びグループの鍵で別個に暗号化されている文書セッション鍵を獲得することが可能である。ＡＣＬ及び暗号化された鍵の両方はその文書内に初期的に埋め込まれているものと同様の態様でセキュア即ち安全確保することが可能である。

更に、その文書における文書許可情報１４２０，１４６０はポリシー、即ち文書ポリシー参照又は識別子を包含することが可能である。従って、クライエントは、オフラインにある間に、電子文書内の文書ポリシー参照を識別することが可能であり、且つその文書ポリシー参照に基づいて局所的に維持されているポリシーの文書・許可情報を獲得することが可能である。全てのポリシーアップデートは各クライエントサーバー同期でクライエント上に反映されることを文書制御システムは保証することが可能であるので、アドミニストレーター即ち管理者はポリシーを変化させ且つ有界な時間量内において、未だに文書に対してアクセスを与えている全てのクライエントに関してその変化が反映されることを知ることが可能である。

上述した初期的オフラインアクセスモデルに加えて、付加的な柔軟性を与えるために、文書制御システム内に従来のリースモデルを使用することも可能である。このモデルにおいては、最初にユーザが特定のマシンからある文書にアクセスする場合には、ユーザはオンラインになければならない。その時に、ユーザはオフラインリースを受取り、それはそのリースが更新されねばならなくなる前に特定した時間期間の間オフラインでその文書をユーザが見ることを可能とさせる。このようなリースモデルは、本人即ち主体に対してアクセスを許可するものでない初期的なＡＣＬを埋込み、且つサーバーから新たなものをフェッチすることが必要となる前にどれ位の間ＡＣＬがクライエント上に維持することが可能であるかを特定するｖａｌｉｄｉｔｙ ｉｎｔｅｒｖａｌ即ち有効期間を使用することによって、説明した文書制御システムにおいて実現することが可能である。更に、本文書制御システムはある文書へアクセスするためにユーザがオンラインでなければならない非オフラインアクセスモデルをイネーブル即ち動作可能とさせるためにコンフィギャラブル即ち形態特定可能なものとすることが可能であり、この場合には、その文書を開くために必要とされる鍵はクライエント上に維持されることは必要ではない。

文書制御システムは、通常、クライエント時間の精度に依存するものであるが、以下のセキュリティ保証の全てを一体的に提供することが可能である。（１）ポリシー修正−全てのポリシーは全ての同期オペレーションにおいて同期されるので、そのポリシーにおいて特定されたｏｆｆｌｉｎｅ ｖａｌｉｄｉｔｙ ｉｎｔｅｒｖａｌ即ちオフライン有効期間内において各クライエントに関しポリシー修正が反映されることが保証されている。（２）ＡＣＬ修正−修正された（非ポリシー）ＡＣＬは、それがオンラインにある間に見られた場合にのみクライエントに関して反映される。維持された非ポリシーＡＣＬは、そのＡＣＬ内において特定されている場合に、ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ即ち有効期間内にクライエントからドロップ即ち捨て去られることが保証されている。（３）失効−失効された文書は、失効が全ての同期オペレーションにおいてクライエントと同期されているので、その文書のＡＣＬにおいて特定されたｏｆｆｌｉｎｅ ｖａｌｉｄｉｔｙ ｉｎｔｅｒｖａｌ即ちオフライン有効期間内においてそのシステムにおける全てのクライエントにより見ることが出来ないものとされることが保証されている。（４）満了−満了した文書は、ユーザがオンラインにあるか又はオフラインにあるかに拘わらずに、満了日に見ることが出来ないものとなる。（５）満了修正−満了はＡＣＬにおいて特定され、従って満了修正はポリシー毎又はＡＣＬ修正毎に反映される。（６）ユーザ又はグループメンバーシップ修正−ユーザ鍵が失効される（例えば、ユーザがその会社を去る）又はそのユーザがグループから除去される場合に、その文書に対するｏｆｆｌｉｎｅ ｖａｌｉｄｉｔｙ ｉｎｔｅｒｖａｌ即ちオフライン有効期間内に対して最早アクセスを有することのない文書をそのユーザが見ることが不可能であることを保証することが可能である。

図１５はサーバーにより使用される文書情報デリバリ技術を例示したフローチャートである。第一電子文書に関してアクションを取るためのクライエントに対するリクエストが１５００においてサーバーにおいて受取られる。このリクエストに応答して、第一電子文書に関する情報が１５１０において識別される。その関連情報は、第一電子文書と関連しており且つそれとは異なる第二電子文書を表示することが可能である。この情報は２つ又はそれ以上の文書を関連付けることが可能であり且つそれらの関係を記述することが可能であり、この関連情報は例えばテーブル又はデータベース内においてサーバーにおいて格納することが可能である。第二電子文書に関する情報は取られるべきアクションを容易なものとさせるために１５２０においてクライエントに関係付けられる。

第二文書情報をクライエントに関係付ける場合に、そのアクションに関して第一及び第二文書のうちの１つを選択することを可能とするためにクライエントへ第二文書情報を送ることを関与させることが可能である。第二文書情報をクライエントと関連付ける場合に、第一電子文書に関する代わりに第二電子文書に関してアクションを取ることを可能とするために、第二電子文書を獲得し且つ第二電子文書をクライエントヘ送ることを関与させることが可能である。この第二文書は既に存在しているか又は全体的に又は部分的に発生させることが必要な場合があり、そのことは第二文書を表示する関連情報によって表わすことが可能である。

図１６は文書制御システムにおけるワークフローを例示したブロック図である。クライエント１６１０はネットワーク１６００を介して文書制御サーバー１６２０と通信的に結合させることが可能である。クライエント１６１０はリクエスト１６３０を文書制御サーバー１６２０へ送ることが可能であり、そこでリクエスト１６３０は文書１６４０に関して取られるべきアクションと関連する。サーバー１６２０は情報１６４５をチェックすることが可能であり、それは局所的に又は他の個所に格納することが可能であり即ち文書１６４０と関連しており且つ第二文書１６５０を表示する。サーバー１６２０は情報１６５５を送ることが可能であり、それは第二文書１６５０及び／又は文書１６５０自身に関する情報とすることが可能である。

クライエント１６１０は情報１６５５に基づいて第二文書１６５０をユーザが見ることを強制させることが可能である。例えば、第二文書１６５０は第一文書１６４０の後のバージョンとすることが可能であり、且つ情報１６５５はそのアクションが第一文書１６４０に関して許可されていないことを特定する文書・許可情報を包含することが可能である。第一文書１６４０は潜在的にユーザの知るところがない場合を包含するクライエント１６１０により第二文書１６５０と置換させることが可能である（例えば、第一文書の代わりに開き及び／又は第一文書上に格納すべく書込む）。第二文書１６５０は第一文書１６４０とは異なる言語バージョン（例えば、オリジナルが英語である場合のフランス語バージョン）又は異なるフォーマットのバージョン（例えば、異なるファイル圧縮及び／又は暗号化方法）とすることが可能である。

サーバー１６２０において第二電子文書１６５０を獲得する場合に、第二電子文書１６５０の少なくとも一部を発生させること（潜在的に全体的な文書１６５０を発生させることを包含する）を関与させることが可能であり、又は文書１６５０は予め存在する文書とすることが可能である。関連情報１６４５はユーザに基づく関連情報を包含することが可能であり、且つ文書１６５０を獲得する場合に、ユーザに基づく関連情報及びクライエント１６１０において識別されたユーザに基づいて文書１６５０を獲得することを関与させることが可能である。文書１６５０は特定のユーザ、そのユーザの位置及び／又はそのユーザのアクセス時間に対してカスタム化することが可能である（例えば、文書１６４０は、送られた場合に既に期限経過したものとして識別されるスタブ文書とすることが可能であり、且つこのスタブ文書が開かれる場合に、各ユーザはアクセスを試みる時にそのユーザに対し特に発生された新たな文書を自動的に受取ることが可能であり、即ちそのスタブ文書はオペレーティングシステムにおいて通常の文書のように見え且つそのように取り扱うことが可能であるが、オンライン中に開かれる場合に常に現在の状態である）。文書１６５０のカスタム化はサーバー１６２０において又はその他の箇所において行うことが可能である。ユーザは上述した如くに識別することが可能であり、且つ文書制御システムは本明細書を介して記載したシステム及び技術を使用することが可能であり、文書１６４０，１６５０は上述したようなセキュア即ち確保した文書とすることが可能である。

図１７はクライエントにより使用される文書情報受取事実を例示したフローチャートである。局所的に維持されている配信された文書が１７００において開かれる。この配信された文書は、上述したようなセキュア即ち確保された文書とすることが可能であり、それはコンタクトすべき文書制御サーバーを識別する。配信された文書から識別制御サーバーは１７１０においてコンタクトされる。該サーバーは、配信された文書が適切な文書であるか否か、又は異なる関連する文書が代わりに使用されるべきであるか否かを判別することが可能である。配信された文書の代わりに第二文書を使用することは、文書制御サーバーから受取った情報に基づいて、文書アクションに関して１７２０において強制される。

従って、文書制御システムは１つのシステムにおいて文書セキュリティ及びバージョン管理の両方の問題に対処することが可能である。配信された文書の異なるバージョンが配信されたバージョンの代わりに見るべきである場合には、このことは配信された文書に対して文書セキュリティを取り扱う文書制御サーバーにおいて定義され且つ制御することが可能である。文書の著者は、文書の配信したバージョンが期限を経過しているものであり且つその代わりにより新しいバージョンを見るべきであることを特定することが可能である。更に、著者は、１つの文書の複数のバージョン及び誰がどのバージョンを見るべきかのユーザに基づく定義を容易に制御することが可能である。

著者又はアドミニストレーター（管理者）は、二人のユーザが異なるコンテントを有する全く異なる文書を受取る可能性を含めてどの文書がどの受取人に対して適切なバージョンであるか、及び両者共元々配信した文書に関連するという意味においてどれが異なる文書バージョンであるかを指定することが可能である。文書間のバージョン関係は、文書セキュリティ目的のために発生される文書識別子を使用して特定することが可能である。このバージョン関係は、各ノードがバージョンである有向グラフを使用して定義することが可能であり、且つ有向エッジはどのバージョンが優先性を有するかを表わす。各エッジもどのユーザに対してそれが適用するかを表わすことが可能である。図を表示させるためのグラフィカルユーザインターフェースを使用してバージョン関係を定義することが可能であり、例えば、ドラッグアンドドロップ操作によりどのバージョンがその他のバージョンの利益となるように期限経過即ち満了となることを特定する。

各文書を改訂することが可能であり且つ各ユーザは文書の最も最近のバージョンのみを見ることを本システムが確保することが可能である場合の文書の異なる逐次的なバージョンの文脈において、文書制御システムにおける失効の考えをある文書が別の文書で置換されたか否かを包含すべく拡張することが可能である。従って、文書を開くと、ユーザがその文書に関して従来のアクション（例えば、印刷等）を実施するためにアクセスを有しているか否かをチェックすることに加えて、そのユーザがその文書の特定のバージョンに対してのアクセスを有するべきであるか否かに関して判別を行うことが可能である。サーバー１６２０は、持続的にバージョン化されている文書を格納することが可能な付加的なレポジトリーサービスを潜在的に提供することを包含して、文書をどこで見つけることが可能であるかの情報を格納することが可能である。

各ユーザが異なるバージョンを見ることが出来る場合には、同様のアプローチを使用することが可能であり、交差するユーザ／グループを特定するための能力を付加する（例えば、「バージョン０の代わりに、全ての従業員はバージョンＡを見るべきである；全てのマネージャはバージョンＢを見るべきである；役員はバージョンＣを見るべきである」、尚付加的なバージョン関係情報は、役員はバージョンＣに加えて従属バージョンＡ及びＢを開くことが可能であることを特定する）。競合を解決するための規則を与えることが可能である。

本明細書に記載したシステム及び技術は、複数の文書制御サーバーを使用する包括的な文書制御システムにおいて結合させることが可能である。再度図９を参照すると、文書制御サーバー９００は説明した種々の技術を結合して実現することが可能である。システムのセキュリティを増加させるために、全てのクライエント・サーバー通信は、セキュリティソケットレイヤー（ＳＳＬ）を介するものとすることが可能であり、それは通信を暗号化し且つサーバー認証を提供し、及び／又は文書のセキュアリング即ち安全確保はクライエント側のセキュアリングを使用して行うことが可能である。サーバー９００はアタッカーから物理的にセキュア即ち安全確保することが可能であり且つ少なくとも１個のファイヤウォールの後ろ側に位置することが可能である。サーバー９００における全ての機密状態情報は、それが安定な格納装置へ持続される前に暗号化させることが可能であり、このために使用される暗号化鍵はサーバーコード内に埋め込むことが可能であり、不明瞭なシステム資源内に隠され及び／又は改竄防止暗号モジュール内に包含させることが可能である。更に、クライエント側において、ユーザのログオンクリデンシャル即ち身分証明をキャッシュさせて、認証を必要とする複数の連続的なオペレーションに対する繰り返される認証を回避することが可能である。キャッシュされたクリデンシャルはサーバープライベート鍵により署名し、この目的のために専用のものとさせ、且つクライエント上に常駐することが可能であり、その署名されたクリデンシャルはその有効期間を制限するために期限日を包含することが可能であり且つクライエントがサーバー９００に対する認証を試みる場合に定義させることが可能である。

上述したように、文書はサーバーにおいて又はクライエントにおいてのいずれかにおいてセキュア即ち確保することが可能である。文書はセキュアリング即ち安全確保の前に１つのフォーマットから別のオーマットへ変換することが可能である（例えば、マイクロソフトワードからＰＤＦ（商標）へ）、文書制御システムはこの目的のためにＰＤＦ（商標）作成サービスと統合させることが可能である。セキュアラー（ｓｅｃｕｒｅｒ）コンポーネント９６０，９９０はＰＤＦ（商標）ライブラリー周りのラッパー（ｗｒａｐｐｅｒ）とすることが可能であり、それは、入力としてＰＤＦ（商標）文書、及び暗号鍵及びＰＤＦ（商標）文書の暗号化辞書内へ埋め込まれるべき情報を表わす１組の名前／値の対を取る。該セキュアラーは提供された暗号化鍵でその文書の暗号化を行い且つ特定した情報をその文書内に埋め込むことが可能である。そのセキュアリング即ち安全確保がサーバー９００上で実施されると、そのセキュアリングは別のプロセスで行うことが可能であり−このようなプロセスのプールは、複数のセキュアリングリクエストを同時に満足させることが可能であるように使用可能に維持することが可能であり、且つこのようなプロセスの最大数はサーバー９００に対するコンフィギュレーションオプションとすることが可能である。これらのセキュアリングプロセスはある数の成功したセキュアリングオペレーションの後に終了させることが可能であり、その数はコンフィギュレーションオプションとすることが可能であり、又はいずれかの不成功なセキュアリングオペレーションの後に終了させることが可能である。

図１８は図９の文書制御サーバーにおける文書セキュアリングワークフローを例示したブロック図である。文書のセキュアリング即ち安全確保は、通常、２つのハイレベルなオペレーションを関与させることが可能であり、即ち、文書のセキュアリングに関連するシステム状態の準備と、関連情報の文書内への埋込及びその暗号化である。状態の準備は、どのようにして文書をセキュア即ち確保すべきかを特定するセキュアリングクライエントと、文書をセキュアリングするためにシステムを準備することが可能なサーバーとの間のジョイントオペレーションとすることが可能である。情報を文書内へ埋込み且つセキュアリングはサーバー上（例えば、暗号化されていない文書をセキュアリングの時にサーバーへ送り、次いで暗号化した形態をクライエントへリターンする）、又はクライエント上（例えば、クライエントが文書を暗号化するのに必要なコンポーネントを有している）のいずれかにおいて行うことが可能である。

セキュアリングクライエントはセキュア即ち確保すべき文書に対する所望のセキュリティの使用を準備することが可能である。このことは、ワシントン州レドモンドのマイクロソフトコーポレイションにより提供されているアウトルック（Ｏｕｔｌｏｏｋ）（商標）ソフトウエアのような電子メールアプリケーションの如きクライエントにおけるエンドユーザインタラクションを関与させることが可能である。クライエントはＲＰＣを介してサーバーへ接続し、認証を行い、且つ情報をサーバーへ送ることが可能である（１８００）。システムがサーバー側のセキュアリングを使用している場合には、クライエントは暗号化されていない文書及びセキュアリング仕様をサーバーへ送る。システムがクライエント側のセキュアリングを使用する場合には、その仕様を送ることが必要であるに過ぎない。

サーバーはユーザを認証することが可能であり、彼が文書をセキュア即ち確保するための許可を有していることを確保する（１８０５）。サービスプロバイダーはその文書に対するチケット（ＧＵＩＤ）を供給することが可能である（１８１０）。アクセス制御リスト仕様をアクセス制御マネージャへ与えることが可能であり、従ってそれは本人即ち主体を正規化させ且つ多分許可を妥当性確認することが可能である（１８１５）、ＡＣＭは、最初に、正規化マッピングのメモリ内キャッシュを使用することを試みることが可能である。格納プロバイダーはその他のキャッシュされた正規化マッピングに対してクエリー即ち質問されることが可能である（１８２０）。本人プロバイダーは全てのキャッシュされていない正規化エントリに対してクエリー即ち質問されることが可能である（１８２５）。正規化されたＡＣＬは格納プロバイダー内に持続させることが可能であり、それによりＡＣＬのその後の修正を可能とさせる（１８３０）。

暗号化され且つ文書内に格納されるべき情報（例えば、チケット及びＡＣＬ）はクリプトサービスプロバイダーへ（Ｃｒｙｐｔｏ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）供給することが可能であり（１８３５）、それはその文書を暗号化するために使用される文書鍵を作成することが可能である。文書シュレッディングが所望されない場合には、文書鍵、チケット、ＡＣＬはサーバー公開鍵を使用して暗号化することが可能である。シュレッディングが所望される場合には、その文書鍵はサーバーを離れるべきではないので、その文書鍵を暗号化すべきではない。システムがサーバー側のセキュアリングを使用している場合には、暗号モジュールからの暗号化されたチケットデータをその文書内に埋込むことが可能であり、且つその文書鍵をその文書を暗号化するために使用することが可能である（１８４０）。システムがクライエント側のセキュアリングを使用している場合には、このことは必要ではない。

本システムは文書がセキュア即ち確保されたことを監査することが可能である（１８４５）。システムがサーバー側のセキュアリングを使用している場合には、暗号化されたファイルをクライエントへリターン即ち戻すことが可能である（１８５０）。そうでない場合には、暗号化されたチケットデータ及び文書鍵はクライエントへリターン即ち戻すことが可能である（１８５０）。システムがクライエント側のセキュアリングを使用している場合には、そのクライエントに関する文書セキュアラーは暗号化されたチケットデータを埋込み且つそのクライエントに関する文書鍵を使用してその文書を暗号化することが可能である（１８５５）。

図１９は図９の文書制御サーバーにおけるサーバー側ＡＣＬ評価ワークフローを例示したブロック図である。サーバーが許可を包含するオペレーションを実施する場合に、サーバーは、最初に、認証されたユーザのアイデンティティ即ち識別を決定することが可能である（１９００）。その文書内の暗号化されたサーバー制御情報を解読することが可能である（１９１０）。暗号化された制御情報におけるチケットは、格納サービスプロバイダーから最も最近の文書ＡＣＬを検索するために使用することが可能である（１９２０）。アクセス制御マネージャはＡＣＬを評価することが可能であり、どの許可が認証されたユーザに対して関連性があるかを決定する（１９３０）。ＡＣＬはグループを参照する場合があり、従って格納プロバイダーは、認証されたユーザがどのグループに属するかを決定するためにクエリー即ち質問されることが可能である（１９４０）。

図２０は図９の文書制御サーバーにおけるオンライン文書ビューイングワークフローを例示したブロック図である。オンライン中に文書のビューイング即ち見ることは、２つの主要なフェーズを関与させることが可能である。第一フェーズは、認証されたユーザがどの許可を有しているかを決定することを関与させ、且つ第二フェーズはクライエント上の文書を解読するために文書鍵をリターン即ち返すことが関与する。文書がオンラインでビュー即ち見るべきである場合には、ビューイングアプリケーションがセキュア即ち確保されている文書を開き且つその文書が制御サーバーと関連していることを認識することが可能である（例えば、その文書はビューイングクライエントにおいてセキュリティハンドラーを関与させることが可能である）。サーバーＲＰＣを使用して、ビューイングアプリケーションは、文書内の暗号化辞書内の暗号化された制御情報をサーバーへ送信することが可能である（２０００）。サーバーは、図１９に関連して上述したように、許可を包含するオペレーションとしてＡＣＬを評価することが可能である（２０１０）。次いで、格納プロバイダーは、この文書が失効されていないことを確保するためにクエリー即ち質問されることが可能である（２０２０）。その文書鍵は制御情報から抽出することが可能である（２０３０）。サーバーはこの文書のオンラインビューイングを監査することが可能である（２０４０）。この文書をビューイングするための規則である最も最近のＡＣＬ、及び文書鍵をビューイングクライエントへリターン即ち返すことが可能である（２０５０）。次いで、このビューイングアプリケーションは許可を実施することが可能である（例えば、セキュリティハンドラーはどの許可を実施するかをビューイングアプリケーションに報告し、且つその文書を見ることが可能であるように暗号解読鍵を提供することが可能である）。

図２１は図９の文書制御サーバーにおける失効ワークフローを例示したブロック図である。クライエントは暗号化した制御情報をサーバーへ送ることが可能である（２１００）。サーバーは、認証されたユーザが、図１９に関連して上述したように、文書を失効させるための許可を有しているか否かを判別することが可能である（２１１０）。次いで、サーバーはその文書を失効させることが可能である（２１２０）。クライエントはアクノレッジメントを受取ることが可能である（２１３０）。

図２２は図９の文書制御サーバーにおける監査イベント検索ワークフローを例示したブロック図である。クライエントはサーバーへ暗号化した制御情報を送ることが可能である（２２００）。サーバーは、認証されたユーザが、図１９に関連して上述したように、この文書に対する監査履歴を得るための許可を有しているか否かを判別することが可能である（２２１０）。格納プロバイダーは、どのイベントがこの文書に対して関連性があるかを決定するためにクエリー即ち質問されることが可能である（２２２０）。次いで、クライエントは監査情報を受取り且つユーザへ表示することが可能である（２２３０）。

図２３はマルチ文書制御サーバー２３６０を具備する文書制御システムを例示したブロック図である。このシステムは、信頼性及びスケーラビリティ即ち拡縮性を与えるために三層アーキテクチャを使用することが可能である。アプリケーション層２３００におけるクライエント２３１０，２３２０，２３３０はビジネス論理層２３５０における文書制御サーバー２３６０と通信を行い、サーバー２３６０は格納層２３７０におけるエンタプライズシステム（例えば、データベース管理システム（ＤＢＭＳ）２３８０）と通信を行う。そのサーバーの特定のインスタンスに対して特定なものではない全てのサーバー状態を第三層２３７０内に格納することが可能であり、従って複数のサーバーインスタンスはこのような状態を共有することが可能である。

複数の文書制御サーバーインスタンス２３６０が使用される場合には、１つがダウンすると、リクエストは他のサーバーへ経路付けさせることが可能である。ロードバランサー（ｌｏａｄ ｂａｌａｎｃｅｒ）２３４０はサーバーインスタンス２３６０に対するリクエストのルーチング即ち経路付けを取り扱うことが可能である。サーバー自身内において、例えばＪａｖａ又は．Ｎｅｔ言語等の管理型コードを使用する言語でサーバーを書くことにより高い信頼性を達成することが可能である。多数の正規及び非正規主体乃至は本人を管理するために、２つのレベルのキャッシュを主体乃至は本人情報に対して設けることが可能である。サーバー２３６０は最近クエリーされた正規ユーザに対する正規マッピング及びグループメンバーシップのメモリ内キャッシュを有することが可能である。多数の文書制御サーバーが格納プロバイダー内に二次的キャッシュを共有することが可能である。

所望の情報がこれらのキャッシュのうちのいずれかの中に存在しない場合には、サーバーはアクセス制御サービスプロバイダー内の直接的本人乃至は主体プロバイダーへ直接的にアクセスすることが可能であり、次いで、局所的に及び格納プロバイダー内においての両方でその情報をキャッシュすることが可能である。グループメンバーシップ情報は、妥当な時間で必要に応じて検索することが可能であるように、バッチ処理されるべきである。二次的サービスとしての文書制御サーバーのうちの１つはマスターに指定することが可能であり且つバッチ処理タスクを実施する責任を有している。多くの場合において、実際のセキュアリングはサーバーへの及びそれからの文書を転送することのオーバーヘッドを取除くため及びサーバーに関するロードを減少させるためにクライエント上で行うことが可能である。同様に、クライエント側のセキュアリングの場合には、クライエントは文書の暗号化を実施することも可能であり、そのことはサーバーのロード即ち負荷を更に減少させる。

この三層アーキテクチャは、サーバーのレプリカを大きなエンタプライズに対してスケーリングするために付加させることを可能とする。文書は、上述したように、特定のホスト名に対しての代わりに複数のサービスからなるクラスターへ繋げることが可能である。ＤＮＳ（ドメインネーミングシステム）ラウンドロビンをシステムへ付加し、付加的なハードウエアが文書制御サーバーとして作用することを可能とさせることが可能である。サーバーは状態を包含することがない場合があり、従ってハードウエアのスケーラビリティ即ち拡縮性の懸念は標準の「１つのデータベース」問題へ還元させることが可能である。本人即ち主体管理に関するアルゴリズムを個々のオペレーションに対するＯ（１）及び集合的オペレーション（バッチ処理等）に対するＯ（ｎ）とすべく設計することが可能である。

本発明及び本明細書において説明した機能的オペレーション即ち動作の全てはデジタル電子回路において、又はコンピュータハードウエア、ファームウエア、ソフトウエアにおいて、又はそれらの結合において実現することが可能である。本発明の装置は、プログラム可能なプロセッサにより実行するためにマシン読取可能な格納装置にタンジブルに実現させたソフトウエアプロダクト（例えば、コンピュータプログラムプロダクト）で実現することが可能であり、且つ本発明のオペレーションの処理は、入力データに関して動作し且つ出力を発生することにより本発明の機能を実施する命令からなるプログラムを実行するプログラム可能なプロセッサにより実施することが可能である。本発明は、データ格納システムからデータ及び命令を受取り且つそれへデータ及び命令を送信すべく結合されている少なくとも１個のプログラム可能なプロセッサ、少なくとも１個の入力装置、少なくとも１個の出力装置を包含するプログラム可能なシステム上で実行可能な１つ又はそれ以上のソフトウエアプログラムで効果的に実現することが可能である。各ソフトウエアプログラムはハイレベル手順又はオブジェクト指向型プログラミング言語において、又は所望により、アッセンブリ又はマシン言語で実現することが可能であり、且ついずれの場合においても、この言語はコンパイル型又はインタプリタ型の言語とすることが可能である。適宜のプロセサは、例示として、汎用及び特別目的の両方のマイクロプロセッサを包含する。通常、プロセッサはリードオンリメモリ、ランダムアクセスメモリ及び／又はマシン読取可能な信号（例えば、ネットワーク接続を介して受取られるデジタル信号）から命令及びデータを受取る。通常、コンピュータは、データファイルを格納するための１つ又はそれ以上の大量記憶装置を包含しており、このような装置は、内部ハードディスク及び着脱自在なディスク等の磁気ディスク、磁気・光学ディスク、及び光学ディスクを包含している。ソフトウエアプログラム命令及びデータをタンジブルに実現するのに適した格納装置は、例示として、ＥＰＲＯＭ（電気的にプログラム可能なリードオンメモリ）、ＥＥＰＲＯＭ（電気的に消去可能プログラム可能なリードオンリメモリ）、フラッシュメモリ装置等の半導体メモリ装置、内部ハードディスク及び着脱自在なディスク等の磁気ディスク、磁気・光学ディスク、ＣＤ−ＲＯＭディスクを包含する全ての形態の非揮発性メモリを包含する。前述したもののいずれも、ＡＳＩＣ（応用特定集積回路）により補充するか、又はその中に組込むことが可能である。

本発明を特定の実施例について説明した。その他の実施例は特許請求の範囲内のものである。例えば、本発明のオペレーション即ち動作は、異なる順番で実施することが可能であり尚且つ所望の結果を達成することが可能である。そのオペレーションはサブスクリプションビジネスモデルを使用してホスト型サービスとして提供することが可能であり、且つインターネットを介して使用可能な通常使用可能なシステムインフラストラクチャと統合させることが可能である。文書バージョン制御技術をピアツーピアシステム及び技術を使用して実現することが可能である。更に、文書に対するパミッション即ち許可の組を異なるワークフローが与えられる文書コンテントに関して種々のアクションをカバーすべく拡張させることが可能である（例えば、ある人のみが１つの文書、又は１つの文書の一部に署名することを可能とさせる許可、及び／又は誰が電子形態の異なるセクションを書込み及び／又は見ることが可能であるかを制御する許可）。

更に、ポリシーアップデートを常に同期させるか必ずしもその他のＡＣＬを同期させるものではないことに対する代替は、システム内のどのＡＣＬが変化したかに関する情報を提供することを関与させることが可能である。同期オペレーションは高及び低優先度オペレーションへ分割することが可能である。高優先度同期はバックグラウンドにおいてより頻繁に発生することが可能であり、且ついつ情報が変化したかの表示を与える。例えば、どのアクセス制御リスト及びポリシーがそのクライエントの最後の同期以来変化したかの表示である。低優先度同期オペレーションはどのようにして情報が変化したかを必要とする場合がある。例えば、このことは、変化したシステム内の全ての文書に対するオフラインアクセス情報を包含する。どのようにしてアクセス制御情報が変化をしたかを同期させることは、何が変化したかの要約よりも通常より資源集約的である。文書に対するアクセス制御が修正され且つクライエントが修正に気が付いているが低優先度同期を実施していない場合には、システムは保守的なものとすることが可能であり且つ低優先度同期が行われるまでインプリメンテーションがその文書へのアクセスを阻止することが可能である。

以上、本発明の具体的実施の態様について詳細に説明したが、本発明は、これら具体例にのみ制限されるべきものではなく、本発明の技術的範囲を逸脱することなしに種々の変形が可能であることは勿論である。

文書制御システムに対する動作環境を例示したブロック図。 例示的な文書制御サーバーを例示したブロック図。 認証システムにおけるワークフローを例示したブロック図。 サーバーにより使用される認証技術を例示したフローチャート。 文書制御システムにおけるワークフローを例示したブロック図。 許可・ブローカーサーバーにより使用される文書制御技術を例示したフローチャート。 文書レポジトリーと統合された文書制御システムにおけるワークフローを例示したブロック図。 電子メールクライエントと統合された文書制御システムにおけるワークフローを例示したブロック図。 図２の例に対応する文書制御サーバーを例示したブロック図。 図９からのサーバーの例示的な詳細を例示したブロック図。 文書制御システムにおいて使用することが可能なオフライン文書アクセスモデルを例示したブロック図。 サーバーにより実施される同期オペレーションを例示したフローチャート。 クライエントにより実施される同期オペレーションを例示したフローチャート。 セキュア即ち確保された文書のコンポーネントを例示したブロック図。 サーバーにより使用される文書情報デリバリ技術を例示したフローチャート。 文書制御システムにおけるワークフローを例示したブロック図。 クライエントにより使用される文書情報受取技術を例示したフローチャート。 図９の文書制御サーバーにおける文書セキュアリングワークフローを例示したブロック図。 図９の文書制御サーバーにおけるサーバー側アクセス制御リスト評価ワークフローを例示したブロック図。 図９の文書制御サーバーにおけるオンライン文書ビューイングワークフローを例示したブロック図。 図９の文書制御サーバーにおける失効ワークフローを例示したブロック図。 図９の文書制御サーバーにおける監査イベント検索ワークフローを例示したブロック図。 複数文書制御サーバーを具備する文書制御システムを例示したブロック図。

符号の説明

１００ ネットワーク
１１０ クライエント
１２０ サーバー
１３０ エンタプライズシステム
２００ 文書制御サーバー
２１０ サーバーコア
２２０，２３０ コンフィギュレーション及びロギングコンポーネント
２４０ 内部サービスコンポーネント
２５０ メッソド
２６０ 外部サービスプロバイダー

Claims (57)

1. クライエントからリクエストを受取り、
   ユーザのグループと関連する第一鍵を有するオフラインアクセス情報を前記クライエントへ送ることにより前記グループのメンバーとしてユーザによるアクションを可能とさせるために前記リクエストに応答して前記クライエントを事前認可し、
   前記第一鍵は電子文書内の第二鍵を解読することにより前記電子文書へアクセスするために前記クライエントにおいて使用可能である、
   ことを特徴とする方法。
2. 請求項１において、前記クライエントを事前認可する場合に、最後に記録したクライエント・同期の時間をそのユーザに対するユーザ・グループ情報における最後の変化の時間と比較することを特徴とする方法。
3. 請求項１において、前記クライエントを事前認可する場合に、そのユーザに対する現在のユーザ・グループ情報をそのクライエントからそのユーザに対して受取ったユーザ・グループ情報と比較することを特徴とする方法。
4. 請求項１において、前記クライエントが、前記電子文書内に存在する文書・許可情報に基づいて前記電子文書に関するアクションを可能とさせることを特徴とする方法。
5. 請求項１において、前記オフラインアクセス情報が、更に、前記電子文書を包含する複数の文書に関連する文書・許可情報を有しており、且つ前記クライエントが前記文書・許可情報に基づいて前記電子文書に関するアクションを可能とさせることを特徴とする方法。
6. 請求項１において、リクエストを受取る場合に、第二文書に関するアクションを取ることのリクエストを前記クライエントから受取ることを特徴とする方法。
7. 請求項６において、更に、前記クライエントにおけるユーザを認証されたユーザとして検証することを特徴とする方法。
8. 請求項６において、前記オフラインアクセス情報が、更に、
   少なくとも１個のユーザ特定鍵、
   前記第一鍵を包含する少なくとも１個のグループ特定鍵、
   複数の文書と関連する少なくとも１組の文書・許可情報、
   を有していることを特徴とする方法。
9. 請求項８において、更に、前記クライエントからオフライン監査ログを受取ることを特徴とする方法。
10. 請求項８において、前記少なくとも１組の文書・許可情報が、前記第二文書と関連する１つ又はそれ以上のポリシーを有しており、且つ前記オフラインアクセス情報が、更に、文書失効リストを有していることを特徴とする方法。
11. 請求項８において、前記オフラインアクセス情報が、更に、同期優先順位付け情報に基づいて選択された特定の文書と関連する少なくとも１組の文書・許可情報を有していることを特徴とする方法。
12. 文書制御サーバーのユーザのグループと関連する第一鍵を有するオフラインアクセス情報を、オンラインである場合に、文書制御サーバーから受取り、
    電子文書内の第二鍵を解読するために前記第一鍵を使用し且つ前記電子文書と関連する文書・許可情報に基づいて前記電子文書に関するアクションを支配するオペレーションを実施することにより、オフラインである場合に、前記電子文書へのアクセスを許可する、
    ことを特徴とする方法。
13. 請求項１２において、前記電子文書に関するアクションを支配する場合に、前記電子文書から前記文書・許可情報を獲得することを特徴とする方法。
14. 請求項１２において、前記電子文書に関するアクションを支配する場合に、
    前記電子文書の文書ポリシー参照を識別し、
    前記文書ポリシー参照に基づいて局所的に維持されている文書・許可情報を獲得する、
    ことを特徴とする方法。
15. 請求項１２において、前記オフラインアクセス情報が、少なくとも１個のユーザ特定鍵、前記第一鍵を包含する少なくとも１個のグループ特定鍵、複数の文書と関連する少なくとも１組の文書・許可情報、文書失効リスト、を有していることを特徴とする方法。
16. 請求項１２において、更に、現在の時間と前記オフラインアクセス情報の受取時間との間の差異がサーバー・同期・周波数パラメータを超える場合には、オフラインである場合に、前記文書へのアクセスを阻止することを特徴とする方法。
17. 請求項１６において、前記サーバー・同期・周波数パラメータが前記文書に対して特定的であることを特徴とする方法。
18. 請求項１２において、更に、
    オフライン監査ログを維持し、
    オンラインである場合に前記オフライン監査ログをアップロードする、
    ことを特徴とする方法。
19. 電子文書を暗号化し、
    文書制御サーバーのアドレスと、文書・許可情報と、前記暗号化した電子文書を解読する場合に使用可能な暗号化鍵とを前記暗号化した電子文書内に組込み、
    前記暗号化鍵が前記文書制御サーバーにより発生され且つ前記文書制御サーバーのユーザのグループと関連している鍵で暗号化されていることを特徴とする方法。
20. 請求項１９において、前記暗号化鍵が前記文書制御サーバーにより発生されるセッション鍵を有しており、前記電子文書を暗号化する場合に文書鍵を使用して前記電子文書を暗号化し、且つ組込む場合に前記文書鍵及び前記文書・許可情報を有する文書セキュリティペイロードを前記暗号化した電子文書内に組込み、前記文書セキュリティペイロードが前記セッション鍵を使用して暗号化されていることを特徴とする方法。
21. 請求項２０において、前記文書セキュリティペイロードが、更に、前記文書制御サーバーにより割当てられる文書識別子を有しており、且つ組込む場合に、更に、前記文書制御サーバーと関連する公開鍵を使用して暗号化されている前記セッション鍵のコピーを前記暗号化された電子文書内に組込むことを特徴とする方法。
22. 請求項１９において、前記文書・許可情報が前記電子文書より小さな粒度のレベルにおいてアクセス許可を特定することを特徴とする方法。
23. 機械読取可能な媒体内にタンジブルに実現されているソフトウエアプロダクトにおいて、前記ソフトウエアプロダクトが１つ又はそれ以上のデータ処理装置をして、
    クライエントからリクエストを受取り、
    ユーザのグループと関連する第一鍵を有するオフラインアクセス情報を前記クライエントへ送ることにより前記ユーザのグループのメンバーとしてユーザによるアクションを可能とさせるために前記リクエストに応答して前記クライエントを事前認可し、前記第一鍵が電子文書内の第二鍵を解読することにより前記電子文書へのアクセスを前記クライエントにおいて使用可能とする、
    オペレーションを実施すべく動作可能な命令を有していることを特徴とするソフトウエアプロダクト。
24. 請求項２３において、クライエントを事前認可する場合に、最後に記録したクライエント・同期の時間をそのユーザに対するユーザ・グループ情報における最後の変化の時間と比較することを特徴とするソフトウエアプロダクト。
25. 請求項２３において、前記クライエントを事前認可する場合に、そのユーザに対する現在のユーザ・グループ情報を前記クライエントからそのユーザに対して受取ったユーザ・グループ情報と比較することを特徴とするソフトウエアプロダクト。
26. 請求項２３において、前記クライエントが、前記電子文書内に存在する文書・許可情報に基づいて前記電子文書に関するアクションを可能とさせることを特徴とするソフトウエアプロダクト。
27. 請求項２３において、前記オフラインアクセス情報が、更に、前記電子文書を包含する複数の文書と関連する文書・許可情報を有しており、且つ前記クライエントが前記文書・許可情報に基づいて前記電子文書に関するアクションを可能とさせることを特徴とするソフトウエアプロダクト。
28. 請求項２３において、リクエストを受取る場合に、第二文書に関するアクションを取ることの要求を前記クライエントから受取ることを特徴とするソフトウエアプロダクト。
29. 請求項２８において、前記オペレーションが、更に、前記クライエントにおけるユーザを認証されたユーザとして検証することを特徴とするソフトウエアプロダクト。
30. 請求項２８において、前記オフラインアクセス情報が、更に、
    少なくとも１個のユーザ特定鍵、
    前記第一鍵を包含する少なくとも１個のグループ特定鍵、
    複数の文書と関連する少なくとも１組の文書・許可情報、
    を有することを特徴とするソフトウエアプロダクト。
31. 請求項３０において、前記オペレーションが、更に、前記クライエントからのオフライン監査ログを受取ることを包含していることを特徴とするソフトウエアプロダクト。
32. 請求項３０において、前記少なくとも１組の文書・許可情報が、前記第二文書と関連する１つ又はそれ以上のポリシーを有しており、且つ前記オフラインアクセス情報が、更に、文書失効リストを有していることを特徴とするソフトウエアプロダクト。
33. 請求項３０において、前記オフラインアクセス情報が、更に、特定の文書と関連する少なくとも１組の文書・許可情報を有しており、且つ前記オペレーションが、更に、同期優先順位付け情報に基づいて前記文書特定文書・許可情報を選択することを包含していることを特徴とするソフトウエアプロダクト。
34. 機械読取可能な媒体にタンジブルに実現されているソフトウエアプロダクトにおいて、前記ソフトウエアプロダクトが、１つ又はそれ以上のデータ処理装置をして、
    文書制御サーバーのユーザのグループと関連する第一鍵を有するオフラインアクセス情報を、オンラインである場合に、前記文書制御サーバーから受取り、
    前記電子文書内の第二鍵を解読するために前記第一鍵を使用し且つ前記電子文書と関連する文書・許可情報に基づいて前記電子文書に関するアクションを支配するオペレーションを実施することにより、オフラインである場合に、電子文書へのアクセスを可能とさせる、
    オペレーションを実施させるべく動作可能な命令を有していることを特徴とするソフトウエアプロダクト。
35. 請求項３４において、前記電子文書に関するアクションを支配する場合に、前記電子文書から前記電子文書・許可情報を獲得することを特徴とするソフトウエアプロダクト。
36. 請求項３４において、前記電子文書に関するアクションを支配する場合に、
    前記電子文書内の文書ポリシー参照を識別し、
    前記文書ポリシー参照に基づいて局所的に維持されている文書・許可情報を獲得する、
    ことを特徴とするソフトウエアプロダクト。
37. 請求項３４において、前記オフラインアクセス情報が、少なくとも１個のユーザ特定鍵と、前記第一鍵を包含する少なくとも１個のグループ特定鍵と、複数の文書と関連する少なくとも１組の文書・許可情報と、文書失効リストとを有していることを特徴とするソフトウエアプロダクト。
38. 請求項３４において、前記オペレーションが、更に、現在の時間と前記オフラインアクセス情報の受取時間との間の差異がサーバー・同期・周波数パラメータを超える場合に、オフラインである場合に、前記文書へのアクセスを阻止することを特徴とするソフトウエアプロダクト。
39. 請求項３８において、前記サーバー・同期・周波数パラメータが前記文書に対して特定的であることを特徴とするソフトウエアプロダクト。
40. 請求項３４において、前記オペレーションが、更に、
    オフライン監査ログを維持し、
    オンラインである場合に前記オフライン監査ログをアップロードする、
    ことを包含していることを特徴とするソフトウエアプロダクト。
41. 機械読取可能な媒体にタンジブルに実現されているソフトウエアプロダクトにおいて、前記ソフトウエアプロダクトが、１つ又はそれ以上のデータ処理装置をして、
    電子文書を暗号化し、
    文書制御サーバーのアドレスと、文書・許可情報と、前記暗号化した電子文書を解読する場合に使用可能な暗号化鍵であって前記文書制御サーバーにより発生され且つ前記文書制御サーバーのユーザのグループと関連している鍵で暗号化されている暗号化鍵とを前記暗号化されている電子文書内に組込む、
    オペレーションを実施すべく動作可能な命令を有していることを特徴とするソフトウエアプロダクト。
42. 請求項４１において、前記暗号化鍵が前記文書制御サーバーにより発生されるセッション鍵を有しており、前記電子文書を暗号化する場合に文書鍵を使用して前記電子文書を暗号化し、且つ組込む場合に前記文書鍵と前記文書・許可情報とを有する文書セキュリティペイロードを前記暗号化した電子文書内に組込み、前記文書セキュリティペイロードが前記セッション鍵を使用して暗号化されていることを特徴とするソフトウエアプロダクト。
43. 請求項４２において、前記文書セキュリティペイロードが、更に、前記文書制御サーバーにより割当てられた文書識別子を有しており、且つ組込む場合に、更に、前記文書制御サーバーと関連する公開鍵を使用して暗号化された前記セッション鍵のコピーを前記暗号化された電子文書内に組込むことを特徴とするソフトウエアプロダクト。
44. 請求項４１において、前記文書・許可情報が、前記電子文書より小さな粒度のレベルにおいてアクセス許可を特定とすることを特徴とするソフトウエアプロダクト。
45. クライエントリクエストに応答してオフラインアクセス情報をクライエントと同期させる文書制御サーバーが設けられており、前記オフラインアクセス情報が１つのグループと関連する第一鍵を有しており、前記第一鍵が電子文書内の第二鍵を解読することにより前記電子文書へアクセスことを前記クライエントにおいて使用可能であり、
    オフラインである場合にグループのメンバーとしてのユーザによる前記電子文書へのアクセスを可能とさせるクライエントが、前記電子文書内の前記第二鍵を解読するために前記第一鍵を使用し且つ前記電子文書に関連する文書・許可情報に基づいて前記電子文書に関するアクションを支配する、
    ことを特徴とするシステム。
46. 請求項４５において、前記電子文書が前記文書・許可情報を有していることを特徴とするシステム。
47. 請求項４６において、前記第二鍵が前記文書制御サーバーにより発生されるセッション鍵を有しており、且つ前記電子文書が、更に、文書鍵と前記文書・許可情報とを有する文書セキュリティペイロードを有しており、前記文書セキュリティペイロードが前記セッション鍵を使用して暗号化されていることを特徴とするシステム。
48. 請求項４５において、前記オフラインアクセス情報が、更に、
    少なくとも１個のユーザ特定鍵、
    前記第一鍵を包含する少なくとも１個のグループ特定鍵、
    複数の文書と関連する少なくとも１組の文書・許可情報、
    を有していることを特徴とするシステム。
49. 請求項４５において、前記クライエントが、前記オフラインアクセス情報を同期させるために周期的に前記文書制御サーバーとコンタクトするエージェントを有していることを特徴とするシステム。
50. 請求項４５において、前記文書制御サーバーが、
    コンフィギュレーション及びロギングコンポーネントを具備するサーバーコア、
    動的にロードした方法にわたって機能性を与える内部サービスコンポーネント、
    １つ又はそれ以上のアクセス制御サービスプロバイダーを包含する動的にロードした外部サービスプロバイダー、
    を有していることを特徴とするシステム。
51. 請求項４５において、更に、
    前記文書制御サーバーを包含する複数の文書制御サーバーからなるクラスターを有しているビジネスロジック層、
    ビュアクライエント、セキュアリングクライエント、管理クライエントを有する前記クライエントを包含するアプリケーション層、
    クライエントリクエストを前記文書制御サーバーへ経路付けするロードバランサー、
    を有していることを特徴とするシステム。
52. 請求項４５において、前記クライエントリクエストが、第二文書に関するアクションを取ることの前記クライエントからのリクエストを有していることを特徴とするシステム。
53. 請求項５２において、前記文書制御サーバーが翻訳コンポーネントを包含している許可・ブローカーサーバーを有しており、前記第二文書が前記許可・ブローカーサーバーにより前に確保された文書を有しており、且つ前記翻訳コンポーネントが前記クライエントから受取ったリクエストに応答して第一許可・定義フォーマットにある第一文書・許可情報を第二許可・定義フォーマットでの第二文書・許可情報へ翻訳すべく動作可能であることを特徴とするシステム。
54. 請求項５２において、前記サーバーが前記リクエストに応答して前記第二文書に関連する情報を識別すべく動作可能な許可・ブローカーサーバーを有しており、前記関連する情報が前記サーバーにおいて維持され且つ前記第二文書とは異なり且つそれと関連している第三電子文書を表示し、前記サーバーが前記第三電子文書に関する情報を前記取るべきアクションを容易化させるために前記クライエントを関係付けるべく動作可能であることを特徴とするシステム。
55. 請求項５２において、前記サーバーが１つ又はそれ以上のデータ処理装置をして認証手順を行わせるオペレーションを実施させるべく動作可能な命令を有するソフトウエアプログラムを前記リクエストに応答して獲得し且つ送信すべく動作可能な許可・ブローカーサーバーを有しており、且つ前記クライエントが前記認証プログラムを使用して現在のユーザを識別し且つ前記第二文書に関連する現在のユーザ及び文書・許可情報に基づいて前記第二文書に関するアクションを制御することを特徴とするシステム。
56. 複数ユーザのグループのメンバーとしてユーザによるアクションを可能とさせるためにクライエントを事前認可するために制御された文書に対してオフラインアクセス情報であって前記グループに関連する第一鍵であって電子文書内の第二鍵を解読することにより前記電子文書へアクセスするために前記クライエントにおいて使用可能な第一鍵を有しているオフラインアクセス情報をトランスペアレントに供給するサーバー手段、
    前記オフラインアクセス情報を使用して前記電子文書へアクセスするクライエント手段、
    を有していることを特徴とするシステム。
57. 請求項５６において、更に、
    電子文書に関してアクションを取るためにクライエントリクエストに応答して認証プロセスを動的に獲得し且つ送信するサーバー手段、
    現在のユーザを識別するために受取った認証プロセスとインターフェースし且つ前記現在のユーザ及び文書・許可情報に基づいて電子文書に関するアクションを制御するクライエント手段、
    を有していることを特徴とするシステム。

Images