JP6397044B2 - 拡張分散リソースディレクトリ - Google Patents

Description

（関連出願に対する相互参照）
本願は、２０１４年３月１１日に出願された米国仮特許出願第６１／９５１，１４１号の利益を主張するものであり、該仮特許出願の開示は、その全体が参照により本明細書中に援用される。

リソース制約ノードおよびネットワークは、マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）システムの重要な部分を構成する。Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｃｏｎｓｔｒａｉｎｅｄ ＲＥＳＴｆｕｌ Ｅｎｖｉｒｏｎｍｅｎｔｓ（ＣｏＲＥ） Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ（ＩＥＴＦ ＣｏＲＥ）は、ＣｏＲＥリソースディレクトリ（ＲＤ）を開発している。図１は、ＣｏＲＥリソースディレクトリアーキテクチャの実施例を示し、ＣｏＲＥリソースディレクトリは、ウェブサーバがリソースディレクトリを発見することができるように、リソースディレクトリがサポートする、ウェブインターフェースを規定する。さらに、ウェブインターフェースは、ウェブサーバが、リソース記述を登録、維持、ルックアップ、および除去することを可能にする。ＩＥＴＦはまた、リソースディレクトリと併用され得る、リンク属性を定義している。

図１を参照すると、ＣｏＲＥ ＲＤアーキテクチャ内のリソースディレクトリ１００が、描写されている。リソースディレクトリ１００は、概して、エンドポイント、例えば、エンドポイント１０２と称され得る、他のウェブサーバ上にホストされるリソースと関連付けられたウェブリンクのためのリポジトリであることができる。エンドポイントは、ポートと関連付けられたウェブサーバを指し得、したがって、物理的ノードは、１つまたはそれを上回るエンドポイントをホストし得る。エンドポイントは、種々のＭ２Ｍ／ＩｏＴデバイス内にホストされることができる。リソースディレクトリ１００は、エンドポイント１０２が、ウェブリンクのセット（リソースディレクトリエントリと呼ばれる）を登録および維持するためのＲＥＳＴｆｕｌ（表現可能な状態の転送）インターフェースのセットを実装する。インターフェースはまた、リソースディレクトリが、エントリを検証することを可能にし、クライアント（例えば、クライアント１０４）が、リソースディレクトリ１００からリソースをルックアップすることを可能にする。リソースは、概して、ＲＥＳＴｆｕｌアーキテクチャ内の一意のアドレス指定可能なエンティティを指す。エンドポイントはまた、クライアントとして作用することができ、したがって、クライアントもまた、Ｍ２Ｍ／ＩｏＴデバイス内にホストされることができる。

依然として、概して、図１を参照すると、エンドポイント１０２は、リソースディレクトリエントリをリソースディレクトリ１００上に先を見越して登録および維持する。エントリは、ソフトステートであって、周期的にリフレッシュされる必要があり得る。エンドポイント１０２は、インターフェースを装備し、所与のリソースディレクトリエントリを登録、更新、および除去する。さらに、リソースディレクトリは、ＣｏＲＥリンクフォーマットを使用して発見されることができる。リソースディレクトリ、例えば、リソースディレクトリ１００は、ウェブリンクをエンドポイント１００から先を見越して発見し、それらをリソースディレクトリエントリとして追加してもよい。リソースディレクトリ１００はまた、ウェブリンクを先を見越して発見し、既存のリソースディレクトリエントリを検証してもよい。リソースディレクトリ１００内に保持されるウェブリンクを発見するためのルックアップインターフェースは、ＣｏＲＥリンクフォーマットを使用して提供される。

図２は、ＣｏＲＥリソースディレクトリアーキテクチャにおけるリソース登録の現在の技法を図示する。図１および２を参照すると、エンドポイント１０２は、登録インターフェース１０６を使用して、そのリソースを登録する。２０２では、登録インターフェース１０６は、ＰＯＳＴをエンドポイント１０２から受け取る。ＰＯＳＴは、ＣｏＲＥリンクフォーマットに従ってメッセージペイロード内のディレクトリに追加されるべきリソースのリストを含有してもよい。ＰＯＳＴはまた、エンドポイント１０２の名前、エンドポイント１０２と関連付けられたドメイン、および登録の有効期間を示す、クエリストリングパラメータを含有してもよい。実施例では、エンドポイント名以外の全てのパラメータは、随意である。リソースディレクトリ１００は、次いで、新しいリソースを作成する、またはリソースディレクトリ内の既存のリソースを更新し、その場所を返す（２０４）。実施例によると、エンドポイント１００は、登録インターフェース１０６を使用して登録をリフレッシュするときにそれが受信する場所を使用する。リソースディレクトリ１００内のエンドポイントリソースは、有効期間パラメータによって示される周期の間、アクティブに保たれる。エンドポイント１０２は、登録インターフェース１０６または更新インターフェースのいずれかを使用して、本周期内におけるエントリのリフレッシュに関与する。

図１から３を参照して、背景実施例を継続すると、リソースディレクトリ１００が、それに登録されるリソースを発見するために使用されるようにするために、ルックアップインターフェース１０８が、提供されることができる。例示的ルックアップインターフェース１０８は、クライアント１０４が、ＲＤ１００と相互作用し、例えば、「ＧＥＴ」方法を実装するために規定される。例示的ＵＲＩテンプレートは、／｛＋ｒｄ−ｌｏｏｋｕｐ−ｂａｓｅ｝／｛ｌｏｏｋｕｐ−ｔｙｐｅ｝｛？ｄ，ｅｐ，ｇｐ，ｅｔ，ｒｔ，ｐａｇｅ，ｃｏｕｎｔ，ｒｅｓｏｕｒｃｅ−ｐａｒａｍ｝である。例示的パラメータとして、以下が挙げられる。
・ｒｄ−ｌｏｏｋｕｐ−ｂａｓｅ：＝ＲＤルックアップ関数セットパス（必須）。これは、ＲＤルックアップ関数セットのパスである。ある場合には、ＲＤは、可能である場合、本変数に対して値「ｒｄ−ｌｏｏｋｕｐ」を使用する。
・ｌｏｏｋｕｐ−ｔｙｐｅ：＝（「ｄ」、「ｅｐ」、「ｒｅｓ」、「ｇｐ」）（必須）。本変数は、行うべきルックアップの種類を選択するために使用される（例えば、ドメイン、エンドポイント、またはリソース）。
・ｅｐ：＝エンドポイント（随意）。エンドポイント、グループ、およびリソースルックアップのために使用される。
・ｄ：＝ドメイン（随意）。ドメイン、グループ、エンドポイント、およびリソースルックアップのために使用される。
・ｐａｇｅ：＝ページ（随意）。パラメータは、カウントパラメータを伴わずに使用されることができない。結果は、インデックス（ｐａｇｅ＊ｃｏｕｎｔ）から開始する「ｃｏｕｎｔ」結果を含有する、ページ内の結果セットから返される。
・ｃｏｕｎｔ：＝カウント（随意）。結果の数は、本パラメータ値に限定されてもよい。ある場合には、パラメータが存在しない場合、ＲＤ実装特有デフォルト値が、使用される。
・ｒｔ：＝リソースタイプ（随意）。グループ、エンドポイント、およびリソースルックアップのために使用される。
・ｅｔ：＝エンドポイントタイプ（随意）。グループ、エンドポイント、およびリソースルックアップのために使用される。
・ｒｅｓｏｕｒｃｅ−ｐａｒａｍ：＝リンク属性パラメータ（随意）。本パラメータは、ＲＦＣ６６９０「Ｃｏｒｅ Ｌｉｎｋ Ｆｏｒｍａｔ」の第４．１節に定義されるような任意のリンク属性を示してもよい。リソースルックアップのために使用される。

図３は、ＣｏＲＥリソースディレクトリアーキテクチャにおけるリソースルックアップのための現在の技法を図示する。示されるように、３０２では、クライアント１０４は、リソースタイプ（ｒｔ）パラメータをルックアップする。実施例では、クライアント１０４は、温度リソースタイプ（例えば、温度センサ）を伴うリソースの発見を試みている。したがって、リソースタイプは、温度に設定される。３０４では、示されるように、ＲＤ１００は、「ｃｏａｐ：／／ｎｏｄｅ１／ｔｅｍｐ」のＵＲＩを伴うリソースを返す。

リソースディレクトリ１００は、ＣｏＲＥリソースディレクトリアーキテクチャにおいて規定されるように、集中化される。集中型リソースディレクトリは、インターネットを横断するスケーラビリティに欠ける。例えば、あるクライアントは、そのローカルドメイン内のリソースにのみアクセスすることを所望し得る。集中型リソースディレクトリは、他のクライアントに影響を及ぼさずに、そのような局在型リソース管理を良好にサポートしない。その結果、分散リソースディレクトリが、提案されている。

図４は、例示的ＤＲＤアーキテクチャにおける例示的分散リソースディレクトリＤＲＤ４００を図示する。提案される分散リソースディレクトリアーキテクチャは、分散ハッシュテーブルへのインターフェースを規定し、分散ハッシュテーブル能力を使用して、分散リソースディレクトリをイネーブルにする方法を規定する。関与リソースディレクトリは、分散リソースディレクトリオーバーレイを形成する。提案される分散リソースディレクトリ（ＤＲＤ）アーキテクチャは、集中型リソースディレクトリと同一のＲＥＳＴインターフェースを提供する。エンドポイントは、１つまたはそれを上回る制約アプリケーションプロトコル（ＣｏＡＰ）サーバを起動させ得る、物理的ノードであってもよく、ＤＲＤにおいてＲＥＳＴ動作（例えば、ＰＯＳＴ、ＧＥＴ）を使用することができる。エンドポイントはまた、クライアントとして作用することができる。したがって、エンドポイントは、ＣｏＡＰクライアントと称され得る。従来または旧来のＨＴＴＰクライアントはまた、ＤＲＤ内に記憶されるリソースにアクセスする必要があり得る。示されるように、ＤＲＤアーキテクチャ内の種々のノードは、エンドポイント（ＥＰ）４０２、ピア（Ｐ）４０４、ＨＴＴＰプロキシ（ＨＰ）４０６、ＨＴＴＰクライアント４０８、およびＣｏＡＰクライアント４１０を含む。示されるように、エンドポイント４０２は、「ノード」上に常駐し、ＣｏＡＰプロトコルを使用して通信する、エンティティであって、したがって、ＣｏＡＰエンドポイントと称され得る。ＣｏＡＰエンドポイントは、ＣｏＡＰメッセージのソースまたは宛先であることができる。ピア４０４は、宛先へのオーバーレイを通るパスを辿ってメッセージを自動転送可能なフルオーバーレイメンバーノードである。いくつかのピアはまた、ＨＴＴＰプロキシ４０６として作用することができる。言い換えると、ピアとして作用することに加え、ノードはまた、プロトコル変換のためのプロキシとしても作用する。ＨＴＴＰプロキシ４０６は、ＨＴＴＰおよびＣｏＡＰプロトコルの両方を起動し、その２つの間の変換を行うことが可能である。ＨＴＴＰクライアント４０８は、ＨＴＴＰメッセージを使用して要求を所与のリソースディレクトリに送信する、クライアントである。ＣｏＡＰクライアント４１０は、ＣｏＡＰメッセージを使用して要求を所与のリソースディレクトリに送信する、ＣｏＡＰエンティティである。

