JP6510030B2 - モノのインターネット（ＩｏＴ）におけるデバイス場所登録のためのサーバ - Google Patents

Description

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

モノのインターネット（ＩｏＴ）パラダイムでは、我々を取り囲む物体の多くが、何らかの形態でインターネットに接続されるであろう。ＩｏＴは、相互接続された物体のネットワークへの現在のインターネットの進化であり、それは、環境から情報を得て（感知）、物理的世界と相互作用する（作動／コマンド／制御）だけではなく、情報転送、分析、適用、および通信のためのサービスも提供する。２０１１年だけで、地球上の相互接続されたデバイスの数は、実際の人々の数を追い抜いている。現在、９０億個もの相互接続されたデバイスが存在しており、２０２０年までに２４０億個のデバイスに達すると予期されている。

無線周波数識別（ＲＦＩＤ）は、物体に取り付けられたタグを自動的に識別および追跡する目的のためにデータを転送するための無線周波数電磁場の無線非接触使用である。タグは、電子的に記憶された情報を含む。タグは、電子製品コード（ＥＰＣ）と呼ばれる固有の識別番号と、潜在的に、製造業者、医療組織、軍組織、ロジスティクスプロバイダ、および小売業者、または商品もしくは機器の物理的場所を追跡する必要がある他者が着目する追加の情報とを含む。ＲＦＩＤプリンタによってタグの中に書き込まれると、タグは、９６ビットのデータのストリングを含む。最初の８ビットは、プロトコルのバージョンを識別するヘッダである。次の２８ビットは、このタグのためのデータを管理する組織を識別する。組織番号は、ＥＰＣグローバルコンソーシアムによって割り当てられる。次の２４ビットは、物体クラスであり、製品の種類を識別する。最後の３６ビットは、特定のタグのための固有の通し番号である。これらの最後の２つのフィールドは、タグを発行した組織によって設定される。ユニフォームリソースロケータ（ＵＲＬ）同様に、電子製品コード番号全体が、特定の製品を固有に識別するためのグローバルデータベースへのキーとして使用されることができる。

ＩＥＥＥ８０２．１５．４デバイスは、無線パーソナルエリアネットワーク（ＷＰＡＮ）内でデバイスを固有に識別する４８ビット（長）ＩＥＥＥアドレスを有する。バッテリ寿命を延長させるために、より短いアドレス（１６ビット）が、パケットサイズを短縮するため、故に、デバイスがアクティブに通信する時間を短縮するために使用される。

国際モバイル加入者識別（ＩＭＳＩ）は、セルラーネットワークのユーザを識別するために使用され、全セルラーネットワークに関連付けられた固有の識別である。それは、６４ビットフィールドとして記憶され、電話によってネットワークに送信される。移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）は、モバイル通信用グローバルシステム（ＧＳＭ（登録商標））または汎用モバイル電気通信システム（ＵＭＴＳ）モバイルネットワーク内の加入を固有に識別する番号である。それは、モバイル／携帯電話内の加入者識別モジュール（ＳＩＭ）カードに対する電話番号である。ＭＳＩＳＤＮは、ＩＭＳＩとともに、モバイル加入者を識別するために使用される２つの重要な番号である。後者は、ＳＩＭ、すなわち、携帯電話の中に挿入されるカードを識別する一方、前者は、呼を加入者にルーティングするために使用される。ＩＭＳＩは、多くの場合、ホーム場所レジスタ（ＨＬＲ）（「加入者データベース」）におけるキーとして使用され、ＭＳＩＳＤＮは、通常、呼を携帯電話に接続するためにダイヤルされる番号である。ＳＩＭは、ＩＭＳＩに固有に関連付けられる一方、ＭＳＩＳＤＮは、時間で変化し得、すなわち、異なるＭＳＩＳＤＮがＳＩＭに関連付けられ得る。

インターネットプロトコルバージョン６（ＩＰｖ６）アドレスは、ＩＰｖ６コンピュータネットワークに参加するコンピュータまたは他のネットワークノードのネットワークインターフェースを識別するために使用される数値ラベルである。

ＩＰｖ６アドレスは、１２８ビットのサイズを有し、ホストの個々のネットワークインターフェースを固有に識別し、ホスト間のＩＰパケットのルーティングを可能にする目的を果たす。ＩＰｖ６アドレスは、４つの十六進の数字の８つのグループとして表され、各グループは、１６ビット（２オクテット）を表す。グループは、コロン（：）によって分離される。

ルーティング情報プロトコル（ＲＩＰ）は、初期のＡＳ内インターネットルーティングプロトコルのうちの１つであり、今日も依然として広く使用されている。ＲＩＰは、ホップカウントをコスト指標として使用する。各リンクは、１のコストを有する。ＲＩＰは、用語「ホップ」を使用し、これは、ソースルータから宛先サブネットまでの最短経路に沿って通過するサブネットの数（宛先サブネットを含む）である。

図１は、自律システム（ＡＳ）１０２の一部を図示する略図である。ＡＳ１０２は、インターネット内に共通の明確に定義されたルーティングポリシーを提示する１つ以上のネットワークオペレータの制御下で接続されるＩＰルーティングプリフィックスの集合体である。同じＡＳ１０２内のルータは全て、同じルーティングアルゴリズムを起動し、互いについての情報を有する。

経路の最大コストは、１５に限定され、したがって、直径１５ホップ未満である自律システムにＲＩＰの使用を限定する。ＲＩＰでは、ルーティング更新は、ＲＩＰアドバタイズメントを使用して、約３０秒毎に近隣間で交換される。

各ルータは、ルーティングテーブルとして知られるＲＩＰテーブルを維持する。ルータのルーティングテーブルは、ルータの距離ベクトルおよびルータの転送テーブルの両方を含む。ルーティングテーブルは、３つの欄を有する。第１の欄は、宛先サブネットに対するものであり、第２の欄は、宛先サブネットまでの最短経路に沿った次のルータの識別を示し、第３の欄は、最短経路に沿った宛先サブネットに到達するまでのホップの数を示す。表１は、ルータＤのためのルーティングテーブルを示す。サブネットは、ＩＰネットワークの論理的可視細分化である。ネットワークを２つ以上のネットワークに分割する実践は、サブネット化と呼ばれる。サブネットに属する全ホストは、ルーティングプリフィックスと呼ばれる、そのＩＰアドレス内で共通の同じ最上位ビットグループを用いてアドレスされる。

ここで、３０秒後、ルータＤが、ルータＡから、表２に示されるアドバタイズメントを受信すると仮定する。このアドバタイズメントは、ルータＡからのルーティングテーブル情報のみである。この情報は、特に、サブネットｚがルータＡから４ホップのみ離れていることを伝達する。ルータＤは、このアドバタイズメントを受信すると、アドバタイズメントと古いルーティングテーブルをマージする。特に、ルータＤは、ここで、ルータＢを通る経路より短い、ルータＡを通るサブネットｚまでの経路が存在することを知る。したがって、ルータＤは、そのルーティングテーブルを更新し、表３に示されるようなより新しい最短経路を考慮する。

ＲＦＣ７９２に規定されるインターネット制御メッセージプロトコル（ＩＣＭＰ）は、ホストおよびルータによって、ネットワーク層情報を互いに通信するために使用される。ＩＣＭＰは、多くの場合、ＩＰの一部と見なされる。ＩＣＭＰメッセージは、ＩＰデータグラム内で搬送される。ＩＣＭＰメッセージは、基本ＩＰヘッダを使用して送信される。ＩＣＭＰメッセージフォーマットは、表４に示される。各ＩＣＭＰメッセージは、その目的を定義し、チェックサムを提供する、３つのフィールドを含む。それらは、タイプ、コード、およびチェックサムフィールドである。タイプフィールドは、ＩＣＭＰメッセージを識別し、コードフィールドは、関連付けられたタイプフィールドについてのさらなる情報を提供し、チェックサムは、メッセージの完全性を決定する方法を提供する。「未使用」と標識された任意のフィールドは、後の拡張のために確保され、送信されるとき、ゼロでなければならないが、受信機は、これらのフィールドを使用すべきではない（それらをチェックサムに含む以外）。

４２から２５２のタイプ番号は、割り当てられない。ＩＣＭＰｖ６の場合、１５９−１９９のタイプ番号は、割り当てられない。

図２は、開発中のｏｎｅＭ２Ｍ規格によって定義される「共通サービスエンティティ（ＣＳＥ）」１０２と呼ばれるｏｎｅＭ２Ｍサービス層を図示する略図である。サービス層の目的は、ｅ−ヘルス、全車両管理、およびスマートホーム等の異なる「バーティカル」Ｍ２Ｍサイロシステムおよびアプリケーションによって利用され得る、「ホリゾンタル」サービスを提供することである。ＣＳＥ１０２は、「発見」、「データ管理」、および「リポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図２は、ｏｎｅＭ２Ｍにおける開発中のＣＳＦを図示する。

図３は、ＣＳＥ１０２がサポートする、ｏｎｅＭ２Ｍ機能アーキテクチャに示されるような４つの参照点を図示する略図である。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）３０２とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥ３０４とインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）３０６とインターフェースをとる。ＮＳＥ３０６は、デバイス管理、場所サービス、およびデバイストリガリング等の下層ネットワークサービスをＣＳＥに提供する。

ＩｏＴデバイスのための新規命名スキームは、ＩｏＴデバイスの既存の命名スキームがデバイス発見およびグループ動作を効率的にサポートしないという問題に対処することができる。

ＩｏＴデバイス名サービス（ＩＤＮＳ）は、デバイス名が、場所および他のコンテキスト情報から生成され、場所変更またはコンテキスト変動に起因して更新され、かつ発見される方法を担当することができる。例示的ＩＤＮＳは、以下の機能性を有することができる。
（１） サブ場所登録機能：ＩＤＮＳは、主要場所における建物／設備の所有者／管理者がサブ場所を登録することを承認することができる。
（２） サブ場所プールマネージャ：ＩＤＮＳは、可能なサブ場所を主要場所下に含むサブ場所プールを維持することができる。サブ場所は、階層方式で維持されることができ、これは、各サブ場所がツリー構造に従ってそれ自身のサブ場所を有し得ることを意味する。
（３） デバイス登録機能：ＩＤＮＳは、ＩｏＴデバイスまたはその管理者／所有者がデバイスを登録することを承認することができる。登録情報では、デバイスの名前の一部（例えば、ラベルフィールド）、場所、または他のコンテキスト情報が、ＩＤＮＳがフルデバイス名を記録／生成することが可能であるように含まれ得る。
（４） デバイス名生成機能：ＩＤＮＳは、その場所および他のコンテキスト情報、例えば、タイプに基づいて、適切な名前をＩｏＴデバイスに割り当てることができる。
（５） デバイス名更新機能：ＩＤＮＳは、ＩｏＴデバイスまたはその管理者／所有者がデバイスの移動／場所変更に起因してデバイスの名前を更新することを承認することができる。
（６） デバイス名プールマネージャ：ＩＤＮＳは、同じ主要場所内のＩｏＴデバイスの名前を維持することができる。
（７） デバイスおよび名前発見機能：ＩＤＮＳは、同じ場所内のＩｏＴデバイスもしくはデバイス管理者、または他の場所内のＩＤＮＳからのデバイス名発見を承認することができる。

デバイス名スキームおよびＩＤＮＳの実施形態は、新しい特徴を可能にすることができる。
（１） サブネット化：命名スキームは、ＩｏＴネットワークの異なるレベルの物理的サブネット化を生成することができる。
（２） 名前ルーティングプロトコル（ＮＲＰ）：ＩｏＴデバイスは、その名前によってルーティングされることができる。名前スキームおよびＮＲＰを用いることで、ＩｏＴデバイスは、それらの間の直接通信を可能にするためにフルプロトコルスタックを実装する必要がない。
（３） デバイスグループ動作：提案されるＩＤＮＳおよびＮＲＰを用いることで、ＩｏＴデバイスのグループは、上位層の関与を伴わずに、効率的に発見され、動作させられることができる。
（４） デバイスの場所特定：提案される名前スキームおよびＩＮＤＳは、人がそのデバイスの場所を特定する／見つけることに役立つことができる。

一実施形態では、名前サービスは、ＩｏＴデバイスのための名前を維持することができる。名前サービスは、ＩＤＮＳであることができる。名前サービスは、ＩｏＴデバイスのための場所フィールドおよびラベルフィールドを有する名前を記憶することができる。場所情報を含む場所フィールドは、主要場所およびサブ場所を含むことができる。

一実施形態では、モノのインターネット（ＩｏＴ）デバイスは、メッセージを第２のＩｏＴデバイスにルーティングするように適合される。ＩｏＴデバイスは、ＩｏＴデバイスへのその途中でメッセージを転送するための第３のＩｏＴデバイスを示すルーティングテーブルを含むことができる。ルーティングテーブルは、主要場所および少なくとも１つのサブ場所を含む場所フィールドを含むＩｏＴデバイス名を使用することができる。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本願の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。
本発明は、例えば、以下を提供する。
（項目１）
プロセッサおよびメモリを備えているサーバであって、前記サーバは、前記サーバの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記サーバの前記プロセッサによって実行されると、
ネットワークデバイスのための名前を記憶することを前記サーバに行わせ、
前記名前は、場所フィールドおよびラベルフィールドを有し、前記場所フィールドは、主要場所およびサブ場所を含む場所情報を含む、サーバ。
（項目２）
前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、項目１に記載のサーバ。
（項目３）
前記場所フィールドは、階層的に配列されており、前記ベース場所の後に、１つ以上のサブ場所識別子が続く、項目１に記載のサーバ。
（項目４）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
サブ場所プールを維持することを前記サーバにさらに行わせ、
前記サブ場所プールは、階層方式で、前記主要場所の下に可能なサブ場所を含む、項目３に記載のサーバ。
（項目５）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
サブ場所名をサブ場所登録機能に登録することを前記サーバにさらに行わせる、項目１に記載のサーバ。
（項目６）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
ネットワークデバイスの場所および他のコンテキスト情報に基づいて、前記名前のうちの１つを前記ネットワークデバイスに割り当てることを前記サーバにさらに行わせる、項目１に記載のサーバ。
（項目７）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
ネットワークデバイスの場所の変更により、前記名前のうちの前記１つを更新することを前記サーバにさらに行わせる、項目１に記載のサーバ。
（項目８）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
前記名前を使用するデバイス名発見要求に応答することを前記サーバにさらに行わせる、項目１に記載のサーバ。
（項目９）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
前記ネットワークデバイスのための階層場所ツリーを含むテーブルを記憶することを前記サーバにさらに行わせる、項目１に記載のサーバ。
（項目１０）
前記テーブルは、ネットワークデバイスを媒体アクセス制御（ＭＡＣ）アドレスに関連付けている、項目９に記載のサーバ。
（項目１１）
プロセッサおよびメモリを備えているネットワークデバイスであって、前記ネットワークデバイスは、前記ネットワークデバイスの前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記ネットワークデバイスの前記プロセッサによって実行されると、
メッセージを第２のネットワークデバイスにルーティングすることを前記ネットワークデバイスに行わせ、
前記ネットワークデバイスは、ルーティングテーブルを含み、前記ルーティングテーブルは、前記ネットワークデバイスへの途中で前記メッセージを転送するための第３のネットワークデバイスを示し、前記ルーティングテーブルは、場所フィールドを含むネットワークデバイス名を使用する、ネットワークデバイス。
（項目１２）
前記ルーティングテーブルは、前記第２のネットワークデバイスまでの距離尺度を含む、項目１１に記載のネットワークデバイス。
（項目１３）
前記ルーティングテーブルは、ネットワークデバイスに対する利用可能時間情報を含む、項目１１に記載のネットワークデバイス。
（項目１４）
前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、項目１１に記載のネットワークデバイス。
（項目１５）
サーバによる使用のための方法であって、前記サーバは、プロセッサおよびメモリを備え、前記サーバは、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
ネットワークデバイスのための名前を記憶することを含む方法の機能を果たし、
前記名前は、場所フィールドおよびラベルフィールドを有し、前記場所フィールドは、主要場所およびサブ場所を含む場所情報を含む、方法。
（項目１６）
前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、項目１５に記載のサーバ。
（項目１７）
前記場所フィールドは、階層的に配列されており、前記ベース場所の後に、１つ以上のサブ場所識別子が続く、項目１５に記載の方法。
（項目１８）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
サブ場所プールを維持する機能をさらに果たし、
前記サブ場所プールは、階層方式で、前記主要場所の下に可能なサブ場所を含む、項目１７に記載の方法。
（項目１９）
前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、
サブ場所名をサブ場所登録機能内に登録する機能をさらに果たす、項目１５に記載の方法。
（項目２０）
ネットワークデバイスによる使用のための方法であって、前記ネットワークデバイスは、プロセッサおよびメモリを備え、前記ネットワークデバイスは、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
メッセージを第２のネットワークデバイスにルーティングすることを含む方法の機能を果たし、
前記ネットワークデバイスは、ルーティングテーブルを含み、前記ルーティングテーブルは、前記ネットワークデバイスへの途中で前記メッセージを転送するための第３のネットワークデバイスを示し、前記ルーティングテーブルは、場所フィールドを含むネットワークデバイス名を使用する、方法。
（項目２１）
前記ルーティングテーブルは、前記第２のネットワークデバイスまでの距離尺度を含む、項目２０に記載の方法。
（項目２２）
前記ルーティングテーブルは、ネットワークデバイスに対する利用可能時間情報を含む、項目２０に記載の方法。
（項目２３）
前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、項目２０に記載の方法。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。

図１は、自律システム（ＡＳ）の一部を図示する略図である。

図２は、開発中のｏｎｅＭ２Ｍ標準的によって定義される「共通サービスエンティティ（ＣＳＥ）」と呼ばれるｏｎｅＭ２Ｍサービス層を図示する略図である。

図３は、ＣＳＥがサポートする、ｏｎｅＭ２Ｍ機能アーキテクチャに示されるような４つの参照点を図示する略図である。

図４は、自家所有者が、台所内の照明のリストを発見し、照明のグループをオン／オフにすることを欲する例を図示する略図である。

図５は、サービス層またはアプリケーション層内のグループを伴うＣｏＲＥＲＤ実装を図示する略図である。

図６は、ＩＰを経由するシンレイヤとしてＩＤＳＮを示す略図である。

図７は、名前ルーティングプロトコル（ＮＲＰ）を経由するシンレイヤとしてＩＤＳＮを示す略図である。

図８は、住宅の間取り図と、冷蔵庫、煙センサ、台所内の照明、居間内の照明および電話、玄関の呼び鈴等の住宅内に位置するデバイスとを図示する略図である。

図９は、例示的ＩｏＴデバイス名サービス（ＩＤＮＳ）の略図である。

図１０は、一実施形態のサブ場所登録のためのメッセージフォーマットを図示する略図である。

図１１は、サブ場所登録のための詳細なメッセージフローおよびメッセージを図示する略図である。

図１２は、住宅管理者がＩＤＮＳにサブ場所である食堂を除去することを要求するためのメッセージフローを図示するメッセージフロー図である。

図１３は、一実施形態の場所ツリーを図示する略図である。

図１４は、デバイス登録メッセージをＩＤＮＳに送信することを図示する略図である。

図１５は、サブ場所識別子クエリメッセージフォーマットの実施例を図示する略図である。

図１６は、一例示的実施形態における、ＩｏＴデバイス登録のためのメッセージフロー図である。

図１７は、例示的サブ場所識別子妥当性確認メッセージフォーマットの略図である。

図１８は、例示的実施形態における、ＩｏＴデバイス名生成のためのメッセージフロー図である。

図１９は、例示的名前更新要求メッセージを示す略図である。

図２０は、例示的ＩｏＴデバイス名更新プロセスのメッセージフロー図である。

図２１は、デバイス名階層を図示する略図である。

図２２は、例示的デバイスおよび名前発見要求メッセージの略図である。

図２３は、例示的ＭＡＣアドレスクエリ方法を示すメッセージフロー図である。

図２４は、例示的高度デバイスおよび名前クエリを示す、フロー図である。

図２５は、リソース制約のあるデバイスである、１階の台所内の煙センサと、２階の廊下の煙センサとを図示する略図である。

図２６は、呼び鈴および主寝室内の電話を伴うトポロジを示す略図である。

図２７−３１は、一実施例の例示的ルーティングテーブルおよびトポロジを図示する略図である。

図２７−３１は、一実施例の例示的ルーティングテーブルおよびトポロジを図示する略図である。

図２７−３１は、一実施例の例示的ルーティングテーブルおよびトポロジを図示する略図である。

図２７−３１は、一実施例の例示的ルーティングテーブルおよびトポロジを図示する略図である。

図２７−３１は、一実施例の例示的ルーティングテーブルおよびトポロジを図示する略図である。

図３２は、ドア錠および照明がＩＰを使用して接続される実施例の略図である。

図３３は、ドア錠および照明がＮＲＰを使用して接続される、実施例の略図である。

図３４は、デバイスを見つける方法を図示するメッセージフロー図である。

図３５は、ＣＳＥ内にデバイス名サービスを伴う例示的ｏｎｅＭ２Ｍ実施形態の略図である。

図３６は、新しいｏｎｅＭ２Ｍ ＣＳＦとしてＣＳＥ内にホストされた名前ルーティング機能を伴う例示的ｏｎｅＭ２Ｍ実施形態の略図である。

図３７Ａ−Ｂは、例示的グラフィカルユーザインターフェースの略図である。

図３７Ａ−Ｂは、例示的グラフィカルユーザインターフェースの略図である。

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

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

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

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

