JP6511583B2 - サービス要素 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２００，３１６号（２０１５年８月３日出願、名称「Ｓｅｒｖｉｃｅ Ｅｌｅｍｅｎｔｓ」）の利益を主張し、上記出願の開示は、参照により本明細書に引用される。

（ＩｏＴサービス）
モノのインターネット（ＩｏＴ）は、数十億ものデバイスが情報を感知、通信、および共有し、全てがパブリックまたはプライベートネットワークを経由して相互接続される世界である。これらの相互接続されたデバイスは、定期的に収集され、分析され、アクションを開始するために使用されるデータを有し、豊富なサービスを提供する。

図１は、ＩｏＴシステム内のデバイス、ゲートウェイ、ルータ、およびサーバ、ならびにアプリケーションおよびユーザの展開を図示する。本明細書では、ユーザ、クライアント、およびアプリケーションという用語は、同義的に使用され、サービスを要求するエンティティを指す。クライアントは、アプリケーション（例えば、ＡＥ）のフォーマットであることができる。アプリケーションを電話にインストールし、次いで、サービスにアクセスすることができる。デバイスアプリケーションドメイン１０１内のデバイスは、データを感知および収集し、データは、デバイス自体またはアクセスネットワーク内の接続されたゲートウェイのみならず、インターネット、オペレータネットワーク、またはクラウド内のサーバに記憶され、サービスをネットワークアプリケーションドメイン１０５内のアプリケーションまたはユーザに提供し得る。

（ｏｎｅＭ２Ｍサービス層）
開発中のｏｎｅＭ２Ｍ規格（参照することによってその全体として組み込まれるｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１）は、「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層（ＳＬ）を定義する。ＳＬは、ｅ−ヘルス、フリート管理、およびスマートホーム等の異なる「バーティカル」マシンツーマシン（Ｍ２Ｍ）システムおよびアプリケーションによって利用され得る「ホリゾンタル」サービスを提供する。図２に示されるように、ＣＳＥ１１０は、複数の参照点をサポートする。Ｍｃａ参照点１１１は、アプリケーションエンティティ（ＡＥ）１１２とインターフェースをとる。Ｍｃｃ参照点（図示せず）は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点１１４は、異なるサービスプロバイダドメイン内の別のＣＳＥ１１６とインターフェースをとる。Ｍｃｎ参照点１１７は、下層ネットワークサービスエンティティ（ＮＳＥ）１１８とインターフェースをとる。ＮＳＥ１１８は、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。

ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）を有効にする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのＡＥを含むノードである。物理的マッピングの例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理的マッピングの例は、制約付きＭ２Ｍデバイス内に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＭＮのための物理的マッピングの例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。ＩＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＩＮのための物理的マッピングの例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。ｏｎｅＭ２Ｍエンティティを含まないノードである非ｏｎｅＭ２Ｍノード（ＡＥまたはＣＳＥのいずれでもない）も存在し得る。そのようなノードは、管理を含むインターワーキング目的のためにｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。

（ｏｎｅＭ２Ｍにおけるリソース構造）
ＡＥ、ＣＳＥ、データ等のｏｎｅＭ２Ｍシステム内のエンティティ（参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１）は、リソースとして表される。リソース構造は、そのようなリソースの表現として規定される。そのようなリソースは、一意にアドレス可能である。

リソースは、図３に示され、以下により詳細に説明されるように、テーブル表記を介して規定される。リソース（例えば、リソース１２１）は、ＣＳＥ１１０との関連付けで規定される。リソースは、ｏｎｅＭ２Ｍシステム内のコンポーネントおよび要素のＣＳＥ１１０における表現である。他のＣＳＥ、ＡＥ、センサを表すアプリケーションデータ、コマンド等は、そのリソース表現を用いてＣＳＥ１１０に把握される。リソース１２１は、ｏｎｅＭ２Ｍアーキテクチャでは、一意にアドレス可能なエンティティとして説明され得る。リソース１２１は、子リソース（例えば、子リソース１２３）と、属性（例えば、属性１２２）とを含み得る。子リソース１２３は、その親リソースである別のリソース（リソース１２１）のサブリソースとして定義され得る。親リソース（リソース１２１）は、子リソースへの参照を含む。属性１２２は、リソース自体に関する情報を記憶する。

グラフィカル表現が、属性および子リソースを表すために使用される。正方形ボックスは、リソース（例えば、リソース１２１および子リソース１２３）のために使用され、丸角を伴う正方形ボックスは、属性（例えば、属性１２２）のために使用される。＜ｒｅｓｏｕｒｃｅＴｙｐｅ＞内の属性は、図３に示されるようなものであり得る。アナウンス可能＜ｒｅｓｏｕｒｃｅＴｙｐｅ＞リソースのための属性テーブルは、その＜ｒｅｓｏｕｒｃｅＴｙｐｅ＞に対してアナウンスされるべき属性を示す「＜ｒｅｓｏｕｒｃｅＴｙｐｅＡｎｎｃ＞のための属性」と題された追加の列を含む。