図５は、分散リソースディレクトリ４００におけるリソース登録の現在の技法を図示する。例えば、リソース登録では、５０２において、ＥＰ４０２ａは、そのリソースを分散リソースディレクトリ４００の中に登録するために、リソースのリストを（メッセージのペイロード内に）含有する、ＣｏＡＰ ＰＯＳＴメッセージを送信する。ＥＰ４０２は、そのリソースが発見可能であり得るように、これを行う。ピア、例えば、第１のピア４０４ａ（分散リソースディレクトリオーバーレイに関与する分散ハッシュテーブルアルゴリズムを起動させる）が、登録メッセージを受信すると、分散ハッシュテーブル内のリソースのＣｏＡＰ ＵＲＩのハッシュ下にＣｏＡＰ登録構造を記憶する（５０４）。ＣｏＡＰ登録のペイロードは、オーバーレイの中に値として記憶される。５０６において、分散ハッシュテーブルＡＣＫメッセージを第２のピア４０４ｂから得た後、第１のピア４０４ａは、ＣｏＡＰ ＡＣＫメッセージをＥＰ４０２ａに送信し（５０８）、リソースが分散リソースディレクトリ４００の中に登録されたことを示す。

５０２におけるＰＯＳＴ要求は、エンドポイント４０２ａを一意に識別するために使用される、エンドポイント４０２ａ名を示すためのクエリストリングパラメータを含む。エンドポイント名設定は、異なる代替を有する。１つの方法は、デバイスのＭＡＣアドレスをハッシュし、エンドポイント名を生成することである。別の方法は、共通名を使用することである。

実施例として、依然として、図４および５を参照すると、名前「９９９６１７２」を伴うエンドポイントが、１つの温度リソースおよび１つの光リソース記述を分散リソースディレクトリ４００の中に登録することを所望する場合、エンドポイントは、ＵＲＩ「ｃｏａｐ：／／ｏｖｅｒｌａｙ−１．ｃｏｍ／ｐｒｏｘｙ−１／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅ？ｅｐ＝９９９６１７２」を伴うＰＯＳＴ要求を送信する。リソース記述は、メッセージのペイロード内に含まれる。登録メッセージの実施例は、以下に与えられる。
Ｒｅｑ：ＰＯＳＴ ｃｏａｐ：／／ｏｖｅｒｌａｙ−１．ｃｏｍ／ｐｒｏｘｙ−１／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅ？ｅｐ＝９９９６１７２
Ｐａｙｌｏａｄ：
＜／ｔｅｍｐｅｒａｔｕｒｅ-１＞；ｌｔ＝４１；ｒｔ＝"Ｔｅｍｐｅｒａｔｕｒｅ"；ｉｆ＝"ｓｅｎｓｏｒ"，
＜／ｌｉｇｈｔ−２＞；ｌｔ＝４１；ｒｔ＝"ＬｉｇｈｔＬｕｘ"；ｉｆ＝"ｓｅｎｓｏｒ"

その結果、ハッシュ関数に適用されるキーは、第２のピア４０４ｂ（Ｐ２）が値を記憶するためのピアであることを判定する、ｃｏａｐ：／／ｏｖｅｒｌａｙ−１．ｃｏｍ／ｐｒｏｘｙ−１／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅ？ｅｐ＝９９９６１７２となる。第２のピア４０４ｂ上に記憶される値は、ペイロードである。

また、図６を参照すると、図６は、分散リソースディレクトリ４００におけるリソース発見の現在の技法を図示する。分散リソースディレクトリ４００は、ＣｏＡＰ ＵＲＩとＮｏｄｅ−ＩＤとの間のマッピング情報をフェッチし、リソースのアドレス情報を得ることによって、ランデブーをサポートする。具体的には、６０２において、エンドポイント（図６におけるクライアント４１０ａ）は、要求されるリソースのＵＲＩ情報を含む、ＣｏＡＰ ＧＥＴ要求を分散リソースディレクトリ４００に送信する。本要求をハンドリングする分散リソースディレクトリピア（図６におけるピア４０４ｃ）は、６０４において、ＣｏＡＰ ＵＲＩのハッシュのために、分散ハッシュテーブルルックアップを行う。分散ハッシュテーブルは、次いで、リソースの値に関与するピア（図６におけるピア４０４ｂ）を見出す。６０６では、宛先ピア４０４ｂは、記憶された値をピア４０４ｃに返す。６０８では、ピア４０４ｃは、コンテンツ（例えば、記憶された値）を、エンドポイント４１０ａとも称され得る、クライアント４１０に返信する。

例えば、クライアント４１０ａが、本明細書に規定されるように、ＵＲＩ：ｃｏａｐ：／／ｏｖｅｒｌａｙ−１．ｃｏｍ／ｐｒｏｘｙ−１／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅ？ｅｐ＝９９９６１７２を伴うリソースを発見することを所望する場合、ピア４０４ｃは、ＧＥＴ要求を受信し、ピア４０４ｂにマップするＵＲＩにハッシュ関数を使用する。その結果、ピア４０４ｃは、要求をピア４０４ｂに自動転送する。ピア４０４ｂは、リソースのペイロードをピア４０４ｃに返し、順に、ペイロードをクライアント４１０ａに返す。

前述のように、ＣｏＲＥリソースディレクトリは、ＣｏＲＥリソースディレクトリが集中化されるように、集中型リソースディレクトリを含む。本明細書では、集中型ディレクトリは、クライアントによって同時に効率的にアクセスされず、ＩｏＴシステムまたはＭ２Ｍネットワークのために効率的にスケーリングされないと認識される。さらに、本明細書では、前述の分散リソースディレクトリは、他の欠点の中でもとりわけ、限定された登録能力およびルックアップ能力を有すると認識される。

