特許 6811263 Ｍ２Ｍ−ＩＯＴサービスのパブリケーションおよび発見

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6811263

(24)【登録日】2020年12月16日

(45)【発行日】2021年1月13日

(54)【発明の名称】Ｍ２Ｍ−ＩＯＴサービスのパブリケーションおよび発見

(51)【国際特許分類】

   G06F 9/455 20060101AFI20201228BHJP

   G06F 9/46 20060101ALI20201228BHJP

   G06F 13/00 20060101ALI20201228BHJP

   G16Y 30/00 20200101ALI20201228BHJP

【ＦＩ】

   G06F9/455

   G06F9/46 420A

   G06F13/00 540A

   G16Y30/00

【請求項の数】41

【外国語出願】

【全頁数】65

(21)【出願番号】特願2019-13029(P2019-13029)

(22)【出願日】2019年1月29日

(62)【分割の表示】特願2017-503566(P2017-503566)の分割

【原出願日】2015年7月22日

(65)【公開番号】特開2019-110543(P2019-110543A)

(43)【公開日】2019年7月4日

【審査請求日】2019年1月29日

(31)【優先権主張番号】62/027,398

(32)【優先日】2014年7月22日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】シュウ リ

(72)【発明者】

【氏名】チュアン リー

(72)【発明者】

【氏名】リージュン ドン

(72)【発明者】

【氏名】グアン ルー

(72)【発明者】

【氏名】シャミム アクバル ラフマン

(72)【発明者】

【氏名】ズオ チェン

(72)【発明者】

【氏名】チョンガン ワン

【審査官】 多胡 滋

(56)【参考文献】

【文献】 特開２００６−３０２２７１（ＪＰ，Ａ）

【文献】 特開２００５−０３８０１６（ＪＰ，Ａ）

【文献】 特開２００４−２３５８９４（ＪＰ，Ａ）

【文献】 山登庸次，外２名，ユーザ状況に適したサービス提供のためのサービス代理処理機能の研究開発，電子情報通信学会論文誌，日本，社団法人電子情報通信学会，２００８年１２月 １日，第12号，pp.1682-1692

【文献】 磯村学，外２名，広域に分散するセンサネットワークのための統合通信基盤の提案，情報処理学会論文誌，日本，社団法人情報処理学会，２００８年 ６月１５日，第49巻，第6号，pp.1803-1818

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
前記第１のコンピューティングシステムが、前記第１のファイルを記憶することと、
前記第１のコンピューティングシステムが、前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと、
前記第１のコンピューティングシステムが、前記第２のファイルを伝送することであって、前記第２のファイルは、１つ以上の他のデバイスによって発見可能である、ことと
を含む、コンピュータ実装方法。

【請求項2】

第１のコンピューティングシステムが複数の形式のリソース記述を受信することは、複数のＩｏＴデバイスから第１のコンピューティングシステムが複数の形式のリソース記述を受信することを含む、請求項１に記載のコンピュータ実装方法。

【請求項3】

第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述する前記ウェブサービス記述言語による第１のファイルを生成することは、第１のコンピューティングシステムが、特定のサービスにアクセスする方法を記述する前記ウェブサービス記述言語による第１のファイルを生成することを含む、請求項１に記載のコンピュータ実装方法。

【請求項4】

前記第１のコンピューティングシステムが、特定のサービスにアクセスする方法を記述する前記ウェブサービス記述言語による第１のファイルを生成することは、前記第１のコンピューティングシステムが、サービスが利用可能な時、サービスが利用可能な場所、およびサービスと関連付けられたコストのうちの１つ以上のものを記述する前記ウェブサービス記述言語による第１のファイルを生成することをさらに含む、請求項３に記載のコンピュータ実装方法。

【請求項5】

第１のコンピューティングシステムが、前記ウェブサービス記述言語による第１のファイルを生成することは、第１のコンピューティングシステムが、ＷＳＤＬ−Ｉファイルを生成することを含む、請求項４に記載のコンピュータ実装方法。

【請求項6】

第１のコンピューティングシステムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、第１のコンピューティングシステムが、複数の類似サービスを記述する情報を含む、前記ウェブサービス記述言語による第２のファイルを生成することを含む、請求項１に記載のコンピュータ実装方法。

【請求項7】

第１のコンピューティングシステムが、グループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、ＷＳＤＬ−Ｇファイルを生成することを含む、請求項６に記載のコンピュータ実装方法。

【請求項8】

前記第１のコンピューティングシステムは、ゲートウェイコンピューティングシステムである、請求項１に記載のコンピュータ実装方法。

【請求項9】

サーバシステムにおいて、前記記述されたサービスのグループに対応する前記通信される前記ウェブサービス記述言語による第２のファイルを受信することをさらに含む、請求項１に記載のコンピュータ実装方法。

【請求項10】

前記サーバシステムが、サービス消費者システムから、サービスを発見するための要求を受信することをさらに含む、請求項９に記載のコンピュータ実装方法。

【請求項11】

前記要求に応答して、前記サーバシステムが、前記サービス消費者システムに、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイルに関する情報を通信することをさらに含む、請求項１０に記載のコンピュータ実装方法。

【請求項12】

前記サービス消費者システムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内の情報を参照し、前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内で識別されたサービスに関連する情報を含有すると識別することと、
前記サービス消費者システムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内で識別されたサービスに関する情報のための要求を生成し、前記第１のコンピューティングシステムに通信することと
をさらに含む、請求項１１に記載のコンピュータ実装方法。

【請求項13】

前記第１のコンピューティングシステムが、前記サービス消費者システムに、複数のサービス毎に、サービスを記述する前記ウェブサービス記述言語による第１のファイルを伝送することをさらに含む、請求項１２に記載のコンピュータ実装方法。

【請求項14】

前記第１のコンピューティングシステムが、複数のサービス毎に、サービスを記述する前記ウェブサービス記述言語による第１のファイルを受信することと、
前記第１のコンピューティングシステムが、前記受信された前記ウェブサービス記述言語による第１のファイルを解析し、サービスおよび前記識別されたサービスにアクセスするためのプロセスに関するパラメータを識別することと、
前記第１のコンピューティングシステムが、前記識別されたパラメータを採用し、前記識別されたサービスが実行されることの要求を生成および伝送することと
をさらに含む、請求項１３に記載のコンピュータ実装方法。

【請求項15】

システムであって、
ゲートウェイコンピューティングシステム
を備え、
前記ゲートウェイコンピューティングシステムは、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合されているコンピューティングメモリと
を備え、
前記コンピューティングメモリには、
複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
前記ウェブサービス記述言語による前記第１のファイルを記憶することと、
前記ウェブサービス記述言語による前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと、
前記ウェブサービス記述言語による前記第２のファイルを伝送することとであって、前記ウェブサービス記述言語による前記第２のファイルは、１つ以上の他のデバイスによって発見可能である、ことと
を含む動作を実行するための実行可能なコンピューティング命令が記憶されている、システム。

【請求項16】

複数の形式のリソース記述を受信することは、複数のＩｏＴデバイスから複数の形式のリソース記述を受信することを含む、請求項１５に記載のシステム。

【請求項17】

受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述する前記ウェブサービス記述言語による第１のファイルを生成することは、特定のサービスにアクセスする方法を記述する前記ウェブサービス記述言語による第１のファイルを生成することを含む、請求項１５に記載のシステム。

【請求項18】

特定のサービスにアクセスする方法を記述する前記ウェブサービス記述言語による第１のファイルを生成することは、サービスが利用可能な時、サービスが利用可能な場所、およびサービスと関連付けられたコストのうちの１つ以上のものを記述する前記ウェブサービス記述言語による第１のファイルを生成することをさらに含む、請求項１７に記載のシステム。

【請求項19】

前記ウェブサービス記述言語による第１のファイルを生成することは、ＷＳＤＬ−Ｉファイルを生成することを含む、請求項１８に記載のシステム。

【請求項20】

前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、複数の類似サービスを記述する情報を含む前記ウェブサービス記述言語による第２のファイルを生成することを含む、請求項１５に記載のシステム。

【請求項21】

グループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、ＷＳＤＬ−Ｇファイルを生成することを含む、請求項２０に記載のシステム。

【請求項22】

前記ゲートウェイコンピューティングシステムに通信可能に結合されるサーバシステムをさらに備え、前記サーバシステムには、前記記述されたサービスのグループに対応する前記通信される前記ウェブサービス記述言語による第２のファイルを受信すること
を含む動作を実行するための実行可能なコンピューティング命令が記憶されている、請求項１５に記載のシステム。

【請求項23】

サービス消費者システムをさらに備え、前記サービス消費者システムは、前記サーバシステムおよび前記ゲートウェイコンピューティングシステムと通信可能に結合され、前記サーバシステムには、前記サービス消費者システムから、サービスを発見するための要求を受信すること
を含むさらなる動作を実行するための実行可能なコンピューティング命令が記憶されている、請求項２２に記載のシステム。

【請求項24】

前記サーバシステムには、前記要求に応答して、前記サービス消費者システムに、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイルに関する情報を通信すること
を含むさらなる動作を実行するための実行可能なコンピューティング命令が記憶されている、請求項２３に記載のシステム。

【請求項25】

前記サービス消費者システムには、
前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内の情報を参照し、前記ゲートウェイコンピューティングシステムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内で識別されたサービスに関連する情報を含有すると識別することと、
前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイル内で識別されたサービスに関する情報のための要求を生成し、前記ゲートウェイコンピューティングシステムに通信することと
を含むさらなる動作を実行するための実行可能なコンピューティング命令が記憶されている、請求項２４に記載のシステム。

【請求項26】

前記ゲートウェイコンピューティングシステムには、前記サービス消費者システムに、複数のサービス毎に、サービスを記述する第１の前記ウェブサービス記述言語による第１のファイルを伝送すること
を含むさらなる動作を実行するための実行可能なコンピューティング命令が記憶されている、請求項２５に記載のシステム。

【請求項27】

前記ゲートウェイコンピューティングシステムには、
複数のサービス毎に、サービスを記述する前記ウェブサービス記述言語による第１のファイルを受信することと、
前記受信された前記ウェブサービス記述言語による第１のファイルを解析し、サービスおよび前記識別されたサービスにアクセスするためのプロセスに関するパラメータを識別することと、
前記識別されたパラメータを採用し、前記識別されたサービスが実行されることの要求を生成および伝送することと
を含むさらなる動作を実行するための実行可能な命令が記憶されている、請求項２６に記載のシステム。

【請求項28】

コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
を含み、サービスを記述する前記ウェブサービス記述言語による第１のファイルを生成することは、
前記サービスが利用可能な時を示す情報を組み込むことと、
前記サービスが利用可能な場所を示す情報を組み込むことと、
前記サービスの使用と関連付けられたコストを示す情報を組み込むことと、
前記第１のコンピューティングシステムが、前記ウェブサービス記述言語による前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含む、コンピュータ実装方法。

【請求項29】

システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合されているコンピューティングメモリと
を備え、
前記コンピューティングメモリには、
複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと
を含む動作を実行するための実行可能なコンピューティング命令が記憶されており、
サービスを記述する前記ウェブサービス記述言語による第１のファイルを生成することは、
前記サービスが利用可能な時を示す情報を組み込むことと、
前記サービスが利用可能な場所を示す情報を組み込むことと、
前記サービスの使用と関連付けられたコストを示す情報を組み込むことと、
前記ウェブサービス記述言語による前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含む、システム。

【請求項30】

コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数の形式のリソースの状態を記述するリソース記述を受信することであって、
各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含み、
前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルすることを含む、コンピュータ実装方法。

【請求項31】

前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルすることは、グループ識別子、グループ機能、グループメンバーの数、グループ統計、前記グループ内のサービスのための領域、前記グループ内のサービスに予期される入力、および前記グループ内のサービスから予期される出力のうちの少なくとも複数のものをコンパイルすることを含む、請求項３０に記載のコンピュータ実装方法。

【請求項32】

システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと
を備え、
前記コンピューティングメモリには、
複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含む動作を実行するための実行可能なコンピューティング命令が記憶されており、
前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することは、前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルすることを含む、システム。

【請求項33】

前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルすることは、グループ識別子、グループ機能、グループメンバーの数、グループ統計、前記グループ内のサービスのための領域、前記グループ内のサービスに予期される入力、および前記グループ内のサービスから予期される出力のうちの少なくとも複数のものをコンパイルすることを含む、請求項３２に記載のシステム。

【請求項34】

コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することであって、前記ウェブサービス記述言語による第１のファイルを生成することは、コアリソースディレクトリファイルを解析し、ウェブサ前記ウェブサービス記述言語による第１のービス記述言語タグおよび前記コアリソースディレクトリファイルのコンテンツに対応するコンテンツを生成することを含む、ことと、
前記第１のコンピューティングシステムが、前記ウェブサービス記述言語による前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含む、コンピュータ実装方法。

【請求項35】

システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合されているコンピューティングメモリと
を備え、
前記コンピューティングメモリには、
複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することであって、前記ウェブサービス記述言語による第１のファイルを生成することは、コアリソースディレクトリファイルを解析し、ウェブサービス記述言語タグおよび前記コアリソースディレクトリファイルのコンテンツに対応するコンテンツを生成することを含む、ことと、
前記ウェブサービス記述言語による前記第１のファイルに含まれる情報を要約することによって、前記記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを生成することと
を含む動作を実行するための実行可能なコンピューティング命令が記憶されている、システム。

【請求項36】

コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数の形式のリソースの状態を記述するリソース記述を受信することであって、
各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
前記第１のコンピューティングシステムが、サービス毎に前記サービスが既存のグループに対応するかどうかを判定することと、
サービスが既存のグループに対応するという判定に応じて、
記述されたサービスのグループに対応する既存の前記ウェブサービス記述言語による第２のファイルを更新することと、
記述されたサービスのグループに対応する更新された前記ウェブサービス記述言語による前記第２のファイルを、少なくとも１つの遠隔の記憶場所に記憶するために、前記少なくとも１つの遠隔の記憶場所に伝送することと、
サービスが既存のグループに対応しないという判定に応じて、
記述されたサービスの新しいグループに対応する前記ウェブサービス記述言語による第２のファイルを作成することであって、前記サービスを含む記述されたサービスの新しいグループは、既存のグループに対応しないと判定される、ことと、
前記記述されたサービスの新しいグループに対応する前記ウェブサービス記述言語による第２のファイルを、少なくとも１つの遠隔の記憶場所に記憶するために、前記少なくとも１つの遠隔の記憶場所に伝送することと
を含む、コンピュータ実装方法。

【請求項37】

システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合されているコンピューティングメモリと
を備え、
前記コンピューティングメモリには、
複数の形式のリソースの状態を記述するリソース記述を受信することであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ことと、
受信されたリソース記述毎に、デバイスによって提供される各リソースに対応するＣｏＡＰの観察機能を含むサービスを記述するウェブサービス記述言語による第１のファイルを生成することと、
サービス毎に前記サービスが既存のグループに対応するかどうかを判定することと、
サービスが既存のグループに対応するという判定に応じて、
記述されたサービスのグループに対応する前記ウェブサービス記述言語による第２のファイルを更新することと、
記述されたサービスのグループに対応する前記ウェブサービス記述言語による前記第２のファイルを、少なくとも１つの遠隔の記憶場所に記憶するために、前記少なくとも１つの遠隔の記憶場所に伝送することと、
サービスが既存のグループに対応しないという判定に応じて、
記述されたサービスの新しいグループに対応する前記ウェブサービス記述言語による第２のファイルを作成することであって、前記サービスを含む記述されたサービスの新しいグループは、既存のグループに対応しないと判定される、ことと、
前記記述されたサービスの新しいグループに対応する前記ウェブサービス記述言語による第２のファイルを、少なくとも１つの遠隔の記憶場所に記憶するために、前記少なくとも１つの遠隔の記憶場所に伝送することと
を含む動作を実行するための実行可能なコンピューティング命令が記憶されている、システム。

【請求項38】

前記ウェブサービス記述言語による前記第１のファイルは、前記第１のコンピューティングシステムにおけるゲートウェイにおいて記憶されており、前記ウェブサービス記述言語による前記第２のファイルは、前記第１のコンピューティングシステムの外部に記憶されている、請求項１に記載のコンピュータ実装方法。

【請求項39】

前記ウェブサービス記述言語による前記第２のファイルは、前記ウェブサービス記述言語による前記第１のファイルを記憶している前記ゲートウェイを識別するために前記１つ以上の他のデバイスによって使用される、請求項３８に記載のコンピュータ実装方法。

【請求項40】

前記ウェブサービス記述言語による前記第１のファイルは、前記ゲートウェイコンピューティングシステムにおけるゲートウェイにおいて記憶されており、前記ウェブサービス記述言語による前記第２のファイルは、前記ゲートウェイコンピューティングシステムの外部に記憶されている、請求項１５に記載のシステム。

【請求項41】

前記ウェブサービス記述言語による前記第２のファイルは、前記ウェブサービス記述言語による前記第１のファイルを記憶している前記ゲートウェイを識別するために前記１つ以上の他のデバイスによって使用される、請求項４０に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本願は、２０１４年７月２２日に出願された米国仮特許出願第６２／０２７，３９８号の３５Ｕ．Ｓ．Ｃ．§１１９（ｅ）のもとでの利益を主張するものであり、該米国仮特許出願の内容は、その全体が参照により本明細書中に援用される。

【背景技術】

【0002】

サービスとは、ネットワーク環境内で利用可能かつアクセス可能である、機能性または能力の定義されたセットを指す。デバイスおよび／またはソフトウェアアプリケーションは、特定のデバイスまたはアプリケーションのための所望の機能を実施するサービスに、要求を伝送する。

【0003】

サービスは、様々な技術的環境において採用される。例えば、サービスは、ウェブ関連技術において広範に使用されている。特定の機能を伴うウェブサービスは、特定のネットワークアドレスにおいて利用可能であり得る。特定の機能性を要求するシステムは、ウェブを介して、要求をウェブサービスに伝送し得、これは、次いで、所望の機能を実施する。例示的シナリオでは、ウェブサービスは、あるシステムによって、そうでなければ互換性のないシステムとデータを交換するために採用され得る。

【0004】

サービスはまた、マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）技術の状況において広く使用されている。マシンツーマシン（Ｍ２Ｍ）は、ネットワーク化されたデバイスが、ヒトの手動補助を伴わずに、情報を交換し、アクションを実施することを有効にする技術を説明するために使用される、幅広い標識である。モノのインターネット（ＩｏＴ）とは、機械および機械のコンポーネントを含む、オブジェクトに、一意の識別子と、ヒト／ヒトまたはヒト／コンピュータ相互作用を要求せずに、ネットワークを経由して、オブジェクト間でデータを自動的に転送する能力とが提供される、シナリオを指す。時として、Ｍ２Ｍ／ＩｏＴ状況においてリソースと称される、サービスが、例えば、セキュリティ、課金、およびデータ管理に関連するものを含む、Ｍ２Ｍ能力へのアクセスを提供するために使用される。

【0005】

