JP2017516213A - リソースディレクトリのための検索エンジン最適化 - Google Patents

Abstract

進化型リソースディレクトリは、フィルタ処理された優先順序を付けられた検索結果を提供し得る。サーバとリソースディレクトリとを備えているネットワークでは、リソースディレクトリは、サーバから受信される複数のＵＲＩを登録する。リソースディレクトリは、複数のＵＲＩの各々の間のクロスリンクを測定することと、複数のＵＲＩのコンテキストを識別することとに基づいて、複数のＵＲＩに対する初期ランキングを決定し得る。初期ランキングは、ランク付けされたデータベースに記憶される。クライアントの検索クエリに応答して、リソースディレクトリは、ランク付けされたデータベースに記憶された複数のＵＲＩのリアルタイムランキングを決定し得る。リアルタイムランキングは、サーバの各々に対するスリープ状態をチェックすることに基づいて、および／またはサーバのトラフィック負荷に部分的に平衡を保たせることによって決定され得る。

Description

検索エンジン最適化は、ウェブ検索エンジン結果に影響を及ぼすために「普通の」（すなわち、非ＩｏＴ）インターネットで現在使用されている、頻用される方法である。経験から、大部分の場合において、たとえ返されたユニフォームリソースアイデンティファイア（以降ではＵＲＩと称される）の総数が約数百または数千ものＵＲＩ（例えば、Ｇｏｏｇｌｅ検索結果の多くのページ）であろうとも、人間のユーザは、ウェブ検索からの最初のいくつかの返されたＵＲＩのみから選択するであろうことが見出されている。つまり、最初の返されたウェブ検索結果ページの最上部にある最初のいくつかのＵＲＩのみが、典型的にはユーザによって選択され、全ての他のＵＲＩは、典型的には無視され、決してクリックされない。

普通のインターネット検索に対して、返されたＵＲＩは、ＨＴＴＰベースである。技術的には、これは、ＵＲＩの第１の部分（すなわち、スキーム）が「ｈｔｔｐ」を規定することを意味する。例えば、「ｈｔｔｐ：／／ｗｗｗ．ｂｅｓｔｃａｒｓ．ｃｏｍ」または「ｈｔｔｐｓ：／／ｍｙｂａｎｋ．ｃｏｍ」が、ＨＴＴＰ ＵＲＩの例である。

人間のユーザが、典型的には、ウェブ検索からの最初のいくつかの返されたＵＲＩのみに焦点を合わせるであろうという事実は、検索エンジン最適化の原因と結果の両方である。つまり、人間のユーザは、現代の検索エンジンが、ＵＲＩの返されたリストの最上部に最良の検索結果を暗黙的に置いているという事実に慣れてきている。検索エンジン最適化とは、検索エンジンが彼らのウェブサイトを比較的高くランク付けすることを確実にすることに役立てるために、ウェブサイト開発者によって使用される一組の技法を指す。

図１は、多くの場合、クロスリンキング、またはある時は、インバウンドリンキングと称される、頻用される検索エンジン最適化技法を図示する。このクロスリンキング技法は、所与のウェブサイトが他のウェブサイトから指し示されることを確実にすることである。それらを指し示す多くのクロスリンクを有するウェブサイトは、クロスリンキングがウェブサイトの人気の強力な尺度と見なされるので、検索エンジンによってより高くランク付けされる。クロスリンキングは、検索エンジンがワールドワイドウェブをクロールおよびマッピングするために定期的に利用するウェブクローラによって検出される。

別の頻用される検索エンジン最適化技法は、ウェブサイトコンテンツが選択されたキーワードを使用することを確実にすることである。これは、検索エンジンが、それらのランキングアルゴリズムへの入力の一部として、ウェブページ内のあるキーワードの頻度および分布を使用するからである。再度、これらのキーワードは、検索エンジンウェブクローラによって検出される。

インターネットリソース検索をサポートするための現在のＩｏＴモデルは、非常に単純であり、いかなる高度検索エンジン最適化のような概念もサポートしない。現在のＩｏＴでは、主要検索ノードは、ＩｏＴリソースを指し示すＵＲＩを記憶するリソースディレクトリである。これらのＵＲＩは、普通のインターネット検索エンジンで典型的に行われるように、ウェブクローラによって発見される代わりに、ＩｏＴサーバによってリソースディレクトリに直接プッシュされる。そして、リソースディレクトリは、特定のＩｏＴリソースを探しているクライアントによって、検索エンジンとして使用される。検索は、例えば、２０１３年１２月１１日に更新されたＣｏＲＥリソースディレクトリのインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｒｅｓｏｕｒｃｅ−ｄｉｒｅｃｔｏｒｙ−０１）で開示されるように、クライアントからの入力パラメータを介して調整されることができる。しかしながら、所与のクライアントの検索要求に対して、返されたＵＲＩのリストは、一律でフィルタ処理されておらず、潜在的に非常に大きい。

ＩｏＴのＵＲＩは、普通のインターネットの通りにＨＴＴＰベースであり得るか、または多くの場合、制約アプリケーションプロトコル（以降ではＣｏＡＰと称される）ベースであり得るかのいずれかである。ＣｏＡＰは、例えば、２０１３年６月２８日に更新された制約アプリケーションプトロコルのインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｃｏａｐ−１８）で開示されるように、制約されたデバイスのために特異的に設計されている最適化されたウェブ転送プロトコルであるが、その他の点では、ＨＴＴＰの表現状態転送（以降ではＲＥＳＴｆｕｌと称される）アプローチに従う。ＲＥＳＴｆｕｌとは、ウェブ転送プロトコルのための通信のステートレス要求／応答モデルを指す。

ＨＴＴＰアプローチと同様に、ＵＲＩの第１の部分（すなわち、スキーム）が「ｃｏａｐ」を規定する場合、ＣｏＡＰ ＵＲＩが識別されることができる。例えば、「ｃｏａｐ：／／ｔｅｍｐｓｅｎｓｏｒ．ｆｌｏｏｒ２．ｂｌｄｇ６」または「ｃｏａｐｓ：／／ｓｅｃｕｒｉｔｙｃａｍｅｒａ．ｈｏｍｅ」が、ＣｏＡＰ ＵＲＩの例である。さらに、ＩｏＴに対して、ＵＲＩとそれらの属性および関係との記述は、ＲＦＣ６６９０「制約ＲＥＳＴｆｕｌ環境リンク形式」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６６９０）で定義され、「ＣＯＲＥリンク形式」と称される。

以下の詳細な使用事例は、どのようにして現在のリソースディレクトリが稼働するか、およびその欠点のうちのいくつかを例証する。ある大工場が、建物を通して分配された１０００個の温度センサを有すると仮定される。図２は、それらのＵＲＩをリソースディレクトリに登録する、温度センサ２０２、２０４、および２０６を図示する。図２に示されるように、各センサ２０２、２０４、または２０６は、始動時に、（ＣｏＡＰ Ｐｏｓｔを介して）それらのリソース（ＵＲＩ）をローカルリソースディレクトリ２０８に登録するであろう。これは、リソースディレクトリがＵＲＩのデータベースを構築することを可能にするであろう。実践では、リソースディレクトリは、概して、範囲が制限される。例えば、大都市は、いくつかのリソースディレクトリを有し得る。しかしながら、理論上、いかなるものもリソースディレクトリ２０８の範囲が大域的であることを妨げない。リソースディレクトリの範囲は、完全に実装および開発の選択である。

図３は、クライアント３０２が温度センサのリストに対してリソースディレクトリにクエリを行う、実施例を図示する。温度センサ２０２、２０４、および２０６がそれらのＵＲＩをリソースディレクトリに登録した後、クライアントは、図３に示されるように（ＣｏＡＰ ＧＥＴを介して）検索クエリを送信する。検索クエリは、どのＵＲＩが工場のドメインにおける温度示度値を提供するであろうかを識別するようにリソースディレクトリに要求する。これは、クエリの一部である検索パラメータを通して規定される。

図４は、同一の例で、クライアント検索クエリに応答して、どのようにしてリソースディレクトリ２０８が温度センサのフィルタ処理されていないリストを返すかを図示する。リソースディレクトリは、それがそのデータベースに登録した１０００個の温度センサＵＲＩの完全なリストで（ＣｏＡＰ ＧＥＴ応答を介して）応答する。

この現在のＩｏＴモデルにおけるクライアントの課題が、図５に図示される。クライアントのクエリに応答して返される１０００個の温度センサのリストから、１０００個のＵＲＩのうちのどれにクライアントはアクセスを試みるべきか？基礎的仮定は、時間、帯域幅、処理能力等の制約により、クライアント３０２が１０００個全てのＵＲＩにアクセスすることは実用的ではないということである。

追加の背景情報として、例えば、「ｏｎｅＭ２Ｍ機能アーキテクチャ」、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．４２で開示されるようなｏｎｅＭ２Ｍは、コネクテッドカー、スマートヘルス等の異なるＭ２Ｍアプリケーションをサポートするように種々のハードウェアおよびソフトウェア内に容易に埋め込まれることができる共通サービス層を規定することを目標としている。共通サービス層としてのｏｎｅＭ２Ｍは、基本的に、一組の共通サービス機能、例えば、発見共通サービス機能を定義する。１つ以上の特定のタイプの共通サービス機能のセットのインスタンス化は、共通サービスエンティティと称される。共通サービスエンティティは、インフラストラクチャノード、中央ノード、またはアプリケーション特有のノード等の異なるタイプのネットワークノード上でホストされることができる。

