JP2018520598A - モノのインターネットのための広域サービス発見 - Google Patents

Abstract

クラウドベースのＤＮＳ−ＳＤアーキテクチャは、別個のＬＡＮを一緒にリンクし、サービス発見観点から、とりわけ、通常のインターネットＤＮＳと別個のクラウドベースのＤＮＳ−ＳＤサーバと、スリープノードハンドリングとを含む仮想発見ゾーンを形成し得る。例では、クラウドベースのＤＮＳ−ＳＤサーバは、通常のインターネットＤＮＳサーバと別個である。このクラウドＤＮＳ−ＳＤサーバは、仮想発見ゾーン内のサービス発見専用のサービスとしてのプライベートインフラストラクチャ（ＩａａＳ）として起動し得る。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１８８，７８１号（２０１５年７月６日出願、名称「Ｗｉｄｅ Ａｒｅａ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｏｆ Ｔｈｉｎｇｓ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

（ドメイン名システム）
ドメイン名システム（ＤＮＳ）は、インターネットに接続されるデバイス（ホストとも呼ばれる）についての情報の分散型データベースである。具体的には、ＤＮＳは、人間読み取り可能な名（ニーモニックデバイスとして使用される）とＩＰアドレス（インターネットルーティングにおいて使用される）との間でマップするための情報を含む。
・ 例１：ウェブサイト名「ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ」は、ＩＰアドレス「７４．１２５．２２４．７２」にマップする。
・ 例２：電子メールアドレス「ｊｏｈｎ．ｓｍｉｔｈ＠ＢｅｓｔＣｏｍｐａｎｙ．ｃｏｍ」は、ＩＰアドレス「２０８．４９．７９．２４２」にマップする。

この情報は、ＤＮＳリソース記録（ＲＲ）と称される、ＤＮＳデータベースエントリ内に記憶される。ＤＮＳサーバは、ＤＮＳ記録内に記憶されるインターネット接続デバイス（ホスト）についての情報を与えることによって、クライアントクエリに応答する。最も一般的クエリは、名前をＩＰアドレスに変換することである。この機能は、ＤＮＳ名前解決と称される。技術的に、解決される名前は、ＦＱＤＮと称される。本明細書で議論されるであろう、他のタイプの可能なＤＮＳクエリも存在する。

ＤＮＳのための半手動スキームは、最初は、機能していたが、インターネットに接続されるホストの数が指数関数的に成長し始めると、良好に対応しなくなった。調査が、したがって、より自動的かつスケーラブルなソリューションを決定するために行われ、ＤＮＳを定義する重要となる一連のＩＥＴＦ規格をもたらした。ＲＦＣ１０３４およびＲＦＣ１０３５（参照することによってその全体として組み込まれる）を参照されたい。

ＤＮＳは、今日、世界中に位置する多くのコンピュータサーバにわたって拡散される分散型データベースである。データベースは、ドメイン名の概念について編成される（例えば、「．ｃｏｍ」は、ドメイン名の一部であり、「ｗｗｗ．ＢｅｓｔＣｏｍｐａｎｙ．ｃｏｍ」は、ＦＱＤＮである）。各ドメイン名は、本質的に、ドメイン名空間と呼ばれる大きな反転ツリー内のパスである（図１参照）。ドメインは、空間全体のサブツリーである。ツリー構造は、上位に単一（論理）ルートを有する。ツリーの深度は、１２７レベルに限定される。ツリー内の各ノードは、最大６３文字の長さであり得るテキストラベル名を有する。ドメイン名は、常時、リーフノードからルートに向かって読み取られ、ドットが、パス内の名前を分離する。したがって、例えば、ＦＱＤＮ「ｗｗｗ．ＢｅｓｔＣｏｍｐａｎｙ．ｃｏｍ」に対して、「．ｃｏｍ」は、ツリーの上位にあり、上位レベルドメイン（ＴＬＤ）と称される。次いで、「．ＢｅｓｔＣｏｍｐａｎｙ」は、ツリーの次の下層にあり、「ｗｗｗ」は、ツリーの下位リーフであろう。

前述のように、ＤＮＳデータベースエントリは、ＲＲと呼ばれるフォーマットで記憶される。ＲＲは、ドメインまたは特定のドメイン名（ＦＱＤＮ）によって編成される。ＦＱＤＮＳは、最終的に、物理的ネットワークデバイスに関連付けられる一方、ドメイン（例えば、「．ｃｏｍ」）は、デバイスのグループを識別するために使用される。それらが含む、デバイスに関連する情報のタイプによって分類される種々のタイプのＲＲが存在する。いくつかの例示的ＤＮＳ ＲＲが、表１に列挙される。

ＤＮＳクエリおよび応答は、典型的には、直接、ポート５３上のＵＤＰパケットを経由して、送信される。ＴＣＰトランスポートオプションも、存在するが、典型的には、非常に短いトランザクションであるＤＮＳクエリ／応答のための推奨されるオプションではない。ＤＮＳは、図２に示されるように、３つのコンポーネントを用いて、単一メッセージフォーマットを定義する。

３つのコンポーネントは、ヘッダ部分１０５と、質問部分１０７と、回答部分１０９とである。ヘッダ部分１０５に関して、固定された１２バイトヘッダが、メッセージのタイプおよび可変部分のサイズを記述するフィールドとともに存在する。質問部分１０７は、ＤＮＳ名サーバに送信される情報のための１つ以上のクエリを含む。回答部分１０９は、回答１１１、権限１１２、および追加情報１１３等の質問部分１０７内のクエリ／質問への回答として、３つのサブコンポーネント内に１つ以上のＲＲを含む。回答１１１は、質問に直接回答する、ＲＲである。権限１１２は、解決プロセスを継続するために使用され得る正式ＤＮＳ名サーバを指し示すＲＲである。追加情報１１３は、元の質問に厳密に回答する必要はない、クエリに関連する追加情報を含むＲＲである。

図３は、ユーザがウェブブラウジングを行うことによって開始されるＤＮＳルックアップのための典型的メッセージシーケンス略図を図示する。ステップ１２１では、ラップトップ１３０におけるユーザが、最新のＧｏｏｇｌｅビジネスニュースを読むことを欲する。この情報は、ラップトップ１３０のブラウザ１３１に関連付けられたユーザインターフェースを通して入力される。ブラウザ１３１は、次いで、「ｇｏｏｇｌｅ．ｃｏｍ」のＩＰアドレスを入手することが必要であることを認識する。したがって、ブラウザ１３１は、この要求を用いて、ラップトップ１３０内のＤＮＳクライアント１３２にコンタクトする。ステップ１２２では、ＤＮＳクライアント１３１が要求を入手すると、ＦＱＤＮ＝「ｇｏｏｇｌｅ．ｃｏｍ」を伴うＤＮＳメッセージクエリを形成する。このクエリは、インターネット１２０を経由して、デフォルトＤＮＳサーバ１３３に送信される。ＤＮＳサーバ１３３のＩＰアドレスは、ＤＮＳクライアント１３２内ですでに利用可能であり得る。ＤＮＳサーバ１３３のＩＰアドレスは、ラップトップ内で事前にプロビジョニングされていることも、ラップトップブートアッププロセスにおいてＤＨＣＰ等のプロトコルによって読み出されていることもある。

ステップ１２３では、ＤＮＳサーバ１３３は、ステップ１２２の受信されたクエリに基づいて内部ルックアップを行い、「．ｃｏｍ」ドメインのサーバがＤＮＳサーバ１３４であることを決定する。したがって、ＤＮＳメッセージ（ＲＲを含む）が、ＤＮＳクライアント１３２に返信され、同一クエリを用いて反復的検索を行い、ＤＮＳサーバ１３４にコンタクトすべきであることを知らせる。ステップ１２４では、ＤＮＳクライアントは、ステップ１２２の類似情報を伴うＤＮＳメッセージをＤＮＳサーバ１３４に送信する。この例では、ＤＮＳサーバ１３４は、正式ドメインサーバであり、したがって、さらなる反復は、必要ない。ステップ１２５では、ＤＮＳサーバ１２５は、「Ａ」ＲＲを含むステップ１２４への応答を伴うＤＮＳメッセージを送信し、「Ａ」ＲＲは、要求される「ｇｏｏｇｌｅ．ｃｏｍ」サーバのＩＰアドレス（７４．１２５．２２４．７２）を含むであろう。ステップ１２６では、ＤＮＳクライアント１３２は、ＤＮＳメッセージからの「ｇｏｏｇｌｅ．ｃｏｍ」ＩＰアドレスをブラウザ１３１に送信する。ステップ１２７では、ブラウザ１３１は、最新のビジネスニュースであり得るそれが欲するコンテンツを読み出すために、ＨＴＴＰ入手要求を直接「ｇｏｏｇｌｅ．ｃｏｍ」ＩＰアドレス（７４．１２５．２２４．７２）に送信する。ステップ１２８では、「ｇｏｏｇｌｅ．ｃｏｍ」サーバは、適切な最新のビジネスニュースコンテンツを伴うＨＴＴＰ応答で応答する。

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

ＩＥＴＦでは、ＩＰ「サービス」は、サービス名（例えば、ＦＴＰ、ＨＴＴＰ）と、トランスポートプロトコル（例えば、ＵＤＰ、ＴＣＰ）と、トランスポートプロトコルのポート番号とを含む３つの情報の組み合わせによって認識される。公知のインターネットＩＰサービスの広範なレジストリは、ＩＥＴＦによってサービス名およびトランスポートプロトコルポート番号レジストリ内に維持される。ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ａｓｓｉｇｎｍｅｎｔｓ／ｓｅｒｖｉｃｅ−ｎａｍｅｓ−ｐｏｒｔ−ｎｕｍｂｅｒｓ／ｓｅｒｖｉｃｅ−ｎａｍｅｓ−ｐｏｒｔ−ｎｕｍｂｅｒｓ．ｘｈｔｍｌ（参照することによってその全体として組み込まれる）を参照されたい。

