(57)【要約】【課題】ピア・ツー・ピア型コラボレーションシステムで使用するエンドポイントに称呼を割り当てるための分散型の方法を提供すること。【解決手段】このスキーマはテレスペースメンバーの各々の各エンドポイントにユニークな番号を割り当てる。あるメンバーの各番号はそのメンバーがテレスペースに参加した順序を表わし、また別のテレスペースメンバーによって加入するように招待された各メンバーについては、招待した側のメンバーも表す。これらの新しいメンバーによってさらに多くのメンバーに加入するように招待すると、割り当て番号はさらに桁数を追加して招待メンバーの家系図または連鎖を表わすようになる。このような番号付けスキーマだと、図１１Ａのステップ１１２６で、ダイナミクス・マネージャ３０４Ａは従属性の衝突を解決し、完全な順位を維持する。【選択図】図１１Ａ
2011175654.tif 000002
【特許請求の範囲】
【請求項１】
ピア・ツー・ピア型コラボレーションシステムで使用するエンドポイントに称呼を割り当てるための分散型の方法において、
テレスペースの複数のメンバーの各々の各エンドポイントへユニークな称呼を割り当てるステップであって、メンバーの各称呼は、前記テレスペースに前記メンバーが加入した順序を表わし、前記テレスペースの別のメンバーであって招待する側のメンバーを含むメンバーによって加入するよう招待された各メンバーについては、前記招待する側のメンバーを表わすものであるステップと、
割り当てられた前記称呼を保存するステップと
を含むことを特徴とする方法。
【請求項２】
異なるエンドポイントの複数の前記称呼の各々は招待する側のメンバーの連鎖を表わすことを特徴とする請求項１に記載の方法。
【請求項３】
前記称呼は、前記テレスペースの創始メンバーを表わす第１の順位と、前記創始メンバーによって前記テレスペースへ加入するように招待されたメンバーを表わす少なくとも第２の順位とを含む複数の順位を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記割り当てるステップは
Ａ）前記テレスペースの作成時に、テレスペースの創始メンバーに対応するエンドポイントが、第１の順位の数字を含むユニークな称呼をそれ自体に割り当てるステップと、
Ｂ）前記テレスペースの作成に続いて、前記創始メンバーにより、前記テレスペースへ前記創始メンバーが招待した前記テレスペースの新規メンバーに対応する複数のエンドポイントの各々に対して、前記テレスペースの創始メンバーの前記第１の順位の数字と、前記新規メンバーが前記テレスペースへ加入した順序を表わすシーケンシャル順位である前記新規メンバーのエンドポイントの称呼の第２ の順位の数字とを含むユニークな称呼を割り当てるステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記割り当てるステップは、前記招待する側のメンバーの各々が、招待する側のエンドポイントが前記テレスペースへ招待する新規のテレスペース・メンバーの各々にユニークな称呼を割り当てるステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
ピア・ツー・ピア型コラボレーションシステムにおいて使用するエンドポイントへの称呼を割り当てるための分散型の方法において、
テレスペースの各々の招待する側のメンバーが、前記招待する側のメンバーが順次前記テレスペースへ招待する新規のテレスペース・メンバーの各々の各エンドポイントにユニークな称呼を割り当てるステップと、
前記招待する側のメンバーが前記テレスペースへ招待する複数のテレスペース・メンバーに対して、メンバーの各称呼は前記テレスペース内でユニークなものであることを保証するステップと
を含むことを特徴とする方法。
【請求項７】
前記保証するステップは、前記招待する側のメンバーが前記テレスペースへ招待する複数のテレスペース・メンバーに対して、メンバーの各称呼が前記コラボレーションシステムの中でユニークなものであることを保証することを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記割り当てるステップは、前記称呼を割り当てるために疑似乱数ジェネレータを使用することを含むことを特徴とする請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はインターネットなどのネットワークを介して通信できるように相互に接続されたコンピュータに関し、さらに詳しくは分散型データ・モデルに準拠してデータを調整あるいは維持するための分散型コンピュータシステムに関する。
【背景技術】
【０００２】
インターネットは、数百万のユーザ間での通信及び対話（ｉｎｔｅｒａｃｔｉｏｎ）のためのダイナミックな公共の環境を作り出した。ビジネスにおいては、インターネットによりベンダとメーカ、メーカとディストリビュータ、ディストリビュータとカスタマ、その他の関係が再定義された。個々の企業の社内にある機密ネットワークへインターネット技術が拡張され、これらは「イントラネット」あるいは「プライベート・インターネット」と呼ばれているが、会社のディレクトリ及び会社のネットワーク・インフラストラクチャを使って、新しい形で社員間、またワークグループ間でのドキュメントや情報の共有ができるようになった。オンライン・サービスたとえば電子掲示板やチャットルーム、電子商取引また製品のテクニカルサポートなどが、インターネットを介して運営されているウェブ（ＷＷＷ  （Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ））上で利用できる。
【０００３】
インターネットは、その中心に、サーバ・クライアント・アーキテクチャがあり、これは個々のクライアント（即ちインターネット・コンテンツのユーザ）がたとえばブラウザなどのコンピュータで実行可能なアプリケーションを介してサーバ（インターネット・コンテンツのプロバイダ）とインタフェースし、ウェブ・サイトからドキュメントを入手する。ブラウザはソフトウェア・プログラムで、パーソナル・コンピュータからインターネット・ドキュメントを要求、受信（たとえばダウンロード）、解釈、表示することができるようにし、また一般にインターネットを散策（ｎａｖｉｇａｔｅ）できる。ウェブ・サーバは典型的には外部プログラムを実行するための標準インタフェースを備え、最も一般的なインタフェースはＣｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ  （ＣＧＩ）である。ウェブ・サイトはドキュメントの集合で、通常はホームページと、これにリンクされるドキュメントで構成され、クライアントから離れたリモートな場所にあるサーバ上に配置されている。ドキュメントはコンパウンド・ドキュメントであっても良く、これはデータ、グラフィックス、ビデオ、サウンド、および／またはその他の形式のメディアならびに他の文書へのリンクで構成される。基本的に、ＷＷＷは相互接続されたドキュメントの、または、さらに正確にはインターネット上の様々なサイトに配置されているドキュメント・オブジェクトのウェブ（蛛の巣：ｗｅｂ）である。
【０００４】
ＷＷＷ上のドキュメント・オブジェクトの形式にはドキュメントとスクリプトとがある。スクリプトは実行可能なプログラムまたはファイルに格納された一組のコマンドであり、これがウェブ・サーバにより実行され、ドキュメントを作成し、そのドキュメントがウェブ・ブラウザへ返される。スクリプトによる代表的なアクションには、ライブラリ・ルーチンまたはその他のアプリケーションを実行してファイルまたはデータベースから情報を取り出すこと、または選択されたハイパーテキスト・リンクに対応する文書を取得することが含まれる。スクリプトは、たとえば、ユーザがウェブ・ブラウザ上で特定のハイパーテキスト・リンクを選択した時に、ウェブ・サーバ上で実行される。
【０００５】
インターネット技術の基礎となっているものは標準化の進歩であり、これにはパーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロトコル、インフラストラクチャの標記方法（たとえばＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  ＬｏｃａｔｏｒまたはＵＲＬ）が含まれる。ＵＲＬはＷＷＷにある全てのドキュメント・オブジェクトについてその位置のアドレスを提供する。ＵＲＬはドキュメント・オブジェクトを唯一無二の形で（以下、ユニークに）参照し、しばしばインターネット・プロトコルを用いたアクセス・アルゴリズムを定義する。
【０００６】
本明細書で使用されている表現として、「インターネット・プロトコル」は、インターネット上で送信するためのドキュメントを含むメッセージを生成するために一般に受け入れられて使用されたり、またはインターネット上でこうしたメッセージを送信するための、それぞれ現行のまたは将来の言語表記および現行または将来の通信プロトコルであると定義される。これらの言語表記には、たとえば、現時点ではＨｙｐｅｒｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  （ＨＴＭＬ）やｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  （ＸＭＬ）が含まれる。これらの通信プロトコルはたとえば現時点では、Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  （ＨＴＴＰ）、ＴＣＰ／ＩＰ、ＦＴＰ、ＧＯＰＨＥＲなどを含む。当業者はこれらの言語表記やプロトコルに詳しいであろう。
【０００７】
ＨＴＭＬはハイパーテキスト・ドキュメントを記述するために使用される言語で、マルチメディア・コンテンツや他のドキュメントへのリンクを含む。ＨＴＭＬドキュメントはマークアップ要素（以下、マークアップ・エレメント）の階層的セットを含み、多くのエレメントが開始タグとこれに続くコンテンツ、さらにそれに続く終了タグを備える。タグはアングル・ブラケット（＜と＞）で囲み、ドキュメントがどのような構造になっているか、ドキュメントをどのように表示するか、またハイパーテキスト・リンクのリンク先とラベルなどを表わす。マークアップ・エレメントのためのタグが存在しており、これらはたとえばタイトル、ヘッダーや、ボールド、インタリックなどのテキスト属性、リスト、パラグラフ境界、他のドキュメントへの外部リンク、また同じ文書の他の部分への内部リンク、グラフィック画像、及びその他多くのドキュメント機能などである。ＨＴＭＬを使ったプログラミングに関しては多くの成書が流通している。
【０００８】
ＸＭＬはインターネット・プロトコルに含まれるもう一つの言語表記である。ＸＭＬは、少なくとも現行バージョンでは、ＨＴＭＬと互換性があってこれを補足するものである。コンピュータに格納されていて、ＸＭＬドキュメントと呼ばれるデータ・オブジェクトのクラスを記述する、またこれらのオブジェクトを処理するプログラムの動作を記述する標準的な方法である。ＸＭＬドキュメントはエンティティ（ｅｎｔｉｔｉｅｓ）と呼ばれる格納単位から構成され、これにはテキストデータまたはバイナリデータのどちらかが含まれる。テキストは文字から構成され、その幾つかはドキュメントの文字内容を構成し、別の幾つかはマークアップ（ｍａｒｋｕｐ）を構成する。マークアップはドキュメントの記述たとえば格納レイアウトや論理構造などを記述する（以下、エンコードする）。ＸＭＬ処理装置と呼ばれるソフトウェアモジュールを使用してＸＭＬドキュメントを読み出し、その内容や構造へのアクセスを提供する。ＸＭＬに関するさらに詳しい情報はＸＭＬ仕様バージョン１．０への参照で得ることができ、＜ＨＴＴＰ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＸＭＬ＞で利用可能であり、また本明細書の参照に含めてある。
【０００９】
ウェブ・サーバとウェブ・ブラウザは代表的にはＨＴＴＰメッセージプロトコルおよびその基盤となるインターネットのＴＣＰ／ＩＰデータトランスポート・プロトコルを用いて通信する。ＨＴＴＰにおいて、ウェブ・ブラウザはウェブ・サーバへの接続を確立してからＨＴＴＰ要求メッセージをサーバに送出する。要求メッセージに呼応して、ウェブ・サーバは認証をチェックし、たとえばＵＲＬで識別されるドキュメントをダウンロードするなどの要求された動作を実行し、要求された動作で得られたＨＴＭＬドキュメントあるいはエラーメッセージのどちらかを含むＨＴＴＰ応答メッセージを返す。返されたドキュメントは単にウェブ・サーバ上に格納されているスタティック（静的）ファイルであったり、要求メッセージに呼応して呼び出されたスクリプトを使用して動的に生成されることがある。
【００１０】
インターネットを活用するために、インターネット・プロトコルに準拠したツールや資源が開発されており、これには企業で必須のアプリケーションたとえばｅメール（ｅ−ｍａｉｌ）が含まれる。ｅメールというのは電子メールのことで、これを用いて選択したアドレスで電子的にドキュメントを送受信する。インターネットを使う対話の大半が、「ドキュメントの送受信」モデルに従ったｅメールの使用や、その他のブラウザを使うメディアであると予想されていた。おそらくはこのモデルのために、ユーザはインターネットを本質的に「ピア・ツー・ピア」的なものであり、これによって個人が他の個人によって提供されたドキュメントにアクセスできるものであり、しかも、もっと大きな権限を有する者による干渉を受けないでできるものであると見なすことが多い。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
インターネットはユーザに娯楽を提供したり通信の有用な方法を提供する上でダイナミックかつフレキシブルなものであるが、ユーザの要求の全部を満たすことはできない。ユーザはますますインターネットを通して対話するようになるが、もっと在来型の方法たとえばマルチメディア（電話、ファックス、ホワイトボード）のものやマルチテンポラル（リアルタイム、オーバーナイト・メール）なもの、またその他形式にとらわれない通信手段を使うことにより、インターネット以外での対話も引き続き行われている。
【００１２】
共有されるプライベート空間での個人や中小グループ間でのパーソナルでプライベートな通信やその他共有される相互の活動にインターネットに基づくパラダイムを拡張することが望ましい。このような対話は、参加者のパーソナルコンピュータ間またはその他のネットワーク接続可能なデバイス間で即時的、直接的、機密的に行なわれるのが望ましく、これらの対話は、通信が傍受されたり機密性が侵害されたりするような第三者のウェブ・サイトへとインターネット上のトラフィックが集中させるようなサーバ・ボトルネックとは何ら関わりを持たないのが良い。
【００１３】
また様々な遠隔地（以下、リモートサイト）にいるユーザがピア・ツー・ピアの形式でドキュメントを共有し編集できるようにする一方で、ローカルサイトにおいてドキュメントの一貫したコピーを維持することのできる技術を提供するのも望ましい。このような技術ではユーザの誰もがドキュメントに関する変更要求を発行でき、変更要求が発行された時点でサイトがネットワークから切断されても当該変更が調整された方法で全てのローカルサイトにあるコピーに対して非同期的に行なうことができる。この技術は全てのサイトにわたって高いレベルでのデータ一貫性を提供することにより各々のサイトが様々な地理的に分散したユーザによる閲覧および／または編集のために基本的に同じドキュメントを提示することができるようになる。
【課題を解決するための手段】
【００１４】
本発明はパーソナルコンピュータ・システム、通信装置、またはその他のネットワーク接続可能なデバイスで動作可能で、遠隔地に居る他のユーザと共有して特定のタスクたとえば「チャット」、ゲーム、またはビジネスアプリケーションを実行するためのアクティビティとよばれる装置に関するものである。アクティビティはデルタと呼ばれるデータ変更要求をユーザとの対話呼応して生成するためのツールを含む。アクティビティはデータ・モデルに準拠して不揮発性で永続的であることが望ましいメモリにデータを保存するためのデータ変更エンジンも備える。データ変更エンジンはツールからデルタを受信して、そのデルタにその要求を実行するアクティビティ特有のコマンドを提供し、デルタの実行に起因するデータ変更をツールへ通知するためのツール・エンドを含む。データ変更エンジンはダイナミクス・マネージャからデータ変更指示を受信してからデルタを実行する、即ちデルタのコマンドを実行して要求された変更をデータに加えるためのダイナミクス・マネージャ・エンドも含む。
【００１５】
別の観点においては、本発明は「テレスペース」と呼ばれる共有プライベート空間で個人間及び小グループ間での通信及びその他の共有活動及び相互活動を提供するためのシステムに関する。本発明のシステムにおいては、テレスペースの参加者またはメンバーは、ネットワーク接続可能なデバイスを介して対話し、このデバイスはたとえばインターネットなどのネットワーク上で互いに通信してテレスペース・データのローカルコピーを個々に格納する。各々のテレスペースはテレスペースのメンバーのネットワーク接続可能なデバイスの各々の上で動作可能な１つ以上のアクティビティの具現化されたもの（以下、インスタンシエーション）である。各々のアクティビティはテレスペースのメンバーとの対話に呼応してデータ変更要求またはデルタを開始するための１つ以上のツールを含む。各々のアクティビティはまた、ツールとは別に、共通データ・モデルに準拠したテレスペース・データのローカルコピーを保持するための１つ以上のデータ変更エンジンも含む。このデータ・モデルはたとえば、アクティビティに固有であって、テレスペース全体にわたるものであることが望ましい。各々のネットワーク接続可能なデバイスもデルタに呼応して、要求された変更をデータのローカルコピーに適用することによりデータ変更エンジンに指示を出してデルタを実行させるためと、様々なネットワーク接続可能なデバイスからのデルタの実行を調整するためのダイナミクス・マネージャを含む。
【００１６】
さらに別の観点においては、本発明は望ましくはインターネット・プロトコルに従って通信するように接続された望ましくはネットワーク接続可能な別の場所にある複数のデバイスを含むネットワーク化されたシステムにおいて実施できる。ネットワーク接続可能な各のデバイスは（ａ）共通データ・モデルに準拠してアクティビティに関連するデータのローカルコピーを格納するためのメモリ、（ｂ）前述のデータ変更エンジンに対応する１つ以上のツールを各々が含む１つ以上のアクティビティ、（ｃ）デルタが関係するテレスペースに参加するネットワーク化されたシステムのネットワーク接続可能な全てのデバイスの間でデルタを共有させるための通信マネージャ、（ｄ）ローカルに生成されたデルタと遠隔地で生成された（以下、リモート生成された）デルタの両方の実行を調整するためのダイナミクス・マネージャ、を含む。ネットワーク化されたシステムのネットワーク接続可能なデバイスのどれででもユーザの対話を開始してその結果としてのデルタを生成することができ、このときのデルタは望ましくはネットワーク上のデバイスの各々に送信される。ダイナミクス・マネージャはローカルのデータ変更エンジンの動作を指示し、望ましくはデルタの実行に優先順位を付けてネットワーク化されたシステム全体でのデータの実質的な一貫性を維持する。ネットワーク化されたシステムは様々なリモートサイトにいるユーザに対して、たとえばデータを共有して編集したり、ピア・ツー・ピア型の形式でその他の活動を独立して実行できるようにする一方で、ネットワークから切断されている時でも各々のネットワーク接続可能なデバイスで使用するデータの実質的に一貫したコピーを保持することができるようにする。
【００１７】
さらに別の観点においては、本発明は個人間の対話のためのアクティビティに基づくコラボレーションシステム（ＡＢＣシステム）として実装可能である。ＡＢＣシステムはたとえば公衆ネットワーク（たとえばインターネットまたはワイドエリアネットワーク（ＷＡＮ））経由またはプライベート・ネットワーク（ローカル・エリア・ネットワーク（ＬＡＮ）またはイントラネット）経由で、ケーブル、光ファイバー、赤外線（ＩＲ）またはその他の形式の通信リンクにより前述のネットワーク化されたシステムを形成するように接続可能なネットワーク接続可能な複数のデバイスを含む。ネットワーク接続可能な各々のデバイスは前述のメモリと、１つ以上のダイナミクス・マネージャを含むフレームワークを装備している。ネットワーク接続可能なデバイスは公衆ネットワーク・インフラストラクチャ、パーソナル・デスクトップ・アプリケーション、及びインフラストラクチャ（時に「パーソナル・インターネット」と呼ばれることがある）、また適用可能なら企業内イントラネットともプラグイン式に互換性を有するものが望ましい。ＡＢＣシステムは動的に挿入可能型アクティビティ・コンポーネント（以下、ダイナミックなスナップイン・アクティビティ・コンポーネント）を使用するのが望ましく、各々がたとえば「チャット」、ドキュメント編集、ゲーム、などの特定のタスクを実行する。アクティビティ・コンポーネントはたとえばシュリンクラップ製品として利用できたりまたはたとえばインターネットなどのネットワーク上からダウンロードできるソフトウェアを含むことができる。アクティビティ・コンポーネントはフレームワークと共通のＡＰＩ（アプリケーション・プログラミング・インタフェース）を介して動作可能である。したがって、フレームワークはアクティビティ・コンポーネントの形をとるアプリケーションのためのプラットフォームであると見なすことができまたそのように機能する。
【００１８】
本発明のさらに別の観点では、ＡＢＣシステム全体で高レベルのデータ一貫性を維持するための分散技術に関する。各々のピア・ユニットにおいて、ダイナミクス・マネージャはデータ変更要求を実行する順序を決定してデータの一貫性を促進（ｐｒｏｍｏｔｅ）するデータ変更要求優先順位スキーマを実現する。データ変更要求優先順位方式の代表的な実施態様においては、各々のデータ変更要求は要求シーケンス番号情報と従属情報とを有する（含むのが望ましい）。ダイナミクス・マネージャは適当なエンジンに対してこの情報に応じてデータ変更を行なわせ、ロールバック（変更取り消し（ｕｎｄｏ））させ、またやり直し（変更の再実行（ｒｅｄｏ））を行なわせることができる。従属情報はたとえば単一の優先データ変更要求を指定することができ、この場合ダイナミクス・マネージャは優先するデータ変更要求に対応するピア・ユニットで実際に処理されてからその優先要求に従属するデータ変更要求を処理するように保証する。同じ優先要求を従属先とするデータ変更要求間で従属性の衝突がある場合、従属性衝突解決スキーマを使用できる。たとえば、日付またはテレスペースのメンバーシップのスポンサー、エンドポイントの特性（たとえばジョブのタイトル、ワークグループ、または部門）、要求された変更の性質またはドキュメント位置、またはその他の根拠に基づいて優先権を付与することができる。
【００１９】
つまり、本発明はそれぞれ別個の商業製品やサービスとして実現可能で、これには個々のアクティビティ・コンポーネント、ネットワーク接続可能な個々のデバイス用のフレームワークおよび／またはネットワーク化されたシステムまたはＡＢＣシステム、ならびにシステムを構成するデバイス間の対話を行なうための通信サービスの提供を含む。
【図面の簡単な説明】
【００２０】
【図１】図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図である。
【図２】図２は、図１のコンピュータ・システムで実行される従来のアプリケーションのブロック図で、制御モジュールはディスプレイまたはその他のユーザ・インタフェースとインタフェースすること及びデータ・モデルにしたがってデータを維持することを担当する。
【図３】図３は、インターネット・ベースのシステムのブロック図で、ＷＷＷ用のクライアントサーバ・システムと、本発明の実施態様によるパーソナル・ウェブのためのピア・ツー・ピアシステムとの両方を示す。
【図４】図４は、本発明の実施態様による図１のコンピュータ・システムで実装されるＡＢＣシステムの一部のブロック図である。
【図５】図５は、図１のコンピュータ・システムで実装されるＡＢＣシステムの一部のブロック図で本発明の実施態様による代表的テレスペース・アプリケーションを示す。
【図６】図６は、図５のチェス・テレスペースで実装されるＡＢＣシステムの一部のブロック図である。
【図７】図７は、図４のＡＢＣシステムの一部を含むフレームワーク７００のブロック図である。
【図８】図８は、ピア・ユニット間の通信に関係する図４のＡＢＣシステムの部分の実施態様のブロック図である。
【図９】図９は、図４のＡＢＣシステムで処理するデルタの代表的フォーマットを示す略図である。
【図１０】図１０は、図４のＡＢＣシステムで処理するデルタをサポートするメモリ構造のブロック図である。
【図１１Ａ】図１１Ａは、本発明の実施態様による図４のＡＢＣシステムによるデルタ処理の方法を示すフローチャートである。
【図１１Ｂ】図１１Ｂは、本発明の実施態様による図４のＡＢＣシステムによるデルタ処理の方法を示すフローチャートである。
【図１２】図１２は、図１１の方法において従属性の衝突を解決するためのフローチャートである。
【発明を実施するための形態】
【００２１】
Ａ．術語
最初に、本明細書で使用している幾つかの術語と略語を紹介するのが有用であろう。これには以下を含む：アクティビティ、クライアント、通信マネージャ、コンポーネント、コントローラ、デルタ、デバイス、ダイナミクス・マネージャ、エンジン、フレームワーク、アイデンティティ、メンバー、ナビゲーション、人、サーバ、テレスペース、ツール、ＵＲＬ、ＸＭＬ。
【００２２】
アクティビティ（Ａｃｔｉｖｉｔｙ）は、あるユーザが他のユーザと対話するために実際にはＡＢＣシステムで何をするかを表わす。術語「アクティビティ」は状況によって二つの意味のどちらかを取ることができる。「アウトサイド・ビュー」からは、ＡＢＣシステムとコンピュータ・ユーザとの間のランタイムの対話を意味する、たとえばこの種のアクティビティでは共有ホワイトボードに描画するのをユーザに許可したり、または二人以上のユーザがリアルタイムでチャットするのを許可する。この意味でのアクティビティはまたバックグラウンド・サービス（即ちエージェント）であっても良い。これはローカルデバイスまたはサーバデバイス上でユーザの側で動作し、たとえばアーカイブサーバ・エージェント、または受信ＦＡＸエージェントなどである。ソフトウェア設計者の「インサイド・ビュー」からは、「アクティビティ」はユーザのパーソナル・コンピュータまたはその他の形態の装置上で動作することができ決まったタスクを実行するモジュール化されたプログラムであってコンピュータで実行可能なプログラムを表わす。この意味でのアクティビティはツールとエンジンという２種類のコンポーネントからなり、これらは設計時に統合されて「アクティビティ・テンプレート」を作成する。アクティビティ・テンプレートはたとえばシュリンクラップ・ソフトウェアとして、またはウェブからダウンロードできるソフトウェアとして、など多くの方法で配布することができる。ワープロ、スプレッドシートなどに使用するため広く配布されるプログラムはＡＢＣシステムで使用できるように設計されたバージョンであって、ＡＢＣシステムプログラマ・インタフェースに適合するアクティビティ・テンプレートの形で販売されるバージョンを有するものとして考えている。
【００２３】
クライアント（Ｃｌｉｅｎｔ）は、ユーザのパーソナル・コンピュータ、通信機器、またはその他の形のデバイスで、ヒトとの対話ができ、ネットワークたとえばインターネットに接続可能なものを表わす。ユーザのパーソナル・コンピュータ上で実行されるバックグラウンド・プログラムは「クライアント・サービス・コントローラ」と呼ばれる。ユーザのパーソナル・コンピュータ上で実行されるフォアグラウンドのユーザ・インタフェース（ＵＩ）プログラムは「クライアントＵＩコントローラ」と呼ばれる。
【００２４】
通信マネージャ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｍａｎａｇｅｒ）は、しかるべき宛先とのデルタの送受信を指示するメカニズムを表わす。通信マネージャはたとえば、コンピュータで実行可能なプログラムとして実装することができ、これが、ネットワークたとえばインターネット上で送信するためにツール／エンジンのペアで作成されてローカルに開始したデルタを別のリモート・パーソナル・コンピュータへまたは他の形のネットワーク接続可能なデバイスへ送信する、またはそのリモートデバイスがネットワークに接続されていない場合にはリレー装置へ送信するもので、またこれはネットワークたとえばインターネット上で受信されるリモートで生成されたデルタをダイナミクス・マネージャへ送信する。
【００２５】
コンポーネント（Ｃｏｍｐｏｎｅｎｔ）は、コンピュータで実行可能なプログラムとアクティビティ内部で使用されるその資源を表わす。全てのコンポーネントはＵＲＬで識別される。ウェブがコンポーネントのグローバル・リポジトリで、ＡＢＣシステムの適当なコンポーネント・プラットフォームへ確実にダウンロード可能なバージョンを備えるものとして考えている。
【００２６】
コンピュータ（Ｃｏｍｐｕｔｅｒ）は、以下で定義するような装置を表わす。
【００２７】
コントローラ（Ｃｏｎｔｒｏｌｌｅｒ）は、トップレベルにあるプログラムであってコンピュータで実行可能なプログラムを表わし、これはＡＢＣシステムの「内部」機能を駆動する。コントローラは任意のプラットフォームたとえばＵＮＩＸ（登録商標）のデーモン・コントローラまたはインテル社製マイクロプロセッサ搭載コンピュータ・システム上で動作するマイクロソフト・ウインドウズ（ＴＭ）用コントローラとしてチューニングされる。一般的な２種類のコントローラとしては、一般にユーザからは見えないバックグラウンド・プロセスとして動作するサービス・コントローラと、ユーザが対話的に制御するユーザ・インタフェース（ＵＩ）コントローラがある。
【００２８】
デルタ（Ｄｅｌｔａ）は、１つまたはそれ以上のツールからエンジン宛てのデータ変更要求（即ちデータに対して希望する変更についての通知またはプロンプト）を内包する自己内包型のデータユニットを表わす。ツールはユーザとの対話に応答してダイナミクス・マネージャによるデルタ作成を開始し、後述するように、ダイナミクス・マネージャの制御下で非同期実行のためにこれらをエンジンに送信する。デルタは制御情報を提供するヘッダ部分と、要求が関連するデータに関する情報を提供するペイロード部分とを含む特定のフォーマットを持っている。個々のデルタは１つまたはそれ以上のペイロードを持つことができ、多数のペイロードを使用する場合には各々をユニークなデバイス機能またはユーザの役割を有するテレスペース・メンバーあてに指定できる。ツールはユーザへの表示用またはその他の形でのプレゼンテーションを行なうためエンジンから潜在的データ変更に関する情報を要求し、デルタが表示を変更させた時に非同期的に通知される。
【００２９】
デバイス（Ｄｅｖｉｃｅ）は、たとえばパーソナル・コンピュータ（ｐｃ）や通信機器など、本明細書では文脈からして特に別のものが示されない限りは、通常ネットワーク接続可能な、即ちネットワーク接続可能な他のデバイスとネットワーク上たとえばインターネット上でインターネット・プロトコルを使用して通信することができるような物理的ハードウェア装置を表わす。全てのデバイスにはユニークな識別コードがＡＢＣシステムによって割り当てられ、ＵＲＬを有し、デバイスを使用する者とは区別される。デバイスは潜在的に多くのテレスペースをホスティングする。デバイスは、たとえば、ｐｃであったり、セルラホン、ファックス、ハンドヘルド・オーガナイザ、ケーブルテレビのセットトップ・ボックス、エンターテイメント用電子ユニット（たとえば電子玩具やゲームと、ステレオ装置、またはこれら以外の同様にネットワーク接続可能な機器、装置、製品など）のことがある。
【００３０】
ダイナミクス・マネージャ（Ｄｙｎａｍｉｃｓ  ｍａｎａｇｅｒ）は、ＡＢＣシステムのフレームワークの一部を表わし、デルタの作成を支援したりデルタの実行を調整する。ダイナミクス・マネージャはたとえば、ユーザのパーソナル・コンピュータ上でまたはその他の形態を有しネットワーク接続可能なデバイス上で動作するコンピュータで実行可能なプログラムとして実装することができる。
【００３１】
エンドポイント（Ｅｎｄｐｏｉｎｔ）は、デバイスと人のユニークなペアを表わす。ＡＢＣシステムでは、ある１つのデバイスの多数のユーザの中から一人の人をユニークに識別する方法として、またはその同じ人によって使用される多数のコンピュータの中から１つのデバイスや複数のデバイスを識別する方法として、この概念を使用する。
【００３２】
エンジン（Ｅｎｇｉｎｅ）は、ＡＢＣシステム内部の永続的格納及びデータ構造の管理及び変更を実現するものであってアクティビティの「下半分」と呼ばれるものを表わす。エンジンはコンポーネントとしてパッケージされ、それ自体にはユーザ・インタフェースがなく、ユーザ・インタフェースについては対応するツールに依存し、実質的に移植可能である。エンジンは対応するツールを機能させるためにのみ存在するのが望ましい。エンジンはユニバーサル同期（ｕｎｉｖｅｒｓａｌ  ｓｙｎｃｈｒｏｎｙ）した状態で動作するのが望ましい。
【００３３】
フレームワーク（Ｆｒａｍｅｗｏｒｋ）は、ＡＢＣシステムの「内部動作」を表わし、ダイナミクス・マネージャを始めそのサブシステムのほとんどのものを含んでいるが、ユーザ・インタフェースはない。フレームワークはユーザのパーソナル・コンピュータ上またはその他の形態のネットワーク接続可能なデバイス上で動作することのできるものでコンピュータで実行可能なプログラムであり論理的には高レベルのコントローラとアクティビティの間に位置する。
【００３４】
アイデンティティ（Ｉｄｅｎｔｉｔｙ）は、一般に「人（ｐｅｒｓｏｎ）」と同義語だが、一般にＵＲＬで表わされるもので他の人がある人を認知できる１つの名前を指す。この概念が使用される理由としては、ＡＢＣシステムではある人が多くのアイデンティティまたは別名を持つことができ、またたとえば多くの異なるＵＲＬを持てるという考え方を採用しているためである。
【００３５】
メンバー（Ｍｅｍｂｅｒ）は、テレスペース内部の参加者またはテレスペースの加入者を表わし、一般にテレスペースのメンバーシップを表わす場合にはエンドポイントの人の部分（デバイス部分と区別して）と同義語である。
【００３６】
ナビゲーション（Ｎａｖｉｇａｔｉｏｎ）はＵＲＬ間を移動する動作を表わし、ＡＢＣシステムではウェブ・ブラウザによるウェブページ間、ウェブサイト間のナビゲーションと類似している。
【００３７】
人（Ｐｅｒｓｏｎ）は、人間、または人間の代理として作用するサーバを指し、一般にテレスペース内部のアクティビティに参加している者を指す。各々の人は１つまたはそれ以上のアイデンティティを有し、その各々はＵＲＬでユニークに識別される。
【００３８】
サーバ（Ｓｅｒｖｅｒ）は、通信チャンネルを介する場合を除き普通は人間との直接対話ができないがサービス・コントローラのもとでバックグラウンド・プログラムとしてのみ実行することができるデバイスを指す。
【００３９】
テレスペース（Ｔｅｌｅｓｐａｃｅ）は、仮想空間であって、１つ以上のアクティビティに参加するために人びとが集まり、人びとが何らかのものを共有する仮想空間を指す。テレスペースとアクティビティの結果はユーザのパーソナル・コンピュータ上またはその他の形態のネットワーク接続可能なデバイス上のメモリに永続的に格納される。テレスペースは、一般に、あるユーザのデバイスと他の人達のデバイスの間で同期を保っている。テレスペースは「メンバーシップ」の論理的単位またアクティビティへのアクセスを表わす。テレスペースは１つ以上のアクティビティのインスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）である。
【００４０】
ツール（Ｔｏｏｌ）は、アクティビティのユーザ・インタフェースを実現するものであってアクティビティの「上半分」と呼ばれるものを指す。ツールはコンポーネントとしてパッケージされ、ユーザのジェスチャーに応答してデルタの作成を開始し、個々のアクティビティの対応するエンジンと対話して特定のタスクを実行する。
【００４１】
ＵＲＬは、ｕｎｉｖｅｒｓａｌ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ（汎用資源識別子）の略語で、ドキュメントなどの資源の構造化されたユニークなアドレスであり、また場合によっては資源を取り扱うときの方法を表わす。ＵＲＬは本明細書において実質的に全ての永続的オブジェクト、ユーザから見えるオブジェクト、及び外部プログラムから見えるオブジェクトについて使用される。
【００４２】
ＸＭＬは、前述の通り、拡張マークアップ言語（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）の略語で、ウェブ上で使用することを想定したＳＧＭＬから派生した標準化され的構造化されたデータ・フォーマットである。状況によってはＡＢＣシステムで使用されるメモリ内のオブジェクト構造を表わすこともあり、これはＸＭＬ標準のセマンティクス（ｓｅｍａｎｔｉｃｓ）に準拠するものである。多くのＸＭＬの概念が本明細書で使用されており、たとえばドキュメント、エレメント、タグ、属性、値、コンテンツ、エンティティ、リンク、ポインタなどがある。ＸＭＬは本明細書ではたとえばドキュメント内のデータを構造化するために使用される。
【００４３】
Ｂ．従来のコンピュータ・システム
図１は、代表的なコンピュータ・システム１００の従来型のシステム・アーキテクチャを図で表わしたものであり、開示された本発明をこれに実装することができる。図１に例示したコンピュータ・システムは説明の目的でのみ議論するが、本発明を制限するものとして見なすべきではない。本発明はさらにコンピュータ・システムとして従来考えられてきたデバイスに制限されるものではなく、これはたとえばビデオゲーム・コンソール、パーソナル機器、またはケーブルテレビのセットトップボックスなどを含む各種のネットワーク接続可能なデバイスのいずれにおいても本発明を実装できるためである。以下の説明は特定のコンピュータ・システムを記述する際に共通に使用される術語を示しているが、説明される概念は図１に図示したものとは異なるアーキテクチャを有する他のコンピュータ・システムにも等しく適用されるものである。たとえば、ケーブルテレビのセットトップボックスは大容量格納機能を含まないがデジタル信号プロセッサを内蔵したビデオチューナを含んでいる。
【００４４】
コンピュータ・システム１００は、従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報格納用のランダム・アクセス・メモリ（ＲＡＭ）１１０、永久的な情報格納用のリード・オンリー・メモリ（ＲＯＭ）１１５を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５はバス１３０を制御するために提供されており、割り込みコントローラ１３５は他のシステム・コンポーネントからの様々な割り込み信号を受信して処理するために使用される。
【００４５】
大容量格納はディスケット１４２、ＣＤ−ＲＯＭ１４７またはハードディスク装置１５２によって提供できる。データやソフトウェアはリムーバブル・メディアたとえばディスケット１４２やＣＤ−ＲＯＭ１４７を経由してクライアント・コンピュータ１００と交換できる。ディスケット１４２はディスケットドライブ装置１４１に挿入することができ、ディスケットドライブ装置１４１はコントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤ−ＲＯＭ１４７はＣＤ−ＲＯＭドライブ装置１４６に挿入することができ、ＣＤ−ＲＯＭドライブ装置１４６はコントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は固定ディスクドライブ装置１５１の一部であり、これはコントローラ１５０によってバス１３０へ接続されている。
【００４６】
クライアント・コンピュータ１００へのユーザ入力は多数のデバイスによって提供され得る。たとえば、キーボード１５６とマウス１５７はキーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６はマイクロホン及びスピーカの両方として機能することができるもので、オーディオ・コントローラ１９７を介してバス１３０へ接続されている。他の入力デバイスたとえばペンおよび／またはタブレットや、音声入力用マイクロホンなどを適当なコントローラとバス１３０経由でクライアント・コンピュータ１００へ接続することができるのは当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリアクセスを実行するために提供される。視覚表示はビデオコントローラ１６５によって生成され、これがビデオ・ディスプレイ１７０を制御する。
【００４７】
コンピュータ・システム１００はまたクライアント・コンピュータ１００がバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用する。
【００４８】
コンピュータ・システム１００は一般にオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。
【００４９】
Ｃ．データ・モデルを制御する従来の方法
図２は「モデル・ビュー・コントローラ」として周知の技術を使ったデータ・モデルを制御する従来のシステム２００を示す。システム２００において、データ・モデル・モジュール２０２はたとえばデータベースなどのデータをデータ・モデルにしたがって格納し維持する。コントローラ・モジュール２０４はローカルに開始したイベント２０６（たとえばユーザ入力など）やまたは外部で開始したイベント２０８（たとえばリモートのコンピュータ・システムから受信したイベント通知など）に応じて、「現在値をセットする」コマンドをデータ・モデル・モジュール２０２に指示して格納しているデータへの変更を行なわせる。コントローラ・モジュール２０４はデータ変更を出力装置たとえばディスプレイ２０６などに通知する。ディスプレイ２０６はデータ・モデル・モジュール２０２から変更されたデータを取得してデータの表示を更新し、現在のデータがユーザから観察できるようにする。前述の技術は厳密にイベント駆動型であり動作においてリニアである。典型的には、データへの変更をコントローラ・モジュール２０４に指示させる内部または外部のイベントはコントローラ・モジュール２０４のＦＩＦＯ（先入れ先出し）型バッファに格納され、次いでイベント通知がコントローラモジュールに到達した順序で処理される。また典型的には、グローバルな一貫性問題、即ちシステム２００内のモデルデータのコピーが他のリモートシステムにあるデータと一致していることを保証する対応がシステム２００には行なわれていない。
【００５０】
システム２００で例示したようなデータ・モデルを制御する従来のアプローチは、コンピュータ・システムがメインフレームとパーソナル・コンピュータとを問わず相互に隔絶されて動作していた時代には適切だった。インターネットの発達とともに、コンピュータ・ユーザはコラボレーションするときのもっと優れた方法を要求しており、本発明では、データ・モデルに対してデータ変更エンジンによって行なわれる変更にダイナミクス・マネージャが介在する「モデル介在型制御」と呼べるようなものを提供する。
【００５１】
Ｄ．コンピュータ間動作のインターネット・パラダイム
図３はインターネット環境３００を示したもので、本発明が有利に使用できるものである。ユーザの観点からすると、従来のクライアントサーバ・ビュー３０２において、個別のクライアント３０６、３０８はインターネット３０９上でサーバ３１０と別々に通信する。各々のクライアント３０６、３０８はインターネット３０９経由でサーバへ要求を発信し、各々について、サーバ上に格納されたドキュメントをインターネット３０９上でクライアントへ提供することにより、サーバ３１０がこの要求に応答する。各々のサーバ３１０とクライアント３０６、３０８は、図１に図示したようなパーソナル・コンピュータとして実現でき（サーバの場合には幾つかのＵＩコンポーネントはオプションとなる）、適当なプログラムたとえばクライアント・ブラウザ３１１および／または後述するようなその他の通信インタフェースの実行が可能である。インターネット使用のピア・ツー・ピア・ビュー３１２においては、ユーザのコンピュータ・システムはピア・ユニット３１４Ａ〜Ｄを構成し、インターネット経由の通信は一つのピア・ユニットから別のピア・ユニットへ明らかに介在するものがなくても配向できる。
各々のピア・ユニット３１４Ａ〜Ｄは図１に図示したようなパーソナル・コンピュータとして、またはその他の形態のネットワーク接続可能なデバイスとして実現可能である。本発明はクライアント３０６、３０８、またはピア・ユニット３１４Ａ〜Ｄのいずれかで有利なるように実現可能であるが、このような説明はシステムのピア・ツー・ピア・ビューでの実装が中心となる。
【００５２】
さらに詳細には以下で説明するが、このようなピア・ツー・ピア通信は直接またはリレー・デバイス３１６経由で行なうことができる。リレー・デバイス３１６は「ストア・アンド・フォワード」型が望ましく、これはインターネットから一時的に切断されているピア・ユニット３１４へ向けられたメッセージを格納し、その後再接続した時にそのピア・ユニットへメッセージを転送することができるものである。
【００５３】
Ｅ．ＡＢＣシステムのアーキテクチャと動作
図４はピア・ユニット３１４Ａ〜Ｄの一つ、たとえばピア・ユニット３１４Ａにおいて実現されるＡＢＣシステム４００を示す。ピア・ユニット３１４Ａ上のＡＢＣシステムはフレームワーク４０２、少なくとも一つのテレスペース４０４、及びユーザ・インタフェース４０６を備える。フレームワーク４０２は多数のテレスペース４０４にサービスするためのプラットフォームを提供するのが望ましい。フレームワーク４０２は、アクティビティが動作しフレームワーク・コンポーネントと通信するプログラマ・インタフェースを備えるモジュラー構造が望ましい。
【００５４】
フレームワーク４０２はユーザ・インタフェース・マネージャ４０８、アイデンティティ・マネージャ４１０、テレスペース・マネージャ４１２、アクティビティ・マネージャ４１４、格納・マネージャ４１６、コントローラ・サービス・マネージャ４１８、ダイナミクス・マネージャ４２０、通信マネージャ４２２を含む。       
【００５５】
ユーザ・インタフェース（ＵＩ）マネージャ４０８は多数のユーザ・インタフェース・コントローラ（図示していない）の共有サービスの管理を担当する。ＵＩマネージャ４０８はディスプレイ・ウインドウの窓ガラスの向こうにあるアクティビティのレイアウトを管理し、それ以外にユーザ・インタフェースとして期待する「ルック・アンド・フィール」を提供する。ＵＩマネージャ４０８はアクティビティのナビゲーション（たとえばｇｏ（行く）、ｎｅｘｔ（次）、ｐｒｅｖｉｏｕｓ（前））なども管理しナビゲーション履歴を保持する。
【００５６】
アイデンティティ・マネージャ４１０はあるテレスペース・メンバーのアイデンティティの保存を担当する。前述したように、アイデンティティは名前であり、また対応するＵＲＬであり、これにより各々のユーザが他のユーザによって認識される。個々のユーザは１つまたは多数のアイデンティティを持つことがある。アイデンティティ・マネージャ４１０はアイデンティティのレコードまたはテーブルを望ましくはＸＭＬで保持する。アイデンティティ・マネージャ４１０はまたテレスペース・メンバーのＵＲＬとこれらに対応するデバイスのＵＲＬのレコードまたはテーブルを望ましくはＸＭＬで保存する。これ以外に、独立したメンバー・マネージャを実装することができる。
【００５７】
テレスペース・マネージャ４１２はピア・ユニット３１４Ａで開くことができるテレスペース４０４の各々の管理を担当する。各々のテレスペース４０４は１つまたはそれ以上のアクティビティのインスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）である。各々のテレスペース４０４は対応するアクティビティ・マネージャ４１４を有している。
【００５８】
アクティビティ・マネージャ４１４は（ａ）テレスペースへ新規アクティビティを追加する、（ｂ）テレスペースで既存のアクティビティを開く、（ｃ）アクティビティ・テンプレートの新しいバージョンからテレスペースのアクティビティを更新する。新規のアクティビティを追加するには、アクティビティ・マネージャ４１４にアクティビティ・テンプレートのＵＲＬを提供してテンプレートを開き、テンプレート情報（たとえばコンポーネントＵＲＬ）を抽出してテレスペースへ伝搬する。テンプレートはあるテレスペースについての初期アクティビティ構成を定義する。ユーザは後で必要に応じてテレスペース４０４へさらにアクティビティを追加できる。追加した後、アクティビティはテレスペースの「一部」となりテレスペースのメンバー全員から見えるようになる。テレスペースはアクティビティ・マネージャを識別してアクティビティ・マネージャとデータを結合するタグを備える。望ましくは、各々のドキュメントはローカル・レジストリをこれにリンクし、ＸＭＬタグの名前がレジストリに保存されるようにして、拡張可能な、プラットホームに依存しない方法でドキュメントとこれに対応するテレスペースの間のマッピング（参照ポインタまたは連係）を表現するようにする。各々のテレスペース・メンバーはその人のピア・ユニット３１４Ａ〜Ｄで利用できるテレスペースのフレームワークとアクティビティ・テンプレートを有する。
【００５９】
各々のアクティビティはツール４２４などのツールと、エンジン４２６などのエンジンとを含む。ツール４２４はアクティビティにユーザ・インタフェース（ＵＩ）機能を提供してメンバーとＵＩ４０６経由で対話する。ＵＩを介した対話はたとえばキーボード１５６経由で（図１）またはマウス１５７経由で（図１）開始されたＵＩイベントを含む。このようなＵＩイベントに応答して、ツール４２４はこれに対応するエンジン４２６に対してデータ・モデル変更を実行するように要求し、データ変更が起こった時に非同期的にＵＩを更新する非同期データ変更通知をエンジン４２６に予約する。ツール４２４もコントローラ・サービス・マネージャ４１８の指示の下に提供されるバックグラウンドサービスと対話するためのアプリケーション・プログラム・インタフェース（ＡＰＩ）を実装している。エンジン４２６はテレスペース４０４をサポートするデータの維持と変更、および／またはツールを介して得られたユーザとの対話からの結果の維持と変更を担当する。後述するように、エンジン４２６は永続的モデルデータを変更することと非同期データ変更通知をツール４２４に送出することをどちらもダイナミクス・マネージャ４２０の指示制御下で行なうことができる。格納・マネージャ４１６は格納されたデータへのアクセスを制御する。
【００６０】
アクティビティ・テンプレートの作成について、ソフトウェア・デベロッパはフレームワーク内で使用するツールとエンジンを書いたり取り込んだりできる。アクティビティ・テンプレートはアクティビティを含むツール・コンポーネント及びエンジン・コンポーネントの永続的表現である。アクティビティ・テンプレートはたとえばシュリンク・ラップしたソフトウェアとして配布したりたとえばインターネット上で遠隔地のサーバからピア・ユニット３１４Ａにダウンロードしたりできる。アクティビティ・コンポーネントはウェブ・ドキュメントであると考えることができ、ＵＲＬ経由で永続的に表現される。アクティビティ・テンプレートそれ自体がＵＲＬを有するのが望ましく、これによりアクティビティ設計の変更を追跡できるようになる。アクティビティ・テンプレートは単一のアクティビティ・テンプレートかまたはアクティビティ集合体テンプレートであり得る。単一のアクティビティ・テンプレートはたとえば「チャット」などの一つのアクティビティにだけに関連する。それに対してアクティビティ集合体テンプレートは「チャット及びアウトライン」などといったアクティビティの集合体に関連する。
【００６１】
使用するときは、ＡＢＣシステム４００はアイデンティティ・マネージャ４１０経由でメンバーのアイデンティティを取得し、テレスペース・マネージャを開き、テレスペース・マネージャに対してＵＲＬ経由でテレスペースを開くように要求し、テレスペース・マネージャにアクティビティ・マネージャを要求し、さらに、通常はアクティビティのＵＲＬを使って、アクティビティ・マネージャがアクティビティを開く。次に、ＡＢＣシステム４００はメンバーがテレスペースを使用して特定のアクティビティによって提供される共有された特定のタスクを実行することができるようにする。
【００６２】
図５はピア・ユニット３１４Ａ〜Ｄ上のＡＢＣシステム５００の代表的なマルチ・テレスペースの使用方法を示す。ＡＢＣシステム５００が分散システムであることは理解されるべきである。そこでここでは、ピア・ユニット３１４Ａだけのコンポーネントの説明が提供されているが、ピア・ユニット３１４Ｂ〜Ｄも同様のコンポーネントを備えているので、これらについては別個の説明は不要である。
【００６３】
ピア・ユニット３１４Ａについて図示したように、ＡＢＣシステム５００はピア・ユニット３１４Ａがメンバーとして登録されている複数の代表的テレスペースを含み、これには自動車設計テレスペース５０２、チャット・テレスペース５０４、チェスで遊ぶテレスペース５０６が含まれている。また図示してあるように、ピア・ユニット３１４はテレスペース５０２、５０４、５０６の操作中に使用される複数のコンポーネントを有している。ピア・ユニット３１４Ａは、メンバーとして登録されているテレスペース５０２、５０４、５０６の各々をリストし記述してあるテレスペース・レコード５０８と、これらのテレスペースに参加するテレスペース・メンバーのアイデンティティの各々をリストし記述してあるメンバー・レコード５１２とを保持するメモリ５１０を備えている。ＵＩ５１２はユーザが開始したテレスペースへの変更及びメンバー・レコード５０８．５１４への変更を受信できる。
【００６４】
テレスペース５０２、５０４、５０６の各々は図示したアクティビティ５２２、５２４、５２６のうちの異なる一つを例示している（これとは別の場合には、図示したアクティビティ５２２、５２４、５２６は単一のテレスペースに常駐することもあるが、この場合単一のテレスペースの全てのメンバーがアクティビティの各々へのアクセスを行なうことになる）。各々のアクティビティ５２２、５２４、５２６は各々のアクティビティに対応する特定のツール５３２、５３４、５３６であって、各々のエンジン５４２、５４４、５４６の制御下にメモリ５１０に格納された対応するデータ・モデル５５２、５５４、５５６に対して変更を行うためのツール５３２、５３４、５３６を含み、これらのツールはそれぞれテレスペース５０２、５０４、５０６の中に永続的に保存される。たとえば、自動車設計テレスペース５０２はＣＡＤ（ｃｏｍｐｕｔｅｒ−ａｉｄｅｄ  ｄｅｓｉｇｎ）ソフトウェアの形でツール５３２を含むことができるアクティビティ５２２のインスタンスであり、チェスで遊ためのテレスペース５０６はソフトウェアのチェスゲームの形を取るツール５３６を含むことができるアクティビティ５２６のインスタンスである。
【００６５】
ユーザはユーザ・インタフェース５１４経由でテレスペース５０２、５０４、５０６のアクティビティ５２２、５２４、５２６を遂行し、ユーザ・インタフェース５１４はツール５３２、５３４、５３６とのインタフェースを持つことによりユーザの要求をツールに提供する。この要求に応答して、エンジン５４２、５４４、５４６がダイナミクス・マネージャ５０１の制御下でメモリ５１０内の対応するデータ・モデル５５２、５５４、５５６の永続状態を変更し、現在の状態を反映させる。たとえば、チェスで遊ぶためのテレスペース５０６でのデータの永続的状態は、そのチェス盤と、盤上のチェスの駒の位置を含むことができる。ユーザ要求はチェスの駒の動きを指定でき、これがデータの変更、即ちデルタを構成する。また現在の状態はデルタの実行と駒の動きの完了を反映する。
【００６６】
図６はＡＢＣシステム５００の動作を示したもので、ピア・ユニット３１４Ａに配置され図５を参照して説明したコンポーネントに関するものである。エンジン５４６はアクティビティ５２６の特定の集中タスクを推進する上で実装するときの候補となるアクションまたはオプション（たとえばチェスの駒の動き）をツール５３６に提示する。ツール５３６はユーザ・インタフェース５１４経由でテレスペース５０６のメンバー（メンバー・レコード５１２に記録されているメンバー）であるユーザと対話し、アクティビティのビュー（画像）を提示する（たとえば、チェス盤面のビューと、おそらくは動きのリスト）。ユーザのジェスチャーと呼ばれる（たとえばビショップをＸからＹへ動かすなど）ものであってユーザ・インタフェース５１４から入力されたユーザ入力に応答して、ツール５３６はデルタを生成してシステム内に格納することにより、ユーザによる選択をメモリ内に記録する。デルタは要求された変更の単位であり、好ましくは、コンテナ・オブジェクトの形である。コンテナ・オブジェクトはオブジェクト指向プログラミング技術に馴染みのある者にはには周知である。ツール５３６はデルタにおいて要求された変更の粒度（ｇｒａｎｕｌａｒｉｔｙ）の決定を担当する。デルタ・コンテナ・オブジェクトはたとえば特定のチェスの駒の識別及びチェスの駒の動きを構成する盤面のもとの位置と目標位置といった、ユーザの指定したデータに加えて、変更を実行するための１つまたはそれ以上のコマンドを保持（内蔵）することができる。生成時には、デルタはコマンドが何も入っていない空の状態で、変更を行なうためにエンジン５４６によって適当なコマンドを埋め込まれるまで、それ自身が単に変更要求を構成しているだけである。デルタにおいてエンジン特有の方法（これはツール５３６には分かっていなくとも良い）で変更を行なうのに必要とされるコマンドを記録するのはエンジン５４６の責任である。
【００６７】
さらに詳しく説明すると、線「ａ」で示したように、ツール５３６はダイナミクス・マネージャ５０１によるデルタ生成を要求することからデルタの作成を開始する。ダイナミクス・マネージャ５０１はデルタを作成して線ａ’でツール５３６へデルタを返し、フォールトリカバリ（障害復旧）が必要な場合に備えて作成したデルタを記録する。
【００６８】
図６の線「ａ」で示してあるように、ツール５３６はツール・インタフェース６０２を介してエンジン５４６のツール・エンド６０４へデルタの制御を渡し、これによりエンジンを起動する（この説明は時としてデルタが渡されるまたはデルタへの制御を一つのコンポーネントから別のコンポーネントへ渡すべきであることを表わす。望ましくは、デルタはメモリ内に割り当てられ、ポインタがＸＭＬエレメントとして渡されるオブジェクトである。）。エンジンのツール・インタフェース６０２はデルタにコーティングされている要求された変更を行なうことができるコマンドを作成するための、または、言い換えればユーザの意図にしたがうように逐次的な形で適当なコマンド、代表的にはエンジンに特有なコマンドでデルタを埋めるための、一組のアプリケーション・プログラム・インタフェースを表出する。次にエンジン５４６はこの段階ではコマンドで埋められているデルタの制御をツール５３６に戻す。
【００６９】
図６の線「ｂ」で示してあるように、ツール５３６は実行のために埋められたデルタの制御をダイナミクス・マネージャ５０１へ渡す（即ち送出する）。ダイナミクス・マネージャ５０１は他のピア・ユニット３１４Ｂ〜Ｄから線「ｂ」経由で到着するデルタも受信することができる。ダイナミクス・マネージャ５０１は、ピア・ユニット３１４Ｂ〜Ｄにおけるダイナミクス・マネージャとともに、チェスゲームのテレスペースに参加している全てのメンバーについて、ＡＢＣシステムの一方のエンドから別のエンドへ、データ・モデル５５６へ行なわれた変更の一貫性を維持する責任がある。
【００７０】
ダイナミクス・マネージャ５０１はキュー構造６１２とダイナモ・プロセス６１４とを含み、好ましくはコンピュータで実行可能なプログラムがダイナミクス・マネージャの主論理を含む。ダイナミクス・マネージャ５０１とそのダイナモ・プロセス６１４は通信マネージャ６２２と双方向通信する。ダイナミクス・マネージャ５０１は受信したデルタを順序付ける目的でキューに入れてキュー構造６１２にして、次にダイナモ・プロセス６１４がキューに入っているデルタを処理するときにはキュー構造にサービスし、エンジン５４６に指示して適当な順序でデルタを実行させる。さらに詳しく説明すると、ダイナミクス・マネージャ５０１のダイナモ・プロセス６１４はインタフェース６１５を介して図６の線「ｃ」を介してエンジン５４６のダイナミクス・マネージャ・エンド６１６へ向けて、「デルタ・コマンド実行」メッセージの形で制御信号を送信する。デルタコマンド実行メッセージはエンジン５４６に指示して、メモリ５１０に含まれており、テレスペースに永続するデータ・モデル５５６への要求された変更を行なうことで、ツール５３６から受信したデルタの実行を遂行する。
【００７１】
ダイナミクス・マネージャ５０１のダイナモ・プロセス６１４はまた、通信マネージャ６２２経由で他のエンドポイントへ向けてローカルに開始した全デルタを配布し、通信マネージャ６２２はネットワークたとえば６２６上でピア・ユニット３１４Ｂ〜Ｄへデルタを送信する。ピア・ユニット３１４Ｂ〜Ｄ各々では、各々のダイナミクス・マネージャが受信したデルタを自分のローカル・キュー構造へとキュー入れし、つぎに特定の順序で各々のエンジンへデルタを渡して実行させる。
【００７２】
一つのダイナミクス・マネージャはアプリケーションによって一つのテレスペースまたは多数のテレスペースをサポートできるので、多数のエンジンに指示して様々なテレスペース用のデルタを実行させる責任をとらせることもできる。多数のテレスペースを持つシステムでは、図５に図示したように、デルタの情報を調べることで、あるデルタをどのエンジンが実行すべきかを、ダイナミクス・マネージャ５０１が決定する。デルタはエンジンのうちの特定の一つに同定されまたデルタのペイロードの中に入っているエンジン識別子またはコードのタグを付けられたコマンドを含む。キューに入れられたデルタがダイナミクス・マネージャで処理される時に、ダイナミクス・マネージャはエンジン・コードと参照されたデルタとを関連付け、適当なエンジンによるデルタの実行を指示する。
【００７３】
最後に、図６の線「ｄ」で示されているように、エンジン５４６は「データ変更通知」メッセージを送出してツール５３６にデルタの実行を通知し、またデータ・モデル５５６におけるデータの新しい現在状態を通知する。デルタ変更通知は値または参照を使って行うことができる。つまり、通知は新しいデータの値それ自体を含むことができたり、またはメモリ内の新しいデータへのポインタを含むことができる。この通知に応答して、ツール５３６はたとえばチェス番のグラフィック上での動きを表示することにより、ユーザが利用可能な変更をユーザ・インタフェース５１４に行なわせる。ユーザがディスプレイ１７０を観察している場合（図１）、ユーザは、デルタの実行によって行なわれたチェス・ゲームへの変更を見ることができるが、それ以外の場合には、変更が行なわれた時点でユーザが変更を「見る」ことなくメモリ５１０内のデータに変更が行なわれる。
【００７４】
望ましくは、ピア・ユニット３１４Ａのデータ・モデル５５６に格納されているデータ・モデル５５６へ変更がエンジン５４６によって行なわれるのと実質的に同時に、他のピア・ユニット３１４Ｂ〜Ｄもローカルに格納しているデータに対して同様の変更を行なって一貫した方法でデルタの意図を反映する。ピア・ユニット３１４Ａ〜Ｄのどれかがネットワークたとえばインターネットに接続されていないような状況が起こり得る。ピア・ユニット３１４Ａが切断されているときには、通信マネージャ６２２はデバイス・プレゼンス・デテクタ４３０を使用してピア・ユニット３１４Ａが接続されているかどうかを確認し、接続されていない場合には、接続が復元される時まで送出されるデルタを送出デルタストア６２８に格納しておき、接続された時点で、格納したデルタを送信する。１つ以上の宛先ピア・ユニット３１４Ｂ〜Ｄがネットワークから切断されている場合、ピア・ユニット３１４Ａの通信マネージャ６２２はプロセスを続けて他のピア・ユニットが切断されているか否かにかかわらず送出デルタをリレー３１６（図３）に送信する。リレー・デバイス３１６（図３）はこのような送出デルタを受信し、必要に応じて送出デルタストア３１８（図３）に格納し、ピア・ユニット３１４Ｂ〜Ｄが再接続された時点で宛先へ転送する。動作中には、通信マネージャ６２２は全ての送出デルタをリレー３１６のＵＲＬへ送信することができ、リレーは搭載されている参照テーブル３２０を使用してデルタを中継する場合に使用する宛先ピア・ユニット３１４Ｂ〜ＤのエンドポイントＵＲＬを確認する。リレー・サービスは実際にはインターネット・サービス・プロバイダ（ＩＳＰ）またはその他のインターネット組織によって提供され得るものである。
【００７５】
ツール５３６とエンジン５４６の間で、ユーザ・インタフェース・アクティビティはツール５３６経由でのみ直接行なわれ、データ・モデルの変更はエンジン５４６経由でのみ直接行なわれることが理解される。専門用語を使った表現では、ツール５３６はＵＩを「保有」しており、エンジン５４６はデータ・モデルを「保有」している。これは図２に図示したような現行の代表的アプリケーションとは対照的である。たとえば、今日のスプレッドシート・プログラムでは、代表的にはツールの機能とエンジンの機能を組み合わせており、本発明の前述の実施態様のようにこれらを分離するのではない。ツールをエンジンから分離することにより、従ってデータ・モデルからＵＩを分離することにより、ダイナミクス・マネージャはたとえばデータの一貫性を維持する目的で、様々なピア・ユニットから発せられたデルタの間に介在し仲介できる。さらに、エンジンからツールを切り離すことでデルタの実行処理を非同期的に行なえるようになる。これはダイナミクス・マネージャ５０１とエンジン５４６がテレスペースの中にいる全てのメンバーについてデータの一貫性を維持するような方法で各々の責任を遂行するのに時間がかかるため有用である。また、他のピア・ユニット３１４Ｂ〜Ｄから到着するデルタがローカルに開始されたデルタの実行のタイミングに影響することがあることからも有用である。
【００７６】
図７は個別に実装されたアクティビティ（図示していない）で使用するフレームワーク７００の実施態様を示す。フレームワークは、たとえばフレームワーク上で動作可能なアプリケーション独自のスナップイン（プラグイン）であるコンピュータ・プログラム製品として、個々のアクティビティとは独立して、販売またはライセンスすることができる。一般的に言うと、フレームワークはテレスペースに関してコラボレーションをホスティングする。図示したフレームワーク７００は１つ以上のダイナミクス・マネージャ７０２、１つの通信マネージャ７０４、１つのデータ構造テンプレート７０６を含む。データ構造テンプレート７０６はアクティビティ・デベロッパが使用するための原始型オブジェクト（オブジェクト・プリミティブ）を、望ましくはＸＭＬフォーマットで含むことができる。フレームワーク７００はたとえばコンピュータで読み取り可能な媒体７０６として実装可能で、媒体上にダイナミクス・マネージャ７０２と通信マネージャ７０４を含むコンピュータで実行可能なコードと、データ構造テンプレート７００のオブジェクト・プリミティブを含むコンピュータで読み取り可能なデータとが格納される。
【００７７】
Ｆ．通信マネージャ、プレゼンス・サーバ、及びリレー
図８はネットワークたとえばインターネット８０３経由で多数のピア・ユニット８０２Ａ〜Ｄの間での通信ができるように装備したＡＢＣシステム８００を示す。各々のピア・ユニット８０２Ａ〜Ｄはピア・ユニット３１４Ａに関連して前述したコンポーネントを含むことができる（図８に図示したピア・ユニットの個数は単に例示を目的として選択したものであり、特定の実装の構成により左右され、また時間とともに変化することがある）。各々のピア・ユニット８０２Ａ〜Ｄはツール８０５Ａ〜Ｄによって開始されエンジン８０７Ａ〜Ｄにより実行されるデルタ処理を調節するためのダイナミクス・マネージャ８０４Ａ〜Ｄを含み、またピア・ユニット８０２Ａ〜Ｄの間の通信を調整するための通信マネージャ８０６Ａ〜Ｄを含む。通信マネージャ８０６Ａ〜Ｄの役割はネットワークたとえばインターネット８０３上でインターネット・プロトコルたとえばＴＣＰ／ＩＰなどを使用してメッセージ（デルタを含む）を送受信することを含む。各々のピア・ユニット８０２Ａ〜Ｄはとくに機能の上で通信マネージャ８３０Ａ〜Ｄの動作サポートにおいてデータを格納するためのメモリ８０８Ａ〜Ｄを含む。
【００７８】
前述のように、通信マネージャ８０６Ａ〜Ｄ各々はそれ自体のピア・ユニットと他のピア・ユニットとの間の通信を全て管理する責任がある。たとえば、通信マネージャ８２２はピア・ユニット８０２Ａとピア・ユニット８０２Ｂ〜Ｄの間の双方向通信を管理する。通信はピア・ユニット８０２Ａからピア・ユニット８０２Ｂ〜Ｄの１つまたはそれ以上へ送出される、またはピア・ユニット８０２Ｂ〜Ｄの一つからピア・ユニット８０２Ａへ送出されるどちらかのメッセージを含むことができる。宛先ピア・ユニット８０２Ｂ〜Ｄ（前者の場合）またはピア・ユニット８０２Ａ（後者の場合）がネットワークたとえばインターネットに接続されている限り（「オンライン」状態である）直接かつ仲介なしに送信を行なうことができる。前述のように、デバイス・プレゼンス・マネージャ８１２を用いて想定した宛先がオンラインになっているか、または一時的に切断されている（「オフライン」状態である）どうかを確認することができる。宛先がオフラインになっている場合、通信はリレー８１４（前述の通り）を経由して行なうことができ、リレーは宛先がオンラインに復帰した時に宛先へのメッセージを転送する。
【００７９】
つまり、ピア・ユニット８０２Ａがピア・ユニット８０２Ｃへのメッセージを送出しようとして、ピア・ユニット８０２Ｃがオンラインであるとプレゼンス・サーバ８１２から通信マネージャ８０６Ａに通知されている場合には、通信マネージャ８０６Ａはネットワークたとえばインターネット８０３経由で直接ピア・ユニット８０２ＣのＵＲＬ宛てにメッセージを送出する。ピア・ユニット８０２Ｃでは通信マネージャ８０６Ｃがメッセージを受信して、メッセージをダイナミクス・マネージャ８０４Ｃへ渡す。
【００８０】
逆に、ピア・ユニット８０２Ａがピア・ユニット８０２Ｃへのメッセージを送出しようとして、ピア・ユニット８０２Ｃがオフラインであるとプレゼンス・サーバ８１２から通信マネージャ８０６Ａに通知されている場合には、通信マネージャ８０６Ａはネットワークたとえばインターネット８０３経由でリレー８１４のＵＲＬへメッセージを送出する。リレー８１４は高性能ファイルサーバとして実装可能で、ピア・ユニット８０２Ｃがオンラインに復帰するまで中継メッセージを保存しておき、復帰時にメッセージをピア・ユニット８０２ＣのＵＲＬへ転送する。ピア・ユニット８０２Ｃでは前述のようにメッセージを受信して、通信マネージャ８０６Ｃ経由でダイナミクス・マネージャ８０４Ｃへ渡す。
【００８１】
したがって、プレゼンス・サーバ８１２はＡＢＣシステム８００内ではピア・ユニット８０２Ａ〜Ｄがオンラインかどうかをモニタする目的で、また他のピア・ユニットの接続状態をピア・ユニットの各々に通知する目的で、使用することができる。この目的を満たすためには、プレゼンス・サーバ８１２はたとえば図１のコンピュータ・システム１００に示したように構成することができる。
【００８２】
動作中、ピア・ユニット８０２Ａ〜Ｄの各々はプレゼンス・サーバ８１２に自分の接続状態を通知する責任、即ちユニットがオンライン中かまたはこれからオフラインになろうとしているところかを通知する責任がある。別の方法としては、プレゼンス・サーバ８１２は時々ピア・ユニット８０２Ａ〜Ｄをポーリングしてこれらの接続状態の情報を取得することができる。この情報はプレゼンス・サーバ８１２内で望ましくは揮発性メモリ８１６内の接続ディレクトリ８１８に保存する。接続ディレクトリ８１８は初期状態では空で、ピア・ユニット８０２Ａ〜Ｄが接続状態の状態をプレゼンス・サーバ８１２に提供するまで、たとえば接続状態の通知を提供するまで、空のままである。そして、状態に関する情報の受信時に、接続ディレクトリ８１８は通知してきたピア・ユニットのＵＲＬと接続状態の情報を保存する。
【００８３】
プレゼンス・サーバ８１２はピア・ユニット８０２Ａ〜Ｄに対して接続状態予約サービスを提供することもできる。プレゼンス・サーバ８１２は各々の接続しているピア・ユニット８０２Ａ〜Ｄに他の各ピア・ユニット８０２Ａ〜Ｄの接続状態を通知し接続状態の変化も通知する。プレゼンス・サーバ８１２は（ａ）メッセージを送信「したい」ピア・ユニット８０２Ａ〜Ｄから状態変化通知の要求があった時点で、（ｂ）ネットワークたとえばインターネット８０３へピア・ユニットが接続する時点で、（ｃ）時々、たとえばピア・ユニットのいずれかの状態に変化があった時点で、または（ｄ）上記の組み合わせのいずれかの時点で、接続しているピア・ユニット８０２Ａ〜Ｄへ接続状態通知を送信できる。望ましくは、全ての通信はインターネット・プロトコルに準拠して行なう。これらのプロトコルにはとくに前述のものが含まれる。
【００８４】
各ピア・ユニット８０２Ａ〜Ｄはまたメンバーシップ状態サービスに加入することができ、そうすることでそれ以後はメンバーとなっている各テレスペースのメンバーシップの現状に基づいて知ることができる。このサービスを有効にするためには、プレゼンス・サーバ８１２はプレゼンス・サーバによってサポートされる各メンバーについてのレコードを格納するため揮発性メモリ８１６にメンバー・ディレクトリ８２２を保持しておく。各ピア・ユニットはプレゼンス・サーバに時々、あるいは、これ以外ではメンバーシップ状態に何らかの変更があった時点で、現在のメンバーシップ状態を提供する。
【００８５】
例示すると、ピア・ユニット８０２Ａがピア・ユニット８０２Ｂへたとえばデルタなどのメッセージを送信したい場合、ピア・ユニット８０２Ａはプレゼンス・サーバ４３０にアクセスしてピア・ユニット８０２ＢのＵＲＬを取得し、これの接続状態の情報を得る。ピア・ユニット８０２Ａが予約サービスに加入していると仮定すると、ピア・ユニット８０２Ｂの状態についての通知を受信することになる。つまりダイナミクス・マネージャ８０４Ａは宛先ピア・ユニット８０２Ｂがネットワークに接続しているかどうかについての知識がなくとも通信マネージャ８０６Ａへメッセージを渡すことができる。
【００８６】
Ｇ．分散データ一貫性モデルとデルタ処理
前述したように、ピア・ユニット８０２Ａ〜Ｄ内のダイナミクス・マネージャ８０４Ａ〜Ｄはローカルに生成したデルタやリモートで生成したデルタを受信することと各々のエンジン８０７Ａ〜Ｄで実行する正しい順序を維持することで、テレスペースに参加しているＡＢＣシステム８００のピア・ユニット３１４Ａ〜Ｄの全部にわたってデータ・モデルの一貫性を高いレベルで維持できるようにすることが役割である。どれか一つのピア・ユニットから発信されたデルタが順不同に受信および／または実行されたり、または一時的にネットワークからピア・ユニットが切断されているため大幅に遅延した後で受信および／または実行されるため、こうすることは一層困難なものになる。さらに、デルタは別々で一貫性のないローカルデータの状態に基づいて生成されることがある。
【００８７】
理論的には、データの一貫性は３つの属性を使って記述することができ、その各々は何らかの程度でコラボレーション・システムである程度達成できるものであり、それらは即ち因果関係の保存、意図の保存、および収束性である。さらに詳しく説明すると、これらの一貫性の属性は以下のように記述することができる。
【００８８】
１．因果関係の保存（即ちシーケンス（順序）の一貫性）は、デルタＡがデルタＢの原因となる場合、デルタＡは最初に実行される必要があり、デルタの作成を生じたシーケンスがその実行において保存されるようにすることが必要とされる。言い換えれば、この属性を満たすには従属動作の実行順序が自然界の原因／結果の順序と同じである必要がある。
【００８９】
２．意図の保存（即ちセマンティック（意味）上の一貫性）はデルタの意味とその作成の裏に隠れている意図が保存される必要がある。言い換えれば、この属性を満たすには、デルタの何らかの対について、たとえばデルタＡとデルタＢで、一方の実行は他方の意図を保存しなければならない。これを達成するには、データ状態に対する変更をユーザが要求した時点でのデータ状態をシステムで記録する。たとえば、共有ドキュメントの場合、変更「ｘ」が要求された時、次の単語が「ｙ」でありこれは「ｘ」が実行された時にも同じである。言い換えれば、各ピア・ユニットに格納されたデータに対してデルタを実行する効果が元となるピア・ユニットに格納されたデータに対する同じデルタの実行の効果と同じでなければならない。
【００９０】
３．収束性は全てのピア・ユニット８０２Ａ〜Ｄの各々によって維持されるデータのコピーは同じデルタを実行した後に同一でなければならないことを要求する。これは「完全順序」（ｔｏｔａｌ  ｏｒｄｅｒｉｎｇ）として公知である。
【００９１】
ＡＢＣシステム８００は高レベルのデータ一貫性を維持するのに必要な情報を記録しておき、実行が他のデルタの先行実行に依存するデルタについてのデルタ実行順序の制約を強制する。たとえば、ピア・ユニット８０２Ａのダイナミクス・マネージャ８０４Ａでのデルタ受信の順序毎にデルタが大文字Ａ、Ｂ、Ｃ、Ｄで指定されている時、デルタＡ、Ｂ、Ｃ、Ｄは因果関係を保存するように受け取った順序で正しく実行することが可能である。これは、たとえばデルタＡとＣがピア・ユニット８０２Ａからローカルに開始されたものでデルタＢとＤがピア・ユニット８０２Ｄからリモートで到着したものである場合でも同じである。ただし、場合によっては、受信した順序でこれらのデルタを実行すると、順序が乱れた変更が行なわれて因果関係の違反が起こることになる。たとえばローカルに生成されたデルタとリモートで生成されたデルタがたどる通信経路でのレイテンシ（待ち時間ｌａｔｅｎｃｉｅｓ）が異なっているため、デルタが交互に入れ違いになって受信される結果を招くことがある。さらに、因果関係の保存が実現されたとしても、結果は意図の保存に関する属性を侵害することがあり、変更の意味がなくなる場合もある。たとえば、デルタＢは文章「Ａ  ｃｏｗ  ｈａｓ  ｌｅｇｓ」（牛には脚がある）について「脚」の前に「４本の」を挿入したいとする。デルタＡがデルタＢでの変更について知識がなく、同じ文章の中でで「脚」を「頭」に変更したい場合にデルタＢで文脈を変更するためにデルタＢの前に実行されてしまうと、結果は「Ａ  ｃｏｗ  ｈａｓ  ｆｏｕｒ  ａ  ｈｅａｄ」（牛には４つの頭がある）になる。実際、この結果は意味がなく、またデルタＡがデルタＢより後に処理されることにより発生する結果にも意味がないのである。収束性については、ピア・ユニット８０２Ａ〜Ｄでのデータのコピーの「同一性」（即ち複製）が破られる状況には複数のものがある。たとえば、ネットワーク上の通信障害によりデルタがあるピア・ユニット８０２Ａ〜Ｄで受信されなくなることがあり、そのために異なるデルタ実行結果が発生する場合がある。不可能でなくとも現実のシステムにおける完全収束、因果関係の完全保存、意図の完全保存を実現するのは困難であるが、高いレベルのデータ一貫性がピア・ユニット間えのコラボレーションには望ましい。
【００９２】
高レベルのデータ一貫性を実現するためには、各々のダイナミクス・マネージャ８０４Ａ〜Ｄは、所定のフォーマットのデルタを作成し、デルタと各々のメモリにデータ一貫性を維持するのに使用するある種の情報を記録するのが望ましい。さらに詳しく説明すると、各ダイナミクス・マネージャ８０４Ａ〜Ｄが作成する各々のデルタにシーケンス番号（Ｓｅｑ．  Ｎｏ．）を割り当て、特定のピア・ユニット８０２Ａ〜Ｄにおいてダイナミクス・マネージャによって作成された全デルタの中でのデルタのシーケンシャルな位置を表わす。ダイナミクス・マネージャ８０４Ａ〜Ｄは次にデルタに割り当てたシーケンス番号と一緒にエンドポイント識別子（ＥＰ）を記録し、これはデルタの発生の元となったエンドポイント（ピア・ユニットと人）を指定しているものである。ダイナミクス・マネージャ８０４Ａ〜Ｄはまたデルタに作成時刻で単一の従属性を指定する情報を記録する。デルタに記録された従属性情報は、たとえば他の一つのデルタの発生元となるエンドポイントのシーケンス番号とＥＰの形態を取るが、このときの他の１つのデルタは、たとえば、通常はそのデルタについて作成したピア・ユニットで注目しているデルタと同じアクティビティで注目しているデルタの作成の直前にエンジン８０７Ａ〜Ｄによって実行された最後のデルタである。
【００９３】
ある種のデルタは、たとえばテレスペース・データの状態がその実行に重要でないため、先行するデルタに依存しない。これらのデルタは「独立デルタ」と呼ばれる。独立デルタでは、このような従属性シーケンス番号を提供する必要がない。各ダイナミクス・マネージャ８０４Ａ〜Ｄは受信したデルタのヘッダから一貫性情報を抽出し、デルタ情報の残りと一緒にこの情報をメモリに保持する。
【００９４】
図９は本発明の実施態様によるデルタ９００のフォーマットを示しており、これは上記で説明した一貫性情報を使うことができるものである。デルタ９００はヘッダ９０２と、これに続くペイロード９０４を持っている。ヘッダ９０２はデルタを識別し、一貫性情報を含み、他の「ハウスキーピング（ｈｏｕｓｅ−ｋｅｅｐｉｎｇ）」情報を含むこともある。ペイロード９０２は１つ以上のコマンド・フィールド９０８を有し、これがエンジン８０７Ａ〜Ｄの内の一つによってデルタに記録されたコマンドを指定する。
【００９５】
ヘッダ９０２は一貫性情報、たとえば次のようなものを指定する：
Ｓｅｑ．  Ｎｏ．  ＠  ＥＰ  Ｎｏ．  ：  Ｓｅｑ．  Ｎｏ．  ＠  ＥＰ  Ｎｏ．
【００９６】
ここで、最初のＳｅｑ．  Ｎｏ．  ＠  ＥＰ  Ｎｏ．  （コロンの前のもの）は、発生元となるピア・ユニットでの、即ちＵＲＬで識別されたピア・ユニット３１４Ａでの、現在のデルタのシーケンス番号であり、コロンは「〜が以下に依存する」と読むものであり、コロンの後の第２のＳｅｑ．  Ｎｏ．  ＠  ＥＰ  は従属しているシーケンス番号であって、これはたとえば同じピア・ユニットたとえばＵＲＬで指定されたピア・ユニット３１４Ａで生成された直前のデルタを指定するもので、ここで現在のデルタが従属する先のデルタを参照する。
【００９７】
図１０はデルタからたとえばダイナミクス・マネージャ８０４Ａによって抽出された情報を格納するための代表的なメモリ構造１０００を示している。ダイナミクス・マネージャ８０４Ａは次のようなレコードを永続的に保持する：即ち、Ａ）デルタ・ログ１００２であり、これはテレスペース内部でダイナミクス・マネージャによって実行されたデルタの全部の記録、即ちデルタ１、デルタ２、．．．デルタｎの記録であり、ｎはテレスペースにおいてダイナミクス・マネージャ８０４Ａにより一番最後に実行されたデルタに対応するカウントであり、Ｂ）デルタ・格納１００４であり、これはこのようなデルタの内容を格納し、またたとえばデルタ・ログ１００２に実装できるものであり、Ｃ）ベクトル１００６であり、これはピア・ユニット８０２Ａのダイナミクス・マネージャ８０４Ａがテレスペースの他のピア・ユニット８０２Ｂ〜Ｄ各々から受信したデルタの最大シーケンス番号とそのテレスペースについてダイナミクス・マネージャ８０４Ａで生成された最大のシーケンス番号を指定するアレイであり、Ｄ）エンドポイント（ＥＰ）ログ１００８であり、これはピア・ユニット３１４Ａもメンバーに加入している先のテレスペースのメンバーであるエンドポイントのリストで、各々のエンドポイント識別子を提供するものであり、Ｅ）データ・モデル空間１０１０であり、これは各々のアクティビティにおいて使用するアクティビティ特有のデータ・モデルに準拠したデータ用の格納を提供するものであり、Ｆ）ローカル・デルタ・キュー１０１２であり、Ｇ）到着デルタ・キュー１０１４であり、Ｈ）ホールド・デルタ・キュー１０１６である。
【００９８】
ベクトル１００６は高いレベルのデータ一貫性を維持する際に使用される情報を格納するための観点からして重要であることからして、さらに説明を行なう。ベクトル１００６はたとえば各受信データに関して次のような一貫性情報を保存する：即ち、（ａ）発生元のエンドポイントの識別子（ＵＩＤ）、これはテレスペース全体から見てユニークなものでそのエンドポイントの識別である。（ｂ）エンドポイントから見たときの相対的なシーケンス番号、これは各エンドポイントから受信したテレスペース内のデルタのその時点でのカウントで、基本的には、受信デルタの順序付けの目的を有するものでピアであるエンドポイントのタイムスタンプに相当する。（ｃ）デルタの従属シーケンス番号、これはエンドポイントがデルタを作成した時点で、そのピア・ユニットで実行されたシーケンスにおける（即ち「ユーザが見た」現在状態）何らかの先行デルタに基づいていたことを示す。好適実施態様においては、これらの情報の全部が受信デルタから抽出できる。
【００９９】
動作中には、たとえばダイナミクス・マネージャ８０４Ａによってデルタを受信した場合、ダイナミクス・マネージャは受信デルタがローカルに発生したかリモートで発生したかによって、受信デルタをローカル・デルタ・キュー１０１２又は到着デルタ・キュー１０１４のどちらか一方に置く。実装によってはしかるべきキューの中のデルタの各々へのポインタだけを格納することができる。デルタ・キュー１０１２、１０１４はたとえばＦＩＦＯ（先入れ先出し）ワークロード・バッファとして実装される（別の方法では、ある種の実装では到着デルタとローカル・デルタの両方を保持するために単一のキューを使用することができる）。ダイナミクス・マネージャ８０４Ａはキュー１０１２、１０１４から先入れ先出し方式でデルタを処理する。実装によってはたとえば負荷のバランスを取るためおよび／またはレイテンシを制御するために、ローカル・データ又は到着デルタのキュー１０１２、１０１４の一方又は他方からのデルタを処理するための適当な優先順位アルゴリズムを使用することができる。ローカル・キューにあるローカルデルタより先に到着キューにある全ての到着デルタを処理してデルタ処理に置ける平均的レイテンシを制限するのが望ましい。別の方法では、ローカルデルタが優先的に処理される逆の順序の場合にはピア・ユニットがネットワークへ再接続した時に到着デルタ・キューが長くなる場合に長いレイテンシを回避できる。
【０１００】
図１１Ａはデルタ処理メソッド１１００の代表的実装を図示したもので、前述の順位付け及びデータ一貫性情報を使用する。ステップ１１０２において、ダイナミクス・マネージャ８０４Ａは次の、又は「現在の」デルタを、ローカル・デルタ・キュー１０１２と到着デルタ・キュー１０１４の一方から取り出す。ステップ１１０６で、ダイナミクス・マネージャ８０４Ａはベクトル１００６をチェックし、シーケンス及び従属性情報から、現在のデルタが独立かどうか、また対応する従属性シーケンス番号を持っていないかどうかを決定する。そうだとなった場合には、ステップ１１０８で、図１１Ｂのサブルーチン１１１０を呼び出すかまたは起動することにより、受信した順序で現在のデルタをすぐに処理する。サブルーチン１１１０のステップ１１１２で、ダイナミクス・マネージャ８０４Ａは、デルタのＵＩＤ、シーケンス番号、従属シーケンス番号をデルタ・ログに記録することにより、デルタ・ログへデルタを登録または同化する。次に、ステップ１１１４がデルタを実行させる。その後、ステップ１１１６ではタイムスタンプ・ベクトル１００６を更新する。そのため、ダイナミクス・マネージャ８０４Ａはヘッダ情報を抽出し、ベクトル１００６の中のそれに対応するピア・ユニットのエンドポイント番号と最大シーケンス番号を更新する。次に、サブルーチンは、ステップ１１２８に戻って図の１１Ａのデルタ処理を継続する。ステップ１１０６のテストで、現在のデルタが独立ではないと判断した場合、ステップ１１１８で、ダイナミクス・マネージャ８０４Ａはベクトル１００６の従属シーケンス番号（デルタの先頭になっているもので指定されている）をチェックし、現在のデルタが従属している先のデルタが処理されているかどうか判断する。対応するエンドポイントについてシーケンス番号がベクトル１００６に格納されている番号より小さければ、これはすでに処理されている（理論的にはこの情報をデルタ・ログに格納してもいいのだが、デルタログはそのサイズを現実的な範囲内に保つため時々パージするのが望ましい）。未だ処理されていない場合には、ステップ１１２２で、現在のデルタはホールド・デルタ・キュー１０１６に置かれる。現在のデルタの従属先であるデルタがすでに処理されている場合には、現在のデルタは以下で詳細に説明するように処理することができる。
【０１０１】
ステップ１１２４で、ダイナミクス・マネージャ８０４Ａはデルタ処理の順序を決定し、前述したように図１１Ｂのサブルーチン１１１０を次に関連させる。デルタ・ログ１００２のデルタ・シーケンス番号で示されて判るように現在のデルタがすでに実行されたデルタに従属していて、同じ優先順位のデルタに従属する受信デルタが他にない場合、それ以上の一貫性を心配することもなく、現在のデルタはすぐに処理さる。一方、現在のデルタがデルタ・ログ１００２に登録されている別の係属デルタと同じ従属シーケンス番号即ちＳｅｑ．  Ｎｏ．  ＠  ＥＰを持っている場合には、これらのデルタの間で衝突条件が発生する。
【０１０２】
本実施態様においては、衝突の発生時におけるデルタの実行順序はデルタの発生元のエンドポイントに依存するが、他の実装ではこれ以外に別の優先順位スキーマまたは初期設定順序を使用して衝突を解決することができる。実装されたときには、テレスペースのメンバーであるエンドポイントには（たとえばテレスペースの第１のエンドポイント・メンバーによって）それぞれユニークなエンドポイント番号が割り当てられ、この番号がたとえばエンドポイントがもともとテレスペースに参加した順序に対応する。つまり、ピア・ユニット３１４Ａがそのテレスペースで最初のものだったとすると、これにはＥＰ１と番号が付けられ、それに続く新しいメンバーは階層的番号スキーマにしたがって番号を受信して、たとえばテレスペースへ新しいメンバーを招待したスポンサーであるエンドポイントを反映する。つまり、エンドポイントＥＰ１が新しく２人のメンバーをテレスペースへ招待した場合、これらはＥＰ１．１とＥＰ１．２として番号が付けられる。次に、エンドポイントＥＰ１．１が新しく３人のメンバーを招待して加入させた場合、新しいメンバーはＥＰ１．１．１、ＥＰ１．１．２、ＥＰ１．１．３と番号が付けられる。エンドポイント番号の桁は左から右へ第一位、第二位、などと表わすことができる。つまり、ＥＰ１．１．３では、一番左側の番号「１」が第一位、二番目の位置の桁の「１」が第二位であり、「３」が第三位である。
【０１０３】
前述の番号付けスキーマは、ピア・ツー・ピアで、完全分散型コラボレーション・システムに使用するエンドポイントへユニークな番号を割り当てるのに特に適した特別な性質を有しているので、メンバーは何時でもメンバーシップに加入したり脱退することができ、または何時でもテレスペースに接続したりテレスペースから一時的に切断したりできる。前述のように、このスキーマはテレスペースメンバーの各々の各エンドポイントにユニークな番号を割り当てる。あるメンバーの各番号はそのメンバーがテレスペースに参加した順序を表わし、またまた別のテレスペースメンバー（「招待する側のメンバー」）によって加入するように招待された（または何らか支援された）各メンバーについては、招待した側のメンバーも表わしている。これらの新しいメンバーによってさらに多くのメンバーに加入するように招待すると、割り当て番号はさらに桁数を追加して招待メンバーの家系図または連鎖を表わすようになる。したがって、割り当て番号はテレスペースの創始メンバー以後にテレスペースへ追加された各メンバーの家系図（ａｎｃｅｓｔｒｙ）を表わすものと考えられる。つまり、割り当て番号の数字が複数の場合には、第一位はテレスペースの創始メンバーを表わし、第一位以降の各位（即ち第二位、第三位など）は先行する位の数字で指定される招待する側のメンバーによってテレスペースへの参加を招待されたメンバーを表わしている。招待する側のメンバーはテレスペースの創始メンバーであったり、または中程度に古参の別のメンバーでテレスペース・メンバーシップを後援する特権があるメンバーであったりする。一つの実施態様においては、各々招待する側のメンバーはそれが後援するメンバーにテレスペース番号を割り当てる責任がある。
【０１０４】
このような番号付けスキーマだと、図１１Ａのステップ１１２６で、ダイナミクス・マネージャ３０４Ａは従属性の衝突を解決し、完全な順位を維持する。図１２に図示してあるように、従属性衝突の解決を行なうのは、各位毎の数字によってＥＰ番号を比較するステップ１２０２と、その比較に基づいて処理順位を決定するステップ１２０４で、最低の位に最低の番号を持ったデルタが最初に処理されるように順序が決められる。次に、ステップ１２０６では、デルタのどれかが順序を外れて先に処理されていなければならない他のデルタより先に処理されていないかをテストする。順序から外れて処理されたデルタがない場合には、ステップ１２０８で次のデルタを処理する。一方、順序を外れて処理されたものがあれば、ステップ１２１０でそのデルタの実行の直前のデータ状態まで処理を戻してから、ステップ１２１２で正しい順序でデルタの処理を「やり直し」する。
【０１０５】
このように、この従属性衝突を解決するスキーマではたとえば第一位に「１」のある全てのエンドポイント番号が第一位に「２」や「３」またはもっと大きな値を取るエンドポイント番号より先行して処理されることを保証する。デルタが第一位で同じ番号の値を持っている時には、順位が特定されるまで第二位の数字を比較するなどして、「実行」また必要なら「取消」「再実行」動作をデルタに対して行なうことで、デルタ実行の順位を明らかにする。
【０１０６】
たとえば、デルタ・ログ１００２が例示の目的で次のような形のデルタ及び関連情報を含んでいたとする
”  Ｓｅｑ．  Ｎｏ．  ＡＡ  ＠  ＥＰ．  Ｎｏ．  ＢＢ：  Ｓｅｑ．  Ｎｏ．  ＣＣ  ＠  ＥＰ．  Ｎｏ．  ＤＤ  ”
これはエンドポイント番号ＢＢにあるシーケンス番号ＡＡがエンドポイント番号ＤＤのシーケンス番号ＣＣに従属している」と読みとることができる。本明細書では例示の目的でデルタはＡからＣまでとして表わし、その指定にあわせてアルファベット順で受信されるものとする。デルタ・ログ１００２は次のようになる：
Ｄｅｌｔａ  ”Ａ”  −−  Ｓｅｑ．  Ｎｏ．  １  ＠  ＥＰ  １．２：  Ｓｅｑ．  Ｎｏ．  ０  ＠  ＥＰ  １
Ｄｅｌｔａ  ”Ｂ”  −−  Ｓｅｑ．  Ｎｏ．  ２  ＠  ＥＰ  １．２：  Ｓｅｑ．  Ｎｏ．  １  ＠  ＥＰ  １．２
Ｄｅｌｔａ  ”Ｃ”  −−  Ｓｅｑ．  Ｎｏ．  １  ＠  ＥＰ  １：  Ｓｅｑ．  Ｎｏ．  １  ＠  ＥＰ  １．２
【０１０７】
この例では、デルタＡはエンドポイント１．２からのシーケンス番号１を持っており、これはエンドポイント１からのシーケンス番号０に従属している。デルタＢとＣの両方とも同じエンドポイントからの同じデルタに従属しており、そのデルタと言うのはデルタＡである。デルタＢはエンドポイント１．２で生成されたもので、デルタＣはエンドポイント１で生成されたものである。本実施態様によれば、３つのデルタ全てが従属デルタであり、これらは次のような順序で処理される。最初にデルタＡが処理されるが、これは受信したこれらのデルタの最初のものであったためである。またしたがってダイナミクス・マネージャは適当なエンジンにデルタＡによって指定されたデータ変更を実行させる。次に、デルタＢ（次に受信したデルタ）が処理され、適当なエンジンにデルタＢにより指定されたデータ変更を実行させる。次いで、ダイナミクス・マネージャはデルタＣを処理し、デルタＢと従属性の衝突があること、またデルタＣはデルタＢ（即ちＥＰ１．２）より小さいエンドポイント番号（即ちＥＰ１）を持っていることが判る。その結果、デルタＢは「取り消される」ことになり、またはさらに詳しく説明すると、格納されているデータに対して行なわれたデータ変更が破棄されて、そのデータ変更を実行する前の状態にまでデータを復元または戻すようにする。次に、デルタＣが処理されデルタＣによって指定されたデータ変更が行なわれる。最後に、デルタＢが処理されてデータ変更がもう一度行なわれる。このように、この例での要求されたデータ変更の実行順序は、復元とやり直しの後で、デルタＡ、次にデルタＣ、そしてデルタＢの順序となる。
【０１０８】
前述の例は第一位と第二位の番号だけのあるエンドポイント番号に関係したものだが、例示した原理はさらに多くのもっと大きい次数を持った他のエンドポイント番号にも等しく良く適用され、前述のように大きな次数の比較が衝突の解決には必要である。したがって、従属性の衝突があった際の優先順位は、前述のように、メンバーシップについてのスポンサーシップの順位、そしてメンバーシップの日付に基づく年代順で割り当てられる。
【０１０９】
別の方法としては、従属性の衝突時の優先順位はエンドポイントの特性（たとえば業務のタイトル、ワークグループ、または部門）、要求された変更の性質（たとえばパラグラフの消去または章の追加）、データ中の変更位置（たとえばドキュメント・タイトルの変更またはドキュメントの要約の変更）、またはその他の根拠に基づいたものでも良い。優先順位を付与するためのこうした基準の各々の裏にある原理を例示するには、衝突の発生時には、たとえば何らかの特性を備えたエンドポイントからのデルタを、他の特性を備えたものより先に、たとえば製品設計チームからのデルタなどをマーケティング・チームからのデルタより先に処理する、またはその逆を行なうことができる。
【０１１０】
さらに、データ変更のロールバック（変更取り消し）ややり直し（時としてＵＮＤＯおよびＲＥＤＯと呼ばれる）はオーバヘッドの観点では高価であるから、実装によってはデルタ処理の優先順位決についての別の形態を提供することが望ましいこともある。実装する場合には、たとえばアクティビティによって他の優先順位決定方法を提供することがある。ある種のアクティビティは衝突解決または優先順位の決定方法が一種類であることがあり、また別のアクティビティは別のタイプのものを備えることがあるが、これはたとえば特定のアクティビティについてのデータ一貫性の重要性に依存することがある。チャット・ルームのようなリアルタイムのアクティビティでは、応答時間を短縮するために変更の取り消しとやり直しを避けることがあるが、これはとくに実行順序があまり重要ではないためである。
【０１１１】
他の実装では、デルタの実行を、たとえば編集中のドキュメントのある部分に対する変更に何らかの形で関連するデルタのクラスターの実行、またはある種類の変更に何らかの形で関連するデルタのクラスターの実行とすることで、ほぼ同時に全ての変更を行なえるようにすることがある。さらに、ベクトル１００６に格納されたエンドポイントについての最大シーケンス番号より所定の値だけ若いシーケンス番号を持っているような過剰に順番が遅くなったデルタはやり直しが多すぎるので、スラッシング（ｔｈｒａｓｈｉｎｇ）を防止するため実装によっては破棄されることがある。
【０１１２】
図１１Ａに戻って、ステップ１１２８では、ダイナミクス・マネージャ３０４Ａは現在のデルタの優先処理に依存しているためこれまでに処理されていなかったデータがホールド・デルタ・キュー１０１６にあるかどうかを判定する。このようなデルタがある場合、メソッドはステップ１１２４に戻って処理を行なう。このようなデルタがステップ１１２４、１１２６、１１２８のループで全て処理された後、メソッド１１００はステップ１１０２に戻る。
【０１１３】
データの一貫性を最適化するためのデルタ処理の前述の方法は本明細書で説明しているような実装でとくに有利であり、その場合には、Ａ）ピア・ユニットはネットワークから一時的に切断されることがあるからローカル・デルタが順序を外れて処理されるような長い遅延の後までデルタを受信しないことがある、Ｂ）エンドポイントはメンバーシップのリストに動的に加入したり脱退したりすることがある、Ｃ）データの一貫性に関するオーバヘッドは最小限に押えられピア・ユニット間に分散される。
【０１１４】
さらに別のエンドポイント・ナンバリング・スキーマは本発明の特定の実施態様において有利に用いることができる。たとえば、擬似乱数ジェネレータを使ってユニークなテレスペースメンバー識別子を割り当てるようなスキーマを実現できる。乱数ジェネレータが充分にランダムな数を生成しシード（種）が充分ユニークなものであれば一意性を保証できる。たとえば、ネットワーク・アダプタのＭＡＣアドレスをジェネレータのシードとして使用し３２バイト値を作成することでテレスペース内に限らずＡＢＣシステム内でも一意性を保証できる。
【０１１５】
アクティビティを構成する各ツール−エンジンの組み合わせが別々のダイナミクス・マネージャに対応できることと、多数のダイナミクス・マネージャを提供してた数の同時に実行するアクティビティに対応できる点で、ＡＢＣシステムはマルチタスク、マルチスレッドにすることもできる。テレスペースとダイナミクス・マネージャの間の一対一の関係ではデルタ処理で最小の遅延が導入されるが、スレッドが窮乏する（ｓｔａｒｖａｔｉｏｎ）とエラー状態またはフォールト状態を起してしまうことがある。他方、単一のダイナミクス・マネージャで多くのテレスペースをサポートすると渋滞（ｃｏｎｇｅｓｔｉｏｎ）の問題が起こることがある。各コンポーネントの最適な個数はハードウェアの用途、参加するピア・ユニットの個数、トラフィック条件によって左右される。
【０１１６】
ＡＢＣシステムは複数のコンピュータ・システム（ＣＳ）を含み、その各々が１つ以上のテレスペース（ＴＳ）を備え、各テレスペースが１つ以上のアクティビティ・コンポーネントを具現化（ｉｎｓｔａｎｔｉａｔｉｏｎ）し、各アクティビティ・コンポーネントには１つ以上のツール（Ｔ）とエンジン（Ｅ）のペアを有し、これら各々の動作はダイナミクス・マネージャ（ＤＭ）によって調整される。つまり、ＡＢＣシステムは１つ以上のダイナミクス・マネージャを備えた多数のテレスペースを有することができる。したがって、ＡＢＣシステムはたとえば次のように構成することができる：
ＡＢＣシステム＝
ＣＳ1  ＝  ＤＭ1  ＋  Ａ1、  ここでＡ1  ＝  Ｔ1  ＋  Ｅ1
ＣＳ2  ＝  ＤＭ2  ＋  Ａ2、  ここでＡ2  ＝  Ｔ2  ＋  Ｅ2
．．．
．．．
ＣＳn  ＝  ＤＭn  ＋  Ａn、  ここでＡn  ＝  Ｔn  ＋  Ｅn
【０１１７】
ここで全部のアクティビティＡ、Ａ２、Ａｎは１つ以上のテレスペースに含まれるものとし、”ｎ”は正の整数である。つまり、例を挙げると、様々なテレスペースのインスタンシーエションの例は次のようになる：
ＴＳ  ⊂  Ａ1、  または
ＴＳ  ⊂  Ａ1  ＋  Ａ2、  または
ＴＳ  ⊂  Ａ1  ＋  Ａ2  ＋  Ａm
あるいは
ＴＳ1  ⊂  Ａ1
ＴＳ2  ⊂  Ａ2
．．．
ＴＳm  ⊂  Ａm
【０１１８】
ここで記号「⊂」は「〜を含む集合」を表わし、「ｍ」は正の整数である。したがって、各テレスペースは１つまたはそれ以上のアクティビティを具現化し、フレームワークは単一のテレスペースを有することができる。別の方法では、各テレスペースは１つ以上のアクティビティを具現化し、フレームワークが多数のテレスペースを有することができる。
【０１１９】
前述した実施態様のコンポーネントをソフトウェアで実装したものは、たとえばコンピュータで読み取り可能な媒体、たとえば図１のディスケット１４２、ＣＤ−ＲＯＭ１４７、ＲＯＭ１１５、またはハードディスク装置１５２などの有形の媒体上に固定されるか、またはモデムまたはその他のインタフェース・デバイスたとえば媒体１９１上のネットワーク１９５に接続した通信アダプタ１９０を介して送信することができるかのどちらかのコンピュータ用命令及びルーチンを含む。媒体１９１は光通信回線または有線通信回線を含みこれに制限されない有形の媒体であるか、またはマイクロ波、赤外線、またはその他の通信技術を含みこれに制限されない無線技術で実現される。これはまたインターネットであっても良い。一連のコンピュータ用命令が本明細書で本発明に関連して前述し多機能の全部または一部を実現する。多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用される多数のプログラミング言語でこのようなコンピュータ用命令を書くことができることは当業者には理解されよう。さらに、このような命令は現在または将来の、半導体、磁気、光、またはその他のメモリ・デバイスを含みこれに制限されない何らかのメモリ技術を用いて保存することができ、あるいは現在または将来の、光、赤外線、マイクロ波、またはその他の送信技術を含みこれに制限されない何らかの通信技術を用いて送信される。このようなコンピュータ・プログラム製品が、印刷したまたは電子化された説明を伴ったリムーバブル媒体、たとえばシュリンクラップ・ソフトウェアとして配布される、コンピュータ・システムのたとえばシステムのＲＯＭまたは固定ディスク上にプリロードされる、またはたとえばインターネットまたはＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）などのネットワーク上のサーバまたは電子掲示板システムから配布されることを想定している。
【０１２０】
本発明の代表的実施態様を開示したが、本発明の利点の幾つかを実現する様々な変化や変更を本発明の精神と範囲から逸脱することなく成し得ることは当業者には明らかであろう。同じ機能を実行する他のコンポーネントが適宜置き換えられることができることは当業者には明らかであろう。さらに、本発明の方法は適当なプロセッサ用命令を用いるソフトウェアで全て実装したもの、またはハードウェア論理とソフトウェア論理とを組み合わせて用いて同じ結果を実現しようとするハイブリッド型で実装したもののどちらかで実現可能である。さらに、メモリの容量、特定の機能を実現するために使用される論理および／または命令の特定の構成、ならびに本発明のコンセプトに対するその他の変更はすべて添付の請求の範囲に含まれることを意図している。
【図１】
2011175654.tif 000003
【図２】
2011175654.tif 000004
【図３】
2011175654.tif 000005
【図４】
2011175654.tif 000006
【図５】
2011175654.tif 000007
【図６】
2011175654.tif 000008
【図７】
2011175654.tif 000009
【図８】
2011175654.tif 000010
【図９】
2011175654.tif 000011
【図１０】
2011175654.tif 000012
【図１１Ａ】
2011175654.tif 000013
【図１１Ｂ】
2011175654.tif 000014
【図１２】
2011175654.tif 000015