図６は、ｏｎｅＭ２Ｍ機能アーキテクチャ６００を図示し、１）アプリケーションエンティティ（ＡＥ）６０２が、Ｍｃａインターフェースを介して共通サービスエンティティ（ＣＳＥ）６０４内の共通サービス機能にアクセスして活用することができ、２）共通サービスエンティティ６０４が、Ｍｃｃインターフェースを介して別の共通サービスエンティティ６０６と通信することができ、３）共通サービスエンティティ６０４がさらに、Ｍｃｎインターフェースを介して基礎的ネットワークからのネットワークサービスエンティティ（ＮＳＥ）６０８を活用することもできる。例えば、共通サービスエンティティとしてのＭ２Ｍサーバは、発見共通サービス機能を有し、発見共通サービス機能は、Ｍ２Ｍサーバ内で維持されるリソース、またはＭ２Ｍサーバがアクセスできる他の場所でさえも維持されるリソースを検索するために、アプリケーションエンティティによって活用されることができる。

普通のインターネットで高度検索エンジン最適化のために使用される技法は、いくつかの理由で、ＩｏＴまたはＭ２Ｍには直接使用されることができない。第１に、検索エンジン最適化技法の多くは、Ｇｏｏｇｌｅ等の強力な検索エンジンのモデルに基づく。このモデルでは、検索エンジンは、ウェブサイトプロパティ、例えば、クロスリンク、キーワード等を検出するために、ワールドワイドウェブ全体にわたってウェブクローラを利用する。しかしながら、ＩｏＴまたはＭ２Ｍモデルは、ＵＲＩを記憶するリソースディレクトリがあるが、これらのＵＲＩがサーバによってリソースディレクトリに直接プッシュされるという点で、根本的に異なる。加えて、リソースディレクトリは、ウェブ空間のプロパティを決定するために、いかなるタイプのウェブクローラも利用しない。ＩｏＴまたはＭ２Ｍモデルでは、リソースディレクトリは、特定のリソース、ＵＲＩを探しているクライアントによって、検索エンジンとして使用される。

第２に、大部分のＩｏＴまたはＭ２Ｍの場合、人間がＩｏＴまたはＭ２Ｍ検索に関与しない。普通のインターネットでのウェブ検索と異なり、ＩｏＴまたはＭ２Ｍ検索では、人間は、多数の返されたＵＲＩを伴う検索結果からいずれのＵＲＩを選択するかについて認識決定を行うことができない。代わりに、ＩｏＴまたはＭ２Ｍ検索では、検索結果は、典型的には、限定された意思決定および限定された処理能力を伴う制約されたデバイスに返される。最後に、普通のインターネットウェブサイトは、常に利用可能であると仮定される。しかしながら、ＩｏＴまたはＭ２Ｍでは、多くのサーバは、頻繁にスリープモードになり、したがって、常に利用可能ではない場合がある。この特性は、現在、普通のインターネットウェブ検索結果では考慮されない。

したがって、ＩｏＴまたはＭ２Ｍデバイスに最も効率的な検索結果を提供するであろう現在のリソースディレクトリ機能性に、より高度な検索エンジン最適化を追加する必要性がある。この高度検索エンジン最適化は、リソースディレクトリが、最良のＵＲＩを選択するための最適化された検索結果をクライアントに提供することを可能にし得る。

本明細書では、サーバと、リソースディレクトリとを備えているネットワーク内で、リソースディレクトリのための検索エンジン最適化を提供する方法、デバイス、およびシステムが説明される。例示的実施形態では、リソースディレクトリは、サーバから受信されるユニフォームリソースアイデンティファイアを登録する。リソースディレクトリは、ユニフォームリソースアイデンティファイアの各々の間のクロスリンクを測定することに基づいて、ユニフォームリソースアイデンティファイアの初期ランキングを決定し得る。より多くのユニフォームリソースアイデンティファイアが別のものにクロスリンクされるほど、ユニフォームリソースアイデンティファイアが高くランク付けされる。リソースディレクトリはさらに、ユニフォームリソースアイデンティファイアのコンテキストを識別することに基づいて、初期ランキングを決定し得る。ユニフォームリソースアイデンティファイアのコンテキストは、リソースタイプ、ドメイン、地理的場所、マルチキャスト、およびユニキャストを備え得る。リソースディレクトリは、同一のリソースタイプ等のコンテキストに基づいてユニフォームリソースアイデンティファイアのグループを選択し、そのグループを選択されていないユニフォームリソースアイデンティファイアのグループより高くランク付けし得る。初期ランキングを決定すると、リソースディレクトリは、初期ランキングを記憶するランク付けされたデータベースを生成し得る。

クライアントから受信される検索クエリに応答して、リソースディレクトリは、ランク付けされたデータベースに記憶されるユニフォームリソースアイデンティファイアのリアルタイムランキングを決定し得る。リアルタイムランキングは、サーバの各々に対するスリープ状態をチェックすることによって決定され得る。例えば、ユニフォームリソースアイデンティファイアが検索時にスリープしている場合、スリープしているユニフォームリソースアイデンティファイアは、起動している別のユニフォームリソースアイデンティファイアより低くランク付けされるか、またはスリープしているユニフォームリソースアイデンティファイアは、検索結果から完全に除去される。リアルタイムランキングはさらに、サーバのトラフィック負荷に部分的に平衡を保たせることに基づいて決定され得る。何回もより高くランク付けされているか、またはより高いトラフィックフローを有するものとして検出されている、ユニフォームリソースアイデンティファイアは、他のユニフォームリソースアイデンティファイアより低くランク付けされ得る。リアルタイムランキングを決定すると、リソースディレクトリは、フィルタ処理された優先順序を付けられたユニフォームリソースアイデンティファイアのランク付けされたリストを生成し、そのランク付けされたリストをクライアントに返し得る。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、さらに、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。
図１は、普通の（非ＩｏＴ）インターネットでサーバＡにクロスリンクすることの実施例を図示する系統図である。 図２は、それらのユニフォームリソースアイデンティファイアをリソースディレクトリに登録する温度センサを図示する系統図である。 図３は、クライアントが温度センサのリストに対してリソースディレクトリにクエリを行う実施例を図示する系統図である。 図４は、リソースディレクトリがフィルタ処理されていない温度センサのリストを返す実施例を図示する系統図である。 図５は、フィルタ処理されていないユニフォームリソースアイデンティファイアのリストからリソースを取得することにおけるクライアントの課題を描写する。 図６は、ｏｎｅＭ２Ｍサービス層機能アーキテクチャを図示する系統図である。 図７は、例示的実施形態による、進化型リソースディレクトリアーキテクチャを図示する系統図である。 図８は、例示的実施形態による、全体的リソースディレクトリプロシージャを図示する系統図である。 図９は、例示的実施形態による、ランキングをクロスリンクするためのサブプロシージャを図示する系統図である。 図１０は、例示的実施形態による、それらのユニフォームリソースアイデンティファイアをリソースディレクトリに登録する温度センサを図示する系統図である。 図１１は、例示的実施形態による、温度センサのリストに対してリソースディレクトリにクエリを行うクライアントを図示する系統図である。 図１２は、例示的実施形態による、フィルタ処理された温度センサのリストを返すリソースディレクトリを図示する系統図である。 図１３は、例示的実施形態による、最高ランクのユニフォームリソースアイデンティファイアのセットのみからリソースをフェッチするクライアントを図示する系統図である。 図１４は、例示的実施形態による、Ｍ２Ｍ／ＩｏＴサービス層内に検索エンジン最適化を伴うリソースディレクトリを図示する系統図である。 図１５は、例示的実施形態による、ｏｎｅＭ２Ｍ機能アーキテクチャにおける共通サービス機能内のリソースディレクトリを図示する系統図である。 図１６は、例示的実施形態による、リソース登録およびリソースクエリのための共通サーバ機能内のリソースディレクトリプロシージャを図示するフロー図である。 図１７は、グラフィカルユーザインターフェースの略図である。 図１８Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１８Ｂは、図１７Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１８Ｃは、図１８Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１８Ｄは、図１８Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

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

以下の略語および定義が、本開示で使用されるであろう。
ＡＥ： アプリケーションエンティティ
ＣｏＡＰ： 制約アプリケーションプロトコル
ＣＯＲＥ： 制約ＲＥＳＴｆｕｌ環境
クロスリンク： ２つのＵＲＩの間の定義された関係。具体的には、１つのＵＲＩが別のＵＲＩを指し示す（そこにつながる）。
ＣＳＥ： 共通サービスエンティティ
ＣＳＦ： 共通サービス機能
ＨＴＴＰ： ハイパーテキスト転送プトロコル
ＩＥＴＦ： インターネット技術タスクフォース
ＩｏＴ： モノのインターネット
Ｍ２Ｍ： マシンツーマシン
ＮＳＥ： ネットワークサービスエンティティ
ＲＤ： リソースディレクトリ
リソース： ＵＲＩによって識別され、ウェブ転送プロトコルによってアクセスされることができる、ネットワークデータオブジェクト、またはＳＷプロセス
ＲＥＳＴ： 表現状態転送（ウェブ転送プトロコルのための通信の状態がない要求／応答モデル）
ＳＥＯ： 検索エンジン最適化
ＵＲＩ： ユニフォームリソースアイデンティファイア（ＣｏＡＰまたはＨＴＴＰリソースを識別するために使用される文字列）
ウェブ検索： 所望の情報を含むウェブ（インターネット）上のＵＲＩを検索するように設計されているフトウェアシステム
ウェブ転送プトロコル： ウェブ（インターネット）にわたるリソースの転送のためのプトロコル。ＨＴＴＰおよびＣｏＡＰは、ＩｏＴのための主要プトロコルである。ウェブ転送プトロコルを使用するアプリケーションは、大きく異なり得る。一例は、ウェブブラウザ（クライアント）およびコンテンツサーバ（例えば、セキュリティビデオカメラ）である。別の例は、温度センサソフトウェア（クライアント）および制御サーバである。

