JP6456472B2 - 複数のデバイス上での複数のコマンドの実行を可能にすることによるｍ２ｍシステムにおけるサービス層と管理層との間の拡張型動作 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０２６，１６５号（２０１４年７月１８日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

デバイス管理（ＤＭ）は、従来、管理サーバとデバイス上で作動する管理クライアントとの間で行われている。この動作モードは、個人用のモバイルデバイス（例えば、電話およびタブレット）、または個々に管理される動作可能なネットワークデバイス等のデバイスのための既存のＤＭプロトコルに適合し得る。したがって、デバイスのグループのためのＤＭプロトコルを管理することにおいて、限定された開発およびサポートが存在してきた。

オープンモバイルアライアンス（ＯＭＡ）は、ＯＭＡ ＤＭプロトコル、ＯＭＡゲートウェイ管理対象オブジェクト（ＧｗＭＯ）プロトコル、およびＯＭＡ軽量マシンツーマシン（ＬＷＭ２Ｍ）プロトコルを含む、ネットワーク内のＤＭのためのいくつかのプロトコルを開発してきた。さらに、ブロードバンドフォーラム（ＢＢＦ）は、カスタマ構内設備（ＣＰＥ）ＷＡＮ管理プロトコル（ＣＷＭＰ）を含む。これらのプロトコルは、ネットワーク内のモバイルデバイス等の独立型デバイスを管理するために使用され得る。ＯＭＡ ＧｗＭＯプロトコルは、ゲートウェイの背後のエンドデバイスのグループを管理するために使用され得る。しかしながら、プロトコルは、ゲートウェイにアタッチされたデバイスに限定される。ＯＭＡ ＬＷＭ２Ｍは、制約のあるマシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）デバイスを管理するために使用され得る。ＢＢＦ ＣＷＭＰプロトコルは、デバイスのグループへのファイル転送を提供するために、ローカルエリアネットワーク（ＬＡＮ）内でマルチキャストグループを使用する機構を規定する。さらに、これらのプロトコルは、主に、ソフトウェアダウンロードに焦点を合わせる。別個に、ＢＢＦ ＣＷＭＰは、マルチキャストが展開され得るＬＡＮ内のデバイスに限定される。要するに、現在のＤＭ規格によってエンドツーエンドアーキテクチャにおいて拡張型グループ管理動作を提供することには不足がある。

より具体的には、現在の規格では、どのようにしてＭ２ＭサーバがＤＭサーバと通信することができるかについてプロシージャも、殆どまたは全くない。これは、通信用のインターフェースの非標準化に起因する。現在、インターフェースは、各サービスプロバイダのためのカスタマイズされた開発を必要とする。例えば、サービス層がＯＭＡ ＤＭ、ＯＭＡ軽量Ｍ２Ｍ（ＬＷＭ２Ｍ）、およびＢＢＦ ＣＷＭＰデバイスをサポートするために、３つのカスタムＡＰＩインターフェースが、これらのデバイスの各々と通信するために開発される必要がある。これは、効率を低減させ、異なるシステム間の相互運用性も限定する。

本概要は、発明を実施するための形態において以下でさらに説明される一連の概要を簡略化された形態において紹介するために提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述のニーズは、管理サーバへのグループ動作のためのデバイス管理動作を拡張するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。

本願の一側面は、不揮発性メモリとプロセッサとを備えている、グループオングループ動作を行うための装置を対象とする。不揮発性メモリは、プロセッサによって実行されると、サーバにあるステップを行わせるコンピュータ実行可能命令を記憶する。１つのステップは、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、グループオングループ動作を開始する要求をデバイス所有者から受信するためのものである。次に、要求が処理される。さらに、コマンドを実行するためにデバイス上で作動するＤＭクライアントとセッションを確立するためのグループ管理要求ＡＰＩを管理サーバに送信するステップがある。

本願の別の側面は、Ｍ２Ｍサーバと管理サーバとの間に存在するＭ２Ｍインターフェースを経由してグループオングループ動作を確立するためのコンピュータ実装方法を対象とする。方法は、デバイスのグループを管理するために、デバイス所有者から登録要求を受信するステップを含む。方法は、デバイスのグループのための登録通知を受信するステップも含む。次に、例えば、デバイス所有者から等、デバイスグループを作成するための要求が受信される。さらに、デバイスグループを作成するための受信された要求が実行される。一実施形態では、方法は、コマンドグループを作成するための要求を受信するステップと、コマンドグループを作成するように、受信された要求を処理するステップとをさらに含む。別の実施形態によると、方法は、デバイスグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信するステップをさらに含む。別の実施形態では、方法は、コマンドグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信するステップをさらに含む。

本願のさらに別の側面は、Ｍ２Ｍインターフェースを経由してグループオングループ動作を行うためのコンピュータ実装方法を対象とする。方法は、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、グループオングループ動作を開始する要求をデバイス所有者から受信するステップを含む。方法は、要求を処理するステップを含む。加えて、コマンドを実行するためにデバイス上で作動するＤＭクライアントとセッションを確立するためのグループ管理要求ＡＰＩを管理サーバに送信するステップがある。さらに、デバイスによるコマンドの成功した実行を示す応答をＤＭサーバから受信するステップがある。

したがって、その詳細な説明がさらに理解され得るために、および当技術分野への貢献がさらに認識され得るために、本発明のある実施形態が、かなり広く概説されている。
例えば、本願は以下の項目を提供する。
（項目１）
グループオングループ動作を行うためのコンピュータ実装装置であって、前記装置は、不揮発性メモリとプロセッサとを備え、前記不揮発性メモリは、コンピュータ実行可能命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
前記グループオングループ動作を開始するための要求を受信するステップであって、前記要求は、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、ステップと、
前記要求を処理するステップと、
デバイス上で前記コマンドを実行するためのグループ管理要求ＡＰＩを管理サーバに送信するステップと
を前記装置に行わせる、装置。
（項目２）
前記プロセッサは、前記デバイスによる前記コマンドの実行を示す応答を前記管理サーバから受信する命令を実行する、項目１に記載の装置。
（項目３）
デバイスグループを作成するためのグループ管理要求ＡＰＩを前記管理サーバに送信することをさらに含む、項目１に記載の装置。
（項目４）
コマンドグループを作成するためのグループ管理要求ＡＰＩを前記管理サーバに送信することをさらに含む、項目３に記載の装置。
（項目５）
前記デバイスグループおよびコマンドグループが作成されたという返信を前記管理サーバから受信することと、
前記デバイスグループおよびコマンドグループが作成されたという返信をデバイス所有者に送信することと
をさらに含む、項目４に記載の装置。
（項目６）
前記コマンドグループは、ｍｅｍｂｅｒＴｙｐｅ、ｍｅｍｂｅｒｓＬｉｓｔ、ｃｏｍｍａｎｄｓＬｉｓｔ、ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇ、ａｒｇｕｍｅｎｔｓＬｉｓｔ、ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、ｒｅｓｐｏｎｓｅＰｅｒｉｏｄ、およびそれらの組み合わせから選択されるグループリソースを含む、項目１に記載の装置。
（項目７）
前記ｍｅｍｂｅｒＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞である、項目６に記載の装置。
（項目８）
前記＜ｍｇｍｔＣｍｄ＞は、ｅｘｅｃＴａｒｇｅｔ、ｅｘｅｃＩｎｓｔａｎｔ、およびそれらの組み合わせから選択される属性を含む、項目７に記載の装置。
（項目９）
前記装置は、サーバである、項目１に記載の装置。
（項目１０）
Ｍ２Ｍインターフェースにおいてグループオングループ動作を確立するためのコンピュータ実装装置であって、前記装置は、不揮発性メモリとプロセッサとを備え、前記不揮発性メモリは、コンピュータ実行可能命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
デバイスのグループを管理するための登録要求を受信するステップと、
デバイスグループを作成するための要求を受信するステップと、
前記受信された要求を実行し、前記デバイスのグループのための前記デバイスグループを作成するステップと
を前記装置に行わせる、装置。
（項目１１）
前記プロセッサは、前記デバイスのグループから登録通知を受信するようにさらに構成されている、項目１０に記載の装置。
（項目１２）
Ｍ２Ｍインターフェースにおいてグループオングループ動作を確立するためのコンピュータ実装方法であって、
デバイスのグループを管理するための登録要求を受信することと、
前記デバイスのグループから登録通知を受信することと、
デバイスグループを作成するための要求を受信することと、
前記受信された要求を実行し、前記デバイスのグループのための前記デバイスグループを作成することと
を含む、方法。
（項目１３）
コマンドグループを作成するための要求を受信することと、
前記受信された要求を実行し、前記デバイスのグループのための前記コマンドグループを作成することと
をさらに含む、項目１２に記載の方法。
（項目１４）
前記デバイスグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
前記コマンドグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと
をさらに含む、項目１２に記載の方法。
（項目１５）
前記デバイスグループおよびコマンドグループが作成されたという返信を前記管理サーバから受信することと、
前記デバイスグループおよびコマンドグループが作成されたという返信をデバイス所有者に送信することと
をさらに含む、項目１４に記載の方法。
（項目１６）
前記コマンドグループは、ｍｅｍｂｅｒＴｙｐｅ、ｍｅｍｂｅｒｓＬｉｓｔ、ｃｏｍｍａｎｄｓＬｉｓｔ、ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇ、ａｒｇｕｍｅｎｔｓＬｉｓｔ、ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、ｒｅｓｐｏｎｓｅＰｅｒｉｏｄ、およびそれらの組み合わせから選択されるグループリソースを含む、項目１２に記載の方法。
（項目１７）
Ｍ２Ｍインターフェースにおいてグループオングループ動作を行うためのコンピュータ実装方法であって、
前記グループオングループ動作を開始するための要求を受信することであって、前記要求は、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、ことと、
前記要求を処理することと、
前記デバイス上で前記コマンドを実行するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
前記デバイスによる前記コマンドの実行状態を示す応答を前記管理サーバから受信することと
を含む、方法。
（項目１８）
前記処理するステップは、前記グループリソースのａｒｇｕｍｅｎｔＬｉｓｔの中に配置されている引数参照を値に置換することを含む、項目１７に記載の方法。
（項目１９）
前記ユニフォームリソースロケータは、前記要求を展開するための絶対ユニフォームリソース識別子を含む、項目１７に記載の方法。
（項目２０）
前記デバイスグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
前記コマンドグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと
をさらに含む、項目１７に記載の方法。

本願のより堅調な理解を促進するために、ここで、同様の要素が同様の数字で参照される付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証であることのみを意図している。

図１Ａは、本願による、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システムの系統図を図示する。

図１Ｂは、本願による、図１Ａに図示されるＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図を図示する。

図１Ｃは、本願による、図１Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ端末またはゲートウェイデバイスの系統図を図示する。

図１Ｄは、本願による、図１Ａの通信システムならびに本明細書に説明されるコンテキスト認識コンテンツパブリッシュおよび解決概念の側面が具現化され得る、例示的コンピュータシステムのブロック図である。

図２Ａは、本願の実施形態による、ＤＭサーバがデバイス管理コマンドをデバイス上で作動するＤＭクライアントに送信する、ＯＭＡ ＤＭプロトコルアーキテクチャを図示する。図２Ｂは、本願の実施形態による、サービス層とデバイス管理層との間の通信を伴うＭ２Ｍインターフェースを図示する。

図３は、本願の実施形態による、ＬＷＭ２ＭサーバとＭ２Ｍデバイス上のＬＷＭ２Ｍクライアントとの間のインターフェースを図示する。

図４は、本願の実施形態による、カスタマ構内設備（ＣＰＥ）デバイスを管理するために自動構成サーバ（ＡＣＳ）が使用される、ＢＢＦ ＴＲ−０６９ ＣＰＥ ＷＡＮ管理プロトコルアーキテクチャを示す。

図５は、本願の実施形態による、管理アダプタがサービス層ＡＰＩをＤＭコマンドに変換する、サービス層アーキテクチャを図示する。

図６は、本願の実施形態による、デバイスのグループ上の管理動作の使用事例の実施例を図示する。

図７は、本願の実施形態による、エンドツーエンドＭ２ＭおよびＤＭ統合アーキテクチャを図示する。

図８は、本願の実施形態による、エンドツーエンドＤＭ動作のための呼び出しフローを図示する。

図９は、本願の実施形態による、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースを図示する。

図１０は、本願の実施形態による、グループオングループ動作を示す呼び出しフローを図示する。

図１１は、本願の実施形態による、＜ｍｇｍｔＣｍｄ＞リソースを伴うグループオングループ動作を図示する。

図１２は、本願の実施形態による、Ｍ２Ｍインターフェースグループ管理プロシージャを図示する。

図１３は、本願の実施形態による、グループ管理サポートのためのＯＭＡ ＤＭグループＭＯを図示する。

図１４は、本願の実施形態による、ＤＭサーバリソース上のグループ管理動作を図示する。

図１５は、本願の実施形態による、グラフィカルユーザインターフェースを図示する。

発明を実施するための形態が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な実施例を提供するが、詳細は、実施例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。

本明細書における「一実施形態」、「ある実施形態」、「１つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。さらに、本明細書内の種々の場所における「実施形態」という用語は、必ずしも同一の実施形態を指しているわけではない。つまり、いくつかの実施形態によって提示され得るが、他の実施形態によって提示されない、種々の特徴が説明される。

Ｍ２Ｍ／ＩｏＴ領域では、バルクデバイス管理動作を行うことの能力は、Ｍ２Ｍサーバのための不可欠な特徴であり得る。したがって、本願は、エンドツーエンドシステムにおいて拡張型グループ管理動作をサポートするための既存のサービス層および管理層アーキテクチャに対する拡張を対象とする。すなわち、Ｍ２Ｍアプリケーションは、デバイスのグループをより効率的に管理するために、アプリケーション／サービス層内で管理コマンドの組を供給することができる。

本願の一側面によると、サービス層および管理層アーキテクチャにおける拡張型グループ管理プロシージャが、デバイスおよびコマンドグループを管理することを可能にするために提案される。本願の別の側面によると、グループオングループ動作を行う機構が説明され、グループオングループ動作において、コマンドの組がデバイスのグループに適用されることができる。この能力は、Ｍ２ＭおよびＩｏＴシステム内のデバイスのより効率的な管理を可能にするであろう。別の側面によると、Ｍ２Ｍインターフェースを経由して通信するためのグループ管理プロシージャのための新しいメッセージ形式が説明される。新しいメッセージ形式は、サービス層と管理層との間のインターフェースの標準化において使用されることができる。これは、サービス層にとっての異なるデバイス管理プロトコル間の相互運用性を提供するであろう。

本願のさらに別の側面によると、新しいリソースおよび属性の実施形態が、拡張型グループ管理動作をサポートするために、ｏｎｅＭ２Ｍ、ＯＭＡ ＤＭ、ＯＭＡ ＬＷＭ２Ｍ、およびＢＢＦ ＣＷＭＰアーキテクチャにおいて定義される。例えば、Ｍ２Ｍアプリケーションがコマンドのグループを作成し、これらのコマンドのための引数を提供することを可能にするために、新しいｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソース属性が導入される。さらに、グループオングループ動作を規定するための新しいｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞アドレス方式が説明される。加えて、グループ動作を規定することを可能にするために、＜ｍｇｍｔＣｍｄ＞リソース属性ｅｘｅｃＴａｒｇｅｔに対する拡張が説明される。さらに、グループ動作をサポートするためのＯＭＡ ＤＭ、ＯＭＡ ＬＷＭ２Ｍ、およびＢＢＦ ＣＷＭＰプロトコルのための新しいグループリソースが説明される。さらに、グループ動作をサポートするためのＯＭＡ ＤＭ、ＯＭＡ ＬＷＭ２Ｍ、およびＢＢＦ ＣＷＭＰプロトコル内のグループ処理プロシージャの仕様が説明される。

以下の頭字語が、本願で一般的に使用され、したがって、参考のために以下の表１で提供される。

本願は、アプリケーション有効化プラットフォーム（ＡＥＰ）および接続されたデバイスプラットフォーム（ＣＤＰ）の両方のためのプラットフォーム機能性とサポートとを対象とすることを意図している。ＡＥＰは、アプリケーション有効化層と、ワールドワイドウェブおよびインターネットを含む、サービス層とを含む。アプリケーション有効化層は、以下を含むがそれらに限定されない：（ｉ）サービシングＡＰＩ、規則／スクリプトエンジン、（ｉｉ）ＳＤＫプログラミングインターフェース、および、（ｉｉｉ）企業システム統合。アプリケーション有効化層は、発見、分析論、コンテキスト、およびイベントを含むが、それらに限定されない付加価値サービスを含み得る。ワールドワイドウェブおよびインターネットを含むサービス層は、例えば、分析論、課金、未加工ＡＰＩ、ウェブサービスインターフェース、セマンティックデータモデル、デバイス／サービス発見、デバイス管理、セキュリティ、データ収集、データ適合、集約、イベント管理、コンテキスト管理、最適化された接続性およびトランスポート、Ｍ２Ｍゲートウェイ、ならびにアドレスおよび識別を含み得る。ＣＤＰは、接続性分析、使用分析／報告／アラート、ポリシー制御、自動プロビジョニング、ＳＩＭ起動／動作停止、および加入起動／動作停止を含み得る。

（一般的アーキテクチャ）
図１Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。さらに、Ｍ２Ｍサービス層は、本願で議論され、図に図示されるように、コンテンツサーバ、コンテンツルータ、およびコンテンツクライアント等の他のデバイスと連動するようにも構成され得る。

本願で議論されるように、コンテンツルータ上にパブリッシュされたコンテンツに関係付けられるコンテキスト情報を更新することと、コンテンツ要求を解決するために最良のホップルータを決定することとを行う方法は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、トラックをリザーブする方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上にホストされ得る。さらに、本願で説明されるようなトラックを留保する方法は、本願によるトラックのリザーブ等のサービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図１Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図１Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。例えば、コンテンツルータ用のプロセッサは、以下でさらに詳細に議論され、添付図面に図示されるように、コンテンツパブリッシュマネージャ（ＣＰＭ）、ブルームフィルタプロセッサ、および／またはコンテンツ解決マネージャ（ＣＲＭ）を含み得る。本願の説明によると、Ｍ２Ｍ端末デバイス１８は、コンテンツクライアントであり得、Ｍ２Ｍゲートウェイデバイス１４は、コンテンツルータまたはコンテンツサーバであり得る。Ｍ２Ｍデバイス４０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、感覚データの組み込みセマンティクス命名のための開示されるシステムおよび方法を使用するデバイスであり得る。Ｍ２Ｍデバイス３０はまた、本願に説明され、図に図示されるように、他のデバイスとともに採用され得る。

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

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

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

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

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適な不揮発性メモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。本願によると、メモリは、以下でさらに詳細に議論され、添付図面に図示されるように、コンテンツレコードテーブル（ＣＲＴ）および／またはコンテンツフォワーヂングテーブル（ＣＦＴ）を含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。

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

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

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

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

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子構成要素を含む。ディスプレイ８６は、組み込みセマンティクス名を使用して、ファイルまたはフォルダ内の知覚データを表示し得る。一実施形態では、ディスプレイ８６は、図１５に示されるようなグラフィカルユーザインターフェースを含み得る。ここで、ＧＵＩ１５００は、Ｍ２Ｍサーバ／ゲートウェイの＜ｇｒｏｕｐ＞リソースを表示することができる。例えば、ＧＵＩ１５００は、デバイスのグループ上で実行されるコマンドのリストを示すことができる。さらに、コンピュータシステム９０は、図１Ａおよび１Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７を含み得る。

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

