JP2007511821A - 分散ドキュメントのバージョンコントロール - Google Patents

Abstract

分散ドキュメントのバージョンコントロールを提供するシステムと技術である。一般に、一つの実施において、上記技術は、分散電子ドキュメントに関連したアクションを行なうような要求を受信することと、上記要求に応答して、分散電子ドキュメントとは異なる第２の電子ドキュメントを示す、分散電子ドキュメントに関連した情報を識別することと、第２の電子ドキュメントに関連した情報を伝え、第２の電子ドキュメントに関連して行われるべきアクションを行なわせることとを含む。要求の受信は、サーバで行なわれ、要求は、クライアントにおいて局所的に保持されている分散電子ドキュメントに関連したアクションを行なうようなクライアントからの要求であり得る。上記関連情報は、サーバにおいて保持され得、第２の電子ドキュメントの情報を伝えることは、サーバからクライアントへの、第２の電子ドキュメントの情報を関係付けることを含み得る。

Description

本発明は、ドキュメントコントロールに関するシステムと技術について、例えば、分散ドキュメントのバージョンコントロールについて述べている。

伝統的なドキュメントコントロールシステムは、システムによって保護（ｓｅｃｕｒｅ）されたドキュメントに対する暗号化キーを格納、および、統率するサーバを含んでいた。上記システムでは、保護されたドキュメントが開かれるより前に上記サーバに対して接続を要求し、ドキュメントに対する堅牢な保護を提供してきた。そのようなシステムはまた、ユーザがオフラインのときにクライアント上の復号化ドキュメントキーをキャッシュし、短い時間の間だけクライアントがドキュメントを開くことが出来るようにすることによって、最初はオンライン中に開かれたドキュメントに対してオフライン能力を提供してきた。そのようなシステムはまた、オフライン中のログ情報のキャッシュを含むドキュメントアクセス情報をログし、ドキュメントアクセスを監査（ａｕｄｉｔ）するのに用いることが可能であった。

従来のドキュメントマネジメントシステムは、ドキュメント認証情報を含んできた。ここにドキュメント認証情報とは、ドキュメントに関連した情報であって、異なる個人のグループが異なる認証を有することを可能にする情報である。従来のドキュメントビューイング・ソフトウェア・アプリケーションはまた、ドキュメントマネジメントシステム・フォーマットからソフトウェア・アプリケーションに用いられているフォーマットへドキュメント認証情報を送信するようにデザインされた、ソフトウェア・プラグインをも含んできた。ここに、上記ソフトウェア・プラグインは、それぞれがドキュメントマネジメントシステムと統合するように要求されたソフトウェア・プラグインである。さらに、ｅＸｔｅｎｓｉｂｌｅ Ｒｉｇｈｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸｒＭＬ（登録商標））が定義されており、ドキュメントビューイング・アプリケーションが、ＸｒＭＬ（登録商標）規則にしたがう任意のシステムからのリソース（ｒｅｓｏｕｒｃｅ）と許可（ｐｅｒｍｉｓｓｉｏｎ）とを理論上理解できるようになっている。

ドキュメントを保護するために、多くの異なる暗号化スキームが用いられてきた。これらは、ドキュメント毎を基礎とした対称的な暗号化スキームと、組み合わせの非対称的な暗号化スキーム（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ（ＰＧＰ（登録商標）暗号化））とを含んできた。上記対称的な暗号化スキームは、個人に対し個々のドキュメントに対するパスワードを記憶するように要求するものであり、上記非対称的な暗号化スキームは、ユーザが有している一つのパスワードに基づいて複数のドキュメントを復号化する能力を提供するものであった。また、ネットワーク・マルチキャスト／ブロードキャストの文脈では、クライアント上の暗号化キーをキャッシュする様々な暗号化プロトコルが用いられてきた。多くのソフトウェアプロダクトは、現存するエンタープライズ認証システム（ｅｎｔｅｒｐｒｉｓｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｙｓｔｅｍ）（例えば、Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と直接的に統合し得る。さらにまた、様々なシステムは、Ｔｕｍｂｌｅｗｅｅｄ Ｍｅｓｓａｇｉｎｇ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（登録商標）のように、ユーザがある分散ドキュメントの最新バージョンを探すことが出来るようにする機能をも提供して来た。ここに、上記Ｔｕｍｂｌｅｗｅｅｄ Ｍｅｓｓａｇｉｎｇ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（登録商標）は、ｅ−メールシステムを保護する（ｓｅｃｕｒｅ）するシステムであり、添付のドキュメントを有したｅ−メールの受取人に対し、添付のドキュメントのオリジナルバージョンがアップデートされた際に、現在のドキュメントにリンクするＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有するｅ−メール通知を、送信することが可能なシステムである。

（発明の要約）
一般に、本発明は、一局面では、分散電子ドキュメントに関連したアクションを行なうようにする要求を受信することと、上記要求に応答して上記分散電子ドキュメントに関連した情報を識別することとを特徴とし、上記関連した情報は、分散電子ドキュメントとは異なる第２の電子ドキュメントを示し、上記第２の電子ドキュメントに関する情報を知らせ、第２の電子ドキュメントに関連して行なわれるべきアクションを行なわせることを含む。要求を受信することは、サーバにおいて、分散電子ドキュメントに関連したアクションを行なわせる、クライアントからの要求を受信することを含み得、上記分散電子ドキュメントは、クライアントにおいて局所的に保持される。関連した情報を識別することは、サーバに保持された関連した情報を識別することを含み得る。第２のドキュメント情報を知らせることは、サーバからの第２のドキュメント情報をクライアントに関係付けることを含み得る。

第２のドキュメント情報を関係付けることは、第２のドキュメント情報をクライアントに送信し、上記クライアントが上記第２のドキュメントを入手出来るようにすることを含み得る。第２のドキュメント情報を関係付けることは、第２の電子ドキュメントを入手することと、第２の電子ドキュメントをクライアントに送信することとを含み得る。分散ドキュメントおよび第２のドキュメントは、異なる言語バージョンのドキュメントであり得る。分散ドキュメントと第２のドキュメントとは、一連の異なるバージョンのドキュメントであり得る。

第２の電子ドキュメントは、分散電子ドキュメントの新しいバージョンであり得、関係した情報は、上記アクションが上記クライアントにおける分散電子ドキュメントに関連して認証されていないことを示すドキュメント認証情報であり得る。ドキュメント認証情報は、上記分散電子ドキュメントよりも小さな粒度レベル（ｌｅｖｅｌ ｏｆ ｇｒａｎｕｌａｒｉｔｙ）におけるアクセス認証を指定し得る。上記関連した情報は、第２の電子ドキュメントを示すユーザ依存の関連情報を含み得、第２の電子ドキュメントを入手することは、上記ユーザ依存の関連情報とクライアントにおいて識別されたユーザとに基づいて第２の電子ドキュメントを識別することを含み得る。

第２の電子ドキュメントを入手することは、識別されたユーザに基づいて第２の電子ドキュメントの少なくとも一部を生成することを含み得る。上記分散ドキュメントおよび第２のドキュメントは、異なるフォーマットバージョンのドキュメントを含み得る。上記分散電子ドキュメントは、ソフトウェアプログラムであり得、上記第２の電子ドキュメントは、上記ソフトウェアプログラムの新しいバージョンであり得、上記アクションは、上記ソフトウェアプログラムを実行させることを含み得る。

上記オペレーションはまた、クライアントにおける分散電子ドキュメントにアクセスすることと、サーバのアドレス、および、分散電子ドキュメントにおけるドキュメント識別子とを識別することと、上記アドレスを用いているサーバへ、上記ドキュメント識別子、および、上記要求されたアクションを送信することと、上記クライアントにおける分散ドキュメントを第２のドキュメントを用いて置き換えることとを含み得る。分散ドキュメントを置き換えることは、第２のドキュメントに関するアクションを実行することを含み得る。上記第２のドキュメントは、サーバのアドレスと、第２のドキュメントの識別子とを含み得、上記分散ドキュメントを置き換えることは、分散ドキュメントを格納デバイス内の第２のドキュメントを用いて上書きすることを含み得る。

別の局面によれば、本発明は、局所的に保持された分散ドキュメントを開く動作と、分散ドキュメントから識別されたドキュメントコントロールサーバに接続する動作と、上記ドキュメントコントロールサーバから受信した情報に基づいて、分散ドキュメントの代わりに、少なくとも１つのドキュメントアクションに関連した第２のドキュメントの使用を強いる動作とを含み得る。上記動作はまた、受信した情報に基づいて第２のドキュメントを入手することを含み得、あるいは、上記受信された情報は、第２のドキュメントを含み得る。上記第２のドキュメントは、分散ドキュメントの新しいバージョンであり得、使用を強いることは、トランスパレントに分散ドキュメントを閉じ、第２のドキュメントを開くことを含み得る。

使用を強いることはまた、分散ドキュメントを第２のドキュメントを用いてトランスパレントに上書きすることを含み得る。受信した情報は、第２のドキュメントに関連した認証を分散ドキュメントを用いて指定するドキュメント認証情報であり得る。さらに、分散ドキュメントは、ソフトウェアプログラムであり得、第２のドキュメントは、上記ソフトウェアプログラムの新しいバージョンであり得、上記少なくとも１つのドキュメントアクションは、上記ソフトウェアプログラムを実行することを含み得る。

別の局面によれば、システムは、クライアントに対して局所的な分散電子ドキュメントに関連したアクションが行なわれる際に要求をサーバに送信するように動作することが出来るクライアントと、要求を受信するように動作することが出来るサーバとを含み、クライアントに応答して、上記サーバは、分散電子ドキュメントに関連した情報を識別するように動作することが出来、上記関連した情報は、サーバに保持され、分散電子ドキュメントとは異なるドキュメント、および、関連したドキュメントであり得、上記サーバは、上記第２の電子ドキュメントに関する情報をクライアントに関係付け、アクションが容易に行なわれるようにする。

サーバは、コンフィギュレーションとロギングコンポーネントとを伴うサーバコアと、動的にロードされた複数のメソッド（ｍｅｔｈｏｄ）を横断する機能を提供する内部のサービスコンポーネントと、１つ以上のアクセスコントロールサービス・プロバイダを含む動的にロードされた外部のサービスプロバイダとを含み得る。上記システムはまた、サーバを含む、ドキュメントコントロールサーバのクラスタを有するビジネスロジック階層と、ビューア・クライアント、セキュア・クライアント、および、アドミニストレーション・クライアントを含むクライアントを有するアプリケーション階層と、上記クライアント要求をドキュメントコントロールサーバへルーティングするロードバランサーとを含んでいる。

上記サーバは、翻訳コンポーネントを含んだパーミション仲介サーバ（ｐｅｒｍｉｓｓｉｏｎｓ−ｂｒｏｋｅｒ ｓｅｒｖｅｒ）であり得る。上記局所的なドキュメントは、既にパーミション仲介サーバによって保護されたドキュメントであり得、上記翻訳コンポーネントは、上記クライアントから受信した要求に応答して、第１の認証定義フォーマットの第１のドキュメント認証情報を、第２の認証定義フォーマットの第２のドキュメント認証情報に翻訳するように動作することが出来る。

上記サーバは、上記要求に応答し、１つ以上のデータ処理装置に認証手続きに効果的な動作を実行させるように動作することが出来る命令を有したソフトウェアプログラムを入手し、送信するように動作することが可能な、パーミション仲介サーバであり得る。クライアントは、上記認証プログラムを用いて実際のユーザを識別し、上記実際のユーザと上記第２のドキュメントに関連したドキュメント関連情報とに基づいて、上記第２のドキュメントに関連したアクションをコントロールし得る。

上記サーバは、クライアントの要求に応答して、オフラインアクセス情報をクライアントに同期化させるように動作することが出来るドキュメントコントロールサーバであり得る。オフラインアクセス情報は、グループに関連した第１のキーを含み得、上記第１のキーは、クライアントにおいて、第３のドキュメントにおける第２のキーを復号化することによって上記第３のドキュメントにアクセスすることに利用出来る。上記クライアントは、オフラインの際、上記第１のキーを用いて上記第３のドキュメントにおける第２のキーを復号化することにより、グループのメンバーであるユーザが第３のドキュメントにアクセスすることを許可し得、さらに、第３のドキュメントに関連したドキュメント認証情報に基づいて、第３のドキュメントに関連したアクションを統率し得る。

本発明は、以下の利点の１つ以上を具体化するように実施され得る。ドキュメントコントロールシステムは、ドキュメントマネジメントシステム、格納システム、ならびに、認証コントロール機構およびアクセスコントロール機構のような、現存のエンタープライズ基盤（ｅｎｔｅｒｐｒｉｓｅ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と容易かつ実体的に統合され得る。ドキュメントコントロールシステムのユーザは、最小限のわずらわしさを伴って、認証されたアクションを実行することが可能であり得る。クライアント命令は最小化され得、サーバ・イニシエート（ｓｅｒｖｅｒ ｉｎｉｔｉａｔｅｄ）であり得、クライアントのカスタマイズがトランスパレントに実行され得、これにより、エンタープライズ・ソリューションを配設（ｄｅｐｌｏｙ）するプロセスが容易化される。さらに、上記ドキュメントコントロールシステムは、複数のプラットフォームに配設され得るが、特定のプラットフォームと密接に結びつくことはない。

クライアントの機能は、サーバに強いられ得る。クライアント・アプリケーションのサイズと複雑さとを最小化することによって、単純な管理と配設が可能になる。クライアントの動作を効果的にする新しい機能が、クライアントに関する複雑なアップデートを要求することなしに、サーバにおいて実施され得る。認証システムは、必要に応じてクライアントにプラグインされることが可能であり得る。上記認証システムは、後に発展した認証機構を含む、複数の異なる認証機構と統合され得る。上記認証システムは、例えば、一定の時間の間にログイン・チケットをキャッシュすることによって、または、ユーザを再びトランスパレントに認証すること等によって、トランスパレントな認証をサポートし得る。上記認証システムは、配設が容易であり得る。サーバ・アドミニストレータは、新しく配設された認証プロセスを有したユーザ認証を含み得、新しい認証プロセスは、認証が発生した際に、上記クライアントに自動的にプラグインされ得る。上記認証プロセスは、ドキュメント認証およびアクションから独立したものであり得、このため、実際のドキュメントの分散に関する本質を考慮に入れる必要なしに、アクション間の認証が発生し得る。

ドキュメントコントロールシステムは、ドキュメント認証情報に関する自身についての表現を有した現存のクライアント・アプリケーションを用いることが出来る。上記クライアントアプリケーションは、コントロールされるドキュメントに用いるドキュメント認証情報の全てを表現出来るわけではない。サーバ・プラグインは、複数のタイプのドキュメント認証情報の間で翻訳を行なうことが出来、エンタープライズシステムで用いられ得るような追加的なドキュメント保護構想（ｄｏｃｕｍｅｎｔ ｐｒｏｔｅｃｔｉｏｎ ｃｏｎｃｅｐｔ）が現存のクライアント・アプリケーションと共に用いられることを許容する。パーミション仲介サーバにおけるドキュメント認証情報についての動的な翻訳と仕様とが、多目的かつアップグレードが迅速に行なえるドキュメントコントロールシステムを生成し得る。上記システムは、必要に応じて、異なるドキュメントを一斉に提供するのと同様に、古いフォーマットの認証を翻訳することが出来るため、迅速にバックワード・コンパティブル（ｂａｃｋｗａｒｄｓ ｃｏｍｐａｔｉｂｌｅ）に構成され得る。

オフラインアクセス・モデルは、ユーザが最初にアクセスしたときには、オフラインになり得るように提供され得る。ユーザは、オンライン中のアクセスが否定されたオフラインのドキュメントにアクセスすることを妨害されるのと同時に、一方で、オフラインであるという単純な理由により、アクセス認証を有しているドキュメントへのアクセスを妨害されずに済む。取り消し（ｒｅｖｏｃａｔｉｏｎ）が発行された時とそれがシステム内の全クライアントに対し有効になった時との間に、有界な時間が提供され得る。さらに、ポリシーがモディファイされた時とクライアントがモディファイされたポリシーを用いる時との間に、有界な時間が提供され得る。

ドキュメント情報送達技術は、アクセスされるべき異なるバージョンのドキュメントに関する情報を、自動的に送信するように提供され得る。ドキュメントは、上述のように、ドキュメントコントロールシステムに束縛（ｔｅｔｈｅｒ）され得、上記ドキュメントが開かれた際、上記システムは、代わりにアクセスされる異なるドキュメントに関する情報を関係付けし得る。様々なワークフローが定義され得る。そのようなワークフローは、ユーザが常に最新バージョンのドキュメントを保有することを保証（ｅｎｓｕｒｅ）し得る。あるいは、上記ワークフローは、カスタマイズされたユーザ依存のドキュメント送達を提供し得る。異なるドキュメントを視覚することがユーザに対して提案、または、強制され得る。あるいは、その両方が、ドキュメントに依存して行なわれ得る。

本発明に関する１つ以上の実施形態に関する詳細は、添付の図面と以下に続く詳細な記述とによって示される。本発明に関するその他の特徴と利点とが、詳細な記述、図面、および請求の範囲によって明らかになる。