属性のためのアクセスモードは、読み取り／書き込み（ＲＷ）、読み取り専用（ＲＯ）、および一度だけ書き込み（ＷＯ）等の値をとることができる。ＲＷに関して、属性の値は、発信側からの情報（すなわち、Ｃｏｎｔｅｎｔパラメータ）に基づいて、リソースが作成または更新されるときに設定される。そのような属性は、作成／更新／読み出し／削除／通知動作を可能にされる。ＲＯに対して、属性の値は、ホストするＣＳＥによって内部で設定される。そのような属性は、読み出し動作のみ可能にされる。ＷＯに関して、属性の値は、発信側からの情報（すなわち、Ｃｏｎｔｅｎｔパラメータ）に基づいて、リソースが作成されるときに設定される。そのような属性は、作成後の読み出し動作を可能にされる。

多重度は、子リソースおよび属性の両方のために、異なる関連付けられた意味を伴う値を有することができる。「０」の値は、子リソース／属性が存在しないことを示す。「１」の値は、子リソース／属性が存在することを示す。「０．．１」の値は、子リソース／属性が存在しない可能性があることを示す。存在する場合、１つのみのインスタンスを有し得る。「０．．ｎ」の値は、子リソースが存在しない可能性があることを示す。存在する場合、複数のインスタンスが、サポートされる。「１．．ｎ」の値は、子リソースが常時存在することを示す。これは、少なくとも１つのインスタンスを有し、複数のインスタンスを有することもできる。（Ｌ）で後固定された属性多重度は、それが値のリストであることを示す。

属性テーブル内の＜ｒｅｓｏｕｒｃｅＴｙｐｅＡｎｎｃ＞の属性は、以下の値の組を有することができる。
・ ＭＡ（アナウンスが必須である）：オリジナルリソース内の属性は、アナウンスされるリソースにアナウンスされる。そのようなアナウンスされる属性のコンテンツは、オリジナル属性のコンテンツと同一である。
・ ＯＡ（アナウンスが随意である）：オリジナルリソース内の属性は、オリジナルリソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性のコンテンツに応じて、アナウンスされるリソースにアナウンスされ得る。そのようなアナウンスされる属性のコンテンツは、オリジナル属性のコンテンツと同一である。
・ ＮＡ（アナウンスされない）：オリジナル属性は、アナウンスされるリソースにアナウンスされない。

（ｏｎｅＭ２Ｍサービスアーキテクチャ）
ｏｎｅＭ２Ｍ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ，ＴＳ−０００７ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．７．０（参照することによってその全体として組み込まれる）に説明されるＭ２Ｍサービスアーキテクチャは、Ｍ２ＭアプリケーションおよびＭ２Ｍサービスプロバイダに提供されるＭ２Ｍサービスを規定することによって、ｏｎｅＭ２Ｍ機能アーキテクチャを拡張させる。図２に示されるように、サービスエクスポージャコンポーネント１１３、ネットワークサービス利用コンポーネント１１５、および遠隔サービスエクスポージャコンポーネント１１９等の複数のコンポーネントが存在し得る。サービスエクスポージャコンポーネント１１３は、サービスをＡＥにエクスポーズする。ネットワークサービス利用コンポーネント１１５は、ＮＳＥ１１８からのサービスを消費する。遠隔サービスエクスポージャ１１６は、異なるＭ２Ｍ環境からのサービスを接続する。

サービス、すなわち、サービス層に対するサービス要素概念が本明細書に開示される。サービス／サービス要素は、サービス層においてリソースとして管理されることができる。

ＩｏＴサービスは、複数のサービス要素を有し得る。各サービス要素は、複数のデバイスまたは仮想デバイス（サービス要素ホスト）によって提供され得る。現在、サービス層は、複数のサービス要素から成るサービスをサポートする機能性を欠いている。

