JP2018523873A - サービス要素ホスト選択 - Google Patents

Abstract

モノのインターネットサービス等のサービスは、複数のサービス要素を有し得る。各サービス要素は、複数のデバイスまたは仮想デバイス（サービス要素ホスト）によって提供され得る。サービス／サービス要素は、サービス層のリソースとして管理されることができる。複数のサービス要素を伴うサービスが、サポートされる。クライアントからのＱｏＳ要件に基づいて、サービス要素ホスト選択は、必要コンテキスト情報を使用して、サービス要素ホストを選択する決定を行い得る。クライアントは、ＱｏＳ要件をサービスホストに送信することを選定し、サービスホストは、順に、それをサービス要素ホスト選択に転送し得る。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２００，６８１号（２０１５年８月４日出願、名称「ＳＥＲＶＩＣＥ ＥＬＥＭＥＮＴ ＨＯＳＴ ＳＥＬＥＣＴＩＯＮ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

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

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

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

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

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

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

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

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

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

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

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

開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）は、図４に図示されるように、共通サービスエンティティ（ＣＳＥ）と呼ばれるサービス層を定義する。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、ＣＳＥに、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスを提供する。ＣＳＥは、「発見」または「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図５は、ｏｎｅＭ２Ｍのための例示的ＣＳＦを図示する。

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

以下は、ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャに従う追加のコンテキストである。能力サービス機能（ＣＳＦ）は、「リソース」の組として表される。リソースは、ｏｎｅＭ２Ｍアーキテクチャ内の一意にアドレス可能なエンティティである。リソースは、作成、読み出し、更新、および削除（ＣＲＵＤ）等のＲＥＳＴｆｕｌ方法を介して操作および伝送され得る表現を有し、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースと、属性とを含み得る。子リソースは、親リソースと包含関係を有する、リソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親リソースの寿命によって限定される。各リソースは、リソースの情報を記憶する、「属性」の組をサポートし得る。

本明細書に開示されるのは、サービス要素ホスト選択サービス（ＳＥＨＳ）のための方法、システム、およびデバイスである。第１の例では、クライアントからのＱｏＳ要件に基づいて、ＳＥＨＳは、必要コンテキスト情報を使用して、サービス要素ホスト選択における決定を行い得る。クライアントは、ＱｏＳ要件をサービスホストに送信することを選定し得、これは、順に、それをＳＥＨＳに転送する。ＳＥＨＳは、サービス要求を同様に処理することができる。

別の例では、ＳＥＨＳは、クライアント不満足（例えば、パラメータの最小閾値を満たさない）等を含み得る、コンテキスト変更等のシナリオにおいてサービス要素ホストを再選択し得る。別の例では、ＳＥＨＳは、切り替えが必要とされるとき、サービス要素ホストの複数の候補を選択し得る。

別の例では、ＳＥＨＳは、クライアントのためのサービス要素ホスト選択におけるより正確な決定を行い得るように、クライアントから発信されたサービス要素読み出しの順番を考慮し得る。

とりわけ、本明細書に説明されるような方法、システム、および装置は、サービスホスト選択等のための手段を提供し得る。以下の例では、方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、サービスに対する要求とサービス品質の要件とを含むメッセージを受信することと、メッセージに基づいて、サービス要素ホストを決定することと、要求をサービス要素ホストに転送することとを行う手段を有する。メッセージは、サービスの識別子を含み得る。メッセージは、サービスホストからであることを示し得る。メッセージは、サービスが構成されているサービス要素の数を含み得る。メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを含み得る。メッセージは、第１のサービスのための第１のサービス要素を処理する順番のインジケータを含み得る。第１のサービス要素は、温度データであり得る。

本概要は、発明を実施するための形態において以下でさらに説明される簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

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

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

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

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

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

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

サービス要素（例えば、温度、湿度、およびＣＯ_２データ）を受信するクライアント（例えば、アプリケーション等）は、それらを異なる組み合わせのセンサデバイス（例えば、サービス要素ホスト）から受信し得、天候に関するユーザの快適性レベルおよび環境条件に関連付けられたそれら自身の定義（例えば、容認可能決定／推測を提供するために使用される１つ以上のサービス要素に関連付けられたデータの最小閾値）に基づいて、推測を行い得る。別の例では、サービスホスト（例えば、ゲートウェイ１３３）は、異なるセンサデバイスから受信されたサービス要素に基づいて、大域的快適性のレベルを決定し得る。大域的快適性のレベルは、例えば、そのサービスホストまたはサービスホストのグループによる全てまたは実質的に全てのサービスに関連付けられ得る。

クライアントは、図７に示されるように、ルータを通してネットワークに接続される異なる物理的場所からサービスを要求し得る。例では、クライアント（例えば、図７におけるクライアント１４１、１４２、１４３、または１４４）の各々は、サービスを受信するためのそれ自身のサービス品質（ＱｏＳ）要件を有し得る。ＱｏＳは、最短総距離、最短総応答時間等であり得る。図７では、サービスホスト１５５は、例として、ゲートウェイ上にあり得る。示されるように、このサービスのための３つのサービス要素、すなわち、以下のように、サービス要素Ａ、Ｂ、Ｃが存在する。
・ サービス要素Ａは、サービス要素ホスト１４６、１４７、および１４８を有する。
・ サービス要素Ｂは、サービス要素ホスト１５２および１５３を有する。
・ サービス要素Ｃは、サービス要素ホスト１４９、１５０、１５１、および１５４を有する。

クライアント１４１およびクライアント１４４が、最短総距離のＱｏＳを伴う要求を送信する場合、サービス要素ホスト１４６、１５２、および１５４がサービス要素Ａ、Ｂ、およびＣをクライアント１４１に提供することが最適である。クライアント１４４に関して、サービス要素ホスト１４７、１５３、および１４９がサービス要素Ａ、Ｂ、およびＣを提供することが最適である。別の例では、クライアント１５１およびクライアント１４９が、最短総応答時間のＱｏＳを伴う要求を送信する場合、サービス要素ホスト１４６、１５２、１４９がサービス要素Ａ、Ｂ、Ｃをクライアント１４２およびクライアント１４３に提供することが最適である（この例に対して、他のピアサービス要素ホストと比較して最短応答時間を有すると仮定して）。