（詳細な記述）
記述されているシステムおよび技術は、ドキュメントコントロールシステムを実現するのに用いられ得る。例えば、上記システムおよび技術は、ドキュメントマネジメントと関係してエンタープライズによって用いられ得る。ドキュメントコントロールシステムは、スタンドアロンなシステムとして、または、別のシステムのコンポーネントとして動作し得る。ドキュメントコントロールシステムは、ドキュメントがどこに存在するかに関わらず、誰がドキュメントを視覚することが出来るかと彼らが何をすることが出来るかとをコントロールすることによって、堅牢なドキュメント保護を提供し得る。ここで用いられているように、「ドキュメント」という用語と「電子ドキュメント」という用語とは、電子データのセットを意味する。上記電子データは、ファイルに格納された電子データとネットワークを介して受信した電子データとの両方を含み得、オペレーティングシステム（ＯＳ）またはソフトウェア・アプリケーションのグラフィカルユーザインターフェースにおいて、単一のドキュメントアイコンとして表現され得る。電子ドキュメントは、必ずしもファイルに対応してはいない。ドキュメントは、他のドキュメントを保持しているファイルの一部に、該当するドキュメント専用の単一のファイルに、または、コーディネートされたファイルのセットに格納され得る。さらに、ここで用いられているように、「定期的に」という用語は、ある時間からある時間へ繰り返されることを意味し、一定の定まった期間を要求しない。

記述されているシステムおよび技術は、例えば、ＰＯＲＴＡＢＬＥ ＤＯＣＵＭＥＮＴ ＦＯＲＭＡＴ（ＰＤＦ）を含む、多くの異なるタイプのドキュメントと共に用いられ得る。ＰＤＦドキュメントとは、Ｃａｌｉｆｏｒｎｉａ，Ｓａｎ ＪｏｓｅのＡｄｏｂｅ Ｓｙｓｔｅｍｓ Ｉｎｃｏｒｐｏｒａｔｅｄによって発明されたフォーマットのドキュメントである。ＰＤＦドキュメントは、電子ドキュメントのアピアランス（ａｐｐｅａｒａｎｃｅ）を定義することが可能なプラットフォーム独立ドキュメント・フォーマットの電子ドキュメントの例である。このドキュメントフォーマットは、グラフィックス、アニメーション、および音声を含む多くの異なるタイプのデータを格納することが可能な、プラットフォーム独立型のフォーマットであり得る。規定のアピアランスは、複数のタイプのディスプレイデバイスに対して定義され、終点デバイス（ｆｉｎａｌ ｄｅｓｔｉｎａｔｉｏｎ ｄｅｖｉｃｅ）に関わらず、ドキュメントオーガナイザーにドキュメントのルック（ｌｏｏｋ）とフィール（ｆｅｅｌ）とについてのコントロールを提供する。このタイプのフォーマットを用いたドキュメントを上述の技術と共に用いると、その結果のシステムに対し、追加的な利点が生じ得る。例えば、ドキュメントコントロールシステムは、特定のソフトウェア・デベロップメント・プラットフォームとは結びつかないアーキテクチャを有し得（例えば、システムはＪａｖａ（登録商標）および ．ＮＥＴ（登録商標）の両方の上で実行されるようにデザインされ得る）、ＰＤＦドキュメントのような、プラットフォーム独立ドキュメントを用い得る。このため、ドキュメントコントロールシステムは、いくつかのプラットフォームを横断して迅速に機能し得る。

図１は、ドキュメントコントロールシステムの動作環境を示すブロック図である。ネットワーク１００は、１つ以上のクライアント１１０と、１つ以上のサーバ１２０と、１つ以上のエンタープライズシステム１３０との間に、コミュニケーションリンクを提供し得る。ネットワーク１００は、１つ以上のネットワークプロトコルを用いて通信することが可能な複数の通信ネットワーク・リンキングマシン（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｎｅｔｗｏｒｋ ｌｉｎｋｉｎｇ ｍａｃｈｉｎｅ）であればどんなものであってもよく、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、エンタープライズネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）、および／または、Ｉｎｔｅｒｎｅｔを含み得る。クライアント１１０は、ネットワーク１００を介してサーバ１２０と通信することが可能な任意のマシンまたはプロセスであり得、サーバ１２０は、ネットワーク１００を介してエンタープライズシステム１３０と通信することが可能な任意のマシンまたはプロセスであり得る。さらに、クライアント１１０は、エンタープライズシステム１３０と通信することが出来る。

エンタープライズシステム１３０は、格納システム、認証システム、通信システム、および／または、ドキュメントマネジメントシステムであり得る。サーバ１２０は、現存するエンタープライズシステム１３０と密接に統合されるように、かつ、現存するエンタープライズ基盤を活用するようにデザインされ得る。例えば、サーバ１２０は、エンタープライズにおけるユーザの情報とグループの情報とについての十分なサポートを提供し得る。最近の企業合併に関わった大きな企業に見られるように、上記のような情報は、複数のソースから来る。サーバ１２０は、最小限目立たないようにしながらドキュメントセキュリティを提供し、上記システムを利用しやすくし、これにより、効果的に配設されるようにし得る。例えば、サーバ１２０は、以下でさらに記述されるような洗練されたオフラインアクセス機構を提供するドキュメントコントロールシステムを実施し得る。上記オフラインアクセス機構は、ユーザがたとえオンラインの間に既にドキュメントを見ていなかったとしても、オフラインの間にドキュメントを見ることが出来るようにする。このようにして、ドキュメントコントロールシステムは、通常の動作の間はロー・プロフィール（ｌｏｗ−ｐｒｏｆｉｌｅ）を維持しながら、ドキュメントセキュリティの存在を目立たなくし、より利用しやすくし得る。

図２は、例示的なドキュメントコントロールサーバ２００を示すブロック図である。ドキュメントコントロールサーバ２００は、コンフィギュレーション２２０とロギングコンポーネント２３０とを伴うサーバコア２１０を含み得る。サーバコア２１０は、サーバ２００に接続しているクライアントに対して連続手続き呼び出し（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｅ ｃａｌｌ）（ＲＰＣ）インターフェースを提供し得る。内部のサービスコンポーネント２４０は、複数のメソッド２５０を横断する機能を提供し得る。メソッド２５０と外部のサービスプロバイダ２６０とを含む、サーバ２００のその他のコンポーネントは、コンフィギュレーション・コンポーネント２２０によって提供された情報に基づいて動的にロードされ得る。メソッド２５０は、サーバ２００によるクライアントへの転送機能（例えば、ドキュメントの保護、監査クエリの実行、等）を指定し得る。外部のサービスプロバイダ２６０は、メソッド２５０（例えば、データの格納、ユーザの監査）に利用可能な外部ファシリティ（ｅｘｔｅｒｎａｌ ｆａｃｉｌｉｔｙ）を指定し得る。

コンフィギュレーションコンポーネント２２０は、コンフィギュレーションオブジェクトに対するインターフェースを定義することが出来、ロギングコンポーネント２３０は、サーバ２００によって用いられ、多種多様な情報をログする、ロギングオブジェクトに対するインターフェースを定義することが出来る。コンフィギュレーションオブジェクトは、サーバ・コンフィギュレーションファイル（例えば、サーバ２００によって読み取られる「ｉｎｉ」ファイル）であり得、ロギングオブジェクトは、ログファイル（例えば、テキストファイル）であり得る。あるいは、コンフィギュレーションオブジェクトおよびロギングオブジェクトは、標準化されたインターフェース（例えば、それぞれがｊａｖａ（登録商標）標準ＪＭＸ（ｊａｖａ ｍａｎａｇｅｍｅｎｔ ｅｘｔｅｎｓｉｏｎ）およびｌｏｇ４ｊ）を用いた局所的なオブジェクトまたは遠隔的なオブジェクトであり得る。

サーバコア２１０によって提供されたＲＰＣインターフェースは、メソッド・インターフェースをクライアントに提示するのに用いられ得る。クライアントは、名前が付けられたメソッドの各々をＲＰＣすることが出来、適切な引数（ａｒｇｕｍｅｎｔ）のセットを提供し得る。サーバ２００は、サーバーメソッド・インターフェースを転送するというメソッドのクラスを読み取り、サーバ２００がクライアントから入手を行なうことが出来るというメソッドを定義することによって、自身を初期化し得る。内部のサービス２４０は、複数のメソッド２５０の全てにわたって横断的に用いられるサーバの内部コンポーネントであり得る。これらは、メソッドの依存性にしたがって、静的に定義され、および／または、動的にロードされ得る。内部のサーバ２４０は、暗号化コンポーネントと、ドキュメント保護プロセスと、アクセスコントロール評価と、生成基盤（ｃｒｅａｔｉｏｎ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）とを含み得る。

サーバ２００がクライアントへの転送を行うというメソッドは、エンタープライズシステム環境のバックエンド基盤（ｂａｃｋｅｎｄ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に依存する追加的なサービスに潜在的に依存し得る。外部のサービスプロバイダ２６０は、メソッド２５０とそれらの実行環境との間の接続を指定するサービスプロバイダ・インターフェースのセットを定義し得る。初期化のもと、サーバ２００は、上記環境に必要とされるサービスプロバイダのセットをロードし、初期化し得る。外部のサービスプロバイダ２６０は、デフォルトの実行を含み得、時間が経つと、含まれているサービスプロバイダ・インターフェースを用いて、異なるバックエンド基盤に対して仕立てられた追加的な実行を追加し得る。

例示的なサービスプロバイダが以下で議論されるが、追加的なサービスプロバイダや代替的なサービスプロバイダであってもよい。サービスプロバイダの定義は、サービスプロバイダを実施させるインターフェースの言葉で与えられる。これらのインターフェースは、一般的に定義され得るので、多種多様なシステムにおいて横断的に実施され得る。このため、システムの境界を行き交う情報は、様々なシステムにおいてよりフレキシブルな実施を提供するために、単純な言葉で定義され得る。

ユーザを認証するために認証サービスプロバイダが用いられ得る。コンピュータセキュリティの文脈では、認証とは、受信した通信をもとに、プログラム可能なマシンに別のマシンの身元を確認（ｃｏｎｆｉｒｍ）させる手続き、および／または、他のマシンの実際のユーザを確認させる手続きである。認証が用いられ得るシステムには多くのタイプがあり、認証プロセスを引き起こし得るイベントには多くのタイプがあり、これらは特定の実行に対する要求に依存している。ここで述べられている認証システムと認証技術とは、上述のドキュメントコントロールシステムにおいて、または、その他のシステムにおいて用いられ得る。

図３は、認証システムにおけるワークフローを示すブロック図である。クライアント３１０は、ネットワーク３００を介して接続された仲介サーバ３２０と通信することが出来る。クライアント３１０が認証されたユーザに依存したアクションを行なう必要がある場合、クライアント３１０は、仲介サーバ３２０に要求３５０を送信し得る。例えば、クライアント３１０がドキュメント３０５に関連したアクションを行なう必要がある場合、クライアント３１０は、要求３５０を送信し得る。アクションに関連した用途のために、要求３５０は、サーバ３２０に対し、目下承認されている認証プロセスに関するアップデートがクライアント３１０から所望されていることを示し得る。要求３５０は、アクション、および／または、１つ以上の認証プロセスが、クライアント３１０に近接した位置に既に存在していることを示す情報を含み得る。また、サーバ３２０は、受信した情報に基づき、クライアント３１０で用いる認証プロセスを送信することによって、クライアントの要求に応答すべきかどうかを決定し得る。

加えて、要求３５０は、クライアント３１０とサーバ３２０との間の複数の通信を表現し得る。クライアント３１０は、はじめに、アクションが要求されたことをサーバ３２０に通信し得る。クライアントは、認証が行なわれるべきかどうかを知らせるように要求し、もし認証が行なわれるべきならば、どのように認証が行なわれるべきかを知らせるように要求し得る。サーバ３２０とドキュメント３０５とを識別する情報は、ドキュメント自身に含まれ得、サーバ３２０は、ドキュメント３０５を識別する情報と要求されたアクションとに基づいて、ユーザ認証が必要とされているかどうかを決定し得る。サーバ３２０は、認証が必要とされているかどうかについて応答し、クライアント３１０は、もし認証が必要とされているなら、用いられるべき認証のタイプの中から、どれを用いるかを選択し得る。上記用いられるべき認証のタイプは、潜在的に、承認可能な認証機構の複数のタイプを含み得る。クライアント３１０が指定された認証機能をいまだに有していない場合、クライアント３１０は、対応する認証アップデートを要求し得る。

サーバ３２０は、パーミション仲介サーバ専用であり得、あるいは、サーバ３２０は、その他のリソースを同様に供給し得る。例えば、サーバ３２０は、ここで述べられているようなドキュメントコントロールサーバであり得、様々なクライアント・イニシエートの動作（例えば、ドキュメントを見ること、取り消し、および、保護）は、事実上サーバベースの動作にもなり得る。これらの動作の完了により、サーバへの接続が要求され得る。クライアントによってイニシエートされた上記サーバベースの動作はまた、動的に送達された認証プロセスを用いて認証を引き起こし得る。

サーバ３２０は、認証プロセス３１５を入手し、認証プロセス３１５をクライアント３１０に送信することによって要求３５０に応答することが出来る。認証プロセス３１５は、サーバ３２０によって、または、別のサーバ（例えば、エンタープライズシステムにおけるサーバ）によって格納され得る。このため、認証コンポーネントはクライアント３１０に、サーバ３２０に、および随意に、分離された認証サーバに存在し得る。認証は、サーバ３２０が現存するエンタープライズ認証機構（例えば、パスワードベースの認証）を用い得るように、あるいはさらに、後に発達し得るカスタムな認証機構（例えば、バイオメトリック認証、または、新しいスマートカードシステム）を実行し得るように構成することが可能なサービスプロバイダインターフェースを介して取り扱われ得る。認証サービスプロバイダインターフェースは、サーバ３２０がユーザを認証するのに用いるメソッドを定義し得る。認証サービスプロバイダは、Ｗｉｎｄｏｗｓ（登録商標）認証およびＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）認証に対して、また、例えば、Ｃａｌｉｆｏｒｎｉａ，ＰｌｅａｓａｎｔｏｎのＤｏｃｕｍｅｎｔｕｍ，Ｉｎｃによって提供されたＤｏｃｕｍｅｎｔｕｍ（登録商標）コンテンツマネジメントシステムにおけるＤｏｃｕｍｅｎｔｕｍ（登録商標）ログインマネージャを用いた認証のような、１つ以上のドキュメントマネジメントシステムに対しても実行され得る。

認証プロセス３１５は、認証手続きを効率化するオペレーションをマシンに実行させるように動作出来る命令を有したソフトウェアプログラムを表現する。認証プロセス３１５は、クライアント３１０を受容するときクライアント３１０のコンポーネントになり得、あるいは、クライアント３１０と通信するときスタンドアロンになり得る。認証プロセス３１５は、Ｃａｌｉｆｏｒｎｉａ，Ｓａｎ ＪｏｓｅのＡｄｏｂｅ Ｓｙｓｔｅｍｓ Ｉｎｃｏｒｐｏｒａｔｅｄによって提供されるＡＤＯＢＥ ＡＣＲＯＢＡＴ（登録商標）ソフトウェアのようなドキュメントビューイングアプリケーションへのプラグインになり得る。認証プロセスは、クライアント３１０によって提供された現存するインターフェースを用い、認証情報をサーバ３２０へ通信し得る（例えば、以下でさらに述べられるように、ドキュメントビューイングアプリケーションは、認証プロセス３１５と通信するセキュリティハンドラ・コンポーネント３１７を含み得る）。認証プロセス３１５は、クライアント認証ライブラリ（例えば、ダイナミックリンクライブラリ（ＤＬＬ））またはサーバサービスプロバイダであり得る。

このため、クライアント３１０は、要求３５０をサーバ３２０へ送信した結果としての新しい認証プロセスを用いて、トランスパレントにアップデートされ得る。その結果、認証に関する特定のプロセスは構造化可能（ｃｏｎｆｉｇｕｒａｂｌｅ）になり、かつ、認証コンポーネントの端から端へ（ｅｎｄ−ｔｏ−ｅｎｄ）の送達は、アップデートに気づいているユーザなしに実行され得る。アドミニストレータがドキュメントに対して用いられるべき認証手続きを変更する際、ドキュメントに関連して指定された認証を要求するというアクションを実行しようとしている全クライアントが自動的かつトランスパレントにアップデートされ、新たに指定された機構を用いて認証を行なうことが可能になり得る。認証手続きは、ドキュメント上の一連の手続きの間でも変更され得る。このようにして、新しい要求３５０は、既に送達されたドキュメントの上で実行されるべきアクションと同一のアクションに対して送達される、新しい認証プロセス３１５になる。

認証プロセス３１５は、クライアント３１０において認証手続きを実行し、必要に応じて、任意のローカルハードウェアとインターフェースをとり、上記ローカルハードウェアをコントロールし（例としては、バイオメトリック読み取りデバイスを用いたバイオメトリック認証手続きがある）、認証プロセス３１５は、クライアント３１０によって提供されたインターフェースを用いて、認証情報をもとのサーバ３２０へ通信し得る。認証プロセス３１５は、試みられているアクションに依存して、マルチレベルおよび／またはマルチファクターの認証を含む、多種多様な異なる認証手続きを実行し得る。認証プロセス３１５は各要求に応答して動的に送達され得るため、組織（ｏｒｇａｎｉｚａｔｉｏｎ）は、必要に応じて新しいセキュリティ機能（ｓｅｃｕｒｉｔｙ ｆｅａｔｕｒｅ）をドキュメントコントロールシステムに追加することによって、認証手続きを迅速に変更し得る。