本開示の進化型ＲＤは、ＲＤへのクライアント検索クエリに対してフィルタ処理された優先順序を付けられた検索結果を提供し得る。これは、クライアントが、クライアントが探しているリソースに対して最適化された検索結果に目を通し、最良のＵＲＩを迅速に選択することを可能にし得る。例示的実施形態では、ＲＤのアーキテクチャは、ＲＤ機能ブロックと、最初にＵＲＩを記憶し、後にクライアント検索要求に応答することに関する処理シーケンスとを含む。ＲＤ機能ブロックは、最良の検索結果をクライアントに提供することにおいて使用される以下のＵＲＩランキング／フィルタリング機能を含み得る。
・ 非活動ノード取り扱い：クライアント検索要求時に現在起動しているサーバに対応するＵＲＩをより高くランク付けする。現在スリープ状態のクライアントに関連付けられるＵＲＩは、除外されるか、またはより低くランク付けされることができるかのいずれかである。
・ 準負荷バランシング取り扱い：より少ない知覚された負荷を有するサーバに対応するＵＲＩをより高くランク付けする。
・ コンテキスト取り扱い：類似した物理的性質（例えば、温度センサ）を表し、かつ同一の論理ドメイン（例えば、サブネットワーク）からのＵＲＩの数を削減するためのＵＲＩのフィルタリング。さらに、マルチキャストグループに属するか、または要求クライアントと同一の地理的場所にあるＵＲＩをより高くランク付けする。
・ ＵＲＩクロスリンキング取り扱い：概して高値ＵＲＩを示すＵＲＩの間のリンクをチェックし、これらのＵＲＩをより高くランク付けする。

一実施形態では、既存のＩＥＴＦプトロコルは、ＲＤからクライアントに送信される検索結果においてＵＲＩのランキングを示すことをサポートするように変更され得る。さらに、クライアントは、初期検索要求クエリにおいて、クライアントが関心があるランクの範囲および他の情報を随意に示し得る。

（ＲＤアーキテクチャ）
図７は、例示的実施形態による、進化型ＲＤアーキテクチャ７００を図示する。具体的には、ＲＤ７０２内の情報の流れおよび処理ブロックが示される。以下は、高レベル説明である。

図７のステップ１では、ＲＤ７０２は、ＵＲＩのプッシュ（登録）およびＵＲＩのプル（クエリ）のための別個の論理データベースを有し得る。登録データベース７０４は、それらのＣｏＡＰリソースを登録するサーバから受信されるＵＲＩの未加工データベースであり得る。処理されたデータベース７０６は、クエリに対する応答を提供するために使用されることができる。

図７のステップ２では、ＲＤ７０２は、ＵＲＩの初期ランキングのための新しい処理ブロック７０８を有し得る。新しい処理ブロックは、初期ランキングを決定するために、クロスリンキングを測定すること、および／またはコンテキストを識別することを含み得る。これらの初期処理ブロック７０８は、将来のクライアント検索クエリから独立しているので、オフラインで、または背景処理として行われ得る。

図７のステップ３では、最初にランク付けされたＵＲＩは、次いで、ＵＲＩの別個の処理されたデータベース７０６に入れられる。未加工データベース７０４および処理されたデータベース７０６は、論理的に別個であり得ることに留意されたい。それらは、単一の物理的データベースで実装され得るか、または別個の物理的データベースで実装され得る。

図７のステップ４では、クライアント検索クエリは、ＲＤ７０２の処理されたデータベース７０６に進み得、処理されたデータベース７０６は、クライアントクエリパラメータに対応する最初にランク付けされたリストを引き出す。

図７のステップ５では、リアルタイム処理ブロック７１０が、スリープ状態および準負荷バランシングのために使用されることができる。ＲＤ７０２は、選択されたＵＲＩが現在スリープしているサーバ上にあるかどうかを決定するために、ＲＤ内で利用可能な情報に基づいてリアルタイムチェックを行い得る。サーバが現在スリープしている場合、これらの「スリープしている」ＵＲＩは、クライアントに返送される応答から完全に除外され得る。代替として、スリープしているＵＲＩは、最低にランク付けされ得る。ＲＤ７０２はさらに、ランキング機能がネットワーク内で同一のＵＲＩ（リソースサーバ）を最終的にいつも最高ランク付けしないことを確実にするように、ＲＤ７０２内の情報に基づいて準負荷バランシングを行い得る。準負荷バランシングも、リアルタイムプロセスである。

図７のステップ６では、ランク付けされ、フィルタ処理されたＵＲＩのリストが、その検索要求に対する応答としてクライアントに返される。最終ランキングは、異なる処理（サブランキング）ブロックにわたる加重平均であり得、ＵＲＩの静的（すなわち、初期ランキング）状態と動的（すなわち、リアルタイムランキング）状態との両方の組み合わせを考慮する。

上で説明されるように、ＲＤ７０２は、概して、範囲が制限される。例えば、大都市は、異なる場所にいくつかのＲＤを有し得る。しかしながら、理論上、いかなるものもＲＤ７０２の範囲が大域的であることを妨げない。進化型ＲＤ７０２の範囲は、完全に実装および開発の選択である。上で説明されるＳＥＯ技法は、単一のＲＤ７０２の範囲内で行われると仮定される。

図７に図示される機能性は、以下に説明される図１８Ｃまたは１８Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

（ＲＤランキングおよびフィルタリング機能）
図８は、例示的実施形態による、全体的ＲＤプロシージャを図示する。進化型ＲＤ７０２における全体的ＲＤプロシージャは、図７および８に図示されるようないくつかのランキングならびにフィルタリング機能を含み得る。図８の全体的ＲＤ７０２プロシージャの主要出力は、リストの中のＵＲＩの各々が、クライアント検索要求に対する応答として使用されるであろうランキングに関連付けられるＵＲＩのリストであり得る。さらに、いくつかまたは多くのＵＲＩが、通常、ＲＤプロシージャの最終出力から除外され得、クライアントによって見られないこともあることも留意されたい。

図８のステップ８０２では、ＵＲＩがサーバ８０１によって登録される。

図８のステップ８０４、８０６、８０８、および８１０は、ＵＲＩのランク付けされたデータベースを処理するために使用されるループを形成する。図８のループでは、ステップ８０６が、ＵＲＩのクロスリンキングを測定するために使用され、ステップ８０８が、所与のＵＲＩのコンテキストを識別するために使用される。

図８のステップ８１２では、ＵＲＩのデータベースが処理される。

図８のステップ８１４、８１６、８１８、および８２０は、クライアント３０２からの要求に応答するＲＤ７０２を示す。

図８のステップ８１４では、検索要求がクライアント３０２から受信される。

図８のステップ８１６では、最終的なランク付けされ、フィルタ処理された検索が、クライアント３０２に提供される。

図８に示されるＲＤプロシージャ全体は、クライアントからの同一検索要求（すなわち、同一の入力パラメータを伴うクエリ）の間で再実行される必要があり得る。これは、主にリアルタイムランキング機能のためである。この構成要素は、経時的に異なるランキング出力をもたらし得る。加えて、ＲＤプロシージャの変形例が、ランキングの同一の結果を達成することができる。例えば、ＵＲＩは、最初に、異なるグループ（例えば、クロスリンクを伴うＵＲＩのグループ、およびクロスリンクを伴わない別のグループ）に分類され得る。次いで、図８に示されるように、新しいＵＲＩが登録される度に、全てのＵＲＩを通してループすることが要求されないこともある。

一実施形態では、各ＵＲＩに関連付けられるランクパラメータは、（０〜６３）の絶対値であることが推奨される。これは、過度に大きくなることなく、種々のＵＲＩの間のランクを区別するために十分な値を提供し得る。複数のＵＲＩはさらに、同一のランク値を最終的に有するようになり得る。所与のＵＲＩの最終ランクパラメータは、異なるランクサブランキング（例えば、クロスリンク、コンテキスト等）の加重平均として計算され得る。
例えば、
・ Ｒａｎｋ＝（Ｗｅｉｇｈｔ＿１ｘＲａｎｋ＿ｃｒｏｓｓ−ｌｉｎｋ＋Ｗｅｉｇｈｔ＿２ｘＲａｎｋ＿ｃｏｎｔｅｘｔ＋Ｗｅｉｇｈｔ＿３ｘＲａｎｋ＿ｓｌｅｅｐｉｎｇ＋Ｗｅｉｇｈｔ＿４ｘＲａｎｋ＿ｑｕａｓｉ−ｌｏａｄ-ｂａｌａｎｃｅ）／４
式中、「Ｗｅｉｇｈｔ」は、０〜１の因数であり得る。例えば、負荷バランシングが非常に重要であるシステムでは、Ｗｅｉｇｈｔ＿４は、１に設定されるべきである。代替として、例えば、ネットワーク（例えば、少数のデバイスのみを伴う家庭）内の全トラフィック負荷が非常に低いことが知られている場合、Ｗｅｉｇｈｔ＿４は、０．１に設定されるべきである。