開示されるのは、サービス、サービス要素、各サービスホストからの報告／更新を処理する方法である。サービス層は、各利用可能なサービスのために、サービス、サービス要素、およびサービス要素ホスト記録を構築ならびに維持する能力を有するであろう。本明細書に開示されるのは、例として、ｏｎｅＭ２Ｍにおいて複数のサービス要素を伴うサービスをサポートするためのリソースの使用である。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
第１のサービス要素のための識別子を備えているメッセージを受信することと、
前記第１のサービス要素のための前記識別子に基づいて記録を生成することであって、前記記録は、前記第１のサービス要素に基づく第１のサービスを備えている、ことと、
前記サービスを備えている前記記録をパブリッシュすることと
を含む動作を前記プロセッサに達成させる、装置。
（項目２）
前記メッセージは、サービスの識別子を備えている、項目１に記載の装置。
（項目３）
前記メッセージは、サービスホストからであることを示す、項目１に記載の装置。
（項目４）
前記メッセージは、サービスが構成されているサービス要素の数を備えている、項目１に記載の装置。
（項目５）
前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、項目１に記載の装置。
（項目６）
前記メッセージは、前記第１のサービスのための前記第１のサービス要素を処理する順番のインジケータを備えている、項目１に記載の装置。
（項目７）
前記第１のサービス要素は、温度データである、項目１に記載の装置。
（項目８）
システムであって、前記システムは、
ディスプレイと、
前記ディスプレイと通信可能に接続されているデバイスと
を備え、
前記デバイスは、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、プロセッサによって実行されると、
第１のサービス要素のための識別子を備えているメッセージを受信することと、
前記第１のサービス要素のための前記識別子に基づいて記録を生成することであって、前記記録は、前記第１のサービス要素に基づく第１のサービスを備えている、ことと、
前記サービスを備えている前記記録を前記ディスプレイにパブリッシュすることと
を含む動作を前記プロセッサに達成させる、システム。
（項目９）
前記メッセージは、サービスの識別子を備えている、項目８に記載のシステム。
（項目１０）
前記メッセージは、サービスホストからであることを示す、項目８に記載のシステム。
（項目１１）
前記メッセージは、サービスが構成されているサービス要素の数を備えている、項目８に記載のシステム。
（項目１２）
前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、項目８に記載のシステム。
（項目１３）
前記メッセージは、前記第１のサービスのための前記第１のサービス要素を処理する順番のインジケータを備えている、項目８に記載のシステム。
（項目１４）
さらなる動作が、地理的エリアのグラフィカル表現を提供することを含み、前記グラフィカル表現は、前記第１のサービス要素の場所を示すインジケータを備えている、項目８に記載のシステム。
（項目１５）
さらなる動作が、グラフィカル表現を提供することを含み、前記グラフィカル表現は、前記記録に対する更新の確認を示すインジケータを備えている、項目８に記載のシステム。
（項目１６）
方法であって、前記方法は、
第１のサービス要素のための識別子を備えているメッセージを受信することと、
前記第１のサービス要素のための識別子に基づいて記録を生成することであって、前記記録は、前記第１のサービス要素に基づく第１のサービスを備えている、ことと、
前記サービスを備えている記録をパブリッシュすることと
を含む、方法。
（項目１７）
前記メッセージは、サービスの識別子を備えている、項目１６に記載の方法。
（項目１８）
前記メッセージは、サービスホストからであることを示す、項目１６に記載の方法。
（項目１９）
前記メッセージは、サービスが構成されているサービス要素の数を備えている、項目１６に記載の方法。
（項目２０）
前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、項目１６に記載の方法。

添付の図面と併せて一例として挙げられる以下の説明から、より詳細に理解され得る。
図１は、ＩｏＴシステム内のデバイス、ゲートウェイ、ルータおよびサーバ、ならびにアプリケーションおよびユーザの例示的展開を図示する。 図２は、例示的ｏｎｅＭ２Ｍサービスアーキテクチャを図示する。 図３は、例示的＜ｒｅｓｏｕｒｃｅＴｙｐｅ＞表現慣例を図示する。 図４は、サービス要素の使用を含む天候推測サービスのための例示的ユースケースを図示する。 図５は、サービス、サービス要素、およびホスト報告（以降、Ｓ−ＳＥａＨ報告）に関連付けられた例示的メッセージフローを図示する。 図６は、Ｓ−ＳＥａＨ更新メッセージに関連付けられた例示的メッセージフローを図示する。 図７は、サービス削除の例示的メッセージフローを図示する。 図８は、＜ｓｅｒｖｉｃｅ＞の例示的リソース構造を図示する。 図９は、＜ｓｅｒｖｉｃｅＥｌｅｍｅｎｔ＞の例示的リソース構造を図示する。 図１０は、ｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲＯＡ）内の例示的Ｓ−ＳＥａＨ報告を図示する。 図１１は、サービスおよびサービス要素リソースの例示的メッセージフロー作成を図示する。 図１２は、例示的ｏｎｅＭ２Ｍメッセージルーティングサービスコンポーネントを図示する。 図１３は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。 図１４Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１４Ｂは、図１４Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る例示的アーキテクチャの系統図である。 図１４Ｃは、図１４Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１４Ｄは、図１４Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

本明細書に開示されるのは、サービスを提供するための１つ以上のサービス要素の使用であり、それは、モノのインターネット（ＩｏＴ）のために使用され得る。各サービス要素は、複数のデバイスまたは仮想デバイス（サービス要素ホスト）によって提供され得る。本明細書により詳細に議論されるのは、サービス、サービスホスト、サービス要素、およびサービス要素ホスト等のサービス層に関連付けられた概念である。サービスは、クライアントにとって関心があるアクション、機能、またはデータの組と考えられ得、それらは、クライアントの入力に基づいて、結果および成果物の組を提供するために導入される。サービスホストは、サービスをアナウンスし、クライアントがサービスにアクセスするためのインターフェースを提供し得るエンティティである。サービスホストは、サービス要素から全体的サービスを形成し、それをサービス要求の発信側に配信し得る。サービス要素は、個々のコンポーネントであり、その個々のコンポーネントでサービスが構成されると考えられ得る。サービス要素は、通常、サービスを提供するために使用されるデータ（例えば、物理的世界から感知されるデータ）である。例えば、サービス要素は、温度または血糖値データであり得る。サービス要素は、特定のデバイス（例えば、温度計からの温度）の一次機能に対応し得るか、または複数の機能を伴うデバイス（例えば、モバイルデバイス）によって生成され得る。モバイルデバイスは、１つのセンサまたはセンサの組み合わせを用いて、とりわけ、光、運動、向き、またはタッチを感知し得る。最後に、サービス要素ホストは、サービス要素の物理的ホストとして定義され得る。１つのサービス要素ホスト上に位置する、複数かつ異なるサービス要素（例えば、温度または湿度）が存在し得る。例えば、天候サービスは、そのサービス要素のうちの１つとして温度を含む。したがって、温度センサノードは、サービス要素ホストとなるであろう。