（デバイス管理アーキテクチャ）
デバイス管理（ＤＭ）は、中央に位置する場所にいるユーザが、遠隔に位置するデバイスを構成し、監視し、診断し、別様に管理することができる、プロセスである。これは、デバイスが本質的に移動性である場合、またはそれらへのアクセスを困難にする遠隔地域に展開されている場合、特に有益である。典型的には、中央場所におけるＤＭサーバは、デバイス上で実行されるべきコマンドをダウンロードする。デバイス上で作動するＤＭクライアントは、これらのコマンドを受信し、所望の動作を実行するために必要な状態変化を処理するであろう。ＤＭサーバとＤＭクライアントとの間のこの通信機構は、定義されたプロシージャおよびメッセージ形式を使用して実装され、ＤＭプロトコルとして知られている。周知のＤＭプロトコルのうちの２つは、ＯＭＡ ＤＭプロトコルおよびＢＢＦ ＣＰＥ ＷＡＮ管理プロトコルである。別の新興ＤＭプロトコルは、ＯＭＡ ＬＷＭ２Ｍプロトコルである。

図２Ａは、ＤＭサーバ２１０が、Ｍ２Ｍデバイス２３０上で作動するＤＭクライアントにデバイス管理コマンドを送信するＯＭＡ ＤＭプロトコルアーキテクチャ２００を図示する。ＤＭクライアントは、ＤＭツリー２１０Ａと称されるリソース構造内で管理対象オブジェクト（ＭＯ）の組を維持する。これらのＭＯは、ソフトウェア更新等のデバイス上の特定の機能を管理するために使用される。管理コマンドは、ＤＭツリーのノード上で動作し、デバイス内で状態変化を引き起こし得る。

図２Ｂは、Ｍ２Ｍサービス層２６０からＭ２Ｍインターフェース２７０を通して、ＤＭサーバ２１０を含むＤＭ層２８０にコマンドを配信するための一般的システム２５０を図示し、ＤＭサーバ２１０は、デバイス２３０と通信している。

ＯＭＡ ＬＷＭ２Ｍプロトコルは、ＬＷＭ２Ｍサーバがデバイス上で作動するＬＷＭ２Ｍクライアントを管理する同様のクライアント・サーバアーキテクチャを提供する。図３は、ＬＷＭ２Ｍアーキテクチャ３００、および提供される異なるインターフェースを図示する。これらのインターフェースは、ＬＷＭ２ＭサーバとＬＷＭ２Ｍクライアントとの間の通信に焦点を合わせており、ＬＷＭ２Ｍサーバが異なるデバイス上の複数のＬＷＭ２Ｍクライアントを管理することができるグループ動作のためのサポートがない。動作は、デバイス上に常駐するオブジェクトに対して行われる。

（ＢＢＦ ＣＰＥ ＷＡＮ管理プロトコル）
図４は、カスタマ構内設備（ＣＰＥ）デバイス４３０を管理するために自動構成サーバ（ＡＣＳ）４１０が使用される、ＢＢＦ ＴＲ−０６９ ＣＰＥ ＷＡＮ管理プロトコルアーキテクチャ４００を図示する。ＡＣＳは、ＣＰＥデバイスのデータモデルに対して管理動作を行うために、遠隔プロシージャ呼び出し（ＲＰＣ）を使用する。ＡＣＳは、ファイル転送を開始するために参加すべきマルチキャストグループの詳細を各ＣＰＥに提供するであろう。加えて、同一のＣＰＥから複数のパラメータ値を設定または入手する能力をＡＣＳに与えるために、いくつかのＲＰＣ呼び出しにおいてプロビジジョニングが行われる。これらのプロビジジョニングは、対応するＲＰＣ呼び出しのためのみに有効にされ、同一のＣＰＥに限定される。

（サービス層アーキテクチャ）
サービス層（ＳＬ）は、種々のサービスをそのユーザに提供する、アプリケーション層において動作する水平ソフトウェアプラットフォームである。提供されるサービスのうちのいくつかは、発見、グループ管理、データ管理およびレポジトリ、場所サービス等である。ＳＬによって提供される追加のサービスは、既存のＤＭプロトコルおよびインフラストラクチャを利用するデバイス管理である。図５に示されるように、ＩＮ／ＣＳＥ／ＤＭＧボックスであるＳＬ５１０と管理サーバボックスであるＤＭサーバ５２０との間の通信は、ＳＬプリミティブＡＰＩをＤＭコマンドに変換する管理アダプタ５１０ａによってハンドリングされる。ＤＭＧ内には、次いで、管理またはＤＭサーバにインターフェース接続する管理アダプタがある。ｏｎｅＭ２Ｍアーキテクチャ内では、管理タイプリソース＜ｍｇｍｔＯｂｊ＞および＜ｍｇｍｔＣｍｄ＞が定義され、それらは、ＯＭＡ ＤＭ、ＬＷＭ２Ｍ、およびＢＢＦＣＷＭＰオブジェクトにマップされる。

（高レベルアーキテクチャ）
ある側面によると、ＳＬとＭＬとの間のグループ動作のための例示的システムが、図６に図示される。図６によると、システムは、企業用の構内に基づく。ここで、ＳＬアプリケーション６１０は、ＳＬサーバ６２０と通信している。ＳＬサーバ６２０は、ＤＭまたは管理サーバ６３０と通信している。管理サーバ６３０は、ＤＭ能力６４０を伴う複数のＭ２Ｍデバイスと通信している。

図７は、ｏｎｅＭ２Ｍ等のＳＬサーバとのＤＭアーキテクチャの統合のエンドツーエンドアーキテクチャ７００を図示する。Ｍ２Ｍプロトコル７０５は、Ｍ２Ｍアプリケーション７０１（例えば、ＩＮ−ＡＥ）と、Ｍ２Ｍサーバ７０２（例えば、ｏｎｅＭ２Ｍ ＩＮ−ＣＳＥ）との間の通信を提供する。Ｍ２Ｍインターフェース７１０は、現在、Ｍ２Ｍサーバ７０２とＤＭサーバ７０３との間の通信を提供するように定義されている。ＤＭプロトコルは、ＤＭサーバ７０３と、Ｍ２Ｍデバイス７０４（例えば、ＡＳＮノード）との間の通信を提供する。各ＡＳＮノード７０４は、ＡＳＮ−ＣＳＥ、ＡＳＮ−ＡＥ、およびＤＭクライアントソフトウェアを含む。例えば、ＡＳＮ−ＣＳＥ７０４ａ内のＤＭＧとＤＭクライアント７０４ｃとは、互いに直接通信することができる。

図７の実施形態のための高レベル呼び出しフローが、図８に図示される。ステップの各々は、ローマ数字、例えば、０、１、２によって表される。ステップ０では、ＩＮ−ＣＳＥおよびＤＭサーバは、ビジネス関係を有し、Ｍ２Ｍインターフェースを経由して互いに通信することができる。さらに、ＡＳＮ１およびＡＳＮ２の各々は、デバイス上で作動するＣＳＥ、ＡＥ、およびＤＭクライアントを有する。ＡＳＮ１およびＡＳＮ２のＤＭＧおよびＤＭクライアントは、互いに通信することができる。

次に、デバイス所有者が、ステップ１においてＭ２Ｍプロトコルを通してＩＮ−ＣＳＥに登録することによってＡＳＮデバイスを管理するためのＭ２ＭアプリケーションＩＮ−ＡＥを動作させる。ステップ２では、複数のＡＳＮノードの各々が、Ｍ２Ｍプロトコルを使用してＩＮ−ＣＳＥに登録する。

ＩＮ−ＡＥは、ステップ３に従って、複数のＡＳＮノードを含むグループを設定するための要求をＩＮ−ＣＳＥに対して開始する。この特徴をサポートするための新しいＩＮ−ＣＳＥ＜ｇｒｏｕｐ＞属性が提案され、以下でさらに詳細に説明されるであろう。さらに、ＩＮ−ＣＳＥ内のＤＭＧは、以下でさらに詳細に説明されるように、ＤＭサーバにおいてデバイスのグループを作成するために、新しいＭ２Ｍインターフェースグループ管理プロシージャを使用する。さらに、ＤＭサーバは、作成されたメッセージでＩＮ−ＣＳＥ内のＤＭＧに応答する。ＩＮ−ＣＳＥは、グループが失敗なく作成されたことをＩＮ−ＡＥに知らせる。