最近、ウェブサービスが、Ｍ２Ｍ／ＩｏＴサービスにアクセスすることを可能にすることに関心が集まっている。言い換えると、ウェブアプリケーションが、Ｍ２Ｍ／ＩｏＴサービスによって提供される機能性を利用することを可能にすることへの関心が高まっている。既存の技術は、所望の統合をサポートする際に不適切であることが証明されている。

【発明の概要】

【課題を解決するための手段】

【0006】

本出願人は、本明細書において、Ｍ２Ｍ／ＩｏＴリソースまたはサービスのパブリッシュおよび発見のためのシステムおよび方法を開示する。開示されるシステムおよび方法は、ウェブベースのアプリケーションであり得る、消費者システムが、Ｍ２Ｍ／ＩｏＴデバイスによって提供される機能性を発見し、それにアクセスすることを有効にする。

【0007】

例示的実施形態では、例えば、Ｍ２Ｍゲートウェイシステムであり得る、第１のコンピューティングシステムは、リソース記述をＭ２Ｍ／ＩｏＴデバイスから受信する。リソース記述はそれぞれ、記述が受信されたデバイスまたはシステムにアクセス可能なサービスと考えられ得る、特定のリソースを記述する。例えば、リソース記述は、特定のデバイスが、特定のデバイスの近傍における測定または環境条件を提供するために利用可能であることを記述する、情報を含んでもよい。リソース記述は、リソースディレクトリ（ＲＤ）への参照等の任意の好適なフォーマットにおけるものであってもよい。

【0008】

例示的実施形態では、受信されるリソース記述毎に、ゲートウェイは、リソースを記述するエントリを作成する。例示的実施形態では、ゲートウェイは、サービスと称され得るリソース毎に、別個のまたは個々のファイルを作成してもよい。ファイル内に含まれる情報は、特定のリソースにアクセスする方法に関する情報を含む。例示的シナリオでは、ファイルは、リソースが利用可能な時、リソースがアクセスされ得る場所、およびリソースへのアクセスと関連付けられたコストを規定する情報を含んでもよい。個々のファイルは、任意の好適な様式でフォーマットされてもよい。例示的実施形態では、個々のファイルは、ウェブサービス記述言語（ＷＳＤＬ）を使用してフォーマットされてもよい。ウェブサービス記述言語を使用してフォーマットされた個々のファイルは、ＷＳＤＬ−Ｉファイルと称され得、ゲートウェイ上に記憶されてもよい。

【0009】

例示的実施形態では、ゲートウェイはさらに、リソースまたはサービスの特性に従って、リソースをグループ化するようにプログラムされてもよい。例えば、ゲートウェイは、新しく受信されたリソースと以前に作成されたグループを比較するように適合されてもよい。ゲートウェイは、比較に基づいて、リソースがリソースの既存のグループ化とともにカテゴリ化され得るかどうか、または特定のリソースが新しいグループ化内に属するかどうかを判定する。リソースが温度を識別するための機能性に関する、例示的シナリオでは、ゲートウェイは、リソースが、同様に温度測定を提供するリソースの既存のグループ化とペアにされ得ることを判定してもよい。代替シナリオでは、ゲートウェイは、リソースが任意の既存のグループに類似しないことを判定してもよい。

【0010】

ゲートウェイが、リソースが既存のグループに関連することを判定する場合、ゲートウェイは、特定のリソースを既存のグループに追加する。これは、例えば、グループと関連付けられたリソースに関する情報が記憶されたファイルを更新することを伴ってもよい。情報は、特定のグループと関連付けられたリソースを要約するために好適な任意の情報を含んでもよい。要約情報を含有するファイルは、任意の好適な様式でフォーマットされてもよい。例示的シナリオでは、ファイルは、ウェブサービス記述言語ファイルとしてフォーマットされてもよい。そのようなシナリオでは、ファイルは、ＷＳＤＬ−Ｇファイルと称され得る。

【0011】

ゲートウェイが、リソースが既存のグループに関連しないことを判定する場合、ゲートウェイは、新しいグループを生成してもよい。例えば、ゲートウェイは、新しいグループに関する要約情報が記憶される、新しいファイルを生成してもよい。グループおよびファイルが、最初に作成されるとき、グループ内に１つのみのリソースが存在してもよい。経時的に、ファイルは、新しいリソースがグループに追加されるにつれて更新される。例示的実施形態では、ファイルは、ウェブサービス記述言語ファイルとしてフォーマットされてもよい。

【0012】

開示される実施形態の別の側面によると、ゲートウェイは、デバイスおよびシステムが、リソースの存在を発見し、リソースの使用を要求し得るように、それが情報を受信したリソースについての情報をパブリッシュするようにプログラムされる。例示的実施形態では、ゲートウェイは、リソースの定義されたグループに関する情報を、要約グループ情報が維持される、サーバコンピューティングシステムに通信する。例えば、ゲートウェイは、情報を、利用可能なリソースまたはサービスのためのレジストリとして動作する、サービスレジストリインフラストラクチャ（ＳＲＩ）に通信してもよい。例示的実施形態では、ゲートウェイは、グループ毎に、ソースの特定のグループに関する要約情報を含有するファイルを伝送してもよい。故に、ゲートウェイが、既存のグループに適合しないリソースの受信に応答して、新しいグループを作成すると、ゲートウェイは、対応するファイル（ＷＳＤＬ−Ｇ）をＳＲＩに通信してもよい。グループが以前から存在しており、リソースがグループのためのグループファイルに追加されるインスタンスでは、ゲートウェイは、更新をグループファイルが以前に通信されたＳＲＩに通信してもよい。

【0013】

いったんリソースのグループに関する情報がパブリッシュされると、サーバシステム、すなわち、ＳＲＩは、リソースのグループについての情報を発見するための要求を受信してもよい。例えば、要求は、サービスを使用する必要性を有し得る任意のシステムであり得る、サービス消費者システムから受信されてもよい。例示的シナリオでは、要求は、ウェブアプリケーションから受信されてもよい。要求は、システムが検索しているサービスまたはリソースのタイプに関する、種々のパラメータを提供してもよい。例えば、要求は、特定のタイプの機能または動作に関し、特定のエリア内、および特定の時間周期の間のサービスに対するクエリを規定してもよい。例示的シナリオでは、要求は、製造設備の特定の部分内の温度を提供する、リソースのクエリを規定してもよい。

【0014】

要求に応答して、リソースサーバシステム、すなわち、ＳＲＩは、クエリ内の情報を使用して、応答し得る、リソースのグループを識別する。ＳＲＩは、複数のＷＳＤＬ−Ｇファイルを通して検索し、特定の要求に応答するリソースのグループに関する、１つまたはそれを上回るファイルを識別してもよい。ＳＲＩは、消費者システムに、ＳＲＩがクエリに応答すると判定する、１つまたはそれを上回るＷＳＤＬ−Ｇファイルを返す。

【0015】

消費者システムは、識別されたサービスのグループと関連付けられた情報を解析し、消費者システムが使用し得るサービスまたはリソースと関連付けられたグループを判定する。消費者システムは、ＷＳＤＬ−Ｇファイルから、特定のＷＳＤＬ−Ｇファイル内で要約されたサービスについての付加的情報を含有する、特定のゲートウェイを識別する。消費者システムは、次いで、消費者システムが使用し得ると判定したサービスの特定のグループに関する付加的情報の要求またはクエリを生成し、識別されたゲートウェイに伝送する。

【0016】

ゲートウェイは、クエリを処理し、要求が関連するサービスの特定のグループを識別する。ゲートウェイは、要求内で識別された特定のグループ内に含まれる特定のリソースを識別し、識別されたリソースのそれぞれに対応する個々のファイル（ＷＳＤＬ−Ｉ）を読み出す。ゲートウェイは、例えば、ＷＳＤＬ−Ｉファイルであり得る個々のファイルを消費者システムに通信する。

【0017】

消費者システムは、受信されたＷＳＤＬ−Ｉファイルを解析し、それがアクセスするであろうサービスを判定する。アクセスを所望する特定のサービスを判定した消費者システムは、対応するＷＳＤＬ−Ｉファイルから、特定のサービスへのアクセスに関する特定のパラメータを読み出す。例えば、消費者システムは、ＷＳＤＬ−Ｉファイルから、サービス／リソースがアクセスされ得る特定のシステムならびにリソースにアクセスするための特定の様式および時間を識別してもよい。消費者システムは、リソースを使用するための要求を生成し、識別されたシステムに通信する。

【0018】

Ｍ２Ｍ／ＩｏＴシステムであり得る、識別されたシステムは、要求に応じて、サービスを提供する。例えば、サービスが、温度読取値を提供することに関する場合、識別されたシステムは、所定の間隔で温度読取値を消費者システムに通信してもよい。

【0019】

本概要は、以下の発明を実施するための形態にさらに説明される、簡略化された形態における一連の概念を紹介するために提供される。本要約は、請求される主題の重要特徴または不可欠な特徴を識別することを意図しておらず、請求される主題の範囲を限定するために使用されることも意図していない。他の特徴も、以下に説明される。
例えば、本願は以下の項目を提供する。
（項目１）
コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップと、
前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを伝送するステップと、
を含む、方法。
（項目２）
第１のコンピューティングシステムが複数のリソース記述を受信するステップは、複数のＩｏＴデバイスから第１のコンピューティングシステムが複数のリソース記述を受信するステップを含む、項目１に記載のコンピュータ実装方法。
（項目３）
第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップは、第１のコンピューティングシステムが、特定のサービスにアクセスする方法を記述するウェブサービス記述言語ファイルを生成するステップを含む、項目１に記載のコンピュータ実装方法。
（項目４）
前記第１のコンピューティングシステムが、特定のサービスにアクセスする方法を記述するウェブサービス記述言語ファイルを生成するステップはさらに、前記第１のコンピューティングシステムが、サービスが利用可能な時、サービスが利用可能な場所、およびサービスと関連付けられたコストのうちの１つまたはそれを上回るものを記述するウェブサービス記述言語ファイルを生成するステップを含む、項目３に記載のコンピュータ実装方法。
（項目５）
第１のコンピューティングシステムが、ウェブサービス記述言語ファイルを生成するステップは、第１のコンピューティングシステムが、ＷＳＤＬ−Ｉファイルを生成するステップを含む、項目４に記載のコンピュータ実装方法。
（項目６）
第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップは、第１のコンピューティングシステムが、複数の類似サービスを記述する情報を含む、ウェブサービス記述言語ファイルを生成するステップを含む、項目１に記載のコンピュータ実装方法。
（項目７）
第１のコンピューティングシステムが、グループに対応するウェブサービス記述言語ファイルを生成するステップは、ＷＳＤＬ−Ｇファイルを生成するステップを含む、項目６に記載のコンピュータ実装方法。
（項目８）
前記第１のコンピューティングシステムは、ゲートウェイコンピューティングシステムである、項目１に記載のコンピュータ実装方法。
（項目９）
サーバシステムにおいて、前記記述されたサービスのグループに対応する前記通信されるウェブサービス記述言語ファイルを受信するステップをさらに含む、項目１に記載のコンピュータ実装方法。
（項目１０）
前記サーバシステムが、サービス消費者システムから、サービスを発見するための要求を受信するステップをさらに含む、項目９に記載のコンピュータ実装方法。
（項目１１）
前記要求に応答して、前記サーバシステムが、前記サービス消費者システムに、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルに関する情報を通信するステップをさらに含む、項目１０に記載のコンピュータ実装方法。
（項目１２）
前記サービス消費者システムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内の情報を参照し、前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内で識別されたサービスに関連する情報を含有すると識別するステップと、
前記サービス消費者システムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内で識別されたサービスに関する情報のための要求を生成し、前記第１のコンピューティングシステムに通信するステップと、
をさらに含む、項目１１に記載のコンピュータ実装方法。
（項目１３）
前記第１のコンピューティングシステムが、前記サービス消費者システムに、複数のサービス毎に、サービスを記述するウェブサービス記述言語ファイルを伝送するステップをさらに含む、項目１２に記載のコンピュータ実装方法。
（項目１４）
前記第１のコンピューティングシステムが、複数のサービス毎に、サービスを記述するウェブサービス記述言語ファイルを受信するステップと、
前記第１のコンピューティングシステムが、前記受信されたウェブサービス記述言語ファイルを解析し、サービスおよび前記識別されたサービスにアクセスするためのプロセスに関するパラメータを識別するステップと、
前記第１のコンピューティングシステムが、前記識別されたパラメータを採用し、前記識別されたサービスが実施されることの要求を生成および伝送するステップと、
をさらに含む、項目１３に記載のコンピュータ実装方法。
（項目１５）
システムであって、
ゲートウェイコンピューティングシステム
を備え、
前記ゲートウェイコンピューティングシステムは、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと、
を備え、前記コンピューティングメモリは、
複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップと、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを伝送するステップと、
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、システム。
（項目１６）
複数のリソース記述を受信するステップは、複数のＩｏＴデバイスから複数のリソース記述を受信するステップを含む、項目１５に記載のシステム。
（項目１７）
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップは、特定のサービスにアクセスする方法を記述するウェブサービス記述言語ファイルを生成するステップを含む、項目１５に記載のシステム。
（項目１８）
特定のサービスにアクセスする方法を記述するウェブサービス記述言語ファイルを生成するステップはさらに、サービスが利用可能な時、サービスが利用可能な場所、およびサービスと関連付けられたコストのうちの１つまたはそれを上回るものを記述するウェブサービス記述言語ファイルを生成するステップを含む、項目１７に記載のシステム。
（項目１９）
ウェブサービス記述言語ファイルを生成するステップは、ＷＳＤＬ−Ｉファイルを生成するステップを含む、項目１８に記載のシステム。
（項目２０）
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップは、複数の類似サービスを記述する情報を含む、ウェブサービス記述言語ファイルを生成するステップを含む、項目１５に記載のシステム。
（項目２１）
グループに対応するウェブサービス記述言語ファイルを生成するステップは、ＷＳＤＬ−Ｇファイルを生成するステップを含む、項目２０に記載のシステム。
（項目２２）
前記ゲートウェイコンピューティングシステムに通信可能に結合されるサーバシステムをさらに備え、前記サーバシステムは、前記記述されたサービスのグループに対応する前記通信されるウェブサービス記述言語ファイルを受信するステップ
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、項目１５に記載のシステム。
（項目２３）
サービス消費者システムをさらに備え、前記サービス消費者システムは、前記サーバシステムおよび前記ゲートウェイコンピューティングシステムと通信可能に結合され、前記サーバシステムは、前記サービス消費者システムから、サービスを発見するための要求を受信するステップ
を含むさらなる動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、項目２２に記載のシステム。
（項目２４）
前記サーバシステムは、前記要求に応答して、前記サービス消費者システムに、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルに関する情報を通信するステップ
を含むさらなる動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、項目２３に記載のシステム。
（項目２５）
前記サービス消費者システムは、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内の情報を参照し、前記ゲートウェイシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内で識別されたサービスに関連する情報を含有すると識別するステップと、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイル内で識別されたサービスに関する情報のための要求を生成し、前記ゲートウェイシステムに通信するステップと、
を含むさらなる動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、項目２４に記載のシステム。
（項目２６）
前記ゲートウェイコンピューティングシステムは、前記サービス消費者システムに、複数のサービス毎に、サービスを記述するウェブサービス記述言語ファイルを伝送するステップ
を含むさらなる動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、項目２５に記載のシステム。
（項目２７）
前記ゲートウェイコンピューティングシステムは、
複数のサービス毎に、サービスを記述するウェブサービス記述言語ファイルを受信するステップと、
前記受信されたウェブサービス記述言語ファイルを解析し、サービスおよび前記識別されたサービスにアクセスするためのプロセスに関するパラメータを識別するステップと、
前記識別されたパラメータを採用し、前記識別されたサービスが実施されることの要求を生成および伝送するステップと、
を含むさらなる動作を実施するためのその中に記憶された実行可能命令を有する、項目２６に記載のシステム。
（項目２８）
コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
を含み、サービスを記述するウェブサービス記述言語ファイルを生成するステップは、
前記サービスが利用可能な時を示す情報を組み込むステップと、
前記サービスが利用可能な場所を示す情報を組み込むステップと、
前記サービスの使用と関連付けられたコストを示す情報を組み込むステップと、
を含む、方法。
（項目２９）
システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと、
を備え、
前記コンピューティングメモリは、
複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有し、
サービスを記述するウェブサービス記述言語ファイルを生成するステップは、
前記サービスが利用可能な時を示す情報を組み込むステップと、
前記サービスが利用可能な場所を示す情報を組み込むステップと、
前記サービスの使用と関連付けられたコストを示す情報を組み込むステップと、
を含む、システム。
（項目３０）
コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップと、
を含み、前記第１のコンピューティングシステムが、前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップは、前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルするステップを含む、方法。
（項目３１）
前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルするステップは、グループ識別子、グループ機能、グループメンバーの数、グループ統計、前記グループ内のサービスのための領域、前記グループ内のサービスに予期される入力、および前記グループ内のサービスから予期される出力のうちの少なくとも複数のものをコンパイルするステップを含む、項目３０に記載のコンピュータ実装方法。
（項目３２）
システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと、
を備え、
前記コンピューティングメモリは、
複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップと、
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有し、
前記記述されたサービスのグループに対応するウェブサービス記述言語ファイルを生成するステップは、前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルするステップを含む、システム。
（項目３３）
前記記述されたサービスのグループ内のサービスを要約する情報をコンパイルするステップは、グループ識別子、グループ機能、グループメンバーの数、グループ統計、前記グループ内のサービスのための領域、前記グループ内のサービスに予期される入力、および前記グループ内のサービスから予期される出力のうちの少なくとも複数のものをコンパイルするステップを含む、項目３２に記載のシステム。
（項目３４）
コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
を含み、ウェブサービス記述言語ファイルを生成するステップは、コアリソースディレクトリファイルを解析し、ウェブサービス記述言語タグおよび前記コアリソースディレクトリファイルのコンテンツに対応するコンテンツを生成するステップを含む、方法。
（項目３５）
システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと、
を備え、
前記コンピューティングメモリは、
複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有し、
ウェブサービス記述言語ファイルを生成するステップは、コアリソースディレクトリファイルを解析し、ウェブサービス記述言語タグおよび前記コアリソースディレクトリファイルのコンテンツに対応するコンテンツを生成するステップを含む、システム。
（項目３６）
コンピュータ実装方法であって、
第１のコンピューティングシステムが、複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
前記第１のコンピューティングシステムが、受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
前記第１のコンピューティングシステムが、サービス毎に前記サービスが既存のグループに対応するかどうかを判定するステップと、
サービスが既存のグループに対応するという判定に応じて、
記述されたサービスのグループに対応する既存のウェブサービス記述言語ファイルを更新するステップと、
サーバシステムに、記述されたサービスのグループに対応する前記更新されたウェブサービス記述言語ファイルを伝送するステップと、
サービスが既存のグループに対応しないという判定に応じて、
記述されたサービスの新しいグループに対応する新しいウェブサービス記述言語ファイルを作成するステップであって、前記サービスを含む記述されたサービスの新しいグループは、既存のグループに対応しないと判定される、ステップと、
サーバシステムに、前記記述されたサービスの新しいグループに対応する新しく作成されたウェブサービス記述言語ファイルを伝送するステップと、
を含む、方法。
（項目３７）
システムであって、
コンピューティングプロセッサと、
前記コンピューティングプロセッサと通信可能に結合される、コンピューティングメモリと、
を備え、
前記コンピューティングメモリは、
複数のリソース記述を受信するステップであって、各リソース記述は、デバイスによって提供されるリソースを記述する、ステップと、
受信されたリソース記述毎に、デバイスによって提供されるリソースに対応するサービスを記述するウェブサービス記述言語ファイルを生成するステップと、
サービス毎に前記サービスが既存のグループに対応するかどうかを判定するステップと、
サービスが既存のグループに対応するという判定に応じて、
記述されたサービスのグループに対応する既存のウェブサービス記述言語ファイルを更新するステップと、
サーバシステムに、記述されたサービスのグループに対応する前記更新されたウェブサービス記述言語ファイルを伝送するステップと、
サービスが既存のグループに対応しないという判定に応じて、
記述されたサービスの新しいグループに対応する新しいウェブサービス記述言語ファイルを作成するステップであって、前記サービスを含む記述されたサービスの新しいグループは、既存のグループに対応しないと判定される、ステップと、
サーバシステムに、前記記述されたサービスの新しいグループに対応する新しく作成されたウェブサービス記述言語ファイルを伝送するステップと、
を含む動作を実施するためのその中に記憶された実行可能コンピューティング命令を有する、システム。

