JP2005196581A - 分散コラボレーション・システムでコンタクトを保存し管理するための方法及び装置 - Google Patents

Abstract

【課題】
分散コラボレーション・システムにおいて、コンタクト情報を保存し管理するための方法及び装置を提供する。
【解決手段】
分散コラボレーション・システムにおいて、各々のユーザはローカル・コンタクト・ストアに全てのコンタクト情報を格納する。例えば共有空間又はコンタクト・リスト等のコンタクト情報を保守するつまりコンタクト情報の「供給源」として機能する各サブシステムは例えばＵＲＬなどコンタクト・ストア内のコンタクトを同定する情報だけを格納する。コンタクトとの通信が障害によって失われないでコンタクト通信情報を受信することを保証するため、ローカル・コンタクト・ストアは双方向の購読を用いて更新される。更に詳しくは、あるコンタクトの情報をユーザのローカル・コンタクト・ストアへ追加した時、購読メッセージをそのコンタクトへ送信する。購読メッセージはユーザのコンタクト情報を含みそのコンタクトの購読リストへユーザを追加するように要求する。更新されたコンタクト情報は購読リストにある各々の人へ自動送信される。
【選択図】 図２

Description

本発明は分散型かつピア・ツー・ピア型コラボレーション・システムに関しまたこのようなシステムでコンタクト情報を保存し管理するための方法及び装置に関する。

コラボレーションは「コラボレータ」と呼ばれるメンバのグループにおいて各メンバがそのグループ内の他のコラボレータへ情報を自動送信したり情報を自動受信する能力に関係する。このようなコラボレーションを容易にするため、このような情報をパーソナル・コンピュータ・システム、通信機器、又はハンドヘルド機器及び無線機器を含むその他の通信装置との間で送信できるようにする各種システムが開発された。これらの装置は本明細書では集合的に「コンピュータ」と呼称することにする。

コンピュータによるコラボレーションは１台のコンピュータ又はサーバに接続された又はこれで操作しているユーザ間でローカルに行なうことができる。他に、コラボレーションはネットワーク上例えばインターネット上で行われる場合があり、この場合には、ユーザの各々はネットワークに接続されたコンピュータに配置されている。サーバもネットワークに接続される。ネットワーク化されたコンピュータ・コラボレーション・システムとして幾つかのコラボレーション・モデルが現在実装されつつある。これらのモデルの一つがクライアント・サーバ・モデルで、この場合にはコラボレータ全員が、ネットワーク経由で、中央サーバへ接続される。各コラボレータによって生成された情報はネットワーク上でサーバへ送信され、サーバは情報をネットワーク上で他の各コラボレータへブロードキャスト（ｂｒｏａｄｃａｓｔ）する。このシステムの一つのバージョンではコラボレーションで変更されつつあるデータはサーバ上に集中して格納される。次に、そのデータを変更しようとする各コラボレータはサーバへコマンドを送信してサーバのデータに変更を行わせる。サーバはデータのコピーを変更しコラボレータ全員へ変更したデータの「ビュー」（ｖｉｅｗ）を表す情報を送信することで、各コラボレータはデータをローカルに表示できる。

これ以外に、サーバを用いたシステムでは、サーバに保持されるデータ・コピーの他、更にローカルなデータのコピーを各コラボレーション・コンピュータで保持する。そのデータを変更したい各コラボレータはサーバへコマンドを送信してサーバのデータに変更を加える。サーバはデータのコピーを変更してから、コラボレータ全員へコマンドをブロードキャストする。各コラボレータはコマンドを使ってローカルなデータ・コピーを更新する。このローカル・データ・コピーがローカルに表示される。このモデルの例としては、ニューヨーク州アーモンクにあるアイビーエム社から販売されているロータス・ノーツ（登録商標）やロータス・セイムタイム（登録商標）、またワシントン州レッドモンドのマイクロソフト社から発売されているエクスチェンジが挙げられる。

別のコラボレーション・モデルは「ピア・ツー・ピア型モデル」で、この場合コラボレーションするコンピュータの各々の間にネットワーク上で直接接続が確立される。各コラボレータが生成した情報は他の各コラボレータへ直接送信される。このようなシステムでは、コラボレータがコラボレーション・システムによって生成維持されるプライベートな「仮想」共有空間内で通信する。コラボレータがコラボレーションに参加すると、共有空間の属性及び情報が「シリアル化」されてから新規コラボレータへネットワーク上で送信される。この情報が到着するとこの情報は「非シリアル化」され新規コラボレータのコンピュータ上に共有空間を作成するために使用される。

集中型のデータ・リポジトリ（ｄａｔａ ｒｅｐｏｓｉｔｏｒｙ）はピア・ツー・ピア型コラボレーション・システムでは必要とされないが、これは各コラボレータがコラボレーションにより変更されるデータのローカル・コピーを保有しているためである。データを変更するためには、コラボレータはデータ変更要求、即ち、「デルタ」を生成して他の各コラボレータへ転送する。到着したデータ変更要求は各コラボレータが自分のローカル・データ・コピーを変更するために使用する。この種のコラボレーション・システムの一例としては、０１９０１５ マサチューセッツ州 ビヴァリー、１００ カミングス・センター、スイート５３５Ｑにあるグルーヴ・ネットワークス社が開発販売しているグルーヴ・ワークスペース・コラボレーション・システム（Ｇｒｏｏｖｅ Ｗｏｒｋｓｐａｃｅ ｃｏｌｌａｂｏｒａｔｉｏｎ ｓｙｓｔｅｍ）があり、これについての詳細はｈｔｔｐ：／／ｗｗｗ．ｇｒｏｏｖｅ．ｎｅｔに記載されている。また米国特許第６，４４６，１１３Ｂ１号も参照。

ユーザの利便のため、前述のコラボレーション・システムの全てがコンタクト情報を保存する領域（ｐｒｏｖｉｓｉｏｎ）を有している。コンタクトとはユーザが共通の興味を共有する人びとでありそのため通信する必要があり、また仕事の同僚、関係者、友人、家族であり得る。保存されたコンタクトに関する情報（以下、コンタクト情報）は一般に様々な手段例えば電話や電子メール等でコンタクトと通信するのに必要な情報を含む。この保存されたコンタクト情報によってユーザは情報を記憶しなくても済んだり、他の情報源から情報を取り出さなくても済み、コラボレーション・システムのスピードと利便性を増大させることができる。

各コンタクトについて保存された情報は、例えば「ｖＣａｒｄ」又はその他の配布メカニズムによって他のコンタクトと共有するとコンタクトが決定した視覚的情報を一般に含む。しかし、コンタクト情報は例えばコンタクトに連絡するのに用いる装置に関する装置情報、リレー・サーバ情報、認証情報又は確認情報例えばデジタル署名、デジタル指紋、又はコンタクトとの機密通信を可能にするための暗号化キーなど非視覚的情報も含むことがある。

典型的には、コンタクト情報はコンタクト情報を検索して特定できるようなコンタクト・ディレクトリ又はコンタクト・リストに保持される。コンタクト・リストは多くのサブシステムによって参照され維持される。例えば、コンタクト・リストは、アイデンティティ、コンタクト・リスト・ツール、共有空間メンバ・サブシステム、メッセージ・ストア（ｍｅｓｓａｇｅ ｓｔｏｒｅ）によって参照できる。これらのリスト全部が別々の場所に格納され別々のサブシステムによって維持される。多くの異なったリストが存在しそのためコンタクト情報の多くの「供給源」が存在しているため、更新を配布したりコンタクト情報の全部を最新状態に維持するのは困難である。

例えば、共有空間でのコンタクト情報の変更は、共有空間の各メンバに送信される「コンタクト変更」デルタによって伝播する必要がある。ユーザが多くの共有空間に参加している場合、これらのデルタを全ての共有空間で処理するには時間の掛かる作業になることがある。更に、ユーザと同一のコンタクトが一緒に多くの共有空間に参加している場合、そのコンタクトはユーザのコンタクト情報の同一の更新を共有空間の各々から受信することになる。

同様に、インスタント・メッセンジャー（ｉｎｓｔａｎｔ ｍｅｓｓｅｎｇｅｒ）のコンタクト情報はユーザがそのコンタクトにインスタント・メッセージ（ｉｎｓｔａｎｔ ｍｅｓｓａｇｅ）を送信した場合にだけ更新される。そのため、あるユーザは任意のコンタクトについて最新バージョンの情報を保有するとは保証されない。ユーザの視覚的情報が陳腐化するだけでなくクライアント装置又はリレーの非視覚的リストも変化することがあり、コンタクト情報の更新なしには将来の通信が不可能になる。