ステップ４では、ＩＮ−ＡＥが、ＤＭコマンドのグループを作成するための要求をＩＮ−ＣＳＥに対して開始する。すなわち、新しいＩＮ−ＣＳＥリソースおよび属性が、以下でさらに詳細に議論されるように、この特徴をサポートするように提案される。ＩＮ−ＣＳＥ内のＤＭＧは、ＤＭサーバにおいてコマンドのグループを作成するために、新しいＭ２Ｍインターフェースグループ管理プロシージャを使用する。ＤＭサーバは、作成されたメッセージでＩＮ−ＣＳＥ内のＤＭＧに応答する。順に、ＩＮ−ＣＳＥは、グループが失敗なく作成されたことをＩＮ−ＡＥに応答する。

ステップ５では、ＩＮ−ＡＥが、グループオングループ動作を行うための要求をＩＮ−ＣＳＥに対して開始する。ここで、この特徴をサポートするための新しいＩＮ−ＣＳＥアドレスおよび属性が提案される。ＩＮ−ＣＳＥ内のＤＭＧは、ＤＭサーバにおいてグループオングループ動作を実行するために、新しいＭ２Ｍインターフェースグループ管理プロシージャを使用する。順に、ＤＭサーバは、確認応答メッセージでＤＭＧに応答する。各ＡＳＮノードは、ＤＭコマンドが失敗なく実行された後、ＤＭサーバに応答するであろう。ＤＭサーバから応答のうちの１つ以上のものを受信すると、ＤＭサーバは、「実行成功」メッセージでＤＭＧに応答する。好ましくは、ＤＭサーバは、ＡＳＮ応答の全てが受信された後、実行成功メッセージで応答するであろう。順に、ＩＮ−ＣＳＥは、グループオングループ動作が成功したことをＩＮ−ＡＥに応答する。

図９に示されるように、＜ｇｒｏｕｐ＞リソースは、以下の子属性、すなわち、（ｉ）ｃｏｍｍｏｎ ａｔｔｒｉｂｕｔｅｓ、（ｉｉ）ｍｅｍｂｅｒＴｙｐｅ、（ｉｉｉ）ＣｕｒｒｅｎｔＮｒＯｆＭｅｍｂｅｒｓ、（ｉｖ）ｍａｘＮｒＯｆＭｅｍｂｅｒｓ、（ｖ）ｍｅｍｂｅｒｓＬｉｓｔ、（ｖｉ）ｃｏｍｍａｎｄｓＬｉｓｔ、（ｖｉｉ）ａｒｇｕｍｅｎｔｓＬｉｓｔ、（ｖｉｉｉ）ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、（ｉｘ）ｒｅｓｐｏｎｓｅＰｅｒｉｏｄ、（ｘ）ｍｅｍｂｅｒｓＡｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＤｓ、（ｘｉ）ｍｅｍｂｅｒＴｙｐｅＶａｌｉｄａｔｅ、（ｘｉｉ）ｃｏｎｓｉｓｔｅｎｃｙＳｔｒａｔｅｇｙ、（ｘｉｉｉ）ｇｒｏｕｐＮａｍｅ、（ｘｉｖ）＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞、および（ｘｖ）＜ｆａｎＯｕｔＰｏｉｎｔ＞、ならびに（ｘｖｉ）ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇを含む。

（グループ管理のためのｏｎｅＭ２Ｍサービス層に対する拡張）
別の実施形態によると、２つのグループ管理拡張が、ｏｎｅＭ２Ｍアーキテクチャに対して行われる。第１の拡張は、ＡＳＮデバイスのグループに複数のコマンドを行うことを可能にする＜ｇｒｏｕｐ＞リソースにおいて提示される。これは、グループオングループ動作と称される。一実施形態では、この動作は、ｏｎｅＭ２Ｍにおいて提供されるｆａｎＯｕｔＰｏｉｎｔアドレス機構に対する拡張、例えば、＜ｆａｎＯｕｔＰｏｉｎｔ＞によって開始され得る。第２の拡張は、ｅｘｅｃＴａｒｇｅｔ属性がグループＩＤを規定することを可能にするために拡張されている＜ｍｇｍｔＣｍｄ＞リソースにおいて導入される。ｅｘｅｃＴａｒｇｅｔに対するこの追加は、管理コマンドをグループのメンバーに展開する。

以下の表２は、ＤＭのより進歩した使用を可能にするための既存のｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースおよび＜ｆａｎＯｕｔＰｏｉｎｔ＞アドレス方式に対する第１の拡張に関連する。具体的には、表２は、例えば、ｃｏｍｍａｎｄｓＬｉｓｔ、ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇ、ａｒｇｕｍｅｎｔｓＬｉｓｔ、ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、およびｒｅｓｐｏｎｓｅＰｅｒｉｏｄを含む新しい属性追加を列挙する。さらに、表２は、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースのためのｍｅｍｂｅｒＴｙｐｅ属性の変更を含む。例えば、ｃｏｍｍａｎｄＬｉｓｔが規定されるときはいつでも、タイプは、＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞等のＤＭ関連リソースでなければならない。この属性は、ｏｎｅＭ２Ｍリソースまたは属性にマップされていないＯＭＡ ＤＭ、ＯＭＡ ＬＷＭ２Ｍ、もしくはＢＢＦ ＣＷＭＰリソースまたは属性にも関連する。そうすることにより、これは、サービス層リソースと管理層リソースとの間の１対１の対応を提供することによって、ＤＭＧによる変換の努力を軽減するであろう。表２では、ＲＷ、ＲＯ、およびＷＯは、それぞれ、読み取り／書き込み、読み取り専用、および書き込み専用を表す。さらに、ＯＡは、表２の「＜ｇｒｏｕｐＡｎｎｃ＞属性」の下の公表された随意を表す。

さらなる実施形態によると、上記の属性が追加されると、ｍｅｍｂｅｒｓＬｉｓｔにおける各エントリーに対するコマンドまたは動作を規定するために、＜ｇｒｏｕｐ＞リソースが作成される。次いで、ｍｅｍｂｅｒＴｙｐｅ属性を＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞に規定し、ｃｏｍｍａｎｄｓＬｉｓｔ属性を規定することによって、コマンドのグループが作成されることができる。

別の実施形態によると、以下のＯＭＡ ＤＭコマンドが、ソフトウェアダウンロードを可能にし、引数、例えば、ａｒｇｕｍｅｎｔｓＬｉｓｔの中で定義されるような＄ａｒｇ＃を使用して、アプリケーションの動作をインストールする。
Ｄｅｌｅｔｅ−＄ａｒｇ１／＄ａｒｇ２／ｎａｍｅ
Ｃｒｅａｔｅ−＄ａｒｇ１／＄ａｒｇ２／ｎａｍｅ
Ｕｐｄａｔｅ−＄ａｒｇ１／＄ａｒｇ２／ＵＲＬ
Ｅｘｅｃｕｔｅ−＄ａｒｇ１／＄ａｒｇ２／Ｉｎｓｔａｌｌ
Ｒｅｔｒｉｅｖｅ−＄ａｒｇ１／＄ａｒｇ２／ａｃｔｉｖｅＳｔａｔｕｓ

この例では、我々は、グループのメンバーのＵＲＩを構築するために使用される、２つの引数、すなわち、＄ａｒｇ１および＄ａｒｇ２を規定している。以下で提供されるような表３は、このグループのためのｃｏｍｍａｎｄｓＬｉｓｔ、ｍｅｍｂｅｒｓＬｉｓｔ、およびａｒｇｕｍｅｎｔｓＬｉｓｔ属性のエントリーを示す。ａｒｇｕｍｅｎｔｓＬｉｓｔ内に、「｛ｇｒｏｕｐ｝」への文字列参照がある。これは、引数が別のグループのメンバーから導出されるべきことを示す。ａｒｇｕｍｅｎｔｓＬｉｓｔの順序付けは、引数を参照するために使用される数字を提供し、＄ａｒｇ１は、｛ｇｒｏｕｐ｝を参照し、＄ａｒｇ２は、ｍｙＡｐｐを参照する。次いで、これらの参照は、＜ｇｒｏｕｐ＞リソース内の他の属性で使用されることができる。ＣＳＥ内のＤＭＧは、ファンアウト要求を生成することに先立って、置換を行うであろう。

さらに別の実施形態によると、コマンドのグループが作成されると、デバイスのグループが、コマンドを適用するために指定され得る。デバイスグループは、通常のｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞プロシージャにおいて作成されるであろう。グループの目的がＤＭサーバを通してデバイスを管理することである場合、ｍｅｍｂｅｒｓＬｉｓｔ ＵＲＩは、［ｄｅｖｉｃｅＩｎｆｏ］＜ｍｇｍｔＯｂｊ＞リソースのｄｅｖｉｃｅＬａｂｅｌ属性を指し示すであろう。これは、グループのｍｅｍｂｅｒｓＴｙｐｅが＜ｍｇｍｔＯｂｊ＞リソースのものであることを要求するであろう。一実施形態では、本願は、グループオングループ動作をトリガするために、ｆａｎＯｕｔＰｏｉｎｔの後に＜ｇｒｏｕｐ＞リソースを規定する能力を含むように、ｆａｎＯｕｔＰｏｉｎｔ仮想リソースのアドレス方式を拡張することを提案する。ｆａｎＯｕｔＰｏｉｎｔをアドレスする２つの既存の方法は、（ｉ）／ｃｓｅＢａｓｅ／…／＜ｇｒｏｕｐ＞／ｆａｎＯｕｔＰｏｉｎｔ、および（ｉｉ）／ｃｓｅＢａｓｅ／…／＜ｇｒｏｕｐ＞／ｆａｎＯｕｔＰｏｉｎｔ／＜ｒｅｌａｔｉｖｅ＿ＵＲＩ＞を含む。

