JP2003536123A - 通信マネージャを備えたコンピュータ・システムによるアクティビティに基づいたコラボレーションのための方法及びその装置 - Google Patents

Abstract

(57)【要約】 本発明では、デルタを含むデータ変更要求がネットワーク接続可能なデバイス間でネットワークを介して通信されるようなコラボレーション・システムのための通信サービスを通信マネージャが提供する。通信マネージャはネットワーク接続可能なローカル・デバイス上で動作してローカルな場所で生成されたデルタをネットワークを介して少なくとも一つのネットワーク接続可能なリモート・デバイスへ送信し、また少なくとも一つのネットワーク接続可能なリモート・デバイスからネットワークを介してリモートな場所で生成されたデルタを受信する。通信マネージャはユニキャスト技術、マルチキャスト技術、またはブロードキャスト技術でデルタを送信できる。通信マネージャはネットワーク接続可能なリモート・デバイスがネットワークに接続されていることを示すネットワーク接続状態情報に呼応してローカルな場所で生成されたデルタをネットワーク接続可能なリモート・デバイスのアドレスへ直接送信する。プレゼンス機構は要求に応じて、ネットワーク接続可能なデバイスの各々から取得するネットワーク接続状態情報を維持また配布する。通信マネージャはさらにネットワーク接続可能なリモート・デバイスがネットワークから切断されていることを示すネットワーク接続状態情報に応じてローカルな場所で生成されたデルタをリレーのアドレスへ送信する。ネットワーク接続可能なリモート・デバイスがネットワークに再接続されたことがリレーに通知されるまでリレーはデルタを保存しておき、リレーが再接続されたネットワーク接続可能なリモート・デバイスへデルタを送信する。

Description

【発明の詳細な説明】

【０００１】 発明の分野 本発明はインターネットなどのネットワークを介して通信できるように相互に
接続されたコンピュータに関し、さらに詳しくは分散型データ・モデルに準拠し
てデータを調整あるいは維持するための分散型コンピュータシステムに関する。

【０００２】 発明の背景 インターネットは、数百万のユーザ間での通信及び対話（ｉｎｔｅｒａｃｔｉ
ｏｎ）のためのダイナミックな公共の環境を作り出した。ビジネスにおいては、
インターネットによりベンダとメーカ、メーカとディストリビュータ、ディスト
リビュータとカスタマ、その他の関係が再定義された。個々の企業の社内にある
機密ネットワークへインターネット技術が拡張され、これらは「イントラネット
」あるいは「プライベート・インターネット」と呼ばれているが、会社のディレ
クトリ及び会社のネットワーク・インフラストラクチャを使って、新しい形で社
員間、またワークグループ間でのドキュメントや情報の共有ができるようになっ
た。オンライン・サービスたとえば電子掲示板やチャットルーム、電子商取引ま
た製品のテクニカルサポートなどが、インターネットを介して運営されているウ
ェブ（ＷＷＷ （Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ））上で利用できる。

【０００３】 インターネットは、その中心に、サーバ・クライアント・アーキテクチャがあ
り、これは個々のクライアント（即ちインターネット・コンテンツのユーザ）が
たとえばブラウザなどのコンピュータで実行可能なアプリケーションを介してサ
ーバ（インターネット・コンテンツのプロバイダ）とインタフェースし、ウェブ
・サイトからドキュメントを入手する。ブラウザはソフトウェア・プログラムで
、パーソナル・コンピュータからインターネット・ドキュメントを要求、受信（
たとえばダウンロード）、解釈、表示することができるようにし、また一般にイ
ンターネットを散策（ｎａｖｉｇａｔｅ）できる。ウェブ・サーバは典型的には
外部プログラムを実行するための標準インタフェースを備え、最も一般的なイン
タフェースはＣｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ （ＣＧＩ）
である。ウェブ・サイトはドキュメントの集合で、通常はホームページと、これ
にリンクされるドキュメントで構成され、クライアントから離れたリモートな場
所にあるサーバ上に配置されている。ドキュメントはコンパウンド・ドキュメン
トであっても良く、これはデータ、グラフィックス、ビデオ、サウンド、および
／またはその他の形式のメディアならびに他の文書へのリンクで構成される。基
本的に、ＷＷＷは相互接続されたドキュメントの、または、さらに正確にはイン
ターネット上の様々なサイトに配置されているドキュメント・オブジェクトのウ
ェブ（蛛の巣：ｗｅｂ）である。

【０００４】 ＷＷＷ上のドキュメント・オブジェクトの形式にはドキュメントとスクリプト
とがある。スクリプトは実行可能なプログラムまたはファイルに格納された一組
のコマンドであり、これがウェブ・サーバにより実行され、ドキュメントを作成
し、そのドキュメントがウェブ・ブラウザへ返される。スクリプトによる代表的
なアクションには、ライブラリ・ルーチンまたはその他のアプリケーションを実
行してファイルまたはデータベースから情報を取り出すこと、または選択された
ハイパーテキスト・リンクに対応する文書を取得することが含まれる。スクリプ
トは、たとえば、ユーザがウェブ・ブラウザ上で特定のハイパーテキスト・リン
クを選択した時に、ウェブ・サーバ上で実行される。

【０００５】 インターネット技術の基礎となっているものは標準化の進歩であり、これには
パーソナル・コンピュータのハードウェア、ソフトウェア、ネットワーク・プロ
トコル、インフラストラクチャの標記方法（たとえばＵｎｉｆｏｒｍ Ｒｅｓｏ
ｕｒｃｅ ＬｏｃａｔｏｒまたはＵＲＬ）が含まれる。ＵＲＬはＷＷＷにある全
てのドキュメント・オブジェクトについてその位置のアドレスを提供する。ＵＲ
Ｌはドキュメント・オブジェクトを唯一無二の形で（以下、ユニークに）参照し
、しばしばインターネット・プロトコルを用いたアクセス・アルゴリズムを定義
する。

【０００６】 本明細書で使用されている表現として、「インターネット・プロトコル」は、
インターネット上で送信するためのドキュメントを含むメッセージを生成するた
めに一般に受け入れられて使用されたり、またはインターネット上でこうしたメ
ッセージを送信するための、それぞれ現行のまたは将来の言語表記および現行ま
たは将来の通信プロトコルであると定義される。これらの言語表記には、たとえ
ば、現時点ではＨｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＨＴ
ＭＬ）やｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ）
が含まれる。これらの通信プロトコルはたとえば現時点では、Ｈｙｐｅｒｔｅｘ
ｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＨＴＴＰ）、ＴＣＰ／ＩＰ、ＦＴ
Ｐ、ＧＯＰＨＥＲ、ＮｅｔＢｉｏｓ、ＳＰＸ／ＩＰＸ（ＴＭ）、ＡｐｐｌｅＴａ
ｌｋ（ＴＭ）などを含む。通信プロトコルの主な必要条件はアドレス可能なネッ
トワーク・デバイスカンで信頼性のあるまたは信頼性のない指向性セッションの
確率をサポートすることである。当業者はこれらの言語表記やプロトコルに詳し
いであろう。

【０００７】 ＨＴＭＬはハイパーテキスト・ドキュメントを記述するために使用される言語
で、マルチメディア・コンテンツや他のドキュメントへのリンクを含む。ＨＴＭ
Ｌドキュメントはマークアップ要素（以下、マークアップ・エレメント）の階層
的セットを含み、多くのエレメントが開始タグとこれに続くコンテンツ、さらに
それに続く終了タグを備える。タグはアングル・ブラケット（＜と＞）で囲み、
ドキュメントがどのような構造になっているか、ドキュメントをどのように表示
するか、またハイパーテキスト・リンクのリンク先とラベルなどを表わす。マー
クアップ・エレメントのためのタグが存在しており、これらはたとえばタイトル
、ヘッダーや、ボールド、インタリックなどのテキスト属性、リスト、パラグラ
フ境界、他のドキュメントへの外部リンク、また同じ文書の他の部分への内部リ
ンク、グラフィック画像、及びその他多くのドキュメント機能などである。ＨＴ
ＭＬを使ったプログラミングに関しては多くの成書が流通している。

【０００８】 ＸＭＬはインターネット・プロトコルに含まれるもう一つの言語表記である。
ＸＭＬは、少なくとも現行バージョンでは、ＨＴＭＬと互換性があってこれを補
足するものである。コンピュータに格納されていて、ＸＭＬドキュメントと呼ば
れるデータ・オブジェクトのクラスを記述する、またこれらのオブジェクトを処
理するプログラムの動作を記述する標準的な方法である。ＸＭＬドキュメントは
エンティティ（ｅｎｔｉｔｉｅｓ）と呼ばれる格納単位から構成され、これには
テキストデータまたはバイナリデータのどちらかが含まれる。テキストは文字か
ら構成され、その幾つかはドキュメントの文字内容を構成し、別の幾つかはマー
クアップ（ｍａｒｋｕｐ）を構成する。マークアップはドキュメントの記述たと
えば格納レイアウトや論理構造などを記述する（以下、エンコードする）。ＸＭ
Ｌ処理装置と呼ばれるソフトウェアモジュールを使用してＸＭＬドキュメントを
読み出し、その内容や構造へのアクセスを提供する。ＸＭＬに関するさらに詳し
い情報はＸＭＬ仕様バージョン１．０への参照で得ることができ、＜ＨＴＴＰ：
／／ｗｗｗ．ｗ３．ｏｒｇ／ＸＭＬ＞で利用可能であり、また本明細書の参照に
含めてある。

【０００９】 ウェブ・サーバとウェブ・ブラウザは代表的にはＨＴＴＰメッセージプロトコ
ルおよびその基盤となるインターネットのＴＣＰ／ＩＰデータトランスポート・
プロトコルを用いて通信する。ＨＴＴＰにおいて、ウェブ・ブラウザはウェブ・
サーバへの接続を確立してからＨＴＴＰ要求メッセージをサーバに送出する。要
求メッセージに呼応して、ウェブ・サーバは認証をチェックし、たとえばＵＲＬ
で識別されるドキュメントをダウンロードするなどの要求された動作を実行し、
要求された動作で得られたＨＴＭＬドキュメントあるいはエラーメッセージのど
ちらかを含むＨＴＴＰ呼応メッセージを返す。返されたドキュメントは単にウェ
ブ・サーバ上に格納されているスタティック（静的）ファイルであったり、要求
メッセージに呼応して呼び出されたスクリプトを使用して動的に生成されること
がある。

【００１０】 ＴＣＰ／ＩＰプロトコルを使用するネットワークは宛先デバイスのインターネ
ット・プロトコル（ＩＰ）に従ったアドレス（以下、ＩＰアドレス）に基づいて
メッセージを転送する。ＩＰアドレスは特定のフォーマットに準拠したもので、
現在のところピリオドで区切られた４個の数字で表わされる３２ビットの数値ア
ドレスを含む。ネットワーク上の各デバイスはネットワーク上で通信に使用する
ユニークなＩＰアドレスを有する。本明細書で以降使用する術語「ＩＰアドレス
」は、文脈に応じて、現在の又は将来のインターネット・プロトコルに準拠した
アドレス方式を含むことを想定している。

【００１１】 インターネットを活用するために、インターネット・プロトコルに準拠したツ
ールや資源が開発されており、これには企業で必須のアプリケーションたとえば
ｅメール（ｅ−ｍａｉｌ）が含まれる。ｅメールというのは電子メールのことで
、これを用いて選択したアドレスで電子的にドキュメントを送受信する。インタ
ーネットを使う対話の大半が、「ドキュメントの送受信」モデルに従ったｅメー
ルの使用や、その他のブラウザを使うメディアであると予想されていた。おそら
くはこのモデルのために、ユーザはインターネットを本質的に「ピア・ツー・ピ
ア」的なものであり、これによって個人が他の個人によって提供されたドキュメ
ントにアクセスできるものであり、しかも、もっと大きな権限を有する者による
干渉を受けないでできるものであると見なすことが多い。

【００１２】 インターネットはユーザに娯楽を提供したり通信の有用な方法を提供する上で
ダイナミックかつフレキシブルなものであるが、ユーザの要求の全部を満たすこ
とはできない。ユーザはますますインターネットを通して対話するようになるが
、もっと在来型の方法たとえばマルチメディア（電話、ファックス、ホワイトボ
ード）のものやマルチテンポラル（リアルタイム、オーバーナイト・メール）な
もの、またその他形式にとらわれない通信手段を使うことにより、インターネッ
ト以外での対話も引き続き行われている。

【００１３】 共有されるプライベート空間での個人や中小グループ間でのパーソナルでプラ
イベートな通信やその他共有される相互の活動にインターネットに基づくパラダ
イムを拡張することが望ましい。このような対話は、参加者のパーソナルコンピ
ュータ間またはその他のネットワーク接続可能なデバイス間で即時的、直接的、
機密的に行なわれるのが望ましく、これらの対話は、通信が傍受されたり機密性
が侵害されたりするような第三者のウェブ・サイトへとインターネット上のトラ
フィックが集中させるようなサーバ・ボトルネックとは何ら関わりを持たないの
が良い。

【００１４】 また様々な遠隔地（以下、リモートサイト）にいるユーザがピア・ツー・ピア
の形式でドキュメントを共有し編集できるようにする一方で、ローカルサイトに
おいてドキュメントの一貫したコピーを維持することのできる技術を提供するの
も望ましい。このような技術ではユーザの誰もがドキュメントに関する変更要求
を発行でき、変更要求が発行された時点でサイトがネットワークから切断されて
も当該変更が調整された方法で全てのローカルサイトにあるコピーに対して非同
期的に行なわれる。

【００１５】 発明の要約 本発明はパーソナルコンピュータ・システム、通信装置、またはその他のネッ
トワーク接続可能なデバイスで動作可能で、遠隔地に居る他のユーザと共有して
特定のタスクたとえば「チャット」、ゲーム、またはビジネスアプリケーション
を実行するためのアクティビティとよばれる装置に関するものである。アクティ
ビティはデルタと呼ばれるデータ変更要求をユーザとの対話呼応して生成するた
めのツールを含む。アクティビティはデータ・モデルに準拠して不揮発性で永続
的であることが望ましいメモリにデータを保存するためのデータ変更エンジンも
備える。データ変更エンジンはツールからデルタを受信して、そのデルタにその
要求を実行するアクティビティ特有のコマンドを提供し、デルタの実行に起因す
るデータ変更をツールへ通知するためのツール・エンドを含む。データ変更エン
ジンはダイナミクス・マネージャからデータ変更指示を受信してからデルタを実
行する、即ちデルタのコマンドを実行して要求された変更をデータに加えるため
のダイナミクス・マネージャ・エンドも含む。

【００１６】 別の態様において、本発明は「テレスペース」と呼ばれる共有プライベート空
間で個人及び中小グループ間の通信及びその他の共有及び相互活動を提供するた
めのシステムに係る。本システムにおいて、テレスペースの参加者またはメンバ
ーはネットワーク接続可能なデバイスを介して対話し、デバイスはたとえばイン
ターネットまたはイントラネットなどのネットワーク上で互いに通信してテレス
ペース・データのローカルコピーを個々に格納する。各々のテレスペースはテレ
スペースのメンバーのネットワーク接続可能なデバイス各々で動作可能な１つま
たはそれ以上のアクティビティのインスタンシエーションである。各々のアクテ
ィビティはテレスペースのメンバーとの対話に呼応してデータ変更要求またはデ
ルタを開始するための１つまたはそれ以上のツールを含む。各々のアクティビテ
ィはまた、ツールとは別に、共通データ・モデルに準拠したテレスペース・デー
タのローカルコピーを保持するための１つまたはそれ以上のデータ変更エンジン
も含む。データ・モデルはたとえば、アクティビティに固有であって、テレスペ
ース全体にわたるのが望ましい。各々のネットワーク接続可能なデバイスもロー
カルな場所で生成するデルタについて、デルタに呼応して、要求された変更をデ
ータのローカルコピーに適用することによりデータ変更エンジンに指示を出して
デルタを実行させるためと、様々なネットワーク接続可能なデバイスからのデル
タの実行を調整するためのダイナミクス・マネージャを含む。