図４は、サービス要素の使用を含む、天候推測サービスのためのユースケースを図示する。図４では、近隣１３０は、サービス要素（例えば、温度、湿度、およびＣＯ_２）と、温度センサ１３１、湿度センサ１３２、およびＣＯ_２センサ１３４等の対応するサービス要素ホストとを含む。天候推測サービスホスト１３３は、種々のデバイス（例えば、それらのサービス要素ホスト）から収集されるデータに基づいて、推測を生成し、サービスをその他に提供することができる。

例えば、図４を参照すると、推測は、近隣１３０が晴天であるかどうかであり得、それは、近隣１３０内に展開される種々のセンサデバイスによって収集される温度、湿度、およびＣＯ_２（例えば、空気汚染）データに基づき得る。図４に示されるように、種々のセンサデバイスは、パラメータ、例えば、温度、湿度、およびＣＯ_２の各々を感知するために近隣１３０に展開される。この特定の天候推測サービスは、サービスホストであるゲートウェイ１３３を有する。天候推測サービスは、３つのタイプのサービス要素を有し、それらの各々は、複数のホスト（例えば、種々のセンサ）を有する。

従来、複数のサービス要素から成るサービス（本明細書に定義されるような）をサポートするための機能性を欠いている。従来のサービス層（例えば、ｏｎｅＭ２Ｍサービス層）は、サービスのこの概念を有しておらず、それは、サービスが複数のサービス要素から成り得るシナリオをサポートしない。従来のサービス層は、定義された多くのリソースを有するが、これらは、物理的世界から収集されるデータを記憶のみする。クライアントは、そのデータを読み出し、それをローカルで処理することが可能となるであろう。加えて、従来のサービス層は、複数のサービス要素から成り得るサービスの情報を処理および維持する方法を提供しない。そのような方法がないと、サービスは、サービス層において発見または使用されることができない。

本明細書に議論されるようなサービスは、サービス要素によって集められるデータに基づいて情報を決定する（それは、従来のサービス層で行われるように、データを記憶するだけではない）。本明細書に開示されるサービスは、物理的世界を感知することによって提供されるデータを使用し得る。この新しいサービスは、サービス層によって提供されることができ、サービスがクライアントによって発見および使用されることを可能にする。本明細書に開示されるサービスは、例えば、図４を参照すると、晴天であるかどうか、または近隣１３０に関して晴天であるかどうかを推測し得る。別の例は、血圧データに関連付けられる。ある人が健康であるかどうか、または任意の薬剤が必要とされるかどうかを決定するサービスが提供され得る。

以下に開示されるのは、サービス層が、提案される概念のために、ｏｎｅＭ２Ｍを使用して実装されるｏｎｅＭ２Ｍ例に加え、複数のサービス要素を伴うサービスをサポートするための能力を提供する方法である。図５−図７および図１０−図１１に図示されるステップを行うエンティティは、図１４Ｃまたは図１４Ｄに図示されるもの等のデバイス、サーバ、またはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図５−図７および図１０−図１１に図示される方法は、図１４Ｃまたは図１４Ｄに図示されるデバイスまたはコンピューティングシステム等のコンピューティングデバイスのメモリ内に記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図５−図７および図１０−図１１に図示されるステップを行う。Ｍ２Ｍデバイスの相互作用に関して以下にさらに詳細を伴う例では、図５のサービスホスト１４１は、図１４ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る一方、図５のサービス層１４２は、図１４ＡのＭ２Ｍデバイス１４、１８、または２２上に常駐し得る。

図５は、サービス、サービス要素、およびホスト報告（以降、Ｓ−ＳＥａＨ報告）に関連付けられた例示的メッセージフローを図示する。サービス層１４２は、そのようなＳ−ＳＥａＨ報告の入力をとり、各サービスのためのサービス、サービス要素、およびサービス要素ホスト記録を構築する。本明細書に議論されるように、サービスは、１つ以上のサービス要素から成る。各サービスおよび各サービス要素は、それぞれ、ｓｅｒｖｉｃｅＩＤまたはｅｌｅｍｅｎｔＩＤを割り当てられ得る。

図５を参照すると、ステップ１４４では、サービス層１４２は、サービスホスト１４１からであり得るＳ−ＳＥａＨ報告メッセージを受信する。表１は、特に、新しいサービスが利用可能であるとき、Ｓ−ＳＥａＨ報告メッセージ内に含まれ得るものの例を提供する。