認証プロセス３１５は、クライアント３１０における（例えば、テキスト、バイオメトリックデータ、等の）入力を目的としたユーザをクエリし、受信した入力を暗号化し、暗号化した入力をサーバ３２０における認証プロバイダに返す（例えば、サーバ３２０へ情報を転送するクライアント３１０におけるセキュリティハンドラ３１７に暗号化した入力を送信する）。その結果、サーバ３２０は、直接的、または、認証サーバ３３０と連動してのいずれかによって、認証を取り扱うことが出来る。このパススルー（ｐａｓｓ−ｔｈｒｏｕｇｈ）認証機構において、クライアント３１０は、サーバ３２０にクレデンシャル（ｃｒｅｄｅｎｔｉａｌ）を提供し、サーバ３２０は、ユーザ認証を行うＬＤＡＰまたはＲＡＤＩＵＳのような第三者認証システムと共に機能することが出来る。認証が成功した場合、認証サービスプロバイダは、認証されたユーザ名を返し得る。

加えて、サーバ３２０は、クライアント認証情報を直接的に解釈（ｉｎｔｅｒｐｒｅｔ）することが必ずしも可能でなくてもよい。クライアント３１０がサーバ３２０に対してクレデンシャルを直接的に付与する代わりに、クライアント３１０は、まず認証を行い、その後、結果として生じた情報をサーバ３２０に提供し、既に認証されたクライアント３１０をサーバ３２０が再び照合（ｖｅｒｉｆｙ）出来るようにする。例えば、認証プロセス３１５は、認証サーバ３３０と接続してユーザを直接的に認証し、認証を受信したことは、サーバ３２０へ返され得る。サーバ３２０は、受信したことを認証サーバ３３０へパスし、実際に認証が成功したことを確かめる。このため、クライアント３１０は、個々のサーバシステムへ直接的にクレデンシャルを提供し、個々の認証システムを用いてユーザの身元を確かめるのに用いられ得る認証トークン（ａｕｔｈｅｎｔｉｃａｔｅｄ ｔｏｋｅｎ）をサーバ３２０へ提供し得る。

サーバ３２０は、複数の認証サービスプロバイダを用い得る。サーバ３２０は、以下で述べられるインターフェースを用いることにより、必要に応じて１つ以上の認証プロセス３１５をクライアント３１０へ動的に送達し得る。そのような認証プロセス３１５は、クライアント３１０へセキュアに送達され得、セキュアコードライブラリの読み取りに関連して以下で述べられるように、なりすまし（ｓｐｏｏｆｉｎｇ）が防止され得る。クライアント３１０はまた、例えばユーザ名パスワードテキスト入力をキャプチャし得る認証ライブラリのような、既に利用可能なデフォルトの認証プロセスを１つ以上有することが出来る。そのようなデフォルトの認証プロセスは、ユーザインターフェース（ＵＩ）のカスタマイズに対するサポートと、上記の情報を抽出するための標準的なフォーマットとを、認証プロセスサーバ内に含み得る。さらに、クライアント３１０は、ある時間の間、クレデンシャルを保持することが出来るため、ユーザは、動作を実行するたびにログオンする必要がない。オフラインアクセスをサポートするためのそのようなクライアントクレデンシャルの保持に関する例は、図１１〜１４を参照してさらに記述される。

セキュアコードライブラリのロードは、１つ以上の認証ライブラリ（例えば、ＤＬＬ，ｊａｖａ ｂｙｔｅｃｏｄｅ，ｊａｖａｓｃｒｉｐｔ，等）をクライアントに押し付け、認証ライブラリをクライアント上でのなりすまし（例えば、トロイの木馬プログラム）から防御する一方で、ユーザ側にはいかなるアクション（または知識）をも要求することなしにクライアントのアップデートまたはカスタマイズを提供するように、サーバ３２０の全てに対して実行され得る。サーバ３２０からダウンロードされた認証ライブラリの認証を照合するために、ある機構が提供され得る。サーバ３２０が認証ライブラリをクライアントに押し付けるとき、サーバ３２０は、ライブラリのハッシュ（ｈａｓｈ）を計算し、さらにこのハッシュをクライアント３１０へ送信し得、および／または、サーバ３２０は、認証ライブラリをクライアントに送信する前に、上記認証ライブラリに署名し得る。ハッシュは、クライアントにおいて、局所的に保持され得る。クライアント３１０は、認証ラインブラリのハッシュを計算し、ロード時間の間に、保持された値に対してそれを照合することによって、認証ライブラリが有効であることを保証し得る。加えて、選択されたライブラリのセットが、あるいは、ライブラリの全てが、プロバイダによって署名され得る。プロバイダの公開キーは、クライアント３１０に保持され得る（例えば、ＤＬＬは、クライアント３１０がＡｄｏｂｅ公開キーを含むＡＤＯＢＥ ＡＣＲＯＢＡＴ（登録商標）ソフトウェアである場合に、Ａｄｏｂｅによって署名され得る）。

図４は、サーバに採用される認証技術を示すフローチャートである。４００において、ドキュメントに関連したアクションを行なうような要求が受信される。４１０において、要求に応答して、認証プロセスが入手される。４２０において、現在のユーザを識別することに用いるために、および、現在のユーザと上記電子ドキュメントに関連したドキュメント認証情報とに基づいて電子ドキュメントに関連したアクションをコントロールすることに用いるために、認証プロセスがクライアントへ送信される。このため、サーバ上において認証機構が指定され、必要に応じ、クライアントに対してトランスパレントな方法で、適切なコードがクライアントへ動的にダウンロードされ得る。

認証インターフェースは、テキストベースのユーザ名パスワードに関する記述、または、単一の認証ライブラリのどちらか一方を提供し得る。このことは、２種類の認証方法を用いて実施され得る。第１の方法は、そのどちらをも無視して実施され得た場合でも、ユーザ名と同様に、オパーク・トークン（例えば、連続したバイト列）を必要とし得る。第２の方法は、ユーザ名、パスワード、および、「ドメイン」または「連結列（ｃｏｎｎｅｃｔ ｓｔｒｉｎｇ）」を指定し得る第３の引数を随意に必要とし得る。認証プロバイダは、暴力的な攻撃に対する自身の防御を実行し得、正しいクレデンシャルが提示された場合でさえも、認証を否定するというオプションを有し得る。

実行はまた、ユーザが首尾よく認証（照合）されたかどうかを指定する認証回答（ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ ｒｅｐｌｙ）をも返し得る。照合が否の場合、なぜその人物が照合されなかった（例えば、そのようなユーザはいなかった）のかを示す追加的なエラーメッセージが返され得る。このエラーメッセージは、必ずしもクライアントには返されないが、（認証システムをクラックするのに用いられ得る手助けとなる情報をクライアントに提供しないように）サーバ上にログのみされ得る。将来の認証の試みにおいて用いられるべきトークンもまた、サーバがこれを無視することもあり得るが、返され得る。ユーザ名もまた、誰が認証されたかをサーバが理解出来るように、照合の試みに対して、返され得る。アクセスコントロールリスト（ＡＣＬ）サービスプロバイダは、このユーザ名を受け取り、標準化（ｃａｎｏｎｉｃａｌｉｚｅ）し得る。ユーザ名の標準形（ｃａｎｏｎｉｃａｌ ｆｏｒｍ）は、複数のワークフローに対して一貫して横断的に用いられ得、システムにおける（複数の）標準形を支配する（複数の）定義は、実行によって変化し得る。

クライアントは、複数のメソッドを介して認証を行い得るので、サーバは、上記クライアントがデフォルトによってどのように認証を試み得るのか、または、認証がどのメソッドを次に試みることが出来ないのかを記述することが可能であり得る。認証サービスプロバイダは、例えば、特定のコードライブラリを介して、または、ユーザに対して表示されているベーシックテキストエントリダイアログ（ｂａｓｉｃ ｔｅｘｔ ｅｎｔｒｙ ｄｉａｌｏｇ）を介して、どのように認証が発生し得るかを記述し得る。コードライブラリが用いられると、サーバは、コードライブラリについてのメタデータ（例えば、ＤＬＬ名、サイズ、等）をクライアントに通信し得る。ベーシックテキストエントリダイアログが用いられると、サーバは、ＵＩのうちのどれがユーザにふさわしいかを指定し得る。上記ＵＩでは、例えば、タイトルが「あなたの社内ＬＤＡＰパスワードを入力してください」と要求したり、２つのフィールド「ユーザ名」、「パスワード」のみを要求したりする。

上述の認証システムおよび認証技術に加えて、ドキュメントコントロールシステムとドキュメントコントロール技術とが提供され得る。これらは、上述の認証と組み合わされたり、別々に用いられたりし得る。

図５は、ドキュメントコントロールシステムにおけるワークフローを示すブロック図である。クライアント５１０は、ネットワーク５００を介してパーミション仲介サーバ５２０と通信接続され得る。ドキュメントソース５３０もまた、ネットワーク５００を介してパーミション仲介サーバ５２０と通信接続され得る。ドキュメントソース５３０は、ドキュメントレポジトリ（例えば、ドキュメントマネジメントシステムまたはファイルシステム）、および／または、ドキュメントハンドリングシステム（例えば、ｅ−メールシステム）であり得る。一般に、ドキュメントソース５３０は、以下の２通りであると考えられる。（１）ドキュメント５４０が将来保持され、アクセス可能になることが見込まれているドキュメントソース、（２）ドキュメント５４０が将来保持され、アクセス可能になることが見込まれてはいないドキュメントソース。

ドキュメントソース５３０が第１のタイプの場合、ドキュメント認証情報５５０は、ドキュメントソース５３０に保持され、必要に応じてパーミション仲介サーバ５２０へ送信され得る。このため、ドキュメント認証情報５５０は、（そのような情報は、サーバ５２０に対して指定されたパーミション定義フォーマットでサーバ５２０に保持され得るが）必ずしもパーミション仲介サーバ５２０に保持されなくともよい。ドキュメントソース５３０が第２のタイプの場合、ドキュメント認証情報５５０は、ドキュメントソース５３０において、または、ドキュメント仲介サーバ５２０において生成される。あるいは、ドキュメント５４０が保護され、保護されたドキュメント５４５を生成する場合、ドキュメント認証情報５５０は、クライアント５１０において生成され得る。ドキュメント認証情報５５０は、パーミション仲介サーバ５２０に保持され得る。ドキュメント認証情報５５０は、ドキュメント５４０に対して承認されたアクションのタイプを定義する場合、ＡＣＬであり得る。さらに、ドキュメント認証情報は、ドキュメント自身よりも小さい粒度レベルの認証を指定し得る（例えば、ドキュメント内の特定の（複数の）ページ、（複数の）段落、および／または、（複数の）へのアクセスをコントロールする）。

保護されたドキュメント５４５は、パーミション仲介サーバ５２０によって生成された暗号化キーを用いて暗号化され得、保護されたドキュメント５４５は、サーバ５２０とドキュメント５４５とを識別する情報（例えば、サーバ５２０へのリンク、および、サーバ５２０の文脈内で一意的なドキュメント識別子）を含み得る。保護されたドキュメント５４５は、任意の方法（例えば、ｅ−メール、ドキュメントレポジトリからのダウンロード、コンパクトディスク上での受け取り、等）でクライアント５１０へ送達され得、保護されたドキュメント５４５は、別の保護されたドキュメントのコピー（例えば、別のソースから転送されたｅ−メールへの添付）であり得る。

クライアント５１０が保護されたドキュメント５４５に関するアクションを行なう必要がある場合、クライアント５１０は、ドキュメント５４５が保護されていることを決定し、サーバ５２０とドキュメント５４５とを識別する情報を抽出し、アクションに対応したドキュメント識別情報を含んでいるサーバ５２０へ、要求５１５を送信する。この要求に応答して、パーミション仲介サーバ５２０は、ドキュメント認証情報５５０を第２のドキュメント認証情報５５５に翻訳し得る。第２のドキュメント認証情報は、クライアント５１０へ送信され、クライアント５１０におけるドキュメント５４５に関連したアクションを支配し得る。クライアント５１０は、Ｃａｌｉｆｏｌｎｉａ，Ｓａｎ ＪｏｓｅのＡｄｏｂｅ Ｓｙｓｔｅｍｓ Ｉｎｃｏｒｐｏｒａｔｅｄによって提供されるＡＤＯＢＥ ＡＣＲＯＢＡＴ（登録商標）ソフトウェアのような、ドキュメントビューイングアプリケーションであり得、ドキュメント５４５は、ＰＤＦドキュメントであり得る。

図６は、パーミション仲介サーバに採用されるドキュメントコントロール技術を示すフローチャートである。６００において、電子ドキュメントに関連したアクションを行なうというクライアントからの要求が受信される。６１０において、要求に応答して、電子ドキュメントに関連した第１のドキュメント認証情報が識別される。第１のドキュメント認証情報は、第１の認証定義フォーマットであり得る。６２０において、識別された第１のドキュメント認証情報は、第２の認証定義フォーマットの第２のドキュメント認証情報に翻訳され得る。６３０において、第２のドキュメント認証情報は、クライアントにおける電子ドキュメントに関連したアクションを支配するクライアントへ送信され得る。

図５を再び参照すると、第１のドキュメントパーミション情報５５０は、第２のドキュメントパーミションフォーマット５５５で用いられる第２のパーミション定義フォーマットでは完全には定義されないパーミション情報のタイプを少なくとも１つ含む第１のパーミション定義フォーマットであり得る。２つの情報のセット５５０と５５５との間で翻訳することは、要求５１５に関連した情報に基づいて翻訳を行なうことを含み得る。例えば、第１の情報５５０は、パーミション定義フォーマットが時間の概念を含まないため、第２の情報５５５において完全には定義され得ない時間に依存したパーミション情報を含み得る。しかしながら、この時間に依存したパーミション情報は、要求の時間を考慮に入れることにより現在の要求に関する限られた要求のために、第２のドキュメントパーミション情報５５５において定義され得る。要求５１５の時間と共に、第１のドキュメント情報５５０は、要求されたアクションが認証されたことを示し、このことは、第２のドキュメントパーミション情報５５５に表現され得る。同様に、要求５１５に関連して、第１のドキュメントパーミション情報５５０が要求されたアクションが認証されていないことを示すと、このことは、第２のドキュメントパーミション情報５５５に表示され得る。一連のアクションが要求される場合、一連の要求の時間に基づいて再び翻訳が行なわれ得る。

別の例として、第１の情報５５０は、パーミション定義フォーマットがユーザの概念を含まないため、第２のドキュメントパーミション情報５５５においては完全には定義され得ないユーザ依存のパーミション情報を含み得る。このユーザ依存のパーミション情報は、ユーザベースのドキュメントコントロール情報と、サーバベースのドキュメントコントロール情報との両方を含み得、クライアント５１０を介して入手されたユーザ識別情報を考慮に入れることにより、現在の要求の限られた目的に対しては、第２のパーミション情報５５５において定義され得る。このユーザ識別情報は、本明細書の他の場所に記述されている認証システムおよび認証技術を用いることにより、入手され得る。あとに続くアクションが要求されると、新たに入手されたユーザ識別情報をもとに、再び翻訳が行なわれ得る。さらに、パーミション仲介サーバ５２０によって受信され得る複数の要求は、サーバ５２０に対し、クライアント５１０においてドキュメント５４５に関連して行なわれるアクションに関連した情報５２５を格納させる。これらのアクションは、ユーザ名に関連し得、クライアントに関連したネットワークアドレス（例えば、インターネットプロトコル（ＩＰ）アドレス）にも関連し得る（両者は、クライアントによる報告であり、サーバによる報告である）。要求されたアクションはまた、行なわれるべきアクションであると考えられ得、格納された情報５２５は、サーバ５２０によって、以下で記述されるように、ドキュメント５４５に関連し、格納された、アクション実行情報の検査を生成するのに用いられ得る。格納された情報５２５はまた、サーバ５２０またはドキュメントソース５３０のいずれかにおいて実行された、および／または、要求されたアクション（例えば、ファイルシステム、ドキュメントマネジメントシステムにおいて実行されたアクション、等）をも含み得、生成された監査は、この情報を同様に含み得る。

図７は、ドキュメントレポジトリ７００と統合されたドキュメントコントロールシステムにおけるワークフローを示すブロック図である。パーミション仲介サーバ７３０は、バッチ（ｂａｔｃｈ）モード（例えば、サーバ７３０がまずインストールされとき）でレポジトリ７００内のドキュメントを保護するために、および／または、コンテンツマネジメントシステム（ＣＭＳ）ワークフローにおけるステップとして用いられ得る。セキュアクライアント７２０は、レポジトリ７００からドキュメント７１０を検索することが出来る。ドキュメント識別子７１５もまた、検索され、サーバ７３０へパスされ得る。ドキュメント識別子７１５はまた、サーバ７３０によって、コンテンツに関連したアクションをコントロールするように内部で用いられ得る。レポジトリ７００がＣＭＳの場合、ドキュメント識別子７１５は、ＣＭＳ７００において用いられるドキュメント識別子であり得、レポジトリ７００がファイルシステムの場合、ドキュメント識別子７１５は、ドキュメントのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であり得る。