【００１７】 さらに別の観点においては、本発明は望ましくはインターネット・プロトコル
に従って通信するように接続された望ましくはネットワーク接続可能な別の場所
にある複数のデバイスを含むネットワーク化されたシステムにおいて実施できる
。ネットワーク接続可能な各のデバイスは（ａ）共通データ・モデルに準拠して
アクティビティに関連するデータのローカルコピーを格納するためのメモリ、（
ｂ）前述のデータ変更エンジンに対応する１つ以上のツールを各々が含む１つ以
上のアクティビティ、（ｃ）デルタが関係するテレスペースに参加するネットワ
ーク化されたシステムのネットワーク接続可能な全てのデバイスの間でデルタを
共有させるための通信マネージャ、（ｄ）ローカルに生成されたデルタと遠隔地
で生成された（以下、リモート生成された）デルタの両方の実行を調整するため
のダイナミクス・マネージャ、を含む。ネットワーク化されたシステムのネット
ワーク接続可能なデバイスのどれででもユーザの対話を開始してその結果として
のデルタを生成することができ、このときのデルタは望ましくはネットワーク上
のデバイスの各々に送信される。ダイナミクス・マネージャはローカルのデータ
変更エンジンの動作を指示し、望ましくはデルタの実行に優先順位を付けてネッ
トワーク化されたシステム全体でのデータの実質的な一貫性を維持する。ネット
ワーク化されたシステムは様々なリモートサイトにいるユーザに対して、たとえ
ばデータを共有して編集したり、ピア・ツー・ピア型の形式でその他の活動を独
立して実行できるようにする一方で、ネットワークから切断されている時でも各
々のネットワーク接続可能なデバイスで使用するデータの実質的に一貫したコピ
ーを保持することができるようにする。

【００１８】 さらに別の観点においては、本発明は個人間の対話のためのアクティビティに
基づくコラボレーションシステム（ＡＢＣシステム）として実装可能である。Ａ
ＢＣシステムはたとえば公衆ネットワーク（たとえばインターネットまたはワイ
ドエリアネットワーク（ＷＡＮ））経由またはプライベート・ネットワーク（ロ
ーカル・エリア・ネットワーク（ＬＡＮ）またはイントラネット）経由で、ケー
ブル、光ファイバー、赤外線（ＩＲ）またはその他の形式の通信リンクにより前
述のネットワーク化されたシステムを形成するように接続可能なネットワーク接
続可能な複数のデバイスを含む。ネットワーク接続可能な各々のデバイスは前述
のメモリと、１つ以上のダイナミクス・マネージャを含むフレームワークを装備
している。ネットワーク接続可能なデバイスは公衆ネットワーク・インフラスト
ラクチャ、パーソナル・デスクトップ・アプリケーション、及びインフラストラ
クチャ（時に「パーソナル・インターネット」と呼ばれることがある）、また適
用可能なら企業内イントラネットともプラグイン式に互換性を有するものが望ま
しい。ＡＢＣシステムは動的に挿入可能型アクティビティ・コンポーネント（以
下、ダイナミックなスナップイン・アクティビティ・コンポーネント）を使用す
るのが望ましく、各々がたとえば「チャット」、ドキュメント編集、ゲーム、な
どの特定のタスクを実行する。アクティビティ・コンポーネントはたとえばシュ
リンクラップ製品として利用できたりまたはたとえばインターネットなどのネッ
トワーク上からダウンロードできるソフトウェアを含むことができる。アクティ
ビティ・コンポーネントはフレームワークと共通のＡＰＩ（アプリケーション・
プログラミング・インタフェース）を介して動作可能である。したがって、フレ
ームワークはアクティビティ・コンポーネントの形をとるアプリケーションのた
めのプラットフォームであると見なすことができまたそのように機能する。

【００１９】 本発明のさらに別の観点においては、ローカルな場所で生成したデルタをネッ
トワーク接続可能なリモート・デバイスへ送信するためとリモートな場所で生成
されたデルタをネットワーク接続可能なリモート・デバイスから受信するための
ネットワーク接続可能なローカル・デバイスで動作可能な通信マネージャをさら
に含むフレームワークに関する。通信マネージャはネットワーク接続可能なリモ
ート・デバイスへ直接たとえば各々のＵＲＬに、または「格納及び送信」方式（
以下、「ストア・アンド・フォワード」方式）のリレーへたとえばそのＵＲＬへ
、ネットワーク接続可能なリモート・デバイスに関するネットワーク接続状態の
情報に応じて、選択的に送信可能である。ネットワーク接続状態情報は、たとえ
ば通信プロトコルの互換性や、ローカル・デバイスからリモート・デバイスへ到
達できなくするような機密性の問題（たとえばファイアウォール）に関する情報
などを含み通信マネージャによって保持される接続性情報を含むことがある。接
続状態情報はさらに、たとえばプレゼンス・サーバなどのプレゼンス機構によっ
て保持されるものであって、リモート・デバイスのオンライン／オフライン状態
に関する情報も含むことができる。プレゼンス・サーバはＡＢＣシステムの一部
をなすことができ、たとえば通信マネージャへネットワークを介してオンライン
／オフライン状態情報を送信することを担当する。ネットワーク接続可能なリモ
ート・デバイスが一時的にネットワークへ接続されていない状態（「オフライン
」状態）では、リレーはネットワーク接続可能なリモート・デバイスがネットワ
ークへ再接続したと通知されるまでデルタを保管しておき、再接続したらネット
ワーク接続可能なリモート・デバイスへデルタを送信することができる。ネット
ワーク接続可能なリモート・デバイスからのデルタ受信では、通信マネージャが
プレゼンス・サーバへオンライン／オフライン状態情報を送出してネットワーク
接続可能なローカル・デバイスがネットワークに接続しているか（「オンライン
」状態）したがってリモート・デバイスからのデルタの受信が可能かどうかを通
知する。

【００２０】 つまり、本発明はそれぞれ別個の商業製品やサービスとして実現可能で、これ
には個々のアクティビティ・コンポーネント、ネットワーク接続可能な個々のデ
バイス用のフレームワークおよび／またはネットワーク化されたシステムまたは
ＡＢＣシステム、ならびにシステムを構成するデバイス間の対話を行なうための
通信サービスの提供を含む。

【００２１】 好適実施態様の詳細な説明 Ａ．術語 最初に、本明細書で使用している幾つかの術語と略語を紹介するのが有用であ
ろう。これには以下を含む：アクティビティ、クライアント、通信マネージャ、
コンポーネント、コントローラ、デルタ、デバイス、ダイナミクス・マネージャ
、エンジン、フレームワーク、アイデンティティ、メンバー、ナビゲーション、
人、サーバ、テレスペース、ツール、ＵＲＬ、ＸＭＬ。

【００２２】 アクティビティ（Ａｃｔｉｖｉｔｙ）は、あるユーザが他のユーザと対話する
ために実際にはＡＢＣシステムで何をするかを表わす。術語「アクティビティ」
は状況によって二つの意味のどちらかを取ることができる。「アウトサイド・ビ
ュー」からは、ＡＢＣシステムとコンピュータ・ユーザとの間のランタイムの対
話を意味する、たとえばこの種のアクティビティでは共有ホワイトボードに描画
するのをユーザに許可したり、または二人以上のユーザがリアルタイムでチャッ
トするのを許可する。この意味でのアクティビティはまたバックグラウンド・サ
ービス（即ちエージェント）であっても良い。これはローカルデバイスまたはサ
ーバデバイス上でユーザの側で動作し、たとえばアーカイブサーバ・エージェン
ト、または受信ＦＡＸエージェントなどである。ソフトウェア設計者の「インサ
イド・ビュー」からは、「アクティビティ」はユーザのパーソナル・コンピュー
タまたはその他の形態の装置上で動作することができ決まったタスクを実行する
モジュール化されたプログラムであってコンピュータで実行可能なプログラムを
表わす。この意味でのアクティビティはツールとエンジンという２種類のコンポ
ーネントからなり、これらは設計時に統合されて「アクティビティ・テンプレー
ト」を作成する。アクティビティ・テンプレートはたとえばシュリンクラップ・
ソフトウェアとして、またはウェブからダウンロードできるソフトウェアとして
、など多くの方法で配布することができる。ワープロ、スプレッドシートなどに
使用するため広く配布されるプログラムはＡＢＣシステムで使用できるように設
計されたバージョンであって、ＡＢＣシステムプログラマ・インタフェースに適
合するアクティビティ・テンプレートの形で販売されるバージョンを有するもの
として考えている。

【００２３】 クライアント（Ｃｌｉｅｎｔ）は、ユーザのパーソナル・コンピュータ、通信
機器、またはその他の形のデバイスで、ヒトとの対話ができ、ネットワークたと
えばインターネットに接続可能なものを表わす。ユーザのパーソナル・コンピュ
ータ上で実行されるバックグラウンド・プログラムは「クライアント・サービス
・コントローラ」と呼ばれる。ユーザのパーソナル・コンピュータ上で実行され
るフォアグラウンドのユーザ・インタフェース（ＵＩ）プログラムは「クライア
ントＵＩコントローラ」と呼ばれる。

【００２４】 通信マネージャ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｎａｇｅｒ）は、しか
るべき宛先とのデルタの送受信を指示するメカニズムを表わす。通信マネージャ
はたとえば、コンピュータで実行可能なプログラムとして実装することができ、
これが、ネットワークたとえばインターネット上で送信するためにツール／エン
ジンのペアで作成されてローカルに開始したデルタを別のリモート・パーソナル
・コンピュータへまたは他の形のネットワーク接続可能なデバイスへ送信する、
またはそのリモートデバイスがネットワークに接続されていない場合にはリレー
装置へ送信するもので、またこれはネットワークたとえばインターネット上で受
信されるリモートで生成されたデルタをダイナミクス・マネージャへ送信する。
通信マネージャはたとえばそのリモート・デバイスがネットワークに接続されて
いない場合には、またはネットワークバンド幅の有効利用または通信効率を向上
するため（たとえばファンアウトやルーティング）このようなデルタをリレーへ
転送する。通信マネージャはネットワークたとえばインターネット上で受信され
るリモートな場所で生成されたデルタをダイナミクス・マネージャへ送信する。

【００２５】 コンポーネント（Ｃｏｍｐｏｎｅｎｔ）は、コンピュータで実行可能なプログ
ラムとアクティビティ内部で使用されるその資源を表わす。全てのコンポーネン
トはＵＲＬで識別される。ウェブがコンポーネントのグローバル・リポジトリで
、ＡＢＣシステムの適当なコンポーネント・プラットフォームへ確実にダウンロ
ード可能なバージョンを備えるものとして考えている。

【００２６】 コンピュータ（Ｃｏｍｐｕｔｅｒ）は、以下で定義するような装置を表わす。

【００２７】 コントローラ（Ｃｏｎｔｒｏｌｌｅｒ）は、トップレベルにあるプログラムで
あってコンピュータで実行可能なプログラムを表わし、これはＡＢＣシステムの
「内部」機能を駆動する。コントローラは任意のプラットフォームたとえばＵＮ
ＩＸ^ＴＭのデーモン・コントローラまたはインテル社製マイクロプロセッサ搭載
コンピュータ・システム上で動作するマイクロソフト・ウインドウズ（ＴＭ）用
コントローラとしてチューニングされる。一般的な２種類のコントローラとして
は、一般にユーザからは見えないバックグラウンド・プロセスとして動作するサ
ービス・コントローラと、ユーザが対話的に制御するユーザ・インタフェース（
ＵＩ）コントローラがある。

【００２８】 デルタ（Ｄｅｌｔａ）は、１つまたはそれ以上のツールからエンジン宛てのデ
ータ変更要求（即ちデータに対して希望する変更についての通知またはプロンプ
ト）を内包する自己内包型のデータユニットを表わす。ツールはユーザとの対話
に呼応してダイナミクス・マネージャによるデルタ作成を開始し、後述するよう
に、ダイナミクス・マネージャの制御下で非同期実行のためにこれらをエンジン
に送信する。デルタは制御情報を提供するヘッダ部分と、要求が関連するデータ
に関する情報を提供するペイロード部分とを含む特定のフォーマットを持ってい
る。個々のデルタは１つまたはそれ以上のペイロードを持つことができ、多数の
ペイロードを使用する場合には各々をユニークなデバイス機能またはユーザの役
割を有するテレスペース・メンバーあてに指定できる。ツールはユーザへの表示
用またはその他の形でのプレゼンテーションを行なうためエンジンから潜在的デ
ータ変更に関する情報を要求し、デルタが表示を変更させた時に非同期的に通知
される。

【００２９】 デバイス（Ｄｅｖｉｃｅ）は、たとえばパーソナル・コンピュータ（ｐｃ）や
通信機器など、本明細書では文脈からして特に別のものが示されない限りは、通
常ネットワーク接続可能な、即ちネットワーク接続可能な他のデバイスとネット
ワーク上たとえばインターネット上でインターネット・プロトコルを使用して通
信することができるような物理的ハードウェア装置を表わす。全てのデバイスに
はユニークな識別コードがＡＢＣシステムによって割り当てられ、ＵＲＬを有し
、デバイスを使用する者とは区別される。デバイスは潜在的に多くのテレスペー
スをホスティングする。デバイスは、たとえば、ｐｃであったり、セルラホン、
ファックス、ハンドヘルド・オーガナイザ、ケーブルテレビのセットトップ・ボ
ックス、エンターテイメント用電子ユニット（たとえば電子玩具やゲームと、ス
テレオ装置、またはこれら以外の同様にネットワーク接続可能な機器、装置、製
品など）のことがある。デバイスは潜在的に多くのテレスペースをホスティング
する。

【００３０】 ダイナミクス・マネージャ（Ｄｙｎａｍｉｃｓ ｍａｎａｇｅｒ）は、ＡＢＣ
システムのフレームワークの一部を表わし、デルタの作成を支援したりデルタの
実行を調整する。ダイナミクス・マネージャはたとえば、ユーザのパーソナル・
コンピュータ上でまたはその他の形態を有しネットワーク接続可能なデバイス上
で動作するコンピュータで実行可能なプログラムとして実装することができる。

【００３１】 エンドポイント（Ｅｎｄｐｏｉｎｔ）は、デバイスと人のユニークなペアを表
わす。ＡＢＣシステムでは、ある１つのデバイスの多数のユーザの中から一人の
人をユニークに識別する方法として、またはその同じ人によって使用される多数
のコンピュータの中から１つのデバイスや複数のデバイスを識別する方法として
、この概念を使用する。

【００３２】 エンジン（Ｅｎｇｉｎｅ）は、ＡＢＣシステム内部の永続的格納及びデータ構
造の管理及び変更を実現するものであってアクティビティの「下半分」と呼ばれ
るものを表わす。エンジンはコンポーネントとしてパッケージされ、それ自体に
はユーザ・インタフェースがなく、ユーザ・インタフェースについては対応する
ツールに依存し、実質的に移植可能である。エンジンは対応するツールを機能さ
せるためにのみ存在するのが望ましい。エンジンはユニバーサル同期（ｕｎｉｖ
ｅｒｓａｌ ｓｙｎｃｈｒｏｎｙ）した状態で動作するのが望ましい。

【００３３】 フレームワーク（Ｆｒａｍｅｗｏｒｋ）は、ＡＢＣシステムの「内部動作」を
表わし、ダイナミクス・マネージャを始めそのサブシステムのほとんどのものを
含んでいるが、ユーザ・インタフェースはない。フレームワークはユーザのパー
ソナル・コンピュータ上またはその他の形態のネットワーク接続可能なデバイス
上で動作することのできるものでコンピュータで実行可能なプログラムであり論
理的には高レベルのコントローラとアクティビティの間に位置する。

【００３４】 アイデンティティ（Ｉｄｅｎｔｉｔｙ）は、一般に「人（ｐｅｒｓｏｎ）」と
同義語だが、一般にＵＲＬで表わされるもので他の人がある人を認知できる１つ
の名前を指す。この概念が使用される理由としては、ＡＢＣシステムではある人
が多くのアイデンティティまたは別名を持つことができ、またたとえば多くの異
なるＵＲＬを持てるという考え方を採用しているためである。

【００３５】 メンバー（Ｍｅｍｂｅｒ）は、テレスペース内部の参加者またはテレスペース
の加入者を表わし、一般にテレスペースのメンバーシップを表わす場合にはエン
ドポイントの人の部分（デバイス部分と区別して）と同義語である。

【００３６】 ナビゲーション（Ｎａｖｉｇａｔｉｏｎ）はＵＲＬ間を移動する動作を表わし
、ＡＢＣシステムではウェブ・ブラウザによるウェブページ間、ウェブサイト間
のナビゲーションと類似している。

【００３７】 人（Ｐｅｒｓｏｎ）は、人間、または人間の代理として作用するサーバを指し
、一般にテレスペース内部のアクティビティに参加している者を指す。各々の人
は１つまたはそれ以上のアイデンティティを有し、その各々はＵＲＬでユニーク
に識別される。

【００３８】 リレー（Ｒｅｌａｙ）はストア・アンド・フォワードを確実にまた高信頼性で
行ない、ある種の用途ではメッセージのマルチキャスト・ファンアウト（ｍｕｌ
ｔｉｃａｓｔ） ｆａｎ−ｏｕｔ）を実行できるようなデバイスたとえばサーバ
のことである。転送されるメッセージの本体はリレーにはわからず、またたとえ
ばデルタである場合がある。リレーはデバイス・プレゼンス情報を提供したり、
本発明の幾つかの実施態様において管理機能を実行することができる。

【００３９】 サーバ（Ｓｅｒｖｅｒ）は、通信チャンネルを介する場合を除き普通は人間と
の直接対話ができないがサービス・コントローラのもとでバックグラウンド・プ
ログラムとしてのみ実行することができるデバイスを指す。

【００４０】 テレスペース（Ｔｅｌｅｓｐａｃｅ）は、仮想空間であって、１つ以上のアク
ティビティに参加するために人びとが集まり、人びとが何らかのものを共有する
仮想空間を指す。テレスペースとアクティビティの結果はユーザのパーソナル・
コンピュータ上またはその他の形態のネットワーク接続可能なデバイス上のメモ
リに永続的に格納される。テレスペースは、一般に、あるユーザのデバイスと他
の人達のデバイスの間で同期を保っている。テレスペースは「メンバーシップ」
の論理的単位またアクティビティへのアクセスを表わす。テレスペースは１つ以
上のアクティビティのインスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）
である。

【００４１】 ツール（Ｔｏｏｌ）は、アクティビティのユーザ・インタフェースを実現する
ものであってアクティビティの「上半分」と呼ばれるものを指す。ツールはコン
ポーネントとしてパッケージされ、ユーザのジェスチャーに呼応してデルタの作
成を開始し、個々のアクティビティの対応するエンジンと対話して特定のタスク
を実行する。

【００４２】 ＵＲＬは、ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（汎用資
源識別子）の略語で、ドキュメントなどの資源の構造化されたユニークなアドレ
スであり、また場合によっては資源を取り扱うときの方法を表わす。ＵＲＬは本
明細書において実質的に全ての永続的オブジェクト、ユーザから見えるオブジェ
クト、及び外部プログラムから見えるオブジェクトについて使用される。

【００４３】 ＸＭＬは、前述の通り、拡張マークアップ言語（ｅＸｔｅｎｄｅｄ Ｍａｒｋ
ｕｐ Ｌａｎｇｕａｇｅ）の略語で、ウェブ上で使用することを想定したＳＧＭ
Ｌから派生した標準化され的構造化されたデータ・フォーマットである。状況に
よってはＡＢＣシステムで使用されるメモリ内のオブジェクト構造を表わすこと
もあり、これはＸＭＬ標準のセマンティクス（ｓｅｍａｎｔｉｃｓ）に準拠する
ものである。多くのＸＭＬの概念が本明細書で使用されており、たとえばドキュ
メント、エレメント、タグ、属性、値、コンテンツ、エンティティ、リンク、ポ
インタなどがある。ＸＭＬは本明細書ではたとえばドキュメント内のデータを構
造化するために使用される。

【００４４】 Ｂ．従来のコンピュータ・システム 図１は、代表的なコンピュータ・システム１００の従来型のシステム・アーキ
テクチャを図で表わしたものであり、開示された本発明をこれに実装することが
できる。図１に例示したコンピュータ・システムは説明の目的でのみ議論するが
、本発明を制限するものとして見なすべきではない。本発明はさらにコンピュー
タ・システムとして従来考えられてきたデバイスに制限されるものではなく、こ
れはたとえばビデオゲーム・コンソール、パーソナル機器、またはケーブルテレ
ビのセットトップボックスなどを含む各種のネットワーク接続可能なデバイスの
いずれにおいても本発明を実装できるためである。以下の説明は特定のコンピュ
ータ・システムを記述する際に共通に使用される術語を示しているが、説明され
る概念は図１に図示したものとは異なるアーキテクチャを有する他のコンピュー
タ・システムにも等しく適用されるものである。たとえば、ケーブルテレビのセ
ットトップボックスは大容量格納機能を含まないがデジタル信号プロセッサを内
蔵したビデオチューナを含んでいる。

【００４５】 コンピュータ・システム１００は、従来のマイクロプロセッサを含む中央演算
処理装置（ＣＰＵ）１０５、一時的な情報格納用のランダム・アクセス・メモリ
（ＲＡＭ）１１０、永久的な情報格納用のリード・オンリー・メモリ（ＲＯＭ）
１１５を含む。メモリ・コントローラ１２０はシステムＲＡＭ１１０を制御する
ために提供される。バス・コントローラ１２５はバス１３０を制御するために提
供されており、割り込みコントローラ１３５は他のシステム・コンポーネントか
らの様々な割り込み信号を受信して処理するために使用される。

【００４６】 大容量格納はディスケット１４２、ＣＤ−ＲＯＭ１４７またはハードディスク
装置１５２によって提供できる。データやソフトウェアはリムーバブル・メディ
アたとえばディスケット１４２やＣＤ−ＲＯＭ１４７を経由してクライアント・
コンピュータ１００と交換できる。ディスケット１４２はディスケットドライブ
装置１４１に挿入することができ、ディスケットドライブ装置１４１はコントロ
ーラ１４０によってバス１３０へ接続されている。同様に、ＣＤ−ＲＯＭ１４７
はＣＤ−ＲＯＭドライブ装置１４６に挿入することができ、ＣＤ−ＲＯＭドライ
ブ装置１４６はコントローラ１４５によってバス１３０へ接続されている。最後
に、ハードディスク１５２は固定ディスクドライブ装置１５１の一部であり、こ
れはコントローラ１５０によってバス１３０へ接続されている。

【００４７】 クライアント・コンピュータ１００へのユーザ入力は多数のデバイスによって
提供され得る。たとえば、キーボード１５６とマウス１５７はキーボード及びマ
ウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トラ
ンスデューサ１９６はマイクロホン及びスピーカの両方として機能することがで
きるもので、オーディオ・コントローラ１９７を介してバス１３０へ接続されて
いる。他の入力デバイスたとえばペンおよび／またはタブレットや、音声入力用
マイクロホンなどを適当なコントローラとバス１３０経由でクライアント・コン
ピュータ１００へ接続することができるのは当業者には明らかであろう。ＤＭＡ
コントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリアクセスを
実行するために提供される。視覚表示はビデオコントローラ１６５によって生成
され、これがビデオ・ディスプレイ１７０を制御する。

【００４８】 コンピュータ・システム１００はまたクライアント・コンピュータ１００がバ
ス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・
アダプタ１９０も含む。ネットワーク１９５はローカル・エリア・ネットワーク
（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットであり、多数
のネットワーク・デバイスを相互接続する汎用通信回線を使用する。

【００４９】 コンピュータ・システム１００は一般にオペレーティング・システム・ソフト
ウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、
オペレーティング・システムはシステム資源の割り当てを制御しプロセスのスケ
ジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行す
る。

【００５０】 Ｃ．データ・モデルを制御する従来の方法 図２は「モデル・ビュー・コントローラ」として周知の技術を使ったデータ・
モデルを制御する従来のシステム２００を示す。システム２００において、デー
タ・モデル・モジュール２０２はたとえばデータベースなどのデータをデータ・
モデルにしたがって格納し維持する。コントローラ・モジュール２０４はローカ
ルに開始したイベント２０６（たとえばユーザ入力など）やまたは外部で開始し
たイベント２０８（たとえばリモートのコンピュータ・システムから受信したイ
ベント通知など）に応じて、「現在値をセットする」コマンドをデータ・モデル
・モジュール２０２に指示して格納しているデータへの変更を行なわせる。コン
トローラ・モジュール２０４はデータ変更を出力装置たとえばディスプレイ２０
６などに通知する。ディスプレイ２０６はデータ・モデル・モジュール２０２か
ら変更されたデータを取得してデータの表示を更新し、現在のデータがユーザか
ら観察できるようにする。前述の技術は厳密にイベント駆動型であり動作におい
てリニアである。典型的には、データへの変更をコントローラ・モジュール２０
４に指示させる内部または外部のイベントはコントローラ・モジュール２０４の
ＦＩＦＯ（先入れ先出し）型バッファに格納され、次いでイベント通知がコント
ローラモジュールに到達した順序で処理される。また典型的には、グローバルな
一貫性問題、即ちシステム２００内のモデルデータのコピーが他のリモートシス
テムにあるデータと一致していることを保証する対応がシステム２００には行な
われていない。

【００５１】 システム２００で例示したようなデータ・モデルを制御する従来のアプローチ
は、コンピュータ・システムがメインフレームとパーソナル・コンピュータとを
問わず相互に隔絶されて動作していた時代には適切だった。インターネットの発
達とともに、コンピュータ・ユーザはコラボレーションするときのもっと優れた
方法を要求しており、本発明では、データ・モデルに対してデータ変更エンジン
によって行なわれる変更にダイナミクス・マネージャが介在する「モデル介在型
制御」と呼べるようなものを提供する。

【００５２】 Ｄ．コンピュータ間動作のインターネット・パラダイム 図３はインターネット環境３００を示したもので、本発明が有利に使用できる
ものである。ユーザの観点からすると、従来のクライアントサーバ・ビュー３０
２において、個別のクライアント３０６、３０８はインターネット３０９上でサ
ーバ３１０と別々に通信する。各々のクライアント３０６、３０８はインターネ
ット３０９経由でサーバへ要求を発信し、各々について、サーバ上に格納された
ドキュメントをインターネット３０９上でクライアントへ提供することにより、
サーバ３１０がこの要求に呼応する。各々のサーバ３１０とクライアント３０６
、３０８は、図１に図示したようなパーソナル・コンピュータとして実現でき（
サーバの場合には幾つかのＵＩコンポーネントはオプションとなる）、適当なプ
ログラムたとえばクライアント・ブラウザ３１１および／または後述するような
その他の通信インタフェースの実行が可能である。インターネット使用のピア・
ツー・ピア・ビュー３１２においては、ユーザのコンピュータ・システムはピア
・ユニット３１４Ａ〜Ｄを構成し、インターネット経由の通信は一つのピア・ユ
ニットから別のピア・ユニットへ明らかに介在するものがなくても配向できる。
各々のピア・ユニット３１４Ａ〜Ｄは図１に図示したようなパーソナル・コンピ
ュータとして、またはその他の形態のネットワーク接続可能なデバイスとして実
現可能である。本発明はクライアント３０６、３０８、またはピア・ユニット３
１４Ａ〜Ｄのいずれかで有利なるように実現可能であるが、このような説明はシ
ステムのピア・ツー・ピア・ビューでの実装が中心となる。

【００５３】 さらに詳細には以下で説明するが、このようなピア・ツー・ピア通信は直接ま
たはリレー・デバイス３１６経由で行なうことができる。リレー・デバイス３１
６は「ストア・アンド・フォワード」型が望ましく、これはインターネットから
一時的に切断されているピア・ユニット３１４へ向けられたメッセージを格納し
、その後再接続した時にそのピア・ユニットへメッセージを転送することができ
るものである。

【００５４】 Ｅ．ＡＢＣシステムのアーキテクチャと動作 図４はピア・ユニット３１４Ａ〜Ｄの一つ、たとえばピア・ユニット３１４Ａ
において実現されるＡＢＣシステム４００を示す。ピア・ユニット３１４Ａ上の
ＡＢＣシステムはフレームワーク４０２、少なくとも一つのテレスペース４０４
、及びユーザ・インタフェース４０６を備える。フレームワーク４０２は多数の
テレスペース４０４にサービスするためのプラットフォームを提供するのが望ま
しい。フレームワーク４０２は、アクティビティが動作しフレームワーク・コン
ポーネントと通信するプログラマ・インタフェースを備えるモジュラー構造が望
ましい。

【００５５】 フレームワーク４０２はユーザ・インタフェース・マネージャ４０８、アイデ
ンティティ・マネージャ４１０、テレスペース・マネージャ４１２、アクティビ
ティ・マネージャ４１４、格納・マネージャ４１６、コントローラ・サービス・
マネージャ４１８、ダイナミクス・マネージャ４２０、通信マネージャ４２２を
含む。

【００５６】 ユーザ・インタフェース（ＵＩ）マネージャ４０８は多数のユーザ・インタフ
ェース・コントローラ（図示していない）の共有サービスの管理を担当する。Ｕ
Ｉマネージャ４０８はディスプレイ・ウインドウの窓ガラスの向こうにあるアク
ティビティのレイアウトを管理し、それ以外にユーザ・インタフェースとして期
待する「ルック・アンド・フィール」を提供する。ＵＩマネージャ４０８はアク
ティビティのナビゲーション（たとえばｇｏ（行く）、ｎｅｘｔ（次）、ｐｒｅ
ｖｉｏｕｓ（前））なども管理しナビゲーション履歴を保持する。

【００５７】 アイデンティティ・マネージャ４１０はあるテレスペース・メンバーのアイデ
ンティティの保存を担当する。前述したように、アイデンティティは名前であり
、また対応するＵＲＬであり、これにより各々のユーザが他のユーザによって認
識される。個々のユーザは１つまたは多数のアイデンティティを持つことがある
。アイデンティティ・マネージャ４１０はアイデンティティのレコードまたはテ
ーブルを望ましくはＸＭＬで保持する。アイデンティティ・マネージャ４１０は
またテレスペース・メンバーのＵＲＬとこれらに対応するデバイスのＵＲＬのレ
コードまたはテーブルを望ましくはＸＭＬで保存する。これ以外に、独立したメ
ンバー・マネージャを実装することができる。

【００５８】 テレスペース・マネージャ４１２はピア・ユニット３１４Ａで開くことができ
るテレスペース４０４の各々の管理を担当する。各々のテレスペース４０４は１
つまたはそれ以上のアクティビティのインスタンシエーション（ｉｎｓｔａｎｔ
ｉａｔｉｏｎ）である。各々のテレスペース４０４は対応するアクティビティ・
マネージャ４１４を有している。

【００５９】 アクティビティ・マネージャ４１４は（ａ）テレスペースへ新規アクティビテ
ィを追加する、（ｂ）テレスペースで既存のアクティビティを開く、（ｃ）アク
ティビティ・テンプレートの新しいバージョンからテレスペースのアクティビテ
ィを更新する。新規のアクティビティを追加するには、アクティビティ・マネー
ジャ４１４にアクティビティ・テンプレートのＵＲＬを提供してテンプレートを
開き、テンプレート情報（たとえばコンポーネントＵＲＬ）を抽出してテレスペ
ースへ伝搬する。テンプレートはあるテレスペースについての初期アクティビテ
ィ構成を定義する。ユーザは後で必要に応じてテレスペース４０４へさらにアク
ティビティを追加できる。追加した後、アクティビティはテレスペースの「一部
」となりテレスペースのメンバー全員から見えるようになる。テレスペースはア
クティビティ・マネージャを識別してアクティビティ・マネージャとデータを結
合するタグを備える。望ましくは、各々のドキュメントはローカル・レジストリ
をこれにリンクし、ＸＭＬタグの名前がレジストリに保存されるようにして、拡
張可能な、プラットホームに依存しない方法でドキュメントとこれに対応するテ
レスペースの間のマッピング（参照ポインタまたは連係）を表現するようにする
。各々のテレスペース・メンバーはその人のピア・ユニット３１４Ａ〜Ｄで利用
できるテレスペースのフレームワークとアクティビティ・テンプレートを有する
。

【００６０】 各々のアクティビティはツール４２４などのツールと、エンジン４２６などの
エンジンとを含む。ツール４２４はアクティビティにユーザ・インタフェース（
ＵＩ）機能を提供してメンバーとＵＩ４０６経由で対話する。ＵＩを介した対話
はたとえばキーボード１５６経由で（図１）またはマウス１５７経由で（図１）
開始されたＵＩイベントを含む。このようなＵＩイベントに呼応して、ツール４
２４はこれに対応するエンジン４２６に対してデータ・モデル変更を実行するよ
うに要求し、データ変更が起こった時に非同期的にＵＩを更新する非同期データ
変更通知をエンジン４２６に予約する。ツール４２４もコントローラ・サービス
・マネージャ４１８の指示の下に提供されるバックグラウンドサービスと対話す
るためのアプリケーション・プログラム・インタフェース（ＡＰＩ）を実装して
いる。エンジン４２６はテレスペース４０４をサポートするデータの維持と変更
、および／またはツールを介して得られたユーザとの対話からの結果の維持と変
更を担当する。後述するように、エンジン４２６は永続的モデルデータを変更す
ることと非同期データ変更通知をツール４２４に送出することをどちらもダイナ
ミクス・マネージャ４２０の指示制御下で行なうことができる。格納・マネージ
ャ４１６は格納されたデータへのアクセスを制御する。

【００６１】 アクティビティ・テンプレートの作成について、ソフトウェア・デベロッパは
フレームワーク内で使用するツールとエンジンを書いたり取り込んだりできる。
アクティビティ・テンプレートはアクティビティを含むツール・コンポーネント
及びエンジン・コンポーネントの永続的表現である。アクティビティ・テンプレ
ートはたとえばシュリンク・ラップしたソフトウェアとして配布したりたとえば
インターネット上で遠隔地のサーバからピア・ユニット３１４Ａにダウンロード
したりできる。アクティビティ・コンポーネントはウェブ・ドキュメントである
と考えることができ、ＵＲＬ経由で永続的に表現される。アクティビティ・テン
プレートそれ自体がＵＲＬを有するのが望ましく、これによりアクティビティ設
計の変更を追跡できるようになる。アクティビティ・テンプレートは単一のアク
ティビティ・テンプレートかまたはアクティビティ集合体テンプレートであり得
る。単一のアクティビティ・テンプレートはたとえば「チャット」などの一つの
アクティビティにだけに関連する。それに対してアクティビティ集合体テンプレ
ートは「チャット及びアウトライン」などといったアクティビティの集合体に関
連する。

【００６２】 使用するときは、ＡＢＣシステム４００はアイデンティティ・マネージャ４１
０経由でメンバーのアイデンティティを取得し、テレスペース・マネージャを開
き、テレスペース・マネージャに対してＵＲＬ経由でテレスペースを開くように
要求し、テレスペース・マネージャにアクティビティ・マネージャを要求し、さ
らに、通常はアクティビティのＵＲＬを使って、アクティビティ・マネージャが
アクティビティを開く。次に、ＡＢＣシステム４００はメンバーがテレスペース
を使用して特定のアクティビティによって提供される共有された特定のタスクを
実行することができるようにする。

【００６３】 図５はピア・ユニット３１４Ａ〜Ｄ上のＡＢＣシステム５００の代表的なマル
チ・テレスペースの使用方法を示す。ＡＢＣシステム５００が分散システムであ
ることは理解されるべきである。そこでここでは、ピア・ユニット３１４Ａだけ
のコンポーネントの説明が提供されているが、ピア・ユニット３１４Ｂ〜Ｄも同
様のコンポーネントを備えているので、これらについては別個の説明は不要であ
る。

【００６４】 ピア・ユニット３１４Ａについて図示したように、ＡＢＣシステム５００はピ
ア・ユニット３１４Ａがメンバーとして登録されている複数の代表的テレスペー
スを含み、これには自動車設計テレスペース５０２、チャット・テレスペース５
０４、チェスで遊ぶテレスペース５０６が含まれている。また図示してあるよう
に、ピア・ユニット３１４はテレスペース５０２、５０４、５０６の操作中に使
用される複数のコンポーネントを有している。ピア・ユニット３１４Ａは、メン
バーとして登録されているテレスペース５０２、５０４、５０６の各々をリスト
し記述してあるテレスペース・レコード５０８と、これらのテレスペースに参加
するテレスペース・メンバーのアイデンティティの各々をリストし記述してある
メンバー・レコード５１２とを保持するメモリ５１０を備えている。ＵＩ５１２
はユーザが開始したテレスペースへの変更及びメンバー・レコード５０８．５１
４への変更を受信できる。

【００６５】 テレスペース５０２、５０４、５０６の各々は図示したアクティビティ５２２
、５２４、５２６のうちの異なる一つを例示している（これとは別の場合には、
図示したアクティビティ５２２、５２４、５２６は単一のテレスペースに常駐す
ることもあるが、この場合単一のテレスペースの全てのメンバーがアクティビテ
ィの各々へのアクセスを行なうことになる）。各々のアクティビティ５２２、５
２４、５２６は各々のアクティビティに対応する特定のツール５３２、５３４、
５３６であって、各々のエンジン５４２、５４４、５４６の制御下にメモリ５１
０に格納された対応するデータ・モデル５５２、５５４、５５６に対して変更を
行うためのツール５３２、５３４、５３６を含み、これらのツールはそれぞれテ
レスペース５０２、５０４、５０６の中に永続的に保存される。たとえば、自動
車設計テレスペース５０２はＣＡＤ（ｃｏｍｐｕｔｅｒ−ａｉｄｅｄ ｄｅｓｉ
ｇｎ）ソフトウェアの形でツール５３２を含むことができるアクティビティ５２
２のインスタンスであり、チェスで遊ためのテレスペース５０６はソフトウェア
のチェスゲームの形を取るツール５３６を含むことができるアクティビティ５２
６のインスタンスである。

【００６６】 ユーザはユーザ・インタフェース５１４経由でテレスペース５０２、５０４、
５０６のアクティビティ５２２、５２４、５２６を遂行し、ユーザ・インタフェ
ース５１４はツール５３２、５３４、５３６とのインタフェースを持つことによ
りユーザの要求をツールに提供する。この要求に呼応して、エンジン５４２、５
４４、５４６がダイナミクス・マネージャ５０１の制御下でメモリ５１０内の対
応するデータ・モデル５５２、５５４、５５６の永続状態を変更し、現在の状態
を反映させる。たとえば、チェスで遊ぶためのテレスペース５０６でのデータの
永続的状態は、そのチェス盤と、盤上のチェスの駒の位置を含むことができる。
ユーザ要求はチェスの駒の動きを指定でき、これがデータの変更、即ちデルタを
構成する。また現在の状態はデルタの実行と駒の動きの完了を反映する。

【００６７】 図６はＡＢＣシステム５００の動作を示したもので、ピア・ユニット３１４Ａ
に配置され図５を参照して説明したコンポーネントに関するものである。エンジ
ン５４６はアクティビティ５２６の特定の集中タスクを推進する上で実装すると
きの候補となるアクションまたはオプション（たとえばチェスの駒の動き）をツ
ール５３６に提示する。ツール５３６はユーザ・インタフェース５１４経由でテ
レスペース５０６のメンバー（メンバー・レコード５１２に記録されているメン
バー）であるユーザと対話し、アクティビティのビュー（画像）を提示する（た
とえば、チェス盤面のビューと、おそらくは動きのリスト）。ユーザのジェスチ
ャーと呼ばれる（たとえばビショップをＸからＹへ動かすなど）ものであってユ
ーザ・インタフェース５１４から入力されたユーザ入力に呼応して、ツール５３
６はデルタを生成してシステム内に格納することにより、ユーザによる選択をメ
モリ内に記録する。デルタは要求された変更の単位であり、好ましくは、コンテ
ナ・オブジェクトの形である。コンテナ・オブジェクトはオブジェクト指向プロ
グラミング技術に馴染みのある者にはには周知である。ツール５３６はデルタに
おいて要求された変更の粒度（ｇｒａｎｕｌａｒｉｔｙ）の決定を担当する。デ
ルタ・コンテナ・オブジェクトはたとえば特定のチェスの駒の識別及びチェスの
駒の動きを構成する盤面のもとの位置と目標位置といった、ユーザの指定したデ
ータに加えて、変更を実行するための１つまたはそれ以上のコマンドを保持（内
蔵）することができる。生成時には、デルタはコマンドが何も入っていない空の
状態で、変更を行なうためにエンジン５４６によって適当なコマンドを埋め込ま
れるまで、それ自身が単に変更要求を構成しているだけである。デルタにおいて
エンジン特有の方法（これはツール５３６には分かっていなくとも良い）で変更
を行なうのに必要とされるコマンドを記録するのはエンジン５４６の責任である
。

【００６８】 さらに詳しく説明すると、線「ａ」で示したように、ツール５３６はダイナミ
クス・マネージャ５０１によるデルタ生成を要求することからデルタの作成を開
始する。ダイナミクス・マネージャ５０１はデルタを作成して線ａ’でツール５
３６へデルタを返し、フォールトリカバリ（障害復旧）が必要な場合に備えて作
成したデルタを記録する。

【００６９】 図６の線「ａ」で示してあるように、ツール５３６はツール・インタフェース
６０２を介してエンジン５４６のツール・エンド６０４へデルタの制御を渡し、
これによりエンジンを起動する（この説明は時としてデルタが渡されるまたはデ
ルタへの制御を一つのコンポーネントから別のコンポーネントへ渡すべきである
ことを表わす。望ましくは、デルタはメモリ内に割り当てられ、ポインタがＸＭ
Ｌエレメントとして渡されるオブジェクトである。）。エンジンのツール・イン
タフェース６０２はデルタにコーティングされている要求された変更を行なうこ
とができるコマンドを作成するための、または、言い換えればユーザの意図にし
たがうように逐次的な形で適当なコマンド、代表的にはエンジンに特有なコマン
ドでデルタを埋めるための、一組のアプリケーション・プログラム・インタフェ
ースを表出する。次にエンジン５４６はこの段階ではコマンドで埋められている
デルタの制御をツール５３６に戻す。

【００７０】 図６の線「ｂ」で示してあるように、ツール５３６は実行のために埋められた
デルタの制御をダイナミクス・マネージャ５０１へ渡す（即ち送出する）。ダイ
ナミクス・マネージャ５０１は他のピア・ユニット３１４Ｂ〜Ｄから線「ｂ」経
由で到着するデルタも受信することができる。ダイナミクス・マネージャ５０１
は、ピア・ユニット３１４Ｂ〜Ｄにおけるダイナミクス・マネージャとともに、
チェスゲームのテレスペースに参加している全てのメンバーについて、ＡＢＣシ
ステムの一方のエンドから別のエンドへ、データ・モデル５５６へ行なわれた変
更の一貫性を維持する責任がある。

【００７１】 ダイナミクス・マネージャ５０１はキュー構造６１２とダイナモ・プロセス６
１４とを含み、好ましくはコンピュータで実行可能なプログラムがダイナミクス
・マネージャの主論理を含む。ダイナミクス・マネージャ５０１とそのダイナモ
・プロセス６１４は通信マネージャ６２２と双方向通信する。ダイナミクス・マ
ネージャ５０１は受信したデルタを順序付ける目的でキューに入れてキュー構造
６１２にして、次にダイナモ・プロセス６１４がキューに入っているデルタを処
理するときにはキュー構造にサービスし、エンジン５４６に指示して適当な順序
でデルタを実行させる。さらに詳しく説明すると、ダイナミクス・マネージャ５
０１のダイナモ・プロセス６１４はインタフェース６１５を介して図６の線「ｃ
」を介してエンジン５４６のダイナミクス・マネージャ・エンド６１６へ向けて
、「デルタ・コマンド実行」メッセージの形で制御信号を送信する。デルタコマ
ンド実行メッセージはエンジン５４６に指示して、メモリ５１０に含まれており
、テレスペースに永続するデータ・モデル５５６への要求された変更を行なうこ
とで、ツール５３６から受信したデルタの実行を遂行する。

【００７２】 ダイナミクス・マネージャ５０１のダイナモ・プロセス６１４はまた、通信マ
ネージャ６２２経由で他のエンドポイントへ向けてローカルに開始した全デルタ
を配布し、通信マネージャ６２２はネットワークたとえば６２６上でピア・ユニ
ット３１４Ｂ〜Ｄへデルタを送信する。ピア・ユニット３１４Ｂ〜Ｄ各々では、
各々のダイナミクス・マネージャが受信したデルタを自分のローカル・キュー構
造へとキュー入れし、つぎに特定の順序で各々のエンジンへデルタを渡して実行
させる。

【００７３】 一つのダイナミクス・マネージャはアプリケーションによって一つのテレスペ
ースまたは多数のテレスペースをサポートできるので、多数のエンジンに指示し
て様々なテレスペース用のデルタを実行させる責任をとらせることもできる。多
数のテレスペースを持つシステムでは、図５に図示したように、デルタの情報を
調べることで、あるデルタをどのエンジンが実行すべきかを、ダイナミクス・マ
ネージャ５０１が決定する。デルタはエンジンのうちの特定の一つに同定されま
たデルタのペイロードの中に入っているエンジン識別子またはコードのタグを付
けられたコマンドを含む。キューに入れられたデルタがダイナミクス・マネージ
ャで処理される時に、ダイナミクス・マネージャはエンジン・コードと参照され
たデルタとを関連付け、適当なエンジンによるデルタの実行を指示する。

【００７４】 最後に、図６の線「ｄ」で示されているように、エンジン５４６は「データ変
更通知」メッセージを送出してツール５３６にデルタの実行を通知し、またデー
タ・モデル５５６におけるデータの新しい現在状態を通知する。デルタ変更通知
は値または参照を使って行うことができる。つまり、通知は新しいデータの値そ
れ自体を含むことができたり、またはメモリ内の新しいデータへのポインタを含
むことができる。この通知に呼応して、ツール５３６はたとえばチェス番のグラ
フィック上での動きを表示することにより、ユーザが利用可能な変更をユーザ・
インタフェース５１４に行なわせる。ユーザがディスプレイ１７０を観察してい
る場合（図１）、ユーザは、デルタの実行によって行なわれたチェス・ゲームへ
の変更を見ることができるが、それ以外の場合には、変更が行なわれた時点でユ
ーザが変更を「見る」ことなくメモリ５１０内のデータに変更が行なわれる。

【００７５】 望ましくは、ピア・ユニット３１４Ａのデータ・モデル５５６に格納されてい
るデータ・モデル５５６へ変更がエンジン５４６によって行なわれるのと実質的
に同時に、他のピア・ユニット３１４Ｂ〜Ｄもローカルに格納しているデータに
対して同様の変更を行なって一貫した方法でデルタの意図を反映する。ピア・ユ
ニット３１４Ａ〜Ｄのいずれかをリブートしなければならないような場合には、
デルタはリブート後に実行する用にメモりないに保存される。

【００７６】 ピア・ユニット３１４Ａ〜Ｄのどれかがネットワークたとえばインターネット
に接続されていないような状況が起こり得る。ピア・ユニット３１４Ａが切断さ
れているときには、通信マネージャ６２２はデバイス・プレゼンス・デテクタ４
３０を使用してピア・ユニット３１４Ａが接続されているかどうかを確認し、接
続されていない場合には、接続が復元される時まで送出されるデルタを送出デル
タストア６２８に格納しておき、接続された時点で、格納したデルタを送信する
。１つ以上の宛先ピア・ユニット３１４Ｂ〜Ｄがネットワークから切断されてい
る場合、ピア・ユニット３１４Ａの通信マネージャ６２２はプロセスを続けて他
のピア・ユニットが切断されているか否かにかかわらず送出デルタをリレー３１
６（図３）に送信する。リレー・デバイス３１６（図３）はこのような送出デル
タを受信し、必要に応じて送出デルタストア３１８（図３）に格納し、ピア・ユ
ニット３１４Ｂ〜Ｄが再接続された時点で宛先へ転送する。動作中には、通信マ
ネージャ６２２は全ての送出デルタをリレー３１６のＵＲＬへ送信することがで
き、リレーは搭載されている参照テーブル３２０を使用してデルタを中継する場
合に使用する宛先ピア・ユニット３１４Ｂ〜ＤのエンドポイントＵＲＬを確認す
る。リレー・サービスは実際にはインターネット・サービス・プロバイダ（ＩＳ
Ｐ）またはその他のインターネット組織によって提供され得るものである。

【００７７】 ツール５３６とエンジン５４６の間で、ユーザ・インタフェース・アクティビ
ティはツール５３６経由でのみ直接行なわれ、データ・モデルの変更はエンジン
５４６経由でのみ直接行なわれることが理解される。専門用語を使った表現では
、ツール５３６はＵＩを「保有」しており、エンジン５４６はデータ・モデルを
「保有」している。これは図２に図示したような現行の代表的アプリケーション
とは対照的である。たとえば、今日のスプレッドシート・プログラムでは、代表
的にはツールの機能とエンジンの機能を組み合わせており、本発明の前述の実施
態様のようにこれらを分離するのではない。ツールをエンジンから分離すること
により、従ってデータ・モデルからＵＩを分離することにより、ダイナミクス・
マネージャはたとえばデータの一貫性を維持する目的で、様々なピア・ユニット
から発せられたデルタの間に介在し仲介できる。ツールは様々な種類のエンジン
で、用途によっては柔軟性や移植性を向上するため、使用することができる。さ
らに、エンジンからツールを切り離すことでデルタの実行処理を非同期的に行な
えるようになる。これはダイナミクス・マネージャ５０１とエンジン５４６がテ
レスペースの中にいる全てのメンバーについてデータの一貫性を維持するような
方法で各々の責任を遂行するのに時間がかかるため有用である。また、他のピア
・ユニット３１４Ｂ〜Ｄから到着するデルタがローカルに開始されたデルタの実
行のタイミングに影響することがあることからも有用である。

【００７８】 図７は個別に実装されたアクティビティ（図示していない）で使用するフレー
ムワーク７００の実施態様を示す。フレームワークは、たとえばフレームワーク
上で動作可能なアプリケーション独自のスナップイン（プラグイン）であるコン
ピュータ・プログラム製品として、個々のアクティビティとは独立して、販売ま
たはライセンスすることができる。一般的に言うと、フレームワークはテレスペ
ースに関してコラボレーションをホスティングする。図示したフレームワーク７
００は１つ以上のダイナミクス・マネージャ７０２、１つの通信マネージャ７０
４、１つのデータ構造テンプレート７０６を含む。データ構造テンプレート７０
６はアクティビティ・デベロッパが使用するための原始型オブジェクト（オブジ
ェクト・プリミティブ）を、望ましくはＸＭＬフォーマットで含むことができる
。フレームワーク７００はたとえばコンピュータで読み取り可能な媒体７０６と
して実装可能で、媒体上にダイナミクス・マネージャ７０２と通信マネージャ７
０４を含むコンピュータで実行可能なコードと、データ構造テンプレート７００
のオブジェクト・プリミティブを含むコンピュータで読み取り可能なデータとが
格納される。

【００７９】 Ｆ．通信マネージャ、プレゼンス・サーバ、及びリレー 図８はネットワークたとえばインターネット８０３経由で多数のピア・ユニッ
ト８０２Ａ〜Ｄの間での通信ができるように装備したＡＢＣシステム８００を示
す。各々のピア・ユニット８０２Ａ〜Ｄはピア・ユニット３１４Ａに関連して前
述したコンポーネントを含むことができる（図８に図示したピア・ユニットの個
数は単に例示を目的として選択したものであり、特定の実装の構成により左右さ
れ、また時間とともに変化することがある）。各々のピア・ユニット８０２Ａ〜
Ｄはツール８０５Ａ〜Ｄによって開始されエンジン８０７Ａ〜Ｄにより実行され
るデルタ処理を調節するためのダイナミクス・マネージャ８０４Ａ〜Ｄを含み、
またピア・ユニット８０２Ａ〜Ｄの間の通信を調整するための通信マネージャ８
０６Ａ〜Ｄを含む。通信マネージャ８０６Ａ〜Ｄの役割はネットワークたとえば
インターネット８０３上でインターネット・プロトコルたとえばＴＣＰ／ＩＰな
どを使用してメッセージ（デルタを含む）を送受信することを含む。各々のピア
・ユニット８０２Ａ〜Ｄはとくに機能の上で通信マネージャ８３０Ａ〜Ｄの動作
サポートにおいてデータを格納するためのメモリ８０８Ａ〜Ｄを含む。

【００８０】 前述のように、通信マネージャ８０６Ａ〜Ｄ各々はそれ自体のピア・ユニット
と他のピア・ユニットとの間の通信を全て管理する責任がある。たとえば、通信
マネージャ８２２はピア・ユニット８０２Ａとピア・ユニット８０２Ｂ〜Ｄの間
の双方向通信を管理する。通信はピア・ユニット８０２Ａからピア・ユニット８
０２Ｂ〜Ｄの１つまたはそれ以上へ送出される、またはピア・ユニット８０２Ｂ
〜Ｄの一つからピア・ユニット８０２Ａへ送出されるどちらかのメッセージを含
むことができる。送信はユニキャスト（単一の宛先で、２点間通信）、マルチキ
ャスト（２点間通信で複数の宛先）、またはブロードキャスト（全ての）「聴い
ている」宛先への送信）を使用できる。宛先ピア・ユニット８０２Ｂ〜Ｄ（前者
の場合）またはピア・ユニット８０２Ａ（後者の場合）がネットワークたとえば
インターネットに接続されている限り（「オンライン」状態である）直接かつ仲
介なしに送信を行なうことができる。宛先がたとえば互換性のない通信プロトコ
ルを使用しているか、またはファイアウォールの中にある場合などは宛先には到
達することができない。前述のように、デバイス・プレゼンス・マネージャ８１
２を用いて想定した宛先がオンラインになっているか、または一時的に切断され
ている（「オフライン」状態である）どうかを確認することができる。宛先がオ
フラインになっている場合、通信はリレー８１４（前述の通り）を経由して行な
うことができ、リレーは宛先がオンラインに復帰した時に宛先へのメッセージを
転送する。通信マネージャ８０６Ａは、本明細書で使用している術語の通り、宛
先が接続可能または到達可能であるどうかを決定する役割がある。

【００８１】 つまり、ピア・ユニット８０２Ａがピア・ユニット８０２Ｃへのメッセージを
送出しようとして、ピア・ユニット８０２Ｃがオンラインであるとプレゼンス・
サーバ８１２から通信マネージャ８０６Ａに通知されている場合には、通信マネ
ージャ８０６Ａはそのピア・ユニットが接続可能であれば、ネットワークたとえ
ばインターネット８０３経由で直接ピア・ユニット８０２ＣのＵＲＬ宛てにメッ
セージを送出する。ピア・ユニット８０２Ｃでは通信マネージャ８０６Ｃがメッ
セージを受信して、メッセージをダイナミクス・マネージャ８０４Ｃへ渡す。

【００８２】 逆に、ピア・ユニット８０２Ａがピア・ユニット８０２Ｃへのメッセージを送
出しようとして、ピア・ユニット８０２Ｃがオフラインであるとプレゼンス・サ
ーバ８１２から通信マネージャ８０６Ａに通知されている場合には、通信マネー
ジャ８０６Ａはネットワークたとえばインターネット８０３経由でリレー８１４
のＵＲＬへメッセージを送出する。リレー８１４は高性能ファイルサーバとして
実装可能で、ピア・ユニット８０２Ｃがオンラインに復帰するまで中継メッセー
ジを保存しておき、復帰時にメッセージをピア・ユニット８０２ＣのＵＲＬへ転
送する。ピア・ユニット８０２Ｃでは前述のようにメッセージを受信して、通信
マネージャ８０６Ｃ経由でダイナミクス・マネージャ８０４Ｃへ渡す。宛先ピア
・ユニット８０２Ｃとリレー８１４の両方ともオフラインになっている場合には
、通信マネージャ８０６Ａは一定時間後に（タイムアウト機構により決定される
）メッセージの再送信を試み、また再送が保留中にピア・ユニット８０２Ａが再
立ち上げしたりまたは終了する場合にはデルタをたとえばメモリ８０８Ａに保持
しておく。

【００８３】 したがって、プレゼンス・サーバ８１２はＡＢＣシステム８００内ではピア・
ユニット８０２Ａ〜Ｄがオンラインかまたはオフラインかどうかをモニタする目
的で、また他のピア・ユニットの今ライン／オフライン状態をピア・ユニットの
各々に通知する目的で、使用することができる。この目的を満たすためには、デ
バイス・プレゼンス・サーバ８１２はたとえば図１のコンピュータ・システム１
００に示したように構成することができる。別の方法としては、デバイス・プレ
ゼンス・サーバはリレー・サーバと組み合わせることがでできる。この様な実装
では、デバイス・プレゼンス・プロトコル機能は独立した接続ディレクトリ８１
８ではなく参照テーブル３２０にあるデバイス状態情報を使ってリレー・サーバ
が実行する。

【００８４】 動作中、ピア・ユニット８０２Ａ〜Ｄの各々はデバイス・プレゼンス・サーバ
８１２に自分のオンライン／オフライン状態を通知する責任、即ちユニットがオ
ンライン中かまたはこれからオフラインになろうとしているところかを通知する
責任がある。別の方法としては、プレゼンス・サーバ８１２は時々ピア・ユニッ
ト８０２Ａ〜Ｄをポーリングしてこれらのオンライン／オフライン状態の情報を
取得することができる。この情報はデバイス・プレゼンス・サーバ８１２内で望
ましくは揮発性メモリ８１６内のプレゼンス・ディレクトリ８１８に保存する。
デバイス・プレゼンス・サーバ８１２は望ましくはたとえばＸＭＬを使ってデー
タツリーの形でプレゼンス・ディレクトリ８１８を保存する。プレゼンス・ディ
レクトリ８１８は初期状態では空で、ピア・ユニット８０２Ａ〜Ｄがオンライン
／オフライン状態の状態をデバイス・プレゼンス・サーバ８１２に提供するまで
、たとえば状態の通知を提供するまで、空のままである。そして、状態に関する
情報の受信時に、プレゼンス・ディレクトリ８１８は通知してきたピア・ユニッ
トのＵＲＬとオンライン／オフライン状態の情報を保存する。

【００８５】 デバイス・プレゼンス・サーバ８１２はピア・ユニット８０２Ａ〜Ｄに対して
デバイス接続状態予約サービスを提供することもできる。デバイス・プレゼンス
・サーバ８１２は各々のピア・ユニット８０２Ａ〜Ｄ宛てに他の各ピア・ユニッ
ト８０２Ａ〜Ｄのオンライン／オフライン状態を通知し接続状態の変化も通知す
る。デバイス・プレゼンス・サーバ８１２は（ａ）メッセージを送信「したい」
ピア・ユニット８０２Ａ〜Ｄからデバイス状態変化通知の要求があった時点で、
（ｂ）ネットワークたとえばインターネット８０３へピア・ユニットが接続する
時点で、（ｃ）時々、たとえばピア・ユニットのいずれかの状態に変化があった
時点で、または（ｄ）上記の組み合わせのいずれかの場合に予約しているピア・
ユニット８０２Ａ〜Ｄへ接続状態通知を送信できる。望ましくは、全ての通信は
インターネット・プロトコルに準拠して行なう。これらのプロトコルにはとくに
前述のものが含まれる。

【００８６】 同様に、各ピア・ユニット８０２Ａ〜Ｄはユーザ状態サービスに加入すること
ができ、たとえばユーザがメンバーとなっている各テレスペースについて、加入
することでそれ以降は各メンバーが現在「ログイン」しているかどうかなど、他
のテレスペース・メンバー各々現状に基づいて知ることができる。このサービス
を有効にするためには、デバイス・プレゼンス・サーバ８１２はメモリ８１６内
にテレスペース・メンバー・ディレクトリ８２２を保持しておき、プレゼンス・
サーバによってサポートされており、ユーザ状態情報を格納するためのフィール
ドを有する各テレスペースについてのメンバー・レコードを格納する。これ以外
に、この情報はデバイス・プレゼンス・サーバ８１２にではなく、各ピア・ユニ
ット８０２Ａ〜Ｄの内部に保持しておくこともでき、その場合には、この情報を
提供するために中央に配置されるメンバー・ディレクトリ８２２は必要がなくな
る。

【００８７】 例示すると、ピア・ユニット８０２Ａがピア・ユニット８０２Ｂへたとえばデ
ルタなどのメッセージを送信したい場合、ピア・ユニット８０２Ａはプレゼンス
・サーバ４３０にアクセスする。ピア・ユニット８０２Ａの通信マネージャ８０
６Ａはピア・ユニット８０２ＢのＵＲＬをすでに取得している。ピア・ユニット
８０２Ａはピア・ユニット８０２ＢのＵＲＬを用いて、デバイス・プレゼンス・
サーバ４３０からピア・ユニット８０２Ｂのインターネット・プロトコル（ＩＰ
）アドレスと接続状態を取得する。次に、通信マネージャ８０６Ａはメッセージ
をピア・ユニット８０２ＡのＩＰアドレス宛てに送信する。ダイナミクス・マネ
ージャ８０４Ａは宛先ピア・ユニット８０２Ｂがネットワークに接続しているか
どうかについての知識がなくとも通信マネージャ８０６Ａへメッセージを渡すこ
とができる。