【図面の簡単な説明】

【0020】

例証的実施形態の前述の要約および以下の付加的説明は、添付の図面と併せて読まれることによって、より深く理解され得る。開示されるシステムおよび方法の潜在的実施形態は、描写されるものに限定されないことを理解されたい。

【0021】

【図1】図１は、サービス層の相対的位置付けを描写する、例示的プロトコルスタックを描写する。

【図2】図２は、ネットワーク内の例示的サービス層展開を描写する。

【図3】図３は、例示的ｏｎｅＭ２Ｍアーキテクチャを描写する、略図である。

【図4】図４は、例示的ｏｎｅＭ２Ｍアーキテクチャを描写する、略図である。

【図5】図５は、例示的ＷＳＤＬファイルを描写する、略図である。

【図6】図６は、サービスパブリッシュおよび発見のためのフローを描写する、略図である。

【図7】図７は、Ｍ２Ｍデバイスとウェブサービスとの間の通信経路を描写する、略図である。

【図8】図８は、ＣｏＡＰを使用して記録された観察動作を描写する、略図である。

【図9】図９は、サービスパブリッシュおよび発見のために適合される、システムアーキテクチャの略図である。

【図10】図１０Ａおよび１０Ｂは、ＷＳＤＬ−ＩおよびＷＳＤＬ−Ｇテンプレートをカスタマイズするための例示的ユーザインターフェースを描写する。

【図11】図１１は、例示的ＷＳＤＬ−Ｇテンプレートを描写する、略図である。

【図12】図１２は、リソースをＷＳＤＬファイルにマップするためのプロセスのフロー図である。

【図13】図１３は、リソース記述とＷＳＤＬファイルとの間のマッピングを描写する、略図である。

【図14】図１４は、受信されたリソース記述の処理を描写する、略図である。

【図15】図１５は、リソースへの更新の処理を描写する、略図である。

【図16】図１６は、グループを個々のリソース／サービスから生成するために採用される例示的論理を図示する、略図である。

【図17】図１７は、例示的ＷＳＤＬ−Ｇテンプレートを描写する、略図である。

【図18】図１８は、サービス発見の間の例示的処理を描写する、略図である。

【図19】図１９は、サービス発見の間の例示的処理を描写する、略図である。

【図20】図２０は、サービス発見の間の例示的処理を描写する、略図である。

【図21】図２１は、サービス発見の間の例示的処理を描写する、略図である。

【図22】図２２は、サービスパブリッシュおよび発見を実装するためのＭ２Ｍリソース構成を描写する、略図である。

【図23】図２３は、Ｍ２Ｍサービス層の視点からのサービスパブリッシュを描写する、略図である。

【図24】図２４は、Ｍ２Ｍシステムコンポーネント間のサービスパブリッシュおよび発見のためのコールフローを描写する、略図である。

【図25】図２５は、サービスパブリッシュおよび発見のための代替アーキテクチャの略図である。

【図26A】図２６Ａは、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムの略図である。

【図26B】図２６Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、Ｍ２Ｍ端末デバイス、および通信ネットワークのためのサービスを提供する際のＭ２Ｍサービス層の動作を描写する、例示的システム動作の略図である。

【図26C】図２６Ｃは、本明細書に説明されるシステムおよび方法と関連して基地局として使用され得る、機能コンポーネントを描写する、略図である。

【図26D】図２６Ｄは、本明細書に説明されるシステムおよび方法と関連して使用され得る、例示的コンピューティングシステムの略図である。

【発明を実施するための形態】

【0022】

本出願人は、本明細書において、Ｍ２Ｍ／ＩｏＴリソースまたはサービスのパブリッシュおよび発見のためのシステムおよび方法を開示する。開示されるシステムおよび方法は、ウェブサービスシステムまたはウェブアプリケーションであり得る、サービス消費者システムが、Ｍ２Ｍ／ＩｏＴデバイスによって提供される機能性を発見し、それにアクセスすることを有効にする。
（例示的サービスアーキテクチャ）

【0023】

ネットワークおよびアーキテクチャの視点から、サービスは、「サービス層」内に存在すると考えられ得る。図１は、サービス層の相対的場所を図示する、例示的プロトコルスタックの略図を提供する。示されるように、サービス層１１０は、種々のトランスポートおよびネットワーク層１１２上にある。これは、サービス層内のサービスが、サービスを提供する際、ネットワーク層内の能力を利用することを可能にする。サービス層は、クライアントアプリケーション層１１４の下に存在すると考えられ得る。クライアントアプリケーションは、サービスによって利用可能となる機能性にアクセスするために、サービス層内のサービスに要求を行う。故に、サービス層は、サービスによってエクスポージャされる機能および能力へのアクセスを提供する、ミドルウェアとして動作する。

【0024】

図２は、その中に展開されるサービス層のインスタンスを有する、例示的ネットワークトポグラフィを図示する。図２を参照すると、ネットワークアプリケーションドメイン２１０内に存在するユーザアプリケーションは、特定の機能が実施されることを要求してもよい。ユーザアプリケーションは、例えば、図２６Ａ−Ｄに関連して以下に説明されるもの等のシステムであり得る、デバイス３０上で実行してもよい。一例として、ネットワーク内のデバイスの管理専用ユーザアプリケーションは、デバイスの現在のステータスについての情報を要求してもよい。別の実施例では、ユーザアプリケーションは、ウェブアプリケーションであってもよく、別のデータフォーマッティング標準を使用する、別のアプリケーションにデータを通信する必要があってもよい。

【0025】

アプリケーションは、特定のサービスのための要求をネットワークサービスドメイン２１２に通信する。示されるように、ネットワークサービスドメイン２１２は、種々のネットワークノード２２０を備える。ネットワークノード２２０は、ネットワーク内のネットワークアドレス指定可能エンティティである。ネットワークノード２２０は、例えば、デバイス、ゲートウェイ、もしくはサーバ等の物理的アイテムであってもよい、または、例えば、ＶＭｗａｒｅ等の仮想化ソフトウェアを使用して作成される、例えば、仮想機械等の仮想エンティティであってもよい。図２の例示的実施形態では、ネットワークノード２２０は、例えば、ディレクトリサーバ、アプリケーションサーバ、記憶サーバ、管理サーバ、およびサービスサーバを含む、種々のサーバタイプを備える。ネットワークノード２２０は、例えば、図２６Ｄに関連して以下に説明されるもの等の任意の好適なコンピューティングシステムによって実装されてもよい。図２の実施形態では、種々のネットワーク２２２へのアクセスは、ゲートウェイ２２６を介して提供される。ゲートウェイは、例えば、図２６Ｃまたは２６Ｄに関連して以下に説明されるもの等の任意の好適なコンピューティングシステムによって実装されてもよい。

【0026】

サーバ２２０およびゲートウェイ２２６は、サービス層２３０をその上に有する。サービス層２３０は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワークインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。特定のサービス機能を実施するためのネットワークアプリケーションドメイン２１０内のアプリケーションからの要求は、特定のサービス層２３０にルーティングされ、そこで受信される。サービス層２３０は、要求を処理し、要求されるサービスの結果を要求側アプリケーションに返す。１つまたはそれを上回るサービス能力をサポートするサービス層をホストする、ネットワークノードは、サービスノードと称される。

【0027】

図２を参照すると、サービス層２３０内のサービスはまた、デバイスアプリケーションドメイン２１４内に存在するもの等のデバイスアプリケーションによって要求されてもよい。故に、例えば、センサまたはアクチュエータ等の特定のデバイスが、特定の機能性が実施されることを要求する場合、デバイスは、要求をネットワークサービスドメイン２１２内のサービス層のうちの１つ内に存在する適切なサービスに伝送してもよい。サービス層２３０は、要求を処理し、要求されるサービスの結果を要求側デバイスに返す。デバイスアプリケーションドメイン２１４内のデバイスは、例えば、以下の図２６Ａ−Ｄに関連して説明されるもの等の任意の好適なコンピューティングシステムを使用して実装されてもよい。

【0028】

いくつかのインスタンスでは、ネットワークサービスドメイン内のサービスは、他のサービスのうちの１つによって提供される機能性を要求してもよい。故に、サービス層２３０内のサービスは、要求を別のサービス層２３０内に存在するサービスに伝送してもよい。要求を受信したサービスがその処理を完了すると、応答を要求側サービスに伝送する。

【0029】

サービス層２３０は、任意のタイプのサービス層であってもよい。例えば、サービス層２３０のうちの１つまたはそれを上回るものは、モバイルネットワークデバイスのためのマルチメディアサービスを提供することに具体的に標的化されたＩＰマルチメディアサブシステム（ＩＭＳ）サービス層であってもよい。さらなる実施例として、サービス層２３０のうちの１つまたはそれを上回るものは、Ｍ２Ｍ／ＩｏＴサービス層であってもよい。Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することに具体的に標的化されたあるタイプのサービス層の実施例である。最近、いくつかの産業標準段階（例えば、ＥＴＳＩ Ｍ２Ｍ、ｏｎｅＭ２Ｍ、およびＯＭＡ ＬＷＭ２Ｍ）が、Ｍ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションのインターネット／ウェブ、セルラー、エンタープライズ、およびホームネットワーク等の展開への統合と関連付けられた課題に対処するためのＭ２Ｍ／ＩｏＴサービス層を開発している。

【0030】

Ｍ２Ｍサービス層は、サービス層によってサポートされる一連のＭ２Ｍ中心能力へのアプリケーションおよびデバイスアクセスを提供することができる。いくつかの実施例として、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能となる。

【0031】

ｏｎｅＭ２Ｍの目的および目標は、容易に種々のハードウェアおよびソフトウェア内に埋め込まれ、世界中のＭ２Ｍアプリケーションサーバ内の様々なデバイスに接続するために信頼されることができる、共通Ｍ２Ｍサービス層の必要性に対処する、技術的仕様を開発することである。

【0032】

図３は、例示的基本ｏｎｅＭ２Ｍアーキテクチャを図示する。示されるように、ｏｎｅＭ２Ｍアーキテクチャは、ｏｎｅＭ２Ｍソリューションにおけるアプリケーション論理を提供する、アプリケーションエンティティ（ＡＥ）３１０を備える。ｏｎｅＭ２Ｍ共通サービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上にホストされることができる、共通サービスエンティティ（ＣＳＥ）３１２と称される。サービス機能は、基準点Ｍｃａ３２０およびＭｃｃ３２２を通して他のエンティティにエクスポージャされる。基準点Ｍｃｎ３３０は、下層ネットワークサービスエンティティにアクセスするために使用される。ネットワークサービスエンティティ（ＮＳＥ）３４０は、サービスをＣＳＥに提供する。Ｍ２Ｍサービスの実施例として、デバイス管理、場所サービス、およびデバイストリガリングが挙げられる。下層ＮＳＥは、例えば、３ＧＰＰベースのネットワークであってもよい。

【0033】

ｏｎｅＭ２Ｍアプリケーションは、典型的には、表現状態転送（ＲＥＳＴｆｕｌ）アーキテクチャを使用して実装される。そのようなインスタンスでは、ＣＳＦは、ＲＥＳＴｆｕｌ「リソース」のセットとして表される。リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する、アーキテクチャ内の一意にアドレス指定可能なエンティティである。これらのリソースは、ユニフォームリソース識別子（ＵＲＩ）を使用してアドレス指定可能にされる。リソースは、子リソースおよび属性を含有してもよい。子リソースは、親リソースと含有関係を有するリソースである。親リソース表現は、その子リソースへの参照を含有する。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースについての情報を記憶する、「属性」のセットをサポートする。本出願人は、本明細書において、ウェブアプリケーション等のシステムに可視となるように、Ｍ２Ｍ／ＩｏＴリソース／サービスについての情報をパブリッシュするシステムおよび方法を開示する。

【0034】

図４は、例示的Ｍ２Ｍサービスアーキテクチャのコンポーネントを備える、略図を描写する。Ｍ２Ｍサービスアーキテクチャは、ＡＥにＭ２ＭサービスおよびＭ２Ｍサービスプロバイダへのアクセスを提供することによって、図３に関連して前述のｏｎｅＭ２Ｍ機能アーキテクチャを拡張する。図４に示されるように、ＡＥ４１０は、ＣＳＥ４１４内でともにグループ化されたサービスエクスポージャコンポーネント４１２と通信可能に結合されてもよい。サービスエクスポージャコンポーネント４１２は、ネットワークサービス利用コンポーネント４２０および遠隔サービスエクスポージャコンポーネント４２２と通信可能に結合される。ネットワークサービス利用コンポーネント４１２は、ネットワークサービスエンティティ４３０を介して提供されるサービスへのアクセスを提供する。遠隔サービスエクスポージャコンポーネント４２２は、遠隔Ｍ２Ｍ環境４３２からサービスへのアクセスを提供する。
（ウェブサービス技術）

【0035】

ウェブサービス（ＷＳ）とは、ネットワークを経由してコンピュータ間の相互動作可能相互作用をサポートするために設計されたソフトウェアシステムを実装する方法を指す。ＷＳは、種々のプラットフォームおよびフレームワーク上で起動する、ソフトウェアアプリケーション間の相互動作の標準的手段を提供する。例えば、ＷＳは、第１のプログラムが、ネットワーク内の異なるコンピュータ上に位置する第２のプログラムからサービスを要求し得るように、遠隔手続き呼び出し（ＲＰＣ）を採用してもよい。ＷＳは、拡張マークアップ言語（ＸＭＬ）を使用して実装されてもよく、その優れた相互運用性および拡張性ならびにその機械可読記述によって特徴付けられ得る。ＷＳは、単純サービスを提供するプログラムが、相互に相互作用し、高度な付加価値サービスを送達し得るように、複合動作を達成するように疎結合方式で組み合わせられることができる。
（ウェブサービス記述言語（ＷＳＤＬ））

【0036】

ウェブサービス記述言語（ＷＳＤＬ）は、ＷＳによってもたらされる機能性を記述するために使用される、ＸＭＬベースのインターフェース記述言語である。ＷＳのＷＳＤＬ記述（ＷＳＤＬファイルとも称される）は、サービスが呼ばれ得る名称、それが予期する入力パラメータ、それが送達する出力、およびそれが使用するトランスポートプロトコル等の機械可読記述を提供する。開示されるシステムの側面に従って、ＷＳＤＬファイルは、サービス消費者と称され得る、他のソフトウェアアプリケーションが、利用可能なＷＳを発見し、ＷＳＤＬファイル内に含まれる情報に基づいて、それらのＷＳにアクセスする方法を容易に判定し得るように、サービスプロバイダによってネットワークにパブリッシュされてもよい。

【0037】

既存のＷＳＤＬバージョン２．０フォーマッティングを採用する、例示的ＷＳＤＬテンプレートは、以下に示される。例証されるように、既存のＷＳＤＬフォーマッティングは、例えば、サービスが使用するデータ、サービスによって提供される機能性、サービスが提供される様式、およびサービスがアクセスされ得る場所を含む、サービスに関連する識別情報を提供する。

【化1-1】

【化1-2】

【0038】

前述の実施例によって例証されるように、ＷＳＤＬバージョン２．０は、ウェブサービスを記述するために使用される、いくつかの要素をサポートする。より具体的には、既存のＷＳＤＬテンプレートは、ウェブサービスを記述するために使用される、以下の要素をサポートする。
・＜Ｔｙｐｅｓ＞要素は、特定のサービスによって使用されるデータを記述する。ＸＭＬスキーマ定義（ＸＳＤ）が、本目的のために使用される。
・＜Ｉｎｔｅｒｆａｃｅ＞要素は、特定のサービスを使用して実施されることができる動作（＜Ｉｎｔｅｒｆａｃｅ＞の一部として＜ｏｐｅｒａｔｉｏｎ＞要素内に定義されるように）を定義する。動作情報は、サービスに関連してパスされ得る、具体的入力、出力、および障害メッセージを含んでもよい。サービスとの本データのフォーマッティング交換は、ＷＳＤＬ２．０では、メッセージ交換パターン（ＭＥＰ）と称され得る。
・＜Ｂｉｎｄｉｎｇ＞要素は、ＷＳクライアントまたは消費者がＷＳと通信することができる方法を定義する。バインディングトランスポートプロトコルは、例えば、ＲＥＳＴ ＷＳのためのＨＴＴＰまたは従来のＷＳのためのＳＯＡＰ（ＸＭＬ＋ＨＴＴＰ）を含む、いくつかの異なるプロトコルのいずれかであってもよい。
・＜ｓｅｒｖｉｃｅ＞要素は、ＷＳのためのアドレス（＜ｅｎｄｐｏｉｎｔ＞要素内に規定される）と具体的インターフェースおよびバインディングを関連付ける。

【0039】

典型的には、ＷＳＤＬファイルは、ウェブサービス毎に生成される。図５は、ホテル予約サービスに対応する、例示的ＷＳＤＬファイルを図示する。図５に図示されるように、＜Ｔｙｐｅｓ＞、＜Ｉｎｔｅｒｆａｃｅ＞、＜ｂｉｎｄｉｎｇ＞、および＜ｓｅｒｖｉｃｅ＞ＷＳＤＬ要素は、予約サービスによって実施される動作、予約サービスによって使用されるデータ、予約サービスと通信する方法、および予約サービスがアクセスされ得る場所を定義するために使用される。
（ＷＳＤＬにおけるメッセージ交換パターン（ＭＥＰ））

【0040】