本発明の原理によれば、各ユーザは、そのユーザについてのコンタクト情報全部に単一の場所を提供するために、ローカルなコンタクト・ストア（ｃｏｎｔａｃｔ ｓｔｏｒｅ）にコンタクト情報の全部を格納する。例えば共有空間又はコンタクト・リスト等のコンタクト情報を維持するすなわちコンタクト情報の「供給源」として機能する各サブシステムはコンタクト・ストア内にコンタクトを同定する情報例えばＵＲＬだけを保存する。そのため、コンタクト情報を最新に保つためには、コンタクト・ストア内の情報を更新するだけで良い。

コンタクトとの通信がコンタクト通信情報を受信できなかったことによって失われないように保証するため、ローカルのコンタクト・ストアはアイデンティティ・メッセージを使用する双方向の購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）を用いて更新する。更に詳しくは、あるコンタクトについての情報をあるユーザのローカルなコンタクト・ストアに追加する場合、購読要求メッセージをそのコンタクトに送信する。購読要求メッセージはユーザのコンタクト情報と、そのユーザをそのコンタクトについての購読リストに追加する要求とを含む。後で、コンタクトが彼又は彼女のコンタクト情報を更新する場合、更新情報は購読リストにある各人へ自動的に送信される。ユーザがこのような将来の更新を受け取るためには、コンタクトはそのユーザについての最新のコンタクト情報を維持する必要がある。つまり、購読は、ユーザがそのコンタクトをユーザ自身の購読リストに追加してコンタクトが自動的にユーザの全ての更新を受信することを必要とする「双方向」でなければならない。

一つの実施態様において、コンタクトはあるユーザを彼又は彼女の購読リストへ追加する要求を拒否することがある。この場合、ユーザはそのコンタクトをユーザ自身の購読リストへ追加しない。

別の実施態様において、購読要求メッセージの受取人が要求元のコンタクト情報が受取人のコンタクト・ストア内に存在することを必要とするような何らかの供給源（ｓｏｕｒｃｅ）を持っていない場合でも、要求内のコンタクト情報が「供給源のない」コンタクトとしてコンタクト・ストアに追加されるがこれは単に双方向の購読を実現するためだけに追加される。

更に別の実施態様では、コンタクトについての情報供給源のリストがコンタクト・ストア内に維持される。新規供給源がコンタクト情報をコンタクト・ストアへ追加することを要求する（例えば、ユーザがメンバとしてそのコンタクトを有する共有空間に加入する）場合、コンタクト情報がすでにコンタクト・ストア内に存在すれば、その情報はコンタクト・ストアへ追加されない。その代わり、（新規供給源からの情報がコンタクト・ストア内の情報より新しいものである場合）コンタクト・ストア内の情報が更新されコンタクト供給源がリストに追加される。同様に、コンタクト供給源が消去される場合（例えばユーザがメンバとしてそのコンタクトを有する共有空間を離脱する場合）コンタクト供給源はリストから削除されるがコンタクト情報はコンタクト・ストアから削除されない。リストが空の場合、そのコンタクトは供給源のないコンタクトになる。

更に別の実施態様では、アクティブでない供給源なしのコンタクトについての情報がコンタクト・ストア内に蓄積するのを防止するため、各々の供給源なしのコンタクトと定期的に接触を取り、所定の期限内に応答がない場合にはそれらのコンタクト情報がコンタクト・ストアから削除される。

別の実施態様では、購読要求はコンタクトの名前だけを含み完全な「ｖＣａｒｄ」情報を含まないことがある。この場合、「名前だけ」と言うフラグをｖＣａｒｄ情報にセットしてコンタクト情報更新中にその購読者には選択された情報だけが送信されるようにする。

図１Ａは、例えば前述のグルーヴ・コラボレーション・システムなどのコラボレーション・システム１００の略ブロック図である。図１Ａは３台のコラボレーション装置１０２、１０４、１０６を示しているが、これらはコンピュータ、ＰＤＡ、ラップトップコンピュータ、セットトップ・ボックス、ウェブ閲覧可能な携帯電話又はその他の通信装置であり得る。３台のコラボレーション装置だけを図示したが追加の装置も存在する。グルーヴ・ソフトウェアが当該装置にロードされた場合、それぞれ装置１０２、１０４、１０６にデータベース１０８、１１０、１１２等のデータベースを作成する。これらのデータベース各々はコラボレータによって処理されるデータのローカル・コピーを保持する。後述するように、データベース１０８、１１０、１１２はコラボレーション装置１０２、１０４、１０６の各々の動作に関する情報も保持する。

コラボレーション・ソフトウェアは装置１０２、１０４、１０６に各々トランシーバ１１４、１１６、１１８等のトランシーバも作成する。各トランシーバはデルタと呼ばれるデータ変更要求を作成し矢印１２２、１２４、１２６によって模式的に示してあるようにこれをコラボレータ間で送信する責任がある。典型的には、これらのデータ変更要求は図１Ａに図示したようにインターネット１２０上で送信されるが、例えばＬＡＮネットワーク等の別のネットワーク上で送信することもできる。データ変更要求はシステムにコラボレータを追加・除去したり、またデータ・コピーの同期をとるために各々のコラボレーション装置でローカル・データ・コピーを更新するなどの多数の目的で使用される。

前述のコラボレーション・ソフトウェアを使用するため、ユーザは１つ又はそれ以上のアカウントを設定する。一般に、アカウントは他のシステムで共通に見られるユーザ情報ファイル例えばアイデンティティ・ファイル等に相当する。各アカウントはユーザについての情報例えば電子メールアドレスやその他のユーザとコンタクトを取る方法を含む。アカウント情報は暗号化、署名され例えばデータベース１０８、１１０、１１２等、パスワードで保護されコラボレーション・システムによって維持されるデータベースに格納される。このようなデータベース１２８が図１Ｂに更に詳細に図示してある。

更に詳しくは、システム・データベース１２８はアカウント・データベース１３０を含み、これにはアカウントに関するユーザのプライベートなデータが格納されている。例えば、あるユーザは多数のアイデンティティ、例えばオフィスで使用する職業上のアイデンティティと、画像や休暇の計画を共有するような目的で家族や友人と使用するパーソナル・アイデンティティ等を持つことがある。アカウント・データはこれらのアイデンティティのリスト１３４と各アイデンティティについてのデータ、アカウントに関連付けられた共有空間のリストを含む。アカウント・データベースは、ユーザがメンバになっている各共有空間に関連している別々のデータ・ストアを含み、そのうちのデータ・ストア１４８、１５０、１５２が図示してある。データ・ストア１４８、１５０、１５２は共有空間に関連したローカルなデータ・コピーを含みその共有空間に関連するその他の情報を含むことがある。アカウント・データベース１３０は更にアカウント内の各アイデンティティについてのコンタクト情報と他のコンタクトについてのコンタクト情報を格納するコンタクト・ストア１４０を含む。最後に、アカウント・データベースは他の情報、例えばインスタント・メッセージや招待を格納するメッセージ・ストア１５４等も含む。

各アイデンティティのデータは公共的に利用されることのないプライベート部分１５６と公共的に利用することのできる公共部分１５８であるコンタクト情報とを含む。プライベート部分１５６はそのアイデンティティをユニークに同定するＵＲＬ等とそのアイデンティティがメッセージを暗号化し署名するのに使用する公開鍵／秘密鍵ペアの暗号化・署名秘密鍵等とを含む。公共コンタクト情報１５８はコンタクトをユニークに同定するコンタクトＵＲＬを含み一般にこれはそのアイデンティティのアイデンティティＵＲＬと同一である。コンタクト情報はまたそのコンタクトのシーケンス番号も含む。シーケンス番号はコンタクトが作成された時点でゼロにセットされる整数である。コンタクトのシーケンス番号はそのコンタクト情報に新規装置が追加される時には所定の大きな数（例えば１，０００）だけ増加（以下、インクリメント）される。コンタクトのシーケンス番号（以下、コンタクト・シーケンス番号）はコンタクト情報が何らかの別の理由で変更される（例えばコンタクトのｖＣａｒｄ情報が更新された）時には所定の小さい数（例えば１）だけインクリメントされる。全てのコンタクト情報はアイデンティティの秘密鍵で署名されるので、コンタクト情報を「所有している」アイデンティティだけがその情報を更新することができる点に注意する。更に、コンタクト情報はアカウントの装置の一つだけでしか更新することができない。

