JP4955181B2 - 安全なコラボレーティブ・トランザクションを管理する方法及び装置 - Google Patents
安全なコラボレーティブ・トランザクションを管理する方法及び装置 Download PDFInfo
- Publication number
- JP4955181B2 JP4955181B2 JP2001585004A JP2001585004A JP4955181B2 JP 4955181 B2 JP4955181 B2 JP 4955181B2 JP 2001585004 A JP2001585004 A JP 2001585004A JP 2001585004 A JP2001585004 A JP 2001585004A JP 4955181 B2 JP4955181 B2 JP 4955181B2
- Authority
- JP
- Japan
- Prior art keywords
- key
- message
- delta
- authentication
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 67
- 230000007246 mechanism Effects 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000006854 communication Effects 0.000 description 25
- 238000004891 communication Methods 0.000 description 25
- 238000010586 diagram Methods 0.000 description 20
- 230000000694 effects Effects 0.000 description 11
- 238000010200 validation analysis Methods 0.000 description 11
- 238000012508 change request Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 230000003993 interaction Effects 0.000 description 6
- 230000004044 response Effects 0.000 description 5
- 230000003068 static effect Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 230000027455 binding Effects 0.000 description 3
- 238000009739 binding Methods 0.000 description 3
- 239000002131 composite material Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 108010091205 Libid Proteins 0.000 description 1
- 101100217298 Mus musculus Aspm gene Proteins 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007935 neutral effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000011179 visual inspection Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
- H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Multimedia (AREA)
- Storage Device Security (AREA)
- Document Processing Apparatus (AREA)
- Input From Keyboards Or The Like (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Stored Programmes (AREA)
Description
【０００１】
発明の分野
本発明は安全なデータ交換トランザクションを提供するための方法及び装置に関連し、更に詳しくは、共同作業環境（以下、コラボレーティブ環境）における安全なデータ交換トランザクションを提供する方法及び装置に関する。
【０００２】
発明の背景
現在の計算機アプリケーションはほとんどがシングル・ユーザ・システムである。例えば、従来の編集アプリケーションでは、一人のユーザがファイルを開き内容に変更を加えることができる。第１のユーザがファイルを開いている間に、第２のユーザがそのファイルを開こうとすると、第２のユーザはファイルを開くことができないか変更を加えることができないことになる。第２のユーザはファイルの一時的なコピー（以下、スナップショット・コピー）を取得することができる場合がある。しかしスナップショット・コピーは第１のユーザが作成したオリジナルのコピーに加えたそれ以降の変更は何も更新されない。つまり、第２のユーザはファイルの変更として表現された第１のユーザのアイデアを共有することができない。更に、第２のユーザはオリジナルのファイル内容の変更を行なうことができないので、ファイルの変更として表現されるそのユーザのアイデアを共有することができない。要するに、第１と第２のユーザはファイルの共同作業による（以下、コラボレーティブな）編集ができない。
【０００３】
本明細書で用いている術語であるコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）は複数クライアントがアイデアを共有できるようにする能力を意味する。この共有には一人のアイデアを他のメンバーに対して自動的に表明し、他のメンバーがそのアイデアを明示的に要求しなくても良いようにする能力を含む。コラボレーションは更にアイデアを送信するメンバーからのアイデアを自動的にそれぞれのメンバーが受信できるようにする能力も含む。つまり、最低限、コラボレーションは共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｅｆｆｏｒｔ）に参加しているメンバーの間での通信を意味する。この通信／コラボレーションは多くのモデルをもとにすることができる。「ブレーン・ストーミング型」セッションは制約されないコラボレーション・モデルである。一方、「ラウンド・ロビン」型モデルはそれぞれのメンバーがアイデアを表明するのに特定の順番を待つもので、制約型のコラボレーション・モデルである。
【０００４】
米国特許５，７８１，７３２号に開示された一つのコラボレーション・システムでは、データ変更要求がユーザとの対話に対する応答として生成されすべてのコラボレータに接続されているトランスポンダ・ユニットへ送出される。トランスポンダはコラボレーションに参加しているユーザ全部に対してデータ変更要求をブロードキャストする。各ユーザはコラボレーション用データ（以下、コラボレーティブ・データ）のローカルなコピーを持ち、データ変更要求を受信してローカルなデータ・コピーへ要求された変更を加えるメカニズムを備える。すべてのデータ変更要求がトランスポンダを経由しなければならないため、データ変更要求はすべて同じ順番でそれぞれのコラボレータに受信されることになり、データの完全性が維持される。
【０００５】
コラボレーションは１台の計算機またはサーバで作業しているユーザ間でローカルに行なわれたり、ユーザそれぞれがネットワークに接続された計算機に向かっているようなネットワーク上で行なわれることもある。インターネットはこのようなネットワークの一つで、数百万のユーザ間での通信及び対話のためのダイナミックな公衆環境を作り出した。ビジネスにおいて、インターネットまた特にインターネット上で動作するワールドワイドウェブ・アプリケーションはベンダ／メーカ間、メーカ／ディストリビュータ間、ディストリビュータ／顧客間、その他の関係を再編成した。インターネット技術を企業内の機密ネットワークへ拡張すると、「イントラネット」あるいは「プライベート・インターネット」と呼ばれるようなものが、企業のディレクトリとネットワーク基盤を使用する従業員それぞれや作業グループの間で、新しい形態のドキュメント及び情報の共有を可能にした。
【０００６】
ワールド・ワイド・ウェブ（「ウェブ」）はその中核にサーバ・クライアント・アーキテクチャを有し個々のクライアント（すなわちウェブ・コンテンツのユーザ）はブラウザを通して、公衆ネットワーク上にあるサーバ（すなわち、インターネット・コンテンツ・プロバイダ）とインタフェースすることで、ウェブ・サイトからドキュメントを取得する。ブラウザはパーソナル・コンピュータがインターネット・ドキュメントを要求し、受信し（例えばダウンロードし）、解釈し、表示し、また一般的にはインターネットをナビゲーションできるようにするソフトウェア・プログラムである。ウェブ・サイトはドキュメントの集合体で、ドキュメントは一般にホームページやこれに関連しリンクされるドキュメントから構成され、クライアントからは離れたサーバ上に配置される。ドキュメントはコンパウンド・ドキュメントとすることができ、データ、グラフィックス、ビデオ、サウンド、及び／または他の種類のメディアや、他のドキュメントへのリンクも含められる。
【０００７】
基盤となるウェブ及びその他のインターネット技術は、パーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロトコル、インフラストラクチャの取り決め（例えば一元的資源指定子Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ ＬｏｃａｔｏｒまたはＵＲＬ）を含め、標準化が進んでいる。ＵＲＬはＷＷＷ上のすべてのドキュメント・オブジェクトについて所在アドレスを提供する。ＵＲＬはドキュメント・オブジェクトを択一的に指定しインターネット・プロトコルを使用するアクセス・アルゴリズムも定義することが多い。
【０００８】
インターネットを利用するため、インターネット・プロトコルに準拠した形でツールや資源が開発されており、これには電子メール（ｅ−ｍａｉｌ）などのアプリケーションを含む。電子メールは電子的な郵便で、これを用いてドキュメントを電子的に、選択したアドレスで送受信する。インターネット上での対話（ｉｎｔｅｒａｃｔｉｏｎ）のほとんどが「ドキュメント送受信」モデルに従う電子メールやその他のブラウザを使うメディアであると予想された。おそらくはそのモデルのため、ユーザは高次の権威者による介入なしに個人が他の個人の提供した文書にアクセスすることでインターネットを本質的に「ピアツーピア」であると見なすことが多い。
【０００９】
結果として、更に「ピアツーピア」的に動作する新しいコラボレーション・モデルが開発された。これらのモデルは「テレスペース」と呼ばれる共有プライベート空間にいるユーザ間の直接接続の上に構築される。各ユーザは「アクティビティ」と呼ばれるプログラムを持ち、これはパーソナル・コンピュータ・システムや、通信機器またはその他のネットワーク接続可能な装置で動作可能である。アクティビティ・プログラムは「デルタ」と呼ばれるデータ交換要求を生成することでユーザとの対話に応答する。アクティビティはまたデータ変更エンジンを備え、これがローカルなデータ・コピーを維持しており、デルタによって要求されたデータへの変更を実行する。デルタはダイナミクス・マネージャによって一人のユーザから別のユーザへと配布される。後者の形式のコラボレーション・システムは「通信マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ， Ｋｅｎｎｅｔｈ Ｇ． Ｍｏｏｒｅ， Ｒｏｂｅｒｔ Ｈ． Ｍｙｈｉｌｌ ａｎｄ Ｂｒｉａｎ Ｍ． Ｌａｍｂｅｒｔによる１９９９年７月１９日付け米国特許出願第０９／３５７，００７号、「ダイナミクス・マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｄｙｎａｍｉｃｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ． Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け米国特許出願第０９／３５６，９３０号、「アクティビティ・ベースのコラボレーション用に装備した分散コンピュータ・システムにおいてデータ変更要求に優先順位をつけデータ完全性を維持するための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｐｒｉｏｒｉｔｉｚｉｎｇ ｄａｔａ ｃｈａｎｇｅ ｒｅｑｕｅｓｔｓ ａｎｄ ｍａｉｎｔａｉｎｉｎｇ ｄａｔｅ ｃｏｎｓｉｓｔｅｎｃｙ ｉｎ ａ ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け米国特許出願第０９／３５６，１４８号に詳細に記載されている。
【００１０】
インターネットは、ユーザに娯楽と有用な通信方法を提供する点でダイナミックかつフレキシブルだが、ユーザのニーズ全部には適合しない。例えば、インターネットは各種のハードウェアとソフトウェアで広範囲のユーザを接続する能力を有することから理想的にはコラボレーションに適したものであろう。しかし、インターネットのセキュリティは希望するのとは程遠い。インターネット上で様々な人数のユーザへメッセージを送信できるが、これらのメッセージは代表的にはサード・パーティのウェブ・サイトを経由しここで通信を傍受したり機密性を侵害することが可能である。結果として、ユーザがインターネット経由でいっそう対話する一方、例えば複数媒体（電話、ファクシミリ、ホワイトボード）や、複数時刻（リアルタイム、翌日配達郵便（ｏｖｅｒｎｉｇｈｔ ｍａｉｌ））及びその他の通信告知手段など従来の安全な方法でインターネット「以外で」対話を続けることになる。
【００１１】
共有プライベート空間にいる個人間及び中小グループ間でコラボレーティブな通信やその他の共有及び同時的アクティビティを安全なものにするようにインターネットを拡張するのが望ましい。このような対話は参加者のパーソナル・コンピュータ間またはその他のネットワーク接続可能な装置間で望ましくは瞬間的、直接的、かつ機密に行なわれるべきである。また様々なリモートサイトにいるユーザが安全に通信でき、安全な通信リンクの構築やセキュリティ・システムの維持にユーザの広範囲の関与を必要としないような技術を提供するのも望ましい。また安全なトランザクションを提供する上で関係する「オーバヘッド」を最小限にまで減らして通信量（以下、スループット）と動作速度を改善するのも望ましい。
【００１２】
発明の要約
本発明の図示した実施態様の一つによれば、異なるセキュリティ・レベルを提供してユーザが彼ら自身の通信のセキュリティ・レベルを決定できるようにする。ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。これ以外に、セキュリティ関係のオーバヘッドの増加をもたらすもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。
【００１３】
好適実施態様において、鍵管理のオーバヘッドを減少させるため、同一の物理鍵を暗号化鍵とメッセージ認証鍵に使用する。
【００１４】
一つの実施態様において、セキュリティ・レベルはテレスペースが作成されてテレスペースの寿命がある間は固定されたままである。テレスペースでは、セキュリティ・レベルは全くセキュリティがない状態からテレスペースのメンバーと部外者との間のセキュリティ、更にテレスペースのメンバーのペア間でのセキュリティまで範囲がある。
【００１５】
別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用する。
【００１６】
更に別の実施態様において、中程度または高度なセキュリティ・レベルを有するテレスペースのメンバーはウィスパー（ｗｈｉｓｐｅｒｓ）と呼ばれテレスペースの他のメンバーに対しても機密化される機密通信で通信することができる。
【００１７】
好適実施態様の詳細な説明
図１は代表的なコンピュータ・システム１００の従来のシステム・アーキテクチャを示したもので、これに開示された本発明を実装することができる。ただし図１の代表的なコンピュータ・システムは説明目的のみで議論するもので本発明の制限と見なすべきではない。以下の説明では特定のコンピュータ・システムを記述する際に共通に使用される術語を参照することがあるが、記載される概念は図１に図示したものとは異なるアーキテクチャを有するシステムを含めた他のコンピュータ・システムに等しく適用される。
【００１８】
コンピュータ・システム１００は従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報記憶のためのランダムアクセス・メモリ（ＲＡＭ）１１０、及び永久的情報記憶のためのリードオンリー・メモリ（ＲＯＭ）を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５はバス１３０を制御するために設けてあり、割り込みコントローラ１３５は他のシステム要素からの各種割り込み信号を受信し処理するために使用される。
【００１９】
大容量記憶はディスケット１４２、ＣＤＲＯＭ１４７、またはハードディスク１５２によって提供される。データとソフトウェアは取り出し可能な媒体例えばディスケット１４２やＣＤＲＯＭ１４７を介してクライアント・コンピュータ１００と交換できる。ディスケット１４２はディスケット・ドライブ１４１へ挿入でき、このディスケット・ドライブ１４１はコントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤＲＯＭ１４７はＣＤＲＯＭドライブ１４６へ挿入でき、ＣＤＲＯＭドライブ１４６はコントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は固定ディスク・ドライブ１５１の一部であり、これはコントローラ１５０を介してバス１３０へ接続されている。
【００２０】
コンピュータ・システム１００へのユーザ入力は様々な装置から提供される。例えば、キーボード１５６とマウス１５７はキーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６はマイクロホンとスピーカの両方として機能するもので、オーディオ・コントローラ１９７によってバス１３０へ接続されている。その他の入力装置例えばペン及び／またはタブレットや音声入力用マイクロホンなどがバス１３０と適当なコントローラを介してクライアント・コンピュータ１００へ接続できることは当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリ・アクセスを実行するために提供される。視覚表示はビデオ・ディスプレイ１７０を制御するビデオ・コントローラ１６５によって生成される。
【００２１】
コンピュータ・システム１００はクライアント・コンピュータ１００をバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用する。
【００２２】
コンピュータ・システム１００は一般にオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。
【００２３】
図２は略ブロック図の形で代表的なコラボレーション・システムの構成を示す。図２はネットワーク２１６へ接続された２台のコラボレーティブ・ワークステーション２００、２０２を示す。ワークステーション２００、２０２のそれぞれは図１に示したようなコンピュータ・システムとすることができ、ネットワーク２１６はプライベート・コンピュータ・ネットワーク例えばＬＡＮやＷＡＮ、あるいは公衆コンピュータ・ネットワーク例えばインターネットとすることができる。これ以外に、ワークステーション２００、２０２は同一のコンピュータ（図示していない）上に構成することができ、この場合２つの端末間の通信はそのコンピュータに対してローカルなものとなる。
【００２４】
好適実施態様において、端末２００、２０２のそれぞれは共同作業を実行するデータのローカルなコピー２０４、２１０をそれぞれ保持している。それぞれのローカルなデータ・コピー、例えばデータ・コピー２０４はこれに対応する「ダイナミクス・マネージャ」２０６と呼ばれるソフトウェア・プログラムによって管理される。同様に、データ・コピー２１０はこれに対応するダイナミクス・マネージャ２１２によって管理される。特定のコラボレーション装置を説明の目的で議論するが、他のコラボレーション装置も精神と範囲において本発明の原理から逸脱することなく使用できることが当業者には明らかであろう。
【００２５】
ダイナミクス・マネージャ２０６は「デルタ」と呼ばれる一つまたはそれ以上のデータ変更要求を含む自己内包型データユニットの受信に応答してこれのローカル・データ・コピー２０４を変更し更新する。データ変更要求はデータの希望通の変更に関してダイナミクス・マネージャやその他のコンポーネント（図示していない）への通知または催促である。デルタは例えばマネージャ２０６などのダイナミクス・マネージャによって、ユーザとの対話に応答して作成されるもので、対応するローカル・データ・コピー２０４と、ネットワーク越しに同じコラボレーティブ・セッションに参加しているコラボレータに属する他のコンピュータ上のローカル・データ・コピーとの両方を更新するために用いられる。
【００２６】
デルタは制御情報を提供するへッダ部分と要求が関係するデータについての情報を提供するペイロード部分とを含む特定のフォーマットを有する。個々のデルタは一つまたはそれ以上のペイロードを有することができる。多数のペイロードが使用されるような場合、以下で詳細に説明するように、それぞれが独自の装置機能またはユーザの役割を有する特定のコラボレーション・メンバーを対象とすることができる。
【００２７】
ダイナミクス・マネージャ２０６によって生成されたデルタが他のコラボレータに送信される場合、ダイナミクス・マネージャ２０６は通信マネージャ２０８と相互作用する。同様に、ダイナミクス・マネージャ２１２は通信マネージャ２１４と相互作用する。通信マネージャ２０８は内向きと外向きのデルタを適当な宛先へ配送するメカニズムである。好適実施態様において、通信マネージャはコンピュータで実行可能なプログラムとして実装することができ、このプログラムが別のリモート・パーソナルコンピュータまたは別の形のネットワーク接続可能な装置へネットワーク２１６上で送信するため通信マネージャ２０６によって開始されたデルタを配送し、またネットワーク２１６上で受信したリモートで生成されたデルタをダイナミクス・マネージャ２０６へ配送する。
【００２８】
一般に、通信マネージャ２０８、２１４はダイナミクス・マネージャ２０６、２１２によって生成された全デルタがコラボレーションに参加している全ユーザによって受信されるように構成される。それぞれのデルタは内部シーケンス番号を含みそれぞれのコラボレータのダイナミクス・マネージャは全部のデルタがいつ受信されたかを決定できるようにしてある。別のコラボレータからのデルタはそれぞれのコラボレータへ多数の違う経路を通って送信されることがあるので、デルタは生成された順序と同じ順序で到着するとは限らない。しかし、それぞれのコラボレータによって全デルタが受信され内部シーケンス番号を使って正しい順序でデルタを適用できる。したがって、それぞれのコラボレータによって保持されているローカル・データ・コピーは、全部のデルタで更新されると、コラボレーションの他のメンバーによって保持されているローカル・データ・コピーと一致することになる。
【００２９】
特定のコラボレーションに参加しているコラボレータの間での機密性を維持することが望ましい。これはデルタが公衆ネットワーク例えばインターネット上に送信される場合にとくに言えることである。情報のセキュリティにとって重要な３つの基本概念が存在する。その第１は認証で、これはデータ受信者がデータ作成者（ｄａｔａ ｓｏｕｒｃｅ）の同一性を知っており信用できることを保証するものである。第２は完全性で、データが転送中に変更されなかったことを保証するものである。完全性はデータ作成者以外のものによってデータを書き込むことができないことまた既知の作成者から到着したものであることを実効的に保証する。データ完全性は不正なデータの生成または「なりすまし」による第三者からの攻撃を防止する。最後のセキュリティ概念は機密性で、これは転送中のデータがデータ作成者とデータ受信者以外の第三者によって読み取ることができないことを保証するものである。機密性は第三者によるデータの読み取りまたは「盗聴」による攻撃を防止する。
【００３０】
前述したように、セキュリティはコラボレータが一つまたはそれ以上のアクティビティに参加して項目を共有したり、アクティビティの結果がユーザのパーソナル・コンピュータ上にあるいは他の形のネットワーク接続可能な装置上に永続的に保存されるような仮想空間に基づいている。仮想空間は「テレスペース」または「グループ」と呼ばれるもので各ユーザの装置の中で同期が保たれる。図示したセキュリティ／モデルによると、テレスペースのセキュリティは、テレスペースを形成して、メンバーを受け入れ、更にメンバーシップが安定したあとで「全体の」セキュリティとしてほとんどのユーザが体験するものである。これは安定状態デルタ・プロトコルと呼ばれグループ・メンバー間に渡されるデルタに含まれる情報の認証、完全性及び機密性に関連する。図３は５人のメンバーＭ０、Ｍ１、Ｍ２、Ｍ３、Ｍ４（３０２〜３１０）からなるテレスペースまたはグループ例３００の模式図である。各テレスペース３００内には一つまたはそれ以上のトライブまたはサブグループが存在する。図３には、３人のメンバーＭ２、Ｍ３、Ｍ４（３０６、３０８、３１０）からなるトライブ３１２が図示してある。
【００３１】
各メンバー３０２〜３１０はその内部に「プロトコル・エンジン」（それぞれエンジン３０３〜３１１）を有し、これは他のメンバーへセキュリティ・メッセージを送信しセキュリティ情報を操作するアプリケーション・プログラムである。
【００３２】
テレスペース３００とトライブ３１２において情報は一つまたはそれ以上の鍵により保護される。これは、Ｋとして示してある暗号化鍵と、Ｌで示したメッセージ認証／完全性コード（ＭＡＣ）鍵である。Ｋ及びＬ鍵は対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｉｐｈｅｒ）用の従来の鍵でありテレスペース全体への広がり（スコープ）を有する。本発明のシステムはブロック暗号化（ｂｌｏｃｋ ｃｉｐｈｅｒｓ）とストリーム暗号化（ｓｔｒｅａｍ ｃｉｐｈｅｒｓ）の両方を用いることができるが、メッセージ間での状態は維持されない。つまり一つのメッセージから次のメッセージへセキュリティ暗号ストリーム状態を維持するためには通信しているエンドポイントが必要とされない。この方法では、一時的な通信の中断が発生した場合にも再同期が必要とされない。
【００３３】
ブロック暗号化はカウンター・モードにおいて使用する度に必ず新しく無作為生成される初期化ベクトルを使って使用される。初期化ベクトルは暗号のブロック長と等しい長さを有し従来の方法による典型的なへッダ攻撃を妨害（ｔｈｗａｒｔ）するために使用する。ストリーム暗号化はブロック・モードにおいて初期ベクトルと鍵を組み合わせる、例えば排他的論理和演算により、ついですべてのメッセージで鍵文字列を再初期化することで使用される。この場合、初期ベクトルは鍵長と等しい長さを有する。初期ベクトルは一般に機密性保護されないしまたは認証／完全性の保護もされない。
【００３４】
更にすべての鍵がなんらかの種類の陳腐化メカニズム例えばタイムアウトを関連させるか一定数のメッセージまたはバイト数を保護すると想定する。このメカニズムはテレスペースによって決定されるローカル・ポリシーの一種で以下で説明するいずれのプロトコルでも送信する必要はない。
【００３５】
ＫＧ／ＬＧで示したグループ鍵は（それぞれ）暗号化／ＭＡＣ鍵で、グループ３００の全メンバーによって共有される。これらの鍵は第三者（グループ外の者）による攻撃からデルタに含まれる情報の機密性／完全性をそれぞれ保護するために使用される。同様に、ＫＴ／ＬＴで示したトライブ鍵は暗号化／ＭＡＣ鍵で、トライブ３１２の全メンバーによって共有される。これらの鍵はトライブ以外のグループ・メンバーや第三者による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。
【００３６】
更にＫ０１／Ｌ０１で示してある対になった鍵はメンバーＭ１とＭ２が共有しかつ他のグループ・メンバーの誰も共有していない暗号化／ＭＡＣ鍵（それぞれ）Ｍ０とＭ１で、Ｍ０とＭ１の間で双方向に通信を保護するために使用される双方向鍵である。これらの鍵はグループ・メンバーＭ２、Ｍ３、Ｍ４による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。同様に対になった鍵Ｋｉｊ／Ｌｉｊは別のメンバーの組み合わせＭｉとＭｊの間で交換される情報を他のグループ・メンバーによる攻撃から保護するために使用される。
【００３７】
テレスペース内で安定状態セキュリティは５段階のレベルの一つに組み込まれることになるが、そのレベルはテレスペース３００の作成者がテレスペースを作成する時点で選択できる。５レベルには何らの鍵も使用する必要がない低レベル・セキュリティを含む。このレベルは全く暗号セキュリティを提供しない。次のレベルは１対の鍵（ＫＧ／ＬＧ）をグループの全メンバーに対して使用する中程度レベルのセキュリティである。このレベルでは、ＫＧ／ＬＧ鍵のうちのＭＡＣ鍵ＬＧだけを使ってデルタを保護することにより認証／完全性が提供できる。同様に、認証／完全性及び機密性はＫＧ／ＬＧ鍵の両方を使ってデルタを保護することで提供できる。
【００３８】
次のレベルは高レベルのセキュリティで、グループ鍵ＫＧ／ＬＧと鍵ペアＫｉｊ／Ｌｉｊの組み合わせを使用する。認証／完全性だけが要求される場合にはＭＡＣ鍵のペア（Ｌｉｊ）だけを使用してデルタを保護し、グループ鍵（ＫＧ）は使用しない。これ以外に、認証／完全性／機密性が要求される場合にはグループ暗号化鍵ＫＧとＭＡＣ鍵ペアＬｉｊを使用してデルタを保護する。
【００３９】
中レベルと高レベルのセキュリティ・レベル双方で、暗号化鍵（Ｋｉｊ）とＭＡＣ鍵（Ｌｉｊ）のペアを使用してグループ鍵またはトライブ鍵（ＫＧ／ＬＧまたはＫＴ／ＬＴ）の再キーイングを行なう。
【００４０】
以上のレベルやモードはグループ（テレスペース）全体に適用可能であり、また全トライブ（サブグループ）にも同様に適用可能である。テレスペース内のトライブ全部がテレスペース自体と同一の「全体的セキュリティ」を有するので、グループに対して前述したレベルやモードは、前記のグループ鍵ＫＧ／ＬＧをトライブ鍵ＫＴ／ＬＴで置き換えればトライブに適用できる。
【００４１】
図４はグループ・メンバー間に情報を転送するのに使用する「デルタ」の内容を示す。各デルタはメッセージ・へッダ４００からなり、これにはセキュリティ・システムの特定の実装に依存する情報を含む。この情報にはプロトコルのバージョン番号を含められるので、ここにコラボレーション・システムとセキュリティ・サブシステム両方のバージョン番号を含められる。メッセージ・へッダ４００はメッセージ・フラグ種別またはタグＩＤも含み、これはメッセージの種類が異なるごとに異なる識別子である。メッセージ・へッダに含めることができる他の情報としては、構造化シーケンス番号がある。この番号はテレスペースのスコープを有する部分順列シーケンス番号で、そのスコープ内でメッセージの送信者とメッセージそれ自体の特定インスタンスとを論理的に同定する。
【００４２】
へッダ４００は機密を保護することができないが要求されるセキュリティ・レベルによっては実際にグループ・メンバー間に送出されるペイロードまたは情報を含むアプリケーション・データ４０２と全く同様に認証／完全性を保護する必要がある場合がある。例えば図４に図示してあるようなデルタが符号化される方法は希望するセキュリティ・レベルによって変化する。例えば、暗号としての意味でセキュリティを何も保証しない「低レベル」セキュリティ・モードでは、デルタは図４に図示したように送信され、へッダ情報４００がペイロード４０２よりも先に送信されるのが望ましいが、へッダとペイロードの順序は本発明の動作にとって重要ではない。この場合、第三者（非グループ・メンバー）がデルタ情報４０２を読み取るまたは盗聴でき、またデルタを書き込んだり真似たり、または「なりすます」ことができる。
【００４３】
前述の認証／完全性モードで動作する「中レベル」セキュリティ・システムの場合、デルタ情報は図５に図示したように保護される。更に詳しく説明すると、それぞれのデルタについて、へッダ情報５００が送信され、それに続けて鍵バージョン番号５０２、平文データ５０４、更に認証子５０６が送信される。ここでもこれらの要素の順序は重要ではない。認証子はデータ５０４の認証／完全性を保護しグループ・メンバーによって送信されたメッセージであることを保証するＭＡＣコード５０６とすることができるが、これはグループ認証鍵ＬＧを知っているのはグループのメンバーだけだからである。別の実施態様において、メッセージ認証子として公開鍵署名認証子を使用することもできる。この場合、メッセージ認証子５０６はハッシュして連結したへッダ及びデータの公開鍵署名で構成する。
【００４４】
好適実施態様において、鍵バージョン番号は２つの部分を有しており、これは「鍵識別子ＫｅｙＩｄｅｎｔｉｆｉｅｒ」と呼ばれるテレスペース全体で使われる独自の文字列と、「鍵バージョンＫｅｙＶｅｒｓｉｏｎ」と呼ばれるインクリメンタルなシーケンス番号である。鍵識別子はテレスペースの別のメンバーが独自に生成する鍵同士を識別するために必要とされる。一方のメンバーが、他方のメンバーも新しい鍵を生成していることについて知らないので、鍵識別子は鍵を個別に識別できるようにする。鍵バージョンは古い鍵、現在の鍵、新しい鍵を識別するために必要とされる。安定状態では、メンバーは鍵識別子の値は異なるが鍵バージョンの値が同じ一組の鍵を使用することになる。メンバーは現在の鍵バージョンの値よりも鍵バージョンの値が小さい「古い鍵」を削除することができる。
【００４５】
好適な実装において、ＭＡＣコード５０６は、最初にデータ５０４と連結したへッダ５００をハッシュし、次にハッシュの結果を従来のメッセージ認証アルゴリズムに沿って保護する。中間ハッシュ関数を使用して後述するような高セキュリティ・バージョンに沿った方法でＭＡＣコードを作成する。また従来のＭＡＣアルゴリズムを使用してグループ認証キーＬＧで単純にへッダとデータを保護すれば、中間ハッシュ関数を使用せずにこのモードを実装することも可能である。前述のように、認証／完全性モードにおいて動作する中レベルのセキュリティ・システムは、第三者が読んだり盗聴できるがグループ・メンバーだけが他のグループ・メンバーのデルタに書き込み、真似（ｉｍｐｅｒｓｏｎａｔｅ）または成りすまし（ｓｐｏｏｆ）できるようなセキュリティ・システムを作成する。
【００４６】
認証／完全性／機密性モードで動作する中レベルのセキュリティ・システムは図６に図示してあるようにデルタのデータを保護する。更に詳しく説明すれば、デルタは鍵バージョン番号６０２及び初期ベクトル６０３の付いたへッダを、データ６０４及びメッセージ認証コード６０６とともに送信することで伝達される。しかし、この場合、データ６０４は暗号化されている。このプロトコルはグループ暗号化鍵ＫＧで暗号化することでデルタ・データの機密性を保護しておりグループ認証子６０６による完全性と認証の保護が継続する。データ６０４は従来の暗号化アルゴリズムを用いてグループ暗号化鍵ＫＧで暗号化され、暗号化されたデータは初期ベクトルと連結される。ここでも認証またはＭＡＣコードは好適実施態様においてへッダと平文データの連結をハッシュ化してからグループ認証鍵ＬＧでハッシュ情報を符号化することにより形成されている。またデータとへッダ及びデータのハッシュの連結をひとつの暗号化キーＫＧで暗号化してからその結果をへッダ、鍵バージョン番号、初期ベクトルと連結することでこのモードを実装することも可能である。後者の暗号化は機密性と認証／完全性を両方とも保証し、２つの鍵ＫＧとＬＧの間で機密性及び認証・完全性の責任を分担する別々のＭＡＣ部分を使用しなくてすむ。図６に図示した実装を実際に使用して後述する高セキュリティ・モードに沿った実装を行なうことができる。
【００４７】
認証／完全性モードで動作する「高レベル」セキュリティ・システムにおいてデルタ・データは図５に図示した構成または図７に図示した構成のどちらかを用いて保護できる。このシステムで使用されるプロトコルは平文デルタ情報を送信するが、認証／完全性を保証するため、シングルターゲットの秘密鍵多重認証子か公開鍵署名認証子のいずれかを使用する。
【００４８】
シングルターゲット秘密鍵多重認証子の場合、図５に図示した構成を使用する。更に詳しく説明すれば、へッダ情報５００は鍵バージョン５０２、暗号化していないデータ５０４、メッセージ認証子５０６とともに送信される。しかし、この場合、鍵バージョン番号５０２は送信者と受信者全部との間の鍵バージョンのすべてを連結したもので構成する。同様に、メッセージ認証子５０６は送信者とそれぞれの受信者との間の個別のメッセージ認証子を連結したもので構成する。それぞれのメッセージ認証子は認証鍵で保護されるが、この認証鍵は送信者と受信者との間でのみ使用されるものである（Ｌｉｊ鍵の一つ）。
【００４９】
更に、好適実施態様では、中間ハッシュをメッセージ認証コードに使用する。更に詳しく説明すると、へッダとデータは連結され、ハッシュされ、更に適当な認証鍵によって保護される。この場合、中間ハッシュは認証鍵それぞれに対してへッダとデルタ全体を再ハッシュするのを避けるために使用している。へッダとデルタをハッシュしたら、適当な認証鍵でハッシュした情報を単純に保護することでこのハッシュを複数回使用できる。
【００５０】
別の実施態様では、公開鍵署名認証子をメッセージ認証コードとして使用する。この構成が図７に図示してある。この構成では、へッダ情報７００が最初に送信され、これに暗号化されていない（Ａ／Ｉモード）または暗号化された（Ａ／Ｉ／Ｃモード）データ７０２が続く。メッセージ認証子コード７０４はハッシュし連結したへッダとデータの公開鍵署名から構成される。
【００５１】
認証／完全性／機密性モードで動作する高レベルセキュリティ・システムは図６と図７に図示したデルタ構成でデータを保護する。基本的にこれは図５と図７に図示してある認証／完全性モードと同じであるが、グループ暗号化鍵ＫＧでデルタ・データが暗号化され図６の場合の初期ベクトルと連結される点で異なっている。
【００５２】
デジタル署名またはデジタル証明書を生成して使用するメカニズムが図８に図示してある。データ８００のデジタル署名を生成するためには、多数の一般的に周知のハッシュ・アルゴリズムの一つを用いて、ステップ８０２に示してあるようにデータ８００のハッシュ値を計算する。ハッシュしたデータはステップ８０４に示したように（暗号化と同様の演算で）公開鍵／秘密鍵ペアのうちの秘密鍵を用いて署名される。その結果がデジタル署名８０６である。更に、データがユーザのＩＤまたは公開鍵に関係する場合、（署名ではなく）データはデジタル「証明書」と呼ばれる。
【００５３】
デジタル署名を使用するには、図８で破線より下に示してあるように有効化手順を実行する。更に詳しく説明すると、ハッシュしたデータの確認（復号に似た動作）のために公開鍵／秘密鍵ペアのうちの公開鍵を使用する署名確認アルゴリズム８１４へ、デジタル署名が矢印８１２で示したように提供され、また証明書が矢印８１８で示したように提供される。データ８００それ自体は矢印８０８で示したようにハッシュ・アルゴリズム８１０へ提供される。このハッシュ・アルゴリズムはデジタル署名を生成するために使用したハッシュ・アルゴリズム８０２と同一のものである。囲み８１６に示したように、データの再ハッシュが確認したハッシュ・データと比較される。結果が同一であれば、確認したハッシュ・データは正しい、すなわちデータは正しく（ａｕｔｈｅｎｔｉｃａｌｌｙ）署名に関連している。
【００５４】
機密グループを形成する手順が模式的に図９に図示してありそのステップが図１０に図示してある。図９に図示してあるように、グループ９００は議長９０２とその他のＮ−１人のメンバーで構成され、そのうち３人がメンバー９０６、９０８、９１０として示してある。グループ９００の形成は議長９０２によって管理され、議長は新しいメンバーを招待して追加する権限を与えられたメンバーである。図示した手順によれば、招待者９０４は初期認証の後でグループ９００へ追加される。以下の議論では認証及び完全性による最高セキュリティ・モードに焦点を当てて説明する。その他の意図されるモードはこのモードから派生させることができる。
【００５５】
加入手順はステップ１０００から始まりステップ１００２に進む。ステップ１００２では、議長９０２が招待されることになる人９０４へ招待メッセージを送信する。このメッセージは図９の矢印９１２で模式的に示してある。このメッセージの内容は図１１に示してある。メッセージはへッダ１１００と、これに続く招待者の名前１１０２から構成され、この名前はＵＲＬやその他の識別情報とすることができる。へッダの順序は本発明の原理から逸脱することなく反転できる。招待者の名前に続くのが署名済み招待「ナンス」（ｎｏｎｃｅ）１１０４である。署名済みナンスは議長によって生成されたタイムスタンプのハッシュ、議長９０２の名前／ＵＲＬ、招待者９０４の証明書（入手可能な場合）、テレスペースの名前／ＵＲＬ、署名つきナンスが発生することが考えられる別の状況を識別するために使用されるタグである招待「オプコード」（Ｏｐｃｏｄｅ）を含む署名データである。
【００５６】
一般的に言って、ナンスはプリンシパルＡが生成してプリンシパルＢへ送信するもので時間とともに変化するパラメータであり、これは任意の状況で一回だけ使用されるものである（例えば、本明細書で説明している招待プロトコルを介してＡがＢを招待する場合など）。実際に、ナンスは状況を定義する、言い換えればプロトコル動作の同時性を保証して再生（ｒｅｐｌａｙ）及びインターリーブ攻撃（ｉｎｔｅｒｌｅａｖｉｎｇ ａｔｔａｃｋ）を防止するために使用される。ナンスは秘密にしなくても良く、１回限りの独自なものであれば良い。各種システムで使用されるナンスの典型的な例としては次のようなものがあげられる：衝突しない乱数、タイムスタンプ（十分に信頼できるクロックを備えたシステム、特に信頼できる分散時刻同期プロトコルの存在下ではほぼ理想的である）、シーケンス番号。好適実施態様ではタイムスタンプが使用されている。
【００５７】
本明細書の状況で重要なことは、プロトコルの実行の全部において、ナンスが（暗号学的な確実性の範囲で）絶対に（ローカル・ポリシーで決定されるなんらかの時間的制約の中で）反復できないことである。これは例えば自分が発行したナンス／招待を（プロトコルの実行に関する他の情報とともに）、不揮発記憶に、ローカル・クロックに合わせてある程度の期間（ローカル・ポリシーによって変化する）、メンバーが記憶しておくことで実現可能で、この時刻以降はナンス情報を破棄してプロトコルの実行を中断させなければならない。
【００５８】
署名つきナンス１１０４に続くのは暗号データ１１０６で、これはこのメッセージで使用されるセキュリティ状態情報である。この情報は議長が選択し受信者がメッセージを正しく解釈できるようにするために必要である。更に詳しくは後述するようなワンタイム鍵で情報を暗号化するのに使用したアルゴリズムの名称の文字列を含む。またメッセージ受信者がメッセージを処理するのに必要なその他なんらかの情報、例えば鍵の長さ、ラウンド数、使用したハッシュ・アルゴリズムの名称、鍵ジェネレータ・アルゴリズムの名称、なども含む。
【００５９】
暗号データ１１０６に続くのは、公開鍵暗号化アルゴリズムに基づいてあらかじめなんらかの合意が得られている招待者の公開鍵で暗号化したワンタイム鍵情報１１０８である。ワンタイム鍵は対称暗号化用の鍵で後述するように招待情報を暗号化するために一回だけ使用される。
【００６０】
鍵情報に続くのが招待情報１１１０で、これはワンタイム鍵で暗号化されている。招待情報も前述したように議長によって生成されたタイムスタンプを含み初期ベクトルと連結できる。招待情報はテレスペース名／ＵＲＬを含むアプリケーション・データで招待者９０４に招待を発行したアクティビティの種類について通知する。これは特に、議長９０２によって権限を委譲（ｍａｎｄａｔｅｄ）されたものとしてテレスペース内で使用しなければならない暗号情報（例えば前述の低／中／高レベル、Ａ／Ｉ／Ｃモード）を含む。このようにすると、招待者には参加するように招待されているテレスペースのセキュリティ特性が招待者に通知され、例えば招待者は参加しないと決定することができる。招待者の証明書が不明な場合、暗号化したワンタイム鍵１１０８を無視しタイムスタンプと招待情報１１１０を暗号化しないで送信する。
【００６１】
招待情報１１１０に続くのはへッダ情報１１００、招待ナンス１１０４、暗号化していないワンタイム鍵（メッセージに含まれる場合）、暗号データ１１０６、暗号化していない招待情報（タイムスタンプなし）のハッシュに対する議長の署名である。この署名は議長の証明書に対して示された情報の全部を結合するもので、議長の証明書は招待者のローカルな公開鍵証明書有効化ポリシーを介して議長に結び付けられている。
【００６２】
送信される情報の最後の部分１１１４は議長の証明書で、議長の名称（ＵＲＬ／ペルソナ）、議長の公開署名確認鍵、及びその他の情報例えば公開鍵アルゴリズム識別子、暗号化公開鍵、などが含まれ、これらすべてが（一つまたはそれ以上の）なんらかの「信頼できる」認証局の署名を介して相互に結合されている。証明書は周知のまたは少なくとも招待者に識別可能ななんらかの証明書フォーマットにフォーマットされる。このフォーマットは公開鍵による証明書（ここで証明書認証局は周知の認証局の階層の内部に組み込まれている）、またはＰＧＰやＳＤＳＩなどを使用した「信頼の輪証明書」（ｗｅｂ−ｏｆ−ｔｒｕｓｔ ｃｅｒｔｉｆｉｃａｔｅ）、あるいは更に単純にこの目的のためだけにその場で構成した自己署名証明書であっても良い。招待者が証明書を頼れる「信頼度」は招待者のローカル公開鍵証明書有効化ポリシーに依存する。
【００６３】
このメッセージを受信すると、招待者は図１５に図示してあるフローチャートに概略してあるステップをとる。招待者の手順はステップ１５００から始まってステップ１５０２へと進み、ここで招待者が暗号データ１１０６を調べてメッセージの暗号化に使用されているアルゴリズムを知る。次にステップ１５０４で、招待者は招待者の名前を検証してその招待が招待者に向けられたものかどうかを確認する。
【００６４】
次に、ステップ１５０６で、招待者が招待者のローカルな公開鍵有効化ポリシーに従って議長の名前／ＵＲＬを含む議長の証明書を有効化する。招待者は適当な証明書有効化プロバイダ（招待者のローカル・ポリシーになっている場合にはｔｒｉｖｉａｌ／初期設定で「自己署名証明書をすべて信頼する」有効化アルゴリズムが実装することがある）を起動することにより行なう。
【００６５】
ステップ１５０８で、招待者は議長の署名を確認してこの招待が本当に議長９０２から来たものかどうかを確かめ招待者９０４が本当に招待されたのかを確かめる。
【００６６】
最後にステップ１５１０で、招待者は招待情報を復号して検証し招待者が議長の招待を受け入れたいかどうかを決定する。そして手順はステップ１５１２で終了する。
【００６７】
図１０に戻ると、招待者９０４が招待を受け入れることに決定した場合、ステップ１００４で招待者９０４は議長９０２へ受諾メッセージを送信して応答する。このメッセージが図９では矢印９１４として模式的に図示してある。これ以外に、招待者が招待を受け入れないと決定した場合、エラーメッセージを招待者９０４から議長９０２へ送信する。
【００６８】
受諾メッセージの内容が図１２に図示してある。メッセージはへッダ１２００と、これに続く署名付きの招待ナンス１２０２で構成され、ナンスは招待メッセージで議長から招待者へ送信されたものである。これを用いることで、議長はこの受諾メッセージが招待に応答したものであると認識できることになる。署名付きナンス１２０２には署名つき受諾ナンス１２０４が続く。署名付き受諾ナンスは招待者が生成したタイムスタンプ、招待者９０４の名前／ＵＲＬ、議長９０２の証明書、テレスペースの名前／ＵＲＬ、そして受諾オプコードを含む。
【００６９】
ナンス１２０４には暗号データ１１０６と同様のセキュリティ内容暗号データ１２０６が続く。
【００７０】
次に、公開鍵暗号化メカニズムを使用して、新しく生成したワンタイム鍵１２０８の公開鍵暗号を送信し、パラメータ、情報、公開鍵暗号化鍵が議長９０２から招待者９０４へ送信される（例えば公開ＲＳＡ暗号鍵）。
【００７１】
暗号化ワンタイム鍵１２０８に続くのはアプリケーション・データ１２１０で、これにはワンタイム鍵を使用して暗号化した２個のタイムスタンプと受諾データを含む。この情報１２１０は招待者９０４の受諾について議長９０２に通知するものである。
【００７２】
次に、招待者９０４の署名を送信する。この署名はへッダ情報１２００、議長の名前と招待者のナンス１２０２に受諾ナンス１２０４を連結したもの、暗号化していないワンタイム鍵、暗号データ１２０６と暗号化していない受諾情報（タイムスタンプなし）のハッシュによる。この署名は招待者の証明書にすべての示された情報を結合する（証明書は更に議長の証明書公開鍵有効化ポリシーを介して招待者９０４に結合されている）。議長９０２の名前がこの署名のスコープ内に含まれ招待者が署名した、議長には分かっているワンタイム鍵を議長が第三者へ送信するのを防止し、これにより招待者９０４を真似なければならないことに注意する。最後に、招待者の証明書１２１４を送信する。
このメッセージの受信時に、議長９０２は図１６のフローチャートに示してある手順を実行する。この手順はステップ１６００から始まりステップ１６０２に進み、ここで議長９０２が暗号化されたワンタイム鍵を復号し、これにより鍵を取り込む。
【００７３】
次に、ステップ１６０４で、議長９０２はワンタイム鍵を使って暗号化された受諾情報を復号する。次にステップ１６０６で、議長は招待者の証明書を検証して招待者の名前を取り出す。
【００７４】
ステップ１６０８で、議長９０２は招待ナンスを再計算して再計算したナンスと受信した招待ナンスとを調べ受諾メッセージが応答している招待がどれかを決定する。本発明の一つの態様によれば招待ナンス（図１１の１１０４）は「ステートレス」つまり関連するタイミングとは無関係に解釈できることに注意する。例えば、メンバーＡが装置１から招待者Ｂへ招待を発行したが後にＢの受諾を装置２で受信したと仮定する。オリジナルの招待メッセージではナンスがデルタ経由でＡの使用可能な全装置へ送信されたとしても、招待者Ｂからの受諾メッセージは招待ナンスを伝達するデルタより先に装置２に到着することがあり装置２でのソフトウェアによる比較ができない場合がある。この問題を回避するため、ナンスに関連した情報は装置２を含めた当該メンバーの装置の全部で視覚的に表示される。この表示の一例が図２３に示してあり表示は例えばユーザ・インタフェース・ダイアログボックス２３００経由で、またはその他の類似のメカニズムを介して行なわれる。図２３に図示してあるように、３項目の情報がダイアログ・ボックス２３００に表示される。これは、招待者Ｂの題名２３０２、招待者Ｂの証明書のメッセージ・ダイジェスト２３０４、及び招待メッセージ署名ナンス２３０５からのタイムスタンプである。
【００７５】
送信者の「証明書」は重要な２項目の情報を伝達するパッケージである：これはメッセージ送信者の「題名」と送信者の「公開鍵」である。この場合、Ｂの題名は装置２のプロトコル・エンジンによって抽出されダイアログ・ボックス２３００のテキストボックス２３０２に表示されている。この名前の一例としては、「ｗｔｕｖｅｌｌ＠ｇｒｏｏｖｅ．ｎｅｔ」がある。Ａはこれで受諾メッセージが招待に対応することを確認できる。
【００７６】
受諾を有効化するためには、Ａはすでに招待者Ｂの対象者名を知っているので、Ａは本発明のコラボレーション・システムとは別の経路から認証のメッセージ・ダイジェストを受け取る必要がある。例えば、この情報を受け取る代表的な方法はＡがＢを電話で呼び出して証明書のメッセージ・ダイジェストがどのようなものなのかを尋ねることである。例えば、この計算したメッセージ・ダイジェストは「０ａ，１ｂ，２ｃ，３ｄ；４ｅ，５ｆ，６ａ，７ｂ；８ｃ，９ｄ，ａｅ，ｃｆ；ｃ１，ｄ２，ｅ３，ｆ４；０５，１６，２７，３８；４９，５ａ，６ｂ，７ｃ」といったようなものになる。
【００７７】
Ａが受諾メッセージを介してＢの証明書を受け取ったら、メッセージ・ダイジェスト（または証明書の「フィンガープリント」）を、受諾メッセージのＢの証明書１２１４から、従来のメッセージ・ダイジェスト・アルゴリズム（例えばＭＤ５やＳＨＡ１など）を用いて図２１と図２２に図示してあるセキュリティ・サービス・アーキテクチャにより、アルゴリズム的に計算する。この再計算したメッセージ・ダイジェストがボックス２３０４に表示される。再計算したメッセージ・ダイジェストがすでに分かっている正しいメッセージ・ダイジェストと一致すれば、Ａは提示された証明書が正しいものであるとして受け入れることができる。それ以外の場合には破棄される。この操作は「証明書有効化」と呼ばれる。
【００７８】
「署名付きナンス」はメッセージの署名である。従って、メッセージのタイムスタンプと送信者の証明書を含む情報を互いに結び付ける。「再生攻撃」を避けるためには（すでに送信された正しいメッセージを再送することによる攻撃）、受諾メッセージに含まれている招待ナンス１２０２のタイムスタンプが受け入れ可能な範囲内にあることを確認することも必要である。タイムスタンプ情報はナンスから抽出されてダイアログボックス２３００のボックス２３０５に表示される。この情報は、例えば、「２００００４０７１２１１２４Ｚにあるｎａｓｈｔｇｉｒｉ＠ｇｒｏｏｖｅ．ｎｅｔあての招待メッセージ」といったものである。Ａは幾らか早い時刻にタイムスタンプを生成したのであるから、おそらくＡはその時刻を知っている。メンバーＡはタイムスタンプを解釈して情報が受け入れられるものかどうかを決定できる。メンバーＡが情報を受け入れる場合には、ＯＫボタン２３０６をクリックし、そうではないなら中止ボタン２３０８をクリックする。
【００７９】
同様の問題は招待者Ｂが受諾を送信した装置とは別の装置でテレスペース・データを受け取った場合にも発生する。この後者の問題は同じ方法で処理される。
【００８０】
次に、ステップ１６１０で、議長９０２は議長のローカル公開鍵ポリシーにしたがって招待者の証明書を有効化する。議長がすでに招待者の証明書を先の招待メッセージの時点で持っているならこのステップは省略しても良く、その時点で行なった有効化に満足している。議長は適当な証明書有効化プロバイダを起動することによりこの有効化を行なう。
【００８１】
次に、ステップ１６１２で、議長９０２は招待者の署名を確認し、招待者の署名は更に受諾メッセージの認証／完全性を確認し、この受諾が本当に招待者９０４から来たものであることを確かめる。
【００８２】
次に、ステップ１６１４で、議長は復号した受諾情報を検証して招待情報と一致することを確認し、議長が招待者の受諾を認めたいかどうかを決定する。
最後に、ステップ１６１６で、オプションで追加の署名として議長は自分自身の署名を招待者の証明書に追加することができる。この追加署名によってポリシーが有効になるのでグループ・メンバーは議長９０２の証明書を信頼している限り招待者の証明書を有効化できる。
【００８３】
手順はステップ１６１８で終了し、情報が真正なものなら招待者はこれ以後「テレスペースのメンバー」となる。図１０に戻って、ステップ１００６に記載してあるように、議長９０２が「新規メンバー追加」デルタをグループ９００に存在する全メンバーに送信する。これらの新規メンバー・メッセージは図９で矢印９１６、９１８、９２０として模式的に示してある。
【００８４】
議長が他のそれまでに存在しているメンバーへ送信する新規メンバー追加メッセージの内容が図１３に示してある。デルタ・メッセージはへッダ１３００と、これに続けて統合鍵バージョン番号情報を含み、鍵バージョン情報はグループ鍵とすべての認証／完全性の鍵についての全部の鍵バージョン番号を連結したものである。
【００８５】
統合鍵バージョン１３０２には、暗号化した新規グループ暗号鍵及び認証鍵の連結からなる再キーイング情報１３０４が続く。それぞれのメンバー対に対して、グループ暗号鍵及び認証鍵を連結したものがメンバー同士で対になった鍵を使って暗号化され、結果が初期ベクトルと連結される。これらの連結された鍵が更に連結されて統合再キーイング情報１３０４を形成する。新しいキーは古い／現在のグループ鍵ＫＧ／ＬＧを置き換える。新規に追加されたメンバーは古い／現在のグループ鍵を知ることはない。この再キーイングは新規メンバーがそれ以前のテレスペース通信を記録したり読み取れないようにするために必要である。
【００８６】
次に、新規グループ暗号鍵で暗号化し初期ベクトル１３０６と連結した参加情報を送信する。このデルタの内容は、招待者の名前に招待者の証明書と参加情報を連結したものである。参加情報は議長９０２が生成したアプリケーション・データで、他のグループ・メンバーが、メンバー・マネージャ情報を含めて、知る必要のある新規メンバーについての情報に関連する。またテレスペースのメンバーやその他各種情報例えば招待者の役割などのリストを含めることができる。
【００８７】
最後に、メッセージ多重認証コード１３０８を送信する。これは議長と各メンバーの間の認証子を連結したものとすることができる。各認証子は議長からメンバーへのペアになった認証鍵Ｌ０ｊで保護されているハッシュ情報である。ハッシュ情報はへッダ１３００と、統合新規グループ鍵情報１３０４と、暗号化していないデルタ情報を含む。これ以外に、メッセージ認証コードは前述のハッシュ情報の議長署名とすることができる。
【００８８】
図１３に示したメッセージを受け取ると、各メンバー９０６〜９１０は図１７のフローチャートに示してあるステップを実行する。この手順はステップ１７００で始まりステップ１７０２へ進み、ここでメンバーが暗号化されたグループ鍵を復号し、これによって新しいグループ鍵ＫＧ／ＬＧを知る。しかし、各メンバーは、ＫＧ／ＬＧで保護された古いデータが存在しないことを確認するのに必要とされる限り、古い／現在のグループ鍵ＫＧ／ＬＧの知識を保持している必要がある。その後、各メンバーは古い鍵ＫＧ／ＬＧを破棄しその痕跡をすべて抹消する。
【００８９】
次に、ステップ１７０４で、暗号化されたデルタ情報を各メンバーが復号し、これによってデルタ内の情報を知る。ステップ１７０６では、メンバーが認証鍵で暗号化された多重認証子の項目を介して、メッセージの認証／完全性を確認する。
【００９０】
次に、ステップ１７０８で、メンバーは議長９０２が（議長のＩＤはへッダ情報として送信される）議長であること、また新規メンバーを追加する権限があることを確かめる。
【００９１】
ステップ１７１０では、メンバーがデルタ情報を実行する。これを行なう最中に、メンバーは招待者の名前、証明書、参加情報を含めた新規メンバー・マネージャ情報に気づく。手順はステップ１７１２で終了する。
【００９２】
最後に、図１０に戻って、ステップ１００８で、矢印９２２で模式的に示したように、議長９０２が招待者９０４へテレスペース情報を送信する。手順はステップ１０１０で終了する。テレスペース情報は図１４に示したメッセージとともに招待者９０４へ送信される。この情報はへッダ１４００で始まり、ノンス１２０４と同一の署名つき受諾ナンスが続く。これに、図１２に示した受諾メッセージに関連して説明したように暗号データ１４０４と暗号化したワンタイム鍵（これは新規に生成する）１４０６が続く。
【００９３】
暗号化したワンタイム鍵１４０６のあとには直前のメッセージ部分にあるワンタイム鍵で暗号化されたテレスペース（ＴＳＰ）データが続く。このデータはワンタイム鍵で暗号化したペイロードと連結された初期ベクトルを含む。ペイロードは招待者が生成したタイムスタンプと連結グループ暗号及び認証鍵ＫＧ／ＬＧ、及びＴＳＰデータである。ＴＳＰデータは招待者がメンバーから受信を許可されているＴＳＰデータのメンバーによるバージョンを含むアプリケーション・データである。
【００９４】
暗号化されたＴＳＰデータ１４０８には、へッダ１４００、招待者の名前、署名付きナンス１４０２、連結グループ暗号及び認証鍵、暗号化していないワンタイム鍵、暗号情報１４０４、暗号化していないＴＳＰデータを含むハッシュ情報に対する議長の署名１４１０が続く。最後に、議長の証明書１４１２が後続する。
【００９５】
このメッセージを受信すると、招待者９０４は図１８に示した手順を実行し、手順はステップ１８００で始まりステップ１８０２へ進みここで招待者９０４は暗号化された１回限りの鍵（以下、ワンタイム鍵）を復号してワンタイム鍵を取り出す。
【００９６】
次に、ステップ１８０４で、招待者はワンタイム鍵を使用して暗号化されたＴＳＰデータを復号し、ＴＳＰ情報を取り出す。次に、ステップ１８０６で、招待者９０４は署名つき受諾ナンスを再計算してこれと受信したナンスとを比較してこれが受け入れられるものであることを確認する。先に説明したように、この比較はソフトウェアでまたは視覚的検査によって行なうことができる。このノンスは議長の証明書を含んでいるので、招待者はこの証明書を再有効化する必要がない。
【００９７】
ステップ１８０６では、招待者９０４が議長の署名を検証し、ステップ１８０８では、招待者が復号したＴＳＰデータを初期の「作成中テレスペース」に広める。唯一残っている、なすべきことはテレスペースの他のすべてのメンバーと鍵ペアを交換することで、そのあと、招待者はテレスペースの完全なメンバーとなる。
【００９８】
鍵ペアは再キーイング手順で交換でき、ここで再キーイング情報は他の情報を搬送するデルタに「ピギーバック（相乗り）」する形になる。この再キーイングを実行するための一つのプロトコルは図１３に示した新規メンバー追加デルタ・メッセージで前述した。再キーイング情報は他のデルタ・メッセージに挿入することもできる。このようなピギーバック型デルタ・メッセージは通常のデルタ・メッセージだが、鍵変更（グループ／テレスペース鍵（ＫＧ／ＬＧ）、トライブ／サブグループ鍵（トライブＴ１、ＴｎについてＫＴ１／ＬＴ１、ＫＴｎ／ＬＴｎ）及び／または鍵ペア（Ｋｉｊ／Ｌｉｊ）のあらゆる組み合わせに同時に関係する）がデルタ・メッセージにピギーバックする点で異なっている。デルタそれ自体は同時にトライブＴｋに適した新しい鍵で暗号化される。新しい（再キーイングされた）鍵はこのメッセージで搬送される。鍵ペアがメッセージにピギーバックしている場合、メッセージは公開鍵署名認証子によって保護される。それ以外の場合では、メッセージは現在の鍵ペアを用いる多重認証コードによって保護される。
【００９９】
このようなメッセージの一例が図１９に示してある。デルタ・メッセージはへッダ１９００と、これに続く統合鍵バージョン情報１９０２を含み、統合鍵バージョン情報は新規グループ鍵とすべての新規トライブ認証／完全性鍵についてのすべての鍵バージョン番号の連結である。
【０１００】
統合鍵バージョン情報１９０２には第２のセクション１９０４が続き、これも統合鍵バージョン情報を含む。鍵ペア変更が送信中の場合、この情報は新しい鍵ペアについてのすべての鍵バージョン番号の連結を含む。別の場合は、グループ鍵とトライブ鍵を再キーイングしている場合情報１９０４は古いまたは現在の鍵ペアについての統合鍵バージョン情報を含む。
【０１０１】
統合鍵バージョン１９０４に続くのが統合再キーイング情報１９０６で、これは新しいグループ及びトライブ鍵（ＫＧ／ＬＧ及びＫＴ／ＬＴ）の連結から構成される。各メンバーのペアについて、連結されたグループ暗号化及び認証鍵はメンバーのペアに対して鍵ペアを用いて暗号化され、その結果が初期化ベクトルに連結される。これらの連結された鍵はそれら自身連結されて統合再キーイング情報１９０６を形成する。新しい鍵は古い／現在のグループ鍵ＫＧ／ＬＧを置換する。新しい鍵ペアが転送中の場合、統合グループ再キーイング情報には新しい鍵ペアに対する統合再キーイング情報が続く。各メンバーのＫ／Ｌ鍵は連結されそのメンバーの公開鍵を用いて暗号化される。これらの暗号化された鍵は連結されて統合鍵ペア再キーイング情報を形成する。
【０１０２】
次に、新しいグループ暗号化鍵で暗号化されて、新しい鍵１９０８に対応する初期ベクトルに連結されたデルタ情報が送信される。このデルタの内容は従来のあらゆるデルタ・メッセージとすることができる。
【０１０３】
最後に、メッセージ多重認証コード１９１０が送信される。これはメンバー間の認証子を連結したものとすることができる。それぞれの認証子は送信側メンバーから受信側メンバーへのペアになった認証鍵Ｌｉｊで保護されたハッシュ情報である。ハッシュ情報はへッダ１９００と、統合新規グループ鍵情報１９０４（またこれが送信中の場合には統合新規鍵ペア情報）、更に暗号化されてないデルタ情報を含む。ペアになった鍵がメッセージにピギーバックしている場合には、多重認証コードの代わりに、公開鍵署名認証子を送信する。
【０１０４】
前述のセキュリティ・システムは様々な方法で実装できる。好適実施態様では、図２０に模式的に示したプロバイダ・アーキテクチャを使用する。このようなアーキテクチャが好ましいのは、前述したセキュリティ・プロトコルが「アルゴリズム中立」であることによる、つまり特定の暗号化及び保護アルゴリズムに依存していないためである。このプロトコルはアルゴリズムに中立なインフラストラクチャ例えば図２０に図示してあるそれを利用できる。図２０は縦方向の次元と横方向の次元で構成される２次元構造を示す。縦方向の次元は数個の抽象層から構成され、横方向の次元は縦方向の層を含めた各種アプリケーション及びサービスで構成される。最上部の層はアプリケーション層で、アプリケーションの組を含み、そのうちのアプリケーション２０００と２００２が図示してある。これらのアプリケーションには、分散通信システム及びコラボレーション・システム、例えば前述のコラボレーション・システムや、保護データ記憶、可用性（サービスの非拒絶）、システム管理、医療情報システム、航空管制システム、原子力発電所、軍事情報作戦指令管制システムなどを含み、これだけに限定されない。
【０１０５】
アプリケーション２０００及び２００２は一つまたはそれ以上のセキュリティ・サービスにアクセスするが、そのうちサービス２００４と２００６を図示してある。これらのサービスには、例えば識別、認証、完全性、機密性、プライバシー、許可、権威の代理、アカウンタビリティと非拒絶、タイムスタンプ、公証（ｎｏｔａｒｉｚａｔｉｏｎ）、監査、信頼ポリシー管理、侵入検知及び復旧サービスなどを含む。
【０１０６】
セキュリティ・サービスは抽象プリミティブ・サービス２００８と２０１０を含む抽象（またはアルゴリズムに中立な）プリミティブ・サービスの組み合わせにより実装される。抽象プリミティブ・サービスは実際には具象（またはアルゴリズム特異的な）プリミティブ・サービスの組み合わせによって実装される。例えば、抽象プリミティブ・サービス２００８は具象プリミティブ・サービス２０１２、２０１４、２０１６により実装され、一方抽象プリミティブ・サービス２０１０は具象プリミティブ・サービス２０１８、２０２０、２０２２によって実装される。これらの具象プリミティブ・サービスは例えば特定の暗号サービスやプロトコルなどのサービスを含む。
【０１０７】
各抽象層は高次の抽象層または層群によって消費されるサービスを作成する。好適な実装では、アプリケーション２０００、２００２とセキュリティ・サービス２００４、２００６の間の関連性、ならびにセキュリティ・サービス２００４、２００６と抽象プリミティブ・サービス２００８、２０１０の間の関連性は従来どおりの、これらの層の間で静的なコンパイル時に決定される結合（ｃｏｍｐｉｌｅ−ｔｉｍｅ ｂｉｎｄｉｎｇｓ）である。しかし抽象プリミティブ・サービス２００８、２０１０と具象プリミティブ・サービス（２０１２、２０１４、２０１６、２０１８、２０２０、２０２２）の間の結合は、制約された方法で一つの抽象プリミティブ・サービスと一つまたはそれ以上の具象プリミティブ・サービスを関連づける動的なランタイム結合であるのが望ましい。この動的な結合は「プロバイダ・アーキテクチャ」と呼ばれ、抽象またはアルゴリズム中立なプリミティブ・サービスをなんらかの具象またはアルゴリズム特定のそれで作成することにより実装できるメカニズムであり、実装は任意の時刻にその環境内でアクティブにすることができるようなものである。
【０１０８】
図２１と図２２はプロバイダ・アーキテクチャの特定の実装を模式的に示している。オブジェクト指向プログラミング技術をこの実装では用いているが、他の等価な技術やプログラミング言語で実装することもできることは当業者に理解されるであろう。更に詳しく説明すると、図示した実装はダイナミック・リンク・ライブラリ（ＤＬＬ）を使用して各種サービスを提供している。
【０１０９】
ＤＬＬは図２１と図２２のそれぞれに図示してある。図２１に図示したＤＬＬ はセキュリティ・サービス・マネージャ（ＳＳＭ）と呼ばれるもので、図２２に図示したＤＬＬはセキュリティ・サービス・プロバイダ（ＳＳＰまたは単にプロバイダ）と呼ばれる。セキュリティ・サブシステムのどのランタイム・インスタンシエーションにも必ず一つだけＳＳＭ ＤＬＬがロードされる。一方でＳＳＰ ＤＬＬは何個でもロードでき、それらがすべて独立しているという制限が加えられるだけである（これらがすべてシステム・レジストリなどのファイルに記録されている通りの独立したＬＩＢＩＤとファイル名を有するという意味で）。ＳＳＰ ＤＬＬの名称はそのデベロッパが選択する。図示したＳＳＰ ＤＬＬの例はＳｅｃＰｒｏｖＸＸＸ．ｄｌｌというような名前がつけられていると考えられ、他のＤＬＬはＳｅｃＹＹＹＰｒｏｖ．ｄｌｌまたはＺＺＺＳｅｃＰｒｏｖ．ｄｌｌというような名前をつけることができる。
【０１１０】
図２１と図２２のボックスはマイクロソフト・コモン・オブジェクト・モデル（Ｍｉｃｒｏｓｏｆｔ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に適合するＣＯＭクラスを示す。これらのクラスは、エンジン・クラス（右側に示す）と非エンジン・クラス（左側に示す）の２種類のグループに大別される。ＣＯＭエンジン・クラスのそれぞれは一つだけＩＤＬインタフェースを実装してエクスポートする。例えば、エンジン・クラス２１０６（ＭｅｓｓａｇｅＤｉｇｅｓｔ）はインタフェース２１０４（ＩＭｅｓｓａｇｅＤｉｇｅｓｔ）をエクスポートし、エンジン・クラス２１１８（ＫｅｙＧｅｎｅｒａｔｏｒ）はインタフェース２１１６（ＩＫｅｙＧｅｎｅｒａｔｏｒ）をエクスポートし、エンジン・クラス２１２６（Ｃｉｐｈｅｒ）はインタフェース２１２４（ＩＣｉｐｈｅｒ）をエクスポートする。これはインタフェース２１００をエクスポートするＳｅｃｕｒｉｔｙクラス２１０２についても言えることである。図２２に図示した具象クラスについても同じことが当てはまる。例えば、具象エンジン・クラス２２０４（ＸＸＸＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ）はインタフェース２２０６（ＩＭｅｓｓａｇｅＤｉｇｓｅｔＳｐｉ）をエクスポートし、エンジン・クラス２２０８（ＸＸＸＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）はインタフェース２２０６（ＩＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）をエクスポートし、エンジン・クラス２２１０（ＸＸＸＣｉｐｈｅｒＳｐｉ）はインタフェース２２１２（ＩＣｉｐｈｅｒＳｐｉ）をエクスポートする。
【０１１１】
プロバイダ抽象クラス２１２２とＸＸＸＰｒｏｖｉｄｅｒ具象クラス２２００（図２２）で形成されるプロバイダ／ＸＸＸプロバイダ（Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ）「複合クラス」についても同じことが言える。更に詳しく説明すると、Ｐｒｏｖｉｄｅｒクラス２１２２はＩＰｒｏｖｉｄｅｒインタフェース２１２０をサポートし、ＸＸＸＸＰｒｏｖｉｄｅｒクラス２２００はＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（図２２には図示していない）をサポートする。しかし、Ｐｒｏｖｉｄｅｒクラス２１２２はＸＸＸＰｒｏｖｉｄｅｒ クラス２２００の内部でのみ統合可能で、したがって独立してインスタンシエーションできない。つまり、ＩＰｒｏｖｉｄｅｒ２１２０インタフェースとＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースの両方がＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００によって「エクスポート」されることになる。
【０１１２】
Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラスと図２１に図示したエンジン・クラスの全部は図２２に図示してある他の一つのクラスと組み合わされる（ただしこれは多数のＳＳＰを構成することができそれぞれが多数のアルゴリズムをサポートできることから多面的な関係である）。ＳＳＭ ＤＬＬ（図２１）のパートナーは抽象パートナーと呼ばれ、ＳＳＰ ＤＬＬ（図２２）のパートナーは具象パートナーと呼ばれる。図２１と図２２の左側には、「マスター」クラスと呼ばれる２種類のＣＯＭクラスがあり、これはＳｅｃｕｒｉｔｙクラス２１０２とＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００である。Ｓｅｃｕｒｉｔｙクラス２１０２が「マスター」クラスであるという意味は、各種「スレーブ」Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスを制御できるということである。逆に、各種Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスが「マスター」であるということの意味は、これらが各種のスレーブ低レベル／具象エンジン・クラスを制御すると言うことである。マスター・クラスはほとんどセキュリティ・サブシステムの内部的なもので大半のアプリケーションからは見えない。
【０１１３】
図２１と図２２の右側にはエンジン・クラスと呼ばれる２種類のＣＯＭクラスがあり、これらは図２１に図示した抽象エンジン・クラスと図２２に図示した具象エンジン・クラスである。抽象エンジン・クラスはｍ＿Ｅｎｇｉｎｅフィールドの値に０を持っていれば純粋に抽象的であると言われる。３種類のエンジン・クラス（ＭｅｓｓａｇｅＤｉｇｅｓｔ、ＫｅｙＧｅｎｅｒａｔｏｒ、Ｃｉｐｈｅｒ）が説明のために図示してあるが、これらの個数は原理的に制限されない。これらのエンジン・クラスは図２１と図２２に図示してあるように対で発生し、低レベルのクラスが高レベルのクラスの内部に内包または封入される（ｍ＿Ｅｎｇｉｎｅメンバーを経由する）。高レベル・エンジン・クラスの機能はセキュリティ・サービスの消費者が起動するアプリケーション・プログラミング・インタフェース（ＡＰＩ）をエクスポートすることである。低レベル・エンジン・クラス名に見られる接尾辞「Ｓｐｉ」はサービス・プロバイダ・インタフェース（またはセキュリティに関して言えばセキュリティ・プロバイダ・インタフェース、また時に他の状況下ではシステム・プログラミング・インタフェース）を意味するもので、これの唯一の消費者は高レベル・エンジン・クラスである。これらの低レベル・エンジン・クラス内に実際のアルゴリズム特有の実装コードが存在する−−これが「ＳＳＰ ＤＬＬ」の実際に「提供する」最終的な機能である。エンジン・クラスを２つの部分に分割したことが、これらのサポートするサービスの命名構造に反映されており、完全認証サービス名は抽象／概念の接頭辞と具象／アルゴリズムの接尾辞、例えばＭｅｓｓａｇｅＤｉｇｅｓｔ．ＭＤ５というように構造化される。
【０１１４】
各具象ＳＳＰ（ＸＸＸＰｒｏｖｉｄｅｒクラス２２００）は静的な情報を含み、これにはその名前（ｓ＿ＭｙＮａｍｅ、文字列）、バージョン（ｓ＿ＭｙＶｅｒｓｉｏｎ、数字）、クラスＩＤ（ｓ＿ＭｙＣｌｓｉｄ、１６バイト二進数）、情報（ｓ＿ＭｙＩｎｆｏ、文字列）、ＤＬＬにバンドルされているサービスのリスト（ｓ＿ＭｙＳｖｃＭａｐ［］、文字列のペアのリスト）を含む。ｓ＿ＭｙＳｖｃＭａｐ［］の各エントリでは、一方の文字列がそのサービスで実装するアルゴリズムの名称、他方がそのアルゴリズムを実装する具象エンジン・クラス（ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌにバンドルされる）のＣＯＭ ＣＬＳＩＤ（クラスＩＤ）である。
【０１１５】
エンジン・クラスに加えて、セキュリティ・サブシステムは多数の非エンジン・クラスを含む。代表的な２つのクラス、ＫｅｙとＫｅｙＰａｉｒが図２１に示してある。図面が示すように、このような非エンジン・クラスは相対的に通常のＣＯＭ クラスで、唯一普通とは違う特徴は（抽象）インタフェース・クラスであり（具象）実装クラスはＳＳＭ ＤＬＬ（図２１）とＳＳＰ ＤＬＬ（図２２）の間で分割される（されない）ことである。例えば、Ｋｅｙクラス２１１０の場合だと、ＳＳＭは一般に任意のＳＳＰの鍵がどのようなものであるべきかについての優先的な（インタフェース）知識を持っているが、ＳＳＰそれ自体はＳＳＭによって例えばＸＸＸＫｅｙクラス２２１０によって定義されるインタフェースに準拠したＫｅｙクラスの詳細な実装を供給する必要がある。しかしＫｅｙＰａｉｒクラス２１１４の場合、ＳＳＭはすでに実装についての詳細な知識を持っている−−これはＫｅｙ（それがどのようなものであっても）のペアで構成される。
【０１１６】
セキュリティ・サブシステムをブートする場合、例えば、Ｓｅｃｕｒｉｔｙクラス２１０２がランタイム時に最初にＣｏＣｒｅａｔｅされ、Ｓｅｃｕｒｉｔｙクラス２１０２はＳｅｃｕｒｉｔｙクラスのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）メソッドで次のようなことを行なう。第１に、Ｓｅｃｕｒｉｔｙクラス２１０２は例えばレジストリ（Ｒｅｇｉｓｔｒｙ）に保存されている構成情報を読み込む。
【０１１７】
次に、それぞれの構成された具象プロバイダＸＸＸＰｒｏｖｉｄｅｒ（レジストリから読み出したばかりの）のＰｒｏｇＩＤ（またはＣＬＳＩＤ）に基づいて、セキュリティ・クラスがＸＸＸＰｒｏｖｉｄｅｒ２２００のインスタンスをＣｏＣｒｅａｔｅし、ＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（Ｃｔｏｒはコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）の意味）へのポインタを得る。ＸＸＸＰｒｏｖｉｄｅｒクラスをＣｏＣｒｅａｔｅするこの動作は更にＸＸＸＰｒｉｖｉｄｅｒのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）にＸＸＸＰｒｏｖｉｄｅｒ２２００内部の抽象ＰｒｏｖｉｄｅｒクラスのオブジェクトをＣｏＣｒｅａｔｅして統合する。
【０１１８】
次に、いまＣｏＣｒｅａｔｅしたばかりのＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースを使って、Ｓｅｃｕｒｉｔｙクラス２１０２がＸＸＸＰｒｏｖｉｄｅｒのｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドをＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースから呼び出す。この特別なｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの名称／バージョン／情報／ｃｌｓｉｄ／サービス・データを、「ハードワイヤードな」静的数値変数の位置から統合Ｐｒｏｖｉｄｅｒオブジェクト内の非静的メンバー変数へ「アップロード」する（ｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの統合Ｐｒｏｖｉｄｅｒサブオブジェクトによってエクスポートされるなんらかのメソッドを呼び出すことでこれを完了する）。
【０１１９】
第４に、Ｓｅｃｕｒｉｔｙクラス２１０２は各種の構成された具象プロバイダを指すＩＰｒｏｖｉｄｅｒ＊の静的内部構成リストｓ＿ＰｒｏｖＬｉｓｔ［］を構築する。Ｓｅｃｕｒｉｔｙクラス２１０２は、Ｓｅｃｕｒｉｔｙクラス２１０２がこの時点まで使っていたＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒ＊インタフェースでＱｕｅｒｙＩｎｔｅｒｆａｃｅを呼び出すことで各ＩＰｒｏｖｉｄｅｒ＊を構築する。構成されたＳＳＰのリストｓ＿ＰｒｏｖＬｉｓｔ［］はＳｅｃｕｒｉｔｙクラス２１０２のｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを介してクライアントが利用できるようになる。
【０１２０】
アプリケーションは次のような方法でプロバイダ・アーキテクチャを実際に使用する。あるアプリケーションがＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクト上でｄｉｇｅｓｔ（）メソッドを呼び出して特定メッセージ（バッファ）のダイジェストを実際に計算したいと想定する。アプリケーションはＳＳＭで抽象エンジン・クラスを知っている（すなわちＳｅｃｕｒｉｔｙＳｖｃｓ．ｄｌｌのクラスのＣＬＳＩＤ）。これは作成中にこの情報へリンクされたためだが、現実のアルゴリズム実装が実際に存在するＳＳＰ内の具象エンジン・クラスについては優先順位（すなわち、ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌのクラスのＣＬＳＩＤ）を知らない。したがって、アプリケーションは抽象エンジン・オブジェクトを直接ＣｏＣｒｅａｔｅできるが、具象エンジン・オブジェクトは直接ＣｏＣｒｅａｔｅ できない。しかし、好適実施態様では、抽象エンジン・オブジェクトがｇｅｔＩｎｓｔａｎｃｅ（）と呼ばれるファクトリ・メソッドを有するクラス・ファクトリ・オブジェクトとして処理され、次のように、間接的に具象エンジン・オブジェクトを作成している。
【０１２１】
アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔクラス２１０６から純粋な抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅすることから開始する。このようなオブジェクトは具象エンジン・オブジェクトへ接続されないのでダイジェストを作成するためには使えない、すなわち主状態変数ｍ＿Ｅｎｇｉｎｅは値に０を持っている（副状態変数ｍ＿ＡｌｇＮａｍｅとｍ＿ＰｒｏｖＮａｍｅも同様）。いまＣｏＣｒｅａｔｅしたＩＭｅｓｓａｇｅＤｉｇｅｓｔ＊インタフェース２１０４を使って、アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔのｇｅｔＩｎｓｔａｎｃｅ（）メソッドを呼び出し、使いたいメッセージ・ダイジェスト・アルゴリズムの周知の名前を指定する。ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはファクトリ・メソッドで、次のステップを実行する。第１に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドがＳｅｃｕｒｉｔｙオブジェクトでｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを呼び出して現在構成されているプロバイダのリストをフェッチする。次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはいまフェッチしたばかりのＳＳＰのリストを使って、要求されたアルゴリズムをサポートする最初のＳＳＰが見つかるまで、好適な順番で各ＳＳＰのｇｅｔ（）メソッドを呼び出す。ＳＳＰのｇｅｔ（）メソッドはＳＳＰのｍ＿ＳｖｃＭａｐ［］を使用し、アルゴリズム名を具象エンジン・クラスＰｒｏｇＩＤにマッピングする。つまりこの例では、クラス２０２２のｇｅｔ（）メソッドが要求されたアルゴリズムをサポートしているＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ具象エンジン・クラスのＰｒｏｇＩＤを返す。
【０１２２】
次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはｇｅｔＩｎｓｔａｎｃｅ（）メソッドが呼び出されたＭｅｓｓａｇｅＤｉｇｅｓｔとは別に新しく抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅする。まず、この新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトはもう一つの純粋な抽象エンジン・オブジェクトだが、次のステップでｇｅｔＩｎｓｔａｎｃｅ（）メソッドは完全な／接続されたエンジン・オブジェクトへ（すなわちｍ＿Ｅｎｇｉｎｅフィールドを介してこれの内部に含まれる／作成される具象エンジンとあわせて「非純粋」抽象エンジン・オブジェクトに）変化させる。
【０１２３】
最後に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドを呼び出し、パラメータとして上記で呼び出したｇｅｔ（）オブジェクトから取得したＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ ＣＬＳＩＤ（またはＰｒｏｇＩＤ）を渡す。そのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドはクラス２１０４からＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉオブジェクトのインスタンスをＣｏＣｒｅａｔｅし、新しいＭｅｓｓａｇｅＤｉｇｅｓｔのｍ＿Ｅｎｇｉｎｅフィールドへ得られたＩＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ＊ポインタを格納する。
【０１２４】
つまり、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはアプリケーションへ完全に完成／接続したＭｅｓｓａｇｅＤｉｇｅｓｔエンジン・オブジェクトを返す。この時点で、アプリケーションはエンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドを呼び出してメッセージのダイジェストを計算する。（抽象）エンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドは具象エンジン・オブジェクトのｅｎｇｉｎｅＤｉｇｅｓｔ（）メソッドへの呼び出しを代理または転送して実際の作業を行なわせる。
【０１２５】
上記で説明した実施態様のソフトウェアによる実装は、有形の媒体例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤＲＯＭ、ＲＯＭメモリ、または固定ディスクなどに固定されるか、モデムまたは媒体上のその他のインタフェース装置を介してコンピュータ・システムへ転送可能な一連のコンピュータ命令を含む。媒体は光またはアナログ通信線を含みこれに限定されない有形の媒体としたり、マイクロ波、赤外線またはその他の電送技術を含みこれに限定されない無線技術で実装することができる。媒体はインターネットの場合もある。一連のコンピュータ命令は本発明に関して本明細書ですでに説明した機能の全部または一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用される多数のプログラミング言語で書けることが当業者には理解されよう。更に、このような命令は、現在または将来の、半導体、磁気、光、またはその他のメモリ装置を含みこれに限定されないなんらかのメモリ技術を用いて保存したり、あるいは現在または将来の、光、赤外線、マイクロは、またはその他の伝送技術を含みこれに限定されないなんらかの通信技術を用いて伝送される。このようなコンピュータ・プログラムは印刷物または電子文書を伴なう取り出し自由な媒体として、例えばシュリンクラップ包装ソフトウェアとして配布されたり、コンピュータ・システムに例えばシステムＲＯＭや固定ディスク上にプリロードされていたり、またはサーバまたは電子掲示板から例えばインターネットまたはワールド・ワイド・ウェブなどのネットワーク上で配布されることがあると想定される。
【０１２６】
本発明の代表的実施態様を開示したが、本発明の利点のいくつかを実現し本発明の主旨と範囲から逸脱しない各種の変化及び変更を加えることができることは当業者に明らかであろう。例えば、説明は特定のハードウェア・システム及びオペレーティング・システムを指向したものだったが、他のハードウェアやオペレーティング・システム・ソフトウェアを説明したそれと同じ方法で使用できることは当業者には明らかであろう。例えば特定の関数を実現するために使用された特定の命令などのその他の態様ならびに本発明の概念に対するその他の変更も付録の請求の範囲によって包含されることを意図している。
【図面の簡単な説明】
【図１】 図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図である。
【図２】 図２、はデルタを用いてローカルなデータ・コピーを更新する代表的なコラボレーション・システムの略ブロック図である。
【図３】 図３は、グループ、トライブ、またそれらを保護するために使用される暗号化及び認証鍵を示す略ブロック図である。
【図４】 図４は、低レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図５】 図５は、認証／完全性モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図６】 図６は、認証／完全性／機密モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図７】 図７は、認証／完全性モードで動作する高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図８】 図８は、デジタル署名と証明書の作成及び確認を示す略ブロック図である。
【図９】 図９は、既存のグループへの新規メンバー（招待者）の追加を示す略ブロック図である。
【図１０】 図１０は、既存のグループへ新規メンバーを追加するために議長（ｃｈａｉｒ）を使用するような代表的ルーチンのステップを示すフローチャートである。
【図１１】 図１１は、議長から招待者へ送信される招待メッセージの内容を示す略図である。
【図１２】 図１２は、招待者から議長へ送信される受け入れメッセージの内容を示す略図である。
【図１３】 図１３は、グループの既存のメンバー全員へ議長から送信されて新規メンバーが追加されたことを告知する新規メンバー追加デルタの内容を示す略図である。
【図１４】 図１４は、議長から新規に追加されたメンバーへ送信されてテレスペース・データのメンバーを告知するメッセージの内容を示す略図である。
【図１５】 図１５は、招待者が招待に応答するために使用できる代表的ルーチンのステップを示すフローチャートである。
【図１６】 図１６は、招待者からの受け入れメッセージに応答するために議長が使用できる代表的ルーチンのステップを示すフローチャートである。
【図１７】 図１７は、新規メンバー追加デルタに応答するために既存のメンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１８】 図１８は、テレスペース情報を搬送する議長からのメッセージに応答するために新規追加メンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１９】 図１９は、再キーイング情報が「ピギーバック」したデルタ・メッセージの内容を示す略図である。
【図２０】 図２０は、本発明のセキュリティ・システムの好適な実装の全体的アーキテクチャを示す略ブロック図である。
【図２１】 図２１は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル抽象クラスを示す略ブロック図である。
【図２２】 図２２は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル具象クラスを示す略ブロック図である。
【図２３】 図２３は、視覚的確認のための情報を表示しその情報を受け入れるかまたは破棄するようにユーザに要求するダイアログ・ボックスの画面表示を示す略図である。
発明の分野
本発明は安全なデータ交換トランザクションを提供するための方法及び装置に関連し、更に詳しくは、共同作業環境（以下、コラボレーティブ環境）における安全なデータ交換トランザクションを提供する方法及び装置に関する。
【０００２】
発明の背景
現在の計算機アプリケーションはほとんどがシングル・ユーザ・システムである。例えば、従来の編集アプリケーションでは、一人のユーザがファイルを開き内容に変更を加えることができる。第１のユーザがファイルを開いている間に、第２のユーザがそのファイルを開こうとすると、第２のユーザはファイルを開くことができないか変更を加えることができないことになる。第２のユーザはファイルの一時的なコピー（以下、スナップショット・コピー）を取得することができる場合がある。しかしスナップショット・コピーは第１のユーザが作成したオリジナルのコピーに加えたそれ以降の変更は何も更新されない。つまり、第２のユーザはファイルの変更として表現された第１のユーザのアイデアを共有することができない。更に、第２のユーザはオリジナルのファイル内容の変更を行なうことができないので、ファイルの変更として表現されるそのユーザのアイデアを共有することができない。要するに、第１と第２のユーザはファイルの共同作業による（以下、コラボレーティブな）編集ができない。
【０００３】
本明細書で用いている術語であるコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）は複数クライアントがアイデアを共有できるようにする能力を意味する。この共有には一人のアイデアを他のメンバーに対して自動的に表明し、他のメンバーがそのアイデアを明示的に要求しなくても良いようにする能力を含む。コラボレーションは更にアイデアを送信するメンバーからのアイデアを自動的にそれぞれのメンバーが受信できるようにする能力も含む。つまり、最低限、コラボレーションは共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｅｆｆｏｒｔ）に参加しているメンバーの間での通信を意味する。この通信／コラボレーションは多くのモデルをもとにすることができる。「ブレーン・ストーミング型」セッションは制約されないコラボレーション・モデルである。一方、「ラウンド・ロビン」型モデルはそれぞれのメンバーがアイデアを表明するのに特定の順番を待つもので、制約型のコラボレーション・モデルである。
【０００４】
米国特許５，７８１，７３２号に開示された一つのコラボレーション・システムでは、データ変更要求がユーザとの対話に対する応答として生成されすべてのコラボレータに接続されているトランスポンダ・ユニットへ送出される。トランスポンダはコラボレーションに参加しているユーザ全部に対してデータ変更要求をブロードキャストする。各ユーザはコラボレーション用データ（以下、コラボレーティブ・データ）のローカルなコピーを持ち、データ変更要求を受信してローカルなデータ・コピーへ要求された変更を加えるメカニズムを備える。すべてのデータ変更要求がトランスポンダを経由しなければならないため、データ変更要求はすべて同じ順番でそれぞれのコラボレータに受信されることになり、データの完全性が維持される。
【０００５】
コラボレーションは１台の計算機またはサーバで作業しているユーザ間でローカルに行なわれたり、ユーザそれぞれがネットワークに接続された計算機に向かっているようなネットワーク上で行なわれることもある。インターネットはこのようなネットワークの一つで、数百万のユーザ間での通信及び対話のためのダイナミックな公衆環境を作り出した。ビジネスにおいて、インターネットまた特にインターネット上で動作するワールドワイドウェブ・アプリケーションはベンダ／メーカ間、メーカ／ディストリビュータ間、ディストリビュータ／顧客間、その他の関係を再編成した。インターネット技術を企業内の機密ネットワークへ拡張すると、「イントラネット」あるいは「プライベート・インターネット」と呼ばれるようなものが、企業のディレクトリとネットワーク基盤を使用する従業員それぞれや作業グループの間で、新しい形態のドキュメント及び情報の共有を可能にした。
【０００６】
ワールド・ワイド・ウェブ（「ウェブ」）はその中核にサーバ・クライアント・アーキテクチャを有し個々のクライアント（すなわちウェブ・コンテンツのユーザ）はブラウザを通して、公衆ネットワーク上にあるサーバ（すなわち、インターネット・コンテンツ・プロバイダ）とインタフェースすることで、ウェブ・サイトからドキュメントを取得する。ブラウザはパーソナル・コンピュータがインターネット・ドキュメントを要求し、受信し（例えばダウンロードし）、解釈し、表示し、また一般的にはインターネットをナビゲーションできるようにするソフトウェア・プログラムである。ウェブ・サイトはドキュメントの集合体で、ドキュメントは一般にホームページやこれに関連しリンクされるドキュメントから構成され、クライアントからは離れたサーバ上に配置される。ドキュメントはコンパウンド・ドキュメントとすることができ、データ、グラフィックス、ビデオ、サウンド、及び／または他の種類のメディアや、他のドキュメントへのリンクも含められる。
【０００７】
基盤となるウェブ及びその他のインターネット技術は、パーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロトコル、インフラストラクチャの取り決め（例えば一元的資源指定子Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ ＬｏｃａｔｏｒまたはＵＲＬ）を含め、標準化が進んでいる。ＵＲＬはＷＷＷ上のすべてのドキュメント・オブジェクトについて所在アドレスを提供する。ＵＲＬはドキュメント・オブジェクトを択一的に指定しインターネット・プロトコルを使用するアクセス・アルゴリズムも定義することが多い。
【０００８】
インターネットを利用するため、インターネット・プロトコルに準拠した形でツールや資源が開発されており、これには電子メール（ｅ−ｍａｉｌ）などのアプリケーションを含む。電子メールは電子的な郵便で、これを用いてドキュメントを電子的に、選択したアドレスで送受信する。インターネット上での対話（ｉｎｔｅｒａｃｔｉｏｎ）のほとんどが「ドキュメント送受信」モデルに従う電子メールやその他のブラウザを使うメディアであると予想された。おそらくはそのモデルのため、ユーザは高次の権威者による介入なしに個人が他の個人の提供した文書にアクセスすることでインターネットを本質的に「ピアツーピア」であると見なすことが多い。
【０００９】
結果として、更に「ピアツーピア」的に動作する新しいコラボレーション・モデルが開発された。これらのモデルは「テレスペース」と呼ばれる共有プライベート空間にいるユーザ間の直接接続の上に構築される。各ユーザは「アクティビティ」と呼ばれるプログラムを持ち、これはパーソナル・コンピュータ・システムや、通信機器またはその他のネットワーク接続可能な装置で動作可能である。アクティビティ・プログラムは「デルタ」と呼ばれるデータ交換要求を生成することでユーザとの対話に応答する。アクティビティはまたデータ変更エンジンを備え、これがローカルなデータ・コピーを維持しており、デルタによって要求されたデータへの変更を実行する。デルタはダイナミクス・マネージャによって一人のユーザから別のユーザへと配布される。後者の形式のコラボレーション・システムは「通信マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ， Ｋｅｎｎｅｔｈ Ｇ． Ｍｏｏｒｅ， Ｒｏｂｅｒｔ Ｈ． Ｍｙｈｉｌｌ ａｎｄ Ｂｒｉａｎ Ｍ． Ｌａｍｂｅｒｔによる１９９９年７月１９日付け米国特許出願第０９／３５７，００７号、「ダイナミクス・マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｗｉｔｈ ａ ｄｙｎａｍｉｃｓ ｍａｎａｇｅｒ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ． Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け米国特許出願第０９／３５６，９３０号、「アクティビティ・ベースのコラボレーション用に装備した分散コンピュータ・システムにおいてデータ変更要求に優先順位をつけデータ完全性を維持するための方法及び装置（ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｐｒｉｏｒｉｔｉｚｉｎｇ ｄａｔａ ｃｈａｎｇｅ ｒｅｑｕｅｓｔｓ ａｎｄ ｍａｉｎｔａｉｎｉｎｇ ｄａｔｅ ｃｏｎｓｉｓｔｅｎｃｙ ｉｎ ａ ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｑｕｉｐｐｅｄ ｆｏｒ ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｃｏｌｌａｂｏｒａｔｉｏｎ）」と題するＲａｙｍｏｎｄ Ｅ． Ｏｚｚｉｅ ａｎｄ Ｊａｃｋ Ｅ． Ｏｚｚｉｅによる１９９９年７月１９日付け米国特許出願第０９／３５６，１４８号に詳細に記載されている。
【００１０】
インターネットは、ユーザに娯楽と有用な通信方法を提供する点でダイナミックかつフレキシブルだが、ユーザのニーズ全部には適合しない。例えば、インターネットは各種のハードウェアとソフトウェアで広範囲のユーザを接続する能力を有することから理想的にはコラボレーションに適したものであろう。しかし、インターネットのセキュリティは希望するのとは程遠い。インターネット上で様々な人数のユーザへメッセージを送信できるが、これらのメッセージは代表的にはサード・パーティのウェブ・サイトを経由しここで通信を傍受したり機密性を侵害することが可能である。結果として、ユーザがインターネット経由でいっそう対話する一方、例えば複数媒体（電話、ファクシミリ、ホワイトボード）や、複数時刻（リアルタイム、翌日配達郵便（ｏｖｅｒｎｉｇｈｔ ｍａｉｌ））及びその他の通信告知手段など従来の安全な方法でインターネット「以外で」対話を続けることになる。
【００１１】
共有プライベート空間にいる個人間及び中小グループ間でコラボレーティブな通信やその他の共有及び同時的アクティビティを安全なものにするようにインターネットを拡張するのが望ましい。このような対話は参加者のパーソナル・コンピュータ間またはその他のネットワーク接続可能な装置間で望ましくは瞬間的、直接的、かつ機密に行なわれるべきである。また様々なリモートサイトにいるユーザが安全に通信でき、安全な通信リンクの構築やセキュリティ・システムの維持にユーザの広範囲の関与を必要としないような技術を提供するのも望ましい。また安全なトランザクションを提供する上で関係する「オーバヘッド」を最小限にまで減らして通信量（以下、スループット）と動作速度を改善するのも望ましい。
【００１２】
発明の要約
本発明の図示した実施態様の一つによれば、異なるセキュリティ・レベルを提供してユーザが彼ら自身の通信のセキュリティ・レベルを決定できるようにする。ユーザは低いセキュリティ・レベルを選択してセキュリティ関係のオーバヘッドを可能な限り小さくすることが可能である。これ以外に、セキュリティ関係のオーバヘッドの増加をもたらすもっと高いセキュリティ・レベルを選択することも可能である。異なるセキュリティ・レベルは２種類の鍵のうちの一つまたはそれ以上の使用により作成される：暗号化鍵は平文テキストデータをデルタへ暗号化するために使用し、メッセージ認証鍵を使ってデータを認証しデータの完全性を保証する。２種類の鍵を使ってテレスペースの各メンバーでデータを再暗号化しなくて済むようにする。
【００１３】
好適実施態様において、鍵管理のオーバヘッドを減少させるため、同一の物理鍵を暗号化鍵とメッセージ認証鍵に使用する。
【００１４】
一つの実施態様において、セキュリティ・レベルはテレスペースが作成されてテレスペースの寿命がある間は固定されたままである。テレスペースでは、セキュリティ・レベルは全くセキュリティがない状態からテレスペースのメンバーと部外者との間のセキュリティ、更にテレスペースのメンバーのペア間でのセキュリティまで範囲がある。
【００１５】
別の実施態様において、「トライブ（ｔｒｉｂｅ）」と呼ばれるサブグループをテレスペース内に形成しそれぞれのトライブが自分のいるテレスペースのセキュリティ・レベルを採用する。
【００１６】
更に別の実施態様において、中程度または高度なセキュリティ・レベルを有するテレスペースのメンバーはウィスパー（ｗｈｉｓｐｅｒｓ）と呼ばれテレスペースの他のメンバーに対しても機密化される機密通信で通信することができる。
【００１７】
好適実施態様の詳細な説明
図１は代表的なコンピュータ・システム１００の従来のシステム・アーキテクチャを示したもので、これに開示された本発明を実装することができる。ただし図１の代表的なコンピュータ・システムは説明目的のみで議論するもので本発明の制限と見なすべきではない。以下の説明では特定のコンピュータ・システムを記述する際に共通に使用される術語を参照することがあるが、記載される概念は図１に図示したものとは異なるアーキテクチャを有するシステムを含めた他のコンピュータ・システムに等しく適用される。
【００１８】
コンピュータ・システム１００は従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報記憶のためのランダムアクセス・メモリ（ＲＡＭ）１１０、及び永久的情報記憶のためのリードオンリー・メモリ（ＲＯＭ）を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５はバス１３０を制御するために設けてあり、割り込みコントローラ１３５は他のシステム要素からの各種割り込み信号を受信し処理するために使用される。
【００１９】
大容量記憶はディスケット１４２、ＣＤＲＯＭ１４７、またはハードディスク１５２によって提供される。データとソフトウェアは取り出し可能な媒体例えばディスケット１４２やＣＤＲＯＭ１４７を介してクライアント・コンピュータ１００と交換できる。ディスケット１４２はディスケット・ドライブ１４１へ挿入でき、このディスケット・ドライブ１４１はコントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤＲＯＭ１４７はＣＤＲＯＭドライブ１４６へ挿入でき、ＣＤＲＯＭドライブ１４６はコントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は固定ディスク・ドライブ１５１の一部であり、これはコントローラ１５０を介してバス１３０へ接続されている。
【００２０】
コンピュータ・システム１００へのユーザ入力は様々な装置から提供される。例えば、キーボード１５６とマウス１５７はキーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６はマイクロホンとスピーカの両方として機能するもので、オーディオ・コントローラ１９７によってバス１３０へ接続されている。その他の入力装置例えばペン及び／またはタブレットや音声入力用マイクロホンなどがバス１３０と適当なコントローラを介してクライアント・コンピュータ１００へ接続できることは当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリ・アクセスを実行するために提供される。視覚表示はビデオ・ディスプレイ１７０を制御するビデオ・コントローラ１６５によって生成される。
【００２１】
コンピュータ・システム１００はクライアント・コンピュータ１００をバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用する。
【００２２】
コンピュータ・システム１００は一般にオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。
【００２３】
図２は略ブロック図の形で代表的なコラボレーション・システムの構成を示す。図２はネットワーク２１６へ接続された２台のコラボレーティブ・ワークステーション２００、２０２を示す。ワークステーション２００、２０２のそれぞれは図１に示したようなコンピュータ・システムとすることができ、ネットワーク２１６はプライベート・コンピュータ・ネットワーク例えばＬＡＮやＷＡＮ、あるいは公衆コンピュータ・ネットワーク例えばインターネットとすることができる。これ以外に、ワークステーション２００、２０２は同一のコンピュータ（図示していない）上に構成することができ、この場合２つの端末間の通信はそのコンピュータに対してローカルなものとなる。
【００２４】
好適実施態様において、端末２００、２０２のそれぞれは共同作業を実行するデータのローカルなコピー２０４、２１０をそれぞれ保持している。それぞれのローカルなデータ・コピー、例えばデータ・コピー２０４はこれに対応する「ダイナミクス・マネージャ」２０６と呼ばれるソフトウェア・プログラムによって管理される。同様に、データ・コピー２１０はこれに対応するダイナミクス・マネージャ２１２によって管理される。特定のコラボレーション装置を説明の目的で議論するが、他のコラボレーション装置も精神と範囲において本発明の原理から逸脱することなく使用できることが当業者には明らかであろう。
【００２５】
ダイナミクス・マネージャ２０６は「デルタ」と呼ばれる一つまたはそれ以上のデータ変更要求を含む自己内包型データユニットの受信に応答してこれのローカル・データ・コピー２０４を変更し更新する。データ変更要求はデータの希望通の変更に関してダイナミクス・マネージャやその他のコンポーネント（図示していない）への通知または催促である。デルタは例えばマネージャ２０６などのダイナミクス・マネージャによって、ユーザとの対話に応答して作成されるもので、対応するローカル・データ・コピー２０４と、ネットワーク越しに同じコラボレーティブ・セッションに参加しているコラボレータに属する他のコンピュータ上のローカル・データ・コピーとの両方を更新するために用いられる。
【００２６】
デルタは制御情報を提供するへッダ部分と要求が関係するデータについての情報を提供するペイロード部分とを含む特定のフォーマットを有する。個々のデルタは一つまたはそれ以上のペイロードを有することができる。多数のペイロードが使用されるような場合、以下で詳細に説明するように、それぞれが独自の装置機能またはユーザの役割を有する特定のコラボレーション・メンバーを対象とすることができる。
【００２７】
ダイナミクス・マネージャ２０６によって生成されたデルタが他のコラボレータに送信される場合、ダイナミクス・マネージャ２０６は通信マネージャ２０８と相互作用する。同様に、ダイナミクス・マネージャ２１２は通信マネージャ２１４と相互作用する。通信マネージャ２０８は内向きと外向きのデルタを適当な宛先へ配送するメカニズムである。好適実施態様において、通信マネージャはコンピュータで実行可能なプログラムとして実装することができ、このプログラムが別のリモート・パーソナルコンピュータまたは別の形のネットワーク接続可能な装置へネットワーク２１６上で送信するため通信マネージャ２０６によって開始されたデルタを配送し、またネットワーク２１６上で受信したリモートで生成されたデルタをダイナミクス・マネージャ２０６へ配送する。
【００２８】
一般に、通信マネージャ２０８、２１４はダイナミクス・マネージャ２０６、２１２によって生成された全デルタがコラボレーションに参加している全ユーザによって受信されるように構成される。それぞれのデルタは内部シーケンス番号を含みそれぞれのコラボレータのダイナミクス・マネージャは全部のデルタがいつ受信されたかを決定できるようにしてある。別のコラボレータからのデルタはそれぞれのコラボレータへ多数の違う経路を通って送信されることがあるので、デルタは生成された順序と同じ順序で到着するとは限らない。しかし、それぞれのコラボレータによって全デルタが受信され内部シーケンス番号を使って正しい順序でデルタを適用できる。したがって、それぞれのコラボレータによって保持されているローカル・データ・コピーは、全部のデルタで更新されると、コラボレーションの他のメンバーによって保持されているローカル・データ・コピーと一致することになる。
【００２９】
特定のコラボレーションに参加しているコラボレータの間での機密性を維持することが望ましい。これはデルタが公衆ネットワーク例えばインターネット上に送信される場合にとくに言えることである。情報のセキュリティにとって重要な３つの基本概念が存在する。その第１は認証で、これはデータ受信者がデータ作成者（ｄａｔａ ｓｏｕｒｃｅ）の同一性を知っており信用できることを保証するものである。第２は完全性で、データが転送中に変更されなかったことを保証するものである。完全性はデータ作成者以外のものによってデータを書き込むことができないことまた既知の作成者から到着したものであることを実効的に保証する。データ完全性は不正なデータの生成または「なりすまし」による第三者からの攻撃を防止する。最後のセキュリティ概念は機密性で、これは転送中のデータがデータ作成者とデータ受信者以外の第三者によって読み取ることができないことを保証するものである。機密性は第三者によるデータの読み取りまたは「盗聴」による攻撃を防止する。
【００３０】
前述したように、セキュリティはコラボレータが一つまたはそれ以上のアクティビティに参加して項目を共有したり、アクティビティの結果がユーザのパーソナル・コンピュータ上にあるいは他の形のネットワーク接続可能な装置上に永続的に保存されるような仮想空間に基づいている。仮想空間は「テレスペース」または「グループ」と呼ばれるもので各ユーザの装置の中で同期が保たれる。図示したセキュリティ／モデルによると、テレスペースのセキュリティは、テレスペースを形成して、メンバーを受け入れ、更にメンバーシップが安定したあとで「全体の」セキュリティとしてほとんどのユーザが体験するものである。これは安定状態デルタ・プロトコルと呼ばれグループ・メンバー間に渡されるデルタに含まれる情報の認証、完全性及び機密性に関連する。図３は５人のメンバーＭ０、Ｍ１、Ｍ２、Ｍ３、Ｍ４（３０２〜３１０）からなるテレスペースまたはグループ例３００の模式図である。各テレスペース３００内には一つまたはそれ以上のトライブまたはサブグループが存在する。図３には、３人のメンバーＭ２、Ｍ３、Ｍ４（３０６、３０８、３１０）からなるトライブ３１２が図示してある。
【００３１】
各メンバー３０２〜３１０はその内部に「プロトコル・エンジン」（それぞれエンジン３０３〜３１１）を有し、これは他のメンバーへセキュリティ・メッセージを送信しセキュリティ情報を操作するアプリケーション・プログラムである。
【００３２】
テレスペース３００とトライブ３１２において情報は一つまたはそれ以上の鍵により保護される。これは、Ｋとして示してある暗号化鍵と、Ｌで示したメッセージ認証／完全性コード（ＭＡＣ）鍵である。Ｋ及びＬ鍵は対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｉｐｈｅｒ）用の従来の鍵でありテレスペース全体への広がり（スコープ）を有する。本発明のシステムはブロック暗号化（ｂｌｏｃｋ ｃｉｐｈｅｒｓ）とストリーム暗号化（ｓｔｒｅａｍ ｃｉｐｈｅｒｓ）の両方を用いることができるが、メッセージ間での状態は維持されない。つまり一つのメッセージから次のメッセージへセキュリティ暗号ストリーム状態を維持するためには通信しているエンドポイントが必要とされない。この方法では、一時的な通信の中断が発生した場合にも再同期が必要とされない。
【００３３】
ブロック暗号化はカウンター・モードにおいて使用する度に必ず新しく無作為生成される初期化ベクトルを使って使用される。初期化ベクトルは暗号のブロック長と等しい長さを有し従来の方法による典型的なへッダ攻撃を妨害（ｔｈｗａｒｔ）するために使用する。ストリーム暗号化はブロック・モードにおいて初期ベクトルと鍵を組み合わせる、例えば排他的論理和演算により、ついですべてのメッセージで鍵文字列を再初期化することで使用される。この場合、初期ベクトルは鍵長と等しい長さを有する。初期ベクトルは一般に機密性保護されないしまたは認証／完全性の保護もされない。
【００３４】
更にすべての鍵がなんらかの種類の陳腐化メカニズム例えばタイムアウトを関連させるか一定数のメッセージまたはバイト数を保護すると想定する。このメカニズムはテレスペースによって決定されるローカル・ポリシーの一種で以下で説明するいずれのプロトコルでも送信する必要はない。
【００３５】
ＫＧ／ＬＧで示したグループ鍵は（それぞれ）暗号化／ＭＡＣ鍵で、グループ３００の全メンバーによって共有される。これらの鍵は第三者（グループ外の者）による攻撃からデルタに含まれる情報の機密性／完全性をそれぞれ保護するために使用される。同様に、ＫＴ／ＬＴで示したトライブ鍵は暗号化／ＭＡＣ鍵で、トライブ３１２の全メンバーによって共有される。これらの鍵はトライブ以外のグループ・メンバーや第三者による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。
【００３６】
更にＫ０１／Ｌ０１で示してある対になった鍵はメンバーＭ１とＭ２が共有しかつ他のグループ・メンバーの誰も共有していない暗号化／ＭＡＣ鍵（それぞれ）Ｍ０とＭ１で、Ｍ０とＭ１の間で双方向に通信を保護するために使用される双方向鍵である。これらの鍵はグループ・メンバーＭ２、Ｍ３、Ｍ４による攻撃からデルタの機密性／完全性を（それぞれ）保護するために使用される。同様に対になった鍵Ｋｉｊ／Ｌｉｊは別のメンバーの組み合わせＭｉとＭｊの間で交換される情報を他のグループ・メンバーによる攻撃から保護するために使用される。
【００３７】
テレスペース内で安定状態セキュリティは５段階のレベルの一つに組み込まれることになるが、そのレベルはテレスペース３００の作成者がテレスペースを作成する時点で選択できる。５レベルには何らの鍵も使用する必要がない低レベル・セキュリティを含む。このレベルは全く暗号セキュリティを提供しない。次のレベルは１対の鍵（ＫＧ／ＬＧ）をグループの全メンバーに対して使用する中程度レベルのセキュリティである。このレベルでは、ＫＧ／ＬＧ鍵のうちのＭＡＣ鍵ＬＧだけを使ってデルタを保護することにより認証／完全性が提供できる。同様に、認証／完全性及び機密性はＫＧ／ＬＧ鍵の両方を使ってデルタを保護することで提供できる。
【００３８】
次のレベルは高レベルのセキュリティで、グループ鍵ＫＧ／ＬＧと鍵ペアＫｉｊ／Ｌｉｊの組み合わせを使用する。認証／完全性だけが要求される場合にはＭＡＣ鍵のペア（Ｌｉｊ）だけを使用してデルタを保護し、グループ鍵（ＫＧ）は使用しない。これ以外に、認証／完全性／機密性が要求される場合にはグループ暗号化鍵ＫＧとＭＡＣ鍵ペアＬｉｊを使用してデルタを保護する。
【００３９】
中レベルと高レベルのセキュリティ・レベル双方で、暗号化鍵（Ｋｉｊ）とＭＡＣ鍵（Ｌｉｊ）のペアを使用してグループ鍵またはトライブ鍵（ＫＧ／ＬＧまたはＫＴ／ＬＴ）の再キーイングを行なう。
【００４０】
以上のレベルやモードはグループ（テレスペース）全体に適用可能であり、また全トライブ（サブグループ）にも同様に適用可能である。テレスペース内のトライブ全部がテレスペース自体と同一の「全体的セキュリティ」を有するので、グループに対して前述したレベルやモードは、前記のグループ鍵ＫＧ／ＬＧをトライブ鍵ＫＴ／ＬＴで置き換えればトライブに適用できる。
【００４１】
図４はグループ・メンバー間に情報を転送するのに使用する「デルタ」の内容を示す。各デルタはメッセージ・へッダ４００からなり、これにはセキュリティ・システムの特定の実装に依存する情報を含む。この情報にはプロトコルのバージョン番号を含められるので、ここにコラボレーション・システムとセキュリティ・サブシステム両方のバージョン番号を含められる。メッセージ・へッダ４００はメッセージ・フラグ種別またはタグＩＤも含み、これはメッセージの種類が異なるごとに異なる識別子である。メッセージ・へッダに含めることができる他の情報としては、構造化シーケンス番号がある。この番号はテレスペースのスコープを有する部分順列シーケンス番号で、そのスコープ内でメッセージの送信者とメッセージそれ自体の特定インスタンスとを論理的に同定する。
【００４２】
へッダ４００は機密を保護することができないが要求されるセキュリティ・レベルによっては実際にグループ・メンバー間に送出されるペイロードまたは情報を含むアプリケーション・データ４０２と全く同様に認証／完全性を保護する必要がある場合がある。例えば図４に図示してあるようなデルタが符号化される方法は希望するセキュリティ・レベルによって変化する。例えば、暗号としての意味でセキュリティを何も保証しない「低レベル」セキュリティ・モードでは、デルタは図４に図示したように送信され、へッダ情報４００がペイロード４０２よりも先に送信されるのが望ましいが、へッダとペイロードの順序は本発明の動作にとって重要ではない。この場合、第三者（非グループ・メンバー）がデルタ情報４０２を読み取るまたは盗聴でき、またデルタを書き込んだり真似たり、または「なりすます」ことができる。
【００４３】
前述の認証／完全性モードで動作する「中レベル」セキュリティ・システムの場合、デルタ情報は図５に図示したように保護される。更に詳しく説明すると、それぞれのデルタについて、へッダ情報５００が送信され、それに続けて鍵バージョン番号５０２、平文データ５０４、更に認証子５０６が送信される。ここでもこれらの要素の順序は重要ではない。認証子はデータ５０４の認証／完全性を保護しグループ・メンバーによって送信されたメッセージであることを保証するＭＡＣコード５０６とすることができるが、これはグループ認証鍵ＬＧを知っているのはグループのメンバーだけだからである。別の実施態様において、メッセージ認証子として公開鍵署名認証子を使用することもできる。この場合、メッセージ認証子５０６はハッシュして連結したへッダ及びデータの公開鍵署名で構成する。
【００４４】
好適実施態様において、鍵バージョン番号は２つの部分を有しており、これは「鍵識別子ＫｅｙＩｄｅｎｔｉｆｉｅｒ」と呼ばれるテレスペース全体で使われる独自の文字列と、「鍵バージョンＫｅｙＶｅｒｓｉｏｎ」と呼ばれるインクリメンタルなシーケンス番号である。鍵識別子はテレスペースの別のメンバーが独自に生成する鍵同士を識別するために必要とされる。一方のメンバーが、他方のメンバーも新しい鍵を生成していることについて知らないので、鍵識別子は鍵を個別に識別できるようにする。鍵バージョンは古い鍵、現在の鍵、新しい鍵を識別するために必要とされる。安定状態では、メンバーは鍵識別子の値は異なるが鍵バージョンの値が同じ一組の鍵を使用することになる。メンバーは現在の鍵バージョンの値よりも鍵バージョンの値が小さい「古い鍵」を削除することができる。
【００４５】
好適な実装において、ＭＡＣコード５０６は、最初にデータ５０４と連結したへッダ５００をハッシュし、次にハッシュの結果を従来のメッセージ認証アルゴリズムに沿って保護する。中間ハッシュ関数を使用して後述するような高セキュリティ・バージョンに沿った方法でＭＡＣコードを作成する。また従来のＭＡＣアルゴリズムを使用してグループ認証キーＬＧで単純にへッダとデータを保護すれば、中間ハッシュ関数を使用せずにこのモードを実装することも可能である。前述のように、認証／完全性モードにおいて動作する中レベルのセキュリティ・システムは、第三者が読んだり盗聴できるがグループ・メンバーだけが他のグループ・メンバーのデルタに書き込み、真似（ｉｍｐｅｒｓｏｎａｔｅ）または成りすまし（ｓｐｏｏｆ）できるようなセキュリティ・システムを作成する。
【００４６】
認証／完全性／機密性モードで動作する中レベルのセキュリティ・システムは図６に図示してあるようにデルタのデータを保護する。更に詳しく説明すれば、デルタは鍵バージョン番号６０２及び初期ベクトル６０３の付いたへッダを、データ６０４及びメッセージ認証コード６０６とともに送信することで伝達される。しかし、この場合、データ６０４は暗号化されている。このプロトコルはグループ暗号化鍵ＫＧで暗号化することでデルタ・データの機密性を保護しておりグループ認証子６０６による完全性と認証の保護が継続する。データ６０４は従来の暗号化アルゴリズムを用いてグループ暗号化鍵ＫＧで暗号化され、暗号化されたデータは初期ベクトルと連結される。ここでも認証またはＭＡＣコードは好適実施態様においてへッダと平文データの連結をハッシュ化してからグループ認証鍵ＬＧでハッシュ情報を符号化することにより形成されている。またデータとへッダ及びデータのハッシュの連結をひとつの暗号化キーＫＧで暗号化してからその結果をへッダ、鍵バージョン番号、初期ベクトルと連結することでこのモードを実装することも可能である。後者の暗号化は機密性と認証／完全性を両方とも保証し、２つの鍵ＫＧとＬＧの間で機密性及び認証・完全性の責任を分担する別々のＭＡＣ部分を使用しなくてすむ。図６に図示した実装を実際に使用して後述する高セキュリティ・モードに沿った実装を行なうことができる。
【００４７】
認証／完全性モードで動作する「高レベル」セキュリティ・システムにおいてデルタ・データは図５に図示した構成または図７に図示した構成のどちらかを用いて保護できる。このシステムで使用されるプロトコルは平文デルタ情報を送信するが、認証／完全性を保証するため、シングルターゲットの秘密鍵多重認証子か公開鍵署名認証子のいずれかを使用する。
【００４８】
シングルターゲット秘密鍵多重認証子の場合、図５に図示した構成を使用する。更に詳しく説明すれば、へッダ情報５００は鍵バージョン５０２、暗号化していないデータ５０４、メッセージ認証子５０６とともに送信される。しかし、この場合、鍵バージョン番号５０２は送信者と受信者全部との間の鍵バージョンのすべてを連結したもので構成する。同様に、メッセージ認証子５０６は送信者とそれぞれの受信者との間の個別のメッセージ認証子を連結したもので構成する。それぞれのメッセージ認証子は認証鍵で保護されるが、この認証鍵は送信者と受信者との間でのみ使用されるものである（Ｌｉｊ鍵の一つ）。
【００４９】
更に、好適実施態様では、中間ハッシュをメッセージ認証コードに使用する。更に詳しく説明すると、へッダとデータは連結され、ハッシュされ、更に適当な認証鍵によって保護される。この場合、中間ハッシュは認証鍵それぞれに対してへッダとデルタ全体を再ハッシュするのを避けるために使用している。へッダとデルタをハッシュしたら、適当な認証鍵でハッシュした情報を単純に保護することでこのハッシュを複数回使用できる。
【００５０】
別の実施態様では、公開鍵署名認証子をメッセージ認証コードとして使用する。この構成が図７に図示してある。この構成では、へッダ情報７００が最初に送信され、これに暗号化されていない（Ａ／Ｉモード）または暗号化された（Ａ／Ｉ／Ｃモード）データ７０２が続く。メッセージ認証子コード７０４はハッシュし連結したへッダとデータの公開鍵署名から構成される。
【００５１】
認証／完全性／機密性モードで動作する高レベルセキュリティ・システムは図６と図７に図示したデルタ構成でデータを保護する。基本的にこれは図５と図７に図示してある認証／完全性モードと同じであるが、グループ暗号化鍵ＫＧでデルタ・データが暗号化され図６の場合の初期ベクトルと連結される点で異なっている。
【００５２】
デジタル署名またはデジタル証明書を生成して使用するメカニズムが図８に図示してある。データ８００のデジタル署名を生成するためには、多数の一般的に周知のハッシュ・アルゴリズムの一つを用いて、ステップ８０２に示してあるようにデータ８００のハッシュ値を計算する。ハッシュしたデータはステップ８０４に示したように（暗号化と同様の演算で）公開鍵／秘密鍵ペアのうちの秘密鍵を用いて署名される。その結果がデジタル署名８０６である。更に、データがユーザのＩＤまたは公開鍵に関係する場合、（署名ではなく）データはデジタル「証明書」と呼ばれる。
【００５３】
デジタル署名を使用するには、図８で破線より下に示してあるように有効化手順を実行する。更に詳しく説明すると、ハッシュしたデータの確認（復号に似た動作）のために公開鍵／秘密鍵ペアのうちの公開鍵を使用する署名確認アルゴリズム８１４へ、デジタル署名が矢印８１２で示したように提供され、また証明書が矢印８１８で示したように提供される。データ８００それ自体は矢印８０８で示したようにハッシュ・アルゴリズム８１０へ提供される。このハッシュ・アルゴリズムはデジタル署名を生成するために使用したハッシュ・アルゴリズム８０２と同一のものである。囲み８１６に示したように、データの再ハッシュが確認したハッシュ・データと比較される。結果が同一であれば、確認したハッシュ・データは正しい、すなわちデータは正しく（ａｕｔｈｅｎｔｉｃａｌｌｙ）署名に関連している。
【００５４】
機密グループを形成する手順が模式的に図９に図示してありそのステップが図１０に図示してある。図９に図示してあるように、グループ９００は議長９０２とその他のＮ−１人のメンバーで構成され、そのうち３人がメンバー９０６、９０８、９１０として示してある。グループ９００の形成は議長９０２によって管理され、議長は新しいメンバーを招待して追加する権限を与えられたメンバーである。図示した手順によれば、招待者９０４は初期認証の後でグループ９００へ追加される。以下の議論では認証及び完全性による最高セキュリティ・モードに焦点を当てて説明する。その他の意図されるモードはこのモードから派生させることができる。
【００５５】
加入手順はステップ１０００から始まりステップ１００２に進む。ステップ１００２では、議長９０２が招待されることになる人９０４へ招待メッセージを送信する。このメッセージは図９の矢印９１２で模式的に示してある。このメッセージの内容は図１１に示してある。メッセージはへッダ１１００と、これに続く招待者の名前１１０２から構成され、この名前はＵＲＬやその他の識別情報とすることができる。へッダの順序は本発明の原理から逸脱することなく反転できる。招待者の名前に続くのが署名済み招待「ナンス」（ｎｏｎｃｅ）１１０４である。署名済みナンスは議長によって生成されたタイムスタンプのハッシュ、議長９０２の名前／ＵＲＬ、招待者９０４の証明書（入手可能な場合）、テレスペースの名前／ＵＲＬ、署名つきナンスが発生することが考えられる別の状況を識別するために使用されるタグである招待「オプコード」（Ｏｐｃｏｄｅ）を含む署名データである。
【００５６】
一般的に言って、ナンスはプリンシパルＡが生成してプリンシパルＢへ送信するもので時間とともに変化するパラメータであり、これは任意の状況で一回だけ使用されるものである（例えば、本明細書で説明している招待プロトコルを介してＡがＢを招待する場合など）。実際に、ナンスは状況を定義する、言い換えればプロトコル動作の同時性を保証して再生（ｒｅｐｌａｙ）及びインターリーブ攻撃（ｉｎｔｅｒｌｅａｖｉｎｇ ａｔｔａｃｋ）を防止するために使用される。ナンスは秘密にしなくても良く、１回限りの独自なものであれば良い。各種システムで使用されるナンスの典型的な例としては次のようなものがあげられる：衝突しない乱数、タイムスタンプ（十分に信頼できるクロックを備えたシステム、特に信頼できる分散時刻同期プロトコルの存在下ではほぼ理想的である）、シーケンス番号。好適実施態様ではタイムスタンプが使用されている。
【００５７】
本明細書の状況で重要なことは、プロトコルの実行の全部において、ナンスが（暗号学的な確実性の範囲で）絶対に（ローカル・ポリシーで決定されるなんらかの時間的制約の中で）反復できないことである。これは例えば自分が発行したナンス／招待を（プロトコルの実行に関する他の情報とともに）、不揮発記憶に、ローカル・クロックに合わせてある程度の期間（ローカル・ポリシーによって変化する）、メンバーが記憶しておくことで実現可能で、この時刻以降はナンス情報を破棄してプロトコルの実行を中断させなければならない。
【００５８】
署名つきナンス１１０４に続くのは暗号データ１１０６で、これはこのメッセージで使用されるセキュリティ状態情報である。この情報は議長が選択し受信者がメッセージを正しく解釈できるようにするために必要である。更に詳しくは後述するようなワンタイム鍵で情報を暗号化するのに使用したアルゴリズムの名称の文字列を含む。またメッセージ受信者がメッセージを処理するのに必要なその他なんらかの情報、例えば鍵の長さ、ラウンド数、使用したハッシュ・アルゴリズムの名称、鍵ジェネレータ・アルゴリズムの名称、なども含む。
【００５９】
暗号データ１１０６に続くのは、公開鍵暗号化アルゴリズムに基づいてあらかじめなんらかの合意が得られている招待者の公開鍵で暗号化したワンタイム鍵情報１１０８である。ワンタイム鍵は対称暗号化用の鍵で後述するように招待情報を暗号化するために一回だけ使用される。
【００６０】
鍵情報に続くのが招待情報１１１０で、これはワンタイム鍵で暗号化されている。招待情報も前述したように議長によって生成されたタイムスタンプを含み初期ベクトルと連結できる。招待情報はテレスペース名／ＵＲＬを含むアプリケーション・データで招待者９０４に招待を発行したアクティビティの種類について通知する。これは特に、議長９０２によって権限を委譲（ｍａｎｄａｔｅｄ）されたものとしてテレスペース内で使用しなければならない暗号情報（例えば前述の低／中／高レベル、Ａ／Ｉ／Ｃモード）を含む。このようにすると、招待者には参加するように招待されているテレスペースのセキュリティ特性が招待者に通知され、例えば招待者は参加しないと決定することができる。招待者の証明書が不明な場合、暗号化したワンタイム鍵１１０８を無視しタイムスタンプと招待情報１１１０を暗号化しないで送信する。
【００６１】
招待情報１１１０に続くのはへッダ情報１１００、招待ナンス１１０４、暗号化していないワンタイム鍵（メッセージに含まれる場合）、暗号データ１１０６、暗号化していない招待情報（タイムスタンプなし）のハッシュに対する議長の署名である。この署名は議長の証明書に対して示された情報の全部を結合するもので、議長の証明書は招待者のローカルな公開鍵証明書有効化ポリシーを介して議長に結び付けられている。
【００６２】
送信される情報の最後の部分１１１４は議長の証明書で、議長の名称（ＵＲＬ／ペルソナ）、議長の公開署名確認鍵、及びその他の情報例えば公開鍵アルゴリズム識別子、暗号化公開鍵、などが含まれ、これらすべてが（一つまたはそれ以上の）なんらかの「信頼できる」認証局の署名を介して相互に結合されている。証明書は周知のまたは少なくとも招待者に識別可能ななんらかの証明書フォーマットにフォーマットされる。このフォーマットは公開鍵による証明書（ここで証明書認証局は周知の認証局の階層の内部に組み込まれている）、またはＰＧＰやＳＤＳＩなどを使用した「信頼の輪証明書」（ｗｅｂ−ｏｆ−ｔｒｕｓｔ ｃｅｒｔｉｆｉｃａｔｅ）、あるいは更に単純にこの目的のためだけにその場で構成した自己署名証明書であっても良い。招待者が証明書を頼れる「信頼度」は招待者のローカル公開鍵証明書有効化ポリシーに依存する。
【００６３】
このメッセージを受信すると、招待者は図１５に図示してあるフローチャートに概略してあるステップをとる。招待者の手順はステップ１５００から始まってステップ１５０２へと進み、ここで招待者が暗号データ１１０６を調べてメッセージの暗号化に使用されているアルゴリズムを知る。次にステップ１５０４で、招待者は招待者の名前を検証してその招待が招待者に向けられたものかどうかを確認する。
【００６４】
次に、ステップ１５０６で、招待者が招待者のローカルな公開鍵有効化ポリシーに従って議長の名前／ＵＲＬを含む議長の証明書を有効化する。招待者は適当な証明書有効化プロバイダ（招待者のローカル・ポリシーになっている場合にはｔｒｉｖｉａｌ／初期設定で「自己署名証明書をすべて信頼する」有効化アルゴリズムが実装することがある）を起動することにより行なう。
【００６５】
ステップ１５０８で、招待者は議長の署名を確認してこの招待が本当に議長９０２から来たものかどうかを確かめ招待者９０４が本当に招待されたのかを確かめる。
【００６６】
最後にステップ１５１０で、招待者は招待情報を復号して検証し招待者が議長の招待を受け入れたいかどうかを決定する。そして手順はステップ１５１２で終了する。
【００６７】
図１０に戻ると、招待者９０４が招待を受け入れることに決定した場合、ステップ１００４で招待者９０４は議長９０２へ受諾メッセージを送信して応答する。このメッセージが図９では矢印９１４として模式的に図示してある。これ以外に、招待者が招待を受け入れないと決定した場合、エラーメッセージを招待者９０４から議長９０２へ送信する。
【００６８】
受諾メッセージの内容が図１２に図示してある。メッセージはへッダ１２００と、これに続く署名付きの招待ナンス１２０２で構成され、ナンスは招待メッセージで議長から招待者へ送信されたものである。これを用いることで、議長はこの受諾メッセージが招待に応答したものであると認識できることになる。署名付きナンス１２０２には署名つき受諾ナンス１２０４が続く。署名付き受諾ナンスは招待者が生成したタイムスタンプ、招待者９０４の名前／ＵＲＬ、議長９０２の証明書、テレスペースの名前／ＵＲＬ、そして受諾オプコードを含む。
【００６９】
ナンス１２０４には暗号データ１１０６と同様のセキュリティ内容暗号データ１２０６が続く。
【００７０】
次に、公開鍵暗号化メカニズムを使用して、新しく生成したワンタイム鍵１２０８の公開鍵暗号を送信し、パラメータ、情報、公開鍵暗号化鍵が議長９０２から招待者９０４へ送信される（例えば公開ＲＳＡ暗号鍵）。
【００７１】
暗号化ワンタイム鍵１２０８に続くのはアプリケーション・データ１２１０で、これにはワンタイム鍵を使用して暗号化した２個のタイムスタンプと受諾データを含む。この情報１２１０は招待者９０４の受諾について議長９０２に通知するものである。
【００７２】
次に、招待者９０４の署名を送信する。この署名はへッダ情報１２００、議長の名前と招待者のナンス１２０２に受諾ナンス１２０４を連結したもの、暗号化していないワンタイム鍵、暗号データ１２０６と暗号化していない受諾情報（タイムスタンプなし）のハッシュによる。この署名は招待者の証明書にすべての示された情報を結合する（証明書は更に議長の証明書公開鍵有効化ポリシーを介して招待者９０４に結合されている）。議長９０２の名前がこの署名のスコープ内に含まれ招待者が署名した、議長には分かっているワンタイム鍵を議長が第三者へ送信するのを防止し、これにより招待者９０４を真似なければならないことに注意する。最後に、招待者の証明書１２１４を送信する。
このメッセージの受信時に、議長９０２は図１６のフローチャートに示してある手順を実行する。この手順はステップ１６００から始まりステップ１６０２に進み、ここで議長９０２が暗号化されたワンタイム鍵を復号し、これにより鍵を取り込む。
【００７３】
次に、ステップ１６０４で、議長９０２はワンタイム鍵を使って暗号化された受諾情報を復号する。次にステップ１６０６で、議長は招待者の証明書を検証して招待者の名前を取り出す。
【００７４】
ステップ１６０８で、議長９０２は招待ナンスを再計算して再計算したナンスと受信した招待ナンスとを調べ受諾メッセージが応答している招待がどれかを決定する。本発明の一つの態様によれば招待ナンス（図１１の１１０４）は「ステートレス」つまり関連するタイミングとは無関係に解釈できることに注意する。例えば、メンバーＡが装置１から招待者Ｂへ招待を発行したが後にＢの受諾を装置２で受信したと仮定する。オリジナルの招待メッセージではナンスがデルタ経由でＡの使用可能な全装置へ送信されたとしても、招待者Ｂからの受諾メッセージは招待ナンスを伝達するデルタより先に装置２に到着することがあり装置２でのソフトウェアによる比較ができない場合がある。この問題を回避するため、ナンスに関連した情報は装置２を含めた当該メンバーの装置の全部で視覚的に表示される。この表示の一例が図２３に示してあり表示は例えばユーザ・インタフェース・ダイアログボックス２３００経由で、またはその他の類似のメカニズムを介して行なわれる。図２３に図示してあるように、３項目の情報がダイアログ・ボックス２３００に表示される。これは、招待者Ｂの題名２３０２、招待者Ｂの証明書のメッセージ・ダイジェスト２３０４、及び招待メッセージ署名ナンス２３０５からのタイムスタンプである。
【００７５】
送信者の「証明書」は重要な２項目の情報を伝達するパッケージである：これはメッセージ送信者の「題名」と送信者の「公開鍵」である。この場合、Ｂの題名は装置２のプロトコル・エンジンによって抽出されダイアログ・ボックス２３００のテキストボックス２３０２に表示されている。この名前の一例としては、「ｗｔｕｖｅｌｌ＠ｇｒｏｏｖｅ．ｎｅｔ」がある。Ａはこれで受諾メッセージが招待に対応することを確認できる。
【００７６】
受諾を有効化するためには、Ａはすでに招待者Ｂの対象者名を知っているので、Ａは本発明のコラボレーション・システムとは別の経路から認証のメッセージ・ダイジェストを受け取る必要がある。例えば、この情報を受け取る代表的な方法はＡがＢを電話で呼び出して証明書のメッセージ・ダイジェストがどのようなものなのかを尋ねることである。例えば、この計算したメッセージ・ダイジェストは「０ａ，１ｂ，２ｃ，３ｄ；４ｅ，５ｆ，６ａ，７ｂ；８ｃ，９ｄ，ａｅ，ｃｆ；ｃ１，ｄ２，ｅ３，ｆ４；０５，１６，２７，３８；４９，５ａ，６ｂ，７ｃ」といったようなものになる。
【００７７】
Ａが受諾メッセージを介してＢの証明書を受け取ったら、メッセージ・ダイジェスト（または証明書の「フィンガープリント」）を、受諾メッセージのＢの証明書１２１４から、従来のメッセージ・ダイジェスト・アルゴリズム（例えばＭＤ５やＳＨＡ１など）を用いて図２１と図２２に図示してあるセキュリティ・サービス・アーキテクチャにより、アルゴリズム的に計算する。この再計算したメッセージ・ダイジェストがボックス２３０４に表示される。再計算したメッセージ・ダイジェストがすでに分かっている正しいメッセージ・ダイジェストと一致すれば、Ａは提示された証明書が正しいものであるとして受け入れることができる。それ以外の場合には破棄される。この操作は「証明書有効化」と呼ばれる。
【００７８】
「署名付きナンス」はメッセージの署名である。従って、メッセージのタイムスタンプと送信者の証明書を含む情報を互いに結び付ける。「再生攻撃」を避けるためには（すでに送信された正しいメッセージを再送することによる攻撃）、受諾メッセージに含まれている招待ナンス１２０２のタイムスタンプが受け入れ可能な範囲内にあることを確認することも必要である。タイムスタンプ情報はナンスから抽出されてダイアログボックス２３００のボックス２３０５に表示される。この情報は、例えば、「２００００４０７１２１１２４Ｚにあるｎａｓｈｔｇｉｒｉ＠ｇｒｏｏｖｅ．ｎｅｔあての招待メッセージ」といったものである。Ａは幾らか早い時刻にタイムスタンプを生成したのであるから、おそらくＡはその時刻を知っている。メンバーＡはタイムスタンプを解釈して情報が受け入れられるものかどうかを決定できる。メンバーＡが情報を受け入れる場合には、ＯＫボタン２３０６をクリックし、そうではないなら中止ボタン２３０８をクリックする。
【００７９】
同様の問題は招待者Ｂが受諾を送信した装置とは別の装置でテレスペース・データを受け取った場合にも発生する。この後者の問題は同じ方法で処理される。
【００８０】
次に、ステップ１６１０で、議長９０２は議長のローカル公開鍵ポリシーにしたがって招待者の証明書を有効化する。議長がすでに招待者の証明書を先の招待メッセージの時点で持っているならこのステップは省略しても良く、その時点で行なった有効化に満足している。議長は適当な証明書有効化プロバイダを起動することによりこの有効化を行なう。
【００８１】
次に、ステップ１６１２で、議長９０２は招待者の署名を確認し、招待者の署名は更に受諾メッセージの認証／完全性を確認し、この受諾が本当に招待者９０４から来たものであることを確かめる。
【００８２】
次に、ステップ１６１４で、議長は復号した受諾情報を検証して招待情報と一致することを確認し、議長が招待者の受諾を認めたいかどうかを決定する。
最後に、ステップ１６１６で、オプションで追加の署名として議長は自分自身の署名を招待者の証明書に追加することができる。この追加署名によってポリシーが有効になるのでグループ・メンバーは議長９０２の証明書を信頼している限り招待者の証明書を有効化できる。
【００８３】
手順はステップ１６１８で終了し、情報が真正なものなら招待者はこれ以後「テレスペースのメンバー」となる。図１０に戻って、ステップ１００６に記載してあるように、議長９０２が「新規メンバー追加」デルタをグループ９００に存在する全メンバーに送信する。これらの新規メンバー・メッセージは図９で矢印９１６、９１８、９２０として模式的に示してある。
【００８４】
議長が他のそれまでに存在しているメンバーへ送信する新規メンバー追加メッセージの内容が図１３に示してある。デルタ・メッセージはへッダ１３００と、これに続けて統合鍵バージョン番号情報を含み、鍵バージョン情報はグループ鍵とすべての認証／完全性の鍵についての全部の鍵バージョン番号を連結したものである。
【００８５】
統合鍵バージョン１３０２には、暗号化した新規グループ暗号鍵及び認証鍵の連結からなる再キーイング情報１３０４が続く。それぞれのメンバー対に対して、グループ暗号鍵及び認証鍵を連結したものがメンバー同士で対になった鍵を使って暗号化され、結果が初期ベクトルと連結される。これらの連結された鍵が更に連結されて統合再キーイング情報１３０４を形成する。新しいキーは古い／現在のグループ鍵ＫＧ／ＬＧを置き換える。新規に追加されたメンバーは古い／現在のグループ鍵を知ることはない。この再キーイングは新規メンバーがそれ以前のテレスペース通信を記録したり読み取れないようにするために必要である。
【００８６】
次に、新規グループ暗号鍵で暗号化し初期ベクトル１３０６と連結した参加情報を送信する。このデルタの内容は、招待者の名前に招待者の証明書と参加情報を連結したものである。参加情報は議長９０２が生成したアプリケーション・データで、他のグループ・メンバーが、メンバー・マネージャ情報を含めて、知る必要のある新規メンバーについての情報に関連する。またテレスペースのメンバーやその他各種情報例えば招待者の役割などのリストを含めることができる。
【００８７】
最後に、メッセージ多重認証コード１３０８を送信する。これは議長と各メンバーの間の認証子を連結したものとすることができる。各認証子は議長からメンバーへのペアになった認証鍵Ｌ０ｊで保護されているハッシュ情報である。ハッシュ情報はへッダ１３００と、統合新規グループ鍵情報１３０４と、暗号化していないデルタ情報を含む。これ以外に、メッセージ認証コードは前述のハッシュ情報の議長署名とすることができる。
【００８８】
図１３に示したメッセージを受け取ると、各メンバー９０６〜９１０は図１７のフローチャートに示してあるステップを実行する。この手順はステップ１７００で始まりステップ１７０２へ進み、ここでメンバーが暗号化されたグループ鍵を復号し、これによって新しいグループ鍵ＫＧ／ＬＧを知る。しかし、各メンバーは、ＫＧ／ＬＧで保護された古いデータが存在しないことを確認するのに必要とされる限り、古い／現在のグループ鍵ＫＧ／ＬＧの知識を保持している必要がある。その後、各メンバーは古い鍵ＫＧ／ＬＧを破棄しその痕跡をすべて抹消する。
【００８９】
次に、ステップ１７０４で、暗号化されたデルタ情報を各メンバーが復号し、これによってデルタ内の情報を知る。ステップ１７０６では、メンバーが認証鍵で暗号化された多重認証子の項目を介して、メッセージの認証／完全性を確認する。
【００９０】
次に、ステップ１７０８で、メンバーは議長９０２が（議長のＩＤはへッダ情報として送信される）議長であること、また新規メンバーを追加する権限があることを確かめる。
【００９１】
ステップ１７１０では、メンバーがデルタ情報を実行する。これを行なう最中に、メンバーは招待者の名前、証明書、参加情報を含めた新規メンバー・マネージャ情報に気づく。手順はステップ１７１２で終了する。
【００９２】
最後に、図１０に戻って、ステップ１００８で、矢印９２２で模式的に示したように、議長９０２が招待者９０４へテレスペース情報を送信する。手順はステップ１０１０で終了する。テレスペース情報は図１４に示したメッセージとともに招待者９０４へ送信される。この情報はへッダ１４００で始まり、ノンス１２０４と同一の署名つき受諾ナンスが続く。これに、図１２に示した受諾メッセージに関連して説明したように暗号データ１４０４と暗号化したワンタイム鍵（これは新規に生成する）１４０６が続く。
【００９３】
暗号化したワンタイム鍵１４０６のあとには直前のメッセージ部分にあるワンタイム鍵で暗号化されたテレスペース（ＴＳＰ）データが続く。このデータはワンタイム鍵で暗号化したペイロードと連結された初期ベクトルを含む。ペイロードは招待者が生成したタイムスタンプと連結グループ暗号及び認証鍵ＫＧ／ＬＧ、及びＴＳＰデータである。ＴＳＰデータは招待者がメンバーから受信を許可されているＴＳＰデータのメンバーによるバージョンを含むアプリケーション・データである。
【００９４】
暗号化されたＴＳＰデータ１４０８には、へッダ１４００、招待者の名前、署名付きナンス１４０２、連結グループ暗号及び認証鍵、暗号化していないワンタイム鍵、暗号情報１４０４、暗号化していないＴＳＰデータを含むハッシュ情報に対する議長の署名１４１０が続く。最後に、議長の証明書１４１２が後続する。
【００９５】
このメッセージを受信すると、招待者９０４は図１８に示した手順を実行し、手順はステップ１８００で始まりステップ１８０２へ進みここで招待者９０４は暗号化された１回限りの鍵（以下、ワンタイム鍵）を復号してワンタイム鍵を取り出す。
【００９６】
次に、ステップ１８０４で、招待者はワンタイム鍵を使用して暗号化されたＴＳＰデータを復号し、ＴＳＰ情報を取り出す。次に、ステップ１８０６で、招待者９０４は署名つき受諾ナンスを再計算してこれと受信したナンスとを比較してこれが受け入れられるものであることを確認する。先に説明したように、この比較はソフトウェアでまたは視覚的検査によって行なうことができる。このノンスは議長の証明書を含んでいるので、招待者はこの証明書を再有効化する必要がない。
【００９７】
ステップ１８０６では、招待者９０４が議長の署名を検証し、ステップ１８０８では、招待者が復号したＴＳＰデータを初期の「作成中テレスペース」に広める。唯一残っている、なすべきことはテレスペースの他のすべてのメンバーと鍵ペアを交換することで、そのあと、招待者はテレスペースの完全なメンバーとなる。
【００９８】
鍵ペアは再キーイング手順で交換でき、ここで再キーイング情報は他の情報を搬送するデルタに「ピギーバック（相乗り）」する形になる。この再キーイングを実行するための一つのプロトコルは図１３に示した新規メンバー追加デルタ・メッセージで前述した。再キーイング情報は他のデルタ・メッセージに挿入することもできる。このようなピギーバック型デルタ・メッセージは通常のデルタ・メッセージだが、鍵変更（グループ／テレスペース鍵（ＫＧ／ＬＧ）、トライブ／サブグループ鍵（トライブＴ１、ＴｎについてＫＴ１／ＬＴ１、ＫＴｎ／ＬＴｎ）及び／または鍵ペア（Ｋｉｊ／Ｌｉｊ）のあらゆる組み合わせに同時に関係する）がデルタ・メッセージにピギーバックする点で異なっている。デルタそれ自体は同時にトライブＴｋに適した新しい鍵で暗号化される。新しい（再キーイングされた）鍵はこのメッセージで搬送される。鍵ペアがメッセージにピギーバックしている場合、メッセージは公開鍵署名認証子によって保護される。それ以外の場合では、メッセージは現在の鍵ペアを用いる多重認証コードによって保護される。
【００９９】
このようなメッセージの一例が図１９に示してある。デルタ・メッセージはへッダ１９００と、これに続く統合鍵バージョン情報１９０２を含み、統合鍵バージョン情報は新規グループ鍵とすべての新規トライブ認証／完全性鍵についてのすべての鍵バージョン番号の連結である。
【０１００】
統合鍵バージョン情報１９０２には第２のセクション１９０４が続き、これも統合鍵バージョン情報を含む。鍵ペア変更が送信中の場合、この情報は新しい鍵ペアについてのすべての鍵バージョン番号の連結を含む。別の場合は、グループ鍵とトライブ鍵を再キーイングしている場合情報１９０４は古いまたは現在の鍵ペアについての統合鍵バージョン情報を含む。
【０１０１】
統合鍵バージョン１９０４に続くのが統合再キーイング情報１９０６で、これは新しいグループ及びトライブ鍵（ＫＧ／ＬＧ及びＫＴ／ＬＴ）の連結から構成される。各メンバーのペアについて、連結されたグループ暗号化及び認証鍵はメンバーのペアに対して鍵ペアを用いて暗号化され、その結果が初期化ベクトルに連結される。これらの連結された鍵はそれら自身連結されて統合再キーイング情報１９０６を形成する。新しい鍵は古い／現在のグループ鍵ＫＧ／ＬＧを置換する。新しい鍵ペアが転送中の場合、統合グループ再キーイング情報には新しい鍵ペアに対する統合再キーイング情報が続く。各メンバーのＫ／Ｌ鍵は連結されそのメンバーの公開鍵を用いて暗号化される。これらの暗号化された鍵は連結されて統合鍵ペア再キーイング情報を形成する。
【０１０２】
次に、新しいグループ暗号化鍵で暗号化されて、新しい鍵１９０８に対応する初期ベクトルに連結されたデルタ情報が送信される。このデルタの内容は従来のあらゆるデルタ・メッセージとすることができる。
【０１０３】
最後に、メッセージ多重認証コード１９１０が送信される。これはメンバー間の認証子を連結したものとすることができる。それぞれの認証子は送信側メンバーから受信側メンバーへのペアになった認証鍵Ｌｉｊで保護されたハッシュ情報である。ハッシュ情報はへッダ１９００と、統合新規グループ鍵情報１９０４（またこれが送信中の場合には統合新規鍵ペア情報）、更に暗号化されてないデルタ情報を含む。ペアになった鍵がメッセージにピギーバックしている場合には、多重認証コードの代わりに、公開鍵署名認証子を送信する。
【０１０４】
前述のセキュリティ・システムは様々な方法で実装できる。好適実施態様では、図２０に模式的に示したプロバイダ・アーキテクチャを使用する。このようなアーキテクチャが好ましいのは、前述したセキュリティ・プロトコルが「アルゴリズム中立」であることによる、つまり特定の暗号化及び保護アルゴリズムに依存していないためである。このプロトコルはアルゴリズムに中立なインフラストラクチャ例えば図２０に図示してあるそれを利用できる。図２０は縦方向の次元と横方向の次元で構成される２次元構造を示す。縦方向の次元は数個の抽象層から構成され、横方向の次元は縦方向の層を含めた各種アプリケーション及びサービスで構成される。最上部の層はアプリケーション層で、アプリケーションの組を含み、そのうちのアプリケーション２０００と２００２が図示してある。これらのアプリケーションには、分散通信システム及びコラボレーション・システム、例えば前述のコラボレーション・システムや、保護データ記憶、可用性（サービスの非拒絶）、システム管理、医療情報システム、航空管制システム、原子力発電所、軍事情報作戦指令管制システムなどを含み、これだけに限定されない。
【０１０５】
アプリケーション２０００及び２００２は一つまたはそれ以上のセキュリティ・サービスにアクセスするが、そのうちサービス２００４と２００６を図示してある。これらのサービスには、例えば識別、認証、完全性、機密性、プライバシー、許可、権威の代理、アカウンタビリティと非拒絶、タイムスタンプ、公証（ｎｏｔａｒｉｚａｔｉｏｎ）、監査、信頼ポリシー管理、侵入検知及び復旧サービスなどを含む。
【０１０６】
セキュリティ・サービスは抽象プリミティブ・サービス２００８と２０１０を含む抽象（またはアルゴリズムに中立な）プリミティブ・サービスの組み合わせにより実装される。抽象プリミティブ・サービスは実際には具象（またはアルゴリズム特異的な）プリミティブ・サービスの組み合わせによって実装される。例えば、抽象プリミティブ・サービス２００８は具象プリミティブ・サービス２０１２、２０１４、２０１６により実装され、一方抽象プリミティブ・サービス２０１０は具象プリミティブ・サービス２０１８、２０２０、２０２２によって実装される。これらの具象プリミティブ・サービスは例えば特定の暗号サービスやプロトコルなどのサービスを含む。
【０１０７】
各抽象層は高次の抽象層または層群によって消費されるサービスを作成する。好適な実装では、アプリケーション２０００、２００２とセキュリティ・サービス２００４、２００６の間の関連性、ならびにセキュリティ・サービス２００４、２００６と抽象プリミティブ・サービス２００８、２０１０の間の関連性は従来どおりの、これらの層の間で静的なコンパイル時に決定される結合（ｃｏｍｐｉｌｅ−ｔｉｍｅ ｂｉｎｄｉｎｇｓ）である。しかし抽象プリミティブ・サービス２００８、２０１０と具象プリミティブ・サービス（２０１２、２０１４、２０１６、２０１８、２０２０、２０２２）の間の結合は、制約された方法で一つの抽象プリミティブ・サービスと一つまたはそれ以上の具象プリミティブ・サービスを関連づける動的なランタイム結合であるのが望ましい。この動的な結合は「プロバイダ・アーキテクチャ」と呼ばれ、抽象またはアルゴリズム中立なプリミティブ・サービスをなんらかの具象またはアルゴリズム特定のそれで作成することにより実装できるメカニズムであり、実装は任意の時刻にその環境内でアクティブにすることができるようなものである。
【０１０８】
図２１と図２２はプロバイダ・アーキテクチャの特定の実装を模式的に示している。オブジェクト指向プログラミング技術をこの実装では用いているが、他の等価な技術やプログラミング言語で実装することもできることは当業者に理解されるであろう。更に詳しく説明すると、図示した実装はダイナミック・リンク・ライブラリ（ＤＬＬ）を使用して各種サービスを提供している。
【０１０９】
ＤＬＬは図２１と図２２のそれぞれに図示してある。図２１に図示したＤＬＬ はセキュリティ・サービス・マネージャ（ＳＳＭ）と呼ばれるもので、図２２に図示したＤＬＬはセキュリティ・サービス・プロバイダ（ＳＳＰまたは単にプロバイダ）と呼ばれる。セキュリティ・サブシステムのどのランタイム・インスタンシエーションにも必ず一つだけＳＳＭ ＤＬＬがロードされる。一方でＳＳＰ ＤＬＬは何個でもロードでき、それらがすべて独立しているという制限が加えられるだけである（これらがすべてシステム・レジストリなどのファイルに記録されている通りの独立したＬＩＢＩＤとファイル名を有するという意味で）。ＳＳＰ ＤＬＬの名称はそのデベロッパが選択する。図示したＳＳＰ ＤＬＬの例はＳｅｃＰｒｏｖＸＸＸ．ｄｌｌというような名前がつけられていると考えられ、他のＤＬＬはＳｅｃＹＹＹＰｒｏｖ．ｄｌｌまたはＺＺＺＳｅｃＰｒｏｖ．ｄｌｌというような名前をつけることができる。
【０１１０】
図２１と図２２のボックスはマイクロソフト・コモン・オブジェクト・モデル（Ｍｉｃｒｏｓｏｆｔ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）に適合するＣＯＭクラスを示す。これらのクラスは、エンジン・クラス（右側に示す）と非エンジン・クラス（左側に示す）の２種類のグループに大別される。ＣＯＭエンジン・クラスのそれぞれは一つだけＩＤＬインタフェースを実装してエクスポートする。例えば、エンジン・クラス２１０６（ＭｅｓｓａｇｅＤｉｇｅｓｔ）はインタフェース２１０４（ＩＭｅｓｓａｇｅＤｉｇｅｓｔ）をエクスポートし、エンジン・クラス２１１８（ＫｅｙＧｅｎｅｒａｔｏｒ）はインタフェース２１１６（ＩＫｅｙＧｅｎｅｒａｔｏｒ）をエクスポートし、エンジン・クラス２１２６（Ｃｉｐｈｅｒ）はインタフェース２１２４（ＩＣｉｐｈｅｒ）をエクスポートする。これはインタフェース２１００をエクスポートするＳｅｃｕｒｉｔｙクラス２１０２についても言えることである。図２２に図示した具象クラスについても同じことが当てはまる。例えば、具象エンジン・クラス２２０４（ＸＸＸＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ）はインタフェース２２０６（ＩＭｅｓｓａｇｅＤｉｇｓｅｔＳｐｉ）をエクスポートし、エンジン・クラス２２０８（ＸＸＸＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）はインタフェース２２０６（ＩＫｅｙＧｅｎｅｒａｔｏｒＳｐｉ）をエクスポートし、エンジン・クラス２２１０（ＸＸＸＣｉｐｈｅｒＳｐｉ）はインタフェース２２１２（ＩＣｉｐｈｅｒＳｐｉ）をエクスポートする。
【０１１１】
プロバイダ抽象クラス２１２２とＸＸＸＰｒｏｖｉｄｅｒ具象クラス２２００（図２２）で形成されるプロバイダ／ＸＸＸプロバイダ（Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ）「複合クラス」についても同じことが言える。更に詳しく説明すると、Ｐｒｏｖｉｄｅｒクラス２１２２はＩＰｒｏｖｉｄｅｒインタフェース２１２０をサポートし、ＸＸＸＸＰｒｏｖｉｄｅｒクラス２２００はＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（図２２には図示していない）をサポートする。しかし、Ｐｒｏｖｉｄｅｒクラス２１２２はＸＸＸＰｒｏｖｉｄｅｒ クラス２２００の内部でのみ統合可能で、したがって独立してインスタンシエーションできない。つまり、ＩＰｒｏｖｉｄｅｒ２１２０インタフェースとＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースの両方がＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００によって「エクスポート」されることになる。
【０１１２】
Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラスと図２１に図示したエンジン・クラスの全部は図２２に図示してある他の一つのクラスと組み合わされる（ただしこれは多数のＳＳＰを構成することができそれぞれが多数のアルゴリズムをサポートできることから多面的な関係である）。ＳＳＭ ＤＬＬ（図２１）のパートナーは抽象パートナーと呼ばれ、ＳＳＰ ＤＬＬ（図２２）のパートナーは具象パートナーと呼ばれる。図２１と図２２の左側には、「マスター」クラスと呼ばれる２種類のＣＯＭクラスがあり、これはＳｅｃｕｒｉｔｙクラス２１０２とＰｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒ複合クラス２１２２／２２００である。Ｓｅｃｕｒｉｔｙクラス２１０２が「マスター」クラスであるという意味は、各種「スレーブ」Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスを制御できるということである。逆に、各種Ｐｒｏｖｉｄｅｒ／ＸＸＸＰｒｏｖｉｄｅｒクラスが「マスター」であるということの意味は、これらが各種のスレーブ低レベル／具象エンジン・クラスを制御すると言うことである。マスター・クラスはほとんどセキュリティ・サブシステムの内部的なもので大半のアプリケーションからは見えない。
【０１１３】
図２１と図２２の右側にはエンジン・クラスと呼ばれる２種類のＣＯＭクラスがあり、これらは図２１に図示した抽象エンジン・クラスと図２２に図示した具象エンジン・クラスである。抽象エンジン・クラスはｍ＿Ｅｎｇｉｎｅフィールドの値に０を持っていれば純粋に抽象的であると言われる。３種類のエンジン・クラス（ＭｅｓｓａｇｅＤｉｇｅｓｔ、ＫｅｙＧｅｎｅｒａｔｏｒ、Ｃｉｐｈｅｒ）が説明のために図示してあるが、これらの個数は原理的に制限されない。これらのエンジン・クラスは図２１と図２２に図示してあるように対で発生し、低レベルのクラスが高レベルのクラスの内部に内包または封入される（ｍ＿Ｅｎｇｉｎｅメンバーを経由する）。高レベル・エンジン・クラスの機能はセキュリティ・サービスの消費者が起動するアプリケーション・プログラミング・インタフェース（ＡＰＩ）をエクスポートすることである。低レベル・エンジン・クラス名に見られる接尾辞「Ｓｐｉ」はサービス・プロバイダ・インタフェース（またはセキュリティに関して言えばセキュリティ・プロバイダ・インタフェース、また時に他の状況下ではシステム・プログラミング・インタフェース）を意味するもので、これの唯一の消費者は高レベル・エンジン・クラスである。これらの低レベル・エンジン・クラス内に実際のアルゴリズム特有の実装コードが存在する−−これが「ＳＳＰ ＤＬＬ」の実際に「提供する」最終的な機能である。エンジン・クラスを２つの部分に分割したことが、これらのサポートするサービスの命名構造に反映されており、完全認証サービス名は抽象／概念の接頭辞と具象／アルゴリズムの接尾辞、例えばＭｅｓｓａｇｅＤｉｇｅｓｔ．ＭＤ５というように構造化される。
【０１１４】
各具象ＳＳＰ（ＸＸＸＰｒｏｖｉｄｅｒクラス２２００）は静的な情報を含み、これにはその名前（ｓ＿ＭｙＮａｍｅ、文字列）、バージョン（ｓ＿ＭｙＶｅｒｓｉｏｎ、数字）、クラスＩＤ（ｓ＿ＭｙＣｌｓｉｄ、１６バイト二進数）、情報（ｓ＿ＭｙＩｎｆｏ、文字列）、ＤＬＬにバンドルされているサービスのリスト（ｓ＿ＭｙＳｖｃＭａｐ［］、文字列のペアのリスト）を含む。ｓ＿ＭｙＳｖｃＭａｐ［］の各エントリでは、一方の文字列がそのサービスで実装するアルゴリズムの名称、他方がそのアルゴリズムを実装する具象エンジン・クラス（ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌにバンドルされる）のＣＯＭ ＣＬＳＩＤ（クラスＩＤ）である。
【０１１５】
エンジン・クラスに加えて、セキュリティ・サブシステムは多数の非エンジン・クラスを含む。代表的な２つのクラス、ＫｅｙとＫｅｙＰａｉｒが図２１に示してある。図面が示すように、このような非エンジン・クラスは相対的に通常のＣＯＭ クラスで、唯一普通とは違う特徴は（抽象）インタフェース・クラスであり（具象）実装クラスはＳＳＭ ＤＬＬ（図２１）とＳＳＰ ＤＬＬ（図２２）の間で分割される（されない）ことである。例えば、Ｋｅｙクラス２１１０の場合だと、ＳＳＭは一般に任意のＳＳＰの鍵がどのようなものであるべきかについての優先的な（インタフェース）知識を持っているが、ＳＳＰそれ自体はＳＳＭによって例えばＸＸＸＫｅｙクラス２２１０によって定義されるインタフェースに準拠したＫｅｙクラスの詳細な実装を供給する必要がある。しかしＫｅｙＰａｉｒクラス２１１４の場合、ＳＳＭはすでに実装についての詳細な知識を持っている−−これはＫｅｙ（それがどのようなものであっても）のペアで構成される。
【０１１６】
セキュリティ・サブシステムをブートする場合、例えば、Ｓｅｃｕｒｉｔｙクラス２１０２がランタイム時に最初にＣｏＣｒｅａｔｅされ、Ｓｅｃｕｒｉｔｙクラス２１０２はＳｅｃｕｒｉｔｙクラスのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）メソッドで次のようなことを行なう。第１に、Ｓｅｃｕｒｉｔｙクラス２１０２は例えばレジストリ（Ｒｅｇｉｓｔｒｙ）に保存されている構成情報を読み込む。
【０１１７】
次に、それぞれの構成された具象プロバイダＸＸＸＰｒｏｖｉｄｅｒ（レジストリから読み出したばかりの）のＰｒｏｇＩＤ（またはＣＬＳＩＤ）に基づいて、セキュリティ・クラスがＸＸＸＰｒｏｖｉｄｅｒ２２００のインスタンスをＣｏＣｒｅａｔｅし、ＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェース（Ｃｔｏｒはコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）の意味）へのポインタを得る。ＸＸＸＰｒｏｖｉｄｅｒクラスをＣｏＣｒｅａｔｅするこの動作は更にＸＸＸＰｒｉｖｉｄｅｒのＦｉｎａｌＣｏｎｓｔｒｕｃｔ（）にＸＸＸＰｒｏｖｉｄｅｒ２２００内部の抽象ＰｒｏｖｉｄｅｒクラスのオブジェクトをＣｏＣｒｅａｔｅして統合する。
【０１１８】
次に、いまＣｏＣｒｅａｔｅしたばかりのＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースを使って、Ｓｅｃｕｒｉｔｙクラス２１０２がＸＸＸＰｒｏｖｉｄｅｒのｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドをＩＰｒｏｖｉｄｅｒＣｔｏｒインタフェースから呼び出す。この特別なｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの名称／バージョン／情報／ｃｌｓｉｄ／サービス・データを、「ハードワイヤードな」静的数値変数の位置から統合Ｐｒｏｖｉｄｅｒオブジェクト内の非静的メンバー変数へ「アップロード」する（ｎｏ−ａｒｇ−Ｃｔｏｒ（）メソッドはＸＸＸＰｒｏｖｉｄｅｒの統合Ｐｒｏｖｉｄｅｒサブオブジェクトによってエクスポートされるなんらかのメソッドを呼び出すことでこれを完了する）。
【０１１９】
第４に、Ｓｅｃｕｒｉｔｙクラス２１０２は各種の構成された具象プロバイダを指すＩＰｒｏｖｉｄｅｒ＊の静的内部構成リストｓ＿ＰｒｏｖＬｉｓｔ［］を構築する。Ｓｅｃｕｒｉｔｙクラス２１０２は、Ｓｅｃｕｒｉｔｙクラス２１０２がこの時点まで使っていたＸＸＸＰｒｏｖｉｄｅｒのＩＰｒｏｖｉｄｅｒＣｔｏｒ＊インタフェースでＱｕｅｒｙＩｎｔｅｒｆａｃｅを呼び出すことで各ＩＰｒｏｖｉｄｅｒ＊を構築する。構成されたＳＳＰのリストｓ＿ＰｒｏｖＬｉｓｔ［］はＳｅｃｕｒｉｔｙクラス２１０２のｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを介してクライアントが利用できるようになる。
【０１２０】
アプリケーションは次のような方法でプロバイダ・アーキテクチャを実際に使用する。あるアプリケーションがＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクト上でｄｉｇｅｓｔ（）メソッドを呼び出して特定メッセージ（バッファ）のダイジェストを実際に計算したいと想定する。アプリケーションはＳＳＭで抽象エンジン・クラスを知っている（すなわちＳｅｃｕｒｉｔｙＳｖｃｓ．ｄｌｌのクラスのＣＬＳＩＤ）。これは作成中にこの情報へリンクされたためだが、現実のアルゴリズム実装が実際に存在するＳＳＰ内の具象エンジン・クラスについては優先順位（すなわち、ＳｅｃＰｒｏｖＸＸＸ．ｄｌｌのクラスのＣＬＳＩＤ）を知らない。したがって、アプリケーションは抽象エンジン・オブジェクトを直接ＣｏＣｒｅａｔｅできるが、具象エンジン・オブジェクトは直接ＣｏＣｒｅａｔｅ できない。しかし、好適実施態様では、抽象エンジン・オブジェクトがｇｅｔＩｎｓｔａｎｃｅ（）と呼ばれるファクトリ・メソッドを有するクラス・ファクトリ・オブジェクトとして処理され、次のように、間接的に具象エンジン・オブジェクトを作成している。
【０１２１】
アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔクラス２１０６から純粋な抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅすることから開始する。このようなオブジェクトは具象エンジン・オブジェクトへ接続されないのでダイジェストを作成するためには使えない、すなわち主状態変数ｍ＿Ｅｎｇｉｎｅは値に０を持っている（副状態変数ｍ＿ＡｌｇＮａｍｅとｍ＿ＰｒｏｖＮａｍｅも同様）。いまＣｏＣｒｅａｔｅしたＩＭｅｓｓａｇｅＤｉｇｅｓｔ＊インタフェース２１０４を使って、アプリケーションはＭｅｓｓａｇｅＤｉｇｅｓｔのｇｅｔＩｎｓｔａｎｃｅ（）メソッドを呼び出し、使いたいメッセージ・ダイジェスト・アルゴリズムの周知の名前を指定する。ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはファクトリ・メソッドで、次のステップを実行する。第１に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドがＳｅｃｕｒｉｔｙオブジェクトでｇｅｔＰｒｏｖｉｄｅｒｓ（）メソッドを呼び出して現在構成されているプロバイダのリストをフェッチする。次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはいまフェッチしたばかりのＳＳＰのリストを使って、要求されたアルゴリズムをサポートする最初のＳＳＰが見つかるまで、好適な順番で各ＳＳＰのｇｅｔ（）メソッドを呼び出す。ＳＳＰのｇｅｔ（）メソッドはＳＳＰのｍ＿ＳｖｃＭａｐ［］を使用し、アルゴリズム名を具象エンジン・クラスＰｒｏｇＩＤにマッピングする。つまりこの例では、クラス２０２２のｇｅｔ（）メソッドが要求されたアルゴリズムをサポートしているＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ具象エンジン・クラスのＰｒｏｇＩＤを返す。
【０１２２】
次に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはｇｅｔＩｎｓｔａｎｃｅ（）メソッドが呼び出されたＭｅｓｓａｇｅＤｉｇｅｓｔとは別に新しく抽象ＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトをＣｏＣｒｅａｔｅする。まず、この新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトはもう一つの純粋な抽象エンジン・オブジェクトだが、次のステップでｇｅｔＩｎｓｔａｎｃｅ（）メソッドは完全な／接続されたエンジン・オブジェクトへ（すなわちｍ＿Ｅｎｇｉｎｅフィールドを介してこれの内部に含まれる／作成される具象エンジンとあわせて「非純粋」抽象エンジン・オブジェクトに）変化させる。
【０１２３】
最後に、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは新しいＭｅｓｓａｇｅＤｉｇｅｓｔオブジェクトのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドを呼び出し、パラメータとして上記で呼び出したｇｅｔ（）オブジェクトから取得したＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ ＣＬＳＩＤ（またはＰｒｏｇＩＤ）を渡す。そのｃｏｎｓｔｒｕｃｔｏｒ（）メソッドはクラス２１０４からＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉオブジェクトのインスタンスをＣｏＣｒｅａｔｅし、新しいＭｅｓｓａｇｅＤｉｇｅｓｔのｍ＿Ｅｎｇｉｎｅフィールドへ得られたＩＭｅｓｓａｇｅＤｉｇｅｓｔＳｐｉ＊ポインタを格納する。
【０１２４】
つまり、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドはアプリケーションへ完全に完成／接続したＭｅｓｓａｇｅＤｉｇｅｓｔエンジン・オブジェクトを返す。この時点で、アプリケーションはエンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドを呼び出してメッセージのダイジェストを計算する。（抽象）エンジン・オブジェクトのｄｉｇｅｓｔ（）メソッドは具象エンジン・オブジェクトのｅｎｇｉｎｅＤｉｇｅｓｔ（）メソッドへの呼び出しを代理または転送して実際の作業を行なわせる。
【０１２５】
上記で説明した実施態様のソフトウェアによる実装は、有形の媒体例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤＲＯＭ、ＲＯＭメモリ、または固定ディスクなどに固定されるか、モデムまたは媒体上のその他のインタフェース装置を介してコンピュータ・システムへ転送可能な一連のコンピュータ命令を含む。媒体は光またはアナログ通信線を含みこれに限定されない有形の媒体としたり、マイクロ波、赤外線またはその他の電送技術を含みこれに限定されない無線技術で実装することができる。媒体はインターネットの場合もある。一連のコンピュータ命令は本発明に関して本明細書ですでに説明した機能の全部または一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用される多数のプログラミング言語で書けることが当業者には理解されよう。更に、このような命令は、現在または将来の、半導体、磁気、光、またはその他のメモリ装置を含みこれに限定されないなんらかのメモリ技術を用いて保存したり、あるいは現在または将来の、光、赤外線、マイクロは、またはその他の伝送技術を含みこれに限定されないなんらかの通信技術を用いて伝送される。このようなコンピュータ・プログラムは印刷物または電子文書を伴なう取り出し自由な媒体として、例えばシュリンクラップ包装ソフトウェアとして配布されたり、コンピュータ・システムに例えばシステムＲＯＭや固定ディスク上にプリロードされていたり、またはサーバまたは電子掲示板から例えばインターネットまたはワールド・ワイド・ウェブなどのネットワーク上で配布されることがあると想定される。
【０１２６】
本発明の代表的実施態様を開示したが、本発明の利点のいくつかを実現し本発明の主旨と範囲から逸脱しない各種の変化及び変更を加えることができることは当業者に明らかであろう。例えば、説明は特定のハードウェア・システム及びオペレーティング・システムを指向したものだったが、他のハードウェアやオペレーティング・システム・ソフトウェアを説明したそれと同じ方法で使用できることは当業者には明らかであろう。例えば特定の関数を実現するために使用された特定の命令などのその他の態様ならびに本発明の概念に対するその他の変更も付録の請求の範囲によって包含されることを意図している。
【図面の簡単な説明】
【図１】 図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図である。
【図２】 図２、はデルタを用いてローカルなデータ・コピーを更新する代表的なコラボレーション・システムの略ブロック図である。
【図３】 図３は、グループ、トライブ、またそれらを保護するために使用される暗号化及び認証鍵を示す略ブロック図である。
【図４】 図４は、低レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図５】 図５は、認証／完全性モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図６】 図６は、認証／完全性／機密モードで動作する中レベルのセキュリティ・システムまたは高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図７】 図７は、認証／完全性モードで動作する高レベルのセキュリティ・システムにあるグループ内のメンバー間で送信されるデルタの内容を示す略図である。
【図８】 図８は、デジタル署名と証明書の作成及び確認を示す略ブロック図である。
【図９】 図９は、既存のグループへの新規メンバー（招待者）の追加を示す略ブロック図である。
【図１０】 図１０は、既存のグループへ新規メンバーを追加するために議長（ｃｈａｉｒ）を使用するような代表的ルーチンのステップを示すフローチャートである。
【図１１】 図１１は、議長から招待者へ送信される招待メッセージの内容を示す略図である。
【図１２】 図１２は、招待者から議長へ送信される受け入れメッセージの内容を示す略図である。
【図１３】 図１３は、グループの既存のメンバー全員へ議長から送信されて新規メンバーが追加されたことを告知する新規メンバー追加デルタの内容を示す略図である。
【図１４】 図１４は、議長から新規に追加されたメンバーへ送信されてテレスペース・データのメンバーを告知するメッセージの内容を示す略図である。
【図１５】 図１５は、招待者が招待に応答するために使用できる代表的ルーチンのステップを示すフローチャートである。
【図１６】 図１６は、招待者からの受け入れメッセージに応答するために議長が使用できる代表的ルーチンのステップを示すフローチャートである。
【図１７】 図１７は、新規メンバー追加デルタに応答するために既存のメンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１８】 図１８は、テレスペース情報を搬送する議長からのメッセージに応答するために新規追加メンバーが使用できる代表的ルーチンのステップを示すフローチャートである。
【図１９】 図１９は、再キーイング情報が「ピギーバック」したデルタ・メッセージの内容を示す略図である。
【図２０】 図２０は、本発明のセキュリティ・システムの好適な実装の全体的アーキテクチャを示す略ブロック図である。
【図２１】 図２１は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル抽象クラスを示す略ブロック図である。
【図２２】 図２２は、本発明のセキュリティ・システムのオブジェクト指向実装におけるサンプル具象クラスを示す略ブロック図である。
【図２３】 図２３は、視覚的確認のための情報を表示しその情報を受け入れるかまたは破棄するようにユーザに要求するダイアログ・ボックスの画面表示を示す略図である。
Claims (26)
- ローカル・データ・コピーを有する複数のコラボレータ装置が、デルタ・メッセージを交換するテレスペースを管理するための方法であって、各メッセージはヘッダと、前記ローカル・データ・コピーを更新するためのデータとを含み、
（ａ）前記テレスペースを作成するコラボレータ装置が、デルタ・メッセージの真正性と完全性と機密性を保護すべきかどうかを決定するセキュリティのレベルの選択を受信するステップと、
（ｂ）ステップ（ａ）で選択されたセキュリティのレベルがデルタ・メッセージの真正性及び完全性を保護する必要がある場合、デルタ・メッセージを送信するコラボレータ装置が、認証鍵及びメッセージに含まれる前記ヘッダと前記データとに基づいて、予め定められたＭＡＣアルゴリズムを使用して生成されるメッセージ認証コードを、前記メッセージ内に追加するステップと、
（ｃ）ステップ（ａ）で選択されたセキュリティのレベルがデルタ・メッセージの前記機密性を保護する必要がある場合、デルタ・メッセージを送信する前記コラボレータ装置が、前記認証鍵とは異なる暗号化鍵を用いて予め定められた暗号化アルゴリズムにより前記データを暗号化するステップと
を含み、
前記テレスペースは、前記複数のコラボレータ装置のうちの任意のコラボレータ装置からなるサブグループを有し、前記サブグループ内で送信するデルタ・メッセージに対して、サブグループ毎に個別の前記暗号化鍵および前記認証鍵を用いることを特徴とする方法。 - 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の暗号化鍵を用いることを特徴とする請求項１に記載の方法。
- 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の認証鍵を用いることを特徴とする請求項２に記載の方法。
- ステップ（ｂ）は、前記単一の認証鍵、及び一方向ハッシュ関数で前記ヘッダと前記データとをハッシュした結果を、前記ＭＡＣアルゴリズムに提供することを含むことを特徴とする請求項３に記載の方法。
- 各メッセージは、鍵バージョン番号をさらに含むことを特徴とする請求項４に記載の方法。
- 前記鍵バージョン番号は前記単一の認証鍵の鍵バージョンであることを特徴とする請求項５に記載の方法。
- 前記鍵バージョン番号はユニークな鍵識別子とインクリメンタル・シーケンス番号とを含むことを特徴とする請求項５に記載の方法。
- 前記テレスペースの前記複数のコラボレータ装置は、当該複数のコラボレータ装置のペア毎に個別の認証鍵を用いることを特徴とする請求項２に記載の方法。
- ステップ（ｂ）は、各個別の認証鍵、及び一方向ハッシュ関数で前記ヘッダと前記データとをハッシュした結果を、前記ＭＡＣアルゴリズムに提供してコラボレータ装置の各ペアについて別個の認証子を生成し、前記別個の認証子を連結して前記メッセージ認証コードを生成することを含むことを特徴とする請求項８に記載の方法。
- 各メッセージは、鍵バージョン番号をさらに含むことを特徴とする請求項８に記載の方法。
- 前記鍵バージョン番号は別々の認証鍵全部の鍵バージョンであることを特徴とする請求項１０に記載の方法。
- ローカル・データ・コピーを有する複数のコラボレータ装置が、デルタ・メッセージを交換するテレスペースを管理するための装置であって、各メッセージはヘッダと、前記ローカル・データ・コピーを更新するためのデータとを含み、
前記テレスペースを作成する際に、デルタ・メッセージの真正性と完全性と機密性を保護すべきかどうかを決定するセキュリティのレベルの選択を受信するメカニズムと、
前記セキュリティ・レベル選択受信メカニズムと協調動作して、デルタ・メッセージの送信前に、認証鍵及びメッセージに含まれる前記ヘッダと前記データとに基づいて、予め定められたＭＡＣアルゴリズムを使用して生成されるメッセージ認証コードを、前記メッセージ内に追加することにより、デルタ・メッセージの真正性及び完全性を保護するプロトコル・エンジンとを含み、
前記プロトコル・エンジンはデルタ・メッセージの送信前に、前記認証鍵とは異なる暗号化鍵を用いる予め定められた暗号化アルゴリズムにより前記データを暗号化することで、デルタ・メッセージの機密性を保護し、
前記テレスペースは、前記複数のコラボレータ装置のうちの任意のコラボレータ装置からなるサブグループを有し、前記サブグループ内で送信するデルタ・メッセージに対して、サブグループ毎に個別の前記暗号化鍵および前記認証鍵を用いることを特徴とする装置。 - 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の暗号化鍵を用いることを特徴とする請求項１２に記載の装置。
- 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の認証鍵を用いることを特徴とする請求項１３に記載の装置。
- 前記プロトコル・エンジンは、一方向ハッシュ関数で前記ヘッダと前記データとをハッシュする認証モジュールであって、前記単一の認証鍵、及び前記ハッシュした結果を前記ＭＡＣアルゴリズムに提供する認証モジュールを含むことを特徴とする請求項１４に記載の装置。
- 各メッセージは、鍵バージョン番号をさらに含むことを特徴とする請求項１５に記載の装置。
- 前記鍵バージョン番号は前記単一の認証鍵の鍵バージョンであることを特徴とする請求項１６に記載の装置。
- 前記鍵バージョン番号はユニークな鍵識別子とインクリメンタル・シーケンス番号とを含むことを特徴とする請求項１６に記載の装置。
- 前記テレスペースの前記複数のコラボレータ装置は、当該複数のコラボレータ装置のペア毎に個別の認証鍵を用いることを特徴とする請求項１３に記載の装置。
- 前記プロトコル・エンジンは、一方向ハッシュ関数で前記ヘッダと前記データとをハッシュする認証モジュールであって、各個別の認証鍵、及び前記ハッシュした結果を前記ＭＡＣアルゴリズムに提供してコラボレータ装置の各ペアについて別個の認証子を生成し、前記別個の認証子を連結して前記メッセージ認証コードを生成する認証モジュールを含むことを特徴とする請求項１９に記載の装置。
- 各メッセージは、鍵バージョン番号をさらに含むことを特徴とする請求項１９に記載の装置。
- 前記鍵バージョン番号は別々の認証鍵全部の鍵バージョンを連結したものであることを特徴とする請求項２１に記載の装置。
- ローカル・データ・コピーを有する複数のコラボレータ装置が、デルタ・メッセージを交換するテレスペースであって、各メッセージはヘッダと、前記ローカル・データ・コピーを更新するためのデータとを含む、テレスペースにおいて、コンピュータに、
前記テレスペースを作成する際に、デルタ・メッセージの真正性と完全性と機密性を保護すべきかどうかを決定するセキュリティのレベルの選択を受信するステップと、
選択されたセキュリティのレベルがデルタ・メッセージの真正性と完全性を保護する必要がある場合に、認証鍵及びメッセージに含まれる前記ヘッダと前記データとに基づいて、予め定められたＭＡＣアルゴリズムを使用して生成されるメッセージ認証コードを、前記メッセージ内に追加するステップと、
選択されたセキュリティのレベルがデルタ・メッセージの機密性を保護する必要がある場合に、前記認証鍵とは異なる暗号化鍵を用いる予め定められた暗号化アルゴリズムにより前記データを暗号化するステップと
を実行させるプログラムを記録し、
前記テレスペースは、前記複数のコラボレータ装置のうちの任意のコラボレータ装置からなるサブグループを有し、前記サブグループ内で送信するデルタ・メッセージに対して、サブグループ毎に個別の前記暗号化鍵および前記認証鍵を用いることを特徴とするコンピュータ読み取り可能な記録媒体。 - 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の暗号化鍵を用いることを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
- 前記テレスペースの前記複数のコラボレータ装置が、前記テレスペースの全てのコラボレータ装置に送信するデルタ・メッセージに対して、単一の認証鍵を用いることを特徴とする請求項２４に記載のコンピュータ読み取り可能な記録媒体。
- メッセージ認証コードを追加する前記ステップは、前記単一の認証鍵、及び一方向ハッシュ関数で前記ヘッダと前記データとをハッシュした結果を、前記ＭＡＣアルゴリズムに提供することを特徴とする請求項２５に記載のコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/571,851 | 2000-05-12 | ||
| US09/571,851 US6986046B1 (en) | 2000-05-12 | 2000-05-12 | Method and apparatus for managing secure collaborative transactions |
| PCT/US2001/014093 WO2001088674A2 (en) | 2000-05-12 | 2001-05-02 | Method and apparatus for managing secure collaborative transactions |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011181880A Division JP2012019534A (ja) | 2000-05-12 | 2011-08-23 | 安全なコラボレーティブ・トランザクションを管理する方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004501547A JP2004501547A (ja) | 2004-01-15 |
| JP4955181B2 true JP4955181B2 (ja) | 2012-06-20 |
Family
ID=24285327
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001585004A Expired - Fee Related JP4955181B2 (ja) | 2000-05-12 | 2001-05-02 | 安全なコラボレーティブ・トランザクションを管理する方法及び装置 |
| JP2011181880A Pending JP2012019534A (ja) | 2000-05-12 | 2011-08-23 | 安全なコラボレーティブ・トランザクションを管理する方法及び装置 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011181880A Pending JP2012019534A (ja) | 2000-05-12 | 2011-08-23 | 安全なコラボレーティブ・トランザクションを管理する方法及び装置 |
Country Status (10)
| Country | Link |
|---|---|
| US (4) | US6986046B1 (ja) |
| EP (4) | EP1698959A1 (ja) |
| JP (2) | JP4955181B2 (ja) |
| KR (1) | KR100905141B1 (ja) |
| AT (1) | ATE346333T1 (ja) |
| AU (1) | AU2001261117A1 (ja) |
| CA (1) | CA2408437C (ja) |
| DE (1) | DE60124765T2 (ja) |
| IL (2) | IL152351A0 (ja) |
| WO (1) | WO2001088674A2 (ja) |
Families Citing this family (177)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8086508B2 (en) | 2000-07-24 | 2011-12-27 | Cashedge, Inc. | Method and apparatus for delegating authority |
| US7536340B2 (en) | 2000-07-24 | 2009-05-19 | Cashedge, Inc. | Compliance monitoring method and apparatus |
| US7013310B2 (en) | 2002-01-03 | 2006-03-14 | Cashedge, Inc. | Method and apparatus for retrieving and processing data |
| US7797207B1 (en) | 2000-07-24 | 2010-09-14 | Cashedge, Inc. | Method and apparatus for analyzing financial data |
| US7146338B2 (en) | 2001-06-28 | 2006-12-05 | Checkfree Services Corporation | Inter-network financial service |
| US7383223B1 (en) | 2000-09-20 | 2008-06-03 | Cashedge, Inc. | Method and apparatus for managing multiple accounts |
| FR2823928B1 (fr) * | 2001-04-19 | 2003-08-22 | Canal Plus Technologies | Procede pour une communication securisee entre deux dispositifs |
| JP4604422B2 (ja) | 2001-07-31 | 2011-01-05 | ソニー株式会社 | 通信システム、通信装置及び通信方法 |
| US7203845B2 (en) * | 2002-01-11 | 2007-04-10 | Cashedge, Inc. | Multiple trust modes for handling data |
| US7627753B2 (en) * | 2002-03-19 | 2009-12-01 | Microsoft Corporation | Secure digital data format and code enforced policy |
| US7120797B2 (en) * | 2002-04-24 | 2006-10-10 | Microsoft Corporation | Methods for authenticating potential members invited to join a group |
| US20040006705A1 (en) * | 2002-07-05 | 2004-01-08 | Walker Jesse R. | Secure two-message synchronization in wireless networks |
| US7515569B2 (en) * | 2002-11-27 | 2009-04-07 | Agere Systems, Inc. | Access control for wireless systems |
| US7730446B2 (en) * | 2003-03-12 | 2010-06-01 | Microsoft Corporation | Software business process model |
| US7577934B2 (en) * | 2003-03-12 | 2009-08-18 | Microsoft Corporation | Framework for modeling and providing runtime behavior for business software applications |
| US7376834B2 (en) * | 2003-07-18 | 2008-05-20 | Palo Alto Research Center Incorporated | System and method for securely controlling communications |
| US7103779B2 (en) * | 2003-09-18 | 2006-09-05 | Apple Computer, Inc. | Method and apparatus for incremental code signing |
| US8190893B2 (en) | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
| US7302060B2 (en) * | 2003-11-10 | 2007-11-27 | Qualcomm Incorporated | Method and application for authentication of a wireless communication using an expiration marker |
| US8060743B2 (en) * | 2003-11-14 | 2011-11-15 | Certicom Corp. | Cryptographic method and apparatus |
| US7783769B2 (en) * | 2004-03-31 | 2010-08-24 | Intel Corporation | Accelerated TCP (Transport Control Protocol) stack processing |
| CN1950775B (zh) * | 2004-04-29 | 2011-03-16 | Nxp股份有限公司 | 用于程序执行期间的入侵检测的方法，设备和计算机系统 |
| US20060010205A1 (en) * | 2004-05-21 | 2006-01-12 | Bea Systems, Inc. | Systems and methods for collaboration impersonation |
| US20050262075A1 (en) | 2004-05-21 | 2005-11-24 | Bea Systems, Inc. | Systems and methods for collaboration shared state management |
| US20060010125A1 (en) * | 2004-05-21 | 2006-01-12 | Bea Systems, Inc. | Systems and methods for collaborative shared workspaces |
| JP2006018430A (ja) * | 2004-06-30 | 2006-01-19 | Ricoh Co Ltd | 情報処理装置、ネットワークシステム、プログラム、データ構造及び記憶媒体 |
| US7480803B1 (en) * | 2004-07-23 | 2009-01-20 | Sprint Communications Company L.P. | System and method for securing system content by automated device authentication |
| US7636841B2 (en) | 2004-07-26 | 2009-12-22 | Intercall, Inc. | Systems and methods for secure data exchange in a distributed collaborative application |
| US7840002B2 (en) * | 2004-07-29 | 2010-11-23 | Vadium Technology, Inc. | Techniques to strengthen one-time pad encryption |
| US8656161B2 (en) * | 2004-11-30 | 2014-02-18 | Nec Corporation | Information sharing system, information sharing method, group management program and compartment management program |
| JP4701706B2 (ja) * | 2004-12-22 | 2011-06-15 | 富士ゼロックス株式会社 | 情報処理装置、方法、及びプログラム |
| US7752253B2 (en) * | 2005-04-25 | 2010-07-06 | Microsoft Corporation | Collaborative invitation system and method |
| JP4900891B2 (ja) | 2005-04-27 | 2012-03-21 | キヤノン株式会社 | 通信装置及び通信方法 |
| US7890220B2 (en) * | 2005-05-03 | 2011-02-15 | Mks Instruments, Inc. | Low overhead closed loop control system |
| US7647508B2 (en) * | 2005-06-16 | 2010-01-12 | Intel Corporation | Methods and apparatus for providing integrity protection for management and control traffic of wireless communication networks |
| US20070076709A1 (en) * | 2005-07-01 | 2007-04-05 | Geoffrey Mattson | Apparatus and method for facilitating a virtual private local area network service with realm specific addresses |
| US20070086456A1 (en) * | 2005-08-12 | 2007-04-19 | Electronics And Telecommunications Research Institute | Integrated layer frame processing device including variable protocol header |
| US8306918B2 (en) | 2005-10-11 | 2012-11-06 | Apple Inc. | Use of media storage structure with multiple pieces of content in a content-distribution system |
| US20070101400A1 (en) * | 2005-10-31 | 2007-05-03 | Overcow Corporation | Method of providing secure access to computer resources |
| US20070157266A1 (en) * | 2005-12-23 | 2007-07-05 | United Video Properties, Inc. | Interactive media guidance system having multiple devices |
| US20070157281A1 (en) * | 2005-12-23 | 2007-07-05 | United Video Properties, Inc. | Interactive media guidance system having multiple devices |
| US8364965B2 (en) * | 2006-03-15 | 2013-01-29 | Apple Inc. | Optimized integrity verification procedures |
| WO2007108660A1 (en) * | 2006-03-22 | 2007-09-27 | Lg Electronics Inc. | Asymmetric cryptography for wireless systems |
| US8224751B2 (en) | 2006-05-03 | 2012-07-17 | Apple Inc. | Device-independent management of cryptographic information |
| US7945053B2 (en) * | 2006-05-15 | 2011-05-17 | Intel Corporation | Methods and apparatus for a keying mechanism for end-to-end service control protection |
| US7940926B2 (en) * | 2006-06-08 | 2011-05-10 | Novell, Inc. | Cooperative encoding of data by pluralities of parties |
| US7668954B1 (en) | 2006-06-27 | 2010-02-23 | Stephen Waller Melvin | Unique identifier validation |
| US8301753B1 (en) | 2006-06-27 | 2012-10-30 | Nosadia Pass Nv, Limited Liability Company | Endpoint activity logging |
| GB0612775D0 (en) * | 2006-06-28 | 2006-08-09 | Ibm | An apparatus for securing a communications exchange between computers |
| US20080005558A1 (en) * | 2006-06-29 | 2008-01-03 | Battelle Memorial Institute | Methods and apparatuses for authentication and validation of computer-processable communications |
| US8127135B2 (en) * | 2006-09-28 | 2012-02-28 | Hewlett-Packard Development Company, L.P. | Changing of shared encryption key |
| JP4886463B2 (ja) | 2006-10-20 | 2012-02-29 | キヤノン株式会社 | 通信パラメータ設定方法、通信装置及び通信パラメータを管理する管理装置 |
| KR101365603B1 (ko) * | 2006-12-04 | 2014-02-20 | 삼성전자주식회사 | 조건부 인증 코드 삽입 방법 및 그 장치, 인증을 통한조건부 데이터 사용 방법 및 그 장치 |
| US10416838B2 (en) * | 2006-12-11 | 2019-09-17 | Oath Inc. | Graphical messages |
| US8060887B2 (en) * | 2007-03-30 | 2011-11-15 | Uranus International Limited | Method, apparatus, system, and medium for supporting multiple-party communications |
| US7765266B2 (en) * | 2007-03-30 | 2010-07-27 | Uranus International Limited | Method, apparatus, system, medium, and signals for publishing content created during a communication |
| US8627211B2 (en) * | 2007-03-30 | 2014-01-07 | Uranus International Limited | Method, apparatus, system, medium, and signals for supporting pointer display in a multiple-party communication |
| WO2008119149A1 (en) * | 2007-03-30 | 2008-10-09 | Uranus International Limited | Method, apparatus, system, and medium for supporting multiple-party communications |
| US7950046B2 (en) * | 2007-03-30 | 2011-05-24 | Uranus International Limited | Method, apparatus, system, medium, and signals for intercepting a multiple-party communication |
| US8702505B2 (en) | 2007-03-30 | 2014-04-22 | Uranus International Limited | Method, apparatus, system, medium, and signals for supporting game piece movement in a multiple-party communication |
| US7765261B2 (en) * | 2007-03-30 | 2010-07-27 | Uranus International Limited | Method, apparatus, system, medium and signals for supporting a multiple-party communication on a plurality of computer servers |
| US8705348B2 (en) * | 2007-04-18 | 2014-04-22 | Cisco Technology, Inc. | Use of metadata for time based anti-replay |
| EP1986151A1 (en) * | 2007-04-23 | 2008-10-29 | Hewlett-Packard Development Company, L.P. | A data processing system, method and computer program product for providing a service to a service requester |
| US20080288400A1 (en) | 2007-04-27 | 2008-11-20 | Cashedge, Inc. | Centralized Payment Method and System for Online and Offline Transactions |
| US8347098B2 (en) * | 2007-05-22 | 2013-01-01 | Apple Inc. | Media storage structures for storing content, devices for using such structures, systems for distributing such structures |
| US9311492B2 (en) | 2007-05-22 | 2016-04-12 | Apple Inc. | Media storage structures for storing content, devices for using such structures, systems for distributing such structures |
| WO2009018483A1 (en) * | 2007-07-31 | 2009-02-05 | Viasat, Inc. | Input output access controller |
| TWI378702B (en) * | 2007-08-24 | 2012-12-01 | Ind Tech Res Inst | Group authentication method |
| WO2009033248A1 (en) * | 2007-09-10 | 2009-03-19 | Novell, Inc. | A method for efficient thread usage for hierarchically structured tasks |
| KR100959074B1 (ko) * | 2007-12-12 | 2010-05-20 | 한국전자통신연구원 | Ｐ２ｐ 네트워크 상에서의 보안 그룹 생성 방법, 생성장치, 인증 방법, 인증 장치 |
| US9043603B2 (en) * | 2008-01-28 | 2015-05-26 | Seagate Technology Llc | Security threshold enforcement in anchor point-based digital rights management |
| US8533474B2 (en) * | 2008-02-27 | 2013-09-10 | Red Hat, Inc. | Generating session keys |
| US8688975B2 (en) * | 2008-03-25 | 2014-04-01 | International Business Machines Corporation | Certifying a virtual entity in a virtual universe |
| CN101547443B (zh) * | 2008-03-28 | 2011-12-21 | 上海华为技术有限公司 | 信令的传输方法及通信装置 |
| WO2009132668A1 (en) * | 2008-04-30 | 2009-11-05 | Nec Europe, Ltd. | Method and system for verifying the identity of a communication partner |
| WO2009145587A2 (en) | 2008-05-29 | 2009-12-03 | Lg Electronics Inc. | Method of encrypting control signaling |
| CN101321209B (zh) * | 2008-06-19 | 2011-11-16 | 上海软中信息技术有限公司 | 基于pstn的安全通信分布式数据提取方法及实现系统 |
| US8230217B2 (en) * | 2008-10-13 | 2012-07-24 | International Business Machines Corporation | Method and system for secure collaboration using slepian-wolf codes |
| US7899056B2 (en) * | 2009-01-13 | 2011-03-01 | Fujitsu Limited | Device and method for reducing overhead in a wireless network |
| US8023513B2 (en) * | 2009-02-24 | 2011-09-20 | Fujitsu Limited | System and method for reducing overhead in a wireless network |
| US8812854B2 (en) * | 2009-10-13 | 2014-08-19 | Google Inc. | Firmware verified boot |
| US8806190B1 (en) | 2010-04-19 | 2014-08-12 | Amaani Munshi | Method of transmission of encrypted documents from an email application |
| CN102484791A (zh) * | 2010-05-19 | 2012-05-30 | 三洋电机株式会社 | 基站装置 |
| WO2012003504A2 (en) * | 2010-07-02 | 2012-01-05 | Air Computing, Inc. | A system and method for cloud file management |
| WO2012099617A1 (en) | 2011-01-20 | 2012-07-26 | Box.Net, Inc. | Real time notification of activities that occur in a web-based collaboration environment |
| US8751777B2 (en) | 2011-01-28 | 2014-06-10 | Honeywell International Inc. | Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system |
| US8990770B2 (en) | 2011-05-25 | 2015-03-24 | Honeywell International Inc. | Systems and methods to configure condition based health maintenance systems |
| US20120303310A1 (en) * | 2011-05-26 | 2012-11-29 | First Data Corporation | Systems and Methods for Providing Test Keys to Mobile Devices |
| WO2013009337A2 (en) | 2011-07-08 | 2013-01-17 | Arnold Goldberg | Desktop application for access and interaction with workspaces in a cloud-based content management system and synchronization mechanisms thereof |
| US8856530B2 (en) | 2011-09-21 | 2014-10-07 | Onyx Privacy, Inc. | Data storage incorporating cryptographically enhanced data protection |
| US20130080768A1 (en) * | 2011-09-26 | 2013-03-28 | Erik Lagerway | Systems and methods for secure communications using an open peer protocol |
| DE112012004308B4 (de) * | 2011-10-12 | 2020-08-27 | International Business Machines Corporation | Verfahren, System, Vermittlungsserver, Client und Computerprogramm zum Löschen von Daten zum Aufrechterhalten einer Sicherungsstufe |
| US8726084B2 (en) | 2011-10-14 | 2014-05-13 | Honeywell International Inc. | Methods and systems for distributed diagnostic reasoning |
| US9098474B2 (en) | 2011-10-26 | 2015-08-04 | Box, Inc. | Preview pre-generation based on heuristics and algorithmic prediction/assessment of predicted user behavior for enhancement of user experience |
| WO2013062599A1 (en) | 2011-10-26 | 2013-05-02 | Box, Inc. | Enhanced multimedia content preview rendering in a cloud content management system |
| US9773051B2 (en) | 2011-11-29 | 2017-09-26 | Box, Inc. | Mobile platform file and folder selection functionalities for offline access and synchronization |
| US9904435B2 (en) | 2012-01-06 | 2018-02-27 | Box, Inc. | System and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment |
| US20130191629A1 (en) * | 2012-01-19 | 2013-07-25 | Laconic Security, Llc | Secure group-based data storage in the cloud |
| US11232481B2 (en) | 2012-01-30 | 2022-01-25 | Box, Inc. | Extended applications of multimedia content previews in the cloud-based content management system |
| US9965745B2 (en) | 2012-02-24 | 2018-05-08 | Box, Inc. | System and method for promoting enterprise adoption of a web-based collaboration environment |
| US9575981B2 (en) | 2012-04-11 | 2017-02-21 | Box, Inc. | Cloud service enabled to handle a set of files depicted to a user as a single file in a native operating system |
| US9413587B2 (en) | 2012-05-02 | 2016-08-09 | Box, Inc. | System and method for a third-party application to access content within a cloud-based platform |
| WO2013166520A1 (en) | 2012-05-04 | 2013-11-07 | Box, Inc. | Repository redundancy implementation of a system which incrementally updates clients with events that occurred via cloud-enabled platform |
| CN102708192B (zh) * | 2012-05-15 | 2017-11-28 | 华为技术有限公司 | 一种文档共享的方法及系统、设备 |
| US9691051B2 (en) | 2012-05-21 | 2017-06-27 | Box, Inc. | Security enhancement through application access control |
| US8832649B2 (en) * | 2012-05-22 | 2014-09-09 | Honeywell International Inc. | Systems and methods for augmenting the functionality of a monitoring node without recompiling |
| US8914900B2 (en) | 2012-05-23 | 2014-12-16 | Box, Inc. | Methods, architectures and security mechanisms for a third-party application to access content in a cloud-based platform |
| US9712510B2 (en) | 2012-07-06 | 2017-07-18 | Box, Inc. | Systems and methods for securely submitting comments among users via external messaging applications in a cloud-based platform |
| GB2505072A (en) | 2012-07-06 | 2014-02-19 | Box Inc | Identifying users and collaborators as search results in a cloud-based system |
| US9081953B2 (en) | 2012-07-17 | 2015-07-14 | Oracle International Corporation | Defense against search engine tracking |
| US9166958B2 (en) * | 2012-07-17 | 2015-10-20 | Texas Instruments Incorporated | ID-based control unit-key fob pairing |
| US9794256B2 (en) | 2012-07-30 | 2017-10-17 | Box, Inc. | System and method for advanced control tools for administrators in a cloud-based service |
| US8832716B2 (en) | 2012-08-10 | 2014-09-09 | Honeywell International Inc. | Systems and methods for limiting user customization of task workflow in a condition based health maintenance system |
| US9558202B2 (en) | 2012-08-27 | 2017-01-31 | Box, Inc. | Server side techniques for reducing database workload in implementing selective subfolder synchronization in a cloud-based environment |
| US9135462B2 (en) | 2012-08-29 | 2015-09-15 | Box, Inc. | Upload and download streaming encryption to/from a cloud-based platform |
| US9195519B2 (en) | 2012-09-06 | 2015-11-24 | Box, Inc. | Disabling the self-referential appearance of a mobile application in an intent via a background registration |
| US9117087B2 (en) | 2012-09-06 | 2015-08-25 | Box, Inc. | System and method for creating a secure channel for inter-application communication based on intents |
| US9292833B2 (en) | 2012-09-14 | 2016-03-22 | Box, Inc. | Batching notifications of activities that occur in a web-based collaboration environment |
| US10915492B2 (en) | 2012-09-19 | 2021-02-09 | Box, Inc. | Cloud-based platform enabled with media content indexed for text-based searches and/or metadata extraction |
| US9037920B2 (en) | 2012-09-28 | 2015-05-19 | Honeywell International Inc. | Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system |
| US9959420B2 (en) | 2012-10-02 | 2018-05-01 | Box, Inc. | System and method for enhanced security and management mechanisms for enterprise administrators in a cloud-based environment |
| US9495364B2 (en) | 2012-10-04 | 2016-11-15 | Box, Inc. | Enhanced quick search features, low-barrier commenting/interactive features in a collaboration platform |
| US9665349B2 (en) | 2012-10-05 | 2017-05-30 | Box, Inc. | System and method for generating embeddable widgets which enable access to a cloud-based collaboration platform |
| KR101659113B1 (ko) * | 2012-10-09 | 2016-09-23 | 엘에스산전 주식회사 | 전력시스템을 위한 클라우드 서비스 제공 시스템 |
| US10235383B2 (en) | 2012-12-19 | 2019-03-19 | Box, Inc. | Method and apparatus for synchronization of items with read-only permissions in a cloud-based environment |
| CN103067156B (zh) * | 2012-12-28 | 2016-01-20 | 北京移数通电讯有限公司 | 移动互联网用户资源访问的url加密、验证方法和装置 |
| US20140188728A1 (en) | 2012-12-31 | 2014-07-03 | Fiserv, Inc. | Systems and methods for performing financial transactions |
| US9396245B2 (en) | 2013-01-02 | 2016-07-19 | Box, Inc. | Race condition handling in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
| US9953036B2 (en) | 2013-01-09 | 2018-04-24 | Box, Inc. | File system monitoring in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
| EP2755151A3 (en) | 2013-01-11 | 2014-09-24 | Box, Inc. | Functionalities, features and user interface of a synchronization client to a cloud-based environment |
| US10599671B2 (en) | 2013-01-17 | 2020-03-24 | Box, Inc. | Conflict resolution, retry condition management, and handling of problem files for the synchronization client to a cloud-based platform |
| US10846074B2 (en) | 2013-05-10 | 2020-11-24 | Box, Inc. | Identification and handling of items to be ignored for synchronization with a cloud-based platform by a synchronization client |
| US10725968B2 (en) | 2013-05-10 | 2020-07-28 | Box, Inc. | Top down delete or unsynchronization on delete of and depiction of item synchronization with a synchronization client to a cloud-based platform |
| US9633037B2 (en) | 2013-06-13 | 2017-04-25 | Box, Inc | Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform |
| US9805050B2 (en) | 2013-06-21 | 2017-10-31 | Box, Inc. | Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform |
| US9467283B2 (en) | 2013-06-24 | 2016-10-11 | Blackberry Limited | Securing method for lawful interception |
| US9535924B2 (en) | 2013-07-30 | 2017-01-03 | Box, Inc. | Scalability improvement in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
| US9584313B2 (en) * | 2013-08-09 | 2017-02-28 | Introspective Power, Inc. | Streaming one time pad cipher using rotating ports for data encryption |
| US9584488B2 (en) | 2013-08-09 | 2017-02-28 | Introspective Power, Inc. | Data encryption cipher using rotating ports |
| US10509527B2 (en) | 2013-09-13 | 2019-12-17 | Box, Inc. | Systems and methods for configuring event-based automation in cloud-based collaboration platforms |
| US9535909B2 (en) | 2013-09-13 | 2017-01-03 | Box, Inc. | Configurable event-based automation architecture for cloud-based collaboration platforms |
| KR101524743B1 (ko) * | 2013-11-15 | 2015-06-24 | 주식회사 날리지큐브 | 버츄얼 클러스터 |
| GB2512748B (en) | 2014-02-25 | 2015-02-18 | Cambridge Silicon Radio Ltd | Auto-configuration of a mesh relay's TX/RX schedule |
| GB2515853B (en) | 2014-02-25 | 2015-08-19 | Cambridge Silicon Radio Ltd | Latency mitigation |
| US9735967B2 (en) | 2014-04-30 | 2017-08-15 | International Business Machines Corporation | Self-validating request message structure and operation |
| DK3127300T3 (da) * | 2014-05-12 | 2019-10-07 | Google Llc | Håndtering af nic-krypterede flows til at migrere gæster eller opgaver |
| US10530854B2 (en) | 2014-05-30 | 2020-01-07 | Box, Inc. | Synchronization of permissioned content in cloud-based environments |
| US10038731B2 (en) | 2014-08-29 | 2018-07-31 | Box, Inc. | Managing flow-based interactions with cloud-based shared content |
| US9894119B2 (en) | 2014-08-29 | 2018-02-13 | Box, Inc. | Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms |
| US9942211B1 (en) * | 2014-12-11 | 2018-04-10 | Amazon Technologies, Inc. | Efficient use of keystreams |
| US10185946B2 (en) | 2014-12-31 | 2019-01-22 | Fiserv, Inc. | Facilitating presentation of content relating to a financial transaction |
| EP3248360B1 (en) | 2015-01-19 | 2020-05-06 | Inauth, Inc. | Systems and methods for trusted path secure communication |
| RU2017132104A (ru) * | 2015-02-16 | 2019-03-18 | Нек Корпорейшн | Система связи, устройство узла, терминал связи, способ управления ключами и энергонезависимый читаемый компьютером носитель, на котором хранится программа |
| US9509709B2 (en) * | 2015-03-19 | 2016-11-29 | International Business Machines Corporation | Mechanism to augment IPS/SIEM evidence information with process history snapshot and application window capture history |
| US10104047B2 (en) * | 2015-04-08 | 2018-10-16 | Microsemi Solutions (U.S.), Inc. | Method and system for encrypting/decrypting payload content of an OTN frame |
| US9432340B1 (en) * | 2015-05-07 | 2016-08-30 | Bogart Associates | System and method for secure end-to-end chat system |
| US10360287B2 (en) | 2015-05-22 | 2019-07-23 | Microsoft Technology Licensing, Llc | Unified messaging platform and interface for providing user callouts |
| US20160344677A1 (en) | 2015-05-22 | 2016-11-24 | Microsoft Technology Licensing, Llc | Unified messaging platform for providing interactive semantic objects |
| WO2017091672A1 (en) | 2015-11-25 | 2017-06-01 | InAuth, Inc. | Systems and methods for cross-channel device binding |
| US10009328B2 (en) * | 2015-12-07 | 2018-06-26 | Mcafee, Llc | System, apparatus and method for providing privacy preserving interaction with a computing system |
| US9590956B1 (en) * | 2015-12-18 | 2017-03-07 | Wickr Inc. | Decentralized authoritative messaging |
| US10334062B2 (en) | 2016-02-25 | 2019-06-25 | InAuth, Inc. | Systems and methods for recognizing a device |
| US9596079B1 (en) | 2016-04-14 | 2017-03-14 | Wickr Inc. | Secure telecommunications |
| US20180012190A1 (en) * | 2016-07-06 | 2018-01-11 | International Business Machines Corporation | Automatic inference of meeting attendance |
| FR3054905B1 (fr) * | 2016-08-04 | 2019-10-18 | Safran Identity & Security | Procede de generation de cle et procede de controle d'acces |
| US11093852B2 (en) | 2016-10-19 | 2021-08-17 | Accertify, Inc. | Systems and methods for recognizing a device and/or an instance of an app invoked on a device |
| US11403563B2 (en) | 2016-10-19 | 2022-08-02 | Accertify, Inc. | Systems and methods for facilitating recognition of a device and/or an instance of an app invoked on a device |
| US10541814B2 (en) | 2017-11-08 | 2020-01-21 | Wickr Inc. | End-to-end encryption during a secure communication session |
| US10855440B1 (en) | 2017-11-08 | 2020-12-01 | Wickr Inc. | Generating new encryption keys during a secure communication session |
| US11101999B2 (en) | 2017-11-08 | 2021-08-24 | Amazon Technologies, Inc. | Two-way handshake for key establishment for secure communications |
| US10778432B2 (en) | 2017-11-08 | 2020-09-15 | Wickr Inc. | End-to-end encryption during a secure communication session |
| US11310078B2 (en) * | 2018-01-11 | 2022-04-19 | Wesley Rogers | Cipher stream based secure packet communications with key stream transmission over diverse paths |
| US10754972B2 (en) | 2018-01-30 | 2020-08-25 | Salesforce.Com, Inc. | Multi-factor administrator action verification system |
| US11615208B2 (en) * | 2018-07-06 | 2023-03-28 | Capital One Services, Llc | Systems and methods for synthetic data generation |
| US11222311B2 (en) * | 2018-12-18 | 2022-01-11 | The Toronto-Dominion Bank | System and method for secure data transfer |
| JP2022184560A (ja) * | 2021-06-01 | 2022-12-13 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及び情報処理プログラム |
| US11804970B2 (en) * | 2021-10-15 | 2023-10-31 | Lenovo Global Technology (United States) Inc. | Baseboard management controller group administration |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07235921A (ja) * | 1994-02-23 | 1995-09-05 | Nippon Telegr & Teleph Corp <Ntt> | 情報通信のセキュリティ管理方法及び装置 |
| GB9502182D0 (en) * | 1995-02-03 | 1995-03-22 | Plessey Telecomm | Telecommunications service interactions |
| JP3982848B2 (ja) * | 1995-10-19 | 2007-09-26 | 富士通株式会社 | セキュリティレベル制御装置及びネットワーク通信システム |
| US5787175A (en) | 1995-10-23 | 1998-07-28 | Novell, Inc. | Method and apparatus for collaborative document control |
| FR2743235B1 (fr) * | 1995-12-27 | 1998-01-23 | Alsthom Cge Alcatel | Methode pour securiser les collaborations entre objets d'un programme oriente objet |
| JP3562134B2 (ja) * | 1996-04-19 | 2004-09-08 | 富士ゼロックス株式会社 | 協調設計支援システム及び方法 |
| JPH09319673A (ja) * | 1996-05-27 | 1997-12-12 | Matsushita Electric Works Ltd | 暗号鍵更新方法およびそのシステム |
| DE19622630C1 (de) * | 1996-06-05 | 1997-11-20 | Siemens Ag | Verfahren zum gruppenbasierten kryptographischen Schlüsselmanagement zwischen einer ersten Computereinheit und Gruppencomputereinheiten |
| US6453327B1 (en) * | 1996-06-10 | 2002-09-17 | Sun Microsystems, Inc. | Method and apparatus for identifying and discarding junk electronic mail |
| US6272639B1 (en) * | 1996-07-30 | 2001-08-07 | Micron Technology, Inc. | Mixed enclave operation in a computer network |
| JPH10111825A (ja) * | 1996-10-04 | 1998-04-28 | Kokusai Denshin Denwa Co Ltd <Kdd> | 複数データベース一致化更新方法および装置 |
| JP3512311B2 (ja) * | 1997-03-27 | 2004-03-29 | 日立ソフトウエアエンジニアリング株式会社 | 情報リンク管理方法および情報提供システム |
| JPH1115373A (ja) * | 1997-06-20 | 1999-01-22 | Fuji Xerox Co Ltd | 公開鍵暗号方式 |
| US6775382B1 (en) | 1997-06-30 | 2004-08-10 | Sun Microsystems, Inc. | Method and apparatus for recovering encryption session keys |
| JPH11150554A (ja) * | 1997-11-14 | 1999-06-02 | Casio Comput Co Ltd | データ通信装置、データ通信方法及び記憶媒体 |
| US6049878A (en) * | 1998-01-20 | 2000-04-11 | Sun Microsystems, Inc. | Efficient, secure multicasting with global knowledge |
| US6195751B1 (en) | 1998-01-20 | 2001-02-27 | Sun Microsystems, Inc. | Efficient, secure multicasting with minimal knowledge |
| US6334146B1 (en) * | 1998-06-05 | 2001-12-25 | I2 Technologies Us, Inc. | System and method for remotely accessing data |
| US6295361B1 (en) * | 1998-06-30 | 2001-09-25 | Sun Microsystems, Inc. | Method and apparatus for multicast indication of group key change |
| JP2000066941A (ja) * | 1998-08-25 | 2000-03-03 | Nec Corp | 分散ファイル更新方法及びそのシステム |
| US6584566B1 (en) * | 1998-08-27 | 2003-06-24 | Nortel Networks Limited | Distributed group key management for multicast security |
| US6606706B1 (en) * | 1999-02-08 | 2003-08-12 | Nortel Networks Limited | Hierarchical multicast traffic security system in an internetwork |
| US6542993B1 (en) * | 1999-03-12 | 2003-04-01 | Lucent Technologies Inc. | Security management system and method |
| US6961855B1 (en) * | 1999-12-16 | 2005-11-01 | International Business Machines Corporation | Notification of modifications to a trusted computing base |
-
2000
- 2000-05-12 US US09/571,851 patent/US6986046B1/en not_active Expired - Fee Related
-
2001
- 2001-05-02 AU AU2001261117A patent/AU2001261117A1/en not_active Abandoned
- 2001-05-02 JP JP2001585004A patent/JP4955181B2/ja not_active Expired - Fee Related
- 2001-05-02 CA CA2408437A patent/CA2408437C/en not_active Expired - Fee Related
- 2001-05-02 DE DE60124765T patent/DE60124765T2/de not_active Expired - Lifetime
- 2001-05-02 IL IL15235101A patent/IL152351A0/xx unknown
- 2001-05-02 EP EP06011338A patent/EP1698959A1/en not_active Ceased
- 2001-05-02 WO PCT/US2001/014093 patent/WO2001088674A2/en active IP Right Grant
- 2001-05-02 KR KR1020027015206A patent/KR100905141B1/ko not_active IP Right Cessation
- 2001-05-02 AT AT01934977T patent/ATE346333T1/de not_active IP Right Cessation
- 2001-05-02 EP EP01934977A patent/EP1348152B1/en not_active Expired - Lifetime
- 2001-05-02 EP EP06013436A patent/EP1708406A3/en not_active Ceased
- 2001-05-02 EP EP06013559A patent/EP1705599A3/en not_active Ceased
-
2002
- 2002-10-17 IL IL152351A patent/IL152351A/en not_active IP Right Cessation
-
2005
- 2005-10-24 US US11/257,479 patent/US7415606B2/en not_active Expired - Fee Related
- 2005-10-24 US US11/257,358 patent/US7213147B2/en not_active Expired - Fee Related
- 2005-10-24 US US11/257,239 patent/US7171001B2/en not_active Expired - Fee Related
-
2011
- 2011-08-23 JP JP2011181880A patent/JP2012019534A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP1698959A1 (en) | 2006-09-06 |
| JP2004501547A (ja) | 2004-01-15 |
| KR20030010620A (ko) | 2003-02-05 |
| IL152351A0 (en) | 2003-05-29 |
| EP1348152A2 (en) | 2003-10-01 |
| EP1708406A2 (en) | 2006-10-04 |
| EP1705599A3 (en) | 2006-11-22 |
| US20060041752A1 (en) | 2006-02-23 |
| DE60124765D1 (de) | 2007-01-04 |
| KR100905141B1 (ko) | 2009-06-29 |
| US7415606B2 (en) | 2008-08-19 |
| CA2408437C (en) | 2010-11-30 |
| US7171001B2 (en) | 2007-01-30 |
| US7213147B2 (en) | 2007-05-01 |
| AU2001261117A1 (en) | 2001-11-26 |
| EP1708406A3 (en) | 2006-11-22 |
| WO2001088674A3 (en) | 2003-07-24 |
| EP1705599A2 (en) | 2006-09-27 |
| US20060036862A1 (en) | 2006-02-16 |
| IL152351A (en) | 2009-08-03 |
| US20060050869A1 (en) | 2006-03-09 |
| US6986046B1 (en) | 2006-01-10 |
| CA2408437A1 (en) | 2001-11-22 |
| ATE346333T1 (de) | 2006-12-15 |
| DE60124765T2 (de) | 2008-02-14 |
| WO2001088674A2 (en) | 2001-11-22 |
| EP1348152B1 (en) | 2006-11-22 |
| JP2012019534A (ja) | 2012-01-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4955181B2 (ja) | 安全なコラボレーティブ・トランザクションを管理する方法及び装置 | |
| Kohl et al. | The evolution of the Kerberos authentication service | |
| US7620824B2 (en) | Data communicating apparatus, data communicating method, and program | |
| US7395549B1 (en) | Method and apparatus for providing a key distribution center without storing long-term server secrets | |
| US7120797B2 (en) | Methods for authenticating potential members invited to join a group | |
| US7089211B1 (en) | Directory enabled secure multicast group communications | |
| US20030081774A1 (en) | Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure | |
| GB2357229A (en) | Security protocol with messages formatted according to a self describing markup language | |
| WO2002054665A1 (en) | Trusted intermediary | |
| Elgohary et al. | Design of an enhancement for SSL/TLS protocols | |
| El-Ema et al. | A network authentication protocol based on Kerberos | |
| Åslund | Authentication in peer-to-peer systems | |
| Cengiz | A practical key agreement scheme for videoconferencing | |
| Buchberger | Adopting the Noise key exchange in Tox | |
| Li | Secure group communication protocol and implementation for JetMeeting, an application based on P2P | |
| Cui et al. | Approaching secure communications in a message-oriented mobile computing environment | |
| Rodeh | Secure Group Communication | |
| Finin et al. | A Security Architecture for Agent Communication Language | |
| Lee et al. | Design of a system to support security communication between a Web proxy and a CGI program based on PKI | |
| Power et al. | Authentication in a heterogeneous environment | |
| CN117675383A (zh) | 针对网络化协同设计的数据传输架构及数据传输方法 | |
| Sriramulu et al. | A Secure Network Communication Based on Kerberos & MD5 | |
| Raghunathan | A security model for mobile agent environments using X. 509 proxy certificates | |
| Bai et al. | Access revocation and prevention of false repudiation in secure email exchanges | |
| Schmidt | A framework for peer-to-peer applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080304 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20100218 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20100219 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110527 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110823 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120309 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120315 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150323 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees | ||
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |