JP2005056418A

JP2005056418A - ドキュメント・コンポーネント用セキュリティ・コンテナ

Info

Publication number: JP2005056418A
Application number: JP2004224520A
Authority: JP
Inventors: Ronald P Doyle; ロナルド・ピー・ドイル; John R Hind; ジョン・アール・ハインド; Marcia L Stockton; マーシャ・エル・ストックトン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-07-31
Filing date: 2004-07-30
Publication date: 2005-03-03
Anticipated expiration: 2024-07-30
Also published as: US20050039034A1; US7685645B2; US20080215897A1; US7515717B2; JP4575721B2

Abstract

【課題】
ドキュメント・コンポーネント（及び他のコンポーネント・メタデータ）をカプセル化した「セキュリティ・コンテナ」を使ってドキュメント・コンポーネントを保護又は制御する方法、システム、コンピュータ・プログラム、及びビジネス方法を提供する。
【解決手段】
「セキュリティ・コンテナ」は、制御されるべきコンポーネント(即ち、ドキュメント)を複合ドキュメントのような高レベル構成体内にカプセル化する。セキュリティ・コンテナはまた、カプセル化されたコンポーネントと相互対話するためのルールと、権限を与えられた要求者に対してコンポーネント及びルールを復号化するために使用可能な１つ又は複数の暗号化キーを含む。
【選択図】図１

Description

本発明は、コンピュータ・ソフトウェアに関し、更に詳しく言えば、ドキュメント・コンポーネント（及び、他のコンポーネント・メタデータ）をカプセル化する「セキュリティ・コンテナ」を使用して、そのドキュメント・コンポーネントを保護又は制御する方法、システム、コンピュータ・プログラム、及びビジネスを行う方法に関する。

コンテンツを保護するための伝統的な手法は、ファイル全体、全ドキュメント、ときには個々のＥメール・メッセージを細かくアクセス制御及び機能的制御を行うことによるものである。これらの制御は、コンテンツの読み取り、書き込み、送信、及び複写のような特定の動作を制限するために使用される。アクセス制御の一例として、サーバは、ファイルをリスエストするユーザの認証を必要とすることがあり、しかる後、そのファイルを提供すべきかどうかを決定するために、及び、それが肯定される場合、ユーザがそれを実行するためにはどのような動作が許されるかを決定するために、アクセス制御リストにおけるユーザのクリデンシャル（資格認定）を調べることがある。

一般に、コンテンツが平文で（即ち、暗号化されてない文で）ユーザに供給されるときには、通常、前述の簡単な従来技術のアクセス制御を迂回するための簡単な方法が存在する。そのアクセス制御を迂回した後、コンテンツは暗号化されてない形式で保管され、修正され、又は平文で他のユーザに送られる。即ち、如何なる機能的制御も存在しない場合、一旦コンテンツがユーザにとって使用可能にされると、そのコンテンツに関して更なる動作を遂行すべきかどうか、及び誰がそのコンテンツを受け取りそして見ることが可能であるかに関する制御は、そのコンテンツを作成したユーザに帰属したままであるのではなく、そのコンテンツを所有しているユーザに送られる。

一旦ユーザがコンテンツに対するアクセスを受けると、種々のタイプの制御がシステムの種々の局面によって提供され、そのコンテンツに関してどのような動作をユーザが遂行し得るかを管理する。例えば、コンテンツがテキスト・ファイルである場合、ユーザは、一般に、そのファイルが（例えば、システム又はオペレーティング・システム・ソフトウェアによって維持されたアトリビュート（属性）を通して）読取専用としてマークされていなかったならば、あるいは、（更新を許容する前に特別のパスワードを必要とすることによるような）編集に対する保護がされていなかったならば、そのテキスト・ファイルを編集することが許容される。それとは別に、受け取り側のユーザがそのテキストを編集できないようにするために、テキスト情報がレンダリングされた形式で提供されることがある。しかし、そのような制御は容易に迂回され、従って、それが提供する保護は非常に弱いものになる傾向がある。例えば、ファイル書き込み動作がファイル・システム読取専用アトリビュートによって阻止される場合、そのファイル・システムに精通したユーザはそのアトリビュートを直ちにリセットすることができる。あるいは、ユーザは、読取専用アトリビュートがセットされてない別のファイルにそのファイルを保管することが可能である。

機能的制御に関するもう１つの例として、Lotus Notes（商標）のＥメール・アプリケーションは、ローカル・イントラネットの外にあるアドレスを有するいずれの受信者にも、「機密」というセキュリティ・アトリビュートを持ったアウトバウンドＥメール・メッセージを送らないように構成可能である。あるいは、場合によっては、Ｅメール・メッセージは依然としてそのような受信者に配送され得るが、このメッセージは抑止付きのテキスト及び何らかのアタッチメントを有し、実際には送信者が更に何かを送ろうとしているという通知だけを受信者に供給するであろう。この場合、アプリケーション・システムは、所定の制御を維持する責任がある（この例では、ドキュメント毎に全てかゼロか的なレベルでそれらを維持する）。上述した別の例におけるように、ユーザはむしろこれらの機能的制御を容易に回避することが可能である。その場合、ユーザは、単に、Ｅメール・メッセージからセキュリティ・アトリビュート除去しなければならいだけであり、完全なメッセージを送ることができる（なお、「LotusNotes」は、インターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）。

暗号化されたドキュメントは、従来技術を使用して、受信クライアント・デバイスで実行されるプロセスにより自動的に復号化（即ち、暗号化解除）可能である。例えば、あるＥメール・システムは、暗号化された形で受信されるＥメール・メッセージを自動的に復号化する。クライアント・デバイスにおいて作動する従来技術は、機能的な制御をその復号化された結果に対し自動的に強制することがある。例えば、マルチメディア・プレーヤは、ユーザが、事前に暗号化された映画を見ること及び事前に暗号化された歌を聴くことを可能にするが、ユーザがその映画又は歌のコピーを行うことを妨げることが可能である。これは、「封印メディア」又は「ディジタル権」と呼ばれることがある。

別のタイプの機能的制御は、種々のコンテンツが「カット・アンド・ペースト」方法を使用してプログラム間で転送可能であるかどうかを制限することを含む。例えば、オペレーティング・システムは、「クリップボード」のメタファ（暗喩）を行うために使用されるバッファに、ソース・オブジェクトがコピーされることを可能にする動的データ交換（ＤＤＥ）プロトコルをサポートすることが多い。ソース・オブジェクトは、例えば、テキスト・ドキュメントからのワード又はフレーズ、グラフィックス・アプリケーションにおいて使用されるグラフィック・イメージ又は図面、その他等であってもよい。（典型的には、オブジェクトのタイプを識別する情報又はそれを作成したアプリケーションの識別標識が、クリップボードにコピーされたオブジェクトの直列化表示と共にバッファに格納される）。一旦ソース・オブジェクトの情報のコピーがこのバッファに格納されると、そのオブジェクトをターゲット・ロケーションに貼り付ける機能がクリップボード機能によって制御される。そのクリップボード機能は、先ず、オブジェクトのタイプがそのターゲットと互換性があることを保証するためのチェックを行う。従って、例えば、テキスト・エディタ・プログラムの１つのウィンドウにおいて見られるソース・ドキュメントからのテキストが、そのテキスト・エディタ・プログラムの別のウィンドウにおいて見られるターゲット・ドキュメントに貼り付け可能である。あるいは、Ｅメール・アプリケーションがこの特定のタイプのオブジェクトを処理するように適応する場合、テキストは、そのＥメール・アプリケーションによって作成されるＥメール・メッセージに貼り付け可能である。一方、ターゲット・アプリケーションが理解し得ないタイプのコンテンツ（特定のタイプのイメージ・ファイル、又は所有権のあるファイル・タイプのような）をユーザが貼り付けようとする場合、ターゲット・アプリケーションがそのオブジェクト・タイプに対するサポートを欠いているので、その貼り付け動作は失敗するであろう。

多くの場合、これらの伝統的な手法は十分であるけれども、それらは、コンテンツの保護にとっては全てかゼロか的な方法を提供するだけである。即ち、ある特定のファイル（又は、ドキュメント、メッセージ等）は、アクセス制御及び機能的制御でもって完全に保護されるか、又は全く保護されないかである。コンテンツ・クリエータがコンテンツに関して永続的なアクセス制御及び機能的制御を持つこと及びもっと細かいレベルでそのような制御を提供することが有利となる多くの状況が存在する。
米国特許出願１０/４５５,０６８米国特許出願０９/２４０,３８７米国特許出願０９/３８５,３９９米国特許出願０９/４２２,４３０米国特許出願０９/４２２,５３７米国特許出願０９/４２２,４９２米国特許出願０９/４２２,４３１

本発明の目的は、コンテンツへのアクセスを対して既存の手法による利用可能な制御よりも更に細かい制御を提供することにある。

本発明のもう１つの目的は、コンテンツに関して行われる機能に対して既存の手法による利用可能な制御よりも更に細かい制御を提供することにある。

本発明のもう１つの目的は、ドキュメントの個々のコンポーネントへのアクセス及びドキュメントの個々のコンポーネントに関して遂行可能な動作を、ドキュメント・コンポーネント・クリエータが選択的に制御することを可能にすることにある。

本発明の更なる目的は、個々のドキュメント・コンポーネントをカプセル化するために使用可能であって、内蔵したドキュメント・コンポーネントに対するアクセスとその使用とを調停するセキュリティ・コンテナを提供することにある。

本発明のもう１つの目的は、受信者特有のバージョンの作成を必要とすることなく、ドキュメント内のコンポーネントに、細分化されたアクセス及び機能的制御を提供することにある。

本発明のその他の目的及び利点は、以下の説明及び図面において部分的に説明されることになり、また、それらは部分的にはその説明から明らかになるか、または、本発明を実施することによって学習することができる。

上記の目的を達成するために、及び本明細書において広範に説明される発明の目的に従って、本発明は、セキュリティ・コンテナを使用してドキュメント・コンポーネントを保護するための方法、システム、及びコンピュータ・プログラムを提供する。好適な実施例の１つの局面では、これはセキュリティ・コンテナを含み、そのセキュリティ・コンテナ内にドキュメント・コンポーネントと、ドキュメント・コンポーネントに関する動作を制御するための条件付きロジックと、ドキュメント・コンポーネントへのアクセスを制御するために使用可能なキー配布情報と、をカプセル化することによってドキュメント・コンポーネントを保護する。

好適な実施例のもう１つの局面では、これは、セキュリティ・コンテナ内にドキュメント・コンポーネントと、ドキュメント・コンポーネントに関する動作を制御するための条件付きロジックと、ドキュメント・コンポーネントへのアクセスを制御するために使用可能なキー配布情報と、をカプセル化することを含む。そのドキュメント・コンポーネント及び条件付きロジックは、セキュリティ・コンテナ内におけるカプセル化の前に暗号化されることが望ましい。更に、キー配布情報は、そのドキュメント・コンポーネントをアクセスすることを許容された１つ又は複数のユーザ及び／又はプロセス、の識別を含むことが望ましい。

１つ又は複数の許容されたユーザ及び／又はプロセスの識別標識は、それらの、個々の識別標識及び／又はグループ識別標識、を使用してそのユーザ／プロセスを指定し得る。後者の場合、グループ識別標識は、１つ又は複数のユーザ及び／又はプロセスをメンバとして有するグループを識別する。グループ・メンバは、ドキュメント・コンポーネントにアクセスするための要求を受け取る際に動的に決定可能である。これは、グループのメンバが識別されるリポジトリをアクセスすることを含むことが望ましい。

ドキュメント・コンポーネントにおける動作を制御することに加えて、条件付きロジックはドキュメント・コンポーネントに対するアクセスも制御し得る。ドキュメント・コンポーネントにおけるアクセスを制御することに加えて、キー配布情報は条件付きロジックに対するアクセスも更に制御し得る。

キー配布情報は更に、セキュリティ・コンテナ内でカプセル化される、ドキュメント・コンポーネントと条件付きロジックの両方、を暗号化した対称キーを含むことが望ましい。なお、対称キーは、権限を与えられたユーザ及び／又はプロセスによる復号化のために暗号化形式で保存される。各個々のユーザ、プロセス、ユーザのグループ、及び／又はプロセスのグループ、に対する別のバージョンの対称キーがセキュリティ・コンテナに設けられることが望ましい。なお、各個々のバージョンは、対応する個々のユーザ、プロセス、ユーザのグループ、又はプロセスのグループ、と関連した公開キーで持って暗号化されている。

セキュリティ・コンテナは、構造化ドキュメント・フォーマット（拡張可能マークアップ言語（Extensible Markup Language : ＸＭＬ）フォーマットのような）でエンコード可能である。

これらの局面は、更に、ドキュメント・コンポーネントをアクセスするための要求を要求者から受け取るステップと、キー配布情報を使用して要求者がそのドキュメント・コンポーネントをアクセスすることを許可されているかどうかをプログラム的に決定するステップと、そのプログラム的決定が肯定的結果を有するとき、条件付きロジックを使用して、その要求が許されるかどうかをプログラム的に評価するステップと、プログラム的決定が否定的結果を有するとき、その要求を拒否するステップと、を含む。条件付きロジックは、要求者の身元識別情報、要求者によって使用されるデバイス、要求者の背景情報、要求者によって使用されるアプリケーションの区域、要求者のユーザ・プロファイル、及び／又は要求のターゲット宛先（例えば、ターゲット・アプリケーション又はアプリケーション・ゾーン、ターゲット・デバイス、ターゲット受信者のユーザ・プロファイル等）のようなエレメント（要素）を評価することが望ましい。