ランク値の割り当ておよび関連処理は、各ＲＤ７０２の内部決定であり得る。しかしながら、クライアントは、クライアントの入力検索基準を満たす、ＵＲＩの有益かつ明白なランク付けされた出力リストを依然として入手し得る。これは、各検索エンジン（例えば、Ｇｏｏｇｌｅ、Ｂｉｎｇ）が同一の入力検索パラメータに対して異なるランク付けされたＵＲＩのリストを返し得る、現在の普通のインターネットで使用されるものと同一のアプローチに従い得る。これは、例えば、「最高のピザ」がＧｏｏｇｌｅおよびＢｉｎｇにタイプされ、次いで、検索結果が比較される場合、容易に見られることができる。しかしながら、進化型ＲＤ７０２は、ＩｏＴ ＲＤのための効率的なランキングスキームを達成する方法のために、異なるアーキテクチャおよび詳細な案内を与える。

図８に図示されるステップを行うエンティティは、図１８Ｃまたは図１８Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図８に図示される方法は、図１８Ｃまたは図１８Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図８に図示されるステップを行う。さらに、図８に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることを理解されたい。

（１．ＵＲＩクロスリンキング取り扱い）
ＵＲＩクロスリンキングは、依然としてＩｏＴにおいて重要であることが予期される。ＩｏＴでは、クロスリンクの最も一般的な表現は、ＵＲＩが別のＵＲＩとの定義された関係を有するときである。これは、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、ＲＦＣ６６９０「制約ＲＥＳＴｆｕｌ環境リンク形式」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６６９０）で説明されるように、ある時は、「タイプされたリンク（ｔｙｐｅｄ ｌｉｎｋ）」と称され得る。

ＩｏＴのためのクロスリンクの実施例は、アラームコントローラサーバが冗長性目的で別のサーバ上に代替ＵＲＩを有する場合である。サーバは、リンク形式「ホスト」および「アンカ」パラメータを介して、そのＵＲＩへの関連リンクを示すことができる。具体的には、これは、そのリソース（ＵＲＩ）をＲＤに登録または再登録するときにサーバによって示されるであろう。このＩｏＴクロスリンキングは、以下のように表され得る。
・ 例示的シナリオ：
・ アラームコントローラサーバ（ＵＲＩ−１）が、冗長性目的で代替サーバ（ＵＲＩ−２）を示したい
・ すなわち、クライアントは、ＵＲＩ−１が利用可能ではない場合にＵＲＩ−２に進むことができる
・ したがって、ＵＲＩ−１がサーバによってＲＤに登録されるとき、以下の慣例を使用して、以下のようにＵＲＩ−２へのクロスリンクを示し得る
・ ｃｏａｐ：／／ｈｏｍｅ．ａｌａｒｍ１／ｓｅｒｖｅｒ１／ａｌａｒｍ；
・ ａｎｃｈｏｒ＝“ｃｏａｐ：／／ｈｏｍｅ．ａｌａｒｍ２／ｓｅｒｖｅｒ２／ａｌａｒｍ”；
・ ｒｅｌ＝“ａｌｔｅｒｎａｔｅ”
したがって、ホストおよびアンカは、クロスリンキングのための尺度として使用されることができる。普通のインターネットのように、クロスリンクは、ＵＲＩの「人気」の指示であると仮定され得る。つまり、所与のＵＲＩへのより多くのクロスリンクがあるほど、これは、より人気があり、高くランク付けされると仮定されるはずである。

図９は、例示的実施形態によるランキングをクロスリンクするためのサブプロシージャを図示する。例えば、いったんＵＲＩがサーバによってＲＤに登録されると、ＲＤは、クロスリンキングを検出するように、図９に示されるような以下のプロシージャを実行し得る。

図９のステップ９０２、９０４、９０６、および９０８は、ＲＤに登録される全てのＵＲＩを通してループする。

図９のステップ９０４および９０６は、各所与のＵＲＩが別のＵＲＩにクロスリンクされている回数を数える（および正規化する）。正規化とは、ランクパラメータが所定の範囲を有し得、クロスリンクの数がその範囲の中へマッピングされる必要があり得るという事実を指す。例えば、所定の範囲が０〜１００であり、所与のＵＲＩが、最も多いクロスリンクである１０００個のクロスリンクを伴って数えられている。ＲＤは、１０００個のクロスリンクを伴うＵＲＩを、最高ランクであるランク０にマッピングし得る。所与のＵＲＩが、最も少ないクロスリンクである２０個だけのクロスリンクを有する場合、ＲＤは、２０個のクロスリンクを伴うＵＲＩを、最低ランクであるランク１００にマッピングし得る。

結果は、そのＵＲＩへのクロスリンキングの数を反映する、ｒａｎｋ＿ｃｒｏｓｓ−ｌｉｎｋパラメータに記録される。

例示的実施形態では、プロシージャは、ＲＤがクロスリンクを伴うリソース（すなわち、ＵＲＩ）を削除するようにサーバによって要求される場合、再実行され得る。さらに、プロシージャは、クライアントクエリがＲＤに入るであろう場合、処理されたＵＲＩデータベースにデータ投入するように要求する任意の将来のクライアント検索クエリの前に、オフラインで、または背景処理として実行され得る。別の例示的実施形態では、プロシージャの変形例が実行されることができ、クロスリンキングを測定することの同一の結果を達成する。例えば、これは、アンカパラメータを有するＵＲＩにフラグを付け、図９に示されるようにデータベース内の全てのＵＲＩを細かく調べる代わりに、これらのＵＲＩをチェックすることのみが可能であり得る。

図９に図示されるステップを行うエンティティは、図１８Ｃまたは図１８Ｄに図示されるもの等、ネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図９に図示される方法は、図１８Ｃまたは図１８Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図９に図示されるステップを行う。さらに、図９に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることを理解されたい。

（２．非活動ノード取り扱い）
普通のインターネットノードと比較して、ＩｏＴノードの主要な特性のうちの１つは、それらが、多くの場合、低電力状態であり得、したがって、多くの場合、「スリープ」になるであろうことである。例えば、ＩｏＴノードまたはサーバは、バッテリもしくは太陽電池式であり、電力を節約する必要があるときに低電力モードになり得る。これは、ＩｏＴノードまたはサーバへのアクセス可能性に明白な影響を及ぼす。つまり、ＵＲＩをホストするか、またはＵＲＩによって指し示される下部リソースコンテンツを含むサーバは、これらのＵＲＩにアクセスするＣｏＡＰ要求を実際に果たすように常に電源をオンにされないこともある。幸いにも、ＲＤは、スリープ追跡機構を用いて非活動サーバを追跡することができる。具体的には、スリープ追跡機構を伴うこれらのＲＤは、ＵＲＩをそれらに登録したサーバのスリープスケジュールを承知していることが予期される。このＲＤベースのスリープ追跡機構は、標的リソースが非活動サーバ上に位置し、非活動サーバが現在スリープモードであるかどうかを決定する。

非活動サーバは、いくつかのパラメータ、例えば、１）ノードが現在スリープモードであるかどうかを示すスリープ状態、２）ノードがスリープモードにとどまる最大持続時間を示すスリープ持続時間、３）ノードがスリープしていた時間の長さを示すスリープ時間、および、４）ノードがスリープするであろう次の時間を示す、次のスリープを含み得る。非活動サーバのこれらのパラメータは、ＲＤによって記憶され、全ての関心があるクライアントによってアクセスされることができる。本明細書で提供されるＲＤベースのスリープ追跡は、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、２０１４年２月１２日に更新された「ＣｏＡＰのための強化非活動ノードサポート」のインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｒａｈｍａｎ−ｃｏｒｅ−ｓｌｅｅｐｙ−０５）で説明される。したがって、ＲＤが以下で説明されるような検索応答の中のＵＲＩのスリープ状態を考慮する場合、クライアントに多大な利益があろう。

リソース（ＵＲＩ）に対する検索要求に応答する前であるが、初期ランキング機能が果たされた後、ＲＤは、選択されたＵＲＩのうちのいずれかが、図７および８に図示されるような現在スリープしているサーバを伴うかどうかを確認するために、記憶されたスリープスケジュールの内部リアルタイム調査を行なり得る。ＲＤは、最初にランク付けされたデータベースの中のＵＲＩの各々、または検索クエリの中の用語に基づいて選択されるＵＲＩのうちの一部を連続的に調査し得る。例えば、検索クエリの中の用語が、あるリソースタイプへのＵＲＩを指定する場合、ＲＤは、最初にランク付けされたデータベースの中のそのリソースタイプを有するＵＲＩのスリープ状態を調査するのみである。この場合の「リアルタイム」とは、クライアント検索要求がＲＤに入るのと同一の物理（クロック）時間を指している。これは、クライアント検索の前のある時間に行われる初期フィルタリングと対照的である。チェック自体は、ＲＤ内にすでに含まれているサーバスリープスケジュールを比較し、現在の時間に、サーバがスリープ状態であるか、または起動しているかを確認することである。ＲＤは、このリアルタイムチェックを行うために、ＲＤの外部のいかなる情報にもアクセスする必要はない。