技術的に、ＤＮＳ−ＳＤは、２つの機能から成る。第１の機能は、マルチキャストＤＮＳ（ｍＤＮＳ）と称される。ｍＤＮＳは、ローカルＩＰマルチキャスト機能性を利用することによって、任意の従来のユニキャストＤＮＳサーバなしにローカルネットワークＤＮＳ動作を行う能力を提供する。したがって、デバイスは、専用ＤＮＳサーバにクエリに応答することを要求する代わりに、直接、ローカルＩＰマルチキャストＤＮＳクエリ自体に回答することができる（例えば、プリンタは、直接、印刷サービスを探しているマルチキャストＤＮＳクエリに回答するであろう）。ｍＤＮＳは、リンクローカルマルチキャストを使用して、デバイスがそれらのサポート／変更されるサービスを積極的に宣伝することも可能にする。加えて、ｍＤＮＳは、任意の年会費を支払う必要なく、かつ、権限委譲を設定する必要なく、または別様に従来のＤＮＳサーバがそれらの名前に対して回答するように構成する必要なく、ＤＮＳ名前空間の一部がローカル使用自由であること（例えば、新しい「．ｌｏｃａｌ」ドメイン）を指定する。ＲＦＣ６７６２（参照することによってその全体として組み込まれる）を参照されたい。

第２の機能は、それ自体が（やや紛らわしいが）ＤＮＳ−ＳＤと呼ばれる。それは、ＲＦＣ６７６３（参照することによってその全体として組み込まれる）に説明されており、サービス発見クエリをサポートするために、ＤＮＳ記録構造内で要求される変更（例えば、古典的名前解決クエリよりサポートするようにＤＮＳを構成すること）を規定する。それは、所与のドメインの特定のサービスに対してクエリするために、純粋なユニキャストモードでも使用されることができる。しかしながら、このユニキャストモードは、今日では、一般的サービス発見機能として使用されていない。

ＤＮＳ−ＳＤおよびｍＤＮＳの組み合わせは、ネットワーク内の動的マルチキャストサービス発見のコンテキストで使用されるとき、典型的には、単に「ＤＮＳ−ＳＤ」と称される。サービスの発見は、必要に応じて、クライアントがマルチキャストクエリを直接送信し、要求されるＩＰベースのサービスをサポートするデバイスから（ユニキャスト）応答を直接受信することによって行われる。このサービス発見は、ローカルネットワークのために機能する（例えば、複数のＬＡＮを横断してサービスを動的に発見することができない）。

図４は、典型的ＤＮＳ−ＳＤメッセージフローを図示する。ステップ１４１では、ユーザが、カラー文書をワードプロセッサ１３６から印刷することを欲する。ワードプロセッサ１３６は、カラープリンタ（例えば、カラープリンタ１３９）のＩＰアドレスを入手する必要があることを認識する。したがって、ワードプロセッサ１３６は、この要求を伴うメッセージをラップトップ１３０内のＤＮＳクライアント１３２に送信する。ステップ１４２では、ＤＮＳクライアント１３２が要求を入手すると、「カラープリンタ」を探していることを示すＤＮＳ−ＳＤ（マルチキャスト）メッセージクエリを形成すべきであることを決定する。このクエリは、ＩＰマルチキャストによって、ラップトップ１３０が接続されるＬＡＮ１４０を経由して送信される。ＩＰマルチキャスト機構は、ＤＮＳ−ＳＤクエリをＬＡＮ１４０に接続される全デバイスに自動的に配布するであろう（メッセージは、ＬＡＮ１４０の範囲を超えないであろう）。標準的ＤＮＳクエリ（ＵＤＰポート５３を経由して送信される）と異なり、マルチキャストＤＮＳ−ＳＤクエリは、ＵＤＰポート５３５３を経由して送信される。さらに、マルチキャストＤＮＳ−ＳＤドメインは、「ＣｏｌｏｒＰｒｉｎｔｅｒ．ｌｏｃａｌ」等の「．ｌｏｃａｌ」添字で終了する、ＦＱＤＮを有することとして規定される。

ステップ１４３では、ＬＡＮ１４０内の複数のデバイスが、ＤＮＳ−ＳＤマルチキャストクエリを受信するが、ここでは、カラープリンタ１３９のみが、一致するサービスタイプを有する。カラープリンタ１３９は、要求されるサービスサーバのＩＰアドレス（例えば、１９２．１６８．０．１１）を含むＤＮＳ−ＳＤメッセージ（ユニキャスト）応答を送信する。ステップ１４４では、ラップトップ１３０のＤＮＳクライアント１３２は、カラープリンタ１３９のＩＰアドレスをワードプロセッサ１３６に送信する。ステップ１４５では、ワードプロセッサ１３６は、ＨＴＴＰ Ｐｏｓｔ要求を直接カラープリンタ１３９のＩＰアドレスに送信し、添付が印刷されることを要求する。ステップ１４６では、カラープリンタ１３９は、正常ＨＴＴＰ応答コード（２０１）で応答し、添付が正常に印刷されたことを示す。

前述のように、ＤＮＳ−ＳＤは、主に、ローカルネットワーク内のＩＰベースのサービスを発見するために使用される。ＤＮＳ−ＳＤは、通常、ポインタ記録（ＰＴＲ）と、サービスロケータ記録（ＳＲＶ）と、テキスト記録（ＴＸＴ）とを含む３つの標準的ＤＮＳ ＲＲの組み合わせを使用して、サービスを識別する。ＤＮＳ−ＳＤ検索は、クライアントが、所与のドメインに対して、ＰＴＲ記録内の特定のサービスタイプを探すことを検索パラメータにおいて規定するＤＮＳクエリを送信することを伴う。そして、ＤＮＳ−ＳＤサーバは、サービスインスタンスが到達し得る標的デバイス（ホスト）名およびポート（ＳＲＶ ＲＲ内）を与えるゼロ以上のＳＲＶ／ＴＸＴペアの組と、付属情報（ＴＸＴ ＲＲ内）とを返す。そして、標的デバイスのＩＰアドレスは、関連付けられた「Ａ」または「ＡＡＡＡ」記録から得られることができる。

（ハイブリッドＤＮＳ−ＳＤプロキシ）
最近の草案であるハイブリッドユニキャスト／マルチキャストＤＮＳベースのサービス発見は、ハイブリッドプロキシを利用して、ＩＰベースのサービスの選択的広域発見を可能にすることを提案している。ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｄｎｓｓｄ−ｈｙｂｒｉｄ−００（参照することによってその全体として組み込まれる）を参照されたい。具体的には、草案は、ｍＤＮＳを使用して、ローカルネットワーク内のＤＮＳ−ＳＤサービスを発見し、応答を集約し、異なるＬＡＮ内の要求側クライアントに回答するであろうプロキシを提案している。これは、ＤＮＳにおける命名システムに重要な変更を要求するであろう（非常に議論の余地のあり、未だＩＥＴＦにおいて合意されていない）。現在、ＤＮＳドメイン名は、前述のように、最終的には、所与のデバイスに関連付けられる。ハイブリッドユニキャスト／マルチキャストＤＮＳベースのサービス草案が承認される場合、それは、ＬＡＮ（例えば、ローカルリンク）が、所与のサービスを検索するためにそれはクエリされることができるように、個々のデバイスの代わりに、命名される（例えば、「４ｔｈＦｌｏｏｒ．Ｂｕｉｌｄｉｎｇ１．ｃｏｍｐａｎｙＸ．ｃｏｍ」）ことも可能にするであろう。

図５は、ハイブリッドＤＮＳ−ＳＤプロキシシナリオのための例示的フローを図示する。ステップ１５１では、クエリが、カラープリンタを検索するために、特定の「命名された」ＬＡＮ（例えば、３^ｒｄ ｆｌｏｏｒ ｏｆ Ｂｅｓｔ Ｃｏｍｐａｎｙ）に送信されることが要求される。ステップ１５２−１５４では、通常の（ユニキャスト）ＤＮＳクエリ機構が、クエリが所与のＬＡＮ１４０（例えば、３^ｒｄ ｆｌｏｏｒ ｏｆ Ｂｅｓｔ Ｃｏｍｐａｎｙ）のためのＤＮＳ−ＳＤプロキシ１５０に転送されることをもたらすであろう。ステップ１５５−１５６では、ＤＮＳ−ＳＤプロキシ１５０は、ｍＤＮＳ要求をトリガする。ＬＡＮ１４０内のデバイスは、ＤＮＳ−ＳＤマルチキャストクエリを受信するが、（カラープリンタの）一致するサービスタイプを有する、カラープリンタ１３９のみが、回答するであろう。カラープリンタ１３９は、要求されるサービスサーバのＩＰアドレスを含むＤＮＳ−ＳＤメッセージ（ユニキャスト）応答を送信する。ステップ１５７−１５８では、ＩＰアドレスを伴うＤＮＳ応答が、ワードプロセッサ１３６に中継される。ステップ１５９では、ワードプロセッサ１３６は、次いで、ＨＴＴＰ Ｐｏｓｔ要求を直接カラープリンタ１３９のＩＰアドレスに送信し、添付が印刷されることを要求する。

ＤＮＳ−ＳＤは、現在、ローカルネットワーク内のＩＰベースのサービス（例えば、プリンタ、ファッックス等）を発見および宣伝することができるが、ＬＡＮを横断して機能するシステムの必要性が存在する。

本明細書に開示されるのは、別個のＬＡＮを一緒にリンクし、サービス発見の観点から、とりわけ、通常のインターネットＤＮＳと別個のクラウドベースのＤＮＳ−ＳＤサーバと、スリープノードハンドリングとを含む、仮想発見ゾーンを形成する、クラウドベースのＤＮＳ−ＳＤアーキテクチャである。例では、クラウドベースのＤＮＳ−ＳＤサーバは、通常のインターネットＤＮＳサーバと別個である。このクラウドＤＮＳ−ＳＤサーバは、仮想発見ゾーン内のサービス発見専用のサービスとしてのプライベートインフラストラクチャ（ＩａａＳ）として起動し得る。

ＩｏＴデバイスおよびＩｏＴゲートウェイは、ＤＮＳ−ＳＤクエリおよび応答をハンドリングし（例えば、スリーピノードハンドリングのために）、また、他のタイプのＤＮＳクエリ（例えば、標準的ＤＮＳ名前解決クエリ）と区別する。プロシージャは、仮想発見ゾーンを定義および構成し、ノード（例えば、ＤＳＮ−ＳＤサーバ、ＩｏＴゲートウェイ）を制御する。例では、構成は、種々の制御ノードにおけるＯＡＭプロシージャを介して生じ得る。別の例では、構成は、制御ノード間の信号伝達に基づいて、動的ネットワーク自己構成アプローチを介して生じ得る。ユーザインターフェースは、仮想発見ゾーンを図式的に表示し得る。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のＬＡＮからサービスに対するＤＮＳ−ＳＤクエリを受信し、ＤＮＳ−ＳＤクエリの受信に応答して、サービス、すなわち、第２のＬＡＮ上のサービスについての情報を提供する手段を有する。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、要求をサービスに提供し、要求への応答を受信する手段を有し、応答は、サービスに関連付けられたデバイスについてのスリープノード情報を含む。

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

