JP2017527016A - Ｍ２ｍオントロジ管理および意味論的相互運用性 - Google Patents

Ｍ２ｍオントロジ管理および意味論的相互運用性 Download PDF

Info

Publication number
JP2017527016A
JP2017527016A JP2017502692A JP2017502692A JP2017527016A JP 2017527016 A JP2017527016 A JP 2017527016A JP 2017502692 A JP2017502692 A JP 2017502692A JP 2017502692 A JP2017502692 A JP 2017502692A JP 2017527016 A JP2017527016 A JP 2017527016A
Authority
JP
Japan
Prior art keywords
ontology
semantic
node
semantic node
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017502692A
Other languages
English (en)
Other versions
JP6482645B2 (ja
Inventor
リージュン ドン，
リージュン ドン，
グアン ルー，
グアン ルー，
カタリーナ エム． ムラディン，
カタリーナ エム． ムラディン，
ホンクン リ，
ホンクン リ，
シュウ リ，
シュウ リ，
デール エヌ． シード，
デール エヌ． シード，
ウィリアム ロバード ザ フォース フリン，
ウィリアム ロバード ザ フォース フリン，
チョンガン ワン，
チョンガン ワン，
Original Assignee
コンヴィーダ ワイヤレス， エルエルシー
コンヴィーダ ワイヤレス， エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コンヴィーダ ワイヤレス， エルエルシー, コンヴィーダ ワイヤレス， エルエルシー filed Critical コンヴィーダ ワイヤレス， エルエルシー
Publication of JP2017527016A publication Critical patent/JP2017527016A/ja
Application granted granted Critical
Publication of JP6482645B2 publication Critical patent/JP6482645B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G06F16/367—Ontology
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/288—Entity relationship models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83—Querying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/86—Mapping to a database
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • H04L41/0286—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP] for search or classification or discovery of web services providing management functionalities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Biomedical Technology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ｍ２Ｍオントロジプロセッサは、Ｍ２Ｍドメインの外部または内部からパブリッシュされるオントロジを処理し、記憶し、または発見機能を提供することを担う。Ｍ２Ｍオントロジプロセッサは、機能的に、オントロジ処理コンポーネントと、オントロジ分類コンポーネントと、オントロジ発見コンポーネントと、オントロジレポジトリとから成ってもよい。オントロジ処理コンポーネントは、意味論情報をオブジェクト／エンティティに提供するために使用され得る、Ｍ２Ｍ名前空間の外部および内部でパブリッシュされるオントロジを処理し得る。オントロジ分類コンポーネントは、オントロジを分類し、それらを発見および使用のためのオントロジレポジトリ内の正しい階層／場所に記憶し得る。

Description