現在スリープ状態であるＵＲＩのリンクは、２つの代替的方法のうちの１つで扱われることができる。１つの代替案は、現在アクセス可能ではあり得ないので、「スリープしている」ＵＲＩをより低いランキングでランク付けすることである。スリープしているＵＲＩは、デバイスが一時的に起動するときの将来のある期間に対してアクセス可能になり得る。別の代替案は、要求クライアントに返される検索結果からスリープしているＵＲＩを完全に除去することである。この代替案では、検索結果に与えられる解釈は、それが現在アクセス可能な（起動している）ＵＲＩを返すのみであるということである。

ＵＲＩに対する検索要求と、サーバがそれらのスリープスケジュールに従ってスリープモードになることとの間の時間を適切に同期させることができるために、利用可能な正確なリアルタイムクロック機能をＲＤが有することが要求され得る。ＲＤは、スリープしているサーバ内のクロックと同期または非同期のいずれかでることが可能であることに留意されたい。非同期モードでは、ＲＤは、現在スリープしているノードが、ＲＤとサーバとの間のクロックドリフトにより、起動していると不注意に仮定されないことを確実にするように、検索要求を果たすことにおいていくつかの安全バッファ時間を含み得る。例えば、記憶されたスリープスケジュールが、非活動サーバが２秒前に起動したはずであることを示し、ＲＤと非活動サーバとの間に数秒のクロックドリフトがある場合、ＲＤは、控えめに５秒のスリープをスリープスケジュールに追加し、サーバがさらに３秒スリープするであろうことを決定し得る。安全バッファ時間は、前向きまたは後向きであり得る。これは、ＲＤが、現在スリープしているノードが起動していると不注意に仮定されないことを確実にするように、スリープ時間を追加または削減し得ることを意味する。代替として、ＲＤは、それが周期的に再同期することを可能にすることができる、サーバのスリープスケジュールまたはスリープ状態の動的更新を受信し得る。

（３．準負荷バランシング取り扱い）
センサ等のＩｏＴデバイスは、多くの場合、クライアントモードおよびサーバモードの両方で動作する。例えば、センサがリソース（ＵＲＩ）をＲＤに登録しているとき、センサは、クライアントモードで作動している。これは、この場合、クライアントがＣｏＡＰ／ＨＴＴＰ要求（例えば、ＰＵＴ）をサーバの役割を果たしているＲＤに送信しているからである。次いで、ＲＤは、機能を果たし（すなわち、ＵＲＩを記憶し）、クライアントへの応答を策定し得る。逆に、コントローラがセンサにクエリを行う場合、センサがサーバの役割を果たしているであろう。これは、この場合、センサが要求（例えば、ＧＥＴ）を受信しており、機能を果たす（すなわち、温度を測定する）であろうからである。次いで、センサは、コントローラへの応答を策定し得る。したがって、センサは、サーバであると考えられる。

ＩｏＴサーバは、それらの性質上、多くの場合、それらのリソースが制約される。個々のサーバが要求で過負荷状態ではないことが重要である。例えば、所与の検索入力に対して、ＲＤが、偶然に単一のサーバを一貫して高くランク付けする場合、これは、多くのクライアントが自然にそのＵＲＩを選択し得るので、サーバ上での負荷問題を引き起こし得る。したがって、予期される負荷に基づいて、ＲＤが、所与の検索入力に対して、いずれのサーバをより高くランク付けするかの平衡を保とうとすることが重要である。

負荷は、いくつかの方法でＲＤによって推定されることができる。１つの方法は、過去の検索結果を記録し、これを現在／将来の検索結果に組み込むことである。ここで、所与のＵＲＩが何度も高くランク付けされている場合、それは、より低くランク付けされたＵＲＩより比較的多くのトラフィックを受信し得ることが仮定される。したがって、その特定のＵＲＩは、それの負荷バランシングを間接的に行う方法として、将来の検索においてわずかに低くランク付けされるべきである。例えば、第１の検索結果は、センサ１がランク０であり、センサ２がランク１である、１０個の温度センサを含み得る。２度目に同一の検索が要求されるとき、第２の検索結果は、第１の検索結果と同一であり得、ランキングが、同一であり得る。しかしながら、３度目に同一の検索要求を受信することに応答して、ＲＤは、検索要求が行われた最後の２回に、センサ１がより高くランク付けされたことを決定し得、代わりに、センサ１上での比較的高いトラフィックを回避するために、この３度目にセンサ１をセンサ２より低くランク付けし得る。したがって、第３の検索結果では、センサ２は、ランク０であり得、センサ１は、ランク１であり得る。別の例示的実施形態では、ＲＤはさらに、タイマを考慮に入れ得る。例えば、検索要求が数分または数時間離れており、特定のＵＲＩが数分または数時間の間に他のＵＲＩより高くランク付けされる場合、ＲＤは、特定のＵＲＩへの高いトラフィックを回避するために、その特定のＵＲＩが将来の検索においてより低くランク付けされるべきであることを決定し得る。

別の方法は、ＵＲＩに進む実際の要求／トラフィックを記録することである。これは、ＲＤが、トラフィックが流れている逆プロキシまたは境界ノード上で物理的に共同設置されるときに可能である。これは、ＲＤが追加の非ＲＤ機能性にアクセスできることを意味する。例えば、ｏｎｅＭ２Ｍベースのシステム内のゲートウェイにおいて実装されるＲＤは、ゲートウェイがＵＲＩへの要求またはトラフィックの統計をとり、ＲＤが統計にアクセスすることができるので、ＵＲＩに進む実際の要求またはトラフィックを把握し得る。さらに、サーバ自体は、それらがバッテリ式であるか配電線式であるか、それらのバッテリレベル等の有用な情報を提供し得る。例えば、バッテリ式および配電線式サーバの間で、ＲＤは、そのバッテリを節約するために、バッテリ式サーバのランクを下げることを選定し得る。別の実施例では、ＲＤは、そのバッテリを節約するために、低バッテリサーバを高バッテリサーバより低くランク付けし得る。再度、これらは、検索結果を提供するときにＲＤが考慮することができる、動作および保守システム（構成情報）の一部等の帯域外情報源に由来し得る。さらに、この機能と以下で説明されるコンテキスト取り扱いとの間に強力な相互作用があり得る。

この準負荷バランシング機能は、部分的であり完全ではない負荷バランシングソリューションを与え得る。これは、全負荷バランシングソリューションが、サーバによって生成されるトラフィックを含む、サーバ内の実際の負荷のより正確な知識を必要とするであろうためである。しかしながら、これは、ＳＥＯ ＲＤソリューションの範囲外であり得る。この準負荷バランシングは、主に、内部ＲＤ推定値からの知覚された負荷に基づく。

（４．コンテキスト取り扱い）
コンテキストは、この場合、他の関連ＵＲＩに対するＵＲＩの物理的または論理的関係を指し得る。例は、以下を含み得る。
・ 他の類似したＵＲＩ（例えば、温度センサ）と同一の論理ドメイン（例えば、サブネットワーク）内のＵＲＩ
・ 所与のＩＰマルチキャストグループ（例えば、４階の全ての照明）に属するＵＲＩ
・ 他の類似したＵＲＩに物理的（すなわち、地理的場所）に近いＵＲＩ
・ いかなるグループにも属していない（すなわち、ユニキャストである）ＵＲＩ
ＩｏＴシナリオは、多くの場合、限定された地理的地域（例えば、建物、フィールド、近所等）にわたって同一の物理的性質（例えば、温度、湿度等）を測定する、多数のセンサを伴う。ＲＤは、登録情報から受信される「リソースタイプ（ｒｔ）」パラメータに基づいてセンサの特性を承知している。したがって、１つの有用なフィルタリング方法は、例えば、２０１３年１２月１１日に更新されたＣｏＲＥリソースディレクトリのインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｒｅｓｏｕｒｃｅ−ｄｉｒｅｃｔｏｒｙ−０１）で定義されるように、ＲＤが、同一のリソースタイプを伴い、かつ同一の「ドメイン」に属するセンサの一部を選択することであり得る。例えば、同一のドメイン（例えば、建物のサブネットワーク）内に１０００個の温度センサがある場合、ＲＤは、センサの種々のコンテキストに基づいて、検索結果の中のこれらのセンサのわずかな一部のみをクライアントに折り返し報告することを選定することができる。その一部はさらに、上で説明されるような準負荷バランシング機能との相互作用によって選定されることもできる。代替として、全てのセンサが、クライアントに折り返し報告されることができるが、ＵＲＩの選定された一部は、高いランキング値を有し得、残りのセンサは、はるかに低いランキング値を有し得る。

ＩｏＴはさらに、例えば、２０１３年１２月２３日に更新された「ＣｏＡＰのためのグループ通信」のインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｇｒｏｕｐｃｏｍｍ−１８）で開示されるように、ＵＲＩのグループ通信モードをサポートし得る。このモードでは、単一のＵＲＩが、ＩＰマルチキャストを介してサーバのグループにマッピングする。このグループ通信モードは、現在、普通のインターネットではサポートされていない。したがって、別の非常に有用なランキング基準は、ＲＤが、サーバのグループにマッピングしているマルチキャストＵＲＩを、ユニキャストＵＲＩより高くランク付けし得ることである。例えば、マルチキャストＵＲＩの各々は、同一のランクを有し得るが、それらの各々は、ユニキャストＵＲＩより少なくとも１つ高くランク付けされる。これは、基礎的グループ通信機構が、ユニキャストＵＲＩより、１つのＵＲＩにつきはるかに多くの情報をクライアントに配信し得るためである。つまり、要求がＩＰマルチキャストを介してそのグループに加入している複数のサーバに分配されるので、単一のＣｏＡＰグループ通信要求（例えば、ＧＥＴ）は、複数の応答を返し得る。