サービス要求は、要求内のＱｏＳ要件を考慮して応答されることが重要であり得る。従来のシステムは、サービスが複数の／異なるサービス要素ホスト内にホストされる複数のサービス要素から成り得ることを理解しないこともあり、かつ関連コンテキスト情報も理解しないこともあるので、サービス要素を効率的に使用および選択することができない。従来のシステムは、本明細書に議論されるように、クライアントからのＱｏＳ要件を満たすための最良サービス要素ホストを見出すように良好にサポートされず、そのように動作しない。現在、本明細書に議論されるようなこれらの要因を考慮することができるサービス要素ホスト選択機能がない。

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

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

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

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

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

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

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

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

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

本明細書に開示されるのは、サービス要素ホスト選択サービス（ＳＥＨＳ）の機能性である。図９および図１０の各々は、ＳＥＨＳのための別個のシナリオを示す。第１のシナリオを要約すると、クライアントは、ＱｏＳベースのサービス要求をＳＥＨＳに送信し得る。ＳＥＨＳは、要求を処理し、クライアントのＱｏＳに基づいて適切なサービス要素ホストを選択し、サービス要素要求をサービス要素ホストにディスパッチする。第２のシナリオを要約すると、クライアントは、ＱｏＳベースのサービス要求を直接サービスホストに送信することができ、サービスホストは、順に、要求をＳＥＨＳに転送する。このシナリオは、リソース制約付きデバイス内に常駐する場合に発生し、リソース制約付きデバイスは、異なるサービス要素ホストからのサービス要素をつなぎ合わせ、全体的サービスを形成する能力を持たず、クライアントは、それを取り扱うサービスホストに頼る。同様に、ＳＥＨＳは、要求を処理し、クライアントのＱｏＳに基づいて適切なサービス要素ホストを選択し、サービス要素要求をサービス要素ホストにディスパッチする。両シナリオは、本明細書でより詳細に議論される。

より詳細には、第１のシナリオでは、図９に示されるように、ステップ１８１では、ＳＥＨＳ１７１は、サービス要求を受信し、要求は、クライアント１７０からであることを示し得る。ステップ１８２では、ＳＥＨＳ１７１は、サービス要素ホスト選択応答をクライアント１７０に送信し、応答は、クライアント１７０に全ての選択されたサービス要素ホストを知らせ得る。ＳＥＨＳ１７１内では、サービス要求に基づくＱｏＳの処理（ブロック１７６）、関連コンテキスト情報の収集／決定（ブロック１７７）、サービス要素ホストの選択／調節、および選択されたサービス要素ホストの各々へのサービス要求のディスパッチが行われ得る。ステップ１８３では、ＳＥＨＳ１７１は、サービス要素要求をサービス要素ホスト１７２に送信する。ステップ１８４では、クライアント１７０は、サービス要素応答を受信し、応答は、サービス要素ホスト１７２からであることを示す。すなわち、１８４における応答は、クライアント１７２が要求したものに対応するサービス結果またはコンテンツを含み得る（例えば、サービス要素ホストが温度センサノードである場合、温度値）。

第２のシナリオでは、図１０に示されるように、ステップ１９１では、サービスホスト１７３は、サービス要求を受信し、要求は、クライアント１７０からであることを示し得る。ステップ１９２では、サービスホスト１７３は、ステップ１９１の要求をＳＥＨＳ１７１に送信する。ステップ１９３では、サービスホスト１７３は、サービス要素ホスト選択応答を受信し、応答は、選択されたサービス要素ホストを含み、ＳＥＨＳ１７１からであることを示し得る。ＳＥＨＳ１７１内では、サービス要求に基づくＱｏＳの処理（ブロック１７６）、関連コンテキスト情報の収集／決定（ブロック１７７）、サービス要素ホストの選択／調節、および選択されたサービス要素ホストの各々へのサービス要求のディスパッチが行われ得る。ステップ１９４では、サービス要素ホスト１７２は、ＳＥＨＳ１７１からであることを示すサービス要素要求を受信する。ステップ１９５では、サービスホスト１７３は、サービス要素ホスト１７２からであることを示すサービス要素応答を受信する。すなわち、１９５における応答は、サービスホスト１７３が要求するものに対応するサービス結果またはコンテンツ（例えば、サービス要素ホストが温度センサノードである場合、温度値）を含み得る。ステップ１９６では、サービスホスト１７３は、サービス応答をクライアント１７０に送信する。すなわち、１９６における応答は、個々にまたは組み合わせられた／集約された全サービス要素からのサービス結果またはコンテンツを含み得る。

図９および図１０によって図示されるシナリオのいずにおいても、ＱｏＳ要件は、サービス要求内において随意であり得る。サービスホスト１７３またはＳＥＨＳ１７１は、要求されるサービスの特性または他の要因に基づいて、クライアント１７０のためのＱｏＳ要件を決定し得る。サービスホスト１７３は、ＱｏＳ要件をＳＥＨＳ１７１に提供し得るか、またはＱｏＳ要件は、ＳＥＨＳ１７１内にプロビジョニングされ得る。

両シナリオでは、ＳＥＨＳ１７１は、類似様式で動作し得る。ＳＥＨＳ１７１がサービス要求を受信すると、ブロック１７６の「Ｑｏｓベースのサービス要求の処理」は、要求メッセージを解析し（例えば、ステップ１８１またはステップ１９２）、適切なコンテキスト情報のために、ブロック１７７の「関連コンテキスト情報収集」から入力を受信し得る。ブロック１７８の「サービス要素ホストの選択または調節」は、要求メッセージおよび収集されるコンテキスト情報に基づいて、サービス要素ホスト１７２を選択または再選択することを担当する。サービス要素ホスト１７２が選択または再選択された後、ブロック１７９の「選択されたサービス要素ホストのそれぞれのサービス要求ディスパッチ」は、要求をディスパッチすることを担当する。

以下に議論されるのは、ＳＥＨＳ１７１のための相互作用のさらなる詳細である。以下は、ＳＥＨＳ１７１に関連付けられたメッセージ構造、メッセージコンテンツ、およびメッセージングフローの例である。クライアント１７０は、アタッチされたルータ、ゲートウェイ、基地局等（以降、プロキシルータまたはプロキシゲートウェイが提示の簡略化のために使用される）を通してアクセスを得ることによって、サービス要求を送信し得る（例えば、ステップ１８１）。ルータは、プロキシとしての役割を果たし、クライアントのためのサービス要求をＳＥＨＳ１７１またはサービスホスト１７３に送信し得る（ＳＥＨＳ１７１は、ルータをサービス要求の発信側と見なすことができる）。例では、ＳＥＨＳ１７１は、図１９に示されるように、ＣＳＥ内にＣＳＦとして常駐し得る。プロキシルータのアドレスの知識を有するＳＥＨＳ１７１は、ルータからサービス要素ホスト１７２までの距離等、コンテキスト情報をルータから読み出すことを補助し得る。この例に対して、ルータからサービス要素ホスト１７２までの距離は、比較を行うとき、クライアント１７０からサービス要素ホスト１７２までの距離に相当すると考えられ得る。例示的サービス要求メッセージ（例えば、ステップ１８１）が、表３に示される。

表３におけるクライアントのアドレスは、サービスを要求しているクライアント１７０のアドレスである。図９によって要約される第１のシナリオに対して、表３のプロキシのアドレスは、クライアント１７０をインターネットのようなネットワークに接続し得るクライアント１７０のプロキシゲートウェイ（例えば、図１１のプロキシゲートウェイ１６９）のアドレスである。プロキシゲートウェイ１６９のアドレスは、最初は、クライアント１７０に把握されていないこともある。プロキシゲートウェイ１６９は、それ自身のアドレスを追加することによって、クライアント１７０の要求メッセージを再編成し得る。プロキシゲートウェイ１６９は、要求メッセージを検査し、それ自身のアドレスを追加し得ると仮定される。第２のシナリオに対して、表３のプロキシのアドレスは、プロキシゲートウェイ１６９がサービスホスト１７３自体であるので、サービスホスト１７３によってリセットされ、それは、本明細書でより詳細に議論される。表３のｓｅｒｖｉｃｅＩＤは、クライアント１７０が要求しているサービスの識別子である。クライアント１７０がサービスを要求する前、サービスディレクトリからサービスを発見し得ることが想定され、サービスディレクトリは、例えば、ｏｎｅＭ２Ｍアーキテクチャ内のＣＳＥ内に常駐し、サービスのメタデータおよびセマンティクスを記憶し得る。表３のＱｏＳ要件は、クライアント１７０がサービスホスト１７３から望むＱｏＳである。用語「要件」が、使用されるが、本明細書では、ＱｏＳオプションは、優先順位が付けられ、条件および優先順位を考慮して、優先順位に基づいて実装され得ることが想定される。ＳＥＨＳ１７１は、それが解析および理解可能なＱｏＳ要件のリストを維持し得る。このリストは、クライアント１７０の要求に基づいて、知らされ（例えば、パターン決定される）、常に更新され得る。例は、最短総距離、デバイス間のケーブルの長さ、最小遅延、最短応答時間、信頼性、最短スリープ期間等を含み得る。クライアント１７０は、一緒に考慮され得る、複数のＱｏＳ要求を有し得る。以下では、最短総距離が、例証目的のために例として使用される。最短総距離は、概して、プロキシゲートウェイ１６９からサービス要素ホスト１７２までの距離の和としてこれらの例のために定義され得る。

図１１は、図９によって要約される第１のシナリオに基づくＳＥＨＳの例示的メッセージフローを図示する。ステップ２０１では、ＳＥＨＳ１７１は、表３に示されるようなＱｏＳ要件を伴うサービス要求を受信し得る。ステップ２０１のサービス要求は、プロキシゲートウェイ１７０からであることを示し得る。表２に示されるサービスを例として挙げると、クライアント１７０のアドレスは、クライアント１７０自体のアドレスであり、プロキシのアドレスは、クライアント１７０とアタッチされたルータのアドレスであり、ｓｅｒｖｉｃｅＩＤは、「ＤｅｄｕｃｅＳｅｒｖｉｃｅ１」に設定され、ＱｏＳ要件は、最短総距離に設定される。例として、ステップ２０１のサービス要求は、個々のサービス要素の各々に対するサブスクリプション要求であり得る。この例は、例証目的のために本明細書で使用されるであろう。

図１１を継続して参照すると、ステップ２０２では、ＳＥＨＳ１７１によってコンテキスト読み出しが行われる。ＳＥＨＳ１７１は、サービス要素ホストの選択を行うために、関連コンテキスト情報を読み出す。ＳＥＨＳ１７１は、コンテキスト情報をコンテキストプロバイダ１７４から読み出し得る。ＳＥＨＳ１７１は、表４に示されるようなコンテキスト要求メッセージを送信し得る。コンテキストプロバイダ１７４は、プロキシゲートウェイ１６９であり得る。例では、表４のコンテキストフィールドは、ＳＥＨＳ１７１が要求側（例えば、プロキシゲートウェイ１６９）からサービス要素ホスト１７２までの距離情報を要求することを示し得る。サービス要素ホスト１７２のリストは、表４のフィールド内に含まれる。例では、コンテンツプロバイダ１７４としてのプロキシゲートウェイ１６９は、デバイスの場所（例えば、ＧＰＳ）、プロキシゲートウェイ１６９のルーティングテーブル、およびｐｉｎｇ、トレースルーティング等の他のツールのうちの１つ以上のものに基づいて、コンテキスト情報を取得し得る。コンテキストプロバイダ１７４は、プロキシゲートウェイ１６９から列挙されたサービス要素ホストまでの決定された距離を返す。例では、ＳＥＨＳ１７１は、以前のトランザクションからのコンテキスト情報をキャッシュし得、したがって、コンテキスト情報をコンテキストプロバイダ１７４から要求しないこともある。読み出されるコンテキスト情報は、表５に示されるようなものであり得る。