（関連出願の相互参照）
本願は、２０１４年７月１８日に出願され、“Ｍ２Ｍ ＯＮＴＯＬＯＧＹ ＭＡＮＡＧＥＭＥＮＴ ＡＮＤ ＳＥＭＡＮＴＩＣＳ ＩＮＴＥＲＯＰＥＲＡＢＩＬＩＴＹ”と題された、米国仮特許出願第６２／０２６５６９号の利益を主張するものであり、該仮出願の内容は、参照により本明細書中に援用される。
（背景）
物理的環境で展開されるネットワーク使用可能デバイスおよびセンサの数の急速な増加が、通信ネットワークを変化させている。次の１０年以内に、何十億ものデバイスが、スマートグリッド、スマートホーム、ｅ−ヘルス、自動車、輸送、物流、および環境監視等の種々の分野で、多くのアプリケーションおよびサービスプロバイダによるサービスのための無数の実環境データを生成するであろうと予測される。現在の情報ネットワーキング技術への実環境データおよびサービスの統合を可能にする関連技術および解決策は、多くの場合、モノのインターネット（ＩｏＴ）またはマシンツーマシン（Ｍ２Ｍ）通信の包括的用語の下で説明される。デバイスによって作成される大量のデータによる、このデータを識別してクエリする効率的な方法の必要性がある。
図１は、集約点としてアクチュエータを使用する小型生物医学無線センサを使用して、患者の病院またはリハビリテーションセンターによって提供され得る、例示的患者監視アプリケーションを図示する。アクチュエータは、データをネットワークに伝送する。これらの小型装着型リソース制約デバイスは、とりわけ、血圧および血流、中核体温、酸素飽和度、運動、心拍数、聴覚、および視覚等のバイタルを連続的に監視するように患者上に展開され得る、Ｍ２Ｍデバイスの実施例である。Ｍ２Ｍデバイスによって収集される種々の種類のＭ２Ｍデータは、図１で描写されるように、患者の医師、（例えば、２４時間フィットネスからの）個人トレーナ、および／または救急車サービスによって使用されてもよい。医師、個人トレーナ、および救急車サービスがこれらのＭ２Ｍデバイスから生成されたデータを使用することを可能にするために、これらのリソースの意味論も利用可能である必要がある。意味論は、データの形式および構造を理解することができるように、データの記述的定義を提供する（すなわち、意味論はデータの意味を提供する）。
Ｍ２Ｍ意味論サポートは、それらの普遍的理解／解釈だけではなく、それらの任意の高度な処理、例えば、意味論クエリ、データ分析等のオリジナルリソースに対して意味論を有効にするために意図される。背景の節で紹介されるのは、意味論ウェブにおいて開発された既存の技術と、異なる名前空間内で開発された既存のオントロジである。加えて、ｏｎｅＭ２Ｍアーキテクチャおよびサービス層も、紹介される。
意味論ウェブにおける既存の技術
意味論ウェブは、スキーマ言語とオントロジ言語の組み合わせを使用して、オントロジの能力を提供する。オントロジは、所定の指定された語彙を使用して、具体的着目エリアに関するクラスおよびそれらの間の関係またはそれ以上を定義する。ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）によって定義されるようなリソース記述フレームワークスキーマ（ＲＤＦＳ）（例えば、ＲＤＦ語彙記述言語１．０：ＲＤＦスキーマ）は、クラスおよびプロパティを定義するために使用され得る、リソース説明フレームワーク（ＲＤＦ）のための具体的語彙を提供する。ウェブオントロジ言語（ＯＷＬ）は、ウェブのためのより表現的オントロジを構築するために使用され得る付加的リソースを用いてＲＤＦＳ語彙を拡張する。
ＲＤＦは、ウェブで情報を表すためのフレームワークである。ＲＤＦは、本質的に、データモデルである。その基礎的条件的構築ブロックは、ステートメントと呼ばれる、リソース・プロパティ・値トリプルである。ＲＤＦは、ＸＭＬ、ＪＳＯＮ等で構文を与えられている。
図２は、ＲＤＦを使用し得る、意味論実施例を図示する。実施例では、ステートメント８０１は、Ｊｏｈｎ Ｓｍｉｔｈの肩書が教授であることを示し、これは、図２に示されるように、ＲＤＦ言語８０２で表され得る。ｘｍｌｎｓ：ｕｎｉ８０３は、自己定義されたドメイン名であって、プロパティ（名前および肩書）は、ＲＤＦＳの一部として定義される。ＲＤＦは、特定の使用ドメインについての仮定が実施されない、ドメイン独立型である。ＲＤＦスキーマ（ＲＤＦＳ）と呼ばれるスキーマ言語で独自のタームを定義することはユーザ次第である。ＲＤＦＳは、ＲＤＦデータモデルで使用される語彙を定義する。ＲＤＦＳでは、語彙が、定義されてもよく、オブジェクト間の関係が、記述されてもよく、プロパティが、オブジェクトがとり得る値を含み得る、特定の種類のオブジェクトに適用されるように規定されてもよい。
ウェブオントロジ言語（ＯＷＬ）は、ウェブのためのより表現的オントロジを構築するために使用され得る付加的リソースを用いて、ＲＤＦＳ語彙を拡張する。ＯＷＬは、処理、すなわち、推論をより計算上実行可能にするために、ＲＤＦドキュメントの構造およびコンテンツに関する付加的制限を導入する。例えば、ＯＷＬは、標準的セットの演算子、すなわち、共通集合、和集合、および補集合に対応するプロパティを定義し、クラスのブール結合を定義する。図３は、共通集合を使用して、概念「父親」を定義する実施例を図示する。「父親」は、正にクラス「親」および「男性」の共通集合である。言い換えると、「父親」である人は誰でも、「親」かつ「男性」の両方であって、「親」かつ「男性」の両方である人は誰でも、「父親」である。一見すると、ＯＷＬでは、「Ｆａｔｈｅｒ ｉｓ ｒｄｆｓ：ｓｕｂＣｌａｓｓＯｆ Ｐａｒｅｎｔ」および「Ｆａｔｈｅｒ ｉｓ ｒｄｆｓ：ｓｕｂｃｌａｓｓＯｆ Ｍａｌｅ」と言うことは同等であると考えられ得る。しかしながら、これらの２つのｓｕｂＣｌａｓｓＯｆ ｓｔａｔｅｍｅｎｔｓは、全「父親」が「親」かつ「男性」であるはずであるということを述べているにすぎない。それらは、ｏｗｌ：ｉｎｔｅｒｓｅｃｔｉｏｎＯｆを使用して行われ得るように、その性別および親であるということから、ある人が「父親」であると推測するために使用されることはできない。
ＯＷＬは、ＲＤＦおよびＲＤＦＳ、ＸＭＬスキーマデータタイプ、ならびにＯＷＬ名前空間を使用する。ＯＷＬ語彙自体は、名前空間ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／０７／ｏｗｌ＃内に定義され、一般に、プレフィックスｏｗｌによって参照される。データタイプは、ＵＲＩを使用して識別されるデータ値の範囲を表す。ＯＷＬは、いくつかの所定のデータタイプを使用することを可能にし、その大部分は、ＸＭＬスキーマ定義（ＸＳＤ）名前空間内に定義される。ＯＷＬは、ユーザが、ＸＳＤを拡張することによって、その独自のデータタイプを定義することを可能にする。図４および図５は両方とも、ＸＳＤ内にデータタイプを定義する実施例を図示する。
異なる名前空間からの既存のオントロジ
開発および共有されている、多くのオントロジが存在する。それらは、拡張および再使用の基礎を提供することができる。また、狭い範囲の着目エリアの詳細表現を提供する、いくつかのオントロジも存在する。本種類のオントロジを用いても、必ずしも、拡張されず、むしろ、単に、直接使用される、または一般化される。以下は、Ｍ２Ｍシステムに非常に関連する、そのような種類のオントロジのいくつかの実施例である。
Ｆｒｉｅｎｄ ｏｆ ａ Ｆｒｉｅｎｄ（ＦＯＡＦ）（フレンド・オブ・ア・フレンド）プロジェクトは、ワールドワイドウェブ上の友人についての共有情報に関連する情報を表す、ＦＯＡＦオントロジを維持する。オントロジは、個人情報、電子メールアドレス、オンラインアカウント、およびインスタントメッセージング情報、ならびにオンラインドキュメントおよび画像を捕捉するためのクラスおよびプロパティを含有する。ＦＯＡＦプロジェクトの目標は、ウェブ上の種々のコミュニティを分割する壁を破壊するために、アプリケーション独立およびウェブサイト独立様式でユーザのオンラインライフを捕捉するための手段を提供することである。個人のために定義された共通プロパティ（ｆｏａｆ：Ｐｅｒｓｏｎ）の実施例は、とりわけ、ｆｏａｆ：ｎａｍｅ、ｆｏａｆ：ｔｉｔｌｅ、ｆｏａｆ：ｈｏｍｅｐａｇｅ、ｆｏａｆ：ｉｎｔｅｒｅｓｔ、およびｆｏａｆ：ｔｏｐｉｃ＿ｉｎｔｅｒｅｓｔを含む。
意味論センサネットワーク（ＳＳＮ）オントロジが、Ｗ３Ｃ意味論センサネットワークインキュベータグループ（ＳＳＮ−ＸＧ）によって開発されている。ＳＳＮオントロジは、センサおよび観察ならびに関連概念を記述する。ＳＳＮオントロジモデルは、センサ、観察、着目特徴、感知のプロセス（例えば、センサの動作および観察方法）、センサがプラットフォームに展開される、または取り付けられる方法、センサの測定能力、ならびにその環境および特定の環境におけるセンサの耐久特性等、センサまたはその観察の特定の側面を表すために使用され得る、クラスおよびプロパティを含有する。クラスの実施例は、とりわけ、ｓｓｎ：Ｓｅｎｓｏｒ、ｓｓｎ：ＳｅｎｓｏｒＩｎｐｕｔ、およびｓｓｎ：ＳｅｎｓｏｒＯｕｔｐｕｔを含み得る。プロパティの実施例は、とりわけ、ｓｓｎ：ｈａｓＭｅａｓｕｒｅｍｅｎｔＣａｐａｂｉｌｉｔｙ、ｓｓｎ：ｏｂｓｅｒｖａｔｉｏｎＳａｍｐｌｉｎｇＴｉｍｅ、およびｓｓｎ：ｑｕａｌｉｔｙＯｆＯｂｓｅｒｖａｔｉｏｎを含み得る。ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００５／Ｉｎｃｕｂａｔｏｒ／ｓｓｎ／ＸＧＲ−ｓｓｎ−２０１１０６２８／ｉｍａｇｅｓ／ＯｎｔＳｔｒｕｃｔｕｒｅ−Ｏｖｅｒｖｉｅｗ．ｊｐｇ（参照することによってその全体として組み込まれる）を参照されたい。
ＩＥＥＥ１１０７３（ＩＳＯ／ＩＥＥＥ１１０７３、健康情報学−医療／健康デバイス通信規格）個人用健康データ（ＰＨＤ）規格は、体重計、血圧モニタ、血液グルコースモニタ、および同等物等の個人用健康デバイスの相互運用性に対処する規格群である。
ＩＥＥＥ１１０７３−２０６０１（ＩＥＥＥ１１０７３−２０６０１、健康情報学−−個人用健康デバイス通信−−パート２０６０１：アプリケーションプロファイル−−最適化交換プロトコル）は、一般的データタイプ、メッセージタイプ、および通信モデルを定義する、フレームワーク規格である。これは、その特定のタイプの個人用健康デバイスのためのデータモデルのみを定義する必要がある、任意の数の（比較的に少数の）「デバイス特殊化」規格（体重計のためのＩＥＥＥ１１０７３−１０４１５規格等）をサポートする。
ＩＥＥＥ１１０７３−２０６０１は、医療デバイスシステム（ＭＤＳ）およびメトリッククラス等のクラスを定義する。ＭＤＳに関して、各エージェントは、１つのＭＤＳオブジェクトを有し、これは、それを識別し、そのステータスを報告する。ＭＤＳオブジェクトの属性は、それをマネージャに対して識別し、時間およびステータスを表し、他の情報を提供する。ＭＤＳは、したがって、ゼロまたはそれを上回る以下のクラスによって表されるオブジェクトのうちのいくつかを含有する。メトリッククラスは、測定、ステータス、およびコンテキストデータを表すあらゆるオブジェクトのためのベースクラスであって、これはまた、多くのサブクラスを有し、例えば、数値は、単一測定を表し得る。
図６は、実践的実施例を図示しており、体重計のドメイン情報モデルが、ＩＥＥＥ１１０７３−１０４１５によって定義される。図６は、全ての体重計が、体重に関する１つの要求される数値オブジェクトと、身長および肥満度指数に関する２つの随意の数値オブジェクトとを含有することを示す。
図７は、別の実践的実施例を図示しており、血圧モニタのドメイン情報モデルが、ＩＥＥＥ１１０７３−１０４０７によって定義される。これは、全ての血圧が、２つの数値オブジェクト、すなわち、収縮期、拡張期、および平均動脈圧（ＭＡＰ）に関する１つの必須複合数値オブジェクトと、脈拍数に関する１つの随意の数値オブジェクトとを含有することを示す。
ｏｎｅＭ２Ｍサービス層
開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ−ＴＳ−０００１ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−０．６．１）は、図８に図示されるような「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層は、ｅ−ヘルス、保有車両管理、およびスマートホーム等の異なる「バーティカル」Ｍ２Ｍサイロシステムおよびアプリケーションによって利用され得る、「ホリゾンタル」サービスを提供する。ＣＳＥは、４つの基準点Ｍｃａ、Ｍｃｃ、Ｍｃｃ’、およびＭｃｎをサポートする。Ｍｃａ基準点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ基準点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’基準点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ基準点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、場所サービス、およびデバイストリガリング等の下層ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびレポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含有する。図９は、ｏｎｅＭ２ＭのためのＣＳＦを図示する。
ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、ミドルノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）を有効にする。ＡＳＮは、１つのＣＳＥを含有し、少なくとも１つのＡＥを含有する、ノードである。物理的マッピングの実施例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含有し、ＣＳＥを含有しない、ノードである。物理的マッピングの実施例は、制約付きＭ２Ｍデバイス内に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含有し、ゼロまたはそれを上回るＡＥを含有する、ノードである。ＭＮのための物理的マッピングの実施例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。ＩＮは、１つのＣＳＥを含有し、ゼロまたはそれを上回るＡＥを含有する、ノードである。ＩＮのための物理的マッピングの実施例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。
（サービスコンポーネントアーキテクチャ、ＴＳ−０００７サービスコンポーネントアーキテクチャ−Ｖ−０．２．０）に説明されるＭ２Ｍサービスアーキテクチャは、Ｍ２ＭアプリケーションおよびＭ２Ｍサービスプロバイダに提供されるＭ２Ｍサービスを規定することによって、ｏｎｅＭ２Ｍ機能アーキテクチャを拡張させる。図１０に示されるコンポーネントは、サービスエクスポージャコンポーネント、ネットワークサービス利用コンポーネント、および遠隔サービスエクスポージャコンポーネントである。サービスエクスポージャコンポーネントは、サービスをＡＥにエクスポージャする。ネットワークサービス利用コンポーネントは、ＮＳＥからサービスを消費する。そして、遠隔サービスエクスポージャコンポーネントは、異なるＭ２Ｍ環境からのサービスを接続する。
前述のように、Ｍ２Ｍシステムによって再使用され得る、いくつかの既存の共通基本オントロジが存在する。Ｍ２Ｍシステムが、それらの共通基本オントロジを再定義する場合、効果的ではない場合があり、これはまた、既存の基本オントロジを再使用しない場合、Ｍ２Ｍシステムと他のシステムとの間の相互運用性も低減させる。例えば、本明細書により詳細に論じられる使用例では、ジム内で展開されるデバイスである、ジムメンバーの意味論を記述するために、Ｍ２Ｍシステムは、人物を記述するためのオントロジ、センサ、または血圧モニタを記述するためのオントロジ等、対応するオントロジを有する必要があり得る。ＦＯＡＦオントロジ、ＳＳＮオントロジ、ＩＥＥＥ１１０７３個人用健康データモデル等の既存の基本のものを使用しない場合、Ｍ２Ｍシステムは、それらのオントロジを再定義し得る。それらのオントロジは、再定義される場合、既存のものと相互運用不可能であり得ることが可能性として考えられ、これは、Ｍ２Ｍシステムおよび他のシステムが相互に理解することを妨害する。
Ｍ２Ｍシステムはまた、あるバーティカルによって定義されたオントロジが、Ｍ２Ｍサービス層を通して他のバーティカルによって共有および使用され得るように、異なるバーティカルからのオントロジを組み込む必要があり得る。既存のＭ２Ｍシステムは、オントロジ管理のサポートを欠いている。問題として、以下の問題が挙げられる。第１の問題は、他のシステムを用いてＭ２Ｍシステムをモデル化することができる、高レベルオントロジが存在しないことである。そのようなオントロジは、オントロジ共有および再使用の観点から、Ｍ２Ｍシステムが他のシステムと相互作用する方法を理解するために必要とされる。第２の問題は、Ｍ２Ｍシステムが、Ｍ２Ｍシステムによって記憶、発見、および再使用され得るように、Ｍ２Ｍシステムの外部の異なる名前空間からドメイン特有のオントロジを組み込み得る方法の機構が欠如していることである。第３の問題は、Ｍ２Ｍシステムが、Ｍ２Ｍシステムの内部の異なるバーティカルからのオントロジを組み込み得る方法の機構が欠如していることである。第４の問題は、Ｍ２Ｍシステムにパブリッシュされるオントロジが、オントロジ発見を促進するように効率的に記憶され得る方法の機構が欠如していることである。
本明細書に開示されるのは、Ｍ２Ｍドメインの外部または内部のいずれかからパブリッシュされるオントロジの処理、記憶、または発見機能を提供することを担う、Ｍ２Ｍオントロジプロセッサ（ＭＯＰ）である。ＭＯＰは、機能的に、オントロジ処理コンポーネント（ＯＰＣ）と、オントロジ分類コンポーネント（ＯＣＣ）と、オントロジ発見コンポーネント（ＯＤＣ）と、オントロジレポジトリ（ＯＲ）とから成ってもよい。ＯＰＣは、Ｍ２Ｍ名前空間の外部および内部でパブリッシュされたオントロジを処理し得、これは、意味論情報をオブジェクト／エンティティに提供するために使用され得る。ＯＣＣは、オントロジを分類し、それらを発見および使用のためのオントロジレポジトリ内の正しい階層／場所に記憶し得る。ＯＤＣは、オントロジ発見を提供し、使用する要求側のための合致するものを判定し得る。ＯＲは、Ｍ２Ｍドメインの外部および内部にパブリッシュまたは生成される任意のオントロジモデルを記憶し得る。それらのオントロジは、リソースが意味論を有効にするために使用されてもよい。したがって、ＯＲは、ＯＣＣおよびＯＤＣの両方と相互作用し得る。
ＭＯＰ機能性はまた、Ｍ２Ｍ以外の他の名前空間／システムにも適用可能であり得る。例えば、Ｗ３Ｃはまた、Ｍ２Ｍ名前空間からパブリッシュされるオントロジを処理、分類、および記憶するためのＭＯＰ機能性を採用し得る。
開示されるのは、Ｍ２Ｍ高レベルオントロジモデルおよびＭＯＰのｏｎｅＭ２Ｍ実施例ならびにＯＲのリソースツリー実施例である。本開示はまた、複数のオントロジの意味論注釈使用を促進し、かつ推論を促進する、オントロジリソース内のクラスおよび関係のｏｎｅＭ２Ｍ実施例について議論する。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、患者監視アプリケーションを図示する。 図２は、意味論実施例を図示する。 図３は、ｏｗｌ：ｉｎｔｅｒｓｅｃｔｉｏｎの実施例を図示する。 図４は、ＸＳＤ内のデータタイプを定義する実施例を図示する。 図５は、ＸＳＤ内のデータタイプを定義する実施例を図示する。 図６は、ＩＥＥＥ１１０７３−１０４１５によって定義された体重計の例示的ドメイン情報モデルを図示する。 図７は、ＩＥＥＥ１１０７３−１０４０７によって定義された血圧モニタの例示的ドメイン情報モデルを図示する。 図８は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図９は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図１０は、例示的ｏｎｅＭ２Ｍサービスアーキテクチャを図示する。 図１１は、ジムにおける例示的Ｍ２Ｍ使用例を図示する。 図１２は、オントロジ管理を実装し得る、例示的システムを図示する。 図１３は、例示的Ｍ２Ｍオントロジプロセッサを図示する。 図１４は、オントロジ処理ユニットのための例示的方法を図示する。 図１５は、オントロジメッセージをパブリッシュするための例示的メッセージフローを図示する。 図１６は、ＯＷＬ内の例示的オントロジテンプレートを図示する。 図１７は、ＯＰＣがオントロジを互換性のあるフォーマットにコンバートするための例示的方法を図示する。 図１８は、概念マッピング参照の例示的メッセージフローを図示する。 図１９は、オントロジ分類コンポーネントの機能性の例示的概要を図示する。 図２０は、オントロジレポジトリのための例示的構造アーキテクチャを図示する。 図２１は、オントロジレポジトリ内に記憶されたリソースの例示的階層を図示する。 図２２は、非Ｍ２Ｍ名前空間のためのオントロジレポジトリ内に記憶された例示的リソースを図示する。 図２３は、Ｍ２Ｍ名前空間のためのオントロジレポジトリ内に記憶された例示的リソースを図示する。 図２４は、オントロジ発見コンポーネントの例示的機能アーキテクチャを図示する。 図２５は、オントロジ発見のための例示的メッセージフローを図示する。 図２６は、例示的ｏｎｅＭ２Ｍオントロジ管理能力サービス機能を図示する。 図２７は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ内のオントロジ管理のための例示的実装アーキテクチャを図示する。 図２８は、オントロジレポジトリの例示的リソースツリー構造を図示する。 図２９は、そのオントロジを別の外部名前空間にパブリッシュするためにｏｎｅＭ２Ｍ実装によって使用される例示的メッセージ交換を図示する。 図３０は、例示的高レベルオントロジモデルを図示する。 図３１は、Ｍ２Ｍ高レベルオントロジの例示的ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲＯＡ）を図示する。 図３２は、ｏｎｅＭ２Ｍ名前空間内の例示的抽象化を図示する。 図３３は、ｏｎｅＭ２Ｍ名前空間内の例示的抽象化を図示する。 図３４は、Ｍ２Ｍ意味論サポートのための例示的機能アーキテクチャを図示する。 図３５は、ＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図３６は、意味論ノードを伴うＭ２Ｍアーキテクチャを図示する。 図３７は、Ｍ２Ｍ意味論ノードアーキテクチャを図示する。 図３８Ａは、意味論ノード階層を確立するための方法の一実施例を図示する、流れ図である。 図３８Ｂは、図３８Ａにおけるステップをより詳細に図示する。 図３９は、意味論ノード登録のメッセージフローを図示する。 図４０は、子によって開始される親子関係更新を図示する。 図４１は、意味論関連リソース発見を処理するフロー図を図示する。 図４２は、ＲＥＳＴｆｕｌ意味論ノード動作のメッセージフローを図示する。 図４３は、意味論関連リソース発見、読み出し、および妥当性確認プロセスのメッセージフローを図示する。 図４４は、同胞／親／子意味論ノードによって記憶および管理される意味論関連リソースを用いて更新され得る、意味論ノードのフロー図を図示する。 図４５は、同一の意味論を伴うリソースのグループ化のフロー図を図示する。 図４６は、意味論関連リソースプッシュ配信を図示する。 図４７は、デバイスが１つのエリアネットワークから別のエリアネットワークに移動するシナリオを図示する。 図４８は、データ／意味論関連リソース移動のメッセージフローを図示する。 図４９は、独立型意味論ノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図５０は、意味論ノードリソース構造を図示する。 図５１は、ＳＳｓリソース構造を図示する。 図５２は、統合意味論ノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャを図示する。 図５３は、ｘＳＣＬリソース構造を図示する。 図５４は、＜ｓｃｌ１＞上の意味論関連リソース構造を図示する。 図５５は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ意味論を図示する。 図５６は、リソースおよび意味論読み出しのメッセージフローを図示する。 図５７は、独立型意味論ノードを伴う３ＧＰＰ ＭＴＣアーキテクチャを図示する。 図５８は、独立型意味論ノードを伴う３ＧＰＰ ＭＴＣアーキテクチャを図示する。 図５９は、本明細書で説明されるような意味論ノードの使用の一実施例の説明図を提供する。 図６０Ａは、１つまたはそれを上回る開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図６０Ｂは、図６０Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図６０Ｃは、図６０Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図６０Ｄは、図６０Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。 図６１は、Ｍ２Ｍオントロジ管理および意味論的相互運用性を利用するための例示的グラフィカルユーザインターフェースである。 図６２は、例示的意味論センサネットワークオントロジを図示する。 図６３は、例示的ｏｎｅＭ２Ｍ Ｂａｓｅオントロジを図示する。 図６４は、例示的＜ｏｎｔｏｌｏｇｙ＞リソース構造を図示する。 図６５は、例示的＜ｏｎｔｏｌｏｇｙ＞リソース構造を図示する。 図６６は、＜ｃｌａｓｓ＞の例示的リソース構造を図示する。 図６７は、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞の例示的リソース構造を図示する。 図６８は、ｏｎｅＭ２Ｍベースオントロジへの例示的＜ｏｎｔｏｌｏｇｙ＞リソースマッピングを図示する。 図６９は、例示的＜ｏｎｔｏｌｏｇｙ＞リソース構造を図示する。 図７０は、他のリソースによって使用される方法を介してサブスクライブされ得る、例示的＜ｏｎｔｏｌｏｇｙ＞リソースを図示する。
マシンツーマシン（Ｍ２Ｍ）システムは、意味論関連リソースを格納する、意味論ノードを含み得る。Ｍ２Ｍシステムの意味論関連リソースは、専有オントロジのセットに基づき得る。しかし、Ｍ２Ｍシステムによって再使用され得る、多くの既存の共通基本オントロジが存在する。専有オントロジへの依拠は、Ｍ２Ｍシステムの他のシステムとの相互運用性に影響を及ぼし得る。Ｍ２Ｍシステムが、Ｆｒｉｅｎｄ ｏｆ ａ Ｆｒｉｅｎｄ（ＦＯＡＦ）または意味論センサネットワーク（ＳＳＮ）オントロジ等のすでに存在するオントロジを使用することは、より効率的であり得る。Ｍ２Ｍシステム内にはまた、ｅ−ヘルス、保有車両管理、またはスマートホーム等の異なるバーティカルが存在し得る。Ｍ２Ｍシステム内のこれらのバーティカルは、異なるオントロジを同様に有し得る。本明細書に開示されるのは、オントロジの管理および相互運用性に対処するためのオントロジプロセッサおよび他の機構である。オントロジプロセッサは、例えば、Ｍ２Ｍシステムの１つまたはそれを上回る意味論ノード上に常駐してもよい。
意味論ノードとともに常駐し得る、オントロジプロセッサに関する背景を与えるために、意味論ノードアーキテクチャの簡潔な概要が以下で提示される。意味論ノードアーキテクチャに関するさらなる詳細は、図３５−図５９に対応する説明で提供される。これらは、ＥＴＳＩの状況における実施例であるが、他のアーキテクチャの状況でも検討され得る。
従来のマシンツーマシン（Ｍ２Ｍ）システムでは、（エンドデバイスならびにバックエンドネットワークサーバ上でホストされる）Ｍ２Ｍアプリケーションは、交換されたデータの共通定義について事前に合意する必要がある。これは、主に、アプリケーションの代わりにＭ２Ｍデータを解析、解釈、または処理することができる、意味認識Ｍ２Ｍサービス層の欠如によるものである。現在のＭ２Ｍシステムでは、Ｍ２Ｍサービス層は、意味認識能力が欠けており、したがって、Ｍ２Ｍサービス層を通って流動する、またはＭ２Ｍサービス層内に記憶されるデータは、不透明な情報として扱われる。
この意味認識の欠如は、たとえデータが起源であったアプリケーションのいかなる予備知識がなくても、異なるアプリケーションによって発見、アクセス、解釈、および共有することができるように、Ｍ２Ｍアプリケーションによって生成されるデータがＭ２Ｍサービス層によって効果的に抽象化または仮想化されることを可能にするサービスを、Ｍ２Ｍサービス層が提供することを妨げる。結果として、感知および作用される物理的エンティティ（例えば、アプライアンス、人、車、建築物の部屋等）は、Ｍ２Ｍサービス層によって効果的に仮想化／抽象化されない場合があり、物理的エンティティは、環境に固有であり、特定のＭ２Ｍアプリケーションに関係しない一般的エンティティとして扱われる。この制限を克服するために、Ｍ２Ｍシステムにおいて伝送されるデータは、意味認識Ｍ２Ｍサービス層がＭ２Ｍアプリケーションと同一のデータの知識を有することができるように、意味情報と関連付けられ、統合され得る。そうすることで、Ｍ２Ｍサービス層は、アプリケーションにわたるデータの共有をより良好に促進し、付加価値のある意味認識サービスをＭ２Ｍアプリケーションに提供することができる（例えば、データ集約、異なるアプリケーション間のデータ共有等）。
例えば、図１で図示される患者監視アプリケーションでは、患者のバイタル（例えば、血圧、温度、酸素、心拍数等）を監視する無線センサデバイスのそれぞれの上でホストされる、別個のアプリケーションがあり得る。同様に、この情報を利用することができる、ネットワーク内でホストされる別個のアプリケーション（例えば、患者の医師、個人トレーナ、家族、救急車の救急医療隊員等と関連付けられたアプリケーション）があり得る。しかしながら、無線センサデバイスのそれぞれからのＭ２Ｍ意味認識サービスデータがないと、ネットワークアプリケーションが、無線センサデバイス上でホストされるアプリケーションの予備知識、およびそれらが生成する情報のタイプ（例えば、場所／アドレス、データの単位、データのコンテキスト等）を有しない限り、ネットワークアプリケーションは、デバイスアプリケーションから情報を発見、共有、および理解することに困難を有し得る。
意味論ノードは、Ｍ２Ｍサービス層意味認識およびデータ抽象化をサポートするように、Ｍ２Ｍシステムにおいて以下の機能、すなわち、（ｉ）リソースに関連する意味情報を記憶するためのサポート、および／またはリソースに関連する意味情報を記憶するサーバへのインターフェースのためのサポート、（ｉｉ）リソースに関連する意味情報を作成、読み出し、更新、および削除するための機構のためのサポート、（ｉｉｉ）リソースに関連する意味情報をパブリッシュおよび発見するための能力を提供し得る。
本明細書で説明されるように、意味論ノードは、ネットワーク内の独立型コンピュータデバイス（例えば、サーバ）上でホストされ得るか、またはＭ２Ｍゲートウェイ、Ｍ２Ｍデバイス、Ｍ２Ｍサーバ、あるいは同等物等のネットワーク内の既存のエンティティ上でホストされ得る、論理エンティティである。意味論ノードは、意味論関連リソースモデル化を記憶するレポジトリと見なされてもよい。例えば、血圧用のセンサデバイスは、どのようにしてそのデータを記述するかを理解することを希望し得るため、すでに定義された血圧クラスがあるかどうかを解明するように近くの意味論ノードにクエリを実施する。もしそうであれば、意味論ノードは、それがローカルで見出した血圧クラスでセンサデバイスに応答する。もしそうでなければ、意味論ノードは、他の意味論ノード（例えば、同胞または親）にクエリを実施してもよい。意味論ノードの使用は、エンドデバイスにデータのモデルを記憶させる必要を低減させ得る。
意味論ノードは、意味論関連リソースを記憶して管理する。意味論関連リソースは、通常、それらの意味論の理解を可能にするためにそれらと関連付けられる意味論関連リソースを有する必要がある、例えば、リソースツリーの下に記憶されるＥＴＳＩ Ｍ２Ｍリソース、すなわち、＜ＳＣＬ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞等の他のリソースを記述する。一実施例では、意味論関連リソースは、３つのタイプ、すなわち、クラス、関係、およびタームのうちの１つを有してもよい。このカテゴリ化は、意味論ウェブの現在の技法との互換性を提供し、Ｍ２Ｍシステムが既存の意味論関連リソースを活用することを可能にする。本明細書では、ＥＴＳＩおよびｏｎｅＭ２Ｍベースの実施例の混合が存在する。当業者は、ＥＴＳＩおよびｏｎｅＭ２Ｍが類似リソースツリー構造を有し、いずれにおいても、本明細書の概念に依拠可能であるはずであることを理解可能となるであろう。
本明細書で議論されるように、意味論ノードは、異なるレベルが階層構造に形成されるように、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍアクセスネットワーク、およびＭ２Ｍコアネットワーク等の異なるレベルでＭ２Ｍシステムに展開されてもよい。同一のレベルでの意味論ノードは、分配され、同胞関係を有してもよい。異なるレベルの抽象化および互換性の利益を既存のネットワーク階層に提供する、意味論ノードのそのようなハイブリッドアーキテクチャを構築して維持することに関して、機構が開示される。
図１１−図３４ならびにそれらの付随する説明は、以下に説明されるオントロジ管理のための方法、デバイス、およびシステムに関連する意味論ノードアーキテクチャおよびプラットフォームの実施例のさらなる情報および理解を提供する。本明細書に開示されるのは、Ｍ２Ｍドメインの外部または内部のいずれかからパブリッシュされるオントロジへの処理、記憶、または発見機能を提供することを担う、Ｍ２Ｍオントロジプロセッサ（ＭＯＰ）である。
本明細書（例えば、図１２−図３４等）に図示されるステップを実施するエンティティは、図６０Ｃまたは図６０Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る、論理エンティティであることを理解されたい。すなわち、図１２−図３４等に図示される方法は、図６０Ｃまたは図６０Ｄに図示されるデバイスまたはコンピュータシステム等のコンピューティングデバイスのメモリ内に記憶される、ソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装されてもよく、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図１２−図３４等に図示されるステップを実施する。Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴う実施例では、図２５の要求側７７１は、図６０ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１３のＭＯＰ７２１またはサーバ７２９は、図６０ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。
付加的観点のために、図１１は、オントロジ管理に関するジム使用例を図示する。図１１に示されるように、ジムは、周囲温度／湿度を感知するための周囲センサ７０６、トレッドミル７０３、体重計７０２、および血圧モニタ７０１等、その顧客のために展開される複数の異なるデバイスを有し得る。デバイス（例えば、アプリケーションリソース）に関連するリソースならびにデバイスによって生成および報告されるデータリソースは、リソースデータベース内に記憶され得る。
意味論を図１１のデバイスおよびその測定されるデータならびにジムメンバーに提供するために、種々のオントロジが、必要とされる。各オントロジは、異なるタイプのデバイスならびに測定されるデータ毎に意味論情報を記述するために使用されてもよい。ＭＯＰは、ゲートウェイ７０４内に常駐してもよい。ＭＯＰにパブリッシュされ得、ジム内のエンティティの意味論を記述するために活用および使用され得る、外部オントロジが存在する。例えば、ＦＯＡＦ、ＳＳＮ、およびＩＥＥＥ１１０７３−１０４１５が、表３から表６に関してより詳細に論じられるように、メッセージをパブリッシュすることによって、Ｍ２Ｍ名前空間にパブリッシュされてもよい。その結果、ＭＯＰは、外部オントロジを処理、記憶、発見、および別様にその使用を補助し得る。
図１１を継続して参照すると、ＭＯＰは、Ｍ２Ｍシステムによって採用され得る、統一言語でパブリッシュされたオントロジを記憶してもよい。言語は、意味論ウェブからのＲＤＦＳ／ＯＷＬであってもよい。実施例の簡略化された例証のために、Ｍ２Ｍシステムは、パブリッシュされたオントロジを記述する際、ＲＤＦＳ／ＯＷＬを使用すると仮定する。Ｍ２Ｍシステムはまた、他の言語を採用する、またはその独自の言語を開発してもよい。提案されるＭ２Ｍ高レベルオントロジモデルならびにＭＯＰの機能性は、独立型であって、Ｍ２Ｍシステムによって使用される具体的オントロジ言語に依存しない。殆どの場合、Ｍ２Ｍシステムは、Ｍ２Ｍドメインの外部またはＭ２Ｍドメインの内部であり得る、概念（オントロジ）の階層として知識を表し、共有語彙を使用して、それらの概念のクラス、プロパティ、および相互関係を示し得る。これは、以下により詳細に論じられる。
図１２は、オントロジ管理を実装し得る、例示的システム７２０を図示する。Ｍ２Ｍ名前空間７３５および非Ｍ２Ｍ名前空間７３８等、複数の名前空間がシステム７２０内に存在し得る。非Ｍ２Ｍ名前空間７３８は、サーバ７２９上に位置し得る、１つまたはそれを上回るオントロジを含む。図１２に示されるように、Ｍ２Ｍ名前空間７３５（例えば、ｏｎｅＭ２Ｍ名前空間）は、ノード７３７、ノード７２８、およびノード７３６等の意味論ノードであり得る、複数のＭ２Ｍノードを含む。ノード７２８およびノード７３７は、ノード７３６と通信可能に接続されてもよく、ノード７３６は、ＭＯＰ７２１を含む。ノード７２８は、ｅ−ヘルスを含む、Ｍ２Ｍバーティカルを含んでもよい。ノード７３７は、スマートホームを含む、Ｍ２Ｍバーティカルを含んでもよい。ノード７３７およびノード７２８も同様に、複数の他のＭ２Ｍバーティカルを有してもよい。ノード７３６はまた、非Ｍ２Ｍ名前空間７３８内に位置する、サーバ７２９と通信可能に接続されてもよい。
図１３は、ＭＯＰ７２１の実施例を図示する。ＭＯＰ７２１は、機能的に、オントロジ処理コンポーネント（ＯＰＣ）７２６と、オントロジ分類コンポーネント（ＯＣＣ）７２４と、オントロジ発見コンポーネント（ＯＤＣ）７２３と、オントロジレポジトリ（ＯＲ）７２７とから成ってもよい。ＯＰＣ７２６は、意味論情報をオブジェクト／エンティティに提供するために使用され得る、Ｍ２Ｍ名前空間の外部および内部のパブリッシュされたオントロジを処理してもよい。処理されたオントロジは、ＯＣＣ７２４に入力され、発見および使用のために、正しい階層内に適切に記憶される。ＯＣＣ７２４は、オントロジを分類し、発見および使用のために、ＯＲ内の正しい階層／場所内に記憶してもよい。ＯＤＣ７２３は、オントロジ発見を提供し、要求側が使用するための合致するものを判定してもよい。ＯＲ７２７は、Ｍ２Ｍドメインの外部および内部でパブリッシュまたは生成される、任意のオントロジモデルを記憶してもよい。それらのオントロジは、リソースが意味論を有効にするために使用されてもよい。したがって、ＯＲ７２７は、ＯＣＣ７２４およびＯＤＣ７２３の両方と相互作用し得る。ＯＲは、論理エンティティ意味論ノードの一部と見なされ得る。ＭＯＰ７２１機能性はまた、Ｍ２Ｍ以外の他の名前空間／システムにも適用可能であり得る。例えば、Ｗ３Ｃはまた、Ｍ２Ｍ名前空間からパブリッシュされるオントロジを処理、分類、および記憶するために、ＭＯＰ機能性を採用してもよい。
図１４は、ＭＯＰ７２１のＯＰＣ７２６に関する例示的方法７３０を図示する。ステップ７３１において、ＯＰＣは、オントロジを受信する。受信されたオントロジメッセージ（すなわち、オントロジパブリッシングメッセージ）は、パブリッシュされると、以下により詳細に論じられる、特定のフォーマットを有し得る。オントロジは、外部名前空間（非Ｍ２Ｍ名前空間７３８）または内部名前空間（例えば、Ｍ２Ｍ名前空間７３５）からのものであってもよい。ステップ７３２において、ＯＰＣ７２６は、受信されたオントロジの互換性を判定する。ＯＰＣ７２６は、オントロジ表現がＭ２Ｍ名前空間内で使用されるものと同一フォーマットを有するかどうかを識別する。例えば、Ｍ２Ｍ名前空間内部の全オントロジがＯＷＬによって表される場合、他のフォーマットで表されるそれらのオントロジは、Ｍ２Ｍ名前空間と互換性がないと見なされる。ステップ７３３において、ＯＰＣ７２６は、互換性のないオントロジを互換性のあるフォーマットにコンバートする。
オントロジパブリッシングメッセージは、名前空間、名前、互換性、アクセス権、トピック、関連性、またはオントロジ表現等の表１に要約されるような１つまたはそれを上回るフィールドを含んでもよい。表１のフィールドは、外部名前空間（例えば、非Ｍ２Ｍ名前空間７３８）と関連付けられた、またはＯＰＣ７２６にパブリッシュされるそのオントロジを有する、Ｍ２Ｍバーティカル（例えば、ノード７２８およびノード７３７上のＭ２Ｍバーティカルｅ−ヘルスおよびスマートホーム）と関連付けられたメッセージのために使用されてもよい。パブリッシュされたオントロジは、ＯＰＣ７２６への以前にパブリッシュされたオントロジの更新であってもよい。
表１を参照すると、名前空間フィールドは、パブリッシュされたオントロジの名前空間を示す。名前フィールドは、パブリッシュされたオントロジの名前を示す。互換性フィールドは、オントロジパブリッシングメッセージ本文内に含有されるオントロジ表現が、Ｍ２Ｍ名前空間（例えば、Ｍ２Ｍ名前空間７３５）を有するＭ２Ｍシステム７３５によって選定されるオントロジ表現と互換性があるかどうかを示す。オントロジ管理に関して本明細書で論じられる実施例を単純化するために、Ｍ２Ｍシステム７２１は、図１２に示されるように、Ｍ２Ｍ名前空間７３５によって同等に包含されると仮定される。Ｍ２Ｍシステム７３９は、１つを上回る互換性のあるフォーマットをサポートすることが可能である。本フィールドは、パブリッシャ（サーバ７２９）がＭＯＰ７２１と事前にそのオントロジ表現の互換性をチェックしなかった場合、空欄のまま残され得る。そうでなければ、サーバ７２９は、本明細書により詳細に論じられるように、本フィールドを適切なコンテンツで埋め得る。
表１を継続して参照すると、アクセス権は、オントロジが他の当事者およびエンティティによってアクセスされ得る方法を示す。アクセス権は、オントロジパブリッシャとの異なる関係を伴う異なる当事者（例えば、個人、事業体、政府、または他の当事者）に対して異なり得る。アクセス権フィールドは、表２のように現れ得る。サブフィールド「動作」は、ＲＯ（読取専用）、ＲＷ（読取および書込）等の許可された動作を示す。サブフィールド「当事者」は、パブリッシュされたオントロジに動作を行うことが許可された対応する当事者／複数の当事者を示し、一般（例えば、全ての当事者は、それに関する動作を有することができる）、パブリッシャとある関係を伴う当事者、個々の当事者等であり得る。表２は、いくつかの実施例を示しており、全ての一般当事者がパブリッシュされたオントロジへの読取アクセスを有することが可能である一方、パブリッシャ（パブリッシャは、別のアプリケーションであり得る）と同一所有者を伴うアプリケーションのみ、パブリッシュされたオントロジへの読取および書込アクセスを有することができる。
表１をさらに参照すると、トピックは、オントロジが関連するトピックを指定する。トピックフィールドは、１つまたはそれを上回るキーワードを含有し、オントロジを記述してもよい。例えば、ＦＯＡＦオントロジがパブリッシュされるとき、トピックフィールドは、「人物」であり得る。トピックは、全名前空間によって理解される、周知の／一般に使用される語彙に由来し得、同様に標準化され得る。本フィールドはまた、空欄のまま残され得、したがって、ＯＣＣ７２４は、以下により詳細に論じられる、パブリッシュされたオントロジに関する関連トピックを決定し得る。関連性は、表１に示されるように、パブリッシュされたオントロジが他のオントロジと任意の関連性を有するかどうかを示す。例えば、パブリッシュされたオントロジは、ＯＲ７２７内に記憶された既存のオントロジから拡張または改訂されてもよい。例えば、ＦｏＡＦオントロジは、すでに定義されたもの以外の人物のより多くの属性を含むように拡張されてもよい。オントロジ表現は、表１に示されるように、パブリッシュされたオントロジの表現を含有する。いくつかのインスタンスでは、パブリッシャは、オントロジのＵＲＩのみをパブリッシュし得る。オントロジ表現が非Ｍ２Ｍ準拠フォーマットにある場合、オントロジのスキーマが含まれ得る。
簡単に前述されたように、オントロジは、外部名前空間（非Ｍ２Ｍ名前空間）または内部名前空間（例えば、ｏｎｅＭ２Ｍ名前空間）からのものであってもよい。図１４のステップ７３１と併せて、図１３および図１２を参照すると、ＯＰＣ７２６は、サーバ７２９等の１つまたはそれを上回る非Ｍ２Ｍ名前空間をホストし得る、１つまたはそれを上回るサーバからオントロジを受信してもよい。サーバ７２９は、非Ｍ２Ｍ名前空間７３８のオントロジをＭＯＰ７２１に先を見越してパブリッシュしてもよい。ＭＯＰ７２１はまた、更新された非Ｍ２Ｍ名前空間オントロジをサーバ７２９から要求してもよい。ＭＯＰ７２１からの要求は、とりわけ、時間、ユーザアクション（例えば、ユーザ入力コマンド）等のイベントに基づいてもよい。サーバ７２９またはその上の名前空間は、ＦＯＡＦ、ＳＳＮ、ＩＥＥＥ、大学、事業体、私人、政府、または他のエンティティ等の１つまたはそれを上回る権限保有機関によって統轄されてもよい。
図１４のステップ７３１と併せて図１３および図１２を継続して参照すると、ＯＰＣ７２６はまた、ＭＯＰ７２１のＭ２Ｍ名前空間７３５と関連付けられた１つまたはそれを上回るバーティカルを有する、ノード７２８およびノード７３７等の１つまたはそれを上回るＭ２Ｍノードからオントロジを受信してもよい。バーティカルの実施例は、とりわけ、ｅ−ヘルス（ノード７２８）、保有車両管理、およびスマートホーム（ノード７３７）を含む。ノード７２８およびノード７３７は、オントロジをＭＯＰ７２１に先を見越してパブリッシュしてもよい。ＭＯＰ７２１はまた、更新されたＭ２Ｍバーティカルオントロジをノード７２８およびノード７３７から要求してもよい。要求は、とりわけ、時間、ユーザアクション（例えば、ユーザ入力コマンド）等のイベントに基づいてもよい。ノード７２８、ノード７３７、またはノード７２８およびノード７３７のホストされたバーティカルは、ＦＯＡＦ、ＳＳＮ、ＩＥＥＥ、大学、事業体、私人、政府、または他のエンティティ等の１つまたはそれを上回る権限保有機関によって統轄されてもよい。
図１５は、オントロジメッセージをパブリッシュするための例示的メッセージフローを図示する。図１５のメッセージフローは、外部名前空間（例えば、非Ｍ２Ｍ名前空間７３８）または内部名前空間（例えば、Ｍ２Ｍ名前空間７３５）に適用可能であり得る。便宜上、パブリッシャ７４１は、図１５に示されるように、外部または内部名前空間を表すであろう。ステップ７４２において、パブリッシャ７４１は、Ｍ２Ｍシステム７３９によって採用されたオントロジ表現フォーマットにクエリしてもよい。必須要件は、パブリッシャが、Ｍ２Ｍシステム７３９のオントロジレポジトリ内のそのオリジナルオントロジを表すために、Ｍ２Ｍシステムによって使用されるスキーマ（例えば、ＲＤＦＳ／ＯＷＬ）を理解することであり得る。例えば、ｏｎｅＭ２Ｍ（本明細書により詳細に論じられる）では、クエリは、図２８における＜ＯＲ＞リソースのフォーマット属性を読み出すことを標的化することであり得る。代替として、ステップ７４２に関して、随意に、パブリッシャ７４１は、それが所望するオントロジの表現の互換性をチェックし、ＭＯＰ７２１を用いてパブリッシュすることを選定することができる。本メッセージは、オントロジパブリッシングメッセージと別個のメッセージであってもよい。パブリッシャ７４１は、オントロジをメッセージ内に表す際にそれが使用するフォーマットを入力してもよい。ＭＯＰは、受信されたフォーマットがそれが採用しているものであるかどうかを判定してもよい。また、対応する応答メッセージ（「はい」または「いいえ」）が、パブリッシャ７４１に返される。Ｍ２Ｍシステム７３９が使用するフォーマットは、応答メッセージに添付され、パブリッシャにこれについて知らせてもよい。
図１５を継続して参照すると、ステップ７４３において、ステップ７４２においてパブリッシャから送信される情報に基づいて、ＭＯＰは、Ｍ２Ｍシステム７３９によって採用される互換性結果またはフォーマット（オントロジテンプレートであり得る）を返してもよい。オントロジテンプレートは、比較的に単純である、図１６に示されるようなオントロジであってもよい。ステップ７４４において、パブリッシャ７４１は、ＭＯＰ７２１からのフィードバックに基づいて、パブリッシュされるであろうオントロジを互換性のあるフォーマットにコンバートすることを選定してもよい。必須要件は、パブリッシャ７４１が、ＲＤＦＳ／ＯＷＬでそのオリジナルオントロジを表すためのＲＤＦＳ／ＯＷＬスキーマを理解することであり得る。ＭＯＰ７２１は、オントロジを処理し、Ｍ２Ｍシステム７３９によって採用されるオントロジをフォーマットにコンバートしてもよい。随意に、パブリッシャ７４１はまた、直接、オリジナルオントロジをその独自のフォーマットでパブリッシュしてもよい。ＭＯＰ７２１によるコンバートは、本明細書により詳細に論じられるように、表８に示されるような概念名マッピングテーブルに基づいてもよい。図１５は、パブリッシャ７４１がオントロジを互換性のあるフォーマットにコンバートするシナリオを示す。
図１５をさらに参照すると、ステップ７４４において、パブリッシャ７４１は、表１のフィールドを含有し得る、パブリッシングメッセージを作成する。例証目的のために、表３から表７は、異なるオントロジのフィールド内に含有され得るものを示す。
表３は、ＦＯＡＦオントロジを用いたＦＯＡＦ＿プロジェクト名前空間からのものであり得る、パブリッシングメッセージを示す。名前空間フィールドは、「ＦＯＡＦ＿Ｐｒｏｊｅｃｔ：ｈｔｔｐ：／／ｘｍｌｎｓ．ｃｏｍ／ｆｏａｆ／０．１／」に設定される。名前フィールドは、「ＦＯＡＦ」に設定される。ＦＯＡＦオントロジもまた、ＲＤＦ／ＯＷＬで書き込まれ、したがって、互換性フィールドは、「Ｙ」に設定される。アクセス権は、「一般」に設定される（ＦＯＡＦは、一般に公開される）。トピックフィールドは、「人物」に設定される。オントロジ表現のＵＲＬは、メッセージ本文内に含有され、そこから、ＭＯＰ７２１は、オントロジをダウンロードし、得ることが可能である。
表４は、ＳＳＮオントロジを用いたＳＳＮ＿Ｐｒｏｊｅｃｔ名前空間からのパブリッシングメッセージを示す。名前空間フィールドは、「ＳＳＮ＿Ｐｒｏｊｅｃｔ：ｈｔｔｐ：／／ｐｕｒｌ．ｏｃｌｃ．ｏｒｇ／ＮＥＴ／ｓｓｎｘ／ｓｓｎ」に設定される。名前フィールドは、「ＳＳＮ」に設定される。ＳＳＮオントロジもまた、ＲＤＦ／ＯＷＬで書き込まれており、したがって、互換性フィールドは、「Ｙ」に設定される。アクセス権は、「一般」に設定される（ＳＳＮは、一般に公開される）。トピックフィールドは、「センサ」に設定される。オントロジ表現のＵＲＬは、メッセージ本文内に含有され、そこから、ＭＯＰ７２１は、オントロジをダウンロードし、得ることが可能である。
表５は、体重計のデータオントロジのＩＥＥＥ１１０７３名前空間からのパブリッシングメッセージを示す。名前空間フィールドは、「ＩＥＥＥ１１０７３」に設定される。名前は、「ｓｃａｌｅ：ＩＥＥＥ１１０７３−１０４１５」に設定される。パブリッシャは、ＲＤＦ／ＯＷＬと異なるスキーマにおいてオントロジをパブリッシュする。したがって、互換性フィールドは、「Ｎ」に設定される。ＯＰＣ７２６は、オントロジを互換性のあるフォーマットにコンバートすることを担う必要がある。結果として生じるオントロジは、表９に関して以下により詳細に論じられる。アクセス権は、「ＩＥＥＥメンバー」に設定される（ＩＥＥＥメンバーのみ、ＩＥＥＥ１１０７３−１０４１５の仕様にアクセス可能である）。後に、要求側が本オントロジへのアクセスを所望する場合、ＭＯＰ７２１は、ＩＥＥＥエンドポイントまたはアプリケーションとチェックを行い、要求側の会員資格を有効にする必要がある。トピックフィールドは、「健康」に設定される。オントロジ表現は、メッセージ本文内に含有され、オントロジのスキーマに続き、各フィールドの値を含有する。
表６は、血圧モニタのデータオントロジのＩＥＥＥ１１０７３名前空間からのパブリッシングメッセージを示す。名前空間フィールドは、「ＩＥＥＥ１１０７３」に設定される。名前は、「ＢＰＭｏｎｉｔｏｒ：ＩＥＥＥ１１０７３−１０４０７」に設定される。パブリッシャは、Ｍ２Ｍシステム７３９が採用する互換性のあるフォーマットでオントロジをパブリッシュする。したがって、互換性フィールドは、「Ｙ」に設定される。アクセス権は、「ＩＥＥＥメンバー」に設定される（ＩＥＥＥメンバーのみ、ＩＥＥＥ１１０７３−１０４０７の仕様にアクセス可能である）。トピックフィールドは、「健康」に設定される。オントロジ表現は、メッセージ本文内に含有され、これは、ＸＳＤ内で使用されるパターンに従って、単純および複雑なデータタイプを記述する。
表７は、血圧（ＢＰ）オントロジのＭ２Ｍバーティカル（例えば、ｅ−ヘルス）からのパブリッシングメッセージを示す。名前空間フィールドは、「Ｍ２Ｍ」に設定される。互換性フィールドは、バーティカルが、オントロジを表す際、Ｍ２Ｍ準拠フォーマットに従うため、「Ｙ」に設定される。トピックフィールドは、空欄のまま残される。オントロジ表現は、メッセージ本文内に含有され、ＸＳＤ内で使用されるパターンに従って、単純および複雑なデータタイプを記述する。
図１５をさらに参照すると、ステップ７４６において、ＭＯＰ７２１のＯＰＣ７２６は、パブリッシュされたオントロジを処理し、ＯＣＣ７２４は、以下により詳細に論じられる、ＯＲ７２７内の正しい階層にオントロジを記憶し得る。ステップ７４７において、ステップ７４６におけるパブリッシュされたオントロジの処理および記憶の成功後、ＭＯＰ７２１は、記憶されたオントロジのＵＲＩをパブリッシャ７４１に返してもよい。
上記で簡単に論じられたように、フォーマットと互換性がないＭ２Ｍドメインで表されるオントロジ（例えば、表５）に関して、ＯＰＣ７２６は、オントロジを互換性のあるフォーマットにコンバートしてもよい。例えば、Ｍ２Ｍ名前空間内部の全オントロジが、ＯＷＬによって表される場合、他のフォーマットで表されるそれらのオントロジは、Ｍ２Ｍ名前空間内で互換性がないと見なされる。図１７は、ＯＰＣ７２６がオントロジを互換性のあるフォーマットにコンバートする例示的方法を図示する。ステップ７５１において、ＯＰＣ７２６は、オントロジのスキーマに続いて、各フィールドの値を含有する、オントロジパブリッシングメッセージのメッセージ本文を読み取る。ステップ７５２において、ＯＰＣ７２６は、スキーマに基づいて、各フィールドを解析することが可能である。オントロジは、具体的着目エリアのためのものであり得る、クラスおよび関係を定義するためのタームの所定の指定された語彙である。Ｍ２Ｍ名前空間７３５の外部または内部からの各オントロジは、通常、２つの概念、すなわち、クラスおよび関係から成る。ＯＰＣ７２６は、Ｍ２Ｍ名前空間７３５および他の名前空間によって使用され得る、概念名前間の可能性として考えられるマッピングを維持する。ＲＤＦ／ＯＷＬでは、対応する概念名前は、クラスおよびプロパティならびにｘｓｄ：ｃｏｍｐｌｅｘｔｙｐｅ／ｘｓｄ：ｓｉｍｐｌｅｔｙｐｅおよびｘｓｄ：ｅｌｅｍｅｎｔである。ステップ７５２において、ＯＰＣ７２６は、概念マッピング提案を作成する。表８は、概念名前間の例示的マッピングを示す。本マッピングテーブルは、ＭＯＰ７２１によって、漸増的かつ動的に維持されてもよく、これは、新しいマッピングが、ＭＯＰ７２１によって学習および追加され得ることを意味する。ＭＯＰ７２１が、対応するマッピングを見つけることが不可能である、故に、パブリッシュされたオントロジを理解不可能である、新しい概念名前に遭遇すると、可能性として考えられるマッピングを提案し、パブリッシャと協議してもよい。パブリッシャは、マッピングを確認するか、または新しいものを提案するかのいずれかであることができる。図１８は、概念マッピング参照のメッセージフローを図示する。
図１８を参照すると、ステップ７５５において、ＭＯＰ７２１は、提案されるマッピングならびにＭ２Ｍ名前空間７３５からの概念名前の意味を含有する、概念マッピング提案をオントロジパブリッシャ７４１に送信する。Ｍ２Ｍ名前空間はまた、Ｍ２Ｍドメインとも呼ばれ得ることに留意されたい。ステップ７５６において、パブリッシャ７４１は、受信された概念名前とその独自の名前の意味を比較し、概念マッピング合致を決定する。ステップ７５７において、パブリッシャ７４１は、ＭＯＰ７２１に、概念マッピング提案に合意する確認応答を送信する。ステップ７５８において、ＭＯＰ７２１は、例えば、表８に類似する、概念名前マッピングテーブルにマッピングをローカルで記憶する。表８は、新しい概念名前マッピング（下線）がテーブルに追加されることを示す。マッピングに基づいて、ＯＰＣは、パブリッシュされたオントロジを互換性のあるフォーマットにコンバートすることが可能である。例えば、表５は、パブリッシュされたオントロジを異なるフォーマットで示す。ＯＰＣは、ｄａｔａＭｏｄｅｌをｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅにマップし、ｅｌｅｍｅｎｔをｘｓｄ：ｅｌｅｍｅｎｔにマップする。その結果、パブリッシュされたオントロジは、表９に示されるような表現にコンバートされることができる。
図１９は、オントロジ分類コンポーネントの機能性の要約を図示する。ＯＣＣ７２４は、ＯＰＣ７２６の出力である、Ｍ２Ｍ準拠オントロジを容認する。
ＯＣＣ７２４は、オントロジを分類し、それを記憶するための正しい階層を特定する。分類は、オントロジが非Ｍ２Ｍ名前空間（例えば、非Ｍ２Ｍ名前空間７３８）またはＭ２Ｍ名前空間（例えば、Ｍ２Ｍ名前空間７３５）に属するかどうか、それが属する名前空間、それが属するトピック等を決定することを含む。ＯＣＣ７２４は、パブリッシュされたオントロジを解釈し、オントロジの基礎的条件を抽出する。基礎的条件は、オントロジ内に含有される、クラスおよびプロパティを含む。クラスおよびプロパティはそれぞれ、Ｍ２Ｍシステムの中に組み込まれることができ、オントロジレポジトリ（ＯＲ）７２７内に記憶されるであろう。
ＯＲ７２７は、オントロジを発見を単純化し得る構造内に記憶する。例示的構造アーキテクチャは、図２０に示される。ＯＲ７２７は、Ｍ２Ｍ名前空間７３５の外部および内部からパブリッシュされるオントロジを区別し、したがって、論理的に、２つの部分、すなわち、非Ｍ２Ｍ名前空間およびＭ２Ｍ名前空間から成る。非Ｍ２Ｍ名前空間のためのＯＲ７２７は、アーキテクチャ上、３つのレベルを有する。すなわち、第１のレベルは、上記の実施例におけるように、ＦＯＡＦ＿Ｐｒｏｊｅｃｔ，ＳＳＮ＿Ｐｒｏｊｅｃｔ，ＩＥＥＥ１１０７３であり得る、個々の名前空間である。第２のレベルは、各個々の名前空間下でオントロジを含有してもよい。第３のレベルは、オントロジ内に定義されたクラス、関係、およびタームを含む、各個々のオントロジの基礎的条件を含有してもよい。
図２０を継続して参照すると、Ｍ２Ｍ名前空間のためのＯＲ７２７も、アーキテクチャ上、３つのレベルを有し得る。第１のレベルは、パブリッシュされたオントロジが関連し得る可能性として考えられるキーワードである、個々のトピック、例えば、人物（人物の記述に関連するオントロジを含有する）、器具（任意の種類の器具の記述に関連するオントロジを含有する）である。第２のレベルは、各個々のトピックに関連するオントロジまたは仮想オントロジを含有してもよい。仮想オントロジは、非Ｍ２Ｍ名前空間からパブリッシュされたトピックに関連するそれらのオントロジである。実際のオントロジ表現は、仮想オントロジ下に記憶されず、代わりに、非Ｍ２Ｍオントロジ階層のためのＯＲ７２７内に記憶された実際のオントロジへのリンクを有する。第３のレベルは、オントロジ内に定義されたクラス、関係、およびタームを含む、各個々のオントロジの基礎的条件を含有してもよい。ＯＲ７２７内に記憶されたリソースの詳細な階層は、図２１に示される。
以下の議論は、表３−表７に関して説明されるパブリッシュされたオントロジの実施例のうちの１つまたはそれを上回るものを使用して、ＯＣＣ７２４の処理、ＯＲ７２７内への記憶、およびＯＲ７２７の各レベル内の対応するコンテンツについて議論する。図２２は、非Ｍ２Ｍ名前空間７３８のためにＯＲ７２７内に記憶された例示的リソースを図示する。表３に示されるメッセージ内にパブリッシュされたオントロジに関して、ｒｄｆ／ｘｍｌファイル内のオントロジが、ＯＰＣ７２６によって、メッセージ本文内に含有されるリンクからダウンロードされた。ＯＣＣ７２４は、オントロジをＦＯＡＦ＿Ｐｒｏｊｅｃｔと称される新しい名前空間下に記憶する。ＯＣＣ７２４はまた、オントロジ内に定義されたクラスおよびプロパティを抽出し、対応して、それらをクラスおよび関係サブレベル下に記憶する。その間に、ＯＣＣ７２４は、新しいトピック「人物」を作成し、実際のオントロジのリンクを仮想オントロジのものとして本トピック下に記憶する。
図２２を継続して参照すると、表４に示されるメッセージ内にパブリッシュされたオントロジに関して、ＯＷＬファイル内のオントロジが、ＯＰＣ７２６によって、メッセージ本文内に含有されるリンクからダウンロードされた。ＯＣＣ７２４は、オントロジをＳＳＮ＿Ｐｒｏｊｅｃｔと称される名前空間下に記憶する。ＯＣＣ７２４はまた、オントロジ内に定義されたクラスおよびプロパティを抽出し、対応して、クラスおよび関係サブレベル下に記憶する。その間に、ＯＣＣ７２４は、新しいトピック「センサ」を作成し、実際のオントロジのリンクを仮想オントロジのものとして本トピック下に記憶する。
図２２を継続して参照すると、表５および表９に示されるメッセージ内にパブリッシュされたオントロジに関して、ＯＣＣ７２４は、オントロジをＩＥＥＥ１１０７３と称される新しい名前空間下に記憶する。ＯＣＣ７２４はまた、オントロジ内に定義されたクラスを抽出し、それらをクラスサブレベル下に記憶する。その間に、ＯＣＣ７２４は、新しいトピック「健康」を作成し、実際のオントロジのリンクを仮想オントロジとして本トピック下に記憶する。図２３は、空間考慮のため、図２１と異なって描写されていることに留意されたい。
図２３を参照すると、表７に示されるメッセージ内にパブリッシュされたオントロジに関して、ＯＣＣ７２４は、オントロジをＭ２Ｍ名前空間下に記憶する。パブリッシングメッセージ内のトピックフィールドは、空欄のまま残されているため、ＯＣＣ７２４は、既存のもの「健康」である、本オントロジのための関連トピックを決定してもよい。オントロジは、１つを上回るトピックに関連してもよく、オントロジ表現は、１回記憶されてもよく、そのリンクは、他の異なるトピックにおいて対応する仮想オントロジ下に記憶されてもよいことに留意されたい。楕円７６３、楕円７６４、楕円７６５、および楕円７６６に参照されるオントロジは、実際のオントロジであって、オリジナルオントロジのＵＲＩを含有する。楕円７６７は、実際のオントロジである。
図２４は、ＯＤＣの例示的機能アーキテクチャを図示する。オントロジ発見コンポーネント（ＯＤＣ）７２３は、Ｍ２Ｍアプリケーション（例えば、ｏｎｅＭ２ＭにおけるＡＥ）等の任意のエンティティからの発見要求を容認し、発見要求を分析し、合致するトピックをＭ２Ｍ名前空間７３５のためのＯＲ７２７から見つけ、合致するトピックを検索し、要求される合致するオントロジまたは基礎的条件を要求側に返す。本明細書におけるＯＤＣ議論は、意味論関連リソースの発見、読み出しおよび妥当性確認プロセスに関して論じられるものに類似するが、調節されたリソース階層を伴う。
発見要求メッセージにおける例示的フィールドおよび説明は、要求タイプ、検索キー、または応答タイプを含んでもよい。表１０は、フィールドの要約を示す。要求タイプは、オントロジ全体またはオントロジ内部の基礎的条件であり得る、要求側が検索しているものを示す。したがって、本フィールドの可能性として考えられる値は、オントロジ、クラス、関係であり得る。検索キーは、要求側によって送信される検索キーを含む。オントロジはまた、図３４における意味論レポジトリによって維持される、その独自の意味論（例えば、それらが属する名前空間またはトピック）を有してもよく、その結果、オントロジ発見は、図３４における意味論クエリプロセッサを通して行われてもよいことに留意されたい。応答タイプは、合致する結果のＵＲＩまたは合致する結果のＵＲＩおよび表現であり得る、要求側が所望する応答を示す。
図２５は、オントロジ発見のための例示的メッセージフローを図示する。ステップ７７２において、要求側７７１（例えば、Ｍ２Ｍアプリケーション、例えば、別のジム内の別の血圧モニタアプリケーション）が、発見要求をＭＯＰ７２１に送信する。要求タイプは、「クラス」に設定され、検索キーは、「健康」および「血圧」および「ＢＰ」に設定され、要求側が血圧をモデル化するクラスの発見に関心があることを示す。応答タイプは、「ＵＲＩ」に設定され、要求側が合致するクラスのＵＲＩのみを必要とすることを意味する。要求側は、発見されたオントロジを使用して、それ自体またはその測定されるデータ等の意味論情報を記述してもよい。
ステップ７７３において、ＭＯＰ７２１のＯＤＣ７２３は、要求を分析し、Ｍ２Ｍ名前空間７３５のためのＯＲ７２７をトピックレベルで検索する。ＯＤＣ７２３は、可能性として考えられる合致するトピックが「健康」であることを見出す。ＯＤＣ７２３はさらに、「健康」トピック下でオントロジを検索し、２つの合致するオントロジを見出す。１つは、オリジナルオントロジのＵＲＩ：Ｎｏｎ−Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ／ＩＥＥＥ１１０７３／１１４０７／を含有する仮想のものである。もう１つは、Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ／ｈｅａｌｔｈ／ｂｌｏｏｄＰｒｅｓｓｕｒｅ／のＵＲＩを伴うものである。ＯＤＣ７２３は、最終的に、２つの合致するクラスを２つのオントロジ下で見つけ、ステップ７７４において、それらのＵＲＩを要求側７７１に返す。ステップ７７５において、要求側７７１は、２つのオントロジの表現を読み出し、それらのいずれかがそのデータを記述するために好適であるかどうかを確認してもよい。要求側７７１はまた、その独自のデータに好適になるように既存のものいずれかを拡張させてもよい。例えば、表６は、ＩＥＥＥ１１０７３−１０４０７によってパブリッシュされたオントロジを示し、４つの要素を有する。表７は、Ｍ２Ｍバーティカルによってパブリッシュされたオントロジを示し、２つの要素を有する。クライアントは、記述される必要がある２つの要素のみを有する、データを有してもよい。したがって、表７におけるオントロジは、好適なオントロジとなるであろう。
図１１と関連付けられたジム使用例を参照すると、異なるデバイス、例えば、周囲温度／湿度等を感知するための周囲センサ、体重計、およびジムユーザがそのバイタルを記録するための血圧モニタが展開され得る。デバイス（例えば、アプリケーションリソース）に関連するリソースならびにデバイスによって生成および報告されるデータリソースは、リソースデータベース内に記憶されてもよい。
意味論をそれらのデバイスおよびその測定されるデータに提供するために、各デバイスは、その独自の要件を満たすオントロジを発見し、それを使用する必要があり得る。一方、ジムのメンバーもまた、そのプロファイルおよび相互の関係を記述するためにオントロジを必要とする。以下は、ＯＲ７２７によって維持されるパブリッシュされたオントロジが、Ｍ２Ｍ名前空間によって再び再作成される必要がないように、ジム使用例において発見および使用され得る方法を示す。
ジムメンバー７０７（以降、ジムメンバー）の電話は、オントロジを見つけ、そのプロファイルおよび他者との関係を記述するために、発見要求（メッセージ内にクラス、人物、ＵＲＩを含有する）をＭＯＰ７２１に送信してもよく、ＭＯＰは、「人物」トピック下のＦＯＡＦオントロジを本要求に合致させ、オントロジのＵＲＩをジムメンバー７０７に返してもよい。それを使用するために、ジムメンバー７０７は、ＵＲＩを標的化することによって、オントロジ表現をＯＲ７２７から読み出す。
周囲センサ７０６のアプリケーションは、オントロジを見つけ、その測定されるデータを記述するために、発見要求（メッセージ内にクラス、人物、ＵＲＩを含有する）をＭＯＰ７２１に送信してもよく、ＭＯＰ７２１は、「センサ」トピック下のＳＳＮオントロジを本要求に合致させ、オントロジのＵＲＩをセンサに返してもよい。それを使用するために、周囲センサ７０６は、ＵＲＩを標的化することによって、オントロジ表現をＯＲ７２７から読み出す。周囲センサ７０６は、リソース制約デバイスであるため、ＳＳＮオントロジの全体的表現を処理する能力を有していない場合があることに留意されたい。周囲センサ７０６はさらに、オントロジの基礎的条件をＵＲＩから発見し、それが必要とするもの（例えば、ｓｓｎ：ＳｅｎｓｏｒＯｕｔｐｕｔ）のみを読み出してもよい。
血圧モニタ７０１のアプリケーションは、オントロジを見つけ、その測定されるデータを記述するために、発見要求（メッセージ内にクラス、健康；血圧、ＵＲＩを含有する）をＭＯＰ７２１に送信してもよく、ＭＯＰ７２１は、「健康」トピック下の２つのオントロジを本要求に合致させ、オントロジのＵＲＩを血圧モニタ７０１のアプリケーションに返してもよい。それらのうちの１つを使用するために、血圧モニタ７０１のアプリケーションは、ＵＲＩを標的化することによって、オントロジ表現をＯＲ７２７から読み出す。
体重計７０２のアプリケーションは、オントロジを見つけ、その測定されるデータを記述するために、発見要求（メッセージ内にクラス、健康；体重計、ＵＲＩを含有する）をＭＯＰ７２１に送信してもよく、ＭＯＰ７２１は、「健康」トピック下のオントロジを本要求に合致させ、オントロジのＵＲＩを体重計７０２のアプリケーションに返してもよい。それを使用するために、体重計７０２のアプリケーションは、ＵＲＩを標的化することによって、オントロジ表現をＯＲ７２７から読み出す。周囲センサ７０６、ジムメンバー７０７、血圧モニタ７０１のアプリケーション、および体重計７０２のアプリケーション等のデバイスのうちの１つは、ＯＲ７２７から発見および読み出されるオントロジで充足されない場合がある可能性がある。デバイスは、その要件に従ってオントロジを拡張または修正してもよい。
以下は、ｏｎｅＭ２Ｍに適用可能であり得る、特定の実施例の議論である。ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）のセットを備える、共通サービスエンティティ（ＣＳＥ）としてインスタンス化される。一実施例では、ＭＯＰ７２１は、図２６に示されるように、ｏｎｅＭ２Ｍ ＣＳＦとしてＣＳＥ内にホストされてもよい。別の実施例として、ＭＯＰ７２１は、論じられるように、意味論ノードの一部であってもよい（また、ｏｎｅＭ２Ｍ ＣＳＦでもあり得る）。
任意のｏｎｅＭ２Ｍバーティカル、すなわち、ＡＥは、Ｍｃａ基準点を介して、オントロジ管理ＣＳＦにトークし、そのオントロジをパブリッシュする、もしくは既存のオントロジを発見してもよい、または他のＣＳＥは、Ｍｃｃ／Ｍｃｃ’基準点を介して、オントロジ管理ＣＳＦにトークし、そのオントロジをパブリッシュする、もしくは既存のオントロジを発見してもよい。ｏｎｅＭ２Ｍ名前空間の外部からのパブリッシャは、Ｍｃｃ’基準点を介して、オントロジ管理ＣＳＦにトークし、そのオントロジをパブリッシュしてもよい。その結果、ＭＯＰに関して本明細書で論じられる対応するメッセージおよび提案されるプロシージャは、Ｍｃａ、Ｍｃｃ、およびＭｃｃ’基準点に適用されるであろう。
図２７もまた、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（サービスコンポーネントアーキテクチャ、ＴＳ−０００７サービスコンポーネントアーキテクチャ−Ｖ−０．２．０）におけるオントロジ管理の例示的実装アーキテクチャを示す。ｏｎｅＭ２Ｍバーティカル、すなわち、ＡＥは、Ｍｃａ基準点を介して、オントロジ管理サービスコンポーネントにトークし、そのオントロジをパブリッシュする、もしくは既存のオントロジを発見してもよい。ｏｎｅＭ２Ｍ名前空間の外部からのパブリッシャは、新しい基準点Ｍｃｃ／Ｍｃｃ’を介して、オントロジ管理サービスコンポーネントにトークし、そのオントロジをパブリッシュしてもよい。前述の節に提案されるメッセージおよびプロシージャは、それらの基準点に適用される。
オントロジレポジトリ（ＯＲ）の例示的ｏｎｅＭ２Ｍベースのリソースツリー構造が、図２８に示され、これは、２つのサブリソース、すなわち、＜Ｎｏｎ−Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ＞および＜Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ＞を有する。＜ＯＲ＞のフォーマット属性は、ｏｎｅＭ２Ｍアーキテクチャによって採用されるオントロジ表現フォーマットを示す。＜Ｎｏｎ−Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ＞は、ｏｎｅＭ２Ｍ以外の名前空間からパブリッシュされる全オントロジを記憶する。＜Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ＞は、ｏｎｅＭ２Ｍバーティカルからパブリッシュされる全オントロジを記憶する。表１１は、＜ｎａｍｅｓｐａｃｅ＞の属性およびその説明を示す。表１２は、＜ｅｘｔｅｒｎａｌ−ｏｎｔｏｌｏｇｙ＞の属性およびその説明を示す。表１３は、＜ｉｎｔｅｒｎａｌ−ｏｎｔｏｌｏｇｙ＞の属性およびその説明を示す。＜ｖｉｒｔｕａｌ−ｏｎｔｏｌｏｇｙ＞のａｃｔｕａｌＬｉｎｋ属性は、＜Ｎｏｎ−Ｍ２Ｍ−Ｎａｍｅｓｐａｃｅ＞下に記憶されたオリジナルオントロジのリンクを示す。
加えて、図２８は、＜ｉｎｔｅｒｎａｌ−ｏｎｔｏｌｏｇｙ＞および＜ｅｘｔｅｒｎａｌ−ｏｎｔｏｌｏｇｙ＞としてインスタンス化される、提案される＜ｏｎｔｏｌｏｇｙ＞リソースの子リソースを示す。本リソースは、図７０に例示され、＜ｃｌａｓｓ＞、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞、および＜ｔｅｒｍ＞サブリソースを含有する。図７０はまた、＜ｏｎｔｏｌｏｇｙ＞リソースが別のリソースによって使用される方法を介してサブスクライブされることができることを示す。
図６２は、意味論センサネットワーク（ＳＳＮ）オントロジの例示的オントロジ表現を図示する。以下の表に提供されるように、実施例は、意味論オントロジに関して提供され得る。図６３は、ｏｎｅＭ２Ｍベースオントロジを図示する。本明細書により詳細に論じられるように、ｏｎｅＭ２Ｍベースオントロジへのリソースマッピングが存してもよい。ｏｎｅＭ２Ｍベースオントロジは、簡単に論じられ、背景を以下の議論に取り込むことに役立つために使用される。ｏｎｅＭ２Ｍベースオントロジは、意味論機能性の有効化をもたらすために要求されるＭ２Ｍサービス層のための仕様のより大きい主要部の一部として開発中である。本オントロジは、他のオントロジ、例えば、本明細書に図６２を参照して説明される意味論センサネットワークオントロジもまた、ｏｎｅＭ２Ｍプラットフォームにマップされ、利用され得るように要求される、現在最小限のオントロジとして設計されている（例えば、最小数の規定を義務付ける）。ｏｎｅＭ２Ｍでは、外部オントロジが、ｏｎｅＭ２Ｍ実装において表されるべき具体的タイプのデバイスまたは実世界「モノ」（建物、部屋、車、都市等）を記述するために使用され得る。目標は、既存の成果の再使用を最大限にし、かつ意味論的に駆動されるインターワーキングソリューションを提供することである。
図６４から図６８を参照して以下に論じられるのは、＜ｃｌａｓｓ＞および＜ｒｅｌａｔｉｏｎｓｈｉｐ＞サブリソースのための異なる検討事項である。＜ｃｌａｓｓ＞および＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースの第１の検討事項は、以下に提供される。図６４、図６５、および図６９は、属性を構築する異なる方法を図示する、＜ｏｎｔｏｌｏｇｙ＞リソースである。図６４および図６５は、クラスおよび関係情報をオントロジ定義内に維持するために、その説明属性を構築する異なる方法を有する。血圧測定が、実施例として使用される。図６４および図６５の差異は、図６５が、意味論情報のオリジナル表現である、ＲＤＦトリプルにおいてクラスおよび関係を定義することである。図６４はさらに、トリプルを関係およびオブジェクトに分割する。これらの２つの方法は、意味論発見および推論ならびにオントロジリソースの作成方法に影響を及ぼし得る。
＜ｃｌａｓｓ＞および＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースのためのリソース構造の第２の検討事項は、図６６および図６７に示される。表１４および表１５は、これらの２つのリソースの属性およびその説明を示す。本第２の実施例では、２つのリソース（＜ｃｌａｓｓ＞９０１および＜ｒｅｌａｔｉｏｎｓｈｉｐ＞９０５）は、オントロジ内の関係を記述する複数の属性ならびに関係カテゴリ９０６または制限９０７等の他の特性を有する。「ｉｓＳｕｂｊｅｃｔＯｆ」（＜ｃｌａｓｓ＞９０１に関する）等の属性は、異なるオプションとともに詳述され、その１つでは、属性は、単一値（＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースのＵＲＩ）を含有し、別のものでは、属性は、タプル（＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソースおよび対応するオブジェクト＜ｃｌａｓｓ＞リソースの両方へのＵＲＩ）を含有する。別の変形例では、これらの値は、対応するリソースのＵＲＩの代わりに、文字値であってもよい。
＜ｃｌａｓｓ＞および＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソース（図６６−図６７、表１４、表１５）の第２の実施形態は、その変形例（いくつかの属性は、単一値もしくはタプルとして提供され、または直接またはＵＲＩとして提供される）とともに、高度な機能性のために特に有用であり得る。関係タイプの理解は、高度な推論のために使用され得る。例えば、オントロジにおいて利用可能な一般化対特殊化関係を示す全関係、またはいくつかのオントロジ間の均等クラスを理解する能力は、高度な推論のために使用され得ることを理解されたい。同様に、サブジェクトとして具体的クラスを有する関係の理解は、導出または拡張された論理が、具体的クラスに基づいてクエリのために適用されることを可能にし得る。ＳＳＮオントロジからの概念を使用する、表１４および表１５に提供される属性実施例に加え、図６８は、（例えば、図６３に関して）本明細書に導入されるようなｏｎｅＭ２Ｍベースオントロジへの＜ｏｎｔｏｌｏｇｙ＞リソースマッピングの実施例を図示する。図６８に示されるような実施例を検討すると、属性は、単一ＵＲＩ値を含有すると仮定され得る。＜ｓｅｒｖｉｃｅＣｌａｓｓ＞および＜ｈａｓＯｐｅｒａｔｉｏｎＲｅｌ＞のような表記は、これらが＜ｃｌａｓｓ＞タイプの＜ｓｅｒｖｉｃｅ＞リソースおよび＜ｒｅｌａｔｉｏｎｓｈｉｐ＞タイプの＜ｈａｓＯｐｅｒａｔｉｏｎ＞リソースを表すことを伝達することを意味する。表記ｉｓＳｕｂｊｅｃｔＯｆ（ｈａｓＯｐｅｒａｔｉｏｎ）は、値ｈａｓＯｐｅｒａｔｉｏｎを伴うｉｓＳｕｂｊｅｃｔタイプの属性を示す。全属性ではなく、例示的もののみが示される。
Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍ）はまた、同様にＭＯＰ機能性を採用し、オントロジを処理、分類、および記憶し得る、他の名前空間／システム（例えば、Ｗ３Ｃ）にＭ２Ｍオントロジをパブリッシュしてもよい。図２９に示されるメッセージフローは、そのオントロジを別の外部名前空間にパブリッシュするために、ｏｎｅＭ２Ｍ実装によって使用されるメッセージ交換の実施例である。外部名前空間またはシステムは、ＭＯＰを含んでもよい、または図１３−図１９と関連付けられた説明等の上記に提示されるようなＭＯＰの分類および発見特徴のいくつかを伴わずに、基本機能性のみを実装し、これらのメッセージをサポートし、Ｍ２Ｍオントロジもしくはそのリンクを記憶してもよい。使用されるメッセージは、図１３−図１９と関連付けられた説明等の前述のものに類似する。メッセージ交換に加え、ｏｎｅＭ２Ｍ ＭＯＰは、必要に応じて、ステップ３、すなわち、Ｍ２Ｍオントロジの別のフォーマットへの変換を実施するであろう。ＭＯＰ機能性は、Ｍ２Ｍ以外の他の名前空間／システムにも適用可能であり得る。例えば、Ｗ３Ｃはまた、ＭＯＰ機能性を採用し、Ｍ２Ｍ名前空間からパブリッシュされたオントロジを処理、分類、および記憶してもよい。
Ｍ２Ｍ高レベルオントロジモデル
図３０は、高レベルオントロジモデルを図示する。物理的世界内のモノは、物理的オブジェクトであり得ると見なされる。物理的オブジェクトはそれぞれ、異なる名前空間内の抽象オブジェクトとしてモデル化されてもよい。例えば、人物／ジムメンバーは、ＦＯＡＦ名前空間を用いてＦＯＡＦオントロジによってモデル化されることができ、センサは、Ｗ３Ｃ ＳＳＮ名前空間を用いてＳＳＮオントロジによってモデル化されてもよく、健康デバイス（体重計、血圧モニタ）は、ＩＥＥＥ１１０７３名前空間によってモデル化されることができる。一方、Ｍ２Ｍシステム内のＭ２Ｍノード（例えば、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ）は、Ｍ２Ｍ名前空間内の抽象オブジェクトに抽象化され、その一実施例は、ｏｎｅＭ２Ｍである。抽象オブジェクトは、Ｍ２Ｍシステムによって維持されるリソースによって表され得る、機能エンティティを含有する。例えば、図３１に示されるように、物理的オブジェクトは、ｏｎｅＭ２Ｍ名前空間内のＭ２Ｍノードに抽象化され、それぞれ、ＡＥまたは／およびＣＳＥを含有してもよい。
図３１は、図３０に示されるＭ２Ｍ高レベルオントロジモデルの例示的ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲＯＡ）を図示する。Ｍ２Ｍノードは、物理的オブジェクトの１つのサブクラスであって、デバイス、ゲートウェイ、およびサーバのサブクラスを有する。Ｍ２Ｍノードは、ｏｎｅＭ２Ｍ名前空間内のｏｎｅＭ２Ｍノードに抽象化されることができる。ｏｎｅＭ２Ｍ名前空間では、４つのタイプのノード、すなわち、ＡＤＮ、ＡＳＮ、ＭＮ、およびＩＮが定義され、これらは、ｏｎｅＭ２Ｍノードのサブクラスである。ＡＤＮは、ＡＥのみを含有する。ＡＳＮは、１つのＣＳＥおよび１つまたはそれを上回るＡＥを含有する。ＭＮは、１つのＣＳＥおよびゼロまたはそれを上回るＡＥを含有する。ＩＮは、１つのＣＳＥおよびゼロまたはそれを上回るＡＥを含有する。それらは、図３１に示されるように、「ｃｏｎｔａｉｎｓ」関係によって示されることができる。図３２および図３３は、ｏｎｅＭ２Ｍ名前空間内で判定され得る、抽象化の異なる実施例である。図３２は、物理的オブジェクトが血圧モニタである実施例を図示する。血圧モニタは、ＡＤＮに抽象化され、ＡＥを含有する。ＡＥは、リソースツリー内の＜ｂｌｏｏｄＰｒｅｓｓｕｒｅＡＥ＞リソースによって表される。図３３は、ジムユーザに属し得る電話の実施例を図示する。電話は、ＡＳＮに抽象化され、ＣＳＥおよびＡＥを含有する。ＣＳＥは、＜ｐｈｏｎｅＣＳＥ＞リソースによって表され、ＡＥは、電話上にインストールされたジムＡＥであり得、リソースツリー内の＜ｇｙｍＡＥ＞リソースによって表される。物理的オブジェクトは、抽象化された後のみ、オントロジによってモデル化されることができる。ＭＯＰ７２１は、それらのオントロジの処理を担う。
Ｍ２Ｍ意味論サポートの機能アーキテクチャ
以下は、さらに観点を与えるためのオントロジに関するさらなる議論である。物理的世界内の全てのモノは、物理的オブジェクトと見なされ得る。物理的オブジェクトはそれぞれ、異なる名前空間内の抽象オブジェクトとしてモデル化されてもよい。図３０は、物理的オブジェクトの抽象化および異なる名前空間の例示的概要を図示する。物理的オブジェクト７１１の抽象化から派生する、名前空間７１２、名前空間７１３、および名前空間７１４等の任意の数の名前空間が存在し得る。各名前空間は、１つまたはそれを上回る物理的オブジェクトをモデル化する、１つのオントロジまたは複数のオントロジを有してもよい。
図３４は、Ｍ２Ｍ意味論サポートのための例示的機能アーキテクチャを図示し、コンポーネントは、以下のうちの１つまたはそれを上回るものであり得る。
・リソースデータベースは、物理的Ｍ２Ｍデバイスから収集されるリソースと、Ｍ２Ｍアプリケーション（通常リソース）に関わる、人物、デバイス等のＭ２Ｍアプリケーションに関連する任意のリソースとを記憶する。Ｍ２Ｍ意味論サポートは、それらの普遍的理解／解釈のためのオリジナルリソースに対する意味論だけではなく、それらへの任意の高度な処理、例えば、意味論クエリ、データ分析等を有効にする。
・オントロジプロセッサは、Ｍ２Ｍドメインの外部および内部でパブリッシュ／生成されるオントロジの処理、分類、記憶、および発見機能を提供することを担う。これは、オントロジを記憶する、オントロジレポジトリを含有する。それらのオントロジは、通常リソースが意味論を有効にするために使用されることができる。オントロジレポジトリは、本明細書に紹介される論理エンティティである意味論ノードの一部と見なされ得る。Ｍ２Ｍシステムは、オントロジプロセッサによって、オントロジを処理、管理、および別様に使用し得る。
・意味論レポジトリは、ＲＤＦを利用するオプションを有し得る、ある表現において、通常リソースの意味論情報を記憶する。
・ルールレポジトリは、多くの場合、リソースデータベース内のリソースと関連付けられた既存の意味論を超える、新しい知識を表すために使用される、ルールを記憶する。ルールは、典型的には、条件文、すなわち、ｉｆ−ｔｈｅｎ節である。
・推論器は、ルールレポジトリおよび意味論レポジトリ内の既存のリソース意味論情報からの入力をとり、ルール内の条件が充足される場合、新しいリソース意味論情報を生成する。新しいリソース意味論情報は、意味論レポジトリに追加される。
・意味論クエリプロセッサは、クライアントからのクエリをハンドリングし、意味論レポジトリ内に記憶された知識／リソース意味論情報を検索し、結果をクライアントに返す。
上記の図１１に関して論じられるようなジム使用例に関して、
・意味論レポジトリは、ジムメンバー、ジム内のデバイス、およびデバイスによって生成されるデータについての意味論情報を記憶し得る。
・意味論ベースのクエリサービスは、メンバーが、可用性、機能等に基づいて、トレッドミルの使用を選択することを所望するとき、必要とされ得る。
・ルールレポジトリは、メンバーがシニア会員資格を有するかどうか、ある機械を使用することが許可されているか等のルールを記憶してもよく、推論器は、新しい意味論情報、例えば、人物のアクセス可能デバイスをリソースに追加するためのルールを使用してもよい。
・上記に示される意味論サポートの機能は、ジム使用例では、ゲートウェイ７０４上にホストされ得る。
図３５は、そのＴＳ１０２ ６９０においてＥＴＳＩによって定義されるＥＴＳＩ Ｍ２Ｍアーキテクチャを実装する、通信システム１２０を図示する略図である。この略図は、本開示の理解を支援するために使用され、本明細書で開示される主題の説明を促進するように簡略化されていることに留意されたい。図３５に示されるように、システム１２０は、ネットワークドメイン１２２、ネットワークドメイン１３０、ネットワークドメイン１３５、およびネットワークドメイン１３８等の複数のネットワークドメインを備えてもよい。各ネットワークドメインは、ＮＳＣＬ１２６、ＮＳＣＬ１３１、ＮＳＣＬ１３６、およびＮＳＣＬ１３９等のネットワークサービス能力層（ＮＳＣＬ）を含んでもよい。各ＮＳＣＬは、それぞれ、ネットワークドメイン１２２およびネットワークドメイン１３０内のネットワークアプリケーション１２７およびネットワークアプリケーション１３２等のそれぞれのネットワークアプリケーションと連動してもよい。
さらに示されるように、ネットワークドメイン１２２等のネットワークドメインはさらに、（例えば、図１の患者監視アプリケーションで使用されるＭ２Ｍデバイスのうちの１つであり得る）デバイス１４５等の１つまたはそれを上回るデバイスと、ゲートウェイ１４０等の１つまたはそれを上回るゲートウェイとを備えてもよい。３ＧＰＰタームでは、デバイスおよびゲートウェイは、ＵＥの実施例である。示されるように、デバイス１４５は、アーキテクチャによって定義されるｍＩｄ基準点を経由してＮＳＣＬ１２６と通信する、デバイスサービス能力層（ＤＳＣＬ）１４６を実行していてもよい。デバイスアプリケーション（ＤＡ）１４７もまた、デバイス１４５上で作動していてもよく、かつｄＩａ基準点を経由してＤＳＣＬ１４６と通信してもよい。同様に、ゲートウェイ１４０は、ｍＩｄ基準点を経由してＮＳＣＬ１２６と通信するゲートウェイサービス能力層（ＧＳＣＬ）１４１を実装してもよい。ゲートウェイ１４０上で作動するゲートウェイアプリケーション（ＧＡ）１４２は、ｄＩａ基準点を介してＧＳＣＬ１４１と通信してもよい。一般に、ｄＩａ基準点は、デバイスおよびゲートウェイアプリケーションがそれぞれのローカルサービス能力（すなわち、それぞれ、ＤＳＣＬまたはＧＳＣＬで利用可能なサービス能力）と通信することを可能にする。ｍＩｄ基準点は、Ｍ２Ｍデバイス（例えば、ＤＳＣＬ１４６）またはＭ２Ｍゲートウェイ（例えば、ＧＳＣＬ１４１）に常駐するＭ２ＭＳＣＬが、ネットワークドメイン（例えば、ＮＳＣＬ１２６）内のＭ２Ｍサービス能力と通信することを可能にし、その逆も同様である。
依然として図３５をさらに詳細に参照すると、ＮＳＣＬ１２６は、ドメイン１２２内にあり、Ｍ２Ｍサーバプラットフォーム１２５上にネットワークアプリケーション（ＮＡ）１２７を伴って構成されてもよい。ＮＡ１２７およびＮＳＣＬ１２６は、基準点ｍＩａ１２８を介して通信してもよい。ｍＩａ基準点は、ＮＡが、Ｍ２Ｍドメイン内のＮＳＣＬから利用可能なＭ２Ｍサービス能力にアクセスすることを可能にしてもよい。
典型的には、デバイス１４５、ゲートウェイ１４０、およびＭ２Ｍサーバプラットフォーム１２５は、図６０Ｃおよび図６０Ｄで図示され、以下で説明されるデバイス等のコンピュータデバイスを備える。ＮＳＣＬ、ＤＳＣＬ、ＧＳＣＬ、ＮＡ、ＧＡ、およびＤＡエンティティは、典型的には、システム１２０においてそれぞれの機能を果たすように、基礎的条件的なデバイスまたはプラットフォーム上で実行される、ソフトウェアの形態で実装される論理エンティティである。
図３５でさらに示されるように、ＮＳＣＬ１３１は、ＮＡ１３２とともにドメイン１３０内にあってもよい。ＮＡ１３２およびＮＳＣＬ１３１は、ｍＩａ基準点１３３を介して通信してもよい。また、ネットワークドメイン１３５内のＮＳＣＬ１３６、およびネットワークドメイン１３８内のＮＳＣＬ１３９もあり得る。ｍＩｍ基準点１２３は、ネットワークドメイン１２２内のＮＳＣＬ１２６、ネットワークドメイン１３０内のＮＳＣＬ１３１、ネットワークドメイン１３５内のＮＳＣＬ１３６、またはネットワークドメイン１３８内のＮＳＣＬ１３９等の異なるネットワークドメイン内のＭ２Ｍネットワークノードが、相互と通信することを可能にする、ドメイン間基準点であってもよい。本明細書で簡単にするために、「Ｍ２Ｍサーバ」という用語は、サービス能力サーバ（ＳＣＳ）、ＮＳＣＬ、アプリケーションサーバ、ＮＡ、またはＭＴＣサーバを示すために使用されてもよい。加えて、本明細書で議論されるようなユーザ機器（ＵＥ）という用語は、ＧＡ、ＧＳＣＬ、ＤＡ、またはＤＳＣＬに適用されてもよい。本明細書で議論されるようなＵＥは、移動局、固定または移動加入者ユニット、ポケットベル、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサまたはアクチュエータ、消費者電子機器、および同等物と見なされてもよい。本明細書で議論されるようなマシンツーマシンサービス能力層エンティティは、Ｍ２ＭサーバまたはＵＥを含んでもよい。
Ｉ．意味論ノードを伴うＭ２Ｍアーキテクチャ
意味論ノードを含むＭ２Ｍシステムの一実施例が、図３６で図示される。Ｍ２Ｍシステム１５０で示されるように、意味論ノードは、３つのレベルで展開される。エリアネットワーク１５４、エリアネットワーク１５５、エリアネットワーク１５６、およびエリアネットワーク１５７等のネットワークを含み得る、エリアレベルがあってもよい。アクセスネットワーク１５２およびアクセスネットワーク１５３等のネットワークを含み得る、アクセスレベルがあってもよい。そして、コアネットワーク１５１等のネットワークを含む、コアレベルがあってもよい。
システム１５０に示されるように、アプリケーション１５８は、基準点ｓＩｃ１５９を介して、エリアネットワーク１５７内に位置するＭ２Ｍ意味論ノード１６０と通信可能に接続されてもよい。ｓＩｃ基準点は、概して、意味論ノードにトークするために、アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワークエンティティ内の他の非意味論ノードエンティティによって使用される。Ｍ２Ｍ意味論ノード１６０は、基準点ｓＩｅ１６２を介して外部意味論ノード１６３と通信可能に接続される。Ｍ２Ｍシステム内の意味論ノードは、ｓＩｅ基準点を介して外部意味論ノードと連動してもよい。外部意味論ノードは、意味論ウェブについてＲＤＦＳによって定義されるもの等の他の既存の意味論関連リソースを管理してもよい。Ｍ２Ｍ意味論ノード１６０はまた、ｓＩｓ基準点１６１を介して、アクセスネットワーク１５３内に位置するＭ２Ｍ意味論ノード１６４と通信可能に接続される。Ｍ２Ｍ意味論ノード１６４は、ｓＩｃ基準点１６６を介してＭ２Ｍゲートウェイ１６５と通信可能に接続され、かつ基準点ｓＩｓを介してコアネットワーク１５１内に位置するＭ２Ｍ意味論ノード１６８と通信可能に接続される。本実施例では、Ｍ２Ｍゲートウェイ１６５自体は、意味論ノードではないが、他の実施例では、Ｍ２Ｍゲートウェイ１６５は、意味論ノードの機能性を組み込むことができる。
意味論ノードは、オフローディング、負荷バランシング、容易なアクセス等の目的で、エリアレベルで展開されてもよい。エリアレベルでは、ローカルエリアネットワーク内の全てのデバイスが、アタッチトアクセスまたはコアネットワーク内の意味論ノードと通信する場合、展開された意味論ノードがない可能性がある。エリアレベルでの意味論ノードは、アクセスレベルで（例えば、Ｍ２Ｍ意味論ノード１６４と接続されたＭ２Ｍ意味論ノード１６０）またはコアレベルで（例えば、意味論ノードを含むＭ２Ｍサーバ１７０と接続されたＭ２Ｍ意味論ノード１６９）対応する親意味論ノードを有してもよい。意味論ノードは、ｓＩｓ基準点を通して相互にトークする。基準点の詳細は、以降でさらに詳細に定義される。アクセスレベルでの意味論ノードはまた、それがｓＩｓ基準点を経由して通信する、コアレベルでの親を有してもよい。同様に、アクセスレベルでの意味論ノードは、それがｓＩｓ基準点を経由して通信する、エリアレベルでの子意味論ノードを有してもよい。コアレベルでの意味論ノードはまた、アクセスまたはエリアレベルで子意味論ノードを有してもよい。
図３６で図示される親子関係に加えて、意味論ノードはまた、意味論ノードレベル（例えば、アクセス、エリア、またはコア）のうちのいずれかで同胞の概念をサポートする。同胞意味論ノードは、階層内の同一レベルでのノードであり、意味論ノードの負荷を分配するために使用することができる。例えば、コアネットワーク１５１では、Ｍ２Ｍ意味論ノード１６８は、意味論ノードを含むＭ２Ｍサーバ１７０と接続される。バーティカルな観点から、１つより多くの意味論ノードの確立された階層がある場合には、ノードは、相互にデータ送信し、ｓＩｓ基準点を経由した通信、ブロードキャスト、発見等を介して、意味情報を共有することができる。
容量の制限による、制約されたデバイスについては、意味論は、特定の意味論、または遠隔意味論ノードに記憶された意味論を指し示すリンクを指すコードであり得る。そのような意味情報は、データを作成したアプリケーションによって、またはサービス層によって提供されてもよい。
アクセスレベルでは、１つのアクセスネットワークで展開された１つまたはそれを上回る意味論ノードがあり得る。もしそうであれば、同胞は、ｓＩｓ基準点を通して意味情報通知、ブロードキャスト、および発見のために相互と通信してもよい。アクセスレベルでの意味論ノードは、それがｓＩｓ基準点を経由して通信する、コアレベルでの親を有してもよい。同様に、アクセスレベルでの意味論ノードは、それがｓＩｓ基準点を経由して通信する、エリアレベルでの子意味論ノードを有してもよい。
コアレベルでは、コアネットワークで展開された１つまたはそれを上回る意味論ノードがあり得る。これらのノードは、同胞であってもよく、通知、ブロードキャスト、および発見を使用して意味情報を共有するために、ｓＩｓ基準点を経由して相互と通信してもよい。コアレベルでの意味論ノードはまた、アクセスまたはエリアレベルで子意味論ノードを有してもよい。アプリケーション、すなわち、エリアネットワーク、アクセスネットワーク、およびコアネットワーク内の他の非意味論ノードエンティティは、ｓＩｃ基準点を介して意味論ノードにトークする。
上記のように、意味論ノードは、ネットワーク内の独立型物理ノード（例えば、独立型Ｍ２Ｍ意味論ノード１６０）であってもよく、または図３６のシステム１５０で示されるようなＭ２Ｍデバイス１７１、Ｍ２Ｍゲートウェイ１７２、またはＭ２Ｍサーバ１７０等のネットワーク内の別の物理ノード上でホストされる論理エンティティであり得る。換言すると、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、およびＭ２Ｍサーバは、意味論ノード機能性をサポートすることができる。
図３６で図示される多層意味論ノード階層の特徴は、それが異なるレベルの抽象化を提供できることである。意味論ノードは、エリアネットワーク特有の意味論関連リソースがローカルで見出され得るように、Ｍ２Ｍエリアネットワーク内等のローカル的領域中の意味論関連リソースを管理することのみを担当してもよい。ローカル的領域中で典型的ではない任意の意味論関連リソースを、高次親または並列同胞意味論ノードに記憶し、見出すことができる。別の特徴は、インターネット階層、場所階層等により、意味論関連リソースがそれら自体で階層を有し得ることである。結果として、意味論の複数の層は、既存のネットワークアーキテクチャと一致する。加えて、意味論ノードは、各レベルで分配されてもよく、これは、集中型意味論ノードがコアネットワークのみで展開される場合に単一故障点を防止する。
ＩＩ．意味論ノードアーキテクチャ
ここで、意味論ノードのアーキテクチャに関するさらなる詳細について議論する。記述されるように、意味論ノードは、意味論関連リソースを記憶して管理する。本明細書で定義されるように、意味論関連リソースは、Ｍ２Ｍデバイスまたはアプリケーションによって生成されるデータ、あるいはＭ２Ｍデバイスまたはアプリケーション自体の意味等のモノの意味情報を記述するために使用することができる、情報を備える。一実施例では、意味論関連リソースは、ＸＭＬスキーマ定義（ＸＳＤ）、ＲＤＦスキーマ／ウェブオントロジ言語（ＲＤＦＳ／ＯＷＬ）、または同等物等の既存のスキーマを使用して、拡張マークアップ言語（ＸＭＬ）で表現されてもよい。実施例では、３つのタイプの意味論関連リソース、すなわち、それぞれ以下でさらに完全に説明される、クラス、関係、およびタームが、意味論ノードに記憶されてもよい。このような意味論関連リソースのカテゴリ化は、意味論ウェブの現在の技法との互換性を提供する。この互換性は、Ｍ２Ｍシステムが、例えば、Ｗ３Ｃによって定義される、これらのコアクラスおよびコアプロパティ等の既存の意味論関連リソースを活用することを可能にする。Ｍ２Ｍシステムの外部のアプリケーションおよびエンティティは、意味論を互換性にするために必要な形式変換または修正による、いかなる余分なオーバーヘッドも被ることなく、意味論ノードによってホストされる意味論関連リソースを使用することができる。
クラス。本明細書では、Ｍ２Ｍドメイン内のオブジェクト／モノのクラスの概念について議論される。図１の例示的健康監視システムでは、例えば、システムに関連するオブジェクトのクラスは、患者、医師、救急車の通信指令係、血圧、中核体温、酸素飽和度、運動加速度計、および同等物を含む。クラスは、ユニフォームリソース識別子（ＵＲＩ）またはユニフォームリソースロケータ（ＵＲＬ）によって識別されてもよい。クラスは、クラスを定義する情報を含有する、フィールド記述を含有する。例えば、摂氏単位の整数として温度データを表し、例えば、これらの意味論を温度センサによって生成されるデータに提供するために使用することができる、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスは、以下のようにＸＳＤのスキーマを用いてＸＭＬで定義されてもよい。
ここで、クラスは、“ｄｅｓｃｒｉｐｔｉｏｎ”、“ｕｎｉｔ”、および“ｂａｓｅ”というフィールドを含有し、これらのフィールドの中の情報は、それぞれ、“ｔｅｍｐｅｒａｔｕｒｅｉｎＣｅｌｓｉｕｓ”、“Ｃｅｌｓｉｕｓ”、および“ｉｎｔｅｇｅｒ”である。別の実施例として、ＢｌｏｏｄＰｒｅｓｓｕｒｅクラスは、２つのフィールド、すなわち、収縮期圧のための１つのフィールド、および拡張期圧のための別のフィールドを含有してもよい。このＢｌｏｏｄＰｒｅｓｓｕｒｅクラスのためのクラス記述は、両方のフィールドの記述を含み、以下のようにＸＭＬ／ＸＳＤを使用して表現されてもよい。
しかしながら、再度、クラス（および他のタイプの意味論関連リソース、すなわち、関係およびターム）は、ＸＭＬ／ＸＳＤを使用する表現に限定されないが、むしろ、例えば、ＲＤＦＳ／ＯＷＬおよび同等物を含む、種々の好適な記述言語のうちのいずれかで表現され得ることが理解される。クラスはまた、相互に関係付けられてもよい。例えば、「血圧」は、「生命」のサブクラスであってもよく、または同等に、「生命」は、「血圧」のスーパークラスであってもよい。サブクラス／スーパークラス関係は、クラスの階層を定義する。一般に、Ａの全てのインスタンスがＢのインスタンスでもある場合、ＡはＢのサブクラスである。クラスは、複数のスーパークラスを有してもよい。
関係。関係は、特別な種類の意味論関連リソースである。関係は、意味論関連リソース間の関連、例えば、「作者」、「寿命」、「加入者」等を記述する。関係はまた、全体的な一意の命名スキームをＭ２Ｍドメインの関係に与える、ＵＲＩ／ＵＲＬによって識別することもできる。クラスおよび継承は、計算の他の分野で、例えば、オブジェクト指向プログラミングで知られている。しかし類似点がある一方で、差異も存在する。オブジェクト指向プログラミングでは、オブジェクトクラスは、それが適用される関係またはプロパティを定義する。新しい関係またはプロパティをクラスに追加することは、クラスを修正することを意味する。しかしながら、ここで、関係は、全体的に定義され、つまり、それらは、クラス定義に属性としてカプセル化されない。クラス自体の定義を変更することなく既存のクラスに適用される、新しい関係が定義されてもよい。クラスのように、関係も相互に関係付けることができる。例えば、「エネルギーモード」および「使用モード」は、「モード」のサブ関係である。デバイスが電気の「エネルギーモード」および手動の「使用モード」を有する場合には、電気および手動の「モード」を有する。
ターム。タームは、Ｍ２Ｍドメインで一般的に使用されている概念である。本明細書で定義されるように、タームは、リソースの意味論を記述するために多くの当事者によって使用され得る値である。タームの定義は、それがパブリッシュされる、あるドメインで普遍的に承認されてもよい。例えば、手動、ユーザ指図、および自律は、それぞれ、例えば、アプライアンスの使用モードを記述するために使用され得る、タームの実施例である。一般に、意味論関連リソースの作成者は、その意味論関連リソースが、クラス、関係、またはタームであるかどうかを判定するであろう。次いで、意味論ノードは、それらの作成者によって定義または判定されるカテゴリの下で意味論関連リソースを記憶するであろう。例えば、図１の患者監視実施例では、意味論関連リソースクラス、関係、およびタームは、血圧モニタ製造業者によって、医師によって、または別のアプライアンス製造業者によって作成されてもよい。他の実施例では、意味論関連リソースクラス、リソース、およびタームは、バーティカルアプリケーションによって定義または作成されてもよい。
リソース（データ、モノ等を含む）の意味論は、リソース、関係、および値から成る、リソース・関係・値トリプルによって記述することができる。値は、クラス、ターム、または他のリソースのいずれか一方であり得る。以下は、いくつかの実施例である。
・Ａ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）ｈａｓＴｙｐｅ（関係）ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ（クラス）
・Ａｎ ａｐｐｌｉａｎｃｅ（リソース）ｈａｓＵｓａｇｅＭｏｄｅ（関係）ｕｓｅｒ−ｄｉｒｅｃｔｅｄ（ターム）
・Ａ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）ｇｅｎｅｒａｔｅｄＢｙＳａｍｅＡｐｐｌｉｃａｔｉｏｎＡｓ（関係）ａｎｏｔｈｅｒ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）
提案されたｓＩｃ、ｓＩｓ、およびｓＩｅ基準点を通して、意味論ノードのクラス、関係、およびタームリソースへの要求を実施することができる。図３７は、Ｍ２Ｍ意味論ノードのクラス、関係、およびタームリソースの例示的説明図である。本実施例で図示されるように、意味論ノード４２０は、異なるアプリケーションおよびドメインからの種々のクラス４２２、関係４２４、およびターム４２６を記憶するように構成されてもよい。代替として、意味論ノード４２０は、アプライアンス意味論、車両意味論、医療アプリケーション意味論、または同等物等の一意のアプリケーションまたはドメインのためのクラス、関係、およびタームリソースを記憶するように構成されてもよい。
ＩＩＩ．Ｍ２Ｍ意味論ノード機能および基準点
この節では、意味論ノードの機能および基準点に関するさらなる詳細が提供される。一実施例では、意味論ノードは、以下の機能、すなわち、意味論ノードのリソースに対する要求を登録して実施することを可能にするように、意味論ノード階層内のより低レベルの子または並列同胞意味論ノードを認証することを含む、他の意味論ノードを認証すること、意味論関連クラス、関係、およびタームリソースをパブリッシュ、作成、削除、更新、および読み出すことを可能にするように、アプリケーション、デバイス、および／またはユーザを認証すること、意味論関連クラス、関係、およびタームリソースを記憶して管理すること、意味論関連リソースの発見のためのサポートを提供すること、発見クエリに協力して意味論関連リソース情報を共有するために、意味論ノードが相互と（親子、同胞の間で）通信するためのサポートを提供することを実施してもよい。
意味論ノードは、１つまたはそれを上回る基準点またはインターフェースを介して、ネットワーク内の他のエンティティと通信してもよい。一実施例では、３つの基準点、すなわち、ｓＩｓ基準点、ｓＩｃ基準点、およびｓＩｅ基準点が定義される。ｓＩｓ基準点は、意味論ノード間の通信に使用される。ｓＩｓ基準点はまた、親子または同胞関係を形成するように別の意味論ノードに登録するため、他の意味論ノードを発見するため、その状態（例えば、オンライン、オフライン、オーバーロード等）について他者に通知するため、特定の動作（例えば、登録解除、登録）を実施するように別の意味論ノードにトリガするため、別の意味論ノード内の意味論関連リソースをパブリッシュ、作成、削除、更新、および読み出すために、意味論ノードによって使用されてもよい。加えて、意味論ノードは、図５３、図５４、および図５５に関連して以下でさらに説明されるように、別の意味論ノード内の意味論関連リソースに加入するため、および対応する通知を受信するため、その階層内の同胞および親意味論ノード上の意味論関連リソースを発見するため、意味論関連リソースのグループを１つの意味論ノードから別の意味論ノードへ移動させるため、および意味論をリソースに提供するように別の意味論ノードに記憶された意味論関連リソースがそのリソースと結び付けられて関連付けられることを可能にするために、ｓＩｓ基準点を使用してもよい。
本実施例では、ｓＩｃ基準点は、種々のネットワークドメイン（例えば、エリアネットワーク、アクセスネットワーク、またはコアネットワーク）からの意味論ノードと通信するために、アプリケーションまたは非意味論ノードによって使用されてもよい。ｓＩｃ基準点はまた、アプリケーションまたは非意味論ノードが、意味論ノード内の意味論関連リソースをパブリッシュ、作成、削除、更新、読み出し、加入、または発見すること、意味論ノードから通知を受信することも可能にする。加えて、ｓＩｃ基準点は、意味論をリソースに提供するように、意味論ノードに記憶された意味論関連リソースがそのリソースと結び付けられて関連付けられることを可能にする。
ｓＩｅ基準点は、Ｍ２Ｍシステム内のノードの既存の階層の一部である意味論ノードと外部意味論ノードとの間の通信に使用されてもよい。外部意味論ノードは、Ｍ２Ｍドメインの外部に意味論関連リソースを記憶する。外部意味論ノードの一実施例は、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００５／Ｉｎｃｕｂａｔｏｒ／ｓｓｎで説明されるようなＷ２Ｃ Ｓｅｍａｎｔｉｃ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ Ｉｎｃｕｂａｔｏｒ Ｇｒｏｕｐによって定義される、意味論センサネットワークオントロジのための意味論関連リソースを記憶するサーバであってもよい。ｓＩｅ基準点は、意味論ノードが外部意味論ノード内の意味論関連リソースを読み出し、発見し、およびそれに加入することを可能にし、その逆も同様である。また、ｓＩｅ基準点を介して、外部意味論ノードは、Ｍ２Ｍシステム内の意味論ノードを発見し、通知を受信してもよい。
これらの基準点を効果的に定義する、ｓＩｓ、ｓＩｅ、およびｓＩｃ基準点と関連付けられるメッセージの一実施例が、表１６で以下に記載される。
表１６は、意味論ノード関連メッセージ、それらの対応する意味、および使用される基準点を記載する。
ハイパーテキスト転送プロトコル（ＨＴＴＰ）または制約アプリケーションプロトコル（ＣｏＡＰ）等のプロトコルが、異なるタイプのメッセージを搬送するための基礎的条件的トランスポートプロトコルとして使用されてもよい。上記で議論される種々の意味論ノード機能性を果たすためのこれらのメッセージの使用の実施例が、以下で提示される。
ＩＶ．Ｍ２Ｍ意味論ノードプロシージャ
Ａ．意味論ノード階層を構築する
この節では、一実施例による、どのようにして意味論ノードの階層（以降では「意味論ノード階層」）が構築され得るかに関して、付加的な詳細が提供される。本実施例では、意味論ノード階層は、ネットワーク内の異なるエリア、アクセス、およびコアレベルに位置する意味論ノード間の親子および同胞関係を判定することによって構築される。
図３８Ａは、意味論ノード階層を確立するための方法の一実施例を図示する、フロー図である。意味論ノードがネットワークに参加する（ステップ５０４）、すなわち、オンラインになるとき、最初に、ネットワーク内で動作意味論ノードになることができる前に、子・親および同胞関係を構築する必要がある。この目的を達成するために、ステップ５０６では、意味論ノードは、同一のレベルで同胞意味論ノードの発見を実施してもよい。
同胞意味論ノードの発見は、同胞意味論ノードを発見しようとして発見要求を発行することができる、意味論ノード発見要求（例えば、マルチキャスト、ブロードキャスト、エニーキャスト）を送信することに基づいてもよい。要求は、ネットワークを混雑させ得る、発見要求および応答メッセージのフラッディングを制限する、定義されたホップ制限を有することができる。代替として、発見は、利用可能である場合、ドメイン名システム（ＤＮＳ）、ＤＮＳサービス発見（ＤＮＳ−ＳＤ）、サービスロケーションプロトコル（ＳＬＰ）等のネットワーク内で利用可能な既存の発見機構を活用することができる。意味論ノードは、ＩＰアドレスまたは管理される意味情報のタイプ等の隣接同胞意味論ノードの返信された情報を記憶してもよい。以下でさらに議論されるように、同胞意味論ノード発見応答メッセージはまた、高次意味論ノード発見サーバのアドレス、同胞の親意味論ノードのアドレス、または両方をピギーバックしてもよい。
依然として図３８Ａを参照すると、同胞意味論ノードの発見に続いて、意味論ノードは、次に、ステップ５０８、ステップ５１０、およびステップ５１２で、高次レベル意味論ノードを発見すること、および／または、それらに登録することを試みてもよい。意味論ノードが、それが登録する必要がある高次ノードを供給された場合、単純に、この供給された意味論ノードに登録し、親子関係を構築することができる（ステップ５０８、ステップ５１２）。別様に、意味論ノードは、既存の高次意味論ノードを発見し、登録するようにそれらのうちの１つを選択する必要がある（ステップ５１０）。選択は、同一のタイプの意味論リソース、および同等物をサポートする、隣接上位レベルで最近傍等の基準に基づいてもよい。図３８Ｂは、これらのステップ５０８、ステップ５１０、およびステップ５１２をさらに詳細に図示する。
本実施例では、各レベルでは、デフォルトで高次意味論ノード発見要求を受理する、１つの意味論ノード発見サーバがあってもよい。意味論ノード発見サーバのアドレスは、低次レベル意味論ノードに周知されてもよい。図３８Ｂに示されるように、新しい意味論ノードが高次親意味論ノードアドレスを供給されない場合（ステップ６０２）、および新しい意味論ノードが上位レベルで意味論ノード発見サーバを供給されない場合（ステップ６０４）、最初に、同胞意味論ノード発見６０６を実施することができる。同胞発見の一部として、意味論ノード発見サーバのアドレスは、共有されてもよい（例えば、発見された同胞意味論ノードから受信される同胞発見応答でピギーバックされる）（ステップ６０８）。一方で、これはまた、登録する独自の親としてノードを選択し得るように、同胞の親意味論ノード情報（アドレス）を明示的に要求してもよい（ステップ６１０、６１８）。
新しい意味論ノードが上位意味論ノード発見サーバのアドレスを供給される場合、意味論ノード発見を直接実施することができる（ステップ６０４からステップ６１４への通過を制御する）。別様に、同胞の親リストから選択したいかどうか、および同胞からデフォルト意味論ノード発見サーバのアドレスを読み出したいかどうかを決定する（ステップ６０８および６１０）。新しい意味論ノードが同胞の親から上位意味論ノードを選択する場合（ステップ６１８）、意味論ノード発見をさらに行わないことを選択してもよい。別様に、これは、（同一のタイプの意味論リソース等をサポートする、ホップ数で最近傍にある）親を選択する基準を決定する（ステップ６１４）。基準に基づいて、これは、上位レベルでの意味論ノードのアドレスに加えて、発見したい情報（距離、意味論リソースのサポートされたタイプ等）を設定する（ステップ６１６）。
ステップ６２０では、新しい意味論ノードが、発見した、または別様に選択した高次親意味論ノードに登録してもよい。新しい意味論ノードが、高次意味論ノード発見サーバのアドレスを知ることも、それが登録し得るその同胞のいかなる高次親意味論ノードも識別することもできない場合、いずれの高次親意味論ノードも利用可能ではないと判定し、ステップ６１２でプロセスを終了させてもよい。
図３８Ａを再度参照すると、いったん同胞の発見ならびに親ノードの発見および登録が完了すると、新しい意味論ノードの同胞および親についての情報が記憶される（ステップ５１４）。図３８Ａでさらに図示されるように、新しい同胞がネットワークに参加するか、または既存の同胞がオフラインになる場合、意味論ノードは、その意味論ノード関係を更新してもよい（ステップ５１６、５１８）。ステップ５２０では、新しい意味論ノードが現在動作している。図３８Ａでさらに図示されるように、動作意味論ノードは、ある以降の時点で、別の高次ノードに登録するようにトリガされてもよく（ステップ５２２）、またはネットワークから離れてもよい（ステップ５２６）。前者の場合、意味論ノードは、その現在の親を登録解除し、新しい親に登録してもよい（ステップ５２４）。後者の場合、意味論ノードは、単純に、その現在の親を登録解除してもよい（ステップ５２８）。
図３９は、上記で議論され、図３８Ａおよび図３８Ｂで図示される、意味論ノード発見および登録プロセスをさらに図示する、メッセージフロー図である。ステップ１８５では、新しい意味論ノード１８１が、意味論ノード発見要求を同胞意味論ノード１８２に送信する。同胞意味論ノード１８２は、新しい意味論ノード１８１と同一のネットワークレベルにある。ステップ１８５の意味論ノード発見要求は、意味論ノード発見サーバ１８３に関する情報（例えば、アドレス）、または同胞意味論ノード１８２の親（例えば、上位）意味論ノード１８４である意味論ノードの情報に対する要求を含有してもよい。親意味論ノードに対する要求は、新しい意味論ノード１８１が、登録する独自の親を選択することを可能にしてもよい。
意味論ノード発見サーバ１８３は、同一のレベルで散乱させられた意味論ノードの情報を記憶するための集中点、またはネットワークの同一のレベルで発見要求を大量送信し、意味論ノードの返信された応答を収集する集合点と見なされてもよい。意味論ノード発見サーバ１８３は、新しい意味論ノード１８１のネットワークレベルより高い、同一である、または低いレベルネットワークレベルでネットワークに常駐する、サーバであってもよい。本実施例は、意味論ノード発見サーバ１８３が、新しい意味論ノード１８１のネットワークレベルに関して上位レベルにあることを仮定する。意味論ノード発見サーバ１８３のアドレスを、低次意味論ノード（例えば、同胞意味論ノード１８２）に周知させることができる。新しい意味論ノード１８１が意味論ノード発見サーバ１８３を供給されない場合には、新しい意味論ノード１８１が同胞意味論ノード発見を実施してもよい。新しい意味論ノード１８１が意味論ノード発見サーバ１８３のアドレスを供給される場合には、意味論ノード発見を直接実施することができる。
図３９のステップ１８６では、同胞意味論ノード１８２が、意味論ノード発見応答を送信する。意味論ノード発見応答は、意味論ノード発見サーバ１８３の情報（例えば、アドレス情報）、または同胞意味論ノード１８２の親である意味論ノードの情報を含有してもよい。ネットワークのレベルでの各同胞ノードは、同胞意味論ノード１８２によって提供される情報とは異なり得る、親意味論ノード情報および意味論ノード発見サーバ情報で応答してもよい。
ステップ１８７では、新しい意味論ノード１８１が、意味論ノード発見サーバ１８３の受信されたアドレスを抽出する。ステップ１８８では、新しい意味論ノード１８１が、意味論ノード発見要求を意味論ノード発見サーバ１８３に送信する。ステップ１８８での要求は、意味論ノード１８１が接続し得る、１つまたはそれを上回る親意味論ノードに対するクエリであってもよい。ステップ１８９では、意味論ノード発見サーバ１８３が、意味論ノード発見応答を新しい意味論ノード１８１に送信する。ステップ１８９での応答は、１つまたはそれを上回る親意味論ノードを含有してもよい。ステップ１９０では、新しい意味論ノード１８１が、登録する１つの親意味論ノードを選択する。ステップ１９１では、意味論ノード１８１が、その選択された親意味論ノード１８４への登録に対する要求を送信する。ステップ１９２では、親意味論ノード１８４が、ステップ１９１での登録に対する要求への応答を送信する。
概して、新しい意味論ノード１８１が意味論ノード発見サーバ１８３のアドレスを供給される場合、意味論ノード発見を直接実施することができる。別様に、新しい意味論ノード１８１は、１つまたはそれを上回る同胞から受信される親意味論ノードのリストから選択したいかどうか、および同胞から意味論ノード発見サーバ１８３のデフォルトアドレスを読み出したいかどうかを決定する。各レベルで、デフォルトで高次意味論ノード発見要求を受理する、１つまたはそれを上回る意味論ノード発見サーバがあってもよい。新しい意味論ノード１８１が同胞の親から上位意味論ノードを選択する場合、新しい意味論ノード１８１は、意味論ノード発見をさらに行わないことを選択してもよい。新しい意味論ノード１８１は、親を選択する（例えば、同一のタイプの意味論関連リソース等をサポートする、ホップ数で最近傍等のオプションから選択する）基準を決定するオプションを有してもよい。基準に基づいて、新しい意味論ノード１８１は、上位レベルでの意味論ノードのアドレスに加えて、発見したい情報（例えば、距離、意味論関連リソースのサポートされたタイプ等）を設定する。
図４０は、その一実施例による、親子関係更新プロセス（図３８Ａのステップ５２２および５２４）のさらなる詳細を提供する、メッセージフローを提供する。更新は、子または親意味論ノードによって開始されてもよい。ステップ２０５では、意味論ノード２０１が、通知に基づいて現在の親意味論ノード２０３から登録解除することを決定する。通知は、とりわけ、登録解除を開始する現在の親意味論ノード２０３からのメッセージ、現在の意味論ノード２０３が連絡可能ではない（例えば、オフラインである、切断されている、または他の通信問題）であるという判定、または親意味論ノード２０３と関連付けられる受信された状態更新（例えば、ネットワークトラフィック混雑、デバイスまたは回線エラー、メモリ容量問題等）であってもよい。
ステップ２０６では、意味論ノード２０１が、親子関係を終了させる要求を含む、登録解除要求を現在の親意味論ノード２０３に送信する。ステップ２０７では、意味論ノード２０１が、現在の親意味論ノード２０３、または現在の親意味論ノード２０３の知覚された状態を通信することができる別のデバイスから、ステップ２０６で送信された登録解除要求への応答を受信してもよい。図３９に関して図示されるステップと同様に、意味論ノード２０１は、新しい親意味論ノードに登録しようとする。ステップ２０８では、意味論ノード２０１が、意味論ノード発見要求を意味論ノード発見サーバ２０２に送信する。ステップ２０９では、意味論ノード発見サーバ２０２が、意味論ノード発見応答を意味論ノード２０１に送信する。ステップ２１０では、意味論ノード２０１が、登録する１つの上位意味論ノードを選択する。ステップ２１１では、意味論ノード２０１が、その選択された新しい親意味論ノード２０４への登録に対する要求を送信する。ステップ２１２では、新しい親意味論ノード２０４が、親子関係の更新を確認する、ステップ２１１での登録に対する要求への応答を送信する。
（示されていないが、図４０の要素を参照した）実施例では、親意味論ノードが、子の登録解除をトリガし、登録する子のための新しい親意味論ノードを提供してもよい。この新しい親情報は、登録解除トリガメッセージに、または代替として、別個のトリガメッセージに含まれてもよい。意味論ノード２０１は、現在の親意味論ノード２０３に登録要求を新しい親意味論ノード２０４へ送信させることによって、新しい親意味論ノード２０４に登録することができる。現在の親意味論ノード２０３は、登録目的で、意味論ノード２０１の情報を新しい親意味論ノード２０４に転送するオプションを有する。現在の親意味論ノード２０３または意味論ノード２０１は、現在の親意味論ノード２０３を新しい親意味論ノード２０４に切り替える前に、親子関係を終了させてもよい。
概して、意味論ノードの親子関係は、子意味論ノードがオフラインになるとき、または子意味論ノードが別の高次親意味論ノードに登録するときに、現在の親意味論ノードを登録解除することによって終了させられる。
隣接同胞意味論ノードがネットワークに参加する場合、新しい意味論ノードを追加することによって、対応する同胞情報が更新される。隣接同胞意味論ノードがネットワークから離れる場合、意味論ノードを削除するか、またはネットワークから離れた同胞意味論ノードの状態を示すようにテーブルを別様に更新する（例えば、状態＝オフライン）ことによって、対応する同胞情報が更新される。意味論ノードは、例えば、表１４で上記に示されるＳＥＭＡＮＴＩＣＳ＿ＮＯＤＥ＿ＳＴＡＴＵＳ＿ＮＯＴＩＦＹ（）メッセージを使用して、その状態を同胞意味論ノードにブロードキャストするか、または別様に通信してもよい。状態更新は、どのようにして同胞および親子関係が維持されるかに影響を及ぼしてもよい。
Ｂ．意味論関連リソース発見、読み出し、および妥当性確認
アプリケーション、デバイス、ユーザ、ピア意味論ノード、外部意味論ノード、または非意味論ノードは、ｓＩｃ、ｓＩｓ、およびｓＩｅ基準点を通して、意味論関連リソース発見要求を意味論ノードに送信してもよい。発見要求メッセージは、意味論関連リソースのタイプ（クラス、関係、またはターム）と、検索文字列とを含んでもよい。例えば、摂氏単位の整数として、その温度読取データをそのＭ２Ｍゲートウェイに報告する必要がある、Ｍ２Ｍシステム内の温度感知アプリケーション（Ａｐｐ１）を仮定されたい。ゲートウェイサービス能力層（ＧＳＣＬ）がデータを理解することを可能にするために、Ａｐｐ１は、データを適正な意味情報と関連付ける必要がある。本明細書で説明されるプロシージャに従って、Ａｐｐ１は、摂氏単位の整数として温度データを表す、意味論関連リソースクラス、すなわち、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスを記憶する、意味論ノードを発見してもよい。発見後に、Ａｐｐ１は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスの表現を読み出し、その温度データの意味論を提供するためにそれが使用したいものであるという妥当性を確認するであろう。次いで、これは、データをその属性（意味論属性）のうちの１つとしてｔｅｍｅｐｒａｔｕｒｅＲｅａｄｉｎｇクラスと結び付けるであろう。ＧＳＣＬでは、データは、例えば、図５９で図示されるように、ｈａｓＴｙｐｅ関係を使用してｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスに結び付く意味論属性を有するであろう、Ａｐｐ１のための＜ｔｅｍｐＤａｔａ＞コンテナの下で記憶されてもよい。結果として、ＧＳＣＬ内の＜ｔｅｍｐＤａｔａ＞コンテナの下で記憶された全てのＡｐｐ１データは、データの各アイテムが整数であり、摂氏単位を有するという同一の意味論を有するであろう。別の実施例として、Ａｐｐ１は、ＮＳＣＬからリソースを取り出すアプリケーションであってもよい。リソースは、（上記の実施例に類似する）ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスに結び付く意味論属性を有してもよい。リソースのコンテナ内のデータを理解して解釈するために、Ａｐｐ１は、リソースの意味論属性が結び付けられる意味論関連リソース、この場合は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスを読み出す必要があろう。Ａｐｐ１は、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラス意味論関連リソースの表現を読み出した後、現在、整数であり、摂氏単位を有することが分かっている、リソースデータを解釈できるであろう。
図４１は、一実施例による、意味論ノードにおける意味論関連リソース発見要求の処理を図示する、フロー図である。ブロック２２１では、意味論ノードが、要求された意味論関連リソースのタイプと、潜在的な検索文字列とを含む、意味論関連リソース発見要求を受信する。ブロック２２２では、意味論ノードが、発見要求をチェックする。要求が不十分であるか、または不正な形式である（例えば、要求されたリソースのタイプが欠落している）場合、発見要求は無効と見なされ、無効な発見応答がブロック２３３によって示されるように発行側（例えば、要求クライアントデバイス）に返信されるであろう。ブロック２２３によって示されるように、要求が有効である場合、検索文字列は、ローカルで記憶された意味論関連リソースと比較される。具体的には、要求された意味論関連リソースのタイプに基づいて、意味論ノードは、どのタイプ（すなわち、クラス、関係、またはターム）の意味論関連リソースをそれが検索するであろうかを判定することができる。ブロック２２４によって示されるように、キーワードとして検索文字列を使用して、意味論ノードは、１つまたはそれを上回る合致する意味論関連リソースを見出すように、そのローカル意味データベースを検索する。合致する意味論関連リソースがローカルで見出された場合、意味論関連リソースのアドレス（例えば、ＵＲＬ／ＵＲＩ）が、ブロック２２５によって示されるように、発見応答で発行側に返信されてもよい。
ローカルで見出された合致する意味論関連リソースがない場合、意味論ノードは、その同胞意味論ノードから、合致する意味論関連リソースを見出そうとするであろう。ブロック２２６およびブロック２２７によって示されるように、意味論ノードは、発見要求を同胞に転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック２２８では、合致する意味論関連リソースが連絡を受けた同胞から見出されるかどうかが判定される。合致する意味論関連リソースがその同胞から返信される場合、意味論関連リソースの対応するアドレス（例えば、ＵＲＩ／ＵＲＬ）が、成功した発見応答とともに発行側に返送される（ブロック２２５）。
意味論ノードの同胞から返信される、合致する意味論関連リソースがない場合には、ブロック２２９によって示されるように、親意味論ノードが連絡を受けることができるかどうかが判定される。親意味論ノードがない場合には、否定結果を示す発見応答が発行側に返信されるであろう（ブロック２３３）。親意味論ノードがある場合、意味論ノードは、その親意味論ノードから合致する意味論関連リソースを見出そうとするであろう。それぞれ、ブロック２３０およびブロック２３１によって示されるように、意味論ノードは、発見要求を親意味論ノードに転送し、応答が戻ってくることを待つであろう時間窓を設定する。ブロック２３２では、合致する意味論関連リソースが連絡を受けた親から見出されるかどうかが判定される。合致する意味論関連リソースが連絡を受けた親から返信される場合、意味論関連リソースの対応するアドレス（例えば、ＵＲＩ／ＵＲＬ）が、成功した発見応答とともに発行側に返送される（ブロック２２５）。意味論ノードの親から返信される、合致する意味論関連リソースがない場合には、否定結果を示す発見応答が発行側に返信されるであろう（ブロック２３３）。
発行側が、合致する意味論リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を含有する成功した発見応答を受信した後、発行側は、意味論リソースの表現を読み出すことができる。
一実施例では、意味論ノードは、クライアントおよびサーバから成る、ＲＥＳＴｆｕｌアーキテクチャ形式（表現状態転送）をサポートしてもよい。クライアント（例えば、発行側）は、サーバ（例えば、意味論ノード）への意味論要求を開始する。本実施例では、サーバ（例えば、意味論ノード）は、意味論に対する要求を処理し、適切な意味論応答を返信する。要求および応答は、意味論関連リソースの表現の転送の周囲で構築される。クライアントは、意味論関連リソース（例えば、クラス、関係、またはターム）上のＲＥＳＴｆｕｌ動作を意味論ノードに要求することができる、アプリケーション、ユーザ、デバイス、意味論ノード等であり得る。
ＲＥＳＴｆｕｌアーキテクチャでリソースを取り扱うとき、意味論関連リソースに適用され得る４つの基本的方法がある。
・ＣＲＥＡＴＥ：クラス、関係、またはタームリソースを作成する
・ＲＥＴＲＩＥＶＥ：クラス、関係、またはタームリソースのコンテンツを読み取る
・ＵＰＤＡＴＥ：クラス、関係、またはタームリソースのコンテンツを書き込む
・ＤＥＬＥＴＥ：クラス、関係、またはタームリソースを削除する
ＲＥＳＴｆｕｌサーバの役割を果たす意味論ノードが、受信した要求の妥当性を確認してもよい。動作は、発行側が適正なアクセス権の認定を受けた場合に可能にされる。
図４２は、このＲＥＳＴｆｕｌ実施例による、これらのＲＥＳＴｆｕｌ意味論ノード動作をさらに図示する、メッセージフロー図である。ステップ２４３では、発行側２４１が、ＲＥＳＴｆｕｌ ＣＲＥＡＴＥ、ＵＰＤＡＴＥ、ＲＥＴＲＩＥＶＥ、またはＤＥＬＥＴＥという動詞を対応して使用して、意味論関連リソース（クラス、関係、またはターム）を作成、要求、読み出し、または削除するように要求する。発行側２４１は、アプリケーション、別の意味論ノード、デバイス、ユーザ、または同等物であってもよい。ステップ２４３で意味論関連リソースを作成するために、発行側２４１は、意味論関連リソースのタイプおよび表現を提供する、ＣＲＥＡＴＥ要求を発行する。ステップ２４３で意味論関連リソースを更新するために、発行側２４１は、意味論関連リソースの一意の識別またはアドレス、および更新または部分的に更新された表現を提供する、ＵＰＤＡＴＥ要求を発行する。ステップ２４３で意味論関連リソースを読み出すために、発行側２４１は、意味論関連リソースの一意の識別またはアドレス、および随意に検索文字列パラメータを提供する、ＲＥＴＲＩＥＶＥ要求を発行する。ステップ２４３で意味論関連リソースを削除するために、発行側２４１は、意味論関連リソースの一意の識別またはアドレスを提供する、ＤＥＬＥＴＥ要求を発行する。
ステップ２４４では、意味論ノード２４２が、サーバの役割を果たし、受信した要求の妥当性を確認し、別様にそれを処理する。受信した要求は、発行側２４１が適正なアクセス権の認定を受けた場合に許可される。作成動作が意味論ノード２４２によって許可される場合、新しい意味論関連リソースは、それがクラス、関係、またはタームであるかどうかに基づいて、適切なリソースプールの下で作成される。そして意味論関連リソースは、意味論ノード２４２によって一意の識別子またはアドレスを割り当てられる。更新動作が意味論ノード２４２によって許可される場合、意味論関連リソースの表現が更新される。読み出し動作が意味論ノード２４２によって許可される場合、意味論関連リソースの表現は、発行側２４１が要求する形式で準備される。削除動作が意味論ノード２４２によって許可される場合、要求された意味論関連リソースが削除される。
ステップ２４５では、意味論ノード２４２が応答を発行側２４１に返信する。作成動作については、新たに作成された意味論関連リソースの識別またはアドレスが発行側に返信される。更新動作については、動作が成功しようとそうでなかろうと、応答コードが発行側２４１に返信される。読み出し動作については、発行側２４１が要求する形式の意味論関連リソースの表現が、発行側２４１に返信される。削除動作については、動作が成功したかどうかを示すように、応答コードが発行側２４１に返信される。
図４３は、本明細書で説明される意味論関連リソース発見、読み出し、および妥当性確認をさらに図示する、メッセージフロー２５０である。本実施例では、ネットワークは、発行側２５１、意味論ノード２５２、意味論ノード２５２の同胞である同胞意味論ノード２５３、および意味論ノード２５２にとって親である親意味論ノード２５４を含有してもよい。ステップ２５６では、発行側２５１が、意味論関連リソース発見要求を意味論ノード２５２に送信する。メッセージフロー２５０に示されるように、意味論ノード２５２は、ステップ２５６で、要求に合致する意味論関連リソースを見出すように、（図４１のプロセスに類似する）いくつかのステップを通過する。図示されるように、第１に、意味論ノード２５２は、そのローカルディレクトリを検索するであろう。これは、いかなる合致リソースも見出さない場合、時間窓を設定し、発見要求を同胞２５３等のその同胞に転送するであろう。応答がその同胞から受信されない場合、意味論ノード２５２は、その要求を親意味論ノード２５４に転送するであろう。本実施例では、親意味論ノード２５４が合致するリソースを見出し、それが見出した意味論関連リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を示す応答を意味論ノード２５２に返送するであろうことが仮定される。
ステップ２５７では、次いで、意味論ノード２５２が、発行側の要求に合致した、親意味論ノード２５４からの意味論関連リソースのアドレス（例えば、ＵＲＩ／ＵＲＬ）を含む、意味論関連リソース発見応答を発行側２５１に返送する。ステップ２５９では、発行側２５１が、受信したＵＲＬに基づいて意味論関連リソース読み出し要求を送信する。ステップ２６０では、親意味論ノード２５４が、クラス、関係、またはタームを含み得る、要求された意味情報を含有する、意味論関連リソース読み出し応答を送信する。
ステップ２６１では、発行側２５１が、ステップ２６０からの受信した意味情報の表現をチェックする（妥当性を確認する）。ステップ２６０で送信される、受信した意味論関連リソースが、正確には発行側２５１が欲しいものではない可能性がある。例えば、発行側２５１が温度クラスを要求し、返信された合致するリソースが関連華氏単位を伴うｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇと呼ばれるクラスであるが、発行側２５１が摂氏単位を伴う温度クラスを所望する場合には、発行側２５１は、親意味論ノード２５４が意味論を修正することを要求することができる。これは、意味論関連リソースを修正するように、ステップ２６２で意味論関連リソース修正要求を親意味論ノード２５４に送信することによってサポートすることができる。ステップ２６３では、新たに追加または修正された意味論関連リソースのアドレス（例えば、ＵＲＬ／ＵＲＩ）が、発行側２５１に返信されるであろう。
意味論関連リソースの修正を参照すると、概して、意味論ノードがそれ自体で修正をサポートしない場合、意味論ノードは、修正を実施するようにその同胞または親と協力してもよい。意味論ノードが修正をサポートする場合には、意味論ノードは、新しいクラスを追加するか、現在のクラスを拡張することによって、クラスをローカルで修正してもよい。
Ｃ．意味論関連リソースに加入する
一実施例では、意味論ノードは、それに加入するクライアント（例えば、アプリケーション、別の意味論ノード、デバイス、ユーザ、または同等物）をサポートすることができる。一実施例として、クライアントは、加入した意味論関連リソースへの任意の更新があるときに通知されるように、意味論ノードに加入してもよい。更新が起こるとき、加入クライアントは、リソースの新しい表現で通知されるであろう。それ自体が意味論ノードであるクライアントの場合、加入した意味論関連リソースは、加入者意味論ノードが関係しない（例えば、親子または同胞ではない）別の意味論ノードに記憶され得る。本実施例では、クライアントは、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥ＿ＲＥＱメッセージを意味論ノードに発行してもよい。メッセージは、リソースが更新されたときにクライアントが通知を受信することを希望する、意味論関連リソースを識別する。意味論ノードは、加入を承認する、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥ＿ＲＥＳＰメッセージで要求に応答するであろう。クライアントが加入した意味論関連リソースが更新されるとき、意味論ノードは、更新についてクライアントに通知するように、ＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＳＵＢＳＣＲＩＢＥＲ＿ＮＯＴＩＦＹメッセージを送信するであろう。
別の実施例として、意味論ノードは、その同胞、親、または子意味論ノードのうちの１つによって記憶および管理される意味論関連リソースを用いて更新されることに関心があり得る。図４４は、一実施例による、この状況のための加入／通知プロセスの例示的なフロー２７０である。本実施例では、意味論ノード２７１は、加入先意味論ノード２７２によって記憶および管理される意味論関連リソースを用いて更新される。加入先意味論ノード２７２は、意味論ノード２７１の同胞、親、または子であってもよい。ステップ２７３では、意味論ノード２７１が、加入標的を識別し、トリガ基準に関連する意味論関連リソース通知のみを受信するように、通知トリガ基準を設定してもよい。例えば、加入者は、新しい通知が送信される前に、特定の意味論関連リソースまたは意味論関連リソースへの特定数の更新を特定するように、通知トリガ基準を構成してもよい。意味論ノード２７１はまた、通知が送信されるべきときの期間スケジューリング情報を設定してもよい。
ステップ２７４では、意味論ノード２７１が、意味論ノードリソース加入要求を標的意味論ノード２７２に送信する。ステップ２７５では、標的意味論ノード２７２が、ステップ２７４の意味論加入要求を受理するかどうかを判定する。標的意味論ノード２７２は、既存の加入者、加入を取り扱う負荷（例えば、更新情報の収集または通知を送信するために使用される帯域幅に関する負荷）等に基づいて、加入要求を受理するかどうかを決定することができる。ステップ２７６では、標的意味論ノード２７２が、意味論ノード加入応答を意味論ノード２７１に送信する。ステップ２７６での応答は、加入の確認、および加入を処理する際に使用されるであろうパラメータを含んでもよい。ステップ２７７では、ステップ２７６後のある時点で、標的意味論ノード２７２が、ステップ２７４で受信される要求トリガに合致する、意味通知トリガ条件を検出する。ステップ２７８では、標的意味論ノード２７２が、特定の意味論関連リソースに関して意味論ノード２７１を更新するように、意味論ノードリソース加入通知メッセージを送信する。
概して、意味論関連リソース加入は、ピア意味論ノードまたは親意味論ノードからの意味論関連リソース発見を促進することができる。例えば、（意味論ノードに記憶される、新たに作成または更新された意味論関連リソースのＵＲＩを含むであろう）通知メッセージに基づいて、意味論ノードは、発見要求を送信することなく、他のノードの意味論関連リソース上で発見を実施することが可能であり得る。
Ｄ．意味論関連リソースへの結び付きおよび関連
意味論ノードの意味論関連リソースは、種々の方法で使用することができる。例えば、意味論関連リソース表現は、意味論ノードから読み出されてもよく、データが（例えば、ネットワークサーバ上、デバイス上、ゲートウェイ上等に）記憶されるネットワーク場所に、共同設置様式で記憶されてもよい。代替として、リソースの意味論は、意味論ノード上に記憶されてもよく、意味論へのリンクは、同一場所に位置し、データとともに記憶されてもよい。この意味論リンクは、データ内にインラインで記憶され（すなわち、埋め込まれ）てもよく、またはデータと並行して別々に（例えば、別個のリソースまたは属性に）記憶されてもよい。したがって、この意味論関連リソースへの結び付きを通して、意味論をＭ２Ｍシステム内の通常リソース（例えば、＜ＳＣＬ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞等）に適用することができる。典型的には、この結び付きは、リソースが作成されるときにリソース作成者／生成者によって作成されるであろう。
図１の患者健康監視アプリケーションの以前の実施例を続けると、意味論ノード上で定義される意味クラスがあり、これらのクラスのＵＲＬは、患者健康監視アプリケーションによって発見されてもよい。表１７は、患者健康監視アプリケーションに関連するタイプ「クラス」の意味論関連リソースの実施例を示す。データが、ｈａｓＴｙｐｅと呼ばれる意味関係を使用して、意味クラスに結び付けられてもよい。結果として、ｅｘａｍｐｌｅ／ｈｅａｌｔｈｍｏｎｉｔｏｒｉｎｇ／ｄａｔａ１というＵＲＩを伴う各データリソースについて、リソースの意味論は、以下の関連によって把握されるであろう。
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｐａｔｉｅｎｔ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｐａｔｉｅｎｔ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｄｏｃｔｏｒ／ｄａｔａ２ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｄｏｃｔｏｒ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｔｅｍｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｔｅｍｐｅｒａｔｕｒｅ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｈｒ／ｄａｔａ５ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｈｅａｒｔｒａｔｅ
ｈａｓＴｙｐｅ関係はまた、意味論ノード上に記憶されたｈａｓＴｙｐｅ関係の意味記述を参照する、ＵＲＬ／ＵＲＩによって識別されてもよい。
Ｅ．グループ化最適化
リソースのグループが類似意味論を有する（例えば、同一のアプリケーション内の全てのリソースが同一の意味論を有する）場合、類似意味論を、そのアプリケーションの下の各個別リソースの代わりに、アプリケーションに適用することができる。図４５は、その一実施例による、同一の意味論を伴うリソースのグループ化の方法２８１を図示する。ステップ２８１では、同一のアプリケーションの既存のデータの一部が、同一の意味論関連を共有すると判定される。ステップ２８２では、同一の意味論を共有する、同一のアプリケーション内の判定されたデータが、グループに分類される。ステップ２８３では、ステップ２８２の各グループが、適切な意味論と関連付けられる。ステップ２８４では、同一のアプリケーションからの新たに受信したデータが、同一の意味論を共有するグループに入れられる。同一のアプリケーションの既存のデータは、それぞれ、同一の意味論結び付きおよび関連を共有する、複数のグループに分類されてもよい。新しいデータが同一のアプリケーションから生成される場合、データは、同一の意味論を共有するグループに入れられる。
例えば、血圧監視データの複数のインスタンスは、同一の意味論を有する。したがって、各インスタンスは、以下に示されるような同一の意味論（ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ）と関連付けられてもよい。
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ１ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ２ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ／ｄａｔａ３ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
このグループ化最適化をサポートすることによって、以下の関連も有効であり得る。
・ｅｘａｍｐｌｅ／ｈｅａｌｔｈ／ｂｐ ｈａｓＴｙｐｅ ｓｅｍａｎｔｉｃｓＮｏｄｅ１／ｃｌａｓｓ／ｂｌｏｏｄｐｒｅｓｓｕｒｅ
Ｆ．意味論関連リソースをプッシュ配信する
上記のように、意味論ノードでホストされるクラス、関係、およびタームが発見され、他者によって使用されてもよい。要求の頻度に基づいて、意味論関連リソースのうちのいくつかが、より容易な発見またはアクセスのために、別の意味論ノードでプッシュ配信またはミラーリングされてもよい。例えば、１つの意味論ノードが、別の意味論ノードから同一の転送された発見要求を（例えば、ポリシー定義閾値を超える）ある回数検出した後に、意味論関連リソースのミラーリングされたコピーをその意味論ノードにプッシュ配信することを決定してもよい。
意味論関連リソースのプッシュ配信は、図４６に示されるように、同胞間で、または親および子意味論ノード間で起こることができる。例えば、コアネットワーク２９５内の図４６の意味論ノード２９１は、意味論ノード２９２、意味論ノード２９３、および意味論ノード２９４から、同一の意味論関連リソース（例えば、温度）に対する多くの発見および読み出し要求を受信してもよい。発見要求が定義された閾値に達するとき、意味論ノード２９３および意味論ノード２９４がより速い応答時間で意味論関連リソースにアクセスし得るように、意味論ノード２９１は、意味論ノード２９２上で同一の意味論関連リソースを作成する（すなわち、リソースをミラーリングする）ことを決定してもよい。意味論ノード２９１は、次いで、適切なＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＣＲＥＡＴＥ＿ＲＥＳＰメッセージで応答するであろう、他の意味論ノードにＳＥＭＡＮＴＩＣＳ＿ＲＥＳＯＵＲＣＥ＿ＣＲＥＡＴＥ＿ＲＥＱメッセージを発行することによって、意味論ノード上でミラーリングされたリソースを作成してもよい。
以下のオプションは、意味論関連リソースを最新の状態に保つために使用されてもよい。図４６を参照すると、意味論ノード２９１は、意味論関連リソースの元の表現への任意の更新がある（例えば、加入が必要とされない）場合に、意味論ノード２９２上の意味論関連リソースを自動的に更新してもよい。代替として、意味論ノード２９２は、元の意味論関連リソースに加入してもよい。意味論関連リソースへの意味論ノード２９２の加入に基づいて、意味論ノード２９２は、特定の加入先意味論関連リソースへの任意の変更について通知されるであろう。また、前述のシナリオの組み合わせがあってもよい。例えば、意味論ノード２９１の自動更新が、意味論ノード２９１上の全ての意味論関連リソースについて周期的に起こる状況があってもよい一方で、意味論ノード２９２は、特定の加入先意味論関連リソースのためのより即時の更新を所望する。
意味論関連リソースのプッシュ配信は、いずれか一方の方向へ、同胞間で、親と子との間で起こることができる。例えば、図４６を参照すると、意味論ノード２９６は、あるローカル意味論関連リソースをその親意味論ノード２９７にプッシュ配信してもよい。別の実施例では、意味論ノード２９１は、ある高次意味論関連リソースを子意味論ノード２９８にプッシュ配信してもよい。
Ｇ．データ／意味論関連リソース移動
図４７は、デバイスが１つのネットワークから別のネットワークへ移動するシナリオを図示する。このシナリオでは、デバイスに関連する意味論リソース、およびデバイスによって生成されるデータもまた、意味論リソース読み出しによるセキュリティ、オーバーヘッド、および／または負荷のための新しい場所へ移動させられる必要があり得る。
図４７を参照すると、デバイスは、最初に、エリアネットワーク３０１内に位置していてもよいが、エリアネットワーク３０２へ移動している。最初に、デバイス３０９は、意味論ノード３０６と通信した。デバイス３０９がエリア３０２に到着した後、デバイス３０９は、最初に、線３０３によって実証されるように、意味論ノード３０６に通信し続けてもよい。これは、アクセスネットワーク３０４、アクセスネットワーク３０８、およびコアネットワーク３００で不必要なオーバーヘッドをもたらし得る。この問題および他の問題に対処するために、意味論ノード３０６の意味論関連リソースは、エリアネットワーク３０２内の意味論ノード３０７に移動させられてもよい。意味論関連リソースを意味論ノード３０７に移動させた後、デバイス３０９は、意味論関連リソースのためのコアネットワーク３００を横断する必要はないが、代わりに、線３０５によって示されるように、意味論ノード３０７と通信することができる。
図４８は、図４７で描写されるようなデータまたは意味論関連リソースの移動をさらに図示する、例示的メッセージフロー３１０である。ステップ３１５では、第１のエリアネットワーク内の意味論ノード３１１が、エリアネットワーク２内に位置するデバイスアプリケーション３１４とメッセージを交換する。ステップ３１５で交換されるメッセージは、例えば、意味論関連リソース読み出し要求および意味論関連リソース読み出し応答を含んでもよい。ステップ３１６では、意味論ノード３１１が、デバイスアプリケーション２１４と関連付けられる意味論関連リソースを、第２のエリアネットワーク内に位置する意味論ノード３１３に移動させることを決定する。意味論ノード３１３は、第１のエリアネットワークより通信的に近く（到達するためにより少ない時間を要する）、または論理的に近く（例えば、より少ないホップ）あり得る。ステップ３１６を参照すると、他のデバイスは、意味論ノード発見サーバ３１２、デバイスアプリケーション３１４、または別のコンピュータデバイス（図示せず）等の意味論関連リソースを移動させる決定を実施してもよい。
ステップ３１７では、意味論ノード発見要求および応答が、意味論ノードの階層ならびに同胞関係を構築するために、意味論ノード３１１と意味論ノード発見サーバ３１２との間で交換される。ステップ３１８では、意味論ノード３１１が、意味論ノード３１３のアドレスを判定する。ステップ３２０では、意味論関連リソース作成要求メッセージが、デバイスアプリケーション３１４によって使用される意味論関連リソース（および他のデータ）をコピーするために、意味論ノード３１３に送信される。意味論ノード３１３は、意味論関連リソースおよび他のデータのコピーが成功したという確認応答を含み得る、意味論関連リソース作成応答メッセージで応答する。ステップ３２１では、意味論連鎖更新要求メッセージが、デバイスアプリケーション３１４に送信される。ステップ３２１でのメッセージは、デバイスアプリケーション３１４が意味論ノード３１３から意味論関連リソースを取り出すための命令を含んでもよい。ステップ３２２では、意味論連鎖更新応答メッセージは、意味論ノード連鎖が更新されるという確認応答を含んでもよい。ステップ３２３では、デバイスアプリケーション３１４は、意味論ノード３１３から、クラス、関係、およびタームのタイプの意味論関連リソースを読み出す。
Ｖ．ＥＴＳＩ Ｍ２Ｍ／ｏｎｅＭ２Ｍ実施例
Ａ．意味論ノードを伴うＥＴＳＩ Ｍ２Ｍアーキテクチャ
上記のように、本明細書で説明される意味論ノード概念は、ＥＴＳＩ Ｍ２Ｍアーキテクチャを拡張するために使用することができる。以下の実施例（例えば、図４９−図５５）は、ＥＴＳＩ実施例であって、これらは、ｏｎｅＭ２Ｍアーキテクチャ同様に合理的にコンバート／実装されてもよいことに留意されたい。一実施例では、１つまたはそれを上回る意味論ノードは、図４９に示されるように、Ｍ２Ｍ意味論ノードと称され得る、独立型ネットワークエンティティとしてアクセス／コアネットワーク内に位置してもよい。図４９では、Ｍ２Ｍ意味論ノード３３１およびＭ２Ｍ意味論ノード３３２は、同一のアクセス／コアネットワーク３３０内に位置する。エリア／コアネットワーク３３０内のＭ２Ｍ意味論ノードは、上記で説明されるｓＩｃ基準点を介して、ＤＳＣＬ、ＧＳＣＬ、ＮＳＣＬ、およびアプリケーションと連動してもよい。加えて、Ｍ２Ｍ意味論ノード３３１およびＭ２Ｍ意味論ノード３３２は、ｓＩｓ基準点３３４を介して相互と連動してもよい。Ｍ２Ｍ意味論ノード３３１およびＭ２Ｍ意味論ノード３３２はまた、ｓＩｅ基準点を介して、別のタイプの外部意味論ノード３３３を参照してもよい。本実施例では、アクセス／コアネットワーク３３０内に位置するＭ２Ｍ意味論ノードはまた、同胞および／または親子関係を形成してもよい。
意味論ノードは、現在のＥＴＳＩ Ｍ２Ｍアーキテクチャのサービス能力層（ｘＳＣＬ）で使用されるような相補的リソース構造をサポートしてもよく、このリソース構造は、図５０で図示される様式で、本明細書で説明される意味論ノードに適用されてもよい。本実施例では、＜ｓｓＢａｓｅ＞リソース３４１は、ホスティング意味論ノード上に常駐するリソースツリーのルートである。＜ｓｓＢａｓｅ＞リソース３４１は、ホスティング意味論ノードを説明する属性を含有してもよい。＜ｓｓＢａｓｅ＞リソース３４１は、とりわけ、ＳＳリソース３４３、クラスリソース３４４、関係リソース３４６、タームリソース３４８、アクセス権リソース３４９、および加入リソース３５０の集合を表す、集合リソースを含有する。クラスリソース３４４の下には、クラスリソース３４４のサブクラスである、他の＜ｃｌａｓｓ＞リソース３４５があり得る。関係リソース３４６の下には、関係リソース３４６のサブ関係である、＜ｒｅｌａｔｉｏｎｓｈｉｐ＞リソース３４７があり得る。ＳＳリソース集合３４３は、遠隔意味論ノードがローカル意味論ノードに登録または登録解除するときに、作成または削除される意味論ノードリソースを含有する。
図５１に示されるように、ＳＳリソース３４３のための集合の中の各意味論ノードリソースは、対応するリソース構造を有してもよい。これらのリソースは、ローカル意味論ノードに登録された遠隔意味論ノードの状態を維持する。例えば、連絡先情報、発見情報（例えば、発表された意味クラス、表現、およびタームリソース）、およびセキュリティ情報（例えば、対応する遠隔意味論ノードと通信するために使用される信用証明）等の状態である。
図５０を再度参照すると、＜ｓｓＢａｓｅ＞リソース３４１の下のクラス３４４、関係３４６、およびターム３４８集合はそれぞれ、ローカル意味論ノード上でホストされる意味論関連リソースのそれぞれのインスタンスを含有することができる。各インスタンスは、意味表現を含有するとともに、タグ等の発見関連情報等のそれと関連付けられる他の属性を有することができる。意味論関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスすることができる。＜ｓｓＢａｓｅ＞リソース３４１の下のアクセス権リソース３４９は、アクセス権のインスタンスを含有することができる。これらのアクセス権リソース３４９は、どのクライアントが、意味論ノードによってサポートされるどの意味論関連リソースおよび動作へのアクセスを供与されるかを制御する、アクセス権のインスタンスを定義することができる。代替として、アクセス権集合の他のインスタンスは、より粒度の細かいアクセス制御を提供するようにリソース構造でサポートすることができる（図５０に示されていない）。加入リソース３５０の集合は、加入リソースのインスタンスを含有することができる。加入リソースのインスタンスは、特定通知トリガ基準イベントが起こるときに、意味論ノードから意味通知を受信することを希望するクライアントによって作成することができる。発見リソース３４２は、クライアント意味発見要求をサポートする。これらの発見要求は、検索基準（例えば、特定のタイプの属性を有する意味論関連リソース）をサポートすることができる。意味論ノードは、（存在する場合）検索基準に合致するリソースアドレス（例えば、ＵＲＩ）のリストで発見要求に応答することができる。意味論ノードはまた、他の意味論ノードへの要求の転送（例えば、子、同胞、または親意味論ノードへの発見要求の転送）をサポートすることもできる。
Ｂ．意味論能力を伴うｘＳＣＬ
図５２で図示される別の実施例では、Ｍ２Ｍ意味論ノードは、別個の独立型意味論ノードとしてよりも、ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、および／またはＮＳＣＬ内の組み込まれた能力として展開されてもよい。この組み込まれた実施例では、ｓＩｓ基準点は、別個のままであってもよく、またはＥＴＳＩ Ｍ２ＭｍＩｄ基準点は、ｓＩｓ機能性をサポートするように拡張させられてもよい。同様に、ｓＩｃ基準点は、別個のままであってもよく、またはＥＴＳＩ Ｍ２Ｍ ｍＩａおよびｄＩａ基準点は、ｓＩｃ機能性をサポートするように拡張させられてもよい。本実施例では、ＧＳＣＬまたはＤＳＣＬ内に位置するＭ２Ｍ意味論ノードは、それらが登録されるＮＳＣＬと親子関係を確立してもよい。加えて、ＧＳＣＬまたはＤＳＣＬ内に位置する意味論ノードはまた、相互と同胞関係を確立してもよい。
図５２の実施例をサポートするために、ｘＳＣＬは、図５３に示されるリソース構造を有してもよい。意味論ノードのリソース集合は、意味論ノード能力を有する遠隔ＳＣＬがローカルＳＣＬに登録または登録解除するときに作成または削除される、意味論ノードリソースを含有する。この集合の中の各意味論ノードリソースは、図５３に示される、対応するリソース構造を有してもよい。これらのリソースは、ローカルＳＣＬに登録される遠隔意味論ノードの状態を維持する。例えば、意味発見情報（例えば、発表された意味クラス、表現、およびタームリソース）等の状態である。
＜ｓｃｌＢａｓｅ＞リソース３６１の下のクラス、関係、およびターム集合はそれぞれ、ローカルＳＣＬ上でホストされる意味論関連リソースのそれぞれのインスタンスを含有してもよい。各インスタンスは、意味表現を含有するとともに、タグ等の発見関連情報等のそれと関連付けられる他の属性を有することができる。意味論関連リソースのこれらの集合は、そうするための適正なアクセス権を有するクライアントによってアクセスされてもよい。
Ｃ．ＥＴＳＩ Ｍ２Ｍ意味論実装の使用インスタンスの実施例
意味論ノードによって管理される意味論関連リソースは、＜ｓｃｌＢａｓｅ＞、＜ａｐｐｌｉｃａｔｉｏｎ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞、および同等物等のＥＴＳＩ Ｍ２Ｍリソース構造のリソースに関連付けられ、結び付けられてもよい。以下の議論は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞の意味情報を提供するために、どのようにして意味論関連リソースが使用され得るかを例証する。
本実施例では、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇクラスは、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｃｌａｓｓｅｓ／ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇというＵＲＩを有することを仮定されたい。ｈａｓＬｏｃａｔｉｏｎという関係も、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｒｅｌａｔｉｏｎｓｈｉｐｓ／ｈａｓＬｏｃａｔｉｏｎというＵＲＩを有する。加えて、‘ｎｏｒｔｈｅａｓｔＣｈｉｎａ’というタームも、ｓｃｌ１上で定義および記憶され、ｓｃｌ１／ｔｅｒｍｓ／ｎｏｒｔｈｅａｓｔＣｈｉｎａというＵＲＩを有する。図５４は、図５３に示されるｘＳＣＬリソース構造の実施例である、＜ｓｃｌ１＞上の意味論関連リソース構造を示す。このリソース構造は、意味論関連リソースのＵＲＩを判定する。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅは、ｇｓｃｌ２／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐ１／ｃｏｎｔａｉｎｅｒｓ／＜ｔｅｍｐｅｒａｔｕｒｅ＞／ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ／＜ｉｎｓｔ１＞というＵＲＩを有する。図５５のｘＳＣＬリソース構造で示されるような意味論を用いてｃｏｎｔｅｎｔＩｎｓｔａｎｃｅを拡張することによって、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのコンテンツを効果的に記述し、曖昧性を伴わずに解釈することができる。
図５６は、リソースおよび意味論読み出しの一実施例を図示する、メッセージフローである。ステップ３９３では、ＮＡ３９０が、データリソースについて、ＲＥＴＲＩＥＶＥ要求をＧＳＣＬ２ ３９１に送信する。データリソースは、例えば、とりわけ、血圧センサ示度値、中核体温センサ示度値、酸素飽和度センサ示度値、または運動加速度計センサ示度値であってもよい。ステップ３９４では、ＧＳＣＬ２ ３９１が、データリソースの表現を返信する。データリソースを理解するために、ＮＡは、データリソースの意味論を読み出しする必要がある。したがって、ステップ３９５では、ＮＡ３９０が、読み出し要求をＧＳＣＬ３９１に送信する。ステップ３９６では、ＧＳＣＬ２ ３９１が、ＳＣＬ１ ３９２上に記憶されるデータリソースに対する関連意味論関連リソースのＵＲＩのリストを返信する。ステップ３９７から３９９では、ＮＡ３９０が、それぞれ、ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ、ｈａｓＬｏｃａｔｉｏｎ、およびｎｏｒｔｈｅａｓｔＣｈｉｎａという意味論関連リソースについて、ＲＥＴＲＩＥＶＥメッセージをＳＣＬ１ ３９２と交換する。これらの意味論関連リソースにより、ＮＡ３９０は、データリソースを理解することができ、したがって、データリソースを使用および操作することができる。
ＶＩ．３ＧＰＰ ＭＴＣアーキテクチャ実施例
さらに上記のように、３ＧＰＰ ＭＴＣアーキテクチャは、本明細書で説明される意味論ノードによって提供される意味論サポートを用いて拡張させられてもよい。図５７に示されるように、一実施例では、Ｍ２Ｍ意味論ノード４０１は、３ＧＰＰコアネットワーク境界の外部に位置してもよい。さらに示されるように、ＳＣＳ４０４は、意味論能力をサポートするように拡張させられてもよく、かつｓＩｓ基準点（図示せず）を介してＭ２Ｍ意味論ノード４０１と連動してもよい。Ｍ２Ｍ意味論ノード４０１はまた、ｓＩｃ基準点４０３を介して、３ＧＰＰマシン型通信連動機能（ＭＴＣ−ＩＷＦ）４０２と連動してもよい。アプリケーションサーバ（ＡＳ）４０６およびＡＳ４０７は、ｓＩｃ基準点４００を介してＭ２Ｍ意味論ノード４０１と通信してもよい。図５８は、意味論ノードを伴う３ＧＰＰ ＭＴＣアーキテクチャの別の実施例を図示する。本実施例では、意味論ノードは、ＳＣＳ４０８に組み込まれている。図５８で４０９においてさらに示されるように、本実施例では、ｓＩｃ基準点は、３ＧＰＰ ＭＴＣ Ｔｓｐの一部であってもよい。
ｏｎｅＭ２Ｍ、３ＧＰＰ、およびＥＴＳＩ Ｍ２Ｍアーキテクチャが、本明細書で背景として説明され、以降で説明される種々の実施例を例証するために使用され得るが、本開示の範囲内にとどまりながら、以降で説明される実施例の実装が変動し得ることが理解される。当業者であれば、開示された実施例は、上記で議論される３ＧＰＰまたはＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されないが、むしろｏｎｅＭ２Ｍ、ＭＱＴＴ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステムで実装され得ることも認識するであろう。
図６０Ａは、図１２または図１１等の１つまたはそれを上回る開示された実施例が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であってもよい。
図６０Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ、または同等物）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー、または同等物）、あるいは異種ネットワークのネットワークであってもよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト、または同等物等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成ってもよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、および同等物等の１つまたはそれを上回るチャネルアクセス方法を採用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備えてもよい。
図６０Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含んでもよい。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常はＭ２Ｍゲートウェイの後ろにある、エリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信してもよい。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信してもよい。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービスプラットフォーム２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信されてもよい。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信してもよい。
図６０Ｂを参照すると、フィールドドメイン内に例証されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つまたはそれを上回るサーバ、コンピュータ、または同等物によって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装されてもよい。
図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および基礎的条件的通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用してもよい。Ｍ２Ｍサービス層２２’は、１つまたはそれを上回るサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）、または同等物によって実装されてもよい。
図６０Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。
いくつかの実施例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に論じられるように、オントロジパブリッシングメッセージを使用して通信する、所望のアプリケーションを含んでもよい。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含んでもよい。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。
本願のＭ２Ｍオントロジ管理は、サービス層の一部として実装されてもよい。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および基礎的条件的ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得る、デバイス、ゲートウェイ、またはサービス／プラットフォーム等のＭ２Ｍ機能的エンティティ）は、アプリケーションまたはサービスを提供してもよい。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本発明のＭ２Ｍオントロジ管理および意味論的相互運用性メッセージを含有し得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装されてもよい。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特有のノード）上でホストすることができる、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願のＭ２Ｍオントロジ管理および意味論的相互運用性メッセージは、本願のＭ２Ｍオントロジ管理および意味論的相互運用性メッセージのサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。
図６０Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図６０Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非可撤性メモリ４４と、可撤性メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。Ｍ２Ｍデバイス３０は、実施例と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、Ｍ２Ｍオントロジ管理および意味論的相互運用性のための開示されたシステムおよび方法を使用する、デバイスであってもよい。Ｍ２Ｍデバイス３０（例えば、ＭＯＰ７２１、ＯＤＣ７２３、ＯＰＣ７２６、ＯＣＣ７２４、ＯＲ７２７、ゲートウェイ７０４、周囲センサ７０６、血圧モニタ７０１、体重計７０２、パブリッシャ７４１、およびその他）は、Ｍ２Ｍオントロジ管理および意味論的相互運用性のための開示されるシステムおよび方法を実施する、例示的実装であり得る。
プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械、および同等物であってもよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ３２は、伝送／受信要素３６に結合され得る、送受信機３４に結合されてもよい。図６０Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を実施してもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を実施してもよい。
伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成されてもよい。例えば、実施例では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー、および同等物等の種々のネットワークおよびエアインターフェースをサポートしてもよい。実施例では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。さらに別の実施例では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成されてもよい。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
加えて、伝送／受信要素３６は、単一の要素として図６０Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含んでもよい。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用してもよい。したがって、実施例では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含んでもよい。
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成されてもよい。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有してもよい。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。
プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。プロセッサ３２は、本明細書に説明される実施例のうちのいくつかでは、Ｍ２Ｍオントロジ管理メッセージ（例えば、オントロジを互換性のあるメッセージにコンバートする）が、成功もしくは不成功（例えば、例外ハンドリング（ＥＨＲ）、ＳＬＭＰ、もしくはリンクプロファイル提出等）であるかどうかに応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御する、または別様に、ＯＰＣ７２６、ＯＣＣ７２４、ＯＲ７２７、ＯＤＣ７２３のステータス、もしくは本明細書におけるプロセスおよびコンポーネントと関連付けられた他の意味論を示すように構成されてもよい。例えば、同様に、図２０から図２３において本明細書に説明されるように、ディスプレイ上のオントロジの編成である。ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色の制御は、図に図示される、または本明細書で論じられる（例えば、図１１から図６１等）、方法フローまたはコンポーネントのいずれかのステータスを反映してもよい。本明細書に開示されるのは、Ｍ２Ｍオントロジ管理および意味論的相互運用性のメッセージおよびプロシージャである。メッセージおよびプロシージャは、ディスプレイ４２上に表示され得る、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、リソース関連リソースを要求し、とりわけＭ２Ｍオントロジ管理および意味論的相互運用性のためのリソースを要求、構成、またはクエリするためのインターフェース／ＡＰＩを提供するように拡張されることができる。
プロセッサ３２は、電源４８から電力を受容してもよく、Ｍ２Ｍデバイス３０内の他のコンポーネントへの電力を分配および／または制御するように構成されてもよい。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。
プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に結合されてもよい。Ｍ２Ｍデバイス３０は、実施例と一致したままで、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ３２はさらに、付加的な特徴、機能性、および／または有線あるいは無線接続を提供する、１つまたはそれを上回るソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に結合されてもよい。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および同等物を含んでもよい。
図６０Ｄは、例えば、図６０Ａおよび６０ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備えてもよく、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ可読命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行されてもよい。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、オントロジパブリッシングメッセージの受信等、Ｍ２Ｍオントロジ管理および意味論的相互運用性のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理してもよい。
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送経路であるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。
システムバス８０に結合されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読取専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含有する。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供してもよい。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含有してもよい。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでもよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。
さらに、コンピュータシステム９０は、図６０Ａおよび６０Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含有してもよい。
図６１は、本明細書で論じられる方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。ディスプレイインターフェース１（例えば、タッチスクリーンディスプレイ）は、ブロック２に、表１から１５のパラメータ等、Ｍ２Ｍオントロジおよび意味論と関連付けられたテキストを提供してもよい。別の実施例では、本明細書で論じられるステップのいずれかの進捗度（例えば、送信されたメッセージまたはステップの成功）が、ブロック２に表示されてもよい。加えて、グラフィカル出力３が、ディスプレイインターフェース１上に表示されてもよい。グラフィカル出力３は、オントロジのトポロジ、本明細書で論じられる任意の方法もしくはシステムの進捗度のグラフィカル出力、または同等物であってもよい。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス、または同等物等の機械によって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装される、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。
図で図示されるような本開示の主題の好ましい実施例を説明する際に、明確にするために、特定のタームが採用される。しかしながら、請求された主題は、そのように選択された特定のタームに限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。意味論関連リソースは、オントロジ（オントロジは、クラス、関係、およびタームから成り得る）、または独立クラス、関係、タームであることができる。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含んでもよい（例えば、本明細書に開示される例示的方法間のステップのスキップ、組み合わせステップ、または追加ステップ）。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。