実施形態は、モノのインターネット（ＩｏＴ）デバイス等のネットワークデバイスのための命名デバイスおよびスキームに関する。ＩｏＴデバイスは、センサ、モバイルデバイス、医療デバイス、自動車、機械、および器具を含む、インターネットに接続されるデバイスを含むことができる。ＩｏＴデバイスは、情報を感知、通信、および共有し、インターネットを横断する公共またはプライベートネットワークを経由して、相互接続ならびに相互作用されることができる、デバイスを含むことができる。デバイス／器具／機械（家庭用器具、遠隔センサ／アクチュエータ、機械、モバイルデバイス、自動車等）の多くが、前述の能力を装備すると、ＩｏＴデバイスとなるであろうことが予想され得る。特に、これらのＩｏＴデバイスは、データを定期的に収集、分析、および使用させ、アクションを開始し、ホームオートメーション、知的産業制御、遠隔およびリアルタイム医療等の範囲に及ぶ種々のサービスを提供することができる。

ＩｏＴデバイスの既存の識別子は、本来、デバイス発見およびグループ動作をサポートしない。多くのＩｏＴ使用例では、ユーザが、同じ場所内にあるデバイス、または同一コンテキスト情報を伴うデバイス、例えば、同一タイプのデバイスを発見することを欲することは、非常に一般的である。発見後、ユーザは、デバイスに対してグループ動作を行うことを欲し得る。

図４は、自家所有者が、台所４０４内の照明のリストを発見し、照明のグループをオン／オフにすることを欲する例を図示する略図である。ＩｏＴデバイスの既存の識別子は、そのような高度デバイス発見を促進しない。例えば、発明の背景で論じられたＩｏＴデバイス識別子のいずれも、本来、場所または他のコンテキスト情報に基づいて、高度デバイス発見をサポートし得るデバイス場所情報を含まない。さらに、デバイス発見およびグループ動作の既存のサポートは、図５に示されるように、ＣｏＲＥ ＲＤ実装、サービス層またはアプリケーション層内のグループの設定等、より高次の層の関与を要求する。しかしながら、リソース制約のあるデバイスがそのようなフルプロトコルスタックをサポートすることは、非常に高価である。

現在のＩｏＴシステムでは、互いに通信するデバイスは、同じサブネット内に位置するが、ソースデバイスは、依然として、そのデータをサービス層に報告し、それを記憶し、他のデバイスは、データをサービス層から読み出す。例えば、ＥＴＳＩ Ｍ２Ｍアーキテクチャ／ｏｎｅＭ２Ｍアーキテクチャにおけるように、デバイス上のデバイスアプリケーションは、リソースツリー上に記憶されるべき感知データまたはそのステータスを送信する。データに関心がある別のデバイス上のデバイスアプリケーションは、リソースにサブスクライブする必要があるであろう。リソース上で更新があると、他のデバイスは、通知されるであろう。それらのデバイスは、互いに近くに位置し、サービスプラットフォームの関与を伴わずに互いにトークすることを欲し得る可能性が非常に高く、それは、待ち時間およびサービスコストを削減することができる。言い換えると、近接サービスは、Ｍ２Ｍ／ＩｏＴシステムにおいて固有かつ基本的な相互作用パラダイムである。残念ながら、既存のデバイス命名スキームは、そのような通信パラダイムを効果的に促進することができない。

その結果、現在のＩｏＴシステムは、デバイス発見、デバイスグループ動作、より高次の層（例えば、サービス層）の関与を伴わない直接デバイス通信等、Ｍ２Ｍ／ＩｏＴ特徴アプリケーションおよび動作を促進するための効果的デバイス命名スキームを欠いている。

以下は、ＩｏＴデバイスのための新規命名スキームを説明し、スマートホーム使用例を使用して、命名スキームが屋内ＩｏＴデバイスに適用され得る方法について論じる。命名スキームはまた、産業現場制御等の使用例における屋外ＩｏＴデバイスにも適用可能である。第２に、提案される命名スキームを用いて、デバイス名が、場所および他のコンテキスト情報から生成され、場所変更またはコンテキスト変動に起因して更新され、かつ発見される方法を担当することができる例示的ＩｏＴデバイス名サービス（ＩＤＮＳ）が、説明される。第３に、命名スキームおよびＩＤＮＳによって可能にされ得るいくつかの新しい特徴が、説明される。最後に、主要な制御メッセージのＩＣＭＰメッセージ実施形態および提案されるＩＤＮＳのｏｎｅＭ２Ｍ実施形態が、論じられる。

ＩｏＴデバイスのための例示的命名スキームは、表５に示される。デバイスの１つの一次属性は、その場所であり、それは、デバイス名の一部として含まれる。デバイス名内に含まれる場所属性を用いることで、デバイスは、その名前から場所を特定可能である。同じ場所を伴うデバイスは、データ集約、デバイス管理、デバイスルーティング等の目的のために、一緒に容易にグループ化されることができる。例示的ＩｏＴデバイス名は、以下の２つの主要フィールドを有する。
・ ＩｏＴデバイスの名前内に含まれる場所フィールドは、ＩｏＴデバイスを識別およびアドレスするための主要な特性であると考えられる。ＩｏＴデバイスの場所は、主要場所（行政上の場所、座標、またはジオハッシュであり得る）と、サブ場所（デバイスが主要場所内で展開される場所）とから成り得る。
・ 多くのデバイスが同じ場所内に位置し得、したがって、ラベルフィールドが、デバイスを固有に識別するために場所に添付されることができる。ラベルは、デバイスのタイプ等のデバイスのいくつかの重要なセマンティクス／コンテキスト情報を組み込み得る。ラベルフィールドは、グローバルな唯一性を必要としない。しかしながら、同じ場所内において、ローカルな唯一性を必要とする。ＩＤＮＳは、同じサブ場所内のラベルフィールドのローカルな唯一性を確実にすることができる。

この命名スキームは、以下を行うことができる。
・ デバイス発見を促進する、例えば、住宅の１階の全照明を見つける。
・ デバイス集約およびグループ動作を促進する、例えば、住宅内の全照明をオフにする。

以下の実施例は、スマートホーム、スマート病院等の用途のために展開される屋内ＩｏＴデバイスを取り扱う。それらの屋内デバイスは、建物内の特定の部屋に位置する。図８は、住宅の間取り図と、冷蔵庫、煙センサ、台所内の照明、居間内の照明および電話、玄関の呼び鈴等の住宅内に位置するデバイスとを図示する略図である。

住宅内のデバイスの場所は、いくつかの階層を有することができる。以下の実施例では、第１の階層は、住宅の場所を示し、第２の階層は、階を示し、第３の階層は、部屋を示し、各部屋内のデバイスは、固有のラベルを有する。その結果、住宅内のデバイスは、例として、以下の名前を有し得る。
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｂａｔｈｒｏｏｍ３．Ｌｉｇｈｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｂｅｄｒｏｏｍ４．Ｌｉｇｈｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｅｎｔｒｙ．ｄｏｏｒｂｅｌｌ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｅｎｔｒｙ．Ｌｉｇｈｔ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋｉｔｃｈｅｎ．Ｆｒｉｄｇｅ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋｉｔｃｈｅｎ．Ｌｉｇｈｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋｉｔｃｈｅｎ．Ｌｉｇｈｔ２
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｒｅａｔ．Ｇａｔｅｗａｙ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｒｅａｔ．Ｐｈｏｎｅ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｒｅａｔ．Ｌｉｇｈｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｒｅａｔ．ＴＶ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇａｒａｇｅ．Ｃａｒ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇａｒａｇｅ．Ｃａｒ２
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇａｒａｇｅ．Ｌｉｇｈｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．Ｍａｓｔｅｒｂｅｄｒｏｏｍ．Ｐｈｏｎｅ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．Ｍａｓｔｅｒｂｅｄｒｏｏｍ．ＴＶ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．Ｈａｌｌｗａｙ．Ｇａｔｅｗａｙ

ドットは、異なる階層を連結するために使用されるが、他の記号も同様に使用されることができる。

アドレスの長さを短縮するために、各階層の名前内の文字の数を限定することが可能である。第１の階層は、サブネット化のための最高階層であり、第１の階層内に比較的により多くのサブネットが存在するため、固有であるために、他よりも比較的に多くの文字を有する必要がある。例えば、前述の識別子は、デバイス間でトランスポートされるメッセージのサイズを縮小するために、以下のように現れ得る。
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｂ３．Ｌｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｂ４．Ｌｔ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｅ．Ｄｂ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｅ．Ｌ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋ．Ｆｇ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋ．Ｌ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋ．Ｌ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｔ．Ｇｗ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｔ．Ｐｈ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｔ．Ｌ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｔ．ＴＶ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｇ．Ｃ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｇ．Ｃ２
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｇｇ．Ｌ１
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．ＭＢ．Ｐｈ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．ＭＢ．ＴＶ
・ ａｄｄｒｅｓｓｏｆＪｏｈｎＨｏｍｅ．Ｆ２．ＨＷ．Ｇｗ

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

図９は、例示的ＩｏＴデバイス名サービス（ＩＤＮＳ）９０２の略図である。ＩｏＴデバイス名サービス（ＩＤＮＳ）９０２は、デバイス名が、場所および他のコンテキスト情報から生成され、場所変更またはコンテキスト変動に起因して更新され、かつ発見される方法を担当することができる。一実施形態では、ＩＤＮＳ９０２は、以下の機能性を有する。
１） サブ場所登録機能９０４：ＩＤＮＳ９０２は、主要場所内の建物／設備の所有者／管理者（以降、建物および建物管理者と称する）がサブ場所を登録することを承認することができる。例えば、図８に示される住宅に対して、主要場所は、住宅の住所である一方、サブ場所は、住宅内の異なる階、部屋、例えば、１階、２階、玄関、台所、食堂、主寝室であり得る。
２） サブ場所プールマネージャ９０６：ＩＤＮＳ９０２は、主要場所下の可能なサブ場所を含むサブ場所プールを維持することができる。サブ場所は、階層方式で維持されることができ、これは、各サブ場所が、ツリー構造に従ってそれ自身のサブ場所を有し得ることを意味する。
３） デバイス登録機能９０８：ＩＤＮＳ９０２は、ＩｏＴデバイスまたはその管理者／所有者がデバイスを登録することを承認することができる。登録要求には、デバイスの名前の一部（例えば、ラベルフィールド）、場所、または他のコンテキスト情報が、ＩＤＮＳ９０２がデバイス名を記録／生成することが可能であるように含まれ得る。
４） デバイス名生成機能９１０：ＩＤＮＳ９０２は、その場所および他のコンテキスト情報、例えば、タイプに基づいて、適切な名前をＩｏＴデバイスに割り当てることができる。
５） デバイス名更新機能９１２：ＩＤＮＳ９０２は、ＩｏＴデバイスまたはその管理者／所有者がデバイスの移動／場所変更に起因してデバイスの名前を更新することを承認することができる。
６） デバイス名プールマネージャ９１４：ＩＤＮＳ９０２は、同じ主要場所内のＩｏＴデバイスの名前を維持することができる。
７） デバイスおよび名前発見機能９１６：ＩＤＮＳ９０２は、同じ場所内のＩｏＴデバイスもしくはデバイス管理者から、または他の場所内のＩＤＮＳ９０２からのデバイスおよびその名前発見を承認することができる。