図１１を継続して参照すると、ステップ２０３では、ＳＥＨＳ１７１は、ＱｏＳ要件および取得されたコンテキスト情報に基づいて、サービス要素ホストの組を選択し得る。表５に基づくこの例では、ＳＥＨＳ１７１は、クライアント１７０までの最短総距離を有するので、サービス「ＤｅｄｕｃｅＳｅｒｖｉｃｅ１」の３つのサービス要素の各々をクライアント１７０に提供するサービス要素ホスト１７２として、「ｔｅｍｐＳｅｎｓｏｒ１」、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ２」、および「ａｉｒＳｅｎｓｏｒ２」を選択する。ステップ２０４では、ＳＥＨＳ１７１は、ステップ２０１のオリジナルサービス要求を継続中サービスリストに入れる。ステップ２０５では、ＳＥＨＳ１７１は、選択されたサービス要素ホスト１７２の各々にディスパッチされるであろうクライアント１７０のためのサービス要素要求を編成する。ステップ２０５において生成されたサービス要素要求では、サービス要素ホスト１７２がサービス要素を送信すべき場所を把握するように、クライアント１７０のアドレスが、含まれ得る。

図１１を継続して参照すると、ステップ２０６ａでは、ＳＥＨＳ１７１は、クライアント１６９の代わりに、サービス要素要求を選択されたサービス要素ホスト１７２にディスパッチする。ＳＥＨＳ１７１は、クライアント１７０のアドレス、ステップ２０１のサービス要求からのｓｅｒｖｉｃｅＩＤ、およびサービス要素ホスト１７２のための対応するｓｅｒｖｉｃｅＥｌｅｍｅｎｔＩＤをディスパッチされる要求メッセージ内に含み得る。ＳＥＨＳ１７１は、クライアント１７０とサービス要素ホスト１７２との間の共通信頼ポイントであり得る。ステップ２０６ａまたは２０１のサービス要素要求メッセージは、クライアント１７０と通信するときに使用され得るセキュリティ証明情報を含み得る。ステップ２０６ｂでは、ＳＥＨＳ１７１は、要求されるサービス内に含まれる各サービス要素のための確認および選択されたサービス要素ホスト１７２を含み得る、メッセージを送信する。サービス要素ホスト１７２とクライアント１７０との間のセキュアな通信を確立するために、セキュリティキーが、ステップ２０６ｂのメッセージ内に含まれ得る。加えて、ＳＥＨＳ１７１は、表６に示されるように、同じサービスおよびプロキシゲートウェイに対応する選択されたサービス要素ホスト１７２を記憶し得る。前述は、以下の状況において有用であり得る。例えば、別のクライアント（図示せず）がクライアント１７０と同じプロキシゲートウェイ１６９を使用して、同じＱｏＳ要件を伴う同じサービスのためのサービス要求を送信する場合、ＳＥＨＳ１７１は、ステップ２０２およびステップ２０３を実施する必要がないこともある。ＳＥＨＳ１７１は、すでに選択されたサービス要素ホスト１７２を使用して、要求および他の関連付けられたメッセージングをディスパッチし得る。

図１１を継続して参照すると、ステップ２０７では、プロキシゲートウェイ１６９は、ステップ２０１に関連付けられたサービス要素（例えば、サービス要素に関連付けられたデータ）を受信する。ステップ２０７のメッセージは、サービス要素ホスト１７２からであることを示し得る。ステップ２０８では、プロキシゲートウェイ１６９は、各サービス要素ホスト１７２からの受信されたメッセージをチェックし、サービス要素の閾値量が受信されたかどうかを決定し得る。ステップ２０９では、サービス要素の閾値量がプロキシゲートウェイ１６９によって受信されたことの決定後、サービス完了メッセージをＳＥＨＳ１７１に送信し得る。ステップ２１０では、ＳＥＨＳ１７１は、サービス要求を継続中リストから除去し得、それは、ステップ２０１のサービス要求が完了されたことを示す。

図１２は、図１０によって要約される第２のシナリオに基づく、ＳＥＨＳの例示的メッセージフローを図示する。ステップ２１１では、サービスホスト１７３は、ＱｏＳ要件を伴う表３に示されるようなサービス要求を受信する。サービス要求は、サービスホスト１７３からであることを示し得る。ステップ２１２では、サービスホスト１７３は、サービス要素ホスト１７２がサービス要素をサービスホスト１７３に送信するように、プロキシゲートウェイ１６９からの要求メッセージ内のプロキシアドレスをそれ自体（サービスホスト１７３）へリセットする。ステップ２１３では、サービスホスト１７３は、ステップ２１１のサービス要求をＳＥＨＳ１７１に転送する。ステップ２１４から２１８ａは、図１１のステップ２０２からステップ２０６ａに類似する。図１２のステップ２１８ｂは、図１１のステップ２０６ｂに類似するが、ステップ２１８ｂでは、ＳＥＨＳ１７１は、確認をサービスホスト１７３に送信する。

図１２を継続して参照すると、ステップ２１９では、サービスホスト１７３は、ステップ２１１に関連付けられたサービス要素を受信する。ステップ２２０では、サービスホスト１７３は、各サービス要素ホスト１７２から受信されたメッセージをチェックし、サービス要素の閾値量が受信されたかどうかを決定し得る。ステップ２２１では、サービスホスト１７３は、閾値量が受信されると、ステップ２１９の受信されたサービス要素の完全サービスを形成する。例えば、図６の推測サービスに対して、サービスは、受信された温度、湿度、およびＣＯ_２データからの推測によって編成される。ステップ２２２ａでは、サービス要素の閾値量がサービスホスト１７３によって受信されたことの決定後、サービス完了メッセージをＳＥＨＳ１７１に送信し得る。ステップ２２２ｂでは、サービスホスト１７３は、全体的サービスをプロキシゲートウェイ１６９に送信する。ステップ２２３では、ＳＥＨＳ１７１は、サービス要求を継続中リストから除去する。除去は、ステップ２１１のサービス要求が完了したことを示し得る。他のクライアント（図示せず）も、他のクライアントのためのプロキシとしての役割を果たすサービスホスト１７３に要求を送信し得るので、サービス要素選択は、同じＱｏＳ要件を伴うサービス要求に対して、主要なイベント（例えば、電力サイクル、エラー、閾値超過等）がなければ、１回のみ発生し得る。