より詳細な理解は、付随の図面と併せて、一例として与えられる以下の説明から得られ得る。
図１は、例示的ＤＮＳデータベース構造を図示する。 図２は、３つのコンポーネントを伴う例示的単一メッセージＤＮＳフォーマットを図示する。 図３は、ユーザがウェブブラウジングを行うことによって開始されるＤＮＳルックアップのための例示的メッセージシーケンス略図を図示する。 図４は、例示的ＤＮＳ−ＳＤメッセージフローを図示する。 図５は、ハイブリッドＤＮＳ−ＳＤプロキシシナリオのための例示的フローを図示する。 図６は、例示的広域サービス発見システムを図示する。 図７は、仮想発見ゾーン内のプリンタの発見のための例示的フローを図示する。 図８は、システム始動のために使用され得る例示的方法を図示する。 図９は、システム動作のための例示的方法を図示する。 図１０は、仮想発見ゾーンを自己構成する例示的相を図示する。 図１１は、仮想発見ゾーンを自己構成する別の例示的相を図示する。 図１２は、スリープノードハンドリングを組み込み得る例示的広域サービス発見実装を図示する。 図１３は、ＤＮＳ ＲＲを使用するスリーピノードシナリオをハンドリングするための例示的フローを図示する。 図１４は、広域サービス発見に関連付けられた例示的ユーザインターフェースを図示する。 図１５Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１５Ｂは、図１５Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１５Ｃは、図１５Ａの通信システム内の側面が具現化され得る、例示的コンピュータシステムの系統図である。 図１５Ｄは、図１５Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャを図示する。

本明細書に開示されるのは、ＩｏＴシナリオのためにローカルネットワークを超えて機能するＤＮＳサービス発見（ＤＮＳ−ＳＤ）である。ＤＮＳ−ＳＤは、現在、ローカルネットワーク内のＩＰベースのサービス（例えば、プリンタ、ファックス等）を発見および宣伝することができるが、ＬＡＮを横断して機能しない。しかしながら、多くのＩｏＴシナリオでは、これは、不十分である。サービス名の例は、「温度センサ」または「ライトスイッチ」もしくは「ドアロック」であろう。他のサービスも、ＲＦＣ７２５２に記載されるようなトランスポートプロトコル（例えば、ＣｏＡＰを使用するＩｏＴサービスのためのＵＤＰ）およびポート番号（例えば、デフォルトＵＤＰ ＣｏＡＰポートは、５６８３である）に関して本明細書で議論される。

従来のＤＮＳ−ＳＤ技術のいくつかの制限または限定が、以下に議論される。従来のＤＮＳ−ＳＤは、ＤＮＳサーバに直接クエリし、サービスを検索する厳密なユニキャスト方法をサポートし（例えば、ｍＤＮＳは要求されない）、ＬＡＮを横断して機能することができる。しかしながら、このユニキャストアプローチは、複数の理由から、汎用サービス発見アプローチと考えられない。第１の理由は、所与のサービスを検索するクライアントが検索すべきドメインを決定し得る方法に関連付けられた問題に関わるものである。ユニキャストのために、検索すべきドメインを把握する必要がある。多くのまたは全てのドメインを検索する総当たりアプローチは、非常に多くの信号伝達と、より重要なこととして、サービスを見つけることにおいて潜在的に有意な遅延をもたらすであろう。「現在の」ドメインを検索する単純なアプローチは、サービスがそこに登録されていない場合、機会の逸失をもたらし得る。

第２の理由は、デバイスがそのサポートされるサービスについての情報でＤＮＳサーバを自動的に更新できる方法に関連付けられた問題に関わるものである。ＤＮＳ ＲＲの更新は、クライアントと、クライアントが更新するＤＮＳサーバとの間の非常に複雑なセキュリティアソシエーションを要求する。この強固なセキュリティアソシエーションは、例えば、それがセキュリティ証明書の手動構成を要求し得るので、多くの場合、プリンタ、ＩｏＴデバイス等の単純な既製デバイスでは可能ではない。多くの場合、ヒトオペレータがこの情報の全てをＤＮＳサーバに手動で入力することは、サービスおよびデバイスのスケールならびに予期される動的性質により、実践的であるとは考えられない。

従来のＤＮＳ−ＳＤは、サーバにクエリするためのｍＤＮＳ方法をサポートする。従来のＤＮＳ−ＳＤに関連付けられたｍＤＮＳは、ローカルリンク内のサービス発見のために良好に機能すると考えられ得るが、ローカルリンク外では機能しないように明示的に制約されている。この制約の理由は、ｍＤＮＳ機能がＩＥＴＦ（ＲＦＣ６７６３の第２２節参照）によってローカルリンクＩＰマルチキャストアドレスのためのみに配分されているからである。概して、サービス発見のためのＬＡＮを超えたマルチキャストは、多くのシナリオにおいて、有意なネットワーク輻輳を生じさせることが予期され、したがって、ＩＥＴＦによって明示的に禁止されている。本明細書に議論される場合、ローカルリンクは、典型的には、ＬＡＮまたはＬＡＮのサブセクションに匹敵する。リンクは、典型的には、Ｅｔｈｅｒｎｅｔ（登録商標）またはＷｉＦｉ等のそれに接続される複数のデバイスで共有される伝送媒体である。多くの場合、リンクは、単層２（ブロードキャスト）ドメインになる（但し、ブリッジのようなＬ２デバイスによって拡張され得る）。典型的には、ローカルリンクは、パケットを中継するために、層３ＩＰルータを要求しない。本書では、簡単のために、用語「ＬＡＮ」または「ローカルネットワーク」は、用語「ローカルリンク」と同義的に使用される。

ＩｏＴは、それらが標準化されたプロトコルを使用して全体的インターネットの中に完全に統合され得るほどの現在の主に独占的Ｍ２Ｍシステムの進化を説明するために作られた用語である。本明細書に開示されるのは、ＤＮＳ−ＳＤがＩｏＴシナリオのためにローカルネットワークを超えて機能するようにＤＮＳ−ＳＤを使用するアプローチ（広域サービス発見）である。ローカルネットワークを超えて発見を要求する、多くのＩｏＴシナリオでは、現在のＤＮＳ−ＳＤは、十分ではない。例えば、スマートグリッド（例えば、ネットワーク化された電気事業）オペレータが、ＩｏＴデバイスを都市を横断して展開する場合、オペレータは、その展開全体を横断して（例えば、複数のＬＡＮを横断して）サービスの共通発見を欲するであろうが、それは、今までのところ満たされることが可能ではないニーズである。

「Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｓｃａｌａｂｌｅ ＤＮＳ ＳＤ−Ｃｈａｒｔｅｒ ｆｏｒ ＷＧ」と題されたＩＥＴＦ文書は、この問題を明示的に規定しており、「ＤＮＳ−ＳＤ／ｍＤＮＳプロトコルスイートは、自宅、キャンパス、および企業ネットワークを含む、多くのシナリオにおいて使用される。しかしながら、ゼロ構成ｍＤＮＳプロトコルは、設計上、リンクローカルマルチキャスト範囲に制約され、したがって、遠隔リンク上のサービスを発見するために使用されることができない」と述べている。ｈｔｔｐ：／／ｄａｔａｔｒａｃｋｅｒ．ｉｅｔｆ．ｏｒｇ／ｗｇ／ｄｎｓｓｄ／ｃｈａｒｔｅｒ（参照することによってその全体として組み込まれる）を参照されたい。

前述の問題に対処することを試みるハイブリッドＤＮＳ−ＳＤプロキシは、必要に応じて（例えば、ＤＮＳ−ＳＤクエリ時）頻繁なｍＤＮＳマルチキャストトラフィックを開始することを含む短所を有する。頻繁なマルチキャストは、到達すべきより多くのデバイスまたはより多くのネットワークが存在し、それが、より高いオーバーヘッドトラフィックを生じさせるので、ＩｏＴ環境に良好に対応しない。ＩｏＴデバイスの多くは、多くの場合、スリープ中であることもあり、したがって、マルチキャストＤＮＳ−ＳＤクエリの多くを取りそこなうこともある。さらに、ハイブリッドＤＮＳ−ＳＤプロキシは、ＩｏＴ展開のために最適化されたＩｏＴ特定のアーキテクチャ（例えば、ＲＤ）およびＩｏＴ特定のプロトコル（例えば、ＣｏＡＰ）を活用せず、故に、これらのＩｏＴ特定のノードおよびプロトコルと比較して、より高いオーバーヘッドおよび非効率性を生じさせる。

したがって、従来のＤＮＳ−ＳＤサービス発見アプローチは、互いにある論理的関係（例えば、ある限界内の広域サービス発見）を有する複数のＬＡＮを横断してサービス発見（ＤＮＳ−ＳＤ）を可能にするより効率的機構をサポートするように有意に改変され得る。

本明細書で議論される広域サービス発見は、リソースディレクトリ（ＲＤ）を活用し得る。（ＲＤ）は、ＩｏＴ環境のために、他のサーバ上に保持されるリソースの記述（例えば、ＵＲＩ）をホストするサーバである。ＣｏＲＥリソースディレクトリｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｒｅｓｏｕｒｃｅ−ｄｉｒｅｃｔｏｒｙ−０２（以降、ＣｏＲＥリソースディレクトリ）（参照することによってその全体として組み込まれる）を参照されたい。リソースディレクトリは、集中ルックアップがそれらのリソースに対して行われることを可能にする。通常のＧｏｏｇｌｅタイプウェブ検索がＩｏＴ環境内で効率的に機能しないであろうことを仮定する。代わりに、ＲＤは、デバイスがそのリソースならびに関連メタデータを登録することを可能にするＲＥＳＴｆｕｌ ＣｏＡＰインターフェースをサポートする。デバイスのリソース間の関係も、記憶され得る。別個のＲＥＳＴｆｕｌインターフェースは、第三者クライアントが、ＲＤを検索し、その所与の検索基準を満たすリソースを見つける（発見する）ことを可能にする。第三者クライアントは、ＲＤによって検索結果が提供されると、リソース（ＵＲＩ）に直接進むことができる。

