(57)【要約】  本発明は、第１リソース及び第２リソースが構成されたＭ２Ｍデバイスで行われる方法及びそのための装置であって、前記第１リソースのフィルタリング属性に第１条件情報を追加するステップと、前記第２リソースに対応するアドレスを示す第１情報及び前記デバイスで行われる動作を示す第２情報を含む要求メッセージを、第１エンティティから受信するステップと、所定の条件を満たす場合、前記第１リソースに設定されたアドレス情報が示す第２エンティティに通知メッセージを送信するステップとを有し、前記所定の条件は、（１）前記第２リソースが前記第１リソースの親リソースに該当する、（２）前記第１条件情報が前記動作に対応する変数を含む、との条件を含み、前記第１リソースと前記第２リソースはそれぞれ、固有のアドレスを用いて固有にアドレシング可能なデータ構造を表す方法、及びそのための装置に関する。【選択図】図１２
2016526322.tif 000002
【特許請求の範囲】
【請求項１】
第１リソース及び第２リソースが構成されたＭ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）デバイスで行われる方法であって、
前記第１リソースのフィルタリング属性に第１条件情報又は第２条件情報を追加するステップと、
前記第２リソースに対応するアドレスを示す第１情報及び前記デバイスで行われる動作を示す第２情報を含む要求メッセージを、第１エンティティから受信するステップと、
所定の条件を満たす場合、前記第１リソースに設定されたアドレス情報が示す第２エンティティに通知メッセージを送信するステップと、
を有し、
前記所定の条件は、
（１）前記第２リソースが前記第１リソースの親リソースに該当する、
（２）前記第１リソースのフィルタリング属性が前記第１条件情報を含む場合、前記第１条件情報が前記動作に対応する変数を含む、
（３）前記第１リソースのフィルタリング属性が前記第２条件情報を含む場合、前記動作によって前記第２リソース又は前記第２リソースの子リソースが変化するとき、前記第２条件情報が前記第２リソース又は前記第２リソースの子リソースの変化した状態に対応する変数を含む、との条件を含み、
前記第１リソースと前記第２リソースはそれぞれ、固有のアドレスを用いて固有にアドレシング可能なデータ構造を表す、方法。
【請求項２】
前記第１条件情報は、前記第２リソース又は前記第２リソースの子リソースをアクセスする動作が行われるか否かにかかわらず、当該動作が試みられるか否かをモニタリングするために用いられる、請求項１に記載の方法。
【請求項３】
前記変数は、生成、回収、更新、削除のうち少なくとも一つを示す、請求項１に記載の方法。
【請求項４】
前記通知メッセージは、前記動作に対応するパラメータを含む、請求項１に記載の方法。
【請求項５】
前記第２条件情報が前記第１リソースのフィルタリング属性に追加される場合、前記通知メッセージは、前記変化した状態に対応するパラメータを含む、請求項１に記載の方法。
【請求項６】
前記所定の条件は、
（４）前記要求メッセージを送信した第２エンティティが前記第２リソースに対して回収権限（ｒｅｔｒｉｅｖｅ  ｐｅｒｍｉｓｓｉｏｎ）を有する、
（５）前記第１エンティティと前記第２エンティティとが異なる場合、前記第１エンティティが前記第２エンティティに通知メッセージを送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有する、との条件をさらに含む、請求項１に記載の方法。
【請求項７】
前記第１リソースは購読のためのリソースに該当し、前記第２リソースは購読対象リソースに該当する、請求項１に記載の方法。
【請求項８】
第１リソース及び第２リソースが構成されたＭ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）デバイスであって、
ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｕｎｉｔ）と、
プロセッサと、を備え、
前記プロセッサは
前記第１リソースのフィルタリング属性に第１条件情報又は第２条件情報を追加し、
前記ネットワークインターフェースユニットを介して、前記第２リソースに対応するアドレスを示す第１情報及び前記デバイスで行われる動作を示す第２情報を含む要求メッセージを、第１エンティティから受信し、
所定の条件を満たす場合、前記ネットワークインターフェースユニットを介して、前記第１リソースに設定されたアドレス情報が示す第２エンティティに通知メッセージを送信するように構成され、
前記所定の条件は、
（１）前記第２リソースが前記第１リソースの親リソースに該当する、
（２）前記第１リソースのフィルタリング属性が前記第１条件情報を含む場合、前記第１条件情報が前記動作に対応する変数を含む、
（３）前記第１リソースのフィルタリング属性が前記第２条件情報を含む場合、前記動作によって前記第２リソース又は前記第２リソースの子リソースが変化するとき、前記第２条件情報が前記第２リソース又は前記第２リソースの子リソースの変化した状態に対応する変数を含む、との条件を含み、
前記第１リソースと前記第２リソースはそれぞれ、固有のアドレスを用いて固有にアドレシング可能なデータ構造を表す、Ｍ２Ｍデバイス。
【請求項９】
前記第１条件情報は、前記第２リソース又は前記第２リソースの子リソースをアクセスする動作が行われるか否かにかかわらず、当該動作が試みられるか否かをモニタリングするために用いられる、請求項８に記載のＭ２Ｍデバイス。
【請求項１０】
前記変数は、生成、回収、更新、削除のうち少なくとも一つを示す、請求項８に記載のＭ２Ｍデバイス。
【請求項１１】
前記通知メッセージは、前記動作に対応するパラメータを含む、請求項８に記載のＭ２Ｍデバイス。
【請求項１２】
前記第２条件情報が前記第１リソースのフィルタリング属性に追加される場合、前記通知メッセージは、前記変化した状態に対応するパラメータを含む、請求項８に記載のＭ２Ｍデバイス。
【請求項１３】
前記所定の条件は、
（４）前記要求メッセージを送信した第２エンティティが前記第２リソースに対して回収権限（ｒｅｔｒｉｅｖｅ  ｐｅｒｍｉｓｓｉｏｎ）を有する、
（５）前記第１エンティティと前記第２エンティティとが異なる場合、前記第１エンティティが前記第２エンティティに通知メッセージを送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有する、との条件をさらに含む、請求項８に記載のＭ２Ｍデバイス。
【請求項１４】
前記第１リソースは購読のためのリソースに該当し、前記第２リソースは購読対象リソースに該当する、請求項８に記載のＭ２Ｍデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）通信システムに関し、特に、Ｍ２Ｍシステムにおいて特定リソースに対して行われる動作を購読して通知する方法及びそのための装置に関する。
【背景技術】
【０００２】
近年、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）通信に関する関心が高まっている。Ｍ２Ｍ通信は人間の介入無しで機械（Ｍａｃｈｉｎｅ）と機械との間に行われる通信を意味し、ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）又はＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）通信とも呼ばれる。Ｍ２Ｍ通信に使われる端末をＭ２Ｍデバイス（Ｍ２Ｍ  ｄｅｖｉｃｅ）と呼ぶが、Ｍ２Ｍデバイスは一般に、低い移動性（ｌｏｗ  ｍｏｂｉｌｉｔｙ）、時間耐性（ｔｉｍｅ  ｔｏｌｅｒａｎｔ）又は遅延耐性（ｄｅｌａｙ  ｔｏｌｅｒａｎｔ）、小さなデータ送信（ｓｍａｌｌ  ｄａｔａ  ｔｒａｎｓｍｉｓｓｉｏｎ）などの特性を有し、機械間の通信情報を中央で保存して管理するＭ２Ｍサーバーと接続して使われる。また、Ｍ２Ｍデバイスが互いに異なる通信方式で接続されると、通信方式が変更される区間でＭ２Ｍゲートウェイを介してＭ２ＭデバイスとＭ２Ｍサーバーとが接続され、これで全体Ｍ２Ｍシステムが構成される。当該システムに基づいてモノの追跡（Ｔｒａｃｋｉｎｇ）、電力計量（Ｍｅｔｅｒｉｎｇ）、自動支払システム（Ｐａｙｍｅｎｔ）、医療分野サービス、遠隔調整などのサービスを提供することができる。
【０００３】
本発明は、Ｍ２Ｍシステムに関する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、Ｍ２Ｍシステムにおいて効率的に信号を送受信する方法及びそのための装置を提供することにある。
【０００５】
本発明の他の目的は、Ｍ２Ｍシステムにおいて特定リソースに対する購読／通知を効率的に行う方法及びそのための装置を提供することにある。
【０００６】
本発明の更に他の目的は、Ｍ２Ｍシステムにおいて特定リソースに対して行われる動作を効率的に購読して通知する方法及びそのための装置を提供することにある。
【０００７】
本発明の更に他の目的は、Ｍ２Ｍシステムにおいて購読対象リソースの状態変化にかかわらず、行われる動作に基づいて購読して通知する方法及びそのための装置を提供することにある。
【０００８】
本発明で遂げようとする技術的課題は、上記の技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとっては明らかになるであろう。
【課題を解決するための手段】
【０００９】
本発明の一態様として、第１リソース及び第２リソースが構成されたＭ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）デバイスで行われる方法が提供され、前記方法は、前記第１リソースのフィルタリング属性に第１条件情報又は第２条件情報を追加するステップと、前記第２リソースに対応するアドレスを示す第１情報及び前記デバイスで行われる動作を示す第２情報を含む要求メッセージを、第１エンティティから受信するステップと、所定の条件を満たす場合、前記第１リソースに設定されたアドレス情報が示す第２エンティティに通知メッセージを送信するステップとを有し、前記所定の条件は、（１）前記第２リソースが前記第１リソースの親リソースに該当する、（２）前記第１リソースのフィルタリング属性が前記第１条件情報を含む場合、前記第１条件情報が前記動作に対応する変数を含む、（３）前記第１リソースのフィルタリング属性が前記第２条件情報を含む場合、前記動作によって前記第２リソース又は前記第２リソースの子リソースが変化するとき、前記第２条件情報が前記第２リソース又は前記第２リソースの子リソースの変化した状態に対応する変数を含む、との条件を含み、前記第１リソースと前記第２リソースはそれぞれ、固有のアドレスを用いて固有にアドレシング可能なデータ構造を表すことができる。
【００１０】
本発明の他の態様として、第１リソース及び第２リソースが構成されたＭ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）デバイスが提供され、前記Ｍ２Ｍデバイスは、ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｕｎｉｔ）と、プロセッサとを備え、前記プロセッサは、前記第１リソースのフィルタリング属性に第１条件情報又は第２条件情報を追加し、前記ネットワークインターフェースユニットを介して、前記第２リソースに対応するアドレスを示す第１情報及び前記デバイスで行われる動作を示す第２情報を含む要求メッセージを、第１エンティティから受信し、所定の条件を満たす場合、前記ネットワークインターフェースユニットを介して、前記第１リソースに設定されたアドレス情報が示す第２エンティティに通知メッセージを送信するように構成され、前記所定の条件は、（１）前記第２リソースが前記第１リソースの親リソースに該当する、（２）前記第１リソースのフィルタリング属性が前記第１条件情報を含む場合、前記第１条件情報が前記動作に対応する変数を含む、（３）前記第１リソースのフィルタリング属性が前記第２条件情報を含む場合、前記動作によって前記第２リソース又は前記第２リソースの子リソースが変化するとき、前記第２条件情報が前記第２リソース又は前記第２リソースの子リソースの変化した状態に対応する変数を含む、との条件を含み、前記第１リソースと前記第２リソースはそれぞれ、固有のアドレスを用いて固有にアドレシング可能なデータ構造を表すことができる。
【００１１】
好適には、前記第１条件情報は、前記第２リソース又は前記第２リソースの子リソースをアクセスする動作が行われるか否かにかかわらず、当該動作が試みられるか否かをモニタリングするために用いられてもよい。
【００１２】
好適には、前記変数は、生成、回収、更新、削除のうち少なくとも一つを示すことができる。
【００１３】
好適には、前記通知メッセージは、前記動作に対応するパラメータを含むことができる。
【００１４】
好適には、前記第２条件情報が前記第１リソースのフィルタリング属性に追加される場合、前記通知メッセージは、前記変化した状態に対応するパラメータを含むことができる。
【００１５】
好適には、前記所定の条件は、（４）前記要求メッセージを送信した第２エンティティが前記第２リソースに対して回収権限（ｒｅｔｒｉｅｖｅ  ｐｅｒｍｉｓｓｉｏｎ）を有する、（５）前記第１エンティティと前記第２エンティティとが異なる場合、前記第１エンティティが前記第２エンティティに通知メッセージを送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有する、との条件をさらに含むことができる。
【００１６】
好適には、前記第１リソースは購読のためのリソースに該当し、前記第２リソースは購読対象リソースに該当してもよい。
【発明の効果】
【００１７】
本発明によれば、Ｍ２Ｍシステムにおいて効率的に信号を送受信することができる。
【００１８】
また、本発明によれば、Ｍ２Ｍシステムにおいて特定リソースに対する購読／通知を効率的に行うことができる。
【００１９】
また、本発明によれば、Ｍ２Ｍシステムにおいて特定リソースに対して行われる動作を効率的に購読して通知することができる。
【００２０】
また、本発明によれば、Ｍ２Ｍシステムにおいて購読対象リソースの状態変化にかかわらず、行われる動作に基づいて購読して通知することができる。
【００２１】
本発明から得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者には明確に理解されるであろう。
【図面の簡単な説明】
【００２２】
【図１】Ｍ２Ｍシステムを例示する。
【図２】Ｍ２Ｍシステムの階層構造（ｌａｙｅｒｅｄ  ｓｔｒｕｃｔｕｒｅ）を例示する。
【図３】Ｍ２Ｍシステムの機能的アーキテクチャー（ｆｕｎｃｔｉｏｎａｌ  ａｒｃｈｉｔｅｃｔｕｒｅ）を例示する。
【図４】Ｍ２Ｍシステムの構成を例示する。
【図５】Ｍ２Ｍシステムで使われるリソース（ｒｅｓｏｕｒｃｅ）を例示する。
【図６】特定Ｍ２Ｍアプリケーションのためのリソースを例示する。
【図７】一般的なＭ２Ｍシステムの通信流れを例示する。
【図８】Ｍ２Ｍシステムにおいて異なるエンティティが相互連動する例を示す。
【図９】購読リソースに関連した手順を例示する。
【図１０】通知のための手順を例示する。
【図１１】購読リソースが使われる例を示す。
【図１２】本発明に係る動作購読（ｏｐｅｒａｔｉｏｎ  ｓｕｂｓｃｒｉｐｔｉｏｎ）方法を例示する。
【図１３】本発明に係る実施例を示す。
【図１４】本発明を適用し得る装置のブロック図を例示する。
【発明を実施するための形態】
【００２３】
添付の図面は、本発明に関する理解を助けるために詳細な説明の一部として含まれ、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
本発明に係る好適な実施例について添付の図面を参照して詳しく説明する。添付の図面と共に以下に開示する詳細な説明は、本発明の例示的な実施例を説明するためのものであり、本発明を実施し得る唯一の実施例を表すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、本発明の属する分野における通常の技術者にとってはこのような具体的な細部事項無しにも本発明を実施可能であるということが理解できる。
【００２４】
いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で示すことができる。また、本明細書を通じて同一の構成要素には同一の図面符号を付することができる。
【００２５】
本明細書で、Ｍ２Ｍデバイス（Ｍ２Ｍ  ｄｅｖｉｃｅ）とは、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）通信のためのデバイスを指す。Ｍ２Ｍデバイスは、固定していたり移動性を有することができ、Ｍ２Ｍサーバーと通信してユーザデータ及び／又は制御情報を送受信することができる。Ｍ２Ｍデバイスは、端末（Ｔｅｒｍｉｎａｌ  Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｌ）、ＵＴ（Ｕｓｅｒ  Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅ  Ｓｔａｔｉｏｎ）、無線装置（ｗｉｒｅｌｅｓｓ  ｄｅｖｉｃｅ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、無線モデム（ｗｉｒｅｌｅｓｓ  ｍｏｄｅｍ）、携帯装置（ｈａｎｄｈｅｌｄ  ｄｅｖｉｃｅ）などと呼ぶことができる。本発明において、Ｍ２Ｍサーバーは、Ｍ２Ｍ通信のためのサーバーを意味し、固定局（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）又は移動局（ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ）として具現することができる。Ｍ２Ｍサーバーは、Ｍ２Ｍデバイス及び／又は他のＭ２Ｍサーバーと通信してデータ及び制御情報を交換することができる。また、Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスが接続しているネットワークとＭ２Ｍサーバーが接続しているネットワークとが異なる場合、あるネットワークから他のネットワークに入る接続点の役目を担う装置のことを指す。また、Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスとして機能することができ、その他にも、例えば、Ｍ２Ｍゲートウェイに接続されたＭ２Ｍデバイスを管理したり、一つのメッセージを受信し、接続されたＭ２Ｍデバイスにそのままの又は変更したメッセージを伝達したり（ｍｅｓｓａｇｅ  ｆａｎｏｕｔ）、メッセージ集積（ｍｅｓｓａｇｅ  ａｇｇｒｅｇａｔｉｏｎ）を行う機能を有することができる。Ｍ２Ｍデバイスという用語は、Ｍ２ＭゲートウェイとＭ２Ｍサーバーを含む概念で使うことができ、このことから、Ｍ２ＭゲートウェイとＭ２ＭサーバーはＭ２Ｍデバイスと呼ぶことができる。
【００２６】
また、本明細書で、“エンティティ（ｅｎｔｉｔｙ）”という用語は、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバーのようなハードウェアを指すこともでき、又は、後述するＭ２Ｍアプリケーション層とＭ２Ｍ（共通）サービス層のソフトウェアコンポーネント（ｓｏｆｔｗａｒｅ  ｃｏｍｐｏｎｅｎｔ）を指すこともできる。
【００２７】
以下では、本発明はＭ２Ｍシステムを中心に説明するが、本発明は、Ｍ２Ｍシステムに制限されず、例えば、クライアント−サーバー（又は、送信者−応答者（ｓｅｎｄｅｒ−ｒｅｓｐｏｎｄｅｒ））モデルによるシステムにも同一／同様に適用可能である。
【００２８】
図１にはＭ２Ｍシステムを例示する。図１は、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｔａｎｄａｒｄｓ  Ｉｎｓｔｉｔｕｔｅ）技術規格（Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＴＳ）に基づくＭ２Ｍシステムを例示する。
【００２９】
ＥＴＳＩ  ＴＳ  Ｍ２Ｍ技術規格に従うＭ２Ｍシステムは、様々なＭ２Ｍアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）のための共通Ｍ２Ｍサービスフレームワーク（Ｓｅｒｖｉｃｅ  Ｆｒａｍｅｗｏｒｋ）を定義する。Ｍ２Ｍアプリケーションは、ｅヘルス（ｅ−Ｈｅａｌｔｈ）、都市自動化（Ｃｉｔｙ  Ａｕｔｏｍａｔｉｏｎ）、コネクテッドコンシューマー（Ｃｏｎｎｅｃｔｅｄ  Ｃｏｎｓｕｍｅｒ）、オートモーティブ（Ａｕｔｏｍｏｔｉｖｅ）のようなＭ２Ｍサービスソリューションを具現するソフトウェアコンポーネント（ｓｏｆｔｗａｒｅ  ｃｏｍｐｏｎｅｎｔ）を意味することができる。 Ｍ２Ｍシステムではこのような様々なＭ２Ｍアプリケーションを具現するために共通に必要な機能が提供される。これらの共通に必要な機能をＭ２Ｍサービス又はＭ２Ｍ共通サービスと呼ぶことができる。このようなＭ２Ｍ共通サービスを利用すると、各Ｍ２Ｍアプリケーションに基本サービスフレームワークを再び構成することなくＭ２Ｍアプリケーションがを容易に具現することができる。
【００３０】
Ｍ２Ｍサービスは、サービス能力（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ、ＳＣ）の集合の形態で提供され、Ｍ２Ｍアプリケーションはオープンインターフェース（ｏｐｅｎ  ｉｎｔｅｒｆａｃｅ）を介してＳＣ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ）の集合又はＳＣ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ）に接近し、ＳＣ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ）の提供するＭ２Ｍサービス又は機能を利用することができる。ＳＣは、Ｍ２Ｍサービスを構成する機能（例、デバイスの管理、位置、発見、グループ管理、登録、保安など）を提供することができ、ＳＣ層（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｉｅｓ  Ｌａｙｅｒ）又はＳＣエンティティ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｅｎｔｉｔｙ）は、Ｍ２Ｍアプリケーションがサービスフレームワーク上で提供される時に使用し得るＭ２Ｍサービスのための機能（ｆｕｎｃｔｉｏｎ）の集合といえる。
【００３１】
ＳＣ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ）は、ｘＳＣで表現することができる。ここで、ｘは、Ｎ／Ｇ／Ｄのいずれか一つで表現することができ、ＳＣがネットワーク（Ｎｅｔｗｏｒｋ）（及び／又はサーバー）、ゲートウェイ（Ｇａｔｅｗａｙ）、デバイス（Ｄｅｖｉｃｅ）のうちいずれに存在するかを示す。例えば、ＮＳＣは、ネットワーク及び／又はサーバー上に存在するＳＣを示し、ＧＳＣは、ゲートウェイ上に存在するＳＣを示す。
【００３２】
Ｍ２Ｍアプリケーションはネットワーク、ゲートウェイ、又はデバイス上に存在することができる。ネットワーク上に存在したりサーバーと直接接続して存在するＭ２Ｍアプリケーションは、Ｍ２Ｍネットワークアプリケーション（Ｍ２Ｍ  Ｎｅｔｗｏｒｋ  Ａｐｐｌｉｃａｔｉｏｎ）と称し、ＮＡ（Ｎｅｔｗｏｒｋ  Ａｐｐｌｉｃａｔｉｏｎ）と略してもよい。例えば、ＮＡは、サーバーに直接接続して具現されるソフトウェアであり、Ｍ２Ｍゲートウェイ又はＭ２Ｍデバイスと通信し、それらを管理する役割を担うことができる。デバイス上に存在するＭ２Ｍアプリケーションは、Ｍ２Ｍデバイスアプリケーション（Ｍ２Ｍ  Ｄｅｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ）と称し、ＤＡ（Ｄｅｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ）と略してもよい。例えば、ＤＡは、Ｍ２Ｍデバイスで駆動されるソフトウェアであり、センサー情報などをＮＡに伝達することもできる。ゲートウェイ上に存在するＭ２Ｍアプリケーションは、Ｍ２Ｍゲートウェイアプリケーション（Ｇａｔｅｗａｙ  Ａｐｐｌｉｃａｔｉｏｎ）と称し、ＧＡ（Ｇａｔｅｗａｙ  Ａｐｐｌｉｃａｔｉｏｎ）と略してもよい。例えば、ＧＡは、Ｍ２Ｍゲートウェイを管理する役割を担うこともでき、ＤＡにＭ２Ｍサービス又は機能（例、ＳＣｓ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｉｅｓ）又はＳＣ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ））を提供することもできる。Ｍ２Ｍアプリケーションは、アプリケーションエンティティ（ＡＥ）とアプリケーション層を総称することができる。
【００３３】
図１を参照すると、Ｍ２Ｍシステムアーキテクチャーは、ネットワークドメインとデバイス及びゲートウェイドメインとに区別できる。ネットワークドメインは、Ｍ２Ｍシステム管理のための機能（ｆｕｎｃｔｉｏｎ）とネットワーク管理のための機能（ｆｕｎｃｔｉｏｎ）を含むことができる。Ｍ２Ｍシステム管理のための機能は、デバイス及びゲートウェイドメインに存在するデバイスを管理するＭ２ＭアプリケーションとＭ２Ｍ  ＳＣｓ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｉｅｓ）によって行うことができ、ネットワーク管理のための機能は、コアネットワークとアクセスネットワークによって行うことができる。したがって、図１の例で、コアネットワークとアクセスネットワークは、Ｍ２Ｍ機能を果たすというよりは、各エンティティの間の接続を提供する。コアネットワーク及びアクセスネットワークを介してネットワークドメインとデバイス及びゲートウェイドメインとにおいてＭ２Ｍ  ＳＣｓ間にＭ２Ｍ通信を行うことができ、各ドメインにおけるＭ２Ｍアプリケーションは、各ドメインにおけるＭ２Ｍ  ＳＣｓを介して信号又は情報を交換することができる。
【００３４】
アクセスネットワーク（Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）は、Ｍ２Ｍデバイス及びゲートウェイドメインがコアネットワークと通信できるようにするエンティティである。アクセスネットワークの例には、ｘＤＳＬ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）、ＨＦＣ（Ｈｙｂｒｉｄ  Ｆｉｂｅｒ  Ｃｏａｘ）、衛星（ｓａｔｅｌｌｉｔｅ）、ＧＥＲＡＮ、ＵＴＲＡＮ、ｅＵＴＲＡＮ、無線（Ｗｉｒｅｌｅｓｓ）ＬＡＮ、ＷｉＭＡＸなどがある。
【００３５】
コアネットワーク（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）接続、サービスとネットワーク制御、相互接続、ローミング（ｒｏａｍｉｎｇ）などの機能を提供するエンティティである。コアネットワークは、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）コアネットワーク、ＥＴＳＩ  ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ）コアネットワーク、及び３ＧＰＰ２コアネットワークなどを含む。
【００３６】
Ｍ２Ｍ  ＳＣは、複数のＭ２Ｍネットワークアプリケーションで共有可能なＭ２Ｍ共通サービス機能（Ｃｏｍｍｏｎ  Ｓｅｒｖｉｃｅ  Ｆｕｎｃｔｉｏｎ、ＣＳＦ）を提供し、Ｍ２Ｍサービスをオープンインターフェース（ｏｐｅｎ  ｉｎｔｅｒｆａｃｅ）を介して露出することでＭ２ＭアプリケーションがＭ２Ｍサービスを利用できるようにする。Ｍ２Ｍ  ＳＣＬ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｌａｙｅｒ）は、このようなＭ２Ｍ  ＳＣエンティティ又はＭ２Ｍ共通サービス機能を含む階層を意味することができる。
【００３７】
Ｍ２Ｍアプリケーションは、サービスロジック（ｓｅｒｖｉｃｅ  ｌｏｇｉｃ）を動作させ、オープンインターフェースを介してＭ２Ｍ  ＳＣｓを用いることができるエンティティである。Ｍ２Ｍアプリケーション層は、このようなＭ２Ｍアプリケーション及び関連動作ロジック（ｏｐｅｒａｔｉｏｎａｌ  ｌｏｇｉｃ）を含む階層を意味することができる。
【００３８】
Ｍ２Ｍデバイスは、Ｍ２Ｍ  ＳＣｓを介してＭ２Ｍデバイスアプリケーションを動作させるエンティティである。Ｍ２ＭデバイスはネットワークドメインのＭ２Ｍサーバーと直接通信することもでき、Ｍ２Ｍゲートウェイを介してネットワークドメインのＭ２Ｍサーバーと通信することもできる。Ｍ２Ｍゲートウェイを介して接続される場合には、Ｍ２Ｍゲートウェイはプロキシ（ｐｒｏｘｙ）のように動作する。Ｍ２Ｍデバイスは、Ｍ２Ｍアプリケーション及び／又はＭ２Ｍ  ＳＣｓを含むことができる。
【００３９】
Ｍ２Ｍ領域ネットワーク（Ｍ２Ｍ  ａｒｅａ  ｎｅｔｗｏｒｋ）は、Ｍ２ＭデバイスとＭ２Ｍゲートウェイ間の接続（ｃｏｎｎｅｃｔｉｖｉｔｙ）を提供する。この場合、Ｍ２Ｍゲートウェイ及びＭ２Ｍサーバー間のネットワークとＭ２Ｍデバイス及びＭ２Ｍゲートウェイ間のネットワークとが異なり得る。例えば、Ｍ２Ｍ領域ネットワークは、ＩＥＥＥ  ８０２．１５．１、ジグビー（Ｚｉｇｂｅｅ）、ブルトゥース（Ｂｌｕｅｔｏｏｔｈ）、ＩＥＴＦ  ＲＯＬＬ、ＩＳＡ１００．１１ａのようなＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）技術と、ＰＬＣ（Ｐｏｗｅｒ  Ｌｉｎｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｍ−ＢＵＳ、無線Ｍ−ＢＵＳ、ＫＮＸのようなローカルネットワーク技術によって具現することができる。
【００４０】
Ｍ２ＭゲートウェイはＭ２Ｍ  ＳＣｓを介してＭ２Ｍアプリケーションを管理し、Ｍ２Ｍアプリケーションに対してサービスを提供するエンティティである。Ｍ２ＭゲートウェイはＭ２Ｍデバイスとネットワークドメイン間のプロキシの役割を担い、ＥＴＳＩ非−互換（ｎｏｎ−ｃｏｍｐｌｉａｎｔ）Ｍ２Ｍデバイスにもサービスを提供する役割を担うことができる。Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスのうち、ゲートウェイ機能を有するエンティティのことを指すことができる。Ｍ２Ｍゲートウェイは、Ｍ２Ｍアプリケーション及び／又はＭ２Ｍ  ＳＣｓを含むことができる。
【００４１】
図１に示したＭ２Ｍシステムアーキテクチャーは例示に過ぎず、各エンティティの名称は変更されてもよい。例えば、Ｍ２Ｍ  ＳＣはＭ２Ｍ共通サービス機能（ｃｏｍｍｏｎ  ｓｅｒｖｉｃｅ  ｆｕｎｃｔｉｏｎ、ＣＳＦ）と呼ばれてもよく、ＳＣＬ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｌａｙｅｒ）は共通サービス層（Ｃｏｍｍｏｎ  Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ、ＣＳＬ）又は共通サービスエンティティ（Ｃｏｍｍｏｎ  Ｓｅｒｖｉｃｅ  Ｅｎｔｉｔｙ、ＣＳＥ）と呼ばれてもよい。また、Ｍ２Ｍアプリケーションはアプリケーションエンティティ（ａｐｐｌｉｃａｔｉｏｎ  ｅｎｔｉｔｙ、ＡＥ）と呼ばれてもよく、Ｍ２Ｍアプリケーション層は簡略にアプリケーション層と呼ばれてもよい。同様に、各ドメインの名称も変わってもよい。例えば、ｏｎｅＭ２Ｍシステムにおいて、ネットワークドメインは、インフラストラクチャードメイン（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ｄｏｍａｉｎ）と呼び、デバイス及びゲートウェイドメインはフィールドドメイン（ｆｉｅｌｄ  ｄｏｍａｉｎ）と呼ぶこともできる。
【００４２】
図１に例示したように、Ｍ２Ｍシステムは、Ｍ２Ｍ通信のためにＭ２Ｍアプリケーション層とＭ２Ｍ  ＳＣ層を含む階層構造として理解されてもよい。
【００４３】
図２にはＭ２Ｍシステムの階層構造（ｌａｙｅｒｅｄ  ｓｔｒｕｃｔｕｒｅ）を例示する。
【００４４】
図２を参照すると、Ｍ２Ｍシステムは、アプリケーション層２０２、共通サービス層２０４、基底ネットワークサービス層（ｕｎｄｅｒｌｙｉｎｇ  ｎｅｔｗｏｒｋ  ｓｅｒｖｉｃｅｓ  ｌａｙｅｒ）２０６を含むことができる。前述したように、アプリケーション層２０２はＭ２Ｍアプリケーション層に対応し、共通サービス層２０４はＭ２Ｍ  ＳＣＬに対応し得る。基底ネットワークサービス層２０６は、コアネットワークに存在する装置管理（ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）、位置サービス（ｌｏｃａｔｉｏｎ  ｓｅｒｖｉｃｅ）、及び装置トリガリング（ｄｅｖｉｃｅ  ｔｒｉｇｇｅｒｉｎｇ）のようなサービスを共通サービス層２０４に提供する。
【００４５】
図３にはＭ２Ｍシステムの機能的アーキテクチャー（ｆｕｎｃｔｉｏｎａｌ  ａｒｃｈｉｔｅｃｔｕｒｅ）を例示する。機能的な側面においてＭ２Ｍシステムアーキテクチャーはアプリケーションエンティティ（ａｐｐｌｉｃａｔｉｏｎ  ｅｎｔｉｔｙ、ＡＥ）３０２、共通サービスエンティティ（ｃｏｍｍｏｎ  ｓｅｒｖｉｃｅ  ｅｎｔｉｔｙ、ＣＳＥ）３０４、基底（ｕｎｄｅｒｌｙｉｎｇ）ネットワークサービスエンティティ（ｎｅｔｗｏｒｋ  ｓｅｒｖｉｃｅ  ｅｎｔｉｔｙ、ＮＳＥ）３０６を含むことができる。各エンティティ３０２，３０４，３０６は、共通サービスエンティティ３０４が支援する基準点（ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ）を介して通信することができる。基準点は、各エンティティ３０２，３０４，３０６間の通信流れ（ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｆｌｏｗ）を指定する役割を担う。基準点はＭｃｘと表現することができ、Ｍｃは“Ｍ２Ｍ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ”を意味する。本明細書で、Ｍｃａ基準点、Ｍｃｃ基準点、Ｍｃｎ基準点はそれぞれＭｃａ、Ｍｃｃ、Ｍｃｎと表記することができる。
【００４６】
図３を参照すると、Ｍｃａ基準点３１２は、アプリケーションエンティティ（ＡＥ）３０２と共通サービスエンティティ（ＣＳＥ）３０４との通信の流れを指定する。Ｍｃａ基準点３１２は、ＡＥ３０２がＣＳＥ３０４によって提供されるサービスを利用できるようにし、ＣＳＥ３０４がＡＥ３０２と通信できるようにする。Ｍｃａ基準点３１２はＭ２Ｍアプリケーション層とＭ２Ｍ共通サービス層（又はエンティティ）との間のインターフェースを意味することができる。
【００４７】
Ｍｃｃ基準点３１４は、異なる共通サービスエンティティ（ＣＳＥ）３０４の間の通信流れを指定する。Ｍｃｃ基準点３１４は、ＣＳＥ３０４が必要な機能を提供する際、他のＣＳＥのサービスを利用できるようにする。Ｍｃｃ基準点３１４を介して提供されるサービスは、ＣＳＥ３０４が支援する機能に依存的であってもよい。Ｍｃｃ基準点３１４は、Ｍ２Ｍ共通サービス層同士の間のインターフェースを意味することができる。
【００４８】
Ｍｃｎ基準点３１６は、ＣＳＥ３０４と基底ネットワークサービスエンティティ（ＮＳＥ）３０６との間の通信の流れを指定する。Ｍｃｎ基準点３１６は、ＣＳＥ３０４が要求された機能を提供するように、基底ＮＳＥ３０６の提供するサービスを利用できるようにする。Ｍｃｎ基準点３１２は、Ｍ２Ｍ共通サービス層とＭ２Ｍ基底ネットワーク層との間のインターフェースを意味することができる。
【００４９】
また、図３の例で、ＣＳＥ３０４は様々な共通サービス機能（ｃｏｍｍｏｎ  ｓｅｒｖｉｃｅ  ｆｕｎｃｔｉｏｎ、ＣＳＦ）を提供することができる。例えば、ＣＳＥ３０４は、アプリケーション及びサービス層管理（Ａｐｐｌｉｃａｔｉｏｎ  ａｎｄ  Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ）機能、通信管理及び伝達処理（Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｄｅｌｉｖｅｒｙ  Ｈａｎｄｌｉｎｇ）機能、データ管理及び保存（Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｒｅｐｏｓｉｔｏｒｙ）機能、装置管理（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ）機能、グループ管理（Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ）機能、発見（Ｄｉｓｃｏｖｅｒｙ）機能、位置（Ｌｏｃａｔｉｏｎ）機能、ネットワークサービス露出／サービス実行及びトリガリング（Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ  Ｅｘｐｏｓｕｒｅ／Ｓｅｒｖｉｃｅ  Ｅｘｅｃｕｔｉｏｎ  ａｎｄ  Ｔｒｉｇｇｅｒｉｎｇ）機能、登録（Ｒｅｇｉｓｔｒａｔｉｏｎ）機能、保安（Ｓｅｃｕｒｉｔｙ）機能、サービス課金及び計算（Ｓｅｒｖｉｃｅ  Ｃｈａｒｇｉｎｇ  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ）機能、サービスセッション管理機能（Ｓｅｒｖｉｃｅ  Ｓｅｓｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ）、購読／通知（Ｓｕｂｓｃｒｉｐｔｉｏｎ／Ｎｏｔｉｆｉｃａｔｉｏｎ）機能のうち少なくとも一つを含むことができる。ＣＳＥ３０４は、上記共通サービス機能のインスタンス（ｉｎｓｔａｎｃｅ）を表し、Ｍ２Ｍアプリケーションが使用して共有できる共通サービス機能のサブセットを提供する。共通サービス機能を概略的に説明すると次のとおりである。
【００５０】
−  アプリケーション及びサービス層管理（Ａｐｐｌｉｃａｔｉｏｎ  ａｎｄ  Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ、ＡＳＭ）：ＡＥとＣＳＥの管理機能を提供する。例えば、ＡＳＭ機能は、ＣＳＥの機能を設定（ｃｏｎｆｉｇｕｒｅ）し、問題点を解決（ｔｒｏｕｂｌｅｓｈｏｏｔ）し、アップグレード（ｕｐｇｒａｄｅ）するだけでなく、ＡＥの機能をアップグレードすることができる。
【００５１】
−  通信管理及び伝達処理（Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｄｅｌｉｖｅｒｙ  Ｈａｎｄｌｉｎｇ、ＣＭＤＨ）：他のＣＳＥ、ＡＥ、ＮＳＥとの通信を提供する。例えば、ＣＭＤＨ機能は、ＣＳＥ−ＣＳＥ通信（ＣＳＥ−ｔｏ−ＣＳＥ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）のための接続（ｃｏｎｎｅｃｔｉｏｎ）をいつどのように使用するかを決定し、特定要求が遅延伝達されるように制御することができる。
【００５２】
−  データ管理及び保存（Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｒｅｐｏｓｉｔｏｒｙ、ＤＭＲ）：Ｍ２Ｍアプリケーションがデータを交換、共有できるようにする。例えば、ＤＭＲ機能は、大量のデータを収集（ｃｏｌｌｅｃｔｉｎｇ）／併合（ａｇｇｒｅｇａｔｉｎｇ）し、データを特定フォーマットに変換（ｃｏｎｖｅｒｔｉｎｇ）して保存（ｓｔｏｒｉｎｇ）することができる。
【００５３】
−  装置管理（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ、ＤＭＧ）：Ｍ２Ｍゲートウェイ及びＭ２Ｍデバイスだけでなく、Ｍ２Ｍ領域ネットワークに存在するデバイスに対するデバイス機能を管理する。例えば、ＤＭＧ機能は、アプリケーション設置及び設定、ファームウェア（Ｆｉｒｍｗａｒｅ）アップデート、ロギング（Ｌｏｇｇｉｎｇ）、モニタリング（Ｍｏｎｉｔｏｒｉｎｇ）、診断（Ｄｉａｇｎｏｓｔｉｃｓ）、ネットワークトポロジ（Ｔｏｐｏｌｏｇｙ）管理などを行うことができる。
【００５４】
−  発見（Ｄｉｓｃｏｖｅｒｙ，ＤＩＳ）：与えられた範囲及び条件内で要求に応じて情報及びリソース（ｒｅｓｏｕｒｃｅ）のような情報を検索（ｓｅａｒｃｈｉｎｇ）する。
【００５５】
−  グループ管理（Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ、ＧＭＧ）：例えば、リソース（ｒｅｓｏｕｒｃｅ）、Ｍ２Ｍデバイス、又はＭ２Ｍゲートウェイをまとめてグループを生成できるが、グループ関連要求をハンドリング（ｈａｎｄｌｉｎｇ）する。
【００５６】
−  位置（Ｌｏｃａｔｉｏｎ、ＬＯＣ）：Ｍ２ＭアプリケーションがＭ２Ｍデバイス又はＭ２Ｍゲートウェイの位置情報を取得できるようにする役割を担う。
【００５７】
−  ネットワークサービス露出／サービス実行及びトリガリング（Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ  Ｅｘｐｏｓｕｒｅ／  Ｓｅｒｖｉｃｅ  Ｅｘｅｃｕｔｉｏｎ  ａｎｄ  Ｔｒｉｇｇｅｒｉｎｇ、ＮＳＳＥ）：基底ネットワークの通信を可能にし、基底ネットワークが提供するサービス又は機能を使用できるようにする。
【００５８】
−  登録（Ｒｅｇｉｓｔｒａｔｉｏｎ、ＲＥＧ）：Ｍ２Ｍアプリケーション又は他のＣＳＥの特定ＣＳＥへの登録を処理する役割を担う。登録は、特定ＣＳＥのＭ２Ｍサービス機能を使用するために行われる。
【００５９】
−  保安（Ｓｅｃｕｒｉｔｙ、ＳＥＣ）：保安キーのような敏感なデータハンドリング、保安関連付け（Ａｓｓｏｃｉａｔｉｏｎ）設立、認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、権限付与（Ａｕｔｈｏｒｉｚａｔｉｏｎ）、ＩＤ（Ｉｄｅｎｔｉｔｙ）保護などの役割を担う。
【００６０】
−  サービス課金及び計算（Ｓｅｒｖｉｃｅ  Ｃｈａｒｇｉｎｇ  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ、ＳＣＡ）：ＡＥ又はＣＳＥに課金機能を提供する役割を担う。
【００６１】
−  サービスセッション管理（Ｓｅｒｖｉｃｅ  Ｓｅｓｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ、ＳＳＭ）：端対端（ｅｎｄ−ｔｏ−ｅｎｄ）通信のためのサービス層のＭ２Ｍセッションを管理する役割を担う。
【００６２】
−購読／通知（Ｓｕｂｓｃｒｉｐｔｉｏｎ／Ｎｏｔｉｆｉｃａｔｉｏｎ、ＳＵＢ）：特定リソース（ｒｅｓｏｕｒｃｅ）に対する変更を購読（Ｓｕｂｓｃｒｉｐｔｉｏｎ）し、当該リソース（ｒｅｓｏｕｒｃｅ）が変更されるとそれを通知（ｎｏｔｉｆｉｃａｔｉｏｎ）する役割を担う。
【００６３】
図４は、Ｍ２Ｍシステムの構成を例示する。本明細書で、ノード（ｎｏｄｅ）は、一つ以上のＭ２Ｍアプリケーションを含むエンティティ、又は一つのＣＳＥと０個以上のＭ２Ｍアプリケーションを含むエンティティを意味する。
【００６４】
アプリケーション専用ノード（Ａｐｐｌｉｃａｔｉｏｎ  Ｄｅｄｉｃａｔｅｄ  Ｎｏｄｅ、ＡＤＮ）は、少なくとも一つのアプリケーションエンティティ（ＡＥ）を有するが、共通サービスエンティティ（ＣＳＥ）を有しないノードを意味することができる。ＡＤＮは、Ｍｃａを介して一つの中間ノード（Ｍｉｄｄｌｅ  Ｎｏｄｅ、ＭＮ）又は一つのインフラストラクチャーノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｎｏｄｅ、ＩＮ）と通信することができる。ＡＤＮは、制限された能力を有するＭ２Ｍデバイス（Ｍ２Ｍ  ｄｅｖｉｃｅ  ｈａｖｉｎｇ  ａ  ｃｏｎｓｔｒａｉｎｅｄ  ｃａｐａｂｉｌｉｔｙ）と呼ぶこともできる。制限された能力を有するＭ２Ｍデバイスは、共通サービス層（ｃｏｍｍｏｎ  ｓｅｒｖｉｃｅ  ｌａｙｅｒ）又は共通サービスエンティティ（ＣＳＥ）を含まないＭ２Ｍデバイスを意味することができる。制限された能力を有するＭ２Ｍデバイスは、簡略に、制限的なＭ２Ｍデバイス（ｃｏｎｓｔｒａｉｎｅｄ  Ｍ２Ｍ  ｄｅｖｉｃｅ）と呼ぶこともできる。
【００６５】
アプリケーションサービスノード（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｎｏｄｅ、ＡＳＮ）は、少なくとも一つの共通サービスエンティティ（ＣＳＥ）及び少なくとも一つのＭ２Ｍアプリケーションエンティティ（ＡＥ）を有するノードを意味することができる。ＡＳＮは、Ｍｃｃを介して一つの中間ノード又は一つのインフラストラクチャーノードと通信することができる。ＡＳＮは、Ｍ２Ｍデバイスと呼ぶことができる。
【００６６】
中間ノード（Ｍｉｄｄｌｅ  Ｎｏｄｅ、ＭＮ）は、一つの共通サービスエンティティ（ＣＳＥ）と０個以上のＭ２Ｍアプリケーションエンティティ（ＡＥ）を有するノードを意味することができる。ＭＮは、Ｍｃｃを介して一つのインフラストラクチャーノード（ＩＮ）又は他の中間ノード（ＭＮ）と通信することができ、又はＭｃｃを介してＩＮ／ＭＮ／ＡＳＮと通信することができ、又はＭｃａを介してＡＤＮと通信することができる。ＭＮは、Ｍ２Ｍゲートウェイと呼ぶことができる。
【００６７】
インフラストラクチャーノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｎｏｄｅ、ＩＮ）は、一つの共通サービスエンティティ（ＣＳＥ）及び０個以上のアプリケーションエンティティ（ＡＥ）を有するノードを意味することができる。ＩＮは、Ｍｃｃを介して少なくとも一つの中間ノード（ＭＮ）と通信することができ、及び／又は少なくとも一つのＡＳＮと通信することができる。或いはＩＮは、Ｍｃａを介して一つ以上のＡＤＮと通信することができる。ＩＮは、Ｍ２Ｍサーバーと呼ぶことができる。
【００６８】
図４を参照すると、例１は、ＡＤＮ（４０２）とＩＮ（４２２）との間の通信を例示する。ＡＤＮ（４０２）は、制限された能力を有するＭ２Ｍデバイスであってもよい。この場合、ＡＤＮ（４０２）はＣＳＥ又は共通サービス層を有しておらず、Ｍｃａを介してＩＮ（４２２）のＣＳＥと通信することができる。また、この場合、ＡＤＮ（４０２）は、ＣＳＥ又は共通サービス層を有しておらず、ＡＥ又はアプリケーション層で生成されたデータを他のエンティティに保存／共有することができない。このため、例１で、ＡＤＮ（４０２）のＡＥ又はアプリケーション層で生成されたデータは、ＩＮ（４２２）のＣＳＥに保存して共有することができる。
【００６９】
例２は、ＡＤＮ（４０４）とＭＮ（４１４）との間の通信を例示する。ＡＤＮ（４０４）も、制限された能力を有するＭ２Ｍデバイスであってもよい。このため、ＡＤＮ（４０４）がＭＮ（４１４）のＣＳＥと通信する以外は、例１と略同様に動作することができる。すなわち、ＡＤＮ（４０４）はＭｃａを介してＭＮ（４１４）のＣＳＥと通信することができる。また、ＡＤＮ（４０４）は、ＣＳＥ又は共通サービス層を有しておらず、ＡＥ又はアプリケーション層で生成されたデータを他のエンティティに保存／共有することができない。このため、ＡＤＮ（４０４）のＡＥ又はアプリケーション層で生成されたデータは、ＭＮ（４１４）のＣＳＥに保存して共有することができる。
【００７０】
一方、例２で、ＭＮ（４１４）はＭＮ（４１２）を経てＩＮ（４２２）と通信することができる。この場合、ＭＮ（４１４）とＭＮ（４１２）、そしてＭＮ（４１２）とＩＮ（４２２）はＭｃｃを介して通信することができる。ＭＮ（４１４）がＭＮ（４１２）を経ずにＩＮ（４２２）と直接通信することもできる。
【００７１】
例３は、ＡＳＮ（４０６）とＭＮ（４１４）との間の通信を例示する。例１又は例２と違い、ＡＳＮ（４０６）はＣＳＥ又は共通サービス層を有しているため、ＡＳＮ（４０６）のＡＥ又はアプリケーション層で生成されたデータを自身のＣＳＥ又は共通サービス層に保存することができる。また、ＡＳＮ（４０６）のＡＥは、ＡＳＮ（４０６）のＣＳＥを介してＭＮ（４１４）のＣＳＥと通信することができる。
【００７２】
例４は、ＡＳＮ（４０８）とＩＮ（４２２）との間の通信を例示する。例３と比較して、ＡＳＮ（４０８）のＣＳＥはＭＮを経ずにＩＮ（４２２）のＣＳＥと直接通信することができる。
【００７３】
ＩＮ（４２２又は４２４）は、インフラストラクチャードメイン又はネットワークドメインに位置し、一つのＣＳＥ及び０個以上のＡＥを含むことができる。ＩＮ（４２２，４２４）はＭｃｃを介して互いに通信することができる。
【００７４】
図５には、Ｍ２Ｍシステムで用いられるリソース（ｒｅｓｏｕｒｃｅ）を例示する。
【００７５】
Ｍ２Ｍシステムにおいてアプリケーションエンティティ（ＡＥ）、ＣＳＥ、データなどはリソース（ｒｅｓｏｕｒｃｅ）と表現することができる。Ｍ２Ｍシステムにおいて、リソースは、固有のアドレス（例、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ又はＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ））を用いて固有にアドレシング可能なエンティティ（ｕｎｉｑｕｅｌｙ  ａｄｄｒｅｓｓａｂｌｅ  ｅｎｔｉｔｙ）を意味する。Ｍ２Ｍシステムでリソースは特定データ構造と表現され、各リソースは互いに論理的に連結されてもよい。リソースは、ＣＳＥ又は共通サービス層によって管理されて保存されてもよい。このため、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサーバーのＣＳＥ又は共通サービス層ではこのようなリソースを有することができる。一方、Ｍ２ＭシステムのＡＥ又はアプリケーション層ではこのようなリソース構造を有することができない。各リソースは子リソースと属性を有する。Ｍ２Ｍリソースでルート（Ｒｏｏｔ）リソースは属性（ａｔｔｒｉｂｕｔｅ）と子リソース（ｃｈｉｌｄ  ｒｅｓｏｕｒｃｅ）を有することができる。例えば、リソースをツリー構造で表現することができる。例えば、ルートリソースのタイプは、＜ｂａｓｅＵＲＩ＞又は＜ＣＳＥＢａｓｅ＞と表示することができる。リソースのタイプは、“＜”と“＞”で表示することができる。
【００７６】
Ｍ２Ｍシステムでは様々なリソースタイプが定義されるが、Ｍ２Ｍアプリケーションは、リソースタイプが実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）されたリソースに基づいて通信を行うことができる。例えば、アプリケーションを登録し、センサー値を読み込むなどのＭ２Ｍサービスを行うために用いられてもよい。それぞれのリソースは、該当のリソースタイプのインスタンスが生成される際に固有のアドレス情報（例、ＵＲＩ）が与えられ、ルートリソースと同様に、属性及び子リソースを有することができる。各リソースは、固有のアドレス情報を用いてアドレシングされてもよい。特定リソースタイプは、該当のリソースが実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）された時に有し得る子リソースと属性を定義する。特定リソース実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）の際、リソースは、当該リソースのリソースタイプに定義された属性と子リソースを有することができる。
【００７７】
属性は、リソース自体に関する情報を保存し、子リソースを有することができない。子リソースは、自身の属性と自身の子リソースを有することができ、例えば、子リソースには、遠隔ＣＳＥリソース、アプリケーションエンティティリソース、接近制御リソース、コンテナリソース、グループリソース、購読リソースなどがある。
【００７８】
−  遠隔ＣＳＥリソース：当該ＣＳＥに登録（連結）された他のＣＳＥの情報を含む。例えば、遠隔ＣＳＥリソースのタイプは、＜ｅｎｔｉｔｙ＞又は＜ｒｅｍｏｔｅＣＳＥ＞と表示することができる。
【００７９】
−  アプリケーションエンティティリソース：ルートリソースのアプリケーションエンティティリソース（例、＜ｂａｓｅＵＲＩ＞／＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞）又はルートリソースの遠隔ＣＳＥリソース（例、＜ｂａｓｅＵＲＩ＞／＜ｅｎｔｉｔｙ＞又は＜ＣＳＥＢａｓｅ＞／＜ｒｅｍｏｔｅ  ＣＳＥ＞）の下位に存在するリソースであり、ルートリソースのアプリケーションエンティティリソース（例、＜ｂａｓｅＵＲＩ＞／＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞）の下位に存在する場合、当該ＣＳＥに登録（連結）されたアプリケーションエンティティの情報を保存し、ルートリソースの遠隔ＣＳＥリソース（例、＜ｂａｓｅＵＲＩ＞／＜ｅｎｔｉｔｙ＞又は＜ＣＳＥＢａｓｅ＞／＜ｒｅｍｏｔｅ  ＣＳＥ＞）の下位に存在する場合には、特定遠隔ＣＳＥに登録されたアプリケーションエンティティの情報を保存する。例えば、アプリケーションエンティティリソースのタイプは、＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＡＥ＞と表示することができる。
【００８０】
−  接近制御リソース：接近権限に関連した情報を保存するリソースである。このリソースに含まれた接近権限情報を用いて権限付与（ａｕｔｈｏｒｉｚａｔｉｏｎ）を行うことができる。例えば、接近制御リソースのタイプは、＜ａｃｃｅｓｓＲｉｇｈｔ＞又は＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞と表示することができる。
【００８１】
−  コンテナリソース：ＣＳＥ又はＡＥ別に生成されるデータを保存する。例えば、コンテナリソースのタイプは、＜ｃｏｎｔａｉｎｅｒ＞と表示することができる。
【００８２】
−  グループリソース：複数のリソースを一つにまとめて一緒に処理できるようにする機能を提供する。例えば、グループリソースのタイプは、＜ｇｒｏｕｐ＞と表示することができる。
【００８３】
−  購読リソース：リソースの状態が変更されることを通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）にて知らせる機能を果たす。例えば、購読リソースのタイプは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞と表示することができる。
【００８４】
図６には特定Ｍ２Ｍアプリケーションのためのリソースタイプを例示する。前述したように、特定Ｍ２Ｍアプリケーションのためのリソースは、Ｍ２ＭゲートウェイのＣＳＥ又は共通サービス層のリソースにおいてアプリケーションリソース（Ａｐｐｌｉｃａｔｉｏｎ  Ｒｅｓｏｕｒｃｅ）に保存することができる。特定Ｍ２Ｍアプリケーションのためのリソースは、全体リソースと同様に、属性（ａｔｔｒｉｂｕｔｅ）と子リソース（ｃｈｉｌｄ  ｒｅｓｏｕｒｃｅ）を有することができる。図６の例で、子リソースはタイプ（例、“＜”、“＞”で表示）と定義されており、実体化の際に実際の名前が与えられて保存される。
【００８５】
図７には一般的なＭ２Ｍシステムの通信流れを例示する。一般に、Ｍ２Ｍシステムの動作はデータ交換に基づいて行われる。例えば、特定デバイスが他のデバイスの動作を止めるために該当の命令をデータの形態として他の装置に伝達することができる。デバイス内でデータを保存するためには特定形態のデータ構造が用いられるが、これをリソース（Ｒｅｓｏｕｒｃｅ）と呼ぶ。リソースは、固有のアドレス（例、ＵＲＩ）を用いてアクセスすることができる。
【００８６】
図７を参照すると、ＡＥとＣＳＥとの連結又はＣＳＥ同士の連結において要求及び応答方式（Ｒｅｑｕｅｓｔ  ａｎｄ  Ｒｅｓｐｏｎｓｅ  Ｓｃｈｅｍｅ）が用いられる。発信者（ｏｒｉｇｉｎａｔｏｒ）は、受信者（ｒｅｃｅｉｖｅｒ）に保存されているリソースを要求するために要求メッセージを送信し、それに対する応答として応答メッセージを受信することができる。同様に、受信者は、発信者からリソースを要求するメッセージを受信し、それに対する応答として応答メッセージを発信者に送信することができる。本明細書では簡略に、要求メッセージを要求と呼び、応答メッセージを応答と呼ぶこともできる。発信者から受信者に送信される要求メッセージは次のような情報を含むことができる。
【００８７】
−  ｏｐ：実行される動作（Ｏｐｅｒａｔｉｏｎ）の形態
生成（Ｃｒｅａｔｅ）／回収（Ｒｅｔｒｉｅｖｅ）／更新（Ｕｐｄａｔｅ）／削除（Ｄｅｌｅｔｅ）／通知（Ｎｏｔｉｆｙ）のうち一つであってもよい。本明細書では、動作に該当する情報を命令（ｃｏｍｍａｎｄ）と呼ぶこともできる。
【００８８】
−  ｔｏ：目的リソースのＵＲＩ
−  ｆｒ：要求（Ｒｅｑｕｅｓｔ）を生成した発信者の識別情報（又はＩＤ）
−  ｍｉ：当該要求に対する追加情報（Ｍｅｔａ  ｉｎｆｏｒｍａｔｉｏｎ）
−  ｃｎ：伝達されるリソースの内容
【００８９】
当該要求が成功裏に行われた場合、応答（Ｒｅｓｐｏｎｓｅ）メッセージは次のような情報を含むことができる。応答メッセージは、次の情報のうち少なくとも一つを含むことができ、又は結果値（ｒｓ）のみを含んでもよい。
【００９０】
−  ｔｏ：要求を生成した発信者の識別情報（又はＩＤ）
−  ｆｒ：要求を受信した受信者の識別情報（又はＩＤ）
−  ｍｉ：要求に対する追加情報（Ｍｅｔａ  ｉｎｆｏｒｍａｔｉｏｎ）
−  ｒｓ：要求に対する結果（例えば、Ｏｋａｙ、Ｏｋａｙ  ａｎｄ  Ｄｏｎｅ、Ｏｋａｙ  ａｎｄ  ｉｎ  ｐｒｏｇｒｅｓｓ）
−  ａｉ：追加的な情報
−  ｃｎ：伝達されるリソースの内容
【００９１】
当該要求に失敗した場合、応答メッセージは次のような情報を含むことができる。
【００９２】
−  ｔｏ：要求を生成した発信者のＩＤ
−  ｆｒ：要求を受信した受信者のＩＤ
−  ｍｉ：要求に対する追加情報（Ｍｅｔａ  ｉｎｆｏｒｍａｔｉｏｎ）
−  ｒｓ：要求に対する結果（例えば、Ｎｏｔ  Ｏｋａｙ）
−  ａｉ：追加的な情報
【００９３】
本明細書で、発信者は発信者デバイス（又は、そのＣＳＥ又はＡＥ）を表し、受信者は、受信者デバイス（又は、そのＣＳＥ又はＡＥ）を表すことができる。また、リソースを有しているデバイス（又は、そのＣＳＥ）をホスティングデバイス（又はホスティングＣＳＥ）と呼ぶ。
【００９４】
一例として、発信者は受信者上にリソースを生成するために、図７に例示した方式を利用することができる。この場合、発信者はリソース生成要求メッセージ（例、ＣＲＥＡＴＥ  ｒｅｑｕｅｓｔ）を受信者に送信することができる。リソース生成要求メッセージは次のような情報を含むことができる。
【００９５】
−  ｏｐ：Ｃ（Ｃｒｅａｔｅ）
−  ｔｏ：生成対象リソースの親のＵＲＩ
−  ｆｒ：発信者ＩＤ
−  ｃｎ：生成対象リソースの属性情報を含み、選択的に（ｏｐｔｉｏｎａｌｌｙ）生成対象リソースの識別情報（例、生成対象リソースの名前）を含むことができる。
【００９６】
受信者がリソース生成要求メッセージを受信した場合、受信者は、発信者が認証されているか否かを確認する。生成対象リソースに関する情報（例、アクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）又はアクセス制御政策（ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ  ｐｏｌｉｃｙ））がまだ受信者に知られておらず、受信者は発信者を認証することによって、リソースを生成するか否かを決定することができる。発信者が認証されている場合、対象リソースの生成を許容することができる。また、リソース生成要求メッセージに生成対象リソースの識別情報が含まれる場合、受信者は、生成対象リソースの識別情報が受信者のリソース構造に既に存在するか否かを検証（ｖｅｒｉｆｙ）する。万一、有効な識別情報が提供されていないと（例えば、生成対象リソースの識別情報が重複すると）、受信者は生成対象リソースの識別情報を割り当てることができる。同様に、万一、リソース生成要求メッセージが生成対象リソースの識別情報を含まない場合、受信者は生成対象リソースの識別情報を割り当てることができる。
【００９７】
受信者は生成対象リソースを成功裏に生成した場合、次の情報を含む応答メッセージを発信者に送信することができる。
【００９８】
−  ｔｏ：発信者ＩＤ
−  ｆｒ：受信者ＩＤ
−  ｃｎ：生成されたリソースのＵＲＩ及び／又は内容（ｃｏｎｔｅｎｔ）
【００９９】
他の例として、発信者は、受信者上のリソースに関する情報（例、属性情報）を回収（ｒｅｔｒｉｅｖｅ）するために、図７に例示した方式を用いることができる。この場合、発信者は受信者上のリソースに関する情報（例、属性情報）を回収するために回収要求メッセージ（例、ＲＥＴＲＩＥＶＥ  ｒｅｑｕｅｓｔ）を受信者に送信することができる。発信者は回収要求メッセージを用いて受信者の対象リソースから全ての属性を回収したり一部の属性のみを回収したりすることができる。回収要求メッセージは次のような情報を含むことができる。
【０１００】
−  ｏｐ：Ｒ（Ｒｅｔｒｉｅｖｅ）
−  ｔｏ：回収対象リソースのＵＲＩ
−  ｆｒ：発信者ＩＤ
【０１０１】
受信者は発信者から回収要求メッセージを受信すると、回収要求メッセージから回収対象リソースのＵＲＩを参照して回収対象リソースが存在するか否か検証し、発信者が回収対象リソースに対して回収権限（ｐｅｒｍｉｓｓｉｏｎ  ｆｏｒ  ｒｅｔｒｉｅｖｉｎｇ）を有するか否かを確認する。万一、回収対象リソースが存在していないか、発信者が正当な回収権限を有しないと、受信者は応答メッセージを用いて誤り（ｅｒｒｏｒ）を送信することができる。逆に、回収対象リソースが存在し、発信者が正当な回収権限を有すると、受信者は応答メッセージを発信者に送信することができる。応答メッセージは次のような情報を含むことができる。
【０１０２】
−  ｔｏ：発信者ＩＤ
−  ｆｒ：受信者ＩＤ
−  ｃｎ：回収対象リソースの内容（ｃｏｎｔｅｎｔ）
【０１０３】
更に他の例として、発信者は、受信者上の特定リソースにおいて属性情報を更新（ｕｐｄａｔｅ）するために、図７に例示した手順を用いることができる。この場合、発信者は更新要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）を受信者に送信することができる。発信者は更新要求メッセージを用いて受信者上の特定リソースにおいて属性情報を新しい値に更新することができる。更新要求メッセージは次のような情報を含むことができる。
【０１０４】
−  ｏｐ：Ｕ（Ｕｐｄａｔｅ）
−  ｔｏ：更新対象リソースのＵＲＩ
−  ｆｒ：発信者ＩＤ
−  ｃｎ：更新対象リソースにおいて更新される情報
【０１０５】
受信者は発信者から更新要求メッセージを受信すると、更新要求メッセージから更新対象リソースのＵＲＩを参照して更新対象リソースが存在するか否か検証し、更新対象リソースの修正を行うように発信者に権限が与えられているか否か（ｗｈｅｔｈｅｒ  ｔｈｅ  ｏｒｉｇｉｎａｔｏｒ  ｉｓ  ａｕｔｈｏｒｉｚｅｄ  ｔｏ  ｐｅｒｆｏｒｍ  ｍｏｄｉｆｙｉｎｇ  ｔｈｅ  ｔａｒｇｅｔ  ｒｅｓｏｕｒｃｅ）を確認する。万一更新対象リソースが存在し、発信者に正当な権限が与えられている場合には、受信者は更新対象リソースを更新される情報（例、ｃｎ）に更新することができる。成功裏に更新された場合、受信者は応答メッセージを発信者に送信することができる。応答メッセージは次のような情報を含むことができる。
【０１０６】
−  ｔｏ：発信者ＩＤ
−  ｆｒ：受信者ＩＤ
−  ｃｎ：動作結果
【０１０７】
更に他の例として、発信者は受信者上で特定リソースを削除（ｄｅｌｅｔｅ）するために、図７に例示した手順を用いることができる。この場合、発信者は削除要求メッセージ（例、ＤＥＬＥＴＥ  ｒｅｑｕｅｓｔ）を受信者に送信することができる。削除要求メッセージは次のような情報を含むことができる。
【０１０８】
−ｏｐ：Ｄ（Ｄｅｌｅｔｅ）
−ｔｏ：削除対象リソースのＵＲＩ
−ｆｒ：発信者ＩＤ
【０１０９】
受信者は発信者から削除要求メッセージを受信すると、回収要求メッセージから削除対象リソースのＵＲＩを参照して削除対象リソースが存在するか否か検証し、対象リソースを削除するように発信者に権限が与えられているか否かを確認する。万一、対象リソースが存在していないか、発信者に権限が与えられていない場合には、受信者は応答メッセージを用いて誤り（ｅｒｒｏｒ）を送信することができる。逆に、対象リソースが存在し、発信者に権限が与えられている場合には、受信者は、次のような情報を含む応答メッセージを発信者に送信することができる。
【０１１０】
−  ｔｏ：発信者ＩＤ
−  ｆｒ：受信者ＩＤ
−  ｃｎ：動作結果
【０１１１】
図８はＭ２Ｍシステムにおいて異なるエンティティが相互連動する例を示す。
【０１１２】
図８には、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｎｏｄｅ）に登録されたＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）がＭ２Ｍデバイス（Ｍ２Ｍ  Ｄｅｖｉｃｅ）と連動する例が示されている。例えば、Ｍ２Ｍデバイスは、物理的な装置であるセンサーを含むことができ、ＩＮに登録されたＡＥは、Ｍ２Ｍデバイスのセンサー値を読み込むことができる。
【０１１３】
Ｍ２Ｍデバイス上に存在するＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）は、センサーから値を読み取り、読み取った値を、自身が登録しているＣＳＥ（ｄｃｓｅ）にリソース形態（例、＜ｃｏｎｔａｉｎｅｒ＞リソース）で保存する。そのために、Ｍ２Ｍデバイス上に存在するＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）は、Ｍ２Ｍデバイスに存在するＣＳＥにまず登録しなければならない。図８に例示するように、登録が完了すると、ｄｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ１リソースの形態で登録されたＭ２Ｍアプリケーション関連情報が保存される。例えば、Ｍ２Ｍデバイスのセンサー値がＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）によってｄｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ１リソースの下位のＣｏｎｔａｉｎｅｒリソースに保存されると、ＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｎｏｄｅ）に登録されているＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）が当該値に接近することができる。また、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）がＭ２Ｍデバイスに接近するためにはＩＮ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｎｏｄｅ）のＣＳＥ（ｎｃｓｅ）に登録しなければならない。これは、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）がＣＳＥ（ｄｃｓｅ）に登録する方法と同様に、ｎｃｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐｌｉｃａｔｉｏｎ２リソースにＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）に関する情報が保存される。また、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）は、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）と直接通信せずに、中間のＣＳＥ（ｎｃｓｅ）とＣＳＥ（ｄｃｓｅ）を介して通信することができる。そのために、ＣＳＥ（ｎｃｓｅ）とＣＳＥ（ｄｃｓｅ）は相互に登録されなければならない。ＣＳＥ（ｄｃｓｅ）がＣＳＥ（ｎｃｓｅ）に登録すると、ｎｃｓｅ／ｃｓｅｓ／ｄｃｓｅリソースの下位にｄｃｓｅ関連情報（例、Ｌｉｎｋ）が保存される。これによって、ＡＥ（ａｐｐｌｉｃａｔｉｏｎ２）はＡＥ（ａｐｐｌｉｃａｔｉｏｎ１）の情報に接近できる経路を取得し、当該経路を通じてセンサーの値を読むことができる。
【０１１４】
図９には、購読リソースに関連した手順を例示する。
【０１１５】
Ｍ２Ｍシステム（例、ｏｎｅＭ２Ｍ）では、リソースの変化に応じて、当該リソースの変化に関心を有するエンティティ（Ｅｎｔｉｔｙ）が当該変化に対する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）することができる。この場合、通知を購読するためには、購読のためのリソースが設定されなければならない。購読のためのリソースは、購読リソース又は＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースと呼ぶことができる。購読リソースが生成／設定された場合、購読リソースが設定されたデバイス（又はエンティティ）は、購読リソースに設定された条件を満たす修正／変化が購読対象リソース（ｓｕｂｓｃｒｉｂｅｄ−ｔｏ  ｒｅｓｏｕｒｃｅ又はｓｕｂｓｃｒｉｂｅｄ  ｒｅｓｏｕｒｃｅ）で発生する場合、購読リソースに設定されたアドレスに通知を送信することができる。購読リソースが設定されたり及び／又は購読対象リソースを含むデバイス（又はエンティティ）をホスティングデバイス（又はホスティングエンティティ）と呼ぶ。例えば、Ｍ２ＭゲートウェイのＣＳＥに購読対象リソースが存在することができ、この場合、Ｍ２Ｍゲートウェイをホスティングデバイスと呼び、Ｍ２ＭゲートウェイのＣＳＥをホスティングＣＳＥと呼ぶことができる。
【０１１６】
購読リソースを用いてリソース指向的な方式（ｒｅｓｏｕｒｃｅ−ｏｒｉｅｎｔｅｄ  ｍａｎｎｅｒ）で購読手順を行うことができる。例えば、特定購読対象リソースに対して購読するために購読リソースを生成することができ、購読リソースを修正することによって購読のための条件を変更することができ、購読をそれ以上希望しない場合には購読リソースを削除することができる。
【０１１７】
購読リソース（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｒｅｓｏｕｒｃｅ）は、購読対象リソース（ｓｕｂｓｃｒｉｂｅｄ−ｔｏ  ｒｅｓｏｕｒｃｅ）に関する情報を含む。購読対象リソースと購読リソースとの関係は、親−子の関係と表現することができる。例えば、購読対象リソースを含む＜ｃｏｎｔａｉｎｅｒ＞リソースは、子リソースとして＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを有することができる。親購読対象リソースが削除されるとき、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースは削除されてもよい。
【０１１８】
購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）リソースが子リソースである場合には、購読リソースの設定（属性設定）に応じて、親リソースの状態変化を指示する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）が、購読リソース内のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性に明示されたエンティティに伝達されてもよい。発信者が購読可能なリソースに対するＲＥＴＲＩＥＶＥ（又はＲＥＡＤ）権限（ｐｅｒｍｉｓｓｉｏｎ）を有する場合、発信者は購読リソースを生成することができる。購読リソースの発信者はリソース購読者となる。購読対象リソースに対する修正がある場合、その修正をフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ  ａｔｔｒｉｂｕｔｅ）と比較し、通知がリソース購読者に送信されるか否かを決定する。
【０１１９】
他の例として、購読リソースは親リソースの下の特定リソースに生成されてもよい。この場合、特定リソースは、購読リソースの集合（ｃｏｌｌｅｃｔｉｏｎ）を有するリソースであってもよく、このリソースを購読集合（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｃｏｌｌｅｃｔｉｏｎ）リソースと呼ぶことができる。例えば、特定エンティティは、＜ｒｅｓｏｕｒｃｅＵＲＩ＞／ｓｕｂｓｃｒｉｐｔｉｏｎｓ／＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞の構造として購読リソース＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞が生成されてもよいが、この場合、特定エンティティは購読リソースを介してｒｅｓｏｕｒｃｅＵＲＩによって識別されるリソースを購読することができ、ｒｅｓｏｕｒｃｅＵＲＩによって識別されるリソースに変化が発生する場合、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ属性を満たすか否かによって上記特定エンティティに通知が送信されてもよい。また、この例で、＜ｒｅｓｏｕｒｃｅＵＲＩ＞／ｓｕｂｓｃｒｉｐｔｉｏｎｓリソースは購読集合リソースに該当する。
【０１２０】
購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）は、様々な属性と子リソースを有することができる。例えば、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）は、子リソースとして、通知配達のためのスケジューリング情報を含むｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅリソースを有することができる。また、例えば、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）は表１の属性を有することができる。表１で、Ｒ／Ｗは、当該属性の読み（ｒｅａｄ）／書き（ｗｒｉｔｅ）の許容（ｐｅｒｍｉｓｓｉｏｎ）を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ  ＯＮＬＹ（ＲＯ）、ＷＲＩＴＥ  ＯＮＬＹ（ＷＯ）のうち一つであってもよい。また、表１で、発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）は、当該属性が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースにおいて発生可能な回数を示す。表１は例示に過ぎず、購読リソースの属性は表１と異なるように構成されてもよい。
【０１２１】
【表１】
2016526322.tif 000003
【０１２２】
表１の例で、フィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）は、購読対象リソースの修正／変化に対する条件のリストであり、各条件は、論理的ＡＮＤ関係にあってもよい。例えば、フィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）が２個の条件を含む場合、購読対象リソースの修正／変化が２個の条件を全て満たす場合に通知を送信することができる。購読リソースにフィルタリング属性を設定することによって通知メッセージの量を調節することができ、設定したフィルタリング属性を満たす時に、通知対象エンティティ（ｎｏｔｉｆｉｃａｔｉｏｎ  ｔａｒｇｅｔ  ｅｎｔｉｔｙ）に通知が送信されるようにし、通知メッセージがあふれる問題を防止することができる。表２に、フィルタリング属性に含まれてもよい条件を例示する。
【０１２３】
【表２】
2016526322.tif 000004
【０１２４】
図９を参照すると、デバイス１（９１０）は、デバイス２（９２０）の特定リソースを購読するために、図９に例示した手順を行うことができる。デバイス１（９１０）は、購読対象リソースの変化による通知を受ける対象であるあってもよく、対象でなくてもよい。図９の例で、特定リソースは購読対象リソースに該当し、デバイス２（９２０）は、購読対象リソースを含んでいることから、ホスティングデバイス（又はエンティティ）に該当し得る。
【０１２５】
Ｓ９０２段階で、デバイス１（９１０）は特定リソースを購読するために、購読リソースに対する要求をデバイス２（９２０）に送信することができる。例えば、購読リソースに対する要求は、購読リソースの生成要求、回収要求、削除要求、更新要求のいずれか一つであってもよい。各要求は、図７を参照して説明した要求−応答方式による要求メッセージの形態を有することができる。例えば、Ｓ９０２の要求が生成要求である場合、購読リソースに対する要求は、Ｃ（Ｃｒｅａｔｅ）を有するｏｐ情報、購読リソースの属性情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ、ｅｘｐｉｒａｔｉｏｎＴｉｍｅなど）を含むｃｎ情報、デバイス１（９１０）の識別情報を有するｆｒ情報、及び／又はデバイス２（９２０）の識別情報を有するｔｏ情報を含むことができる。他の例として、Ｓ９０２の要求が回収要求である場合、購読リソースに対する要求は、Ｒ（Ｒｅｔｒｉｅｖｅ）を有するｏｐ情報、デバイス１（９１０）の識別情報を有するｆｒ情報、デバイス２（９２０）の識別情報を有するｔｏ情報、及び／又は回収対象属性を示すｃｎ情報を含むことができる。更に他の例として、Ｓ９０２の要求が削除又は更新要求である場合、購読リソースに対する要求は、図７を参照して説明した情報の全て又は一部を含むことができる。
【０１２６】
Ｓ９０４段階で、デバイス２（９２０）は、購読リソースに対する要求を処理できるか否か検査（ｖａｌｉｄａｔｅ）し、処理できる場合には当該要求を処理する。例えば、デバイス２（９２０）が生成要求を受信する場合、ｔｏ情報に指定された購読対象リソースを購読可能か否か、要求発信者（例、９１０）が購読対象リソースに対してＲＥＴＲＩＥＶＥ権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否か、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩが要求発信者（例、９１０）を指示しない場合に、要求発信者（例、９１０）がｎｏｔｉｆｉｃａｔｉｏｎＵＲＩと指定されたエンティティ又はデバイスに通知を送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有するか否か、ホスティングデバイス又はエンティティ（例、９２０）がｎｏｔｉｆｉｃａｔｉｏｎＵＲＩと指定されたエンティティ又はデバイスに通知を送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有するか否かを検査する。これらを全て満たす場合、デバイス２（９２０）はｔｏ情報に指定された購読対象リソースの下に購読リソースを生成することができる。
【０１２７】
他の例として、デバイス２（９２０）が回収要求を受信する場合、デバイス２（９２０）は、要求発信者（例、９１０）が購読リソースに対してＲＥＴＲＩＥＶＥ権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否かを検査し、これを満たす場合、購読リソースの全て又は回収要求で指定された一部を返還（ｒｅｔｕｒｎ）することができる。
【０１２８】
更に他の例として、デバイス２（９２０）が更新要求を受信する場合、デバイス２（９２０）は、購読リソースが存在するか否か検証（ｖｅｒｉｆｙ）した後、当該属性がＷＲＩＴＥ可能な属性であるか否か、及び要求発信者（例、９１０）が修正する権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否かを検査し、これを満たす場合、提供された属性を更新する。
【０１２９】
さらに他の例として、デバイス２（９２０）が削除要求を受信する場合、デバイス２（９２０）は、要求発信者（例、９１０）がＤＥＬＥＴＥ権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否かを検査し、これを満たす場合、購読リソースを削除する。
【０１３０】
Ｓ９０６段階で、デバイス２（９２０）は、購読リソースに対する要求を処理した後、応答メッセージをデバイス１（９１０）に送信することができる。Ｓ９０６の応答メッセージは、図７を参照して説明した応答メッセージと同一／類似の形態を有することができる。また、回収要求の場合、応答メッセージは、返還される情報を含むことができる。
【０１３１】
図１０には通知のための手順を例示する。通知のための手順において発信者は、購読リソースをホスティングしているデバイス又はエンティティ（例、９２０）であってもよい。また、受信者は、購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すデバイス（又はエンティティ）であってもよい。通知のための手順のために所定の政策情報を設定することができる。このような政策情報を満たす場合に、発信者が通知メッセージ（例、ＮＯＴＩＦＹ）を送信するように設定することができる。
【０１３２】
通知メッセージ（例、ＮＯＴＩＦＹ）は、購読リソースの情報に対してトリガリングされるメッセージである。通知メッセージは、購読対象リソースの変化が購読リソースに設定されたフィルタリング属性を満たす場合、購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示す受信者に送信することができる。通知メッセージの受信者は、購読リソースの設定によって購読リソースを生成／設定したデバイス又はエンティティと同一であってもよく、異なってもよい。例えば、デバイス１（９１０）はデバイス３（９３０）と同じエンティティであってもよく、異なるエンティティであってもよい。通知メッセージは次のような情報を含むことができる。
【０１３３】
−  ｆｒ：発信者（例、９２０）の識別情報又はＩＤ
−  ｔｏ：購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）
−  ｃｎ：購読対象リソースの修正内容（ｍｏｄｉｆｉｅｄ  ｃｏｎｔｅｎｔ）を示すデータ及び／又はこの通知メッセージを生成した購読参照（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｒｅｆｅｒｅｎｃｅ）情報（例、当該購読リソースのＵＲＩ）
【０１３４】
図１０を参照すると、Ｓ１００２段階で、発信者（９２０）は、購読対象リソースの変化を検出／感知することができる。購読対象リソースは購読リソースの親リソースであり、購読対象リソースの下において購読リソースと同じレベルにあるリソース又は属性が修正／変化する場合、発信者（９２０）（例えば、ＳＵＢ  ＣＳＦ又はＣＳＥ、図３参照）は、購読対象リソースの変化として認知することができる。
【０１３５】
購読対象リソースの変化が検出される場合、Ｓ１００４段階で、発信者（９２０）は、当該変化が購読リソースに設定されたフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）とマッチングされるか否かを確認する。フィルタリング属性は、例えば、表２に例示した属性の少なくとも一つを含むことができる。購読対象リソースの変化がフィルタリング属性に含まれた条件を全て満たさない場合、発信者（９２０）は当該変化を無視することができる。
【０１３６】
万一、購読対象リソースの変化がフィルタリング属性に含まれた条件を全て満たす場合には、Ｓ１００６段階で、発信者（９２０）は、購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すエンティティ（９３０）に通知メッセージを送信することができる。Ｓ１００６の通知メッセージは、例えば、発信者（９２０）の識別情報、購読対象リソースの変更内容を示すデータ、及び／又は通知メッセージを生成した購読参照情報を含むことができる。
【０１３７】
図１１には購読リソースが用いられる例を示す。
【０１３８】
前述したように、購読リソースは、特定リソースの子リソースとして生成／設定することができ、ホスティングデバイス又はエンティティ（又は、購読リソースが生成／設定されたＭ２Ｍデバイス又はエンティティ）は、親リソースにおける状態変化を追跡（ｔｒａｃｋ）し、状態変化が発生すると、購読リソースの通知アドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）を参照して通知メッセージを送信する。この場合、購読リソースの状態変化を追跡／モニタリングすることは、例えば、購読リソースが生成／設定されたＭ２Ｍデバイスの購読／通知（ＳＵＢ）共通サービス機能（ＣＳＦ）が担当することができる（例、図３参照）。Ｍ２Ｍデバイスは、購読対象リソース（例、購読リソースの親リソース）に対して修正／変化が発生する度に、購読リソースに設定されたアドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に通知を送ることができる。
【０１３９】
しかし、購読リソースが生成／設定されたＭ２Ｍデバイスで特定動作のための要求メッセージを受信しても、購読対象リソースの変化がない場合にはＭ２Ｍデバイスは通知メッセージを送信しない。例えば、外部デバイスから回収要求メッセージ（例、ＲＥＴＲＩＥＶＥ  ｒｅｑｕｅｓｔ）を受信する場合、Ｍ２Ｍデバイスは、対象リソースの属性情報を応答メッセージを用いて回答するので、対象リソースに対する変化は発生しない。この場合、購読リソースに設定されたアドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に通知メッセージが送信されない。このため、このように購読対象リソースに変化が発生しない場合、購読者（ｓｕｂｓｃｒｉｂｅｒ）（又は購読デバイス）は購読対象リソースに対してアクセスがあった否かを確認できない。
【０１４０】
また、前述したように、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）は、購読対象リソースと親−子の関係を有するように生成／設定することができる。購読リソースが生成／設定された状況で、購読リソースと同じレベルにある他のリソース（例、購読対象リソースの子リソース又は属性）が削除される場合、これは購読対象リソースに変化が発生したことであるから、デバイス（又はそのＳＵＢ  ＣＳＦ）は、購読リソースに設定されたアドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に通知メッセージを送信する。しかし、購読リソースと異なるレベルにあるリソースは購読リソースの対象ではなく、設定された購読リソースを用いて変化を認知することができない。例えば、特定デバイスにおいてリソースはレベル別に異なるアクセス権限を有してもよい。例えば、親リソースと該親リソースの子リソースとが異なるアクセス権限を有してもよい。このため、購読リソースが設定された場合、当該購読リソースは該当のレベルに対してのみ動作でき、当該購読リソースは、他のレベルに対しては適用できない。
【０１４１】
図１１を参照すると、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）が特定リソース（例、Ｒｅｓｏｕｒｃｅ１）の子リソースとして生成されている。この場合、購読リソースはＲｅｓｏｕｒｃｅ１であり、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）によって変化を認知できる範囲は１１３０である。しかし、購読リソースと異なるレベル（例、１１４０）にあるリソースや属性の変化に対しては、購読リソース（例、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）を用いて、特定フィルタリング条件を満たす変化を認知することができない。例えば、図１１の例で、＜ｃｏｎｔａｉｎｅｒ＞リソースの下におけるａｔｔｒｉｂｕｔｅ４属性が削除されるなどの変化を認知することができない。
【０１４２】
また、購読リソースは購読対象リソースの子リソースとして生成／設定されるため、購読対象リソースが削除される場合、購読リソースも併せて削除される。したがって、購読対象リソースが削除される場合に購読リソース自体が削除されるため、購読者は購読対象リソースの削除に対して通知を受けないことがある。
【０１４３】
リソースを生成する場合にも同様の問題が発生しうる。購読対象リソースの下において購読リソースと同じレベルにリソースが生成される場合、購読対象リソースの変化が発生したため、購読者に通知が送信されてもよい。しかし、購読リソースは他のレベルにあるリソースに対してはアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有しない場合もあり、購読リソースと異なるレベルでリソースが生成される場合には購読者に通知が送信されないことがある。このように、異なるレベルにあるリソースの変化を購読したい場合には、当該レベルの親リソースの子リソースとして別の購読リソースを生成／設定しなければならない。
【０１４４】
例えば、図１１の例で、購読対象リソース（例、Ｒｅｓｏｕｒｃｅ１）の下にａｔｔｒｉｂｕｔｅ５が生成される場合、デバイス２（９２０）は、購読リソースに設定されたフィルタリング情報（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）を満たすか否か確認し、基準情報を満たす場合には、購読リソースに設定されたアドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に通知を送信することができる。しかし、図１１の例で、購読リソースと同じレベルのリソースが生成され、特定フィルタリング条件を満たす変化（例えば、ａｔｔｒｉｂｕｔｅ４が特定値を有するリソースを生成時）を認知することができない。
【０１４５】
このような問題は、購読対象リソースに対して行われる動作を購読することによって解決することができる。例えば、購読対象リソースを回収する動作が行われる場合、前述したように、回収動作（ｒｅｔｒｉｅｖｅ  ｏｐｅｒａｔｉｏｎ）が購読対象リソースの変化を発生させず、通知メッセージは発生しない。しかし、回収動作を購読するように設定することができたら、購読対象リソースの変化にかかわらず、購読対象リソースを回収する動作が行われる場合に当該動作に対する通知メッセージを発生することができる。
【０１４６】
同様に、購読リソースの下位にリソースを生成又は削除する場合にも生成又は削除動作を購読するように購読リソースを設定できれば、生成又は削除される対象リソースに対して設定されたフィルタリング属性を満たす場合に通知メッセージを発生することができる。
【０１４７】
同様に、購読対象リソース全体が削除される場合にも削除動作を購読するように購読リソースを設定できれば、購読対象リソースと購読リソースが削除される前に通知メッセージが発生し、購読対象リソースの削除が認知できる。
【０１４８】
そこで、本発明では、Ｍ２Ｍデバイスで行われる特定動作（ｏｐｅｒａｔｉｏｎ）を購読する方法を提案する。具体的には、本発明では、特定動作の購読のために、購読リソースに購読対象動作に関する条件情報を追加することを提案する。より具体的には、購読リソースのフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）に購読対象動作に対する条件情報を追加することを提案する。購読対象動作は、購読しようとする命令を意味できる。
【０１４９】
例えば、購読対象動作に関する条件情報は、購読対象リソースをアクセスする動作が特定値とマッチングされる場合に通知を行うことを示す第１条件情報を含むことができる。第１条件情報は、当該動作が行われるか否かにかかわらず、購読対象リソースにある動作が試みられているか否かをモニタリングできるようにする。例えば、第１条件情報はｏｐｅｒａｔｉｏｎＭｏｎｉｔｏｒという名前を有することができる。例えば、第１条件情報は、悪意的なアプリケーション又はデバイスが購読対象リソースにアクセスを試みる場合、アクセス権限の故リソース変化がないが、第１条件情報を購読リソース（又はフィルタリング属性）に設定することによってこのような悪意的な試み（ｍａｌｉｃｉｏｕｓ  ａｔｔｅｍｐｔ）をモニタリングすることができる。第１条件情報は、生成（Ｃｒｅａｔｅ）、回収（Ｒｅｔｒｉｅｖｅ）、更新（Ｕｐｄａｔｅ）、削除（Ｄｅｌｅｔｅ）、通知（Ｎｏｔｉｆｙ）のようなストリング因子（ｓｔｒｉｎｇ  ａｒｇｕｍｅｎｔ）に設定することができる。また、本発明に係る条件情報は、表２に例示された条件に追加設定することができる。
【０１５０】
また、本発明に係る購読対象動作に関する条件情報は、特定動作によって購読対象リソースが変化する時、購読対象リソースの変化された状態が特定状態とマッチングされる場合に通知を行うことを示す第２条件情報を含むことができる。第２条件情報は、第１条件情報とともに購読対象動作が行われた場合にリソース状態を確認する上で有用である。第２条件情報は、生成されている（Ｃｒｅａｔｅｄ）（又は、子リソースが生成されている）、更新されている（Ｕｐｄａｔｅｄ）、削除されている（Ｄｅｌｅｔｅｄ）（又は、子リソースが削除されている）のようなリソースの状態を示す値又はストリングに設定することができる。さらに、購読対象が削除される場合、（Ｉｔｓｅｌｆ  Ｄｅｌｅｔｅｄ）に設定されてもよい。例えば、第２条件情報はｒｅｓｏｕｒｃｅＳｔａｔｕｓという名前を有することができる。
【０１５１】
さらに、本発明に係る購読対象動作に関する条件情報は、購読対象動作の実行結果が特定値に該当する場合に通知を行うことを示す第３条件情報、及び／又は購読リソースに対する要求メッセージを送ったデバイス（又はエンティティ）の識別情報（例、ＵＲＩ、ＩＤ）が特定値又はストリングに該当する場合に通知を行うことを示す第４条件情報を含むことができる。例えば、第３条件情報は、成功（例えば、Ｓｕｃｃｅｓｓ、Ｏｋａｙ、Ｏｋａｙ  ａｎｄ  Ｄｏｎｅ、Ｏｋａｙ  ａｎｄ  Ｓｃｈｅｄｕｌｅｄ、Ｏｋａｙ  ａｎｄ  Ｉｎ  Ｐｒｏｇｒｅｓｓなど）又は失敗（例えば、Ｎｏｔ  ｏｋａｙ）又はエラーコードに設定することができる。例えば、第４条件情報は、正当な権限を有するデバイス又はエンティティの識別情報に設定することができる。
【０１５２】
ホスティングデバイス／エンティティは、第１条件情報と第２条件情報が同時にフィルタリング属性として設定されることを防ぐこともでき、又は同時にフィルタリング属性として設定される場合、同じ動作に対して第１条件情報と第２条件情報を設定する時に、第２条件情報を優先視し（第１条件情報を無視し）、当該動作に対しては第２条件情報を満たす時に通知し、特定動作が第１条件情報又は第２条件情報のいずれかにのみ設定されている場合には、特定動作に対しては設定されている特定条件情報（第１条件情報又は第２条件情報）を満たす時に通知する。
【０１５３】
購読対象動作に関する条件情報は、購読リソース生成手順によって購読リソースが生成／設定されるデバイス（又は、そのＣＳＥ）（又はホスティングデバイス／エンティティ）に伝達されてもよく、或いは購読リソースに対する更新手順によって当該デバイス／エンティティに伝達されてもよい。購読リソース生成手順又は更新手順では購読リソースに対する要求を送信することができ（図９参照）、購読リソースに対する要求（例、ｃｎ情報）は、図９を参照して説明した情報とは別に、購読対象動作に関する情報、購読対象動作を行った後に通知を行うリソース状態に関する情報、購読対象動作の実行結果、購読リソースに対する要求メッセージを送ったデバイス（又はエンティティ）の識別情報（例、ＵＲＩ、ＩＤ）を含むことができる。例えば、購読対象動作を行った後に通知を行うリソース状態に関する情報は、生成されている（Ｃｒｅａｔｅｄ）、削除されている（Ｄｅｌｅｔｅｄ）、回収されている（Ｒｅｔｒｉｅｖｅｄ）、更新されている（Ｕｐｄａｔｅｄ）、などを含むことができる。また、例えば、購読対象動作の実行結果は、成功（例、Ｓｕｃｃｅｓｓ、Ｏｋａｙ、Ｏｋａｙ  ａｎｄ  Ｄｏｎｅ、Ｏｋａｙ  ａｎｄ  Ｓｃｈｅｄｕｌｅｄ、Ｏｋａｙ  ａｎｄ  Ｉｎ  Ｐｒｏｇｒｅｓｓなど）又は失敗（例、Ｎｏｔ  ｏｋａｙ）又はエラーコードを含むことができる。
【０１５４】
購読リソース生成時に伝達
本発明に係る購読対象動作に関する条件情報は、購読リソースの生成要求メッセージ（例、ＣＲＥＡＴＥ  ｒｅｑｕｅｓｔ）中の特定情報に追加することができる。例えば、購読対象動作に関する条件情報は、生成要求メッセージのｃｎ情報に含まれてもよく、或いは、購読リソース生成要求メッセージを送ったデバイス（又はエンティティ）の識別情報は、生成要求メッセージのｆｒ情報に含まれてもよい。
【０１５５】
購読リソース更新にて伝達
本発明に係る購読対象動作に関する条件情報は、購読リソースの更新要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）中の特定情報に追加することもできる。例えば、購読対象動作に関する条件情報は、更新要求メッセージのｃｎ情報に含まれてもよく、或いは、購読リソース更新要求メッセージを送ったデバイス（又はエンティティ）の識別情報は、更新要求メッセージのｆｒ情報に含まれてもよい。
【０１５６】
受信者（例、受信デバイス又はエンティティ）が要求メッセージから購読対象動作に関する条件情報を受信すると、受信者は、購読リソースの下に当該条件情報を追加することができる。例えば、受信者は、購読リソースのフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）に購読対象動作に関する条件情報を追加することができる。
【０１５７】
特定動作に対する要求が受信される場合、ホスティングデバイス又はエンティティは、要求メッセージに含まれたアドレス情報（例、ｔｏ情報）を参照して当該動作が購読対象リソースに対するものか否か確認する。万一、要求メッセージに含まれたアドレス情報が購読対象リソースのＵＲＩに該当すると、購読リソースのフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）を参照して購読対象動作であるか否かを判別できる。購読対象動作に該当すると、受信者は通知メッセージを、購読リソースに含まれたアドレス（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に送信することができる。この場合、通知メッセージは、例えば、購読対象動作、購読対象動作を行った後のリソース状態、又は購読対象動作の実行結果をさらに含むことができる。例えば、購読対象動作に関する（属性）情報は、生成（Ｃｒｅａｔｅ）、削除（Ｄｅｌｅｔｅ）、回収（Ｒｅｔｒｉｅｖｅ）、更新（Ｕｐｄａｔｅ）、通知（Ｎｏｔｉｆｙ）などを含むことができる。また、例えば、購読対象動作を行った後のリソース状態に関する（属性）情報は、子リソースが生成されている（Ｃｒｅａｔｅｄ）、子リソースが削除されている（Ｄｅｌｅｔｅｄ）、更新されている（Ｕｐｄａｔｅｄ）、当該リソースが削除されている（Ｉｔｓｅｌｆ  Ｄｅｌｅｔｅｄ）、などを含むことができる。また、例えば、購読対象動作の実行結果は、成功（例、Ｓｕｃｃｅｓｓ、Ｏｋａｙ、Ｏｋａｙ  ａｎｄ  Ｄｏｎｅ、Ｏｋａｙ  ａｎｄ  Ｓｃｈｅｄｕｌｅｄ、Ｏｋａｙ  ａｎｄ  Ｉｎ  Ｐｒｏｇｒｅｓｓなど）又は失敗（例、Ｎｏｔ  ｏｋａｙ）又はエラーコードを含むことができる。例えば、要求メッセージに含まれたアドレス情報が購読対象リソースのＵＲＩと同一である場合に又は購読対象リソースのＵＲＩを含む場合に、要求メッセージに含まれたアドレス情報は購読対象リソースのＵＲＩに該当してもよく、購読リソースの設定によって特定動作に対する購読を行うことができる。
【０１５８】
図１２に、本発明に係る動作購読（ｏｐｅｒａｔｉｏｎ  ｓｕｂｓｃｒｉｐｔｉｏｎ）方法を例示する。図１２で、各デバイス９１０，９２０，９３０はＡＥ及び／又はＣＳＥを含むことができ、図１２の各段階は、各デバイス９１０，９２０，９３０に含まれたＡＥ又はＣＳＥで行うことができる。
【０１５９】
図１２を参照すると、Ｓ１２０２段階で、デバイス１（９１０）はデバイス２（９２０）に購読リソース生成のために要求メッセージ（例、ＣＲＥＡＴＥ  ｒｅｑｕｅｓｔ）を送信することができる。この場合、要求メッセージは購読対象動作に関する（属性）情報を含むことができる。もし既に購読リソースが生成されている場合には、購読リソースのうちフィルタリング属性を更新するための要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）を送信することができ、このような要求メッセージに購読対象動作に関する（属性）情報が含まれてもよい。
【０１６０】
Ｓ１２０２段階で購読リソース生成のための要求メッセージ（例、ＣＲＥＡＴＥ  ｒｅｑｕｅｓｔ）を受信する場合、デバイス２（９２０）は、要求メッセージに含まれた情報を用いて購読リソースを生成することができる。例えば、デバイス２（９２０）は、要求メッセージ（例、ＣＲＥＡＴＥ  ｒｅｑｕｅｓｔ）のｔｏ情報に含まれた購読リソースの親ＵＲＩを参照して購読リソースを生成し、ｃｎ情報に含まれた属性情報を参照して購読リソースの属性を設定することができる。この場合、購読対象動作に関する（属性）情報は、購読リソースの下のフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）に設定することができる。
【０１６１】
Ｓ１２０２段階で購読リソース更新のための要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）を受信する場合、デバイス２（９２０）は、要求メッセージに含まれた情報を用いて購読リソースを更新することができる。例えば、デバイス２（９２０）は、要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）のｔｏ情報に含まれた購読リソースのＵＲＩを参照して購読リソースの位置を把握し、ｃｎ情報に含まれた購読対象動作に関する（属性）情報を用いて購読リソースのフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）を更新することができる。又は、デバイス２（９２０）は、要求メッセージ（例、ＵＰＤＡＴＥ  ｒｅｑｕｅｓｔ）のｔｏ情報に購読リソースのフィルタリング属性のＵＲＩが含まれており、ｃｎに全体フィルタリング属性又は部分フィルタリング属性が含まれていると、購読リソースのフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）を更新することができる。
【０１６２】
Ｓ１２０２及びＳ１２０４段階でデバイス２（９２０）が購読対象動作に関する（属性）情報を受信すると、デバイス２（９２０）は、購読対象動作に関する（属性）情報を購読リソースのフィルタリング属性に追加することができる。例えば、購読対象動作に関する（属性）情報が購読対象動作を示す情報を含む場合、デバイス２（９２０）は、購読リソースのフィルタリング属性に第１条件情報（例、ｏｐｅｒａｔｉｏｎＭｏｎｉｔｏｒ）を追加することができる。又は、例えば、購読対象動作に関する（属性）情報が動作実行後の通知を行うリソース状態を示す情報を含む場合には、デバイス２（９２０）は、購読リソースのフィルタリング属性に第２条件情報（例、ｒｅｓｏｕｒｃｅＳｔａｔｕｓ）を追加することができる。又は、例えば、購読対象動作に関する（属性）情報が通知を行う購読対象動作の実行結果を示す情報を含む場合には、デバイス２（９２０）は、購読リソースのフィルタリング属性に第３条件情報を追加することができる。又は、例えば、購読対象動作に関する（属性）情報が通知を行う条件として特定デバイスの識別情報を含む場合、デバイス２（９２０）は、購読リソースのフィルタリング属性に第４条件情報を追加することができる。
【０１６３】
その後、Ｓ１２０６段階で、デバイス２（９２０）は、特定動作（例、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅなど）の実行のための要求メッセージを受信することができる。Ｓ１２０６段階の要求メッセージは、購読対象リソースのＵＲＩに対応する第１情報及び／又は購読対象リソース（又はその子リソース）に対して行われる動作を示す第２情報を含むことができる。
【０１６４】
Ｓ１２０８段階で、デバイス２（９２０）は、通知メッセージを送るための条件を満たすか否かを判別する。例えば、デバイス２（９２０）は、上記第１情報を参照して、購読対象リソースが購読リソースを有するか否かを判別できる。この場合、デバイス２（９２０）は、上記第１情報に対応する購読対象リソースが購読リソースと親−子リソース関係に該当するか否かを判別できる。又は、例えば、デバイス２（９２０）は、購読リソースのフィルタリング属性が動作購読のための条件情報（例、第１乃至第４条件情報）を含むか否かを判別できる。又は、例えば、デバイス２（９２０）は上記第２情報を参照して、購読リソースのフィルタリング属性の第１条件情報が、上記第２情報が示す動作に対応する変数を含むか否かを判別できる。又は、例えば、動作によって購読対象リソース又はその子リソースの状態が変化する場合、デバイス２（９２０）は、購読リソースのフィルタリング属性の第２条件情報が変化された状態に対応する変数を含むか否かを判別できる。又は、例えば、デバイス２（９２０）は、デバイス１（９１０）が購読対象リソースに対して回収権限（ｒｅｔｒｉｅｖｅ  ｐｅｒｍｉｓｓｉｏｎ）を有するか否かを判別できる。又は、例えば、デバイス１（９１０）とデバイス３（９３０）とが異なる場合、デバイス２（９２０）は、デバイス１（９１０）がデバイス３（９３０）に通知メッセージを送るアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔｓ）を有するか否かを判別できる。上記の例示された条件を判別し、一部又は全てを満たす場合に、デバイス２（９２０）は、購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すエンティティに通知メッセージを送信することができる。
【０１６５】
Ｓ１２０８段階で条件の一部又は全てを満たす場合、Ｓ１２１０段階でデバイス２（９２０）は、購読リソースに設定されたアドレス情報（例、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すエンティティに通知メッセージを送信することができる。この例で、購読リソースにデバイス３（９３０）（又は、その特定エンティティ又はリソース）を示すＵＲＩが設定されているとすれば、通知メッセージはデバイス３（９３０）（又は、その特定エンティティ又はリソース）に送信されてもよい。図１２の例で、デバイス１（９１０）とデバイス３（９３０）は、同じデバイス又はエンティティであってもよく、異なるデバイス又はエンティティであってもよい。
【０１６６】
Ｓ１２１０で送信される通知メッセージは、例えば、第１条件情報が購読リソースのフィルタリング属性に追加される場合、購読対象動作に関する情報（例、Ｓ１２０６段階の第２情報に対応する情報）を含むことができる。同様に、通知メッセージは、例えば、第２条件情報が購読リソースのフィルタリング属性に追加される場合、購読対象動作を行った後のリソース状態を示す情報を含むことができる。同様に、第３条件情報／第４条件情報が購読リソースのフィルタリング属性に追加される場合、通知メッセージは、対応する情報を含むことができる。
【０１６７】
図１２に例示した方法によれば、購読対象動作が回収（Ｒｅｔｒｉｅｖｅ）動作であるがためリソース状態の変化がなくても、通知メッセージを送信することができる。また、購読対象動作が生成（Ｃｒｅａｔｅ）動作である場合、購読対象リソースの下において購読リソースと異なるレベルにあるリソースに対する生成である場合にも通知メッセージを送信することができる。同様に、購読対象動作が削除（Ｄｅｌｅｔｅ）動作である場合、購読対象リソース全体が削除される場合にも通知メッセージを送信することができる。
【０１６８】
また、特定動作を購読するように購読リソースを設定したとしても、購読対象リソースの状態変化がある場合、前述したように、購読リソースに設定されたアドレスに通知を送信することができる。したがって、特定動作がフィルタリング属性を満たさない場合にも、購読リソースの設定によって通知を送信することができる。ただし、この場合、通知メッセージには購読対象動作と関連した情報がさらに含まれない。例えば、特定動作がフィルタリング属性を満たさず、購読対象リソースの状態変化のみがある場合、通知メッセージは、購読対象リソースの変更内容、変更されたＵＲＩ又は付加情報などを含むことができる。
【０１６９】
図１３は、本発明に係る実施例を示す。図１３の例で、ＣＳＥＢａｓｅリソース１３２０の下に購読リソース１３５０が生成されていると仮定する。したがって、購読対象リソースはＣＳＥＢａｓｅリソース１３２０である。また、フィルタリング属性１３５２は、本発明に係る第１条件情報と第２条件情報が設定されていると仮定する。例えば、フィルタリング属性１３５２において第２条件情報はＣＲＥＡＴＥＤに設定されていると仮定する。また、購読リソースのアドレス情報１３５４はスマートグリッド管理サーバーのＵＲＩに設定されていると仮定する。
【０１７０】
図１３の例で、Ｍ２Ｍデバイス９１０はスマートメーター（ｓｍａｒｔ  ｍｅｔｅｒ）として動作し、共通サービス層を有しないＡＤＮ（Ａｐｐｌｉｃａｔｉｏｎ  Ｄｅｄｉｃａｔｅｄ  Ｎｏｄｅ）と仮定する。このため、Ｍ２Ｍデバイス９１０は、制限された能力を有し、独自でデータを保存したり管理できず、検針データを全てＭ２Ｍゲートウェイ９２０に保存することができる。Ｍ２Ｍデバイス９１０は周期的に電力使用量を検針し、当該周期に使用した使用量を保存するためにＭ２Ｍゲートウェイ９２０における自身のアプリケーションリソース１３３２の下に属性を生成することができる。例えば、当該検針された使用量を保存するために、ｓｍａｒｔＭｅｔｅｒＶａｌ属性１３４０を生成することができる。そのために、Ｍ２Ｍデバイス９１０は、生成要求メッセージをＭ２Ｍゲートウェイ９２０に送信することができる。この例で、生成要求メッセージは、次のような情報を含むことができる。
【０１７１】
−  ｏｐ：要求される動作を示すのでＣ（Ｃｒｅａｔｅ）に設定
−  ｔｏ：生成対象リソースの親ＩＤを示すので”ＣＳＥＢａｓｅ／ｓｍａｒｔＭｅｔｅｒＡＥ”に設定
−  ｆｒ：生成要求メッセージの発信者識別情報を示すので”ｓｍａｒｔＭｅｔｅｒＡＥ”に設定
−  ｃｎ：生成対象属性の名前として”ｓｍａｒｔＭｅｔｅｒＶａｌ”とデータ”１００”を含む
【０１７２】
Ｍ２Ｍゲートウェイ９２０は、上記生成要求メッセージを受信すると、前述した手順によって生成要求メッセージに含まれた情報を用いてｓｍａｒｔＭｅｔｅｒＶａｌ属性１３４０を生成することができる。また、Ｍ２Ｍゲートウェイ９２０は、ｔｏ情報を参照して、購読対象リソースに対する動作であることがわかり、フィルタリング属性１３５２を参照して、フィルタリング属性１３５２に第２条件情報がＣＲＥＡＴＥＤに設定されていることがわかる。この例で、生成要求メッセージに含まれた動作に関する情報（例、ｏｐ）がＣ（Ｃｒｅａｔｅ）に設定されており、生成要求メッセージによってｓｍａｒｔＭｅｔｅｒＶａｌ属性１３４０が成功裏に生成されているため、Ｍ２Ｍゲートウェイ９２０は、当該動作がフィルタリング属性を満たすと判別できる。したがって、Ｍ２Ｍゲートウェイ９２０は、購読リソースに設定されたアドレス情報１３５４が示すスマートグリッド管理サーバーに通知メッセージを送信することができる。この場合、通知メッセージは、購読対象動作に関する情報（例、ＣＲＥＡＴＥ）と当該動作実行後のリソース状態に関する情報（例、ＣＲＥＡＴＥＤ）を含むことができる。
【０１７３】
Ｍ２Ｍデバイス９１０がリソース生成権限を有しないか又はｓｍａｒｔＭｅｔｅｒＡＥリソース１３３２に対して権限がない場合には、Ｍ２Ｍゲートウェイ９２０が当該リソースを生成できず、通知は発生しない。このようにＭ２Ｍデバイス９１０が正当な権限を有していない場合にも、購読リソースのフィルタリング属性１３５２に本発明に係る第１条件情報さえ設定されていれば、通知を発生させることができる。
【０１７４】
一方、購読リソースのフィルタリング属性１３５２に本発明に係る第１条件情報も第２条件情報も設定されていない場合には、ｓｍａｒｔＭｅｔｅｒＶａｌ属性１３４０が成功裏に生成されても、（アクセス権限問題などによって）購読リソース１３５０の範囲に該当しないリソースの変化であるがため通知は発生しない。この場合には、スマートグリッド管理サーバーがスマートメートル９１０によって生成された検針情報を即座に把握できないという問題が発生しうる。
【０１７５】
第１条件情報と第３条件情報の組合せにより、購読対象リソースに対して第１条件情報で明示した動作に対して、第３条件情報で明示した実行結果又は失敗に関する条件を満たす場合に通知を行うことができる。勿論、第４条件情報の組合せにより、第４条件情報で明示した発信者条件を満たす場合に、通知を行うことができる。
【０１７６】
また、本発明の第１条件情報及び／又は第２条件情報は、表２に例示した属性と結合して用いられてもよい。例えば、第１条件情報がリソースタイプに関連した条件情報（例、ｒｅｓｏｕｒｃｅＴｙｐｅ）と共に設定される場合、特定リソースタイプに対する動作をモニタリングすることができる。例えば、第１条件情報がＣＲＥＡＴＥに設定され、リソースタイプに関連した条件情報（例、ｒｅｓｏｕｒｃｅＴｙｐｅ）が＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＡＥ＞に設定される場合、アプリケーションエンティティリソースタイプ（＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＡＥ＞）のインスタンスが生成されるとき、通知メッセージが送信されてもよい。他の例として、第１条件情報が特定リソースのラベルに関連した条件情報（例、ｌａｂｅｌｓ）と共に設定されるとき、当該ラベルを有するリソースに対する動作をモニタリングすることができる。さらに他の例として、第１条件情報が特定コンテンツタイプに関連した条件情報（例、ｃｏｎｔｅｎｔＴｙｐｅ）と共に設定されるとき、当該コンテンツタイプを有するリソースに対する動作をモニタリングすることができる。
【０１７７】
また、本発明の第２条件情報（例、ｒｅｓｏｕｒｃｅＳｔａｔｕｓ）も表２に例示した属性と結合して用いられてもよい。例えば、第２条件情報がリソースタイプに関連した条件情報（例、ｒｅｓｏｕｒｃｅＴｙｐｅ）と共に設定される場合、特定リソースタイプに関連した動作の結果が第２条件情報を満たすか否かをモニタリングすることができる。他の例として、第１条件情報が特定リソースのラベルに関連した条件情報（例、ｌａｂｅｌｓ）と共に設定される場合、当該ラベルを有するリソースに対する動作の結果が第２条件情報を満たすか否かをモニタリングすることができる。さらに他の例として、第１条件情報が特定コンテンツタイプに関連した条件情報（例、ｃｏｎｔｅｎｔＴｙｐｅ）と共に設定される場合、当該コンテンツタイプを有するリソースに対する動作の結果が第２条件情報を満たすか否かをモニタリングすることができる。
【０１７８】
本明細書では明示的に例示していないが、表２に例示した条件情報と本発明に係る条件情報（例、第１乃至第４条件情報）とを結合して他の動作をモニタリングするようにフィルタリング属性（例、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ）に設定できることも明らかであろう。
【０１７９】
本発明に係る動作購読方法が適用される場合、リソース変化が発生しない動作に対しても購読が可能である。したがって、ＤＤＯＳ攻撃のような悪意的攻撃にも柔軟に対処できるという長所がある。また、本発明が適用される場合、実行されない命令に対しても購読が可能なため、特定デバイスのアクセス権限設定誤り又は悪意的な試みに対して効率的に対処でき、有利である。また、本発明が適用される場合、動作購読を用いて特定動作を追跡（ｔｒａｃｋ）できるため、特定リソースに対してどのような動作が行われるかに関する統計情報を構築できるという長所がある。また、本発明が適用される場合、リソース変化の他、特定動作に対する条件もさらに設定できるため、不要な通知メッセージを低減し、関心のある通知メッセージのみを選別的に購読することができる。また、本発明が適用される場合、動作購読によって実時間でリソース／属性に関する情報を更新でき、有利である。このように、本発明に係る動作購読方式は、非常に有利な効果を提供するため、強力である。
【０１８０】
本発明に係る動作購読方式に適用し得るアクセス制御（ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ）方法を説明する。
【０１８１】
１．回収動作に対してアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔ）がある場合、動作購読が可能である。
【０１８２】
２．特定動作の購読時に、当該動作で使用するアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔ）値と異なるアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔ）値を使用することができる。例えば、リソース回収のためのアクセス権限値と回収動作購読のためのアクセス権限値として異なる値を使用することができる。
【０１８３】
３．特定動作の購読時に、当該動作に対してアクセス権限（ａｃｃｅｓｓ  ｒｉｇｈｔ）がある場合、当該動作に対する購読が可能である。例えば、リソースを生成し得るアクセス権限がある場合に、生成動作の購読が可能である。
【０１８４】
通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信する際、送信するリソースに回収権限があると通知を送信し、回収権限がない場合には通知を送信しなくてもよい。
【０１８５】
図１４は、本発明を適用し得る装置のブロック図である。本発明において、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバー又はＭ２Ｍデバイスはそれぞれ、送信装置１０又は受信装置２０として動作することができる。
【０１８６】
送信装置１０と受信装置２０は、情報及び／又はデータ、信号、メッセージなどを運ぶ無線信号を送信又は受信できるＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）ユニット１３，２３と、無線通信システムにおける通信に関連した各種情報を記憶するメモリ１２，２２と、ＲＦユニット１３，２３及びメモリ１２，２２の構成要素と動作時に接続（ｏｐｅｒａｔｉｖｅｌｙ  ｃｏｎｎｅｃｔｅｄ）され、当該装置が前述した本発明の実施例のうち少なくとも一つを実行するようにメモリ１２，２２及び／又はＲＦユニット１３，２３を制御するように構成されたプロセッサ１１，２１と、をそれぞれ備える。
【０１８７】
メモリ１２，２２は、プロセッサ１１，２１の処理及び制御のためのプログラムを格納することができ、入／出力される情報を記憶することができる。メモリ１２，２２はバッファーとして活用されてもよい。また、メモリ１２，２２は各種の設定情報とデータを含むリソースを記憶するために用いられてもよい。
【０１８８】
プロセッサ１１，２１は、通常、送信装置又は受信装置における各種モジュールの動作全般を制御する。特に、プロセッサ１１，２１は、本発明を実行するための各種の制御機能を有することができる。プロセッサ１１，２１は、コントローラ（ｃｏｎｔｒｏｌｌｅｒ）、マイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ（ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などと呼ぶことができる。プロセッサ１１，２１は、ハードウェア（ｈａｒｄｗａｒｅ）、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア、又はそれらの結合によって具現することができる。ハードウェアを用いて本発明を具現する場合には、本発明を実行するように構成されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）などをプロセッサ１１，２１に備えることができる。一方、ファームウェアやソフトウェアを用いて本発明を具現する場合には、本発明の機能又は動作を実行するモジュール、手順又は関数などを含むようにファームウェアやソフトウェアが構成されてもよい。本発明を実行するように構成されたファームウェア又はソフトウェアは、プロセッサ１１，２１に組み込まれたり、メモリ１２，２２に格納されてプロセッサ１１，２１によって駆動されてもよい。
【０１８９】
送信装置１０のプロセッサ１１は、プロセッサ１１又はプロセッサ１１と接続されたスケジューラからスケジューリングされて外部に送信される信号及び／又はデータに対して所定の符号化（ｃｏｄｉｎｇ）及び変調（ｍｏｄｕｌａｔｉｏｎ）を行った後、ＲＦユニット１３に送信する。受信装置２０の信号処理過程は、送信装置１０の信号処理過程と逆に構成される。プロセッサ２１の制御下に、受信装置２０のＲＦユニット２３は、送信装置１０によって送信された無線信号を受信する。プロセッサ２１は、受信アンテナを介してて受信された無線信号に対する復号（ｄｅｃｏｄｉｎｇ）及び復調（ｄｅｍｏｄｕｌａｔｉｏｎ）を行い、送信装置１０が本来送信しようとしたデータを復元することができる。
【０１９０】
ＲＦユニット１３，２３は一つ以上のアンテナを具備する。アンテナはプロセッサ１１，２１の制御下に、本発明の一実施例によって、ＲＦユニット１３，２３によって処理された信号を外部に送信したり、外部から無線信号を受信してＲＦユニット１３，２３に伝達する機能を果たす。図１４では送信装置と受信装置がそれぞれＲＦユニットを介して通信するとしたが、送信装置と受信装置とが有線ネットワークを介して通信することも可能である。この場合、ＲＦユニットはネットワークインターフェースユニット（ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ  ｕｎｉｔ、ＮＩＵ）に取り替わってもよい。
【０１９１】
以上説明した実施例は本発明の構成要素と特徴が所定の形態で結合されたものである。各構成要素又は特徴は、別の明示的な言及がない限り、選択的なものとして考慮しなければならない。各構成要素又は特徴を他の構成要素や特徴と結合されない形態で実施してもよく、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は他の実施例に含まれてもよく、又は他の実施例の対応する構成又は特徴に取って代わってもよい。特許請求の範囲で明示的な引用関係にない請求項を結合して実施例を構成してもよく、出願後の補正によって新しい請求項として含めてもよいことは明らかである。
【０１９２】
本文書で基地局によって行われると説明した特定動作は、場合によっては、その上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）によって行われてもよい。すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）で構成されるネットワークにおいて端末との通信のために行われる様々な動作は、基地局又は基地局以外の他のネットワークノードで行われることは明らかである。基地局は、固定局（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）、Ｎｏｄｅ  Ｂ、ｅＮｏｄｅ  Ｂ（ｅＮＢ）、アクセスポイント（ａｃｃｅｓｓ  ｐｏｉｎｔ）などの用語に代えてもよい。また、端末は、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＭＳＳ（Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）などの用語に代えてもよい。
【０１９３】
本発明に係る実施例は、様々な手段、例えば、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア又はそれらの結合などによって具現することができる。ハードウェアによる具現の場合、本発明の一実施例は１つ又はそれ以上のＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。
【０１９４】
ファームウェアやソフトウェアによる具現の場合、本発明は、以上説明した機能又は動作を実行するモジュール、手順、関数などの形態を含むソフトウェアコード又は命令語（ｉｎｓｔｒｕｃｔｉｏｎ）として具現することができる。ソフトウェアコード又は命令語は、コンピュータ読み取り可能な媒体に記憶されてプロセッサによって駆動され、プロセッサによって駆動される時、本発明に係る動作を実行することができる。コンピュータ読み取り可能な媒体は、プロセッサの内部又は外部に設けられたり、遠隔でネットワークを介してプロセッサと接続され、当該プロセッサとデータを交換することができる。
【０１９５】
本発明の特徴から逸脱しない範囲で本発明を他の特定の形態として具体化できることが当業者にとっては明らかである。したがって、上記の詳細な説明はいずれの面においても制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は、添付した請求項の合理的な解釈によって決定されなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。
【産業上の利用可能性】
【０１９６】
本発明は、端末、サーバー、ゲートウェイなどのような通信装置に用いることができる。
【図１】
2016526322.tif 000005
【図２】
2016526322.tif 000006
【図３】
2016526322.tif 000007
【図４】
2016526322.tif 000008
【図５】
2016526322.tif 000009
【図６】
2016526322.tif 000010
【図７】
2016526322.tif 000011
【図８】
2016526322.tif 000012
【図９】
2016526322.tif 000013
【図１０】
2016526322.tif 000014
【図１１】
2016526322.tif 000015
【図１２】
2016526322.tif 000016
【図１３】
2016526322.tif 000017
【図１４】
2016526322.tif 000018
【国際調査報告】
2016526322.tif 000019
2016526322.tif 000020
2016526322.tif 000021
2016526322.tif 000022