コンタクト情報は更にコンタクトのｖＣａｒｄ情報（名前、電話番号、ファクシミリ番号、電子メールアドレス等を含む個人用及び仕事用のデータ）を含む。ｖＣａｒｄ情報はコンタクトの名前だけしか含まないｖＣａｒｄに対して「名前だけ」と言うビットも備えている。コンタクト情報は更にそのコンタクト情報を「所有している」アイデンティティが存在する装置のリストと、一般にサーバであるリレー装置のリストと、機密データも含む。機密データは前述の公開鍵・秘密鍵ペアの公開鍵、鍵アルゴリズム、及び自己署名情報を含むことができる。

本発明の原理によれば、アカウントに関連するアイデンティティについてのコンタクト情報を含め全てのコンタクト情報は図２に更に詳細に図示してあるコンタクト・ストアに格納される。

更に詳しくは、コンタクト・ストア２００はコンタクト・ストア・エントリのセットを有し、そのうちのエントリ１（２０２）とエントリＮ（２０４）が図示してある。コンタクト・ストアは１つ又はそれ以上のエントリを含むことができることが当業者には理解されよう。各コンタクト・ストア・エントリ、例えばエントリ２０２はコンタクト情報等を含み、このコンタクト情報はコンタクトＵＲＬ２０６、コンタクト・シーケンス番号２０８、コンタクトのｖＣａｒｄ情報２１０、そのコンタクト情報を「所有している」アイデンティティが存在する装置のリスト２１２、リレー装置のリスト２１４、及び公開機密データ２１６を含む。コンタクト・ストア・エントリはまた、そのエントリのコンタクト情報の「所有者」を同定するＵＲＬのリストである供給源のリスト２２０を含む。そのコンタクト情報の新しい供給源が追加される時には供給源が供給源リスト２２０に追加され、そのコンタクト情報の供給源が削除される時にはリスト２２０から削除される。コンタクト・ストア・エントリの削除フラグ２２１によって後述するように削除のためにコンタクト情報をマークすることができる。

本発明の原理によれば、そのアカウントのアイデンティティに対応するコンタクト・ストア・エントリ（例えば、コンタクト・ストア・エントリ２０２）は以下で更に詳細に説明する購読リスト２１８も含む。購読リスト２１８は購読しているコンタクトを同定するコンタクトＵＲＬとコンタクト・ストア・エントリにあるコンタクト情報を購読したコンタクトの各装置についての情報を含む。後述するように、リスト２１８はそのエントリのコンタクト情報が変更された時にリストにあるコンタクトの各装置へコンタクトの更新情報を送信するのに使用される。リスト上の装置はコンタクト情報を購読したコンタクトの全ての装置（リレー装置を除く）を含む。購読リスト２１８はコンタクト・ストア・エントリにあるコンタクト情報を購読した各装置について、各購読装置のエントリを含む購読装置のリストを含み、そのうちエントリ２２２と２２４が図示してある。各購読装置のエントリはその装置をユニークに同定する装置ＵＲＬ２２６、装置状態フィールド２２８、この装置がアイデンティティに関連したコンタクト情報のうち名前だけのバージョンを受信すべきかどうかを示す名前だけフラグ２３０、ピンカウント・フィールド２３２を含む。これらのフィールドについては後述する。

購読装置エントリの装置状態フィールド２２８は購読装置が置かれる６つの状態のうちの一つを識別する装置状態番号を保持する。６種類の装置状態とその定義は次の通りである。

状態：定義
１：現在のアカウントの１つ又はそれ以上のアイデンティティがそのコンタクトについてのコンタクト情報の供給源を持っており、そのコンタクトは現在のアカウントの１つ又はそれ以上のアイデンティティについてのコンタクト情報の供給源を持っている。
２：現在のアカウントの１つ又はそれ以上のアイデンティティがそのコンタクトについてのコンタクト情報の供給源を持っているが、そのコンタクトは現在のアカウントのどのアイデンティティについてもコンタクト情報の供給源を持っていない。
３：現在のアカウントのどのアイデンティティもそのコンタクトについてのコンタクト情報の供給源を持っていないが、そのコンタクトは現在のアカウントの１つ又はそれ以上のアイデンティティについてのコンタクト情報の供給源を持っている。
４：現在のアカウントのどのアイデンティティもそのコンタクトについてのコンタクト情報の供給源を持っておらず、そのコンタクトは現在のアカウントのどのアイデンティティについてもコンタクト情報の供給源を持っていない。
５：現在のアカウントの１つ又はそれ以上のアイデンティティがそのコンタクトについてのコンタクト情報の供給源を持っているが、そのコンタクトはコンタクト情報に対する購読要求を拒否した。
６：現在のアカウントのどのアイデンティティもそのコンタクトについてのコンタクト情報の供給源を持っておらず、そのコンタクトはコンタクト情報に対する購読要求を拒否した。

６種類のコンタクト装置状態３００〜３１０を図３に示す。図３はユーザによって受信されたコンタクト伝播（ｃｏｎｔａｃｔ ｄｉｓｓｅｍｉｎａｔｉｏｎ）メッセージによって発生した状態遷移も図示している。状態遷移とコンタクト伝播メッセージについては以下で詳細に説明する。

好適実施態様において、アカウントとコンタクト・ストアはデータベース２００等の暗号化ＸＭＬオブジェクト・ストアに格納されるＸＭＬドキュメントとして実装される。これらＸＭＬドキュメントの例示的な形式を以下に示す。

account
{identities}
identity_1
private signing key (for Identity 1)
private encryption key (for Identity 1)
identity_2
...
{spaces}
{contacts}
entry_1
contact information
URL
sequence number
vCard information
devices
relay servers
public key algorithms
public signing key
public encryption key
status word
subscriptions
subscription 1 contactURL
devices
device1 DeviceURL State NameOnly PingCount
device2 DeviceURL State NameOnly PingCount
...
subscription2 contactURL
...
sources
source_1 URL
source_2 URL
deleted flag
entry_2
...

コンタクト・ストア２００はアカウントに関連したコンタクト全部について集中型（アカウントごと）のストレージ（ｓｔｏｒａｇｅ）を提供しているので、パーソナル・コンタクト・リスト、メッセージ・ストア等の様々な場所でコンタクトのコピーが消費する空間の量を有意に減少させる。更に、コンタクト・ストア２００はいかなるコンタクト情報をも更新する単一の点を提供する。更にコンタクト・ストア２００によりコンタクト・ストアのクライアントはコンタクト・ストア内のいかなるコンタクトにも任意のデータを関連付けることができる。そのデータへの変更はオプションでアカウント装置の全部へ配布できる。この任意のデータを用いてコンタクトにコメントを追加したり、コンタクトになりすますこと（ｓｐｏｏｆｉｎｇ）を防止することができる。

コンタクト・ストア２００はエンジンではないが、アカウントに関連付けられた装置の全部へコンタクトに関連付けられた何らかのデータへの変更を配布するために、別のエンジン例えばアカウント・エンジン又は共有空間メンバ・エンジン等によって維持することができるローカル・ストレージ（ｌｏｃａｌ ｓｔｏｒａｇｅ）である。この配布はアカウント・ストアに格納されコンタクト・ストア内のコンタクトに関連したプロパティ・リストを取得することにより行われる。このプロパティ・リストはそのコンタクトについてのプロパティ・リスト・プロバイダにより提供される。例えば、アカウント・エンジンはこのようなプロバイダであり得る。つまり、コンタクト情報のストレージはローカルに為されるが、関連データはアカウント装置の全部にわたって透過的に伝播できる。

本発明の原理によれば、自分のデータ・ストア（例えばメッセージ・ストアやメンバ・マネージャ）にあるコンタクト情報のコピーをそれまで保守していた全部のエンジンを変更して、それらのデータ・ストア内に完全なコンタクト情報の代わりにコンタクトＵＲＬを格納する。データ・ストアはＵＲＬだけを含むが、エンジンによって作成されたデータが他の共有空間メンバへの伝播のため共有空間シリアル化の一環としてシリアル化される際には、データ内のコンタクトＵＲＬを用いてコンタクト・ストアから実際のコンタクト情報を取得し、そのコンタクト情報はシリアル化したデータに含まれている。逆に、別の共有空間メンバから受信したデータを共有空間非シリアル化の一環として非シリアル化する際には、非シリアル化されたデータ内にあるコンタクト情報をコンタクト・ストアに追加し、関連付けられたコンタクトＵＲＬだけを共有空間データ・ストアに格納する。

前述したように、コンタクト・ストアはアカウント・エンジン又は共有空間メンバ・エンジン等の既存のエンジンによって保守できる。このエンジンは別のユーザから受信したメッセージに応答してコンタクトを更新する能力を備えている。これらのメッセージは以下のメッセージ形式を含む：

