JP5078357B2 - ピアの発見 - Google Patents

Description

本願は、参照によりその内容が本明細書に組み込まれている、２００３年１１月１２日に出願された優先権仮出願第６０／５１８６４６号の利益を主張する。

本発明は、通信ネットワーク内でのピアの発見に関する。

多くの知られている回線交換（ｃｉｒｃｕｉｔ−ｓｗｉｔｃｈｅｄ）またはパケット交換電話ソリューションでは、集中型の装置（たとえば、スイッチまたは構内交換機（ＰＢＸ））が、呼の終了、呼の処理、交換、および／または呼の対応機能を提供する。大規模なシステムでは、中央装置が、コンピュータに電話セットを接続するライン・カードと呼ばれる回路基板上でいくつかの機能を制御する、強力なコンピュータであることもある。小規模なシステム（たとえば、端末セットが１０個以下のシステム）では、中央の知能（ｉｎｔｅｌｌｉｇｅｎｃｅ）が実際に、中央の処理装置を保持するように特別に設計された「黄金の」電話セット内に所在していることもある。

中央装置のとる形態に関わらず、いくつかの端末セット（たとえば、有線または無線電話セット）は通常、中央装置に接続される。中央装置と比較すると、端末セットは通常「ダム（ｄｕｍｂ）」デバイスである。すなわち、端末セットは単に、フック・スイッチ情報およびキー・プレス（たとえば、デュアル・トーン多周波数すなわちＤＴＭＦトーン）を中央装置に送信し、ダイヤル・トーン、呼出音、音声信号など、中央装置からの信号を音に（あるいは、場合によっては画像またはビデオに）変換することしかできない。端末セットは通常、他のどんな端末セットの存在にも気付かず、別の端末セットとそれ自体を相互接続する固有の能力を有していない。

集中型電話システムでは、ネットワーク内での電話セットの管理および発見は通常、中央装置によって実施される。たとえば、従来の回線交換型の時分割多重（ＴＤＭ）電話システムでは、各端末セットが、たとえば中央の呼処理装置上のポートに接続されることがある。典型的には、各端末セットは、電源投入時に発生する初期化シーケンスの一部として、それ自体の使用可能性を中央装置に告知する。中央装置は、新しい端末セットが接続されたときのかかる告知の有無について各ポートを監視し、したがって新たに追加された端末セットを「発見」することができる。

集中型のボイス・オーバ・インターネット・プロトコル（ＩＰ）すなわちＶｏＩＰ電話システムでは、これと非常に似てはいるがやや複雑化した手続きが利用されるものの、端末セットは依然として、ネットワークを介してそれ自体の使用可能性を中央の呼処理装置に告知する。当技術分野で知られているように、ＶｏＩＰは、ＩＰに基づくデータ・ネットワークを介して呼を送出する。通信は、パケット・データの形をとっており、したがって、回線交換ネットワークの場合のような固定式の接続は存在しない。通信するのは、テキスト、音声、グラフィック、あるいはビデオであってもよい。ＩＰ装置は、相互運用可能なように、Ｈ．３２３やセッション開始プロトコル（ＳＩＰ）のような標準に準拠していることがある。Ｈ．３２３標準には一般に、端末、ネットワーク装置、およびサービスの間でのマルチメディア通信がどのように発生するかが記述されている。ＳＩＰ標準は、インターネットを介するマルチメディア・セッションをセット・アップし、変更し、解体するための技術要件をカバーする。本明細書で使用する「呼」という用語は、２つのエンド・ポイント間でのマルチメディア通信を指し、また、音声電話を含む。

中央装置が回線交換型であるのかそれともパケット交換型であるのかに関わらず、新しい端末セットを発見する過程の中で、中央装置は通常、ネットワーク・アドレスの形の加入者電話番号（Ｄｉｒｅｃｔｏｒｙ Ｎｕｍｂｅｒ：ＤＮ）の割当ておよび管理を自動的に行うことになる。ＤＮは、たとえばＰＢＸの内線であってもよい。ＤＮは、個々のセットに割り当てられると、中央装置の維持しているＤＮのリストに加えられる。呼出し元の端末セットからＤＮが転送されたときに、集中型の装置が呼び出すべき物理的な端末セットの識別を判定できることが、この集中型のリストに基づいているだけであることが多い。
優先権仮出願第６０／５１８６４６号 Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）ｅｄｉｔｏｒ'ｓ ｑｕｅｕｅの、「ｄｒａｆｔ−ｉｅｔｆ−ｚｅｒｏｃｏｎｆ−ｉｐｖ４−ｌｉｎｋｌｏｃａｌ−１７．ｔｘｔ」 「Ｈｏｓｔ ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ」と題するＲＦＣ １１１２

提供されるポート数（たとえば、電話端子）および処理能力（たとえば、処理装置のタイプおよび速度）の制限の故に、集中型の装置は通常、対応できるユーザの数および提供できる呼処理能力の量に上限がある。顧客は、自身の現在の装置におけるポート数および／または呼処理に必要な能力が足りなくなると、より大規模な中央装置にアップグレードしたいと望むこともある。不都合なことに、かかるアップグレードには通常かなりのコストがかかり、足かせとなる可能性もある。

より高い処理能力に伴うコストおよびメモリが減少し続けるに従い、ネットワークに接続されるあらゆる電話セットに呼処理エンジンを含めることが、実現可能になってきている。かかるシステムでは、中央装置を排除することが望ましいかもしれない。かかる非集中型（ｄｅｃｅｎｔｒａｌｉｚｅｄ）システムは、分散型電話システムと呼ばれることもある。

不都合なことに、端末セットの発見を対象とする上述の手法は、集中型の装置が存在し得ないことから、非集中型システムには不適当である。

したがって、分散型電話システムでは、端末セットまたは他の形態のネットワーク装置の発見に関する代替的な様式が、望ましいはずである。より一般的には、分散型マルチメディア通信システムなどのピア・ツー・ピア・システム内での端末セットまたは他の形態のネットワーク装置の発見に関する様式が、望ましいはずである。

あるピアがピア・ツー・ピア・ネットワークに最初に接続するときには、そのピアは、ネットワークへのそれ自体の接続を他のピアに通知する。ピアは、他のピアからの存在通知を受信し、それらを使用してネットワーク上のピアのリストを作成することができ、このリストは、各ピアの一意の識別子によってソートすることができる。見込まれる（ｐｒｏｓｐｅｃｔｉｖｅ）ネットワーク・アドレスが、たとえばソート済みのリスト内でのピアの順序位置に基づいて選択される。衝突検査によって、見込まれるネットワーク・アドレスと、他のピアのネットワーク・アドレスとの間の衝突が解決される。各ピアは、たとえば新しいピアがそのアドレスを主張するのを防ぐために、他のピアにそれ自体のネットワーク・アドレスを周期的に通知することができる。あるピアが非アクティブ状態になったときは、それを検出した別のピアが、その切断されたピアのアドレスが既に主張されている旨を、残りのピアに周期的に通知することを開始することができる。ピアは、ボイス・オーバＩＰ電話セットでもよく、ネットワーク・アドレスは、加入者電話番号でもよい。

本発明の一態様によれば、複数のネットワーク装置のうちの１つのネットワーク装置において、存在通知を送信する工程と、１つまたは複数の他のネットワーク装置から１つまたは複数の存在通知を受信する工程と、受信された前記存在通知に基づいて、前記１つのネットワーク装置の見込まれるネットワーク・アドレスを選択する工程とを含む方法が、提供される。

本発明の他の態様によれば、第１のネットワーク装置と、第２のネットワーク装置と、少なくとも１つの他のネットワーク装置とを含むネットワークにおいて、前記第１のネットワーク装置のネットワーク・アドレスを維持する方法であって、前記第２のネットワーク装置において、前記第１のネットワーク装置の前記ネットワーク・アドレスを維持する工程と、前記第１のネットワーク装置が非アクティブ状態にあると判定されたときは、前記第１のネットワーク装置の前記ネットワーク・アドレスが主張されている旨を、前記少なくとも１つの他のネットワーク装置に通知する工程とを含む方法が、提供される。

本発明の他の態様によれば、ネットワーク装置において使用される、第１の状態と第２の状態とを含む状態マシンを維持する工程を含む方法であって、前記第１の状態は、前記ネットワーク装置が見込まれるネットワーク・アドレスを選択したことを示し、前記第２の状態は、前記ネットワーク装置が前記見込まれるネットワーク・アドレスをそれ自体のネットワーク・アドレスとして主張したことを示す方法が、提供される。

本発明の他の態様によれば、１つまたは複数の他のネットワーク装置と共に使用されるネットワーク装置であって、前記ネットワーク装置と前記他のネットワーク装置とが、累積的に複数のネットワーク装置を形成し、存在通知を送信し、前記他のネットワーク装置から１つまたは複数の存在通知を受信し、受信された前記存在通知に基づいて、前記ネットワーク装置の見込まれるネットワーク・アドレスを選択するように適合されたネットワーク装置が、提供される。

本発明の他の態様によれば、非アクティブ状態のネットワーク装置と少なくとも１つの他のネットワーク装置とを含むネットワークに接続されるネットワーク装置であって、前記非アクティブ状態のネットワーク装置の前記ネットワーク・アドレスを維持し、前記非アクティブ状態のネットワーク装置が非アクティブ状態にあると判定されたときは、前記非アクティブ状態のネットワーク装置の前記ネットワーク・アドレスが主張されている旨を、前記少なくとも１つの他のネットワーク装置に通知するように適合されたネットワーク装置が、提供される。

本発明の他の態様によれば、第１の状態と第２の状態とを含む状態マシンを維持するように適合されたネットワーク装置であって、前記第１の状態は、前記ネットワーク装置が見込まれるネットワーク・アドレスを選択したことを示し、前記第２の状態は、前記ネットワーク装置が前記見込まれるネットワーク・アドレスをそれ自体のネットワーク・アドレスとして主張したことを示すネットワーク装置が、提供される。

本発明の他の態様によれば、複数のネットワーク装置のうちの１つのネットワーク装置での実行を対象とするマシン実行可能なコードを含むマシン可読媒体であって、存在通知を送信するためのマシン実行可能なコードと、１つまたは複数の他のネットワーク装置から１つまたは複数の存在通知を受信するためのマシン実行可能なコードと、受信された前記存在通知に基づいて、前記１つのネットワーク装置の見込まれるネットワーク・アドレスを選択するためのマシン実行可能なコードとを備えるマシン可読媒体が、提供される。