コンテキストはさらに、シナリオに応じて、種々の他の基準に基づいて計算されることもできる。例えば、地理的位置を特定する特徴がＲＤで利用可能である場合、要求クライアントに最も近いＵＲＩに関連付けられるサーバは、より高い優先順位を与えられてもよい。地理的位置を特定する特徴は、例えば、２０１４年２月１２日に更新された「ものの場所を特定するためのリンク形式属性」のインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｆｏｓｓａｔｉ−ｃｏｒｅ−ｇｅｏ−ｌｉｎｋ−ｆｏｒｍａｔ−ａｔｔｒｉｂｕｔｅ−０３）で開示される。これは、検索要求の中にＲＤへの標準化様式で各自の場所情報を含むようにクライアントに要求し得る。

（信号伝達変化）
ＣｏＡＰおよびＨＴＴＰ関連信号伝達が、進化型ＲＤのためのＳＥＯ様機能をサポートするために変更され得る。具体的には、実施形態では、クライアントは、その検索要求の中で、それがある数のＵＲＩに関心を持っていること、および／または、それが非活動ではないノードに関心を持っていることを示すことによって、検索応答のサイズを制限することができる。ＲＤからの検索応答は、この入力を考慮し、さらに、検索応答の中で各ＵＲＩのランクを明示的に示し得る。

一実施形態では、ＣＯＲＥリンク形式は、検索応答において「ランク」のための以下のパラメータをサポートするように更新され得る。ＣＯＲＥリンク形式は、ＣｏＡＰまたはＨＴＴＰプトロコルのいずれかと併せて使用されることができる。
・ クライアントへのクエリ応答（すなわち、ＧＥＴ応答）で、ＲＤは、新しいパラメータ（すなわち、「ランク」）を通して、返されるＵＲＩのランクを示し得る。ランクは、好ましくは、以下のように解釈され得る
・ランクパラメータは、（０〜６３）の絶対値であることが推奨される。しかしながら、これは、例示的符号化であり、他の範囲も使用され得る（例えば、０〜１００）。主要な基準は、ランキング範囲が、過度に大きくなることなく、種々のＵＲＩを区別するために十分な値を提供するべきであることであり得る
・推奨されるランク符号化では、「０」ランク値は、最優先ＵＲＩと見なされ得る。「６３」ランク値は、最低優先順位を伴うＵＲＩと見なされ得る
・返されるＵＲＩのリストは、ランク＝０を有する第１のＵＲＩから始まって連続してランク付けされ得る。複数のＵＲＩが、最終的に同一のランク値を有するようになり得ることに留意されたい
・ 以下の例は、リソースタイプ温度センサ（ｒｔ＝ｔｅｍｐｅｒａｔｕｒｅ＿ｓｅｎｓｏｒ）を伴う全ての終点に対する調査を行うクライアントを示す
・ 要求：ＧＥＴ ｃｏａｐ：／／ｒｄ−ｌｏｏｋｕｐ／ｅｐ？ｒｔ＝ｔｅｍｐｅｒａｔｕｒｅ＿ｓｅｎｓｏｒ
・ 応答：２．０５コンテンツ
・ ＜ｃｏａｐ：／／ｓｅｎｓｏｒ Ａ．ｈｏｍｅ＞；ｅｐ＝”ｎｏｄｅ＿Ａ”；ｒａｎｋ＝０
・ ＜ｃｏａｐ：／／ｓｅｎｓｏｒ Ｃ．ｈｏｍｅ＞；ｅｐ＝”ｎｏｄｅ＿Ｃ”；ｒａｎｋ＝１
・ ＜ｃｏａｐ：／／ｓｅｎｓｏｒ Ｂ．ｈｏｍｅ＞；ｅｐ＝”ｎｏｄｅ＿Ｂ”；ｒａｎｋ＝２
・ ＜ｃｏａｐ：／／ｓｅｎｓｏｒ Ｄ．ｈｏｍｅ＞；ｅｐ＝”ｎｏｄｅ＿Ｄ”；ｒａｎｋ＝３
・ ＲＤに送信される所与の同一クエリ要求が、ランク付けされたＵＲＩの異なる応答を経時的にもたらし得ることに留意されたい。これは、主に、これらが時間依存性であるので、ＵＲＩランキングへの準負荷バランシングおよび非活動ノードチェックの影響に起因し得る。

加えて、随意に、ＲＤへの初期クライアントクエリ（すなわち、ＧＥＴ要求）では、クライアントはさらに、ＣｏＡＰプトロコルおよびＨＴＴＰプトロコルの両方に対して以下の選好を示し得る。
・ クライアントが検索結果において受け入れられ得るランクパラメータ値の範囲。例えば、クライアントは、範囲（０〜１０）内のランクのみを受け入れるであろうことを示し得る。したがって、この場合、ＲＤは、範囲（１１〜６３）内のランクを有するＵＲＩの任意の内部検索結果をさらに除外する必要があり得る。
・ クライアントが、スリープしているノードが検索結果に含まれることを望むかどうか。
ＣｏＡＰプトロコルは、例えば、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、２０１３年６月２８日に更新された制約アプリケーションプロトコルのインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｃｏａｐ−１８）で開示される。ＨＴＴＰプトロコルは、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、ＲＦＣ２６１６「ハイパーテキスト転送プトロコル−ＨＴＴＰ／１．１」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２６１６）で開示される。

ランクの範囲、リソースタイプ、およびスリープ状態指示等の情報は、好ましくは、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、ＲＦＣ３９８６「ユニフォームリソースアイデンティファイア（ＵＲＩ）：一般構文」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３９８６）で開示されるように、ＣｏＡＰ／ＨＴＴＰ検索要求のＵＲＩ文字列のクエリ部分の一部として含まれることができる。これらのクエリ文字列パラメータのこの解釈は、標準化され得るか、または最終的に事実上の解釈となり得るかのいずれかである。例として、ＣｏＡＰクライアントクエリは、以下の通りであり得る。
・ ＧＥＴ ｃｏａｐ：／／ｒｄ−ｌｏｏｋｕｐ／ｅｐ？ｒｔ＝ｔｅｍｐｅｒａｔｕｒｅ＿ｓｅｎｓｏｒ＆ｒａｎｋ＝０＆ｒａｎｋ＝１＆ｓｌｅｅｐｙ＝Ｎｏ
・ ここで、ＲＤへの要求は、
・ タイプ＝「温度センサ」
・ かつ、ランク＝（０または１）
・ かつ、非活動ノードが検索結果に含まれるべきではない
のＵＲＩを調査する。

上で説明されるように、上で定義される全てのパラメータ（すなわち、ランク、非活動ノード指示）は、ＩＥＴＦにおいて標準化され得るか、または事実上の解釈になり得る。さらに、デバイス製造業者および／またはネットワークオペレータのプライベート加入ならびにビジネス関係に基づいてこれらのパラメータが全て機密情報であり得る第３の可能なモデルもある。

（実施例）
図１０は、例示的実施形態による、それらのユニフォームリソースアイデンティファイアをリソースディレクトリに登録する温度センサの実施例を図示する。ある大工場が、建物を通して分配された１０００個の温度センサを有すると仮定される。図１０に示されるように、各センサは、始動時にＣｏＡＰ Ｐｏｓｔを介して、それらのリソース（ＵＲＩ）をローカルＲＤ７０２に登録し得る。これは、ＲＤ７０２が未加工ＵＲＩのデータベースを構築することを可能にし得る。次いで、ＲＤ７０２は、上で説明されるように、クロスリンキング、コンテキスト等のそれらのプロパティに基づいて、全てのＵＲＩを処理し得る。次いで、ランク付けされたＵＲＩは、ＲＤの処理されたデータベースに記憶される。

図１１は、例示的実施形態による、温度センサのリストに対してリソースディレクトリにクエリを行うクライアントを図示する。最初にランク付けされたＵＲＩが処理されたデータベースに記憶された後、クライアントは、図１１に示されるように、ＣｏＡＰ ＧＥＴを介して検索クエリを送信し得る。検索クエリは、どのＣｏＡＰリソース（ＵＲＩ）が工場内で温度示度値を提供するであろうかを識別するようにＲＤ７０２に要求し得る。つまり、クエリは、リソースタイプが「ｔｅｍｐｅｒａｔｕｒｅ＿ｓｅｎｓｏｒ」であるべきことを規定し、ドメインが工場の建物であるべきことを規定し得る。さらに、クライアントは、範囲（０〜１０）内のランクを有するＵＲＩのみに関心があることを示し得る。さらに、クライアントは、現在スリープモードであるサーバ上にあるＵＲＩに関心がないことを示し得る。