購読要求メッセージ ── このメッセージ形式は受信者のアイデンティティ・コンタクト情報の更新を自動的に受信するために送信者が受信者の購読リストに追加されることを要求する。購読要求メッセージは受信者についての完全なｖＣａｒｄ情報又は受信者の「名前だけ」と言うｖＣａｒｄのいずれかを含む。どちらの場合でも、保安上の目的から、このメッセージは受信者が送信者を確認して認証するために充分な情報、例えばデジタル署名を含む。

要求拒否メッセージ ── このメッセージは購読要求メッセージの受信者が更新の要求を拒否した場合に購読要求メッセージの送信者に返送される。購読要求は許可を設定するユーザ・インタフェース画面を用いて拒否できる。

送信者にはコンタクトの供給源がないと言うメッセージ ── このメッセージは購読者についてのコンタクト情報がコンタクト・ストアから削除された場合に購読リストにある各装置へ送信され、送信者がその購読者についてコンタクト情報の他の供給源を持たないことを示す。

コンタクトが更新されたと言うメッセージ ── このメッセージはあるアイデンティティのコンタクト情報が変化した場合に購読リストにある全てのコンタクトに送信され、送信者についてのコンタクト情報を受信者に更新させる。このメッセージは送信者の自己署名を含み、当該更新中に、保安上の目的から、メッセージ処理エンジンは自己署名が確認されたかどうかを検出する。自己署名が確認されない場合、コンタクト情報は破棄されエラーが発生する。

「コンタクトが更新された」と言うメッセージは送信者のｖＣａｒｄ情報も含む。購読リストにあるコンタクトについての名前だけと言うビットがセットされた場合、ｖＣａｒｄ情報は送信者の名前と、更新目的でコンタクトと通信するのに充分な情報だけを含む。名前だけと言うビットは購読リストにコンタクトを配置する購読要求メッセージが名前だけのｖＣａｒｄを含む場合に購読リスト内に設定される。後でメッセージ送信者が受信者と交信したときには、送信者の完全なｖＣａｒｄ情報を受信できるが、名前だけのｖＣａｒｄ情報から完全なｖＣａｒｄ情報へ購読リストのエントリを変更するためには、受信者は完全なｖＣａｒｄ情報を含む購読要求メッセージを新たに送信する必要がある。ＬＡＮ／ディレクトリの公開モードを「名前だけ」に変更することではすでに完全なｖＣａｒｄ情報を持っているユーザには影響しないが、更新が通知メッセージの結果でない場合には全てのコンタクト更新について再購読が必要になる。

装置消去メッセージ ── このメッセージは、購読リストがその一部をなすコンタクト・ストア・エントリに関連付けられたアイデンティティが永久に無効になる時又はその装置が消去される時に購読リストにある全ての購読装置へ送信される。このメッセージの受信者はそれまでの購読状態とは関係なく購読リストから送信者の装置を削除する。

ピン（Ｐｉｎｇ）メッセージ ── このメッセージは受信者がまだ有効かどうか調べるために使用する。もう有効ではなくなった供給源なしのコンタクトについてコンタクト・ストア内にコンタクト情報を保存するのを避けるため、コンタクト・ストアは定期的に購読リストにある供給源なしのコンタクトへ各々ピン（Ｐｉｎｇ）メッセージを送信する。所定数のピン・メッセージに対して応答がない場合、その供給源なしのコンタクトは削除にマークされる。この点で、状態４又は状態６になっている購読リスト内の購読者装置に相当するコンタクト・ストア内のコンタクト情報は削除される。同様に、装置を有しない購読者に相当するコンタクト情報は削除フラグ２２１をセットすることにより削除用にマークされる。コンタクト情報が削除用にマークされた場合、購読者装置は状態４であると仮定される。

ポン（Ｐｏｎｇ）メッセージ──このメッセージはピン・メッセージの送信者へそのメッセージの受信者から送信され受信者がまだアクティブであることを示す。

コンタクト情報を維持するためにコンタクト・ストアによって行われる処理について図４から図１５を参照して詳細に説明する。図４はアイデンティティのコンタクト・ストアへ新しいコンタクト供給源を追加する例示的な手順のステップを示す。この処理はコンタクト供給源が内部になくコンタクト情報が現在のアカウントにあるアイデンティティの一つによって所有されていない場合に実行される。処理はステップ４００で始まってステップ４０２に進み、ここでコンタクト・ストア内にすでにコンタクト供給源が存在するかどうかの判定を行う。コンタクトが未だコンタクト・ストア内に存在しない場合、処理はステップ４０４に進みここでコンタクト・ストアへコンタクト情報を追加する。

次に、ステップ４０８で、コンタクトに関係する全ての装置がアイデンティティのアカウント・アイデンティティの全部に関連付けられた購読リストに追加される。各々の追加された装置の状態変数の値は状態２にセットされる。次に、ステップ４１６で、情報をコンタクト・ストアへ追加しているコンタクトの装置の各々へアイデンティティによって購読要求メッセージが送信され、アイデンティティがコンタクトの購読リストへ追加され、これによって購読を双方向にする。処理はステップ４２０で終了する。

これ以外に、ステップ４０２で、コンタクトについての情報がコンタクト・ストアに存在すると判断された場合、ここで処理はステップ４０６へ進み、アイデンティティの購読リストにあるコンタクト装置のどれかが状態３又は状態４になっているか調べる。状態３又は状態４のいずれかになっている装置がない場合、処理はステップ４２０で終了する。しかし、１つ又はそれ以上の装置が状態３又は状態４のいずれかになっていると判断された場合、処理はステップ４１０へ進み、ここで削除フラグを調べることによりコンタクト・レコードが削除にマークされているかどうかを判定する。コンタクト・レコードが削除にマークされていた場合、ステップ４１４で、（削除フラグをリセットすることにより）コンタクト・レコードは削除のマークが解除され、ステップ４１８で、コンタクト情報に関連付けられた装置の全部がアイデンティティの購読リストに追加され状態変数の値が状態２にセットされる。この動作は図３に図示してあるように状態３０６と状態３０２の間の状態遷移３２８に相当する。処理はステップ４２０で終了する。

これ以外に、ステップ４１０で、コンタクト・レコードが削除にマークされていないと判断された場合、アイデンティティの購読リストにある各装置の状態変数の値は状態３から状態１へ変更される。この動作は図３に示した通り状態３００と状態３０４の間の状態遷移３１４に相当する。次に、ステップ４１６で、購読要求メッセージが、情報をコンタクト・ストアへ追加しようとしているコンタクトの装置の各々へアイデンティティによって送信されアイデンティティがコンタクトの購読リストへ追加され、これによって購読を双方向にする。処理はステップ４２０で終了する。

図５はコンタクト供給源がコンタクト・ストアから除去された場合にコンタクト・ストアによって行われる例示的な処理を示す。この処理はコンタクト供給源が内部になく、かつ、コンタクト情報が現在のアカウントにあるアイデンティティの一つではない場合に行われ、ステップ５００で始まってステップ５０２へ進み、ここで、除去しようとするコンタクト情報がコンタクト・ストア内にあるこのコンタクト情報についての最後の供給源かどうか判断を行う。このコンタクト情報が最後の供給源ではない場合、処理はステップ５１４で終了する。これ以外に、コンタクト情報が最後の供給源だった場合、処理はステップ５０４へ進み、ここで、全てのコンタクト装置を処理したかどうか判定を行う。全部の装置が処理された場合、処理はステップ５１４で終了する。

これ以外に、ステップ５０４で、全てのコンタクト装置が処理されていないと判断された場合、ステップ５０６で、次の装置に関連した状態変数の値が、装置が状態１又は状態２になっていることを示しているかどうか、チェックを行う。装置が状態１又は状態２になっていない場合、処理はステップ５０４に戻り、ここで処理すべき追加の装置が残っているかどうかを調べる。

次の装置が状態１又は状態２になっていると、ステップ５０６で判定された場合、処理はステップ５０８に進み、ここで「送信者はコンタクトの供給源を持たない」と言うメッセージが装置に関連付けられたコンタクトへ送信される。このメッセージはコンタクトがアイデンティティのコンタクト・ストア内で供給源なしになったことを示す。アイデンティティのコンタクト情報が受信者であるコンタクトのコンタクト・ストア内で供給源なしになった場合、両者はそれらの購読リストから他方の名前を削除できコンタクト・ストア内で他方のコンタクトを削除されたものとしてマークすることができる。