本発明の他の態様によれば、非アクティブ状態のネットワーク装置と、少なくとも１つの他のネットワーク装置とを含むネットワーク内のネットワーク装置での実行を対象とするマシン実行可能なコードを含むマシン可読媒体であって、前記非アクティブ状態のネットワーク装置の前記ネットワーク・アドレスを維持するためのマシン実行可能なコードと、前記非アクティブ状態のネットワーク装置が非アクティブ状態にあると判定されたときは、前記非アクティブ状態のネットワーク装置の前記ネットワーク・アドレスが主張されている旨を、前記少なくとも１つの他のネットワーク装置に通知するためのマシン実行可能なコードとを含むマシン可読媒体が、提供される。

本発明の他の態様によれば、ネットワーク装置によって実行されたとき、前記ネットワーク装置が第１の状態と第２の状態とを含む状態マシンを維持するようになる、マシン実行可能なコードを格納するマシン可読媒体であって、前記第１の状態は、前記ネットワーク装置が見込まれるネットワーク・アドレスを選択したことを示し、前記第２の状態は、前記ネットワーク装置が前記見込まれるネットワーク・アドレスをそれ自体のネットワーク・アドレスとして主張したことを示すマシン可読媒体が、提供される。

本発明の他の諸態様および特徴は、本発明の特定の諸実施形態に関する以下の説明を添付の図面と併せて考察すれば、当業者には明らかとなるであろう。

ここで、本発明の例示的な諸実施形態を、添付の図面を参照して説明する。

概要として、中央のルーティングまたはスイッチング装置のない例示的な分散型電話システムでは、ある種の特徴が望ましいはずである。１つの望ましい特徴は、端末セットのネットワークへの初期接続時に、好ましくは、ネットワーク内の様々な端末セットの選出する各ＤＮ間の衝突を最小限に抑えようと試みることにより、各端末セットに一意のＤＮを自動的に割り当てることができる能力であるかもしれない。他の望ましいまたは義務的な特徴は、各端末セットが他の端末セットに電話をかけることができるように、ネットワークに接続されている他のあらゆる端末セットのＤＮを各端末セットが認識していることを保証することである。他の望ましい特徴は、ネットワークからの端末セットの切断が生じ、あるいは端末セットの電力の消失が生じたときにも（これらはいずれも端末セットを「非アクティブ状態」にする）、その端末セットに割り当てられたＤＮを保存することができる能力である。ＤＮを保存する動機は、（たとえば、端末セットとネットワークの間の接続障害、単純な電力の消失、または圏外への無線端末セットの移動を原因とする）ネットワークからの端末セットの一時的な切断の結果として、非アクティブ状態の端末セットのＤＮが再び割り当てられるのを防ぐためであるかもしれない。この再割当ては、どの端末セットが呼び出されたのかについて呼出し側に混乱を招く可能性がある。

これらの特徴をサポートするために、本発明の一実施形態における例示的な端末セットは（たとえば、電話セット、携帯情報端末（ＰＤＡ）、パーソナル・コンピュータ（ＰＣ）、無線端末、シン・トランク・インターフェイス（ＴＴＩ）、または他のネットワーク装置）、「購入時のままの（ｆａｃｔｏｒｙ ｆｒｅｓｈ）」（すなわち、未構成の）状態で最初にネットワークに接続するときには、ネットワーク接続通知を用いて、それ自体のネットワークへの接続をネットワーク上のその他の端末セット（それ自体の「ピア」）に通知する。ネットワーク接続通知は、端末セットに関連する一意の識別子を、たとえば媒体アクセス制御（ＭＡＣ）アドレスなどを含む。当技術分野で知られているように、ＭＡＣアドレスは、ネットワーク装置用の一意の識別子として働く、一意のハードウェア・アドレスまたはハードウェア番号である。ネットワーク接続通知は、「Ｉ＿ＡＭ＿ＨＥＲＥ」メッセージの形をとることができ、このメッセージは、（本発明の一実施形態のような場合では、少なくともその他のピアから各受信メッセージについての肯定応答が送信されない場合には）それが受信される可能性を高めるために複数回にわたって送信される。

また、新たに接続された端末セットは、他の端末セットからの存在通知（ｅｘｉｓｔｅｎｃｅ ｎｏｔｉｆｉｃａｔｉｏｎ）を受信する。存在通知は、現在ネットワーク上に所在し（すなわち、アクティブであり、ネットワークに接続されている）、あるいは以前ネットワーク上に所在した（すなわち、以前はアクティブな状態にあって接続もされていたが、今は切断状態となり、非アクティブである）端末セットの存在に関する指示（ｉｎｄｉｃａｔｉｏｎ）である。この実施形態では、存在通知は、「Ｉ＿ＡＭ＿ＨＥＲＥ」メッセージ（先に説明した）、「ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージ（以下で説明する）、または「ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージ（以下で説明する）のいずれかとすることができる。各存在通知は、上記のメッセージがそれに関して送信される端末セットの一意の識別子を含む。さらに、後者の２つのタイプのメッセージ（「ＰＥＥＲ＿ＡＳＳＥＲＴ」および「ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージ）は、既に主張されているＤＮの指示を提供し、あるＤＮを既に少なくとも１つの端末セットが主張しているネットワークに新たに接続された端末セットが参加するときにだけ、受信される。

存在メッセージからは、ネットワーク上のすべての端末セットのリスト（経路表と呼ばれる）が作成される。リスト内の端末セットは、それらの一意のネットワーク装置識別子によってソートされる。ＤＮを既に主張しているどの端末セットについても、その主張しているＤＮが、ソート済みのリスト内で示されることになる。新たに接続された端末セットは、リスト内の順序位置を有することになる。

新たに接続された端末セットは、見込まれるＤＮを選択するために、リスト内でのそれ自体の順序位置に関連するオフセットをベースＤＮに追加することができる。たとえば、ＤＮがＰＢＸの内線であるシステムにおいて、新しい端末セットが５つの端末セットのリスト内の３番目にあると仮定すると、見込まれるＤＮを２０３と（端末セットの順序位置に等しいオフセット、すなわちベースＤＮの２００に３を足したもの）決定することができる。端末セットに関連する一意の順序位置に基づいて見込まれるＤＮの選択を行うことにより、様々な端末セットが一意の見込まれるＤＮを選択することが容易になる。これは、以前に割り当てられたＤＮを有する既存の端末セットを有していないネットワークに、購入時のままの複数の端末セットが同時に参加するというシナリオを仮定している。この原理（ｒａｔｉｏｎａｌｅ）は、様々な端末セットが当初同じ見込まれるＤＮを選択することにより、衝突解決処理に時間を費やすことになり得るのを防止しようと試みることである。

次いで、新たに接続された端末セットは、それ自体の見込まれるＤＮを選択すると、それを他の各端末セットに通知する。これは、「ＤＮプローブ」と呼ばれる。新たに接続された端末セットは、（他の端末セットのうちの１つによる、そのＤＮに対する既存の主張に基づく何らかの異議（ｏｂｊｅｃｔｉｏｎ）がある場合でも）その見込まれるＤＮを主張することに他の端末セットが反対するのでなければ、その見込まれるＤＮをそれ自体のＤＮとして主張する。新たに接続された端末セットは、異議があればそれを示すのに十分な時間をその他の端末セットに与えるために、それ自体の見込まれるＤＮを主張する前に、所定の時間間隔だけ経過させてもよい。見込まれるＤＮの主張が成功したものと仮定すると、新たに接続された端末セットは、そのＤＮに対するそれ自体の主張を他の各端末セットに通知する。また、新たに接続されたセットは、端末セットが電力を消失したときにも、割当て済みのＤＮを呼び出すことができるように、その主張したＤＮを不揮発性メモリ内に格納する。経路表も格納することができる。

確立されているネットワークに新たに接続された端末セットが参加する場合は、そのネットワーク上の他の端末セットは、既にそれら自体のＤＮの選択を済ませている。この場合では、新たに接続された端末セットの選出した見込まれるＤＮが、既に既存の端末セットのうちの１つに割り当てられている可能性もある。たとえば、ソート済みの端末セットのリスト内での新たに接続された端末セットの順序位置が、リストの末尾以外である（たとえば、新しい端末セットの一意の識別子によりそれがソート済みのリストの中間付近に配置されている）場合は、新たに接続された端末セットの順序位置に関連するオフセットがベースＤＮに追加された結果として得られる見込まれるＤＮが、既存の端末セットのうちの１つのＤＮであることもある。

この可能性の点から、新たに接続された電話機は、それ自体の見込まれるＤＮを他のいずれかの端末セットに通知しようと試みる前に、まず、それ自体の経路表を参照して、その見込まれるＤＮが既にネットワーク内の他のいずれかの端末セットによって主張されているかどうかを判定する。見込まれるＤＮが既に別のセットによって主張されている場合は、新たに接続された端末セットは、その選出をいずれかのその他の端末セットに通知する前に、たとえばリスト内で見受けられる最大のＤＮに１などのオフセットを追加することによって、別の見込まれるＤＮを選択することができる。これにより、そうしない場合には新たに接続された端末セットがそれ自体の見込まれるＤＮを他の各端末セットに通知して、その他の端末セットのうちの既にそのＤＮを主張している１つの端末セットから異議を受信するだけに終わる可能性のある、ネットワーク上の不必要な通信オーバーヘッドを回避することができる。

新たに接続された端末セットは、ＤＮの主張に成功すると、そのＤＮに対するそれ自体の主張を、周期的にネットワーク上のその他の端末セットに通知する。この実施形態では、それぞれの周期的な通知は、「ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージの形をとり、これは、新たに接続された端末セットの継続的なネットワーク・プレゼンスおよびそのＤＮに対する継続的な主張を示す、「ハートビート」として働く。この通知は、ネットワーク上のその他の端末セットによって監視される。この実施形態では、周期的な通知は、（たとえば、０秒と２秒の間の）ランダムな時間間隔で発生する。端末セットからの通知を受信することなく所定の量の時間が経過した場合は、その端末セットは、非アクティブ状態になったものと推定される。周期的な通知は、そのＤＮを後に追加される端末セットがそれ自体のＤＮとして主張しようと試みるのを防止する働きもする。たとえば、別の端末セットがそのＤＮをそれ自体の見込まれるＤＮとして選択しており、他の端末セットからの何らかの異議を待っている場合に、この通知は、その端末セットによるそのＤＮの主張に対する異議として働くこともある。急送異議（Ｅｘｐｒｅｓｓ ｏｂｊｅｃｔｉｏｎ）（たとえば、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージ）を送信することもできる。