Claims (20)

  1. デバイスであって、
    プロセッサと、
    前記プロセッサと結合されるメモリであって、前記メモリは、前記プロセッサによって実行されると、前記プロセッサに、
    オントロジパブリッシングメッセージを受信するステップであって、前記オントロジパブリッシングメッセージは、第１の名前空間からの第１のオントロジを含む、ステップと、
    前記オントロジパブリッシングメッセージに基づいて、前記第１のオントロジが第２の名前空間のためのフォーマットと互換性がないことを判定するステップと、
    前記第１のオントロジが前記第２の名前空間のためのフォーマットと互換性がないことの判定に応答して、前記第１のオントロジを互換性のあるフォーマットにコンバートするステップと、
    を含む、動作をもたらさせる、実行可能命令を含む、メモリと、
    を備える、デバイス。
  2. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの名前のインジケーションおよび前記第１のオントロジの名前空間のインジケーションを含む、請求項１に記載のデバイス。
  3. 前記オントロジパブリッシングメッセージは、前記第１のオントロジのアクセス権を含み、前記アクセス権は、当事者によって前記第１のオントロジにアクセスするための能力のインジケーションを含む、請求項１に記載のデバイス。
  4. 前記オントロジパブリッシングメッセージは、前記第１のオントロジが関連するトピックを含む、請求項１に記載のデバイス。
  5. 前記オントロジパブリッシングメッセージは、前記第１のオントロジと別のオントロジの関連性のインジケーションを含む、請求項１に記載のデバイス。
  6. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの表現にリンクする、ユニバーサルリソースインジケータを含む、請求項１に記載のデバイス。
  7. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの表現としてのスキーマを含む、請求項１に記載のデバイス。
  8. さらなる動作として、ディスプレイデバイスに前記コンバートされた第１のオントロジを表示させる命令を提供するステップを含む、請求項１に記載のデバイス。
  9. 方法であって、
    オントロジパブリッシングメッセージを受信するステップであって、前記オントロジパブリッシングメッセージは、第１の名前空間からの第１のオントロジを含む、ステップと、
    前記オントロジパブリッシングメッセージに基づいて、前記第１のオントロジが第２の名前空間のためのフォーマットと互換性がないことを判定するステップと、
    前記第１のオントロジが前記第２の名前空間のためのフォーマットと互換性がないことの判定に応答して、前記第１のオントロジを互換性のあるフォーマットにコンバートするステップと、
    を含む、方法。
  10. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの名前のインジケーションおよび前記第１のオントロジの名前空間のインジケーションを含む、請求項９に記載の方法。
  11. 前記オントロジパブリッシングメッセージは、前記第１のオントロジのアクセス権を含み、前記アクセス権は、当事者によって前記第１のオントロジにアクセスするための能力のインジケーションを含む、請求項９に記載の方法。
  12. 前記オントロジパブリッシングメッセージは、前記第１のオントロジが関連するトピックを含む、請求項９に記載の方法。
  13. 前記オントロジパブリッシングメッセージは、前記第１のオントロジと別のオントロジの関連性のインジケーションを含む、請求項９に記載の方法。
  14. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの表現にリンクする、ユニバーサルリソースインジケータを含む、請求項９に記載の方法。
  15. 前記オントロジパブリッシングメッセージは、前記第１のオントロジの表現としてのスキーマを含む、請求項９に記載の方法。
  16. ディスプレイデバイスに前記コンバートされた第１のオントロジを表示させる命令を提供するステップをさらに含む、請求項９に記載の方法。
  17. オントロジレポジトリコンポーネントを使用したマシンツーマシン（Ｍ２Ｍ）オントロジ処理のためのデバイスであって、
    プロセッサと、
    前記プロセッサと結合されるメモリであって、前記メモリは、前記プロセッサによって実行されると、前記プロセッサに、
    Ｍ２Ｍ準拠オントロジを受信するステップと、
    前記オントロジを分類するステップと、
    前記オントロジを記憶するための階層を判定するステップと、
    前記オントロジの基礎的条件を抽出するステップと、
    前記オントロジの基礎的条件を記憶するステップと、
    を含む、動作をもたらさせる、実行可能命令を含む、メモリと、
    を備える、デバイス。
  18. 前記階層は、名前空間、オントロジ、および基礎的条件を含む、請求項１７に記載のデバイス。
  19. さらなる動作として、
    外部オントロジを互換性のあるフォーマットにコンバートするステップと、
    前記オントロジと複数のオントロジを関連付けるステップと、
    を含む、請求項１７に記載のデバイス。
  20. さらなる動作として、ディスプレイデバイスに前記オントロジの記憶された基礎的条件を表示させる命令を提供するステップを含む、請求項１７に記載のデバイス。