サーバ７３０は、ドキュメント識別子７１５を用いてレポジトリ７００と通信し、ドキュメントパーミション情報７４０（例えば、ＣＭＳからのＡＣＬまたはファイルシステムからのファイル・パーミション情報）を入手することが出来る。ドキュメントパーミション情報７４０は、ドキュメント７１０に特有のものであり得、または、複数のドキュメントに対するパーミション（例えば、ドキュメントマネジメントシステムによって維持されたポリシまたはファイルシステムによって維持されたファイルパーミションのセット）を定義し得る。入手されたドキュメントパーミション情報７４０は、サーバ７３０によって用いられ、ドキュメント７１０に対するイニシャルＡＣＬを生成する。データのセット７５０は、イニシャルＡＣＬ、ドキュメント識別子７１５、および、サーバ７３０によって生成されたキーを含み、セキュアクライアント７２０へ返信され得る。クライアント７２０は、データのセット７５０を用い、ドキュメント７１０の暗号化されたバージョンである、保護されたドキュメント７６０を生成し得る。この保護されたドキュメント７６０は、イニシャルＡＣＬ、ドキュメント識別子７１５、およびドキュメント７６０の一部としてパッケージされたキーを含み得る。

クライアントが保護されたドキュメント７６０に関連したアクションを行なうように試みる（例えば、ドキュメント７６０またはこのドキュメントの任意のコピーを開こうとする）とき、ドキュメント識別子７１５は、ドキュメントから読み出され得、サーバ７３０へ送信され、現在のＡＣＬであって、レポジトリ７００におけるドキュメントの状態を反映させる、ドキュメント７６０に対する現在のＡＣＬを入手するのに用いられ得る。このため、保護されたドキュメントに関連して行なわれるアクションは、ドキュメントレポジトリ７００におけるソースドキュメントに対して現在のパーミションを定義する、ドキュメントパーミション情報に基づいてコントロールされ得る。ソースドキュメントは、もともとは保護されたドキュメント７６０であり得、あるいは、保護されたドキュメントがレポジトリ７００へ返信されない場合、ソースドキュメントは、オリジナルなドキュメント７１０であり得る。サーバ７３０は、他の目的のためにドキュメントパーミション情報を格納し得るが、この情報は、レポジトリ７００から読み出され、ドキュメント７６０へのアクセスが要求されたときはいつも翻訳され得るため、サーバ７３０は、ドキュメントパーミション情報を必ずしも格納する必要はない。

図８は、ｅ−メールクライアント８００と統合されたドキュメントコントロールシステムにおけるワークフローを示すブロック図である。ｅ−メールクライアント８００は、ｅ−メールシステムへのプラグインであり得、ｅ−メールへの添付８１０を保護するために用いられ得る。ユーザがｅ−メールの添付８１０を保護することを選択するとき、ｅ−メールクライアント８００は、ユーザが添付に適用しようと所望しているルールに、および／または、ｅ−メールに対する受取人リストに基づいて自動的に生成され得るルールにユーザを促し得る。上記ルールは、セキュアクライアント８２０においてＡＣＬ８３０に変換され、パーミション仲介サーバ８４０へ送信され得る。サーバ８４０は、ＡＣＬを格納し、上述のようなデータのセット８５０を返し得る。このデータ８５０は、サーバ８４０によって生成され格納され得るドキュメント識別子、イニシャルＡＣＬ、および暗号化キーを含むセキュアな添付８６０を生成するために用いられ得る。

クライアントが保護されたドキュメント８６０に関連したアクションを行なおうとする（例えば、ドキュメント８６０、または、このドキュメントの任意のコピーを開こうとする）とき、ドキュメントからドキュメント識別子が読み出され、サーバ８４０へ送信され、サーバ８４０に格納されたドキュメントＡＣＬの現在の状態を反映する、ドキュメント８６０に対する現在のＡＣＬを入手するのに用いられ得る。ｅ−メールの送信者は、サーバ８４０とやり取りし、ｅ−メールが既に送信された後でさえも、ドキュメント８６０に対する現在のＡＣＬを交換することが出来る。このため、保護されたドキュメントが配信された後でさえも、保護されたドキュメントに関連して行なわれるアクションはコントロールされ得、ドキュメントのセキュリティに関する性質はモディファイされ得る。

図５〜８は、ドキュメントコントロールシステムにおいて実施され得るアクセスコントロール基盤を示している。図２と関連して記述されたサーバに関する文脈では、アクセスコントロールサービスプロバイダが実施され得、アクセスコントロールリスト（ＡＣＬ）の言葉でアクセスコントロールが定義され得る。ＡＣＬは、パーミション（例えば、プリント出来ること、ビュー出来ること）をプリンシパル（例えば、ユーザおよびグループ）にマッピングし得、逆もまた同様である。アクセスコントロールサービスプロバイダインターフェースは、サーバによって用いられ得るメソッドを定義し、上記プリンシパルを、複数のワークフローを横断して一貫して用いられ得る標準形にマッピングし得る。アクセスコントロールサービスプロバイダは、ＮＩＳ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ），ＬＤＡＰ，および、ｅ−メールシステム（例えば、ＵＮＩＸ（登録商標）システムで主に実行される公的なソフトウェアプログラムでありインターネットメーリングリストを取り扱うＭａｊｏｒｄｏｍｏ）のような様々なシステムに実施され得る。さらに、アクセスコントロール基盤は、複数の共有のＡＣＬ（例えば、複数のドキュメントの間でシェアされるべきＡＣＬであって、そのような共有のＡＣＬは、ポリシーと呼称される）をサポートし得る。

図９は、図２の例に対応するドキュメントコントロールサーバを示すブロック図である。サーバ９００は、以下を含む様々な基本的な特徴をサポートすることが出来る。（１）アクセスコントロール−誰がドキュメントにアクセスすることが出来るかと彼らがどのようなパーミションを有するかとをコントロールする能力、（２）取り消し−ドキュメントを取り消し、それ以降見られないようにする能力、（３）インターバルの期限切れ、および／または、インターバルの有効化−その時間の前および後にはドキュメントを見ることが出来ないような時間を指定する能力、（４）ドキュメントシュレッディング−ドキュメントの期限切れのもと、ドキュメント復号化キーを破壊することにより、ドキュメントコントロールサーバに関連してドキュメントを再現不可能にする能力、（５）監査−ドキュメント上で実行されるアクション（例えば、見ること、見ようとすること、等）を監査する能力、および、（６）オフラインアクセス−オフライン時にドキュメントにアクセスする能力。加えて、アーキテクチャを変更することなしに複数の特徴が容易に追加され得る。

認証サービスプロバイダ９１０は、本明細書の他の場所で記述されているように実行され、アクセスコントロールサービスプロバイダ９３０は、記述されているアクセスコントロールサービスを達成し得る。複数のＡＣＬは、複数のアクセスコントロールエントリ（ＡＣＥ）からなるセットと、プロパティのセットとを含み得る。ＡＣＬプロパティは、全体としてＡＣＬに適用され得る（例えば、有効期限）。ＡＣＥは、プリンシパルをルールにマッピングし得、プリンシパル、ルール、および、ＡＣＥに対する有効期間からなるリストを含み得る。ＡＣＬの評価が行なわれるとき、有効期間内にあるＡＣＥのみが考慮される必要がある。有効期間は、異なるユーザおよびグループが、異なるときにドキュメントを見る許可を付与されるようにする。例えば、ＡＣＥは、「広報スタッフのメンバーのみがリリース日の前にドキュメントを見ることが出来、その後は誰でもドキュメントを見ることが出来ること」を指定し得る。

複数のルールは、プロパティと、付与されたパーミションと、否定されたパーミションとのセットを含み得る。これらのパーミションは、ビューイングクライアントアプリケーション（例えば、ＡＤＯＢＥ ＡＣＲＯＢＡＴ（登録商標）ソフトウェア）、および／または、定義されたサーバのに特有のものであり得る。加えて、プロパティが拡張可能なように、パーミションは、ＡＣＬフォーマットを変更することなしに新しいものが追加され得る。

サーバ９００は、ユーザが外部のいかなるＡＣＬ機構をも用いることなしにセキュアクライアントインターフェースを用いてアクセスコントロールリストを指定することが出来るようにする、サーバ自身の単純な機構を有し得る。加えて、第三者ＡＣＬ／権利（ｒｉｇｈｔ）の仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）は、サーバ９００によって用いられる内部のＡＣＬフォーマットに翻訳され得る。サーバ９００は、その他のシステムのアクセスコントロールファシリティ（例えば、ドキュメントマネジメントシステム、データベースシステム、ファイルシステム、等）と統合され、これらシステムにおける機能を活用し得る。

サーバ９００は、不完全な情報を含み得る多種多様なユーザおよびグループのレポジトリの統合をサポートし得、サーバ９００は、標準的なユーザ中心（ｕｓｅｒ−ｃｅｎｔｒｉｃ）の方法で、この情報への効果的なアクセスが出来るようにされ得る。サーバ９００およびクライアント９８０の両方の上でＡＣＬを扱うためのファシリティが提供され得る。サーバ９００は、ＡＣＬを照合し、サーバベースのドキュメントセキュアラ９６０またはクライアントベースのドキュメントセキュアラ９９０のいずれかを用いて、ドキュメントが保護される前にＡＣＬが有効なことを保証する。複数のＡＣＬは、拡張可能であり、オパークな第三者パーミションを可能にする。さらに、ドキュメントを保護することは、オンラインな方法で行なわれ、サーバがＡＣＬを照合することが出来るようにするため、サーバ９００に接続され得る。

サーバ９００は、どのプリンシパル（例えば、ユーザおよびグループ）がドキュメントに対するどのパーミションを有しているのかを指定するため、複数のＡＣＬをドキュメントに関連付けることが出来る。プリンシパルは、複数の名前を有し得る。しかしながら、プリンシパルはまた、区別のつけられた標準的な名前をも有し得る。サーバ９００の複数のタスクの一つは、プリンシパルの様々な名前をその標準的な名前に翻訳し得る。パーミションとプロパティとは、認証されたオペレーションを記述するが、パーミションはブール値であり、プロパティは様々なタイプであり得る。パーミションは、明示的に付与され明示的に否定されない場合に付与され得、あいまいな（ｕｎｃｌｅａｒ）パーミションは、暗黙のうちに否定される。

各ドキュメントは、ＡＣＬに関係し得る。典型的には、この関係は１：１であり得るが、複数のドキュメントが同一のＡＣＬをシェアする場合のポリシーでは、この関係はＮ：１であり得る。電子ドキュメントファイルは、保護の時刻を記録する、ＡＣＬの不変の（ｉｍｍｕｔａｂｌｅ）スナップショットを含み得る。サーバ９００はまた、権限が付与された個人によってモディファイされ得る最新のＡＣＬのコピーをも維持し得る。サーバ９００は、複数のＡＣＬを、それらが用いられる前に標準化し得る（例えば、全プリンシパル名をそれらの標準形に翻訳する）。このことは、複数のＡＣＬが生成またはモディファイされるとき（例えば、保護するとき、または、ＡＣＬ定義が変更されたとき）にはいつも行なわれ得る。一旦ＡＣＬが標準形になると、特定の認証されたユーザに対して関係のある権限を決定することと同様に、グループ内のメンバーを決定することは、文字列についての基本的なマッチングを通して行なわれ得るので、クライアント９８０とサーバ９００の両方の上でＡＣＬの評価を行なうには、遥かに単純になり得る。

時間内の特定のポイント（例えば、オンラインビューイング、取り消し、ドキュメント監査検索（ｄｏｃｕｍｅｎｔ ａｕｄｉｔ ｒｅｔｒｉｅｖａｌ）、等）における特定のユーザに対してのＡＣＬに関するサーバ側の評価は、サーバ９００において直接的に実行され得る。サーバ９００は、ＡＣＬを調べ、現在有効であって、認証されたユーザまたは彼女／彼がメンバーであるグループのいずれかを含むＡＣＥを探し得る。その後、パーミションとプロパティとを抽出し得る。サーバ９００内の標準化を取り扱うサーバ基盤は、３つの階層を有し得る。第１の階層は、非標準的なプリンシパルをそれらの標準形にマッピングする、サーバ９００におけるメモリ内キャッシュであり得る。第２の永続性のキャッシュは、標準的なマッピングと、グループ内ユーザ情報とを格納し得る。このキャッシュは、複数のサーバ９００を横断して潜在的に用いられ得る。第３の階層は、アクセスコントロールサービスプロバイダ９３０であり得る。

アクセスコントロールサービスプロバイダ９３０は、非標準的な文字列のいくつかのセットに関する標準形を提供するプリンシパルモジュールのセットを含み得る。これらプリンシパルモジュールはまた、標準的なグループまたは標準的なユーザと標準形とが対応するか否かを特定し得る。しかしながら、アーキテクチャは、特定のプリンシパルモジュールが全てのユーザを一般的に知っていること、あるいは、特定の非標準的な文字列についての完全な答えを与えることが出来ることを、必ずしも仮定しなくてもよい。ユーザおよびグループのレポジトリの文脈における複数の専門のドメインをサポートするため、各プリンシパルモジュールが、その上では自らが権限（ａｕｔｈｏｒｉｔｙ）になるような（複数の）ドメインを生成し得る。サーバ９００において直接的に実行され得る標準化のプロセスは、非標準的形を取り得、そのうちの一つが返ってきた値が標準的であることを宣言するまで、権限内のモジュールをクエリすることによって、それを繰り返し精緻化し得る。

典型的なシナリオは、特定のユーザがオペレーションを実行するためのパーミションを有しているかどうかを、どのようなグループに彼女／彼が入っているかを考慮に入れて決定するサーバ９００を含むため、サーバ９００における複数のメソッド９７０は、認証されたユーザが中心のものであり得る。多くの第三者グループ機構は、「誰がグループのメンバーか？」によって、しかし「どのグループが特定のユーザを含んでいるか？」にはよらずに、グループメンバーをアクセス可能に組織する。さらに、多くのケースでは、グループはユーザについての非標準形を含み得る。このため、グループレポジトリの出力は、サーバ９００によって直接的には利用可能ではなく、媒介的な翻訳が用いられ得る。

複数のグループプロバイダに対し、非常に小さな共通部分が仮定され得る。グループプロバイダは、既知の標準的なグループについてのリストを提供することが可能であることが所望され得る。このため、有効なグループは、グループモジュールによって指定された既知のグループの和集合であり得る。グループモジュールはまた、グループ中心の方法で組織されたメンバー情報を提供し得る。これは、多数の存在しているレポジトリの実行を与えるための、効果的なアプローチであり得る。

サーバ９００は、システム内の一連のユーザに対するグループ情報をバッチ処理する能力を有し得る。例えば、複数のサーバからなるグループにおけるあるサーバは、日常的にそのようなバッチ処理を実行し得る。このことは、サーバコアにおいて実行され得、全てのグループを数え上げることと、メンバーを標準化することと、グループネスティング（ｇｒｏｕｐ ｎｅｓｔｉｎｇ）を調べ、推移閉包を計算することとを含み得る。推移閉包の計算のほとんどは、そのようなタイプのオペレーションはデータベースシステムを用いて実行することが自然であるため、格納サービスプロバイダ９２０内に存在し得る。

プリンシパルはユーザまたはグループのいずれかであり得る。プリンシパルは、文字列として表現され得る。グループはプリンシパルを含み得る。プリンシパルは、主な標準形を評価または退化（ｒｅｄｕｃｅ）したものであり得る多くのエイリアス表現を有し得る。ユーザおよびグループは、複数のドメインであり得る。ドキュメントコントロールシステムの統合がｅ−メールベースでない場合でさえも、ｅ−メールアドレスに用いられるｎａｍｅ＠ｓｕｂ．ｄｏｍａｉｎ．ｃｏｍフォーマットを含むコンベンション（ｃｏｎｖｅｎｔｉｏｎ）が採択され得る。さらに、どの標準形が用いられるべきかについての仕様は、この仕様が統合に依存したもの（ｉｎｔｅｇｒａｔｉｏｎ−ｄｅｐｅｎｄｅｎｔ）であるため、一般システムにおいて未定義なままにされ得る。特定の統合に関する文脈での例は、以下の通りである。「ｈｅｒｂａｃｈ＠ｃｏｍｐａｎｙ．ｃｏｍ」は、「ｊｏｎａｔｈａｎ＿ｈｅｒｂａｃｈ＠ｃｏｒｐ．ｃｏｍｐａｎｙ．ｃｏｍ」および「ｊｈｅｒｂａｃｈ＠ｃｏｍｐａｎｙ．ｃｏｍ」を含む多くの文字列に対する標準形の例である。同様に、「ａｔｇ＠ｃｏｍｐａｎｙ．ｃｏｍ」は、「ａｔｇ＠ｓｅａ．ｃｏｍｐａｎｙ．ｃｏｍ」に対する標準形である。

