JP7038113B2 - モノのインターネットにおけるセマンティックマッシュアップの許可 - Google Patents

モノのインターネットにおけるセマンティックマッシュアップの許可 Download PDF

Info

Publication number
JP7038113B2
JP7038113B2 JP2019516962A JP2019516962A JP7038113B2 JP 7038113 B2 JP7038113 B2 JP 7038113B2 JP 2019516962 A JP2019516962 A JP 2019516962A JP 2019516962 A JP2019516962 A JP 2019516962A JP 7038113 B2 JP7038113 B2 JP 7038113B2
Authority
JP
Japan
Prior art keywords
mashup
resource
semantic
sms
host
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.)
Active
Application number
JP2019516962A
Other languages
English (en)
Other versions
JP2020502610A (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 JP2020502610A publication Critical patent/JP2020502610A/ja
Application granted granted Critical
Publication of JP7038113B2 publication Critical patent/JP7038113B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)

Description

（関連出願の相互参照）
本出願は、「M2M／IOTサービスレイヤにおけるセマンティックマッシュアップの許可方法」と題する２０１６年９月２９日出願の米国仮特許出願第６２／４０１，４６１号の利益を主張する。その内容は本明細書に参照により組み込まれる。
セマンティックウェブは、ワールドワイドウェブコンソーシアム（World Wide Web Consortium:W3C）による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク（Resource Description Framework:RDF）を促進する。
セマンティックウェブは、データのために特に設計された言語、すなわちリソース記述フレームワーク（RDF）、ウェブオントロジー言語（Web Ontology Language:OWL）、および拡張可能なマークアップ言語（Extensible Markup Language:XML）でパブリッシュすることを伴う。これらの技術を組み合わせて、リンクされたデータのウェブを介してウェブ文書のコンテンツを補足または置換する記述を提供する。したがって、コンテンツはそれ自身を、ウェブアクセス可能データベース内に記憶される記述データとして、または特に、XMLが組み込まれた拡張HTML（Extensible HTML:XHTML）文書、もしくはより多くの場合、別個に記憶されるレイアウトまたはレンダリングの指図を伴う純粋なXML文書におけるマークアップとして現し得る。
セマンティックウェブスタックは、図１に示されるように、W3Cによって規定されたセマンティックウェブのアーキテクチャを例示する。コンポーネントの機能および関係は、以下のように要約することができる。
XMLは、文書内のコンテンツ構造のための基本的な構文を提供するが、その中に含まれるコンテンツの意味にセマンティクスを関連付けしない。Turtle等の代替構文が存在するため、XMLは現在、ほとんどの場合でセマンティックウェブ技術に必要なコンポーネントではない。Turtleは事実上の業界標準だが、正式な標準化プロセスを経ていない。
XMLスキーマは、XML文書内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。
W3C技術スタック例に記述されるRDFは、単純なデータモデルであり、データモデルは、主語－述語－目的語、例えば、S-P-OトリプルまたはRDFトリプルの形態でオブジェクト（「ウェブリソース」）およびその関係を参照する。RDFベースのモデルは、種々の構文、例えば、RDF/XML、N3、TurtleおよびRDFaで表され得る。RDFは、セマンティックウェブの基本的な規格である。
RDFグラフは、エッジがRDFトリプルの「述語」を表すのに対し、グラフのノードは、RDFトリプルの「主語」または「目的語」を表す有向グラフである。すなわち、RDFトリプルに記述されるリンク構造は、そのような有向RDFグラフを形成する。
RDFスキーマ［RDF Schema 1.1］は、プロパティおよびクラスの一般化された階層のためのセマンティクスを用いてRDFベースのリソースのプロパティおよびクラスを記述するための語彙であり、RDFを拡張する。
OWL［OWL 2 Web Ontology Language Document Overview,http://www.w3.org/TR/owl-overview/］は、プロパティおよびクラス、とりわけ、クラス間の関係（例えば、離接）、基数（例えば、「正確に１つ」）、相等性、より豊富なタイプのプロパティ、プロパティの特性（例えば、対称性）、および列挙されたクラスを記述するために、より多くの語彙を追加する。
SPARQL［SPARQL 1.1 Overview，http://www.w3.org/TR/sparql11-overview/］は、ウェブ上またはRDFストア（例えば、セマンティックグラフストア）においてRDFグラフのコンテンツ（例えば、RDFトリプル）をクエリおよび操作するための、セマンティックウェブデータソースのためのプロトコルおよびクエリ言語である。
SPARQL1.1クエリは、RDFグラフのためのクエリ言語であり、データがRDFとしてネイティブに記憶されているか、またはミドルウェアを介してRDFとして見なされるかにかかわらず、多様なデータソースにわたるクエリを表すために使用され得る。SPARQLは、その積および和と一緒に、必要とされるグラフパターンおよび随意のグラフパターンをクエリするための機能を含む。SPARQLは、集約、サブクエリ、否定、式による値の作成、拡張値試験、およびソースRDFグラフによるクエリの制約もサポートする。SPARQLクエリの結果は、結果のセットまたはRDFグラフであり得る。
SPARQL1.1更新は、RDFグラフのための更新言語である。SPARQL1.1更新は、RDFのためにSPARQLクエリ言語由来の構文を使用する。更新動作は、セマンティックグラフストアにおけるグラフの集合に対して行われる。動作は、セマンティックグラフストア内のRDFグラフを更新、作成、および除去するために提供される。
RIFは、W3Cルール交換フォーマットである。RIFは、コンピュータが実行可能なウェブルールを表すためのXML言語である。RIFは、ダイアレクトと呼ばれる複数のバージョンを提供する。ダイアレクトは、RIF基本論理ダイアレクト（RIF Basic Logic Dialect:RIF-BLD）およびRIF生成ルールダイアレクト（RIF Production Rules Dialect:RIF PRD）を含む。
セマンティック検索は、検索者の意図と、ウェブ上であるかクローズドシステム内でるかにかかわらず、検索可能なデータ空間内に現れるときの文脈上の意味とを理解することによって検索精度を改善して、より関連性の高い結果を生成しようとする。セマンティック検索システムは、検索の文脈、場所、意図、ならびに単語、同義語、一般化および特殊クエリ、概念一致、および自然言語クエリの変形例を含む種々の点を考慮し、関連する検索結果を提供する。GoogleおよびBingのような主要なウェブ検索エンジンは、セマンティック検索のいくつかの要素を取り込んでいる。セマンティック検索は、セマンティクス、すなわち、言語における意味の科学を使用して、非常に関連性の高い検索結果を生成する。ほとんどの場合、その目標は、大まかに関連したキーワード結果のリストをユーザに分類させるのではなく、ユーザがクエリした情報を届けることである。例えば、セマンティクスは、階層関係データベース内の記録検索またはクエリを強化するために使用され得る。
セマンティッククエリは、連想的および文脈的性質のクエリおよび分析を可能にする。セマンティッククエリは、データ内に含まれる構文情報、セマンティック情報および構造情報に基づいて、明示的に導かれる情報および暗示的に導かれる情報の両方の探索を可能にする。セマンティッククエリは、正確な結果（おそらく、ただ１つの情報の独特の選択）を届けるように、またはパターン照合およびデジタル推論を通してよりファジィかつ制限のない質問に回答するように設計される。
セマンティッククエリは、名前付きグラフ、リンクされたデータまたはトリプルに働きかける。このことにより、クエリが、情報間の実際の関係を処理し、データのネットワークからの回答を推論することを可能にする。これは、セマンティック検索とは対照的であり、セマンティック検索は、セマンティック（意味の科学）を非構造化されたテキストにおいて使用し、より良好な検索結果を生成する（例えば、自然言語処理）。
技術的観点から、セマンティッククエリは、データベースクエリとよく似た正確なリレーション型の動作である。セマンティッククエリは、構造化されたデータに働きかける。したがって、演算子（例えば、＞、＜、および＝）、名前空間、パターン照合、サブクラス化、推移関係、セマンティックルール、および文脈全文検索のような広範囲の特徴を利用する可能性を有する。W3Cのセマンティックウェブ技術スタックは、セマンティッククエリをSQLに類似した構文で公式化するためのSPARQLを提供する。セマンティッククエリは、トリプルストア、グラフデータベース、セマンティックウィキ、自然言語および人工知能システムにおいて使用される。
セマンティッククエリの別の重要な側面は、関係のタイプをシステムへの知能の組み込みに使用し得ることである。顧客と製品との関係は、近隣地域とその都市との関係とは基本的に異なる性質を有する。後者は、セマンティッククエリエンジンが、マンハッタンに住んでいる顧客がニューヨーク市にも住んでいることを推論することを可能にする一方、他の関係は、より複雑なパターンおよび「文脈分析」を有し得る。このプロセスは、推測または推論と呼ばれ、所与の事実に基づいて新しい情報を導くくめのソフトウェアの能力である。
oneM2M機能アーキテクチャは、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0およびそのセマンティック機能のサポートに指定されている。開発中のoneM2M規格は、「共通サービスエンティティ（Common Service Entity:CSE）」と呼ばれるサービスレイヤを定義する。サービスレイヤの目的は、異なる「垂直」M2Mシステムおよびアプリケーションによって利用可能な「水平」サービスを提供することである。CSEは、図２に示されるように、４つの参照点をサポートする。Mca参照点は、アプリケーションエンティティ（Application Entity:AE）とインタフェースをとる。Mcc参照点は、同一サービスプロバイダドメイン内の別のCSEとインタフェースをとり、Mcc’参照点は、異なるサービスプロバイダドメイン内の別のCSEとインタフェースをとる。Mcn参照点は、下層ネットワークサービスエンティティ（Network Service Entity:NSE）とインタフェースをとる。NSEは、デバイス管理、場所サービスおよびデバイストリガ等の下層ネットワークサービスをCSEに提供する。
CSEは、「発見」、「データ管理およびリポジトリ」等の「共通サービス機能（Common Service Function:CSF）」と呼ばれる、複数の論理機能を含む。図３は、oneM2Mによって規定されるCSFをいくつか図示している。
oneM2Mアーキテクチャは、図２に示すように以下のタイプのノードを可能にする。アプリケーションサービスノード（Application Service Node:ASN）：ASNは、１つのCSEを含み、少なくとも１つのアプリケーションエンティティ（AE）を含むノードである。物理的マッピングの例：ASNは、M2Mデバイス内に常駐し得る。アプリケーション専用ノード（Application Dedicated Node:ADN）：ADNは、少なくとも１つのAEを含むが、CSEを含まないノードである。ゼロ以上のADNが、oneM2Mシステムのフィールドドメイン内に存在し得る。物理的マッピングの例：アプリケーション専用ノードは、制約付きM2Mデバイス内に常駐し得る。中間ノード（Middle Node:MN）：MNは、１つのCSEを含み、ゼロ以上のAEを含むノードである。ゼロ以上のMNが、oneM2Mシステムのフィールドドメイン内に存在し得る。物理的マッピングの例：MNは、M2Mゲートウェイ内に常駐し得る。インフラストラクチャノード（Infrastructure Node:IN）：INは、１つのCSEを含み、ゼロ以上のAEを含むノードである。INは、oneM2Mサービスプロバイダごとにインフラストラクチャドメイン内に１つだけ存在する。IN内のCSEは、他のノードタイプには適用できないCSE機能を含み得る。物理的マッピングの例：INは、M2Mサービスインフラストラクチャ内に常駐し得る。非oneM2Mノード（Non-oneM2M Node:NoDN）：非oneM2Mノードは、oneM2Mエンティティ（AEまたはCSEのいずれでもない）を含まないノードである。このようなノードは、管理を含む、インターワーク目的のために、oneM2Mシステムにアタッチされたデバイスを表す。
図４に示す＜semanticDescriptor＞リソースは、リソースおよび場合によりサブリソースに関するセマンティック記述を記憶するために使用される。このような記述は、オントロジーに従って提供され得る。セマンティック情報は、oneM2Mシステムのセマンティック機能によって使用され、アプリケーションまたはCSEにも利用可能である。
＜semanticDescriptor＞リソースは、表Ａに規定される属性を含むものとする。
Figure 0007038113000001
さらに、＜semanticDescriptor＞リソースは、＜subscription＞子リソースを含むものとし、＜subscription＞子リソースは、その購読対象リソース（subscribed-to resource）のための購読情報を含む。
一般フィルタリングは、要求動作に規定されたフィルタ基準を有することによってサポートされる（oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0 第8.1.2節）。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値がoneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.1 第8.5.4節に記述されており、その定義は下表に示す。複数のインスタンスを使用することができ、これは、フィルタ基準を評価するための一般的ルールに従い、「OR」セマンティクスが適用され、例えば、セマンティックフィルタのうちの１つまたは複数がセマンティック記述に一致する場合、セマンティックフィルタ基準のための総合的な結果が真であることを意味する。下表のセマンティクスは、oneM2M TR-0007に定義され、oneM2M TS-0001の要求パラメータsemanticFilterに対応することに留意されたい。semanticFilterパラメータに含まれるSPAQRLクエリが、親リソースの＜semanticDescriptor＞子リソースのうちの１つのセマンティックトリプルと一致する場合、これは、このセマンティックフィルタリングが成功しており、対応する親リソースは戻されることを意味する。
Figure 0007038113000002
上記の提案は、以下の仮定を使用する：セマンティック記述は、RDFトリプル（表現、例えば、RDF/XML、Turtle、oneM2M内にまだ完全に規定されていない記述フォーマット）として規定され、セマンティックフィルタ基準は、セマンティック記述に対して実行されるべきSPARQL要求のために使用されるであろう。
以下は、oneM2M TR-0007に与えられるセマンティックフィルタリング例である。
Figure 0007038113000003
これは、my:myDevice1によって記述されるAEリソースは結果セットに含まれるが、my:myDevice2によって記述されるAEリソースは含まれないことを意味する。
場合によっては、１回の検索のための関連セマンティック情報は、異なる＜semanticDescriptor＞リソース間に分散されている場合がある。図５で与えられる例はこの場合を示す。主語－述語－目的語関係を表すセマンティックグラフが図示されており、このグラフの異なる部分（楕円で表される）は異なる＜semanticDescriptor＞リソースに記憶されている。セマンティックフィルタリングは、完全なセマンティックグラフ（の一部）に適用される必要があり、このことにより、グラフのいくつかの異なる部分をセマンティック動作の実行のために一緒にする必要があるという問題が生じる。
この問題は概して、セマンティックウェブの領域では明らかではない。クラスインスタンスを識別するURIが直接デリファレンスし得ることから、概念（例えば、クラス、関係）情報をそのURIに基づいて発見し得るからである。oneM2Mの場合、アクセスされ得るリソースおよびセマンティクスのみが、リソースのコンテンツとして記憶される。
現在SPARQL1.1は、SERVICEキーワードを使用してフェデレーテッドクエリをサポートし、遠隔SPARQLエンドポイントのURLが指定され得る。このアプローチに関して、要求側は、どのセマンティック記述子が検索に要求されるセマンティックインスタンスを含むかを予め把握しているであろう。したがって、セマンティック記述子がリソースツリー内に分散されている場合、このアプローチは一般に適用できなくなる。
TR-0007に提示される＜semanticDescriptor＞リソースをまたいで記憶されているセマンティック記述に対してセマンティックフィルタリングを可能にするための解決策は、resourceDescriptorLink OWL注釈プロパティの形態で注釈リンクを導入する。この注釈プロパティは、任意のクラスインスタンスのために指定でき、その値は、＜semanticDescriptor＞リソースのURLであり、所与のクラスインスタンスのための追加のRDFトリプルが見出され得る。以下の例は、図７のグラフを作成するために、oneM2Mベースオントロジー（図６）に定義されたクラスおよび関係を用いる。
この解決策は、受信側におけるSPARQLベースのセマンティックフィルタリングエンジンのための以下の機能フローを伴う。SPARQL要求として公式化されるセマンティックフィルタは、候補リソースのセマンティック記述子リソースのコンテンツに対して実行される。実行の過程において、１つまたは複数のresourceDescriptorLink注釈を伴うクラスインスタンスに遭遇する場合、実行は停止される。semanticDescriptorLinkが参照する＜semanticDescriptor＞リソースの各々のコンテンツが、SPARQL要求が実行されているコンテンツに追加される（遅延評価、代替としては実行前にすべてをフェッチするが、不必要な情報のフェッチをもたらし得る）。SPARQL要求の実行は、拡大されたコンテンツに対して継続される。
oneM2M TR-0007は、セマンティックマッシュアップを「セマンティックM2Mシステムにおいて、M2Mアプリケーションは、物理的リソースと同様に機能する「仮想物」を発行でき、直近１分間／１時間の間に通過した車両の数、車両の平均速度等の新たな情報を提供できる」ものとして定義している。簡単なセマンティック仮想マッシュアップ手順は、TR-0007に定義されており、これは以下の図８に示す。
基本的に、これらの「仮想物」は、他のM2Mリソースと同様にしてM2Mシステム内で検索され、発見され得る。しかし、物理的な物とは対照的に、仮想物はソフトウェアとしてのみ実装される。新たな仮想物がセマンティックM2Mシステムに登録（または発行）されると、メンバM2Mリソースのリストが物の属性として一緒に記憶される。仮想物がクエリの受信時点で動的に情報を収集した場合、メンバリソースを収集する前もってプログラムされたクエリも他の情報と一緒に記憶される。仮想物がIN-CSEに追加されると、それは他のすべてのM2Mリソースと同じように取り扱われ、処理される。これは、仮想物が、発見されるべきM2Mアプリケーションに対して公開されていることを意味する。
図８のステップ１では、M2Mアプリケーションは、例えば「部屋１の気温を取得してください」等のセマンティッククエリをセマンティックM2Mシステムに送信する。
図８のステップ２では、セマンティックエンジンは、これを正常なセマンティッククエリとして取り扱い、発見要求をIN-CSEに送信する。
図８のステップ３では、IN-CSEは部屋１の温度を提供する仮想物のURIを返す。
図８のステップ４では、セマンティックエンジンは、IN-CSEに要求を送信し、仮想物の情報、例えば、サービス論理、マッシュアップタイプ（静的または動的）および前もってプログラムされたクエリを検索する。
図８のステップ５では、IN-CSEは要求された情報を返す。
図８のステップ６では、セマンティックエンジンは仮想物をインスタンス化する。頻繁に要求される仮想物については、これはセマンティックエンジンにキャッシュされ、要求を直接取り扱い得る。
図８のステップ７では、セマンティックエンジンにおける仮想物は、前もってプログラムされたクエリを用いてそのメンバリソースから要求されたデータを収集する。
図８のステップ８では、IN-CSEはメンバリソースからの結果を返送する。
図８のステップ９では、仮想物は、そのサービス論理（例えば平均値の計算）を受信データに適用し、結果を計算する。
図９に示すように、基本的なオープンインターコネクトコンソーシアム（Open Interconnect Consortium:OIC）アーキテクチャ［OIC Specification 1.1、https://openconnectivity.org/resources/specifications/draft-candidate-specifications］は、OICサーバおよびOICクライアントを含む。リソース提供側とみなされるOICサーバはOICリソースをホストするが、OICクライアントはOICサーバでホストされているリソースにアクセスして操作するリソース消費側である。リソースは、要求／応答モデルに基づいて操作され、これは５つのタイプの操作、例えば生成、検索、更新、削除および通知（CRUDN操作）を含む。CRUDNは、メッセージ通信プロトコル（例えば、CoAP、HTTP等）におけるPUT/GET/POST/DELETE操作に最終的にマッピングされることに留意されたい。基本的に、OICクライアントは、OICサーバのリソースを対象としたRESTful要求（例えば、生成、検索、更新、削除および通知）を送信し、次に、OICサーバはRESTful要求を処理し、対応する応答をOICクライアントに送信する。OIC規格は、さまざまなタイプのリソースを定義しており、各タイプのリソースは、複数のプロパティを持つことができ、各プロパティは読み取り専用または読み書き可能であり得る。いくつかの一般的なプロパティ（OIC標準規格で指定されている）は次のように説明される。
リソースタイプ（“rt”）：リソースのタイプを意味する。特定のリソースは、複数のリソースタイプに属し得るが、このプロパティは複数の値を有し得る。
インタフェース（“if”）：リソースによってサポートされるインタフェースを意味する。インタフェースは、リソースおよびプロパティへどのようにアクセスすべきかを説明および指定する。このプロパティは複数の値を有し得る。OIC規格は以下のインタフェースを定義する。特定のリソースは、それらのインタフェースのうちの１つまたはすべてをサポートできる。
基準インタフェース（“oic.if.baseline”）：リソースのすべてのプロパティ（例えば、完全表現）は、RETRIEVE（例えば、GET操作－通常、RETRIEVEは、メッセージ通信プロトコル（例えば、CoAPおよびHTTP）のGET操作にマッピングされる。したがって、GETを使用してRETRIEVE操作を実施する。）およびUPDATEを用いて、このインタフェースを介してアクセスし得る。例えば、図１０に示すように、OICクライアントは、（“My/room/1”というURIによって識別される）OICリソースのすべてのプロパティを取得するために、OICサーバにリソース検索要求（例えば、GET/My/room/1?if=oic.if.baseline）を送信し得る。
リンクリストインタフェース（“oic.if.ll”）：このインタフェースは、OICで定義されたリソースタイプであるOICコレクションリソースに含まれるリンクへのビューを（RETRIEVEを用いて）提供する。コレクションリソースは、基本的に、他の複数のリソース（リンクと呼ばれる）を含む。このインタフェースを使用して、OICサーバでホストされているリソースを発見し得る。図１１は、OICクライアントが、（“/My/room/1”というURIで識別される）コレクションリソースに含まれるリンク／リソースのリストを取得するために、OICサーバにリソース検索要求（例えば、GET/My/room/1?if=oic.if.ll）を送信するための一例を示す。
アクチュエータインタフェース（“oic.if.a”）：このインタフェースにより、OICアクチュエータリソースを読み書きすることが可能になる。図１２は、アクチュエータの１つのタイプであるOICサーバ上でOICクライアントがどのように動作するかの一例を示す。具体的には、OICクライアントがアクチュエータの表現を取得しようとした場合（例えば、RETRIEVE操作）、リソース検索要求（例えば、GET/the/light/2?if=“oic.if.a”）をアクチュエータに送信し、その表現を検索し得る。OICクライアントがアクチュエータの表現のうちの１つを変更しようとした場合、リソース更新要求（例えば、PUT/the/light/2?if=“oic.if.a”{“color”:“blue”}）をアクチュエータに送信し得る。
センサインタフェース（“oic.if.s”）：このインタフェースにより、OICセンサリソースを読み取ることのみが可能になる。図１３は、センサとして機能するOICサーバの表現をOICクライアントがどのように検索できるかの一例を示す。具体的には、OICクライアントがセンサの表現を取得しようとした場合、リソース検索要求（例えば、GET/the/light/1?if=“oic.If.s”）をセンサに送信し、その表現を検索し得る。OICクライアントがセンサの表現のうちの１つを変更しようとした場合、センサはエラーメッセージを返すべきであることに留意されたい。
バッチインタフェース（“oic.if.b”）：このインタフェースは、コレクションリソースに含まれる各リソース／リンクに対して１つのRETRIEVE要求または１つのUPDATE要求を同時に用いることによって、OICコレクションリソースに含まれるすべてのリンクまたはリソースに対して動作する（RETRIEVEおよびUPDATE）ことを可能にする。図１４は、バッチインタフェースを適用することによって、OICクライアントがどのように（異なるOICサーバによってホストされる）異なるリソースを検索するかの一例を示す。具体的には、OICクライアントは、リソース検索要求（例えば、GET My/room/1?if=oic.if.b）をOICデバイス１（例えば、OICサーバまたは異なる状況においてはOICクライアントとして機能し得るゲートウェイ）に送信し得る。その結果、OICデバイス１は、コレクションリソースのOICデバイス１の２つのリソース／リンクに対応する２つのリソース検索要求（例えば、GET the/light/1?if=oic.if.sおよびGET the/light/2?if=oic.if.a）を生成する。これら２つのリソース検索要求は、それらの表現を検索するために異なるOICサーバ（例えば、OICサーバ２およびOICサーバ３）に送信するものとする。すべての結果を受信した後、OICデバイス１は集約された結果をOICクライアントに送信して、そのリソース検索要求に応答するものとする。
読み取り専用インタフェース（“oic.if.r”）：このインタフェースにより、リソースのすべての「読み取り専用」プロパティをRETRIEVE（検索）することのみが可能になる。
読み書きインタフェース（“oic.if.rw”）：このインタフェースにより、リソースのすべての「読み書き」プロパティをRETRIEVEまたはUPDATE（更新）することが可能になる。
名前（“n”）：リソースに割り当てられた、人間が読める名前を意味する。リソース識別子（“id”）：リソースをホストするOICサーバ全体で一意となるべきリソースインスタンスの識別子を意味する。
本開示は、改善された再利用性、相互運用性およびシステム効率を提供し得る、IoT（例えば、M2M）におけるセマンティックマッシュアップサービスを可能にするための方法を説明する。
個別のセマンティックマッシュアッププロファイル（Semantic Mashup Profile:SMP）、仮想セマンティックマッシュアップリソース（Virtual Semantic Mashup Resource:VSMR）、またはセマンティックマッシュアップ結果（Semantic Mashup Result:SMRS）を含み得る、モジュール設計を有するセマンティックマッシュアップアーキテクチャが本明細書に開示される。この種のモジュール設計は、SMP、VSMRおよびSMRSの再利用性を改善し得る。さらに、このマッシュアップアーキテクチャは、各マッシュアッププロセス中にセマンティクスを活用するため、これにより相互運用性が向上する。さらに、このアーキテクチャは、サービス層で新たなセマンティックマッシュアップサービス（Semantic Mashup Service:SMS）を実現し、その結果としてシステム効率を改善し得る。
SMPの発見および検索のための特徴および手順が本明細書で開示される。SMPの表現は、セマンティックデータモデル（例えば、RDFトリプル）を使用して記述され得るが、それは、改善された相互運用性をもってセマンティックに発見され、理解され得る。
VSMRを生成するための特徴および手順が本明細書で開示される。VSMRは、対応するSMPにリンクしており、セマンティック発見を活用し、適切なマッシュアップメンバを見つけ出すことができる。VSMRは、マッシュアップメンバの編成、SMRSの生成、およびSMRSの記憶のための柔軟なアプローチをサポートする。
SMRS検索を含むVSMR発見および検索のための特徴および手順が本明細書で開示される。VSMRは、そのセマンティック情報に基づいて発見および再利用され得るが、これにより相互運用性および再利用性が向上できる。
VSMRのマッシュアップメンバとその対応するオリジナルリソースとの同期を維持するためにいくつかのアプローチが設計され得る、VSMR維持のための特徴および手順が本明細書で開示される。
この概要は、発明を実施するための形態において以下でさらに説明される概念の選択を簡単な形式で紹介するために提供されている。この概要は、特許請求される主題の重要な特徴または本質的な特徴を特定することを意図しておらず、また特許請求される主題の範囲を限定するために用いられることを意図していない。さらに、特許請求される主題は、本開示の任意の部分に記述される任意のまたはすべての不都合を解決する制限に限定されない。
添付の図面とともに、例として与えられる以下の説明からより詳細に理解できる。
図１は、セマンティックウェブのアーキテクチャを示す。 図２は、oneM2Mアーキテクチャの図を示す。 図３は、oneM2Mの共通サービス機能の図を示す。 図４は、リソースツリーにおける＜semanticDescriptor＞リソースの構造の図を示す。 図５は、異なるリソースに記憶されたセマンティック情報全体でのセマンティックフィルタの範囲の図を示す。 図６は、oneM2Mベースのオントロジーの図を示す。 図７は、resourceDescriptionLinkの使用例の図である。 図８は、セマンティック仮想マッシュアップ手順の図を示す。 図９は、OICアーキテクチャの図を示す。 図１０は、OICリソースのプロパティを取得するために基準インタフェースを使用する一例の図を示す。 図１１は、OICコレクションリソースのリンクを取得するためにリンクリストインタフェースを使用する一例の図を示す。 図１２は、OICアクチュエータリソースに対して動作するためにアクチュエータインタフェースを使用する一例の図を示す。 図１３は、OICセンサに対して動作するためにセンサインタフェースを適用する一例の図を示す。 図１４は、OICコレクションリソースに対して動作するためにバッチインタフェースを使用する一例の図を示す。 図１５は、スマート農業のユースケースの例示図を示す。 図１６は、スマート駐車場のユースケースの例示図を示す。 図１７は、問題の実例の例示図を示す。 図１８は、セマンティックマッシュアップのためのアーキテクチャの例示図を示す。 図１９は、SMPにおけるマッシュアップ機能の実例の例示図を示す。 図２０は、マッシュアップ結果を生成するVSMRの実例の例示図を示す。 図２１は、セマンティックマッシュアップの手順の例示図を示す。 図２２は、VSMRおよびマッシュアップ結果の分離の例示図を示す。 図２３は、SMPホスト、VSMRホストおよびSMRSホスト間の相互作用の例示図を示す。 図２４は、高度SMSアーキテクチャにおけるVSMR移行の例示図である。 図２５は、SMPの表現の一例の例示図を示す。 図２６は、SMP発見および検索の例示図を示す。 図２７は、RDFトリプルを適用して入力パラメータを表現する一例の例示図を示す。 図２８は、VSMR生成手順の例示図を示す。 図２９は、VSMR発見の例示図を示す。 図３０は、VSMR検索手順の例示図を示す。 図３１は、VSMRにマッシュアップメンバの表現を記憶する一例の例示図を示す。 図３２は、VSMRを購読するSMS要求側の例示図を示す。 図３３は、共同VSMR生成および検索の例示図を示す。 図３４は、リソース検索要求を送信することによってオリジナルリソースを確認するSMSホストの例示図を示す。 図３５は、SMSホストがオリジナルリソースを観察する例示図を示す。 図３６は、オリジナルリソースの消去を報告するリソースホストの例示図を示す。 図３７は、新しいオリジナルリソースを報告するリソースホストの例示図である。 図３８は、VSMRメンテナンスのための全体的な手順の例示図を示す。 図３９は、oneM2Mアーキテクチャにおけるサポートセマンティックマッシュアップサービスの例示図である。 図４０は、セマンティックマッシュアッププロファイルリソース＜smp＞の例示図を示す。 図４１は、＜smp＞リソースを操作する手順の例示図を示す。 図４２は、仮想セマンティックマッシュアップリソース＜vsmr＞の例示図を示す。 図４３は、＜vsmr＞リソースを操作する手順の例示図を示す。 図４４は、セマンティックマッシュアップ結果リソース＜smrs＞の例示図を示す。 図４５は、＜smrs＞リソースを操作する手順の例示図を示す。 図４６Ａは、oneM2Mにおけるセマンティックマッシュアップの全体的な手順の例示図を示す。 図４６Ｂは、引き続きoneM2Mにおけるセマンティックマッシュアップの全体的な手順の例示図を示す。 図４６Ｃは、引き続きoneM2Mにおけるセマンティックマッシュアップの全体的な手順の例示図を示す。 図４７Ａは、OICアーキテクチャ下のSMSの例示図を示す。 図４７Ｂは、OICアーキテクチャ下のSMSの例示図を示す。 図４８は、SMSを提供し、そのローカルリソースをマッシュアップメンバとして使用するOICサーバの例示図である。 図４９は、マッシュアップメンバが他のOICサーバ由来のものである、SMSを提供するOICサーバの例示図である。 図５０は、グラフィカルユーザインタフェースの例示図である。 図５１Ａは、開示されている主題が実施され得る、例示的な機械対機械（Machine-To-Machine:M2M）またはモノのインターネット（IoT）の通信システムを示す。 図５１Ｂは、図５１Ａに示すM2M/IoT通信システム内で使用され得る例示的なアーキテクチャを示す。 図５１Ｃは、図５１Ａに示す通信システム内で使用され得る例示的なM2M/IoT端末またはゲートウェイデバイスを示す。 図５１Ｄは、図５１Ａの通信システムの態様における例示的なコンピューティングシステムを示す。
ユースケースを以下で紹介する。これらのユースケースによる支援は、IoTにおけるアプリケーション（例えば、M2M）が、オリジナルリソースをマッシュアップすることによって取得され得る推定された情報または知識を取得するように有益に設計され得るという見通しを提供する。以下のIoT（例えば、M2M）のユースケース（例えば、スマート農業、スマート駐車場等）は、オリジナルリソースを単独で取得することは好ましくないことを実証している。図１５に示すスマート農業アプリケーションの状況では、土壌の水分レベルを監視するために多くの水分センサ１５０２が農地に配置されている。その一方で、天候センサ１５０４（例えば、温度計、気圧計、湿度計等）は、農地領域の測候所に配置されている。天候センサ１５０４によって生成されたデータ量は、農地領域における天候（例えば、雨、風または晴れ）を予測するために測候所によって使用される。したがって、農地のインテリジェント灌漑システムは、農地を灌漑するか否か、および灌漑にどの程度の水量が必要かを判断するために、（水分センサによって生成される）農地の水分レベルおよび（測候所によって配置されるさまざまな種類のセンサによって生成される）天気予報結果を一緒に分析する。しかしながら、水分センサを所有し自由にアクセスすることができる農地所有者は、測候所を所有していない（例えば、図１５の測候所Ａおよび測候所Ｂ）。このことにより、農地所有者が灌漑の判断を行うことは実行不可能となる。結果として、水分センサ１５０２および天候センサ１５０４の両方からのデータにアクセスし、インテリジェントな灌漑判断を生成し得る新たなサービスまたは機能が農地所有者に提供される必要がある。
スマート駐車場のユースケースでは、スマート駐車場はスマートシティにおける主要なアプリケーションであり得る。スマートシティでは、各駐車スポット（例えば、駐車ビル内および任意の路上駐車スポット）に駐車センサを装備することができる。駐車センサは、状態（例えば、空車か否か）、地理的位置およびその関連駐車スポットの駐車料金を提供し得る。図１６は例示的なスマート駐車システムを示す。サーバＡは、クライアントの目的地住所ならびにサーバＢ、サーバＣおよびサーバＤからの情報に基づいて、クライアントに適切な駐車スポットを計算し得る。サーバＢはある地理位置から別の地理位置までの（徒歩、自転車または車による）時間費用推定値を提供し得る。サーバＣは、駐車ビルの位置情報、異なる期間における駐車料金および駐車ビル内の利用可能な駐車スポットを提供し得る。サーバＤは、各路上駐車スペースの位置情報、状態および費用を提供し得る。
図１６に示すように、所与の建物Ａの近くにいくつかの駐車ビルおよび多くの路上駐車スポットがあると仮定すると、これらの駐車ビル内の駐車センサはサーバＣに登録され得るが、建物Ａの近くの路上駐車場はサーバＤに登録される。目的地が建物Ａである場合の、ユーザ（例えば、クライアント）が適切な駐車スポットを見つけようと試みる場合を考える。適切な駐車スポットは、空の駐車スポットとして定義され得るが、これはより少ない時間費用（例えば、駐車スポットから目的地までの徒歩に要する時間がより少ない）およびより少ない駐車費用（例えば、より低い駐車料金）であることに留意されたい。したがって、ユーザは、クエリ（例えば、建物Ａの近くの適切な駐車スポットを見つける）を、リアルタイム駐車サービスを提供するサーバＡに送信し得る。クエリを受信した後、サーバＡは建物Ａの近くの駐車スポットの情報を検索し、ユーザに最適な駐車場を見つけ得る。具体的には、サーバＡは、サーバＣおよびサーバＤから建物Ａ近くの各駐車センサの状態、駐車料金および地理的位置を検索し得る。次に、サーバＡは、各駐車スポットから建物Ａまでの推定時間費用をクエリすることによって、サーバＢからそれらの駐車スポットの費用を取得し得る。その後、サーバＡはこれらの情報を分析して、ユーザに最適な駐車スポットを見つけ得る。例えば、最適な駐車場は、利用可能な駐車スポットを見つけることにより算出することができ、この駐車スポットは、建物Ａ周辺の駐車スポットのうち「0.5×timeCost＋0.5×parkingCost」の最小値をとる。基本的に、サーバＡは、複数のサーバからリソース（例えば、駐車スポット情報および料金情報）を検索し、検索されたリソースの組み合わせに基づいて結果（例えば、最適な駐車スポット）を算出する必要がある。
スマート農業およびスマート駐車場のユースケースに記載されているように、ユーザまたはアプリケーションは、オリジナルリソース（例えば、スマート農業における特定の水分センサの水分レベルおよび特定の駐車場の駐車料金）を知り得ないかまたは知る必要がなく、むしろ、ユーザまたはアプリケーションは、サービス層に維持され得る複数のオリジナルリソースの組み合わせから推定される情報または知識（例えば、スマート農業での灌漑の提案およびスマート駐車場での適切な駐車場）により関心を持つ。アプリケーションはそれらのオリジナルリソースを検索し、オリジナルリソースのみから知識を計算または推定し得るが、このアプローチでは複数の問題がもたらされ得る。第１に、例えば、アプリケーションは、オリジナルリソースを複数回（例えば、各オリジナルのリソースにつき１回）検索する必要がある。これにより、特に多数のオリジナルリソースが関与している場合、アプリケーションに大きなオーバーヘッドが発生し得る。第２に、一部のオリジナルのリソースは慎重な扱いを要することがある。それらは、アプリケーションに公開されていないか、またはアプリケーションによって直接検索されることが許可されていないことがあり、サービスプロバイダによってのみアクセスされ得る。第３に、多くのアプリケーションが同じ知識を取得することに関心を持っている場合、それぞれがオリジナルリソースを検索し、共有することなく独立して知識を推定する必要がある。第４に、関与するオリジナルリソースが異なるドメインまたはバーティカルマーケット由来のものである場合、アプリケーションはオリジナルリソースを見つけて理解するために、さまざまなドメイン知識を有する必要があり、これはアプリケーションに余分な負担をかけることを避けられない。
図１７は、以下の問題の例を示している。１）異なるオリジナルリソースを維持し得るいくつかのサービス層ノード（例えば、リソースホスト２８０４）が存在することがある、２）２つのアプリケーションが２つの要求（例えば、要求１７１１および要求１７１２）を生成する、３）要求１７１１は、サービス層ノード１７０１、サービス層ノード１７０２およびサービス層ノード１７０３それぞれからの、３つの選択されたリソースのみに基づいて回答され得る、３）要求１７１２は、サービス層ノードＮに記憶され得る３つの選択されたリソースのみに基づいて回答され得る。この例では、アプリケーション１７２１またはアプリケーション２ １７２２は、マッシュアップ機能を実行するために頼るオリジナルリソースを３回検索する必要があり得る。サービス層ノード１７０１、サービス層ノード１７０２およびサービス層ノード１７０３が３つの異なる垂直ドメイン由来のものであり得る場合、アプリケーション１７２１はそれら３つの垂直のドメイン知識を有する必要がある。
さらに引き続き図１７を参照すると、以下のように問題が提示され得る。アプリケーションは、各サービス層ノードから潜在的に関連性のあるリソースを直接発見および検索し得るが、最終的にそれ自体でクエリに回答し得る。しかし、このアプローチは、煩雑かつ非効率的であり得る。第１に、アプリケーションは、検索操作を複数回実行する必要があり、第２に、異なるアプリケーションが同じプロセスを繰り返す必要があるが、それらは同様の要求を発し得る。サービス層は新しいサービスを提供する必要があり、これは同じまたは異なるノードからさまざまなタイプのデータをインテリジェントに収集し、アプリケーションからの要求に効率的に回答し得る。データのタイプは、そのセマンティック注釈または記述情報によって指定され得る。セマンティックマッシュアップはそのようなサービスを提供し得るが、既存のサービス層（例えば、oneM2M）はまだこの機能をサポートしていない。この例では、要求１７１１は、どの単一のサービス層ノードによっても独立して回答されない場合がある。代わりに、要求１７１１は、サービス層ノード１７０１、ノード１７０２およびノード１７０３それぞれから選択されたリソース（√でラベル付けされている）のみに基づいて回答され得る。要求１７１２は、サービス層ノードＮによって回答され得るが、単一のリソースには基づいていない。代わりに、要求１７１２は、複数の選択されたリソース（Ｘでラベル付けされている）のみに基づいて回答され得る。各サービス層ノードは、特定のリソースを維持しており、これらは類似しているか（例えば、ノード１７０１、ノード１７０２およびノード１７０３において）または多様（例えばノードＮ）であり得る。
従来のマッシュアップ解決策（例えば、ウェブマッシュアップアプリケーションおよびツール）は、相互運用性または再利用性にある制限を有する。例えば、Google Mashup Editorは、異なる垂直ドメインのリソースの動的なマッシュアップを十分にサポートしておらず（相互運用性の問題）、またモジュールマッシュアップ設計がないため、既存のマッシュアップ機能およびマッシュアップリソースを再利用するようにアプリケーションまたはユーザをサポートしない（再利用性の問題）。
要約すれば、従来のシステムに関して、以下の問題のうちの１つまたは複数が存在し得る。第１の問題は、既存のマッシュアップ解決策が相互運用性および再利用性に対するサポートが限られていることであり、これはM2M/IoTシステムにとって重要であり得る。第２の問題は、既存のM2M/IoTサービス層（例えば、oneM2M、OIC）にセマンティックマッシュアップ解決策がないことであり得る。
本明細書に開示される問題のうちの１つまたは複数を解決し得るさらなる詳細が以下で開示される。最初に、モジュール設計を有する新たなセマンティックマッシュアップサービスアーキテクチャについて説明する。加えて、方法（例えば、手順）および高度マッシュアップアーキテクチャの特徴を説明する。開示される方法およびシステムは、セマンティックマッシュアップの再利用性および相互運用性を解決し得る。開示される方法およびシステムは、SMPリソースの再利用性および相互運用性を改善するために、クライアント（例えば、SMS要求側1808）がSMPリソースを発見および検索する方法を指定する。開示される方法およびシステムは、VSMRの再利用性および相互運用性を改善するために、VSMRを生成する方法ならびにVSMRを発見および検索する方法の詳細を指定する。開示される方法およびシステムは、セマンティックマッシュアップシステム効率をさらに改善するために、VSMRを維持する方法をさらに指定する。
以下に開示されるのは、開示される頭字語のうちのいくつかを翻訳するために使用され得る表１であり、表２は、用語の多くについて何らかの見解を提供し得るいくつかの説明を提供し得る。
Figure 0007038113000004
Figure 0007038113000005
Figure 0007038113000006
Figure 0007038113000007
図１８に示されているセマンティックマッシュアップサービス（SMS）アーキテクチャ１８００に関する詳細を以下に提供する。これは、モジュール設計を特徴とし、より高い再利用性、より良好な相互運用性およびより高いシステム効率を達成し得る方法でセマンティクスを利用する。
第１に、SMSアーキテクチャ１８００は、分離されたSMP１８０２およびVSMR１８０４を含み得る。SMP１８０２は、１）入力パラメータに関するセマンティック情報（例えば、inputDescriptor）、２）マッシュアップのためのマッシュアップメンバまたはメンバリソース（用語「メンバリソース」、「マッシュアップメンバ」および「マッシュアップメンバリソース」は区別なく使用され得る）がどのように選択されるべきかに関するセマンティック情報（例えば、memberFilter）、３）マッシュアップ機能に関するセマンティック情報（例えば、functionDescriptor）、または４）マッシュアップ結果に関するセマンティック情報（例えば、outputDescriptor）等、その関連マッシュアップサービスのプロファイル情報をセマンティックに記述する。
SMP１８０２によって説明されるようにマッシュアップサービスを活用するために、VSMRは、SMS要求側１８０８（例えば、ユーザまたはアプリケーション）のためのインタフェースとして生成され、マッシュアップサービスを実現し得る。VSMRはSMP１８０２を参照し、そのプロファイル情報を使用してセマンティックマッシュアップ結果を計算または生成する。VSMRは、複数のSMS要求側１８０８によって検索またはアクセスされ得るセマンティックマッシュアップ結果（例えば、SMRS１８０６）を維持する。VSMRはまた、各オリジナルメンバリソースへの参照を維持し得る。さらに、SMS要求側１８０８は、マッシュアップ機能を実行し、マッシュアップ結果を再計算するようにVSMRをトリガし得る。SMP１８０２は、アプリケーションまたはSMS要求側１８０８によって提供または生成され得るが、VSMR１８０４は、SMS要求側１８０８またはVSMRを作成するためのコマンドを発行するであろう他のアプリケーションによって生成される。SMP１８０２は多くのVSMR１８０４によって使用され得る。VSMRは他のSMS要求側１８０８（元々はVSMRを生成しない）によってアクセスされ得る。SMP１８０２をホストするサービス層ノードはSMPホスト１８１０と呼ばれるのに対し、VSMR１８０４をホストするサービス層ノードはVSMRホスト２３０２と呼ばれる。SMPホスト１８１０およびVSMRホスト２３０２は、異なる物理的ノードに位置していても、または同じ物理的ノードに一緒に位置していてもよい。例えば、SMSホストはSMP１８０２、VSMR、またはこの両方をホストし得る。
第２に、SMSアーキテクチャ１８００下でのセマンティックマッシュアップ手順、例えば、SMP１８０２を発見および検索する手順、VSMRを生成する手順、VSMRを発見および検索する手順およびVSMRを維持する手順を記述し、簡潔に説明する。
第３に、高度SMSアーキテクチャ２２００では、セマンティックマッシュアップ結果（例えば、SMRS１８０６）がVSMRから分離される。次に、SMRS１８０６をホストするサービス層ノードは、SMRSホスト２３０４と呼ばれる。VSMRとSMRS１８０６とのこの分離により、SMS要求側１８０８は、VSMR１８０４を知るかまたはこれとインタフェースをとる必要すらないだろう。またSMS要求側１８０８は、SMRSホスト２３０４からマッシュアップ結果を単に検索し得るが、SMRS１８０６は対応するVSMRへの参照を維持する。このアプローチは、１）VSMRは、対応するSMRS１８０６およびSMRS１８０６にアクセスするSMS要求側１８０８に大きな影響を与えることなく、あるVSMRホスト２３０２（例えば輻輳状態のホスト）から別のVSMRホスト２４０２（例えば軽負荷ホスト）に容易に移動または移行され得る、２）さらにVSMRの再利用性を向上し得るという利点をもたらし得る。
（セマンティックマッシュアップアーキテクチャ）
SMSを可能にするために、高い再利用性および相互運用性を達成するためにいくつかの問題を解決し得る。例えば、マッシュアップメンバ、必要な入力パラメータ、マッシュアップ機能、マッシュアップ結果等をモデル化するか否か、およびモデル化の方法が課題として挙げられる。マッシュアップメンバは異なるデータモデルを有する異なる垂直ドメイン由来であり得るため、マッシュアップメンバの記述方法は相互運用性には重要であり得る。さらに、マッシュアップ機能は、さまざまなドメイン由来の、さまざまな要件を持つアプリケーションにとって理解可能であるべきであり、これは再利用性に影響を与え得る。
図１８に示すように、SMSアーキテクチャ１８００は、SMSホスト１８１０、SMPライブラリ１８０２、VSMR１８０４またはSMS要求側１８０８を含み得る。SMSホスト１８１０は、SMS要求側１８０８にセマンティックマッシュアップサービスを提供し得る。SMSホストは、SMPホスト１８１０、VSMRホスト２３０２または両者の組み合わせであってよい。SMP１８０２のみを含み得るSMSホストは、SMPホスト１８１０であってよく、これは、SMP１８０２をホストするためにSMSのみを提供し得る。VSMR１８０４のみを含むSMSホストは、VSMRホスト２３０２であってよく、マッシュアップ結果を計算または公開することを含め、VSMR１８０４をホストするためにSMSのみを提供し得る。SMSホストがSMPライブラリとVSMR１８０４との両方を含む場合、フルSMSをサポートし得る（例えば、SMP１８０２とVSMR１８０４との両方をホストする）。SMSホストは、例えばデフォルトで、SMP１８０２とVSMR１８０４との両方を含む機能を有し得る。
SMPホスト１８１０は、SMP１８０２のセットを含むそれ自身のSMPライブラリを有し得る。SMP１８０２は、特定のマッシュアップ論理についてのプロファイル情報（例えば、スマート駐車場のユースケースで論じたような適切な駐車場）をセマンティックにモデル化し記述する。このアーキテクチャでは、SMP１８０２のプロファイル情報は、入力パラメータのセマンティック記述、メンバリソースのセマンティック記述、マッシュアップ機能のセマンティック記述、またはマッシュアップ結果のセマンティック記述を含み得るが、これらはSMP要素または表現と呼ばれ得る。マッシュアップ結果は、選択されるマッシュアップメンバおよびもしあれば入力パラメータに対してマッシュアップ機能を実行することによって計算され得る。SMP１８０２は、１）SMP１８０２を使用するために、どのタイプの入力パラメータが必要とされ得るか、２）SMP１８０２を使用するためにどのタイプのオリジナルリソースがマッシュアップメンバであることが要求され得るか、３）どのタイプのマッシュアップ機能がSMP１８０２に使用され得るか、または４）どのタイプのマッシュアップ結果がSMP１８０２を使用するために計算および生成され得るかを含み得る。SMP１８０２は通常、入力パラメータ、メンバリソースまたはマッシュアップ結果を含まない。
SMP１８０２のマッシュアップ機能は、図１９に示すように、複数の操作を含み得るが、各操作は、異なる入力（SMS要求側１８０８、マッシュアップメンバの値もしくは表現または他の操作による出力によって提供され得る）および出力を有し得ることに留意されたい。さらに、マッシュアップ機能は、マッシュアップ結果がどのように計算されるべきかを指定するスクリプトであり得る。
VSMR１８０４は、SMS要求側１８０８にSMSインタフェースを提供する仮想リソースとみなされ得る。各VSMR１８０４は、マッシュアップメンバのセットを含み、少なくとも１つのSMP１８０２を適用し得る。VSMR１８０４の各マッシュアップメンバはオリジナルリソースと関連付けられる。SMP１８０２は、マッシュアップメンバによって提供されたコンテンツおよびSMS要求側１８０８からの入力パラメータに基づいてマッシュアップ結果を生成するためのマッシュアップ機能を提供する（例えば、findSuitableParkingLotアプリケーションでは、SMS要求側１８０８は目的地の地理位置をVSMR１８０４に提供し得る）。
図２０は、VSMR１８０４がどのようにマッシュアップ結果を生成するかの例を示す。本質的に、マッシュアップ機能２００２は、マッシュアップメンバのコンテンツおよびSMS要求側１８０８からの入力パラメータに基づいて結果を生成する（例えば、目的地の地理位置は、findSuitableParkingLotアプリケーションにおいてSMS要求側１８０８によって送信されるべき入力パラメータであるとみなされる）。生成されたマッシュアップ結果は、SMRS１８０６に記憶され編成され得るが、これはアーキテクチャ内のVSMR１８０４の子リソースとみなされ得る。VSMR１８０４は、その提供されたSMSをセマンティックにモデル化し記述しているため、このSMSを入手することに関心があり得る他のSMS要求側１８０８は、このVSMR１８０４を発見するか、またはこのVSMRのSMRS１８０６を検索できる。
SMS要求側１８０８がSMSを利用するための複数の方法が存在し得る。第１のアプローチでは、SMS要求側１８０８は、SMSホスト１８１０の利用可能なSMP１８０２を発見する。例えば、SMS要求側１８０８は、利用可能なSMP１８０２（例えば、スマート駐車場アプリケーションのminParkingRate、minTimeCostおよびsuitableParkingLot）を見つけるためにSMP発見要求を送信し得る。次に、SMS要求側１８０８は、関連するSMP１８０２を識別し、入力パラメータを提供することによって、VSMR生成要求をSMSホストに送信し得る。VSMR１８０４が生成された後、SMS要求側１８０８はVSMR１８０４からのセマンティックマッシュアップ結果をトリガし検索し得る。また、SMS要求側１８０８はさらに、VSMR１８０４が生成された後にVSMR１８０４を購読し得る。VSMR１８０４を購読した後、SMS要求側１８０８は、VSMR１８０４で何らかの変更が行われると通知を受けることができる。予測されるSMSに対して既に生成されたVSMR１８０４がある場合、SMS要求側１８０８は既存のVSMR１８０４に直接アクセスして、そのセマンティックマッシュアップ結果を検索するか、または既存のVSMR１８０４を直接購読し得る。SMS要求側１８０８およびオリジナルリソースは、アーキテクチャの外側にあるとみなされる部分であり得る（例えば、それらはSMSホストと対話し得るエンティティであり、これにはセマンティックマッシュアップアーキテクチャが含まれる）ことに留意されたい。
開示されるこのアーキテクチャは、以下の技術的効果を有し得る。SMP生成およびVSMR生成は、互いに別個のもので独立することができ、これによりSMP１８０２がシステム（または他のアプリケーション）によって提供され、さまざまなVSMR１８０４によって使用されることが可能になる。このような分離により、SMP１８０２およびVSMR１８０４は異なる場所に柔軟に、かつ場合によってより効率的に記憶され得る。その結果、再利用性およびシステム効率が改善され得る。
各SMPの表現は、セマンティックトリプルを使用してモデル化され得るが、このことは、特にマッシュアップメンバが異なるドメインから選択されるときに相互運用性を可能にする。SMP１８０２のこのようなセマンティクスベースのモデル化は、アプリケーションまたは機械が各SMP１８０２のプロファイル情報を十分に理解するのを手助けするため、再利用性も改善し得る。
図１８～図２０に示す機能は、後述の図５１Ｃまたは図５１Ｄに示されるもののうちの１つのような無線デバイスまたはその他装置（例えば、サーバ、ゲートウェイ、デバイスまたは他のコンピュータシステム）のメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得ることが理解されよう。さらに、図１８～図２０に示す機能は、仮想化ネットワーク機能のセットとして実装され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。
図２１は、セマンティックマッシュアップの例示的な高度な手順を示す。各々についてのさらなる詳細は本明細書に開示される。ステップ２１００は、SMP発見タスクとみなされ得る。ステップ２１００では、SMS要求側１８０８は、SMSホスト内の既存のSMP１８０２を発見し得るため、これらのSMP１８０２を適用して対応するVSMR１８０４を生成し得る。例えば、SMS要求側１８０８は、セマンティック発見要求をSMSホスト１８１０に送信することによって、駐車場関連のSMP１８０２を発見し得る。このタスクの態様は、本明細書でより詳細に論じられる。ステップ２１０１は、VSMR生成タスクとみなされ得る。ステップ２０１２では、対応するSMP１８０２を発見した後、SMS要求側１８０８は、VSMR生成要求を送信することによってVSMR１８０４を生成するように要求し得る。この要求は、VSMR１８０４を生成するためにどのSMPが適用されるかを示し得る。VSMR生成要求を受信した後、SMSホストはまず、VSMR生成要求に一致する利用可能なVSMR１８０４があるかどうかを確認し得るが、もしそうであれば、SMSホストは別の新しいVSMR１８０４を生成することはできず、そうでない場合は、SMSホストは、適用されたSMP１８０２に基づいてそのマッシュアップメンバを確立することによりVSMR１８０４を生成し得るが、例えば、適用されたSMP１８０２は、VSMR１８０４のマッシュアップメンバとなるべきオリジナルリソースをどのように選択するかの基準を定義する。SMSホスト１８１０それ自体もまた、先回りしてVSMR１８０４を生成し得る。
引き続き図２１を参照すると、ステップ２１０２はVSMR発見タスクとみなされ得る。ステップ２０１２では、VSMR１８０４が生成された後、このVSMR１８０４に関心がある他のSMS要求側（例えば、SMS要求側２１０８）は、セマンティック発見要求をSMSホスト１８１０に送信することによってVSMR１８０４を発見し得る。SMS要求側はまた、要求されたVSMR１８０４をまず発見し（例えばステップ２１０２）、次に必要なVSMR１８０４が見つからない場合にはVSMRを生成する（例えばステップ２１０３～ステップ２１０４）ことに留意されたい。ステップ２１０１およびステップ２０１２は、SMS要求側に適用される異なる戦略に基づいてスワップ可能であり得る。
ステップ２１０３およびステップ２０１４は、VSMRコンテンツ検索タスクとみなされ得る。ステップ２１０３およびステップ２０１４では、本明細書でより詳細に開示されるように、VSMR１８０４のコンテンツ（例えば、マッシュアップ結果）を検索し得る。例えば、これは、VSMR１８０４、SMS要求側１８０８およびSMS要求側２１０８のURIを発見した後に行われ得る。
ステップ２１０５は、VSMR維持タスクとみなされ得る。ステップ２１０５では、VSMR１８０４内のマッシュアップメンバは実際には、異なるリソースホスト２８０４によってホストされるオリジナルリソースにリンクするか、またはオリジナルリソースからコピーする。したがって、オリジナルリソースの表現が変更されると、VSMR１８０４の対応するマッシュアップメンバは更新され得るが、それに応じて、VSMR１８０４のマッシュアップ結果が再計算され得る。さらに、オリジナルリソースはそれらのリソースホスト２８０４で消去または追加され得るため、VSMR１８０４のマッシュアップメンバもそれに応じて修正され得る。
要約すると、Ａ）タスク０－SMP発見（例えば、ステップ２１００）、Ｂ）タスク１－VSMR生成（例えば、ステップ２０１１）、Ｃ）タスク２－VSMR発見（例えば、ステップ２１０２）、Ｄ）タスク３－VSMRコンテンツ検索（例えば、ステップ２１０３～２１０４）、Ｅ）タスク４－VSMR維持（例えば、ステップ２１０５）に分割され得る。
図２１に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２１に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２１に示すステップを実行する。図２１に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２１に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
図１８に示すSMSアーキテクチャ１８００では、VSMR１８０４のマッシュアップ結果は、VSMR１８０４下に位置するSMRS１８０６に記憶され編成され、例えば、SMRS１８０６は、VSMR１８０４の子リソースであるとみなされ得る。図２２の高度SMSアーキテクチャ２２００では、VSMR１８０４およびそのマッシュアップ結果は分離され得るが、例えば、マッシュアップ結果はそのVSMR１８０４とは異なる別個のリソースとみなされ得る。図２２に示すように、SMRS１８０６は、１つまたは複数のVSMR１８０４によって生成されたマッシュアップ結果を含み得るリソースのタイプである。SMRS１８０６は、図２３のSMRSホスト２３０４と呼ばれる異なるサービス層ノードでホストされ得る。VSMR１８０４は、smrsIDを含めることによってその関連SMRS１８０６を識別し得る。その結果、マッシュアップ結果はもはやVSMR１８０４に記憶され得ない。代わりに、対応するSMRS１８０６は、マッシュアップ結果を維持し得るが、マッシュアップ結果は、SMRSリソースのvsmrID属性によって示される関連VSMR１８０４によって生成される。SMRS１８０６のマッシュアップ結果は、マッシュアップ結果に関心を持ち得る他のＳＭＳ要求側が、対応するSMRS１８０６からマッシュアップ結果を直接検索し得るようにセマンティックにモデル化され記述され得る。
図２２に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２２に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２２に示すステップを実行する。図２２に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２２に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
図２３は、高度SMSアーキテクチャ２２００を適用することによってSMSをクライアント（例えば、SMS要求側）に提供するために、SMPホスト１８１０、VSMRホスト２３０２およびSMRSホスト２３０４がどのように互いと対話するかの主な手順を示す。
図２３のステップ２３１１：VSMRホスト２３０２は、SMS要求側からVSMR生成要求を受信する。VSMR生成要求は、どのSMP１８０２が新しいVSMR１８０４に適用され得るかを識別し得る。
図２３のステップ２３１２：VSMR生成要求を受信した後、VSMRホスト２３０２は対応するSMPホスト１８１０にSMP検索要求を送信し得る。ここで、SMPホスト１８１０およびVSMRホスト２３０２は異なるエンティティとみなされる（これは、SMP１８０２およびVMSRが両方ともSMSホストによってホストされる図１８に示すアーキテクチャとはわずかに異なる）ため、VSMRホスト２３０２はSMPホスト１８１０から対応するSMP１８０２を検索し得ることに留意されたい。
図２３のステップ２３１３：SMPホスト１８１０は、要求されたSMP１８０２の表現を返し得る。
図２３のステップ２３１４：要求されたSMP１８０２の表現を取得した後、VSMRホスト２３０２は、ステップ２３１１においてSMS要求側によって要求されるVSMR１８０４を生成できる。また、新たなVSMR１８０４は、SMRS１８０６と関連付けて、そのマッシュアップ結果を記憶し得る。VSMR１８０４を生成した後、VSMRホスト２３０２は、その関連SMRS１８０６のURIを送信することによってVSMR１８０４が生成されたことをSMS要求側に通知し得る。
図２３のステップ２３１５：VSMRホスト２３０２は、そのマッシュアップメンバの表現を検索し、これらの表現に対してマッシュアップ機能を実行することによってマッシュアップ結果を生成する。
図２３のステップ２３１６：VSMRホスト２３０２は、生成されたマッシュアップ結果をSMRSホスト２３０４に送信し得るので、SMRSホスト２３０４は、結果として、生成されたマッシュアップ結果を記憶して編成する。
図２３のステップ２３１７：SMRSホスト２３０４は、応答をVSMRホスト２３０２に送信し、マッシュアップ結果がSMRSホスト２３０４に首尾よく記憶されたか否かを示し得る。
図２３のステップ２３１８：VSMRのマッシュアップ結果を記憶するための場所は、経時的に調整され得るが、例えば、VSMR１８０４は、経時的にそのマッシュアップ結果に対して異なるSMRSホストを選択し得る（例えば、オリジナルSMRSホスト２３０４はVSMR１８０４のマッシュアップ結果を記憶するのに十分な容量を有していない）。したがって、VSMRホスト２３０２は、VSMR１８０４とその対応するSMRS１８０６との間の関係を維持し得る。
図２３のステップ２３１９：VSMR１８０４がそのSMRS１８０６を変更した後、VSMR１８０４は、新たなSMRS１８０６のURIについてSMS要求側に通知し得る。ここで、VSRMホストは、VSMR１８０４がメッセージをSMS要求側に送信し得るようにSMS要求側のアドレス（例えば、URI）を維持すると仮定する。例えば、SMS要求側は、VSMRホスト２３０２を購読し、VSMRホスト２３０２の購読中に通知URI（例えば、SMS要求側のURI）を付与し、次いで、VSMRホスト２３０２は、新たなSMRSホスト２３０４のURIをこの通知URIに送信し得るので、これはSMS要求側によって受信され得る。ステップ２３１５～ステップ２３１９は、VSMRホスト２３０２がセマンティックマッシュアッププロファイルを定期的に実行し、それ自体でマッシュアップ結果を生成するときに使用され得る。
図２３のステップ２３２０：SMRS１８０６を取得したいSMS要求側（図示せず）は、SMRS１８０６を発見し、SMRS検索要求をSMRSホスト２３０４に送信し得る。
図２３のステップ２３２１：SMRS検索要求を受信した後、SMRSホスト２３０４は、最新のマッシュアップ結果をSMS要求側に直接応答し得るか、またはSMRSホスト２３０４は、マッシュアップ結果更新要求を生成し、その関連付けられたVSMR１８０４がマッシュアップ結果を再計算し、更新マッシュアップ結果をSMRSホスト２３０４にフィードバックすることを可能にし得る。
図２３のステップ２３２２：マッシュアップ要求を受信した後、VSMR１８０４は、そのマッシュアップメンバの表現を検索し、これらの表現に対してマッシュアップ機能を実行することによって、マッシュアップ結果を再生成し得る。
図２３のステップ２３２３：VSMRホスト２３０２は、ステップ２３２１からのマッシュアップ要求に応答するために、新たなマッシュアップ結果をSMRSホスト２３０４に送信する。
図２３のステップ２３２４：最新のマッシュアップ結果を受信した後、それに応じてSMRSホスト２３０４は最新のマッシュアップ結果を記憶し、マッシュアップ結果が記憶されたことを確認するためにVSMRホスト２３０２に応答し、次いで最新のマッシュアップ結果をSMS要求側に送信し得る。
図２３に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２３に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２３に示すステップを実行する。図２３に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２３に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
VSMR１８０４とそのマッシュアップ結果とを分離することの利点の１つは、VSMR移行を容易にすることであり、これは図２４に示されている。具体的には、（VSMRホスト間の負荷分散等の何らかの理由により）VSMR１８０４があるVSMRホスト２３０２から新たなVSMRホスト２４０２への移行を試みると、VSMR１８０４とそのマッシュアップ結果とが分離されていれば、VSMR１８０４のマッシュアップ結果は移行される必要がなくなる。VSMRのマッシュアップ結果を移行しないことにより、移行トラフィックが減少し得る。また、SMS要求側１８０８は、VSMRとそのマッシュアップ結果とが分離されている場合、VSMRの移行を認識できないか、またはそうする必要がない。言い換えれば、SMS要求側１８０８は依然として、検索要求を同じSMRSホスト２３０４に送信することによってマッシュアップ結果を検索し得る。
特に図２４を参照すると、最初のステップであり得るステップ２４１１では、VSMR1がVSMRホスト２３０２で生成されホストされる。対応するマッシュアップ結果は、VSMR1のsmrsID属性によって示されるようにSMRSホストで記憶される。ステップ２４１２では、VSMR1は、負荷分散等の理由で別のVSMRホスト２４０２に移行する。VSMR1全体をVSMRホスト１からVSMRホスト２４０２にコピーし得る。ステップ２４１３では、VSMRホスト２４０２におけるVSMR1のsmrsID属性は同じであり、依然としてSMRSホスト２３０４におけるSMRS1ホストを指している。依然として、VSMRホスト２４０２で生成されたマッシュアップ結果はSMRSホスト２３０４で記憶され得る。しかし、SMRS1は、その対応するVSMR1の新しいホストとしてVSMRホスト２４０２を記録し得る。ステップ２４１４では、SMS要求側１８０８は依然としてSMRSホスト２３０４から通常通りマッシュアップ結果を検索する。SMS要求側１８０８は、VSMRホスト２３０２からVSMRホスト２４０２へのVSMR1の移行を認識していない場合がある。
図２４に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２４に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２４に示すステップを実行する。図２４に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２４に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
セマンティックマッシュアッププロファイルの発見および検索（セマンティックマッシュアップのタスク０）－SMPリソース
SMPライブラリ内のSMP１８０２は、smpID、memberFilter、inputDescriptor、functionDescriptorおよびoutputDescriptorの属性を含み得るが、これらは以下で詳述される。smpID属性は、SMPのID（例えばそのURI）を示す。smpID属性は、SMP１８０２をホストするSMPホスト１８１０（またはＳＭＳホスト）内の固有の識別子であるべきである。
memberFilter属性を使用して、同じリソースホストまたは異なるリソースホスト２８０４における複数のオリジナルリソースからマッシュアップメンバのセットを決定するための基準のセットを示し得る。memberFilter属性は、メタデータモデル、例えば、RDFトリプルによって記述され得る。SMSホストは、memberFilter属性のメタデータに基づいてセマンティッククエリを生成し得る。一例を図２５に示す。ここで、memberFilter属性のメタデータは、近くの駐車場（例えば、駐車場と目的地との間の距離が１マイル未満である）が、このSMP１８０２を使用して新たなVSMR１８０４を生成し得る場合、VSMR１８０４のマッシュアップメンバであり得ることを意味する一方、各マッシュアップメンバは、４つの属性、例えば、駐車場のURI、状態、地理位置および駐車料金を有し得る。
inputDescriptor属性は、複数の入力パラメータおよびそれらのタイプを含み得る。これらの入力パラメータは、SMS要求側１８０８がこのSMP１８０２を適用してVSMR１８０４を生成しようとしたときに指定され得る。inputDescriptor属性は、セマンティックメタデータ、例えば、RDFトリプルによって記述される。inputDescriptor属性を取得することによって、SMS要求側１８０８は必要な入力パラメータの数および必要な入力パラメータ各々のタイプを理解し得る。一例を図２５に示す。SMS要求側１８０８がこのSMP１８０２を適用してVSMR１８０４を生成しようと試みるときに、（その位置の経度および緯度の値を含む）１つの地理位置入力パラメータがSMS要求側１８０８によって提供されるべきである。
outputDescriptor属性は、出力パラメータの数およびそれらの対応するタイプを定義する。outputDescriptor属性は、セマンティックメタデータ、例えば、RDFトリプルによって記述される。一例を図２５に示す。ここで、outputDescriptor属性のメタデータは、選択された駐車場のURI、状態、地理位置および駐車料金がSMS要求側に返され得ることを意味する。
functionDescriptor属性は、SMP１８０２のマッシュアップ機能を記述するためのものである。マッシュアップ機能は、出力（例えばマッシュアップ結果）を生成するためにマッシュアップメンバに対して適用され、この出力はoutputDescriptor属性で定義され得る。functionDescriptor属性のコンテンツは、SMSホストによって理解され得る任意のプログラミング言語によって記述されるスクリプトであり得る。一例を図２５に示す。ここで、functionDescriptor属性は、マッシュアップメンバの中から最適な駐車場をどのように選択するかを示すプログラミングコードのセットによって記述され、マッシュアップ機能は、この適切な駐車場のURI、状態、位置情報および駐車料金を返す。
SMP１８０２はまた、以下に詳述される＜semanticDescriptor＞子リソースを含み得る。＜semanticDescriptor＞子リソースは、どの種類のマッシュアップメトリックが適用されるか、このSMP１８０２を記述するためにどのオントロジーが使用され得るか、およびどの種類のSMSでこのメトリックが適用され得るか（例えば、メトリックがどんな種類の適用状況で使用され得るか）を示すためのものである。＜semanticDescriptor＞リソースの記述子属性は、RDFトリプルとして記述される。一例を図２５に示す。ここで、＜semanticDescriptor＞リソースのメタデータは、このSMP１８０２のタイプが“SuitableParkingLot”である（例えば、このSMP１８０２はFindParkingLotサービスに適用可能である）ことを示し、このSMP１８０２のマッシュアップメトリックは“jointOptimization”（例えば、駐車場の駐車料金および駐車場と目的地との間の距離を一緒に考慮する）である［手順を明確に説明するために、駐車場と目的地との間の距離が短いほど、この駐車場の時間費用が低くなると考える。言い換えれば、駐車場がはるかにその距離に近い場合、ユーザは駐車場から目的地に到達するのにかかる時間が少なくなる。］。
セマンティックマッシュアッププロファイルの発見および検索（セマンティックマッシュアップのタスク０）－SMP発見および検索
SMS要求側１８０８がSMSホスト（またはSMPホスト１８１０）のアドレスを提供されるかまたは発見すると仮定すると、以下のステップを適用することによってSMS要求側１８０８は特定のタイプのSMP１８０２を発見し、SMSホストからその表現を検索し得る。
図２６のステップ２６１１：SMS要求側１８０８はSMP発見要求をSMPホストに送信する（SMS要求側１８０８はさらに、SMP発見要求を中央セマンティックグラフストアに送信し得るとともに、中央セマンティックグラフストアは要求に応答し得ることに留意されたい）。SMP発見要求はsmpFilterを含むことができ、これは通常、SMP１８０２のタイプまたはマッシュアップメトリックを指定する。例えば、SMS要求側１８０８が「FindParkingLot」アプリケーションに適用され得るSMPリソースを発見しようと試みる場合、smpFilterは以下の値を取り得る。
SELECT ?smp
WHERE { ?smp rdf:type smp:semanticMashupProfile .
?smp base: hasService smp:FindParkingLot .
}
図２６のステップ２６１２：SMSホストは、SMS要求側１８０８に適格SMP１８０２のsmpIDを含む応答を送信し得るが、これは、＜semanticDescriptor＞子リソースに含まれ、smpFilterによって記述される基準を満たすセマンティック情報を有する。SMSホストは、SMS要求側１８０８が適格SMP１８０２を発見するための適切な特権を有するか否かを確認するためにアクセス制御を実行し得ることに留意されたい。言い換えれば、SMS要求側１８０８にSMPを発見する権限が与えられていなければ、SMSホストは対応するsmpIDをSMS要求側に送信できない。
図２６のステップ２６１３：適格SMP１８０２のsmpIDを受信した後、SMS要求側１８０８は、SMP検索要求を送信して、ステップ２６１２で発見されたSMP１８０２のうちの１つを検索し得る。
図２６のステップ２６１４：SMP検索要求を受信した後、SMSホストは、対応するSMP１８０２の表現を含む応答を送信し得る。SMSホストは、SMS要求者１８０８がSMPの表現を検索するための適切な特権を有するか否かを確認するためにアクセス制御を行い得ることに留意されたい。言い換えれば、SMS要求側１８０８にSMPの表現を検索する権限を与えられていない場合、SMSホストは適切なエラーコードをSMS要求側に送信し得る。
図２６に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２６に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２６に示すステップを実行する。図２６に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２６に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
（仮想セマンティックマッシュアップリソース生成（セマンティックマッシュアップのタスク１））
VSMR１８０４は、SMSホストまたはVSMRホストに存在し得るリソースのタイプとみなされる。任意のVSMR１８０４としては、vsmrID、smpID、smrsStoreType、smrsID、memberStoreType、mashupMemberID、resultGenType、periodForResultGen、smpInputPara、smrs、mashupMember、＜semanticDescriptor＞または＜subscription＞パラメータが挙げられ得る。これらのパラメータ各々は、VSMR１８０４の属性または子リソースであり得ることに留意されたい。
vsmrIDパラメータは、このVSMR１８０４のIDを示す。vsmrIDパラメータは、VSMRリソースのURIとして表され得る。
smpIDパラメータは、どのSMPリソースがVSMRリソースに適用されるかを示す。
smrsStoreTypeパラメータは、どのセマンティックマッシュアップ結果が記憶されるべきであるかを示す。具体的には、smrsStoreType＝“Child Resource”である場合、このVSMR１８０４のマッシュアップ結果は、このVSMR１８０４の子リソースとして記憶され得る。smrsStoreType=“Reference”である場合、このVSMR１８０４のマッシュアップ結果は、SMRSリソース（VSMR１８０４とは異なるリソース）に記憶され得る。SMRSリソースがVSMR１８０４のマッシュアップ結果を記憶するために適用される場合、SMRSリソースのURIは、このVSMR１８０４のsmrsIDパラメータによって識別され得ることに留意されたい。
smrsIDパラメータは、このVSMR１８０４のマッシュアップ結果を記憶しているSMRSリソースの識別子を示す。smrsStoreTypeの値が“Reference“ではない場合、smrsIDパラメータは使用できないことに留意されたい。
memberStoreTypeパラメータは、このVSMR１８０４のマッシュアップメンバを記憶する方法を示す。具体的には、memberStoreType=“URI Only“である場合、VSMR１８０４は、各メンバリソースのURIを維持するためにmashupMemberIDパラメータ（次で説明する）を使用し得る。memberStoreType=“URI and Value“である場合、VSMR１８０４は、mashupMemberパラメータを使用して、各メンバリソースのURIおよび値の両方を維持し得る（例えば、“FindParkingLot”アプリケーションでは、VSMR１８０４は、各メンバリソースのparkingLotStatus、parkingLotLocation、parkingLotRateおよびparkingLotURIを維持し得る）。
mashupMemberIDパラメータは、VSMR１８０４のマッシュアップメンバの識別子を示す。このパラメータの値はリストである。mashupMemberパラメータが、その子リソースとしてVSMR１８０４の直下に位置している場合（例えば、memberStoreType=“URI Only“である場合）、このパラメータは使用できない。
mashupMemberパラメータは、smpIDパラメータによって示される、対応するSMP１８０２のmemberFilterに記述される基準に基づいてオリジナルリソースから選択され得るマッシュアップメンバのセットを含む。
resultGenTypeパラメータは、VSMR１８０４がマッシュアップ結果をどのように生成するかを意味する。具体的には、resultGenType=“When VSMR Is Created“である場合、マッシュアップ結果は、VSMR１８０４が生成されるときに生成され得る。resultGenType=“When SMS Requestor Requests“である場合、マッシュアップ結果は、SMS要求側１８０８がVSMR１８０４のマッシュアップ結果を検索しようとしたときに計算および生成される。resultGenType=“Periodically“である場合、マッシュアップ結果は定期的に計算および生成され得る（期間の長さはperiodForResultGen属性によって特定される）。resultGenType=“When A Mashup Member Is Updated“である場合、マッシュアップ結果はVSMR１８０４のマッシュアップメンバに対して更新が行われる度に計算および生成され得る。この属性の値はリストであり、例えば、複数のイベントは、VSMR１８０４に対するマッシュアップ結果を計算して生成するためにトリガされ得ることに留意されたい。
periodForResultGenパラメータは、VSMR１８０４に対してセマンティックマッシュアップ結果を再計算し生成するための期間を示す。セマンティックマッシュアップ結果を再計算する時間になったとき、VSMR１８０４をホストするSMSホストは、各マッシュアップメンバの最新表現がまだ取得されていなければ検索し得る。この属性は、resultGenType=“Periodically“である場合に使用され得る。
smpInputParaパラメータは、マッシュアップ結果を計算するために必要とされ得る入力パラメータの値を含む。これらの入力パラメータのタイプは、このVSMR１８０４のsmpIDパラメータによって識別される、対応するSMPリソースの＜inputDescriptor＞によって指定され得る。
smrsパラメータは、VSMRリソースのマッシュアップ結果を記憶する。smrsStoreTypeの値が“Child Resource”ではない場合、smrsパラメータは使用できないことに留意されたい。
＜semanticDescriptor＞パラメータは、どの種類のSMSがこのVSMR１８０４によって提供されるかを示す。
＜subscription＞パラメータは、このVSMR１８０４に関する購読情報を含む。
セマンティックマッシュアッププロファイル発見手順を介してSMPリソースを取得した後、SMS要求側１８０８は、発見されたSMPリソースを適用することによってVSMR１８０４を生成し得る。VSMR１８０４を生成する手順は以下で詳述する。
図２８のステップ２８１１：SMS要求側１８０８がSMP１８０２を発見し検索した後、SMS要求側１８０８はVSMR生成要求をSMSホスト１８１０に送信し得る。VSMR生成要求は、適用されるSMP１８０２のURI（例えば、smpID属性の値）、resultGenTypeの値（マッシュアップ結果の生成方法を示す）、および入力パラメータ（適用されるSMP１８０２のinputDescriptor属性によって定義および記述され得る）を含み得る。入力パラメータは、メタデータモデル、例えば、RDFトリプルによって記述され得る。例えば、新しいVSMRを生成するために（図２５に記述されている）“SuitableParkingLot”SMP１８０２が適用される場合、VSMR生成要求の入力パラメータは、図２７のように記述され得る。
図２８のステップ２８１２：VSMR生成要求を受信した後、SMSホスト１８１０は、入力パラメータがSMP１８０２（smpIDによって識別される）の要件（例えば、inputDescriptor属性のメタデータ）を満たし得るかどうかを最初に確認し得る。例えば、（図２５に記述されている）「SuitableParkingLot」SMP１８０２が適用される場合、VSMR生成要求には２つの入力パラメータ（例えば目的地の経度および緯度）があるはずである。言い換えれば、SMSホストは、VSMR生成要求のみを受諾し得るが、VSMR生成要求には、正確に２つの入力パラメータ（そのタイプはそれぞれ経度および緯度であり得る）が含まれ、そうでなければ、SMSホストはVSMR生成要求を拒否し、SMS要求側にエラーコードを返し得る。
図２８のステップ２８１３：受信したVSMR生成要求が有効である場合、SMSホストは、ステップ２８１１のVSMR生成要求に含まれるものと同じsmpIDおよび同じ入力パラメータを有する既存のVSMRが生成されたか否かを確認し得る。
図２８のステップ２８１４：VSMR生成要求と同じsmpIDおよび入力パラメータを有する既存のVSMRがあり、かつSMS要求側１８０８がこの既存のVSMRにアクセスすることが許可される場合［通常、SMSホストは、事前設定され得るアクセス制御ポリシーのセットを維持し得る。SMSホスト内の各リソース（VSMRを含む）は、アクセス制御を実行するためにそれらのアクセス制御ポリシーのうちのいずれかを適用し得る。］（例えば、ステップ２８１４（ａ））、SMSホストはこの既存のVSMRのURIをSMS要求側１８０８に返し得る（例えば、ステップ２８２０に進む）。そうでなければ（例えば、VSMR生成要求と同じsmpIDおよび入力パラメータを有する既存のVSMRが、SMS要求側１８０８にアクセスすることを許可しないか、またはそのような既存のVSMRが存在しない）、SMSホストは新しいVSMRを生成し始め得る（例えば、ステップ２８２５に進む）。
図２８のステップ２８１５：SMSホストは、SMSホストに適用されるアクセス制御ポリシーを確認することによって、SMS要求側１８０８がこの対応するタイプのSMP１８０２に対してVSMRを生成することを許可されているかどうかを判断するべきである。SMS要求側１８０８がVSMRを生成する権限が与えられていない場合、SMSホストはその不許可を示す適切なエラーコードをSMS要求側１８０８に返し得るが、そうでなければ、ステップ２８１６に進む。
図２８のステップ２８１６：SMSホストは、VSMR要求に与えられたsmpIDによって示される、対応するSMP１８０２のmemberFilter属性に含まれるセマンティック情報に基づいてSPARQLクエリを生成することによって、新たなVSMRのマッシュアップメンバとなるように適切なオリジナルリソースを最初に選択し得る。SPARQLクエリは、ステップ２８１７（ａ）およびステップ２８１７（ｂ）において“semanticFilter”として含まれ得る。
図２８のステップ２８１７：サービス層に集中セマンティックグラフストア２８０２が存在する場合、SMSホストは、適切なオリジナルリソースのURIを見つけるために、“semanticFilter”を含むセマンティック発見を集中セマンティックグラフストア２８０２に送信し得る（例えば、ステップ２８１７（ａ））。集中セマンティックグラフストア２８０２が存在しない場合、SMSホストは、適切なオリジナルリソースのURIを見つけるために、セマンティック発見をその登録されたリソースホスト２８０４に送信し得る（例えば、ステップ２８１７（ｂ））。
図２８のステップ２８１８：集中セマンティックグラフストア２８０２がセマンティック発見要求を受信すると（例えばステップ２８１８（ａ））、集中セマンティックグラフストア２８０２は維持されているRDFトリプルを検索し、適格オリジナルリソースのURIをSMSホストに返し得る［適格オリジナルリソースは、適用されるSMP１８０２のmemberFilter属性の要件または基準を満たすオリジナルリソースとして定義される。例えば、”SuitablePakringLot”SMP１８０２では、memberFilter属性は、目的地までの距離が１マイル未満の駐車場である適格リソースを定義する。］。リソースホストがセマンティック発見要求を受信すると（ステップ２８１８（ｂ））、リソースホストはローカルセマンティックグラフストアを構築し、ローカルセマンティックグラフ全体でRDFトリプルを検索し、適格オリジナルリソースのURIをSMSホストに返し得る。適格オリジナルリソースのURIをSMSホストに返す前に、集中セマンティックグラフストア２８０２またはリソースホスト２８０４は、SMSホストがそれらのオリジナルリソースを発見するための適切な特権を有するか否かを確認できることに留意されたい［ローカルセマンティックグラフストアは、リソースホスト２８０４によって一時的に維持され、例えば、ローカルセマンティックグラフストアは、リソースホストの１つの機能または一部分である。］。集中セマンティックグラフストア２８０２またはリソースホスト２８０４はさらに、SMS要求側１８０８がVSMR１８０４にそれらのオリジナルリソースを含める（そうすることによって、SMS要求側の情報（例えばID）は、ステップ２８１７でセマンティック発見要求に含まれ得る）ための適切な特権を有するか否かを確認し得ると本明細書では考えられる。SMSホストがオリジナルリソースを発見する権限が与えられていない（あるいは、SMS要求側１８０８がVSMR１８０４にオリジナルリソースを含めることができない）場合、集中セマンティックグラフストア２８０２またはリソースホスト２８０４はオリジナルリソースのURIをSMS要求側１８０８に送信できない。
図２８のステップ２８１９：適切なオリジナルリソースのURIを取得した後、SMSホストは対応するVSMR１８０４を生成し得る。新たなVSMRのsmpIDおよびresultGenTypeパラメータの値は、VSMR生成要求に含まれるものと一致し得るが、新たなVSMRのsmrsパラメータの値は空であり得る。mashupMemberパラメータは、ステップ２８１８から取得され得る適格オリジナルリソースおよびそれらのURIを含み、例えば、それらの適格オリジナルリソースは、対応するVSMRのマッシュアップメンバとなる。
図２８のステップ２８２０：要求されたVSMRを首尾よく生成した後、SMSホストは、VSMRのURIまたはVSMRのSMRSのURIをSMS要求側１８０８に返し得るため、SMS要求側１８０８は、後でVSMRのコンテンツ（例えばマッシュ結果）を検索し得る。応答メッセージはまた、SMS要求側に対して生成されたVSMRのマッシュアップメンバの数を含み得る。この情報は、SMS要求側１８０８が、ステップ２８１８において適格メンバリソースが見つからない（例えば、VSMRがマッシュアップメンバを有していない）状況、または有効なマッシュアップ結果を生成するのに適格メンバリソースの数が十分ではない状況を認識し得るため有用であり得る。
図２８に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２８に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２８に示すステップを実行する。図２８に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２８に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
首尾よくVSMRを生成した後、他のSMS要求側１８０８はVSMRを発見し使用し得る（または同じSMS要求側１８０８はVSMRを使用できる）。
仮想セマンティックマッシュアップリソース発見（セマンティックマッシュアップのタスク２）
VSMR発見とは、生成されたVSMR１８０４が、VSMR１８０４によって提供されるサービスに関心がある他のSMS要求側１８０８によって発見され得ることを意味する。したがって、既存のVSMR１８０４は、システム効率を改善するために他のSMS要求側１８０８によって再利用され得る。例えば、スタジアムでフットボールの試合があるとき、何万人ものユーザがスタジアムの近くの適切な駐車場を見つけることを要求する（例えば目的地は同じである）場合がある。次に、スタジアム近くの適切な駐車場を見つけるサービスを提供するVSMR１８０４はユーザにより再利用され得るため、異なるユーザが必ずしも実際に同じタイプのSMSを提供する独自のVSMR１８０４を生成する必要がない。
図２９に示すように、VSMR発見手順は以下のステップを含み得る。
図２９のステップ２９１１：特定のSMSに関心があるSMS要求側は、VSMR発見要求をSMSホスト（またはVSMRホスト２３０２）に送信する。VSMR発見要求は、SMS要求側によって要求されたSMSのタイプに基づくSPARQLクエリを含むvsmrFilterを含み得る。
図２９のステップ２９１２：VSMR発見要求を受信した後、SMSホストは、ローカルセマンティックグラフストアを構築し、ローカルセマンティックグラフストアでRDFトリプルを検索し、SMS要求側によって生成されるVSMR発見要求の要件と一致するVSMRのリストを返し得る。サービス層に中央セマンティックグラフストアがある場合、SMSホストはさらに、VSMR発見要求を中央セマンティックグラフストアにリレーし得る。中央セマンティックグラフストアは、RDFトリプルを検索し、一致したVSMRのURIのリストをSMSホストに返し得る。その結果、SMSホストは一致したVSMRリソースのURIのリストをSMS要求側にリレーする。SMSホストまたは中央グラフストアは、SMS要求側１８０８が一致したVSMRを発見するための適切な特権を有するか否かを確認するためにアクセス制御を行い得ることに留意されたい。言い換えれば、SMS要求側１８０８にVSMRを発見する権限が与えられていなければ、たとえVSMRがVSMR発見要求の要件に一致していてもSMSホストはVSMRのURIをSMS要求側１８０８に送信できない。
図２９に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図２９に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図２９に示すステップを実行する。図２９に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図２９に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
仮想セマンティックマッシュアップリソース検索（セマンティックマッシュアップのタスク３）
SMS要求側１８０８は、以下のステップを適用することによってマッシュアップ結果のコンテンツを検索し得る。
図３０のステップ３０１０：VSMR１８０４のマッシュアップ結果を検索する前に、SMS要求側１８０８は、まず対応するVSMR１８０４を生成または発見し得る。
図３０のステップ３０１１：VSMR１８０４を生成または発見した後、SMS要求側１８０８はVSMRリソースのURIを知っているはずである。したがって、SMS要求側１８０８は、VSMRリソースのURIを含むVSMR検索要求をSMSホストに送信し得る［本質的に、VSMR検索要求とは、VSMR１８０４のマッシュアップ結果を検索することである。また、SMS要求側１８０８は、SMRS検索要求を送信して対応するVSMR１８０４のマッシュアップ結果を検索し得る。］。
図３０のステップ３０１２：SMSホストは、SMS要求側１８０８がVSMR１８０４にアクセスするための適切な特権を有するか否かを確認すべきである。SMS要求側１８０８がVSMR１８０４にアクセスできない場合、SMSホストはその不許可を示す適切なエラーコードを返し得るが、そうでなければ、ステップ３０１３に進む。
図３０のステップ３０１３：VSMR１８０４がマッシュアップ結果を生成するためにさまざまな方法があり得るが、これは、resultGenType（例えば、VSMR１８０４の１つの属性）によって定義され得る。具体的には、VSMRリソースのresultGenTypeパラメータの値が“When SMS Requestor Requests”である場合、VSMR検索要求を受信すると、VSMR１８０４はそのマッシュアップメンバの表現を検索し始め得る（例えば、ステップ３０１３に進む）。そうでなければ、VSMR１８０４は、現在のマッシュアップ結果を用いて直接応答することができ（例えば、ステップ３０１７に進む）、これは、VSMRリソースの＜smrs＞子リソースによって暗示される。resultGenTypeの詳細な説明を表１０に示す。
図３０のステップ３０１４：（SMS要求側１８０８がタイムアウト期間中に応答を受信しないという理由故に）SMS要求側１８０８がＶＳＭＲ検索要求を再送信するのを回避するために、マッシュアップ結果を計算するには長い時間がかかる場合があり、SMSホストは、SMSホストがVSMR検索要求を受信してマッシュアップ結果を計算していることを示すために、（VSMR１８０４のマッシュアップ結果を含めることなく）確認を直ちにSMS要求側１８０８に送信し得る。
図３０のステップ３０１５：SMSホストは、マッシュアップメンバリソース検索要求を各マッシュアップメンバに送信し得る。各マッシュアップメンバリソース検索要求は、対応するマッシュアップメンバのURIを含み得る。
図３０のステップ３０１６：マッシュアップメンバリソース検索要求を受信した後、リソースホストは対応するメンバリソースの表現を用いてSMSホストに応答し得る。リソースホストはまた、SMSホストがメンバリソースを検索するための適切な特権を有するか否かを確認するためのアクセス制御を実行し得ることに留意されたい（一例では、リソースホストはSMS要求側１８０８がメンバリソースを検索するための適切な特権を有することも確認し得るが、そうすることによって、SMS要求側の情報（例えば、ID）は、ステップ３０１５において、メンバリソース検索要求に含まれ得る）。SMSホストがメンバリソースを検索する権限を与えられていない場合（またはSMS要求側１８０８がメンバリソースを検索する権限を与えられていない場合）、リソースホストはメンバリソースの表現をSMS要求側に送信できず、代わりに、適切なエラーコードを返し得る。
図３０のステップ３０１７：マッシュアップメンバの表現を受信した後、SMSホストはこれらの表現をVSMRリソースに記憶し得る（これらの表現を記憶する満了期限は、オリジナルリソースにおけるこれらの表現の満了期限に基づき得ることに留意されたい）。例えば、findParkingLotの例では、VSMRリソースは、（目的地近くの駐車場として記述される）そのマッシュアップメンバの状態、位置情報および駐車料金情報を取得し得る。したがって、図３１に示すように、この情報はVSMRリソース下に記憶され得る（これは、この情報をVSMR１８０４下に記憶するために使用されなくてもよい、例えば、VSMR１８０４はオリジナルリソースのURIを単に記憶し、それらの表現を必要に応じて検索し得ることに留意されたい。）。その後、SMSホストはマッシュアップ機能を実行するが、このマッシュアップ機能は、（このVSMR１８０４によって適用される）対応するSMP１８０２のfunctionDescriptor属性に記述されている。マッシュアップ機能の出力は、VSMR１８０４内またはSMRS１８０６内に記憶され得る。findParkingLotの例では、出力は、最適な駐車場の状態、位置および駐車料金情報であり得る。
図３０のステップ３０１８：SMSホストは、ステップ３０１１からのVSMR検索要求に応答するために、SMRS１８０６に記憶されているマッシュアップ結果をSMS要求側１８０８に送信する。
図３０に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３０に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３０に示すステップを実行する。図３０に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３０に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
また、SMS要求側１８０８は、マッシュアップ結果が更新されるとSMSホストがマッシュアップ結果をSMS要求側１８０８に自動的に送信するようにVSMRリソースを購読し得る（例えば、resultGenType=“Periodically“である場合、マッシュアップ結果は定期的に計算されるべきであり、SMSホストは、更新されたマッシュアップ結果を、VSMR１８０４を購読するSMS要求側に送信し得る）。以下のステップが適用され得る。
ステップ３２１０：VSMR１８０４を購読する前に、SMS要求側１８０８は対応するVSMR１８０４を既に生成または発見している可能性がある。
図３２のステップ３２１１：図３２に示すように、SMS要求側１８０８は、VSMR購読要求をSMSホストに送信する。VSMR購読要求は、SMS要求側１８０８のURI（例えば、どこに通知が送信されるべきかを意味する購読者のURI）、notificationContentType（通知のコンテンツタイプを示す）、およびeventNotificationCriteria（SMS要求側に通知を送信するSMSホストのためのトリガイベントを示す）を含む。通常、VSMRリソースについては、マッシュアップ結果が更新され、通知メッセージのコンテンツが更新されたマッシュアップ結果（例えば、findParkingLotアプリケーションでは、マッシュアップ結果は、最適な駐車場のURI、状態、位置情報および駐車料金であり得る）になると、SMSホストは通知をSMS要求側１８０８に送信するようにトリガする。
図３２のステップ３２１２：VSMR購読要求を受信した後、SMSホストは、そのnotificationContentTypeおよびeventNotificationCriteriaに関連するVSMRリソースの購読リストにSMS要求側１８０８を追加し得る。
図３２のステップ３２１３：SMSホストは、SMS要求側１８０８が首尾よくVSMRリソースを購読したことを示す応答メッセージをSMS要求側１８０８に送信し得る。
図３２のステップ３２１：VSMR１８０４のマッシュアップ結果が更新されると、SMSホストは直ちに通知をSMS要求側に送信し得る。通知メッセージのコンテンツはnotificationContentTypeによって示される。
図３２のステップ３２１５：SMS要求側１８０８は、SMS要求側１８０８が首尾よく通知メッセージを受信したことを示す応答メッセージをSMSホストに送信し得る。
図３２に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３２に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３２に示すステップを実行する。図３２に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３２に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
（共同仮想セマンティックマッシュアップリソース生成および検索）
前述の通り、SMS要求側１８０８は、まずVSMR１８０４を生成し得るが、その後、生成されたVSMRリソースをホストするSMSホストは、生成されたVSMRリソースを将来再利用するために生成されたVSMRリソースのURIをSMS要求側１８０８に通知する（例えば、SMS要求側１８０８は、将来的にVSMR検索要求をURIに送信することによってVSMRリソースのコンテンツを検索し得る）。
しかしながら、SMS要求側１８０８は将来的にVSMRのマッシュアップ結果を検索できないため、VMSRリソースのURIについてSMS要求側１８０８に通知することが必要ではない状況が存在する。言い換えれば、マッシュアップ結果を取得した後、SMS要求側１８０８は、もはやVSMR１８０４の将来のマッシュアップ結果に関心を持たない場合がある。したがって、生成されたVSMR１８０４のURIをSMS要求側に送信する代わりに、SMSホストは、VSMR１８０４を生成した後にマッシュアップ結果を直ちに計算し、マッシュアップ結果をSMS要求側に送信し得る。これは、共同仮想セマンティックマッシュアップリソース生成および検索と呼ばれる。
SMS要求側１８０８は、以下のステップを適用して、VSMR１８０４を共同で生成し、生成されたVSMR１８０４のマッシュアップ結果を検索し得る。
図３３のステップ３３１０：新たなVSMRリソースを共同で生成および検索する前に、SMS要求側１８０８は、SMSホストから対応するSMPリソースを既に発見している可能性がある。
図３３のステップ３３１１：共同VSMR生成および検索手順は、（VSMR生成手順においてVSMR生成要求を送信するのではなく）SMS要求側１８０８がセマンティッククエリ要求を送信することによってトリガされる。セマンティッククエリは、smpIDおよびsmpInputParaの値を含み得る。例えば、findSuitablePakingLotingアプリケーションでは、セマンティッククエリ要求は、”find the SuitableParkingLot for me where my destination is ［-73.985833°，40.748417°］”と表現され得るが、青色で強調されている情報（SuitableParkingLot）は、ｓｍｐＩＤの値を含み、オレンジ色で強調されている情報（［-73.985833°，40.748417°］”）は、smpInputParaの値を含む。共同VSMR生成および検索法が適用される場合、resultGenTypeの値は、デフォルトで“When VSMR Is Created”に設定される（resultGenTypeの詳細な説明は、表１０に示される）のであり、例えば、VSMR１８０４のマッシュアップ結果は、VSMR１８０４がSMSホストで生成されたときに計算され得ることに留意されたい。
図３３のステップ３３１２：セマンティッククエリ要求を受信した後、SMSホストは、セマンティッククエリ要求のsmpID値によって特定される対応するSMPリソースを適用することによって、まずVSMR１８０４を生成し得る。SMSホストがVSMR１８０４を生成する手順は、図２８で説明したステップ２８１２～２８１９に続く。
図３３のステップ３３１３：首尾よくリソースを生成した後、SMSホストは、図３０のステップ３０１４～３０１６を実行することによって、VSMRリソースにマッシュアップ結果を生成するように直ちにトリガし得る。
図３３のステップ３３１４：VSMR１８０４において首尾よくマッシュアップ結果を生成した後、SMSホストは、ステップ３３１１においてセマンティッククエリに応答するためにマッシュアップ結果をSMS要求側１８０８に送信し得る。次いで、SMSホストは、生成されたVSMRリソースを消去し得る。
図３３に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３３に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３３に示すステップを実行する。図３３に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３３に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
（仮想セマンティックマッシュアップリソース維持（セマンティックマッシュアップのタスク４））
VSMR１８０４維持は、１）VSMRリソースのマッシュアップメンバとなる新たな適格リソースを追加すること、２）VSMRリソースの削除されたもしくは適格でないマッシュアップメンバを消去すること、または３）VSMRリソースのマッシュアップメンバの表現を更新することを含み得る。VMSRリソース維持は、SMSホストまたはリソースホストによって初期化され得る。
SMSホストによるオリジナルリソースの変更確認を以下に開示する。SMSホストは、以下のステップを適用することによってVSMRリソース維持を開始し得る。
図３４のステップ３４１０：SMSホスト１８１０がVSMRリソース維持を開始する前に、VSMR１８０４はSMSホスト１８１０内に既に作成されている可能性がある。VSMR１８０４のマッシュアップメンバの１つがリソースホスト１ ３４０２内のオリジナルリソース（例えばrsc1）であると仮定する。
図３４のステップ３４１１：SMSホストは、リソース検索要求をそのマッシュアップメンバに送信することによって、オリジナルリソースの変更を確認し得る（例えば、VSMR維持を実行する）。図３４に示すように、SMSホストは、VSMRのマッシュアップメンバの１つ、例えばリソースホスト１ ３４０２によってホストされるrsc1にリソース検索要求を送信する。
図３４のステップ３４１２：リソース検索要求を受信した後、リソースホスト１は対応する応答をSMSホスト１８１０に送信し得る。
図３４のステップ３４１３（ａ）：ステップ３４１２の応答メッセージが単にrsc1の表現を含み、rsc1が依然としてVSMR１８０４のマッシュアップメンバに該当する（例えば、rsc1は、（VSMR１８０４によって適用されるSMPの１つの属性である）memberFilterに記述される基準を満たす）場合、SMSホスト１８１０は、rsc1の表現に基づいてマッシュアップメンバの表現を更新し、ステップ３４１４に進み得る。
図３４のステップ３４１３（ｂ）：ステップ３４１２の応答メッセージが、rsc1が存在しない（例えば、“findSuitableParkingLot”アプリケーションで道路工事中にいくつかの路上駐車メータが取り除かれている場合がある）ことを示すか、またはSMSホスト１８１０が、rsc1がもはやVSMRリソースのマッシュアップメンバに該当しないと知った場合、rsc1はVSMRリソースのマッシュアップメンバから消去され得る。あるいは、SMSホスト１８１０は、セマンティック発見を送信することによって、新たなリソースがVSMR１８０４のマッシュアップメンバになることを確認し得る（VSMRリソースの新たなマッシュアップメンバを見つける手順は、図２８のステップ２８１５～２８１７に適用され得ることに留意されたい）。新たなリソース（VSMRリソースのマッシュアップメンバに該当する）を見つけることができた場合、これらの新たなリソースを追加してVSMR１８０４のマッシュアップメンバにすることができ、SMSホスト１８１０はこれらの新たなリソースの表現を検索し得る。
図３４のステップ３４１４：VSMR１８０４リソースのマッシュアップメンバおよびそれらの対応する表現を更新した後、SMSホスト１８１０は、resultGenTypeの値が“When A Mashup Member Is Updated”である場合、そのマッシュアップメンバにVSMR１８０４の（適用されたSMPリソースのfunctionDescriptor属性に記述される）マッシュアップ機能を実行することによってマッシュアップ結果を再計算し得る（例えば、SMSホスト１８１０は、何らかの更新がVSMR１８０４のマッシュアップメンバに対して行われたときにマッシュアップ結果を再計算し得る）。そうでない場合（例えば、resultGenTypeの値が“When A Mashup Member Is Updated”ではない）、SMSホスト１８１０はマッシュアップ結果を再計算しなくてもよい。
図３４のステップ３４１５：マッシュアップ結果を更新した後、SMSホストは、マッシュアップ結果をSMRS１８０６に記憶し、保留中の検索要求に基づいて、またはコンテンツ（例えば、VSMR１８０４のマッシュアップ結果）の購読により、それらをSMS要求側１８０８に送信し得る。
図３４に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３４に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３４に示すステップを実行する。図３４に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３４に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
リソースホストによるオリジナルリソースの変更報告を以下に開示する。リソースホスト２８０４はまた、オリジナルリソースへの変更を先回りして報告することによってVSMR維持を開始し得る。リソースホストがオリジナルリソースに対する何らかの変更を先回りして報告する前に、SMSホスト１８１０（またはVSMRホスト２３０２）は、対応するVSMRリソースのマッシュアップメンバであるこれらのオリジナルリソースをまず購読し得る。次のステップが適用される。
図３５のステップ３５１０：VMSRのマッシュアップメンバを購読する前に、SMSホストは既にVSMRリソースを生成している可能性がある。rsc1（リソースホスト１によってホストされているリソースである）はVSMRリソースの１つのマッシュアップメンバであると仮定し、図３５は、rsc1を購読しているSMSホストのための手順を示す。他のオリジナルリソースを購読しているSMSホスト１８１０は、ｒｓｃ１を購読しているSMSホスト１８１０と同じステップを実行し得ることに留意されたい。
図３５のステップ３５１１：SMSホスト１８１０は、rsc1を購読するために、リソース購読要求をリソースホスト１に送信し得る。リソース購読要求は、notificationContentType、eventNotificationCriteriaおよびmashupMemURIを含み得る。notificationContentTypeは、通知メッセージ内のコンテンツタイプを意味する。eventNotificationCriteriaは、リソースホスト１ ３４０２が通知をSMSホスト１８１０に送信するためのトリガイベントを示す。通常、rsc1に対して行われたいかなる変更も、リソースホスト１による通知の送信をトリガし得る。mashupMemURIは、VSMRのマッシュアップメンバのURIを示し、これは通知がどこに送信されるべきかを識別する。
図３５のステップ３５１２：リソース購読要求を受信した後、リソースホスト１は、そのnotificationContentTypeおよびeventNotificationCriteriaに関連するrsc1の購読リストにmashupMemURIを追加し得る。
図３５のステップ３５１３：リソースホスト１ ３４０２は、SMSホストがリソースホスト１のrsc1を首尾よく購読したことを示す応答メッセージをSMSホストに送信し得る。
図３５のステップ３５１４：SMSホスト１８１０がrsc1を購読した後、rsc1の表現に対して何らかの更新が行われると、リソースホスト１ ３４０２は、リソース購読要求のmashupMemURIによって識別されるURIに通知を送信し得る。
図３５のステップ３５１５：通知を受信した後、SMSホスト１８１０は対応するマッシュアップメンバの表現を変更し得る。
図３５のステップ３５１６：首尾よく通知を受信した後、SMSホスト１８１０は、通知が首尾よく受信されたことを示すために、応答をリソースホスト１ ３４０２に送信し得る。
図３５に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３５に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３５に示すステップを実行する。図３５に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３５に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
ステップ３５１５でrsc1の表現が変更された後、rsc1はVSMR１８０４の適格マッシュアップメンバではない可能性があることに留意されたい。したがって、VSMR１８０４は、そのマッシュアップメンバからrsc1を消去し、購読削除要求をリソースホスト１に送信し得る。VSMRのマッシュアップメンバからrsc1を消去した後、VSMR１８０４は、図３４のステップ３４１３（ｂ）およびステップ３４１４を実行することによって、そのマッシュアップメンバとなる新たな適格オリジナルリソースの検索をトリガし得る。
リソースホストによるオリジナルリソースの消去報告を以下に開示する。（VSMR１８０４のマッシュアップメンバである）いくつかのオリジナルリソースは、それらのオリジナルリソースの生成側または他のサービス層エンティティによってリソースホストから消去され得る。次いで、リソースホストは、通知を送信し、対応するオリジナルリソースの消去についてVSMR１８０４に通知し得る。リソースホストがオリジナルリソースの消去を報告するステップは、次のように示され得る。
図３６のステップ３６１０：SMSホスト１８１０が既にVSMRリソースを作成し、rsc1（リソースホスト１によってホストされるリソースである）がVSMRリソースの１つのマッシュアップメンバであると仮定する一方、SMSホスト１８１０は既にrsc1を購読しており、例えば、rsc1に何らかの変更が行われていれば、リソースホストは通知をSMSホストに送信し得る。
図３６のステップ３６１１：図３６に示すように、rsc1がリソースホスト１から消去された場合、リソースホスト１は通知メッセージをSMSホスト１８１０に送信し、rsc1が消去されたことをVSMR１８０４に通知し得る。
図３６のステップ３６１２：首尾よく通知メッセージを受信した後、SMSホストは、通知メッセージが受信されたことを確認するために応答メッセージを送信し得る。
図３６のステップ３６１３：SMSホスト１８１０は、VSMR１８０４の、rsc1に関連付けられた対応するマッシュアップメンバを削除し得る。
図３６のステップ３６１４：SMSホスト１８１０は、VSMR１８０４のマッシュアップメンバになり得る新たなリソースを見つけるためにトリガし得る。VSMRリソースの新たなマッシュアップメンバを見つけるための手順は、図２８のステップ２８１６～２８１８を適用し得る。（VSMRリソースのマッシュアップメンバに該当する）新たなリソースが見つかった場合、これらの新たなリソースを追加してVSMRリソースのマッシュアップメンバにすることができ、SMSホスト１８１０はさらにこれらの新たなリソースの表現を検索し得る。
図３６のステップ３６１５：VSMRリソースのマッシュアップメンバを更新した後、SMSホスト１８１０は、resultGenTypeの値が“When A Mashup Member Is Updated”である場合、そのマッシュアップメンバにVSMR１８０４の（適用されたSMPリソースのfunctionDescriptor属性に記述される）マッシュアップ機能を実行することによってマッシュアップ結果を更新または再計算し得る（例えば、SMSホスト１８１０は、更新がVSMR１８０４のマッシュアップメンバに対して行われたときにマッシュアップ結果を再計算し得る）。そうでない場合（例えば、resultGenTypeの値が“When A Mashup Member Is Updated”ではない）、SMSホスト１８１０はマッシュアップ結果を再計算しなくてもよい。
図３６のステップ３６１６：マッシュアップ結果を更新した後、SMSホスト１８１０は、マッシュアップ結果をSMRS１８０６に記憶し、それらをSMS要求側１８０８に送信し得る。SMS要求側１８０８は、VSMRリソースのコンテンツを検索するかまたはVSMR１８０４のコンテンツ（例えば、マッシュアップ結果）を購読することを要求する。
図３６に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３６に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３６に示すステップを実行する。図３６に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３６に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
リソースホストによる新たなオリジナルリソースの報告
新たなオリジナルリソースがリソースホストに追加され得るが、これらの新たなオリジナルリソースは、VMSRのマッシュアップメンバに該当し得る。したがって、リソースホストは、新たなオリジナルリソースがそのマッシュアップメンバになり得るかどうかをVMSRに通知し得る。具体的には、以下となる。
図３７のステップ３７１０：SMSホスト１８１０が既にVSMR１８０４を生成しており、rsc1（リソースホスト１ ３４０２によってホストされるリソースである）がVSMR１８０４の１つのマッシュアップメンバであると仮定する一方、SMSホストのVSMR１８０４は既にリソースホスト１ ３４０２を購読している。購読要求は、VSMR１８０４のURI（例えば、購読者のURI）、notificationContentTypeおよびeventNotificationCriteriaを含む。notificationContentTypeパラメータは、通知メッセージ内のコンテンツタイプを意味する。eventNotificationCriteriaパラメータは、いずれかのホストリソースがVSMRのマッシュアップメンバに該当すると、リソースホスト１ ３４０２が通知を送信し得ることを示す。eventNotificationCriteriaパラメータは、ホストリソースがVSMRのマッシュアップメンバに該当するか否かを判断するための情報を含み得る。この情報は、セマンティック発見のsemanticFilterと同じであり得る。
図３７のステップ３７１１：新たなオリジナルリソース、例えばrsc2がリソースホスト１ ３４０２に追加され、rsc2がVSMRのマッシュアップメンバに該当すると仮定する。
図３７のステップ３７１２：リソースホスト１ ３４０２は、（通知とみなされる）VSMRマッシュアップメンバ共同要求をSMSホストに送信し得る。VSMRマッシュアップメンバ共同要求は、VSMRのURI、rsc2のURIおよびrsc2の対応する表現を含み得る。
図３７のステップ３７１３：VMSRは、新たなオリジナルリソースがマッシュアップメンバに該当しているか否か、例えば、VMSRは、新たなオリジナルリソースが（VSMR１８０４によって適用される対応するSMP１８０２の１つの属性である）memberFilterに記述された基準を満たすか否かを確認し得る。
図３７のステップ３７１４（ａ）：rsc2がVSMRマッシュアップメンバに該当していない場合、SMSホストは応答を送信し、rsc2の不適格を示し得る。
図３７のステップ３７１４（ｂ）：rsc2がVSMRマッシュアップメンバに該当する場合、SMSホストはrsc2をVSMRリソースのマッシュアップメンバに追加し得るとともに、SMSホストは応答を送信してrsc2が適格であることを示し得る。
図３７のステップ３７１５：VSMR１８０４は、図３５のステップ３５１１～ステップ３５１３を適用することによって、rsc2を購読し、rsc2の表現への変更に関する自動通知を得ることができる。
図３７のステップ３７１６：SMSホストは、resultGenTypeの値が“When A Mashup Member Is Updated”である場合、そのマッシュアップメンバにVSMR１８０４のマッシュアップ機能を実行することによってマッシュアップ結果を再計算し得る（例えば、SMSホストは、更新がVSMR１８０４のマッシュアップメンバに対して行われたときにマッシュアップ結果を再計算し得る）。そうでない場合（例えば、resultGenTypeの値が“When A Mashup Member Is Updated”ではない）、SMSホストはマッシュアップ結果を再計算しなくてもよい。
図３７のステップ３７１７：マッシュアップ結果を更新した後、SMSホストは、マッシュアップ結果をSMRＳ１８０６に記憶し、それらをSMS要求側１８０８に送信し得る。SMS要求側１８０８は、VSMRリソースのコンテンツを検索するかまたはVSMR１８０４のコンテンツ（例えば、マッシュアップ結果）を購読することを要求する。
図３７に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３７に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３７に示すステップを実行する。図３７に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３７に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
このセクションでは、リソースホストがそれらのオリジナルリソースに対する変更を報告するときのVSMR維持のための全体的な手順が提供される。
図３８のステップ３８１０：VSMR１８０４がSMS要求側１８０８によって既に生成されており、rsc1およびrsc2が現在VSMR１８０４のマッシュアップメンバであると仮定する。rsc1およびrsc2は、それぞれリソースホスト１ ３４０２およびリソースホスト２ ３８０２によってホストされ得ることに留意されたい。VSMR１８０４は周期的にマッシュアップ結果を生成する、例えば、resultGenType=“Periodically”であると仮定する。
図３８のステップ３８１１～３８１４：前述の通り、リソースホスト２８０４がそれらのオリジナルリソースに対する変更を報告することを可能にするために、SMSホストはVSMR１８０４のオリジナルリソースを購読し得る。したがって、図３８に示すように、（VSMR１８０４をホストする）SMSホストは、リソースホスト１ ３４０２およびリソースホスト２ ３８０２が（rsc1およびrsc2に対して行われる）変更をSMSホストに報告することを可能にするために、VSMR購読要求をリソースホスト１ ３４０２およびリソースホスト２ ３８０２それぞれに送信し得る。その結果、リソースホスト１ ３４０２およびリソースホスト２ ３８０２は、VSMR購読要求に応答し、SMSホストが対応するオリジナルリソースを首尾よく購読したかどうかを知らせ得る。
図３８のステップ３８１５～３８１６：rsc1のある表現が変更された場合、リソースホスト１ ３４０２は通知をSMSホストにおいてVSMR１８０４の対応するマッシュアップメンバに送信し得る。
図３８のステップ３８１７～３８１８：SMSホストが通知を受信すると、SMSホストは、ステップ３８１６において、受信した通知のコンテンツに基づいて対応するマッシュアップメンバの表現を更新し得る。次に、SMSホストは、通知を首尾よく受信したことを示すメッセージをリソースホスト１ ３４０２に送信し得る。resultGenType=“When A Mashup Member Is Updated”である場合、SMSホストはマッシュアップ結果を再生成し始め得る。
図３８のステップ３８１９～３８２０：rsc2がリソースホスト２ ３８０２から消去された場合、リソースホスト２ ３８０２は、通知をSMSホストにおいてVSMR１８０４の対応するマッシュアップメンバに送信し得る。
ステップ３８２１～３８２２：SMSホストが通知を受信すると、VSMR１８０４はrsc2に関連付けられているマッシュアップメンバを消去し得る。次に、SMSホストは、通知を首尾よく受信したことを示すメッセージをリソースホスト２ ３８０２に送信し得る。
図３８のステップ３８２３：通常、マッシュアップメンバを削除すると、SMSホストがトリガされ、VSMR１８０４のマッシュアップメンバとなる新たな適格オリジナルリソースを発見するが、このプロセスはVSMR維持を実施するために使用することはできない。セマンティック発見を行った後に、リソースホスト３ ３８０４のrsc3が、適格オリジナルリソースであることが判明したと仮定する。次に、VSMR１８０４は、そのマッシュアップメンバとなるrsc3を追加する。
図３８のステップ３８２４～３８２５：SMSホストは、マッシュアップメンバリソース要求をリソースホスト３ ３８０４に送信することによって、rsc3の表現を検索し得る。リソースホスト３ ３８０４は、rsc3の表現をSMSホストに応答し得る。
図３８のステップ３８２６：SMSホストが応答メッセージを受信した後、VSMR１８０４は、rsc3に関連付けられているリソースメンバの表現を更新し得る。resultGenType=“When A Mashup Member Is Updated”である場合、SMSホストはVSMR１８０４のマッシュアップ結果を再生成し始め得る。
図３８のステップ３８２７～３８２８：リソースホスト３ ３８０４がrsc3に対する変更を報告することを可能にするために、SMSホストは、VSMR購読要求をリソースホスト３ ３８０４に送信することによってrsc3を購読し得る。その結果、リソースホスト３ ３８０４は、VSMR購読要求に応答し、SMSホストがrsc3を首尾よく購読したかどうかを知らせ得る。
図３８のステップ３８２９：（最後の期間の終了時からの累積経過時間をカウントする）タイマが（VSMR１８０４のperiodForResultGen属性によって特定される）期間の長さに達すると、VSMR１８０４は、マッシュアップメンバに対してマッシュアップ機能を実行することによって直ちにマッシュアップ結果を生成し得る。タイマは各期間の終了時にリセットされ得ることに留意されたい。
図３８のステップ３８３０：マッシュアップ結果を更新した後、SMSホストは、マッシュアップ結果をSMRS１８０６に記憶し、それらをSMS要求側１８０８に送信し得る。SMS要求側１８０８は、VSMRリソースのコンテンツを検索することを要求する。いくつかのSMS要求側１８０８が以前にVSMR１８０４を購読している場合、SMSホストは直ちに通知をそれらのSMS要求側１８０８に送信し得ることに留意されたい。
図３８に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図３８に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図３８に示すステップを実行する。図３８に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図３８に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
oneM2Mを以下でより詳細に説明する。このセクションでは、oneM2M機能アーキテクチャ下でSMSをサポートするための、いくつかのアーキテクチャ構成、新たなoneM2Mリソースおよび新たな共通属性、ならびに新たなoneM2M手順を説明する。
第１に、oneM2M機能アーキテクチャ下でセマンティックマッシュアップサービスをサポートするためのアーキテクチャ構成が例示される。
第２に、リソースおよび属性を説明する。新たなリソース各々を操作するためのRESTfulな手順も説明する。SMP１８０２をモデル化し、それらに対する操作（例えば、SMPの生成、SMPの検索、SMPの更新およびSMPの削除）を可能にするために、新たな＜smp＞リソースについて説明する。VSMRをモデル化し、それらに対する操作（例えば、VSMRの生成、VSMRの検索、VSMRの更新およびVSMRの削除）を可能にするために、＜vsmr＞リソースについて説明する。SMRS１８０６をモデル化し、それらに対する操作（例えば、SMRSの生成、SMRSの検索、SMRSの更新およびSMRSの削除）を可能にするために、＜smrs＞リソースについて説明する。parentVSMRは、それらがメンバリソースとして＜vsmr＞によって使用される場合、それらを＜vsmr＞と関連付けるために既存のoneM2Mリソースのための属性（例えば、「共通」属性）として記述される。smpIDは、既存のoneM2Mリソースの属性として記述され、それらが＜smp＞下でセマンティックマッシュアップサービスのためのメンバリソースとして使用されることを示す。
第３に、oneM2M機能アーキテクチャ下にセマンティックマッシュアップサービスを実装するための全体的な手順例について説明する。
oneM2MアーキテクチャにおけるSMS構成を以下に開示する。上記セクションでは、SMP１８０２、VSMR１８０４およびSMRS１８０６（これらは一緒にSMSを提供する）のモジュール設計によってセマンティックマッシュアップがどのように行われるかについて説明する。このようなSMSは、新たなCSF（例えば、SMS CSF）として、oneM2M機能アーキテクチャ下に実装され得る。このSMS CSFは、（例えば、図３９において）CSEに配置され得る。SMS CSFは、SMPホスト１８１０、VSMRホスト２３０２、SMRSホスト２３０４、または３つの組み合わせ（例えば、SMSホスト）の機能の実現であり得る。
図３９は、SMS CSFがIN-CSEに位置している実施例を示す（SMS CSFもASN-CSEまたはMN-CSEによってホストされ得ることに留意されたい）。SMS CSFは、親VSMRを生成し、マッシュアップ結果を計算するためのマッシュアップメンバとして、ASN-CSE1ならびにMN-CSE2 4608およびMN-CSE3のオリジナルリソース、場合によってはサードパーティのサービスまたは他のサービス層を活用する。IN-AE1およびIN-AE2は、SMS CSFを活用してVSMRを生成するため、マッシュアップ結果の計算をトリガするため、またはマッシュアップ結果にアクセスするために、IN-CSEとインタフェースをとるSMS要求側１８０８であり得る。
図３９に示す機能は、後述の図５１Ｃまたは図５１Ｄに示されるもののうちの１つのような無線デバイスまたはその他装置（例えば、サーバ、ゲートウェイ、デバイスまたは他のコンピュータシステム）のメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得ることが理解されよう。図３９に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。IN-CSEは、そのローカルリソース、他のMN-CSEおよびASN-CSEからのリソース、サードパーティからのサービス、またはさらにはOIC等の他のサービス層からのサービスに基づいてＳＭＳを提供し得る。SMS要求側としてのIN-AEは、IN-CSEからのSMSを使用し得る。MN-CSEおよびASN-CSEはリソースホストであり得る。IN-CSEは、SMSホストおよびリソースホストの両方として機能する。
セマンティックマッシュアッププロファイルリソース＜smp＞リソースは、セマンティックマッシュアッププロファイルをモデル化し表現するように記述される。＜smp＞リソースは、セマンティックマッシュアップサービスを提供するoneM2M CSEに提供され得る。あるいは、特別な管理アプリケーションまたはCSEがoneM2M CSEで＜smp＞リソースを生成するように要求し得る。＜smp＞リソースがoneM2M CSE（例えばSMSホスト）で提供または生成されると、SMS要求側１８０８として機能する他のoneM2M CSEまたはAEが＜smp＞リソースを発見および検索し得る。
＜smp＞リソースは、表３で指定された子リソースおよび表４で指定された属性を含み得る。＜smp＞リソースの構造も図４０に示す。本明細書では、いくつかのセマンティックマッシュアッププロファイルは必要ではない場合があり、したがって表３および表４の特定の態様、例えばinpuDescriptorを使用しない場合があると考えられる。
Figure 0007038113000008
Figure 0007038113000009
図４１は、受信側４１０２および発信側４１０４を用いて＜smp＞リソースを操作する（例えば、＜smp＞リソースの生成、検索、更新または削除）例示的な手順を示す。
図４１に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４１に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４１に示すステップを実行する。図４１に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４１に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
図４１では、ステップ４１１１において、発信側４１０４は発信側で何らかの処理を行う。これは、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.1.1節（以下10.1.1.1）等に従うことができる。ステップ４１１２では、発信側４１０４は要求メッセージを受信側４１０２に送信し得る。要求メッセージは、＜smp＞に対する生成メッセージ、検索メッセージ、更新メッセージまたは削除メッセージであり得る。ステップ４１１３では、ステップ４１１２のメッセージを処理する。ステップ４１１４では、ステップ４１１３の処理に基づく。これらのステップは、表５～表８でさらに説明する。＜smp＞を生成する手順は、表５に記載されるように＜smp＞リソースを生成するために用いられ得る。
Figure 0007038113000010
＜smp＞を検索する手順は、表６に記載されるように＜smp＞リソースの属性を検索するために用いられ得る。
Figure 0007038113000011
表７に記載されている＜smp＞を更新する手順を用いて、既存の＜smp＞を更新し得る、例えば、そのinputDescriptorへの更新を行う。一般的な更新手順は、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.3節に記載されている。
Figure 0007038113000012
表８に記載されている＜smp＞を削除する手順を用いて、既存の＜smp＞を削除し得る。一般的な削除手順は、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.4.1節に記載されている。
Figure 0007038113000013
仮想セマンティックマッシュアップリソース＜vsmr＞リソースを用いて、仮想セマンティックマッシュアップリソースをモデル化し表現し得る。SMS要求側１８０８としてのoneM2M CSEまたはAEは、SMS CSFを実装し、SMSホストまたはVSMRホスト２３０２として機能する別のoneM2M CSEで＜vsmr＞リソースを生成するように要求し得る。生成された各＜vsmr＞リソースはセマンティックマッシュアッププロファイル（例えば＜smp＞リソース）に対応し得る。マッシュアップ結果を計算するために＜vsmr＞リソースがどのようにマッシュアップ操作を実行すべきかは、対応する＜smp＞リソースで指定され得る。＜vmsr＞およびその対応する＜smp＞リソースは、同じCSEまたは異なるoneM2M CSEに配置され得るが、＜vsmr＞のsmpID属性により、対応する＜smp＞リソースを位置づけることができることに留意されたい。＜vsmr＞リソース（例えばマッシュアップ結果）がその子リソースとして＜smrs＞を有する場合、マッシュアップ結果を検索するためにSMS要求側１８０８（例えばoneM2M CSEまたはAE）またはさらにはSMSホストが＜vsmr＞リソースに来ることができる。
＜vsmr＞リソースは、表９で指定された子リソースおよび表１０で指定された属性を含み得る。＜vsmr＞リソースの構造も図４２に示す。
Figure 0007038113000014
Figure 0007038113000015
Figure 0007038113000016
図４３は、＜vsmr＞リソースを操作する（例えば、＜vsmr＞リソースの生成、検索、更新または削除）例示的な手順を示す。
図４３に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４３に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４３に示すステップを実行する。図４３に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４３に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
図４３では、ステップ４３１１において、発信側４１０４は発信側で何らかの処理を行う。これは、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.1.1節（以下10.1.1.1）等に従うことができる。ステップ４３１２では、発信側４１０４は要求メッセージを受信側４１０２に送信し得る。要求メッセージは、＜smp＞に対する生成メッセージ、検索メッセージ、更新メッセージまたは削除メッセージであり得る。ステップ４３１３では、ステップ４３１２のメッセージを処理する。ステップ４３１４では、ステップ４３１３の処理に基づく。これらのステップは、表１１～表１５でさらに説明する。＜vsmr＞を生成する手順は、表１１に記載されるように＜vsmr＞リソースを生成するために用いられ得る。
Figure 0007038113000017
Figure 0007038113000018
＜vsmr＞を検索する手順は、表１２に記載されるように＜vsmr＞リソースの属性を検索するために用いられ得る。
Figure 0007038113000019
＜vsmr＞／mashupを検索する手順は、表１３に記載されるように、＜vsmr＞をホストするＣＳＥをトリガしてマッシュアップ結果を再計算し、マッシュアップ結果をこの検索要求の要求側１８０８（例えば、AE）に返すために用いられ得る。
Figure 0007038113000020
表１４に記載されている＜vsmr＞を更新する手順を用いて、既存の＜vsmr＞を更新し得る、例えば、そのmemberStoreTypeへの更新を行う。一般的な更新手順は、oneM2M－TS－0001 oneM2M Functional Architecture-V2.9.0の第10.1.3節に記載され得る。
Figure 0007038113000021
表１５に記載されている＜vsmr＞を削除する手順を用いて、既存の＜vsmr＞を削除し得る。一般的な削除手順は、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.4.1節に記載されている。
Figure 0007038113000022
セマンティックマッシュアップ結果リソースである＜smrs＞リソースを用いて、仮想セマンティックマッシュアップリソースのマッシュアップ結果をモデル化し表現し得る。＜smrs＞リソースは、その子リソースとして＜vsmr＞下に配置され得る。あるいは、＜vsmr＞リソースは＜smrs＞リソースを指すsmrsID属性を有し得るため、＜smrs＞リソースは別の場所（例えば、＜vsmr＞の子リソースではない）に記憶され得る。マッシュアップ操作の実行結果として、＜smrs＞リソースが自動的に生成され得る。＜smrs＞リソースは、oneM2M CSE又はoneM2M AEであり得るSMS要求側１８０８に公開され得る。SMS要求側として、oneM2M CSEまたはAEは、＜smrs＞リソースにアクセスしてマッシュアップ結果の再計算をトリガするか、またはマッシュアップ結果を検索し得る。＜smrs＞および対応する＜vsmr＞が異なる場所（例えば、親子関係ではない）に配置される場合、VSMRホスト２３０２（例えば、＜vsmr＞が配置される場所）は、＜smrs＞リソースにアクセスしてマッシュアップ結果を更新し得る。同様に、SMRSホスト２３０４（例えば、＜smrs＞が維持される場所）は、＜vsmr＞にアクセスして、マッシュアップ操作の実行をトリガし、新たなマッシュアップ結果を得ることができる。
＜smrs＞リソースは、表１６で指定された子リソースおよび表１７で指定された属性を含み得る。＜smrs＞リソースの構造も図４４に示す。
Figure 0007038113000023
Figure 0007038113000024
図４５は、＜smrs＞リソースを操作する（例えば、＜smrs＞リソースの生成、検索、更新または削除）手順を示す。
図４５に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４５に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４５に示すステップを実行する。図４５に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４５に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
図４５では、ステップ４５１１において、発信側４１０４は発信側で何らかの処理を行う。これは、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.1.1節（以下10.1.1.1）等に従うことができる。ステップ４５１２では、発信側４１０４は要求メッセージを受信側４１０２に送信し得る。要求メッセージは、＜smp＞に対する生成メッセージ、検索メッセージ、更新メッセージまたは削除メッセージであり得る。ステップ４５１３では、ステップ４５１２のメッセージを処理する。ステップ４５１４では、ステップ４５１３の処理に基づく。これらのステップは、表１８～表２２でさらに説明する。＜smrs＞を生成する手順は、表１８に記載されるように＜smrs＞リソースを生成するために用いられ得る。
Figure 0007038113000025
＜smrs＞を検索する手順は、表１９に記載されるように＜smrs＞リソースの属性を検索するために用いられ得る。
Figure 0007038113000026
＜smrs＞／mashupを検索する手順は、表２０に記載されるように＜smrs＞リソースの仮想子リソースmashupを検索するために用いられ得る。
Figure 0007038113000027
表２１に記載されている＜smrs＞を更新する手順を用いて、既存の＜smrs＞を更新し得る、例えば、そのmashupResultFormatへの更新を行う。一般的な更新手順は、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.3節に記載されている。
Figure 0007038113000028
表２２に記載されている＜smrs＞を削除する手順は、既存の＜smrs＞を削除するために用いられ得る。一般的な削除手順は、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の第10.1.4.1節に記載されている。
Figure 0007038113000029
oneM2M共通属性の表２３は、いくつかのoneM2Mリソース（例えば、＜container＞、＜group＞等）の共通属性として追加され得る新たな属性を列挙している。
Figure 0007038113000030
図４６Ａ～図４６Ｃ（本明細書では図４６）は、oneM2M機能アーキテクチャにおいてセマンティックマッシュアップをサポートするための全体的な手順例を示す。これには以下の部分が含まれ得る。SMP１８０２の発見および検索（例えば図４６のステップ４６１１～４６１５）、VSMRの生成（例えば図４６のステップ４６６～４６１２）、またはマッシュアップ結果の検索（例えば図４６のステップ４６１３～４６１５）。この例では、以下の仮定がなされ得る。IN-AE４６０２はSMS要求側であり、IN-CSE４６０４は、SMSホストとして機能し、＜smp＞リソース、＜vsmr＞リソース、および＜smrs＞リソースをホストして、セマンティックマッシュアップサービスを提供し、マッシュアップのための＜vsmr＞リソースのメンバリソースは、MN-CSE1 ４６０６およびMN-CSE2 ４６０８由来のものであり得る。＜smp＞リソース、＜vsmr＞リソースおよび＜smrs＞リソースを記述するためのセマンティックトリプルは、セマンティックグラフストア（Semantic Graph Store:SGS）に記憶され、セマンティックリソースの発見を可能にし得る。MN-CSE1 ４６０６およびMN-CSE2 ４６０８におけるオリジナルリソース（例えば、メンバリソース）を記述するためのセマンティックトリプルは、セマンティックリソースの発見を可能にするために同様にSGSに記憶され得る。リソースURI（例えば、＜smp＞、＜vsmr＞、＜smrs＞およびオリジナルメンバリソース）はそれらのセマンティックトリプルに含まれており、それらはSGSに記憶され得るが、セマンティックリソース発見を用いて発見されるかまたは除外され得る。
図４６に示すステップについては以下でより詳細に説明する。図４６のステップ４６１１：IN-AE４６０２は、IN-CSE４６０４にRETRIEVE操作を送信して、“SuitableParkingService”と呼ばれる、特定のマッシュアップサービスをサポートし得る＜smp＞リソースを発見する。このメッセージはsmpFilter（または既存のoneM2M semanticFilterパラメータを使用）を含み、これは実際にはSPARQLクエリパターンである。smpFilterの例を以下に示す。
(Line1) @PREFIX smp: <http://smp.example.com> .
(Line2) select ?smp
(Line3) where {
(Line4) ?smp rdf:type smp:SMPResource .
(Line5) ?smp smp:hasService “SuitableParkingService”
(Line6) }
あるいは、セマンティックマッシュアップオントロジーでSuitableParkingServiceがクラスとして定義されている場合は、Line5を次のトリプルに変更してもよい。
?smp rdf:type smp:SuitableParkingService
図４６のステップ４６１２：IN-CSE４６０４は、ステップ４６１１でSPARQLクエリパターンをSGSに送信することによってセマンティックリソースの発見または除外を実行する。
図４６のステップ４６１２．ａ：IN-CSE４６０４はSPARQLクエリをSGSに送信し、予想される＜smp＞リソースを発見する。SPARQLクエリは、実際にはステップ４６１１から受信したSPARQLクエリパターンである。
図４６のステップ４６１２．ｂ：SGSは、SPARQLクエリを実行し、対応する＜smp＞リソースを見つけ、IN-CSE４６０４またはIN-AE４６０２がそれらの＜smp＞リソースを発見するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する［前述のアクセス制御戦略は、単にoneM2Mシステムの既存のアクセス制御ポリシーを採用する］。IN-CSE４６０４またはIN-AE４６０２に＜smp＞リソースのURIを発見する権限が与えられていない場合、SGSは＜smp＞リソースのＵＲＩを返さなくてもよいことに留意されたい。
図４６のステップ４６１２．ｃ：SGSは、IN-CSE４６０４に応答を送信する。この応答メッセージは、SPARQLクエリの条件を満たし、IN-CSE４６０４またはIN-AE４６０２によって発見された＜smp＞URIのリストを含む。
図４６のステップ４６１３：IN-CSE４６０４は発見された＜smp＞URIをIN-AE４６０２に返す。
図４６のステップ４６１４：IN-AE４６０２は、ステップ４６１３に含まれる＜smp＞URIリストから＜smp＞を選ぶ。次いで、IN-AE４６０２は、RETRIEVE操作を送信し、この＜smp＞の属性および子リソースを検索する。このステップの目的は、IN-AE４６０２がこの＜smp＞に必要な入力パラメータのタイプ（例えばinputDescriptor属性）と、この＜smp＞によって生成され得るマッシュアップ結果のタイプ（例えばoutputDescriptor属性）を理解することである。
図４６のステップ４６１５：IN-CSE４６０４は、IN-AE４６０２が対応する＜smp＞リソースを検索するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する。IN-AE４６０２に＜smp＞リソースを検索する権限が与えられていない場合、IN-CSE４６０４は適切なエラーコードを送信し得ることに留意されたい。
図４６のステップ４６１６：IN-AE４６０２に＜smp＞リソースを検索する権限が与えられている場合、IN-CSE４６０４は応答をIN-AE４６０２に送信する。この応答メッセージは、＜smp＞の表現（またはその子リソースの表現と一緒に）を含む。
図４６のステップ４６１７：検索された＜smp＞に基づいて、IN-AE４６０２は＜vsmr＞リソースを生成するためにIN-CSE４６０４にCREATE操作を送信する。このメッセージは、生成される＜vsmr＞リソースの表現（例えば、そのsmpID属性）を含み得る。IN-AE４６０２は、＜vsmr＞の以下の属性を設定し得る。
smpID＝ステップ４６１３で発見され、ステップ４６１４で選択された＜smp＞URI。
smrsStoreType=“Child Resource”。これは、セマンティックマッシュアップ結果が、この＜vsmr＞の子リソースとして生成され得ることを意味する。
memberStoreType=“URI Only“。
resultGenType=“When VSMR Is Created“および“When SMS Requestor Requests“。これは、＜vsmr＞が生成され、IN-AE４６０２が＜smrs＞の仮想子リソースmashupにRETRIEVE要求を送信したときに、IN-CSE４６０４がセマンティックマッシュアップ結果を計算し得ることを意味する。
図４６のステップ４６１８：IN-CSE４６０４は、IN-AE４６０２が＜vsmr＞リソースを生成するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する。IN-AE ４６０２に＜vsmr＞リソースを生成する権限が与えられていない場合、IN-CSE４６０４は適切なエラーコードをIN-AE４６０２に送信し得ることに留意されたい。
図４６のステップ４６１９：IN-AE４６０２に＜vsmr＞リソースを生成する権限が与えられている場合、IN-CSE４６０４は、ステップ４６１７で与えられたsmpIDに従って対応する＜smp＞リソースを見つける。これば、＜smp＞リソースのmemberFilter属性に従ってSPARQLクエリを構成する。SPARQLクエリは、SGSに送信され、ステップ４６２２で生成される＜vsmr＞のためのメンバリソースを発見し得る。
図４６のステップ４６１９．ａ：ステップ４６１９で構成されたSPARQLクエリはIN-CSE４６０４からSGSに送信される。
図４６のステップ４６１９．ｂ：SGSは、SPARQLクエリを実行し、対応するメンバリソースを見つけ、IN-CSE４６０４またはIN-AE４６０２がこれらメンバリソースを発見するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する。IN-CSE４６０４またはIN-AE４６０２にメンバリソースのURIを発見する権限が与えられていない場合、SGSはメンバリソースのURIを返さなくてもよいことに留意されたい。
図４６のステップ４６１９．ｃ：SGSは、発見されたメンバリソース（例えば、それらのＵＲＩ）のリストを含む応答をIN-CSE４６０４に送信する。
図４６のステップ４６２０：IN-CSE４６０４は、ステップ４６１９．ｃで返されたリスト内のリソースを、ステップ４６２２で生成される＜vsmr＞のメンバリソースとして選択する。
図４６のステップ４６２１：ステップ４６１７でresultGenType=“When VSMR Is Created“が与えられたため、IN-CSE４６０４は各メンバリソースのコンテンツ値または表現を検索し得る。この例では、MN-CSE1 ４６０６およびMN-CSE2 ４６０８によってそれぞれホストされる２つのメンバリソースrsc1およびrsc2があると仮定する。
図４６のステップ４６２１．ａ：IN-CSE４６０４は、MN-CSE1 ４６０６にRETRIEVE操作を送信し、第１のメンバリソースrsc1を検索する。
図４６のステップ４６２１．ｂ：MN-CSE1 ４６０６は、IN-CSE４６０４またはIN-AE４６０２がメンバリソース（例えばrsc1）を検索するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する。IN-CSE４６０４またはIN-AE４６０２にメンバリソースを検索する権限が与えられていない場合、MN-CSE1 ４６０６は適切なエラーコードを送信し得ることに留意されたい。
図４６のステップ４６２１．ｃ：IN-CSE４６０４またはIN-AE４６０２にメンバリソースを検索する権限が与えられていない場合、第１のメンバリソースrsc1のコンテンツ値または表現はIN-CSE４６０４に返される。
図４６のステップ４６２１．ｄ：IN-CSE４６０４は、MN-CSE2 ４６０８にRETRIEVE操作を送信し、第２のメンバリソースrsc2を検索する。
図４６のステップ４６２１．ｅ：MN-CSE2 ４６０８は、IN-CSE４６０４またはIN-AE４６０２がメンバリソース（例えばrsc2）を検索するための適切な権限を有しているかどうかを確認するためにアクセス制御を実行する。IN-CSE４６０４またはIN-AE４６０２にメンバリソースを検索する権限が与えられていない場合、MN-CSE2 ４６０８は適切なエラーコードを送信し得ることに留意されたい。
図４６のステップ４６２１．ｆ：IN-CSE４６０４またはIN-AE４６０２にメンバリソースを検索する権限が与えられていない場合、第２のメンバリソースrsc2のコンテンツ値または表現はIN-CSE４６０４に返される。
図４６のステップ４６２２：IN-CSE４６０４は、ステップ４６１７で与えられた属性値、ステップ４６２０で決定されたメンバリソースに基づいて＜vsmr＞リソースを生成する。ステップ４６１７で与えられたようにsmrsStoreType=“Child Resource”であるため、IN-CSE４６０４はさらに、セマンティックマッシュアップ結果リソース＜smrs＞を、生成した＜vsmr＞の子リソースとして生成し、配置し得る。
図４６のステップ４６２３：resultGenType=“When VSMR Created“であるため、IN-CSE４６０４は、対応する＜smp＞リソースのfunctionDescriptor属性で指定されたようにマッシュアップ操作を実行する。マッシュアップ操作は、（ステップ４６２１．ｃおよびステップ４６２１．ｆで検索された）各メンバリソースのコンテンツ値および（ステップ４６１７に含まれる）入力パラメータに対して実行され得る。次いで、IN-CSE４６０４は、計算されたマッシュアップ結果を、＜vsmr＞／＜smrs＞リソースのmashupResult属性に記憶する。
図４６のステップ４６２４：IN-CSE４６０４は、IN-AE４６０２に応答を送信する。この応答メッセージは、生成された＜vmsr＞のURIを含み得、セマンティックマッシュアップ結果を検索するためのURI（例えば、＜vsmr＞／＜smrs＞）も含み得る。
図４６のステップ４６２５：IN-AE４６０２は、IN-CSE４６０４にRETRIEVE操作を送信し、セマンティックマッシュアップ結果を検索する。この要求のターゲットとされるURIは、＜vsmr＞／＜smrs＞であるが、セマンティックマッシュアップ結果はステップ４６２３で計算されているため、＜smrs＞リソースのmashupResult属性を検索するためのものである。
あるいは、ステップ４６１７でresultGenType=“When SMS Requestor Requests“であると示されているため、IN-AE４６０２はRETRIEVE操作を＜vsmr＞／＜smrs＞／mashupに送信し、IN-CSE４６０４をトリガしてセマンティックマッシュアップ結果を再計算し得る。この場合、以下のステップ４６２６を用いてもよい。
図４６のステップ４６２６：ステップ４６２５のターゲットURIが＜vsmr＞／＜smrs＞／mashupである場合、このステップが使用され得る。RETRIEVE操作を受信した後、IN-CSE４６０４は、IN-AE４６０２が＜vsmr＞／＜smrs＞／mashupリソースを検索するための適切な権限を有しているかどうかを確認するためにアクセス制御をまず実行し得る。IN-AE４６０２に＜vsmr＞／＜smrs＞／mashupリソースを検索する権限が与えられている場合、IN-CSE４６０４はステップ４６２１およびステップ４６２３を実行してマッシュアップ結果を再計算し、そうでない場合、適切なエラーコードを送信する。
図４６のステップ４６２７：IN-CSE４６０４はセマンティックマッシュアップ結果をIN-AE４６０２に返す。
図４６に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４６に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４６に示すステップを実行する。図４６に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４６に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
あるいは、oneM2M CSEは、新たな＜vsmr＞リソースを生成する代わりに、既存のoneM2M＜group＞リソースを活用してSMSを実装し得る。これは以下の通り機能する。＜group＞リソースは、表１０に定義されているように、＜vsmr＞リソースのほとんどの属性（例えばsmpID、smpInputPara、resultGenType等）を有し得る。この＜group＞リソースは、基本的に特定のＳＭＳを提供する。＜group＞リソースをホストするCSEは、実際にはSMSホストである。さらに、＜group＞はその子リソースとして＜smrs＞有していてもよく、またはマッシュアップ結果を記憶するために単純に新たな属性”smrs”を有する。＜group＞リソースの各メンバは、マッシュアップメンバ（オリジナルリソース等）としてみなされる。その結果、＜group＞リソースのmemberID属性を用いて、セマンティックマッシュアップに関連または要求されるマッシュアップメンバのリストを含めることができる。
＜group＞リソースは、新たな仮想リソース“mashup”を有し得る。別のCSEまたはAEが、＜group＞リソースによって提供されるSMSを利用したい場合、この新たな仮想リソース“mashup”をターゲットとするRETRIEVE要求を送信する（例えば、／＜group＞／mashup）。“mashup”仮想リソースをターゲットとするRETRIEVE要求を受信する度、＜group＞リソースをホストするCSEは、smpInputPara属性に含まれる入力パラメータ、新たなsmpID属性で示される＜smp＞リソースのマッシュアッププロファイル情報、および各マッシュアップメンバの表現（この＜group＞リソースの“fanOutPoint”仮想リソースを使用して検索され得る）を用いてマッシュアップ結果を計算し得る。次に、＜group＞リソースをホストするCSEは、要求側のCSEまたはAEに応答を送信する。応答メッセージには、計算されたマッシュアップ結果が含まれ得る。計算されたマッシュアップ結果は、新たな属性“smrs”に、または＜group＞リソースが子リソースとして＜smrs＞を有する場合は＜smrs＞子リソースに記憶され得る。
さらに、＜group＞リソースをホストするＣＳＥは、（＜group＞リソースのmemberID属性に含まれる）各マッシュアップメンバの表現を定期的に検索し、マッシュアップメンバの新たな表現に基づいてマッシュアップ結果を再計算し得る。他のCSEまたはAEは、“mashup”仮想リソースを購読し得る。次に、＜group＞リソースをホストするCSEは、それらの他のCSEまたはAEに自動通知（新たなマッシュアップ結果を含む）を送信し得る。それらの他のCSEまたはAEは、実際にはマッシュアップ結果の購読者であり得る。
また、＜group＞リソースをホストするCSEは、（＜group＞リソースのmemberID属性に含まれている）各マッシュアップメンバを購読し得る。マッシュアップメンバに変更があると、CSEは自動通知を受け取り得る。次いで、CSEは、既存のメンバが使用不可になった場合は別のマッシュアップメンバを見つける必要があるか、または１つもしくは複数のマッシュアップメンバの表現が変更された場合、マッシュアップ結果を再計算する必要があり得る。他のCSEまたはAEは、“mashup”仮想リソースを購読し得る。次に、＜group＞リソースをホストするCSEは、新たなマッシュアップ結果が生成されるとそれらの他のCSEまたはAEに自動通知（新たなマッシュアップ結果を含む）を送信し得る。
VSMRは、VSMRのマッシュアップメンバであり得るオリジナルリソースを購読し得る。VSMRによって送信される購読要求は、オリジナルリソースのURI、mashupMemURI、notificationContentType、およびeventNotificationCriteriaを含み得る。mashupMemURIパラメータは、通知がどこに送達されるべきかを示し、notificationContentTypeは、通知のコンテンツタイプを示し、eventNotificationCriteriaパラメータは、通知を送信するリソースホストのためのトリガイベントを示す。eventNotificationCriteriaパラメータの条件は、oneM2M規格［oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0］で提供されているものと同様であってよい。具体的には、eventNotificationCriteriaパラメータのeventType条件タグは、通知を送信するようにリソースホストをトリガし得るイベントのタイプ（購読先リソースで発生する可能性がある）を示す。
（オリジナルリソースを購読するVSMRに適用され得る）eventType条件の例示的な値は、Ａ）購読先リジナルリソースの属性への更新（VSMRはさらに、属性条件タグを使用して、購読先のオリジナルリソースのどの属性がリソースホストによる通知の送信をトリガするかを指定し得ることに留意されたい）、Ｂ）購読先オリジナルリソースの削除、Ｃ）購読先オリジナルリソースの直接の子の生成、またはＤ）購読先オリジナルリソースの直接の子の削除である。
購読先オリジナルリソースの直接の子の生成に関して、ここでは、購読先オリジナルリソースのどの種類の子の生成がリソースホストによる通知の送信をトリガし得るかを指定するために、新たな条件タグ、例えばcreationFilterを導入することに留意されたい。この条件タグは、新たなオリジナルリソースがVSMRのマッシュアップメンバに該当するかどうかをリソースホストが確認するために使用され得る（新たなオリジナルリソースが適格であった場合、リソースホストは、通知を送信して、新たな適格マッシュアップメンバに関してVSMRに通知すべきであり、そうでない場合、リソースホストは通知を送信すべきではない）。creationFilterの値は、プログラミングコードのセットであり得る。
オープンインターコネクトコンソーシアム（OIC）の例を以下に開示する。OICアーキテクチャは、OICサーバおよびOICクライアントを含み得る。リソースプロバイダとみなされるOICサーバはOICリソースをホストするが、OICクライアントは、OICサーバでホストされているリソースにアクセスして操作するリソース消費側である。リソースは、要求または応答モデルに基づいて操作され得る。基本的に、OICクライアントは、OICサーバのリソースをターゲットとするRESTful要求（例えば、生成、検索、更新、削除、および通知）を送信し、次に、OICサーバはRESTful要求を処理し、対応する応答をOICクライアントに送信し得る。OIC規格は、さまざまなタイプのリソースを定義しており、各タイプのリソースは、複数のプロパティを持つことができ、各プロパティは読み取り専用または読み書き可能であってよく、異なるリソースインタフェースによってアクセスされ得る。さらに、いくつかの共通プロパティ、例えば、リソースタイプ（“rt”）、インタフェース（“if”）、名称（“n”）およびリソースアイデンティティ（“id”）についても詳述されている。その結果、OICサーバからOICクライアントへの応答メッセージのコンテンツは、以下のような複数の要因に依存し得る。１）OICクライアントからOICサーバへ送信されるRESTful要求のタイプ、２）RESTful操作の対象となっているリソースのタイプ、または３）RESTful操作のクエリパラメータに含まれるインタフェースのタイプ。
SMSをOICアーキテクチャに実装するための複数の選択肢がある。OICサーバはリソースをホストし、OICクライアントから要求を受信し得るため、OICサーバはリソースホストまたはSMSホストとみなされ得る。言い換えれば、SMSホストおよびリソースホストの機能は、OICサーバ内に実装され得る。対照的に、OICクライアントは、SMS要求側１８０８の機能を実装し得る。方法１または方法２に関して示され開示されている以下の例示的な方法は、OICアーキテクチャでSMSを実装している。
方法１では、OICサーバ１ ４７０２は、マッシュアップメンバとして使用されるそのローカルリソースに基づいてSMSを提供し得る。図４７（ａ）に示すように、OICサーバ１ ４７０２はSMSホストおよびリソースホストとして機能する。リソースホストとしては、そのOICリソースはマッシュアップメンバとして活用されてもよく、SMSホストとしては、SMS機能および手順を実装する。このSMSは、既存のOICコレクションリソースを活用してVSMR機能を実装し得る。OICサーバ１ ４７０２は、この場合、ローカルOICリソース由来のものであり得るマッシュアップメンバの表現に基づいてマッシュアップ結果を計算する。OICクライアント２およびOICクライアント３は、OIC CRUDN操作を用いてOICサーバ１ ４７０２でSMSにアクセスする２つのSMS要求側１８０８であり得る。
方法２では、OICサーバ1 ４７０２はSMSを提供し得るが、マッシュアップメンバは他のOICサーバ由来のものであり得る。図４７（ｂ）に示すように、OICサーバ1 ４７０２は依然としてSMSホストとして機能するが、マッシュアップメンバはそのローカルリソース由来のものでない場合があり、代わりに、OICサーバ2 ４７０８およびOICサーバ3 ４７１０由来のOICリソースがマッシュアップメンバとして使用され得る。これらのマッシュアップメンバ（例えば、OICサーバ2 ４７０８またはOICサーバ3 ４７１０のオリジナルリソース）にアクセスするために、OICサーバ1 ４７０２はOICクライアント１を活用してOICサーバ2 ４７０８およびOICサーバ3 ４７１０と対話する。ここでは、OICサーバ1 ４７０２およびOICクライアント1が同じ物理的デバイスに存在しており、OICサーバ1 ４７０２とOICクライアント1との間に内部インタフェースがあると仮定する。図４７（ａ）に示すように、OICサーバ1 ４７０２は依然として、そのローカルコレクションリソースを使用してVSMR機能を実装する。図４７（ａ）との違いは、この場合のマッシュアップメンバはローカルリソース由来のものではない場合があるということである。マッシュアップ結果を計算するために、OICサーバ1 ４７０２は、（OICクライアント1を介して）OICサーバ2 ４７０８およびOICサーバ3 ４７１０からマッシュアップメンバの表現を検索し得る。計算されたマッシュアップ結果は、OIC CRUDN操作を用いてOICクライアント2およびOICクライアント3（両方ともSMS要求側であり得る）によってアクセスされ得るOICサーバ1 ４７０２でローカルに維持され得る。
図４７Ａ～図４７Ｂに示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４７Ａ～図４７Ｂに示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４７Ａ～図４７Ｂに示すステップを実行する。図４７Ａ～図４７Ｂに示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４７Ａ～図４７Ｂに示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
方法１－OICサーバはSMSを提供し、そのローカルリソースはマッシュアップメンバである。SMSをサポートするために、図４８を参照して以下が用いられ得る。新たなリソースプロパティおよび新たなリソースインタフェースが存在し得る（表２４および表２５）。セマンティックマッシュアッププロファイル（“smp”）は、コレクションリソースのリンクに対してマッシュアップがどのように実行されるべきかを記述するために、コレクションリソースの新たなプロパティとして使用され得る。この場合、コレクションリソースのリンクは、マッシュアップ操作のためのメンバリソースとみなされ得る。セマンティック入力パラメータ（“sip”）は、コレクションリソースの新たなプロパティとして使用され、“smp”プロパティに記述されたマッシュアップに必要とされ得る入力パラメータを含めることができる。セマンティックマッシュアップ結果（“smrs”）は、コレクションリソースの新たなプロパティとして使用され、マッシュアップリソースを維持し得る。新たなリソースインタフェース（例えば、mashup1及びmashup2）は、コレクションリソースに使用され得る。mashup1インタフェースを使用してコレクションリソースの“smrs”プロパティを検索し得るのに対し、mashup2インタフェースを使用して、マッシュアップ操作をトリガし、マッシュアップ結果を再計算し、次に最新のマッシュアップ結果を取得し得る。
図４８は例示的なセマンティックマッシュアップ手順を示す。図４８のステップ４８１１～４８１３について、コレクションソース（例えば、／oic／collectionA）は、OICクライアント（またはOICサーバそれ自体）によってOICサーバで生成され得る。コレクションリソースは、いくつかのリンクを含むことができ、各リンクはセマンティックマッシュアップメンバである。コレクションリソースは新たなプロパティ“smp”、“sip”または“smrs”を有し得る。SMP１８０２に関するプロファイル情報（特にセマンティックマッシュアップ機能の記述およびマッシュアップ結果の記述）が“smp”プロパティに含まれ得る。“smp”プロパティの値は、コレクションリソースが生成されると設定され得る。“sip”プロパティは、各入力パラメータの名称および値を与え得る。“sip”プロパティの値は、コレクションリソースが生成されると設定され得る。マッシュアップ結果が“smp”プロパティのプロファイル情報に従ってリンク（例えばマッシュアップメンバ）に対してOICサーバにより計算されると、“smrs”プロパティを使用してマッシュアップ結果を記憶し得る。
図４８のステップ４８１５～４８１６について、OICクライアント４８０２は、mashup1インタフェースを使用してマッシュアップ結果を直接検索し得る。例えば、OICクライアント４８０２はOICサーバに次の要求を送信し得る。この要求を受信すると、OICサーバ４７０２は、“smrs”プロパティの値を含む応答メッセージをOICクライアント４８０２に送信し得る。（OICサーバに送信される要求メッセージ）GET ／oic／collectionA ?oic．if．mashup1
あるいは、図４８のステップ４８１６～４８１８では、OICクライアント４８０２は、mashup2インタフェースを使用してOICサーバ４７０２がマッシュアップ結果を再計算するようにトリガし得る。例えば、OICクライアント４８０２はOICサーバ４７０２に次の要求を送信し得る。（OICサーバに送信される要求メッセージ）GET ／oic／collectionA ?oic．if．mashup2。この要求メッセージは、“sip”プロパティの値を含み得る。この要求を受信すると、OICサーバ４７０２は、コレクションリソースのリンクに対してマッシュアップ結果を再計算し（例えばそれらをマッシュアップメンバリソースと見なす）、新たなマッシュアップ結果を“smrs”プロパティに記憶し、“smrs”プロパティの更新された値を含む応答メッセージをOICクライアント４８０２に送信し得る。
Figure 0007038113000031
Figure 0007038113000032
図４８に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４８に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４８に示すステップを実行する。図４８に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４８に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
あるいは、コレクションリソースを活用する代わりに、新たなOICリソース（VSMRと呼ばれる）が導入されてもよい。新たなOIC VSMRリソースは、表２４に定義される“smp”、“sip”および“smrs”プロパティを有し、表２５で説明されるmashup1およびmashup2の両方のインタフェースをサポートする。加えて、コレクションリソースと同様に、VSMRリソースはマッシュアップメンバとしてリンクのセットを有する。マッシュアップ結果は、“smp”プロパティに含まれるマッシュアッププロファイル情報（例えばマッシュアップ機能）、“sip”プロパティに含まれる入力パラメータ、および各マッシュアップメンバの値（例えばＶＳＭＲに含まれるすべてのリンク）に基づいて計算される。マッシュアップの結果は、mashup1インタフェースを介してOICクライアントに公開される。言い換えれば、OICクライアントは、mashup1インタフェースを使用してマッシュアップ結果を検索するためにVSMRリソースに来ることができる（例えば、GET／oic／vsmrExample?mashup1、ここで／oic／vsmrExampleはVSMRリソースの例である）。OICクライアントがマッシュアップ結果を再計算するようにOICサーバをトリガしたい場合、OICクライアントは、mashup2インタフェースを使用し得、GET／oic／vsmsExample?mashup2（ここで／oic／vsmrExampleはVSMRリソース例である）のようなメッセージをOICサーバに送信し得る。図４８と同様の手順が適用可能である。
方法２－OICサーバはSMSを提供するが、マッシュアップメンバは他のOICサーバ由来のものである。図４９に示すように、OICサーバ１ ４７０２は、コレクションリソース（例えば、／oic／collectionA）をホストすることによってSMSを提供する。上記の方法１と同様に、／oic／collectionAは新たなプロパティ（例えば、“smp”、“sip”および“smrs”）を有し、新たなインタフェース（例えばmashup1およびmashup2）をサポートする。しかし、方法１とは異なり、／oic／collectionAリソースのリンクは、OICサーバ１ ４７０２ではなく、それぞれOICサーバ２ ４７０８およびOICサーバ３ ４７１０でそれぞれホストされている。OICサーバ１ ４７０２がマッシュアップ結果を計算するとき、OICサーバ１ ４７０２は／oic／collectionAの各リンクの表現を検索し得る。言い換えれば、マッシュアップメンバは、OICサーバ１ ４７０２に記憶されるのではなく、他のOICサーバ（例えば、OICサーバ２ ４７０８およびOICサーバ３ ４７１０）由来のものであり得る。加えて、OICクライアント１ ４８０２およびOICサーバ１ ４７０２は物理的に同じ場所に配置され、同じM2Mデバイスまたはゲートウェイに属し得ると仮定される。図４９の手順を以下で説明する。
図４９のステップ４９１１～４９１３は図４８のステップ４８１１～４８１３と同様である。図４９のステップ４９１２では、OICサーバ１ ４７０２は、生成される／oic／collectionAの２つのリンク（すなわち、OICサーバ２ ４７０８の／oic／rsc2リソースおよびOICサーバ３ ４７１０の／oic／rsc3リソース）を既に知っていると仮定する。
図４９のステップ４９１４～４９１８は、新たなmashup2インタフェースを使用してOICサーバ1 ４７０２からマッシュアップ結果を検索するためにOICクライアント2 ４７０４によって使用される。
図４９のステップ４９１４は、図４８のステップ６と同じである。内部インタフェースを介して、OICサーバ1 ４７０２はOICクライアント１と対話し、それを活用して／oic／collectionAのこれら２つのリンクを検索する。
図４９のステップ４９１５ａおよび４９１５ｂ：OICクライアント１は、OICサーバ２ ４７０８およびOICサーバ３ ４７１０それぞれにRETRIEVEを送信し、OICサーバ２ ４７０８からは／oic／rsc2、OICサーバ２ ４７０８からは／oic／rsc3を検索する。
図４９のステップ４９１６ａおよび４９１６ｂ：／oic／rsc2および／oic／rsc3の表現は、OICクライアント１に送り返され得るが、OICクライアント１はこれらをOICサーバ１ ４７０２に転送し得る。
図４９のステップ４９１７：OICサーバ１ ４７０２は、その“smp”および“sip”プロパティ値ならびにステップ６ａ／６ｂからの応答（例えば、マッシュアップメンバの表現）に基づいてマッシュアップ結果を計算し得る。計算されたマッシュアップ結果は、プロパティ“smrs”に記憶され得る。
図４９のステップ４９１８：OICサーバ１ ４７０２は応答をOICクライアント２に送信し得る。この応答メッセージは、“smrs”プロパティの値（例えば、ステップ４９１７で計算されたマッシュアップ結果）を含み得る。
図４９のステップ４９１９～４９２０：OICクライアント２は、新たなmashup1インタフェースを使用してOICサーバ１ ４７０２からマッシュアップ結果を検索し得る。これらは、図４８のステップ４８１４～４８１５と同じであり得る。
図４９に示すステップを実行するエンティティは、無線通信もしくはネットワーク通信のための装置または図５１Ｃもしくは図５１Ｄに示されるもののようなコンピュータシステムのメモリに記憶され、そのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得る論理的エンティティであり得ることが理解されよう。すなわち、図４９に示す方法は、図５１Ｃまたは図５１Ｄに示される装置またはコンピュータシステムのような装置のメモリに記憶されるソフトウェア（例えば、コンピュータ実行命令）の形態で実装され得るが、そのコンピュータ実行命令は、装置のプロセッサによって実行されたときに図４９に示すステップを実行する。図４９に示す機能は、仮想化ネットワーク機能のセットとして実施され得ることも理解されよう。ネットワーク機能は、必ずしも直接通信しなくてもよく、むしろ、転送または経路指定機能を介して通信し得る。また、図４９に示す任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行命令（例えばソフトウェア）の制御下で装置の通信回路によって実行され得ることも理解されよう。
グラフィカルユーザインタフェース（Graphical User Interface:GUI）等のインタフェースを使用して、セマンティックマッシュアップに関連する機能をユーザが制御または構成するのを支援し得る。図５０は、セマンティックマッシュアッププロファイル（例えば、＜smp＞リソース）、仮想セマンティックマッシュアップリソース（例えば、＜vsmr＞リソース）、またはオリジナルリソース間の関係をユーザが表示または構成することを可能にする例示的インタフェース５００２を示す図である。各セマンティックマッシュアッププロファイルの各リソース構造は、表示または構成され得る。同じセマンティックマッシュアッププロファイルを用いる仮想セマンティックマッシュアップリソースが表示または構成され得る。例えば、セマンティックマッシュアッププロファイル１は、仮想セマンティックマッシュアップリソース１１および仮想セマンティックマッシュアップリソース１２によって使用され得ることが示される。
引き続き図５０を参照すると、セマンティックマッシュアッププロファイル２は、３つの仮想セマンティックマッシュアップリソース（例えば、仮想セマンティックマッシュアップリソース２１、仮想セマンティックマッシュアップリソース２２および仮想セマンティックマッシュアップリソース２３）によって使用され得る。各仮想セマンティックマッシュアップリソースのメンバリソースが表示または構成され得る。例えば、仮想セマンティックマッシュアップリソース１２は、２つのメンバリソース（例えば、オリジナルリソース１２ー１およびオリジナルリソース１２ー２）を有する。このインタフェースを通じて、メンバリソースは、仮想セマンティックマッシュアップリソースから消去されても、または新たなメンバリソースが仮想セマンティックマッシュアップリソースに追加されてもよい。インタフェース５００２は、図５１Ｃ～図５１Ｄに示されるようなディスプレイを使用して生成され得ることが理解されよう。
図５１Ａは、モノのインターネット（IoT）においてセマンティックマッシュアップを可能にすることに関連する１つまたは複数の開示された概念が実施され得る（例えば、図１７～図５０および関連する説明）、例示的な機械対機械（M2M）、IoT、またはモノのWeb（Web of Things:WoT）通信システム１０の例示図を示す。一般に、M2M技術は、IoT／WoTのための構築ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT／WoTのコンポーネントおよびIoT／WoTサービス層等であり得る。通信システム１０は、開示される実施例の機能を実装するために使用され得るとともに、また機能および論理的エンティティ、例えば、SMSアーキテクチャ１８００、SMP１８０２、VSMR１８０４、SMRS１８０６、要求側１８０８、SMSホスト１８１０、オリジナルリソース、マッシュアップ機能２００２、高度SMSアーキテクチャ２２００、VSMRホスト２３０２、SMRSホスト２３０４、２４０２、リソースホスト２８０４、３４０２、セマンティックグラフストア２８０２、受信側４１０２、発信側４１０４、MN－CSE４６０６、４６０８、IN－CSE４６０４、IN－AE４６０２、OICサーバ４７０２、４７０８、４７１０、OICクライアント４７０４、４７０６、４８０２、センサ１５０２、１５０４、およびGUI５００２等のGUIを生成するための論理的エンティティを含み得る。
図５１Ａに示すように、M2M／IoT／WoT通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ethernet（登録商標）、ファイバ、ISDN、PLC等）または無線ネットワーク（例えばWLAN、セルラー等）または異種ネットワークからなるネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージ通信、放送等のコンテンツを複数のユーザに提供する多元接続ネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access:CDMA）、時分割多元接続（Time Division Multiple Access:TDMA）、周波数分割多元接続（Frequency Division Multiple Access:FDMA）、直交FDMA（Orthogonal FDMA:OFDMA）、単一キャリアＦＤＭＡ（Single-Carrier FDMA:SC－FDMA）等の１つまたは複数のチャネルアクセス方式を採用し得る。さらに、通信ネットワーク１２は、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、家庭用ネットワーク、または企業ネットワーク等の他のネットワークを含んでもよい。
図５１Ａに示すように、M2M／IoT／WoT通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインとはエンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは通常M2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ１４および端末デバイス１８を含む。必要に応じて、任意の数のM2Mゲートウェイデバイス１４およびM2M端末デバイス１８がM2M／IoT／WoT通信システム１０に含まれ得ることが理解され得る。M2Mゲートウェイデバイス１４およびM2M端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成されている。M2Mゲートウェイデバイス１４により、無線M2Mデバイス（例えばセルラーおよび非セルラー）ならびに固定ネットワークM2Mデバイス（例えばPLC）は通信ネットワーク１２または直接無線リンク等のオペレータネットワークを介して通信できる。例えば、M2Mデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介してM2Mアプリケーション２０またはM2Mデバイス１８にデータを送信し得る。M2Mデバイス１８はまた、M2Mアプリケーション２０またはM2Mデバイス１８からデータを受信し得る。さらに、以下に説明するように、データおよび信号は、M2Mサービス層２２を介してM2Mアプリケーション２０に送受信され得る。M2Mデバイス１８およびゲートウェイ１４は、例えば、セルラー、WLAN、WPAN（例えば、Zigbee、6LoWPAN、Bluetooth（登録商標））、直接無線リンク、および有線を含む種々のネットワークを介して通信し得る。
図５１Ｂを参照すると、フィールドドメイン内の図示されているM2Mサービス層２２は、M2Mアプリケーション２０（例えば、アプリケーション１７２１またはアプリケーション２ １７２２）、M2Mゲートウェイデバイス１４、M2M端末デバイス１８、および通信ネットワーク１２にサービスを提供する。通信ネットワーク１２は、開示される実施例の機能を実装するために使用され得るとともに、また機能および論理的エンティティ、例えば、基本SMSアーキテクチャ１８００、SMP１８０２、VSMR１８０４、SMRS１８０６、要求側１８０８、SMSホスト１８１０、オリジナルリソース、マッシュアップ機能２００２、高度SMSアーキテクチャ２２００、VSMRホスト２３０２、SMRSホスト２３０４、２４０２、リソースホスト２８０４、３４０２、セマンティックグラフストア２８０２、受信側４１０２、発信側４１０４、MN－CSE４６０６、４６０８、IN－CSE４６０４、IN－AE４６０２、OICサーバ４７０２、４７０８、 ４７１０、OICクライアント４７０４、４７０６、４８０２、センサ１５０２、１５０４、およびGUI５００２等のGUIを生成するための論理的エンティティを含み得る。M2Mサービス層２２は、必要に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス１４、M2M端末デバイス１８、および通信ネットワーク１２と通信し得る。M2Mサービス層２２は、１つまたは複数のサーバ、コンピュータ等によって実装され得る。M2Mサービス層２２は、M2M端末デバイス１８、M2Mゲートウェイデバイス１４およびM2Mアプリケーション２０に適用されるサービス機能を提供する。M2Mサービス層２２の機能は、例えばウェブサーバとして、セルラーコアネットワークにおいて、クラウドにおいて等、種々の方法で実装され得る。
図示されたM2Mサービス層２２と同様に、インフラストラクチャドメイン内にM2Mサービス層２２’がある。M2Mサービス層２２’は、インフラストラクチャドメインにおいてM2Mアプリケーション２０’および下層通信ネットワーク１２’にサービスを提供する。M2Mサービス層２２’はさらに、フィールドドメインにおいてM2Mゲートウェイデバイス１４およびM2M端末デバイス１８にサービスを提供する。M2Mサービス層２２’は、任意の数のM2Mアプリケーション、M2MゲートウェイデバイスおよびM2M端末デバイスと通信し得ることが理解され得る。M2Mサービス層２２’は、異なるサービスプロバイダによってサービス層と対話し得る。M2Mサービス層２２’は、１つまたは複数のサーバ、コンピュータ、仮想マシン（例えば、クラウド／コンピュータ／ストレージファーム等）等によって実装され得る。
さらに図５１Ｂを参照すると、M2Mサービス層２２および２２’は、多様なアプリケーションおよび垂直が活用し得るサービス提供機能のコアセットを提供する。これらのサービス機能により、M2Mアプリケーション２０および２０’は、デバイスと対話し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を実行することが可能になる。基本的に、これらのサービス機能により、アプリケーションにこれらの機能を実装する負担が加わらなくなるため、アプリケーション開発を簡素化し、製品化までの費用および時間を削減する。サービス層２２および２２’によってさらに、M2Mアプリケーション２０および２０’はサービス層２２および２２’が提供するサービスに関連する種々のネットワーク１２および１２’を介して通信できる。
いくつかの例では、M2Mアプリケーション２０および２０’は、本明細書で開示されるように、IoTにおいてセマンティックマッシュアップを可能にすることに関する方法を用いて通信する所望のアプリケーションを含み得る。M2Mアプリケーション２０および２０’としては、これらに限定しないが交通、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産管理、セキュリティおよび監視等の種々の産業におけるアプリケーションを挙げることができる。上述のように、システムのデバイス、ゲートウェイおよび他のサーバを横断して動作するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンス、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、それらの機能をサービスとしてM2Mアプリケーション２０および２０’に提供する。
本願のIoTにおいてセマンティックマッシュアップを可能にすることは、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインタフェース（Application Programming Interface:API）および下層ネットワークインタフェースを通じて付加価値サービス機能をサポートするミドルウェア層である。M2Mエンティティ（例えば、デバイス、ゲートウェイ、またはハードウェアに実装されるサービス／プラットフォーム等のM2M機能エンティティ）は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mの両方は、本出願のIoTにおいてセマンティックマッシュアップを可能にすることを含み得るサービス層を使用する。oneM2Mサービス層は、共通サービス機能（CSF）（例えば、サービス機能）のセットをサポートする。１つまたは複数の特定の種類のCSFのセットのインスタンス化は、共通サービスエンティティ（CSE）と呼ばれ、これは、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）でホストされ得る。さらに、本願のIoTにおいてセマンティックマッシュアップを可能にすることは、サービス指向アーキテクチャ（Service Oriented Architecture:SOA）またはリソース指向アーキテクチャ（Resource-Oriented Architecture:ROA）を使用して本願のIoTにおいてセマンティックマッシュアップを可能にすること等のサービスにアクセスするM2Mネットワークの一部として実装され得る。
本明細書に開示されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は典型的には、HTTP、CoAPまたはMQTT等のアプリケーションプロトコル層上に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層はまた、例えば制御層およびトランスポート／アクセス層等のより低いリソース層でコアネットワークへのインタフェースを提供する。サービス層は、サービス定義、サービスランタイムの有効化、ポリシー管理、アクセス制御およびサービスクラスタリングを含む、複数のカテゴリの（サービス）能力または機能をサポートする。近年、いくつかの業界標準化団体、例えば、oneM2Mは、インターネット／ウェブ、セルラー、企業、および家庭用ネットワーク等の展開へのM2Mタイプのデバイスおよびアプリケーションの統合に関連する課題を解決するためにM2Mサービス層を開発している。M2Mサービス層は、CSEまたはSCLと呼ばれ得るサービス層によってサポートされる上述の能力または機能の集合またはセットへのアクセスにより、種々のデバイスにアプリケーションに提供し得る。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性管理（種々のアプリケーションによって共通して用いられ得る）が挙げられるが、これらに限定されない。これらの能力または機能は、M2Mサービス層によって定義されたメッセージフォーマット、リソース構造およびリソース表現を利用するAPIを介してそのような種々のアプリケーションで利用可能となる。CSEまたはSCLは、ハードウェアまたはソフトウェアによって実装され得るとともに、種々のアプリケーションまたはデバイス（例えば機能エンティティ間の機能インタフェース）が（サービス）能力または機能を使用するために、それらに公開されるそのような能力または機能を提供する機能エンティティである。
一例では、論理的エンティティ、例えば、基本SMSアーキテクチャ１８００、SMP１８０２、VSMR１８０４、SMRＳ１８０６、要求側１８０８、SMSホスト１８１０、オリジナルリソース、マッシュアップ機能２００２、高度SMSアーキテクチャ２２００、VSMRホスト２３０２、SMRSホスト２３０４、２４０２、リソースホスト２８０４、３４０２、セマンティックグラフストア２８０２、受信側４１０２、発信側４１０４、MN－CSE４６０６、４６０８、IN－CSE４６０４、IN－AE４６０２、OICサーバ４７０２、４７０８、４７１０、OICクライアント４７０４、４７０６、４８０２、センサ１５０２、１５０４、およびGUI５００２等のGUIを生成するための論理的エンティティは、図５１Ｂに示すように、M2Mサーバ、M2MゲートウェイまたはM2Mデバイス等のM2MノードによってホストされるM2Mサービス層インスタンス内でホストされ得る。例えば、論理的エンティティ、例えば、基本SMSアーキテクチャ１８００、SMP１８０２、VSMR１８０４、SMRＳ１８０６、要求側１８０８、SMSホスト１８１０、オリジナルリソース、マッシュアップ機能２００２、高度SMSアーキテクチャ２２００、VSMRホスト２３０２、SMRSホスト２３０４、２４０２、リソースホスト２８０４、３４０２、セマンティックグラフストア２８０２、受信側４１０２、発信側４１０４、MN－CSE４６０６、４６０８、IN－CSE４６０４、IN－AE４６０２、OICサーバ４７０２、４７０８、４７１０、OICクライアント４７０４、４７０６、４８０２、センサ１５０２、１５０４、およびGUI５００２等のGUIを生成するための論理的エンティティは、M2Mサービス層インスタンス内において、または既存のサービス機能内のサブ機能として個々のサービス機能を構成し得る。
図５１Ｃは、例えばM2M端末デバイス１８（OICクライアント２ ４７０４または要求側１８０８を含み得る）またはM2Mゲートウェイデバイス１４（図２６、図２８、図４１、図４９等の１つまたは複数のコンポーネントを含み得る）等の例示的なM2Mデバイス３０の例示的なシステム図を示す。図５１Ｃに示されるように、M2Mデバイス３０は、プロセッサ３２、トランシーバ３４、送信／受信要素３６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ／タッチパッド４２、取り外し不能メモリ４４、取り外し可能メモリ４６、電源４８、全地球測位システム（Global Positioning System:GPS）チップセット５０およびその他周辺機器５２を備え得る。M2Mデバイス３０は、開示された主題との整合性を保ちながら、前述の要素の任意の副組み合わせを備え得ることが理解され得る。M2Mデバイス３０（例えば、VSMRホスト２３０２、SMRSホスト２３０４、２４０２、リソースホスト２８０４、３４０２、セマンティックグラフストア２８０２、受信側４１０２、発信側４１０４、MN－CSE４６０６、４６０８、IN－CSE４６０４、IN－AE４６０２、OICサーバ４７０２、４７０８等）は、IoTにおいてセマンティックマッシュアップを可能にするための開示されたシステムおよび方法を実行する例示的な実施態様であり得る。
プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor:DSP）、複数のマイクロプロセッサ、DSPコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit:ASIC）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array:FPGA）回路、任意の他のタイプの集積回路（Integrated Circuit:IC）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、出力制御、入力／出力処理、またはM2Mデバイス３０が無線環境で動作することを可能にする他の任意の機能を実行し得る。プロセッサ３２はトランシーバ３４と接続され得る。トランシーバ３４は送信／受信要素３６と接続され得る。図５１Ｃは、プロセッサ３２およびトランシーバ３４を別個のコンポーネントとして図示しているが、プロセッサ３２およびトランシーバ３４は、電子パッケージまたはチップに一緒に統合されてもよいことが理解され得る。プロセッサ３２は、アプリケーション層プログラム（例えばブラウザ）または無線アクセス層（RAN）プログラムまたは通信を実行し得る。プロセッサ３２は、例えばアクセス層またはアプリケーション層等での認証、セキュリティ鍵合意または暗号操作等のセキュリティ操作を実行し得る。
送信／受信要素３６は、M2Mサービスプラットフォーム２２に信号を送信するか、またはM2Mサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、送信／受信要素３６は、RF信号を送信または受信するように構成されたアンテナであり得る。送信／受信要素３６は、WLAN、WPAN、セルラー等の種々のネットワークおよび電波インタフェースをサポートし得る。一例では、送信／受信要素３６は、例えばIR、UVまたは可視光信号を送信または受信するように構成されたエミッタ／検出器であり得る。さらに別の例では、送信／受信要素３６は、RF信号および光信号の両方を送信および受信するように構成され得る。送信／受信要素３６は、無線信号または有線信号の任意の組み合わせを送信または受信するように構成され得ることが理解され得る。
加えて、送信／受信要素３６は図５１Ｃに単一の要素として図示されているが、M2Mデバイス３０は、任意の数の送信／受信要素３６を備え得る。より具体的には、M2Mデバイス３０は、MIMO技術を採用し得る。したがって、一例では、M2Mデバイス３０は、無線信号を送信および受信するための２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を備え得る。
トランシーバ３４は、送信／受信要素３６によって送信される信号を変調し、送信／受信要素３６によって受信される信号を復調するように構成され得る。上述のように、M2Mデバイス３０はマルチモード機能を有し得る。したがって、トランシーバ３４は、M2Mデバイス３０が、例えばUTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数のトランシーバを含み得る。
プロセッサ３２は、取り外し不能メモリ４４または取り外し可能メモリ４６等の任意のタイプの適切なメモリから情報にアクセスし、そこにデータを記憶し得る。取り外し不能メモリ４４としては、ランダムアクセスメモリ（Random-Access Memory:RAM）、読み取り専用メモリ（Read-Only Memory:ROM）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを挙げることができる。取り外し可能メモリ４６としては、加入者識別モジュール（Subscriber Identity Module:SIM）カード、メモリスティック、セキュアデジタル（Secure Digital:SD）メモリカード等を挙げることができる。他の例では、プロセッサ３２は、サーバまたは家庭用コンピュータ等、M2Mデバイス３０に物理的に配置されていないメモリからの情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に記載の例のいくつかにおける、IoTにおいてセマンティックマッシュアップを可能にすることが成功したか失敗したか（例えば、セマンティック発見、セマンティックマッシュアップ、＜smrs＞検索等）に応じて、ディスプレイまたはインジケータ４２上の照明パターン、画像または色を制御し、そうでない場合は、IoTおよび関連コンポーネントでセマンティックマッシュアップを可能にする状態を示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像または色は、本明細書に図示または説明されている図（例えば、図２６、図２８、図４１、図４９等）中の方法の流れまたはコンポーネントのいずれかの状態を反映し得る。IoTにおいてセマンティックマッシュアップを可能にするメッセージおよび手順（例えば、方法）が本明細書で開示される。メッセージおよび手順は、入力ソース（例えば、スピーカ／マイクロフォン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介してIoTにおいてセマンティックマッシュアップを可能にすることを要求するためのユーザ用のインタフェース／APIを提供するように拡張され得る。さらなる例では、とりわけディスプレイ４２上に表示され得るセマンティックマッシュアップ方法の要求、構成またはクエリがあり得る。
プロセッサ３２は、電源４８から電力を受け取ることができ、M2Mデバイス３０内の他のコンポーネントに電力を分配または制御するように構成され得る。電源４８は、M2Mデバイス３０に電力供給する任意の適切なデバイスであり得る。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケル－カドミウム（NiCd）、ニッケル－亜鉛（NiZn）、ニッケル水素（NiMH）、リチウムイオン（Liイオン）等）、太陽電池、燃料電池等を挙げることができる。
プロセッサ３２はさらに、M2Mデバイス３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されたＧＰＳチップセット５０と接続され得る。M2Mデバイス３０は、本明細書に開示された情報と整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得し得ることが理解され得る。
プロセッサ３２はさらに、他の周辺機器５２と接続され得るが、他の周辺機器５２としては、追加の特徴、機能または有線もしくは無線接続性を提供する１つまたは複数のソフトウェアまたはハードウェアモジュールを挙げることができる。例えば、周辺機器５２としては、種々のセンサ、例えば、加速度計、バイオメトリクス（例えば指紋）センサ、ｅ－コンパス、衛星トランシーバ、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus:USB）ポート、または他の相互接続インタフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（Frequency Modulated:FM）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を挙げることができる。
送信／受信要素３６は、センサ、家庭用電化製品、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療デバイスまたはｅヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、電車または航空機等の車両のような他の装置またはデバイスに組み込まれ得る。送信／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インタフェース等の１つまたは複数の相互接続インタフェースを介してそのような装置またはデバイスの他のコンポーネント、モジュールまたはシステムに接続し得る。
図５１Ｄは、例えば、図５１Ａおよび図５１ＢのM2Mサービスプラットフォーム２２が実装され得る例示的なコンピューティングシステム９０の例示的なブロック図を示す。コンピューティングシステム９０（例えば、M2M端末デバイス１８またはM2Mゲートウェイデバイス１４）は、コンピュータまたはサーバを含み得、そのような命令が記憶またはアクセスされるあらゆる手段によって、主にコンピュータ可読命令によって制御され得る。そのようなコンピュータ可読命令は、コンピューティングシステム９０に作業をさせるために中央処理装置（Central Processing Unit:CPU）９１内で実行され得る。多くの既知のワークステーション、サーバおよびパーソナルコンピュータでは、中央処理装置９１はマイクロプロセッサと呼ばれるシングルチップCPUによって実装される。他の機械では、中央処理装置９１は複数のプロセッサを含んでいてもよい。コプロセッサ８１は、追加の機能を実行する、またはCPU９１を支援する、メインCPU９１とは異なる任意選択のプロセッサである。CPU９１またはコプロセッサ８１は、マッシュアップ結果の計算等、IoTにおいてセマンティックマッシュアップを可能にするための開示されたシステムおよび方法に関するデータを受信し、生成し、処理し得る。
動作中、CPU９１は、命令をフェッチし、復号し、実行し、コンピュータのメインデータ転送経路であるシステムバス８０を介して他のリソースとの間で情報を転送する。このようなシステムバスはコンピューティングシステム９０のコンポーネント同士を接続し、データ交換用の媒体を規定する。典型的には、システムバス８０は、データを送信するデータ回線、アドレスを送信するアドレス回線、および割込みを送信し、システムバスを動作させる制御回線を備える。そのようなシステムバス８０の例は、PCI（Peripheral Component Interconnect）バスである。
システムバス８０に接続されたメモリデバイスは、ランダムアクセスメモリ（RAM）８２および読み取り専用メモリ（ROM）９３を含む。このようなメモリは、情報を記憶および検索することを可能にする回路機構を備える。ROM９３は一般に、容易に修正できない記憶データを含む。RAM８２に記憶されたデータは、CPU９１または他のハードウェアデバイスによって読み取りまたは変更され得る。RAM８２またはROM９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されるときに仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、システムプロセスをユーザプロセスから隔離するメモリ保護機能を提供し得る。したがって、第１のモードで動作しているプログラムは、それ自身のプロセス仮想アドレス空間によってマップされたメモリのみにアクセスでき、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス空間内のメモリにはアクセスできない。
さらに、コンピューティングシステム９０は、CPU９１からの命令をプリンタ９４、キーボード８４、マウス９５およびディスクドライブ８５等の周辺機器に伝達する役割を果たす周辺機器コントローラ８３を備え得る。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用され得る。そのような視覚的出力としては、テキスト、グラフィックス、動画およびビデオを挙げることができる。ディスプレイ８６は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイまたはタッチパネルを用いて実現され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するのに必要な電子部品を備える。
さらに、コンピューティングシステム９０は、コンピューティングシステム９０を図５１Ａおよび図５１Ｂのネットワーク１２等の外部通信ネットワークに接続するために使用され得るネットワークアダプタ９７を備え得る。
本明細書に記載のシステム、方法およびプロセスのいずれかまたはすべては、コンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令（例えばプログラムコード）の形で具現化され得るが、この命令は、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等の機械により実行されたときに、本明細書に記載のシステム、方法およびプロセスを実行または実施することを理解されたい。具体的には、上記のステップ、操作または機能のいずれも、そのようなコンピュータ実行可能命令の形で実施され得る。コンピュータ可読記憶媒体は、情報を記憶するための任意の方法または技術において実装される揮発性および不揮発性、取り外し可能および取り外し不能の媒体の両方を含むことができるが、そのようなコンピュータ可読記憶媒体は信号自体を含まない。本明細書の説明から明らかなように、記憶媒体は法定で定められた主題であると解釈されるべきである。コンピュータ可読記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD－ROM、デジタル汎用ディスク（Digital Versatile Disk:DVD）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を格納するために使用可能で、コンピュータによってアクセス可能な任意の他の物理的媒体が挙げられる。コンピュータ可読記憶媒体には、コンピュータプログラムが記憶されていてもよい。コンピュータプログラムは、データ処理ユニットにロード可能であり得、コンピュータプログラムがデータ処理ユニットによって実行されるときにデータ処理ユニットに方法ステップを実行させるように構成され得る。
図中に示す本開示の主題（IoTにおいてセマンティックマッシュアップを可能にすること）の好ましい方法、システムまたは装置を説明するにあたって、明確さを期して特定の用語が使用される。しかしながら、特許請求される主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、類似の目的を果たすために同様の方法で動作するすべての技術的等価物を包含することを理解されたい。
本明細書に記載の種々の技術は、ハードウェア、ファームウェア、ソフトウェア、または適切な場合にはそれらの組み合わせと関連して実施され得る。そのようなハードウェア、ファームウェアおよびソフトウェアは、通信ネットワークのさまざまなノードに配置されている装置に常駐し得る。装置は、本明細書に記載の方法を実現するために、単独でまたは互いに組み合わせて動作し得る。本明細書で使用されるとき、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」等は同じ意味で用いられ得る。さらに、「または」という語の使用は、本明細書で別段の定めがない限り、一般に包括的に用いられる。
本明細書は、最良の形態を含む本発明を開示するために、また任意のデバイスまたはシステムを製造および使用すること、ならびに任意の組み込まれた方法を実行することを含め、当業者が本発明を実践することを可能にするために実施例を用いる。本発明の特許性のある範囲は特許請求の範囲によって定義され、当業者が思い付く他の実施例（例えば、本明細書に開示されている例示的方法のステップの省略、ステップの組み合わせまたはステップの追加）を含み得る。本明細書で提供される異なる実施例から、リソースまたは属性のうちのいくつかを消去するか、または属性もしくはリソース（例えば子リソース）を追加してもよいことが本明細書で企図される。例えば、図（例えば、図４０、図４２または図４４等）または表（例えば、表４、表９または表１０等）に示されるリソースまたは属性のいくつかは、図または表間で組み合わされても、または省略されてもよい（例えば、５つの属性を有する代わりに３つの属性があってもよい）。そのような他の実施例は、特許請求の範囲内にあることが意図され、これにより本明細書に開示されるように、ＩｏＴにおいてセマンティックマッシュアップを可能にするために特許請求の範囲を広げるかまたは狭めることができる。
とりわけ、本明細書に記載の方法、システムおよび装置は、IoTにおいてセマンティックマッシュアップを可能にするための手段を提供し得る。方法、システム、コンピュータ可読記憶媒体または装置は、プロファイルを取得し、プロファイルを使用して、プロファイルにより示される複数のオリジナルリソースからデータを収集する仮想リソースを生成し、収集されたデータに基づいて仮想リソースの結果を計算し、仮想リソースの結果を要求側に提供する手段を有する。プロファイルはセマンティックマッシュアップであり得る。セマンティックマッシュアッププロファイルは、マッシュアップ機能を含み得る。マッシュアップ機能は、複数のオリジナルリソースからデータを使用し得る。マッシュアップ機能は、要求側からの入力を使用し得る。仮想リソースは仮想セマンティックリソースであり、結果はセマンティックマッシュアップ結果である。仮想セマンティックリソースは、別の要求側によって発見および使用され得る。オリジナルリソースが修正されると、仮想セマンティックリソースが更新され得る。仮想セマンティックリソースは新たな場所に移動し得る。結果は仮想リソースとは別個に記憶され得る。方法、システム、コンピュータ可読記憶媒体または装置は、セマンティックマッシュアップリソースを生成する要求を受信し、要求メッセージに基づいてセマンティックマッシュアッププロファイルを識別し、セマンティックマッシュアッププロファイルに基づいて、生成されるセマンティックマッシュアップリソースのためのマッシュアップメンバリソースを決定し、セマンティックマッシュアップ結果を生成し、決定されたマッシュアップメンバリソースに基づいてセマンティックマッシュアップリソースを生成し、セマンティックマッシュアップリソースの結果のアドレスおよびセマンティックマッシュアップリソースのアドレスを送信する命令を提供する手段を有する。セマンティックマッシュアッププロファイルは、マッシュアップ機能に関するセマンティック情報を含み得る。マッシュアップ機能は、セマンティックマッシュアッププロファイルによって示されるように複数のオリジナルリソースからデータを使用し得る。セマンティックマッシュアッププロファイルは、マッシュアップメンバリソースがどのように選択されるべきかに関する情報を含み得る。セマンティックマッシュアップリソースは、複数の要求側によって発見または使用され得る。セマンティックマッシュアップリソースは、対応するオリジナルリソースが修正された後に更新され得る。要求メッセージは、セマンティックマッシュアップ挙動を示すタイプ属性を含み得る。本段落における、また発明を実施するための形態を通して開示されているすべての組み合わせ（ステップの削除または追加を含む）が企図される。