ＣｏＲＥリソースディレクトリは、両手段によるＣｏＡＰサービスの発見を可能にする、ＲＤフィールドと従来のＤＮＳ−ＳＤフィールドとの単純マッピングを定義する。具体的には、それは、特別なクライアントが、最初に、ＲＤからＣｏＡＰサービスの標準的ＲＤルックアップを行うことができることを提案する。そのクライアントは、次いで、応答を行い、従来のＤＮＳ−ＳＤ内に情報のユニキャスト登録を行うことができる。前述のように、これは、複雑なセキュリティアソシエーションをＤＮＳインフラストラクチャと確立することが可能なクライアントを要求する。したがって、クライアントは、単純ＩｏＴデバイスであることができないが、特別な目的管理構成クライアントである可能性が最も高いであろう。

図６は、例示的広域サービス発見システム１６０を図示する。ＬＡＮ１７０、ＬＡＮ１７５、およびＬＡＮ１８０は、それぞれ、ゲートウェイ１７１、ゲートウェイ１７６、およびゲートウェイ１８１を含む。ＬＡＮ１７０等の各ＬＡＮは、ゲートウェイ（例えば、ゲートウェイ１７１）とローカルで通信可能に接続されるＩｏＴデバイス（例えば、ＩｏＴデバイス１７２）と、インターネット１６２と通信可能に接続されるゲートウェイとを含み得る。広域サービス発見システム１６０におけるゲートウェイ１７１等のゲートウェイは、ＣｏＡＰ ＲＤまたは似た機能性をサポートし得る。インターネット１６２は、ＤＮＳサーバ１６１およびＩｏＴサービスクラウド１６６と通信可能に接続される。ＩｏＴサービスクラウド１６６は、他のサービスの中でもとりわけ、ビッグデータ分析１６３、記憶装置１６４、およびＩｏＴ ＤＮＳ−ＳＤサーバ１６５を含み得る。システム１６０の種々のＬＡＮ内のＩｏＴデバイスは、第三者ＩｏＴデバイスサービス発見サーバ（例えば、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５）によって管理される仮想発見プロセス内で協力し得る所有者またはオペレータ（例えば、事業体、公益事業等）を有し得る。標準的ＤＮＳ名前解決は、依然として、インターネット１６２の既存の（「通常」）ＤＮＳインフラストラクチャによって行われ得る。ＬＡＮ１７０およびＬＡＮ１８０は、同一仮想発見ゾーン１６７内にある。

本明細書により詳細に議論されるように、ＤＮＳ−ＳＤクエリは、２ステッププロセスで行われ得る。最初に、同一ＬＡＮ内でサービスをローカルで発見することが試みられる。これが成功しない場合、クエリは、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５にルーティングされることができる。このクラウドベースのＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、仮想発見ゾーン１６７内のＩｏＴデバイスに対するサービス発見クエリに応答することができる。

本明細書に議論されるように、広域サービス発見システム１６０は、ＬＡＮを超えて確立される仮想発見ゾーンを可能にする。この例では、ＬＡＮ１７０およびＬＡＮ１８０は、仮想発見ゾーン１６７の中に一緒にスティッチングされる２つの物理的に別個の（非連続的）ＬＡＮである。仮想発見ゾーン１６７では、サービス発見は、ゾーン全体内の全デバイスにわたって可能にされ得る。ゾーンは、恣意的サイズであり、要求に応じた数のＬＡＮを包含し得る。１つのみの仮想発見ゾーン１６７が、図６に示されるが、複数の仮想発見ゾーンが定義されることもできる（通常、そうなるであろう）。例えば、図示されないが、ＬＡＮ１７５およびＬＡＮ１８０は、別個の仮想発見ゾーン内にあり得る。

図６を継続して参照すると、サービスは、所与のＩｏＴ仮想発見ゾーン１６７外の発見のためにエクスポーズされない。仮想発見ゾーンは、重複および非重複の両方であり得る。したがって、２つの重複ゾーンの一部であるサービスが、それらのゾーンの各々において発見可能であり得る。別の例では、所与の仮想発見ゾーンは、複数の古典的ｍＤＮＳドメインを包含し得る。古典的ｍＤＮＳドメインは、単一サブネットまたはＬＡＮである。所与の仮想発見ゾーンは、典型的には、複数のＬＡＮを包含するであろう。

図７、図１０、図１１−図１３、および他の図に図示されるステップを行うエンティティは、図１５Ｃに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリに記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。すなわち、図７、図１０、図１１−図１３、および他の図に図示される方法は、図１５Ｃに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリに記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図７、図１０、図１１−図１３、および他の図に図示されるステップを行う。例では、Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴うが、図１０のデバイス１７２は、図１５ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１０のＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、図１５ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図７は、仮想発見ゾーン内のプリンタの発見のための例示的フローを図示する。ステップ１９１では、ＤＮＳ−ＳＤクエリが、ＩｏＴデバイス１８２からゲートウェイ１８１に送信される。ＩｏＴデバイス１８２は、自動車内に位置するコンピューティングデバイスであり得る。ステップ１９１のクエリは、ホームオフィスカラープリンタ（例えば、ＩｏＴデバイス１７２）を使用するための要求であり得る。ステップ１９２では、ゲートウェイ１８１は、ＬＡＮ１８０を検索するが、要求されるサービスを見つけられない。ステップ１９３では、ゲートウェイ１８１は、ステップ１９２の結果に基づいて、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５にクエリすべきであることを決定する。ゲートウェイ１８１は、ＣｏＡＰ ＲＤを含み得る。ステップ１９４では、ゲートウェイ１８１は、クエリをＩｏＴ ＤＮＳ−ＳＤサーバ１６５に送信する。クエリは、事実上、ステップ１９１のクエリを反映させ得る。ステップ１９４のこのクエリでは、それは、ＩｏＴデバイス１７２（例えば、ホームオフィスにおけるカラープリンタ）の場所を要求し得る。ステップ１９５では、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、ホームオフィスカラープリンタ（ＩｏＴデバイス１７２）がＩｏＴ ＤＮＳ−ＳＤサーバ１６５に登録されていることを決定し得る。ステップ１９６では、ゲートウェイ１８１は、ＩｏＴデバイス１７２のＩＰアドレスまたはＩｏＴデバイス１７２の利用可能性を示す情報を含み得る、ＤＮＳ−ＳＤ応答を受信する。ゲートウェイ１８１において受信されたＩＰアドレスは、公共の一意のＩＰアドレスであり得る。ゲートウェイ１８１は、ネットワークアドレス変換（ＮＡＴ）を介して、公共のＩＰアドレスをプライベートＩＰアドレスに変換し得る。後の要求（例えば、ステップ１９８）は、デバイス間のＩＰ通信を可能にするために、従来のＮＡＴ原理を使用するプライベートＩＰアドレスに対するものであり得る。他の従来のＩＰ通信シナリオも、想定される。ステップ１９７では、ゲートウェイ１８１は、ＩｏＴデバイス１８２に、ステップ１９６において受信されたＩＰアドレスを送信する。ステップ１９８では、ＩｏＴデバイス１８２は、要求される文書を印刷するためのＩｏＴデバイス１７２への要求データを送信する。ステップ１９８の要求は、添付を含む、ＣｏＡＰ ＰＯＳＴ要求であり得る。

図７のフローは、以下の使用例に関連し得る。車の運転者が、夕方、仕事後に自宅に向かっている。彼女は、帰宅後、重要な予算のスプレッドシートを精査する必要があることを思い出す。運転者は、次いで、車載コンピュータに、音声コマンドによって、ある文書を彼女の電子メールから彼女の「ホームオフィスカラープリンタ」に印刷するように命令する。車載コンピュータは、次いで、「ホームオフィスカラープリンタ」に対する標準的ＤＮＳ−ＳＤ発見クエリを送信する。このプリンタは、車が接続されるＬＡＮ内で発見されない。（図７の１９１参照）。クエリは、次いで、車がクラウドＤＮＳ−ＳＤサーバがその仮想発見ゾーンに接続される全ての他のデバイスを把握しているであろうことを把握しているので、車載ＩｏＴゲートウェイによって、セルラー接続を経由してＩｏＴクラウドＤＮＳ−ＳＤサーバに転送される。（図７のステップ１９４参照）。クラウドＤＮＳ−ＳＤサーバでは、ホームオフィスカラープリンタは、以前に登録されており、したがって、クラウドＤＮＳ−ＳＤサーバは、プリンタの要求される情報（ＩＰアドレスを含む）を送信することによって、クエリに正常に回答する。（図７のステップ１９６および１９７参照）。車載コンピュータは、次いで、即座に、要求を直接自宅のプリンタに送信し、スプレーシートを印刷する（図７のステップ１９８参照）。

図７の議論を継続して参照すると、ＩｏＴデバイス１７２（例えば、プリンタ）に対するプライベートアドレスを有する中間ソリューションが、サポートされ得る。そのような状況では、プリンタに対して発見されるであろうＩＰアドレスは、実際には、ホームゲートウェイ（ゲートウェイ１７１）に割り当てられ、クラウドサーバ（ＩｏＴ ＤＮＳ−ＳＤサーバ１６５）に登録されるであろう。ゲートウェイ１７１（または同様のデバイス）は、次いで、印刷要求を車から受信し（ステップ１９８において）、それをプリンタにローカルで割り当てられる内部（プライベート）ＩＰアドレスに変換するであろう。これは、ネットワークアドレス変換（ＮＡＴ）アプローチを利用する。例えば、ゲートウェイ１７１は、マッピングを認識し得る。他のデバイスは、ゲートウェイ１７１がサービスを提供していると考え得る。

