JP6194024B2 - Ｍ２ｍサービス設定変更方法及びこのための装置 - Google Patents

Description

本発明は、無線通信システムに関し、具体的に、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）システムでサービス設定を変更する方法及びこのための装置に関する。

近来、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）通信に対する関心が高まっている。Ｍ２Ｍ通信は、人の介入なしに各機械（Ｍａｃｈｉｎｅ）間で行われる通信を意味し、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）またはＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）通信とも称される。Ｍ２Ｍ通信に使用される端末をＭ２Ｍデバイス（Ｍ２Ｍ ｄｅｖｉｃｅ）と称するが、Ｍ２Ｍデバイスは、一般に低い移動性（ｌｏｗ ｍｏｂｉｌｉｔｙ）、時間耐性（ｔｉｍｅ ｔｏｌｅｒａｎｔ）または遅延耐性（ｄｅｌａｙ ｔｏｌｅｒａｎｔ）、小さいデータ伝送（ｓｍａｌｌ ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ）などの特性を有し、各機械間の通信情報を中央で格納・管理するＭ２Ｍサーバーと連結されて使用される。また、Ｍ２Ｍデバイスが互いに異なる通信方式に従って連結されると、通信方式が変更される区間でＭ２Ｍゲートウェイを介してＭ２ＭデバイスとＭ２Ｍサーバーとが連結され、これを通じて全体のＭ２Ｍシステムが構成される。該当のシステムを基盤にして事物追跡（Ｔｒａｃｋｉｎｇ）、電力計量（Ｍｅｔｅｒｉｎｇ）、自動支払いシステム（Ｐａｙｍｅｎｔ）、医療分野サービス、遠隔調整などのサービスを提供することができる。

本発明は、Ｍ２Ｍシステムに関する。

本発明の目的は、Ｍ２Ｍシステムで効率的に信号を送受信する方法及びこのための装置を提供することにある。

本発明の他の目的は、Ｍ２Ｍシステムで効率的にサービス設定を変更する方法及びこのための装置を提供することにある。

本発明の更に他の目的は、Ｍ２Ｍシステムで特定のデバイスの状態変化に従ってサービス設定を変更する方法及びこのための装置を提供することにある。

本発明の更に他の目的は、Ｍ２Ｍシステムで移動端末またはゲートウェイに対してサービス持続性を保障する方法及びこのための装置を提供することにある。

本発明で達成しようとする技術的課題は、前記技術的課題に制限されず、言及していない更に他の技術的課題は、下記の記載から本発明の属する技術分野で通常の知識を有する者に明確に理解され得るだろう。

本発明の一態様として、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）システムでＭ２ＭゲートウェイがＭ２Ｍサービス設定を変更するための方法が提供され、前記方法は、少なくとも一つの政策情報を少なくとも一つのデバイスに伝送するステップであって、前記少なくとも一つの政策情報のそれぞれは、範囲情報（ｓｃｏｐｅ ｉｎｆｏｒｍａｔｉｏｎ）及び条件情報（ｃｏｎｄｉｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含む、ステップと、前記Ｍ２Ｍゲートウェイの状態が、前記条件情報が指示する状態に該当する場合、前記範囲情報が指示するデバイスに前記Ｍ２Ｍゲートウェイの状態変化を指示する第１の通知を伝送するステップを含むことができる。

本発明の他の態様として、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）システムのＭ２Ｍゲートウェイが提供され、前記Ｍ２Ｍゲートウェイは、ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｕｎｉｔ）と、プロセッサとを含み、前記プロセッサは、前記ネットワークインターフェースユニットを介して少なくとも一つの政策情報を少なくとも一つのデバイスに伝送するように構成され、前記少なくとも一つの政策情報のそれぞれは、範囲情報及び条件情報を含み、また、前記プロセッサは、前記Ｍ２Ｍゲートウェイの状態が、前記条件情報が指示する状態に該当する場合、前記範囲情報が指示するデバイスに前記Ｍ２Ｍゲートウェイの状態変化を指示する第１の通知を伝送するように構成され得る。

好ましくは、前記第１の通知は、前記少なくとも一つの政策情報のうち一つを指示する第１の識別情報を含み、前記範囲情報が指示するデバイスが前記第１の通知を受信する場合、前記デバイスは、前記第１の識別情報が指示する政策情報によってＭ２Ｍサービスを行うことができる。

好ましくは、前記少なくとも一つの政策情報は、制限政策情報（ｌｉｍｉｔ ｐｏｌｉｃｙ ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記制限政策情報は、前記少なくとも一つのデバイスで発生した要求の許容イベントカテゴリー範囲（ａｌｌｏｗｅｄ ｅｖｅｎｔ ｃａｔｅｇｏｒｙ ｒａｎｇｅ）を指示する情報と、前記制限政策情報が適用される前記Ｍ２Ｍゲートウェイの状態を指示する情報とを含み、前記少なくとも一つのデバイスで発生した要求は、前記Ｍ２Ｍゲートウェイの状態及び前記要求が前記許容イベントカテゴリー範囲に含まれるか否かによって前記Ｍ２Ｍゲートウェイに伝送されるか否かを決定することができる。

好ましくは、前記少なくとも一つの政策情報は、基本政策情報（ｄｅｆａｕｌｔ ｐｏｌｉｃｙ ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記少なくとも一つのデバイスは、前記第１の通知を受信しない場合、前記基本政策情報によってＭ２Ｍサービスを行うことができる。

好ましくは、前記少なくとも一つの政策情報は基本政策情報を含み、前記基本政策情報は、前記少なくとも一つのデバイスで発生した要求に対する基本属性を指示する情報と、前記基本政策情報が適用される前記Ｍ２Ｍゲートウェイの状態を指示する情報とを含み、前記Ｍ２Ｍゲートウェイの状態が、前記基本政策情報が適用される状態に該当し、前記少なくとも一つのデバイスで発生した要求の特定の属性が指定されていない場合、前記基本政策情報に含まれた基本属性を適用することができる。

好ましくは、前記Ｍ２Ｍゲートウェイの状態が、前記条件情報が指示する状態から他の状態に変更される場合、前記範囲情報が指示するデバイスに前記Ｍ２Ｍゲートウェイの状態変化を指示する第２の通知を伝送することができる。

好ましくは、前記第２の通知は、前記少なくとも一つの政策情報のうち一つを指示する第２の識別情報を含み、前記範囲情報が指示するデバイスが前記第２の通知を受信する場合、前記デバイスは、前記第２の識別情報が指示する政策情報によってＭ２Ｍサービスを行うことができる。

好ましくは、前記第１の通知の伝送のために購読のための資源が生成され、前記購読のための資源は、前記範囲情報及び前記条件情報を基盤にして生成され、前記Ｍ２Ｍゲートウェイまたは政策管理者によって生成され得る。

好ましくは、前記購読のための資源は、前記通知が伝送されるデバイスの住所に対する第１の情報と、前記通知を行う基準値に対する第２の情報とを含み、前記購読のための資源を生成することは、前記範囲情報を前記第１の情報にマッピングし、前記条件情報が指示する状態の値を前記第２の情報にマッピングすることを含むことができる。

好ましくは、前記条件情報は、前記Ｍ２Ｍゲートウェイの状態を示す情報の住所値と、特定の条件を指示する条件値とを含むことができる。

好ましくは、前記範囲情報は、前記政策情報が適用されるアプリケーションインスタンスまたはアプリケーションエンティティの識別情報を含むことができる。

好ましくは、前記制限政策情報は、前記Ｍ２Ｍゲートウェイに伝達されなかった要求の処理方式を指示する情報をさらに含むことができる。

好ましくは、前記要求の処理方式は、全ての係留中の要求を伝送すること、最も最近の要求を伝送すること、特定の範囲のイベントカテゴリー値を有する要求または特定の範囲の寿命を有する要求を伝送すること、または、次の政策に従って要求を処理することを含むことができる。

好ましくは、前記基本政策情報は、前記少なくとも一つのデバイスで発生する要求のイベントカテゴリーに対する基本値を指示する情報を含むことができる。

本発明によると、Ｍ２Ｍシステムで効率的に信号を送受信することができる。

また、本発明によると、Ｍ２Ｍシステムで効率的にサービス設定を変更することができる。

また、本発明によると、Ｍ２Ｍシステムで特定のデバイスの状態変化に従ってサービス設定を変更することができる。

また、本発明によると、Ｍ２Ｍシステムで移動端末またはゲートウェイに対してサービス持続性を保障することができる。

本発明で得られる効果は、以上で言及した各効果に制限されず、言及していない更に他の効果は、下記の記載から本発明の属する技術分野で通常の知識を有する者に明確に理解され得るだろう。

Ｍ２Ｍシステムを例示する図である。 Ｍ２Ｍシステムの層構造（ｌａｙｅｒｅｄ ｓｔｒｕｃｔｕｒｅ）を例示する図である。 Ｍ２Ｍシステムの機能的アーキテクチャ（ｆｕｎｃｔｉｏｎａｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を例示する図である。 Ｍ２Ｍシステムの構成を例示する図である。 Ｍ２Ｍシステムで使用される資源（ｒｅｓｏｕｒｃｅ）を例示する図である。 特定のＭ２Ｍアプリケーションのための資源を例示する図である。 一般的なＭ２Ｍシステムの通信の流れを例示する図である。 Ｍ２Ｍシステムで互いに異なるエンティティが互いに連動する例を示す図である。 購読のための資源を例示する図である。 Ｍ２Ｍシステムのオーバーレイネットワーク構造を例示する図である。 Ｍ２Ｍシステムを例示する図である。 Ｍ２Ｍシステムの動作を例示する図である。 本発明に係るＭ２Ｍサービス設定変更動作を例示する図である。 本発明に係る基本政策情報を例示する図である。 本発明に係る制限政策情報を例示する図である。 本発明によって制限政策情報を購読資源にマッピングする例を示す図である。 本発明に係るＭ２Ｍデバイスの属性情報を格納するための資源構造を例示する図である。 本発明に係るＭ２Ｍサービス設定変更動作を例示する図である。 本発明が適用され得る装置を例示するブロック図である。

添付の図面は、本発明に関する理解を促進するために詳細な説明の一部として含まれ、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
本発明に係る好ましい実施例を添付の図面を参照して詳細に説明する。添付の図面と共に以下で開示する詳細な説明は、本発明の例示的な実施例を説明するためのものであって、本発明が実施され得る唯一の実施例を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、本発明の属する分野における通常の技術者は、本発明がこのような具体的な細部事項なしでも実施され得ることが分かる。

いくつかの場合、本発明の概念が曖昧になることを避けるために公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示することができる。また、本明細書において、同一の構成要素に対して同一の図面符号を使用することができる。

本明細書において、Ｍ２Ｍデバイス（Ｍ２Ｍ ｄｅｖｉｃｅ）は、Ｍ２Ｍ通信のためのデバイスを称する。Ｍ２Ｍデバイスは、固定されたり、移動性を有することができ、Ｍ２Ｍサーバーと通信し、ユーザーデータ及び／または制御情報を送受信することができる。Ｍ２Ｍデバイスは、端末（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、ＵＴ（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅ Ｓｔａｔｉｏｎ）、無線装置（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、無線モデム（ｗｉｒｅｌｅｓｓ ｍｏｄｅｍ）、携帯装置（ｈａｎｄｈｅｌｄ ｄｅｖｉｃｅ）などと称することができる。本発明において、Ｍ２Ｍサーバーは、Ｍ２Ｍ通信のためのサーバーを称し、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）または移動局（ｍｏｂｉｌｅ ｓｔａｔｉｏｎ）を称する。Ｍ２Ｍサーバーは、各Ｍ２Ｍデバイス及び／または他のＭ２Ｍサーバーと通信し、データ及び制御情報を交換することができる。また、本発明において、Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスが連結されたネットワークと、Ｍ２Ｍサーバーが連結されたネットワークとが互いに異なる場合、一つのネットワークから他のネットワークに入っていく連結点としての役割をする装置を称する。

また、本明細書において、「エンティティ（ｅｎｔｉｔｙ）」という用語は、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバーなどのハードウェアを称するのに使用することができ、または、以下で説明するＭ２Ｍアプリケーション層とＭ２Ｍ（共通）サービス層のソフトウェアコンポーネント（ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ）を称するのに使用することができる。

図１は、Ｍ２Ｍシステムを例示する。図１は、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）技術規格（Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＴＳ）によるＭ２Ｍシステムを例示する。

ＥＴＳＩ ＴＳ Ｍ２Ｍ技術規格によるＭ２Ｍシステムは、多様なＭ２Ｍアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）のための共通Ｍ２Ｍサービスフレームワーク（Ｓｅｒｖｉｃｅ Ｆｒａｍｅｗｏｒｋ）を定義する。Ｍ２Ｍアプリケーションは、ｅヘルス（ｅ―Ｈｅａｌｔｈ）、都市自動化（Ｃｉｔｙ Ａｕｔｏｍａｔｉｏｎ）、コネクテッドコンシューマ（Ｃｏｎｎｅｃｔｅｄ Ｃｏｎｓｕｍｅｒ）、オートモチーブ（Ａｕｔｏｍｏｔｉｖｅ）などのＭ２Ｍサービスソリューションを具現するソフトウェアコンポーネントを称することができる。Ｍ２Ｍシステムでは、このような多様なＭ２Ｍアプリケーションを具現するために共通的に必要な各機能を提供し、共通的に必要な各機能は、Ｍ２ＭサービスまたはＭ２Ｍ共通サービスと称することができる。このようなＭ２Ｍ共通サービスを用いると、各Ｍ２Ｍアプリケーションごとに基本サービスフレームワークを再び構成する必要なしでＭ２Ｍアプリケーションを容易に具現することができる。