図１２は、例示的実施形態による、フィルタ処理された温度センサのリストを返すリソースディレクトリを図示する。図１２を参照すると、ＲＤ７０２は、ＣｏＡＰ ＧＥＴ応答を介して、１０００の入力よりはるかに少ない（すなわち、センサの総数未満）優先順序を付けられたＵＲＩのリストで応答し得る。これは、初期ランキングおよびリアルタイムフィルタリングが多数のＵＲＩを排除したためである。いくつかは、ランク（０〜１０）内のＵＲＩのみを提供すること、および現在スリープしていないＵＲＩのみを考慮することに関するクライアントの指図により、明確に排除されている。これは、ＲＤ７０２の処理されたデータベース内のＵＲＩ調査後に起こる、非活動ノード関連ＵＲＩに対するリアルタイムチェックでＲＤによって処理され得る。

さらに、このシナリオでは、センサは、同一のリソースタイプを有し、同一のドメイン内に位置し得る。したがって、ＲＤコンテキスト識別機能は、類似した（温度）値を測定していると仮定されるので、検索リストから多数のＵＲＩを排除し得る。検索結果リストが小さいことの他の理由は、多くのセンサが現在スリープ状態であると仮定されるからである。

図１３は、例示的実施形態による、最高ランクのユニフォームリソースアイデンティファイアのみからリソースをフェッチするクライアントを図示する。図１３を参照すると、次いで、クライアントは、フィルタ処理されたＲＤ検索結果の中で返された上位３つのＵＲＩのみを容易かつ効率的に要求し得る。要求されるＵＲＩの最終的な数は、クライアントアプリケーションに基づき得る。

明確にするために、本明細書に説明される実施例の殆どは、ＣｏＡＰの使用を示す。しかしながら、一般的に、同等の機能性が、ＨＴＴＰを用いて容易に達成され得る。さらに、ＨＴＴＰおよびＣｏＡＰ連動を伴う混合ネットワークもさらに、例えば、２０１４年２月１２日に更新されたＨＴＴＰ−ＣｏＡＰマッピング実装のためのガイドラインのインターネット草稿（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｈｔｔｐ−ｍａｐｐｉｎｇ−０３）で開示されるように、同等の機能性を達成し得る。

図１０−１３に図示される機能性は、以下に説明される図１８Ｃまたは図１８Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークノード（例えば、サーバ、ゲートウェイ、デバイス、またはコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

図１４は、Ｍ２Ｍ／ＩｏＴサービス層で実装される検索エンジン最適化を伴うリソースディレクトリの実施形態を図示する。上で説明されるように、ＲＤのＳＥＯ様機能（例えば、ランキングおよびフィルタリング機能）は、その開示がその全体として本明細書に記載される場合のように、参照することによって組み込まれる、「ｏｎｅＭ２Ｍ機能アーキテクチャ」、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．４２で開示されるようなＨＴＴＰまたはＣｏＡＰ層の上方の層等のＩｏＴサービス層まで拡張され得る。本実施形態の実施例は、以下の主要な発想とともに図１４に図示される。
・ サーバ８０１が、ＩｏＴデバイス１４０２（例えば、３ＧＰＰマシン型通信デバイス）の中に常駐し得る一方で、クライアントは、ＩｏＴアプリケーションの一部であり得る
・ ＲＤ７０２（上で説明されるようなＳＥＯ様特徴を含む）は、ＩｏＴゲートウェイ１４０４またはＩｏＴサーバの一部として実装され得る
・ サーバ８０１が、サービス層インターフェースを経由してリソースをＲＤ７０２に登録し得る一方で、クライアントは、同様にサービス層インターフェースを経由してＲＤ７０２へのクエリを発行し得る。ＩｏＴゲートウェイ１４０４内のＲＤ７０２は、ＳＥＯ様特徴を実行し、サービス層インターフェースを経由してランク付けされたＵＲＩのリストをクライアント３０２に返し得る。

ＲＤ７０２がｏｎｅＭ２Ｍゲートウェイの一部である、図１４に示されるネットワークに対して、ＲＤ７０２の範囲は、ゲートウェイドメインに対応し得る。つまり、ゲートウェイによって供給されるＭ２Ｍエリアネットワーク内の全てのデバイス（サーバ）は、それらのリソースをＲＤ７０２に登録し得る。次いで、ＲＤ７０２は、これらのリソースに対応するＵＲＩを処理してランク付けし得る。次いで、ＲＤ７０２への検索クエリは、ゲートウェイドメインの内側または外部ネットワークドメインのいずれかからもたらされ得る。次いで、ＲＤ７０２は、ゲートウェイドメインの内側に位置するサーバを対象とするランク付けされたＵＲＩを伴う検索結果を返し得る。

ＳＥＯ−ＲＤが、図１４に示されるようにｏｎｅＭ２Ｍゲートウェイの一部として論理的に実装される場合、ＲＤ７０２は、ゲートウェイ１４０４を通ってＩｏＴデバイスに／から流れるユーザプレーントラフィックの統計に容易にアクセスし得る。これは、ＲＤが上で説明されるような準負荷バランシング機能を実装することをより単純にし得る。具体的には、ＲＤ７０２は、ゲートウェイ境界の内側に位置するＵＲＩ（リソース）への外部要求（例えば、ＣｏＡＰ ＧＥＴ）を監視することが可能であり得る。これは、ＲＤ７０２が、準負荷バランシングアルゴリズムの一部として行うランキング計算にこの負荷計量を組み込むことを可能にし得る。

図１５は、別の例示的実施形態による、ｏｎｅＭ２Ｍ機能アーキテクチャ内のＲＤ ＣＳＦ１５０２を図示する。図１５に示されるように、上で説明されるＳＥＯ様特徴（例えば、ランキングおよびフィルタリング）は、新しいｏｎｅＭ２Ｍ ＣＳＦ（ＲＤ ＣＳＦ１５０２と称される）として、およびｏｎｅＭ２Ｍ ＣＳＥの一部として実装されることができる。ＣＳＥ１ １５０４は、Ｍ２Ｍ／ＩｏＴゲートウェイまたはサーバであり得る。ＲＤ ＣＳＦ１５０２は、以下の機能を有し得る。
・ それは、ＡＥまたはＣＳＥからのリソース登録を受け入れ、全ての登録されたリソースを維持し得る。
・ それは、上で説明されるような機構に従って、登録されたリソースをランク付けし得る。

それは、ＡＥまたはＣＳＥからのリソースクエリを処理し、上で説明されるようなフィルタ処理されたリソースのリストを返し得る。図１４−１５に図示される機能性は、以下に説明される図１８Ｃまたは図１８Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークノード（例えば、サーバ、ゲートウェイ、デバイス、またはコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

図１６は、図１５に示されるＲＤ ＣＳＦ１５０２に基づく、リソース登録プロシージャおよびリソースクエリプロシージャを図示する。

図１６のステップ１では、要求側１ １６０２（例えば、ＡＥまたはＣＳＥ）が、リソース登録要求メッセージをＲＤ ＣＳＦ１５０２に送信し得る。このメッセージは、以下の情報、すなわち、１）登録されるリソースのリスト、２）上で説明されるようなそのＵＲＩ、クロスリンク、負荷、コンテキスト、場所、およびスリープスケジュール等の各リソースの属性を含み得る。
・ このステップは、ｏｎｅＭ２Ｍにおける既存のリソース告知を使用して実現されることができるが、追加の属性（すなわち、上で説明されるようなクロスリンク、負荷、コンテキスト、場所、およびスリープスケジュール）が、各告知されたリソースのために追加される必要があり得ることに留意されたい。

図１６のステップ２では、ＲＤ ＣＳＦ１５０２が、リソース登録応答を要求側１ １６０２に返送し得る。

図１６のステップ３では、ＲＤ ＣＳＦ１５０２が、上で説明される方法に従って、全ての登録されたリソースをランク付けし得る。

図１６のステップ４では、要求側２ １６０４（例えば、ＡＥまたはＣＳＥ）が、リソースクエリメッセージをＲＤ ＣＳＦ１５０２に送信し得る。このメッセージは、以下の情報、すなわち、１）上で説明されるような所望のランク、所望のリソース場所、所望のリソース負荷等の検索基準を含み得る。
・ このステップは、上で説明されるような所望のランク等の新しい基準を用いて、ｏｎｅＭ２Ｍで既存の発見ＣＳＦを使用して実装され得ることに留意されたい。

図１６のステップ５では、ＲＤ ＣＳＦ１５０２が、上で説明される方法に従って、ステップ４に含まれる基準に基づいて、その維持されたリソースを検索し得る。

図１６のステップ６では、ＲＤ ＣＳＦ１５０２が、結果（すなわち、発見されたリソースのリスト）を要求側２に送信し得る。

ＡＥまたはＣＳＥ自体が、ある種のリソースであり得る。次いで、ＡＥまたはＣＳＥによる告知されたリソースは、そのクロスリンクと見なされることができる。結果として、より多くの告知されたリソース（すなわち、より多くのクロスリンク）を伴うＡＥまたはＣＳＥは、より高いランクを割り当てられ得、それらは、発見され、より高い確率で要求側２に返され得る。

さらに、別の実施形態では、新しいＲＤ ＣＳＦにおいて本開示のＳＥＯ様特徴を提供する代わりに、これらの特徴は、ｏｎｅＭ２Ｍにおける既存の発見ＣＳＦに対する修正として実装され得ることに留意されたい。その代替実施形態では、図１６の同一のプロシージャが適用され得、単にＲＤ ＣＳＦを修正された発見ＣＳＦと置換する。