代替として、＜ｒｅｌａｔｉｖｅ＿ＵＲＩ＞は、ｍｅｍｂｅｒｓＬｉｓｔ ＵＲＩによって提供される親リソースの子リソースまたは属性を規定する。グループオングループ動作を可能にするために、本開示は、第３のアドレス方式：／ｃｓｅＢａｓｅ／…／＜ｇｒｏｕｐ＞／ｆａｎＯｕｔＰｏｉｎｔ／＜ａｂｓｏｌｕｔｅ＿ＵＲＩ＞を追加することを提案する。ここで、＜ａｂｓｏｌｕｔｅ＿ＵＲＩ＞は、ｍｅｍｂｅｒＴｙｐｅ＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞の＜ｇｒｏｕｐ＞リソースを指し示す。さらに、ＣＳＥは、依然として要求を展開するであろうが、元の要求の動作を使用する代わりに、＜ａｂｓｏｌｕｔｅ＿ＵＲＩ＞によってそれに指し示されるグループで規定されるコマンドを使用するであろう。

このグループオングループ機構および呼び出しフローは、図１０に示される。ＩＮ−ＡＥは、＜ｍｇｍｔＯｂｊ＞に設定されたｍｅｍｂｅｒＴｙｐｅを用いて、かつ表２で規定される属性を使用して、／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＣｏｍｍａｎｄｓ＜ｇｒｏｕｐ＞リソースを作成する。さらに、どのようにして応答が処理されるべきかを示すために、ここでｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎも規定され得ることが、当業者に想定される。最初に、ステップ０は、ＤＭサーバとＩＮ−ＣＳＥとの間、およびＩＮ−ＡＥとＩＮ−ＣＳＥとの間で、図８において上で説明されるような完成したブートストラップならびに登録プロシージャを説明する。ステップ１では、ＩＮ−ＡＥが、「／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓ」と呼ばれる＜ｇｒｏｕｐ＞リソースを作成することを要求する。要求では、ｍｅｍｂｅｒＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞に設定される。ｃｏｍｍａｎｄＬｉｓｔは、Ｄｅｌｅｔｅ、Ｃｒｅａｔｅ、Ｕｐｄａｔｅ、Ｅｘｅｃｕｔｅ、およびＲｅｔｒｉｅｖｅに設定される。ｍｅｍｂｅｒＬｉｓｔは、＄ａｒｇ１／＄ａｒｇ２／／ｎａｍｅ、＄ａｒｇ１／＄ａｒｇ２／ｎａｍｅ、＄ａｒｇ１／＄ａｒｇ２／ＵＲＬ、＄ａｒｇ１／＄ａｒｇ２／Ｉｎｓｔａｌｌ、＄ａｒｇ１／＄ａｒｇ２／ａｃｔｉｖｅＳｔａｔｕｓに設定される。ａｒｇｕｍｅｎｔｓＬｉｓｔは、＄ｇｒｏｕｐＩＤ、ｍｙＡｐｐに設定される。ステップ１ａでは、ＩＮ−ＣＳＥ内のＤＭＧ７０２ａが、ｍｙＣｏｍｍａｎｄｓ＜ｇｒｏｕｐ＞リソースを作成する。ステップ１ｂでは、ＤＭＧが、コマンドグループを作成するためのグループ管理要求ＡＰＩをＭ２Ｍインターフェースを経由してＤＭサーバに送信する。ステップ１ｃでは、ＤＭＧが、作成された応答をＩＮ−ＡＥに送信する。

ステップ２では、ＩＮ−ＡＥが、／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓと呼ばれるデバイス＜ｇｒｏｕｐ＞を作成するための要求を開始する。グループは、以下の属性を含む：ｍｅｍｂｅｒＴｙｐｅ＝＜ｍｇｍｔＯｂｊ＞、およびｍｅｍｂｅｒｓＬｉｓｔ＝｛／ｉｎ−ｃｓｅ／ｍｎ−ｃｓｅ１／ｎｏｄｅ，／ｉｎ−ｃｓｅ／ｍｎ−ｃｓｅ２／ｎｏｄｅ，／ｉｎ−ｃｓｅ／ｍｎ−ｃｓｅ３／ｎｏｄｅ｝。ＤＭＧ７０２ａは、ステップ２ａにおいてｍｙＤｅｖｉｃｅｓ＜ｇｒｏｕｐ＞を作成する。ステップ２ｂでは、ＤＭＧが、デバイスグループを作成するためのグループ管理要求ＡＰＩをＭ２Ｍインターフェースを経由してＤＭサーバに送信する。ステップ２ｃでは、ＤＭＧが、作成された応答をＩＮ−ＡＥに送信する。ステップ２、２ａ、２ｂ、および２ｃは、ステップ１、１ａ、１ｂ、および１ｃの前、後、または同時に起こり得ることが、当業者に想定される。

次に、ステップ３では、ＩＮ−ＡＥは、画像が記憶されるＵＲＬおよび個々のコマンドのための他の値を含むペイロードを伴って、「／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＣｏｍｍａｎｄｓ／ｆａｎＯｕｔＰｏｉｎｔ／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓ」を作成することをＤＭＧに要求する。ＩＮ−ＡＥは、以下のコマンドを発行することによって、グループオングループ動作をトリガする。この場合のトリガは、絶対ＵＲＩによってｍｅｍｂｅｒＴｙｐｅ＜ｍｇｍｔＯｂｊ＞を伴う＜ｇｒｏｕｐ＞リソースに提供される。この例では、Ｃｒｅａｔｅ動作のみがサポートされる。
ｏｐ：ＣＲＥＡＴＥ
ｆｒ：／ｉｎ−ｃｓｅ／ｉｎ−ａｅ
ｔｏ：／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＣｏｍｍａｎｄｓ／ｆａｎＯｕｔＰｏｉｎｔ／ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓ
ｃｎ：［ペイロードは、画像が記憶されるＵＲＬおよび個々のコマンドのための他の値を含む］
ｇｉｄ：［ｍｙＣｏｍｍａｎｄｓのグループ識別子］。

次に、ステップ４では、ＩＮ−ＣＳＥ内のＤＭＧが、要求をグループオングループ要求として処理する。ＤＭＧは、ｇｒｏｕｐＭｇｍｔＲｅｑ（）を実行することに先立って、ａｒｇｕｍｅｎｔｓＬｉｓｔによって規定される置換を行なう。この例では、引数＄ａｒｇ１は、｛ｇｒｏｕｐ｝として規定され、ＤＭＧが置換を行なうとき、＄ａｒｇ１引数をステップ２で作成されるグループの各メンバーと置換するであろう。＄ａｒｇ２に対して、置換は、比較的単純であり、＄ａｒｇ２をｍｙＡｐｐと置換する。以下の表４は、全ての置換が完了した後の結果を示す。

さらに、ＤＭＧは、ステップ５においてグループオングループ動作を実行するためのｇｒｏｕｐＭｇｍｔＲｅｑ ＡＰＩをＭ２Ｍインターフェースを経由してＤＭサーバに送信する。

ＤＭ目的のためのグループ管理プロシージャの使用も、サービス層リソースに適用され得ることが当業者に想定される。これらの場合において、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞タイプリソースではなく、基本的なＣＲＵＤ動作がグループメンバーに対して行われることができるであろう。グループオングループ動作のみならず、ｃｏｍｍａｎｄｓＬｉｓｔおよびａｒｇｕｍｅｎｔｓＬｉｓｔ属性が使用されることができる。

本願のさらなる側面では、ｏｎｅＭ２Ｍにおけるグループ管理動作に対する拡張は、＜ｍｇｍｔＣｍｄ＞タイプリソースの使用を含み得る。これらのリソースは、ＢＢＦ ＣＷＭＰ（またはＴＲ−０６９）プロトコルで使用されるもの等の管理コマンドを表すように、ＩＮ−ＣＳＥのリソースツリーにおいて作成される。＜ｍｇｍｔＣｍｄ＞リソースは、ＩＮ−ＡＥによって作成されるか、または管理対象エンティティ上のＣＳＥによって作成される。ｃｍｄＴｙｐｅおよびｅｘｅｃＲｅｑＡｒｇｓ属性は、それぞれ、＜ｍｇｍｔＣｍｄ＞に関連付けられるコマンドのタイプおよびコマンド引数を提供する。この情報は、＜ｍｇｍｔＣｍｄ＞を遠隔プロシージャ呼び出し（ＲＰＣ）に変換するために、管理アダプタによって使用されるであろう。＜ｍｇｍｔＣｍｄ＞が規定されると、次いで、ＡＥは、＜ｍｇｍｔＣｍｄ＞リソースを実行し、指示された管理動作を遠隔エンティティに対して行なうことができる。これは、いかなるペイロードも伴わずに＜ｍｇｍｔＣｍｄ＞リソースのｅｘｅｃＥｎａｂｌｅ属性に対する更新を行うことによって為される。要求の「ｔｏ：」フィールドは、管理コマンドが実行される遠隔エンティティのＣＳＥ−ＩＤを提供する。ホスティングＣＳＥが既存のデバイス管理プロトコルを使用して管理コマンドを行なった後、ホスティングＣＳＥは、管理動作を追跡するために＜ｅｘｅｃＩｎｓｔａｎｃｅ＞サブリソースを作成する。次いで、ＡＥは、後に、この＜ｅｘｅｃＩｎｓｔａｎｃｅ＞リソースから状態を読み出すことができる。