セキュリティ・コンテナは、（例えば）ドキュメント内に組み込まれたり、ユーザ・インターフェースに設置されたり、又は、クリップボード、アプリケーション・プログラミング・インターフェース、プロセス間通信、もしくはメッセージング・システム、を含む手法を使用してソースから宛先に送られたりすることことが可能である。ドキュメント・コンポーネントがターゲット宛先にコピーされるべき時、そのコンポーネントを直接にコピーすることを具体的に可能にする条件付きロジックが存在しない場合には、セキュリティ・コンテナ全体がコピーされる。

開示された手法はビジネスを行う方法においても有利に使用可能であり、それによって、セキュリティ・コンテナを使用してドキュメント・コンポーネントへのアクセスを制御するためのサービスがクライアントに対して提供される。このサービスは、ペイ・パー・ユース（使用毎支払い）方式の請求、月毎又は他の期間毎の請求、その他というような種々の歳入モデルの下で提供可能であり、より高レベルの構成体におけるコンテンツの部分（即ち、ドキュメント内のドキュメント・コンポーネント）に対するアクセスのより細かな制御と、その部分に及ぼす機能的な制御とを含む利点をクライアントに提供し、コンテンツ部分の確実な配布を保証し、及びコンテンツ部分の確実な貯蔵を保証する。

次に、図面を参照して本発明を説明する。それらの図面では、同じ参照番号は同じ素子を示す。

従来技術は、一般に、全ファイル、リンク、ドキュメント、又はＥメール・メッセージ、のレベルにおいてアクセス制御及び機能的制御を提供するのに対し、本発明は、これらの制御をコンテンツの部分に拡張し、それによってより融通性のあるかつよりきめの細かい方法を提供することを可能にする。従って、制御は、高レベル構成体における個々の部分のレベルで施され得る。なお、本明細書では、この高レベル構成体は、複合ドキュメント、ドキュメント、又はファイルと呼ばれる（これは、説明のためであって、限定のためではない）。本明細書では、個々のコンテンツ部分は、コンポーネント、ドキュメント・コンポーネント、又はオブジェクトと等価に呼ばれる。

本願で開示される「セキュリティ・コンテナ」は、複合ドキュメントのような高レベル構成体内で制御されるべきコンテンツ部分をカプセル化する。コンテンツ・クリエータは、コンテンツを個々に制御することを可能にするために、セキュリティ・コンテナにおけるカプセル化すべきコンテンツの任意の部分を指定する場合がある。従って、特定の複合ドキュメントは、複数のコンテンツ部分が個々に制御されるべきときには２つ以上のセキュリティ・コンテナを含む場合がある。換言すると、ドキュメントは、２つ以上のコンポーネントを有するものとして論理的に構成可能であり、これらのコンポーネントのうちのいずれにおけるコンポーネント・クリエータも、それ自身のセキュリティ・コンテナにそれを置くように選択可能である。本願において開示される手法に従って制御可能なコンテンツ部分の例は、テキスト・ドキュメント内の個々のパラグラフやセンテンスやまたはワード、スプレッドシート内のテーブル又はセル、プレゼンテーション・スライドセットからの図面又は図表、アニメーションからのイメージまたはフレーム等を含む。

複合ドキュメントの概念はその分野では知られており、非常に多くの種々のタイプのコンテンツ又は種々のタイプのオブジェクトから構成可能である。例えば、マイクロソフト社からの「ＯＬＥ」フレームワークは、テキスト、グラフィックス、アニメーション等のためのオブジェクトから構成される複合ドキュメントを作成及び表示するために、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供する。このフレームワークの下では、ドキュメントは、それが含む基本オブジェクトの活動化を調整するオブジェクト・コンテナである。本発明によれば、これらの基本オブジェクトの幾つかは、アクセス及び／又は機能的使用が制御されるべきオリジナル・コンテンツ・オブジェクト（ここでは、ドキュメント・コンポーネントと呼ぶ）、をカプセル化するセキュリティ・コンテナである。

本発明によれば、高レベル・ドキュメントの一部である各ドキュメント・コンポーネントとメタデータが関連付けられる。（「ドキュメント」という用語は、本願では、例示態様で示され、ファイル、メッセージ等を含むものとして解釈されるべきである）。特定のドキュメント・コンポーネントに対して、メタデータは、種々の異なるタイプのアクセス制御及び／又は機能的制御を提供することを可能にする。個々のドキュメント・コンポーネントにおける制御のこの低レベル・アプリケーションは、ドキュメントのコンテンツに関連する種々のレベルの制限を施すために、本願において更に詳細に説明されるように多数のエレメントに基づいている場合がある。例えば、あるユーザはドキュメントにおける選択された部分を見ることを許され、一方、他のユーザは、それらの部分を見ること及び編集することが可能にされ、更に他のユーザは、保護された部分を見ることも、それらを如何なる方法で操作することも許されない。アクセス制御及び機能的制御も同様に指定するために、更に複雑な条件が使用可能であり、本願では、幾つかの例が説明されることになる。

本発明のセキュリティ・コンテナは、制御されるドキュメント・コンポーネントのみならず、そのドキュメント・コンポーネントに対するアクセス制御及び機能的制御を提供するメタデータもカプセル化する。換言すれば、セキュリティ・コンテナは、ドキュメント・コンポーネントと、誰がそのドキュメント・コンポーネントをアクセスできるか及びアクセスを許されたときにそれらが何を行うことができるかを管理するルールのセットとを保持している。

セキュリティ・コンテナのある部分が暗号化され、他の部分は平文であるが、更に詳細に後述されるように、公開キー暗号化の使用を通して、改ざんされないように効果的に保護される。（コードを安全に配布及びインストールするための従来技術は、ハッカーが、例えば、セキュリティ・コンテナの相互作用を処理するコードを、セキュリティ・コンテナ実装のコードであることを装う不正コードでもって重畳することによって、セキュリティ・コンテナの保護を潜り抜け得る、という危険を最少限にするために使用されることが望ましい。これらの従来技術は、本発明の範囲外であるが、コンテンツが使用されるデバイスにおけるセキュリティ・コンテナを庇護する。）

セキュリティ・コンテナは、システム・クリップボード、アプリケーション・プログラミング・インターフェース、プロセス間通信、及びメッセージング・システムを使用して、複製され、ドキュメント内に組み込まれ、ユーザ・インターフェース上に置かれ、及び／又はソースから宛先に送られる。従って、たとえそれが複製又は転送されても、セキュリティ・コンテナは、その中にある保護されたデータへのアクセスを制御するメタデータを依然として保持し、それによって、コンテンツが他のユーザに送られてもコンポーネント・クリエータの意図を実行する。

このように、セキュリティ・コンテナは、ドキュメント・コンポーネントへのアクセスを、権限を与えられたユーザに制限するのみならず、許可されてないユーザへの情報の偶発的な及び／又は不正な散逸の影響を抑制する。ほとんどのコンピュータ・ユーザは、クリップボード上に実際に格納されていたものが期待したものでなかったことを知るためにのみ、クリップボードからドキュメント又はメッセージに何かを貼り付けようとするという筋書きに通じている。多くの場合、これは単なる煩雑事項に過ぎず、偶発的な貼り付けを元に戻すこと、しかる後所望のコンテンツを見つけること、それをクリップボードに置くこと、及び貼り付け動作をもう一度行うこと、によって修正可能である。しかし、ユーザがエラーを発見しなかった場合、深刻な反動が存在することがある。例えばユーザは、上級管理者に対する機密のビジネス・レポートを作成すると同時に、自分の友人とのオンライン・チャットによって通信することがある。ユーザが未保護の機密情報を自分のレポートから自分のチャット・セッションに偶発的にコピーした場合、この情報が自分の友人に配送されることを防ぐ方法はない。一方、本発明を使用することによって、セキュリティ・コンテナは、たとえそれが意図されてない受信者又は許可されてない受信者に偶然に又は意図的に送られても、そのカプセル化されたコンテンツを保護し続けることになる。

図１は、好適な実施例に従ってセキュリティ・コンテナ１００を構成する方法の概念図を提供する。好適な実施例では、暗号化された情報及び暗号化されてない情報の両方を含む暗号化ヘッダ１１０が設けられる。暗号化ヘッダ１１０は、どの要求者がセキュリティ・コンテナの暗号化部分をアクセスすることを許可されているかに関する第１パスの決定を行うために使用される。暗号化ヘッダは、更に、権限を与えられた要求者が暗号化部分をアクセスすることを可能にする１つ又は複数の暗号化された対称キーを有する。暗号化ヘッダ１１０に対する望ましい構成が図３に関連して後述され、この構成を使用する例が図４に関連して後述される。

各セキュリティ・コンテナは、前述のように、ルールによって指定されることが望ましいアクセス制御及び／又は機能的制御を含む。本発明によれば、これらのルールは、セキュリティ・コンテナ内に暗号化形式で格納される（エレメント１２０参照）。そのルールを暗号化することは、未許可のユーザがそのセキュリティ・コンテナにおけるドキュメント・コンポーネントを操作することができないという保証を強化する。（用語「ルール」は、ルール・ベースのシステム又はルール・エンジンと共に使用するように本発明の実施例を限定するものとして解釈されるべきではないことに留意してほしい。そのルールは、ブール代数の値、許可された動作のリスト、機密のロジック等のように簡単に実装可能である）。好適な実施例では、ルールは対称キーでもって暗号化され、そして、この対称キーは、それ自身、各権限を与えられたユーザ、プロセス、ユーザ・グループ、又はプロセスのグループに対して１回だけ、その権限を与えられたエンティティの公開キーでもって暗号化される。その結果生じたそのような権限を与えられたエンティティの各々に対する暗号化された対称キーは、上述のように、暗号化ヘッダ１１０内に含まれる。従って、暗号化ヘッダは、更に詳細に後述されるように、権限を与えられたエンティティに対してキー情報を配布する安全かつ効率的な方法を提供する。（本願における権限を与えられたユーザ又はユーザ・グループという参照は、権限を与えられたプロセス又はプロセスのグループにも適用するものとして解釈されるべきである）。

暗号化された対称キーは、例えば、ハッカーが、セキュリティ・コンテナ実装コードであるように装う不正コードをインストールすることによってセキュリティ・コンテナに障害を生じさせることを防ぐために、追加レベルの暗号化でもって任意選択的に保護可能である。（その不正コードは、ユーザのプライベート・キーを傍受し、それを使ってセキュリティ・コンテナのドキュメント・コンポーネントを復号化し、しかる後、セキュリティ・コンテナの組み込まれたルールに関係なくそのドキュメント・コンポーネントを使用する）。この任意選択的な機能強化は、権限を与えられたユーザの公開キーで持って対称キーを暗号化するのではなく、セキュリティ・コンテナ実装コードに知られている秘密キーを使って対称キーを隠蔽する。望ましくは、この秘密キーは対称キーであり、従って、ルールとドキュメント・コンポーネントとを暗号化するために使用される対称キーを暗号化と復号化の両方を行うために使用される。それとは別の方法として、公開キー・インフラストラクチャ（ＰＫＩ）公開／プライベートのキー・ペアが使用可能である。この任意選択的な機能強化の第１局面では、ルール及びドキュメント・コンポーネントを暗号化した対称キーが、先ず、権限を与えられたユーザ又はユーザ・グループの公開キーでもって暗号化され、しかる後、セキュリティ・コンテナ実装コードに知られている秘密キーがその結果を暗号化するために使用される。（このプロセスは、権限を与えられた各ユーザ又はユーザ・グループに対して繰り返される）。この任意選択的機能強化の第２局面では、ルールとドキュメント・コンポーネントとを暗号化した対称キーが、先ず、セキュリティ・コンテナ実装コードに知られている秘密キーでもって暗号化され、しかる後、その結果が各ユーザ又はユーザ・グループの公開キーで持って暗号化される。いずれの局面においても、追加の暗号化は、正当なセキュリティ・コンテナ実装コードと対話している権限を与えられたユーザにとってのみ基本となる対称キーが使用可能にされる、という保証の強化をもたらす。

ルール１２０の暗号化されてない形式に従ってセキュア・ハッシュ（擬似乱数）１３０が計算されることが望ましい。このセキュア・ハッシュは、セキュリティ・コンテナでは暗号化されない。セキュア・ハッシュは、ＳＨＡ−１アルゴリズム又はＭＤ５アルゴリズムのようなその分野では周知の手法を使用して作成可能である。望ましくは、所定のアルゴリズムが使用される。別の方法として、アルゴリズムは暗号化ヘッダ（図示されてない）において識別可能である。暗号化されてないセキュア・ハッシュを暗号化されたルールに追加することは、復号化が成功したかどうかを、（図１０のブロック８４０〜８５０に関連して更に詳細に説明されるように）そのルールを復号化及び解釈しようとする受信者が決定することを可能にする。

ディジタル署名１４０は、ルール及び暗号化ヘッダに従って計算されることが望ましい。ディジタル署名を計算するための手法はその分野では周知である。好適な実施例では、ディジタル署名は、ルール及び暗号化ヘッダをハッシュ（擬似乱数化）すること及びこのハッシュをコンピュータ・クリエータのプライベート・キー(周知の公開キーに対応する)でもって署名することによって計算される。その結果生じたディジタル署名１４０は、セキュリティ・コンテナでは暗号化されない。好適な実施例では、このプロセスでは暗号化されないルールを使用するけれども、別の実施例では、暗号化されたルールが使用可能である。ディジタル署名のその後の妥当性に関してコンポーネント・クリエータの公開キーを容易に見つけることを可能にするために（図１０のブロック８４０〜８５０に関連して更に詳細に説明される）、好適な実施例は、コンポーネント・クリエータの識別名（distinguishedname : ＤＮ）又は同様の明白な識別子及び／又は暗号化ヘッダにおけるＸ.５０９証明書（又は、それの識別子）を含む。（図３のエレメント３４０及び３５０参照）。

結局、各セキュリティ・コンテナ１００は、図１のエレメント１５０に示されるように、暗号化されたドキュメント・コンポーネントを含む。好適な実施例によれば、ドキュメント・コンポーネントは、ルールを暗号化するために使用された対称キーと同じ対称キーを使って暗号化される。

好適な実施例では、セキュリティ・コンテナのルールにおいて具体化された制御は、（１）許可、（２）コンテキスト（前後の文脈）、（３）ゾーン（区域）、及び／又は、（４）環境の検証ルール、のような要因に基づいている。これらの要因のあるものはユーザに関連することがあり、一方、別のものはカプセル化されたドキュメント・コンポーネントのソース、及び／又は、そのコンポーネントに対して要求された動作の宛先、といった要因に関連することがある。次に、これらの要因の各々を更に詳細に説明する。

（１）「許可」は、読み取り又は書き込みに対する許可のような一般的なアトリビュート、並びに、「生データが回復可能である」（セキュリティ・コンテナのドキュメント・コンポーネントがセキュリティ・コンテナなしで平文においてコピー可能であることを意味する）、「定位置における編集が許される」（即ち、既存のセキュリティ・コンテナ内でドキュメント・コンポーネントに対する編集を行うことができる）、「未保護のデバイスに関するレンダリングが許される」、「暗くレンダしなければならない」、「サイズ変更できない」、「カラーのみをレンダする」、「印刷できない」、「ネットワーク・ファイル・サーバに格納できない」、「企業イントラネット外にＥメールで送信できない」等のような細分化された一般的でないアトリビュートを含む。

（２）要求の「コンテキスト」は、一般に、その要求が受け取られときに何が起こるかに関する情報であり、その受け取られた要求を送ったデバイスのタイプや、その要求を生成したアプリケーションや、要求を発するデバイスにおいて使用可能なハードウェア及び／又はソフトウェアや、受け取られた要求が通ったネットワーク接続のタイプ（適用可能である場合）や、要求者の物理的ロケーション、等といった情報を含み得る。

（３）「ゾーン」は、セキュリティ・コンテナが組み込まれるドキュメントのセキュリティ分類、ドキュメントがレンダされるウェブ・サイトのセキュリティ・ゾーン、組込みドキュメント（即ち、セキュリティ・コンテナを保持するドキュメント）が属する分離ゾーン、等のような情報を含み得る。分離ゾーンは、同一出願人による「コンピュータ・プログラム間におけるコンテンツの挿入を制限するための方法、システム、及びプログラム（Method, System and Program Product for Limiting Insertion of Contentbetween Computer Programs）」と題した米国特許出願１０/４５５,０６８（以後、「分離ゾーン発明」と呼ぶ）に開示されている。例えば、分離ゾーンは、ビジネス目的のためにのみ（「ビジネス・ゾーン」として）又は個人使用のためにのみ（「パーソナル・ゾーン」として）使用されるアプリケーション・プログラム及び／又はファイルの集合体を定義するために使用することができる。この同一出願人による米国特許出願に開示されているように、分離ゾーンはゾーン境界にまたがるコンテンツの挿入を制限するために使用することができる。１つのゾーンから別のゾーンにコンテンツを挿入しようとする試みがなされるとき、ユーザは、自分が挿入を進めたいのか、あるいは、挿入が進む前に自分がセキュリティ・クリデンシャルを提供することを必要とするのか、等を確認するようにプロンプト指示されることがある。ビジネス及びパーソナルの各分離ゾーンの使用は、それによって、ビジネス関連コンテンツへの個人情報の不注意による挿入、及びその逆、の可能性を減少させる（又は、それを防止する）。（この米国特許によれば、コンテンツの挿入を制限するための別のタイプの分離ゾーンも定義及び使用可能であり、また、本願におけるビジネス・ゾーン及びパーソナル・ゾーンに対する参照は説明目的のためである。）

（４）「環境確認ルール」の例は、「各使用時に要求者のＩＤ及びパスワードに関してプロンプト指示する」、「現在実行しているプロセスからユーザ身元識別情報を受容する」、「各使用時に３部構成のユーザ認証が要求される」（即ち、対象者が何を知っているか、誰であるか、何を持っているか、を含む認証）、「組込みドキュメントのコンテキスト(及び／又はゾーン)の受容、及び「現在実行中のプロセスのコンテキスト(及び／又はゾーン)の使用」を含む。

従来技術の複合ドキュメントは、上記のようにそれの基本オブジェクトの活動化を調整する。一般に、従来技術のオブジェクトは、周知のように、直列形式で持続的に格納される。その調整するプロセスの一部は、それらの方法及びプロパティが役目を果たすことができるようオブジェクトを非直列化及びインスタンス化することである。次に、好適な実施例のセキュリティ・コンテナがこの環境において使用される態様を説明する。

本発明によれば、各セキュリティ・コンテナは、それが保護するドキュメント・コンポーネントに対するプロキシとして作用し、即ち、そのドキュメント・コンポーネントの位置にあり、すべての方法及びプロパティ活動をフィルタする。ドキュメント・コンポーネントは、例えば、リッチ・テキスト、スプレッドシート・セル、ピクチャ、オブジェクト集合体等であってもよい。

図２は、オブジェクト指向セキュリティ・コンテナ・動作のモデルを示す。ドキュメント・コンポーネント・オブジェクト２３０を含むセキュリティ・コンテナ・オブジェクト２００が示される。セキュリティ・コンテナ・オブジェクト２００は、参照番号２１０として総体的に示されたインターフェースを有し、インターフェース２１０は、そのコンテナ・オブジェクトと対話するための方法及び属性を含む。更に、ドキュメント・コンポーネント・オブジェクト２３０は、そのドキュメント・コンポーネント・オブジェクトと対話するためのインターフェース２４０を有する。ドキュメント・コンポーネント・オブジェクトのインターフェース２４０に関する方法の例が示され、それは直列化、非直列化、編集、表示及び印刷を含む。

更に、セキュリティ・コンテナは、ルール、即ち、「フィルタ・ルール」２２０を含む。これらのフィルタ・ルールは、インターフェース２１０からの方法呼び出しを遮断する。その遮断された呼び出しがドキュメント・コンポーネント・オブジェクト２３０を参照する場合、フィルタ・ルール２２０は、ドキュメント・コンポーネント・オブジェクトのインターフェース２４０からの方法又は属性が呼び出し可能であるかどうかを決定する。これは、図２では矢印２５２によって表される。その矢印は、インターフェース２１０をインターフェース２４０に接続している。

一方、セキュリティ・コンテナ自体は、それ自身の幾つかの方法及び属性を有し、従って、遮断された呼び出しは、ドキュメント・コンポーネント・オブジェクト２３０よりもむしろこれらの１つを参照することがある。セキュリティ・コンテナに対するインターフェース２１０は、例えば、その含まれたオブジェクトへのアクセスを管理するための方法の１つを含むことが望ましい。従って、参照番号２１１として示された「アクセスの管理」と呼ばれる方法は、権限を与えられたエンティティのリストにおいてユーザ又はユーザ・グループ（又は、等価的には、プロセス）を追加、変更、又は削除するためにアドミニストレータ又は他の特権ユーザによって使用されることがある。これは、図２では矢印２５１によって表される。

本発明の実施例を更に詳細に説明する前に、先ず、幾つかの発明を説明する。同出願人による、「ポリシ・プロファイルに基づいて暗号化レベルを選択するための方法、システム及び装置（Method, System and Apparatus for Selecting Encryption Levels Basedon Policy Profiling）」と題した米国特許出願０９/２４０,３８７では、内蔵したコンテンツのセクションに対して複数レベルのセキュリティを有するドキュメントを操作する手法を教示している。ユーザがドキュメントを要求するとき、そのユーザのアクセス権が決定され、このユーザのアクセス権が不十分であるいずれのドキュメント・セクションも「排除」される、即ち、そのユーザに与えられたドキュメント・バージョンから削除されることになる。更に、または、その代わりに、その「排除動作」は、ユーザのデバイスがドキュメントの種々のセクションを受けるためには十分に安全であるかどうか、又は、そのデバイスが一旦受け取ったコンテンツを復号化することができるかどうか、といった情報に基づいて行うことができる。ドキュメントを「排除」しなかったセクションは、可変セキュリティ・レベルに適応したポリシ・プロファイルを使用して選択された暗号化手法を使って暗号化される。これは本発明とは異なり、同じセキュリティ・コンテナ内で保護された同じドキュメント・コンポーネントをすべての受信者に提供し、上記米国特許出願におけるように、種々のユーザに対してドキュメントを条件付では修正しない。

同出願人による、「スタイル・シート処理を使用するデータ・ポリシの強制（Enforcing Data Policy Using Style Sheet Processing）」と題した米国特許出願０９/３８５,３９９では、格納されたポリシ情報を使用してドキュメントのコンテンツが制御される手法を教示している。格納された「ポリシ・オブジェクト」が開示され、これらのポリシ・オブジェクトは、スキーマにおいて、又は許容可能なドキュメント・シンタックスを定義するドキュメント・タイプ定義（ＤＴＤ）において参照される。データ・ポリシを強化するためにポリシ・オブジェクトを使用する例として、ドキュメントを要求するユーザのコンテキストが決定されることが可能であり、また、ユーザの現在のコンテキストを仮定すると、そのドキュメントの選択された部分がユーザに配布されるべきかどうかをポリシ・オブジェクトが評価することが可能である。これらのポリシ・オブジェクトに対する拡張は、同出願人による、「スタイル・シート処理を使用した選択的データ暗号化（SelectiveData Encryption Using Style Sheet Processing）」と題した米国特許出願０９/４２２,４３０において定義されている（以後、これを「選択的データ暗号化発明」と呼ぶ）。

この「選択的データ暗号化発明」において開示された拡張ポリシ・オブジェクトは、コミュニティ独特の暗号化を通してエレメントの可視性を１つ又は複数の「コミュニティ」に制限することを可能にする（なお、「コミュニティ」は、情報に関する権限を与えられたビューア（視る者）の集合体であり、人間及びプログラム的エンティティ又はプロセスを含む）。従って、例えば、拡張ポリシ・オブジェクトは、ドキュメント・エレメントをアクセスすることを許可されているユーザ又はプロセスのコミュニティ、及びドキュメント・エレメントを暗号化するときに使用されるべき暗号化の強度、を識別する。これらの発明において開示されるようなポリシ・オブジェクトは、構成されたドキュメントにおいてエンコードされたコンテンツに関するエレメント独特の処理を達成するために実行可能なコードを含むことが望ましい。

上記「選択的データ暗号化発明」は、自身のキー配布マテリアルを保持する選択的に暗号化されたドキュメント、を作成するために、ポリシ駆動の拡張スタイル・シート・プロセッサを使用されるようにする、手法も教示している。即ち、構成されたドキュメントに対するドキュメント・オブジェクト・モデル（ＤＯＭ）が、その構成されたドキュメントの暗号化されたエレメントを選択的に復号化するために使用可能な情報を、含むようにプログラム的に修正される。各エレメントは、１つ又は複数の権限を与えられたコミュニティ（例えば、個々のユーザ又はプロセス、あるいは、ユーザ又はプロセスのグループ）のために暗号化されることもある。従って、キー配布マテリアルは、要求者又はターゲット受信者がそのエレメントに対して権限を与えられたコミュニティのメンバである場合にのみ、特定のドキュメント・エレメントの復号化を可能にする。このキー配布手法は、本発明の好適な実施例によって強化され、更に詳細に後述される。

上記選択的データ暗号化発明に従って選択的に暗号化されたドキュメントの復号化を遂行するための別の装置が「クライアント・プロキシによる復号化のためにスタイル・シート処理を使用する選択的データ暗号化（Selective Data Encryption Using Style Sheet Processing forDecryption by a Client Proxy）」と題した米国特許出願０９/４２２,５３７、「グループ・クラークによる復号化のためにスタイル・シート処理を使用する選択的データ暗号化（SelectiveData Encryption Using Style Sheet Processing for Decryption by a Group Clerk）」と題した米国特許出願０９/４２２,４９２、及び「キー・回復・エージェントによる復号化のためにスタイル・シート処理を使用する選択的データ暗号化（SelectiveData Encryption Using Style Sheet Processing for Decryption by a Key RecoveryAgent）」と題した米国特許出願０９/４２２,５３７に開示されている。これらの同出願人による発明は、以後、「関連発明」と呼ばれ、上記「選択的データ暗号化発明」に加えて、十分に説明されたものとして本願に組み込まれる。