アクセスコントロールサービスプロバイダインターフェースは、ユーザモジュールおよびグループモジュールの２つのサブタイプに分割され得るプリンシパルプロバイダ（ｐｒｉｎｃｉｐａｌ ｐｒｏｖｉｄｅｒ）を含み得る。これらモジュールの目的は、標準的な情報とグループメンバーに関する情報とを提供することであり得る。プリンシパルプロバイダは、その能力の限りにおいて、プリンシパルを標準形に翻訳し得る。プリンシパルプロバイダは、返された値が標準形であるか否か、それがグループまたはユーザに知られているか否か、および、キャッシュにおいて返された結果がどのくらい長く有効であると考えられ得るかを示し得る。プリンシパルプロバイダは、正規表現定義のセットとして指定された、権限のドメインを有し得る。グループプロバイダは、権限のドメインを知っている全グループを数え上げることが出来る。

様々なサーバのメソッド９７０をサポートするために、ユーザおよびグループの情報は、そのような情報のソースが複数あり得るため、理路整然と提供され得る。このため、いくつかのユーザモジュールといくつかのグループモジュールとがあり得る。ハイレベルから、各々は異なるように構成され得、異なるバックエンドシステムとインタフェースを取り得、おそらくは複数のドメインにわたる権限となり得る。さらに、異なるモジュールをドメイン権限として定義することは、エクストラネット（ｅｘｔｒａｎｅｔ）サポートを提供することの手助けとなり得る。

プリンシパルモジュールのコンフィギュレーションは、適切なクラスファイルを記述し得る。各モジュールはまた、権限がどのようなものであるかを構成する基盤と同様に、連結文字列やプリファレンス（ｐｒｅｆｅｒｅｎｃｅ）のような、いくつかのモジュール依存のコンフィギュレーション情報を有しえる。異なる実施はまた、システムの残りの部分との統合を容易にするため、前処理（ｐｒｅ−ｐｒｏｃｅｓｓｉｎｇ）と後処理（ｐｏｓｔ−ｐｒｏｃｅｓｓｉｎｇ）とを統率するルールを有し得る。

ＡＣＬマネージャ９４０は、任意個のプリンシパルプロバイダのロードに関係のあるコードを含み得る。図１０は、図９からのサーバの例示的な詳細を示すブロック図である。サーバは、主なメモリ内キャッシュを有し、グループメンバーまたは標準的なマッピングに対して、ＡＣＬマネージャ１０１０によって取り扱われ得る。ユーザは、メモリ内に、サービスプロバイダが共通の要求を求められないように、最近の標準的なマッピングを格納し得る。

ＡＣＬマネージャ１０１０はまた、複数のメソッドをまたがる（ｃｒｏｓｓ−ｍｅｔｈｏｄ）コードを含み得、ＡＣＬサービスプロバイダマネージャ１０２０は、ストレージレベル（ｓｔｏｒａｇｅ−ｌｅｖｅｌ）の（例えば、複数のサーバをまたがる）キャッシュに対するトランスパレントなインターフェースであり得る。ＡＣＬサービスプロバイダマネージャ１０２０に対するクエリは、結果として、まず格納プロバイダ１０３０が必要な情報を有しているか否かをチェックし、それを返す。そうでない場合、ＡＣＬサービスプロバイダマネージャ１０２０は、ユーザおよびグループモジュール１０４０に対してクエリを発行し得、できるだけ多くの情報をストレージ層に持続するように試みる。キャッシュエントリは、標準的な結果が返されたことによる期限切れによって変更され得る（例えば、格納プロバイダまたはプリンシパルモジュールのいずれかによって指定されるとき）。

図９を再び参照する。格納サービスプロバイダ９２０は、永続性ストレージ（ｐｅｒｓｉｓｔｅｎｔ ｓｔｏｒａｇｅ）においてデータを生成および検索するために、サーバ９００が用いるメソッドの集まり（ｃｏｌｌｅｃｔｉｏｎ）を記述する、インターフェースを提供し得る。このインターフェースは、システムにおける最大のサービスプロバイダインターフェースであり得、ドキュメントコントロールシステムに新たな統合や特徴が実施された際にさらに大きくなり得る。格納サービスプロバイダ９２０は、以下のエリアにおいて複数のメソッドを提供し得る。（１）ドキュメントチケットの割り当て−サーバ上で保護された各ドキュメントは、ＧＵＩＤ（ｇｌｏｂａｌ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）を用いてチケットを付与され得る、（２）ドキュメントの取り消についての記録、（３）ユーザ、グループ、ドキュメントに対する暗号化キーとルートサーバのキーとのセーブ、（４）ユーザエイリアスとグループメンバーとのデータのキャッシュ、（５）ユーザアクセスの監査と保護、（６）名前の付けられたＡＣＬまたはポリシーの管理と格納、（７）ドキュメントに対する現在のＡＣＬの格納と検索、（８）ドキュメントに対するイニシャルＡＣＬの生成。

格納プロバイダインターフェースは、多種多様なバックエンドシステムを横断する複数の実施を可能にするようにデザインされ得る。このことは、ＯＤＢＣとＪＤＢＣとの両方と協働し得る一般的なリレーショナルデータベース（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ）の実施を用いて実現され得る。加えて、格納プロバイダインターフェースは、Ｄｏｃｕｍｅｎｔｕｍ（登録商標）システムのようなコンテンツマネジメントシステムに対する実施をサポートするようにデザインされ得る。チケットの生成は、単刀直入に行なわれ得る。例えば、このことは、各予約において増加する整数をデータベース内に保持することによって実施され得る。ドキュメントの取り消しは、そのチケットに基づいてドキュメントを取り消す能力として定義され得、付与されたチケットに関連したドキュメントが取り消されたか否かを別々にクエリする。

格納プロバイダはまた、ユーザエイリアスとグループメンバーのデータとに対するストレージを提供し得る。エイリアスとメンバー情報は、アクセスコントロールリストを評価するのに用いられ得る。格納プロバイダ９２０は、アクセスコントロールサービスプロバイダ９３０がこの情報に効果的なアクセスを提供できない場合でさえも、適切なパフォーマンスを保証する手助けとなるキャッシュとして用いられ得る。例えば、限られたケースでは、アクセスコントロール情報は、所要のデータを提供するフラットファイル（ｆｌａｔ ｆｉｌｅ）から来てもよい。ユーザおよびグループのエイリアス情報をキャッシュするとき、格納プロバイダは、ユーザおよびグループプロバイダに酷似したプリンシパルに基づいてクエリの検索を実行し得る。返されたデータは、同一のフォーマットであり得、有効性に関する指標をも提供し得る。ゴールは、サーバがユーザエイリアスまたはグループメンバーに関するデータを用いた際に、提供されたデータがリアルタイムなバージョンまたはキャッシュされたバージョンであるか否かを、サーバが区別し得ないようなものであり得る。

所与のユーザまたはグループに対して、ユーザまたはグループの標準的な名前が入手され得る。ユーザに対し、このユーザが所属しているグループの全てが入手され得る。エイリアスデータの変更は、即座に視覚することが出来る。推移閉包の計算（グループを含むグループのグループメンバーシップ）のため、グループメンバーのキャッシュの変更は、より複雑であり得る。このことから、グループコンテンツの変更は、サーバがグループの推移閉包を目下計算していない場合は、即座に視覚することは出来ない。

ドキュメント保護のオペレーションとドキュメントアクセスの試み（うまくいくか否かに関わらず）は、格納プロバイダ９２０の監査メソッドを通して監査され得る。保護イベントとアクセスイベントとを記録するようにメソッドを定義することに加え、インターフェースは、ドキュメントチケットによっておよびユーザによるクエリするによって、監査ヒストリ上の１組のクエリメソッドをも定義し得る。格納プロバイダはまた、ＡＣＬの生成およびモディファイを可能にする複数のメソッドをも実施し得る。これらのメソッドは、監査ヒストリの情報を維持するために用いられ得る。格納サービスプロバイダ９２０の複数の実施は、関係のあるデータベースを用いること、および／または、監査されたログに関する現存のドキュメントマネジメントシステム（例えば、Ｄｏｃｕｍｅｎｔｕｍ（登録商標）監査証跡物（ａｕｄｉｔ ｔｒａｉｌ ｏｂｊｅｃｔ））の概念を用いることを含めて、必要に応じて実施され得る。

格納プロバイダ９２０は、名前によってＡＣＬを格納したり検索出来たりする。ＡＣＬは、私的なＡＣＬ（例えば、特定のユーザ）であったり、公的なＡＣＬであったりし得る。公的なＡＣＬは、様々なユーザによって保護された複数のドキュメントに横断的にシェアされるべく意図されたポリシーを表現する。格納されたＡＣＬの表現は、格納プロバイダのみにとっての関心事であり、引数にしたがってＡＣＬを取得し、結果にしたがってＡＣＬを返すようにデザインされ得る。ＡＣＬは、アクセスコントロールリストインターフェースの言葉で記述され得る。

格納プロバイダは、ＡＣＬの生成、消去、および検索のためのメソッドのセットを有し得る。メソッドは、名前の付けられたＡＣＬまたはポリシー（例えば、公的なＡＣＬ）のいずれかを記述している引数を取得し得る。これらはまた、所与のドキュメントに（チケットＧＵＩＤを介して）関連した、ＡＣＬに対するメソッドでもあり得る。所与のドキュメントをＡＣＬと関連付ける際、チケットデータもまた用いられ得る。このチケットデータは、特定のドキュメントに特有のものであり得、どのプリンシパルがドキュメントを保護したかと同様に、ドキュメントが保護されたときに、日付（ｄａｔｅ）のようなドキュメント特定情報を格納するのに用いられ得る。複数のドキュメントの間でシェアされるＡＣＬはまた、保護の時間に関連したコントロール、または、ドキュメントを保護した人物に関連したコントロールを指定し得る。チケットデータはまた、セキュアクライアントによって、サービスプロバイダに対応した情報を提供するように用いられ得る。例えば、Ｄｏｃｕｍｅｎｔｕｍ（登録商標）システムの統合において、チケットデータは、ソースドキュメントに対してＤｏｃｕｍｅｎｔｕｍ（登録商標）ＧＵＩＤを提供し得る。サービスプロバイダ情報はまた、サービスプロバイダから受信した、サービスプロバイダに対応するドキュメントの適切な情報的局面を把握するような名前／値の対からなるセットを含む、バイト列であり得る。

名前からＡＣＬを検索するのに加えて、サーバも特定のドキュメントに対するＡＣＬを検索することが出来る。使用するＡＣＬを検索する際、サーバは、パラメータとして、プリンシパルを随意に提供し得る。このことは、ヒントを提供し、最適化された格納プロバイダが、特定のプリンシパルに対して関係のあるＡＣＬの部分集合を返すことが出来るようにする。

ＡＣＬを生成および格納する際、提示されたサービスプロバイダの特定のデータをセキュアクライアントに通す（ｐａｓｓ−ｔｈｒｏｕｇｈ）機会もある。このことは、終端間の機構を提供し、サービスプロバイダに、このドキュメントが特定のＡＣＬのどれを参照するのかについてのヒントを付与し得る。このことは、チケットデータに関連して上記で記述された能力の類似であるが、ドキュメントとは対照的に、ＡＣＬに特有のものであり得る。

格納プロバイダは、必ずしもＡＣＬを解釈しなくてもよい。格納プロバイダは、ＡＣＬについてのいかなる解釈をも行なうことなしに、ＡＣＬを格納したり検索したりし得る。ドキュメントは、生成されたときにイニシャルＡＣＬを付与され得る。上記イニシャルＡＣＬは、ドキュメントに格納され、上記ドキュメントに対する他のＡＣＬがクライアントの近くに存在しない場合のオフラインアクセスコントロールに用いられ得る。格納インターフェースは、メソッドであって、これによって現在のＡＣＬとイニシャルＡＣＬとがサーバのセキュアコンポーネントまたはビューイングコンポーネントに戻される（ｐａｓｓｅｄ ｂａｃｋ）ような、メソッドを提供し得る。一般に、主に２つのケースがあり得る。（１）保護されたコンテンツは、ドキュメントコントロールシステムの他に、いかなる別々のアイデンティティ（ｓｅｐａｒａｔｅ ｉｄｅｎｔｉｔｙ）をも有さない（例えば、コンテンツはｅ−メールの添付である）、（２）コンテンツは、ドキュメントコントロールシステムの他に、アイデンティティを有する（例えば、コンテンツは、Ｄｏｃｕｍｅｎｔｕｍ（登録商標）レポジトリ内のＰＤＦレンディション（ｒｅｎｄｉｔｉｏｎ）である）。後者の場合、サービスプロバイダは、現在のルールの言葉で、コンテンツへのアクセスを動的にコントロールすることが可能である。コンテンツを送達するレポジトリは、上記のルールを、オブジェクトに適用する。さらに、一旦ＡＣＬがセーブされると、ポリシーに関しては、オーナーによって、または、システムアドミニストレータによってモディファイされ得る。

イニシャルＡＣＬと現在のＡＣＬとの両方は、格納サービスプロバイダによって生成され得、コンテンツへのアクセスコントロールは、下部オブジェクト（ｕｎｄｅｒｌｙｉｎｇ ｏｂｊｅｃｔ）上のアクセスコントロールの言葉で媒介され得る。そうでない場合、コンテンツのマネジメントは、オンラインとオフラインの両ケースにおいて、ちょうど一致し得る。加えて、クライアントがどのような（複数の）サービスがサービスプロバイダによってサポートされるのかを見るために用いることが出来るブーリアン・サポートプロバイダ・メソッド（Ｂｏｏｌｅａｎ ｓｕｐｐｏｒｔｓＰｒｏｖｉｄｅｒ ｍｅｔｈｏｄ）が提供され得る。このようにして、クライアントは、どのサービスプロバイダが利用可能であるかについての予想を有することが出来、上記サービスが上記ドキュメントコントロールサーバのコンフィギュレーション（例えば、名前／値の対のどのセットがチケットデータ内のサービスプロバイダ情報に合法的に含まれ得るかを決定する）によって実際にサポートされているかどうかを、サポートプロバイダメソッドから決定することが出来る。サポートプロバイダ（）がいくつかのサービスに対して可である場合、インターフェースの残部が実施され得る。このようにして、カスタマは、ドキュメントレポジトリにおけるドキュメントに対する保護とｅ−メールの添付に対する保護との両方のために、同一のサーバを用いることが出来る。

サーバ９００はまた、暗号化コンポーネント９５０をも含み得る。上記暗号化コンポーネント９５０は、様々なネイティブの暗号化コンポーネント（例えば、Ｊａｖａ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｅｘｔｅｎｓｉｏｎまたは ．Ｎｅｔ Ｃｒｙｐｔｏ ｃｏｍｐｏｎｅｎｔｓ）を活用する２重の実施を有し得る。一般に、ドキュメントコントロールサーバは、いくつかの暗号化プリミティブ（ｃｒｙｐｔｏｇｒａｐｈｉｃ ｐｒｉｍｉｔｉｖｅ）を有し得る。これら暗号化プリミティブの実施は、一般のインターフェースの背後に配置され得、例えば、セキュリティ機能を追加すること、および／または、特定のエンタープライズの要求をアドレス（ａｄｄｒｅｓｓ）することことのように、必要に応じて実施を変更すること（例えば、キーのサイズの変更）が出来るようにする。加えて、これら暗号化プリミティブの実施は、カスタムなオペレーションと同様に標準的な暗号化オペレーションを用い得る。

暗号化コンポーネント９５０のインターフェースは、以下のプリミティブに対するサポートを提供し得る。（１）システム化された暗号化と復号化（例えば、１２８ビットＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）および／または１２８ビットＲＣ４（Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ４））、（２）公開キー暗号化および復号化ならびに署名および照合（例えば、１０２４ビットＲＳＡ）、（３）ドキュメントのインテグリティ（ｉｎｔｅｇｒｉｔｙ）（例えば、１２８ビットキーを有した一方向ＨＭＡＣＳＨＡ１ハッシュ関数）を提供するのに用いられるメッセージ認証コード（ＭＡＣ）、（４）セキュアなハッシュ関数であって、ハッシュが同じ値である２つのメッセージを探すことが計算上実行不可能である、ハッシュ関数（例えば、ＳＨＡ１）。（５）暗号化キーを生成するため、および、メッセージにランダムさを導入するのに用いられ得る乱数生成器（例えば、 ．Ｎｅｔ実施に対する ．Ｎｅｔフレームワークに提供されるＳｅｃｕｒｅ Ｒａｎｄｏｍ ｎｕｍｂｅｒ ｇｅｎｅｒａｔｏｒ、および、Ｊａｖａ実施における乱数を生成するためのｊａｖａ．ＳｅｃｕｒｅＲａｎｄｏｍ ｃｌａｓｓ）。これら暗号化プリミティブは、Ｊａｖａ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｅｘｔｅｎｓｉｏｎ（ＪＣＥ）機構を用いてＪａｖａに実施され得、また、 ．Ｎｅｔサービスプロバイダ機構を用いて１つ以上の ．Ｎｅｔ言語に実施され得る。ドキュメントコントロールシステムにおけるクライアントとサーバとの両方が、暗号化技術を用いることにより、ドキュメントを保護およびアクセスすることが可能であるため、上記暗号化インターフェースと上記暗号化の実施とは、クライアント上でも用いられ得る。暗号化インターフェースはまた、クライアント上で用いられるＣ＋＋で記述された任意の暗号化オペレーションに対しても、Ｃ＋＋で実施され得る。

