安全なコラボレーティブ・トランザクションを管理する方法及び装置
【課題】異なるセキュリティ・レベルを提供してユーザが自分自身の通信のセキュリティ・レベルを決定できるようにする。
【解決手段】ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。他にも、セキュリティ関係のオーバヘッドの増加を伴うもののもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用できるようにする。
【解決手段】ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。他にも、セキュリティ関係のオーバヘッドの増加を伴うもののもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用できるようにする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は安全なデータ交換トランザクションを提供するための方法及び装置に関連し、更に詳しくは、共同作業環境（以下、コラボレーティブ環境）における安全なデータ交換トランザクションを提供する方法及び装置に関する。
【背景技術】
【０００２】
現在の計算機アプリケーションはほとんどがシングル・ユーザ・システムである。例えば、従来の編集アプリケーションでは、一人のユーザがファイルを開き内容に変更を加えることができる。第１のユーザがファイルを開いている間に、第２のユーザがそのファイルを開こうとすると、第２のユーザはファイルを開くことができないか変更を加えることができないことになる。第２のユーザはファイルの一時的なコピー（以下、スナップショット・コピー）を取得することができる場合がある。しかしスナップショット・コピーは第１のユーザが作成したオリジナルのコピーに加えたそれ以降の変更は何も更新されない。つまり、第２のユーザはファイルの変更として表現された第１のユーザのアイデアを共有することができない。更に、第２のユーザはオリジナルのファイル内容の変更を行なうことができないので、ファイルの変更として表現されるそのユーザのアイデアを共有することができない。要するに、第１と第２のユーザはファイルの共同作業による（以下、コラボレーティブな）編集ができない。
【０００３】
本明細書で用いている術語であるコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）は複数クライアントがアイデアを共有できるようにする能力を意味する。この共有には一人のアイデアを他のメンバーに対して自動的に表明し、他のメンバーがそのアイデアを明示的に要求しなくても良いようにする能力を含む。コラボレーションは更にアイデアを送信するメンバーからのアイデアを自動的にそれぞれのメンバーが受信できるようにする能力も含む。つまり、最低限、コラボレーションは共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｅｆｆｏｒｔ）に参加しているメンバーの間での通信を意味する。この通信／コラボレーションは多くのモデルをもとにすることができる。「ブレーン・ストーミング型」セッションは制約されないコラボレーション・モデルである。一方、「ラウンド・ロビン」型モデルはそれぞれのメンバーがアイデアを表明するのに特定の順番を待つもので、制約型のコラボレーション・モデルである。
【０００４】
特許文献１に開示された一つのコラボレーション・システムでは、データ変更要求がユーザとの対話に対する応答として生成されすべてのコラボレータに接続されているトランスポンダ・ユニットへ送出される。トランスポンダはコラボレーションに参加しているユーザ全部に対してデータ変更要求をブロードキャストする。各ユーザはコラボレーション用データ（以下、コラボレーティブ・データ）のローカルなコピーを持ち、データ変更要求を受信してローカルなデータ・コピーへ要求された変更を加えるメカニズムを備える。すべてのデータ変更要求がトランスポンダを経由しなければならないため、データ変更要求はすべて同じ順番でそれぞれのコラボレータに受信されることになり、データの完全性が維持される。
【０００５】
コラボレーションは１台の計算機またはサーバで作業しているユーザ間でローカルに行なわれたり、ユーザそれぞれがネットワークに接続された計算機に向かっているようなネットワーク上で行なわれることもある。インターネットはこのようなネットワークの一つで、数百万のユーザ間での通信及び対話のためのダイナミックな公衆環境を作り出した。ビジネスにおいて、インターネットまた特にインターネット上で動作するワールドワイドウェブ・アプリケーションはベンダ／メーカ間、メーカ／ディストリビュータ間、ディストリビュータ／顧客間、その他の関係を再編成した。インターネット技術を企業内の機密ネットワークへ拡張すると、「イントラネット」あるいは「プライベート・インターネット」と呼ばれるようなものが、企業のディレクトリとネットワーク基盤を使用する従業員それぞれや作業グループの間で、新しい形態のドキュメント及び情報の共有を可能にした。
【０００６】
ワールド・ワイド・ウェブ（「ウェブ」）はその中核にサーバ・クライアント・アーキテクチャを有し個々のクライアント（すなわちウェブ・コンテンツのユーザ）はブラウザを通して、公衆ネットワーク上にあるサーバ（すなわち、インターネット・コンテンツ・プロバイダ）とインタフェースすることで、ウェブ・サイトからドキュメントを取得する。ブラウザはパーソナル・コンピュータがインターネット・ドキュメントを要求し、受信し（例えばダウンロードし）、解釈し、表示し、また一般的にはインターネットをナビゲーションできるようにするソフトウェア・プログラムである。ウェブ・サイトはドキュメントの集合体で、ドキュメントは一般にホームページやこれに関連しリンクされるドキュメントから構成され、クライアントからは離れたサーバ上に配置される。ドキュメントはコンパウンド・ドキュメントとすることができ、データ、グラフィックス、ビデオ、サウンド、及び／または他の種類のメディアや、他のドキュメントへのリンクも含められる。
【０００７】
基盤となるウェブ及びその他のインターネット技術は、パーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロトコル、インフラストラクチャの取り決め（例えば一元的資源指定子Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ ＬｏｃａｔｏｒまたはＵＲＬ）を含め、標準化が進んでいる。ＵＲＬはＷＷＷ上のすべてのドキュメント・オブジェクトについて所在アドレスを提供する。ＵＲＬはドキュメント・オブジェクトを択一的に指定しインターネット・プロトコルを使用するアクセス・アルゴリズムも定義することが多い。
【０００８】
インターネットを利用するため、インターネット・プロトコルに準拠した形でツールや資源が開発されており、これには電子メール（ｅ−ｍａｉｌ）などのアプリケーションを含む。電子メールは電子的な郵便で、これを用いてドキュメントを電子的に、選択したアドレスで送受信する。インターネット上での対話（ｉｎｔｅｒａｃｔｉｏｎ）のほとんどが「ドキュメント送受信」モデルに従う電子メールやその他のブラウザを使うメディアであると予想された。おそらくはそのモデルのため、ユーザは高次の権威者による介入なしに個人が他の個人の提供した文書にアクセスすることでインターネットを本質的に「ピアツーピア」であると見なすことが多い。
【０００９】
結果として、更に「ピアツーピア」的に動作する新しいコラボレーション・モデルが開発された。これらのモデルは「テレスペース」と呼ばれる共有プライベート空間にいるユーザ間の直接接続の上に構築される。各ユーザは「アクティビティ」と呼ばれるプログラムを持ち、これはパーソナル・コンピュータ・システムや、通信機器またはその他のネットワーク接続可能な装置で動作可能である。アクティビティ・プログラムは「デルタ」と呼ばれるデータ交換要求を生成することでユーザとの対話に応答する。アクティビティはまたデータ変更エンジンを備え、これがローカルなデータ・コピーを維持しており、デルタによって要求されたデータへの変更を実行する。デルタはダイナミクス・マネージャによって一人のユーザから別のユーザへと配布される。後者の形式のコラボレーション・システムは「通信マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ， Ｋｅｎｎｅｔｈ Ｇ． Ｍｏｏｒｅ， Ｒｏｂｅｒｔ Ｈ． Ｍｙｈｉｌｌ ａｎｄ Ｂｒｉａｎ Ｍ． Ｌａｍｂｅｒｔによる１９９９年７月１９日付け出願の特許文献２、「ダイナミクス・マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｄｙｎａｍｉｃｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ． Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け出願の特許文献３、「アクティビティ・ベースのコラボレーション用に装備した分散コンピュータ・システムにおいてデータ変更要求に優先順位をつけデータ完全性を維持するための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｐｒｉｏｒｉｔｉｚｉｎｇ ｄａｔａ ｃｈａｎｇｅ ｒｅｑｕｅｓｔｓ ａｎｄ ｍａｉｎｔａｉｎｉｎｇ ｄａｔｅ ｃｏｎｓｉｓｔｅｎｃｙ ｉｎ ａ ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け出願の特許文献４に詳細に記載されている。
【００１０】
インターネットは、ユーザに娯楽と有用な通信方法を提供する点でダイナミックかつフレキシブルだが、ユーザのニーズ全部には適合しない。例えば、インターネットは各種のハードウェアとソフトウェアで広範囲のユーザを接続する能力を有することから理想的にはコラボレーションに適したものであろう。しかし、インターネットのセキュリティは希望するのとは程遠い。インターネット上で様々な人数のユーザへメッセージを送信できるが、これらのメッセージは代表的にはサード・パーティのウェブ・サイトを経由しここで通信を傍受したり機密性を侵害することが可能である。結果として、ユーザがインターネット経由でいっそう対話する一方、例えば複数媒体（電話、ファクシミリ、ホワイトボード）や、複数時刻（リアルタイム、翌日配達郵便（ｏｖｅｒｎｉｇｈｔ ｍａｉｌ））及びその他の通信告知手段など従来の安全な方法でインターネット「以外で」対話を続けることになる。
【００１１】
共有プライベート空間にいる個人間及び中小グループ間でコラボレーティブな通信やその他の共有及び同時的アクティビティを安全なものにするようにインターネットを拡張するのが望ましい。このような対話は参加者のパーソナル・コンピュータ間またはその他のネットワーク接続可能な装置間で望ましくは瞬間的、直接的、かつ機密に行なわれるべきである。また様々なリモートサイトにいるユーザが安全に通信でき、安全な通信リンクの構築やセキュリティ・システムの維持にユーザの広範囲の関与を必要としないような技術を提供するのも望ましい。また安全なトランザクションを提供する上で関係する「オーバヘッド」を最小限にまで減らして通信量（以下、スループット）と動作速度を改善するのも望ましい。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許第５，７８１，７３２号明細書
【特許文献２】米国特許第６，６４０，２４１号明細書
【特許文献３】米国特許第６，４４６，１１３号明細書
【特許文献４】米国特許第６，８５９，８２１号明細書
【発明の概要】
【００１３】
本発明の図示した実施態様の一つによれば、異なるセキュリティ・レベルを提供してユーザが彼ら自身の通信のセキュリティ・レベルを決定できるようにする。ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。これ以外に、セキュリティ関係のオーバヘッドの増加をもたらすもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。
【００１４】
好適実施態様において、鍵管理のオーバヘッドを減少させるため、同一の物理鍵を暗号化鍵とメッセージ認証鍵に使用する。
【００１５】
一つの実施態様において、セキュリティ・レベルはテレスペースが作成されてテレスペースの寿命がある間は固定されたままである。テレスペースでは、セキュリティ・レベルは全くセキュリティがない状態からテレスペースのメンバーと部外者との間のセキュリティ、更にテレスペースのメンバーのペア間でのセキュリティまで範囲がある。
【００１６】
別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用する。
【００１７】
更に別の実施態様において、中程度または高度なセキュリティ・レベルを有するテレスペースのメンバーはウィスパー（ｗｈｉｓｐｅｒｓ）と呼ばれテレスペースの他のメンバーに対しても機密化される機密通信で通信することができる。
【図面の簡単な説明】
【００１８】
【図１】図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図である。
【図２】図２、はデルタを用いてローカルなデータ・コピーを更新する代表的なコラボレーション・システムの略ブロック図である。
【図３】図３は、グループ、トライブ、またそれらを保護するために使用される暗号化及び認証鍵を示す略ブロック図である。
【図４】図４は、低レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図５】図５は、認証／完全性モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図６】図６は、認証／完全性／機密モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図７】図７は、認証／完全性モードで動作する高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図８】図８は、デジタル署名と証明書の作成及び確認を示す略ブロック図である。
【図９】図９は、既存のグループへの新規メンバー（招待者）の追加を示す略ブロック図である。
【図１０】図１０は、既存のグループへ新規メンバーを追加するために議長（ｃｈａｉｒ）を使用するような代表的ルーチンのステップを示すフローチャートである。
【図１１】図１１は、議長から招待者へ送信される招待メッセージの内容を示す略図である。
【図１２】図１２は、招待者から議長へ送信される受け入れメッセージの内容を示す略図である。
【図１３】図１３は、グループの既存のメンバー全員へ議長から送信されて新規メンバーが追加されたことを告知する新規メンバー追加デルタの内容を示す略図である。
【図１４】図１４は、議長から新規に追加されたメンバーへ送信されてテレスペース・データのメンバーを告知するメッセージの内容を示す略図である。
【図１５】図１５は、招待者が招待に応答するために使用できる代表的ルーチンのステップを示すフローチャートである。
【図１６】図１６は、招待者からの受け入れメッセージに応答するために議長が使用できる代表的ルーチンのステップを示すフローチャートである。
【図１７】図１７は、新規メンバー追加デルタに応答するために既存のメンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１８】図１８は、テレスペース情報を搬送する議長からのメッセージに応答するために新規追加メンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１９】図１９は、再キーイング情報が「ピギーバック」したデルタ・メッセージの内容を示す略図である。
【図２０】図２０は、本発明のセキュリティ・システムの好適な実装の全体的アーキテクチャを示す略ブロック図である。
【図２１】図２１は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル抽象クラスを示す略ブロック図である。
【図２２】図２２は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル具象クラスを示す略ブロック図である。
【図２３】図２３は、視覚的確認のための情報を表示しその情報を受け入れるかまたは破棄するようにユーザに要求するダイアログ・ボックスの画面表示を示す略図である。
【発明を実施するための形態】
【００１９】
図１は代表的なコンピュータ・システム１００の従来のシステム・アーキテクチャを示したもので、これに開示された本発明を実装することができる。ただし図１の代表的なコンピュータ・システムは説明目的のみで議論するもので本発明の制限と見なすべきではない。以下の説明では特定のコンピュータ・システムを記述する際に共通に使用される術語を参照することがあるが、記載される概念は図１に図示したものとは異なるアーキテクチャを有するシステムを含めた他のコンピュータ・システムに等しく適用される。
【００２０】
コンピュータ・システム１００は従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報記憶のためのランダムアクセス・メモリ（ＲＡＭ）１１０、及び永久的情報記憶のためのリードオンリー・メモリ（ＲＯＭ）を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５はバス１３０を制御するために設けてあり、割り込みコントローラ１３５は他のシステム要素からの各種割り込み信号を受信し処理するために使用される。
【００２１】
大容量記憶はディスケット１４２、ＣＤＲＯＭ１４７、またはハードディスク１５２によって提供される。データとソフトウェアは取り出し可能な媒体例えばディスケット１４２やＣＤＲＯＭ１４７を介してクライアント・コンピュータ１００と交換できる。ディスケット１４２はディスケット・ドライブ１４１へ挿入でき、このディスケット・ドライブ１４１はコントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤＲＯＭ１４７はＣＤＲＯＭドライブ１４６へ挿入でき、ＣＤＲＯＭドライブ１４６はコントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は固定ディスク・ドライブ１５１の一部であり、これはコントローラ１５０を介してバス１３０へ接続されている。
【００２２】
コンピュータ・システム１００へのユーザ入力は様々な装置から提供される。例えば、キーボード１５６とマウス１５７はキーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６はマイクロホンとスピーカの両方として機能するもので、オーディオ・コントローラ１９７によってバス１３０へ接続されている。その他の入力装置例えばペン及び／またはタブレットや音声入力用マイクロホンなどがバス１３０と適当なコントローラを介してクライアント・コンピュータ１００へ接続できることは当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリ・アクセスを実行するために提供される。視覚表示はビデオ・ディスプレイ１７０を制御するビデオ・コントローラ１６５によって生成される。
【００２３】
コンピュータ・システム１００はクライアント・コンピュータ１００をバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用する。
【００２４】
コンピュータ・システム１００は一般にオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。
【００２５】
図２は略ブロック図の形で代表的なコラボレーション・システムの構成を示す。図２はネットワーク２１６へ接続された２台のコラボレーティブ・ワークステーション２００、２０２を示す。ワークステーション２００、２０２のそれぞれは図１に示したようなコンピュータ・システムとすることができ、ネットワーク２１６はプライベート・コンピュータ・ネットワーク例えばＬＡＮやＷＡＮ、あるいは公衆コンピュータ・ネットワーク例えばインターネットとすることができる。これ以外に、ワークステーション２００、２０２は同一のコンピュータ（図示していない）上に構成することができ、この場合２つの端末間の通信はそのコンピュータに対してローカルなものとなる。
【００２６】
好適実施態様において、端末２００、２０２のそれぞれは共同作業を実行するデータのローカルなコピー２０４、２１０をそれぞれ保持している。それぞれのローカルなデータ・コピー、例えばデータ・コピー２０４はこれに対応する「ダイナミクス・マネージャ」２０６と呼ばれるソフトウェア・プログラムによって管理される。同様に、データ・コピー２１０はこれに対応するダイナミクス・マネージャ２１２によって管理される。特定のコラボレーション装置を説明の目的で議論するが、他のコラボレーション装置も精神と範囲において本発明の原理から逸脱することなく使用できることが当業者には明らかであろう。
【００２７】
ダイナミクス・マネージャ２０６は「デルタ」と呼ばれる一つまたはそれ以上のデータ変更要求を含む自己内包型データユニットの受信に応答してこれのローカル・データ・コピー２０４を変更し更新する。データ変更要求はデータの希望通の変更に関してダイナミクス・マネージャやその他のコンポーネント（図示していない）への通知または催促である。デルタは例えばマネージャ２０６などのダイナミクス・マネージャによって、ユーザとの対話に応答して作成されるもので、対応するローカル・データ・コピー２０４と、ネットワーク越しに同じコラボレーティブ・セッションに参加しているコラボレータに属する他のコンピュータ上のローカル・データ・コピーとの両方を更新するために用いられる。
【００２８】
デルタは制御情報を提供するへッダ部分と要求が関係するデータについての情報を提供するペイロード部分とを含む特定のフォーマットを有する。個々のデルタは一つまたはそれ以上のペイロードを有することができる。多数のペイロードが使用されるような場合、以下で詳細に説明するように、それぞれが独自の装置機能またはユーザの役割を有する特定のコラボレーション・メンバーを対象とすることができる。
【００２９】
ダイナミクス・マネージャ２０６によって生成されたデルタが他のコラボレータに送信される場合、ダイナミクス・マネージャ２０６は通信マネージャ２０８と相互作用する。同様に、ダイナミクス・マネージャ２１２は通信マネージャ２１４と相互作用する。通信マネージャ２０８は内向きと外向きのデルタを適当な宛先へ配送するメカニズムである。好適実施態様において、通信マネージャはコンピュータで実行可能なプログラムとして実装することができ、このプログラムが別のリモート・パーソナルコンピュータまたは別の形のネットワーク接続可能な装置へネットワーク２１６上で送信するため通信マネージャ２０６によって開始されたデルタを配送し、またネットワーク２１６上で受信したリモートで生成されたデルタをダイナミクス・マネージャ２０６へ配送する。
【００３０】
一般に、通信マネージャ２０８、２１４はダイナミクス・マネージャ２０６、２１２によって生成された全デルタがコラボレーションに参加している全ユーザによって受信されるように構成される。それぞれのデルタは内部シーケンス番号を含みそれぞれのコラボレータのダイナミクス・マネージャは全部のデルタがいつ受信されたかを決定できるようにしてある。別のコラボレータからのデルタはそれぞれのコラボレータへ多数の違う経路を通って送信されることがあるので、デルタは生成された順序と同じ順序で到着するとは限らない。しかし、それぞれのコラボレータによって全デルタが受信され内部シーケンス番号を使って正しい順序でデルタを適用できる。したがって、それぞれのコラボレータによって保持されているローカル・データ・コピーは、全部のデルタで更新されると、コラボレーションの他のメンバーによって保持されているローカル・データ・コピーと一致することになる。
【００３１】
特定のコラボレーションに参加しているコラボレータの間での機密性を維持することが望ましい。これはデルタが公衆ネットワーク例えばインターネット上に送信される場合にとくに言えることである。情報のセキュリティにとって重要な３つの基本概念が存在する。その第１は認証で、これはデータ受信者がデータ作成者（ｄａｔａ ｓｏｕｒｃｅ）の同一性を知っており信用できることを保証するものである。第２は完全性で、データが転送中に変更されなかったことを保証するものである。完全性はデータ作成者以外のものによってデータを書き込むことができないことまた既知の作成者から到着したものであることを実効的に保証する。データ完全性は不正なデータの生成または「なりすまし」による第三者からの攻撃を防止する。最後のセキュリティ概念は機密性で、これは転送中のデータがデータ作成者とデータ受信者以外の第三者によって読み取ることができないことを保証するものである。機密性は第三者によるデータの読み取りまたは「盗聴」による攻撃を防止する。
【００３２】
前述したように、セキュリティはコラボレータが一つまたはそれ以上のアクティビティに参加して項目を共有したり、アクティビティの結果がユーザのパーソナル・コンピュータ上にあるいは他の形のネットワーク接続可能な装置上に永続的に保存されるような仮想空間に基づいている。仮想空間は「テレスペース」または「グループ」と呼ばれるもので各ユーザの装置の中で同期が保たれる。図示したセキュリティ／モデルによると、テレスペースのセキュリティは、テレスペースを形成して、メンバーを受け入れ、更にメンバーシップが安定したあとで「全体の」セキュリティとしてほとんどのユーザが体験するものである。これは安定状態デルタ・プロトコルと呼ばれグループ・メンバー間に渡されるデルタに含まれる情報の認証、完全性及び機密性に関連する。図３は５人のメンバーＭ０、Ｍ１、Ｍ２、Ｍ３、Ｍ４（３０２〜３１０）からなるテレスペースまたはグループ例３００の模式図である。各テレスペース３００内には一つまたはそれ以上のトライブまたはサブグループが存在する。図３には、３人のメンバーＭ２、Ｍ３、Ｍ４（３０６、３０８、３１０）からなるトライブ３１２が図示してある。
【００３３】
各メンバー３０２〜３１０はその内部に「プロトコル・エンジン」（それぞれエンジン３０３〜３１１）を有し、これは他のメンバーへセキュリティ・メッセージを送信しセキュリティ情報を操作するアプリケーション・プログラムである。
【００３４】
テレスペース３００とトライブ３１２において情報は一つまたはそれ以上の鍵により保護される。これは、Ｋとして示してある暗号化鍵と、Ｌで示したメッセージ認証／完全性コード（ＭＡＣ）鍵である。Ｋ及びＬ鍵は対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｉｐｈｅｒ）用の従来の鍵でありテレスペース全体への広がり（スコープ）を有する。本発明のシステムはブロック暗号化（ｂｌｏｃｋ ｃｉｐｈｅｒｓ）とストリーム暗号化（ｓｔｒｅａｍ ｃｉｐｈｅｒｓ）の両方を用いることができるが、メッセージ間での状態は維持されない。つまり一つのメッセージから次のメッセージへセキュリティ暗号ストリーム状態を維持するためには通信しているエンドポイントが必要とされない。この方法では、一時的な通信の中断が発生した場合にも再同期が必要とされない。
【００３５】
ブロック暗号化はカウンター・モードにおいて使用する度に必ず新しく無作為生成される初期化ベクトルを使って使用される。初期化ベクトルは暗号のブロック長と等しい長さを有し従来の方法による典型的なへッダ攻撃を妨害（ｔｈｗａｒｔ）するために使用する。ストリーム暗号化はブロック・モードにおいて初期ベクトルと鍵を組み合わせる、例えば排他的論理和演算により、ついですべてのメッセージで鍵文字列を再初期化することで使用される。この場合、初期ベクトルは鍵長と等しい長さを有する。初期ベクトルは一般に機密性保護されないしまたは認証／完全性の保護もされない。
【００３６】
更にすべての鍵がなんらかの種類の陳腐化メカニズム例えばタイムアウトを関連させるか一定数のメッセージまたはバイト数を保護すると想定する。このメカニズムはテレスペースによって決定されるローカル・ポリシーの一種で以下で説明するいずれのプロトコルでも送信する必要はない。
【００３７】
ＫＧ／ＬＧで示したグループ鍵は（それぞれ）暗号化／ＭＡＣ鍵で、グループ３００の全メンバーによって共有される。これらの鍵は第三者（グループ外の者）による攻撃からデルタに含まれる情報の機密性／完全性をそれぞれ保護するために使用される。同様に、ＫＴ／ＬＴで示したトライブ鍵は暗号化／ＭＡＣ鍵で、トライブ３１２の全メンバーによって共有される。これらの鍵はトライブ以外のグループ・メンバーや第三者による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。
【００３８】
更にＫ０１／Ｌ０１で示してある対になった鍵はメンバーＭ１とＭ２が共有しかつ他のグループ・メンバーの誰も共有していない暗号化／ＭＡＣ鍵（それぞれ）Ｍ０とＭ１で、Ｍ０とＭ１の間で双方向に通信を保護するために使用される双方向鍵である。これらの鍵はグループ・メンバーＭ２、Ｍ３、Ｍ４による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。同様に対になった鍵Ｋｉｊ／Ｌｉｊは別のメンバーの組み合わせＭｉとＭｊの間で交換される情報を他のグループ・メンバーによる攻撃から保護するために使用される。
【００３９】
テレスペース内で安定状態セキュリティは５段階のレベルの一つに組み込まれることになるが、そのレベルはテレスペース３００の作成者がテレスペースを作成する時点で選択できる。５レベルには何らの鍵も使用する必要がない低レベル・セキュリティを含む。このレベルは全く暗号セキュリティを提供しない。次のレベルは１対の鍵（ＫＧ／ＬＧ）をグループの全メンバーに対して使用する中程度レベルのセキュリティである。このレベルでは、ＫＧ／ＬＧ鍵のうちのＭＡＣ鍵ＬＧだけを使ってデルタを保護することにより認証／完全性が提供できる。同様に、認証／完全性及び機密性はＫＧ／ＬＧ鍵の両方を使ってデルタを保護することで提供できる。
【００４０】
次のレベルは高レベルのセキュリティで、グループ鍵ＫＧ／ＬＧと鍵ペアＫｉｊ／Ｌｉｊの組み合わせを使用する。認証／完全性だけが要求される場合にはＭＡＣ鍵のペア（Ｌｉｊ）だけを使用してデルタを保護し、グループ鍵（ＫＧ）は使用しない。これ以外に、認証／完全性／機密性が要求される場合にはグループ暗号化鍵ＫＧとＭＡＣ鍵ペアＬｉｊを使用してデルタを保護する。
【００４１】
中レベルと高レベルのセキュリティ・レベル双方で、暗号化鍵（Ｋｉｊ）とＭＡＣ鍵（Ｌｉｊ）のペアを使用してグループ鍵またはトライブ鍵（ＫＧ／ＬＧまたはＫＴ／ＬＴ）の再キーイングを行なう。
【００４２】
以上のレベルやモードはグループ（テレスペース）全体に適用可能であり、また全トライブ（サブグループ）にも同様に適用可能である。テレスペース内のトライブ全部がテレスペース自体と同一の「全体的セキュリティ」を有するので、グループに対して前述したレベルやモードは、前記のグループ鍵ＫＧ／ＬＧをトライブ鍵ＫＴ／ＬＴで置き換えればトライブに適用できる。
【００４３】
図４はグループ・メンバー間に情報を転送するのに使用する「デルタ」の内容を示す。各デルタはメッセージ・へッダ４００からなり、これにはセキュリティ・システムの特定の実装に依存する情報を含む。この情報にはプロトコルのバージョン番号を含められるので、ここにコラボレーション・システムとセキュリティ・サブシステム両方のバージョン番号を含められる。メッセージ・へッダ４００はメッセージ・フラグ種別またはタグＩＤも含み、これはメッセージの種類が異なるごとに異なる識別子である。メッセージ・へッダに含めることができる他の情報としては、構造化シーケンス番号がある。この番号はテレスペースのスコープを有する部分順列シーケンス番号で、そのスコープ内でメッセージの送信者とメッセージそれ自体の特定インスタンスとを論理的に同定する。
【００４４】
へッダ４００は機密を保護することができないが要求されるセキュリティ・レベルによっては実際にグループ・メンバー間に送出されるペイロードまたは情報を含むアプリケーション・データ４０２と全く同様に認証／完全性を保護する必要がある場合がある。例えば図４に図示してあるようなデルタが符号化される方法は希望するセキュリティ・レベルによって変化する。例えば、暗号としての意味でセキュリティを何も保証しない「低レベル」セキュリティ・モードでは、デルタは図４に図示したように送信され、へッダ情報４００がペイロード４０２よりも先に送信されるのが望ましいが、へッダとペイロードの順序は本発明の動作にとって重要ではない。この場合、第三者（非グループ・メンバー）がデルタ情報４０２を読み取るまたは盗聴でき、またデルタを書き込んだり真似たり、または「なりすます」ことができる。
【００４５】
前述の認証／完全性モードで動作する「中レベル」セキュリティ・システムの場合、デルタ情報は図５に図示したように保護される。更に詳しく説明すると、それぞれのデルタについて、へッダ情報５００が送信され、それに続けて鍵バージョン番号５０２、平文データ５０４、更に認証子５０６が送信される。ここでもこれらの要素の順序は重要ではない。認証子はデータ５０４の認証／完全性を保護しグループ・メンバーによって送信されたメッセージであることを保証するＭＡＣコード５０６とすることができるが、これはグループ認証鍵ＬＧを知っているのはグループのメンバーだけだからである。別の実施態様において、メッセージ認証子として公開鍵署名認証子を使用することもできる。この場合、メッセージ認証子５０６はハッシュして連結したへッダ及びデータの公開鍵署名で構成する。
【００４６】
好適実施態様において、鍵バージョン番号は２つの部分を有しており、これは「鍵識別子ＫｅｙＩｄｅｎｔｉｆｉｅｒ」と呼ばれるテレスペース全体で使われる独自の文字列と、「鍵バージョンＫｅｙＶｅｒｓｉｏｎ」と呼ばれるインクリメンタルなシーケンス番号である。鍵識別子はテレスペースの別のメンバーが独自に生成する鍵同士を識別するために必要とされる。一方のメンバーが、他方のメンバーも新しい鍵を生成していることについて知らないので、鍵識別子は鍵を個別に識別できるようにする。鍵バージョンは古い鍵、現在の鍵、新しい鍵を識別するために必要とされる。安定状態では、メンバーは鍵識別子の値は異なるが鍵バージョンの値が同じ一組の鍵を使用することになる。メンバーは現在の鍵バージョンの値よりも鍵バージョンの値が小さい「古い鍵」を削除することができる。
【００４７】
好適な実装において、ＭＡＣコード５０６は、最初にデータ５０４と連結したへッダ５００をハッシュし、次にハッシュの結果を従来のメッセージ認証アルゴリズムに沿って保護する。中間ハッシュ関数を使用して後述するような高セキュリティ・バージョンに沿った方法でＭＡＣコードを作成する。また従来のＭＡＣアルゴリズムを使用してグループ認証キーＬＧで単純にへッダとデータを保護すれば、中間ハッシュ関数を使用せずにこのモードを実装することも可能である。前述のように、認証／完全性モードにおいて動作する中レベルのセキュリティ・システムは、第三者が読んだり盗聴できるがグループ・メンバーだけが他のグループ・メンバーのデルタに書き込み、真似（ｉｍｐｅｒｓｏｎａｔｅ）または成りすまし（ｓｐｏｏｆ）できるようなセキュリティ・システムを作成する。
【００４８】
認証／完全性／機密性モードで動作する中レベルのセキュリティ・システムは図６に図示してあるようにデルタのデータを保護する。更に詳しく説明すれば、デルタは鍵バージョン番号６０２及び初期ベクトル６０３の付いたへッダを、データ６０４及びメッセージ認証コード６０６とともに送信することで伝達される。しかし、この場合、データ６０４は暗号化されている。このプロトコルはグループ暗号化鍵ＫＧで暗号化することでデルタ・データの機密性を保護しておりグループ認証子６０６による完全性と認証の保護が継続する。データ６０４は従来の暗号化アルゴリズムを用いてグループ暗号化鍵ＫＧで暗号化され、暗号化されたデータは初期ベクトルと連結される。ここでも認証またはＭＡＣコードは好適実施態様においてへッダと平文データの連結をハッシュ化してからグループ認証鍵ＬＧでハッシュ情報を符号化することにより形成されている。またデータとへッダ及びデータのハッシュの連結をひとつの暗号化キーＫＧで暗号化してからその結果をへッダ、鍵バージョン番号、初期ベクトルと連結することでこのモードを実装することも可能である。後者の暗号化は機密性と認証／完全性を両方とも保証し、２つの鍵ＫＧとＬＧの間で機密性及び認証・完全性の責任を分担する別々のＭＡＣ部分を使用しなくてすむ。図６に図示した実装を実際に使用して後述する高セキュリティ・モードに沿った実装を行なうことができる。
【００４９】
認証／完全性モードで動作する「高レベル」セキュリティ・システムにおいてデルタ・データは図５に図示した構成または図７に図示した構成のどちらかを用いて保護できる。このシステムで使用されるプロトコルは平文デルタ情報を送信するが、認証／完全性を保証するため、シングルターゲットの秘密鍵多重認証子か公開鍵署名認証子のいずれかを使用する。
【００５０】
シングルターゲット秘密鍵多重認証子の場合、図５に図示した構成を使用する。更に詳しく説明すれば、へッダ情報５００は鍵バージョン５０２、暗号化していないデータ５０４、メッセージ認証子５０６とともに送信される。しかし、この場合、鍵バージョン番号５０２は送信者と受信者全部との間の鍵バージョンのすべてを連結したもので構成する。同様に、メッセージ認証子５０６は送信者とそれぞれの受信者との間の個別のメッセージ認証子を連結したもので構成する。それぞれのメッセージ認証子は認証鍵で保護されるが、この認証鍵は送信者と受信者との間でのみ使用されるものである（Ｌｉｊ鍵の一つ）。
【００５１】
更に、好適実施態様では、中間ハッシュをメッセージ認証コードに使用する。更に詳しく説明すると、へッダとデータは連結され、ハッシュされ、更に適当な認証鍵によって保護される。この場合、中間ハッシュは認証鍵それぞれに対してへッダとデルタ全体を再ハッシュするのを避けるために使用している。へッダとデルタをハッシュしたら、適当な認証鍵でハッシュした情報を単純に保護することでこのハッシュを複数回使用できる。
【００５２】
別の実施態様では、公開鍵署名認証子をメッセージ認証コードとして使用する。この構成が図７に図示してある。この構成では、へッダ情報７００が最初に送信され、これに暗号化されていない（Ａ／Ｉモード）または暗号化された（Ａ／Ｉ／Ｃモード）データ７０２が続く。メッセージ認証子コード７０４はハッシュし連結したへッダとデータの公開鍵署名から構成される。
【００５３】
認証／完全性／機密性モードで動作する高レベルセキュリティ・システムは図６と図７に図示したデルタ構成でデータを保護する。基本的にこれは図５と図７に図示してある認証／完全性モードと同じであるが、グループ暗号化鍵ＫＧでデルタ・データが暗号化され図６の場合の初期ベクトルと連結される点で異なっている。
【００５４】
デジタル署名またはデジタル証明書を生成して使用するメカニズムが図８に図示してある。データ８００のデジタル署名を生成するためには、多数の一般的に周知のハッシュ・アルゴリズムの一つを用いて、ステップ８０２に示してあるようにデータ８００のハッシュ値を計算する。ハッシュしたデータはステップ８０４に示したように（暗号化と同様の演算で）公開鍵／秘密鍵ペアのうちの秘密鍵を用いて署名される。その結果がデジタル署名８０６である。更に、データがユーザのＩＤまたは公開鍵に関係する場合、（署名ではなく）データはデジタル「証明書」と呼ばれる。
【００５５】
デジタル署名を使用するには、図８で破線より下に示してあるように有効化手順を実行する。更に詳しく説明すると、ハッシュしたデータの確認（復号に似た動作）のために公開鍵／秘密鍵ペアのうちの公開鍵を使用する署名確認アルゴリズム８１４へ、デジタル署名が矢印８１２で示したように提供され、また証明書が矢印８１８で示したように提供される。データ８００それ自体は矢印８０８で示したようにハッシュ・アルゴリズム８１０へ提供される。このハッシュ・アルゴリズムはデジタル署名を生成するために使用したハッシュ・アルゴリズム８０２と同一のものである。囲み８１６に示したように、データの再ハッシュが確認したハッシュ・データと比較される。結果が同一であれば、確認したハッシュ・データは正しい、すなわちデータは正しく（ａｕｔｈｅｎｔｉｃａｌｌｙ）署名に関連している。
【００５６】
機密グループを形成する手順が模式的に図９に図示してありそのステップが図１０に図示してある。図９に図示してあるように、グループ９００は議長９０２とその他のＮ−１人のメンバーで構成され、そのうち３人がメンバー９０６、９０８、９１０として示してある。グループ９００の形成は議長９０２によって管理され、議長は新しいメンバーを招待して追加する権限を与えられたメンバーである。図示した手順によれば、招待者９０４は初期認証の後でグループ９００へ追加される。以下の議論では認証及び完全性による最高セキュリティ・モードに焦点を当てて説明する。その他の意図されるモードはこのモードから派生させることができる。
【００５７】
加入手順はステップ１０００から始まりステップ１００２に進む。ステップ１００２では、議長９０２が招待されることになる人９０４へ招待メッセージを送信する。このメッセージは図９の矢印９１２で模式的に示してある。このメッセージの内容は図１１に示してある。メッセージはへッダ１１００と、これに続く招待者の名前１１０２から構成され、この名前はＵＲＬやその他の識別情報とすることができる。へッダの順序は本発明の原理から逸脱することなく反転できる。招待者の名前に続くのが署名済み招待「ナンス」（ｎｏｎｃｅ）１１０４である。署名済みナンスは議長によって生成されたタイムスタンプのハッシュ、議長９０２の名前／ＵＲＬ、招待者９０４の証明書（入手可能な場合）、テレスペースの名前／ＵＲＬ、署名つきナンスが発生することが考えられる別の状況を識別するために使用されるタグである招待「オプコード」（Ｏｐｃｏｄｅ）を含む署名データである。
【００５８】
一般的に言って、ナンスはプリンシパルＡが生成してプリンシパルＢへ送信するもので時間とともに変化するパラメータであり、これは任意の状況で一回だけ使用されるものである（例えば、本明細書で説明している招待プロトコルを介してＡがＢを招待する場合など）。実際に、ナンスは状況を定義する、言い換えればプロトコル動作の同時性を保証して再生（ｒｅｐｌａｙ）及びインターリーブ攻撃（ｉｎｔｅｒｌｅａｖｉｎｇ ａｔｔａｃｋ）を防止するために使用される。ナンスは秘密にしなくても良く、１回限りの独自なものであれば良い。各種システムで使用されるナンスの典型的な例としては次のようなものがあげられる：衝突しない乱数、タイムスタンプ（十分に信頼できるクロックを備えたシステム、特に信頼できる分散時刻同期プロトコルの存在下ではほぼ理想的である）、シーケンス番号。好適実施態様ではタイムスタンプが使用されている。
【００５９】
本明細書の状況で重要なことは、プロトコルの実行の全部において、ナンスが（暗号学的な確実性の範囲で）絶対に（ローカル・ポリシーで決定されるなんらかの時間的制約の中で）反復できないことである。これは例えば自分が発行したナンス／招待を（プロトコルの実行に関する他の情報とともに）、不揮発記憶に、ローカル・クロックに合わせてある程度の期間（ローカル・ポリシーによって変化する）、メンバーが記憶しておくことで実現可能で、この時刻以降はナンス情報を破棄してプロトコルの実行を中断させなければならない。
【００６０】
署名つきナンス１１０４に続くのは暗号データ１１０６で、これはこのメッセージで使用されるセキュリティ状態情報である。この情報は議長が選択し受信者がメッセージを正しく解釈できるようにするために必要である。更に詳しくは後述するようなワンタイム鍵で情報を暗号化するのに使用したアルゴリズムの名称の文字列を含む。またメッセージ受信者がメッセージを処理するのに必要なその他なんらかの情報、例えば鍵の長さ、ラウンド数、使用したハッシュ・アルゴリズムの名称、鍵ジェネレータ・アルゴリズムの名称、なども含む。
【００６１】
暗号データ１１０６に続くのは、公開鍵暗号化アルゴリズムに基づいてあらかじめなんらかの合意が得られている招待者の公開鍵で暗号化したワンタイム鍵情報１１０８である。ワンタイム鍵は対称暗号化用の鍵で後述するように招待情報を暗号化するために一回だけ使用される。
【００６２】
鍵情報に続くのが招待情報１１１０で、これはワンタイム鍵で暗号化されている。招待情報も前述したように議長によって生成されたタイムスタンプを含み初期ベクトルと連結できる。招待情報はテレスペース名／ＵＲＬを含むアプリケーション・データで招待者９０４に招待を発行したアクティビティの種類について通知する。これは特に、議長９０２によって権限を委譲（ｍａｎｄａｔｅｄ）されたものとしてテレスペース内で使用しなければならない暗号情報（例えば前述の低／中／高レベル、Ａ／Ｉ／Ｃモード）を含む。このようにすると、招待者には参加するように招待されているテレスペースのセキュリティ特性が招待者に通知され、例えば招待者は参加しないと決定することができる。招待者の証明書が不明な場合、暗号化したワンタイム鍵１１０８を無視しタイムスタンプと招待情報１１１０を暗号化しないで送信する。
【００６３】
招待情報１１１０に続くのはへッダ情報１１００、招待ナンス１１０４、暗号化していないワンタイム鍵（メッセージに含まれる場合）、暗号データ１１０６、暗号化していない招待情報（タイムスタンプなし）のハッシュに対する議長の署名である。この署名は議長の証明書に対して示された情報の全部を結合するもので、議長の証明書は招待者のローカルな公開鍵証明書有効化ポリシーを介して議長に結び付けられている。
【００６４】
送信される情報の最後の部分１１１４は議長の証明書で、議長の名称（ＵＲＬ／ペルソナ）、議長の公開署名確認鍵、及びその他の情報例えば公開鍵アルゴリズム識別子、暗号化公開鍵、などが含まれ、これらすべてが（一つまたはそれ以上の）なんらかの「信頼できる」認証局の署名を介して相互に結合されている。証明書は周知のまたは少なくとも招待者に識別可能ななんらかの証明書フォーマットにフォーマットされる。このフォーマットは公開鍵による証明書（ここで証明書認証局は周知の認証局の階層の内部に組み込まれている）、またはＰＧＰやＳＤＳＩなどを使用した「信頼の輪証明書」（ｗｅｂ−ｏｆ−ｔｒｕｓｔ ｃｅｒｔｉｆｉｃａｔｅ）、あるいは更に単純にこの目的のためだけにその場で構成した自己署名証明書であっても良い。招待者が証明書を頼れる「信頼度」は招待者のローカル公開鍵証明書有効化ポリシーに依存する。
【００６５】
このメッセージを受信すると、招待者は図１５に図示してあるフローチャートに概略してあるステップをとる。招待者の手順はステップ１５００から始まってステップ１５０２へと進み、ここで招待者が暗号データ１１０６を調べてメッセージの暗号化に使用されているアルゴリズムを知る。次にステップ１５０４で、招待者は招待者の名前を検証してその招待が招待者に向けられたものかどうかを確認する。
【００６６】
次に、ステップ１５０６で、招待者が招待者のローカルな公開鍵有効化ポリシーに従って議長の名前／ＵＲＬを含む議長の証明書を有効化する。招待者は適当な証明書有効化プロバイダ（招待者のローカル・ポリシーになっている場合にはｔｒｉｖｉａｌ／初期設定で「自己署名証明書をすべて信頼する」有効化アルゴリズムが実装することがある）を起動することにより行なう。
【００６７】
ステップ１５０８で、招待者は議長の署名を確認してこの招待が本当に議長９０２から来たものかどうかを確かめ招待者９０４が本当に招待されたのかを確かめる。
【００６８】
最後にステップ１５１０で、招待者は招待情報を復号して検証し招待者が議長の招待を受け入れたいかどうかを決定する。そして手順はステップ１５１２で終了する。
【００６９】
図１０に戻ると、招待者９０４が招待を受け入れることに決定した場合、ステップ１００４で招待者９０４は議長９０２へ受諾メッセージを送信して応答する。このメッセージが図９では矢印９１４として模式的に図示してある。これ以外に、招待者が招待を受け入れないと決定した場合、エラーメッセージを招待者９０４から議長９０２へ送信する。
【００７０】
受諾メッセージの内容が図１２に図示してある。メッセージはへッダ１２００と、これに続く署名付きの招待ナンス１２０２で構成され、ナンスは招待メッセージで議長から招待者へ送信されたものである。これを用いることで、議長はこの受諾メッセージが招待に応答したものであると認識できることになる。署名付きナンス１２０２には署名つき受諾ナンス１２０４が続く。署名付き受諾ナンスは招待者が生成したタイムスタンプ、招待者９０４の名前／ＵＲＬ、議長９０２の証明書、テレスペースの名前／ＵＲＬ、そして受諾オプコードを含む。
【００７１】
ナンス１２０４には暗号データ１１０６と同様のセキュリティ内容暗号データ１２０６が続く。
【００７２】
次に、公開鍵暗号化メカニズムを使用して、新しく生成したワンタイム鍵１２０８の公開鍵暗号を送信し、パラメータ、情報、公開鍵暗号化鍵が議長９０２から招待者９０４へ送信される（例えば公開ＲＳＡ暗号鍵）。
【００７３】
暗号化ワンタイム鍵１２０８に続くのはアプリケーション・データ１２１０で、これにはワンタイム鍵を使用して暗号化した２個のタイムスタンプと受諾データを含む。この情報１２１０は招待者９０４の受諾について議長９０２に通知するものである。
【００７４】
次に、招待者９０４の署名を送信する。この署名はへッダ情報１２００、議長の名前と招待者のナンス１２０２に受諾ナンス１２０４を連結したもの、暗号化していないワンタイム鍵、暗号データ１２０６と暗号化していない受諾情報（タイムスタンプなし）のハッシュによる。この署名は招待者の証明書にすべての示された情報を結合する（証明書は更に議長の証明書公開鍵有効化ポリシーを介して招待者９０４に結合されている）。議長９０２の名前がこの署名のスコープ内に含まれ招待者が署名した、議長には分かっているワンタイム鍵を議長が第三者へ送信するのを防止し、これにより招待者９０４を真似なければならないことに注意する。最後に、招待者の証明書１２１４を送信する。
このメッセージの受信時に、議長９０２は図１６のフローチャートに示してある手順を実行する。この手順はステップ１６００から始まりステップ１６０２に進み、ここで議長９０２が暗号化されたワンタイム鍵を復号し、これにより鍵を取り込む。
【００７５】
次に、ステップ１６０４で、議長９０２はワンタイム鍵を使って暗号化された受諾情報を復号する。次にステップ１６０６で、議長は招待者の証明書を検証して招待者の名前を取り出す。
【００７６】
ステップ１６０８で、議長９０２は招待ナンスを再計算して再計算したナンスと受信した招待ナンスとを調べ受諾メッセージが応答している招待がどれかを決定する。本発明の一つの態様によれば招待ナンス（図１１の１１０４）は「ステートレス」つまり関連するタイミングとは無関係に解釈できることに注意する。例えば、メンバーＡが装置１から招待者Ｂへ招待を発行したが後にＢの受諾を装置２で受信したと仮定する。オリジナルの招待メッセージではナンスがデルタ経由でＡの使用可能な全装置へ送信されたとしても、招待者Ｂからの受諾メッセージは招待ナンスを伝達するデルタより先に装置２に到着することがあり装置２でのソフトウェアによる比較ができない場合がある。この問題を回避するため、ナンスに関連した情報は装置２を含めた当該メンバーの装置の全部で視覚的に表示される。この表示の一例が図２３に示してあり表示は例えばユーザ・インタフェース・ダイアログボックス２３００経由で、またはその他の類似のメカニズムを介して行なわれる。図２３に図示してあるように、３項目の情報がダイアログ・ボックス２３００に表示される。これは、招待者Ｂの題名２３０２、招待者Ｂの証明書のメッセージ・ダイジェスト２３０４、及び招待メッセージ署名ナンス２３０５からのタイムスタンプである。
【００７７】
送信者の「証明書」は重要な２項目の情報を伝達するパッケージである：これはメッセージ送信者の「題名」と送信者の「公開鍵」である。この場合、Ｂの題名は装置２のプロトコル・エンジンによって抽出されダイアログ・ボックス２３００のテキストボックス２３０２に表示されている。この名前の一例としては、「ｗｔｕｖｅｌｌ＠ｇｒｏｏｖｅ．ｎｅｔ」がある。Ａはこれで受諾メッセージが招待に対応することを確認できる。
【００７８】
受諾を有効化するためには、Ａはすでに招待者Ｂの対象者名を知っているので、Ａは本発明のコラボレーション・システムとは別の経路から認証のメッセージ・ダイジェストを受け取る必要がある。例えば、この情報を受け取る代表的な方法はＡがＢを電話で呼び出して証明書のメッセージ・ダイジェストがどのようなものなのかを尋ねることである。例えば、この計算したメッセージ・ダイジェストは「０ａ，１ｂ，２ｃ，３ｄ；４ｅ，５ｆ，６ａ，７ｂ；８ｃ，９ｄ，ａｅ，ｃｆ；ｃ１，ｄ２，ｅ３，ｆ４；０５，１６，２７，３８；４９，５ａ，６ｂ，７ｃ」といったようなものになる。
【００７９】
Ａが受諾メッセージを介してＢの証明書を受け取ったら、メッセージ・ダイジェスト（または証明書の「フィンガープリント」）を、受諾メッセージのＢの証明書１２１４から、従来のメッセージ・ダイジェスト・アルゴリズム（例えばＭＤ５やＳＨＡ１など）を用いて図２１と図２２に図示してあるセキュリティ・サービス・アーキテクチャにより、アルゴリズム的に計算する。この再計算したメッセージ・ダイジェストがボックス２３０４に表示される。再計算したメッセージ・ダイジェストがすでに分かっている正しいメッセージ・ダイジェストと一致すれば、Ａは提示された証明書が正しいものであるとして受け入れることができる。それ以外の場合には破棄される。この操作は「証明書有効化」と呼ばれる。
【００８０】
「署名付きナンス」はメッセージの署名である。従って、メッセージのタイムスタンプと送信者の証明書を含む情報を互いに結び付ける。「再生攻撃」を避けるためには（すでに送信された正しいメッセージを再送することによる攻撃）、受諾メッセージに含まれている招待ナンス１２０２のタイムスタンプが受け入れ可能な範囲内にあることを確認することも必要である。タイムスタンプ情報はナンスから抽出されてダイアログボックス２３００のボックス２３０５に表示される。この情報は、例えば、「２００００４０７１２１１２４Ｚにあるｎａｓｈｔｇｉｒｉ＠ｇｒｏｏｖｅ．ｎｅｔあての招待メッセージ」といったものである。Ａは幾らか早い時刻にタイムスタンプを生成したのであるから、おそらくＡはその時刻を知っている。メンバーＡはタイムスタンプを解釈して情報が受け入れられるものかどうかを決定できる。メンバーＡが情報を受け入れる場合には、ＯＫボタン２３０６をクリックし、そうではないなら中止ボタン２３０８をクリックする。
【００８１】
同様の問題は招待者Ｂが受諾を送信した装置とは別の装置でテレスペース・データを受け取った場合にも発生する。この後者の問題は同じ方法で処理される。
【００８２】
次に、ステップ１６１０で、議長９０２は議長のローカル公開鍵ポリシーにしたがって招待者の証明書を有効化する。議長がすでに招待者の証明書を先の招待メッセージの時点で持っているならこのステップは省略しても良く、その時点で行なった有効化に満足している。議長は適当な証明書有効化プロバイダを起動することによりこの有効化を行なう。
【００８３】
次に、ステップ１６１２で、議長９０２は招待者の署名を確認し、招待者の署名は更に受諾メッセージの認証／完全性を確認し、この受諾が本当に招待者９０４から来たものであることを確かめる。
【００８４】
次に、ステップ１６１４で、議長は復号した受諾情報を検証して招待情報と一致することを確認し、議長が招待者の受諾を認めたいかどうかを決定する。
最後に、ステップ１６１６で、オプションで追加の署名として議長は自分自身の署名を招待者の証明書に追加することができる。この追加署名によってポリシーが有効になるのでグループ・メンバーは議長９０２の証明書を信頼している限り招待者の証明書を有効化できる。
【００８５】
手順はステップ１６１８で終了し、情報が真正なものなら招待者はこれ以後「テレスペースのメンバー」となる。図１０に戻って、ステップ１００６に記載してあるように、議長９０２が「新規メンバー追加」デルタをグループ９００に存在する全メンバーに送信する。これらの新規メンバー・メッセージは図９で矢印９１６、９１８、９２０として模式的に示してある。
【００８６】
議長が他のそれまでに存在しているメンバーへ送信する新規メンバー追加メッセージの内容が図１３に示してある。デルタ・メッセージはへッダ１３００と、これに続けて統合鍵バージョン番号情報を含み、鍵バージョン情報はグループ鍵とすべての認証／完全性の鍵についての全部の鍵バージョン番号を連結したものである。
【００８７】
統合鍵バージョン１３０２には、暗号化した新規グループ暗号鍵及び認証鍵の連結からなる再キーイング情報１３０４が続く。それぞれのメンバー対に対して、グループ暗号鍵及び認証鍵を連結したものがメンバー同士で対になった鍵を使って暗号化され、結果が初期ベクトルと連結される。これらの連結された鍵が更に連結されて統合再キーイング情報１３０４を形成する。新しいキーは古い／現在のグループ鍵ＫＧ／ＬＧを置き換える。新規に追加されたメンバーは古い／現在のグループ鍵を知ることはない。この再キーイングは新規メンバーがそれ以前のテレスペース通信を記録したり読み取れないようにするために必要である。
【００８８】
次に、新規グループ暗号鍵で暗号化し初期ベクトル１３０６と連結した参加情報を送信する。このデルタの内容は、招待者の名前に招待者の証明書と参加情報を連結したものである。参加情報は議長９０２が生成したアプリケーション・データで、他のグループ・メンバーが、メンバー・マネージャ情報を含めて、知る必要のある新規メンバーについての情報に関連する。またテレスペースのメンバーやその他各種情報例えば招待者の役割などのリストを含めることができる。
【００８９】
最後に、メッセージ多重認証コード１３０８を送信する。これは議長と各メンバーの間の認証子を連結したものとすることができる。各認証子は議長からメンバーへのペアになった認証鍵Ｌ０ｊで保護されているハッシュ情報である。ハッシュ情報はへッダ１３００と、統合新規グループ鍵情報１３０４と、暗号化していないデルタ情報を含む。これ以外に、メッセージ認証コードは前述のハッシュ情報の議長署名とすることができる。
【００９０】
図１３に示したメッセージを受け取ると、各メンバー９０６〜９１０は図１７のフローチャートに示してあるステップを実行する。この手順はステップ１７００で始まりステップ１７０２へ進み、ここでメンバーが暗号化されたグループ鍵を復号し、これによって新しいグループ鍵ＫＧ／ＬＧを知る。しかし、各メンバーは、ＫＧ／ＬＧで保護された古いデータが存在しないことを確認するのに必要とされる限り、古い／現在のグループ鍵ＫＧ／ＬＧの知識を保持している必要がある。その後、各メンバーは古い鍵ＫＧ／ＬＧを破棄しその痕跡をすべて抹消する。
【００９１】
次に、ステップ１７０４で、暗号化されたデルタ情報を各メンバーが復号し、これによってデルタ内の情報を知る。ステップ１７０６では、メンバーが認証鍵で暗号化された多重認証子の項目を介して、メッセージの認証／完全性を確認する。
【００９２】
次に、ステップ１７０８で、メンバーは議長９０２が（議長のＩＤはへッダ情報として送信される）議長であること、また新規メンバーを追加する権限があることを確かめる。
【００９３】
ステップ１７１０では、メンバーがデルタ情報を実行する。これを行なう最中に、メンバーは招待者の名前、証明書、参加情報を含めた新規メンバー・マネージャ情報に気づく。手順はステップ１７１２で終了する。
【００９４】
最後に、図１０に戻って、ステップ１００８で、矢印９２２で模式的に示したように、議長９０２が招待者９０４へテレスペース情報を送信する。手順はステップ１０１０で終了する。テレスペース情報は図１４に示したメッセージとともに招待者９０４へ送信される。この情報はへッダ１４００で始まり、ノンス１２０４と同一の署名つき受諾ナンスが続く。これに、図１２に示した受諾メッセージに関連して説明したように暗号データ１４０４と暗号化したワンタイム鍵（これは新規に生成する）１４０６が続く。
【００９５】
暗号化したワンタイム鍵１４０６のあとには直前のメッセージ部分にあるワンタイム鍵で暗号化されたテレスペース（ＴＳＰ）データが続く。このデータはワンタイム鍵で暗号化したペイロードと連結された初期ベクトルを含む。ペイロードは招待者が生成したタイムスタンプと連結グループ暗号及び認証鍵ＫＧ／ＬＧ、及びＴＳＰデータである。ＴＳＰデータは招待者がメンバーから受信を許可されているＴＳＰデータのメンバーによるバージョンを含むアプリケーション・データである。
【００９６】
暗号化されたＴＳＰデータ１４０８には、へッダ１４００、招待者の名前、署名付きナンス１４０２、連結グループ暗号及び認証鍵、暗号化していないワンタイム鍵、暗号情報１４０４、暗号化していないＴＳＰデータを含むハッシュ情報に対する議長の署名１４１０が続く。最後に、議長の証明書１４１２が後続する。
【００９７】
このメッセージを受信すると、招待者９０４は図１８に示した手順を実行し、手順はステップ１８００で始まりステップ１８０２へ進みここで招待者９０４は暗号化された１回限りの鍵（以下、ワンタイム鍵）を復号してワンタイム鍵を取り出す。
【００９８】
次に、ステップ１８０４で、招待者はワンタイム鍵を使用して暗号化されたＴＳＰデータを復号し、ＴＳＰ情報を取り出す。次に、ステップ１８０６で、招待者９０４は署名つき受諾ナンスを再計算してこれと受信したナンスとを比較してこれが受け入れられるものであることを確認する。先に説明したように、この比較はソフトウェアでまたは視覚的検査によって行なうことができる。このノンスは議長の証明書を含んでいるので、招待者はこの証明書を再有効化する必要がない。
【００９９】
ステップ１８０６では、招待者９０４が議長の署名を検証し、ステップ１８０８では、招待者が復号したＴＳＰデータを初期の「作成中テレスペース」に広める。唯一残っている、なすべきことはテレスペースの他のすべてのメンバーと鍵ペアを交換することで、そのあと、招待者はテレスペースの完全なメンバーとなる。
【０１００】
鍵ペアは再キーイング手順で交換でき、ここで再キーイング情報は他の情報を搬送するデルタに「ピギーバック（相乗り）」する形になる。この再キーイングを実行するための一つのプロトコルは図１３に示した新規メンバー追加デルタ・メッセージで前述した。再キーイング情報は他のデルタ・メッセージに挿入することもできる。このようなピギーバック型デルタ・メッセージは通常のデルタ・メッセージだが、鍵変更（グループ／テレスペース鍵（ＫＧ／ＬＧ）、トライブ／サブグループ鍵（トライブＴ１、ＴｎについてＫＴ１／ＬＴ１、ＫＴｎ／ＬＴｎ）及び／または鍵ペア（Ｋｉｊ／Ｌｉｊ）のあらゆる組み合わせに同時に関係する）がデルタ・メッセージにピギーバックする点で異なっている。デルタそれ自体は同時にトライブＴｋに適した新しい鍵で暗号化される。新しい（再キーイングされた）鍵はこのメッセージで搬送される。鍵ペアがメッセージにピギーバックしている場合、メッセージは公開鍵署名認証子によって保護される。それ以外の場合では、メッセージは現在の鍵ペアを用いる多重認証コードによって保護される。
【０１０１】
このようなメッセージの一例が図１９に示してある。デルタ・メッセージはへッダ１９００と、これに続く統合鍵バージョン情報１９０２を含み、統合鍵バージョン情報は新規グループ鍵とすべての新規トライブ認証／完全性鍵についてのすべての鍵バージョン番号の連結である。
【０１０２】
統合鍵バージョン情報１９０２には第２のセクション１９０４が続き、これも統合鍵バージョン情報を含む。鍵ペア変更が送信中の場合、この情報は新しい鍵ペアについてのすべての鍵バージョン番号の連結を含む。別の場合は、グループ鍵とトライブ鍵を再キーイングしている場合情報１９０４は古いまたは現在の鍵ペアについての統合鍵バージョン情報を含む。
【０１０３】
統合鍵バージョン１９０４に続くのが統合再キーイング情報１９０６で、これは新しいグループ及びトライブ鍵（ＫＧ／ＬＧ及びＫＴ／ＬＴ）の連結から構成される。各メンバーのペアについて、連結されたグループ暗号化及び認証鍵はメンバーのペアに対して鍵ペアを用いて暗号化され、その結果が初期化ベクトルに連結される。これらの連結された鍵はそれら自身連結されて統合再キーイング情報１９０６を形成する。新しい鍵は古い／現在のグループ鍵ＫＧ／ＬＧを置換する。新しい鍵ペアが転送中の場合、統合グループ再キーイング情報には新しい鍵ペアに対する統合再キーイング情報が続く。各メンバーのＫ／Ｌ鍵は連結されそのメンバーの公開鍵を用いて暗号化される。これらの暗号化された鍵は連結されて統合鍵ペア再キーイング情報を形成する。
【０１０４】
次に、新しいグループ暗号化鍵で暗号化されて、新しい鍵１９０８に対応する初期ベクトルに連結されたデルタ情報が送信される。このデルタの内容は従来のあらゆるデルタ・メッセージとすることができる。
【０１０５】
最後に、メッセージ多重認証コード１９１０が送信される。これはメンバー間の認証子を連結したものとすることができる。それぞれの認証子は送信側メンバーから受信側メンバーへのペアになった認証鍵Ｌｉｊで保護されたハッシュ情報である。ハッシュ情報はへッダ１９００と、統合新規グループ鍵情報１９０４（またこれが送信中の場合には統合新規鍵ペア情報）、更に暗号化されてないデルタ情報を含む。ペアになった鍵がメッセージにピギーバックしている場合には、多重認証コードの代わりに、公開鍵署名認証子を送信する。
【０１０６】
前述のセキュリティ・システムは様々な方法で実装できる。好適実施態様では、図２０に模式的に示したプロバイダ・アーキテクチャを使用する。このようなアーキテクチャが好ましいのは、前述したセキュリティ・プロトコルが「アルゴリズム中立」であることによる、つまり特定の暗号化及び保護アルゴリズムに依存していないためである。このプロトコルはアルゴリズムに中立なインフラストラクチャ例えば図２０に図示してあるそれを利用できる。図２０は縦方向の次元と横方向の次元で構成される２次元構造を示す。縦方向の次元は数個の抽象層から構成され、横方向の次元は縦方向の層を含めた各種アプリケーション及びサービスで構成される。最上部の層はアプリケーション層で、アプリケーションの組を含み、そのうちのアプリケーション２０００と２００２が図示してある。これらのアプリケーションには、分散通信システム及びコラボレーション・システム、例えば前述のコラボレーション・システムや、保護データ記憶、可用性（サービスの非拒絶）、システム管理、医療情報システム、航空管制システム、原子力発電所、軍事情報作戦指令管制システムなどを含み、これだけに限定されない。
【０１０７】
アプリケーション２０００及び２００２は一つまたはそれ以上のセキュリティ・サービスにアクセスするが、そのうちサービス２００４と２００６を図示してある。これらのサービスには、例えば識別、認証、完全性、機密性、プライバシー、許可、権威の代理、アカウンタビリティと非拒絶、タイムスタンプ、公証（ｎｏｔａｒｉｚａｔｉｏｎ）、監査、信頼ポリシー管理、侵入検知及び復旧サービスなどを含む。
【０１０８】
セキュリティ・サービスは抽象プリミティブ・サービス２００８と２０１０を含む抽象（またはアルゴリズムに中立な）プリミティブ・サービスの組み合わせにより実装される。抽象プリミティブ・サービスは実際には具象（またはアルゴリズム特異的な）プリミティブ・サービスの組み合わせによって実装される。例えば、抽象プリミティブ・サービス２００８は具象プリミティブ・サービス２０１２、２０１４、２０１６により実装され、一方抽象プリミティブ・サービス２０１０は具象プリミティブ・サービス２０１８、２０２０、２０２２によって実装される。これらの具象プリミティブ・サービスは例えば特定の暗号サービスやプロトコルなどのサービスを含む。
【０１０９】
各抽象層は高次の抽象層または層群によって消費されるサービスを作成する。好適な実装では、アプリケーション２０００、２００２とセキュリティ・サービス２００４、２００６の間の関連性、ならびにセキュリティ・サービス２００４、２００６と抽象プリミティブ・サービス２００８、２０１０の間の関連性は従来どおりの、これらの層の間で静的なコンパイル時に決定される結合（ｃｏｍｐｉｌｅ−ｔｉｍｅ ｂｉｎｄｉｎｇｓ）である。しかし抽象プリミティブ・サービス２００８、２０１０と具象プリミティブ・サービス（２０１２、２０１４、２０１６、２０１８、２０２０、２０２２）の間の結合は、制約された方法で一つの抽象プリミティブ・サービスと一つまたはそれ以上の具象プリミティブ・サービスを関連づける動的なランタイム結合であるのが望ましい。この動的な結合は「プロバイダ・アーキテクチャ」と呼ばれ、抽象またはアルゴリズム中立なプリミティブ・サービスをなんらかの具象またはアルゴリズム特定のそれで作成することにより実装できるメカニズムであり、実装は任意の時刻にその環境内でアクティブにすることができるようなものである。
【０１１０】
図２１と図２２はプロバイダ・アーキテクチャの特定の実装を模式的に示している。オブジェクト指向プログラミング技術をこの実装では用いているが、他の等価な技術やプログラミング言語で実装することもできることは当業者に理解されるであろう。更に詳しく説明すると、図示した実装はダイナミック・リンク・ライブラリ（ＤＬＬ）を使用して各種サービスを提供している。
【０１１１】
ＤＬＬは図２１と図２２のそれぞれに図示してある。図２１に図示したＤＬＬ はセキュリティ・サービス・マネージャ（ＳＳＭ）と呼ばれるもので、図２２に図示したＤＬＬはセキュリティ・サービス・プロバイダ（ＳＳＰまたは単にプロバイダ）と呼ばれる。セキュリティ・サブシステムのどのランタイム・インスタンシエーションにも必ず一つだけＳＳＭ ＤＬＬがロードされる。一方でＳＳＰ ＤＬＬは何個でもロードでき、それらがすべて独立しているという制限が加えられるだけである（これらがすべてシステム・レジストリなどのファイルに記録されている通りの独立したＬＩＢＩＤとファイル名を有するという意味で）。ＳＳＰ ＤＬＬの名称はそのデベロッパが選択する。図示したＳＳＰ ＤＬＬの例はＳｅｃＰｒｏｖＸＸＸ．ｄｌｌというような名前がつけられていると考えられ、他のＤＬＬはＳｅｃＹＹＹＰｒｏｖ．ｄｌｌまたはＺＺＺＳｅｃＰｒｏｖ．ｄｌｌというような名前をつけることができる。
【０１１２】
図２１と図２２のボックスはマイクロソフト・コモン・オブジェクト・モデル（Ｍｉｃｒｏｓｏｆｔ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に適合するＣＯＭクラスを示す。これらのクラスは、エンジン・クラス（右側に示す）と非エンジン・クラス（左側に示す）の２種類のグループに大別される。ＣＯＭエンジン・クラスのそれぞれは一つだけＩＤＬインタフェースを実装してエクスポートする。例えば、エンジン・クラス２１０６（ＭｅｓｓａｇｅＤｉｇｅｓｔ）はインタフェース２１０４（ＩＭｅｓｓａｇｅＤｉｇｅｓｔ）をエクスポートし、エンジン・クラス２１１８（ＫｅｙＧｅｎｅｒａｔｏｒ）はインタフェース２１１６（ＩＫｅｙＧｅｎｅｒａｔｏｒ）をエクスポートし、エンジン・クラス２１２６（Ｃｉｐｈｅｒ）はインタフェース２１２４（ＩＣｉｐｈｅｒ）をエクスポートする。これはインタフェース２１００をエクスポートするＳｅｃｕｒｉｔｙクラス２１０２についても言えることである。図２２に図示した具象クラスについても同じことが当てはまる。例えば、具象エンジン・クラス２２０４（ＸＸＸＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ）はインタフェース２２０６（ＩＭｅｓｓａｇｅＤｉｇｓｅｔＳｐｉ）をエクスポートし、エンジン・クラス２２０８（ＸＸＸＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）はインタフェース２２０６（ＩＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）をエクスポートし、エンジン・クラス２２１０（ＸＸＸＣｉｐｈｅｒＳｐｉ）はインタフェース２２１２（ＩＣｉｐｈｅｒＳｐｉ）をエクスポートする。
【０１１３】
プロバイダ抽象クラス２１２２とＸＸＸＰｒｏｖｉｄｅｒ具象クラス２２００（図２２）で形成されるプロバイダ／ＸＸＸプロバイダ（Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ）「複合クラス」についても同じことが言える。更に詳しく説明すると、Ｐｒｏｖｉｄｅｒクラス２１２２はＩＰｒｏｖｉｄｅｒインタフェース２１２０をサポートし、ＸＸＸＸＰｒｏｖｉｄｅｒクラス２２００はＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（図２２には図示していない）をサポートする。しかし、Ｐｒｏｖｉｄｅｒクラス２１２２はＸＸＸＰｒｏｖｉｄｅｒ クラス２２００の内部でのみ統合可能で、したがって独立してインスタンシエーションできない。つまり、ＩＰｒｏｖｉｄｅｒ２１２０インタフェースとＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースの両方がＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００によって「エクスポート」されることになる。
【０１１４】
Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラスと図２１に図示したエンジン・クラスの全部は図２２に図示してある他の一つのクラスと組み合わされる（ただしこれは多数のＳＳＰを構成することができそれぞれが多数のアルゴリズムをサポートできることから多面的な関係である）。ＳＳＭ ＤＬＬ（図２１）のパートナーは抽象パートナーと呼ばれ、ＳＳＰ ＤＬＬ（図２２）のパートナーは具象パートナーと呼ばれる。図２１と図２２の左側には、「マスター」クラスと呼ばれる２種類のＣＯＭクラスがあり、これはＳｅｃｕｒｉｔｙクラス２１０２とＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００である。Ｓｅｃｕｒｉｔｙクラス２１０２が「マスター」クラスであるという意味は、各種「スレーブ」Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスを制御できるということである。逆に、各種Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスが「マスター」であるということの意味は、これらが各種のスレーブ低レベル／具象エンジン・クラスを制御すると言うことである。マスター・クラスはほとんどセキュリティ・サブシステムの内部的なもので大半のアプリケーションからは見えない。
【０１１５】
図２１と図２２の右側にはエンジン・クラスと呼ばれる２種類のＣＯＭクラスがあり、これらは図２１に図示した抽象エンジン・クラスと図２２に図示した具象エンジン・クラスである。抽象エンジン・クラスはｍ＿Ｅｎｇｉｎｅフィールドの値に０を持っていれば純粋に抽象的であると言われる。３種類のエンジン・クラス（ＭｅｓｓａｇｅＤｉｇｅｓｔ、ＫｅｙＧｅｎｅｒａｔｏｒ、Ｃｉｐｈｅｒ）が説明のために図示してあるが、これらの個数は原理的に制限されない。これらのエンジン・クラスは図２１と図２２に図示してあるように対で発生し、低レベルのクラスが高レベルのクラスの内部に内包または封入される（ｍ＿Ｅｎｇｉｎｅメンバーを経由する）。高レベル・エンジン・クラスの機能はセキュリティ・サービスの消費者が起動するアプリケーション・プログラミング・インタフェース（ＡＰＩ）をエクスポートすることである。低レベル・エンジン・クラス名に見られる接尾辞「Ｓｐｉ」はサービス・プロバイダ・インタフェース（またはセキュリティに関して言えばセキュリティ・プロバイダ・インタフェース、また時に他の状況下ではシステム・プログラミング・インタフェース）を意味するもので、これの唯一の消費者は高レベル・エンジン・クラスである。これらの低レベル・エンジン・クラス内に実際のアルゴリズム特有の実装コードが存在する−−これが「ＳＳＰ ＤＬＬ」の実際に「提供する」最終的な機能である。エンジン・クラスを２つの部分に分割したことが、これらのサポートするサービスの命名構造に反映されており、完全認証サービス名は抽象／概念の接頭辞と具象／アルゴリズムの接尾辞、例えばＭｅｓｓａｇｅＤｉｇｅｓｔ．ＭＤ５というように構造化される。
【０１１６】
各具象ＳＳＰ（ＸＸＸＰｒｏｖｉｄｅｒクラス２２００）は静的な情報を含み、これにはその名前（ｓ＿ＭｙＮａｍｅ、文字列）、バージョン（ｓ＿ＭｙＶｅｒｓｉｏｎ、数字）、クラスＩＤ（ｓ＿ＭｙＣｌｓｉｄ、１６バイト二進数）、情報（ｓ＿ＭｙＩｎｆｏ、文字列）、ＤＬＬにバンドルされているサービスのリスト（ｓ＿ＭｙＳｖｃＭａｐ［］、文字列のペアのリスト）を含む。ｓ＿ＭｙＳｖｃＭａｐ［］の各エントリでは、一方の文字列がそのサービスで実装するアルゴリズムの名称、他方がそのアルゴリズムを実装する具象エンジン・クラス（ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌにバンドルされる）のＣＯＭ ＣＬＳＩＤ（クラスＩＤ）である。
【０１１７】
エンジン・クラスに加えて、セキュリティ・サブシステムは多数の非エンジン・クラスを含む。代表的な２つのクラス、ＫｅｙとＫｅｙＰａｉｒが図２１に示してある。図面が示すように、このような非エンジン・クラスは相対的に通常のＣＯＭ クラスで、唯一普通とは違う特徴は（抽象）インタフェース・クラスであり（具象）実装クラスはＳＳＭ ＤＬＬ（図２１）とＳＳＰ ＤＬＬ（図２２）の間で分割される（されない）ことである。例えば、Ｋｅｙクラス２１１０の場合だと、ＳＳＭは一般に任意のＳＳＰの鍵がどのようなものであるべきかについての優先的な（インタフェース）知識を持っているが、ＳＳＰそれ自体はＳＳＭによって例えばＸＸＸＫｅｙクラス２２１０によって定義されるインタフェースに準拠したＫｅｙクラスの詳細な実装を供給する必要がある。しかしＫｅｙＰａｉｒクラス２１１４の場合、ＳＳＭはすでに実装についての詳細な知識を持っている−−これはＫｅｙ（それがどのようなものであっても）のペアで構成される。
【０１１８】
セキュリティ・サブシステムをブートする場合、例えば、Ｓｅｃｕｒｉｔｙクラス２１０２がランタイム時に最初にＣｏＣｒｅａｔｅされ、Ｓｅｃｕｒｉｔｙクラス２１０２はＳｅｃｕｒｉｔｙクラスのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）メソッドで次のようなことを行なう。第１に、Ｓｅｃｕｒｉｔｙクラス２１０２は例えばレジストリ（Ｒｅｇｉｓｔｒｙ）に保存されている構成情報を読み込む。
【０１１９】
次に、それぞれの構成された具象プロバイダＸＸＸＰｒｏｖｉｄｅｒ（レジストリから読み出したばかりの）のＰｒｏｇＩＤ（またはＣＬＳＩＤ）に基づいて、セキュリティ・クラスがＸＸＸＰｒｏｖｉｄｅｒ２２００のインスタンスをＣｏＣｒｅａｔｅし、ＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（Ｃｔｏｒはコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）の意味）へのポインタを得る。ＸＸＸＰｒｏｖｉｄｅｒクラスをＣｏＣｒｅａｔｅするこの動作は更にＸＸＸＰｒｉｖｉｄｅｒのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）にＸＸＸＰｒｏｖｉｄｅｒ２２００内部の抽象ＰｒｏｖｉｄｅｒクラスのオブジェクトをＣｏＣｒｅａｔｅして統合する。
【０１２０】
次に、いまＣｏＣｒｅａｔｅしたばかりのＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースを使って、Ｓｅｃｕｒｉｔｙクラス２１０２がＸＸＸＰｒｏｖｉｄｅｒのｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドをＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースから呼び出す。この特別なｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの名称／バージョン／情報／ｃｌｓｉｄ／サービス・データを、「ハードワイヤードな」静的数値変数の位置から統合Ｐｒｏｖｉｄｅｒオブジェクト内の非静的メンバー変数へ「アップロード」する（ｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの統合Ｐｒｏｖｉｄｅｒサブオブジェクトによってエクスポートされるなんらかのメソッドを呼び出すことでこれを完了する）。
【０１２１】
第４に、Ｓｅｃｕｒｉｔｙクラス２１０２は各種の構成された具象プロバイダを指すＩＰｒｏｖｉｄｅｒ＊の静的内部構成リストｓ＿ＰｒｏｖＬｉｓｔ［］を構築する。Ｓｅｃｕｒｉｔｙクラス２１０２は、Ｓｅｃｕｒｉｔｙクラス２１０２がこの時点まで使っていたＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒ＊インタフェースでＱｕｅｒｙＩｎｔｅｒｆａｃｅを呼び出すことで各ＩＰｒｏｖｉｄｅｒ＊を構築する。構成されたＳＳＰのリストｓ＿ＰｒｏｖＬｉｓｔ［］はＳｅｃｕｒｉｔｙクラス２１０２のｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを介してクライアントが利用できるようになる。
【０１２２】
アプリケーションは次のような方法でプロバイダ・アーキテクチャを実際に使用する。あるアプリケーションがＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクト上でｄｉｇｅｓｔ（）メソッドを呼び出して特定メッセージ（バッファ）のダイジェストを実際に計算したいと想定する。アプリケーションはＳＳＭで抽象エンジン・クラスを知っている（すなわちＳｅｃｕｒｉｔｙＳｖｃｓ．ｄｌｌのクラスのＣＬＳＩＤ）。これは作成中にこの情報へリンクされたためだが、現実のアルゴリズム実装が実際に存在するＳＳＰ内の具象エンジン・クラスについては優先順位（すなわち、ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌのクラスのＣＬＳＩＤ）を知らない。したがって、アプリケーションは抽象エンジン・オブジェクトを直接ＣｏＣｒｅａｔｅできるが、具象エンジン・オブジェクトは直接ＣｏＣｒｅａｔｅ できない。しかし、好適実施態様では、抽象エンジン・オブジェクトがｇｅｔＩｎｓｔａｎｃｅ（）と呼ばれるファクトリ・メソッドを有するクラス・ファクトリ・オブジェクトとして処理され、次のように、間接的に具象エンジン・オブジェクトを作成している。
【０１２３】
アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔクラス２１０６から純粋な抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅすることから開始する。このようなオブジェクトは具象エンジン・オブジェクトへ接続されないのでダイジェストを作成するためには使えない、すなわち主状態変数ｍ＿Ｅｎｇｉｎｅは値に０を持っている（副状態変数ｍ＿ＡｌｇＮａｍｅとｍ＿ＰｒｏｖＮａｍｅも同様）。いまＣｏＣｒｅａｔｅしたＩＭｅｓｓａｇｅＤｉｇｅｓｔ＊インタフェース２１０４を使って、アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔのｇｅｔＩｎｓｔａｎｃｅ（）メソッドを呼び出し、使いたいメッセージ・ダイジェスト・アルゴリズムの周知の名前を指定する。ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはファクトリ・メソッドで、次のステップを実行する。第１に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドがＳｅｃｕｒｉｔｙオブジェクトでｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを呼び出して現在構成されているプロバイダのリストをフェッチする。次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはいまフェッチしたばかりのＳＳＰのリストを使って、要求されたアルゴリズムをサポートする最初のＳＳＰが見つかるまで、好適な順番で各ＳＳＰのｇｅｔ（）メソッドを呼び出す。ＳＳＰのｇｅｔ（）メソッドはＳＳＰのｍ＿ＳｖｃＭａｐ［］を使用し、アルゴリズム名を具象エンジン・クラスＰｒｏｇＩＤにマッピングする。つまりこの例では、クラス２０２２のｇｅｔ（）メソッドが要求されたアルゴリズムをサポートしているＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ具象エンジン・クラスのＰｒｏｇＩＤを返す。
【０１２４】
次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはｇｅｔＩｎｓｔａｎｃｅ（）メソッドが呼び出されたＭｅｓｓａｇｅＤｉｇｅｓｔとは別に新しく抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅする。まず、この新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトはもう一つの純粋な抽象エンジン・オブジェクトだが、次のステップでｇｅｔＩｎｓｔａｎｃｅ（）メソッドは完全な／接続されたエンジン・オブジェクトへ（すなわちｍ＿Ｅｎｇｉｎｅフィールドを介してこれの内部に含まれる／作成される具象エンジンとあわせて「非純粋」抽象エンジン・オブジェクトに）変化させる。
【０１２５】
最後に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドを呼び出し、パラメータとして上記で呼び出したｇｅｔ（）オブジェクトから取得したＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ ＣＬＳＩＤ（またはＰｒｏｇＩＤ）を渡す。そのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドはクラス２１０４からＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉオブジェクトのインスタンスをＣｏＣｒｅａｔｅし、新しいＭｅｓｓａｇｅＤｉｇｅｓｔのｍ＿Ｅｎｇｉｎｅフィールドへ得られたＩＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ＊ポインタを格納する。
【０１２６】
つまり、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはアプリケーションへ完全に完成／接続したＭｅｓｓａｇｅＤｉｇｅｓｔエンジン・オブジェクトを返す。この時点で、アプリケーションはエンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドを呼び出してメッセージのダイジェストを計算する。（抽象）エンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドは具象エンジン・オブジェクトのｅｎｇｉｎｅＤｉｇｅｓｔ（）メソッドへの呼び出しを代理または転送して実際の作業を行なわせる。
【０１２７】
上記で説明した実施態様のソフトウェアによる実装は、有形の媒体例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤＲＯＭ、ＲＯＭメモリ、または固定ディスクなどに固定されるか、モデムまたは媒体上のその他のインタフェース装置を介してコンピュータ・システムへ転送可能な一連のコンピュータ命令を含む。媒体は光またはアナログ通信線を含みこれに限定されない有形の媒体としたり、マイクロ波、赤外線またはその他の電送技術を含みこれに限定されない無線技術で実装することができる。媒体はインターネットの場合もある。一連のコンピュータ命令は本発明に関して本明細書ですでに説明した機能の全部または一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用される多数のプログラミング言語で書けることが当業者には理解されよう。更に、このような命令は、現在または将来の、半導体、磁気、光、またはその他のメモリ装置を含みこれに限定されないなんらかのメモリ技術を用いて保存したり、あるいは現在または将来の、光、赤外線、マイクロは、またはその他の伝送技術を含みこれに限定されないなんらかの通信技術を用いて伝送される。このようなコンピュータ・プログラムは印刷物または電子文書を伴なう取り出し自由な媒体として、例えばシュリンクラップ包装ソフトウェアとして配布されたり、コンピュータ・システムに例えばシステムＲＯＭや固定ディスク上にプリロードされていたり、またはサーバまたは電子掲示板から例えばインターネットまたはワールド・ワイド・ウェブなどのネットワーク上で配布されることがあると想定される。
【０１２８】
本発明の代表的実施態様を開示したが、本発明の利点のいくつかを実現し本発明の主旨と範囲から逸脱しない各種の変化及び変更を加えることができることは当業者に明らかであろう。例えば、説明は特定のハードウェア・システム及びオペレーティング・システムを指向したものだったが、他のハードウェアやオペレーティング・システム・ソフトウェアを説明したそれと同じ方法で使用できることは当業者には明らかであろう。例えば特定の関数を実現するために使用された特定の命令などのその他の態様ならびに本発明の概念に対するその他の変更も付録の請求の範囲によって包含されることを意図している。
【技術分野】
【０００１】
本発明は安全なデータ交換トランザクションを提供するための方法及び装置に関連し、更に詳しくは、共同作業環境（以下、コラボレーティブ環境）における安全なデータ交換トランザクションを提供する方法及び装置に関する。
【背景技術】
【０００２】
現在の計算機アプリケーションはほとんどがシングル・ユーザ・システムである。例えば、従来の編集アプリケーションでは、一人のユーザがファイルを開き内容に変更を加えることができる。第１のユーザがファイルを開いている間に、第２のユーザがそのファイルを開こうとすると、第２のユーザはファイルを開くことができないか変更を加えることができないことになる。第２のユーザはファイルの一時的なコピー（以下、スナップショット・コピー）を取得することができる場合がある。しかしスナップショット・コピーは第１のユーザが作成したオリジナルのコピーに加えたそれ以降の変更は何も更新されない。つまり、第２のユーザはファイルの変更として表現された第１のユーザのアイデアを共有することができない。更に、第２のユーザはオリジナルのファイル内容の変更を行なうことができないので、ファイルの変更として表現されるそのユーザのアイデアを共有することができない。要するに、第１と第２のユーザはファイルの共同作業による（以下、コラボレーティブな）編集ができない。
【０００３】
本明細書で用いている術語であるコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）は複数クライアントがアイデアを共有できるようにする能力を意味する。この共有には一人のアイデアを他のメンバーに対して自動的に表明し、他のメンバーがそのアイデアを明示的に要求しなくても良いようにする能力を含む。コラボレーションは更にアイデアを送信するメンバーからのアイデアを自動的にそれぞれのメンバーが受信できるようにする能力も含む。つまり、最低限、コラボレーションは共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｅｆｆｏｒｔ）に参加しているメンバーの間での通信を意味する。この通信／コラボレーションは多くのモデルをもとにすることができる。「ブレーン・ストーミング型」セッションは制約されないコラボレーション・モデルである。一方、「ラウンド・ロビン」型モデルはそれぞれのメンバーがアイデアを表明するのに特定の順番を待つもので、制約型のコラボレーション・モデルである。
【０００４】
特許文献１に開示された一つのコラボレーション・システムでは、データ変更要求がユーザとの対話に対する応答として生成されすべてのコラボレータに接続されているトランスポンダ・ユニットへ送出される。トランスポンダはコラボレーションに参加しているユーザ全部に対してデータ変更要求をブロードキャストする。各ユーザはコラボレーション用データ（以下、コラボレーティブ・データ）のローカルなコピーを持ち、データ変更要求を受信してローカルなデータ・コピーへ要求された変更を加えるメカニズムを備える。すべてのデータ変更要求がトランスポンダを経由しなければならないため、データ変更要求はすべて同じ順番でそれぞれのコラボレータに受信されることになり、データの完全性が維持される。
【０００５】
コラボレーションは１台の計算機またはサーバで作業しているユーザ間でローカルに行なわれたり、ユーザそれぞれがネットワークに接続された計算機に向かっているようなネットワーク上で行なわれることもある。インターネットはこのようなネットワークの一つで、数百万のユーザ間での通信及び対話のためのダイナミックな公衆環境を作り出した。ビジネスにおいて、インターネットまた特にインターネット上で動作するワールドワイドウェブ・アプリケーションはベンダ／メーカ間、メーカ／ディストリビュータ間、ディストリビュータ／顧客間、その他の関係を再編成した。インターネット技術を企業内の機密ネットワークへ拡張すると、「イントラネット」あるいは「プライベート・インターネット」と呼ばれるようなものが、企業のディレクトリとネットワーク基盤を使用する従業員それぞれや作業グループの間で、新しい形態のドキュメント及び情報の共有を可能にした。
【０００６】
ワールド・ワイド・ウェブ（「ウェブ」）はその中核にサーバ・クライアント・アーキテクチャを有し個々のクライアント（すなわちウェブ・コンテンツのユーザ）はブラウザを通して、公衆ネットワーク上にあるサーバ（すなわち、インターネット・コンテンツ・プロバイダ）とインタフェースすることで、ウェブ・サイトからドキュメントを取得する。ブラウザはパーソナル・コンピュータがインターネット・ドキュメントを要求し、受信し（例えばダウンロードし）、解釈し、表示し、また一般的にはインターネットをナビゲーションできるようにするソフトウェア・プログラムである。ウェブ・サイトはドキュメントの集合体で、ドキュメントは一般にホームページやこれに関連しリンクされるドキュメントから構成され、クライアントからは離れたサーバ上に配置される。ドキュメントはコンパウンド・ドキュメントとすることができ、データ、グラフィックス、ビデオ、サウンド、及び／または他の種類のメディアや、他のドキュメントへのリンクも含められる。
【０００７】
基盤となるウェブ及びその他のインターネット技術は、パーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロトコル、インフラストラクチャの取り決め（例えば一元的資源指定子Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ ＬｏｃａｔｏｒまたはＵＲＬ）を含め、標準化が進んでいる。ＵＲＬはＷＷＷ上のすべてのドキュメント・オブジェクトについて所在アドレスを提供する。ＵＲＬはドキュメント・オブジェクトを択一的に指定しインターネット・プロトコルを使用するアクセス・アルゴリズムも定義することが多い。
【０００８】
インターネットを利用するため、インターネット・プロトコルに準拠した形でツールや資源が開発されており、これには電子メール（ｅ−ｍａｉｌ）などのアプリケーションを含む。電子メールは電子的な郵便で、これを用いてドキュメントを電子的に、選択したアドレスで送受信する。インターネット上での対話（ｉｎｔｅｒａｃｔｉｏｎ）のほとんどが「ドキュメント送受信」モデルに従う電子メールやその他のブラウザを使うメディアであると予想された。おそらくはそのモデルのため、ユーザは高次の権威者による介入なしに個人が他の個人の提供した文書にアクセスすることでインターネットを本質的に「ピアツーピア」であると見なすことが多い。
【０００９】
結果として、更に「ピアツーピア」的に動作する新しいコラボレーション・モデルが開発された。これらのモデルは「テレスペース」と呼ばれる共有プライベート空間にいるユーザ間の直接接続の上に構築される。各ユーザは「アクティビティ」と呼ばれるプログラムを持ち、これはパーソナル・コンピュータ・システムや、通信機器またはその他のネットワーク接続可能な装置で動作可能である。アクティビティ・プログラムは「デルタ」と呼ばれるデータ交換要求を生成することでユーザとの対話に応答する。アクティビティはまたデータ変更エンジンを備え、これがローカルなデータ・コピーを維持しており、デルタによって要求されたデータへの変更を実行する。デルタはダイナミクス・マネージャによって一人のユーザから別のユーザへと配布される。後者の形式のコラボレーション・システムは「通信マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ， Ｋｅｎｎｅｔｈ Ｇ． Ｍｏｏｒｅ， Ｒｏｂｅｒｔ Ｈ． Ｍｙｈｉｌｌ ａｎｄ Ｂｒｉａｎ Ｍ． Ｌａｍｂｅｒｔによる１９９９年７月１９日付け出願の特許文献２、「ダイナミクス・マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｄｙｎａｍｉｃｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ． Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け出願の特許文献３、「アクティビティ・ベースのコラボレーション用に装備した分散コンピュータ・システムにおいてデータ変更要求に優先順位をつけデータ完全性を維持するための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｐｒｉｏｒｉｔｉｚｉｎｇ ｄａｔａ ｃｈａｎｇｅ ｒｅｑｕｅｓｔｓ ａｎｄ ｍａｉｎｔａｉｎｉｎｇ ｄａｔｅ ｃｏｎｓｉｓｔｅｎｃｙ ｉｎ ａ ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け出願の特許文献４に詳細に記載されている。
【００１０】
インターネットは、ユーザに娯楽と有用な通信方法を提供する点でダイナミックかつフレキシブルだが、ユーザのニーズ全部には適合しない。例えば、インターネットは各種のハードウェアとソフトウェアで広範囲のユーザを接続する能力を有することから理想的にはコラボレーションに適したものであろう。しかし、インターネットのセキュリティは希望するのとは程遠い。インターネット上で様々な人数のユーザへメッセージを送信できるが、これらのメッセージは代表的にはサード・パーティのウェブ・サイトを経由しここで通信を傍受したり機密性を侵害することが可能である。結果として、ユーザがインターネット経由でいっそう対話する一方、例えば複数媒体（電話、ファクシミリ、ホワイトボード）や、複数時刻（リアルタイム、翌日配達郵便（ｏｖｅｒｎｉｇｈｔ ｍａｉｌ））及びその他の通信告知手段など従来の安全な方法でインターネット「以外で」対話を続けることになる。
【００１１】
共有プライベート空間にいる個人間及び中小グループ間でコラボレーティブな通信やその他の共有及び同時的アクティビティを安全なものにするようにインターネットを拡張するのが望ましい。このような対話は参加者のパーソナル・コンピュータ間またはその他のネットワーク接続可能な装置間で望ましくは瞬間的、直接的、かつ機密に行なわれるべきである。また様々なリモートサイトにいるユーザが安全に通信でき、安全な通信リンクの構築やセキュリティ・システムの維持にユーザの広範囲の関与を必要としないような技術を提供するのも望ましい。また安全なトランザクションを提供する上で関係する「オーバヘッド」を最小限にまで減らして通信量（以下、スループット）と動作速度を改善するのも望ましい。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許第５，７８１，７３２号明細書
【特許文献２】米国特許第６，６４０，２４１号明細書
【特許文献３】米国特許第６，４４６，１１３号明細書
【特許文献４】米国特許第６，８５９，８２１号明細書
【発明の概要】
【００１３】
本発明の図示した実施態様の一つによれば、異なるセキュリティ・レベルを提供してユーザが彼ら自身の通信のセキュリティ・レベルを決定できるようにする。ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。これ以外に、セキュリティ関係のオーバヘッドの増加をもたらすもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。
【００１４】
好適実施態様において、鍵管理のオーバヘッドを減少させるため、同一の物理鍵を暗号化鍵とメッセージ認証鍵に使用する。
【００１５】
一つの実施態様において、セキュリティ・レベルはテレスペースが作成されてテレスペースの寿命がある間は固定されたままである。テレスペースでは、セキュリティ・レベルは全くセキュリティがない状態からテレスペースのメンバーと部外者との間のセキュリティ、更にテレスペースのメンバーのペア間でのセキュリティまで範囲がある。
【００１６】
別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用する。
【００１７】
更に別の実施態様において、中程度または高度なセキュリティ・レベルを有するテレスペースのメンバーはウィスパー（ｗｈｉｓｐｅｒｓ）と呼ばれテレスペースの他のメンバーに対しても機密化される機密通信で通信することができる。
【図面の簡単な説明】
【００１８】
【図１】図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図である。
【図２】図２、はデルタを用いてローカルなデータ・コピーを更新する代表的なコラボレーション・システムの略ブロック図である。
【図３】図３は、グループ、トライブ、またそれらを保護するために使用される暗号化及び認証鍵を示す略ブロック図である。
【図４】図４は、低レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図５】図５は、認証／完全性モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図６】図６は、認証／完全性／機密モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図７】図７は、認証／完全性モードで動作する高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図８】図８は、デジタル署名と証明書の作成及び確認を示す略ブロック図である。
【図９】図９は、既存のグループへの新規メンバー（招待者）の追加を示す略ブロック図である。
【図１０】図１０は、既存のグループへ新規メンバーを追加するために議長（ｃｈａｉｒ）を使用するような代表的ルーチンのステップを示すフローチャートである。
【図１１】図１１は、議長から招待者へ送信される招待メッセージの内容を示す略図である。
【図１２】図１２は、招待者から議長へ送信される受け入れメッセージの内容を示す略図である。
【図１３】図１３は、グループの既存のメンバー全員へ議長から送信されて新規メンバーが追加されたことを告知する新規メンバー追加デルタの内容を示す略図である。
【図１４】図１４は、議長から新規に追加されたメンバーへ送信されてテレスペース・データのメンバーを告知するメッセージの内容を示す略図である。
【図１５】図１５は、招待者が招待に応答するために使用できる代表的ルーチンのステップを示すフローチャートである。
【図１６】図１６は、招待者からの受け入れメッセージに応答するために議長が使用できる代表的ルーチンのステップを示すフローチャートである。
【図１７】図１７は、新規メンバー追加デルタに応答するために既存のメンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１８】図１８は、テレスペース情報を搬送する議長からのメッセージに応答するために新規追加メンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１９】図１９は、再キーイング情報が「ピギーバック」したデルタ・メッセージの内容を示す略図である。
【図２０】図２０は、本発明のセキュリティ・システムの好適な実装の全体的アーキテクチャを示す略ブロック図である。
【図２１】図２１は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル抽象クラスを示す略ブロック図である。
【図２２】図２２は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル具象クラスを示す略ブロック図である。
【図２３】図２３は、視覚的確認のための情報を表示しその情報を受け入れるかまたは破棄するようにユーザに要求するダイアログ・ボックスの画面表示を示す略図である。
【発明を実施するための形態】
【００１９】
図１は代表的なコンピュータ・システム１００の従来のシステム・アーキテクチャを示したもので、これに開示された本発明を実装することができる。ただし図１の代表的なコンピュータ・システムは説明目的のみで議論するもので本発明の制限と見なすべきではない。以下の説明では特定のコンピュータ・システムを記述する際に共通に使用される術語を参照することがあるが、記載される概念は図１に図示したものとは異なるアーキテクチャを有するシステムを含めた他のコンピュータ・システムに等しく適用される。
【００２０】
コンピュータ・システム１００は従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報記憶のためのランダムアクセス・メモリ（ＲＡＭ）１１０、及び永久的情報記憶のためのリードオンリー・メモリ（ＲＯＭ）を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５はバス１３０を制御するために設けてあり、割り込みコントローラ１３５は他のシステム要素からの各種割り込み信号を受信し処理するために使用される。
【００２１】
大容量記憶はディスケット１４２、ＣＤＲＯＭ１４７、またはハードディスク１５２によって提供される。データとソフトウェアは取り出し可能な媒体例えばディスケット１４２やＣＤＲＯＭ１４７を介してクライアント・コンピュータ１００と交換できる。ディスケット１４２はディスケット・ドライブ１４１へ挿入でき、このディスケット・ドライブ１４１はコントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤＲＯＭ１４７はＣＤＲＯＭドライブ１４６へ挿入でき、ＣＤＲＯＭドライブ１４６はコントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は固定ディスク・ドライブ１５１の一部であり、これはコントローラ１５０を介してバス１３０へ接続されている。
【００２２】
コンピュータ・システム１００へのユーザ入力は様々な装置から提供される。例えば、キーボード１５６とマウス１５７はキーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６はマイクロホンとスピーカの両方として機能するもので、オーディオ・コントローラ１９７によってバス１３０へ接続されている。その他の入力装置例えばペン及び／またはタブレットや音声入力用マイクロホンなどがバス１３０と適当なコントローラを介してクライアント・コンピュータ１００へ接続できることは当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリ・アクセスを実行するために提供される。視覚表示はビデオ・ディスプレイ１７０を制御するビデオ・コントローラ１６５によって生成される。
【００２３】
コンピュータ・システム１００はクライアント・コンピュータ１００をバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用する。
【００２４】
コンピュータ・システム１００は一般にオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。
【００２５】
図２は略ブロック図の形で代表的なコラボレーション・システムの構成を示す。図２はネットワーク２１６へ接続された２台のコラボレーティブ・ワークステーション２００、２０２を示す。ワークステーション２００、２０２のそれぞれは図１に示したようなコンピュータ・システムとすることができ、ネットワーク２１６はプライベート・コンピュータ・ネットワーク例えばＬＡＮやＷＡＮ、あるいは公衆コンピュータ・ネットワーク例えばインターネットとすることができる。これ以外に、ワークステーション２００、２０２は同一のコンピュータ（図示していない）上に構成することができ、この場合２つの端末間の通信はそのコンピュータに対してローカルなものとなる。
【００２６】
好適実施態様において、端末２００、２０２のそれぞれは共同作業を実行するデータのローカルなコピー２０４、２１０をそれぞれ保持している。それぞれのローカルなデータ・コピー、例えばデータ・コピー２０４はこれに対応する「ダイナミクス・マネージャ」２０６と呼ばれるソフトウェア・プログラムによって管理される。同様に、データ・コピー２１０はこれに対応するダイナミクス・マネージャ２１２によって管理される。特定のコラボレーション装置を説明の目的で議論するが、他のコラボレーション装置も精神と範囲において本発明の原理から逸脱することなく使用できることが当業者には明らかであろう。
【００２７】
ダイナミクス・マネージャ２０６は「デルタ」と呼ばれる一つまたはそれ以上のデータ変更要求を含む自己内包型データユニットの受信に応答してこれのローカル・データ・コピー２０４を変更し更新する。データ変更要求はデータの希望通の変更に関してダイナミクス・マネージャやその他のコンポーネント（図示していない）への通知または催促である。デルタは例えばマネージャ２０６などのダイナミクス・マネージャによって、ユーザとの対話に応答して作成されるもので、対応するローカル・データ・コピー２０４と、ネットワーク越しに同じコラボレーティブ・セッションに参加しているコラボレータに属する他のコンピュータ上のローカル・データ・コピーとの両方を更新するために用いられる。
【００２８】
デルタは制御情報を提供するへッダ部分と要求が関係するデータについての情報を提供するペイロード部分とを含む特定のフォーマットを有する。個々のデルタは一つまたはそれ以上のペイロードを有することができる。多数のペイロードが使用されるような場合、以下で詳細に説明するように、それぞれが独自の装置機能またはユーザの役割を有する特定のコラボレーション・メンバーを対象とすることができる。
【００２９】
ダイナミクス・マネージャ２０６によって生成されたデルタが他のコラボレータに送信される場合、ダイナミクス・マネージャ２０６は通信マネージャ２０８と相互作用する。同様に、ダイナミクス・マネージャ２１２は通信マネージャ２１４と相互作用する。通信マネージャ２０８は内向きと外向きのデルタを適当な宛先へ配送するメカニズムである。好適実施態様において、通信マネージャはコンピュータで実行可能なプログラムとして実装することができ、このプログラムが別のリモート・パーソナルコンピュータまたは別の形のネットワーク接続可能な装置へネットワーク２１６上で送信するため通信マネージャ２０６によって開始されたデルタを配送し、またネットワーク２１６上で受信したリモートで生成されたデルタをダイナミクス・マネージャ２０６へ配送する。
【００３０】
一般に、通信マネージャ２０８、２１４はダイナミクス・マネージャ２０６、２１２によって生成された全デルタがコラボレーションに参加している全ユーザによって受信されるように構成される。それぞれのデルタは内部シーケンス番号を含みそれぞれのコラボレータのダイナミクス・マネージャは全部のデルタがいつ受信されたかを決定できるようにしてある。別のコラボレータからのデルタはそれぞれのコラボレータへ多数の違う経路を通って送信されることがあるので、デルタは生成された順序と同じ順序で到着するとは限らない。しかし、それぞれのコラボレータによって全デルタが受信され内部シーケンス番号を使って正しい順序でデルタを適用できる。したがって、それぞれのコラボレータによって保持されているローカル・データ・コピーは、全部のデルタで更新されると、コラボレーションの他のメンバーによって保持されているローカル・データ・コピーと一致することになる。
【００３１】
特定のコラボレーションに参加しているコラボレータの間での機密性を維持することが望ましい。これはデルタが公衆ネットワーク例えばインターネット上に送信される場合にとくに言えることである。情報のセキュリティにとって重要な３つの基本概念が存在する。その第１は認証で、これはデータ受信者がデータ作成者（ｄａｔａ ｓｏｕｒｃｅ）の同一性を知っており信用できることを保証するものである。第２は完全性で、データが転送中に変更されなかったことを保証するものである。完全性はデータ作成者以外のものによってデータを書き込むことができないことまた既知の作成者から到着したものであることを実効的に保証する。データ完全性は不正なデータの生成または「なりすまし」による第三者からの攻撃を防止する。最後のセキュリティ概念は機密性で、これは転送中のデータがデータ作成者とデータ受信者以外の第三者によって読み取ることができないことを保証するものである。機密性は第三者によるデータの読み取りまたは「盗聴」による攻撃を防止する。
【００３２】
前述したように、セキュリティはコラボレータが一つまたはそれ以上のアクティビティに参加して項目を共有したり、アクティビティの結果がユーザのパーソナル・コンピュータ上にあるいは他の形のネットワーク接続可能な装置上に永続的に保存されるような仮想空間に基づいている。仮想空間は「テレスペース」または「グループ」と呼ばれるもので各ユーザの装置の中で同期が保たれる。図示したセキュリティ／モデルによると、テレスペースのセキュリティは、テレスペースを形成して、メンバーを受け入れ、更にメンバーシップが安定したあとで「全体の」セキュリティとしてほとんどのユーザが体験するものである。これは安定状態デルタ・プロトコルと呼ばれグループ・メンバー間に渡されるデルタに含まれる情報の認証、完全性及び機密性に関連する。図３は５人のメンバーＭ０、Ｍ１、Ｍ２、Ｍ３、Ｍ４（３０２〜３１０）からなるテレスペースまたはグループ例３００の模式図である。各テレスペース３００内には一つまたはそれ以上のトライブまたはサブグループが存在する。図３には、３人のメンバーＭ２、Ｍ３、Ｍ４（３０６、３０８、３１０）からなるトライブ３１２が図示してある。
【００３３】
各メンバー３０２〜３１０はその内部に「プロトコル・エンジン」（それぞれエンジン３０３〜３１１）を有し、これは他のメンバーへセキュリティ・メッセージを送信しセキュリティ情報を操作するアプリケーション・プログラムである。
【００３４】
テレスペース３００とトライブ３１２において情報は一つまたはそれ以上の鍵により保護される。これは、Ｋとして示してある暗号化鍵と、Ｌで示したメッセージ認証／完全性コード（ＭＡＣ）鍵である。Ｋ及びＬ鍵は対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｉｐｈｅｒ）用の従来の鍵でありテレスペース全体への広がり（スコープ）を有する。本発明のシステムはブロック暗号化（ｂｌｏｃｋ ｃｉｐｈｅｒｓ）とストリーム暗号化（ｓｔｒｅａｍ ｃｉｐｈｅｒｓ）の両方を用いることができるが、メッセージ間での状態は維持されない。つまり一つのメッセージから次のメッセージへセキュリティ暗号ストリーム状態を維持するためには通信しているエンドポイントが必要とされない。この方法では、一時的な通信の中断が発生した場合にも再同期が必要とされない。
【００３５】
ブロック暗号化はカウンター・モードにおいて使用する度に必ず新しく無作為生成される初期化ベクトルを使って使用される。初期化ベクトルは暗号のブロック長と等しい長さを有し従来の方法による典型的なへッダ攻撃を妨害（ｔｈｗａｒｔ）するために使用する。ストリーム暗号化はブロック・モードにおいて初期ベクトルと鍵を組み合わせる、例えば排他的論理和演算により、ついですべてのメッセージで鍵文字列を再初期化することで使用される。この場合、初期ベクトルは鍵長と等しい長さを有する。初期ベクトルは一般に機密性保護されないしまたは認証／完全性の保護もされない。
【００３６】
更にすべての鍵がなんらかの種類の陳腐化メカニズム例えばタイムアウトを関連させるか一定数のメッセージまたはバイト数を保護すると想定する。このメカニズムはテレスペースによって決定されるローカル・ポリシーの一種で以下で説明するいずれのプロトコルでも送信する必要はない。
【００３７】
ＫＧ／ＬＧで示したグループ鍵は（それぞれ）暗号化／ＭＡＣ鍵で、グループ３００の全メンバーによって共有される。これらの鍵は第三者（グループ外の者）による攻撃からデルタに含まれる情報の機密性／完全性をそれぞれ保護するために使用される。同様に、ＫＴ／ＬＴで示したトライブ鍵は暗号化／ＭＡＣ鍵で、トライブ３１２の全メンバーによって共有される。これらの鍵はトライブ以外のグループ・メンバーや第三者による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。
【００３８】
更にＫ０１／Ｌ０１で示してある対になった鍵はメンバーＭ１とＭ２が共有しかつ他のグループ・メンバーの誰も共有していない暗号化／ＭＡＣ鍵（それぞれ）Ｍ０とＭ１で、Ｍ０とＭ１の間で双方向に通信を保護するために使用される双方向鍵である。これらの鍵はグループ・メンバーＭ２、Ｍ３、Ｍ４による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。同様に対になった鍵Ｋｉｊ／Ｌｉｊは別のメンバーの組み合わせＭｉとＭｊの間で交換される情報を他のグループ・メンバーによる攻撃から保護するために使用される。
【００３９】
テレスペース内で安定状態セキュリティは５段階のレベルの一つに組み込まれることになるが、そのレベルはテレスペース３００の作成者がテレスペースを作成する時点で選択できる。５レベルには何らの鍵も使用する必要がない低レベル・セキュリティを含む。このレベルは全く暗号セキュリティを提供しない。次のレベルは１対の鍵（ＫＧ／ＬＧ）をグループの全メンバーに対して使用する中程度レベルのセキュリティである。このレベルでは、ＫＧ／ＬＧ鍵のうちのＭＡＣ鍵ＬＧだけを使ってデルタを保護することにより認証／完全性が提供できる。同様に、認証／完全性及び機密性はＫＧ／ＬＧ鍵の両方を使ってデルタを保護することで提供できる。
【００４０】
次のレベルは高レベルのセキュリティで、グループ鍵ＫＧ／ＬＧと鍵ペアＫｉｊ／Ｌｉｊの組み合わせを使用する。認証／完全性だけが要求される場合にはＭＡＣ鍵のペア（Ｌｉｊ）だけを使用してデルタを保護し、グループ鍵（ＫＧ）は使用しない。これ以外に、認証／完全性／機密性が要求される場合にはグループ暗号化鍵ＫＧとＭＡＣ鍵ペアＬｉｊを使用してデルタを保護する。
【００４１】
中レベルと高レベルのセキュリティ・レベル双方で、暗号化鍵（Ｋｉｊ）とＭＡＣ鍵（Ｌｉｊ）のペアを使用してグループ鍵またはトライブ鍵（ＫＧ／ＬＧまたはＫＴ／ＬＴ）の再キーイングを行なう。
【００４２】
以上のレベルやモードはグループ（テレスペース）全体に適用可能であり、また全トライブ（サブグループ）にも同様に適用可能である。テレスペース内のトライブ全部がテレスペース自体と同一の「全体的セキュリティ」を有するので、グループに対して前述したレベルやモードは、前記のグループ鍵ＫＧ／ＬＧをトライブ鍵ＫＴ／ＬＴで置き換えればトライブに適用できる。
【００４３】
図４はグループ・メンバー間に情報を転送するのに使用する「デルタ」の内容を示す。各デルタはメッセージ・へッダ４００からなり、これにはセキュリティ・システムの特定の実装に依存する情報を含む。この情報にはプロトコルのバージョン番号を含められるので、ここにコラボレーション・システムとセキュリティ・サブシステム両方のバージョン番号を含められる。メッセージ・へッダ４００はメッセージ・フラグ種別またはタグＩＤも含み、これはメッセージの種類が異なるごとに異なる識別子である。メッセージ・へッダに含めることができる他の情報としては、構造化シーケンス番号がある。この番号はテレスペースのスコープを有する部分順列シーケンス番号で、そのスコープ内でメッセージの送信者とメッセージそれ自体の特定インスタンスとを論理的に同定する。
【００４４】
へッダ４００は機密を保護することができないが要求されるセキュリティ・レベルによっては実際にグループ・メンバー間に送出されるペイロードまたは情報を含むアプリケーション・データ４０２と全く同様に認証／完全性を保護する必要がある場合がある。例えば図４に図示してあるようなデルタが符号化される方法は希望するセキュリティ・レベルによって変化する。例えば、暗号としての意味でセキュリティを何も保証しない「低レベル」セキュリティ・モードでは、デルタは図４に図示したように送信され、へッダ情報４００がペイロード４０２よりも先に送信されるのが望ましいが、へッダとペイロードの順序は本発明の動作にとって重要ではない。この場合、第三者（非グループ・メンバー）がデルタ情報４０２を読み取るまたは盗聴でき、またデルタを書き込んだり真似たり、または「なりすます」ことができる。
【００４５】
前述の認証／完全性モードで動作する「中レベル」セキュリティ・システムの場合、デルタ情報は図５に図示したように保護される。更に詳しく説明すると、それぞれのデルタについて、へッダ情報５００が送信され、それに続けて鍵バージョン番号５０２、平文データ５０４、更に認証子５０６が送信される。ここでもこれらの要素の順序は重要ではない。認証子はデータ５０４の認証／完全性を保護しグループ・メンバーによって送信されたメッセージであることを保証するＭＡＣコード５０６とすることができるが、これはグループ認証鍵ＬＧを知っているのはグループのメンバーだけだからである。別の実施態様において、メッセージ認証子として公開鍵署名認証子を使用することもできる。この場合、メッセージ認証子５０６はハッシュして連結したへッダ及びデータの公開鍵署名で構成する。
【００４６】
好適実施態様において、鍵バージョン番号は２つの部分を有しており、これは「鍵識別子ＫｅｙＩｄｅｎｔｉｆｉｅｒ」と呼ばれるテレスペース全体で使われる独自の文字列と、「鍵バージョンＫｅｙＶｅｒｓｉｏｎ」と呼ばれるインクリメンタルなシーケンス番号である。鍵識別子はテレスペースの別のメンバーが独自に生成する鍵同士を識別するために必要とされる。一方のメンバーが、他方のメンバーも新しい鍵を生成していることについて知らないので、鍵識別子は鍵を個別に識別できるようにする。鍵バージョンは古い鍵、現在の鍵、新しい鍵を識別するために必要とされる。安定状態では、メンバーは鍵識別子の値は異なるが鍵バージョンの値が同じ一組の鍵を使用することになる。メンバーは現在の鍵バージョンの値よりも鍵バージョンの値が小さい「古い鍵」を削除することができる。
【００４７】
好適な実装において、ＭＡＣコード５０６は、最初にデータ５０４と連結したへッダ５００をハッシュし、次にハッシュの結果を従来のメッセージ認証アルゴリズムに沿って保護する。中間ハッシュ関数を使用して後述するような高セキュリティ・バージョンに沿った方法でＭＡＣコードを作成する。また従来のＭＡＣアルゴリズムを使用してグループ認証キーＬＧで単純にへッダとデータを保護すれば、中間ハッシュ関数を使用せずにこのモードを実装することも可能である。前述のように、認証／完全性モードにおいて動作する中レベルのセキュリティ・システムは、第三者が読んだり盗聴できるがグループ・メンバーだけが他のグループ・メンバーのデルタに書き込み、真似（ｉｍｐｅｒｓｏｎａｔｅ）または成りすまし（ｓｐｏｏｆ）できるようなセキュリティ・システムを作成する。
【００４８】
認証／完全性／機密性モードで動作する中レベルのセキュリティ・システムは図６に図示してあるようにデルタのデータを保護する。更に詳しく説明すれば、デルタは鍵バージョン番号６０２及び初期ベクトル６０３の付いたへッダを、データ６０４及びメッセージ認証コード６０６とともに送信することで伝達される。しかし、この場合、データ６０４は暗号化されている。このプロトコルはグループ暗号化鍵ＫＧで暗号化することでデルタ・データの機密性を保護しておりグループ認証子６０６による完全性と認証の保護が継続する。データ６０４は従来の暗号化アルゴリズムを用いてグループ暗号化鍵ＫＧで暗号化され、暗号化されたデータは初期ベクトルと連結される。ここでも認証またはＭＡＣコードは好適実施態様においてへッダと平文データの連結をハッシュ化してからグループ認証鍵ＬＧでハッシュ情報を符号化することにより形成されている。またデータとへッダ及びデータのハッシュの連結をひとつの暗号化キーＫＧで暗号化してからその結果をへッダ、鍵バージョン番号、初期ベクトルと連結することでこのモードを実装することも可能である。後者の暗号化は機密性と認証／完全性を両方とも保証し、２つの鍵ＫＧとＬＧの間で機密性及び認証・完全性の責任を分担する別々のＭＡＣ部分を使用しなくてすむ。図６に図示した実装を実際に使用して後述する高セキュリティ・モードに沿った実装を行なうことができる。
【００４９】
認証／完全性モードで動作する「高レベル」セキュリティ・システムにおいてデルタ・データは図５に図示した構成または図７に図示した構成のどちらかを用いて保護できる。このシステムで使用されるプロトコルは平文デルタ情報を送信するが、認証／完全性を保証するため、シングルターゲットの秘密鍵多重認証子か公開鍵署名認証子のいずれかを使用する。
【００５０】
シングルターゲット秘密鍵多重認証子の場合、図５に図示した構成を使用する。更に詳しく説明すれば、へッダ情報５００は鍵バージョン５０２、暗号化していないデータ５０４、メッセージ認証子５０６とともに送信される。しかし、この場合、鍵バージョン番号５０２は送信者と受信者全部との間の鍵バージョンのすべてを連結したもので構成する。同様に、メッセージ認証子５０６は送信者とそれぞれの受信者との間の個別のメッセージ認証子を連結したもので構成する。それぞれのメッセージ認証子は認証鍵で保護されるが、この認証鍵は送信者と受信者との間でのみ使用されるものである（Ｌｉｊ鍵の一つ）。
【００５１】
更に、好適実施態様では、中間ハッシュをメッセージ認証コードに使用する。更に詳しく説明すると、へッダとデータは連結され、ハッシュされ、更に適当な認証鍵によって保護される。この場合、中間ハッシュは認証鍵それぞれに対してへッダとデルタ全体を再ハッシュするのを避けるために使用している。へッダとデルタをハッシュしたら、適当な認証鍵でハッシュした情報を単純に保護することでこのハッシュを複数回使用できる。
【００５２】
別の実施態様では、公開鍵署名認証子をメッセージ認証コードとして使用する。この構成が図７に図示してある。この構成では、へッダ情報７００が最初に送信され、これに暗号化されていない（Ａ／Ｉモード）または暗号化された（Ａ／Ｉ／Ｃモード）データ７０２が続く。メッセージ認証子コード７０４はハッシュし連結したへッダとデータの公開鍵署名から構成される。
【００５３】
認証／完全性／機密性モードで動作する高レベルセキュリティ・システムは図６と図７に図示したデルタ構成でデータを保護する。基本的にこれは図５と図７に図示してある認証／完全性モードと同じであるが、グループ暗号化鍵ＫＧでデルタ・データが暗号化され図６の場合の初期ベクトルと連結される点で異なっている。
【００５４】
デジタル署名またはデジタル証明書を生成して使用するメカニズムが図８に図示してある。データ８００のデジタル署名を生成するためには、多数の一般的に周知のハッシュ・アルゴリズムの一つを用いて、ステップ８０２に示してあるようにデータ８００のハッシュ値を計算する。ハッシュしたデータはステップ８０４に示したように（暗号化と同様の演算で）公開鍵／秘密鍵ペアのうちの秘密鍵を用いて署名される。その結果がデジタル署名８０６である。更に、データがユーザのＩＤまたは公開鍵に関係する場合、（署名ではなく）データはデジタル「証明書」と呼ばれる。
【００５５】
デジタル署名を使用するには、図８で破線より下に示してあるように有効化手順を実行する。更に詳しく説明すると、ハッシュしたデータの確認（復号に似た動作）のために公開鍵／秘密鍵ペアのうちの公開鍵を使用する署名確認アルゴリズム８１４へ、デジタル署名が矢印８１２で示したように提供され、また証明書が矢印８１８で示したように提供される。データ８００それ自体は矢印８０８で示したようにハッシュ・アルゴリズム８１０へ提供される。このハッシュ・アルゴリズムはデジタル署名を生成するために使用したハッシュ・アルゴリズム８０２と同一のものである。囲み８１６に示したように、データの再ハッシュが確認したハッシュ・データと比較される。結果が同一であれば、確認したハッシュ・データは正しい、すなわちデータは正しく（ａｕｔｈｅｎｔｉｃａｌｌｙ）署名に関連している。
【００５６】
機密グループを形成する手順が模式的に図９に図示してありそのステップが図１０に図示してある。図９に図示してあるように、グループ９００は議長９０２とその他のＮ−１人のメンバーで構成され、そのうち３人がメンバー９０６、９０８、９１０として示してある。グループ９００の形成は議長９０２によって管理され、議長は新しいメンバーを招待して追加する権限を与えられたメンバーである。図示した手順によれば、招待者９０４は初期認証の後でグループ９００へ追加される。以下の議論では認証及び完全性による最高セキュリティ・モードに焦点を当てて説明する。その他の意図されるモードはこのモードから派生させることができる。
【００５７】
加入手順はステップ１０００から始まりステップ１００２に進む。ステップ１００２では、議長９０２が招待されることになる人９０４へ招待メッセージを送信する。このメッセージは図９の矢印９１２で模式的に示してある。このメッセージの内容は図１１に示してある。メッセージはへッダ１１００と、これに続く招待者の名前１１０２から構成され、この名前はＵＲＬやその他の識別情報とすることができる。へッダの順序は本発明の原理から逸脱することなく反転できる。招待者の名前に続くのが署名済み招待「ナンス」（ｎｏｎｃｅ）１１０４である。署名済みナンスは議長によって生成されたタイムスタンプのハッシュ、議長９０２の名前／ＵＲＬ、招待者９０４の証明書（入手可能な場合）、テレスペースの名前／ＵＲＬ、署名つきナンスが発生することが考えられる別の状況を識別するために使用されるタグである招待「オプコード」（Ｏｐｃｏｄｅ）を含む署名データである。
【００５８】
一般的に言って、ナンスはプリンシパルＡが生成してプリンシパルＢへ送信するもので時間とともに変化するパラメータであり、これは任意の状況で一回だけ使用されるものである（例えば、本明細書で説明している招待プロトコルを介してＡがＢを招待する場合など）。実際に、ナンスは状況を定義する、言い換えればプロトコル動作の同時性を保証して再生（ｒｅｐｌａｙ）及びインターリーブ攻撃（ｉｎｔｅｒｌｅａｖｉｎｇ ａｔｔａｃｋ）を防止するために使用される。ナンスは秘密にしなくても良く、１回限りの独自なものであれば良い。各種システムで使用されるナンスの典型的な例としては次のようなものがあげられる：衝突しない乱数、タイムスタンプ（十分に信頼できるクロックを備えたシステム、特に信頼できる分散時刻同期プロトコルの存在下ではほぼ理想的である）、シーケンス番号。好適実施態様ではタイムスタンプが使用されている。
【００５９】
本明細書の状況で重要なことは、プロトコルの実行の全部において、ナンスが（暗号学的な確実性の範囲で）絶対に（ローカル・ポリシーで決定されるなんらかの時間的制約の中で）反復できないことである。これは例えば自分が発行したナンス／招待を（プロトコルの実行に関する他の情報とともに）、不揮発記憶に、ローカル・クロックに合わせてある程度の期間（ローカル・ポリシーによって変化する）、メンバーが記憶しておくことで実現可能で、この時刻以降はナンス情報を破棄してプロトコルの実行を中断させなければならない。
【００６０】
署名つきナンス１１０４に続くのは暗号データ１１０６で、これはこのメッセージで使用されるセキュリティ状態情報である。この情報は議長が選択し受信者がメッセージを正しく解釈できるようにするために必要である。更に詳しくは後述するようなワンタイム鍵で情報を暗号化するのに使用したアルゴリズムの名称の文字列を含む。またメッセージ受信者がメッセージを処理するのに必要なその他なんらかの情報、例えば鍵の長さ、ラウンド数、使用したハッシュ・アルゴリズムの名称、鍵ジェネレータ・アルゴリズムの名称、なども含む。
【００６１】
暗号データ１１０６に続くのは、公開鍵暗号化アルゴリズムに基づいてあらかじめなんらかの合意が得られている招待者の公開鍵で暗号化したワンタイム鍵情報１１０８である。ワンタイム鍵は対称暗号化用の鍵で後述するように招待情報を暗号化するために一回だけ使用される。
【００６２】
鍵情報に続くのが招待情報１１１０で、これはワンタイム鍵で暗号化されている。招待情報も前述したように議長によって生成されたタイムスタンプを含み初期ベクトルと連結できる。招待情報はテレスペース名／ＵＲＬを含むアプリケーション・データで招待者９０４に招待を発行したアクティビティの種類について通知する。これは特に、議長９０２によって権限を委譲（ｍａｎｄａｔｅｄ）されたものとしてテレスペース内で使用しなければならない暗号情報（例えば前述の低／中／高レベル、Ａ／Ｉ／Ｃモード）を含む。このようにすると、招待者には参加するように招待されているテレスペースのセキュリティ特性が招待者に通知され、例えば招待者は参加しないと決定することができる。招待者の証明書が不明な場合、暗号化したワンタイム鍵１１０８を無視しタイムスタンプと招待情報１１１０を暗号化しないで送信する。
【００６３】
招待情報１１１０に続くのはへッダ情報１１００、招待ナンス１１０４、暗号化していないワンタイム鍵（メッセージに含まれる場合）、暗号データ１１０６、暗号化していない招待情報（タイムスタンプなし）のハッシュに対する議長の署名である。この署名は議長の証明書に対して示された情報の全部を結合するもので、議長の証明書は招待者のローカルな公開鍵証明書有効化ポリシーを介して議長に結び付けられている。
【００６４】
送信される情報の最後の部分１１１４は議長の証明書で、議長の名称（ＵＲＬ／ペルソナ）、議長の公開署名確認鍵、及びその他の情報例えば公開鍵アルゴリズム識別子、暗号化公開鍵、などが含まれ、これらすべてが（一つまたはそれ以上の）なんらかの「信頼できる」認証局の署名を介して相互に結合されている。証明書は周知のまたは少なくとも招待者に識別可能ななんらかの証明書フォーマットにフォーマットされる。このフォーマットは公開鍵による証明書（ここで証明書認証局は周知の認証局の階層の内部に組み込まれている）、またはＰＧＰやＳＤＳＩなどを使用した「信頼の輪証明書」（ｗｅｂ−ｏｆ−ｔｒｕｓｔ ｃｅｒｔｉｆｉｃａｔｅ）、あるいは更に単純にこの目的のためだけにその場で構成した自己署名証明書であっても良い。招待者が証明書を頼れる「信頼度」は招待者のローカル公開鍵証明書有効化ポリシーに依存する。
【００６５】
このメッセージを受信すると、招待者は図１５に図示してあるフローチャートに概略してあるステップをとる。招待者の手順はステップ１５００から始まってステップ１５０２へと進み、ここで招待者が暗号データ１１０６を調べてメッセージの暗号化に使用されているアルゴリズムを知る。次にステップ１５０４で、招待者は招待者の名前を検証してその招待が招待者に向けられたものかどうかを確認する。
【００６６】
次に、ステップ１５０６で、招待者が招待者のローカルな公開鍵有効化ポリシーに従って議長の名前／ＵＲＬを含む議長の証明書を有効化する。招待者は適当な証明書有効化プロバイダ（招待者のローカル・ポリシーになっている場合にはｔｒｉｖｉａｌ／初期設定で「自己署名証明書をすべて信頼する」有効化アルゴリズムが実装することがある）を起動することにより行なう。
【００６７】
ステップ１５０８で、招待者は議長の署名を確認してこの招待が本当に議長９０２から来たものかどうかを確かめ招待者９０４が本当に招待されたのかを確かめる。
【００６８】
最後にステップ１５１０で、招待者は招待情報を復号して検証し招待者が議長の招待を受け入れたいかどうかを決定する。そして手順はステップ１５１２で終了する。
【００６９】
図１０に戻ると、招待者９０４が招待を受け入れることに決定した場合、ステップ１００４で招待者９０４は議長９０２へ受諾メッセージを送信して応答する。このメッセージが図９では矢印９１４として模式的に図示してある。これ以外に、招待者が招待を受け入れないと決定した場合、エラーメッセージを招待者９０４から議長９０２へ送信する。
【００７０】
受諾メッセージの内容が図１２に図示してある。メッセージはへッダ１２００と、これに続く署名付きの招待ナンス１２０２で構成され、ナンスは招待メッセージで議長から招待者へ送信されたものである。これを用いることで、議長はこの受諾メッセージが招待に応答したものであると認識できることになる。署名付きナンス１２０２には署名つき受諾ナンス１２０４が続く。署名付き受諾ナンスは招待者が生成したタイムスタンプ、招待者９０４の名前／ＵＲＬ、議長９０２の証明書、テレスペースの名前／ＵＲＬ、そして受諾オプコードを含む。
【００７１】
ナンス１２０４には暗号データ１１０６と同様のセキュリティ内容暗号データ１２０６が続く。
【００７２】
次に、公開鍵暗号化メカニズムを使用して、新しく生成したワンタイム鍵１２０８の公開鍵暗号を送信し、パラメータ、情報、公開鍵暗号化鍵が議長９０２から招待者９０４へ送信される（例えば公開ＲＳＡ暗号鍵）。
【００７３】
暗号化ワンタイム鍵１２０８に続くのはアプリケーション・データ１２１０で、これにはワンタイム鍵を使用して暗号化した２個のタイムスタンプと受諾データを含む。この情報１２１０は招待者９０４の受諾について議長９０２に通知するものである。
【００７４】
次に、招待者９０４の署名を送信する。この署名はへッダ情報１２００、議長の名前と招待者のナンス１２０２に受諾ナンス１２０４を連結したもの、暗号化していないワンタイム鍵、暗号データ１２０６と暗号化していない受諾情報（タイムスタンプなし）のハッシュによる。この署名は招待者の証明書にすべての示された情報を結合する（証明書は更に議長の証明書公開鍵有効化ポリシーを介して招待者９０４に結合されている）。議長９０２の名前がこの署名のスコープ内に含まれ招待者が署名した、議長には分かっているワンタイム鍵を議長が第三者へ送信するのを防止し、これにより招待者９０４を真似なければならないことに注意する。最後に、招待者の証明書１２１４を送信する。
このメッセージの受信時に、議長９０２は図１６のフローチャートに示してある手順を実行する。この手順はステップ１６００から始まりステップ１６０２に進み、ここで議長９０２が暗号化されたワンタイム鍵を復号し、これにより鍵を取り込む。
【００７５】
次に、ステップ１６０４で、議長９０２はワンタイム鍵を使って暗号化された受諾情報を復号する。次にステップ１６０６で、議長は招待者の証明書を検証して招待者の名前を取り出す。
【００７６】
ステップ１６０８で、議長９０２は招待ナンスを再計算して再計算したナンスと受信した招待ナンスとを調べ受諾メッセージが応答している招待がどれかを決定する。本発明の一つの態様によれば招待ナンス（図１１の１１０４）は「ステートレス」つまり関連するタイミングとは無関係に解釈できることに注意する。例えば、メンバーＡが装置１から招待者Ｂへ招待を発行したが後にＢの受諾を装置２で受信したと仮定する。オリジナルの招待メッセージではナンスがデルタ経由でＡの使用可能な全装置へ送信されたとしても、招待者Ｂからの受諾メッセージは招待ナンスを伝達するデルタより先に装置２に到着することがあり装置２でのソフトウェアによる比較ができない場合がある。この問題を回避するため、ナンスに関連した情報は装置２を含めた当該メンバーの装置の全部で視覚的に表示される。この表示の一例が図２３に示してあり表示は例えばユーザ・インタフェース・ダイアログボックス２３００経由で、またはその他の類似のメカニズムを介して行なわれる。図２３に図示してあるように、３項目の情報がダイアログ・ボックス２３００に表示される。これは、招待者Ｂの題名２３０２、招待者Ｂの証明書のメッセージ・ダイジェスト２３０４、及び招待メッセージ署名ナンス２３０５からのタイムスタンプである。
【００７７】
送信者の「証明書」は重要な２項目の情報を伝達するパッケージである：これはメッセージ送信者の「題名」と送信者の「公開鍵」である。この場合、Ｂの題名は装置２のプロトコル・エンジンによって抽出されダイアログ・ボックス２３００のテキストボックス２３０２に表示されている。この名前の一例としては、「ｗｔｕｖｅｌｌ＠ｇｒｏｏｖｅ．ｎｅｔ」がある。Ａはこれで受諾メッセージが招待に対応することを確認できる。
【００７８】
受諾を有効化するためには、Ａはすでに招待者Ｂの対象者名を知っているので、Ａは本発明のコラボレーション・システムとは別の経路から認証のメッセージ・ダイジェストを受け取る必要がある。例えば、この情報を受け取る代表的な方法はＡがＢを電話で呼び出して証明書のメッセージ・ダイジェストがどのようなものなのかを尋ねることである。例えば、この計算したメッセージ・ダイジェストは「０ａ，１ｂ，２ｃ，３ｄ；４ｅ，５ｆ，６ａ，７ｂ；８ｃ，９ｄ，ａｅ，ｃｆ；ｃ１，ｄ２，ｅ３，ｆ４；０５，１６，２７，３８；４９，５ａ，６ｂ，７ｃ」といったようなものになる。
【００７９】
Ａが受諾メッセージを介してＢの証明書を受け取ったら、メッセージ・ダイジェスト（または証明書の「フィンガープリント」）を、受諾メッセージのＢの証明書１２１４から、従来のメッセージ・ダイジェスト・アルゴリズム（例えばＭＤ５やＳＨＡ１など）を用いて図２１と図２２に図示してあるセキュリティ・サービス・アーキテクチャにより、アルゴリズム的に計算する。この再計算したメッセージ・ダイジェストがボックス２３０４に表示される。再計算したメッセージ・ダイジェストがすでに分かっている正しいメッセージ・ダイジェストと一致すれば、Ａは提示された証明書が正しいものであるとして受け入れることができる。それ以外の場合には破棄される。この操作は「証明書有効化」と呼ばれる。
【００８０】
「署名付きナンス」はメッセージの署名である。従って、メッセージのタイムスタンプと送信者の証明書を含む情報を互いに結び付ける。「再生攻撃」を避けるためには（すでに送信された正しいメッセージを再送することによる攻撃）、受諾メッセージに含まれている招待ナンス１２０２のタイムスタンプが受け入れ可能な範囲内にあることを確認することも必要である。タイムスタンプ情報はナンスから抽出されてダイアログボックス２３００のボックス２３０５に表示される。この情報は、例えば、「２００００４０７１２１１２４Ｚにあるｎａｓｈｔｇｉｒｉ＠ｇｒｏｏｖｅ．ｎｅｔあての招待メッセージ」といったものである。Ａは幾らか早い時刻にタイムスタンプを生成したのであるから、おそらくＡはその時刻を知っている。メンバーＡはタイムスタンプを解釈して情報が受け入れられるものかどうかを決定できる。メンバーＡが情報を受け入れる場合には、ＯＫボタン２３０６をクリックし、そうではないなら中止ボタン２３０８をクリックする。
【００８１】
同様の問題は招待者Ｂが受諾を送信した装置とは別の装置でテレスペース・データを受け取った場合にも発生する。この後者の問題は同じ方法で処理される。
【００８２】
次に、ステップ１６１０で、議長９０２は議長のローカル公開鍵ポリシーにしたがって招待者の証明書を有効化する。議長がすでに招待者の証明書を先の招待メッセージの時点で持っているならこのステップは省略しても良く、その時点で行なった有効化に満足している。議長は適当な証明書有効化プロバイダを起動することによりこの有効化を行なう。
【００８３】
次に、ステップ１６１２で、議長９０２は招待者の署名を確認し、招待者の署名は更に受諾メッセージの認証／完全性を確認し、この受諾が本当に招待者９０４から来たものであることを確かめる。
【００８４】
次に、ステップ１６１４で、議長は復号した受諾情報を検証して招待情報と一致することを確認し、議長が招待者の受諾を認めたいかどうかを決定する。
最後に、ステップ１６１６で、オプションで追加の署名として議長は自分自身の署名を招待者の証明書に追加することができる。この追加署名によってポリシーが有効になるのでグループ・メンバーは議長９０２の証明書を信頼している限り招待者の証明書を有効化できる。
【００８５】
手順はステップ１６１８で終了し、情報が真正なものなら招待者はこれ以後「テレスペースのメンバー」となる。図１０に戻って、ステップ１００６に記載してあるように、議長９０２が「新規メンバー追加」デルタをグループ９００に存在する全メンバーに送信する。これらの新規メンバー・メッセージは図９で矢印９１６、９１８、９２０として模式的に示してある。
【００８６】
議長が他のそれまでに存在しているメンバーへ送信する新規メンバー追加メッセージの内容が図１３に示してある。デルタ・メッセージはへッダ１３００と、これに続けて統合鍵バージョン番号情報を含み、鍵バージョン情報はグループ鍵とすべての認証／完全性の鍵についての全部の鍵バージョン番号を連結したものである。
【００８７】
統合鍵バージョン１３０２には、暗号化した新規グループ暗号鍵及び認証鍵の連結からなる再キーイング情報１３０４が続く。それぞれのメンバー対に対して、グループ暗号鍵及び認証鍵を連結したものがメンバー同士で対になった鍵を使って暗号化され、結果が初期ベクトルと連結される。これらの連結された鍵が更に連結されて統合再キーイング情報１３０４を形成する。新しいキーは古い／現在のグループ鍵ＫＧ／ＬＧを置き換える。新規に追加されたメンバーは古い／現在のグループ鍵を知ることはない。この再キーイングは新規メンバーがそれ以前のテレスペース通信を記録したり読み取れないようにするために必要である。
【００８８】
次に、新規グループ暗号鍵で暗号化し初期ベクトル１３０６と連結した参加情報を送信する。このデルタの内容は、招待者の名前に招待者の証明書と参加情報を連結したものである。参加情報は議長９０２が生成したアプリケーション・データで、他のグループ・メンバーが、メンバー・マネージャ情報を含めて、知る必要のある新規メンバーについての情報に関連する。またテレスペースのメンバーやその他各種情報例えば招待者の役割などのリストを含めることができる。
【００８９】
最後に、メッセージ多重認証コード１３０８を送信する。これは議長と各メンバーの間の認証子を連結したものとすることができる。各認証子は議長からメンバーへのペアになった認証鍵Ｌ０ｊで保護されているハッシュ情報である。ハッシュ情報はへッダ１３００と、統合新規グループ鍵情報１３０４と、暗号化していないデルタ情報を含む。これ以外に、メッセージ認証コードは前述のハッシュ情報の議長署名とすることができる。
【００９０】
図１３に示したメッセージを受け取ると、各メンバー９０６〜９１０は図１７のフローチャートに示してあるステップを実行する。この手順はステップ１７００で始まりステップ１７０２へ進み、ここでメンバーが暗号化されたグループ鍵を復号し、これによって新しいグループ鍵ＫＧ／ＬＧを知る。しかし、各メンバーは、ＫＧ／ＬＧで保護された古いデータが存在しないことを確認するのに必要とされる限り、古い／現在のグループ鍵ＫＧ／ＬＧの知識を保持している必要がある。その後、各メンバーは古い鍵ＫＧ／ＬＧを破棄しその痕跡をすべて抹消する。
【００９１】
次に、ステップ１７０４で、暗号化されたデルタ情報を各メンバーが復号し、これによってデルタ内の情報を知る。ステップ１７０６では、メンバーが認証鍵で暗号化された多重認証子の項目を介して、メッセージの認証／完全性を確認する。
【００９２】
次に、ステップ１７０８で、メンバーは議長９０２が（議長のＩＤはへッダ情報として送信される）議長であること、また新規メンバーを追加する権限があることを確かめる。
【００９３】
ステップ１７１０では、メンバーがデルタ情報を実行する。これを行なう最中に、メンバーは招待者の名前、証明書、参加情報を含めた新規メンバー・マネージャ情報に気づく。手順はステップ１７１２で終了する。
【００９４】
最後に、図１０に戻って、ステップ１００８で、矢印９２２で模式的に示したように、議長９０２が招待者９０４へテレスペース情報を送信する。手順はステップ１０１０で終了する。テレスペース情報は図１４に示したメッセージとともに招待者９０４へ送信される。この情報はへッダ１４００で始まり、ノンス１２０４と同一の署名つき受諾ナンスが続く。これに、図１２に示した受諾メッセージに関連して説明したように暗号データ１４０４と暗号化したワンタイム鍵（これは新規に生成する）１４０６が続く。
【００９５】
暗号化したワンタイム鍵１４０６のあとには直前のメッセージ部分にあるワンタイム鍵で暗号化されたテレスペース（ＴＳＰ）データが続く。このデータはワンタイム鍵で暗号化したペイロードと連結された初期ベクトルを含む。ペイロードは招待者が生成したタイムスタンプと連結グループ暗号及び認証鍵ＫＧ／ＬＧ、及びＴＳＰデータである。ＴＳＰデータは招待者がメンバーから受信を許可されているＴＳＰデータのメンバーによるバージョンを含むアプリケーション・データである。
【００９６】
暗号化されたＴＳＰデータ１４０８には、へッダ１４００、招待者の名前、署名付きナンス１４０２、連結グループ暗号及び認証鍵、暗号化していないワンタイム鍵、暗号情報１４０４、暗号化していないＴＳＰデータを含むハッシュ情報に対する議長の署名１４１０が続く。最後に、議長の証明書１４１２が後続する。
【００９７】
このメッセージを受信すると、招待者９０４は図１８に示した手順を実行し、手順はステップ１８００で始まりステップ１８０２へ進みここで招待者９０４は暗号化された１回限りの鍵（以下、ワンタイム鍵）を復号してワンタイム鍵を取り出す。
【００９８】
次に、ステップ１８０４で、招待者はワンタイム鍵を使用して暗号化されたＴＳＰデータを復号し、ＴＳＰ情報を取り出す。次に、ステップ１８０６で、招待者９０４は署名つき受諾ナンスを再計算してこれと受信したナンスとを比較してこれが受け入れられるものであることを確認する。先に説明したように、この比較はソフトウェアでまたは視覚的検査によって行なうことができる。このノンスは議長の証明書を含んでいるので、招待者はこの証明書を再有効化する必要がない。
【００９９】
ステップ１８０６では、招待者９０４が議長の署名を検証し、ステップ１８０８では、招待者が復号したＴＳＰデータを初期の「作成中テレスペース」に広める。唯一残っている、なすべきことはテレスペースの他のすべてのメンバーと鍵ペアを交換することで、そのあと、招待者はテレスペースの完全なメンバーとなる。
【０１００】
鍵ペアは再キーイング手順で交換でき、ここで再キーイング情報は他の情報を搬送するデルタに「ピギーバック（相乗り）」する形になる。この再キーイングを実行するための一つのプロトコルは図１３に示した新規メンバー追加デルタ・メッセージで前述した。再キーイング情報は他のデルタ・メッセージに挿入することもできる。このようなピギーバック型デルタ・メッセージは通常のデルタ・メッセージだが、鍵変更（グループ／テレスペース鍵（ＫＧ／ＬＧ）、トライブ／サブグループ鍵（トライブＴ１、ＴｎについてＫＴ１／ＬＴ１、ＫＴｎ／ＬＴｎ）及び／または鍵ペア（Ｋｉｊ／Ｌｉｊ）のあらゆる組み合わせに同時に関係する）がデルタ・メッセージにピギーバックする点で異なっている。デルタそれ自体は同時にトライブＴｋに適した新しい鍵で暗号化される。新しい（再キーイングされた）鍵はこのメッセージで搬送される。鍵ペアがメッセージにピギーバックしている場合、メッセージは公開鍵署名認証子によって保護される。それ以外の場合では、メッセージは現在の鍵ペアを用いる多重認証コードによって保護される。
【０１０１】
このようなメッセージの一例が図１９に示してある。デルタ・メッセージはへッダ１９００と、これに続く統合鍵バージョン情報１９０２を含み、統合鍵バージョン情報は新規グループ鍵とすべての新規トライブ認証／完全性鍵についてのすべての鍵バージョン番号の連結である。
【０１０２】
統合鍵バージョン情報１９０２には第２のセクション１９０４が続き、これも統合鍵バージョン情報を含む。鍵ペア変更が送信中の場合、この情報は新しい鍵ペアについてのすべての鍵バージョン番号の連結を含む。別の場合は、グループ鍵とトライブ鍵を再キーイングしている場合情報１９０４は古いまたは現在の鍵ペアについての統合鍵バージョン情報を含む。
【０１０３】
統合鍵バージョン１９０４に続くのが統合再キーイング情報１９０６で、これは新しいグループ及びトライブ鍵（ＫＧ／ＬＧ及びＫＴ／ＬＴ）の連結から構成される。各メンバーのペアについて、連結されたグループ暗号化及び認証鍵はメンバーのペアに対して鍵ペアを用いて暗号化され、その結果が初期化ベクトルに連結される。これらの連結された鍵はそれら自身連結されて統合再キーイング情報１９０６を形成する。新しい鍵は古い／現在のグループ鍵ＫＧ／ＬＧを置換する。新しい鍵ペアが転送中の場合、統合グループ再キーイング情報には新しい鍵ペアに対する統合再キーイング情報が続く。各メンバーのＫ／Ｌ鍵は連結されそのメンバーの公開鍵を用いて暗号化される。これらの暗号化された鍵は連結されて統合鍵ペア再キーイング情報を形成する。
【０１０４】
次に、新しいグループ暗号化鍵で暗号化されて、新しい鍵１９０８に対応する初期ベクトルに連結されたデルタ情報が送信される。このデルタの内容は従来のあらゆるデルタ・メッセージとすることができる。
【０１０５】
最後に、メッセージ多重認証コード１９１０が送信される。これはメンバー間の認証子を連結したものとすることができる。それぞれの認証子は送信側メンバーから受信側メンバーへのペアになった認証鍵Ｌｉｊで保護されたハッシュ情報である。ハッシュ情報はへッダ１９００と、統合新規グループ鍵情報１９０４（またこれが送信中の場合には統合新規鍵ペア情報）、更に暗号化されてないデルタ情報を含む。ペアになった鍵がメッセージにピギーバックしている場合には、多重認証コードの代わりに、公開鍵署名認証子を送信する。
【０１０６】
前述のセキュリティ・システムは様々な方法で実装できる。好適実施態様では、図２０に模式的に示したプロバイダ・アーキテクチャを使用する。このようなアーキテクチャが好ましいのは、前述したセキュリティ・プロトコルが「アルゴリズム中立」であることによる、つまり特定の暗号化及び保護アルゴリズムに依存していないためである。このプロトコルはアルゴリズムに中立なインフラストラクチャ例えば図２０に図示してあるそれを利用できる。図２０は縦方向の次元と横方向の次元で構成される２次元構造を示す。縦方向の次元は数個の抽象層から構成され、横方向の次元は縦方向の層を含めた各種アプリケーション及びサービスで構成される。最上部の層はアプリケーション層で、アプリケーションの組を含み、そのうちのアプリケーション２０００と２００２が図示してある。これらのアプリケーションには、分散通信システム及びコラボレーション・システム、例えば前述のコラボレーション・システムや、保護データ記憶、可用性（サービスの非拒絶）、システム管理、医療情報システム、航空管制システム、原子力発電所、軍事情報作戦指令管制システムなどを含み、これだけに限定されない。
【０１０７】
アプリケーション２０００及び２００２は一つまたはそれ以上のセキュリティ・サービスにアクセスするが、そのうちサービス２００４と２００６を図示してある。これらのサービスには、例えば識別、認証、完全性、機密性、プライバシー、許可、権威の代理、アカウンタビリティと非拒絶、タイムスタンプ、公証（ｎｏｔａｒｉｚａｔｉｏｎ）、監査、信頼ポリシー管理、侵入検知及び復旧サービスなどを含む。
【０１０８】
セキュリティ・サービスは抽象プリミティブ・サービス２００８と２０１０を含む抽象（またはアルゴリズムに中立な）プリミティブ・サービスの組み合わせにより実装される。抽象プリミティブ・サービスは実際には具象（またはアルゴリズム特異的な）プリミティブ・サービスの組み合わせによって実装される。例えば、抽象プリミティブ・サービス２００８は具象プリミティブ・サービス２０１２、２０１４、２０１６により実装され、一方抽象プリミティブ・サービス２０１０は具象プリミティブ・サービス２０１８、２０２０、２０２２によって実装される。これらの具象プリミティブ・サービスは例えば特定の暗号サービスやプロトコルなどのサービスを含む。
【０１０９】
各抽象層は高次の抽象層または層群によって消費されるサービスを作成する。好適な実装では、アプリケーション２０００、２００２とセキュリティ・サービス２００４、２００６の間の関連性、ならびにセキュリティ・サービス２００４、２００６と抽象プリミティブ・サービス２００８、２０１０の間の関連性は従来どおりの、これらの層の間で静的なコンパイル時に決定される結合（ｃｏｍｐｉｌｅ−ｔｉｍｅ ｂｉｎｄｉｎｇｓ）である。しかし抽象プリミティブ・サービス２００８、２０１０と具象プリミティブ・サービス（２０１２、２０１４、２０１６、２０１８、２０２０、２０２２）の間の結合は、制約された方法で一つの抽象プリミティブ・サービスと一つまたはそれ以上の具象プリミティブ・サービスを関連づける動的なランタイム結合であるのが望ましい。この動的な結合は「プロバイダ・アーキテクチャ」と呼ばれ、抽象またはアルゴリズム中立なプリミティブ・サービスをなんらかの具象またはアルゴリズム特定のそれで作成することにより実装できるメカニズムであり、実装は任意の時刻にその環境内でアクティブにすることができるようなものである。
【０１１０】
図２１と図２２はプロバイダ・アーキテクチャの特定の実装を模式的に示している。オブジェクト指向プログラミング技術をこの実装では用いているが、他の等価な技術やプログラミング言語で実装することもできることは当業者に理解されるであろう。更に詳しく説明すると、図示した実装はダイナミック・リンク・ライブラリ（ＤＬＬ）を使用して各種サービスを提供している。
【０１１１】
ＤＬＬは図２１と図２２のそれぞれに図示してある。図２１に図示したＤＬＬ はセキュリティ・サービス・マネージャ（ＳＳＭ）と呼ばれるもので、図２２に図示したＤＬＬはセキュリティ・サービス・プロバイダ（ＳＳＰまたは単にプロバイダ）と呼ばれる。セキュリティ・サブシステムのどのランタイム・インスタンシエーションにも必ず一つだけＳＳＭ ＤＬＬがロードされる。一方でＳＳＰ ＤＬＬは何個でもロードでき、それらがすべて独立しているという制限が加えられるだけである（これらがすべてシステム・レジストリなどのファイルに記録されている通りの独立したＬＩＢＩＤとファイル名を有するという意味で）。ＳＳＰ ＤＬＬの名称はそのデベロッパが選択する。図示したＳＳＰ ＤＬＬの例はＳｅｃＰｒｏｖＸＸＸ．ｄｌｌというような名前がつけられていると考えられ、他のＤＬＬはＳｅｃＹＹＹＰｒｏｖ．ｄｌｌまたはＺＺＺＳｅｃＰｒｏｖ．ｄｌｌというような名前をつけることができる。
【０１１２】
図２１と図２２のボックスはマイクロソフト・コモン・オブジェクト・モデル（Ｍｉｃｒｏｓｏｆｔ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に適合するＣＯＭクラスを示す。これらのクラスは、エンジン・クラス（右側に示す）と非エンジン・クラス（左側に示す）の２種類のグループに大別される。ＣＯＭエンジン・クラスのそれぞれは一つだけＩＤＬインタフェースを実装してエクスポートする。例えば、エンジン・クラス２１０６（ＭｅｓｓａｇｅＤｉｇｅｓｔ）はインタフェース２１０４（ＩＭｅｓｓａｇｅＤｉｇｅｓｔ）をエクスポートし、エンジン・クラス２１１８（ＫｅｙＧｅｎｅｒａｔｏｒ）はインタフェース２１１６（ＩＫｅｙＧｅｎｅｒａｔｏｒ）をエクスポートし、エンジン・クラス２１２６（Ｃｉｐｈｅｒ）はインタフェース２１２４（ＩＣｉｐｈｅｒ）をエクスポートする。これはインタフェース２１００をエクスポートするＳｅｃｕｒｉｔｙクラス２１０２についても言えることである。図２２に図示した具象クラスについても同じことが当てはまる。例えば、具象エンジン・クラス２２０４（ＸＸＸＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ）はインタフェース２２０６（ＩＭｅｓｓａｇｅＤｉｇｓｅｔＳｐｉ）をエクスポートし、エンジン・クラス２２０８（ＸＸＸＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）はインタフェース２２０６（ＩＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）をエクスポートし、エンジン・クラス２２１０（ＸＸＸＣｉｐｈｅｒＳｐｉ）はインタフェース２２１２（ＩＣｉｐｈｅｒＳｐｉ）をエクスポートする。
【０１１３】
プロバイダ抽象クラス２１２２とＸＸＸＰｒｏｖｉｄｅｒ具象クラス２２００（図２２）で形成されるプロバイダ／ＸＸＸプロバイダ（Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ）「複合クラス」についても同じことが言える。更に詳しく説明すると、Ｐｒｏｖｉｄｅｒクラス２１２２はＩＰｒｏｖｉｄｅｒインタフェース２１２０をサポートし、ＸＸＸＸＰｒｏｖｉｄｅｒクラス２２００はＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（図２２には図示していない）をサポートする。しかし、Ｐｒｏｖｉｄｅｒクラス２１２２はＸＸＸＰｒｏｖｉｄｅｒ クラス２２００の内部でのみ統合可能で、したがって独立してインスタンシエーションできない。つまり、ＩＰｒｏｖｉｄｅｒ２１２０インタフェースとＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースの両方がＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００によって「エクスポート」されることになる。
【０１１４】
Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラスと図２１に図示したエンジン・クラスの全部は図２２に図示してある他の一つのクラスと組み合わされる（ただしこれは多数のＳＳＰを構成することができそれぞれが多数のアルゴリズムをサポートできることから多面的な関係である）。ＳＳＭ ＤＬＬ（図２１）のパートナーは抽象パートナーと呼ばれ、ＳＳＰ ＤＬＬ（図２２）のパートナーは具象パートナーと呼ばれる。図２１と図２２の左側には、「マスター」クラスと呼ばれる２種類のＣＯＭクラスがあり、これはＳｅｃｕｒｉｔｙクラス２１０２とＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００である。Ｓｅｃｕｒｉｔｙクラス２１０２が「マスター」クラスであるという意味は、各種「スレーブ」Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスを制御できるということである。逆に、各種Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスが「マスター」であるということの意味は、これらが各種のスレーブ低レベル／具象エンジン・クラスを制御すると言うことである。マスター・クラスはほとんどセキュリティ・サブシステムの内部的なもので大半のアプリケーションからは見えない。
【０１１５】
図２１と図２２の右側にはエンジン・クラスと呼ばれる２種類のＣＯＭクラスがあり、これらは図２１に図示した抽象エンジン・クラスと図２２に図示した具象エンジン・クラスである。抽象エンジン・クラスはｍ＿Ｅｎｇｉｎｅフィールドの値に０を持っていれば純粋に抽象的であると言われる。３種類のエンジン・クラス（ＭｅｓｓａｇｅＤｉｇｅｓｔ、ＫｅｙＧｅｎｅｒａｔｏｒ、Ｃｉｐｈｅｒ）が説明のために図示してあるが、これらの個数は原理的に制限されない。これらのエンジン・クラスは図２１と図２２に図示してあるように対で発生し、低レベルのクラスが高レベルのクラスの内部に内包または封入される（ｍ＿Ｅｎｇｉｎｅメンバーを経由する）。高レベル・エンジン・クラスの機能はセキュリティ・サービスの消費者が起動するアプリケーション・プログラミング・インタフェース（ＡＰＩ）をエクスポートすることである。低レベル・エンジン・クラス名に見られる接尾辞「Ｓｐｉ」はサービス・プロバイダ・インタフェース（またはセキュリティに関して言えばセキュリティ・プロバイダ・インタフェース、また時に他の状況下ではシステム・プログラミング・インタフェース）を意味するもので、これの唯一の消費者は高レベル・エンジン・クラスである。これらの低レベル・エンジン・クラス内に実際のアルゴリズム特有の実装コードが存在する−−これが「ＳＳＰ ＤＬＬ」の実際に「提供する」最終的な機能である。エンジン・クラスを２つの部分に分割したことが、これらのサポートするサービスの命名構造に反映されており、完全認証サービス名は抽象／概念の接頭辞と具象／アルゴリズムの接尾辞、例えばＭｅｓｓａｇｅＤｉｇｅｓｔ．ＭＤ５というように構造化される。
【０１１６】
各具象ＳＳＰ（ＸＸＸＰｒｏｖｉｄｅｒクラス２２００）は静的な情報を含み、これにはその名前（ｓ＿ＭｙＮａｍｅ、文字列）、バージョン（ｓ＿ＭｙＶｅｒｓｉｏｎ、数字）、クラスＩＤ（ｓ＿ＭｙＣｌｓｉｄ、１６バイト二進数）、情報（ｓ＿ＭｙＩｎｆｏ、文字列）、ＤＬＬにバンドルされているサービスのリスト（ｓ＿ＭｙＳｖｃＭａｐ［］、文字列のペアのリスト）を含む。ｓ＿ＭｙＳｖｃＭａｐ［］の各エントリでは、一方の文字列がそのサービスで実装するアルゴリズムの名称、他方がそのアルゴリズムを実装する具象エンジン・クラス（ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌにバンドルされる）のＣＯＭ ＣＬＳＩＤ（クラスＩＤ）である。
【０１１７】
エンジン・クラスに加えて、セキュリティ・サブシステムは多数の非エンジン・クラスを含む。代表的な２つのクラス、ＫｅｙとＫｅｙＰａｉｒが図２１に示してある。図面が示すように、このような非エンジン・クラスは相対的に通常のＣＯＭ クラスで、唯一普通とは違う特徴は（抽象）インタフェース・クラスであり（具象）実装クラスはＳＳＭ ＤＬＬ（図２１）とＳＳＰ ＤＬＬ（図２２）の間で分割される（されない）ことである。例えば、Ｋｅｙクラス２１１０の場合だと、ＳＳＭは一般に任意のＳＳＰの鍵がどのようなものであるべきかについての優先的な（インタフェース）知識を持っているが、ＳＳＰそれ自体はＳＳＭによって例えばＸＸＸＫｅｙクラス２２１０によって定義されるインタフェースに準拠したＫｅｙクラスの詳細な実装を供給する必要がある。しかしＫｅｙＰａｉｒクラス２１１４の場合、ＳＳＭはすでに実装についての詳細な知識を持っている−−これはＫｅｙ（それがどのようなものであっても）のペアで構成される。
【０１１８】
セキュリティ・サブシステムをブートする場合、例えば、Ｓｅｃｕｒｉｔｙクラス２１０２がランタイム時に最初にＣｏＣｒｅａｔｅされ、Ｓｅｃｕｒｉｔｙクラス２１０２はＳｅｃｕｒｉｔｙクラスのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）メソッドで次のようなことを行なう。第１に、Ｓｅｃｕｒｉｔｙクラス２１０２は例えばレジストリ（Ｒｅｇｉｓｔｒｙ）に保存されている構成情報を読み込む。
【０１１９】
次に、それぞれの構成された具象プロバイダＸＸＸＰｒｏｖｉｄｅｒ（レジストリから読み出したばかりの）のＰｒｏｇＩＤ（またはＣＬＳＩＤ）に基づいて、セキュリティ・クラスがＸＸＸＰｒｏｖｉｄｅｒ２２００のインスタンスをＣｏＣｒｅａｔｅし、ＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（Ｃｔｏｒはコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）の意味）へのポインタを得る。ＸＸＸＰｒｏｖｉｄｅｒクラスをＣｏＣｒｅａｔｅするこの動作は更にＸＸＸＰｒｉｖｉｄｅｒのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）にＸＸＸＰｒｏｖｉｄｅｒ２２００内部の抽象ＰｒｏｖｉｄｅｒクラスのオブジェクトをＣｏＣｒｅａｔｅして統合する。
【０１２０】
次に、いまＣｏＣｒｅａｔｅしたばかりのＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースを使って、Ｓｅｃｕｒｉｔｙクラス２１０２がＸＸＸＰｒｏｖｉｄｅｒのｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドをＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースから呼び出す。この特別なｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの名称／バージョン／情報／ｃｌｓｉｄ／サービス・データを、「ハードワイヤードな」静的数値変数の位置から統合Ｐｒｏｖｉｄｅｒオブジェクト内の非静的メンバー変数へ「アップロード」する（ｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの統合Ｐｒｏｖｉｄｅｒサブオブジェクトによってエクスポートされるなんらかのメソッドを呼び出すことでこれを完了する）。
【０１２１】
第４に、Ｓｅｃｕｒｉｔｙクラス２１０２は各種の構成された具象プロバイダを指すＩＰｒｏｖｉｄｅｒ＊の静的内部構成リストｓ＿ＰｒｏｖＬｉｓｔ［］を構築する。Ｓｅｃｕｒｉｔｙクラス２１０２は、Ｓｅｃｕｒｉｔｙクラス２１０２がこの時点まで使っていたＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒ＊インタフェースでＱｕｅｒｙＩｎｔｅｒｆａｃｅを呼び出すことで各ＩＰｒｏｖｉｄｅｒ＊を構築する。構成されたＳＳＰのリストｓ＿ＰｒｏｖＬｉｓｔ［］はＳｅｃｕｒｉｔｙクラス２１０２のｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを介してクライアントが利用できるようになる。
【０１２２】
アプリケーションは次のような方法でプロバイダ・アーキテクチャを実際に使用する。あるアプリケーションがＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクト上でｄｉｇｅｓｔ（）メソッドを呼び出して特定メッセージ（バッファ）のダイジェストを実際に計算したいと想定する。アプリケーションはＳＳＭで抽象エンジン・クラスを知っている（すなわちＳｅｃｕｒｉｔｙＳｖｃｓ．ｄｌｌのクラスのＣＬＳＩＤ）。これは作成中にこの情報へリンクされたためだが、現実のアルゴリズム実装が実際に存在するＳＳＰ内の具象エンジン・クラスについては優先順位（すなわち、ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌのクラスのＣＬＳＩＤ）を知らない。したがって、アプリケーションは抽象エンジン・オブジェクトを直接ＣｏＣｒｅａｔｅできるが、具象エンジン・オブジェクトは直接ＣｏＣｒｅａｔｅ できない。しかし、好適実施態様では、抽象エンジン・オブジェクトがｇｅｔＩｎｓｔａｎｃｅ（）と呼ばれるファクトリ・メソッドを有するクラス・ファクトリ・オブジェクトとして処理され、次のように、間接的に具象エンジン・オブジェクトを作成している。
【０１２３】
アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔクラス２１０６から純粋な抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅすることから開始する。このようなオブジェクトは具象エンジン・オブジェクトへ接続されないのでダイジェストを作成するためには使えない、すなわち主状態変数ｍ＿Ｅｎｇｉｎｅは値に０を持っている（副状態変数ｍ＿ＡｌｇＮａｍｅとｍ＿ＰｒｏｖＮａｍｅも同様）。いまＣｏＣｒｅａｔｅしたＩＭｅｓｓａｇｅＤｉｇｅｓｔ＊インタフェース２１０４を使って、アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔのｇｅｔＩｎｓｔａｎｃｅ（）メソッドを呼び出し、使いたいメッセージ・ダイジェスト・アルゴリズムの周知の名前を指定する。ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはファクトリ・メソッドで、次のステップを実行する。第１に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドがＳｅｃｕｒｉｔｙオブジェクトでｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを呼び出して現在構成されているプロバイダのリストをフェッチする。次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはいまフェッチしたばかりのＳＳＰのリストを使って、要求されたアルゴリズムをサポートする最初のＳＳＰが見つかるまで、好適な順番で各ＳＳＰのｇｅｔ（）メソッドを呼び出す。ＳＳＰのｇｅｔ（）メソッドはＳＳＰのｍ＿ＳｖｃＭａｐ［］を使用し、アルゴリズム名を具象エンジン・クラスＰｒｏｇＩＤにマッピングする。つまりこの例では、クラス２０２２のｇｅｔ（）メソッドが要求されたアルゴリズムをサポートしているＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ具象エンジン・クラスのＰｒｏｇＩＤを返す。
【０１２４】
次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはｇｅｔＩｎｓｔａｎｃｅ（）メソッドが呼び出されたＭｅｓｓａｇｅＤｉｇｅｓｔとは別に新しく抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅする。まず、この新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトはもう一つの純粋な抽象エンジン・オブジェクトだが、次のステップでｇｅｔＩｎｓｔａｎｃｅ（）メソッドは完全な／接続されたエンジン・オブジェクトへ（すなわちｍ＿Ｅｎｇｉｎｅフィールドを介してこれの内部に含まれる／作成される具象エンジンとあわせて「非純粋」抽象エンジン・オブジェクトに）変化させる。
【０１２５】
最後に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドを呼び出し、パラメータとして上記で呼び出したｇｅｔ（）オブジェクトから取得したＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ ＣＬＳＩＤ（またはＰｒｏｇＩＤ）を渡す。そのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドはクラス２１０４からＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉオブジェクトのインスタンスをＣｏＣｒｅａｔｅし、新しいＭｅｓｓａｇｅＤｉｇｅｓｔのｍ＿Ｅｎｇｉｎｅフィールドへ得られたＩＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ＊ポインタを格納する。
【０１２６】
つまり、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはアプリケーションへ完全に完成／接続したＭｅｓｓａｇｅＤｉｇｅｓｔエンジン・オブジェクトを返す。この時点で、アプリケーションはエンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドを呼び出してメッセージのダイジェストを計算する。（抽象）エンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドは具象エンジン・オブジェクトのｅｎｇｉｎｅＤｉｇｅｓｔ（）メソッドへの呼び出しを代理または転送して実際の作業を行なわせる。
【０１２７】
上記で説明した実施態様のソフトウェアによる実装は、有形の媒体例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤＲＯＭ、ＲＯＭメモリ、または固定ディスクなどに固定されるか、モデムまたは媒体上のその他のインタフェース装置を介してコンピュータ・システムへ転送可能な一連のコンピュータ命令を含む。媒体は光またはアナログ通信線を含みこれに限定されない有形の媒体としたり、マイクロ波、赤外線またはその他の電送技術を含みこれに限定されない無線技術で実装することができる。媒体はインターネットの場合もある。一連のコンピュータ命令は本発明に関して本明細書ですでに説明した機能の全部または一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用される多数のプログラミング言語で書けることが当業者には理解されよう。更に、このような命令は、現在または将来の、半導体、磁気、光、またはその他のメモリ装置を含みこれに限定されないなんらかのメモリ技術を用いて保存したり、あるいは現在または将来の、光、赤外線、マイクロは、またはその他の伝送技術を含みこれに限定されないなんらかの通信技術を用いて伝送される。このようなコンピュータ・プログラムは印刷物または電子文書を伴なう取り出し自由な媒体として、例えばシュリンクラップ包装ソフトウェアとして配布されたり、コンピュータ・システムに例えばシステムＲＯＭや固定ディスク上にプリロードされていたり、またはサーバまたは電子掲示板から例えばインターネットまたはワールド・ワイド・ウェブなどのネットワーク上で配布されることがあると想定される。
【０１２８】
本発明の代表的実施態様を開示したが、本発明の利点のいくつかを実現し本発明の主旨と範囲から逸脱しない各種の変化及び変更を加えることができることは当業者に明らかであろう。例えば、説明は特定のハードウェア・システム及びオペレーティング・システムを指向したものだったが、他のハードウェアやオペレーティング・システム・ソフトウェアを説明したそれと同じ方法で使用できることは当業者には明らかであろう。例えば特定の関数を実現するために使用された特定の命令などのその他の態様ならびに本発明の概念に対するその他の変更も付録の請求の範囲によって包含されることを意図している。
【特許請求の範囲】
【請求項１】
コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加する方法であって、
（ａ）新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、
（ｂ）前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、
（ｃ）前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、
（ｄ）前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送るステップであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含む、ステップと、
（ｅ）前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップと
を含むことを特徴とする方法。
【請求項２】
ステップ（ｂ）は第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項３】
ステップ（ｃ）は第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項４】
ステップ（ｅ）は第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記招待メッセージは更にへッダと前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第１のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記招待メッセージは前記議長装置の名前と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含む議長装置のデジタル証明書を更に含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第２のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項１に記載の方法。
【請求項９】
ステップ（ｃ）は前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認を含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージで受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージの中で前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加するための装置であって、
新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するメカニズムと、
前記議長装置から前記招待者装置へ招待メッセージを送る議長プロトコル・エンジンであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含むことを特徴とする議長プロトコル・エンジンと、
前記招待者装置から前記議長装置へ受諾メッセージを送る招待者プロトコル・エンジンであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含むことを特徴とする招待者プロトコル・エンジンと、
前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送る議長デジタル・メカニズムであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含むことを特徴とする議長デルタ・メカニズムと、
前記議長装置から前記招待者装置へグループ・データ・メッセージを送る議長加入メカニズムであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含むことを特徴とする議長加入メカニズムと、
を含むことを特徴とする装置。
【請求項１３】
前記議長プロトコル・エンジンは第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１４】
前記招待者プロトコル・エンジンは第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１５】
前記議長加入メカニズムは第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１６】
前記招待メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第１のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項１２に記載の装置。
【請求項１７】
前記招待メッセージは更に前記議長装置の名前を含む議長装置のデジタル証明書と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含むことを特徴とする請求項１２に記載の装置。
【請求項１８】
前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第２のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項１２に記載の装置。
【請求項１９】
前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項１２に記載の装置。
【請求項２０】
前記議長プロトコル・エンジンは前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認を行なうことを特徴とする請求項１２に記載の装置。
【請求項２１】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージの中にあって受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項２０に記載の装置。
【請求項２２】
前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージで前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項２０に記載の装置。
【請求項２３】
コンピュータに、コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加する方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記方法は、
新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、
前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、
前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、
前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送るステップであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含む、ステップと、
前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップと
を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項２４】
前記議長装置から前記招待者装置へ招待メッセージを送るステップは、第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項２５】
前記招待者装置から前記議長装置へ受諾メッセージを送るステップは、第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項２６】
前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップは、第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項１】
コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加する方法であって、
（ａ）新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、
（ｂ）前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、
（ｃ）前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、
（ｄ）前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送るステップであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含む、ステップと、
（ｅ）前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップと
を含むことを特徴とする方法。
【請求項２】
ステップ（ｂ）は第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項３】
ステップ（ｃ）は第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項４】
ステップ（ｅ）は第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記招待メッセージは更にへッダと前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第１のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記招待メッセージは前記議長装置の名前と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含む議長装置のデジタル証明書を更に含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第２のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項１に記載の方法。
【請求項９】
ステップ（ｃ）は前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認を含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージで受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージの中で前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加するための装置であって、
新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するメカニズムと、
前記議長装置から前記招待者装置へ招待メッセージを送る議長プロトコル・エンジンであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含むことを特徴とする議長プロトコル・エンジンと、
前記招待者装置から前記議長装置へ受諾メッセージを送る招待者プロトコル・エンジンであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含むことを特徴とする招待者プロトコル・エンジンと、
前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送る議長デジタル・メカニズムであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含むことを特徴とする議長デルタ・メカニズムと、
前記議長装置から前記招待者装置へグループ・データ・メッセージを送る議長加入メカニズムであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含むことを特徴とする議長加入メカニズムと、
を含むことを特徴とする装置。
【請求項１３】
前記議長プロトコル・エンジンは第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１４】
前記招待者プロトコル・エンジンは第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１５】
前記議長加入メカニズムは第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを特徴とする請求項１２に記載の装置。
【請求項１６】
前記招待メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第１のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項１２に記載の装置。
【請求項１７】
前記招待メッセージは更に前記議長装置の名前を含む議長装置のデジタル証明書と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含むことを特徴とする請求項１２に記載の装置。
【請求項１８】
前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第２のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項１２に記載の装置。
【請求項１９】
前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項１２に記載の装置。
【請求項２０】
前記議長プロトコル・エンジンは前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認を行なうことを特徴とする請求項１２に記載の装置。
【請求項２１】
前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージの中にあって受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項２０に記載の装置。
【請求項２２】
前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージで前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項２０に記載の装置。
【請求項２３】
コンピュータに、コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵／秘密鍵ペアを有する招待者装置を追加する方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記方法は、
新規コラボレータ装置を前記グループに追加する権限と公開鍵／秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、
前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、
前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、
前記議長装置から前記グループの全コラボレータ装置へ新規メンバー・メッセージを送るステップであって、前記新規メンバー・メッセージは新規のコラボレータ装置間鍵を含む、ステップと、
前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップであって、前記グループ・データ・メッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップと
を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項２４】
前記議長装置から前記招待者装置へ招待メッセージを送るステップは、第１のワンタイム鍵を生成し、前記第１のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第１のワンタイム鍵を暗号化し、前記暗号化された第１のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項２５】
前記招待者装置から前記議長装置へ受諾メッセージを送るステップは、第２のワンタイム鍵を生成し、前記第２のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第２のワンタイム鍵を暗号化して、前記暗号化された第２のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項２６】
前記議長装置から前記招待者装置へグループ・データ・メッセージを送るステップは、第３のワンタイム鍵を生成し、前記第３のワンタイム鍵で前記グループ・データ情報を暗号化し、前記招待者装置の公開鍵で前記第３のワンタイム鍵を暗号化して、前記暗号化された第３のワンタイム鍵と前記暗号化されたグループ・データ情報を前記招待メッセージに含めることを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−１９５３４（Ｐ２０１２−１９５３４Ａ）
【公開日】平成２４年１月２６日（２０１２．１．２６）
【国際特許分類】
【出願番号】特願２０１１−１８１８８０（Ｐ２０１１−１８１８８０）
【出願日】平成２３年８月２３日（２０１１．８．２３）
【分割の表示】特願２００１−５８５００４（Ｐ２００１−５８５００４）の分割
【原出願日】平成１３年５月２日（２００１．５．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年１月２６日（２０１２．１．２６）
【国際特許分類】
【出願日】平成２３年８月２３日（２０１１．８．２３）
【分割の表示】特願２００１−５８５００４（Ｐ２００１−５８５００４）の分割
【原出願日】平成１３年５月２日（２００１．５．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]