次に、本発明の説明に戻ると、セキュリティ・コンテナ内のコンテンツに対して権限を与えられたユーザが、「キー・クラス」機構を使用して識別されることが望ましい。なお、このキー・クラス機構は、コンテンツを見ることの権限を与えられたコミュニティに対称キーを確実に配布する。特に、上記「選択的データ暗号化発明」において開示された方法が、好適な実施例において使用される。他の関連発明は、復号化を種々の方法で遂行するときにキー・クラスを使用可能であり、これらの復号化方法は（更に詳細に後述される）本発明の実施例において使用可能である。

キー・クラスは、前述のようにセキュリティ・コンテナ内のドキュメント・コンポーネントの権限を与えられたユーザを識別するために使用可能な情報を、暗号化された対称キーと共に、平文で保持する。更に、キー・クラスは、セキュリティ・コンテナのルール及びドキュメント・コンポーネントを暗号化するために使用された暗号化アルゴリズム、並びに、そのアルゴリズムによって使用されたキー長、及びコンポーネント・クリエータの周知の公開キーを得るために使用可能な情報、を識別することが望ましい。キー・クラスの構造は図３に示され、キー・クラスの例が図４に示される。

図３に示されるように、各キー・クラス３００は、それの暗号化アルゴリズムの識別子（エレメント３１０）、それのキー長（エレメント３２０）、アルゴリズムによる使用のためのゼロ又は１つ以上のヒント(エレメント３３０)、コンポーネント・クリエータのＤＮ（エレメント３４０）、コンポーネント・クリエータのＸ.５０９証明書又はこのＸ.５０９証明書の識別子（エレメント３５０）、及び１つ又は複数のキー・オブジェクト（エレメント３６０、３７０、…３９０）を含む。好適な実施例では、キー・クラス３００は、図１の暗号化ヘッダ１１０として使用される。従って、キー・クラス又は暗号化ヘッダに対する参照が本願では相互交換可能に使用される。

好適な実施例では、コンポーネント・クリエータ（それのプライベート・キーがセキュリティ・コンテナにおける所定の動作のために使用される）のＤＮ３４０及びＸ.５０９証明書又は証明書識別子３５０は、受信者がその対応する公開キーを得ることができるようにセキュリティ・コンテナ内に平文で与えられる。Ｘ.５０９証明書は比較的大きいので、その証明書全体よりもむしろ証明書識別子の使用が望ましい。しかる後、証明書自体が、必要なときに証明書識別子を使用して検索可能である。（本発明の範囲を逸脱することなく、本願において開示されたＸ.５０９証明書又は証明書識別子の代わりに、他のタイプのセキュリティ・クリデンシャルが使用可能である）。コンポーネント・クリエータの公開キーは、例えば、セキュリティ・コンテナの一部分を通して計算されたディジタル署名を正当化するために必要とされることがある。（図１０のブロック８４０−８５０の説明を参照してほしい）。

次に図４を参照すると、本願では、この例示のキー・クラス３０１を含む例を示すときＸＭＬ表記法が使用されるが、それは説明を目的とするのためであって、限定の目的とするものではない。従って、例示のキー・クラス３０１は、「タイプ」アトリビュート３１１と「長さ」アトリビュート３２１とを有する「クラス」エレメント３０２を使用してエンコードされる。タイプ・アトリビュート３１１は暗号化アルゴリズムを識別するために使用され（図３におけるエレメント３１０）、長さアトリビュート３２１はキー長を指定する（図３におけるエレメント３２０）。図３において参照示される任意選択的ヒント３３０は図４には表示されてなく、ブロック暗号を初期化するためのパッディング（付け足し）・ビットのようなものを含み得る。

上記「選択的データ暗号化発明」は単一ファイル内で複数のキー・クラスを使用する機能を開示していることに注意してほしい。従って、そこに開示されたキー・クラスは、キー・クラス間を区別するために使用される「名前」アトリビュートを有する。本発明の好適な実施例は、特定のセキュリティ・コンテナにおけるドキュメント・コンポーネントを制御するための同じルール・セットを使用する。従って、本願における説明は名前アトリビュートの使用を省略する。別の実施例では、特定のセキュリティ・コンテナにおいて複数のキー・クラスが使用可能である。例えば、特定のセキュリティ・コンテナにおけるドキュメント・コンポーネントを暗号化するために複数の暗号化アルゴリズムを可能にすることが有用であると考えられる。この場合、すべての権限を与えられたユーザがその可能にされたアルゴリズムのいずれを使用することも許可されるように、キー・エレメント(後述される)がキー・クラス間で複製されることが望ましい。この別の方法は、例えば、セキュリティ・コンテナに対するターゲット・オーディエンスが種々の暗号化アルゴリズムをサポートし得るが、必ずしもそのオーディエンスのすべてのメンバが同じ暗号化アルゴリズムをサポートするのではない場合には有用であるかもしれない。

タイプ及び長さアトリビュートに加えて、キー・クラスのアトリビュートもクリエータのＤＮ及びＸ.５０９証明書識別子を指定するために使用可能である。図４におけるエレメント３４１、３５１を見られたい。更に、図１における別のエレメント１４０としてディジタル署名が示されているが（図９におけるエレメント７４０も参照）、別の実施例では、この値がキー・クラス３０１のアトリビュートとして指定可能である。

各キー・クラスは、本願では「キー」エレメントと呼ばれる１つ又は複数の子エレメントも含む。これらのキー・エレメントは、図３では、キー・オブジェクト３６０、３７０、．．．３９０によって表される。図４では、キー・クラス３０１の例が３つのキー・オブジェクト３６１、３７１、３８１を有する。（例示のキー・クラス３６１の拡張バージョンが、それに含まれた個々のエレメントを説明するために、図７に示される）。各キー・エレメントは、このセキュリティ・コンテナのドキュメント・コンポーネントをアクセスすることを許可されている個々のユーザ又はプロセス、あるいは、許可されているユーザ又はプロセスのグループを定義する。各キー・エレメントの望ましい構成が図５に示される。それに示されるように、キー・エレメント４００は、識別名（ＤＮ）４１０、Ｘ.５０９証明書識別子４２０、及び暗号化された対称キー４３０から構成される。ＤＮ４１０は、関連の暗号化された対称キーの復号化を試みるべきかどうかを決定するためにプログラム的にそれがスキャンされるよう、好適な実施例では平文である。

図５に示されるようにＸ.５０９証明書識別子４２０を使用する代わりに、所望であればＸ.５０９証明書全体がキー・エレメント内でエンコード可能である。図６はこの代替方法を示す。図示のように、キー・エレメント４０１は、図５におけるように(平文の) 識別名４１０及び暗号化された対称キー４３０を含むが、Ｘ.５０９全体は参照番号４２１においてエンコードされる。（明らかなように、Ｘ.５０９証明書識別子４２０又はＸ.５０９証明書４２１は、キー・クラス・アトリビュートの値として格納されるときには暗号化されない）。

次に図７を参照して、例示のキー・エレメントを更に詳細に説明する。このキー・エレメント３６１は、図４におけるサンプルのキー・クラス３０１からの第１リストのキー・エレメントであり、図５に示された構成に一致する。この例では、ＤＮアトリビュート３６２（特に、平文における）は、このキー・エレメントが Acme 組織（「o=acme」）に関連しているということ、更に詳しく言えば、共通名「managers（マネージャ）」（「cn=managers」）を有する「groups（グループ）」（「ou=groups」）と名付けられたそれの組織単位に関連しているということを指定する。これは、ディレクトリにおけるエントリを参照することが意図されている。なお、そのエントリは、マネージャ・グループ（即ち、Acme組織のマネージャのグループ）内にある個人のリストを含むことが望ましい。単に視覚的表示を可能にするために、KeyIdentifierアトリビュート３６３に対するサンプル値が供給される。（実際の動作では、この値は、Ekey アトリビュートの値と共に、その分野では知られているBase64エンコーディングを使用して２進フォーマットでエンコードされて、その結果がＸＭＬアトリビュート値において許容し得る印刷可能文字のみを含むようになることが望ましい。）

Ekey アトリビュート３６４は、対称キーの暗号化バージョンである。基礎となる対称キーは、セキュリティ・コンテナのルールとドキュメント・コンポーネントとを暗号化するために使用され、従って、権限を与えられた要求者に対してその情報を復号化するために使用可能である。好適な実施例によれば、前記「関連発明」において開示された手法は、（キー・エレメント３６１、３７１、３８１のEkey アトリビュートに示されるように）対称キーの暗号化バージョンを作成するために使用され、その対称キーの異なる暗号化バージョンが各異なるキー・エレメントに対して作成され、それによって、各々の権限を与えられたエンティティに対称キーを確実に配布する。更に詳しく言えば、キー・エレメント３６１において指定されるキー識別子３６３を有するエンティティと関連した公開キーは、対称キーを暗号化するために使用され、その結果、エンティティのプライベート・キーを平文における対称キーを回復するために使用することができるようになる。従って、図３のキー・クラス３００におけるキー・エレメントを参照すると、キー・エレメント３６１は、マネージャのグループの公開キーによって暗号化されたものとして、対称キーを（そのEkey アトリビュートの中に）含み、キー・エレメント３７１は、（ＤＮアトリビュート値において共通名「E135246」及び組織単位「users」を有する）個々のユーザの公開キーによって暗号化されたものとして、この同じ対称キーを含み、また、キー・エレメント３８１は、「hr」（人的資源を表す）グループと関連した公開キーによって暗号化されたものとして、同じ対称キーを含む。

グループの場合、ＤＮがそのグループを識別する。グループのメンバである個々人は、そのグループのプライベート・キーを得るために本発明の範囲外の手法を使用するか、あるいは、それらの代わりに本発明が使用されることを要求する。同出願人による、「グループ・クラークによる復号化のためにスタイル・シート処理を使用する選択的データ暗号化（Selective Data Encryption Using Style Sheet Processing forDecryption by a Group Clerk）」と題した米国特許出願０９/４２２,４９２は、これを達成するための１つの方法を定義している。（従って、Ｘ.５０９証明書における公開キーは、「サブジェクト」フィールド４４０において識別されるグループに属し、一方、ＤＮはグループ・クラークに属する）。しかし、本発明の範囲から逸脱することなく、グループのメンバーシップを決定するために及び個々のグループ・メンバを代表してグループのプライベート・キーを利用するために、他の手法が使用されてもよい。

暗号化アルゴリズム及びキー長が選択される態様及び対称キーの値が決定される態様は、本発明の一部を形成するものではない。そのアルゴリズム及びキー長を選択する１つの方法が、同出願人による、「ポリシ・プロファイリングに基づいて暗号化レベルを選択するための方法、システム及び装置（Method, System and Apparatus for Selecting Encryption Levels Basedon Policy Profiling）」と題した米国特許出願０９/２４０,３８７に開示されている。

次に、セキュリティ・コンテナのルールとドキュメント・コンポーネントとへのアクセスを保護するためのキー・クラス・エレメントの使用を、１つの例に関連して説明する。複合ドキュメントが Acme 組織の種々の従業員に関する情報を含み、各従業員に関する個人情報がセンシティブである（即ち、未許可のアクセスに対して保護を必要とする）ものと仮定する。従って、コンテンツ・クリエータ(例えば、この複合ドキュメントを作成するためにソフトウェア・アプリケーションを書くか又は使用する人)は、各従業員レコードがセキュリティ・コンテナ内に格納されるべきであることを指定し得る。更に、各保護された従業員レコードへのアクセスは、その従業員、Acme組織におけるすべての管理者、及び Acme 組織のＨＲ（人的資源）部門で働く誰かに制限されるべきであるものと更に仮定する。（明らかなように、この例では、各セキュリティ・コンテナは従業員レコードを含むが、別の例では、特定の複合ドキュメントにおける種々のセキュリティ・コンテナのドキュメント・コンポーネントは必ずしも同様のドキュメント・コンポーネントを含まない）。

図８には、ＸＭＬフォーマットを使用して、サンプル従業員レコード６００が提供される。この従業員に対する現在の給与及び医療情報（「curr_salary」及び「medical_condition」エレメントによってエンコードされる）はセンシティブな情報又は機密情報と考えられ、それによって、その従業員レコードへのアクセスを通して制御を必要とし、そのレコードに関する遂行可能な機能に関して制御を必要とする。これらのアクセス制御及び機能的制御は本発明のセキュリティ・コンテナによって提供可能である。図９は、未だ認証されていないユーザ又はプロセスにセキュリティ・コンテナが従業員レコード６００を表示する方法を概念的に示す。換言すれば、図８におけるドキュメント・コンポーネント６００は、図９のエレメント７５０によって総体的に示される暗号化された難解な形式でセキュリティ・コンテナに格納される。この例では、セキュリティ・コンテナ７００の暗号化ヘッダ７１０は図４におけるキー・クラス３０１を含む。セキュリティ・コンテナ７００は、更に、暗号化されたルール（エレメント７２０によって総体的に示される）、これらのルールを通して作成されたセキュア・ハッシュ（エレメント７３０によって示される）、及びキー・クラス７１０及びルールを通して作成されたディジタル署名７４０のセットも含む。図４における例に関連して説明されたように、キー・クラス３０１は、ユーザの３つの異なるセット（２つのユーザ・グループ及び１つの個人ユーザ）に対するキー・エレメントを含む。従って、いずれかのグループに属している又は特定の個人ユーザである、いかなるユーザも、セキュリティ・コンテナ７００における情報に対する少なくとも何らかのアクセス権を有する。ユーザに代わって作用するソフトウェアは、キー・クラスの非暗号化ＤＮ部分をスキャンすることによって、関連のプライベート・キーを使用したその暗号化されたエレメント（即ち、対応する Ekey アトリビュートの値として指定される暗号化された対称キー）の復号化を試みるように進行すべきかどうかを素早く決定することができる。