Ｍ２Ｍサービスは、サービス能力（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ、ＳＣ）の形態で提供され、Ｍ２Ｍアプリケーションは、オープンインターフェース（ｏｐｅｎ ｉｎｔｅｒｆａｃｅ）を介してＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）に接近し、ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）が提供するＭ２Ｍサービスを利用することができる。ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）は、Ｍ２Ｍアプリケーションがサービスフレームワーク上で提供されるときに使用できるＭ２Ｍサービスの各機能（ｆｕｎｃｔｉｏｎ）の集合と言うことができる。ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）は、ＳＣエンティティ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｅｎｔｉｔｙ）及びＳＣ層（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｌａｙｅｒ）を通称することができる。

ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）は、ｘＳＣと表現することができる。ここで、ｘは、Ｎ／Ｇ／Ｄのうち一つと表現することができ、ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）がネットワーク（Ｎｅｔｗｏｒｋ）（及び／またはサーバー）、ゲートウェイ（Ｇａｔｅｗａｙ）、デバイス（Ｄｅｖｉｃｅ）のうちいずれに存在するかを示す。例えば、ＮＳＣは、ネットワーク及び／またはサーバー上に存在するＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を示し、ＧＳＣは、ゲートウェイ上に存在するＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を示す。

Ｍ２Ｍアプリケーションは、ネットワーク、ゲートウェイ、またはデバイス上に存在することができる。ネットワーク上に存在したり、サーバーと直接連結されて存在するＭ２Ｍアプリケーションは、Ｍ２Ｍネットワークアプリケーション（Ｍ２Ｍ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ）と称し、簡略にＮＡ（Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ）と示すことができる。例えば、ＮＡは、サーバーに直接連結されて具現されるソフトウェアであって、Ｍ２ＭゲートウェイまたはＭ２Ｍデバイスと通信し、これらを管理する役割をすることができる。デバイス上に存在するＭ２Ｍアプリケーションは、Ｍ２Ｍデバイスアプリケーション（Ｍ２Ｍ Ｄｅｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ）と称し、簡略にＤＡ（Ｄｅｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ）と示すことができる。例えば、ＤＡは、Ｍ２Ｍデバイスで駆動されるソフトウェアであって、センサー情報などをＮＡに伝達することもできる。ゲートウェイ上に存在するＭ２Ｍアプリケーションは、Ｍ２Ｍゲートウェイアプリケーション（Ｇａｔｅｗａｙ Ａｐｐｌｉｃａｔｉｏｎ）と称し、簡略にＧＡ（Ｇａｔｅｗａｙ Ａｐｐｌｉｃａｔｉｏｎ）と示すことができる。例えば、ＧＡは、Ｍ２Ｍゲートウェイを管理する役割もすることができ、ＤＡにＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を提供することもできる。Ｍ２Ｍアプリケーションは、アプリケーションエンティティ（ＡＥ）とアプリケーション層を通称することができる。

図１を参照すると、Ｍ２Ｍシステムアーキテクチャは、ネットワークドメインと、デバイス及びゲートウェイドメインとに区分することができる。ネットワークドメインは、Ｍ２Ｍシステム管理のための各機能（ｆｕｎｃｔｉｏｎ）と、ネットワーク管理のための各機能とを含むことができる。Ｍ２Ｍシステム管理のための機能は、デバイス及びゲートウェイドメインに存在する各デバイスを管理するＭ２ＭアプリケーションとＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）によって行うことができ、ネットワーク管理のための機能は、コアネットワークとアクセスネットワークによって行うことができる。したがって、図１の例において、コアネットワークとアクセスネットワークは、Ｍ２Ｍ機能を行うよりは、各エンティティ間の連結を提供する。コアネットワークとアクセスネットワークを介してネットワークドメインとデバイス及びゲートウェイドメインでＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）間のＭ２Ｍ通信を行うことができ、各ドメインのＭ２Ｍアプリケーションは、各ドメインのＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を介して信号または情報を取り交わすことができる。

アクセスネットワーク（Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）は、Ｍ２Ｍデバイス及びゲートウェイドメインとコアネットワークとの通信を可能にするエンティティである。アクセスネットワークの例としては、ｘＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＨＦＣ（Ｈｙｂｒｉｄ Ｆｉｂｅｒ Ｃｏａｘ）、衛星（ｓａｔｅｌｌｉｔｅ）、ＧＥＲＡＮ、ＵＴＲＡＮ、ｅＵＴＲＡＮ、無線（Ｗｉｒｅｌｅｓｓ）ＬＡＮ、ＷｉＭＡＸなどがある。

コアネットワーク（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）連結、サービスとネットワーク制御、相互連結、ローミング（ｒｏａｍｉｎｇ）などの機能を提供するエンティティである。コアネットワークは、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）コアネットワーク、ＥＴＳＩ ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）コアネットワーク及び３ＧＰＰ２コアネットワークなどを含む。

Ｍ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）は、多くのＭ２Ｍネットワークアプリケーションで共有され得るＭ２Ｍ共通サービス機能（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ、ＣＳＦ）を提供し、Ｍ２Ｍサービスをオープンインターフェースを介して露出させ、各Ｍ２ＭアプリケーションがＭ２Ｍサービスを利用できるようにする。Ｍ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）エンティティは、共通サービス機能（ＣＳＦ）の一つのインスタンスと理解することができ、各Ｍ２Ｍアプリケーションによって使用されて共有され得る各共通サービス機能（ＣＳＦ）のサブセットを提供する。Ｍ２Ｍ ＳＣＬ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｌａｙｅｒ）は、このようなＭ２Ｍ ＳＣエンティティを含む層を称することができる。

Ｍ２Ｍアプリケーションは、サービスロジッグ（ｓｅｒｖｉｃｅ ｌｏｇｉｃ）を動作させ、オープンインターフェースを介してＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を使用できるエンティティである。Ｍ２Ｍアプリケーション層は、このようなＭ２Ｍアプリケーション及び関連動作ロジッグ（ｏｐｅｒａｔｉｏｎａｌ ｌｏｇｉｃ）を含む層を称することができる。

Ｍ２Ｍデバイスは、Ｍ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を通じてＭ２Ｍデバイスアプリケーションを動作させるエンティティである。Ｍ２Ｍデバイスは、直接ネットワークドメインのＭ２Ｍサーバーと通信することもでき、Ｍ２Ｍゲートウェイを介してネットワークドメインのＭ２Ｍサーバーと通信することもできる。Ｍ２Ｍゲートウェイを介して連結される場合、Ｍ２Ｍゲートウェイは、プロキシ（ｐｒｏｘｙ）のように動作する。Ｍ２Ｍデバイスは、Ｍ２Ｍアプリケーション及び／またはＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を含むことができる。

Ｍ２Ｍ領域ネットワーク（Ｍ２Ｍ ａｒｅａ ｎｅｔｗｏｒｋ）は、Ｍ２ＭデバイスとＭ２Ｍゲートウェイとの間の連結（ｃｏｎｎｅｃｔｉｖｉｔｙ）を提供する。この場合、Ｍ２ＭゲートウェイとＭ２Ｍサーバーとの間のネットワークと、Ｍ２ＭデバイスとＭ２Ｍゲートウェイとの間のネットワークとは互いに異なり得る。例えば、Ｍ２Ｍ領域ネットワークは、ＩＥＥＥ８０２．１５．１、ジグビー（Ｚｉｇｂｅｅ）、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、ＩＥＴＦ ＲＯＬＬ、ＩＳＡ１００．１１ａなどのＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）技術と、ＰＬＣ（Ｐｏｗｅｒ Ｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｍ―ＢＵＳ、無線Ｍ―ＢＵＳ、ＫＮＸなどのローカルネットワーク技術を用いて具現することができる。

Ｍ２Ｍゲートウェイは、Ｍ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を通じてＭ２Ｍアプリケーションを管理し、Ｍ２Ｍアプリケーションに対してサービスを提供するエンティティである。Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスとネットワークドメインとの間のプロキシとしての役割をし、ＥＴＳＩ非―互換（ｎｏｎ―ｃｏｍｐｌｉａｎｔ）Ｍ２Ｍデバイスにもサービスを提供する役割をすることができる。Ｍ２Ｍゲートウェイは、各Ｍ２Ｍデバイスのうちゲートウェイ機能を有するエンティティを称することができる。Ｍ２Ｍゲートウェイは、Ｍ２Ｍアプリケーション及び／またはＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）を含むことができる。

図１に例示したＭ２Ｍシステムアーキテクチャは、例示に過ぎなく、各エンティティの名称は変わり得る。例えば、ｏｎｅＭ２Ｍ技術規格によるシステム（ｏｎｅＭ２Ｍシステムと称する）において、Ｍ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）は、Ｍ２Ｍ共通サービスエンティティ（ｃｏｍｍｏｎ ｓｅｒｖｉｃｅ ｅｎｔｉｔｙ、ＣＳＥ）と称することができ、ＳＣＬ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｌａｙｅｒ）は、共通サービス層（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ、ＣＳＬ）と称することができる。また、Ｍ２Ｍアプリケーションは、アプリケーションエンティティ（ａｐｐｌｉｃａｔｉｏｎ ｅｎｔｉｔｙ、ＡＥ）と称することができ、Ｍ２Ｍアプリケーション層は、簡略にアプリケーション層と称することができる。同様に、各ドメインの名称も変わり得る。例えば、ｏｎｅＭ２Ｍシステムにおいて、ネットワークドメインは、インフラストラクチャドメイン（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｄｏｍａｉｎ）と称することができ、デバイス及びゲートウェイドメインはフィールドドメイン（ｆｉｅｌｄ ｄｏｍａｉｎ）と称することができる。

図１に例示したように、Ｍ２Ｍシステムは、Ｍ２Ｍ通信のためにＭ２Ｍアプリケーション層及びＭ２Ｍ ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）層を含む層構造として理解することができる。

図２は、Ｍ２Ｍシステムの層構造を例示する。

図２を参照すると、Ｍ２Ｍシステムは、アプリケーション層２０２、共通サービス層２０４、及び基底ネットワークサービス層（ｕｎｄｅｒｌｙｉｎｇ ｎｅｔｗｏｒｋ ｓｅｒｖｉｃｅｓ ｌａｙｅｒ）２０６を含むことができる。上述したように、アプリケーション層２０２はＭ２Ｍアプリケーション層に対応し、共通サービス層２０４はＭ２Ｍ ＳＣＬに対応し得る。基底ネットワークサービス層２０６は、コアネットワークに存在する装置管理（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）、位置サービス（ｌｏｃａｔｉｏｎ ｓｅｒｖｉｃｅ）、及び装置トリガリング（ｄｅｖｉｃｅ ｔｒｉｇｇｅｒｉｎｇ）などの各サービスを共通サービス層２０４に提供する。

図３は、Ｍ２Ｍシステムの機能的アーキテクチャを例示する。機能的な側面において、Ｍ２Ｍシステムアーキテクチャは、アプリケーションエンティティ（ａｐｐｌｉｃａｔｉｏｎ ｅｎｔｉｔｙ、ＡＥ）３０２、共通サービスエンティティ（ｃｏｍｍｏｎ ｓｅｒｖｉｃｅ ｅｎｔｉｔｙ、ＣＳＥ）３０４、及び基底（ｕｎｄｅｒｌｙｉｎｇ）ネットワークサービスエンティティ（ｎｅｔｗｏｒｋ ｓｅｒｖｉｃｅ ｅｎｔｉｔｙ、ＮＳＥ）３０６を含むことができる。各エンティティ３０２、３０４、３０６は、共通サービスエンティティ３０４が支援する基準点（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）を介して通信することができる。基準点は、各エンティティ３０２、３０４、３０６間の通信の流れ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｌｏｗ）を指定する役割をする。基準点はＭｃｘと表現することができ、Ｍｃは、「Ｍ２Ｍ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ」を意味する。本明細書において、Ｍｃａ基準点、Ｍｃｃ基準点、及びＭｃｎ基準点は、それぞれＭｃａ、Ｍｃｃ、Ｍｃｎと表記することができる。

図３を参照すると、Ｍｃａ基準点３１２は、アプリケーションエンティティ（ＡＥ）３０２と共通サービスエンティティ（ＣＳＥ）３０４の通信の流れを指定する。Ｍｃａ基準点３１２は、ＡＥ ３０２がＣＳＥ ３０４によって提供されるサービスを利用できるようにし、ＣＳＥ ３０４がＡＥ ３０２と通信できるようにする。Ｍｃａ基準点３１２は、Ｍ２Ｍアプリケーション層とＭ２Ｍ共通サービス層との間のインターフェースを称することができる。