Claims (20)

  1. セマンティックマッシュアップのための装置であって、
    プロセッサと、
    前記プロセッサに接続され、実行可能命令を記憶するメモリと、を備え、
    前記実行可能命令は前記プロセッサによって実行されると、前記プロセッサに、
    セマンティックマッシュアップリソースを生成する要求を第１エンティティから受信することと、
    前記要求に基づいてセマンティックマッシュアッププロファイルを識別することと、当該セマンティックマッシュアッププロファイルが第２エンティティによって生成され、当該セマンティックマッシュアッププロファイルが前記第１エンティティによって発見され、当該セマンティックマッシュアッププロファイルがsmpIDによって指定され、前記要求は、前記第１エンティティから入力されたデータを含み、
    前記セマンティックマッシュアッププロファイルに基づいて、
    生成される前記セマンティックマッシュアップリソースのためのマッシュアップメンバリソースを決定することと、
    セマンティックマッシュアップ結果を生成することと、
    前記決定されたマッシュアップメンバリソースに基づいて前記セマンティックマッシュアップリソースを生成することと、
    前記セマンティックマッシュアップリソースの結果のアドレスおよび前記セマンティックマッシュアップリソースのアドレスを送信する命令を提供することと、
    を含む操作を実行させる、装置。
  2. 前記セマンティックマッシュアッププロファイルは、マッシュアップ機能に関するセマンティック情報を含む、請求項１に記載の装置。
  3. 前記マッシュアップ機能は、前記セマンティックマッシュアッププロファイルによって示されるように複数のオリジナルリソースからデータを使用する、請求項２に記載の装置。
  4. 前記セマンティックマッシュアッププロファイルは、前記マッシュアップメンバリソースがどのように選択されるべきかに関する情報を含む、請求項１に記載の装置。
  5. 前記セマンティックマッシュアップリソースは、複数の要求側によって発見および使用される、請求項１に記載の装置。
  6. 前記セマンティックマッシュアップリソースは、対応するオリジナルリソースが修正された後に更新される、請求項１に記載の装置。
  7. 前記要求は、前記セマンティックマッシュアップ結果を生成するステップが定期的に行われているかどうかを示すタイプ属性を含む、請求項１に記載の装置。
  8. セマンティックマッシュアップのための方法であって、
    セマンティックマッシュアップリソースを生成する要求を第１エンティティから受信することと、
    前記要求に基づいてセマンティックマッシュアッププロファイルを識別することと、当該セマンティックマッシュアッププロファイルが第２エンティティによって生成され、当該セマンティックマッシュアッププロファイルが前記第１エンティティによって発見され、当該セマンティックマッシュアッププロファイルがsmpIDによって指定され、前記要求は、前記第１エンティティから入力されたデータを含み、
    前記セマンティックマッシュアッププロファイルに基づいて、
    生成される前記セマンティックマッシュアップリソースのためのマッシュアップメンバリソースを決定することと、
    セマンティックマッシュアップ結果を生成すること、
    前記決定されたマッシュアップメンバリソースに基づいて前記セマンティックマッシュアップリソースを生成することと、
    前記セマンティックマッシュアップリソースの結果のアドレスおよび前記セマンティックマッシュアップリソースのアドレスを送信する命令を提供することと、
    を含む、コンピュータが実行する方法。
  9. 前記セマンティックマッシュアッププロファイルは、マッシュアップ機能に関するセマンティック情報を含む、請求項８に記載の方法。
  10. 前記マッシュアップ機能は、前記セマンティックマッシュアッププロファイルによって示されるように複数のオリジナルリソースからデータを使用する、請求項９に記載の方法。
  11. 前記セマンティックマッシュアッププロファイルは、前記マッシュアップメンバリソースがどのように選択されるべきかに関する情報を含む、請求項８に記載の方法。
  12. 前記セマンティックマッシュアップリソースは、複数の要求側によって発見および使用される、請求項８に記載の方法。
  13. 前記セマンティックマッシュアップリソースは、対応するオリジナルリソースが修正された後に更新される、請求項８に記載の方法。
  14. 前記要求は、前記セマンティックマッシュアップ結果を生成するステップが定期的に行われているかどうかを示すタイプ属性を含む、請求項８に記載の方法。
  15. コンピュータ実行可能命令を記憶しているコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令はコンピューティングデバイスによって実行されたときに前記コンピューティングデバイスに、
    セマンティックマッシュアップリソースを生成する要求を第１エンティティから受信することと、
    前記要求に基づいてセマンティックマッシュアッププロファイルを識別することと、当該セマンティックマッシュアッププロファイルが第２エンティティによって生成され、当該セマンティックマッシュアッププロファイルが前記第１エンティティによって発見され、当該セマンティックマッシュアッププロファイルがsmpIDによって指定され、前記要求は、前記第１エンティティから入力されたデータを含み、
    前記セマンティックマッシュアッププロファイルに基づいて、
    生成される前記セマンティックマッシュアップリソースのためのマッシュアップメンバリソースを決定することと、
    セマンティックマッシュアップ結果を生成することと、
    前記決定されたマッシュアップメンバリソースに基づいて前記セマンティックマッシュアップリソースを生成することと、
    前記セマンティックマッシュアップリソースの結果のアドレスおよび前記セマンティックマッシュアップリソースのアドレスを送信する命令を提供することと、
    を含む操作を実行させる、コンピュータ可読記憶媒体。
  16. 前記セマンティックマッシュアッププロファイルは、マッシュアップ機能に関するセマンティック情報を含む、請求項１５に記載のコンピュータ可読記憶媒体。
  17. 前記マッシュアップ機能は、前記セマンティックマッシュアッププロファイルによって示されるように複数のオリジナルリソースからデータを使用する、請求項１６に記載のコンピュータ可読記憶媒体。
  18. 前記セマンティックマッシュアッププロファイルは、前記マッシュアップメンバリソースがどのように選択されるべきかに関する情報を含む、請求項１５に記載のコンピュータ可読記憶媒体。
  19. 前記セマンティックマッシュアップリソースは、複数の要求側によって発見および使用される、請求項１５に記載のコンピュータ可読記憶媒体。
  20. 前記セマンティックマッシュアップリソースは、対応するオリジナルリソースが修正された後に更新される、請求項１５に記載のコンピュータ可読記憶媒体。
