JP2018514162A - Ｍ２ｍサービスを追加するためのデバイスおよび方法 - 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. 前記基準は、サービスノード場所、サービスドメイン要件、アクセス制御、下層ネットワークプロトコル、デバイス管理、負荷バランス、サービスノードタイプ、サポートされるＡＰＩ、セキュリティ、データ記憶、集約選好、およびそれらの組み合わせから選択される、請求項１２に記載の方法。