さらなる実施形態では、拡張が、グループ動作をサポートするために、＜ｍｇｍｔＣｍｄ＞リソースに追加されることができる。この拡張は、上で説明される「ｅｘｅｃＴａｒｇｅｔ」属性を規定することによって提供される。ｅｘｅｃＴａｒｇｅｔ属性は、＜ｍｇｍｔＣｍｄ＞のための標的を規定することにおいて、属性の有効値としてグループＩＤを含むように拡張されることができる。更新がｅｘｅｃＥｎａｂｌｅに対して行われると、ホストＣＳＥは、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒｓＬｉｓｔ属性で規定されるノード上で＜ｍｇｍｔＣｍｄ＞を実行するであろう。

なおさらなる実施形態では、ｅｘｅｃＴａｒｇｅｔ属性と＜ｇｒｏｕｐ＞リソースとの組み合わせを含む、＜ｍｇｍｔＣｍｄ＞グループ動作のための拡張が説明される。ＡＥは、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒｓＬｉｓｔにおいて＜ｍｇｍｔＣｍｄ＞リソースのグループを規定することができる。ＡＥは、各＜ｍｇｍｔＣｍｄ＞リソース内で、ｅｘｅｃＴａｒｇｅｔ属性を使用して、標的ノードまたはさらにグループＩＤも規定し得る。これは、＜ｍｇｍｔＣｍｄ＞リソースに対して上で規定されるグループオングループ動作を拡張するための代替的手段である。＜ｇｒｏｕｐ＞リソースが規定された後、上で詳細に開示されるｆａｎＯｕｔＰｏｉｎｔアドレス方式を使用して、＜ｍｇｍｔＣｍｄ＞リソースの実行がトリガされる。

図１１に示されるような例示的実施形態によると、＜ｍｇｍｔＣｍｄ＞ｅｘｅｃＴａｒｇｅｔ属性の使用を伴う、グループオングループ動作１１００の実施例が開示されている。２つのグループが、作成される。グループ１ １１１０は、３つのｍｇｍｔＣｍｄリソースのＵＲＩを含み、グループ２ １１２０は、２つのデバイスＵＲＩを含む。＜ｍｇｍｔＣｍｄ＞リソースの各々のｅｘｅｃＴａｒｇｅｔ属性は、グループ２のＵＲＩを含む。グループオングループ動作は、以下の動作、すなわち、Ｕｐｄａｔｅ．．／ｇｒｏｕｐ１／ｆａｎＯｕｔＰｏｉｎｔ／ｅｘｅｃＥｎａｂｌｅによってトリガされる。次いで、ホストＣＳＥは、いかなる順序にも限定されない、以下のような要求を処理するであろう：
グループ１のｍｅｍｂｅｒｓＬｉｓｔを抽出しながら、ホストＣＳＥは、以下の動作を実行する：
Ｕｐｄａｔｅ．．／ｍｇｍｔＣｍｄ１／ｅｘｅｃＥｎａｂｌｅ
Ｕｐｄａｔｅ．．／ｍｇｍｔＣｍｄ２／ｅｘｅｃＥｎａｂｌｅ
Ｕｐｄａｔｅ．．／ｍｇｍｔＣｍｄ３／ｅｘｅｃＥｎａｂｌｅ

ＭｇｍｔＣｍｄ１のｅｘｅｃＴａｒｇｅｔは、グループ２のＵＲＩを規定する。これは、上で規定されるように、ｍｇｍｔＣｍｄ１がｄｅｖ１およびｄｅｖ２上で実行されることをもたらすであろう。同様に、ｍｇｍｔＣｍｄ２のｅｘｅｃＴａｒｇｅｔも、グループ２のＵＲＩを規定する。これは、上で規定されるように、ｍｇｍｔＣｍｄ２がｄｅｖ１およびｄｅｖ２上で実行されることをもたらすであろう。ＭｇｍｔＣｍｄ３のｅｘｅｃＴａｒｇｅｔも、グループ２のＵＲＩを規定する。これは、上で規定されるように、ｍｇｍｔＣｍｄ３がｄｅｖ１およびｄｅｖ２上で実行されることをもたらすであろう。注目すべきは、ｍｇｍｔＣｍｄｓ１、２、および３の各成功した実行に対して、関連＜ｅｘｅｃＩｎｓｔａｎｃｅ＞リソースが、対応するデバイスに対して作成される。これは、３つのｍｇｍｔＣｍｄリソースの各々の下のｅｘｅｃＩｎｓｔａｎｃｅ１およびｅｘｅｃＩｎｓｔａｎｃｅ２リソースとして図１１に示される。これらの＜ｅｘｅｃＩｎｓｔａｎｃｅ＞リソースのｅｘｅｃＴａｒｇｅｔ属性は、＜ｍｇｍｔＣｍｄ＞が実行されたグループ２のメンバーＩＤを指し示す。これらの＜ｅｘｅｃＩｎｓｔａｎｃｅ＞リソースは、グループオングループ要求を処理したホストＣＳＥによって作成される。

（Ｍ２Ｍインターフェースグループ管理プロシージャ）
ＤＭグループ管理プロシージャは、動作がｍｅｍｂｅｒＴｙｐｅ＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞を伴うｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースに対して行われるときはいつでも、トリガされることができる。本願において上で説明されるように、これらの要求は、ＤＭＧによって処理され、次いで、ＤＭＧは、任意の引数の置換を行い、結果を適切なグループ管理ＡＰＩに変換するであろう。３つの主要なグループ動作は、以下である。

デバイスグループ動作：これらの動作は、ユーザがＤＭを行うデバイスのグループを操作する（ＣＲＵＤ）ことを可能にする。このタイプのグループに関連付けられるｍｅｍｂｅｒＴｙｐｅは、サービス層指向グループ動作と区別するための＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞である。これは、要求が処理のためにＤＭＧに転送されるべきであることをＣＳＥに示すであろう。

コマンドグループ動作：これらの動作は、ユーザがデバイスまたはデバイスのグループに対して行うコマンドのグループ（ＤＭであるかどうか）を操作する（ＣＲＵＤ）ことを可能にする。このタイプのグループに関連付けられるｍｅｍｂｅｒＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞であり、ｃｏｍｍａｎｄｓＬｉｓｔ属性は、サービス層指向グループ動作と区別するように規定されなければならない。これは、要求が処理のためにＤＭＧに転送されるべきであることをＣＳＥに示すであろう。

グループオングループ動作：この動作は、一連のコマンドがデバイスのグループに対して行われるグループオングループ動作をユーザが開始することを可能にする。動作は、ｆａｎＯｕｔＰｏｉｎｔのための新しいアドレス方式を使用することによってトリガされ、新しいアドレス方式において、ｍｅｍｂｅｒＴｙｐｅ＜ｍｇｍｔＯｂｊ＞の＜ｇｒｏｕｐ＞リソースを指し示す絶対ＵＲＩがｆａｎＯｕｔＰｏｉｎｔ仮想リソースの後に付加される。

図１２は、グループ管理プロシージャが動作する方法を図示する例示的呼び出しフローを示す。図１２のステップは、ローマ数字によって示される。ここでは、２つのＡＳＮノードが、ＩＮ−ＣＳＥを通してＩＮ−ＡＥによって管理される。

最初に、上記の図８に示される登録およびブートストラッププロシージャが、ステップ０で採用される。次に、ステップ１では、ＩＮ−ＡＥが、ｍｅｍｂｅｒＴｙｐｅ＝＜ｍｇｍｔＯｂｊ＞を伴うｍｙＤｅｖｉｃｅｓ＜ｇｒｏｕｐ＞リソースを作成することを要求し、ｍｅｍｂｅｒｓＬｉｓｔ ＵＲＩは、［ｄｅｖｉｃｅＩｎｆｏ］リソースのｄｅｖｉｃｅＬａｂｅｌ属性を指し示す。次いで、ＤＭＧは、ステップ２で必要であれば、最初に置換を行うことによって要求を処理する。ａｒｇｕｍｅｎｔｓＬｉｓｔ属性が規定され、（＄ａｒｇ＃によって表される）引数参照が使用される場合、ＤＭＧは、見出される各引数参照の代わりにａｒｇｕｍｅｎｔｓＬｉｓｔの中の値を使う。次に、ＤＭＧは、ステップ３に従って上で説明されるようにｇｒｏｕｐＭｇｍｔＲｅｑ（）ＡＰＩを呼び出す。この場合、要求のタイプは、デバイスグループに対して０である。ステップ４では、ＤＭサーバが、成功応答コードで応答する。ステップ５では、ＩＮ−ＣＳＥが、作成された応答をＩＮ−ＡＥに送信する。

次に、ＩＮ−ＡＥは、ｍｅｍｂｅｒＴｙｐｅ＝＜ｍｇｍｔＯｂｊ＞を伴うｍｙＣｍｄｓ＜ｇｒｏｕｐ＞リソースを作成することを要求し、ｃｏｍｍａｎｄｓＬｉｓｔ属性の中でコマンドのリストを規定する（ステップ６）。ＤＭＧは、必要であれば、最初に置換を行うことによってコマンドグループ要求を処理する（ステップ７）。ａｒｇｕｍｅｎｔｓＬｉｓｔ属性が規定され、（＄ａｒｇ＃によって表される）引数参照が使用される場合、ＤＭＧは、見出される各引数参照の代わりにａｒｇｕｍｅｎｔｓＬｉｓｔの中の値を使う。ステップ８では、ＤＭＧが、表５内のｇｒｏｕｐＭｇｍｔＲｅｑ（）ＡＰＩを呼び出す。この場合、要求のタイプは、コマンドグループに対して１である。ＤＭサーバは、成功応答コードで応答する（ステップ９）。さらに、ＩＮ−ＣＳＥは、作成された応答をＩＮ−ＡＥに送信する（ステップ１０）。ステップ６−１０は、ステップ１−５の前、後、または同時に起こり得ることが想定される。