図１１は、ドキュメントコントロールシステムにおいて用いられ得るオフラインドキュメントアクセスモデルを示すブロック図である。クライアント１１１０は、ネットワーク１１００を介してドキュメントコントロールサーバ１１２０と通信接続され得る。ドキュメントコントロールサーバ１１２０は、伝統的なオフラインアクセスモデルに類似したリースモデル（ｌｅａｓｅ ｍｏｄｅｌ）を含む、複数のオフライン使用モデル（ｕｓａｇｅ ｍｏｄｅｌ）を提供し得る。上記リースモデルでは、ユーザは、ドキュメントに最初にアクセスするときにはオンラインでなければならず、オフラインであるドキュメントに特定の時間の間、すなわち、リース期間の間にアクセスすることが出来る。加えて、ドキュメントコントロールサーバ１１２０は、ドキュメントに最初にアクセスしたときにユーザがオフラインとなり得るイニシャルアクセスモデルを提供し得る。ここで用いられているように、「オンライン」という用語は、クライアント１１１０がサーバ１１２０と通信することが可能なことを意味する。このため、クライアント１１１０は、ネットワーク１１００と接続され、サーバ１１２０は、クライアント１１１０がオンラインであるときに動作可能である。

一般に、クライアント１１１０とドキュメントコントロールサーバ１１２０とは、定期的に同期化し、クライアント１１１０に保持されたオフラインアクセス情報の任意の変更をアップデートする。このオフラインアクセス情報は、効果的な方法で、クライアントに対してあらかじめ権限を付与（ｐｒｅ−ａｕｔｈｏｒｉｚｅ）し、クライアント１１１０が、ネットワーク１１００に接続されている間、まだアクセスされていない保護されたドキュメント（例えば、ｅ−メールを介してクライアントにおいて受信した保護されたドキュメントであって、まだ開かれていないドキュメント）に関連したアクションを行なうことを許容する。クライアント１１１０は、ドキュメントコントロールサーバ１１２０へ要求１１３０を送信する。要求１１３０は、オフラインアクセス情報のアップデートのためのものであり得る。例えば、サーバ１１２０へ定期的に接続を行ない、オフラインアクセス情報のダウンロードを行なうエージェントが、クライアント１１１０と共に提供され得る。この同期化動作は、アップデートに気づいているクライアント１１１０のユーザなしに、バックグラウンドにおいて静的に起こり得る。ユーザが次回ドキュメントを開こうとするとき、ダウンロードされたオフラインアクセス情報は、オフラインの間、将来のアクセスのために、クライアントによって用いられ得る。

要求１１３０は、サーバ１１２０へ定期的に送信された要求であれば、任意のタイプであってよい。例えば、クライアント１１１０からの、ドキュメント１１３５に関連したアクションを行なうような要求であり得る。上記ドキュメント１１３５は、クライアント１１１０または他の場所に配置され、かつ、保護された、または、保護されていない、ドキュメントであり得る。サーバ１１２０は、要求１１３０に関連して、クライアント１１１０において認証された、ユーザを照合し得る。また、この認証されたユーザについての照合は、イニシエートのための同期化動作を引き起こし得る。例えば、サーバ１１２０は、上述の任意のサーバのようなものであり得、同期化動作は、（例えば、オンラインの間にユーザがドキュメントにアクセスまたは保護しようと試みるとき）認証を用いたその他の動作に便乗したもの（ｐｉｇｇｙｂａｃｋ）であり得る。代替的に、同期化は、先の認証なしに起こり得る。サーバ１１２０は、ユーザの公開キーを用いてオフラインアクセス情報を暗号化し、上記ユーザしかそれらを復号化することが出来ないようにし得る。暗号化されたオフラインアクセス情報は、クライアント１１１０によって保持され得、上記保持された情報は、ユーザが次回ドキュメントを開こうとした際に、復号化され、クライアントの保護されたローカルデータベースをアップデートするために用いられ得る。このことは、以下で記述される。

クライアント１１１０がサーバ１１２０と同期化するとき、サーバ１１２０は、
現在のユーザが所属しているユーザのグループに関連したキー１１４５を含んだオフラインアクセス情報１１４０を送信し得る（キーの絵は、１つ以上の暗号化キーを象徴的に表現するために用いられている）。キー１１４５は、オフラインの間、電子ドキュメント１１５０における第２のキーを復号化することによって、保護された電子ドキュメント１１５０へアクセスするように用いられ得る。電子ドキュメント１１５０は、キー１１５５によって暗号化されたコンテンツを含み得、電子ドキュメント１１５０は、キー１１４５によって暗号化されたキー１１５５を含み得る。代替的に、上記のキー暗号化に関して、１レベル以上の間接的方法が存在し得る。例えば、キー１１４５は、キー１１５５を復号化するのに用いられ得る。キー１１５５は、ドキュメント１１５０のコンテンツを復号化するのに用いられ得る別のキーを復号化するために用いられ得る。間接的方法のレベル数と用いられるキーの個数とに関係なく、ユーザのグループに関連したキー１１４５は、オフラインの間、電子ドキュメント１１５０における第２のキー１１５５を復号化することによって、保護された電子ドキュメント１１５０へアクセスするために用いられ得る。加えて、オフラインアクセス情報１１４０は、グループ特有のその他のキーと、１つ以上のユーザ特有のキーと、複数のドキュメントに関連した少なくとも１セットのドキュメント・パーミション情報（例えば、上述されたようなポリシー）と、ドキュメント取り消しリストとを含み得る。

同期化動作はまた、オフラインの間にクライアントによって実行されたオペレーションのオフライン監査ログ（ｏｆｆｌｉｎｅ ａｕｄｉｔ ｌｏｇ）１１６０をサーバ１１２０へ返信するクライアント１１１０をも含み得る。これにより、クライアントは、サーバと定期的に同期化し、局所的に保持された監査ログメッセージをアップロードし、最新の取り消しリストと、ポリシーに対する任意のアップデートとを、ダウンロードすることが出来る。上述されたような複数のＡＣＬを用いたシステムにおいては、潜在的に多数のＡＣＬがシステムに存在するため、必ずしも、新しいＡＣＬの全てが、各同期化を用いてダウンロードされない。ドキュメントコントロールシステムは、データの新鮮さに関する保証についての、制約されたセットを提供し得る。用いられ得る保証は、以下の通りである。（１）ドキュメント特有のＡＣＬとポリシーとが、オフラインの有効期間を指定する（例えば、ドキュメント特有のＡＣＬが、サーバとの間の別の同期化を行なう以前に有効であるような、一定の時間または日数が必要とされ、その時間または日数の後、ドキュメントは、同期化することなしにはオフラインで視覚され得ない）。（２）各同期化において、取り消しおよびポリシーのアップデートの全てが、クライアントにおいて同期化される。これにより、ポリシーまたは取り消しのリストは、人気のあるドキュメントに対しては期限切れの、高々特定数のタイムユニットであり得る。さらに、上記同期化はまた、オンライン中にアクセスされた任意のドキュメントに対する現在のＡＣＬを送信し得る。

図１２は、サーバによって実行される同期化動作を示すフローチャートである。１２００において、要求が受信される。１２１０において、サーバは、上記要求に応答して、アップデートが必要であるか否かを決定する。例えば、サーバは、最後に記録されたクライント同期化の時間と、ユーザに対するユーザグループ情報における最後の変更の時間とを比較し得る。あるいは、サーバは、ユーザに対する現在のユーザグループ情報と、クライアントから受信した、ユーザに対するユーザグループ情報とを比較し得る（例えば、クライアントは、サーバを、現在サーバに保持されているユーザおよびグループのキーに基づいて識別し得る。また、サーバは、クライアントに保持されているキーについてのなんらかの変更が要求されているか否かに基づいて、応答し得る）。

１２２０において、アップデートが必要な場合、サーバは、オフラインアクセス情報を送信する。このことは、削除（ｒｅｍｏｖｅ）のためのキーと局所的な追加（ａｄｄ）のためのキーとに関するリストを、サーバがクライアントに送信することを含み得る。１２３０において、いかなるアップデートも必要とされていない場合、サーバは、現在のユーザグループ情報に関する妥当性検証（ｖａｌｉｄａｔｉｏｎ）を送信し得る。これにより、現在のオフラインアクセス情報が有効であることと、現時点でクライアントとサーバとが同期化していることとを、クライアントに示し得る。加えて、１２２０においてサーバがオフラインアクセス情報を送信した場合、または、１２３０においてクライアントのオフラインアクセス情報を再度妥当性検証した場合、上記サーバはまた、サーバ参照時間を送信し得る。上記サーバ参照時間は、クライアントにおいて記録され、将来クライアント−サーバ間の同期化が再度必要とされるのはいつであるかを決定するために用いられるべき時間である。最後に、１２４０において、サーバは、オフライン監査ログをクライアントから受信する。その結果、上述のように、サーバは、オフラインの間、ドキュメントに関連して行われるべきアクションに関連した情報を含んだ監査を生成し得る。

図１３は、クライアントによって実行されるべき同期化動作を示すフローチャートである。１３００において、第１のキーを含むオフラインアクセス情報が受信され、クライアントがネットワークに接続された際、オフライン監査ログがサーバにアップデートされる。１３１０において、クライアントは、オフラインアクセス情報を保持する。暗号化キーとその他の機密情報（ｓｅｎｓｉｔｉｖｅ ｉｎｆｏｒｍａｔｉｏｎ）は、例えば、攻撃者がそのような情報を容易に獲得することが出来ないように、安全な方法で、ユーザのマシンに局所的に保持され得る。

セキュリティは、例えば、Ｎｅｗ Ｙｏｒｋ，ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎによって提供された、スマートカード、または、埋め込み型のセキュリティチップのような、改ざん防止ハードウェア（ｔａｍｐｅｒ−ｒｅｓｉｓｔａｎｔ ｈａｒｄｗａｒｅ）に格納された暗号化キーを用い、ファイルを暗号化することによって提供され得る。ハードウェアの改ざん防止ストレージが利用可能でない場合、なんらかのセキュリティを提供するため、ソフトウェア難読化技術（ｓｏｆｔｗａｒｅ ｏｂｆｕｓｃａｔｉｏｎ ｔｅｃｈｎｉｑｕｅ）が用いられ得る。クライアントに保持されたデータは、ユーザおよびクグループのプライベートキーと、ドキュメント取り消しリストと、ポリシーに対してアップデートされた複数のＡＣＬと、ドキュメントに対してアップデートされた複数のＡＣＬとセキュリティデータとを含み得る。クライアントは、オンライン中にアクセスされ、オペレーションについてのオフライン監査ログは、オフライン中にクライアントによって実行される。

１３３０において、クライアントがネットワークに接続されていない際、ドキュメントにアクセスするような要求が受信される。決定１３４０において、最近にサーバ同期化が発生したか否かを決定するためのチェックが行なわれ得る。例えば、クライアントは、現在の時刻とオフラインアクセス情報の受信時刻（ｒｅｃｅｉｐｔ ｔｉｍｅ）との間の差が、サーバ同期化周期のパラメータを上回るかどうかをチェックし得る。サーバ同期化周期のパラメータは、アクセスされるべきドキュメントに特有のものであり得る。さらに、現在の時刻を決定することは、最新の既知の同期化時刻とローカルシステムクロックとの比較を行うことを含み得る。

１３５０において、サーバとの間の同期化が十分最近に発生しなかった場合、クライアントは、ドキュメントへのアクセスを防止し得る。１３６０において、十分最近に同期化が発生した場合、ドキュメント内の第２のキーを暗号化するために第１のキーが用いられる。１３７０において、電子ドキュメントに関連したアクションは、電子ドキュメントに関連したドキュメント・パーミション情報に基づいて統率され得る。電子ドキュメントに関連したアクションを統率することは、ドキュメントパーション情報を電子ドキュメント自身から入手することを含み得る。電子ドキュメントに関連したアクションを統率することは、電子ドキュメント内のドキュメントポリシー参照（ｄｏｃｕｍｅｎｔ ｐｏｌｉｃｙ ｒｅｆｅｒｅｎｃｅ）を識別することと、ドキュメントポリシー参照に基づいて、局所的に保持されたドキュメント・パーミション情報を入手することとを含み得る。加えて、１３８０において、ドキュメントアクセスと、試みられたドキュメントアクセスとの両方を記録し得る、オフライン監査ログが維持され得る。

図１４は、保護されたドキュメント１４００のコンポーネントを示すブロック図である。保護されたドキュメント１４００には、暗号辞書（ｅｎｃｒｙｐｔ ｄｉｃｔｉｏｎａｒｙ）１４０５が含まれ得る。暗号辞書１４０５は、ドキュメント１４００のコンテンツにアクセスするために用いられ得る暗号化キーと、オンラインの際に接続するための、サーバのアドレス（例えば、ホスト名、ポート番号、および、接続プロトコル）とを含み得る。暗号辞書１４０５は、暗号化ドキュメント１４００の、ドキュメントを暗号化するのに用いられる（つまり、ドキュメントのコンテンツを暗号化するのに用いられる）ドキュメントキーによって暗号化されていない位置に埋め込まれ得る。

例示的な暗号辞書１４１０は、ドキュメントパーミション情報１４２０（例えば、上述のイニシャルＡＣＬ）、および／または、１つ以上の暗号化されたドキュメントキー１４３０を含む。ドキュメント１４００のコンテンツを暗号化するのに用いられるドキュメントキーは、グループキーとユーザキーとを用いて複数回暗号化され得、これら暗号化されたドキュメントキー１４３０は、保護されたドキュメント１４００における暗号辞書１４０５に含まれ得る。ドキュメントコントロールサーバは、ドキュメントコントロールシステムにおけるユーザおよびグループに対する、ユーザおよびグループのキーを動的に生成し、維持することが出来る。暗号化されたドキュメントキー１４３０とドキュメントパーミション情報１４２０とをドキュメント１４００に含めることにより、上述の同期化動作を用いてクライアントに適切なユーザおよびグループのキーを提供することによって、オフラインアクセスがサポートされ得る。

別の例示的な暗号辞書１４４０は、ドキュメントキー１４５０と、ＡＣＬ１４６０と、ドキュメントチケット１４７０と、バージョン情報１４８０（例えば、フォーマットバージョン文字列）と、暗号化されたセッションキー１４９０とを含み得る。ドキュメントキー１４５０は、ドキュメントコントロールサーバによって生成され、（例えば、ＲＣ４またはＡＥＳ暗号化を用いて）ドキュメントコンテンツを暗号化するのに用いられ得るランダムな１２８ビットキーであり得る。暗号辞書１４４０の一部は、生成されたセッションキーを用いて暗号化され得、ＭＡＣは、暗号辞書についての任意の改変を検出するために用いられ得る。暗号化されたセッションキー１４９０は、グループキーとユーザキーとを用いて複数回暗号化されたセッションキーであり得る。加えて、セッションキーは、サーバの公開キーを用いて暗号化され得る。

ユーザがオフラインのドキュメントを開こうとする際、クライアントは、ユーザのキー、または、上記ユーザがメンバーである任意のグループのグループキーを用いて、ドキュメントに対するセッションキーが、暗号化されているか否かを確認し得る。クライアントは、サーバとの同期化の間に、ユーザのキーと、上記ユーザがメンバーである全てのグループのキーとを入手し得る。その後、ドキュメントの暗号辞書における情報を暗号化するために、適切なキーが用いられる。その後、クライアントは、ユーザがどのパーミションを有しているのかを決定するために、ＡＣＬがサーバ上で評価されたのと同様な方法で、ＡＣＬを評価し得る。クライアントの取り消しリストがチェックされ得る。ドキュメントが取り消しされず、有効期限が切れていない場合、ドキュメントが開かれ得、ドキュメントへのユーザのアクセスが局所的に監査され得る。

このイニシャルアクセスモデルは、ユーザがドキュメントに初めてアクセスする際に、彼らをオフラインにすることが出来る。ドキュメント１４００が保護された際、ドキュメント内では、ドキュメントに対するイニシャルＡＣＬが埋め込まれ得、不変（ｉｍｍｕｔａｂｌｅ）になり得る。ユーザがドキュメントを開こうとする際、埋め込まれたＡＣＬが、アクセスを有しているか否かを決定するために用いられ得る。さらに、ドキュメント１４００は、イニシャルＡＣＬがドキュメント内に保持されている場合でさえも、取り消し、または、有効期限が満了し得る。さらに、他の場所に維持されている、ドキュメント１４００に対する現在のＡＣＬが、アップデートされ得、上述のように、クライアントがオンラインの際、このＡＣＬが用いられ得る。

ユーザがオンラインのドキュメントにアクセスする際、サーバ上に格納され得る現在のＡＣＬは、クライアント上に保持され、上記のアクセスのために用いられ得る。その後、保持されたＡＣＬは、ドキュメントへの将来のオフラインアクセスのために用いられ得る。クライアントがアップデートされたＡＣＬをサーバから入手する際、クライアントは、ドキュメントへアクセスすることが出来るユーザとグループとの各々に関するキーを用いて個別に暗号化されたセッションキーをも入手し得る。ＡＣＬと暗号化されたキーとの両方は、当所ドキュメントに埋め込まれたのと同様な方法で、保護され得る。