【００８８】 図９は通信マネージャ８０６Ａ経由での通信に関係するピア・ユニット８０２
Ａの幾つかのコンポーネントの実装を示す。メモリ８３０Ａは通信マネージャ８
０６Ａの動作サポートに使うデータを格納する（他のピア・ユニット８０２Ｂ〜
Ｄも同様のメモリ構造を設けて各々の通信マネージャ８０６Ｂ〜Ｄ用のデータを
格納する）。図示したように、通信マネージャ８０６Ａはメモリ８３０Ａに送出
メッセージ・キュー構造９０４を保持しており、これにはデルタを含む全ての送
出メッセージが、望ましくはＸＭＬの形式で、格納される。送出メッセージ・キ
ュー構造９０４は他のピア・ユニット８０２Ｂ〜Ｄへ配送するため通信マネージ
ャ８０６Ａがダイナミクス・マネージャ８０４Ａから受信したメッセージを含む
（またはメモリ８３０Ａに格納される何らかの他のメッセージを参照する）作業
リスト・アレイとして実現可能である。このようにすると、送出メッセージ・キ
ュー構造９０４は図６の送出デルタ・ストア６２８を含むことができる。送出メ
ッセージ・キュー構造９０４以外に、メモリ８３０Ａは配送チケット・アレイ９
０６も含み、これは資源処理のためメッセージ・ペイロード（たとえば多数のＸ
ＭＬエレメントとしてフォーマットされ、各ＸＭＬエレメントがドキュメントの
一部分（以下、フラグメント）になっている）と配送エンドポイントとの関連を
提供する。メモリ８３０Ａはさらに接続ディレクトリ９０８も含み、これはたと
えばピア・ユニット８０２Ａ〜Ｄやリレー８１４などのネットワーク接続可能な
デバイスを含め、考えられる宛先エンドポイントのＵＲＬでインデックスされ、
各々の接続状態を格納する。

【００８９】 通信マネージャ８０６Ａはレシーバ９１２とトランスミッタ９１４を含み、こ
れらは受信スレッドと送信スレッドを各々処理する。レシーバ９１２は他のピア
・ユニット８０２Ｂ〜Ｄまたはリレー８１４からリンク９１８上に到着するデル
タを含む到着メッセージを受信し、本明細書の他の部分に記載しているように、
処理のためダイナミクス・マネージャ８０４Ａへリンク９１８上で転送する。

【００９０】 通信マネージャ８０６Ａのトランスミッタ９１４はダイナミクス・マネージャ
８０４Ａからリンク９２２上で送出メッセージを取得する。トランスミッタ９１
４は送出メッセージを検査し、デバイスＵＲＬを抽出する。次に、トランスミッ
タ９１４はランプ１００２Ａ（図１０）の「デバイスＵＲＬからＩＰアドレスへ
」のマップ１００１を使用して抽出したデバイスＵＲＬをＩＰアドレスにマッピ
ングする。最後に、トランスミッタ９１４は接続ディレクトリ９０８にアクセス
して宛先デバイスの接続性を確認する。前述したように、プレゼンス・サーバは
宛先デバイスのオンライン／オフライン状態を提供するが、通信マネージャは接
続性を追跡して最終的に判定する。各メッセージについて、プレゼンス及び接続
状態情報に応じて、トランスミッタ９１４がメッセージを指定された宛先へ転送
するためのパスを選択する。宛先デバイスがオンライン状態でプレゼンスおよび
接続性情報で示された通りに接続できる場合、トランスミッタ９１４はリンク９
２４上で宛先デバイスそれ自体のＵＲＬに向けてメッセージを発信する。宛先が
オンライン状態になくまたオンライン及び接続性情報で示された通りに到達でき
ない場合、トランスミッタ９１４はリンク９２４上でリレー８１４へメッセージ
を送り、リレーでメッセージ転送に使用する宛先デバイスのＵＲＬをメッセージ
に含める。本明細書の他の部分で説明したように、リレー８１４は宛先デバイス
がオンライン状態に復帰し接続可能になるまで保留メッセージを貯めておくため
のローカル・ストレージを備えている。その一方で、ピア・ユニット８０２Ａ自
体がオフラインの場合、トランスミッタ９１４はピア・ユニット８０２Ａがオン
ライン状態に復帰するまで送出メッセージを送出メッセージ・キュー９０４に蓄
えておき、復帰した時点で前述のようにメッセージを送信する。メッセージ・キ
ュー９０４はたとえばＸＭＬフォーマットで、ピア・ユニット８０２Ａのシャッ
トダウンまたはリブート後にも残る。

【００９１】 代表的実施態様において、通信マネージャ８０６Ａは、宛先ピア・ユニット８
０６Ｂ〜Ｄの通信マネージャが受信に成功したことを確認するまで、全てのデル
タを含め、送信されたメッセージ全部のコピーをメモリ８３０Ａに保持しておく
。所定の期限内に確認が受信されないと、通信マネージャ８０６Ａはメッセージ
を再送する。確認が戻ってこないと、通信マネージャ８０６Ａは所定の試行回数
まで再送を試みる。最大試行回数はＡＢＣシステムで、または特定のテレスペー
スでプリセットしておいたり、ユーザが調節できる。最大試行回数になっても確
認が得られない場合、その宛先ピア・ユニットへのメッセージを破棄するか、ま
たはその宛先ピア・ユニットへの通信を他のチャンネルたとえばリレー経由でた
めすことができる。これ以外に、最大試行回数のセットを行なわないこともある
。その場合にリレー・サーバが到達可能でなければ、ピア・デバイスまたはリレ
ー・サーバのいずれかが利用できるようになるまで、デバイスはメッセージを無
期限に保持する。

【００９２】 さらに、幾つかの実施態様では、送信元ピア・ユニットが各メッセージについ
て「生存期間」（ｔｉｍｅ−ｔｏ−ｌｉｖｅ）とよばれる期限を設定できる。送
信元ピア・ユニットの通信マネージャはたとえばメッセージのコピーと一緒にメ
モリ内に生存期間（ＴＴＬ）を格納する。ＴＴＬに応じて、送信元ピア・ユニッ
トはＴＴＬ期限までに送信に成功しなかった場合にはメッセージを破棄する。各
宛先ピア・ユニットが送信元ピア・ユニットへ確認メッセージを送り返すことで
メッセージ受信を確認するような代表的実施態様では、確認がＴＴＬ期限までに
受信されなかった場合には送信元ピア・ユニットがメッセージを破棄する。たと
えば、あるメッセージ「正午に昼食をご一緒しませんか？」（Ｃａｎ ｙｏｕ
ｍｅｅｔ ｍｅ ｆｏｒ ｌｕｎｃｈ ａｔ ｎｏｏｎ？）を送信する場合、そ
のメッセージはＴＴＬデータを持つことができ、宛先ピア・ユニットが正午まで
に受信される確認を送らない場合にはメッセージを送信側エンドポイントで破棄
する。この機能のさらに別の変化としては、デルタを含むメッセージの場合、デ
ルタがＴＴＬ期限までに宛先によって実行されなければ破棄するように設定でき
る。ＴＴＬ期限は、たとえばテレスペース内の全メッセージに対して、または特
定の種類の全メッセージに対して、または各メッセージについてたとえばメッセ
ージ内容や宛先エンドポイントに基づいて、様々な制御レベルでユーザが指定で
きる。

【００９３】 別の代表的実施態様では、通信マネージャ８０６Ａはあるメッセージについて
指定された宛先エンドポイントを別のアイデンティティに対応する１つまたはそ
れ以上の別のエンドポイントへマッピングして、自動的にこれらの別のエンドポ
イントへメッセージのコピーを転送する役割を果たすことができる。つまり、メ
ッセージが一つの宛先ＵＲＬを指定していたとしても、通信マネージャ８０６Ａ
は別のＵＲＬへメッセージを送信するようにプログラムできる。このためには、
通信マネージャ８０６Ａは、ピア・ユニット８０２Ａについて、たとえばＸＭＬ
フォーマットで、メモリ８０８Ａに格納されていてアイデンティティ・マネージ
ャ４０８（図４）により保持されるアイデンティティ・データ構造へアクセスす
る。次に、アイデンティティ・データ構造から抽出したアイデンティティ情報に
呼応して、通信マネージャ８０６Ａは本来は第１の宛先ピア・ユニットへ宛てら
れたメッセージを第１のピア・ユニットの代わりにまたは第１のピア・ユニット
を含めて１つまたはそれ以上の他のピア・ユニットへ転送する。たとえば、ある
ユーザがＪａｃｋという名前でテレスペース内の人へメッセージを送りたい場合
、ユーザはＪａｃｋのホーム・コンピュータの宛先エンドポイントを指定できる
。通信マネージャ８０６Ａは、たとえばアイデンティティ・マネージャ４０８経
由で、アイデンティティ・データ構造をチェックしてＪａｃｋが仕事用のエンド
ポイントも持っていると判定できる。次に、通信マネージャは自宅用コンピュー
タに送る代わりとしてまたは自宅用コンピュータに加えて、メッセージを仕事用
のコンピュータの方へ転送することができる。これは自宅用コンピュータがオフ
ラインになっているかまたは到達不可能であると通信マネージャ８０６Ａが判定
した場合にとくに有用である。さらに、通信マネージャ８０６Ａは、Ｊａｃｋの
自宅と仕事のエンドポイントの両方へメッセージを送信しようとする場合に冗長
性を認識することができるので、メッセージを一方または他方宛てにだけ送信し
て、冗長なあるいは不要なトラフィックを削減するように選択することができる
。このパラグラフで説明したようなアイデンティティによるルーティングに関し
ての通信マネージャ８０６Ａの動作は、たとえば各々のメッセージに関してユー
ザの制御下に置くことができ、また特定のテレスペースについてまたはメッセー
ジの種別についてまたは宛先エンドポイントに関係するアイデンティティについ
てプリセットできる。アイデンティティ・データ構造は、たとえば特定の人に到
達するためなどで、メッセージを送信すべきエンドポイントに対する命令を含む
ことができ、このような命令はテレスペースメンバーにより時々更新することが
できる。

【００９４】 通信マネージャ８０６Ａはピア・ユニット８０２Ａ内部にある資源アウェアネ
ス・マネージャ（ＲＡＭ）９３０とも通信するが、ＲＡＭはピア・ユニット８０
２Ａの外部にある資源プロバイダから取得した資源情報を管理する役割がある。
このような情報はピア・ユニット８０２Ａがメンバーになっているテレスペース
へ参加するのに有用または必要である。図１０は資源アウェアネス・マネージャ
・プロバイダまたはＲＡＭＰ１００２Ａ〜Ｃと呼ばれる多数の情報源から情報を
取得するＲＡＭ９３０の典型的動作を示した者で、ＲＡＭＰ１００２Ａとしてプ
レゼンス・サーバ８１２、ＲＡＭＰ１００２Ｂとしてファイルサーバなどを含む
。ＲＡＭ９３０は通信マネージャ８０６Ａからの要求に応じて情報を取得する適
当なＲＡＭＰを決定できる。要求に呼応して、ＲＡＭ９３０は要求された情報を
通信マネージャ８０６Ａへ非同期的に返す。たとえば、特定のＵＲＬに対応する
ＩＰアドレスについての通信マネージャ８０６Ａからの要求に呼応してＲＡＭＰ
１００２Ａ（プレゼンス・サーバ）は前述のデバイスＵＲＬからＩＰアドレスへ
のマッピングを実行して要求されたＩＰアドレスを返す。通信マネージャ８０６
Ａは返されたＩＰアドレスをたとえばメモリ８０８Ａにキャッシュする。

【００９５】 ＲＡＭＰ１００２Ａ〜Ｃの動作は以下のプロパティ・セットについての説明に
鑑みて最も良く説明できる。本明細書で使用しているように、資源は人、ドキュ
メント、またはデバイスを含むことができ、各々がＵＲＬによりユニークに識別
される。各々のプロパティについて、ＲＡＭは説明情報のプロパティ・セットを
格納する。プロパティ・セットはたとえば「ストリング名」即ち資源の種類（即
ち人、ドキュメントまたはデバイス）に特有の標準的リストの形を取ることがで
きる。ＲＡＭ９３０は各ＲＡＭＰ１００２Ａ〜Ｃに問い合わせを行ないサポート
されているし源プロパティ名のリストを取得することができる、つまりＲＡＭ動
作はプロパティ・セットの動的発見で特徴付けることができる。要求に呼応して
、ＲＡＭ９３０はたとえばＸＭＬフォーマットで、望ましくは階層的データ構造
の形で、情報を返すことができる。返された情報は別の種類の要求に対応するこ
とができ、次のような形を取ることができる：（ａ）「スタティック・タグ」（
ｓｔａｔｉｃ ｔａｇ）呼応、これはたとえばローカル・デバイスなど指定され
たＵＲＬに関してとくに要求された通りの情報を返すもの、または（ｂ）「クエ
リ」（ｑｕｅｒｙ）呼応、これはクエリに呼応して情報を返すものである。クエ
リ呼応は構造化されていたり、値に基づくものだったり、または「変更時に更新
」することができる。値に基づくクエリ呼応は、たとえば（ｉ）関連オペレータ
（何らかの期間に関するデータ、または特定の給料を得る従業員についてのデー
タなど）に呼応する情報、または位置的値に呼応する（即ち指定された順序で照
合される）、または（ｃ）「変更時に更新」される要求に応じる情報、これは要
求を出した実体からの最後のクエリ以降に変更された情報（たとえばファイルＸ
ＸＸがＹＹＹＹにリネームされたなど）を返す。例示すると、ＲＡＭ９３０は様
々なＲＡＭＰ１００２Ａ〜Ｃと通信して名前のついた資源たとえば特定の人につ
いてのメタデータを取得するように依頼されたり、または特定の人がオンライン
のディスカッションに参加できるかどうかを指定する情報を取得するように依頼
されることがある。

【００９６】 図８に戻って、ＡＢＣシステム８００はピア・ツー・ピア・モデル経由でピア
・ユニット８０２Ａ〜Ｄ間の通信を提供する。ＡＢＣシステム８００は宛先デバ
イスの接続状態と関係なくたとえばリレーなどのリレー８１４を提供することで
通信を可能にする。リレー８１４は論理的プロキシで、直接のピア・ツー・ピア
通信が不可能な場合に通信を仲介することができる。リレー８１４はまたコラボ
レーション環境内でのある種の通信形態を最適化する可能性のあるホストでもあ
る。リレー８１４は転送中のデルタを含めたメッセージを格納するためのメモリ
８３２、インターネット８０３からメッセージを受信するためのレシーバ８３４
、インターネット８０３上へメッセージを送信するためのトランスミッタ８３６
を含む。リレー８１４を使用する際には、ピア・ユニット８０２Ａ〜Ｄは「コラ
ボレーション・クライアント」として参照される。

【００９７】 図１１は以下のような追加コンポーネントを含むリレー８１４の実装を示す。 ・切断されている宛先クライアントへのデルタ・リレー・サービスを制御する
デルタ・リレー・モジュール１１０２。

【００９８】 ・「ファンアウト」（ｆａｎ−ｏｕｔ）と呼ばれるマルチキャスト通信または
ブロードキャスト通信を提供するファンアウト・モジュール１１０４、このモジ
ュールは同時に１つ以上の宛先デバイスへメッセージを送信できる。送信側ピア
・ユニット８０２Ａ〜Ｄが比較的低速の通信リンク９２４（図９）で宛先ピア・
ユニットへ接続されている場合に多数の２点間（ユニキャスト）送信では時間が
かかりすぎるのでとくに有用である。

【００９９】 ・認証されたピア・ユニット８０２Ａ〜Ｄにファイアウォール越しにメッセー
ジを送信許可する、たとえば機密プライベート・ネットワーク上のデバイスと公
衆ネットワーク経由で通信するための、プロキシを提供するファイアウォール・
モジュール１１０６。ファイアウォール・モジュール１１０６は一般にファイア
ウォールが送出側トラフィックを許可し到着トラフィックを許可しないことから
これを実現できる。

【０１００】 ・転送コスト情報を格納しピア・ユニット８０２Ａ〜Ｄからの転送コスト問い
合わせに応じて情報を提供する転送コスト・モジュール１１０８。この情報によ
り、コラボレーション・クライアントは、ピア・ユニット８０２Ａ〜Ｄが実行す
る最小コストの転送経路決定にしたがって、宛先ピア・ユニットへ直接メッセー
ジを送信するか、またはリレーを経由するかを選択できる。ピア・ユニット８０
２Ａ〜Ｄは情報のローカルコピーを、たとえば通信マネージャに保存しておくこ
とができる。