本明細書に説明されるのは、拡張分散リソースディレクトリ（ＤＲＤ）のための方法、デバイス、およびシステムである。例示的実施形態では、分散リソースディレクトリネットワーク内のノード、例えば、リソースディレクトリノードは、メッセージペイロードをエンドポイントから受信する。メッセージペイロードは、登録要求またはリソースルックアップ要求を含んでもよい。メッセージペイロードの受信に応じて、リソースディレクトリサーバは、メッセージペイロードと関連付けられたキーを判定してもよい。キーは、パラメータおよびパラメータと関連付けられた値を有してもよい。キーの判定に応じて、キーは、ハッシュ関数に適用され、ピアリソースディレクトリと関連付けられたマッピング情報を生成する。マッピング情報に基づいて、リソースディレクトリサーバは、メッセージペイロードをピアリソースディレクトリに伝送してもよい。メッセージペイロードの伝送に応じて、リソースディレクトリノードは、応答をピアリソースディレクトリから受信してもよい。応答は、ピアリソースディレクトリに記憶されるリソースの場所またはコンテンツを示してもよい。応答の受信に応じて、リソースディレクトリノードは、応答を組み合わせることによって、結果として生じる応答を生成してもよい。リソースディレクトリノードは、結果として生じる応答を、ウェブサーバであり得る、要求側エンドポイントに伝送してもよい。結果として生じる応答は、ハッシュパラメータを含んでもよい。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
例えば、本願は以下の項目を提供する。
（項目１）
プロセッサと、メモリと、通信回路とを備える、ノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードのメモリ内に記憶されるコンピュータ実行可能命令をさらに備え、前記コンピュータ実行可能命令は、前記ノードのプロセッサによって実行されると、前記ノードに、
エンドポイントから受信されたメッセージペイロードと関連付けられた１つまたはそれを上回るキーを判定することであって、前記メッセージペイロードは、登録要求を備える、ことと、
前記１つまたはそれを上回るキーをハッシュ関数に適用し、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を備える、ことと、
前記マッピング情報に基づいて、前記メッセージペイロードを１つまたはそれを上回るピアリソースディレクトリサーバに伝送することと、
少なくとも１つの応答を前記１つまたはそれを上回るピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、前記リソースの場所を示す、ことと、
前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと
を行わせる、ノード。
（項目２）
前記メッセージペイロードと関連付けられた１つまたはそれを上回るキーは、少なくとも１つのパラメータおよび前記少なくとも１つのパラメータと関連付けられた少なくとも１つの値を備える、項目１に記載のノード。
（項目３）
前記少なくとも１つのパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、またはインターフェースを示す、項目２に記載のノード。
（項目４）
前記少なくとも１つのパラメータは、複数のパラメータであり、前記少なくとも１つの値は、複数の値であり、前記ハッシュ関数は、前記登録要求内のパラメータおよび値のそれぞれに適用される、項目２に記載のノード。
（項目５）
前記メッセージペイロードが伝送される、前記１つまたはそれを上回るピアリソースディレクトリサーバは、それぞれ、前記メッセージペイロードを記憶する、複数のピアリソースディレクトリサーバであり、前記コンピュータ実行可能命令はさらに、前記ノードに、
前記メッセージペイロード内にあるパラメータの数に基づいて、前記複数のピアリソースディレクトリサーバ内のピアリソースディレクトリサーバの数を判定すること
を行わせる、項目４に記載のノード。
（項目６）
前記メッセージペイロードが伝送される、前記１つまたはそれを上回るピアリソースディレクトリサーバは、前記メッセージペイロードを記憶する、選択された１つのピアリソースディレクトリサーバであり、前記コンピュータ実行可能命令はさらに、前記ノードに、
前記複数のピアリソースディレクトリが、前記メッセージペイロードを記憶する選択された１つのピアリソースディレクトリへの参照を記憶するように、複数のピアリソースディレクトリサーバに、前記選択された１つのピアリソースディレクトリへの参照を伝送すること
を行わせる、項目４に記載のノード。
（項目７）
前記登録要求は、前記エンドポイントの名前およびそのリソース記述を備える、項目１に記載のノード。
（項目８）
前記エンドポイントは、ウェブサーバ、マシンツーマシンデバイス、またはゲートウェイとして動作するように構成される、項目１に記載のノード。
（項目９）
プロセッサと、メモリと、通信回路とを備える、ノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードのメモリ内に記憶されるコンピュータ実行可能命令をさらに備え、前記コンピュータ実行可能命令は、前記ノードのプロセッサによって実行されると、前記ノードに、
エンドポイントから受信されたメッセージペイロードと関連付けられた１つまたはそれを上回るキーを判定することであって、前記メッセージペイロードは、リソースルックアップ要求を備える、ことと、
前記１つまたはそれを上回るキーをハッシュ関数に適用し、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を備える、ことと、
前記マッピング情報に基づいて、前記メッセージペイロードを１つまたはそれを上回るピアリソースディレクトリサーバに伝送することと、
少なくとも１つの応答を前記１つまたはそれを上回るピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、前記１つまたはそれを上回るピアリソースディレクトリサーバ上に記憶されるリソースのコンテンツを示す、ことと、
前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと
を行わせる、ノード。
（項目１０）
前記メッセージペイロードと関連付けられた１つまたはそれを上回るキーは、１つまたはそれを上回るパラメータを備える、項目９に記載のノード。
（項目１１）
前記１つまたはそれを上回るパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、またはインターフェースを示す、項目１０に記載のノード。
（項目１２）
前記リソースルックアップ要求は、ルックアップタイプおよび１つまたはそれを上回るパラメータを備える、項目９に記載のノード。
（項目１３）
前記１つまたはそれを上回るパラメータは、複数のパラメータであり、前記コンピュータ実行可能命令はさらに、前記ノードに、
前記パラメータが、第１の論理連結語を使用して相互に接続される場合、前記メッセージペイロードを複数のピアリソースディレクトリサーバに伝送することであって、前記複数とは、前記メッセージペイロード内のパラメータの数に基づく、ことと、
前記パラメータが、第２の論理連結語を使用して相互に接続される場合、前記メッセージペイロードを１つのみのピアリソースディレクトリサーバに伝送することと
を行わせる、項目１０に記載のノード。
（項目１４）
前記メッセージペイロードが伝送される、前記１つまたはそれを上回るピアリソースディレクトリサーバは、前記リソースルックアップ要求を前記マッピング情報によって示される他のピアリソースディレクトリサーバに伝搬する、選択された１つのピアリソースディレクトリサーバである、項目１０に記載のノード。
（項目１５）
前記エンドポイントは、ウェブサーバ、マシンツーマシンデバイス、またはゲートウェイとして動作するように構成される、項目９に記載のノード。
（項目１６）
方法であって、
リソースディレクトリサーバによって、エンドポイントから受信されたメッセージペイロードと関連付けられた１つまたはそれを上回るキーを判定することであって、前記メッセージペイロードは、登録要求またはリソースルックアップ要求のうちの少なくとも１つを備える、ことと、
前記１つまたはそれを上回るキーをハッシュ関数に適用し、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を備える、ことと、
前記マッピング情報に基づいて、前記メッセージペイロードを１つまたはそれを上回るピアリソースディレクトリサーバに伝送することと、
前記リソースディレクトリサーバにおいて、少なくとも１つの応答を前記１つまたはそれを上回るピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、リソースの場所または前記１つまたはそれを上回るピアリソースディレクトリサーバ上に記憶されるリソースのコンテンツを示す、ことと、
前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと、
を含む、方法。
（項目１７）
前記メッセージペイロードと関連付けられた１つまたはそれを上回るキーは、少なくとも１つのパラメータおよび前記少なくとも１つのパラメータと関連付けられた少なくとも１つの値を備える、項目１６に記載の方法。
（項目１８）
前記少なくとも１つのパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、またはインターフェースを示す、項目１７に記載の方法。
（項目１９）
前記登録要求は、前記エンドポイントの名前およびそのリソース記述を備える、項目１７に記載の方法。
（項目２０）
前記リソースルックアップ要求は、ルックアップタイプおよび１つまたはそれを上回るパラメータを備える、項目１７に記載の方法。

より詳細な理解は、付随の図面と併せて、一例として与えられる、以下の説明から得られ得る。

図１は、制約ＲＥＳＴｆｕｌ環境（ＣｏＲＥ）リソースディレクトリアーキテクチャを図示する、システム図である。

図２は、ＣｏＲＥリソースディレクトリアーキテクチャにおけるリソース登録の実施例を図示する、流れ図である。

図３は、ＣｏＲＥリソースディレクトリアーキテクチャにおけるリソースルックアップの実施例を図示する、流れ図である。

図４は、例示的分散リソースディレクトリアーキテクチャを図示する、システム図である。

図５は、図４に描写される分散リソースディレクトリにおけるリソース登録の実施例を図示する、流れ図である。

図６は、図４に描写される分散リソースディレクトリにおけるリソース発見の実施例を図示する、流れ図である。

図７は、例示的実施形態による、記憶補助機構を使用したエンドポイントからのリソース登録を図示する、流れ図である。

図８は、例示的実施形態による、記憶補助機構における別のエンドポイントからのリソース登録を図示する、流れ図である。

図９は、例示的実施形態による、記憶補助機構における光グループ登録を図示する、流れ図である。

図１０は、例示的実施形態による、記憶補助機構における圧力グループ登録を図示する、流れ図である。

図１１は、例示的実施形態による、記憶補助実装におけるリソースルックアップを図示する、流れ図である。

図１２は、例示的実施形態による、記憶補助実装における別のリソースルックアップを図示する、流れ図である。

図１３は、例示的実施形態による、記憶補助実装におけるさらに別のリソースルックアップを図示する、流れ図である。

図１４は、例示的実施形態による、記憶補助実装におけるさらに別のリソースルックアップを図示する、流れ図である。

図１５は、例示的実施形態による、リソース登録の実施例を図示する、流れ図である。

図１６は、別の例示的実施形態による、リソース登録の別の実施例を図示する、流れ図である。

図１７は、例示的実施形態による、光グループ登録を図示する、流れ図である。

図１８は、例示的実施形態による、圧力グループ登録を図示する、流れ図である。

図１９は、例示的実施形態による、参照支援実装におけるリソースルックアップ実施例を図示する、流れ図である。

図２０は、例示的実施形態による、参照支援実装における別のリソースルックアップ実施例を図示する、流れ図である。

図２１は、例示的実施形態による、参照支援実装におけるさらに別のリソースルックアップを図示する、流れ図である。

図２２Ａは、１つまたはそれを上回る開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムのシステム図である。

図２２Ｂは、図２２Ａに例証されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクスチャのシステム図である。

図２２Ｃは、図２２Ａに例証される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスのシステム図である。

図２２Ｄは、図２２Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

続く発明を実施するための形態は、例示的実施形態を例証するために提供され、本発明の範囲、可用性、または構成を限定することを意図するものではない。種々の変更が、本発明の精神および範囲から逸脱することなく、要素およびステップの機能および配列において行われ得る。

用語「オーバーレイネットワーク」は、本明細書で使用されるように、別のネットワーク上に構築される、ネットワークを指す。オーバーレイネットワーク内のノードは、それぞれ、下層ネットワーク内のパスに対応する、仮想または論理リンクによって接続されると考えることができる。例えば、ピアツーピア（Ｐ２Ｐ）ネットワーク等の分散システムは、そのノードがインターネット上で起動するため、オーバーレイネットワークと見なされることができる。「ホームリソースディレクトリ（ＲＤ）」である、ノードは、本明細書で使用されるように、ＥＰがそのリソースを登録することを所望するときのエンドポイント（ＥＰ）の第１のコンタクトポイントを指す。ホームＲＤはまた、クライアントがリソースを発見することを所望するときのクライアントのための第１のコンタクトポイントを指す。本明細書で使用されるように、「記憶ＲＤ」である、ノードは、リソース登録エントリを記憶し、ホームＲＤがクライアントの発見要求を自動転送する、ピアを指し得る。本明細書で使用されるように、別様に規定されない限り、「関与ＲＤ」である、ノードは、リソース登録メッセージ内のあらゆる可能性として考えられるキーにハッシュ関数を使用することから生じる、ピアのＲＤを指し得る。本明細書で使用されるように、別様に規定されない限り、「ＣｏＲＥ関与ＲＤ」である、ノードは、ホームＲＤがリソース発見要求を自動転送する第１のコンタクトポイントである、関与ＲＤのうちの１つを指す。

例示的実施形態によると、拡張分散リソースディレクトリは、本明細書に説明されるように、リソースの統一資源識別子（ＵＲＩ）を把握せずに、リソースルックアップをサポートすることができる。一実施例では、リソース記述の複数のコピーが、本明細書では、ピアＲＤと称される、複数のリソースディレクトリ（ＲＤ）内に記憶される。参照支援（ＲＥ）実装と称される、本明細書に説明される別の例示的実装では、ホームピアは、登録メッセージを１つのみのピアＲＤに送信し、他のピアＲＤに、リソースおよびそれと関連付けられた情報が記憶される場所を通知する。

概して、図４に描写される分散リソースディレクトリアーキテクチャを参照すると、本明細書に説明される実施形態は、高度分散リソースルックアップを可能にする。一実施例では、クライアントは、リソースの発見および読み出しに先立って、リソースＵＲＩを把握する必要はない。例えば、クライアントは、その個別のホームＲＤへのリンクパラメータベースのクエリを規定する、リソースを要求およびルックアップしてもよい。言い換えると、分散リソースディレクトリは、クライアントへのリンクパラメータベースのクエリを満たす、リソースを返すことができる。

記憶補助（ＳＡ）実装と称され得る、例示的実施形態では、リソース登録の冗長コピーが、複数のピア内に提供される。本明細書では、データ記憶容量が増加するにつれて、そのようなデータ記憶と関連付けられたコストが減少すると認識され、したがって、ピアは、データ記憶能力を効率的に具備することができる。以下に詳細に説明されるように、ピアは、リソースの値内の可能性として考えられるキーワード／パラメータにハッシュ関数を使用することによって、データ記憶のために選定されてもよい。選定されるピアは、その記憶能力を使用して、リソース登録を記憶してもよい。ある場合には、Ｈ（）として示される、１つのハッシュ関数が、適用され、全リソースディレクトリピア間に統合および分散ハッシュ空間を生成すると仮定される。