次に、ステップ５１０で、状態１になっている全装置について、装置に関連付けられた状態変数の値が全部のアカウント・アイデンティティにある購読リスト内で１から３へ変更される。この動作は図３の状態３００から状態３０４への状態遷移３１２に相当する。次に、ステップ５１２で、状態２になっている全ての装置がアイデンティティの購読リストから削除される。この動作は図３において状態３０２から状態３０６への状態遷移３１６に相当する。更に、状態５になっている全ての装置がアイデンティティの購読リストから削除される。この動作は図３に置いて状態３０８から状態３１０への状態遷移３３０に相当する。処理はステップ５１４で終了する。各装置を削除する際に図７に示してあり後述する処理が実行されることに注意する。

図６はコンタクト・ストア内の情報が更新されたときに全ての購読者に通知するコンタクト・ストアによって行われる例示的処理を示す。この処理はステップ６００で始まってステップ６０２へ進み、ここで更新しようとしているコンタクト情報が現在のアカウントにあるアイデンティティの一つによって保有されているかどうかの判定を行う。このようなコンタクト情報に対して更新が行われつつある場合には、ステップ６０８で、「コンタクトが更新された」と言うメッセージをアカウントの購読リスト内にある状態１、２又は３の装置の全部へ送信する。これはコンタクト情報を更新しなければならないことを各購読者に通知する。

これ以外に、ステップ６０２で、アイデンティティによって所有されていないコンタクト情報へのコンタクト情報変更が行われていることの判定を行い、処理はステップ６０４へ進み、ここで更新が別のコンタクトから受信した「コンタクト更新」メッセージによるものかどうかの判定を行う。更新がこのような更新メッセージの結果である場合には処理はステップ６１４で終了する。

更新が到着した更新メッセージの結果ではない場合、ステップ６０６で、新しいコンタクト・シーケンス番号がコンタクト・ストア内のコンタクト・レコードで記録されている現在のシーケンス番号より大きいかどうか（又は新しいコンタクト・シーケンス番号が現在のシーケンス番号と等しい場合には格納されたコンタクトが異なるか）を調べるチェックを行う。新しいシーケンス番号が現在のシーケンス番号より大きくないか、又は格納されたコンタクトが異なる場合、処理はステップ６１４で終了する。しかし、新しいシーケンス番号が現在のシーケンス番号より大きく格納されたコンタクトが同一の場合には、ステップ６１０で、コンタクト情報の更新を要求しているコンタクトへ購読要求メッセージを送信する。ステップ６１２で、「送信者はコンタクトの供給源を持たない」と言うメッセージが状態３になっているコンタクトの購読リストにある全部の装置へ送信される。処理はステップ６１４で終了する。

図７はコンタクト装置が購読リストから削除される場合にコンタクト・ストアによって実行される例示的な処理を示す。この処理はステップ７００で始まってステップ７０２へ進み、ここで削除した装置がコンタクトに関連付けられた最後の装置だったかどうか、かつ、コンタクトが現在供給源なしかどうかを判定する。そうであれば、処理はステップ７０４に進み、ここで関連付けられたコンタクトが削除にマークされ処理はステップ７０６で終了する。これ以外に、削除された装置がコンタクトに関連付けられた最後の装置ではない場合、処理はステップ７０２から直接ステップ７０６へ進んで終了する。

図８はすでにアクティブではなくなっている供給源なしコンタクトを除外するため、コンタクト・ストアによって定期的に、例えば最後の時点から１週間後に、実行される例示的な処理を示している。この処理はステップ８００で始まってステップ８０２へ進み、ここでコンタクト・ストア内の各コンタクトを調べる。全部のコンタクトが処理されたら、処理はステップ８０４で終了する。これ以外に、処理すべきコンタクトが更に残っている場合、処理はステップ８０６へ進み、ここで、任意のコンタクトについて、購読リスト内でそのコンタクトに関連付けられた装置全部を調べる。ステップ８０６で、処理すべき購読リスト内の装置がこれ以上残っていなければ、購読リスト内にあってコンタクトに関連付けられた全部の装置が処理されたことになり処理はステップ８０２へ戻り、処理すべきコンタクトが更に残っているかどうかを調べるチェックを行う。

ステップ８０６で、処理すべき装置が更に残っていると判断された場合、処理はステップ８０８へ進み、ここで次の装置状態をチェックする。次の装置がその装置に関連付けられた状態変数の値で示される状態３になっていなければ、処理はステップ８０６へ戻りここで処理すべき装置が更に残っているかどうかを調べるチェックを行う。これ以外に、ステップ８０８で、調べている装置が状態３にあると判断された場合、処理はステップ８１０へ進み、ここで、装置に関連付けられたピンカウント（ＰｉｎｇＣｏｕｎｔ）変数をインクリメントする。次に、ステップ８１２で、インクリメントしたピンカウント変数の値が所定の限界、例えば４より大きいかどうかの判定を行う。ピンカウント変数の値が所定の限界より小さいか又は等しい場合には、ステップ８１６で、ピン・メッセージを装置へ送信する。装置がアクティブな場合、この装置はピン・メッセージの受信時にポン・メッセージを返す。処理はステップ８０６へ戻り更にコンタクトを処理する必要があるかどうかを調べる。

しかし、ステップ８１２で、ピンカウント変数値が所定の限界を越えていた場合、ステップ８１４で装置は全てのアカウント・アイデンティティの購読リストから削除される。処理はステップ８０６へ戻り更に処理すべきコンタクトが残っているかどうかを調べる。

図９Ａと図９Ｂは並置した場合に他のコンタクトから受信したメッセージを処理するためコンタクト・ストアによって実行される例示的処理を示している。この処理の第１のステップはどの種類のメッセージを受信したか調べることである。この第一ステップが図９Ａと図９Ｂに図示してある。処理はステップ９００で始まってステップ９０２へ進み、ここで幾つかの初期チェックを行ってメッセージがコンタクト伝播メッセージかどうか調べ、送信者のコンタクト情報がうまく認証されたことと、送信者の署名がその送信者についてすでにファイル上にあるいずれかの署名と一致したことを確認する。これらの初期チェックに合格しなかった場合には、処理はページ間接続９２６と９３０を経由して進みステップ９３８で終了する。

これ以外に、ステップ９０２で、初期チェックに合格した場合、メッセージを調べて受信したメッセージの形式を決定する。ステップ９０４でチェックを行いメッセージが購読要求メッセージかどうかを調べる。そうなら、購読要求メッセージ・ルーチン処理９０６を実行する。

メッセージが購読要求メッセージでない場合、処理はステップ９０８へ進み、ここでチェックを行ってメッセージが要求拒否メッセージかどうかを調べる。そうなら、要求拒否メッセージ・ルーチン処理９１０を実行する。

メッセージが要求拒否メッセージではない場合、処理はステップ９１２へ進みここでチェックを行ってメッセージが送信者はコンタクトの供給源なしと言うメッセージかどうかを調べる。そうなら、供給源なしメッセージ・ルーチン処理９１４を実行する。

メッセージが送信者はコンタクトの供給源なしと言うメッセージではない場合、処理はステップ９１６へ進みここでチェックを行ってメッセージがコンタクト更新済みメッセージかどうかを調べる。そうならコンタクト更新済みメッセージ・ルーチン処理９１８を実行する。

メッセージがコンタクト更新済みメッセージではない場合、処理はステップ９２０へ進みここでチェックを行ってメッセージがピン・メッセージかどうかを調べる。そうなら、ピン・メッセージ・ルーチン処理９２２を実行する。

メッセージがピン・メッセージではない場合、処理はページ間接続９２４と９２８を通ってステップ９３２へ進み、ここでメッセージがポン・メッセージかどうかを調べる。そうなら、ポン・メッセージ・ルーチン処理９３４を実行する。

最後に、メッセージがポン・メッセージではない場合、これは装置削除メッセージのはずであるから装置削除メッセージ・ルーチン処理９３６を実行する。いずれの場合も、処理はステップ９３８で終了する。

購読要求メッセージ・サブルーチン９０６処理が図１０に更に詳細に図示してある。この処理はステップ１０００で始まってステップ１００２へ進み、ここで要求側に対して購読が許可されているか調べる。前述したように、ユーザ・インタフェース選択を提供してアイデンティティが所有者のアイデンティティ情報に対する購読更新に関する許可をセットすることができる。これらの許可はステップ１００２でチェックされてメッセージ送信者がコンタクト情報更新を購読する許可を持っているかどうか調べる。

許可によって送信者が更新を購読できない場合、ステップ１００４で送信者のコンタクト情報がメッセージ受信者のコンタクト・ストアから除去され、ステップ１０１０で要求拒否メッセージがメッセージ送信者へ送信される。サブルーチンはステップ１０２２へ戻る。

