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