ＩＤＮＳ９０２は、同じ場所内の全てのデバイスがＩＤＮＳ９０２にアクセス可能であり得るように、建物内の主要ゲートウェイ内にホストされることができる一方、他の場所内のＩＤＮＳ９０２は、互いに相互作用することができる。デバイスとそのＩＤＮＳ９０２との間の全制御メッセージ（ドメイン内通信）は、ＩＰならびに提案される名前によってルーティングされることができ、それは、提案される名前スキームによって可能にされる有意な特徴である。

提案されるＩＤＮＳ９０２は、図６および図７に示されるように、ＩＰまたはＮＲＰ（以下に論じられる名前ルーティングプロトコル）の上部のシンレイヤであり得る。ＩＤＮＳクライアントおよびサーバの両方が、ＩＰアドレスを割り当てられる場合、ＩＤＮＳクライアントとサーバとの間の通信は、ＩＰによってルーティングされることができる。本開示は、本開示で提案される主要な制御メッセージのＩＣＭＰメッセージ実施形態を提供する。一方、ＩＤＮＳクライアントが、ＩＤＮＳサーバ名を認識している場合（プロビジョニングによって）、ＩＤＮＳクライアントとサーバとの間の通信は、本開示で提案されるＮＲＰによってルーティングされることができる。

ＩＤＳＮ９０２は、サブ場所登録機能９０４をサポートすることができる。一実施例では、建物管理者は、ＩＤＮＳ９０２に建物内のサブ場所について通知する必要がある。ここでは、建物管理者は、この建物内の全てのサブ場所の知識を有すると仮定する。建物管理者がそのような情報を認識する場合、建物管理者は、それらの全ての代わりに、ＩｏＴデバイスを含むそれらのサブ場所のみを報告することを選定することができる（建物管理者は同様に、デバイス管理者でもあり得る）。サブ場所は、階層、例えば、階、部屋を有するので、建物管理者は、サブ場所を層状方式で、すなわち、層毎に報告することができる。例えば、図８における実施例では、建物管理者は、階番号の第１の層、次いで、各階上のサブ場所を報告する。

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

図１０は、一実施形態のサブ場所登録のためのメッセージフォーマットを図示する略図である。
・ 層番号は、サブ場所がある層を示し、例えば、階は、層番号２を有し、部屋は、層番号３を有する。
・ 上位層ノードは、この層に対する現在の層の上方にあるノードを示す。例えば、階層（層２）の上位層ノードは、住宅であり、部屋層（層３）の上位層ノードは、層２における階のうちの１つであることができる。したがって、各層は、２つ以上のブランチを含み得る。場所は、階層ツリーを形成する。
・ ノードフィールドは、そのブランチ内に含まれるサブ場所を示し、その寸法および座標は、登録メッセージ内に同様に含まれることができる。全てのサブ場所登録メッセージから、ＩＤＮＳは、建物内の各サブ場所の間取り図および寸法を確認することができる。

図１１は、実施例におけるサブ場所登録のための詳細なメッセージフローおよびメッセージを図示する略図である。

図１１のステップ１では、住宅管理者は、サブ場所登録メッセージをＩＤＮＳ９０２内のサブ場所登録機能９０４に送信し、層番号は、２であり、上位層ノードは、住宅住所であり、２つのノード、すなわち、１階および２階がこの層２にはある。

図１１のステップ２では、サブ場所登録機能９０４は、登録成功応答を住宅管理者に返し、そこには、サブ場所識別子が添付され得る。

図１１のステップ３では、住宅管理者は、サブ場所登録メッセージをＩＤＮＳ９０２内のサブ場所登録機能９０４に送信し、層番号は、３であり、上位層ノードは、１階であり、全ノード（部屋）は、１階にある。

図１１のステップ４では、サブ場所登録機能９０４は、登録成功応答を住宅管理者に返し、そこには、サブ場所識別子が添付され得る。

図１１のステップ５では、住宅管理者は、サブ場所登録メッセージをＩＤＮＳ９０２内のサブ場所登録機能９０４に送信し、層番号は、３であり、上位層ノードは、２階であり、全ノード（部屋）は、２階にある。

図１１のステップ６では、サブ場所登録機能９０４は、登録成功応答を住宅管理者に返し、そこには、サブ場所識別子が添付され得る。

サブ場所登録機能９０４はまた、建物管理者からのサブ場所の任意のさらなる更新をサポートすることができ、例えば、新しい部屋が、構造変更に起因して、追加または削除されることができる。サブ場所更新をトリガし得る別の理由は、部屋がＩｏＴデバイスを含まないものからＩｏＴデバイスが展開されるものに変化すること、またはその逆となることである。より高次の層内のサブ場所が、建物管理者によって除去される場合、その層下の全てのサブ場所も同様に、除去されることができることに留意されたい。

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

図１２は、住宅管理者がＩＤＮＳ９０２にサブ場所である食堂を除去することを要求するためのメッセージフローを図示するメッセージフロー図である。

図１２のステップ１では、住宅管理者は、サブ場所除去要求をＩＤＮＳ９０２内のサブ場所登録機能９０４に送信し、層番号は、３であり、上位層ノードは、１階であり、ノードは、食堂である。

図１２のステップ２では、サブ場所登録機能９０４は、除去成功応答を返す。

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

サブ場所プールマネージャ９０６は、建物管理者によって登録されるサブ場所を維持することができる。それは、層の各々に含まれる全てのサブ場所、例えば、第２の層内の１階、第３の層内の台所を記録することができる。言い換えると、各サブ場所は、図１３に示されるように、場所ツリー内のノードに対応することができる。サブ場所プールマネージャ９０６は、表６に示されるフィールドを用いてサブ場所を記録することができる。記述フィールドは、建物管理者からのサブ場所登録メッセージから抽出されることができ、これは、建物管理者がサブ場所を記述する方法を示す。識別子フィールドは、ＩＤＮＳ９０２によって生成されることができ、それは、２つ以上の値を有し得る。例えば、サブ場所である寝室＃４は、２つの識別子：寝室４（ロングバージョン）およびＢ４（ショートバージョン）を有することができる。一実施形態では、サブ場所の識別子は、同一親ノード下でそれを固有に識別することが可能であり得る。言い換えると、異なる親ノード下の子ノードが同一識別子を使用することを防止する必要はない。ＩＤＮＳ１０２は、登録されるときにサブ場所の識別子を生成するとき、この状況を回避しようとすることができる。識別子フィールドは、名前生成機能９１０によってデバイス名を生成するために使用されることができる。

ＩＤＮＳ９０２は、デバイス登録機能９０８を有することができる。建物内に設置されたＩｏＴデバイスは、ＩＤＮＳに登録されることができ（ＩＤＮＳサーバのＩＰアドレスまたは名前が、同じ場所内のＩｏＴデバイスにプロビジョニングされている）、それは、デバイス登録機能９０８によってハンドリングされる。ＩｏＴデバイス自体またはＩｏＴデバイス管理者は、図１４に示されるように、デバイス登録メッセージをＩＤＮＳ９０２に送信する。デバイス登録メッセージは、情報の異なる組み合わせを含み得る。フィールドの各々は、随意または必須として標識されることができる。媒体アクセス制御（ＭＡＣ）アドレスフィールドは、必須であることができる。ＭＡＣアドレスは、製造後のデバイスの固有のアドレスである。場所フィールドも同様に、必須であることができる。場所は、名前スキームに基づいてデバイス名を生成するために名前生成機能９１０によって要求される。場所フィールドは、異なるフォーマットおける値が割り当てられ得る。

場所記述（Ｄ）、例えば、寝室＃４が、表６内の記述フィールドに示される。記述に基づいて、名前生成機能９１０は、サブ場所プールマネージャ９０６にクエリし、デバイス名内に含まれるであろう、適切なサブ場所識別子を見つけるであろう。場所フィールド内に含まれる記述は、表６内の記述フィールドと正確に同一である必要はなく、サブ場所プールマネージャ９０６は、ファジークエリをサポートすることが可能であり、最近似一致を見つけることに留意されたい。

場所識別子（Ｉ）、例えば、Ｂｅｄｒｏｏｍ４が、表６内の識別子フィールドに示される。デバイスまたはデバイス管理者は、以下の状況において、サブ場所識別子を把握し得る。デバイスまたはデバイス管理者は、録前に適切なサブ場所識別子に対してサブ場所プール機能にクエリし得、それによって、登録メッセージに（Ｉ）フォーマットを用いて入力し得る。登デバイス管理者は、建物管理者と同一エンティティであり得、建物内のサブ場所識別子の知識を有する。

名前生成機能９１０は、サブ場所プールマネージャ９０６を用いて、識別子が有効場所識別子であるかどうかを検証することができる。名前生成機能９１０は、それを使用して、デバイス名を生成することができる。

場所座標（Ｃ）、例えば、３Ｄ（ｘ、ｙ、ｚ）における座標の組み合わせが、到着時間（ＴｏＡ）、受信信号強度指示等、既存の屋内測位システム（ＩＰＳ）技術により、デバイス自体によって自動的に得られ得る。座標に基づいて、名前生成機能９１０は、サブ場所プールマネージャ９０６にクエリし、適切なサブ場所識別子を見つけるであろう。サブ場所プールマネージャ９０６は、建物の間取り図および各サブ場所の寸法の知識を有し、その結果、デバイスがあるサブ場所を決定し、サブ場所識別子を名前生成機能９１０に返すことができる。

場所値のフォーマットも、図１４に示されるように、デバイス登録メッセージ内に含まれることができる。

ＩｏＴデバイスまたはデバイス管理者は、登録メッセージ内に、デバイスのコンテキスト情報の一部、例えば、デバイスのタイプ、デバイスのスリープスケジュール等も含むことができる。名前生成機能９１０は、それらから選択し、デバイス名のラベルフィールドに組み込むであろう。タグフィールドは、デバイス自体またはデバイス管理者がデバイス名のラベルフィールド内に含むことを欲する値、例えば、デバイス管理者特有のいくつかの文字を含むことができる。

デバイス登録機能９０８は、デバイス名生成機能９１０と通信し、デバイスのためのグローバルに固有の名前を得ることができる。そのような名前が生成される場合、デバイス登録機能９０８は、デバイスまたはデバイス管理者に、登録成功応答で返信することができる。

デバイス名生成機能９１０は、ＩＤＮＳ９０２が管理するドメイン内にＩｏＴデバイスのためのグローバルに固有の名前を生成することができる。実施例では、デバイス名生成機能９１０は、建物内の全ての登録されるデバイスのための名前を生成することに関与する。デバイス登録機能９０８は、デバイス登録情報をデバイス名生成機能９１０に転送する。

場所フィールドが（Ｄ）（記述）のフォーマットを有する場合、デバイス名生成機能９１０は、記述に一致する対応する場所識別子に対してサブ場所プールマネージャ９０６にクエリすることができる。図１５は、サブ場所識別子クエリメッセージフォーマットの実施例を図示する略図である。場所記述は、デバイス登録メッセージからコピーされることができる。短縮フィールドは、デバイス名生成機能９１０が、存在する場合、短縮／ショートバージョンの識別子を欲するかどうかを示す。

サブ場所プールマネージャ９０６が、一致するサブ場所を見つける場合、サブ場所識別子をデバイス名生成機能９１０に返すことができる。デバイス名生成機能９１０は、サブ場所識別子と、随意に登録メッセージ内に含まれる他のコンテキスト情報／タグとを、デバイスの名前の中に組み込む。名前が生成された後、それは、デバイス登録機能９０８に返されることができ、デバイス登録機能９０８は、適宜、登録成功応答を発信側に返す。生成されたデバイス名は、デバイス名プールマネージャ９１４によって記録および維持されることができる。後に、デバイスが同じ場所に留まるならば、それがバッテリの不足等に起因して切断し得る場合でも、名前を得るためにデバイス登録プロセスを経る必要はない。初期登録メッセージ内に含まれるコンテキスト情報の一部が変化しない限り、同じ場所においてその後も同一の名前を使用することができる。

図１６は、一例示的実施形態における、ＩｏＴデバイス登録のためのメッセージフロー図である。

図１６のステップ１では、デバイス管理者は、デバイス登録メッセージをデバイス登録機能９０８に送信する。

図１６のステップ２では、デバイス登録機能９０８は、登録メッセージの主要本文をデバイス名生成機能９１０に転送する。

図１６のステップ３では、登録メッセージ内に、場所が、記述を用いて表される。デバイス名生成機能９１０は、サブ場所識別子クエリをサブ場所プールマネージャ９０６に送信する。

図１６のステップ４では、サブ場所プールマネージャ９０６は、一致するエントリーを見つけ、対応するサブ場所識別子を返す。

図１６のステップ５では、デバイス名生成機能９１０は、提案される名前スキームに基づいて、デバイス名を生成し、デバイス登録機能９０８に返す。

図１６のステップ６では、デバイス名生成機能９１０はまた、新しいデバイスおよびその名前をデバイス名プールマネージャ９１４に報告する。

図１６のステップ７では、デバイス登録機能９０８は、デバイス管理者に登録成功応答で応答し、登録成功応答にデバイス名が添付される。

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

記述に一致するサブ場所プール内に記憶されたそのような場所が、存在しないことも可能である。したがって、デバイス登録は、失敗し得、失敗応答が、エラーコード（誤った場所）とともに、デバイス登録発信側に返されることができる。

場所フィールドが、（Ｉ）（識別子）（デバイス管理者がデバイス登録の前にサブ場所プールマネージャ９０６にクエリした）のフォーマットを有する場合、デバイス名生成機能９１０は、サブ場所プールマネージャ９０６と識別子を確認する必要がある。図１７は、例示的サブ場所識別子確認メッセージフォーマットの略図である。サブ場所識別子確認メッセージは、確認されるであろう識別子を含むことのみを必要とする。

サブ場所識別子が有効であり、サブ場所プールマネージャ９０６によって確認される場合、デバイス名生成機能９１０は、サブ場所識別子と、随意に登録メッセージ内に含まれる他のコンテキスト情報／タグとを、デバイスの名前の中に組み込む。名前が生成された後、デバイス登録機能９０８に返され、適宜、登録成功応答を発信側に返す。生成されたデバイス名は、デバイス名プールマネージャ９１４によって記録および維持されるであろう。後に、デバイスが同じ場所に留まるならば、バッテリの不足等に起因して切断し得る場合でも、名前を得るためにデバイス登録プロセスを経る必要はない。初期登録メッセージ内に含まれるコンテキスト情報の一部が変化しない限り、同じ場所においてその後も同一の名前を使用することができる。

図１８は、例示的実施形態における、ＩｏＴデバイス名生成のためのメッセージフロー図である。

図１８のステップ１では、デバイス管理者は、サブ場所識別子クエリをサブ場所プールマネージャ９０６に送信する。

図１８のステップ２では、サブ場所プールマネージャ９０６は、一致するエントリーを見つけ、対応するサブ場所識別子を返す。

図１８のステップ３では、デバイス管理者は、デバイス登録メッセージを適切なサブ場所識別子とともにデバイス登録機能９０８に送信する。

図１８のステップ４では、デバイス登録機能９０８は、登録メッセージの主要本文をデバイス名生成機能９１０に転送する。

図１８のステップ５では、登録メッセージ内に、場所が、その識別子を用いて表される。デバイス名生成機能９１０は、サブ場所識別子確認要求をサブ場所プールマネージャ９０６に送信する。

図１８のステップ６では、サブ場所識別子が確認された後、サブ場所プールマネージャ９０６は、確認をデバイス名生成機能９１０に返す。

図１８のステップ７では、デバイス名生成機能９１０は、提案される名前スキームに基づいて、デバイス名を生成し、デバイス登録機能９０８に返す。

図１８のステップ８では、デバイス名生成機能９１０は、新しいデバイスおよびその名前をデバイス名プールマネージャ９１４にも報告する。

図１８のステップ９では、デバイス登録機能９０８は、デバイス管理者に登録成功応答で応答し、そこには、デバイス名が添付される。

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

サブ場所が、サブ場所プールマネージャ９０６に従って無効である場合、デバイス登録は、失敗し得、失敗応答が、エラーコード（誤った場所）とともに、デバイス登録発信側に返されることができる。

デバイス名更新機能９１２は、その場所、またはその名前内に含まれる他のコンテキスト情報が変化する場合、デバイスの名前を更新することを担当することができる。以下は、主に、デバイスの場所が変化するシナリオに焦点を当て、それについて論じる。デバイスの場所は、デバイス管理者によって移動させられる場合、またはデバイス自体が移動性を有する場合、変化し得る。デバイス自体が移動性を有する場合（例えば、ｉＲｏｂｏｔ）、その名前は、その移動性がその任務を果たすことに起因するとき、期間中、更新される必要はない。その結果、本開示では、より恒久的な／長期間のデバイス場所変更をもたらし、デバイス名更新をトリガする移動性、例えば、デバイス管理者が照明を浴室＃３から浴室＃２に移動させる移動性、またはデバイス管理者がそのスマートフォンを居間から主寝室に携行するような移動性のみを考える。高移動性を伴うデバイスに対して、命名のために、おおよその場所を使用し得る。例えば、患者上の装着式デバイスに対して、デバイスの名前内の場所フィールドは、患者の家、病院等の患者のおおよその場所に基づいて設定されることができる。別の例として、輸送追跡タグに対して、デバイスの名前内の場所フィールドは、輸送経路全体、例えば、ＮＪからＰＡまでのルート９５に基づいて、設定されることができる。

デバイス管理者またはデバイス自体が、場所記述または場所識別子を認識する場合、名前更新要求をＩＤＮＳ９０２に送信することができる。デバイスは、ルーティング目的のために近隣発見を行うとき、新しい場所識別子をその近隣から得ることが可能であり得る。デバイスが近隣の名前を得て、それらの近隣の場所が現在のものと異なることに気付く場合、その場所／名前が更新される必要があると結論付け得る。

図１９は、例示的名前更新要求メッセージを示す略図である。現在の名前フィールド１９０２は、デバイス名更新機能９１２が、適切なデバイスを見つけ、デバイス名プールマネージャ９１４において更新することを可能にする。変更の数フィールド１９０４は、更新メッセージ内に含まれる変更の数を示す。変更フィールド１９０６、１９０８、および１９１０は、デバイスの場所および他のコンテキスト情報を含み得る。

説明を簡単にするために、ここでは、デバイス管理者が新しい場所識別子を把握していると仮定する。

図２０は、例示的ＩｏＴデバイス名更新プロセスのメッセージフロー図である。

図２０のステップ１では、デバイス管理者は、更新メッセージをＩＤＮＳ９０２内のデバイス名更新機能９１２に送信する。この例では、灯鏡が、１階の浴室＃４から２階の浴室＃３に移動させられる。

図２０のステップ２では、デバイス名更新機能９１２は、デバイス名プールマネージャ９１４と、更新メッセージ内に含まれるデバイス名が有効であり、既存のものであることを確認する。

図２０のステップ３では、デバイス名プールマネージャ９１０は、デバイス名をデバイス名更新機能９１２と確認する。

図２０のステップ４では、デバイス名更新機能９１２は、サブ場所プールマネージャ９０６と、新しいサブ場所識別子が有効なものであることを確認する。

図２０のステップ５では、サブ場所プールマネージャ９０６は、サブ場所識別子をデバイス名更新機能９１２と確認する。

図２０のステップ６では、両方が図２０のステップ２およびステップ３において確認された後、デバイス名更新機能９１２は、新しいデバイス名を生成するために、メッセージをデバイス名生成機能９１０に転送する。

図２０のステップ７では、デバイス名生成機能９１０は、新しいデバイス名を生成し、デバイス名更新機能９１２に転送する。図２０のシナリオでは、名前の場所フィールドが、変更されるであろう。名前のラベルフィールドは、ラベル内の一部のコンテキスト情報が変化しない限り、変化しないこともある。

図２０のステップ８では、デバイス名生成機能９１０は、デバイス名プールマネージャ９１４を新しいデバイス名で更新する。

図２０のステップ９では、デバイス名更新機能９１２は、デバイス名更新成功を新しい名前とともにデバイス管理者に返す。

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

デバイス名プールマネージャ９１４は、ＩＤＮＳ９０２が担当する主要場所内のデバイスの名前の記録および維持をサポートすることができる。一実施形態のデバイス名プール記録は、表７に示される。デバイスは、そのＭＡＣアドレスによって索引を付けられることができる。名前フィールドは、デバイスの現在の名前ならびに過去に使用された名前を含むことができる。

デバイス名プールマネージャ９１４はまた、デバイスのＭＡＣアドレス、その現在の名前、または任意の過去の名前によってエントリーを見つけることをサポートすることができる。デバイス名プールマネージャ９１４は、図２１に示されるような階層に従うように、デバイス名記録を維持することができる。