サービス要素ホスト再選択が、現在選択されているサービス要素ホスト１７２によって提供されるサービスのクライアントの不満足（例えば、最小閾値を満たさない）を含み得る、コンテキスト変化に起因して、ＳＥＨＳ１７１において発生し得る。サービス要素ホスト再選択に関する例は、以下に議論される。例は、図９の第１のシナリオのコンテキストにおけるものであるが、サービス要素ホスト再選択は、図１０の第２のシナリオ等の他のシナリオにも適用可能である。ＳＥＨＳ１７１によって取り扱われ得る、サービス要素ホストを再選択するようにＳＥＨＳ１７１をトリガし得る、本明細書に提供されるもの以外の要因が存在することも可能である。

図１３は、コンテキストの変化に基づくサービス要素ホスト再選択の例示的メッセージフローを図示する。ステップ２３１では、ＳＥＨＳ１７１は、コンテキストプロバイダ１７４によって提供される関心のあるコンテキストにサブスクライブする。ＳＥＨＳ１７１によって考慮され得る異なるコンテキスト情報が存在する。例えば、ＳＥＨＳ１７１は、信頼性のＱｏＳ要件に基づいて、サービス要素ホスト１７２のバッテリに関連付けられた情報にサブスクライブし得る。ＳＥＨＳ１７１は、バッテリ電力のための閾値が満たされる場合、通知され得る。例は、デバイス間の距離に関して、図１３のフローのためにコンテキスト要求され得る。ＳＥＨＳ１７１は、プロキシゲートウェイ１６９からサービス要素ホスト１７２までの距離のためのコンテキスト情報にサブスクライブし得る。ステップ２３２では、ＳＥＨＳ１７１は、コンテキストにおける変化を通知するためのメッセージを受信する。ステップ２３２のメッセージは、コンテキストプロバイダ１７４からであることを示し得る。例では、プロキシゲートウェイ１６９からサービス要素ホスト「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ１」までの距離は、３である。表７に示される３の距離は、７等の別の数字から減少している。

図１３を継続して参照すると、ステップ２３３では、３へのｈｕｍｉｄｉｔｙＳｅｎｓｏｒ１の距離の変化は、関連継続中サービス、または表６に示されるような選択されたサービス要素ホスト履歴内に記憶されるサービスのために、サービス要素ホスト再選択を行うようにＳＥＨＳ１７１をトリガする。ＳＥＨＳ１７１は、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ１」を新しいサービス要素ホスト１７５として選択し、サービス要素「ｓｅｒｖｉｃｅ１．ｈｕｍｉｄｉｔｙ」を提供し得る。ステップ２３４では、ＳＥＨＳ１７１は、プロキシゲートウェイ１６９に、新しく選択されたサービス要素ホスト１７５の通知を送信し、それは、サービス要素のうちの１つを提供する。ステップ２３５では、プロキシゲートウェイ１６９は、現在のステータスとともに、一般的サービス要素ホスト切り替えに対する変化の通知（またはサービス要素ホスト１７５に対する切り替えの特定の言及）の受信を確認する。ステータスは、プロキシゲートウェイ１６９がサービス要素を受信している段階を示す。例では、プロキシゲートウェイ１６９は、ある期間、例えば、１０分にわたって、サービスを受信する（例えば、個々のサービス要素の各々にサブスクライブする）ことを欲し得る。その結果、ステータスにおいて、プロキシゲートウェイ１６９は、それがサービスを例えば、４分受信したこと、したがって、６分残っていることを通知し得る。ステップ２３６では、ＳＥＨＳ１７１は、サービス要素要求を、プロキシゲートウェイ１６９からの現在のサービス要素受信ステータスとともに、新しく選択されたサービス要素ホスト１７５に送信する。

図１３を継続して参照すると、ステップ２３７では、ＳＥＨＳ１７１は、サービス要素要求キャンセルを古いサービス要素ホスト１７２に送信する。例えば、サービス要素ホスト１７２は、表６および表７に示されるように、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ２」であり得る。ステップ２３８では、新しいサービス要素ホスト１７５は、未完了サービス要素をプロキシゲートウェイ１６９に提供する。例では、サービス要素ホスト１７５（「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ１」）は、残りの６分にわたって湿度データをプロキシゲートウェイ１６９に送信する。ステップ２３９では、プロキシゲートウェイ１６９は、期間内にサービス要素ホストから閾値数のサービス要素（例えば、期間あたり、量あたり、またはそれらの組み合わせ）（元々選択されたものと新しく選択されたものの組み合わせであり得る）を受信したかどうかを決定する。ステップ２４０では、閾値に到達後、プロキシゲートウェイ１６９は、サービス完了確認をＳＥＨＳ１７１に送信する。ステップ２４１では、ＳＥＨＳ１７１は、サービス要求を継続中リストから除去する。除去は、プロキシゲートウェイ１６９によって要求されるサービスの完了を示し得る。

図１４は、クライアントの不満足（例えば、最小閾値を満たさない）に基づく、サービス要素ホスト再選択の例示的メッセージフローを図示する。ステップ２５１では、クライアント２７０は、不満足閾値に到達するＱｏＳに対してアラートされる。アラートは、例えば、ドロップされたパケットまたは他のエラー等のサブスクライブされるトリガイベントの構成に基づいて受信され得る。アラートは、ＳＥＨＳ１７１のために受信され得る。ＱｏＳは、クライアントが最初に要求した要件と異なり得る。例えば、クライアント１７０は、サービス要素ホスト１７２（例えば、「ｔｅｍｐＳｅｎｓｏｒ１」）がある時間にわたって期待される通り温度データを送信しなかったことをアラートまたは別様に決定され得る。理由は、センサが、所定のスケジュールに基づいてそのスリープモードに切り替わったか、または別様に利用不可能であり得ることであり得る。ステップ２５２では、ＳＥＨＳ１７１は、クライアント１７０のためにサービス要素ホストを再選択するための要求を受信し得る。要求は、クライアント１７０からであることを示し得、サービス要素ＩＤを含み得る。ステップ２５３では、ステップ２５２の要求に基づいて、ＳＥＨＳ１７１は、関連継続中サービスのためのサービス要素ホストの再選択を行うようにトリガされ得る。例では、ＳＥＨＳ１７１は、サービス要素ホスト１７５（例えば、「ｔｅｍｐＳｅｎｓｏｒ２」）がサービス要素ホスト１７２（例えば、「ｔｅｍｐＳｅｎｓｏｒ１」）の代わりに要求されるサービス要素を提供するため選択されるように、変更を行い得る。

図１４を継続して参照すると、ステップでは、ＳＥＨＳ１７１は、クライアント１７０に、要求されるサービス要素（例えば、温度）のために新しく選択されたサービス要素ホスト１７５を知らせるメッセージを送信する。ステップ２５５では、クライアント１７０は、サービス要素ホスト１７５に、サービス要素を得ることに関する要求を送信し得る。要求は、ＳＥＨＳ１７１の代わりに、クライアント１７０から直接ディスパッチされる。この直接要求は、代替であり、本明細書で議論されるいくつかの他の例と異なる。ステップ２５６では、ＳＥＨＳ１７１は、サービス要素ホスト１７２にそれとのサービスのキャンセルを通知するために、メッセージをサービス要素ホスト１７２に送信する。サービス要素ホスト１７２は、ＳＥＨＳ１７１に確認または同等メッセージで応答し得る。ステップ２５７からステップ２６０は、図１３のステップに類似する。

以下に議論されるのは、ＳＥＨＳがクライアントの要求に基づいてサービス要素ホストの複数の候補を選択し得る方法に関する方法であり、それによって、クライアントがＱｏＳの閾値変化（例えば、ＱｏＳ劣化）が存在することを決定すると、クライアントは、自動的に次の候補に切り替えられることができる。表３におけるサービス要求メッセージは、バックアップのための１つ以上の候補を有するオプションを示すために追加されるフィールドを有し得る。図１５は、サービス要素ホストの複数の候補を伴うサービス要求の例示的メッセージフローを図示する。ステップ２７１およびステップ２７２は、図１１のステップ２０１およびステップ２０２に類似する。ステップ２７３では、ＳＥＨＳ１７１は、ＱｏＳ要件、コンテキスト情報等に基づいて、複数の候補グループを選択し得る。例では、ＳＥＨＳ１７１は、「ｔｅｍｐＳｅｎｓｏｒ１」、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ２」、「ａｉｒＳｅｎｓｏｒ２」を第１の候補として、「ｔｅｍｐＳｅｎｓｏｒ１」、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ２」、「ａｉｒＳｅｎｓｏｒ３」を第２の候補として、「ｔｅｍｐＳｅｎｓｏｒ２」、「ｈｕｍｉｄｉｔｙＳｅｎｓｏｒ２」、「ａｉｒＳｅｎｓｏｒ２」を第３の候補等として選択し得る。ステップ２７４では、ＳＥＨＳは、オリジナルサービス要求を継続中サービスリスト内に入れ得る。ステップ２７５では、ＳＥＨＳ１７１は、サービス要素のための要求を生成するための命令を提供する。ステップ２７６ａでは、サービス要素のための要求は、サービス要素ホスト１７２にディスパッチされ、サービス要素ホスト１７２は、サービス要素（例えば、温度、湿度、ＣＯ_２に関するデータ）を集めるためのサービス要素ホストとしての選択のための複数の候補のうちの第１の候補であり得る。ステップ２７６ｂでは、ＳＥＨＳ１７１は、メッセージをクライアント１７０に送信する。メッセージは、サービス要素ホスト１７２が選択されたことの確認を含み得る。メッセージは、サービス要素ホストの複数の候補グループのリストも含み得る。

図１５を継続して参照すると、ステップ２７７からステップ２７８は、図１１のステップ２０７およびステップ２０８に類似する。ステップ２７９は、図１４のステップ２５１に類似する。ステップ２８０では、クライアント２７０は、サービス要素「ｓｅｒｖｉｃｅ１．ｔｅｍｐｅｒａｔｕｒｅ」を提供するためのサービス要素ホストとしての別の候補（例えば、第３の候補−ｔｅｍｐＳｅｎｓｏｒ２）に切り替えることに関連付けられたメッセージを送信する。ステップ２８０のメッセージは、温度に関連付けられたサービス要素（例えば、ｔｅｍｐＳｅｎｓｏｒ１）に関するサービス要素ホスト１７２へのキャンセルメッセージであり得る。ステップ２８１からステップ２８５は、それぞれ、図１４のステップ２５６からステップ２６０に類似する。

以下の議論は、特に、サービスを要求するとき、サービス要素の順番を考慮する。言い換えると、サービスのサービス要素は、完全なサービスを得るために、クライアントによって受信されるべき、所定の順序を有し得る。以下に議論されるのは、サービス要素の要求が要求側クライアントにある順序で到達する２つの例示的シナリオである。処理順序に関する考慮点（例えば、順序外で到達しているが、ある順序で処理している）も、本明細書で検討されるが、以下で直接述べられない。

表８および図１６に示されるようなサービス要素の順番に関する第１のシナリオでは、サービスＳ１は、２つのサービス要素：ＡおよびＢを有する。サービス要素Ａは、デバイス−１、デバイス−４、およびデバイス−６と標識された３つのサービス要素ホストを有する。３つのサービス要素ホストの応答時間は、それぞれ、１１秒、５秒、および１秒である。サービス要素Ｂは、１つのサービス要素ホスト（デバイス８）を有し、その応答時間は、１０秒毎に変動し、２０秒または１秒のいずれかである。この例では、応答時間は、サービス要素要求が着信した瞬間に決定され、サービス要素Ａは、サービス要素Ｂの前に提供される必要がある。最短総応答時間のＱｏＳ要件を伴うＳＥＨＳ１７１によって受信される要求があり得る。

サービス要素の順番に関する第１のシナリオの検討を継続すると、サービス要素の順番が考慮されない場合、ＳＥＨＳ１７１は、他のサービス要素ホストの中で最短応答時間を有するので、サービス要素Ａを配信するためにデバイス−６を選定するであろう。さらに、１つのみのサービス要素ホストがサービス要素Ｂを提供するので、デバイス−８が、代替を伴わずに選択される。要求が、図１６に示されるブロック２９１におけるデバイス−８の（その応答時間が２０秒である場合の）非効率的期間内において着信する場合、サービス要素Ｂの応答時間は、２０秒である。したがって、サービスの総応答時間は、デバイス−６が選定される場合、ｍａｘ（１，２０）＝２０秒であろう。しかしながら、この例示的第１のシナリオでは、サービス要素Ａは、サービス要素Ｂの前に要求側クライアント１７０に到達する必要があることが要求される。同じデバイスが選定される（デバイス−６およびデバイス−８）場合、サービスの総応答時間は、１＋２０＝２１秒であろう。

サービス要素の順番に関する第１のシナリオの検討を継続すると、デバイス−６およびデバイス−８の選択は、サービス要素の順番が考慮されるとき、サービス要素ホストの最も効率的組み合わせではない。より効率的ソリューションは、ＳＥＨＳ１７１が、最初に、サービス要素Ａを提供するために、デバイス−１を選択することであり得る。クライアント１７０がサービス要素Ａを受信後、サービス要素Ｂのための要求が、その後、デバイス−８にディスパッチされる。その時点で、デバイス−８は、その効率的期間（１秒）にすでに切り替わっており、総応答時間は、１１＋１＝１２秒である。

サービス要素の順番に関する第２のシナリオでは、表９および図１７に示されるように、サービスＳ２は、２つのサービス要素：ＣおよびＤを有する。サービス要素Ｃは、デバイス−２およびデバイス−５と標識された２つのサービス要素ホストを有する。２つのサービス要素ホストの応答時間は、それぞれ、１０秒および１秒である。サービス要素Ｄは、デバイス−６およびデバイス−９と標識された２つのサービス要素ホストを有する。２つのサービス要素ホストの応答時間は、２０秒および１秒であるが、それらは、オンライン／オフラインスケジュールまたはスリープスケジュールを有する。このシナリオでは、要求は、ＳＥＨＳ１７１によって、最短総応答時間のＱｏＳ要件とともに受信される。さらに、サービス要素Ｃは、サービス要素Ｄの前、要求側クライアント１７０に到達する必要があることも要求される。

サービス要素の順番に関する第２のシナリオを継続して参照すると、ＳＥＨＳ１７１が、サービス要素Ａを提供するためにデバイス−５を選択する場合、１秒後、デバイス−６がオンラインになるが、デバイス−９がオフラインになる状況が発生する。２つのサービス要素の順番を考慮すると、サービスの総応答時間は、１＋２０＝２１秒であろう。デバイス−２がサービス要素Ｃを提供することを可能にする等、より効率的選択が、ＳＥＨＳ１７１によって行われ得る。次の１０秒後、デバイス−２がサービス要素Ｃの提供を終了すると、デバイス９は、オンラインになる。ＳＥＨＳ１７１は、サービス要素Ｄを提供するためにデバイス−９を選択するオプションを有する。したがって、サービスの総応答時間は、１０＋１＝１１秒であろう。

図１８は、ＳＥＨＳがＣＳＥ内にｏｎｅＭ２Ｍ ＳＥＨＳ ＣＳＦ２９４としてホストされ得る例示的例証である。ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、能力サービス機能（ＣＳＦ）の組を含む能力サービスエンティティ（ＣＳＥ）としてインスタンス化される。

アプリケーションエンティティ（ＡＥ）またはＣＳＥであり得る、クライアント１７０は、ＭｃａまたはＭｃｃ参照点を介して、ｏｎｅＭ２Ｍ ＳＥＨＳ ＣＳＦ２９４と通信し、サービスを要求し得る。ｏｎｅＭ２Ｍ ＳＥＨＳ ＣＳＦ２９４は、Ｍｃｎ参照点を介して、下層ネットワークサービスエンティティと通信し、関連コンテキスト情報を読み出し得る。ｏｎｅＭ２Ｍ ＳＥＨＳ ＣＳＦ２９４は、各サービス要素ホスト１７２と通信し、Ｍｃａ、Ｍｃｃ／Ｍｃｃ’参照点を介して、サービス要求をディスパッチし得る。

図１９は、ｏｎｅＭ２Ｍ ＲｏＡのためのサービス要求の例示的例証である。この例では、サービスホストは、ＭＮ−ＣＳＥである。クライアントであるＡＥ３０１は、サービス要求をＩＮ−ＣＳＥ３０２内のＳＥＨＳ ＣＳＦに送信する。コンテキストプロバイダは、ＮＳＥ３０３であり得る。ＩＮ−ＣＳＥ３０２内のＳＥＨＳは、コンテキスト情報にサブスクライブし、その通知をＮＳＥ３０３から入手し得る（またはそれを読み出す）。ＩＮ−ＣＳＥ３０２は、サービス要素ホストであるＡＳＮ−ＣＳＥ３０４にサービス要素要求を送信し、応答をそこから受信し得る。

本明細書に議論されるようなメッセージに基づいて、ＩＮ−ＣＳＥ３０２は、以下のリソースをそのリソース構造内に維持し、定義されたプロシージャ、すなわち、サービス要求のためのＲＥＳＴｆｕｌインターフェースを提供し得る。図２０は、＜ｓｅｒｖｉｃｅＲｅｑｕｅｓｔ＞のリソースツリー構造の例示的例証である。表１０および表１１は、＜ｓｅｒｖｉｃｅＲｅｑｕｅｓｔ＞リソースの子リソースおよび属性を示す。それらの共通属性は、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１（以降、［１］）を参照し得る。

