JP2017514321A - リソースセマンティクス有効化 - Google Patents

Abstract

マシンツーマシンシステムにおいてセマンティクスサポートを提供するセマンティクスノード機能のための方法、およびシステムが開示される。一実施例において、セマンティクスノードは、他のデバイスによって発見され、読み出され、または確認されることが可能なセマンティクスリソースを管理し得る。別の実施例において、セマンティクスノードは、他のノードによって発見され得、セマンティクスリソースは、加入機構を用いて発見され得る。

Description

（関連出願の引用）
本願は米国特許出願第１４／６０７，６４８号（２０１５年１月２８日出願、名称「ＥＮＡＢＬＩＮＧ ＲＥＳＯＵＲＣＥ ＳＥＭＡＮＴＩＣＳ」）に関連し、上記出願は、米国仮特許出願第６１／９３７，２０９号（２０１４年２月７日出願、名称「ＥＮＡＢＬＥ ＲＥＳＯＵＲＣＥ ＳＥＭＡＮＴＩＣＳ ＩＮ Ｍ２Ｍ ＳＹＳＴＥＭＳ」））の利益を主張し、これら出願の内容は、参照により本明細書に引用される。

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

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

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

セマンティクスの概念は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）として知られている国際規格団体によって導かれる協調的な動きである、セマンティックウェブの分野で一般的に知られている。この規格は、ワールドワイドウェブ上の共通データ形式を推進する。ウェブページにセマンティック内容を含むことを促すことによって、セマンティックウェブは、非構造化および半構造化文書によって支配された現在のウェブを「データのウェブ」に変換することを目指す。セマンティックウェブスタックは、Ｗ３Ｃのリソースディスクリプションフレームワーク（ＲＤＦ）を基礎とする。

開発中のｏｎｅＭ２Ｍ規格は、図２Ｂで図示されるような「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層の目的は、ｅヘルス、フリート管理、およびスマートホーム等の異なる「垂直」Ｍ２Ｍサイロシステムおよびアプリケーションによって使用されることができる、「水平」サービスを提供することである。ＣＳＥは、図２Ａに示されるような４つの基準点をサポートする。Ｍｃａ基準点は、アプリケーションエンティティ（ＡＥ）と連動する。Ｍｃｃ基準点は、同一のサービスプロバイダドメイン内の別のＣＳＥと連動し、Ｍｃｃ’基準点は、異なるサービスプロバイダドメイン内の別のＣＳＥと連動する。Ｍｃｎ基準点は、基礎的ネットワークサービスエンティティ（ＮＳＥ）と連動する。ＮＳＥは、デバイス管理、場所サービス、およびデバイストリガリング等の基礎的ネットワークサービスをＣＳＥに提供する。ＣＳＥは、図２Ｂの発見７０１、管理およびレポジトリ７０２等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図２Ｂは、ｏｎｅＭ２Ｍにおいて開発中のＣＳＦを図示する。

ｏｎｅＭ２Ｍに先立って、ＥＴＳＩ Ｍ２Ｍは、ＥＴＳＩ ＴＳ １０２ ６９０マシンツーマシン通信（Ｍ２Ｍ）機能アーキテクチャＶ２．１．１で定義されるような独自のサービス層指向Ｍ２Ｍ規格を公表した。ｏｎｅＭ２Ｍのアーキテクチャは、ＥＴＳＩ Ｍ２Ｍアーキテクチャに類似する。ＥＴＳＩ Ｍ２Ｍは、サービス能力と呼ばれる種々のサービスモジュールから成る、サービス能力層エンティティを定義した。

さらなる背景として、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｆ−ｃｏｎｃｅｐｔｓ／で説明されるリソースディスクリプションフレームワーク（ＲＤＦ）は、ウェブで情報を表すためのフレームワークである。ＲＤＦは、本質的に、データモデルである。その基礎的構成要素は、ステートメントと呼ばれる、リソース・プロパティ・値のトリプルである。ＲＤＦは、ＸＭＬで構文を与えられている。

ＲＤＦは、リソース、プロパティ、値、およびステートメントの概念を含む。リソースは、オブジェクトまたは「モノ」と考えられ得る。リソースは、著者、本、出版者、場所、人、ホテル、部屋、検索クエリ等であり得る。リソースは、ユニバーサルリソース識別子（ＵＲＩ）を有する。ＵＲＩは、統一リソースロケータ（ＵＲＬ）、ウェブアドレス、またはある他の種類の一意の識別子であり得る。識別子は、必ずしもリソースへのアクセスを可能にしない。ＵＲＩスキームは、ウェブの場所について定義されているが、電話番号、ＩＳＢＮ番号、および地理的な場所等の多様なオブジェクトについても定義されている。プロパティは、特別な種類のリソースと見なされ、リソース間の関係、例えば、「により著作」、「年齢」、「題名」等を表し得る。ＲＤＦにおけるプロパティはまた、ＵＲＩによっても識別される。

値は、リソースまたはリテラルであり得る。リテラルは、原子価（文字列）であり得る。例えば、「年齢」というプロパティを有するリソースは、「２０」というリテラル値を有することができる。ステートメントは、リソースのプロパティをアサートする。ステートメントは、リソース、プロパティ、および値から成るリソース・プロパティ・値のトリプルである。ＲＤＦにおける表現の基礎的構造は、各々がリソース、プロパティ、および値から成るトリプルの集合である。各トリプルは、それがリンクするノードによって表されるモノの間の関係のステートメントを表す。

ＲＤＦは、特定の使用ドメインについての仮定が行われない、ドメイン独立型である。ＲＤＦスキーマ（ＲＤＦＳ）と呼ばれるスキーマ言語で独自の用語を定義することは、ユーザ次第である。ＲＤＦＳは、ＲＤＦデータモデルで使用される語彙を定義する。ＲＤＦＳでは、語彙を定義し、どのプロパティがどの種類のオブジェクトに適用されるか、およびそれらがどのような値をとるかを特定し、オブジェクト間の関係を記述することができる。

Ｗ３Ｃによって定義されるコアクラスは、以下である。
・ｒｄｆｓ：Ｒｅｓｏｕｒｃｅ、全てのリソースのクラス
・ｒｄｆｓ：Ｃｌａｓｓ、全てのクラスのクラス。クラスに属する個人のグループは同一のプロパティを共有する。
・ｒｄｆｓ：Ｌｉｔｅｒａｌ、全てのリテラル（文字列）のクラス
・ｒｄｆ：Ｐｒｏｐｅｒｔｙ、全てのプロパティのクラス
・ｒｄｆ：Ｓｔａｔｅｍｅｎｔ、全ての具体化されたステートメントのクラス
Ｗ３Ｃによって定義されるコアプロパティは、以下である。
・ｒｄｆ：ｔｙｐｅ、リソースをそのクラスに関係付ける。リソースは、そのクラスのインスタンスであることが宣言される。
・ｒｄｆｓ：ｓｕｂＣｌａｓｓＯｆ、クラスをその上位クラスのうちの１つに関係付ける。クラスのインスタンスは、その上位クラスのインスタンスである。
・ｒｄｆｓ：ｓｕｂＰｒｏｐｅｒｔｙＯｆ、プロパティをそのスーパープロパティのうちの１つに関係付ける。
・ｒｄｆｓ：ｄｏｍａｉｎ、プロパティＰのドメイン、またはトリプルの中のプロパティの特定対象を特定する。
・ｒｄｆｓ：ｒａｎｇｅ、プロパティＰの範囲を特定する。述語Ｐを伴ってトリプルの中の値として出現し得る、これらのリソースのクラス。

Ｍ２Ｍシステムならびに背景技術としてのＲＤＦおよびＲＤＦＳの先述の議論により、本願は、Ｍ２Ｍシステムにおけるセマンティックサポートおよび管理のためのシステムおよび方法を対象とする。

本明細書では、マシンツーマシン（Ｍ２Ｍ）システムにおいてセマンティクスサポートを提供する、セマンティクスノード機能のための方法、デバイス、およびシステムが開示される。セマンティクスノードを伴うＭ２Ｍアーキテクチャ、ならびにセマンティクスノードのアーキテクチャが提案される。本開示は、とりわけ、セマンティクスノード基準点（ｓＩｓ、ｓＩｅ、ｓＩｃ）、セマンティクスノードプロシージャ、およびセマンティクスノードメッセージを定義する。

加えて、複合データタイプに関する問題が、セマンティクス関連リソースの構造および表現と、リソースをセマンティクス関連リソースと結び付けて関連付けることによりリソースに対してセマンティクスを有効にする方法とによって、本明細書で対処され得る。別の側面では、問題は、複合データタイプの中のフィールドが抽出され、解釈されることができるように、制限／ファセット単位および記述を伴うＸＳＤの拡張を可能にする機構を介して対処され得る。さらに別の側面では、問題は、記述／属性（それを発見可能かつ解釈可能にするデータタイプのキーワード、および各々への値が適切に定量化されることができるようなデータタイプの中の各フィールドの単位等）を、データタイプの名前および複合データタイプの中のフィールドに組み込むことによって対処され得る。

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

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

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

このセマンティック認識の不足は、たとえデータが起源であったアプリケーションのいかなる予備知識がなくても、異なるアプリケーションによって発見、アクセス、解釈、および共有されることができるように、Ｍ２Ｍアプリケーションによって生成されるデータがＭ２Ｍサービス層によって効果的に抽象化または仮想化されることを可能にするサービスを、Ｍ２Ｍサービス層が提供することを妨げる。結果として、感知および作用される物理的エンティティ（例えば、アプライアンス、人、車、建築物の部屋等）は、Ｍ２Ｍサービス層によって効果的に仮想化／抽象化されない場合があり、物理的エンティティは、環境に固有であり、特定のＭ２Ｍアプリケーションに関係しない一般的エンティティとして扱われる。

この制限を克服するために、Ｍ２Ｍシステムにおいて伝送されるデータは、セマンティック認識Ｍ２Ｍサービス層がＭ２Ｍアプリケーションと同じデータの知識を有することができるように、セマンティック情報に関連付けられ、統合される必要がある。そうすることで、Ｍ２Ｍサービス層は、アプリケーションにわたるデータの共有をより良好に促進し、付加価値のあるセマンティック認識サービスをＭ２Ｍアプリケーションに提供することができる（例えば、データ集約、異なるアプリケーション間のデータ共有等）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜ｓｃｌＢａｓｅ＞リソース３６１の下のクラス、関係、およびターム集合はそれぞれ、ローカルＳＣＬ上でホストされるセマンティクス関連リソースのそれぞれのインスタンスを含み得る。＜Ｓｓｃｌ＞は、本明細書で議論されるように、セマンティクス関連リソースのルートの名前として使用される。ルートは、例示的な命名であり、本明細書で議論されるように命名される必要はない。各インスタンスは、セマンティック表現を含むとともに、タグ等の発見関連情報等のそれに関連付けられる他の属性を有し得る。セマンティクス関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされ得る。

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

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

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

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

（オントロジー言語）
セマンティックウェブは、語彙、分類、およびオントロジーの能力を提供するために、スキーマ言語とオントロジー言語との組み合わせを使用すると言われ得る。語彙は、通信で使用される明確に定義されたタームの集合と見なされ得る。分類は、タームが階層様式で組織化される語彙と見なされ得る。各タームは、分類の中の１つ以上の他の要素と親子関係を共有し得る。オントロジーは、概念および規定関心分野に対する概念間の関係またはそれ以上を定義するために、タームの所定の確保された語彙を使用する。オントロジーは、実際には、語彙、分類、またはそれ以上のもののいずれかを指すことができる。典型的には、タームは、知識ドメインを記述するための豊富な形式論理ベースのモデルを指す。オントロジーを使用して、語彙タームの背後のセマンティクス、それらの相互作用、および使用の文脈を表現することができる。

ＲＤＦスキーマ（ＲＤＦＳ）は、クラスおよびプロパティの分類、ならびにプロパティのための単純なドメインおよび範囲仕様を定義するために使用されることができる、ＲＤＦのための具体的語彙を提供する。ウェブオントロジー言語（ＯＷＬ）は、ドメイン知識のセマンティクスを捕捉するオントロジーを定義するための表現言語を提供する。

要約すると、以前に議論されたように、ＲＤＦは、ウェブで情報を表すためのフレームワークである。ＲＤＦは、本質的に、データモデルである。その基礎的構成要素は、ステートメントと呼ばれる、リソース・プロパティ・値のトリプルである。ＲＤＦは、ＸＭＬで構文を与えられている。図２７に示される例では、ステートメントは、以下で示されるようにＲＤＦで表されることができる、Ｊｏｈｎ Ｓｍｉｔｈの肩書が教授であることである。ｘｍｌｎｓ：ｕｎｉは、プロパティ（名前および肩書）がＲＤＦＳの一部として定義される、自己定義されたドメイン名である。
＜ｒｄｆ：ＲＤＦ
ｘｍｌｎｓ：ｒｄｆ＝“ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／０２／２２−ｒｄｆ−ｓｙｎｔａｘ−ｎｓ＃”
ｘｍｌｎｓ：ｘｓｄ＝“ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＬＭＳｃｈｅｍａ＃”
ｘｍｌｎｓ：ｕｎｉ＝“ｈｔｔｐ：／／ｗｗｗ．ｍｙｄｏｍａｉｎ．ｏｒｇ／ｕｎｉ−ｎｓ”＞
＜ｒｄｆ：Ｄｅｓｃｒｉｐｔｉｏｎ ｒｄｆ：ａｂｏｕｔ＝“９４９３５２”＞
＜ｕｎｉ：ｎａｍｅ＞Ｊｏｈｎ Ｓｍｉｔｈ＜／ｕｎｉ：ｎａｍｅ＞
＜ｕｎｉ：ｔｉｔｌｅ＞Ｐｒｏｆｅｓｓｏｒ＜／ｕｎｉ：ｔｉｔｌｅ＞
＜／ｒｄｆ：Ｄｅｓｃｒｉｐｔｉｏｎ＞
＜／ｒｄｆ：ＲＤＦ＞
ＲＤＦは、特定の使用ドメインについての仮定が行われない、ドメイン独立型である。ＲＤＦＳと呼ばれるスキーマ言語で独自の用語を定義することは、ユーザ次第である。ＲＤＦＳは、ＲＤＦデータモデルで使用される語彙を定義する。ＲＤＦＳでは、語彙を定義し、どのプロパティがどの種類のオブジェクトに適用されるか、およびそれらがどのような値をとることができるかを規定し、オブジェクト間の関係を記述することができる。

ＯＷＬは、ウェブのためのより多くの表現オントロジーを構築するために使用されることができる、追加のリソースを用いてＲＤＦＳ語彙を拡張する。ＯＷＬは、処理をより計算上決定可能にするために、ＲＤＦ文書の構造およびコンテンツに関する追加の制限を導入する。ＯＷＬは、ＲＤＦおよびＲＤＦＳ、ＸＭＬスキーマデータタイプ、ならびにＯＷＬ名前空間を使用する。ＯＷＬ語彙自体は、名前空間ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／０７／ｏｗｌ＃において定義され、一般的にプレフィックスｏｗｌによって参照される。ＯＷＬ２は、元のＯＷＬ語彙を拡張し、同一の名前空間を再利用する。

データタイプは、ＵＲＩを使用して識別されるデータ値の範囲を表す。ＯＷＬは、殆どがＸＭＬスキーマ定義（ＸＳＤ）名前空間において定義される、いくつかの所定のデータタイプを使用することを可能にする。

ＯＷＬは、クラスｒｄｆｓ：Ｄａｔａｔｙｐｅのインスタンスを作成し、１つ以上のファセット制限をインスタンスに関連付けることによって、独自のデータタイプを定義することを可能にする。ファセット制限は、有効値の範囲を構成する具体的データタイプの値のセットを記述する方法である。表３は、ＯＷＬによってサポートされるファセットを含む。

複合タイプは、その要素およびテキスト子ならびにその属性を含む、要素の許可されたコンテンツを記述する。複合タイプ定義は、属性使用のセットおよびコンテンツモデルから成る。複合タイプは、制限（ベースタイプが許可するいくつかの要素、属性、または値を無効にする）によって、または拡張（追加の属性および要素が出現することを可能にする）によって、別の複合タイプから導出されることができる。（データタイプとも呼ばれる）単純タイプは、要素または属性に出現し得るテキスト値を制約する。

Ｗ３Ｃ ＸＭＬスキーマ定義言語（ＸＳＤ）は、１９個の基本データタイプのセット（ａｎｙＵＲＩ、ｂａｓｅ６４Ｂｉｎａｒｙ、ブール、日付、ｄａｔｅＴｉｍｅ、小数、２倍、持続時間、浮動、ｈｅｘＢｉｎａｒｙ、ｇＤａｙ、ｇＭｏｎｔｈ、ｇＭｏｎｔｈＤａｙ、ｇＹｅａｒ、ｇＹｅａｒＭｏｎｔｈ、ＮＯＴＡＴＩＯＮ、ＱＮａｍｅ、文字列、および時間）を提供する。これは、新しいデータタイプが３つの機構によってこれらの基本要素から構築されることを可能にする。
・ 制限（許可された値のセットを削減する）
・ リスト（一連の値を可能にする）
・ 融合（いくつかのタイプからの値の選択を可能にする）
以下は、ＸＳＤでデータタイプを定義する２つの例である。
例１：
＜ｓｉｍｐｌｅＴｙｐｅ ｎａｍｅ＝“Ｔｅｍｐｅｒａｔｕｒｅ”＞
＜ｒｅｓｔｒｉｃｔｉｏｎ ｂａｓｅ＝“ｉｎｔｅｇｅｒ”＞
＜／ｒｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓｉｍｐｌｅＴｙｐｅ＞
例２：
＜ｃｏｍｐｌｅｘＴｙｐｅ ｎａｍｅ＝“ＢｌｏｏｄＰｒｅｓｓｕｒｅ”＞
＜ｓｅｑｕｅｎｃｅ＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｓ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｄ” ｔｙｐｅ ＝“ｉｎｔｅｇｅｒ”／＞
＜／ｓｅｑｕｅｎｃｅ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
セマンティクス関連リソースの構造および属性が、さらに詳細に議論される。加えて、Ｍ２Ｍシステムにおける正規リソースに対してセマンティクスを有効にするためにこれらのリソースを使用する方法に関して、機構およびプロシージャが規定される。

Ｍ２Ｍシステム内のリソースのコンテンツは、通常、ＸＳＤ規格で定義されるような既存の基本的なもの以外の複合データタイプである。したがって、各個々のリソースのセマンティクスを定義することなく、同じタイプのリソースが同一のセマンティクスに従い、解釈されることができる（例えば、セマンティクスグループ化最適化）ように、複合データタイプのセマンティクスを定義することが自然である。ＯＷＬは、クラスｒｄｆｓ：Ｄａｔａｔｙｐｅのインスタンスを作成し、１つ以上のファセット制限をインスタンスに関連付けることによって、独自のデータタイプを定義することを可能にするが、新しい複合データタイプを定義することにおいて手段を提供しない。換言すると、新たに定義されるデータタイプは、基本的タイプから拡張されることに限定され得る。ＸＳＤは、新しいデータタイプが、制限、リスト、および融合によって１９個の基本要素から構築されることを可能にするが、リソースのコンテンツを理解するための十分な制限を提供することはできない。したがって、ＸＳＤによって複合データタイプ内のフィールドに提供されるセマンティクスは、非常に限定される。以下は、２つの例を示し、１つは、単純データタイプであり、もう１つは、ＸＳＤによって定義される複合データタイプである。

ＸＳＤに関して本明細書で議論されるように、例１は、そのようなデータタイプの値が全て整数であることを定義するために、標準制限のうちの１つを使用する、単純Ｔｅｍｐｅｒａｔｕｒｅデータタイプである。しかしながら、既存の制限ファセットは、温度示度値が摂氏、華氏、または何か他の単位であるかどうかが依然として曖昧であるように、値の単位を制限することができない。

例２は、それぞれが整数で値を有する、２つのフィールド‘ｓ’および‘ｄ’を順に有することを定義するために、リスト機構を使用する、複合ＢｌｏｏｄＰｒｅｓｓｕｒｅデータタイプである。しかしながら、既存の制限ファセットは、各フィールドの単位を制限することができない。そしてシーケンスの中の要素の名前から、何が複合データに含まれる２つのフィールドであるかが把握されることができない。したがって、異なるアプリケーションがコンテンツインスタンスの中のインスタンスを理解および解釈することは可能ではない場合がある。

要約すると、前述の問題は、セマンティクス関連リソースの構造および表現と、リソースをセマンティクス関連リソースと結び付けて関連付けることによって、リソースに対してセマンティクスを有効にする方法とによって、本明細書で対処され得る。加えて、問題は、複合データタイプの中のフィールドが抽出されて解釈されることができるように、制限／ファセット単位および記述を伴うＸＳＤの拡張を可能にする機構を介して対処され得る。最後に、問題は、それを発見可能かつ解釈可能にするデータタイプのキーワード、および各々に対する値が適切に定量化されることができるようなデータタイプの中の各フィールドの単位等の記述／属性をデータタイプの名前および複合データタイプの中のフィールドに組み込むことによって、対処され得る。

リソース構造は、以降でさらに詳細に議論されるであろう。実施例では、セマンティクスノードは、現在のＥＴＳＩ Ｍ２ＭアーキテクチャのｘＳＣＬで使用されるような補完的リソース構造をサポートし得る。セマンティクスノードのリソース構造の実施例は、図１７に示される。リソース＜Ｓｓｃｌ＞は、ホスティングセマンティクスノード上に存在するリソースツリーのルートである。＜Ｓｓｃｌ＞は、本明細書で議論されるようなセマンティクス関連リソースのルートの名前として使用される。ルートは、例示的な命名であり、本明細書で議論されるように命名される必要はない。＜Ｓｓｃｌ＞リソースは、ホスティングセマンティクスノードを記述する属性を含み得る。＜Ｓｓｃｌ＞リソースは、＜ＳＳ＞リソース（他のセマンティクスノードからの通知されたセマンティクス関連リソース）、＜ｃｌａｓｓ＞リソース、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソース、＜ｔｅｒｍ＞リソース、＜ａｃｃｅｓｓＲｉｇｈｔ＞リソース、および＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの集合を表す集合リソースを含む。

Ｍ２Ｍシステム内で、複数のタイプのリソースが存在することができる。以下、すなわち、クラス＜ｃｌａｓｓ＞、関係＜ｒｅｌａｔｉｏｎｓｈｉｐ＞、およびターム＜ｔｅｒｍ＞のうちのいくつかを含み得るセマンティクス関連リソースがあり得る。セマンティクス関連リソースは、セマンティクスノード上に記憶されたリソースを指す。別様に、リソースは、正規リソースを指すために使用され得る。正規リソースは、ＣＳＥＢａｓｅ、アプリケーションエンティティ（ＡＥ）、コンテナ、およびｏｎｅＭ２Ｍアーキテクチャで定義されるｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ等のうちのいくつかを含み得る。そして類似リソースが、ＥＴＳＩ Ｍ２Ｍアーキテクチャでも採用され得る。