ＷＳＤＬは、サービス指向アーキテクチャ（ＳＯＡ）において定義されるために使用されてもよい。ＳＯＡは、一連の機能性を提供するソフトウェアコンポーネントが、非依存型サービスとしてカプセル化され、メッセージを介して、相互と通信する、アーキテクチャスタイルである。ＷＳＤＬが、ＳＯＡのサポートにおいて使用される場合、ＷＳＤＬは、１）サービスが送受信可能なメッセージ、および２）それらを動作にグループ化することによるメッセージの関連性を定義する。ＷＳＤＬ２．０は、メッセージ交換パターン（ＭＥＰ）と呼ばれる動作タイプを記述するための一般的機構を導入する。ＭＥＰは、同一動作に属するメッセージが交換される順序を定義する所定のテンプレートを採用することによって、ＷＳＤＬ動作の動作タイプを定義する。以下の８つのＭＥＰが、ＷＳＤＬ２．０において定義される。
・入力のみ：サービスがメッセージを受信する。
・ロバストな入力のみ：サービスがメッセージを受信し、障害の場合、障害メッセージを返す。
・入出力：サービスがメッセージを受信し、応答メッセージを返す。
・入力と随意の出力：サービスがメッセージを受信し、随意に、応答メッセージを返す。・出力のみ：サービスがメッセージを送信する。
・ロバストな出力のみ：サービスがメッセージを送信し、パートナーサービスにおける障害の場合、障害メッセージを受信する。
・出入力：サービスがメッセージを送信し、応答メッセージを受信する。
・出力と随意の入力：サービスがメッセージを送信し、随意に、応答メッセージを受信する。
これらのパターンは全て、サービスとサービスを遠隔で呼び出すパートナー（すなわち、サービス消費者）との間のメッセージ交換を記述する。
（既存のサービスパブリッシュおよび発見プロセス）

【0041】

図６は、既存のサービスパブリッシュおよび発見処理の論理フローを描写する。既存のＷＳパブリッシュおよび発見処理は、３つの一次システム、すなわち、サービスプロバイダシステム６１０と、サービスレジストリシステム６１２と、サービス消費者システム６１４とによる処理およびその間の通信を伴う。サービスプロバイダシステム６１０は、特定のサービスへのアクセスを提供するように動作する。図６におけるフロー１によって例証されるように、サービスプロバイダシステム６１０は、システム６１０を介してアクセス可能なサービス毎に、記述をパブリッシュする。パブリッシュ処理は、サービスレジストリシステム６１２へのサービスの記述の通信を伴ってもよい。サービス記述は、ＷＳＤＬファイルとしてフォーマットされてもよい。

【0042】

サービスレジストリシステム６１２は、例えば、ユニバーサル記述、発見、および統合（ＵＤＤＩ）であり得る、サービスレジストリインフラストラクチャ（ＳＲＩ）を活用してもよい。サービスレジストリシステムまたはＳＲＩ６１２は、サービス記述情報を記憶する。例示的実施形態では、ＳＲＩ６１２は、ＳＲＩ６１２にパブリッシュされるサービス毎に、ＷＳＤＬファイルを記憶する。

【0043】

図６のフロー２によって例証されるように、サービス消費者システム６１４は、ウェブサービスを発見するために、要求をＳＲＩ６１２に通信する。要求は、要求されるサービスのタイプを規定するパラメータを含んでもよい。要求に応答して、ＳＲＩ６１２は、要求に規定されるパラメータに対応するサービスのためのＷＳＤＬファイルをサービス消費者システム６１４に転送する。

【0044】

サービス消費者システム６１４は、受信されたＷＳＤＬファイルからの情報を使用して、サービスプロバイダ６１０によって提供されるサービスにアクセスするための要求をフォーマットする。例えば、サービス消費者システム６１４は、ＷＳＤＬファイル内の情報を使用して、サービスプロバイダシステム６１０が、特定のサービスへのアクセスを提供し、対応する要求をシステム６１０に伝送することを識別する。

【0045】

サービスパブリッシュおよびレジストリの代替アプローチも試みられている。例えば、サービスパブリッシュおよび発見は、一般的検索エンジン、特殊ＷＳ広告ウェブサイト、および／または単純様式におけるウェブ上での伝搬性ＷＳＤＬファイルを使用して実施されてもよい。
（ＷＳ意味論）

【0046】

ＷＳＤＬは、サービスを、関連入力および出力、エンドポイント、およびサービスに関連する他の情報とともに記述するための手段を提供する。本情報を用いる場合でも、ＷＳＤＬファイルを処理するコンピューティングシステムは、例えば、インターフェース記述内の有意義な識別子およびテキスト情報を含む、関連付けられた情報の全てを完全に処理するために、ヒト補助を要求し得る。故に、ＯＷＬ−Ｓ等のいくつかの既存の試みは、意味注釈をＷＳＤＬファイルに追加することに焦点を当てている。
（ウェブアプリケーション記述言語（ＷＡＤＬ）およびＲＥＳＴｆｕｌサービス記述言語（ＲＳＤＬ））

【0047】

既存のパブリッシュおよび発見システムは、ＷＡＳＤＬ以外の技術を採用してもよい。例えば、サービスは、表象状態転送（ＲＥＳＴ）スタイルウェブアプリケーションを記述するために使用され得るウェブアプリケーション記述言語（ＷＡＤＬ）を使用して、記述される場合がある。ＷＡＤＬは、「リソース」が中心概念であるという意味において、ＲＥＳＴまたはリソース指向アーキテクチャ（ＲＯＡ）スタイルに従う、典型的には、ＨＴＴＰベースのウェブアプリケーションを記述するために採用される、記述言語である。ＷＡＤＬは、２００９年８月３１日にＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓによってワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）に提出されたが、標準化されておらず、広く採用されていない。

【0048】

それと比較して、ＷＳＤＬバージョン２．０は、形式仕様であって、ＷＳを記述および定義するための業界標準である。ＷＳＤＬは、サービス指向記述言語である。ＷＳは、「サービス」が中心概念である、サービス指向アーキテクチャ（ＳＯＡ）を実装するための最も一般的技術のうちの１つになりつつある。既存のＷＳは、２つのタイプにグループ化されることができる。すなわち、１）従来のタイプである、大規模ＷＳと、２）ＲＥＳＴｆｕｌ ＷＳである。２つのタイプは、大規模ＷＳがＳＯＡＰ（ＨＴＴＰ＋ＸＭＬ）をトランスポートプロトコルとして使用し、ＲＥＳＴ設計原理に従わないという点において異なる。例えば、「追加」動作は、ＨＴＴＰにおいて「取得」動作にバインディングする。それと比較して、ＲＥＳＴｆｕｌ ＷＳは、ＲＥＳＴ設計原理に従い、１）ＨＴＴＰ方法を明示的に使用し、２）ステートレスであって、３）ディレクトリ構造状ＵＲＩをエクスポージャし、４）ＸＭＬ、ジャバスクリプトオブジェクト表記法（ＪＳＯＮ）を転送することを含む。ＲＥＳＴｆｕｌ ＷＳベースのシステムは、ＲＯＡ（「リソース」が中心概念である）ではなく、依然として、ＳＯＡであり得ることは、着目に値する。

【0049】

ＲＥＳＴｆｕｌサービス記述言語（ＲＳＤＬ）はまた、ＲＥＳＴｆｕｌ ＷＳのための機械可読ＸＭＬ記述でもある。ＲＳＤＬは、ウェブのＨＴＴＰアーキテクチャに基づいて、ＷＳの再使用を簡略化するように意図される。しかしながら、ＲＳＤＬは、ＲＥＳＴｆｕｌ ＷＳを記述するために具体的に設計されている一方、最新のＷＳＤＬ２．０は、本目的をすでに達成することができる。加えて、ＷＡＤＬと同様に、ＲＳＤＬは、広く採用されているＷＳＤＬ２．０と比較して、ＷＳを記述するための標準化言語ではない。
（Ｍ２ＭシステムおよびＭ２Ｍサービス）

【0050】

図７は、ウェブサービスシステムとＭ２Ｍシステムリソースとの間の通信経路を描写する、ネットワーク略図である。示されるように、Ｍ２Ｍエリアネットワーク７１０は、Ｍ２Ｍエンドデバイス７１２とＭ２Ｍゲートウェイ（ＧＷ）７１４との間の接続を提供する。Ｍ２Ｍエリアネットワーク７１０は、例えば、ＩＥＥＥ８０２．１５、Ｚｉｇｂｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等のパーソナルエリアネットワーク技術を採用するネットワークを含む、任意の好適なネットワークであってもよい。Ｍ２Ｍデバイス７１２は、湿度もしくは温度等の感覚情報の報告等のサービスを提供する、または照明スイッチ等のコントローラとして機能する、リソース制約デバイスであってもよい。Ｍ２Ｍエンドデバイス７１２は、コアネットワーク７２０を経由して、Ｍ２Ｍサーバ７２２と通信する、Ｍ２Ｍ ＧＷ７１４と通信する。Ｍ２Ｍサーバ７２２は、外部ネットワークおよびアプリケーション７３０とインターフェースをとる。外部アプリケーション７３０は、サービスの消費者であってもよく、Ｍ２Ｍサーバ７２２を介して、デバイス７１２によって提供されるサービスにアクセスしてもよい。
（ＣｏＡＰプロトコルにおけるリソース観察）

【0051】

制約付きアプリケーションプロトコル（ＣｏＡＰ）は、無線センサネットワーク等の制約付きノード／ネットワークと併用するために具体的に開発されたアプリケーションプロトコルである。ＣｏＡＰは、ますます注目が集まっており、ＩｏＴシステムのための有望なメッセージングプロトコルとなりつつある。ＣｏＡＰサーバとＣｏＡＰクライアントとの間のＲＥＳＴｆｕｌリソース動作のサポートに加え、ＣｏＡＰプロトコルはまた、リソース表現をＣｏＡＰサーバ（すなわち、サービスプロバイダ）から関与ＣｏＡＰクライアント（すなわち、サービス消費者）に自動的にプッシュすることを可能にする、「観察」と称される加入／通知機構を定義する。

【0052】

図８は、ＣｏＡＰを使用して記録された観察動作の実施例を図示する。ＣｏＡＰクライアントは、最初に、取得要求を観察オプションとともに、ＣｏＡＰサーバに送信し、関与リソースを登録する。クライアントは、３つの通知をＣｏＡＰサーバから受信し、第１の通知は、登録に応じて送信され、他の２つの通知は、リソースの状態が変化したときに発行される。通知は、ＣｏＡＰクライアントからのオリジナル取得要求内に含有される同一トークンをエコーし、したがって、ＣｏＡＰクライアントは、それらをオリジナル取得要求に容易に相関させることができる。
（既存のパブリッシュおよび発見処理の制限）

【0053】

多くの既存のソフトウェアシステム（エンタープライズアプリケーションシステム等）は、ＷＳ技術を使用することによって、分散かつ疎結合方式で実装されている。現在、新しく出現したＭ２Ｍ／ＩｏＴサービスを活用および／または統合するために、既存の方法論を拡張することに関心が集まっている。故に、それらの新しく出現したＭ２Ｍサービスを既存のＷＳベースのソフトウェアシステムにスムーズに統合するためのシステムおよび方法の開発は、解決されるべき基本問題である。そのようなシステムの開発は、新しく出現したシステムにおいて使用されている多様な技術によって複雑となる。例えば、多くの既存のシステムは、ＳＯＡを採用する一方、新しく出現したシステムは、典型的には、ＲＯＡを利用する。

【0054】

前述の議論に記載のように、サービスパブリッシュおよび発見の目的のために、サービスを記述するために使用され得る、いくつかの異なるサービス／リソース記述言語（例えば、ＷＳＤＬ、ＷＡＤＬ、またはＲＳＤＬ）が存在する。これらの言語はそれぞれ、ウェブベースのシステムによるＭ２Ｍサービスの効率的パブリッシュおよび発見を妨げる、制限を有する。本明細書における議論は、最も広く使用されている記述言語であるため、ＷＳＤＬに焦点を当てる。しかしながら、他の記述言語も類似制限を有し得、ＷＳＤＬに関連して以下に説明されるように、同様に拡張され、開示されるシステムおよび方法を提供し得ることを理解されたい。
（既存のＷＳＤＬパブリッシュ／発見アーキテクチャは、ＩｏＴシステムに不適切である）

【0055】

ＩｏＴの状況では、典型的には、リソース（温度、湿度等）を提供する、多数のデバイス（例えば、センサ）が存在する。ある推定によると、２０２０年までに５００億個のＩｏＴデバイスが存在することになるであろう。さらに、ＩｏＴネットワークでは、類似タイプのデバイスに関してであっても、デバイスは、多数のばらつきを有し得る。例えば、類似機能性を提供するデバイスが、異なる製造業によって作成された異なるソフトウェアを使用して得る等である。ＩｏＴデバイスは、デバイスが非アクティブ、すなわち、スリープとなり得る周期に起因して、常時、アクセス可能ではない場合がある。ＩｏＴデバイスはまた、デバイスがアクセスされ得る方法を含め、動的構成変化（例えば、スリープスケジュールの調節、入力および出力フォーマットの変更等）を経時的に受ける。

【0056】

図６に関連して前述のように、Ｍ２ＭおよびＩｏＴリソース／サービスをパブリッシュする既存の方法は、各サービスプロバイダが、リソースのそれぞれに対応するＷＳＤＬファイルを生成し、リソース毎に、ＷＳＤＬファイルのそれぞれをサービスレジストリに伝送することを伴う。しかし、本既存の処理は、ＩｏＴ状況では、最適とは言えない。例えば、サービスプロバイダ、すなわち、ＩｏＴデバイスと、ＷＳＤＬファイルを生成、パブリッシュ、および更新するために必要とされる、サービスレジストリとの間の直接相互作用は、リソース制約デバイスおよびネットワークにとって課題である。多くのＩｏＴデバイスは、制限されたコンピューティング処理容量および制限された電力予算を有し、その両方とも、ＳＲＩとの通信を抑制する。

【0057】

さらなる実施例として、ＩｏＴデバイスからの多数のＷＳＤＬファイルは、ＳＲＩを容易に圧倒し得る。前述のように、非常に多くのＩｏＴデバイスが存在する可能性が高く、それぞれ、１つまたはそれを上回るリソースまたはサービスを有する。現在の実践に従って、各リソースは、別個のＷＳＤＬファイルが、生成され、ＳＲＩに通信される結果をもたらす。多数のＷＳＤＬファイルが通信され、ＳＲＩ上に記憶されることは、ＳＲＩを容易に圧倒し、長時間のクエリ遅延につながり得る。

【0058】

デバイス構成の変更を表すための頻繁な更新は、現在のパブリッシュおよび発見プロシージャを使用すると、ＳＲＩ性能を損なわせ得る。ＩｏＴデバイスは、その構成を動的に調節するように適合される。例えば、ＩｏＴデバイスは、時として、その構成を調節し、エネルギーを保存する。構成におけるそのような変更は、最適には、デバイス上のリソースに対応するＷＳＤＬファイルにも表されるであろう。最適には、構成におけるそのような変更は、ＳＲＩ上に位置する対応するＷＳＤＬファイルにも表されるべきである。残念ながら、構成における変更に伴ってＳＲＩを更新するために要求されるであろう、頻繁な更新は、ＳＲＩの処理オーバーヘッドおよび性能を有意に増加させる。

【0059】

サービスパブリッシュおよび発見のための既存の方法は、ＩｏＴデバイス可用性を考慮しない。前述のように、いくつかのＩｏＴデバイスは、例えば、特定のデバイスがスリープに入ることに起因して、利用可能ではない周期を被る。故に、現在の実践に従って、サービス消費者システムが、ＳＩＲを介してサービスを特定し得る場合でも、消費者システムは、デバイスが、利用不可能である、すなわち、スリープ中であり得るため、特定のサービスプロバイダデバイスにアクセス不可能であり得る。

【0060】

本出願人はまた、リソースのパブリッシュおよび発見の既存のプロセスの不適切性に加え、リソースを記述するために現在使用されているウェブサービス記述言語（ＷＳＤＬ）が、ＩｏＴデバイスの特性に対応しないことにも着目する。例えば、既存のＷＳＤＬテンプレートは、Ｍ２Ｍサービスの特性を適切に記述するための特徴または要素を欠いている。所与のサービスに関して、３つのデータアイテム、すなわち、サービスがアクセスされ得る場所、サービスがアクセスされ得る時、およびサービスへのアクセスと関連付けられたコストが、把握される場合が多い。いくつかの点において、Ｍ２Ｍ／ＩｏＴデバイスによって提供されるサービスは、レストランが、関連付けられた３つのデータアイテム、すなわち、場所（ピザレストランが７８１ ３ｒｄ Ａｖｅ．に位置し得る）、時（ピザレストランが月曜日から金曜日の９ＡＭ〜６ＰＭに営業し得る）、および料金（ピザスライスがスライスあたり＄３．５である）を有し得るという点において、ピザレストランによって提供されるサービスと異ならない。ピザレストランを広告するとき、潜在的顧客に場所、時、および料金について知らせることが有用であることと同様に、Ｍ２ＭおよびＩｏＴおよびパブリッシュサービス情報についても、本出願人は、場所、時、および料金を規定する情報をパブリッシュすることが有用であることに着目する。しかしながら、既存のＷＳＤＬテンプレート要素は、本情報のパブリッシュを適切にサポートしない。

【0061】

サービスが位置する「場所」に関して、特定の場所に近接するサービスを利用する概念は、ＩｏＴシステムに共通である。例示的シナリオでは、可能性として考えられる火災イベントを検出するために、光／煙霧センサに近接する温度センサデバイスを特定することが所望され得る。別の例示的シナリオでは、特定のサービスへのアクセスに関わるネットワークトラフィックを低減させるように、近接近するサービスを特定することが所望され得る。既存のＷＳＤＬテンプレートは、位置情報をパブリッシュおよび発見するために指定される要素を欠いている。

【0062】

サービスがアクセスされ得る「時」に関して、ＩｏＴデバイスおよびそれらが提供するサービス／リソースは、利用可能ではない周期を被る。例えば、ＩｏＴデバイスが、デバイスがスリープである周期を経るのは、非典型的であるわけではない。利用可能ではない周期の間のサービスへのアクセスの試みは、サービスの失敗をもたらす可能性が高い。既存のＷＳＤＬテンプレートは、サービスに関連する時間的情報をパブリッシュおよび発見するために指定される要素を欠いている。既存のＷＳＤＬテンプレートおよび処理は、サービスが常時利用可能であると仮定する。

【0063】

サービスにかかり得る「料金」に関して、少なくとも部分的に、サービスにアクセスするために関連付けられたコストに基づいて、使用するサービスに関する決定が、行われてもよい。現在のＷＳＤＬバージョン２．０テンプレートは、サービスプロバイダがサービス記述内のそのサービスを使用するための価格（必ずしも、実際のお金ではなく、例えば、仮想通貨を使用する）を規定することをサポートしない。

【0064】

既存のＷＳＤＬテンプレートはまた、Ｍ２Ｍシステムにおける新しいサービスプロビジョニングまたは相互作用パターンを記述するための特徴を欠いている。既存のＷＳＤＬ２．０仕様は、８つのメッセージ交換パターン（ＭＥＰ）を定義する。定義されたＭＥＰの多くは、単一トランザクションにおけるサービスプロバイダとサービス消費者との間の相互作用を記述する。定義されたＭＥＰは、ある時間周期にわたる複数のトランザクションまたは相互作用を記述する能力を欠いている。

【0065】