図７の使用例は、特に、単純デバイスに対して、従来のＤＮＳ−ＳＤ技術を使用して効率的に遂行されないであろう。家庭用プリンタ等の単純デバイスは、とりわけ、費用、自宅所有者の複雑性、およびセキュリティリスクにより、公共のインターネットＤＮＳ記録に入力されることは稀である。ハイブリッドＤＮＳ−ＳＤプロキシアプローチも、車の運転者が「自宅のプリンタ」の代わりに「任意のプリンタ」を単に規定した場合、移動中の車からクエリすべきＤＮＳ−ＳＤプロキシが明白ではないであろうため、困難であろう。仮想発見ゾーンに対して、ドメインのゾーンは、ゾーン全体である。図９における説明に従って、現在のＬＡＮから開始するゾーン全体内での検索があることを意味する。

図８は、システム始動のために使用され得る、例示的方法２００を図示する。ステップ２０１では、ＤＮＳ−ＳＤサーバが、前述のように構成される。これは、仮想発見ゾーンの所有者またはオペレータによって開始され得る。仮想発見ゾーンは、ＩｏＴローカルネットワークに関連付けられ得る。例えば、組み合わせられた図６のＬＡＮ１７０およびＬＡＮ１８０は、仮想発見ゾーン（例えば、同一所有者またはオペレータ）であり得る。別の例では、ＬＡＮ１８０およびＬＡＮ１７０は、協力する所有者（またはオペレータ）のグループが互いに信頼し、ＩｏＴサービスの共有を欲するので、仮想発見ゾーンを形成し得る。協力のための理由は、事業関係のためであり得る。所有者は、例えば、自宅所有者、会社所有者、または公共事業であり得る。クラウドＤＮＳ−ＳＤサーバ自体は、Ａｍａｚｏｎ^ＴＭまたはＧｏｏｇｌｅ^ＴＭのようなクラウドサーバプロバイダ上で起動し得る。例では、クラウドＤＮＳ−ＳＤは、ＩｏＴ顧客を標的とするクラウドプロバイダのためのＩａａＳとしての供給であり得る。

ステップ２０２では、仮想発見ゾーンが、ＩｏＴネットワークのオペレータまたは所有者によって定義され得る。これは、クラウドＤＮＳ−ＳＤサーバとゲートウェイのグループとの間の関連付けを定義することによって遂行され得る。例えば、図６を参照すると、仮想発見ゾーン１（図示せず）＝｛ＩｏＴ ＤＮＳ−ＳＤサーバ１６５、ゲートウェイ１７１およびゲートウェイ１７６｝であり、仮想発見ゾーン２（例えば、仮想発見ゾーン１６７）＝｛ＩｏＴ ＤＮＳ−ＳＤサーバ１６５、ゲートウェイ１７１およびゲートウェイ１８１｝である。仮想ゾーンの定義は、ＩｏＴネットワークのために存在する従来のＯＡＭインターフェース（例えば、ＳＮＭＰ）を通して構成またはプログラムされ得る。要するに、ＯＡＭインターフェースを通して、ＤＮＳ−ＳＤサーバ１６５および関連ゲートウェイは、定義された仮想発見ゾーン関係を有する。各ノードは、そのそれぞれのオペレータによって、異なるオペレータ間の全体的協力関係のコンテキストにおいて構成され得る。ここで議論されるようなノードは、任意の所与のボックス（例えば、ゲートウェイ、デバイス、ＤＮＳサーバ等）を意味する。この構成プロセスの一部として、ゲートウェイ（例えば、ゲートウェイ１７１）は、クラウドＤＮＳ−ＳＤサーバ（例えば、ＤＮＳ−ＳＤサーバ１６５）ホスト名と、クラウドＤＮＳ−ＳＤサーバにアクセスまたは書き込むために必要とされる任意のセキュリティ証明書とを提供され得る。ＤＮＳ−ＳＤサーバ１６５は、クラウド内にあるので、単一の物理的ノード内に常駐する必要はないことに留意されたい。標準的クラウド機能性は、負荷バランシング目的のため等、要求に応じて、それを分散させ得る。これは、ゲートウェイ（例えば、ゲートウェイ１７１）およびＩｏＴデバイス（例えば、ＩｏＴデバイス１７２）に透過的に行われ得る。

ステップ２０３では、各ＬＡＮセグメント内のＣｏＡＰ ＲＤ（ゲートウェイの一部であり得る）が、事前設定される。ＬＡＮ内のデバイスは、そのＵＲＩをＲＤに登録する。ＲＦＣ６６９０（参照することによってその全体として組み込まれる）に議論されるようなリンクフォーマットメッセージを参照されたい。ＵＲＩおよび関連付けられた情報は、次いで、ＣｏＲＥ Ｒｅｓｏｕｒｃｅ Ｄｉｒｅｃｔｏｒｙの第９節に議論されるように、ＲＤによって、その関連付けられたＤＮＳ−ＳＤ ＲＲフォーマットの中にマップされることができる。ＲＤは、ＣｏＡＰおよびＨＴＴＰベースのサービスについての情報を記憶することができることに留意されたい。

ステップ２０４では、各ゲートウェイ（例えば、ゲートウェイ１７１）は、それがクラウドＤＮＳ−ＳＤサーバ（例えば、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５）にエクスポートすることを欲するＤＮＳ−ＳＤ記録を決定するであろう。前文は、ＣｏＡＰ ＲＤ記録が安定すると（例えば、閾値期間にわたって新しいＲＤ更新がなくなると）生じ得る。ゲートウェイ１７１のＲＤが、少ない（例えば、比較的に少量の記録を含む）場合、ゲートウェイ１７１のＲＤは、簡単のために、全てのその記録をＩｏＴ ＤＮＳ−ＳＤサーバ１６５にエクスポートすることを決定し得る。ゲートウェイ１７１のＲＤが、比較的に大量の情報を含む場合、全ての記録をエクスポートすることは非効率的であり得る。この場合、ゲートウェイ１７１が、（例えば、アプリケーション知識によって）ＬＡＮ１７０外のデバイスに関心があるであろうことをそれが認知しているいくつかの重要なサービスを有する場合、ゲートウェイ１７１は、これらの特定の記録のみをＩｏＴ ＤＮＳ−ＳＤサーバ１６５にエクスポートするであろう。記録をＲＤからＤＮＳ−ＳＤサーバにエクスポートするための従来のプロセスが、ＣｏＲＥ Ｒｅｓｏｕｒｃｅ Ｄｉｒｅｃｔｏｒｙの第９．６節に説明されるように使用されることができる。ＩｏＴ ＤＮＳ−ＳＤサーバ１６５には、したがって、従来のＤＮＳ ＲＲならびに本明細書で議論される新しいＲＲで事前設定されるであろう。さらに、関連更新が、前述のプロセス後にＲＤの記録に行われた場合、ＲＤは、新しいＲＲのみＤＮＳ−ＳＤにエクスポートし得る。

図９は、例示的システム動作段階を図示する。図８に関連付けられたステップは、システム動作段階内に保存され得る。以下のステップは、例証目的のために、図６のコンテキストで検討される。ステップ２１１では、ＬＡＮ１７０のＩｏＴデバイス１７２によるＤＮＳクエリがある。ステップ２１２では、ゲートウェイ１７１は、ステップ２１１のクエリがサービス発見ＤＮＳクエリであるかどうかを決定し得る。ステップ２１３では、ステップ２１１のクエリが従来のＤＮＳクエリ（例えば、名前解決クエリ）であると決定されるかどうかのクエリが、インターネット上のＤＮＳサーバ１６１に対して行われる。

ステップ２１５では、ステップ２１１のクエリが、サービス発見ＤＮＳクエリである場合、ＬＡＮ１７０内のローカルクエリが、生じ得る。例えば、このローカルクエリは、とりわけ、ＣｏＡＰ ＲＤの検索、またはＬＡＮ１７０内の全ての他のデバイスへのｍＤＮＳマルチキャストクエリを開始することであり得る。第１の例では、ＩｏＴデバイス１７２は、ＬＡＮ１７０内の全ての他のデバイスへのｍＤＮＳマルチキャストクエリを直接開始することを決定し得る。この場合、ゲートウェイ１７１は、通常のＩｏＴデバイスとしての役割を果たす以外に何もする必要はなく、それが所与のサービスをサポートする場合、ｍＤＮＳクエリにおそらく応答する。第２の例では、ＩｏＴデバイス１７２は、ユニキャストＤＮＳ−ＳＤクエリを行うことを決定し得る。ゲートウェイ１７１がユニキャストＤＮＳ−ＳＤ要求を受信すると、それは、それを捕獲し、最初に、サービスがそのローカルＣｏＡＰ ＲＤデータベース内で見つけられることが可能かどうかの確認を試みるであろう。前述のように、これは、ＣｏＲｅ Ｒｅｓｏｕｒｃｅ Ｄｉｒｅｃｔｏｒｙの第９節に説明されるように、ＲＤとＤＮＳ−ＳＤ記録との間の単純マッピングである。ローカルクエリの選択肢（例えば、ｍＤＮＳまたはユニキャストＤＮＳ−ＳＤからＲＤへ）は、ＩｏＴデバイス１７２のアプリケーション論理に任せられる。

ステップ２１６では、サービスがＬＡＮ１７０内で発見されるかどうの決定が、行われる。ステップ２１７では、ステップ２１１のクエリ内で要求されたサービスが、ＬＡＮ１７０内で見つけられる場合、ゲートウェイ１７１または別のローカルデバイスは、要求側ＩｏＴデバイス１７２にＤＮＳ−ＳＤ応答で応答する。ステップ２１９では、ステップ２１１のクエリ内で要求されるサービスが、ＬＡＮ１７０内で見つからない場合、ゲートウェイ１７１は、要求側ＩｏＴデバイス１７２に直ちに応答しないこともある。代わりに、ゲートウェイ１７１は、ユニキャストＤＮＳ−ＳＤクエリをＩｏＴ ＤＮＳ−ＳＤサーバ１６５に転送し、要求されるサービスが仮想発見ゾーン内（例えば、仮想発見ゾーン１６７内のＬＡＮ１８０内）のいずれかで見つけられ得るかどうかを確認し得る。ゲートウェイ１７１は、いくつかの重複発見仮想ゾーンに属し得ることが可能であることに留意されたい。したがって、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５がステップ２１７のクエリを受信すると、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、この特定のクエリが検索すべき所望する仮想発見ゾーンについて決定を行うであろう。この決定は、負荷バランシング、セキュリティ証明書、または他の要因に基づき得る。重複発見仮想ゾーンが検索されることを可能にするためのＩｏＴ ＤＮＳ−ＳＤサーバ１６５のデフォルト構成が存在し得る。