Ｍｃｃ基準点３１４は、互いに異なる各共通サービスエンティティ（ＣＳＥ）３０４間の通信の流れを指定する。Ｍｃｃ基準点３１４は、ＣＳＥ ３０４が必要な各機能を提供するとき、他のＣＳＥのサービスを利用できるようにする。Ｍｃｃ基準点３１４を介して提供されるサービスは、ＣＳＥ ３０４が支援する各機能に依存的であり得る。Ｍｃｃ基準点３１２は、各Ｍ２Ｍ共通サービス層間のインターフェースを称することができる。

Ｍｃｎ基準点３１６は、ＣＳＥ ３０４と基底ネットワークサービスエンティティ（ＮＳＥ）３０６との間の通信の流れを指定する。Ｍｃｎ基準点３１６は、ＣＳＥ ３０４が要求された各機能を提供するために基底ＮＳＥ ３０６が提供するサービスを利用できるようにする。Ｍｃｎ基準点３１２は、Ｍ２Ｍ共通サービス層とＭ２Ｍ基底ネットワーク層との間のインターフェースを称することができる。

また、図３の例において、ＣＳＥ ３０４は、多様な共通サービス機能（ｃｏｍｍｏｎ ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ、ＣＳＦ）を提供することができる。例えば、ＣＳＥ ３０４は、アプリケーション及びサービス層管理（Ａｐｐｌｉｃａｔｉｏｎ ａｎｄ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ）機能、通信管理及び伝達処理（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｄｅｌｉｖｅｒｙ Ｈａｎｄｌｉｎｇ）機能、データ管理及び格納（Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙ）機能、装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）機能、グループ管理（Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ）機能、発見（Ｄｉｓｃｏｖｅｒｙ）機能、位置（Ｌｏｃａｔｉｏｎ）機能、ネットワークサービス露出／サービス実行及びトリガリング（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ｅｘｐｏｓｕｒｅ／Ｓｅｒｖｉｃｅ Ｅｘｅｃｕｔｉｏｎ ａｎｄ Ｔｒｉｇｇｅｒｉｎｇ）機能、登録（Ｒｅｇｉｓｔｒａｔｉｏｎ）機能、保安（Ｓｅｃｕｒｉｔｙ）機能、サービス課金及び計算（Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）機能、サービスセッション管理機能（Ｓｅｒｖｉｃｅ Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ）、及び購読／通知（Ｓｕｂｓｃｒｉｐｔｉｏｎ／Ｎｏｔｉｆｉｃａｔｉｏｎ）機能のうち少なくとも一つを含むことができる。ＣＳＥ ３０４は、前記各共通サービス機能のインスタンス（ｉｎｓｔａｎｃｅ）を示し、各Ｍ２Ｍアプリケーションが使用して共有できる各共通サービス機能のサブセットを提供する。以下では、各共通サービス機能を概略的に説明する。

― アプリケーション及びサービス層管理（Ａｐｐｌｉｃａｔｉｏｎ ａｎｄ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ、ＡＳＭ）：各ＡＥと各ＣＳＥの管理機能を提供する。例えば、ＡＳＭ機能は、各ＣＳＥの機能を設定（ｃｏｎｆｉｇｕｒｅ）し、問題を解決（ｔｒｏｕｂｌｅｓｈｏｏｔ）し、アップグレード（ｕｐｇｒａｄｅ）するだけでなく、各ＡＥの機能をアップグレードすることができる。

― 通信管理及び伝達処理（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｄｅｌｉｖｅｒｙ Ｈａｎｄｌｉｎｇ、ＣＭＤＨ）：他の各ＣＳＥ、各ＡＥ、各ＮＳＥとの通信を提供する。例えば、ＣＭＤＨ機能は、ＣＳＥ―ＣＳＥ通信（ＣＳＥ―ｔｏ―ＣＳＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）のための連結（ｃｏｎｎｅｃｔｉｏｎ）をいつどのように使用するかを決定し、特定の要求が遅延して伝達され得るように制御することができる。

― データ管理及び格納（Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙ、ＤＭＲ）：各Ｍ２Ｍアプリケーションがデータを交換・共有できるようにする。例えば、ＤＭＲ機能は、大量のデータを収集（ｃｏｌｌｅｃｔｉｎｇ）／併合（ａｇｇｒｅｇａｔｉｎｇ）し、データを特定のフォーマットに変換（ｃｏｎｖｅｒｔｉｎｇ）・格納（ｓｔｏｒｉｎｇ）することができる。

― 装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ、ＤＭＧ）：Ｍ２Ｍゲートウェイ及びＭ２Ｍデバイスのみならず、Ｍ２Ｍ領域ネットワークに存在する各デバイスに対するデバイス機能を管理する。例えば、ＤＭＧ機能は、アプリケーション設置及び設定、ファームウェア（Ｆｉｒｍｗａｒｅ）アップデート、ロギング（Ｌｏｇｇｉｎｇ）、モニタリング（Ｍｏｎｉｔｏｒｉｎｇ）、診断（Ｄｉａｇｎｏｓｔｉｃｓ）、ネットワークトポロジー（Ｔｏｐｏｌｏｇｙ）管理などを行うことができる。

― 発見（Ｄｉｓｃｏｖｅｒｙ、ＤＩＳ）：与えられた範囲及び条件内で要求に応じて情報及び資源などの情報を検索（ｓｅａｒｃｈｉｎｇ）する。

― グループ管理（Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ、ＧＭＧ）：例えば、資源（ｒｅｓｏｕｒｃｅ）、Ｍ２Ｍデバイス、またはＭ２Ｍゲートウェイを束ねてグループを生成できるが、グループ関連要求をハンドリング（ｈａｎｄｌｉｎｇ）する。

― 位置（Ｌｏｃａｔｉｏｎ、ＬＯＣ）：Ｍ２ＭアプリケーションがＭ２ＭデバイスまたはＭ２Ｍゲートウェイの位置情報を獲得する役割をする。

― ネットワークサービス露出／サービス実行及びトリガリング（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ｅｘｐｏｓｕｒｅ／Ｓｅｒｖｉｃｅ Ｅｘｅｃｕｔｉｏｎ ａｎｄ Ｔｒｉｇｇｅｒｉｎｇ、ＮＳＳＥ）：基底ネットワークの通信を可能にし、基底ネットワークが提供するサービスまたは機能を使用できるようにする。

― 登録（Ｒｅｇｉｓｔｒａｔｉｏｎ、ＲＥＧ）：Ｍ２Ｍアプリケーションまたは他のＣＳＥが特定のＣＳＥに登録を処理する役割をする。登録は、特定のＣＳＥのＭ２Ｍサービス機能を使用するために行われる。

― 保安（Ｓｅｃｕｒｉｔｙ、ＳＥＣ）：保安キーなどの敏感なデータハンドリング、保安連関関係（Ａｓｓｏｃｉａｔｉｏｎ）設立、認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、権限付与（Ａｕｔｈｏｒｉｚａｔｉｏｎ）、ＩＤ（Ｉｄｅｎｔｉｔｙ）保護などの役割をする。

― サービス課金及び計算（Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ、ＳＣＡ）：ＣＳＥに課金機能を提供する役割をする。

― サービスセッション管理（Ｓｅｒｖｉｃｅ Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ、ＳＳＭ）：端対端（ｅｎｄ―ｔｏ―ｅｎｄ）通信のためのサービス層のＭ２Ｍセッションを管理する役割をする。

― 購読／通知（Ｓｕｂｓｃｒｉｐｔｉｏｎ／Ｎｏｔｉｆｉｃａｔｉｏｎ、ＳＵＢ）：特定の資源に対する変更を購読（Ｓｕｂｓｃｒｉｐｔｉｏｎ）するとき、該当の資源が変更されるとこれを通知（ｎｏｔｉｆｉｃａｔｉｏｎ）する役割をする。

図４は、Ｍ２Ｍシステムの構成を例示する。本明細書において、ノード（ｎｏｄｅ）は、一つ以上のＭ２Ｍアプリケーションを含むエンティティ、または一つのＣＳＥ及び０個以上のＭ２Ｍアプリケーションを含むエンティティを意味する。

アプリケーション専用ノード（Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｄｉｃａｔｅｄ Ｎｏｄｅ、ＡＤＮ）は、少なくとも一つのアプリケーションエンティティ（ＡＥ）を有するが、共通サービスエンティティ（ＣＳＥ）を有さないノードを称することができる。ＡＤＮは、Ｍｃａを介して一つの中間ノード（Ｍｉｄｄｌｅ Ｎｏｄｅ、ＭＮ）または一つのインフラストラクチャノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ、ＩＮ）と通信することができる。ＡＤＮは、制限された能力を有するＭ２Ｍデバイス（Ｍ２Ｍ ｄｅｖｉｃｅ ｈａｖｉｎｇ ａ ｃｏｎｓｔｒａｉｎｅｄ ｃａｐａｂｉｌｉｔｙ）と称することができるが、制限された能力を有するＭ２Ｍデバイスは、共通サービス層（ｃｏｍｍｏｎ ｓｅｒｖｉｃｅ ｌａｙｅｒ）または共通サービスエンティティ（ＣＳＥ）を含まないＭ２Ｍデバイスを称することができる。制限された能力を有するＭ２Ｍデバイスは、簡略に制限的なＭ２Ｍデバイス（ｃｏｎｓｔｒａｉｎｅｄ Ｍ２Ｍ ｄｅｖｉｃｅ）と称することができる。

アプリケーションサービスノード（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｎｏｄｅ、ＡＳＮ）は、少なくとも一つの共通サービスエンティティ（ＣＳＥ）を有し、少なくとも一つのＭ２Ｍアプリケーションエンティティ（ＡＥ）を有するノードを称することができる。ＡＳＮは、Ｍｃｃを介して一つの中間ノード（Ｍｉｄｄｌｅ Ｎｏｄｅ）または一つのインフラストラクチャノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）と通信することができる。ＡＳＮは、Ｍ２Ｍデバイスと称することができる。

中間ノード（Ｍｉｄｄｌｅ Ｎｏｄｅ、ＭＮ）は、一つの共通サービスエンティティ（ＣＳＥ）及び０個以上のＭ２Ｍアプリケーションエンティティ（ＡＥ）を有するノードを称することができる。ＭＮは、Ｍｃｃを介して一つのインフラストラクチャノード（ＩＮ）または他の中間ノード（ＭＮ）と通信することができ、あるいは、Ｍｃｃを介してＩＮ／ＭＮ／ＡＳＮと通信することができ、あるいは、Ｍｃａを介してＡＤＮと通信することができる。ＭＮは、Ｍ２Ｍゲートウェイと称することができる。

インフラストラクチャノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ、ＩＮ）は、一つの共通サービスエンティティ（ＣＳＥ）を有し、０個以上のアプリケーションエンティティ（ＡＥ）を有するノードを称することができる。ＩＮは、Ｍｃｃを介して少なくとも一つの中間ノード（ＭＮ）と通信することができ、及び／または少なくとも一つのＡＳＮと通信することができる。あるいは、ＩＮは、Ｍｃａを介して一つ以上のＡＤＮと通信することができる。ＩＮは、Ｍ２Ｍサーバーと称することができる。

図４を参照すると、ケース１は、ＡＤＮ ４０２とＩＮ ４２２との間の通信を例示する。ＡＤＮ ４０２は、制限された能力を有するＭ２Ｍデバイスであり得る。この場合、ＡＤＮ ４０２は、ＣＳＥまたは共通サービス層を有さないので、Ｍｃａを介してＩＮ ４２２のＣＳＥと通信することができる。また、この場合、ＡＤＮ ４０２は、ＣＳＥまたは共通サービス層を有さないので、ＡＥまたはアプリケーション層で生成されたデータを格納することができない。したがって、ケース１において、ＡＤＮ ４０２のＡＥまたはアプリケーション層で生成されたデータは、ＩＮ ４２２のＣＳＥに格納することができる。

ケース２は、ＡＤＮ ４０４とＭＮ ４１４との間の通信を例示する。ＡＤＮ ４０４も、制限された能力を有するＭ２Ｍデバイスであり得る。したがって、ＡＤＮ ４０４がＭＮ ４１４のＣＳＥと通信するという点を除いては、ケース１と類似する形に動作することができる。すなわち、ＡＤＮ ４０４は、Ｍｃａを介してＭＮ ４１４のＣＳＥと通信することができる。また、ＡＤＮ ４０４は、ＣＳＥまたは共通サービス層を有さないので、ＡＥまたはアプリケーション層で生成されたデータを格納することができない。したがって、ＡＤＮ ４０４のＡＥまたはアプリケーション層で生成されたデータは、ＭＮ ４１４のＣＳＥに格納することができる。

一方、ケース２において、ＭＮ ４１４は、ＭＮ ４１２を経てＩＮ ４２２と通信することができる。この場合、ＭＮ ４１４とＭＮ ４１２、そして、ＭＮ ４１２とＩＮ ４２２は、Ｍｃｃを介して通信することができる。ＭＮ ４１４がＭＮ ４１２を経ずに直接ＩＮ ４２２と通信することも可能である。