【０１０１】 ・地延珠尾方（以下、レイテンシ情報）及びスループット情報を保存しピア・
ユニット８０２Ａ〜Ｄからのレイテンシ問い合わせに呼応して情報を提供する転
送レイテンシ・モジュール１１１０。この情報により、コラボレーション・クラ
イアントはピア・ユニット８０２Ａ〜Ｄが実行するレイテンシ比較による経路決
定にしたがって、宛先ピア・ユニットへ直接メッセージを送信するか、またはリ
レーを経由するかを選択できる。送信側ピア・ユニット８０２Ａ〜Ｄが比較的低
速の通信リンク９２４（図９）で宛先ピア・ユニットへ接続されている場合にと
くにこれは有用である。ピア・ユニット８０２Ａ〜Ｄは情報のローカルコピーを
、たとえば通信マネージャに保存しておくことができる。

【０１０２】 ・たとえば認証の「ロックオン」（ｌｏｃｋ−ｏｎ）形式など簡略化と性能上
の理由で暗号化しないのが望ましいといった通信メッセージの認証を提供する認
証モジュール１１１２。

【０１０３】 図１２は送出メッセージ各々についての最適経路を決定する際にコラボレーシ
ョン・クライアントの通信マネージャ個々で実装することのできる転送方法１２
００を示す。転送方法１２００はステップ１２０２ではじまり、ここで宛先の接
続状態を調べる。通信マネージャは自分自身の接続性情報を保持でき、「プレゼ
ンス」情報（即ちオンライン／オフライン状態）をプレゼンス・サーバ８１２か
ら取得できる。宛先がネットワークたとえばインターネットから切断されている
場合、ステップ１２０２では送信にリレー８１４の経由が必要であるとの結論に
なる。ステップ１２０４ではメッセージを多数の宛先に送信するかどうかを調べ
、またたとえばリレー８１４のモジュール１１０４のファンアウト・サービスを
利用して送信を行なうのが最善かどうかも調べる。たとえば、通信マネージャは
宛先数があらかじめプログラムされた個数を越えるか、ユーザが指定した個数を
越えるか、または利用可能なバンド幅、ネットワークの混雑状況、及びメッセー
ジを送信しようとしているピア・ユニットの総数に基づいて動的に計算した数、
のどれかを越えるような場合、通信マネージャがリレー８１４経由でメッセージ
を転送することがある。ステップ１２０６では認証が必要な機密ネットワークへ
ファイアウォールを越えて送信する必要がある宛先かどうかを調べる。そのよう
な宛先の場合、リレーは認証されるが送信側ピア・ユニットが認証されない場合
には送信を行なうためにリレー８１４が選択される。宛先の条件と認証に関する
情報はリレー８１４のＲＡＭ９３０とファイアウォール・モジュール１１０６経
由で取得できる。ステップ１２０８では、ＲＡＭとリレー８１４の転送コスト・
モジュール１１０８から提供された転送コスト情報に基づいて、直接メッセージ
を送信する場合と、リレーを経由して送信する場合の相対的コストを判定する。
最小コストでの転送は、たとえば全ての通信について自動的に実行したり、また
はオペレータが選択するオプションとすることができる。最小コストの転送が有
効でステップ１２１０のテストでリレーが最小コストの選択肢を提供すると示さ
れている場合には、メッセージはステップ１２１０でリレー８１４から送出され
る。ステップ１２１２では転送スピードに関してＲＡＭ９３０とリレー８１４の
転送レイテンシ・モジュール１１１０から得られた情報に基づいて、同様に決定
を行なう。最小レイテンシの転送経路はたとえば全部の通信について自動的に実
行したり、またはオペレータが選択するオプションとすることができる。有効に
なっていて、ステップ１２１４のテストでリレーが最小レイテンシの選択肢を提
供すると示されている場合には、ステップ１２１４でメッセージがリレー８１４
によって送信される。リレー経由で送信しない場合、ステップ１２１８でメッセ
ージを宛先ピア・ユニットへ直接送信させる。ステップ１２０２〜１２１８の順
序を適宜変更できるおよび／または特定の実装の必要に適合するように上記で説
明したテストを改善できることは容易に理解されよう。

【０１０４】 アクティビティを構成する各ツール−エンジンの組み合わせが別々のダイナミ
クス・マネージャに対応できることと、多数のダイナミクス・マネージャを提供
してた数の同時に実行するアクティビティに対応できる点で、ＡＢＣシステムは
マルチタスク、マルチスレッドにすることもできる。テレスペースとダイナミク
ス・マネージャの間の一対一の関係ではデルタ処理で最小の遅延が導入されるが
、スレッドが窮乏する（ｓｔａｒｖａｔｉｏｎ）とエラー状態またはフォールト
状態を起してしまうことがある。他方、単一のダイナミクス・マネージャで多く
のテレスペースをサポートすると渋滞（ｃｏｎｇｅｓｔｉｏｎ）の問題が起こる
ことがある。各コンポーネントの最適な個数はハードウェアの用途、参加するピ
ア・ユニットの個数、トラフィック条件によって左右される。

【０１０５】 ＡＢＣシステムは複数のコンピュータ・システム（ＣＳ）を含み、その各々が
１つ以上のテレスペース（ＴＳ）を備え、各テレスペースが１つ以上のアクティ
ビティ・コンポーネントを具現化（ｉｎｓｔａｎｔｉａｔｉｏｎ）し、各アクテ
ィビティ・コンポーネントには１つ以上のツール（Ｔ）とエンジン（Ｅ）のペア
を有し、これら各々の動作はダイナミクス・マネージャ（ＤＭ）によって調整さ
れる。つまり、ＡＢＣシステムは１つ以上のダイナミクス・マネージャを備えた
多数のテレスペースを有することができる。したがって、ＡＢＣシステムはたと
えば次のように構成することができる： ＡＢＣシステム＝ ＣＳ_１ ＝ ＤＭ_１ ＋ Ａ_１、 ここでＡ_１ ＝ Ｔ_１ ＋ Ｅ_１ ＣＳ_２ ＝ ＤＭ_２ ＋ Ａ_２、 ここでＡ_２ ＝ Ｔ_２ ＋ Ｅ_２ ．．． ．．． ＣＳ_ｎ ＝ ＤＭ_ｎ ＋ Ａ_ｎ、 ここでＡ_ｎ ＝ Ｔ_ｎ ＋ Ｅ_ｎ

【０１０６】 ここで全部のアクティビティＡ、Ａ２、Ａｎは１つ以上のテレスペースに含ま
れるものとし、”ｎ”は正の整数である。つまり、例を挙げると、様々なテレス
ペースのインスタンシーエションの例は次のようになる： ＴＳ ⊂ Ａ_１、 または ＴＳ ⊂ Ａ_１ ＋ Ａ_２、 または ＴＳ ⊂ Ａ_１ ＋ Ａ_２ ＋ Ａ_ｍ あるいは ＴＳ_１ ⊂ Ａ_１ ＴＳ_２ ⊂ Ａ_２ ．．． ＴＳ_ｍ ⊂ Ａ_ｍ

【０１０７】 ここで記号「⊂」は「〜を含む集合」を表わし、「ｍ」は正の整数である。し
たがって、各テレスペースは１つまたはそれ以上のアクティビティを具現化し、
フレームワークは単一のテレスペースを有することができる。別の方法では、各
テレスペースは１つ以上のアクティビティを具現化し、フレームワークが多数の
テレスペースを有することができる。

【０１０８】 前述した実施態様のコンポーネントをソフトウェアで実装したものは、たとえ
ばコンピュータで読み取り可能な媒体、たとえば図１のディスケット１４２、Ｃ
Ｄ−ＲＯＭ１４７、ＲＯＭ１１５、またはハードディスク装置１５２などの有形
の媒体上に固定されるか、またはモデムまたはその他のインタフェース・デバイ
スたとえば媒体１９１上のネットワーク１９５に接続した通信アダプタ１９０を
介して送信することができるかのどちらかのコンピュータ用命令及びルーチンを
含む。媒体１９１は光通信回線または有線通信回線を含みこれに制限されない有
形の媒体であるか、またはマイクロ波、赤外線、またはその他の通信技術を含み
これに制限されない無線技術で実現される。これはまたインターネットであって
も良い。一連のコンピュータ用命令が本明細書で本発明に関連して前述し多機能
の全部または一部を実現する。多くのコンピュータ・アーキテクチャまたはオペ
レーティング・システムで使用される多数のプログラミング言語でこのようなコ
ンピュータ用命令を書くことができることは当業者には理解されよう。さらに、
このような命令は現在または将来の、半導体、磁気、光、またはその他のメモリ
・デバイスを含みこれに制限されない何らかのメモリ技術を用いて保存すること
ができ、あるいは現在または将来の、光、赤外線、マイクロ波、またはその他の
送信技術を含みこれに制限されない何らかの通信技術を用いて送信される。この
ようなコンピュータ・プログラム製品が、印刷したまたは電子化された説明を伴
ったリムーバブル媒体、たとえばシュリンクラップ・ソフトウェアとして配布さ
れる、コンピュータ・システムのたとえばシステムのＲＯＭまたは固定ディスク
上にプリロードされる、またはたとえばインターネットまたはＷＷＷ（Ｗｏｒｌ
ｄ Ｗｉｄｅ Ｗｅｂ）などのネットワーク上のサーバまたは電子掲示板システ
ムから配布されることを想定している。

【０１０９】 本発明の代表的実施態様を開示したが、本発明の利点の幾つかを実現する様々
な変化や変更を本発明の精神と範囲から逸脱することなく成し得ることは当業者
には明らかであろう。同じ機能を実行する他のコンポーネントが適宜置き換えら
れることができることは当業者には明らかであろう。さらに、本発明の方法は適
当なプロセッサ用命令を用いるソフトウェアで全て実装したもの、またはハード
ウェア論理とソフトウェア論理とを組み合わせて用いて同じ結果を実現しようと
するハイブリッド型で実装したもののどちらかで実現可能である。さらに、メモ
リの容量、特定の機能を実現するために使用される論理および／または命令の特
定の構成、ならびに本発明のコンセプトに対するその他の変更はすべて添付の請
求の範囲に含まれることを意図している。

【図面の簡単な説明】

【図１】 図１は、従来のコンピュータ・システムの代表的アーキテクチャのブロック図
である。

【図２】 図２は、図１のコンピュータ・システムで実行される従来のアプリケーション
のブロック図で、制御モジュールはディスプレイまたはその他のユーザ・インタ
フェースとインタフェースすること及びデータ・モデルにしたがってデータを維
持することを担当する。

【図３】 図３は、インターネット・ベースのシステムのブロック図で、ＷＷＷ用のクラ
イアントサーバ・システムと、本発明の実施態様によるパーソナル・ウェブのた
めのピア・ツー・ピアシステムとの両方を示す。

【図４】 図４は、本発明の実施態様による図１のコンピュータ・システムで実装される
ＡＢＣシステムの一部のブロック図である。

【図５】 図５は、図１のコンピュータ・システムで実装されるＡＢＣシステムの一部の
ブロック図で本発明の実施態様による代表的テレスペース・アプリケーションを
示す。

【図６】 図６は、図５のチェス・テレスペースで実装されるＡＢＣシステムの一部のブ
ロック図である。

【図７】 図７は、図４のＡＢＣシステムの一部を含むフレームワーク７００のブロック
図である。

【図８】 図８は、ピア・ユニット間の通信に関係する図４のＡＢＣシステムの一部の実
施態様のブロック図である。

【図９】 図９は、ピア・ユニット間の通信に関係する図４のＡＢＣシステムの一部の実
施態様のブロック図である。

【図１０】 図１０は図９の資源監視マネージャの使用を示すブロック図である。

【図１１】 図１１は、図８のリレーの実施態様のブロック図である。