図１０は、セキュリティ・コンテナによって仲介されるドキュメント・コンポーネントへのアクセスを要求者が要求するときに、好適な実施例において遂行される動作を示す。セキュリティ・コンテナ・インターフェース２１０がユーザのアクセス・要求を受け取る（ブロック８００）。（本願における「ユーザ」、「要求者」、又は「要求元エンティティ」という参照は、個人又はグループ・メンバのような人間のユーザと、ドキュメント・コンポーネントを要求する実行プログラムといったプログラミング・プロセス又はエンティティとに等しく適用するものとして解釈されるべきである。人間ユーザの場合のように、プログラム的プロセスは、キー・オブジェクトにおいて、又はプロセスのグループを表すキー・オブジェクトを使用することによって、個々に識別可能である。）しかる後、ユーザのＤＮが、例えば、従来技術の手法を使って、ローカル・ストレージから又はディレクトリから得られる（ブロック８０５）。

次に、ユーザのＤＮが、セキュリティ・コンテナの暗号化ヘッダにおけるキー・エレメントのＤＮアトリビュートに比較される（ブロック８１０）。たとえユーザのＤＮが（例えば、特定のユーザを識別する図４のキー・エレメント３７１に示されるように）暗号化ヘッダにおいて直接にリストされていなくても、ユーザは、アクセス権を有するグループのメンバであることによって、依然としてアクセス権を有し得る。各グループ・メンバを識別するために、グループ・メンバーシップが、キー・エレメントにおいて指定されたグループを拡張することによって評価される。グループのＤＮは、グループのメンバの識別子が事前に格納されているディレクトリを調べるために使用されることが望ましい。

権限を与えられたユーザを識別するためにグループ・メンバーシップを使用することは、アクセス権を制御する非常に融通性のある有利な方法を提供する。権限を与えられたユーザを識別するためにグループ・メンバーシップを使用することは前記「関連発明」において開示された。この方法は、セキュリティ・コンテナにおけるドキュメント・コンポーネントへのアクセスを制御するよう本発明によって強化される。例えば、ユーザ「ボブ」がキー・エレメント３７１における「cn=E135246」の値と関連する指定された個人ユーザではなく、キー・エレメント３６１によって表されたマネージャ・グループ又はキー・エレメント３８１によって表されたＨＲグループにもない場合、ボブはそのセキュリティ・コンテナに対するアクセスを拒否されることになる。しかし、その後、ボブがマネージャになる場合、彼は、グループ・メンバーシップを定義するディレクトリにおけるマネージャ・グループの定義に彼のＤＮ（又は、ディレクトリがグループ・メンバーシップを識別する方法に依存した他の識別子）を単に加えることによって、そのマネージャ・グループがそこでの権限を与えられたユーザであるすべてのセキュリティ・コンテナへのアクセスを自動的に持つことになる。個々のセキュリティ・コンテナは（特に、どのユーザが許可されているかを決定するコードを含めて）変更される必要がなく、保護されたドキュメント・コンポーネントを作成するコードも必要としない。

ユーザを認証し、グループにおけるユーザのメンバーシップを決定し、グループのプライベート・キーをそのユーザに提供し、そのユーザに代わってグループのプライベート・キーを使用して復号化を行うための手法は本発明の範囲外であることに留意すべきである。「グループ・クラークによる復号化のためにスタイル・シート処理を使用する選択的データ暗号化（Selective Data Encryption Using Style Sheet Processing forDecryption by a Group Clerk）」と題した前記米国特許出願０９/４２２,４９２において開示された手法は、これを行い得る１つの方法である。

グループのクラークに接触することが可能でない場合（例えば、そのグループ・クラークへのネットワーク接続が使用可能でない場合、又はグループ・クラーク・プロセスがオフラインである場合）、セキュリティ・コンテナが、将来、同じユーザによってアクセスされ得るようグループ・メンバに代わってグループ・クラークから取り出された対称キーを記憶するために、ローカル・キャッシュが任意選択的に維持される。これは図１０に示されていないが、本願に開示された教示事項を知れば、当業者によって容易に組み込み可能である。キャッシュされたエントリは図５及び図６に示されたキー・エレメントと同様の構成を有することが望ましい。このキャッシュされたエントリには、グループ・クラークによって復号化された対称キーがこの個人ユーザの公開キーによって再暗号化されている。更に、ユーザのＤＮ及びユーザのＸ.５０９証明書の識別子がそのグループ・クラークの情報の代わりに指定されることが望ましい。このユーザがメンバであると決定されたグループにこのユーザを相関させるために、更なるフィールドが追加可能である。このようなキャッシュされたエントリに対して許容されたキャッシュ持続時間を表示するために特別のルールが使用されてもよい。

図１０の説明に戻ると、個人としてのユーザ又はグループ・メンバとしてのユーザのいずれかに対して一致が見つかった場合(ブロック８１５)、このユーザはアクセス権を持ち、制御がブロック８２５に移る。そうでない場合、要求者はカプセル化されたドキュメント・コンポーネントに対するアクセス権を持たず（ブロック８２０）、セキュリティ・コンテナは、その要求者がドキュメント・コンポーネントに関してそれ以上何も更に学ばないようにする。このドキュメント・コンポーネントがロックされ、従って、このドキュメント・コンポーネントをアクセスすることができない、ということをユーザに表示するために、ロックを表す読取専用アイコン（又は、ドキュメント・コンポーネントへのアクセスが拒否されることを意味する同様のユーザ・インターフェース・メタファ）が要求者に戻される。別の方法として、例外が与えられるか、あるいは、特定の実装方法次第で、エラー・メッセージ、エラー・コード又は他の表示が戻されてもよい。そこで、この処理要求に対する図１０の処理が終了する。

制御がブロック８２５に達するとき、このユーザは、セキュリティ・コンテナのルールをアクセスすること(即ち、復号化すること)を許可され、それらのルールの評価次第で、セキュリティ・コンテナ内のドキュメント・コンポーネントに関する指定された機能をアクセスしかつ遂行するための少なくとも何らかの権利を有する。従って、ブロック８２５は、セキュリティ・コンテナのルールとドキュメント・コンポーネントとを保護する対称キー、を暗号化するために使用された公開キー、に対応するプライベート・キーを得る。

個人ユーザの場合、プライベート・キーは、このユーザのためのＸ.５０９証明書における身元識別情報と公開キーとに対応する、ユーザのプライベート・キーである。プライベート・キーは、一般に、ユーザのコンピュータにおけるローカル・ストレージに安全に格納される。ユーザが複数のＰＫＩ公開キー／プライベート・キーのペアを有する場合、このユーザのＤＮが見つかったキー・エレメントからのキー識別子が、正しい証明書（及び関連のプライベート・キー）を識別するために使用可能である。例えば、特定ユーザのＤＮが図４のキー・エレメント３７１における「ＤＮ」アトリビュート値と一致する場合、そのキー・エレメントの「keyIdentifier」アトリビュートの値は、キー・エレメント３７１の「Ekey」アトリビュート値を暗号化するために使用された公開キーの値に対応するＸ.５０９証明書を識別する。従って、そのＸ.５０９証明書に対応するプライベート・キーが、暗号化ヘッダにおけるキー・クラスから対称キー（Ekey アトリビュートにおける）を復号化するために使用される（ブロック８３０）。

別の方法として、ユーザがグループ・メンバであることによって認証される場合、ブロック８２５において得られたプライベート・キーは、そのグループと関連したプライベート・キーである。ある実施例では、グループ・メンバはそれぞれグループのプライベート・キーのコピーを有する。しかし、好適な実施例では、グループ・メンバはこのグループのプライベート・キーを個々には格納しない。その代わり、各グループに対して事前に指定されたグループ・クラークがプライベート・キーを維持している。グループ・クラークの使用は、そのクラークが接触する方法と、そのユーザが真にグループ・メンバであるかどうかを（例えば、ユーザを認証し、上述のように、ユーザの識別表示を既知のグループ・メンバに比較することによって）そのクラークが検証する方法とを更に詳細に説明した前記「関連発明」において開示されている。

グループ・クラークは、グループのプライベート・キーに関するクラークのコピーを使用して、グループ・メンバを代表してブロック８３０において暗号化された対称キーの復号化を行い、その復号化された対称キーを相互に認証されたセキュア・チャネルを介して（例えば、セキュア・ソケット層（ＳＳＬ）、又は、トランスポート層セキュリティ（ＴＬＳ）プロトコルのようなプロトコルを使用して）ユーザに戻す。別の方法として、セキュア・チャネルが確立されない場合、グループ・クラークは、グループのプライベート・キーを使用して復号化を遂行し、しかる後、ユーザの公開キーを使用して現在平文の対称キーを再暗号化することが望ましい。そこで、対称キーのこの再暗号化バージョンは、非セキュア・チャネルを介してユーザに配送可能であり、その後、ユーザは自身のプライベート・キーでもってその対称キーを復号化する。（別の方法として、再暗号化は、グループ・クラーク及びグループ・メンバによって共用される対称キーを使用して遂行されてもよい）。

ユーザが個々に許可されようとも、あるいはグループ・メンバであることによって許可されようとも、ブロック８３５に達すると、このユーザに対する対称キーは今や使用可能である。そこで、この対称キーが、セキュリティ・コンテナからのルールを復号化するために使用される。

ブロック８４０において、セキュリティ・コンテナに含まれたセキュア・ハッシュ及びディジタル署名が検証される。ルールのセキュア・ハッシュ（図１のエレメント１３０及び図９のエレメント７３０参照）は、適正なプライベート・キーが対称キーを回復させるために（即ち、ブロック８３０において行われた復号化において）使用されたかどうかを決定することを可能にする。これは、単にブロック８３０の結果を調べることによるだけでは容易には決定され得ない。それは、得られるビット列が使用不可能なランダムなビット列であるかも知れず、あるいは、（ブロック８３５における復号化からの）有効なルール及び（復号化がルールによって許される場合には）有効な復号化されたドキュメント・コンポーネントを提供し得る実の対称キーであるかもしれないためである。単に、無効の対称キーが使用されたために、セキュリティ・コンテナがルールの破壊されたバージョン又はドキュメント・コンポーネントを提供することは明らかに受容し得ないことであろう。従って、周知の従来技術を使用して、ブロック８３５に起因した復号化されたルールを通してセキュア・ハッシュが計算され、この新たに計算されたハッシュがセキュア・ハッシュ値１３０に比較される。

新たに計算されたハッシュ値がセキュア・ハッシュ１３０と一致する場合、これは、正しい対称キーがルールを復号化するために使用されたということの保証を強化することを表し、セキュリティ・コンテナがルールを中断するように、及びユーザが許可される場合にはドキュメント・コンポーネントを復号化するように、進行し得るという保証を強化することを表す。ハッシュ値における不一致は、ブロック８３５においてルールを復号化するために適正な対称キーが使用されなかったことを表す。従って、ブロック８５０に示されるように、セキュリティ・コンテナをアクセスしようとする試みは拒否可能である。例えば、「保護コンテンツは使用不可能」という表示が戻されてもよい。又は、ユーザが権限を与えられた異なる身元識別情報を有する場合、キー・クラスの処理を継続する対話的プロセス（図１０には示されない）が使用可能である。この対話的プロセスにおいて、ユーザに対する別のＤＮを得るために、制御はブロック８０５に戻ることが望ましく、ＤＮが権限を与えられるかどうかをブロック８１０〜８４０がチェックし、そのＤＮに関連したプライベート・キーを得て、そのプライベート・キーを使用して対称キーを復号化し、復号化された対称キーを使用してルールをロック解除し、しかる後、ハッシュを再計算し、それをセキュア・ハッシュ１３０と比較してこのバージョンのルールが受容可能であるかどうかを決定する。

好適な実施例では、ブロック８４０の処理は、コンポーネント・クリエータの公開キーを得ることも含む。この公開キーは、本発明の範囲から逸脱することなく多くの種々の方法で得ることが可能である。例えば、暗号化ヘッダ１１０からのコンポーネント・クリエータのＤＮが、公開キーを格納しているディレクトリにおいてコンポーネント・クリエータを探索するために使用可能である。別の方法として、コンポーネント・クリエータの公開キーが、暗号化ヘッダ１１０内にあるＸ.５０９証明書に含まれ得るし、あるいは、暗号化ヘッダ１１０からのＸ.５０９証明書識別子がこの証明書を見つけるために使用可能であり、その場合、公開キーの値が証明書から検索可能である。