ケース３は、ＡＳＮ ４０６とＭＮ ４１４との間の通信を例示する。ケース１またはケース２とは異なり、ＡＳＮ ４０６は、ＣＳＥまたは共通サービス層を有するので、ＡＳＮ ４０６のＡＥまたはアプリケーション層で生成されたデータを自身のＣＳＥまたは共通サービス層に格納することができる。また、ＡＳＮ ４０６のＡＥは、ＡＳＮ ４０６のＣＳＥを介してＭＮ ４１４のＣＳＥと通信することができる。

ケース４は、ＡＳＮ ４０８とＭＮ ４１４との間の通信を例示する。ケース３と比較すると、ＡＳＮ ４０８のＣＳＥは、ＭＮを経ずに直接ＩＮ ４２２のＣＳＥと通信することができる。

ＩＮ ４２２または４２４は、インフラストラクチャドメインまたはネットワークドメインに位置することができ、一つのＣＳＥを含み、０個以上のＡＥを含むことができる。各ＩＮ ４２２、４２４は、Ｍｃｃを介して互いに通信することができる。

図５は、Ｍ２Ｍシステムで使用される資源を例示する。

Ｍ２Ｍシステムにおいて、アプリケーションエンティティ（ＡＥ）、ＣＳＥ、データなどは、資源として表現することができる。Ｍ２Ｍシステムにおいて、資源は、固有の住所（例えば、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ ＩｄｅｎｔｉｆｉｅｒまたはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ））を用いて固有にアドレッシングされ得るデータ構造を称する。Ｍ２Ｍシステムにおいて、資源は、ツリー構造を有することができ、ＣＳＥまたは共通サービス層によって管理されて格納され、互いに論理的に連結され得る。したがって、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサーバーのＣＳＥまたは共通サービス層では、このような資源を有することができる。その一方、Ｍ２ＭシステムのＡＥまたはアプリケーション層では、このような資源構造を有することができない。ツリー構造を有するＭ２Ｍ資源において、ｂａｓｅＵＲＩはルート資源で、ｂａｓｅＵＲＩは、属性（ａｔｔｒｉｂｕｔｅ）及び子資源（ｃｈｉｌｄ ｒｅｓｏｕｒｃｅ）を有することができる。

Ｍ２Ｍシステムにおいては、多様な資源が定義されるが、各Ｍ２Ｍアプリケーションは、資源を基盤にして通信を行うことができる。例えば、アプリケーションを登録し、センサー値を読み込むなどのＭ２Ｍサービスを行うのに使用することができる。それぞれの資源は、インスタンスが生成されるとき、固有の住所情報（例えば、ＵＲＩ）が与えられ、ルート資源と同一に属性及び子資源を有することができ、各資源は、固有の住所情報を用いてアドレッシングすることができる。

属性は、資源自体に対する情報を格納し、子資源を有することができない。子資源は、自身の属性及び自身の子資源を有することができ、例えば、子資源には、ＣＳＥ資源、アプリケーション資源（Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ）、接近権限資源（Ａｃｃｅｓｓ Ｒｉｇｈｔ Ｒｅｓｏｕｒｃｅ）、コンテナ資源（Ｃｏｎｔａｉｎｅｒ Ｒｅｓｏｕｒｃｅ）、グループ資源（Ｇｒｏｕｐ Ｒｅｓｏｕｒｃｅ）、購読資源（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｓｏｕｒｃｅ）、発見資源（Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｏｕｒｃｅ）などがある。

― ＣＳＥ資源は、ｂａｓｅＵＲＩ／ｅｎｔｉｔｙの下位に存在する資源であって、該当のＣＳＥに登録（連結）された他のＣＳＥの情報を含む。

― アプリケーション資源：ｂａｓｅＵＲＩ／ａｐｐｌｉｃａｔｉｏｎまたはｂａｓｅＵＲＩ／ｅｎｔｉｔｙ／（特定のＣＳＥ）／ａｐｐｌｉｃａｔｉｏｎの下位に存在する資源であって、ｂａｓｅＵＲＩ／ａｐｐｌｉｃａｔｉｏｎの下位に存在する場合、該当のＣＳＥに登録（連結）された各アプリケーションの情報が格納され、ｂａｓｅＵＲＩ／ｃｓｅｓ／（特定のＣＳＥ）／ａｐｐｌｉｃａｔｉｏｎの下位に存在する場合、「（特定のＣＳＥ）」という名前を有するＣＳＥに登録された各アプリケーションの情報を格納する。

― 接近権限資源：ｂａｓｅＵＲＩ／ａｃｃｅｓｓＲｉｇｈｔの下位に存在する資源であって、接近権限と関連する情報を格納する資源である。本資源に含まれた接近権限情報を用いて権限付与を行うことができる。

― コンテナ資源：ｂａｓｅＵＲＩ／ｃｏｎｔａｉｎｅｒの下位に存在する資源であって、ＣＳＥまたはＡＥ別に生成されるデータを格納する。

― グループ資源：ｂａｓｅＵＲＩ／ｇｒｏｕｐの下位に存在する資源であって、多くの資源を一つに束ねて共に処理できるようにする機能を提供する。

― 購読資源（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｒｅｓｏｕｒｃｅ）：ｂａｓｅＵＲＩ／ｓｕｂｓｃｒｉｐｔｉｏｎの下位に存在する資源であって、資源の状態が変更されることを通知を通じて知らせる機能を行う。

― 発見資源：ｂａｓｅＵＲＩ／ｄｉｓｃｏｖｅｒｙの下位に存在する資源であって、特定の資源を探すのに使用される。

図６は、特定のＭ２Ｍアプリケーションのための資源を例示する。上述したように、特定のＭ２Ｍアプリケーションのための資源は、Ｍ２ＭゲートウェイのＣＳＥまたは共通サービス層の資源でアプリケーション資源に格納することができる。特定のＭ２Ｍアプリケーションのための資源は、全体の資源と類似する形に属性及び子資源を有することができる。図６において、ｎｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌｓ資源は、購読資源と関連する資源であり得る。

図７は、一般的なＭ２Ｍシステムの通信の流れを例示する。一般に、Ｍ２Ｍシステムの動作は、データ交換を基盤にして行われる。例えば、特定のデバイスは、他のデバイスの動作を停止させるために該当の命令をデータの形態で他の装置に伝達することができる。デバイス内でデータを格納するために特定の形態のデータ構造が用いられるが、これを資源と称する。資源は、固有の住所（例えば、ＵＲＩ）を用いて接続することができる。

図７を参照すると、ＡＥとＣＳＥとの間の連結または各ＣＳＥ間の連結で要求及び応答方式（Ｒｅｑｕｅｓｔ ａｎｄ Ｒｅｓｐｏｎｓｅ Ｓｃｈｅｍｅ）が使用される。発信者（ｏｒｉｇｉｎａｔｏｒ）は、受信者（ｒｅｃｅｉｖｅｒ）に格納された資源を要求するために要求メッセージを伝送し、それに対する応答として応答メッセージを受信することができる。同様に、受信者は、発信者から資源を要求するメッセージを受信し、それに対する応答として応答メッセージを発信者に伝送することができる。本明細書において、要求メッセージは要求と略称することができ、応答メッセージは応答と略称することができる。発信者から受信者に伝送される要求メッセージは、次のような情報を含むことができる。

― ｏｐ：実行される動作（Ｏｐｅｒａｔｉｏｎ）の形態
生成（Ｃｒｅａｔｅ）／回収（Ｒｅｔｒｉｅｖｅ）／更新（Ｕｐｄａｔｅ）／削除（Ｄｅｌｅｔｅ）のうち一つであり得る。

― ｔｏ：目的資源のＵＲＩ

― ｆｒ：要求（Ｒｅｑｕｅｓｔ）を生成した発信者の識別情報（またはＩＤ）

― ｍｉ：該当の要求に対するメタ情報（Ｍｅｔａ ｉｎｆｏｒｍａｔｉｏｎ）

― ｃｎ：伝達される資源の内容

該当の要求が成功裏に行われた場合、応答（Ｒｅｓｐｏｎｓｅ）メッセージは、次のような情報を含むことができる。応答メッセージは、下記の情報のうち少なくとも一つを含むことができ、または結果値（ｒｓ）のみを含むこともできる。

― ｔｏ：要求を生成した発信者の識別情報（またはＩＤ）

― ｆｒ：要求を受信した受信者の識別情報（またはＩＤ）

― ｍｉ：要求に対するメタ情報

― ｒｓ：要求に対する結果（例えば、Ｏｋａｙ、Ｏｋａｙ ａｎｄ Ｄｏｎｅ、Ｏｋａｙ ａｎｄ ｉｎｐｒｏｇｒｅｓｓ）

― ａｉ：追加的な情報

― ｃｎ：伝達される資源の内容

該当の要求に失敗した場合、応答メッセージは、次のような情報を含むことができる。

― ｔｏ：要求を生成した発信者のＩＤ

― ｆｒ：要求を受信した受信者のＩＤ

― ｍｉ：要求に対するメタ情報

― ｒｓ：要求に対する結果（例えば、Ｎｏｔ Ｏｋａｙ）

― ａｉ：追加的な情報

図８は、Ｍ２Ｍシステムで互いに異なるエンティティが互いに連動する例を示す。

図８を参照すると、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）に登録されたＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）がＭ２Ｍデバイスと連動する例が示されている。例えば、Ｍ２Ｍデバイスは、物理的な装置であるセンサーを含むことができ、ＩＮに登録されたＡＥは、Ｍ２Ｍデバイスのセンサー値を読み込むことができる。

Ｍ２Ｍデバイス上に存在するＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）は、センサーから値を読み込み、読み込んだ値を自身が登録したＣＳＥ（ｄｃｓｅ）に資源の形態（例えば、＜ｃｏｎｔａｉｎｅｒ＞資源）で格納する。このために、Ｍ２Ｍデバイス上に存在するＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）は、Ｍ２Ｍデバイスに存在するＣＳＥに先に登録しなければならない。図８に例示したように、登録が完了すると、ｄｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ １資源の形態で登録されたＭ２Ｍアプリケーション関連情報が格納される。例えば、Ｍ２Ｍデバイスのセンサー値がＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）によってｄｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ １資源の下位のコンテナ資源に格納されると、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）に登録されたＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）が該当の値に接近することができる。また、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）がＭ２Ｍデバイスに接近するためには、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）のＣＳＥ（ｎｃｓｅ）に登録されなければならない。ＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）がＣＳＥ（ｄｃｓｅ）に登録する方法と同様に、ｎｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ ２資源にＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）に対する情報が格納される。また、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）は、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）と直接通信するのではなく、中間のＣＳＥ（ｎｃｓｅ）とＣＳＥ（ｄｃｓｅ）を介して通信することができる。このために、ＣＳＥ（ｎｃｓｅ）とＣＳＥ（ｄｃｓｅ）は、互いに登録されなければならない。ＣＳＥ（ｄｃｓｅ）がＣＳＥ（ｎｃｓｅ）に登録すると、ｎｃｓｅ／ｃｓｅｓ／ｄｃｓｅ資源の下位にｄｃｓｅ関連情報（例えば、Ｌｉｎｋ）が格納される。これを通じて、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ ２）は、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ １）の情報に接近できる経路を得るようになり、該当の経路を介してセンサーの値を読み込むことができる。

図９は、購読のための資源を例示する。Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍ）では、資源の変化に従って該当の資源の変化に関心があるエンティティが、該当の変化に対する通知を購読することができる。この場合、通知を購読するためには、購読のための資源が設定されなければならない。購読のための資源は、購読資源または＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源と称することができる。

購読資源は、購読対象資源（ｓｕｂｓｃｒｉｂｅｄ―ｔｏ ｒｅｓｏｕｒｃｅ）に対する情報を含む。購読対象資源と購読資源との関係は親―子関係として表現することができる。例えば、購読対象資源を含む＜ｃｏｎｔａｉｎｅｒ＞資源は、子資源として＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源を有することができる。親購読対象資源が削除されるとき、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源は削除することができる。

購読資源が子資源である場合は、購読資源の設定（属性設定）に応じて親資源の状態変化を指示する通知を、購読資源内のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性に明示されたエンティティに伝達することができる。発信者が購読可能な資源に対するＲＥＴＲＩＥＶＥ権限を有する場合、発信者は購読資源を生成することができる。購読資源の発信者は資源購読者になる。購読対象資源に対する修正がある場合、その修正を基準属性と比較して、通知が資源購読者に伝送されるか否かを決定する。

図９を参照すると、制限的でない例として、購読資源（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源）は、多様な属性及び子資源を有することができる。例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源は、子資源として、通知配達のためのスケジューリング情報を含むｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源を有することができる。また、例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源は、表１の各属性を有することができる。表１において、Ｒ／Ｗは、該当の属性の読み取り（ｒｅａｄ）／書き込み（ｗｒｉｔｅ）の許容の有無（ｐｅｒｍｉｓｓｉｏｎ）を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表１において、発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）は、該当の属性が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源で発生可能な回数を示す。