ＤＮを主張した端末セットは、ネットワークから切断されまたは電力を消失した場合は、そのＤＮに対するそれ自体の主張をネットワーク上のその他の端末セットに周期的に通知することができない可能性が高い。この場合には、（たとえば、その端末セットからの最近のＰＥＥＲ＿ＡＳＳＥＲＴメッセージが何ら存在しないことから）切断された端末セットの使用不能状態に気付いたネットワーク内の別の端末セットが介入し、切断された端末セットは非アクティブ状態にあるが、それ自体のＤＮは既に主張されている旨を、ネットワーク上のその他の端末セットに周期的に通知することを開始する。介入してきた端末セットは、便宜上「代理（ｓｕｒｒｏｇａｔｅ）」と呼ぶが、それ自体のＤＮに対するその主張をその他の端末セットに周期的に通知することに加えて、（以下で説明する「ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージの形をとる）これらの周期的な通知を送信する責任を負う。どの端末セットを非アクティブ状態の端末セットの代理にするべきかを決定するアルゴリズムを、適用することができる。非アクティブ状態の端末セットに代わって送信される代理による周期的な通知は、切断された端末セットのＤＮを後に追加された端末セットがそれ自体のＤＮとして主張しようと試みるのを防止することができる。

切断された端末セットは、後にネットワークに再接続された場合は、（それ自体の不揮発性メモリから呼び出すことのできる）それ自体のＤＮをその他の端末セットに通知することを自ら再開することができる。代理の端末セットは、再接続を検出したときは、再接続された端末セットがその責任を再び果たすようになっているので、再接続された端末セットのＤＮをその他の端末セットに通知するのを中止することができる。

図１を参照すると、本発明の一実施形態によるピアの発見を利用する、電話（ｔｅｌｅｐｈｏｎｙ）システム１０（または「電話（ｔｅｌｅｐｈｏｎｅ）システム１０」）が示されている。電話システム１０は、スイッチ２０を介してローカル・エリア・ネットワーク（ＬＡＮ）３０と接続されているＴＴＩ（Ｔｈｉｎ Ｔｒｕｎｋ Ｉｎｔｅｒｆａｃｅ：シン・トランク・インターフェイス）４０と、（端末セットの形とネットワーク装置の形のそれぞれの）複数の電話セット１００−１〜１００−Ｎとを有する。別法として、スイッチ２０は、ネットワーク・ハブに置き換えることもできる。分かりやすくするために、ここでは４つの電話セットしか示されていないが、Ｎ≧２とする、合計Ｎ個の電話セットを存在させることもでき、さらに本発明のいくつかの実施形態では、Ｎは大きな数、たとえば千単位である。シン・トランク・インターフェイス４０は、たとえば基本的なアナログまたはデジタルＴ１／Ｅ１インターフェイス、あるいは他の任意のＰＳＴＮインターフェイスであり、ローカル・セントラル・オフィスまたはＰＳＴＮ（公衆交換電話網）相互動作インターフェイスを提供し、いくつかの電話「回線（ｌｉｎｅ）」１、２、３、４と結合されている。回線１、２、３、４は、ローカル・セントラル・オフィスまたはＰＳＴＮ（図示せず）から提供される機構を表す対線（ｗｉｒｅ ｐａｉｒｓ）である。本発明のいくつかの実施形態では、複数のシン・トランク・インターフェイスを必要とする多くの回線が存在する。たとえば、ＰＳＴＮに８つの回線が必要とされる場合は、システム１０に第２のシン・トランク・インターフェイスを追加することができる。

図１のシステム１０は、従来の集中型電話システムとは異なり、分散型の呼処理を特徴としている。この分散型の呼処理は、たとえば分散型の音声メールを含めたいくつかの機能を特徴とすることもある。

図２を参照すると、図１の電話システム１０における例示的な電話セット１００−Ｘ（Ｘ＝１〜Ｎ）の部分的な回路ブロック図が、示されている。中央処理装置（ＣＰＵ）５３０、メモリ管理ユニット（ＭＭＵ）５４５、およびランダム・アクセス・メモリ（ＲＡＭ）５３５が、計算装置の基礎を提供する。この計算装置は、オーディオ信号の符号化および復号用のデジタル信号処理装置（ＤＳＰ）５２０に接続されている。ＤＳＰ ５２０は、オーディオ・インターフェイス５１０に接続されている。計算装置は、ＬＡＮおよびパーソナル・コンピュータ（ＰＣ）への接続を可能にする３ポート・スイッチ５２５にも接続されている。計算装置は、フラッシュ不揮発性メモリ５４０、赤外線（ＩＲ）インターフェイス５５０、キーパッドおよびボタン・インターフェイス５５５、液晶ディスプレイ（ＬＣＤ）コントローラ５６０、端末セット１００の標準化された拡張を可能にするパーソナル・コンピュータ・メモリ・カード国際協会（ＰＣＭＣＩＡ）インターフェイス５６５などの周辺機器のホストにも接続されている。ここでは特定のアーキテクチャが示されているが、より一般的には、以下で説明する方法を実装するのに十分な処理およびメモリ容量が使用可能であると仮定すれば、どんなパケット・ベースの（たとえば、インターネット・プロトコル（ＩＰ））電話でも使用することができる。たとえば、Ｍｉｔｅｌ社、Ｎｏｒｔｅｌ Ｎｅｔｗｏｒｋｓ社、Ａｖａｙａ社、Ｓｉｅｍｅｎｓ社、ＮＥＣ社、Ｐｉｎｇｔｅｌ社、３ＣＯＭ社などによって製造される既製のＩＰ電話（たとえば、Ｎｏｒｔｅｌ ｉ２００４、Ｓｉｅｍｅｎｓ ｏｐｔｉＰｏｉｎｔ ４１０、またはＡｖａｙａ ４６１０）を使用することもできる。

図３を参照すると、図２の電話セット１００−Ｘ上で動作するソフトウェアの機能ブロック図が示されている。このソフトウェアは通常、図２のＲＡＭ５３５内に格納され、ＣＰＵ５３０上で走り、磁気または光ディスク、テープ、チップ、あるいは別の形態の１次または２次ストレージとし得る、マシン可読媒体３２からロードすることができる。より一般的には、このソフトウェアは、汎用または専用の処理装置、ファームウェア、ハードウェア、特定用途向け集積回路（ＡＳＩＣ）、書替え可能ゲート・アレイ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：ＦＰＧＡ）、汎用または専用ロジックによって実行される、メモリ内に格納されたマシン実行可能なコードの任意の適当な組合せとして実装することができる。

システム・ディスパッチャ１２０が、呼処理モジュール７０、音声メール・モジュール８０、ダイヤル規則モジュール９０、ピア発見モジュール１１０、ディスプレイ・ハンドラ１３０、オーディオ・ハンドラ１４０、および入力ハンドラ１５０を含む様々な機能要素間の通信およびスケジューリングを行う。

呼処理モジュール７０は、呼のセット・アップおよび解体、ならびに音声チャネルのセット・アップを行うために、プロトコル・スタック６０と相互作用する。いくつかのセットにおける呼処理モジュール７０が、集中型の装置を必要としない分散型の形式で、集合的にＰＢＸと同様の呼処理機能を提供するように働く。

音声メール・モジュール８０は、呼が受信されたがユーザがそれに応答できないときに、音声メール・サービスを提供する。

ダイヤル規則モジュール９０は、電話をどのようにかけるかを制御する呼処理モジュール７０に適用する、１組のダイヤル規則を含んでいる。

ピア発見モジュール１１０は、端末セット１００−Ｘが最初にネットワークに接続されたときのピアの発見を容易にする。ピア発見モジュール１１０は、本明細書の焦点であり、以下でより詳細に説明する。

ディスプレイ・ハンドラ１３０は、情報をフォーマットしユーザに表示する責任を負う。

オーディオ・ハンドラ１４０は、呼出音、話中音、通話中着信音などのオーディオ音を再生するように、あるいはシステム・ディスパッチャ１２０からのオーディオ・メッセージを受信したときに、ネットワークからハンドセットのスピーカ（またはスピーカ・フォン）への音声チャネルに接続するように適合されている。

入力ハンドラ１５０は、キー・プレス、フック・スイッチ、ボリューム・キー、ハンズ・フリー、ミュート・ボタンなどの機能を監視し、システム・ディスパッチャ１２０にそれが取るべき適切な措置について知らせる責任を負う。

図４は、電話システム１０内の各端末セット１００−Ｘによって作成され維持される経路表２００である。経路表は、ＬＡＮ３０上に所在する他の端末セット（非アクティブ状態になった可能性のある端末セットを含む）の指示を表している。以下に記載されるように、端末セット１００−Ｘは、ネットワーク３０上の他の端末セットから受信される複数の「Ｉ＿ＡＭ＿ＨＥＲＥ」メッセージの情報、場合によっては他のタイプのメッセージ（たとえば、「ＰＥＥＲ＿ＡＳＳＥＲＴ」メッセージ）の情報も格納することによって、経路表２００を作成する。この実施形態では、経路表２００は、それによってネットワーク３０に関連するすべての端末セットの概要が示されるように、現在の端末セット１００−Ｘのエントリも含んでいる。

図４に示されるように、経路表２００は、ネットワーク３０上に所在する端末セットのそれぞれに関する、ＤＮ（列２１０）、ＭＡＣアドレス（列２２０）、ＩＰアドレス（列２３０）、装置タイプ（列２５０）、およびアクティブ・フラグ（列２９３）を含めた様々なタイプの情報を格納している。

ＤＮ（列２１０）は、加入者電話番号であり、これはＰＢＸの内線に類似するものである。列２１０内に端末セットのＤＮが示されている場合は、そのＤＮがその端末セットによって主張されているものと理解される。端末セットがＤＮを依然として主張していない場合（たとえば、それがネットワーク３０上でのそれ自体の所在を告知したばかりである場合、または見込まれるＤＮを選択したにすぎず、それを依然として決定的な形では主張していない場合）は、その端末セットについての列２１０は、空欄となる。図４では、列２１０内のＤＮが昇順で示されているが、以下で明らかとなるように、ＤＮは、ネットワークに端末セットが追加される順序および他の要因によっては、昇順以外の形にあるいは順次的な順序以外の形にすることもできる。