既存のＷＳＤＬテンプレートはまた、例えば、ＣｏＡＰプロトコルにおける「観察」動作等の新しい相互作用パターンを記述することをサポートしない。図８に関連して前述のように、観察動作に関連して、ＣｏＡＰクライアントは、ＣｏＡＰサーバに登録後、規定時間周期にわたって、いくつかの通知を受信する。既存のＷＳＤＬは、そのような特徴を適切に記述する構造を欠いている。
（Ｍ２Ｍ／ＩｏＴサービスの拡張パブリッシュおよび発見）

【0066】

本出願人は、Ｍ２Ｍ／ＩｏＴデバイスによって提供されるサービスのパブリッシュおよび発見のための新しいシステムおよび方法を開発した。開示されるシステムおよび方法は、制約付きＭ２Ｍ／ＩｏＴデバイスに関して特に有用である。開示される実施形態のある側面によると、ＩｏＴデバイスは、リソース記述をＭ２Ｍ ＧＷに通信する。ＧＷは、中間ノードとして動作する。受信されるリソース毎に、ＧＷは、リソースを、ＷＳＤＬ−Ｉファイル（「Ｉ」は、ファイルが個々のサービスに関することを示す）と称される「個々の」ＷＳＤＬファイル内にラップする。ＧＷはまた、いくつかの特性を共有する、サービスのグループを作成し、グループ化を、ＷＳＤＬ−Ｇファイル（「Ｇ」は、ファイルがサービスのグループに関することを示す）と称され得るＷＳＤＬファイル内に記録する。ＧＷは、グループ化されたＷＳＤＬファイル（すなわち、ＷＳＤＬ−Ｇファイル）をＳＲＩにパブリッシュする。ＧＷは、典型的には、個々のＷＳＤＬ−Ｉファイルをパブリッシュせず、それによって、ＷＳＤＬプロセスから生じるオーバーヘッドを低減させる。例えば、ウェブサービスアプリケーションであり得る、サービス消費者システムは、特定のパラメータを満たすサービスに関して、ＳＲＩにクエリする。ＳＲＩは、クエリパラメータに対応するＷＳＤＬ−Ｇファイルを返す。サービス消費者システムは、ＷＳＤＬ−Ｇファイル内の情報を使用して、適切なＧＷを特定し、特定のＷＳＤＬ−Ｇファイルに規定されるサービスに関する特定の情報を要求する。それに応答して、ＧＷは、特定のＷＳＤＬ−Ｇファイルに対応するＷＳＤＬ−Ｉファイルを返す。サービス消費者システムは、受信されたＷＳＤＬ−Ｉファイル内の情報を使用して、１つまたはそれを上回るサービスを選択し、選択されたサービスを受信するための要求をフォーマットする。

【0067】

パブリッシュおよび発見処理における中間物としてのＧＷの導入は、Ｍ２Ｍエリアネットワーク内で頻繁であり得る、ＷＳＤＬ更新を留保する利点を有する。ＧＷは、ＷＳＤＬ−ＧファイルをＳＲＩにパブリッシュする必要のみあり、これは、ＳＲＩとの通信オーバーヘッドおよびＳＲＩ内の算出オーバーヘッドを低減させる。

【0068】

図９Ａは、Ｍ２Ｍ／ＩｏＴサービスのパブリッシュおよび発見のためのシステムアーキテクチャおよび高レベルフローを描写する、略図である。図９Ａを参照すると、複数のＭ２Ｍ／ＩｏＴデバイス９１０が、ＧＷ９１２と通信可能に結合される。デバイス９１０は、例えば、感覚情報を提供するセンサ等の任意のＭ２Ｍ／ＩｏＴデバイスであってもよい。デバイス９１０は、例えば、Ｍ２Ｍエリアネットワークを経由して、ＧＷ９１２と通信してもよい。図９Ａを参照すると、ステップ１において、デバイス９１０は、リソース記述をＧＷ９１２に通信する。リソース記述は、特定のデバイスによって提供されるリソースまたはサービスを記述する。情報は、例えば、サービスが行うこと、サービスが位置する場所、およびサービスと関連付けられたコストに関する情報を含んでもよい。例示的実施形態では、デバイス９１０およびゲートウェイ９１２は、図２６Ａ−Ｄに関連して以下に説明されるようなシステムを使用して実装されてもよい。

【0069】

ステップ２において、ＧＷ９１２は、サービス毎にＷＳＤＬ−Ｉファイルを生成することによって、個々のリソースのそれぞれをサービスにラップする。代替の例示的実施形態では、デバイス９１０は、ＷＳＤＬ−Ｉファイルを生成し、ファイルをＧＷ９１２に通信してもよい。いくつかのインスタンスでは、デバイス９１０は、例えば、温度、湿度、光等の複数のリソースを提供するように適合されてもよい。例示的シナリオでは、各リソースは、別個のＷＳＤＬ−Ｉファイルにラップされてもよい。しかしながら、典型的には、各デバイス９１０は、１つのみのリソースを提供する。故に、外部消費者システムは、前述のように、その既存のＳＯＡスタイルに準拠するＷＳＤＬ−Ｉファイルを通して、Ｍ２Ｍサービスを発見することのみ必要である。

【0070】

Ｍ２Ｍ／ＩｏＴデバイス９１０は、エネルギー効率目的のために、その構成を動的に変更する、または頻繁に利用不可能になり得る。そのような変更がデバイス９１０で生じると、対応するＷＳＤＬ−Ｉファイルも、適宜、更新される必要がある。そのような更新の発生は、関与し得る多数のデバイスを前提として、頻繁であり得る。開示されるシステムでは、ＷＳＤＬ−Ｉファイルは、直接ＳＲＩ９１４にパブリッシュされる代わりに、ＧＷ９１２に記憶される。故に、開示されるシステムおよび方法は、ネットワークを横断して多数のファイルを伝送する必要性を回避し、改良されたスケーラビリティをもたらす。各ＷＳＤＬ−ＩファイルをＳＲＩにパブリッシュするのではなく、ＧＷ９１２は、機能性の類似性に基づいて、リソースをグループ化する。例示的シナリオでは、ＧＷ９１２は、特定の地理的場所における温度読取値を記録する、デバイスのグループを定義してもよい。ＧＷ９１２は、特定のグループのメンバーであるサービスを記録する、ＷＳＤＬ−Ｇファイルと称される、ＷＳＤＬフォーマットファイルを作成する。

【0071】

図９Ａを参照すると、ステップ３において、ＧＷ９１２は、ファイルをＳＲＩ９１４に通信することによって、ＷＳＤＬ−Ｇファイルをパブリッシュする。例示的実施形態では、ＳＲＩ９１４は、図７に描写されるような典型的Ｍ２Ｍシステムアーキテクチャに準拠する、Ｍ２Ｍサーバに実装されてもよく、図２６Ｄに関連して以下に説明されるもの等のデバイス上に実装されてもよい。ＧＷ９１２は、続いて、更新情報をデバイス９１０から受信してもよい。例えば、デバイスは、その構成を変更する、またはスリープに入り得、これは、更新されたリソース情報がＧＷ９１２に通信される結果をもたらし得る。ＧＷ９１２は、そのような更新に応答して、適切なサービスのための対応するＷＳＤＬ−Ｉを変更してもよい。ＧＷ９１２はまた、受信されたリソース更新よって実装された変更が、ＷＳＤＬ−Ｇファイル内に反映されたグループ情報に影響を及ぼす場合、対応するＷＳＤＬ−Ｇを更新してもよい。一般に、ＷＳＤＬ−Ｇは、多くの場合、下層ＷＳＤＬ−Ｉファイルへの変更によって影響されない、高レベル共通情報を反映するため、頻繁に更新される必要はない。ＷＳＤＬ−Ｇファイルは、頻繁に変化しないため、ＧＷ９１２が改訂されたＷＳＤＬ−ＧファイルをＳＲＩ９１４に転送する必要があるインスタンスは、比較的に少ない。その結果、ＧＷ９１２とＳＲＩ９１４との間の更新の通信専用のリソースは、既存の方法と比較して低減される。

【0072】

任意の１つのＷＳＤＬ−Ｇファイルのために、複数のＷＳＤＬ−Ｉファイルが存在してもよい。故に、ＷＳＤＬ−ＩおよびＷＳＤＬ−Ｇファイルは、階層的に関連するものと見なされ得る。本関係は、複数のステップを伴う発見処理に反映される。図９Ａを参照すると、ステップ４に示されるように、Ｍ２Ｍ／ＩｏＴサービスを利用し得る任意のシステムであり得る、消費者システム９１６は、要求を生成し、ＳＲＩ９１４に伝送する。例示的実施形態では、サービス消費者システム９１６は、ウェブサービスによって提供される情報を使用する、ウェブベースのアプリケーションであってもよい。例示的シナリオでは、消費者システム９１６は、ＩｏＴ／Ｍ２Ｍシステムから天気予報サービスにアクセスし、受信された情報を使用して、リアルタイムで労働力の派遣を計画する、芝生整備システムであってもよい。別の例示的シナリオでは、消費者システム９１６は、道路側ＩｏＴ／Ｍ２Ｍシステムからの交通状態サービスにアクセスし、受信された情報を使用し、渋滞を緩和するように、トラフィックフローを動的に誘導する、交通管理システムであってもよい。例示的実施形態では、サービス消費者システム９１６は、図２６Ａ−Ｄに関連して説明されるようなシステムを使用して実装されてもよい。要求は、サービスの特性を定義する特定のパラメータを用いて、クエリを規定してもよい。例えば、要求は、特定の倉庫設備における６ＰＭ〜６ＡＭの時間の間の温度読取値を提供する、サービスを定義するパラメータを規定してもよい。ＳＲＩ９１４は、そこに記憶されたＷＳＤＬ−Ｇファイルにクエリし、クエリパラメータに応答して、サービスのグループに関する特定のＷＳＤＬ−Ｇファイルを識別する。応答ＷＳＤＬ−Ｇファイルは、消費者システム９１６に通信される。

【0073】

図９Ａのステップ５を参照すると、消費者システム９１６は、受信されたＷＳＤＬ−Ｇファイル内の情報を解析し、特定のファイルと関連付けられたゲートウェイを識別する。消費者システム９１６は、受信されたＷＳＤＬ−Ｇファイルに関する詳細な情報の要求を生成し、識別されたゲートウェイに伝送する。ＧＷ９１２は、要求を受信し、要求に対応するＷＳＤＬ−Ｇファイルを識別し、ＷＳＤＬ−Ｇファイルに対応するＷＳＤＬ−Ｉファイルを集め、その要求を起源とする集められたＷＳＤＬ−Ｉファイルを消費者システム９１６に通信する。

【0074】

ステップ６において、消費者システム９１６は、ＧＷ９１２から受信された受信ＷＳＤＬ−Ｉファイルを処理する。消費者システム９１６は、ＷＳＤＬ−Ｉファイル内に提供される情報を使用して、１つまたはそれを上回るサービスを選択する。選択されたサービスに関するＷＳＤＬ−Ｉファイル内の情報を使用して、消費者システム９１６は、選択されたサービスに対応する特定のデバイス９１０を識別し、サービスにアクセスするための要求を生成し、要求を特定のデバイス９１０に伝送する。

【0075】

図９Ａに関して、ステップ（１）−（３）は、サービスパブリッシュに関し、ステップ（４）−（５）は、サービス発見に関し、ステップ（６）は、サービスアクセスに関することを理解されたい。

【0076】

開示される方法では、ＷＳＤＬ−Ｉファイル内に含まれるサービスアクセス詳細は、消費者システムがＳＲＩにコンタクトしたときにＷＳＤＬファイルを通信する既存のプロセスと比較して、後に、すなわち、ＧＷにコンタクトするとき、消費者システムに通信される。開示されるシステムおよび方法におけるように、処理の後の段階でサービスアクセス詳細を提供することは、アクセスするための具体的サービスプロバイダを判定し、入力／出力およびエンドポイントアドレス情報に関連する正確なアクセス詳細を得ることを伴う、動的サービスプロバイダバインディングに対してより柔軟性を可能にする。本向上した柔軟性は、サービスステータスの動的変更およびＭ２Ｍデバイス内で生じ得る異種特性に対応する。それと比較して、既存のＷＳＤＬパブリッシュおよび発見処理では、サービス消費者は、サービスアクセス情報を直接ＳＲＩから得る。本既存の技術を使用すると、消費者は、デバイスのステータスが、変化している場合があり、かつもはや利用可能ではない場合があるため、デバイス上のサービスにアクセスできないであろうことが可能性として考えられる。加えて、選択した場合、サービス提供をもたらし得た類似サービスを伴うデバイスは、使用されないままとなるであろう。

【0077】

本願によるサービスの発見は、最初に、ＳＲＩにクエリし、続いて、ＧＷにクエリする、２ステッププロセスを伴うが、いくつかの状況では、発見は、ＧＷに対する１ステップ要求を用いて進められてもよい。例えば、消費者システムは、消費者システムが、ＧＷおよびグループに関する情報ならびにそこに記憶されたＷＳＤＬ−Ｉファイルを前もって得ている場合、直接、ＧＷにコンタクトし、適切なＷＳＤＬ−Ｉファイルを選択してもよい。
（ＷＳＤＬ−Ｉテンプレート）

【0078】

ＷＳＤＬ−Ｉテンプレートは、個々のサービス毎にＷＳＤＬ−Ｉファイルを生成するために使用される、一般的テンプレートである。前述のように、既存のＷＳＤＬ２．０テンプレートは、サービスへのアクセス方法に関連する情報のみを含むため、Ｍ２Ｍシナリオにおいて使用されるとき、最適とは言えない。本出願人は、ＷＳＤＬ−Ｉが、サービスへのアクセス方法を記述するだけではなく、また、例えば、サービスが利用可能な時、サービスプロバイダが位置する場所、およびサービスを使用するためのコスト等のコンテキストまたはソーシャル情報を記述するように、新しい属性を既存のＷＳＤＬテンプレートに追加することを提案する。これらはそれぞれ、Ｍ２Ｍシナリオにおけるサービスプロビジョニングの成功に影響を及ぼす潜在性を有する、無視できない要因である。

【0079】

サービスを使用するためのコストに関して、一般的用語「仮想金額」が、本明細書で使用され、例えば、Ｍ２Ｍシステムにおいて使用され、ソーシャル関連の協働をサポートまたは促進することができる、クレジット、スコア、または仮想マネー等の任意の好適な値の測定値を指してもよい。例えば、デバイスは、他のシステムがそのリソースにアクセスすることを可能にするためのクレジットを獲得する、または仮想マネーもしくはスコアを獲得してもよい。仮想価格の値は、異なるアプリケーションシナリオに依存してもよい。仮想価格は、ネットワークオペレータ、デバイス自体、またはネットワークキャリアによって設定されてもよい。

【0080】

例示的実施形態では、ＷＳＤＬテンプレートは、サービスが利用可能な時、サービスプロバイダが位置する場所、およびサービスを使用するためのコストを記述する情報を受信するための新しい属性を含むように適合されている。例示的実施形態では、属性は、以下の実施例に示されるように、現在のＷＳＤＬ２．０テンプレートの＜ｅｎｄｐｏｉｎｔ＞セクションに追加されている。

【化2-1】

【化2-2】

【化2-3】

【0081】

所与のＷＳＤＬ−Ｉファイルに関して、＜ｏｐｅｒａｔｉｏｎ＞要素は、入力および出力のためのメッセージ交換パターンおよびデータタイプを記述する。入力／出力のための実践的値は、ＷＳＤＬファイル内に含まれない。むしろ、入力は、サービス消費者から生じ、出力は、入力を処理後、サービスプロバイダから生じるであろう。本明細書に提案されるような新しい属性等のサービス記述情報に関して、値は、ＷＳＤＬファイル内に含まれる。これは、具体的ＵＲＩがサービスがアクセスされ得る場所を示すために含まれる、＜ｅｎｄｐｏｉｎｔ＞部分に類似する。異なる測定基準系が、広く展開され、他のサービスとの相互動作可能である、Ｍ２Ｍサービスの能力を低下させずに、属性のための値を設定するために使用されてもよい。潜在的実施形態の一側面によると、意味論情報が、消費者がそれらの属性内の値の意味を正しく理解することに役立てるために属性に追加される。

【0082】

例示的実施形態では、個人は、サービスのために規定されるべき属性をカスタマイズしてもよいことを理解されたい。例えば、個人は、コンピューティングシステムによって生成および表示されるユーザインターフェースを採用し、サービスに適用され、それに関して記録されるべき属性を規定してもよい。図１０Ａは、サービスのためのＷＳＤＬ−Ｉファイル内に記憶されるべき属性を規定するために、システムによって生成され、個人によって使用され得る、例示的ユーザインターフェースを描写する。示されるように、ユーザインターフェースは、ユーザが、個人がサービスに適用することを所望し、サービスのためのＷＳＤＬ−Ｉファイル内に含まれる属性を選択し得る、チェックボックスを提供する。図１０Ａの例示的実施形態では、ユーザインターフェースは、ユーザが、ＷＳＤＬ−Ｉファイル内に、サービスが利用可能な時、サービスプロバイダが位置する場所、およびサービスを使用する仮想コストを規定する属性を含むことを選択することを可能にする、ユーザインターフェース特徴を提供する。いったんユーザが、サービスに関連する特定の属性を選択し、「確認」ボタンを選択すると、対応するＷＳＤＬ−Ｉファイルが、ユーザ入力に準拠して構成されてもよい。図１０Ａの例示的実施形態は、対応するＷＳＤＬ−Ｉファイル内に含まれるべき属性に応じて、特定の属性を選択するための特徴を図示するが、ユーザインターフェースは、付加的および／または異なる属性を選択するための付加的特徴を伴って改変および／または拡張されてもよいことを理解されたい。
（ＷＳＤＬ−ＩによるＣｏＡＰにおける「オブザーバ」動作の記述有効化）

【0083】

ＷＳＤＬ−Ｉファイルは、ＣｏＡＰプロトコルにおいて使用される「観察」動作を記述するように有効にされてもよい。ＣｏＡＰプロトコルでは、クライアントが所与のリソースのための観察動作をサブスクライブすることを意図するとき、クライアントは、特定の情報をリソースプロバイダに伝送する。例えば、クライアントは、クライアントがプロバイダから送信される後続通知を理解することを可能にするために使用されるべきトークンおよびクライアントが通知を受信すべき時間を示す観察持続時間を伝送してもよい。

【0084】

観察動作をＷＳＤＬ−Ｉテンプレート内に記述することは、以下に説明されるような特定のプロシージャを実施することを伴う。例示的シナリオでは、関わるリソースは、デバイス上の温度リソースである。故に、パラメータ名は、容易な理解のために、「温度」に関連してもよい。

【0085】

観察動作を記述するために、新しいデータ要素が、観察登録のためにＷＳＤＬ−Ｉ内に定義されてもよい（すなわち、ｘｓ：ｅｌｅｍｅｎｔｎａｍｅ＝“ｏｂｓｅｒｖｅＲｅｇｉｓｔ”）。観察登録データ要素は、以下の実施例に示されるように、サービス消費者によって使用されるべきサービストークンおよび観察持続時間を含んでもよい。異なるトークンが、続いて、ＣｏＡＰ層内に自動的に生成され、これは、ＣｏＡＰクライアントによって、後続通知を認識するために使用される。それと比較して、本明細書に定義されるｏｖｓｅｒｖｅＳｅｒｖｉｃｅＴｏｋｅｎは、サービス消費者（ＣｏＡＰ層の上方にある）が、サービスプロバイダからの通知を認識することを有効にするためのものである。以下の実施例に示されるように、新しいデータ要素は、ＷＳＤＬ−Ｉファイルの＜ｔｙｐｅ＞セクションに定義されてもよい。

【化3】

【0086】

観察動作を実装することはまた、通知のための新しいデータ要素（すなわち、ｘｓ：ｅｌｅｍｅｎｔｎａｍｅ＝“ｏｂｓｅｒｖｅＲｅｓｐｏｎｓｅ”）を定義することも伴う。ｏｖｓｅｒｖｅＲｅｓｐｏｎｓｅ通知データ要素は、以下の例示的リストに示されるように、例えば、リソース表現（例えば、温度）およびトークンを示す、要素を含む。

【化4】

【0087】

オブザーバ動作を実装することはさらに、ＷＳＤＬ−Ｉファイル内の＜ｏｐｅｒａｔｉｏｎ＞セクションにおけるパターン属性のための新しい値（すなわち、「Ｏｂｓｅｒｖｅ−Ｉｎ−Ｏｕｔ」）を定義することを伴う。概して、ＷＳＤＬ２．０は、任意の者が、ＷＳＤＬプロセッサによって処理され得る、新しいパターンを認識および理解することができる、新しいパターンを定義することを可能にする。実際、Ｏｂｓｅｒｖｅ−Ｉｎ−Ｏｕｔは、ｏｖｓｅｒｖｅＴｉｍｅＤｕｒａｔｉｏｎが０に設定される場合、従来のＩｎ−Ｏｕｔパターンとなってもよい。故に、ＷＳＤＬ−Ｉファイル内の＜ｏｐｅｒａｔｉｏｎ＞は、以下の実施例に示されるような「観察」動作として記述されてもよい。以下に示されるように、動作のパターンは、「Ｏｂｓｅｒｖｅ−Ｉｎ−Ｏｕｔ」（消費者が次の時間周期において通知のバッチを受信し得ることを示す）に設定され、入力／出力メッセージは、上記に定義されるような新しいデータ要素、すなわち、それぞれ、ｏｖｓｅｒｖｅＲｅｇｉｓｔ（登録のために使用される）およびｏｖｓｅｒｖｅＲｅｓｐｏｎｓｅ（後続通知のために使用される）を使用する。

【化5】

（ＷＳＤＬ−Ｇテンプレート）

【0088】

ＷＳＤＬ−Ｉファイルを生成することによって、受信されたデバイスリソースのそれぞれをサービスとしてラップすることに加え、ＧＷはまた、類似サービスをグループにカテゴリ化する。ＧＷは、ＷＳＤＬ−Ｉファイル内に含まれる情報を要約することによって、グループ毎にＷＳＤＬ−Ｇファイルを生成する。ＧＷは、代替として、または加えて、直接、Ｍ２Ｍ／ＩｏＴデバイスから受信されるリソース記述内に含まれる情報から、ＷＳＤＬ−Ｇファイルを生成してもよい。例示的ＷＳＤＬ−Ｇテンプレートは、図１１に描写される。ＷＳＤＬ−Ｇテンプレートは、特定のＷＳＤＬ−Ｇファイルを生成する際に使用される、一般的テンプレートである。図１１の例示的ＷＳＤＬ−Ｇテンプレートによって例証されるように、ＷＳＤＬ−Ｇファイルは、典型的には、サービスのグループに関連する高レベルまたは集約された統計的情報を含む。図１１のＷＳＤＬ−Ｇテンプレートは、例証のために提示される。図１１に描写されるものの付加的または異なる属性が、代替実施形態では使用されてもよいことを理解されたい。

【0089】

図１１を参照すると、例示的ＷＳＤＬ−Ｇテンプレートは、＜ｇｒｏｕｐＩｄｅｎｔｉｆｉｅｒ＞属性を含んでもよい。＜ｇｒｏｕｐＩｄｅｎｔｉｆｉｅｒ＞属性は、グループＩＤを定義するデータを受信するように意図される。グループＩＤは、グループ内に定義されたサービスの特定のグループについての情報に関する要求がＧＷに行われるときに、消費者サービスによって使用されてもよい。

【0090】

ＷＳＤＬ−Ｇテンプレートは、＜ｇｒｏｕｐＦｕｎｃｔｉｏｎ＞属性を含んでもよい。＜ｇｒｏｕｐＦｕｎｃｔｉｏｎ＞属性は、特定のグループの機能を記述する情報を受信する。例示的シナリオでは、情報は、明確な意味論情報を含んでもよい。

【0091】

＜ｎｕｍｂｅｒＯｆＭｅｍｂｅｒｓ＞属性は、現在グループ内に存在するメンバーの数を示す情報を受信する。例示的実施形態では、メンバーの数の値は、正確な数字ではなく、むしろ、比較用語で表されるより一般化された測定基準であってもよい。例えば、メンバーの数は、特定の値を上回るまたはそれ未満、例えば、２０より大きい（＞）として表されてもよい。

【0092】

＜ｇｒｏｕｐＳｔａｔｉｓｔｉｃｓ＞属性は、サービスのグループに関する統計に関する情報を受信する。例えば、属性は、本グループ内のサービスにアクセスする際の成功の確率を示す情報を含んでもよい。加えて、ＱｏＳ関連パラメータもまた、テンプレートに追加されてもよい。情報は、特定のグループと関連付けられたサービスを使用するかどうかを評価する際、サービス消費者システムによって使用されてもよい。

【0093】

＜ｌｏｃａｔｉｏｎＲｅｇｉｏｎ＞属性は、グループ内のサービスが提供される領域を示す情報を受信する。

【0094】

＜ｉｎｐｕｔＡｌｌｏｗｅｄ＞属性は、サービスを実施するために消費者から必要とされるパラメータを記述する。＜ｏｕｔｐｕｔＥｘｐｅｃｔｅｄ＞属性は、グループ内のサービスから予期される出力を記述する。＜ｉｎｐｕｔＡｌｌｏｗｅｄ＞および＜ｏｕｔｐｕｔＥｘｐｅｃｔｅｄ＞属性は、典型的には、個々のサービスに関する具体的記述を提供せず、むしろ、クライアントが初期または高レベル理解を有するためのグループ内のサービスの入力および出力の要約リストを含む。

【0095】

＜ＧＷＡｄｄｒｅｓｓ＞属性は、特定のＷＳＤＬ−Ｇテンプレートを起源とするＧＷにコンタクトする方法を示す情報を含む。例えば、情報は、ＧＷが到達され得るＩＰアドレスおよび／または具体的ポートを含んでもよい。

【0096】

例示的実施形態では、個人は、サービスのグループ化のために規定される情報をカスタマイズしてもよいことを理解されたい。例えば、個人は、特定のグループ内のサービス毎に記憶された情報内に含まれる属性を規定するために、コンピューティングシステムによって生成および表示される、ユーザインターフェースを採用してもよい。図１０Ｂは、システムによって生成され、個人によって使用され、サービスのための属性を規定し得る、例示的ユーザインターフェースを描写する。示されるように、ユーザインターフェースは、ユーザが、個人がサービスの特定のグループのための対応するＷＳＤＬ−Ｇファイル内に含まれることを所望する特定の属性を選択し得る、チェックボックスを提供する。図１０Ｂの例示的実施形態では、ユーザインターフェースは、ユーザが、ＷＳＤＬ−Ｇファイル内に、サービスのそれぞれによって提供されるサービスの品質を規定する属性および／またはそれを介してサービスがアクセスされるゲートウェイの特性を規定する属性を含むかどうかを選択することを可能にする、ユーザインターフェース特徴を提供する。いったんユーザが、サービスのグループに関連する特定の属性を選択し、「確認」ボタンを選択すると、ＷＳＤＬ−Ｇファイルは、ユーザ選択に準拠して構成される。図１０Ｂの例示的実施形態は、対応するＷＳＤＬ−Ｇファイル内に含まれるべき属性に応じて、特定の属性を選択するための特徴を図示するが、ユーザインターフェースは、付加的および／または異なる属性を選択するための付加的特徴を伴って改変および／または拡張されてもよいことを理解されたい。
（リソース記述とＷＳＤＬ−Ｉサービス記述との間のマッピング）

【0097】

Ｍ２Ｍシステムでは、他のシステムに利用可能にされるデバイス動作は、リソースと称され、特定の記述構文および言語を使用して記述される。ウェブサービス動作では、他のシステムに提供される機能は、サービスと称され、特定の記述構文および言語を使用して記述される。故に、ＧＷが、リソース記述をデバイスから受信すると、ＧＷは、リソース記述からの情報をウェブサービス記述を予期するシステムに理解可能であるようにフォーマットする必要がある。本プロセスは、時として、ＷＳＤＬ−Ｉファイルを生成することによるリソースのサービスへのラップと称される。処理は、典型的には、リソース記述からの要素をＷＳＤＬ−Ｉファイル内の対応する要素にマップすることを伴う。

【0098】

リソースを記述するために、多数の異なるアプローチが存在する。故に、処理リソース記述を処理し、ＷＳＤＬ−Ｉファイルを作成するために、あらゆるインスタンスで使用され得る、一般的プロシージャは、存在しない。コアリソースディレクトリ（ＲＤ）は、ＩＥＴＦドメイン内の一般的概念であって、多くの場合、リソース記述を記憶するためのリポジトリとして使用される。ＲＤは、デバイス上にホストされるリソースについてのウェブリンクのためのリポジトリとしての役割を果たす。ＲＤは、デバイスのためのＲＥＳＴインターフェースのセットを実装し、リソースディレクトリエントリと称される、ウェブリンクのセットを登録および維持する。リソースディレクトリエントリは、リソース記述としての役割を果たし得る。例示的実施形態では、ＲＤは、Ｍ２Ｍ／ＩｏＴデバイスがＲＤに登録し、そのリソース記述をＧＷに通信するように、ＧＷと同じ場所に存在してもよい。

【0099】

図１２は、ＲＤを使用して記述されるリソース記述をＷＳＤＬ−Ｉファイルにマップするためのプロセスを描写する。図１２の左側に示されるように、デバイス−１は、ＰＯＳＴ要求を初期化し、ＰＯＳＴのペイロード部分内にフォーマットされたリンクによって記述される、その温度リソースをＧＷに提出してもよい。ＰＯＳＴ要求は、リソースを記述するための関連情報の全てを含み、その情報は、ＷＳＤＬ−Ｉファイルを生成するために使用される。提供される情報は、例えば、リソースが行うこと、リソースが位置する場所、リソースが利用可能な時、およびリソースと関連付けられたコストを規定する情報を含んでもよいことを理解されたい。要求の受信に応じて、ＧＷは、リソース記述をＲＤ内に記憶し、ＷＳＤＬ関連プロシージャを実行し、ＷＳＤＬ−Ｉファイルを生成する。

【0100】

概して、ＧＷは、リソース記述内の情報を解析し、解析された情報をＷＳＤＬテンプレートの適切な要素にマップすることによって、リソース記述からＷＳＤＬ−Ｉファイルを生成する。本マッピングは、受信されたリソース記述のフォーマッティングに応じて、変動する。しかしながら、概して、マッピングは、ＧＷが、リソース記述からのどの情報がＷＳＤＬテンプレート内のどの要素に対応するかを識別する情報を含むことを要求する。

【0101】

図１３は、受信されたリソース記述と生成されたＷＳＤＬ−Ｉファイルとの間の例示的マッピングを描写する、略図である。図１３を参照すると、参照文字Ａは、トランスポートプロトコルを規定するリソース記述内の情報をマークする。対応する矢印によって記載されるように、リソース記述情報は、ＷＳＤＬ−Ｉファイル内の＜ｂｉｎｄｉｎｇ＞要素で使用されてもよい。

【0102】

参照文字Ｂは、特定のサービスプロバイダを規定するリソース記述内の情報をマークする。対応する矢印によって記載されるように、本特定のリソース記述情報は、ＷＳＤＬ−Ｉファイル内のｓｅｒｖｉｃｅ＞要素で使用されてもよい。

【0103】

参照文字Ｃは、デバイス／リソースが利用可能であり得ない時を示す情報をマークする。対応する矢印によって記載されるように、リソース記述からの本特定の情報は、ＷＳＤＬ−Ｉファイル内の＜ａｖａｉｌａｂｉｌｉｔｙ＞要素で使用されてもよい。

【0104】

参照文字Ｄは、特定のリソースと関連付けられた仮想価格を示す情報をマークする。対応する矢印によって記載されるように、本特定の情報は、ＷＳＤＬ−Ｉファイル内の＜ｖｉｒｔｕａｌＰｒｉｃｅ＞要素にマップされてもよい。

【0105】

参照文字Ｆは、リソースまたはサービスがアクセスされ得る場所を示す情報をマークする。対応する矢印によって記載されるように、本特定の情報は、ＷＳＤＬ−Ｉファイル内の＜ｇｅｏＬｏａｃａｔｉｏｎ＞要素にマップされてもよい。

【0106】

参照文字Ｅは、リソースまたはサービスのタイプを規定する情報をマークする。対応する矢印によって記載されるように、情報は、ＷＳＤＬ−Ｉファイル内の＜ｔｙｐｅ＞要素にマップされてもよい。

【0107】

参照文字Ｇは、特定のリソースのためのインターフェース情報を規定する情報をマークする。対応する矢印によって記載されるように、情報は、ＷＳＤＬ−Ｉファイル内の＜Ｉｎｔｅｒｆａｃｅ＞要素にマップされてもよい。
（サービスグループ化）

【0108】

ＧＷは、類似特性を有するサービスのグループを識別し、識別されたグループ化をＷＳＤＬ−Ｇファイル内に記録する。ＧＷは、任意の有用基準に基づいて、サービスをグループ化してもよい。例示的シナリオでは、ＧＷは、類似機能性を有するサービスをグループ化してもよい。典型的には、ＧＷがリソース記述をデバイスから受信すると、生じる２つの典型的シナリオが存在する。第１のシナリオではリソースは、新しいタイプであって、その場合、ＧＷは、リソースのための新しいグループを定義し、グループのためのＷＳＤＬ−Ｇファイルを生成する。第２のシナリオでは、リソース記述は、既存のリソース記述への更新を定義し、その場合、ＧＷは、特定のリソースと関連付けられたグループおよびＷＳＤＬ−Ｇファイルを更新する。

【0109】

図１４は、新しいリソースに関するリソース記述がＧＷにおいて受信されると実施される処理のフロー図を描写する。図１４を参照すると、ステップ１において、ＧＷは、新しいリソース記述をデバイスから受信する。リソース記述は、例えば、提供される機能性を規定する情報、リソースが利用可能な時間、リソースの場所、およびリソースを使用するためのコストを含む、リソースに関する関連詳細を通信するために好適な任意のフォーマットにおけるものであってもよい。例示的シナリオでは、リソースは、ＲＤを使用して通信される。

【0110】

再び、図１４を参照すると、ステップ２において、ＧＷは、リソース情報を解析し、新しいＷＳＤＬ−Ｉファイルを生成し、ファイルをメモリ内に記憶する。ＧＷは、受信されたリソース記述を処理し、図１３に関連して前述のように、マッピングを実施してもよい。

【0111】

ステップ３において、ＧＷは、受信されたリソースとＧＷによって定義された既存のグループを比較する。ＧＷは、リソースが既存のグループにカテゴリ化されることができるかどうかを評価する。その場合、処理は、ステップ４に継続し、既存のＷＳＤＬ−Ｇファイルが、特定のリソースの受信を反映するように更新される。リソースが、既存のグループ内にカテゴリ化されることができない場合、処理は、ステップ５に継続し、新しいＷＳＤＬ−Ｇファイルが、作成される。

【0112】

ステップ４において、ＧＷは、新しく識別されたリソースを既存のグループに追加する。より具体的には、ＧＷは、既存のグループのためのＷＳＤＬ−Ｇファイルを更新し、新しいリソース／サービスを反映する。ＷＳＤＬ−Ｇファイルの更新に応じて、ＧＷは、新しいメンバーをグループに追加することが、以前に１つまたはそれを上回るＳＲＩに通信された任意のＷＳＤＬ−Ｇファイルの更新を要求し得るかどうかを評価する。例えば、新しいリソースが、グループ内の既存のメンバーより豊富な情報を提供し得る場合、ＷＳＤＬ−Ｇファイル内の＜ＯｕｔｐｕｔＥｘｐｅｃｔ＞セクション（図１３参照）は、本変更を反映するように更新される必要があり得る。ＧＷが、以前に配信されたＷＳＤＬ−Ｇファイルが更新を要求すると判定する場合、ＧＷは、ＷＳＤＬ−Ｇ更新要求をＳＲＩに開始する。

【0113】

ステップ５において、ＧＷが、新しいリソースが任意の既存のグループに属さないことを判定するインスタンスでは、ＧＷは、新しいグループを定義し、グループのための新しいＷＳＤＬ−Ｇファイルを作成する。グループが最初に定義されるとき、１つのグループのメンバーのみ存在するであろう。

【0114】

ステップ６において、ＧＷは、新しいＷＳＤＬ−Ｇファイルを１つまたはそれを上回るＳＲＩにパブリッシュする。

【0115】

図１５は、ＧＷが、更新を既存のリソースに提供するリソース記述を受信するときに実施される処理のフロー図を描写する。示されるように、ステップ１において、ＧＷは、リソース更新をデバイスから受信する。Ｍ２Ｍ／ＩｏＴデバイスが、デバイスの入力／出力、サービス可用性、またはデバイスの動作の任意の他の側面における変更を反映する、動的変更を受け得ることは、典型的である。その結果、ＧＷは、デバイス変更のステータスとして、リソース更新要求をデバイスから頻繁に受信してもよい。

【0116】

ステップ２において、更新要求内に含まれる情報に応じて、ＧＷは、更新された特定のリソースのための対応するＷＳＤＬ−Ｉファイルを更新する。本明細書に開示される改良された処理下、ＷＳＤＬ−Ｉファイルは、典型的には、ＳＲＩデバイスではなく、ＧＷにのみ記憶されることを理解されたい。故に、Ｍ２Ｍ／ＩｏＴデバイスに典型的である、サービスへの頻繁な更新は、ＳＲＩを更新するためにリソースを費やすことを要求しない。

【0117】

ステップ３において、ＷＳＤＬ−Ｉファイルの更新に加え、ＧＷはまた、ソース更新がその対応するサービスが属するグループに影響を及ぼし得るかどうかを評価する。ＧＷが、リソース更新がグループおよび対応するＷＳＤＬ−Ｇファイルに更新を要求しないと判定する場合、さらなるアクションは、必要とされず、処理は、ステップ４において終了する。ＧＷが、リソース更新がグループの更新を要求すると判定する場合、処理は、ステップ５に継続する。

【0118】

ステップ５において、ＧＷは、グループを更新し、受信されたサービス更新を反映する。例えば、受信された更新が、デバイスがバッテリエネルギー消耗に起因していずれは到達不能となるであろうことを示す場合、ＧＷは、サービスを対応するグループから削除するであろう。ＧＷは、グループのためのＷＳＤＬ−Ｇファイルを更新する。

【0119】

ステップ６において、ＧＷは、ＷＳＤＬ−Ｇファイルのローカルコピーの更新に加え、また、１つまたはそれを上回るＳＲＩ上に記憶されたＷＳＤＬ−Ｇファイルの任意のコピーを更新する必要があるかどうかを判定する。例えば、具体的出力インターフェースを有する全デバイスが利用不可能となる場合、ＧＷは、具体的出力がもはやサポートされないため、ＷＳＤＬ−Ｇファイル内の＜ｏｕｔｐｕｔＥｘｐｅｃｔ＞セクションを修正するであろう。本シナリオでは、ＧＷは、更新がグループおよびＷＳＤＬ−Ｇへの変更を要求し、変更が現在ＷＳＤＬ−Ｇのコピーを維持している任意のＳＲＩに成し遂げられるべきほど重要であることを判定してもよい。他のインスタンスでは、

【0120】

図１３および１４に関連する上記の議論は、識別されたサービスのグループを記録するためのＷＳＤＬ−Ｇファイルの生成を参照する。ＧＷは、類似特性を有するサービスのグループを識別し、識別されたグループ化をＷＳＤＬ−Ｇファイル内に記録する。ＧＷは、任意の有用基準に基づいて、サービスをグループ化してもよい。例示的シナリオでは、ＧＷは、類似サービス機能性を有するサービスをグループ化してもよい。類似機能性を有するサービスの判定は、任意の好適な様式で実施されてもよい。リンク−フォーマットがリソースを記述するために使用される、例示的シナリオでは、「ｃｔ」パラメータは、リソースの機能性を示すためのものであって、ＧＷは、同一「ｃｔ」を有する全リソース／サービスを含むグループを作成してもよい。

【0121】

図１６は、グループを個々のリソース／サービスから生成するために採用される例示的論理の例証を提供する。図１６に描写される実施例では、２つのリソース記述が、ＧＷに提出されており、両方とも、温度に関連する。故に、ＧＷは、「温度」と呼ばれる新しいグループを定義してもよく、２つのリソースをグループに割り当ててもよい。いくつかのインスタンスでは、リソースは、同一グループに属すると特徴付けられ得るが、それでもなお、個々のリソース／サービス間にばらつきを有し得る。例えば、リンクフォーマット仕様において定義されるような結果コンテンツに対応し得る、「ｒｔ」パラメータから、リソース／サービスの一方は、摂氏で温度読取値を提供する一方、他方は、華氏で読取値を提供する。また、２つのリソースは、その「ｉｆ」パラメータ（インターフェース記述）に関しても異なる。「ｉｆ」パラメータは、２つのリソース／サービスの一方が豊富な情報を提供可能である一方、他方が基本情報のみを提供することを示す。これは、リソース／サービスを提供するデバイスの一方が、「センサ豊富」インターフェースをサポートする、シナリオで生じ得、それによって、温度読取値だけではなく、また、感知／サンプリングタイムスタンプ、最近の傾向データ（より寒冷化または温暖化しつつある）等の関連付けられたコンテキスト情報も返す。本同一シナリオでは、「センサ基本」インターフェースを伴う他方のデバイスは、単純温度値のみを返してもよい。

【0122】

図１６の実施例に関して、「温度」グループを定義後、ＧＷは、グループのためのＷＳＤＬ−Ｇファイルを生成する。図１６の実施例に対応する例示的ＷＳＤＬ−Ｇファイルは、図１７に図示される。図１７に示されるように、ＧＷは、＜ｇｒｏｕｐＩｄｅｎｔｉｆｉｅ＞パラメータを使用して、具体的グループ識別子がグループに割り当てられており、本インスタンスでは、「ＴＥＭ０９０９０１１」の値を有する。ＧＷは、＜ｇｒｏｕｐＦｕｎｃｔｉｏｎ＞パラメータのための値を定義しており、本インスタンスでは、「温度」の値が割り当てられている。グループ内のメンバーの数は、＜ｎｕｍｂｅｒＯｆＭｅｍｂｅｒｓ＞パラメータを使用して識別され、本特定の実施例では、２０の値が割り当てられている。メンバーの数に関する値は、グループと関連付けられたリソースの数（いくつかのデバイスの数に対応し得る）を表してもよい。＜ｇｒｏｕｐＳｔａｔｉｓｔｉｃｓ＞パラメータは、グループ内のサービスへのアクセスの試みの９０％が成功することを示す。グループのための場所は、＜ｌｏｃａｔｉｏｎＲｅｇｉｏｎ＞パラメータを使用して識別され、本特定の実施例では、グループのメンバーがＡｍｈｅｒｓｔタウンエリア内に分布されていることを示す。ＷＳＤＬ−Ｇファイルは、グループのメンバーが典型的に承認するクエリ入力のタイプを識別するための＜ｉｎｐｕｔＡｌｌｏｗｅｄ＞パラメータを含む。本特定の実施例では、＜ｉｎｐｕｔＡｌｌｏｗｅｄ＞パラメータは、本グループ内のサービスが郵便番号または地理的座標に関するクエリ／入力値を承認することを示す。言い換えると、サービスは、郵便番号または地理的座標によって、温度読取値に関するクエリに応答する。最後に、ＷＳＤＬ−Ｇファイルは、グループ内に定義されたサービスが関連付けられ、それを通してグループ内のサービスがコンタクトされ得る、ゲートウェイのアドレスを識別する、＜ｇｗＡｄｄｒｅｓｓ＞パラメータを含む。図１７の特定の実施例では、＜ｇｗＡｄｒｅｓｓ＞パラメータは、ＧＷがアクセスされ得る、特定のインターネットプロトコルアドレスを識別する。
（サービス発見およびアクセス処理）

【0123】

図１３から１６に関連する議論は、主に、サービスパブリッシュのための例示的実施形態の記述に対処する。いったんサービスがＧＷに登録され、サービスのグループがＳＲＩにパブリッシュされると、サービスは、サービス消費者システムによって発見およびアクセスされてもよい。図１８は、サービス発見のための例示的プロセスのフロー図を描写する。図１８を参照すると、ステップ１において、例えば、ウェブサービスであり得る、サービス消費者システムである消費者−１は、Ｍ２Ｍシステムによって提供されるサービスのためのサービス発見要求を初期化する。言い換えると、サービス消費者システムは、アプリケーションまたはビジネス需要を満たすために、サービスの使用を要求することを判定する。

【0124】

ステップ２において、サービス消費者システムである消費者−１は、要求を生成し、ＳＲＩに通信する。要求は、クエリとしてフォーマットされてもよい。例えば、消費者−１は、所望のサービスに関する特性を規定するクエリを生成および伝送してもよい。例示的シナリオでは、要求は、所望の機能性、その機能性が必要とされる時間、およびサービスが提供される好ましい場所を規定してもよい。図１７に関連して前述の値のいずれかは、サービス消費者システムから提出されるクエリのための基礎であってもよいことを理解されたい。要求／クエリは、任意の好適な技術を使用してフォーマットおよび通信されてもよい。

【0125】

ステップ３において、ＳＲＩは、要求／クエリ内の情報を使用して、そこに記憶されたグループ情報を検索し、サービス消費者システムによって提出された検索基準を満たすサービスグループを識別する。より具体的には、ＳＲＩは、ＳＲＩに以前に転送された種々のＷＳＤＬ−Ｇファイルに規定されるデータを検索する。サービスのグループ、すなわち、規定される基準を満たすＷＳＤＬ−Ｇファイルの識別に応じて、ＳＲＩは、応答ＷＳＤＬ−Ｇファイルのリストを消費者−１システムに通信する。

【0126】

いくつかのシナリオ下では、消費者−１によって提出された選択基準に対応するＷＳＤＬ−Ｇファイルが存在しない場合がある。そのようなシナリオでは、ＳＲＩは、グループ情報を返さなくてもよい。そのようなインスタンスでは、消費者−１システムは、新しい選択基準のセットを用いて、新しいクエリを生成してもよい。

【0127】

ステップ４において、消費者−１システムは、識別されたＷＳＤＬ−Ｇファイルのコンテンツを解析し、さらなる情報が得られるべき１つまたはそれを上回るグループを選択する。言い換えると、消費者−１システムは、所望のサービスを提供するための望ましい候補であるグループを判定する。消費者−１システムは、いったん特定のグループを選択すると、グループに関する個々のファイルが記憶されたゲートウェイを識別する。ゲートウェイを識別する情報は、選択されたグループに対応するＷＳＤＬ−Ｇファイルから読み出される。

【0128】

図１８のステップ５において、消費者−１は、クエリを生成し、選択されたサービスのグループに対応するＷＳＤＬ−Ｇファイル内で識別された特定のゲートウェイＧＷ−１に伝送する。クエリは、選択されたサービスグループ化内で識別された特定のサービスに関する情報を要求する。例示的シナリオでは、通信は、特定のＷＳＤＬ−Ｇファイル内で識別されたサービスに対応するＷＳＤＬ−Ｉファイルを要求する。

【0129】

ステップ６において、ＧＷ−１は、消費者−１からのクエリを解析し、要求される情報を識別する。例示的シナリオでは、ＧＷ−１は、そのメモリを検索し、要求内で識別されたＷＳＤＬ−Ｇファイルに対応するＷＳＤＬ−Ｉファイルを識別する。言い換えると、ＧＷ−１は、そのメモリを検索し、識別されたグループ内に含まれるサービスのためのＷＳＤＬ−Ｉファイルを読み出す。開示される実施形態の側面に従って、識別されたグループ内のサービスの数が非常に多い場合、ＧＷ−１は、検索時間を加速するために、返信リスト内のエントリの数を制限してもよい。ＧＷ−１は、識別されたＷＳＤＬ−Ｉファイルを消費者−１システムに通信する。

【0130】

ステップ７において、消費者−１システムは、ＧＷ−１から返されたＷＳＤＬ−Ｉファイルを解析する。消費者−１は、グループ内のサービス毎に、利用可能な情報の全てを利用可能にする。消費者−１は、ＷＳＤＬ−Ｉファイル内に含まれる情報に基づいて、１つまたはそれを上回るサービスを選択する。

【0131】

ステップ８において、消費者−１は、要求を生成し、選択された１つまたはそれを上回るサービスに伝送する。消費者−１システムは、要求をフォーマットする方法を判定するために、選択されたサービスのためのＷＳＤＬ−Ｉファイル内の情報を使用する。例えば、消費者−１は、ＷＳＤＬ−Ｉファイルから、要求をサービスを提供するデバイスに伝送するための具体的様式およびフォーマットを判定する。

【0132】

例示的シナリオでは、消費者１システムは、ＷＳＤＬ−Ｉ要求を選択されたサービスを提供するデバイスに伝送し、図１８では、デバイス−１として識別される。代替シナリオでは、消費者−１システムが通信するように適合されないプロトコルにおいてデバイス−１と通信する必要があり得る。そのようなシナリオでは、デバイス−１との通信は、ＧＷ−１を通してルーティングされてもよい。ＧＷは、サービスアクセスプロセスの間、変換またはプロキシ機能を実施してもよい。例示的シナリオでは、そのような変換は、消費者−１システムがＨＴＴＰを使用して通信するように適合されているが、デバイス−１がＣｏＡＰプロトコルを使用するように適合されている場合に要求されてもよい。

【0133】

最後に、ステップ９において、デバイス−１は、消費者−１によって要求されるサービスを実施する。
（可用性を意識したサービス発見およびアクセス）

【0134】

前述のように、開示される実施形態の側面によると、ＷＳＤＬテンプレートは、サービス可用性、サービス場所、およびサービス価格を含む、サービスに関する付加的情報の記録をサポートするように修正されてもよい。本情報の捕捉の結果、情報は、サービス発見処理およびサービスアクセスの間に使用されてもよい。

【0135】

図１９は、サービス可用性に関する情報がサービス毎に記録されている、サービス発見の間の例示的処理を図示する。図１９を参照すると、消費者−１は、図１８に関連して上記で概略されたようなプロセスに従って、デバイス−１上のサービス−１を発見し、それにアクセスする。そのプロセスの一部として、消費者−１は、サービス−１に関するサービス／デバイス可用性情報を受信する。例示的シナリオでは、サービス／デバイス可用性情報は、サービス−１が特定の日時に利用不可能になるようにスケジュールされていることを示してもよい。そのようなシナリオでは、図１９８のステップ４に示されるように、消費者−１サービスは、サービス−１が利用不可能となるであろうことを識別し、ステップ５において、ＧＷ−１に先を見越してコンタクトし、サービス−１によって提供されるものと同一タイプのサービスを提供することができる代替デバイスを検索する。殆どのインスタンスでは、消費者−１サービスは、ＧＷ−１が、直接、サービス−１と同一グループ内にある他の利用可能なサービスの代替ＷＳＤＬ−Ｉファイルを返すことが可能であるため、ＳＲＩにコンタクトすることによって、新しいサービスを発見する必要はないことを理解されたい。ステップ６において、ＧＷ−１は、サービス−１と類似サービスを提供し、要求される時間の間に利用可能な他のサービスに関してメモリを検索する。ＧＷ−１は、消費者−１に、デバイス−２上のサービス−２がサービス−１に取って代わる候補であることを通信する。通信は、サービス２のためのＷＳＤＬ−Ｉファイルを含む。ステップ７において、消費者−１システムは、サービス−２のためのＷＳＤＬ−Ｉファイル内の情報を使用して、要求を生成し、サービス−２に伝送する。

【0136】

可用性情報を利用するための他の方法も、存在することを理解されたい。例えば、可用性を意識したサービス発見およびアクセスをサポートするための代替方法は、消費者システムが、ＧＷへのその要件を規定し、ＧＷが、消費者システムが、利用不可能になるとき、順番にサービスにアクセスし得るように、サービスのバッチを返すことである。
（場所を意識したサービス発見およびアクセス）

【0137】

図２０は、サービスの地理的場所に関する情報が、サービス毎に記録された、対応するＷＳＤＬ−Ｉファイル内に記憶されている、サービス発見の間の例示的処理を図示する。図２０を参照すると、消費者−１は、図１８に関連して上記で概略されるようなプロセスに従って、デバイス−１上のサービス−１を発見し、それにアクセスする。そのプロセスの一部として、消費者−１システムは、サービス−１に関するサービス／デバイスの地理的場所情報を受信する。アプリケーションまたはビジネス要件に基づいて、ステップ４において、消費者−１は、続いて、サービス−１に近接する１つまたはそれを上回る付加的サービスを要求してもよい。サービス−１が温度の報告に関連し、消費者−１が企業のエンタープライズシステム内の火災報知アプリケーションである、例示的シナリオでは、消費者−１は、サービス−１に近接する光または煙霧に関する付加的読取値を必要とすることを判定してもよい。ステップ５において、消費者−１システムは、特定の特性を伴うサービスに関する要求を生成し、ＧＷ−１に伝送する。要求がサービス−１に近接するサービスに関するものであるため、ＧＷ−１もまた、要求されるサービスに関するＷＳＤＬ−Ｉファイルをそこに記憶しているであろう可能性が高い。ステップ６において、ＧＷ−１は、要求される基準を満たすサービスを検索し、デバイス２上のサービス２を識別する。ＧＷ−１は、消費者−１システムに、サービス２を識別し、サービス２のためのＷＳＤＬ−Ｉファイルを含む、応答を伝送する。ステップ７において、消費者−１システムは、サービス−２にアクセスするための要求を伝送する。
（仮想価格を意識したサービス発見およびアクセス）

【0138】

図２１は、仮想価格に関する情報がサービス毎に記録されている、サービス発見の間の例示的処理を図示する。図２１を参照すると、ステップ１において、消費者−１システムは、ＳＲＩから読み出されたＷＳＤＬ−Ｇファイルを使用して、ＧＷ−１がＷＳＤＬ−Ｇに対応するサービスに関する情報を有すると識別する。ステップ２において、消費者−１は、さらなるサービス発見のために、要求をＧＷ−１に通信する。ステップ３に示されるように、ＷＳＤＬ−Ｉ内に含まれる仮想価格情報を用いて、デバイス自体またはネットワークオペレータは、異なる目的のために、価格を動的に更新することができる。例えば、デバイスが、長時間、過負荷であって、他のピアと比較して、非常に多くのエネルギーを消費している場合、そのデバイスによって提供されるサービスの仮想価格は、サービスアクセス要求のうちのいくつかが同一グループ内の他のピアにオフロードされ得るように、より高い値に設定され得る。価格情報をＷＳＤＬ−Ｉファイル内に含める能力は、サービスプロバイダが、例えば、要求側の場所、要求側組織の識別、または要求側組織のメンバー等の任意の数の変数に応じて、より柔軟性のあるサービススキームを有することを有効にし、そのいずれも、異なる価格を課金させ得る。

【0139】

再び、図２１を参照すると、ステップ４において、ＧＷは、ＷＳＤＬ−Ｉファイルを含む候補のリストを生成し、消費者−１に伝送する。ＷＳＤＬ−Ｉファイル内の情報は、各サービスと関連付けられた仮想価格情報を含有する。ステップ５において、消費者−１は、サービスを選択するために、ＷＳＤＬ−Ｉファイルのそれぞれを評価する。評価の一部として、消費者−１は、サービスのそれぞれを使用する相対的価格を検討する。例示的シナリオでは、消費者−１システムは、少なくとも部分的に、サービスの相対的価格に起因して、サービス−２を使用することを判定する。ステップ６において、消費者−１は、要求をサービス２に伝送する。ステップ７において、サービス−２は、サービスからの結果を返す。
（ｏｎｅＭ２Ｍ実施形態）

【0140】

本明細書に開示されるシステムおよび方法の多くの異なる可能性として考えられる実装が、存在することを理解されたい。例示的実施形態では、リソースパブリッシュおよび発見のための開示される方法は、ｏｎｅＭ２Ｍ仕様に従って、ＲＥＳＴｆｕｌリソースベースのプログラミングインターフェースを使用して実装されてもよい。

【0141】

概して、図３に関連して前述のように、ｏｎｅＭ２Ｍ共通サービス層は、共通サービス機能（ＣＳＦ）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、これは、いくつかの異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード等、およびその対応するＣＳＥは、それぞれ、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥと称される）のいずれか上にホストされることができる。ｏｎｅＭ２Ｍアプリケーションは、多くの場合、アプリケーションエンティティ（ＡＥ）と称される。

【0142】

サービスパブリッシュおよび発見のためのシステムの例示的Ｍ２Ｍ実施形態では、２つの新しいリソース＜ＷＳＤＬ−Ｉ＞および＜ＷＳＤＬ−Ｇ＞が、定義される。図２２は、２つのリソースの例示的実装を図示する。図は、リソースを記述するために、以下のｏｎｅＭ２Ｍ慣例を使用する。正方形ボックスは、リソースおよび子リソースを表すために使用され、丸角を伴う正方形ボックスは、属性を表すために使用され、多様な各属性および子リソースが、定義され、「＜」および「＞」を用いて境界されたリソース名は、リソースの作成の間に割り当てられる名称を示す。