ステップ２２１では、サービスが仮想発見ゾーン１６７内のいずれかで発見された場合、ゲートウェイ１７１は、ＤＮＳ−ＳＤ応答をＩｏＴ ＤＮＳ−ＳＤサーバ１６５から受信し、応答を要求側ＩｏＴデバイス１７２に転送する。

ステップ２２３では、ＩｏＴデバイス１７２は、応答を見て、本明細書に議論されるように、スリープステータスを伴う返された新しいＲＲ記録を見ることによって、要求されるサービスを行うことができるサーバが、現在スリープ中か、またはアウェイクであるか（または比較的に短時間以内にウェイクアップするであろうか）をチェックする。サーバがスリープ中である場合、ＩｏＴデバイス１７２は、ゲートウェイ１７１を介して、同一仮想発見ゾーン内のいずれかの別のサーバを見つけることを試みるであろう。

ステップ２１９では、ゾーン内のいずれにも利用可能なアウェイクサービスサーバが存在しない場合、ＩｏＴデバイス１７２は、ゲートウェイ１７１をトリガし、ＤＮＳ−ＳＤ要求を通常のインターネットＤＮＳサーバ１６１に送信することができる。ＩｏＴデバイス１７２は、そのアプリケーションタイミングまたは他の要件に基づいて、種々のＤＮＳ−ＳＤ要求をトリガすることを欲する回数を決定し得ることに留意されたい。ステップ２２５では、ＩｏＴデバイス１７２は、要求に応じて、サービスサーバにコンタクトする。

以下は、デバイスに関するスリープモードに関連付けられた信号伝達変更の議論である。本明細書に議論されるように、ＤＮＳのプロトコル要素は、ＲＲの概念である。これらのＲＲは、ＤＮＳドメインならびに個々のデバイスの特性を説明する。例えば、「Ａ」記録は、デバイス（ホスト）のＩＰｖ４アドレスを提供し、「ＭＸ」記録は、所与のドメインに関する電子メールサーバ名を提供する。

ＩＥＴＦ規格に適用され得る、信号伝達変更は、以下に提供される。一般的ＤＮＳ ＲＲフォーマットは、以下の表４の通りである。ＲＦＣ１０３５からのサポートおよびｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ａｓｓｉｇｎｍｅｎｔｓ／ｄｎｓ−ｐａｒａｍｅｔｅｒｓ／ｄｎｓ−ｐａｒａｍｅｔｅｒｓ．ｘｈｔｍｌ（以降、ＤＮＳパラメータ）（両方とも参照することによってその全体として組み込まれる）を参照されたい。

ここで、ＩｏＴデバイススリープ特性を記憶するための新しいＤＮＳ ＲＲ（「ＩＯＴＳＬＥＥＰＩＮＦＯ」と呼ばれる）を以下の表５および以下の通り定義する。

ここで、
１．ＲＲタイプ＝ＩＯＴＳＬＥＥＰＩＮＦＯ（新しいＲＲタイプである）
２．現在のスリープ状態＝０（アウェイク）、または１（スリープ中）
３．スリープ持続時間＝ＩｏＴデバイスがスリープ中であり得る時間間隔（例えば、秒単位）を示す、３２ビット符号無し整数（または別の長さの整数）。ゼロ値は、スリープ持続時間が未知であることを意味する。
４．スリープ周期性＝スリープ持続時間の開始間の時間間隔（例えば、秒単位）を示す、１６ビット符号無し整数。ゼロ値は、スリープ周期性が未知のであることを意味し得る。
５．クラス＝インターネット。

上で定義された新しいＲＲ（ＩＯＴＳＬＥＥＰＩＮＦＯ）は、通常のインターネットＤＮＳインフラストラクチャまたは本明細書に導入される新しいクラウドＤＮＳ−ＳＤサーバのいずれか内に記憶され得る。したがって、新しいＲＲ（ＩＯＴＳＬＥＥＰＩＮＦＯ）は、古典的ＤＮＳインフラストラクチャならびに新しいクラウドＤＮＳ−ＳＤサーバの両方のための有意な値を有し得る。以下（例えば、図１３）では、スリーピノードのハンドリングに関する追加の議論が行われる。

以下は、仮想発見ゾーン構成のための代替である。本明細書では、ＯＡＭベースのアプローチが、仮想発見ゾーンを作成および構成する方法に対して提供される。代替アプローチは、以下に議論されるように、制御ノード（例えば、ＩｏＴ ＤＳＮ−ＳＤサーバ、ＩｏＴゲートウェイ）間の信号伝達に基づく動的ネットワーク自己構成（自動）アプローチのためのものであり得る。他のアプローチも、本明細書に議論されるように、自動的に行われ得ることに留意されたい。図１０は、図６のシステムを参照して、仮想発見ゾーンを自己構成する例示的段階を図示する。ステップ２３１では、ＬＡＮ１７０が、動的に（自動的に）形成され得る。例えば、消防署によって火災中に展開される８０２．１５温度センサネットワークが挙げられる。ステップ２３２では、ＣｏＡＰ ＰＯＳＴ要求等のメッセージが、送信され得る。例えば、新しいＩｏＴ ＬＡＮ１７０が作成されると、そのゲートウェイ１７１は、自動的に、ＣｏＡＰベースのアプリケーションメッセージをＩｏＴ ＤＮＳ−ＳＤサーバ１６５に送信し、ＬＡＮ１７０がたった今作成されたことを知らせ得る。ステップ２３２のメッセージは、ＬＡＮ１７０が仮想発見ゾーン１６７に割り当てられる要求を含み得、仮想発見ゾーン１６７を形成するための要件を含み得る。ステップ２３２のメッセージは、その物理的ＧＰＳ座標（例えば、ゲートウェイ１７１座標）ならびにＬＡＮ１７０内のＩｏＴデバイス１７２およびＩｏＴデバイス１７３によってサポートされる重要なサービス等のＬＡＮ１７０についての情報を含み得る。ステップ２３２のメッセージは、ＬＡＮ１７０による物理的カ対象範囲を示し得る。物理的カ対象範囲は、地理的エリア（例えば、建物、ＧＰＳ座標、都市、州等）に関連付けられ得る。ＣｏＡＰ ＲＤ（ゲートウェイ１７１と共同配置される）は、別のＣｏＡＰベースのアプリケーションメッセージに送信し（後に）、ＬＡＮ１７０内のデバイスについての情報（例えば、そのＩＰアドレス）およびそのリソースまたはサービスついての情報を事前設定し得る。本明細書におけるＣｏＡＰの使用は、例示的である。代替は、ＨＴＴＰメッセージを使用して、同一機能を果たすであろう。

ステップ２３３では、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、ＬＡＮ１７０に関連付けるべき仮想発見ゾーンを決定する。仮想発見ゾーンは、ＬＡＮの論理的グループ化であり、それらのＬＡＮに対して、共通ＤＮＳ−ＳＤサービス発見ゾーンが存在するであろう。新しいＬＡＮを割り当てるべきゾーンの決定は、例えば、ＬＡＮのＧＰＳ座標に基づいて行われ得る。言い換えると、クラウドＤＮＳ−ＳＤサーバ（ＩｏＴ ＤＮＳ−ＳＤサーバ１６５）は、ある地理的エリアを対象とする仮想発見ゾーンを作成し得る。アクセス許可、加入されるサービス等の他の要因も、想定され得る。複数の仮想発見ゾーンが割り当てられる場合、ステップ２３４のメッセージは、複数の識別子、および複数の仮想発見ゾーンのうちの各仮想発見ゾーンに属するデバイスまたはサービスのリストを含み得る。仮想発見ゾーン１６７の識別子は、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５によって決定され得（但し、ゲートウェイ１７１は、新しく作成されたＬＡＮ１７０をＩｏＴ ＤＮＳ−ＳＤサーバ１６５に報告するプロセス中に識別子を示唆し得る）、それは、例えば、新しいＬＡＮ１７０のＧＰＳまたは他の座標に加えたそのサービスのハッシュであり得る。地理は、ＬＡＮ１７０の単一デバイス、ＬＡＮ１７０のデバイスの平均または他の閾値地理（例えば、地理的境界内にあるＬＡＮ上の平均デバイスに基づく）、主にゲートウェイ１７１の地理等に関連付けられ得る。以下は、新しく作成されたＬＡＮのために仮想発見ゾーンを割り当てるためのくつかの例である。第１の例では、各仮想発見ゾーンは、ある物理的エリアに関連付けられ得る。そして、新しく作成されたＬＡＮが、ＬＡＮがその対象範囲内にある場合、既存の仮想発見ゾーンに割り当てられるであろう。第２の例では、ＩｏＴ ＤＮＳ−ＳＤサーバは、２つ以上の仮想発見ゾーンを新しく作成されたＬＡＮに割り当て得る。複数のＬＡＮの割り当ての理由は、ＬＡＮの対象範囲が大きすぎること、またはあるプライバシー、セキュリティ、もしくは他の懸念が存在する場合に関連付けられ得る。

ステップ２３４では、ＣｏＡＰベースのアプリケーションメッセージ等のメッセージが、送信される。メッセージは、それが割り当てられる（例えば、仮想発見ゾーン１６７に割り当てられる）仮想発見ゾーンに関連付けられた情報を含み得る。ステップ２３４のメッセージは、割り当てられた仮想発見ゾーン１６７の識別子を含み得る。ステップ２３５では、ＬＡＮ１７０は、仮想発見ゾーン１６７の割り当てを受諾または拒否し得る。

図１１は、仮想発見ゾーンを自己構成する別の例示的段階を図示する。ステップ２４１では、ＬＡＮ１７０を解除する（例えば、前の例における火災が消火されてから数日後）、または別様に仮想発見ゾーン１６７へのＬＡＮ１７０の関連付けを解除することが決定され得る。例では、消防署による火災中に展開される８０２．１５温度センサネットワークは、もはや必要とされず、閉鎖されるであろう。ステップ２４２では、ゲートウェイ１７１は、ＣｏＡＰベースのアプリケーションメッセージ等のメッセージをＩｏＴ ＤＮＳ−ＳＤサーバ１６５に送信する。ステップ２４２のメッセージは、ＬＡＮ１７０が仮想発見ゾーン１６７から関連付け解除されることの要求を含む。例では、（アプリケーションデータ：仮想発見ゾーン１６７からのＬＡＮ１７０の関連付け解除要求）。ステップ２４３では、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、ステップ２４２のメッセージを受信し、メッセージが正しい許可を有する場合、ＬＡＮ１７０を仮想発見ゾーン１６７から適切に関連付け解除する。ステップ２４４では、削除または他の考慮点の確認を含むメッセージが、送信される。ステップ２４４のメッセージは、ＣｏＡＰ ＤＥＬＥＴＥ応答であり得る。ステップ２４５では、ゲートウェイ１７１は、ＬＡＮ１７０を解除またはＩｏＴ ＤＮＳ−ＳＤサーバ１６５からの関連付けを解除するために必要とされる任意のステップを継続し得る。