これ以外に、ステップ１００２で決定したように許可によって送信者が購読を許可する場合、処理はステップ１００６へ進み、ここで送信者のコンタクト情報が受信者のコンタクト・ストアに存在するかどうかの判定を行う。コンタクト情報がコンタクト・ストア内にない場合、ステップ１００８で、コンタクト情報がコンタクト・ストアへ追加される。処理は次にステップ１０２０へ進み、ここで送信者の装置が受信者の購読リストへ追加され状態変数が状態３にセットされる。サブルーチンはステップ１０２２へ戻る。

ステップ１００６でコンタクト情報がすでに受信者のコンタクト・ストアに存在すると判断された場合、ステップ１０１２で、チェックを行ってコンタクトが削除にマークされているかどうかを調べる。そうならステップ１０１６で、コンタクト・レコードが削除マークを解除され処理はステップ１０２０へ進み、ここで送信者の装置が受信者の購読リストへ追加されて状態変数の値が状態３にセットされる。サブルーチンはステップ１０２２に戻る。この動作は図３に図示した状態４（３０６）から状態３（３０４）への遷移３１８に相当する。

これ以外に、ステップ１０１２でコンタクトが削除にマークされていないと判断された場合、処理はステップ１０１４へ進み、ここで全部のアカウント・アイデンティティについて、送信者のコンタクト装置に対応する購読リスト内の状態変数の値が２から１へ、又は５から１へ、変更される。これらの動作は各々状態３０２から状態３００への状態遷移３２５と、状態３０８から状態３００への状態遷移３２２に相当する。次に、ステップ１０１８で、送信者側装置のピン・カウンタが全部のアカウント・アイデンティティでゼロにセットされる。サブルーチンは次にステップ１０２２に戻る。

要求拒否メッセージ処理サブルーチン９１０が図１１に更に詳細に図示してある。この処理はステップ１１００で始まりステップ１１０２へ進み、ここでメッセージ送信者のコンタクト情報が受信者のコンタクト・ストアに存在するかどうかの判定を行う。この情報がコンタクト・ストアに存在しない場合にはサブルーチンはステップ１１０６へ戻る。

これ以外で、ステップ１１０２で送信者のコンタクト情報がコンタクト・ストアに存在していると判断された場合、送信者の装置の全部がアカウント・アイデンティティの各々で処理される。第一に、ステップ１１０４で、チェックを行い送信者について処理すべき装置レコードが未だ残っているかを調べる。処理すべき装置レコードが残っている場合には、ステップ１１０８で、チェックを行って処理すべき次の装置レコードにある状態変数の値が１か又は２かを調べる。状態変数の値が１又は２の場合、処理はステップ１１１０へ進みここで全てのアカウント・アイデンティティについて受信者の購読リストにある送信者の装置レコードでの状態変数の値を５に変更する。この動作は図３の状態３００から状態３０８への状態遷移３２４と状態３０２から状態３０８への状態遷移３２６に相当する。

これ以外に、送信者の装置レコードの状態変数の値が１又は２ではない場合には、ステップ１１１２で、チェックを行ない、状態変数の値が３かどうかを調べる。値が３ではない場合、処理はステップ１１０４へ戻って、更に処理すべき装置レコードがあるかどうかを調べる。しかし、状態変数の値が３であれば、ステップ１１１４で、全てのアカウント・アイデンティティにおいて装置レコードを削除する。この動作は図３の状態３０４から状態３１０への状態遷移３３２に相当する。処理はステップ１１０４へ戻って更に処理すべき装置レコードが存在するか調べる。全てのレコードが処理されたら、サブルーチンはステップ１１０６へ戻る。

供給源なしメッセージ処理サブルーチン９１４が図１２に更に詳細に図示してある。この処理はステップ１２００で始まりステップ１２０２へ進みここでメッセージ送信者のコンタクト情報が受信者のコンタクト・ストアに存在するかどうかを調べる。情報がコンタクト・ストアに存在しない場合サブルーチンはステップ１２０６へ戻る。

これ以外に、ステップ１２０２で送信者のコンタクト情報がコンタクト・ストアに存在すると判断された場合、送信者の装置の全部がアカウント・アイデンティティの各々で処理される。第一に、ステップ１２０４で、チェックを行い、処理すべき送信者側の装置レコードが未だ残っているか調べる。処理すべき装置レコードが残っている場合、ステップ１２０８でチェックを行い、処理すべき次の装置レコードの状態変数の値が１かどうか調べる。状態変数の値が１であれば、処理はステップ１２１０へ進みここで全部のアカウント・アイデンティティについて受信者の購読リストにある送信者の装置レコードで状態変数の値を２に変更する。この動作は図３の状態３００から状態３０２への状態遷移３２３に相当する。

これ以外に、送信者の装置レコードで状態変数の値が１ではない場合には、ステップ１２１２で、チェックを行って状態変数の値が３かどうかを調べる。値が３でなければ、処理はステップ１２０４へ戻り、処理すべき装置レコードが更に残っているかチェックする。しかし、状態変数の値が３であれば、ステップ１２１４で、全てのアカウント・アイデンティティで装置レコードが削除される。この動作は図３の状態３０４から状態３０６への状態遷移３２０に相当する。処理はステップ１２０４へ戻り処理すべき装置レコードが更に残っているかどうか調べる。全てのレコードを処理したら、サブルーチンはステップ１２０６へ戻る。

コンタクト更新済みメッセージ処理サブルーチン９１８が図１３に更に詳細に図示してある。この処理はステップ１３００で始まりステップ１３０２へ進みここでメッセージ送信者のコンタクト情報が受信者のコンタクト・ストアに存在するかどうかを調べる。この情報がコンタクト・ストアに存在しない場合サブルーチンはステップ１３１０へ戻る。

これ以外に、ステップ１３０２で送信者のコンタクト情報がコンタクト・ストアに存在すると判断された場合、ステップ１３０４で、送信者のコンタクト・シーケンス番号が変更されたかどうかを調べる。このシーケンス番号が変更された場合、ステップ１３０６で受信者のコンタクト・ストアにある送信者のコンタクト情報を更新して処理はステップ１３０８へ進む。しかしこのシーケンス番号が変更されなかった場合には処理はステップ１３０８へ直接進む。

ステップ１３０８で、全てのアカウント・アイデンティティについて購読リストにある送信者の装置のピン・カウンタがゼロにセットされる。サブルーチンはステップ１３１０へ戻る。

ピン・メッセージ処理サブルーチン９２２が図１４に更に詳細に図示してある。この処理はステップ１４００で始まってステップ１４０２へ進み、ここで受信者のコンタクト・ストアにメッセージ送信者のコンタクト情報が存在するかどうかを調べる。この情報がコンタクト・ストアに存在しない場合にはサブルーチンはステップ１４０８へ戻る。

これ以外で、ステップ１３０２で送信者のコンタクト情報がコンタクト・ストアに存在すると判断された場合には、ステップ１３０４で、送信者の装置レコードはその状態変数の値が２になっているかどうか調べる。状態変数の値が２であれば、送信者へポン・メッセージが返される。装置レコードが状態２でなければ、サブルーチンはステップ１４０８へ戻る。

ポン・メッセージ処理サブルーチン９２４が図１５に更に詳細に図示してある。この処理はステップ１５００で始まりステップ１５０２へ進んで、ここで受信者のコンタクト・ストアにメッセージ送信者のコンタクト情報が存在するかを調べる。この情報がコンタクト・ストアに存在しない場合には、サブルーチンはステップ１５１２へ戻る。

受信者のコンタクト・ストアに前記の情報が存在する場合、ステップ１５０４で、チェックを行いコンタクトが削除にマークされているかどうかを調べる。そうなら、ステップ１５０６で、コンタクト・レコードの削除マークが解除され処理はステップ１５０８へ進んで、ここで全てのアカウント・アイデンティティについて受信者の購読リストに送信者の装置を追加し、状態変数の値を状態３にセットする。この動作は図３に示した状態４（３０６）から状態３（３０４）への状態遷移３１８に相当する。これ以外で、ステップ１５１０でコンタクトが削除にマークされていなかったと判断された場合には、処理は直接ステップ１５１０へ進む。

次に、ステップ１５１０で、全てのアカウント・アイデンティティについて送信者の装置レコードでピン・カウンタがゼロにセットされる。サブルーチンはステップ１５１２で終了する。

装置削除メッセージ処理サブルーチン９３６が図１６に更に詳細に図示してある。この処理はステップ１６００で始まってステップ１６０２へ進み、ここで受信者のコンタクト・ストアにメッセージ送信者のコンタクト情報が存在するかどうかを調べる。この情報がコンタクト・ストアに存在しない場合にはサブルーチンはステップ１６１０へ戻る。

これ以外で、ステップ１６０２で、送信者のコンタクト情報がコンタクト・ストアに存在すると判断された場合には、ステップ１６０４で、現在のアカウントでの全てのアイデンティティが処理されたかどうかを調べる。そうなら、処理はステップ１６１０で終了する。違う場合には、ステップ１６０６で、メッセージ送信者に関連付けられた購読リストを取得し、ステップ１６０８で、メッセージに記載された装置が購読リストから削除される。処理はステップ１６０４へ戻り全てのアイデンティティが処理されたかどうかを調べる。全部のアイデンティティを処理した場合には、処理はステップ１６１０で終了する。

他の二つの処理を用いてコンタクト・ストアを保守する。これらの処理はアカウントを別の装置へインポートした場合とアカウントが装置から削除された場合に行われる。第１の処理は図１７に図示してあり、アカウントが別の装置へインポートされた場合にステップ１７００で始まる。この処理はステップ１７０２へ進み、ここでそのアカウントについてコンタクト・ストア内にある全てのコンタクト・ストア・エントリが調べられる。ステップ１７０２で判断されたように処理すべきエントリが残っていれば、ステップ１７０６で、処理のために次のエントリを選択する。ステップ１７０８で、そのエントリにある供給源リストを調べることでエントリが供給源なしコンタクトのものかどうかを調べる。コンタクトがステップ１７０８で判断されたように供給源なしであれば、そのコンタクトについて購読リストにある全部の装置を処理する。更に詳しくは、ステップ１７１０で全部の装置を処理したかどうか調べる。違う場合には、ステップ１７１４で、処理する次の装置を選択する。ステップ１７１８で、「購読要求」メッセージを選択した装置へ送信する。ステップ１７２２で、「送信者はコンタクトの供給源を持たない」と言うメッセージを選択した装置へ送信する。処理はステップ１７１０へ戻って全ての装置を処理したかどうか調べる。ステップ１７１０で判断されたように全ての装置が処理された場合、処理はステップ１７０２へ戻り全てのコンタクト・ストア・エントリを処理したかどうか調べる。ステップ１７０２で判断されたように全部のエントリを処理したら、この処理はステップ１７０４で終了する。

ステップ１７０８に戻って、コンタクトがステップ１７０８で判断されたように供給源なしではない場合、処理はステップ１７１２へ進み、ここで、エントリがそのアカウントにあるアイデンティティによって所有されているコンタクトのものかどうかを調べる。コンタクト情報がアイデンティティによって所有されている場合には、処理はステップ１７０２へ戻って全部のエントリを処理したかどうか調べる。

これ以外に、ステップ１７１２で、コンタクト情報がアイデンティティによって所有されていないと判断された場合、そのコンタクトについて購読リストにある全ての装置を処理する。更に詳しくは、ステップ１７１６で全部の装置を処理したかどうか調べる。違う場合、ステップ１７２０で、処理のために次の装置を選択する。ステップ１７２４で、「購読要求」メッセージを選択した装置へ送信する。処理はステップ１７１６へ戻って全部の装置を処理したかどうか調べる。ステップ１７１６で判断されたように全ての装置を処理したら、処理はステップ１７０２へ戻って全てのコンタクト・ストア・エントリを処理したか調べる。

装置からアカウントが削除された時に実行される処理が図１８Ａと図１８Ｂに図示してある。この処理はステップ１８００で始まりステップ１８０２へ進んで、ここでそのアカウントのコンタクト・ストアにある全部のエントリを処理したかどうか調べる。ステップ１８０２で判断されたとおり全部のエントリが処理されていない場合、ステップ１８０６で次の未処理エントリが選択される。次に、ステップ１８０８で、エントリがそのアカウントに関連付けられたアイデンティティの一つによって所有されているかどうかを調べる。違う場合、処理はステップ１８０２へ戻って全部のエントリを処理したかどうか調べる。これ以外に、ステップ１８０８で、エントリがアイデンティティによって所有されていると分かった場合、ステップ１８１０でそのエントリの全ての購読リストを処理したかどうかを調べる。ステップ１８１０で判断されたように全部のリストが処理されていない場合、ステップ１８１２で次の未処理リストを処理するために選択する。

次に、ステップ１８１４で、選択したリストの全ての購読者を処理したか調べる。違う場合、リスト内の次の未処理購読者を選択する。処理はページ間接続１８２０と１８２４を経由してステップ１８２６へ進み、ここで、購読者エントリ内の装置リストを調べることにより、選択した購読者について全部の装置を処理したか調べる。違う場合、ステップ１８２８で、次の未処理装置を選択する。ステップ１８３０で、選択された装置が状態１、２又は３になっているかどうかを調べる。違う場合処理はステップ１８２６へ戻って処理すべき装置が更に残っているかどうかを調べる。

これ以外に、ステップ１８３０で、選択された装置が状態１、２又は３のいずれか一つの状態になっていると判断された場合、ステップ１８３２で、「装置削除」メッセージを選択された装置へ送信する。処理はステップ１８２６へ戻って処理すべき装置が更に残っているか調べる。ステップ１８２６で判断されたように、全部の装置を処理したら、処理はページ間接続１８２２と１８１８を経由してステップ１８１４へ戻り選択したリストに処理すべき購読者が更に残っているか調べる。ステップ１８１４で判断されたように全部の購読者を処理したら処理はステップ１８１０へ戻り処理すべき購読リストが未だ残っているかどうか調べる。

ステップ１８１０で判断されたように全部の購読リストを処理したら、処理はステップ１８０２へ戻り処理すべきエントリが残っているかを調べる。ステップ１８０２で、全部のエントリを処理したことが判断されたら、処理はステップ１８０４で終了する。

前述の実施態様のソフトウェアによる実装は、例えばコンピュータで読み取り可能な媒体例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭメモリ、又は固定ディスク等の有形媒体上に固定されるか、又は媒体上でモデム又はその他のインタフェース装置を経由してコンピュータ・システムへ転送可能な一連のコンピュータ命令を含む。媒体は光又はアナログ通信回線を含みこれに制限されない有形媒体であるか、又はマイクロ波、赤外線又はその他の伝送技術を含みこれに制限されない無線技術で実現される。媒体はインターネットでもあり得る。一連のコンピュータ命令は本発明に関して本明細書で前述した機能の全部又は一部を実現する。このようなコンピュータ命令は多くのコンピュータ・アーキテクチャ又はオペレーティング・システムで使用される多数のプログラミング言語で書くことができることは当業者には理解されよう。更に、このような命令は現在又は将来の、半導体、磁気、光又はその他のメモリ装置を含みこれに制限されない何らかのメモリ技術を用いて保存するか、又は現在又は将来の光、赤外線、マイクロ波、又はその他の伝送技術を含みこれに制限されない何らかの通信技術を用いて伝送することが可能である。このようなコンピュータ・プログラム製品は着脱可能な媒体に印刷又は電子化文書を伴って、例えばシュリンクラップ・ソフトウェア等として配布されたり、コンピュータ・システム例えばシステムＲＯＭ又は固定ディスクへ導入済み、又はサーバ又は電子掲示板からネットワーク上例えばインターネット又はワールドワイド・ウェブで配布することができることを企図している。

本発明の典型的実施態様を開示したが、本発明の精神と範囲から逸脱することなく本発明の利点の幾つかを実現する様々な変化や変更を成し得ることは当業者には明らかであろう。例えば、他の実装において、図示したものとは異なるプロトコルや変換を実行し得ることが当業者には明らかであろう。例えば特定の処理フローや図示したステップの順序、並びに本発明の概念へのその他の変更などのその他の態様は添付の請求の範囲で包含されることを意図している。

図１Ａは、従来技術の分散コラボレーション・システムの略ブロック図である。 図１Ｂは、図１Ａのコラボレータ・コンピュータの一つにあるシステム・データベースの更に詳細なブロック図である。 図２は、図１Ｂに図示したデータベースのアカウント・ストアの更に詳細なブロック図である。 図３は、購読リストのコンタクト装置レコードの各種状態と各種動作により引き起こされる状態間での遷移を示す状態図である。 図４は、コンタクト情報をコンタクト・ストアへ追加する例示的な処理のステップを示すフローチャートである。 図５は、コンタクト情報をコンタクト・ストアから除去する例示的処理のステップを示すフローチャートである。 図６は、コンタクト・ストア内のコンタクト情報を更新する例示的処理のステップを示すフローチャートである。 図７は、購読リストからコンタクト装置を削除する例示的な処理のステップを示すフローチャートである。 図８は、定期的チェックを実行して供給源なしコンタクトがまだ有効かどうか判定する例示的な処理のステップを示すフローチャートである。 図９Ａと図９Ｂは、並置した場合コンタクトから受信したコンタクト伝播メッセージを処理するための例示的処理のステップを示すフローチャートを構成する。 図１０は、購読要求メッセージを処理する例示的なサブルーチンのステップを示すフローチャートである。 図１１は、要求拒否メッセージを処理する例示的サブルーチンのステップを示すフローチャートである。 図１２は、送信側が供給源を持たないと言うメッセージを処理するための例示的サブルーチンのステップを示すフローチャートである。 図１３は、コンタクト更新済みと言うメッセージを処理するための例示的サブルーチンのステップを示すフローチャートである。 図１４は、ピン（ｐｉｎｇ）メッセージを処理する例示的サブルーチンのステップを示すフローチャートである。 図１５は、ポン（ｐｏｎｇ）メッセージを処理する例示的サブルーチンのステップを示すフローチャートである。 図１６は、装置消去メッセージを処理する例示的サブルーチンのステップを示すフローチャートである。 図１７は、アカウントが装置へインポートされた場合にコンタクト・ストア・エントリを処理する例示的サブルーチンのステップを示すフローチャートである。 図１８Ａと図１８Ｂは、並置した場合に装置からアカウントが削除された場合に実行される例示的処理を示すフローチャートである。

Claims (20)

1. ネットワークにより接続された複数のコラボレーション・コンピュータを有し、各々のコンピュータはローカル・データ・ストアとコンタクト情報を使用する複数のロケーションとを有することを特徴とする分散型コラボレーション・システムにおいてコンタクト情報を格納し管理するための方法であって、
   （ａ）あるコンタクトについてのコンタクト情報をコラボレーション・コンピュータで受信した際に、前記コンタクト情報とユニークなコンタクト参照とをそのコラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内の単一のコンタクト・ストアに格納し、
   （ｂ）前記コンタクト情報の代わりに複数のロケーションの各々に前記コンタクト参照を配置する
   ことを特徴とする方法。
2. （ｃ）あるコンタクトについてのコンタクト情報をコンタクトからコラボレーション・コンピュータで受信した際に、前記コンタクト情報の更新を要求するメッセージをそのコンタクトに送信することを更に含む
   ことを特徴とする請求項１に記載の方法。
3. 各々のコラボレーション・コンピュータは前記コラボレーション・コンピュータのユーザに対応する少なくとも一つのアイデンティティを有することを特徴とする請求項２に記載の方法であって、前記方法は
   （ｄ）前記コンタクト・ストア内に前記アイデンティティについてのコンタクト情報を配置すること
   を更に含むことを特徴とする請求項２に記載の方法。
4. 前記メッセージが前記アイデンティティについての前記コンタクト情報を含むことを特徴とする請求項３に記載の方法。
5. （ｅ）メッセージ受信時に前記コンタクトは前記コンタクトによって使用されるコラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内のコンタクト・ストアに前記アイデンティティのための前記コンタクト情報を格納する
   ことを更に含むことを特徴とする請求項４に記載の方法。
6. （ｆ）第１の供給源からコンタクト情報を受信した時に前記コンタクト・ストア内に前記コンタクト情報を格納することと、
   （ｇ）前記格納したコンタクト情報内に前記コンタクト情報の供給源のリストを作成することと、
   （ｈ）前記コンタクト情報を前記第１の供給源とは異なる第２の供給源からコラボレーション・コンピュータで受信した時に前記供給源のリストへ供給源を追加することと、
   （ｉ）前記第１と第２の供給源の一方からコンタクト情報を除去する要求を前記コラボレーション・コンピュータで受信した時に前記供給源のリストから供給源を除去することと
   を更に含むことを特徴とする請求項５に記載の方法。
7. （ｊ）前記供給源のリストが空になって、かつ、前記アイデンティティについての前記コンタクト情報が前記コンタクトによって使用されるコラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内の前記コンタクト・ストアから削除されたときに前記コンタクト・ストアから前記コンタクト情報を削除する
   ことを更に含むことを特徴とする請求項６に記載の方法。
8. 各々のコラボレーション・コンピュータはこれに関連付けられた前記ローカル・データ・ストア内に少なくとも一つのアカウント領域を有し、ステップ（ａ）は
   （ａ１）前記アカウント領域内に前記コンタクト情報とユニークなコンタクト参照とを格納すること
   を含むことを特徴とする請求項１に記載の方法。
9. （ｃ）前記コラボレーション・コンピュータから受信したメッセージに応答して前記コンタクト情報を更新し削除すること
   を更に含むことを特徴とする請求項１に記載の方法。
10. 前記コンタクト情報はこれに関連付けられた状態を有し、かつ、ステップ（ｃ）は前記メッセージに応答して前記状態を変更すること
    を含むことを特徴とする請求項９に記載の方法。
11. ネットワークにより接続された複数のコラボレーション・コンピュータを有し、各々のコンピュータはローカル・データ・ストアとコンタクト情報を使用する複数のロケーションとを有することを特徴とする分散型コラボレーション・システムにおいてコンタクト情報を格納し管理するための装置であって、
    あるコンタクトについてのコンタクト情報をコラボレーション・コンピュータで受信した時に動作してそのコラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内の単一のコンタクト・ストアに前記コンタクト情報とユニークなコンタクト参照とを格納するための手段と、
    前記コンタクト情報の代わりに前記複数のロケーションの各々に前記コンタクト参照を配置するための手段と
    を含むことを特徴とする装置。
12. あるコンタクトについてのコンタクト情報をあるコンタクトからコラボレーション・コンピュータで受信した時に動作して、前記コンタクト情報の更新を要求するメッセージをそのコンタクトに送信するための手段
    を更に含むことを特徴とする請求項１１に記載の装置。
13. 各々のコラボレーション・コンピュータは前記コラボレーション・コンピュータのユーザに対応する少なくとも一つのアイデンティティを有することを特徴とする請求項１２に記載の装置であって、前記装置は
    前記コンタクト・ストア内に前記アイデンティティについてのコンタクト情報を配置するための手段
    を更に含むことを特徴とする請求項１２に記載の装置。
14. 前記メッセージは前記アイデンティティについての前記コンタクト情報を含むことを特徴とする請求項１３に記載の装置。
15. 前記コンタクトによって使用されるコラボレーション・コンピュータでメッセージを受信した時に動作して前記コンタクトによって使用される前記コラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内のコンタクト・ストア内に前記アイデンティティについての前記コンタクト情報を格納するための手段
    を更に含むことを特徴とする請求項１４に記載の装置。
16. 第１の供給源からコンタクト情報を受信した時に前記コンタクト・ストア内に前記コンタクト情報を格納するための手段と、
    前記格納したコンタクト情報内に前記コンタクト情報の供給源のリストを作成するための手段と、
    前記コンタクト情報を前記第１の供給源とは異なる第２の供給源からコラボレーション・コンピュータで受信した時に前記供給源のリストへ供給源を追加するための手段と、
    前記第１と第２の供給源の一方からコンタクト情報を除去する要求を前記コラボレーション・コンピュータで受信した時に前記供給源のリストから供給源を除去するための手段と、
    を更に含むことを特徴とする請求項１５に記載の装置。
17. 前記供給源のリストが空になって、かつ、前記アイデンティティについての前記コンタクト情報が前記コンタクトによって使用されるコラボレーション・コンピュータに関連付けられた前記ローカル・データ・ストア内の前記コンタクト・ストアから削除されたときに前記コンタクト・ストアから前記コンタクト情報を削除するための手段
    を更に含むことを特徴とする請求項１６に記載の装置。
18. 各々のコラボレーション・コンピュータはこれに関連付けられた前記ローカル・データ・ストア内に少なくとも一つのアカウント領域を有し、かつ、単一のコンタクト・ストア内に前記コンタクト情報とユニークなコンタクト参照とを格納するための前記手段は前記アカウント領域に前記コンタクト情報とユニークなコンタクト参照とを格納するための手段を含む
    ことを特徴とする請求項１１に記載の装置。
19. 前記コラボレーション・コンピュータから受信したメッセージに応答して前記コンタクト情報を更新し削除するための手段
    を更に含むことを特徴とする請求項１１に記載の装置。
20. 前記コンタクト情報はこれに関連付けられた状態を有し、かつ、前記コンタクト情報を更新し削除するための前記手段は前記メッセージに応答して前記状態を変更するための手段を含む
    ことを特徴とする請求項１９に記載の装置。

Images