さらに、ドキュメントにおけるドキュメントパーミション情報１４２０，１４６０は、ポリシー、すなわち、ドキュメントポリシー参照（ｄｏｃｕｍｅｎｔ ｐｏｌｉｃｙ ｒｅｆｅｒｅｎｃｅ）または識別子を含み得る。このため、クライアントは、オフライン中に、電子ドキュメント内のドキュメントポリシー参照を識別し得、ドキュメントポリシー参照に基づいて、局所的に保持された、ポリシーのドキュメントパーミション情報を入手し得る。ドキュメントコントロールシステムは、ポリシーのアップデートの全てが各クライアントサーバの同期化を用いてクライアントに反映されることを保証し得る。このため、アドミニストレータはポリシーを変更し得、いまだに任意のドキュメントにアクセスを提供している全クライアントに対して変更が反映され得ることを、有界な時間内で知ることが出来る。

上述のイニシャルオフラインアクセスモデルに加えて、伝統的なリースモデルもまた、ドキュメントコントロールシステムにおいて用いられ、追加的なフレキシビリティーを提供し得る。このモデルにおいて、ユーザが特定のマシンから最初にドキュメントにアクセスすると、彼らはオンラインになり得る。その際、ユーザは、オフラインリース（ｏｆｆｌｉｎｅ ｌｅａｓｅ）を受信する。上記オフラインリースは、リースが更新される前、ユーザが、オフライン時間の間に、特定の期間にわたってドキュメントを視覚することを許容する。そのようなリースモデルは、イニシャルＡＣＬの埋め込みによって記述される、ドキュメントコントロールシステムに実施され得る。イニシャルＡＣＬは、どのプリンシパルへのアクセスも許容しない。新しいＡＣＬがサーバによってフェッチされる必要が生じる前に、どのくらいの長さにわたってＡＣＬがクライアントに保持され得るかを指定するｖａｌｉｄｉｔｙ＿ｉｎｔｅｒｖａｌを用いる。加えて、ドキュメントコントロールシステムは、ユーザが、ドキュメントにアクセスするためにオンラインとなるような非オフライン・アクセスモデルを実現するように構造化可能である。このケースでは、ドキュメントを開くために必要なキーは、クライアントに保持される必要はない。

ドキュメントコントロールシステムは、さらに以下の安全保障（ｓｅｃｕｒｉｔｙ ｇｕａｒａｎｔｅｅ）を併せて用い得る。（１）ポリシーモディフィケーション−ポリシーの全てが全同期化動作において同期化されるため、ポリシーにおいて指定されるｏｆｆｌｉｎｅ＿ｖａｌｉｄｉｔｙ＿ｉｎｔｅｒｖａｌにおいて、各クライアント上に、ポリシーモディフィケーションが反映されることが保証される。（２）ＡＣＬモディフィケーション−モディファイされた（非ポリシー）ＡＣＬは、オンラインの間に視覚された場合に限り、クライアント上に反映され得る。保持された非ポリシーＡＣＬは、ＡＣＬにおいて指定される場合、ｖａｌｉｄｉｔｙ＿ｐｅｒｉｏｄ内で、クライアントから除外されることが保証される。（３）取り消し−全ての同期化動作において取り消しがクライアントと同期化されるため、取り消されたドキュメントは、ドキュメントのＡＣＬにおいて指定されるｏｆｆｌｉｎｅ＿ｖａｌｉｄｉｔｙ＿ｉｎｔｅｒｖａｌにおいて、システム内の全クライアントから視覚不能になることが保証される。（４）期限切れ−ユーザがオンラインであるかオフラインであるかに関わらず、失効日において、期限切れになったドキュメントは視覚され得ない。（５）期限切れのモディフィケーション−ＡＣＬにおいて期限切れが指定される。このため、期限切れは、ポリシーまたはＡＣＬのモディフィケーションによって、反映され得る。（６）ユーザまたはグループのモディフィケーション−（例えば、ユーザが会社を退職するために）ユーザのキーが取り消された場合、または、ユーザがグループから抹消された場合、ユーザは、ｏｆｆｌｉｎｅ＿ｖａｌｉｄｉｔｙ＿ｉｎｔｅｒｖａｌ内にもはやアクセスをしないドキュメントを、視覚することが不可能になり得る。

図１５は、サーバに採用されるドキュメント情報送達技術を示すフローチャートである。１５００において、クライアントに対する第１の電子ドキュメントに関連したアクションを行うような要求は、サーバにおいて受信される。１５１０において、要求に応答して、第１の電子ドキュメントの関連情報が識別される。上記関連情報は、第１の電子ドキュメントとは異なり、かつ、関連した、第２の電子ドキュメントを識別し得る。この情報は、２つ以上のドキュメントを関連付けし得、それらの間の関係を記述し得る。この関連情報は、サーバにおいて、例えばテーブルまたはデータベースに格納され得る。１５２０において、第２の電子ドキュメントに関する情報がクライアントに関係付けられ、行われるべきアクションが容易に行われるように得る。

第２のドキュメント情報をクライアントに関係付けることは、第２のドキュメント情報をクライアントに送信し、アクションに関連して第１または第２のドキュメントのうちの１つを選択することを含み得る。第２のドキュメント情報をクライアントに関係付けることは、第２の電子ドキュメントを入手し、第２の電子ドキュメントをクライアントに送信し、第１の電子ドキュメントに代わって第２の電子ドキュメントに関連したアクションを行うことが出来るようにすることを含み得る。第２のドキュメントは、既に存在し得るか、全体、あるいは、一部が生成されることが所望され得る。このことは、第２のドキュメントを示す関連情報によって示され得る。

図１６は、ドキュメントコントロールシステムにおけるワークフローを示すブロック図である。クライアント１６１０は、ネットワーク１６００を介してドキュメントコントロールサーバ１６２０と通信接続され得る。クライアント１６１０は、要求１６３０をドキュメントコントロールサーバ１６２０に送信し得る。上記要求１６３０は、ドキュメント１６４０に関連して行われるべきアクションに関係している。サーバ１６２０は、局所的に、または、他の場所に格納され、ドキュメント１６４０に関連し、第２のドキュメントの１６５０を示している、情報１６４５をチェックし得る。その後、サーバ１６２０は、情報１６５５を送信し得る。上記情報１６５５は、第２のドキュメント１６５０についての情報、および／または、第２のドキュメント１６５０自身であり得る。

クライアント１６１０は、情報１６５５に基づいて、第２のドキュメント１６５０をユーザに視覚させ得る。例えば、第２のドキュメント１６５０は、第１のドキュメントの新しいバージョンであり得、情報１６５５は、ドキュメントパーミション情報を含み得る。上記ドキュメントパーミション情報は、第１のドキュメント１６４０に関連したアクションが許可されていないことを特定し得る。第１のドキュメント１６４０は、クライアント１６１０によって、場合によってはユーザの知識なしに、（例えば、第１のドキュメントに代わって開かれた、および／または、第１のドキュメント上のストレージに書かれた）第２のドキュメント１６５０に置き換えられ得る。第２のドキュメント１６５０はまた、第１のドキュメント１６４０とは異なる言語バージョン（例えば、英語のオリジナルに対するフランス語バージョン）、または、異なるフォーマットバージョン（例えば、異なるファイル圧縮スキーム、および／または、暗号化スキーム）であり得る。

サーバ１６２０において第２の電子ドキュメント１６５０を入手することは、第２の電子ドキュメント１６５０の少なくとも一部を生成することを含み得る（ドキュメント１６５０の全体を生成することも潜在的に含み得る）。あるいは、ドキュメント１６５０は、既存のドキュメントであり得る。関連情報１６４５は、ユーザベースの関連情報を含み得、ドキュメント１６５０を入手することは、ユーザベースの関連情報とクライアント１６１０において識別されたユーザとに基づいて、ドキュメント１６５０を入手することを含み得る。ドキュメント１６５０は、特定のユーザ、上記ユーザの位置、および／または、上記ユーザのアクセスの時間に対して、カスタマイズされ得る（例えば、ドキュメント１６４０は、送信された際に既に期限切れとして識別された、スタブドキュメント（ｓｔｕｂ ｄｏｃｕｍｅｎｔ）であり得る。また、このドキュメントが開かれたとき、各ユーザは、アクセスが試みられた際に、ユーザ用に生成された新しいドキュメントを自動的に受信し得る。すなわち、スタブドキュメントは、オペレーティングシステムにおける正規のドキュメントに類似し、正規のドキュメントとして操作され得るが、オンラインの際には常に最新である）。ドキュメント１６５０のカスタマイズは、サーバ１６２０または他の場所において行われ得る。上述のように、ユーザが識別され得る。ドキュメントコントロールシステムはまた、本特許明細書を通して記述されているシステムおよび技術を採用し得る。ドキュメント１６４０，１６５０は、上述の保護されたドキュメントであり得る。

図１７は、クライアントに採用されるドキュメント情報受信技術を示すフローチャートである。１７００において、局所的に保持された分散ドキュメントが開かれる。上述のように、上記分散ドキュメントは、接続するドキュメントコントロールサーバを識別する、保護されたドキュメントであり得る。１７１０において、分散ドキュメントから識別されたドキュメントコントロールサーバが接続される。上記サーバは、分散ドキュメントが適切なドキュメントであるか否か、または、異なる関係したドキュメントが代わりに用いられるべきかを決定し得る。１７２０において、ドキュメントコントロールサーバから受信した情報に基づき、ドキュメントアクションに関連して、分散ドキュメントの代わりに、第２のドキュメントの使用が強いられる。

これにより、ドキュメントコントロールサーバシステムは、ドキュメントセキュリティのイシュー（ｉｓｓｕｅ）と、あるシステムにおけるバージョンマネジメントとの両方にアドレスし得る。分散バージョンの代わりに、異なるバージョンの分散ドキュメントが視覚される得る場合、このことは、分散ドキュメントに対するドキュメントセキュリティをも扱うドキュメントコントロールサーバにおいて定義され、コントロールされ得る。ドキュメントの著者は、ドキュメントの分散バージョンの期限切れを指定し得、新しいバージョンが代わりに視覚され得る。さらに、著者は、ドキュメントの複数のバージョンと、誰がそのバージョンを視覚しているかについてのユーザベースの定義とを容易にコントロールし得る。

著者またはアドミニストレータは、どの受取人に対してどのドキュメントが適切なバージョンであるかを指定し得る。上記の指定は、二人のユーザが異なるコンテンツを有した完全に異なるドキュメントを受信する可能性と、二人のユーザの両者がもともとの分散ドキュメントに関連しているという意味においてどのドキュメントが異なるバージョンであるかとを含む。ドキュメントとの間のバージョンの関係は、ドキュメントセキュリティの目的で生成されたドキュメント識別子を用いて指定され得る。バージョンの関係は、有向グラフを用いて定義され得る。上記有向グラフにおいては、各ノードがバージョンを表し、有向エッジ（ｄｉｒｅｃｔｅｄ ｅｄｇｅ）がどのバージョンが優先されるかを示す。各エッジはまた、どのユーザがそれを適用するかを示し得る。例えば、他のバージョンの支持を受けてどのバージョンが有効期限切れになるかを特定するため、ドラッグ・アンド・ドロップ動作によって、バージョンの関係を定義するための図式を表示するグラフィカルユーザインターフェースが用いられ得る。

ドキュメントの異なる一連のバージョンについての文脈で、ドキュメントが受信され、各ユーザが最新バージョンのドキュメントのみを視覚することが保証され、ドキュメントが別のものに置き換えられるか否かを含むように、ドキュメントコントロールシステムにおける取り消しの概念が拡張され得る。このため、ドキュメントを開いた際、ユーザがドキュメント上での伝統的なアクション（例えば、印刷等）を実行するようなアクセスを有しているか否かをチェックすることに加え、上記ユーザがドキュメントの特定のバージョンに対するアクセスを有し得るかについての決定が行なわれ得る。サーバ１６２０は、ドキュメントがどこで探されべきかについての情報を格納し得る。上記情報は、潜在的に、追加的なレポジトリのサービスの提供に関する情報を含む。上記情報は、永続的なバージョンのドキュメントが格納され得る、追加的なレポジトリに関するサービスを、潜在的に提供することを含み得る。

各ユーザが異なるバージョンを視覚し得る場合において、興味のあるユーザ／グループを特定する能力を追加することによって、同様なアプローチが用いられ得る（例えば、「バージョン・ゼロに代わり、全従業員はバージョンＡを視覚し、全マネージャはバージョンＢを視覚し、役員はバージョンＣを視覚し得る」。ここに、追加的なバージョン関係性情報は、バージョンＣに加え、バージョンＡとＢの付随的なバージョンを役員が開き得ることを明記する）。矛盾を解決するためのルールが提供され得る。

ここで述べられているシステムと技術は、複数のドキュメントコントロールサーバを用いた包括的なドキュメントコントロールシステムと組み合わされ得る。図９を再び参照する。ドキュメントコントロールサーバ９００は、上述の様々な技術を、組み合わせることによって実施し得る。システムのセキュリティを向上させるため、クライアント−サーバ間通信の全ては、通信を暗号化し、サーバ認証、および／または、クライアント側の保護を用いて実行されるべきドキュメントの保護を提供するため、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）上で行なわれ得る。サーバ９００は、攻撃者から実体的に保護され得、少なくとも１つのファイアウォール越しに存在し得る。安定なストレージに永在（ｐｅｒｓｉｓｔ）する前に、サーバ９００における機密情報の全てが暗号化され得る。ここで用いられる暗号化キーは、無名の（ｏｂｓｃｕｒｅ）システムリソースに隠れてサーバコードに埋め込まれ得、および／または、改ざん防止暗号化モジュールに格納され得る。さらに、クライアント側では、認証が必要な複数の一貫した動作に対して繰り返し認証が行なわれることを防ぐように、ユーザのログオン・クレデンシャルがキャッシュされ得る。キャッシュされたクレデンシャルは、この目的にのみ使用される、サーバのプライベートキーによって署名され、クライアント上に常駐し得る。署名されたクレデンシャルは、有効期間を制限する有効期限を含み得、クライアントがサーバ９００に対して認証しようとする際に提示され得る。

上述のように、ドキュメントは、サーバまたはクライアントのいずれかの上で保護され得る。保護される前に、ドキュメントは、あるフォーマットから別のフォーマットへ（例えば、ＭｉｃｒｏｓｏｆｔＷｏｒｄ（登録商標）からＰＤＦへ）変換され得る。このために、ドキュメントコントロールシステムがＰＤＦ生成サービスと統合され得る。セキュアラ・コンポーネント９６０と９９０とは、ＰＤＦドキュメントを、暗号化キーと、ＰＤＦドキュメントの暗号辞書内に埋め込まれた情報を表す名前／値の対のセットと同様に、入力として受け取る、ＰＤＦライブラリの周りのラッパー（ｗｒａｐｐｅｒ）であり得る。セキュアラは、提供された暗号化キーを用いてドキュメントを暗号化し、特定の情報をドキュメントに埋め込み得る。サーバ９００上で保護が実行された際、上記保護は、個別のプロセスで実行され得る。そのようなプロセスのプールは、複数の保護要求が同時に満足されるように、入手可能なままにされ得る。そのようなプロセスの最大数は、サーバ９００に対するコンフィギュレーション・オプション（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎ）であり得る。これら保護プロセスは、保護動作が数回成功した後に終了し得る。上記回数もまた、コンフィギュレーションオプション、または、任意の失敗した保護動作であり得る。

図１８は、図９のドキュメントコントロールサーバにおけるドキュメント保護のワークフローを示すブロック図である。一般に、ドキュメントの保護は、２つのハイレベル動作を含み得る。ドキュメントの保護に関連したシステム状態を用意することと、関係のある情報をドキュメントに埋め込み、それを暗号化すること。状態を用意することは、どのようにしてドキュメントが保護され得るかと、保護されたドキュメントに対してシステムを用意し得るサーバとを指定し得る、セキュアクライアント間のジョイント動作であり得る。ドキュメントに情報を埋め込み、保護することは、サーバ上で実行される（例えば、暗号化されていないドキュメントが、保護される際にサーバへ向けて送信され、暗号化された形態がクライアントに戻される）、または、クライアント上で実行される（例えば、クライアントは、ドキュメントを暗号化するのに必要なコンポーネントを有する）のいずれかによる。

セキュアクライアントは、保護されるべきドキュメントに対する所望のセキュリティについての仕様を用意し得る。このことは、例えば、Ｗａｓｈｉｎｇｔｏｎ，ＲｅｄｍｏｎｔのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるＯｕｔｌｏｏｋ（登録商標）ソフトウェアのようなクライアントにおける、エンドユーザのやり取りを含み得る。上記クライアントは、ＲＰＣを介してサーバと接続され、認証を行い、サーバへ向けて情報を送信し得る（１８００）。システムがサーバ側の保護を用いている場合、クライアントは、暗号化されていないドキュメントと保護についての仕様とをサーバへ送信し得る。システムがクライアント側の保護を用いる場合、仕様のみが送信される必要がある。

サーバは、ユーザがドキュメントを保護するためのパーミションを有していることを保証することによって、上記ユーザを認証し得る（１８０５）。サービスプロバイダは、ドキュメントに対してチケット（ＧＵＩＤ）を提供し得る（１８１０）。アクセスコントロールマネージャがプリンシパルを標準化し、ことによるとパーミションを有効化するように、アクセスコントロールリストの仕様が、アクセスコントロールマネージャに付与され得る（１８１５）。ＡＣＭは、最初、標準マッピングのメモリ内キャッシュを用いようとする。ストレージプロバイダは、他のキャッシュされた標準マッピングに対し、クエリされ得る（１８２０）。プリンシパルプロバイダは、キャッシュされていない非標準的なエントリの全てに対してクエリされ得る（１８２５）。標準化されたＡＣＬは、ストレージプロバイダに永在し、ＡＣＬに関する一連のモディフィケーションを許容する（１８３０）。

暗号化され、ドキュメントに格納されるべき情報（例えば、チケットおよびＡＣＬ）が、ドキュメントを暗号化するのに用いられ得るドキュメントキーを生成する、Ｃｒｙｐｔｏ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒに提供され得る（１８３５）。ドキュメントシュレッディングが所望されない場合、ドキュメントキー、チケット、およびＡＣＬが、サーバの公開キーを用いて暗号化され得る。シュレッディングが所望される場合、上記キーがサーバに残され得ないため、ドキュメントキーは暗号化され得ない。システムがサーバ側のセキュリティを用いない場合、暗号化モジュールから暗号化されたチケットデータがドキュメントに埋め込まれ得、ドキュメントを暗号化するために、ドキュメントキーが用いら得る（１８４０）。上記システムがクライアント側の保護を用いる場合、このことは必要とはされない。

システムは、ドキュメントが保護されていることを監査し得る（１８４５）。上記システムがサーバ側の保護を用いる場合、暗号化されたファイルがクライアントへ戻され得る（１８５０）。そうでない場合、暗号化されたチケットデータとドキュメントキーとが、クライアントに戻され得る（１８５０）。システムがクライアント側の保護を用いる場合、クライアント上のドキュメントセキュアラは、暗号化されたチケットデータを埋め込み、クライアント上のドキュメントキーを用いてドキュメントを暗号化し得る（１８５５）。

図１９は、図９のドキュメントコントロールサーバにおける、サーバ側のＡＣＬ評価ワークフローを示すブロック図である。サーバは、パーミションを含んだオペレーションを実行する際、まず、認証されたユーザの身元を決定し得る（１９００）。ドキュメントにおける、暗号化されたサーバコントロール情報が、復号化され得る（１９１０）。ストレージサービスプロバイダから最新のドキュメントＡＣＬを検索するため、暗号化されたコントロール情報におけるチケットが用いられ得る（１９２０）。アクセスコントロールマネージャは、どのパーミションが認証されたユーザに関係があるかを決定することにより、ＡＣＬを評価し得る（１９３０）。上記ＡＣＬは、グループを参照する。このため、ストレージプロバイダは、クエリされ、ユーザがどのグループに所属しているかを決定し得る（１９４０）。

図２０は、図９のドキュメントコントロールサーバにおけるオンラインドキュメントビューイングのワークフローを示すブロック図である。オンラインの間にドキュメントを視覚することは、２つの主要な段階を含み得る。第１の段階は、認証されたユーザがどのパーミションを有しているかを決定することを含む。第２の段階は、クライアント上のドキュメントを復号化するドキュメントキーを戻すことを含む。ドキュメントがオンランで視覚されるべき場合、ビューイングアプリケーションは、保護されたドキュメントを開き、上記ドキュメントがコントロールサーバに関連していることを認識し得る（例えば、ドキュメントは、ビューイングクライアントにおけるセキュリティハンドラを含み得る）。ビューイングアプリケーションは、サーバＲＰＣを用い、ドキュメントにおける暗号辞書内にある、暗号化されたコントロール情報を、サーバへ転送し得る（２０００）。図１９と関連して上述されたように、上記サーバは、上記ＡＣＬを、パーミションを含むオペレーションとして評価し得る（２０１０）。その後、このドキュメントが取り消されていないことを保証するため、ストレージプロバイダがクエリされ得る（２０２０）。コントロール情報から、ドキュメントキーが抽出され得る（２０３０）。サーバは、このドキュメントのオンラインビューイングを監査し得る（２０４０）。ドキュメントキーと同様に、上記ドキュメントを視覚するためのルールである最新のＡＣＬが、ビューイングクライアントに戻され得る（２０５０）。その後、ビューイングアプリケーションがパーミションを実施する（例えば、セキュリティハンドラは、どのパーミションを実施するかをビューイングアプリケーションに通知し、ドキュメントが視覚可能となるように、復号化キーを提供し得る）。

図２１は、図９のドキュメントコントロールサーバにおける取り消しワークフローを示すブロック図である。クライアントは、暗号化されたコンとロール情報をサーバへ送信し得る（２１００）。図１９と関連して上述されたように、サーバは、認証されたユーザがドキュメントを取り消すためのパーミションを有しているか否かを決定し得る（２１１０）。その後、サーバは、ドキュメントの取り消しを実行し得る（２１２０）。クライアントは、確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信し得る（２１３０）。

図２２は、図９のドキュメントコントロールサーバにおける、監査イベント検索ワークフローを示すブロック図である。クライアントは、暗号化されたコントロール情報をサーバへ送信し得る（２２００）。図１９に関連して上述されたように、サーバは、認証されたユーザが、このドキュメントに対する監査されたヒストリを取得するためのパーミションを有しているか否かを決定し得る（２２１０）。このドキュメントに対し、どのイベントが関係があるかを決定するため、ストレージプロバイダがクエリされ得る（２２００）。その後、クライアントは、監査情報を受信し、ユーザに表示し得る（２２３０）。

図２３は、複数のドキュメントコントロールサーバ２３６０を用いたドキュメントコントロールシステムを示すブロック図である。上記システムは、３階層のアーキテクチャを用い、信頼度と拡張性とを提供し得る。アプリケーション階層におけるクライアント２３１０，２３２０，２３３０は、ビジネスロジック階層２３５０における複数のドキュメントコントロールサーバ２３６０と通信を行する。上記ビジネスロジック階層２３５０における複数のドキュメントコントロールサーバ２３６０は、ストレージ階層２３７０におけるエンタープライズシステム（例えば、データベースマネジメントシステム（ＤＢＭＳ）２３８０）と通信を行なう。サーバの特定のインスタンスに特有ではないサーバ状態の全ては、複数のサーバインスタンスがそのような状態をシェアし得るように、第３の階層２３７０に格納され得る。

複数のドキュメントコントロールサーバのインスタンス２３６０が用いられる場合では、あるサーバが故障した際、他のサーバへ要求がルーティングされ得る。ロードバランサー２３４０は、上記要求の、サーバインスタンス２３６０へのルーティングを取り扱うことが出来る。サーバ自身において、例えば、Ｊａｖａまたは ．ＮＥＴ言語のような、組織化されたコードを用いた言語を用いてサーバを記述することにより、高い信頼性が達成され得る。多数の標準的または非標準的なプリンシパルを管理するため、プリンシパル情報に対し、２つのレベルのキャッシュが提供され得る。サーバ２３６０は、標準的なマッピングと、最近クエリされた、標準的なユーザに対するグループメンバーシップとに関する、メモリ内キャッシュを有し得る。多くのドキュメントコントロールサーバは、ストレージプロバイダ内の２次キャッシュをシェアし得る。

所望の情報は、これらキャッシュのいずれにも存在すべきではない。サーバは、アクセスコントロールサービスプロバイダ内のダイレクトなプリンシパルプロバイダに直接的に通信し、その後、ストレージプロバイダの近くの情報、または、ストレージプロバイダの内部の情報の両方を、キャッシュし得る。グループメンバー情報は、十分な長さの時間において、必要に応じて検索されるように、バッチ処理され得る。２次的なサービスとして、１つ以上のドキュメントコントロールサーバは、マスタを指定し、バッチ処理のタスクを実行する責任を有する。多くのケースにおいて、実際の保護はクライアント上で行なわれ、サーバへのドキュメントの転送とサーバからのドキュメントの転送とのオーバーヘッドを除去し、サーバ上のロードを減少させる。同様に、クライアント側の保護を用いて、クライアントは、ドキュメントの暗号化をも実行し、サーバのロードをさらに減少させる。

３階層のアーキテクチャは、大きなエンタープライズに対して、一定の比率に拡大したサーバのレプリカが追加されることを許容する。上述のように、ドキュメントは、特定のホスト名の代わりに、サーバのクラスタに束縛され得る。ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｉｎｇ Ｓｙｓｔｅｍ）ラウンドロビンがシステムに追加され、追加的なハードウェアがドキュメントコントロールサーバとして作用することを許容する。上記サーバは、状態を含まず、このため、ハードウェアに関する拡張性は、標準的な「１データベース（ｏｎｅ ｄａｔａｂａｓｅ）」問題に還元され得る。プリンシパルのマネジメントに関するアルゴリズムは、個々のオペレーションに対し、Ｏ（１）と記され、アグリゲートオペレーション（ａｇｇｒｅｇａｔｅ ｏｐｅｒａｔｉｏｎ：例えば、バッチ処理等）に対しては、Ｏ（ｎ）と記され得る。

本発明、および、本明細書に記述された機能上のオペレーションの全ては、デジタル電子回路において、または、コンピュータハードウェア、ファームウェア、ソフトウェア、または、それらの組み合わせにおいて、実施され得る。本発明の装置は、プログラム可能なプロセッサによる実行のため、機械可読の格納デバイスに具現化されたソフトウェアプロダクト（例えば、コンピュータプログラムプロダクト）に実施され得る。本発明の処理動作は、命令のプログラムを実行するプログラム可能なプロセッサによって実行され、入力データ上で動作し、出力を生成することによって、本発明の機能を実行し得る。本発明は、有利にも、１つ以上のソフトウェアプログラムの上で実施され得る。上記１つ以上のソフトウェアプログラムは、少なくとも１つのプログラム可能なプロセッサを含んだプログラム可能なシステムの上で実行可能である。上記少なくとも１つのプログラム可能なプロセッサは、データ格納システムと、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとから、データと命令とを受信できるように接続され、これらへデータと命令とを転送できるように接続され得る。各ソフトウェアプログラムは、ハイレベルの手続きまたはオブジェクト指向のプログラミング言語によって、あるいは、必要に応じて、アセンブリまたは機械言語によって実施され得る。また、どの場合でも、言語はコンパイラ言語またはインタープリタ言語であり得る。適切なプロセッサは、例として、多目的のマイクロプロセッサと、特殊目的のマイクロプロセッサとを含む。一般に、プロセッサは、読み取り専用メモリ、ランダムアクセスメモリ、および／または、機械可読信号（例えば、ネットワーク接続を介して受信したデジタル信号）から、命令とデータとを受信し得る。一般に、コンピュータは、データファイルを格納するための、１つ以上の大容量記憶デバイスを含み得る。そのようなデバイスは、例えば、内蔵ハードディスク、取り外し可能ディスク、光磁気ディスクのような磁気ディスク、および、光ディスクを含み得る。ソフトウェアプログラム命令とデータとを実体的に具現化するのに適切な格納デバイスは、任意の形態の非揮発性メモリであり得る。上記非揮発性のメモリは、例えばＥＰＲＯＭ（電気的にプログラム可能な読み取り専用メモリ）、ＥＥＰＲＯＭ（電気的に消去可能であってプログラム可能な読み取り専用メモリ）を含む半導体メモリデバイスと、フラッシュメモリデバイスと、例えば内蔵ハードディスクまたは外付けハードディスクのような磁気ディスクと、光磁気ディスクと、ＣＤ−ＲＯＭディスクとを含み得る。上記のいずれもが、ＡＳＩＣｓ（特定用途向け回路）によって補助され得る、または、ＡＳＩＣｓに組み込まれ得る。

本発明は、特定の実施形態の言葉で述べられてきた。その他の実施形態は、以下の請求項の範囲内にある。例えば、本発明のオペレーションは、異なる順序で実行され得るが、それでもなお、所望の結果を達成する。上記オペレーションは、予約ビジネスモデル（ｓｕｂｓｃｒｉｐｔｉｏｎ ｂｕｓｉｎｅｓｓ ｍｏｄｅｌ）を用いて、ホストされたサービスとして提供され得る。また、インターネットを介して一般に入手可能なシステム基盤を用いて、統合が実行され得る。ピア・トゥ・ピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）なシステムおよび技術を用いることにより、ドキュメントバージョンコントロール技術が実施され得る。さらに、ドキュメントに対するパーミションのセットは、異なるフレームワークに対して与えられたドキュメントコンテンツに関連した様々なアクションをカバーするように拡張され得る（例えば、特定の人物のみがドキュメントまたはドキュメントの一部に署名することを許容するパーミション、および／または、誰が電子フォームの異なるセクションに記入し得るか、および／または、誰が視覚し得るかをコントロールするパーミションなど）。

加えて、ポリシーのアップデートを常に同期化し、他のＡＣＬについては必ずしもそうしないことの代わりとして、システム内のどのＡＣＬが変更したかに関する情報を提供することが含まれ得る。その後、同期化動作は、高優先度の動作と低優先度の動作とに分割され得る。高優先度の同期化は、バックグラウンドにおいてより頻繁に発生し得、いつ情報が変更されたかについての指示を提供し得る。例えば、クライアントの最後の同期化以来、どのアクセスコントロールリストとどのポリシーとが変更したかを指示し得る。低優先度の同期化動作は、どのようにして情報が変更されたかを伴い得る。例えばこれは、システム内の全ドキュメントに対するオフラインアクセス情報が変更されたことを含み得る。一般に、アクセスコントロール情報の変更のされ方についての同期化は、変更されたものが何かについての概略よりも、資源消費を要求し得る。ドキュメントに対するアクセスコントロールがモディファイされ、クライアントが、モディフィケーションに気付いているにもかかわらず、低優先度の同期化を実行しなかった場合、システムは保守的になり、実施は、低優先度の同期化に置き換わるまで、上記ドキュメントへのアクセスを妨害し得る。

４６ 様々な図面における同じ番号は、同じ要素を示している。
図１は、ドキュメントコントロールシステムに対する動作環境を示すブロック図である。 図２は、例示的なドキュメントコントロールサーバを示すブロック図である。 図３は、認証システムにおけるワークフローを示すブロック図である。 図４は、サーバによって採用される認証技術を示すフォローチャートである。 図５は、ドキュメントコントロールシステムにおけるワークフローを示すブロック図である。 図６は、パーミション仲介サーバによって採用されるドキュメントコントロール技術を示すフローチャートである。 図７は、ドキュメントレポジトリと統合されたドキュメントコントロールシステムにおけるワークフローを示すブロック図である。 図８は、ｅ−メールクライアントと統合されたドキュメントコントロールシステムにおけるワークフローを示すブロック図である。 図９は、図２の例に対応するドキュメントコントロールサーバを示すブロック図である。 図１０は、図９のサーバに関する例についての詳細を示すブロック図である。 図１１は、ドキュメントコントロールシステムで用いられ得るようなオフラインドキュメント・アクセスモデルを示すブロック図である。 図１２は、サーバによって実行されるような同期化動作を示すフローチャートである。 図１３は、クライアントによって実行されるような同期化動作を示すフローチャートである。 図１４は、保護されたドキュメントのコンポーネントを示すブロック図である。 図１５は、サーバによって採用されるドキュメント情報送達技術を示すフローチャートである。 図１６は、ドキュメントコントロールシステムにおけるワークフローを示すブロック図である。 図１７は、クライアントによって採用されるドキュメント情報受信技術を示すフローチャートである。 図１８は、図９のドキュメントコントロールサーバにおけるドキュメント保護ワークフローを示すブロック図である。 図１９は、図９のドキュメントコントロールサーバにおけるサーバ側アクセスコントロールリスト評価ワークフローを示すブロック図である。 図２０は、図９のドキュメントコントロールサーバにおけるオンラインドキュメントビューイング・ワークフローを示すブロック図である。 図２１は、図９のドキュメントコントロールサーバにおける取り消しワークフローを示すブロック図である。 図２２は、図９のドキュメントコントロールサーバにおける監査イベント検索ワークフローを示すブロック図である。 図２３は、複数のドキュメントコントロールサーバを有したドキュメントコントロールシステムを示すブロック図である。

Claims (46)

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. 第１の認証定義フォーマットにおける第１のドキュメント認証情報を、第２の認証定義フォーマットにおける第２のドキュメント認証情報にマッピングするサーバ手段であって、該第１のドキュメント認証情報は、電子ドキュメントに関連している、手段と、
    該第２のドキュメント認証情報に基づいて、該電子ドキュメントに関連したアクションをコントロールする、クライアント手段と
    をさらに含み、
    該第１の認証定義フォーマットは、該クライアント手段によって用いられた該第２の認証定義フォーマットにおいて完全には定義され得ない認証情報のタイプを少なくとも１つ含んでいる、
    請求項４５に記載のシステム。

Images