図１６に図示されるステップを行うエンティティは、図１８Ｃまたは図１８Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１６に図示される方法は、図１８Ｃまたは図１８Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１６に図示されるステップを行う。さらに、図１６に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることを理解されたい。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、リソースディレクトリのための検索エンジン最適化に関係付けられる機能性を制御および／または構成するようにユーザを支援するために使用されることができる。図１７は、ユーザが検索システムの動作を理解するようにリソースディレクトリの中への検索の結果を視認することを可能にする、デバッグインターフェース１７０２を図示する略図である。図１７はさらに、リソースディレクトリのための検索エンジンで使用される検索パラメータを調節するために使用される、インターフェース１７０４も図示する。さらに、以下で説明される図１８Ｃ−Ｄに示されるもの等のディスプレイを使用して、インターフェース１７０２および１７０４が生成されることができることも理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図１８Ａは、本明細書に説明されるような進化型リソースディレクトリのＳＥＯ様機能が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の系統図である。概して、Ｍ２Ｍ技術は、ＩｏＴの構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴの構成要素ならびにＩｏＴサービス層等であり得る。

概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷＯＴだけではなく、ＩｏＴ／ＷｏＴサービス層等の構成要素またはノードであり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。

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

図１８Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍ端末デバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はさらに、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図１８Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図１８Ｃおよび１２Ｄで図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

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

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

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでもよく、さらに、他の開示されるシステムおよび方法と併せて使用され得る。

一実施形態では、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティは、図１８Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

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

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

さらに、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図１８Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティを実行するか、または含むことができる。デバイス３０は、図１８Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、もしくは非Ｍ２Ｍネットワークの一部であり得る。図１８Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はさらに、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させ得る。プロセッサ３２はさらに、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

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

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

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

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

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させるか、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得るか、または情報をユーザに表示するように構成され得る。別の実施例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にし得る。

プロセッサ３２は、電源４８から電力を受容し得、Ｍ２Ｍノード３０内の他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

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

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

図１８Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等、Ｍ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティを実行するか、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワーク基地局、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

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

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

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

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

さらに、コンピューティングシステム９０は、例えば、図１８Ａおよび図１８Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にし得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等の機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。リソースディレクトリ２０８および７０２、センサ２０２、２０４、および２０６等のセンサ、クライアント３０２、ＡＥ６０２、ＣＳＥ６０４、６０６、および１５０４、ＮＳＥ６０８、データベース７０４および７０６、初期ランキング機能７０８、リアルタイムランキング機能７１０、サーバ８０１、ＩｏＴデバイス１４０２、ＩｏＴゲートウェイ（またはサーバ）１４０４、ＲＤ ＣＳＦ１５０２、要求側１６０２および１６０４、ならびにインターフェース１７０２および１７０４等のインターフェースを生成する論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されるコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理的）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形または物理的媒体を含むが、それらに限定されない。

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

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

Claims (21)

1. 複数のサーバとリソースディレクトリとを備えているネットワークでの使用のための方法であって、前記方法は、前記リソースディレクトリにおいて行われ、前記方法は、
   前記複数のサーバから受信される複数のユニフォームリソースアイデンティファイア（ＵＲＩ）を登録することと、
   前記複数のＵＲＩの各々の間のクロスリンクを測定することに基づいて、前記複数のＵＲＩに対する初期ランキングを決定することと、
   前記初期ランキングに基づいて、ランク付けされたデータベースを生成することと
   を含む、方法。
2. 前記複数のＵＲＩの各々の間のクロスリンクを測定することは、
   前記複数のＵＲＩの各々が別のＵＲＩにクロスリンクされている回数を数えることと、
   前記複数のＵＲＩの前記各々に対して、前記回数をランクの所定の範囲にマッピングすることと、
   前記マッピングすることに基づいて、前記複数のＵＲＩのクロスリンクランキングを決定することであって、前記クロスリンクランキングは、前記回数を示す、ことと
   をさらに含む、請求項１に記載の方法。
3. 前記複数のＵＲＩのクロスリンクランキングを決定することは、
   前記複数のＵＲＩの中の第１のＵＲＩを決定することであって、前記第１のＵＲＩは、前記複数のＵＲＩの中の第２のＵＲＩより多くクロスリンクされている、ことと、
   前記第１のＵＲＩを前記第２のＵＲＩより高くランク付けすることと
   をさらに含む、請求項２に記載の方法。
4. 前記複数のＵＲＩの前記初期ランキングは、前記複数のＵＲＩのコンテキストを識別することに基づいてさらに決定される、請求項１に記載の方法。
5. 前記複数のＵＲＩの前記コンテキストは、リソースタイプ、ドメイン、地理的場所、マルチキャスト、およびユニキャストを備えている、請求項４に記載の方法。
6. 前記複数のＵＲＩのコンテキストを識別することは、
   前記コンテキストに基づいて、前記複数のＵＲＩからＵＲＩのグループを選択することと、
   前記ＵＲＩのグループを、前記複数のＵＲＩの中の選択されていないＵＲＩのグループより高くランク付けすることと、
   前記ランキングに基づいて、前記複数のＵＲＩに対するコンテキストランキングを決定することと
   をさらに含む、請求項５に記載の方法。
7. 前記ＵＲＩのグループは、前記論理ドメインに基づいて選択される、請求項６に記載の方法。
8. 前記ＵＲＩのグループは、前記リソースタイプに基づいて選択される、請求項６に記載の方法。
9. 前記ＵＲＩのグループは、前記地理的場所に基づいて選択される、請求項６に記載の方法。
10. 前記ＵＲＩのグループは、前記マルチキャストグループに基づいて選択される、請求項６に記載の方法。
11. クライアントから検索クエリを受信することと、
    前記検索クエリに基づいて、前記ランク付けされたデータベースの中の前記複数のＵＲＩのリアルタイムランキングを決定することと、
    前記リアルタイムランキングに基づいて、前記複数のＵＲＩのランク付けされたリストを生成することと
    をさらに含む、請求項１に記載の方法。
12. 前記検索クエリは、リソースタイプ、ドメイン、ランクの範囲、およびスリープ状態インジケータを備えている、請求項１１に記載の方法。
13. 前記複数のＵＲＩの前記リアルタイムランキングは、前記複数のサーバの各々に対するスリープ状態をチェックすることに基づいて決定される、請求項１１に記載の方法。
14. 前記複数のサーバの各々に対するスリープ状態をチェックすることは、
    前記複数のＵＲＩの各々に対する前記スリープ状態を前記複数のサーバから受信されるスリープスケジュールと比較することと、
    前記スリープ状態を比較することに基づいて、前記複数のＵＲＩに対するスリープ状態ランキングを決定することと
    をさらに含む、請求項１３に記載の方法。
15. 前記スリープ状態ランキングを決定することは、前記複数のＵＲＩの中のＵＲＩがスリープ状態である場合、前記ＵＲＩを前記複数のＵＲＩの中の起動している別のＵＲＩより低くランク付けすることをさらに含む、請求項１４に記載の方法。
16. 前記スリープ状態ランキングを決定することは、前記複数のＵＲＩの中のＵＲＩがスリープ状態である場合、前記ランク付けされたリストの中の前記ＵＲＩを除去することをさらに含む、請求項１４に記載の方法。
17. 前記複数のＵＲＩの前記リアルタイムランキングは、前記複数のサーバのトラフィック負荷に部分的に平衡を保たせることに基づいて決定される、請求項１１に記載の方法。
18. 前記複数のサーバのトラフィック負荷に部分的に平衡を保たせることは、
    前記複数のＵＲＩの中の第１のＵＲＩを決定することであって、前記第１のＵＲＩは、前記複数のＵＲＩの中の第２のＵＲＩより所定の回数高くランク付けされている、ことと、
    前記第１のＵＲＩを前記第２のＵＲＩより低くランク付けすることと、
    前記ランキングに基づいて、前記複数のＵＲＩに対する準負荷バランシングランキングを生成することと
    をさらに含む、請求項１７に記載の方法。
19. 前記複数のサーバのトラフィック負荷に部分的に平衡を保たせることは、
    前記複数のＵＲＩの中の第１のＵＲＩを決定することであって、前記第１のＵＲＩは、前記複数のＵＲＩの中の第２のＵＲＩより高いトラフィック負荷を伴って検出されている、ことと、
    前記第１のＵＲＩを前記第２のＵＲＩより低くランク付けすることと、
    前記ランキングに基づいて、前記複数のＵＲＩに対する準負荷バランシングランキングを生成することと
    をさらに含む、請求項１７に記載の方法。
20. 前記ランク付けされたデータベースは、クロスリンクランキング、コンテキストランキング、スリープ状態ランキング、および準負荷バランシングランキングの加重平均に基づいて生成される、請求項１に記載の方法。
21. 複数のサーバとリソースディレクトリとを備えているネットワーク内のシステムであって、前記システムは、
    プロセッサと、
    前記プロセッサに連結されているメモリと
    を備え、
    前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
    前記複数のサーバから受信される複数のユニフォームリソースアイデンティファイア（ＵＲＩ）を登録することと、
    前記複数のＵＲＩの各々の間のクロスリンクを測定することに基づいて、前記複数のＵＲＩに対する初期ランキングを決定することと、
    前記初期ランキングに基づいて、ランク付けされたデータベースを生成することと
    を含む動作を前記プロセッサに達成させる、システム。