ＭＡＣアドレス（列２２０）は、各端末セット用の一意の識別子として働く、一意のハードウェア・アドレスまたはハードウェア番号である。以下で理解されるように、この実施形態では、ＭＡＣアドレスを、同じＤＮが異なる端末セットによって選択されたときの衝突を解決するために使用することができる。経路表２００内に示されるあらゆる端末セットのＭＡＣアドレスが、列２２０内で指定される。経路表２００では、端末セットは、ＭＡＣアドレスの昇順にソートされている。一代替実施形態では、端末セットを降順にソートすることもできる。

ＩＰアドレス（列２４０）は、たとえばＶｏＩＰ端末セットの場合の、各端末セットに割り当てられたＩＰアドレスを表している。

装置タイプ（列２５０）は、ネットワーク３０上の各ネットワーク装置のタイプの指示である。この例では、各ネットワーク装置は、端末セットである（列２５０内の「ＳＥＴ」という値で識別されている）。諸代替実施形態では、ネットワーク装置は、たとえばゲートウェイやシン・トランク・インターフェイスなど、他のタイプの装置を含むことができる。本明細書で説明されるピアの発見は、ネットワーク装置を対象に、装置タイプに関わらず実施することができる。

アクティブ・フラグ（列２９３）は、端末セットが現在アクティブであるかどうかに関する指示である。先に説明したように、端末セットは、他の端末セットに対して、それ自体が依然としてアクティブなままであることを知らせるＰＥＥＲ＿ＡＳＳＥＲＴメッセージを周期的に送信する。所定の時間間隔の間に（たとえば、各ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ間の所定の固定継続期間の３倍であって、この固定継続期間をたとえば２秒としてもよい）、端末セット１００−ＸによってＰＥＥＲ＿ＡＳＳＥＲＴメッセージが受信されない場合は、端末セット１００−Ｘの維持している経路表２００において、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージの受信されていない端末セットの状態が、非アクティブにセットされる。非アクティブ状態の端末セットがＰＥＥＲ＿ＡＳＳＥＲＴメッセージの送信を再開すると、その端末セットの状態が、アクティブにリセットされる。

図５は、本発明の一実施形態によるピアの発見中に例示的な端末セット１００−Ｘによって実装される状態マシンを示す。図５の説明上、端末セット１００−Ｘはそれぞれ、当業者に知られている様式で、電源投入および初期化プロセス中に、ネットワーク上の動的ホスト構成プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＤＨＣＰ）サーバから、あるいはｚｅｒｏｃｏｎｆ（インターネット技術特別調査委員会（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）の仕様。現時点ではＲｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）ｅｄｉｔｏｒ'ｓ ｑｕｅｕｅの、「ｄｒａｆｔ−ｉｅｔｆ−ｚｅｒｏｃｏｎｆ−ｉｐｖ４−ｌｉｎｋｌｏｃａｌ−１７．ｔｘｔ」）を使用することによって、ＩＰアドレスを取得しているものと仮定される。

端末セット１００−Ｘは、ＩＰアドレスを取得すると、その端末セット１００−Ｘがネットワーク３０上に所在していることを示す、初期の「Ｉ＿ＡＭ＿ＨＥＲＥ」状態８００に入る。この状態８００では、端末セット１００−Ｘは、ネットワーク３０上にそれ自体が所在している旨をネットワーク３０上のその他の端末セットに通知することによって、「それ自体の告知」を行い、他のネットワーク装置からネットワーク３０上にそれらが所在していることに関する通知を受信し始める。この実施形態では、端末セット１００−Ｘは、ネットワーク内の他の端末セットにマルチキャストされる、端末セット１００−ＸのＭＡＣアドレスおよびＩＰアドレスを含むＩ＿ＡＭ＿ＨＥＲＥメッセージを用いて、それ自体の告知を行う。当業者にはよく知られているように、「マルチキャスト」は、ネットワーク上の潜在的な受信元の合計数のサブセットとし得る複数の受信元に、単一のメッセージを送信することを指す。１群の受信元に同じメッセージを送信する場合は、マルチキャストは、ブロードキャスト（この場合は、そのメッセージの宛先でないものであっても、すべてのネットワーク装置がメッセージを受信する）、およびユニキャスト（２つのネットワーク装置間での、所期の受信元につき１回繰り返されるポイント・ツー・ポイント送信）よりも効率的であることもある。ＶｏＩＰ端末セットの場合には、マルチキャストは、当業者にはよく知られているはずの「Ｈｏｓｔ ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ」と題するＲＦＣ １１１２に記載のＩＰマルチキャストでよい。

端末セットは、Ｉ＿ＡＭ＿ＨＥＲＥマルチキャスト・メッセージをＮ回送信するが、ここではＮを、１以上の正の整数とする。端末セットが非常に大規模なネットワークの一部を形成する諸実施形態では、いくつかのまたは全部の端末セットに同時に電源を供給することが可能であり、したがって、ネットワーク内の各端末セットの受信バッファがそれぞれ、一時に複数のメッセージを受信することができる。本発明のいくつかの実施形態では、受信バッファがオーバーフローした場合にも、Ｉ＿ＡＭ＿ＨＥＲＥマルチキャスト・メッセージがその他の端末セットに配信されることを保証するために、各端末セットについて、Ｎは３以上である。Ｉ＿ＡＭ＿ＨＥＲＥマルチキャスト・メッセージは、（たとえば、それぞれ０秒と２秒の間の）ランダムな間隔で送信される。固定された間隔ではなくランダムな間隔でＮ個のＩ＿ＡＭ＿ＨＥＲＥメッセージを送信することにより、Ｉ＿ＡＭ＿ＨＥＲＥマルチキャスト・メッセージが１つまたは複数の端末セットによって受信されないというリスクを低減することができる。固定された間隔が使用された場合は、所与の端末セットにおいて、異なる端末セットからのＩ＿ＡＭ＿ＨＥＲＥメッセージがＮ回の送信間隔のそれぞれの間に現れる順序が、各間隔において同じ順序となることもあり、最後に到達するメッセージまで、一貫して破棄（ｄｒｏｐ）される可能性がある。ランダムな間隔でメッセージを送信すると、メッセージが１回の間隔の間に到達する順序が、別の１回の間隔の間に到達する順序とは異なることがある。したがって、１つ（または複数）のメッセージが破棄される１つ（または複数）の端末セットは、間隔によっては異なることがあり、特定の端末セットからのＮ個のＩ＿ＡＭ＿ＨＥＲＥメッセージの１つが受信される可能性が、非常に高くなり得る。

上記の記載は、メッセージの受信に成功すると明示的な肯定応答が送信されるプロトコルと比較して、全体のメッセージ・トラフィックを低減させ得る点で好まれることがある、個々のメッセージの受信に対して明示的には肯定応答が返されないメッセージング・プロトコルを想定していることに留意されたい。

また、初期状態８００の間に、端末セット１００−Ｘは、経路表２００（図４）を構築しまたは更新するのに必要な情報を含む、ネットワーク３０内の他の端末セットからのメッセージを待つ。

状態マシンは、３つのイベントのいずれかが発生すると、初期状態８００からＤＮプローブ状態９００に移行する。第１のイベントは、端末セット１００−Ｘが他の端末セットからのＩ＿ＡＭ＿ＨＥＲＥメッセージを受信し、それ自体の経路表２００を構築するのに十分な時間を与えることが企図された、所定の時間間隔の満了である。第２のイベントは、現在の端末セット１００−Ｘが既にそれ自体の不揮発性メモリ内に格納されたＤＮを有しているとの判定があることである。第３のイベントは、現在の端末セット１００−ＸのＭＡＣアドレスと一致するＭＡＣアドレスを有するＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージが受信されることであり、これは、現在の端末セット１００−Ｘがアクティブ状態に復帰し、それに代わってそれ自体の代理が送信したＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを受信したところである、という状況を反映している。

ＤＮプローブ状態９００では、端末セット１００−Ｘは、見込まれるＤＮを選択し、他の端末セットに対して、セット１００−Ｘがその見込まれるＤＮを主張することに対してそれらの他の端末セットのいずれかが何らかの異議を有しているかどうかを判定するための、Ｍ個のＤＮ＿ＰＲＯＢＥマルチキャスト・メッセージを送信するが、ここではＭを、１以上の整数とする。場合によっては２個以上のＤＮ＿ＰＲＯＢＥメッセージを送信する原理は、メッセージの少なくとも１つのコピーを、ネットワーク上のその他の端末セットのそれぞれが受信する可能性を高めることである。この実施形態では、ＤＮ＿ＰＲＯＢＥメッセージは、送信元の端末セットのＭＡＣアドレスおよびＩＰアドレス、ならびに送信元の端末セットによって選択された見込まれるＤＮを含む。ＤＮ＿ＰＲＯＢＥメッセージに対する他の端末セットからの応答がない場合は、何らかの異議を有する他の端末セットはないものと仮定され、端末セット１００−Ｘは、そのＤＮをそれ自体のＤＮとして主張する、ＤＮアサート状態７００に入る。これは、現在の端末セットの見込まれるＤＮが全く新しく選択されたＤＮであるのか、それとも不揮発性メモリから呼び出された永続的なＤＮであるのかに関わらず行われる。

ＤＮアサート状態７００は、端末セット１００−ＸがＤＮの主張に成功した、定常状態を表している。この状態では、端末セット１００−Ｘは、その端末セットがアクティブなままであり、「健康状態（ｈｅａｌｔｈｙ）」にある旨の周期的な標識（ｉｎｄｉｃａｔｏｒ）となるＰＥＥＲ＿ＡＳＳＥＲＴマルチキャスト・メッセージを、ネットワーク内のその他の端末セットに対して周期的に送信する。この実施形態におけるＰＥＥＲ＿ＡＳＳＥＲＴメッセージは、ＩＰアドレスと、ＭＡＣアドレスと、主張済みのＤＮとを含む。ＤＮアサート状態７００において、主張済みのＤＮと別の端末セットによって主張されたＤＮとの間に衝突が存在することが発見された場合は、状態マシンは、ＤＮプローブ状態９００に戻る。衝突が存在することが発見され得る状況の１つの例は、ネットワークが（たとえば、通常は地理的に離れた位置にある２つのサブ・ネットワークを相互接続している、仮想私設ネットワーク（ＶＰＮ）に障害が発生したときに）２つのサブ・ネットワークにセグメント化される場合であるかもしれない。ネットワークがセグメント化されても、端末セット同士を別々のセグメントに接続し、異なるサブ・ネットワーク上の異なる端末セットが同じＤＮを主張できるようにすることが可能である。このネットワークのセグメント同士が再接続されたときに、衝突が存在することが発見され得る。その場合には、衝突の解決が必要である。