図１０は、Ｍ２Ｍシステムのオーバーレイネットワーク構造を例示する。

Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍ）は、オーバーレイネットワーク（Ｏｖｅｒｌａｙ Ｎｅｔｗｏｒｋ）構造で構成される。オーバーレイネットワークは、概念的に物理ネットワーク上に成立する仮想のネットワークを意味する。このオーバーレイネットワーク構造内のノード（例えば、ｏｎｅＭ２Ｍでは、上述したように、ＡＤＮ、ＡＳＮ、ＭＮ、ＩＮなどがノードにマッピングされ得る）は、仮想、論理リンクで連結することができる。各リンクは、実際の物理ネットワーク内で多くの物理的リンクを介するが、通信や実際の動作のためには物理的リンクを考慮しない。例えば、図１０（ａ）を参照すると、実際のネットワークでは４個のホップ（Ｈｏｐ）で連結されるが、オーバーレイネットワークでは２個のホップで連結されたように見られる。ホップは、ネットワークに存在する各ノード間の連結を通称する用語である。

実際の物理ネットワークノードとオーバーレイネットワークのノード（すなわち、オーバーレイノード）とが同一でない理由は、次の通りである。

１．機能的な差によってノードが生成され得る。例えば、物理ネットワークで特別な機能を行う一部のデバイスがオーバーレイノードとして選定され得る。

２．連結されたネットワークの差で上位ノードの差があり得る。例えば、図１０（ｂ）を参照すると、物理ネットワークは、ブルートゥース、ワイファイ（Ｗｉ―Ｆｉ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）で連結することができ、それぞれのネットワークごとにゲートウェイが存在し得る。この場合、オーバーレイネットワークでは各ゲートウェイがノードに見られる。

図１１は、Ｍ２Ｍシステムを例示する。

図１１を参照すると、図１１に例示したＭ２Ｍシステムは、自転車を共有するＭ２Ｍサービスを提供する。図１１の例において、自転車に含まれた多様なセンサー１１１０の情報をＭ２Ｍサービスプラットフォーム１１３０に伝達するためにスマートフォン１１２０をゲートウェイとして使用する。例えば、自転車のセンシング情報は、位置、自転車ユーザーの心臓搏動情報、タイヤ圧力を含むことができる。各センサー１１１０は、センシング情報を周期的に伝達し、自転車共有サービスを提供する地方自治団体１１４０とヘルスケアサービスセンター１１５０で自転車ユーザーのためのＭ２Ｍサービスを提供できるようにする。

図１１の例において、ゲートウェイデバイスを経るべき理由は、基本的に、ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）と通称されるゲートウェイ内部ネットワークまたはＭ２Ｍ領域ネットワーク（Ｍ２Ｍ Ａｒｅａ Ｎｅｔｗｏｒｋ）内に存在する各デバイス（例えば、加速器、タイヤ―センサー、ロック装置）が、例えば、３ＧＰＰ、３ＧＰＰ２などのアクセスネットワークに連結され得ないためである。ゲートウェイは、領域ネットワークのプロトコルとアクセスネットワークプロトコルとの間のメッセージ解釈及び変換作業などを行うことができ、機能的に両ネットワークに全て連結可能である。

図１２は、Ｍ２Ｍシステムの動作を例示する。

図１２を参照すると、Ｓ１２０２段階において、サービスドメイン１２６０の各アプリケーションがＭ２Ｍサービスプラットフォーム１１３０にサービスを登録し、自転車共有サービスに対する情報変化を購読することができる。Ｍ２Ｍサービスプラットフォーム１１３０の各資源は、自転車共有サービス提供者（または自転車提供者）１１４０とヘルスサービス提供者１１５０が所有するので、更に他の資源に接続する必要があるアプリケーションは、資源の正当な接続権限（ａｃｃｅｓｓ ｒｉｇｈｔ）を要求し、適切であれば、サービス規約（ｓｅｒｖｉｃｅ ａｇｒｅｅｍｅｎｔ）を基盤にして要求を承認（ｇｒａｎｔ）することができる。

Ｓ１２０４段階において、自転車をロック解除（ｕｎｌｏｃｋ）することができる。例えば、ユーザーがスマートフォン１１２０を自転車にタグすることによって、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）インターフェースを介して自転車をロック解除することができる。

Ｓ１２０６段階において、特定の条件がトリガーされると（例えば、自転車が使用中である。）、各センサー１１１０は、ゲートウェイであるスマートフォン１１２０を介してＭ２Ｍサービスプラットフォーム１１３０に自転車の状態変化を報告（ｒｅｐｏｒｔ）することができる。

Ｓ１２０８段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、自転車共有サービス提供者１１４０に状態変化を通知することができる。この場合、自転車共有サービス提供者１１４０は、自身のウェブサイト上に自転車が使用中である状況を記録することができる。

Ｓ１２１０段階において、Ｍ２Ｍサービス管理のための正常報告の場合（ｎｏｒｍａｌ ｒｅｐｏｒｔｉｎｇ ｃａｓｅ ｆｏｒ ｍａｎａｇｉｎｇ Ｍ２Ｍ ｓｅｒｖｉｃｅ）、ユーザーの心搏動数（ｈｅａｒｔ―ｒａｔｅ）は、ハンドル（ｈａｎｄｌｅｂａｒ）上の心搏動数センサーによって持続的に収集することができる。心搏動数、位置、時間などのヘルス関連情報は、Ｍ２Ｍサービスプラットフォーム１１３０に周期的に報告することができる。

Ｓ１２１２段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、自転車共有サービス提供者１１４０とヘルスサービス提供者１１５０にヘルスサービス情報を通知することができる。

Ｓ１２１４段階において、緊急状況に対処した緊急報告の場合（ｕｒｇｅｎｔ ｒｅｐｏｒｔｉｎｇ ｃａｓｅ ｆｏｒ ｈａｎｄｌｉｎｇ ａｎｙ ｅｍｅｒｇｅｎｃｙ）、自転車に乗る間に、タイヤ圧力センサー１１１０が前のタイヤの低い空気圧（ｌｏｗ ｐｒｅｓｓｕｒｅ）を検出することができる。この場合、該当の情報は、位置情報と共に、スマートフォン１１２０を介してＭ２Ｍサービスプラットフォーム１１３０に直ぐ伝送することができる。

Ｓ１２１６段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、自転車共有サービス提供者１１４０に状態変化を通知することができる。

Ｓ１２１８段階において、自転車共有サービス提供者１１４０は、受信された位置情報に応じて最も近い自転車修理店に訪ねて、経路情報（ｒｏｕｔｅ ｉｎｆｏｒｍａｔｉｏｎ）をＭ２Ｍサービスプラットフォーム１１３０に伝送することができる。

Ｓ１２２０段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、経路情報をナビゲーションアプリケーションを有するスマートフォン１１２０に伝達することができる。

しかし、一般に、Ｍ２Ｍシステムにおいて、ゲートウェイは、常に電源に連結された状態で動作するものでない場合がある。ゲートウェイの電力が枯渇した場合、ゲートウェイは、領域ネットワークとアクセスネットワークとの間の連結を保障することができない。すなわち、ゲートウェイの電力が枯渇する場合、全体のＭ２Ｍシステムの動作が不能状態に転換される。例えば、Ｓ１２２２段階において、スマートフォン１１２０のバッテリーの消耗により、各センサー１１１０とＭ２Ｍサービスプラットフォーム１１３０との間の連結が切れる場合がある。したがって、各センサー１１１０とＭ２Ｍサービスプラットフォーム１１３０は、これ以上互いに報告または通知することができない。したがって、特定のデバイスの状態に応じてサービス持続性を保障するために、他のデバイスのサービス設定を変更できる方案が要求される。例えば、図１２の例において、特定の状況で（例えば、ゲートウェイの電力が一定の電力しきい値（Ｔｈｒｅｓｈｏｌｄ）以下に落ちる場合）、サービス持続性のためにデータの量を変更するようにサービス設定を変更できる方案が要求される。

一方、ゲートウェイまたは端末の状態に応じて、Ｍ２Ｍサービス設定変更のために各Ｍ２Ｍデバイスから伝送される要求メッセージに重要度を表示する必要がある。したがって、各Ｍ２Ｍデバイスから伝送される要求メッセージの重要度を定義する方案を提案する。要求の重要度を記述するために、要求のメタ情報に重要度表示子を追加することができる。重要度表示子は、イベントカテゴリー（Ｅｖｅｎｔ Ｃａｔｅｇｏｒｙ）と称することができる。イベントカテゴリーは、要求の発信者によって設定することができる。そうすると、イベントカテゴリーを含む要求は、各客体に割り当てられた政策（Ｐｏｌｉｃｙ）を基盤にして差別的にハンドリングすることができる。Ｍ２Ｍデバイスによって伝送される要求メッセージはｅｃを含むことができる。

ｅｃ：該当の要求をハンドリングするのに用いられるイベントカテゴリーを指示する。イベントカテゴリーは、ＣＭＤＨ ＣＳＦで遠隔ホスティングされた各資源（ｒｅｍｏｔｅｌｙ ｈｏｓｔｅｄ ｒｅｓｏｕｒｃｅｓ）に接続しようとする各要求がどのように処理されるかに関するものである。ＣＭＤＨを介した連結の選択及びスケジューリングは、イベントカテゴリーを差別的にハンドリングする政策によって運営することができる。

例えば、イベントカテゴリーが特定値Ｘに設定された要求メッセージを仮定すると、要求メッセージがローカルＣＳＥと異なるホスティングＣＳＥ上で実行される動作を要求する場合、前記要求メッセージは、ホスティングＣＳＥに行く経路上に存在する特定のＣＳＥに格納することができる。格納された要求メッセージは、既に提供された（イベントカテゴリーに対する）政策によって該当のメッセージを次のＣＳＥに伝達することができ、そうでない場合は、前記要求メッセージを格納したＣＳＥに一定時間後に伝達することができる。ローカルＣＳＥは、要求メッセージを受信する１番目のＣＳＥを称することができる。例えば、要求メッセージの発信者がＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）上のアプリケーションである場合、ローカルＣＳＥは、前記ＩＮ上のＣＳＥを称することができる。同様に、要求メッセージの発信者がＭＮ（Ｍｉｄｄｌｅ Ｎｏｄｅ）上のアプリケーションである場合、ローカルＣＳＥは、前記ＭＮ上のＣＳＥを称することができる。また、ホスティングＣＳＥは、要求メッセージの対象になる資源（またはアドレッシングされた資源）が存在するＣＳＥを称することができる。

図１３は、本発明に係るＭ２Ｍサービス設定変更動作を例示する。

Ｓ１３０２段階とＳ１３０４段階において、ＭＮ（Ｍｉｄｄｌｅ Ｎｏｄｅ）１３２０（例えば、ＭＮのＣＳＥ）は、要求と関連する少なくとも一つの政策情報を受信し、該当の情報を資源の形態で格納する。具体的には、Ｓ１３０２段階において、ＭＮ（例えば、ＭＮのＣＳＥ）は、要求と関連する基本政策情報を受信し、Ｓ１３０４段階において、ＭＮ（例えば、ＭＮのＣＳＥ）は、要求と関連する制限政策情報を受信することができる。要求と関連する少なくとも一つの政策情報は、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）、Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍシステム）で全体のサービス政策を管理する政策管理者（ｐｏｌｉｃｙ ｍａｎａｇｅｒ）、またはＭＮの内部にあるＡＥ １３３０から受信することができる。例えば、基本政策情報は、要求に対する基本政策（ｒｅｑｕｅｓｔ ｄｅｆａｕｌｔ）を含み、範囲情報（例えば、表２参照）及び条件情報（例えば、表２参照）を含むことができる。また、例えば、制限政策情報は、要求に対する制限政策（ｒｅｑｕｅｓｔ ｌｉｍｉｔａｔｉｏｎ）を含み、範囲情報（例えば、表３参照）及び条件情報（例えば、表３参照）を含むことができる。基本政策情報と制限政策情報に関する詳細な内容は、それぞれ図１４と図１５を参照して詳細に説明する。

Ｓ１３０６段階において、ＭＮ １３２０は、Ｓ１３０２段階とＳ１３０４段階で受信された少なくとも一つの政策情報を、範囲情報に明示されたデバイスまたはエンティティに伝達することができる。例えば、基本政策情報は、基本政策情報に含まれた範囲情報が指示するエンティティ（またはＭ２Ｍデバイス）に伝達することができ、制限政策情報は、制限政策情報に含まれた範囲情報が指示するエンティティ（またはＭ２Ｍデバイス）に伝達することができる。また、制限的でない例として、Ｓ１３０６段階は、Ｓ１３０２段階とＳ１３０４段階後に行うこともでき、それぞれＳ１３０２段階後に行ったり、Ｓ１３０４段階後に行うことができる。また、Ｓ１３０６段階において、少なくとも一つの政策情報は、例えば、通知の形態でＭＮ１３２０が伝達したり、あるいはＡＥ １３１０がＭＮ １３２０に登録されるとき、ＡＥ １３１０に少なくとも一つの政策情報を含む資源の住所（例えば、ＵＲＩ）を伝達し、ＡＥ １３１０が回収するように誘導することができる。

Ｓ１３０８段階において、ＭＮ １３２０は購読資源を生成することができる。例えば、ＭＮ１３２０は、Ｓ１３０２段階またはＳ１３０４段階において、少なくとも一つの政策情報を受信する場合、該当の政策情報に含まれた条件情報（例えば、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ属性）を基盤にして購読資源を生成することができる。例えば、購読資源の生成時、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ属性に含まれたＣｒｉｔｅｒｉａを購読資源のｆｉｌｔｅｒＣｒｉｔｅｒｉａ属性にマッピングすることができる（例えば、表３参照）。購読資源生成は、図１６を参照して詳細に説明する。ＭＮ １３２０は、生成された購読資源を購読することができる。

あるいは、Ｓ１３０２段階またはＳ１３０４段階において、政策情報が適用される条件が明示されている場合、シナリオの構成に応じてＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）、Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍシステム）で全体のサービス政策を管理する政策管理者、及び／またはＭＮノードの内部にあるＡＥ １３３０がＭＮ １３２０を購読することができる。この購読は、明示された条件に表現された内容を基盤にして行うことができる。

Ｓ１３１０段階において、ＭＮ １３２０がＳ１３０２段階またはＳ１３０４段階で受信された少なくとも一つの政策情報のうち特定の条件が明示されないものがある場合、該当の政策によって最初のサービスを進行することができる。すなわち、少なくとも一つの政策情報のうち条件（ｃｏｎｄｉｔｉｏｎ）情報が明示されていない基本政策情報及び／または制限政策情報によってサービスを進行することができる。該当の政策情報は、Ｓ１３０６段階で各政策情報に含まれた範囲情報が指示するエンティティ（またはＭ２Ｍデバイス）に割り当てることができる。

あるいは、Ｓ１３０２段階またはＳ１３０４段階において、受信された少なくとも一つの政策情報の全てが特定の条件を明示しているが、ＭＮ １３２０の最初の状態がいずれの条件にも該当しない場合、基本政策情報によって最初のサービスを進行することができる。

あるいは、ＭＮ １３２０の状態は、Ｓ１３０２段階またはＳ１３０４段階で受信された少なくとも一つの政策情報に含まれた第１の条件情報を満足することができる。この場合、第１の条件情報を含む政策情報によって最初のサービスを進行することができる。

最初のサービスのための政策情報は、前記各例のうちいずれか一つによってのみ選択されるものではない。例えば、前記各例のうち一部または全部を組み合わせて最初のサービスのための政策情報を決定することができる。一例として、Ｓ１３０２段階またはＳ１３０４段階において、受信された少なくとも一つの政策情報のうち特定の条件が明示されないものがあり、ＭＮ １３２０の最初の状態がいずれの条件にも該当しない場合、条件が明示されていない政策情報によって最初のサービスを進行することができる。他の例として、Ｓ１３０２段階またはＳ１３０４段階で受信された少なくとも一つの政策情報のうち特定の条件が明示されないものがあり、ＭＮ １３２０が第１の条件情報を満足する場合、第１の条件情報を含む政策情報によって最初のサービスを進行することができる。

Ｓ１３１２段階において、ＭＮ １３２０がＳ１３０２またはＳ１３０４段階で受信された少なくとも一つの政策情報に含まれた更に他の第２の条件情報を満足することができる。例えば、ＭＮ １３２０が最初の状態（例えば、Ｓ１３１０段階で適用された少なくとも一つの政策情報に含まれた条件に該当する状態）と異なる条件状態に該当し得る。例えば、第２の条件情報が指示する状態は、ＭＮ １３２０の残余電力量が特定の状態（例えば、Ｙ％未満）に該当する場合を含むことができる。

Ｓ１３１４段階において、ＭＮ １３２０は、Ｓ１３１２段階で検出された状態変化を購読資源（例えば、購読資源内のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性）に明示されたエンティティ（またはＭ２Ｍデバイス）に伝達または通知することができる。この場合、政策情報資源の範囲（Ｓｃｏｐｅ）と同一のエンティティに伝達または通知することができる。例えば、購読資源（例えば、購読資源のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性）に明示されたエンティティ（またはＭ２Ｍデバイス）の範囲は、Ｓ１３０２またはＳ１３０４段階で受信された少なくとも一つの政策情報に含まれた範囲情報が指示するエンティティ（またはＭ２Ｍデバイス）と同一であり得る。この場合、ＭＮ １３２０が伝送する通知は、条件と関連したり、及び／または政策と関連する識別情報を含むことができる。例えば、前記条件と関連したり、及び／または政策と関連する識別情報は、該当の政策情報を含む資源の住所（例えば、ＵＲＩ）または他の識別子を含むことができる。

Ｓ１３１６段階において、通知を受けた政策の範囲に含まれたエンティティ（またはＭ２Ｍデバイス）は、要求と関連する政策（例えば、基本政策または制限政策）を行う。要求と関連する政策は、基本政策情報または制限政策情報によって行うことができる。あるいは、要求と関連する政策は、Ｓ１３１４段階で受信された通知に含まれた識別情報が指示する政策情報によって行うことができる。例えば、制限政策情報に含まれた条件情報が、ＭＮ １３２０の残余電力量が特定の状態（例えば、Ｘ％未満）に該当することを指示する場合、通知を受けた政策の範囲に含まれたエンティティ（またはＭ２Ｍデバイス）は、新規の要求制限政策を施行することによってＭＮ １３２０に伝送される要求を制限する動作（例えば、重要度Ｘ以上のイベントカテゴリーを有する要求のみを伝送）を行うことができる。これを通じて、ＭＮ １３２０の通信のために使用される電力消費を防止し、サービス持続性を維持することができる。

Ｓ１３１８段階において、ＭＮ １３２０の変更された条件による新規の政策に従うサービスが動作する。この場合、新規の政策は、基本政策または制限政策を含むことができる。

Ｓ１３２０段階において、Ｓ１３０２またはＳ１３０４段階で受信された少なくとも一つの政策情報に含まれた更に他の第３の条件情報を満足することができる。すなわち、ＭＮ １３２０の状態は、Ｓ１３１８段階で適用された少なくとも一つの政策情報に含まれた状態条件（第２の条件情報に該当）と異なる条件状態に該当し得る。例えば、ＭＮ １３２０の残余電力量が特定の状態（例えば、Ｙ％未満）に該当した後、充電を通じて電力が不足な状態から脱することができる（例えば、Ｘ％以上に上昇し得る）。

Ｓ１３２２段階において、ＭＮ １３２０は、Ｓ１３２０段階で検出された状態変化を購読資源（例えば、購読資源内のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性）に明示されたエンティティ（またはＭ２Ｍデバイス）に伝達または通知することができる。この場合、政策情報資源の範囲と同一のエンティティに伝達または通知する。例えば、購読資源（例えば、購読資源のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性）に明示されたエンティティ（またはＭ２Ｍデバイス）の範囲は、Ｓ１３０２またはＳ１３０４段階で受信された少なくとも一つの政策情報に含まれた範囲情報が指示するエンティティ（またはＭ２Ｍデバイス）と同一であり得る。この場合、ＭＮ １３２０が伝送する通知は、条件と関連したり、及び／または政策と関連する識別情報を含むことができる。例えば、前記条件と関連したり、及びまたは政策と関連する識別情報は、該当の政策情報を含む資源の住所（例えば、ＵＲＩ）または他の識別子を含むことができる。

Ｓ１３２４段階において、ＭＮ １３２０から通知を受けたエンティティ（またはＭ２Ｍデバイス）は、制限政策によって係留（Ｐｅｎｄｉｎｇ）された要求を処理することができる。この場合、例えば、制限政策情報で係留中の要求を処理する動作属性（例えば、ｐｅｎｄｉｎｇＲｅｑｕｅｓｔ属性）によって係留中の要求を処理することができる。

図１３に例示した各段階及び／または構成は、必要に応じて省略したり、実施したり、修正して実施することができる。例えば、図１３の例によるＭＮ １３２０の状態変化は、残余電力量による状態変化を含むが、ＭＮ １３２０の状態変化は、ＭＮ １３２０がバッテリーを基盤にして動作するのか、それとも、ケーブルを介して連結された電源を基盤にして動作するのかによる状態変化を含むことができる。この場合、ＭＮ １３２０が最初にバッテリーを基盤にして動作するのか、それとも、ケーブル電源を基盤にして動作するのかによってバッテリー基盤の動作のための政策情報及びケーブル電源基盤の動作のための政策情報のうち一つによって最初のサービスを進行することができる。

一例として、Ｓ１３１０段階において、ＭＮ １３２０が自転車の電源を基盤にして動作する場合、ケーブル電源を基盤にした動作のための政策情報によって最初のサービスを進行することができ、ＭＮ １３２０がバッテリー電源を基盤にして動作する場合、バッテリー電源を基盤にした動作のための政策情報によって最初のサービスを進行することができる。この場合、ケーブル電源を基盤にした政策情報は基本政策に設定し、バッテリー電源を基盤にした政策情報は制限政策に設定することができる。

また、例えば、ＭＮ １３２０が最初に自転車の電源ケーブルに連結されることによって、ケーブル電源を基盤にして動作している途中でバッテリー電源に転換される場合、ＭＮ １３２０は、Ｓ１３１２段階でこのような状態変化を感知し、Ｓ１３１４段階で検出された状態変化を購読資源に明示されたエンティティ（またはＭ２Ｍデバイス）に伝達または通知することができる。この場合、Ｓ１３１６段階において、通知を受けたエンティティ（またはＭ２Ｍデバイス）は、バッテリー電源を基盤にした動作のための政策情報によってサービスを行うことができる。バッテリー電源を基盤にした政策情報による場合、エンティティ（またはＭ２Ｍデバイス）は、ＭＮ １３２０に伝送される要求を制限することができる。これを通じて、ＭＮ １３２０の通信のために使用される電力消費を減少させ、サービス持続性を維持することができる。

また、ＭＮ １３２０がバッテリー電源を基盤にして動作している途中で、再び電源ケーブルに連結されることによってケーブル電源を基盤にした動作に転換される場合、ＭＮ １３２０は、Ｓ１３２０段階でこのような状態変化を感知し、Ｓ１３２２段階で検出された状態変化を購読資源に明示されたエンティティ（またはＭ２Ｍデバイス）に伝達または通知することができる。この場合、通知を受けたエンティティ（またはＭ２Ｍデバイス）は、Ｓ１３２４段階でバッテリー電源を基盤にした政策を行うことによって、係留された要求を動作属性によって処理することができる。

更に他の例において、バッテリー電源を基盤にした政策情報とケーブル電源を基盤にした政策情報などの２個の政策情報が適用可能である場合、二つのうち一つの政策情報を基本政策情報に設定し、他の政策情報を制限政策情報に設定した後、ＭＮ １３２０の状態変化に従って基本政策情報の使用の有無に対する通知をエンティティ（またはＭ２Ｍデバイス）に伝達することができる。この例において、ＭＮ １３２０が制限政策情報の適用のための状態から基本政策情報の適用のための状態に転換される場合、ＭＮ １３２０は、制限政策情報を無視することを指示する通知をエンティティ（またはＭ２Ｍデバイス）に伝達したり、基本政策情報に復帰することを指示する通知をエンティティ（またはＭ２Ｍデバイス）に伝達することができる。

図１４は、本発明に係る基本政策情報を例示する。要求に対する基本政策情報は、基本政策情報のための資源に格納できるが、例えば、＜ｒｅｑｕｅｓｔＤｅｆａｕｌｔｓ＞資源に格納することができる。基本政策情報のための資源は、ローカルエンティティ（またはＭ２Ｍデバイス）（例えば、１３１０）が伝送できる要求に対する基本値（Ｄｅｆａｕｌｔ ｖａｌｕｅ）を指示する情報を含むことができる。基本政策情報のための資源タイプ（例えば、＜ｒｅｑｕｅｓｔＤｅｆａｕｌｔｓ＞）は、ローカルエンティティ（またはＭ２Ｍデバイス）（例えば、１３１０）やＣＳＦによって発生する要求で各属性に対して如何なる値も指示されないとき、ＣＭＤＨ関連パラメーターに使用できる基本値を示すのに使用することができる。また、基本政策情報は、基本政策情報が適用される条件を指示する条件情報を含むことができる。この場合、特定のノード（例えば、ホスティングＣＳＥまたはこれを含むノード）の状態が条件情報の条件を満足するか否かによって要求に対する基本値が異なる形に変更され得る。

図１４を参照すると、基本政策情報のための資源は、範囲情報（例えば、ｓｃｏｐｅ）、基本イベントカテゴリー情報（例えば、ｄｅｆａｕｌｔＥｖｅｎｔＣａｔｅｇｏｒｙ）、及び基本寿命情報（例えば、ｄｅｆａｕｌｔＬｉｆｅＳｐａｎ）を含むことができる。基本イベントカテゴリー情報と基本寿命情報は、基本値を示す情報である。図１４に例示していないが、基本政策情報のための資源は、基本政策資源が適用される条件情報を含むことができる。この場合、条件情報（例えば、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ）は、モニタリング対象情報の住所情報（例えば、＜ｌｉｎｋ＞）と、条件に該当するか否かを示す基準情報（例えば、＜ｃｒｉｔｅｒｉａ＞）を含むことができる。範囲情報（例えば、ｓｃｏｐｅ）は、基本政策情報が適用されるアプリケーションインスタンスまたはエンティティの識別情報（例えば、ＩＤ）を含むことができる。基本イベントカテゴリー情報（例えば、ｄｅｆａｕｌｔＥｖｅｎｔＣａｔｅｇｏｒｙ）は、範囲情報に明示されたデバイスによって発生した要求でイベントカテゴリーが明示されていない場合に使用される基本値を示す。例えば、範囲情報（例えば、ｓｃｏｐｅ）に明示されたエンティティ（またはＭ２Ｍデバイス）のうち一つが特定の条件（例えば、基本政策資源の条件情報に該当する条件）で要求メッセージを伝送するとき、イベントカテゴリーに対して如何なる値も明示されない場合、基本イベントカテゴリー情報（例えば、ｄｅｆａｕｌｔＥｖｅｎｔＣａｔｅｇｏｒｙ）の値を該当の値に設定することができる。基本寿命情報（例えば、ｄｅｆａｕｌｔＬｉｆｅＳｐａｎ）は、範囲情報に明示されたデバイスによって発生した要求で寿命（ｌｉｆｅ ｓｐａｎ）が明示されていない場合に使用される基本値を示す。

例えば、基本政策情報のための資源は、表２に例示した情報（または属性情報）を含むことができる。表２において、Ｒ／Ｗは、該当の属性の読み取り／書き込みの許容の有無を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表２において、発生回数は、該当の属性が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源で発生可能な回数を示す。

表２に例示したａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎは、表３のａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎと区別するためにｄｅｆａｕｌｔＡｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ（ｄＡＣ）と称することができる。

図１５は、本発明に係る制限政策情報を例示する。要求に対する制限政策情報は、制限政策情報のための資源に格納できるが、例えば、＜ｒｅｑｕｅｓｔＬｉｍｉｔｓ＞資源に格納することができる。制限政策情報のための資源（例えば、＜ｒｅｑｕｅｓｔＬｉｍｉｔｓ＞資源）は、ＣＭＤＨ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ Ｄｅｌｉｖｅｒｙ Ｈａｎｄｌｉｎｇ）機能と関連するパラメーター（例えば、イベントカテゴリーと寿命関連パラメーター）の制限を定義する。該当の制限は、該当のノードが保有または登録した（ｒｅｇｉｓｔｅｒｅｄ）ＡＥとＣＳＥで発生した要求に適用される。制限政策情報のための資源は、ローカルエンティティ（またはＭ２Ｍデバイス）（例えば、１３１０）が各ＣＭＤＨ関連パラメーターを有する要求を送るとき、各ＣＭＤＨ関連パラメーターを検証するのに使用される制限範囲（ｌｉｍｉｔ ｒａｎｇｅ）を示すことができる。例えば、要求が制限範囲外のＣＭＤＨ関連パラメーターを有する場合、前記要求は拒絶され得る。また、制限政策情報は、制限政策情報が適用される条件を指示する条件情報を含むことができる。この場合、特定のノード（例えば、ホスティングＣＳＥまたはこれを含むノード）の状態が条件情報の条件を満足するか否かによって、前記要求に対する制限政策が異なる形に変更され得る。

図１５を参照すると、制限政策情報のための資源は、範囲情報（例えば、ｓｃｏｐｅ）、条件情報（例えば、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ）、係留中の要求の処理方式に関する情報（例えば、ｐｅｎｄｉｎｇＲｅｑｕｅｓｔ）、イベントカテゴリーの範囲情報（例えば、ｒａｎｇｅＥｖｅｎｔＣａｔｅｇｏｒｙ）、及び寿命の範囲情報（例えば、ｒａｎｇｅＬｉｆｅＳｐａｎ）を含むことができる。範囲情報（例えば、ｓｃｏｐｅ）は、制限政策情報が適用されるアプリケーションインスタンスまたはエンティティの識別情報（例えば、ＩＤ）を含むことができる。条件情報（例えば、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ）は、モニタリング対象情報の住所情報（例えば、＜ｌｉｎｋ＞）と、条件に該当するか否かを示す基準情報（例えば、＜ｃｒｉｔｅｒｉａ＞）を含むことができる。モニタリング対象情報は、Ｍ２Ｍデバイスの属性情報を格納するための資源内でモニタリング対象装置の特定の情報を称することができる（例えば、図１７参照）。係留中の要求の処理方式に関する情報（例えば、ｐｅｎｄｉｎｇＲｅｑｕｅｓｔ）は、Ｍ２Ｍゲートウェイまたはデバイスに伝達できずに係留中の要求の処理方式を定義する。例えば、係留中の要求を処理する方式は、全ての係留中の要求を伝送すること、最も最近の要求を伝送すること、特定の範囲のイベントカテゴリー値を有する要求または特定の範囲の寿命を有する要求を伝送すること、または、次の政策によって要求を処理することを含むことができる。イベントカテゴリーの範囲情報（例えば、ｒａｎｇｅＥｖｅｎｔＣａｔｅｇｏｒｙ）は、範囲情報に明示されたデバイスによって発生した要求（または要求のイベントカテゴリー）の許容範囲を指示する。寿命の範囲情報（例えば、ｒａｎｇｅＬｉｆｅＳｐａｎ）は、範囲情報に明示されたデバイスによって発生した要求（または要求の寿命）の許容範囲を指示する。

例えば、制限政策情報のための資源は、表３に例示した情報（または属性情報）を含むことができる。表３において、Ｒ／Ｗは、該当の属性の読み取り／書き込みの許容有無を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表３において、発生回数は、該当の属性が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源で発生可能な回数を示す。表３において、Ａｐｐ―Ｉｎｓｔ―ＩＤは、アプリケーションインスタンスＩＤを示す。

図１６は、本発明によって制限政策情報を購読資源にマッピングする例を示す。

本発明によると、特定のデバイス（例えば、ＭＮ １３２０）の状態変化に従って他のデバイス（例えば、ＡＥ １３１０）の政策を変化させることによって、Ｍ２Ｍサービス設定を変更することができる。このために、他のデバイスに特定のデバイスの状態変化を通知しなければならないが、この場合、購読資源を利用することができる。購読資源は、基本及び制限政策情報に含まれた条件情報と範囲情報を用いて生成することができる。基本及び制限政策情報が条件情報を含むと仮定すると、例えば、政策を所有した特定のデバイス（例えば、ＭＮ １３２０）が制限政策情報のための資源（例えば、＜ｒｅｑｕｅｓｔＬｉｍｉｔ＞資源）を購読資源（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源）にマッピングし、購読資源を生成することができる。また、定義した政策を基盤にして政策情報を生成するエンティティ（例えば、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）、Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍシステム）で全体のサービス政策を管理する政策管理者、またはＭＮノードの内部にあるＡＥ）が該当の購読情報を生成することができる。

前記購読資源が生成されるとき、マッピング規則は次の通りである。例えば、制限政策情報のための資源において、範囲情報のための資源（例えば、＜ｓｃｏｐｅ＞資源）を購読資源の通知住所情報のための資源（例えば、＜ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ＞資源）にマッピングすることができる。また、例えば、条件情報（例えば、＜ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ＞）において、モニタリング対象情報の住所情報（例えば、＜ｌｉｎｋ＞）は購読資源の生成位置にマッピングすることができる（購読される状態に対するモニタリングイシュー連関関係がある。）。また、例えば、条件情報（例えば、ａｓｓｏｃｉａｔｅｄＣｏｎｄｉｔｉｏｎ）の基準情報（例えば、＜ｃｒｉｔｅｒｉａ＞）（詳細条件の基準値）は、購読資源の基準値情報（例えば、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）にマッピングすることができる。結論的には、該当の政策の内部情報の資源と購読情報の資源とをペアリング（Ｐａｒｉｎｇ）し、該当の政策が購読しているデバイス（またはエンティティ）の状態に応じて変動できるように設定することができる。

図１７は、本発明に係るＭ２Ｍデバイスの属性情報を格納するための資源構造を例示する。Ｍ２Ｍデバイスが一つのノードとして表現できるので、Ｍ２Ｍデバイスの属性情報を格納する資源はノード資源（ｎｏｄｅ ｒｅｓｏｕｒｃｅ）と称することができる。ノード資源は、他のＭ２Ｍ動作（例えば、ｏｎｅＭ２Ｍ動作）によって活用できるＭ２Ｍノードの特定の情報を示す。例えば、ソースＣＳＥがターゲットＣＳＥに要求メッセージを伝送するとき、ソースＣＳＥのＣＭＤＨ ＣＳＦは、ターゲットＣＳＥの到達可能スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）を基盤にしていつターゲットＣＳＥに要求メッセージを伝送するかを決定することができる。ノード資源は、到達可能スケジュール、コンテキスト情報（例えば、メモリ及び格納装置（ｓｔｏｒａｇｅ））、及びネットワークトポロジー（ｎｅｔｗｏｒｋ ｔｏｐｏｌｏｇｙ）などのＭ２Ｍノード（またはデバイス）の性質に対する情報を含むことができる。

ノード資源の位置は、ノードのタイプによって変わり得る。例えば、ＡＳＮは、ローカルＣＳＥの＜ｂａｓｅＵＲＩ＞の下に位置し得る。また、例えば、ＡＤＮは、ホスティングＣＳＥの＜Ａｐｐｌｉｃａｔｉｏｎ＞資源の下に位置し得る。また、例えば、ＭＮは、ローカルＣＳＥの＜ｂａｓｅＵＲＩ＞の下に位置し得る。

図１７を参照すると、ノード資源は、多様な属性情報及び子資源を含むことができる。例えば、ノード資源は、属性情報としてノード識別情報（例えば、ｎｏｄｅＩＤ）を含むことができる。また、例えば、ノード資源は、メモリと関連する資源（例えば、＜ｍｅｍｏｒｙ＞資源）、格納装置と関連する資源（例えば、＜ｓｔｏｒａｇｅ＞資源）、電力（ｐｏｗｅｒ）と関連する資源（例えば、＜ｐｏｗｅｒ＞資源）、ネットワークトポロジーと関連する資源（例えば、＜ｎｅｔｗｏｒｋＴｏｐｏｌｏｇｙ＞資源）、及び／またはスケジュールと関連する資源（例えば、＜ｓｃｈｅｄｕｌｅ＞資源）を含むことができる。図１７において、属性情報と子資源の横の数字は、発生回数を示す。発生回数が０〜１である場合は選択事項であり得る（ｏｐｔｉｏｎａｌ）。

表４は、ノード資源の子資源を表に示したものである。

表４において、＜ｍｇｍｔＯｂｊ＞資源タイプは、個別的なＭ２Ｍ管理機能を示す管理データを含み、各外部管理技術（例えば、ＯＭＡ ＤＭ、ＢＢＦ ＴＲ―０６９、ＬＷＭ２Ｍ）データモデルにマッピングするための一般的な構造を示す。メモリ及び格納装置などのノード特定の情報は、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）標準規格による装置管理技術または他の方法（例えば、ＪＮＩ（Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ））を通じて獲得することができる。＜ｍｇｍｔＯｂｊ＞資源タイプは、前記二つの方法を含む管理機能を示すので、下位資源のタイプは＜ｍｇｍｔＯｂｊ＞資源タイプである。

図１８は、本発明に係るＭ２Ｍサービス設定変更動作を例示する。

図１８のＳ１２０４段階〜Ｓ１２２０段階に対する説明は、図１２のＳ１２０４段階〜Ｓ１２２０段階と同一である。したがって、図１２に対する説明を参照して援用する。

図１２の例とは異なり、Ｓ１８２２段階において、スマートフォン１１２０の状態が特定の状態に該当する場合、スマートフォン１１２０は、状態変化をＭ２Ｍサービスプラットフォーム１１３０に報告することができる。特定の状態は、ゲートウェイまたは端末で故障や不良が予想される場合を含むことができる。具体的には、例えば、特定の状態は、ゲートウェイまたは端末の残余バッテリーが低い場合（例えば、残余バッテリー量が全体のＸ％以下である場合）、バッテリー放電が予想される場合、位置や速度などの情報を通じて連結が喪失すると予想される場合、または、多様なトリガーを通じてサービスを正常に行えないと予想される場合を含むことができる。前記の例示した場合に該当すると、ゲートウェイまたは端末は、自身の状態を含んで、警告メッセージをＭ２Ｍサービスプラットフォーム１１３０に伝達することができる。

Ｓ１８２４段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、自転車提供者１１４０と各センサー１１１０のＭ２Ｍサービス設定をバッテリー消耗を減少させるように変更することができる。例えば、Ｍ２Ｍサービスプラットフォーム１１３０は、サービス設定を「ｏｎｌｙ ｅｍｅｒｇｅｎｃｙ ｃａｓｅ」に変更することができる。この場合、緊急要求メッセージのみを各センサー１１１０を介して発信することができ、他の場合は、サービスの最後にバッチモード（Ｂａｔｃｈ Ｍｏｄｅ）で通知することができる。