セキュリティ・コンテナにおけるデータの許可されてない修正を検出するために、好適な実施例では、各セキュリティ・コンテナにおいてディジタル署名を含む。（図１のエレメント１４０及び図９のエレメント７４０参照）。望ましくは、このディジタル署名は、キー・クラス及びルールを通して計算され、従って、権限を与えられたユーザの暗号化ヘッダ及びそれのリストに対する修正、並びに、ルールに対する修正を検出するために使用可能である。好適な実施例では、コンポーネント・クリエータのプライベート・キーが、所定のアルゴリズム及びキー長を使用して、ディジタル署名を作成するために使用される。ディジタル署名を作成するための手法は、その分野では周知である。例えばディジタル署名は、コンピュータ・クリエータのプライベート・キーでもって前述のフィールドのハッシュを暗号化することによって計算されることが望ましい。（好適な実施例において、ハッシュを計算するときに使用されるルールは暗号化されてないルールであるが、別の実施例では、暗号化されたルールが使用可能である）。ディジタル署名は、セキュリティ・コンテナ内に平文で保持される。ブロック８４０は、コンポーネント・クリエータの公開キーを使用してこのディジタル署名を復号化し、暗号化されてないハッシュ値を生成する。そこで、そのカバーされたフィールドにおけるハッシュが新たに計算され、ディジタル署名から得られたハッシュと比較される。セキュリティ・コンテナは、コンポーネント・クリエータの公開キーを使用するディジタル署名のこのチェックが比較一致し得なかった場合、恐らく障害があるものとして廃棄されなければならない。（明らかなように、セキュア・ハッシュ及びディジタル署名のチェックは、たとえそれらが図１０では一緒に示されていても別々に行われ、不一致のハッシュ及び不一致のディジタル署名のために別々のエラー処理ロジックが提供可能である）。

図２をもう一度参照すると、ブロック８３５によって復号化されたルール２２０は、セキュリティ・コンテナのインターフェース２１０の方法及び特性に対する参照を排除する。従って、ブロック８５５は、ユーザの遮断されたアクセス要求を評価のためにルールに送ることを表し、その結果に従って、ドキュメント・コンポーネントは、復号化され、非直列化され、そしてインスタンス化される。その方法及び特性２４０が呼び出され、ドキュメント・コンポーネントが何らかの形式でユーザに戻される(ブロック８６０)。（例えば、ドキュメント・コンポーネントがテキスト形式である場合、前述のように、それはテキストとして、恐らくそのテキストを描いたイメージとして戻されるであろう）。

たとえユーザが、ブロック８２５に達することによって、及びその後の処理によって、セキュリティ・コンテナのドキュメント・コンポーネントへのあるレベルのアクセスを行っても、更なるアクセス関連のチェックがルールによって遂行可能であり、従って、ユーザが依然としてアクセスを拒否される場合があり得る。そうでない場合、ユーザがアクセス権を有するときは、要求者がドキュメント・コンポーネントに関して何を行おうとしているかを決定するようにルールが機能する。

図１０に示された論理的動作のシーケンスに対する代替として、ユーザは、そのユーザのＤＮ及びそのユーザが属するグループのＤＮをすべて論理的に定義させることができ、一致を期待しているセキュリティ・コンテナの暗号化ヘッダのリストをスキャンすることができる。一致が見つかった場合、ユーザは、そのユーザ又はグループに対して意図された対称キーのバージョンを復号化するように関連するプライベート・キーを適用することもできる。

ユーザがルール及びコンテンツを自身のプライベート・キーでもって復号化することの代替として、あるいは、グループ・クラークがグループ・メンバに代わってルール及びコンテンツを復号化することの代替として、クライアントの代わりに働くクライアント・プロキシによって、又はすべての保護されたコンテンツに関しての権限を与えられたユーザとして有効に働くキー回復エージェントによって、復号化が実行可能である。キー・クラス情報をクライアント・プロキシ及びキー回復エージェントと共に使用するための手法は、上記「関連発明」（特に、米国特許出願０９／４２２,５３７及び同０９／４２２,４３１）に詳細に開示されている。一般に、クライアントとクライアント・プロキシとの間の通信は、クライアント・プロキシが情報を復号化し、それを平文でクライアントに戻すために、できれば相互に認証されたセキュア・チャネルを使用する。別の方法として、クライアント・プロキシは、クライアントの公開キーでもって（又は、クライアントとプロキシとの間で共用される対称キーでもって）情報を再暗号化してもよい。好適な実施例では、クライアント・プロキシは、クライアントに代わってセキュリティ・コンテナをアクセスするために、セキュリティ・コンテナに関して権限を与えられたユーザでなければならないことに留意されたい。キー回復エージェントの場合、他の唯一の権限を与えられたユーザが自身のアクセス権を失ったとき、追跡目的即ち監査のために、暗号化されたドキュメント・コンポーネントを回復させることが必要となる場合がある。前記「関連発明」において開示されているように、キー回復エージェントは、キー・オブジェクトを定義させることによって、そのキー回復エージェントについての各キー・クラス内で任意の対称キーの平文値を回復することが可能である。複数のキー回復エージェントが許される場合、キー・オブジェクトはグループを識別するものとして定義可能である。望ましくは、キー回復エージェントは（例えば、キー回復エージェントと関連した特別のＩＤをルールで使用することによって）ルールのフィルタリングを回避することを可能にされ、従って、それはいつも、組み込まれたドキュメント・コンポーネントのすべての方法及び特性をアクセスすることができる。更に、キー回復エージェントは、（図２における参照番号２１１として一般的に示されるように）セキュリティ・コンテナを管理するように定義されたいずれのルールに対してもアクセスを行い得ることが望ましい。いずれにしても、クライアント・プロキシ又はキー回復エージェントに対するキー回復プロセスは、図１０に関して上述したように進行する。

要求者との対話におけるある時点で（例えば、ユーザがそれとの対話を終了するとき）、セキュリティ・コンテナ・オブジェクトは、一般に、それ自体を直列化するように（即ち、記憶又は伝送のためにそれ自体を正規のフォーマットに変換するように）要請される。一方、ドキュメント・コンポーネント・オブジェクトが何らかの方法でそれの方法又は特性の使用を変更されたものと仮定すると、セキュリティ・コンテナは、それが持っていたドキュメント・コンポーネントを直列化し、この直列化されたストリーム及びルールを暗号化し、しかる後、それ自体の選択的に暗号化されたＸＭＬストリームを再構成する。ルール及びドキュメント・コンポーネントを復号化するために使用された対称キーは、この再暗号化のために使用されることが望ましく、その復号化を遂行したセキュア・コンテナ・ロジックによって記憶されることが望ましい。（対称キーは、一般に、セキュリティ・コンテナのための、暗号化されてないルールと他の状態データとが存在する、保護メモリ領域に格納されることになる。そのような保護メモリが動作する態様は本発明の範囲外である）。

前記「参照発明」において開示されたキー・クラス手法の使用に関連して好適な実施例を説明したが、キー・マテリアルを配布し、そのような情報をセキュリティ・コンテナ内でエンコードするための他の手法が、本発明の範囲を逸脱することなく代替的に使用可能である。

特定のドキュメント・コンポーネントに対するルールの規定は、明らかに広く変更可能である。本願における記述は説明を目的として提供され、限定を目的とするものではない。ルールが機能的制御における種々の要因と見なし得る方法の例として、セキュリティ・コンテナにおけるドキュメント・コンポーネントが機密のテキスト・ファイルであると仮定し、更にこのユーザは、自分のデスクトップ・コンピュータを使用するときには機密情報を受け取ることだけを望んでいるということを表すユーザ・プロファイルを有するものと仮定する。この場合、ルールは要求者へのドキュメント・コンポーネントの配布を防止することになる。ルールは、要求されたドキュメント・コンポーネントの代わりに、ユーザにそのユーザの要求を拒否する理由を知らせる代用メッセージが配布されるように書かれてもよい。別の方法として、ユーザはエラー表示を受けてもよく、あるいは単に何も受け取らなくてもよい。

もう１つの例として、もしも要求者のコンテキストが示しているのが、その要求者が、自分の「ビジネス」分離ゾーンにいるものとして自分が構成したテキスト処理アプリケーションを使っている、ということである場合は、ルールによって、そのテキスト処理アプリケーションによるセキュリティ・コンテナの持つドキュメント・コンポーネントの処理と、ビジネス分離ゾーン内でのドキュメント・コンポーネントのレンダリングが可能になるということを保証するために、そのルールがチェックを行うことが可能である。あるいは、Microsoft Word のドキュメントを編集するために、例えば StarOffice（商標）を使用することを保証するため、または、それ以外の場合にはこのドキュメント・コンポーネントへのアクセスを妨げるために、これらルールがチェックを行ってもよい。あるいは、ユーザがLotus Freelance Graphics(商標)からの図面を Word のドキュメントに貼り付けようとする場合は、その図面のためにセキュリティ・コンテナにおいてカプセル化されたルールが、このアプリケーション間の転送を妨げるので、その貼り付け動作は成功しないことになる。これに対して、続いてそのユーザが図面（又は、その図面を表すアイコン）をクリップボード上にコピーし、しかる後、アイコンをFreelance ドキュメントに貼り付けようとする場合、（そのルールによってチェックされた他の条件が適合しているものと仮定すると）そのルールはこの転送を許可することになる。（なお、「StarOffice」は Sun Microsystem,Inc. の商標であり、「Freelance」は International Business Machines Corporation の商標である）。

更にもう１つの例として、セキュリティ・コンテナのドキュメント・コンポーネントを印刷するようにユーザが要求するものと仮定する。ユーザのプリンタがカラーでの印刷をサポートする場合のみ印刷を可能にするというルールが定義可能であり、あるいは、選択されたユーザに対してのみ印刷が可能にされ、一方他のユーザ（又は、選択されたユーザの別のセット）は、ドキュメント・コンポーネントを見ることができるが印刷することはできないということをルールが指定し得る。グループは、上述のように、種々の機能を遂行することができるユーザを定義可能である。例えば、「print-me」グループは、ドキュメント・コンポーネントを印刷することを許されているユーザを識別するように定義可能であり、「see-me」グループは、ドキュメント・コンポーネントを見ることを許されているユーザを識別するように定義可能である。グループ・メンバーシップは、例えば、ユーザＩＤをルールに直接にコード化することによって静的に識別可能である。あるいは、グループ・メンバーシップは動的に決定可能である。この場合、グループ名はルール内で指定されることが望ましく、グループ・メンバーシップは、実行時における遅いバインディングによって（例えば、グループの最新のメンバーシップを知るためにディレクトリと相談することによって、又は人の属するグループが列挙されているローカル・ストレージと相談することによって）解決される。権限を与えられたユーザに対するグループ・メンバーシップを動的に決定することに関して上述したように、グループに対するユーザのこの遅いバインディングは、ユーザに権利を付与するための非常に融通性のある方法を提供する。

更にもう１つの例として、本願に開示されたセキュリティ・コンテナは、ドキュメント・コンポーネントの集合体がセキュア態様で遂行されることを可能にする。例えば、オンライン・マガジンは、それぞれがそれ自身の著者のセキュリティ制約を伴なうストーリを、電子コレクションからコピーされたライセンス・クリップ・アートと共に集め、それによって集合ドキュメントを作成することができる。本願において開示されたセキュリティ・コンテナを使用するとき、種々の著者のセキュリティ制約や、並びにクリップ・アート・コレクションによって課せられたセキュリティ制約が、集合ドキュメント内に有効に残っている。これは、従来技術による手法においては、本発明におけるようにドキュメント内のオブジェクト（即ち、個々のドキュメント・コンポーネントを表すオブジェクト）に関して動作するのではなくファイル又はドキュメント・レベルで動作する、というのとは対照的である。従って、これらの従来技術による手法は、アクセス権及び／又は機能的権利に関する種々のルールを有する部分から構成された集合体を処理することができない。特に、本願の発明者は、本発明におけるように、ドキュメントの一部分又はコンポーネントを他のドキュメントにコピーすること、及び宛先でそのコピーされたコンポーネントに対する制御をそのままにしておくこと、を可能にする従来技術を知らない。

更に複雑な例では、本発明によるコンテンツ保護は、多重特権グループ構造（即ち、複数のグループが定義され、各グループが他のグループとは異なる権利を有するところ）におけるユーザのメンバーシップと、ユーザの要求が行われたときに使用中のアプリケーションと、要求の時間にアプリケーションを管理する分離ゾーンと、要求者のコンピュータのデバイス・タイプと、デバイスのネットワーク・アドレス（又は、アドレス・パターン）と、デバイスに取り付けられたキーボードのタイプと、要求が受け取られたときの現在の時刻との結合に基づかせることができる。