JP2019516962A 2016-09-29 2017-09-29 モノのインターネットにおけるセマンティックマッシュアップの許可 Active JP7038113B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662401461P 2016-09-29 2016-09-29
US62/401,461 2016-09-29
PCT/US2017/054274 WO2018064464A1 (en) 2016-09-29 2017-09-29 Enabling semantic mashup in internet of things

Publications (2)

Publication Number Publication Date
JP2020502610A JP2020502610A (ja) 2020-01-23
JP7038113B2 true JP7038113B2 (ja) 2022-03-17

Family

ID=60164797

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019516962A Active JP7038113B2 (ja) 2016-09-29 2017-09-29 モノのインターネットにおけるセマンティックマッシュアップの許可

Country Status (6)

Country Link
US (1) US11076013B2 (ja)
EP (1) EP3519992A1 (ja)
JP (1) JP7038113B2 (ja)
KR (1) KR102254038B1 (ja)
CN (1) CN110447025A (ja)
WO (1) WO2018064464A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017061815A1 (en) * 2015-10-07 2017-04-13 Samsung Electronics Co., Ltd. Method for resource mapping between restful server and onem2m system
WO2017117345A1 (en) * 2015-12-30 2017-07-06 Convida Wireless, Llc Semantics based content specification of iot data
EP3458952A1 (en) * 2016-06-30 2019-03-27 Siemens Aktiengesellschaft A method for amending or adding functionality to an automation device
US10536294B2 (en) * 2017-07-17 2020-01-14 Midea America Corp. Computer-based platform for quality management of home devices
US11416563B1 (en) * 2017-10-20 2022-08-16 Amazon Technologies, Inc. Query language for selecting and addressing resources
US11366865B1 (en) * 2018-09-05 2022-06-21 Amazon Technologies, Inc. Distributed querying of computing hubs
WO2020146689A1 (en) * 2019-01-11 2020-07-16 Convida Wireless, Llc Enabling distributed semantic mashup
CN111539784B (zh) * 2020-04-10 2023-05-26 上海交通大学 基于组合语义学习的服务包推荐方法及系统
CN112235325B (zh) * 2020-12-14 2021-03-09 中国电力科学研究院有限公司 一种对与智能终端相连接的功能模组进行访问控制的方法及系统
KR102367505B1 (ko) * 2021-08-17 2022-02-25 한국전자기술연구원 고급 시맨틱 디스커버리 방법 및 이를 적용한 m2m 플랫폼
CN115203172B (zh) * 2022-06-30 2023-11-07 北京亚控科技发展有限公司 模型构建及模型数据订阅方法、装置、电子设备和介质
TWI799349B (zh) * 2022-09-15 2023-04-11 國立中央大學 利用本體論整合城市模型及物聯網開放式標準之智慧城市應用方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150370900A1 (en) 2013-02-18 2015-12-24 Nec Europe Ltd. Method and system for generating a virtual thing for a machine-to-machine application and a method and system for providing a result of a virtual thing to a machine-to-machine application

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102999563A (zh) * 2012-11-01 2013-03-27 无锡成电科大科技发展有限公司 基于资源描述框架的网络资源语义检索方法及系统
EP2941725B1 (en) * 2013-02-18 2020-05-06 Nec Corporation Method and system for semantically querying a database by a machine-to-machine application
EP3101840B1 (en) * 2014-02-24 2018-01-03 Huawei Technologies Co., Ltd. Method and apparatus for processing information in m2m communications
CN105610880B (zh) * 2014-11-10 2020-06-16 中兴通讯股份有限公司 M2m通信架构、信息交互方法及装置
KR101931858B1 (ko) * 2015-07-09 2018-12-24 주식회사 케이티 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
CN108353263B (zh) * 2015-10-30 2021-02-09 Lg 电子株式会社 处理无线通信系统中的服务请求的方法及其设备

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150370900A1 (en) 2013-02-18 2015-12-24 Nec Europe Ltd. Method and system for generating a virtual thing for a machine-to-machine application and a method and system for providing a result of a virtual thing to a machine-to-machine application

