JP2014506764A - マシンツーマシン（ｍ２ｍ）エンティティを管理するシステム、方法、および装置 - Google Patents

Abstract

マシンツーマシン（Ｍ２Ｍ）エンティティを管理するシステム、方法、および装置が開示される。本発明は、Ｍ２Ｍ環境でＭ２Ｍエンティティを管理するための１つまたは複数の管理レイヤを実装することを含むことができる方法が含む。この方法はまた、複数の管理レイヤを使用してＭ２Ｍエリアネットワークを管理することを含んでもよく、およびＭ２Ｍエリアネットワークは、１つまたは複数のＭ２Ｍエンドデバイスを含んでもよい。Ｍ２Ｍエンドデバイスは、例えばＭ２Ｍゲートウェイおよび／またはＭ２Ｍデバイスを含んでもよい。管理レイヤは、アプリケーション管理レイヤ、サービス管理レイヤ、ネットワーク管理レイヤ、およびデバイス管理レイヤを含んでもよい。管理レイヤは、Ｍ２Ｍエンティティの構成管理、障害管理、および性能管理を提供してもよい。

Description

本出願は、通信に関し、特に、マシンツーマシン（「Ｍ２Ｍ」）通信に関する。

本出願は、（ｉ）２０１１年２月１１日に出願された、「Enhanced Gateway-Based Machine-To-Machine (M2M) Device Management」と題する、米国（ＵＳ）仮特許出願第６１／４４１，９１１号（整理番号 ＩＤＣ−１０９２８ＵＳ０１）、（ｉｉ）２０１１年６月１４日に出願された、「Data Model For Managing M2M Area Networks and M2M Devices behind the M2M Gateway」と題する米国仮特許出願第６１／４９６，８１２号（整理番号ＩＤＣ−１１０７２ＵＳ０１）、（ｉｉｉ）２０１１年６月２４日に出願された、「Data Model For Managing M2M Area Networks and M2M Devices behind the M2M Gateway」と題する米国仮特許出願第６１／５００，７９８号（整理番号ＩＤＣ−１１０７７ＵＳ０１）、（ｉｖ）２０１１年２月１８日に出願された、「Machine-to-Machine (M2M) Remote Entity Management」と題する米国仮特許出願第６１／４４４，３２３号（整理番号ＩＤＣ−１０９３０ＵＳ０１）、（ｖ）２０１１年３月１４日に出願された、「Machine-to-Machine (M2M) Remote Entity Management」と題する米国仮特許出願第６１／４５２，４２２号（整理番号ＩＤＣ−１０９５４ＵＳ０１）、（ｖｉ）２０１１年５月１３日に出願された、「Remote Entity Management for Machine-to-Machine (M2M) Communications」と題する米国仮特許出願第６１／４８５，６３１号（整理番号ＩＤＣ−１１０４７ＵＳ０１）、（ｖｉｉ）２０１１年６月２４日に出願された、「Remote Entity Management for Machine-to-Machine (M2M) Communications」と題する米国仮特許出願第６１／５０１、０４６号（整理番号ＩＤＣ−１１０７８ＵＳ０１）、および（ｖｉｉｉ）２０１１年７月１５日に出願された、「Remote Entity Management for Machine-to-Machine (M2M) Communications」と題する米国仮特許出願第６１／５０８，５６４号（整理番号ＩＤＣ−１１０９８ＵＳ０１）に関連し、それらの利益および／または優先権を主張する。上述した各米国仮特許出願は参照により本明細書に組み込まれる。

マシンツーマシン（「Ｍ２Ｍ」）通信とは、かかるＭ２Ｍ通信を介して、スマートメータ、ホームオートメーション、ｅＨｅａｌｔｈ、フリート管理などの様々なアプリケーション（「Ｍ２Ｍ」アプリケーション）を実行するための情報を送信し、受信し、または交換するように構成された、マシンと呼ばれるデバイスによって行われ、当該デバイス間で行われ、および／または当該デバイスが共同で行う通信のカテゴリを言う。一般に、様々なアプリケーションの実行、そしてそのような実行に伴うＭ２Ｍ通信は、Ｍ２Ｍ通信の発信をトリガ、起動、および／または発生させるための人間の介在を必要とせずに、マシンによって行われる。理解されるように、Ｍ２Ｍアプリケーションの成功した実装と普及は、様々なエンティティによって製造および運用される場合がある様々なマシンツーマシンの相互動作性を保証する（例えば保証するための要件を定義する）基準が業界全体で受け入れられることに依存する可能性が高い。

添付図面と併せて例として与えられる以下の発明を実施するための形態から、より詳細な理解が得られるであろう。それらの図面における図は、詳細な説明と同様に例示的なものである。したがって、図および詳細な説明は制限的なものと見なすべきでなく、かつ他の同様に有効な例が可能であり、および予想される。さらに、図中の同一の参照符号は同一の要素を指す。

マシンツーマシン（Ｍ２Ｍ）通信および／または動作に関する実施形態を含む１つまたは複数の実施形態を実装またはその他の他の方法で実施することができるシステムの例を示すブロック図である。 マシンツーマシン（Ｍ２Ｍ）通信および／または動作に関する実施形態を含む１つまたは複数の実施形態を実装またはその他の他の方法で実施することができるシステムの例を示すブロック図である。 マシンツーマシン（Ｍ２Ｍ）通信および／または動作に関する実施形態を含む１つまたは複数の実施形態を実装またはその他の他の方法で実施することができるシステムの例を示すブロック図である。 リモートエンティティ管理（ＲＥＭ）を実行するための機能的アーキテクチャを定義する論理管理レイヤの例示的なセットを示すブロック図である。 管理レイヤのセットおよびそれらの機能に従ったリソース構造を備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワークを示すブロック図である。 管理レイヤのセットおよびそれらの機能に従ったリソース構造を備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワークを示すブロック図である。 管理レイヤのセットおよびそれらの機能に従ったリソース構造を備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワークを示すブロック図である。 管理オブジェクト（ｍｇｍｔＯｂｊｓ）リソースを備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワークを示すブロック図である。 管理オブジェクト（ｍｇｍｔＯｂｊｓ）リソースを備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワークを示すブロック図である。 ｘＲＥＭを実行するためのクライアント−サーバモデルの図を示すブロック図である。 複数の異なる管理プロトコルを使用するｘＲＥＭをサポートする、トンネルベースのアプローチを示すブロック図である。 ＲＥＭに対して使用する管理プロトコルのタイプを判定するための例示的なフロー７００、７３０、および７６０をそれぞれ示すフローチャートである。 ＲＥＭに対して使用する管理プロトコルのタイプを判定するための例示的なフロー７００、７３０、および７６０をそれぞれ示すフローチャートである。 ＲＥＭに対して使用する管理プロトコルのタイプを判定するための例示的なフロー７００、７３０、および７６０をそれぞれ示すフローチャートである。 ｘＲＥＭに対する管理プロトコルのタイプをネゴシエーションし、および／またはデバイスに通知するプロシージャを示すメッセージフローチャートである。 ｘＲＥＭに対する管理プロトコルのタイプをネゴシエーションし、および／またはデバイスに通知するプロシージャを示すメッセージフローチャートである。 ｘＲＥＭに対する管理プロトコルのタイプをネゴシエーションし、および／またはデバイスに通知するプロシージャを示すメッセージフローチャートである。 ｘＲＥＭに対する管理プロトコルのタイプをネゴシエーションし、および／またはデバイスに通知するプロシージャを示すメッセージフローチャートである。 リソースアクセス履歴の例示的構造の図である。 「メソッド」に基づいて構造化されたリソースアクセス履歴に対する例示的構造の図である。 「メソッド」および「要求者ＩＤ」に基づいて構造化されたリソースリソースアクセス履歴の例示的構造の図である。 管理権限委譲（委譲者により開始される）についてのプロシージャのメッセージフローチャートである。 管理権限の委譲（デバイスにより開始される）についてのプロシージャの例示的なメッセージフローチャートである。 管理権限委譲（デバイス側から委譲先に直接開始される）についての例示的なメッセージフローチャートである。 管理権限の委譲（委譲先により開始される）についての例示的なメッセージフローチャートである。 管理権限の委譲（ゲートウェイをプロキシとする）についての例示的なメッセージフローチャートである。 管理権限の委譲（デバイスからゲートウェイへの委譲）についての例示的なメッセージフローチャートである。 管理権限の委譲についての例示的なプロシージャの図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドの例示的構造を示すブロック図である。 リソースコマンドインスタンスの例示的構造を示すブロック図である。 リソースコマンドインスタンスの例示的構造を示すブロック図である。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 リソースコマンドのｘＲＥＭについての例示的なメッセージフローを示すメッセージフローチャートである。 ＯＭＡ ＧｗＭＯ「透過」モードを利用することによりＭ２Ｍ ＧＷ（Ｇ’）を介してＤタイプＥＴＳＩ Ｍ２Ｍデバイスを管理するための例示的アーキテクチャを示すブロック図である。 ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭについての例示的アーキテクチャを示すブロック図である。 ＯＭＡ ＧｗＭＯ １．０を利用するための例示的アーキテクチャを示すブロック図である。 ｘＲＥＭの例示的アーキテクチャを示すブロック図である。 ＯＭＡ ＧｗＭＯ １．０を利用するための例示的アーキテクチャを示すブロック図である。 ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭの例示的アーキテクチャを示すブロック図である。 ＯＭＡ ＧｗＭＯ １．０を利用するための例示的アーキテクチャを示すブロック図である。 本開示の実施形態に従ったＥＴＳＩ Ｍ２Ｍ ｘＲＥＭの例示的アーキテクチャを示すブロック図である。 ＯＭＡ ＧｗＭＯを利用した、ＧＷベースのデバイス管理の例を示すブロック図である。 ＯＭＡ ＤＭとＭ２Ｍ ＧＷとを部分的に密に統合するための例示的アーキテクチャを示すブロック図である。 ＯＭＡ ＤＭとＭ２Ｍ ＧＷとを疎に統合する場合の例示的アーキテクチャを示すブロック図である。 ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏについての例示的なリソース構造を示すブロック図である。 ａｒｅａＮｗｋＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 図３８ＡのａｒｅａＮｗｋＩｎｓｔａｎｃｅに対する６ＬｏＷＰＡＮの下位リソースの詳細についての例示的リソース構造を示すブロック図である。 ａｒｅａＮｗｋＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙについての例示的なリソース構造を示すブロック図である。 ｄｅｖｉｃｅＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｄｅｖｉｃｅＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐについての例示的なリソース構造を示すブロック図である。 ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐについての例示的なリソース構造を示すブロック図である。 ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓについての例示的なリソース構造を示すブロック図である。 ｅｔｓｉａｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓについての例示的なリソース構造を示すブロック図である。 ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｅｓｉＳｅｎｓｏｒについての例示的なリソース構造を示すブロック図である。 ｓｅｎｓｏｒＩｎｓｔａｎｃｅについての例示的なリソース構造を示すブロック図である。 ｘＲＥＭを実行するためのシステムの例示的アーキテクチャのブロック図である。 １つまたは複数の開示される実施形態を実装することができる例示的通信システムの図である。 図４８Ａに示す通信システム内で使用することができる例示的無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図４８Ａに示す通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図４８Ａに示す通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図４８Ａに示す通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

例示的なシステムアーキテクチャ
図１Ａ乃至１Ｃは、１つまたは複数の実施形態を実装またはその他の方法で実施することができるシステム１０の例を示すブロック図である。そのような実施形態は、例えば、マシンツーマシン（Ｍ２Ｍ）アプリケーション、Ｍ２Ｍサービス能力（ＳＣ）、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、およびＭ２ＭデバイスなどのＭ２Ｍリモートエンティティを管理することを含む、Ｍ２Ｍ通信および／または動作に関する実施形態を含んでもよい。

システム１０は、１つまたは複数のアーキテクチャに従って構成されてもよく、および／または１つまたは複数のアーキテクチャを使用して実装されてもよく、それらのアーキテクチャのいずれかは、様々な標準に基づいていてもよく、および／または様々な標準に従って構成されてもよい。これらの標準は、例えば、「マシンツーマシン（Ｍ２Ｍ）通信、機能アーキテクチャ」と題され、「ＥＴＳＩ ＴＳ １０２ ６９０」と呼ばれる欧州電気通信標準化機構（ＥＴＳＩ）により公表された技術仕様（ＴＳ）ドラフトなどの、Ｍ２Ｍ通信および／または動作に関する標準を含んでもよい。他の例は、例えば、「技術仕様グループサービスおよびシステム態様、マシンタイプ通信（ＭＴＣに対するサービス要件」と題する第３世代パートナーシッププロジェクト（３ＧＰＰ） ＴＳ ２２．３６８などのマシンタイプ通信（ＭＴＣ）に関連するものを含む、３ＧＰＰおよび／または第３世代パートナーシッププロジェクト２（３ＧＰＰ２）により公表された標準を含んでもよい。ＥＴＳＩ ＴＳ １０２ ６９０と３ＧＰＰ ＴＳ ２２．３６８は共に、参照により本明細書に組み込まれる。システム１０のアーキテクチャは他の標準に準拠してもよい。

システム１０は、デバイスドメイン１２、ネットワークドメイン１４、およびネットワークアプリケーションドメイン１６を含んでもよい。ネットワークアプリケーションドメイン１６は、Ｍ２Ｍネットワークアプリケーション１８ａおよび１８ｂを含んでもよい。Ｍ２Ｍネットワークアプリケーション１８ａおよび１８ｂは、個々のホスティングデバイス（図示せず）上で記憶され、実行され、および／またはホスティングされてもよい。あるいは、Ｍ２Ｍネットワークアプリケーション１８ａおよび１８ｂは、同一のホスティングデバイス（同じく図示せず）上で記憶され、実行され、および／またはホスティングされてもよい。ホスティングデバイスは、例えばホスティングアプリケーションサーバを含む１つまたは複数のサーバを含んでもよく、ならびに１つまたは複数の汎用もしくは専用コンピュータ、パーソナルコンピュータ、メインフレーム、ミニコンピュータ、サーバ型コンピュータ、および／または任意の適切なオペレーティングシステムで動作し、ソフトウェアを実行することが可能なプロセッサベースのプラットフォームに配置してもよい。ホスティングデバイスは複数の要素を含んでもよく、それらの要素は１つの単一のデバイスに形成されてもよく、ならびにサービングノード、クライアントノード、ピアノードまたはその他のノードの単一のノードに集中させてもよい。あるいは、ホスティングデバイスの要素は、２つ以上の別個のデバイスから形成されてもよく、したがってサービングノード、クライアントノード、ピアノードまたはその他のノードの複数のノード間で分散されてもよい。

ネットワークドメイン１４は、アクセスネットワークおよび／またはコアネットワーク（アクセス／コア）ネットワーク２０ならびにトランスポートネットワーク２２を含んでもよい。アクセス／コアネットワーク２２は、例えば、（ｉ）デジタル加入者回線技術（総称して「ｘＤＳＬ」）、（ｉｉ）ハイブリッド光ファイバー／同軸ケーブル（ＨＦＣ）ネットワーク、（ｉｉｉ）プログラマブルロジックコントローラ（ＰＬＣ）、（ｉｖ）衛星通信およびネットワーク、（ｖ）Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ：登録商標）／Ｅｎｈａｎｃｅｄ Ｄａｔａ ＧＳＭ Ｅｎｖｉｒｏｎｍｅｎｔ（ＥＤＧＥ）ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋｓ（ＧＥＲＡＮ）、（ｖｉ）ユニバーサル移動通信システム（ＵＭＴＳ）地上無線アクセスネットワーク（ＵＴＲＡＮ）、（ｖｉｉ）発展型ＵＴＲＡＮ（ｅＵＴＲＡＮ）、（ｖｉｉｉ）Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）についての１つまたは複数のプロトコルに従って、通信のために構成されたネットワークであってもよい。アクセスおよび／またはコアネットワーク２０を表すことができる例示的なアクセスおよび／またはコアネットワークの詳細は、下記で図４８Ａ〜４８Ｅと関連して説明される。トランスポートネットワーク２２を表すことができる例示的なトランスポートネットワークの詳細もまた、下記で図４８Ａ乃至４８Ｅと関連して説明される。

アクセス／コアネットワーク２０はまた、インターネットプロトコル（ＩＰ）スイートに従って接続性を提供してもよい。アクセス／コアネットワーク２０は、他の通信プロトコルに従って接続性を提供してもよい。加えて、アクセス／コアネットワーク２０は、サービスおよびネットワーク制御機能、他のネットワークとの相互接続、およびローミングサービスを提供してもよい。例として、アクセス／コアネットワーク２０は、３ＧＰＰ、ＥＴＳＩ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）により公表されたプロトコル、および３ＧＰＰ２により公表されたプロトコルに従って、通信のために構成されたネットワークであってもよい。

アクセス／コアネットワーク２０は、Ｍ２Ｍサーバ２４ａを含んでもよく、ならびにトランスポートネットワーク２２は、Ｍ２Ｍサーバ２４ｂおよび２４ｃを含んでもよい。Ｍ２Ｍサーバ２４ａ乃至２４ｃの各々は、それぞれのサービスプロバイダにより所有、維持、および／または運用されてもよい。例えば、Ｍ２Ｍサーバ２４ａは、無線（例えばセルラ）電気通信サービスプロバイダにより所有、維持、および／または運用されてもよく、一方、Ｍ２Ｍサーバ２４ｂおよび２４ｃは、他のサービスプロバイダにより所有、維持、および／または運用されてもよい。場合によっては、第１、第２および第３のＭ２Ｍサーバ２４ａ乃至２４ｃ各々の所有、維持、および／または運用は、２つ以上のプロバイダ間で分割されてもよい。

Ｍ２Ｍサーバ２４ａ乃至２４ｃは、それぞれのネットワークサービス能力レイヤ（Ｎ−ＳＣＬ）２６ａ乃至２６ｃおよびそれぞれのネットワーク通信プロトコルスタック２８ａおよび２８ｃを含んでもよく、または含むように構成されてもよい（図１Ｂ）。Ｎ−ＳＣＬ２６ａ乃至２６ｃは、それぞれのＭ２Ｍ ＳＣ（Ｎ−ＳＣ）３０ａ乃至３０ｃおよびそれに伴うリソース構造３２ａ乃至３２ｃを含んでもよい（図１Ｂ）。

デバイスドメイン１２は、Ｍ２Ｍデバイス３４ａ乃至３４ｇ、Ｍ２Ｍゲートウェイ３６ａおよび３６ｂ、ならびにＭ２Ｍエリアネットワーク３８ａおよび３８ｂを含んでもよい。Ｍ２Ｍデバイス３４ａ乃至３４ｇは、ぞれぞれのＭ２Ｍアプリケーション（ＤＡ）４０ａ乃至４０ｈ、およびそれぞれのネットワーク通信プロトコルスタック４２ａ乃至４２ｇを含んでもよい。Ｍ２Ｍデバイス３４ａ乃至３４ｇの一部、すなわちＭ２Ｍデバイス３４ａ乃至３４ｄ（以降「Ｄ３４ａ乃至３４ｄ」または「Ｄタイプのデバイス３４ａ乃至３４ｄ」）は、それぞれのＳＣＬ（Ｄ−ＳＣＬ）４４ａ乃至４４ｄを含んでもよく、または含むように構成されてもよい。Ｄ−ＳＣＬ４４ａ乃至４４ｄは、それぞれのＳＣ（Ｄ−ＳＣ）４６ａ乃至４６ｄ、およびそれに伴うリソース構造４８ａ乃至４８ｄを含んでもよく、または含むように構成されてもよい（図１Ｂ）。

Ｍ２Ｍデバイス３４ｅ乃至３４ｇ（以降「Ｄ’３４ｅ乃至３４ｇ」または「Ｄ’タイプのデバイス３４ｅ乃至３４ｇ」）はＤ−ＳＣＬを有さない。Ｄ３４ａ乃至３４ｄはその他の方式でＤ’３４ｅ乃至３４ｇと異なってもよい。例えば、Ｄ’３４ｅ乃至３４ｆは、処理電力およびメモリの制限などのリソース制約を受ける場合があるのに対し、Ｄ３４ａ乃至３４ｄはそのようなリソース制約を受けない場合がある。代わりに、および／またはそれに加えて、Ｄ’３４ｅ乃至３４ｇは、Ｄ−ＳＣＬ４４ａ乃至４４ｄと異なる機能を含んでもよく、含むように構成されてもよい。

Ｍ２Ｍゲートウェイ３６ａおよび３６ｂは、それぞれのＭ２Ｍアプリケーション（ＧＡ）５０ａおよび５０ｂ、それぞれのネットワーク通信プロトコルスタック５２ａおよび５２ｂ、ならびにそれぞれのＳＣＬ（Ｇ−ＳＣＬ）５４ａおよび５４ｂを含んでもよく、または含むように構成されてもよい（図１）。Ｇ−ＳＣＬ５４ａおよび５４ｂは、それぞれのＳＣ（Ｇ−ＳＣ）５６ａおよび５６ｂ、ならびにそれに伴うリソース構造５８ａ乃至５８ｅを含んでもよく、または含むように構成されてもよい（図１Ｂ）。

Ｍ２Ｍエリアネットワーク３８ａおよび３８ｂは、Ｍ２Ｍゲートウェイ３６ａおよび３６ｂ、ならびに存在する場合には他のＭ２Ｍゲートウェイ（図示せず）に通信可能に結合されてもよい。Ｍ２Ｍエリアネットワーク３８ａおよび３８ｂは、Ｄ３４ｄおよびＤ’３４ｅ〜３４ｇに加えてＭ２Ｍデバイス（図示せず）を含んでもよい。それらの追加的なＭ２Ｍデバイスは、Ｄタイプのデバイスであってもよく、またはＤ’タイプのデバイスであってもよい。Ｍ２Ｍエリアネットワーク３８ａおよび３８ｂの各々は、例えばメッシュアーキテクチャおよび／またはピアツーピアアーキテクチャを使用して構成されてもよい。

Ｄ３４ｄとＤ’３４ｅとをともに通信可能に結合し、ならびに／またはＤ３４ｄ、Ｄ’３４ｅ間、および／もしくはＭ２Ｍエリアネットワーク３８ａの隣接Ｍ２Ｍデバイス間を通信可能に結合する通信リンクは、有線および／または無線であってもよい。Ｄ’３４ｆおよび３４ｇをともに通信可能に結合し、ならびに／またはＤ’３４ｆ、３４ｇおよび／もしくはＭ２Ｍエリアネットワーク３８ｂの隣接Ｍ２Ｍデバイス間を通信可能に結合する通信リンクも、有線および／または無線であってもよい。

Ｄ３４ｄ、Ｄ’３４ｅおよびＭ２Ｍエリアネットワーク３８ａの他のＭ２Ｍデバイスを、Ｍ２Ｍゲートウェイ３６ａに通信可能に結合する通信リンクと、Ｄ’３４ｆ、３４ｇおよびＭ２Ｍエリアネットワーク３８ｂの他のＭ２ＭデバイスをＭ２Ｍゲートウェイ３６ｂに通信可能に結合する通信リンクとは、有線および／または無線であってもよい。これらの通信リンクの各々は、独自インタフェース、標準インタフェースおよび／またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばｄＩａ基準点などの基準点として定義されてもよい。そのようなｄＩａ基準点に相当する例示的なｄＩａ基準点の詳細は、ＥＴＳＩ ＴＳ １０２ ６９０で見られる。

Ｍ２Ｍゲートウェイ３６ａ、Ｍ２Ｍゲートウェイ３６ｂ、Ｄ３４ｂ乃至３４ｃ、およびＤ３４ａは、有線および／または無線の通信リンクを介して、それぞれＭ２Ｍサーバ２４ａ、２４ｂ、および２４ｃに通信可能に結合してもよい。これらの通信リンクは、独自インタフェース、標準インタフェースおよび／またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばｍＩａ基準点などの基準点として定義されてもよい。そのようなｍＩａ基準点に相当する例示的なｍＩａ基準点の詳細は、ＥＴＳＩ ＴＳ １０２ ６９０で見られる。

Ｍ２Ｍネットワークアプリケーション１８ａをＭ２Ｍサーバ２４ａと通信可能に結合し、ならびにＭ２Ｍネットワークアプリケーション１８ｂをＭ２Ｍサーバ２４ｂおよび２４ｃと通信可能に結合する通信リンクは、有線および／または無線であってもよい。これらの通信リンクの各々は、独自インタフェース、標準インタフェースおよび／またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばｍＩａ基準点などの基準点として定義されてもよい。そのようなｍＩａ基準点に相当する例示的なｍＩａ基準点の詳細はＥＴＳＩ ＴＳ １０２ ６９０で見られる。

Ｄ３４ａ乃至３４ｄのＤＡ４０ａ乃至４０ｄと、Ｄ−ＳＣＬ４４ａ乃至４４ｄとのそれぞれの間の通信は、ｍＩａ基準点を使用して実施されてもよい。ｄＩａおよびｍＩａ基準点は、Ｍ２Ｍネットワークアプリケーション１８ｂとＤＡ４０ａ乃至４０ｅとの間、およびＭ２Ｍネットワークアプリケーション１８ａとＤＡ４０ｆ〜４０ｇとの間に統一したインタフェースを提供してもよい。

図１には２つのＭ２Ｍゲートウェイと８つのＭ２Ｍデバイスが示されるが、デバイスドメイン１２は、それよりも多いまたは少ないＭ２Ｍゲートウェイ、およびそれよりも多いまたは少ないＭ２Ｍデバイスを含んでもよい。実際には、デバイスドメイン１２は、多数のＭ２Ｍデバイス、および多数のＭ２Ｍゲートウェイを有するであろう。加えて、かつ／または代わりに、システム１０は、より多いまたは少ないＭ２Ｍサーバ、より多いまたは少ないＭ２Ｍネットワークアプリケーション、およびより多いまたは少ないＭ２Ｍエリアネットワークを含んでもよい。

Ｍ２Ｍエリアネットワーク３８ａおよび３８ｂの各々は、例えば電気電子技術者学会（ＩＥＥＥ）８０２．１５．ｘ、Ｚｉｇｂｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｏｕｔｉｎｇ Ｏｖｅｒ Ｌｏｗ ｐｏｗｅｒ ａｎｄ Ｌｏｓｓｙ ｎｅｔｗｏｒｋｓ（ＲＯＬＬ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｏｃｉｅｔｙ ｏｆ Ａｕｔｏｍａｔｉｏｎ（ＩＳＡ）Ｗｉｒｅｌｅｓｓ Ｓｙｓｔｅｍｓ ｆｏｒ Ｉｎｄｕｓｔｒｉａｌ Ａｕｔｏｍａｔｉｏｎ、およびＰｒｏｃｅｓｓ Ｃｏｔｒｏｌ ａｎｄ Ｒｅｌａｔｅｄ Ａｐｐｌｉｃａｔｉｏｎ（ＩＳＡ１００．１１ａ）などのパーソナルエリアネットワークプロトコルに準拠して、通信のために構成されたネットワークであってもよい。Ｍ２Ｍエリアネットワーク３８ａおよび３８ｂは、例えば図４８Ａ乃至４８Ｅに関連して下記で説明するような他のネットワークプロトコルに準拠して構成されてもよい。

ここで図１Ｃを参照すると、Ｎ−ＳＣ３０ａ乃至３０ｃの各々は、アプリケーション実施可能能力（ＡＥ：application enablement capability）、汎用通信能力（ＧＣ：generic communication capability）、到達可能性（reachability）、アドレス指定・リポジトリ能力（ＲＡＲ：addressing and repository capability）、通信選択能力（ＣＳ：communication selection capability）、リモートエンティティ管理能力（ＲＥＭ：remote entity management capability）、セキュリティ能力（ＳＥＣ：security capability）、履歴・データ保持能力（ＨＤＲ：history and data retention capability）、トランザクション管理能力（ＴＭ：transaction management capability）、相互動作プロキシ能力（ＩＰ：interworking proxy capability）、ならびに電気通信オペレータ公開能力（ＴＯＥ：telecom operator exposure capability）を含んでもよく、または含むように構成されてもよく、当該能力の各々は、１つの能力から別の能力へ、情報（例えば処理されたメッセージから）を渡すためのルーティング機能に接続されてもよい。Ｎ−ＳＣ３０ａ乃至３０ｃの各々は、内部ソフトウェアのスケジューリング、オペレーティングシステムインタフェースの管理等を行うマネージャを含んでもよい。

Ｇ−ＳＣ５６ａおよび５６ｂの各々、ならびにＤ−ＳＣ４６ａ乃至４６ｄの各々も、マネージャとともにルーティング機能に接続されたＡＥ、ＧＣ、ＲＡＲ、ＣＳ、ＲＥＭ、ＳＥＣ、ＨＤＲ、ＴＭ、およびＩＰを含んでもよい。便宜上、以下では、ＡＥ、ＧＣ、ＲＡＲ、ＣＳ、ＲＥＭ、ＳＥＣ、ＨＤＲ、ＴＭ、ルーティング機能およびマネージャに、プレフィックス「Ｎ」、「Ｇ」、または「Ｄ」を付加して、Ｎ−ＳＣ、Ｇ−ＳＣ、およびＤ−ＳＣを区別する。ＡＥ、ＧＣ、ＲＡＲ、ＣＳ、ＲＥＭ、ＳＥＣ、ＨＤＲ、ＴＭ、ルーティング機能およびマネージャに、プレフィックス「ｘ」を付加して、Ｎ−ＳＣ、Ｇ−ＳＣおよびＤ−ＳＣとまとめて称する。

Ｎ−ＳＣ３０ａ乃至３０ｃ、Ｇ−ＳＣ５６ａ、５６ｂ、およびＤ−ＳＣ４６ａ乃至４６ｄの各々は、ＳＣツーＳＣの対話能力も含んでもよく、それによりデバイスツーデバイス（Ｄ２Ｄ）、ゲートウェイツーゲートウェイ（Ｇ２Ｇ）、およびサービスツーサーバ（Ｓ２Ｓ）の直接の通信を可能にする。Ｎ−ＳＣ３０ａ乃至３０ｃ、Ｇ−ＳＣ５６ａ、５６ｂ、およびＤ−ＳＣ４６ａ乃至４６ｄ（総称して「ｘＳＣ」）の一部またはすべての一部分は、例えばＥＴＳＩ ＴＳ １０２ ６９０などのＭ２Ｍ通信および／または動作に関する標準に準拠して定義されてもよい。

一般に、ＳＣは、様々なＭ２Ｍアプリケーションにより利用され得る機能を定義し、および／または実装してもよい。それを容易にするために、ＳＣ２４は、オープンインタフェースのセットを通じてそのような機能を様々なＭ２Ｍアプリケーションに公開してもよい。加えて、ＳＣは、アクセス／コアネットワークおよび／またはトランスポートネットワーク２０、２２の機能（ネットワーク機能）を使用してもよい。ただし、ＳＣは、ネットワークの仕様を様々なＭ２Ｍアプリケーションから隠蔽し、代わりにＳＣを介してそのようなアプリケーションに対し、ネットワーク管理を扱ってもよい。ＳＣはＭ２Ｍ専用としてもよい。あるいは、ＳＣは汎用的であってもよく、例えばＭ２ＭアプリケーションとＭ２Ｍアプリケーション以外のアプリケーションへのサポートを提供してもよい。下記でより詳細に説明するように、Ｎ−ＳＣＬリソース構造３２ａ乃至３２ｃ、Ｇ−ＳＣＬリソース構造５８ａ乃至５８ｅ、および／またはＤ−ＳＣＬ４４ａ乃至４４ｄの各々は、ｘＳＣのうち１つまたは複数のアーキテクチャに基づいて、階層として配置される１つまたは複数のリソースおよび／または属性を含んでもよい。

例示的なｘＲＥＭ管理レイヤおよび機能
図２は、ｘＲＥＭを実行するための機能アーキテクチャを定義する論理管理レイヤ２００の例示的なセットを示すブロック図である。一般に、管理レイヤ２００は、通信モジュール、ＳＣＬ、およびアプリケーションを管理するための機能を定義することができる。また、管理レイヤ２００は、管理機能を区別し、対応する管理オブジェクトおよびリソース構造を定義し、ｘＲＥＭでそれぞれＭ２Ｍデバイス（ＤＲＥＭ）、Ｍ２Ｍゲートウェイ（ＧＲＥＭ）、およびＭ２Ｍエリアネットワーク（ＮＲＥＭ）に対する管理機能を特定することができる。管理レイヤ２００の管理機能の区別は、Ｍ２Ｍリモートエンティティのタイプに基づいていてもよい。管理レイヤ２００は、例えば、（ｉ）Ｍ２Ｍアプリケーション（ｉｉ）Ｍ２Ｍ ＳＣ（ｉｉｉ）Ｍ２ＭエリアネットワークおよびＭ２Ｍゲートウェイ（ｉｖ）Ｍ２Ｍデバイス、を管理するための機能を定義する別個のレイヤを含んでもよい。管理レイヤ２００の各々は、その管理レイヤに存在するＭ２Ｍリモートエンティティの構成管理２１０、障害管理２１２、性能管理２１４などを実行するための機能を含んでもよい。一実施形態では、管理レイヤ２００は、アプリケーション管理レイヤ２０２、サービス管理レイヤ２０４、ネットワーク管理レイヤ２０６、およびデバイス管理レイヤ２０８を含んでもよい。管理レイヤ２００はその他のレイヤも含んでもよい。

例示的なＭ２Ｍアプリケーション管理レイヤ
Ｍ２Ｍアプリケーション管理レイヤ２０２は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにＭ２Ｍアプリケーションを管理することに関連するｘＲＥＭにおける管理機能を特定することを含む、Ｍ２Ｍアプリケーションの管理を扱ってもよい。Ｍ２Ｍアプリケーション管理レイヤ２０２は、Ｍ２Ｍデバイスおよび／またはＭ２Ｍゲートウェイ（総称して「Ｄ／Ｇ」）におけるＭ２Ｍアプリケーションのライフサイクル管理を扱ってもよく、それは、Ｄ／Ｇにおけるアプリケーションソフトウェアのインストール、更新、削除、起動、無効化のいずれかを含んでもよい。Ｍ２Ｍアプリケーション管理レイヤ２０２はまた、Ｄ／Ｇにおけるアプリケーションの構成管理を扱ってもよい。このことは、例えばそのようなアプリケーションの初期設定および／または更新を構成すること、および／またはプロビジョニングすることを含んでもよい。Ｍ２Ｍアプリケーション管理レイヤ２０２は、例えば障害関連情報を収集すること、および／または読み出すことを含む、Ｄ／Ｇにおけるアプリケーションの障害管理を扱ってもよい。Ｍ２Ｍアプリケーション管理レイヤ２０２は、例えば性能関連情報を収集すること、および／または読み出すことを含む、Ｄ／Ｇにおけるアプリケーションの性能管理を扱ってもよい。Ｍ２Ｍアプリケーション管理レイヤ２０２の所有者は、例えばＭ２Ｍアプリケーションプロバイダである。

例示的なＭ２Ｍサービス管理レイヤ
Ｍ２Ｍサービス管理レイヤ２０４は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにＭ２Ｍ ＳＣを管理することに関連するｘＲＥＭにおける管理機能を特定することを含む、Ｍ２ＭのＳＣの管理を扱ってもよい。Ｍ２Ｍサービス管理レイヤ２０４は、Ｄ／ＧにおけるＳＣＬのソフトウェア／ファームウェアの更新、ＳＣＬの初期設定および／または更新の構成またはプロビジョニングを含む、Ｄ／ＧにおけるＳＣＬの構成管理、例えば障害関連情報を収集すること、および読み出すことを含むＤ／ＧにおけるＳＣＬの障害管理、ならびに性能関連情報を収集すること、および読み出すことを含むＤ／ＧにおけるＳＣＬの性能管理を扱ってもよい。Ｍ２Ｍサービス管理レイヤ２０４の所有者は、例えばＭ２Ｍサービスプロバイダである。

例示的なＭ２Ｍネットワーク管理レイヤ
Ｍ２Ｍネットワーク管理レイヤ２０６は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにＭ２Ｍエリアネットワークを管理することに関連するｘＲＥＭにおける管理機能を特定することを含む、Ｍ２Ｍエリアネットワークを管理することを扱ってもよい。例えば、このレイヤは、ルーティング管理、トポロジ管理、およびネットワークライフサイクル管理を制御してもよい。Ｍ２Ｍエリアネットワークは多くの場合はＭ２Ｍ ＧＷによって接続されるため、Ｍ２Ｍ ＧＷはネットワーク管理レイヤ２０６においての役割を担ってもよい。

Ｍ２Ｍネットワーク管理レイヤ２０６は、例えば、ＩＰｖ６アドレスのプレフィクス、動作周波数、ＷＰＡＮ ＩＤなどを構成することを含む、Ｍ２Ｍエリアネットワークの初期動作設定を構成すること、および／またはプロビジョニングすることを含む、Ｍ２Ｍエリアネットワークの設定管理を扱ってもよい。Ｍ２Ｍネットワーク管理レイヤ２０６はまた、（ｉ）６ＬｏＷＰＡＮ／ＲＯＬＬ／ＣｏＡＰにおけるパラメータおよび／または定数の更新を含む、Ｄ／Ｇの構成を更新すること（ｉｉ）異常の検出（例えば失効したルーティングまたは誤ったルーティング、ループバックルーティングなど）ならびに／または警告の生成および／もしくは処理を含む、Ｍ２Ｍエリアネットワークの障害管理（ｉｉｉ）Ｍ２Ｍエリアネットワーク（例えば全体）のデューティサイクル管理、トポロジ／ルーティング管理およびＱｏＳ管理を含む、Ｍ２Ｍエリアネットワークの性能管理を扱ってもよい。ネットワーク管理レイヤ２０６の所有者はＭ２Ｍエリアネットワークプロバイダであり、これは、Ｍ２Ｍアプリケーションプロバイダ、Ｍ２Ｍサービスプロバイダ、またはＭ２Ｍユーザとすることができる。

例示的なＭ２Ｍデバイス管理レイヤ
デバイス管理レイヤ２０８は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにＭ２Ｍエンドデバイスに関連するｘＲＥＭにおける管理機能を特定することを含む、Ｄ／ＧなどのＭ２Ｍエンドデバイスの管理を扱ってもよい。デバイス管理レイヤ２０８は、リソースに制約のあるＭ２Ｍデバイスに対する管理機能を扱ってもよく、これは例えばデューティサイクル管理および電力管理を含んでもよい。デバイス管理レイヤ２０８は、（ｉ）Ｄ／Ｇの初期動作を構成すること、および／またはＤ／Ｇの構成を更新することを含む、Ｄ／Ｇの構成管理、（ｉｉ）異常の検出や警告の生成および処理を含む、Ｄ／Ｇの障害管理、（ｉｉｉ）例えば、制約のあるリソース（センサ、アクチュエータ、電源／バッテリ、メモリ、ＣＰＵ、通信インタフェースなど）の管理、節電管理（例えばノード全体のデューティサイクル、トランシーバのデューティサイクル）、センサおよびアクチュエータの管理（例えば種々のアプリケーション間で共有すること）を含むことができる、Ｄ／Ｇの性能管理、を扱ってもよい。デバイス管理レイヤ２０８の所有者は、Ｍ２Ｍアプリケーションプロバイダ、Ｍ２Ｍサービスプロバイダ、Ｍ２Ｍエリアネットワークプロバイダ、またはＭ２Ｍユーザであってもよい。

図３Ａを参照すると、管理レイヤのセットとそれらの機能に従ってリソース構造を備えるＳＣＬをプロビジョニングするための例示的なリソース構造のフレームワーク３００を示すブロック図が示される。そのようなリソース構造をプロビジョニングすることができるＳＣＬは、例えばＮ−ＳＣＬ２６ａ乃至２６ｃのいずれかなどのホスティングＳＣＬであってもよい。ホスティングＳＣＬ上にプロビジョニングされたリソース構造は、後に、そのホスティングＳＣＬ、他のホスティングＳＣＬおよび／またはリモートＳＣＬ間の同期を介して、１つまたは複数の他のホスティングＳＣＬおよび／またはＧ−ＳＣＬ５６ａ、５６ｂおよび／またはＤ−ＳＣＬ４４ａ乃至４４ｄなどの１つまたは複数のリモートＳＣＬ上でプロビジョニング（例えばすべてまたは一部を複製）されてもよい。あるいは、そのようなリソースがプロビジョニングされるＳＣＬは、Ｇ−ＳＣＬ５６ａ、５６ｂおよび／またはＤ−ＳＣＬ４４ａ乃至４４ｄなどのリモートＳＣＬであってもよい。リモートＳＣＬ上でプロビジョニングされたリソース構造は、後に、そのリモートＳＣＬ、他のリモートＳＣＬおよび／またはホスティングＳＣＬ間の同期を介して、Ｎ−ＳＣＬ２６ａ乃至２６ｃなどの１つまたは複数の他のリモートＳＣＬおよび／または１つまたは複数のホスティングＳＣＬ上でプロビジョニング（例えば全体または一部を複製）されてもよい。加えて、かつ／またはこれに替えて、リソース構造フレームワーク３００は、複数のホスティングＳＣＬおよび／または複数のリモートＳＣＬ上でリソース構造をプロビジョニングするために使用されてもよい。

リソース構造フレームワーク３００は、適切なＳＣＬのルートリソース（「＜ｓｃｌＢａｓｅ＞」）３０２、＜ｓｃｌＢａｓｅ＞３０２の下位にある複数のリソース（「下位リソース」）、および、１つまたは複数の属性３０４（「ａｔｔｒｉｂｕｔｅ」）を含んでもよい。ａｔｔｒｉｂｕｔｅ３０４は、＜ｓｃｌＢａｓｅ＞３０２から直下にある下位リソースの一部またはすべてに関連付けられてもよい（例えば共通している）。あるいは、ａｔｔｒｉｂｕｔｅ３０４は、＜ｓｃｌＢａｓｅ＞３０２から直接かつ／または間接的に下位にある下位リソースに関連付けられてもよい。＜ｓｃｌＢａｓｅ＞３０２から直接下位にある下位リソースは、ＳＣＬ（「ｓｃｌ」）下位リソース３０６、アプリケーション（「ａｐｐｌｉｃａｔｉｏｎｓ」）下位リソース３０８、コンテナ（「ｃｏｎｔａｉｎｅｒｓ」）下位リソース３１０、グループ（「ｇｒｏｕｐｓ」）下位リソース３１２、アクセス権（「ａｃｃｅｓｓＲｉｇｈｔｓ」）下位リソース３１４、サブスクリプション（「ｓｕｂｓｃｒｉｐｔｉｏｎｓ」）下位リソース３１６、検出（「ｄｉｓｃｏｖｅｒｙ」）下位リソース３１８、アクセスステータス（「ａｃｃｅｓｓＳｔａｔｕｓ」）下位リソース３２０、および管理オブジェクト（「ｍｇｍｔＯｂｊｓ」）下位リソース３２２を含んでもよい。

ｓｃｌｓ下位リソース３０６は、個々のＳＣＬリソースの集合であってもよく、ＳＣＬリソースの各々は、例えばＭ２Ｍサービス登録プロシージャを介してホスティングＳＣＬと対話する権限が与えられた、関連付けられた（例えばリモートの）ＳＣＬを表してもよい。ｓｃｌｓ下位リソース３０６の各ＳＣＬリソースは、関連付けられたＳＣＬのそのローカルＳＣＬへの成功した登録、またはその逆の成功した登録に応じて作成されてもよい。ｓｃｌｓ下位リソース３０６は、個々の登録されたＳＣＬについてのコンテキスト情報を含み、維持し、かつ／または格納してもよい。ｓｃｌｓ下位リソース３０６の各々は、１つまたは複数の下位リソースおよび／または１つまたは複数の属性（図示せず）を含んでもよい。

ａｐｐｌｉｃａｔｉｏｎｓ下位リソース３０８は、個々のアプリケーションリソースの集合であってもよく、リソースの各々は、アプリケーションについての情報を含み、維持し、かつ／または格納してもよい。ａｐｐｌｉｃａｔｉｏｎｓ下位リソース３０８の各アプリケーションリソースは、関連するアプリケーションのローカルＳＣＬへの成功した登録に応じて作成されてもよい。

ｃｏｎｔａｉｎｅｒｓ下位リソース３１０は、個々のコンテナリソースの集合であってもよく、リソースの各々は、アプリケーション間および／またはＳＣＬ間で情報を交換するのに使用する汎用的なリソースであってもよい。ｃｏｎｔａｉｎｅｒｓ下位リソース３１０の各コンテナリソースは、対応するコンテナを、情報をバッファリングするための仲介として使用することにより、アプリケーション間および／またはＳＣＬ間の情報の交換を容易にしてもよい。

ｇｒｏｕｐｓ下位リソース３１２は、個々のグループリソースの集合であってもよい。ｇｒｏｕｐｓ下位リソース３１２の各グループリソースが使用されて、＜ｓｃｌＢａｓｅ＞３０２から直接かつ／または間接的に下位にある下位リソースを含む他の、下位リソースのグループを定義し、および／または下位リソースのグループにアクセスしてもよい。

ａｃｃｅｓｓＲｉｇｈｔｓ下位リソース３１４は、個々のアクセス権（「ａｃｃｅｓｓＲｉｇｈｔ」）リソースの集合であってもよく、リソースの各々は、パーミッションの表現を含み、維持し、かつ／または格納してもよい。ａｃｃｅｓｓＲｉｇｈｔｓ下位リソース３１４の各ａｃｃｅｓｓＲｉｇｈｔリソースは、ホスティングＳＣＬの外部にあるエンティティにアクセス可能な他の下位リソースの１つまたは複数に関連付けられてもよい。ａｃｃｅｓｓＲｉｇｈｔｓ３１４の各々のパーミッションの表現は、パーミッション所有者の識別、およびパーミッションの所有者に付与された権利の識別を含んでもよい。パーミッション所有者に付与された権利の識別は、例えば、対応する下位リソースについて付与された権利の１つまたは複数に関連付けられたパーミッションフラグとしてもよい。

ｓｕｂｓｃｒｉｐｔｉｏｎｓの下位リソース３１６は、個々のサブスクリプションリソースの集合であってもよい。ｓｕｂｓｃｒｉｐｔｉｏｎｓ３１６の各サブスクリプションリソースは、その親リソース、すなわち＜ｓｃｌＢａｓｅ＞３０２への（例えばアクティブな）サブスクリプションのステータスを追跡するための情報を含んでもよい。各ｓｕｂｓｃｒｉｐｔｉｏｎｓ３１６は、＜ｓｃｌＢａｓｅ＞３０２上の変更の通知についての、発行元からの要求を表してもよい。

ｄｉｓｃｏｖｅｒｙ３１８が使用されて、下位リソースの検出を可能にしてもよい。ｄｉｓｃｏｖｅｒｙ３１８が使用されて、検出フィルタ基準に一致する下位リソースのユニフォームリソース識別子（ＵＲＩ）のリストを読み出してもよい。ａｃｃｅｓｓＳｔａｔｕｓ３２０は、個々のアクセスステータスリソースの集合であってもよい。

ｍｇｍｔＯｂｊｓ下位リソース３２２は、個々の管理オブジェクト（「ｍｇｍｔＯｂｊ」）リソースの集合であってもよい。ｍｇｍｔＯｂｊｓ３２２の各ｍｇｍｔＯｂｊリソースは、ＲＥＭを実行するための管理情報および／またはパラメータを含み、維持し、および／または格納してもよい。ｍｇｍｔＯｂｊｓ下位リソース３２２は、アプリケーション管理オブジェクト下位リソース（「ａｐｐＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３２４、ＳＣＬ管理オブジェクト下位リソース（「ｓｃｌＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３２６、ネットワーク管理オブジェクト下位リソース（「ｎｗｋＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３２８、デバイス管理オブジェクト下位リソース（「ｄｅｖＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３３０、ＯＭＡ−ＤＭ管理オブジェクト下位リソース（「ｏｍａＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３３２、およびＢＢＦ−ＴＲ０６９管理オブジェクト下位リソース（「ｂｂｆＭｇｍｔＯｂｊｅｃｔｓ」）下位リソース３３４を含んでもよい。ｍｇｍｔＯｂｊｓ下位リソース３２２はまた、その他のｍｇｍｔＯｂｊリソースおよび／または異なるｍｇｍｔＯｂｊリソースを含んでもよい。

ａｐｐＭｇｍｔオブジェクト下位リソース３２４は、個々のアプリケーション管理オブジェクト（「ａｐｐＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ａｐｐＭｇｍｔオブジェクトリソースは、アプリケーション管理レイヤ２０２（図２）などのアプリケーション管理レイヤ、およびその機能に従ってＲＥＭを実行するための情報および／またはパラメータを含んでもよい。各ａｐｐＭｇｍｔオブジェクトリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３２４−１として、ａｐｐＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２４の下位に配置されてもよい。

ｓｃｌＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２６は、個々のＳＣＬ管理オブジェクト（「ｓｃｌＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ｓｃｌＭｇｍｔオブジェクトリソースは、サービス管理レイヤ２０４（図２）などのサービス管理レイヤとその機能に従ってＲＥＭを実行するための情報、および／またはパラメータを含んでもよい。各ｓｃｌＭｇｍｔオブジェクトリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３２６−１として、ｓｃｌＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２６の下位に配置されてもよい。

ｎｗｋＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２８は、個々のネットワーク管理オブジェクト（「ｎｗｋＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ｎｗｋＭｇｍｔＯｂｊｅｃｔリソースは、ネットワーク管理レイヤ２０６（図２）などのネットワーク管理レイヤおよびその機能に従ってＲＥＭを実行するための情報および／またはパラメータを含んでもよい。各ｎｗｋＭｇｍｔＯｂｊｅｃｔリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３２８−１としてｎｗｋＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２８の下位に配置されてもよい。

ｄｅｖＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３０は、個々のデバイス管理オブジェクト（「ｄｅｖＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ｄｅｖＭｇｍｔＯｂｊｅｃｔリソースは、デバイス管理レイヤ２０８（図２）などのデバイス管理レイヤおよびその機能に従ってＲＥＭを実行するための情報および／またはパラメータを含んでもよい。各ｄｅｖＭｇｍｔオブジェクトリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３３０−１としてｄｅｖＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３０の下位に配置されてもよい。

ｏｍａＭｇｍｔＯｂｊｅｃｔｓ３３２は、個々のＯＭＡ−ＤＭ管理オブジェクト（「ｏｍａＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ｏｍａＭｇｍｔＯｂｊｅｃｔリソースは、ＯＭＡ−ＤＭおよび／またはＯＭＡ−ＤＭと互換性のある管理機能に従ってＲＥＭを実行するための情報および／またはパラメータを含んでもよい。各ｏｍａＭｇｍｔＯｂｊｅｃｔリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３３２−１として、ｏｍａＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３２の下位に配置されてもよい。

ｂｂｆＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３４は、個々のＢＢＦ−ＴＲ０６９管理オブジェクト（「ｂｂｆＭｇｍｔＯｂｊｅｃｔ」）リソースの集合であってもよい。各ｂｂｆＭｇｍｔＯｂｊｅｃｔリソースは、ＢＢＦ−ＴＲ０６９および／またはＢＢＦ−ＴＲ０６９と互換性のある管理機能、例えばＢＢＦ−ＴＲ０６９のリモートプロシージャコール（ＲＰＣ）メソッドに従ってＲＥＭを実行するための情報および／またはパラメータを含んでもよい。各ｂｂｆＭｇｍｔＯｂｊｅｃｔリソースは、＜ｍｇｍｔＯｂｊｅｃｔ＞インスタンス３３４−１としてｂｂｆＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３４の下位に配置されてもよい。

ｍｇｍｔＯｂｊｓ下位リソース３２２は、図３Ａに示すように＜ｓｃｌＢａｓｅ−ｏｆ−Ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ｓｃｌ＞／ｍｇｍｔＯｂｊｓのみに存在するが、他の（例えば複数の）ｍｇｍｔＯｂｊｓ下位リソースは、＜ｓｃｌＢａｓｅ＞３０２の様々なより下位の枝／位置に配置されてもよい。そのようにすると、そのような他のｍｇｍｔＯｂｊｓ下位リソースは、特定の管理機能（アプリケーションやＳＣＬなど）に明示的に対応することができる。

図３Ｂは、管理レイヤのセットおよびその機能に従ったリソース構造を備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワーク３４０を示すブロック図である。そのようなリソース構造をプロビジョニングすることができるＳＣＬは、例えばＧ−ＳＣＬ５６ａ、５６ｂおよび／またはＤ−ＳＣＬ４４ａ乃至４４ｄなどのいずれかのローカルＳＣＬである。ローカルＳＣＬ上でプロビジョニングされたリソース構造は、後に、そのローカルＳＣＬおよび／またはホスティングＳＣＬ間の同期を介して、１つまたは複数の他のホスティングＳＣＬおよび／またはＮ−ＳＣＬ２６ａ乃至２６ｃなどの１つまたは複数のリモートＳＣＬ上でプロビジョニング（例えば全体または一部を複製）されてもよい。あるいは、そのようなリソース構造をプロビジョニングすることができるＳＣＬは、Ｎ−ＳＣＬ２６ａ乃至２６ｃなどのホスティングＳＣＬであってもよい。ホスティングＳＣＬ上でプロビジョニングされたリソース構造は、後に、ホスティングＳＣＬとリモートＳＣＬ間の同期を介して、Ｇ−ＳＣＬ５６ａ、５６ｂおよび／またはＤ−ＳＣＬ４４ａ乃至４４ｄなどの１つまたは複数の他のリモートＳＣＬ上でプロビジョニング（例えば全体または一部を複製）されてもよい。加えて、かつ／またはこれに替えて、リソース構造フレームワーク３４０は、複数のローカルＳＣＬおよび／または複数のホスティングＳＣＬ上でリソース構造をプロビジョニングするために使用されてもよい。

リソース構造フレームワーク３４０は、＜ｓｃｌＢａｓｅ＞３４２、＜ｓｃｌＢａｓｅ＞３４２への複数の下位リソース、＜ｓｃｌＢａｓｅ＞３４２から直接下位にある下位リソースの一部またはすべてに関連付けられた１つまたは複数の属性３４４（「ａｔｔｒｉｂｕｔｅ」）、ならびに＜ｓｃｌＢａｓｅ＞３４２から間接的に下位にある下位リソースに関連付けられたａｔｔｒｉｂｕｔｅ３５０およびａｔｔｒｉｂｕｔｅを含んでもよい。

＜ｓｃｌＢａｓｅ＞３４２から直接下位にある下位リソースは、以下の点を除いては図３Ａの＜ｓｃｌＢａｓｅ＞３０２から直接下位にある下位リソースと同様である。＜ｓｃｌＢａｓｅ＞３４２から直接下位にある下位リソースは、ａｐｐｌｉｃａｔｉｏｎｓ下位リソース３４６およびｍｇｍｔＯｂｊｓ下位リソース３４８を含んでもよい。

ｍｇｍｔＯｂｊｓ下位リソース３４８（＜ｓｃｌＢａｓｅ＞／ｍｇｍｔＯｂｊｓにおける）は、個々の管理オブジェクト（「ｍｇｍｔＯｂｊ」）リソースの集合であってもよい。ｍｇｍｔＯｂｊｓ下位リソース３４８は、（ｉ）サービス管理レイヤおよびその機能、（ｉｉ）ネットワーク管理レイヤおよびその機能（ｉｉｉ）デバイス管理レイヤおよびその機能（ｉｖ）ＯＭＡ−ＤＭおよび／またはＯＭＡ−ＤＭと互換性のある管理機能（ｖ）ＢＢＦ−ＴＲ０６９および／またはＢＢＦ−ＴＲ０６９と互換性のある管理機能のいずれかに従って、ＲＥＭを実施するための管理情報および／またはパラメータを含み、維持し、および／または格納してもよい。ｍｇｍｔＯｂｊｓ下位リソース３４８は、例えば、ｓｃｌＭｇｍｔＯｂｊｅｃｔｓ下位リソース３２６、ｎｗｋＭｇｍｔｔＯｂｊｅｃｔｓ下位リソース３２８、ｄｅｖＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３０、ｏｍａＭｇｍｔＯｂｊｅｃｔｓ下位リソース３３２、およびｂｂｆＭｇｍｔｔＯｂｊｅｃｔｓ下位リソース３３４を含んでもよい。ｍｇｍｔＯｂｊｓ下位リソース３４８は、他のｍｇｍｔＯｂｊリソースおよび／または異なるｍｇｍｔＯｂｊリソースも含んでもよい。

ａｐｐｌｉｃａｔｉｏｎｓ下位リソース３４６は、個々のアプリケーション（「＜ａｐｐｌｃｉａｔｉｏｎ＞」）リソース３５２、ａｃｃｅｓｓＳｔａｔｕｓ下位リソース３５４、ｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソース３５６、ｍｇｍｔＯｂｊｓ下位リソース３５８、およびａｐｐｌｉｃａｔｉｏｎｓ下位リソース３４６の下位リソースに関連する属性３５０の集合を含んでもよい。ｍｇｍｔＯｂｊｓ下位リソース３５８（＜ｓｃｌＢａｓｅ＞／ａｐｐｌｉｃａｔｉｏｎｓ／ｍｇｍｔＯｂｊｓにおける）は、＜ｓｃｌＢａｓｅ＞３４２の下に登録されたすべてのアプリケーションのＲＥＭを全体として実行するための下位リソースの集合を含んでもよい。

個々のアプリケーションリソース３５２の各々は、ｃｏｎｔａｉｎｅｒｓ下位リソース３６２、ｇｒｏｕｐｓ下位リソース３６４、ａｃｃｅｓｓＲｉｇｈｔｓ下位リソース３６６、ａｃｃｅｓｓＳｔａｔｕｓ下位リソース３６８、ｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソース３７０、ｍｇｍｔＯｂｊｓ下位リソース３７２、および対応する個々のアプリケーションリソースの下位リソース３５２に関連するａｔｔｒｉｂｕｔｅ３６０を含んでもよい。ｍｇｍｔＯｂｊｓ下位リソース３７２（＜ｓｃｌＢａｓｅ＞／ａｐｐｌｉｃａｔｉｏｎｓ／＜ａｐｐｌｉｃａｔｉｏｎ＞／ｍｇｍｔＯｂｊｓに位置するにおける）は、対応する＜ａｐｐｌｉｃａｔｉｏｎ＞下位リソース３５２に関連付けられた特定の＜ａｐｐｌｉｃａｔｉｏｎ＞のＲＥＭを実行するための下位リソースの集合を含んでもよい。

図３Ｃは、管理レイヤのセットおよびその機能に従ったリソース構造を有するＳＣＬをプロビジョニングするための例示的なリソース構造フレームワーク３７６を示すブロック図である。そのようなリソース構造をプロビジョニングすることができるＳＣＬは、例えばＮ−ＳＣＬ２６ａ乃至２６ｃなどのいずれかのホスティングＳＣＬであってもよい。ホスティングＳＣＬ上でプロビジョニングされたリソース構造は、後に、そのホスティングＳＣＬ、他のホスティングＳＣＬおよび／またはリモートＳＣＬ間の同期を介して、１つまたは複数の他のホスティングＳＣＬおよび／またはＧ−ＳＣＬ５６ａ、５６ｂやＤ−ＳＣＬ４４ａ乃至４４ｄなどの１つまたは複数のリモートＳＣＬ上でプロビジョニングされてもよい（例えば全体または一部を複製する）。あるいは、そのようなリソース構造をプロビジョニングすることができるＳＣＬは、Ｇ−ＳＣＬ５６ａ、５６ｂおよび／またはＤ−ＳＣＬ４４ａ乃至４４ｄなどのいずれかのリモートＳＣＬであってもよい。リモートＳＣＬ上でプロビジョニングされたリソース構造は、後に、そのリモートＳＣＬ、他のリモートＳＣＬおよび／またはホスティングＳＣＬ間の同期を介して、１つまたは複数の他のリモートＳＣＬおよび／またはＮ−ＳＣＬ２６ａ乃至２６ｃなどの１つまたは複数のホスティングＳＣＬ上でプロビジョニングされてもよい（例えば全体または一部を複製する）。加えて、かつ／またはこれに替えて、リソース構造のフレームワーク３４０を使用して、複数のホスティングＳＣＬおよび／または複数のリモートＳＣＬ上でリソース構造をプロビジョニングしてもよい。

リソース構造フレームワーク３７６は、＜ｓｃｌＢａｓｅ＞３７８、＜ｓｃｌＢａｓｅ＞３７８への複数の下位リソース、＜ｓｃｌＢａｓｅ＞３７８から直接および／または間接的に下位にある下位リソースの一部またはすべてに関連する１つまたは複数の属性を含んでもよい。＜ｓｃｌＢａｓｅ＞３７８から直接下位にある下位リソースは、＜ｓｃｌＢａｓｅ＞３７８から直接下位にｍｇｍｔＯｂｊｓ下位リソースがない点を除いて、図３Ａの＜ｓｃｌＢａｓｅ＞３０２から直接下位にあるリソースと同様である。代わりに、リソース構造フレームワーク３７６は、＜ｓｃｌＢａｓｅ＞３７６の様々なさらに下位にある枝／位置に配置することができる複数のｍｇｍｔＯｂｊｓ下位リソースを含む。例えば、＜ｓｃｌＢａｓｅ＞３７６は、ｍｇｍｔＯｂｊｓ下位リソース３８０（＜ｓｃｌＢａｓｅ＞ｓｃｌｓ／ｍｇｍｔＯｂｊｓに位置する）を含んでもよい。ｍｇｍｔＯｂｊｓ下位リソース３８０は、Ｍ２Ｍサーバに登録されたすべてのＳＣＬのＲＥＭを全体として実行するための下位リソースの集合を含んでもよい。それらの下位リソースは、サービス管理レイヤ２０４（図２）などのサービス管理レイヤおよびその機能に従って、Ｍ２Ｍサーバに登録されたすべてのＳＣＬのＲＥＭを全体として実行するための情報および／またはパラメータを含んでもよい。

＜ｓｃｌＢａｓｅ＞３７６はまた、ｍｇｍｔＯｂｊｓ下位リソース３８２（＜ｓｃｌＢａｓｅ＞／ｓｃｌｓ／＜ｓｃｌ＞／ｍｇｍｔＯｂｊｓにおける）も含んでもよい。このｍｇｍｔＯｂｊｓ下位リソース３８２は、Ｍ２Ｍサーバに登録された＜ｓｃｌ＞のサービス能力および他の管理機能（ネットワーク管理レイヤおよびデバイス管理レイヤ）のＲＥＭを実行するための下位リソースの集合を含んでもよい。一実施形態では、当該下位リソースは、（ｉ）ネットワーク管理レイヤ２０６（図２）などのネットワーク管理レイヤおよびその機能、ならびに（ｉｉ）デバイス管理レイヤ２０８（図２）などのデバイス管理レイヤ、に従ってＭ２Ｍサーバに登録された＜ｓｃｌ＞のサービス能力および他の管理機能のＲＥＭを実行するための情報および／またはパラメータを含んでもよい。

＜ｓｃｌＢａｓｅ＞３７６はまた、ｍｇｍｔＯｂｊｓ下位リソース３８４（＜ｓｃｌＢａｓｅ＞／ｓｃｌｓ／＜ｓｃｌ＞／ａｐｐｌｉｃａｔｉｏｎｓ／／ｍｇｍｔＯｂｊｓにおける）も含んでもよい。ｍｇｍｔＯｂｊｓ下位リソー３８４は、サーバに通知されたすべてのアプリケーションのＲＥＭを全体として実行するための下位リソースの集合を含んでもよい。＜ｓｃｌＢａｓｅ＞３７６はさらに、ｍｇｍｔＯｂｊｓ下位リソース３８６（＜ｓｃｌＢａｓｅ＞／ｓｃｌｓ／＜ｓｃｌ＞／ａｐｐｌｉｃａｔｉｏｎｓ／＜ａｐｐｌｉｃａｔｉｏｎＡｎｎｃ＞／ｍｇｍｔＯｂｊｓにおける）を含んでもよい。このｍｇｍｔＯｂｊｓ下位リソース３８６は、Ｍ２Ｍサーバに通知された特定の＜ａｐｐｌｉｃａｔｉｏｎＡｎｎｃ＞のＲＥＭを実行するための下位リソースの集合を含んでもよい。

一実施形態では、ｍｇｍｔＯｂｊｓ下位リソース３８２（＜ｓｃｌＢａｓｅ＞／ｓｃｌｓ／＜ｓｃｌ＞／ｍｇｍｔＯｂｊｓにおける）は、Ｍ２Ｍサーバに登録する別のＤ／Ｇを管理するために、ＤＡおよび／またはＧＡによって使用されてもよい。Ｍ２Ｍサーバ（すなわち＜ｓｃｌ＞）は、自身の＜ｍｇｍｔＯｂｊ＞をＤ／Ｇに知らせてもよい。次いでＤＡ／ＧＡは、Ｄ／Ｇにおけるそのような通知された＜ｍｇｍｔＯｂｊ＞にアクセスすることができ、それによりＭ２Ｍサーバにおけるメッセージングの中継を介して他のＤ／Ｇを管理することが可能になる。

図４Ａは、ｍｇｍｔＯｂｊｓを備えるＳＣＬをプロビジョニングするための例示的なリソース構造フレームワーク４００を示すブロック図である。リソース構造フレームワーク（「ｍｇｍｔＯｂｊｓ構造フレームワーク」）４００は、ルートとしてのｍｇｍｔＯｂｊｓ４０２、ｍｇｍｔＯｂｊｓ４０２への複数の下位リソース、ｍｇｍｔＯｂｊｓ４０２から直接下位にある下位リソースの一部またはすべてに関連する１つまたは複数の属性４０４（「ａｔｔｒｉｂｕｔｅ」）、およびｍｇｍｔＯｂｊｓ４０２から間接的に下位にある下位リソースに関連するａｔｔｒｉｂｕｔｅ４１６、４１８、４３０、および４４２を含んでもよい。ａｔｔｒｉｂｕｔｅ４０４は、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｍｇｍｔＯｂｊｓ４０２のテキスト形式の詳細などの詳細、およびａｌｌｏｗｅｄＭｅｔｈｏｄを含んでもよい。ａｌｌｏｗｅｄＭｅｔｈｏｄは、ｍｇｍｔＯｂｊｓ下位リソース４０２を処理するための許可されたＲＥＳＴｆｕｌメソッドを指定してもよい。

ｍｇｍｔＯｂｊｓ４０２への複数の下位リソースは、ｍｇｍｔＯｂｊ（「＜ｍｇｍｔＯｂｊ＞」）下位リソース４０６、管理オブジェクトアナウンス（「＜ｍｇｍｔＯｂｊＡｎｎｃ＞」）下位リソース４０８、ａｃｃｅｓｓＲｉｇｈｔｓ下位リソース４１０、ａｃｃｅｓｓＳｔａｔｕｓ下位リソース４１２、およびｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソース４１４を含んでもよい。

＜ｍｇｍｔＯｂｊ＞下位リソース４０６は、特定の管理オブジェクトであってもよく、およびこの＜ｍｇｍｔＯｂｊ＞下位リソース４０６に対して関連する管理データ／パラメータを格納するためのプレースホルダであってもよい。＜ｍｇｍｔＯｂｊＡｎｎｃ＞下位リソース４０８は、公表された管理オブジェクトに対するプレースホルダであってもよい。＜ｍｇｍｔＯｂｊＡｎｎｃ＞下位リソース４０８は、以下の属性、（ｉ）ｌｉｎｋ、（ｉｉ）ａｃｃｅｓｓＲｉｇｈｔＩＤ、および（ｉｉｉ）ｓｅａｒｃｈＳｔｒｉｎｇｓを含んでもよい。

＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４１０は、ＲＥＭを実行するために使用される下位リソースに対するパーミッションの表現を含み、保持し、かつ／または格納してもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４０８は、親がある場合は親から継承されてもよい。

ａｃｃｅｓｓＳｔａｔｕｓ下位リソース４１４は個々のアクセスステータスリソースの集合であってもよい。ｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソース４１４は、サブスクリプションリソースの集合であってもよく、サブスクリプションリソースの各々は、その親リソースへの（例えばアクティブな）サブスクリプションのステータスを追跡するための情報を含んでもよい。ｓｕｂｓｃｒｉｐｔｉｏｎｓ４１４の各々は、親リソース上の変更の通知について、発行元からの要求を表してもよい。

＜ｍｇｍｔＯｂｊ＞下位リソース４０６は、（ｉ）管理目的の複数パラメータの集合に対するプレースホルダとすることができる＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０（ｉｉ）単一の管理パラメータとすることができる＜ｐａｒａｍｅｔｅｒ＞下位リソース４２２（ｉｉｉ）ｘＲＥＭ目的の＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４２４（ｉｖ）＜ａｃｃｅｓｓＳｔａｔｕｓ＞下位リソース４２６、および＜ｓｕｂｓｃｒｉｐｔｉｏｎｓ＞下位リソース４２８、を含んでもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４２４は、ＲＥＭを実行するために使用される下位リソースについてのパーミッションの表現を含み、保持し、かつ／または格納してもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４２４は、親がある場合は、親から継承されてもよい。

＜ｍｇｍｔＯｂｊ＞下位リソース４０６は、以下の属性、（ｉ）ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｄｅｓｃｒｉｐｔｉｏｎ（例えば＜ｍｇｍｔＯｂｊ＞下位リソース４０６のテキスト形式の詳細）、ａｌｌｏｗｅｄＭｅｔｈｏｄ、およびｃｏｎｔｅｎｔＴｙｐｅ、を含んでもよい。ａｌｌｏｗｅｄＭｅｔｈｏｄは、＜ｍｇｍｔＯｂｊ＞下位リソース４０６を処理するための許可されたＲＥＳＴｆｕｌメソッドを指定してもよい。ｃｏｎｔｅｎｔＴｙｐｅは、＜ｍｇｍｔＯｂｊ＞下位リソース４０６のタイプを指定してもよい。ｃｏｎｔｅｎｔＴｙｐｅ属性はｄａｔａＴｙｐｅ属性とも称されてもよい。

＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０は、＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４３２を含んでもよい。この＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４３２は、管理目的の複数パラメータの集合に対するプレースホルダであってもよい。＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４３２を、＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４３２への下位にすることにより、階層ツリー構造をサポートすることができ、および既存の管理オブジェクトのインポートがフラット構造に比べて容易となり得る。

＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０はまた、（ｉ）単一の管理パラメータを保持および／または格納するための＜ｐａｒａｍｅｔｅｒ＞下位リソース４３４（ｉｉ）ｘＲＥＭ目的の＜ａｃｃｅｓｓＲｉｇｈｔｓ＞ 下位リソース４３６（ｉｉｉ）＜ａｃｃｅｓｓＳｔａｔｕｓ＞下位リソース４３８、および＜ｓｕｂｓｃｒｉｐｔｉｏｎｓ＞下位リソース４４０、を含んでもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４３６は、ＲＥＭを実行するために使用される下位リソースに対するパーミッションの表現を含み、保持し、かつ／または格納してもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４３６は、親がある場合は親から継承されてもよい。

＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０は、以下の属性、（ｉ）ａｃｃｅｓｓＲｉｇｈｔＩＤ、（ｉｉ）ｃｒｅａｔｉｏｎＴｉｍｅ、（ｉｉｉ）ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、（ｉｖ）ｄｅｓｃｒｉｐｔｉｏｎ（例えば＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０のテキスト形式の詳細）（ｖ）ａｌｌｏｗｅｄＭｅｔｈｏｄ、および（ｖｉ）ｃｏｎｔｅｎｔＴｙｐｅ／ｄａｔａＴｙｐｅ、を含んでもよい。ａｌｌｏｗｅｄＭｅｔｈｏｄは、＜ｍｇｍｔＯｂｊ＞下位リソース４３６を処理するための許可されたＲＥＳＴｆｕｌメソッドを指定してもよい。ｃｏｎｔｅｎｔＴｙｐｅ／ｄａｔａＴｙｐｅは＜ｍｇｍｔＯｂｊ＞下位リソース４３６のタイプを指定してもよい。

さらに、図４Ａの例に示すように、ｍｇｍｔＯｂｊｓ４０２は、別の＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４３２を、＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０の下位に置くことにより、追加的な階層構造を有する。この下位構造では、＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０は、多くの＜ｐａｒａｍｅｔｅｒｓ＞下位リソースと個々の＜ｐａｒａｍｅｔｅｒ＞リソース４３４の両方を含んでもよい。このような階層構造は、他の管理ツリーをｍｇｍｔＯｂｊｓ４０２にインポートすることを簡素化することができ、および／またはツリー構造のマッピングを実行することを簡素化することができる。１つのコンテナ（またはグループ）リソースが、別のコンテナ（またはグループ）をその下位リソースとして持つｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ（またはメンバ）の作成および使用を可能にするように適合されないかぎり、このような階層構造は＜ｍｇｍｔＯｂｊ＞下位リソース４０６およびその子（例えば既存のコンテナまたはグループリソースを使用する）なしでは実現できない可能性があることに留意されたい。

＜ｐａｒａｍｅｔｅｒ＞リソース４３４は、（ｉ）＜ｐａｒａｍｅｔｅｒ＞下位リソース４３４のデフォルト値を含み、保持し、かつ／または格納することができる＜ｄｅｆａｕｌｔＶａｌｕｅ＞下位リソース４４４（ｉｉ）＜ｐａｒａｍｅｔｅｒ＞下位リソース４３４の現在の値を含み、保持し、かつ／または格納することができる＜ｃｕｒｒｅｎｔＶａｌｕｅ＞下位リソース４４６（ｉｉｉ）ｘＲＥＭ目的の＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４４８（ｉｖ）＜ａｃｃｅｓｓＳｔａｔｕｓ＞下位リソース４５０、および（ｖ）＜ｓｕｂｓｃｒｉｐｔｉｏｎｓ＞下位リソース４４４、を含んでもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４４８は、ＲＥＭを実行するために使用される下位リソースのパーミッションの表現を含み、保持し、かつ／または格納してもよい。＜ａｃｃｅｓｓＲｉｇｈｔｓ＞下位リソース４４８は、親がある場合は親から継承されてもよい。

＜ｐａｒａｍｅｔｅｒ＞リソース４３４は、以下の属性（ｉ）ａｃｃｅｓｓＲｉｇｈｔＩＤ（ｉｉ）ｃｒｅａｔｉｏｎＴｉｍｅ、（ｉｉｉ）ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ（ｉｖ）ｄｅｓｃｒｉｐｔｉｏｎ（例えば＜ｐａｒａｍｅｔｅｒ＞リソース４３４のテキスト形式の詳細）、およびａｌｌｏｗｅｄＭｅｔｈｏｄ、を含んでもよい。ａｌｌｏｗｅｄＭｅｔｈｏｄは＜ｐａｒａｍｅｔｅｒ＞リソース４３４を処理するための許可されたＲＥＳＴｆｕｌメソッドを指定してもよい。

代替的な実施形態において、ｍｇｍｔＯｂｊｓを備えるＳＣＬをプロビジョニングするための２つのレベルのリソース構造フレームワーク４５８を図４Ｂに示す。リソース構造フレームワーク４５８はｍｇｍｔＯｂｊｓ４６０を含んでもよい。ｍｇｍｔＯｂｊｓ４６０は、ｍｇｍｔＯｂｊｓ４６０が＜ｐａｒａｍｅｔｅｒｓ＞下位リソース４２０を含まない点を除いて、図４ＡのｍｇｍｔＯｂｊｓ４０２と同様である。

例示的なＭ２ＭのｘＲＥＭ管理モデル
一実施形態では、ｘＲＥＭは、クライアント／サーバ（Ｃ／Ｓ）モデルで実装されてもよい。加えて、かつ／またはこれに替えて、ｘＲＥＭは、プロキシ機能を使用して、Ｄ ３４ｄやＤ’３４ｅ乃至３４（図１）など、Ｍ２Ｍ ＧＷの後ろにあるＭ２Ｍデバイスを管理してもよい。

一実施形態では、ｘＲＥＭサーバは管理コントローラであってもよい。ｘＲＥＭサーバは、例えば、ＳＮＭＰマネージャ、ＯＭＡ ＤＭに準拠したＤＭサーバ、およびＢＢＦ−ＴＲ０６９に準拠したＡＣＳのいずれかとして動作してもよく、またはそれらと同様の機能により動作してもよい。ｘＲＥＭサーバは、ｘＲＥＭクライアントおよびｘＲＥＭプロキシとの対話を制御および管理してもよい。

一実施形態では、ｘＲＥＭクライアントは、ｘＲＥＭサーバによって制御されるソフトウェアエンティティであってもよい。ｘＲＥＭクライアントは、例えば、ＳＮＭＰエージェント、ＯＭＡ ＤＭに準拠したＤＭクライアント、およびＢＢＦ ＴＲ−０６９に準拠したＣＰＥのいずれかとして動作してもよく、またはそれらの同様の機能により動作してもよい。ｘＲＥＭサーバおよびｘＲＥＭクライアントは協働して管理セッションを確立し、および管理機能を実行してもよい。

一実施形態では、ｘＲＥＭプロキシは、ｘＲＥＭクライアントおよびｘＲＥＭサーバ両方の役割を果たしてもよい。ｘＲＥＭプロキシは、ＯＭＡ ＤＭ、および／もしくはＢＢＦ ＴＲ−０６９に準拠して動作するＭ２Ｍデバイス、ならびに／またはＳＣＬを有さないＭ２Ｍデバイスなど、Ｄ’タイプのデバイスを管理するための非ｘＲＥＭ管理サーバ機能を有してもよい。ｘＲＥＭプロキシは、ＲＥＭクライアントとｘＲＥＭサーバ（または非ｘＲＥＭ管理サーバ）との間の変換および／または適合（adaptation）機能を含んでもよい。例示的な機能は、ｘＲＥＭクライアントとｘＲＥＭサーバとの間の変換、およびｘＲＥＭクライアントと非ｘＲＥＭ管理サーバとの間の変換を含んでもよい。

一実施形態では、ｘＲＥＭは、位置する場所に応じて、ｘＲＥＭサーバ（マネージャ）、ｘＲＥＭクライアント（管理されるエンティティ）、またはｘＲＥＭプロキシ（マネージャおよび管理されるエンティティの両方として動作する）とすることができる。

図５は、ｘＲＥＭを実行するためのクライアント−サーバモデル５００の図を示すブロック図である。ｘＲＥＭは、ＥＴＳＩ ＴＳ １０２ ９６０に準拠して実行されてもよい。図５を参照すると、ＮＲＥＭ５０２はｘＲＥＭサーバ５０２−１を含んでもよく、サーバ５０２−１は、ＤＲＥＭ５０４およびＧＲＥＭ５０６のそれぞれｘＲＥＭクライアント５０４−１および５０６−１、またはＧＲＥＭ５１０のｘＲＥＭプロキシ５１０−１などの１つまたは複数のｘＲＥＭクライアントとの通信対話を実行する。ＮＲＥＭ５０２は、第３者の管理権限５１２、およびＮＲＥＭ５０８などの他のＮＲＥＭとの別個のインタフェースを有してもよい。ＧＲＥＭ５１０は、ｘＲＥＭクライアント５１０−２またはｘＲＥＭプロキシ５１０−１として動作してもよい。Ｍ２ＭゲートウェイがＭ２Ｍサーバによって管理されることになるエンドデバイスとして動作するときに、ＧＲＥＭ５１０は、ｘＲＥＭクライアントとして動作してもよい。Ｍ２Ｍゲートウェイが、Ｍ２ＭサーバがＭ２Ｍゲートウェイの後ろにあるＭ２Ｍデバイス（ＥＴＳＩ準拠または非ＥＴＳＩのいずれか）を管理するためのプロキシとして動作するときに、ＧＲＥＭ５１０はｘＲＥＭプロキシとして動作してもよい。ｘＲＥＭプロキシ５１０−１として、ＧＲＥＭ５１０は、ｘＲＥＭクライアント５１０−２、ｘＲＥＭサーバ５１０−３、非ｘＲＥＭ管理サーバ５１０−４、およびプロトコル変換ユニット５１０−５を含んでもよい。ＤＲＥＭ５１２ はｘＲＥＭクライアント５１２−１を含んでもよい。ｘＲＥＭクライアント５１２−１は、ＮＲＥＭ５０２におけるｘＲＥＭサーバ５０２−１と対話してもよく、あるいは、ｘＲＥＭプロキシ５１０−１におけるｘＲＥＭサーバ５１０−３と対話してもよい。

ＯＭＡ ＤＭが使用されてｘＲＥＭを実装する場合、ｘＲＥＭサーバ５０２−１は、ＤＭサーバであってもよく、およびｘＲＥＭクライアント５１２−１は、ＤＭクライアントであってもよい。ｘＲＥＭプロキシ５１０−１は、ＯＭＡ ＧｗＭＯであってもよい。ＢＢＦ ＴＲ−０６９が使用されてｘＲＥＭを実装する場合、ｘＲＥＭサーバ５０２−１は、ＡＣＳであってもよく、およびｘＲＥＭクライアント５１２−１は、ＣＰＥであってもよい。ＳＮＭＰが使用されてｘＲＥＭを実装する場合、ｘＲＥＭサーバ５０２−１は、ＳＮＭＰマネージャであってもよく、ｘＲＥＭクライアント５１２−１は、ＳＮＭＰエージェントであってもよい。ｘＲＥＭプロキシ５１０−１は、ＳＮＭＰプロキシであってもよい。

複数の管理プロトコルのサポート
一実施形態に従って、システム１０などの統合されたＭ２Ｍシステムは、複数の垂直（vertical）Ｍ２Ｍアプリケーションを含んでもよく、異なる管理プロトコルが配置されてもよい。例えば、ｘＲＥｍクライアントとしてＤＭクライアントをサポートするＭ２Ｍデバイスは、ＢＢＦ ＴＲ−０６９のみをサポートするＭ２Ｍ ＧＷ、またはＢＢＦ ＴＲ−０６９デバイスのみを管理してきたＭ２Ｍサーバに移動してもよく、および接続してもよい。代替的な形態では、他の適切なＯＭＡ ＤＭデバイスおよびＢＢＦ ＴＲ−０６９デバイスが、本発明の実施形態に従った統合されたＭ２Ｍシステムにおいて管理されてもよい。

図６は、複数の異なる管理プロトコルを使用するｘＲＥＭをサポートする、トンネルベースの手法を説明するブロック図である。ＮＲＥＭ６０２および／またはＧＲＥＭ６０４は、異なるＭ２Ｍ ＧＷおよびデバイスとの管理対話に対して、異なる管理プロトコルを使用してもよい。トンネルモジュールが以下を実行することができる。トンネルモジュールは、Ｄ／ＧＲＥＭとＮＲＥＭとの間、および／またはＧＲＥＭとＤＲＥＭとの間のネゴシエーションを実行して、使用する管理プロトコルを判定する。トンネルモジュールはまた、その判定に従ってｘＲＥＭソフトウェアの更新を実行してもよい。

トンネルモジュールは、データモデル変換を実行して、ｘＲＥＭデータモデルとＯＭＡ ＤＭｍｇｍｔオブジェクト、ＢＢＦ ＴＲ−０６９管理パラメータ、および／またはＳＮＭＰ ＭＩＢとの間で変換してもよい。トンネルモジュールはまた、ＯＭＡ ＤＭコマンドまたはＢＢＦ ＴＲ０６９コマンドとｘＲＥＭ ＲＥＳＴｆｕｌメソッドとの間の管理コマンドの変換および／またはマッピングを実行してもよい。トンネルモジュールはまた、ＯＭＡ ＤＭ、ＢＢＦ ＴＲ−０６９またはＳＮＭＰプロトコルが、ｍＩｄ基準点上でＲＥＳＴｆｕｌメソッドを使用できるように適合するプロトコル適合を実行してもよい。

管理プロトコルをネゴシエーションまたは指示する方式
例えばｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅと称するパラメータが使用されて、管理プロトコルのタイプを表してもよい。ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅは、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２ＭサーバのＳＣＬであるリソース＜ｓｃｌ＞の属性（または下位リソース）であってもよい。加えて、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅは、構成パラメータとしてＭ２Ｍ ＳＣＬ管理オブジェクト（「ＳＣＬＭＯ」と称される）に含まれてもよい。一実施形態では、Ｍ２Ｍデバイスは「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を使用して、Ｍ２ＭデバイスとＭ２Ｍサーバとの間、またはＭ２ＭデバイスとＭ２Ｍゲートウェイとの間で使用する管理プロトコルのタイプを指示してもよい。一実施形態では、Ｍ２Ｍゲートウェイは「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を使用して、Ｍ２ＭゲートウェイとＭ２Ｍサーバとの間で使用される管理プロトコルのタイプを表してもよい。このことを容易にするために、Ｍ２Ｍゲートウェイの＜ｓｃｌ＞は、属性（または下位リソース）「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を含んでもよく、およびＭ２ＭゲートウェイのＳＣＬＭＯは、パラメータ「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を含んでもよい。Ｍ２ＭデバイスがＭ２Ｍゲートウェイの後ろに存在する場合は、第２の属性（または下位リソース）「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅＥｘｔ」が使用されて、Ｍ２Ｍゲートウェイの後ろにあるＭ２ＭデバイスとＭ２Ｍゲートウェイとの間の管理プロトコルのタイプを表してもよい。

一実施形態では、Ｍ２Ｍサーバは、「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を使用して、Ｍ２Ｍデバイスおよび／またはＭ２Ｍゲートウェイを管理するために自身がサポートする管理プロトコルのタイプを表してもよい。このことを容易にするために、Ｍ２Ｍサーバの＜ｓｃｌ＞は、属性（または下位リソース）「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を含んでもよい。

一実施形態では、Ｎ−ＳＣＬ（および／またはＧ−ＳＣＬ）は、対応するＮＲＥＭおよび／またはＧＲＥＭがサポートする複数の管理プロトコルのリストを表す属性（または下位リソース）ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを含んでもよい。

代替として、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを、ｍｇｍｔＯｂｊｓリソースの属性および／または各＜ｍｇｍｔＯｂｊ＞インスタンスの属性として追加することができる。以下の方式は、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを、＜ｓｃｌ＞の属性、ｍｇｍｔＯｂｊｓリソースの属性、または＜ｍｇｍｔＯｂｊ＞リソースの属性として使用して、ＤＲＥＭおよび／またはＧＲＥＭ（「Ｄ／ＧＲＥＭ」）とＮＲＥＭとの間、および／またはＤＲＥＭとＧＲＥＭとの間の管理プロトコルをネゴシエーションまたは指示するために適用されてもよい。

図７Ａ乃至７Ｃはそれぞれ、ＲＥＭに使用する管理プロトコルのタイプを判定するための例示的なフロー７００、７３０、および７６０を説明するフローチャートである。各フロー７００、７３０、および７６０は、便宜上図１Ａ乃至１Ｃのシステム１０を参照して説明する。フロー７００、７３０、および７６０は、他のアーキテクチャを使用して実行されてもよい。

Ｄ／ＧＲＥＭとＮＲＥＭのと間
方式１−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを「ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」（ＳＣＬ登録）および／または「Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」にピギーバック（Piggyback）する

まず図７Ａのフロー７００を参照すると、Ｄ／ＧＲＥＭがＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ処理を開始してもよく（７０２）、その間にＤ／ＧＲＥＭは、１つまたは複数の要求（「ＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＱＵＥＳＴ」（ＳＣＬ登録要求））メッセージをＭ２Ｍサーバ（ＮＲＥＭ）に送信してもよい。ＳＣＬ登録処理開始（７０２）の一部として、その前、かつ／またはその後に、Ｄ／ＧＲＥＭは、Ｄ／Ｇ−ＳＣＬの「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」属性／下位リソースから、Ｄ／ＧＲＥＭがサポートする管理プロトコルのタイプを示す値（「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）」）を読み出してもよい。

Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）は次いで、ＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージの１つまたは複数を選択してもよく、および当該メッセージを、パラメータとしてのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）で埋めてもよく（populate）、ならびにそのＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＱＵＥＳＴ［ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）］メッセージを、Ｍ２Ｍサーバ（ＮＲＥＭ）に送信してもよい（７０４）。ＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＱＵＥＳＴ［ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）］メッセージに応答して、Ｍ２Ｍサーバ（ＮＲＥＭ）は、１つまたは複数の応答（「ＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」（ＳＣＬ登録応答））メッセージを選択してもよく、および当該メッセージを、パラメータとしてのその受信したｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）で埋めてもよい（populate）。その後、Ｍ２Ｍサーバ（ＮＲＥＭ）は、そのＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥ［ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）］メッセージを、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）に送信して、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）の受信、および／または受信したｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにより示される管理プロトコルのタイプの受付を確認応答してもよい（７０６）。ＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥ［ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）］メッセージの受信、およびもし存在すれば、ＳＣＬ登録処理を完了するための他のメッセージ（ある場合）の受信後、Ｄ／ＧＲＥＭはＳＣＬ登録処理を終了してもよい（７０８）。フロー７００を実行することにより、Ｄ／ＧＲＥＭは、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ属性／下位リソースをＳＣＬ登録処理上にピギーバックして、ＲＥＭを実行する際にＭ２Ｍサーバ（ＮＲＥＭ）およびＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）が使用することができる管理プロトコルのタイプの通知および／または受付けを容易にしてもよい。

図には示さないが、Ｍ２Ｍサーバ（ＮＲＥＭ）は、要求されないで、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ属性／下位リソースをＳＣＬ登録処理上にピギーバックして、Ｎ−ＳＣＬのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ属性／下位リソースにより指定され、あるいは指示された管理プロトコルのタイプを使用するようにＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）に指示してもよい。Ｍ２Ｍサーバ（ＮＲＥＭ）は、例えば、Ｎ−ＳＣＬのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ属性／下位リソースからｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）を読み出し、１つまたは複数のＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージを、パラメータとしてのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）で埋め、および埋められたＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥ［ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）］メッセージをＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）に送信してもよい。

代替として、Ｍ２Ｍサーバ（ＮＲＥＭ）およびＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）は、Ｍ２Ｍサーバ（ＮＲＥＭ）またはＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）のいずれかが、受信したｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）を他方に送信するまで、それぞれのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ（値）で埋められたＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージおよびＳＣＬ ＲＥＧＩＳＴＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージを交換することにより、使用する管理プロトコルのタイプをネゴシエーションしてもよい。

図７Ｂ乃至７Ｃを参照すると、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＵｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ（ＳＣＬ登録更新）にピギーバックする処理は以下の通りである。

Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎの処理中に、Ｍ２Ｍサーバ（ＮＲＥＭ）は、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）に送信されるメッセージにそれをピギーバックすることにより、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）により使用されることになる「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を指定することができる。

あるいは、「Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」の処理中に、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）は、Ｍ２Ｍサーバ（ＮＲＥＭ）に送信されるメッセージに「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をピギーバックすることにより、Ｍ２Ｍサーバ（ＮＲＥＭ）に自身の「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をレポートすることができる。

方式２−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを「ｍｇｍｔＯｂｊリソースの作成」にピギーバックする
ＥＴＳＩ Ｍ２Ｍ機能アーキテクチャは、管理オブジェクトリソースを作成するための以下のプロシージャを定義している。その結果、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをそれらのプロシージャに埋め込むことができ、それによりＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）が自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＭ２Ｍサーバ（ＮＲＥＭ）に通知することができるようにする。

図８に示すように、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをｍｇｍｔＯｂｊリソースの作成にピギーバックする処理は以下の通りである。

この処理がＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）によって開始される場合は、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）はこの処理中に要求メッセージをＭ２Ｍサーバ（ＮＲＥＭ）に送信する。Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）は、「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をパラメータとしてその要求メッセージにピギーバックすることができる。

方式３−「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を送信するための新たなプロシージャを作成する
方式２および方式３で説明したように「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を既存のＭ２Ｍプロシージャにピギーバック代わりに、以下のプロシージャは、Ｍ２Ｍサーバ（ＮＲＥＭ）とＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）との間で「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を送信するための処理を定義する。図９に示すように、本処理は以下の通りである。

「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」の更新
Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）は、＜ｓｃｌ−ｏｆ−ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ｓｃｌ−ｄｇ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する更新メッセージを送信して、「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を更新する。

＜ｓｃｌ−ｏｆ−ｓｅｒｖｅｒ＞はＭ２Ｍサーバを表す。＜ｓｃｌ−ｄｇ＞は、自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅのＭ２Ｍサーバを更新するためのＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）を表す。「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」は、＜ｓｃｌ−ｄｇ＞の新たな属性であってもよい。その結果、Ｍ２Ｍサーバ（ＮＲＥＭ）は、Ｍ２Ｍサーバに登録するＭ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）の「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を認識する。

ＮＲＥＭはまた、図１０に示すように、＜ｓｃｌ−ｄｇ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する更新メッセージを能動的に送信して、Ｍ２Ｍデバイス／ゲートウェイの「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を変更してもよい。

代替として、ＮＲＥＭはまた、＜ｓｃｌ−ｄｇ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する読出メッセージを送信して、Ｍ２Ｍデバイス／ゲートウェイにおいて使用される現在の管理プロトコルを読み出してもよい。

方式４−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＳＣＬ検出にピギーバックする
ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを、以下の方式を使用してＳＣＬ検出のためのメッセージにピギーバックすることもできる。図１１に示すように、Ｍ２Ｍデバイス／ゲートウェイ（Ｄ／ＧＲＥＭ）がＭ２Ｍサーバ（ＮＳＣＬ）を検出する要求メッセージを発行するときに、Ｍ２Ｍデバイス／ゲートウェイは自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをその要求メッセージに含める。ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ情報は、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにより示される管理プロトコルをサポートしないＭ２Ｍサーバをフィルタリングすることを支援す ることができる。

Ｍ２ＭサーバのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅは、Ｍ２Ｍデバイス／ゲートウェイへのＳＣＬ ＤＩＳＣＯＶＥＲＹ ＲＥＳＰＯＮＳＥメッセージにピギーバックされてもよい。ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅは、Ｍ２Ｍデバイス／ゲートウェイが適切なＭ２Ｍサーバを選択することを支援することができる。Ｍ２Ｍデバイス／ゲートウェイはまた、ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにより示される管理プロトコルを使用するように変更することができる。

ＤＲＥＭとＧＲＥＭとの間
この場合、Ｍ２Ｍデバイスは、プロキシとしてのＭ２Ｍゲートウェイの後ろにある。その結果、Ｍ２Ｍデバイスは、各自のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＭ２Ｍゲートウェイに指示する必要があり、またはＭ２Ｍゲートウェイが能動的にＭ２ＭデバイスのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを読み出すことができる。上記の事例１と同様の方式を利用することができる。

方式１−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを「ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」および「Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」にピギーバックする
ＥＴＳＩ Ｍ２Ｍ機能アーキテクチャは、ＳＣＬ管理のために以下のプロシージャを定義しており、その結果、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをそれらのプロシージャに埋め込むことができ、それによりＤＲＥＭが自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＧＲＥＭに通知することができる。

ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ
この処理中に、ＤＳＣＬはＮＳＣＬに複数の要求メッセージを送信する。ＤＲＥＭは、それらの要求メッセージのいずれか１つにパラメータとして「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をピギーバックすることができる。加えて、ＧＲＥＭは、ＤＲＥＭへの応答メッセージに「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をピギーバックして、「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」により指定される管理プロトコルを使用するようにＤＲＥＭに指示することができる。

Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ
「Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」の処理中に、ＧＲＥＭは、ＤＲＥＭに送信されるメッセージにｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをピギーバックすることにより、ＤＲＥＭにより使用されることになる「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を指定することができる。「Ｕｐｄａｔｅ ＳＣＬ Ｒｅｇｉｓｔｒａｔｉｏｎ」の処理中に、ＤＲＥＭは、ＧＲＥＭに送信されるメッセージに「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をピギーバックすることにより、自身の「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をＧＲＥＭにレポートすることができる。

方式２−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを「ｍｇｍｔＯｂｊリソースの作成」にピギーバックする
ＥＴＳＩ Ｍ２Ｍ機能アーキテクチャは、管理オブジェクトリソースを作成するために以下のプロシージャを定義している。その結果、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをそれらのプロシージャに埋め込むことができ、それによりＤＲＥＭが自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅをＧＲＥＭに通知することができる。

ｍｇｍｔＯｂｊリソースを作成する
この処理がＤＳＣＬ（ＤＲＥＭ）によって開始される場合、ＤＳＣＬは、要求メッセージをＮＧＳＣＬに送信する。この処理中に、ＤＲＥＭは、「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」をパラメータとしてその要求メッセージにピギーバックすることができる。

方式３−「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を送信するための新たなプロシージャを作成する
方式２および方式３で説明したように「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を既存のＭ２Ｍプロシージャにピギーバックする代わりに、以下のプロシージャを利用してＧＲＥＭとＤＲＥＭと間で「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を送信することもできる。

「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を更新する
Ｍ２Ｍデバイス（ＤＲＥＭ）は、＜ｓｃｌ−ｏｆ− ｇｗ＞／ｓｃｌｓ／＜ｓｃｌ−ｄ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する更新メッセージを送信して「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を更新する。＜ｓｃｌ−ｏｆ−ｇｗ＞はＭ２Ｍゲートウェイを表す。＜ｓｃｌ−ｄ＞は、Ｍ２Ｍゲートウェイに登録し、そのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅのＭ２Ｍゲートウェイを更新しているＭ２Ｍデバイスを表す。「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」は＜ｓｃｌ−ｄ＞の属性である。その結果、Ｍ２Ｍゲートウェイ（ＧＲＥＭ）は、Ｍ２Ｍゲートウェイに登録するＭ２Ｍデバイス（ＤＲＥＭ）の「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を認識する。

Ｍ２Ｍゲートウェイ（ＧＲＥＭ）はまた、＜ｓｃｌ−ｄ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する更新メッセージを能動的に送信して、Ｍ２Ｍデバイスの「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を変更することができる。

「ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ」を読み出す
Ｍ２Ｍゲートウェイ（ＧＲＥＭ）は、＜ｓｃｌ−ｄ＞／ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにアドレス指定する読出メッセージを送信して、Ｍ２Ｍデバイスで使用されている現在の管理プロトコルを読み出す。

方式４−ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐeをＳＣＬ検出にピギーバックする
ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅはまた、以下の手法を使用して、ＳＣＬ検出のためのメッセージにピギーバックされてもよい。

Ｍ２Ｍデバイス（ＤＲＥＭ）が、Ｍ２Ｍゲートウェイ（ＧＳＣＬ）を検出するための要求メッセージを発行するときに、Ｍ２Ｍデバイスは自身のｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを要求メッセージに含める。ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅ情報は、ｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにより示される管理プロトコルをサポートしないＭ２Ｍゲートウェイをフィルタリングすることを支援することができる。

Ｍ２ＭゲートウェイのｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅを、Ｍ２ＭデバイスへのＳＣＬ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージにピギーバックすることができる。ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅは、Ｍ２Ｍデバイスが適切なＭ２Ｍゲートウェイを選択することを支援することができる。Ｍ２Ｍデバイスはまた、ピギーバックされたｍｇｍｔＰｒｏｔｏｃｏｌＴｙｐｅにより示される管理プロトコルを使用するように変更することができる。

すべてのアクセス履歴に対する例示的なリソース定義
リモートエンティティ管理を目的に、要求元／発行元ＳＣＬが受信側−ＳＣＬのローカルリソース毎に有していたすべてのアクセス履歴を、受信側−ＳＣＬが記録（log）しておくことが重要である場合がある。現在のＥＴＳＩ Ｍ２Ｍ機能アーキテクチャは、リソースａｃｃｅｓｓＳｔａｔｕｓを定義しているが、これは、過去におけるリソースに対するすべてのオペレーションではなく、最後のアクセス（読出／更新／サブスクライブ）のみを記録するものである。すべてのアクセス履歴の格納を容易にするために、ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓと称する新たなリソースが本開示において定義される。ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓに対する関連するオペレーションも定義される。

リソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓ
ａｃｃｅｓｓＳｔａｔｕｓに基づいて、図１２の例に示すようにａｃｃｅｓｓＨｉｓｔｏｒｉｅｓが定義されてもよい。図１２は、リソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓの例示的な構造を示す。図１２を参照すると、ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓは以下の構成要素を含んでもよい。
・「ａｔｔｒｉｂｕｔｅ」はａｃｃｅｓｓＲｉｇｈｔＩＤを有してもよい。
・ｓｔａｔｕｓ：アクセス履歴の記録を開始または停止するかどうかを表すために使用される。
・＜ａｃｃｅｓｓｌｎｓｔａｎｃｅ＞：アクセスインスタンスの数。

各＜ａｃｃｅｓｓｌｎｓｔａｎｃｅ＞は、それについてのアクセスの詳細を記録する以下の下位リソースを有してもよい。
・ｍｅｔｈｏｄ：そのアクセスに関連するメソッド、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ、Ｓｕｂｓｃｒｉｐｔｉｏｎ、またはＡｎｎｏｕｎｃｅであってもよい。
・ｒｅｑｕｅｓｔｏｒＩＤ：そのアクセスを要求しているエンティティのＩＤ。
・ｒｅｓｏｕｒｃｅＵＲＩ：そのアクセスが動作すべきリソースのＵＲＩ。
・ｔｉｍｅＳｔａｍｐ：そのアクセスが発生した時刻。
・ｓｅｑｕｅｎｃｅＮｕｍｂｅｒ：アクセスの順序を表す、自動的に増分する整数。
・ｒｅｓｕｌｔ：その動作の結果。
−メソッドが更新の場合は、ｒｅｓｏｕｒｃｅＵＲＩの新たな値を表す。
−他のメソッドに対するＳｕｃｃｅｓｓまたはＦａｉｌｕｒｅとすることもできる。障害管理のためにここで種々のタイプのＦａｉｌｕｒｅを定義することが可能である。

リソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓは、Ｍ２ＭデバイスおよびＧＷに格納されてもよい。デバイス／ＧＷにおいてローカルリソースに対するオペレーションが存在するといつでも、ａｃｃｅｓｓＩｎｓｔａｎｃｅが自動的に作成され、ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓに追加される。リソースとして、ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓは多くの場合、管理の目的でＮＲＥＭによりアクセスされてもよい。言い換えると、ＮＲＥＭはＤ／ＧＲＥＭに関するａｃｃｅｓｓＨｉｓｔｏｒｉｅｓを作成／読出／更新／削除することができる。以下の機能が実装されてもよい。
・Ｃｒｅａｔｅ：ＮＲＥＭが、特定の時間間隔もしくは恒久的に特定の「ｍｅｔｈｏｄ」および／または「ｒｅｓｏｕｒｃｅＵＲＩ」についてのａｃｃｅｓｓＨｉｓｔｏｒｉｅｓを作成するようにＤ／ＧＲＥＭに要求する。
・Ｒｅｔｒｉｅｖｅ：ＮＲＥＭがＤ／ＧＲＥＭからすべてのまたは一部の＜ａｃｃｅｓｓＩｎｓｔａｎｃｅ＞を読み出す。
・Ｕｐｄａｔｅ：ＮＲＥＭが、「ｓｔａｔｕｓ」の値を変更することによりアクセス履歴機能を無効または再開するようにＤ／ＧＲＥＭに要求する。
・Ｄｅｌｅｔｅ：ＮＲＥＭがすべてのまたは一部の＜ａｃｃｅｓｓＩｎｓｔａｎｃｅ＞を削除するようにＧ／ＧＲＥＭに要求する。

図１２に示す＜ａｃｃｅｓｓＩｎｓｔａｎｃｅ＞はフラット構造であり、これを図１３に示すように「ｍｅｔｈｏｄ」および／または図１４に示すよう「ｒｅｑｕｅｓｔｏｒＩＤ」に基づいて再構成して、それぞれ２レベルおよび３レベルの階層構造を形成することができる。図１３は、「メソッド」に基づいて構造化されたリソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓについての例示的構造を示す。図１４は、「ｍｅｔｈｏｄ」および「ｒｅｑｕｅｓｔｏｒＩＤ」に基づいて構造化されたリソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓについての例示的構造を示す。このような階層構造は、特にリソースに制約があるＭ２ＭデバイスにおいてリソースａｃｃｅｓｓＨｉｓｔｏｒｉｅｓへのクエリ／読出オペレーションを迅速化するのに有用である場合がある。

ｘＲＥＭについての管理権限委譲に対する例示的なコールフロー
Ｍ２Ｍデバイスおよび／またはＧＷの管理権限は、別のＭ２Ｍサーバに委譲されてもよい。Ｍ２Ｍデバイスの管理権限を、別のＭ２Ｍ ＧＷに委譲することもできる。本開示の実施形態に従って、Ｍ２ＭデバイスおよびＧＷについての管理権限の委譲プロシージャが本明細書に記載される。

管理権限委譲
委譲元により開始される委譲
図１５は、管理権限委譲（委譲元により開始される）についてのプロシージャのメッセージフローチャートを示す。図１５を参照すると、Ｎ−ＳＣＬ−１がＤ／Ｇ−ＳＣＬを他のＮ−ＳＣＬに委譲する。Ｎ−ＳＣＬ１は、Ｄ／Ｇ−ＳＣＬがオンラインになった後に「ＤＥＬＥＧＡＴＩＯＮ ＰＲＥＰＡＲＡＴＩＯＮ」（委譲の準備）をＤ／Ｇ−ＳＣＬに発行する。「ＤＥＬＥＧＡＴＩＯＮ ＰＲＥＰＡＲＡＴＩＯＮ」が使用されて、進行中の委譲動作を行える状態になるようにＤ／Ｇ−ＳＣＬに指示することができる。Ｄ／Ｇ−ＳＣＬは「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」（委譲応答）をＮ−ＳＣＬ１に送り返すことができる。Ｄ／Ｇはその後オンライン状態のままでいてもよい。Ｎ−ＳＣＬ１は、Ｄ／Ｇ ＳＣＬに対する新たな管理権限として選択されたＮ−ＳＣＬ Ｘ に「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」（委譲要求）を発行してもよい。「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」は以下の情報を含んでもよい。
・委譲されることになるのＤ／Ｇ−ＳＣＬのＵＲＩおよび／または認証に関連する情報
・管理委譲を要求する理由

Ｎ−ＳＣＬ Ｘは、「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」にＹＥＳまたはＮＯを回答することにより、Ｎ−ＳＣＬ１に「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」を送り返してもよい。Ｎ−ＳＣＬ１は、委譲を受け入れることに同意するＮ−ＳＣＬを発見し、または最大回数を試行するまで、他のＮ−ＳＣＬに「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」を繰り返し送信してもよい。

Ｎ−ＳＣＬ １は「ＤＥＬＥＧＡＴＩＯＮ ＩＮＦＯＲＭ」（委譲通知）をＤ／Ｇ−ＳＣＬに発行してもよい。同意するＮ−ＳＣＬ Ｘがない場合、Ｎ−ＳＣＬ １はこのメッセージを使用して、進行中の委譲を取り消すことをＤ／Ｇ−ＳＣＬに通知してもよい。そしてＤ／Ｇは通常通りに動作することができる。その後スリープ状態に移ることができる。そして、委譲処理全体が停止してもよい。そうでない場合は、「ＤＥＬＥＧＡＴＩＯＮ ＩＮＦＯＲＭ」は、委譲を受け入れることに同意するＮ−ＳＣＬ Ｘについての情報を含む。Ｄ／Ｇ−ＳＣＬは「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」を送り返してもよい。

Ｎ−ＳＣＬ １は「ＤＥＬＥＧＡＴＩＯＮ ＳＴＡＲＴ」（委譲開始）をＮ−ＳＣＬ Ｘに発行して、委譲動作を実行するようにそれをトリガしてもよい。

Ｎ−ＳＣＬ Ｘは、Ｄ／Ｇ−ＳＣＬ に「ＤＥＬＥＧＡＴＩＯＮ ＥＸＥＣＵＴＩＯＮ」（委譲実行）を発行してもよい。Ｄ／Ｇ−ＳＣＬはＮ−ＳＣＬ Ｘに対する認証を実行してもよい。

Ｄ／Ｇ−ＳＣＬはＮ−ＳＣＬ Ｘに「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」を送り返してもよい。Ｄ／Ｇ ＳＣＬは、Ｎ−ＳＣＬ Ｘをその新たな管理権限に設定することにより、自身の管理オブジェクトを更新してもよい。Ｎ−ＳＣＬ Ｘは、Ｄ／Ｇ−ＳＣＬを自身の権限下にある管理されるエンティティとして含めることにより、自身の管理オブジェクトを更新してもよい。

Ｎ−ＳＣＬ Ｘは、Ｎ−ＳＣＬ １に「ＤＥＬＥＧＡＴＩＯＮ ＦＩＮＩＳＨ」（委譲終了）を発行してもよい。

Ｎ−ＳＣＬ １は、Ｎ−ＳＣＬ Ｘに「ＤＥＬＥＧＡＴＩＯＮ ＡＣＫ」（委譲確認応答）を送り返してもよい。

Ｎ−ＳＣＬ １は、自身の管理権限からＤ／Ｇ−ＳＣＬを除くことにより、自身の管理オブジェクトを更新してもよい。

Ｎ−ＳＣＬ １は、管理権限を委譲する先のエンティティとしてＮ−ＳＣＬ Ｘを追加することにより、自身の管理オブジェクトを更新してもよい。

Ｎ−ＳＣＬ Ｘは、管理権限を委譲する元のエンティティとしてＮ−ＳＣＬ １を追加することにより、自身の管理オブジェクトを更新してもよい。

デバイスにより開始される委譲
図１６は、管理権限委譲（デバイスにより開始される）の例示的なメッセージフローチャートを示す。このことは、Ｄ／Ｇが能動的に管理権限の委譲を要求するシナリオで適用されてもよい。委譲元により開始される委譲との唯一の相違は、最初の２つのステップである。図１６を参照すると、Ｄ／Ｇ−ＳＣＬは「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」をＮ−ＳＣＬ １に発行する。Ｄ／Ｇ−ＳＣＬは、このメッセージで委譲を要求する理由を指示することができる。Ｎ−ＳＣＬ １は、委譲を実行する自身の意思をＤ／Ｇ−ＳＣＬに通知することにより、「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」をＤ／Ｇ−ＳＣＬに送り返してもよい。Ｎ−ＳＣＬ １は委譲を実行することを拒否してもよい。そして、委譲処理全体が停止してよい。

図１６と異なり、代替として、Ｄ／Ｇは、委譲先（新たな管理権限）に直接「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」を送信してもよい。そして、委譲先が委譲元に承認を求める要求をすることができる。例示的な詳細なプロシージャが図１７において示され、図１７は、管理権限委譲（デバイスにより委譲先に直接開始される）の例示的なメッセージフローチャートを説明する。このシナリオは、委譲元が事前にデバイスへのいくつかの考えられる委譲先を構成する必要があり、およびデバイスと委譲元との間の通信に問題が生じたときに発生する場合がある。

委譲先により開始される委譲
委譲元により開始される委譲およびデバイスにより開始される委譲に加えて、管理権限の委譲を場合によっては委譲先により開始することもできる。例えば、図１８は、管理権限の委譲（委譲先により開始される）についての例示的なメッセージフローチャートを示す。図１８を参照すると、Ｎ−ＳＣＬ ＸがＮ−ＳＣＬ １に委譲を要求してもよい。Ｎ−ＳＣＬ １は、Ｄ／Ｇ−ＳＣＬの管理権限をＮ−ＳＣＬ Ｘに委譲することを承認してもよい。各ステップの意義は図１６に関連して説明したステップと同様である。

プロキシとしてのゲートウェイの下での委譲
一部のデバイスがゲートウェイの後ろにあるシナリオでは、管理権限の委譲はプロキシとしてのゲートウェイを介して実行されてもよい。例えば、図１９は、管理権限の委譲（プロキシとしてのゲートウェイ）についての例示的なメッセージフローチャートを示す。図１９を参照すると、Ｎ−ＳＣＬ−１は、プロキシとしてのＧ−ＳＣＬを介して、Ｄ−ＳＣＬをＮ−ＳＣＬ Ｘに委譲してもよい。Ｇ−ＳＣＬが実際には、委譲の集約を実行する。基本的に、Ｇ−ＳＣＬが、その後ろにあるＤまたはＤ’の代わりに、図１６と同様のプロシージャを使用して、Ｎ−ＳＣＬ １およびＮ−ＳＣＬ Ｘによる管理権限の委譲を実行してもよい。ＤまたはＤ’がオンラインになるときに、Ｇ−ＳＣＬは、委譲の結果、すなわち新たな管理権限Ｎ−ＳＣＬ Ｘをそれらに通知する。

デバイスツーゲートウェイ委譲
一実施形態では、Ｄ−ＳＣＬの管理権限はＧ−ＳＣＬ １から別のＧ−ＳＣＬ Ｘに委譲される。例えば、図２０は、管理権限委譲（デバイスツーゲートウェイ委譲）についての例示的なメッセージフローチャートを示す。図２０を参照すると、Ｄ−ＳＣＬ、Ｇ−ＳＣＬ １、およびＧ−ＳＣＬ Ｘ間の委譲処理の後、Ｇ−ＳＣＬ １は、委譲の結果をＮ−ＳＣＬ １に通知してもよい。

階層的ＳＣＬ構造
図２１は一般的なシナリオの図を示し、このシナリオでは、１）すべてのＳＣＬの管理権限関係が階層構造を形成し、２）ＳＣＬ４が自身のＳＣＬ９に対する管理権限をＳＣＬ３に委譲することを要求する。基本的には次の３つのステップに従う。
・ステップ１：ＳＣＬ４は、ＳＣＬ２およびＳＣＬ１を介して、ホップバイホップ（hop-by-hop）で最終的にＳＣＬ３に「ＤＥＬＥＧＡＴＩＯＮ ＲＥＱＵＥＳＴ」を発行する。
・ステップ２：ＳＣＬ３は、「ＤＥＬＥＧＡＴＩＯＮ ＲＥＳＰＯＮＳＥ」をＳＣＬ４に送り返す。
・ステップ３：ＳＣＬ４は、「ＤＥＬＥＧＡＴＩＯＮ ＩＮＦＯＲＭ」をＳＣＬ９に発行する。
・ステップ４：ＳＣＬ３およびＳＣＬ９は、「ＤＥＬＥＧＡＴＩＯＮ ＥＸＥＣＵＴＩＯＮ」に関連する対話を実行する。
・ステップ５：ＳＣＬ３は、ＳＣＬ１およびＳＣＬ２を介して、ホップバイホップで最終的にＳＣＬ４に「ＤＥＬＥＧＡＴＩＯＮ ＩＮＦＯＲＭ」を送信する。
ＳＣＬ１、ＳＣＬ２、およびＳＣＬ４は、それらの管理オブジェクトを更新し、それに応じてこの管理権限の変更を反映させてもよい。

例示的なｘＲＥＭ権限委譲
ＮＲＥＭは、ＤＲＥＭおよびＧＲＥＭを管理する役割を担う。しかし、ＥＴＳＩ ｘＲＥＭは、リモートエンティティ管理（ｘＲＥＭ）権限の概念も、ｘＲＥＭの権限委譲の概念も記載していない。Ｍ２ＭデバイスまたはＧＷのｘＲＥＭ権限は、Ｍ２Ｍサーバの交換、ロードバランス、および移動性等の理由で、Ｍ２Ｍサーバから別のＭ２Ｍサーバに委譲される必要がある。Ｍ２ＭデバイスがＭ２Ｍ ＧＷの後ろにある状態になった場合、またはその逆の場合には、Ｍ２ＭデバイスのｘＲＥＭ権限さえもＭ２ＭサーバからＭ２Ｍ ＧＷに委譲することができる。

ＯＭＡ−ＤＭは、クライアントの権限委譲についての高レベルのプロシージャを定義しているが、スリープ状態のデバイスや中間にあるＭ２Ｍ ＧＷについては考慮しない。その結果、ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭに直接適用することができない。ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭは、自身のｘＲＥＭ権限委譲を有する必要がある。

Ｍ２ＭデバイスまたはＧＷがＭ２Ｍサーバへの登録に成功すると、Ｍ２Ｍサーバは基本的にＭ２Ｍデバイス／ＧＷについてのｘＲＥＭ権限を所有する。Ｍ２ＭデバイスがＭ２Ｍ ＧＷの後ろにあるときに、ＧＷがそれらのＭ２Ｍデバイス上のｘＲＥＭ権限を有する。したがって、ｘＲＥｍ権限の委譲は以下のようにいくつかの異なるシナリオを意味する場合がある。
ケース１：Ｍ２Ｍサーバが自身のｘＲＥＭ権限を別のＭ２Ｍサーバに委譲する。
ケース２：Ｍ２Ｍサーバが自身のｘＲＥＭ権限をＭ２Ｍ ＧＷに委譲する。
ケース３：Ｍ２Ｍ ＧＷが自身のｘＲＥＭ権限をＭ２Ｍサーバに委譲する。
ケース４：Ｍ２Ｍ ＧＷが自身のｘＲＥＭ権限を別のＭ２Ｍ ＧＷに委譲する。

ｘＲＥＭについての例示的機能
その結果、ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭは、ｘＲＥＭの権限委譲をサポートするための新たな機能を有する必要がある。ネットワークリモートエンティティ管理（ＮＲＥＭ）は以下の機能、ｘＲＥＭ権限委譲を支援する機能、を有する必要がある。ＮＲＥＭはＭ２ＭデバイスおよびＭ２ＭゲートウェイについてのｘＲＥＭ権限を有する。ＮＲＥＭは、ｘＲＥＭの権限委譲をサポートするために以下の機能、Ｍ２ＭデバイスおよびＭ２ＭゲートウェイについてのｘＲＥＭ権限を別のＭ２Ｍサーバに委譲する機能、またはＭ２ＭデバイスについてのｘＲＥＭ権限をＭ２Ｍゲートウェイに委譲する機能、別のＭ２ＭサーバまたはＭ２Ｍゲートウェイから要求されるｘＲＥＭ権限委譲を処理する機能、を有する必要がある。。管理されるＭ２ＭエリアネットワークのＭ２Ｍデバイスに対してリモート管理プロキシとして機能するときに、ゲートウェイリモートエンティティ管理（ＧＲＥＭ）は以下の機能を有する必要がある。

ｘＲＥＭ権限委譲をサポートする機能。Ｍ２ＭデバイスがＭ２Ｍゲートウェイの後ろにあるときに、Ｍ２Ｍゲートウェイが、それらのＭ２ＭデバイスについてのｘＲＥＭ権限を有する。ｘＲＥＭ権限の委譲をサポートするために、Ｍ２Ｍゲートウェイは以下の機能、Ｍ２Ｍデバイスについての自身のｘＲＥＭ権限をＭ２Ｍサーバまたは別のＭ２Ｍゲートウェイに委譲する機能、別のＭ２ＭサーバまたはＭ２ＭゲートウェイからのｘＲＥＭ権限の委譲メッセージを処理する機能、ｘＲＥＭ権限委譲をサポートする機能、を有する必要がある。Ｍ２ＭサーバはＭ２ＭゲートウェイについてのｘＲＥＭ権限を有する。

Ｍ２Ｍゲートウェイは以下の機能、Ｍ２ＭゲートウェイについてのｘＲＥＭ権限を別のＭ２Ｍサーバに委譲するようにＭ２Ｍサーバに能動的に要求する機能、およびＭ２ＭサーバからのｘＲＥＭ権限委譲メッセージを受動的に処理する機能、を有する必要がある。

デバイスリモートエンティティ管理（ＤＲＥＭ）は、以下の機能、ｘＲＥＭ権限委譲をサポートする機能を有する必要がある。Ｍ２Ｍサーバは、Ｍ２ＭデバイスについてのｘＲＥＭ権限を有する。

Ｍ２Ｍデバイスは以下の機能、Ｍ２Ｍデバイスについての自身のｘＲＥＭ権限を別のＭ２Ｍサーバに委譲するように能動的にＭ２Ｍサーバに要求する機能、およびＭ２ＭサーバからのｘＲＥＭ権限委譲メッセージを受動的に処理する機能、を有する必要がある。

例示的な非ＲＥＳＴｆｕｌ管理コマンドサポート
本発明では、非ＲＥＳＴｆｕｌ管理コマンドがＲＥＳＴｆｕｌな方式で表され、および実現される、Ｍ２Ｍ ｘＲＥＭについてのシステム、装置、および方法の実施形態が提供される。そのような非ＲＥＳＴｆｕｌ管理コマンドの例は、デバイスをリブートするリブートコマンド、ダウンロードコマンドの受信者にファイルのダウンロードを指示するダウンロードコマンド、特定の処理を実行する実行コマンド、１つの場所から別の場所にリソースを複製および／または移動するコピーコマンド、のうちのいずれかを含んでもよい。リブートコマンドおよびダウンロードコマンドはそれぞれ、例えばＢＢＦ−ＴＲ０６９に準じて定義されてもよい。実行コマンドおよびコピーコマンドは、例えばＯＭＡ−ＤＭの「Ｅｘｅｃ」コマンドおよびＯＭＡ−ＤＭの「Ｃｏｐｙ」コマンドであってもよい。非ＲＥＳＴｆｕｌ管理コマンドはまた、例えば制御可能要素を備えるＭ２Ｍデバイスの制御可能要素（例えばアクチュエータ）の制御に使用される１つまたは複数のコマンドなどの他のコマンドも含んでもよい。

１つまたは複数の実施形態では、リソースコマンドと呼ばれるリソースが使用されて、非ＲＥＳＴｆｕｌ管理コマンドを表し、およびコマンドの１つまたは複数の発行元により指定される異なる方式での非ＲＥＳＴｆｕｌ管理コマンドの実行（「コマンド実行」）をサポートしてもよい。リソースコマンドが使用されて、任意のＲＥＳＴｆｕｌメソッドを使用するデバイスにおいて、非ＲＥＳＴｆｕｌ管理コマンドの発行およびコマンド実行を容易にしてもよい。

さらに、リソースコマンドが使用されて、任意の非ＲＥＳＴｆｕｌ管理コマンドについて、中間コマンド実行、遅延の後の（例えばランダムな）コマンド実行、１回のコマンド実行（例えばワンタイムコマンド実行）、および／または複数の反復されるコマンド実行を容易にしてもよい。

図２２Ａは、リソースコマンド（「＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞」）を表すデータ構造のインスタンスを有する＜ｓｃｌｂａｓｅ＞の例示的データ構造を示すブロック図である。＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞は、図２２Ａに示すものなどのいくつかのデータ構造要素を含んでもよい。示されるそれらのデータ構造要素の中には、属性を表すデータ構造要素（「ａｔｔｒｉｂｕｔｅ」）、下位リソースのｅｘｅｃＭｏｄｅ、ｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＳｔａｒｔＴｉｍｅ、ｅｘｅｃＤｕｒａｔｉｏｎ、ｅｘｅｃＲｅｓｕｌｔ、ｅｘｅｃＳｔａｔｕｓ、ｒｅｑｕｅｓｔｏｒＩＤ、およびａｃｔｏｒＩＤを表すデータ構造要素がある。「ａｔｔｒｉｂｕｔｅ」は、上記説明したａｃｃｅｓｓＲｉｇｈｔＩＤをんでもよい。

ｅｘｅｃＭｏｄｅは、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞の非ＲＥＳＴｆｕｌ管理コマンドのコマンド実行の特定のモードを指定するために使用されてもよい。ｅｘｅｃＭｏｄｅデータ構造要素は、コマンド実行についてのモード（「コマンド実行モード」）を表す１つまたは複数のエントリを含んでもよい。コマンド実行モードの例は、Ｉｍｍｅｄｉａｔｅ Ｏｎｃｅモード、Ｉｍｍｅｄｉａｔｅ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモード、Ｒａｎｄｏｍ Ｏｎｃｅモード、およびＲａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモードを含んでもよい。

Ｉｍｍｅｄｉａｔｅ Ｏｎｃｅモードは、コマンド実行を直ちに、一度のみ行うことを指定する。Ｉｍｍｅｄｉａｔｅ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモードは、コマンド実行を直ちに、かつ繰り返し行うことを指定する。任意の２つのコマンド実行間の時間間隔はｅｘｅｃＰａｒａｍｅｔｅｒにおいて指定されてもよい。Ｒａｎｄｏｍ Ｏｎｃｅモードは、コマンド実行を（例えばランダムな）遅延の後にかつ一度のみ行うことを指定する。遅延はｅｘｅｃＰａｒａｍｅｔｅｒにおいて指定されてもよい。Ｒａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモードは、コマンド実行を（例えばランダムな）遅延の後に繰り返し行うことを指定する。遅延および２つのコマンド実行間の任意の間隔は、ｅｘｅｃＰａｒａｍｅｔｅｒにおいて指定されてもよい。

ｅｘｅｃＰａｒａｍｅｔｅｒはコンテナであってもよく、およびコマンド実行モードに関連付けられた情報を含んでもよい。既に述べた情報に加えて、当該情報は、（ｉ）Ｒａｎｄｏｍ ＯｎｃｅモードおよびＲａｎｄｏｍ Ｒｅｐｅａｔｅｄｌｙモードにおいてコマンド実行の前にどのように一定時間バックオフ（backoff）するかを指定する情報、および／または（ｉｉ）Ｉｍｍｅｄｉａｔｅ ａｎｄ ＲｅｐｅａｔｅｄｌｙモードおよびＲａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモードにおいてコマンド実行を繰り返す頻度を指定する情報を含んでもよい。

ｅｘｅｃＳｔａｒｔＴｉｍｅは、コマンド実行の実際の最後の時間を指定してもよい。ｅｘｅｃＤｕｒａｔｉｏｎは、継続されるコマンド実行に対して必要な継続時間を指定してもよい。ｅｘｅｃＲｅｓｕｌｔは、最後のコマンド実行に対して返された値を指定してもよい。ｅｘｅｃＳｔａｔｕｓは、コマンド実行の現在のステータスを指定してもよい。このステータスは、例えば、終了（成功または失敗）、保留、動作中等であってもよい。ｒｅｑｕｅｓｔｏｒＩＤは、コマンド実行が呼び出されるのを要求する要求者のＩＤ（例えばＵＲＩ）を指定してもよい。ａｃｔｏｒＩＤは、コマンド実行を呼び出す受信者のＩＤ（例えばＵＲＩ）を指定してもよい。

図２２Ｂは、コマンドリソースを表す例示的なデータ構造（「コマンドリソース構造」）を示すブロック図である。コマンドリソース構造は、図２２Ｂに示すものなど、いくつかのデータ構造要素を含んでもよい。そして、このコマンドリソース構造のデータ構造要素の多くは、図２２Ａのコマンドリソース構造と同様である。示されるこれらのデータ構造要素の中には、属性（「コマンドリソース『ａｔｔｒｉｂｕｔｅ』」）を定義するデータ構造要素、およびそれぞれのコマンド（「＜ｃｏｍｍａｎｄ＞」）の集合を表すデータ構造要素のセットが含まれる。リソースとしての＜ｃｏｍｍａｎｄ＞の各インスタンスは、単一のコマンドを表し、ならびに＜ｃｏｍｍａｎｄ＞インスタンスの属性および／または下位リソースを表すデータ構造要素を含む。これらの＜ｃｏｍｍａｎｄ＞インスタンスの属性および／または下位リソースは、コマンド実行をどのようにトリガし、および実行するかを指定してもよい。＜ｃｏｍｍａｎｄ＞インスタンスの属性および／または下位リソースの中には、ｅｘｅｃＥｎａｂｌｅ下位リソース（「ｅｘｅｃＥｎａｂｌｅ」）を表すデータ構造要素がある。ｅｘｅｃＥｎａｂｌｅは、「ｅｘｅｃｕｔｅ」属性とも呼ばれ、コマンド実行の状態における変化を呼び出すことを容易にしてもよい。例えば、ｅｘｅｃＥｎａｂｌｅはブール変数であり、ならびにその変数の特定の値はコマンド実行、中断コマンド実行、再開コマンド実行、および／または取消しコマンド実行を呼び出してもよい。そのため、コマンド実行、中断コマンド実行、再開コマンド実行、および取消コマンド実行のいずれかは、ｅｘｅｃＥｎａｂｌｅの値を変更することによって呼び出されてもよい。ｅｘｅｃＥｎａｂｌｅの値はＲＥＳＴｆｕｌメソッドを使用して変更されてもよい。

例えば、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥが使用されて、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を呼び出してもよい（例えばトリガ）。．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＥｎａｂｌｅへのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥ ｔｏにおいて第１の値（例えば「１」）を指定することにより、コマンド実行が呼び出されてもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥおよびＤＥＬＥＴＥが使用されて、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を取消（停止）してもよい。．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＥｎａｂｌｅへのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥにおいて第２の値（例えば「０」）を指定することにより、取消コマンドの実行が呼び出されて＜ｃｏｍｍａｎｄ＞インスタンスを停止してもよい。加えて、またはその代わりに、．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／にＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥを発行することにより、取消コマンド実行が呼び出されて、そのような＜ｃｏｍｍａｎｄ＞インスタンスがＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥに従って削除される前に、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を停止してもよい。

ｅｘｅｃＥｎａｂｌｅに加えて、＜ｃｏｍｍａｎｄ＞インスタンスの下位リソースは、ｅｘｅｃＢａｓｅＤｅｌａｙ、ｅｘｃｅＡｄｄｉｔｉｏｎａｌＤｅｌａｙ、ｅｘｅｃＦｒｅｑｕｅｎｃｙ、ｅｘｅｃＮｕｍｂｅｒ、ｅｘｅｃＲｅｓｏｕｒｃｅ、ｅｘｅｃＳｔａｔｕｓ、ｅｘｅｃＲｅｓｕｌｔ、ｅｘｅｃＩｓｓｕｅｒ、およびｅｘｅｃＰａｒａｍｅｔｅｒなどの下位リソースを表すデータ構造要素を含んでもよい。

ｅｘｅｃＢａｓｅＤｅｌａｙは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行前の最小の遅延を指定してもよい。ｅｘｃｅＡｄｄｉｔｉｏｎａｌＤｅｌａｙは、ランダムな追加的遅延の生成を容易にしてもよい。総遅延は、ｅｘｅｃＢａｓｅＤｅｌａｙとランダムな追加的遅延との和になる。ｅｘｅｃＢａｓｅＤｅｌａｙおよびｅｘｅｃＡｄｄｉｔｉｏｎａｌＤａｌｙは、（ｉ）Ｒａｎｄｏｍ ＯｎｃｅモードおよびＲａｎｄｏｍ Ｒｅｐｅａｔｅｄｌｙモードにおいてコマンド実行前に一定の時間どのようにバックオフするかを指定する情報、および／または（２）Ｉｍｍｅｄｉａｔｅ ａｎｄ ＲｅｐｅａｔｅｄｌｙモードおよびＲａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙモードにおいてコマンド実行を繰り返す頻度を指定する情報を含んでもよい。

ｅｘｅｃＦｒｅｑｕｅｎｃｙは、＜ｃｏｍｍａｎｄ＞インスタンスの繰り返されるコマンド実行の頻度を指定してもよい。ｅｘｅｃＮｕｍｂｅｒは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を繰り返すことができる回数を指定してもよい。ｅｘｅｃＲｅｓｏｕｒｃｅは、＜ｃｏｍｍａｎｄ＞インスタンスがコマンド実行を受けるリソースＵＲＩを指定してもよい。リソースＵＲＩは、リソースのグループを含むグループリソースを指す。そのようにして、複数の＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行が、グループリソースを指すリソースＵＲＩの機能として呼び出されてもよい。ｅｘｅｃＲｅｓｏｕｒｃｅは任意であってもよい。例えば＜ｃｏｍｍａｎｄ＞インスタンスが下位リソースとして＜ｃｏｍｍａｎｄ＞インスタンスの下位に置かれる場合は、ｅｘｅｃＲｅｓｏｕｒｃｅは必要でない場合がある。

ｅｘｅｃＳｔａｔｕｓは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行の現在のステータスを指定してもよい。ステータスは、例えば、保留中、実行中、中断、停止、再開、終了かつ成功、および終了かつ失敗等であってもよい。ｅｘｅｃＲｅｓｕｌｔは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行の実行結果を格納してもよい。ｅｘｅｃＲｅｓｕｌｔを、例えばｅｘｅｃＲｅｓｏｕｒｃｅがリソースのグループを指す場合に、複数の結果が生成された場合に＜ｃｏｍｍａｎｄ＞インスタンスの下位リソースとしてモデル化することができる。

ｅｘｅｃＩｓｓｕｅｒは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を呼び出す要求を発行する発行元のＩＤを指定してもよい。ｅｘｅｃＰａｒａｍｅｔｅｒは、＜ｃｏｍｍａｎｄ＞インスタンスに固有のパラメータを格納するコンテナ（例えばプレースホルダ）であってもよい。

ここで図２２Ｃを参照すると、図２２Ｃは、別の例示的なコマンドリソース構造を示すブロック図である。このコマンドリソース構造は、図２２Ｃに示すものなどのいくつかのデータ構造要素を含んでもよい。そしてこのコマンドリソース構造のデータ構造要素の多くは、図２２Ｂのコマンドリソース構造と同様である。図２２Ｃに示すデータ構造要素の中には、いくつかの属性、すなわちｃｏｍｍａｎｄＩＤ属性、ｅｘｅｃＤｉｓａｂｌｅ属性、ｅｘｅｃＰａｕｓｅ属性、ｅｘｅｃＲｅｓｕｍｅ属性、およびｅｘｅｃＲｅｓｕｌｔ属性を定義するデータ構造要素が含まれる。

ｅｘｅｃＥｎａｂｌｅ属性は、「ｅｘｅｃｕｔｅ」属性とも呼ばれ、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行の呼び出しを容易にしてもよい。ｅｘｅｃＥｎａｂｌｅ属性へのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｃｏｍｍａｎｄ＞インスタンスのコマンド実行を呼び出してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥのペイロードは、空であってもよく、または任意の値（例えばｅｘｅｃＥｎａｂｌｅ＝１）に設定されてもよい。

ｅｘｅｃＤｉｓａｂｌｅ属性は、「ｃａｎｃｅｌ」（取消し）属性とも呼ばれ、＜ｃｏｍｍａｎｄ＞インスタンスの取消コマンド実行の呼び出しを容易にしてもよい。ｅｘｅｃＤｉｓａｂｌｅ属性へのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｃｏｍｍａｎｄ＞インスタンスの取消コマンド実行を呼び出してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥのペイロードは空であってもよく、または任意の値（例えばｅｘｅｃＤｉｓａｂｌｅ＝１）に設定されてもよい。

ｅｘｅｃＰａｕｓｅ属性は、＜ｃｏｍｍａｎｄ＞インスタンスの取消コマンド実行の呼び出しを容易にしてもよい。ｅｘｅｃＰａｕｓｅ属性へのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｃｏｍｍａｎｄ＞インスタンスの中断コマンド実行を呼び出してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥのペイロードは空であってもよく、または任意の値（例えばｅｘｅｃＰａｕｓｅ＝１）に設定されてもよい。

ｅｘｅｃＲｅｓｕｍｅ属性は、＜ｃｏｍｍａｎｄ＞インスタンスの再開コマンド実行の呼び出しを容易にしてもよい。ｅｘｅｃＲｅｓｕｍｅ属性へのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、そのような再開コマンド実行を呼び出してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥのペイロードは空であってもよく、または任意の値（例えばｅｘｅｃＲｅｓｕｍｅ＝１）に設定されてもよい。

上述したことは、図２３Ａ、図２３Ｂおよび図２３Ｃのデータ構造が、ＲＥＳＴｆｕｌメソッドを使用して非ＲＥＳＴｆｕｌ管理コマンドのコマンド実行を容易にしてもよいことを示す。このことは、ＢＢＦ−ＴＲ０６９およびＯＭＡ−ＤＭの非ＲＥＳＴｆｕｌ管理コマンドのコマンド実行を容易にすることを含む。例えば、ＢＢＦ−ＴＲ０６９のリブートは、データ構造において．．．／ｃｏｍｍａｎｄｓ／ｒｅｂｏｏｔ／として表されてもよい。ＢＢＦ−ＴＲ０６９のダウンロードは、データ構造において．．．／ｃｏｍｍａｎｄｓ／ｄｏｗｎｌｏａｄ／として表されてもよい。ＯＭＡ−ＤＭの実行は、データ構造において．．．／ｃｏｍｍａｎｄｓ／ｅｘｅｃ／として表されてもよい。ＯＭＡ−ＤＭの複製は、データ構造において．．．／ｃｏｍｍａｎｄｓ／ｃｏｐｙ／として表されてもよい。

＜ｃｏｍｍａｎｄ＞インスタンスが使用されて、他の管理用ＡＰＩまたはリモートプロシージャコール（ＲＰＣ）をモデル化し、および表してもよい。リソースコマンドは、既存の「リソース」の下に下位リソースの下に配置されてもよく、および既存の「リソース」の下に下位リソースとして配置されてもよく、それにより、各ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞が、トリガされた時に必要であれば、「リソース」上で自動的に実行されるようにされてもよい。加えて、「ｅｘｅｃＲｅｓｏｕｒｃｅ」を使用して、ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞を実行することができるリソースを指定することができる。この方式では、リソースコマンドを、集中化された点に配置することができ、および「ｅｘｅｃＲｅｓｏｕｒｃｅ」が参照するリソースの直下にある必要はない。ＯＭＡ−ＤＭ ＦＵＭＯを例として、以下に２つの方式が説明される。

方式１：「ｅｘｅｃＲｅｓｏｕｒｃｅ」を使用してＦＵＭＯにおける動作を参照する
図２３に示すように、ＯＭＡ ＦＵＭＯは、ダウンロード、更新、ならびにダウンロード・更新、の３つの動作を有する。ＯＭＡ−ＤＭでは、その３つの動作はＤＭサーバによってトリガされて、ＤＭクライアントに非ＲＥＳＴｆｕｌのＥｘｅｃコマンドを発行する。それら３つの動作をＲＥＳＴｆｕｌ方式で呼び出すために、Ｅｘｅｃは、図２３に記載するいくつかの属性を有する＜ｃｏｍｍａｎｄ＞ｅｘｅｃとしてモデル化される。２つの重要な属性はｅｘｅｃＥｎａｂｌｅとｅｘｅｃＲｅｓｏｕｒｃｅである。

ネットワーク領ドメイン（「ＮＡ」）のＭ２Ｍアプリケーションは、「ダウンロード」の動作を行う必要があるときは、単に．．．／ｍｇｍｔＯｂｊｓ／ｃｏｍｍａｎｄｓ／ｅｘｅｃ／にＵＰＤＡＴＥメソッドを発行して
ｅｘｅｃＥｎａｂｌｅ＝１、かつ
ｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｍｇｍｔＯｂｊｓ／ＦＵＭＯ／Ｄｏｗｎｌｏａｄに設定する。
ＮＡが「更新」動作を行う必要があるときは、単に．．．／ｍｇｍｔＯｂｊｓ／ｃｏｍｍａｎｄｓ／ｅｘｅｃ／にＵＰＤＡＴＥメソッドを発行して
ｅｘｅｃＥｎａｂｌｅ＝１、かつ
ｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｍｇｍｔＯｂｊｓ／ＦＵＭＯ／Ｕｐｄａｔｅに設定する。
ＮＡが「ダウンロード・更新」の動作を行う必要があるときは、単に．．．／ｍｇｍｔＯｂｊｓ／ｃｏｍｍａｎｄｓ／ｅｘｅｃ／にＵＰＤＡＴＥメソッドを発行して、
ｅｘｅｃＥｎａｂｌｅ＝１、かつ
ｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｍｇｍｔＯｂｊｓ／ＦＵＭＯ／ＤｏｗｎｌｏａｄＡｎｄＵｐｄａｔｅに設定する。

方式２：コマンドを使用してＦＵＭＯにおける動作を再モデル化する
図２４Ａ〜２４Ｂに示すように、別の方式は、すべてのＦＵＭＯ動作を＜ｃｏｍｍａｎｄ＞リソースとして直接再モデル化するものである。動作の実行をトリガするには、対応する＜ｃｏｍｍａｎｄ＞のｅｘｅｃＥｎａｂｌｅへの更新のみが必要となる。その結果、追加的なＥｘｅｃコマンドを定義する必要は全くない。この方式では「ｅｘｅｃＲｅｓｏｕｒｃｅ」は必要でない。

図２４Ａに示すように、３つのＦＵＭＯ動作が、それぞれ３つの＜ｃｏｍｍａｎｄ＞リソースとして（すなわちダウンロード、更新、ダウンロード・更新）、リソースコマンド下に再モデル化されてもよい。各ＦＵＭＯ動作はいくつかの子／リーフノードを有するので、それらは「ｅｘｅｃＰａｒａｍｅｔｅｒ」の下に属性としてモデル化される必要がある。ダウンロード・更新を例として使用すると、「ＰｋｇＵＲＬ」は／ｃｏｍｍａｎｄｓ／ｄｏｗｎｌｏａｄＡｎｄＵｐｄａｔｅ／ｅｘｅｃＰａｒａｍｅｔｅｒｓの属性として追加されてもよい。

ＮＡが「ダウンロード・更新」動作を実行する必要があるときは、単に．．．／ｍｇｍｔＯｂｊｓ／ＦＵＭＯ／ｃｏｍｍａｎｄｓ／ｄｏｗｎｌｏａｄＡｎｄＵｐｄａｔｅ／にＵＰＤＡＴＥメソッドを発行して、
ｅｘｅｃＥｎａｂｌｅ＝１かつ
ＰｋｇＵＲＬ＝対応するパッケージのＵＲＬに設定する。

旧ＦＵＭＯ動作がそのまま維持される必要がある場合は、図２４Ｂに示すように、再モデル化されたコマンドがノードＥｘｔの下に部分ツリーとして配置されてもよい。

１つまたは複数の実施形態では、コマンドリソース構造は、同一の非ＲＥＳＴｆｕｌ管理コマンドの複数回の発行をサポートしてもよい（例えば複数のＮＡまたは他の発行元が同一の非ＲＥＳＴｆｕｌ管理コマンドのコマンド実行を要求してもよい）。

同一の非ＲＥＳＴｆｕｌの管理コマンドの複数回の発行をサポートするコマンドリソース構造の２つの例が図２５Ａおよび図２５Ｂに示される。図２５Ａに示すコマンドリソース構造は、図２２Ａのコマンドリソース構造と同様であり、ならびに＜ｃｏｍｍａｎｄ＞を複数のインスタンスの集合、すなわち＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅｓ＞として定義することにより、図２２Ａのコマンドリソース構造を拡張する。上記のプロシージャが使用されて、＜ｃｏｍｍａｎｄ＞のコマンド実行を呼び出し、および対応する＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を生成してもよい。＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞は、複数のＮＡによって発行される対応する＜ｃｏｍｍａｎｄ＞インスタンスを維持してもよい。生成された＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞の各コマンド実行は、上記のようにその属性および／または下位リソースにアクセスすることにより停止または変更されてもよい。例えば、既存の＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞のコマンド実行は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用して停止されて、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞／ｅｘｅｃＥｎａｂｌｅを１から０に変更してもよい。＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞および／または＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞のコマンド実行の状態における変化は、他のＲＥＳＴｆｕｌメソッドを使用してアクセス、および操作されてもよい。

図２５Ｂに示すコマンドリソース構造は、図２２Ｂのコマンドリソース構造と同様であり、および＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ（＜ｅｘｅｃＩｎｓｔａｎｃｅｓ＞とも呼ぶ）を、複数の要求インスタンスの集合、すなわち＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞（＜ｅｘｅｃＩｎｓｔａｎｃｅｓ＞とも呼ぶ）として定義することにより、図２２Ｂのコマンドリソース構造を拡張する。上記のプロシージャが使用されて、コマンド実行、もしくは＜ｃｏｍｍａｎｄ＞のコマンド実行の状態の変化を呼び出し、および／または対応する＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を生成する。＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、対応する＜ｃｏｍｍａｎｄ＞インスタンス（例えばＮＡによって発行される）を維持してもよい。生成された＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の各コマンド実行は、上記のようにその属性にアクセスすることによって停止または変更されてもよい。例えば、既存の＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のコマンド実行は、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞／ｅｘｅｃＥｎａｂｌｅにＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用して停止されてもよい。

＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞および／または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のコマンド実行の状態における変化は、他のＲＥＳＴｆｕｌメソッドを使用してアクセスおよび操作されてもよい。

図２６Ａはリソースコマンドの例示的構造を示すブロック図である。リソースコマンドは、＜ｃｏｍｍａｎｄ＞の下位リソースおよび以下の属性を有してもよい。
ａｃｃｅｓｓＲｉｇｈｔＩＤ
ｃｒｅａｔｉｏｎＴｉｍｅ
ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ
ｅｘｐｉｒａｔｉｏｎＴｉｍｅ
ｓｅａｒｃｈＳｔｒｉｎｇｓ
ｃｏｎｔｅｎｔＴｙｐｅ：ＦＦＳフォーマットであってもよい
ｍｏＩＤ
ｏｒｉｇｉｎａｌＭＯ、および
ｄｅｓｃｒｉｐｔｉｏｎ（すなわちコマンドリソースのテキスト形式の詳細）
＜ｃｏｍｍａｎｄ＞を属性としてモデル化することもできる。

図２６Ｂは、リソースコマンドの例示的構造を示すブロック図である。リソースコマンドは、以下の属性と共に下位リソースのサブスクリプションおよび＜ｃｏｍｍａｎｄ＞の下位リソースを有してもよい。
ａｃｃｅｓｓＲｉｇｈｔＩＤ
ｃｒｅａｔｉｏｎＴｉｍｅ
ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ
ｅｘｐｉｒａｔｉｏｎＴｉｍｅ
ｓｅａｒｃｈＳｔｒｉｎｇｓ
ｃｏｎｔｅｎｔＴｙｐｅ：ＦＦＳフォーマットであってもよい
ｍｏＩＤ
ｏｒｉｇｉｎａｌＭＯ、および
ｄｅｓｃｒｉｐｔｉｏｎ（すなわちコマンドリソースのテキスト形式の詳細）
＜ｃｏｍｍａｎｄ＞を属性としてモデル化することもできる。

各＜ｃｏｍｍａｎｄ＞は、下位リソース（ｉ）ｓｕｂｓｃｒｉｐｔｉｏｎｓ、および（ｉｉ）ｅｘｅｃＲｅｑｕｅｓｔｓを含んでもよい。ｅｘｅｃＲｅｑｕｅｓｔｓは、同一の非ＲＥＳＴｆｕｌの管理コマンドのコマンド実行を呼び出すための異なる発行元からの要求を格納するプレースホルダであってもよい。１つまたは複数の実施形態では、これらの要求は、＜ｃｏｍｍａｎｄ＞インスタンスに対する異なる引数を有してもよい。

各＜ｃｏｍｍａｎｄ＞インスタンスは以下の属性を有してもよい。
ａｃｃｅｓｓＲｉｇｈｔＩＤ
ｃｒｅａｔｉｏｎＴｉｍｅ
ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ
ｅｘｐｉｒａｔｉｏｎＴｉｍｅ
ｓｅａｒｃｈＳｔｒｉｎｇｓ
ｃｏｎｔｅｎｔＴｙｐｅ：ＦＦＳフォーマットであってもよい
ｍｏＩＤ
ｏｒｉｇｉｎａｌＭＯ、および
ｄｅｓｃｒｉｐｔｉｏｎ（すなわちコマンドリソースのテキスト形式の詳細）
＜ｃｏｍｍａｎｄ＞を属性としてモデル化することもできる。

各＜ｃｏｍｍａｎｄ＞は例えば図２７Ａに示すようにいくつかの＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を下位リソースとして有する。各＜ｃｏｍｍａｎｄ＞は以下の属性を有する。
ａｃｃｅｓｓＲｉｇｈｔＩＤ
ｃｒｅａｔｉｏｎＴｉｍｅ
ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ
ｅｘｅｃＥｎａｂｌｅ：コマンドを実行することを呼び出すために使用されるブール変数

ｅｘｅｃＥｎａｂｌｅが１から０に変更されると、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞は停止されてもよい。ｅｘｅｃＥｎａｂｌｅを、中断などのより多くのオプションをサポートするように調整されてもよい。

ｅｘｅｃＭｏｄｅ：どのようにコマンドを実行するかを指定するために使用される。

Ｉｍｍｅｄｉａｔｅ Ｏｎｃｅ：受信者はコマンドを直ちに一度のみ実行する。

Ｉｍｍｅｄｉａｔｅ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ：受信者はコマンドを直ちに、しかし繰り返して実行する。２つの実行間の間隔はコンテナｅｘｅｃＰａｒａｍｅｔｅｒｓによって指定される。

Ｒａｎｄｏｍ Ｏｎｃｅ：受信者はランダムの遅延の後、かつ一度のみコマンドを実行する、ランダムの遅延はｅｘｅｃＰａｒａｍｅｔｅｒｓにおいて指定される

Ｒａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ：受信者はランダムの遅延の後、かつ繰り返しコマンドを実行する。ランダムの遅延および２つの実行間の間隔はコンテナｅｘｅｃＰａｒａｍｅｔｅｒｓにより指定される。

ｅｘｅｃＢａｓｅＤｅｌａｙ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行することができる前の最小の遅延を指定する。

ｅｘｃｅＡｄｄｉｔｉｏｎａｌＤｅｌａｙ：ランダムの追加的な遅延を生成するために使用される。総遅延は、ｅｘｅｃＢａｓｅＤｅｌａｙとランダムの追加的遅延との和であってもよい。

ｅｘｅｃＦｒｅｑｕｅｎｃｙ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を繰り返し実行できる頻度を指定する。

ｅｘｅｃＮｕｍｂｅｒ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を繰り返し実行できる回数を指定する。

ｅｘｅｃＲｅｓｏｕｒｃｅ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行することができるリソースＵＲＩを表してもよい。リソースＵＲＩは、リソースのグループを含むグループリソースを指すことができ、そしてコマンドはそれらの各リソース上で実行されてもよい。ｅｘｅｃＲｅｓｏｕｒｃｅは任意であってもよい。＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞が、その＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行することができるリソースの下に下位リソースとして配置される場合は、ｅｘｅｃＲｅｓｏｕｒｃｅは必要でない場合がある。

ｅｘｅｃＳｔａｔｕｓ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞の現在のステータスを表してもよい。ステータスは、保留中、実行中、および終了（成功または失敗）のいずれかであってもよい。

ｅｘｅｃＩｓｓｕｅｒ：＜ｃｏｍｍａｎｄ＞を発行する発行元を表してもよい。

ｅｘｅｃＰａｒａｍｅｔｅｒ：各々単一のコマンドに固有のパラメータを格納するプレースホルダである。

ｅｘｅｃＢａｓｅＤｅｌａｙおよびｅｘｅｃＡｄｄｉｔｉｏｎａｌＤｅｌａｙは、「Ｒａｎｄｏｍ Ｏｎｃｅ」モードおよび「Ｒａｎｄｏｍ Ｒｅｐｅａｔｅｄｌｙ」モードにおいて、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行する前にどのように一定時間バックオフするかを指定するために使用される。ｅｘｅｃＦｒｅｑｕｅｎｃｙおよびｅｘｅｃＮｕｍｂｅrは、「Ｉｍｍｅｄｉａｔｅ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ」および「Ｒａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ」下で同一の＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行する頻度を指定するために使用される。

「ｅｘｅｃ」で始まる上記の属性を下位リソースとしてモデル化することもできる。「ｅｘｅｃ」で始まる上記の属性を、通常のＲＥＳＴｆｕｌ ＣＲＵＤ動作（すなわちＣｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｄｅｌｅｔｅ、Ｕｐｄａｔｅ）に適用して、リソースを操作することにさらなる柔軟性を付与することができる。

各＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞は図２７Ｂに示すように以下の属性を有してもよい。
ａｃｃｅｓｓＲｉｇｈｔＩＤ
ｃｒｅａｔｉｏｎＴｉｍｅ
ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ

ｅｘｅｃＥｎａｂｌｅ：コマンドの実行をトリガするために使用されるブール変数。ｅｘｅｃＥｎａｂｌｅが１から０に変更されると、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞は停止されてもよい。ｅｘｅｃＥｎａｂｌｅは、中断などのより多くのオプションをサポートするように適合されてもよい。

ｅｘｅｃＭｏｄｅ：コマンドをどのように実行できるかを指定するために使用される。

Ｉｍｍｅｄｉａｔｅ Ｏｎｃｅ：受信者はコマンドを直ちに、かつ一度のみ実行する。

Ｉｍｍｅｄｉａｔｅ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ：受信者はコマンドを直ちに、しかし繰り返して実行する。２つの実行間の間隔はコンテナｅｘｅｃＰａｒａｍｅｔｅｒｓにより指定される。

Ｒａｎｄｏｍ Ｏｎｃｅ：受信者はランダムの遅延の後に一度のみコマンドを実行する。ランダムの遅延はｅｘｅｃＰａｒａｍｅｔｅｒｓで指定することができる。

Ｒａｎｄｏｍ ａｎｄ Ｒｅｐｅａｔｅｄｌｙ：受信者はランダムの遅延の後に、かつ繰り返しコマンドを実行する。ランダムの遅延および２つの実行間の間隔はコンテナｅｘｅｃＰａｒａｍｅｔｅｒｓにより指定されてもよい。

ｅｘｅｃＢａｓｅＤｅｌａｙ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行できる前の最小の遅延を指定するために使用される。

ｅｘｃｅＡｄｄｉｔｉｏｎａｌＤｅｌａｙ：ランダムな追加的遅延を生成するために使用される。総遅延は、ｅｘｅｃＢａｓｅＤｅｌａｙとランダムな追加的遅延との和であってもよい。

ｅｘｅｃＦｒｅｑｕｅｎｃｙ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を繰り返し実行できる頻度を指定するために使用される。

ｅｘｅｃＮｕｍｂｅｒ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を繰り返し実行できる回数を指定するために使用される。

ｅｘｅｃＲｅｓｏｕｒｃｅ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行することができるリソースＵＲＩを表してもよい。リソースＵＲＩは、リソースのグループを含むグループリソースを指してもよく、そしてコマンドはそれらの各リソース上で実行されてもよい。ｅｘｅｃＲｅｓｏｕｒｃｅは任意であってもよい。＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞が、その＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞を実行することができるリソースの下に下位リソースとして配置される場合は、ｅｘｅｃＲｅｓｏｕｒｃｅは必要でない場合もある。

ｅｘｅｃＳｔａｔｕｓ：＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞の現在のステータスを表してもよい。このステータスは、保留中、実行中、および終了（成功または失敗）のいずれかであってもよい。

ｅｘｅｃＩｓｓｕｅｒ：＜ｃｏｍｍａｎｄ＞を発行する発行元を表してもよい。

ｅｘｅｃＰａｒａｍｅｔｅｒｓ：各々単一のコマンドに固有のパラメータを格納するプレースホルダである。

「ｅｘｅｃ」で始まる上記の属性を下位リソースとしてモデル化することもできる。

ここで図２８Ａを参照すると、図２８Ａは、別の例示的なコマンドリソース構造を示すブロック図である。このコマンドリソース構造は、いくつかのデータ構造要素を含んでもよい。そして、このコマンドリソース構造のデータ構造要素の多くは、図２２Ｃのコマンドリソース構造と同様である。上記述べたように、コマンドリソース構造は、同一の非ＲＥＳＴｆｕｌ管理コマンド（例えば属性ｃｏｍｍａｎｄＩＤによって識別される）のコマンド実行に対する複数の発行元（例えば、複数のＮＡ）の要求をサポートする。そのようなサポートを容易にするために、一実施形態では、異なる＜ｃｏｍｍａｎｄ＞が各要求に対して作成されてもよい。各＜ｃｏｍｍａｎｄ＞は異なる名前を有してもよいが、その属性ｃｏｍｍａｎｄＩＤは互いに同一であってもよい。属性ｃｏｍｍａｎｄＩＤ（コマンドのタイプにより分類されてもよい）は、コマンドの状態における変更を呼び出すコマンドを指定する。＜ｃｏｍｍａｎｄ＞の下位リソースｅｘｅｃＲｅｑｕｅｓｔｓは使用されなくてもよい。さらに、各発行元はリソースコマンドの下に特定の＜ｃｏｍｍａｎｄ＞を作成してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥが使用されて、作成された＜ｃｏｍｍａｎｄ＞のコマンド実行を呼び出してもよい（例えばＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをリソース＜ｃｏｍｍａｎｄ＞のｅｘｅｃＥｎａｂｌｅ属性上で使用する）。

あるいは、下位リソースｅｘｅｃＲｅｑｕｅｓｔｓが使用されて、同一の＜ｃｏｍｍａｎｄ＞のコマンド実行に対する複数の要求を格納してもよい。発行元は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを＜ｃｏｍｍａｎｄ＞のｅｘｅｃＥｎａｂｌｅ属性上で使用して、＜ｃｏｍｍａｎｄ＞のコマンド実行を呼び出してもよい。したがって、受信者は、その発行元について、．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／の下に＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成してもよい。発行元は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性であるｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ上でそれぞれ使用して、この生成された＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を取り消し、中断し、および再開してもよい。

加えて、発行元は、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥ動作をコマンドリソース．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞上で使用して、この生成された＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除することができる。＜ｃｏｍｍａｎｄ＞の属性ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、ｅｘｅｃＲｅｓｕｍｅは使用されなくてもよい。

上記で詳細に述べたように、４つの属性（ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、ｅｘｅｃＲｅｓｕｍｅ）が構成および使用されて、コマンド（＜ｃｏｍｍａｎｄ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）のそれぞれコマンド実行、中断コマンド実行、再開コマンド実行、および取消コマンド実行を呼び出す。

代替として、４つの特殊な＜ｃｏｍｍａｎｄ＞リソースがデータ構造、すなわち、．．．／ｃｏｍｍａｎｄｓ／ｅｎａｂｌｅ、．．．／ｃｏｍｍａｎｄｓ／ｄｉｓａｂｌｅ、．．．／ｃｏｍｍａｎｄｓ／ｐａｕｓｅ、および．．．／ｃｏｍｍａｎｄｓ／ｒｅｓｕｍｅ、において作成されてもよい。この４つの特殊なコマンドは、それぞれの「ｅｘｅｃＲｅｓｏｕｒｃｅ」属性のみを有してもよい。

．．．／ｃｏｍｍａｎｄｓ／ｅｎａｂｌｅが使用されて、一般的なコマンド実行を呼び出してもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥまたはＵＰＤＡＴＥの動作を、属性ｅｘｅｃＲｅｓｏｕｒｃｅがｅｘｅｃＲｅｓｏｕｒｃｅ＝「．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞」に設定された「．．．／ｃｏｍｍａｎｄｓ／ｅｎａｂｌｅ」リソース上で発行して、「．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞」のコマンド実行を呼び出す。

．．．／ｃｏｍｍａｎｄｓ／ｄｉｓａｂｌｅが使用されて、．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）の一般的な取消しコマンド実行を呼び出してもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥまたはＵＰＤＡＴＥを、属性ｅｘｅｃＲｅｓｏｕｒｃｅがｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）に設定された．．．／ｃｏｍｍａｎｄｓ／ｄｉｓａｂｌｅリソース上で発行して、．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）の取消しコマンド実行を呼び出す。

．．．／ｃｏｍｍａｎｄｓ／ｐａｕｓｅが使用されて、既存の．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）の中断コマンド実行を呼び出してもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥまたはＵＰＤＡＴＥを、属性ｅｘｅｃＲｅｓｏｕｒｃｅがｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔ−Ｉｎｓｔａｎｃｅ＞）に設定された．／ｃｏｍｍａｎｄｓ／ｐａｕｓｅリソース上で発行して、．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔ−Ｉｎｓｔａｎｃｅ＞）の中断コマンド実行を呼び出してもよい。

．．．／ｃｏｍｍａｎｄｓ／ｒｅｓｕｍｅが使用されて、既存の．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）の再開コマンド実行を呼び出してもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥまたはＵＰＤＡＴＥを、属性ｅｘｅｃＲｅｓｏｕｒｃｅがｅｘｅｃＲｅｓｏｕｒｃｅ＝．．．／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞（または...／ｃｏｍｍａｎｄｓ／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＲｅｑｕｅｓｔｓ／＜ｒｅｑｕｅｓｔＩｎｓｔ−ａｎｃｅ＞）に設定された、．／ｃｏｍｍａｎｄｓ／ｒｅｓｕｍｅリソース上で発行して、再開コマンド実行を呼び出してもよい。

ｘＲＥＭコマンド管理についての例示的なメッセージフローチャート
図２９Ａ乃至２９Ｒは、リソースコマンドのｘＲＥＭについての例示的なメッセージフローを説明するメッセージフローチャートである。図２９Ａ乃至２９Ｒのメッセージフローは、図２２Ｃ、２５Ｂおよび２８Ａ乃至２８Ｄのコマンドリソース構造を参照して説明する。メッセージフローは、リソースコマンドまたは＜ｃｏｍｍａｎｄｓ＞の他の構造を使用して実行されてもよい。

まず図２９Ａを参照すると、リソースコマンド構造を作成するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図２９Ａのメッセージフローを使用して作成されたリソースコマンド構造は、図２２Ｃ、図２５Ｂおよび図２８Ａに示すリソースコマンド構造の一部またはすべてを含んでもよい。例えば、リソースコマンド構造は、それらの図に示される＜ｃｏｍｍａｎｄ＞の要素のすべてを含んでもよい。あるいは、リソースコマンド構造は、示される＜ｃｏｍｍａｎｄ＞の要素のサブセットを含んでもよい。そのようなサブセットは、＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースのサブセットを含んでもよい。例として、リソースコマンド構造は、（ｉ）例えば、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅおよびｃｏｍｍａｎｄＩＤなどの属性、および（ｉｉ）例えば、ｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓ、ｓｕｂｓｃｒｉｐｔｉｏｎｓなどの下位リソース、を含んでもよい。別の例として、リソースコマンド構造は、（ｉ）例えば「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、ｅｘｅｃＲｅｓｕｍｅ、およびｃｏｍｍａｎｄＩＤなどの属性、および（ｉｉ）例えばｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓ、およびｓｕｂｓｃｒｉｐｔｉｏｎｓなどの下位リソース、を含んでもよい。さらに別の例として、リソースコマンド構造は、（ｉ）例えば「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、およびｃｏｍｍａｎｄＩＤなどの属性、および（ｉｉ）例えばｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓ、およびｓｕｂｓｃｒｉｐｔｉｏｎｓなどの下位リソースを含んでもよい。リソースコマンド構造は、図２２Ｃ、２５Ｂおよび２８Ａに示される＜ｃｏｍｍａｎｄ＞の要素（例えば属性および下位リソース）の他の組み合わせを含んでもよい。

リソースコマンド構造はまた、図２２Ｃ、２５Ｂおよび２９Ａに示されない＜ｃｏｍｍａｎｄ＞の他の要素を含んでもよい。それらの他の要素は、図２２Ｃ、２５Ｂおよび２８Ａに示される＜ｃｏｍｍａｎｄ＞の要素の任意の組み合わせと組み合わせた、リソースコマンド構造に含まれてもよい。

リソースコマンド構造の作成を開始するために、発行元は、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥをＭ２Ｍサーバに発行してもよい。発行元は、例えばＮＡ、Ｍ２ＭデバイスおよびＭ２Ｍ ＧＷのいずれかであってもよい。発行元としてのＭ２ＭデバイスまたはＭ２Ｍ ＧＷは、Ｍ２Ｍサーバへの登録に応答して、または登録の一部としてＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを発行してもよい。Ｍ２Ｍデバイス、Ｍ２Ｍ ＧＷ、またはＮＡは、またある時に、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥを発行してもよい。

＜ｓｃｌｂａｓｅ＞の所与のノードにおいて、リソースコマンド構造の作成を容易にするために、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥは、リソースコマンド構造をその下に作成することができるノード（例えばリソース）の識別子を含んでもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥは、リソース＜ｍｇｍｔＯｂｊｓ＞の識別子（以降「＜ｍｇｍｔＯｂｊｓ＞識別子」）を含んでもよく、それにより、リソースコマンド構造を作成することができるノードとしてリソース＜ｍｇｍｔＯｂｊｓ＞を識別することができる。

代替として、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥは、リソース＜ｃｏｍｍａｎｄｓ＞を、リソースコマンド構造をその下に作成することができるノードとして識別するためのリソース＜ｃｏｍｍａｎｄｓ＞の識別子（以降「＜ｃｏｍｍａｎｄｓ＞識別子」）を含んでもよい。＜ｍｇｍｔＯｂｊｓ＞および＜ｃｏｍｍａｎｄｓ＞識別子の各々は、上記のように、例えばＵＲＩ、リンク、アドレスのいずれであってもよい。説明を簡潔にするために、以下では、リソースコマンド構造がリソース＜ｍｇｍｔＯｂｊｓ＞の下に作成されてもよいと仮定する。ただし、リソースコマンド構造は＜ｓｃｌｂａｓｅ＞の任意のノードの下に作成されてもよい。

ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥはまた、リソースコマンド構造の任意の属性を埋めるための情報を含んでもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥは、ｃｏｍｍａｎｄＩＤ属性を埋める情報を含んでもよく、それにより、実行を要求し、リソースコマンド構造を使用して実行することができる非ＲＥＳＴｆｕｌコマンドのタイプを示すことができる。

ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥはさらに、リソースコマンド構造の下位リソース（例えば、パラメータリソース）の１つまたは複数を埋めるための情報を含んでもよい。例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥは、下位リソースｅｘｅｃＰａｒａｍｅｔｅｒｓを埋めるための１つまたは複数のパラメータおよび／または引数を含んでもよい。それらのパラメータおよび／または引数は、リソース＜ｃｏｍｍａｎｄ＞および／または非ＲＥＳＴｆｕｌコマンドに固有であってもよい。ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥはまた、非ＲＥＳＴｆｕｌコマンドに従って、下位リソースｅｘｅｃＭｏｄｅ、ｅｘｅｃＢａｓｅＤｅｌａｙ、ｅｘｅｃＡｄｄｉｔｉｏｎＤｅｌａｙ、ｅｘｅｃＦｒｅｑｕｅｎｃｙ、ｅｘｅｃＮｕｍｂｅｒ、およびｅｘｅｃＲｅｓｏｕｒｃｅのいずれかを埋めるための情報も含んでもよい。

ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥを受信した後に、Ｍ２Ｍサーバは、Ｍ２Ｍサーバのリソース＜ｍｇｍｔＯｂｊｓ＞の下にリソースコマンド構造を作成してもよい。作成されたリソースコマンド構造（以降「サーバ＜ｃｏｍｍａｎｄ＞」）は、図２２Ｃ、２５Ｂおよび２８Ａに示す＜ｃｏｍｍａｎｄ＞の要素すべてを含んでもよい。あるいは、サーバ＜ｃｏｍｍａｎｄ＞は、例えば＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースのサブセットなどの、示される＜ｃｏｍｍａｎｄ＞の要素のサブセットを含んでもよい。サーバ＜ｃｏｍｍａｎｄ＞は、例えば、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅおよびｃｏｍｍａｎｄＩＤ属性、ならびにｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓおよびｓｕｂｓｃｒｉｐｔｉｏｎｓの下位リソースを含んでもよい。

あるいは、サーバ＜ｃｏｍｍａｎｄ＞は、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、ｅｘｅｃＲｅｓｕｍｅおよびｃｏｍｍａｎｄＩＤ属性、ならびにｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓおよびｓｕｂｓｃｒｉｐｔｉｏｎｓの下位リソースを含んでもよい。さらに別の例として、サーバ＜ｃｏｍｍａｎｄ＞は、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅおよびｃｏｍｍａｎｄＩＤ属性、ならびにｅｘｅｃＰａｒａｍｅｔｅｒｓ、ｅｘｅｃＲｅｑｕｅｓｔｓおよびｓｕｂｓｃｒｉｐｔｉｏｎｓの下位リソースを含んでもよい。サーバ＜ｃｏｍｍａｎｄ＞は、＜ｃｏｍｍａｎｄ＞の要素（例えば、属性および下位リソース）（図２２Ｃ、２５Ｂおよび２７Ａに示されるものおよび示されないもの）の他の組み合わせを含んでもよい。

サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースを埋めるための情報が、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥに含まれている場合、Ｍ２Ｍサーバは、そのような対応する属性および／または下位リソースを、提供された情報で埋めてもよい。所与の属性および／または下位リソースを埋めるための情報が提供されない場合、Ｍ２Ｍサーバはそのような属性および／または下位リソースを当初作成された時の状態のままにしてもよい（例えばブランクとするか、あるいはデフォルトの属性および／またはパラメータを有する）。下記でより詳細に説明するように、属性および下位リソースは、属性および／または下位リソースを埋めるための情報を含むＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行することにより、サーバ＜ｃｏｍｍａｎｄ＞の作成後に埋められてもよい。

ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥに応答して、Ｍ２Ｍサーバは応答メッセージ（「ＲＥＳＰＯＮＳＥ」）を発行元に送信してもよい。Ｍ２Ｍサーバは、示されるようにサーバ＜ｃｏｍｍａｎｄ＞を作成した後にＲＥＳＰＯＮＳＥを送信してもよい。あるいは、Ｍ２Ｍサーバは、サーバ＜ｃｏｍｍａｎｄ＞の作成中にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバはまた、発行元に確認応答（「ＡＣＫ／ＮＡＣＫ」）メッセージ（図示せず）を送信して、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥの受信を確認応答してもよい。発行元に（例えば一定時間内に）よりＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥの確認応答がされていないことを示してもよい。

レスポンスは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の作成に成功したか、または失敗したかを示すインジケーション（例えばコード）を含んでもよい。インジケーションは、作成の成功を示す１つの値および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の作成に成功したことを示す第１のインジケーション（例えばコード）と、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の作成に失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍサーバは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の作成に成功した場合にのみレスポンスを発行してもよい。

ＲＥＳＰＯＮＳＥは、作成中にサーバ＜ｃｏｍｍａｎｄ＞に割り当てられたノードの識別子（「サーバ＜ｃｏｍｍａｎｄ＞識別子」）を含んでもよい。このサーバ＜ｃｏｍｍａｎｄ＞識別子が使用されて、サーバ＜ｃｏｍｍａｎｄ＞にアクセスしてもよい。サーバ＜ｃｏｍｍａｎｄ＞コマンド識別子は、例えばノードのＵＲＩ、リンク、またはアドレスであってもよい。

ＲＥＳＰＯＮＳＥは、作成中にｅｘｅｃＥｎａｂｌｅ下位リソースに割り当てられたノードの識別子（「ｅｘｅｃＥｎａｂｌｅ識別子」）も含んでもよい。上記で説明し、および下記でより詳しく説明するように、ｅｘｅｃＥｎａｂｌｅ識別子が使用されて、コマンド実行の状態における変更を呼び出してもよい（例えばコマンド実行、取消しコマンド実行、中断コマンド実行および再開コマンド実行のいずれかを呼び出す）。

あるいは、ＲＥＳＰＯＮＳＥはまた、ｅｘｅｃＥｎａｂｌｅ識別子、作成中にｅｘｅｃＤｉｓａｂｌｅに割り当てられたノードの識別子（「ｅｘｅｃＤｉｓａｂｌｅ識別子」）（存在する場合）、作成中にｅｘｅｃＰａｕｓｅに割り当てられたノードの識別子（「ｅｘｅｃＰａｕｓｅ識別子」）（存在する場合）、作成中にｅｘｅｃＲｅｓｕｍｅに割り当てられたノードの識別子（「ｅｘｅｃＲｅｓｕｍｅ識別子」）（存在する場合）、も含んでもよい。上記で説明し、および下記でより詳しく説明するように、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ識別子の各々は、コマンド実行の状態における変更を呼び出すために使用されてもよい。ｅｘｅｃＥｎａｂｌｅが使用されて、コマンド実行を呼び出してもよい。ｅｘｅｃＤｉｓａｂｌｅが使用されて、取消しコマンドの実行を呼び出してもよい。ｅｘｅｃＰａｕｓｅが使用されて、中断コマンドの実行を呼び出してもよい。ｅｘｅｃＲｅｓｕｍｅが使用されて、再開コマンドの実行を呼び出してもよい。

代替として、Ｍ２Ｍサーバは、存在する場合はｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ識別子を、例えば「ａｔｔｒｉｂｕｔｅ」属性など、サーバ＜ｃｏｍｍａｎｄ＞の属性または下位リソースに格納してもよい。このようにして、そのように格納されたｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅおよびｅｘｅｃＲｅｓｕｍｅ識別子のいずれかは、後に読み出されてもよい。

ここで図２９Ｂを参照すると、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造から情報を読み出すための例示的なメッセージフローを説明するメッセージフローチャートが示される。読み出しを開始するために、ＮＡ（すなわち発行元）がＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥをＭ２Ｍサーバに発行してもよい。ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥはサーバ＜ｃｏｍｍａｎｄ＞識別子を含んでもよい。

ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥを受信した後に、Ｍ２Ｍサーバはサーバ＜ｃｏｍｍａｎｄ＞識別子を使用して、サーバ＜ｃｏｍｍａｎｄ＞を検索してもよい。いったん検索されると、Ｍ２Ｍサーバは、読出可能な情報（例えば属性、パラメータおよび／または引数）を有するサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースから、そのような読出可能な情報（以降「読出属性情報」および／または「読出下位リソース情報」）をクエリし、ならびに読み出してもよい。読出属性情報および／または読出下位リソース情報は、格納されたｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ識別子のいずれかを含んでもよい。

読出属性情報および／または読出下位リソース情報を取得した後に、Ｍ２ＭサーバはＮＡにＲＥＳＰＯＮＳＥを送信してもよい。このＲＥＳＰＯＮＳＥは、サーバ＜ｃｏｍｍａｎｄ＞識別子ならびに読出属性情報および／または読出下位リソース情報を含んでもよい。

代替として、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥが使用されて、読出可能な情報を有するサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースから、そのような読出可能な情報の１つまたは複数の選択部分を読み出してもよい。このことを容易にするために、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥは、読出可能な情報の選択部分を有するサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに割り当てられた各ノードの識別子を含んでもよい。その識別子（または２つ以上ある場合は複数の識別子）を使用して、Ｍ２Ｍサーバは、読出可能な情報（以降「読出属性情報および／または読出下位リソース情報」）の選択部分を検索し、クエリし、および取得してもよい。そしてＭ２Ｍサーバは、選択された読出属性情報および／または読出下位リソース情報を含むＲＥＳＰＯＮＳＥをＮＡに送信してもよい。

図示しないが、Ｍ２Ｍサーバはまた、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥの受信を確認応答するために、発行元にＡＣＫ／ＮＡＣＫメッセージを送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥの確認応答がされていないことを示してもよい。

ここで図２９Ｃを参照すると、サーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄ＞インスタンスの集合（「サーバ＜ｃｏｍｍａｎｄ＞インスタンス」）などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートが示される。削除を開始するために、発行元は、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥをＭ２Ｍサーバに発行してもよい。発行元は、ＮＡ、Ｍ２Ｍデバイス、またはＭ２Ｍ ＧＷであってもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、リブート、非ＲＥＳＴｆｕｌコマンドの取消し、および登録解除等に応答して、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥを発行してもよい。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥは、サーバ＜ｃｏｍｍａｎｄ＞識別子を含んでもよい。あるいは、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥは、サーバ＜ｃｏｍｍａｎｄ＞インスタンスの集合が作成されたリソース（例えばサーバ＜ｃｏｍｍａｎｄｓ＞）に割り当てられたノードの識別子を含んでもよい（以降「サーバ＜ｃｏｍｍａｎｄｓ＞識別子」）。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥを受信した後、Ｍ２Ｍサーバは、サーバ＜ｃｏｍｍａｎｄ＞識別子またはサーバ＜ｃｏｍｍａｎｄｓ＞識別子を使用して、サーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞をそれぞれ検索し、および削除してもよい。このことは、サーバ＜ｃｏｍｍａｎｄ＞のすべての属性および／または下位リソースを削除すること、またはサーバ＜ｃｏｍｍａｎｄｓ＞について、かかるサーバ＜ｃｏｍｍａｎｄｓ＞のサーバ＜ｃｏｍｍａｎｄ＞インスタンスの各々を削除することを含んでもよい。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥに応答して、Ｍ２Ｍサーバは発行元にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバは、示されるようにサーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞を削除した後にＲＥＳＰＯＮＳＥを送信してもよい。あるいは、Ｍ２Ｍサーバは、サーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞の削除中にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバは、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥの受信を確認応答するために、発行元にＡＣＫ／ＮＡＣＫメッセージ（図示せず）を送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥの確認応答がされていないことを示してもよい。

ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞の削除に成功したか、または失敗したかを示すインジケーション（例えばコード）を含んでもよい。インジケーションは、削除の成功を示す１つの値であってもよく、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞の削除に成功したことを示す第１のインジケーション（例えばコード）、およびＭ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞の削除に失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍサーバは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞またはサーバ＜ｃｏｍｍａｎｄｓ＞の削除に成功した場合にのみ、ＲＥＳＰＯＮＳＥを発行してもよい。

図２９Ｄは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を、非ＲＥＳＴｆｕｌコマンドを実行する際に使用する情報によって更新するための例示的なメッセージフローを説明するメッセージフローチャートである。図２９Ｅ乃至２９Ｎは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出すための例示的なメッセージフローを説明するフローチャートである。図２９Ｄのメッセージフローおよび図２９Ｅ乃至２９Ｎのメッセージフローは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用してもよいことに対し、図２９Ｄのメッセージフローは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用して、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造の要素を、非ＲＥＳＴｆｕｌコマンドを実行する際に（すなわちコマンド実行が呼び出された後に）使用することができる情報（例えば属性、パラメータおよび／または引数）で埋めてもよい。ただし、図２９Ｅ乃至２９Ｎのメッセージフローは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出させてもよい。

ここで図２９Ｄを参照すると、ＮＡ（すなわち発行元）はＭ２ＭサーバにＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを発行して、更新を開始してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、サーバ＜ｃｏｍｍａｎｄ＞識別子、およびサーバ ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースを情報で埋めるためのそのような情報（例えば、属性、パラメータおよび／または引数）を含んでもよい。上記のＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥと同様に、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、ｃｏｍｍａｎｄＩＤ属性を埋めるための情報を含んでもよく、それにより実行を要求し、およびリソースコマンド構造を使用して実行することができる非ＲＥＳＴｆｕｌコマンドのタイプを示してもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥはさらに、リソースコマンド構造の下位リソース（例えば、パラメータリソース）の１つまたは複数を埋めるための情報を含んでもよい。例えば、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、ｅｘｅｃＰａｒａｍｅｔｅｒｓ下位リソースを埋めるための１つまたは複数のパラメータおよび／または引数を含んでもよい。それらのパラメータおよび／または引数は、リソース＜ｃｏｍｍａｎｄ＞および／または非ＲＥＳＴｆｕｌコマンドに固有であってもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥはまた、非ＲＥＳＴｆｕｌコマンドに従って、下位リソースｅｘｅｃＭｏｄｅ、ｅｘｅｃＢａｓｅＤｅｌａｙ、ｅｘｅｃＡｄｄｉｔｉｏｎＤｅｌａｙ、ｅｘｅｃＦｒｅｑｕｅｎｃｙ、ｅｘｅｃＮｕｍｂｅｒ、およびｅｘｅｃＲｅｓｏｕｒｃｅのいずれかを埋めるための情報も含んでもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信後、Ｍ２Ｍサーバは、サーバコマンド識別子を使用してサーバ＜ｃｏｍｍａｎｄ＞を検索する。その後、Ｍ２Ｍサーバは、そのサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースを、提供された情報で埋めてもよい。任意の所与の属性および／または下位リソースを埋めるための情報が提供されない場合、Ｍ２Ｍサーバは、そのような属性および／または下位リソースを当初作成された状態（例えばブランク、またはデフォルトの属性および／もしくはパラメータを有する）または最後に変更された状態のままにしてもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは発行元にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバは、示されるように、サーバ＜ｃｏｍｍａｎｄ＞を更新した後にＲＥＳＰＯＮＳＥを送信してもよい。あるいは、Ｍ２Ｍサーバは、サーバ＜ｃｏｍｍａｎｄｓ＞の更新中にレスポンスを送信してもよい。Ｍ２Ｍサーバはまた、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答するために、発行元にＡＣＫ／ＮＡＣＫメッセージ（図示せず）を送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の更新に成功したか、または更新に失敗したかを示すインジケーション（例えばコード）を含んでもよい。インジケーションは、更新の成功を示す１つの値、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の更新に成功したことを示す第１のインジケーション（例えばコード）、およびサーバ＜ｃｏｍｍａｎｄ＞の更新に失敗したことを示す第２のインジケーション（例えばコード）含んでもよい。別の代替として、Ｍ２Ｍサーバは、Ｍ２Ｍサーバがサーバ＜ｃｏｍｍａｎｄ＞の更新に成功した場合にのみＲＥＳＰＯＮＳＥを発行してもよい。

ＲＥＳＰＯＮＳＥはまた、サーバ＜ｃｏｍｍａｎｄ＞識別子、ならびに／または更新された属性および／もしくは下位リソースを含んでもよい。ＲＥＳＰＯＮＳＥはさらに、属性および／または下位リソースを更新するのに使用された情報、または同様のことを示す確認を含んでもよい。

ここで図２９Ｅを参照すると、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出すための例示的なメッセージフローを説明するフローチャートが示される。更新を開始するために、ＮＡ（すなわち発行元）は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行する。このＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、サーバ＜ｃｏｍｍａｎｄ＞識別子を含むと共に、下位リソースｅｘｅｃＥｎａｂｌｅを指定してもよい（例えば、．．．／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＥｎａｂｌｅ）。あるいは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥはｅｘｅｃＥｎａｂｌｅ識別子を含んでもよい。

そのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは、発行元に、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答するためのＡＣＫ／ＮＡＣＫメッセージ（ＲＥＳＰＯＮＳＥ（レスポンス）として示される）を送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

Ｍ２Ｍサーバは、サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに従って、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出してもよい。Ｍ２Ｍサーバは、コマンド実行を呼び出すことの一部として、いくつかの機能を実行してもよい。これらの機能は、例えば、サーバ＜ｃｏｍｍａｎｄ＞（例えば、ｃｏｍｍａｎｄＩＤ）により識別されるコマンドを、Ｍ２ＭデバイスまたはＭ２Ｍ ＧＷによって解釈または実行することができる非ＲＥＳＴｆｕｌコマンドに変換または翻訳することを含んでもよい。上記機能はまた、属性、パラメータおよび／または引数を、サーバ＜ｃｏｍｍａｎｄ＞により識別されるコマンドと、Ｍ２ＭデバイスまたはＭ２Ｍ ＧＷにより解釈または実行することができる非ＲＥＳＴｆｕｌコマンドとの間でマッピングする（「マッピングされた属性、パラメータおよび／または引数」）ための機能も含んでもよい。

Ｍ２Ｍサーバはまた、ｅｘｅｃＲｅｑｕｅｓｔｓ下位リソースの下にリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成して、呼び出されたサーバ＜ｃｏｍｍａｎｄ＞を保持し、および追跡してもよい。リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースの１つまたは複数を含んでもよい。Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成する時に、そのような属性および／または下位リソースをサーバ＜ｃｏｍｍａｎｄ＞から継承またはインポートしてもよい。サーバ＜ｃｏｍｍａｎｄ＞が要素の様々な組み合わせを含んでもよいと仮定すると、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞はまた、要素の様々な組み合わせを含んでもよい。例えば、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、図２５Ｂ、２８Ｃおよび２８Ｄに示すリソース ＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の要素のすべてを含んでもよく、それらの要素は、例えば図２２Ｃ、２５Ｂおよび２８Ａに示すサーバ＜ｃｏｍｍａｎｄ＞への必然的結果であってもよい。

あるいは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、示されるリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の要素のサブセットを含んでもよい。そのようなサブセットは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性および／または下位リソースのサブセットを含んでもよい。例として、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＳｔａｔｕｓ、ｅｘｅｃＲｅｓｕｌｔ およびｅｘｅｃＤｉｓａｂｌｅ属性、ならびにｓｕｂｓｃｒｉｐｔｉｏｎｓサブスクリプションリソースを含んでもよい。別の例として、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＳｔａｔｕｓ、ｅｘｅｃＲｅｓｕｌｔ、およびｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ属性、ならびにｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソースを含んでもよい。さらに別の例として、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、「ａｔｔｒｉｂｕｔｅ」、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＳｔａｔｕｓおよびｅｘｅｃＲｅｓｕｌｔ属性、ならびにｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソースを含んでもよい。下位リソースは、図２５Ｂ、図２８Ｃおよび図２８Ｄに示すサーバ＜ｃｏｍｍａｎｄ＞および／またはリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の要素（例えば、属性および下位リソース）の他の組み合わせを含んでもよい。

リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞は、図２５Ｂ、図２８Ｃおよび図２８Ｄには示されない＜ｃｏｍｍａｎｄ＞の他の要素も含んでもよい。それらの他の要素は、図２５Ｂ、図２８Ｃおよび図２８Ｄに示すリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の要素の任意の組み合わせと組み合わせたリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞に含まれてもよい。

リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞をｅｘｅｃＲｅｑｕｅｓｔｓ下位リソースの下に作成すると、Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞に、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞が作成されたノードの識別子を割り当ててもよい（「＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子」）。この＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子は、上記述べたように、例えばＵＲＩ、リンクおよびアドレスのいずれであってもよい。

Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞によりインポートされ、または継承されたサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに埋められた情報の一部またはすべてを、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞にインポート（またはリソース ＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞に継承させる）してもよい。そのような情報は、サーバ＜ｃｏｍｍａｎｄ＞ のｅｘｅｃＰａｒａｍｅｔｅｒｓ下位リソースに埋められた１つまたは複数のパラメータおよび／または引数を含んでもよい。情報はまた、例えばｅｘｅｃＭｏｄｅ、ｅｘｅｃＢａｓｅＤｅｌａｙ、ｅｘｅｃＡｄｄｉｔｉｏｎＤｅｌａｙ、ｅｘｅｃＦｒｅｑｕｅｎｃｙ、ｅｘｅｃＮｕｍｂｅｒ、およびｅｘｅｃＲｅｓｏｕｒｃｅの下位リソースに埋められた情報の一部またはすべてを含んでもよい。

リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成した後に、Ｍ２Ｍサーバは、要求メッセージ（「ＲＥＱＵＥＳＴ」（リクエスト））をＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷに送信してもよく、それによりかかるＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにおけるコマンド実行を呼び出してもよい。リクエストは、非ＲＥＳＴｆｕｌコマンドを含んでもよい。ＲＥＱＵＥＳＴはまた、マッピングされた属性、パラメータ、および引数のいずれかを含んでもよい。

ＲＥＱＵＥＳＴに応答して、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、非ＲＥＳＴｆｕｌコマンドを実行してもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、リクエストへのＲＥＳＰＯＮＳＥ（「ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥ」（コマンド実行レスポンス））を送信してもよい。このＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥは、存在する場合は結果を含むことができる（「｛｝」の記号で表される）。Ｍ２Ｍサーバは、結果を抽出し、および、後の読み出しのために、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のｅｘｅｃＲｅｓｕｌｔ下位リソースに格納してもよい。代わりに、かつ／またはそれに加えて、Ｍ２Ｍサーバは、結果をＮＡへのＲＥＳＰＯＮＳＥ（「ＮＡ ＲＥＳＰＯＮＳＥ」（応答））において送信してもよい。結果を取得した後に、ＮＡはそれを処理してもよい。

ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのコマンド実行を実行したことに成功したか、または非ＲＥＳＴｆｕｌコマンドのコマンド実行を実行したことに失敗したかを示すインジケーション（例えばコード）も含んでもよい。インジケーションは、コマンド実行の成功を示す１つの値および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがコマンド実行に成功したことを示す第１のインジケーション（例えばコード）、およびＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがコマンド実行に失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがコマンド実行に成功した場合にのみＲＥＳＰＯＮＳＥを発行してもよい。

図には示さないが、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのコマンド実行に失敗したときに、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除してもよい。Ｍ２Ｍサーバはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのコマンド実行に失敗したことを通知されることに応答して、サーバ＜ｃｏｍｍａｎｄ＞および／またはサーバ＜ｃｏｍｍａｎｄｓ＞の１つもしくは複数を削除してもよい。

ここで図２９Ｆを参照すると、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートが示される。図２９Ｆのメッセージフローは、以下の点を除いて図２９Ｅのメッセージフローと同様である。図２９Ｆのメッセージフローでは、Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成する前にリクエストを発行してもよい。また、Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成した後にＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥを受信してもよい。

図２９Ｇは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートである。図２９Ｇのメッセージフローは、以下の点を除いて図２９Ｅのメッセージフローと同様である。図２９Ｇのメッセージフローでは、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅおよび／またはｅｘｅｃＲｅｓｕｍｅ属性（または下位リソース）を含むリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成した後に、Ｍ２Ｍサーバは、対応するｅｘｅｃＤｉｓａｂｌｅ識別子、ｅｘｅｃＰａｕｓｅ識別子および／またはｅｘｅｃＲｅｓｕｍｅ識別子を発行元に送信してもよい。

あるいは、Ｍ２Ｍサーバは、ｅｘｅｃＥｎａｂｌｅ識別子、ｅｘｅｃＤｉｓａｂｌｅ識別子、ｅｘｅｃＰａｕｓｅ識別子、およびｅｘｅｃＲｅｓｕｍｅ識別子を、例えば「ａｔｔｒｉｂｕｔｅ」属性など、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性または下位リソースに格納してもよい。このようにして、そのように格納されたｅｘｅｃＥｎａｂｌｅ識別子、ｅｘｅｃＤｉｓａｂｌｅ識別子、ｅｘｅｃＰａｕｓｅ識別子、およびｅｘｅｃＲｅｓｕｍｅ識別子は後に読み出されてもよい。下記で説明するように、発行元（例えばＮＡ）は、ｅｘｅｃＤｉｓａｂｌｅ識別子、ｅｘｅｃＰａｕｓｅ識別子および／またはｅｘｅｃＲｅｓｕｍｅ識別子を使用して、取消しコマンド実行、中断コマンド実行および／または再開コマンド実行をそれぞれ呼び出してもよい。

ここで図２９Ｈを参照すると、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートが示される。図２９Ｈのメッセージフローは、以下の点を除いて図２９Ｇのメッセージフローと同様である。図２９Ｇのメッセージフローでは、Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成する前にリクエストを発行してもよい。また、Ｍ２Ｍサーバは、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を作成した後にコマンド実行応答を受信してもよい。

図２９Ｉおよび図２９Ｊは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行の状態の変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、ＮＡ（すなわち発行元）は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行してもよい。このＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を含むとともに、下位リソースｅｘｅｃＤｉｓａｂｌｅを指定してもよい（例えば、．．．／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＤｉｓａｂｌｅ）。あるいは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、Ｍ２Ｍサーバから送信されるＲＥＳＰＯＮＳＥを介して取得されるｅｘｅｃＤｉｓａｂｌｅ識別子（図２９Ｉ）または、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性からそれを読み出した後のＤｉｓａｂｌｅ識別子を含んでもよい（図２９Ｊ）。

そのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは、ＡＣＫ／ＮＡＣＫメッセージ（応答として図示する）を発行元に送信して、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

Ｍ２Ｍサーバは次いで、サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに従って、非ＲＥＳＴｆｕｌコマンドのＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ（「取消しコマンド実行」）を呼び出してもよい。Ｍ２Ｍサーバは、ＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すことの一部としていくつかの機能を実行してもよい。これらの機能は、例えば、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを、非ＲＥＳＴｆｕｌコマンドの実行のＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出す非ＲＥＳＴｆｕｌコマンド（「非ＲＥＳＴｆｕｌ取消しコマンド」）に変換または翻訳することを含んでもよい。上記機能は、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるコマンドと、非ＲＥＳＴｆｕｌ取消しコマンドとの間でマッピングされた属性、パラメータおよび／または引数を作成する機能も含んでもよい。

ＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すための機能を実行した後に、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにＲＥＱＵＥＳＴを送信してもよく、それにより、かかるＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにおいてＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出してもよい。ＲＥＱＵＥＳＴはまた、非ＲＥＳＴｆｕｌ取消しコマンドを含んでもよい。リクエストはまた、非ＲＥＳＴｆｕｌ取消しコマンドを実行するためのマッピングされた属性、パラメータ、および引数も含んでもよい。

ＲＥＱＵＥＳＴに応答して、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、非ＲＥＳＴｆｕｌ取消しコマンドを実行してもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷはＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥ（コマンド実行レスポンス）を送信してもよい。このＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥは、存在する場合には結果を含んでもよい。Ｍ２Ｍサーバは、結果を抽出し、および後の呼び出しのために、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のｅｘｅｃＲｅｓｕｌｔ下位リソースに結果を格納してもよい。代わりに、かつ／またはそれに加えて、Ｍ２Ｍサーバは、結果をＮＡレスポンスにおいて送信してもよい。結果を取得した後に、ＮＡはそれらを処理してもよい。

ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌ取消しコマンドの取消しコマンド実行を実行したことに成功したか、または非ＲＥＳＴｆｕｌ取消しコマンドの取消しコマンド実行を実行したことに失敗したかを示すインジケーション（例えばコード）も含んでもよい。インジケーションは、ＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮの成功を示す１つの値および失敗を示す別の値であってもよい。あるいは、レスポンスは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮに成功したことを示す第１のインジケーション（例えばコード）、およびＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮに失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが取消しコマンド実行に成功した場合にのみレスポンスを発行してもよい。

図には示さないが、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮに失敗したときに、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除してもよい。Ｍ２Ｍサーバはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのＣＡＮＣＥＬ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮに失敗したことを通知されることに応答して、サーバ＜ｃｏｍｍａｎｄ＞および／またはサーバ＜ｃｏｍｍａｎｄｓ＞の１つもしくは複数を削除してもよい。

図２９Ｋおよび２９Ｌは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行の状態における変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、ＮＡ（すなわち発行元）は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行してもよい。このＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を含むとともに、下位リソースｅｘｅｃＰａｕｓｅを指定してもよい（例えば、．．．／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃＰａｕｓｅ）。あるいは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、Ｍ２Ｍサーバから送信される応答を介して取得されるｅｘｅｃＰａｕｓｅ識別子（図２９Ｋ）または、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性から取得されたそれを読み出した後のｅｘｅｃＰａｕｓｅ識別子（図２９Ｌ）を含んでもよい。

そのＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは、ＡＣＫ／ＮＡＣＫメッセージ（応答として図示する）を発行元に送信して、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

Ｍ２Ｍサーバは次いで、サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに従って、非ＲＥＳＴｆｕｌコマンドのＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ（中断コマンド実行）を呼び出してもよい。Ｍ２Ｍサーバは、ＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すことの一部としていくつかの機能を実行してもよい。それらの機能は、例えば、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを、実行している非ＲＥＳＴｆｕｌコマンドのＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すための非ＲＥＳＴｆｕｌコマンド（「非ＲＥＳＴｆｕｌ中断コマンド」）に変換または翻訳することを含んでもよい。機能は、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるコマンドと、非ＲＥＳＴｆｕｌ中断コマンドとの間でマッピングされる属性、パラメータおよび／または引数を作成する機能も含んでもよい。

ＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すための機能を実行した後に、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにＲＥＱＵＥＳＴを送信してもよく、それにより、かかるＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにおいてＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出してもよい。リクエストはまた、非ＲＥＳＴｆｕｌ中断コマンドを含んでもよい。リクエストはまた、非ＲＥＳＴｆｕｌ中断コマンドを実行するためのマッピングされた属性、パラメータおよび引数も含んでもよい。

ＲＥＱＵＥＳＴに応答して、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、非ＲＥＳＴｆｕｌ中断コマンドを実行してもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥ（コマンド実行レスポンス）を送信してもよい。このＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥは、存在する場合は結果を含んでもよい。Ｍ２Ｍサーバは、結果を抽出し、および後の読み出しのために、当該結果をリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のｅｘｅｃＲｅｓｕｌｔ下位リソースに格納してもよい。代わりに、かつ／または加えて、Ｍ２Ｍサーバは、結果をＮＡ ＲＥＳＰＯＮＳＥ（ＮＡレスポンス）において送信してもよい。存在する場合、結果を取得した後に、ＮＡはそれらを処理してもよい。

ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌ中断コマンドの中断コマンド実行に成功したか、または非ＲＥＳＴｆｕｌ中断コマンドの中断コマンド実行に失敗したかを示すインジケーション（例えばコード）も含んでもよい。インジケーションは、ＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮの成功を示す１つの値、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに成功したかを示す第１のインジケーション（例えばコード）、およびＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したかを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮに成功した場合にのみＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥを発行してもよい。

示されないが、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したときに、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除してもよい。Ｍ２Ｍサーバはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌ中断コマンドのＰＡＵＳＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したことを通知されることに応答して、サーバ＜ｃｏｍｍａｎｄ＞および／またはサーバ＜ｃｏｍｍａｎｄｓ＞の１つもしくは複数を削除してもよい。

図２９Ｍおよび２９Ｎは、サーバ＜ｃｏｍｍａｎｄ＞などのリソースコマンド構造を更新して、非ＲＥＳＴｆｕｌコマンドのコマンド実行の状態における変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、ＮＡ（すなわち発行元）は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行してもよい。このＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を含むとともに、下位リソースｅｘｅｃＲｅｓｕｍｅを指定してもよい（例えば、．．．／＜ｃｏｍｍａｎｄ＞／ｅｘｅｃ−Ｒｅｓｕｍｅ）。あるいは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、Ｍ２Ｍサーバから送信されるＲＥＳＰＯＮＳＥを介して取得されるｅｘｅｃＲｅｓｕｍｅ識別子（図２９Ｍ）、または、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞（図２９Ｎ）の属性からそれを読み出した後のｅｘｅｃＲｅｓｕｍｅ識別子を含んでもよい。

このＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは、ＡＣＫ／ＮＡＣＫメッセージ（ＲＥＳＰＯＮＳＥとして示される）を発行元に送信して、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

Ｍ２Ｍサーバは次いで、サーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに従って、非ＲＥＳＴｆｕｌコマンドのＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ（再開コマンド実行）を呼び出してもよい。Ｍ２ＭサーバはＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出すことの一部としていくつかの機能を実行してもよい。これらの機能は、例えば、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを、中断された非ＲＥＳＴｆｕｌコマンドのＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ行を呼び出すための非ＲＥＳＴｆｕｌコマンド（「非ＲＥＳＴｆｕｌ再開コマンド」）に変換または翻訳することを含んでもよい。当該機能はまた、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞により識別されるコマンドと、非ＲＥＳＴｆｕｌ再開コマンドとの間でマッピングされた属性、パラメータおよび／または引数を作成するための機能を含んでもよい。

ＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出す機能を実行した後、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにＲＥＱＵＥＳＴを送信してもよく、それにより、そのＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷにおいてＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを呼び出してもよい。リクエストは非ＲＥＳＴｆｕｌ再開コマンドを含んでもよい。リクエストはまた、非ＲＥＳＴｆｕｌ再開コマンドを実行するためのマッピングされた属性、パラメータおよび引数のいずれかを含んでもよい。

ＲＥＱＵＥＳＴに応答して、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、非ＲＥＳＴｆｕｌ再開コマンドを実行してもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥ（コマンド実行レスポンス）を送信してもよい。このＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥは、存在する場合は結果を含んでもよい。Ｍ２Ｍサーバは、結果を抽出し、後の読み出しのために、当該結果をリソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のｅｘｅｃＲｅｓｕｌｔ下位リソースに格納してもよい。代わりに、かつ／または加えて、Ｍ２Ｍサーバは、結果をＮＡ ＲＥＳＰＯＮＳＥ（ＮＡレスポンス）において送信してもよい。存在する場合、結果を取得した後に、ＮＡはそれらを処理してもよい。

ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌ再開コマンドの再開コマンド実行の実行に成功したか、または非ＲＥＳＴｆｕｌ再開コマンドの再開コマンド実行の実行に失敗したかを示すインジケーション（例えばコード）も含んでもよい。インジケーションは、ＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮの成功を示す１つの値、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに成功したことを示す第１のインジケーション（例えばコード）、およびＭ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷがＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに成功した場合にのみＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮ ＲＥＳＰＯＮＳＥを発行してもよい。

図には示されてないが、Ｍ２Ｍサーバは、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌコマンドのＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したときに、リソース＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除してもよい。Ｍ２Ｍサーバはまた、Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷが非ＲＥＳＴｆｕｌ中断コマンドのＲＥＳＵＭＥ ＣＯＭＭＡＮＤ ＥＸＥＣＵＴＩＯＮを実行したことに失敗したことを通知されることに応答して、サーバ＜ｃｏｍｍａｎｄ＞および／またはサーバ＜ｃｏｍｍａｎｄｓ＞の１つもしくは複数を削除してもよい。

ここで図２９Ｏを参照すると、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞などのリソースコマンド構造を、非ＲＥＳＴｆｕｌコマンドを行う際に使用する情報により更新するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図２９Ｄのメッセージフローと同様に、図２９Ｏのメッセージフローは、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥを使用して、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞などのリソースコマンド情報の要素を、非ＲＥＳＴｆｕｌコマンドを行う際に使用することができる情報（例えば属性、パラメータおよび／または引数のいずれか）で埋めてもよい。

示されるように、ＮＡ（すなわち発行元）は、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥをＭ２Ｍサーバに発行して、更新を開始してもよい。ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子、ならびに＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性および／または下位リソースを情報で埋めるためのかかる情報（例えば、属性、パラメータおよび／または引数）を含んでもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信後、Ｍ２Ｍサーバは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を使用して、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を検索する。その後、Ｍ２Ｍサーバは、その＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性および／または下位リソースを、提供された情報で埋める。任意の所与の属性および／または下位リソースを埋めるための情報が提供されない場合、Ｍ２Ｍサーバは、そのような属性および／または下位リソースを、当初作成されたように（例えばブランク、またはデフォルトの属性および／もしくはパラメータを有する）、または最後に変更されたままにしてもよい。

ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥに応答して、Ｍ２Ｍサーバは発行元にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバは、示されるように、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を更新した後にＲＥＳＰＯＮＳＥを送信してもよい。あるいは、Ｍ２Ｍサーバは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の更新中にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバはまた、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの受信を確認応答するために、発行元にＡＣＫ／ＮＡＣＫメッセージ（図示せず）を送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥの確認応答がされていないことを示してもよい。

ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の更新に成功したか、または失敗したかを示すインジケーション（例えばコード）を含んでもよい。このインジケーションは、更新の成功を示す１つの値、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の更新に成功したことを示す第１のインジケーション（例えばコード）、および＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の更新に失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍサーバは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の更新に成功した場合にのみレスポンスを発行してもよい。

ＲＥＳＰＯＮＳＥはまた、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子、ならびに／または更新された属性および／もしくは下位リソースを含んでもよい。ＲＥＳＰＯＮＳＥはさらに、属性および／または下位リソースの更新に使用された情報、または同様のことを示す確認を含んでもよい。

図２９Ｐは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞などのリソースコマンド構造から情報を読み出すための例示的なメッセージフローを説明するメッセージフローチャートである。読み出しを開始するために、ＮＡ（すなわち発行元）はＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥをＭ２Ｍサーバに発行する。このＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を含んでもよい。

ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥの受信後、Ｍ２Ｍサーバは＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を使用して＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を検索してもよい。検索されると、Ｍ２Ｍサーバは、読出可能な情報（例えば属性、パラメータおよび／または引数）を有する＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性および／または下位リソースからそのような読出可能な情報（以降「読出属性情報」および／または「読出下位リソース情報」）をクエリし、および取得してもよい。読出属性情報および／または読出下位リソース情報は、例えば、格納されたｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、およびｅｘｅｃＲｅｓｕｍｅ識別子のいずれか、ならびに／またはｅｘｅｃＳｔａｔｕｓおよびｅｘｅｃＲｅｓｕｌｔｓなどの他の属性および／もしくは下位リソースからの任意の情報を含んでもよい。

読出属性情報および／または読出下位リソース情報を取得した後、Ｍ２ＭサーバはＮＡにＲＥＳＰＯＮＳＥを送信してもよい。このＲＥＳＰＯＮＳＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子、ならびに読出属性情報および／または読出下位リソース情報を含んでもよい。

代替として、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥが使用されて、読出可能な情報を有する＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の属性および／または下位リソースから、そのような読出可能な情報の１つまたは複数の選択部分を読み出してもよい。このことを容易にするために、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥは、読出可能な情報の選択部分を有するサーバ＜ｃｏｍｍａｎｄ＞の属性および／または下位リソースに割り当てられた各ノードの識別子を含んでもよい。その識別子（または２つ以上ある場合は複数の識別子）を使用して、Ｍ２Ｍサーバは、選択された読出属性情報および／または読出下位リソース情報を検索し、クエリし、および取得してもよい。そしてＭ２Ｍサーバは、選択された読出属性情報および／または読出下位リソース情報を含むＲＥＳＰＯＮＳＥをＮＡに送信してもよい。

示されないが、Ｍ２Ｍサーバはまた、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥの受信を確認応答するために発行元にＡＣＫ／ＮＡＣＫメッセージを送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥの確認応答がされていないことを示してもよい。

図２９Ｑは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートである。削除を開始するために、発行元は、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥをＭ２Ｍサーバに発行してもよい。発行元は、ＮＡ、Ｍ２Ｍデバイス、またはＭ２Ｍ ＧＷであってもよい。Ｍ２Ｍデバイスおよび／またはＭ２Ｍ ＧＷは、リブート、非ＲＥＳＴｆｕｌコマンドの取消し、登録解除等に応答して、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥを発行してもよい。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子を含んでもよい。あるいは、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞インスタンスの集合が作成されたリソース（例えば＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞）に割り当てられたノードの識別子を含んでもよい（以降「＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞識別子」）。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥの受信後、Ｍ２Ｍサーバは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞識別子または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞識別子を使用して、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞をそれぞれ検索し、および削除してもよい。このことは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞のすべての属性および／または下位リソースを削除すること、あるいは＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞については、それら＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の各＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞を削除することを含んでもよい。

ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥに応答して、Ｍ２Ｍサーバは発行元にＲＥＳＰＯＮＳＥを送信してもよい。Ｍ２Ｍサーバは、示されるように、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞を削除した後に、ＲＥＳＰＯＮＳＥを送信してもよい。あるいは、Ｍ２Ｍサーバは、＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の削除中に、レスポンスを送信してもよい。Ｍ２Ｍサーバは、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥの受信を確認応答するために、発行元にＡＣＫ／ＮＡＣＫメッセージ（図示せず）を送信してもよい。発行元により（例えば一定時間内に）ＡＣＫ／ＮＡＣＫメッセージが受信されないことは、Ｍ２ＭサーバによってＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥの確認応答がされていないことを示してもよい。

レスポンスは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の削除に成功したか、または失敗したかを示すインジケーション（例えばコード）を含んでもよい。インジケーションは、削除の成功を示す１つの値、および失敗を示す別の値であってもよい。あるいは、ＲＥＳＰＯＮＳＥは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の削除に成功したことを示す第１のインジケーション（例えばコード）、およびＭ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の削除に失敗したことを示す第２のインジケーション（例えばコード）を含んでもよい。別の代替として、Ｍ２Ｍサーバは、Ｍ２Ｍサーバが＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅｓ＞の削除に成功した場合にのみＲＥＳＰＯＮＳＥを発行してもよい。

ここで図２９Ｒを参照すると、サーバ ＜ｃｏｍｍａｎｄ＞、サーバ＜ｃｏｍｍａｎｄｓ＞および／または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図２９Ｒのメッセージフローは、図２９Ｃのメッセージフローと図２９Ｉ（または図２９Ｊ）のメッセージフローとの組み合わせ、または図２９Ｑのメッセージフローと図２９Ｉ（または図２９Ｊ）のメッセージフローとの組み合わせと同様である。示されるように、発行元がＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥをＭ２Ｍサーバに発行するときに、Ｍ２Ｍサーバは、任意の＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞がコマンド実行または中断コマンド実行に使用されているかを判定し、そしてＭ２Ｍサーバは、それを削除する前にそのような＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞の取消しコマンド実行を実施してもよい。Ｍ２Ｍサーバは、図２９Ｉまたは図２９Ｊのメッセージフローに従って、取消しコマンド実行を実施してもよい。

前述したことに加えて、Ｍ２Ｍサーバは、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥまたはＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥが発行されることなく、サーバ＜ｃｏｍｍａｎｄ＞または別のリソースコマンド構造を作成および／または削除してもよい。

例示的なゲートウェイベースのマシンツーマシン（「Ｍ２Ｍ」）デバイス管理
一実施形態に従って、図３０Ａは、ＯＭＡ ＧｗＭＯ「透過」モードを利用することによりＭ２Ｍ ＧＷ（Ｇ’）を介してＤタイプＥＴＳＩ Ｍ２Ｍデバイスを管理するための例示的アーキテクチャを示す。図３０Ａを参照すると、ＮＲＥＭはＧｗＭＯ固有のインタフェースおよびコンポーネントを使用して、ＧＲＥＭからデバイス情報を取得し、ＧＲＥＭはそのタスクを実行するためにＧｗＭＯインタフェースを介してＤＲＥＭと順に通信する。次いで、ＮＲＥＭは、メッセージ交換のためにＯＭＡ ＤＭプロトコル−クライアントサーバ対話モデルを使用して直接ＤＲＥＭと通信してもよい。「透過」モードでは、ＧＲＥＭはデバイスを管理するためにＯＭＡ ＤＭプロトコルをサポートする必要はないことに留意されたい。

一実施形態に従って、図３０Ｂは、ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭの例示的アーキテクチャを示す。図３０Ｂを参照すると、ｘＲＥＭが機能的な下位モジュールに分割される。例えば、ＲＥＭサーバは、デバイス管理においてサーバの役割を果たす（ＯＭＡ ＤＭまたはＡＣＳにおけるＤＭサーバと同様）。ＲＥＭクライアントは、デバイス管理においてクライアントの役割を果たす（ＯＭＡ ＤＭまたはＣＰＥにおけるＤＭクライアントと同様）。ＲＥＭプロキシコンポーネントは、ＲＥＭプロキシサーバ（ＮＲＥＭにおける）およびＲＥＭプロキシクライアント（ＤＲＥＭにおける）とそれぞれ通信するＧＲＥＭのみに存在する。ＲＥＭプロキシサーバは、ＲＥＭプロキシコンポーネントと通信してＧＷの後ろにあるデバイスの情報を取得するために使用されるＮＲＥＭに存在する。ＲＥＭプロキシクライアントは、ＤＲＥＭに存在し、ＤＲＥＭは、デバイス情報をＧＷにレポートするようにＲＥＭプロキシコンポーネントに応答するために使用される。デバイス情報は最終的にＮＲＥＭに転送される。

プロキシモードでは、Ｍ２Ｍ ＧＷは、「中間者」（man-in-the-middle）のように動作してもよい。Ｍ２Ｍ ＧＷは、図３１Ａに示すようにＧｗＭＯ、ならびにＤＭクライアントおよびＤＭサーバの両方をサポートすることができ、図３１Ａは、ＯＭＡ ＧｗＭＯ １．０を利用するための例示的アーキテクチャを示す。このモードでは、ＮＲＥＭは直接ＤＲＥＭと通信せず、代わりにＧＲＥＭにより変換され、および中継される。ＤＲＥＭに対して、ＧＲＥＭはサーバのように見え、ＮＲＥＭに対しては、ＧＲＥＭはクライアントのように振舞う。このモードは、Ｍ２Ｍ ＧＷにより多くの機能と機能性を追加する。例示的な利益は、コマンドの論理出力数および応答集約などのより付加価値の高いサービス、ならびにＭ２Ｍコアにおけるトラフィック負荷の軽減、および制約されたＭ２Ｍデバイス、特にスリープ状態のノードの管理の高効率化を含む。図３１Ｂはこのモードに対するｘＲＥＭの例示的アーキテクチャを示す。

一実施形態に従って、Ｍ２Ｍデバイス（Ｄ’）はＥＴＳＩ Ｍ２Ｍサービス能力を有さなくてもよい。それらはＯＭＡ ＤＭのクライアント機能は有さないが、他のＯＭＡでないデバイス管理プロトコルを有すると想定されてもよい。その結果、Ｍ２Ｍ ＧＷは「適合」モードを採用して、ＯＭＡプロトコルと他の管理プロトコルとの間で変換してもよい。図３２Ａは、ＯＭＡ ＧｗＭＯ １．０を利用するための例示的アーキテクチャを示す。図３２Ｂは、ＥＴＳＩ Ｍ２Ｍ ｘＲＥＭの例示的アーキテクチャを示す。「プロキシ」モードと比較して、ＳＮＭＰなどのいくつかの非ＯＭＡ管理プロトコルは、ｄＩａインタフェースまたは別のＮＤＭ−１インタフェースのいずれかの上でのＭ２Ｍ ＧＷとＭ２Ｍデバイスとの間の対話に利用されてもよい。プロトコル変換は、管理コマンドのマッピング／翻訳だけでなく、管理ツリー構造（またはリソース）のマッピング／翻訳等も指すことに留意されたい。Ｄ’タイプのデバイスが実際にＯＭＡ ＤＭのクライアント機能を有する場合は、「透過」モードおよび「プロキシ」モードも適用することができる。

一実施形態に従って、ｄタイプの非ＥＴＳＩ Ｍ２Ｍデバイスがいくつかの異なる管理プロトコルを使用することができることが想定されてもよい。その結果、Ｍ２Ｍ ＧＷは「適合」モードを使用して、それらを管理してもよい。図３３Ａおよび図３３Ｂに示すアーキテクチャは、図３２Ａおよび図３２Ｂに示すものと同様である。ｄタイプのデバイスは、ＺｉｇＢｅｅコーディネータなどの非ＥＴＳＩのＭ２Ｍ ＧＷであり、それを通じて、ＥＴＳＩのＭ２Ｍサービス能力を使用しおよびアクセスして、非ＥＴＳＩ Ｍ２Ｍエリアネットワークをともに接続することができることに留意されたい。

一実施形態では、図３４は、ＯＭＡ ＧｗＭＯを利用したＧＷベースのデバイス管理の図を示す。図３４に示すように、単一のＭ２Ｍ ＧＷは、複数のＭ２Ｍエリアネットワークを異なるタイプのＭ２Ｍデバイスに接続することができる。Ｍ２Ｍ ＧＷは、異なるエリアネットワークに対して、透過モード、プロキシモード、または適合管理モードを課すことができる。

図３０乃至図３４のすべてにおいて、追加的なＯＭＡ ＧｗＭＯおよびＤＭ論理エンティティ（ＯＭＡ ＤＭサーバなど）は必ずしもｘＲＥＭの一部ではなく、代わりにｘＲＥＭの外部にある独立したエンティティであってもよい。ただし、本明細書に開示されるアーキテクチャが適用されてもよい。例えば、図３５は、ＯＭＡ ＤＭおよびＭ２Ｍ ＧＷを部分的に緊密に統合する場合の例示的アーキテクチャを示す。図３６は、ＯＭＡ ＤＭおよびＭ２Ｍ ＧＷを緩く統合する場合の例示的アーキテクチャを示す。

Ｍ２Ｍゲートウェイの後ろにあるＭ２ＭエリアネットワークおよびＭ２Ｍデバイスを管理するための例示的なデータモデル
下記でより詳細に説明するように、Ｍ２Ｍゲートウェイの後ろにあるマシンツーマシン通信（Ｍ２Ｍ）エリアネットワークおよびＭ２Ｍデバイスを管理するための管理オブジェクト（ＭＯ）。Ｍ２Ｍエリアネットワーク管理は、デバイスリスト（device inventory）および構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、およびデバイスのグループ管理などの機能を提供してもよい。これは、アプリケーション（Ａ）、Ｍ２Ｍダイレクトデバイス（Ｄ）、Ｍ２Ｍローカルデバイス（ｄタイプ、Ｄ’タイプ、またはＤタイプのデバイス）、およびＭ２Ｍゲートウェイ（Ｇ）を含んでもよい。

管理オブジェクト（ＭＯ）は、Ｍ２ＭゲートウェイによりＭ２Ｍエリアネットワークを管理するために定義されてもよい。そのような１つのＭＯは、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏリソースであり、当該リソースは、エリアネットワーク情報および構成についての管理オブジェクトであってもよい。別のＭＯは、Ｍ２ＭローカルデバイスリストについてのＭＯとすることができるｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙリソースであってもよい。Ｍ２Ｍローカルデバイスグループについての管理オブジェクトは、例えばｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓリソースであってもよい。Ｍ２Ｍローカルデバイスのグループを操作する管理オブジェクトは、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓおよびｅｔｓｉＡｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓのいずれかであってもよく、ならびにＭ２Ｍデバイス内に統合されたセンサについての管理オブジェクトリソースは、ｅｔｓｉＳｅｎｓｏｒｓリソースであってもよい。

ＭＯは、異なる従属レベルにおいて編成および／または配置されてもよい。例えば、ＭＯは、Ｍ２Ｍサーバにおける＜ｓｃｌＢａｓｅ−ｏｆ−Ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ＧＳＣＬ＞の下のいずれかにある同一のプレースホルダの下位リソースであってもよい。例として、Ｍ２Ｍゲートウェイの後ろにあるアタッチされたデバイスを全体として管理するために、＜ｓｃｌＢａｓｅ−ｏｆ−ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ＧＳＣＬ＞／ａｔｔａｃｈｅｄＤｅｖｉｃｅｓの下にｍｇｍｔＯｂｊｓ下位リソースが作成されてもよい。ＭＯは、例えば、＜ｓｃｌＢａｓｅ−ｏｆ−Ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ＧＳＣＬ＞／ａｔｔａｃｈｅｄＤｅｖｉｃｅｓ／ｍｇｍｔＯｂｊｓの下に配置されてもよい。ＭＯは、別のＭＯの下位リソースであってもよい。例えば、ｅｔｓｉＳｅｎｓｏｒｓは、＜ｄｅｖｉｃｅＩｎｖｅｎｔｏｒｙ＞の下位リソースであってもよく、＜ｄｅｖｉｃｅＩｎｖｅｎｔｏｒｙ＞はｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙの下位リソースであってもよい。

図３７に示すように、エリアネットワーク情報および構成についてのＭＯ、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏは、サブスクリプションの集合および＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞などの、１つまたは複数の属性および複数の下位リソースを含んでもよい。＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞は、Ｍ２Ｍエリアネットワークのインスタンスであってもよい。ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏの属性は、例えば、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、ｎｕｍＯｆＡｒｅａＮｗｋｓ、およびｄｅｓｃｒｉｐｔｉｏｎを含んでもよい。ｎｕｍＯｆＡｒｅａＮｗｋｓ属性は、Ｍ２Ｍエリアネットワークの数を表してもよい。ｄｅｓｃｒｉｐｔｉｏｎ属性は、ｍｇｍｔＯｂｊのテキスト形式の詳細であってもよい。属性（および／または変数）は、ＥＴＳＩ Ｍ２Ｍ ＴＳ １０２ ６９０に準拠してもよい。代替として、属性および／またはサブスクリプションの集合は、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、ｎｕｍＯｆＡｒｅａＮｗｋｓ、およびｄｅｓｃｒｉｐｔｉｏｎを含み、保持し、および／または格納してもよい。

図３８Ａに示すように、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏリソースの＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、１つまたは複数の属性および複数の下位リソースを含んでもよい。＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、（ｉ）Ｍ２Ｍエリアネットワークの識別を収容するａｒｅａＮｗｋＩＤ属性、（ｉｉ）例えばＢｌｕｅｔｏｏｔｈ（登録商標）／６ＬｏＷＰＡＮ、８０２．１５．４／６ＬｏＷＰＡＮ、Ｗｉ−ＦｉネットワークなどＭ２Ｍエリアネットワークのタイプを指定するａｒｅａＮｗｋＴｙｐｅ属性、（ｉｉｉ）Ｍ２Ｍエリアネットワークの動作チャネル周波数を指定するｗｏｒｋｍｇＣｈａｎｎｅｌＦｒｅｑｕｅｎｃｙ属性、および（ｉｖ）Ｍ２Ｍエリアネットワークのアドレスモード（例えば、ＩＰｖ４、ＩＰｖ６、Ｓｈｏｒｔ ＭＡＣ（メディアアクセス制御）、またはＬｏｎｇ ＭＡＣ）を指定するａｄｄｒｅｓｓＭｏｄｅ属性、を含んでもよい。

＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースの複数の下位リソースは、サブスクリプションの集合、＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞下位リソース、ａｔｔａｃｈｅｄＤｅｖｉｃｅｓ下位リソース、グループ下位リソース、６ＬｏＷＰＡＮ下位リソース、Ｗｉ−Ｆｉ下位リソース、ＲＦＩＤ下位リソース、およびＺｉｇＢｅｅ下位リソースを含んでもよい。

＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞下位リソースは、エリアネットワークインスタンスにおける単一のデバイスについての情報を含んでもよい。ａｔｔａｃｈｅｄＤｅｖｉｃｅｓ下位リソースは、エリアネットワークにアタッチされたすべてのデバイスについてのプレースホルダであってもよく、およびグループ下位リソースは、グループ動作または動作の論理出力数に対して定義されたデバイスグループについてのプレースホルダであってもよい。６ＬｏＷＰＡＮ下位リソースは、６ＬｏＷＰＡＮネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークが６ＬｏＷＰＡＮネットワークであるときに使用されてもよい。Ｗｉ−Ｆｉ下位リソースは、Ｗｉ−Ｆｉネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがＷｉ−Ｆｉネットワークであるときに使用されてもよい。ＲＦＩＤ下位リソースは、ＲＦＩＤネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがＲＦＩＤネットワークであるときに必要とされる場合があり、およびＺｉｇＢｅｅ下位リソースは、ＺｉｇＢｅｅネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがＺｉｇＢｅｅネットワークであるときに必要とされる場合がある。拡張が下位リソースとして含まれてもよく、および拡張のためにプレースホルダを提供してもよい。

＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースに関連付けられた属性は、（ｉ）エリアネットワークインスタンスにおけるデバイスの数を表すことができるｎｕｍＯｆＤｅｖｉｃｅｓ（ｉｉ）２回のスリープ間の間隔を表すことができるｓｌｅｅｐＩｎｔｅｒｖａｌ（ｉｉｉ）各スリープの継続時間を表すことができるｓｌｅｅｐＤｕｒａｔｉｏｎ（ｉｖ）そのエリアネットワーク＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースにおける最大の伝送単位を表すことができるＭＴＵ、および（ｖ）ＩＥＴＦ ＣｏＡＰブロックサイズ伝送で使用されるブロックサイズを表すことができるｂｌｏｃｋＳｉｚｅ、を含んでもよい。ｂｌｏｃｋＳｉｚｅは、エリアネットワーク＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースが制約されたアプリケーションプロトコル（ＣｏＡＰプロトコル）をサポートするときに、有用である場合がある。ｓｌｅｅｐＩｎｔｅｒｖａｌ属性は、一般的な時間間隔として使用されてもよく、これを通じてＭ２Ｍサーバは、何らかの報告または応答を、例えばｓｌｅｅｐＩｎｔｅｒｖａｌの時間単位ごと、など周期的に返送するようにＭ２Ｍデバイスおよび／またはＭ２Ｍゲートウェイに指示することができる。

図３８Ｂに示すように、６ＬｏＷＰＡＮ下位リソースは、ｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソースのサブスクリプション、ならびに６ＬｏＷＰＡＮにおけるアドレス指定、ルーティング、および近隣の検出のいずれかに関連する複数の属性を有してもよい。複数の属性は、（ｉ）エリアネットワークのＩＰアドレスプレフィクスを指定するためのｉｐＡｄｄｒＰｒｅｆｉｘ属性、および（ｉｉ）Ｍ２Ｍエリアネットワークのルーティングモードを指定するためのｒｏｕｔｉｎｇＭｏｄｅ属性を含んでもよい。６ＬｏＷＰＡＮネットワークについて、ｒｏｕｔｉｎｇＭｏｄｅ属性は、ルーティングモードがメッシュアンダー（mesh-under）またはルートオーバー（route-over）になることを指定してもよい。

複数の属性はまた、（ｉ）変更に備えてヘッダ圧縮コンテキスト情報を発信し続ける最小の時間を指定するためのｍｉｎＣｏｎｔｅｘｔＣｈａｎｇｅＤｅｌａｙ属性（ｉｉ）送信されることになる要求されていないルータアドバタイズ（advertisements）の最大数を格納および／または指定するためのｍａｘＲｔｒＡｄｖｅｒｔｉｓｅｍｅｎｔｓ属性（ｉｉｉ）すべてのノードのマルチキャストアドレスに送信される２つの連続したルータアドバタイズ間の最小の間隔を指定するためのｍｉｎＤｅｌａｙＢｅｔｗｅｅｎＲａｓ属性（ｉｖ）ルータアドバタイズメッセージを、受信されたルータ要請（Solicitation）メッセージへの応答として送信する最大の遅延を指定するためのｍａｘＲａＤｅｌａｙＴｉｍｅ属性（ｖ）一時的な隣接キャッシュについてのタイマを格納し、および提供するためのｅｎｔａｔｉｖｅＮｃｅＬｉｆｅｔｉｍｅ属性（ｖｉｉ）重複したアドレス検出メッセージについてのホップ制限値を格納および／または指定するためのｈｏｐＬｉｍｉｔ属性（ｖｉｉｉ）第１のｍａｘＲｔｒＳｏｌｉｃａｔｉｏｎｓのルータ要請の最初の再送に対する間隔を格納および／または指定するためのｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性（ｉｘ）ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌにより定義された最初の再送の回数を格納および／または指定するためのｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎｓ属性（ｘ）デバイスが最初の再送の後に二進指数バックオフを使用する場合があるため、ルータ要請に対する最大の再送間隔を格納および／または指定するためのｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性、を含んでもよい。ｈｏｐＬｉｍｉｔ、ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ、ｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎｓ、およびｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性は、デバイスに適用可能であってもよい。他のパラメータは、デバイスおよびＭ２Ｍゲートウェイの両方に適用可能であってもよい。

図３８Ｃに示すように、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏリソースの＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、１つまたは複数の属性およびｓｕｂｓｃｒｉｐｔｉｏｎｓ下位リソースを含んでもよい。＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、（ｉ）Ｍ２Ｍエリアネットワークの識別を収容するａｒｅａＮｗｋＩＤ属性（ｉｉ）例えばＢｌｕｅｔｏｏｔｈ／６ＬｏＷＰＡＮ、８０２．１５．４／６ＬｏＷＰＡＮ、Ｗｉ−ＦｉネットワークなどのＭ２Ｍエリアネットワークのタイプを指定するａｒｅａＮｗｋＴｙｐｅ属性（ｉｉｉ）Ｍ２Ｍエリアネットワークの動作チャネル周波数を指定するｗｏｒｋｍｇＣｈａｎｎｅｌＦｒｅｑｕｅｎｃｙ属性（ｉｖ）Ｍ２Ｍエリアネットワークのアドレスモード（例えば、ＩＰｖ４、ＩＰｖ６、Ｓｈｏｒｔ ＭＡＣ（メディアアクセス制御）、またはＬｏｎｇ ＭＡＣ）を指定するａｄｄｒｅｓｓＭｏｄｅ属性（ｖ）６ＬｏＷＰＡＮ属性、Ｗｉ−Ｆｉ属性、ＲＦＩＤ属性、ＺｉｇＢｅｅ属性、を含んでもよい。

６ＬｏＷＰＡＮ属性は、６ＬｏＷＰＡＮネットワークに関連するパラメータ、例えばエリアネットワークが６ＬｏＷＰＡＮネットワークであるときに使用することができる情報、を含むプレースホルダであってもよい。Ｗｉ−Ｆｉ属性は、Ｗｉ−Ｆｉネットワークに関連するパラメータ、例えばエリアネットワークがＷｉ−Ｆｉネットワークであるときに使用することができる情報、を含むプレースホルダであってもよい。ＲＦＩＤ属性は、ＲＦＩＤネットワークに関連するパラメータを含むプレースホルダであってもよく、およびＺｉｇＢｅｅ属性は、ＺｉｇＢｅｅネットワークに関連するパラメータを含むプレースホルダであってもよい。

加えて、＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、特定タイプのエリアネットワークに関連するより多くの属性を有してもよい。例えば、Ｍ２Ｍエリアネットワークが６ＬｏＷＰＡＮネットワークである場合、＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースは、６ＬｏＷＰＡＮにおけるアドレス指定、ルーティング、および／または隣接検出に関連するいくつかの属性を含んでもよい。複数の属性は、（ｉ）ｉｐＡｄｄｒＰｒｅｆｉｘ属性、（ｉｉ）ｒｏｕｔｉｎｇＭｏｄｅ属性、（ｉｉｉ）ｍｉｎＣｏｎｔｅｘｔＣｈａｎｇｅＤｅｌａｙ属性、（ｉｖ）ｍａｘＲｔｒＡｄｖｅｒｔｉｓｅｍｅｎｔｓ属性、（ｖｉ）ｍｉｎＤｅｌａｙＢｅｔｗｅｅｎＲａｓ属性、（ｖｉｉ）ｍａｘＲａＤｅｌａｙＴｉｍｅ属性、（ｖｉｉｉ）ｔｅｎｔａｔｉｖｅＮｃｅＬｉｆｅｔｉｍｅ属性、（ｉｘ）ｈｏｐＬｉｍｉｔ属性、（ｘ）ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性、（ｘｉ）ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌにより定義された最初の再送の回数を格納および／または指定するためのｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎｓ属性、ならびに（ｘｉｉ）ｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性、を含んでもよい。ｈｏｐＬｉｍｉｔ、ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ、ｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎｓ、およびｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ属性はデバイスに適用可能であってもよい。他のパラメータは、デバイスおよびＭ２Ｍゲートウェイの両方に適用可能であってもよい。

図３９に示すように、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙ ＭＯは、（ｉ）Ｍ２Ｍゲートウェイにアタッチされた各アクティブなデバイスについての個々の＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞情報の集合を含むことができる、＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞下位リソース（ｉｉ）各エリアネットワークを識別することができる＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソース（ｉｉｉ）定義されたデバイスグループに対するプレースホルダを提供することができるｇｒｏｕｐｓ下位リソース、および（ｉｖ）サブスクリプション集合下位リソース。サブスクリプション集合下位リソースは、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＳＳフォーマットに含めることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、ｄｅｓｃｒｉｐｔｉｏｎ（例えば、ｍｇｍｔＯｂｊのテキスト形式の詳細）、およびＭ２Ｍゲートウェイにアタッチされたデバイスの数、ｎｕｍＯｆＤｅｖｉｃｅｓなどの属性を含んでもよい。

同一のＭ２Ｍゲートウェイの下のＭ２Ｍエリアネットワークは、単一のｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙ下位リソースに対応してもよく、または各エリアネットワークがその自身のｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙ下位リソースを有してもよい。ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙ下位リソースは、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏ下位リソースの下位にあってもよい。代替として、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙ ＭＯは、＜ａｒｅａＮｗｋＩｎｓｔａｎｃｅ＞下位リソースおよび／またはｇｒｏｕｐｓ下位リソースを含まなくてもよい。

図４０Ａに示すように、各＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞は、ｄｅｖｉｃｅＧｒｏｕｐｓＬｉｓｔなどのデバイスが属するグループの識別のリストと、Ｄ’Ａ、またはＤＡなどの、このデバイス上のすべてのアプリケーションのアプリケーション識別のグループ、ｄｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎｓＬｉｓｔと、隣接ノードの識別のリスト、ｄｅｖｉｃｅＮｅｉｇｈｂｏｒｓＬｉｓｔと、バッテリ情報、ｅｔｓｉＢａｔｔｅｒｙと、メモリ情報、ｅｔｓｉＭｅｍｏｒｙと、センサ／アクチュエータ情報、ｅｔｓｉＳｅｎｓｏｒと、６ＬｏＷＰＡＮネットワークに関連するパラメータを含むプレースホルダを提供することができる６ＬｏＷＰＡＮと、Ｗｉ−Ｆｉネットワークに関連するパラメータを含むプレースホルダを提供することができるＷｉ−Ｆｉと、ＲＦＩＤネットワークに関連するパラメータを含むプレースホルダを提供することができるＲＦＩＤと、ＺｉｇＢｅｅネットワークに関連するパラメータを含むプレースホルダを提供することができるＺｉｇＢｅｅと、拡張のためのプレースホルダとすることができるｅｘｔｅｎｓｉｏｎｓと、を含んでもよい。

このグループは、例えばＥＴＳＩ ＴＳ １０２ ６０９に規定されるものなどの標準的なグループリソースを提供してもよい。＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞は、デバイスのタイプとすることができるｄｅｖｉｃｅＴｙｐｅ、デバイスの識別子とすることができるｄｅｖｉｃｅＩＤ、デバイスのアドレス種別とすることができるａｄｄｒｅｓｓＴｙｐｅ、デバイスが属するＭ２Ｍエリアネットワークの識別を含むことができるａｒｅａＮｗｋＩＤ、Ｍ２Ｍエリアネットワークの内部で使用されるデバイスの内部ＩＰアドレスとすることができるｉｎｔｅｒｎａｌａｄｄｒｅｓｓ、およびＭ２Ｍエリアネットワークの外部で使用されるデバイスの外部ＩＰアドレスとすることができるｅｘｔｅｒｎａｌａｄｄｒｅｓｓ、などの属性を含んでもよい。このアドレスは、Ｍ２Ｍゲートウェイにおけるアドレス変換でポート番号が使用される場合に、ポート情報を含んでもよい。さらに、２回のスリープ間の間隔、ｓｌｅｅｐＩｎｔｅｒｖａｌと、各スリープの継続時間、ｓｌｅｅｐＤｕｒａｔｉｏｎ、スリープもしくはアウェイク（awake）などのデバイス状態、ステータス、エリアネットワークにおける最大伝送単位を含むことができるＭＴＵ、およびＩＥＴＦ ＣｏＡＰのブロックサイズ伝送で使用されるブロックサイズを含むことができるｂｌｏｃｋＳｉｚｅ。

図４０Ｂに示すように、各＜ｄｅｖｉｃｅＩｎｓｔａｎｃｅ＞は、ｄｅｖｉｃｅＧｒｏｕｐＬｉｓｔなどのデバイスが属するグループの識別のリスト、例えば、Ｄ’Ａ、またはＤＡなどの、そのデバイス上のすべてのアプリケーションのアプリケーション識別のグループ、ｄｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎｓＬｉｓｔ、隣接ノードの識別のリスト、ｄｅｖｉｃｅＮｅｉｇｈｂｏｒｓＬｉｓｔ、バッテリ情報、ｅｔｓｉＢａｔｔｅｒｙ、メモリ情報、ｅｔｓｉＭｅｍｏｒｙ、センサ／アクチュエータ情報、ｅｔｓｉＳｅｎｓｏｒ、を含んでもよい。サブスクリプション集合は、デバイスのタイプとすることができるｄｅｖｉｃｅＴｙｐｅ、デバイス識別子とすることができるｄｅｖｉｃｅＩＤ、デバイスのアドレス種別とすることができるａｄｄｒｅｓｓＴｙｐｅ、デバイスが属するＭ２Ｍエリアネットワークの識別を含むことができるａｒｅａＮｗｋＩＤ、Ｍ２Ｍエリアネットワークの内部で使用されるデバイスの内部ＩＰアドレスとすることができるｉｎｔｅｒｎａｌａｄｄｒｅｓｓ、およびＭ２Ｍエリアネットワークの外部で使用されるデバイスの外部ＩＰアドレスとすることができるｅｘｔｅｒｎａｌａｄｄｒｅｓｓ、などの属性を含んでもよい。このアドレスは、Ｍ２Ｍゲートウェイにおけるアドレス変換でポート番号が使用される場合のポート情報を含んでもよい。さらに、２回のスリープ間の間隔であるｓｌｅｅｐＩｎｔｅｒｖａｌ、各スリープの継続時間であるｓｌｅｅｐＤｕｒａｔｉｏｎ、スリープ状態やアウェイク状態などのデバイス状態のステータス、送信されることになる要求されていないルータアドバタイズの最大数であるｍａｘＲｔｒＡｄｖｅｒｔｉｓｅｍｅｎｔｓ、すべてのノードのマルチキャストアドレスに送信される２回の連続したルータアドバタイズ間の最小の間隔であるｍｉｎＤｅｌａｙＢｅｔｗｅｅｎＲａｓ、ルータアドバタイズメッセージを受信されたルータ要請メッセージへの応答として送信する際の最大の遅延であるｍａｘＲａＤｅｌａｙＴｉｍｅ、一時的な隣接キャッシュについてのタイマであるｔｅｎｔａｔｉｖｅＮｃｅＬｉｆｅｔｉｍｅ、重複したアドレス検出メッセージについてのホップの上限値であるｈｏｐＬｉｍｉｔ、第１のｍａｘＲｔｒＳｏｌｉｃａｔｉｏｎｓのルータ要請の最初の再送の間隔であるｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ、最初の再送の回数であるｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎｓ、および、デバイスが最初の再送の後に二進指数バックオフを使用することができることから、ルータ要請の最大の再送間隔であるｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ。

図４１Ａに示すように、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓ ＭＯは、デバイスおよびサブスクリプションのグループを定義する＜ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅ＞などの下位リソースを含んでもよい。サブスクリプション集合および属性は、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＦＳとして形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎ、を含んでもよい。

図４１Ｂに示すように、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓ ＭＯは、下位リソースのｓｕｂｓｃｒｉｐｔｉｏｎと、デバイスの複数グループの集合として定義するグループとを含んでもよい。ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓは、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＦＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎ、などの属性を含んでもよい。

各下位リソース＜ｇｒｏｕｐ＞は、同一グループに属するデバイスの識別のリストを含んでもよい。加えて、デバイスは、複数の＜ｇｒｏｕｐ＞インスタンスに属し、および存在してもよい。

図４２に示すように、各＜ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅ＞は、サブスクリプション集合を有するｓｕｂｓｃｒｉｐｔｉｏｎなどの下位リソースと、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＦＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎなどの属性とを含んでもよい。さらに、ｇｒｏｕｐＩＤは、グループ種別を含むことができるグループの識別であるｇｒｏｕｐＴｙｐｅ、グループにおけるデバイスの数などのｇｒｏｕｐＳｉｚｅ、グループにおけるデバイスの集合として定義されたメンバ、およびデバイスがそのグループのメンバになるための条件を指定する条件、を含んでもよい。

図４３Ａに示すように、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓ ＭＯは、グループ上で実行されることになる動作または操作を表すことができる＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞と、各デバイスがデバイスのリストを含む定義されたデバイスグループのプレースホルダを含むことができ、および１つまたは複数の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞によって操作されるｇｒｏｕｐｓ等の下位リソースを含んでもよい。サブスクリプション集合と属性は、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎを含んでもよい。

Ｍ２Ｍゲートウェイの後ろにあるＭ２Ｍデバイスのグループを管理／動作させるために使用されることに加えて、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓは、Ｍ２Ｍサーバに直接接続するＭ２Ｍデバイスのグループの動作を管理するために使用されてもよい。その場合は、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓは、＜ｓｃｌＢａｓｅ−ｏｆ−Ｓｅｒｖｅｒ＞／ｓｃｌｓ／ｍｇｍｔＯｂｊｓ／ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓの下に配置されてもよい。対応する＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞は、Ｍ２Ｍデバイスまたはゲートウェイのグループの登録解除、Ｍ２Ｍデバイスまたはゲートウェイのグループのスリープモードへの移行、Ｍ２Ｍデバイスまたはゲートウェイのグループのリブート、およびＭ２Ｍデバイスまたはゲートウェイのグループ上での同一のソフトウェア／ファームウェアの更新の実行、を含んでもよい。

また、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓが使用されて、Ｍ２ＭデバイスまたはＭ２Ｍゲートウェイ上のアプリケーションのグループを管理してもよい。その場合、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓは、＜ｓｃｌＢａｓｅ−ｏｆ−Ｓｅｒｖｅｒ＞／ｓｃｌｓ／＜ｓｃｌ＞／ａｐｐｌｉｃａｔｉｏｎｓ／ｍｇｍｔＯｂｊｓ／ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓの下に配置されてもよい。対応する＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞は、Ｍ２Ｍアプリケーションのグループの登録解除、およびＭ２Ｍアプリケーションのグループ上での同一のソフトウェア／ファームウェアの更新の実行、を含んでもよい。

図４３Ｂに示すように、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐＯｐｅｒａｔｉｏｎｓ ＭＯは、グループ上で実行されることになる動作または操作を表すことができる＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞などの下位リソースを含んでもよい。サブスクリプション集合および属性は、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎを含んでもよい。

図４４Ａに示すように、各＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞は、サブスクリプション集合、ならびにｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＳＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎなどの属性、を有する下位リソースを含んでもよい。＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞は、下位リソースとして、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を実行することができるグループの識別のリストとすることができるｄｅｖｉｃｅＧｒｏｕｐｓＬｉｓｔを含むｇｒｏｕｐｓと、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞の結果の集合とすることができるｅｘｅｃＲｅｓｕｌｔｓとを含んでもよく、ならびに＜ｒｅｓｕｌｔＩｎｓｔａｎｃｅ＞を含む下位リソースとそのサブスクリプションおよび属性ａｇｇｒｅｇａｔｅｄＲｅｓｕｌｔを有してもよい。

＜ｒｅｓｕｌｔＩｎｓｔａｎｃｅ＞は、単一のデバイスから結果を表してもよく、ならびに下位リソースサブスクリプションと、デバイス識別とすることができるｄｅｖｉｃｅＩＤ、ｄｅｖｉｃｅＩＤのデバイスからの結果とすることができるｒｅｓｕｌｔＶａｌｕｅ、ｄｅｖｉｃｅＩＤのデバイス上の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞のステータスとすることができるｅｘｅｃＳｔａｔｕｓ、ｄｅｖｉｃｅＩＤ上の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を開始することになるｅｘｅｃＥｎａｂｌｅ、ｄｅｖｉｃｅＩＤ上の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を中断することになるｅｘｅｃＰａｕｓｅ、ｄｅｖｉｃｅＩＤ上の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を再開することになるｅｘｅｃＲｅｓｕｍｅ、ｄｅｖｉｃｅＩＤ上の＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を停止することになるｅｘｅｃＤｉｓａｂｌｅ、集約された結果とすることができるａｇｇｒｅｇａｔｅｄＲｅｓｕｌｔ、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞により必要とされる引数を含み、および動作固有とすることができるｅｘｅｃＰａｒａｍｅｔｅｒｓを含む属性と、を含んでもよい。

さらに、ｏｐｅｒａｔｉｏｎＩＤは、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞の識別であってもよく、および＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞何をあらわすかを指定してもよい。ｇｒｏｕｐＩＤは、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を実行することができるグループの識別を提供してもよく、およびｇｒｏｕｐＩＤは、＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を複数の定義されたデバイスグループ上で実行できる場合の、複数の識別を含んでもよい。あるいは、それらの複数のグループ識別は、ｄｅｖｉｃｅＧｒｏｕｐｓＬｉｓｔリソースに含まれてもよい。ｅｘｅｃＥｎａｂｌｅは、ｇｒｏｕｐＩＤにおけるデバイス上で＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を開始してもよい。ｅｘｅｃＰａｕｓｅは、ｇｒｏｕｐＩＤにおけるデバイス上で＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を中断してもよい。ｅｘｅｃＲｅｓｕｍｅは、ｇｒｏｕｐＩＤにおけるデバイス上で＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を再開してもよい。ｅｘｅｃＤｉｓａｂｌｅは、ｇｒｏｕｐＩＤにおけるデバイス上で＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞を停止してもよい。ｅｘｅｃＳｔａｔｕｓは＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞のステータスを提供してもよい。ステータスは、保留中、実行中、停止、中断、再開、実行が成功したデバイスの数、成功して終了したデバイスの数、および／または実行が失敗したデバイスの数、を含んでもよい。

図４３Ｂに示すように、各＜ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅ＞は、ｓｕｂｓｃｒｉｐｔｉｏｎｓはサブスクリプション集合と、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＳＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎを含む属性とを有する、サブスクリプションなどの下位リソースを含んでもよい。さらに、ｇｒｏｕｐＩＤは、＜ｏｐｅｒａｔｉｏｎ＞を実行することができるグループの識別を提供してもよく、ｅｎａｂｌｅは＜ｏｐｅｒａｔｉｏｎ＞を開始するために提供されてもよく、ｄｉｓａｂｌｅは＜ｏｐｅｒａｔｉｏｎ＞を停止し、ｒｅｓｕｌｔｓは、＜ｏｐｅｒａｔｉｏｎ＞の結果の集合を含んでもよく、ａｇｇｒｅｇａｔｅｄＲｅｓｕｌｔは集約された結果を含んでもよい。各＜ｒｅｓｕｌｔＩｎｓｔａｎｃｅ＞は、デバイスの識別を示すｄｅｖｉｃｅＩＤと、ｄｅｖｉｃｅＩＤのデバイスからの結果とすることができるｒｅｓｕｌｔなどの２つの属性を有してもよい。

図４４に示すように、ｅｔｓｉＳｅｎｓｏｒｓ ＭＯは、センサインスタンスについての＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞などの下位リソースと、サブスクリプション集合を含むサブスクリプションと、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＳＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むｄｅｓｃｒｉｐｔｉｏｎなどの属性と、を含んでもよい。ｅｔｓｉＳｅｎｓｏｒｓは、Ｍ２Ｍサービス能力を有するＤタイプのＭ２Ｍデバイスに適用可能であってもよい。

図４５に示すように、＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞は、関連するグループを有するｇｒｏｕｐｓなどの下位リソースを含んでもよい。例えば、１つのｇｒｏｕｐｓは、＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞を使用するデバイス上のＤ’Ａ、またはＤＡアプリケーションを表すａｐｐｌｉｃａｔｉｏｎＬｉｓｔであってもよい。Ｃｏｎｔａｉｎｅｒｓは、センサの測定値を格納してもよい。サブスクリプション集合および属性は、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、ＦＳＳ形式とすることができるｃｏｎｔｅｎｔＴｙｐｅ、ｍｏＩＤ、ｏｒｉｇｉｎａｌＭＯ、およびｍｇｍｔＯｂｊのテキスト形式の詳細を含むことができるｄｅｓｃｒｉｐｔｉｏｎを含んでもよい。ｓｅｎｓｏｒＩＤは＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞の識別を記述してもよい。ｓｅｎｓｏｒＴｙｐｅは、温度、圧力、＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞の製造者を定義した製造者、および＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞上で実行することが可能な動作を含むことができる動作などの＜ｓｅｎｓｏｒＩｎｓｔａｎｃｅ＞の種別を記述してもよい。Ｅｎａｂｌｅは、センサの読み取りを可能にすることを含んでもよい。センサがスイッチセンサの場合は、ｅｎａｂｌｅはスイッチを入れることを意味してもよい。Ｅｎａｂｌｅは、動作の結果を格納する属性としてｒｅｓｕｌｔを有してもよい。Ｄｉｓａｂｌｅは、センサの測定値を無効にすることを含んでもよい。センサがスイッチセンサの場合は、ｄｉｓａｂｌｅはスイッチを切ることを意味してもよい。Ｄｉｓａｂｌｅは、動作結果を格納する属性としてｒｅｓｕｌｔを有してもよい。他の動作は特定のセンサに対して考えられてもよい。

例示的な動作環境
図４６は、ＤＡおよび／またはＧＡにより使用される管理オブジェクトに従ってＲＥＭを実行して、Ｍ２Ｍサーバ（ここでは＜ｓｃｌ＞）に登録した別のＤ／Ｇを管理するためのシステムの例示的アーキテクチャのブロック図である。

Ｍ２Ｍサーバ（すなわち＜ｓｃｌ＞）は、４７０２に示すように、自身の管理オブジェクトをＤ／Ｇに公表することができ、そして、ＤＡ／ＧＡはＤ／Ｇにおけるそのような公表された管理オブジェクトにアクセスし、次いでＭ２Ｍサーバにおけるメッセージの中継を介して他のＤ／Ｇを管理することが可能になる。

図４８Ａは、１つまたは複数の開示される実施形態を実施することができる例示的な通信システム１００の図である。通信システム１００は、音声、データ、映像、メッセージング、放送等のコンテンツを複数の無線ユーザに提供する多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つまたは複数のチャネルアクセス方式を採用してもよい。

図４８Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびに他のネットワーク１１２を含んでもよい。ただし、開示される実施形態では、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの各々は、無線環境で動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、およびユーザデバイス（ＵＥ）、移動局、固定型または移動型の加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ機、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、および消費者電子製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂも含んでもよい。基地局１１４ａおよび１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの少なくとも１つと無線上でインタフェースをとって、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２等の１つまたは複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａおよび１１４ｂは、ベーストランシーバ局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータ等であってもよい。基地局１１４ａおよび１１４ｂはそれぞれ単一の要素として示されるが、基地局１１４ａおよび１１４ｂは任意の数の相互接続された基地局および／またはネットワーク要素を含んでよいことが理解されよう。

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノード等のほかの基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セルと呼ばれることもある特定の地理的領域（図示せず）内で無線信号を送信および／または受信するように構成されてもよい。セルはさらにセルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは３つのセクタに分割されてもよい。そのため、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタに１つを含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがってセルの各セクタに複数の送受信機を利用してもよい。

基地局１１４ａおよび１１４ｂは、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの１つまたは複数と通信してもよく、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光等）であってもよい。エアインタフェース１１６は、適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

より具体的には、上記で述べたように、通信システム１００は多元接続システムであってもよく、ならびにＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡおよびＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０４における基地局１１４ａ、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）等の無線技術を実装してもよく、当該技術は、広帯域ＣＤＭＡ（ＷＣＤＭＡ：登録商標）を使用してエアインタフェース１１６を確立してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態では、基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、発展型ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよく、当該技術は、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立してもよい。

他の実施形態では、基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、ＩＥＥＥ８０２．１６（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ ＩＸ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ：登録商標）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

図４８Ａにおける基地局１１４ｂは、例えば無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、ならびに職場、家庭、自動車、キャンパスなどの局所的な領域において無線接続を容易にするための任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、セルラベースののＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図３８Ａに示すように、基地局１１４ｂは、インターネット１１０への直接の接続を有してもよい。そのため、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスする必要がない場合もある。

ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあってもよく、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの１つまたは複数に音声、データ、アプリケーション、および／またはｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）サービスを提供するように構成された任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続、および映像配布などを提供してもよく、ならびに／またはユーザ認証などの高レベルなセキュリティ機能を実行してもよい。図３８Ａには示さないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接的な通信状態にあってもよく、または間接的な通信状態にあってもよいことが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１０４に接続されるのに加えて、コアネットワーク１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信状態にあってもよい。

コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄがＰＳＴＮ１０８、インターネット１１０および／または他のネットワーク１１２にアクセスするためのゲートウェイとしてサービスを提供してもよい。ＰＳＴＮ１０８は、従来の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダにより所有および／または運営される有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用することができる１つまたは複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの一部またはすべては、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図３８Ａに示すＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用することができる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図４８Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図４８Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機能１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上述の要素のサブコンビネーションを含んでよいことが理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１１８は、シグナルコーディング、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境で動作することを可能にする他の機能を実行してもよい。プロセッサ１１８は送受信機１２０に結合されてもよく、送受信機１２０は送信／受信要素１２２に結合されてもよい。図４８Ｂはプロセッサ１１８および送受信機１２０を別個の構成要素として示すが、プロセッサ１１８および送受信機は電子パッケージや電子チップに共に統合されてもよいことが理解されよう。

送信／受信要素１２２は、エアインタフェース１１６上で基地局（例えば基地局１１４ａ）に信号を送信し、または当該基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、送信／受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信および受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。

加えて、図４８Ｂでは送信／受信要素１２２を１つの要素として示されるが、ＷＴＲＵ１０２は任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を採用してもよい。そのため、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上で無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含んでもよい。

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

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６および／またはディスプレイ／タッチパッド１２８（例えば液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、ならびにそれらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの任意タイプの適切なメモリからの情報にアクセスしてもよく、ならびにそれらにデータを記憶してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態では、プロセッサ１１８は、サーバまたは家庭用コンピュータ（図示せず）などの、ＷＴＲＵ１０２に物理的に位置しないメモリからの情報にアクセスし、および当該メモリデータを記憶してもよい。

プロセッサ１１８は、電源１３４から電力を受け取り、その電力をＷＴＲＵ１０２中の他の構成要素に分配および／または制御するように構成することができる。電源１３４は、ＷＴＲＵ１０２に電力を供給するのに適した任意の装置でよい。例えば、電源１３４は、１つまたは複数の乾電池（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含むことができる。

プロセッサ１１８はまた、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、あるいはその代わりに、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上で位置情報を受信し、および／または、２つ以上の近隣の基地局から信号が受信されることになるタイミングに基づいて自身の位置を判定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切な位置判定方法により位置情報を取得してよいことが理解されよう。

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

図４８Ｃは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上記のように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を採用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０６と通信状態にあってもよい。図４８Ｃに示すように、ＲＡＮ１０４は、ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを含んでもよく、それらの各々は、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。ＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃはそれぞれ、ＲＡＮ１０４内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０４はまた、ＲＮＣ１４２ａおよび１４２ｂを含んでもよい。ＲＡＮ１０４は実施形態との整合性を保ちながら、任意の数のＮｏｄｅＢおよびＲＮＣを含んでもよいことが理解されよう。

図４８Ｃに示すように、ＮｏｄｅＢ１４０ａおよび１４０ｂは、ＲＮＣ１４２ａと通信状態にあってもよい。加えて、ＮｏｄｅＢ１４０ｃは、ＲＮＣ１４２ｂと通信状態にあってもよい。ＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、Ｉｕｂインタフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａおよび１４２ｂは、Ｉｕｒインタフェースを介して相互に通信してもよい。ＲＮＣ１４２ａおよび１４２ｂの各々は、それらが接続されたＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃを制御するように構成されてもよい。また、ＲＮＣ１４２ａおよび１４２ｂの各々は、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化などの他の機能を実行またはサポートするように構成されてもよい。

図４８Ｃに示すコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンター（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。上記の各要素はコアネットワーク１０６の一部として記述されるが、これらの要素の任意の１つはコアネットワークオペレータ以外のエンティティにより所有および／または運営されてもよいことが理解されよう。

ＲＡＮ１０４におけるＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介してコアネットワーク１０６におけるＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６はＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、ＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと従来の陸線通信デバイスとの間の通信を容易にしてもよい。

ＲＡＮ１０４におけるＲＮＣ１４２ａはまた、ＩｕＰＳインタフェースを介してコアネットワーク１０６におけるＳＧＳＮ１４８に接続されてもよい。ＳＧＳＮ１４８はＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、インターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとＩＰ使用可能デバイスとの間の通信を容易にしてもよい。

上述したように、コアネットワーク１０６はまたネットワーク１１２にも接続されてもよく、ネットワーク１１２は、他のサービスプロバイダにより所有および／または運営される有線または無線のネットワークを含んでもよい。

図４８Ｄは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０６と通信状態にあってもよい。

ＲＡＮ１０４は、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃを含んでもよいが、ＲＡＮ１０４は実施形態との整合性を保ちながら任意の数のｅＮｏｄｅＢを含んでもよいことが理解されよう。ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは各々、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。一実施形態では、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃはＭＩＭＯ技術を実装してもよい。したがって、例えばｅＮｏｄｅＢ１４０ａは、複数のアンテナを使用してＷＴＲＵ１０２ａに無線信号を送信し、およびＷＴＲＵ１０２ａから無線信号を受信してもよい。

ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃの各々は、特定のセル（図示せず）に関連付けられてもよく、ならびに無線リソース管理決定、ハンドオーバー決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリング等を処理するように構成されてもよい。図４８Ｄに示すように、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、Ｘ２インタフェース上で相互に通信してもよい。

図４８Ｄに示すコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでもよい。上述した要素の各々はコアネットワーク１０６の一部として示されるが、それらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことが理解されよう。

ＭＭＥ１４２は、Ｓ１インタフェースを介してＲＡＮ１０４におけるｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃの各々に接続されてもよく、ならびに制御ノードとしての役割を果たしてもよい。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃの初期アタッチ中の特定サービングゲートウェイの選択等を担ってもよい。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）とを切り替えるための制御プレーン機能も提供してもよい。

サービングゲートウェイ１４４は、Ｓ１インタフェースを介してＲＡＮ１０４におけるｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃの各々に接続されてもよい。サービングゲートウェイ１４４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃにユーザデータパケットを送信してもよく、ならびにそれらからのユーザデータパケットを転送してもよい。サービングゲートウェイ１４４はまた、ｅＮｏｄｅＢ間のハンドオーバー中のユーザプレーンアンカリング、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに利用可能なときのページングのトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのコンテキストを管理および記憶するなどの他の機能を実行してもよい。

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６に接続されてもよく、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとＩＰ使用可能デバイスとの間の通信を容易にしてもよい。

コアネットワーク１０６は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと従来の陸線通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を担うＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、または当該ゲートウェイと通信してもよい。加えて、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃにネットワーク１１２へのアクセスを提供してもよく、ネットワーク１１２は、他のサービスプロバイダにより所有および／または運営される他の有線または無線ネットワークを含んでもよい。

図４８Ｅは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ８０２．１６無線技術を使用してエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。下記でさらに述べるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよびＲＡＮ１０４、ならびにコアネットワーク１０６の異なる機能エンティティ間の通信リンクは、基準点として定義されてもよい。

図４８Ｅに示すように、ＲＡＮ１０４は、基地局１４０ａ、１４０ｂおよび１４０ｃ、ならびにＡＳＮゲートウェイ１４２を含んでもよいが、ＲＡＮ１０４は、実施形態との整合性を保ちながら任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことが理解されよう。基地局１４０ａ、１４０ｂおよび１４０ｃはそれぞれＲＡＮ１０４における特定のセル（図示せず）に関連付けられてもよく、ならびにそれぞれエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。一実施形態では、基地局１４０ａ、１４０ｂおよび１４０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、例えば基地局１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、およびＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１４０ａ、１４０ｂおよび１４０ｃはまた、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシー施行などのモビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１４２は、トラフィック集約点としての役割を果たしてもよく、ならびにページング、加入者プロファイルのキャッシュ、およびコアネットワーク１０６へのルーティングなどを担ってもよい。

ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとＲＡＮ１０４との間のエアインタフェース１１６は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義されてもよい。加えて、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃの各々は、コアネットワーク１０６との論理インタフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとコアネットワーク１０６との間の論理インタフェースはＲ２基準点として定義されてもよく、認証、権限付与、ＩＰホスティング構成管理、および／またはモビリティ管理に使用されてもよい。

基地局１４０ａ、１４０ｂおよび１４０ｃの各々の間の通信リンクは、基地局間のＷＴＲＵのハンドオーバーおよびデータの転送を容易にするプロトコルを含む、Ｒ８基準点として定義されてもよい。基地局１４０ａ、１４０ｂおよび１４０ｃとＡＳＮゲートウェイ２１５との間の通信リンクは、Ｒ６基準点として定義されてもよい。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃの各々に関連付けられたモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含んでもよい。

図４８Ｅに示すように、ＲＡＮ１０４は、コアネットワーク１０６に接続されてもよい。ＲＡＮ１０４とコアネットワーク１０６との間の通信リンクは、例えばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含む、Ｒ３基準点として定義されてもよい。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１４４、認証・認可・課金管理（ＡＡＡ）サーバ１４６、およびゲートウェイ１４８を含んでもよい。上述した要素の各々は、コアネットワーク１０６の一部として記述されるが、これらの要素のいずれか１つはコアネットワークオペレータ以外のエンティティにより所有および／または運営されてもよいことが理解されよう。

ＭＩＰ−ＨＡは、ＩＰアドレスの管理を担ってもよく、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃが異なるＡＳＮ間および／または異なるコアネットワーク間をローミングすることを可能にさせてもよい。ＭＩＰ−ＨＡ１４４は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと、ＩＰ使用可能デバイスとの間の通信を容易にしてもよい。ＡＡＡサーバ１４６は、ユーザ認証およびユーザサービスをサポートすることを担ってもよい。ゲートウェイ１４８は、他のネットワークとの相互動作を容易にしてもよい。例えば、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと、従来の陸線通信デバイスとの間の通信を容易にしてもよい。加えて、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができるネットワーク１１２へのアクセスを提供してもよい。

図４８Ｅには示さないが、ＲＡＮ１０４は他のＡＳＮに接続されてもよく、およびコアネットワーク１０６は他のコアネットワークに接続されてもよいことが理解されよう。ＲＡＮ１０４と他のＡＳＮとの間の通信リンクは、Ｒ４基準点として定義されてもよく、Ｒ４基準点は、ＲＡＮ１０４と他のＡＳＮとの間でのＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのモビリティを調整するプロトコルを含んでもよい。コアネットワーク１０６と他のコアネットワークとの間の通信リンクは、Ｒ５基準点として定義されてもよく、Ｒ５基準点は、ホームコアネットワークと移動先（visited）コアネットワークとの間の相互動作を容易にするためのプロトコルを含んでもよい。

上記では特定の組み合わせで特徴および要素について説明したが、当業者の１人は、各特徴または要素は単独で、または他の特徴および要素との任意の組み合わせで使用することができることを認識されよう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続上で伝送される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、これらに限定されないが、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。ソフトウェアと関連付けられたプロセッサが使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波送受信機を実装してもよい。

結論
ＥＴＳＩ ＴＳ １０２ ６９０ Ｖ０．１２．３（２０１１−０６）ドラフトおよび同標準の先行版（総称して「Ｍ２Ｍ通信に対するＥＴＳＩ標準ドラフト」）は、Ｍ２Ｍ通信のためのＥＴＳＩ標準ドラフトのコンテキスト内のかかる用語の意味を定義する、所定の定義を有するいくつかの用語を含む。本明細書には、ＥＴＳＩ ＴＳ １０２ ６９０ Ｖ０．１２．３（２０１１−０６）ドラフトおよび同標準の先行版により指定、開示、および／または参照される用語およびそれに関連する定義が、参照により組み込まれる。

実施形態
一実施形態では、方法は、Ｍ２Ｍ環境においてＭ２Ｍエンティティを管理するための１つまたは複数の管理レイヤを実装することを含んでもよい。方法はまた、複数の管理レイヤを使用して、Ｍ２Ｍエリアネットワークを管理することも含んでもよく、Ｍ２Ｍエリアネットワークは１つまたは複数のＭ２Ｍエンドデバイスを含んでもよい。Ｍ２Ｍエンドデバイスは、例えばＭ２Ｍゲートウェイおよび／またはＭ２Ｍデバイスを含んでもよい。管理レイヤは、アプリケーション管理レイヤ、サービス管理レイヤ、ネットワーク管理レイヤ、およびデバイス管理レイヤのいずれかを含んでもよい。管理レイヤは、Ｍ２Ｍエンティティの構成管理、障害管理、および性能管理のいずれかを提供してもよい。

一実施形態では、方法は、リモートエンティティ管理（「ＲＥＭ」）のためのサービス能力（「ＳＣ」）と、複数の管理レイヤのうちの１つに従って第２のＭ２ＭエンティティのＲＥＭを実行するための下位リソース構造を有するリソース構造とによって、第１のＭ２Ｍエンティティを構成することを含んでもよい。方法はさらに、下位リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを実行することを含んでもよい。

上記実施形態における方法であり、第１のＭ２ＭエンティティはＭ２Ｍサーバであってもよく、第２のＭ２Ｍエンティティは、Ｍ２Ｍアプリケーション、Ｍ２Ｍサービス能力、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイスであってもよい。

上記実施形態の少なくとも１つにおける方法であり、複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤのうちの少なくとも２つを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、アプリケーション管理レイヤに従ったＭ２Ｍアプリケーションのリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態における方法であり、アプリケーション管理レイヤは、アプリケーションのライフサイクル管理を実行するための１つまたは複数の機能を含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、サービス管理レイヤに従ったＭ２Ｍサービス能力のリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態における方法であり、サービス管理は、ソフトウェア管理および／またはファームウェア管理を実行するための機能を備える。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、ネットワーク管理レイヤに従ったＭ２Ｍエリアネットワークのリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、デバイス管理レイヤに従ったＭ２Ｍデバイスのリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、複数の管理レイヤの各々は、第２のＭ２Ｍエンティティの構成管理、障害管理、および性能管理のいずれかを実行するための１つまたは複数の機能を定義してもよい。

上記実施形態の少なくとも１つにおける方法は、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを、第１のＭ２Ｍエンティティにおいて受信することをさらに含んでもよく、第２のＭ２ＭエンティティのＲＥＭは、前記コマンドに応答して実行されてもよい。

上記実施形態における方法であり、前記コマンドはＲＥＳＴｆｕｌメソッドを備える。

上記実施形態の少なくとも１つにおける方法は、下位リソース構造のリソースおよび属性のいずれかを操作する第１のコマンドを、第１のＭ２Ｍエンティティにおいて受信することをさらに含んでもよい。

上記実施形態における方法であり、第２のＭ２ＭエンティティのＲＥＭを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作する第２のコマンドを第２のＭ２Ｍエンティティに送信することと、受信された第２のコマンドに応答して第２のＭ２ＭエンティティのＲＥＭを実行することとを含んでもよい。

上記実施形態における方法であり、第１のコマンドおよび第２のコマンドの両方は、ＲＥＳＴｆｕｌメソッドを含んでもよい。

上実施形態の少なくとも１つにおける方法であり、第１のコマンドはＲＥＳＴｆｕｌメソッドを含んでもよく、および第２のコマンドは非ＲＥＳＴｆｕｌメソッドを備える。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２ＭエンティティのＲＥＭを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを、第２のＭ２Ｍエンティティに送信することと、受信されたコマンドに応答して第２のＭ２ＭエンティティのＲＥＭを実行することとを含んでもよい。

上記実施形態における方法であり、コマンドは非ＲＥＳＴｆｕｌメソッドまたはＲＥＳＴｆｕｌメソッドのいずれかであってもよい。

上記実施形態の少なくとも１つにおける方法であり、第２のＭ２Ｍエンティティは、下位リソース構造の複製を含んでもよく、および第２のＭ２ＭエンティティのＲＥＭを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作した後に、下位リソース構造の複製を操作して下位リソース構造を複製することを備える。

一実施形態では、装置は、ＲＥＭのためのＳＣと、複数の管理レイヤのうちの１つに従って第２のＭ２ＭエンティティのＲＥＭを実行するための下位リソース構造を有するリソース構造とによって構成された第１のＭ２Ｍエンティティを含んでもよい。装置はさらに、下位リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを実行するように適合されたプロセッサを含んでもよい。

上記実施形態における装置であり、第１のＭ２ＭエンティティはＭ２Ｍサーバを含んでもよく、および第２のＭ２Ｍエンティティは、Ｍ２Ｍアプリケーション、Ｍ２Ｍサービス能力、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイスを含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤのうちの２つ以上を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、第２のＭ２ＭエンティティのＲＥＭのための下位リソース構造は、アプリケーション管理レイヤに従ったＭ２ＭアプリケーションのＲＥＭのためのリソース構造を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、アプリケーション管理レイヤは、アプリケーションのライフサイクル管理を実行するための機能を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、サービス管理レイヤに従ったＭ２Ｍサービス能力のリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態における装置であり、サービス管理は、ソフトウェア管理および／またはファームウェア管理を実行するための機能を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、ネットワーク管理レイヤに従ったＭ２Ｍエリアネットワークのリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、第２のＭ２Ｍエンティティのリモートエンティティ管理のための下位リソース構造は、デバイス管理レイヤに従ったＭ２Ｍデバイスのリモートエンティティ管理のためのリソース構造を含んでもよい。

上記実施形態の少なくとも１つにおける装置であり、複数の管理レイヤの各々は、第２のＭ２Ｍエンティティの構成管理、障害管理、および性能管理のいずれかを実行するための機能を定義してもよい。

上記実施形態の少なくとも１つにおける装置であり、第１のＭ２Ｍエンティティは、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを受信するＳＣを含んでもよく、第２のＭ２ＭエンティティのＲＥＭは、コマンドに応答して実行されてもよい。

上記実施形態の少なくとも１つにおける装置であり、コマンドはＲＥＳＴｆｕｌメソッドであってもよい。

上記実施形態の少なくとも１つにおける装置であり、第１のＭ２Ｍエンティティは、（ｉ）下部リソース構造のリソースおよび属性のいずれかを操作する第１のコマンドを受信するＳＣ、および（ｉｉ）第２のＭ２Ｍエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作する第２のコマンドを、第２のＭ２Ｍエンティティと通信するＳＣ、を含んでもよい。

上記実施形態における装置であり、プロセッサは、第２のコマンドに応答して、第２のＭ２Ｍエンティティで保持された下部リソース構造のリソースの複製および属性の複製のいずれかを操作させる第２のコマンドを、第２のＭ２Ｍエンティティに送信するように適合されてもよい。

上記実施形態の少なくとも１つにおける装置であり、第１のコマンドおよび第２のコマンドの両方はＲＥＳＴｆｕｌメソッドであってもよく、または代わりに、第１のコマンドはＲＥＳＴｆｕｌメソッドであってもよく、ならびに第２のコマンドは非ＲＥＳＴｆｕｌメソッドであってもよい。

上記実施形態の少なくとも１つにおける装置であり、第１のＭ２Ｍエンティティは、（ｉ）第２のＭ２Ｍエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作するコマンドを、第２のＭ２Ｍエンティティと通信するＳＣを含んでもよい。

前記実施形態における装置であり、プロセッサは、第２のコマンドに応答して、第２のＭ２Ｍエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作させるコマンドを、第２のＭ２Ｍエンティティに送信するように適合されてもよい。

上記実施形態における装置であり、コマンドは非ＲＥＳＴｆｕｌメソッドであってもよく、または代わりにＲＥＳＴｆｕｌメソッドであってもよい。

一実施形態では、システムは、ＲＥＭのためのサービス能力と、複数の管理レイヤの１つに従って第２のＭ２ＭエンティティのＲＥＭを実行するための下位リソース構造を有するリソース構造とによって構成された第１のＭ２Ｍエンティティを有するサーバを含んでもよい。システムはまた、下位リソース構造のリソースおよび属性のいずれかを操作することによって、第２のＭ２ＭエンティティのＲＥＭを実行するように適合されたプロセッサを含んでもよい。システムはさらに、下位リソース構造の複製により構成された第２のＭ２Ｍエンティティと、サーバによる操作の後に下位リソース構造の複製を操作して下位リソース構造を複製するように構成されたプロセッサとを有するデバイスを含んでもよい。

一実施形態では、有形のコンピュータ可読記憶媒体は、（ｉ）ＲＥＭのためのＳＣと、複数の管理レイヤのうちの１つに従って第２のＭ２ＭエンティティのＲＥＭを実行するための下位リソース構造を有するリソース構造とによって、第１のＭ２Ｍエンティティを構成し、ならびに（ｉｉ）下位リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを実行するための実行可能命令を記憶してもよい。実行可能命令は、メモリにロード可能であってもよく、およびコンピューティングデバイスにより実行可能であってもよい。

一実施形態では、有形のコンピュータ可読記憶媒体は、（ｉ）ＲＥＭのためのＳＣと、複数の管理レイヤのうちの１つに従って第２のＭ２ＭエンティティのＲＥＭを実行するための下位リソース構造を有するリソース構造とによって、第１のＭ２Ｍエンティティを構成し、（ｉｉ）下位リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを実行し、ならびに（ｉｉｉ）第２のＭ２Ｍエンティティによって保持された下位リソース構造の複製を操作して、それにより下位リソース構造のリソースおよび属性のいずれかの操作後に、下部リソース構造を複製するための実行可能命令を記憶してもよい。

一実施形態では、方法は、Ｍ２Ｍ環境において管理機能を実行するためのクライアント／サーバベースのリモートエンティティ管理（ｘＲＥＭ）のモデルを実装することを含んでもよい。方法はまた、当該モデルをＭ２Ｍ環境におけるＭ２Ｍデバイスに適用することを含んでもよい。

一実施形態では、方法は、トンネルベースの技術を使用して、複数の管理プロトコルを使用してＭ２Ｍ環境におけるｘＲＥＭを実装することと、当該モデルをＭ２Ｍ環境におけるＭ２Ｍデバイスに適用することを含んでもよい。

一実施形態では、方法は、属性コンポーネントを備えるリソースコマンドを提供することと、リソースコマンドをＭ２Ｍエンドデバイスと通信することとを含んでもよい。

上記実施形態における方法であり、リソースコマンドは非ＲＥＳＴｆｕｌコマンドであってもよい。

一実施形態では、方法は、属性コンポーネントおよび考えられるいくつかのサブパラメータを有するリソースコマンド構造を提供することを含んでもよい。方法はまた、リソースコマンドをＭ２Ｍエンドデバイスに通信することを含んでもよい。従来の非ＲＥＳＴｆｕｌ管理コマンドは、ＲＥＳＴｆｕｌメソッドを使用してＭ２Ｍエンドデバイス上で容易に動作される場合がある。

一実施形態では、方法は、ａｃｃｅｓｓＨｉｓｔｏｒｉｅｓリソース構造をＭ２ＭデバイスまたはＭ２Ｍゲートウェイにおいて記憶し、Ｍ２ＭデバイスまたはＭ２Ｍゲートウェイにおける動作を検出し、およびａｃｃｅｓｓＨｉｓｔｏｒｉｅｓリソース構造を操作して、その動作に関連付けられた少なくとも１つの詳細を記憶することを含んでもよい。

一実施形態では、方法は、マシンツーマシン（Ｍ２Ｍ）デバイスまたはゲートウェイ上で権限を委譲する要求を受信し、およびＭ２Ｍデバイスまたはゲートウェイ上で権限を付与することを含んでもよい。

一実施形態では、方法はＭ２Ｍエンドデバイスにおいて実施されてもよい。方法は、Ｍ２Ｍエンドデバイスを管理するための１つまたは複数の属性コンポーネントを有するリソースコマンドを受信することを含んでもよい。

上記実施形態における方法はまた、リソースコマンドに基づいて１つまたは複数の管理機能を適用することを含んでもよい。

一実施形態では、方法は、１つまたは複数の属性コンポーネントを含むリソースコマンドを提供し、およびリソースコマンドをＭ２Ｍエンドデバイスに通信することを含んでもよい。

一実施形態では、第１のシステムにおいてｘＲＥＭを実行する方法は、例えば、ＥＴＳＩ ＴＳ １０２ ６９０ドラフトなどのＭ２Ｍ通信用のプロトコル（「Ｍ２Ｍ通信プロトコル」）に従って通信するように適合された第１、第２および第３のデバイスを含んでもよい。Ｍ２Ｍ通信プロトコルは、論理レイヤ（「管理レイヤ」）の各々に存在するエンティティを管理するための論理レイヤのスタックまたは集合を定義してもよい。これらの管理レイヤは、例えば、Ｍ２Ｍアプリケーション管理レイヤ、Ｍ２Ｍサービス能力レイヤ、Ｍ２Ｍネットワーク管理レイヤ、およびＭ２Ｍデバイス管理レイヤを含んでもよい。第１のデバイスは、管理レイヤのうち第１の論理レイヤ（「第１の管理レイヤ」）に存在するエンティティを定義してもよい。エンティティは、例えばＭ２Ｍアプリケーション、Ｍ２Ｍサービス能力、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイスであってもよい。第１のデバイスは、第１の管理レイヤに従ってエンティティを管理するためのリソース（「第１の管理レイヤリソース」）を定義する第１のデータ構造を含んでもよい。第２のデバイスも、第１の管理レイヤリソースを定義する第２のデータ構造を含んでもよい。そして第２のデバイスは、第１および第３のデバイスと通信可能に結合してもよい。

方法は、第２のデバイスから第３のデバイスに、第１の管理レイヤリソースを識別する識別子を提供することを含んでもよい。方法はまた、識別子および第１の管理レイヤリソースに適用する情報を第２のデバイスにおいて第３のデバイスから受信し、および情報を第１の管理レイヤリソースに適用することを含んでもよい。

１つまたは複数の例では、情報を第１の管理レイヤリソースに適用することは、第２のデータ構造を操作することを含んでもよい。あるいは、情報を第１の管理レイヤリソースに適用することは、第２のデバイスから第１のデバイスに情報を送信して、第１のデバイスに第１のデータ構造を操作させることを含んでもよい。

識別子は、例えばユニフォームリソース識別子（uniform resource identifier）、リンク、およびアドレスのいずれかを含んでもよく、ならｂに／またはそれらのいずれかであってもよい。第１の管理レイヤリソースは、管理オブジェクトを含んでもよく、および／または定義してもよい。さらに、第１、第２および第３のデバイスの各々は、Ｍ２Ｍ通信プロトコルに従って通信するモジュールを含んでもよい。第３のデバイスはさらに、第１の管理レイヤリソースに適用する情報を提供するように適合されたアプリケーション、例えばＭ２Ｍアプリケーションを含んでもよく、およびアプリケーションの実行は、Ｍ２Ｍ通信プロトコルに従って情報を通信することを含む。第１のデバイスはまた、アプリケーションを含んでもよく、およびそのようなアプリケーションの実行は、Ｍ２Ｍ通信プロトコルに従って情報を通信することを含む。

１つまたは複数の実施形態において、第１のデバイスは電気器具であってもよく、第３のデバイスは、無線送信／受信ユニット（「ＷＴＲＵ」）であってもよく、および第２のデバイスはサーバを含んでもよい。

別の例として、ｘＲＥＭのための装置が開示される。装置は、Ｍ２Ｍ通信プロトコルに従って通信するように適合された第１のデバイスを含む。上記のように、Ｍ２Ｍ通信プロトコルは、管理レイヤのスタックまたは集合を定義する。第１のデバイスは、第１のデータ構造を含んでもよい。第１のデータ構造は、第１の管理レイヤに従って、第１の管理レイヤに存在する第２のデバイスのエンティティを管理するための第１の管理レイヤリソースを定義する。第１のデバイスはまた、第２のデバイスおよび第３のデバイスと通信可能に結合してもよい。第１のデバイスはさらに、実行可能命令を記憶するように適合されたメモリを含んでもよく、実行可能命令は、第１の管理レイヤリソースを識別する識別子を第３のデバイスに提供し、識別子および第１の管理レイヤリソースに適用する情報を第３のデバイスから受信し、ならびに情報を第１の管理レイヤリソースに適用する、ように適合される。第１のデバイスはまた、メモリから実行可能命令を取得し、および実行可能命令を実行するように適合されたプロセッサも含んでもよい。

識別子は、ユニフォームリソース識別子、リンク、およびアドレスのいずれかを含んでもよく、かつ／またはそれらのいずれかであってもよい。第１の管理レイヤリソースは管理オブジェクトを含んでもよい。

第１のデバイスは、Ｍ２Ｍ通信プロトコルに従って通信するモジュールを含んでもよい。第１の管理レイヤリソースに適用する情報は、第３のデバイスのアプリケーションから受信されてもよい。第１のデバイスは、サーバを含んでもよく、第２のデバイスは電気器具であってもよく、および第３のデバイスはＷＴＲＵであってもよい。

第２のシステムにおいてｘＲＥＭを実行するための方法の別の例が開示される。第２のシステムは、Ｍ２Ｍ通信プロトコルに従って通信するように適合された第１および第２のデバイスを含んでもよい。Ｍ２Ｍ通信プロトコルは管理レイヤを定義する。第１のデバイスは、第１の管理レイヤに存在するエンティティを定義し、および第１の管理レイヤリソースを定義する第１のデータ構造を備える。第２のデバイスも、第１の管理レイヤリソースを定義する第２のデータ構造を含む。第１のデバイスは第２のデバイスに通信可能に結合してもよい。

方法は、第１のデバイスが第２のデバイスとネゴシエーションして、第１の管理レイヤに従ってエンティティを管理するための管理プロトコルのタイプを定義することを含んでもよい。第２のデバイスとのネゴシエーションは、例えば、第２のデバイスにおけるサービス能力レイヤ（「ＳＣＬ」）の登録を要求する第１のメッセージを、第１のデバイスから第２のデバイスに送信することを含んでもよく、第１のメッセージは、管理プロトコルのタイプを定義する属性と、属性に割り当てられた第１の値とを含む。第２のデバイスとのネゴシエーションはまた、第１のメッセージに応答して送信された第２のメッセージを、第１のデバイスにおいて第２のデバイスから受信することを含んでもよい。第２のメッセージは、管理プロトコルのタイプを定義する属性に割り当てられた第２の値を含んでもよい。

１つまたは複数の実施形態において、第２のデバイスとのネゴシエーションは、ＳＣＬの登録への更新を要求する第３のメッセージを、第１のデバイスにおいて第２のデバイスから受信することをさらに含んでもよく、第３のメッセージは、管理プロトコルのタイプを定義する属性に割り当てられた第２の値を含む。

代替として、第２のデバイスとのネゴシエーションは、第２のデバイスにおけるＳＣＬにオブジェクトを作成することを要求する第１のメッセージを、第１のデバイスから第２のデバイスに送信することを含んでもよい。このことを容易にするために、第１のメッセージは、管理プロトコルのタイプを定義する属性およびその属性に割り当てられた第１の値を含んでもよい。第２のデバイスとのネゴシエーションはさらに、第１のメッセージに応答して送信された第２のメッセージを、第１のデバイスにおいて第２のデバイスから受信することを含んでもよい。第２のメッセージは、属性に割り当てられた第２の値を含んでもよい。

別の代替として、第２のデバイスとのネゴシエーションは、第２のデバイスにおけるＳＣＬのオブジェクトを更新することを要求する第１のメッセージを、第１のデバイスから第２のデバイスに送信することを含んでもよい。第１のメッセージは、管理プロトコルのタイプを定義する属性を識別するための識別子および属性に割り当てられた第１の値を含んでもよい。第２のデバイスとのネゴシエーションはまた、第１のメッセージに応答して送信された第２のメッセージを、第１のデバイスにおいて第２のデバイスから受信することを含んでもよい。第２のメッセージは、属性に割り当てられた第２の値を含んでもよい。

さらなる別の代替では、第２のデバイスとのネゴシエーションは、第２のデバイスにおいてＳＣＬでオブジェクトを更新することを要求する第１のメッセージを、第１のデバイスにおいて第２のデバイスから受信することを含んでもよい。更新を容易にするために、第１のメッセージは、管理プロトコルのタイプを定義する属性を識別する識別子および当該属性に割り当てられた第１の値を含んでもよい。第２のデバイスとのネゴシエーションは、第１のメッセージに応答して第１のデバイスから第２のデバイスに第２のメッセージを送信することを含んでもよい。第２のメッセージは、属性に割り当てられた第２の値を含んでもよい。

別の代替では、第２のデバイスとのネゴシエーションは、第２のデバイスを検出するための第１のメッセージを、第１のデバイスから第３のデバイスに送信することを含んでもよい。第１のメッセージは、管理プロトコルのタイプを定義する属性を識別するための識別子および当該属性に割り当てられた第１の値を含んでもよい。第２のデバイスとのネゴシエーションは、第１のメッセージに応答して送信された第２のメッセージを、第１のデバイスにおいて第３のデバイスから受信することを含んでもよい。この第２のメッセージは、プロトコルのタイプを定義する属性に割り当てられた第２の値を含んでもよい。属性に割り当てられた第２の値は、第２のデバイスにおけるＳＣＬから取得されてもよい。第２のデバイスとのネゴシエーションは、第１の値と第２の値が等しい場合に、第１のデバイスのＳＣＬの登録のために第２のデバイスを選択することをさらに含んでもよい。

管理プロトコルのタイプは、シンプルネットワーク管理プロトコル（「ＳＮＭＰ」）、ブロードバンドフォーラム（「ＢＢＦ」）ＴＲ−０６９ ＣＰＥ ＷＡＮ管理プロトコル、およびオープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルのいずれかであってもよい。

第２のシステムにおいてｘＲＥＭを実行するための方法のさらなる例が開示される。方法は、第１の論理レイヤに従ってエンティティを管理するための管理プロトコルのタイプを、第２のデバイスに通知することを含んでもよい。

ｘＲＥＭを実行するための方法の別の例が開示される。方法は、第３のデバイスのｘＲＥＭについての権限を第１のデバイスに委譲する要求を、第１のデバイスが第２のデバイスから受信することと、当該要求に応答して、第２のデバイスが権限を第１のデバイスに渡すことを含んでもよい。権限を取得した後に、第１のデバイスは第３のデバイスに対する権限を実行してもよい。

１つまたは複数の実施形態において、方法は、ＲＥＳＴｆｕｌメソッドを実行する要求を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第１のエンティティは、コマンドを定義するリソース（「コマンドリソース」）のデータ構造を含んでもよい。要求は、コマンドリソースを識別するための識別子と、コマンドを実行するための情報とを含んでもよい。方法はまた、識別子およびコマンドを実行するための情報に応じてコマンドを実行することを含んでもよい。識別子は、ユニフォームリソース識別子、リンク、およびアドレスのいずれかであってもよい。

１つまたは複数の実施形態において、第１のエンティティは、第１および第２のコマンドリソースのそれぞれ第１および第２のデータ構造を含んでもよく、ならびに識別子は、第２のリソースに対するポインタを含んでもよく、および／またはポインタであってもよい。

１つまたは複数の実施形態において、方法は、ＲＥＳＴｆｕｌメソッドを実行する要求を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第１のエンティティは、コマンドを定義するコマンドリソースのデータ構造を含んでもよい。要求は、コマンドリソースを識別するための識別子と、コマンドを実行するための情報とを含んでもよい。方法はまた、要求に応答してリソースの第１のインスタンスを生成し、リソースの第１のインスタンスを識別する識別子を更新し、ならびに識別子およびコマンドを実行するための情報に応じてコマンドを実行することを含んでもよい。

１つまたは複数の実施形態において、方法は、ＲＥＳＴｆｕｌメソッドを実行するための第１の要求を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第１のエンティティは、コマンドリソースのデータ構造を含んでもよく、第１の要求は、コマンドリソースを識別するための第１の識別子、およびコマンドを実行するための第１の情報を含んでもよい。方法はまた、第１の要求に応答して、コマンドリソースの第１のインスタンスを生成し、コマンドリソースの第１のインスタンスを識別する第１の識別子を更新し、ならびにＲＥＳＴｆｕｌメソッドを実行するための第２の要求を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第２の要求は、コマンドリソースを識別するための第２の識別子と、コマンドを実行するための第２の情報とを含んでもよい。方法はさらに、第２の要求に応答して、コマンドリソースの第２のインスタンスを生成し、コマンドリソースの第２のインスタンスを識別する第２の識別子を更新し、第１の識別子およびコマンドを実行するための第１の情報に応じてコマンドを実行し、ならびに第２の識別子およびコマンドを実行するための第２の情報に応じてコマンドを実行することを含んでもよい。

一実施形態では、マシンツーマシン通信についてのプロトコルに従ってｘＲＥＭを実行するための方法が開示される。方法は、ＲＥＳＴｆｕｌメソッドを実行するための要求（「ＲＥＳＴｆｕｌメソッド要求」）を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第１のエンティティは、そのＲＥＳＴｆｕｌメソッドにより変更することが可能なデータ構造を含んでもよい。このデータ構造は、例えば、本明細書で「ｓｃｌｂａｓｅ」等と称される任意のデータ構造を含むサービス能力レイヤ（「ＳＣＬ」）を表すデータ構造であってもよい。ＲＥＳＴｆｕｌメソッド要求は、第１のエンティティにより実行可能なコマンド（以降「リソースコマンド」）に関連付けられたリソースを識別してもよい。方法はまた、ＲＥＳＴｆｕｌメソッドを実行して、リソースコマンドに従ってデータ構造への変更を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッドは、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥ、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥ、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥ、および／またはＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥであってもよい。ＲＥＳＴｆｕｌメソッドが例えばＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、リソースコマンドを表す下位データ構造（以降「コマンドリソース構造」）をデータ構造においてインスタンス化することを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、データ構造からコマンドリソース構造を削除することを含んでもよい。ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造の一部もしくはすべての複製、および／またはコマンドリソース構造の状態（「コマンドリソース状態」）を第２のエンティティに送信することを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造を変更して、コマンドの状態（「コマンド状態」）における変更を呼び出すことを含んでもよい。１つまたは複数の実施形態において、下位データ構造を変更することは、コマンドリソース構造を変更してコマンドの実行（「コマンド実行」）を呼び出すことを含んでもよい。コマンド実行は、例えばコマンドリソース構造のそのような変更を検出することに応答して第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための下位リソース（「下位リソース」）（「コマンド実行下位リソース」）を定義してもよい。このコマンド実行下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅ等と称される下位リソースの１つまたは複数の実施形態であってもよい。コマンドリソース構造の１つまたは複数の要素（「コマンドリソース構造要素」）は、コマンド実行下位リソースを表してもよい。

１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行下位リソースを変更することは、コマンド実行下位リソースを表すコマンドリソース構造要素をその情報によって変更することにより、コマンド実行を呼び出すことを含んでもよい。

コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は、割り当てられ、およびコマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は「０」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「０」によって変更することでコマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための属性を定義してもよい。それらの実施形態では、コマンドリソース構造要素は、その属性を表してもよく、およびそのような要素は、識別子（「属性識別子」）によって識別可能であってもよい。このコマンド実行属性識別子は、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅ等と称される属性の１つまたは複数の実施形態であってもよい。

ＲＥＳＴｆｕｌメソッド要求は、属性識別子を含んでもよい。さらに、属性を表すコマンドリソース構造要素の選択は、コマンド実行を呼び出してもよい。そして、コマンドリソース構造を変更してコマンドの実行を呼び出すことは、属性識別子を使用して、属性を表すコマンドリソース構造要素を選択し、それによりコマンドの実行を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更するステップは、コマンドリソース構造を変更してコマンド実行の中断を呼び出すステップを含むことができる。コマンド実行の中断は、例えば、コマンドリソース構造のそのような変更を検出するのに応答して第１のエンティティによって呼び出すことができる。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行の中断を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅ等と称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更してコマンド実行の中断を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更してコマンド実行の中断を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、中断を呼び出すことを含んでもよい。コマンド実行リソース構造を変更するための情報は、割り当られ、およびコマンド実行の中断を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して中断を呼び出すための情報は「１」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「１」により変更することによって、コマンド実行の中断を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行の中断を呼び出すための属性（「実行中断属性」）を定義してもよい。コマンド-リソース構造要素の１つまたは複数は、実行中断属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この実行中断属性は、例えば、本明細書の以下でｅｘｅｃＰａｕｓｅ等と称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、実行中断属性識別子を含んでもよい。さらに、実行中断属性を表すコマンドリソース構造要素の選択は、コマンド実行の中断を呼び出してもよい。そして、コマンドリソース構造を変更してコマンド実行の中断を呼び出すことは、実行中断属性識別子を使用して、実行中断属性を表すコマンドリソース構造要素を選択し、それによりコマンド実行の中断を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、中断中のコマンドの実行を再開させること（「再開コマンド実行」）を含んでもよい。再開コマンド実行は、例えば、再開コマンド実行をさせるためのコマンドリソース構造への変更を検出することに応答して第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅ等と称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して再開コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、再開コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および再開コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報は「２」であってもよく、したがって再開コマンド実行下位リソースを表すコマンドリソース構造要素を「２」により変更することによって、再開コマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための属性（「実行再開属性」）を定義してもよい。コマンドリソース構造要素の１つまたは複数が実行再開属性を表してもよく、およびそのような要素は対応する属性識別子によって識別可能であってもよい。この実行再開属性は、例えば、本明細書の以下でｅｘｅｃＲｅｓｕｍｅ等と称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、実行再開属性識別子を含んでもよい。さらに、実行再開属性を表すコマンドリソース構造要素の選択は、再開コマンド実行を呼び出してもよい。コマンドリソース構造を変更して再開コマンド実行を呼び出すことは、実行再開属性識別子を使用して、実行再開属性を表すコマンドリソース構造要素を選択し、それにより再開コマンド実行を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンド実行の取消し（「取消コマンド実行」）を呼び出すことを含んでもよい。取消コマンド実行は、例えば、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出するのに応答して第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して取消コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して取消コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および取消コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して、取消コマンド実行を呼び出すための情報は「３」であってもよく、したがって、取消コマンド実行下位リソースを表すコマンドリソース構造要素を「３」により変更することによって、取消コマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための属性（「取消実行属性」）を定義してもよい。コマンドリソース構造要素の１つまたは複数は、取消実行属性を表してもよく、およびそのような要素は、対応する属性識別子によって識別可能であってもよい。この取消実行属性は、例えば、本明細書の以下でｅｘｅｃＤｉｓａｂｌｅなどと称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、取消実行属性識別子を含んでもよい。さらに、取消実行属性を表すコマンドリソース構造要素の選択は、取消コマンド実行を呼び出してもよい。コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥである１つまたは複数の実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造を変更してコマンド実行の状態の変化を呼び出し、およびコマンドリソース構造をデータ構造から削除することを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、取消コマンド実行を呼び出すことを含んでもよい。取消コマンド実行は、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。あるいは、取消コマンド実行は、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、上記のように、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。１つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。

マシンツーマシン通信のプロトコルに従ってリモートエンティティ管理を実行するための代替の方法が開示される。この方法は、第１のエンティティにおいて第２のエンティティからＲＥＳＴｆｕｌメソッド要求を受信することを含んでもよい。第１のエンティティは、そのＲＥＳＴｆｕｌメソッドにより変更可能なデータ構造を含んでもよい。データ構造は、第１のリソースを表す下位データ構造を含んでもよく、第１のリソースは、コマンドリソース状態を呼び出す動作を定義する。下位データ構造は識別子により識別可能であってもよく、ＲＥＳＴｆｕｌメソッド要求は識別子を含んでもよく、およびリソースコマンドを識別してもよい。方法は、ＲＥＳＴｆｕｌメソッドを実行して、識別子およびリソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース状態における変化を呼び出す動作は、コマンド実行を呼び出す動作、コマンド実行への中断を呼び出す動作、再開コマンド実行を呼び出す動作、または取消コマンド実行を呼び出す動作を含んでもよい。

一実施形態では、マシンツーマシン通信のプロトコルに従ってｘＲＥＭを実行するための方法は、ＲＥＳＴｆｕｌメソッドを実行する要求（「ＲＥＳＴｆｕｌメソッド要求」）を、第１のエンティティにおいて第２のエンティティから受信することを含んでもよい。第１のエンティティは、ＲＥＳＴｆｕｌメソッドにより変更可能なデータ構造を含んでもよい。このデータ構造は、例えば、本明細書で「ｓｃｌｂａｓｅ」などと称されるデータ構造を含むサービス能力レイヤ（「ＳＣＬ」）を表すデータ構造であってもよい。ＲＥＳＴｆｕｌメソッド要求は、第３のエンティティにより実行可能なコマンド（以降「リソースコマンド」）に関連付けられたリソースを識別してもよい。方法はまた、ＲＥＳＴｆｕｌメソッドを実行して、リソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッドは、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥ、ＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥ、ＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥ、および／またはＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥであってもよい。ＲＥＳＴｆｕｌメソッドが、例えば、ＲＥＳＴｆｕｌメソッドＣＲＥＡＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、リソースコマンドを表す下位データ構造（以降「コマンドリソース構造」）をデータ構造においてインスタンス化することを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造をデータ構造から削除することを含んでもよい。ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＲＥＴＲＩＥＶＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造の一部もしくはすべての複製、および／またはコマンドリソース構造の状態（「コマンドリソース状態」）を第２のエンティティに送信することを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＵＰＤＡＴＥである実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造を変更して、コマンドの状態（「コマンド状態」）における変化を呼び出すことを含んでもよい。１つまたは複数の実施形態において、下位データ構造を変更するステップは、コマンドリソース構造を変更してコマンドの実行（「コマンド実行」）を呼び出すことを含んでもよい。コマンド実行は、例えば、コマンドリソース構造へのそのような変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための下位リソース（「下位リソース」）（「コマンド実行下位リソース」）を定義してもよい。このコマンド実行下位リソースは、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される下位リソースの１つまたは複数の実施形態であってもよい。コマンドリソース構造の１つまたは複数の要素（「コマンドリソース構造要素」）は、コマンド実行下位リソースを表してもよい。

１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行下位リソースを変更することは、コマンド実行下位リソースを表すコマンドリソース構造要素をその情報により変更することによって、コマンド実行を呼び出すことを含んでもよい。

コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は、割り当てられ、およびコマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は「０」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「０」により変更することでコマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための属性を定義してもよい。これらの実施形態では、コマンドリソース構造要素は属性を表してもよく、およびそのような要素は識別子（「属性識別子」）により識別可能であってもよい。このコマンド実行属性識別子は、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される属性の１つまたは複数の実施形態であってもよい。

ＲＥＳＴｆｕｌメソッド要求は、属性識別子を含んでもよい。さらに、属性を表すコマンドリソース構造要素の選択は、コマンド実行を呼び出してもよい。そして、コマンドリソース構造を変更してコマンドの実行を呼び出すことは、属性識別子を使用して、属性を表すコマンドリソース構造要素を選択し、それによりコマンドの実行を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更してコマンド実行への中断を呼び出すことを含んでもよい。コマンド実行への中断は、例えば、コマンドリソース構造のそのような変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行への中断を呼び出す下位リソースを定義してもよい。この下位リソースは、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行への中断を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更してコマンド実行への中断を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、中断を呼び出すことを含んでもよい。コマンド実行下位リソースを変更するための情報は、割り当てられ、およびコマンド実行への中断を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して中断を呼び出すための情報は「１」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「１」により変更することによって、コマンド実行への中断を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、コマンド実行への中断を呼び出すための属性（「中断実行属性」）を定義してもよい。コマンドリソース構造要素の１つまたは複数は、中断実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この中断実行属性は、本明細書の以下でｅｘｅｃＰａｕｓｅなどと称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、中断実行属性識別子を含んでもよい。さらに、中断実行属性を表すコマンドリソース構造要素の選択は、コマンド実行への中断を呼び出してもよい。そして、コマンドリソース構造を変更してコマンド実行への中断を呼び出すことは、中断実行属性識別子を使用して、中断実行属性を表すコマンドリソース構造要素を選択し、それによりコマンド実行への中断を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンドの中断された実行の実行を再開させることを含んでもよい（「再開コマンド実行」）。再開コマンド実行は、例えば、再開コマンド実行をさせるためのコマンドリソース構造の変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報を含んでもよい。これらの実施形態では、コマンド実行リソース構造を変更して再開コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、再開コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および再開コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報は「２」であってもよく、したがって再開コマンド実行の下位リソースを表すコマンドリソース構造要素を「２」により変更することによって、再開コマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための属性（「再開実行属性」）を定義してもよい。コマンドリソース構造要素の１つまたは複数は、再開実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この再開実行属性は、例えば、本明細書の以下でｅｘｅｃＲｅｓｕｍｅなどと称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、再開実行属性識別子を含んでもよい。さらに、再開実行属性を表すコマンドリソース構造要素の選択は、再開コマンド実行を呼び出してもよい。コマンドリソース構造を変更して再開コマンド実行を呼び出すことは、再開実行属性識別子を使用して、再開実行属性を表すコマンドリソース構造要素を選択し、それにより再開コマンド実行を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンド実行の取消しを呼び出す（「取消コマンド実行」）ことを含んでもよい。取消コマンド実行は、例えば、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でｅｘｅｃＥｎａｂｌｅなどと称される下位リソースの１つまたは複数の実施形態であってもよい。１つまたは複数の実施形態において、ＲＥＳＴｆｕｌメソッド要求は、コマンド実行下位リソースを変更して、取消コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して取消コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および取消コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して取消コマンド実行を呼び出すための情報は「３」であってもよく、したがって、取消コマンド実行下位リソースを表すコマンドリソース構造要素を「３」により変更することによって、取消コマンド実行を呼び出す。

１つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための属性（「取消実行属性」）を定義してもよい。コマンドリソース構造要素の１つまたは複数は、取消実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この取消実行属性は、本明細書の以下でｅｘｅｃＤｉｓａｂｌｅなどと称される属性の１つまたは複数の実施形態であってもよい。ＲＥＳＴｆｕｌメソッド要求は、取消実行属性識別子を含んでもよい。さらに、取消実行属性を表すコマンドリソース構造要素の選択は、取消コマンド実行を呼び出してもよい。コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。

ＲＥＳＴｆｕｌメソッドがＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥである１つまたは複数の実施形態では、ＲＥＳＴｆｕｌメソッドを実行することは、コマンドリソース構造を変更してコマンド実行の状態における変化を呼び出し、およびコマンドリソース構造をデータ構造から削除することを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、取消コマンド実行を呼び出すことを含んでもよい。取消コマンド実行は、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第１のエンティティによって呼び出されてもよい。あるいは、取消コマンド実行は、ＲＥＳＴｆｕｌメソッドＤＥＬＥＴＥに応答して、第１のエンティティによって呼び出されてもよい。

１つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、上記のように、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。１つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。

マシンツーマシン通信のプロトコルに従ってリモートエンティティ管理を実行するための代替の方法が開示される。この方法は、第１のエンティティにおいて第２のエンティティからＲＥＳＴｆｕｌメソッド要求を受信することを含んでもよい。第１のエンティティは、そのＲＥＳＴｆｕｌメソッドにより変更可能なデータ構造を含んでもよい。データ構造は、第１のリソースを表す下位データ構造を含んでもよく、第１のリソースは、コマンドリソース状態を呼び出す動作を定義する。下位データ構造は、識別子により識別可能であってもよく、ならびにＲＥＳＴｆｕｌメソッド要求は識別子を含んでもよく、およびリソースコマンドを識別してもよい。方法は、ＲＥＳＴｆｕｌメソッドを実行して、識別子およびリソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。

１つまたは複数の実施形態において、コマンドリソース状態における変化を呼び出す動作は、コマンド実行を呼び出す動作、コマンド実行への中断を呼び出す動作、再開コマンド実行を呼び出す動作、または取消コマンド実行を呼び出す動作を含んでもよい。

１つまたは複数の実施形態において、コマンドの状態における変化を呼び出す下位データ構造（例えば、下記で説明するように＜ｃｏｍｍａｎｄ＞、＜ｃｏｍｍａｎｄＩｎｓｔａｎｃｅ＞、または＜ｒｅｑｕｅｓｔＩｎｓｔａｎｃｅ＞）のうちのいずれかは、その下部データ構造が下位にあるデータ構造からインポートされた属性、下位リソース、パラメータおよび引数のうちのいずれかを含んでもよい。

一実施形態では、方法は、デバイスのアドレスマッピングを保持すること、およびそのアドレスマッピングを使用して、デバイスに通知を送信することを含んでもよい。デバイスは、デバイス管理デバイスであってもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、Ｍ２Ｍデバイスを管理するための透過モードおよびプロキシモードのうちの１つを使用して、サービス能力（Ｄ）を有するＭ２Ｍデバイスを管理することを含んでもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、Ｍ２Ｍデバイスを管理すること、およびＭ２Ｍデバイスを管理するための適合モードを使用することを含んでもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、非ＥＴＳＩ Ｍ２Ｍデバイスを管理すること、および非ＥＴＳＩ Ｍ２Ｍデバイスを管理するための適合モードを使用することを含んでもよい。

一実施形態では、方法は、ゲートウェイにおいて、デバイスのアドレスマッピングを保持すること、およびそのアドレスマッピングを使用してデバイスに通知を送信することを含んでもよい。

上記実施形態における方法であり、デバイスはデバイス管理用デバイスである。

上記実施形態の少なくとも１つにおける方法であり、デバイスは、サービス能力（Ｄ）により構成されてもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、サービス能力（Ｄ）を有するＭ２Ｍデバイスを管理すること、および透過モードおよびプロキシモードのうちの１つを使用してＭ２Ｍデバイスを管理することを含んでもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、Ｍ２Ｍデバイスを管理すること、および適合モードを使用してＭ２Ｍデバイスを管理することを含んでもよい。

一実施形態では、方法は、デバイス管理ゲートウェイにおいて、非ＥＴＳＩ Ｍ２Ｍデバイスを管理すること、および適合モードを使用して非ＥＴＳＩ Ｍ２Ｍデバイスを管理することを含んでもよい。

一実施形態では、Ｍ２ＭエリアネットワークおよびＭ２Ｍデバイスをモデリングするデータについてのデータ構造は、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含む少なくとも１つの管理オブジェクトを含み、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含んでもよく、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含み、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓを含み、および少なくとも１つの管理オブジェクトは、ｅｔｓｉＳｅｎｓｏｒｓを含む。データ構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも１つを提供してもよい。

一実施形態では、マシンツーマシン（Ｍ２Ｍ）エリアネットワークおよびＭ２Ｍデバイスをデータについてのデータモデリングの方法は、Ｍ２Ｍネットワークおよび少なくとも１つのデバイスについての少なくとも１つの管理オブジェクトを含む、Ｍ２Ｍについてのデータモデルを管理することを含んでもよい。

上記実施形態における方法であり、管理することは、デバイスリストおよび構成管理を提供してもよい。

上記実施形態の少なくとも１つにおける方法であり、管理することは、エリアネットワーク構成管理を提供してもよい。

上記実施形態の少なくとも１つにおける方法であり、管理することは、エリアネットワーク性能管理を提供してもよい。

上記実施形態の少なくとも１つにおける方法であり、管理することは、デバイスのグループ管理を提供してもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＳｅｎｓｏｒｓを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、下位リソースを含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、別の管理オブジェクトの下位リソースを含んでもよい。

上記実施形態における方法であり、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏは、ａｒｅａＮｗｋＩｎｓｔａｎｃｅを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ａｒｅａＮｗｋＩｎｓｔａｎｃｅは、ａｒｅａＮｗｋＩＤ、ａｒｅａＮｗｋＴｙｐｅ、ｗｏｒｋｍｇＣｈａｎｎｅｌＦｒｅｑｕｅｎｃｙ、およびａｄｄｒｅｓｓＭｏｄのうちのいずれかを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙは、ｄｅｖｉｃｅＩｎｓｔａｎｃｅおよびｄｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＬｉｓｔのうちのいずれかをグループとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＩｎｓｔａｎｃｅは、ｄｅｖｉｃｅＧｒｏｕｐＬｉｓｔ、ｅｔｓｉＢａｔｔｅｒｙ、ｅｔｓｉＭｅｍｏｒｙ、およびｅｔｓｉＳｅｎｓｏｒのうちの少なくとも１つを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＩｎｓｔａｎｃｅは、ｄｅｖｉｃｅＴｙｐｅ、ｄｅｖｉｃｅＩＤ、ａｄｄｒｅｓｓＴｙｐｅ、ａｒｅａＮｗｋＩＤ、ｉｎｔｅｒｎａｌ ａｄｄｒｅｓｓ、ｅｘｔｅｒｎａｌ ａｄｄｒｅｓｓ、ｓｌｅｅｐＩｎｔｅｒｖａｌ、ｓｌｅｅｐＤｕｒａｔｉｏｎ、ｓｔａｔｕｓ、ｍａｘＲｔｒＡｄｖｅｒｔｉｓｅｍｅｎｔｓ、ｍｉｎＤｅｌａｙＢｅｔｗｅｅｎＲａｓ、ｍａｘＲａＤｅｌａｙＴｉｍｅ、ｔｅｎａｔｉｖｅＮｃｅＬｉｆｅｔｉｍｅ、ｈｏｐＬｉｍｉｔ、ｒｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌ、ｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｓ、またはｍａｘＲｔｒＳｏｌｉｃｉｔａｔｉｏｎＩｎｔｅｒｖａｌのうちの少なくとも１つを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓは、ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅは、ｇｒｏｕｐＩＤ、ｇｒｏｕｐＴｙｐｅ、ｇｒｏｕｐＳｉｚｅ、ｍｅｍｂｅｒ（メンバ）、またはｃｏｎｄｉｔｉｏｎ（条件）のうちの少なくとも１つを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓは、ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅは、ｇｒｏｕｐＩＤ、ｅｎａｂｌｅ、ｄｉｓａｂｌｅ、ｒｅｓｕｌｔｓ（結果）、またはｄｅｓｃｒｉｐｔｉｏｎ（詳細）のうちの少なくとも１つを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＳｅｎｓｏｒｓは、ｓｅｎｓｏｒＩｎｓｔａｎｃｅを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｓｅｎｓｏｒＩｎｓｔａｎｃｅは、ｓｅｎｓｏｒＩＤ、ｓｅｎｓｏｒＴｙｐｅ、ｍａｎｕｆａｃｔｕｒｅｒ（製造者）、またはｏｐｅｒａｔｉｏｎｓ（動作）のうちの少なくとも１つを下位リソースとして含んでもよい。

上記実施形態の少なくとも１つにおける方法であり、ｏｐｅｒａｔｉｏｎｓは、ｅｎａｂｌｅ、ｄｉｓａｂｌｅ、またはｒｅｓｕｌｔ（結果）のうちの少なくとも１つを下位リソースとして含んでもよい。

一実施形態では、マシンツーマシン（Ｍ２Ｍ）エリアネットワークおよびＭ２Ｍデバイスをモデリングするデータについてのリソース構造は、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含む少なくとも１つの管理オブジェクトを含んでもよく、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含み、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含み、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＧｒｏｕｐＯｐｅｒａｔｉｏｎｓを含み、少なくとも１つの管理オブジェクトはｅｔｓｉＳｅｎｓｏｒｓを含み、リソース構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも１つを提供する。

一実施形態では、Ｍ２ＭエリアネットワークおよびＭ２Ｍデバイスをモデリングするデータについてのデータ構造は、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓを含む少なくとも１つの管理オブジェクト、およびｅｔｓｉＳｅｎｓｏｒｓを含む少なくとも１つの管理オブジェクトを含む。データ構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも１つを提供する。

一実施形態では、マシンツーマシン（Ｍ２Ｍ）エリアネットワークおよびＭ２Ｍデバイスについてのデータモデリングの方法は、Ｍ２Ｍネットワークおよび少なくとも１つのデバイスについての少なくとも１つの管理オブジェクトを含む、Ｍ２Ｍについてのデータモデルを管理することを含んでもよい。

上記実施形態における方法であり、管理することは、デバイスリストおよび構成管理を提供する。

上記実施形態の少なくとも１つにおける方法であり、管理することは、エリアネットワーク構成管理を提供する。

上記実施形態の少なくとも１つにおける方法であり、管理することは、エリアネットワーク性能管理を提供する。

上記実施形態の少なくとも１つにおける方法であり、管理することは、デバイスのグループ管理を提供する。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含む。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含む。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含む。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓを含む。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、ｅｔｓｉＳｅｎｓｏｒｓを含む。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、下位リソースを備える。

上記実施形態の少なくとも１つにおける方法であり、少なくとも１つの管理オブジェクトは、別の管理オブジェクトの下位リソースを備える。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏは、ａｒｅａＮｗｋＩｎｓｔａｎｃｅを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ａｒｅａＮｗｋＩｎｓｔａｎｃｅは、ａｒｅａＮｗｋＩＤ、ａｒｅａＮｗｋＴｙｐｅ、ｗｏｒｋｉｎｇＣｈａｎｎｅｌＦｒｅｑｕｅｎｃｙ、ａｄｄｒｅｓｓＭｏｄｅ、ｓｌｅｅｐＩｎｔｅｒｖａｌ、ｓｌｅｅｐＤｕｒａｔｉｏｎ、ｎｕｍＯｆＤｅｖｉｃｅｓ、およびａｔｔａｃｈｅｄＤｅｖｉｃｅｓのうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙは、ｄｅｖｉｃｅＩｎｓｔａｎｃｅおよびａｒｅａＮｗｋＩｎｓｔａｎｃｅのうちの少なくとも１つをグループとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＩｎｓｔａｎｃｅは、ｇｒｏｕｐｓ（グループ）、ｄｅｖｉｃｅＴｙｐｅ、ｄｅｖｉｃｅＩＤ、ａｄｄｒｅｓｓＴｙｐｅ、ａｒｅａＮｗｋＩＤ、ｉｎｔｅｒｎａｌＡｄｄｒｅｓｓ、ｅｘｔｅｒｎａｌＡｄｄｒｅｓｓ、ｓｌｅｅｐＩｎｔｅｒｖａｌ、ｓｌｅｅｐＤｕｒａｔｉｏｎ、ｓｔａｔｕｓ（状態）、ｅｔｓｉＢａｔｔｅｒｙ、ｅｔｓｉＭｅｍｏｒｙ、ｅｔｓｉＳｅｎｓｏｒ、ｂｌｏｃｋＳｉｚｅ、およびＭＴＵのうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＩｎｓｔａｎｃｅは、６ＬｏＷＰＡＮ、Ｗｉ−Ｆｉ、ＲＦＩＤ、およびＺｉｇＢｅｅのうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐは、ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｄｅｖｉｃｅＧｒｏｕｐＩｎｓｔａｎｃｅは、ｇｒｏｕｐＩＤ、ｇｒｏｕｐＴｙｐｅ、ｇｒｏｕｐＳｉｚｅ、ｍｅｍｂｅｒ（メンバ）、またはｓｔａｔｕｓ（状態）のうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓは、ｇｒｏｕｐｓ（グループ）、ｓｕｂｓｃｒｉｐｔｉｏｎｓ（詳細）、およびｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅのうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｏｐｅｒａｔｉｏｎＩｎｓｔａｎｃｅは、ｇｒｏｕｐＩＤ、ｅｘｅｃＥｎａｂｌｅ、ｅｘｅｃＤｉｓａｂｌｅ、ｅｘｅｃＰａｕｓｅ、ｅｘｅｃＲｅｓｕｍｅ、ｅｘｅｃＳｔａｔｕｓ、ＯｐｅｒａｔｉｏｎＩＤ、ｅｘｅｃＲｅｓｕｌｔｓ、およびｅｘｅｃＰａｒａｍｅｔｅｒｓのうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｅｔｓｉＳｅｎｓｏｒｓは、ｓｅｎｓｏｒＩｎｓｔａｎｃｅを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｓｅｎｓｏｒＩｎｓｔａｎｃｅは、ｓｅｎｓｏｒＩＤ、ｓｅｎｓｏｒＴｙｐｅ、ｍａｎｕｆａｃｔｕｒｅｒ（製造者）、またはｏｐｅｒａｔｉｏｎｓ（動作）のうちの少なくとも１つを下位リソースとして含む。

上記実施形態の少なくとも１つにおける方法であり、ｏｐｅｒａｔｉｏｎｓは、ｅｎａｂｌｅ、ｄｉｓａｂｌｅ、またはｒｅｓｕｌｔ（結果）のうちの少なくとも１つを下位リソースとして含む。

一実施形態では、無線送信／受信ユニットは、上記実施形態のうちのいずれか１つにおける方法を実装するように構成されてもよい。

一実施形態では、基地局は、上記実施形態のうちのいずれか１つにおける方法を実装するように構成されてもよい

一実施形態では、有形コンピュータ可読記憶媒体は、上記実施形態のうちのいずれか１つにおける方法を実行するために、メモリにロード可能であり、およびコンピューティングデバイスにより実行可能な実行可能命令を記憶してもよい。

一実施形態では、マシンツーマシン（Ｍ２Ｍ）エリアネットワークおよびＭ２Ｍデバイスをモデリングするデータについてのリソース構造は、ｅｔｓｉＡｒｅａＮｗｋＩｎｆｏを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＩｎｖｅｎｔｏｒｙを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＡｒｅａＮｗｋＤｅｖｉｃｅＧｒｏｕｐｓを含む少なくとも１つの管理オブジェクト、ｅｔｓｉＧｒｏｕｐＭｇｍｔＯｐｅｒａｔｉｏｎｓを含む少なくとも１つの管理オブジェクト、およびｅｔｓｉＳｅｎｓｏｒｓを含む少なくとも１つの管理オブジェクトを含んでもよく、ならびにリソース構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも１つを提供する。

上述した方法、装置、およびシステムの変形は、本発明の範囲から逸脱しないで可能である。適用することができる種々の実施形態に照らして、説明される実施形態は例示に過ぎず、および下記の特許請求の範囲を限定するものと解釈すべきでないことが理解されよう。例えば、本明細書に記載の例示的実施形態はハンドヘルドデバイスを含み、当該ハンドヘルドデバイスは、任意の適切な電圧を提供するバッテリなどの任意の適切な電圧源を含んでもよく、またはそのような電圧源と共に利用されてもよい。

上記では特定の組み合わせで特徴および要素を説明したが、当業者の一人は、各特徴または要素を単独で、または他の特徴および要素と任意の組み合わせで使用することができることを認識されよう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアに実装されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続上で伝送される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、これらに限定されない。ソフトウェアと関連したプロセッサが使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波送受信機を実装してもよい。

さらに、上記の実施形態では、処理プラットフォーム、コンピューティングシステム、コントローラ、およびプロセッサを収容する他のデバイスが記述される。これらのデバイスは、少なくとも１つの中央処理装置（「ＣＰＵ」）およびメモリを収容してもよい。コンピュータプログラミングの分野の当業者の慣行に従って、動作および操作もしくは命令の記号的表現への参照は、各種ＣＰＵおよびメモリによって実行されてもよい。そのような動作および操作もしくは命令は、「実行される」「コンピュータにより実行される」、または「ＣＰＵにより実行される」等と言及されてもよい。

当業者は、動作および記号的に表現された操作もしくは命令は、ＣＰＵによる電気信号の操作を含むことを認識されよう。電子システムは、結果として電子信号の変換または減少を生じさせることができるデータビット、およびメモリシステム内の記憶場所におけるデータビットの保持を表し、それにより、ＣＰＵの動作ならびに信号の他の処理を再構成するか、またはその他の形で変化させる。データビットが保持される記憶場所は、データビットに対応し、またはデータビットを表す特定の電気的特性、磁気的特性、光学的特性、または有機的特性を有する物理的な位置である。例示的実施形態は、上記のプラットフォームまたはＣＰＵに限定されず、ならびに他のプラットフォームおよびＣＰＵは本明細書に記載の方法を支援してもよいことを理解されたい。

データビットは、磁気ディスク、光学ディスク、およびＣＰＵにより読み取り可能な任意の他の揮発性（例えば、ランダムアクセスメモリ（「ＲＡＭ」））または不揮発性（例えば、読み出し専用メモリ（「ＲＯＭ」））の大容量記憶システムを含むコンピュータ可読媒体に保持することもできる。コンピュータ可読媒体は、協働するまたは相互接続されたコンピュータ可読媒体を含むことができ、そのような媒体は、処理システムに限定的に存在するか、または処理システムにとってローカルもしくはリモートの複数の相互接続された処理システム間に分散される。例示的な実施形態は上記のメモリに限定されず、他のプラットフォームおよびメモリが本明細書に記載の方法を支援できることを理解されたい。

本出願の詳細で使用される要素、動作、または指示はいずれも、明示的にその旨を述べない限り本発明に不可欠または必須であると解釈すべきでない。また、本明細書で使用される場合、冠詞「ａ」は１つまたは複数の項目を含むことが意図される。１つのみの項目が意図される場合は、用語「１つの」または同様の文言が使用される。さらに、本明細書で使用される複数の項目および／または複数の項目のカテゴリの列挙により従った用語「〜のいずれか（any of）」は、「〜のいずれか」、「〜の任意の組み合わせ」、「任意の複数の〜」、ならびに／あるいは、項目および／または個々の項目のカテゴリもしくは他の項目および／もしくは複数の項目のカテゴリを伴う「複数の任意の組み合わせ」を含むことが意図される。さらに、本明細書で使用される場合、用語「セット（set）」および／または「集合」は、ゼロを含む任意の数の項目を含むことが意図される。さらに、本明細書で使用される場合、用語「数（number）」は、ゼロを含む任意の数を含むことが意図される。

さらに、請求項は、その趣旨の記述がない限り記載された順序または要素に限定されると解釈すべきでない。加えて、請求項における用語「手段（means）」の使用は、米国特許法第１１２条第６項を援用することが意図され、および用語「手段」を含まない請求項はいずれもそのように意図されない。

Claims (37)

1. リモートエンティティ管理（「ＲＥＭ」）のためのサービス能力（「ＳＣ」）と、複数の管理レイヤの１つに従って第２のＭ２ＭエンティティのＲＥＭを行うための下部リソース構造を有するリソース構造とを備えるように、第１のマシンツーマシン（「Ｍ２Ｍ」）エンティティを構成するステップと、
   前記下部リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを行うステップと
   を含むことを特徴とする方法。
2. 前記第１のＭ２ＭエンティティはＭ２Ｍサーバを含み、前記第２のＭ２Ｍエンティティは、Ｍ２Ｍアプリケーション、Ｍ２Ｍサービス能力、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイスを含むことを特徴とする請求項１に記載の方法。
3. 前記複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤ、の少なくとも２つを含むことを特徴とする請求項１に記載の方法。
4. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、アプリケーション管理レイヤに従ったＭ２Ｍアプリケーションのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項１に記載の方法。
5. 前記アプリケーション管理レイヤはアプリケーションのライフサイクル管理を行うための機能を備えることを特徴とする請求項４に記載の方法。
6. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、サービス管理レイヤに従ったＭ２Ｍサービス能力のリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項１に記載の方法。
7. 前記サービス管理は、ソフトウェア管理および／またはファームウェア管理を行う機能を備えることを特徴とする請求項６に記載の方法。
8. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、ネットワーク管理レイヤに従ったＭ２Ｍエリアネットワークのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項１に記載の方法。
9. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、デバイス管理レイヤに従ったＭ２Ｍデバイスのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項１に記載の方法。
10. 各前記複数の管理レイヤは、前記第２のＭ２Ｍエンティティの設定管理、障害管理、および性能管理のいずれかを行う機能を定義することを特徴とする請求項１に記載の方法。
11. 前記下部リソース構造の前記リソースおよび属性のいずれかを操作するコマンドを前記第１のＭ２Ｍエンティティで受け取るステップをさらに含み、前記第２のＭ２ＭエンティティのＲＥＭは前記コマンドに応じて行われることを特徴とする請求項１に記載の方法。
12. 前記コマンドはＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項１１に記載の方法。
13. 前記下部リソース構造の前記リソースおよび属性のいずれかを操作する第１のコマンドを前記第１のＭ２Ｍエンティティで受け取るステップをさらに含み、前記第２のＭ２ＭエンティティのＲＥＭを行うステップは、前記下部リソース構造の前記リソースおよび属性のいずれかを操作する第２のコマンドを前記第２のＭ２Ｍエンティティに送信するステップと、前記受け取られた第２のコマンドに応じて前記第２のＭ２ＭエンティティのＲＥＭを行うステップとを含むことを特徴とする請求項１に記載の方法。
14. 前記第１のコマンドおよび第２のコマンドの両方がＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項１３に記載の方法。
15. 前記第１のコマンドはＲＥＳＴｆｕｌメソッドを含み、前記第２のコマンドは非ＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項１３に記載の方法。
16. 前記第２のＭ２ＭエンティティのＲＥＭを行うステップは、前記下部リソース構造の前記リソースおよび属性のいずれかを操作するコマンドを前記第２のＭ２Ｍエンティティに送信するステップと、前記受け取られたコマンドに応じて前記第２のＭ２ＭエンティティのＲＥＭを行うステップとを含むことを特徴とする請求項１に記載の方法。
17. 前記コマンドは非ＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項１６に記載の方法。
18. 前記コマンドはＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項１６に記載の方法。
19. 前記第２のＭ２Ｍエンティティは、前記下部リソース構造のコピーを備え、前記第２のＭ２ＭエンティティのＲＥＭを行うステップは、前記下部リソース構造のリソースおよび属性のいずれかを操作した後に、前記下部リソース構造の前記コピーを操作して前記下部リソース構造を複製するステップを含むことを特徴とする請求項１に記載の方法。
20. リモートエンティティ管理（「ＲＥＭ」）のためのサービス能力と、複数の管理レイヤの１つに従って第２のＭ２ＭエンティティのＲＥＭを行うための下部リソース構造を有するリソース構造とを備えて構成された第１のマシンツーマシン（「Ｍ２Ｍ」）エンティティと、
    前記下部リソース構造のリソースおよび属性のいずれかを操作することにより、第２のＭ２ＭエンティティのＲＥＭを行うように適合されたプロセッサと
    を備えることを特徴とする装置。
21. 前記第１のＭ２ＭエンティティはＭ２Ｍサーバを含み、前記第２のＭ２Ｍエンティティは、Ｍ２Ｍアプリケーション、Ｍ２Ｍサービス能力、Ｍ２Ｍエリアネットワーク、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイスを含むことを特徴とする請求項２０に記載の装置。
22. 前記複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤ、の少なくとも２つを含むことを特徴とする請求項２０に記載の装置。
23. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、アプリケーション管理レイヤに従ったＭ２Ｍアプリケーションのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項２０に記載の装置。
24. 前記アプリケーション管理レイヤは、アプリケーションのライフサイクル管理を行うための機能を備えることを特徴とする請求項２３に記載の装置。
25. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、サービス管理レイヤに従ったＭ２Ｍサービス能力のリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項２０に記載の装置。
26. 前記サービス管理は、ソフトウェア管理および／またはファームウェア管理を行う機能を備えることを特徴とする請求項２５に記載の装置。
27. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、ネットワーク管理レイヤに従ったＭ２Ｍエリアネットワークのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項２０に記載の装置。
28. 第２のＭ２Ｍエンティティのリモートエンティティ管理のための前記下部リソース構造は、デバイス管理レイヤに従ったＭ２Ｍデバイスのリモートエンティティ管理のためのリソース構造を含むことを特徴とする請求項２０に記載の装置。
29. 各前記複数の管理レイヤは、前記第２のＭ２Ｍエンティティの設定管理、障害管理、および性能管理のいずれかを行う機能を定義することを特徴とする請求項２０に記載の装置。
30. 前記第１のＭ２Ｍエンティティは、前記下部リソース構造の前記リソースおよび属性のいずれかを操作するコマンドを受け取るＳＣをさらに備え、前記第２のＭ２ＭエンティティのＲＥＭは、前記コマンドに応じて行われることを特徴とする請求項２０に記載の装置。
31. 前記コマンドはＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項２０に記載の装置。
32. 前記第１のＭ２Ｍエンティティは、
    前記下部リソース構造の前記リソースおよび属性のいずれかを操作する第１のコマンドを受け取るＳＣと、
    前記第２のＭ２Ｍエンティティで保持されている前記下部リソース構造のコピーの前記リソースのコピーと前記属性のコピーとのいずれかを操作する第２のコマンドを前記第２のＭ２Ｍエンティティに通信するＳＣと
    をさらに備え、
    前記プロセッサは、第２のコマンドに応答して、前記第２のＭ２Ｍエンティティで保持されている前記下部リソース構造のコピーの前記リソースの前記コピーと前記属性の前記コピーとのいずれかの操作を行わせる第２のコマンドを前記第２のＭ２Ｍエンティティに送信するようにさらに適合されることを特徴とする請求項２０に記載の装置。
33. 前記第１のコマンドおよび第２のコマンドの両方がＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項３２に記載の装置。
34. 前記第１のコマンドはＲＥＳＴｆｕｌメソッドを含み、前記第２のコマンドは非ＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項３２に記載の装置。
35. 前記第１のＭ２Ｍエンティティは、
    前記第２のＭ２Ｍエンティティで保持されている前記下部リソース構造のコピーの前記リソースのコピーと前記属性のコピーとのいずれかを操作するコマンドを前記第２のＭ２Ｍエンティティに通信するＳＣをさらに備え、
    前記プロセッサは、第２のコマンドに応答して、前記第２のＭ２Ｍエンティティで保持されている前記下部リソース構造のコピーの前記リソースの前記コピーと前記属性の前記コピーとのいずれかの操作を行わせるコマンドを前記第２のＭ２Ｍエンティティに送信するようにさらに適合されることを特徴とする請求項２０に記載の装置。
36. 前記コマンドは非ＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項３５に記載の装置。
37. 前記コマンドはＲＥＳＴｆｕｌメソッドを含むことを特徴とする請求項３５に記載の装置。

Images