Ｓ−ＳＥａＨ報告メッセージは、とりわけ、ｓｅｒｖｉｃｅＩＤ、ｎｕｍＯｆＥｌｅｍｅｎｔ、ｅｌｅｍｅｎｔＩＤ、ｎｕｍＯｆＥｌｅｍｅｎｔＨｏｓｔ、ｌｉｓｔＯｆＥｌｅｍｅｎｔＨｏｓｔ、およびｓｅｒｖｉｃｅＥｌｅｍｅｎｔＯｒｄｅｒを含み得る。ｓｅｒｖｉｃｅＩＤは、サービスを表し、それを区別し得る識別子である。ｓｅｒｖｉｃｅＩＤは、各サービスが一意の識別子を有するように、サービスディレクトリ等の中央点によって割り当てられ得る。例として、ｓｅｒｖｉｃｅＩＤは、サービスの説明だけではなく、それをその他から区別するか、または、それがＵＲＩ等であり得るいくつかの標識を含み得る。ｎｕｍＯｆＥｌｅｍｅｎｔは、サービスが構成されているサービス要素の数を示す。ｎｕｍＯｆＥｌｅｍｅｎｔフィールドの後、示されるように、その識別子、要素ホストの数、および対応するホスト識別子を伴うサービス要素が続き得る。ｎｕｍＯｆＥｌｅｍｅｎｔフィールドは、ステップ１４４のＳ−ＳＥａＨ報告メッセージ内に含まれるｅｌｅｍｅｎｔＩＤの数から得られ得る。

ｅｌｅｍｅｎｔＩＤは、このサービス内のサービス要素を表し、それを区別し得る識別子である。ｅｌｅｍｅｎｔＩＤは、ｓｅｒｖｉｃｅＩＤから拡張され得る。表２を参照すると、サービスは、３つのサービス要素を有するＤｅｄｕｃｅＳｅｒｖｉｃｅ１のｓｅｒｖｉｃｅＩＤを有する。ｅｌｅｍｅｎｔＩＤは、ｓｅｒｖｉｃｅＩＤから拡張され、それらは、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１．ｔｅｍｐｅｒａｔｕｒｅ、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１．ｈｕｍｉｄｉｔｙ、およびＤｅｄｕｃｅＳｅｒｖｉｃｅ１．ａｉｒである。ｎｕｍＯｆＥｌｅｍｅｎｔＨｏｓｔは、各サービス要素のための要素ホストの数を示す。ｎｕｍＯｆＥｌｅｍｅｎｔＨｏｓｔフィールドは、ｌｉｓｔＯｆＥｌｅｍｅｎｔＨｏｓｔフィールドを検討することによって推測され得る。

ｌｉｓｔＯｆＥｌｅｍｅｎｔＨｏｓｔは、各サービス要素のためのサービス要素ホストのリストまたは他のインジケータを含む。ｎｕｍＯｆＥｌｅｍｅｎｔ後、一例では、ｅｌｅｍｅｎｔＩＤ、ｎｕｍＯｆＥｌｅｍｅｎｔＨｏｓｔ、ｌｉｓｔＯｆＥｌｅｍｅｎｔＨｏｓｔの複数の組み合わせが続き得る。サービス要素ホストは、サービスホストに登録している、またはサービスホストによって発見されたサービス要素ホストによって把握され、サービスホストに対して更新される。ｓｅｒｖｉｃｅＥｌｅｍｅｎｔＯｒｄｅｒは、サービスを要求することにおいて、サービス要素の順番の要因（例えば、インジケータ）を考慮する。言い換えると、サービスのサービス要素は、完全なサービスを得るために、クライアントによって受信されるべき所定の順序を有し得る。そのような順序要件がない場合、このフィールドは、Ｓ−ＳＥａＨ報告メッセージから省略され、そうでなければ、Ｓ−ＳＥａＨ報告内に示され得る。他のフィールドと同様に、ｓｅｒｖｉｃｅＥｌｅｍｅｎｔＯｒｄｅｒは、クライアントに読み出されるか、または提供され得る。

表２は、メッセージから導出され得る例示的Ｓ−ＳＥａＨ記録を例証する。それは、Ｓ−ＳＥａＨ記録または報告メッセージに関してディスプレイインターフェース（例えば、ディスプレイ／タッチパッド４２）上に表示され得るものの例でもあり得る。ｓｅｒｖｉｃｅＥｌｅｍｅｎｔＯｒｄｅｒは、この例では、必要とされないので、表２に示されない。サービス、サービス要素、およびサービス要素ホストのために、表２のこの記録内および全体に含まれる識別子は、例証目的のためのものであり、他の可能な形態、例えば、ＩＰアドレス、ＭＳＩＳＤＮ、またはＩＭＳＩであり得ることを理解されたい。

図５を継続して参照すると、ステップ１４５では、サービス層１４２は、表２に示されるものに類似し得るＳ−ＳＥａＨ記録を生成する。表２のＳ−ＳＥａＨ記録は、サービスホスト１４１からステップ１４４において提供されるメッセージ等のＳ−ＳＥａＨ報告メッセージに基づく。サービス層１４２は、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１を適切に共有またはパブリッシュし得る。したがって、サービス層１４２は、表１の情報を維持するための属性を有する、サービスリソースを有し、それをパブリッシュし得る。サービス層１４２は（いくつかの例では）、単に、サービス要素等を追加または除去し得る、更新情報を送信し得る。ステップ１４６では、サービス層１４２は、メッセージをサービスホスト１４２に送信する。ステップ１４６のメッセージは、記録がサービスのために成功裏に作成された（または不完全もしくは相反情報等の理由から不成功である）ことを示し得る。

サービス層１４２およびサービスホスト１４１に関するさらなる明確化のために、サービスホスト１４１が、サービス（例えば、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１）について主に把握している。したがって、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１を有するサービスホスト１４１は、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１をサービス層１４２にパブリッシュすることを欲し得る。サービス層１４２によって提供される機能性により、クライアントは、サービスホスト１４１のＤｅｄｕｃｅＳｅｒｖｉｃｅ１（および他のサービス）を発見し得る。サービス層１４１は、サービスホスト１４１によって提供されるサービスが、クライアントによって発見され、次いで、使用されることができるように、サービス（例えば、ＤｅｄｕｃｅＳｅｒｖｉｃｅ１）の情報を管理することができる。

以下に議論されるのは、サービス、サービス要素、およびサービス要素ホストの更新に関するシナリオである。一般的メッセージフローが、図６に提供され、さらなる詳細は、異なるシナリオに関して本明細書に提供される。ステップ１５１では、サービス層１４２は、Ｓ−ＳＥａＨ更新メッセージを受信する。ステップ１５２では、サービス層１４２は、ステップ１５１のＳ−ＳＥａＨ更新メッセージに示されるケースに基づいて、アクションを生成する。ステップ１５３では、サービス層１４２は、さらなる情報を要求すること、補正された情報を要求すること、成功を確認すること、失敗を通知すること等のメッセージを送信する。

ステップ１５１の更新メッセージは、サービスに関係し得る異なるタイプの更新を含み得る。以下に議論されるのは、いくつかの可能な更新である。ケースのために、更新メッセージは、それに関連付けられた対応するケース番号を有する。ケース１に対して、サービスＩＤ（ケース１）に対する更新が存在する。サービスの識別子は、サービス層１４２に登録された後に修正され得る。例えば、ｓｅｒｖｉｃｅＩＤの割り当て側は、ｓｅｒｖｉｃｅＩＤがもはや一意のではないことを検出したので、ｓｅｒｖｉｃｅＩＤを変更するか、またはｓｅｒｖｉｃｅＩＤ内に含まれるコンテキスト情報を更新することを決定し得る。

概して図６に示されるメッセージフロー内のステップは、ケース１（サービスＩＤに対する更新）に関して以下により詳細に議論される。ステップ１５１では、サービス層１４２は、表３に示されるようなＳ−ＳＥａＨ更新メッセージを受信する。表３は、ケース番号、古いｓｅｒｖｉｃｅＩＤ、および新しいｓｅｒｖｉｃｅＩＤ等のステップ１４２のメッセージのコンテンツの例を提供する。ステップ１５２では、サービス層１４２は、サービス記録が古いｓｅｒｖｉｃｅＩＤに一致することを見出し、新しいｓｅｒｖｉｃｅＩＤと置換する。サービス層１４２は、新しいｓｅｒｖｉｃｅＩＤが他の既存のサービスＩＤ間で一意であることを確実にする必要があり得る。ステップ１５３では、サービス層１４２は、成功もしくは不成功（例えば、古いｓｅｒｖｉｃｅＩＤに基づく記録が見出されない、または新しいｓｅｒｖｉｃｅＩＤが他の既存のもの間で一意ではない）、確認等を伴うメッセージを送信し得る。

ケース２に関して、いくつかのサービス要素（ケース２Ｉ、２Ｄ）に対する更新が存在し得る。サービス要素の数が増やされる場合（ケース２Ｉ）、新しいサービス要素およびそのサービス要素ホストが、更新メッセージ内に含まれるであろう。例えば、図４のユースケースに関して、追加の温度センサを展開する決定が行われ得る。次いで、サービス要素ホスト番号が、増やされる。サービス要素の数が減らされる場合（ケース２Ｄ）、除去されるべきサービス要素の識別子が、更新メッセージ内に含まれるであろう。例えば、温度センサのいくつかが、バッテリが枯渇したため、動作を停止させ得る。次いで、サービス要素ホスト番号の数が、減らされる。

概して図６に示されるメッセージフロー内のステップは、ケース２Ｉ（サービス要素の数に対する更新）に関して以下により詳細に議論される。ステップ１５１では、サービス層１４２は、表４に示されるように、Ｓ−ＳＥａＨ更新メッセージを受信し得る。表４は、ケース番号、更新されるべきｓｅｒｖｉｃｅＩＤ、新しいサービス要素の数、新しいｅｌｅｍｅｎｔＩＤおよびその対応するサービス要素ホストの数、ならびにサービス要素ホストのリストを含む例示的テーブルである。２つ以上のサービス要素が、ステップ１５１のメッセージに基づいて追加され得ることを理解されたい。ステップ１５２では、サービス層１４２は、ｓｅｒｖｉｃｅＩＤに一致するサービス記録を見出す。サービス層１４２は、ｎｕｍＯｆＥｌｅｍｅｎｔを新しいものに変更し、新しいサービス要素および対応するサービス要素ホストの数、ならびにサービス要素ホストのリストを記録に追加する。ステップ１５３では、サービス層１４２は、成功または不成功確認（例えば、とりわけ、ｓｅｒｖｉｃｅＩＤに基づく記録が見出されない、または新しいサービス要素ホストに到達不能である）に関連付けられた情報を含み得るメッセージを送信する。

概して図６に示されるメッセージフロー内のステップは、ケース２Ｄに関して以下により詳細に議論される。ステップ１５１では、サービス層１４２は、表５に示されるようなＳ−ＳＥａＨ更新メッセージを受信し得る。表５は、ケース番号、更新されるべきｓｅｒｖｉｃｅＩＤ、新しいサービス要素の数、および除去されるべき既存のサービス要素の識別子を含む例示的テーブルである。ステップ１５２では、サービス層１４２は、サービス記録がｓｅｒｖｉｃｅＩＤに一致することを決定する。サービス層１４２は、ｎｕｍＯｆＥｌｅｍｅｎｔを新しいものに変更し、削除されたサービス要素および対応するサービス要素ホストのリストを記録から除去する。ステップ１５３では、サービス層１４２は、成功または不成功確認（例えば、ｓｅｒｖｉｃｅＩＤに基づく記録が見出されない、または除去されるべきｅｌｅｍｅｎｔＩＤがサービス内に見出されない）に関連付けられた情報を含み得るメッセージを送信する。

ケース３に関して、既存のサービス要素のサービス要素ホストに対する更新が存在し得る（ケース３）。概して図６に示されるメッセージフロー内のステップは、ケース３（既存のサービス要素のサービス要素ホストに対する更新）に関して以下により詳細に議論される。ステップ１５１では、サービス層１４２は、表６に示されるようなＳ−ＳＥａＨ更新メッセージを受信し得る。サービスホスト１４１は、ステップ１５１における１つの集約されたメッセージ内で複数のサービスのためのサービス要素ホストを更新し得ることを理解されたい。表６は、ケース番号、更新されるべきｓｅｒｖｉｃｅＩＤ、更新されるべき既存のサービス要素の識別子、新しいサービス要素ホストの数、および新しいサービス要素ホストのリストを含む例示的テーブルである。ステップ１５２では、サービス層１４２は、サービス記録がｓｅｒｖｉｃｅＩＤに一致することを決定する。サービス層１４２は、メッセージに示されるサービス要素ホストを更新する。ステップ１５３では、サービス層１４２は、成功または不成功確認（例えば、ｓｅｒｖｉｃｅＩＤに基づく記録が見出されない、または更新されるべきｅｌｅｍｅｎｔＩＤがサービス内に見出されない）に関連付けられた情報を含み得るメッセージを送信する。

図７は、サービス削除のための例示的メッセージフローを図示する。ステップ１５５では、サービス層１４２は、Ｓ−ＳＥａＨ情報を削除するためのＳ−ＳＥａＨ削除メッセージを受信する。削除メッセージは、ｓｅｒｖｉｃｅＩＤを含み得る。ステップ１５６では、サービス層１４２は、ｓｅｒｖｉｃｅＩＤに対応する記録を見つける。ｓｅｒｖｉｃｅＩＤに対応する記録が見出されると、サービスの記録ならびに関連付けられたサービス要素情報は、削除される。ステップ１５７では、サービス層１４２は、成功または不成功確認に関連付けられた情報を含み得る、メッセージを送信する。

以下に議論されるのは、ｏｎｅＭ２Ｍシナリオに関するサービスおよびサービス要素のさらなる詳細である。図８は、本明細書に開示されるサービスの例示的リソースツリー構造を図示する。＜ｓｅｒｖｉｃｅ＞リソース（例えば、＜ｓｅｒｖｉｃｅ＞１６１）は、＜ＣＳＥＢａｓｅ＞または＜遠隔ＣＳＥ＞の子リソースであり得、それは、サービスの情報を、それぞれ、ローカルＣＳＥおよび他の遠隔ＣＳＥ上に記憶する。表７および表８は、＜ｓｅｒｖｉｃｅ＞リソースの子リソースならびに属性の例を示す。それらの共通属性は、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１に見出され得る。

＜ｓｅｒｖｉｃｅＥｌｅｍｅｎｔ＞のリソースツリー構造は、図９に示される。表９および表１０は、＜ｓｅｒｖｉｃｅＥｌｅｍｅｎｔ＞リソースの子リソースならびに属性の例を示す。それらの共通属性は、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１に見出され得る。

図１０は、ｏｎｅＭ２Ｍ ＲｏＡアーキテクチャにおいて具現化され得る例示的サービス要素およびホスト報告を図示する。この例では、サービスホスト１４１は、ＭＮ−ＣＳＥ１７６であり、それは、ＩＮ−ＣＳＥ１７７におけるサービス層にＳ−ＳＥａＨ報告を送信する。図１１は、そのホストされるサービスならびに関連付けられたサービス要素をＩＮ−ＣＳＥに報告するＭＮ−ＣＳＥの例示的メッセージフローを図示する。ステップ１８１では、ＩＮ−ＣＳＥ１７７は、＜ｓｅｒｖｉｃｅ＞、＜ｓｅｒｖｉｃｅ ｅｌｅｍｅｎｔ＞作成メッセージを受信する。ステップ１８１のメッセージは、表１の適切な情報を提供する。ステップ１８２では、ＩＮ−ＣＳＥ１７７は、ステップ１８１のメッセージからの情報に基づいて、リソースを生成する。ステップ１８３では、ＩＮ−ＣＳＥ１７７は、確認等であり得る作成応答を含むメッセージを送信し得る。