デバイスおよび名前発見機能９１６は、デバイス、デバイス管理者、建物管理者、アプリケーション等からのデバイスまたは名前クエリをハンドリングすることができる。提案される名前スキームはまた、より高度なデバイス発見を有効にする。デバイスクエリは、その名前をブラウジングすることのみによって、同じ場所内に展開されるデバイスのグループ、または同一コンテキスト情報を伴うデバイスのグループを発見するために構築され得る。例えば、クエリは、以下であり得る。
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅに位置するデバイスを発見する
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅの１階（Ｆ１）に位置するデバイスを発見する
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅの１階（Ｆ１）の浴室３（Ｂａｔｈｒｏｏｍ３）に位置するデバイスを発見する。

図２１に示されるデバイス名階層によると、前述のクエリは、対応して、ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ、Ｆ１、Ｂａｔｈｒｏｏｍ３である、親ノード下の全デバイスを返すことによって、容易に応答されることができる。

図２２は、例示的デバイスおよび名前発見要求メッセージの略図である。クエリタイプ２２０２は、要求側がＩＤＮＳ９０２に返してもらいたい結果を示す。

クエリタイプ２２０２は、デバイスのＭＡＣアドレスがクエリされるべきことを示すことができる。クエリ本文フィールド２２０４には、デバイス名プールマネージャ９１４が一致するデバイスを見つけるために、デバイスの完全名が含まれる。デバイスのＭＡＣアドレスが、要求側に返されるであろう。

図２３は、例示的ＭＡＣアドレスクエリ方法を示すメッセージフロー図である。

図２３のステップ１では、要求側は、デバイスおよび名前発見要求をデバイスおよび名前発見機能９１６に送信し、一致するデバイスのＭＡＣアドレスが返されることを欲することを示す。

図２３のステップ２では、デバイスおよび名前発見機能９１６は、デバイス名をデバイス名プールマネージャ９１４に転送する。

図２３のステップ３では、デバイス名プールマネージャ９１４は、一致するエントリーを見つけ、デバイスのＭＡＣアドレスをデバイスおよび名前発見機能９１６に返す。

図２３のステップ４では、デバイスおよび名前発見機能９１６は、要求側に一致するデバイスのＭＡＣアドレで応答する。

クエリタイプ２２０２は、デバイスの名前がクエリされるべきであることを示すことができる。クエリ本文フィールド２２０４には、デバイス名プールマネージャ９１４が一致するデバイスを見つけるために、デバイスのＭＡＣアドレスが含まれる。デバイスの名前が、要求側に返されるであろう。メッセージフローは、メッセージ内のコンテンツを除き、図２３に類似する。

クエリタイプ２２０２は、ＭＡＣアドレスとデバイスまたは複数のデバイスの名前との両方がクエリされることを示すことができる。クエリ本文フィールド２２０４には、デバイス名プールマネージャ９１４が一致する名前ならびにＭＡＣアドレスを見つけるために、デバイス名の一部が含まれる。デバイスのＭＡＣアドレスおよび対応する名前が、要求側に返されるであろう。メッセージフローは、メッセージ内のコンテンツを除き、図２３に類似する。

クエリタイプ２２０２は、高度デバイスおよび名前クエリであること示すことができる。クエリ本文フィールドには、デバイス名プールマネージャ９１４が全一致するデバイスを見つけるために、フィルタが含まれ、フィルタは、指定された場所記述／識別子および他のコンテキスト情報を考慮して設計される。デバイス’ＭＡＣアドレスおよび対応する名前が、要求側に返されることができる。メッセージフローは、図２３に類似する。しかしながら、クエリ本文が、場所記述のみを含む場合、デバイスおよび名前発見機能は、サブ場所プールマネージャ９０６から場所識別子に対してクエリする必要がある。

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

図２４は、例示的高度デバイスおよび名前クエリを示すフロー図である。

図２４のステップ１では、要求側は、デバイスおよび名前発見要求をデバイスおよび名前発見機能９１６に送信し、高度クエリであることを示す。要求側は、１階の寝室＃４内の全デバイスを発見することを欲する。

図２４のステップ２では、デバイスおよび名前発見機能９１６は、サブ場所識別子クエリをサブ場所プールマネージャ９０６に送信する。

図２４のステップ３では、サブ場所プールマネージャ９０６は、対応するサブ場所識別子を返す。

図２４のステップ４では、デバイスおよび名前発見機能９１６は、サブ場所識別子をデバイス名プールマネージャ９１４に転送する。

図２４のステップ５では、デバイス名プールマネージャ９１４は、一致するエントリーを見つけ、デバイスのＭＡＣアドレスのリストをデバイスおよび名前発見機能９１６に返す。

図２４のステップ６では、デバイスおよび名前発見機能９１６は、要求側に一致するデバイスのＭＡＣアドレスおよび名前で応答する。

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

ＩＤＮＳ９０２の使用は、ＩｏＴネットワーク内のいくつかの特徴を可能にすることができる。例えば、命名スキームは、ＩｏＴネットワークの異なるレベルの物理的サブネット化を生成する。言い換えると、サブネットに属する全デバイスは、その名前に共通の同じプリフィックスを有する。例えば、以下である。
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅは、住宅内の全デバイスの名前におけるプリフィックスである。
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１は、住宅の１階の全デバイスの名前におけるプリフィックスである。
・ ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋｉｔｃｈｅｎは、住宅の１階の台所内の全デバイスの名前におけるプリフィックスである。

提案される命名スキームによって可能にされるサブネット化は、以下の利点を有する。
・ デバイスのアドレス配分は、より効率的となり、その提案は、固有である。
・ サブネット化は、サブネットワークが異なるエンティティによって管理上制御されるとき、デバイス管理に利点を有する（デバイスグループ動作についての第５．３．３節に論じられる）。

インターネット内のサブネット化は、ホスト部分からのいくつかの上位ビットをサブネットマスクとして指定し、ホストをサブネットにグループ化する。同じマスクを伴う同じサブネット内のホストは、同じソースノードからの同じ次のホップルータを通してアドレスされることができる。しかしながら、本節において定義されたサブネットを形成する、提案される命名を伴うＩｏＴデバイスは、異なる次のホップルータを通してアドレスされ得る。言い換えると、サブネット内のＩｏＴデバイスは、異なる中間ノードを通してサブネット外のデバイスとトークし得る。ＩｏＴデバイス間の無線接続に起因して、同じサブネット内のデバイスは、使用されるルーティングアルゴリズムに応じて、異なる次のホップデバイスを通してピックアップまたはルーティングし得る可能性が非常に高い（異なる特性、例えば、リンク帯域幅、輻輳、信号強度が、次のホップノードの選定において考慮され得る）。同じサブネット内のデバイスが、異なるルーティングデバイスによってルーティングされる場合、それらは、異なるグループに集約されることができ、グループの各々は、次のホップと同じルーティングデバイスを有する。

ＩＤＮＳ９０２および表５の命名スキームは、名前ルーティングをサポートするために使用されることができる。ルーティングは、送信側から所望の宛先までの経路を見つけるタスクである。ＩＰ「インターネットモデル」では、これは、主に、ソースと宛先ネットワークとの間の一連のルータを見つける問題に帰着する。メッセージが単一ネットワークまたはサブネット上にある限り、任意の転送問題は、ネットワークに特有の技術の責務である。スマートホームネットワーク等のＩｏＴネットワークでは、デバイスがメッセージを別のデバイスに直接送信することが有利である多くのシナリオが存在する。

例えば、ドア錠が、自家所有者によって、居間内の照明がオンにされるためのメッセージ／コマンドを送信するように構成され得る。冷蔵庫は、買物リストを任意の時間にホームゲートウェイに送信するように構成され得る。ユーザが家に到着すると、買物リストが、ホームゲートウェイからユーザのスマートフォンに送信される。台所内の煙センサは、自家所有者が主寝室から聞こえるように、ビープ音を発するために、メッセージ／コマンドを２階の廊下に位置する煙センサに送信するように構成され得る。

以下は、ＩｏＴネットワーク内でルーティングを行うために使用されることが可能な名前ルーティングプロトコル（ＮＲＰ）を説明する。前述のＩｏＴデバイスのための命名スキームは、前述のシナリオで要求されるメッセージルーティングを促進することができる。ルーティング能力（すなわち、ルーティングテーブルを維持し、メッセージを宛先に向けて次のホップにルーティング可能である、ルーティングデバイス）を有するＩｏＴデバイスは、層３ルーティングを有効にするためにＩＰアドレスで常時構成される必要はない。

図２５は、リソース制約のあるデバイスである、１階の台所内の煙センサと、２階の廊下の煙センサとを図示する略図である。提案される名前スキームおよびＮＲＰを用いることにより、それらの間の直接通信を可能にするために、フルプロトコルスタックを実装する必要はない。ＮＲＰは、ＩＰアドレスがＩｏＴデバイスに利用可能ではない場合のオプション／代替である。

各ルーティングデバイスは、スモールエリアネットワーク（例えば、ホームネットワーク）内の可能な宛先ごとに１つのエントリーを有するルーティングデータベースを保持することができる。ルーティングデバイスが、スモールエリアネットワーク外のデバイスのためのルーティングエントリを維持することができることも可能であることに留意されたい。一実施形態では、ゲートウェイ以外のルーティングデバイスは、記憶およびリソース／エネルギー消費を節約するために、そのようなエントリーを保持しない。ゲートウェイは、屋内デバイスの代わりに外界と通信するために、ＩＰアドレスを割り当てられることができる。

一実施形態では、ルーティングデータベース内の各エントリーは、各宛先について以下の情報を保持することができる。
・ デバイス名／ネットワーク名：デバイス名は、前述のＩｏＴデバイスの名前である。ネットワーク名は、例えば、以下のように、特定のアドレスの異なるビルディングブロックとして表され得る。
− ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅは、住宅内の全デバイスのためのネットワーク名である。
− ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１は、住宅の１階の全デバイスのためのネットワーク名である。
− ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｋｉｔｃｈｅｎは、住宅の１階の台所内の全デバイスのためのネットワーク名である。
・ ルーティングデバイス：宛先までのルートに沿った第１のルーティングデバイス。
・ メトリック：宛先までの距離を示す、数字。
・ 有効時間：ルーティング経路が有効であると考えられる時間。ルーティング経路は、リソース制約のあるデバイスを伴い得、それらは、周期的に、またはあるスケジュールに従ってスリープになり得る、そのとき、宛先までのルーティング経路は、無効であると考えられる。

各ルーティングデバイスは、ルーティングデータベースがルーティングデバイス内に現在存在する場合、それを記述するルーティングテーブルブロードキャストメッセージを送信することができ、そのメッセージ本文は、表１０に示される。それは、近隣ルーティングデバイスから得られた情報のみを使用することによって、エリアネットワーク全体のための最適ルーティングを維持する可能性が高い。距離ベクトルアルゴリズムが、経路を計算するために使用されることができる。