更にもう１つの例として、セキュリティ・コンテナがイメージを保持しているものと仮定する。セキュリティ・コンテナはウェブ・ページに組み込まれ、そこから、ユーザは自由な「試行的使用」モードでイメージをダウンロードすることができることになる。（とりわけ、本発明によれば、たとえユーザがこの区別について知らなくても、要求者にダウンロードされるオブジェクトはセキュリティ・コンテナ全体であって、単なるイメージではない）。更に、限定された時間にのみその試行使用モードにユーザを参加させることが望ましいものと仮定する。なお、この限定された時間の後に、ユーザは、既にダウンロードされたイメージを含むウェブ・サイトのコンテンツに対する継続したアクセスを行うためには、メンバーシップの代価を支払わなければならない。従って、セキュリティ・コンテナにおけるルールを、このシナリオを強化するように書くことが可能である。例えば、ルールは、ダウンロードの日付及び時間を記録するためのコードと、限定された自由試行期間の間にイメージが提供されたことを覚えておくためのコードとを含み得る。ユーザがダウンロードされたイメージのコピーにアクセスするときにはいつも、セキュリティ・コンテナは、そのアクセスの日付及び時間をダウンロードの日付及び時間と比較して、今や試行期間が終了してしまったかどうかを決定する。終了してしまってない場合は、自由試行期間が有効に残っており、ユーザはアクセスを許可される。一方、自由試行期間が終了してしまった場合、セキュリティ・コンテナは、自由試行期間が終了してしまったことと更なるアクセスには購入したメンバーシップが必要であることとの表示を戻すことができる。続いて、事前にダウンロードされたオブジェクトをユーザがアクセスしようとするとき（あるいは、その他、自由試行期間中であっても、すべてのアクセスの試みに対して）、ルールは、要求しているユーザがメンバーシップを購入したかどうかを決定するためにディレクトリ又は他のユーザ・レジストリと動的に接触することができる。購入している場合には、アクセスは許可される。ルールは、アクセスのタイプを変更することを許可するように書かれ、また、望むならば、段階的価格のメンバーシップ構造に基づいている場合もあるが、機能的な動作タイプの変更を可能とするように書かれルこともまた可能である。

セキュリティ・コンテナによって制御されるべきすべてのコンテンツが「セキュリティ・センシティブ」である必要があるわけではないことに留意すべきである。むしろ、セキュリティ・コンテナによって行われるアクセス制御及び機能的制御は、いずれのタイプのドキュメント・コンポーネントでも保護するように使用することができる。セキュリティ・コンテナによって強化された制御は、コンポーネント・クリエータの意図次第で、非常に非限定的であってもよく、非常に限定的であってもよく、または両者の間のどんな程度であってもよい。

主として、テキストのコンテンツに関連して好適な実施例を記述したが、これは説明のためであって、限定のためではない。他のコンテンツ・タイプが同様の方法で制御可能である。例えば、音声ファイルは、受信者が音声を聴くことを可能にするが音声を記録することを可能にするものではないという機能的制御と共に配布可能である。本願において開示された手法は特定のコンテンツ・フォーマットに限定されず、コンテンツ・フォーマットの構成又は登録事項を必要としないので、新たに開発されたオブジェクト及びコンテンツ・エンコーディングは、本発明の実装に対して如何なる変更も必要とすることなくサポート可能である。

本発明の実施例はオペレーティング・システム内に組込み可能であり、あるいは、オペレーティング・システムにアドオンまたはプラグインとして提供可能である。他の実施例も本発明の範囲内にある。更に、本発明の実施例は、ユーザのワークステーションにローカルに格納されるコンテンツ、ネットワーク・サーバからの配送を要求することによって検索されるコンテンツ、（Ｅメールまたはメッセージ・キューのような）メッセージングの基盤を介して受け取られるコンテンツ、等と共に有利に使用可能であるということに留意すべきである。

（ほとんどのオペレーティング・システムが既にユーザ及びグループ・アトリビュートを考慮していると仮定して）オペレーティング・システムのプロセス特性にコンテキスト及びゾーンの考察を加えることによって、本願において開示されたセキュリティ・コンテナを使用するときに、アプリケーション間での保護されたコンテンツの貼り付けを更に制御することが可能である。望ましくは、セキュリティ・コンテナの構成は、そのような修正されたオペレーティング・システムではクリップボード上で許される唯一のオブジェクト形式であり、従って本来、すべてのカット・アンド・ペースト・オペレーションは、カット及びペーストされるべきコンテンツを保護するセキュリティ・コンテナとそのルールとの介入を通して制御される。

別の方法として、既存のオペレーティング・システムは、カット・アンド・ペーストをセキュリティ・コンテナに限定するように適応可能である。これを行い得る１つの方法は、例えば、本願において規定されたセキュリティ・コンテナの動作を実施するダイナミック・リンク・ライブラリ（ＤＬＬ）モジュールで置き換えることによって、アプリケーション・プログラム間でのコンテンツの挿入を管理する既存のＡＰＩをラップする（覆う）することである。（権限を与えられたユーザを指定するルール及びＤＮは、ユーザ及びアドミニストレータによって事前定義されることが可能であり、前記同出願人による「分離ゾーン発明」における分離ゾーン間の境界をまたがったコンテンツの挿入を制限するために、特定のアプリケーション・プログラム、ゾーン、Ｅメール受信者、仲間リスト、ファイル・システム・ディレクトリ、等に結合することも可能であるということに留意されたい。例えば、要求元ユーザが権限を与えられているかどうかを検証するように、そして、しかる後、要求されたドキュメント・コンポーネントのためのルールを提供する適正な「保護プロファイル」を自動的に選択するように、あるいは恐らく、ユーザが選択を行うことができるように、そのような保護プロファイルの選択肢をユーザに対して表示するように、ＤＬＬを書くことが可能である。あるいはまた、ユーザが、使用されるべきルールを明示的にセットすることを許されることもある。）しかる後、コンテンツがクリップボードから他のアプリケーションにペーストされるべきとき、セキュリティ・コンテナのルールが呼び出され、その貼り付け動作が実行されることになるかどうかが決定される。既存のクリップボードに対するプラグイン拡張機能として「クリップボード・ビューア」を設けることが可能であり、コンテンツがクリップボードに加えられるときにいつもそれが呼び出される。呼び出し時に、プラグインは、望ましくは、クリップボードに加えられるべきコンテンツを保護するセキュリティ・コンテナを作成し、セキュリティ・コンテナによって保護されてないクリップボード・バッファ内に既に存在している如何なるデータも排除する。このように、アプリケーション間でコンテンツを転送するための要求が行われるときにはいつも、コンテンツはセキュリティ・コンテナによって保護可能である。更に（上記「分離ゾーン発明」の教示を遥かに越えるが）一旦ドキュメント・コンポーネントが本発明のセキュリティ・コンテナ内で保護され、他の受信者に転送されると、そのコンテナは、そのドキュメント・コンポーネントについてのアクセス制御及び機能的制御に関してコンポーネント・クリエータの意図を強要し続ける。

本発明のセキュリティ・コンテナを理解するアプリケーションを使用してドキュメント・コンポーネントが作成される場合、そのアプリケーションは、セキュリティ・コンテナのルールと、権限を与えられたユーザと、にとっての適正な値をコンポーネント・クリエータにプロンプト指示することができ（あるいは、初期設定値を使用することができ）、ドキュメント・コンポーネントはその初期作成のときから、本発明に従って保護されるであろう。

本発明のセキュリティ・コンテナを知らない第１のアプリケーションによってドキュメント・コンポーネントが作成される場合、そのドキュメント・コンポーネントは、ルールと、権限を与えられたユーザと、にとっての適正な値を決定し、その後、ドキュメント・コンポーネントを保護する、セキュリティ・コンテナを知る第２のアプリケーションを呼び出すことによって、セキュリティ・コンテナにおいて後で保護されることが可能である。例えば、クリップ・アート・クリエータは、通常のアートワーク作成ツールを使用してアートワークを作成することもできるし、そのアートワークを通常のファイル・システムに保存することもできる。クリエータは、そのクリップアートを販売のためのライブラリとしてパッケージ化する準備ができるとき、セキュリティ・コンテナ内でそのクリップアート・アイテムを保護するために第２のアプリケーションを呼び出し、試用期間の後に（例えば）支払いを要求するルールを規定し、保護されたセキュリティ・コンテナの形でクリップアート・ライブラリの配布のみを行う。

図１１は、本発明を実施し得る代表的なワークステーション・ハードウェア環境を示す。図１１の環境は、関連する周辺装置を含む、パーソナル・コンピュータのような代表的な単一ユーザ・コンピュータ・ワークステーション９１０を有する。ワークステーション９１０はマイクロプロセッサ９１２及びバス９１４を含み、バス９１４は、既知の手法に従ってマイクロプロセッサ９１２とワークステーション９１０のコンポーネントとの間を接続し、それらの間の通信を可能にする。一般に、ワークステーション９１０はユーザ・インターフェース・アダプタ９１６を含み、このユーザ・インターフェース・アダプタ８１６は、キーボード９１８、マウス９２０、及び／又は、その他のインターフェース・デバイス９２２であって、接触感応型スクリーンやディジタイザ入力パッド等といった任意のインターフェース・デバイスたり得るもの、の如き１つ又は複数のインターフェース・デバイスにバス９１４を介してマイクロプロセッサ９１２を接続する。。バス９１４は、更に、ＬＣＤスクリーン又はモニタといったディスプレイ・デバイス９２４を、ディスプレイ・アダプタ９２６を介してマイクロプロセッサ９１２に接続する。バス９１４はまた、マイクロプロセッサ９１２を、メモリ９２８と、ハード・ドライブ、ディスケット・ドライブ、テープ・ドライブ等を含み得る長期ストレージ９３０とにも接続する。

ワークステーション９１０は、例えば、通信チャネル又はモデム９３２を介して他のコンピュータ又はコンピュータ・ネットワークと通信を行うことが可能である。別の方法として、ワークステーション９１０は、セルラ・ディジタル・パケット・データ（ＣＤＰＤ）カードのような無線インターフェース９３２を使用して通信を行うことも可能である。ワークステーション９１０は、ローカル・エリア・ネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）におけるそのような他のコンピュータと関連付けることも可能であり、あるいは、ワークステーション９１０は、他のコンピュータを有するクライアント／サ−バ構成におけるクライアント等であってもよい。これらの構成、並びに、適正な通信ハードウェア及びソフトウェアはすべてその分野では知られている。

図１２は、本発明を実施し得るデータ処理ネットワーク９４０を示す。データ処理ネットワーク９４０は、無線ネットワーク９４２やネットワーク９４４のような複数の個別のネットワークを含む場合があり、それらのネットワークの各々は、複数の個別のワークステーション９１０を含む場合がある。更に、当業者には明らかなように、１つ又は複数のＬＡＮが含まれ得る（図示されてない）。なお、ＬＡＮは、ホスト・プロセッサに結合された複数のインテリジェント・ワークステーションを含む場合がある。

図１２を更に参照すると、ネットワーク９４２及び９４４は、ゲートウェイ・コンピュータ９４６又はアプリケーション・サーバ９４７（データ・リポジトリ９４８をアクセスし得る）のようなメインフレーム・コンピュータ又はサーバも含み得る。ゲートウェイ・コンピュータ９４６は各ネットワーク９４４へのエントリ・ポイントとして働く。ゲートウェイ・コンピュータ９４６は、通信リンク９５０ａによって別のネットワーク９４２に結合されることが望ましい。ゲートウェイ・コンピュータ９４６は、通信リンク９５０ｂ、９５０ｃを使用して１つ又は複数のワークステーション９１０に直接に結合可能である。ゲートウェイ・コンピュータ９４６は、インターナショナル・ビジネス・マシーンズ・コーポレーション（「ＩＢＭ（商標）」）から入手可能な Enterprise System Architecture）/370（商標）、Enterprise SystemArchitecture/390(商標)コンピュータ等を利用して実装可能である。アプリケーション次第で、Application System/400（商標）（AS/400（商標）としても知られている）のような中規模コンピュータが使用可能である。（なお、「EnterpriseSystem Architecture/370」、「ＩＢＭ」、「Enterprise System Architecture/390」、「ApplicationSystem/400」及び「AS/400」はＩＢＭ社の商標である）。ゲートウェイ・コンピュータ９４６は、バス９４９を介して（データ・リポジトリ９４８のような）ストレージ・デバイスにも結合可能である。

ゲートウェイ・コンピュータ９４６がネットワーク９４２から地理的に大きく離れて設置されてもよいこと、同様に、ワークステーション９１０がネットワーク９４２及び９４４からかなり離れて設置されてもよいことは、当業者には明らかであろう。例えば、ネットワーク９４２はカリフォルニアに設置され、一方、ゲートウェイ・コンピュータ９４６はテキサスに設置され、１つ又は複数のワークステーション９１０はフロリダに設置されてもよい。ワークステーション９１０は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のようなネットワーク・プロトコルを使用して、携帯電話、無線周波数ネットワーク、衛星ネットワーク等のような多くの別の接続媒体を介して無線ネットワーク９４２に接続可能である。無線ネットワーク９４２は、ＴＣＰやユーザ・データグラム・プロトコル（ＵＤＰ）といったネットワーク接続９５０ａを、ＩＰ、Ｘ.２５、フレーム・リレー、統合サービス・ディジタル網（ＩＳＤＮ）、公衆交換電話網（ＰＳＴＮ）等のもとで使用してｍゲートウェイ・コンピュータ９４６に接続することが望ましい。別の方法として、ワークステーション９１０は、ダイヤル接続９５０ｂ又は９５０ｃを使用してゲートウェイ９４６に直接に接続されてもよい。更に、無線ネットワーク９４２及び９４４は、図１２に示された方法と同様の方法で、１つ又は複数の他のネットワーク（図示されていない）に接続されてもよい。