【図１２】 図１２は、図４のＡＢＣシステムでの転送方法のブロック図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケネス・ジー・ムーア アメリカ合衆国 マサチューセッツ州 01886 ウェストフォード ジャック ラ ビット レーン ７ (72)発明者 ロバート・エイチ・マイヒル アメリカ合衆国 マサチューセッツ州 02465 ニュートン マーレイ ロード 41 (72)発明者 ブライン・エム・ランバート アメリカ合衆国 マサチューセッツ州 01845 ノース アンドヴァー チャドウ ィック ストリート 91 Ｆターム(参考） 5B045 BB28 BB42 BB48 GG01 5B085 BA06 BG02 BG07 CA04 CA06 【要約の続き】 する。通信マネージャはさらにネットワーク接続可能な リモート・デバイスがネットワークから切断されている ことを示すネットワーク接続状態情報に応じてローカル な場所で生成されたデルタをリレーのアドレスへ送信す る。ネットワーク接続可能なリモート・デバイスがネッ トワークに再接続されたことがリレーに通知されるまで リレーはデルタを保存しておき、リレーが再接続された ネットワーク接続可能なリモート・デバイスへデルタを 送信する。

Claims (37)

【特許請求の範囲】
1. 【請求項１】 少なくとも１台のネットワーク接続可能なリモート・デバイ
   スと協調動作しネットワーク上で通信するのに適したネットワーク接続可能なロ
   ーカル・デバイスであって、該ネットワーク接続可能なローカル・デバイスは、 Ａ）データ・モデルにしたがってデータのローカル・コピーを格納するメモリ
   と、 Ｂ）前記メモリと連動されたデータ変更エンジンであって、複数のデータ変更
   要求に呼応して、前記データ・もであるに従って前記メモリ内のデータの前記ロ
   ーカル・コピーのストレージを制御し、かつ、前記データの前記ローカル・コピ
   ーを変更することを特徴とし、前記データ変更要求にはローカルな場所で生成さ
   れたデータ変更要求とリモートな場所で生成されたデータ変更要求とを含婿とを
   特徴とするデータ変更エンジンと、 Ｃ）前記データ変更エンジン連動されたダイナミクス・マネージャであって、
   前記データ変更要求に呼応して、前記エンジンを制御し、かつ、と前記データ変
   更要求の実行を調整することを特徴とするダイナミクス・マネージャと、 Ｄ）通信マネージャであって、前記ダイナミクス・マネージャと連動されて前
   記ローカルな場所でに生成したデータ変更要求を前記少なくとも一つのネットワ
   ーク接続可能なリモート・デバイスへ送信するためと前記リモートな場所で生成
   されたデータ変更要求を受信するためであることを特徴とする通信マネージャと を含むことを特徴とするネットワーク接続可能なローカル・デバイス。
2. 【請求項２】 前記通信マネージャは前記ネットワーク接続可能なリモート
   ・デバイスのネットワーク接続状態に応じて前記ローカルな場所で生成されたデ
   ータ変更要求を前記少なくとも一つのネットワーク接続可能なリモート・デバイ
   スへ直接送信できることを特徴とする請求項１に記載のネットワーク接続可能な
   ローカル・デバイス。
3. 【請求項３】 前記通信マネージャはプレゼンス機構に呼応して前記少なく
   とも一つのネットワーク接続可能なリモート・デバイスが前記ネットワークに接
   続されている場合前記少なくとも一つのネットワーク接続可能なリモート・デバ
   イスへ前記ネットワーク上で前記ローカルな場所で生成されたデータ変更要求を
   送信し、前記少なくとも一つのネットワーク接続可能なリモート・デバイスが前
   記ネットワークから切断されている場合には前記ネットワークを介してリレーへ
   前記ローカルな場所で生成されたデータ変更要求を送信することを特徴とする請
   求項１に記載のネットワーク接続可能なローカル・デバイス。
4. 【請求項４】 前記通信マネージャは前記少なくとも一つのネットワーク接
   続可能なリモート・デバイスが前記ネットワークへ再接続された時点で前記少な
   くとも一つのネットワーク接続可能なリモート・デバイスへ前記ローカルな場所
   で生成されたデータ変更要求を転送するように前記リレーに指示することを特徴
   とする請求項３に記載のネットワーク接続可能なローカル・デバイス。
5. 【請求項５】 前記通信マネージャは前記ネットワーク接続可能なローカル
   ・デバイスが前記ネットワークに接続されているかどうか、したがってリモート
   な場所で生成されたデータ変更要求を受信できるかどうかを示す接続状態通知を
   前記ネットワークを介して前記プレゼンス機構へ送信することを特徴とする請求
   項３に記載のネットワーク接続可能なローカル・デバイス。
6. 【請求項６】 前記通信マネージャは前記ネットワーク接続可能なリモート
   ・デバイスからリモート な場所で生成されたデータ変更要求を受信して前記受信したデータ変更要求を前
   記ダイナミクス・マネージャへ転送することと、前記ダイナミクス・マネージャ
   は前記データ変更エンジンに指示して前記受信したデータ変更要求であってリモ
   ートな場所で生成されたデータ変更要求を実行させることを特徴とする請求項３
   に記載のネットワーク接続可能なローカル・デバイス。
7. 【請求項７】 プレゼンス機構及び前記リレーとの組み合わせにあることを
   特徴とする請求項３に記載のネットワーク接続可能なローカル・デバイス。
8. 【請求項８】 前記プレゼンス機構はネットワーク接続可能な前記ローカル
   ・デバイス及び前記リモート・デバイスのオンライン／オフライン状態の表示を
   保存することを特徴とする請求項７に記載の組み合わせ。
9. 【請求項９】 前記通信マネージャは前記少なくとも一つのネットワーク接
   続可能なリモート・デバイスが前記ネットワークから切断されている場合前記ネ
   ットワークを介して前記リレーへ前記ローカルな場所で生成されたデータ変更要
   求を送信し、前記リレーはリレー・メモリを有するストア・アンド・フォワード
   ・リレーを含み、前記リレーは前記リレー・メモリに前記ローカルな場所で生成
   されたデータ変更要求を格納し、前記少なくとも一つのネットワーク接続可能な
   リモート・デバイスが前記ネットワークに接続された時点で前記ローカルな場所
   で生成されたデータ変更要求を前記少なくとも一つのネットワーク接続可能なリ
   モート・デバイスへ転送することを特徴とする請求項８に記載の組み合わせ。
10. 【請求項１０】 前記少なくとも一つのネットワーク接続可能なリモート・
    デバイスはネットワーク接続可能な複数のリモート・デバイスを含み、前記リレ
    ーは前記通信マネージャに呼応してマルチキャストを使用し前記ネットワーク接
    続可能な複数のリモート・デバイスへ前記ローカルな場所で生成されたデータ変
    更要求を転送できることを特徴とする請求項７に記載の組み合わせ。
11. 【請求項１１】 前記通信マネージャは最小レイテンシ情報に呼応して、直
    接通信と間接通信の一方で前記ローカルな場所で生成されたデータ変更要求を送
    信でき、前記直接通信は１つ以上の前記ネットワーク接続可能なリモート・デバ
    イスへ直接前記ローカルデータ変更要求を送信することを含み、前記間接通信は
    前記リレー経由で１つ以上の前記ネットワーク接続可能なリモート・デバイスへ
    前記ローカルな場所で生成されたデータ変更要求を送信することを含むことを特
    徴とする請求項１０に記載の組み合わせ。
12. 【請求項１２】 前記通信マネージャは最小コスト情報に応じて、直接通信
    と間接通信の一方で前記ローカルな場所で生成されたデータ変更要求を送信でき
    、前記直接通信は１つ以上の前記ネットワーク接続可能なリモート・デバイスへ
    直接前記ローカルな場所で生成されたデータ変更要求を送信することを含み、前
    記間接通信は前記リレー経由で１つ以上の前記ネットワーク接続可能なリモート
    ・デバイスへ前記ローカルな場所で生成されたデータ変更要求を送信することを
    含むことを特徴とする請求項１０に記載の組み合わせ。
13. 【請求項１３】 分散型データ・モデルに従ってデータの複数コピーを保持
    するための分散型協調システムであって、該コピーはユーザのアクションに呼応
    して複数のコンピュータ・システムにより変更可能であることを特徴とする分散
    型協調システムであって、前記システムは、 Ａ）複数のコンピュータ・システムであって、前記コンピュータ・システムの
    各々は前記データのローカル・コピーを変更するための複数のデータ変更要求を
    ローカルな場所に生成することが可能であり、かつ、前記ローカルな場所で生成
    されたデータ変更要求ならびに前記コンピュータ・システムの他のシステムで生
    成されたデータ変更要求であってリモートな場所で生成されたデータ変更要求と
    を含むデータ変更要求を実行することが可能であることにより、前記データの前
    記ローカル・コピーに前記要求された変更を行うことが可能であり、前記コンピ
    ュータ・システムの各々はネットワークを介して他の前記コンピュータ・システ
    ムを含む宛先へローカルな場所で生成されたデータ変更要求を送信するためと前
    記ネットワークを介して前記他のコンピュータ・システムからリモートな場所で
    生成されたデータ変更要求を受信するための通信マネージャを含むことを特徴と
    する複数のコンピュータ・システムと、 Ｂ）前記通信マネージャの一つから送信されたデータ変更要求を受信し、かつ
    、前記宛先が前記ネットワークに接続された時点で前記受信したデータ変更要求
    を転送するためのリレーとを含む ことを特徴とする分散協調型システム。
14. 【請求項１４】 前記ネットワーク上で前記コンピュータ・システムに連動
    されて前記コンピュータ・システムの各々が前記ネットワークと接続されている
    かまたは切断されているかを示す情報を保存するためのプレゼンス・サーバをさ
    らに含むことを特徴とする請求項１３に記載のコンピュータ・システム。
15. 【請求項１５】 前記通信マネージャは前記ネットワークに接続された宛先
    へ直接データ変更要求を送信し、かつ、少なくとも一時的に前記ネットワークか
    ら切断されている宛先へは前記リレーを経由してデータ変更要求を送信すること
    を特徴とする請求項１４に記載のコンピュータ・システム。
16. 【請求項１６】 前記通信マネージャは宛先へデータ変更要求を直接送信す
    るか前記リレーを経由するかを、少なくとも部分的に最小コスト転送経路情報に
    基づいて決定できることを特徴とする請求項１３に記載のコンピュータ・システ
    ム。
17. 【請求項１７】 前記通信マネージャは、宛先へデータ変更要求を直接送信
    するか前記リレーを経由するかを、少なくとも部分的に最小レイテンシ転送経路
    情報に基づいて決定できることを特徴とする請求項１３に記載のコンピュータ・
    システム。
18. 【請求項１８】 各コンピュータ・システムはさらに Ａ）ローカルな場所で生成されたデータ変更要求を受信するツールと、 Ｂ）前記ツールとは別に前記データの前記複数コピーの前記ローカルコピーを
    制御するためと前記データ・モデルにしたがって前記ローカルコピーに変更を行
    なうためのエンジンと、 Ｃ）前記ローカルな場所で生成されたデータ変更要求及びリモートな場所で生
    成されたデータ変更要求に応じて前記変更を行なう際に前記エンジンを制御する
    ためのダイナミクス・マネージャと を含むことを特徴とする請求項１３に記載のコンピュータ・システム。
19. 【請求項１９】 ネットワークを介してネットワーク接続可能なデバイス間
    でデルタを含むデータ変更要求を通信できるようなものであって、アクティビテ
    ィに基づくコラボレーション・システムのための通信サービスを提供するフレー
    ムワーク装置であって、前記フレームワーク装置はネットワーク接続可能なロー
    カル・デバイスで動作しローカルな場所で生成したデルタをネットワークを介し
    て少なくとも一つのネットワーク接続可能なリモート・デバイスへ送信するため
    とリモートな場所で生成されたデルタを少なくとも一つのネットワーク接続可能
    なリモート・デバイスから受信するための通信マネージャを含み、前記通信マネ
    ージャは前記ネットワーク接続可能なリモート・デバイスが前記ネットワークに
    接続されていることを示すネットワーク接続状態情報に応じて前記ネットワーク
    接続可能なリモート・デバイスのアドレスへ直接前記ローカルな場所で生成され
    たデルタを送信し、前記ネットワーク接続可能なリモート・デバイスが前記ネッ
    トワークから切断されていることを示すネットワーク接続状態情報に応じてリレ
    ーのアドレスへ前記ローカルな場所で生成されたデルタを送信することを特徴と
    する装置。
20. 【請求項２０】 前記通信マネージャはプレゼンス機構から前記ネットワー
    クを介して前記ネットワーク接続状態情報を受信することを特徴とする請求項１
    ９に記載のフレームワーク装置。
21. 【請求項２１】 コンピュータで読み取り可能な媒体をさらに含み、前記通
    信マネージャは前記媒体上に格納されたコンピュータで読み取り可能なプログラ
    ム・コードを含むことを特徴とする請求項１９に記載のフレームワーク装置。
22. 【請求項２２】 前記リレーと組み合わされており、前記リレーは前記ネッ
    トワーク接続可能なリモート・デバイスが前記ネットワークに再接続されたこと
    を前記リレーに通知されるまでデルタを保存するためのメモリと、前記再接続さ
    れたネットワーク接続可能なリモート・デバイスへ前記デルタを送信するトラン
    スミッタを含むことを特徴とする請求項１９に記載のフレームワーク装置。
23. 【請求項２３】 前記通信マネージャは前記ネットワーク接続可能なローカ
    ル・デバイスが前記ネットワークに接続されているかどうか、したがってネット
    ワーク接続可能なリモート・デバイスからデルタを受信可能かどうかを示すネッ
    トワーク接続状態情報を前記プレゼンス・サーバへ送信するための手段を含むこ
    とを特徴とする請求項１９に記載のフレームワーク装置。
24. 【請求項２４】 前記ローカルな場所で生成されたデルタと前記リモートな
    場所で生成されたデルタに呼応して前記ネットワーク接続可能なローカル・デバ
    イスに含まれるデータ変更エンジンを制御し前記ローカルな場所で生成されたデ
    ルタとリモートな場所で生成されたデルタで指示された通りに格納データへ変更
    を行なうためのダイナミクス・マネージャをさらに含むことを特徴とする請求項
    １９に記載のフレームワーク装置。
25. 【請求項２５】 コンピュータで読み取り可能な媒体をさらに含み、前記通
    信マネージャと前記ダイナミクス・マネージャは各々前記媒体上に格納されたコ
    ンピュータで読み取り可能なプログラム・コードを含むことを特徴とする請求項
    １９に記載のフレームワーク装置。
26. 【請求項２６】 ネットワークを介してネットワーク接続可能なデバイス間
    でデルタを含むデータ変更要求を通信できるようなものであって、アクティビテ
    ィに基づくコラボレーション・システムのための通信サービスを提供する方法で
    あって、前記方法は、 Ａ）ネットワーク接続可能なローカル・デバイスからネットワークを介して少
    なくとも一つのネットワーク接続可能なリモート・デバイスへローカルな場所で
    生成されたデルタを送信し前記少なくとも一つのネットワーク接続可能なリモー
    ト・デバイスからリモートな場所で生成されたデルタを受信するステップと、 Ｂ）前記ネットワーク接続可能なリモート・デバイスが前記ネットワークに接
    続されていることを示すネットワーク接続状態情報に応じて、前記ネットワーク
    接続可能なリモート・デバイスのアドレスへ直接前記ローカルな場所で生成され
    たデルタを送信するステップと、 Ｃ）前記ネットワーク接続可能なリモート・デバイスが前記ネットワークから
    切断されていることを示すネットワーク接続状態情報に応じて、リレーのアドレ
    スへ前記ローカルな場所で生成されたデルタを送信するステップと、 を含むことを特徴とする方法。
27. 【請求項２７】 前記ネットワーク接続状態情報はオンライン／オフライン
    状態情報を含み、前記方法はさらにプレゼンス機構から前記ネットワークを介し
    て前記オンライン／オフライン状態情報を受信するステップを含むことを特徴と
    する請求項２６に記載の方法。
28. 【請求項２８】 プレゼンス機構が前記オンライン／オフライン状態情報を
    維持しまた前記ネットワークを介して配布し、前記プレゼンス機構は前記ネット
    ワーク接続可能なデバイスの各々についてのオンライン／オフライン状態情報を
    前記ネットワーク接続可能なデバイスの各々からのオンライン／オフライン通知
    によって取得するステップをさらに含むことを特徴とする請求項２７に記載の方
    法。
29. 【請求項２９】 前記リレーは前記ネットワーク接続可能なリモート・デバ
    イスが前記ネットワークに再接続されたことを前記リレーに通知されるまで前記
    デルタを保存しておき前記リレーが前記再接続されたネットワーク接続可能なリ
    モート・デバイスへ前記デルタを送信するステップをさらに含むことを特徴とす
    る請求項２７に記載の方法。
30. 【請求項３０】 前記ネットワーク接続可能なローカル・デバイスは前記ネ
    ットワーク接続可能なローカル・デバイスが前記ネットワークに接続されている
    かどうか、したがってネットワーク接続可能なリモート・デバイスからのデルタ
    受信が可能かどうかを示すオンライン／オフライン状態通知を前記プレゼンス・
    サーバへ送信するステップをさらに含むことを特徴とする請求項２６に記載の方
    法。
31. 【請求項３１】 前記ネットワーク接続可能なローカル・デバイスに含まれ
    る通信マネージャは前記ネットワーク状態情報に含まれ前記通信マネージャで保
    持される接続性情報から前記少なくとも一つのネットワーク接続可能なリモート
    ・デバイスの接続性を判定するステップをさらに含むことを特徴とする請求項２
    ６に記載の方法。
32. 【請求項３２】 プレゼンス機構で前記少なくとも一つのネットワーク接続
    可能なリモート・デバイスについてのオンライン／オフライン状態情報を保持し
    、前記オンライン／オフライン状態情報は前記ネットワーク接続状態情報に含ま
    れるステップをさらに含むことを特徴とする請求項３１に記載の方法。
33. 【請求項３３】 前記デルタを前記少なくとも一つのネットワーク接続可能
    なリモート・デバイスへ送信できるようになるまで前記ネットワーク接続可能な
    ローカル・デバイスに前記ローカルな場所で生成されたデルタを永続的に保存す
    るステップをさらに含むことを特徴とする請求項２６に記載の方法。
34. 【請求項３４】 前記送信ステップは複数のネットワーク接続可能なリモー
    ト・デバイスへ前記ローカルな場所で生成されたデルタを送信し、前記送信ステ
    ップは前記ローカルな場所で生成されたデルタを前記ネットワーク接続可能なリ
    モート・デバイスへマルチキャスト送信するステップを含むことを特徴とする請
    求項２６に記載の方法。
35. 【請求項３５】 前記少なくとも一つのネットワーク接続可能なリモート・
    デバイスから確認メッセージが受信されない場合には、最大試行回数までの間前
    記送信ステップを反復するステップをさらに含むことを特徴とする請求項２６に
    記載の方法。
36. 【請求項３６】 前記デルタの各々に生存期間を関連付けておき、関連する
    生存期間が経過したら前記デルタの各々を破棄するステップをさらに含むことを
    特徴とする請求項３５に記載の方法。
37. 【請求項３７】 前記送信ステップは前記ネットワーク接続可能なローカル
    ・デバイスに格納されたアイデンティティ情報に応じて前記少なくとも一つのネ
    ットワーク接続可能なリモート・デバイスへ前記メッセージを配送するステップ
    を含むことを特徴とする請求項２６に記載の方法。