JP6599546B2 - サービス層におけるアンルートリソース発見を可能にする方法 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２０４，５４６号（２０１５年８月１３日出願）の利益を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

（技術分野）
本願は、リソース発見アーキテクチャおよびプロトコルを対象とする。より具体的には、本願は、サービス層におけるアンルートリソース発見プロトコルを説明する。

現在、ｏｎｅＭ２Ｍ発見要求は、発信側、すなわち、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）から、ホスティングＣＳＥに送信される。発信側とホスティングＣＳＥとの間に位置する通過ＣＳＥは、発見要求を転送することのみ可能である。これは、発見のプライバシを確実にするが、通過ＣＳＥが発見プロセスに関与することを可能にしない。

現在の発見機構は、通過ＣＳＥが発見要求を処理することができる展開／システムのためのサポートも欠いている。ひいては、発信側は、通過ＣＳＥにおいてリソースの任意の一致インスタンスを見出すこと、または全ての一致するリソースを見出すことを求めることができない。

さらに、発信側は、２つ以上のリソースに基づく条件付き発見要求を行うことができない。その上さらに、発信側は、最適一致するリソースを見出すことができず、例えば、一致するリソースを伴う別のホスティングＣＳＥがあり得、一致するリソースは、サービスレベルホップの数に関して発信側により近いＣＳＥ、または発見要求をハンドリングするためのさらなる処理能力を有するＣＳＥの中にあり得る。

これらの欠点は、当技術分野で以下の問題を提起する。第１に、発信側からホストＣＳＥに信号伝達する不必要なサービス層がある。第２に、フィルタ基準に一致するリソースを発見することにおける不必要な待ち時間がある。さらに、リソース発見における融通性がない。すなわち、オリジナルリソースおよびアナウンスされたリソースを両方とも含む発見リソースは、発信側またはホスティングＣＳＥのみにある。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述の必要性は、サービス層におけるアンルートリソース発見を促進するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。

本願の一側面では、ネットワーク化装置が説明されている。装置は、リソースの発見を実施するための命令を記憶している非一過性メモリを含む。装置はさらに、非一過性メモリに動作可能に結合されるプロセッサも含む。プロセッサは、少なくとも発見要求メッセージを生成する命令を実施するように構成される。プロセッサはさらに、発見要求メッセージを共通サービスエンティティに送信する命令を実施するように構成される。さらに、プロセッサは、共通サービスエンティティから発見応答を受信する命令を実施するように構成される。

本願の別の側面では、共通サービスエンティティにおいて発見を行うためのコンピュータ実装方法が説明されている。方法は、発見タイプを含む発見要求メッセージ（ＤＲＭ）を生成するステップを含む。方法はさらに、ＤＲＭをＣＳＥに送信するステップも含む。方法はさらに、ＣＳＥから発見応答を受信するステップを含む。

本願のさらに別の側面は、ネットワーク化装置を対象とする。装置は、リソースに対する発見要求メッセージを処理するための命令を記憶している非一過性メモリを含む。装置はさらに、非一過性メモリに動作可能に結合されるプロセッサも含む。プロセッサは、（ｉ）発信側からフィルタ基準を含む発見要求メッセージを受信する命令と、（ｉｉ）任意のリソースがメッセージの中のフィルタ基準に一致するかどうかをチェックする命令と、（ｉｉｉ）発見応答メッセージを準備する命令とを実施するように構成される。

本願のその上さらに別の側面は、共通サービスエンティティにおいて発見を実施するためのコンピュータ実装方法を対象とする。方法は、発信側から発見タイプおよびフィルタ基準を含む発見要求メッセージを受信するステップを含む。方法はさらに、リソースがメッセージの中のフィルタ基準に一致するかどうかをチェックするステップも含む。方法はさらに、発見応答メッセージを準備するステップを含む。

上に述べたように、その詳細な説明がさらに理解され得るために、および当技術分野への本寄与がさらに認識され得るために、本発明のある実施形態が、かなり広義に概説されている。
本発明はさらに、例えば、以下を提供する。
（項目１）
ネットワーク上の装置であって、前記装置は、
前記ネットワーク上のリソースに対する発見要求メッセージを処理するための命令を記憶している非一過性メモリと、
前記非一過性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
発信側からフィルタ基準を含む前記発見要求メッセージを受信することと、
任意のリソースが前記発見要求メッセージにおける前記フィルタ基準に一致するかどうかをチェックすることと、
発見応答を準備することと
を行う前記命令を実施するように構成されている、装置。
（項目２）
前記プロセッサは、前記発見要求メッセージの前記フィルタ基準および発見タイプに基づいて、いくつの結果を返すべきかを決定する前記命令を実施するようにさらに構成されている、項目１に記載の装置。
（項目３）
前記決定する命令は、一致するリソース限界「ｋ」より小さい一致するリソースの数「Ｌ」に基づく、項目２に記載の装置。
（項目４）
前記決定する命令は、
前記フィルタ基準に一致する他の共通サービスエンティティをチェックすることと、
前記チェックする命令に基づいて、ホスティング共通サービスエンティティを更新することと
を含む、項目３に記載の装置。
（項目５）
前記プロセッサは、前記発見要求メッセージを別の共通サービスエンティティに転送すること、または前記発見応答メッセージを前記発信側に送信することを行う前記命令を実施するようにさらに構成されている、項目１に記載の装置。
（項目６）
前記プロセッサは、
第２の発見応答メッセージを受信することと、
前記第２の発見応答メッセージからの結果に基づいて前記発見応答を更新することと
を行う命令を実施するようにさらに構成されている、項目１に記載の装置。
（項目７）
前記発見要求メッセージは、ルート発見、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される発見タイプを含む、項目１に記載の装置。
（項目８）
前記発見タイプは、条件付き持続性または代替共通サービスエンティティリダイレクトを有する、項目７に記載の装置。
（項目９）
前記発見要求メッセージは、最大ｋ個のリソース発見を見出すこと、最大Ｎ個のホップリソース発見を見出すこと、全てのリソース発見を見出すこと、一致するリソース限界、およびホップ限界のうちの少なくとも１つを含む、項目１に記載の装置。
（項目１０）
ネットワーク上の共通サービスエンティティの発見を実施する方法であって、前記方法は、
発信側から発見タイプおよびフィルタ基準を含む発見要求メッセージを受信することと、
リソースが前記発見要求メッセージにおける前記フィルタ基準に一致するかどうかをチェックすることと、
発見応答を準備することと、
前記フィルタ基準および前記発見タイプに基づいて、前記発見応答においていくつの結果を返すべきかを決定することと
を含む、方法。
（項目１１）
前記決定するステップは、一致するリソース限界「ｋ」より小さい一致するリソースの数「Ｌ」に基づく、項目１０に記載の方法。
（項目１２）
前記決定するステップは、
前記フィルタ基準に一致する他の共通サービスエンティティをチェックすることと、
前記チェックするステップに基づいて、ホスティング共通サービスエンティティを更新することと
を含む、項目１０に記載の方法。
（項目１３）
前記発見要求メッセージを別の共通サービスエンティティに転送すること、または前記発見応答メッセージを前記発信側に送信することをさらに含む、項目１０に記載の方法。
（項目１４）
第２の発見応答メッセージを受信することと、
前記第２の発見応答メッセージからの結果に基づいて前記発見応答を更新することと
をさらに含む、項目１に記載の方法。
（項目１５）
ネットワーク上の装置であって、前記装置は、
前記ネットワーク上のリソースの発見を実施するための命令を記憶している非一過性メモリと、
前記非一過性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
発見要求メッセージを生成することと、
前記発見要求メッセージを前記ネットワーク上の共通サービスエンティティに送信することと、
前記共通サービスエンティティから発見応答を受信することと
を行う前記命令を実施するように構成されている、装置。
（項目１６）
前記発見要求メッセージは、発見タイプを含む、項目１５に記載の装置。
（項目１７）
前記発見タイプは、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される、項目１６に記載の装置。
（項目１８）
前記マルチホップ発見は、ルート発見、最大ｋ個のリソース発見を見出すこと、最大Ｎ個のホップリソース発見を見出すこと、全てのリソース発見を見出すこと、一致するリソース限界、およびホップ限界のうちの少なくとも１つを含む、項目１７に記載の装置。
（項目１９）
前記発見要求メッセージは、要求を実施する共通サービスエンティティのタイプ、ある階層の前記共通サービスエンティティ、有意な処理を伴う共通サービスエンティティ、リスト内の共通サービスエンティティ、およびそれらの組み合わせから成る群から選択されるフィルタを含む、項目１５に記載の装置。
（項目２０）
前記発見応答は、ホップ限界に達していること、前記一致するリソース限界に達していること、およびそれらの組み合わせから成る群から選択される、項目１５に記載の装置。
（項目２１）
ネットワーク上の共通サービスエンティティの発見を実施する方法であって、前記方法は、
発見タイプを含む発見要求メッセージを生成することと、
前記発見要求メッセージを前記ネットワーク上の前記共通サービスエンティティに送信することと、
前記共通サービスエンティティから発見応答を受信することと
を含み、
前記発見タイプは、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される、方法。
（項目２２）
前記発見要求メッセージは、要求を実施する共通サービスエンティティのタイプ、ある階層の共通サービスエンティティ、有意な処理を伴う共通サービスエンティティ、リスト内の共通サービスエンティティ、およびそれらの組み合わせから成る群から選択されるフィルタを含む、項目２１に記載の方法。
（項目２３）
前記発見応答は、少なくとも２つの共通サービスエンティティから受信され、
前記少なくとも２つの共通サービスエンティティから受信される重複発見応答は、削除される、
項目２１に記載の方法。
（項目２４）
前記発見応答は、ホップ限界に達していること、および一致するリソース限界に達していることについての情報を含む、項目２３に記載の方法。

本願のより堅調な理解を促進するために、ここで、同様の要素が同様の数字で参照される、付随の図面を参照する。これらの図面は、本願を限定すると解釈されるべきではなく、例証的にすぎないことを意図している。
図１は、アプリケーション層、共通サービス層、およびネットワークサービス層の間の関係を図示する。 図２は、アプリケーションエンティティ、共通サービスエンティティ（ＣＳＥ）、および下層ネットワークの間の関係を図示する。 図３は、フィールドドメインとインフラストラクチャドメインとの間の関係を図示する。 図４は、ある実施形態による、一般的リソース発見プロシージャを図示する。 図５Ａは、マシンツーマシン（Ｍ２Ｍ）またはＩｏＴ通信システムの実施形態を図示する。 図５Ｂは、Ｍ２Ｍサービスプラットフォームの本願の実施形態を図示する。 図５Ｃは、例示的Ｍ２Ｍデバイスの系統図の本願の実施形態を図示する。 図５Ｄは、例示的なコンピューティングシステムのブロック図の本願の実施形態を図示する。 図６は、発信側、複数の通過ＣＳＥ、およびホストＣＳＥの間の関係を示す実施形態を図示する。 図７は、ある実施形態による、発見プロシージャを図示する。 図８は、別の実施形態による、発見要求プロシージャを図示する。 図９は、ある実施形態による、通過ＣＳＥにおける発見プロシージャを図示する。 図１０は、別の実施形態による、マルチホップ発見プロシージャを図示する。 図１１は、別の実施形態による、発見要求プロシージャを図示する。 図１２は、別の実施形態による、通過ＣＳＥにおける発見プロシージャを図示する。 図１３は、ある実施形態による、条件付き発見プロシージャを図示する。 図１４は、ある実施形態による、リダイレクト発見プロシージャを図示する。 図１５は、さらに別の実施形態による、発見プロトコルを図示する。 図１６は、別の実施形態による、共通サービスエンティティ（ＣＳＥ）の中の強化発見プロトコルを図示する。 図１７は、別の実施形態による、グラフィカルユーザインターフェースを図示する。 図１８ＡおよびＢは、グラフィカルユーザインターフェースの例を図示する。