近隣発見（例えば、６ＬｏＷＰＡＮ）を通して、全てのデバイスは、その１ホップ近隣を見つけることが可能であり、そこから、ルーティングテーブルが構築される。以下では、玄関の呼び鈴を例として使用して、ルーティングテーブルが最初から構築される方法を示し、主に、呼び鈴が主寝室内の電話に向かってルーティング経路を見つける方法に焦点を当てる。（以下では、デバイス識別子の第１の階層は、提示を簡単にするために示されない）。

呼び鈴Ｆ１．Ｅ．Ｄｂが、それ自体から１ホップ距離内にある、その近隣：Ｆ１．Ｅ．Ｌ（玄関照明）、Ｆ１．Ｇｇ．Ｌ１（車庫照明１）、Ｆ１．Ｇｇ．Ｃｍａ１（車庫一酸化炭素アラーム１）、Ｆ１．Ｇｇ．Ｃ１（車庫の車１）を発見する。近隣発見の間、呼び鈴は、近隣のスリープスケジュールまたはプレゼンススケジュール（すなわち、デバイスがルーティングサービス／機能を提供するために利用可能であるときのスケジュール）の知識も同様に得る。呼び鈴は、前述の情報を使用して、表８に示されるような初期ルーティングテーブルを形成する。

主寝室内の照明Ｆ２．ＭＢ．Ｌ２は、直接、電話（Ｆ２．ＭＢ．Ｐｈ）に到達することができ、表９に示されるように、そのルーティングテーブル内のＦ２．ＭＢ．Ｐｈのための１つのエントリーを有する（Ｆ２．ＨＷ．Ｃｍａは、２階の廊下内の一酸化炭素アラームである）。

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

その結果として、近隣発見後、最初のルーティングデバイス内のルーティングテーブルは、図２７に示される。

主寝室内の照明２は、そのルーティングテーブルをその近隣に送信し、これは、表１０に示されるようなフォーマットに従ってメッセージ内で搬送される。
・ タイプ：送信側のルーティングテーブルの全部または一部を含むメッセージであることを示す。
・ ＴＴＬ：メッセージ内に含まれるエントリーに対する有効期間を示す。
・ ルーティングテーブルエントリ：各々は、ルーティングテーブル内に１つのエントリーを含み、それは、デバイス／ネットワーク名、次のホップ、距離、および有効時間と同一フォーマットに従う。メッセージ内に含まれるエントリーの最大数は、５に限定される（この数字は、柔軟に更新される）。

２階の廊下の一酸化炭素アラームＦ２．ＨＷ．Ｃｍａが、ルーティングテーブルブロードキャストメッセージを主寝室内の照明Ｆ２．ＭＢ．Ｌ２から受信すると、表１１および図２８に示されるように、それ自身のルーティングテーブルを更新する。Ｆ２．ＭＢ．ＰｈおよびＦ２．ＭＢ．Ｌ２のエントリーの有効時間は、Ｆ２．ＨＷ．Ｃｍａが表９から１０：００〜１８：００のルーティング機能のみを提供するので、１０：００〜１８：００に更新される。

上階の照明Ｆ２．Ｓｔ．Ｌ２が、ルーティングテーブルブロードキャストメッセージを２階の廊下の一酸化炭素アラームＦ２．ＨＷ．Ｃｍａから受信すると、表１２および図２９に示されるように、それ自身のルーティングテーブルを更新する。Ｆ２．ＭＢ．ＰｈおよびＦ２．ＭＢ．Ｌ２のエントリーの有効時間は、１２：００〜１８：００に更新され、それは、ルーティング経路内に伴われるデバイスの有効時間から共同の組をとる。

下階の照明Ｆ１．Ｓｔ．Ｌ１が、ルーティングテーブルブロードキャストメッセージを上階の照明Ｆ２．Ｓｔ．Ｌ２から受信すると、表１３に示されるように、それ自身のルーティングテーブルを更新する。

玄関の呼び鈴Ｆ１．Ｅ．Ｄｂが、ルーティングテーブルブロードキャストメッセージを下階の照明Ｆ１．Ｓｔ．Ｌ１から受信すると、表１４および図３１に示されるように、それ自身のルーティングテーブルを更新する。前述のプロセスを通して、呼び鈴は、２階の主寝室内の電話までのルーティング経路を見つけることが可能である。通信が、玄関の有効時間外に生じる必要がある場合、呼び鈴は、主寝室内の電話に到達することができないと考えられる。

呼び鈴は、デバイスの複数のエントリーを１つのエントリーに集約し得る。表１５に示される実施例として、Ｆ２．ＭＢ．Ｘのエントリー（Ｘは、下階の照明Ｆ１．Ｓｔ．Ｌ１の次のホップを用いて呼び鈴から到達されることができる主寝室内のデバイスを表すために使用される）は、Ｆ２．ＭＢ．Ｐｈ、Ｆ２．ＭＢ．Ｌ２のエントリーから集約される。

デバイスグループ動作が、提案されるＩＤＮＳおよびＮＲＰによって提供される機能性によって可能にされ、それは、上位層、例えば、サービス層の関与を必要としない。

デバイスおよび名前発見機能９１６は、クエリ本文フィールド内に入れられた基準を満たすデバイスのグループが要求側によって得られ得るように、高度デバイス発見をサポートすることができる。図３３に示される実施例では、要求側は、居間内の全照明を発見することを欲するドア錠である。このステップ後、ドア錠は、居間内の全照明の識別子／名前：ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｌ．Ｌ１、…、ａｄｄｒｅｓｓＯｆＪｏｈｎＨｏｍｅ．Ｆ１．Ｌ．Ｌ６を得る。

ドア錠は、コマンドをペイロードとして層３メッセージ（例えば、ＩＣＭＰメッセージ）内に含む。同じサブ場所内に位置するデバイスは、同じサブネット内にある可能性が非常に高い。その結果、ドア錠と複数の照明との間のルーティング効率を最適化するために、ソースデバイスは、ルーティングのために、宛先デバイスのうちの１つ（一次宛先）を常時選択し、宛先フィールド内に入れる。一方、宛先デバイスの残りは、層３メッセージのペイロード内に添付されるであろう。メッセージが一次宛先デバイスに到達後、一次宛先デバイスは、宛先の残りへの対応したメッセージの分配を担当することができる。層３は、図３２および図３３に示されるように、ＩＰまたはＮＲＰであり得る。

提案される名前スキームおよびＩＮＤＳは、人がそのデバイスの場所を特定する／見つけることに役立つことができる。例えば、自家所有者は、その電話を置いた場所を忘れ得る。図３４は、デバイスを見つけるための方法を図示するメッセージフロー図である。図３４のステップ１では、ある人が、デバイス場所クエリをＩＤＮＳに送信する。クエリには、その人物は、ＩＤＮＳがデバイスを識別することに役立ち得る任意の記述、例えば、タグ（Ｊｏｈｎの電話）を入力することができる。デバイス名プールマネージャ９１４は、クエリをハンドリングすることができる。それは、クエリ内に含まれるタグを使用して、デバイス名プール内の全デバイスを検索し、タグに一致するものを得ることができる。

図３４のステップ２では、デバイス名プールマネージャ９１４は、デバイス名から場所フィールドを抽出し、場所記述クエリをサブ場所プールマネージャ９０６に送信する。

図３４のステップ３では、サブ場所プールマネージャ９０６は、対応するサブ場所記述をデバイス名プールマネージャ９１４に返すことができる。

図３４のステップ４では、デバイス名プールマネージャ９１４は、サブ場所記述を当該人物に返すことができ、その人物は、その電話が置かれた場所を把握するであろう。

一実施形態では、本開示で使用される主要な制御メッセージは、以下の通りである。
（１） サブ場所登録要求および応答メッセージ。
（２） デバイス登録要求および応答メッセージ。
（３） サブ場所識別子クエリおよび応答メッセージ。
（４） サブ場所識別子確認および応答メッセージ。
（５） デバイス名更新および応答メッセージ。
（６） デバイスおよび名前発見要求および応答メッセージ。

これらの制御メッセージは、ＩＣＭＰ／ＩＣＭＰｖ６メッセージによって搬送されることができる。例えば、４２から２５２の未使用ＩＣＭＰメッセージタイプが、それらのために使用されることができ、例えば、１００、１０１、１０２、１０３、１０４、１０５が、コード０を伴って前述の６つの要求メッセージのために確保される一方、対応する応答メッセージは、同一メッセージタイプであるが、コード１を有する。同様に、１５９から１９９の未使用ＩＣＭＰｖ６メッセージタイプが、それらのために使用されることができ、例えば、１７０、１７１、１７２、１７３、１７４、１７５が、前述の６つの要求メッセージのために確保される。

メッセージのコンテンツは、ＩＣＭＰメッセージのメッセージ本文フィールド内で搬送されることができる。

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

図３５は、ＣＳＥ３５０４内にデバイス名サービス３５０２を伴う例示的ｏｎｅＭ２Ｍ実施形態の略図である。ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、能力サービス機能（ＣＳＦ）３５０６の組を備えている、能力サービスエンティティ（ＣＳＥ）３５０４としてインスタンス化される。一実施形態として、提案されるＩＤＮＳ９０２は、ｏｎｅＭ２Ｍ ＣＳＦ３５０６としてＣＳＥ３５０４内にホストされ得る。ＣＳＥ３５０４は、ローカルエリアネットワーク（例えば、ホームネットワーク）内のゲートウェイに常駐し得る。デバイス名サービスＣＳＦ３５０２は、デバイス名が、場所および他のコンテキスト情報から生成され、場所変更またはコンテキスト変動に起因して更新され、かつ発見される方法を担当する。デバイス名サービス３５０２は、既存の登録ＣＳＦとの相互作用を有し得る、またはデバイス名サービスの機能性のいくつか（すなわち、サブ場所登録機能９０４、デバイス登録機能９０８）は、既存の登録ＣＳＦに移動させられ得ることに留意されたい。

建物管理者ＡＥ３５０８は、Ｍｃａ参照点を介して、デバイス名サービスＣＳＦ３５０２にトークし、サブ場所を登録することができる。デバイスＡＥは、Ｍｃａ参照点を介して、デバイス名サービスＣＳＦ３５０２にトークし、それ自体を登録し、その名前を得ること、または場所もしくは他のコンテキスト情報が変化した場合、その名前を更新することができる。デバイスおよび名前発見は、任意のＡＥからデバイス名サービスＣＳＦ３５０２へのＭｃａ参照点を介して、または、異なるＣＳＥ内のデバイス名サービスＣＳＦ間のＭｃｃ参照点を介して実行されることができる。その結果、第５．２節に提案される全ての対応するメッセージおよびプロシージャは、ＭｃａおよびＭｃｃ参照点に適用されるであろう。