さらなる実施形態によると、ＩＮ−ＡＥは、以下のＵＲＩを標的にすることによって、グループオングループ動作を開始する：ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＣｍｄｓ／ｆａｎＯｕｔＰｏｉｎｔ／ｉｎ−ｃｓｅ−ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓ（ステップ１１）。絶対ＵＲＩは、ｉｎ−ｃｓｅ／ｉｎ−ａｅ／ｍｙＤｅｖｉｃｅｓである。次に、ＤＭＧは、必要であれば、最初に置換を行うことによって要求を処理する（ステップ１２）。ａｒｇｕｍｅｎｔｓＬｉｓｔ属性が規定され、（＄ａｒｇ＃によって表される）引数参照が使用される場合、ＤＭＧは、見出される各引数参照の代わりにａｒｇｕｍｅｎｔｓＬｉｓｔの中の値を使う。次に、ＤＭＧは、上記のｇｒｏｕｐＭｇｍｔＲｅｑ（）ＡＰＩを呼び出す（ステップ１３）。この場合、要求のタイプは、グループオングループ動作に対して２であり、ＲｓｐＩｎｄｉｃａｔｏｒは、グループメンバーからの個々の応答を要求する１に設定される。ステップ１４では、ＤＭサーバが、ＡＳＮ１上で作動するＤＭクライアントとＤＭセッションを確立し、ｍｙＣｍｄｓグループ内でコマンドを実行する。次に、ＤＭサーバは、成功に対するコード＝０およびどのメンバーから応答が受信されたかを示すＧｒｐＭｅｍｂｅｒ＝ＡＳＮ１を伴う応答を送信する。ＩＮ−ＣＳＥは、成功応答をＩＮ−ＡＥに送信する（ステップ１６）。

ステップ１７−１９は、ステップ１４−１６と実質的に同等である。すなわち、ＤＭサーバは、ＡＳＮ２上で作動するＤＭクライアントとＤＭセッションを確立し、ｍｙＣｍｄｓグループ内でコマンドを実行する（ステップ１７）。次いで、ＤＭサーバは、成功に対するコード＝０およびどのメンバーから応答が受信されたかを示すＧｒｐＭｅｍｂｅｒ＝ＡＳＮ２を伴う応答を送信する（ステップ１８）。さらに、ＩＮ−ＣＳＥは、成功応答をＩＮ−ＡＥに送信する（ステップ１９）。

（Ｍ２Ｍインターフェースグループ管理ＡＰＩ）
さらに別の実施形態によると、ＤＭＧがａｒｇｕｍｅｎｔｓＬｉｓｔで見出される置換を完了すると、次いで、要求をｇｒｏｕｐＭｇｍｔＲｅｑ（）ＡＰＩ呼び出しに変換する。例示的形式が、表５で提供される。ＲｓｐＩｎｄｉｃａｔｏｒは、個々のデバイスからの応答がどのようにして処理されるかを規定することを可能にする。これは、処理待ち時間が非常に変化しやすく、要求側がコマンドの状態に対してリアルタイム更新を得たい場合に有用である。ある場合には、デバイスは、スリープしていることもあり、コマンドが実行され得る前に長い時間を要し得る。この場合に個々の応答を受信する能力を有することは、どのデバイスが動作を完了したかをサービス層が把握するために有益である。

ＤＭサーバが返送する応答の例が、表６で提供される。個々の応答が要求されるとき（ＲｓｐＩｎｄｉｃａｔｏｒ＞０）、ＤＭサーバは、表６で規定されるようなグループメンバーを示さなければならない。これは、要求側が応答をメンバーに相関させることを可能にする。

（管理層更新）
なおさらなる実施形態では、管理層アーキテクチャ内の管理層更新が説明される。ここでは、Ｍ２Ｍインターフェースおよび拡張型グループ管理プロシージャをサポートするために、更新が必要とされる。新しいＭ２Ｍインターフェースグループ管理プロシージャに対する応答メッセージ形式が、上で詳細に説明されている。拡張型グループ管理プロシージャのサポートは、以下でさらに詳細に説明される。

図１３は、本開示で規定される拡張型グループ管理動作をサポートするために使用され得る、ＯＭＡ ＤＭプロトコルにおける提案されたグループＭＯの例示的実施形態を示す。ＭＯ内で、３つの主要内部ノード、すなわち、ＣｏｍｍａｎｄＧｒｏｕｐ、ＤｅｖｉｃｅＧｒｏｕｐ、およびＧｒｏｕｐＳｔａｔｕｓが定義される。ＣｏｍｍａｎｄＧｒｏｕｐノードは、コマンドのグループを構成することを提供し、１に設定されたｇｒｏｕｐＭｇｍｔＲｅｑのタイプパラメータにマップされる。このタイプを伴う任意の要求は、このノード内に子リソースを作成するであろう。ＤｅｖｉｃｅＧｒｏｕｐノードは、デバイスを一緒にグループ化する能力を提供し、０に設定されたｇｒｏｕｐＭｇｍｔＲｅｑのタイプパラメータにマップされる。要求がデバイスのグループを作成するために行われるとき、子ノードが、この内部ノードの下に作成される。最終的に、ＧｒｏｕｐＳｔａｔｕｓノードが、グループオングループ動作を処理するためにＤＭサーバによって使用される。ＤＭサーバは、ＲｓｐＩｎｄｉｃａｔｏｒ設定に基づいて状態を提供するために、ＧｒｏｕｐＳｔａｔｕｓ内に子ノードを作成し、各状態が得られると状況を保存するであろう。グループ管理要求全体がサービス提供された後、子ノードは削除されるであろう。

図１４は、図１２からの管理動作のグループを図示する。ステップは、以下で提供される。ステップ１（図示せず）では、ＩＮ−ＣＳＥが、ＩＮ−ＡＥからのデバイスグループ要求を処理する。次に、ＩＮ−ＣＳＥ内のＤＭＧは、デバイスグループ要求が行われたことを示すｔｙｐｅ＝０を伴うｇｒｏｕｐＭｇｍｔＲｅｑを送信する（ステップ２）。この要求は、図１４に図示される「２．」と「ｍｙＤｅｖｉｃｅｓ」との間の線によって示されるように、ｍｙＤｅｖｉｃｅｓノードおよび全てのその子ノードを作成する。例示的要求が、表７において以下に示される。

ステップ３では、ＤＭサーバが、成功応答コードをＩＮ−ＣＳＥに提供する。次に、ＩＮ−ＣＳＥは、ステップ４においてＩＮ−ＡＥ（図示せず）からのコマンドグループ要求を処理する。その後、ＩＮ−ＣＳＥ内のＤＭＧは、コマンドグループ要求が行われたことを示すｔｙｐｅ＝１を伴うｇｒｏｕｐＭｇｍｔＲｅｑを送信する（ステップ５）。この要求は、図１４に図示される「５．」と「ｍｙＣｏｍｍａｎｄｓ」との間の線によって示されるように、ｍｙＣｏｍｍａｎｄｓノードおよび全てのその子ノードを作成する。例示的要求が、表８において以下に示される。

次に、ＤＭサーバは、成功応答コードをＩＮ−ＣＳＥに提供する（ステップ６）。ＩＮ−ＣＳＥは、ステップ７においてＩＮ−ＡＥ（図示せず）からのグループオングループ要求を処理する。後に、ＩＮ−ＣＳＥ内のＤＭＧは、グループオングループ要求が行われ、利用可能であるときはいつでも個々の応答が要求されることを示すｔｙｐｅ＝２およびＲｓｐＩｎｄｉｃａｔｏｒ＝１を伴うｇｒｏｕｐＭｇｍｔＲｅｑを送信する（ステップ８）。この要求は、ＧｒｐＬａｂｅｌｓパラメータにおいて２つの標識、すなわち、ｍｙＣｏｍｍａｎｄｓおよびｍｙＤｅｖｉｃｅｓを規定する。次いで、ＤＭサーバは、図１４に図示される「８．」と「ｍｙＧｒｐＳｔａｔ」との間の線によって示されるように、ｍｙＧｒｐＳｔａｔノードおよび全てのその子ノードを作成するであろう。ｍｙＧｒｐＳｔａｔノードは、各デバイスの実行状態を記録するために、．／ＧｒｏｕｐＭＯ／ＧｒｏｕｐＳｔａｔｕｓ／ｍｙＧｒｐＳｔａｔｕｓ／Ｄｅｖｉｃｅｓの下に２つの子ノードを含む。例示的要求が、表９において以下に示される。

さらに、コマンドｃｍｄ１およびｃｍｄ２が交換されるＤＭセッションが、ＡＳＮ１とＤＭサーバとの間に確立される（ステップ９）。ＤＭセッションが完了したとき、実行が成功した場合、．／ＧｒｏｕｐＭＯ／ＧｒｏｕｐＳｔａｔｕｓ／ｍｙＧｒｐＳｔａｔｕｓ／Ｄｅｖｉｃｅｓ／ｄｅｖ１／ｓｔａｔｕｓノードは、ＤＭサーバによって「Ｐａｓｓ」に設定される。