例証的実施形態の詳細な説明が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な例を提供するが、詳細は、例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。

本明細書における「一実施形態」、「ある実施形態」、「１つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。さらに、本明細書内の種々の場所における用語「実施形態」は、必ずしも同一の実施形態を指しているわけではない。すなわち、いくつかの実施形態によって提示され得るが、他の実施形態によって提示されない、種々の特徴が説明される。

概して、ｏｎｅＭ２Ｍは、発信側がホスティングＣＳＥにおいて規定フィルタ基準に一致するリソースを見出すことを可能にする単純なリソース発見機構を提供する。発信側は、事前プロビジョニングを通して、または事前発見動作を通してのいずれかで、ホスティングＣＳＥを知らされる。フィルタ基準は、発信側が、タイプによって、作成時間によって、更新時間によって、サイズによって、標識によって等、受信される応答を調整することを可能にする。ホスティングＣＳＥは、一致するリソースのアドレスのリストで応答する。これは、最大でもある発信側が規定した最大数であり得る。発見要求がホスティングＣＳＥに向かうと、それは、典型的には、いくつかの通過ＣＳＥをトラバースする。本願によると、通過ＣＳＥは、発見プロセスを支援し、強化リソース発見機構を可能にするプロトコルで構成される。

一実施形態において、発信側は、強化リソース発見機構のうちの１つの選択を可能にするための発見要求、およびこれらの機構に関連するパラメータを規定するための発見要求を（新しいＡＰＩを通して）発行し得る。発信側は、マルチホップ発見、条件付き発見、またはホスティングＣＳＥリダイレクトを行うことを通過ＣＳＥに要求することができる。マルチホップ発見の場合、発信側は、ホスティングＣＳＥへのサービス層ルート発見を行うこと、または最初の「Ｋ」個の一致するリソースを見出すことを通過ＣＳＥに求めることができる。別個に、別の実施形態において、条件付き発見の場合、発信側は、所定の条件が満たされる場合にのみ発見要求を転送することを特定のＣＳＥに求めることができる。別の実施形態において、ホスティングＣＳＥリダイレクトの場合、発信側は、より良好なホスティングＣＳＥを提案することを通過ＣＳＥに求めることができる。

別個に、発信側は、条件付き発見、ホスティングＣＳＥリダイレクト、および／またはマルチホップ発見のステータスを信号伝達する発見応答を受信し得る。マルチホップ発見に対して、応答は、発信側とホスティングＣＳＥとの間の通過ＣＳＥと、ルート発見のためのこれらのＣＳＥのステータスとを信号伝達し得る。例えば、条件付き発見では、応答は、通過ＣＳＥにおいて条件が満たされなかったことを発信側に信号伝達し得る。別の例では、ホスティングＣＳＥリダイレクトに対して、応答は、一致するリソースを有するホスティングＣＳＥのリストを発信側に信号伝達し得る。

概して、以下でさらに詳細に議論される実施形態において、マルチホップ発見中、通過ＣＳＥは、発見要求を処理し、保留の発見応答を準備する。この発見応答は、すぐに送信されない。加えて、それらは、より多くの一致するリソースが必要とされる場合、発見要求を転送し、発見応答を待つ。発見応答の受信時、それらは、一致するリソースのリストを抽出し、送信する前にこのリストを保留の発見応答に付加する。条件付き発見では、通過ＣＳＥは、それが状態をチェックする必要があるかどうかを検証する。それは、条件が満たされる場合にのみ要求を転送する。ホスティングＣＳＥリダイレクト中に、通過ＣＳＥは、他のホスティングＣＳＥが一致するリソースを有するかどうかを決定する。該当する場合、ＣＳＥは、メトリクスの組ともにこの情報を発信側に提供する。

（定義および頭字語）
以下では、本願で一般的に使用される用語および語句の定義が表１で提供される。表２はさらに、本願で使用される用語および語句の頭字語を提供する。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層は、例えば、制御層およびトランスポート／アクセス層等の下部リソース層におけるコアネットワークへのインターフェースも提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシ管理、アクセス制御、およびサービスクラスタ化を含む（サービス）能力または機能性の複数のカテゴリをサポートする。近年、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するために、Ｍ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと称され得るサービス層によってサポートされる上記能力もしくは機能性の集合または組へのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例は、種々のアプリケーションによって一般に使用されることができるセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含むが、それらに限定されない。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装され得、それらがそのような能力もしくは機能を使用するために、種々のアプリケーションならびに／もしくはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）にエクスポーズされる（サービス）能力または機能性を提供する機能エンティティである。

（ｏｎｅＭ２Ｍ共通サービス層および共通サービス機能）
ｏｎｅＭ２Ｍは、全てのアプリケーション間のデータの交換および共有のための単一のホリゾンタルプラットフォームを定義する規格の組を開発してきた。これは、異なる業種にわたる用途さえも含む。ＯｎｅＭ２Ｍは、異なる技術と連携するためのフレームワークを提供することによって、その統一を促進する分散ソフトウェア層（オペレーティングシステムのような）を作成している。この分散ソフトウェア層は、Ｍ２Ｍアプリケーションとデータトランスポートを提供する通信ＨＷ／ＳＷとの間に位置する、共通サービス層で実装される。これは、例えば、図１に図示されている。

共通サービス層は、機能性によって共通サービス機能（ＣＳＦ）に一緒にグループ化されるサービスの組を提供する。いくつかのインスタンス化されたＣＳＦは、共通サービスエンティティ（ＣＳＥ）を構成する。ＣＳＥは、アプリケーション（ｏｎｅＭ２Ｍ用語ではアプリケーションエンティティまたはＡＥ）、他のＣＳＥ、および下層ネットワーク（ｏｎｅＭ２Ｍ用語ではネットワークサービスエンティティまたはＮＳＥ）とインターフェースをとる。

図２に示されるように、これらのインターフェースを横断して流れる通信は、Ｍｃａ、Ｍｃｃ（ならびにＭｃｃ’）、およびＭｃｎ参照点を通る。図２には、ｏｎｅＭ２Ｍによって現在定義されている１２個のＣＳＦも示されている。ＣＳＦの各々は、以下で簡潔に説明される。
（アプリケーションおよびサービス層管理ＣＳＦ）：ＡＥおよびＣＳＥの管理を提供する。これは、ＣＳＥの機能を構成、トラブルシューティング、およびアップグレードする能力、ならびにＡＥをアップグレードする能力を含む。
（発見ＣＳＦ）：フィルタ基準に基づいて、アプリケーションおよびサービスについての情報を検索する。
（登録ＣＳＦ）：ＡＥ（または他の遠隔ＣＳＥ）がＣＳＥに登録するための機能性を提供する。これは、ＡＥ（または遠隔ＣＳＥ）がＣＳＥのサービスを使用することを可能にする。
（通信管理／配信ハンドリングＣＳＦ）：他のＣＳＥ、ＡＥ、およびＮＳＥとの通信を提供する。このＣＳＦは、通信を配信するための時間、通信接続、および、必要であり許可される場合、後に転送されることができるように通信要求をバッファすることを決定する。
（グループ管理ＣＳＦ）：グループ関連要求のハンドリングを提供する。Ｍ２Ｍシステムが、複数のデバイス、アプリケーション等の上でバルク動作をサポートすることを可能にする。
（セキュリティＣＳＦ）：識別、認証、および認可を含むアクセス制御等のサービス層のためのセキュリティ機能を提供する。
（データ管理およびレポジトリＣＳＦ）：データ記憶および仲介機能を提供する（集約のためにデータを収集すること、データを再フォーマットすること、ならびに分析および意味処理のためにデータを記憶すること）。
（場所ＣＳＦ）：ＡＥが地理的場所情報を取得することを可能にする機能性を提供する。
（サービス課金および会計ＣＳＦ）：サービス層のための課金機能を提供する。
（デバイス管理ＣＳＦ）：Ｍ２ＭゲートウェイおよびＭ２Ｍデバイス上のデバイス能力の管理を提供する。
（ネットワークサービスエクスポージャ、サービス実行、およびトリガＣＳＦ）：ネットワークサービス機能にアクセスするための下層ネットワークとの通信を管理する。
（サブスクリプションおよび通知ＣＳＦ）：イベントにサブスクライブすることを可能にし、このイベントが起こるときに通知される機能性を提供する。

（機能的アーキテクチャ）
ｏｎｅＭ２Ｍは、図３に示されるようなリソース指向アーキテクチャ（ＲＯＡ）と呼ばれるサービス層アーキテクチャを開発している。

ＲＯＡでは、アーキテクチャは、リソースの周囲に開発される。ＣＳＦは、それらのサービスを実施するためにこれらのリソースに対して動作する。リソースは、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有するアーキテクチャ内の一意にアドレス可能な要素である。これらのリソースは、ユニフォームリソース識別子（ＵＲＩ）を使用して、アドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。結果として、リソースは、基礎リソースから生じる階層ツリーと考えられることができる。親リソース表現は、その子リソースの参照を含む。子リソースの存続期間は、親リソースの存続期間によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。ある属性の組が、全てのリソースに共通する一方で、他は、特定のリソースのみに適用される。後者は、「リソース特定の属性」と称される。１つのＣＳＥ（ホスティングＣＳＥと称される）に位置するあるリソースが、遠隔ＣＳＥにアナウンスされることができ、これらは、アナウンスされたリソースと称される。アナウンスされたリソースは、オリジナルリソースの属性のみならず、それら自身の属性も含み得る。オリジナルリソースとアナウンスされたリソースとの間の同期化は、ホスティングＣＳＥの責任である。

（リソース発見ＣＳＦ）
リソース発見は、例えば、発信側等のエンティティが、アプリケーションおよびサービスについての情報を検索するプロセスであり、その情報は、属性およびリソースの中に含まれている。リソース発見の発信側は、ＡＥまたはＣＳＥであることができ、常に、受信側ＣＳＥにおけるルートリソースを標的にしている（ルートリソースは、検索が開始するリソースである）。検索結果は、発信側によって規定されるフィルタ基準および発見結果タイプに依存し、受信側ＣＳＥにおけるアクセス制御ポリシの影響を受ける。すなわち、発信側が「ＤＩＳＣＯＶＥＲ」アクセス権を有するかどうかである。発信側は、返された結果の数を限定するために、および、例えば、リソースタイプ、リソース作成時間、リソースサイズ等に基づくある検索パラメータに一致する結果のみを戻すために、フィルタ基準を使用することができる。検索パラメータの完全なリストが、以下の表３で提供される。これらのパラメータは、複合検索基準を作成するために関係演算によって組み合わせられ得る。例えば、複数の条件が一緒に使用されるとき、異なる条件は、「ＡＮＤ」論理演算を使用するものとし、同一の条件は、「ＯＲ」論理演算を使用するものとする。