JP2017502692A 2014-07-18 2015-07-17 Ｍ２ｍオントロジ管理および意味論的相互運用性 Expired - Fee Related JP6482645B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462026569P 2014-07-18 2014-07-18
US62/026,569 2014-07-18
PCT/US2015/040921 WO2016011361A1 (en) 2014-07-18 2015-07-17 M2m ontology management and semantics interoperability

Publications (2)

Publication Number Publication Date
JP2017527016A true JP2017527016A (ja) 2017-09-14
JP6482645B2 JP6482645B2 (ja) 2019-03-13

Family

ID=53762383

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017502692A Expired - Fee Related JP6482645B2 (ja) 2014-07-18 2015-07-17 Ｍ２ｍオントロジ管理および意味論的相互運用性

Country Status (6)

Country Link
US (1) US20160019294A1 (ja)
EP (1) EP3170111B1 (ja)
JP (1) JP6482645B2 (ja)
KR (1) KR20170035961A (ja)
CN (1) CN106663143B (ja)
WO (1) WO2016011361A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200098380A (ko) * 2019-02-11 2020-08-20 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 지식 베이스 관리 방법, 장치, 기기 및 매체

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9553843B1 (en) * 2014-10-08 2017-01-24 Google Inc. Service directory profile for a fabric network
CN105610880B (zh) * 2014-11-10 2020-06-16 中兴通讯股份有限公司 M2m通信架构、信息交互方法及装置
WO2016128415A1 (en) * 2015-02-09 2016-08-18 Eurotech S.P.A. System and method for the data management in the interaction between machines
KR102046700B1 (ko) * 2015-02-20 2019-11-19 콘비다 와이어리스, 엘엘씨 메시지 버스 서비스 디렉토리
WO2017024227A1 (en) * 2015-08-06 2017-02-09 Convida Wireless, Llc Mechanisms for multi-dimension data operations
CN106919550B (zh) * 2015-12-25 2021-09-07 华为技术有限公司 一种语义验证的方法和装置
WO2017117345A1 (en) * 2015-12-30 2017-07-06 Convida Wireless, Llc Semantics based content specification of iot data
KR101707446B1 (ko) * 2016-01-29 2017-02-16 계명대학교 산학협력단 ISO/IEEE 11073 표준 프로토콜과 oneM2M 표준 프로토콜 간의 변환 방법
KR102169930B1 (ko) * 2016-05-05 2020-10-26 한국전자기술연구원 M2M/IoT 플랫폼에서의 시맨틱 정보 관리 방법
US10964430B2 (en) * 2016-05-12 2021-03-30 Surescripts LLC System and method for determining computer system compatibility
CN107484211B (zh) 2016-06-08 2020-06-26 华为技术有限公司 切换接入点的方法及装置
US10635704B2 (en) 2016-07-15 2020-04-28 Cisco Technology, Inc. Automatic ontology generation for internet of things applications
EP4099186A1 (en) * 2016-09-19 2022-12-07 Northrup, Charles Thing machine
US20180089316A1 (en) 2016-09-26 2018-03-29 Twiggle Ltd. Seamless integration of modules for search enhancement
US10067965B2 (en) 2016-09-26 2018-09-04 Twiggle Ltd. Hierarchic model and natural language analyzer
US10826778B2 (en) * 2016-12-06 2020-11-03 Sap Se Device discovery service
US10719534B2 (en) * 2017-02-02 2020-07-21 General Electric Company Rollup engine for internet of things
US11178523B2 (en) * 2017-02-22 2021-11-16 Telefonaktiebolaget Lm Ericsson (Publ) First communication device, network device and methods therein for indentifying at least one second communication device providing a semantic representation
US11290860B2 (en) * 2017-06-20 2022-03-29 Samsung Electronics Co., Ltd. Method for processing request message in M2M system and device therefor
CN109246660B (zh) 2017-06-30 2020-05-08 华为技术有限公司 一种管理本体的方法以及m2m平台
CN109218142A (zh) * 2017-06-30 2019-01-15 中兴通讯股份有限公司 一种基于OneM2M协议物联网平台终端接入方法和装置
WO2019001445A1 (zh) * 2017-06-30 2019-01-03 华为技术有限公司 一种管理本体的方法以及m2m平台
EP3457408B1 (en) * 2017-09-19 2021-09-15 Siemens Healthcare GmbH Healthcare network
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
KR102309171B1 (ko) * 2017-12-05 2021-10-06 한국전자기술연구원 M2m 플랫폼의 리소스 미러링 방법
CN108040042B (zh) * 2017-12-05 2020-07-03 重庆邮电大学 一种针对多播情况下CoAP协议的安全方法
US10862971B2 (en) 2018-04-27 2020-12-08 EMC IP Holding Company LLC Internet of things gateway service for a cloud foundry platform
DE102018113082A1 (de) * 2018-05-31 2019-12-05 Atos Information Technology GmbH System von dynamisch verwalteten / selbstorganisierenden Objektnetzwerken
CN108848159A (zh) * 2018-06-14 2018-11-20 电子科技大学 一种物联网设备互操作调度方法
US10715640B2 (en) * 2018-07-13 2020-07-14 EMC IP Holding Company LLC Internet of things gateways of moving networks
CN109063114B (zh) * 2018-07-27 2020-11-24 华南理工大学广州学院 能源云平台的异构数据集成方法、装置、终端及存储介质
CN109257437A (zh) * 2018-10-23 2019-01-22 河北地质大学 基于互联网的科技管理用信息发布系统及方法
CN112997170A (zh) * 2018-11-20 2021-06-18 西门子股份公司 用于将用于自动化目的的数据模型变换成目标本体的方法
JP7059916B2 (ja) * 2018-12-18 2022-04-26 日本電信電話株式会社 情報処理システム、方法およびプログラム
EP4254086A1 (en) * 2022-03-31 2023-10-04 Siemens Aktiengesellschaft Transforming an ontology into a graph-based information model for automation purposes
TWI799349B (zh) * 2022-09-15 2023-04-11 國立中央大學 利用本體論整合城市模型及物聯網開放式標準之智慧城市應用方法
US11893037B1 (en) 2022-09-24 2024-02-06 Bank Of America Corporation Dynamic code generation utility with configurable connections and variables

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003196276A (ja) * 2001-12-28 2003-07-11 Toshiba Corp 他言語オントロジー辞書利用装置及び方法並びにプログラム
JP2004102790A (ja) * 2002-09-11 2004-04-02 Nippon Telegr & Teleph Corp <Ntt> オントロジー変換装置、オントロジー変換方法、オントロジー変換プログラムおよび記録媒体
JP2005100612A (ja) * 2003-09-15 2005-04-14 Microsoft Corp グローバル関連プレイリストを作成及び再生するシステム及び方法
JP2010079857A (ja) * 2008-09-29 2010-04-08 Toshiba Corp 構造化データ検索プログラム及び構造化データ検索装置
US20100175054A1 (en) * 2009-01-06 2010-07-08 Katarina Matusikova System and method for transforming a uml model into an owl representation
JP2012128509A (ja) * 2010-12-13 2012-07-05 Nippon Hoso Kyokai <Nhk> 概念処理装置及びプログラム

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003211000A1 (en) * 2002-02-12 2003-09-04 Sandpiper Software, Inc. Ontology frame-based knowledge representation in the unified modeling language (uml)
WO2003077079A2 (en) * 2002-03-08 2003-09-18 Enleague Systems, Inc Methods and systems for modeling and using computer resources over a heterogeneous distributed network using semantic ontologies
US20040117346A1 (en) * 2002-09-20 2004-06-17 Kilian Stoffel Computer-based method and apparatus for repurposing an ontology
US7761480B2 (en) * 2003-07-22 2010-07-20 Kinor Technologies Inc. Information access using ontologies
US7433876B2 (en) * 2004-02-23 2008-10-07 Radar Networks, Inc. Semantic web portal and platform
US7383260B2 (en) * 2004-08-03 2008-06-03 International Business Machines Corporation Method and apparatus for ontology-based classification of media content
KR100685791B1 (ko) * 2004-12-13 2007-02-22 한국전자통신연구원 자연어를 온톨로지 기반 지식으로 변환하는 방법 및 장치
KR100727032B1 (ko) * 2005-11-08 2007-06-12 한국전자통신연구원 상황 인식 시스템에서 상황 지식의 공유와 재사용을 위한상황 지식 모델링 방법
WO2008146807A1 (ja) * 2007-05-31 2008-12-04 Nec Corporation オントロジ処理装置、オントロジ処理方法、及びオントロジ処理プログラム
US8010567B2 (en) * 2007-06-08 2011-08-30 GM Global Technology Operations LLC Federated ontology index to enterprise knowledge
US20090077094A1 (en) * 2007-09-17 2009-03-19 Yan Bodain Method and system for ontology modeling based on the exchange of annotations
US8140680B2 (en) * 2008-01-09 2012-03-20 International Business Machines Corporation Machine-processable semantic description for resource management
US20090177634A1 (en) * 2008-01-09 2009-07-09 International Business Machine Corporation Method and System for an Application Domain
CN101373380B (zh) * 2008-07-14 2011-06-15 浙江大学 一种仿人机器人控制系统及机器人操纵方法
US8145333B2 (en) * 2008-12-01 2012-03-27 Rockwell Automation Technologies, Inc. Ontology-based system and method for industrial control
US8214401B2 (en) * 2009-02-26 2012-07-03 Oracle International Corporation Techniques for automated generation of ontologies for enterprise applications
EP2246810A1 (en) * 2009-04-30 2010-11-03 Collibra NV/SA Method for ontology evolution
US8484141B2 (en) * 2010-02-02 2013-07-09 International Business Machines Corporation Evaluating ontologies
US20120131168A1 (en) * 2010-11-22 2012-05-24 Telefonaktiebolaget L M Ericsson (Publ) Xdms for resource management in m2m
EP2469421A1 (en) * 2010-12-23 2012-06-27 British Telecommunications Public Limited Company Method and apparatus for processing electronic data
EP2854423B1 (en) * 2011-02-11 2019-10-23 IOT Holdings, Inc. Systems, methods and apparatus for managing machine-to-machine (M2M) entities
KR101229274B1 (ko) * 2011-03-31 2013-02-04 인하대학교 산학협력단 대용량 온톨로지의 효율적인 저장 및 유지관리를 위한 관계형 데이터베이스 기반저장소, 검색방법 및 이를 이용하여 컴퓨터에 검색을 실행시키는 프로그램을 기록한 컴퓨터로 판독 가능한 기록매체
US20120330869A1 (en) * 2011-06-25 2012-12-27 Jayson Theordore Durham Mental Model Elicitation Device (MMED) Methods and Apparatus
US8856169B2 (en) * 2011-07-13 2014-10-07 Case Western Reserve University Multi-modality, multi-resource, information integration environment
US9894457B2 (en) * 2012-02-03 2018-02-13 Interdigital Patent Holdings, Inc. Method and apparatus to support M2M content and context based services
CN102581745B (zh) * 2012-02-29 2014-09-10 清华大学 一种化学机械抛光传输机器人系统
US20140207776A1 (en) * 2013-01-22 2014-07-24 Maluuba Inc. Method and system for linking data sources for processing composite concepts
EP2941725B1 (en) * 2013-02-18 2020-05-06 Nec Corporation Method and system for semantically querying a database by a machine-to-machine application
EP2959383A1 (en) * 2013-02-19 2015-12-30 Interdigital Patent Holdings, Inc. Information modeling for the future internet of things
CN103147789B (zh) * 2013-03-07 2015-03-25 中国矿业大学 煤矿井下救援机器人控制系统及控制方法
CN105556513A (zh) * 2013-03-14 2016-05-04 昂托米克斯公司 用于个性化临床决策支持工具的系统和方法
US10503795B2 (en) * 2013-04-02 2019-12-10 Nec Corporation Method and system for managing data
EP2995100B1 (en) * 2013-05-06 2021-07-28 Convida Wireless, LLC Semantics support and management in m2m systems
CN105453085B (zh) * 2013-07-02 2021-02-02 康维达无线有限责任公司 语义发布和发现的机制
US10235681B2 (en) * 2013-10-15 2019-03-19 Adobe Inc. Text extraction module for contextual analysis engine
US9380060B2 (en) * 2013-12-27 2016-06-28 Verizon Patent And Licensing Inc. Machine-to-machine service based on common data format
US9684708B2 (en) * 2014-02-21 2017-06-20 International Business Machines Corporation Representing a machine-to-machine device model based on ontological relationships

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003196276A (ja) * 2001-12-28 2003-07-11 Toshiba Corp 他言語オントロジー辞書利用装置及び方法並びにプログラム
JP2004102790A (ja) * 2002-09-11 2004-04-02 Nippon Telegr & Teleph Corp <Ntt> オントロジー変換装置、オントロジー変換方法、オントロジー変換プログラムおよび記録媒体
JP2005100612A (ja) * 2003-09-15 2005-04-14 Microsoft Corp グローバル関連プレイリストを作成及び再生するシステム及び方法
JP2010079857A (ja) * 2008-09-29 2010-04-08 Toshiba Corp 構造化データ検索プログラム及び構造化データ検索装置
US20100175054A1 (en) * 2009-01-06 2010-07-08 Katarina Matusikova System and method for transforming a uml model into an owl representation
JP2012128509A (ja) * 2010-12-13 2012-07-05 Nippon Hoso Kyokai <Nhk> 概念処理装置及びプログラム

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
LUIS IRIBARNE, ET AL.: "Open-Environmental Ontology Modeling", IEEE TRANSACTIONS ON SYSTEMS, MAN AND CYBERNETICS - PART A: SYSTEMS AND HUMANS, vol. 41, no. 4, JPN6018005981, July 2011 (2011-07-01), pages 730 - 745, XP011366649, DOI: doi:10.1109/TSMCA.2011.2132706 *
古崎 晃司ほか: "オントロジー利用研究の事例分析", 言語処理学会第１３回年次大会ワークショップ「言語的オントロジーの構築・連携・利用」論文集, JPN6018005982, 19 March 2007 (2007-03-19), JP, pages ｐ．１−９ *
石榑 康雄: "Ｍ２Ｍ時代の医療・健康ＩＣＴ", 電子情報通信学会誌, vol. 第９６巻 第５号, JPN6018031842, 1 May 2013 (2013-05-01), JP, pages ｐ．３１３−３１７ *
辻 秀一ほか: "Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）技術の動向", 電気学会論文誌Ｃ 電子・情報・システム部門誌, vol. Ｖｏｌ．１３３ Ｎｏ．３, JPN6018031843, 1 March 2013 (2013-03-01), JP, pages ｐ．５２０−５３１ *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200098380A (ko) * 2019-02-11 2020-08-20 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 지식 베이스 관리 방법, 장치, 기기 및 매체
KR102438812B1 (ko) 2019-02-11 2022-08-31 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 지식 베이스 관리 방법, 장치, 기기 및 매체
US11900269B2 (en) 2019-02-11 2024-02-13 Beijing Baidu Netcom Science And Technology Co., Ltd. Method and apparatus for managing knowledge base, device and medium

Also Published As

Publication number Publication date
KR20170035961A (ko) 2017-03-31
JP6482645B2 (ja) 2019-03-13
EP3170111B1 (en) 2021-10-27
WO2016011361A1 (en) 2016-01-21
CN106663143A (zh) 2017-05-10
US20160019294A1 (en) 2016-01-21
CN106663143B (zh) 2019-12-17
EP3170111A1 (en) 2017-05-24
WO2016011361A8 (en) 2017-01-12

Similar Documents

Publication Publication Date Title
JP6482645B2 (ja) Ｍ２ｍオントロジ管理および意味論的相互運用性
US11741138B2 (en) Enabling resource semantics
JP6510023B2 (ja) Ｍ２ｍシステムにおけるセマンティクスサポートおよび管理
US10635663B2 (en) Mechanisms for semantics publishing and discovery
JP6454787B2 (ja) Ｍ２ｍシステムのためのセマンティクス注釈およびセマンティクスリポジトリ

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180221

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180223

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180518

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180816

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181116

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181212

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20190111

R155 Notification before disposition of declining of application

Free format text: JAPANESE INTERMEDIATE CODE: R155

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190212

R150 Certificate of patent or registration of utility model

Ref document number: 6482645

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees