JP6291573B2 - セマンティクス公表および発見のための機構 - Google Patents

Description

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

物理的環境で展開されるネットワーク使用可能デバイスおよびセンサの数の急速な増加が、通信ネットワークを変化させている。次の１０年以内に、何十億ものデバイスが、スマートグリッド、スマートホーム、ｅ−ヘルス、自動車、輸送、物流、および環境監視等の種々の分野で、多くの用途およびサービスプロバイダによるサービスのための無数の実環境データを生成するであろうと予測される。現在の情報ネットワーキング技術への実環境データおよびサービスの統合を可能にする関連技術および解決策は、多くの場合、モノのインターネット（ＩｏＴ）またはマシンツーマシン（Ｍ２Ｍ）通信の包括的用語の下で説明される。デバイスによって作成される大量のデータによる、このデータを識別して問い合わせる効率的な方法の必要性がある。

図１は、集約点としてアクチュエータを使用する小型生物医学無線センサを使用して、患者の病院またはリハビリテーションセンターによって提供され得る、例示的患者監視アプリケーションを図示する。アクチュエータは、データをネットワークに伝送する。これらの小型装着型リソース制約デバイスは、とりわけ、血圧および血流、中核体温、酸素飽和度、運動、心拍数、聴覚、および視覚等の生命兆候を連続的に監視するように患者上に展開され得る、Ｍ２Ｍデバイスの実施例である。Ｍ２Ｍデバイスによって収集される種々の種類のＭ２Ｍデータは、図１で描写されるように、患者の医師、（例えば、２４時間フィットネスからの）個人トレーナ、および／または救急車サービスによって使用され得る。医師、個人トレーナ、および救急車サービスがこれらのＭ２Ｍデバイスから生成されたデータを使用することを可能にするために、これらのリソースのセマンティクスも利用可能である必要がある。セマンティクスは、データの形式および構造を理解することができるように、データの記述的定義を提供する（すなわち、セマンティクスはデータの意味を提供する）。

しかしながら、草稿ＥＴＳＩ ＴＳ １０２ ６９０およびＴＳ １０２ ９２１で説明されるＥＴＳＩ Ｍ２Ｍアーキテクチャ等の現在のＭ２Ｍシステムは、セマンティクスをサポートする機構を定義しない（例えば、ＥＴＳＩ Ｍ２Ｍ定義コンテナリソース内に記憶されたデータは、それとともに記憶することができるいかなるセマンティクス情報も有しない）。結果として、デバイスおよびアプリケーションは、交換されたコンテナの共通定義について、ならびに含まれたデータについて、事前に合意する必要がある。これは、現在のＭ２Ｍシステムにおいて異なるアプリケーションにわたるＭ２Ｍデータの再利用を困難にする。

本明細書では、セマンティクス公表および発見のための方法、デバイス、およびシステムが開示される。実施形態では、セマンティクス関連リソース識別子を公表する方法は、キーワードをセマンティクス関連リソースの識別子に追加することと、識別子を兄弟ノードおよび子ノードのうちの少なくとも１つに公表することとを含み得る。

別の実施形態では、方法は、セマンティクス関連リソースを公表するためにブルームフィルタを使用することを含み得る。別の実施形態では、方法は、セマンティクスノードによって、セマンティクスノードのダイジェストを子ノードに公表する一方で、セマンティクス関連リソースの識別子を兄弟ノードに公表することを含み得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
例えば、本願は以下の項目を提供する。
（項目１）
セマンティクス関連リソース識別子を公表するために使用されるデバイスであって、前記デバイスは、
プロセッサと、
前記プロセッサと連結されているメモリと
を備え、
前記メモリは、実行可能命令を備えており、前記命令は、前記プロセッサによって実行されると、
セマンティクス関連リソースに対する識別子を構築することであって、前記識別子は、
タイプと
キーワードと
を含む、ことと、
前記識別子を含むメッセージを公表することと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目２）
前記識別子は、ホストアドレスをさらに含む、項目１に記載のデバイス。
（項目３）
前記識別子とともに最大ホップ数を公表することをさらに含む、項目１に記載のデバイス。
（項目４）
セマンティクス関連リソースまたはセマンティクス関連リソースの識別子の閾値量に達したことを決定することと、
前記閾値量に達することに基づいて、前記メッセージの前記公表のための命令を提供することと
をさらに含む、項目１に記載のデバイス。
（項目５）
集約形式において複数のキーワードで前記キーワードを表すことであって、前記集約形式は、ブルームフィルタに基づく、ことと、
前記集約形式における前記複数のキーワードを有する前記キーワードを含むダイジェストメッセージを生成することと
をさらに含む、項目１に記載のデバイス。
（項目６）
ハイブリッドアプローチを使用して、前記識別子を含む前記メッセージ、および前記ダイジェストメッセージを普及させることをさらに含む、項目５に記載のデバイス。
（項目７）
前記ハイブリッドアプローチは、
前記識別子を含む前記メッセージの前記普及を兄弟セマンティクスノードまたは親セマンティクスノードに制限すること、または
前記ダイジェストメッセージの前記普及を兄弟セマンティクスノードに制限すること
を含む、項目６に記載のデバイス。
（項目８）
セマンティクス関連リソース識別子を発見するために使用されるデバイスであって、前記デバイスは、
プロセッサと、
前記プロセッサと連結されているメモリと
を備え、
前記メモリは、実行可能命令を備えており、前記命令は、前記プロセッサによって実行されると、
要求デバイスから、セマンティクス関連リソースに対する要求を受信することであって、前記要求は、第１のキーワードを含む、ことと、
前記要求されたセマンティクス関連リソースが前記デバイス上でローカルに記憶されていないことを決定することと、
前記要求されたセマンティクス関連リソースが前記デバイス上でローカルに記憶されていないことを決定することに応答して、前記第１のキーワードを第２のキーワードと合致させることであって、前記第２のキーワードは、前記セマンティクス関連リソースの識別子に関連付けられている、ことと、
前記第２のキーワードとの前記第１のキーワードの前記合致に基づいて、前記識別子に含まれているセマンティクスノードのアドレスを前記要求デバイスに転送することと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目９）
前記識別子は、タイプをさらに含む、項目８に記載のデバイス。
（項目１０）
前記要求は、前記第１のキーワードに関連付けられている第１のタイプと、前記第１のキーワードに関連付けられている前記アドレスとをさらに含む、項目８に記載のデバイス。
（項目１１）
さらなる動作が、
前記第１のタイプを第２のタイプと合致させることであって、前記第２のタイプは、前記第２のキーワードに関連付けられている、ことと、
前記第２のタイプとの前記第１のタイプの前記合致と前記第２のキーワードとの前記第１のキーワードの前記合致とに基づいて、前記アドレスを転送するための命令を提供することと
を含む、項目１０に記載のデバイス。
（項目１２）
さらなる動作が、前記第２のキーワードとの前記第１のキーワードの前記合致に基づいて、前記セマンティクスノードから前記セマンティクス関連リソースを読み出すことを含む、項目８に記載のデバイス。
（項目１３）
プロセッサと、
前記プロセッサと連結されているメモリと
を備え、
前記メモリは、実行可能命令を備えており、前記命令は、前記プロセッサによって実行されると、
所望の第１のセマンティクス関連リソースに対する要求を第１のセマンティクスノードに送信することであって、前記要求は、第１のキーワードを含む、ことと、
前記第１のセマンティクスノードから、第２のセマンティクスノードに対する識別子を含む応答を受信することであって、前記第２のセマンティクスノードは、第２のキーワードに関連付けられている第２のセマンティクス関連リソースを有し、前記第２のキーワードは、前記所望の第１のセマンティクス関連リソースに対する前記第１のキーワードに合致する、ことと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目１４）
前記要求は、前記第１のキーワードに関連付けられているタイプをさらに含む、項目１３に記載のデバイス。
（項目１５）
前記タイプは、クラス、関係、またはタームである、項目１４に記載のデバイス。
（項目１６）
さらなる動作が、
前記第２のセマンティクス関連リソースに対する要求を前記第２のセマンティクスノードに送信することと、
前記第２のセマンティクス関連リソースを受信することと
を含む、項目１３に記載のデバイス。
（項目１７）
さらなる動作が、
前記第２のセマンティクス関連リソースに対する要求を前記第２のセマンティクスノードに送信することと、
前記第２のセマンティクス関連リソースを受信することと、
前記第２のセマンティクス関連リソースが前記所望の第１のセマンティクス関連リソースに合致することを検証することと
を含む、項目１３に記載のデバイス。
（項目１８）
さらなる動作が、
前記第２のセマンティクス関連リソースが前記所望の第１のセマンティクス関連リソースに合致しないことを決定することと、
前記受信した第２のセマンティクス関連リソースの修正に対する要求を前記第２のセマンティクスノードに送信することと
を含む、項目１７に記載のデバイス。
（項目１９）
さらなる動作が、前記第２のセマンティクスノードへの前記第２のセマンティクス関連リソースに対する前記要求の状態を表示するための命令を提供することを含む、項目１７に記載のデバイス。
（項目２０）
さらなる動作が、前記第２のセマンティクス関連リソースの前記検証の状態を表示するための命令を提供することを含む、項目１７に記載のデバイス。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、患者監視アプリケーションを図示する。 図２は、セマンティクス関連リソース識別子の例示的な形式を図示する。 図３は、例示的なセマンティクスノードトポロジーを図示する。 図４は、例示的な集約識別子形式を図示する。 図５は、セマンティクス関連リソースの識別子を公表する例示的方法を図示する。 図６は、セマンティクス関連リソースを発見する例示的方法を図示する。 図７は、セマンティクス関連リソースの発見および検証のための例示的なコールフローを図示する。 図８は、ダイジェストを使用して公表する例示的方法を図示する。 図９は、ブルームフィルタを使用してセマンティクス関連リソースを発見する例示的方法を図示する。 図１０は、ダイジェストリソース構造を図示する。 図１１は、兄弟ダイジェストを図示する。 図１２は、親ダイジェストを図示する。 図１３は、セマンティクスノード間の兄弟関係を図示する。 図１４は、セマンティクス関連リソース識別子の公表を図示する。 図１５は、セマンティクスノードダイジェストの公表を図示する。 図１６は、ハイブリッド識別子およびダイジェスト公表を図示する。 図１７は、セマンティクス関連リソース発見を図示する。 図１８は、ＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図１９は、セマンティクスノードを伴うＭ２Ｍアーキテクチャを図示する。 図２０は、Ｍ２Ｍセマンティクスノードアーキテクチャを図示する。 図２１Ａは、セマンティクスノード階層を確立する方法の一実施形態を図示するフロー図である。 図２１Ｂは、図２１Ａのステップをさらに詳細に図示する。 図２２は、セマンティクスノード登録のメッセージフローを図示する。 図２３は、子によって開始される親子関係更新を図示する。 図２４は、セマンティクス関連リソース発見を処理するフロー図を図示する。 図２５は、ＲＥＳＴｆｕｌセマンティクスノード動作のメッセージフローを図示する。 図２６は、セマンティクス関連リソース発見、読み出し、および検証プロセスのメッセージフローを図示する。 図２７は、兄弟／親／子セマンティクスノードによって記憶および管理されるセマンティクス関連リソースを用いて更新され得る、セマンティクスノードのフロー図を図示する。 図２８は、同一のセマンティクスを伴うリソースのグループ化のフロー図を図示する。 図２９は、セマンティクス関連リソースプッシュ配信を図示する。 図３０は、デバイスが１つのエリアネットワークから別のエリアネットワークに移動するシナリオを図示する。 図３１は、データ／セマンティクス関連リソース移動のメッセージフローを図示する。 図３２は、独立型セマンティクスノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図３３は、セマンティクスノードリソース構造を図示する。 図３４は、ＳＳｓリソース構造を図示する。 図３５は、統合セマンティクスノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図３６は、ｘＳＣＬリソース構造を図示する。 図３７は、＜ｓｃｌ１＞上のセマンティクス関連リソース構造を図示する。 図３８は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅセマンティクスを図示する。 図３９は、リソースおよびセマンティクス読み出しのメッセージフローを図示する。 図４０は、独立型セマンティクスノードを伴う３ＧＰＰ ＭＴＣアーキテクチャを図示する。 図４１は、独立型セマンティクスノードを伴う３ＧＰＰ ＭＴＣアーキテクチャを図示する。 図４２は、本明細書で説明されるようなセマンティクスノードの使用の一実施例の説明図を提供する。 図４３Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図４３Ｂは、図４３Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図４３Ｃは、図４３Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図４３Ｄは、図４３Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

セマンティクスノード（ｓｅｍａｎｔｉｃｓ ｎｏｄｅ）でホストされるセマンティクス関連リソースが発見され、他のコンピュータデバイスによって使用され得る。セマンティクスノードがセマンティクス関連リソースに対する要求を受信すると、セマンティクスノードは、そのローカル意味論データベースをチェックし得る。合致がない場合、セマンティクスノードは、それと論理的関係を有する他のセマンティクスノード、例えば、兄弟ノードまたは親ノードに要求を転送し得る。

セマンティクス関連リソースのセマンティクス公表および発見のためのシステムは、セマンティクスノードによって積極的に回答することができない各発見要求を大量送信または転送するステップを含み得る。大規模ネットワークで実装される場合、各要求を大量送信または転送することは、ネットワーク上の有意なオーバーヘッドおよび帯域幅消費を引き起こし得る。前述の大量送信および転送環境に加えて、セマンティクスノードが合致セマンティクス関連リソースを返信することに協力しない場合、追加のネットワーク問題があり得る。例えば、セマンティクスノード間の協力がないことは、セマンティクスノードに、複数の他のセマンティクスノードから返信される、類似する合致セマンティクス関連リソースを受信させ得、これは、ネットワーク内で有意なオーバーヘッドおよび帯域幅消費を課し得る。本明細書では、セマンティクス関連リソースの場所を発見（検索）すること、およびセマンティクス関連リソースの場所を公表（伝送）することを促進し得る、追加のセマンティクス関連リソース方式が開示される。

セマンティクスノードアーキテクチャの簡潔な概要が以下で提示される。セマンティクスノードアーキテクチャに関するさらなる詳細は、図１８−図４２に対応する説明で提供される。

従来のマシンツーマシン（Ｍ２Ｍ）システムでは、（エンドデバイスならびにバックエンドネットワークサーバ上でホストされる）Ｍ２Ｍアプリケーションは、交換されたデータの共通定義について事前に合意する必要がある。これは主に、アプリケーションの代わりにＭ２Ｍデータを解析、解釈、または処理することができる、意味認識Ｍ２Ｍサービス層の欠如によるものである。現在のＭ２Ｍシステムでは、Ｍ２Ｍサービス層は、意味認識能力が欠けており、したがって、Ｍ２Ｍサービス層を通って流動する、またはＭ２Ｍサービス層内に記憶されるデータは、不透明な情報として扱われる。

この意味認識の欠如は、たとえデータが起源であったアプリケーションのいかなる予備知識がなくても、異なるアプリケーションによって発見、アクセス、解釈、および共有することができるように、Ｍ２Ｍアプリケーションによって生成されるデータがＭ２Ｍサービス層によって効果的に抽象化または仮想化されることを可能にするサービスを、Ｍ２Ｍサービス層が提供することを妨げる。結果として、感知および作用される物理的エンティティ（例えば、アプライアンス、人、車、建築物の部屋等）は、Ｍ２Ｍサービス層によって効果的に仮想化／抽象化されない場合があり、物理的エンティティは、環境に固有であり、特定のＭ２Ｍアプリケーションに関係しない一般的エンティティとして扱われる。この制限を克服するために、Ｍ２Ｍシステムにおいて伝送されるデータは、意味認識Ｍ２Ｍサービス層がＭ２Ｍアプリケーションと同一のデータの知識を有することができるように、セマンティクス情報に関連付けられ、統合され得る。そうすることで、Ｍ２Ｍサービス層は、アプリケーションにわたるデータの共有をより良好に促進し、付加価値のある意味認識サービスをＭ２Ｍアプリケーションに提供することができる（例えば、データ集約、異なるアプリケーション間のデータ共有等）。

例えば、図１で図示される患者監視アプリケーションでは、患者の生命兆候（例えば、血圧、温度、酸素、心拍数等）を監視する無線センサデバイスの各々の上でホストされる、別個のアプリケーションがあり得る。同様に、この情報を利用することができる、ネットワーク内でホストされる別個のアプリケーションがあり得る（例えば、患者の医師、個人トレーナ、家族、救急車の救急医療隊員等）。しかしながら、無線センサデバイスの各々からのＭ２Ｍ意味認識サービスデータがないと、ネットワークアプリケーションが、無線センサデバイス上でホストされるアプリケーションの予備知識、およびそれらが生成する情報のタイプ（例えば、場所／アドレス、データの単位、データのコンテキスト等）を有しない限り、ネットワークアプリケーションは、デバイスアプリケーションから情報を発見、共有、および理解することに困難を有し得る。

セマンティクスノードは、Ｍ２Ｍサービス層意味認識およびデータ抽象化をサポートするために、Ｍ２Ｍシステムにおいて以下の機能、すなわち、（ｉ）セマンティクス情報を記憶するためのサポート、および／またはセマンティクス情報を記憶するサーバへのインターフェースのためのサポート、（ｉｉ）セマンティクス情報を作成、読み出し、更新、および削除するための機構のためのサポート、（ｉｉｉ）ローカルおよび遠隔リソースへのセマンティクス情報更新のための機構のためのサポート、（ｉｖ）セマンティクス情報をローカルまたは遠隔のいずれかで記憶され得る対応するリソースに関連付ける／結び付けるためのサポート、および（ｖ）セマンティクス記述を公表して発見する能力を提供し得る。

本明細書で説明される場合、セマンティクスノードは、ネットワーク内の独立型コンピュータデバイス（例えば、サーバ）上でホストされ得るか、またはＭ２Ｍゲートウェイ、Ｍ２Ｍデバイス、Ｍ２Ｍサーバ等のネットワーク内の既存のエンティティ上でホストされ得る、論理エンティティである。セマンティクスノードは、データを記述するレポジトリと見なされ得る。例えば、血圧用のセンサデバイスは、どのようにしてそのデータを記述するかを理解することを希望し得、従って、すでに定義された血圧クラスがあるかどうかを解明するために近くのセマンティクスノードに問い合わせを行う。すでに定義された血圧クラスがある場合、セマンティクスノードは、それがローカルで見出した血圧クラスでセンサデバイスに応答する。もしそうでなければ、セマンティクスノードは、他のセマンティクスノード（例えば、兄弟または親）に問い合わせを行い得る。セマンティクスノードの使用は、エンドデバイスにデータの記述を記憶させる必要を低減させ得る。

セマンティクスノードは、セマンティクス関連リソースを記憶して管理する。セマンティクス関連リソースは、通常、例えば、ＥＴＳＩ Ｍ２Ｍリソース等の他のリソースを記述し、ＥＴＳＩ Ｍ２Ｍリソースは、リソースツリー、すなわち、＜ＳＣＬ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞の下に記憶され、それらは、それらのセマンティクスの理解を可能にするために、それらに関連付けられたセマンティクス関連リソースを有する必要がある。一実施形態では、セマンティクス関連リソースは、３つのタイプ、すなわち、クラス、関係、およびタームのうちの１つを有し得る。このカテゴリ化は、セマンティクスウェブの現在の技法との適合性を提供し、Ｍ２Ｍシステムが既存のセマンティクス関連リソースを活用することを可能にする。

本明細書で議論されるように、セマンティクスノードは、異なるレベルが階層構造に形成されるように、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍアクセスネットワーク、およびＭ２Ｍコアネットワーク等の異なるレベルでＭ２Ｍシステムに展開され得る。同一のレベルでのセマンティクスノードは、分散され、兄弟関係を有し得る。異なるレベルの抽象化および適合性の利益を既存のネットワーク階層に提供する、セマンティクスノードのそのようなハイブリッドアーキテクチャを構築して維持することに関して、機構が開示される。

図２−図１７ならびにそれらの付随する説明は、以下で説明されるセマンティクス公表および発見のための方法、デバイス、およびシステムと関連するセマンティクスノードアーキテクチャおよびプラットフォームの実施形態のさらなる情報および理解を提供する。

効率的なセマンティクス関連リソース公表方式は、セマンティクス関連リソース発見および共有を可能にして促進することが開示されている。セマンティクスノードは、セマンティクス関連リソースを公表または非公表することによって、セマンティクス関連リソースが作成、更新、または削除されるときをその兄弟および子に知らせ得る。セマンティクスノードは、そのローカルデータベースまたはディレクトリにセマンティクス関連リソースを記憶する。これらのディレクトリは、どのセマンティクス関連リソースが記憶され、ネットワーク内で共有されることができるかを他のセマンティクスノードが把握するように交換される。他のエンティティは、セマンティクスノードからセマンティクス関連リソースを発見することができ、たとえ合致するリソースがそのローカルディレクトリの中になくても、要求を兄弟に大量送信する必要も、要求を親に転送する必要もなく、代わりに他のセマンティクスノードから公表された情報を検索することができる。以下でさらに詳細に議論されるセマンティクス関連リソース公表方式は、セマンティクス関連リソース識別子キーワードの公表と、セマンティクスノードダイジェストの公表と、ハイブリッド識別子およびダイジェストの公表とを含み得る。

以下では、セマンティクス関連リソースを記憶するセマンティクスノードを隣接セマンティクスノード（例えば、兄弟、子、または非関連セマンティクスノード）に通知するためのキーワードを含む、セマンティクス関連リソースの識別子の使用が開示される。セマンティクスノードによって記憶および管理されるセマンティクス関連リソースは、ユニバーサルリソースロケータ（ＵＲＬ）またはユニバーサルリソース識別子（ＵＲＩ）であり得る、一意の識別子を有する。セマンティクスノードに記憶されたセマンティクス関連リソースを他のセマンティクスノードに知らせるために、セマンティクス関連リソースの存在が、キーワードを使用して公表され得る。公表は、いくつかある方法の中でも、新たに作成されたセマンティクス関連リソース（または識別子）の閾値数に達したことに基づいて、またはある時間閾値後に、自動的にトリガされ得る。セマンティクスノード上のセマンティクス関連リソースの存在は、セマンティクス関連リソースの識別子、セマンティクス関連リソースのコンテンツ、またはセマンティクス関連リソースの識別子およびコンテンツを使用することによって公表され得る。

図２は、キーワードを使用するセマンティクス関連リソース識別子７１０の例示的な形式を図示する。ホストアドレス７１１は、セマンティクス関連リソースを記憶して管理する、元のセマンティクスノードのアドレスである。ホストアドレスは、ＩＰアドレス、ＭＳＤＮ ＩＤ等であり得る。タイプ７１２は、クラス、関係、またはターム等の定義されたタイプのうちの１つであり得る、セマンティクス関連リソースのタイプである。セマンティクス関連リソース識別子７１０はまた、１つ以上のキーワードを含み得る、キーワード７１３を含み得る。

図３は、セマンティクス公表および発見と関連して本明細書で議論されるであろう、例示的なセマンティクスノードトポロジー７２０を図示する。セマンティクスノード７２３は、兄弟セマンティクスノード７２２および兄弟セマンティクスノード７２４と通信可能に接続される。セマンティクスノード７２３はまた、親セマンティクスノード７２１、子セマンティクスノード７２５、および子セマンティクスノード７２６と通信可能に接続される。兄弟セマンティクスノード７２４はまた、任意のコンピュータデバイスであり得る、ユーザ機器（ＵＥ）７２７と通信可能に接続され得る。

図３を続けて参照すると、以下は、キーワードを使用する公表に関する例示的なシナリオである。セマンティクスノード７２３は、表１に示されるような、その上に記憶されたいくつかのセマンティクス関連リソースを有し得る。各記憶されたセマンティクス関連リソースは、表１に示されるような識別子を有し得る。表１の各識別子は、図２に示される識別子形式による、「セマンティクスノード７２３」というホストアドレス、および「クラス」というタイプを有する。表１では、識別子に対するキーワードは、行１内の識別子に対して「温度」および「摂氏」、行２内の識別子に対して「湿度」、行３の識別子に対して「トレッドミル」、および行４の識別子に対して「血圧」である。

図４は、表１の４つのセマンティクス関連リソースを１つの集約識別子に集約する例示的な集約識別子形式を図示し、集約識別子は、公表メッセージを介して１つ以上の他のセマンティクスノードに伝送される。セマンティクスノード７２３は、（図２の形式に従って）表１に類似する様式で別々に識別子を公表するか、または図４に示されるように、キーワードを公表メッセージ内の単一のキーワード（例えば、集約識別子）に集約し得る（例えば、Ｓｅｍａｎｔｉｃｓ Ｎｏｄｅ ７２３．ｃｌａｓｓ．ｔｅｍｐｅｒａｔｕｒｅ．Ｃｅｌｓｉｕｓ；ｈｕｍｉｄｉｔｙ；ｔｒｅａｄｍｉｌｌ；ｂｌｏｏｄｐｒｅｓｓｕｒｅ）。集約識別子を含む公表メッセージが使用されるとき、公表メッセージを受信するセマンティクスノードに、集約識別子の各識別子を抽出または解析する方法を示す、セミコロン等の異なるインジケータがあり得る。

図２を参照すると、セマンティクス関連リソース識別子７１０の長さをさらに短縮するために、各タイプは、各セマンティクスノードに普遍的に知られ得る、標識を有し得る。例えば、クラスは、標識「１」を有し得、関係は、標識「２」を有し得、タームは、標識「３」を有し得る。

キーワードは、同一のタイプを伴う複数のセマンティクス関連リソースに合致し得るが、セマンティクス関連リソースを区別し得る追加の別個のキーとなるワードを伴う。例えば、クラスｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇは、ｔｅｍｐというキーワードを有し得、クラスｔｅｍｐｅｒａｔｕｒｅＩｎＣは、温度（ｔｅｍｐｅｒａｔｕｒｅ）および摂氏（ＩｎＣ）のキーワードを有し得、クラスｔｅｍｐｅｒａｔｕｒｅＩｎＦは、温度（ｔｅｍｐｅｒａｔｕｒｅ）および華氏（ＩｎＦ）のキーワードを有し得る。キーワードは、複数のセマンティクス関連リソースを異なるタイプと合致させ得る。例えば、関係タイプｈａｓＣｏｒｅＴｅｍｐｅｒａｔｕｒｅは、温度というキーワードとともに選択され得、タームタイプ摂氏も、温度というキーワードとともに選択され得る。ホストセマンティクスノードは、キーワードを選択し得る。

加えて、セマンティクスノードを公表するためのセマンティクスノードアドレスが、それによって公表されるセマンティクス関連リソースに対して同一であるため、送信された公表メッセージ内の識別子は、含まれるタイプおよびキーワードのみを有し、ホストアドレスを有しないこともある（例えば、ｔｙｐｅ１．ｋｅｙｗｏｒｄ１）。公表メッセージを受信するセマンティクスノードは、ホストアドレスが識別子に含まれないとき、ＩＰまたはＭＡＣ層情報に基づいてホストアドレスをその受信した識別子のテーブルに追加し得る（例えば、ｈｏｓｔ１．ｔｙｐｅ１．ｋｅｙｗｏｒｄ１）。

図５は、図３との関連でセマンティクス関連リソースの識別子を公表する例示的方法を図示する。ステップ７３１では、セマンティクスノード７２３が、各タイプ（例えば、クラス、関係、またはターム）に対するセマンティクス関連リソースの数を記録し得る。セマンティクス関連リソースの数は、セマンティクスノード７２３が特定のセマンティクスノードまたは複数のセマンティクスノードを最後に公表したとき以降に追加されたセマンティクス関連リソースの総数であり得る。ステップ７３２では、セマンティクスノード７２３が、セマンティクス関連リソースの閾値量に達したかどうかを決定し得る。閾値量は、１つの特定のタイプ（例えば、クラス）、またはタイプの任意の組み合わせに基づき得る。閾値量に達した場合、ステップ７３３で、セマンティクスノード７２３は、セマンティクスノード７２３の追加されたセマンティクス関連リソースに対応するキーワードの全てまたはいくつかを連結させ得る。ｔｅｍｐに対するｔｅｍｐｅｒａｔｕｒｅ等の連結されたキーワードは、公表された識別子とともに、またはその代わりに含まれ得る（例えば、Ｃｌａｓｓ．ｔｅｍｐｅｒａｔｕｒｅ．ｔｅｍｐまたはＣｌａｓｓ．ｔｅｍｐ）。ステップ７３４では、セマンティクスノード７２３が、タイプにステップ７３１の数えられたセマンティクス関連リソースの適切なキーワードを取り付ける。ステップ７３５では、セマンティクスノード７２３が、図２または図４に類似する形式で識別子情報を含み得る、公表メッセージを作成する。公表メッセージは、ステップ７３４の情報を含む。

続けて図５を参照すると、ステップ７３６では、セマンティクスノード７２３が、任意の子セマンティクスノードがあるかどうかを決定する。ステップ７３７では、子セマンティクスノード７２５および子セマンティクスノード７２６があるため、ステップ７３５の公表メッセージは、子セマンティクスノード７２５および子セマンティクスノード７２６に送信される。ステップ７３８では、セマンティクスノード７２３が、任意の兄弟セマンティクスノードがあるかどうかを決定する。セマンティクスノード７２３は、図３に示されるような兄弟セマンティクスノード７２２および７２４を有する。ステップ７３９では、兄弟ノードがあるため、セマンティクスノード７２３が、公表メッセージの伝搬を制限するためにホップ制限（例えば、１または２）を設定し得る。ホップ制限は、識別子を含む公表メッセージに含まれ得る。ステップ７４０では、セマンティクスノード７２３が、公表メッセージをその兄弟に送信する。公表メッセージは、アプリケーショントランスポートプロトコル（例えば、ＨＴＴＰまたはＣｏＡＰ）を使用して送信され得る。

図５およびその付随する説明は、公表シナリオについて議論するものの、非公表シナリオが同一または類似方法で稼働し得るが、新たに除去されたセマンティクス関連リソースの数が、非公表にするトリガ（例えば、識別子を除去する命令）として使用され得る。セマンティクスノード７２２等のセマンティクスノードは、その兄弟（例えば、セマンティクスノード７２３）または親（例えば、セマンティクスノード７２１）から公表メッセージを受信すると、同一のタイプの公表されたセマンティクス関連リソースの識別子（例えば、表１に類似する）を構築するように、タイプフィールドおよびキーワードを抽出する。

図６は、セマンティクス関連リソースを発見する例示的方法を図示する。ステップ７５１では、兄弟セマンティクスノード７２４が、セマンティクスノード７２３から公表メッセージを受信し得る。公表メッセージは、他のセマンティクスノードならびにセマンティクスノード７２３上に位置するセマンティクス関連リソースに対する、セマンティクスノード１２３上に位置する全ての識別子（または識別子の更新）を含み得る。セマンティクスノード７２４は、識別子を記憶し得る。ステップ７５２では、兄弟セマンティクスノード７２４が、ＵＥ７２７からセマンティクス関連リソースに対する要求を受信し得る。ステップ７５３では、兄弟セマンティクスノード７２４が、要求されたセマンティクス関連リソースがローカルに記憶されていないことを決定する。ステップ７５４では、兄弟セマンティクスノード７２４が、セマンティクス関連リソースをローカルで見出せないとき、ステップ７５１で受信された識別子等のその受信した識別子を検索する。ステップ７５５では、兄弟セマンティクスノード７２４が、ステップ７５２の受信した要求に合致するキーワードおよびタイプを有する識別子を見出す。例証目的で、識別子は、セマンティクスノード７２３に対応する。ステップ７５６では、兄弟セマンティクスノード７２４が、セマンティクスノード７２３のアドレスをＵＥ７２７に転送し得る。代替として、兄弟セマンティクスノード７２４は、セマンティクスノード７２３から１つ以上の合致セマンティクス関連リソースのコピーを要求し、合致セマンティクス関連リソースをローカルに記憶し、セマンティクス関連リソースでＵＥ７２７に応答し得る。別の実施形態では、元の要求は、セマンティクスノード７２３に転送され得、セマンティクスノード７２３は、ＵＥ７２７に直接応答し得る。

図７は、修正された応答を含む、セマンティクス関連リソースの発見および検証のための例示的なコールフロー７６０を図示する。ステップ７６１では、ＵＥ７２７が、セマンティクス関連リソースに対する要求（すなわち、セマンティクス関連リソース発見要求）をセマンティクスノード７２４に送信する。要求は、タイプと、１つ以上のキーワードとを含む。ステップ７６２では、セマンティクスノード７２４が、要求を処理し、識別子に対応するキーワードに基づいて、別のセマンティクスノード（セマンティクスノード７２３）がステップ７６１の要求に合致するセマンティクス関連リソースを有することを発見する。ステップ７６３では、セマンティクスノード７２３が、ステップ７６２で見出された識別子をＵＥ７２７に送信する。ステップ７６４では、ＵＥ７２７が、ステップ７６３の受信した識別子を処理する。ステップ７６５では、ＵＥ７２７が、要求（例えば、ステップ７６１に類似する要求）を送信し、ＵＥ７２７が、要求に合致する応答を受信する。

続けて図７を参照すると、ステップ７６６では、ＵＥ７２７が、ステップ７６５で受信されるセマンティクス関連リソースの表現をチェックする。例えば、ＵＥ７２７が、温度クラスを要求し得、返信された合致セマンティクス関連リソースは、華氏の関連単位を伴うｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇと呼ばれるクラスであり得る。ＵＥ７２７は、華氏よりも摂氏という単位を伴う温度クラスを好み得るが、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスの他のフィールドを容認し得る。ステップ７６７で、ＵＥ７２７が、セマンティクスノード７２３にセマンティクス関連リソース修正要求を送信し得る。ステップ７６８で、セマンティクスノード７２３が、新しいクラスを追加することによって、または摂氏という単位を反映するように現在のクラスを拡張することによって、クラスをローカルで修正し得る。ステップ７６９で、新たに追加または修正されたセマンティクス関連リソースの識別子が、ＵＥ７２７に返信される。表２は、デバイス間で送信され得る、発見に関連する例示的メッセージを示す。

表３および表４は、それぞれ、セマンティクス関連リソース識別子公表およびセマンティクス関連リソース発見から発生する、ネットワーク、ソースセマンティクスノード、および兄弟／親セマンティクスノードへのオーバーヘッドを示す。表３および表４から、ネットワーク帯域幅が別個／累積識別子の公表メッセージをトランスポートする際に主に使用され、発見プロセスがソース／要求されたセマンティクスノードとその兄弟／親との間で余分なオーバーヘッドを引き起こさないことを観察することができる。ソース／要求されたセマンティクスノードは、それ自体および公表されたリソースによってホストされる、そのローカルで維持されたセマンティクス関連リソースディレクトリを検索し、合致した識別子を直接返信することができる。

以下では、ネットワークへの全識別子公表と比較して、ネットワークオーバーヘッドを低減させ得る、セマンティクスノード内の記憶されたセマンティクス関連リソースを公表する、セマンティクスノードダイジェスト機構が開示される。セマンティクスダイジェストは、セマンティクス関連リソースを公表するための記憶装置が１ビット程度と小さくあり得るように、ブルームフィルタを使用し得る。ブルームフィルタは、メンバーシップクエリ（すなわち、「要素Ｘが集合Ｙの中にあるか？」と尋ねるクエリ）をサポートするために、集合の確率的表現のためのコンパクトデータ構造である。ブルームフィルタがコンパクトな表現を可能にするが、トレードオフは、メンバーシップクエリにおけるわずかな誤検出率であり、すなわち、クエリが、要素を集合のメンバーとして誤って認識する場合がある。

ブルームフィルタは、パラメータＫおよびＮによって定義される。Ｋ個の独立ハッシュ関数、およびＭビットのアレイがあり得る。ブルームフィルタのビットは、Ｎ個のキーワードの集まり（フィルタに入れられるであろうアイテムの最大数）を符号化するために使用される。公表されたセマンティクスノードダイジェストは、セマンティクスノードに記憶されたセマンティクス関連リソースのキーワードの集まりを含む。

以下は、表１のセマンティクス関連リソース識別子を使用して、どのようにしてブルームフィルタが利用され得るかの実施例である。Ｋ、すなわち、ハッシュ関数の数は、本実施例では３であり得る。Ｋが３である場合、表１の４つのセマンティクス関連リソース識別子のキーワードに対して使用されるであろう、３つのハッシング関数（例えば、ｆ（ｘ）、ｇ（ｘ）、およびｈ（ｘ））があろう。各ハッシング関数は、各識別子のハッシュ値を生成し得る。各ハッシュ値は、オンにされるべきブルームフィルタ内のビットを表す。Ｍは、ブルームフィルタのアレイ内のビット数である。Ｍは、ハッシュ関数の範囲より小さくなるべきであり、そうでなければ、いくつかのビットがオンにされないことがある。本実施例については、Ｍは１６である。Ｎは、キーワードの数である。我々の実施例では、Ｎは、全ての識別子に対して全キーワードの最大数である。Ｍ、Ｋ、およびＮは、ユーザ選好に基づいて決定されるか、またはセマンティクスノード７２３によって自動的に決定され得る。誤検出の確率は、方程式（１）によって決定され得る。アレイの最適なサイズ（Ｍ）およびハッシュ関数の最適な数（Ｋ）は、それぞれ、方程式２および方程式３に基づいて決定され得る。

よって、我々の実施例では、キーワード「温度（ｔｅｍｐｅｒａｔｕｒｅ）」および表１の他のキーワードは、ハッシュ関数を通して処理され、表５に示されるように、３つの結果を有するであろう。ハッシュ関数（例えば、ｆ（ｘ）、ｇ（ｘ）、ｈ（ｘ））の結果は、各ハッシュ関数を通過するキーワードの結果に基づいてオンにされる位置である。結果として、１６ビットブルームフィルタは、０１１０１１１１ １１００１１１１のようになるであろう。ビット５、６、１３、および１５は、オフであるため、ゼロのままである。

表８は、図３との関連でダイジェストを使用して公表する例示的方法を図示する。ステップ７７１では、セマンティクスノード７２３が、各タイプ（例えば、クラス、関係、またはターム）に対するセマンティクス関連リソースの数を記録し得る。セマンティクス関連リソースの数は、セマンティクスノード７２３がブルームフィルタを特定のセマンティクスノードまたは複数のセマンティクスノードに最後に伝搬したとき以降に追加された、セマンティクス関連リソースの数であり得る。ステップ７７２では、セマンティクスノード７２３が、セマンティクス関連リソースの閾値量に達したかどうかを決定し得る。閾値量は、１つの特定のタイプ（例えば、クラス）、またはタイプの任意の組み合わせに基づき得る。

閾値量に達した場合、ステップ７７３では、セマンティクスノード７２３が、公表されるべき全てのセマンティクス関連リソースに対する全てのキーワードをコンパイルし得る。ステップ７７４では、セマンティクスノード７２３は、方程式１、方程式２、または方程式３に基づいて、ＫおよびＭを決定し得る。ステップ７７５では、セマンティクスノード７２３が、全てのキーワードにハッシュ関数を使用する。ステップ７７６では、ハッシュ値がＭより大きい場合、モジュロ演算子がステップ７７５のハッシュ関数値に適用され得る。モジュロを適用することは、ハッシュ値をＭの範囲内に保つ。ステップ７７７では、セマンティクスノード７２３が、ダイジェストメッセージを作成するように、ステップ７７５またはステップ７７６の結果に基づいて、対応する位置でビットをオンにする。ダイジェストメッセージは、ブルームフィルタ、ホストアドレス、ならびにステップ７７５で処理されたキーワードに関連付けられているクラスを含み得る。

続けて図８を参照すると、ステップ７７８では、セマンティクスノード７２３が、任意の子セマンティクスノードがあるかどうかを決定する。ステップ７７９では、子セマンティクスノード７２５および子セマンティクスノード７２６があるため、ステップ７７７のダイジェストメッセージ（すなわち、ブルームフィルタを含むメッセージ）が、子セマンティクスノード７２５および子セマンティクスノード７２６に送信される。ステップ７８０では、セマンティクスノード７２３が、任意の兄弟セマンティクスノードがあるかどうかを決定する。セマンティクスノード７２３は、図３に示されるような兄弟セマンティクスノード７２２および７２４を有する。ステップ７８１では、セマンティクスノード７２３が、ダイジェストメッセージの伝搬を制限するためにホップ制限（例えば、１、２、またはそれを上回る）を設定し得る。ステップ７８２では、セマンティクスノード７２３が、ダイジェストメッセージをその兄弟に送信する。ダイジェストメッセージは、アプリケーショントランスポートプロトコルを使用して送信され得る。ブルームフィルタは、ハッシュ関数とともに、最初に各セマンティクスノードに公表されるであろう。後の更新で、ハッシュ関数は、同一のままである場合は、公表される必要がないであろう。

非公表は、図８で図示される様式と同様であるが、適切な値をゼロに設定することによって行われ得る。非公表に対して、セマンティクスノードは、フィルタ内でそれらの存在を確認するために他のキーワードがビットを必要としないならば、そのビットをゼロに設定するのみであろう。例えば、摂氏が除去された場合、ビット３は、温度の存在を確認するために使用されるので、ビット２または４のみがゼロに設定されるであろう。加えて、非公表または公表は、記憶されたハッシュ関数を使用して、新しいブルームフィルタを作成することによって、以前のブルームフィルタをローカルで更新することを含み得る。新しいブルームフィルタは、次いで、他のセマンティクスノードに伝搬させられ得、それらの現在のブルームフィルタを置き換えるために使用され得る。

図９は、ブルームフィルタを使用してセマンティクス関連リソースを発見する例示的方法を図示する。ステップ７９１では、兄弟セマンティクスノード７２４が、セマンティクスノード７２３からダイジェストメッセージを受信し得る。ダイジェストメッセージは、初期通信において、またはハッシュ関数がセマンティクスノード７２３によって変更された場合、ハッシュ関数とともにブルームフィルタを有し得る。セマンティクスノード７２４は、ハッシュ関数とともにブルームフィルタを記憶し得る。ステップ７９２では、兄弟セマンティクスノード７２４が、ＵＥ７２７から、セマンティクス関連リソースに対するキーワードを含む要求を受信し得る。ステップ７９３では、兄弟セマンティクスノード７２４が、要求されたセマンティクス関連リソースがローカルに記憶されていないことを決定する。ステップ７９４では、兄弟セマンティクスノード７２４がセマンティクス関連リソースをローカルで見出すことができないとき、ステップ７９２の受信したキーワードに対してハッシュ関数を使用し、それをローカルに記憶されたブルームフィルタと比較する。ステップ７９５では、兄弟セマンティクスノード７２４が、１つ以上のブルームフィルタの位置がステップ７９４のハッシュ化値に合致することを見出す。例証目的で、ブルームフィルタは、セマンティクスノード７２３に対応する。ステップ７９６では、兄弟セマンティクスノード７２４が、セマンティクスノード７２３のアドレスをＵＥ７２７に転送し得る。代替として、兄弟セマンティクスノード７２４は、セマンティクスノード７２３から１つ以上の合致セマンティクス関連リソースのコピーを要求し、合致セマンティクス関連リソースをローカルに記憶し、セマンティクス関連リソースでＵＥ７２７に応答し得る。別の実施形態では、元の要求は、セマンティクスノード７２３に転送され得、セマンティクスノード７２３は、ＵＥ７２７に直接応答し得る。

表６および表７は、それぞれ、セマンティクス関連リソース識別子公表およびセマンティクス関連リソース発見から発生し得る、ネットワーク、ソースセマンティクスノード、および兄弟／親セマンティクスノードへのオーバーヘッドを示す。ダイジェストメッセージ（ブルームフィルタ）のトランスポートで使用される帯域幅は、本明細書で議論されるように、図５および図６のセマンティクス発見識別子公表メッセージより有意に小さくあり得る。上記で議論されるように、ブルームフィルタにおける誤検出合致により、メッセージが要求されたセマンティクス関連リソースを含まないセマンティクスノードに送信された場合、ネットワーク帯域幅が非効率的に使用される時間があり得る。

以下では、図３との関連でセマンティクスノードダイジェストのＲＥＳＴｆｕｌ実施形態が議論される。要約すると、本明細書に記載されるいくつかの実施形態は、ＲＥＳＴアーキテクチャ（ＲＥＳＴｆｕｌアーキテクチャ）の制約に一致する、説明される構成要素およびエンティティを伴う、表現状態転送（ＲＥＳＴ）アーキテクチャに関連して説明される。ＲＥＳＴｆｕｌアーキテクチャは、物理的構成要素実装または使用される通信プロトコルに関連するよりもむしろ、アーキテクチャで使用される構成要素、エンティティ、コネクタ、およびデータ要素に適用される制約に関連して説明される。当業者であれば、本開示の範囲内にとどまりながら、本実施形態の実装が変動し得ることを認識するであろう。

図１０に示されるようなフィルタ８０１（すなわち、ブルームフィルタ）リソース構造は、セマンティクスノードダイジェストを記憶する。セマンティクスノード７２４上のタイプ（例えば、クラス、関係、またはターム）で最新のセマンティクス関連リソースを示す、フィルタ８０１の下に記憶された、複数のフィルタインスタンス＜ｆｉｌｔｅｒ＞８０２があり得る。例えば、フィルタリソースは、更新されたときに交換される。＜ｆｉｌｔｅｒ＞８０２の属性８０３は、タイプ、ｎｏｆＡｒｒａｙＢｉｔｓ、ｎＯｆＫｅｙｓ、およびｎＯｆＨａｓｈを含む。タイプは、フィルタが表すセマンティクス関連リソースディレクトリのタイプである。ｎＯｆＡｒｒａｙＢｉｔｓは、フィルタ内のアレイビットの数（Ｍ）である。ｎＯｆＫｅｙｓは、フィルタによって表されるキーワードの数（Ｎ）である。ｎＯｆＨａｓｈは、フィルタを生成するために使用されるハッシュ関数の数（Ｋ）である。

ｈａｓｈＦｕｎｃｔｉｏｎｓリソース８０５は、ブルームフィルタを生成するために使用されるＫ個のハッシュ関数を記憶する。セマンティクスノード７２４はまた、図１１および図１２に示されるように、セマンティクスノードダイジェスト８１１およびセマンティクスノードダイジェスト８１５も記憶する。親セマンティクスノード７２１および兄弟セマンティクスノード７２３等の兄弟および親は、セマンティクスノードダイジェスト８１１およびセマンティクスノードダイジェスト８１５を公表する。ｆｉｌｔｅｒＣｏｎｔｅｎｔリソース８０６は、１６ビットブルームフィルタ（例えば、０１１０１１１１ １１００１１１１）を伴う上記の実施例等のブルームフィルタのビットを含む。

セマンティクスノードダイジェストがＲＥＳＴｆｕｌ方法で記憶されると、兄弟および子に公表されるだけでなく、他のホストによって積極的に読み出され得る。例えば、図１３に示されるように、セマンティクスノード８２２は、セマンティクスノード８２１およびセマンティクスノード８２３に対して兄弟であるが、セマンティクスノード８２１とセマンティクスノード８２３とは、兄弟関係を有していない。セマンティクスノード８２１は、クラスフィルタをその兄弟セマンティクスノード８２２に公表する。セマンティクスノード８２２は、Ｓｅｍａｎｔｉｃｓ ｎｏｄｅ ８２２／ｓｉｂｌｉｎｇｓ／ＳｅｍａｎｔｉｃｓＮｏｄｅ８２１／ｆｉｌｔｅｒｓ／ｆｉｌｔｅｒＣｌａｓｓｏｆＳｅｍａｎｔｉｃｓＮｏｄｅ ８２１等のリソースのＵＲＩとともに、ＰＯＳＴ応答等の応答を返信する。リソース発見を通して、セマンティクスノード８２３は、セマンティクスノード８２１の公表されたフィルタの知識を有する。セマンティクスノード８２３は、発見要求に基づいて、リソースを合致させるためにフィルタを使用することができ、これは、合致セマンティクス関連リソースを見出す機会を増加させる。セマンティクスノード８２３は、発見要求をセマンティクスノード８２１に転送し得る。

以下では、ダイジェストおよび識別子メッセージ公表（または非公表）を利用するために使用され得る、ハイブリッドアプローチが議論される。ダイジェスト公表は、レベル間トラフィックを低減させるために使用され得る。例えば、セマンティクスノード７２３は、識別子を兄弟セマンティクスノードのみに公表し得る（例えば、図５のステップ７３１−７３５、７３８−７４０を参照）。セマンティクスノード７２３はまた、ダイジェストを子セマンティクスノードのみに公表し得る（例えば、図８のステップ７７１−７７９）。本明細書で議論されるような階層構造（例えば、親、兄弟、および子）に基づき得る、任意の数のハイブリッド公表／非公表アプローチがあり得る。ハイブリッドアプローチはまた、発見プロセスのために使用され得る。例えば、識別子を合致させる初期処理があり得る（例えば、図６）。そして、識別子合致を使用して見出される合致がない場合、後続の処理は、ブルームフィルタを使用して合致させようとし得る（例えば、図９）。本明細書で議論されるような階層構造（例えば、親、兄弟、および子）に基づき得る、任意の数のハイブリッド発見アプローチがあり得る。

以下では、ＣｏＲＥリンク形式およびＣｏＲＥリソースディレクトリ（ＲＤ）でのセマンティクス関連リソース公表および発見の実施形態が議論される。制約されたサーバによってホストされるリソースの発見は、ループ内に人間がおらず、静的インターフェースが脆弱性をもたらすＭ２Ｍアプリケーションにおいて重要である。ＨＴＴＰウェブサーバによって提供されるリソースの発見は、典型的には、ウェブ発見と呼ばれ、リソース間の関係の記述は、ウェブリンキングと呼ばれる（ＲＦＣ ５９８８参照）。そのような発見機構の重要な機能は、これらのリソースおよび可能なさらなるリンク関係について属性によって補完される、サーバによってホストされるリソースのユニバーサルリソース識別子（ＵＲＩ、リンクと呼ばれる）を提供することである。

制約ＲＥＳＴｆｕｌ環境（ＣｏＲＥ）において、このリンクの集まりは、（特定のリソースとともに送達されるＨＴＴＰヘッダとは対照的に）それ自体のリソースとして搬送される。ＩＥＴＦ（例えば、ＲＦＣ ６６９０）によって定義されるＣｏＲＥリンク形式は、これらのリンク記述を表すようにＨＴＴＰリンクヘッダ形式（例えば、ＲＦＣ ５９８８）を拡張することによって、ＣｏＲＥリソース発見での使用のためのリンク形式を特定する。ＣｏＲＥリンク形式は、ペイロードとして搬送され、インターネットメディアタイプを割り当てられる。周知の相対的ＵＲＩ「／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅ」が、サーバによってホストされるリソースについてのリンクのリストを要求するため、したがって、ＣｏＲＥリソース発見を行うためのデフォルト入力点として定義される。ＣｏＲＥリンク形式は、ＲＦＣ ５９８８で特定されるＨＴＴＰリンクヘッダフィールドを拡張する。

実施形態では、セマンティクス関連リソースの提案された識別子は、本明細書で紹介されるウェブリンキングまたはＣｏＲＥリンク形式を活用し得る。‘ｋｗ’と呼ばれる新しいＣｏＲＥリンク属性が定義され得る。リソースタイプ‘ｋｗ’属性は、キーワードをセマンティクス関連リソースに関連付けるために使用される。結果として、セマンティクス関連リソースをアドレス指定する既存の識別子（例えば、ＵＲＩ／ＵＲＬ）が再利用され得るが、‘ｋｗ’属性をウェブリンキングまたはＣｏＲＥリンク形式に追加することによって、セマンティクス関連リソースが、公表され、それらに関連付けられているキーワードとともに維持される。セマンティクス関連リソース発見は、本明細書でさらに詳細に議論される、セマンティクス関連リソースのキーワードを把握することから利益を得ることができる。

ＣｏＲＥリソースディレクトリは、ウェブサーバが、ＲＤを発見するため、およびリソース記述を登録、維持、参照、および除去するために、リソースディレクトリ（ＲＤ）がサポートするウェブインターフェースを特定する。さらに、リソースディレクトリと併せて有用な新しいリンク属性が定義される。

ＲＤは、エンドポイント（ＥＰ）と呼ばれる、他のウェブサーバ上でホストされるリソースについてのウェブリンクのためのレポジトリとして使用される。ＲＤは、組のウェブリンク（リソースディレクトリエントリと呼ばれる）を登録して維持するためにエンドポイントに対する、エントリを検証するためにＲＤに対する、およびＲＤからリソースを参照するためにクライアントに対する、組のＲＥＳＴインターフェースを実装する。エンドポイント自体はまた、クライアントの役割を果たすこともできる。

リソース発見は、マルチキャストまたはユニキャストＧＥＴ要求のいずれかを／．ｗｅｌｌ−ｋｎｏｗｎ／ｃｏｒｅに送信し、クエリ文字列の中に値「ｃｏｒｅ．ｒｄ」とともにリソースタイプ（ｒｔ）パラメータを含むことによって、行われ得る。リソース公表は、リソース登録によって行われ得る。エンドポイントからのＰＯＳＴは、エンドポイントの名前、そのドメイン、および登録の寿命を示す、クエリ文字列パラメータとともに、ＣｏＲＥリンク形式でのメッセージペイロードとして、ディレクトリに追加されるべきリソースのリストを含む。

セマンティクスノードは、その兄弟および子ノードをＲＤと見なし得、そこで、そのセマンティクス関連リソースを公表し得る。これを可能にするために、セマンティクスノードは、ＰＯＳＴをＲＤ（その兄弟および子）に送信し得る。本明細書では、セマンティクス関連リソース識別子の公表、セマンティクスノードダイジェストの公表、ならびにハイブリッド識別子およびダイジェスト公表のためのＣｏＲＥリンク形式方法が議論される。３つ全てのセマンティクス関連リソース公表をサポートするために、公表方法（ｐｍ）と呼ばれる、１つのＵＲＩテンプレート変数が、ＣｏＲＥ ＲＤリソース登録要求インターフェースに追加され得る。ｐｍは、異なる公表またはダイジェスト方法を示すように、特定の値（例えば、０、１、または２）に設定され得る。ハイブリッドアプローチは、ＲＤが兄弟または子であるときに異なってｐｍが設定されるときに採用される（ｐｍ＝ＲＤが兄弟であるときには識別子、ｐｍ＝ＲＤが子であるときにはダイジェスト）。ｐｍは、他の公表方法のために拡張可能であり得る。

図１４は、本明細書で議論されるように、識別子を公表するためのＰＯＳＴメッセージの例示的な使用を図示する。ステップ８４３では、セマンティクスノード８４１（すなわち、ＥＰ）が、ｐｍ＝識別子および他の関連情報とともに、ＰＯＳＴメッセージをセマンティクスノード８４２（すなわち、ＲＤ）に送信する。セマンティクスノード８４２は、兄弟、子等の任意のタイプのセマンティクスノードであり得、または正式な階層関係を有していないこともある。ステップ８４４では、セマンティクスノード８４２が、ステップ８４３の情報がセマンティクスノード８４２上に記憶されていることを確認する応答をセマンティクスノード８４１に送信し得る。図１５は、本明細書で議論されるようなダイジェストメッセージを公表するためのＰＯＳＴメッセージの例示的な使用を図示する。ステップ８４５では、セマンティクスノード８４１（すなわち、ＥＰ）が、ｐｍ＝ダイジェストおよび他の関連情報とともに、ＰＯＳＴメッセージをセマンティクスノード８４２（すなわち、ＲＤ）に送信する。セマンティクスノード８４２は、兄弟、子等の任意のタイプのセマンティクスノードであり得るか、または正式な階層関係を有していないこともある。ステップ８４６では、セマンティクスノード８４２が、ステップ８４５の情報がセマンティクスノード８４２上に記憶されていることを確認する応答をセマンティクスノード８４１に送信し得る。

図１６は、本明細書で議論されるように、ハイブリッドアプローチを公表するためのＰＯＳＴメッセージの例示的な使用を図示する。ステップ８４７では、セマンティクスノード８４１が、ｐｍ＝ダイジェストおよび他の関連情報とともに、ＰＯＳＴメッセージをセマンティクスノード８４２（すなわち、ＲＤ）に送信するのみであり得る。本実施例に対して、セマンティクスノード８４２は、子セマンティクスノードであり得る。ステップ８４８では、セマンティクスノード８４１は、ｐｍ＝識別子および他の関連情報とともに、ＰＯＳＴメッセージをセマンティクスノード８４３（すなわち、ＲＤ）に送信するのみであり得る。本実施例に対して、セマンティクスノード８４０は、兄弟セマンティクスノードのみであり得る。

図１７は、セマンティクス関連リソース発見のための例示的なＧＥＴメッセージを例証する。セマンティクス関連リソース発見は、ＧＥＴ要求によって行われ得る。本明細書で議論されるように、クラス、関係、またはターム等のセマンティクス関連リソースタイプがあり得る。「ｋｗ」属性（キーワード属性）を設定することによって、キーワードに合致するセマンティクス関連リソースが発見され得る。ステップ８５１では、セマンティクスノード８４１が、「ｔｅｍｐ」のｋｗとともに、取得コマンドを送信する。ステップ８５２では、セマンティクスノード８４２が、セマンティクスノード８４１にタイプクラスのセマンティクス関連リソースｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇを送信する。

上記は、セマンティクス関連リソースの公表および発見のための複数の技法である。セマンティクス関連リソース公表および発見の標的は、兄弟および子として例証されるが、セマンティクスノードは、そのような関係を有していない場合がある、公表および発見のための他のセマンティクスノードを選択し得る。クラス、関係、およびターム等の本明細書で議論されるセマンティクス関連リソースのタイプは、前述のタイプに限定されるべきではない。

本明細書で議論されるように、いったん新しいセマンティクス関連リソースが作成されるか、または古いセマンティクス関連リソースがセマンティクスノードから除去されると、セマンティクスノードは、公表／非公表メッセージを兄弟セマンティクスノードおよび子セマンティクスノードに送信し得る。これらのメッセージは、ＨＴＴＰまたはＣｏＡＰ、ならびにその他等の１つ以上の既存のプロトコルに結び付けられ得る。そうするために、ＨＴＴＰまたはＣｏＡＰ等のプロトコルは、公表／非公表メッセージを搬送するための基礎的トランスポートプロトコルとして使用され得る。公表／非公表メッセージは、ＨＴＴＰ／ＣｏＡＰメッセージのペイロード内にカプセル化され得るか、または代替として、公表／非公表メッセージ内の一部の情報は、ＨＴＴＰ／ＣｏＡＰヘッダおよび／またはオプション内のフィールドに結び付けられ得る。例えば、一実施形態では、公表／非公表メッセージは、ＨＴＴＰまたはＣｏＡＰ要求のペイロードで搬送される、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）または拡張マークアップ言語（ＸＭＬ）記述として符号化され得る。そのような類似実施形態はまた、前述または以下の開示された方式でのセマンティクス関連リソース公表／非公表メッセージ、ならびに対応するセマンティクス関連リソース発見要求および応答メッセージにも適用される。

上記では、セマンティクス公表および発見を構築および維持することに関する機構が議論される。以下は、セマンティクスノードアーキテクチャに関するさらなる詳細である。セマンティクス概念は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）として知られている国際規格団体によって先導される協調的な動きである、セマンティクスウェブの分野で一般的に知られている。本規格は、ワールドワイドウェブ上の共通データ形式を推進する。ウェブページに意味コンテンツを含むことを促すことによって、セマンティクスウェブは、非構造化および半構造化文書によって支配されている現在のウェブを「データのウェブ」に変換することを目指す。セマンティクスウェブスタックは、Ｗ３Ｃのリソースディスクリプションフレームワーク（ＲＤＦ）をもとにする。

種々の実施形態では、以下の機能性がセマンティクスノード上で有効化され得、すなわち、（ｉ）セマンティクスノードによって管理されるセマンティクス関連リソースは、発見され、読み出され、有効にされることが可能である、（ｉｉ）セマンティクスノードは、他のノードによって発見され得、セマンティクス関連リソースもまた、加入機構を用いて発見され得る、（ｉｉｉ）セマンティクス関連リソースがセマンティクス情報を提供され、普遍的に理解されるように、セマンティクス関連リソースは、Ｍ２Ｍシステム内のリソースと結び付けられ、関連付けられ得る、（ｉｖ）セマンティクス関連リソースは、効率的な発見および容易なアクセスの目的で、階層内の他のセマンティクスノードにプッシュ配信され得る、（ｖ）セマンティクス関連リソースの関連および結び付きは、記述されているセマンティクス関連リソースのセマンティクス類似性およびグループ化に基づいて最適化され得る、（ｖｉ）セマンティクス関連リソースは、データの移動とともに、１つのセマンティクスノードから別のセマンティクスノードへ移動させられ得る。

以降で説明される一実施形態では、セマンティクスノードは、ＥＴＳＩ Ｍ２Ｍ／ｏｎｅＭ２Ｍアーキテクチャのサービス能力層（ｘＳＣＬ）で実装される。別の実施形態では、セマンティクスノードは、３ＧＰＰマシン型通信（ＭＴＣ）アーキテクチャのサービス能力サーバ（ＳＣＳ）で実装される。

（Ｍ２Ｍアーキテクチャ）
図３４は、そのＴＳ １０２ ６９０においてＥＴＳＩによって定義されるＥＴＳＩ Ｍ２Ｍアーキテクチャを実装する、通信システム１２０を図示する略図である。この略図は、本開示の理解を支援するために使用され、本明細書で開示される主題の説明を促進するように簡略化されていることに留意されたい。図２に示されるように、システム１２０は、ネットワークドメイン１２２、ネットワークドメイン１３０、ネットワークドメイン１３５、およびネットワークドメイン１３８等の複数のネットワークドメインを備え得る。各ネットワークドメインは、ＮＳＣＬ１２６、ＮＳＣＬ１３１、ＮＳＣＬ１３６、およびＮＳＣＬ１３９等のネットワークサービス能力層（ＮＳＣＬ）を含み得る。各ＮＳＣＬは、ネットワークドメイン１２２およびネットワークドメイン１３０内のネットワークアプリケーション１２７およびネットワークアプリケーション１３２等のそれぞれのネットワークアプリケーションと連動し得る。

さらに示されるように、ネットワークドメイン１２２等のネットワークドメインはさらに、（例えば、図１の患者監視アプリケーションで使用されるＭ２Ｍデバイスのうちの１つであり得る）デバイス１４５等の１つ以上のデバイスと、ゲートウェイ１４０等の１つ以上のゲートウェイとを備え得る。３ＧＰＰ用語では、デバイスおよびゲートウェイは、ＵＥの実施例である。示されるように、デバイス１４５は、アーキテクチャによって定義されるｍＩｄ基準点を経由してＮＳＣＬ１２６と通信する、デバイスサービス能力層（ＤＳＣＬ）１４６を実行し得る。デバイスアプリケーション（ＤＡ）１４７もまた、デバイス１４５上で作動し得、ｄＩａ基準点を経由してＤＳＣＬ１４６と通信し得る。同様に、ゲートウェイ１４０は、ｍＩｄ基準点を経由してＮＳＣＬ１２６と通信するゲートウェイサービス能力層（ＧＳＣＬ）１４１を実装し得る。ゲートウェイ１４０上で作動するゲートウェイアプリケーション（ＧＡ）１４２は、ｄＩａ基準点を経由してＧＳＣＬ１４１と通信し得る。一般に、ｄＩａ基準点は、デバイスおよびゲートウェイアプリケーションがそれぞれのローカルサービス能力（すなわち、それぞれ、ＤＳＣＬまたはＧＳＣＬで利用可能なサービス能力）と通信することを可能にする。ｍＩｄ基準点は、Ｍ２Ｍデバイス（例えば、ＤＳＣＬ１４６）またはＭ２Ｍゲートウェイ（例えば、ＧＳＣＬ１４１）に常駐するＭ２ＭＳＣＬが、ネットワークドメイン内のＭ２Ｍサービス能力（例えば、ＮＳＣＬ１２６）と通信することを可能にし、その逆も同様である。

依然として図２をさらに詳細に参照すると、ＮＳＣＬ１２６は、ドメイン１２２内にあり、Ｍ２Ｍサーバプラットフォーム１２５上にネットワークアプリケーション（ＮＡ）１２７を伴って構成され得る。ＮＡ１２７およびＮＳＣＬ１２６は、基準点ｍＩａ１２８を介して通信し得る。ｍＩａ基準点は、ＮＡが、Ｍ２Ｍドメイン内のＮＳＣＬから利用可能なＭ２Ｍサービス能力にアクセスすることを可能にし得る。

典型的には、デバイス１４５、ゲートウェイ１４０、およびＭ２Ｍサーバプラットフォーム１２５は、図２６Ｃおよび図２６Ｄで図示され、以下で説明されるデバイス等のコンピュータデバイスを備えている。ＮＳＣＬ、ＤＳＣＬ、ＧＳＣＬ、ＮＡ、ＧＡ、およびＤＡエンティティは、典型的には、システム１２０においてそれぞれの機能を果たすように、基礎的なデバイスまたはプラットフォーム上で実行される、ソフトウェアの形態で実装される論理エンティティである。

図２でさらに示されるように、ＮＳＣＬ１３１は、ＮＡ１３２とともにドメイン１３０内にあり得る。ＮＡ１３２およびＮＳＣＬ１３１は、ｍＩａ基準点１３３を介して通信し得る。ネットワークドメイン１３５内のＮＳＣＬ１３６、およびネットワークドメイン１３８内のＮＳＣＬ１３９もあり得る。ｍＩｍ基準点１２３は、ネットワークドメイン１２２内のＮＳＣＬ１２６、ネットワークドメイン１３０内のＮＳＣＬ１３１、ネットワークドメイン１３５内のＮＳＣＬ１３６、またはネットワークドメイン１３８内のＮＳＣＬ１３９等の異なるネットワークドメイン内のＭ２Ｍネットワークノードが、互いに通信することを可能にする、ドメイン間基準点であり得る。本明細書で簡単にするために、「Ｍ２Ｍサーバ」という用語は、サービス能力サーバ（ＳＣＳ）、ＮＳＣＬ、アプリケーションサーバ、ＮＡ、またはＭＴＣサーバを示すために使用され得る。加えて、本明細書で議論される場合、ユーザ機器（ＵＥ）という用語は、ＧＡ、ＧＳＣＬ、ＤＡ、またはＤＳＣＬに適用され得る。本明細書で議論される場合、ＵＥは、移動局、固定または移動加入者ユニット、ポケットベル、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサまたはアクチュエータ、消費者電子機器等と見なされ得る。本明細書で議論される場合、マシンツーマシンサービス能力層エンティティは、Ｍ２ＭサーバまたはＵＥを含み得る。

（Ｉ．セマンティクスノードを伴うＭ２Ｍアーキテクチャ）
セマンティクスノードを含むＭ２Ｍシステムの一実施形態が、図３５で図示される。Ｍ２Ｍシステム１５０で示されるように、セマンティクスノードは、３つのレベルで展開される。エリアネットワーク１５４、エリアネットワーク１５５、エリアネットワーク１５６、およびエリアネットワーク１５７等のネットワークを含み得る、エリアレベルがあり得る。アクセスネットワーク１５２およびアクセスネットワーク１５３等のネットワークを含み得る、アクセスレベルがあり得る。そして、コアネットワーク１５１等のネットワークを含む、コアレベルがあり得る。

システム１５０に示されるように、アプリケーション１５８は、基準点ｓＩｃ１５９を介して、エリアネットワーク１５７内に位置するＭ２Ｍセマンティクスノード１６０と通信可能に接続され得る。ｓＩｃ基準点は、概して、セマンティクスノードに通信をするために、アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワークエンティティ内の他の非セマンティクスノードエンティティによって使用される。Ｍ２Ｍセマンティクスノード１６０は、基準点ｓＩｅ１６２を介して外部セマンティクスノード１６３と通信可能に接続される。Ｍ２Ｍシステム内のセマンティクスノードは、ｓＩｅ基準点を介して外部セマンティクスノードと連動し得る。外部セマンティクスノードは、セマンティクスウェブに対してＲＤＦＳによって定義されるもの等の他の既存のセマンティクス関連リソースを管理し得る。Ｍ２Ｍセマンティクスノード１６０はまた、ｓＩｓ基準点１６１を介して、アクセスネットワーク１５３内に位置するＭ２Ｍセマンティクスノード１６４と通信可能に接続される。Ｍ２Ｍセマンティクスノード１６４は、ｓＩｃ基準点１６６を介してＭ２Ｍゲートウェイ１６５と通信可能に接続され、かつ基準点ｓＩｓを介してコアネットワーク１５１内に位置するＭ２Ｍセマンティクスノード１６８と通信可能に接続される。本実施形態では、Ｍ２Ｍゲートウェイ１６５自体は、セマンティクスノードではないが、他の実施形態では、Ｍ２Ｍゲートウェイ１６５は、セマンティクスノードの機能性を組み込むことができる。

セマンティクスノードは、オフローディング、負荷バランシング、容易なアクセス等の目的で、エリアレベルで展開され得る。エリアレベルでは、ローカルエリアネットワーク内の全てのデバイスが、取り付けられたアクセスネットワーク内またはコアネットワーク内のセマンティクスノードと通信する場合、展開されたセマンティクスノードがない可能性がある。エリアレベルでのセマンティクスノードは、アクセスレベルに対応する親セマンティクスノードを有し得るか（例えば、Ｍ２Ｍセマンティクスノード１６４と接続されたＭ２Ｍセマンティクスノード１６０）、またはコアレベルに対応する親セマンティクスノードを有し得る（例えば、セマンティクスノードを含むＭ２Ｍサーバ１７０と接続されたＭ２Ｍセマンティクスノード１６９）。セマンティクスノードは、ｓＩｓ基準点を通して互に通信をする。基準点の詳細は、以降でさらに詳細に定義される。アクセスレベルでのセマンティクスノードも、それがｓＩｓ基準点を経由して通信する、コアレベルでの親を有し得る。同様に、アクセスレベルでのセマンティクスノードは、それがｓＩｓ基準点を経由して通信する、エリアレベルでの子セマンティクスノードを有し得る。コアレベルでのセマンティクスノードはまた、アクセスまたはエリアレベルで子セマンティクスノードを有し得る。

図３５で図示される親子関係に加えて、セマンティクスノードはまた、セマンティクスノードレベル（例えば、アクセス、エリア、またはコア）のうちのいずれかで兄弟の概念をサポートする。兄弟セマンティクスノードは、階層内の同一レベルでのノードであり、セマンティクスノードの負荷を分散するために使用されることができる。例えば、コアネットワーク１５１では、Ｍ２Ｍセマンティクスノード１６８は、セマンティクスノードを含むＭ２Ｍサーバ１７０と接続される。垂直な観点から、１つより多くのセマンティクスノードの確立された階層がある場合には、ノードは、互に通信をし、ｓＩｓ基準点を経由した通知、ブロードキャスト、発見等を介して、セマンティクス情報を共有することができる。

容量の制限による、制約されたデバイスに対して、セマンティクスは、特定の意味、または遠隔セマンティクスノードに記憶されたセマンティクスを指し示すリンクを指すコードであり得る。そのようなセマンティクス情報は、データを作成したアプリケーションによって、またはサービス層によって提供され得る。

アクセスレベルにおいて、１つのアクセスネットワークで展開された１つ以上のセマンティクスノードがあり得る。もしそうであれば、兄弟は、ｓＩｓ基準点を通してセマンティクス情報通知、ブロードキャスト、および発見のために互に通信し得る。アクセスレベルでのセマンティクスノードは、それがｓＩｓ基準点を経由して通信する、コアレベルでの親を有し得る。同様に、アクセスレベルでのセマンティクスノードは、それがｓＩｓ基準点を経由して通信する、エリアレベルでの子セマンティクスノードを有し得る。

コアレベルにおいて、コアネットワークで展開された１つ以上のセマンティクスノードがあり得る。これらのノードは、兄弟であり得、通知、ブロードキャスト、および発見を使用してセマンティクス情報を共有するために、ｓＩｓ基準点を経由して互に通知し得る。コアレベルでのセマンティクスノードはまた、アクセスまたはエリアレベルにおいて子セマンティクスノードを有し得る。アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワーク内の他の非セマンティクスノードエンティティは、ｓＩｃ基準点を介してセマンティクスノードに通信をする。

上記のように、セマンティクスノードは、ネットワーク内の独立型物理ノード（例えば、独立型Ｍ２Ｍセマンティクスノード１６０）であり得るか、または図３５のシステム１５０で示されるようなＭ２Ｍデバイス１７１、Ｍ２Ｍゲートウェイ１７２、またはＭ２Ｍサーバ１７０等のネットワーク内の別の物理ノード上でホストされる論理エンティティであり得る。換言すると、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、およびＭ２Ｍサーバは、セマンティクスノード機能性をサポートすることができる。

図３５で図示される多層セマンティクスノード階層の特徴は、それが異なるレベルの抽象化を提供できることである。セマンティクスノードは、エリアネットワーク特有のセマンティクス関連リソースがローカルで見出され得るように、Ｍ２Ｍエリアネットワーク内等の局所的領域中のセマンティクス関連リソースを管理することのみを担当し得る。局所的領域中で典型的ではない任意のセマンティクス関連リソースは、高レベルの親または並列の兄弟セマンティクスノードに記憶され、見出されことができる。別の特徴は、インターネット階層、場所階層等により、セマンティクス関連リソースがそれら自体で階層を有し得ることである。結果として、セマンティクスの複数の層は、既存のネットワークアーキテクチャと整合する。加えて、セマンティクスノードは、各レベルで分散され得、これは、集中型セマンティクスノードがコアネットワークのみで展開された場合の単一故障点を防止する。

（ＩＩ．セマンティクスノードアーキテクチャ）
ここで、セマンティクスノードのアーキテクチャに関するさらなる詳細について議論する。記述されるように、セマンティクスノードは、セマンティクス関連リソースを記憶して管理する。本明細書で定義される場合、セマンティクス関連リソースは、Ｍ２Ｍデバイスまたはアプリケーションによって生成されるデータ、あるいはＭ２Ｍデバイスまたはアプリケーション自体の意味等のモノのセマンティクス情報を記述するために使用することができる、情報を備えている。一実施形態では、セマンティクス関連リソースは、ＸＭＬスキーマ定義（ＸＳＤ）、ＲＤＦスキーマ／ウェブオントロジー言語（ＲＤＦＳ／ＯＷＬ）等の既存のスキーマを使用して、拡張マークアップ言語（ＸＭＬ）で表現され得る。実施形態では、３つのタイプのセマンティクス関連リソース、すなわち、それらの各々が以下でさらに完全に説明される、クラス、関係、およびタームが、セマンティクスノードに記憶され得る。このようなセマンティクス関連リソースのカテゴリ化は、セマンティクスウェブの現在の技法との適合性を提供する。この適合性は、Ｍ２Ｍシステムが、例えば、Ｗ３Ｃによって定義される、これらのコアクラスおよびコアプロパティ等の既存のセマンティクス関連リソースを活用することを可能にする。Ｍ２Ｍシステムの外部のアプリケーションおよびエンティティは、セマンティクスを適合性にするために必要な形式変換または修正による、いかなる余分なオーバーヘッドも被ることなく、セマンティクスノードによってホストされるセマンティクス関連リソースを使用することができる。

（クラス）：ここで、Ｍ２Ｍドメイン内のオブジェクト／モノのクラスの概念が議論される。図１の例示的健康監視システムでは、例えば、システムに関連するオブジェクトのクラスは、患者、医師、救急車の通信指令係、血圧、中核体温、酸素飽和度、運動加速度計等を含む。クラスは、ユニフォームリソース識別子（ＵＲＩ）またはユニフォームリソースロケータ（ＵＲＬ）によって識別され得る。クラスは、クラスを定義する情報を含む、フィールド記述を含む。例えば、摂氏単位の整数として温度データを表し、例えば、これらのセマンティクスを温度センサによって生成されるデータに提供するために使用することができる、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスは、以下のようにＸＳＤのスキーマを用いてＸＭＬで定義され得る。
＜ｓｉｍｐｌｅＴｙｐｅ ｎａｍｅ＝“ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ”＞
＜ｒｅｓｔｒｉｃｔｉｏｎ＞
ｄｅｓｃｒｉｐｔｉｏｎ ＝“ｔｅｍｐｅｒａｔｕｒｅ ｉｎ Ｃｅｌｓｉｕｓ” ｕｎｉｔ＝“Ｃｅｌｓｉｕｓ” ｂａｓｅ＝“ｉｎｔｅｇｅｒ”
＜／ｒｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓｉｍｐｌｅＴｙｐｅ＞
ここで、クラスは、“ｄｅｓｃｒｉｐｔｉｏｎ”、“ｕｎｉｔ”、および“ｂａｓｅ”というフィールドを含み、これらのフィールドの中の情報は、それぞれ、“ｔｅｍｐｅｒａｔｕｒｅ ｉｎ Ｃｅｌｓｉｕｓ”、“Ｃｅｌｓｉｕｓ”、および“ｉｎｔｅｇｅｒ”である。別の実施例として、ＢｌｏｏｄＰｒｅｓｓｕｒｅクラスは、２つのフィールド、すなわち、収縮期圧のための１つのフィールド、および拡張期圧のための別のフィールドを含み得る。このＢｌｏｏｄＰｒｅｓｓｕｒｅクラスのためのクラス記述は、両方のフィールドの記述を含み、以下のようにＸＭＬ／ＸＳＤを使用して表現され得る。
＜ｃｏｍｐｌｅｘＴｙｐｅ ｎａｍｅ＝“ＢｌｏｏｄＰｒｅｓｓｕｒｅ”＞
＜ｓｅｑｕｅｎｃｅ＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｓｙｓｔｏｌｉｃＩＮｍｍＨＧ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｄｉａｓｔｏｌｉｃＩＮｍｍＨＧ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜／ｓｅｑｕｅｎｃｅ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
しかしながら、再度、クラス（および他のタイプのセマンティクス関連リソース、すなわち、関係およびターム）は、ＸＭＬ／ＸＳＤを使用する表現に限定されないが、むしろ、例えば、ＲＤＦＳ／ＯＷＬ等を含む、種々の好適な記述言語のうちのいずれかで表現され得ることが理解される。クラスはまた、互に関係付けられ得る。例えば、「血圧」は、「生命」のサブクラスであり得、または等価的に、「生命」は、「血圧」のスーパークラスであり得る。サブクラス／スーパークラス関係は、クラスの階層を定義する。一般に、Ａの全てのインスタンスがＢのインスタンスでもある場合、ＡはＢのサブクラスである。クラスは、複数のスーパークラスを有し得る。

関係。関係は、特別な種類のセマンティクス関連リソースである。関係は、セマンティクス関連リソース間の関連、例えば、「作者」、「寿命」、「加入者」等を記述する。関係はまた、全体的な一意の命名スキームをＭ２Ｍドメインの関係に与える、ＵＲＩ／ＵＲＬによって識別することもできる。クラスおよびインヘリタンスは、計算の他の分野で、例えば、オブジェクト指向プログラミングで知られている。しかし類似点がある一方で、差異も存在する。オブジェクト指向プログラミングでは、オブジェクトクラスは、それが適用される関係またはプロパティを定義する。新しい関係またはプロパティをクラスに追加することは、クラスを修正することを意味する。しかしながら、ここでは、関係は、全体的に定義され、つまり、それらは、クラス定義における属性としてカプセル化されない。クラス自体の定義を変更することなく既存のクラスに適用される、新しい関係が定義され得る。クラスのように、関係も互に関連付けることができる。例えば、「エネルギーモード」および「使用モード」は、「モード」のサブ関係である。デバイスが電気の「エネルギーモード」および手動の「使用モード」を有する場合には、電気および手動の「モード」を有する。

（ターム）：タームは、Ｍ２Ｍドメインで一般的に使用されている概念である。本明細書で定義される場合、タームは、リソースのセマンティクスを記述するために多くの関係者によって使用され得る値である。タームの定義は、それが公表される、あるドメインで普遍的に承認され得る。例えば、手動、ユーザ指図、および自律は、それぞれ、例えば、アプライアンスの使用モードを記述するために使用され得る、タームの例である。一般に、セマンティクス関連リソースの作成者は、そのセマンティクス関連リソースが、クラス、関係、またはタームであるかどうかを決定するであろう。次いで、セマンティクスノードは、それらの作成者によって定義または決定されるカテゴリの下でセマンティクス関連リソースを記憶するであろう。例えば、図１の患者監視実施例では、セマンティクス関連リソースクラス、関係、およびタームは、血圧モニタ製造業者によって、医師によって、または別のアプライアンス製造業者によって作成され得る。他の実施例では、セマンティクス関連リソースクラス、リソース、およびタームは、垂直アプリケーションによって定義または作成され得る。

リソース（データ、モノ等を含む）のセマンティクスは、リソース、関係、および値から成る、リソース・関係・値トリプルによって記述することができる。値は、クラス、ターム、または他のリソースのいずれかであり得る。以下は、いくつかの実施例である。
・ コンテンツインスタンス（リソース）は、ｈａｓＴｙｐｅ（関係） ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ（クラス）
・ アプリケーション（リソース）は、ｈａｓＵｓａｇｅＭｏｄｅ（関係） ユーザ指図（ターム）
・ コンテンツインスタンス（リソース）は、ｇｅｎｅｒａｔｅｄＢｙＳａｍｅＡｐｐｌｉｃａｔｉｏｎＡｓ（関係）別のコンテンツインスタンス（リソース）
提案されたｓＩｃ、ｓＩｓ、およびｓＩｅ基準点を通して、セマンティクスノードのクラス、関係、およびタームリソースへの要求を行うことができる。図３６は、Ｍ２Ｍセマンティクスノードのクラス、関係、およびタームリソースの例示的説明図である。本実施例で図示されるように、セマンティクスノード４２０は、異なるアプリケーションおよびドメインからの種々のクラス４２２、関係４２４、およびターム４２６を記憶するように構成され得る。代替として、セマンティクスノード４２０は、アプライアンスセマンティクス、車両セマンティクス、医療アプリケーションセマンティクス等の一意のアプリケーションまたはドメインのためのクラス、関係、およびタームリソースを記憶するように構成され得る。

（ＩＩＩ．Ｍ２Ｍセマンティクスノード機能および基準点）
この節では、セマンティクスノードの機能および基準点に関するさらなる詳細が提供される。一実施形態では、セマンティクスノードは、以下の機能を行い得る：
他のセマンティクスノードを認証（セマンティクスノード階層内のより低レベルの子または並列兄弟セマンティクスノードを認証することを含む）することにより、それらが登録し、セマンティクスノードのリソースに対する要求を行うことを可能にすること、アプリケーション、デバイス、および／またはユーザを認証することにより、それらがセマンティクス関連クラス、関係、およびタームリソースを公表、作成、削除、更新、および読み出すことを可能にすること、セマンティクス関連クラス、関係、およびタームリソースを記憶して管理すること、セマンティクス関連リソースの発見のためのサポートを提供すること、および発見クエリに協力してセマンティクス関連リソース情報を共有するために、セマンティクスノードが互に（親子、兄弟の間で）通信するためのサポートを提供すること。

セマンティクスノードは、１つ以上の基準点またはインターフェースを介して、ネットワーク内の他のエンティティと通信し得る。一実施形態では、３つの基準点、すなわち、ｓＩｓ基準点、ｓＩｃ基準点、およびｓＩｅ基準点が定義される。ｓＩｓ基準点は、セマンティクスノード間の通信に使用される。ｓＩｓ基準点はまた、親子または兄弟関係を形成するように別のセマンティクスノードに登録するため、他のセマンティクスノードを発見するため、その状態（例えば、オンライン、オフライン、オーバーロード等）に関して他者に通知するため、特定の動作（例えば、登録解除、登録）を行うように別のセマンティクスノードをトリガするため、別のセマンティクスノード内のセマンティクス関連リソースを公表、作成、削除、更新、および読み出すために、セマンティクスノードによって使用され得る。加えて、セマンティクスノードは、図３６、図３７、および図３８に関連して以下でさらに説明されるように、別のセマンティクスノード内のセマンティクス関連リソースに加入し、対応する通知を受信するため、その階層内の兄弟および親セマンティクスノード上のセマンティクス関連リソースを発見するため、セマンティクス関連リソースのグループを１つのセマンティクスノードから別のセマンティクスノードへ移動させるため、および、別のセマンティクスノードに記憶されたセマンティクス関連リソースがあるリソースと結び付けられて関連付けられ、そのセマンティクスをそのリソースに提供することを可能にするために、ｓＩｓ基準点を使用し得る。

本実施形態では、ｓＩｃ基準点は、種々のネットワークドメイン（例えば、エリアネットワーク、アクセスネットワーク、またはコアネットワーク）からのセマンティクスノードと通信するために、アプリケーションまたは非セマンティクスノードによって使用され得る。ｓＩｃ基準点はまた、アプリケーションまたは非セマンティクスノードが、セマンティクスノード内のセマンティクス関連リソースを公表、作成、削除、更新、読み出し、加入、または発見すること、およびセマンティクスノードから通知を受信することも可能にする。加えて、ｓＩｃ基準点は、セマンティクスノードに記憶されたセマンティクス関連リソースがあるリソースと結び付けられて関連付けられ、そのセマンティクスをそのリソースに提供することを可能する。

ｓＩｅ基準点は、Ｍ２Ｍシステム内のノードの既存の階層の一部であるセマンティクスノードと外部セマンティクスノードとの間の通信のために使用され得る。外部セマンティクスノードは、Ｍ２Ｍドメインの外側にセマンティクス関連リソースを記憶する。外部セマンティクスノードの一実施例は、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００５／Ｉｎｃｕｂａｔｏｒ／ｓｓｎで説明されるようなＷ２Ｃ Ｓｅｍａｎｔｉｃ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ Ｉｎｃｕｂａｔｏｒ Ｇｒｏｕｐによって定義される、セマンティックセンサネットワークオントロジーのためのセマンティクス関連リソースを記憶するサーバであり得る。ｓＩｅ基準点は、セマンティクスノードが外部セマンティクスノード内のセマンティクス関連リソースを読み出し、発見し、およびそれに加入することを可能にし、その逆も同様である。また、ｓＩｅ基準点を介して、外部セマンティクスノードは、Ｍ２Ｍシステム内のセマンティクスノードを発見し、通知を受信し得る。

これらの基準点を効果的に定義する、ｓＩｓ、ｓＩｅ、およびｓＩｃ基準点に関連付けられているメッセージの一実施形態が、表１で以下に記載される。

表８は、セマンティクスノード関連メッセージ、それらの対応する意味、および使用される基準点を記載する。

ハイパーテキスト転送プロトコル（ＨＴＴＰ）または制約アプリケーションプロトコル（ＣｏＡＰ）等のプロトコルが、異なるタイプのメッセージを搬送するための基礎的トランスポートプロトコルとして使用され得る。上記で議論される種々のセマンティクスノード機能性を果たすためのこれらのメッセージの使用の実施例が、以下で提示される。

（ＩＶ．Ｍ２Ｍセマンティクスノードプロシージャ）
（Ａ．セマンティクスノード階層を構築する）
この節では、一実施形態による、どのようにしてセマンティクスノードの階層（以降では「セマンティクスノード階層」）が構築され得るかに関して、追加の詳細が提供される。本実施形態では、セマンティクスノード階層は、ネットワーク内の異なるエリア、アクセス、およびコアレベルに位置するセマンティクスノード間の親子および兄弟関係を決定することによって構築される。

図２１Ａは、セマンティクスノード階層を確立する方法の一実施形態を図示する、フロー図である。セマンティクスノードがネットワークに参加するとき（ステップ５０４）、すなわち、それがオンラインになるとき、それがネットワーク内で動作セマンティクスノードになることができる前に、子・親および兄弟関係を最初に構築する必要がある。この目的を達成するために、ステップ５０６では、セマンティクスノードは、同一のレベルで兄弟セマンティクスノードの発見を行い得る。

セマンティクスノード発見要求（例えば、マルチキャスト、ブロードキャスト、エニーキャスト）を送信することに基づき得、兄弟セマンティクスノードの発見は、兄弟セマンティクスノードを発見しようとして発見要求を発行することができる。要求は、ネットワークを混雑させ得る、発見要求および応答メッセージのフラッディングを制限する定義されたホップ制限を有することができる。代替として、発見は、利用可能である場合、ドメイン名システム（ＤＮＳ）、ＤＮＳサービス発見（ＤＮＳ−ＳＤ）、サービスロケーションプロトコル（ＳＬＰ）等のネットワーク内で利用可能な既存の発見機構を活用することができる。セマンティクスノードは、ＩＰアドレスまたは管理されるセマンティクス情報のタイプ等の隣接兄弟セマンティクスノードの返信された情報を記憶し得る。以下でさらに議論されるように、兄弟セマンティクスノード発見応答メッセージはまた、高レベルセマンティクスノード発見サーバのアドレス、兄弟の親セマンティクスノードのアドレス、または両方をピギーバックし得る。

依然として図２１Ａを参照すると、兄弟セマンティクスノードの発見に続いて、セマンティクスノードは、次に、ステップ５０８、ステップ５１０、およびステップ５１２で、高レベルのセマンティクスノードを発見しようと、および／またはそれらに登録しようとし得る。セマンティクスノードが、それが登録する必要がある高レベルノードを供給されている場合、単純に、この供給されたセマンティクスノードに登録し、親子関係を構築することができる（ステップ５０８、ステップ５１２）。別様に、セマンティクスノードは、既存の高レベルセマンティクスノードを発見し、登録するためにそれらのうちの１つを選択する必要がある（ステップ５１０）。選択は、同一のタイプのセマンティクス関連リソース等をサポートする、隣接上位レベルで最近傍等の基準に基づき得る。図２１Ｂは、これらのステップ５０８、ステップ５１０、およびステップ５１２をさらに詳細に図示する。

本実施形態では、各レベルでは、デフォルトで高レベルセマンティクスノード発見要求を受理する、１つのセマンティクスノード発見サーバがあり得る。セマンティクスノード発見サーバのアドレスは、低レベルセマンティクスノードに周知され得る。図２１Ｂに示されるように、新しいセマンティクスノードが高レベル親セマンティクスノードアドレスを供給されていない場合（ステップ６０２）、および新しいセマンティクスノードが上位レベルでセマンティクスノード発見サーバを供給されていない場合（ステップ６０４）、最初に、兄弟セマンティクスノード発見６０６を行うことができる。兄弟発見の一部として、セマンティクスノード発見サーバのアドレスは、共有され得る（例えば、発見された兄弟セマンティクスノードから受信される兄弟発見応答でピギーバックされる）（ステップ６０８）。一方で、新しいセマンティクスノードはまた、兄弟の親セマンティクスノード情報（アドレス）を明示的に要求し得、登録すべき自身の親として１つを選択し得る。（ステップ６１０、６１８）。

新しいセマンティクスノードが上位セマンティクスノード発見サーバのアドレスを供給されている場合、セマンティクスノード発見を直接行うことができる（ステップ６０４からステップ６１４への通過を制御する）。そうでない場合、兄弟の親リストから選択したいかどうか、および兄弟からデフォルトセマンティクスノード発見サーバのアドレスを読み出したいかどうかを決定する（ステップ６０８および６１０）。新しいセマンティクスノードが兄弟の親から上位セマンティクスノードを選択する場合（ステップ６１８）、セマンティクスノード発見をさらに行わないことを選択し得る。上位セマンティクスノード発見サーバのアドレスを供給されている場合、これは、（同一のタイプのセマンティクス関連リソース等をサポートする、ホップ数で最近傍にある）親を選択する基準を決定する（ステップ６１４）。基準に基づいて、これは、上位レベルでのセマンティクスノードのアドレスに加えて、発見したい情報（距離、セマンティクス関連リソースのサポートされたタイプ等）を設定する（ステップ６１６）。

ステップ６２０では、新しいセマンティクスノードが、発見した、または別様に選択した高レベル親セマンティクスノードに登録し得る。新しいセマンティクスノードが、高レベルセマンティクスノード発見サーバのアドレスを知ることも、それが選択し得るその兄弟のいかなる高レベル親セマンティクスノードも識別することもできない場合、いずれの高レベル親セマンティクスノードも利用可能ではないと決定し、ステップ６１２でプロセスを終了させ得る。

図２１Ａを再度参照すると、兄弟の発見ならびに親ノードの発見および登録が完了すると、新しいセマンティクスノードの兄弟および親に関する情報が記憶される（ステップ５１４）。図２１Ａでさらに図示されるように、新しい兄弟がネットワークに参加するか、または既存の兄弟がオフラインになる場合、セマンティクスノードは、そのセマンティクスノード関係を更新し得る（ステップ５１６、５１８）。ステップ５２０では、新しいセマンティクスノードが現在動作している。図２１Ａでさらに図示されるように、動作セマンティクスノードは、ある以降の時点で、別の高レベルノードに登録するようにトリガされ得（ステップ５２２）、またはネットワークから離れてもよい（ステップ５２６）。前者の場合、セマンティクスノードは、その現在の親を登録解除し、新しい親に登録し得る（ステップ５２４）。後者の場合、セマンティクスノードは、単純に、その現在の親を登録解除し得る（ステップ５２８）。

図２２は、上記で議論され、図２１Ａおよび図２１Ｂで図示される、セマンティクスノード発見および登録プロセスをさらに図示する、メッセージフロー図である。ステップ１８５では、新しいセマンティクスノード１８１が、セマンティクスノード発見要求を兄弟セマンティクスノード１８２に送信する。兄弟セマンティクスノード１８２は、新しいセマンティクスノード１８１と同一のネットワークレベルにある。ステップ１８５のセマンティクスノード発見要求は、セマンティクスノード発見サーバ１８３に関する情報（例えば、アドレス）、または兄弟セマンティクスノード１８２の親（例えば、上位）セマンティクスノード１８４であるセマンティクスノードの情報に対する要求を含み得る。親セマンティクスノードに対する要求は、新しいセマンティクスノード１８１が、登録する自身の親を選択することを可能にし得る。

セマンティクスノード発見サーバ１８３は、同一のレベル内に散乱させられたセマンティクスノードの情報を記憶するための集中点、またはネットワークの同一のレベルで発見要求を大量送信し、セマンティクスノードの返信される応答を収集する集合点と見なされ得る。セマンティクスノード発見サーバ１８３は、新しいセマンティクスノード１８１のネットワークレベルより高いレベル、同一レベル、または低いレベルのネットワークレベルでネットワークに常駐する、サーバであり得る。本実施例は、セマンティクスノード発見サーバ１８３が、新しいセマンティクスノード１８１のネットワークレベルに関して上位レベルにあることを仮定する。セマンティクスノード発見サーバ１８３のアドレスを、低レベルセマンティクスノード（例えば、兄弟セマンティクスノード１８２）に周知させることができる。新しいセマンティクスノード１８１がセマンティクスノード発見サーバ１８３を供給されていない場合、新しいセマンティクスノード１８１は、兄弟セマンティクスノード発見を行い得る。新しいセマンティクスノード１８１がセマンティクスノード発見サーバ１８３のアドレスを供給されている場合、セマンティクスノード発見を直接行うことができる。

図２２のステップ１８６では、兄弟セマンティクスノード１８２が、セマンティクスノード発見応答を送信する。セマンティクスノード発見応答は、セマンティクスノード発見サーバ１８３の情報（例えば、アドレス情報）、または兄弟セマンティクスノード１８２の親であるセマンティクスノードの情報を含み得る。ネットワークのレベルでの各兄弟ノードは、兄弟セマンティクスノード１８２によって提供される情報とは異なり得る、親セマンティクスノード情報およびセマンティクスノード発見サーバ情報で応答し得る。

ステップ１８７では、新しいセマンティクスノード１８１が、セマンティクスノード発見サーバ１８３の受信されたアドレスを抽出する。ステップ１８８では、新しいセマンティクスノード１８１が、セマンティクスノード発見要求をセマンティクスノード発見サーバ１８３に送信する。ステップ１８８での要求は、セマンティクスノード１８１が接続し得る、１つ以上の親セマンティクスノードに対する問い合わせであり得る。ステップ１８９では、セマンティクスノード発見サーバ１８３が、セマンティクスノード発見応答を新しいセマンティクスノード１８１に送信する。ステップ１８９での応答は、１つ以上の親セマンティクスノードを含み得る。ステップ１９０では、新しいセマンティクスノード１８１が、登録する１つの親セマンティクスノードを選択する。ステップ１９１では、セマンティクスノード１８１が、その選択された親セマンティクスノード１８４への登録に対する要求を送信する。ステップ１９２では、親セマンティクスノード１８４が、ステップ１９１での登録に対する要求への応答を送信する。

概して、新しいセマンティクスノード１８１がセマンティクスノード発見サーバ１８３のアドレスを供給されている場合、セマンティクスノード発見を直接行うことができる。そうでなければ、新しいセマンティクスノード１８１は、１つ以上の兄弟から受信される親セマンティクスノードのリストから選択したいかどうか、および兄弟からセマンティクスノード発見サーバ１８３のデフォルトアドレスを読み出したいかどうかを決定する。各レベルにおいて、デフォルトで高レベルセマンティクスノード発見要求を受理する、１つ以上のセマンティクスノード発見サーバがあり得る。新しいセマンティクスノード１８１が兄弟の親から上位セマンティクスノードを選択する場合、新しいセマンティクスノード１８１は、セマンティクスノード発見をさらに行わないことを選択し得る。新しいセマンティクスノード１８１は、親を選択する（例えば、同一のタイプのセマンティクス関連リソース等をサポートする、ホップ数で最近傍等のオプションから選択する）基準を決定するオプションを有し得る。基準に基づいて、新しいセマンティクスノード１８１は、上位レベルでのセマンティクスノードのアドレスに加えて、発見したい情報（例えば、距離、セマンティクス関連リソースのサポートされたタイプ等）を設定する。

図２３は、その一実施形態による、親子関係更新プロセス（図２１Ａのステップ５２２および５２４）のさらなる詳細を提供する、メッセージフローを提供する。更新は、子または親セマンティクスノードによって開始され得る。ステップ２０５では、セマンティクスノード２０１が、通知に基づいて現在の親セマンティクスノード２０３から登録解除することを決定する。通知は、とりわけ、登録解除を開始する現在の親セマンティクスノード２０３からのメッセージ、現在のセマンティクスノード２０３が連絡可能ではない（例えば、オフラインである、切断されている、または他の通信問題）という決定、または親セマンティクスノード２０３に関連付けられている受信された状態更新（例えば、ネットワークトラフィック混雑、デバイスまたは回線エラー、メモリ容量問題等）であり得る。

ステップ２０６では、セマンティクスノード２０１が、親子関係を終了させるための要求を含む、登録解除要求を現在の親セマンティクスノード２０３に送信する。ステップ２０７では、セマンティクスノード２０１が、親セマンティクスノード２０３から、または現在の親セマンティクスノード２０３の知覚された状態を通信することができる別のデバイスから、ステップ２０６で送信された登録解除要求への応答を受信し得る。図２２に関して図示されるステップと同様に、セマンティクスノード２０１は、新しい親セマンティクスノードに登録しようとする。ステップ２０８では、セマンティクスノード２０１が、セマンティクスノード発見要求をセマンティクスノード発見サーバ２０２に送信する。ステップ２０９では、セマンティクスノード発見サーバ２０２が、セマンティクスノード発見応答をセマンティクスノード２０１に送信する。ステップ２１０では、セマンティクスノード２０１が、登録するための１つの上位セマンティクスノードを選択する。ステップ２１１では、セマンティクスノード２０１が、その選択された新しい親セマンティクスノード２０４への登録のための要求を送信する。ステップ２１２では、新しい親セマンティクスノード２０４が、親子関係の更新を確認する、ステップ２１１での登録のための要求への応答を送信する。

（示されていないが、図２３の要素を参照して）実施形態では、親セマンティクスノードが、子の登録解除をトリガし、登録する子のための新しい親セマンティクスノードを提供し得る。この新しい親情報は、登録解除トリガメッセージに、または代替として、別個のトリガメッセージに含まれ得る。セマンティクスノード２０１は、現在の親セマンティクスノード２０３に登録要求を新しい親セマンティクスノード２０４へ送信させることによって、新しい親セマンティクスノード２０４に登録することができる。現在の親セマンティクスノード２０３は、登録目的で、セマンティクスノード２０１の情報を新しい親セマンティクスノード２０４に転送するオプションを有する。現在の親セマンティクスノード２０３またはセマンティクスノード２０１は、現在の親セマンティクスノード２０３を新しい親セマンティクスノード２０４に切り替える前に、親子関係を終了させ得る。

概して、セマンティクスノードの親子関係は、子セマンティクスノードがオフラインになるとき、または子セマンティクスノードが別の高レベル親セマンティクスノードに登録するときに、現在の親セマンティクスノードを登録解除することによって終了させられる。

隣接兄弟セマンティクスノードがネットワークに参加する場合、新しいセマンティクスノードを追加することによって、対応する兄弟情報が更新される。隣接兄弟セマンティクスノードがネットワークから離れる場合、セマンティクスノードを削除するか、またはネットワークから離れた兄弟セマンティクスノードの状態を示すようにテーブルを別様に更新する（例えば、状態＝オフライン）ことによって、対応する兄弟情報が更新される。セマンティクスノードは、例えば、表１で上に示されるＳＥＭＡＮＴＩＣＳ＿ＮＯＤＥ＿ＳＴＡＴＵＳ＿ＮＯＴＩＦＹ（）メッセージを使用して、その状態を兄弟セマンティクスノードにブロードキャストするか、または別様に伝達し得る。状態更新は、どのようにして兄弟および親子関係が維持されるかに影響を及ぼし得る。

（Ｂ．セマンティクス関連リソース発見、読み出し、および検証）
アプリケーション、デバイス、ユーザ、ピアセマンティクスノード、外部セマンティクスノード、または非セマンティクスノードは、ｓＩｃ、ｓＩｓ、およびｓＩｅ基準点を通して、セマンティクス関連リソース発見要求をセマンティクスノードに送信し得る。発見要求メッセージは、セマンティクス関連リソースのタイプ（クラス、関係、またはターム）と、検索文字列とを含み得る。例えば、摂氏単位の整数として、その温度読取データをそのＭ２Ｍゲートウェイに報告する必要がある、Ｍ２Ｍシステム内の温度感知アプリケーション（Ａｐｐ１）を仮定されたい。ゲートウェイサービス能力層（ＧＳＣＬ）がデータを理解することを可能にするために、Ａｐｐ１は、データを適正なセマンティクス情報に関連付ける必要がある。本明細書で説明されるプロシージャに従って、Ａｐｐ１は、摂氏単位の整数として温度データを表す、セマンティクス関連リソースクラス、すなわち、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスを記憶する、セマンティクスノードを発見し得る。発見後に、Ａｐｐ１は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスの表現を読み出し、その温度データのセマンティクスを提供するためにそれが使用したいものであることを検証するであろう。次いで、これは、データをその属性（セマンティクス属性）のうちの１つとしてｔｅｍｅｐｒａｔｕｒｅＲｅａｄｉｎｇクラスと結び付けるであろう。ＧＳＣＬでは、データは、Ａｐｐ１のための＜ｔｅｍｐＤａｔａ＞コンテナの下で記憶され得、＜ｔｅｍｐＤａｔａ＞コンテナは、例えば、図４２で図示されるように、ｈａｓＴｙｐｅ関係を使用してｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスに結び付くセマンティクス属性を有するであろう。結果として、ＧＳＣＬ内の＜ｔｅｍｐＤａｔａ＞コンテナの下で記憶された全てのＡｐｐ１データは、データの各アイテムが整数であり、摂氏単位を有するという同一のセマンティクスを有するであろう。別の実施例として、Ａｐｐ１は、ＮＳＣＬからリソースを取り出すアプリケーションであり得る。リソースは、（上記の実施例に類似する）ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスに結び付くセマンティクス属性を有し得る。リソースのコンテナ内のデータを理解して解釈するために、Ａｐｐ１は、リソースのセマンティクス属性が結び付けられるセマンティクス関連リソース、この場合は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスを読み出す必要があろう。Ａｐｐ１は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスセマンティクス関連リソースの表現を読み出した後、現在、整数であり、摂氏単位を有することが分かっている、リソースデータを解釈できるであろう。

図２４は、一実施形態による、セマンティクスノードにおけるセマンティクス関連リソース発見要求の処理を図示する、フロー図である。ブロック２２１では、セマンティクスノードが、要求されたセマンティクス関連リソースのタイプと、潜在的な検索文字列とを含む、セマンティクス関連リソース発見要求を受信する。ブロック２２２では、セマンティクスノードが、発見要求をチェックする。要求が不十分であるか、または不正な形式である（例えば、要求されたリソースのタイプが欠落している）場合、発見要求は無効と見なされ、無効な発見応答がブロック２３３によって示されるように発行側（例えば、要求クライアントデバイス）に返信されるであろう。ブロック２２３によって示されるように、要求が有効である場合、検索文字列は、ローカルで記憶されたセマンティクス関連リソースと比較される。具体的には、要求されたセマンティクス関連リソースのタイプに基づいて、セマンティクスノードは、どのタイプ（すなわち、クラス、関係、またはターム）のセマンティクス関連リソースをそれが検索するであろうかを決定することができる。ブロック２２４によって示されるように、キーワードとして検索文字列を使用して、セマンティクスノードは、１つ以上の合致するセマンティクス関連リソースを見出すために、そのローカル意味データベースを検索する。合致するセマンティクス関連リソースがローカルで見出された場合、セマンティクス関連リソースのアドレス（例えば、ＵＲＬ／ＵＲＩ）が、ブロック２２５によって示されるように、発見応答で発行側に返信され得る。

ローカルで見出された合致するセマンティクス関連リソースがない場合、セマンティクスノードは、その兄弟セマンティクスノードから、合致するセマンティクス関連リソースを見出そうとするであろう。ブロック２２６およびブロック２２７によって示されるように、セマンティクスノードは、発見要求を兄弟に転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック２２８では、合致するセマンティクス関連リソースが連絡を受けた兄弟から見出されるかどうかが決定される。合致するセマンティクス関連リソースがその兄弟から返信される場合、セマンティクス関連リソースの対応するアドレス（例えば、ＵＲＩ／ＵＲＬ）が、成功発見応答とともに発行側に返送される（ブロック２２５）。

セマンティクスノードの兄弟から返信される、合致するセマンティクス関連リソースがない場合には、ブロック２２９によって示されるように、親セマンティクスノードが連絡を受けることができるかどうかが決定される。親セマンティクスノードがない場合には、否定結果を示す発見応答が発行側に返信されるであろう（ブロック２３３）。親セマンティクスノードがある場合、セマンティクスノードは、その親セマンティクスノードから合致するセマンティクス関連リソースを見出そうとするであろう。それぞれ、ブロック２３０およびブロック２３１によって示されるように、セマンティクスノードは、発見要求を親セマンティクスノードに転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック２３２では、合致するセマンティクス関連リソースが連絡を受けた親から見出されるかどうかが決定される。合致するセマンティクス関連リソースが連絡を受けた親から返信される場合、セマンティクス関連リソースの対応するアドレス（例えば、ＵＲＩ／ＵＲＬ）が、成功発見応答とともに発行側に返送される（ブロック２２５）。セマンティクスノードの親から返信される、合致するセマンティクス関連リソースがない場合には、否定結果を示す発見応答が発行側に返信されるであろう（ブロック２３３）。

発行側が、合致するセマンティクス関連リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を含む成功発見応答を受信した後、発行側は、セマンティクス関連リソースの表現を読み出すことができる。

一実施形態では、セマンティクスノードは、クライアントおよびサーバから成る、ＲＥＳＴｆｕｌアーキテクチャ形式（表現状態転送）をサポートし得る。クライアント（例えば、発行側）は、サーバ（例えば、セマンティクスノード）へのセマンティクス要求を開始する。本実施形態では、サーバ（例えば、セマンティクスノード）は、セマンティクスに対する要求を処理し、適切なセマンティクス応答を返信する。要求および応答は、セマンティクス関連リソースの表現の転送の周りで構築される。クライアントは、セマンティクス関連リソース（例えば、クラス、関係、またはターム）に対するＲＥＳＴｆｕｌ動作をセマンティクスノードに要求することができる、アプリケーション、ユーザ、デバイス、セマンティクスノード等であり得る。

ＲＥＳＴｆｕｌアーキテクチャでリソースを取り扱うとき、セマンティクス関連リソースに適用され得る４つの基本的方法がある。
ＣＲＥＡＴＥ：クラス、関係、またはタームリソースを作成する
ＲＥＴＲＩＥＶＥ：クラス、関係、またはタームリソースのコンテンツを読み取る
ＵＰＤＡＴＥ：クラス、関係、またはタームリソースのコンテンツを書き込む
ＤＥＬＥＴＥ：クラス、関係、またはタームリソースを削除する
ＲＥＳＴｆｕｌサーバの役割を果たすセマンティクスノードが、受信した要求を検証し得る。動作は、発行側が適正なアクセス権の認定を受けた場合に可能にされる。

図２５は、このＲＥＳＴｆｕｌ実施形態による、これらのＲＥＳＴｆｕｌセマンティクスノード動作をさらに図示する、メッセージフロー図である。ステップ２４３では、発行側２４１が、ＲＥＳＴｆｕｌ ＣＲＥＡＴＥ、ＵＰＤＡＴＥ、ＲＥＴＲＩＥＶＥ、またはＤＥＬＥＴＥという動詞を対応して使用して、セマンティクス関連リソース（クラス、関係、またはターム）を作成、更新、読み出し、または削除することを要求する。発行側２４１は、アプリケーション、別のセマンティクスノード、デバイス、ユーザ等であり得る。ステップ２４３でセマンティクス関連リソースを作成するために、発行側２４１は、ＣＲＥＡＴＥ要求を発行し、セマンティクス関連リソースのタイプおよび表現を提供する。ステップ２４３でセマンティクス関連リソースを更新するために、発行側２４１は、ＵＰＤＡＴＥ要求を発行し、セマンティクス関連リソースの一意の識別またはアドレス、および更新または部分的に更新された表現を提供する。ステップ２４３でセマンティクス関連リソースを読み出すために、発行側２４１は、ＲＥＴＲＩＥＶＥ要求を発行し、セマンティクス関連リソースの一意の識別またはアドレス、および随意に検索文字列パラメータを提供する。ステップ２４３でセマンティクス関連リソースを削除するために、発行側２４１は、ＤＥＬＥＴＥ要求を発行し、セマンティクス関連リソースの一意の識別またはアドレスを提供する。

ステップ２４４では、セマンティクスノード２４２が、サーバの役割を果たし、受信した要求を検証し、別様にそれを処理する。受信した要求は、発行側２４１が適正なアクセス権の認定を受けている場合に許可される。作成動作がセマンティクスノード２４２によって許可される場合、新しいセマンティクス関連リソースは、それがクラス、関係、またはタームであるかどうかに基づいて、適切なリソースプールの下で作成される。そしてセマンティクス関連リソースは、セマンティクスノード２４２によって一意の識別子またはアドレスを割り当てられる。更新動作がセマンティクスノード２４２によって許可される場合、セマンティクス関連リソースの表現が更新される。読み出し動作がセマンティクスノード２４２によって許可される場合、セマンティクス関連リソースの表現は、発行側２４１が要求する形式で準備される。削除動作がセマンティクスノード２４２によって許可される場合、要求されたセマンティクス関連リソースが削除される。

ステップ２４５では、セマンティクスノード２４２が応答を発行側２４１に返信する。作成動作に対して、新たに作成されたセマンティクス関連リソースの識別またはアドレスが発行側に返信される。更新動作に対して、動作が成功しようとそうでなかろうと、応答コードが発行側２４１に返信される。読み出し動作に対して、発行側２４１が要求する形式のセマンティクス関連リソースの表現が、発行側２４１に返信される。削除動作に対して、動作が成功したかどうかを示すために、応答コードが発行側２４１に返信される。

図２６は、本明細書で説明されるセマンティクス関連リソース発見、読み出し、および検証をさらに図示する、メッセージフロー２５０である。本実施例では、ネットワークは、発行側２５１、セマンティクスノード２５２、セマンティクスノード２５２の兄弟である兄弟セマンティクスノード２５３、およびセマンティクスノード２５２に対して親である親セマンティクスノード２５４を含み得る。ステップ２５６では、発行側２５１が、セマンティクス関連リソース発見要求をセマンティクスノード２５２に送信する。メッセージフロー２５０に示されるように、セマンティクスノード２５２は、ステップ２５６での要求に合致するセマンティクス関連リソースを見出すために、（図２４のプロセスに類似する）いくつかのステップを経る。図示されるように、第１に、セマンティクスノード２５２は、そのローカルディレクトリを検索するであろう。これは、いかなる合致リソースも見出さない場合、時間窓を設定し、発見要求を兄弟２５３等のその兄弟に転送するであろう。応答がその兄弟から受信されない場合、セマンティクスノード２５２は、その要求を親セマンティクスノード２５４に転送するであろう。本実施例では、親セマンティクスノード２５４が合致するリソースを見出し、それが見出したセマンティクス関連リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を示す応答をセマンティクスノード２５２に返送するであろうことが仮定される。

ステップ２５７では、次いで、セマンティクスノード２５２が、発行側の要求に合致した、親セマンティクスノード２５４からのセマンティクス関連リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を含む、セマンティクス関連リソース発見応答を発行側２５１に返送する。ステップ２５９では、発行側２５１が、受信したＵＲＬに基づいてセマンティクス関連リソース読み出し要求を送信する。ステップ２６０では、親セマンティクスノード２５４が、クラス、関係、またはタームを含み得る、要求されたセマンティクス情報を含む、セマンティクス関連リソース読み出し応答を送信する。

ステップ２６１では、発行側２５１が、ステップ２６０からの受信したセマンティクス情報の表現をチェックする（検証する）。ステップ２６０で送信された受信したセマンティクス関連リソースが、正確には発行側２５１が欲しいものではない可能性がある。例えば、発行側２５１が温度クラスを要求し、返信された合致するリソースが関連華氏単位を伴うｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇと呼ばれるクラスであり、発行側２５１が摂氏単位を伴う温度クラスを所望する場合、発行側２５１は、親セマンティクスノード２５４がセマンティクスを修正することを要求することができる。これは、セマンティクス関連リソースを修正するために、ステップ２６２でセマンティクス関連リソース修正要求を親セマンティクスノード２５４に送信することによってサポートされることができる。ステップ２６３では、新たに追加または修正されたセマンティクス関連リソースのアドレス（例えば、ＵＲＬ／ＵＲＩ）が、発行側２５１に返信されるであろう。

セマンティクス関連リソースの修正に関して、概して、セマンティクスノードがそれ自体で修正をサポートしない場合、セマンティクスノードは、修正を行うようにその兄弟または親と協力し得る。セマンティクスノードが修正をサポートする場合には、セマンティクスノードは、新しいクラスを追加するか、現在のクラスを拡張することによって、クラスをローカルで修正し得る。

（Ｃ．セマンティクス関連リソースに加入する）
一実施形態では、セマンティクスノードは、それに加入するクライアント（例えば、アプリケーション、別のセマンティクスノード、デバイス、ユーザ等）をサポートすることができる。一実施例として、クライアントは、加入したセマンティクス関連リソースに対する任意の更新があるときに通知されるように、セマンティクスノードに加入し得る。更新が生じるとき、加入クライアントは、リソースの新しい表現で通知されるであろう。それ自体がセマンティクスノードであるクライアントの場合、加入したセマンティクス関連リソースは、加入者セマンティクスノードが関係しない（例えば、親子または兄弟ではない）別のセマンティクスノードに記憶され得る。本実施例では、クライアントは、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥ＿ＲＥＱメッセージをセマンティクスノードに発行し得る。メッセージは、リソースが更新されたときにクライアントが通知を受信することを希望する、セマンティクス関連リソースを識別する。セマンティクスノードは、加入を承認する、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥ＿ＲＥＳＰメッセージで要求に応答するであろう。クライアントが加入したセマンティクス関連リソースが更新されるとき、セマンティクスノードは、更新をクライアントに通知するために、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥＲ＿ＮＯＴＩＦＹメッセージを送信するであろう。

別の実施例として、セマンティクスノードは、その兄弟、親、または子セマンティクスノードのうちの１つによって記憶および管理されるセマンティクス関連リソースに関して更新されることに関心があり得る。図２７は、一実施形態による、この状況のための加入／通知プロセスの例示的なフロー２７０である。本実施例では、セマンティクスノード２７１は、加入先セマンティクスノード２７２によって記憶および管理されるセマンティクス関連リソースに関して更新される。加入先セマンティクスノード２７２は、セマンティクスノード２７１の兄弟、親、または子であり得る。ステップ２７３では、セマンティクスノード２７１が、加入標的を識別し、トリガ基準に関連するセマンティクス関連リソース通知のみを受信するように、通知トリガ基準を設定し得る。例えば、加入者は、新しい通知が送信される前に、特定のセマンティクス関連リソース、またはセマンティクス関連リソースに対する更新の特定数を特定するように、通知トリガ基準を構成し得る。セマンティクスノード２７１はまた、通知が送信されるべきときの期間スケジューリング情報を設定し得る。

ステップ２７４では、セマンティクスノード２７１が、セマンティクスノードリソース加入要求を標的セマンティクスノード２７２に送信する。ステップ２７５では、標的セマンティクスノード２７２が、ステップ２７４のセマンティクス加入要求を受理するかどうかを決定する。標的セマンティクスノード２７２は、既存の加入者、加入を取り扱う負荷（例えば、更新情報の収集または通知を送信するために使用される帯域幅に関する負荷）等に基づいて、加入要求を受理するかどうかを決定することができる。ステップ２７６では、標的セマンティクスノード２７２が、セマンティクスノード加入応答をセマンティクスノード２７１に送信する。ステップ２７６での応答は、加入の確認、および加入を処理する際に使用されるであろうパラメータを含み得る。ステップ２７７では、ステップ２７６後のある時点で、標的セマンティクスノード２７２が、ステップ２７４で受信された要求トリガに合致する、意味通知トリガ条件を検出する。ステップ２７８では、標的セマンティクスノード２７２が、特定のセマンティクス関連リソースに関してセマンティクスノード２７１を更新するために、セマンティクスノードリソース加入通知メッセージを送信する。

概して、セマンティクス関連リソース加入は、ピアセマンティクスノードまたは親セマンティクスノードからのセマンティクス関連リソース発見を促進することができる。例えば、（セマンティクスノードに記憶される、新たに作成または更新されたセマンティクス関連リソースのＵＲＩを含むであろう）通知メッセージに基づいて、セマンティクスノードは、発見要求を送信することなく、他のノードのセマンティクス関連リソースに対する発見を行うことが可能であり得る。

（Ｄ．セマンティクス関連リソースへの結び付きおよび関連）
セマンティクスノードのセマンティクス関連リソースは、種々の方法で使用することができる。例えば、セマンティクス関連リソース表現は、セマンティクスノードから読み出され得、データが（例えば、ネットワークサーバ上、デバイス上、ゲートウェイ上等に）記憶されるネットワーク場所に、共同設置様式で記憶され得る。代替として、リソースのセマンティクスは、セマンティクスノード上に記憶され得、セマンティクスへのリンクは、データとともに、同一場所に位置し、記憶され得る。このセマンティクスリンクは、データ内にインラインで記憶され得るか（すなわち、埋め込まれ）、またはデータと並んで別個に（例えば、別個のリソースまたは属性に）記憶され得る。したがって、このセマンティクス関連リソースへの結び付きを通して、セマンティクスは、Ｍ２Ｍシステム内の通常リソース（例えば、＜ＳＣＬ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞等）に適用されることができる。典型的には、この結び付きは、リソースが作成されるときにリソース作成者／生成者によって作成されるであろう。

図１の患者健康監視アプリケーションの以前の実施例を続けると、セマンティクスノード上で定義される意味クラスがあり、これらのクラスのＵＲＬは、患者健康監視アプリケーションによって発見され得る。表２は、患者健康監視アプリケーションに関連するタイプ「クラス」のセマンティクス関連リソースの例を示す。データは、ｈａｓＴｙｐｅと呼ばれる意味関係を使用して、意味クラスに結び付けられ得る。結果として、ｅｘａｍｐｌｅ／ｈｅａｌｔｈｍｏｎｉｔｏｒｉｎｇ／ｄａｔａ１というＵＲＩを伴う各データリソースに対して、リソースのセマンティクスは、以下の関連によって把握されるであろう。
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｐａｔｉｅｎｔ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｐａｔｉｅｎｔ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｄｏｃｔｏｒ／ｄａｔａ２ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｄｏｃｔｏｒ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｔｅｍｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｔｅｍｐｅｒａｔｕｒｅ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｈｒ／ｄａｔａ５ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｈｅａｒｔｒａｔｅ
ｈａｓＴｙｐｅ関係はまた、セマンティクスノード上に記憶されたｈａｓＴｙｐｅ関係のセマンティクス記述を参照する、ＵＲＬ／ＵＲＩによって識別され得る。

（Ｅ．グループ化最適化）
リソースのグループが類似セマンティクスを有する（例えば、同一のアプリケーション内の全てのリソースが同一のセマンティクスを有する）場合、類似セマンティクスは、アプリケーションの下の各個々のリソースの代わりに、アプリケーションに適用されることができる。図２８は、その一実施形態による、同一のセマンティクスを伴うリソースのグループ化の方法２８１を図示する。ステップ２８１では、同一のアプリケーションの既存のデータの一部が、同一のセマンティクス関連を共有すると決定される。ステップ２８２では、同一のセマンティクスを共有する、同一のアプリケーション内の決定されたデータが、グループに分類される。ステップ２８３では、ステップ２８２の各グループが、適切なセマンティクスに関連付けられている。ステップ２８４では、同一のアプリケーションからの新たに受信したデータが、同一のセマンティクスを共有するグループに入れられる。同一のアプリケーションの既存のデータは、複数のグループに分類され得、それらの各々は、同一のセマンティクス結び付きおよび関連を共有する。新しいデータが同一のアプリケーションから生成される場合、データは、同一のセマンティクスを共有するグループに入れられる。

例えば、血圧監視データの複数のインスタンスは、同一のセマンティクスを有する。したがって、各インスタンスは、以下に示されるような同一のセマンティクス（ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ）に関連付けられ得る。
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ２ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ３ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ ・・・
このグループ化最適化をサポートすることによって、以下の関連も有効であり得る。
・ ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
（Ｆ．セマンティクス関連リソースをプッシュ配信する）
上記のように、セマンティクスノードにおいてホストされるクラス、関係、およびタームが発見され、他者によって使用され得る。要求の頻度に基づいて、セマンティクス関連リソースのうちのいくつかが、より容易な発見またはアクセスのために、プッシュ配信されるか、または別のセマンティクスノードにおいてミラーリングされ得る。例えば、１つのセマンティクスノードは、別のセマンティクスノードから同一の転送された発見要求を（例えば、ポリシー定義閾値を超える）ある回数検出した後、セマンティクス関連リソースのミラーリングされたコピーをそのセマンティクスノードにプッシュ配信することを決定し得る。

セマンティクス関連リソースのプッシュ配信は、図２９に示されるように、兄弟間で、または親セマンティクスノードと子セマンティクスノードとの間で生じることができる。例えば、コアネットワーク２９５内の図２９のセマンティクスノード２９１は、セマンティクスノード２９２、セマンティクスノード２９３、およびセマンティクスノード２９４から、同一のセマンティクス関連リソース（例えば、温度）に対する多くの発見および読み出し要求を受信し得る。発見要求が定義された閾値に達するとき、セマンティクスノード２９３およびセマンティクスノード２９４がより速い応答時間でセマンティクス関連リソースにアクセスし得るように、セマンティクスノード２９１は、セマンティクスノード２９２上に同一のセマンティクス関連リソースを作成する（すなわち、リソースをミラーリングする）ことを決定し得る。セマンティクスノード２９１は、次いで、適切なＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＣＲＥＡＴＥ＿ＲＥＳＰメッセージで応答するであろう、他のセマンティクスノードにＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＣＲＥＡＴＥ＿ＲＥＱメッセージを発行することによって、セマンティクスノード上にミラーリングされたリソースを作成し得る。

以下のオプションは、セマンティクス関連リソースを最新の状態に保つために使用され得る。図２９を参照すると、セマンティクスノード２９１は、セマンティクス関連リソースの元の表現に対する任意の更新がある場合、セマンティクスノード２９２上のセマンティクス関連リソースを自動的に更新し得る（例えば、加入が必要とされない）。代替として、セマンティクスノード２９２は、元のセマンティクス関連リソースに加入し得る。セマンティクス関連リソースに対するセマンティクスノード２９２の加入に基づいて、セマンティクスノード２９２は、特定の加入先セマンティクス関連リソースへの任意の変更に関して通知されるであろう。また、前述のシナリオの組み合わせがあり得る。例えば、セマンティクスノード２９１の自動更新が、セマンティクスノード２９１上の全てのセマンティクス関連リソースに対して周期的に生じる一方で、セマンティクスノード２９２は、特定の加入先セマンティクス関連リソースに対するより即時の更新を所望する状況があり得。

セマンティクス関連リソースのプッシュ配信は、いずれの方向においても、兄弟間で、親と子との間で生じることができる。例えば、図２９を参照すると、セマンティクスノード２９６は、あるローカルセマンティクス関連リソースをその親セマンティクスノード２９７にプッシュ配信し得る。別の実施例では、セマンティクスノード２９１は、ある高次セマンティクス関連リソースを子セマンティクスノード２９８にプッシュ配信し得る。

（Ｇ．データ／セマンティクス関連リソース移動）
図３０は、デバイスが１つのネットワークから別のネットワークへ移動するシナリオを図示する。このシナリオでは、デバイスに関連するセマンティクス関連リソース、およびデバイスによって生成されるデータもまた、セマンティクス関連リソース読み出しに起因して、セキュリティ、オーバーヘッド、および／または負荷のために新しい場所へ移動させられる必要があり得る。

図３０を参照すると、デバイスは、最初に、エリアネットワーク３０１内に位置しているたが、エリアネットワーク３０２へ移動していることがある。最初に、デバイス３０９は、セマンティクスノード３０６と通信していた。デバイス３０９がエリア３０２に到着した後、デバイス３０９は、最初に、線３０３によって例証されるように、セマンティクスノード３０６に通信し続け得る。これは、アクセスネットワーク３０４、アクセスネットワーク３０８、およびコアネットワーク３００で不必要なオーバーヘッドをもたらし得る。この問題および他の問題に対処するために、セマンティクスノード３０６のセマンティクス関連リソースは、エリアネットワーク３０２内のセマンティクスノード３０７に移動させられ得る。セマンティクス関連リソースをセマンティクスノード３０７に移動させた後、デバイス３０９は、セマンティクス関連リソースのためにコアネットワーク３００を横断する必要はなく、代わりに、線３０５によって示されるように、セマンティクスノード３０７と通信することができる。

図３１は、図３０で描写されるようなデータまたはセマンティクス関連リソースの移動をさらに図示する、例示的メッセージフロー３１０である。ステップ３１５では、第１のエリアネットワーク内のセマンティクスノード３１１が、エリアネットワーク２内に位置するデバイスアプリケーション３１４とメッセージを交換する。ステップ３１５で交換されるメッセージは、例えば、セマンティクス関連リソース読み出し要求およびセマンティクス関連リソース読み出し応答を含み得る。ステップ３１６では、セマンティクスノード３１１が、デバイスアプリケーション２１４に関連付けられたセマンティクス関連リソースを、第２のエリアネットワーク内に位置するセマンティクスノード３１３に移動させることを決定する。セマンティクスノード３１３は、第１のエリアネットワークより通信的に近く（到達するためにより少ない時間を要する）、または論理的に近く（例えば、より少ないホップ）あり得る。ステップ３１６を参照すると、他のデバイスは、セマンティクスノード発見サーバ３１２、デバイスアプリケーション３１４、または別のコンピュータデバイス（図示せず）等のセマンティクス関連リソースを移動させる決定を行い得る。

ステップ３１７では、セマンティクスノード発見要求および応答が、セマンティクスノードの階層ならびに兄弟関係を構築するために、セマンティクスノード３１１とセマンティクスノード発見サーバ３１２との間で交換される。ステップ３１８では、セマンティクスノード３１１が、セマンティクスノード３１３のアドレスを決定する。ステップ３２０では、セマンティクス関連リソース作成要求メッセージが、デバイスアプリケーション３１４によって使用されるセマンティクス関連リソース（および他のデータ）をコピーするために、セマンティクスノード３１３に送信される。セマンティクスノード３１３は、セマンティクス関連リソースおよび他のデータのコピーが成功したという確認応答を含み得る、セマンティクス関連リソース作成応答メッセージで応答する。ステップ３２１では、セマンティクス連結更新要求メッセージが、デバイスアプリケーション３１４に送信される。ステップ３２１でのメッセージは、デバイスアプリケーション３１４がセマンティクスノード３１３からセマンティクス関連リソースを取り出すための命令を含み得る。ステップ３２２では、セマンティクス連結更新応答メッセージは、セマンティクスノード連結が更新されるという確認応答を含み得る。ステップ３２３では、デバイスアプリケーション３１４は、セマンティクスノード３１３から、クラス、関係、およびタームのタイプのセマンティクス関連リソースを読み出す。

（Ｖ．ＥＴＳＩ Ｍ２Ｍ／ｏｎｅＭ２Ｍ実施形態）
（Ａ．セマンティクスノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャ）
上記のように、本明細書で説明されるセマンティクスノード概念は、ＥＴＳＩ Ｍ２Ｍアーキテクチャを拡張するために使用することができる。一実施形態では、１つ以上のセマンティクスノードは、図３２に示されるように、Ｍ２Ｍセマンティクスノードと称され得る、独立型ネットワークエンティティとしてアクセス／コアネットワーク内に位置し得る。図３２では、Ｍ２Ｍセマンティクスノード３３１およびＭ２Ｍセマンティクスノード３３２は、同一のアクセス／コアネットワーク３３０内に位置する。エリア／コアネットワーク３３０内のＭ２Ｍセマンティクスノードは、上で説明されるｓＩｃ基準点を介して、ＤＳＣＬ、ＧＳＣＬ、ＮＳＣＬ、およびアプリケーションと連動し得る。加えて、Ｍ２Ｍセマンティクスノード３３１およびＭ２Ｍセマンティクスノード３３２は、ｓＩｓ基準点３３４を介して互に連動し得る。Ｍ２Ｍセマンティクスノード３３１およびＭ２Ｍセマンティクスノード３３２はまた、ｓＩｅ基準点を介して、別のタイプの外部セマンティクスノード３３３を参照し得る。本実施形態では、アクセス／コアネットワーク３３０内に位置するＭ２Ｍセマンティクスノードはまた、兄弟および／または親子関係を形成し得る。

セマンティクスノードは、現在のＥＴＳＩ Ｍ２Ｍアーキテクチャのサービス能力層（ｘＳＣＬ）で使用されるような相補的リソース構造をサポートし得、このリソース構造は、図３３で図示される様式で、本明細書で説明されるセマンティクスノードに適用され得る。本実施形態では、＜ｓｓＢａｓｅ＞リソース３４１は、ホスティングセマンティクスノード上に常駐するリソースツリーのルートである。＜ｓｓＢａｓｅ＞リソース３４１は、ホスティングセマンティクスノードを説明する属性を含み得る。＜ｓｓＢａｓｅ＞リソース３４１は、とりわけ、ＳＳリソース３４３、クラスリソース３４４、関係リソース３４６、タームリソース３４８、アクセス権リソース３４９、および加入リソース３５０の集合を表す、集合リソースを含む。クラスリソース３４４の下には、クラスリソース３４４のサブクラスである、他の＜ｃｌａｓｓ＞リソース３４５があり得る。関係リソース３４６の下には、関係リソース３４６のサブ関係である、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソース３４７があり得る。ＳＳリソース集合３４３は、遠隔セマンティクスノードがローカルセマンティクスノードに登録または登録解除するときに、作成または削除されるセマンティクスノードリソースを含む。

図３４に示されるように、ＳＳリソース３４３に対する集合における各セマンティクスノードリソースは、対応するリソース構造を有し得る。これらのリソースは、ローカルセマンティクスノードに登録された遠隔セマンティクスノードの状態を維持する。例えば、連絡先情報、発見情報（例えば、発表された意味クラス、表現、およびタームリソース）、およびセキュリティ情報（例えば、対応する遠隔セマンティクスノードと通信するために使用される信用証明）等の状態である。

図３３を再度参照すると、＜ｓｓＢａｓｅ＞リソース３４１の下のクラス３４４、関係３４６、およびターム３４８集合の各々は、ローカルセマンティクスノード上でホストされるセマンティクス関連リソースのそれぞれのインスタンスを含むことができる。各インスタンスは、意味表現を含むとともに、タグ等の発見関連情報等のそれに関連付けられている他の属性を有することができる。セマンティクス関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされることができる。＜ｓｓＢａｓｅ＞リソース３４１の下のアクセス権リソース３４９は、アクセス権のインスタンスを含むことができる。これらのアクセス権リソース３４９は、どのクライアントが、セマンティクスノードによってサポートされるどのセマンティクス関連リソースおよび動作へのアクセスを供与されるかを制御する、アクセス権のインスタンスを定義することができる。代替として、アクセス権集合の他のインスタンスは、より粒度の細かいアクセス制御を提供するようにリソース構造でサポートすることができる（図３３に示されていない）。加入リソース３５０の集合は、加入リソースのインスタンスを含むことができる。加入リソースのインスタンスは、特定通知トリガ基準イベントが生じるときに、セマンティクスノードから意味通知を受信することを希望するクライアントによって作成されることができる。発見リソース３４２は、クライアント意味発見要求をサポートする。これらの発見要求は、検索基準（例えば、特定のタイプの属性を有するセマンティクス関連リソース）をサポートすることができる。セマンティクスノードは、（存在する場合）検索基準に合致するリソースアドレス（例えば、ＵＲＩ）のリストで発見要求に応答することができる。セマンティクスノードはまた、他のセマンティクスノードへの要求の転送（例えば、子、兄弟、または親セマンティクスノードへの発見要求の転送）をサポートすることもできる。

（Ｂ．セマンティクス能力を伴うｘＳＣＬ）
図３５で図示される別の実施形態では、Ｍ２Ｍセマンティクスノードは、別個の独立型セマンティクスノードとしてよりも、ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、および／またはＮＳＣＬ内の組み込まれた能力として展開され得る。この組み込まれた実施形態では、ｓＩｓ基準点は、別個のままであり得るか、またはＥＴＳＩ Ｍ２Ｍ ｍＩｄ基準点が、ｓＩｓ機能性をサポートするように拡張させられ得る。同様に、ｓＩｃ基準点は、別個のままであり得るか、またはＥＴＳＩ Ｍ２Ｍ ｍＩａおよびｄＩａ基準点が、ｓＩｃ機能性をサポートするように拡張させられ得る。本実施形態では、ＧＳＣＬまたはＤＳＣＬ内に位置するＭ２Ｍセマンティクスノードは、それらが登録されるＮＳＣＬと親子関係を確立し得る。加えて、ＧＳＣＬまたはＤＳＣＬ内に位置するセマンティクスノードはまた、互に兄弟関係を確立し得る。

図３５の実施形態をサポートするために、ｘＳＣＬは、図３６に示されるリソース構造を有し得る。セマンティクスノードのリソース集合は、セマンティクスノード能力を有する遠隔ＳＣＬがローカルＳＣＬに登録または登録解除するときに作成または削除される、セマンティクスノードリソースを含む。この集合の中の各セマンティクスノードリソースは、図３６に示される、対応するリソース構造を有し得る。これらのリソースは、ローカルＳＣＬに登録される遠隔セマンティクスノードの状態を維持する。例えば、意味発見情報（例えば、発表された意味クラス、表現、およびタームリソース）等の状態である。

＜ｓｃｌＢａｓｅ＞リソース３６１の下のクラス、関係、およびターム集合の各々は、ローカルＳＣＬ上でホストされるセマンティクス関連リソースのそれぞれのインスタンスを含み得る。各インスタンスは、意味表現を含むとともに、タグ等の発見関連情報等のそれに関連付けられている他の属性を有することができる。セマンティクス関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされ得る。

（Ｃ．ＥＴＳＩ Ｍ２Ｍセマンティクス実装の使用事例の実施例）
セマンティクスノードによって管理されるセマンティクス関連リソースは、＜ｓｃｌＢａｓｅ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞等のＥＴＳＩ Ｍ２Ｍリソース構造のリソースに関連付けられ、結び付けられ得る。以下の議論は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のセマンティクス情報を提供するために、どのようにしてセマンティクス関連リソースが使用され得るかを例証する。

本実施例では、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスは、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｃｌａｓｓｅｓ／ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇというＵＲＩを有することを仮定されたい。ｈａｓＬｏｃａｔｉｏｎという関係も、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｒｅｌａｔｉｏｎｓｈｉｐｓ／ｈａｓＬｏｃａｔｉｏｎというＵＲＩを有する。加えて、‘ｎｏｒｔｈｅａｓｔ Ｃｈｉｎａ’というタームも、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｔｅｒｍｓ／ｎｏｒｔｈｅａｓｔＣｈｉｎａというＵＲＩを有する。図３７は、図３６に示されるｘＳＣＬリソース構造の実施例である、＜ｓｃｌ１＞上のセマンティクス関連リソース構造を示す。このリソース構造は、セマンティクス関連リソースのＵＲＩを決定する。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅは、ｇｓｃｌ２／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐ１／ｃｏｎｔａｉｎｅｒｓ／＜ｔｅｍｐｅｒａｔｕｒｅ＞／ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ／＜ｉｎｓｔ１＞というＵＲＩを有する。図３８のｘＳＣＬリソース構造で示されるようなセマンティクスを用いてｃｏｎｔｅｎｔＩｎｓｔａｎｃｅを拡張することによって、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのコンテンツを効果的に記述し、曖昧性を伴わずに解釈することができる。

図３９は、リソースおよびセマンティクス読み出しの一実施例を図示する、メッセージフローである。ステップ３９３では、ＮＡ３９０が、データリソースに対して、ＲＥＴＲＩＥＶＥ要求をＧＳＣＬ２ ３９１に送信する。データリソースは、例えば、とりわけ、血圧センサ示度値、中核体温センサ示度値、酸素飽和度センサ示度値、または運動加速度計センサ示度値であり得る。ステップ３９４では、ＧＳＣＬ２ ３９１が、データリソースの表現を返信する。データリソースを理解するために、ＮＡは、データリソースのセマンティクスを読み出す必要がある。したがって、ステップ３９５では、ＮＡ３９０が、読み出し要求をＧＳＣＬ３９１に送信する。ステップ３９６では、ＧＳＣＬ２ ３９１が、ＳＣＬ１ ３９２上に記憶されるデータリソースに対する関連セマンティクス関連リソースのＵＲＩのリストを返信する。ステップ３９７から３９９では、ＮＡ３９０が、それぞれ、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ、ｈａｓＬｏｃａｔｉｏｎ、およびｎｏｒｔｈｅａｓｔＣｈｉｎａというセマンティクス関連リソースについて、ＲＥＴＲＩＥＶＥメッセージをＳＣＬ１ ３９２と交換する。これらのセマンティクス関連リソースにより、ＮＡ３９０は、データリソースを理解することができ、したがって、データリソースを使用および操作することができる。

（ＶＩ．３ＧＰＰ ＭＴＣアーキテクチャ実施形態）
さらに上記のように、３ＧＰＰ ＭＴＣアーキテクチャはまた、本明細書で説明されるセマンティクスノードによって提供されるセマンティクスサポートを用いて拡張させられ得る。図４０に示されるように、一実施形態では、Ｍ２Ｍセマンティクスノード４０１は、３ＧＰＰコアネットワーク境界の外側に位置し得る。さらに示されるように、ＳＣＳ４０４は、セマンティクス能力をサポートするように拡張させられ得、ｓＩｓ基準点（図示せず）を介してＭ２Ｍセマンティクスノード４０１と連動し得る。Ｍ２Ｍセマンティクスノード４０１はまた、ｓＩｃ基準点４０３を介して、３ＧＰＰマシン型通信連動機能（ＭＴＣ−ＩＷＦ）４０２と連動し得る。アプリケーションサーバ（ＡＳ）４０６およびＡＳ４０７は、ｓＩｃ基準点４００を介してＭ２Ｍセマンティクスノード４０１と通信し得る。図４１は、セマンティクスノードを伴う３ＧＰＰ ＭＴＣアーキテクチャの別の実施形態を図示する。本実施形態では、セマンティクスノードは、ＳＣＳ４０８に組み込まれている。図４１で４０９においてさらに示されるように、本実施形態では、ｓＩｃ基準点は、３ＧＰＰ ＭＴＣ Ｔｓｐの一部であり得る。

３ＧＰＰおよびＥＴＳＩ Ｍ２Ｍアーキテクチャが、本明細書で背景として説明され、以降で説明される種々の実施形態を例証するために使用され得るが、本開示の範囲内にとどまりながら、以降で説明される実施形態の実装が変動し得ることが理解される。当業者であれば、開示された実施形態は、上記で議論される３ＧＰＰまたはＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されないが、むしろｏｎｅＭ２Ｍ、ＭＱＴＴ、Ｗ３Ｃセマンティクスウェブ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることも認識するであろう。

図４３Ａは、図１、図３、図１４、およびその他等の１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

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

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

図４３Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図３のセマンティクスノード７２３等のセマンティクスノードおよび他のＵＥ（例えば、ＵＥ１２７）は、図４３Ｃの構成要素を反映し得る。図４３Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、セマンティクス関連リソース公表および発見のための開示されたシステムおよび方法を使用する、デバイスであり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書で説明される実施形態のうちのいくつかでのセマンティクス関連リソース公表および発見（例えば、ブルームフィルタの処理またはセマンティクス関連リソースの読み出し）が成功しているか、または成功していないかに応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するか、あるいは別様に識別子およびブルームフィルタ等のリソース伝搬プロセスの状態を示すように構成され得る（例えば、図７および図８）。アプリケーションプログラミングインターフェースが、セマンティクス関連リソース公表メッセージおよび発見メッセージを定義するために表示され得る。

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

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

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

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

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

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

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

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

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

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

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

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

Claims (17)

1. マシンツーマシン（Ｍ２Ｍ）デバイスからのデータのセマンティクスに関連する情報を有するリソースを識別するための識別子を伝送するために使用されるデバイスであって、前記デバイスは、
   プロセッサと、
   前記プロセッサに結合されたメモリと
   を備え、
   前記メモリは、実行可能な命令を備え、前記命令は、前記プロセッサによって実行されると、
   前記リソースを識別するための識別子を構築することであって、前記識別子は、前記リソースのタイプとキーワードとを含む、ことと、
   前記識別子を含むメッセージを、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有する少なくとも１つのリソースを記憶する少なくとも１つのセマンティクスノードに伝送することと
   を含む動作を前記プロセッサに行わせる、デバイス。
2. 前記識別子は、前記リソースを記憶するセマンティクスノードのアドレスをさらに含む、請求項１に記載のデバイス。
3. 前記動作は、前記識別子とともに前記メッセージを受信することが可能なセマンティクスノードの数の制限を伝送することをさらに含む、請求項１に記載のデバイス。
4. 前記動作は、
   Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有するリソースまたは前記リソースを識別するための識別子の閾値量に達したことを決定することと、
   前記閾値量に達することに基づいて、前記メッセージを伝送することと
   をさらに含む、請求項１に記載のデバイス。
5. 前記キーワードは、ブルームフィルタを用いて符号化された複数のキーワードを含み、
   前記動作は、前記符号化された複数のキーワードを含むダイジェストメッセージを生成することをさらに含む、請求項１に記載のデバイス。
6. 前記デバイスは、セマンティクスノードの階層内のセマンティクスノードであり、
   前記動作は、
   前記識別子を含む前記メッセージと前記ダイジェストメッセージとを、前記デバイスよりも高い階層レベルの親セマンティクスノード、前記デバイスと同一の階層レベルの兄弟セマンティクスノード、前記デバイスより低い階層レベルの子セマンティクスノードのうちの少なくとも１つに伝送することをさらに含む、請求項５に記載のデバイス。
7. 前記識別子を含む前記メッセージを伝送することは、前記兄弟セマンティクスノードまたは前記親セマンティクスノードに制限され、
   前記ダイジェストメッセージを伝送することは、前記兄弟セマンティクスノードに制限される、請求項６に記載のデバイス。
8. マシンツーマシン（Ｍ２Ｍ）デバイスからのデータのセマンティクスに関連する情報を有するリソースを識別するための識別子を発見するために使用されるデバイスであって、前記デバイスは、
   プロセッサと、
   前記プロセッサに結合されたメモリと
   を備え、
   前記メモリは、実行可能な命令を備え、前記命令は、前記プロセッサによって実行されると、
   要求デバイスから、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有するリソースに対する要求を受信することであって、前記要求は、第１のキーワードを含む、ことと、
   前記要求されたリソースが前記デバイス上でローカルに記憶されていないことを決定することと、
   前記要求されたリソースが前記デバイス上でローカルに記憶されていないことを決定することに応答して、前記第１のキーワードが第２のキーワードに類似していると決定することであって、前記第２のキーワードは、前記リソースを識別するための識別子に関連付けられている、ことと、
   前記第１のキーワードが前記第２のキーワードに類似していると決定することに基づいて、前記識別子に含まれている、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有する少なくとも１つのリソースを記憶するセマンティクスノードのアドレスを前記要求デバイスに転送することと
   を含む動作を前記プロセッサに行わせる、デバイス。
9. 前記識別子は、前記要求されたリソースのタイプをさらに含む、請求項８に記載のデバイス。
10. 前記要求は、前記第１のキーワードに関連付けられている前記要求されたリソースの第１のタイプと、前記第１のキーワードに関連付けられている前記アドレスとをさらに含む、請求項８に記載のデバイス。
11. 前記動作は、
    前記第１のタイプがＭ２Ｍデバイスからのデータのセマンティクスに関連する情報を有するリソースの第２のタイプに類似していると決定することであって、前記第２のタイプは、前記第２のキーワードに関連付けられている、ことと、
    前記第１のタイプが前記第２のタイプに類似している、かつ、前記第１のキーワードが前記第２のキーワードに類似していると決定することに基づいて、前記アドレスを転送することと
    をさらに含む、請求項１０に記載のデバイス。
12. 前記動作は、前記第１のキーワードが前記第２のキーワードに類似していると決定することに基づいて、前記セマンティクスノードから前記リソースを読み出すことをさらに含む、請求項８に記載のデバイス。
13. プロセッサと、
    前記プロセッサに結合されたメモリと
    を備え、
    前記メモリは、実行可能な命令を備え、前記命令は、前記プロセッサによって実行されると、
    マシンツーマシン（Ｍ２Ｍ）デバイスからのデータのセマンティクスに関連する情報を有する第１のリソースに対する要求を、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有する少なくとも１つのリソースを記憶する第１のセマンティクスノードに送信することであって、前記要求は、第１のキーワードを含む、ことと、
    前記第１のセマンティクスノードから、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有する少なくとも１つのリソースを記憶する第２のセマンティクスノードを識別するための識別子を含む応答を受信することであって、前記第２のセマンティクスノードは、第２のリソースを有し、前記第２のリソースは、Ｍ２Ｍデバイスからのデータのセマンティクスに関連する情報を有し、かつ、第２のキーワードに関連付けられており、前記第２のキーワードは、前記第１のリソースに対する前記第１のキーワードに類似している、ことと
    を含む動作を前記プロセッサに行わせる、デバイス。
14. 前記要求は、前記第１のキーワードに関連付けられている前記第１のリソースのタイプをさらに含む、請求項１３に記載のデバイス。
15. 前記動作は、
    前記第２のリソースに対する要求を前記第２のセマンティクスノードに送信することと、
    前記第２のリソースを前記第２のセマンティクスノードから受信することと
    をさらに含む、請求項１３に記載のデバイス。
16. 前記動作は、
    前記第２のリソースに対する要求を前記第２のセマンティクスノードに送信することと、
    前記第２のリソースを前記第２のセマンティクスノードから受信することと、
    前記第２のリソースが前記第１のリソースに類似していることを検証することと
    をさらに含む、請求項１３に記載のデバイス。
17. 前記動作は、
    前記第２のリソースが前記第１のリソースに類似していないことを決定することと、
    前記第２のリソースを修正するための修正要求を前記第２のセマンティクスノードに送信することと
    をさらに含む、請求項１６に記載のデバイス。

Images