あるいは、Ｍ２Ｍサービスプラットフォーム１１３０は、ゲートウェイや端末の状態を把握した後、サービス持続性を維持するためにサービス設定を変更するようにゲートウェイや端末に命令することができる。例えば、正常報告の場合（Ｓ１２０８、Ｓ１２１２、Ｓ１２１６段階参照）、報告の形態をバッチモードまたは準―リアルタイムモード（Ｑｕａｓｉ―Ｒｅａｌ Ｍｏｄｅ）に変更する。バッチモードは、ゲートウェイや端末が伝送するデータがあるが、リアルタイム（Ｒｅａｌ―ｔｉｍｅ）で伝送または伝達せずに係留させていながら、サービスが終了する時点で係留されたデータを伝達するモードを称する。準―リアルタイムモードは、ゲートウェイや端末が伝送するデータがあるが、リアルタイムで伝送または伝達せずに係留させ、ゲートウェイや端末がサービス持続性を維持できる状態に回復する場合、係留されたデータをリアルタイムで送るモードを称する。対照的に、例えば、緊急報告の場合（例えば、Ｓ１８２２参照）、報告する形態を変更しない。

Ｓ１８２６段階において、自転車ユーザーは、目的地に到着し、指定された場所に自転車を駐車することができる。この場合、各センサー１１１０は、累積された情報と正常イベント購読情報をスマートフォン１１２０を介してＭ２Ｍサービスプラットフォーム１１３０に報告することができる。

Ｓ１８２８段階において、Ｍ２Ｍサービスプラットフォーム１１３０は、共有自転車の使用量（ｕｓａｇｅ）を自転車提供者１１４０とヘルスサービス提供者１１５０に通知することができる。

図１８の例において、Ｍ２Ｍゲートウェイとして動作するスマートフォン１１２０とＭ２Ｍサービスプラットフォーム１１３０が別個のエンティティであると記述されているが、他の例においては、Ｍ２ＭゲートウェイがＭ２Ｍサービスプラットフォーム１１３０としての役割をすることも可能である。

図１９は、本発明が適用され得る装置を例示するブロック図である。本発明において、Ｍ２Ｍゲートウェイ、Ｍ２ＭサーバーまたはＭ２Ｍデバイスは、それぞれ伝送装置１０または受信装置２０として動作することができる。

伝送装置１０と受信装置２０は、情報及び／またはデータ、信号、メッセージなどを運ぶ無線信号を伝送または受信できるＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニット１３、２３と、無線通信システム内の通信と関連する各種情報を格納するメモリ１２、２２と、前記ＲＦユニット１３、２３及びメモリ１２、２２などの構成要素と動作時に連結（ｏｐｅｒａｔｉｖｅｌｙ ｃｏｎｎｅｃｔｅｄ）され、前記構成要素を制御し、該当の装置が上述した本発明の各実施例のうち少なくとも一つを行うようにメモリ１２、２２及び／またはＲＦユニット１３、２３を制御するように構成されたプロセッサ１１、２１とをそれぞれ含む。

メモリ１２、２２は、プロセッサ１１、２１の処理及び制御のためのプログラムを格納することができ、入／出力される情報を格納することができる。メモリ１２、２２をバッファーとして活用することができる。また、メモリ１２、２２は、各種設定情報及びデータを含む資源を格納するのに使用することができる。

プロセッサ１１、２１は、通常、伝送装置または受信装置内の各種モジュールの全般的な動作を制御する。特に、プロセッサ１１、２１は、本発明を行うための各種制御機能を行うことができる。プロセッサ１１、２１は、コントローラー（ｃｏｎｔｒｏｌｌｅｒ）、マイクロコントローラー（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコンピューター（ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などと称することもできる。プロセッサ１１、２１は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの結合によって具現することができる。ハードウェアを用いて本発明を具現する場合は、本発明を行うように構成されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ）またはＤＳＰｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）などをプロセッサ１１、２１に備えることができる。一方、ファームウェアやソフトウェアを用いて本発明を具現する場合は、本発明の機能または各動作を行うモジュール、手順または関数などを含むようにファームウェアやソフトウェアを構成することができ、本発明を行えるように構成されたファームウェアまたはソフトウェアは、プロセッサ１１、２１内に備えられたり、メモリ１２、２２に格納されてプロセッサ１１、２１によって駆動され得る。

伝送装置１０のプロセッサ１１は、前記プロセッサ１１または前記プロセッサ１１と連結されたスケジューラーからスケジューリングされ、外部に伝送される信号及び／またはデータに対して所定の符号化（ｃｏｄｉｎｇ）及び変調（ｍｏｄｕｌａｔｉｏｎ）を行った後、これら信号及び／またはデータをＲＦユニット１３に伝送する。受信装置２０の信号処理過程は、伝送装置１０の信号処理過程と逆に構成される。プロセッサ２１の制御下で、受信装置２０のＲＦユニット２３は、伝送装置１０によって伝送された無線信号を受信する。前記プロセッサ２１は、受信アンテナを介して受信された無線信号に対する復号（ｄｅｃｏｄｉｎｇ）及び復調（ｄｅｍｏｄｕｌａｔｉｏｎ）を行い、伝送装置１０が本来伝送しようとしていたデータを復元することができる。

ＲＦユニット１３、２３は、一つ以上のアンテナを備える。アンテナは、プロセッサ１１、２１の制御下で、本発明の一実施例によって、ＲＦユニット１３、２３によって処理された信号を外部に伝送したり、外部から無線信号を受信してＲＦユニット１３、２３に伝達する機能を行う。図９において、送信装置と受信装置がそれぞれＲＦユニットを介して通信することが示されているが、送信装置と受信装置が有線ネットワークを介して通信することも可能である。この場合、ＲＦユニットは、ネットワークインターフェースユニット（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｕｎｉｔ、ＮＩＵ）に取り替えることができる。

以上で説明した各実施例は、本発明の各構成要素と各特徴が所定の形態で結合されたものである。各構成要素または特徴は、別途の明示的な言及がない限り、選択的なものとして考慮しなければならない。各構成要素または特徴は、他の構成要素や特徴と結合されない形態で実施することができる。また、一部の構成要素及び／または特徴を結合して本発明の実施例を構成することも可能である。本発明の各実施例で説明する各動作の順序は変更可能である。いずれかの実施例の一部の構成や特徴は、他の実施例に含ませることができ、または、他の実施例の対応する構成または特徴に取り替えることができる。特許請求の範囲で明示的な引用関係のない各請求項を結合して実施例を構成したり、出願後の補正によって新たな請求項として含ませ得ることは自明である。

本文書において、基地局によって行われると説明した特定の動作は、場合に応じては、その上位ノード（ｕｐｐｅｒ ｎｏｄｅ）によって行うことができる。すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ ｎｏｄｅｓ）からなるネットワークで端末との通信のために行われる多様な動作は、基地局または基地局以外の他のネットワークノードによって行われ得ることは自明である。基地局は、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）、Ｎｏｄｅ Ｂ、ｅＮｏｄｅ Ｂ（ｅＮＢ）、アクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ）などの用語に取り替えることができる。また、端末は、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）などの用語に取り替えることができる。

本発明に係る実施例は、多様な手段、例えば、ハードウェア、ファームウェア、ソフトウェア、またはそれらの結合などによって具現することができる。ハードウェアによる具現の場合、本発明の一実施例は、一つまたはそれ以上のＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）、プロセッサ、コントローラー、マイクロコントローラー、マイクロプロセッサなどによって具現することができる。

ファームウェアやソフトウェアによる具現の場合、本発明は、以上で説明した機能または各動作を行うモジュール、手順、関数などの形態を含むソフトウェアコードまたは命令語（ｉｎｓｔｒｕｃｔｉｏｎ）で具現することができる。ソフトウェアコードまたは命令語は、コンピューターで判読可能な媒体に格納し、プロセッサによって駆動することができ、プロセッサによって駆動されるとき、本発明に係る各動作を行うことができる。前記コンピューターで判読可能な媒体は、前記プロセッサの内部または外部に位置したり、遠隔でネットワークを介して前記プロセッサと連結することができ、前記プロセッサとデータを取り交わすことができる。

本発明は、本発明の特徴から逸脱しない範囲で他の特定の形態に具体化できることは当業者にとって自明である。したがって、前記の詳細な説明は、全ての面で制限的に解釈してはならなく、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的解釈によって決定しなければならなく、本発明の等価的範囲内での全ての変更は本発明の範囲に含まれる。

本発明は、端末、サーバー、ゲートウェイなどの通信装置に使用することができる。

Claims (10)

1. Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）システムでＭ２Ｍゲートウェイが状態変化を通知する方法であって、
   前記Ｍ２Ｍゲートウェイが、ポリシ情報を格納するステップであって、前記ポリシ情報は、制限ポリシ情報が適用される１以上のデバイスを示す範囲情報（ｓｃｏｐｅ ｉｎｆｏｒｍａｔｉｏｎ）を含む制限ポリシ情報と、前記１以上のデバイスの要求のイベントカテゴリーパラメータに対する許容値を示す許容イベントカテゴリーセット（ａｌｌｏｗｅｄ ｅｖｅｎｔ ｃａｔｅｇｏｒｙ ｓｅｔ）と、前記制限ポリシ情報が適用される条件を示す条件情報（ｃｏｎｄｉｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含む、ステップと、
   前記範囲情報により示される前記１以上のデバイスへ第２の通知を伝送するステップであって、前記第２の通知は前記許容イベントカテゴリーセットを含む、ステップと、
   前記Ｍ２Ｍゲートウェイが、前記条件情報により示される前記Ｍ２Ｍゲートウェイの状態変化を検出する場合、前記１以上のデバイスに前記Ｍ２Ｍゲートウェイの状態変化を示す第１の通知を伝送するステップを含み、
   前記要求が前記許容イベントカテゴリーセットの中のイベントカテゴリーパラメータ値を有するか否かによって、前記１以上のデバイスの要求が伝送されるか否かが、前記１以上のデバイスにより決定される、方法。
2. 前記第１の通知は、前記ポリシ情報に対応する識別情報を含み、
   前記範囲情報が示す前記１以上のデバイスが前記第１の通知を受信する場合、前記１以上のデバイスは、前記識別情報が示す前記ポリシ情報によってＭ２Ｍサービスを行う、請求項１に記載の方法。
3. 前記ポリシ情報は基本ポリシ情報を含み、前記基本ポリシ情報は、前記１以上のデバイスの前記要求の前記イベントカテゴリーパラメータに対する基本値(default value)を含む、請求項１に記載の方法。
4. 通知購読のための資源を生成するステップをさらに含み、
   前記通知購読のための資源は、前記Ｍ２Ｍゲートウェイにより前記条件情報に基づいて生成される、請求項１に記載の方法。
5. 前記通知購読のための資源は、前記通知が伝送されるデバイスの住所に対する第１の情報と、前記通知を行う基準値に対する第２の情報と、を含み、
   前記通知購読のための資源を生成するステップは、前記範囲情報を前記第１の情報にマッピングし、前記条件情報が示す状態の値を前記第２の情報にマッピングするステップを含む、請求項４に記載の方法。
6. 前記条件情報は、モニタリング対象情報の住所情報と、前記条件に該当するか否かを示す基準情報と、を含む、請求項１に記載の方法。
7. 前記第２の通知は、要求の処理方式を示す情報をさらに含む、請求項１に記載の方法。
8. 前記要求の処理方式は、全ての係留中の要求を伝送するステップ、最も最近の要求を伝送するステップ、特定の範囲のイベントカテゴリーパラメータを有する要求または特定の範囲の寿命を有する要求を伝送するステップ、または、次のポリシによって要求を処理するステップの少なくとも一つを含む、請求項７に記載の方法。
9. 前記基本ポリシ情報は、前記１以上のデバイスの要求に対する基本属性と、前記基本ポリシ情報が適用される前記Ｍ２Ｍゲートウェイの状態を含み、
   前記Ｍ２Ｍゲートウェイの状態は前記基本ポリシ情報が適用される前記Ｍ２Ｍゲートウェイの状態に対応し、前記１以上のデバイスの要求の特定属性が指定されない場合、前記基本ポリシ情報に含まれる前記基本属性が適用される、請求項３に記載の方法。
10. Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）システムのＭ２Ｍゲートウェイにおいて、前記Ｍ２Ｍゲートウェイは、
    ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｕｎｉｔ）と、
    プロセッサと、を含み、
    前記プロセッサは、前記Ｍ２Ｍゲートウェイで、制限ポリシ情報が適用される１以上のデバイスを示す範囲情報を含む制限ポリシ情報と、前記１以上のデバイスの要求のイベントカテゴリーパラメータに対する許容値を示す許容イベントカテゴリーセット（ａｌｌｏｗｅｄ ｅｖｅｎｔ ｃａｔｅｇｏｒｙ ｓｅｔ）と、前記制限ポリシ情報が適用される条件を示す条件情報を含むポリシ情報を格納し、
    前記格納された範囲情報により示される前記１以上のデバイスへ、前記ネットワークインターフェースユニットを介して前記許容イベントカテゴリーセットを含む第２の通知を伝送し、
    前記Ｍ２Ｍゲートウェイが、前記条件情報により示される前記Ｍ２Ｍゲートウェイの状態変化を検出する場合、前記Ｍ２Ｍゲートウェイの状態変化を示す第１の通知を、前記ネットワークインターフェースユニットを介して１以上のデバイスに伝送するように構成され、
    前記要求が前記許容イベントカテゴリーセットの中のイベントカテゴリーパラメータ値を有するか否かによって、前記１以上のデバイスの要求が伝送されるか否かが、前記１以上のデバイスにより決定される、Ｍ２Ｍゲートウェイ。

Images