便宜上、本明細書で使用されるように、別様に規定されない限り、ピアＲＤは、単に、ピアと称され得る。クライアントは、一例として、限定ではないが、以下の提示されるもの等の種々のルックアップキーワード／パラメータを指定することができる。
・ｄ：ドメイン
・ｅｐ：エンドポイント
・ｇｐ：グループ名
・ｅｔ：エンドポイントタイプ
・ｒｔ：リソースタイプ
・ｌｔ：リソース有効期間
・ｉｆ：インターフェース

さらに例証するために、以下は、限定として提示されるわけではないが、１つまたはそれを上回るＲＤピアに登録され得る、リソースおよびそのペイロードの実施例である。
１． ｅｐ＝９９９６１７２
ｐａｙｌｏａｄ：＜／ｔｅｍｐｅｒａｔｕｒｅ−１＞；ｌｔ＝４１；ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”；ｉｆ＝”ｓｅｎｓｏｒ”，
＜／ｔｅｍｐｅｒａｔｕｒｅ−２＞；ｌｔ＝４１；ｒｔ＝”ＬｉｇｈｔＬｕｘ”；ｉｆ＝”ｓｅｎｓｏｒ”
２． ｅｐ＝９２３４５７１
ｐａｙｌｏａｄ：＜／Ｔｅｍｐ−１＞；ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”；ｉｆ＝”ｇａｔｅｗａｙ”
３． ｇｐ＝ｌｉｇｈｔｓ
ｐａｙｌｏａｄ：＜ｃｏａｐ：／／ｈｏｓｔ１：ｐｏｒｔ１＞；ｅｐ＝”ｎｏｄｅ１”；ｄ＝”ｄｏｍａｉｎ１”
＜ｃｏａｐ：／／ｈｏｓｔ１：ｐｏｒｔ１＞；ｅｐ＝”ｎｏｄｅ２”；ｄ＝”ｄｏｍａｉｎ１”
４． ｇｐ＝ｐｒｅｓｓｕｒｅ
Ｐａｙｌｏａｄ＜ｃｏａｐ：／／ｈｏｓｔ２：ｐｏｒｔ２＞；ｅｐ＝”ｎｏｄｅ２”；ｄ＝”ｄｏｍａｉｎ１”

例示的実施形態では、所与のエンドポイントは、種々の方法において候補ＩＰアドレスを得ることによって、ディレクトリサーバを見出すことができる。例えば、ある場合には、各ピアＲＤは、少なくとも以下のベースＲＤリソース：＜／ｒｄ＞；ｒｔ＝”ｃｏｒｅ．ｒｄ”；＜／ｒｄ−ｌｏｏｋｕｐ＞；ｒｔ＝”ｃｏｒｅ．ｒｄ−ｌｏｏｋｕｐ”および＜／ｒｄ−ｇｒｏｕｐ＞；ｒｔ＝”ｃｏｒｅ．ｒｄ−ｇｒｏｕｐ”を有する。本明細書に説明されるように、エンドポイントは、リソースインターフェースを使用して、そのリソースをそのホームＲＤに登録してもよい。本インターフェースは、ＰＯＳＴをエンドポイントから受け取ってもよい。ＰＯＳＴは、ＣｏＲＥリンクフォーマット内にメッセージペイロードとしてディレクトリに追加されるべきリソースのリストを含有してもよい。ＰＯＳＴはまた、クエリストリングパラメータを含有してもよい。ある場合には、エンドポイントまたはグループ名のみをハッシュする代わりに、ピアＲＤは、ハッシュ関数をリソースのペイロード（例えば、リソースリンクフォーマット記述）内に含有される全パラメータおよびその値に適用してもよい。ハッシュ関数が適用された後、ホームＲＤは、同一パラメータを有するリソースを記憶することに関与する、ピアのアドレスを得てもよい。したがって、ピアの大記憶容量およびそれと関連付けられた低コストを活用することによって、ホームＲＤは、リソースペイロードをハッシュされたピアに送信してもよい。前述のように、例示的ＳＡ実装をさらに説明するために本明細書に説明される、４つの例示的リソースおよびペイロードが、存在する。図４にＥＰ７０２として図示されるＥＰ９９９６１７２のリソース登録を含む、実施例が、最初に説明される。

図７−２１（本明細書に後述される）は、リソースを管理および読み出すための方法および装置の種々の実施形態を図示する。これらの図では、種々のステップまたは動作は、１つまたはそれを上回るエンドポイント、クライアント、および／またはピアによって行われるように示される。これらの図に図示されるエンドポイント、クライアント、および／またはピアは、通信ネットワーク内の論理エンティティを表してもよく、以下に説明される図２２Ｃまたは２２Ｄに図示される一般的アーキテクチャの１つを備え得る、そのようなネットワークのノードのメモリ内に記憶され、そのプロセッサ上で実行される、ソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装されてもよいことを理解されたい。すなわち、図７−２１に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装されてもよく、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図に図示されるステップを行う。また、これらの図に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれを実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路（例えば、それぞれ、図２２Ｃおよび２２Ｄの回路３４または９７）によって行われてもよいことを理解されたい。

ここで図７を参照すると、例示的ネットワーク７００は、ＥＰ７０２と、ピア１、３、５、および１１（Ｐ１、Ｐ３、Ｐ５、およびＰ１１）とを含む。例示的ネットワーク７００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク４００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。さらに、参照番号は、図中の同一または類似特徴を示すために、種々の図で繰り返され得ることを理解されたい。

示されるように、図示される実施例によると、エンドポイント７０２は、９９９６１７２という名前を有し、７０４において、そのホームＲＤである、Ｐ１にそのリソースを登録する。７０６において、Ｐ１は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｅｐ＝９９９６１７２
・ｌｔ＝４１
・ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”
・ｒｔ＝”ＬｉｇｈｔＬｕｘ”
・ｉｆ＝”ｓｅｎｓｏｒ”

前述のキーワード／パラメータは、ハッシュ関数に適用されるためのキーとして使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ３、Ｐ５、およびＰ１１を含む。したがって、７０８ａ、７０８ｂ、および７０８ｃにおいて、Ｐ１は、それぞれ、登録メッセージをＰ３、Ｐ５、およびＰ７に自動転送する。ピアＰ３、Ｐ５、およびＰ７はそれぞれ、ペイロードを記憶し、確認をＰ１に返す（７１０ａ−ｃ）。７１２において、Ｐ１は、確認応答を組み合わせてもよい。７１４において、確認に応答して、Ｐ１は、ＥＰ７０２に返信する。ある場合には、異なるキーは、登録メッセージが同一ピアＲＤに自動転送される結果をもたらす。例えば、ｌｔ＝４１またはｉｆ＝“ｓｅｎｓｏｒ”をハッシュするとき、両ハッシュの結果は、Ｐ５がピアリソースディレクトリであるべきことを示し得る。同様に、ｒｔ＝‘Ｔｅｍｐｅｒａｔｕｒｅ”およびｒｔ＝“ＬｉｇｈｔＬｕｘ”をハッシュするとき、両ハッシュの結果は、Ｐ１１がピアリソースディレクトリであるべきことを示し得る。

ここで図８を参照すると、例示的ネットワーク８００は、ＥＰ８０２として図示されるＥＰ９２３４５７１と、ピア３、２、１１、および６（Ｐ３、Ｐ２、Ｐ１１、およびＰ６）とを含む。例示的ネットワーク８００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク８００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、図示される実施例によると、エンドポイント８０２は、９２３４５７１という名前を有し、８０４において、そのホームＲＤである、Ｐ３にそのリソースを登録する。８０６において、Ｐ３は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｅｐ＝９２３４５７１
・ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”
・ｉｆ＝”ｇａｔｅｗａｙ”

前述のキーワード／パラメータは、ハッシュ関数の入力として使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ２、Ｐ１１、およびＰ５を含む。したがって、８０８ａ、８０８ｂ、および８０８ｃにおいて、Ｐ３は、それぞれ、登録メッセージをＰ２、Ｐ１１、およびＰ５に自動転送する。ピアＰ２、Ｐ１１、およびＰ５はそれぞれ、ペイロードを記憶し、確認をＰ３に返す（８１０ａ−ｃ）。８１２において、Ｐ３は、確認応答を組み合わせてもよい。８１４において、確認に応答して、Ｐ３は、ＥＰ８０２に返信する。

ここで図９を参照すると、例示的実施形態による、「光」グループ登録実施例が、提示される。示されるように、例示的ネットワーク９００は、以下に説明されるように、管理ノードでもある、ＥＰ９０２と、ピア１、３、６、および２（Ｐ１、Ｐ３、Ｐ６、およびＰ２）とを含む。例示的ネットワーク９００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク９００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、図示される実施例によると、管理ノード（ＥＰ９０２）は、グループを構成するために使用される。９０４において、ＥＰ９０２は、そのホームＲＤ（Ｐ１）に要求を行う。要求は、作成するためのグループ名と、グループが属する随意のドメインとを示す。登録メッセージはまた、そのグループが属するエンドポイントのリストを含んでもよい。９０６において、Ｐ１は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｇｐ＝ｌｉｇｈｔｓ
・ｅｐ＝”ｎｏｄｅ１”
・ｄ＝”ｄｏｍａｉｎ１”
・ｅｐ＝”ｎｏｄｅ２”

前述のキーワード／パラメータは、ハッシュ関数の入力として使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１、Ｐ３、Ｐ６、およびＰ２を含む。したがって、９０８ａ、９０８ｂ、および９０８ｃにおいて、Ｐ１は、それぞれ、登録メッセージをＰ３、Ｐ６、およびＰ２に自動転送する。ピアＰ３、Ｐ６、およびＰ２はそれぞれ、ペイロードを記憶し、確認をＰ１に返す（９１０ａ−ｃ）。Ｐ１は、ハッシュされたピアの１つであるため、また、９０７において、登録メッセージを記憶してもよい。９１２において、Ｐ３は、確認応答を組み合わせてもよい。９１４において、確認に応答して、Ｐ３は、ＥＰ９０２に返信する。