図６は、図５の初期状態８００における端末セット１００−Ｘの動作を示す流れ図である。まず、現在の端末セット１００−ＸのＤＮが存続しているかどうかが判定される（８１０）。この実施形態では、ＤＮの主張を済ませるために、端末セット１００−Ｘがそれ以前に初期化状態８００、ＤＮプローブ状態９００、およびＤＮアサート状態７００を経由している場合に、ＤＮが存続していることになる。この場合では、主張済みのＤＮは、たとえばフラッシュ・メモリなどの不揮発性メモリ内に格納されていることになる。ＤＮを不揮発性メモリ内に格納する目的は、端末セット１００−Ｘが、たとえば偶発的な電力消失またはネットワーク３０からの切断の故に、非アクティブ状態になった場合にも、アクティブ状態に復帰したときはそのＤＮを再び主張することができるように、ＤＮを保存するためである。

８１０で、端末セット１００−ＸのＤＮが存続していると判定された場合は、状態マシンは、ＤＮプローブ状態９００に移行する（９０５）。この場合では、ネットワーク上のその他の端末セットが現時点で、端末セット１００−Ｘが非アクティブ状態にあると見なしている場合にも、その他の端末セットは既に、ネットワーク上での端末セット１００−Ｘの所在を示す通知を受けていることが想定されている。

一方、８１０で、端末セットが永続的なＤＮを有していないと判定された場合、それは、端末セット１００−Ｘが（ＤＮおよび経路表２００に関して）構成が依然としてなされていない「購入時のままの」状態にあることを示す。この場合には、Ｉ＿ＡＭ＿ＨＥＲＥメッセージのＮ個のインスタンスのうちのいくつのインスタンスが送信されたのかを追跡するのに使用されるカウンタが、ゼロに初期化される（８１２）。次いで、ランダム・タイマが０秒と２秒の間にセットされ、第２のタイマが２秒にセットされる（８１４）。第２のタイマについての２秒という間隔は、経路表２００（図４）を作成するための他のネットワーク装置からのメッセージを受信するのに十分な時間が与えられることを保証するものである。もちろん、他の諸実施形態では、この継続期間が異なることもある。カウンタが増分され（８１６）、端末セットは、メッセージが受信されるのを待つ、「メッセージ待ち」状態（８２０）に入る。

メッセージ待ち状態の間にランダム・タイマが満了した場合は、Ｉ＿ＡＭ＿ＨＥＲＥマルチキャスト・メッセージがその他の端末セットに送信され（８２２）、端末セット１００−Ｘは、メッセージ待ち状態（８２０）に戻る。

８２０で、ネットワーク内の他のいずれかの端末セットから受信されたどのメッセージも、タイプが検査される（８４０）。

受信メッセージが、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージである場合は、（初期状態８００ではこのメッセージが受信されていないはずなので）端末セットは、そのＤＮ＿ＣＯＮＦＬＩＣＴメッセージを無視し、状態マシンは、メッセージ待ち状態（８２０）に戻る。

受信メッセージが、別の端末セットから送信されたＩ＿ＡＭ＿ＨＥＲＥメッセージである場合は、受信されたＩ＿ＡＭ＿ＨＥＲＥメッセージからのデータ（たとえば、ＭＡＣアドレスおよびＩＰアドレス）が、経路表２００に追加される。

受信メッセージが、別の端末セットから送信されたＰＥＥＲ＿ＡＳＳＥＲＴメッセージまたはＤＮ＿ＰＲＯＢＥメッセージである場合は、ＰＥＥＲ＿ＡＳＳＥＲＴまたはＤＮ＿ＰＲＯＢＥメッセージ内のデータを、経路表２００に追加することができる（これらのメッセージは、以下でより詳細に説明する）。

受信メッセージが、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴである場合は、そのＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているデータを使用して、経路表２００を更新することができる（８７０）（たとえば、送信元の端末セットがそれ以前に経路表２００内に存在しない場合は、それを追加することができる）。その後、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のＭＡＣアドレスが、ローカルのＭＡＣアドレス（すなわち、現在の端末セット１００−ＸのＭＡＣアドレス）と比較される（８７２）。

それらが同じものであることが発見された場合、それは、現在の端末セット１００−Ｘが非アクティブ状態の期間後、アクティブ状態に復帰し、端末セット１００−Ｘに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信している別の端末セットからメッセージを受信したところである、という状況を表す。この場合には、端末セットは、ＤＮプローブ状態（９０５）に移行する。

一方、受信されたＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のＭＡＣアドレスが、ローカルのＭＡＣアドレスとは異なる場合は、端末セットは、メッセージ待ち状態に戻り、さらなるメッセージを待つ（８２０）。

メッセージ待ち状態の間に第２のタイマが満了した場合は、カウンタが最大値Ｎに達したかどうかが評価される（８８０）。

この評価によってカウンタの値がＮを超えていないことが判明した場合、それは、Ｎ個未満のＩ＿ＡＭ＿ＨＥＲＥメッセージが送信されたことを示す。この場合には、ランダム・タイマおよび第２のタイマがリセットされ（８１４）、カウンタの値が増分された後（８１６）、待ち状態（８２０）に戻る。

一方、８８０の評価によってカウンタの値がＮと等しいことが判明した場合、それは、Ｎ個のＩ＿ＡＭ＿ＨＥＲＥメッセージが送信されたことを示す。この場合には、端末セット１００−Ｘの状態マシンは、ＤＮプローブ状態（９０６）に移行する。

図７は、図５のＤＮプローブ状態９００における端末セット１００−Ｘの動作を示す流れ図である。図７に示されるように、ＤＮプローブ状態９００を指す２つのエントリ・ポイントが存在する。第１のエントリ・ポイントは、初期状態８００からの９０５にあり、現在の端末セットが非アクティブ状態の期間後に、不揮発性メモリからそれ自体のＤＮを呼び出している状況を表している。第２のエントリ・ポイントは、やはり初期状態８００からのものであるが、９０６にあり、端末セット１００−Ｘがそれ以前にはＤＮを主張していない状況を表している。後者の場合では、９１０で、端末セットが見込まれるＤＮを選択する（前者の場合では、見込まれるＤＮは呼出し済みのＤＮとなる）。

端末セット１００−Ｘは、見込まれるＤＮを選択するために、経路表２００（図４）における（ソート済みの）端末セットのリスト内でのそれ自体の順序位置を判定する（９１０）。たとえば、端末セット１００−Ｘがリストの最初にある場合は、選択対象の見込まれるＤＮを、たとえばベースＤＮの２００に１（それ自体の順序位置）を足し、見込まれるＤＮを２０１とすることができる。端末セットに関連する一意の順序位置に基づいて見込まれるＤＮの選択を行うことにより、以前に割り当てられたＤＮを有する既存の端末セットを有していないネットワークに、購入時のままの複数の端末セットが同時に参加するというシナリオにおいて、各端末セットが一意の見込まれるＤＮを選択することが容易になる。

確立されたネットワークに端末セット１００−Ｘが参加する場合に発生し得る潜在的なＤＮの衝突が起きないようにするために、９１０で、端末セット１００−Ｘは、それ自体の経路表２００（図４）を参照して、選択対象の見込まれるＤＮが既に別の端末セットに割り当てられているかどうかを判定することもできる。見込まれるＤＮが既に割り当てられている場合は、新たに接続された端末セットは、たとえばリスト内で見受けられる最大のＤＮに１などのオフセットを追加することによって、別の見込まれるＤＮを選択することができる。

９１０に続いて（またはエントリ・ポイント９０５から）、送信されたＤＮ＿ＰＲＯＢＥメッセージのインスタンスの数を追跡するためのカウンタが、初期化され（９１２）、増分される（９１４）。ＤＮ＿ＰＲＯＢＥメッセージのインスタンスが送信され、ＤＮ＿ＰＲＯＢＥメッセージの各インスタンス間の（固定されたまたはランダムな）時間間隔のカウント・ダウンを行うのに使用されるタイマが、セットされる（９１６）。次いで、端末セット１００−Ｘは、「イベント待ち」状態（９２０）に入る。

ある端末セットが、同様にプローブ状態にある別の端末セットと同じＤＮを選択した場合、その端末セットは、ネットワーク上でプローブされている両方の装置のＭＡＣアドレスを調べ、衝突が起きていることを知ることになる。一実施形態では、同じＤＮを有する端末セット間の衝突が存在する場合は、最も低いＭＡＣアドレスを有する端末セットがそのＤＮを保持し、その他の端末セットは、別のＤＮを取得しなければならない。

ＤＮプローブ状態９００を指すＤＮアサート状態７００からの別のエントリ・ポイント（９０８）も存在することに留意されたい。このエントリ・ポイント９０８は、端末セット１００−Ｘの主張するＤＮと、ネットワーク内のその他の端末セットの１つまたは複数によって望まれるまたは主張されているＤＮとの間に衝突が存在していることが発見された状況を表している。かかる場合では、動作は、上述した９１０から開始する。

イベント待ち状態（９２０）からタイマが満了した場合は、端末セット１００−Ｘは、所望の数であるＭ個のＤＮ＿ＰＲＯＢＥメッセージが既に送信されているかどうかを確認する（９８０）。Ｍ個のＤＮ＿ＰＲＯＢＥメッセージが既に送信されていると判定された場合は、端末セットは次に、見込まれるＤＮが不揮発性メモリ内のＤＮから呼び出されたものかどうかを判定する（９８２）。９８２の判定が肯定的になされた場合は、状態マシンは、７０７を経由してＤＮアサート状態７００に移行し、そうでない場合は、７０５を経由してＤＮアサート状態７００に移行する。

あるいは、９８０で、Ｍ個未満のＤＮ＿ＰＲＯＢＥメッセージが送信されていると判定された場合は、動作は９１４に戻る。

イベント待ち状態（９２０）から、メッセージが別の端末セットから受信された場合は、さらなる動作は、受信メッセージのメッセージ・タイプに依存し、これは９３０で確認される。

メッセージ・タイプが、Ｉ＿ＡＭ＿ＨＥＲＥメッセージを示す場合は、端末セットは、そのデータがまだ所在していなければ、Ｉ＿ＡＭ＿ＨＥＲＥメッセージ内に含まれているデータを経路表２００に追加した後（９３２）、イベント待ち状態（９２０）に戻る。