図２１は、ｏｎｅＭ２Ｍにおけるサービス要求の例示的メッセージフローを図示する。図２１のメッセージフローは、前述のメッセージフローより簡略化されている。ステップ３１１では、ＡＥ３０１（例えば、クライアント１７０）は、＜ｓｅｒｖｉｃｅＲｅｑｕｅｓｔ＞を作成し、サービス要求をＩＮ−ＣＳＥ３０２（例えば、ＳＥＨＳ１７１）に送信する。ステップ３１２では、ＩＮ−ＣＳＥ３０２は、ＱｏＳ要件に基づいて、ＡＳＮ−ＣＳＥ３０４（例えば、サービス要素ホスト１７２）を選択する。ステップ３１３では、ＩＮ−ＣＳＥ３０２は、＜ｓｅｒｖｉｃｅＲｅｑｕｅｓｔ＞をＡＳＮ−ＣＳＥ３０４に転送する。ステップ３１４では、ＡＳＮ−ＣＳＥ３０４は、サービス要素応答をＡＥ３０１に送信する。

図２２は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（ＳＯＡ）内の例示的ＳＥＨＳを図示する。ＡＥ３２１または遠隔サービスエクスポージャコンポーネント３２２等の形態のサービスプロバイダは、サービス要素およびその対応するサービス要素ホスト（例えば、サービス要素ホスト１７２）を報告および更新するために、Ｍｃａ参照点３３１またはＭｓｃ参照点３３２を介して、サービス要素ホスト選択サービスコンポーネント３２３（例えば、ＳＥＨＳ１７１）にトークし得る。ＡＥ３２１または遠隔サービスエクスポージャコンポーネント３２２等の形態におけるクライアント（例えば、クライアント１７０）は、Ｍｃａ参照点３３１またはＭｓｃ参照点３３２を介して、サービス要素ホスト選択サービスコンポーネント３２３と通信し、サービスを要求し得る。サービス要素ホスト選択サービスコンポーネント３２３は、Ｍｓｃ参照点３３２を介して、ネットワークサービス利用コンポーネント３２４（例えば、コンテキストプロバイダ１７４）を通して下層ネットワークサービスエンティティと通信し、関連コンテキスト情報を読み出すであろう。サービス要素ホスト選択サービスコンポーネント３２３は、Ｍｃａ参照点３３１またはＭｓｃ参照点３３２を介して、各サービス要素ホストと通信し、サービス要求をディスパッチし得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とりわけ、本明細書に説明されるような方法、システム、および装置は、サービスホスト選択等のための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、サービスに対する要求とサービス品質の要件とを含む、メッセージを受信するスことと、メッセージに基づいて、サービス要素ホストを決定することと、要求をサービス要素ホストに転送することとを行う手段を有する。メッセージは、サービスの識別子を含み得る。メッセージは、サービスホストからであることを示し得る。メッセージは、サービスが構成されているサービス要素の数を含み得る。メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを含み得る。メッセージは、第１のサービスのための第１のサービス要素を処理する順番のインジケータを含み得る。第１のサービス要素は、温度データであり得る。本段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で検討される。

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

Claims (20)

1. 装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   サービスに対する要求とサービス品質の要件とを備えているメッセージを受信することと、
   前記メッセージに基づいて、サービス要素ホストを決定することと、
   前記要求を前記サービス要素ホストに転送することと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記メッセージは、サービスの識別子を備えている、請求項１に記載の装置。
3. 前記メッセージは、サービスホストからであることを示す、請求項１に記載の装置。
4. 前記メッセージは、サービスが構成されているサービス要素の数を備えている、請求項１に記載の装置。
5. 前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、請求項１に記載の装置。
6. 前記メッセージは、第１のサービスのための第１のサービス要素を処理する順番のインジケータを備えている、請求項１に記載の装置。
7. 前記第１のサービス要素は、温度データである、請求項１に記載の装置。
8. システムであって、前記システムは、
   ディスプレイと、
   前記ディスプレイと通信可能に接続されるデバイスと
   を備え、
   前記デバイスは、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、プロセッサによって実行されると、
   サービスに対する要求を備えているメッセージを受信することと、
   前記メッセージに基づいて、サービス要素ホストを決定することと、
   前記要求を前記サービス要素ホストに転送することと、
   前記サービス要素ホストを備えている記録を前記ディスプレイにパブリッシュすることと
   を含む動作を前記プロセッサに達成させる、システム。
9. 前記メッセージは、サービスの識別子を備えている、請求項８に記載のシステム。
10. 前記メッセージは、サービスホストからであることを示す、請求項８に記載のシステム。
11. 前記メッセージは、サービスが構成されているサービス要素の数を備えている、請求項８に記載のシステム。
12. 前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、請求項８に記載のシステム。
13. 前記メッセージは、第１のサービスのための第１のサービス要素を処理する順番のインジケータを備えている、請求項８に記載のシステム。
14. さらなる動作が、地理的エリアのグラフィカル表現を提供することを含み、前記グラフィカル表現は、前記サービス要素ホストの場所を示すインジケータを備えている、請求項８に記載のシステム。
15. さらなる動作が、グラフィカル表現を提供することを含み、前記グラフィカル表現は、前記サービス要素要求の受信の確認を示すインジケータを備えている、請求項８に記載のシステム。
16. 方法であって、前記方法は、
    サービスに対する要求を備えているメッセージを受信することと、
    前記メッセージに基づいて、サービス要素ホストを決定することと、
    前記要求を前記サービス要素ホストに転送することと
    を含む、方法。
17. 前記メッセージは、サービスの識別子を備えている、請求項１６に記載の方法。
18. 前記メッセージは、サービスホストからであることを示す、請求項１６に記載の方法。
19. 前記メッセージは、サービスが構成されているサービス要素の数を備えている、請求項１６に記載の方法。
20. 前記メッセージは、各サービス要素のための複数のサービス要素ホストのインジケータを備えている、請求項１６に記載の方法。