発信側は、返された結果のフォーマットを受信側ＣＳＥに示すために発見結果タイプを使用することができる。２つのオプションが、利用可能である。第１は、階層アドレス指定であり、第２は、非階層アドレス指定である。リソース発見は、ＲＥＴＲＩＥＶＥ方法を使用して実装される。受信側ＣＳＥがリソース発見動作と一般的読み出し動作とを区別することを可能にするために、発信側は、専用フラグを使用して、これを受信側ＣＳＥに信号伝達する。一般的リソース発見プロシージャが、図４に示されている。ステップの各々は、番号によって表される。最初に、発信側は、リソース＜ＣＳＥＢａｓｅ＞／＜ａｐｐ０１＞の特定の子リソースを標的にして、リソース発見要求（ステップ００１）を受信側ＣＳＥに発行する。受信側ＣＳＥは、要求を処理し、発見されたリソースの適切なリストを返す（ステップ００２）。受信側ＣＳＥは、発見されたリソースのＤＩＳＣＯＶＥＲ特権に従って発見結果を限定し得、それ自身のローカルポリシに従ってフィルタ基準を変更し得る。発見されたリソースの完全なリストが返されることができない場合、受信側ＣＳＥは、発信側に警告するであろう。警告は、例えば、フラグを伴ってもよい。リソース発見応答（ステップ００３）は、フィルタ基準に一致するリソースのアドレスのリストを含む。必要とされる場合、アドレスによって指し示されるリソースを読み出すことが、発信側の責任である。

（サービス発見）
ＤＮＳ−サービス発見（ＤＮＳ−ＳＤ）は、近年ＤＮＳに追加された比較的新しい特徴である。ＤＮＳ−ＳＤは、ＤＮＳによって提供される通常の名前解決機能に加えて、利用可能なローカルネットワークＩＰベースのサービスを発見するためのＤＮＳの使用を指す。例えば、ＩＰを介してアクセスされることができるローカルネットワーク内の利用可能なプリンタに対してＤＮＳ−ＳＤに問い合わせを行う。具体的には、クライアントが探しているサービスのタイプ、例えば、印刷を考慮して、この機構は、クライアントが、標準ＤＮＳクエリを使用して、所与のドメイン内で、その所望のサービスのデバイス（名前を付けられたインスタンス）のローカルリストを発見することを可能にする。ＩＥＴＦ標準化ソリューションの商業的先駆けは、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒによるものであり、「ＡｐｐｌｅＴａｌｋ」（「Ｂｏｎｊｏｕｒ」と称されることもある）と称された。

（一般的アーキテクチャ）
図５Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

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

サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）、例えば、サービス能力の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上でホストされ得る、ＳＣＳ等の共通サービスエンティティ（ＣＳＥ）と称される。

図５Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図５Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０はさらに、例えば、本願に説明され、図に図示されるように、発信側およびホスティング／通過ＣＳＥを含む、他のデバイスとともに採用され得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態において、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。

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

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

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

図５Ｄは、例えば、図５Ａおよび５ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、組み込みセマンティクス名を伴うセンサデータのクエリ等の組み込みセマンティクス命名のための開示されたシステムおよび方法に関連付けられるデータを受信、生成、ならびに処理し得る。

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。これは、例えば、マルチホップ発見、条件付き発見、およびホスティングＣＳＥリダイレクトのための発見結果を含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。ディスプレイ８６は、組み込みセマンティクス名を使用して、ファイルまたはフォルダ内のセンサデータを表示し得る。さらに、コンピューティングシステム９０は、図５Ａおよび５Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７を含み得る。

（アンルート（ＥＮ−ＲＯＵＴＥ）リソース発見）
本願の側面によると、提案される強化発見ＣＳＦおよびアンルート処理は、付加利益をサービス層に提供する。これは、例えば、マルチホップ発見を含み、それによって、通過ＣＳＥは、フィルタ基準に一致する任意のリソースを有するかどうかを決定する。これは、条件付き発見も含み、それによって、通過ＣＳＥは、発見要求を転送する前に条件が満たされているかどうかを決定する。これはさらに、ホスティングＣＳＥリダイレクトを含み得、通過ＣＳＥは、フィルタ基準に一致するリソースを有する代替ホスティングＣＳＥを認識し、発見要求をこれらの代替ホスティングＣＳＥのうちの１つにリダイレクトすることができる。

図６に図示されるような一実施形態において、典型的サービス層展開が仮定されるであろう。図６では、発信側（ＡＥまたはＣＳＥ）６１０とホスティングＣＳＥ６３０とは、いくつかの通過ＣＳＥ６２０によって分離される。一側面では、通過ＣＳＥのうちの１つ以上のものは、複数のレジストリＣＳＥを有することができる。

処理は、典型的には、発信側で始まる。存在する場合、どの強化発見プロシージャがエンティティの各々において従われるかを示すために、単一のパラメータが、概して、含まれる。この新しいパラメータである発見タイプ（Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ）は、発信側によって生成される発見要求メッセージに含まれる。Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅは、以下のタイプの値のうちの１つ以上のものを含み得る：（ｉ）転送（強化発見プロシージャなし）、（ｉｉ）マルチホップ発見、（ｉｉｉ）条件付き発見、および（ｉｖ）ホスティングＣＳＥリダイレクト。代替として、発信側は、発見要求においてＤｉｓｃｏｖｅｒｙ Ｔｙｐｅパラメータを省略し、Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅパラメータの欠如を強化発見プロシージャを使用しない（すなわち、転送を使用する）指示として扱い得るＣＳＥにおける暗示的挙動に依拠し得る。

ＣＳＥにおいて、新しいｄｉｓｃｏｖｅｒｙＴｙｐｅ属性が採用され得る。ここで、各ＣＳＥは、随意に、強化発見プロシージャのうちの１つ以上のものをサポートし得る。この情報は、例えば、ｄｉｓｃｏｖｅｒｙＴｙｐｅ等の＜ＣＳＥＢａｓｅ＞リソースの属性に含まれ得る。属性は、サポートされた発見プロシージャをリストアップすることができる。例えば、転送（強化発見プロシージャなし）に対して、ＣＳＥは、それが通過ＣＳＥである場合、発見要求をホスティングＣＳＥに向けて転送する。この属性のための他のオプションは、例えば、マルチホップ発見、条件付き発見、およびホスティングＣＳＥリダイレクトを含み得る。

加えて、ｄｉｓｃｏｖｅｒｙＴｙｐｅ属性は、ＣＳＥが複数の強化発見機構を同時に実施することが可能であるかどうかも示し得る。例えば、ｄｉｓｃｏｖｅｒｙＴｙｐｅは、マルチホップ発見および条件付き発見であり得る。ｄｉｓｃｏｖｅｒｙＴｙｐｅ属性は、エンティティが、ＣＳＥによってサポートされるサポートされた強化発見プロシージャを発見することを可能にする。

別の側面によると、各ＣＳＥにおけるアクセス制御は、ＤＩＳＣＯＶＥＲ動作のための既存のアクセス制御規則に基づき得る。すなわち、リソースにおけるＤＩＳＣＯＶＥＲ特権を有する発信側は、強化発見プロシージャのための自動的特権を有する。代替として、さらなる融通性を提供するために、特定の発見特権は、各強化発見タイプに対して維持され得る。これは、個々の規則がマルチホップ発見、条件付き発見、およびホスティングＣＳＥリダイレクトに適用されることを可能にするであろう。例えば、３つの追加のａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓが、定義され得る：（ｉ）ＤＩＳＣＯＶＥＲ＿ＭＵＬＴＩＨＯＰは、リソースを発見し、要求を転送する特権であり、（ｉｉ）ＤＩＳＣＯＶＥＲ＿ＣＯＮＤＩＴＩＯＮＡＬは、リソースを条件付きで発見する特権であり、（ｉｉｉ）ＤＩＳＣＯＶＥＲ＿ＲＥＤＩＲＥＣＴは、ホスティングＣＳＥをリダイレクトする特権である。

次に、発信側、通過ＣＳＥ、およびホスティングＣＳＥ間の図７に図示されるような全体的処理が議論されるであろう。概して、所望のｄｉｓｃｏｖｅｒｙＴｙｐｅを規定することが、発信側の責任である。例えば、発信側が特定のホスティングＣＳＥにおける特定のリソースに関心を持っている場合、おそらく、強化プロシージャを用いることなく発見要求を発行するであろう。代替として、強化プロシージャが所望される場合、いくつかのオプションが発信側に利用可能である。発信側は、強化発見を行うために要求されるＣＳＥタイプを規定し得る。例えば、発信側は、強化発見が以下においてのみ起こることを要求し得る：（ｉ）ＭＮ−ＣＳＥ（ＡＳＮ−ＣＳＥではない）、（ｉｉ）あるクラスまたは階層のＣＳＥ（ＣＳＥが割り当てられた階層またはクラスタイプを有することを仮定する）、（ｉｉｉ）有意な処理（高メモリ、低アクティビティ等）を有するＣＳＥ、または（ｉｖ）供給されたリスト内のＣＳＥ。さらなる実施形態によると、ＣＳＥは、場合にのみ、強化発見プロシージャを行うであろう：（ｉ）それが発信側によって要求される場合、（ｉｉ）それが要求された強化発見プロシージャをサポートする場合、および（ｉｉｉ）発信側が強化プロシージャを行うアクセス権を有する場合。

マルチホップ発見中、発信側は、発見フィルタ基準に一致する任意のリソースを保有するかどうかをチェックすること、および結果を発信側に返すこと（ホスティングＣＳＥに向かう全ホップにおいて）を各通過ＣＳＥに求める発見要求を発行することができる。影響を受けたエンティティの各々における処理が、以下で説明される。

図８は、マルチホップ発見要求をハンドリングする発信側における動作を図示する。各ステップは、ローマ数字、例えば、１、２等によって表される。ステップ１では、発信側は、発見要求を発行する。例示的実施形態において、この要求は、ＲＥＴＲＩＥＶＥ方法を通して送信される。しかしながら、これは、専用方法を通して、またはＵＰＤＡＴＥ、ＣＲＥＡＴＥ、もしくは他の類似方法を通して送信され得る。要求は、以下のパラメータを含み得る。
Ｔｏ： 発見がホスティングＣＳＥ上で開始する場所のルートのホスティングＣＳＥアドレス。
Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ： 検索および期待される返される結果のためのフィルタ基準。
Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｕｌｔ Ｔｙｐｅ： 返される発見結果の随意のフォーマット。
ｄｉｓｃｏｖｅｒｙＴｙｐｅ： 発見要求を処理することを通過ＣＳＥに求めるマルチホップ発見。
ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅ： 発信側の意図について通過ＣＳＥおよびホスティングＣＳＥに知らせる。
ｒｏｕｔｅＤｉｓｃｏｖｅｒｙ： 発信側がホスティングＣＳＥへのサービス層ルーティングパスを見出すことを望むことを信号伝達する。サービス層ルーティングパスは、発信側とホスティングＣＳＥとの間の登録チェーンを辿る特別なルーティングパスであり、要求が通過ＣＳＥをトラバースするにつれて要求によって辿られるサービス層ホップを示す。例えば、発信側は、ＣＳＥ１に登録され、ＣＳＥ１は、ＣＳＥ２に登録され、ＣＳＥ２は、ＩＮ−ＣＳＥに登録される。サービス層ルーティングパスは、発信側→ＣＳＥ１→ＣＳＥ２→ＩＮ−ＣＳＥである。通過ＣＳＥは、フィルタ基準に一致するリソースを検索することを要求されないが、応答を返すように要求され、それによって、発信側は、それ自体と規定ホスティングＣＳＥとの間でサービス層ルーティングパスを維持することができる。
ｆｉｎｄＵｐｔｏＫＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側がフィルタ基準に一致する最大「Ｋ」個のリソースを望み、「Ｋ」個のリソースが見出された場合、通過ＣＳＥが発見要求を転送することを止めるべきことを信号伝達する。
ｆｉｎｄＵｐｔｏＮＨｏｐｓＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側が、発信側のＮ個のサービス層ホップ内のフィルタ基準に一致するリソースを見出すことを望むことを信号伝達する。Ｎ番目のホップを処理するＣＳＥは、発見要求を転送することを止めるべきである。
ｆｉｎｄＡｌｌＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側が、ホスティングＣＳＥ内および発信側とホスティングＣＳＥとの間の任意の通過ＣＳＥ内のフィルタ基準に一致する、全てのリソースを望むことを信号伝達する。
Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｐｏｎｓｅ： オン／オフに設定される。オンである場合、発信側に向けて応答を送信する前、発見結果を集約すべきことを通過ＣＳＥに知らせる。オフである場合、フィルタ基準に一致するリソースを見出す場合、発信側に向けて発見結果を送信すべきことを通過ＣＳＥに知らせる。
ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔパラメータ（フィルタ基準に含まれ得る）は、発信側が探している一致するリソースの数を規定する（上で説明されるような「Ｋ」の値）。
ｈｏｐＬｉｍｉｔパラメータ（フィルタ基準に含まれ得る）は、発見要求のためのサービス層ホップの最大数（上で説明されるようなＮの値）を規定する。

図８のステップ２によると、発信側は、発見応答メッセージを待つ。ｄｉｓｃｏｖｅｒｙＴｙｐｅがｍｕｌｔｉＨｏｐＤｉｓｃｏｖｅｒｙに設定され、Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｐｏｎｓｅがオフに設定された場合、発信側は、（通過ＣＳＥから、およびホスティングＣＳＥから）複数の応答メッセージを受信し得る。発信側は、応答を初期発見要求と相互参照するために要求識別子を使用する。ステップ２ａでは、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅがｒｏｕｔｅＤｉｓｃｏｖｅｒｙに設定される場合、発信側は、アドレス（またはサービス層におけるＩＤ）を抽出し、それ自体とホスティングＣＳＥとの間のＣＳＥアドレスのリストを作成する。しかしながら、ステップ２ｂに示されるように、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅがｒｏｕｔｅＤｉｓｃｏｖｅｒｙではない場合、発信側は、全ての返された結果の更新されたリストを保持する。

次に、ステップ３では、発信側は、（ｉ）ホスティングＣＳＥから応答を受信すること、または、（ｉｉ）パラメータｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥとともに通過ＣＳＥから応答を受信することに応じて、発見プロシージャを終了させ得る。これは、フィルタ基準に一致する所望の数のリソースが見出されたこと、および、発見要求が転送されることを止めたことを発信側に信号伝達し、（ｉｉｉ）パラメータｈｏｐＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥとともにＣＳＥから応答を受信する。これらは、所望の数のホップが発見要求によってトラバースされたことを発信側に信号伝達する。

別の実施形態において、発信側は、随意に、２つの別個のリストを保持し得る。１つはオリジナルリソースのもの、１つはアナウンスされたリソースのものである。それは、全て（または選択数）のアナウンスされたリソースのオリジナルリソースアドレスを読み出すことを決定し得る。アナウンスされたリソースリスト上のリソースが、オリジナルリソースリスト上のリソースを指し示していることを決定する場合、それは、アナウンスされたリソースを重複としてマークし得るか、またはアナウンスされたリソースを削除することを決定し得る。

（マルチホップ発見のための通過ＣＳＥにおけるプロシージャ）
さらに別の実施形態によると、図９は、Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｐｏｎｓｅ＝Ｏｎを伴う事例のための通過ＣＳＥにおけるプロシージャを図示する。これは、通過ＣＳＥにおける発見要求応答メッセージが発信側に即時に返送されないことを意味する。ステップ１によると、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅがｒｏｕｔｅＤｉｓｃｏｖｅｒｙであるかどうかチェックが行われる。該当する場合、通過ＣＳＥは、以下のパラメータを含むが、それらに限定されない発見応答メッセージをステップ２で準備する：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：標的ＣＳＥのＣＳＥアドレス。随意に、通過ＣＳＥは、この通過ＣＳＥに関連する他の情報、例えば、ロードする条件、アクセス制御等を追加し得る。メッセージは、続いて、ステップ１７で発信側に送信される。

一方で、ステップ１におけるクエリが否定であると決定される場合、通過ＣＳＥは、発見を開始すべきローカルルートリソースを決定する（ステップ２）。これは、通過ＣＳＥルート、例えば、／ＣＳＥＢａｓｅに設定され得る。次に、通過ＣＳＥは、フィルタ基準に一致する任意のリソースがあるかどうかチェックする（ステップ３）。クエリへの応答が「いいえ」である場合、通過ＣＳＥ（ＣＳＥ＿Ａ）は、ホスティングＣＳＥに登録されている場合、ホスティングＣＳＥに向けて要求を転送するか、または通過ＣＳＥ（ＣＳＥ＿Ａ）が登録されている別の通過ＣＳＥ（ＣＳＥ＿Ｂ）に要求を転送する（ステップ６）。

一方で、クエリへの応答が「はい」である場合、通過ＣＳＥは、いくつの結果を返すべきかを決定する（ステップ４）。ここでは、通過ＣＳＥは、Ｍｕｌｔｉｈｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅがｆｉｎｄＵｐｔｏＮＨｏｐＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙに等しいかどうかをチェックする。該当する場合、通過ＣＳＥは、ホップカウントに基づいて、それが最後のＣＳＥであるかどうかをチェックする（発見要求の中のｈｏｐＬｉｍｉｔ＝＝１）（ステップ５）。チェックが偽である場合、通過ＣＳＥは、以下のパラメータを伴う応答メッセージを準備する（ステップ８）：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：見出されたリソースのリスト、および（ｉｖ）ｈｏｐＬｉｍｉｔＲｅａｃｈｅｄ＝ＦＡＬＳＥ。通過ＣＳＥは、１だけｈｏｐＬｉｍｉｔをデクリメントすることによって発見要求メッセージを修正する。通過ＣＳＥは、次いで、ホスティングＣＳＥに向けて発見要求メッセージを転送する。その後、それは、発見応答メッセージが集約することを待つ、ステップ１５を進める。

ステップ５におけるクエリへの回答が「はい」である場合、通過ＣＳＥは、以下のパラメータを伴う応答メッセージを準備する（ステップ９）：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：見出されたリソースのリスト、および（ｉｖ）ｈｏｐＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥ。ここでは、通過ＣＳＥは、発見要求メッセージを転送しない。通過ＣＳＥは、発見要求応答メッセージを発信側に送信するステップ１７に進む。

一方で、ステップ４におけるクエリへの応答が「いいえ」である場合、通過ＣＳＥは、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅがｆｉｎｄＵｐｔｏＫＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙまたは＝ｆｉｎｄＡｌｌＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙであるかどうかをチェックする（ステップ１０）。これが前者である場合、通過ＣＳＥは、Ｌ個の一致するリソースのリストを有し、発見要求の中で規定されるｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔは、「Ｋ」である。通過ＣＳＥは、Ｌ＜Ｋであるかどうかをチェックする（ステップ１１）。Ｌ＜Ｋである場合（ステップ１２）、通過ＣＳＥは、以下のパラメータを伴う応答メッセージを準備する：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：Ｌ個の見出されたリソースのリスト、および（ｉｖ）ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＦＡＬＳＥ。次いで、通過ＣＳＥは、見出されたリソースの数だけｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔをデクリメントすることによって（ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔ＝ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔ−Ｌ）、発見要求メッセージを修正する。通過ＣＳＥは、ホスティングＣＳＥに向けて発見要求メッセージを転送する。次いで、ＣＳＥは、発見応答メッセージが集約することを待つ（ステップ１５）。

そうでなければ、ステップ１１におけるクエリへの回答が「いいえ」である場合、通過ＣＳＥは、以下のパラメータを伴う応答メッセージを準備する（ステップ１３）：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：Ｋ個の見出されたリソースのリスト、および（ｉｖ）ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥ。通過ＣＳＥは、発見要求メッセージを転送せず、発見応答メッセージを発信側に送信することを進め得る（ステップ１７）。

ステップ１０へのクエリへの回答がｆｉｎｄＡｌｌＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙである場合、ステップ１４に進む。ここでは、通過ＣＳＥは、以下のパラメータを伴う応答メッセージを準備する：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：見出されたリソースのリスト、および（ｉｖ）ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＦＡＬＳＥ。通過ＣＳＥは、ホスティングＣＳＥに向けて発見要求メッセージを転送し続ける。次いで、通過ＣＳＥは、ステップ１５で発見応答メッセージを待ってもよい。発見応答の受信時、通過ＣＳＥは、応答を要求と相互参照するために要求ＩＤを使用する（ステップ１６）。それは、次いで、受信された応答から結果を抽出し、この情報をステップ（７、８、１２、または１４）で準備される発見応答に集約する。最終的に、通過ＣＳＥは、その処理を終了する（ステップ１８）。

（マルチホップ発見のためのホスティングＣＳＥにおけるプロシージャ）
図１０に図示されるような別の実施形態によると、発見要求の受信時におけるホスティングＣＳＥにおける動作が説明される。ステップ１では、ホスティングＣＳＥは、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅが何であるかをチェックする。これがＲｏｕｔｅＤｉｓｃｏｖｅｒｙである場合、パラメータを伴う発見応答メッセージ（ホスティングＣＳＥのアドレスを伴う）を生成するステップ７に進む。メッセージは、Ｔｏ：発信側のＩＤ、Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、およびＣｏｎｔｅｎｔ：ホスティングＣＳＥのＣＳＥアドレスを含む。随意に、ホスティングＣＳＥは、このホスティングＣＳＥに関連する他の情報、例えば、ロードする条件、アクセス制御等を追加し得る。次に、発見応答メッセージが送信される（ステップ８）。その後、ＣＳＥは、その処理を終了する（ステップ９）。

一方で、ステップ１から、発見サブタイプがｆｉｎｄＡｌｌＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙである場合、ステップ４に進む。ステップ４では、ホスティングＣＳＥは、パラメータを伴う発見応答メッセージを生成する：Ｔｏ：発信側のＩＤ、Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、およびＣｏｎｔｅｎｔ：フィルタ基準に一致する全てのリソースのアドレス。次いで、このプロセスは、上記で議論されるようなステップ８を進める。

代替として、ステップ１から、発見サブタイプがｆｉｎｄＵｐｔｏＫＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙである場合、このプロセスは、ホスティングＣＳＥがフィルタ基準に一致する任意のリソースがあるかどうかをチェックするステップ２に移行する。該当しない場合、それは、上で説明されるようなステップ７に進む。該当する場合、それは、いくつの結果を返すべきかを決定する（ステップ３）。具体的には、ホスティングＣＳＥは、Ｌ個の一致するリソースのリストおよび発見要求の中で規定されるｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔを有する。Ｌ＜Ｋである場合、このプロセスは、ステップ５に進む。ステップ５では、ホスティングＣＳＥは、以下のパラメータを伴う応答メッセージを準備する：Ｔｏ：発信側のＩＤ、Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、Ｃｏｎｔｅｎｔ：Ｌ個の見出されたリソースのリスト、ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥ。ステップ５から、このプロセスは、上で説明されるようなステップ８に進み、次いで、上で説明されるようなステップ９に進む。

代替として、ステップ３からの回答が「いいえ」である場合、このプロセスは、ステップ６に進む。ステップ６では、ホスティングＣＳＥは、以下のパラメータを伴う応答メッセージを準備する：Ｔｏ：発信側のＩＤ、Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、Ｃｏｎｔｅｎｔ：Ｋ個の見出されたリソースのリスト、ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥ。次いで、これは、ステップ８を進める。

マルチホップ発見プロシージャは、代替物を有し得る。発信側は、マルチホップ処理を行う必要がある通過ＣＳＥを具体的にリストアップし得る。通過ＣＳＥがリスト上にない場合、それは、ホスティングＣＳＥに向けて発見要求を転送することに戻り得る。

（マルチホップ発見コールフロー）
図１１に示されるような別の実施形態によると、エンティティの各々における処理およびそれらの間の信号伝達が説明されている。コールフローは、発信側が規定フィルタ基準に一致する最初の３つのリソースを探していることを仮定する。この基準に一致するリソースは、通過ＣＳＥ２（２ｘ）の中、通過ＣＳＥ３（２ｘ）の中、およびＩＮ−ＣＳＥ（１ｘ）の中に位置する。示されていないが、発信側が集約応答を要求したことが仮定される（Ａｇｇｒｅｇａｔｅｄ Ｒｅｓｐｏｎｓｅ＝Ｏｎ）。

ステップ１では、発信側は、ＩＮ−ＣＳＥに向けて、Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｍｕｌｔｉｈｏｐＤｉｓｃｏｖｅｒｙ、ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅ＝ｆｉｎｄＵｐｔｏＫＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ、ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔ＝３を規定する発見要求を発行する。

本実施形態において、ステップ２で、通過ＣＳＥ１において、一致するリソースが存在しないので、発見要求がＩＮ−ＣＳＥに向けて転送される。ステップ３では、通過ＣＳＥ２において、２つの一致するリソースが存在する。通過ＣＳＥは、（一致するリソース限界を１まで低減させて）発見要求を更新し、ＩＮ−ＣＳＥに向けてそれを転送する。さらに、通過ＣＳＥ２は、保留の発見応答（２つの一致するリソースのアドレスを伴う）を準備し、次いで、発見応答を待つ。

ステップ４では、通過ＣＳＥ３において、２つの一致するリソースが存在するが、要求は、もう１つのリソースのみを探している。通過ＣＳＥ３は、発見応答（１つの一致するリソースのアドレスを伴う）を準備し、発信側に向けて、以下のうちの１つ以上のものを規定する発見応答を送信する：ｃｏｎｔｅｎｔ＝一致するリソースのアドレスおよびｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥ。発見要求はＩＮ−ＣＳＥに向けて転送されないことに留意されたい。

ステップ５では、通過ＣＳＥ２において、受信された発見応答からの結果は、（ステップ３からの）保留の発見応答に付加され、保留の発見応答は、発信側に向けて送信される。詳細は、ｃｏｎｔｅｎｔ＝一致するリソース（通過ＣＳＥ２から２つおよび通過ＣＳＥ３から１つ）のアドレスのリスト、およびｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ＝ＴＲＵＥを含むが、それらに限定されない。ステップ６では、通過ＣＳＥ１において、保留の発見応答がないので、受信された発見応答は、発信側に向けて転送される。

（条件付き発見）
本願の別の側面によると、発信側は、ホスティングＣＳＥに向けて発見要求を発行し得る。しかしながら、それは、別のリソースに対する条件が満たされる場合にのみ行われる必要があり得る。条件は、「条件付きＣＳＥ」と称されるＣＳＥにおいてチェックされる。以下の説明は、単一の条件に適用されるが、処理は、任意の数の条件を含むように一般化されることができる。影響を受けたエンティティの各々における処理が、以下で説明される。

一実施形態において、必須条件として、発信側は、条件がチェックされるべきリソースのアドレスを把握している。これは、事前発見プロシージャによって取得されていることもある。ステップ１によると、発信側は、発見要求を発行する。これは、専用方法を通して、またはＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＣＲＥＡＴＥ、もしくは他の類似方法を通して送信され得る。要求は、以下のパラメータのうちの１つ以上のものを含み得る：（ｉ）Ｔｏ：発見がホスティングＣＳＥ上で開始する場所のルートのアドレス、（ｉｉ）Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：検索および期待される返される結果のためのフィルタ基準、（ｉｉｉ）Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｕｌｔ Ｔｙｐｅ：返される発見結果の随意のフォーマット、（ｉｖ）Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙ：条件付き通過ＣＳＥである場合に発見要求を処理することを通過ＣＳＥに求める、（ｖ）ＣｏｎｄｉｔｉｏｎｅｄＯｎ：条件がチェックされるべきリソースのアドレス、（ｖｉ）ＣｏｎｄｉｔｉｏｎＣｒｉｔｅｒｉａ：条件がチェックされるべきリソースのための基準。基準は、メモリサイズ、リソースタイプ、バッテリステータス等に基づき得る。（ｖｉｉ）ＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅ：条件に見切りをつける前、条件付き通過ＣＳＥがどれだけ待つべきか。０の値は、発見要求の受信時にのみ、チェックが行われるべきことを示す。ゼロではない値は、発見要求を転送する前、条件が満たされるまで条件付き通過ＣＳＥが待つことを可能にされることを示す。ＣＳＥは、ＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅ時間にわたって、または発見要求が満了するまで待つことを可能にされる。

ステップ２によると、発信側は、発見応答メッセージを待つ。発信側は、条件付き通過ＣＳＥからのＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＦＡＩＬを伴う応答を受信すると、発見プロシージャを終了させ得る。これは、条件が満たされておらず、条件付き発見に一致するリソースがないことを発信側に信号伝達する。それは、ホスティングＣＳＥから応答を受信する場合にも発見要求を終了させ得る。これは、条件が条件付き通過ＣＳＥにおいて満たされ、返された結果がホスティングＣＳＥにおけるフィルタ基準に一致することを発信側に信号伝達する。

図１２は、発見要求の受信時における通過ＣＳＥにおける動作を図示する。ステップ１では、ＣＳＥは、通過ＣＳＥが条件付きＣＳＥである（通過ＣＳＥが発見要求のＣｏｎｄｉｔｏｎｅｄＯｎパラメータの中のＣＳＥに対応する）かどうかをチェックする。該当する場合、このプロセスは、ステップ３に進むであろう。そうでなければ、このプロセスは、ステップ２に進み、ホスティングＣＳＥに向けて要求を転送し続ける。ステップ２によると、通過ＣＳＥ（ＣＳＥ＿Ａ）は、それがホスティングＣＳＥに登録されている場合に要求をホスティングＣＳＥに転送するか、または代替として、通過ＣＳＥ（ＣＳＥ＿Ａ）が登録されている別の通過ＣＳＥ（ＣＳＥ＿Ｂ）に要求を転送する。次いで、それは、ステップ１０に進む。

次に、ステップ３では、このプロセスは、ＣｏｎｄｉｔｉｏｎＣｒｉｔｅｒｉａが、発見要求のＣｏｎｄｉｔｏｎｅｄＯｎパラメータによって指し示されるリソースのために満たされているかどうかをチェックする（ステップ３）。該当する場合、これは、ステップ２に移行する。そうでなければ、このプロセスは、ステップ４に移行する。ステップ４では、ＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅがゼロであるかどうかをチェックする。該当する場合、ステップ５に移行し、以下のパラメータを伴う発見応答メッセージを準備する：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、および（ｉｉｉ）Ｃｏｎｔｅｎｔ：空、ＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＦＡＩＬ。次いで、このプロセスは、通過ＣＳＥ処理が終了するステップ１０に進む。

ステップ４から、回答が「いいえ」である場合、それは、ステップ６に移行し、持続性タイマを開始する。このタイマは、要求された条件に見切りをつける前、通過ＣＳＥがどれだけ待つべきかを表す。代替として、通過ＣＳＥは、ホスティングＣＳＥに向けて発見要求をさらに転送し得るが、それは、パラメータＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＦＡＩＬを伴う。これは、図には示されていない。

ステップ７は、ステップ６から続行する。ここでは、条件がＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅ時間中に満たされるかどうかチェックが行われる。該当する場合、ステップ８に移行する。ここでは、持続性タイマが停止される。次いで、ステップ２に進み、ホスティングＣＳＥに向けて発見要求を転送する。代替として、ステップ６で開始される持続性タイマが満了する場合、ステップ５に移行する。代替として、発見要求が満了する場合、ステップ９に移行する。

代替として、ステップ７から、発見要求が満了する場合、持続性タイマを停止し（ステップ９）、次いで、ステップ５に移行する。さらに、処理は、ステップ１０で終了する。

実施形態において、通過ＣＳＥが条件付きＣＳＥである場合、それは、ホスティングＣＳＥに転送される発見要求の中に条件が成功したという指示を含み得る（図示せず）。条件付きＣＳＥはさらに、条件が満たされるとき、発見応答を発信側に送信し得る（図示せず）。発信側は、その初期クエリからの発見応答が間もなく到着するという指示としてこれを使用し得る。

（条件付き発見のためのホスティングＣＳＥにおけるプロシージャ）
ホスティングＣＳＥにおけるプロシージャは、以下で説明される通りである。このプロシージャは、条件が満たされる場合にのみ、条件付き通過ＣＳＥが発見要求を転送することを仮定する。そのような場合、ホスティングＣＳＥにおいて受信される発見要求は、パラメータＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＰＡＳＳを有し得る。ステップ１によると、ホスティングＣＳＥは、フィルタ基準に一致するリソースを検索する。それは、検索結果に基づいて発見応答を準備し、ステップ２に進む。ここでは、ホスティングＣＳＥは、発見応答メッセージを送信する。このプロセスを終了するステップ５に進む。

代替として、ホスティングＣＳＥがパラメータＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＦＡＩＬを伴う発見要求を受信し得ることが仮定される場合、ホスティングＣＳＥにおけるプロシージャは、以下に説明される通りである。これは、たとえ条件が満たされなくても、条件付き通過ＣＳＥがホスティングＣＳＥに向けて発見要求を転送することを意味する。これは、以下の場合において起こり得る：（ｉ）ホスティングＣＳＥが、何回の発見試行がリソースに対して行われたかという指示を欲する場合、または、（ｉｉ）通過ＣＳＥが発見応答で発見要求に応答することを許可されていない場合。ステップ１では、ホスティングＣＳＥは、発見要求がＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙタイプであるかどうかをチェックする。該当しない場合、それは、ステップ２に進む。ステップ２では、ホスティングＣＳＥは、フィルタ基準に一致するリソースを検索する。それは、検索結果に基づいて発見応答を準備し、ステップ４に進む。

そうでなければ、このプロセスは、ホスティングＣＳＥがＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓをチェックするステップ３に進む。ＰＡＳＳである場合、次いで、ステップ２に進む。ＦＡＩＬである場合、以下のパラメータを伴う発見応答メッセージを準備する：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、および（ｉｉｉ）Ｃｏｎｔｅｎｔ：空。その後、ホスティングＣＳＥは、発見応答メッセージを送信する（ステップ４）。次いで、ホスティングＣＳＥにおいて処理を終了するステップ５に進む。

（条件付き発見コールフロー）
例えば、図１３に示されるような別の実施形態によると、上記の実施形態のうちの１つからのエンティティの各々における処理およびそれら間の信号伝達の例を示す。コールフローは、ノード１における利用可能なメモリを監視するリソース１（ノード１、通過ＣＳＥ２）が１キロバイト未満である（ｃｏｎｄｉｔｉｏｎ１→ｎｏｄｅ１／ｍｅｍｏｒｙ／ｍｅｍＡｖａｉｌａｂｌｅ＜１ＫＢｙｔｅ）場合にのみ、発信側がＩＮ−ＣＳＥの中の規定フィルタ基準に一致するリソース（１キロバイトを上回るリソースサイズ）を探していることを仮定する。

ステップ１によると、発信側は、ＩＮ−ＣＳＥに向けて発見要求を発行する。要求は、以下のうちの１つ以上のものを規定し得る：（ｉ）Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙ、（ｉｉ）ＣｏｎｄｉｔｉｏｎＯｎ＝／ＴｒａｎｓｉｔＣＳＥ２／ｒｅｓｏｕｒｃｅ１、および（ｉｉｉ）ＣｏｎｄｉｔｉｏｎＣｒｉｔｅｒｉａ：ｍｅｍＡｖａｉｌａｂｌｅ＜１Ｋｂｙｔｅ。ステップ２では、通過ＣＳＥ１が条件付きＣＳＥではないので、発見要求は、ＩＮ−ＣＳＥに向けて転送される。ステップ３では、通過ＣＳＥ２が条件付きＣＳＥであるので、ＣＳＥは、ＣｏｎｄｉｔｉｏｎＣｒｉｔｅｒｉａが満たされているかどうかを検証する。条件が満たされる場合、通過ＣＳＥ２は、さらなる処理のためにＩＮ−ＣＳＥに向けて発見要求を転送する。条件が満たされない場合、通過ＣＳＥ２は、以下のうちの１つ以上のものを規定する発見応答を準備し、発信側に返す：（ｉ）Ｔｏ：発信者、（ｉｉ）ｃｏｎｔｅｎｔ＝“ｅｍｐｔｙ”、および（ｉｉｉ）ＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＦＡＬＳＥ。ステップ４では、通過ＣＳＥ３が条件付きＣＳＥではないので、発見要求は、ＩＮ−ＣＳＥに向けて転送される。さらに、ステップ５では、発見要求がホスティングＣＳＥに到達する場合、これは、条件が成功したことを意味する。ＩＮ−ＣＳＥは、フィルタ基準に一致するリソースのリストを取得し、発見応答を生成し、発信側に向けてそれを送信する。詳細：（ｉ）Ｔｏ：発信者、（ｉｉ）ｃｏｎｔｅｎｔ＝一致するリソースのアドレスのリスト、および、（ｉｉｉ）随意に、ＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ＝ＴＲＵＥ。

（ホスティングＣＳＥリダイレクトを用いた発見）
本願のその上さらなる側面によると、発信側は、ホスティングＣＳＥに向けて発見要求を発行し得る。それは、同時に、通過ＣＳＥがフィルタ基準に一致するリソースを有する代替ホスティングＣＳＥについて把握しているかどうか、それらにクエリを行い得る。影響を受けたエンティティの各々における処理が、以下で説明される。第１のプロトコルが、ホスティングＣＳＥリダイレクトのために発信側にある。

ステップ１では、発信側は、発見要求を発行する。これは、専用方法を通して、またはＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＣＲＥＡＴＥ、もしくは他の類似方法を通して送信され得る。要求は、以下のパラメータを含み得る：（ｉ）Ｔｏ：発見がホスティングＣＳＥ上で開始する場所のルートのアドレス、（ｉｉ）Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：検索および期待される返される結果のためのフィルタ基準、（ｉｉｉ）Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｕｌｔ Ｔｙｐｅ：返される発見結果の随意のフォーマット、（ｉｖ）Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｈｏｓｔｉｎｇＣＳＥＲｅｄｉｒｅｃｔ：フィルタ基準に一致するリソースを有する代替ホスティングＣＳＥを把握しているかどうかを査定するように通過ＣＳＥに知らせる。例えば、標的ＣＳＥは、発見検索基準への一致があるかどうかを確認するために、それがホストしている全てのアナウンスされたリソースを調べ得る。代替として、通過ＣＳＥが処理／転送した全ての以前の発見応答のキャッシュを保持する場合、通過ＣＳＥは、フィルタ基準に一致する任意のリソースがあるかどうかを決定するために、このキャッシュを調べ得る。

さらに別のパラメータは、ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎを含み得る。これは、代替ホスティングＣＳＥについて把握している場合に通過ＣＳＥにおいて行われるべきアクションであり得る。可能なオプションは、ｎｏｔｉｆｙＯｒｉｇｉｎａｔｏｒを含み、それは、代替ホスティングＣＳＥが存在することを発信側に通知する。新しい発見要求を代替ホスティングＣＳＥに送信する最終決定は、発信側に委ねられる。これは、ｔａｋｅＡｕｔｏｎｏｍｏｕｓＡｃｔｉｏｎのアクションも含み得る。これは、通過ＣＳＥがホスティングＣＳＥを自律的に変更することを可能にする（プライバシまたはセキュリティをあまり要求しないサービスもしくはアプリケーションに対して）。

ステップ２によると、発信側は、発見応答メッセージを待つ。発信側は、以下のアクションのうちの１つ以上のものに応じて、発見プロシージャを終了させ得る。１つのアクションは、潜在的ホスティングＣＳＥのリストと、随意に、これらの潜在的ホスティングＣＳＥのためのメトリクスとを伴う、通過ＣＳＥから応答を受信することを含み得る。発信側は、次いで、（供給されたメトリクスに基づいて）最良のホスティングＣＳＥを決定し、新しい発見要求を発行することができる。別のアクションは、ホスティングＣＳＥから応答を受信することを含み得る。これが発見要求の場合と同じホスティングＣＳＥである場合、ホスティングＣＳＥリダイレクトが起こっていない。これが発見要求の場合と同じホスティングＣＳＥではない場合、これは、通過ＣＳＥがホスティングＣＳＥを自律的に変更したことを発信側に信号伝達する。代替として、発見応答は、ｄｉｓｃｏｖｅｒｙＲｅｄｉｒｅｃｔパラメータを含み得る。このパラメータがＴＲＵＥに設定されている場合、それは、ホスティングＣＳＥがリダイレクトされたことを発信側に信号伝達する。

別の実施形態において、ホスティングＣＳＥリダイレクトのための通過ＣＳＥにおけるプロシージャがある。図１４は、例えば、発見要求の受信時における通過ＣＳＥにおける動作を図示する。ステップ１によると、通過ＣＳＥがフィルタ基準に一致するリソースを有する任意の代替ホスティングＣＳＥについて把握しているかどうか、チェックが行われる。例えば、これは、通過ＣＳＥへのアナウンスメントを通して達成され得る。該当する場合、このプロセスは、ステップ３に進む。ステップ３では、ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎがｎｏｔｉｆｙＯｒｉｇｉｎａｔｏｒであるかどうか、クエリが行われる。該当する場合、ステップ４に進み、以下の１つ以上のパラメータを伴う発見応答メッセージを準備し得る：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：通過ＣＳＥのＩＤ、および（ｉｉｉ）Ｃｏｎｔｅｎｔ：潜在的ホスティングＣＳＥのアドレス、および随意に、これらのＣＳＥに関連付けられるメトリクス。いくつかのメトリクスは、サービス層パラメータ、例えば、トラフィック負荷、サービス層ホップ、下層ネットワークパラメータ、例えば、ホップの数、下層アクセスネットワークのタイプ、および維持されたリソースについての情報、例えば、タイプ、ある基本的セマンティクス等を含み得る。さらに、通過ＣＳＥは、発見要求を転送しない。次いで、このプロセスは、ステップ６に進む。

代替として、クエリがステップ３から「いいえ」である場合、ステップ５に進む。ステップ５では、それは、最良のホスティングＣＳＥを選定する。これは、ホスティングＣＳＥへの最低ホップカウント、ホスティングＣＳＥへの下層ネットワーク接続性等に基づき得る。選定されたホスティングＣＳＥが発見要求メッセージに含まれるものと異なる場合、選定されたホスティングＣＳＥに一致するように「Ｔｏ」パラメータを変更することによって、発見要求メッセージを修正する。それは、これがリダイレクトされた発見要求であるという指示を含む（ｄｉｓｃｏｖｅｒｙＲｅｄｉｒｅｃｔ＝ＴＲＵＥを設定する）。次いで、それは、選定されたホスティングＣＳＥに向けて発見要求を転送する。次いで、このプロセスは、ステップ６に進む。代替として、標的ＣＳＥは、発見要求を全ての代替ホスティングＣＳＥ（またはあるメトリクス（例えば、より低いホップカウント）に基づいてこれらの一部）にファンアウトし得る。さらに、このプロセスは、終了する（ステップ６）。

その上さらに、ステップ１からのクエリが「いいえ」である場合、それは、ホスティングＣＳＥに向けて要求を転送するために、ステップ２を続ける。ステップ２によると、通過ＣＳＥ（ＣＳＥ＿Ａ）は、ホスティングＣＳＥに登録されている場合は要求をホスティングＣＳＥに転送する。代替として、それは、通過ＣＳＥ（ＣＳＥ＿Ａ）が登録されている別の通過ＣＳＥ（ＣＳＥ＿Ｂ）に要求を転送し得る。次いで、このプロセスは、ステップ６に進み得る。

その上さらに別の実施形態において、プロシージャは、ホスティングＣＳＥリダイレクトのためのホスティングＣＳＥにおけるものであり得る。ステップ１によると、ホスティングＣＳＥは、フィルタ基準に一致するリソースを検索する。それは、検索結果に基づいて発見応答を準備し、ステップ２に進む。ステップ２では、ホスティングＣＳＥは、発見応答メッセージを準備する。それは、以下のパラメータを含み得る：（ｉ）Ｔｏ：発信側のＩＤ、（ｉｉ）Ｆｒｏｍ：ホスティングＣＳＥのＩＤ、（ｉｉｉ）Ｃｏｎｔｅｎｔ：フィルタ基準に一致するリソースのリスト、および（ｉｖ）ｄｉｓｃｏｖｅｒｙＲｅｄｉｒｅｃｔ：発見要求メッセージの中のｄｉｓｃｏｖｅｒｙＲｅｄｉｒｅｃｔパラメータの値に設定されている。ＴＲＵＥに設定される場合、これが発見要求メッセージに含まれるホスティングＣＳＥではないことを発信側に示す。

別の実施形態によると、ホスティングＣＳＥリダイレクトコールフローが説明されるであろう。図１５に示されるように、コールフローは、１つ以上の実施形態からのエンティティの各々における処理およびそれら間の信号伝達の例を示す。エンティティの間の太い矢印は、登録関係を表す。通過ＣＳＥ２および通過ＣＳＥ４は、両方とも通過ＣＳＥ３に登録される。しかしながら、通過ＣＳＥ４は、発信側からＩＮ−ＣＳＥまでの登録パスの上にない。これを反映するために、通過ＣＳＥ４は、赤で示されている。コールフローは、発信側が規定フィルタ基準に一致するリソースを探していることを仮定する。発信側は、ＩＮ−ＣＳＥの中のリソース発見を標的にするが、標的ＣＳＥが他のＣＳＥの中の一致するリソースについて把握している場合、標的ＣＳＥがホスティングＣＳＥを自律的に変更することを可能にする。提示される例では、通過ＣＳＥ３は、（例えば、登録プロシージャ中に通過ＣＳＥ３の中で作成される遠隔ＣＳＥの結果として）通過ＣＳＥ４の中の一致するリソースを認識している。

ステップ１によると、発信側は、ＩＮ−ＣＳＥに向けて、以下のうちの１つ以上のものを規定する発見要求を発行する：（ｉ）Ｔｏ：ＩＮ−ＣＳＥ、（ｉｉ）Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｈｏｓｔｉｎｇＣＳＥＲｅｄｉｒｅｃｔ、および（ｉｉｉ）ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎ＝ｔａｋｅＡｕｔｏｎｏｍｏｕｓＡｃｔｉｏｎ。ステップ２では、通過ＣＳＥ１がいかなる他の潜在的ホスティングＣＳＥについても知らないので、発見要求は、ＩＮ−ＣＳＥに向けて転送される。ステップ３では、通過ＣＳＥ２がいかなる他の潜在的ホスティングＣＳＥについても知らないので、発見要求は、ＩＮ−ＣＳＥに向けて転送される。ステップ４では、通過ＣＳＥ３は、フィルタ基準に一致するリソースが通過ＣＳＥ４において見出され得ることを把握している。それは、発見要求のホスティングＣＳＥを自律的に変更することを決定する。それは、発見要求を修正し、さらなる処理のために通過ＣＳＥ４に向けて要求を転送する。修正された発見要求：（ｉ）Ｔｏ：通過ＣＳＥ４、（ｉｉ）Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｈｏｓｔｉｎｇＣＳＥＲｅｄｉｒｅｃｔ、および（ｉｉｉ）ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎ＝ｔａｋｅＡｕｔｏｎｍｏｕｓＡｃｔｉｏｎ。