図１２は、サービスリポジトリコンポーネント１８５を伴う例示的ｏｎｅＭ２Ｍサービス指向アーキテクチャを図示する。サービスリポジトリコンポーネント１８５は、Ｍｓｃ参照点を介して報告されるローカルサービスコンポーネントと、Ｍｃｃ’参照点を介してそれ自体に報告される外部サービスコンポーネントとを維持する。維持は、作成、更新、削除、および読み出しを含む。

図１３は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース２０１（例えば、タッチスクリーンディスプレイ）は、表１から表６のパラメータ等のサービス要素に関連付けられたテキストをブロック２０２内に提供し得る。別の例では、本明細書で議論されるステップのいずれかの進捗度（例えば、送信されるメッセージまたはステップの成功）は、ブロック２０２に表示され得る。加えて、グラフィカル出力２０３が、ディスプレイインターフェース２０１上に表示され得る。グラフィカル出力２０３は、ホスト（サービス要素またはサービス）のトポロジ、本明細書で議論される任意の方法またはシステムの進捗度のグラフィカル出力等であり得る。

本明細書に現れる請求項の範囲、解釈、または用途をいかようにも過度に限定することなく、本明細書に開示される例のうちの１つ以上のものの技術的効果は、サービスが生成およびパブリッシュされる方法に調節を提供することである。サービス構成（および関連知能）は、サービス要素および関連付けられた構造の使用を含み得る。本明細書に開示される概念のうちの１つ以上のものの別の技術的効果は、従来の実装と比較して、サービス層が本明細書に議論されるようなサービス要素等をサポートする場合、サービス／サービス要素が、サービス層におけるリソースとして管理され得、これは、サービスを編成し、それと通信するとき、より効率的であり得ることである。

図１４Ａは、サービス要素に関連付けられた１つ以上の開示される概念が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。図１４Ａのサービス層２２は、サービス層１４２と類似様式であるが、本明細書により詳細に議論されるような観点で動作し得る。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

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

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

本明細書に議論されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能的層と考えられ得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはサービス能力層（ＳＣＬ）と称され得るサービス層によってサポートされる前述の能力または機能性の集合もしくはセットへのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得るセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（例えば、そのような機能エンティティ間の機能インターフェース）である。

図１４Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である（図１０または図５の１つ以上のコンポーネントを含み得る）。図１４Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、サービスホスト１３３、サービスホスト１４１、温度センサ１３１、ＣＯ_２センサ１３２、湿度センサ１３４、およびその他）は、サービスのサービス要素および関連付けられたメッセージングならびに構成のための開示されるシステムおよび方法を行う例示的実装であり得る。

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

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

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

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

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

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

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

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

伝送／受信要素３６は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。

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

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

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

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

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

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

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

図に例証されるように、本開示の主題（サービス要素）の好ましい方法、システム、または装置を説明する上で、明確にするために、特有の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」等は、同義的に使用され得る。

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

Claims (15)

1. サービス要素を管理するための装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   複数のサービス要素のうちの第１のサービス要素のための識別子を備えているメッセージを受信することであって、前記複数のサービス要素の各々は、第１のサービスを提供するために使用される個々のコンポーネントである、ことと
   前記第１のサービス要素のための前記識別子に基づいて記録を生成することであって、前記記録は、前記第１のサービス要素に対応するサービス要素ホストのリストを備えている、ことと、
   前記サービス要素ホストのリストを備えている前記記録をパブリッシュすることと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記メッセージは、前記第１のサービスの識別子を備えている、請求項１に記載の装置。
3. 前記メッセージは、サービスホストからであることを示す、請求項１に記載の装置。
4. 前記メッセージは、サービスが構成されているサービス要素の数を備えている、請求項１に記載の装置。
5. 前記メッセージは、前記複数のサービス要素の各サービス要素のための複数のサービス要素ホストのインジケータを備えている、請求項１に記載の装置。
6. 前記第１のサービス要素は、湿度データである、請求項１に記載の装置。
7. 前記第１のサービス要素は、温度データである、請求項１に記載の装置。
8. サービス要素を管理する方法であって、前記方法は、
   複数のサービス要素のうちの第１のサービス要素のための識別子を備えているメッセージを受信することであって、前記複数のサービス要素の各々は、第１のサービスを提供するために使用される個々のコンポーネントである、ことと
   前記第１のサービス要素のための前記識別子に基づいて記録を生成することであって、前記記録は、前記第１のサービス要素に対応するサービス要素ホストのリストを備えている、ことと、
   前記サービス要素ホストのリストを備えている前記記録をパブリッシュすることと
   を含む、方法。
9. 前記メッセージは、前記第１のサービスの識別子を備えている、請求項８に記載の方法。
10. 前記メッセージは、サービスホストからであることを示す、請求項８に記載の方法。
11. 前記メッセージは、サービスが構成されているサービス要素の数を備えている、請求項８に記載の方法。
12. 前記メッセージは、前記複数のサービス要素の各サービス要素のための複数のサービス要素ホストのインジケータを備えている、請求項８に記載の方法。
13. 前記第１のサービス要素は、湿度データである、請求項８に記載の方法。
14. 前記第１のサービス要素は、温度データである、請求項８に記載の方法。
15. コンピュータプログラムを記憶しているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、前記コンピュータプログラムは、前記データ処理ユニットによって起動されると、請求項８〜１４のいずれかに記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータ読み取り可能な記憶媒体。