メッセージ・タイプが、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを示す場合は、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージからのＤＮが、ローカルのＤＮ（すなわち、選択済みの見込まれるＤＮ）と比較される（９３４）。これらのＤＮが一致した場合、それは、端末セット１００−Ｘが暫定的に選択したＤＮを、別の端末セットがアサートしようとしている状況を表す。この場合には、動作は９１０に戻る。一方、これらのＤＮが一致しない場合は、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信した端末用のエントリが既に存在していれば、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているデータを用いて経路表２００が更新され、そうではなく、上記のエントリがまだ存在していなければ、これを作成するために、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているデータが経路表２００に追加される（９３２）。

メッセージ・タイプが、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージの受信された旨を示す場合は、エントリがまだ存在していなければ、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているデータが経路表２００に追加され、そうではなく、エントリが存在しているならば、上記のデータを用いて経路表２００が更新される（９４０）。次いで、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のＭＡＣアドレスが、端末セット１００−ＸのＭＡＣアドレスと比較される（９４２）。

これらのＭＡＣアドレスが異なる場合は、端末セット１００−Ｘは、イベント待ち状態（９２０）に戻る。

あるいは、これらのＭＡＣアドレスが同じものである場合、それは、現在の端末セット１００−Ｘが非アクティブ状態の期間後、アクティブ状態に復帰し、端末セット１００−Ｘに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信している別の端末セットからメッセージを受信したところである、という状況を表す。この場合には、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のＤＮと、現在プローブされているＤＮ（すなわち、選択済みの見込まれるＤＮ）とのさらなる比較が行われる（９４４）。

これらのＤＮが一致しない場合、それは、端末セット１００−Ｘが現在、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内で指定されたＤＮとは異なるＤＮをプローブしている、という状況を表す。これは、端末セット１００−Ｘが非アクティブ状態にあった間に、端末セット１００−Ｘの不揮発性メモリ内に格納されていた永続的なＤＮがクリアされ、あるいは破損した場合に発生し得る。この場合には、以前に主張した別のＤＮを端末セット１００−Ｘがプローブするのを防ぐために、選択済みの見込まれるＤＮが、メッセージからのＤＮにリセットされ（９４６）、動作が９１２に戻り、その結果、端末セット１００−Ｘは、以前に主張したそれ自体のＤＮをプローブするための措置を取ることになる。

あるいは、（９４４で）これらのＤＮが一致することが発見された場合、それは、端末セット１００−Ｘが現在、ＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内で指定されたのと同じＤＮをプローブしている、という状況を表し、そのＤＮは、端末セット１００−Ｘが非アクティブ状態にあると判定される前に主張したＤＮであるはずである。この場合には、動作はイベント待ち状態（９２０）に戻る。

メッセージ・タイプが、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージの受信された旨を示す場合、それは、そのプローブ中の見込まれるＤＮに対して別の端末セットが異議を示している、という状況を表している可能性がある。この場合には、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージ内のＤＮと、現在プローブされているＤＮとの比較が行われる（９５０）。

これらのＤＮが一致しない場合は、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージに関するさらなるアクションは取られず、動作はイベント待ち状態（９２０）に戻る。ＤＮ＿ＣＯＮＦＬＩＣＴメッセージがマルチキャストされた場合、それは、別の端末セットに宛てられたＤＮ＿ＣＯＮＦＬＩＣＴメッセージが無視されることを表す。ＤＮ＿ＣＯＮＦＬＩＣＴメッセージがユニキャストされた場合、それは、異なる端末セットからの２つのＤＮ＿ＣＯＮＦＬＩＣＴメッセージのうち、１番目のＤＮ＿ＣＯＮＦＬＩＣＴメッセージが受信されたことから、先にプローブしたものとは異なるＤＮを現在の端末セットがプローブし始めているので、２番目のメッセージが受信されても無視されることになる、という状況を表している可能性がある。

あるいは、９５０で、これらのＤＮが一致することが発見された場合、それは、現在の端末セット１００−Ｘに見込まれる形で選択されたＤＮに対して別の端末セットが異議を示している、という状況を表す。この場合には、別の見込まれるＤＮを選択しプローブできるように、動作は９１０に戻る。

メッセージ・タイプが、ＤＮ＿ＰＲＯＢＥメッセージの受信された旨を示す場合は、現在の端末セット１００−Ｘがそれ自体の選択済みの見込まれるＤＮをプローブするのとほぼ同じ様式で、別の端末セットが、選択済みの見込まれるＤＮをプローブすることになる。この別の端末セットの見込まれるＤＮ（これは入力側のＤＮ＿ＰＲＯＢＥメッセージ内で示される）が、ローカルで選択された見込まれるＤＮと比較される（９６０）。

これらのＤＮが一致しない場合は、入力側のＤＮ＿ＰＲＯＢＥメッセージに関するさらなるアクションは取られず、動作はイベント待ち状態（９２０）に戻る。

あるいは、９６０で、これらのＤＮが一致することが発見された場合、それは、現在の端末セット１００−Ｘと同じＤＮを別の端末セットがプローブしていることを意味する。この場合には、それらの見込まれるＤＮの間に衝突が存在する。この実施形態では、かかる衝突は、各端末セットの一意のＭＡＣアドレスに基づいて解決される。特に、最も低いＭＡＣアドレス（「最下位アクティブＭＡＣ（ｌｏｗｅｓｔ ａｃｔｉｖｅ ＭＡＣ）」、すなわちＬＡＭ）を有する端末セットが、上記のＤＮを主張することを許可され、その他の端末セットは、別のＤＮを選択することになる。これと等しく有効な他の衝突解決スキームを適用できることが、理解されるであろう。たとえば、一代替実施形態では、最上位アクティブＭＡＣ（ｈｉｇｈｅｓｔ ａｃｔｉｖｅ ＭＡＣ）が上記のＤＮを主張するのを許可してもよい。選出したスキームの詳細は、各端末セットにおいてそれが一貫して適用される限り、重要でない。

したがって、有効な衝突解決スキームに従い、ＤＮ＿ＰＲＯＢＥメッセージ内のＭＡＣアドレスが、ローカルのＭＡＣアドレスと比較される（９６２）。ＤＮ＿ＰＲＯＢＥメッセージ内のＭＡＣアドレスが、ローカルのＭＡＣアドレスよりも低い値である場合は、その他の端末セットがそのＤＮを主張することを許され、現在の端末セットは、別の見込まれるＤＮを選択するために９１０に戻る。そうでない場合は、端末セットは、ＤＮ＿ＰＲＯＢＥメッセージを無視し、イベント待ち状態（９２０）に戻り、それにより、それ自体の見込まれるＤＮを有効な形で維持する。

図８は、図５に示されるＤＮアサート状態における端末セット１００−Ｘの動作を示す流れ図である。先に説明したように、永続的なＤＮを有していない端末セットが、ＤＮプローブ状態９００からこの状態（７０５）に移行することもある。この場合には、端末セット１００−Ｘはまず、見込まれるＤＮがＤＮプローブ状態９００においてプローブされたばかりであると仮定する（７１０）。その後、マルチキャストＰＥＥＲ＿ＡＳＳＥＲＴメッセージが、ネットワーク上の他の端末セットに送信される（７１２）。

あるいは、永続的なＤＮを有する端末セットが、ＤＮプローブ状態９００から移行してくることもあり（７０７）、その場合は、動作が７１２から始まる。

７１２に続いて、タイマが、０秒と２秒の間のランダムな時間間隔にセットされる（７１４）。次いで、「メッセージ待ち」状態（７２０）において、端末セット１００−Ｘは、メッセージが受信されまたはタイマが満了するのを待つ。

タイマが満了した場合は、動作は７１２に戻り、別のマルチキャストＰＥＥＲ＿ＡＳＳＥＲＴメッセージが送信される。

ＤＮ＿ＣＯＮＦＬＩＣＴメッセージが受信された場合は、端末セットは、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージ内に含まれているＤＮがローカルのＤＮと衝突するかどうかを検証する（７３２）。

ＤＮ＿ＣＯＮＦＬＩＣＴメッセージ内に含まれているＤＮがローカルで主張されたＤＮと一致すると判定された場合、それは、ネットワーク上の重複したＤＮを原因とする衝突を示す。この場合には、衝突の生じているリモートの端末セットがアクティブであるかどうかがさらに評価される（７３３）。

リモートのセットがアクティブであることが発見された場合、およびこの有効な衝突解決スキーム（すなわち、最下位アクティブＭＡＣアドレスが優先される）によって、現在の端末セットがその主張しているＤＮを保持すべきであることが示された場合は（７３４）、動作は７１２に戻り、その結果、端末セットから直ちに別のＰＥＥＲ＿ＡＳＳＥＲＴメッセージが送信されることになる。

一方、７３４で、現在の端末セットがその主張しているＤＮを保持すべきではないと判定された場合は、ＤＮ＿ＣＯＮＦＬＩＣＴメッセージ内のデータを用いて経路表２００（図４）が更新される（７３５）。具体的には、衝突の生じているＤＮを有する端末セットを、それ自体のＤＮと共に経路表２００に追加することができる。これは、現在の端末セット１００−Ｘが後に選択した見込まれるＤＮが、衝突の生じるＤＮと偶然一致することになった際には、その見込まれるＤＮを経路表２００内のＤＮと突き合わせてチェックすることによって、衝突が明らかになるようにするものである。

その後は、どの衝突警報も非アクティブ化され（７３６）、端末セット１００−Ｘは、ＤＮプローブ状態９００に移行する（９０８）。衝突警報は、ＤＮの衝突に関する通知であり、この通知は、本発明のいくつかの実施形態ではシステム管理者へと送信されることもある。衝突警報は通常、システム管理者が手動でＤＮを既存の端末セットの主張しているＤＮにリセットした場合にだけ発生する。

７３３で、リモートの端末装置が非アクティブ状態にあると判定された場合は、どのＤＮの現在の衝突警報も非アクティブ化され（７３６）、端末セットは、ＤＮプローブ状態９００に移行する（９０８）。