ここで図１０を参照すると、例示的実施形態による、「圧力」グループ登録実施例が、提示される。示されるように、例示的ネットワーク１０００は、以下に説明されるように、管理ノードでもある、ＥＰ１００２と、ピア１、３、６、および２（Ｐ１、Ｐ３、Ｐ６、およびＰ２）とを含む。例示的ネットワーク１０００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１０００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、図示される実施例によると、管理ノード（ＥＰ９０２）は、グループを構成するために使用される。１００４では、ＥＰ１００２は、そのホームＲＤ（Ｐ１）に要求を行う。要求は、作成するためのグループ名と、グループが属する随意のドメインとを示す。登録メッセージはまた、そのグループが属するエンドポイントのリストを含んでもよい。１００６において、Ｐ１は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｇｐ＝ｐｒｅｓｓｕｒｅ
・ｄ＝”ｄｏｍａｉｎ１”
・ｅｐ＝”ｎｏｄｅ２”

前述のキーワード／パラメータは、ハッシュ関数の入力として使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１、Ｐ３、Ｐ６、およびＰ２を含む。したがって、１００８ａ、１００８ｂ、および１００８ｃにおいて、Ｐ１は、それぞれ、登録メッセージをＰ３、Ｐ６、およびＰ２に自動転送する。ピアＰ３、Ｐ６、およびＰ２はそれぞれ、ペイロードを記憶し、確認をＰ１に返す（１０１０ａ−ｃ）。Ｐ１は、ハッシュされたピアの１つであるため、また、１００７において、登録メッセージを記憶してもよい。１０１２において、Ｐ３は、確認応答を組み合わせてもよい。９１４において、確認に応答して、Ｐ３は、ＥＰ１００２に返信する。

一例として、分散リソースおよびグループ登録が、図７−１０を参照して説明されるように行われた後、ピアＲＤは、一例として提示され限定するものではないが、表１（以下）に示される情報を記憶してもよい。

ある場合には、前述のリソースおよびグループ登録方法は、リソースおよびグループが、前述の既存のルックアップ（発見）インターフェースを介して、ルックアップ（発見）されることを可能にする。ここで、背景として、リソースおよびグループルックアップに目を向けると、クライアントは、リソースルックアップ要求をそのホームＲＤに送信する。リソースルックアップ要求は、クライアントが発見することを所望するルックアップタイプおよびパラメータを指定することができる。ホームＲＤは、要求を分析し、クライアントが規定するキーを抽出してもよい。例示的実施形態では、ホームＲＤは、それらのキーにハッシュ関数を適用し、リソース登録を記憶するピアＲＤを算出する。キーは、ＡＮＤ／ＯＲによって接続されてもよい。例えば、キーは、得られたＲＤ（ハッシュ関数が適用された後に示されるＲＤＳ）のそれぞれが、同一リソース登録を記憶するため、ＡＮＤによって接続されてもよく、要求は、それらのうちの１つに自動転送されてもよい。ホームＲＤは、ランダムに、または、例えば、宛先ＲＤの負荷もしくはホームＲＤと宛先ＲＤとの間の帯域幅等のあるコンテキスト情報に基づいて、宛先ＲＤをピックアップしてもよい。キーは、規定された要求を満たすリソースが、得られたＲＤを横断して分散され得る可能性があるとき、ＯＲによって接続されてもよい。その結果、ホームＲＤは、要求を全ての得られたＲＤに自動転送し、リソースの結合セットを受信する必要があり得る。

ホームＲＤは、要求が自動転送されるべきピアＲＤを判定してもよい。ホームＲＤが応答をピアＲＤから受信した後、例えば、重複なく、リソースの完全リストを含有する、ルックアップ結果を生成してもよく、リストを要求側クライアントに返してもよい。

種々の例示的実施形態による、リソースおよびグループルックアップを例証するための実施例が、以下に提示される。図１１を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｒｅｓ？ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”ＡＮＤ ｉｔ＝”ｇａｔｅｗａｙ”ルックアップ要求を含む、実施例が、図示される。図１１は、クライアント１１０２と、ホームＲＤ１１０４と、ピア１１（Ｐ１１）とを含む、例示的ネットワーク１１００を示す。例示的ネットワーク１１００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１１００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、１１０６において、クライアント１１０２は、リソースルックアップ要求をそのホームＲＤ１１０４に送信する。クライアント１１０２は、同時に、ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”およびｉｔ＝”ｇａｔｅｗａｙ”を満たすリソースを得ることを所望する。１１０８において、ホームＲＤは、ハッシュ関数を要求内に示される２つのキーに適用する。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１１およびＰ６を含む。例示的側面では、ホームＲＤ１１０４は、完全リソースルックアップ結果を得るために、示されるＲＤ（Ｐ１１およびＰ６）のうちのいずれか一方を選定してもよい。図示される実施例では、ホームＲＤは、１１１０において、Ｐ１１を選定し、ルックアップ要求をＰ１１に送信する。１１１２において、Ｐ１１は、要求と関連付けられた応答をホームＲＤ１１０４に返す。ホームＲＤ１１０４は、１１１４において、応答をクライアント１１０２に自動転送する。

図１２を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｒｅｓ？ｒｔ＝”ＬｉｇｈｔＬｕｘ”ＯＲ ｉｔ＝”ｇａｔｅｗａｙ”要求を含む、実施例が、図示される。図１２は、クライアント１２０２と、ホームＲＤ１２０４と、ピア１１（Ｐ１１）および６（Ｐ６）とを含む、例示的ネットワーク１２００を示す。例示的ネットワーク１２００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１２００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、１２０６において、クライアント１２０２は、リソースルックアップ要求をそのホームＲＤ１２０４に送信する。クライアント１２０２は、ｒｔ＝”ＬｉｇｈｔＬｕｘ”またはｉｔ＝”ｇａｔｅｗａｙ”を満たすリソースを得ることを所望する。１２０８において、ホームＲＤは、ハッシュ関数を要求内に示される２つのキーに適用する。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１１およびＰ６を含む。例示的側面では、ＯＲは、キーを接続しているので、ホームＲＤ１１０４は、完全リソースルックアップ結果を得るために、示されるＲＤ（Ｐ１１およびＰ６）の両方に要求を自動転送することを必要とする。したがって、図示される実施例では、ホームＲＤは、ルックアップ要求をＰ１１（１２１０ａ）およびＰ６（１２１０ｂ）に送信する。１２１２ａおよび１２１２ｂにおいて、Ｐ１１およびＰ６は、それぞれ、要求と関連付けられた応答をホームＲＤ１２０４に返す。１２１４において、ホームＲＤは、受信された応答を組み合わせてもよい。さらに、１２１４において、ホームＲＤ１２０４は、重複応答が排除されるように結果を組み合わせてもよい。１２１６において、ホームＲＤは、完全ルックアップ結果である、組み合わせられた応答を、クライアント１２０２に送信し、それによって、ルックアップ要求を満たす。

ここで図１３を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｇｐ？ｄ＝”ｄｏｍａｉｎ１”ルックアップ要求を含む、グループルックアップ要求の実施例が、図示される。図１３は、クライアント１３０２と、ホームＲＤ１３０４と、ピア１（Ｐ１）とを含む、例示的ネットワーク１３００を示す。例示的ネットワーク１３００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１３００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、１３０６において、クライアント１３０２は、リソースルックアップ要求をそのホームＲＤ１３０４に送信する。クライアント１３０２は、ｄ＝“ｄｏｍａｉｎ１”を満たすグループを得ることを所望する。１３０８において、ホームＲＤは、ハッシュ関数を要求（ｄ＝“ｄｏｍａｉｎ１”）内に示されるキーに適用する。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１を含む。図示される実施例では、ホームＲＤ１３０４は、１３１０において、ルックアップ要求をＰ１に送信する。１３１２において、Ｐ１１は、要求と関連付けられた応答をホームＲＤ１３０４に返す。ホームＲＤ１３０４は、１３１４において、応答をクライアント１３０２に自動転送する。

ここで図１４を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｇｐ？ｅｐ＝”ｎｏｄｅ２”ルックアップ要求を含む、グループルックアップ要求の実施例が、図示される。図１４は、クライアント１４０２と、ホームＲＤ１４０４と、ピア２（Ｐ２）とを含む、例示的ネットワーク１４００を示す。例示的ネットワーク１４００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１４００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、１４０６において、クライアント１４０２は、リソースルックアップ要求をそのホームＲＤ１４０４に送信する。クライアント１４０２は、その中にエンドポイント（ｎｏｄｅ２）を伴うグループを得ることを所望する。１４０８において、ホームＲＤは、ハッシュ関数を要求（ｅｐ＝“ｎｏｄｅ２”）内に示されるキーに適用する。ハッシュ関数が、実施例に従って適用されると、結果は、ｎｏｄｅ２である、Ｐ２を含む。図示される実施例では、ホームＲＤ１４０４は、１４１０において、ルックアップ要求をＰ２に送信する。１４１２において、Ｐ１は、要求と関連付けられた応答をホームＲＤ１４０４に返す。ホームＲＤ１４０４は、１４１４において、応答をクライアント１４０２に自動転送する。

参照支援（ＲＥ）実装と称され得る、別の例示的実施形態では、ピアＲＤは、例えば、リソース自体を記憶するのではなく、記憶ＲＤの参照を保つ。

ここで図１５を参照すると、ＥＰ７０２と、ピア１、３、５、および１１（Ｐ１、Ｐ３、Ｐ５、およびＰ１１）とを含む、例示的ネットワーク７００が、示される。示されるように、図示される実施例によると、エンドポイント７０２は、９９９６１７２という名前を有し、１５０４において、そのホームＲＤである、Ｐ１にそのリソースを登録する。１５０６において、Ｐ１は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｅｐ＝９９９６１７２
・ｌｔ＝４１
・ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”
・ｒｔ＝”ＬｉｇｈｔＬｕｘ”
・ｉｆ＝”ｓｅｎｓｏｒ”

前述のキーワード／パラメータは、ハッシュ関数に適用されるためのキーとして使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ３、Ｐ５、およびＰ１１を含む。さらに、図示される実施例によると、１５０６において、Ｐ１は、登録メッセージが自動転送される、３つの結果として生じるＲＤ（Ｐ３、Ｐ５、またはＰ１１）のうちの１つを選定してもよい。１５０８において、Ｐ１は、登録メッセージを選定されるピア（Ｐ３）に自動転送する。１５１０において、Ｐ３は、ペイロードを記憶し、確認をＰ１に返す。１５１４ａおよび１５１４ｂにおいて、Ｐ１は、それぞれ、Ｐ５およびＰ１１に、登録メッセージがＰ３に記憶されていることを通知する。１５１６ａおよび１５１６ｂにおいて、Ｐ５およびＰ１１は、それぞれ、将来的リソースルックアップのために、Ｐ３のアドレスを適切な参照下に記憶する。１５１２において、Ｐ１は、ＥＰ７０２に返信し、それによって、リソース要求を満たす。