ステップ５では、通過ＣＳＥ４は、フィルタ基準に一致するリソースのリストを取得し、発見応答を生成し、発信側に向けてそれを送信する。詳細は、（ｉ）Ｔｏ：発信側、および、（ｉｉ）ｃｏｎｔｅｎｔ＝一致するリソースのアドレスのリストを含むがそれらに限定されない。

（実施形態）
表４にリストアップされるような新しい属性が、既存のｏｎｅＭ２Ｍ＜ＣＳＥＢａｓｅ＞リソースのために提案される。

３つの新しいサポートされる動作は、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓによって認可され得る。これらは、表５にリストアップされている。

ＲＥＴＲＩＥＶＥ要求のための新しいパラメータがある。これらは、以下を含む。
Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ： 発見関連要求に適用され、発信側によって要求される強化発見プロシージャを示すために使用される随意のパラメータ。Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅのための以下の値が定義される。
ｍｕｌｔｉＨｏｐＤｉｓｃｏｖｅｒｙ： 通過ＣＳＥが、本願において上で説明されるような論理に従うことができる。
ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙ： 通過ＣＳＥが、本願において上で説明されるような論理に従うことができる。
ｈｏｓｔｉｎｇＣＳＥＲｅｄｉｒｅｃｔ： 通過ＣＳＥが、本願において上で説明されるような論理に従うことができる。
ｆｏｒｗａｒｄｉｎｇ： 通過ＣＳＥが、発見要求を転送するのみである。

発信側は、その要求の中で複数の発見タイプ、例えば、ｍｕｌｔｉＨｏｐＤｉｓｃｏｖｅｒｙ＋ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙを規定し得る。代替として、ＤｉｓｃｏｖｅｒｙＴｙｐｅが存在しない場合、通過ＣＳＥは、要求を処理すべきでなく、単純に、上で説明されるように要求を転送し、例えば、現在の発見にロールバックすべきである。
ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ ＳｕｂＴｙｐｅ： ＤｉｓｃｏｖｅｒｙＴｙｐｅ＝ｍｕｌｔｉＨｏｐＤｉｓｃｏｖｅｒｙであるとき、発見関連要求に適用される随意のパラメータ。マルチホップ発見の目的および通過ＣＳＥにおいて要求される論理を示すために使用される。ＭｕｌｔｉＨｏｐ Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅのための以下の値が、定義される。
ｒｏｕｔｅＤｉｓｃｏｖｅｒｙ： 発信側がホスティングＣＳＥへのサービス層ルーティングパスを見出すことを望むことを信号伝達する。
ｆｉｎｄＵｐｔｏＫＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側がフィルタ基準に一致する最大Ｋ個のリソースを望むことを信号伝達する。
ｆｉｎｄＵｐｔｏＮＨｏｐＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側が、発信側からのＫ個のサービス層ホップ内のフィルタ基準に一致するリソースを見出すことを望むことを信号伝達する。
ｆｉｎｄＡｌｌＲｅｓｏｕｒｃｅｓＤｉｓｃｏｖｅｒｙ： 発信側がフィルタ基準に一致する全てのリソースを望むことを信号伝達する。
ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎ： ＤｉｓｃｏｖｅｒｙＴｙｐｅ＝ｈｏｓｔｉｎｇＣＳＥＲｅｄｉｒｅｃｔであるとき、発見関連要求に適用される随意のパラメータ。通過ＣＳＥが発見要求を自律的にリダイレクトすることができるかどうか、またはこれが発信側によって行われるものであるかどうかを示すために使用される。ＲｅｑｕｅｓｔｅｄＡｃｔｉｏｎのための以下の値が定義される。
ｎｏｔｉｆｙＯｒｉｇｉｎａｔｏｒ： 新しい発見要求を代替ホスティングＣＳＥに送信する最終決定が発信側に委ねられる。
ｔａｋｅＡｕｔｏｎｏｍｏｕｓＡｃｔｉｏｎ： 通過ＣＳＥがホスティングＣＳＥを自律的に変更することを可能にする。
ＣｏｎｄｉｔｉｏｎｅｄＯｎ： Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙであるときに含まれるべき随意のリソースアドレス。これは、条件が検証されるべきリソースを示す。
ＣｏｎｄｉｔｉｏｎＣｒｉｔｅｒｉａ： Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙであるときに含まれるべき随意の基準。これは、ＣｏｎｄｉｔｉｏｎｅｄＯｎリソースに対して試験されるべき基準を表す。
ＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅ： Ｄｉｓｃｏｖｅｒｙ Ｔｙｐｅ＝ｃｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙであるときに含まれるべき随意のタイマ値。これは、どれだけ条件付き通過ＣＳＥがＣｏｎｄｉｔｉｏｎｅｄＯｎリソースに対して条件を監視するであろうかを表す。０である場合、条件付き通過ＣＳＥは、発見要求の受信時、条件をチェックするであろう。ゼロではない場合、条件付き通過ＣＳＥは、条件が満たされることを待つであろう。それは、（どちらが最初であっても）ＣｏｎｄｉｔｉｏｎＰｅｒｓｉｓｔｅｎｃｅ時間後、または発見要求の満了後のいずれかで、断念し、条件が満たされなかったことについて発信側に通知するであろう。

加えて、フィルタ基準パラメータは、具体的には以下の表６にリストアップされるようなマルチホップ発見のための２つの新しい条件を有する。

ＲＥＴＲＩＥＶＥ応答のための新しいパラメータがある。これらは、以下を含む。
ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔＲｅａｃｈｅｄ： ｍａｔｃｈｉｎｇＲｅｓｏｕｒｃｅＬｉｍｉｔが達成されているかどうかを表す随意のフラグ。
ｈｏｐＬｉｍｉｔＲｅａｃｈｅｄ： 最大数のサービス層ホップが発見要求によってトラバースされているかどうかを表す随意のフラグ。
ＣｏｎｄｉｔｉｏｎａｌＤｉｓｃｏｖｅｒｙＳｔａｔｕｓ： ＣｏｎｄｉｔｉｏｎｅｄＯｎリソースにおける条件チェックが満たされたかどうかを表す随意のフラグ。
ｄｉｓｃｏｖｅｒｙＲｅｄｉｒｅｃｔ： 通過ＣＳＥが関連付けられる発見要求を新しいホスティングＣＳＥにリダイレクトしたかどうかを表す随意のフラグ。

図１６は、現在のｏｎｅＭ２Ｍ機能アーキテクチャに基づいて強化発見ＣＳＦを形成するために、提案される発想を既存の発見ＣＳＦに実装するための例示的実施形態を示す。強化発見ＣＳＦは、ＡＳＮ−ＣＳＥ、ＭＮ−ＣＳＥ、およびＩＮ−ＣＳＥの中で見出されることができる。この新しい強化発見（ｅＤＩＳ）ＣＳＦは、リソースを発見するために、発見要求の中の情報（発信側が供給した発見タイプ、フィルタ基準、宛先／標的ノード）を使用する。

要求を受信すると、ｅＤＩＳ ＣＳＦは、供給された発見タイプを使用して要求を処理する方法を決定する。発見タイプがマルチホップ発見である場合、ｅＤＩＳ ＣＳＦは、要求されたマルチホップ発見サブタイプに基づいてアクションをとり、すなわち、一致するリソースを発見し、より多くの一致するリソースが要求される場合、要求を他のＭＮ−ＣＳＥまたはＩＮ−ＣＳＥに転送する。発見タイプが条件付き発見であり、このｅＤＩＳ ＣＳＦをホストするノードが条件の標的である場合、ｅＤＩＳ ＣＳＦは、条件を評価し、条件が満たされる場合にのみ、要求を他のＭＮ−ＣＳＥまたはＩＮ−ＣＳＥに転送し得る。発見タイプがホスティングＣＳＥリダイレクトである場合、ｅＤＩＳ ＣＳＦは、最初に、フィルタ基準に一致するホスティングリソースである任意の他のＣＳＥを把握しているかどうかを決定し、該当する場合、要求をこれらの他のＣＳＥにリダイレクトし得る。

図１７は、提案される発想が、（ｉ）発信側として挙動するノード上で、および（ｉｉ）サービス層ソフトウェアモジュールを起動する中間ノード上で、どのようにしてＧＵＩインターフェースを介して表示されることができるかを図示する。サービス層参照点を越える提案されるメッセージがあるので、メッセージは、ノード間でスニファツールを使用して検出されることができる。ＧＵＩインターフェースは、構成をサービス層ソフトウェアに提供するために使用されることができ、例えば、本願で提案されるパラメータ／リソースのうちのいくつかを設定する。ＧＵＩインターフェースはさらに、動作中にパラメータ／リソースの変更を表示するために使用されることもできる。一実施形態において、ディスプレイ上のＧＵＩは、ある検索パラメータに一致する返された結果を含み得る。検索パラメータは、リソースタイプ、リソース作成時間、リソースサイズ等に基づき得る。例えば、フィルタ基準に一致する「ｋ」個のリソースが、ＧＵＩ上に表示され得る。加えて、サービス層ホップの数が表示される。例示的実施形態によると、ＧＵＩは、「ＰａｒｋｉｎｇＦｉｎｄｅｒ」アプリケーションとして表示され得る。アプリケーションは、それによって、ユーザが検索パラメータ等の情報を入力し得るユーザインターフェースを含み得る。そうすることによって、ＧＵＩは、利用可能なフリースポットの数を示す結果を出力する。

発信側内のＧＵＩは、ユーザが発見要求を生成し、中間ノードに送信し、続いて、種々の発見タイプ（マルチホップ発見、条件付き発見、ホスティングＣＳＥリダイレクト）の下で発見応答を表示することを可能にすることができる。中間ノード内のＧＵＩは、種々の発見タイプ（マルチホップ発見、条件付き発見、ホスティングＣＳＥリダイレクト）のための条件を作成するようにサービス層を構成するために使用されることができる。例えば、ユーザは、ＦＡＬＳＥに評価するであろう条件付き発見を伴う発見要求を生成するために、発信側内のＧＵＩを使用し得る。ＧＵＩは、発見応答を表示し得る。

プロセッサ３２は、本明細書に説明される例のうちのいくつかにおける学習管理システムが成功であるか、不成功であるか（例えば、サービス要求、コンテキスト読み出し、またはコンテキスト通知等）に応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するか、または、別様にサービス要素および関連付けられるコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、もしくは色は、本明細書に図示または議論される表もしくは図（例えば、図４および７−１５）の中の方法フローまたはコンポーネントのうちのいずれかのステータスを反映し得る。ここでは、サービス要素のメッセージおよびプロシージャが議論される。メッセージおよびプロシージャは、ユーザが、入力ソース（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介してリソース関連リソースを要求し、とりわけ、ディスプレイ４２上に表示され得るサービス要素関連情報を要求すること、構成すること、またはクエリすることを行うためのインターフェース／ＡＰＩを提供するために、拡張されることができる。

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

本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図４および７−１５による複数のコールフローにおいて上記で開示されるような１つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、メモリの中に記憶され、図５Ｃおよび５Ｄにおいて上記で開示されるプロセッサによって実行され、ＵＥ、ＨＳＳ、ならびにＳＣＳを含むデバイスで採用され得る。一実施形態において、図５Ｃおよび５Ｄにおいて上で説明されるような、非一過性メモリと、それに動作可能に結合されるプロセッサとを有する、コンピュータ実装ＵＥが、開示される。具体的には、発信側の非一過性メモリは、その中に位置するリソースのためのＣＳＥの発見を行うためのその上に記憶された命令を有する。プロセッサは、（ｉ）発見タイプを含む発見要求メッセージ（ＤＲＭ）を生成すること、（ｉｉ）ＤＲＭをＣＳＥに送信すること、（ｉｉｉ）ＣＳＥから発見応答を受信することを行う命令を実施するように構成される。

別の実施形態によると、通過ＣＳＥの非一過性メモリは、リソースのための発見要求を処理するためのその上に記憶された命令を有する。プロセッサは、（ｉ）プロセッサから発見要求を受信する命令を実施するように構成される。要求は、発見タイプおよびフィルタ基準を含み得、（ｉｉ）任意のリソースがメッセージの中のフィルタ基準に一致するかどうかをチェックし、（ｉｉｉ）発見応答メッセージを準備する。例示的実施形態において、プロセッサは、フィルタ基準に基づいて、いくつの結果を返すべきかを決定する。

（実際の例）
上記の用途は、実際の状況で有用であり得る。これは、例えば、複数の階／フロアがある駐車ビルの中の利用可能な駐車場所を見つけることを含み得る。図１８Ａは、利用可能な駐車場所のグラフィカルユーザインターフェースを図示する。すなわち、各フロアが、１つのゲートウェイ１８０１を有し得、ビル内の各駐車場所が、各場所のステータス（空き／使用中）に関する指示を提供するために、その最近傍のゲートウェイと通信するセンサ１８０４を具備する。これはさらに、駐車場所の詳細（例えば、場所がミニバンのために十分に大きいかどうか、車椅子用の駐車場所であるかどうか、エレベータに近いかどうか、および駐車場所からのビデオフィード）を含み得る。各駐車場所の利用可能性はさらに、この建造物ならびにこのサービスプロバイダによって管理される他の建造物の全ての駐車場所のアナウンスメントを有する、「ＰａｒｋｉｎｇＦｉｎｄｅｒ」サービスプロバイダ１８０２と共有される。

この例では、車が駐車ビルに入り、運転者が任意の利用可能な駐車場所を探している。カーナビゲーションシステムは、駐車ビルのＷｉ−Ｆｉネットワークに自動的に接続する、「ＰａｒｋｉｎｇＦｉｎｄｅｒ」アプリケーション１８０３を具備する。「ＰａｒｋｉｎｇＦｉｎｄｅｒ」アプリケーションは、アナウンスされた空いた場所のうちの１つを選択し、サービスプロバイダから詳細を読み出し得る。代替として、「ＰａｒｋｉｎｇＦｉｎｄｅｒ」アプリケーションは、フロア／階ゲートウェイから空いた場所についての詳細（例えば、場所がミニバンのために十分に大きいかどうか、車椅子のアクセスのために確保されているかどうか、エレベータに近いかどうか、本場所のビデオフィード等）を読み出すように「ＰａｒｋｉｎｇＦｉｎｄｅｒ」サービスプロバイダに求め得る。別個に、警察車両が、駐車ビルに入り、誰かが確保された場所、例えば、車椅子専用の場所に違法に駐車しているかどうかをチェックし得る。

別の例は、図１８Ｂのグラフィカルユーザインターフェースに示される、小さいオフィス内のセキュリティに関する。オフィスの入口は、そのフィードをビデオゲートウェイ１８０５およびＭＮ−ＣＳＥセンサゲートウェイ１８０４に周期的に報告するビデオカメラを用いて、監視される。ゲートウェイは、各２４期間にわたって全てのビデオフィードを記憶し、録画が効率的に読み出されることができるように、それらのタイムスタンプを記録する。ＩＴ部門が問題（例えば、未知のユーザがローカルマシンにログオンしようとした）を報告するとき、オフィス管理者は、これが不法侵入のためであるか、または何らかの他の原因に起因したかどうかを決定するために、トラブルシューティングする必要がある。結果として、管理者は、正面のドアが開かれている場合のみであるが、最新の受付デスクビデオフィードに関する情報を閲覧することを望む。オフィス管理者アプリケーションは、オフィス管理者によってトリガされる場合に（例えば、トラブルシューティングされる必要がある、報告された問題）、ビデオフィードの情報を中継する。

図１８ＡおよびＢは、本明細書で議論される方法ならびにシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース（例えば、タッチスクリーンディスプレイ）は、表２−６のパラメータ等のサービス要素ホスト選択に関連付けられるテキストを提供し得る。別の例では、本明細書で議論されるステップのうちのいずれかの進行が表示され得る。加えて、グラフィカル出力が、ディスプレイインターフェース上に表示され得る。

システムおよび方法は、現在、具体的側面と考えられているものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正ならびに類似配列を網羅することが意図され、その範囲は、全てのそのような修正および類似構造を包含するよう、最も広義の解釈を与えられるべきである。本開示は、以下の請求項のありとあらゆる側面を含む。

Claims (19)

1. ネットワーク上の装置であって、前記装置は、
   前記ネットワーク上のリソースに対する発見要求メッセージを処理するための命令を記憶している非一過性メモリと、
   前記非一過性メモリに動作可能に結合されているプロセッサと
   を備え、
   前記プロセッサは、
   発信側からフィルタ基準を含む前記発見要求メッセージを受信することであって、前記フィルタ基準はマッチングリソース限界「ｋ」を有することと、
   「Ｌ」のリソースが前記発見要求メッセージにおける前記フィルタ基準を満たすことを確認することであって、前記「Ｌ」の値は前記「ｋ」の値よりも小さいことと、
   前記フィルタ基準を満たす「Ｌ」のリソースを含む第１の発見応答を準備することと、
   前記発見要求メッセージをアップデートしたうえ共通サービスエンティティに転送することであって、前記アップデートは「ｋ」−「Ｌ」の前記フィルタ基準を満たさないリソースに関するアップデートであることと、
   前記共通サービスエンティティから第２の発見応答を受信することと、
   前記第２の発見応答を前記第１の発見応答に追加して第３の発見応答を生成することと、
   前記第３の発見応答を前記発信側に送信することと
   を行う前記命令を実施するように構成されている、装置。
2. 前記プロセッサは、前記発見要求メッセージの前記フィルタ基準および発見タイプに基づいて、いくつの結果を返すべきかを決定する前記命令を実施するようにさらに構成され、前記決定する命令は、一致するリソース限界「ｋ」より小さい一致するリソースの数「Ｌ」に基づく、請求項１に記載の装置。
3. 前記決定する命令は、
   前記フィルタ基準に一致する他の共通サービスエンティティをチェックすることと、
   前記チェックする命令に基づいて、前記リソースの同期を行うホスティング共通サービスエンティティを更新することと
   を含む、請求項２に記載の装置。
4. 前記プロセッサは、
   前記第２の発見応答からの結果に基づいて前記第１の発見応答を更新することと
   を行う命令を実施するようにさらに構成されている、請求項１に記載の装置。
5. 前記発見要求メッセージは、ルート発見、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される発見タイプを含む、請求項１に記載の装置。
6. 前記発見タイプは、条件付き持続性または代替共通サービスエンティティリダイレクトを有する、請求項５に記載の装置。
7. 前記発見要求メッセージは、最大ｋ個のリソース発見を見出すこと、最大Ｎ個のホップリソース発見を見出すこと、全てのリソース発見を見出すこと、一致するリソース限界、およびホップ限界のうちの少なくとも１つを含む、請求項１に記載の装置。
8. ネットワーク上の共通サービスエンティティの発見を実施する方法であって、前記方法は、
   発信側から発見タイプおよびフィルタ基準を含む発見要求メッセージを受信することであって、前記フィルタ基準はマッチングリソース限界「ｋ」を有することと、
   「Ｌ」のリソースが前記発見要求メッセージにおける前記フィルタ基準を満たすことを確認することであって、前記「Ｌ」の値は前記「ｋ」の値よりも小さいことと、
   前記フィルタ基準を満たす「Ｌ」のリソースを含む第１の発見応答を準備することと、
   前記フィルタ基準および前記発見タイプに基づいて、前記第１の発見応答においていくつの結果を返すべきかを決定することと、
   前記発見要求メッセージをアップデートしたうえ共通サービスエンティティに転送することであって、前記アップデートは「ｋ」−「Ｌ」の前記フィルタ基準を満たさないリソースに関するアップデートであることと、
   前記共通サービスエンティティから第２の発見応答を受信することと、
   前記第２の発見応答を前記第１の発見応答に追加して第３の発見応答を生成することと、
   前記第３の発見応答を前記発信側に送信することと
   を含む、方法。
9. 前記決定するステップは、一致するリソース限界「ｋ」より小さい一致するリソースの数「Ｌ」に基づく、請求項８に記載の方法。
10. 前記決定するステップは、
    前記フィルタ基準に一致する他の共通サービスエンティティをチェックすることと、
    前記チェックするステップに基づいて、前記リソースの同期を行うホスティング共通サービスエンティティを更新することと
    を含む、請求項８に記載の方法。
11. 前記第２の発見応答からの結果に基づいて前記第１の発見応答を更新することと
    をさらに含む、請求項８に記載の方法。
12. ネットワーク上の装置であって、前記装置は、
    前記ネットワーク上のリソースの発見を実施するための命令を記憶している非一過性メモリと、
    前記非一過性メモリに動作可能に結合されているプロセッサと
    を備え、
    前記プロセッサは、
    発見タイプを含む発見要求メッセージを生成することと、
    前記発見要求メッセージを前記ネットワーク上の共通サービスエンティティに送信することと、
    前記共通サービスエンティティから発見応答を受信することと、
    を行う前記命令を実行するように構成されており、
    前記発見タイプは、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される、装置。
13. 前記マルチホップ発見は、ルート発見、最大ｋ個のリソース発見を見出すこと、最大Ｎ個のホップリソース発見を見出すこと、全てのリソース発見を見出すこと、一致するリソース限界、およびホップ限界のうちの少なくとも１つを含む、請求項１２に記載の装置。
14. 前記発見要求メッセージは、要求を実施する共通サービスエンティティのタイプ、ある階層の前記共通サービスエンティティ、有意な処理を伴う共通サービスエンティティ、リスト内の共通サービスエンティティ、およびそれらの組み合わせから成る群から選択されるフィルタを含む、請求項１２に記載の装置。
15. 前記発見応答は、ホップ限界に達していること、一致するリソース限界に達していること、およびそれらの組み合わせから成る群から選択される、請求項１２に記載の装置。
16. ネットワーク上の共通サービスエンティティの発見を実施する方法であって、前記方法は、
    発見タイプを含む発見要求メッセージを生成することと、
    前記発見要求メッセージを前記ネットワーク上の前記共通サービスエンティティに送信することと、
    前記共通サービスエンティティから発見応答を受信することと
    を含み、
    前記発見タイプは、マルチホップ発見、条件付き発見、ホスティング共通サービスエンティティリダイレクト、およびそれらの組み合わせから成る群から選択される、方法。
17. 前記発見要求メッセージは、要求を実施する共通サービスエンティティのタイプ、ある階層の共通サービスエンティティ、有意な処理を伴う共通サービスエンティティ、リスト内の共通サービスエンティティ、およびそれらの組み合わせから成る群から選択されるフィルタを含む、請求項１６に記載の方法。
18. 前記発見応答は、少なくとも２つの共通サービスエンティティから受信され、
    前記少なくとも２つの共通サービスエンティティから受信される重複発見応答は、削除される、
    請求項１６に記載の方法。
19. 前記発見応答は、ホップ限界に達していること、および一致するリソース限界に達していることについての情報を含む、請求項１８に記載の方法。