再びメッセージ待ち状態７２０を参照すると、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージが受信された場合、およびＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のＤＮが、経路表２００内の１つまたは複数の非アクティブ状態の端末セットのＤＮと等しい場合、それは、現在の端末セット１００−Ｘが非アクティブ状態の端末セットに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信する必要があり得る、という状況を表す。この状況は、たとえばネットワークが、１つのサブ・ネットワーク上の端末セットが別のサブ・ネットワーク上の端末セットを非アクティブ状態にあると見なすような、２つのサブ・ネットワークにセグメント化された場合に発生する可能性がある。１つのサブ・ネットワーク上の端末セットが、別のサブ・ネットワーク上にあるそれ自体の代理がそれに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信している間に、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信することもある。サブ・ネットワーク同士が再接続された際に、代理は、依然として非アクティブであると信じている端末セットからのＰＥＥＲ＿ＡＳＳＥＲＴを受信することもある。

現在の端末セット１００−Ｘが非アクティブ状態の端末セットに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信することになるかどうかの判定は、非アクティブ状態のピアに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信する責任をどの１つ（または複数）の端末セットが負うかを判定する有効なスキームに基づいている。この実施形態における有効なスキームでは、所与の非アクティブ状態のピアにつき唯一の端末セットにだけ上記の責任を割り当てる（場合によっては、同じ端末セットが複数の非アクティブ状態のピアの責任を負うこともある）。所与の任意の非アクティブ状態のピアの代わりにＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信する責任を、唯一の端末セットにだけ負わせる原理は、重複したＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージが不必要に送信されることを避けるためである。かかるスキームについては、非アクティブ状態の端末セットを検出するのに必要とされる時間よりも長い期間の間、各端末セットがその初期状態８００（図５）内に留まることを保証することが望ましい。
この有効なスキームを、以下の表１に示す。

表１の最初の２つの列が、図４の経路表２００内で維持されている、「代理」ピア（すなわち、他の非アクティブ状態のピアに代わってＩＮＡＣＴＩＶＥ＿ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信する責任を負うピア）の判定に関連する情報のサブセットを表している。表１内の各行が、最初の列において識別される仮想的なネットワーク内のネットワーク装置を表している。表１のネットワーク装置は、経路表２００内のＭＡＣアドレスなど、何らかの一意の識別子によってソートされることが理解される。表１の２番目の列には、各ネットワーク装置に関するアクティブまたは非アクティブの状態が示されている。

この有効なスキームでは、代理と非アクティブ状態のネットワーク装置との間に挟まれるアクティブ状態のネットワーク装置がリスト内に存在しない表１において、アクティブ状態のネットワーク装置は、その装置の次にくる（すなわち、より低い行にある）それぞれの非アクティブ状態のネットワーク装置の代理として働く。たとえば、表１に示されるように、ネットワーク装置Ｅがネットワーク装置ＦおよびＧの代理として働くのは、それらの装置がいずれも非アクティブ状態にあり、装置Ｅの次にきており、それらの装置と装置Ｅとの間に挟まれる他のアクティブ状態の装置がないからである。

非アクティブ状態のネットワーク装置が、ソート済みのリスト内における最初のアクティブ状態のネットワーク装置よりも前にある場合（たとえば、ネットワーク装置Ａと同様の場合）は、ソート済みのリスト内における最後のアクティブ状態のネットワーク装置（ネットワーク装置Ｈ）が、その代理として働くことになる。

諸代替実施形態においては、代理を割り当てるための他のスキームを使用することもできることが理解されるであろう。たとえば、１つの代替スキームでは、非アクティブ状態の装置の代理として、経路表内でそれよりも後にくる装置ではなく、それよりも前にあるアクティブ状態のネットワーク装置を割り当てることができる。別のスキームでは、ネットワーク装置は、表内のそれと隣り合うすべての非アクティブ状態の装置の代理として働くことができるが、本明細書で使用する「隣り合う」という用語は、経路表内のある代理のすぐ上にある、あるいはすぐ下にある、隣接した複数の非アクティブ状態のネットワーク装置を含む。後者のスキームでは、非アクティブ状態の各ネットワーク装置は、２つの代理を有することになる。いくつかの実施形態では、このレベルの冗長性が望ましいこともある。

再び図８を参照すると、７３８に続いて、端末セット１００−Ｘは、受信されたＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているＤＮがローカルで主張されたＤＮと一致するかどうかを検証する（７４０）。これらのＤＮが一致した場合は、先に説明したように、動作は７３４に進む。これらのＤＮが一致しない場合は、端末セット１００−Ｘは、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内のデータを経路表に追加し、あるいはそれを使用して表内の関連するエントリを更新する（７４１）。

次に、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージ内に含まれているＤＮが、現在の端末セット１００−Ｘがその代理として働いている非アクティブ状態のエントリのＤＮと一致するかどうかが評価される（７４２）。この評価が肯定的になされた場合は、ＤＮの衝突を示すマルチキャスト・メッセージとしてＤＮ＿ＣＯＮＦＬＩＣＴメッセージが送信された後（７４６）、別のメッセージを待つ７２０に戻る。７４２の評価が否定的になされた場合は、端末セット１００−Ｘは直ちに、別のメッセージを待つ７２０に戻る。

メッセージ待ち状態７２０の間にＩ＿ＡＭ＿ＨＥＲＥメッセージが受信された場合は、端末セット１００−Ｘは、Ｉ＿ＡＭ＿ＨＥＲＥメッセージからのデータを用いて、そのメッセージの発信元の端末セットに対応する経路表２００（図４）内のエントリの追加または更新を行い（７５０）、次いで７６２（以下で説明する）に進む。

７２０で、ＤＮ＿ＰＲＯＢＥメッセージが受信された場合は、この端末セットは、ＤＮ＿ＰＲＯＢＥメッセージ内のＤＮをローカルで主張されたＤＮと比較する（７６０）。これらのＤＮが一致した場合、それは、現在の端末セット１００−Ｘがそれ自体の見込まれるＤＮとして主張しているＤＮを別の端末セットが選択している、という状況を表す。この場合には、別の端末セットが暫定的に選択したＤＮが既に主張されている旨を、その別の端末セットに効果的な形で通知するために、動作は、直ちにマルチキャストＰＥＥＲ＿ＡＳＳＥＲＴメッセージを送信する７１２に戻る。

７６０の比較によってこれらのＤＮが一致しないことが示された場合は、端末セット１００−Ｘは、経路表２００を参照して、ＤＮ＿ＰＲＯＢＥメッセージ内に含まれているＤＮが非アクティブ状態の端末セットのＤＮと一致するかどうかを判定する（７６２）。ＤＮ＿ＰＲＯＢＥメッセージ内に含まれているＤＮが非アクティブ状態の端末セットと一致する場合は、（上述の有効なスキームを使用すると）現在の端末セットがその非アクティブ状態の端末セットの代理であるものと仮定され、ＤＮ＿ＰＲＯＢＥメッセージの発信元の端末セットにＩＮＡＣＴＩＶＥ＿ＡＳＳＥＲＴ＿ＭＥＳＳＡＧＥメッセージが送信されるその後、動作は別のメッセージを待つ７２０に戻る。７６２で実施された参照によってＤＮ＿ＰＲＯＢＥメッセージの発信元がアクティブであることが示された場合は、端末セット１００−Ｘは直接、別のメッセージを待つ７２０に戻る。

有利なことに、図５の状態マシンを実装している複数の端末セットがネットワークに接続され、上述した動作を行って定常状態（すなわち、ＤＮアサート状態７００）に到達したときは、端末セット間のどのようなＤＮの衝突も人間の介入する必要なしに自動的に解決され、それぞれの端末セットがＤＮを自動的に選択していることになる。さらに、各端末セットは、それぞれが他の任意の端末セットのＤＮをダイヤルすれば、すぐにその端末セットを呼び出すことが可能になるのに十分な他の情報（たとえば、ＩＰアドレス）と対にされた、ネットワーク上の他のあらゆる端末セットのＤＮを含む、ローカルの経路表２００を自動的に作成していることになる。さらに、端末セットが非アクティブ状態になった場合にも、それがネットワークに再接続されたときは、その端末セットのＤＮが存続していることになる。

上記の実施形態では、ネットワーク上のある端末セットがネットワーク上の他の端末セットにデータを送信し、各端末セットが経路表を構築することを可能にする、プッシュ・システムに言及している。経路表は、ＰＥＥＲ＿ＡＳＳＥＲＴメッセージを周期的な間隔で送信する端末セットによって維持される。本発明のいくつかの実施形態では、端末セットなどのネットワーク装置が、たとえばネットワーク上の他のネットワーク装置をポーリングして経路情報を取得する、プル・システムが存在する。

図９を参照すると、本発明の他の実施形態による、分散型ネットワーク内でのピアの発見の方法が示されている。たとえば、電源投入されたときにネットワーク上で使用可能になったネットワーク装置は、たとえばＤＮなど、それ自体およびネットワーク上の他のネットワーク装置についての経路情報を必要とする。まず、ネットワーク装置は、ネットワーク上に所在する少なくとも１つの他のネットワーク装置のうちのどのネットワーク装置に経路情報を送信すべきかを識別する（１１１０）。本発明のいくつかの実施形態では、１１１０で、ネットワーク上の他のネットワーク装置に対して、経路情報を送信すべき他のネットワーク装置に関する標識を要求するメッセージが送信される。この標識は、たとえばタイムスタンプでも、ＭＡＣアドレスでもよい。他の各ネットワーク装置はそれぞれ、それら自体の標識を上記のネットワーク装置に送信し、上記のネットワーク装置は、その標識を受信すると、これを使用して、他のどのネットワーク装置に経路情報を送信すべきかを判定する。たとえば、いくつかの実施形態では、この標識はタイムスタンプであり、経路情報を送信する対象として、最新のタイムスタンプを有するネットワーク装置が選択される。

次に、ネットワーク装置は、経路情報を送信すべき他のネットワーク装置に対して、経路情報を要求するメッセージを送信する（１１２０）。この要求を受信したネットワーク装置は、他のネットワーク装置についての経路情報を含む経路表を有しており、要求を行ったネットワーク装置についての経路情報を判定する（１１３０）。特に、本発明のいくつかの実施形態では、要求を行ったネットワーク装置のＤＮが選択される。この要求を受信したネットワーク装置は、その他のネットワーク装置および要求を行ったネットワーク装置についての経路情報を送信する（１１４０）。要求を行ったネットワーク装置は、その経路情報を受信し記憶する（１１５０）。