別の実施形態として、名前ルーティング機能は、名前ルーティングサービス（ＮＲＳ）ＣＳＦ３６０２と呼ばれる新しいｏｎｅＭ２Ｍ ＣＳＦとして、ＣＳＥ内にホストされ得る。図３６における例示的展開に示されるように、デバイスＡ３６０４は、Ｍｃａインターフェースを経由して、ＣＳＥ１３６０６内のＮＲＳ ＣＳＦ３６０２に接続し、デバイスＢ３６０８も同様に、Ｍｃａインターフェースを経由して、ＣＳＥ３３６１２内のＮＲＳ ＣＳＦ３６１０に接続する。ＮＲＳ ＣＳＦは、可能な宛先ごとに１つのエントリーを有するルーティングデータベースを保持する。ＣＳＥ１ ３６０６、ＣＳＥ２ ３６１６、およびＣＳＥ３ ３６１２内のＮＲＳ ＣＳＦ３６０２、３６１０、および３６１４は、Ｍｃｃインターフェースを通してルーティングテーブルを交換し、デバイスＡ３６０４とデバイスＢ３６０８との間でメッセージをルーティングするためのより完全なルーティングエントリを構築する。

一般に、前述のデバイス名スキーム、命名サービス、およびルーティングサービスは、図３８ＢのＭ２Ｍサービス層２２および２２’等のＭ２Ｍサービス層内に実装され得る。特に、これらの機構およびプロシージャは、ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬ内、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）内、またはｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥ内等のサービス層内にサービス能力（ＳＣ）として実装され得る。そのようなサービス能力（ＳＣ）は、Ｍ２Ｍシステム内の１つ以上の独立型サーバ、コンピュータ、または他のコンピューティングデバイスもしくはノード上で、またはそのようなシステムの１つ以上の既存のサーバ、コンピュータ、もしくはノードの一部としてのいずれかで実行する、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得ることを理解されたい。例えば、本明細書に説明されるデバイス場所管理およびプライバシー制御のためのサービス能力は、図３８Ｃまたは図３８Ｄ（前述）に図示される一般的アーキテクチャを有するもの等のサーバまたはコンピュータ上に実装され得る。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、デバイス命名に関連する機能性を制御および／または構成するようにユーザを支援するために使用されることができる。

図３７Ａは、インターフェース３７０２を図示する略図である。サブ場所登録機能に対して論じられるように、建物管理者は、ＩＤＮＳに建物内のサブ場所について通知する必要があり得る。例えば、所与の建物に対して、建物管理者は、層番号、上位層ノード、およびこの層上のサブ場所またはノード等のデータアイテムを含む情報が、図１０に定義されるメッセージ内に含まれるように設定する必要がある（すなわち、サブ場所登録のメッセージフォーマット）。したがって、グラフィックユーザインターフェース（ＧＵＩ）３７０２は、前述の動作をサポートすることができる。そこから分かるように、ＧＵＩ ３７０２は、図１０に定義されるメッセージ構造と整合される（言い換えると、ＧＵＩ ３７０２からのユーザ入力は、図１０に定義されるメッセージを生成するために使用される）。

図３７Ｂは、インターフェース３７０４を図示する略図である。デバイス名生成／更新機能（それぞれ、ドメイン内のＩｏＴデバイスのためのグローバルに固有の名前を生成または更新することに関与する）に対して、ＧＵＩインターフェース３７０４は、ユーザがデバイス名を追加／更新するために使用され得る。図から分かるように、ユーザは、最初に、実施されるべき動作を選択すること、すなわち、デバイス名登録を通して新しいデバイスを追加すること、または既存のデバイス名を更新することを行う必要があり得る。故に、第１の動作に対して、このＧＵＩ ３７０４の設計は、図１４に定義されるメッセージ構造と整合される（言い換えると、ユーザ入力は、図１４に定義されるメッセージを生成するために使用されるであろう）、第２の動作に対して、このＧＵＩ ３７０４の設計は、図１９に定義されるメッセージ構造と整合される（言い換えると、ユーザ入力は、図１９に定義されるメッセージを生成するために使用されるであろう）。

インターフェース３７０２および３７０４は、以下に説明される図３８Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図３８Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷＯＴだけではなく、ＩｏＴ／ＷｏＴサービス層等の構成要素またはノードであり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、図９のＩＤＮＳ９０２、サブ場所登録機能９０４、サブ場所プールマネージャ９０６、デバイス登録機能９０８、デバイス名生成機能９１０、デバイス名更新機能９１２、デバイス名プールマネージャ９１４、ならびにデバイスおよび名前発見機能９１６、サブネット化機能性、デバイス名ルーティング機能性、デバイス発見機能性、デバイス名サービスＣＳＦ３５０２およびＮＲＳ ＣＳＦ３６０２、２７０２および３７０４等のＧＵＩを生成するための論理エンティティ、ならびに任意のそのような論理エンティティを伴うＩｏＴデバイスおよびゲートウェイを含む、本明細書に説明される機能性および論理エンティティを含むことができる。

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

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

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

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

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

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

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

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

一実施形態では、図９のＩＤＮＳ９０２、サブ場所登録機能９０４、サブ場所プールマネージャ９０６、デバイス登録機能９０８、デバイス名生成機能９１０、デバイス名更新機能９１２、デバイス名プールマネージャ９１４、ならびにデバイスおよび名前発見機能９１６、サブネット化機能性、デバイス名ルーティング機能性、デバイス発見機能性、デバイス名サービスＣＳＦ３５０２およびＮＲＳ ＣＳＦ３６０２、２７０２および３７０４等のＧＵＩを生成するための論理エンティティ、ならびに任意のそのような論理エンティティを伴うＩｏＴデバイスおよびゲートウェイを含む、本明細書に説明される論理エンティティは、図３８Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、図９のＩＤＮＳ９０２、サブ場所登録機能９０４、サブ場所プールマネージャ９０６、デバイス登録機能９０８、デバイス名生成機能９１０、デバイス名更新機能９１２、デバイス名プールマネージャ９１４、ならびにデバイスおよび名前発見機能９１６、サブネット化機能性、デバイス名ルーティング機能性、デバイス発見機能性、デバイス名サービスＣＳＦ３５０２およびＮＲＳ ＣＳＦ３６０２、２７０２および３７０４等のＧＵＩを生成するための論理エンティティ、ならびに任意のそのような論理エンティティを伴うＩｏＴデバイスおよびゲートウェイを含む、本明細書に説明される論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

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

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

さらに、図９のＩＤＮＳ９０２、サブ場所登録機能９０４、サブ場所プールマネージャ９０６、デバイス登録機能９０８、デバイス名生成機能９１０、デバイス名更新機能９１２、デバイス名プールマネージャ９１４、ならびにデバイスおよび名前発見機能９１６、サブネット化機能性、デバイス名ルーティング機能性、デバイス発見機能性、デバイス名サービスＣＳＦ３５０２およびＮＲＳ ＣＳＦ３６０２、２７０２および３７０４等のＧＵＩを生成するための論理エンティティ、ならびに任意のそのような論理エンティティを伴うＩｏＴデバイスおよびゲートウェイを含む、本明細書に説明される論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (14)

1. プロセッサおよびメモリを備えているサーバであって、前記サーバは、通信ネットワークに接続されており、前記サーバは、前記サーバの前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記サーバの前記プロセッサによって実行されると、
   複数のネットワークデバイスのための名前を記憶することであって、前記名前は、場所フィールドおよびラベルフィールドを有し、前記場所フィールドは、主要場所および前記主要場所内のサブ場所を含む場所情報を含み、前記ラベルフィールドは、サブ場所内の各ネットワークデバイスのための固有の識別子を含む、ことと、
   前記複数のネットワークデバイスのうちの１つ以上のネットワークデバイスが共通の場所情報を共有する場合に前記１つ以上のネットワークデバイスがサブネットに属するように、前記記憶された名前に基づいて前記通信ネットワークをサブネット化することと、
   第１のサブネットのネットワークデバイスから、前記ネットワークデバイスの場所の変更を示す要求メッセージを受信することと、
   ネットワークデバイスの場所の変更に起因して、前記主要場所および前記サブ場所を含む前記場所情報を更新することであって、前記ネットワークデバイスは、前記更新された場所情報に対応する第２のサブネットにおいてアドレス可能である、ことと
   を前記サーバに行わせる、サーバ。
2. 前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、請求項１に記載のサーバ。
3. 前記場所フィールドは、階層的に配列されており、前記主要場所の後に、１つ以上のサブ場所識別子が続く、請求項１に記載のサーバ。
4. 前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   サブ場所プールを維持することを前記サーバにさらに行わせ、
   前記サブ場所プールは、階層方式で、前記主要場所の下に可能なサブ場所を含む、請求項３に記載のサーバ。
5. 前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   サブ場所名をサブ場所登録機能に登録することを前記サーバにさらに行わせる、請求項１に記載のサーバ。
6. 前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   ネットワークデバイスの場所および他のコンテキスト情報に基づいて、前記名前のうちの１つを前記ネットワークデバイスに割り当てることを前記サーバにさらに行わせる、請求項１に記載のサーバ。
7. 前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   前記名前を使用するデバイス名発見要求に応答することを前記サーバにさらに行わせる、請求項１に記載のサーバ。
8. 前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   前記ネットワークデバイスのための階層場所ツリーを含むテーブルを記憶することを前記サーバにさらに行わせる、請求項１に記載のサーバ。
9. 前記テーブルは、ネットワークデバイスを媒体アクセス制御（ＭＡＣ）アドレスに関連付けている、請求項８に記載のサーバ。
10. 通信ネットワークにおいて使用される方法であって、前記方法は、
    複数のネットワークデバイスのための名前を記憶することであって、前記名前は、場所フィールドおよびラベルフィールドを有し、前記場所フィールドは、主要場所および前記主要場所内のサブ場所を含む場所情報を含み、前記ラベルフィールドは、サブ場所内の各ネットワークデバイスのための固有の識別子を含む、ことと、
    前記複数のネットワークデバイスのうちの１つ以上のネットワークデバイスが共通の場所情報を共有する場合に前記１つ以上のネットワークデバイスがサブネットに属するように、前記記憶された名前に基づいて前記通信ネットワークをサブネット化することと、
    第１のサブネットのネットワークデバイスから、前記ネットワークデバイスの場所の変更を示す要求メッセージを受信することと、
    ネットワークデバイスの場所の変更に起因して、前記主要場所および前記サブ場所を含む前記場所情報を更新することであって、前記ネットワークデバイスは、前記第１のサブネットの代わりに、前記更新された場所情報に対応する第２のサブネットにおいてアドレス可能である、ことと
    を含む、方法。
11. 前記ネットワークデバイスは、モノのインターネット（ＩｏＴ）デバイスである、請求項１０に記載の方法。
12. 前記場所フィールドは、階層的に配列されており、前記主要場所の後に、１つ以上のサブ場所識別子が続く、請求項１０に記載の方法。
13. 前記方法は、サブ場所プールを維持することをさらに含み、
    前記サブ場所プールは、階層方式で、前記主要場所の下に可能なサブ場所を含む、請求項１２に記載の方法。
14. 前記方法は、サブ場所名をサブ場所登録機能に登録することをさらに含む、請求項１０に記載の方法。