図１１を継続して参照すると、既存の仮想発見ゾーンに対する調節を生じさせ得るいくつかの場合が存在する。以下は、いくつかの例である。第１の例では、ＩｏＴデバイス１７２またはそのサポートされるデバイスが利用不可能となると、対応するゲートウェイ１７１（またはＣｏＡＰ ＲＤ）は、ＣｏＡＰベースのアプリケーションメッセージ等のメッセージを送信し、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５を更新し得る。その結果、ＩｏＴデバイス１７２またはそのサービスは、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５によって維持されている記録から除去されるであろう。第２の例では、ＩｏＴデバイス１７２がそのスリープスケジュールを変更すると、ゲートウェイ１７１（またはＣｏＡＰ ＲＤ）は、ＣｏＡＰベースのアプリケーションメッセージを送信し、新しいスリープ情報をクラウドＤＮＳ−ＳＤサーバに報告するであろう。その結果、クラウドＤＮＳ−ＳＤは、そのＤＮＳ−ＳＤ記録を更新するであろう。第３の例では、ＬＡＮ１７０内であると考えられる、ゲートウェイ１７１またはＩｏＴデバイス１７２が、その座標または物理的場所を変更すると、ゲートウェイ１７１（またはＣｏＡＰ ＲＤ）は、ＣｏＡＰベースのアプリケーションメッセージを送信し、新しい座標をＩｏＴ ＤＮＳ−ＳＤサーバ１６５に送信するであろう。その結果、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、１）ゲートウェイ１７１に対する現在の仮想発見ゾーン１６７を維持する（例えば、物理的座標があまり変化しない場合）、２）新しい仮想発見ゾーンをゲートウェイ１７１に割り当てる（例えば、物理的座標に対する変更が閾値を超える場合）、３）別の既存の仮想発見ゾーンにマージする（例えば、新しい物理的座標が別の既存の仮想発見ゾーンと重複する場合）、または４）別の既存の仮想発見ゾーンと分裂し得る（例えば、新しい物理的座標が既存の仮想発見ゾーンと重複し、非常に多くのデバイスがすでに存在する場合）。ＬＡＮ１７０内のゲートウェイ１７１または他のデバイスは、仮想発見ゾーンの割り当てを拒否し得る。

図１２は、スリープノードハンドリングを組み込み得る、例示的広域サービス発見実装を図示する。例示的シナリオは、複数のＬＡＮに及ぶ都市全体展開を伴うスマートグリッドオペレータのためのスリープノードハンドリングを包含し得る。代替として、これは、都市全体展開のために一緒に協力する協力スマートグリッドオペレータのグループであり得る（各々が限定数のＬＡＮを所有する）。図１２のコンテキストは、以下により詳細に議論されるように、主に、広域サービス発見をサポートするために使用されるＩＥＴＦ関連信号伝達およびノード内の関連付けられた処理論理に焦点を当てる。

例証目的のために、図１２を以下のシナリオで検討する。ＬＡＮ１７０（例えば、所与の近隣を対象とするローカルネットワーク）内の自宅メータ（例えば、ＩｏＴデバイス１７２）は、スリープ中ではない（例えば、アウェイクである）電気料金（コスト）サーバを見つけ、現在の電気料金（コスト）情報に対してポーリングする必要がある。自宅メータは、最新の料金情報を自宅所有者に表示し得るように、これを周期的に行う必要がある。コントローラ（例えば、コントローラ１７４またはコントローラ１８３）と呼ばれるあるデバイスは、料金情報を提供することが可能である。

前述のメータコントローラシナリオを参照すると、図１３は、前述の「ＩＯＴＳＬＥＥＰＩＮＦＯ」と呼ばれるＤＮＳ ＲＲを使用してスリーピノードシナリオをハンドリングするための例示的フローを図示する。ステップ２５１では、「料金情報サーバ」を尋ねる要求が、送信される。ステップ２５２では、ゲートウェイ１７１は、ＲＤをチェックし、ＬＡＮ１７０内でサービスを見つけることを試みる。ステップ２５３では、ゲートウェイ１７１は、その料金情報がコントローラ１７４にあることを提供する応答を送信する。応答は、コントローラ１７４についてのスリープ情報（例えば、ＩＯＴＳＬＥＥＰＩＮＦＯ−表５）を提供するＤＮＳ ＲＲも含み得る。ステップ２５４では、ＩｏＴデバイス１７２（例えば、自宅メータ）は、新しいＩＯＴＳＬＥＥＰＩＮＦＯ ＲＲをチェックし、コントローラ１７４が現在スリープ中であることを決定する。ステップ２５５では、「料金情報サーバ」を求める要求を含むメッセージが、送信される。ステップ２５５における要求は、ステップ２５１の要求に類似し得る。ステップ２５６では、ゲートウェイ１７１は、応答がステップ２５３におけるＲＤから提供されたことを決定し得、したがって、次のステップは、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５にクエリすることである。

図１３を継続して参照すると、ステップ２５７では、仮想発見ゾーン１６７内に位置する「料金情報サーバ」に対する要求を含むメッセージが、送信される。ステップ２５８では、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、コントローラ１８３が「料金情報サーバ」として以前に登録されたことを決定する。ステップ２５９では、別の「料金情報サーバ」（例えば、コントローラ１８３＠７４．１２５．２２４．７２）に対するコンタクト情報（例えば、ＩＰアドレス）を含むメッセージが、送信される。ステップ２６０では、ステップ２５９の情報が、ＩｏＴデバイス１７２に転送される。ステップ２６１では、ＩｏＴデバイス１７２は、コントローラ１８３がアウェイクであることを決定する。このアウェイク状態は、ステップ２６０のメッセージに付随するＤＮＳ ＲＲを検査することによって決定されていることもある。ステップ２６２では、現在の電気料金を要求するメッセージが、送信される。メッセージは、ＣｏＡＰ ＧＥＴ要求であり得る。ステップ２６３では、ＩｏＴデバイス１７２は、２６２からであることを示すメッセージを受信し得る。ステップ２６３のメッセージは、現在の電気料金データを伴うＣｏＡＰ ＧＥＴ応答を含み得る。

図１２および図１３を継続して参照すると、以下は、前述のメータスリープシナリオに関するさらなる考慮点である。自宅メータ（ＩｏＴデバイス１７２）からゲートウェイ１７１へのＤＮＳ−ＳＤクエリであり得るステップ２５１の要求は、同一ＬＡＮ１７０内のコントローラ１７４が料金情報を提供する要求されるサービスをサポートすることが伝えられる結果をもたらす。しかしながら、ステップ２５３のメッセージ内に含まれ得る、「ＩＯＴＳＬＥＥＰＩＮＦＯ」ＲＲは、コントローラ１７４が現在スリープ中であり、容認可能閾値より長い時間にわたってスリープ中となるであろうことを示す。ステップ２５５では、別の要求（ＤＮＳ−ＳＤクエリ）が、ゲートウェイ１７１に行われ得る。ステップ２５６では、前の要求が、考慮される。ゲートウェイ１７１は、前のクエリを追跡する必要があり（あるキャッシュ期間にわたって）、回答を類似質問に最近提供したことを把握する。したがって、前の回答が満足のゆくものではなかったと仮定し、今度は、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５にクエリし、仮想発見ゾーン１６７内のいずれかの別の料金情報サーバを見つける。代替として、ステップ２５２から２５５は、スキップされ得、ゲートウェイ１７１は、直接、適切なＤＮＳ ＲＲ（ＩＯＴＳＬＥＥＰＩＮＦＯ）および他の選好を検査し、要求される料金情報に対して別のコントローラにクエリするかどうかを決定し得る。

ＩｏＴ ＤＮＳ−ＳＤサーバ１６５が、ステップ２５７のクエリを受信すると、ステップ２５８では、この特定のクエリに対して検索することを所望する仮想発見ゾーンについての決定を行う必要があるであろう。これは、例えば、ゲートウェイ１７１の発信元ＩＰアドレス（ステップ２５７のクエリを搬送するメッセージ内に含まれ得る）を確認することによって遂行されることができる。例では、ゲートウェイ１７１のＩＰアドレスから、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５は、その内部データ構造によって、ＲＲと仮想発見ゾーンのマッピングを決定し得る。本明細書に記載されるように、仮想発見ゾーンは、ゲートウェイ（およびその対応するデバイス）のグループとクラウドＤＮＳ−ＳＤサーバ（例えば、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５）との間の関係として定義される。図１３に図示されるように、ＩｏＴ ＤＮＳ−ＳＤサーバは、ステップ２５９において、異なるＬＡＮ（ＬＡＮ１８０）内の別の料金情報サーバ（例えば、コントローラ１８３）で回答する。メータは、このコントローラ１８０がそのＩＯＴＳＬＥＥＰＩＮＦＯ ＲＲに対して現在スリープ中ではなく、したがって、それに直接クエリし、探していた料金情報を入手することが可能であることを確認し得る。代替として、前述のように、メータ（ＩｏＴデバイス１７２）は、ＩＯＴＳＬＥＥＰＩＮＦＯ ＲＲを受信しないこともあり、単に、その要求をＩｏＴ ＤＮＳ−ＳＤサーバ１６５によって提供されるアドレスに送信し得る。