本発明のいくつかの実施形態では、要求を行ったネットワーク装置についての経路情報は、１１３０で判定される代わりに、ステップ１１５０で、要求を行ったネットワーク装置が経路情報を受信したときに判定される。さらに、本発明のいくつかの実施形態では、１１１０は、２つ以上のステップで実施される。第１のステップでは、ネットワーク装置は、どのネットワーク装置がネットワーク上にあるかを判定するために、ネットワーク上のアドレスをポーリングする。第２のステップでは、ネットワーク装置は、他のネットワーク装置に対して、標識を要求するメッセージを送信する。第３のステップでは、他のネットワーク装置から標識が受信されたことに応答して、ネットワーク装置は、その標識を使用して、他のどのネットワーク装置に経路情報を送信すべきかを判定する。本発明のいくつかの実施形態では、上記の第１および第２のステップは、標識の要求がアドレスのポーリングと併せて行われる１つのステップに組み合わされる。

図１０を参照すると、本発明の他の実施形態による、分散型ネットワーク内でのピアの発見の方法が示されている。図１０の実施形態では、経路表を維持し、その経路表内の経路情報を用いて他のネットワーク装置を更新する、ネットワーク装置が指定される。まず、あるネットワーク装置が、たとえば電源投入があった際にネットワーク上で使用可能になったときに、ネットワーク上の他のネットワーク装置にメッセージを送信する（１２１０）。このメッセージが受信されると、経路情報を維持するように指定されている他のネットワーク装置のうちの１つが、その他のネットワーク装置についての経路情報を確認し、メッセージの送信元のネットワーク装置についての経路情報を判定する（１２２０）。たとえば、メッセージの送信元のネットワーク装置のＤＮは、その他のネットワーク装置についての経路情報の一部として確認されたＤＮのうちから判定される。次いで、指定されたネットワーク装置は、メッセージの発信元のネットワーク装置に、その他のネットワーク装置およびメッセージの発信元のネットワーク装置についての経路情報を送信する（１２３０）。指定されたネットワーク装置からの経路情報が受信されると、その経路情報が記憶される（１２４０）。

当業者には理解されるように、本発明の趣旨から逸脱することなく、上述した実施形態には様々な変更を加えることができる。たとえば、本明細書に記載の実施形態の大部分では端末セットであるピアについて言及しているが、ここに記載の方法は、他の形態のネットワーク装置など、端末セット以外のピアにも等しく適用可能であることが理解されるであろう。また、ネットワーク装置は、ＬＡＮだけではなく任意の形態のネットワークによって相互接続されてもよい。さらに、本明細書の記載では、加入者電話番号の選択、プローブ、アサートについて言及しているが、ここに記載の方法は、加入者電話番号以外のネットワーク・アドレスにも等しく適用可能であることが理解されるであろう。

最後に、上述した方法および状態マシンは、各ネットワーク装置によってまたは各ネットワーク装置において実装されるものとして説明されているが、それらがネットワーク装置の外部で実装されることがあっても、それらを依然として（たとえば、周辺装置において）前記ネットワーク装置に関連付けることができることが理解されるであろう。この場合でも、記載の方法および状態マシンは依然として、ネットワーク装置によってまたはネットワーク装置において実施されるものと見なされるはずである。

上記の教示に照らせば、本発明の数々のさらなる変更形態および変形形態が可能である。したがって、本明細書に具体的に記載されている形以外でも、添付の特許請求の範囲内で本発明を実施できることが理解されよう。

本発明の一実施形態によるピアの発見を行うことのできる、ネットワーク化された複数の端末セット（「ピア」）を含む電話システムの図である。 図１の電話システムにおける端末セットの部分的な回路ブロック図である。 図２の端末セット上で動作するソフトウェアの機能ブロック図である。 図２の端末セットの経路表である。 本発明の一実施形態による、分散型ピア・ツー・ピア・ネットワーク内でのピアの発見中に端末セットによって実装される状態マシンの図である。 図５に示される初期状態における端末セットの動作を示す流れ図である。 図５に示される加入者電話番号のプローブ状態における端末セットの動作を示す流れ図である。 図５に示されるＤＮアサート状態における端末セットの動作を示す流れ図である。 本発明の他の実施形態による、分散型ネットワーク内でのピアの発見の動作を示す流れ図である。 本発明の他の実施形態による、分散型ネットワーク内でのピアの発見の動作を示す流れ図である。

Claims (57)

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. 前記ネットワーク・アドレスは、加入者電話番号である、請求項２０に記載のネットワーク・ピア。
38. 前記加入者電話番号は、電話の内線であり、前記ネットワーク・ピアは、電話セットである、請求項３７に記載のネットワーク・ピア。
39. 複数のネットワーク・ピアのうちの１つのネットワーク・ピアでの実行を対象とするマシン実行可能なコードを含むマシン可読媒体であって、
    存在通知を送信するためのマシン実行可能なコードと、
    現在においてネットワークに接続された１つまたは複数の他のアクティブ・ネットワーク・ピアから１つまたは複数のアクティブ・ピア存在通知を受信するためのマシン実行可能なコードと、
    １つまたは複数のアクティブ・ネットワーク・ピアから、以前はネットワークに接続されていたが現在はネットワークに接続されていない１つまたは複数の非アクティブ・ネットワーク・ピアに関する１つまたは複数の非アクティブ・ネットワーク・ピアを受信するマシン実行可能なコードと、
    受信されたアクティブまたは非アクティブ・ピア存在通知から作成されたアドレス・リストに基づいて、前記１つのネットワーク・ピアの見込まれるネットワーク・アドレスを選択するためのマシン実行可能なコードと
    を備えるマシン可読媒体。
40. 各存在通知は、一意のネットワーク・ピア識別子を含む、請求項３９に記載のマシン可読媒体。
41. 前記一意のネットワーク・ピア識別子は、ハードウェア・アドレスである、請求項４０に記載のマシン可読媒体。
42. 前記選択は、前記各一意のネットワーク・ピア識別子に基づく、請求項４０に記載のマシン可読媒体。
43. 前記選択は、
    前記他のネットワーク・ピアの前記各一意のネットワーク・ピア識別子を、前記１つのネットワーク・ピアの一意の識別子と共に分類することであって、分類することにより、前記複数のネットワーク・ピアの分類済みのアドレス・リストを生成することと、
    前記分類済みのアドレス・リスト内での前記１つのネットワーク・ピアの順序位置を判定することと、
    前記順序位置から、前記見込まれるネットワーク・アドレスを作成することとを含む、
    請求項４１に記載のマシン可読媒体。
44. 前記見込まれるネットワーク・アドレスを作成することは、前記順序位置に関連するオフセットをベース・アドレスに追加することを含む、請求項４３に記載のマシン可読媒体。
45. 前記存在通知を送信することは、ネットワーク接続メッセージを送信することを含む、請求項３９に記載のマシン可読媒体。
46. 前記ネットワーク接続メッセージを送信することは、固定された時間間隔あるいはランダムな時間間隔で２つ以上の前記メッセージを送信することを含む、請求項４５に記載のマシン可読媒体。
47. 前記送信は、マルチキャストを含む、請求項３９に記載のマシン可読媒体。
48. 前記見込まれるネットワーク・アドレスと、前記他のネットワーク・ピアのいずれかによって主張されているネットワーク・アドレスとの間に重複が存在するかどうかを判定するためのマシン実行可能なコードと、
    重複が存在する場合は、前記見込まれるネットワーク・アドレスが前記複数のネットワーク・ピアの１つだけによって主張されるように前記重複を解決するためのマシン実行可能なコードと
    をさらに備える、請求項３９に記載のマシン可読媒体。
49. 前記重複が存在するかどうかを判定することは、前記他のネットワーク・ピアによって主張されている前記ネットワーク・アドレスが、前記見込まれるネットワーク・アドレスを含んでいるかどうかを確証することを含む、請求項４８に記載のマシン可読媒体。
50. 前記確証で、前記他のネットワーク・ピアの前記ネットワーク・アドレスが、前記見込まれるネットワーク・アドレスを含んでいることが確証された場合は、前記解決は、前記１つのネットワーク・ピアの新しい見込まれるネットワーク・アドレスを選択することと、前記新しい見込まれるネットワーク・アドレスについて、前記重複が存在するかどうかを判定することを繰り返すこととを含む、請求項４９に記載のマシン可読媒体。
51. 前記重複が存在するかどうかを判定することは、前記確証で、前記他のネットワーク・ピアの前記ネットワーク・アドレスが、前記見込まれるネットワーク・アドレスを含んでいないことが確証された場合は、前記見込まれるネットワーク・アドレスを前記他のネットワーク・ピアのそれぞれに通知することと、前記１つのネットワーク・ピアが前記見込まれるネットワーク・アドレスを主張することに対する、前記他のネットワーク・ピアのいずれかからの何らかの異議が受信されるのを待つこととをさらに含む、請求項４９に記載のマシン可読媒体。
52. 前記１つのネットワーク・ピアが、前記１つのネットワーク・ピアが前記見込まれるネットワーク・アドレスを主張することに対する、前記他のネットワーク・ピアのいずれかからの異議を受信しない場合は、前記見込まれるネットワーク・アドレスを前記１つのネットワーク・ピアのネットワーク・アドレスとして主張するためのマシン実行可能なコードをさらに備える、請求項５１に記載のマシン可読媒体。
53. 前記１つのネットワーク・ピアが、前記１つのネットワーク・ピアが前記見込まれるネットワーク・アドレスを主張することに対する、前記他のネットワーク・ピアのいずれかからの異議を受信した場合は、前記解決は、前記１つのネットワーク・ピアの新しい見込まれるネットワーク・アドレスを選択することと、前記新しい見込まれるネットワーク・アドレスについて、前記重複が存在するかどうかを判定することを繰り返すこととを含む、請求項５１に記載のマシン可読媒体。
54. 前記異議が受信されたときは、ネットワーク・アドレスの重複解決スキームを適用するためのマシン実行可能なコードをさらに備え、前記新しい見込まれるアドレスを選択することは、ネットワーク・アドレスの前記解決スキームによって、前記１つのネットワーク・ピアが前記ネットワーク・アドレスを主張すべきではないと判定されることを条件とする、請求項５３に記載のマシン可読媒体。
55. 前記ネットワーク・アドレスの重複解決スキームは、前記１つのネットワーク・ピアの一意の識別子と、前記異議がそのネットワーク・ピアのために送信された別のネットワーク・ピアの一意の識別子との比較である、請求項５４に記載のマシン可読媒体。
56. 前記ネットワーク・アドレスは、加入者電話番号である、請求項３９に記載のマシン可読媒体。
57. 前記加入者電話番号は、電話の内線であり、前記ネットワーク・ピアは、電話セットである、請求項５６に記載のマシン可読媒体。

Images