ここで図１６を参照すると、ＥＰ８０２と、ピア１、３、５、および１１（Ｐ３、Ｐ２、Ｐ１１、およびＰ６）とを含む、例示的ネットワーク８００が、示される。示されるように、図示される実施例によると、エンドポイント８０２は、１６０４において、そのホームＲＤである、Ｐ３にそのリソースを登録する。１６０６において、Ｐ３は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｅｐ＝９２３４５７１
・ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”
・ｉｆ＝”ｇａｔｅｗａｙ”

前述のキーワード／パラメータは、ハッシュ関数に適用されるためのキーとして使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ２、Ｐ１１、およびＰ６を含む。さらに、図示される実施例によると、１６０６において、Ｐ３は、登録メッセージが自動転送される、３つの結果として生じるＲＤ（Ｐ２、Ｐ１１、またはＰ６）のうちの１つを選定してもよい。１６０８において、Ｐ３は、登録メッセージを選定されたピア（Ｐ２）に自動転送する。１６１０において、Ｐ２は、ペイロードを記憶し、確認をＰ３に返す。１６１４ａおよび１６１４ｂにおいて、Ｐ３は、それぞれ、Ｐ１１およびＰ６に、登録メッセージがＰ２に記憶されていることを通知する。１６１６ａおよび１６１６ｂにおいて、Ｐ１１およびＰ６は、それぞれ、将来的リソースルックアップのために、Ｐ２のアドレスを適切な参照下に記憶する。１６１２において、Ｐ１は、ＥＰ８０２に返信し、それによって、リソース要求を満たす。

ここで図１７を参照すると、例示的実施形態による、「光」グループ登録実施例が、提示される。示されるように、例示的ネットワーク９００は、以下に説明されるように、管理ノードでもある、ＥＰ９０２と、ピア１、３、６、および２（Ｐ１、Ｐ３、Ｐ６、およびＰ２）とを含む。１７０４において、ＥＰ９０２は、そのホームＲＤ（Ｐ１）に要求を行う。要求は、作成するためのグループ名と、グループが属する随意のドメインとを示す。登録メッセージはまた、そのグループが属するエンドポイントのリストを含んでもよい。１７０６において、Ｐ１は、ペイロード内に含有されるリンクフォーマットを解釈し、本登録と関連付けられたキーワード／パラメータが、以下であることを判定してもよい。
・ｇｐ＝ｌｉｇｈｔｓ
・ｅｐ＝”ｎｏｄｅ１”
・ｄ＝”ｄｏｍａｉｎ１”
・ｅｐ＝”ｎｏｄｅ２”

前述のキーワード／パラメータは、ハッシュ関数の入力として使用されてもよい。ハッシュ関数が、実施例に従って適用されると、結果は、Ｐ１、Ｐ３、Ｐ６、およびＰ２を含む。示されるように、１７０８において、Ｐ１は、登録をそれ自体に記憶し、例えば、登録メッセージを自動転送する際に使用されるネットワーク帯域幅を保存する。１７１２ａ−ｃにおいて、Ｐ１は、Ｐ３、Ｐ６、およびＰ２に、ピアがそれぞれ関与するパラメータを含む、リソース登録がＰ１内に記憶されていることを通知してもよい。１７１４ａ−ｃにおいて、Ｐ３、Ｐ６、およびＰ２は、将来的リソースルックアップのために、Ｐ１のアドレスを適切な参照下に記憶してもよい。１７１０において、結果は、ＥＰ９０２に送信される。

ここで図１８を参照すると、例示的実施形態による、「圧力」グループ登録実施例が、提示される。示されるように、例示的ネットワーク１８００は、ＥＰ１８０２と、ピア１および１１とを含む。例示的ネットワーク１８００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１８００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

１８０４において、ピアＰ１は、グループ登録要求を受信してもよい。１８０６において、ハッシュ関数は、グループリソースをピアＲＤ Ｐ１１、Ｐ１、およびＰ２にマップしてもよい。１８０８において、Ｐ１は、登録をそれ自体に記憶し、登録メッセージを自動転送する際のネットワーク帯域幅使用を保存してもよい。１８１０において、Ｐ１は、Ｐ１１に、リソース登録がＰ１内に記憶されていることを通知してもよい。示されるように、Ｐ１のアドレスは、Ｐ２にすでに通知されているため（１８０４）、Ｐ２は、１８１０において通知される必要はない。１８１２において、Ｐ１１は、将来的リソースルックアップのために、Ｐ１のアドレスを適切な参照下に記憶してもよい。

例示的実施形態では、前述の実施例に説明される分散リソースおよびグループ登録が生じた後、ピアＲＤは、表２（以下）に示される情報を記憶してもよい。

ここで、リソースおよびグループルックアップ実装に目を向けると、別の例示的実施形態では、クライアントは、リソースおよびグループルックアップ要求をそのホームＲＤに送信してもよい。ホームＲＤは、ハッシュ関数をパラメータに使用することによって、要求内に規定されたパラメータに対応する関与ピアＲＤを判定してもよい。一実施例では、１つのみのパラメータが、要求内に含有され、ホームＲＤは、要求を関与ＲＤに自動転送してもよい。関与ＲＤは、要求内で規定されたルックアップタイプに基づいて、ｒｄまたはｒｄ−ｇｒｏｕｐディレクトリを検索してもよい。関与ＲＤはまた、要求をその参照カテゴリ内にリスト化されたＲＤに自動転送してもよい。ホームＲＤは、関与ＲＤおよび参照カテゴリ内のＲＤからの全応答を収集してもよく、結果をクライアントに返してもよい。別の例示的シナリオでは、要求内に複数のパラメータが含有され、パラメータは、ＡＮＤによって接続される。そのようなシナリオでは、ホームＲＤは、要求を関与ＲＤ（ＣｏＲＥ関与ＲＤ）のうちの１つに自動転送してもよい。ＣｏＲＥ関与ＲＤは、ハッシュ関数を他のパラメータに適用してもよく、他の関与ＲＤが存在することを判定してもよい。ＣｏＲＥ関与ＲＤは、参照カテゴリ内のリストのための要求もまた添付される、要求を他の関与ＲＤに自動転送してもよい。ＣｏＲＥ関与ＲＤは、全関与ＲＤの参照カテゴリ内のＲＤの結合セットを見出すことが可能である。ＣｏＲＥ関与ＲＤは、次いで、要求をＲＤの結合セットに自動転送してもよい。ＣｏＲＥ関与ＲＤは、全応答を収集してもよく、それらをホームＲＤに返してもよく、これは、順に、応答をクライアントに返す。

別の例示的シナリオでは、要求内に複数のパラメータが含有され、パラメータは、ＯＲによって接続される。そのようなシナリオでは、ホームＲＤは、要求を関与ＲＤ（ＣｏＲＥ関与ＲＤ）のうちの１つに自動転送してもよい。ＣｏＲＥ関与ＲＤは、ハッシュ関数を他のパラメータに適用してもよく、他の関与ＲＤが存在することを判定してもよい。ＣｏＲＥ関与ＲＤは、参照カテゴリ内のリストのための要求もまた添付される、要求を他の関与ＲＤに自動転送してもよい。ＣｏＲＥ関与ＲＤは、全関与ＲＤの参照カテゴリ内のＲＤの上位セットを発見することが可能である。ＣｏＲＥ関与ＲＤは、次いで、要求をＲＤの上位セットに自動転送してもよい。これは、全応答を収集してもよく、ホームＲＤに返してもよく、これは、順に、応答をクライアントに返す。

ここで図１９を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｒｅｓ？ｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”ＡＮＤ ｉｔ＝”ｇａｔｅｗａｙ”ルックアップ要求を含む、実施例が、図示される。図１９は、クライアント１９０２と、ホームＲＤ１９０４と、ピア１１、６、１、および２とを含む、例示的ネットワーク１９００を示す。例示的ネットワーク１９００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク１９００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、１９０６において、クライアント１９０２は、リソースルックアップ要求をそのホームＲＤ１９０４に送信する。クライアント１９０２は、同時にｒｔ＝”Ｔｅｍｐｅｒａｔｕｒｅ”およびｉｔ＝”ｇａｔｅｗａｙ”を満たすリソースを得ることを所望する。１９０８において、ホームＲＤ１９０４は、２つのキーをハッシュ関数に適用し、図示される実施例によると、Ｐ１１およびＰ６である、関与ＲＤを得てもよい。ホームＲＤ１９０４は、それらのうちのいずれか１つをＣｏＲＥ関与ＲＤとして選定してもよい。図示される実施例では、ホームＲＤ１９０４は、Ｐ１１を選定し、要求を適宜自動転送する（１９１０）。示されるように、Ｐ１１は、ハッシュ関数を他のパラメータに使用してもよく、Ｐ６もまた関与ＲＤであることを判定してもよい。１９１２において、Ｐ１１は、要求をＰ６に送信してもよく、参照リスト要求は、要求内に含まれてもよい（添付される）。実施例では、Ｐ６が、いかなる一致リソースも見出さない場合、１９１４において、Ｐ２およびＰ１のアドレスをＰ１１に返してもよい。１９１６において、Ｐ１１は、Ｐ１およびＰ２が結合セットを（両参照リスト内に）備えることを判定する。１９１８ａおよび１９１８ｂにおいて、Ｐ１１は、次いで、それぞれ、Ｐ１およびＰ２の両方に要求を自動転送してもよい。示されるように、図示される実施例によると、Ｐ１が、いかなる一致リソースも見出さない場合、１９２０ａにおいて、「該当なし」応答を返してもよい。図示される実施例によると、Ｐ２は、一致リソースを見出し、それをＰ１１に返す（１９２０ｂ）。１９２２において、Ｐ１１は、次いで、リソースをホームＲＤ１９０４に返してもよく、これは、順に、応答をクライアント１９０２に送信する（１９２４）。