図１４は、本明細書で議論される広域サービス発見に関連付けられた例示的図式的ユーザインターフェースを図示する。ディスプレイ２７０（また、ディスプレイ４２）は、ユーザが、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５のＯＡＭシステムの一部とインターフェースをとることを可能にし得る。ディスプレイ２７０は、タッチスクリーンであり、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５のプロバイダがその関連付けられた仮想発見ゾーンを図式的に表示することを可能にし得る。ディスプレイ２７０の２７２は、例えば、図１２、図６、およびその他に示されるように、所与の仮想発見ゾーン内に含まれるＬＡＮの図式的ビューを提供する。ディスプレイ２７０の２７１に、本明細書に議論されるように、コマンド、変数、入力、出力、フロー、広域サービス発見に関連付けられた動作の成功および失敗のテキスト表現が、存在し得る。以下は、例：仮想発見ゾーン１６７＝｛ＩｏＴ ＤＮＳ−ＳＤサーバ１６５、ＬＡＮ１７０、ＬＡＮ１８０｝である。仮想発見ゾーンは、ＯＡＭによって、または別の様式で動的に作成されていることもある。

さらに、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５のプロバイダは、ＬＡＮの種々の所有者による仮想発見ゾーンの遠隔ビューを可能にもし得る。これらのビューは、ＬＡＮの所有者がパスワードまたは他のセキュリティ証明書を用いてラップトップまたはスマートフォンからアクセスし得るウェブインターフェースを通して行われ得る。例では、図１２に類似するコンテキストでは、個々のＬＡＮが異なるスマートグリッドオペレータ（都市全体展開のためにともに協力している）によって所有されると仮定する。オペレータ−Ａは、ＬＡＮ−１、ＬＡＮ−２、およびＬＡＮ−３（図示せず）を所有し、オペレータ−Ｂは、ＬＡＮ−４およびＬＡＮ−５を所有する。次いで、オペレータ−Ａまたはオペレータ−Ｂのいずれかは、仮想発見ゾーン（図１２に類似する）またはテキスト表現の図式的ビューを入手し得る。

図１５Ａは、広域サービス発見に関連付けられた１つ以上の開示される概念（例えば、とりわけ、図６−図１４）が、実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２ＭデバイスまたはＭ２Ｍゲートウェイは、ＩｏＴ／ＷｏＴのコンポーネントであり得る。

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

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

図１５Ｂは、広域サービス発見と共に使用され得るＭ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図１５Ｂに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、ＩｏＴデバイス１７２、コントローラ１７４、ゲートウェイ１７１、ＩｏＴ ＤＮＳ−ＳＤサーバ１６５、およびその他）は、広域サービス発見のための開示されるシステムおよび方法を行う、例示的実装であり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される例のうちのいくつかにおけるＬＭＳが成功または不成功（例えば、ＩＯＴＳＬＥＥＰＩＮＦＯ ＲＲ、または仮想発見ゾーン内にあるが、ＬＡＮ外のデバイスに到達する）であるかどうかに応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御する、もしくは別様に仮想発見ゾーンまたは関連付けられた方法およびコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、もしくは色は、図に図示される、または本明細書で議論される（例えば、図６−図１４等）、方法フローもしくはコンポーネントのうちのいずれかのステータスを反映し得る。本明細書に開示されるのは、広域サービス発見のメッセージおよびプロシージャである。メッセージおよびプロシージャは、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、広域サービス発見関連情報を要求し、とりわけ、ディスプレイ４２上に表示され得る、広域サービス発見情報を要求、構成、またはクエリするためのインターフェース／ＡＰＩを提供するように拡張され得る。

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

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

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

伝送／受信要素３６は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅＨｅａｌｔｈデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイス内に具現化され得る。伝送／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。

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

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

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

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

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

さらに、コンピュータシステム９０は、図１５Ａのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７を含み得る。

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

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

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

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

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

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

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

図に図示されるような本開示の主題（広域サービス発見）の好ましい方法、システム、または装置を説明する上で、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択される具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。本開示は、ＩｏＴ使用例のための提案されるソリューションを使用することに焦点を当てることに留意されたい。しかしながら、本発明はまた、類似特性を伴う非ＩｏＴシナリオにも適用され得ることが明白である。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」等は、同義的に使用され得る。

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

方法、システム、および装置は、とりわけ、本明細書に説明されるように、デバイスのための広域サービス発見のための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のメッセージを第１のローカルエリアネットワーク上で受信することであって、第１のメッセージは、サービスに対する要求を含む、ことと、サービスが第１のローカルエリアネットワーク上に位置しないことを決定することと、サービスが第１のローカルエリアネットワーク上に位置しないことを決定することに応答して、第２のメッセージをサーバに提供することであって、第２のメッセージは、サービスに対する要求を含む、ことと、第３のメッセージを受信することであって、第３のメッセージは、サービスに関連付けられた情報を含む、こととのための手段を有する。第１のメッセージは、サービスに対する要求を含む複数のメッセージのうちの１つであり得、複数のメッセージは、マルチキャストＤＮＳによって送信され得る。サーバは、ＤＮＳ−ＳＤのためのサーバとして動作し得る。サービスに関連付けられた情報は、サービスのアドレスを含み得る。サービスに関連付けられた情報は、サービスの利用可能性の指示を含み得る。サービスは、遠隔デバイス上に位置し得、遠隔デバイスは、第２のローカルエリアネットワーク上に位置し得る。サーバは、広域ネットワーク上に位置し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、サービスに関連付けられた情報をクライアントデバイスに提供することであって、クライアントデバイスは、第１のメッセージを介して、サービスの要求側であることを示す、ことのための手段を有する。第１のメッセージは、ＤＮＳ−ＳＤクエリであり得る。第３のメッセージは、第２のメッセージへのＤＮＳ−ＳＤ応答であり得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、制約付きアプリケーションプロトコル（ＣｏＡＰ）リソースディレクトリのクエリに基づいて、サービスが第１のローカルエリアネットワーク上に位置しないことを決定する手段を有する。第２のメッセージは、仮想発見ゾーンの割り当てのための要求を含み得る。第３のメッセージは、仮想発見ゾーンの割り当てを含み得る。この段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で検討される。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のＬＡＮから、サービスに関するＤＮＳ−ＳＤクエリを受信するステップことと、ＤＮＳ−ＳＤクエリの受信に応答して、サービス、すなわち、第２のＬＡＮ上のサービスについての情報を提供することとのための手段を有する。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、要求をサービスに提供するステップと、要求に応答して、サービスに関連付けられたデバイスについてのスリープノード情報を含む応答を受信するステップとのための手段を有する。

本明細書に説明される主題は、例証として提供される。種々の修正および変更が、図示ならびに説明される例および用途に従わずに（例えば、ステップをスキップまたは追加して）、かつ請求項に記載される開示される主題の真の精神および範囲から逸脱することなく、本明細書に説明される主題に行われ得る。

Claims (20)

1. 装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   第１のメッセージを第１のローカルエリアネットワーク上で受信することであって、前記第１のメッセージは、サービスに対する要求を含む、ことと、
   前記サービスが前記第１のローカルエリアネットワーク上に位置しないことを決定することと、
   前記サービスが前記第１のローカルエリアネットワーク上に位置しないことを決定することに応答して、第２のメッセージをサーバに提供することであって、前記第２のメッセージは、前記サービスに対する要求を含む、ことと、
   第３のメッセージを受信することであって、前記第３のメッセージは、前記サービスに関連付けられた情報を含む、ことと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記第１のメッセージは、前記サービスに対する要求を含む複数のメッセージのうちの１つであり、前記複数のメッセージは、マルチキャストドメイン名システムによって送信される、請求項１に記載の装置。
3. 前記サーバは、ドメイン名システム-サービス配信（ＤＮＳ−ＳＤ）のためのサーバとして動作する、請求項１に記載の装置。
4. 前記サービスに関連付けられた情報は、前記サービスのアドレスを含む、請求項１に記載の装置。
5. 前記サービスに関連付けられた情報は、前記サービスの利用可能性の指示を含む、請求項１に記載の装置。
6. 前記サービスは、遠隔デバイス上に位置し、前記遠隔デバイスは、第２のローカルエリアネットワーク上に位置している、請求項１に記載の装置。
7. 前記サーバは、広域ネットワーク上に位置している、請求項１に記載の装置。
8. サーバは、サービスとしてのインフラストラクチャ（ＩＡＡＳ）である、請求項１に記載の装置。
9. さらなる動作が、前記サービスに関連付けられた情報をクライアントデバイスに提供することを含み、前記クライアントデバイスは、前記第１のメッセージを介して、前記サービスに対する要求側であることを示す、請求項１に記載の装置。
10. 前記第１のメッセージは、ドメイン名システム−サービス配信（ＤＮＳ−ＳＤ）クエリを含む、請求項１に記載の装置。
11. 前記第３のメッセージは、前記第２のメッセージへのドメイン名システム−サービス配信（ＤＮＳ−ＳＤ）応答を含む、請求項１に記載の装置。
12. 前記サービスが前記第１のローカルエリアネットワーク上に位置しないことを決定することは、制約付きアプリケーションプロトコル（ＣｏＡＰ）リソースディレクトリのクエリに基づく、請求項１に記載の装置。
13. 前記第２のメッセージは、仮想発見ゾーンの割り当てに対する要求をさらに含む、請求項１に記載の装置。
14. 前記第３のメッセージは、前記仮想発見ゾーンの割り当てをさらに含む、請求項１に記載の装置。
15. コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータデバイスによって実行されると、
    第１のメッセージを第１のローカルエリアネットワーク上で受信することであって、前記第１のメッセージは、サービスに対する要求を含む、ことと、
    前記サービスが前記第１のローカルエリアネットワーク上に位置しないことを決定することと、
    前記サービスが前記第１のローカルエリアネットワーク上に位置しないことを決定することに応答して、第２のメッセージをサーバに提供することであって、前記第２のメッセージは、前記サービスに対する要求を含む、ことと、
    第３のメッセージを受信することであって、前記第３のメッセージは、前記サービスに関連付けられた情報を含む、ことと
    を含む動作を前記コンピュータデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
16. 前記第１のメッセージは、前記サービスに対する要求を含む複数のメッセージのうちの１つであり、前記複数のメッセージは、マルチキャストドメイン名システムによって送信される、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
17. 前記サーバは、ドメイン名システム−サービス配信のためのサーバとして動作する、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
18. 前記サービスに関連付けられた情報は、前記サービスのアドレスを含む、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
19. 前記サービスに関連付けられた情報は、前記サービスの利用可能性の指示を含む、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記サービスは、遠隔デバイス上に位置し、前記遠隔デバイスは、第２のローカルエリアネットワーク上に位置している、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。