本発明を具体化するソフトウェア・プログラミング・コードは、一般に、図１１におけるワークステーション９１０のマイクロプロセッサ９１２及び／又はサーバ９４７によって、ＣＤ−ＲＯＭドライブ又はハード・ドライブのようなあるタイプの長期記憶媒体９３０からアクセスされる。そのソフトウェア・プログラミング・コードは、ディスケット、ハード・ドライブ、又はＣＤ−ＲＯＭのような、データ処理システムによる使用のための種々の知られている媒体において具現化可能である。ソフトウェア・プログラミング・コードは、そのような媒体によって配布されるか、または、１つのコンピュータ・システムのメモリ又はストレージからあるタイプのネットワークを介して他のコンピュータ・システムに配布可能である。別の方法として、そのプログラミング・コードは、メモリ９２８において具体化され、バス９１４を使用してマイクロプロセッサ９１２によりアクセス可能である。メモリにおけるソフトウェア・プログラミング・コードを物理的媒体上に具現化するために、及び／又は、ネットワークを介してソフトウェア・コードを配布するための、手法及び方法は周知であり、それに関する詳細な説明は本発明の理解にとって必要ないものと思われる。

上述のように、本発明は、たとえユーザのアクセス権及び機能的権利が幅広く変化しても、制御されるべきコンテンツの同じコピーをすべてのユーザ及び要求元プロセスが受け取ることを可能にする、という多くの利点を提供する。追加の利点として、機密のコンテンツまたはセンシティブなコンテンツの偶然又は故意の散逸による露見は、カプセル化されたルールによって執り行われる組込みアクセス制限及び機能的制限によって限定される。更に、従来技術では、一旦ユーザがコンテンツを成功裏に復号化すると、ユーザは一般に、そのコンテンツを平文形式で自由に配布する。その結果、そのコンテンツを持つことを許可されていない人がそれを受け取ることになるかもしれない。一方、本発明は、コンテンツをいつもそのセキュリティ・コンテナ及びそれに組み込まれたルールと共に配布することによってこの問題を回避している（なお、ユーザがそのユーザ以外に配布されてはならないコンテンツをコピーすることができないように、ルールが書かれることが望ましい）。本願において開示された手法は、（アクセス・ルール及び機能的ルールを変更することに加えて）セキュリティ・アルゴリズム、キー、及びキー長をあるセキュリティ・コンテナから他のセキュリティ・コンテナに、ドキュメントの集合体相互間のみならず、単一の複合ドキュメント内でも変更することを可能にし、従って、非常に融通性がありかつ強力なコンテンツ保護戦略を得ることが可能である。

従来技術として知られた手法では、「ディジタル権利管理（ＤＲＭ）」ファイル・フォーマットが映画、音声及びプレゼンテーション・ファイルを保護するために使用されており、それらは、あるデバイス上で、あるユーザによってのみ再生可能である。しかし、本願の発明者が知っている限り、及び信ずる限りでは、同じ制御されたオブジェクトをすべての受信者に配布する従来技術は知られていない。なお、その制御されたオブジェクトは、制御されるコンテンツのタイプに関係なく高レベル構成体の一部分であってもよく、その場合、配布されたオブジェクトは、好適な実施例のセキュリティ・コンテナとは関係なく、安全に組み込まれた独自のキー回復情報及びルールを保持している。

本発明の実施例を説明したが、一旦当業者が基本的な発明概念を知ると、これらの実施例における追加の変更及び修正を生じさせることが当業者には可能となる。従って、「特許請求の範囲」の記載は、好適な実施例とすべてのそのような変更及び修正とをそれらが本発明の趣旨及び範囲内に入るように含むものであると解釈されるべきである。

本発明の好適な実施例に従ってセキュリティ・コンテナの構成を高レベルで示す図である。本発明の好適な実施例に従ってセキュリティ・コンテナがドキュメント・コンポーネントに対するアクセスを制御する方法を高レベルで示す図である。好適な実施例において使用される「キー・クラス」構成体を示す図である。図３に示された構成体を使用する１つの例を示す図である。好適な実施例のキー・クラスの一部分を形成する「キー・エレメント」の構成体を示す図である。図５の構成体とは別の構成体を示す図である。図５に示された構成体を使用するキー・エレメントの一例を示す図である。好適な実施例を説明するときに使用される従業員レコードのサンプルを示す図である。未だ認証されていないユーザ又はプロセスにセキュリティ・コンテナが情報を表示する方法を概念的に示す図である。本発明の好適な実施例を実装するために使用可能なロジックを示すフローチャートである。本発明を実施し得るコンピュータ・ハードウェア環境のブロック図である。本発明を実施し得るネットワーク・コンピューティング環境を示す図である。

Claims

ドキュメント・コンポーネントを保護するセキュリティ・コンテナであって、前記ドキュメント・コンポーネントと、前記ドキュメント・コンポーネントにおける動作を制御するための条件付きロジックと、前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報と、を前記セキュリティ・コンテナ内にカプセル化することによって前記ドキュメント・コンポーネントを保護するセキュリティ・コンテナ。
前記セキュリティ・コンテナが高レベル・ドキュメントの部分を保護する、請求項１に記載のセキュリティ・コンテナ。
前記高レベルドキュメントが、セキュリティ・コンテナによって複数の部分を保護される、請求項２に記載のセキュリティ・コンテナ。
セキュリティ・コンテナを使用してドキュメント・コンテンツを保護する方法であって、ドキュメント・コンポーネントと、前記ドキュメント・コンポーネントにおける動作を制御するための条件付きロジックと、前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報と、を前記セキュリティ・コンテナ内にカプセル化するステップ、を含む方法。
前記キー配布情報が、前記ドキュメント・コンポーネントをアクセスする権限を与えられた１つ又は複数のユーザ及び／又はプロセスの識別情報を更に含む、請求項４に記載の方法。
前記キー配布情報が、前記セキュリティ・コンテナ内にカプセル化された前記ドキュメント・コンポーネントと前記条件付きロジックの両方、を暗号化した対称キーを更に含み、前記対称キーが、前記権限を与えられたユーザ及び／又はプロセスによる復号化のために暗号化形式で格納される、請求項５に記載の方法。
前記対称キーの前記暗号化形式が、別個の各ユーザ、プロセス、ユーザのグループ、又はプロセスのグループに対する前記対称キーの別バージョンを含み、前記別バージョンが、対応する別個のユーザ、プロセス、ユーザのグループ、又はプロセスのグループと関連した公開キーでもって暗号化されている、請求項６に記載の方法。
前記権限を与えられたユーザ及び／又は前記権限を与えられたプロセスが個々に又はグループとして指定される、請求項５に記載の方法。
前記条件付きロジックが更に、前記ドキュメント・コンポーネントに対するアクセスを制御する、請求項４に記載の方法。
前記キー配布情報が更に、前記条件付きロジックに対するアクセスを制御する、請求項９に記載の方法。
前記ドキュメント・コンポーネント及び前記条件付きロジックが、前記セキュリティ・コンテナ内におけるカプセル化の前に暗号化される、請求項４に記載の方法。
前記セキュリティ・コンテナが、構造化ドキュメント・フォーマットでエンコードされる、請求項４に記載の方法。
前記構造化ドキュメント・フォーマットが拡張可能マークアップ言語（ＸＭＬ）フォーマットである、請求項１２に記載の方法。
前記１つ又は複数のユーザ及び／又はプロセスの前記識別情報が少なくとも１つのグループの識別情報を含み、前記グループが１つ又は複数のユーザ及び／又はプロセスをメンバとして有する、請求項５に記載の方法。
前記ドキュメント・コンポーネントにアクセスするための要求を受け取ったときに、前記メンバが動的に決定される、請求項１４に記載の方法。
前記動的な決定が、前記グループの前記メンバを識別することが行われるリポジトリ、をアクセスすることを更に含む、請求項１５に記載の方法。
前記ドキュメント・コンポーネントをアクセスするための要求を要求者から受け取るステップと、
前記要求者が前記ドキュメント・コンポーネントをアクセスする権限を与えられているかどうかを、前記キー配布情報を使用してプログラム的に決定するステップと、
前記プログラム的に決定するステップが肯定的な結果を有するとき、条件付きロジックを使用して、前記要求が許可されるかどうかをプログラム的に評価し、前記プログラム的に決定するステップが否定的な結果を有するとき、前記要求を拒否するステップと、
を更に含む、請求項４に記載の方法。
前記条件付きロジックが、前記要求者の身元識別情報、前記要求者によって使用されるデバイス、前記要求者のコンテキスト、前記要求者によって使用されるアプリケーションのゾーン、前記要求者のユーザ・プロファイル、及び前記要求者のターゲット宛先、のうちの少なくとも１つを評価する、請求項１７に記載の方法。
１つ又は複数のコンピュータ可読媒体に組み込まれ、セキュリティ・コンテナを使用してドキュメント・コンテンツを保護するための、コンピュータ・プログラムであって、
ドキュメント・コンテンツをアクセスするための要求を要求者から受け取るためのコンピュータ可読プログラム・コード手段であって、前記ドキュメント・コンテンツが、ドキュメント・コンポーネントにおける動作を制御するための条件付きロジック、及び前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報、と共にセキュリティ・コンテナ内に前記ドキュメント・コンポーネントとしてカプセル化される、コンピュータ可読プログラム・コード手段と、
前記要求者が前記ドキュメント・コンポーネントをアクセスする権限を与えられているかどうかを、前記キー配布情報を使用してプログラム的に決定するためのコンピュータ可読プログラム・コード手段と、
前記プログラム的に決定するためのコンピュータ可読プログラム・コード手段の動作が肯定的な結果を生じるときは、前記条件付きロジックを使用して、前記要求が許可され得るかどうかをプログラム的に評価するための、また、前記プログラム的に決定するためのコンピュータ可読プログラム・コード手段が否定的な結果を生じるときは、前記要求を拒否するための、コンピュータ可読プログラム・コード手段と、
を含む、コンピュータ・プログラム。
セキュリティ・コンテナを使用してドキュメント・コンテンツを保護するためのシステムであって、
ドキュメント・コンポーネント、前記ドキュメント・コンポーネントにおける動作を制御するための条件付きロジック、及び前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報、をカプセル化するセキュリティ・コンテナと、
前記ドキュメント・コンポーネントをアクセスするための要求を要求者から受け取るための手段と、
前記要求者が前記ドキュメント・コンポーネントをアクセスする権限を与えられているかどうかを、前記キー配布情報を使用してプログラム的に決定するための手段と、
前記プログラム的に決定するための手段の動作が肯定的な結果を生じるときは、前記条件付きロジックを使用して、前記要求が許可され得るかどうかをプログラム的に評価するための、また、前記プログラム的に決定するための手段の動作が否定的な結果を生じるときは、前記要求を拒否するための、手段と、
を含むシステム。
前記セキュリティ・コンテナがドキュメント内に組み込まれる、請求項２０に記載のシステム。
前記セキュリティ・コンテナがシステム・クリップボード上で前記ドキュメント・コンポーネントをカプセル化する、請求項２０に記載のシステム。
前記セキュリティ・コンテナがユーザ・インターフェース上に配置される、請求項２０に記載のシステム。
前記セキュリティ・コンテナが、プロセス間通信を使用して前記ドキュメント・コンポーネントを交換のためにカプセル化する、請求項２０に記載のシステム。
前記セキュリティ・コンテナが、メッセージング・システムを使用して前記ドキュメント・コンポーネントを交換のためにカプセル化する、請求項２０に記載のシステム。
前記ドキュメント・コンポーネントをターゲット宛先にコピーするための手段を更に含み、前記コピーするための手段が、前記ドキュメント・コンポーネントをコピーするために前記セキュリティ・コンテナ全体をコピーする、請求項２０に記載のシステム。
セキュリティ・コンテナを使用してドキュメント・コンテンツを保護するための方法であって、
ドキュメント・コンテンツをアクセスするための要求を要求者から受け取るステップであって、前記ドキュメント・コンテンツが、ドキュメント・コンポーネントにおける動作を制御するための条件付きロジック及び前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報、と共にセキュリティ・コンテナ内に前記ドキュメント・コンポーネントとしてカプセル化される、ステップと、
前記要求者が前記ドキュメント・コンポーネントをアクセスする権限を与えられているかどうかを、前記キー配布情報を使用してプログラム的に決定するステップと、
前記プログラム的に決定するステップが肯定的な結果を有するときは、前記条件付きロジックを使用して、前記要求が許可され得るかどうかをプログラム的に評価し、また、前記プログラム的に決定するステップが否定的な結果を有するときは、前記要求を拒否する、ステップと
前記受け取るステップ、プログラム的に決定するステップ、及びプログラム的に評価するステップのうちの１つ又は複数を実行するための料金を課するステップと、
を含む方法。
セキュリティ・コンテナを使用してドキュメント・コンテンツを保護するための方法であって、
ドキュメント・コンテンツをアクセスするための要求を要求者から受け取るステップであって、前記ドキュメント・コンテンツが、ドキュメント・コンポーネントにおける動作を制御するための条件付きロジック及び前記ドキュメント・コンポーネントに対するアクセスを制御するために使用可能なキー配布情報、と共にセキュリティ・コンテナ内に前記ドキュメント・コンポーネントとしてカプセル化される、ステップと、
前記要求者が前記ドキュメント・コンポーネントをアクセスする権限を与えられているかどうかを、前記キー配布情報を使用してプログラム的に決定するステップと、
前記プログラム的に決定するステップが肯定的な結果を有するときは、前記条件付きロジックを使用して、前記要求が許可され得るかどうかをプログラム的に評価し、また、前記プログラム的に決定するステップが否定的な結果を有するときは、前記要求を拒否する、ステップと、
前記プログラム的に評価するステップが、前記要求が許可され得ると決定するとき、前記要求者に料金を課するステップと、
を含む方法。