ここで図２０を参照すると、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｒｅｓ？ｒｔ＝”ＬｉｇｈｔＬｕｘ”ＯＲ ｉｔ＝”ｇａｔｅｗａｙ”ルックアップ要求を含む、実施例が、図示される。図２０は、クライアント２００２と、ホームＲＤ２００４と、ピア１１、６、１、２、および３とを含む、例示的ネットワーク２０００を示す。例示的ネットワーク２０００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成も、ネットワーク２０００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用されてもよく、そのような実施形態は全て、本開示の範囲内と見なされる。

示されるように、２００６において、クライアント２００２は、リソースルックアップ要求をそのホームＲＤ２００４に送信する。クライアント２００２は、ｒｔ＝”ＬｉｇｈｔＬｕｘ”またはｉｔ＝”ｇａｔｅｗａｙ”を満たすリソースを得ることを所望する。２００８において、ホームＲＤ２００４は、２つのキーをハッシュ関数に適用し、図示される実施例では、Ｐ１１およびＰ６である、対応するＲＤを得てもよい。ホームＲＤ２００４は、それらのうちのいずれか１つ（図示される実施例ではＰ１１）をＣｏＲＥ関与ＲＤとして選定してもよい。Ｐ１１は、ハッシュ関数を他のパラメータに適用してもよく、Ｐ６もまた関与ＲＤであることを判定してもよい。２０１２において、Ｐ１１は、要求をＰ６に送信してもよく、参照リストもまた、添付されてもよい。２０１４において、Ｐ６が、いかなる一致リソースも見出さない場合、Ｐ２およびＰ１のアドレスをＰ１１に返してもよい。２０１６において、図示される実施例によると、Ｐ１１は、Ｐ１、Ｐ２、およびＰ３が両参照リストの上位セットであることを判定することが可能である。２０１８ａ−ｃにおいて、Ｐ１１は、次いで、それぞれ、要求をＰ１、Ｐ２、およびＰ３に自動転送してもよい。２０１８ａにおいて、Ｐ１が、いかなる一致リソースも見出さない場合、「該当なし」応答を返してもよい。２０１８ｂおよび２０１８ｃにおいて、Ｐ２およびＰ３は、一致リソースを見出し得、それをＰ１１に返してもよい。Ｐ１１は、全一致リソースを連結してもよく、それらをホームＲＤ２００４に返してもよく（２０２０）、これは、順に、応答をクライアント２００２に送信する（２０２２）。

図２１は、例示的実施形態による、別の例示的リソースルックアップ実施例４を図示する。本例示的実施形態では、クライアント２１０２は、グループルックアップを行ってもよい。２１０６において、クライアント２１０２は、ＧＥＴ／ｒｄ−ｌｏｏｋｕｐ／ｇｐ？ｅｐ＝“ｎｏｄｅ２”要求をそのホームＲＤ２１０４に送信する。示されるように、クライアント２１０２は、その中にエンドポイント（ｎｏｄｅ２）を伴うグループを得ることを所望する。２１０８において、ホームＲＤ２１０４は、キー（ｅｐ＝“ｎｏｄｅ２”）をハッシュ関数に適用し、図示される実施例ではＰ２である、対応するＲＤを得てもよい。ホームＲＤ２１０４は、２１１０において、要求をＰ２に自動転送してもよい。Ｐ２は、Ｐ１を参照カテゴリ内に記憶させてもよい。その結果、Ｐ２は、２１１２において、要求をＰ１に自動転送してもよい。２１１４において、図示される実施例によると、Ｐ１は、一致リソースを見出し、それらをＰ２に返す。２１１６において、Ｐ２は、応答をホームＲＤ２１０４に返してもよく、これは、順に、応答をクライアント２１０２に送信する（２１１６）。

したがって、前述の開示全体を通して説明されるように、ノードは、エンドポイントから受信されたメッセージペイロードと関連付けられた１つまたはそれを上回るキーを判定することができる。エンドポイントは、ウェブサーバ、Ｍ２Ｍデバイス、またはゲートウェイとして動作するように構成されてもよい。ノードは、プロセッサと、メモリと、通信回路とを含んでもよい。ノードは、その通信回路を介して通信ネットワークに接続されてもよく、ノードは、ノードのプロセッサによって実行されると、ノードに種々の動作を行わせる、ノードのメモリ内に記憶されるコンピュータ実行可能命令を含んでもよい。一実施例では、メッセージペイロードは、登録要求を含む。ノードは、１つまたはそれを上回るキーをハッシュ関数に適用し、マッピング情報を生成してもよい。前述のように、マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を含んでもよい。ノードは、マッピング情報に基づいて、メッセージペイロードを１つまたはそれを上回るピアリソースディレクトリサーバに伝送してもよい。ノードは、少なくとも１つの応答を１つまたはそれを上回るピアリソースディレクトリサーバから受信してもよい。少なくとも１つの応答は、リソースの場所を示してもよい。また、前述でも詳細に説明されるように、受信された少なくとも１つの応答に基づいて、ノード（例えば、リソースディレクトリサーバ）は、結果として生じる応答をエンドポイントに伝送してもよい。メッセージペイロードと関連付けられた１つまたはそれを上回るキーは、少なくとも１つのパラメータおよび少なくとも１つのパラメータと関連付けられた少なくとも１つの値を含んでもよい。少なくとも１つのパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、またはインターフェースを含んでもよい。前述で詳細に説明された一実施例では、少なくとも１つのパラメータは、複数のパラメータであり、少なくとも１つの値は、複数の値であり、ハッシュ関数は、登録要求内のパラメータおよび値のそれぞれに適用される。さらに、メッセージペイロードが伝送される、１つまたはそれを上回るピアリソースディレクトリサーバは、それぞれ、メッセージペイロードを記憶する、複数のピアリソースディレクトリサーバであってもよく、ノードは、メッセージペイロード内にあるパラメータの数に基づいて、複数のピアリソースディレクトリサーバ内のピアリソースディレクトリサーバの数を判定してもよい。代替として、また、前述に詳細に説明されるように、メッセージペイロードが伝送される、１つまたはそれを上回るピアリソースディレクトリサーバは、メッセージペイロードを記憶する、選択された１つのピアリソースディレクトリサーバであってもよく、ノードは、複数のピアリソースディレクトリサーバに、複数のピアリソースディレクトリが、メッセージペイロードを記憶する選択された１つのピアリソースディレクトリへの参照を記憶するように、選択された１つのピアリソースディレクトリへの参照を伝送してもよい。登録要求は、エンドポイント名およびそのリソース記述を含んでもよいことを理解されたい。

別の実施例では、メッセージペイロードは、リソースルックアップ要求を含み、メッセージペイロードと関連付けられた１つまたはそれを上回るキーは、１つまたはそれを上回るパラメータを含む。リソースルックアップ要求は、ルックアップタイプおよび１つまたはそれを上回るパラメータを含んでもよい。一実施例では、パラメータが、第１の論理連結語（例えば、ＡＮＤ）を使用して相互に接続される場合、ノードは、メッセージペイロードを複数のピアリソースディレクトリサーバに伝送する。複数とは、メッセージペイロード内のパラメータの数に基づいてもよい。別の実施例では、前述に詳細に説明されるように、パラメータが、第２の論理連結語（例えば、ＯＲ）を使用して相互に接続される場合、ノードは、メッセージペイロードを１つのみのピアリソースディレクトリサーバに伝送する。したがって、メッセージペイロードが伝送される、１つまたはそれを上回るピアリソースディレクトリサーバは、リソースルックアップ要求をマッピング情報によって示される他のピアリソースディレクトリサーバに伝搬する、選択された１つのピアリソースディレクトリサーバであってもよい。

図２２Ａは、１つまたはそれを上回る開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であってもよい。図７−２１のいずれかに図示される、クライアント、エンドポイント、ピア、またはリソースディレクトリのいずれかは、図２２Ａ−Ｄに図示されるもの等の通信システムのノードを備えてもよい。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ、または同等物）、または無線ネットワーク（例えば、ＷＬＡＮ、セルラー、または同等物）、もしくは異種ネットワークのネットワークであってもよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト、または同等物等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークを含んでいてもよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、および同等物等の１つまたはそれを上回るチャネルアクセス方法を採用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備えてもよい。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含んでもよい。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるノード（例えば、ネットワークのサーバ、ゲートウェイ、デバイス）を備えてもよい。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含んでもよい。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信してもよい。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信してもよい。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信されてもよい。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信してもよい。例示的Ｍ２Ｍデバイスとして、限定ではないが、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントが挙げられる。

図２２Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つまたはそれを上回るサーバ、コンピュータ、または同等物によって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用される、サービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装されてもよい。

図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用してもよい。Ｍ２Ｍサービス層２２’は、１つまたはそれを上回るサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）、または同等物によって実装されてもよい。

依然として、図２２Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配布能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、図２２Ａおよび２２Ｂに図示されるサービス層２２および２２’等のサービス層（ＳＬ）は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装されてもよい。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装されてもよい。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上にホストされ得る。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシン型通信（ＭＴＣ）のためのアーキテクチャを定義している。そのようなアーキテクチャでは、サービス層およびそれを提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬ内、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）内、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥ内、またはネットワークのある他のノード内に具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイスもしくはノードを含む、ネットワーク内の１つまたはそれを上回る独立型ノード上で、または１つまたはそれを上回る既存のノードの一部としてのいずれかで実行される、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令、および同等物）内に実装されてもよい。実施例として、サービス層またはその構成要素（例えば、ＡＳ／ＳＣＳ１００）のインスタンスは、以下に説明される図２２Ｃまたは２２Ｄに図示される一般的アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス、または同等物）上で起動されるソフトウェアの形態で実装されてもよい。

さらに、本明細書に説明される方法および機能性は、例えば、前述のネットワークおよびアプリケーション管理サービス等、サービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されてもよい。

図２２Ｃは、図２２Ａおよび２２Ｂに図示されるもの等のＭ２Ｍネットワーク内でＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図７−２１に図示されるクライアント、エンドポイント、ピア、またはリソースディレクトリのうちの１つ等のネットワークのノードの例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。図２２Ｃに示されるように、ノード３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非可撤性メモリ４４と、可撤性メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含んでもよい。ノード３０は、実施形態との整合を維持しながら、先述の要素の任意の副次的組み合わせを含み得ることを理解されたい。本ノードは、本明細書に説明されるリソースディレクトリ機能性を実装する、ノードであってもよい。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および同等物であってもよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはノード３０が無線環境で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結されてもよい。図２２Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行ってもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行ってもよい。

図２２Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して、他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御してもよい。特に、プロセッサ３２は、本明細書（例えば、図７−２１）および請求項に説明される伝送および受信ステップを行うために、通信回路を制御してもよい。図２２Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることを理解されたい。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、および同等物を含む、他のノードに信号を伝送する、または他のノードから信号を受信するように構成されてもよい。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー、および同等物等の種々のネットワークおよびエアインターフェースをサポートしてもよい。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成されてもよい。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２２Ｃで描写されているが、ノード３０は、任意の数の伝送／受信要素３６を含んでもよい。より具体的には、ノード３０は、ＭＩＭＯ技術を採用してもよい。したがって、実施形態では、ノード３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含んでもよい。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成されてもよい。上記のように、ノード３０は、マルチモード能力を有してもよい。したがって、送受信機３４は、ノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。

プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、ＵＥ（例えば、ＧＵＩ１４００参照）と、特に、ＵＥと通信する下層ネットワーク、アプリケーション、または他のサービスのステータスを反映させるように構成されてもよい。プロセッサ３２は、電源４８から電力を受け取ってもよく、ノード３０内の他の構成要素への電力の配信および／または制御のために構成されてもよい。電源４８は、ノード３０に電力供給するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。

プロセッサ３２はまた、ノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に連結されてもよい。ノード３０は、実施形態との整合を維持しながら、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、付加的な特徴、機能性、および／または有線もしくは無線接続を提供する、１つまたはそれを上回るソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に連結されてもよい。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および同等物を含んでもよい。

図２２Ｄは、図２２Ａおよび２２Ｂに図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図７−２１に図示されるクライアント、ピア、およびリソースディレクトリ等のネットワークの１つまたはそれを上回るノードを実装するためにもまた使用され得る、例示的コンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備えてもよく、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶もしくはアクセスされる。そのようなコンピュータ可読命令は、コンピュータシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行されてもよい。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理してもよい。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。

システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読取専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含有する。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変化されてもよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供してもよい。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含有してもよい。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでもよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子構成要素を含む。

さらに、コンピュータシステム９０は、例えば、図２２Ａおよび２２Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含有し、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にしてもよい。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、本明細書（例えば、図７−２１）および請求項に説明される伝送および受信ステップを行うために使用されてもよい。

本明細書で説明される方法およびプロセスのうちのいずれかは、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス、または同等物等のマシンによって実行されたときに、本明細書で説明されるシステム、方法、およびプロセスを実行および／または実装する、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることを理解されたい。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

図で図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

以下は、前述の説明において表出し得る、サービスレベル技術に関連する頭字語のリストである。別様に規定されない限り、本明細書で使用される頭字語は、以下にリスト化される対応する用語を指す。
ＣｏＡＰ 制約アプリケーションプロトコル
ＣｏＲＥ 制約ＲＥＳＴｆｕｌ環境
ＤＨＴ 分散ハッシュテーブル
ＤＲＤ 分散リソースディレクトリ
ＥＰ エンドポイント
ＨＴＴＰ ハイパーテキスト転送プロトコル
ＩＥＴＦ インターネット技術タスクフォース
ＩｏＴ モノのインターネット
Ｍ２Ｍ マシンツーマシン
ＭＡＣ 媒体アクセス制御
ＲＤ リソースディレクトリ
ＲＥ 参照支援機構
ＳＡ 記憶補助機構
ＵＲＩ 統一資源識別子

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含んでもよい。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。

Claims (20)

1. プロセッサとメモリと通信回路とを備えるノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに備え、前記コンピュータ実行可能な命令は、前記ノードの前記プロセッサによって実行されると、
   エンドポイントから受信されたメッセージペイロードに関連付けられた１つ以上のキーを判定することであって、前記メッセージペイロードは、リソースに関連付けられた登録要求を含む、ことと、
   前記１つ以上のキーをハッシュ関数に適用することにより、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を含む、ことと、
   前記マッピング情報に基づいて、前記メッセージペイロードを１つ以上のピアリソースディレクトリサーバに伝送することと、
   少なくとも１つの応答を前記１つ以上のピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、前記リソースが記憶されている前記１つ以上のピアリソースディレクトリサーバのそれぞれの場所を示す、ことと、
   前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと
   を前記ノードに行わせる、ノード。
2. 前記メッセージペイロードに関連付けられた前記１つ以上のキーは、少なくとも１つのパラメータと、前記少なくとも１つのパラメータに関連付けられた少なくとも１つの値とを含む、請求項１に記載のノード。
3. 前記少なくとも１つのパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、または、インターフェースを示す、請求項２に記載のノード。
4. 前記少なくとも１つのパラメータは、複数のパラメータであり、前記少なくとも１つの値は、複数の値であり、前記ハッシュ関数は、前記登録要求内の複数のパラメータおよび複数の値のそれぞれに適用される、請求項２に記載のノード。
5. 前記メッセージペイロードが伝送される前記１つ以上のピアリソースディレクトリサーバは、それぞれが前記メッセージペイロードを記憶する複数のピアリソースディレクトリサーバであり、前記コンピュータ実行可能な命令は、
   前記メッセージペイロード内にどのくらい多くのパラメータが存在するかに基づいて、前記複数のピアリソースディレクトリサーバ内にどのくらい多くのピアリソースディレクトリサーバが存在するかを判定すること
   を前記ノードにさらに行わせる、請求項４に記載のノード。
6. 前記メッセージペイロードが伝送される前記１つ以上のピアリソースディレクトリサーバは、前記メッセージペイロードを記憶する選択された１つのピアリソースディレクトリサーバであり、前記コンピュータ実行可能な命令は、
   複数のピアリソースディレクトリが、前記メッセージペイロードを記憶する前記選択された１つのピアリソースディレクトリへの参照を記憶するように、前記選択された１つのピアリソースディレクトリへの参照を前記複数のピアリソースディレクトリサーバに伝送すること
   を前記ノードにさらに行わせる、請求項４に記載のノード。
7. 前記登録要求は、前記エンドポイントの名前およびそのリソース記述を含む、請求項１に記載のノード。
8. 前記エンドポイントは、ウェブサーバ、マシンツーマシンデバイス、または、ゲートウェイとして動作するように構成されている、請求項１に記載のノード。
9. プロセッサとメモリと通信回路とを備えるノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに備え、前記コンピュータ実行可能な命令は、前記ノードのプロセッサによって実行されると、
   エンドポイントから受信されたメッセージペイロードに関連付けられた１つ以上のキーを判定することであって、前記メッセージペイロードは、リソースに関連付けられたリソースルックアップ要求を含む、ことと、
   前記１つ以上のキーをハッシュ関数に適用することにより、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を含む、ことと、
   前記マッピング情報に基づいて、前記メッセージペイロードを１つ以上のピアリソースディレクトリサーバに伝送することと、
   少なくとも１つの応答を前記１つ以上のピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、前記１つ以上のピアリソースディレクトリサーバ上に記憶されている前記リソースのコンテンツを含む、ことと、
   前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと
   を前記ノードに行わせる、ノード。
10. 前記メッセージペイロードに関連付けられた前記１つ以上のキーは、１つ以上のパラメータを含む、請求項９に記載のノード。
11. 前記１つ以上のパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、または、インターフェースを示す、請求項１０に記載のノード。
12. 前記リソースルックアップ要求は、ルックアップタイプと１つ以上のパラメータとを含む、請求項９に記載のノード。
13. 前記１つ以上のパラメータは、複数のパラメータであり、前記コンピュータ実行可能な命令は、
    前記複数のパラメータが、第１の論理連結語を使用して相互に接続される場合、前記メッセージペイロードを複数のピアリソースディレクトリサーバに伝送することであって、前記複数は、前記メッセージペイロード内にどのくらい多くのパラメータが存在するかに基づく、ことと、
    前記複数のパラメータが、第２の論理連結語を使用して相互に接続される場合、前記メッセージペイロードを１つのみのピアリソースディレクトリサーバに伝送することと
    を前記ノードにさらに行わせる、請求項１０に記載のノード。
14. 前記メッセージペイロードが伝送される前記１つ以上のピアリソースディレクトリサーバは、前記リソースルックアップ要求を前記マッピング情報によって示される他のピアリソースディレクトリサーバに伝搬する選択された１つのピアリソースディレクトリサーバである、請求項１０に記載のノード。
15. 前記エンドポイントは、ウェブサーバ、マシンツーマシンデバイス、または、ゲートウェイとして動作するように構成されている、請求項９に記載のノード。
16. 方法であって、
    リソースディレクトリサーバが、エンドポイントから受信されたメッセージペイロードに関連付けられた１つ以上のキーを判定することであって、前記メッセージペイロードは、リソースに関連付けられた登録要求またはリソースに関連付けられたリソースルックアップ要求のうちの少なくとも１つを含む、ことと、
    前記１つ以上のキーをハッシュ関数に適用することにより、マッピング情報を生成することであって、前記マッピング情報は、ピアリソースディレクトリサーバの少なくとも１つの識別を含む、ことと、
    前記マッピング情報に基づいて、前記メッセージペイロードを１つ以上のピアリソースディレクトリサーバに伝送することと、
    前記リソースディレクトリサーバにおいて、少なくとも１つの応答を前記１つ以上のピアリソースディレクトリサーバから受信することであって、前記少なくとも１つの応答は、前記リソースが記憶されている前記１つ以上のピアリソースディレクトリサーバのそれぞれの場所を示し、または、前記１つ以上のピアリソースディレクトリサーバ上に記憶されているリソースのコンテンツを含む、ことと、
    前記受信された少なくとも１つの応答に基づいて、結果として生じる応答を前記エンドポイントに伝送することと、
    を含む、方法。
17. 前記メッセージペイロードに関連付けられた前記１つ以上のキーは、少なくとも１つのパラメータと、前記少なくとも１つのパラメータに関連付けられた少なくとも１つの値とを含む、請求項１６に記載の方法。
18. 前記少なくとも１つのパラメータは、ドメイン、エンドポイント、グループ名、エンドポイントタイプ、リソースタイプ、リソース有効期間、または、インターフェースを示す、請求項１７に記載の方法。
19. 前記登録要求は、前記エンドポイントの名前およびそのリソース記述を含む、請求項１７に記載の方法。
20. 前記リソースルックアップ要求は、ルックアップタイプと１つ以上のパラメータとを含む、請求項１７に記載の方法。