その後、ＤＭサーバは、図１４に示されるような「１０．」からの線によって示されるように、ＡＳＮ１が失敗なく完了したことを示すようにｇｒｏｕｐＭｇｍｔＲｓｐ（）メッセージをＩＮ−ＣＳＥに送信する。

その一方で、別のＤＭセッションが、ＡＳＮ２とＤＭサーバとの間に確立される（ステップ１１）。もう一度、管理コマンドが交換される。ＤＭセッションが完了したとき、実行が成功した場合、．／ＧｒｏｕｐＭＯ／ＧｒｏｕｐＳｔａｔｕｓ／ｍｙＧｒｐＳｔａｔｕｓ／Ｄｅｖｉｃｅｓ／ｄｅｖ２／ｓｔａｔｕｓノードは、ＤＭサーバによって「Ｐａｓｓ」に設定される。

次いで、ＤＭサーバは、図１４に示されるような「１２．」からの線によって示されるように、ＡＳＮ１が失敗なく完了したことを示すようにｇｒｏｕｐＭｇｍｔＲｓｐ（）メッセージをＩＮ−ＣＳＥに送信する（ステップ１２）。

（ＯＭＡ ＬＷＭ２Ｍグループ管理サポート）
なおさらなる実施形態によると、グループ管理サポートが、ＬＷＭ２Ｍプロトコルに対して表１０および表１１で見出されることができる。これらの表の設計は、本質的に平坦であり、階層を限定するように設計されているＬＷＭ２Ｍオブジェクトの精神で従う。結果として、デバイスグループおよびコマンドグループは、オブジェクトＩＤ＝１０を伴うＧｒｏｕｐオブジェクトに組み込まれ、ＧｒｏｕｐＳｔａｔｕｓオブジェクトは、オブジェクトＩＤ＝１１を伴うグループオングループ動作の状態を含む。これら２つのオブジェクトは、ＬＷＭ２Ｍサーバのためにのみ利用可能であり、Ｍ２Ｍインターフェースを経由したグループ通信をサポートするために使用される。

上記のリソースの作成および更新は、本明細書に説明されるようなＯＭＡ ＤＭの場合と同様に起こる。

（ＢＢＦ ＣＷＭＰグループ管理サポート）
図１２は、本開示で提案される拡張型グループ管理プロシージャをサポートするために使用され得る、ＢＢＦ ＣＷＭＰプロファイルの例示的実施形態を示す。プロファイルは、ｃｏｍｍａｎｄｇｒｏｕｐ、ｄｅｖｉｃｅｇｒｏｕｐ、およびｇｒｏｕｐｓｔａｔｕｓに１つずつ、３つの主要セクションに分離される。このプロファイルは、コマンドおよびデバイスのグループを管理する能力を提供するために、ＡＣＳ上でホストされるであろう。次いで、グループ状態データモデルは、必要であれば個々のコマンドおよびデバイスの状態を提供するであろう。グループオングループ動作は、．ｇｒｏｕｐ．ｇｒｏｕｐｓｔａｔｕｓ．｛ｉ｝エントリーの作成をトリガし、要求が完全にサービス提供されるまで維持されるであろう。

上記のリソースの作成および更新は、上で説明されるようなＯＭＡ ＤＭの場合と同様に起こる。

本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能記命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図８、１０、および１２による、複数の呼び出しフローにおいて上記で開示されるような１つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、ＩＮ−ＣＳＥ、ＤＭサーバ、およびＡＳＮデバイスを含むデバイスで採用される、上で開示されるプロセッサ等のプロセッサによって実行され得る。

システムおよび方法が、現在、具体的側面と見なされるものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正および同様の配列を網羅することが意図され、その範囲は、全てのそのような修正および同様の構造を包含するよう、最も広い解釈を与えられるはずである。本開示は、以下の請求項のありとあらゆる側面を含む。

Claims (20)

1. デバイス上でグループオングループ動作を行うためのコンピュータ実装装置であって、前記装置は、不揮発性メモリとプロセッサとを備え、前記不揮発性メモリは、コンピュータ実行可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
   前記グループオングループ動作を開始するための要求を受信するステップであって、前記要求は、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、ステップと、
   前記要求を処理するステップと、
   前記デバイス上で前記コマンドを実行するためのグループ管理要求ＡＰＩを管理サーバに送信するステップと
   を前記装置に行わせる、装置。
2. 前記プロセッサは、前記デバイスによる前記コマンドの実行を示す応答を前記管理サーバから受信する命令を実行する、請求項１に記載の装置。
3. デバイスグループを作成するためのグループ管理要求ＡＰＩを前記管理サーバに送信することをさらに含む、請求項１に記載の装置。
4. コマンドグループを作成するためのグループ管理要求ＡＰＩを前記管理サーバに送信することをさらに含む、請求項３に記載の装置。
5. 前記デバイスグループおよび前記コマンドグループが作成されたという返信を前記管理サーバから受信することと、
   前記デバイスグループおよび前記コマンドグループが作成されたという返信をデバイス所有者に送信することと
   をさらに含む、請求項４に記載の装置。
6. 前記コマンドグループは、ｍｅｍｂｅｒＴｙｐｅ、ｍｅｍｂｅｒｓＬｉｓｔ、ｃｏｍｍａｎｄｓＬｉｓｔ、ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇ、ａｒｇｕｍｅｎｔｓＬｉｓｔ、ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、ｒｅｓｐｏｎｓｅＰｅｒｉｏｄ、および、これらの組み合わせから選択されるグループリソースを含む、請求項４に記載の装置。
7. 前記ｍｅｍｂｅｒＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞または＜ｍｇｍｔＣｍｄ＞である、請求項６に記載の装置。
8. 前記＜ｍｇｍｔＣｍｄ＞は、ｅｘｅｃＴａｒｇｅｔ、ｅｘｅｃＩｎｓｔａｎｔ、および、これらの組み合わせから選択される属性を含む、請求項７に記載の装置。
9. 前記装置は、サーバである、請求項１に記載の装置。
10. Ｍ２Ｍインターフェースにおいてグループオングループ動作が行われるデバイスのグループを確立するためのコンピュータ実装装置であって、前記装置は、不揮発性メモリとプロセッサとを備え、前記不揮発性メモリは、コンピュータ実行可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
    前記デバイスのグループを管理するための登録要求を受信するステップと、
    デバイスグループを作成するための要求を受信するステップと、
    前記受信された要求を実行することにより、前記デバイスのグループのための前記デバイスグループを作成するステップと
    を前記装置に行わせる、装置。
11. 前記プロセッサは、前記デバイスのグループから登録通知を受信するようにさらに構成されている、請求項１０に記載の装置。
12. Ｍ２Ｍインターフェースにおいてグループオングループ動作が行われるデバイスのグループを確立するためのコンピュータ実装方法であって、
    前記デバイスのグループを管理するための登録要求を受信することと、
    前記デバイスのグループから登録通知を受信することと、
    デバイスグループを作成するための要求を受信することと、
    前記受信された要求を実行することにより、前記デバイスのグループのための前記デバイスグループを作成することと
    を含む、方法。
13. コマンドグループを作成するための要求を受信することと、
    前記受信された要求を実行することにより、前記デバイスのグループのための前記コマンドグループを作成することと
    をさらに含む、請求項１２に記載の方法。
14. 前記デバイスグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
    前記コマンドグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと
    をさらに含む、請求項１３に記載の方法。
15. 前記デバイスグループおよび前記コマンドグループが作成されたという返信を前記管理サーバから受信することと、
    前記デバイスグループおよび前記コマンドグループが作成されたという返信をデバイス所有者に送信することと
    をさらに含む、請求項１４に記載の方法。
16. 前記コマンドグループは、ｍｅｍｂｅｒＴｙｐｅ、ｍｅｍｂｅｒｓＬｉｓｔ、ｃｏｍｍａｎｄｓＬｉｓｔ、ｃｏｍｍａｎｄＢｌｏｃｋｉｎｇ、ａｒｇｕｍｅｎｔｓＬｉｓｔ、ｒｅｓｐｏｎｓｅＡｇｇｒｅｇａｔｉｏｎ、ｒｅｓｐｏｎｓｅＰｅｒｉｏｄ、および、これらの組み合わせから選択されるグループリソースを含む、請求項１３に記載の方法。
17. Ｍ２Ｍインターフェースにおいてデバイス上でグループオングループ動作を行うためのコンピュータ実装方法であって、
    前記グループオングループ動作を開始するための要求を受信することであって、前記要求は、ユニフォームリソースインジケータにおいて定義されているグループリソースのコマンドを含む、ことと、
    前記要求を処理することと、
    前記デバイス上で前記コマンドを実行するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
    前記デバイスによる前記コマンドの実行状態を示す応答を前記管理サーバから受信することと
    を含む、方法。
18. 前記処理するステップは、前記グループリソースのａｒｇｕｍｅｎｔＬｉｓｔの中に配置されている引数参照を値に置換することを含む、請求項１７に記載の方法。
19. 前記ユニフォームリソースインジケータは、前記要求を展開するための絶対ユニフォームリソース識別子を含む、請求項１７に記載の方法。
20. デバイスグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと、
    コマンドグループを作成するためのグループ管理要求ＡＰＩを管理サーバに送信することと
    をさらに含む、請求項１７に記載の方法。