【0143】

図２２を参照すると、リソース＜ＷＳＤＬ−Ｉ＞および＜ＷＳＤＬ−Ｇ＞はそれぞれ、属性および子リソースのバッチを有する。例えば、＜ＷＳＤＬ−Ｉ＞リソース内の属性は、前述のように、タイプ、インターフェース、バインディング等、ＷＳＤＬ−Ｉファイル内に定義されるような異なるデータ要素に対応する。同様に、＜ＷＳＤＬ−Ｇ＞リソース内の属性は、図１１に関連して前述のような異なるデータ要素に対応する。

【0144】

Ｍ２Ｍリソース＜ＷＳＤＬ−Ｉ＞および＜ＷＳＤＬ−Ｇ＞は、Ｍ２Ｍシステム内で使用されることを理解されたい。Ｍ２Ｍ ＧＷは、ｘｍｌベースのＷＳＤＬ−ＩおよびＷＳＤＬ−Ｇファイルを生成し、外部サービス消費者によって発見およびアクセスされる。示されるように、ｘｍｌベースのＷＳＤＬ−ＩおよびＷＳＤＬ−Ｇファイルは、表記＜ＸＭＬ−ｂａｓｅｄＷＳＤＬ−Ｉｆｉｌｅ＞および＜ＸＭＬ−ｂａｓｅｄＷＳＤＬ−Ｉｆｉｌｅ＞によって図に図示されるように、＜ｃｏｎｔａｉｎｅｒ＞タイプのリソース内に記憶されてもよい。

【0145】

Ｍ２Ｍ ＧＷは、エッジ機能／コンポーネントとして動作する。Ｍ２Ｍ ＧＷは、Ｍ２Ｍシステム内の異なるノード間で通信するための現在のｏｎｅＭ２Ｍアーキテクチャを活用するだけではなく、また、従来のＷＳベースのプロトコルを使用する、外部サービス消費者システムが、Ｍ２Ｍサービスにアクセスすることを有効にする。

【0146】

図２３は、Ｍ２Ｍサービス層の視点からのサービスパブリッシュを図示する。図２３を参照すると、いくつかのｏｎｅＭ２Ｍサービス層エンティティが、それぞれ、Ｍ２Ｍデバイス、Ｍ２Ｍ ＧＷ、およびＭ２Ｍサーバ上にある。より具体的には、ＡＥは、Ｍ２Ｍデバイス上で動作し、ＭＮ−ＣＳＥは、Ｍ２Ｍ ＧＷ上で動作し、ＩＮ−ＣＳＥは、Ｍ２Ｍサーバ上で動作する。故に、例えば、温度読取値アプリケーションであり得る、ＡＥは、ＭＮ−ＣＳＥに登録することによって、そのリソース記述を提出可能である。ＭＮ−ＣＳＥは、＜ｔｅｍｐｅｒａｔｕｒｅ−Ａｐｐ＞リソースおよび子＜ＷＳＤＬ−Ｉ＞リソースを生成する。ＭＮ−ＣＳＥは、ＩＮ−ＣＳＥに登録することによって、ＷＳＤＬ−ＧをＳＲＩにパブリッシュし、＜ＷＳＤＬ−Ｇ＞リソースは、＜ＩＮ−ＣＳＥＢａｓｅ＞／＜ＭＮ−ＣＳＥＢａｓｅ＞の子リソースとして作成される。

【0147】

図２４は、前述のプロセスと関連付けられた詳述なコールフローを図示する。図２４を参照すると、ステップ１−７は、リソース記述の報告／生成に関連する一方、ステップ８−１５は、リソース記述の更新に関連する。

【0148】

図２４のステップ１において、ＡＥは、制約付きＭ２Ｍデバイス上で実行する。例示的シナリオでは、ＡＥは、デバイスによって測定される温度情報を読取り、報告する。Ｍ２Ｍ ＧＷノード上で起動するＭＮ−ＣＳＥを発見後、ＡＥは、それ自体をＭＮ−ＣＳＥに登録する。登録メッセージは、Ｍ２Ｍデバイスが提供するリソースの記述を含む。リソース記述は、ＷＳＤＬ−Ｉファイルの議論に関連して前述のもの等の属性を含む。

【0149】

ステップ２において、ＭＮ−ＣＳＥは、ＡＥに対応する＜ａｐｐｌｉｃａｔｉｏｎ＞リソースを生成する。登録メッセージ内に提供されるリソース記述を使用して、ＭＮ−ＣＳＥは、＜ａｐｐｌｉｃａｔｉｏｎ＞リソース下に置かれ得る、＜ＷＳＤＬ−Ｉ＞リソースを生成する。

【0150】

ステップ３において、リソースの登録および生成の完了成功後、ＭＮ−ＣＳＥは、確認を生成し、ＡＥに伝送する。

【0151】

ステップ４において、ＭＮ−ＣＳＥは、ＡＥおよびそのリソースが既存のサービスのグループに割り当てられ得るかどうかを識別する。ＭＮ−ＣＳＥが、リソースが新しいグループに割り当てられることができないと判定する場合、新しいグループを生成する。

【0152】

ステップ５において、ＭＮ−ＣＳＥは、リソース作成要求を生成し、Ｍ２Ｍサーバ上で動作するＩＮ−ＣＳＥに伝送する。作成要求は、前述のように、ＷＳＤＬ−Ｇに関連する全属性を含む。

【0153】

ステップ６において、ＭＮ−ＣＳＥからの要求を受信後、ＩＮ−ＣＳＥは、ステップ５の要求内で転送されるグループ記述情報に基づいて、＜ＷＳＤＬ−Ｇ＞リソースを生成する。

【0154】

ステップ７において、＜ＷＳＤＬ−Ｇ＞リソースを作成後、ＩＮ−ＣＳＥは、ＭＮ−ＣＳＥへの応答を生成し、アクションを確認する。

【0155】

本処理の時点で、新しいリソースのパブリッシュが、完了する。リソース／サービスは、前述のように、消費者システムによって発見されるために利用可能となり、個々のリソースは、要求されるために利用可能となる。

【0156】

Ｍ２Ｍデバイスは、ステータスにおける変更を受ける。例えば、Ｍ２Ｍデバイスは、リソースを節約するようにスリープする周期を経る場合がある。故に、Ｍ２Ｍデバイスの動作ステータスは、頻繁に変化する。図２４を参照すると、ステップ８において、Ｍ２Ｍデバイス上のＡＥが、ステータスを変更する、またはステータスの今後の変更を有するとき、ＡＥは、更新要求を生成し、ＭＮ−ＣＳＥに通信する。要求は、ステータスの変更についての情報を含み、変更が＜ＷＳＤＬ−Ｉ＞リソースの１つまたはそれを上回る属性を変更するために行われるべきことを信号伝達する。

【0157】

ステップ９において、ＭＮ−ＣＳＥは、＜ＷＳＤＬ−Ｉ＞リソースを更新し、ステータスにおける変更を反映する。更新のタイプは、変動されてもよい。例えば、更新は、例えば、リソース内の「可用性」属性を修正し、ノードスリープ中を反映するための要求等、リソース内の属性に関連し得る。別の例示的シナリオでは、更新は、障害ハードウェアに起因する、＜ＷＳＤＬ−Ｉ＞リソースの削除を要求してもよい。

【0158】

ステップ１０において、＜ＷＳＤＬ−Ｉ＞リソースを更新後、ＭＮ−ＣＳＥは、確認を生成し、ＡＥに伝送する。

【0159】

ステップ１１において、ＭＮ−ＣＳＥは、＜ＷＳＤＬ−Ｉ＞が属するグループへの更新が、＜ＷＳＤＬ−Ｉ＞リソースへの更新を反映するように必要とされることを判定する。

【0160】

ステップ１２において、ＭＮ−ＣＳＥは、リソース更新要求を生成し、ＩＮ−ＣＳＥに伝送する。要求は、ＩＮ−ＣＳＥ上の対応する＜ＷＳＤＬ−Ｇ＞リソースを更新することを規定する。

【0161】

ステップ１３において、ＭＮ−ＣＳＥからの要求受信後、ＩＮ−ＣＳＥは、要求内に含まれるグループ更新記述に基づいて、＜ＷＳＤＬ−Ｇ＞リソースを更新する。

【0162】

ステップ１４において、＜ＷＳＤＬ−Ｇ＞リソースを更新後、ＩＮ−ＣＳＥは、更新の確認を生成し、ＭＮ−ＣＳＥに伝送する。
（代替サービスパブリッシュおよび発見）

【0163】

本明細書に開示されるシステムおよび方法に準拠するサービスパブリッシュおよび発見のための付加的実施形態が、存在することを理解されたい。図９および２２に関連して前述の実施形態では、ＧＷは、リソース制約デバイスを支援する際、重要な役割を果たす。図２５に描写されるような代替実施形態では、独立型デバイス（例えば、携帯電話）は、ＧＷをトラバースせずに、直接、Ｍ２Ｍサーバとトークしてもよい。故に、ＧＷによって実施されるものとして前述の処理は、代替実施形態では、Ｍ２Ｍサーバにも拡張され得る。加えて、ＳＲＩは、Ｍ２Ｍサーバ上に実装されるのではなく、図２５に示されるように、別個のエンティティとして実装され得る。
（例示的コンピューティング環境）

【0164】

図２６Ａは、１つまたはそれを上回る開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷＯＴだけではなく、ＩｏＴ／ＷｏＴサービス層等のコンポーネントまたはノードであってもよい。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、例えば、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の機能性および論理エンティティならびにユーザインターフェースを生成するための論理エンティティを含むことができる。

【0165】

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

【0166】

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

【0167】

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候のモニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスのモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

【0168】

図２６Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、例えば、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２０Ｃおよび２０Ｄで図示されるデバイスを含む、１つまたはそれを上回るサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）、または同等物によって実装されてもよい。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス、または同等物を備え得る、ネットワークの１つもしくはそれを上回るノードによって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装されてもよい。

【0169】

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

【0170】

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

【0171】

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

【0172】

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用されてもよい。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでもよく、また、他の開示されるシステムおよび方法と併せて使用されてもよい。

【0173】

一実施形態では、例えば、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の論理エンティティは、図２０Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされてもよい。例えば、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備えてもよい。

【0174】

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含んでもよい。前述のように、本システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

【0175】

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装されてもよい。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装されてもよい。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つもしくはそれを上回る独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令、および同等物）として、もしくは１つまたはそれを上回る既存のノードの一部としてのいずれかで実装されてもよい。実施例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２６Ｃまたは図２６Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス、または同等物）上で作動するソフトウェアの形態において実装されてもよい。

【0176】

さらに、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の本願の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

【0177】

図２６Ｃは、例えば、ｅＮＢ２１００、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ、または同等物等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の論理エンティティを実行する、またはそれらを含むことができる。デバイス３０は、図２６Ａ−Ｂに示されるようなＭ２Ｍ端末デバイスまたは非Ｍ２Ｍネットワークの一部であり得る。図２６Ｄに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非可撤性メモリ４４と、可撤性メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含んでもよい。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本ノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであってもよい。

【0178】

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および同等物であってもよい。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行してもよい。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行ってもよい。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させてもよい。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行ってもよい。

【0179】

図２６Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に連結される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御してもよい。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを実施するために、通信回路を制御してもよい。図２６Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内にともに統合され得ることが理解されるであろう。

【0180】

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

【0181】

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

【0182】

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

【0183】

プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶してもよい。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶してもよい。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させる、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得る、または情報をユーザに表示するように構成されてもよい。別の実施例では、ディスプレイは、セッション状態に関する情報を示してもよい。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にしてもよい。

【0184】

プロセッサ３２は、電源４８から電力を受容してもよく、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成されてもよい。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。

【0185】

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

【0186】

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

【0187】

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

【0188】

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

【0189】

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

【0190】

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

【0191】

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

【0192】

さらに、コンピューティングシステム９０は、例えば、図２６Ａおよび図２６Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含有し、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にしてもよい。

【0193】

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または同等物を含む、Ｍ２Ｍネットワークのノード等の機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施するならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装されてもよい。ＡＥ３１０、ＣＳＥ３１２、ＮＳＥ３４０、ＧＷ２２６、ＧＷ９１２、ＳＣＳ９１６、およびＵＥ９１６等の論理エンティティは、コンピュータ可読記憶媒体上に記憶されるコンピュータ実行可能命令の形態において具現化されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形または物理媒体を含むが、それらに限定されない。

【0194】

故に、本出願人は、Ｍ２Ｍ／ＩｏＴサービスのパブリッシュおよび発見のための例示的システムおよび方法を開示した。例示的システムおよび方法では、ゲートウェイシステムは、リソース記述をＭ２Ｍ／ＩｏＴデバイスから受信する。ゲートウェイシステムは、受信されたリソース記述毎に、リソースについての情報を記録する個々のウェブサービス記述言語ファイル（ＷＳＤＬ−Ｉファイル）を作成する。ゲートウェイは、類似特性を伴うサービスのグループを識別し、識別されたグループ毎に、グループに関する情報を記録するウェブサービス記述ファイル（ＷＳＤＬ−Ｇファイル）を生成する。ＷＳＤＬ−Ｇファイルは、サービスレジストリインフラストラクチャ（ＳＲＩ）に通信される。消費者システムは、特定の基準を満たすサービスに関してＳＲＩにクエリし、基準を満たすサービスのグループに関するＷＳＤＬ−Ｇファイルを受信する。消費者システムは、ゲートウェイから選択されたＷＳＤＬ−Ｇファイルに対応するＷＳＤＬ−Ｉファイルを要求する。消費者システムは、受信されたＷＳＤＬ−Ｉファイルを使用して、特定のサービスを選択し、選択されたサービスに関するＷＳＤＬ−Ｉファイル内の情報を使用して、対応するＭ２Ｍ／ＩｏＴデバイスからそのサービスを要求する。

【0195】

例証的実施形態が開示されたが、潜在的実施形態の範囲は、明示的に記載されたものに限定されないことを理解されたい。例えば、システムは、主に、Ｍ２ＭゲートウェイおよびＳＲＩを参照して説明されたが、他のコンピュータ配列も、加えて、または代替として、使用されてもよい。想定される実施形態は、特定のアーキテクチャまたは技術を使用した実装以外にも拡張する。例えば、潜在的実施形態は、ＷＳＤＬ以外のコンピュータ可読記述言語を採用してもよい。潜在的実装は、あらゆるタイプのサービス層アーキテクチャ、システム、および実施形態に及ぶ。

【0196】

本明細書に説明される種々の技法は、ハードウェアまたはソフトウェア、もしくは、必要に応じて、両方の組み合わせに関連して実装されてもよいことを理解されたい。したがって、本明細書に説明される主題の方法および装置またはそのある側面または一部は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または任意の他の機械可読記憶媒体等の有形媒体内に具現化されるプログラムコード（すなわち、命令）の形態をとってもよく、プログラムコードが、コンピュータ等の機械の中にロードされ、それによって実行されると、機械は、本明細書に説明される主題を実践するための装置となる。プログラムコードが、媒体上に記憶される場合、これは、当該プログラムコードが１つまたはそれを上回る媒体上に記憶され、集合的に当該アクションを実施する、すなわち、統合された１つまたはそれを上回る媒体が、アクションを実施するためのコードを含有する場合に当てはまり得るが、しかし、１つを上回る単一媒体が存在する場合、コードの任意の特定の部分が任意の特定の媒体上に記憶される要件は存在しない。プログラマブルコンピュータ上のプログラムコード実行の場合、コンピューティングデバイスは、概して、プロセッサと、プロセッサによって可読である記憶媒体（揮発性および不揮発性メモリおよび／または記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含む。１つまたはそれを上回るプログラムは、例えば、ＡＰＩ、再使用可能制御、または同等物の使用を通して、本明細書に説明される主題に関連して説明されるプロセスを実装または利用してもよい。そのようなプログラムは、好ましくは、高レベル手続き型またはオブジェクト指向型プログラミング言語において実装され、コンピュータシステムと通信する。しかしながら、プログラムは、所望に応じて、アセンブリまたは機械言語で実装されることもできる。いずれの場合も、言語は、コンパイルまたは解釈言語であって、ハードウェア実装と組み合わせられてもよい。

【0197】

例示的実施形態は、１つまたはそれを上回る独立型コンピュータシステムまたはデバイスの文脈において、本明細書に説明される主題の側面の利用を参照し得るが、本明細書に説明される主題は、そのように限定されず、むしろ、ネットワークまたは分散型コンピューティング環境等の任意のコンピューティング環境に関連して実装されてもよい。本明細書に説明される主題のなおもさらなる側面は、複数の処理チップまたはデバイス内もしくはそれを横断して実装されてもよく、記憶も同様に、複数のデバイスを横断して影響されてもよい。そのようなデバイスは、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパーコンピュータ、または自動車および飛行機等の他のシステムの中に統合されるコンピュータを含み得る。

【0198】

以下は、前述の説明に現れ得る、サービスレベル技術に関連する頭字語のリストである。
ＡＥ アプリケーションエンティティ
ＣｏＡＰ 制約付きアプリケーションプロトコル
ＣｏＲＥ 制約付きＲＥＳＴｆｕｌ環境
ＣＳＥ 共通サービスエンティティ
ＣＳＦ 共通サービス機能
ＧＷ ゲートウェイ
ＨＴＴＰ ハイパーテキスト転送プロトコル
ＩＥＴＦ インターネット技術タスクフォース
ＩｏＴ モノのインターネット
ＪＳＯＮ ジャバスクリプトオブジェクト表記
Ｍ２Ｍ マシンツーマシン
ＭＥＰ メッセージ交換パターン
ＯＷＬ−Ｓ ウェブサービスのためのウェブオントロジー言語
ＲＤ リソースディレクトリ
ＲＥＳＴ 表象状態転送
ＲＯＡ リソース指向アーキテクチャ
ＲＰＣ 遠隔プロシージャコール
ＲＳＤＬ ＲＥＳＴｆｕｌサービス記述言語
ＳＯＡ サービス指向アーキテクチャ
ＳＯＡＰ 単純オブジェクトアクセスプロトコル
ＳＲＩ サービスレジストリインフラストラクチャ
ＵＤＤＩ ユニバーサル記述、発見、および統合
ＷＡＤＬ ウェブアプリケーション記述言語
ＷＳ ウェブサービス
ＷＳＤＬ ウェブサービス記述言語
ＷＳＤＬ−Ｇ 類似サービスのグループのためのＷＳＤＬファイル
ＷＳＤＬ−Ｉ 個々のサービスのためのＷＳＤＬファイル
Ｗ３Ｃ ワールドワイドウェブコンソーシアム
ＸＭＬ 拡張マークアップ言語
ＸＳＤ ＸＭＬスキーマ定義

【0199】

主題は、構造特徴および／または方法論的アクションに特有の言語で説明されたが、添付の請求項に定義された主題は、必ずしも、前述の具体的特徴またはアクションに限定されないことを理解されたい。むしろ、前述の具体的特徴およびアクションは、請求項を実装する例示的形態として開示される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26A】

【図26B】

【図26C】

【図26D】