Also Published As

Publication number Publication date
CN110447025A (zh) 2019-11-12
US20180278710A1 (en) 2018-09-27
JP2020502610A (ja) 2020-01-23
KR20190059951A (ko) 2019-05-31
KR102254038B1 (ko) 2021-05-20
EP3519992A1 (en) 2019-08-07
US11076013B2 (en) 2021-07-27
WO2018064464A1 (en) 2018-04-05

Similar Documents

Publication Publication Date Title
JP7038113B2 (ja) モノのインターネットにおけるセマンティックマッシュアップの許可
US11677812B2 (en) Lightweight IoT information model
US11093556B2 (en) Restful operations for semantic IoT
US11005888B2 (en) Access control policy synchronization for service layer
US20180089281A1 (en) Semantic query over distributed semantic descriptors
JP6734404B2 (ja) Ｍ２ｍ／ｉｏｔサービス層におけるセマンティクス推論サービス有効化
KR20200124267A (ko) 분산형 시맨틱 데이터를 통한 시맨틱 동작들 및 추론 지원
Liquori et al. ETSI SmartM2M Technical Report 103715; Study for oneM2M; Discovery and Query solutions analysis & selection

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200923

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210714

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210810

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211109

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: 20220222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220307

R150 Certificate of patent or registration of utility model

Ref document number: 7038113

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150