現在のM2Mシステムでは、(デバイスならびにバックエンドネットワークサーバ上でホストされる)M2Mアプリケーションは、交換されるデータの共通定義について事前に合意する必要がある。これは主に、アプリケーションの代わりに自動的に、M2Mデータを解析、解釈、または処理することができるセマンティック認識M2Mサービス層の不足によるものである。現在のM2Mシステムでは、M2Mサービス層は、セマンティック認識能力が欠けており、M2Mサービス層を通って流動するデータ、またはM2Mサービス層内に記憶されるデータは、不透明な情報として扱われる。
このセマンティック認識の不足は、たとえデータが起源であったアプリケーションのいかなる予備知識がなくても、異なるアプリケーションによって発見、アクセス、解釈、および共有されることができるように、M2Mアプリケーションによって生成されるデータがM2Mサービス層によって効果的に抽象化または仮想化されることを可能にするサービスを、M2Mサービス層が提供することを妨げる。結果として、感知および作用される物理的エンティティ(例えば、アプライアンス、人、車、建築物の部屋等)は、M2Mサービス層によって効果的に仮想化/抽象化されない場合があり、物理的エンティティは、環境に固有であり、特定のM2Mアプリケーションに関係しない一般的エンティティとして扱われる。
この制限を克服するために、M2Mシステムにおいて伝送されるデータは、セマンティック認識M2Mサービス層がM2Mアプリケーションと同じデータの知識を有することができるように、セマンティック情報に関連付けられ、統合される必要がある。そうすることで、M2Mサービス層は、アプリケーションにわたるデータの共有をより良好に促進し、付加価値のあるセマンティック認識サービスをM2Mアプリケーションに提供することができる(例えば、データ集約、異なるアプリケーション間のデータ共有等)。
例えば、図1で図示される患者監視アプリケーションでは、患者の生命兆候(例えば、血圧、温度、酸素、心拍数等)を監視する無線センサデバイスの各々の上でホストされる、別個のアプリケーションがあり得る。同様に、この情報を利用することができる、ネットワーク内でホストされる別個のアプリケーションがあり得る(例えば、患者の医師、個人トレーナ、家族、救急車の救急医療隊員等)。しかしながら、無線センサデバイスの各々からのM2Mセマンティック認識サービスデータがないと、ネットワークアプリケーションが、無線センサデバイス上でホストされるアプリケーションの予備知識、およびそれらが生成する情報のタイプ(例えば、場所/アドレス、データの単位、データのコンテキスト等)を有していない限り、ネットワークアプリケーションは、デバイスアプリケーションから情報を発見、共有、および理解することに困難を有し得る。
本願は、M2Mサービス層セマンティック認識およびデータ抽象化をサポートするために、M2Mシステムにおいて以下の機能を提供することを目指す:(i)セマンティック情報を記憶するためのサポート、および/またはセマンティック情報を記憶するサーバへのインターフェースのためのサポート、(ii)セマンティック情報を作成、読み出し、更新、および削除するための機構のためのサポート、(iii)ローカルおよび遠隔リソースに対するセマンティック情報更新のための機構のためのサポート、(iv)セマンティック情報をローカルまたは遠隔のいずれかで記憶され得る対応するリソースに関連付ける/結び付けるためのサポート、および(v)セマンティック記述を公表および発見する能力。
記述される機能性のうちの1つ以上のものを提供するために、本願は、セマンティクスノードの概念を開示する。本明細書に説明されるように、セマンティクスノードは、論理エンティティであり、この論理エンティティは、ネットワーク内の独立型コンピュータデバイス(例えば、サーバ)上でホストされ得るか、または、M2Mゲートウェイ、M2Mデバイス、M2Mサーバ等のネットワーク内の既存のエンティティ上でホストされ得る。セマンティクスノードは、データを記述するレポジトリと見なされ得る。例えば、血圧用のセンサデバイスは、どのようにしてそのデータを記述するかを理解することを希望し得、すでに定義された血圧クラスがあるかどうかを見つけるために近くのセマンティクスノードにクエリを行う。もしあれば、セマンティクスノードは、それがローカルで見出した血圧クラスでセンサデバイスに応答する。もしなければ、セマンティクスノードは、他のセマンティクスノード(例えば、兄弟または親)にクエリを行い得る。セマンティクスノードの使用は、エンドデバイスにデータの記述を記憶させる必要を低減させ得る。
セマンティクスノードは、セマンティクスノード上に記憶されるセマンティクス関連リソースを記憶して管理する。セマンティクス関連リソースは、通常、例えば、リソースツリーの下に記憶されるETSI M2Mリソース、すなわち、<SCL>、<application>、<container>、<contentInstance>(それらは、それらのセマンティクスの理解を可能にするためにそれらに関連付けられるセマンティクス関連リソースを有する必要がある)等の他のリソースを記述する。一実施例では、セマンティクス関連リソースは、3つのタイプ(クラス、関係、およびターム)のうちの1つを有し得る。このカテゴリ化は、セマンティックウェブの現在の技法との適合性を提供し、M2Mシステムが既存のセマンティクス関連リソースを活用することを可能にする。
本明細書で議論されるように、セマンティクスノードは、M2Mエリアネットワーク、M2Mアクセスネットワーク、およびM2Mコアネットワーク等の異なるレベルでM2Mシステムに展開され得、異なるレベルは、階層構造を形成する。同じレベルでのセマンティクスノードが分配され、兄弟関係を有し得る。セマンティクスノードのそのようなハイブリッドアーキテクチャを構築すること、維持することに関して機構が開示され、それは、異なるレベルの抽象化と、既存のネットワーク階層に対する適合性との利益を提供する。
セマンティクスノードのための機能、基準点、メッセージ、およびプロシージャも開示される。種々の実施例では、以下の機能性がセマンティクスノード上で有効化され得る:(i)セマンティクスノードによって管理されるセマンティクス関連リソースは、発見され、読み出され、および妥当性を立証されることが可能である、(ii)セマンティクスノードは、他のノードによって発見され得、セマンティクス関連リソースもまた、加入機構を用いて発見され得る、(iii)セマンティクス関連リソースがセマンティック情報を提供され普遍的に理解されるように、セマンティクス関連リソースは、M2Mシステム内のリソースと結び付けられ、関連付けられ得る、(iv)セマンティクス関連リソースは、効率的な発見および容易なアクセスの目的で、階層内の他のセマンティクスノードにプッシュ配信され得る、(v)セマンティクス関連リソースの関連付けおよび結び付きは、セマンティクス類似性、および記述されているセマンティクス関連リソースのグループ化に基づいて最適化され得る、(vi)セマンティクス関連リソースは、データの移動とともに、1つのセマンティクスノードから別のセマンティクスノードへ移動させられ得る。
以降で説明される一実施例では、セマンティクスノードは、ETSI M2M/oneM2Mアーキテクチャのサービス能力層(xSCL)において実装される。別の実施例では、セマンティクスノードは、3GPPマシン型通信(MTC)アーキテクチャのサービス能力サーバ(SCS)において実装される。
(I.セマンティクスノードを伴うM2Mアーキテクチャ)
セマンティクスノードを含むM2Mシステムの一実施例が、図3で図示される。M2Mシステム150で示されるように、セマンティクスノードは、3つのレベルにおいて展開される。エリアネットワーク154、エリアネットワーク155、エリアネットワーク156、およびエリアネットワーク157等のネットワークを含み得るエリアレベルがあり得る。アクセスネットワーク152およびアクセスネットワーク153等のネットワークを含み得るアクセスレベルがあり得る。そして、コアネットワーク151等のネットワークを含むコアレベルがあり得る。
システム150に示されるように、アプリケーション158は、基準点sIc159を介して、エリアネットワーク157内に位置するM2Mセマンティクスノード160と通信可能に接続され得る。sIc基準点は、概して、セマンティクスノードと通信をするために、アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワークエンティティ内の他の非セマンティクスノードエンティティによって使用される。M2Mセマンティクスノード160は、基準点sIe162を介して外部セマンティクスノード163と通信可能に接続される。M2Mシステム内のセマンティクスノードは、sIe基準点を介して外部セマンティクスノードと連動し得る。外部セマンティクスノードは、セマンティックウェブについてRDFSによって定義されるもの等の他の既存のセマンティクス関連リソースを管理し得る。M2Mセマンティクスノード160はまた、sIs基準点161を介して、アクセスネットワーク153内に位置するM2Mセマンティクスノード164と通信可能に接続される。M2Mセマンティクスノード164は、sIc基準点166を介してM2Mゲートウェイ165と通信可能に接続され、基準点sIsを介してコアネットワーク151内に位置するM2Mセマンティクスノード168と通信可能に接続される。本実施例では、M2Mゲートウェイ165自体は、セマンティクスノードではないが、他の実施例では、M2Mゲートウェイ165は、セマンティクスノードの機能性を組み込むことができる。
セマンティクスノードは、オフローディング、負荷バランシング、容易なアクセス等の目的で、エリアレベルで展開され得る。エリアレベルでは、ローカルエリアネットワーク内の全てのデバイスが、アタッチされたアクセスまたはコアネットワーク内のセマンティクスノードと通信する場合、展開されたセマンティクスノードがないことが可能である。エリアレベルでのセマンティクスノードは、アクセスレベルにおける対応する親セマンティクスノード(例えば、M2Mセマンティクスノード164と接続されたM2Mセマンティクスノード160)またはコアレベルにおける対応する親セマンティクスノード(例えば、セマンティクスノードを含むM2Mサーバ170と接続されたM2Mセマンティクスノード169)を有し得る。セマンティクスノードは、sIs基準点を通して互いに通信をする。基準点の詳細は、以降でさらに詳細に定義される。アクセスレベルでのセマンティクスノードはまた、それがsIs基準点を経由して通信するコアレベルでの親を有し得る。同様に、アクセスレベルでのセマンティクスノードは、それがsIs基準点を経由して通信するエリアレベルでの子セマンティクスノードを有し得る。コアレベルでのセマンティクスノードはまた、アクセスまたはエリアレベルで子セマンティクスノードを有し得る。
図3で図示される親子関係に加えて、セマンティクスノードはまた、セマンティクスノードレベル(例えば、アクセス、エリア、またはコア)のうちの任意のもので兄弟の概念をサポートする。兄弟セマンティクスノードは、階層内の同一レベルでのノードであり、セマンティクスノードの負荷を分配するために使用されることができる。例えば、コアネットワーク151では、M2Mセマンティクスノード168は、セマンティクスノードを含むM2Mサーバ170と接続される。垂直な観点から、1つより多くのセマンティクスノードの確立された階層がある場合、ノードは、互いに通信をし、sIs基準点を経由した通信、ブロードキャスト、発見等を介して、セマンティック情報を共有することができる。
制約されたデバイスについては、容量の制限により、セマンティクスは、特定のセマンティクスまたは遠隔セマンティクスノードに記憶されたセマンティクスを指し示すリンクを指すコードであり得る。そのようなセマンティック情報は、データを作成したアプリケーションによって、またはサービス層によって提供され得る。
アクセスレベルでは、1つのアクセスネットワークで展開された1つ以上のセマンティクスノードがあり得る。そのような場合、兄弟は、sIs基準点を通してセマンティック情報通知、ブロードキャスト、および発見のために互いに通信し得る。アクセスレベルでのセマンティクスノードは、それがsIs基準点を経由して通信する、コアレベルでの親を有し得る。同様に、アクセスレベルでのセマンティクスノードは、それがsIs基準点を経由して通信するエリアレベルでの子セマンティクスノードを有し得る。
コアレベルでは、コアネットワークで展開された1つ以上のセマンティクスノードがあり得る。これらのノードは、兄弟であり得、通知、ブロードキャスト、および発見を使用してセマンティック情報を共有するために、sIs基準点を経由して互いに通信し得る。コアレベルでのセマンティクスノードはまた、アクセスまたはエリアレベルで子セマンティクスノードを有し得る。アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワーク内の他の非セマンティクスノードエンティティは、sIc基準点を介してセマンティクスノードと通信をする。
上記のように、セマンティクスノードは、論理エンティティであり得、論理エンティティは、ネットワーク内の独立型物理ノード(例えば、独立型M2Mセマンティクスノード160)であり得るか、または図3のシステム150で示されるようなM2Mデバイス171、M2Mゲートウェイ172、またはM2Mサーバ170等のネットワーク内の別の物理ノード上でホストされる。換言すると、M2Mデバイス、M2Mゲートウェイ、およびM2Mサーバは、セマンティクスノード機能性をサポートすることができる。
図3で図示される多層セマンティクスノード階層の特徴は、それが異なるレベルの抽象化を提供できることである。セマンティクスノードは、M2Mエリアネットワーク内等の局所的領域中のセマンティクス関連リソースを管理することのみを担当し得、それによって、エリアネットワーク特有のセマンティクス関連リソースは、ローカルで見出され得る。局所的領域において典型的ではない任意のセマンティクス関連リソースは、高レベルの親または並列の兄弟セマンティクスノードに記憶され、見出されることができる。別の特徴は、インターネット階層、場所階層等により、セマンティクス関連リソースがそれら自体で階層を有し得ることである。結果として、セマンティクスの複数の層は、既存のネットワークアーキテクチャと一致する。加えて、セマンティクスノードは、各レベルで分配され得、これは、集中型セマンティクスノードがコアネットワークのみで展開される場合の単一故障点を防止する。
(II.セマンティクスノードアーキテクチャ)
ここで、セマンティクスノードのアーキテクチャに関するさらなる詳細について議論する。記述されるように、セマンティクスノードは、セマンティクス関連リソースを記憶して管理する。本明細書で定義されるように、セマンティクス関連リソースは、M2Mデバイスまたはアプリケーションによって生成されるデータ、またはM2Mデバイスもしくはアプリケーション自体の意味等のモノのセマンティック情報を記述するために使用されることができる情報を備えている。一実施例では、セマンティクス関連リソースは、XMLスキーマ定義(XSD)、RDFスキーマ/ウェブオントロジー言語(RDFS/OWL)等の既存のスキーマを使用して、拡張マークアップ言語(XML)で表現され得る。例では、3つのタイプのセマンティクス関連リソース(各々が以下でさらに完全に説明される、クラス、関係、およびターム)が、セマンティクスノードに記憶され得る。このようなセマンティクス関連リソースのカテゴリ化は、セマンティックウェブの現在の技法との適合性を提供する。この適合性は、M2Mシステムが、例えば、W3Cによって定義される、これらのコアクラスおよびコアプロパティ等の既存のセマンティクス関連リソースを活用することを可能にする。M2Mシステムの外部のアプリケーションおよびエンティティは、セマンティクスを適合性にするために必要な形式変換または修正による、いかなる余分なオーバーヘッドも被ることなく、セマンティクスノードによってホストされるセマンティクス関連リソースを使用することができる。
クラス:ここで、M2Mドメイン内のオブジェクト/モノのクラスの概念について議論される。図1の例示的健康監視システムでは、例えば、システムに関連するオブジェクトのクラスは、患者、医師、救急車の通信指令係、血圧、中核体温、酸素飽和度、運動加速度計等を含む。クラスは、ユニフォームリソース識別子(URI)またはユニフォームリソースロケータ(URL)によって識別され得る。クラスは、クラスを定義する情報を含む、フィールド記述を含む。例えば、摂氏単位の整数として温度データを表し、例えば、これらのセマンティクスを温度センサによって生成されるデータに提供するために使用されることができる、temperatureReadingクラスは、以下のようにXSDのスキーマを用いてXMLで定義され得る。
<simpleType name=“temperatureReading”>
<restriction>
description =“temperature in Celsius”
unit=“Celsius” base=“integer”
</restriction>
</simpleType>
ここで、クラスは、“description”、“unit”、および“base”というフィールドを含み、これらのフィールドの中の情報は、それぞれ、“temperature in Celsius”、“Celsius”、および“integer”である。別の実施例として、BloodPressureクラスは、2つのフィールド、すなわち、収縮期圧のための1つのフィールド、および拡張期圧のための別のフィールドを含み得る。このBloodPressureクラスのためのクラス記述は、両方のフィールドの記述を含み、以下のようにXML/XSDを使用して表現され得る。
<complexType name=“BloodPressure”>
<sequence>
<element name=“systolicINmmHG” type=“integer”/>
<element name=“diastolicINmmHG” type=“integer”/>
</sequence>
</complexType>
しかしながら、再度、クラス(および他のタイプのセマンティクス関連リソース、すなわち、関係およびターム)は、XML/XSDを使用する表現に限定されず、むしろ、例えば、RDFS/OWL等を含む種々の好適な記述言語のうちのいずれかで表現され得ることが理解される。クラスはまた、互いに関係付けられ得る。例えば、「血圧」は、「生命」の下位クラスであり得、同等に、「生命」は、「血圧」の上位クラスであり得る。下位クラス/上位クラス関係は、クラスの階層を定義する。一般に、Aの全てのインスタンスがBのインスタンスでもある場合、AはBの下位クラスである。クラスは、複数の上位クラスを有し得る。
関係:関係は、特別な種類のセマンティクス関連リソースである。関係は、セマンティクス関連リソース間の関連、例えば、「により作成」、「寿命」、「により加入」等を記述する。関係も、全体的かつ一意の命名スキームをM2Mドメインの関係に与える、URI/URLによって識別されることができる。クラスおよびインヘリタンスは、計算の他の分野で、例えば、オブジェクト指向プログラミングで知られている。しかし、類似点がある一方で、差異も存在する。オブジェクト指向プログラミングでは、オブジェクトクラスは、それに適用される関係またはプロパティを定義する。新しい関係またはプロパティをクラスに追加することは、クラスを修正することを意味する。しかしながら、ここで、関係は、全体的に定義され、つまり、それらは、クラス定義における属性としてカプセル化されない。クラス自体の定義を変更することなく既存のクラスに適用される新しい関係が定義され得る。クラスのように、関係も互いに関係付けられることができる。例えば、「エネルギーモード」および「使用モード」は、「モード」の下位関係である。デバイスが電気の「エネルギーモード」および手動の「使用モード」を有する場合、電気の「モード」と手動の「モード」とを有する。
ターム:タームは、M2Mドメインで一般的に使用されている概念である。本明細書で定義されるように、タームは、リソースのセマンティクスを記述するために多くの当事者によって使用され得る値である。タームの定義は、それが公表されるあるドメイン内で普遍的に承認され得る。例えば、手動、ユーザ指図、および自律は、それぞれ、例えば、アプライアンスの使用モードを記述するために使用され得るタームの例である。一般に、セマンティクス関連リソースの作成者は、そのセマンティクス関連リソースが、クラスであるか、関係であるか、またはタームであるかを決定するであろう。次いで、セマンティクスノードは、それらの作成者によって定義または決定されるカテゴリの下でセマンティクス関連リソースを記憶するであろう。例えば、図1の患者監視実施例では、セマンティクス関連リソースクラス、関係、およびタームは、血圧モニタ製造業者によって、医師によって、または別のアプライアンス製造業者によって作成され得る。他の例では、セマンティクス関連リソースクラス、リソース、およびタームは、垂直アプリケーションによって定義または作成され得る。
リソース(データ、モノ等を含む)のセマンティクスは、リソース、関係、および値から成るリソース・関係・値のトリプルによって記述されることができる。値は、クラス、ターム、または他のリソースのいずれかであり得る。以下は、いくつかの例である。
・ A content instance (リソース) hasType (関係) temperatureReading (クラス)
・ An appliance (リソース) hasUsageMode (関係) user−directed (ターム)
・ A content instance (リソース) generatedBySameApplicationAs (関係) another content instance (リソース)
提案されたsIc、sIs、およびsIe基準点を通して、セマンティクスノードのクラス、関係、およびタームリソースへの要求が行われることができる。図4は、M2Mセマンティクスノードのクラス、関係、およびタームリソースの例示的説明図である。本実施例で図示されるように、セマンティクスノード420は、異なるアプリケーションおよびドメインからの種々のクラス422、関係424、およびターム426を記憶するように構成され得る。代替として、セマンティクスノード420は、アプライアンスセマンティクス、車両セマンティクス、医療アプリケーションセマンティクス等の固有のアプリケーションまたはドメインのためのクラス、関係、およびタームリソースを記憶するように構成され得る。
III.M2Mセマンティクスノード機能および基準点
この節では、セマンティクスノードの機能および基準点に関するさらなる詳細が提供される。一実施例では、セマンティクスノードは、以下の機能を行い得る:他のセマンティクスノードを認証し(セマンティクスノード階層内のより低レベルの子または並列の兄弟セマンティクスノードを認証することを含む)、それらがセマンティクスノードのリソースに対して登録し、リソースに対する要求を行うことを可能にすること;アプリケーション、デバイス、および/またはユーザを認証し、それらがセマンティクス関連クラス、関係、およびタームリソースを公表、作成、削除、更新、および読み出すことを可能にすること;セマンティクス関連クラス、関係、およびタームリソースを記憶して管理すること;セマンティクス関連リソースの発見のためのサポートを提供すること;および、発見クエリに協力してセマンティクス関連リソース情報を共有するために、セマンティクスノードが互いに(親子、兄弟の間で)通信するためのサポートを提供すること。
セマンティクスノードは、1つ以上の基準点またはインターフェースを介して、ネットワーク内の他のエンティティと通信し得る。一実施例では、3つの基準点、すなわち、sIs基準点、sIc基準点、およびsIe基準点が定義される。sIs基準点は、セマンティクスノード間の通信のために使用される。sIs基準点はまた、別のセマンティクスノードに登録し、親子または兄弟関係を形成すること、他のセマンティクスノードを発見すること、その状態(例えば、オンライン、オフライン、オーバーロード等)について他者に通知すること、特定の動作(例えば、登録解除、登録)を行うように別のセマンティクスノードをトリガすること、および、別のセマンティクスノード内のセマンティクス関連リソースを公表、作成、削除、更新、読み出すことを行うためにセマンティクスノードによって使用され得る。加えて、セマンティクスノードは、図20、図21、および図22に関連して以下でさらに説明されるように、別のセマンティクスノード内のセマンティクス関連リソースに加入し、対応する通知を受信すること、その階層内の兄弟および親セマンティクスノード上のセマンティクス関連リソースを発見すること、セマンティクス関連リソースのグループを1つのセマンティクスノードから別のセマンティクスノードへ移動させること、および、別のセマンティクスノードに記憶されたセマンティクス関連リソースがあるリソースと結び付けられ、関連付けられ、セマンティクスをそのリソースに提供することを可能にすることを行うためにsIs基準点を使用し得る。
本実施例では、sIc基準点は、種々のネットワークドメイン(例えば、エリアネットワーク、アクセスネットワーク、またはコアネットワーク)からのセマンティクスノードと通信するために、アプリケーションまたは非セマンティクスノードによって使用され得る。sIc基準点はまた、アプリケーションまたは非セマンティクスノードが、セマンティクスノード内のセマンティクス関連リソースを公表、作成、削除、更新、読み出し、加入、または発見すること、およびセマンティクスノードから通知を受信することも可能にする。加えて、sIc基準点は、セマンティクスノードに記憶されたセマンティクス関連リソースがあるリソースと結び付けられ、関連付けられ、セマンティクスをそのリソースに提供することを可能する。
sIe基準点は、M2Mシステム内のノードの既存の階層の一部であるセマンティクスノードと、外部セマンティクスノードとの間の通信のために使用され得る。外部セマンティクスノードは、M2Mドメインの外側にセマンティクス関連リソースを記憶する。外部セマンティクスノードの一例は、http://www.w3.org/2005/Incubator/ssnで説明されるようなW2C Semantic Sensor Network Incubator Groupによって定義される、セマンティックセンサネットワークオントロジーのためのセマンティクス関連リソースを記憶するサーバであり得る。sIe基準点は、セマンティクスノードが外部セマンティクスノード内のセマンティクス関連リソースを読み出し、発見し、およびそれに加入することを可能にし、その逆も同様である。さらに、sIe基準点を介して、外部セマンティクスノードは、M2Mシステム内のセマンティクスノードを発見し、通知を受信し得る。
これらの基準点を効果的に定義する、sIs、sIe、およびsIc基準点に関連付けられるメッセージの一実施例が、表1で以下に記載される。
表1は、セマンティクスノード関連メッセージ、それらの対応する意味、および使用される基準点を記載する。
ハイパーテキスト転送プロトコル(HTTP)または制約アプリケーションプロトコル(CoAP)等のプロトコルが、異なるタイプのメッセージを搬送するための基礎的トランスポートプロトコルとして使用され得る。上記で議論される種々のセマンティクスノード機能性を果たすためのこれらのメッセージの使用の実施例が、以下で提示される。
(IV.M2Mセマンティクスノードプロシージャ)
(A.セマンティクスノード階層を構築する)
この節では、一実施例による、どのようにしてセマンティクスノードの階層(以降では「セマンティクスノード階層」)が構築され得るかに関して、追加の詳細が提供される。本実施例では、セマンティクスノード階層は、ネットワーク内の異なるエリア、アクセス、およびコアレベルに位置するセマンティクスノード間の親子および兄弟関係を決定することによって構築される。
図5Aは、セマンティクスノード階層を確立するための方法の一実施例を図示するフロー図である。セマンティクスノードがネットワークに参加する(ステップ504)、すなわち、オンラインになるとき、最初に、ネットワーク内で動作セマンティクスノードになることができる前に、子・親および兄弟関係を構築する必要がある。この目的を達成するために、ステップ506では、セマンティクスノードは、同じレベル内で兄弟セマンティクスノードの発見を行い得る。
兄弟セマンティクスノードの発見は、セマンティクスノード発見要求(例えば、マルチキャスト、ブロードキャスト、エニーキャスト)を送信することに基づき得、発見要求は、兄弟セマンティクスノードを発見するために発行されることができる。要求は、ネットワークを混雑させ得る発見要求および応答メッセージのフラッディングを制限する定義されたホップ制限を有することができる。代替として、発見は、利用可能である場合、ドメイン名システム(DNS)、DNSサービス発見(DNS−SD)、サービスロケーションプロトコル(SLP)等のネットワーク内で利用可能な既存の発見機構を活用することができる。セマンティクスノードは、管理されるセマンティック情報のIPアドレスまたはタイプ等、隣接兄弟セマンティクスノードの返信された情報を記憶し得る。以下でさらに議論されるように、兄弟セマンティクスノード発見応答メッセージはまた、高レベルセマンティクスノード発見サーバのアドレス、兄弟の親セマンティクスノードのアドレス、または両方をピギーバックし得る。
依然として図5Aを参照すると、兄弟セマンティクスノードの発見に続いて、セマンティクスノードは、次に、ステップ508、ステップ510、およびステップ512で、高レベルセマンティクスノードを発見、および/またはそれらに登録しようとし得る。セマンティクスノードが、それが登録する必要がある高レベルノードを供給された場合、単純に、この供給されたセマンティクスノードに登録し、親子関係を構築することができる(ステップ508、ステップ512)。そうでなければ、セマンティクスノードは、既存の高レベルセマンティクスノードを発見し、登録するためにそれらのうちの1つを選択する必要がある(ステップ510)。選択は、同じタイプのセマンティクスリソースをサポートする、隣接上位レベルで最近傍等の基準等に基づき得る。図5Bは、これらのステップ508、ステップ510、およびステップ512をさらに詳細に図示する。
本実施例では、各レベルに、1つのセマンティクスノード発見サーバがあり得、それは、デフォルトで高レベルセマンティクスノード発見要求を受理する。セマンティクスノード発見サーバのアドレスは、低レベルセマンティクスノードに周知され得る。図5Bに示されるように、新しいセマンティクスノードが高レベル親セマンティクスノードアドレスを供給されない場合(ステップ602)、かつ、新しいセマンティクスノードが上位レベルでセマンティクスノード発見サーバを供給されない場合(ステップ604)、それは、最初に、兄弟セマンティクスノード発見606を行うことができる。兄弟発見の一部として、セマンティクスノード発見サーバのアドレスは、共有され得る(例えば、発見された兄弟セマンティクスノードから受信される兄弟発見応答でピギーバックされる)(ステップ608)。一方で、それはまた、登録するそれ自身の親としてノードを選択し得るように、兄弟の親セマンティクスノード情報(アドレス)を明示的に要求し得る(ステップ610、618)。
新しいセマンティクスノードが上位セマンティクスノード発見サーバのアドレスを供給される場合、セマンティクスノード発見を直接行うことができる(ステップ604からステップ614への通過を制御する)。そうでなければ、兄弟の親リストから選択したいかどうか、および兄弟からデフォルトセマンティクスノード発見サーバのアドレスを読み出したいかどうかを決定する(ステップ608および610)。新しいセマンティクスノードが兄弟の親から上位セマンティクスノードを選択する場合(ステップ618)、セマンティクスノード発見をさらに行わないことを選択し得る。そうでなければ、それは、(同じタイプのセマンティクスリソース等をサポートする、ホップ数で最近傍にある)親を選択する基準を決定する(ステップ614)。基準に基づいて、それは、上位レベルでのセマンティクスノードのアドレスに加えて、発見したい情報(距離、セマンティクスリソースのサポートされたタイプ等)を設定する(ステップ616)。
ステップ620では、新しいセマンティクスノードが、発見したか、または別様に選択した高レベル親セマンティクスノードに登録し得る。新しいセマンティクスノードが、高レベルセマンティクスノード発見サーバのアドレスを知ることも、それが登録し得るその兄弟のいかなる高レベル親セマンティクスノードも識別することもできない場合、いずれの高レベル親セマンティクスノードも利用可能ではないと決定し、ステップ612でプロセスを終了させ得る。
図5Aを再度参照すると、兄弟の発見ならびに親ノードの発見および登録が完了すると、新しいセマンティクスノードの兄弟および親についての情報が記憶される(ステップ514)。図5Aでさらに図示されるように、新しい兄弟がネットワークに参加するか、または既存の兄弟がオフラインになる場合、セマンティクスノードは、そのセマンティクスノード関係を更新し得る(ステップ516、518)。ステップ520では、新しいセマンティクスノードが現在動作している。図5Aでさらに図示されるように、動作セマンティクスノードは、ある以降の時点で、別の高レベルノードに登録するようにトリガされ得るか(ステップ522)、またはネットワークから離れ得る(ステップ526)。前者の場合、セマンティクスノードは、その現在の親を登録解除し、新しい親に登録し得る(ステップ524)。後者の場合、セマンティクスノードは、単純に、その現在の親を登録解除し得る(ステップ528)。
図6は、上記で議論され、図5Aおよび図5Bで図示される、セマンティクスノード発見および登録プロセスをさらに図示するメッセージフロー図である。ステップ185では、新しいセマンティクスノード181が、セマンティクスノード発見要求を兄弟セマンティクスノード182に送信する。兄弟セマンティクスノード182は、新しいセマンティクスノード181と同じネットワークレベルにある。ステップ185のセマンティクスノード発見要求は、セマンティクスノード発見サーバ183に関する情報(例えば、アドレス)、または兄弟セマンティクスノード182の親(例えば、上位)セマンティクスノード184であるセマンティクスノードの情報に対する要求を含み得る。親セマンティクスノードに対する要求は、新しいセマンティクスノード181が、登録するそれ自身の親を選択することを可能にし得る。
セマンティクスノード発見サーバ183は、同じレベルで散乱させられたセマンティクスノードの情報を記憶するための集中点、またはネットワークの同じレベルで発見要求を大量送信し、セマンティクスノードの返信された応答を収集する集合点と見なされ得る。セマンティクスノード発見サーバ183は、新しいセマンティクスノード181のネットワークレベルより高いか、同じか、または低いレベルのネットワークレベルでネットワークに常駐するサーバであり得る。本実施例は、セマンティクスノード発見サーバ183が、新しいセマンティクスノード181のネットワークレベルに関して上位レベルにあることを仮定する。セマンティクスノード発見サーバ183のアドレスは、低レベルセマンティクスノード(例えば、兄弟セマンティクスノード182)によく知られていることができる。新しいセマンティクスノード181がセマンティクスノード発見サーバ183を供給されない場合、新しいセマンティクスノード181は、兄弟セマンティクスノード発見を行い得る。新しいセマンティクスノード181がセマンティクスノード発見サーバ183のアドレスを供給される場合、それは、セマンティクスノード発見を直接行うことができる。
図6のステップ186では、兄弟セマンティクスノード182が、セマンティクスノード発見応答を送信する。セマンティクスノード発見応答は、セマンティクスノード発見サーバ183の情報(例えば、アドレス情報)、または兄弟セマンティクスノード182の親であるセマンティクスノードの情報を含み得る。あるネットワークのレベルでの各兄弟ノードは、兄弟セマンティクスノード182によって提供される情報とは異なり得る、親セマンティクスノード情報およびセマンティクスノード発見サーバ情報で応答し得る。
ステップ187では、新しいセマンティクスノード181が、セマンティクスノード発見サーバ183の受信されたアドレスを抽出する。ステップ188では、新しいセマンティクスノード181が、セマンティクスノード発見要求をセマンティクスノード発見サーバ183に送信する。ステップ188での要求は、セマンティクスノード181が接続し得る1つ以上の親セマンティクスノードに対するクエリであり得る。ステップ189では、セマンティクスノード発見サーバ183が、セマンティクスノード発見応答を新しいセマンティクスノード181に送信する。ステップ189での応答は、1つ以上の親セマンティクスノードを含み得る。ステップ190では、新しいセマンティクスノード181が、登録する1つの親セマンティクスノードを選択する。ステップ191では、セマンティクスノード181が、その選択された親セマンティクスノード184への登録に対する要求を送信する。ステップ192では、親セマンティクスノード184が、ステップ191での登録に対する要求への応答を送信する。
概して、新しいセマンティクスノード181がセマンティクスノード発見サーバ183のアドレスを供給される場合、セマンティクスノード発見を直接行うことができる。そうでなければ、新しいセマンティクスノード181は、1つ以上の兄弟から受信される親セマンティクスノードのリストから選択したいかどうか、および兄弟からセマンティクスノード発見サーバ183のデフォルトアドレスを読み出したいかどうかを決定する。各レベルにおいて、デフォルトで高レベルセマンティクスノード発見要求を受理する1つ以上のセマンティクスノード発見サーバがあり得る。新しいセマンティクスノード181が兄弟の親から上位セマンティクスノードを選択する場合、新しいセマンティクスノード181は、セマンティクスノード発見をさらに行わないことを選択し得る。新しいセマンティクスノード181は、親を選択する(例えば、同じタイプのセマンティクス関連リソース等をサポートする、ホップ数で最近傍等のオプションから選択する)基準を決定するオプションを有し得る。基準に基づいて、新しいセマンティクスノード181は、上位レベルでのセマンティクスノードのアドレスに加えて、発見したい情報(例えば、距離、セマンティクス関連リソースのサポートされたタイプ等)を設定する。
図7は、その一実施例による、親子関係更新プロセス(図5Aのステップ522および524)のさらなる詳細を提供する、メッセージフローを提供する。更新は、子または親セマンティクスノードによって開始され得る。ステップ205では、セマンティクスノード201が、通知に基づいて現在の親セマンティクスノード203から登録解除することを決定する。通知は、とりわけ、現在の親セマンティクスノード203からの登録解除を開始するためのメッセージ、現在のセマンティクスノード203が連絡可能ではない(例えば、オフラインである、切断されている、または他の通信問題)であるという決定、または親セマンティクスノード203に関連付けられる受信された状態更新(例えば、ネットワークトラフィック混雑、デバイスまたは回線エラー、メモリ容量問題等)であり得る。
ステップ206では、セマンティクスノード201が、親子関係を終了させるための要求を含む登録解除要求を現在の親セマンティクスノード203に送信する。ステップ207では、セマンティクスノード201が、現在の親セマンティクスノード203、または現在の親セマンティクスノード203の知覚された状態を伝達することができる別のデバイスから、ステップ206で送信された登録解除要求への応答を受信し得る。図6に関して図示されるステップと同様に、セマンティクスノード201は、新しい親セマンティクスノードに登録しようとする。ステップ208では、セマンティクスノード201が、セマンティクスノード発見要求をセマンティクスノード発見サーバ202に送信する。ステップ209では、セマンティクスノード発見サーバ202が、セマンティクスノード発見応答をセマンティクスノード201に送信する。ステップ210では、セマンティクスノード201が、登録する1つの上位セマンティクスノードを選択する。ステップ211では、セマンティクスノード201が、その選択された新しい親セマンティクスノード204への登録に対する要求を送信する。ステップ212では、新しい親セマンティクスノード204が、親子関係の更新を確認する、ステップ211での登録に対する要求への応答を送信する。
(示されていないが、図7の要素を参照した)実施例では、親セマンティクスノードが、子の登録解除をトリガし、登録する子のための新しい親セマンティクスノードを提供し得る。この新しい親情報は、登録解除トリガメッセージに、または代替として、別個のトリガメッセージに含まれ得る。セマンティクスノード201は、現在の親セマンティクスノード203に登録要求を新しい親セマンティクスノード204へ送信させることによって、新しい親セマンティクスノード204に登録することができる。現在の親セマンティクスノード203は、登録目的で、セマンティクスノード201の情報を新しい親セマンティクスノード204に転送するオプションを有する。現在の親セマンティクスノード203またはセマンティクスノード201は、現在の親セマンティクスノード203を新しい親セマンティクスノード204に切り替える前に、親子関係を終了させ得る。
概して、セマンティクスノードの親子関係は、子セマンティクスノードがオフラインになるとき、または子セマンティクスノードが別の高レベル親セマンティクスノードに登録するときに、現在の親セマンティクスノードを登録解除することによって終了させられる。
隣接兄弟セマンティクスノードがネットワークに参加する場合、新しいセマンティクスノードを追加することによって、対応する兄弟情報が更新される。隣接兄弟セマンティクスノードがネットワークから離れる場合、セマンティクスノードを削除するか、または別様にネットワークから離れた兄弟セマンティクスノードの状態を示すようにテーブルを更新する(例えば、状態=オフライン)ことによって、対応する兄弟情報が更新される。セマンティクスノードは、例えば、表1で上に示されるSEMANTICS_NODE_STATUS_NOTIFY()メッセージを使用して、その状態を兄弟セマンティクスノードにブロードキャストするか、または別様に伝達し得る。状態更新は、どのようにして兄弟および親子関係が維持されるかに影響を及ぼし得る。
(B.セマンティクス関連リソース発見、読み出し、および確認)
アプリケーション、デバイス、ユーザ、ピアセマンティクスノード、外部セマンティクスノード、または非セマンティクスノードは、sIc、sIs、およびsIe基準点を通して、セマンティクス関連リソース発見要求をセマンティクスノードに送信し得る。発見要求メッセージは、セマンティクス関連リソースのタイプ(クラス、関係、またはターム)と、検索文字列とを含み得る。例えば、摂氏単位の整数として、その温度読み取りデータをそのM2Mゲートウェイに報告する必要がある、M2Mシステム内の温度感知アプリケーション(App1)を仮定されたい。ゲートウェイサービス能力層(GSCL)がデータを理解することを可能にするために、App1は、データを適正なセマンティック情報に関連付ける必要がある。本明細書に説明されるプロシージャに従って、App1は、摂氏単位の整数として温度データを表す、セマンティクス関連リソースクラス、すなわち、temperatureReadingクラスを記憶する、セマンティクスノードを発見し得る。発見後に、App1は、temperatureReadingクラスの表現を読み出し、その温度データのセマンティクスを提供するためにそれが使用したいものであることを確認するであろう。次いで、それは、データをその属性(セマンティクス属性)のうちの1つとしてtemepratureReadingクラスと結び付けるであろう。GSCLでは、データは、App1のための<tempData>コンテナの下で記憶され得、<tempData>コンテナは、例えば、図26で図示されるように、hasType関係を使用してtemperatureReadingクラスに結び付くセマンティクス属性を有するであろう。結果として、GSCL内の<tempData>コンテナの下で記憶された全てのApp1データは、データの各アイテムが整数であり、摂氏単位を有するという同一のセマンティクスを有するであろう。別の例として、App1は、NSCLからリソースを取り出すアプリケーションであり得る。リソースは、(上記の実施例に類似する)temperatureReadingクラスに結び付くセマンティクス属性を有し得る。リソースのコンテナ内のデータを理解して解釈するために、App1は、リソースのセマンティクス属性が結び付けられるセマンティクス関連リソース、この場合は、temperatureReadingクラスを読み出す必要があろう。App1は、temperatureReadingクラスセマンティクス関連リソースの表現を読み出した後、現在、整数であり、摂氏単位を有することが分かっている、リソースデータを解釈できるであろう。
図8は、一実施例による、セマンティクスノードにおけるセマンティクス関連リソース発見要求の処理を図示するフロー図である。ブロック221では、セマンティクスノードが、要求されたセマンティクス関連リソースのタイプと、潜在的な検索文字列とを含む、セマンティクス関連リソース発見要求を受信する。ブロック222では、セマンティクスノードが、発見要求をチェックする。要求が不十分であるか、または不正な形式である(例えば、要求されたリソースのタイプが欠落している)場合、発見要求は無効と見なされ、無効な発見応答がブロック233によって示されるように発行側(例えば、要求クライアントデバイス)に返信されるであろう。ブロック223によって示されるように、要求が有効である場合、検索文字列は、ローカルで記憶されたセマンティクス関連リソースと比較される。具体的には、要求されたセマンティクス関連リソースのタイプに基づいて、セマンティクスノードは、どのタイプ(すなわち、クラス、関係、またはターム)のセマンティクス関連リソースをそれが検索するであろうかを決定することができる。ブロック224によって示されるように、キーワードとして検索文字列を使用して、セマンティクスノードは、1つ以上の一致するセマンティクス関連リソースを見出すように、そのローカルセマンティックデータベースを検索する。一致するセマンティクス関連リソースがローカルで見出された場合、セマンティクス関連リソースのアドレス(例えば、URL/URI)が、ブロック225によって示されるように、発見応答で発行側に返信され得る。
ローカルで見出された一致するセマンティクス関連リソースがない場合、セマンティクスノードは、その兄弟セマンティクスノードから、一致するセマンティクス関連リソースを見出そうとするであろう。ブロック226およびブロック227によって示されるように、セマンティクスノードは、発見要求を兄弟に転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック228では、一致するセマンティクス関連リソースが連絡を受けた兄弟から見出されるかどうかが決定される。一致するセマンティクス関連リソースがその兄弟から返信される場合、セマンティクス関連リソースの対応するアドレス(例えば、URI/URL)が、成功した発見応答とともに発行側に返送される(ブロック225)。
セマンティクスノードの兄弟から返信される、一致するセマンティクス関連リソースがない場合、ブロック229によって示されるように、親セマンティクスノードが連絡を受けることができるかどうかが決定される。親セマンティクスノードがない場合、否定結果を示す発見応答が発行側に返信されるであろう(ブロック233)。親セマンティクスノードがある場合、セマンティクスノードは、その親セマンティクスノードから一致するセマンティクス関連リソースを見出そうとするであろう。それぞれ、ブロック230およびブロック231によって示されるように、セマンティクスノードは、発見要求を親セマンティクスノードに転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック232では、一致するセマンティクス関連リソースが連絡を受けた親から見出されるかどうかが決定される。一致するセマンティクス関連リソースが連絡を受けた親から返信される場合、セマンティクス関連リソースの対応するアドレス(例えば、URI/URL)が、成功した発見応答とともに発行側に返送される(ブロック225)。セマンティクスノードの親から返信される、一致するセマンティクス関連リソースがない場合、否定結果を示す発見応答が発行側に返信されるであろう(ブロック233)。
発行側が、一致するセマンティクスリソースのアドレス(例えば、URL/URI)を含む成功した発見応答を受信した後、発行側は、セマンティクスリソースの表現を読み出すことができる。
一実施例では、セマンティクスノードは、クライアントおよびサーバから成る、RESTfulアーキテクチャ形式(表現状態転送)をサポートし得る。クライアント(例えば、発行側)は、サーバ(例えば、セマンティクスノード)へのセマンティクス要求を開始する。この例では、サーバ(例えば、セマンティクスノード)は、セマンティクスに対する要求を処理し、適切なセマンティクス応答を返信する。要求および応答は、セマンティクス関連リソースの表現の転送の周囲で構築される。クライアントは、セマンティクス関連リソース(例えば、クラス、関係、またはターム)に対するRESTful動作をセマンティクスノードに要求することができる、アプリケーション、ユーザ、デバイス、セマンティクスノード等であり得る。
RESTfulアーキテクチャでリソースを取り扱うとき、セマンティクス関連リソースに適用され得る4つの基本的方法がある。
・CREATE:クラス、関係、またはタームリソースを作成する
・RETRIEVE:クラス、関係、またはタームリソースのコンテンツを読み取る
・UPDATE:クラス、関係、またはタームリソースのコンテンツを書き込む
・DELETE:クラス、関係、またはタームリソースを削除する
RESTfulサーバの役割を果たすセマンティクスノードが、受信した要求を確認し得る。動作は、発行側が適正なアクセス権を与えられている場合に可能にされる。
図9は、本RESTful実施例による、これらのRESTfulセマンティクスノード動作をさらに図示するメッセージフロー図である。ステップ243では、発行側241が、RESTful CREATE、UPDATE、RETRIEVE、またはDELETEの動詞を対応して使用して、セマンティクス関連リソース(クラス、関係、またはターム)を作成、更新、読み出し、または削除するように要求する。発行側241は、アプリケーション、別のセマンティクスノード、デバイス、ユーザ等であり得る。ステップ243でセマンティクス関連リソースを作成するために、発行側241は、セマンティクス関連リソースのタイプおよび表現を提供するCREATE要求を発行する。ステップ243でセマンティクス関連リソースを更新するために、発行側241は、セマンティクス関連リソースの一意の識別またはアドレス、および、更新または部分的に更新された表現を提供するUPDATE要求を発行する。ステップ243でセマンティクス関連リソースを読み出すために、発行側241は、セマンティクス関連リソースの一意の識別またはアドレス、および随意に検索文字列パラメータを提供するRETRIEVE要求を発行する。ステップ243でセマンティクス関連リソースを削除するために、発行側241は、セマンティクス関連リソースの一意の識別またはアドレスを提供するDELETE要求を発行する。
ステップ244では、セマンティクスノード242が、サーバの役割を果たし、受信した要求を確認するか、別様にそれを処理する。受信した要求は、発行側241が適正なアクセス権を与えられている場合に許可される。作成動作がセマンティクスノード242によって許可される場合、新しいセマンティクス関連リソースは、それがクラス、関係、またはタームであるかどうかに基づいて、適切なリソースプールの下で作成される。そしてセマンティクス関連リソースは、セマンティクスノード242によって一意の識別子またはアドレスを割り当てられる。更新動作がセマンティクスノード242によって許可される場合、セマンティクス関連リソースの表現が更新される。読み出し動作がセマンティクスノード242によって許可される場合、セマンティクス関連リソースの表現は、発行側241が要求する形式で準備される。削除動作がセマンティクスノード242によって許可される場合、要求されたセマンティクス関連リソースが削除される。
ステップ245では、セマンティクスノード242が応答を発行側241に返信する。作成動作については、新たに作成されたセマンティクス関連リソースの識別またはアドレスが発行側に返信される。更新動作については、動作が成功しようとそうでなかろうと、応答コードが発行側241に返信される。読み出し動作については、発行側241が要求する形式のセマンティクス関連リソースの表現が、発行側241に返信される。削除動作については、動作が成功したかどうかを示すように、応答コードが発行側241に返信される。
図10は、本明細書に説明されるセマンティクス関連リソース発見、読み出し、および確認をさらに図示するメッセージフロー250である。本実施例では、ネットワークは、発行側251、セマンティクスノード252、セマンティクスノード252の兄弟である兄弟セマンティクスノード253、およびセマンティクスノード252にとって親である親セマンティクスノード254を含み得る。ステップ256では、発行側251が、セマンティクス関連リソース発見要求をセマンティクスノード252に送信する。メッセージフロー250に示されるように、セマンティクスノード252は、ステップ256で、要求に一致するセマンティクス関連リソースを見出すように、(図8のプロセスに類似する)いくつかのステップを通過する。図示されるように、第1に、セマンティクスノード252は、そのローカルディレクトリを検索するであろう。それは、いかなる一致リソースも見出さない場合、時間窓を設定し、発見要求を兄弟253等のその兄弟に転送するであろう。応答がその兄弟から受信されない場合、セマンティクスノード252は、その要求を親セマンティクスノード254に転送するであろう。本実施例では、親セマンティクスノード254が一致するリソースを見出し、それが見出したセマンティクス関連リソースのアドレス(例えば、URI/URL)を示す応答をセマンティクスノード252に返送するであろうことが仮定される。
ステップ257では、次いで、セマンティクスノード252が、発行側251の要求に一致した、親セマンティクスノード254からのセマンティクス関連リソースのアドレス(例えば、URI/URL)を含むセマンティクス関連リソース発見応答を発行側251に返送する。ステップ259では、発行側251が、受信したURLに基づいてセマンティクス関連リソース読み出し要求を送信する。ステップ260では、親セマンティクスノード254が、クラス、関係、またはタームを含み得る、要求されたセマンティック情報を含む、セマンティクス関連リソース読み出し応答を送信する。
ステップ261では、発行側251が、ステップ260からの受信したセマンティック情報の表現をチェックする(確認する)。ステップ260で送信される、受信したセマンティクス関連リソースが、正確には発行側251が所望するものではない可能性がある。例えば、発行側251が温度クラスを要求し、返信された一致するリソースが関連華氏単位を伴うtemperatureReadingと呼ばれるクラスであるが、発行側251が摂氏単位を伴う温度クラスを所望する場合、発行側251は、親セマンティクスノード254がセマンティクスを修正することを要求することができる。これは、セマンティクス関連リソースを修正するように、ステップ262でセマンティクス関連リソース修正要求を親セマンティクスノード254に送信することによってサポートされることができる。ステップ263では、新たに追加または修正されたセマンティクス関連リソースのアドレス(例えば、URL/URI)が、発行側251に返信されるであろう。
セマンティクス関連リソースの修正に関して、概して、セマンティクスノードがそれ自体で修正をサポートしない場合、セマンティクスノードは、修正を行うようにその兄弟または親と協力し得る。セマンティクスノードが修正をサポートする場合、セマンティクスノードは、新しいクラスを追加するか、現在のクラスを拡張することによって、クラスをローカルで修正し得る。
(C.セマンティクス関連リソースへの加入)
一実施例では、セマンティクスノードは、それに加入するクライアント(例えば、アプリケーション、別のセマンティクスノード、デバイス、ユーザ等)をサポートすることができる。一例として、クライアントは、加入したセマンティクス関連リソースへの任意の更新があるときに通知されるように、セマンティクスノードに加入し得る。更新が起こると、加入クライアントは、リソースの新しい表現で通知されるであろう。それ自体がセマンティクスノードであるクライアントの場合、加入したセマンティクス関連リソースは、加入者セマンティクスノードが関係しない(例えば、親子または兄弟ではない)別のセマンティクスノードに記憶され得る。この例では、クライアントは、SEMANTICS_RESOURCE_SUBSCRIBE_REQメッセージをセマンティクスノードに発行し得る。メッセージは、リソースが更新されたときにクライアントが通知を受信することを希望するセマンティクス関連リソースを識別する。セマンティクスノードは、加入を承認するSEMANTICS_RESOURCE_SUBSCRIBE_RESPメッセージで要求に応答するであろう。クライアントが加入したセマンティクス関連リソースが更新されると、セマンティクスノードは、更新についてクライアントに通知するために、SEMANTICS_RESOURCE_SUBSCRIBER_NOTIFYメッセージを送信するであろう。
別の例として、セマンティクスノードは、その兄弟、親、または子セマンティクスノードのうちの1つによって記憶および管理されるセマンティクス関連リソースに関して更新されることに関心があり得る。図11は、一実施例による、この状況のための加入/通知プロセスの例示的なフロー270である。本実施例では、セマンティクスノード271は、加入先セマンティクスノード272によって記憶および管理されるセマンティクス関連リソースに関して更新される。加入先セマンティクスノード272は、セマンティクスノード271の兄弟、親、または子であり得る。ステップ273では、セマンティクスノード271が、加入標的を識別し、トリガ基準に関連するセマンティクス関連リソース通知のみを受信するように、通知トリガ基準を設定し得る。例えば、加入者は、特定のセマンティクス関連リソース、または新しい通知が送信される前のセマンティクス関連リソースに対する更新の特定数を特定するように通知トリガ基準を構成し得る。セマンティクスノード271はまた、通知が送信されるべきときの期間スケジューリング情報を設定し得る。
ステップ274では、セマンティクスノード271が、セマンティクスノードリソース加入要求を標的セマンティクスノード272に送信する。ステップ275では、標的セマンティクスノード272が、ステップ274のセマンティクス加入要求を受理するかどうかを決定する。標的セマンティクスノード272は、既存の加入者、加入を取り扱う負荷(例えば、更新情報の収集または通知を送信するために使用される帯域幅に関する負荷)等に基づいて、加入要求を受理するかどうかを決定することができる。ステップ276では、標的セマンティクスノード272が、セマンティクスノード加入応答をセマンティクスノード271に送信する。ステップ276での応答は、加入の確認、および加入を処理する際に使用されるであろうパラメータを含み得る。ステップ277では、ステップ276後のある時点で、標的セマンティクスノード272が、ステップ274で受信される要求トリガに一致する、セマンティック通知トリガ条件を検出する。ステップ278では、標的セマンティクスノード272が、特定のセマンティクス関連リソースに関してセマンティクスノード271を更新するためのセマンティクスノードリソース加入通知メッセージを送信する。
概して、セマンティクス関連リソース加入は、ピアセマンティクスノードまたは親セマンティクスノードからのセマンティクス関連リソース発見を促進することができる。例えば、(セマンティクスノードに記憶される、新たに作成または更新されたセマンティクス関連リソースのURIを含むであろう)通知メッセージに基づいて、セマンティクスノードは、発見要求を送信することなく、他のノードのセマンティクス関連リソースに対する発見を行うことが可能であり得る。
(D.セマンティクス関連リソースへの結び付きおよび関連付け)
セマンティクスノードのセマンティクス関連リソースは、種々の方法で使用されることができる。例えば、セマンティクス関連リソース表現は、セマンティクスノードから読み出され得、データが(例えば、ネットワークサーバ上、デバイス上、ゲートウェイ上等に)記憶されるネットワーク場所に、共同設置様式で記憶され得る。代替として、リソースのセマンティクスは、セマンティクスノード上に記憶され得、セマンティクスへのリンクは、同一場所に位置し、データとともに記憶され得る。このセマンティクスリンクは、データ内にインラインで記憶され(すなわち、埋め込まれ)得るか、またはデータのそばに別々に(例えば、別個のリソースまたは属性に)記憶され得る。したがって、このセマンティクス関連リソースへの結び付きを通して、セマンティクスがM2Mシステム内の通常リソース(例えば、<SCL>、<application>、<container>等)に適用されることができる。典型的には、この結び付きは、リソースが作成されるときにリソース作成者/生成者によって作成されるであろう。
図1の患者健康監視アプリケーションの以前の実施例を続けると、セマンティクスノードにおいて定義されるセマンティッククラスがあり、これらのクラスのURLは、患者健康監視アプリケーションによって発見され得る。表2は、患者健康監視アプリケーションに関連するタイプ「クラス」のセマンティクス関連リソースの実施例を示す。データが、hasTypeと呼ばれるセマンティック関係を使用して、これらのセマンティッククラスに結び付けられ得る。結果として、example/healthmonitoring/data1というURIを伴う各データリソースに対して、リソースのセマンティクスは、以下の関連によって把握されるであろう。
・example/health/patient/data1 hasType semanticsNode1/class/patient
・example/health/doctor/data2 hasType semanticsNode1/class/doctor
・example/health/bp/data1 hasType semanticsNode1/class/bloodpressure
・example/health/temp/data1 hasType semanticsNode1/class/temperature
・example/health/hr/data5 hasType semanticsNode1/class/heartrate
hasType関係はまた、セマンティクスノード上に記憶されたhasType関係のセマンティック記述を参照するURL/URIによって識別され得る。
(E.グループ化最適化)
リソースのグループが類似セマンティクスを有する(例えば、同一のアプリケーション内の全てのリソースが、同一のセマンティクスを有する)場合、そのアプリケーションの下の各個々のリソースへの代わりに、類似セマンティクスがアプリケーションに適用され得る。図12は、その一実施例による、同一のセマンティクスを伴うリソースのグループ化の方法281を図示する。ステップ281では、同一のアプリケーションの既存のデータの一部が、同一のセマンティクス関連付けを共有すると決定される。ステップ282では、同一のセマンティクスを共有する、同一のアプリケーション内の決定されたデータが、グループに分類される。ステップ283では、ステップ282の各グループが、適切なセマンティクスに関連付けられる。ステップ284では、同一のアプリケーションからの新たに受信したデータが、同一のセマンティクスを共有するグループに入れられる。同一のアプリケーションの既存のデータは、それらの各々が同一のセマンティクス結び付きおよび関連付けを共有する複数のグループに分類され得る。新しいデータが同一のアプリケーションから生成される場合、データは、同一のセマンティクスを共有するグループに入れられる。
例えば、血圧監視データの複数のインスタンスは、同一のセマンティクスを有する。したがって、各インスタンスは、以下に示されるような同一のセマンティクス(semanticsNode1/class/bloodpressure)に関連付けられ得る。・example/health/bp/data1 hasType semanticsNode1/class/bloodpressure
・example/health/bp/data2 hasType semanticsNode1/class/bloodpressure
・example/health/bp/data3 hasType semanticsNode1/class/bloodpressure
・・・・
このグループ化最適化をサポートすることによって、以下の関連付けも有効であり得る。・example/health/bp hasType semanticsNode1/class/bloodpressure
(F.セマンティクス関連リソースをプッシュ配信する)
上記のように、セマンティクスノードでホストされるクラス、関係、およびタームは、他者によって発見され、使用され得る。要求の頻度に基づいて、セマンティクス関連リソースのうちのいくつかが、より容易な発見またはアクセスのために、プッシュ配信され得るか、または別のセマンティクスノードにおいてミラーリングされ得る。例えば、1つのセマンティクスノードが、別のセマンティクスノードから同一の転送された発見要求を(例えば、ポリシー定義閾値を超える)ある回数検出した後に、それは、セマンティクス関連リソースのミラーリングされたコピーをそのセマンティクスノードにプッシュ配信することを決定し得る。
セマンティクス関連リソースのプッシュ配信は、図13に示されるように、兄弟間で、または親マンティクスノードと子セマンティクスノードとの間で起こることができる。例えば、コアネットワーク295内の図13のセマンティクスノード291は、セマンティクスノード292、セマンティクスノード293、およびセマンティクスノード294から、同一のセマンティクス関連リソース(例えば、温度)に対する多くの発見および読み出し要求を受信し得る。発見要求が定義された閾値に達するとき、セマンティクスノード293およびセマンティクスノード294がより速い応答時間でセマンティクス関連リソースにアクセスし得るように、セマンティクスノード291は、セマンティクスノード292上に同一のセマンティクス関連リソースを作成する(すなわち、リソースをミラーリングする)ことを決定し得る。セマンティクスノード291は、他のセマンティクスノードにSEMANTICS_RESOURCE_CREATE_REQメッセージを発行すること(そして、他のセマンティクスノードが適切なSEMANTICS_RESOURCE_CREATE_RESPメッセージで応答するであろうこと)によって、セマンティクスノード上にミラーリングされたリソースを作成し得る。
以下のオプションは、セマンティクス関連リソースを最新の状態に保つために使用され得る。図13を参照すると、セマンティクスノード291は、セマンティクス関連リソースの元の表現への任意の更新がある場合に、セマンティクスノード292上のセマンティクス関連リソースを自動的に更新し得る(例えば、加入が必要とされない)。代替として、セマンティクスノード292は、元のセマンティクス関連リソースに加入し得る。セマンティクス関連リソースへのセマンティクスノード292の加入に基づいて、セマンティクスノード292は、特定の加入先セマンティクス関連リソースに対する任意の変更を通知されるであろう。前述のシナリオの組み合わせもあり得る。例えば、セマンティクスノード291の自動更新が、セマンティクスノード291上の全てのセマンティクス関連リソースに対して周期的に起こる状況があり得るが、セマンティクスノード292は、特定の加入セマンティクス関連リソースに対するより即時の更新を所望する。
セマンティクス関連リソースのプッシュ配信は、兄弟間で、または親と子との間でいずれかの方向に起こることができる。例えば、図13を参照すると、セマンティクスノード296は、あるローカルセマンティクス関連リソースをその親セマンティクスノード297にプッシュ配信し得る。別の例では、セマンティクスノード291は、ある高レベルセマンティクス関連リソースをその子セマンティクスノード298にプッシュ配信し得る。
(G.データ/セマンティクス関連リソース移動)
図14は、デバイスが1つのネットワークから別のネットワークへ移動するシナリオを図示する。このシナリオでは、デバイスに関連するセマンティクスリソース、およびデバイスによって生成されるデータもまた、セマンティクスリソース読み出しによるセキュリティ、オーバーヘッド、および/または負荷のために、新しい場所へ移動させられる必要があり得る。
図14を参照すると、デバイスは、最初に、エリアネットワーク301内に位置していたが、エリアネットワーク302へ移動している。最初に、デバイス309は、セマンティクスノード306と通信していた。デバイス309がエリア302に到着した後、デバイス309は、最初に、線303によって実証されるように、セマンティクスノード306に通信し続け得る。これは、アクセスネットワーク304、アクセスネットワーク308、およびコアネットワーク300における不必要なオーバーヘッドをもたらし得る。この問題および他の問題に対処するために、セマンティクスノード306のセマンティクス関連リソースは、エリアネットワーク302内のセマンティクスノード307に移動させられ得る。セマンティクス関連リソースをセマンティクスノード307に移動させた後、デバイス309は、セマンティクス関連リソースのためにコアネットワーク300を横断する必要はないが、代わりに、線305によって示されるように、セマンティクスノード307と通信することができる。
図15は、図14で描写されるようなデータまたはセマンティクス関連リソースの移動をさらに図示するメッセージフロー310の実施例である。ステップ315では、第1のエリアネットワーク内のセマンティクスノード311が、エリアネットワーク2内に位置するデバイスアプリケーション314とメッセージを交換する。ステップ315で交換されるメッセージは、例えば、セマンティクス関連リソース読み出し要求およびセマンティクス関連リソース読み出し応答を含み得る。ステップ316では、セマンティクスノード311が、デバイスアプリケーション214に関連付けられるセマンティクス関連リソースを、第2のエリアネットワーク内に位置するセマンティクスノード313に移動させることを決定する。セマンティクスノード313は、第1のエリアネットワークより通信的に近く(到達するためにより少ない時間を要する)、または論理的に近く(例えば、より少ないホップ)あり得る。ステップ316に関して、他のデバイス(セマンティクスノード発見サーバ312、デバイスアプリケーション314、または別のコンピュータデバイス(図示せず)等)が、セマンティクス関連リソースを移動させる決定を行い得る。
ステップ317では、セマンティクスノード発見要求および応答が、セマンティクスノードの階層ならびに兄弟関係を構築するために、セマンティクスノード311とセマンティクスノード発見サーバ312との間で交換される。ステップ318では、セマンティクスノード311が、セマンティクスノード313のアドレスを決定する。ステップ320では、セマンティクス関連リソース作成要求メッセージが、デバイスアプリケーション314によって使用されるセマンティクス関連リソース(および他のデータ)をコピーするために、セマンティクスノード313に送信される。セマンティクスノード313は、セマンティクス関連リソースおよび他のデータのコピーが成功したという確認応答を含み得る、セマンティクス関連リソース作成応答メッセージで応答する。ステップ321では、セマンティクス連鎖更新要求メッセージが、デバイスアプリケーション314に送信される。ステップ321でのメッセージは、デバイスアプリケーション314がセマンティクスノード313からセマンティクス関連リソースを取り出すための命令を含み得る。ステップ322では、セマンティクス連鎖更新応答メッセージは、セマンティクスノード連鎖が更新されるという確認応答を含み得る。ステップ323では、デバイスアプリケーション314が、セマンティクスノード313から、クラス、関係、およびタームのタイプのセマンティクス関連リソースを読み出す。
(V.ETSI M2M/oneM2M実施例)
(A.セマンティクスノードを伴うETSI M2Mアーキテクチャ)
上記のように、本明細書に説明されるセマンティクスノード概念は、ETSI M2Mアーキテクチャを拡張するために使用されることができる。一実施例では、1つ以上のセマンティクスノードは、図16に示されるように、M2Mセマンティクスノードと称され得る独立型ネットワークエンティティとしてアクセス/コアネットワーク内に位置し得る。図16では、M2Mセマンティクスノード331およびM2Mセマンティクスノード332は、同一のアクセス/コアネットワーク330内に位置する。エリア/コアネットワーク330内のM2MセマンティクスノードM2M331、およびM2Mセマンティクスノード332は、上記で説明されるsIc基準点を介して、DSCL、GSCL、NSCL、およびアプリケーションと連動し得る。加えて、M2Mセマンティクスノード331、およびM2Mセマンティクスノード332は、sIs基準点334を介して互いに連動し得る。M2Mセマンティクスノード331、およびM2Mセマンティクスノード332はまた、sIe基準点を介して、別のタイプの外部セマンティクスノード333を参照し得る。本実施例では、アクセス/コアネットワーク330内に位置するM2Mセマンティクスノードはまた、兄弟および/または親子関係を形成し得る。
セマンティクスノードは、現在のETSI M2Mアーキテクチャのサービス能力層(xSCL)で使用されるような補完的リソース構造をサポートし得、このリソース構造は、図17で図示される様式で、本明細書に説明されるセマンティクスノードに適用され得る。本実施例では、<ssBase>リソース341は、ホスティングセマンティクスノード上に常駐するリソースツリーのルートである。<ssBase>リソース341は、ホスティングセマンティクスノードを説明する属性を含み得る。<ssBase>リソース341は、とりわけ、SSリソース343、クラスリソース344、関係リソース346、タームリソース348、アクセス権リソース349、および加入リソース350の集合を表す集合リソースを含む。クラスリソース344の下には、クラスリソース344の下位クラスである他の<class>リソース345があり得る。関係リソース346の下には、関係リソース346の下位関係である、<relationship>リソース347があり得る。SSリソース集合343は、遠隔セマンティクスノードがローカルセマンティクスノードに登録または登録解除するときに、作成または削除されるセマンティクスノードリソースを含む。
図18に示されるように、SSリソース343に対する集合の中の各セマンティクスノードリソースは、対応するリソース構造を有し得る。これらのリソースは、ローカルセマンティクスノードに登録された遠隔セマンティクスノードの状態を維持する。例えば、連絡先情報、発見情報(例えば、発表されたセマンティッククラス、表現、およびタームリソース)、およびセキュリティ情報(例えば、対応する遠隔セマンティクスノードと通信するために使用される信用証明)等の状態である。
図17を再度参照すると、<ssBase>リソース341の下のクラス344、関係346、およびターム348集合は、各々、ローカルセマンティクスノード上でホストされるセマンティクス関連リソースのそれぞれのインスタンスを含むことができる。各インスタンスは、セマンティック表現を含むとともに、タグ等の発見関連情報等のそれに関連付けられる他の属性を有することができる。セマンティクス関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされることができる。<ssBase>リソース341の下のアクセス権リソース349は、アクセス権リソースのインスタンスを含むことができる。これらのアクセス権リソース349は、どのクライアントが、セマンティクスノードによってサポートされるどのセマンティクス関連リソースおよび動作へのアクセスを供与されるかを制御するアクセス権のインスタンスを定義することができる。代替として、アクセス権集合の他のインスタンスは、より粒度の細かいアクセス制御を提供するようにリソース構造でサポートされることができる(図17に示されていない)。加入リソース350の集合は、加入リソースのインスタンスを含むことができる。加入リソースのインスタンスは、特定通知トリガ基準イベントが起こるときに、セマンティクスノードからセマンティック通知を受信することを希望するクライアントによって作成されることができる。発見リソース342は、クライアントセマンティック発見要求をサポートする。これらの発見要求は、検索基準(例えば、特定のタイプの属性を有するセマンティクス関連リソース)をサポートすることができる。セマンティクスノードは、(存在する場合)検索基準に一致するリソースアドレス(例えば、URI)のリストで発見要求に応答することができる。セマンティクスノードはまた、他のセマンティクスノードへの要求の転送(例えば、子、兄弟、または親セマンティクスノードへの発見要求の転送)をサポートすることもできる。
(B.セマンティクス能力を伴うxSCL)
図19で図示される別の実施例では、M2Mセマンティクスノードは、別個の独立型セマンティクスノードとしてよりも、ETSI M2MアーキテクチャのDSCL、GSCL、および/またはNSCL内の組み込まれた能力として展開され得る。この組み込まれた実施例では、sIs基準点は、別個のままであり得るか、またはETSI M2M mId基準点が、sIs機能性をサポートするように拡張させられ得る。同様に、sIc基準点は、別個のままであり得るか、またはETSI M2M mIaおよびdIa基準点が、sIc機能性をサポートするように拡張させられ得る。本実施例では、GSCLまたはDSCL内に位置するM2Mセマンティクスノードは、それらが登録されるNSCLと親子関係を確立し得る。加えて、GSCLまたはDSCL内に位置するセマンティクスノードはまた、互いに兄弟関係を確立し得る。
図19の実施例をサポートするために、xSCLは、図20に示されるリソース構造を有し得る。セマンティクスノードのリソース集合は、セマンティクスノード能力を有する遠隔SCLがローカルSCLに登録または登録解除するときに作成または削除されるセマンティクスノードリソースを含む。この集合の中の各セマンティクスノードリソースは、図20に示される対応するリソース構造を有し得る。これらのリソースは、ローカルSCLに登録される遠隔セマンティクスノードの状態を維持する。例えば、セマンティック発見情報(例えば、発表されたセマンティッククラス、表現、およびタームリソース)等の状態である。
<sclBase>リソース361の下のクラス、関係、およびターム集合はそれぞれ、ローカルSCL上でホストされるセマンティクス関連リソースのそれぞれのインスタンスを含み得る。<Sscl>は、本明細書で議論されるように、セマンティクス関連リソースのルートの名前として使用される。ルートは、例示的な命名であり、本明細書で議論されるように命名される必要はない。各インスタンスは、セマンティック表現を含むとともに、タグ等の発見関連情報等のそれに関連付けられる他の属性を有し得る。セマンティクス関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされ得る。
(C.ETSI M2Mセマンティクス実装の使用事例の実施例)
セマンティクスノードによって管理されるセマンティクス関連リソースは、<sclBase>、<application>、<container>、<contentInstance>等のETSI M2Mリソース構造のリソースに関連付けられ、結び付けられ得る。以下の議論は、<contentInstance>のセマンティック情報を提供するために、どのようにしてセマンティクス関連リソースが使用され得るかを例証する。
本実施例では、temperatureReadingクラスは、scl1上で定義および記憶され、scl1/classes/temperatureReadingというURIを有することを仮定されたい。hasLocationという関係も、scl1上で定義および記憶され、scl1/relationships/hasLocationというURIを有する。加えて、‘northeast China’というタームも、scl1上で定義および記憶され、scl1/terms/northeastChinaというURIを有する。図21は、図20に示されるxSCLリソース構造の実施例である、<scl1>上のセマンティクス関連リソース構造を示す。このリソース構造は、セマンティクス関連リソースのURIを決定する。contentInstanceは、gscl2/applications/app1/containers/<temperature>/contentInstances/<inst1>というURIを有する。図22のxSCLリソース構造で示されるようなセマンティクスを用いてcontentInstanceを拡張することによって、contentInstanceのコンテンツは、効果的に記述され、曖昧性を伴わずに解釈されることができる。
図23は、リソースおよびセマンティクス読み出しの一実施例を図示するメッセージフローである。ステップ393では、NA390が、データリソースに対するRETRIEVE要求をGSCL2 391に送信する。データリソースは、例えば、とりわけ、血圧センサ示度値、中核体温センサ示度値、酸素飽和度センサ示度値、または運動加速度計センサ示度値であり得る。ステップ394では、GSCL2 391が、データリソースの表現を返信する。データリソースを理解するために、NAは、データリソースのセマンティクスを読み出す必要がある。したがって、ステップ395では、NA390が、読み出し要求をGSCL391に送信する。ステップ396では、GSCL2 391が、SCL1 392上に記憶されるデータリソースに対する関連のセマンティクス関連リソースのURIのリストを返信する。ステップ397から399では、NA390が、それぞれ、temperatureReading、hasLocation、およびnortheastChinaというセマンティクス関連リソースに対するRETRIEVEメッセージをSCL1 392と交換する。これらのセマンティクス関連リソースにより、NA390は、データリソースを理解することができ、したがって、データリソースを使用および操作することができる。
(VI.3GPP MTCアーキテクチャ実施例)
さらに上記のように、3GPP MTCアーキテクチャは、本明細書に説明されるセマンティクスノードによって提供されるセマンティクスサポートを用いて拡張させられ得る。図24に示されるように、一実施例では、M2Mセマンティクスノード401は、3GPPコアネットワーク境界の外側に位置し得る。さらに示されるように、SCS404は、セマンティクス能力をサポートするように拡張させられ得、かつsIs基準点(図示せず)を介してM2Mセマンティクスノード401と連動し得る。M2Mセマンティクスノード401はまた、sIc基準点403を介して、3GPPマシン型通信連動機能(MTC−IWF)402と連動し得る。アプリケーションサーバ(AS)406およびAS407は、sIc基準点400を介してM2Mセマンティクスノード401と通信し得る。図25は、セマンティクスノードを伴う3GPP MTCアーキテクチャの別の実施例を図示する。本実施例では、セマンティクスノードは、SCS408に組み込まれている。図25で409においてさらに示されるように、本実施例では、sIc基準点は、3GPP MTC Tspの一部であり得る。
(オントロジー言語)
セマンティックウェブは、語彙、分類、およびオントロジーの能力を提供するために、スキーマ言語とオントロジー言語との組み合わせを使用すると言われ得る。語彙は、通信で使用される明確に定義されたタームの集合と見なされ得る。分類は、タームが階層様式で組織化される語彙と見なされ得る。各タームは、分類の中の1つ以上の他の要素と親子関係を共有し得る。オントロジーは、概念および規定関心分野に対する概念間の関係またはそれ以上を定義するために、タームの所定の確保された語彙を使用する。オントロジーは、実際には、語彙、分類、またはそれ以上のもののいずれかを指すことができる。典型的には、タームは、知識ドメインを記述するための豊富な形式論理ベースのモデルを指す。オントロジーを使用して、語彙タームの背後のセマンティクス、それらの相互作用、および使用の文脈を表現することができる。
RDFスキーマ(RDFS)は、クラスおよびプロパティの分類、ならびにプロパティのための単純なドメインおよび範囲仕様を定義するために使用されることができる、RDFのための具体的語彙を提供する。ウェブオントロジー言語(OWL)は、ドメイン知識のセマンティクスを捕捉するオントロジーを定義するための表現言語を提供する。
要約すると、以前に議論されたように、RDFは、ウェブで情報を表すためのフレームワークである。RDFは、本質的に、データモデルである。その基礎的構成要素は、ステートメントと呼ばれる、リソース・プロパティ・値のトリプルである。RDFは、XMLで構文を与えられている。図27に示される例では、ステートメントは、以下で示されるようにRDFで表されることができる、John Smithの肩書が教授であることである。xmlns:uniは、プロパティ(名前および肩書)がRDFSの一部として定義される、自己定義されたドメイン名である。
<rdf:RDF
xmlns:rdf=“http://www.w3.org/1999/02/22−rdf−syntax−ns#”
xmlns:xsd=“http://www.w3.org/2001/XLMSchema#”
xmlns:uni=“http://www.mydomain.org/uni−ns”>
<rdf:Description rdf:about=“949352”>
<uni:name>John Smith</uni:name>
<uni:title>Professor</uni:title>
</rdf:Description>
</rdf:RDF>
RDFは、特定の使用ドメインについての仮定が行われない、ドメイン独立型である。RDFSと呼ばれるスキーマ言語で独自の用語を定義することは、ユーザ次第である。RDFSは、RDFデータモデルで使用される語彙を定義する。RDFSでは、語彙を定義し、どのプロパティがどの種類のオブジェクトに適用されるか、およびそれらがどのような値をとることができるかを規定し、オブジェクト間の関係を記述することができる。
OWLは、ウェブのためのより多くの表現オントロジーを構築するために使用されることができる、追加のリソースを用いてRDFS語彙を拡張する。OWLは、処理をより計算上決定可能にするために、RDF文書の構造およびコンテンツに関する追加の制限を導入する。OWLは、RDFおよびRDFS、XMLスキーマデータタイプ、ならびにOWL名前空間を使用する。OWL語彙自体は、名前空間http://www.w3.org/2002/07/owl#において定義され、一般的にプレフィックスowlによって参照される。OWL2は、元のOWL語彙を拡張し、同一の名前空間を再利用する。
データタイプは、URIを使用して識別されるデータ値の範囲を表す。OWLは、殆どがXMLスキーマ定義(XSD)名前空間において定義される、いくつかの所定のデータタイプを使用することを可能にする。
OWLは、クラスrdfs:Datatypeのインスタンスを作成し、1つ以上のファセット制限をインスタンスに関連付けることによって、独自のデータタイプを定義することを可能にする。ファセット制限は、有効値の範囲を構成する具体的データタイプの値のセットを記述する方法である。表3は、OWLによってサポートされるファセットを含む。
複合タイプは、その要素およびテキスト子ならびにその属性を含む、要素の許可されたコンテンツを記述する。複合タイプ定義は、属性使用のセットおよびコンテンツモデルから成る。複合タイプは、制限(ベースタイプが許可するいくつかの要素、属性、または値を無効にする)によって、または拡張(追加の属性および要素が出現することを可能にする)によって、別の複合タイプから導出されることができる。(データタイプとも呼ばれる)単純タイプは、要素または属性に出現し得るテキスト値を制約する。
W3C XMLスキーマ定義言語(XSD)は、19個の基本データタイプのセット(anyURI、base64Binary、ブール、日付、dateTime、小数、2倍、持続時間、浮動、hexBinary、gDay、gMonth、gMonthDay、gYear、gYearMonth、NOTATION、QName、文字列、および時間)を提供する。これは、新しいデータタイプが3つの機構によってこれらの基本要素から構築されることを可能にする。
・ 制限(許可された値のセットを削減する)
・ リスト(一連の値を可能にする)
・ 融合(いくつかのタイプからの値の選択を可能にする)
以下は、XSDでデータタイプを定義する2つの例である。
例1:
<simpleType name=“Temperature”>
<restriction base=“integer”>
</restriction>
</simpleType>
例2:
<complexType name=“BloodPressure”>
<sequence>
<element name=“s” type=“integer”/>
<element name=“d” type =“integer”/>
</sequence>
</complexType>
セマンティクス関連リソースの構造および属性が、さらに詳細に議論される。加えて、M2Mシステムにおける正規リソースに対してセマンティクスを有効にするためにこれらのリソースを使用する方法に関して、機構およびプロシージャが規定される。
M2Mシステム内のリソースのコンテンツは、通常、XSD規格で定義されるような既存の基本的なもの以外の複合データタイプである。したがって、各個々のリソースのセマンティクスを定義することなく、同じタイプのリソースが同一のセマンティクスに従い、解釈されることができる(例えば、セマンティクスグループ化最適化)ように、複合データタイプのセマンティクスを定義することが自然である。OWLは、クラスrdfs:Datatypeのインスタンスを作成し、1つ以上のファセット制限をインスタンスに関連付けることによって、独自のデータタイプを定義することを可能にするが、新しい複合データタイプを定義することにおいて手段を提供しない。換言すると、新たに定義されるデータタイプは、基本的タイプから拡張されることに限定され得る。XSDは、新しいデータタイプが、制限、リスト、および融合によって19個の基本要素から構築されることを可能にするが、リソースのコンテンツを理解するための十分な制限を提供することはできない。したがって、XSDによって複合データタイプ内のフィールドに提供されるセマンティクスは、非常に限定される。以下は、2つの例を示し、1つは、単純データタイプであり、もう1つは、XSDによって定義される複合データタイプである。
XSDに関して本明細書で議論されるように、例1は、そのようなデータタイプの値が全て整数であることを定義するために、標準制限のうちの1つを使用する、単純Temperatureデータタイプである。しかしながら、既存の制限ファセットは、温度示度値が摂氏、華氏、または何か他の単位であるかどうかが依然として曖昧であるように、値の単位を制限することができない。
例2は、それぞれが整数で値を有する、2つのフィールド‘s’および‘d’を順に有することを定義するために、リスト機構を使用する、複合BloodPressureデータタイプである。しかしながら、既存の制限ファセットは、各フィールドの単位を制限することができない。そしてシーケンスの中の要素の名前から、何が複合データに含まれる2つのフィールドであるかが把握されることができない。したがって、異なるアプリケーションがコンテンツインスタンスの中のインスタンスを理解および解釈することは可能ではない場合がある。
要約すると、前述の問題は、セマンティクス関連リソースの構造および表現と、リソースをセマンティクス関連リソースと結び付けて関連付けることによって、リソースに対してセマンティクスを有効にする方法とによって、本明細書で対処され得る。加えて、問題は、複合データタイプの中のフィールドが抽出されて解釈されることができるように、制限/ファセット単位および記述を伴うXSDの拡張を可能にする機構を介して対処され得る。最後に、問題は、それを発見可能かつ解釈可能にするデータタイプのキーワード、および各々に対する値が適切に定量化されることができるようなデータタイプの中の各フィールドの単位等の記述/属性をデータタイプの名前および複合データタイプの中のフィールドに組み込むことによって、対処され得る。
リソース構造は、以降でさらに詳細に議論されるであろう。実施例では、セマンティクスノードは、現在のETSI M2MアーキテクチャのxSCLで使用されるような補完的リソース構造をサポートし得る。セマンティクスノードのリソース構造の実施例は、図17に示される。リソース<Sscl>は、ホスティングセマンティクスノード上に存在するリソースツリーのルートである。<Sscl>は、本明細書で議論されるようなセマンティクス関連リソースのルートの名前として使用される。ルートは、例示的な命名であり、本明細書で議論されるように命名される必要はない。<Sscl>リソースは、ホスティングセマンティクスノードを記述する属性を含み得る。<Sscl>リソースは、<SS>リソース(他のセマンティクスノードからの通知されたセマンティクス関連リソース)、<class>リソース、<relationship>リソース、<term>リソース、<accessRight>リソース、および<subscription>リソースの集合を表す集合リソースを含む。
M2Mシステム内で、複数のタイプのリソースが存在することができる。以下、すなわち、クラス<class>、関係<relationship>、およびターム<term>のうちのいくつかを含み得るセマンティクス関連リソースがあり得る。セマンティクス関連リソースは、セマンティクスノード上に記憶されたリソースを指す。別様に、リソースは、正規リソースを指すために使用され得る。正規リソースは、CSEBase、アプリケーションエンティティ(AE)、コンテナ、およびoneM2Mアーキテクチャで定義されるcontentInstance等のうちのいくつかを含み得る。そして類似リソースが、ETSI M2Mアーキテクチャでも採用され得る。
以下では、本開示で提案される機構およびプロシージャを図示し得る図28に示されるようなジム使用事例を説明する。例えば、アプリケーション、サービス層(SL)という用語の使用は、それぞれ、oneM2MにおけるAE、CSE、またはETSI M2MにおけるDA/GA/NA、DSCL/GSCL/NSCLにマップされ得る。図28は、同一の用語を用いて使用事例に関与するエンティティ構成を図示する。
ジム使用事例では、ユーザが、腕時計アプリケーション711を有する腕時計710を有する。腕時計710は、ユーザの電話SL713を発見し、それに登録する。トレッドミルアプリケーション714は、ジム内の1つ以上のトレッドミル715上にあり得る。周囲センサ716は、トレッドミル715上に、およびジム全体にあり得る。周囲センサ716は、ジムSL718を発見し、それに登録し得る。そしてユーザがジムにいるとき、電話SL713は、ジムSL718を発見し、それに登録し得る。電話712上のジムアプリケーション721は、トレッドミル715を発見し、ジムSL718を介して、使用するトレッドミル715のうちの1つを選択することが可能であり得る。電話712上のジムアプリケーション721は、トレッドミル715を発見し、トレッドミルアプリケーション714のセマンティクスを把握することによって、使用するトレッドミル715のうちの1つを選択し得る。
電話712上の健康保険アプリケーション722は、周囲センサ716からデータ(例えば、ジム内の温度または湿度)、腕時計710から測定(例えば、ユーザの心拍数、血圧)、またはトレッドミル714からユーザによって終了されたジムトレーニングプログラムを収集する。健康保険アプリケーション722は、収集されたデータに基づいてユーザの健康スコアを計算し、健康スコアを健康保険会社アプリケーション724に共有し得る。電話712上の健康保険アプリケーション722はまた、データ(例えば、健康スコア、運動結果)に基づいてユーザの保険料を決定および調節することができる健康保険会社アプリケーション724に、ユーザの終了したジムトレーニングプログラムを送信し得る。健康保険アプリケーション722および健康保険会社アプリケーション724は、データの適切に追加されて有効にされたセマンティクスを使用することによって、データの同一の解釈を有し得る。
本明細書では、正規リソースに対してセマンティクスを有効にするセマンティクス機能のサービス層(SL)サポートが議論される。セマンティクス関連リソースの詳細な構造、およびどのようにしてセマンティクス関連リソースが、正規リソースに対してセマンティクスを有効にするかが開示される。
<class>のリソースツリー構造が、図29に示される。<class>リソースは、リソース・関数・値のトリプル(Value)の一部としてリソースのセマンティクスを定義するために使用される。表4は、<class>の子リソースを示す。表5は、<class>の属性を示す。
複合データタイプは、<container>リソースの下に記憶されたコンテンツインスタンスを解析するために必要とされるデータ構造を定義する、特殊なクラスである。<class>リソースのタイプ属性は、それがdataTypeであるかどうかを示すために使用される。それがdataTypeである場合、description属性が、ある構文を使用することによってデータ構造を記述するために使用される。XSDは、オプションのうちの1つである。それがdataTypeではない場合、description属性が、ある言語でクラスを定義するために使用される。RDFは、オプションのうちの1つである。RDFはまた、XML構文を有し得る。構文属性は、使用され得る可能なsyntaxを示すために使用される。例えば、XMLは、単純および複合データタイプを記述するためにXSDで使用されるパターンに従うことを意味し得る。XMLにおけるRDFは、クラスがXML構文を用いてRDF言語で記述されることを意味し得る(XMLに基づかない、RDFの他の統語表示も可能である)。文字列は、記述属性が、クラスを記述するいくつかの言葉のみを与えることを意味し得る。
<relationship>リソースのURIの値をとるであろう、properties属性は、随意である。クラスに関連付けられるプロパティは、複合データタイプまたは非複合データタイプであり得る。
XSDの拡張が、記述ファセットおよび単位ファセットである複合データタイプ内の各要素を解釈するように、制限/ファセットを用いて可能にされ得る。記述ファセットは、要素を認識し、要素がどのようなものであるかを理解することにおいてアプリケーションを支援する、可能なキーワードを含む、要素の簡潔な記述を与えるために使用され得る。単位ファセットは、要素の単位を規定するために使用される。以前の例1および例2の更新されたバージョンが、以下に示される。
例1A−記述および単位ファセット:
<simpleType name=“Temperature”>
<restriction>
description =“temperature in Celsius” unit=“Celsius” base=“integer”
</restriction>
</simpleType>
例2A−記述および単位ファセット:
<complexType name=“BloodPressure”>
<sequence>
<element name=“systolic” description=“systolic reading” unit=“mmHG” type=“integer”/>
<element name=“diastolic” description=“diastolic reading” unit=“mmHG” type=“integer”/>
</sequence>
</complexType>
記述/属性が、データタイプおよびその要素の名前に組み込まれ得る。データタイプ名およびデータタイプの要素の名前は、データタイプおよびその要素を解釈することに関してアプリケーションを支援する情報を含み得る。データタイプおよびその要素の名前の形式は、表6のようであり得る。結果として、以前の例1および例2の更新されたバージョンは、以下の通りである。
例1B−記述/属性をデータタイプおよびその要素の名前に組み込む:
<simpleType name=“TemperatureINCelsius”>
<restriction base=“integer”>
</restriction>
</simplType>
例2B−記述/属性をデータタイプおよびその要素の名前に組み込む:
<complexType name=“BloodPressure”>
<sequence>
<element name=“systolicINmmHG” type=“integer”/>
<element name="diastolicINmmHG” type
=“integer”/>
</sequence>
</complexType>
<relationship>のリソースツリー構造が、図30に示される。<relationship>リソースは、クラスに関連付けられることができるプロパティを定義するために使用され得る。換言すると、<class>リソースのプロパティ属性は、<relationship>リソースのリンクを含み得る。<relationship>リソースはまた、リソース・関係・値のトリプル(Relationship)の一部としてリソースのセマンティクスを定義するために使用される。表7は、<relationship>の子リソースを示す。表8は、<relationship>の属性を示す。
<term>のリソースツリー構造が、図31に示される。<term>リソースは、リソース・関係・値のトリプル(Value)の一部としてリソースのセマンティクスを定義するために使用され得る。表9は、<term>の子リソースを示す。表10は、<term>の属性を示す。
セマンティクス関連リソース能力は、例えば、oneM2Mリソース構造、<CSEBase>、<AE>、<container>、<contentInstance>等において、M2Mシステム内の正規リソースに関連付けられて結び付けられ、セマンティクス記述をこれらのリソースに提供することができる。正規リソースは、リソース、関係、および値から成る、リソース・関係・値のトリプルの集合によって記述され得る。値は、クラス、ターム、または他のリソースであり得る。これらのトリプルにおいて、リソース自体は固定されており、既知であるため、追加され得るものは、関係・値のダブルの集合等である。別のsemantics属性が、既存のsearchStrings属性を補完してセマンティクスを有効にするために使用(すなわち、追加)され得る。どのようにしてセマンティクスがoneM2Mリソース構造において<AE>および<container>リソースのために有効にされるかが、ここで議論される。
<AE>リソースに対してセマンティクスを有効にするために、rdf:typeは、<AE>リソースを、識別子およびproducedDataのプロパティを有する本明細書で定義されるような<DeviceApp>クラスに関係付ける。W3C RDFSがrdf:typeのコアプロパティをすでに定義しているため、プレフィックスのうちの1つにhttp://www.w3.org/1999/02/22−rdf−syntax−ns#を含む場合、それを外部関係のうちの1つとして使用し得る。一方、セマンティクスノードにおいてそのような類似関係を定義することに制限はない。semantics属性は、<AE>リソースのセマンティクス記述を記憶するために使用される。本実施例では、図32に示されるように、アプリケーションは、watchOfJohnSmithの識別と血圧のproducedDataとを有する腕時計である。結果として、セマンティクス属性には、複数のアイテムがある。第1のアイテムは、<watchAE>431が<DeviceApp>のタイプを有することを示す。そして<DeviceApp>クラス記述から、それに関連付けられる複数のプロパティがある。したがって、第2および第3のアイテムは、値をこれらのプロパティに割り付けるためである。
プレフィックスは、以下のように定義され得る。
@prefix relationship:<Sscl>/relationships/
@prefix class:<Sscl>/classes/
したがって、セマンティクス属性は、以下のように供給され得る。
rdf: type class/DeviceApp 433
relationship/identifier “watchOfJohnSmith” 434
relationship/producedData “blood pressure” 435
<container>リソースのセマンティクスは、そのコンテナの下の個々の<contentInstance>リソースに適用され得る。これは、類似リソースのグループのセマンティクスを記述することにおいてグループ化最適化と見なされる。
例えば、血圧監視データの複数のインスタンスが、同一のセマンティクスを有し得る。したがって、各コンテンツインスタンスは、以下に示されるように同一のセマンティクスに関連付けられ得る(BloodPressureクラスは、URI Sscl/classes/BloodPressureを用いてここで定義されている)。Ssclは、図17のssBaseと同一でもある、本明細書で議論されるようなルートの単なるもう1つの名前であることに留意されたい。
・<CSEBase1>/bpAE/<bpContainer>/<contentInstance1> rdf:type Sscl/classes/BloodPressure
・<CSEBase1>/bpAE/<bpContainer>/<contentInstance2> rdf:type Sscl/classes/BloodPressure
・<CSEBase1>/bpAE/<bpContainer>/<contentInstance3> rdf:type Sscl/classes/BloodPressure
・・・・
グループ化最適化をサポートすることによって、以下の関連付けも有効である。
・<CSEBase1>/bpAE/<bpContainer> rdf:type Sscl/classes/BloodPressure
<BloodPressure>クラスは、本明細書で定義されるようなデータタイプである、特殊な<class>リソースである。具体的には、コンテンツインスタンスは、そのコンテンツ属性に2つのフィールド、すなわち、systolicINmmHGおよびdiastolicINmmHGを有する、BloodPressureデータタイプを有する。図33に示されるような本実施例では、semantics属性は、コンテナが<BloodPressure>のタイプを有するという情報を記憶するために使用される。
実施例として、<contentInstance>は、<CSEBase1>/bpAE/<bpContainer>/<contentInstance1>のURIを有する。<BloodPressure>クラスが、定義されてSscl上に記憶され、Sscl/classes/BloodPressureのURIを有すると仮定する。図34は、AE731(例えば、腕時計710の中の血圧モニタアプリ(図示せず))によって<bpContainer>コンテナを作成する例示的メッセージフローと、どのようにしてセマンティクスがAE731によって有効にされるかとを示す。ステップ733では、AE731が、正規リソース(例えば、図33に示されるような<bpContainer>437)を作成するための要求をCSE732に送信する。ステップ734では、CSE732が、<bpContainer>437を作成し、ステップ735では、CSE732が、<bpContainer>437を作成することに関連付けられる確認をAE731に送信する。ステップ736では、AE731が、<bpContainer>に関連付けられるセマンティクス情報を提供する。この状況では、AE731は、コンテナ(<bpContainer>437)が血圧タイプを有するデータを含むというセマンティクス情報を提供する。ステップ737では、CSE732が、図33に示されるような<bpContainer>437の属性(セマンティクス属性438)の中にセマンティクス情報を保ち得る。ステップ738では、CSE732が、ステップ736のセマンティクス情報を受信することに関連付けられる確認をAE731に送信し得る。AE731は、<bpContainer>437コンテナリソースのセマンティクス属性438の値を追加する。図35は、コンテナに含まれるデータに関心がある別のアプリケーション(例えば、医師)の使用を図示する。
図35は、<contentInstance>リソースおよび血圧情報を所望し得る診療所に関連付けられ得る別のAE741によるセマンティクス読み出しプロセスの例示的メッセージフローを示す。ステップ743では、AE741が、コンテンツインスタンス(例えば、・・・/<bpContainer>/<contentInstance1>)に対する要求をCSE732に送信する。ステップ744では、CSE732が、<contentInstance>リソースをAE741に提供する。データを理解および解釈するために、アプリケーション(AE741)は、セマンティクス情報が欲しい。この場合、ステップ745では、AE741が、データ(例えば、・・・/<bpContainer>/<contentInstance1>)とともに記憶されたセマンティクス情報を読み出すように後続の要求をCSE742に送信する。ステップ746では、CSE732が、セマンティクス情報を提供する。ステップ746のセマンティクス情報は、データが、この場合、クラスリソースとして定義される、あるタイプ(例えば、type class/blood pressure 439)を有するという情報を含む。ステップ747では、AE741が、このタイプ(クラスリソース)を理解するために、Sscl742(セマンティクスノード)と通信する。AE741は、セマンティクスノードからクラスリソースの定義を読み出す。
本明細書で開示されるように、ジム使用事例に使用され得るセマンティクス関連リソースの実施例が、図36に示される。識別子関係は、オブジェクト/エンティティ、例えば、アプリケーション、データ等に対する識別子を規定する。<identifier>751関係リソースの属性(構文、検索文字列、記述)は、記述がXMLにおけるRDFSで書かれている、表11に示される。
生成されたデータ関係は、アプリケーションの生成されたデータを規定する。<producedData>752関係リソースの属性(構文、検索文字列、記述)は、記述がXMLにおけるRDFSで書かれている、表12に示される。
上記で定義される識別子751および生成されたデータ752関係は、1つのクラスを別のクラスに、1つのクラスをそのプロパティに関係付けるために使用され得る。<DeviceApp>753クラスは、使用事例に関与するアプリケーションのクラスである。<DeviceApp>753は、ここで規定され、拡張可能であるものに限定されない属性を有し得る。腕時計アプリケーション711、トレッドミルアプリケーション714、および周囲センサアプリケーション717は、<DeviceApp>753クラスのインスタンスである。<DeviceApp>753は、識別子およびproducedDataである、本明細書で定義される以下のプロパティを有する。<DeviceApp>753クラスリソースの属性(構文、検索文字列、プロパティ、nOfProperties、タイプ、および記述)は、それぞれ、記述が文字列またはXMLにおけるRDFSで書かれるときに、表13および14に示される。
(例えば、図37の<watch>761のように関連付けられる)腕時計アプリケーション711は、<DeviceApp>753クラスに定義されるプロパティを有する、<DeviceApp>753クラスのインスタンスである。腕時計アプリケーション711は、血圧データを生成することができる。
RDF:
(例えば、図38の<sensor>771のように関連付けられる)周囲センサアプリケーション717は、<DeviceApp>753クラスに定義されるプロパティを有する、<DeviceApp>753クラスのインスタンスである。周囲センサアプリケーション717は、温度データを生成することができる。
RDF:
(例えば、図38の<tredmill>775のように関連付けられる)トレッドミルアプリケーション714は、<DeviceApp>クラスに定義されるプロパティを有する、<DeviceApp>クラスのインスタンスである。トレッドミルアプリケーション714は、ユーザが終了するジムトレーニングプログラムデータを生成することができる。
RDF:
電話712上の(例えば、図37の<healthInsurance>765のように関連付けられる)健康保険アプリケーション722は、<DeviceApp>クラスに定義されるプロパティを有する、<DeviceApp>クラスのインスタンスである。健康保険アプリケーション722は、健康スコアデータを生成することができる。
RDF:
<BloodPressure>754クラスは、データタイプである。これは、フィールドsystolicINmmHGおよびdiastolicINmmHGを有する。<BloodPressure>クラスリソースの属性(構文、検索文字列、タイプ、および記述)は、記述がXMLで書かれている、表15に示される。
図36の<TemperatureInCelsius>755クラスは、データタイプである。<TemperatureInCelsius>755クラスリソースの属性(構文、検索文字列、タイプ、および記述)は、記述がXMLで書かれている、表16に示される。
<GymTrainingProgram>756クラスは、データタイプである。これは、usedEquipmentType、usedEquipmentLevel、durationINMinute、targetHeartRateINPerMinute、およびcalorieBurnINPerHourのフィールドを有する。usedEquipementTypeは、トレーニングに使用されている機器のタイプを示す。usedEquipmentLevelは、機器のどのレベルがトレーニングのために設定されたかを示す。durationINMinuteは、トレーニングが分単位でどれくらいの時間であったかを示す。heartRateINPerMinuteは、トレーニング中の毎分の平均心拍数を示す。calorieBurnINPerHourは、トレーニング中の毎時間の総カロリー燃焼を示す。<GymTrainingProgram>756クラスリソースの属性(構文、検索文字列、タイプ、および記述)は、記述がXMLで書かれている、表17に示される。
<HealthScore>757クラスは、データタイプである。その値は、本実施例では、0〜100の範囲を有する。<HealthScore>757クラスリソースの属性(構文、検索文字列、タイプ、および記述)は、記述がXMLで書かれている、表18に示される。
本明細書では、図37および38に関して、oneM2Mリソース構造が例証目的で使用される。しかしながら、ETSI M2M等の他のM2Mアーキテクチャで定義されるリソースの実施例が、非常に類似し、oneM2M実施例にも適用可能であり得る。図37および38に関する以下の議論は、図34および35に関して示されるような方法との関連で考察され得る。
実施例では、腕時計アプリケーション711が電話サービス層713(例えば、共通サービスエンティティ−CSE、またはサービス層−SL)に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。腕時計は、DeviceApp753のタイプを有する。<DeviceApp>753クラスのスキーマに従うことによって、腕時計アプリケーション711は、それが血圧データを生成し得ることを電話サービス層713に示す。電話SL713は、図37に示されるように、腕時計710のためのアプリケーションリソースを作成し得る(例えば、<watch>761)。腕時計アプリケーション711は、それが測定するデータをアップロードするために、電話SL713上にコンテナを作成する。腕時計アプリケーション711は、コンテンツインスタンスがBloodPressure754のタイプを有することを示す。この<bloodP>762コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図37に示されるように、各コンテンツインスタンスの代わりに<bloodP>762コンテナに関連付けられる。
同様に、健康保険アプリケーション722が電話SL713に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。健康保険アプリケーション722は、DeviceApp753のタイプを有する。<DeviceApp>753クラスのスキーマに従うことによって、健康保険アプリケーション722は、それが健康スコアデータを生成し得ることを電話SL713に示す。電話SL713は、図37に示されるように、健康保険アプリケーション722のためのアプリケーションリソースを作成し得る(例えば、<healthInsurance>765)。健康保険アプリケーション722は、それが計算するデータをアップロードするために、電話SL713上にコンテナを作成する。健康保険アプリケーション722は、コンテンツインスタンスがHealthScore757のタイプを有することを示す。この<healthS>767コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図37に示されるように、各コンテンツインスタンスの代わりに<healthS>767コンテナに関連付けられる。
周囲センサアプリケーション717がジムSL718に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。周囲センサ716は、DeviceApp753のタイプを有する。<DeviceApp>753クラスのスキーマに従うことによって、周囲センサ716は、それが温度データを生成することができることをジムSL718に示す。ジムSL718は、図38に示されるように、周囲センサ716のためのアプリケーションリソースを作成し得る(例えば、<sensor>771)。周囲センサアプリケーション717は、それが測定するデータをアップロードするために、ジムSL718上にコンテナを作成する。周囲センサアプリケーション717は、コンテンツインスタンスがTemperatureINCelsius755のタイプを有することを示す。この<tempReading>774コンテナの下の全てのコンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図38に示されるように、各コンテンツインスタンスの代わりに<tempReading>774コンテナに関連付けられる。
同様に、トレッドミルアプリケーション714がジムSL718に登録するとき、登録メッセージにおいてそのセマンティクスをアタッチする。トレッドミル715は、DeviceApp753のタイプを有する。<DeviceApp>753クラスのスキーマに従うことによって、トレッドミル715は、それがジムトレーニングプログラムデータを生成し得ることをジムSL718に示す。ジムSL718は、図38に示されるように、トレッドミル715のためのアプリケーションリソースを作成し得る(例えば、<treadmill>775)。トレッドミルアプリケーション714は、それが測定するデータをアップロードするために、ジムSL718上にコンテナを作成する。トレッドミルアプリケーション714は、コンテンツインスタンスがGymTrainingProgram756のタイプを有することを示す。この<GymTraining>777コンテナの下の各コンテンツインスタンスが同一のセマンティクスを有するため、セマンティクスは、図38に示されるように、各コンテンツインスタンスの代わりに<GymTraining>777コンテナに関連付けられる。
フロー図、例えば、図34−図35で図示されるステップを行うエンティティは、図39Cまたは図39Dで図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリに記憶され、それのプロセッサ上で実行されるソフトウェア(例えば、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることが理解される。つまり、例えば、図34−図35等で本明細書に図示される方法は、コンピュータデバイスのプロセッサによって実行されると、図34−図35または他の図で図示されるステップを行うコンピュータ実行可能命令である、図39Cまたは図39Dで図示されるデバイスまたはコンピュータシステム等のコンピュータデバイスのメモリに記憶されたソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る。実施例では、M2Mデバイスの相互作用に関して以下でさらに詳細に、図35のAE741が、図39AのM2M端末デバイス18上に存在し得る一方で、図35のCSE732およびSscl742は、図39AのM2Mゲートウェイデバイス14上に存在し得る。
本明細書に出現する請求項の範囲、解釈、または用途をいかようにも制限することなく、本明細書で開示される実施例のうちの1つ以上のものの技術的効果は、どのようにしてセマンティクスが管理されるかに調節を提供することである。セマンティクス情報(および関連知能)が、特殊なエンティティ(例えば、セマンティクスノード)によって取り扱われ、または記憶され得る。本明細書で開示される概念のうちの1つ以上のものの別の技術的効果としては、従来の実装と比較すると、CSEが本明細書で議論されるようなセマンティクスノードまたはセマンティクス階層をサポートする場合、セマンティクス情報がより効率的にアクセスされ、分配され、または記憶され得るように、より柔軟な方法でリソース階層が組織化されることができることである。
3GPPおよびETSI M2Mアーキテクチャが、本明細書で背景技術として説明され、本明細書に説明される主題を例証するために使用され得るが、本明細書に説明される主題の実装は、本開示の範囲内にとどまりながら変動し得ることが理解される。当業者はまた、開示された主題が上記で議論される3GPPまたはETSI M2Mアーキテクチャを使用する実装に限定されず、むしろoneM2M、メッセージキューイングテレメトリトランスポート(MQTT)、ならびに他のM2Mシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることも認識するであろう。
図39Aは、セマンティクス等の1つ以上の開示された概念が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための構成要素を提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT/WoTの構成要素ならびにIoT/WoTサービス層等であり得る。
図39Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、Ethernet(登録商標)、ファイバ、ISDN、PLC等)または無線ネットワーク(例えば、WLAN、セルラー等)、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図39Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは、通常はM2Mゲートウェイの後ろにあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ14と、端末デバイス18とを含む。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じてM2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイデバイス14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20またはM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービス層22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2Mデバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図39Bを参照すると、フィールドドメイン内の図示したM2Mサービスプラットフォーム22は、M2Mアプリケーション20、M2Mゲートウェイデバイス14、ならびにM2M端末デバイス18および通信ネットワーク12のためのサービスを提供する。M2Mサービス層22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、1つ以上のサーバ、コンピュータ等によって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示したM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’がある。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および基礎的通信ネットワーク12’のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイデバイス14およびM2M端末デバイス18のためのサービスも提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス、およびM2M端末デバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによってサービス層と相互作用し得る。M2Mサービス層22’は、1つ以上のサーバ、コンピュータ、仮想マシン(例えば、クラウド/計算/記憶ファーム等)等によって実装され得る。
図39Bも参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよび垂直線が活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
いくつかの実施例では、M2Mアプリケーション20および20’は、本明細書で議論されるように、セマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装を使用して通信する所望のアプリケーションを含み得る。M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
本願のセマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装は、サービス層の一部として実装され得る。サービス層(例えば、電話SL713またはジムゲートウェイサービス層179)は、アプリケーションプログラミングインターフェース(API)および基礎的ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。M2Mエンティティ(例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得る、デバイス、ゲートウェイ、またはサービス/プラットフォーム等のM2M機能的エンティティ)は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mは両方とも、本願のセマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装を含み得るサービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)のセットをサポートする。1つ以上の特定のタイプのCSFのセットのインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、アプリケーション特有のノード)上でホストされることができる共通サービスエンティティ(CSE)と称される。さらに、本願のセマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装は、本願のセマンティクス実装等のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用するM2Mネットワークの一部として実装されることができる。
図39Cは、M2M端末デバイス18等の例示的M2Mデバイス30の系統図である。図39Cに示されるように、M2Mデバイス30は、プロセッサ32と、送受信機34と、伝送/受信要素36と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ/タッチパッド42と、非取り外し可能メモリ44と、取り外し可能メモリ46と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。M2Mデバイス30は、開示された主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。(腕時計710、電話712、周囲センサ716、M2Mデバイス171、M2Mサーバ170、M2Mゲートウェイ172、Sscl742、AE741、CSE732、およびその他と一致する)M2Mデバイス30は、セマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装のための開示されたシステムおよび方法を使用する、デバイスであり得る。
プロセッサ32は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態機械等であり得る。プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mデバイス30が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ32は、伝送/受信要素36に連結され得る送受信機34に連結され得る。図39Cは、プロセッサ32および送受信機34を別個の構成要素として描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/または無線アクセス層(RAN)プログラムおよび/または通信を行い得る。プロセッサ32は、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー合意、および/または暗号化動作等のセキュリティ動作を行い得る。
伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送し、またはM2Mサービスプラットフォーム22から信号を受信するように構成され得る。例えば、実施形態では、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークおよびエアインターフェースをサポートし得る。実施例では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送および/または受信するように構成されるエミッタ/検出器であり得る。さらに別の実施例では、伝送/受信要素36は、RFおよび光信号の両方を伝送および受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図39Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、実施例では、M2Mデバイス30は、無線信号を伝送および受信するための2つまたはそれを上回る伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を変調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、加入者識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の実施例では、プロセッサ32は、サーバまたはホームコンピュータ上等のM2Mデバイス30上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ32は、本明細書に説明される実施例のうちのいくつかでのセマンティクス関連方法が成功しているか、または成功していないか(例えば、データタイプがセマンティクスに適合性があるかどうか、別のアプリケーションがセマンティック情報を集めるためにクエリされたか、またはクエリされる必要があろうかどうか、もしくはセマンティクスの表示)に応答して、ディスプレイまたはインジケータ42上の照明パターン、画像、もしくは色を制御するか、または別様に、セマンティクスノード、セマンティクス関連リソース、もしくはセマンティクスに関する関連実装の状態を示すように構成され得る。ディスプレイまたはインジケータ42上の制御照明パターン、画像、もしくは色は、本明細書で図示または議論される図(例えば、図1−図38)の方法フローまたは構成要素のうちのいずれかの状態を反映し得る。本明細書では、セマンティクス関連リソースのメッセージおよびプロシージャ、ならびにリソースセマンティクス情報管理が開示される。メッセージおよびプロシージャは、ユーザが、入力ソース(例えば、スピーカ/マイクロホン38、キーパッド40、またはディスプレイ/タッチパッド42)を介してリソース関連リソースを要求し、ディスプレイ42上に表示され得るものの中でもとりわけ、リソースのセマンティック情報を要求し、構成し、またはクエリするためのインターフェース/APIを提供するように拡張されることができる。
プロセッサ32は、電源48から電力を受け取り得、M2Mデバイス30内の他の構成要素への電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に電力供給するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含み得る。
プロセッサ32はまた、M2Mデバイス30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成される、GPSチップセット50に連結され得る。M2Mデバイス30は、本明細書で開示される情報と一致したままで、任意の公的な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ32はさらに、追加の特徴、機能性、および/または有線もしくは無線接続を提供する、1つ以上のソフトウェアならびに/もしくはハードウェアモジュールを含み得る他の周辺機器52に連結され得る。例えば、周辺機器52は、加速度計、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
図39Dは、例えば、図39Aおよび39BのM2Mサービスプラットフォーム22が実装され得る例示的なコンピュータシステム90のブロック図である。コンピュータシステム90(例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14)は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶もしくはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム90を稼働させるように、中央処理装置(CPU)91内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他の機械では、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たすか、またはCPU91を支援する主要CPU91とは明確に異なる、随意的なプロセッサである。CPU91および/またはコプロセッサ81は、セマンティクス関連リソースを作成または受信すること等のセマンティクスノード、セマンティクス関連リソース、またはセマンティクスに関する関連実装のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理し得る。
動作中、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送経路であるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム90内の構成要素を接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス80の実施例は、PCI(周辺構成要素相互接続)バスである。
システムバス80に連結されるメモリデバイスは、ランダムアクセスメモリ(RAM)82および読み取り専用メモリ(ROM)93を含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正することができない記憶されたデータを含む。RAM82に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られ、または変更されることができる。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理的アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供し得る。したがって、第1のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピュータシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピュータシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために必要とされる電子構成要素を含む。
さらに、コンピュータシステム90は、図39Aおよび39Bのネットワーク12等の外部通信ネットワークにコンピュータシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。
本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得ることが理解され、命令は、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等の機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行い、および/または実装する。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、それ自体が信号を含まない。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されることができ、コンピュータによってアクセスされることができる任意の他の物理的媒体を含むが、それらに限定されない。
図で図示されるような本開示の主題の好ましい方法、システム、または装置を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。例えば、セマンティクス関連リソース公表および発見の標的は兄弟および子であることが例証されるが、セマンティクスノードは、そのような関係を有していない場合がある、公表および発見のための他のセマンティクスノードを選択することができる。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。
とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン(M2M)システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データのためのセマンティクス情報を要求するための手段と、セマンティクス情報の要求に基づいて、データに関連付けられている(セマンティクス情報の実施例である)タイプを受信するための手段と、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。セマンティクス情報は、クラスリソースを備えている。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データに関連付けられているタイプが、第1のアプリケーションエンティティと適合性があるかどうかを決定するための手段を有し、データは、第2のアプリケーションエンティティからである。(ステップの除去または追加を含む)本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。
とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン(M2M)システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第1のアプリケーションエンティティによって、第2のアプリケーションエンティティに関連付けられているデータを受信するための手段と、第1のアプリケーションエンティティによって、データのためのセマンティクス情報を要求するための手段と、第1のアプリケーションエンティティによって、セマンティクス情報の要求に基づいて、データに関連付けられているタイプを受信するための手段と、第1のアプリケーションエンティティによって、データに関連付けられているタイプが、第1のアプリケーションエンティティと適合性があるかどうかを決定するための手段と、第1のアプリケーションエンティティとの適合性に基づいて、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。セマンティクス情報は、クラスリソースを備えている。第1のアプリケーションエンティティは、センサに関連付けられているアプリケーションを備えている。(ステップの除去または追加を含む)本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。
とりわけ、本明細書に説明されるような方法、システム、および装置は、マシンツーマシン(M2M)システムにおいてセマンティクスサポートを提供するセマンティクスノード機能を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データのためのセマンティクス情報を要求するための手段と、セマンティクス情報の要求に基づいて、データに関連付けられているタイプを受信するための手段と、第1のアプリケーションエンティティによって、データに関連付けられているタイプが、第1のアプリケーションエンティティと適合性があるかどうかを決定するための手段と、第1のアプリケーションエンティティとの適合性に基づいて、セマンティクスノードからタイプの定義を要求するための手段とを有する。タイプは、データに関連付けられている単位を記述するキーワードを備えている名前を有する。データに関連付けられている単位は、温度の単位または血圧の単位を備えている。セマンティクス情報は、クラスリソースを備えている。データは、セマンティクス情報とともにリソース階層において記憶される。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、データに関連付けられているタイプが、第1のアプリケーションエンティティと適合性があるかどうかを決定するための手段を有し、データは、第2のアプリケーションエンティティからである。(ステップの除去または追加を含む)本段落内の全ての組み合わせは、詳細な説明の他の部分と一致する様式で考慮される。