(57)【要約】      （修正有）【課題】ピアツーピア型コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための方法及び装置を提供する。【解決手段】ピアツーピア型コラボレーション・システムにおいて、データ変更コマンドを含むデルタはデルタ・ログと呼ばれる永続的データ構造に構成される。デルタ・ログはブロックに構成され、ブロック内でデルタはグループに構成され、その各々はチェーンに構成されるデルタのセットである。デルタ・ログを「歩き回って（ｗａｌｋ）」収束の問題を検出できる。前後関係の保存を実現するため、各デルタは現在のデルタを実行する前に実行しなければならない他のデルタを表わす依存リストを有する。ダイナミクス・マネージャはコマンドを実行し取り消すことのできる能力を使ってデルタに対してロールバック及びロールフォワード操作を実行し収束を実現する。【選択図】図４
2004152289.tif 000002
【特許請求の範囲】
【請求項１】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための装置であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする装置であって、該装置が、
各エンドポイントにあってデルタとその内容を格納する永続的デルタ・ログ・データ構造と、
各エンドポイントにおけるメカニズムであって、前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを前記デルタ・ログに挿入して、一つのエンドポイントから受信した各デルタが生成及び受信の順序でチェーン内に保持されるようにするメカニズムと、
各エンドポイントにおけるメカニズムであって、デルタ内の前記データ変更コマンドを実行し、全エンドポイントでの前記データ変更コマンドの収束を実現するために、前記デルタ・ログの内容を用いてデータ変更コマンドを選択的に取り消しまたやり直すメカニズムと
を含むことを特徴とする装置。
【請求項２】
前記各エンドポイントで生成され、かつ、他のエンドポイントから受信したデルタはそのデルタを生成した前記エンドポイントとシーケンス番号によって決定されるポイントでデルタ・ログへ挿入されることを特徴とする請求項１に記載の装置。
【請求項３】
デルタ・ログの各チェーンはエンドポイントから受信されシーケンス番号により順序付けられたデルタで構成されることを特徴とする請求項１に記載の装置。
【請求項４】
デルタ・ログ内の各チェーンは予め定められた最大長を有することを特徴とする請求項１に記載の装置。
【請求項５】
前記デルタ・ログ内のチェーンはグループに構成され、各グループ内でチェーンは作成者ＩＤの昇順に構成され、前記作成者ＩＤはエンドポイントのエンドポイントＩＤとそのエンドポイントが前記共有空間をオープンする度に生成される乱数の組み合わせであることを特徴とする請求項１に記載の装置。
【請求項６】
前記共有空間内のエンドポイント間で送信されるエンドポイント・パルスを生成するメカニズムを更に含み、各エンドポイント・パルスはエンドポイントにより生成されそのエンドポイントが消去を希望するデルタ・グループを識別する情報を含むことを特徴とする請求項１に記載の装置。
【請求項７】
各エンドポイントにある手段であって、他のエンドポイントで生成されたエンドポイント・パルスを受信し、全エンドポイントが消去を希望するデルタグループを決定するために、前記エンドポイント・パルスの情報を比較して選択したグループ内のデルタを消去する手段を更に含むことを特徴とする請求項６に記載の装置。
【請求項８】
各エンドポイントにあるメカニズムであって、デルタ内の前記データ変更コマンドを実行する前記メカニズムは、選択されたデルタのデータ変更コマンドをやり直すために、デルタ・ログ内の前記チェーンを使って順次デルタを調べるメカニズムを含むこと特徴とする請求項１に記載の装置。
【請求項９】
各エンドポイントにあるメカニズムであって、デルタ内の前記データ変更コマンドを実行する前記メカニズムは、すでに取り消されたデータ変更コマンドをやり直すために、デルタ・ログ内の前記チェーンを使って順次デルタを調べるメカニズムを含むことを特徴とする請求項８に記載の装置。
【請求項１０】
各デルタは前記各デルタが実行できるようになる前に実行されるべき他のデルタを表わす依存性のリストを有することを特徴とする請求項１に記載の装置。
【請求項１１】
各エンドポイントにあるメカニズムであって、デルタ内の前記データ変更コマンドを実行する前記メカニズムは、そのデルタに含まれるデータ変更コマンドを取り消すために、デルタ内に含まれる取り消し情報を使う手段を含むことを特徴とする請求項１０に記載の装置。
【請求項１２】
前記デルタのデータ変更コマンドを実行するのと同時にデルタ内に取り消し情報を挿入するデータ変更エンジンを更に含むことを特徴とする請求項１１に記載の装置。
【請求項１３】
各エンドポイントにあるメカニズムであって、前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを前記デルタ・ログに挿入する前記メカニズムは各デルタに割り当てられた優先順位に基づいて前記デルタのチェーンをブロックに挿入し、各ブロックが最高優先順位のデルタを一つ含み、前記最高優先順位のデルタが依存する全部のデルタは前記各ブロックの前に作成されたブロックに配置され、前記最高優先順位デルタに依存しない全デルタは前記各ブロックに配置され、前記最高優先順位デルタに依存する全デルタは前記各ブロックと前記各ブロックの後に作成されたブロックに配置されることを特徴とする請求項１０に記載の装置。
【請求項１４】
非同期デルタを作成するメカニズムを更に含み、他のデルタは前記非同期デルタに依存しないことを特徴とする請求項１０に記載の装置。
【請求項１５】
エンドポイントにあるメカニズムであって、依存性リストにあるがそのエンドポイントの前記デルタ・ログにはないデルタを他のエンドポイントからフェッチするメカニズムを更に含むことを特徴とする請求項１０に記載の装置。
【請求項１６】
デルタをフェッチするための前記メカニズムは、フェッチ要求シーケンス番号を含む別のエンドポイントへのフェッチ要求を送信することと、前記他のエンドポイントはフェッチ応答シーケンス番号を含むフェッチ応答メカニズムを含むことと、前記フェッチ応答メカニズムは前記フェッチ要求シーケンス番号が前記フェッチ応答シーケンス番号と等しい場合にデルタをフェッチするための前記メカニズムへ要求されたデルタを返すことを特徴とする請求項１５に記載の装置。
【請求項１７】
前記フェッチ応答メカニズムは、前記フェッチ要求シーケンス番号が前記フェッチ応答シーケンス番号と等しくない場合に前記フェッチするためのメカニズムへ更新メッセージを送信することを特徴とする請求項１６に記載の装置。
【請求項１８】
前記フェッチするためのメカニズムは、前記更新メッセージに応答して前記フェッチ要求シーケンス番号をインクリメントすることを特徴とする請求項１７に記載の装置。
【請求項１９】
前記共有空間内のエンドポイントのサブセットへ送信されるアイデンティティ配布デルタを作成するためのメカニズムを更に含み、前記アイデンティティ配布デルタはそのデルタを生成したエンドポイントとサブシーケンス番号により決定されるポイントでデルタ・ログへ挿入されることを特徴とする請求項１０に記載の装置。
【請求項２０】
各エンドポイントにあるメカニズムであって、活動状態を含む前記共有空間内の全エンドポイントの状態を表わす永続的データを保存するためのメカニズムと、活動状態になっているエンドポイントにだけデルタを送信するためのメカニズムを更に含むことを特徴とする請求項１に記載の装置。
【請求項２１】
各エンドポイントにあるメカニズムであって、デルタの前記データ変更コマンドを実行する前記メカニズムは前記デルタを生成した前記エンドポイントの状態に応答して前記デルタ内の前記データ変更コマンドを選択的に実行することを特徴とする請求項２０に記載の装置。
【請求項２２】
各エンドポイントは現在の状態を有し、各エンドポイントは予め定められたイベントに応答して前記エンドポイントの現在の状態を別の状態に変更するメカニズムを含むことを特徴とする請求項２０に記載の装置。
【請求項２３】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための方法であって、各エンドポイントはローカル・データ・コピーを有し、エンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする方法であって、該方法が、
（ａ）各エンドポイントに配置された永続的デルタ・ログ・データ構造にデルタとその内容を格納するステップと、
（ｂ）前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを前記デルタ・ログに挿入するステップであって、一つのエンドポイントから受信した各デルタは生成及び受信の順序でチェーン内に保持されることを特徴とするステップと、
（ｃ）デルタ内の前記データ変更コマンドを実行し、全エンドポイントでの前記データ変更コマンドの収束を実現するために前記デルタ・ログの内容を用いてデータ変更コマンドを選択的に取り消しまたやり直すステップと、
を含むことを特徴とする方法。
【請求項２４】
前記ステップ（ｂ）は前記各エンドポイントで生成され、かつ、他のエンドポイントから受信したデルタを、そのデルタを生成した前記エンドポイントとシーケンス番号によって決定されるポイントでデルタ・ログへ挿入するステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
デルタ・ログ内の各チェーンはエンドポイントから受信されシーケンス番号により順位付けられたデルタで構成されることを特徴とする請求項２３に記載の方法。
【請求項２６】
デルタ・ログ内の各チェーンは予め定められた最大長を有することを特徴とする請求項２３に記載の方法。
【請求項２７】
前記ステップ（ｂ）は前記デルタ・ログ内の前記チェーンをグループに構成し、各グループ内で、チェーンは作成者ＩＤの昇順に構成され、前記作成者ＩＤはエンドポイントのエンドポイントＩＤとそのエンドポイントが前記共有空間をオープンする度に生成される乱数の組み合わせであることを特徴とする請求項２３に記載の方法。
【請求項２８】
（ｄ）前記共有空間内のエンドポイント間で送信されるエンドポイント・パルスを生成し、各エンドポイント・パルスはエンドポイントで生成されそのエンドポイントが消去を希望するデルタ・グループを識別する情報を含むステップ
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２９】
（ｅ）他のエンドポイントで生成されたエンドポイント・パルスを受信し、全エンドポイントが消去を希望するデルタ・グループを決定するために前記エンドポイントパルスの情報を比較することにより選択したグループ内のデルタを消去するステップ
を更に含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記ステップ（ｃ）は、選択されたデルタ内のデータ変更コマンドをやり直すために、デルタ・ログ内の前記チェーンを使って順次デルタを調べるステップを含むことを特徴とする請求項２３に記載の方法。
【請求項３１】
前記ステップ（ｃ）は、すでに取り消されたデータ変更コマンドをやり直すために、デルタ・ログ内の前記チェーンを使って順次デルタを調べるステップを含むことを特徴とする請求項２３に記載の方法。
【請求項３２】
各デルタは前記各デルタが実行できるようになる前に実行されるべき他のデルタを表わす依存性のリストを有することを特徴とする請求項２３に記載の方法。
【請求項３３】
前記ステップ（ｃ）は、デルタに含まれるデータ変更コマンドを取り消すために、デルタ内に含まれる取り消し情報を使うステップを含むことを特徴とする請求項３２に記載の方法。
【請求項３４】
（ｄ）データ変更コマンドが実行されるのと同時にデルタ内に取り消し情報を挿入するステップ
を更に含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
前記ステップ（ｂ）は、各デルタに割り当てられた優先順位に基づいて前記デルタのチェーンをブロックに挿入するステップであって、各ブロックが最高優先順位のデルタを一つ含み、前記最高優先順位のデルタが依存する全部のデルタは前記各ブロックの前に作成されたブロックに配置され、前記最高優先順位デルタに依存しない全デルタは前記各ブロックに配置され、前記最高優先順位デルタに依存する全デルタは前記各ブロック及び前記各ブロックの後に作成されたブロックに配置されるようにするステップ
を更に含むことを特徴とする請求項３２に記載の方法。
【請求項３６】
（ｄ）非同期デルタを作成するステップであって、他のデルタは前記非同期デルタに依存しないようにするステップ
を更に含むことを特徴とする請求項３２に記載の方法。
【請求項３７】
（ｄ）依存性リストにあるが第１のエンドポイントのデルタ・ログにはないデルタを他のエンドポイントから第１のエンドポイントにフェッチするステップ
を更に含むことを特徴とする請求項３２に記載の方法。
【請求項３８】
前記ステップ（ｄ）は、前記第１のエンドポイントから別のエンドポイントへフェッチ要求シーケンス番号を含むフェッチ要求を送信するステップであって、他のエンドポイントはフェッチ応答シーケンス番号を含むフェッチ応答メカニズムを含むことを特徴とするステップを含み、ステップ（ｄ）はさらに、前記フェッチ要求シーケンス番号が前記フェッチ応答シーケンス番号と等しい場合に別のエンドポイントから第１のエンドポイントへ要求されたデルタを返すステップを含む
ことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記ステップ（ｄ）は前記フェッチ要求シーケンス番号が前記フェッチ応答シーケンス番号と等しくない場合に前記第１のエンドポイントへ更新メッセージを送信するステップ
を更に含むことを特徴とする請求項３８に記載の方法。
【請求項４０】
前記ステップ（ｄ）は前記更新メッセージに応答して前記フェッチ要求シーケンス番号をインクリメントするステップ
を更に含むことを特徴とする請求項３９に記載の方法。
【請求項４１】
前記共有空間内のエンドポイントのサブセットへ送信されるアイデンティティ配布デルタを作成するステップと、そのデルタを生成したエンドポイントとサブシーケンス番号により決定されるポイントで前記アイデンティティ配布デルタをデルタ・ログへ挿入するステップと
を更に含むことを特徴とする請求項３２に記載の方法。
【請求項４２】
（ｄ）活動状態を含む前記共有空間内の全エンドポイントの状態を表わす永続的データを各エンドポイントに保存するステップと、
（ｅ）活動状態になっているエンドポイントにだけデルタを送信するステップ
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項４３】
前記ステップ（ｃ）は、前記デルタを生成した前記エンドポイントの状態に応答して前記デルタ内の前記データ変更コマンドを選択的に実行するステップを含むことを特徴とする請求項４２に記載の方法。
【請求項４４】
各エンドポイントは現在の状態を有し、前記方法が、
（ｆ）予め定められたイベントに応答して前記エンドポイントの現在の状態を別の状態に変更するステップ
を更に含むことを特徴とする請求項４２に記載の方法。
【請求項４５】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するためのコンピュータ・プログラム製品であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とするコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品はコンピュータで読み取り可能なプログラム・コードを有するコンピュータで利用可能な媒体を含み、
各エンドポイントに配置された永続的デルタ・ログ・データ構造にデルタとその内容を格納するためのプログラム・コードと、
前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを前記デルタ・ログに挿入するプログラム・コードであって、一つのエンドポイントから受信した各デルタは生成及び受信の順序でチェーン内に保持されるようにすることを特徴とするプログラム・コードと、
デルタ内の前記データ変更コマンドを実行するプログラム・コードであって、全エンドポイントでの前記データ変更コマンドの収束を実現するために前記デルタ・ログの内容を用いてデータ変更コマンドを選択的に取り消しまたやり直すプログラム・コードと、
を含むことを特徴とするコンピュータ・プログラム製品。
【請求項４６】
前記デルタ・ログへ各デルタを挿入するための前記プログラム・コードは前記各エンドポイントで生成され、かつ、他のエンドポイントから受信したデルタを、そのデルタを生成した前記エンドポイントとシーケンス番号によって決定されるポイントで、デルタ・ログへ挿入するプログラム・コードを含むことを特徴とする請求項４５に記載のコンピュータ・プログラム製品。
【請求項４７】
デルタ・ログの各チェーンはエンドポイントから受信され前記シーケンス番号により順位付けられたデルタで構成されることを特徴とする請求項４５に記載のコンピュータ・プログラム製品。
【請求項４８】
デルタ・ログ内の各チェーンは予め定められた最大長を有することを特徴とする請求項４５に記載のコンピュータ・プログラム製品。
【請求項４９】
前記デルタ・ログへ各デルタを挿入するための前記プログラム・コードは前記デルタ・ログ内のチェーンをグループに構成するためのプログラム・コードを含み、各グループ内でチェーンは作成者ＩＤの昇順に構成され、前記作成者ＩＤはエンドポイントのエンドポイントＩＤとそのエンドポイントが前記共有空間をオープンする度に生成される乱数の組み合わせであることを特徴とする請求項４５に記載のコンピュータ・プログラム製品。
【請求項５０】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための装置であって、各エンドポイントはローカル・データコピーを有しエンドポイントは前記ローカルデータコピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする装置であって、
各エンドポイントにあってデルタとその内容を格納する永続的デルタ・ログ・データ構造と、
各エンドポイントにおける手段であって、前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを前記デルタ・ログに挿入して、一つのエンドポイントから受信した各デルタが生成及び受信の順序でチェーン内に保持されるようにする手段と、
各エンドポイントにおける手段であって、該手段がデルタ内の前記データ変更コマンドを実行し、全エンドポイントでの前記データ変更コマンドの収束を実現するために前記デルタ・ログの内容を用いてデータ変更コマンドを選択的に取り消しまたやり直す手段と
を含むことを特徴とする装置。
【請求項５１】
前記挿入する手段は、前記各エンドポイントで生成され、かつ、他のエンドポイントから受信したデルタに応答して、そのデルタを生成した前記エンドポイントとシーケンス番号によって決定されるポイントでデルタ・ログへデルタを挿入することを特徴とする請求項５０に記載の装置。
【請求項５２】
デルタ・ログの各チェーンはエンドポイントから受信され前記シーケンス番号により順位付けられたデルタで構成されることを特徴とする請求項５０に記載の装置。
【請求項５３】
デルタ・ログ内の各チェーンは予め定められた最大長を有することを特徴とする請求項５０に記載の装置。
【請求項５４】
前記挿入手段は前記デルタ・ログ内のチェーンをグループに構成するための手段を含み、各グループ内でチェーンは作成者ＩＤの昇順に構成され、前記作成者ＩＤはエンドポイントのエンドポイントＩＤとそのエンドポイントが前記共有空間をオープンする度に生成される乱数の組み合わせであることを特徴とする請求項５０に記載の装置。
【請求項５５】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための装置であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする装置であって、
一つのエンドポイントにある第１のツールであって、前記エンドポイントでのユーザのアクションに応答し他のエンドポイントへデータ変更コマンドを送信する第１のデルタ・コンテナを作成するためと前記第１のデルタ・コンテナへデータ変更コマンドを追加するための第１のツールと、
前記一つのエンドポイントにあって前記第１のツールから呼び出され前記第１のデルタ・コンテナへデータ変更コマンドを追加する第２のツールと、
前記第２のツールにある手段であって、第２のデルタ・コンテナを作成し、前記第１のデルタ・コンテナへ前記第２のデルタ・コンテナを追加し、かつ、前記第２のデルタ・コンテナへデータ変更コマンドを追加するための手段と
を含むことを特徴とする装置。
【請求項５６】
前記データ変更コマンドの少なくとも一つは前記データ変更コマンドによって実行されたデータ変更を逆転するための取り消し情報を含むことを特徴とする請求項５５に記載の装置。
【請求項５７】
前記第１のデルタ・コンテナ内の前記データ変更コマンドと前記第２のデルタ・コンテナ内の前記データ変更コマンドを実行するためのデータ変更エンジンと、前記第２のデルタ・コンテナ内の前記データ変更コマンドと前記第２のデルタ・コンテナ内の前記データ変更コマンドに対応する取り消し情報を前記第１のデルタ・コンテナの先頭へ追加するためのダイナミクス・マネージャとを更に含むことを特徴とする請求項５５に記載の装置。
【請求項５８】
前記データ変更エンジンは、前記第２のデルタ・コンテナ内の前記データ変更コマンドが実行され追加されてから前記第１のデルタ・コンテナへ前記第２のデルタ・コンテナが追加される以前に、前記第１のデルタ・コンテナへ追加されたデータ変更コマンドを実行することを特徴とする請求項５７に記載の装置。
【請求項５９】
前記データ変更エンジンは、前記第１のデルタ・コンテナ内の前記データ変更コマンドの実行中のエラー発生に応答して前記第２のデルタ・コンテナ内の前記データ変更コマンドの実行を中止するための手段を含むことを特徴とする請求項５８に記載の装置。
【請求項６０】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための方法であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする方法であって、
（ａ）第１のツールを使って一つのエンドポイントでのユーザのアクションに応答して第１のデルタ・コンテナを作成し他のエンドポイントへデータ変更コマンドを送信するステップと、
（ｂ）前記第１のツールを使って前記第１のデルタ・コンテナへデータ変更コマンドを追加するステップと、
（ｃ）前記一つのエンドポイントにある第２のツールを前記第１のツールで呼び出して前記第１のデルタ・コンテナへデータ変更コマンドを追加するステップと、
（ｄ）前記第２のツールで第２のデルタ・コンテナを作成するステップと、
（ｅ）前記第２のツールを使って、前記第１のデルタ・コンテナへ前記第２のデルタ・コンテナを追加し、かつ、前記第２のデルタ・コンテナへデータ変更コマンドを追加するステップと
を含むことを特徴とする方法。
【請求項６１】
前記データ変更コマンドの少なくとも一つは前記データ変更コマンドによって実行された前記データ変更を逆転するための取り消し情報を含むことを特徴とする請求項６０に記載の方法。
【請求項６２】
（ｆ）前記第２のデルタ・コンテナ内の前記データ変更コマンドと前記第１のデルタ・コンテナ内の前記データ変更コマンドを実行するステップと、
（ｇ）前記第２のデルタ・コンテナ内の前記データ変更コマンドを実行後、前記第２のデルタ・コンテナ内の前記データ変更コマンドと前記第２のデルタ・コンテナ内の前記データ変更コマンドに対応する取り消し情報とを前記第１のデルタ・コンテナの先頭へ追加するステップと、
を更に含むことを特徴とする請求項６０に記載の方法。
【請求項６３】
前記ステップ（ｆ）は前記ステップ（ｇ）を実行後に前記第２のデルタ・コンテナが追加される以前に前記第１のデルタ・コンテナへ追加された前記データ変更コマンドを実行するステップを含むことを特徴とする請求項６２に記載の方法。
【請求項６４】
（ｈ）前記第１のデルタ・コンテナ内の前記データ変更コマンドの実行中のエラー発生時には前記第２のデルタ・コンテナ内の前記データ変更コマンドの実行を中止するステップ
を更に含むことを特徴とする請求項５８に記載の方法。
【請求項６５】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための装置であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする装置であって、
一つのエンドポイントにあるデータ変更エンジンであって、第１のデルタ・コンテナ内の前記データ変更コマンドを実行するためと、前記データ変更コマンドの影響を逆転させるために取り消し情報を生成するためと、前記第１のデルタ・コンテナに前記取り消し情報を格納するためのデータ変更エンジンと、
前記データ変更エンジンにある手段であって、選択されたデータ変更コマンドの実行に応答し前記一つのエンドポイントで第２のデルタ・コンテナを作成して前記第２のデルタ・コンテナへデータ変更コマンドを追加するための手段と
を含むことを特徴とする装置。
【請求項６６】
前記第２のデルタ・コンテナ内の前記コマンドを実行するためと前記第２のデルタ・コンテナ内の前記コマンドの影響を逆転させるための取り消し情報を生成するための手段と、実行時に動作して前記第２のデルタ・コンテナ内の前記コマンドとこれらのコマンドについて生成された取り消し情報とを前記第１のデルタ・コンテナの前記取り消し情報に格納するための手段とを更に含むことを特徴とする請求項６５に記載の装置。
【請求項６７】
前記第１のデルタ・コンテナ内の前記取り消し情報を使って前記第１のデルタ・コンテナ内に含まれた前記コマンドの影響を逆転させるための手段を更に含み、前記取り消し情報を使う前記手段は、前記第２のデルタ・コンテナを作成した前記選択されたコマンドが逆転される前に、前記第１のデルタ・コンテナにもともと格納されていたコマンドを逆転することを特徴とする請求項６６に記載の装置。
【請求項６８】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための方法であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする方法であって、
（ａ）第１のデルタ・コンテナ内の前記データ変更コマンドを実行し、前記データ変更コマンドの影響を逆転させるために取り消し情報を生成し、前記取り消し情報を第１のデータ変更コンテナに格納するステップと、
（ｂ）選択されたデータ変更コマンドの実行に応答して、一つのエンドポイントで第２のデルタ・コンテナを作成するステップと、
（ｃ）データ変更コマンドを前記第２のデルタ・コンテナに追加するステップと
を含むことを特徴とする方法。
【請求項６９】
（ｄ）前記第２のデルタ・コンテナにある前記コマンドを実行し、かつ、前記第２のデルタ・コンテナにある前記コマンドの影響を逆転させるための取り消し情報を作成するステップと、
（ｅ）前記第２のデルタ・コンテナからの前記実行したコマンドとこれらのコマンドについて生成した取り消し情報とを前記第１のデルタ・コンテナの前記取り消し情報に格納するステップと
を更に含むことを特徴とする請求項６８に記載の方法。
【請求項７０】
（ｆ）前記第１のデルタ・コンテナ内に含まれる前記コマンドの影響を逆転させるために、前記第１のデルタ・コンテナ内の前記取り消し情報を使うステップと、
（ｇ）ステップ（ｆ）の実行中に、前記第２のデルタ・コンテナに作成した前記選択されたコマンドを逆転する前に前記第２のデルタ・コンテナにもともと格納されていたコマンドを逆転するステップ
を更に含むことを特徴とする請求項６９に記載の方法。
【請求項７１】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための装置であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする装置であって、
各デルタにある衝突領域であって、前記各デルタの実行が衝突する他のデルタを識別する衝突領域と、
各エンドポイントにある永続的デルタ・ログ・データ構造であって、デルタとその内容とを格納する永続的デルタ・ログ・データ構造と、
各エンドポイントにあるメカニズムであって、前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを、そのデルタのグループ番号とシーケンス番号とに基づいて全エンドポイントにわたって一貫した順序で前記デルタ・ログに挿入するメカニズムと、
最後に入力されたデルタから始めて最初に入力されたデルタに向かって進むように前記デルタ・ログを逆行するデータ・エンジンであって、各々の実行されたデルタの衝突領域と前記デルタ・ログに入力された他のデルタの前記衝突領域とを比較し、前記デルタ・ログに入力された別のデルタと衝突する各々の実行されたデルタの影響を逆転させるデータ・エンジンと、
を含むことを特徴とする装置。
【請求項７２】
前記データ・エンジンは、前記デルタにある前記データ変更コマンドに対して逆の順序で反復し、かつ、各データ変更コマンドについて前記デルタにある取り消し情報を使用して前記コマンドの影響を逆転させることにより、衝突を有する各々の実行されたデルタの影響を逆転させる手段を含むことを特徴とする請求項７１に記載の装置。
【請求項７３】
別のデルタと衝突する各デルタの影響を逆転させた後で、前記データ変更エンジンは最後に入力されたデルタから始めて最初に入力されたデルタに向かって進むように前記デルタ・ログを逆行し、かつ、逆転させた各デルタにある前記データ変更コマンドを再実行することを特徴とする請求項７２に記載の装置。
【請求項７４】
各デルタの前記衝突領域は前記デルタが作成されたときにセットされることを特徴とする請求項７３に記載の装置。
【請求項７５】
コラボレーション・コンピュータ・システム内の複数のエンドポイント間で共有空間の一貫性を維持するための方法であって、各エンドポイントはローカル・データ・コピーを有しエンドポイントは前記ローカル・データ・コピーを更新するためにデルタに含まれるデータ変更コマンドを互いに送信することを特徴とする方法であって、
（ａ）各デルタにあって前記各デルタの実行が衝突する他のデルタを識別する衝突領域を作成するステップと、
（ｂ）各エンドポイントにある永続的デルタ・ログ・データ構造にデルタとその内容とを格納するステップと、
（ｃ）前記各エンドポイントで生成され、かつ、他のエンドポイントから受信した各デルタを、そのデルタ内のグループ番号とシーケンス番号とに基づいて全エンドポイントにわたって一貫した順序で前記デルタ・ログに挿入するステップと、
（ｄ）最後に入力されたデルタから始めて最初に入力されたデルタに向かって進むように前記デルタ・ログを逆行するステップであって、各々の実行したデルタの衝突領域と前記デルタ・ログに入力された他のデルタの前記衝突領域とを比較し、前記デルタ・ログに入力された別のデルタと衝突する各々の実行されたデルタの影響を逆転させるステップと
を含むことを特徴とする方法。
【請求項７６】
前記ステップ（ｄ）は、前記デルタにある前記データ変更コマンドに対して逆の順序で反復し、かつ、各データ変更コマンドについて前記デルタにある取り消し情報を使用して前記コマンドの影響を逆転させることにより、衝突を有する各々の実行されたデルタの影響を逆転させるステップを含むことを特徴とする請求項７５に記載の方法。
【請求項７７】
（ｅ）別のデルタと衝突する各デルタの影響を逆転させた後で、最後に入力されたデルタから始めて最初に入力されたデルタに向かって進むように前記デルタ・ログを逆行し、かつ、逆転させた各デルタにある前記データ変更コマンドを再実行するステップ
を更に含むことを特徴とする請求項７６に記載の方法。
【請求項７８】
前記ステップ（ａ）は前記デルタを作成した時点で各デルタの衝突領域を作成するステップを含むことを特徴とする請求項７７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコラボレータ（ｃｏｌｌａｂｏｒａｔｏｒ）間で共有空間の一貫性を維持する目的でコマンド（ｃｏｍｍａｎｄ）及びデータ・ブロックを直接交換するピアツーピア型（ｐｅｅｒ−ｔｏ−ｐｅｅｒ型）コラボレーション・コンピュータ・システムに関する。
【背景技術】
【０００２】
コラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）は、「コラボレータ」と呼ばれるメンバーからなるグループ内の各メンバーがそのグループ内の他のコラボレータへ情報を自動的に送信しまた他のコラボレータから情報を受信することができる能力に関係する。このようなコラボレーションを容易にするため、パーソナル・コンピュータ・システム間、通信機器間、または携帯装置及び無線装置を含むその他の通信装置間で情報が送信できるようにする各種システムが開発されて来た。これらの装置を総合的に本明細書では「コンピュータ」と呼称する。
【０００３】
コンピュータを用いたコラボレーションは１台のコンピュータ又はサーバに接続されているかこれで作業しているユーザ間でローカル（ｌｏｃａｌ）に行なわれることがある。これ以外に、コラボレーションはネットワーク上で、例えばインターネット等、ユーザ各々がネットワークに接続されたコンピュータを用いている環境で行なわれることがある。サーバもネットワークに接続される。幾つかのコラボレーション・モデルがネットワーク化コンピュータ・コラボレーション・システムとして実現されている。このようなモデルの一つがクライアント・サーバ・モデルで、この場合全てのコラボレータがネットワークを介して中央のサーバへ接続される。各コラボレータによって生成された情報はネットワーク経由でサーバへ送信され、このサーバがネットワーク上で他の各コラボレータへこの情報をブロードキャスト（ｂｒｏａｄｃａｓｔ）する。別のモデルは「ピアツーピア型」で、コラボレータのコンピュータ各々の間でネットワーク上で直接接続を確立するものである。各コラボレータによって生成された情報は他の各コラボレータへ直接送信される。このようなシステムでは、コラボレータはプライベートな「仮想」共有空間内で通信する。
【０００４】
これらのモデルには共に、コラボレータ間で情報を転送する幾つかの方法が存在する。例えば、クライアント・サーバ・システムでは、コラボレーションにおいて変更されようとするデータがサーバ上に格納される。次に、データを変更したい各コラボレータはサーバへコマンドを送信してサーバ上のデータに変更を行なう。サーバはこのデータのコピーに変更を加え、変更されたデータの「ビュー」（ｖｉｅｗ）を表わす情報をコラボレータ全員へ送信し、各コラボレータがローカルにデータを表示できるようにする。
【０００５】
集中データ・リポジトリ（ｃｅｎｔｒａｌ  ｄａｔａ  ｒｅｐｏｓｉｔｏｒｙ）がピアツーピア型コラボレーション・システムで実現できないのは、コラボレータが誰もサーバとして機能しないためである。つまり、このようなシステムでは、各コラボレータがコラボレーションで変更されるデータのローカルなコピーを有している。データを変更するためには、コラボレータがデータ変更要求を生成し、これを他の各コラボレータへ転送する。到着したデータ変更要求を各コラボレータが使用してローカルに保有しているデータのコピーを変更する。
【０００６】
後者のタイプのコラボレーション・システムは、「通信マネージャを装備したコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置」と題する１９９９年７月１９日付けＲａｙｍｏｎｄ  Ｅ．  Ｏｚｚｉｅ，  Ｋｅｎｎｅｔｈ  Ｇ．  Ｍｏｏｒｅ，  Ｒｏｂｅｒｔ  Ｈ．  Ｍｙｈｉｌｌ，  Ｂｒｉａｎ  Ｍ．  Ｌａｍｂｅｒｔによる米国特許出願第０９／３５７，００７号、「ダイナミクス・マネージャを備えたコンピュータ・システムによるアクティビティ・ベースのコラボレーションのための方法及び装置」と題する１９９９年７月１９日付けＲａｙｍｏｎｄ  Ｅ．  Ｏｚｚｉｅ  ａｎｄ  Ｊａｃｋ  Ｅ．  Ｏｚｚｉｅによる米国特許出願第０９／３５６，９３０号、「アクティビティ・ベースのコラボレーションを備えた分散コンピュータ・システムにおいてデータ変更要求に順位付けしデータの一貫性を維持するための方法及び装置」と題する１９９９年７月１９日付けＲａｙｍｏｎｄ  Ｅ．  Ｏｚｚｉｅ，  Ｊａｃｋ  Ｅ．  Ｏｚｚｉｅによる米国特許出願第０９／３５６，１４８号、「ＸＭＬドキュメントの効率的管理の方法及び装置」と題する２０００年６月６日付けＲａｙｍｏｎｄ  Ｅ．  Ｏｚｚｉｅ，  Ｋｅｎｎｅｔｈ  Ｇ．  Ｍｏｏｒｅ，  Ｒａｎｓｏｍ  Ｌ．  Ｒｉｃｈａｒｄｓｏｎ，  Ｅｄｗａｒｄ  Ｊ．  Ｆｉｓｃｈｅｒによる米国特許出願第０９／５８８，１９５号に詳細に記載されている。
【０００７】
このコラボレーション・システムでは、各コラボレータは「アクティビティ」と呼ばれるその人のコンピュータで動作可能なプログラムを持つ。アクティビティのプログラムはデータ変更コマンドを生成することによりユーザとの相互作用に応答するツールを含む。これらのデータ変更コマンドはデータ変更エンジンに提供され、エンジンはデータ変更コマンドにより要求されたデータへの変更を実行することによりローカルなデータのコピーを保持する。このコマンドは「デルタ」と呼ばれる入れ物（以下、コンテナ）に挿入され、デルタは通信マネージャと呼ばれるプログラムによって一人のコラボレータから別のコラボレータへと配布される。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ピアツーピア型コラボレーション・システムをネットワーク上で使用する場合、特別な注意を払う必要がある。主な注意点はネットワークのレイテンシ（ｌａｔｅｎｃｙ）である。特に、デルタがネットワーク上で他のコラボレータのグループへ送信される場合、ネットワーク上の伝送時間の不均衡のためにあるコラボレータには他のコラボレータより早くデルタが到着することがある。全てのコラボレータがデルタを「非同期的に」送受信するので、別のコラボレータは違う順序で要求を受け取ることになる。これは、幾つかのコマンドの正しい実行が、すでに実行された他のコマンドに依存しているため、問題を生じる可能性がある。ローカルなデータ・コピーが一貫性を保つことを保証するため、コラボレーション・システムは前後関係（ｃａｕｓａｌｉｔｙ）を保存する必要がある。特に、前後関係では、第１のコラボレータから受信した現在のデータ変更コマンドを第２のコラボレータが実行する場合に、第２のコラボレータは現在のデータ変更コマンドが作成された時点で第１のコラボレータがすでに実行していた全ての先行データ変更コマンドを実行しておくことが必要とされる。
【０００９】
満足されるべき別の条件としては収束（ｃｏｎｖｅｒｇｅｎｃｅ）が挙げられる。収束は、全コラボレータが同じ操作のセットを実行した時点で、全コラボレータによるデータ変更コマンドの最終的な実行順序が同じであることを保証する。前述の特許出願に記載されたコラボレーション・システムでは、ダイナミクス・マネージャと呼ばれるプログラムであって、各コンピュータにある特別なプログラムがそのコンピュータで生成されたデルタと他のコンピュータからそのコンピュータで受信したデルタを受け取って解釈し、前後関係を保存し収束を保証するようにしている。
【００１０】
ピアツーピア型システムで考えられる別の潜在的な問題点は、現在進行中のセッションの最中にネットワークからコンピュータを切断するかコンピュータを停止させる（ｐｏｗｅｒ  ｄｏｗｎ）ことでコラボレーションを行っているグループに出入りするコラボレータに関してである。コラボレータがローカルに保持しているデータ・コピーの完全性は他のコラボレータからデータ変更コマンドを受信してこれらのコマンドを正しく解釈することにかかっているので、コラボレーションのセッションから離脱するコラボレータはそのシステムを再スタートさせるためにはローカル・データの完全な最新のコピーか、あるいは不在中に他のコラボレータが送信したデータ変更コマンドの集合の、いずれかが必要になる。多くの場合、ローカルなデータのコピーとデータ変更コマンドの集合はきわめて大きくなることがあり、進行中のコラボレーションのセッションに参入するコラボレータにとっては起動にかかる時間が長いものになる。
【課題を解決するための手段】
【００１１】
本発明の原理によれば、デルタはデルタ・ログ（ｄｅｌｔａ  ｌｏｇ）と呼ばれる永続的なデータ構造を構成する。デルタ・ログはブロックから構成され、ブロックはデルタ・ログにおける最も大きな分割単位である。さらに、ブロックはグループを含み、グループはチェーン（ｃｈａｉｎ）を含み、チェーンはデルタを含む。デルタ・ブロックを使って、転送しなければならないデータ変更コマンドの集合体を制限するために使用する優先デルタを実現する。ブロック内でデルタはグループにより構成され、その各々がチェーンに構成されたデルタのセットである。デルタ・グループはどのデルタをパージ（ｐｕｒｇｅ）するか判定するために使用される。チェーンはチェーンを作成したエンドポイントの作成者ＩＤを増分（インクリメント）することで順位付ける。このような方法でデルタ・ログを構成することで、デルタを全てのエンドポイントで一貫した順序に維持する。これによりデルタ・ログを「歩き回る（ｗａｌｋ）」ことをすれば全てのエンドポイントで収束を実現させることが可能になる。
【００１２】
前後関係の保持を実現するため、各デルタは現在のデルタを実行することができるようになる前に実行されていなければならない他のデルタを表わす依存関係（ｄｅｐｅｎｄｅｎｃｙ）のリストを備えている。ダイナミクス・マネージャはコマンドを実行したり取り消す能力を利用してデルタへの操作を戻したり進めたりすることで、収束を達成する。
【００１３】
デルタ・ログが大きくなりすぎるのを防止するため、本発明の原理によるパージ技術が共有空間内のエンドポイント間で送信されるエンドポイント・パルス（ｅｎｄｐｏｉｎｔ  ｐｕｌｓｅ）を使用する。各々のエンドポイント（ｅｎｄｐｏｉｎｔ）はエンドポイント・パルスの中に、パージを希望するデルタ・グループを識別する情報を含んでいる（各エンドポイントが受信を確認した最高順位のグループに基づく）。次に、全エンドポイントはパージを希望するとエンドポイントが宣言したグループを比較して選択されたグループ内のデルタをパージする。
【００１４】
別の実施態様によれば、優先デルタと呼ばれる特別なデルタを用いて非依存性デルタの実行順序を制御する。例えば、あるエンドポイントを共有空間へ招待するデルタは優先デルタとなることがあり、招待デルタとは無関係のデルタは収束を実現するのに必要なロールバック（ｒｏｌｌｂａｃｋ）を起すことはなく、そのため、デルタ・ログ全体の内容を新しい被招待者へ送信する必要はない。
【００１５】
更に別の実施態様によれば、非同期デルタと呼ばれる特別なデルタを使って、ファイル転送処理中に他のデルタの送信を阻止することなく大きなファイルの送信を行なうようにする。非同期デルタは、これらに依存する他のデルタがないように構成されている。したがって、エンドポイントは立替金のデルタの送信を行うために非同期デルタの処理が完了するまで待つ必要がない。
【００１６】
更に別の実施態様によれば、永続性データが共有空間内の全エンドポイントの状態を表わすように保持される。デルタは活動中（アクティブ）のエンドポイントだけに送信され、到着デルタの処理はそのデルタを送信したエンドポイントの状態に依存する。これらの状態は、非集約型で機密的に、メンバーシップ変更の実施、例えば招待と非招待をサポートする。さらに、共有空間内で活動していないエンドポイントを保留してデルタ・ログの一部をパージできるようにすることも可能である。
【発明の効果】
【００１７】
本発明によれば、コラボレータ間で共有空間の一貫性を維持するピアツーピア型コラボレーション・コンピュータ・システムをネットワーク上で実現することが可能となる。
本発明においては、デルタはデルタ・ログと呼ばれる永続的なデータ構造を構成するが、本発明の方法でデルタ・ログを構成することで、デルタを全てのエンドポイントで一貫した順序に維持することが可能になる。これによりデルタ・ログを「歩き回る（walk）」ことをすれば全てのエンドポイントで収束を実現させることが可能になる。
【００１８】
本発明においては、ダイナミクス・マネージャはコマンドを実行したり取り消す能力を利用してデルタへの操作を戻したり進めたりすることで、収束を達成することが可能となる。
【００１９】
本発明においては、デルタ・ログが大きくなりすぎるのを防止するため、本発明の原理によるパージ技術が共有空間内のエンドポイント間で送信されるエンドポイント・パルスを使用する。各々のエンドポイントはエンドポイント・パルスの中に、パージを希望するデルタ・グループを識別する情報を含んでいる（各エンドポイントが受信を確認した最高順位のグループに基づく）。次に、全エンドポイントはパージを希望するとエンドポイントが宣言したグループを比較して選択されたグループ内のデルタをパージすることが可能となる。
【００２０】
本発明においては、優先順位デルタと呼ばれる特別なデルタを用いて非依存性デルタの実行順序を制御することが可能となる。たとえば、あるエンドポイントを共有空間へ招待するデルタは優先デルタとなることがあり、招待デルタとは無関係のデルタは収束を実現するのに必要なロールバックを起すことはなく、そのため、デルタ・ログ全体の内容を新しい被招待者へ送信する必要がなくなる。
【００２１】
本発明においては、非同期デルタと呼ばれる特別なデルタを使って、ファイル転送処理中に他のデルタの送信を阻止することなく大きなファイルの送信を行なうようにできる。非同期デルタは、これらに依存する他のデルタがないように構成されている。したがって、エンドポイントは他のデルタの送信を行うために非同期デルタの処理が完了するまで待つ必要がなくなる。
【００２２】
本発明においては、永続性データが共有空間内の全エンドポイントの状態を表わすように保持できる。デルタは活動中のエンドポイントだけに送信され、到着デルタの処理はそのデルタを送信したエンドポイントの状態に依存する。これらの状態は、非集約型で機密的に、メンバーシップ変更の実施、たとえば招待と非招待をサポートする。さらに、共有空間内で活動していないエンドポイントを保留してデルタ・ログの一部をパージできるようにすることも可能となる。
【発明を実施するための最良の形態】
【００２３】
図１は非常に簡略に、ピアツーピア型コラボレーション・システム１００を示しており、この場合コラボレーションするコンピュータは互いにインターネット等のネットワーク１１０で接続されている。このようなシステムでは様々なネットワークを使用できるが、以下の説明では、ネットワーク１１０がインターネットであると仮定する。本システムでは、コラボレーション・コンピュータ・システム（ｃｏｌｌａｂｏｒａｔｉｎｇ  ｃｏｍｐｕｔｅｒ  ｓｙｓｔｅｍ）はピア・ユニット１０２〜１０８で構成され、インターネット１１０を介しての通信は一つのピア・ユニットから別のピア・ユニットへ、中継なしに送信できる。各ピア・ユニット１０２〜１０８はパーソナル・コンピュータまたはその他の形態のネットワーク接続可能な装置、例えばセット・トップ・ボックス又は携帯機器等で実現可能である。
【００２４】
ピアツーピア型通信はピア・ユニット間で直接行なうことができる。例えば、ピア・ユニット１０２は破線１１２、１１６、１１４で各々示してあるように、ピア・ユニット１０４、１０６、１０８と直接通信できる。同様に、ピア・ユニット１０４は各々接続１２０、１１８を経由してユニット１０８や１０６と接続できる。最後に、ユニット１０６と１０８は接続１２２の上で通信可能である。図１に示したようなコラボレーション・システムは、米国  マサチューセッツ州  ビバリー、カミングス・センター  １００、スイート５３５Ｑのグルーブ・ネットワークス社から入手可能で、グルーブ・ネットワークス社およびオンラインでｈｔｔｐ：／／ｗｗｗ．ｇｒｏｏｖｅ．ｎｅｔから入手可能なグルーブ・プラットフォーム開発キットに詳細に説明されている。以下の説明では、コラボレーション・システムはこのようなシステムであると仮定する。しかし、他のコラボレーション・システムも本発明で使用可能なことは当業者には明らかであろう。
【００２５】
本コラボレーション・システムでは、「アクティビティ」と呼ばれるプログラムが各々のコラボレーション・コンピュータ・システム、通信機器、又はその他のネットワーク接続可能な装置に常駐する。アクティビティにより共有される特定の議題の作業例えば「チャット」、ゲーム、ビジネス用途などを他の遠隔地にいるコラボレータと協動作業で（コラボレーションして）実行できるようになる。このコラボレーションにはプライベート共有空間の個人間および小グループ間で共有される相互のアクティビティが関与する。各共有空間はその共有空間のメンバーのコラボレーション・コンピュータの各々で動作可能な１つまたはそれ以上のアクティビティの事例（ｉｎｓｔａｎｔｉａｔｉｏｎ）である。
【００２６】
本システムでは、共有空間の参加者又はメンバーが、「エンドポイント」に関連する「アカウント」を開いてシステムにアクセスする。個々のコラボレータは１つ以上の装置からシステムにアクセスすることがあるので、エンドポイントは個人と装置の唯一の（以下、ユニークな）組合せとして定義する。各エンドポイントは共有空間データの個別のローカルなコピーを格納する。
【００２７】
各アクティビティは１つまたはそれ以上のツールを含み、その各々が例えばマウス及びキーボードのイベントを受け取る等して、コラボレータと相互作用し、この相互作用に応答してデータ変更要求を開始する。これらのデータ変更要求はローカルに使用され共有空間の他のメンバーへ送信される。各アクティビティはさらに１つまたはそれ以上のデータ変更エンジンも含み、これはツールとは別のもので共通データ・モデルに準拠する共有空間データのローカル・コピーを維持するものである。データ・モデルは、例えば、アクティビティ毎に異なり、共有空間のメンバー全員に対して同一であるのが望ましい。各コラボレーション・コンピュータはダイナミクス・マネージャも含み、これがローカルに生成されたデータ変更要求や、他の共有空間メンバーから受信したデータ変更要求を検証しローカル及びその他のデータ変更要求の実行を調整し、データ変更エンジンに対してデータのローカル・コピーへ要求された変更を行なうように指示する。
【００２８】
図２は更に詳細に、ピア・ユニット１０２〜１０８のうちの一つ、例えばピア・ユニット１０２で実現されるコラボレーション・システムの内部アーキテクチャ２００を示している。ピア・ユニット１０２のコラボレーション・システムは、フレームワーク２０２、１つまたはそれ以上のアクティビティ２０５を実現する少なくとも一つの共有空間２０４、およびユーザ・インタフェース２０６を含む。
【００２９】
フレームワーク２０２は、共有空間２０４が図示してある多数の共有空間にサービスする（ｓｅｒｖｉｃｅ）ためのプラットフォームを提供できる。フレームワーク２０２はモジュール構造が望ましく、アクティビティが動作しフレームワーク・コンポーネントと通信するアプリケーション・プログラム・インタフェース（ＡＰＩ）を備える。フレームワーク２０２はユーザ・インタフェース・マネージャ２０８、アイデンティティ・マネージャ２１０、共有空間マネージャ２１２、アクティビティ・マネージャ２１４、ストレージ・マネージャ（ｓｔｏｒａｇｅ  ｍａｎａｇｅｒ）２１６、ダイナミクス・マネージャ２２０、通信マネージャ２２２を含む。
【００３０】
ユーザ・インタフェース（ＵＩ）・マネージャ２０８は多数のユーザ・インタフェース・コントローラ（図示していない）に対しての共有サービスを管理する責任がある。ユーザ・インタフェース・マネージャ２０８は表示ウィンドウの窓ガラス内のアクティビティ画面表示のグラフィカル（ｇｒａｐｈｉｃａｌ）なレイアウトを管理し、それ以外にユーザ・インタフェースに所望の「ルック・アンド・フィール」（ｌｏｏｋ  ａｎｄ  ｆｅｅｌ）を提供する。ユーザ・インタフェース・マネージャ２０８はアクティビティのナビゲーション（例えば進む、次、前、など）を管理しナビゲーション履歴を保持する。
【００３１】
アイデンティティ・マネージャ２１０は各共有空間メンバーの「アイデンティティ」を保持する責任がある。アイデンティティは名前と、これに対応する一意の資源ロケータ（ＵＲＬ）で、これにより各ユーザが他のユーザに判る。個々のユーザは１つまたはそれ以上のアイデンティティを有することがある。アイデンティティ・マネージャ２１０はアイデンティティのローカルな格納部（以下、ストレージ）にレコード又はテーブルを保持する。アイデンティティ・マネージャ２１０は共有空間メンバーのＵＲＬとこれらに対応する装置のＵＲＬのレコード又はテーブルも保持できる。これ以外に、独立したメンバー・マネージャを実現することが可能である。
【００３２】
共有空間マネージャ２１２はピア・ユニット１０２で開く（以下、オープンする）ことができる共有空間２０４の各々を管理する責任がある。共有空間２０４各々は１つまたはそれ以上のアクティビティの具現化である。各共有空間２０４はこれに対応したアクティビティ・マネージャ２１４を備えている。
【００３３】
各アクティビティ・マネージャ２１４は（ａ）新規アクティビティを共有空間へ追加し、（ｂ）共有空間に既存のアクティビティをオープンし、（ｃ）共有空間アクティビティを更新する責任がある。各アクティビティは共有空間の初期アクティビティ構成を定義したアクティビティ・「テンプレート（ｔｅｍｐｌａｔｅ）」によって定義され、アクティビティを含むツール及びエンジン・コンポーネントの永続的表現である。アクティビティ・テンプレートを作成するには、ソフトウェア開発者はツールを書くかフレームワーク内で使用する既存のツール及びエンジンを適用する。例えば、アクティビティ・テンプレートはシュリンク・ラップしたソフトウェアとして配布したり遠隔地のサーバからピア・ユニット１０２へインターネット経由でダウンロードできる。アクティビティ・コンポーネントはウェブ・ドキュメントと看做すことができ、ＵＲＬ経由で永続的に表現される。アクティビティ・テンプレートそれ自体はＵＲＬを持つのが望ましく、これによりアクティビティの設計変更を追跡できる。アクティビティ・テンプレートは単一のアクティビティ・テンプレートまたはアクティビティ集合のテンプレートとすることができる。単一のアクティビティ・テンプレートは「チャット」等一つのアクティビティだけに関連する。アクティビティの集合テンプレートは例えば「チャットとアウトライン」等のアクティビティ集合に関連する。
【００３４】
新規アクティビティを追加するには、アクティビティ・マネージャ２１４に新規アクティビティのテンプレートのＵＲＬが上記手段により提供される。新規アクティビティあるいは既存のアクティビティをオープンするには、アクティビティ・マネージャはテンプレートをオープンし、テンプレート情報（例えばコンポーネントのＵＲＬ）を抽出して情報を共有空間へ伝播させる。コラボレータは必要に応じて共有空間２０４へ追加のアクティビティを追加できる。追加した後、アクティビティは共有空間の「一部」となって全ての共有空間メンバーから見えるようになり、各共有空間メンバーはそのメンバーのピア・ユニットで利用可能な共有空間のアクティビティ・テンプレートを有する。
【００３５】
各共有空間例えば共有空間２０４はこれに対応するアクティビティ・マネージャ２１４を識別するためとアクティビティ・マネージャにアクティビティと関係するデータを結合するためのタグを備える。望ましくは、このデータはローカル・メモリ内のドキュメントに配置され各ドキュメントはローカル・レジストリ内に保持されたタグ名でリンクされたローカル・レジストリを保持して、ドキュメントとこれに対応する共有空間との間の拡張可能な、プラットホーム非依存のマッピング（参照ポインタ又は関連性）を表現する。
【００３６】
各アクティビティ、例えばアクティビティ２０５はツール２２４等のツールと、エンジン２２６などのエンジンを含む。ツール２２４はユーザ・インタフェース２０６との組み合わせで、アクティビティがコラボレータと相互作用できるようにする。例えば、ツールはキーボード・イベント又はマウス・イベント等、ユーザがユーザ・インタフェース２０６と相互作用した時に生成されるユーザ・インタフェース・イベントを受け取ることができる。このようなユーザ・インタフェース・イベントに応答して、ツール２２４はこれに対応するエンジン２２６へのデータ変更要求を作成できる。ツール２２４はバックグラウンド・サービスと相互作用するアプリケーション・プログラム・インタフェース（ＡＰＩ）も実装する。
【００３７】
エンジン２２６は共有空間２０４をサポートするデータおよび／またはツール２２４を通して得られたユーザとの相互作用から得られるデータを維持して変更する責任がある。エンジンはツール２２４へデータ変更要求を実現するのに必要なコマンド（ｃｏｍｍａｎｄ）を返すことでツール２２４からのデータ変更要求に応答する。ダイナミクス・マネージャ２２０の管理制御下でエンジン２２６はストレージ・マネージャ２１６の制御下でローカルに保存されている共有空間のデータ・コピーに変更を加えることができる。これらの変更が行なわれると、エンジン２２６は非同期的にデータ変更通知を生成する。ツール２２４はエンジン２２６に加入（ｓｕｂｓｃｒｉｂｅ）してこれらのデータ変更通知を受け取り、データの変更が発生した時にツール２２４が非同期的にユーザ・インタフェースを更新できるようにする。
【００３８】
ダイナミクス・マネージャ２２０はツール２２４からのローカルなデータ変更コマンドを受け取り、またネットワーク接続２２８から通信マネージャ２２２経由で他のコラボレーション・コンピュータからのデータ変更コマンドを受け取る。これらのコマンドはコラボレータ間の送信のために暗号化され、ダイナミクス・マネージャ２２０はセキュリティ・マネージャ２３０を使用してこれらのコマンドを復号できる。ダイナミクス・マネージャ２２０は全てのコラボレータで同期を維持するためにどのコマンドを実施するか決定して、エンジン２２６にローカル・データコピーへの変更を行なわせるためにこれらのコマンドをエンジン２２６へ転送する。
【００３９】
動作中にコラボレーション・システム２００はアイデンティティ・マネージャ２１０からメンバーのアイデンティティを取得し共有空間マネージャ２１２をオープンする。システム２００は共有空間マネージャ２１２にＵＲＬ経由で識別した共有空間をオープンしてアクティビティ・マネージャ２１４を作成するように要求する。作成されると、アクティビティ・マネージャ２１４は代表的にはアクティビティのＵＲＬを用いてアクティビティを識別することによりアクティビティをオープンする。次に、コラボレーション・システム２００ではメンバーが共有空間を使って特定のアクティビティによって提供されて共有された特定の議題の作業を実行できるようになる。
【００４０】
前述のように、エンジン２２６によって生成されたデータ変更要求は「デルタ」と呼ばれるコンテナ（ｃｏｎｔａｉｎｅｒ）に配置され、このデルタは他のコラボレータへデータ変更要求を送信するために使用される。例示的なコラボレーション・システムでは、デルタは共有空間内の変更の基本単位（ａｔｏｍｉｃ  ｕｎｉｔ）であり複数のエンドポイントに影響を与えるような共有空間の変更を行なう唯一の方法である。各エンドポイントのダイナミクス・マネージャ２２０は、各デルタのデータ変更コマンドが正しく実行されるようにする責任があり、データ変更コマンドの順序は共有空間内の多数のエンドポイントで一貫する。これを行なうために、ダイナミクス・マネージャ２２０は各種エンジン２２６と協調してデータ変更コマンドを実行したり「取り消したり」する。
【００４１】
ダイナミクス・マネージャは前述の前後関係維持と収束を確実にするために必要な各種サービスを扱う複数のフレームワークを提供する。これらのフレームワークには、コマンド実行フレームワーク、助言フレームワーク、配布フレームワーク、デルタ・ログ管理フレームワークが含まれる。
【００４２】
前後関係の維持を実現するため各デルタは現在のデルタを実行する前に実行されていなければならない他のデルタを表現する依存関係のリストを有する。ダイナミクス・マネージャはコマンドを実行したり取り消したりできる能力を用いてデルタに対してロールバック（ｒｏｌｌ  ｂａｃｋ）及びロールフォワード（ｒｏｌｌ  ｆｏｒｗａｒｄ）操作を行ない収束を実現する。二つのエンドポイント、ＡとＢが独立にデルタＤＡとＤＢを生成して実行し、デルタを他のエンドポイントに送信した場合、一方のエンドポイントは双方のエンドポイントが収束するようにデルタの実行を「ロールバック（巻き戻し）」する必要がある。例えば、エンドポイントＡでは、デルタＤＡはデルタＤＢを受信する前に実行される。エンドポイントＢではデルタＤＡを受信する前にデルタＤＢが実行される。収束を確実にするためには、一方のエンドポイントがロールバックを必要とする。ダイナミクス・マネージャによって決定された正しい実行順序がＤｏ（ＤＡ）Ｄｏ（ＤＢ）なら、エンドポイントＢはロールバックを実行する必要がある。Ｂでの実行順序は、Ｄｏ（ＤＢ）Ｕｎｄｏ（ＤＢ）Ｄｏ（ＤＡ）Ｄｏ（ＤＢ）となる。このようにして、最終的な実行順序は双方のエンドポイントで同一になる。
【００４３】
コマンド実行フレームワークの一部として、ダイナミクス・マネージャ２２０はコマンドが実行された時に発生する例外の処理も提供する。ダイナミクス・マネージャ２２０はツールがユーザ・レベルの取り消し及びやり直し動作を実行できるようにするためにＡＰＩも提供する。ダイナミクス・マネージャ２２０はロールバック動作及びロールフォワード動作で用いられているのと同じ取り消しとやり直しの実装を使用してユーザの取り消し動作及びやり直し動作をサポートする。
【００４４】
ダイナミクス・マネージャは実行の方法及びやり直しの方法（以下、メソッド）の一部としてエンジンにより実行することのできる動作に制限も設ける。さらに詳しくは、エンジンはこれらのメソッドを実行している間にこれより高いレベルのコンポーネント（ビュー等）を呼び出すことができない。ビュー通知をエンジンが実装できるようにするために、ダイナミック・マネージャ２２０は「助言（ａｄｖｉｓｅ）」要素との関係で非同期通知サービスを提供する。これらの要素はダイナミクス・マネージャ２２０に提供されダイナミクス・マネージャ２２０はこれらの通知を受け取るように登録されている全ての実体に非同期的に通知する。この通知はコマンドの実行以外のイベントの通知にも使用される。
【００４５】
ダイナミクス・マネージャ２２０はさらに共有空間内の活動中のエンドポイント（以下、活動エンドポイント）全部でデルタが送受信されることを保証する責任がある。これを行なうには、ダイナミクス・マネージャ２２０は共有空間内の全部のエンドポイントについてコンタクト情報を保持する。ローカルに実行されたデルタは共有空間の全メンバーに配布されて他のエンドポイントでも実行される。代表的には、エンドポイント間の通信ネットワークが完全に信頼できるのものではないので、ダイナミクス・マネージャ２２０は送信中に紛失したかも知れないデルタを再送する責任がある。ダイナミクス・マネージャ２２０はデルタへの依存性（ｄｅｐｅｎｄｅｎｃｙ）を使用していつデルタが紛失したかを検出する。ダイナミクス・マネージャ２２０はまた共有空間内で変更があった時に定期的にパルス（ｐｕｌｓｅ）を送信する。デルタと同様に、パルスも紛失デルタを検出するために使用できる依存関係を含んでいる。
【００４６】
ダイナミクス・マネージャ２２０はデルタが紛失したことを検出すると、共有空間内の他の１つまたはそれ以上のエンドポイントから紛失したデルタを回収しようと通常試みる。デルタは各エンドポイントのデルタ・ログと呼ばれるデータ構造内に格納されるので、他のエンドポイントは通常要求を満たし紛失デルタを再送することができる。ダイナミクス・マネージャ２２０は共有空間内のエンドポイントへ他から情報を配布できるようにするインタフェースも公開する。
【００４７】
ダイナミクス・マネージャ２２０は空間内で実行されたデルタ全部を含む前述のデルタ・ログを保持する。デルタ・ログは３つの理由から保持されている：収束を保証するためにデルタをロールバックする必要がある、デルタを別のエンドポイントが取り出す（以下、フェッチする）必要がある、またユーザがデルタを取り消したりやり直すことがある。ダイナミクス・マネージャ２２０はこれらの理由のどれかでデルタを保持しておく必要がいつなくなったかを検出する。その時点で、ダイナミクス・マネージャ２２０はパージ（ｐｕｒｇｅ）と呼ばれる処理でデルタ・ログからデルタを除去する。ダイナミクス・マネージャ２２０がもはやデルタを必要としないことを検出するためには、他のエンドポイント全部からのパルスを受信しなければならない。所定の期間あるエンドポイントがパルスを送信しないと、ダイナミクス・マネージャ２２０はそのエンドポイントが「遅い」と判定する。遅いエンドポイントは共有空間との接続が失われているように見えるエンドポイントとして定義される。一般に、共有空間からこのようなエンドポイントを一時的に除去して、デルタ・ログからデルタをパージし、デルタ・ログの大きさを減少できるようにするのが望ましい。他のエンドポイントもあるエンドポイントが遅いと判定した場合、遅いエンドポイントは共有空間から切断される。遅いエンドポイントがもう一度共有空間で活動するようになった場合、活動エンドポイントの一つから共有空間の新しいコピーを受け取る必要が出て来る。
【００４８】
デルタのデータ変更コマンドを作成して実行する処理には幾つかのステップが関係しコラボレーション・システムの多くのコンポーネントがこの処理に関係する。図３Ａと図３Ｂは並置した場合にデルタを作成してデルタを共有空間に挿入する際に関係する主なステップを示したフローチャートを構成する。このフローチャートは、デルタが生成されるソース・エンドポイントとデルタを送信する先の宛先エンドポイントのコンポーネントを含め、処理に関係する主なコンポーネントを示した図４との関連で説明されている。
【００４９】
ステップ３００で処理を開始してステップ３０２へ進み、ここでダイナミクス・マネージャ例えばソース・エンドポイント４００（デルタを作成するエンドポイント）のダイナミクス・マネージャ４２０がツール４１８の要求でデルタを作成する。ダイナミクス・マネージャ４２０はＸＭＬコードを使ってデルタを表現する。新規作成したデルタはデータ変更コマンド用の空のコンテナである。代表的なデルタの構造は、デルタの種類、デルタに含まれるコマンドの個数、コマンドを「取り消す」ことができる「取り消し」情報が存在するかどうかによって変化する。図５は一つのコマンドがあり取り消し情報がないデルタ５００の基本的なＸＭＬコード構造を示したもので、図６は二つのコマンドがあり両方のコマンドについての取り消し情報があるデルタ６００の基本的ＸＭＬコード構造を示す。代表的ＸＭＬ構造では、このＸＭＬコードは互いに入れ子になっている複数の階層要素で構成される。各要素はこれと特定の内容に関連する属性を備える。ＸＭＬコード全部がネームスペース（ｎａｍｅｓｐａｃｅ）にあり、ここで「ｇ」はＵＲＬ「ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ」を表わす。
【００５０】
ＬＤｅｌ要素５０２、６０２はローカルなデルタ要素でローカルなエンドポイントだけに関係する属性を持っている。そのため、このデルタ要素はデルタを他のエンドポイントへ送信する際に他のエンドポイントへ送信されない。これは幾つかの属性を持っている。属性はこれが関連のある場合にだけ要素に含まれるので、全ての属性が図５と図６に図示してあるわけではない。ＬＤｅｌ要素５０２、６０２の属性は、やり直しの目的で直前のデルタに関係する場合にセットされる（つまりデルタは一緒に取り消される）属性であるＡｓｓＰｒｅｖＧｅｎＤｅｌ属性を含む。ＢｌｋＤｅｌ属性は、現在のブロックでデルタが最高順位を持っている場合にセットされる。ＤｅｌｔａＴｏＲｅｄｏＩＰ属性はやり直しデルタにセットされる。やり直そうとするデルタの挿入ポイントにセットされる。ＤｏＥｒｒｏｒ属性は最後にデルタが実行されたときにエラーが発生した場合にセットされる。
【００５１】
Ｄｏｎｅ属性はエンドポイントでデルタを実行したときにセットされる。デルタが実行されなかった場合には存在しない。Ｒｅｄｏｎｅ属性はデルタが取り消されてからやり直した場合にセットされる。ＲｅＫｅｙｓ属性は他のエンドポイントへ送信するデルタを暗号化する際に使用されるデルタのキー情報を含む。これはこのデルタの作成者であるエンドポイントにだけ存在する。ＳｅｎｄｅｒＵＩＤ属性はダイナミクス・マネージャ４２０のフェッチ要求（ｆｅｔｃｈ  ｒｅｑｕｅｓｔ）の結果として受信したデルタについての送信者エンドポイントのユニークなＩＤにセットされる。
【００５２】
Ｓｅｓ属性は取り消し動作及びやり直し動作で使用されるデルタ・セッション（ｄｅｌｔａ  ｓｅｓｓｉｏｎ）である。これはデルタを生成したエンドポイントにだけ存在する。Ｕｎｄｏ属性はデルタが取り消しデルタである場合にセットされる。ＵｎｄｏＥｒｒｏｒ属性は最後にデルタを取り消そうとしたときにエラーが発生した場合にセットされる。Ｕｎｄｏｎｅ属性はデルタを取り消した時にセットされる。ＵＲＬ属性はそのデルタ用に指定されていればそのＵＲＬを格納する。このＵＲＬはメッセージＵＲＬとして使用されダイナミクス・マネージャがデルタの進行状況通知をサポートできるようになる。
【００５３】
ＬＤｅｌ要素５０２、６０２の内容はＤｅｌ要素５０４、６０４とＳＥＣ要素５０６、６０６を含む。Ｄｅｌ要素５０４、６０４は他のエンドポイントへ送信されるデルタ要素である。コマンド要素（又はコマンド要素群）だけが配布されることに注意する。すべてのコマンド取り消し情報は配布されない。ＳＥＣ要素５０６、６０６はセキュリティ要素でここにセキュリティ・マネージャ４１４がデルタ固有のセキュリティ情報を格納できる。
【００５４】
Ｄｅｌ要素５０４、６０４の属性には、ＡｄｄＥｐｔ属性を含み、これはこのデルタが共有空間へエンドポイントを追加した時にセットされる。ＡｄｄＮｅｗＥｐｔ属性はこのデルタが新規エンドポイントを共有空間へ追加した時にセットされる。この属性はアカウント空間が新規デバイスにインポートされたときだけ使用される。ＣＲ属性はデルタが作成される際にセットされるデルタの衝突領域を保持する。異なる衝突領域を持つデルタは一貫した実行順序を必要としない。衝突領域がないデルタは他の全てのデルタと衝突する。ＣＲ属性は文字列を含み、空文字列はそのデルタが他の全てのデルタと衝突することを意味する。二つの異なった領域が同一デルタにセットされている場合、衝突文字列は空にセットされデルタは他の全てのデルタと衝突するようになる。代表的には、各ツールはユニークな衝突領域を持ちこれをデルタにセットする。しかし、システム・ツール例えばセキュリティ・マネージャやメンバー・マネージャは衝突領域をセットせずこれらのデルタは他の全てのデルタと衝突する。どのツールもシステム・ツールのデータにアクセスすることがあるためこのことは重要である。
【００５５】
ＤｅｐＳｅｑ属性はデルタの依存性シーケンス（ｄｅｐｅｎｄｅｎｃｙ  ｓｅｑｕｅｎｃｅ）のセットである。これは依存性が暗示されるだけの場合には存在しない。依存性については以下で詳細に説明する。
【００５６】
Ｇｐ属性はデルタのグループ・ナンバーである。ＰｕｒＮｏｔ属性はデルタがパージされるときにデルタのコマンドの一つを作成したエンジンへ通知する必要があればセットされる。Ｓｅｑ属性は後述するようにデルタのシーケンス番号を保持する。Ｖｅｒｓｉｏｎ属性はデルタを作成したダイナミクス・マネージャ４２０のバージョンを保持する。
【００５７】
Ｄｅｌ要素５０４、６０４の内容は、一つのコマンドしかなければコマンド要素５０８、または１つ以上のコマンドが存在する場合にはコマンド群要素６０８を含む。コマンド要素５０８にはコマンドの内容を含む内容セクションが続き、コマンド群要素６０８にはデルタ内の各コマンドに対するコマンド要素６１０、６１２を含む内容セクションが続く。デルタが一つしかコマンドを持たない場合、コマンド要素５０８はデルタ要素の直子である。デルタが複数のコマンドをもつ場合、これらはデルタの直子であるコマンド群要素６０８に含まれる。Ｃｍｄ要素５０８、６１０、６１２は各々デルタ内のコマンドを表わす。これらの要素の内容と属性の大半はコマンドを作成したエンジンがセットする。属性にはコマンドを作成したエンジンのＵＲＬをセットするＥｎｇｉｎｅＵＲＬ属性を含む。ＰｕｒＮｏｔ属性はコマンドをパージするときにコマンドを作成したエンジンが通知を必要とするならセットされる。
【００５８】
コマンドの取り消し情報がない場合には、空のコメント「＜！−−−＞」５１０をプレース・ホルダー（ｐｌａｃｅ  ｈｏｌｄｅｒ）として使用する。取り消し情報がある場合、ＣｍｄＵ要素６１４、６１６がデルタのコマンドの一つについてのコマンド取り消し情報を保持する。この要素の内容と属性はコマンドを実行したエンジンがセットする。
【００５９】
デルタを作成する際、大きな一貫したＸＭＬドキュメント４４０内の無所属のまたは親のないＸＭＬコード・フラグメントがダイナミクス・マネージャ４２０の中でデルタを表現する。ドキュメント４４０の代表的なＸＭＬ表現が図７に図示してある。ＸＭＬドキュメント７００はダイナミクス・マネージャ・ドキュメントのルート要素（ｒｏｏｔ  ｅｌｅｍｅｎｔ）であるＥｎｇｉｎｅＤａｔａ要素７０２を含む。この要素の内容は多数の他の要素を含む。これらにはブロックされる全てのデルタの親であるＢｌｏｃｋｅｄＤｅｌｓ要素７０４を含む。この要素はブロックされるメッセージの親として使用される。これは別の要素からのパルス要素を保持するＥｐｔＰｕｌ要素と、ローカルエンドポイントに固有の情報を含むデルタを表わすＬｏｃａｌＤｅｌ要素を含む。ＣｍｄＵ要素７０６は読み出し専用の空コマンド取り消し要素として用いる。これは明示的な取り消し情報を持っていない全てのコマンドで取り消し要素として使用される。ＣｍｄＵ要素の属性と内容はコマンドを実行するエンジンに固有である。
【００６０】
ときとしてダイナミクス・マネージャ４２０は後に余分だと判定されるＣｍｄＵ要素を作成することがある。これらのＣｍｄＵ要素は将来使用するためＣｍｄＵＰａｒｅｎｔ要素に格納される。例えば、ＣｍｄＵＰａｒｅｎｔ要素７０８、７１０は余分なＣｍｄＵ要素の親として使用される。ＤｅｌＨｌｄｒ要素７１２は「デルタ・ホルダー」４４２と呼ばれるデータ構造を表現するために使用される。この構造については以下で詳細に説明する。同様に、ＤｅｌＬｏｇ要素７１４は「デルタ・ログ」４３８と呼ばれるデータ構造を表現する。これも以下で詳細に説明する。
【００６１】
ＤｉｓｃｏｎｎｅｃｔＮｏｔｉｆｉｃａｔｉｏｎｓ要素７１６は到着する切断通知の一時的な親として使用される。Ｄｉｓｓｅｍｉｎａｔｏｒ要素７１８は他のエンドポイントへ送信又は「配布」（ｄｉｓｓｅｍｉｎａｔｅ）されるのを待っている要素を表わすために使用される。この構造についても以下で詳細に説明する。Ｅｐｔｓ要素７２０は共有空間内のエンドポイントを表現するために使用する。これも以下で詳細に説明する。ＩｎｂｏｕｎｄＤｅｌｔａｓ要素７２２はダイナミクス・マネージャ４２０への到着メッセージの一時的キュー（ｑｕｅｕｅ）として使用されるもので、以下で詳細に説明する。これは全部のエンドポイントで共通のデルタの一部を表わすＤｅｌ要素、別のエンドポイントからの切断通知を保持するＤｉｓＮｔｆｙ要素、別の要素からのパルス要素を保持するＥｐｔＰｕｌ要素、ローカル・エンドポイントに固有の情報を含むデルタを表わすＬｏｃａｌＤｅｌ要素を含む。
【００６２】
ＥｎｇｉｎｅＤａｔａ要素７０２の属性は、ダイナミクス・マネージャ４２０をブロック状態に移行させるデルタの挿入ポイントを保持するＢｌｏｃｋｅｄ属性を含む。ＢｌｏｃｋｅｄＣｏｕｎｔ属性はダイナミクス・マネージャ４２０がブロックされた回数のカウントを保持する。Ｄｉｖｅｒｇｅｎｔ属性は共有空間のダイナミクス・マネージャ４２０が共有空間の他のメンバーから発散する（ｄｉｖｅｒｇｅｎｔ）場合にセットする。この属性は発散する理由を表わす文字列がセットされる。ＬａｓｔＥｐｔＰｕｌｓｅ属性はローカルエンドポイントがパルス・メッセージを最後に送信した時刻を保持する。ＰｕｒｇｉｎｇＤｉｓａｂｌｅｄ属性はパージが無効の場合にセットされる。ＵｎａｃｋｅｄＤｅｌ属性はパルスによって肯定応答されないデルタが存在する場合にセットする。以下で詳細に説明するように、最後の３つの属性は前述のデルタ・ログが定期的にパージされる際に使用される。ＰｉｎｇＳｅｑ属性はリレー・サーバ（ｒｅｌａｙ  ｓｅｒｖｅｒ）に最後に接触した時刻を表わすシーケンス番号を保持する。Ｕｎｉｎｖｉｔｅｄ属性はローカル・エンドポイントが共有空間から招待されていないときセットされる。Ｖｅｒｓｉｏｎ属性はダイナミクス・マネージャ・データ・モデルのバージョンを保持する。最後に、Ｗａｔｅｒｍａｒｋ属性はトランザクション（ｔｒａｎｓａｃｔｉｏｎ）が中止されたときに検出することで永続状態と一貫するようにローカル・キャッシュ（ｌｏｃａｌ  ｃａｓｈ）の状態を保持するために使用する。
【００６３】
この永続的ＸＭＬドキュメント４４０はストレージ・マネージャ２１６によって保持される。本発明で使用するのに適したストレージ・マネージャ２１６は前述の米国特許出願第０９／５８８，１９５号に詳細に記載されている。永続的ＸＭＬドキュメント４４０を作成することに加え、ダイナミクス・マネージャ４２０はデルタを表わすＣＯＭオブジェクトを作成する。後者のオブジェクトはツール４１８が使用してコマンドをデルタに追加したりデルタのプロパティ（ｐｒｏｐｅｒｔｙ）をセットする複数のインタフェースを実装する。
【００６４】
デルタの作成は共有空間に関係するトランザクション・データベースでのトランザクションを自動的に作成する（図示していない）。トランザクションは共有空間データベースにアクセスする排他的メソッドを提供し、特定デルタの結果として開始されたあらゆる変更を完全に取り消すことが可能になる。トランザクションは、これを作成したデルタが中止された場合又は何らかのエラーがデルタ実行中に発生した場合中止される。トランザクションはデルタがコミット（ｃｏｍｍｉｔ）され実行が成功したときにコミットされる。
【００６５】
次に、ステップ３０４で、ツール４１８はデルタ・コンテナへ、直接又は後述するように「入れ子で作成した」デルタを使用して、１つまたはそれ以上のデータ変更コマンドを追加する。コマンドはエンジン４３０等のエンジンで作成・実行される変更の単位であり、デルタはこれらのコマンドが全部常時一緒に実行されることを想定したコマンドのグループである。したがって、デルタはデルタ内のコマンド全部が実行されるかどれも実行されないかという意味で最小単位（ａｔｏｍｉｃ）である。この規則には一つの例外があり、これはコマンド実行中の例外処理中に発生するが、これについては後述する。
【００６６】
デルタと共に作成されデルタを表わすＣＯＭオブジェクトのインタフェースによりコマンドをデルタに追加できる。コマンドはダイナミクス・マネージャ４２０を使って、ＸＭＬデルタ・ドキュメント内のデルタを表わす前述のＸＭＬフラグメント内部に空のコマンドＸＭＬ要素（Ｃｍｄ要素）を作成することで追加される。デルタを作成した時点で、ダイナミクス・マネージャ４２０にはコマンドを後で実行するエンジン４３０等のエンジンの結合可能（ｂｉｎｄａｂｌｅ）なＵＲＬが提供される必要がある。図４には一つのエンジン４３０しか図示していないが、複数のエンジンが存在し得ることは当業者には理解されよう。以下の説明で、エンジン４３０はこれらのエンジン全部を表わすために用いる。このＵＲＬはエンジンのユニークな名前であり、ダイナミクス・マネージャは後で必要になったときにエンジンを見つけ出すことができる。前述のＥｎｇｉｎｅＵＲＬ属性は適用可能なＸＭＬコマンド要素にセットされる。デルタの作成者はコマンドの実行に必要とされる属性や内容を追加できる。例えば、スケッチパッド（ｓｋｅｔｃｈｐａｄ）を実現するエンジンはオブジェクトを描画するコマンドを持つことになる。ユーザがスケッチパッド上にオブジェクトを描画する場合、オブジェクトの形状、色、位置を記述する属性を備えたコマンドが作成される。このコマンドが実行されると、デルタを作成したソース・エンドポイントと遠隔地の宛先エンドポイントの双方で、コマンドの変更がエンジン４３０に関連するデータ・モデル４３２に適用される。
【００６７】
デルタへコマンドを追加する別の方法は、「入れ子で作成した」（ｃｒｅａｔｉｏｎ  ｎｅｓｔｅｄ）デルタによるものである。入れ子で作成したデルタはコンポーネントを統合して更に複雑なツールを作成する簡単な方法である。例えば、ツールは他のツールかも知れない多数の他のコンポーネントを使用できる。ユーザがツールにアクション（ａｃｔｉｏｎ）を起すと、そのツールはデルタ・コンテナを作成する。このツールは他のコンポーネントを呼び出してデルタ・コンテナへコマンドを追加する。デルタへコマンドを直接追加する代わりに、ツールは別のデルタを作成してこの新規デルタを最初のデルタに追加することができる。このデルタの作成は別のデルタの作成に入れ子になっているので、入れ子で作成されたデルタと呼ばれる。例えば、デルタ作成中のステップのセットは、次のようになる。
デルタ１作成
コマンドＡ追加
デルタ２作成（これが入れ子状態に作成されている）
コマンドＢ作成
デルタ２コミット
コマンドＣ追加
デルタ１コミット
【００６８】
両方とも取り消し情報を持つ二つの入れ子で作成されたデルタを含むデルタ８００のＸＭＬ構造が並置される図８Ａと図８Ｂに図示してある。入れ子で作成されたデルタは標準デルタと同じ要素を持ち、コマンド要素に対する幾つかの変化がある。例えば、Ｃｍｄ要素のＮｅｓｔｅｄ属性はコマンドが入れ子で作成されたデルタの一部として作成された場合にセットされる。Ｎｅｓｔｅｄ属性は入れ子で作成されたデルタのＩＤをセットする。さらに、ＮＯｒｄ属性はＣｍｄ要素で入れ子になったデルタ内部のコマンドの順序にセットされる。
【００６９】
以下で説明するように入れ子で作成されたデルタがコミットされると、入れ子でないデルタの場合と同様にデルタ内のいずれのコマンドも実行される。しかし、コマンド実行後にデルタ・ログ４３８にデルタを保存するのではなく、ダイナミクス・マネージャ４２０が外包デルタ（ｃｏｎｔａｉｎｉｎｇ  ｄｅｌｔａ）の先頭へ自動的にコマンドと取り消し情報を追加する。外包デルタが中止されると、入れ子で作成されたデルタのコマンドも中止される。外包デルタがコミットされると、入れ子で作成されたデルタのコマンドはすでに実行されており更に実行されることはない。最終外包デルタのコマンドはこれらが実行される順序になっていることに注意する。コマンドを格納しているデルタが実行されるまで実行されないため、上記デルタ１のコマンド実行順序はＢ、Ａ、Ｃになる。
【００７０】
ツール４１８等のツールがデルタへのコマンド追加を完了したら、ツール４１８はステップ３０６でデルタをコミット又は中止できる。デルタが中止されると、コマンドはどれも実行されず、デルタが作成されたときに開始したトランザクションも中止される。この場合それ以上何も起こらないので、デルタはステップ３０６でコミットされるものと仮定する。デルタがコミットされた場合、残りのステップは実際にローカル・エンドポイントでコマンドを実行してデルタ及びこれのコマンドを宛先エンドポイントへ配布する。デルタが作成されたときに開始されたトランザクションはデルタが実行されて配布待ち行列に入る後までコミットされない。
【００７１】
次に、ステップ３０８で、ダイナミクス・マネージャ４２０は新規にコミットされたデルタがデルタ・ログ４３８のどこに挿入されるかを決定する。デルタ・ログはＸＭＬデータ構造で、実際にはダイナミクス・マネージャ４２０のＸＭＬドキュメント４４０の一部である。この構造は並置される図９Ａと図９Ｂに図示したような代表的なＸＭＬコード構造を持っている。
【００７２】
デルタ・ログＸＭＬ構造はデルタ・ログを表わすＤｅｌＬｏｇ要素９０２を含む幾つかの要素で構成される。ＤｅｌＬｏｇ要素９０２は幾つかの要素を備え、これにはパージされたが未だ削除されていないグループが存在するときにセットされるＮｅｅｄＴｏＤｅｌｅｔｅ属性を含む。ＰｅｎＧｒｐＮｕｍ属性はパージを保留している、つまりパージの候補として宣言された最高順位グループの番号を保持する。ＰｕｒＧｒｐＮｕｍ属性はパージされた最高順位グループの番号を保持する。
【００７３】
ＤｅｌＬｏｇ要素９０２は内容として他の要素も含む。これらには、１つまたはそれ以上のＤｅｌＢｌｋ要素９０４、９２２を含み、この内の各々がデルタのブロック（以下、デルタ・ブロック）を表わす。デルタ・ブロックは後述するように優先デルタを実現するために使用する。ブロック内で、デルタはグループに構成される。各ブロックは、グループがブロック内にデルタを含まない場合でも、ブロック内の第一グループからブロック内の最高グループまでの各グループについての内容要素を有している。
【００７４】
各ＤｅｌＢｌｋ要素、例えば要素９０４は１つまたはそれ以上のＤｅｌＧｒｐ要素９０６、９１０、９１４を含み、その各々がデルタのグループ（以下、デルタ・グループ）を表現する。デルタ・グループはチェーンに構成されたデルタのセットである。グループ内の各チェーンには一つのＸＭＬ要素がある。チェーンはチェーンを作成したエンドポイントの作成者ＩＤの昇順に配列される。ＤｅｌＧｒｐ要素９０６は二つの属性を持つことができる：即ち、次のグループが作成された時刻を保持するＤｏｎｅＴｉｍｅ属性と、グループの番号を保持するＮｕｍｂｅｒ属性である。
【００７５】
各ＤｅｌＧｒｐ要素、例えば要素９０６はデルタのチェーンを表わす１つまたはそれ以上のＤｅｌＣｈｎ要素９０８を含む。各ＤｅｌＣｈｎ要素９０８はチェーンの作成者のＩＤを保持するＣｒｅａｔｏｒＩＤ属性を有する。各ＤｅｌＣｈｎ要素９０８は１つまたはそれ以上のＬＤｅｌＣｈｎ要素９１０を含み、その各々がデルタを表わす。
【００７６】
デルタ・ログ４３８の全ての位置にはユニークなアドレスがあり、これを「挿入ポイント」と呼ぶ。新規デルタは必ずデルタ・ログ４３８の末尾に挿入され、その結果として、新規デルタを挿入するためデルタ・ログ４３８の末尾に対応する挿入ポイントが決定されなければならない。一つの実施態様において、各挿入ポイントはグループ番号、作成者ＩＤ、シーケンス番号の組み合わせで構成される。さらに、作成者ＩＤはエンドポイントＩＤと乱数作成者ＩＤの組み合わせで構成される。エンドポイントＩＤは例えばデバイスＵＲＬとエンドポイントのコンタクトＵＲＬの組み合わせ（例えばハッシュ（ｈａｓｈ））で、エンドポイントのユニークな識別子である。エンドポイントが共有空間をオープンする度に、エンドポイントには新しい乱数作成者ＩＤが割り当てられる。この作成者ＩＤはデルタ・ログに新規デルタを挿入する間に同一エンドポイントで作成されたデルタと衝突が発生しないようにすることを目的としている。これらの衝突はシステム・クラッシュあるいは共有空間へ再招待した場合に発生することがあり、そのエンドポイントが作成した以前のデルタの内部レコードを失わせることになる。
【００７７】
作成者ＩＤが決定したら、グループ番号を決定できる。ここで説明し又前述した特定の実施態様において、デルタ・ログ４３８はチェーンにデルタを収集しチェーンをグループに収集する。チェーンは所定の最大個数のデルタまで同一作成者が作成したデルタで構成される。グループ番号を決定するため、ダイナミクス・マネージャ４２０はまず、新規にコミットされたデルタを形成された最後のチェーンに追加できるかどうか、すなわちチェーンが作成者からのデルタを含むかどうかとチェーンにすでにあるデルタが最大個数以下かどうかを判定する。デルタを最後のチェーンに追加できる場合、グループ番号は最後のチェーンを含むグループの番号である。デルタを追加できない場合、新規チェーンを作成する必要がある。
【００７８】
次に、新規チェーンを現在のグループ内に作成できるかどうか、または新規グループを作成する必要があるか、判定する必要がある。本実施態様では、各グループ内部で、チェーンは作成者ＩＤによる昇順になる必要がある。新規デルタの挿入点はデルタ・ログ４３８の末尾でなければならないため、新規デルタの作成者ＩＤはデルタ・ログの最後のチェーンの作成者ＩＤと比較されなければならない。これがより大きい場合には新規チェーンを最後のグループに追加でき、そのグループの番号はデルタのグループ番号である。
【００７９】
それ以外の場合、新規グループを作成する必要がある。新規グループ及び新規デルタは直前のグループより１だけ大きい番号を持つ。最後に、シーケンス（ｓｅｑｕｅｎｃｅ）番号を決定する。作成者によって作成された第一のデルタはシーケンス番号「１」を持っている。作成された後続の各デルタは直前のデルタより１だけ大きいシーケンス番号を持つ。
【００８０】
作成者ＩＤとシーケンス番号は、まとめて、「デルタ・シーケンス」と呼ぶ番号である。グループ番号はデルタ・シーケンスと連結され、挿入ポイントを作成する。インデックスの作成を容易にするため、グループ番号とシーケンスはデルタの別々の属性として格納される。
【００８１】
ステップ３０８で、挿入ポイントはデルタ属性の計算値を含めることでデルタに「スタンプ」（ｓｔａｍｐ）されるが、デルタはこの時点でデルタ・ログ４３８には実際に挿入されていない。ある種の特殊なコマンド例えば共有空間へメンバーを追加する等でデルタ挿入ポイントを使用するため、挿入ポイントはデルタに含まれる必要がある。この時点でデルタ・ログ４３８の正しい場所にデルタを実際に入れることが理論上可能であろうが、「取り消しデルタ」のコマンドを実現するのが大幅に難しくなる。
【００８２】
挿入ポイントをスタンプしたら、ステップ３１０で、ダイナミクス・マネージャ４２０はデルタのコマンドを実行する（このプロセスを「デルタの実行」と呼ぶ）。このステップを実行するため、ダイナミクス・マネージャ４２０はコマンド要素の全部について反復を実行するエンジンの結合可能なＵＲＬを含む属性をオープンする。ダイナミクス・マネージャ４２０はそのエンジンに結合する、この過程でＵＲＬを取り出しそのＵＲＬに関連しているエンジンを検出する。ダイナミクス・マネージャ４２０がエンジン（例えばエンジン４３０）を特定したら、エンジン４３０を呼び出してコマンドを実行させる。エンジン４３０にコマンドを記述するコマンド要素を提供する以外に、ダイナミクス・マネージャ４２０はエンジン４３０へ空のコマンド取り消し要素も提供する。エンジン４３０はこの要素を使って、後でコマンドの取り消しまたは実行の逆転に必要になるかも知れない情報を格納する。エンジン４３０がコマンド取り消し要素に情報を追加した場合、この要素はデルタに格納される。性能上の理由で、エンジン４３０が取り消し要素に情報を格納しない場合にはダイナミクス・マネージャ４２０は空のコメントをデルタ内の取り消し要素のプレース・ホルダー（ｐｌａｃｅ  ｈｏｌｄｅｒ）として使用する。
【００８３】
コマンド実行で行なわれるステップはコマンドを実行するエンジンと実行されるコマンドにより変化する。エンジン４３０はコマンドを実行し永続データ・モデル４３２に変更を適用する。エンジン４３０はまた変更を行なったことを非同期的に通知する「助言」も作成する。コマンド取り消し要素に取り消し情報を追加することもあり、この取り消し情報はコマンドを将来取り消さなければならない場合に必要とされる。各エンジン４３０はアクセス制御チェックを実行してデルタ作成者がこのコマンドを実行する許可を有していることを確認する。このチェックはコマンドが実行される前に各エンドポイントで行なわれる。いずれかのエンドポイントが許可を持っていない場合には、エンジン４３０は後述するように処理される例外を発生することができる。
【００８４】
さらに、エンジン４３０は実行が入れ子になったデルタを作成できる。実行が入れ子になったデルタは別のデルタの中のコマンドの実行中に作成される。実行が入れ子になったデルタは入れ子で作成されたデルタと類似しているが、外包デルタが作成される時点ではなく、外包デルタのコマンドが実行されている間に作成される点で違う。前述したように、入れ子で作成されたデルタを実行する場合、コマンドと取り消し情報が外包デルタに追加される。しかし、実行が入れ子になったデルタが実行される場合、これが含むコマンドやこの含まれているコマンドに対する全ての取り消し情報は外包デルタの取り消し情報に格納される。
【００８５】
入れ子で作成されたデルタはこのデルタを作成するソース・エンドポイント４００でのみ作成され、そのコマンドは外包デルタを実行する全てのエンドポイントで自動的に実行される。これとは対照的に、実行が入れ子になったデルタは外包デルタを実行する全てのエンドポイントで作成されるのが普通である。これらのコマンドは配布されないので、外包デルタを実行する各エンドポイントで生成される必要が出てくる。例えばデルタを実行するメンバーの役割の相違のため、デルタの実行は別のエンドポイントで別の作用を有する。このような場合、取り消し情報は異なり、実行が入れ子になったデルタ（以下、実行入れ子デルタ）は作成される必要がないか、または違うことがある。外包デルタによるチェックで充分なため実行入れ子デルタでのアクセス制御チェックは行なわない。
【００８６】
デルタが取り消される場合、ダイナミクス・マネージャ４２０は実行入れ子デルタを作成したコマンドを取り消す前に実行入れ子デルタを全て取り消す。
【００８７】
コマンド実行中に発生する例外はダイナミクス・マネージャ４２０が処理する。デルタを作成したソース・エンドポイント４００でデルタが実行されている場合の例外処理は簡単である。この例外はデルタをコミットしようとするツール４３０に渡される。このデルタの一部としてすでに行なわれた全ての変化が取り消されるように注意する。これらの変化が取り消されたことを確実にするため、ダイナミクス・マネージャ４２０は各コマンドの実行前後に「トランザクション」を作成する。コマンド実行中に例外が発生した場合、そのコマンド前後のトランザクションが中止される。後者の処理はコマンドの部分的実行の結果としてなされた全ての変更を取り消す。
【００８８】
その後、ダイナミクス・マネージャ４２０は他の適当なエンジンを呼び出してデルタの一部としてすでに実行された他のコマンドを全て取り消す。これらの呼び出しで、エンジンは共有空間の一部でない何らかの情報を取り消すことができ、その結果、ダイナミクス・マネージャ４２０がデルタ全体を含むトランザクションを中止したときに自動的に取り消されない。各コマンドの実行前後のトランザクションに加え、ダイナミクス・マネージャ４２０はトランザクション内で各デルタを実行する。うまく実行されたコマンドを取り消すためにエンジンが呼び出されたら、ダイナミクス・マネージャ４２０は後者のトランザクションも中止する。このトランザクションは、デルタの一部としたなされた共有空間内の全ての変更で正しく取り消されていない変更が自動的に取り消されるように保証する。例外を有するデルタの一部としてなされた変更が取り消されたことをダイナミクス・マネージャ４２０が確認したら、デルタのコミットを試みたツール４３０に本来のエラーを渡す。
【００８９】
実行後、ステップ３１２で、ダイナミクス・マネージャ４２０は新規デルタをデルタ・ログ４３８に追加する。このステップはステップ３０８でダイナミクス・マネージャ４２０がすでにデルタの正しい挿入ポイントを判定しているので簡単である。処理は、頁間接続３１４、３１６を経由して、ステップ３１８へ続く。
【００９０】
前述のように、コラボレーション・システムの重要な特性は「前後関係（ｃａｕｓａｌｉｔｙ）」で、これは第一のコラボレータから受信した現在のデータ変更コマンドを第２のコラボレータが実行するとき、第２のコラボレータは現在のデータ変更コマンドを作成したときに第一のコラボレータが実行した全ての先行するデータ変更コマンドを実行していることを要求する。ダイナミクス・マネージャ４２０によって提供される主要な特性の一つは「先行実行」である。詳しく説明すると、ダイナミクス・マネージャ４２０は、デルタが作成されたときにデルタの作成者によって実行された全てのデルタをエンドポイントがすでに実行していない限りデルタをエンドポイントが実行しないように保証する。先行実行を保証するため、各デルタはステップ３１８で依存性（ｄｅｐｅｎｄｅｎｃｙ）を内蔵する。
【００９１】
デルタの依存性はデルタを作成したエンドポイントで実行された先行する全てのデルタを記述する。例えば、以下の５つのステップで実行するトランザクションを考えてみる：
１）エンドポイントＡがデルタＡ１を作成する。
２）エンドポイントＡがデルタＡ２を作成する。
３）デルタＡ２を受信後、エンドポイントＢはデルタＢ１を作成する。
４）デルタＢ１を受信後、エンドポイントＡとＢは同時にデルタＡ３とＢ２を作成する
５）デルタＡ３とＢ２を受信後、エンドポイントＣがデルタＣ１を作成する。
【００９２】
この状況では、各デルタ例えばデルタＡ２について、２がシーケンス番号でＡが前述した作成ＩＤの簡略表記を意図している。つまり、表記Ａ２はデルタのシーケンスを表わす。「同時」作成は、デルタＢ２を受信する前にエンドポイントＡがデルタＡ３を作成し、デルタＡ３を受信する前にエンドポイントＢがデルタＢ２を作成することを意味している。こうして得られたデルタは「非依存」であると言われる。
【００９３】
依存性を表わす一つの方法としては、それまでに実行された全デルタのデルタ・シーケンスを各デルタにスタンプ（ｓｔａｍｐ）することである。前述の例でこれを行なうと、各デルタの依存性のセットは次のデルタ・リストで括弧内に示されるようになる。
Ａ１  ｛｝
Ａ２  ｛Ａ１｝
Ｂ１  ｛Ａ１，Ａ２｝
Ａ３  ｛Ａ１，Ａ２，Ｂ１｝
Ｂ２  ｛Ａ１，Ａ２，Ｂ１｝
Ｃ１  ｛Ａ１，Ａ２，Ｂ１，Ａ３，Ｂ２｝
【００９４】
更に多くのデルタが作成されると、依存性のセットはどんどん長くなる。依存性の個数を減少させるため、暗示される依存性は排除する。例えば、デルタＢ１はデルタＡ２に依存しデルタＡ２はデルタＡ１に依存している。したがって、デルタＢ１のデルタＡ１に対する依存はすでにデルタＢ１のＡ２に対する依存性で暗示されている。これらの暗示される依存性の排除によってデルタについて以下のような明示的依存性が得られる：
Ａ１  ｛｝
Ａ２  ｛Ａ１｝
Ｂ１  ｛Ａ２｝
Ａ３  ｛Ｂ１｝
Ｂ２  ｛Ｂ１｝
Ｃ１  ｛Ａ３，Ｂ２｝
【００９５】
更に最適化すると、同じ作成者からの先行デルタに対するデルタの暗示的依存性を仮定できる。例えば、デルタＡ２は暗示的にデルタＡ１に依存していると仮定できる。この更なる最適化によってこれらのデルタで得られる依存性は次のようになる：
Ａ１  ｛｝
Ａ２  ｛｝
Ｂ１  ｛Ａ２｝
Ａ３  ｛Ｂ１｝
Ｂ２  ｛｝
Ｃ１  ｛Ａ３，Ｂ２｝
【００９６】
あるデルタが例えば非依存デルタの場合等に複数の依存性を持つ必要があることに注意する。例えば、後者の依存性リストでは、デルタＣ１はデルタＡ３とＢ２の双方に依存しているが、これら二つのデルタには何の関係もないため、デルタＣ１はこれら両者への依存を明示的に含める必要がある。
【００９７】
あるエンドポイントで作成された次のデルタの依存性リストを維持するのは簡単である。ダイナミクス・マネージャ４２０は新規依存性のセットを維持する。新規デルタがコミットされるか又は同化（ａｓｓｉｍｉｌａｔｅ）される度に、新規デルタの全ての依存性を除去し新規デルタを追加することでこのセットを更新する。例えば、前述の例に別のエンドポイントＤが存在する場合、新規依存性のセットは他のエンドポイントＡ、Ｂ、Ｃで作成されたデルタ各々の受信後に次のようになる：
Ａ１  ｛Ａ１｝
Ａ２  ｛Ａ２｝
Ｂ１  ｛Ｂ１｝
Ａ３  ｛Ａ３｝
Ｂ２  ｛Ａ３，Ｂ２｝
Ｃ１  ｛Ｃ１｝
【００９８】
エンドポイントＤがデルタＣ１を受信後に新規デルタを作成した場合、デルタＣ１は新規デルタの明示的依存性だけとなる必要がある。新規デルタに依存性を追加する時点で、同じ作成者からの先行デルタに対する全ての依存性をチェックするが、その理由は、この依存性は必ず暗示されるからである。
【００９９】
各デルタが他のコラボレータに送信される前に、デルタは「機密化」されなければならない。これにはデルタの暗号化と完全性保護が関与する。これらの操作は比較的複雑で時間がかかるので、ダイナミクス・マネージャ４２０は共有空間データベースにトランザクションがない時にこれらの操作を非同期的に（実行の主軸上ではなく）行なう。これにより共有空間での他の操作に暗号化が干渉しなくなる。デルタを非同期的に機密化するには、この時点でデルタに何らかの機密に関する情報（以下、機密情報）を格納する必要がある。この機密情報はセキュリティ・マネージャ４１４によってデルタを機密化するために後で使用される。ステップ３１９で、ダイナミクス・マネージャ４２０はセキュリティ・マネージャ４１４を起動しデルタの暗号化に後で必要になる情報を格納させる。
【０１００】
非同期暗号化と他のコラボレータへのデルタ転送（「配布」と呼ばれる）は実際にはダイナミクス・マネージャ４２０の配布コンポーネント４２５で実現される。このコンポーネント４２５はＸＭＬドキュメント４４０の配布キュー要素４２６を含み、配布されるべきデルタやその他のメッセージが待ち行列に入れられる。新規デルタのシーケンス番号に属性をセットしてある要素はステップ３２０で配布キュー要素４２６で待ち行列に入れられる。待ち行列に入れることでイベント（ｅｖｅｎｔ）が生成され、このことにより、ダイナミクス・マネージャ４２０が実行の別のスレッド（ｔｈｒｅａｄ）で非同期的に呼び出されて実際に配布を行なうようにする。ダイナミクス・マネージャ４２０が後で非同期的に呼ばれたとき、配布コンポーネント４２５を呼び出して待ち行列４２６にある全てのデルタを処理する。配布コンポーネント４２５は要素を行列から取り出し、シーケンス番号属性を読み取り、デルタ・ログから対応するデルタをオープンし、これを処理する。デルタが非同期処理のため待ち行列に入れられた後で、デルタが作成された時に開始した共有空間データベースのトランザクションがコミットされる。
【０１０１】
各デルタは他のコラボレータへ送信される前に暗号化及び完全性保護により機密化される。暗号化によりデルタメッセージを傍受した誰かが有用な情報を得られないようにする。完全性保護は第三者がデルタを改竄したかどうかダイナミクス・マネージャが検出できるようにする。デルタを処理する時点で、ダイナミクス・マネージャ４２０の配布コンポーネント４２５はステップ３２２でセキュリティ・マネージャ４１４を使用してすでに格納された情報でデルタを機密化する。デルタは２段階処理で機密化される。第一の段階は共有空間データベースをロックして開始する。この段階の間関連する機密情報例えばキーは共有空間データベースから読み出される。第２の段階は共有空間データベースのロックなしに行なわれ、デルタが実際に暗号化される。
【０１０２】
デルタの一部だけが他のコラボレータに送信され、その部分だけが機密化される。ローカル・デルタ要素の中にある情報は配布も機密化もされない。またローカル・エンドポイント４００だけに関係する全てのコマンド取り消し情報も配布されず機密化されない。デルタを機密化することで、グループ番号、シーケンス番号、依存性を含むデルタ要素それ自体は、暗号化しないままにする（しかし完全性は保護される）。この情報はデルタを復号する前に必要とされるので暗号化しないで送信する必要がある。コマンド要素は暗号化され機密処理の内容として送信される。ローカル・デルタ要素もセキュリティ・マネージャ４１４が使用してそのデルタのために格納されるべきあらゆるローカル・データを格納する内容要素を有している。機密化されたデルタは次のように見える：
<urn:groove.net: Del CR="Ywyi5Fkw" DepSeq="6C58D518236030D3BEA50001" Gp="352" Seq="1E3F58465D4741E945370003" Version="1,0,0,0">
<urn:groove.net: SE Version="3,0,0,0">
<urn: groove.net: EC EC
="mk1Bja1etosZFG0tnsUPsJN7Nud4Zlz86op+M0jcj8OjwQEVbTXrJBR8PnakL7icF0S7qLMRwUj7yloV2C5lAjXGvP/zM1XF2pUPYHJSh+PryjxmQ9w+EltEn0ll1vyP9RzN7NeN2v/l/mrhzeSv6Y9awd+qTWhf1luZ4TLV6mV9S6i1GVl9VnKoD0M2wpP+CsK9Gek0tKguhK4mTYspQgAvBGOdjoqf5J1qvGUWmly1C9eWjrCMP7+V9k2SqXgOzTffGM1ExsytVl4kKin5eazhNl49JDPGuB5cgFRXzAi9s1dhlZWX1q4VA24UhfTpOL6cet7JhqMN04gBDvu6tbUTlpcS9BtsMKHtv3EZVlap80C/tiAel5X+NKGSJaZher7rMJjPdxNjx9M4jur5jUrUK6xMRnnxcHPD1vj1pVjP5UR2flC1hFeKPaZ13QyJcB10lSaGg1yvTDrLqw6jMzF6nSL7rLtLMz+iMvxmmQCk9aLB7UuudZ0ygp4eOjnOep+C0EipOyWGUCb8kNSKhn4PcGCSjdPc2jJVXa9nw4BAkCeVkpESMUaXpGhcYtSBbATxCNDzrYYm0HVUAXhknQAAHwP0C2zjq5Tze71V4vpz+cbANOYs2zCcfndohCV+tTClbwPc+kzgbbWqmciJsd+QulwmdV4opZD/1STQaM9iC9hRRpvo4dg69M3xX1CUNDkOwGD0tcfU+k00NgU5ja7+qUp2Uxa15Kk0pJxEfsysd2QY2bak8aaEFR9AvcWlEwl2Ubcr+y8aRJTJqMY9jmvz2ZlEdSYU7qmVpbT7ncNcxQ0olXbD9s++PVC+nNSEQXH4WSABLDDpKcFgpqpQLWk1Ra+lKpfPtGmfmYnqveKM/d1x/oKwfMa4zxo9qhvJQd55KrTjl7knH08ZalKiNbanfVilylPn9HJxF6Gsyn+cQTgstmcN0hKHyAmAraOe54ydGChH9W3rGT8RVtJxbz+BhpTMIUCqP4ehFqtjsESGUV4iLFHNg4UpKXd4H8b61w4ZpHakVPgtaqRhrpVgzgeTu0QhRQ9Ug3HE6koNwQKcW8dhVCZbCorVW6mR3PhzGO3R358+zlXTwNfXxlnRhwA5L6kHnZJywjEjeZb2hGDUtyWVhc"
IV="0dERdZ3iJCWDlo1WeZbmEl+Lxv+PojBF" KID="368BC06A9DB273B133A80002"
KV 
= "2"/>
<urn:groove.net:Auth PTSig
="i1alU0dLC7Oycrmmdzelc+uTnAGv2Ak1RE9oVL4Zy9tylUL5ybT81uVXtGNViSwtZ57BwPrfrgnGQbQcVi/N+duGYGAOc4zL4Mp0L4Vn6tzw6LZP8elU1TDDztpenzZG4zkJcLtvhjnEp82VlU923FnTotv4PeSQOFkpwvc5Zakpwd8NsmctR41Ulc7c8faf1MlqdYF4jQfW0iAlppppppppz7Bo9jnO5f0TOHnlcCWE0tLp32lElHjh2qMfnAlDbt5B4zW"/>
</urn;groove.net:SE>
</urn:groove.net:Del>
【０１０３】
ここでＤｅｌはデルタ要素で、その属性は以下で説明するとおりである。ＳＥ要素は機密化された要素で、デルタに使用する機密性のバージョンを表わす単一の属性を備える。ＥＣ要素は暗号化内容で、デルタの中のコマンドを暗号化した結果である。ＥＣ要素は暗号化されたコマンドのｂａｓｅ６４符号化を含む（暗号化されたコマンドが非常に大きい場合にはバイナリ・ドキュメントをバイナリ属性の代わりに使用する）。ＩＶ要素は暗号化アルゴリズムで使用される初期化ベクトル、ＫＩＤ要素は機密性キーＩＤ、ＫＶ要素はキーのバージョン番号である。Ａｕｔｈ要素はデルタの完全性保護に使用する認証子を含む。ＰＴＳｉｇ要素はデルタのｂａｓｅ６４符号化した署名である。
【０１０４】
機密化した後、デルタはステップ３２４でシリアル化（ｓｅｒｉａｌｉｚｅ）される。例えば、一つの実施態様において、データはＸＭＬの標準バイナリ符号化であるＷＢＸＭＬとしてシリアル化される。デルタが何らかのバイナリ・ドキュメントを有する場合にはＭＩＭＥメッセージとして一緒にまとめることができる。
【０１０５】
最後に、ステップ３２６で、シリアル化デルタが通信マネージャ４０６の出発デルタ・キュー４０８へ転送され、この通信マネージャがこのデルタを共有空間内の他のエンドポイントへ送信する。処理はステップ３２８で終了する。
【０１０６】
図１０Ａと図１０Ｂは並置した場合にソース・エンドポイント４００から宛先エンドポイント４０２でデルタを受信するプロセスのステップを示す。このプロセスはステップ１０００ではじまりステップ１００２に進み、ここで共有空間内の宛先エンドポイント４０２でシリアル化デルタをその宛先エンドポイント４０２の通信マネージャ４１０で受信する。通信マネージャ４１０はデルタを処理する正しい共有空間を特定し、ダイナミクス・マネージャ４２２をその共有空間に呼び出して受信デルタを処理させる。
【０１０７】
ダイナミクス・マネージャ４２２はステップ１００４でデルタを非シリアル化する。このプロセスはデルタをＸＭＬコードへ逆変換するもので、このＸＭＬコードはダイナミクス・マネージャ４２２のＸＭＬドキュメント４２３に格納される。この時点で、ダイナミクス・マネージャ４２２はこれがデルタ要素であることを認識できる。全ての新規到着デルタはダイナミクス・マネージャＸＭＬドキュメント４２３の到着デルタ・キュー４３４に入れられる。このキュー４３４は、ダイナミクス・マネージャ４２２が処理できるようになるまでの一時的な置き場として用いられる。ダイナミクス・マネージャ４２２はデルタの処理を開始する前に他のソース例えばリレー・サーバ等から全てのデルタを受信するまで待機する。ダイナミクス・マネージャ４２２がデルタ処理を開始できるようになると、デルタは到着デルタ・キュー４３４から除去される。
【０１０８】
ステップ１００６では、デルタを送信したエンドポイントが「活動」状態にあるか（エンドポイント状態については後述する）チェックを行なう。デルタを送信したエンドポイントが活動状態でなければ、ステップ１００８でそのデルタは「保留」される。これは、エンドポイントを共有空間へ追加したデルタが実行されていない可能性があるためで、受信デルタは実行されるまで処理できないことによる。つまり、エンドポイントを作成したデルタが取得されるまでエンドポイントから受信した全デルタが保留される。同様に、デルタを生成したエンドポイントが共有空間から「招待されていなかった」場合には、システムは、共有空間でまだ活動している別のエンドポイントがそのデルタを実行し終わらない限りそのエンドポイントからのデルタは処理しない。保留デルタは、デルタを実行する決定がなされるまで、適当な作成者の元で保留デルタ要素４２８に格納される。保留デルタ要素４２８は定期的にパージされる。保留デルタが実行されない場合、これを含むグループが保留デルタ要素４２８からパージされる時に消去される。
【０１０９】
デルタがステップ１００６で決定したように保留されない場合、送信エンドポイントは分かっているので、デルタはステップ１０１０でセキュリティ・マネージャ４１６により完全性チェックを行なえる。この段階で、デルタから依存性やその他の情報の読み出しを継続する前に、デルタが改竄されていないことを確認することが重要である。デルタが完全性チェックに合格しない場合、ステップ１０１４で破棄され、プロセスは頁間接続１０１８と１０２２を経由してステップ１０３２で終了する。
【０１１０】
デルタがステップ１０１２で完全性チェックに合格すると、プロセスは頁間接続１０１６と１０２０を経由してステップ１０２４に進み、ここでデルタの復号を試みる。正しいキーが入手できれば、ステップ１０２４でデルタを復号することが可能である。デルタの依存性はチェックされていないので、そのデルタの何らかのキーが失われている可能性がある。そのような場合、デルタは後で復号される。復号ステップは暗号化デルタのＳＥ要素をデルタ内のコマンドに復元する。
【０１１１】
次に、デルタの依存性属性を検証することで、ステップ１０２６で、デルタの依存性がダイナミクス・マネージャ４２２により取り出される。依存性属性は暗号化されていないので、依存性はステップ１０２４で復号が不可能だった場合でも取り出すことができる。依存性は、並置した場合にこの処理のステップを図示するフローチャートを構成する図１１Ａと図１１Ｂで更に詳細に示してあるように、同化される。
【０１１２】
依存性処理はステップ１１００で開始し、処理はステップ１１０２に進み明示的依存性のリストがデルタの属性からオープンされる。これが作成者からの最初のデルタでない場合には、作成者からの先行デルタを依存性リストの先頭に付加する。ステップ１１０４で、デルタの依存性を全部処理したかどうか判定を行なう。処理してある場合には、依存性処理は頁間接続１１１６と１１２４を経由してステップ１１３０で終了する。
【０１１３】
これ以外に、ステップ１１０４で、全部の依存性が処理されていないと判定される場合、ステップ１１０６で、ダイナミクス・マネージャ４２２は依存性リストから次の依存性を取り出す。これらの依存性デルタ各々に対して、ステップ１１０８でチェックを行ない、依存性デルタが後述するように同化されたか判定する。その依存性デルタがすでに同化されている場合、プロセスはステップ１１０４に戻り更に依存性が残っているか調べる。
【０１１４】
依存性セットのデルタのいずれかが同化されていない場合、ステップ１１１０で次のデルタが保留されたかを判定する。デルタが保留されていない場合、プロセスは頁間接続１１１６と１１２４を経由してステップ１１３０で終了するが、これは次のデルタがないためである。これ以外に、次のデルタがステップ１１１０で判定された通り保留されていれば、処理は頁間接続１１１４と１１２０を経由してステップ１１２６へ進み、ここで保留デルタの同化を試みる。ステップ１１２８で判定されるように同化が成功した場合、処理は頁間接続１１１８と１１１２を経由してステップ１１０４へ戻り、追加の依存性を処理すべきか判定する。これ以外に、保留デルタがステップ１１２８で判定されるように同化できない場合、プロセスはステップ１１３０で終了するが、これは依存性がないためである。
【０１１５】
依存性の幾つかが処理できないために新規デルタが同化できない場合、新規デルタはデルタ・ホルダー４４２に置かれる。デルタ・ホルダーはダイナミクス・マネージャ４２２に関連したＸＭＬドキュメント４２３内のＸＭＬデータ構造である。これは図１２に図示したような構造１２００を持っている。デルタ・ホルダー１２００はデルタ・ホルダーを表わすＤｅｌＨｌｄｒ要素１２０２を含む。この要素は現在活動しているブロックの番号を保持するＡｃｔｉｖｅＢｌｏｃｋＮｕｍ属性を有する。ＤｅｌＨｌｄｒ要素１２０２は１つまたはそれ以上のＨｌｄＧｒｐ要素を含み、その各々が同じ依存性を待っている保留デルタと保留エンドポイント・パルスのグループを表わす。これらの要素の各々は保持されているデルタとパルスの全部が待機している依存性を指定するＤｅｐ属性を備える。各ＨｌｄＧｒｐ要素は１つまたはそれ以上のＬＤｅｌ要素を含み、その各々が保持されたデルタ及び、また１つまたはそれ以上のＥｐｔＰｕｌ要素を表し、その各々が保持されたパルスを表わす。新規デルタは失われた依存性デルタ（ｄｅｐｅｎｄｅｎｃｙ  ｄｅｌｔａ）に対応するデルタ・ホルダー４４２のＨｌｄＧｒｐ要素に格納される。
【０１１６】
ステップ１１１０で決定されるように失われた依存デルタが保留されていない場合、ダイナミクス・マネージャ４２２は共有空間内の他のエンドポイントから依存デルタを取り出そう（以下、フェッチ）とする。さらに詳しくは、デルタを取り出そうとする際に別のエンドポイントへ取り出し要求（以下、フェッチ要求）を送信する。効率を向上させるため、フェッチ要求は全デルタについてバッチ処理され一つの要求で要求される。
【０１１７】
別のエンドポイントから取り出さなければならないデルタの個数が多くなることがあり、そのため顕著な時間を占有することがあるため、エンドポイントが先行の要求からデルタを未だ受信している間は同一デルタについての複数のフェッチ要求を行なえないようにする必要がある。複数の再フェッチは各フェッチ要求にシーケンス番号を付属させることで防止する。到着フェッチ要求が充分に大きなシーケンス番号を持っていない場合には要求を受け取ったエンドポイントは要求されたデルタを送信しない。フェッチ応答シーケンス番号は各エンドポイントで保存されてフェッチ要求がそのエンドポイントで受信された時点で使用される。更に、フェッチ要求シーケンス番号は各エンドポイントで保存されてそのエンドポイントが別のエンドポイントへフェッチ要求を生成する際に使用される。これらのシーケンス番号はどちらもゼロからはじまり以下の方法で使用される。
【０１１８】
フェッチ処理が図１３に図示してあり、この処理はステップ１３００で始まりステップ１３０２に進み、ここで、例えばエンドポイントＡなど第１のエンドポイントでフェッチ要求が生成されて、別のエンドポイント例えばエンドポイントＢへステップ１３０４で送信される。このようなフェッチ要求が生成されるときには、フェッチ要求シーケンス番号を含める。フェッチ要求を受信した場合、ステップ１３０６で、要求内のフェッチ要求シーケンス番号が受信エンドポイントで保存してあるフェッチ要求シーケンス番号と比較される。二つのシーケンス番号が等しい場合にはフェッチ要求は有効で、ステップ１３０８で、要求されたデルタがエンドポイントＡへ転送される。受信エンドポイントはステップ１３１０に記載してある通りフェッチ要求シーケンス番号の格納している値を増加（以下、インクリメント）する。次に、受信エンドポイントはステップ１３１２で、要求エンドポイントへのフェッチ要求シーケンス番号の値を含むフェッチ・シーケンス番号更新メッセージを送信する。しかし、フェッチ要求がステップ１３０６で判定されて無効な場合には、要求されたデルタは送信されない。その代わり、更新メッセージだけがステップ１３１２で送信される。
【０１１９】
フェッチ・シーケンス更新メッセージを送信エンドポイントで受信すると、送信エンドポイントはステップ１３１４にて説明したようにフェッチ要求シーケンス番号を更新する。さらに詳しく説明すると、受信メッセージのフェッチ応答シーケンス番号が送信エンドポイントで使用している現在のフェッチ要求シーケンス番号より大きい場合、このエンドポイントはフェッチ要求シーケンス番号を更新メッセージのシーケンス番号にセットする。それ以外の場合、送信エンドポイントはフェッチ要求シーケンス番号を変更しない。このプロセスはステップ１３１６で終了する。
【０１２０】
以下はこのようなシーケンス番号の使用例である。二つのエンドポイントＡとＢが存在し各々内部にフェッチ要求シーケンス番号とフェッチ応答シーケンス番号の値を格納しており、値がゼロだと仮定する。エンドポイントＡはデルタ１〜１００が欠落していると判断しこれらのデルタのフェッチ要求をエンドポイントＢへ送信する。このフェッチ要求は値ゼロのフェッチ要求シーケンス番号を有している。エンドポイントＢはフェッチ要求を受信し、内部のシーケンス番号を格納しているフェッチ応答シーケンス番号（値がゼロ）と比較して、フェッチ要求が有効であると判断する。エンドポイントＢは要求されたデルタをエンドポイントＡに送信しエンドポイントＡに対して格納しているフェッチ応答シーケンス番号の値を１にインクリメントする。エンドポイントＢはエンドポイントＡにシーケンス番号が１のフェッチ・シーケンス更新メッセージを送信する。
【０１２１】
エンドポイントＡがデルタ１〜２０を受信し、デルタ２１〜１００はデルタとフェッチ・シーケンス更新メッセージが未だ転送中であってもこれらを要求するように決定したと仮定する。エンドポイントＡは値がゼロのフェッチ要求シーケンス番号を持つ別の要求を送信する。エンドポイントＢは新しいフェッチ要求をエンドポイントＡから受信し、これのフェッチ要求シーケンス番号（値がゼロ）はエンドポイントＡに対する現在のフェッチ応答シーケンス番号より小さいため（値が１）、要求が無効であると判定する。そのため、エンドポイントＢはデルタ２１〜１００を再送しないが、その代わり値が１の更新シーケンス番号を有する別のフェッチ・シーケンス更新メッセージを送信する。
【０１２２】
エンドポイントＡはデルタ２１〜１００の受信を終了し、又第１のフェッチ・シーケンス更新メッセージも受信する。これにより、エンドポイントＡは内部のフェッチ要求シーケンス番号の値を１に更新する。エンドポイントＡは第２のフェッチ・シーケンス更新メッセージを無視するが、これはここで搬送された更新シーケンス番号値が格納しているフェッチ要求シーケンス番号より小さい又は等しいためである。そのため、同じデルタは２度送信されない。
【０１２３】
フェッチ要求シーケンス番号とフェッチ応答シーケンス番号はＸＭＬドキュメント４２３の一部であるエンドポイント・データ構造に格納される。エンドポイント情報を保持するＸＭＬデータ構造の例が図１４Ａ及び図１４Ｂに図示してあり、両図は並置した場合にエンドポイントに関する情報を格納する例示的ＸＭＬ構造１４００を図示する。この構造は多数のＸＭＬ要素で構成される。Ｅｐｔｓ要素１４０２はエンドポイントの集合を表わす。この要素１４０２はこのエンドポイントが作成する次のデルタでセットする必要がある新しい依存性を保持するＮＤｅｐｓ属性を有する。Ｅｐｔｓ要素は１つまたはそれ以上のＥｐｔ要素１４０４、１４０６を含み、その各々が単一のエンドポイントを表わす。
【０１２４】
各Ｅｐｔ要素１４０４は多数の属性を備え、これにはエンドポイントのコンタクトＵＲＬを保持するＣｏｎｔａｃｔＵＲＬ属性を含む。ＣｒｅａｔｉｏｎＩｄ属性はエンドポイントを作成したデルタのシーケンスを保持するか、またはこのエンドポイントが共有空間を作成した場合には標記「Ｆｉｒｓｔ」を含む。ＤｅｖｉｃｅＵＲＬ属性はエンドポイントのデバイスＵＲＬを保持する。ＨＧＮ属性はそのエンドポイントがパルスで又はデルタを作成して宣言した最大グループ番号を保持する。ＨＩＰ属性はエンドポイントによって作成されたデルタの最高挿入ポイントを格納する。ＯｌｄＣｒｅａｔｉｏｎＩｄｓはこのエンドポイントを以前に共有空間へ誘致したデルタのシーケンスを保持する。
【０１２５】
ＯｕｔＯｆＤａｔｅＴｉｍｅ属性はエンドポイントから受信した最後のメッセージ以後に第１のローカル・デルタが作成された時刻にセットされる。ＰｅｎｄｉｎｇＬａｇｇａｒｄ属性は後述するようにエンドポイントが遅れている場合にセットする。ＰｕｒＧｒｐ属性はこのエンドポイントがパージしたいと宣言した最高グループを保持する。Ｒｅｑｓ属性はエンドポイントからの保持デルタを同化する必要があるデルタを格納し、ＲｅｑＳｅｑ属性は次のフェッチ要求をエンドポイントで受信する時に使用するフェッチ要求シーケンス番号を保持する。ＲｅｓｐＳｅｑ属性はフェッチの一つに応答した後でエンドポイントへ送信された最後のフェッチ応答シーケンス番号を保持する。
【０１２６】
ＳＰＧ属性はエンドポイントがデルタを作成しなかった場合等のエッジ条件（ｅｄｇｅ  ｃｏｎｄｉｔｉｏｎ）で何をパージするか判定するために使用する２次パージグループを格納する。Ｓｔａｔｅ属性はパージの決定で使用するエンドポイントの状態を保持し、これについては後述する。ＵＩＤ属性はエンドポイントのユニークなＩＤを保持する。一つの実施態様において、これはＣｏｎｔａｃｔＵＲＬとＤｅｖｉｃｅＵＲＬ属性の値のハッシュ（ｈａｓｈ）である。
【０１２７】
Ｅｐｔ要素の各々、例えば要素１４０４は１つまたはそれ以上のＣｒｅａｔｏｒ要素１４０８〜１４１８を含み、その各々が作成者及びデルタを保留する親として使用されるＰｎｄｇＤｅｌｓ要素１４２０を表現する。各Ｃｒｅａｔｏｒ要素は作成者を表現する。エンドポイントが空間を再オープンする度に、デルタを作成する時に使用する新規作成者も作成する。この作成者は、情報の逸失に繋がるようなクラッシュ又はその他の事件の場合にデルタ・シーケンスがユニークであることを確実にするために使用されるランダムなＩＤを有する。各Ｃｒｅａｔｏｒ要素は幾つかの属性を有し、これには作成者によって作成された最高デルタの挿入ポイントを保持するＨＩＰ属性を含む。ＬａｓｔＵＩＤ属性はこの作成者のユニークなＩＤを生成する際に使用された最後のシーケンスを保持する。ＰｕｒｇｅＧｒｐ属性はパージされた時に作成者を消去することができるグループの番号を格納する。ＳｕｂＮｕｍ属性は標的アイデンティティで使用される又は後述するようにこの作成者が作成した非同期デルタで使用される最後のサブシーケンス番号を保持する。
【０１２８】
ＰｎｄｇＤｅｌｓ要素（４３４、図４）は保留デルタ全ての親である。前述のように、保留デルタはダイナミクス・マネージャが同化したい又はしたくないデルタである。保留デルタは、エンドポイントが空間に追加される前、又はエンドポイントが除去された後でデルタが受信された場合にだけ発生する。ＰｎｄｇＤｅｌｓ要素１４２０は１つまたはそれ以上のＬＤｅｌ要素１４２２を含み、この各々がデルタを表現する。
【０１２９】
図１０Ａと図１０Ｂに戻り、ダイナミクス・マネージャがステップ１０２６で全部の依存性を同化しようとした後、処理はステップ１０２８に戻り、ここで全依存性が同化されたか判定する。まだであれば処理はステップ１０３０に進みオリジナルのデルタを保持する。処理はステップ１０３６で終了する。
【０１３０】
これ以外に、ステップ１０２８で全依存性が同化されたと判定した場合、この処理はステップ１０３２に進みここで新規デルタも同化される。デルタの同化は共有空間データベースでトランザクションを作成しデルタをデルタ・ログ４４４に入れることから構成される。前述のように、全てのデルタはグループ番号とシーケンスがあらかじめスタンプされている。つまり、デルタをデルタ・ログ４４４に挿入する処理はデルタ・ログ４４４の正しいグループ要素の決定から開始する。グループが存在しない場合、この時点で作成される。次に、グループを調べてデルタ・シーケンスの中の作成者ＩＤに相当するチェーンを調べる。ここでも、チェーンが存在しなければ作成する。同化すべきデルタはこのチェーンの末尾に追加される。
【０１３１】
デルタを同化すると、ダイナミクス・マネージャ４２２が共有空間データベースで現行のトランザクションをコミットする前にこれが実行される。デルタ実行中に発生するエラーは実行したコマンドをロール・フォワードするかロール・バックすることで処理する。更に、デルタ実行の前後で開始したトランザクションを中止する。デルタ実行エラーは各デルタが実行される際及び現在のトランザクションがコミットされる前に処理される。ロールバックとロールフォワードを制限するため、ダイナミクス・マネージャ４２２はデルタの実行前に可能な限り多くのデルタを同化しようと試みる。したがって、デルタ・ログ４４４は何個のデルタが同化されて実行されていないかの記録である。このカウントはデルタ全部が実行されることを保証するために使用する。
【０１３２】
デルタの同化後、同化したデルタに依存する追加のデルタを同化することが可能になる。これらのデルタは従属（ｄｅｐｅｎｄｅｎｔｓ）と呼ばれる。後者の同化はステップ１０３４で行なわれる。さらに詳しくは、デルタ・ホルダー４４２内部で、デルタはこれらが待機しているデルタに基づいてグループ化される。デルタが同化されると、デルタ・ホルダー４４２内にそのデルタを待っていたデルタがないか調べるチェックを常に行なう。このようなデルタが存在する場合、これらのデルタを同化する。後者の同化中に、これらのデルタについて依存性のチェックを行ない、全て同化された場合には、従属デルタも同様に同化できる。デルタ処理はステップ１０３６で終了する。
【０１３３】
実行処理が図１５Ａと図１５Ｂに更に詳細に図示してある。このプロセスはステップ１５００で開始しステップ１５０２へ進み、ダイナミクス・マネージャ４２２がデルタ・ログ４４４を巻き戻し、デルタ・ログの最後から開始してログの先頭へ向かって進む。さらに詳しくは、ログはチェーン、グループ、ブロックに構成されているので、ログの末尾は最後のブロックの最後のグループの最後のチェーンの最後のデルタである。最後のチェーンの各デルタはチェーンの先頭に向かって動きながら検証される。最後のチェーンの先頭に到達すると、処理は最後から２番目のチェーンの最後のデルタから継続して行ない、グループ内の最初のチェーンの全デルタを調べるまで続く。次に、直前のグループの最後のチェーンにある最後のデルタから処理を継続する。ブロック内の第１のグループに到達すると、処理は直前のブロックの最後のグループの最後のチェーンの最後のデルタから継続する。このように全ての新規に同化したデルタが発見されるまで動作を継続する。
【０１３４】
検証しているデルタが実行されなかった場合、ステップ１５０４で判定するように、処理はステップ１５０２へ戻りここで次のデルタを検証する。しかし、検証しているデルタが実行されている場合、ステップ１５０４で判定するように、ダイナミクス・マネージャ４２２がステップ１５０６でチェックし、他の同化されたデルタ（以下、同化デルタ）のどれかと衝突するかどうか判定する。前述の同化処理中に、全部の同化デルタの前述の衝突文字列のセットが構築される。衝突チェックは検証しているデルタの衝突文字列を衝突文字列セットにある衝突文字列全部と比較して行なう。いずれかの文字列の対の文字列が同一、またはどちらかの比較している文字列が空の場合、対応するデルタが衝突する。衝突が存在しない場合、処理はステップ１５０２へ戻り次のデルタを検証する。
【０１３５】
ステップ１５０６で判定したように衝突がある場合、ステップ１５０８で、ダイナミクス・マネージャはデルタを巻き戻す。前述のように、ダイナミクス・マネージャ４２２はデルタ全部が各エンドポイントで一貫した順序で実行されることを保証することで、異なるエンドポイントが収束することを確保しなければならない。新規同化デルタの一つが、すでに実行された非依存デルタの位置より前にあるデルタ・ログ４４４内のある位置で同化されたことも考えられる。このような状況が発生した場合、収束を保証するため、すでに事項したデルタは同化デルタを実行する前に「ロールバック」（ｒｏｌｌ  ｂａｃｋ）する必要があり、次に同化デルタを実行した後で「ロールフォワード」（ｒｏｌｌ  ｆｏｒｗａｒｄ）する。
【０１３６】
デルタをロールバックするのは逆の順序でデルタのコマンドを反復することで構成される。各コマンドに遭遇すると、エンジン４３６が読み出されてコマンドの影響を取り消す。エンジン４３６は、デルタを最後に実行した時にそのエンジンがあらかじめ生成してあった各デルタ内のコマンド要素及びコマンド取り消し要素にアクセスする。デルタのコマンドのロールバック中にエラーが発生した場合、ダイナミクス・マネージャ４２２はすでにロールバックしたそのデルタの全てのコマンドを再実行しようとしデルタが実行された状態になるようにする。このプロセスはステップ１５１０に進み、ここで全ての新規デルタが検証されたか判定する。検証が未だであれば、プロセスはステップ１５０２に戻ってデルタの検証を続ける。
【０１３７】
全ての新規デルタがステップ１５１０で判定したように検証されていれば、処理は頁間接続１５１２と１５１４を経由してステップ１５１６へ進み、ここでロールフォワード手順を開始する。ステップ１５１６では、デルタ・ログを調べ各デルタをもう一度検証する。ステップ１５１８で検証しているデルタがロールバックされたかを判定する。もしそうなら、プロセスはステップ１５２０へ進む。これ以外で、ステップ１５０６で決定されたような衝突がなかったか、あるいはロールバック中にエラーが発生したため、デルタがロールバックされていない場合、ダイナミクス・マネージャ４２２はステップ１５２２でデルタが新規デルタかどうか判定する。デルタが新規デルタではない場合、ダイナミクス・マネージャ４２２は何もせず処理はステップ１５２８へ進む。しかし、ステップ１５２２でデルタが新規デルタであるとダイナミクス・マネージャが判定する場合、ステップ１５２４とステップ１５２６で新規デルタが復号され実行される。処理はステップ１５２８へ進む。
【０１３８】
ステップ１５１８で判定したようにデルタがうまくロールバックされた場合、ステップ１５２０でダイナミクス・マネージャ４２２はデルタの全コマンドのロールフォワード、又は再実行を開始する。この処理は最初にデルタを実行した処理と全く同様である。このロールフォワード操作の間、ダイナミクス・マネージャ４２２は処理を開始したデルタを含め新規同化したデルタを全部検出する。ダイナミクス・マネージャはすでに後者のデルタについて完全性チェックを行なっているが、前述のようにその時点では未だ復号できなかった可能性があった。デルタが未だ復号されていない場合、ロールフォワード処理の一部として復号される。この時点で、全ての依存デルタが実行されることになる。したがって、デルタを復号するのに必要なキーは入手可能になり復号が成功するはずである。
【０１３９】
デルタ内のコマンドの再実行は前述したコマンド実行と同様に行なわれてこれを作成したエンドポイントのデルタを実行する。しかし、実行中にエラーがある場合、ツールは別のマシン上にあるため、デルタを作成したツールへ例外を渡すことが不可能である。その代わりとして、このようなエラーが発生した場合、実行に成功したコマンドをロールバックしてトランザクションを中止した後、実行中例外があったとしてデルタにマークし、ダイナミクス・マネージャは処理を継続する。
【０１４０】
新規エンドポイントを共有空間に追加するデルタの実行中の例外は別の取り扱いをする。共有空間内の一つのエンドポイントが新規エンドポイントを追加するのに成功した場合、ダイナミクス・マネージャは共有空間内の他の全てのエンドポイントでエンドポイントを追加する必要がある。ある条件下では、例えばメンバー許可の追加を招待とは無関係の新規エンドポイントの招待者から除去した場合等に問題が発生することがある。これらの場合に対処するため、ダイナミクス・マネージャは例外後に追加エンドポイント・デルタの他のコマンドを実行継続する。
【０１４１】
いずれの場合も、処理はステップ１５２８に進み、ロールフォワード処理が完了したか判定する。まだなら、処理はステップ１５１６でデルタ・ログの巻き戻しに戻る。ロールフォワード処理が完了している場合、処理はステップ１５３０で終了する。
【０１４２】
上述の処理は通常デルタの作成、送信、受信を示したものである。しかし、本発明の原理では、幾つかの特殊条件を処理するために特殊なデルタが作成されていた。これら後者のデルタは非同期デルタ、アイデンティティ配布デルタ、優先デルタである。非同期デルタは共有空間内の通常の通信トラフィックの一部として送信されない。その代わり、非常に大きなファイルを転送するのに使用され、これらを含むデルタが長時間にわたって共有空間内の他のデルタの送信を阻害するのを防止し、非対称ファイルの転送をサポートする。非同期デルタは通常デルタとは幾つかの相違がある。最も重要な相違点は、将来デルタが非同期デルタに依存できないことである。したがって、共有空間内の他のデルタは非同期デルタ到着前に実行でき、非同期デルタは一貫性を維持するために実行する必要がない。さらに、ダイナミクス・マネージャは他のエンドポイントから紛失した非同期デルタをフェッチしない、つまりこれらの供給では通常のデルタの供給と同程度の信頼性がない。最後に、非同期デルタに依存するデルタがないので、共有空間内の全エンドポイントへ非同期デルタを送信する必要がない。この特性は特定エンドポイントへの非同期デルタ送信を通常デルタより大幅に簡単にし非対称ファイルのサポートを可能にする。
【０１４３】
しかし、非同期デルタは先行実行をダイナミクス・マネージャが保証できるようにする依存性を持っている、すなわち非同期デルタが遠隔エンドポイントで実行されるとき作成者が非同期デルタの作成時に実行した非同期でないデルタ全部も遠隔エンドポイントで実行されていることになる。非同期デルタはデルタ・ログに明確に定義された挿入ポイントを持ち順位の低いデルタ・ログ挿入ポイントでのデルタ実行前にロールバックすることが可能である。順位の高いデルタ・ログ挿入ポイントを持つ他のデルタは非同期デルタの実行前にロールバックされる。非同期デルタは全てのエンドポイントで同じ相対順序で実行されることを保証しないので、非同期デルタの場合には収束がない。
【０１４４】
非同期デルタは共有空間内で他のデルタとインタリーブ（ｉｎｔｅｒｌｅａｖｅ）することが可能で、低い優先順位で送信できる。例えば、大きなファイルを通常デルタと非同期デルタの組合せで送信できる。通常デルタはファイル記述子の送信に使用し、非同期デルタはファイル内容の送信に使用する。ＧＵＩＤを使用して宛先で記述子と内容を一致させる。ファイル内容を含む非同期デルタはファイルを追加したらすぐ（対称ファイル）送信したり、遠隔エンドポイントがファイルを要求した場合だけ送信することもできる（非対称ファイル）。非同期デルタのＸＭＬ構造は図５に図示した通常デルタと同一だが、デルタが非同期の場合にはＤｅｌ要素のＡｓｙｎｃ属性がセットされる点で異なっている。
【０１４５】
アイデンティティ標的デルタはアイデンティティについて共有空間の他のインスタンス（ｉｎｓｔａｎｃｅ）が知っているだけで良いような未読マークやその他の情報をサポートするように設計されている。アイデンティティ標的デルタはローカル・アイデンティティで対象になるだけである。これらのデルタは共有空間のエンドポイントのサブセットだけに送信され、このサブセットはデルタを作成したメンバーのエンドポイントで構成される。非同期デルタと同様、他のデルタはアイデンティティ配布デルタに依存できないので、アイデンティティ配布デルタは収束や信頼性をサポートしない。
【０１４６】
ダイナミクス・マネージャ４２２は非同期デルタとアイデンティティ配布デルタを「サブデルタ」（ｓｕｄｅｌｔａ）として処理する。デルタ・シーケンスで識別されるのではなく、サブデルタはデルタ・「サブシーケンス」を備えている。デルタ・サブシーケンスは作成者によって作成された最後のデルタのシーケンスに小数が付く。この小数は新規サブデルタが実行される毎にインクリメントされる。例えば、作成者Ａがあるデルタ、二つのアイデンティティ配布デルタ、ついで別のデルタを実行し、最後に別のアイデンティティ配布デルタを実行した場合、これらのデルタとサブデルタは次のシーケンス及びサブシーケンスを持つことになる：
Ａ１，Ａ１．１，Ａ１．２，Ａ２，Ａ２．１
【０１４７】
通常デルタと同様に、サブデルタはデルタ・ログの末尾に必ず挿入されデルタ・ログに一定のグループ番号と挿入ポイントを持っている。上記の例で、Ａ１．１は必ずＡ１の後、かつ、Ａ２の前に挿入される。これはＡ１と同じグループ、Ａ２と同じグループ、又はこれら二つの間のグループに属する。サブデルタは全てのエンドポイントに送信されないので、他のエンドポイントがサブデルタに対して非依存のデルタを作成する可能性が大きい。これはサブデルタがロールバックされる可能性を大幅に増加させる。しかし、グループあたり限られた個数のデルタが存在するだけなので、非依存デルタを生成するエンドポイントはグループ番号を進めることができ、非依存デルタはサブデルタの後に来るようになる。これはサブデルタがロールバックされる回数を制限する。
【０１４８】
サブデルタでは通常デルタと同様の方法で依存性がセットされる。サブデルタは全エンドポイントに送信されないので、依存性はサブデルタの依存性をセットした後でセットされる新規依存性から除去されない。上記の例では、デルタは次のような依存性を持っている：
Ａ１  ｛｝
Ａ１．１  ｛Ａ１｝
Ａ１．２  ｛Ａ１｝
Ａ２  ｛Ａ１｝
Ａ２．１  ｛Ａ１｝
【０１４９】
全てこのエンドポイントからの先行デルタに依存しているので、これらの依存性はデルタには明示的にセットされないことに注意する。サブデルタは全エンドポイントへ送信されないため、共有空間での新規機密キーを含むことはできない。デルタを機密化する際、ダイナミクス・マネージャはサブデルタに再キー（ｒｅｋｅｙ）を送出しない。
【０１５０】
アイデンティティ配布デルタのＸＭＬファイルが図１６に図示してある。このデルタ１６００は一つのコマンドと、そのコマンドの取り消し情報とを含み、一つのコマンドとそのコマンドの取り消し情報のある実行入れ子デルタを含む。Ｄｅｌ要素１６０４のＩｄＤｉｓｓ属性１６０２はデルタがアイデンティティ配布デルタの場合にセットされる。Ｄｅｌ要素１６０４のＳｕｂＳｅｑ属性１６０６はデルタのサブシーケンスを保持する。
【０１５１】
優先デルタは前述のデルタ配布システムで発生する二つの状況に対処するため使用される。第１の状況は、新規エンドポイントが共有空間に招待された場合、招待者が招待前に実行したデルタとは独立して実行されたデルタがこれら先行デルタのロールバックを引き起すことがあるため共有空間で生成されたそれまでのデルタの全部を含むデルタ・ログの内容を送信する必要がある。そのため、新規に招待されたエンドポイントはこれら先行デルタの全部を必要とする。デルタ・ログの内容は共有空間の実際のデータより大幅に大きいことが多く、このような内容の転送は新規エンドポイントのスタートアップで顕著な時間的遅延を招き得る。
【０１５２】
第２の状態は１０個のエンドポイントが存在する共有空間で示すことができる。一つのエンドポイントがオフラインになりデルタを実行する。残りの９個のエンドポイントは全てオンラインの状態で各々が１００個のデルタを実行する。オフラインのエンドポイントがオンラインに戻り、エンドポイントがオフラインだったときに実行されたデルタを他のエンドポイントが全て受信し（今は）オンラインになっているエンドポイントはそのエンドポイントがオフラインだったときに生成されたデルタを受信する。収束を実現するためには二つの可能性がある。オフラインになっているエンドポイントからのデルタが他のデルタより後で到着する場合、オフラインになったエンドポイントはそのデルタをロールバックする必要があり、他のエンドポイントからの９００個のデルタを実行してから、そのデルタをロールフォワードする。他のどのエンドポイントもロールバックする必要がない。しかし、オフラインのエンドポイントからのデルタがデルタ・ログで最初にあると、他の９個のエンドポイントは各々９００個のデルタをロールバックし、一つのデルタを実行し、９００個のデルタをロールフォワードする必要が出て来る。明らかに、前者の状況は大幅に作業が少ないが、グループ番号の割り当て方のため、後者の状況又は少なくともこれに近い状況が最も発生し易い状況になる。
【０１５３】
両方の状況は非依存デルタの順序を制御する方法を提供する優先デルタによって解決される。これらは非依存デルタを順序付けて、招待デルタと無関係のデルタがロールバックを惹起しないようにすることで、第１の状況に対処し、そのため新規の被招待者へデルタ・ログ全体を送信する必要がない。同様に、このような順序付けは第２の状況に対処する上でロールバック量を減少するためにも使用できる。優先デルタは優先デルタと無関係のデルタが優先デルタの依存している全てのデルタより後になるように順序付けて処理される。例えば、独立してＡがデルタＡ１とＡ２を生成しＡ２が優先デルタで、ＢはＢ１を生成したとすると、Ａ２が優先デルタであるから、Ｂ１は必ずＡ１より後に順序付けられる。Ｂ１はＡ２より前か後に来ることができる。
【０１５４】
前述の第１の状況に対処するため、新規エンドポイントが共有空間に追加されたときには、これを追加するデルタは可能な限り高い優先順位を有する。したがって、先行デルタのどれもロールバックされなくて良くなる。第２の状況に対処するためには、オンラインであってデルタを生成しているエンドポイントはデルタの一つを定期的に優先デルタにする。前述の例では、これはオンラインの９個のエンドポイントが生成した９００個のデルタは多数の優先デルタを含むことを意味する。オフラインのエンドポイントは優先デルタを生成せず、そのため９００個のデルタのうちわずかだけをロールバックすればよく、作業量は大幅に減少する。
【０１５５】
同時優先デルタの間の干渉を防止するため、もっと高い優先順位（又は同じ優先順位で低い挿入ポイントの非依存デルタがある場合にはデルタの優先順位は無視される。この動作は、共有空間に新規エンドポイントを追加する非依存デルタが二つ存在する場合、新規に追加されたエンドポイントの一方は保有していないデルタのロールバックを行なう必要が出て来る点で問題がある。この後者の状況は新規に招待したエンドポイントの一方を「同期範囲外（ｏｕｔ  ｏｆ  ｓｙｎｃ）」とマークし共有空間へ再招待される必要があるようにすれば対処できる。
【０１５６】
優先デルタはデルタ「ブロック」と呼ばれる階層構造をデルタ・ログへ付加することで実装される。デルタブロックはデルタ・ログの最大の区分である。ブロックはグループを含み、グループはチェーンを含み、チェーンはデルタを含む。グループは実際には複数のブロックの間に分割される。各ブロックは好きな個数のグループを含み各ブロックは一つの特定のデルタを備え、これはそのブロックを作成させる優先デルタである。新規優先デルタが到着すると、新規ブロックが更に高い優先順位の別のデルタの再同化を行なわせる限り、新規ブロックを作成させる。同化された非依存デルタは以前のブロックから除去され新規ブロックへ移動される。（これには非依存デルタのそれまでの位置へのロールバックと、それに続けて新規位置へ４の非依存デルタによるロールフォワードが必要になる。）これらの非依存デルタは優先デルタがデルタ・ログ状態の完全な表現を含む場合には検出可能である。デルタ・ログ状態は各エンドポイントから受信した最高シーケンスを表わすリストで構成される。あるグループが異なるブロックに分割されグループとシーケンスによる絶対デルタ順序付けが正しくなくなるようなことが考えられることに注意する。
【０１５７】
図９Ａと図９Ｂに図示してあるデルタ・ログのＸＭＬ表現を参照すると、デルタブロックはデルタ・ログ内に１つまたはそれ以上のＤｅｌＢｌｋ要素を含めることで実現される。ブロックはブロック・デルタによるデルタのセットとして定義され、ブロック・デルタはブロック内で最高の優先順位のデルタである。ブロックデルタが依存する全デルタは以前のブロック内にある。ブロック・デルタに依存しないデルタはすべてそのブロック内にある。ブロック・デルタに依存するデルタはそのブロックにあるか後続のブロックにある。この構成ではブロック・デルタが依存する全デルタの後で、ブロックデルタに依存しない全デルタが同化されることを保証する。
【０１５８】
ＤｅｌＢｌｋ要素例えばＤｅｌＢｌｋ要素９０４はこのブロックの優先デルタのシーケンス番号を保持するＤｅｌＳｅｑ属性を含め幾つかの属性を有している。このシーケンス番号は前述の通り構成される。ＨｉｇｈＧｒｐＮｕｍ属性はブロック内の最高順位グループの番号を保持する。ＮｏＵｎｄｏ属性はこのブロック内のデルタがユーザによって取消しできない場合にセットされる。各ＤｅｌＢｌｋ要素９０４は１つまたはそれ以上のＤｅｌＧｒｐ要素がその内部に含まれる。これらのＤｅｌＧｒｐ要素はデルタグループを表わす。
【０１５９】
この実装では、２個の追加エンドポイントデルタが同じブロック番号を持っている場合、独立追加エンドポイント操作で発生した前述の問題を検出できる。この場合、一方の新規エンドポイントは「勝者」と宣言され、他方は「同期範囲外」と宣言される。
【０１６０】
優先デルタは図１７に図示したステップで処理される。優先デルタが同化されようとするとき、これの優先順位を無視するかどうか最初に決定しなければならない。前述のように、優先順位はもっと高い優先順位の非依存デルタが存在すれば無視される。そのため、処理はステップ１７００ではじまりステップ１７０２へ進みここで非依存デルタの全部に位置が特定される。各優先デルタはこれを作成したエンドポイントのデルタ・ログの状態を記述する属性を持っている。この後者の状態はデルタを同化するエンドポイントでのデルタ・ログの状態と比較される。この情報から、非依存デルタの位置が特定できる。
【０１６１】
次に、ステップ１７０４で、非依存デルタの優先順位を比較する。ステップ１７０６で決定されるように、特定した非依存デルタのどれも同化しようとする優先デルタより高い優先順位を持っていない場合、新規デルタの優先順位が尊重される。ステップ１７０８で、各優先デルタはデルタ・ログの新規ブロックを開始する。優先デルタはデルタ・ログをブロックに分割し、優先デルタが依存している全デルタが、優先デルタのブロック内にあるデルタより先にブロック内に同化される。次に、ステップ１７１２で、優先デルタとは独立の全デルタと、優先デルタに依存するデルタが同一ブロック又は後続のブロックに同化される。
【０１６２】
さらに詳しくは、新規ブロックを作成した後、優先デルタに非依存の全てのデルタはデルタ・ログの新しい位置に再同化される必要がある。ロールバック段階の間、これらのデルタは古い位置までロールバックしてから新しい位置へロールフォワードし収束を維持する。処理はステップ１７１４で終了する。
【０１６３】
これ以外に、ステップ１７０６で、より高い優先順位のデルタが発見された場合、同化しようとしている優先デルタの優先順位は尊重されない。この場合、処理はステップ１７１０へ進み、デルタは既存の現在のブロックへ同化される。処理はステップ１７１４で終了する。
【０１６４】
新規デルタを追加したことで各エンドポイントのデルタ・ログのサイズが連続的に増大するのを防止するため、デルタ・ログは定期的にパージされる。しかし、デルタ情報の早まった破壊を防止するため、パージ処理は２段階処理になっている。第一に各エンドポイントはパージしようとするグループを宣言する（各エンドポイントにある最高順位グループに基づく）。次に、全エンドポイントで、エンドポイントがパージしたいと宣言したグループを比較することで選択されたグループのデルタをパージする。この処理が図１８に図示してある。
【０１６５】
処理はステップ１８００ではじまり、ステップ１８０２へ進む。さらに詳しくは、ステップ１８０２で、全エンドポイントがエンドポイント・パルスと呼ばれる送信でパージ情報を定期的にブロードキャスト（ｂｒｏａｄｃａｓｔ）する。各パルスはそのエンドポイントで最高のグループ番号を識別する情報と、パージ決定の保留が行なわれたグループを識別する情報を含む。更に、各エンドポイント・パルスはデルタが依存性を持っているのと同じ方法で依存性を持っている。依存性がパルスを受信するエンドポイントから失われた場合、パルスは丁度デルタが保持されたように保持される。ステップ１８０４で、そのエンドポイントの最高のグループ番号が比較される。ステップ１８０６で、全部の活動中のエンドポイントで最高のグループ番号の最小値より一つ小さい値をパージを保留しているグループとして識別する。最後に、ステップ１８０８で、各エンドポイントは全部の活動中のエンドポイントの保留グループの最小値までをパージする。処理はステップ１８１０で終了する。
【０１６６】
同様の方法で、エンドポイントそれ自体も活動しているかいないかによってエンドポイントＸＭＬ構造からパージされる。各エンドポイントは前述のエンドポイントＸＭＬ構造でＥＰＴ要素のＳｔａｔｅ属性に格納される状態を有する。Ｓｔａｔｅ属性は次の値のいずれかをとることができる。
【０１６７】
【表１】
2004152289.tif 000003
【０１６８】
各エンドポイントは選択した条件によってこれらの定義状態の間を移動する。各種状態の状態図と状態間の遷移を図１９に示した。例えば、エンドポイントは、新規共有空間の作成時に、矢印１９１２で示したようにローカル状態１９０２に入る。ローカル・エンドポイント以外のエンドポイントは矢印１９１４で示したように、そのエンドポイントについてのＡｄｄＭｅｍｂｅｒデルタ（招待）が実行されたときか、そのエンドポイントについてのＡｄｄＤｅｖｉｃｅＦｏｒＭｅｍｂｅｒデルタ（共有空間フェッチ）が実行されたときに活動状態１９０４に入る。同様に、エンドポイントはそれまで未知のエンドポイントからデルタを受信したとき矢印１９１６に示したように新規状態１９０６に入る。
【０１６９】
別のエンドポイントについて空間のシリアル化が開始さたとくきに、矢印１９１８で示したようなローカル状態１９０２から活動状態１９０４へのエンドポイント遷移が起こる。この場合、ローカル・エンドポイントは活動状態１９０４へ変化する。同様に、活動状態１９０４からローカル状態１９０２へのエンドポイント遷移は、エンドポイントの空間が非シリアル化されるときに起こる。この場合、そのエンドポイントはローカル状態１９０２へ遷移する。後者の遷移はアカウントがそれまで導入されていた装置へ再度導入された場合に発生し得る。
【０１７０】
エンドポイントはアカウントが以前に導入されていた装置へ再導入された場合に矢印１９２４で示したように活動状態１９０４から新規状態１９０６への遷移が可能である。エンドポイントは活動状態１９０４から切断中状態１９０８へ、活動エンドポイントがローカル・エンドポイントにより「遅れている」と宣言された場合、矢印１９３０で示したように遷移することができる。遅れ気味のエンドポイントは特定の期間にわたってデルタが同化されなかったエンドポイントとして定義される。時間チェックは前述のパージ宣言処理の間に実行されるのが普通である。活動中のエンドポイントからのデルタが実行され活動中のエンドポイントが共有空間を宣言したことをローカル・エンドポイントに通知した場合にも遷移は起こり得る。さらに共有空間から活動中のエンドポイントを招待しないデルタが実行されるときも発生し得る。最後にこの遷移は、ローカル・エンドポイントによって活動中のエンドポイントが今切断されたことを通知する切断通知が受信される場合にも発生することがある。
【０１７１】
新規状態１９０６から活動状態１９０４への遷移は、矢印１９２３で示したように、そのエンドポイントに付いてのＡｄｄＭｅｍｂｅｒデルタ（招待）が実行されるか、またはＡｄｄＤｅｖｉｃｅＦｏｒＭｅｍｂｅｒデルタ（共有空間フェッチ）が実行されたときに発生する。この遷移は、ＡｄｄＥｎｄｐｏｉｎｔデルタ（アカウントの導入）が実行された場合にも発生することがある。
【０１７２】
新規状態１９０６から切断中状態１９０８への遷移は、矢印１９２６で示したように、挿入ポイントがパージのために保留としてマークされている新規エンドポイントからデルタを受信した場合に発生し得る。これはまた、新規エンドポイントからのデルタの挿入ポイントを「パージのために保留中」とローカル・エンドポイントが宣言する場合にも発生する。更に、この遷移は新規エンドポイントが今切断されたことを通知する切断通知をローカル・エンドポイントが受信する際にも発生することがある。
【０１７３】
新規状態１９０６から切断状態１９１０への遷移は、矢印１９３８で示したように、挿入ポイントがパージされた新規エンドポイントからのデルタを受信した場合に、またローカル・エンドポイントによって受信された新規エンドポイントからのデルタの挿入ポイントがローカル・エンドポイントによってパージされている場合にも発生することがある。
【０１７４】
切断中状態１９０８から活動状態１９０４への遷移は、矢印１９３２によって示されるように、ＡｄｄＭｅｍｂｅｒデルタ（招待）が実行された場合、又はＡｄｄＤｅｖｉｃｅＦｏｒＭｅｍｂｅｒデルタ（共有空間フェッチ）が実行されたときに発生する。このような遷移はＡｄｄＥｎｄｐｏｉｎｔデルタ（アカウント導入）が実行された際にも発生することがある。
【０１７５】
切断中状態１９０８から新規状態１９０６への遷移は、矢印１９２６で示したように、アカウントがそれまで導入されていた装置へ再導入されたときに発生することがある。切断中状態１９０８から切断状態１９１０への遷移は矢印１９３４で示したように切断中のエンドポイントからローカル・エンドポイントが受信したデルタの挿入ポイントがローカル・エンドポイントによりパージされる場合に発生することがある。切断状態１９１０から活動状態１９０４への遷移は矢印１９２２で示したようにローカル・エンドポイントによりＡｄｄＭｅｍｂｅｒデルタ（招待）が実行された場合、又はＡｄｄＤｅｖｉｃｅＦｏｒＭｅｍｂｅｒデルタ（共有空間フェッチ）かＡｄｄＥｎｄｐｏｉｎｔデルタ（アカウント導入）が実行された際にも発生することがある。
【０１７６】
切断状態１９１０から新規状態１９０６への遷移は矢印１９３６で示したようにアカウントがそれまで導入されていた装置へ再導入されたときに発生することがある。
【産業上の利用可能性】
【０１７７】
前述の実施態様のソフトウェアによる実現は、例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭメモリ、又は固定ディスク等の有形媒体上に固定されるか、コンピュータ・システムへモデム又はその他のインタフェース装置を経由して媒体上で転送可能な、一連のコンピュータ命令を含む。媒体は光通信線又はアナログ通信線を含みこれに制限されない有形の媒体であったり、マイクロ波、赤外線、又はその他の伝送技術を含みこれに制限されない無線技術で実現することもできる。媒体はインターネットでもあり得る。一連のコンピュータ命令は本発明に関して本明細書で前述した機能の全部又は一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャやオペレーティングシステムで使用する多数のプログラミング言語で書くことができることは当業者には理解されよう。更に、このような命令は、現在又は将来の、半導体、磁気、光、又はその他のメモリ装置を含みこれに制限されない何らかのメモリ技術を用いて保存され、または現在又は将来の光、赤外線、マイクロ波、又はその他の伝送技術を含みこれに制限されない何らかの通信技術を使って伝送することができる。このようなコンピュータ・プログラム製品が例えばシュリンクラップされたソフトウェアとして印刷又は電子化文書を伴うリムーバブル媒体で配布される、またはコンピュータ・システムに例えばシステムＲＯＭ又は固定ディスクへ導入済みとして、又はネットワーク上のサーバ又は電子掲示板から例えばインターネット又はワールド・ワイド・ウェブから配布されることを意図している。
【０１７８】
本発明の代表的実施態様を開示したが、本発明の趣旨と範囲から逸脱することなく本発明の利点の幾つかを実現するような各種の変化及び変更を成し得ることは当業者には明らかであろう。
【図面の簡単な説明】
【０１７９】
【図１】図１は、本発明を使用できる例示的な従来技術のコラボレーション・システムの略ブロック図である。
【図２】図２は、図１に図示したシステムを実現するために使用するコラボレーション・ソフトウェアを実行する例示的な従来技術のコンピュータ・システムの更に詳細な略ブロック図である。
【図３】図３Ａと図３Ｂは、並置した場合に、本発明の原理によりデルタを作成したエンドポイントでのデルタの処理ステップを示すフローチャートを構成する。
【図４】図４は、デルタの生成、送信、受信処理に関係するダイナミクス・マネージャの主要部分を示す略ブロック図である。
【図５】図５は、一つのデータ変更コマンドがあり取り消し情報のない代表的なデルタを表わすＸＭＬデータ構造を示す略図である。
【図６】図６は、二つのデータ変更コマンドと両方のコマンドに対する取り消し情報を備えた代表的なデルタを表わすＸＭＬデータ構造を示す略図である。
【図７】図７は、ダイナミクス・マネージャにおけるデルタとデルタ処理構造を表わす永続的ＸＭＬドキュメントの構造を示す略図である。
【図８】図８Ａと図８Ｂは、並置した場合に二つの入れ子になって作成され、両方とも取り消し情報を持っているデルタを含むデルタのＸＭＬデータ構造の略図を構成する。
【図９】図９Ａと図９Ｂは、並置した場合に処理中のデルタを保持するデルタ・ログのＸＭＬデータ構造の略図を構成する。
【図１０】図１０Ａと図１０Ｂは、並置した場合にエンドポイントでデルタを受信し処理する過程のステップを示すフローチャートを構成する。
【図１１】図１１Ａと図１１Ｂは、並置した場合に新しいデルタを同化する過程のステップを示すフローチャートを構成する。
【図１２】図１２は、処理中のデルタを保持するデルタ・ホルダのＸＭＬデータ構造を示す略図である。
【図１３】図１３は、デルタの処理中にオーバーフェッチ（ｏｖｅｒ−ｆｅｔｃｈｉｎｇ）を制限する例示的な処理のステップを示すフローチャートである。
【図１４】図１４Ａと図１４Ｂは、並置した場合にエンドポイント情報を格納するＸＭＬデータ構造を表わす略図を構成する。
【図１５】図１５Ａと図１５Ｂは、並置した場合に新規デルタを実行する過程でのステップを示すフローチャートを構成する。
【図１６】図１６は、アイデンティティ配布デルタの例示的ＸＭＬデータ構造を示す略図である。
【図１７】図１７は、優先デルタの同化の例示的プロセスのステップを示すフローチャートである。
【図１８】図１８は、デルタ・ログをパージする例示的プロセスのステップを示すフローチャートである。
【図１９】図１９は、あるエンドポイントについてエンドポイント状態と、エンドポイント状態間の遷移を示す略図である。
【符号の説明】
【０１８０】
２２４    ツール
２２６    エンジン
２０６    ユーザ・インタフェース
２０８    ユーザ・インタフェース・マネージャ
２１０    アイデンティティ・マネージャ
２１２    共有空間マネージャ
２１４    アクティビティ・マネージャ
２２０    ダイナミクス・マネージャ
２１６    ストレージ・マネージャ
２３０    セキュリティ・マネージャ
２２２    通信マネージャ
４０６    通信マネージャ
４０８    出発メッセージ・キュー
４１０    通信マネージャ
４１１    到着メッセージ・キュー
４１４    セキュリティ・マネージャ
４２０    ダイナミクス・マネージャ
４４０    ＸＭＬドキュメント
４２６    配布要素
４３８    デルタ・ログ要素
４２５    配布コンポーネント
４１８    ツール
４３０    エンジン
４３２    データ・モデル
４１６    セキュリティ・マネージャ
４２２    ダイナミクス・マネージャ
４２３    ＸＭＬドキュメント
４２８    到着デルタ・キュー
４３４    保留デルタ要素
４４２    デルタ・ホルダー要素
４４４    デルタ・ログ要素
４３８    データ・モデル
４３６    エンジン
４２４    ツール
１９０２  ローカル状態
１９０４  活動状態
１９０６  新規状態
１９０８  切断中状態
１９１０  切断状態
【図１】
2004152289.tif 000004
【図２】
2004152289.tif 000005
【図３】
2004152289.tif 000006
【図４】
2004152289.tif 000007
【図５】
2004152289.tif 000008
【図６】
2004152289.tif 000009
【図７】
2004152289.tif 000010
【図８】
2004152289.tif 000011
【図９】
2004152289.tif 000012
【図１０】
2004152289.tif 000013
【図１１】
2004152289.tif 000014
【図１２】
2004152289.tif 000015
【図１３】
2004152289.tif 000016
【図１４】
2004152289.tif 000017
【図１５】
2004152289.tif 000018
【図１６】
2004152289.tif 000019
【図１７】
2004152289.tif 000020
【図１８】
2004152289.tif 000021
【図１９】
2004152289.tif 000022