以下では、本開示で提案される機構およびプロシージャを図示し得る図２８に示されるようなジム使用事例を説明する。例えば、アプリケーション、サービス層（ＳＬ）という用語の使用は、それぞれ、ｏｎｅＭ２ＭにおけるＡＥ、ＣＳＥ、またはＥＴＳＩ Ｍ２ＭにおけるＤＡ／ＧＡ／ＮＡ、ＤＳＣＬ／ＧＳＣＬ／ＮＳＣＬにマップされ得る。図２８は、同一の用語を用いて使用事例に関与するエンティティ構成を図示する。

ジム使用事例では、ユーザが、腕時計アプリケーション７１１を有する腕時計７１０を有する。腕時計７１０は、ユーザの電話ＳＬ７１３を発見し、それに登録する。トレッドミルアプリケーション７１４は、ジム内の１つ以上のトレッドミル７１５上にあり得る。周囲センサ７１６は、トレッドミル７１５上に、およびジム全体にあり得る。周囲センサ７１６は、ジムＳＬ７１８を発見し、それに登録し得る。そしてユーザがジムにいるとき、電話ＳＬ７１３は、ジムＳＬ７１８を発見し、それに登録し得る。電話７１２上のジムアプリケーション７２１は、トレッドミル７１５を発見し、ジムＳＬ７１８を介して、使用するトレッドミル７１５のうちの１つを選択することが可能であり得る。電話７１２上のジムアプリケーション７２１は、トレッドミル７１５を発見し、トレッドミルアプリケーション７１４のセマンティクスを把握することによって、使用するトレッドミル７１５のうちの１つを選択し得る。

電話７１２上の健康保険アプリケーション７２２は、周囲センサ７１６からデータ（例えば、ジム内の温度または湿度）、腕時計７１０から測定（例えば、ユーザの心拍数、血圧）、またはトレッドミル７１４からユーザによって終了されたジムトレーニングプログラムを収集する。健康保険アプリケーション７２２は、収集されたデータに基づいてユーザの健康スコアを計算し、健康スコアを健康保険会社アプリケーション７２４に共有し得る。電話７１２上の健康保険アプリケーション７２２はまた、データ（例えば、健康スコア、運動結果）に基づいてユーザの保険料を決定および調節することができる健康保険会社アプリケーション７２４に、ユーザの終了したジムトレーニングプログラムを送信し得る。健康保険アプリケーション７２２および健康保険会社アプリケーション７２４は、データの適切に追加されて有効にされたセマンティクスを使用することによって、データの同一の解釈を有し得る。

本明細書では、正規リソースに対してセマンティクスを有効にするセマンティクス機能のサービス層（ＳＬ）サポートが議論される。セマンティクス関連リソースの詳細な構造、およびどのようにしてセマンティクス関連リソースが、正規リソースに対してセマンティクスを有効にするかが開示される。

＜ｃｌａｓｓ＞のリソースツリー構造が、図２９に示される。＜ｃｌａｓｓ＞リソースは、リソース・関数・値のトリプル（Ｖａｌｕｅ）の一部としてリソースのセマンティクスを定義するために使用される。表４は、＜ｃｌａｓｓ＞の子リソースを示す。表５は、＜ｃｌａｓｓ＞の属性を示す。

複合データタイプは、＜ｃｏｎｔａｉｎｅｒ＞リソースの下に記憶されたコンテンツインスタンスを解析するために必要とされるデータ構造を定義する、特殊なクラスである。＜ｃｌａｓｓ＞リソースのタイプ属性は、それがｄａｔａＴｙｐｅであるかどうかを示すために使用される。それがｄａｔａＴｙｐｅである場合、ｄｅｓｃｒｉｐｔｉｏｎ属性が、ある構文を使用することによってデータ構造を記述するために使用される。ＸＳＤは、オプションのうちの１つである。それがｄａｔａＴｙｐｅではない場合、ｄｅｓｃｒｉｐｔｉｏｎ属性が、ある言語でクラスを定義するために使用される。ＲＤＦは、オプションのうちの１つである。ＲＤＦはまた、ＸＭＬ構文を有し得る。構文属性は、使用され得る可能なｓｙｎｔａｘを示すために使用される。例えば、ＸＭＬは、単純および複合データタイプを記述するためにＸＳＤで使用されるパターンに従うことを意味し得る。ＸＭＬにおけるＲＤＦは、クラスがＸＭＬ構文を用いてＲＤＦ言語で記述されることを意味し得る（ＸＭＬに基づかない、ＲＤＦの他の統語表示も可能である）。文字列は、記述属性が、クラスを記述するいくつかの言葉のみを与えることを意味し得る。

＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースのＵＲＩの値をとるであろう、ｐｒｏｐｅｒｔｉｅｓ属性は、随意である。クラスに関連付けられるプロパティは、複合データタイプまたは非複合データタイプであり得る。

ＸＳＤの拡張が、記述ファセットおよび単位ファセットである複合データタイプ内の各要素を解釈するように、制限／ファセットを用いて可能にされ得る。記述ファセットは、要素を認識し、要素がどのようなものであるかを理解することにおいてアプリケーションを支援する、可能なキーワードを含む、要素の簡潔な記述を与えるために使用され得る。単位ファセットは、要素の単位を規定するために使用される。以前の例１および例２の更新されたバージョンが、以下に示される。
例１Ａ−記述および単位ファセット：
＜ｓｉｍｐｌｅＴｙｐｅ ｎａｍｅ＝“Ｔｅｍｐｅｒａｔｕｒｅ”＞
＜ｒｅｓｔｒｉｃｔｉｏｎ＞
ｄｅｓｃｒｉｐｔｉｏｎ ＝“ｔｅｍｐｅｒａｔｕｒｅ ｉｎ Ｃｅｌｓｉｕｓ” ｕｎｉｔ＝“Ｃｅｌｓｉｕｓ” ｂａｓｅ＝“ｉｎｔｅｇｅｒ”
＜／ｒｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓｉｍｐｌｅＴｙｐｅ＞
例２Ａ−記述および単位ファセット：
＜ｃｏｍｐｌｅｘＴｙｐｅ ｎａｍｅ＝“ＢｌｏｏｄＰｒｅｓｓｕｒｅ”＞
＜ｓｅｑｕｅｎｃｅ＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｓｙｓｔｏｌｉｃ” ｄｅｓｃｒｉｐｔｉｏｎ＝“ｓｙｓｔｏｌｉｃ ｒｅａｄｉｎｇ” ｕｎｉｔ＝“ｍｍＨＧ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｄｉａｓｔｏｌｉｃ” ｄｅｓｃｒｉｐｔｉｏｎ＝“ｄｉａｓｔｏｌｉｃ ｒｅａｄｉｎｇ” ｕｎｉｔ＝“ｍｍＨＧ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜／ｓｅｑｕｅｎｃｅ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
記述／属性が、データタイプおよびその要素の名前に組み込まれ得る。データタイプ名およびデータタイプの要素の名前は、データタイプおよびその要素を解釈することに関してアプリケーションを支援する情報を含み得る。データタイプおよびその要素の名前の形式は、表６のようであり得る。結果として、以前の例１および例２の更新されたバージョンは、以下の通りである。
例１Ｂ−記述／属性をデータタイプおよびその要素の名前に組み込む：
＜ｓｉｍｐｌｅＴｙｐｅ ｎａｍｅ＝“ＴｅｍｐｅｒａｔｕｒｅＩＮＣｅｌｓｉｕｓ”＞
＜ｒｅｓｔｒｉｃｔｉｏｎ ｂａｓｅ＝“ｉｎｔｅｇｅｒ”＞
＜／ｒｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓｉｍｐｌＴｙｐｅ＞
例２Ｂ−記述／属性をデータタイプおよびその要素の名前に組み込む：
＜ｃｏｍｐｌｅｘＴｙｐｅ ｎａｍｅ＝“ＢｌｏｏｄＰｒｅｓｓｕｒｅ”＞
＜ｓｅｑｕｅｎｃｅ＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｓｙｓｔｏｌｉｃＩＮｍｍＨＧ” ｔｙｐｅ＝“ｉｎｔｅｇｅｒ”／＞
＜ｅｌｅｍｅｎｔ ｎａｍｅ＝"ｄｉａｓｔｏｌｉｃＩＮｍｍＨＧ” ｔｙｐｅ ＝“ｉｎｔｅｇｅｒ”／＞
＜／ｓｅｑｕｅｎｃｅ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞

＜ｒｅｌａｔｉｏｎｓｈｉｐ＞のリソースツリー構造が、図３０に示される。＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースは、クラスに関連付けられることができるプロパティを定義するために使用され得る。換言すると、＜ｃｌａｓｓ＞リソースのプロパティ属性は、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースのリンクを含み得る。＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースはまた、リソース・関係・値のトリプル（Ｒｅｌａｔｉｏｎｓｈｉｐ）の一部としてリソースのセマンティクスを定義するために使用される。表７は、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞の子リソースを示す。表８は、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞の属性を示す。

＜ｔｅｒｍ＞のリソースツリー構造が、図３１に示される。＜ｔｅｒｍ＞リソースは、リソース・関係・値のトリプル（Ｖａｌｕｅ）の一部としてリソースのセマンティクスを定義するために使用され得る。表９は、＜ｔｅｒｍ＞の子リソースを示す。表１０は、＜ｔｅｒｍ＞の属性を示す。

セマンティクス関連リソース能力は、例えば、ｏｎｅＭ２Ｍリソース構造、＜ＣＳＥＢａｓｅ＞、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞等において、Ｍ２Ｍシステム内の正規リソースに関連付けられて結び付けられ、セマンティクス記述をこれらのリソースに提供することができる。正規リソースは、リソース、関係、および値から成る、リソース・関係・値のトリプルの集合によって記述され得る。値は、クラス、ターム、または他のリソースであり得る。これらのトリプルにおいて、リソース自体は固定されており、既知であるため、追加され得るものは、関係・値のダブルの集合等である。別のｓｅｍａｎｔｉｃｓ属性が、既存のｓｅａｒｃｈＳｔｒｉｎｇｓ属性を補完してセマンティクスを有効にするために使用（すなわち、追加）され得る。どのようにしてセマンティクスがｏｎｅＭ２Ｍリソース構造において＜ＡＥ＞および＜ｃｏｎｔａｉｎｅｒ＞リソースのために有効にされるかが、ここで議論される。

＜ＡＥ＞リソースに対してセマンティクスを有効にするために、ｒｄｆ：ｔｙｐｅは、＜ＡＥ＞リソースを、識別子およびｐｒｏｄｕｃｅｄＤａｔａのプロパティを有する本明細書で定義されるような＜ＤｅｖｉｃｅＡｐｐ＞クラスに関係付ける。Ｗ３Ｃ ＲＤＦＳがｒｄｆ：ｔｙｐｅのコアプロパティをすでに定義しているため、プレフィックスのうちの１つにｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／０２／２２−ｒｄｆ−ｓｙｎｔａｘ−ｎｓ＃を含む場合、それを外部関係のうちの１つとして使用し得る。一方、セマンティクスノードにおいてそのような類似関係を定義することに制限はない。ｓｅｍａｎｔｉｃｓ属性は、＜ＡＥ＞リソースのセマンティクス記述を記憶するために使用される。本実施例では、図３２に示されるように、アプリケーションは、ｗａｔｃｈＯｆＪｏｈｎＳｍｉｔｈの識別と血圧のｐｒｏｄｕｃｅｄＤａｔａとを有する腕時計である。結果として、セマンティクス属性には、複数のアイテムがある。第１のアイテムは、＜ｗａｔｃｈＡＥ＞４３１が＜ＤｅｖｉｃｅＡｐｐ＞のタイプを有することを示す。そして＜ＤｅｖｉｃｅＡｐｐ＞クラス記述から、それに関連付けられる複数のプロパティがある。したがって、第２および第３のアイテムは、値をこれらのプロパティに割り付けるためである。

プレフィックスは、以下のように定義され得る。
＠ｐｒｅｆｉｘ ｒｅｌａｔｉｏｎｓｈｉｐ：＜Ｓｓｃｌ＞／ｒｅｌａｔｉｏｎｓｈｉｐｓ／
＠ｐｒｅｆｉｘ ｃｌａｓｓ：＜Ｓｓｃｌ＞／ｃｌａｓｓｅｓ／
したがって、セマンティクス属性は、以下のように供給され得る。
ｒｄｆ： ｔｙｐｅ ｃｌａｓｓ／ＤｅｖｉｃｅＡｐｐ ４３３
ｒｅｌａｔｉｏｎｓｈｉｐ／ｉｄｅｎｔｉｆｉｅｒ “ｗａｔｃｈＯｆＪｏｈｎＳｍｉｔｈ” ４３４
ｒｅｌａｔｉｏｎｓｈｉｐ／ｐｒｏｄｕｃｅｄＤａｔａ “ｂｌｏｏｄ ｐｒｅｓｓｕｒｅ” ４３５
＜ｃｏｎｔａｉｎｅｒ＞リソースのセマンティクスは、そのコンテナの下の個々の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースに適用され得る。これは、類似リソースのグループのセマンティクスを記述することにおいてグループ化最適化と見なされる。

例えば、血圧監視データの複数のインスタンスが、同一のセマンティクスを有し得る。したがって、各コンテンツインスタンスは、以下に示されるように同一のセマンティクスに関連付けられ得る（ＢｌｏｏｄＰｒｅｓｓｕｒｅクラスは、ＵＲＩ Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅを用いてここで定義されている）。Ｓｓｃｌは、図１７のｓｓＢａｓｅと同一でもある、本明細書で議論されるようなルートの単なるもう１つの名前であることに留意されたい。
・＜ＣＳＥＢａｓｅ１＞／ｂｐＡＥ／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ１＞ ｒｄｆ：ｔｙｐｅ Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅ
・＜ＣＳＥＢａｓｅ１＞／ｂｐＡＥ／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ２＞ ｒｄｆ：ｔｙｐｅ Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅ
・＜ＣＳＥＢａｓｅ１＞／ｂｐＡＥ／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ３＞ ｒｄｆ：ｔｙｐｅ Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅ
・・・・
グループ化最適化をサポートすることによって、以下の関連付けも有効である。
・＜ＣＳＥＢａｓｅ１＞／ｂｐＡＥ／＜ｂｐＣｏｎｔａｉｎｅｒ＞ ｒｄｆ：ｔｙｐｅ Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅ
＜ＢｌｏｏｄＰｒｅｓｓｕｒｅ＞クラスは、本明細書で定義されるようなデータタイプである、特殊な＜ｃｌａｓｓ＞リソースである。具体的には、コンテンツインスタンスは、そのコンテンツ属性に２つのフィールド、すなわち、ｓｙｓｔｏｌｉｃＩＮｍｍＨＧおよびｄｉａｓｔｏｌｉｃＩＮｍｍＨＧを有する、ＢｌｏｏｄＰｒｅｓｓｕｒｅデータタイプを有する。図３３に示されるような本実施例では、ｓｅｍａｎｔｉｃｓ属性は、コンテナが＜ＢｌｏｏｄＰｒｅｓｓｕｒｅ＞のタイプを有するという情報を記憶するために使用される。

実施例として、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞は、＜ＣＳＥＢａｓｅ１＞／ｂｐＡＥ／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ１＞のＵＲＩを有する。＜ＢｌｏｏｄＰｒｅｓｓｕｒｅ＞クラスが、定義されてＳｓｃｌ上に記憶され、Ｓｓｃｌ／ｃｌａｓｓｅｓ／ＢｌｏｏｄＰｒｅｓｓｕｒｅのＵＲＩを有すると仮定する。図３４は、ＡＥ７３１（例えば、腕時計７１０の中の血圧モニタアプリ（図示せず））によって＜ｂｐＣｏｎｔａｉｎｅｒ＞コンテナを作成する例示的メッセージフローと、どのようにしてセマンティクスがＡＥ７３１によって有効にされるかとを示す。ステップ７３３では、ＡＥ７３１が、正規リソース（例えば、図３３に示されるような＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７）を作成するための要求をＣＳＥ７３２に送信する。ステップ７３４では、ＣＳＥ７３２が、＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７を作成し、ステップ７３５では、ＣＳＥ７３２が、＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７を作成することに関連付けられる確認をＡＥ７３１に送信する。ステップ７３６では、ＡＥ７３１が、＜ｂｐＣｏｎｔａｉｎｅｒ＞に関連付けられるセマンティクス情報を提供する。この状況では、ＡＥ７３１は、コンテナ（＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７）が血圧タイプを有するデータを含むというセマンティクス情報を提供する。ステップ７３７では、ＣＳＥ７３２が、図３３に示されるような＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７の属性（セマンティクス属性４３８）の中にセマンティクス情報を保ち得る。ステップ７３８では、ＣＳＥ７３２が、ステップ７３６のセマンティクス情報を受信することに関連付けられる確認をＡＥ７３１に送信し得る。ＡＥ７３１は、＜ｂｐＣｏｎｔａｉｎｅｒ＞４３７コンテナリソースのセマンティクス属性４３８の値を追加する。図３５は、コンテナに含まれるデータに関心がある別のアプリケーション（例えば、医師）の使用を図示する。

図３５は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースおよび血圧情報を所望し得る診療所に関連付けられ得る別のＡＥ７４１によるセマンティクス読み出しプロセスの例示的メッセージフローを示す。ステップ７４３では、ＡＥ７４１が、コンテンツインスタンス（例えば、・・・／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ１＞）に対する要求をＣＳＥ７３２に送信する。ステップ７４４では、ＣＳＥ７３２が、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースをＡＥ７４１に提供する。データを理解および解釈するために、アプリケーション（ＡＥ７４１）は、セマンティクス情報が欲しい。この場合、ステップ７４５では、ＡＥ７４１が、データ（例えば、・・・／＜ｂｐＣｏｎｔａｉｎｅｒ＞／＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ１＞）とともに記憶されたセマンティクス情報を読み出すように後続の要求をＣＳＥ７４２に送信する。ステップ７４６では、ＣＳＥ７３２が、セマンティクス情報を提供する。ステップ７４６のセマンティクス情報は、データが、この場合、クラスリソースとして定義される、あるタイプ（例えば、ｔｙｐｅ ｃｌａｓｓ／ｂｌｏｏｄ ｐｒｅｓｓｕｒｅ ４３９）を有するという情報を含む。ステップ７４７では、ＡＥ７４１が、このタイプ（クラスリソース）を理解するために、Ｓｓｃｌ７４２（セマンティクスノード）と通信する。ＡＥ７４１は、セマンティクスノードからクラスリソースの定義を読み出す。

本明細書で開示されるように、ジム使用事例に使用され得るセマンティクス関連リソースの実施例が、図３６に示される。識別子関係は、オブジェクト／エンティティ、例えば、アプリケーション、データ等に対する識別子を規定する。＜ｉｄｅｎｔｉｆｉｅｒ＞７５１関係リソースの属性（構文、検索文字列、記述）は、記述がＸＭＬにおけるＲＤＦＳで書かれている、表１１に示される。

生成されたデータ関係は、アプリケーションの生成されたデータを規定する。＜ｐｒｏｄｕｃｅｄＤａｔａ＞７５２関係リソースの属性（構文、検索文字列、記述）は、記述がＸＭＬにおけるＲＤＦＳで書かれている、表１２に示される。

上記で定義される識別子７５１および生成されたデータ７５２関係は、１つのクラスを別のクラスに、１つのクラスをそのプロパティに関係付けるために使用され得る。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスは、使用事例に関与するアプリケーションのクラスである。＜ＤｅｖｉｃｅＡｐｐ＞７５３は、ここで規定され、拡張可能であるものに限定されない属性を有し得る。腕時計アプリケーション７１１、トレッドミルアプリケーション７１４、および周囲センサアプリケーション７１７は、＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのインスタンスである。＜ＤｅｖｉｃｅＡｐｐ＞７５３は、識別子およびｐｒｏｄｕｃｅｄＤａｔａである、本明細書で定義される以下のプロパティを有する。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスリソースの属性（構文、検索文字列、プロパティ、ｎＯｆＰｒｏｐｅｒｔｉｅｓ、タイプ、および記述）は、それぞれ、記述が文字列またはＸＭＬにおけるＲＤＦＳで書かれるときに、表１３および１４に示される。

（例えば、図３７の＜ｗａｔｃｈ＞７６１のように関連付けられる）腕時計アプリケーション７１１は、＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスに定義されるプロパティを有する、＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのインスタンスである。腕時計アプリケーション７１１は、血圧データを生成することができる。
ＲＤＦ：

（例えば、図３８の＜ｓｅｎｓｏｒ＞７７１のように関連付けられる）周囲センサアプリケーション７１７は、＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスに定義されるプロパティを有する、＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのインスタンスである。周囲センサアプリケーション７１７は、温度データを生成することができる。
ＲＤＦ：

（例えば、図３８の＜ｔｒｅｄｍｉｌｌ＞７７５のように関連付けられる）トレッドミルアプリケーション７１４は、＜ＤｅｖｉｃｅＡｐｐ＞クラスに定義されるプロパティを有する、＜ＤｅｖｉｃｅＡｐｐ＞クラスのインスタンスである。トレッドミルアプリケーション７１４は、ユーザが終了するジムトレーニングプログラムデータを生成することができる。
ＲＤＦ：

電話７１２上の（例えば、図３７の＜ｈｅａｌｔｈＩｎｓｕｒａｎｃｅ＞７６５のように関連付けられる）健康保険アプリケーション７２２は、＜ＤｅｖｉｃｅＡｐｐ＞クラスに定義されるプロパティを有する、＜ＤｅｖｉｃｅＡｐｐ＞クラスのインスタンスである。健康保険アプリケーション７２２は、健康スコアデータを生成することができる。
ＲＤＦ：

＜ＢｌｏｏｄＰｒｅｓｓｕｒｅ＞７５４クラスは、データタイプである。これは、フィールドｓｙｓｔｏｌｉｃＩＮｍｍＨＧおよびｄｉａｓｔｏｌｉｃＩＮｍｍＨＧを有する。＜ＢｌｏｏｄＰｒｅｓｓｕｒｅ＞クラスリソースの属性（構文、検索文字列、タイプ、および記述）は、記述がＸＭＬで書かれている、表１５に示される。

図３６の＜ＴｅｍｐｅｒａｔｕｒｅＩｎＣｅｌｓｉｕｓ＞７５５クラスは、データタイプである。＜ＴｅｍｐｅｒａｔｕｒｅＩｎＣｅｌｓｉｕｓ＞７５５クラスリソースの属性（構文、検索文字列、タイプ、および記述）は、記述がＸＭＬで書かれている、表１６に示される。

＜ＧｙｍＴｒａｉｎｉｎｇＰｒｏｇｒａｍ＞７５６クラスは、データタイプである。これは、ｕｓｅｄＥｑｕｉｐｍｅｎｔＴｙｐｅ、ｕｓｅｄＥｑｕｉｐｍｅｎｔＬｅｖｅｌ、ｄｕｒａｔｉｏｎＩＮＭｉｎｕｔｅ、ｔａｒｇｅｔＨｅａｒｔＲａｔｅＩＮＰｅｒＭｉｎｕｔｅ、およびｃａｌｏｒｉｅＢｕｒｎＩＮＰｅｒＨｏｕｒのフィールドを有する。ｕｓｅｄＥｑｕｉｐｅｍｅｎｔＴｙｐｅは、トレーニングに使用されている機器のタイプを示す。ｕｓｅｄＥｑｕｉｐｍｅｎｔＬｅｖｅｌは、機器のどのレベルがトレーニングのために設定されたかを示す。ｄｕｒａｔｉｏｎＩＮＭｉｎｕｔｅは、トレーニングが分単位でどれくらいの時間であったかを示す。ｈｅａｒｔＲａｔｅＩＮＰｅｒＭｉｎｕｔｅは、トレーニング中の毎分の平均心拍数を示す。ｃａｌｏｒｉｅＢｕｒｎＩＮＰｅｒＨｏｕｒは、トレーニング中の毎時間の総カロリー燃焼を示す。＜ＧｙｍＴｒａｉｎｉｎｇＰｒｏｇｒａｍ＞７５６クラスリソースの属性（構文、検索文字列、タイプ、および記述）は、記述がＸＭＬで書かれている、表１７に示される。

＜ＨｅａｌｔｈＳｃｏｒｅ＞７５７クラスは、データタイプである。その値は、本実施例では、０〜１００の範囲を有する。＜ＨｅａｌｔｈＳｃｏｒｅ＞７５７クラスリソースの属性（構文、検索文字列、タイプ、および記述）は、記述がＸＭＬで書かれている、表１８に示される。

本明細書では、図３７および３８に関して、ｏｎｅＭ２Ｍリソース構造が例証目的で使用される。しかしながら、ＥＴＳＩ Ｍ２Ｍ等の他のＭ２Ｍアーキテクチャで定義されるリソースの実施例が、非常に類似し、ｏｎｅＭ２Ｍ実施例にも適用可能であり得る。図３７および３８に関する以下の議論は、図３４および３５に関して示されるような方法との関連で考察され得る。

実施例では、腕時計アプリケーション７１１が電話サービス層７１３（例えば、共通サービスエンティティ−ＣＳＥ、またはサービス層−ＳＬ）に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。腕時計は、ＤｅｖｉｃｅＡｐｐ７５３のタイプを有する。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのスキーマに従うことによって、腕時計アプリケーション７１１は、それが血圧データを生成し得ることを電話サービス層７１３に示す。電話ＳＬ７１３は、図３７に示されるように、腕時計７１０のためのアプリケーションリソースを作成し得る（例えば、＜ｗａｔｃｈ＞７６１）。腕時計アプリケーション７１１は、それが測定するデータをアップロードするために、電話ＳＬ７１３上にコンテナを作成する。腕時計アプリケーション７１１は、コンテンツインスタンスがＢｌｏｏｄＰｒｅｓｓｕｒｅ７５４のタイプを有することを示す。この＜ｂｌｏｏｄＰ＞７６２コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図３７に示されるように、各コンテンツインスタンスの代わりに＜ｂｌｏｏｄＰ＞７６２コンテナに関連付けられる。

同様に、健康保険アプリケーション７２２が電話ＳＬ７１３に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。健康保険アプリケーション７２２は、ＤｅｖｉｃｅＡｐｐ７５３のタイプを有する。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのスキーマに従うことによって、健康保険アプリケーション７２２は、それが健康スコアデータを生成し得ることを電話ＳＬ７１３に示す。電話ＳＬ７１３は、図３７に示されるように、健康保険アプリケーション７２２のためのアプリケーションリソースを作成し得る（例えば、＜ｈｅａｌｔｈＩｎｓｕｒａｎｃｅ＞７６５）。健康保険アプリケーション７２２は、それが計算するデータをアップロードするために、電話ＳＬ７１３上にコンテナを作成する。健康保険アプリケーション７２２は、コンテンツインスタンスがＨｅａｌｔｈＳｃｏｒｅ７５７のタイプを有することを示す。この＜ｈｅａｌｔｈＳ＞７６７コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図３７に示されるように、各コンテンツインスタンスの代わりに＜ｈｅａｌｔｈＳ＞７６７コンテナに関連付けられる。

周囲センサアプリケーション７１７がジムＳＬ７１８に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。周囲センサ７１６は、ＤｅｖｉｃｅＡｐｐ７５３のタイプを有する。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのスキーマに従うことによって、周囲センサ７１６は、それが温度データを生成することができることをジムＳＬ７１８に示す。ジムＳＬ７１８は、図３８に示されるように、周囲センサ７１６のためのアプリケーションリソースを作成し得る（例えば、＜ｓｅｎｓｏｒ＞７７１）。周囲センサアプリケーション７１７は、それが測定するデータをアップロードするために、ジムＳＬ７１８上にコンテナを作成する。周囲センサアプリケーション７１７は、コンテンツインスタンスがＴｅｍｐｅｒａｔｕｒｅＩＮＣｅｌｓｉｕｓ７５５のタイプを有することを示す。この＜ｔｅｍｐＲｅａｄｉｎｇ＞７７４コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図３８に示されるように、各コンテンツインスタンスの代わりに＜ｔｅｍｐＲｅａｄｉｎｇ＞７７４コンテナに関連付けられる。

同様に、トレッドミルアプリケーション７１４がジムＳＬ７１８に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。トレッドミル７１５は、ＤｅｖｉｃｅＡｐｐ７５３のタイプを有する。＜ＤｅｖｉｃｅＡｐｐ＞７５３クラスのスキーマに従うことによって、トレッドミル７１５は、それがジムトレーニングプログラムデータを生成し得ることをジムＳＬ７１８に示す。ジムＳＬ７１８は、図３８に示されるように、トレッドミル７１５のためのアプリケーションリソースを作成し得る（例えば、＜ｔｒｅａｄｍｉｌｌ＞７７５）。トレッドミルアプリケーション７１４は、それが測定するデータをアップロードするために、ジムＳＬ７１８上にコンテナを作成する。トレッドミルアプリケーション７１４は、コンテンツインスタンスがＧｙｍＴｒａｉｎｉｎｇＰｒｏｇｒａｍ７５６のタイプを有することを示す。この＜ＧｙｍＴｒａｉｎｉｎｇ＞７７７コンテナの下の各コンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図３８に示されるように、各コンテンツインスタンスの代わりに＜ＧｙｍＴｒａｉｎｉｎｇ＞７７７コンテナに関連付けられる。

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

本明細書に出現する請求項の範囲、解釈、または用途をいかようにも制限することなく、本明細書で開示される実施例のうちの１つ以上のものの技術的効果は、どのようにしてセマンティクスが管理されるかに調節を提供することである。セマンティクス情報（および関連知能）が、特殊なエンティティ（例えば、セマンティクスノード）によって取り扱われ、または記憶され得る。本明細書で開示される概念のうちの１つ以上のものの別の技術的効果としては、従来の実装と比較すると、ＣＳＥが本明細書で議論されるようなセマンティクスノードまたはセマンティクス階層をサポートする場合、セマンティクス情報がより効率的にアクセスされ、分配され、または記憶され得るように、より柔軟な方法でリソース階層が組織化されることができることである。

３ＧＰＰおよびＥＴＳＩ Ｍ２Ｍアーキテクチャが、本明細書で背景技術として説明され、本明細書に説明される主題を例証するために使用され得るが、本明細書に説明される主題の実装は、本開示の範囲内にとどまりながら変動し得ることが理解される。当業者はまた、開示された主題が上記で議論される３ＧＰＰまたはＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されず、むしろｏｎｅＭ２Ｍ、メッセージキューイングテレメトリトランスポート（ＭＱＴＴ）、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることも認識するであろう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図で図示されるような本開示の主題の好ましい方法、システム、または装置を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。例えば、セマンティクス関連リソース公表および発見の標的は兄弟および子であることが例証されるが、セマンティクスノードは、そのような関係を有していない場合がある、公表および発見のための他のセマンティクスノードを選択することができる。

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

とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン（Ｍ２Ｍ）システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データのためのセマンティクス情報を要求するための手段と、セマンティクス情報の要求に基づいて、データに関連付けられている（セマンティクス情報の実施例である）タイプを受信するための手段と、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。セマンティクス情報は、クラスリソースを備えている。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データに関連付けられているタイプが、第１のアプリケーションエンティティと適合性があるかどうかを決定するための手段を有し、データは、第２のアプリケーションエンティティからである。（ステップの除去または追加を含む）本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。

とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン（Ｍ２Ｍ）システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のアプリケーションエンティティによって、第２のアプリケーションエンティティに関連付けられているデータを受信するための手段と、第１のアプリケーションエンティティによって、データのためのセマンティクス情報を要求するための手段と、第１のアプリケーションエンティティによって、セマンティクス情報の要求に基づいて、データに関連付けられているタイプを受信するための手段と、第１のアプリケーションエンティティによって、データに関連付けられているタイプが、第１のアプリケーションエンティティと適合性があるかどうかを決定するための手段と、第１のアプリケーションエンティティとの適合性に基づいて、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。セマンティクス情報は、クラスリソースを備えている。第１のアプリケーションエンティティは、センサに関連付けられているアプリケーションを備えている。（ステップの除去または追加を含む）本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。

とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン（Ｍ２Ｍ）システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データのためのセマンティクス情報を要求するための手段と、セマンティクス情報の要求に基づいて、データに関連付けられているタイプを受信するための手段と、第１のアプリケーションエンティティによって、データに関連付けられているタイプが、第１のアプリケーションエンティティと適合性があるかどうかを決定するための手段と、第１のアプリケーションエンティティとの適合性に基づいて、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データに関連付けられているタイプが、第１のアプリケーションエンティティと適合性があるかどうかを決定するための手段を有し、データは、第２のアプリケーションエンティティからである。（ステップの除去または追加を含む）本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサと、
前記プロセッサと連結されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
データのためのセマンティクス情報を要求することと、
前記データのためのセマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
セマンティクスノードから前記セマンティクス情報に含まれるセマンティクス関連リソースの定義を要求することと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目２）
前記セマンティクス情報は、関係リソースを備えている、項目１に記載のデバイス。
（項目３）
前記関係リソースは、形式属性を備えている、項目２に記載のデバイス。
（項目４）
前記関係リソースは、記述属性を備えている、項目２に記載のデバイス。
（項目５）
前記セマンティクス情報は、タイプリソースを備えている、項目１に記載のデバイス。
（項目６）
前記タイプリソースは、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、項目５に記載のデバイス。
（項目７）
前記タイプリソースは、前記タイプの名前に組み込まれている記述を備えている、項目５に記載のデバイス。
（項目８）
前記セマンティクス情報は、クラスリソースを備えている、項目１に記載のデバイス。
（項目９）
前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、項目１に記載のデバイス。
（項目１０）
第１のアプリケーションエンティティによって、第２のアプリケーションエンティティに関連付けられているデータを受信することと、
前記第１のアプリケーションエンティティによって、前記データのためのセマンティクス情報を要求することと、
前記第１のアプリケーションエンティティによって、前記セマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
セマンティクスノードから前記セマンティクス情報の定義を要求することと
を含む、方法。
（項目１１）
前記セマンティクス情報は、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、項目１０に記載の方法。
（項目１２）
前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている記述を備えている、項目１０に記載の方法。
（項目１３）
前記セマンティクス情報は、クラスリソースを備えている、項目１０に記載の方法。
（項目１４）
前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、項目１０に記載の方法。
（項目１５）
前記第１のアプリケーションエンティティは、センサに関連付けられているアプリケーションを備えている、項目１０に記載の方法。
（項目１６）
コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータデバイスによって実行されると、
第１のアプリケーションエンティティによって、第２のアプリケーションエンティティに関連付けられているデータを受信することと、
前記第１のアプリケーションエンティティによって、前記データのためのセマンティクス情報を要求することと、
前記第１のアプリケーションエンティティによって、前記セマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
セマンティクスノードから前記セマンティクス情報の定義を要求することと
を含む動作を前記コンピュータデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
（項目１７）
前記セマンティクス情報は、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、項目１６に記載のコンピュータ読み取り可能な記憶媒体。
（項目１８）
前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている記述を備えている、項目１５に記載のコンピュータ読み取り可能な記憶媒体。
（項目１９）
前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている属性を備えている、項目１５に記載のコンピュータ読み取り可能な記憶媒体。
（項目２０）
前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、項目１５に記載のコンピュータ読み取り可能な記憶媒体。

Claims (20)

1. プロセッサと、
   前記プロセッサと連結されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   データのためのセマンティクス情報を要求することと、
   前記データのためのセマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
   セマンティクスノードから前記セマンティクス情報に含まれるセマンティクス関連リソースの定義を要求することと
   を含む動作を前記プロセッサに達成させる、デバイス。
2. 前記セマンティクス情報は、関係リソースを備えている、請求項１に記載のデバイス。
3. 前記関係リソースは、形式属性を備えている、請求項２に記載のデバイス。
4. 前記関係リソースは、記述属性を備えている、請求項２に記載のデバイス。
5. 前記セマンティクス情報は、タイプリソースを備えている、請求項１に記載のデバイス。
6. 前記タイプリソースは、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、請求項５に記載のデバイス。
7. 前記タイプリソースは、前記タイプの名前に組み込まれている記述を備えている、請求項５に記載のデバイス。
8. 前記セマンティクス情報は、クラスリソースを備えている、請求項１に記載のデバイス。
9. 前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、請求項１に記載のデバイス。
10. 第１のアプリケーションエンティティによって、第２のアプリケーションエンティティに関連付けられているデータを受信することと、
    前記第１のアプリケーションエンティティによって、前記データのためのセマンティクス情報を要求することと、
    前記第１のアプリケーションエンティティによって、前記セマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
    セマンティクスノードから前記セマンティクス情報の定義を要求することと
    を含む、方法。
11. 前記セマンティクス情報は、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、請求項１０に記載の方法。
12. 前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている記述を備えている、請求項１０に記載の方法。
13. 前記セマンティクス情報は、クラスリソースを備えている、請求項１０に記載の方法。
14. 前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、請求項１０に記載の方法。
15. 前記第１のアプリケーションエンティティは、センサに関連付けられているアプリケーションを備えている、請求項１０に記載の方法。
16. コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータデバイスによって実行されると、
    第１のアプリケーションエンティティによって、第２のアプリケーションエンティティに関連付けられているデータを受信することと、
    前記第１のアプリケーションエンティティによって、前記データのためのセマンティクス情報を要求することと、
    前記第１のアプリケーションエンティティによって、前記セマンティクス情報の要求に応答して、前記データに関連付けられている前記セマンティクス情報を受信することと、
    セマンティクスノードから前記セマンティクス情報の定義を要求することと
    を含む動作を前記コンピュータデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
17. 前記セマンティクス情報は、前記データに関連付けられている単位を記述するキーワードを備えている名前を有する、請求項１６に記載のコンピュータ読み取り可能な記憶媒体。
18. 前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている記述を備えている、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
19. 前記セマンティクス情報は、前記セマンティクス情報の名前に組み込まれている属性を備えている、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記データは、前記セマンティクス情報とともにリソース階層において記憶されている、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。

Images