JP6254702B2 - Ｍ２ｍシステムにおける通知メッセージ伝達方法及びこのための装置 - Google Patents

Description

本発明は、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）通信システムに関し、より具体的には、Ｍ２Ｍシステムで特定資源をサブスクリプションして通知する方法及びこのための装置に関する。

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

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

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

本発明の他の目的は、Ｍ２Ｍシステムでエンティティ間の連結状態が保障されない環境で通知メッセージを送受信する方法及びこのための装置を提供することにある。

本発明の更に他の目的は、Ｍ２Ｍシステムで不要な通知メッセージを伝送しないことによって、データ伝送効率及びシステム全体の性能を改善する方法及びこのための装置を提供することにある。

本発明の更に他の目的は、Ｍ２Ｍシステムで通知メッセージの重要度を設定可能にすることによって、ユーザーによって設定された重要メッセージに対して優先的に伝送する方法及びこのための装置を提供することにある。

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

本発明の一様相として、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）デバイスで資源サブスクリプション（ｒｅｓｏｕｒｃｅ ｓｕｂｓｃｒｉｐｔｉｏｎ）のための通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を行う方法が開示され、前記方法は、サブスクリプション資源を子資源として含むサブスクリプション対象資源の変化を検出することと、前記サブスクリプション資源に設定された第２の属性情報によって前記変化のイベントカテゴリーを指示する値を含む通知メッセージを生成することと、前記Ｍ２Ｍデバイスのためのスケジューリング資源に設定されたスケジューリング情報及び受信デバイスのためのスケジューリング資源に設定されたスケジューリング情報に基づいて前記受信デバイスへの到達可能性を判別することとを含み、前記スケジューリング情報によって前記受信デバイスが到達可能であると判別される場合、前記通知メッセージは、直ちに前記受信デバイスに伝送され、前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、前記サブスクリプション資源に設定された第１の属性情報が有する値によって前記Ｍ２Ｍデバイスで処理され、前記処理された通知メッセージは、前記受信デバイスが到達可能な状態に回復された後、前記受信デバイスに伝送され得る。

本発明の他の様相として、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）デバイスが提供され、前記Ｍ２Ｍデバイスは、ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｕｎｉｔ）と、前記ネットワークインターフェースユニットと動作時に連結される（ｏｐｅｒａｔｉｖｅｌｙ ｃｏｎｎｅｃｔｅｄ）プロセッサとを含み、前記プロセッサは、サブスクリプション資源を子資源として含むサブスクリプション対象資源の変化を検出し、前記サブスクリプション資源に設定された第２の属性情報によって前記変化のイベントカテゴリーを指示する値を含む通知メッセージを生成し、前記Ｍ２Ｍデバイスのためのスケジューリング資源に設定されたスケジューリング情報及び受信デバイスのためのスケジューリング資源に設定されたスケジューリング情報に基づいて前記受信デバイスへの到達可能性を判別するように構成され、前記スケジューリング情報によって前記受信デバイスが到達可能であると判別される場合、前記通知メッセージは、直ちに前記受信デバイスに伝送され、前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、前記サブスクリプション資源に設定された第１の属性情報が有する値によって前記Ｍ２Ｍデバイスで処理され、前記処理された通知メッセージは、前記受信デバイスが到達可能な状態に回復された後、前記受信デバイスに伝送され得る。

好ましくは、前記サブスクリプション資源及び前記スケジューリング資源のそれぞれは、固有のアドレスを用いて固有にアドレッシング可能なデータ構造を示すことができる。

好ましくは、前記第２の属性情報は、前記サブスクリプション資源によってトリガリングされる前記通知メッセージのためのイベントカテゴリーを定義し、前記通知メッセージに含まれたイベントカテゴリーを指示する値は、前記受信デバイスが前記通知メッセージを正確にハンドリングするために用いることができる。

好ましくは、前記第１の属性情報は、前記スケジューリング情報によって前記受信デバイスに到達可能でない期間が経過した後、前記Ｍ２Ｍデバイスが行う通知メッセージの処理動作を指示することができる。

好ましくは、前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージを処理することは、前記第１の属性情報が第１の値を有する場合、前記生成された通知メッセージを廃棄することと、前記第１の属性情報が第２の値を有する場合、前記生成された通知メッセージを格納し、以前に格納された通知メッセージを廃棄することと、前記第１の属性情報が第３の値を有する場合、前記生成された通知メッセージを全て格納することとを含むことができる。

好ましくは、前記Ｍ２Ｍデバイスのスケジューリング情報が到達可能であることを指示し、且つ、前記受信デバイスのスケジューリング情報が到達可能であることを指示する場合、前記受信デバイスは到達可能であると判別され得る。

好ましくは、前記Ｍ２Ｍデバイスのスケジューリング情報が到達不可であることを指示し、又は、前記受信デバイスのスケジューリング情報が到達不可であることを指示する場合、前記受信デバイスは到達不可であると判別され得る。

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

本発明によると、Ｍ２Ｍシステムでエンティティ間の連結状態が保障されない環境で通知メッセージを送受信することができる。

本発明によると、Ｍ２Ｍシステムで不要な通知メッセージを伝送しないことによって、データ伝送効率及びシステム全体の性能を改善することができる。

本発明によると、Ｍ２Ｍシステムで通知メッセージの重要度を設定可能にすることによって、ユーザーによって設定された重要メッセージに対して優先的に伝送することができる。

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

添付の図面は、本発明に関する理解を助けるために詳細な説明の一部として含まれ、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

Ｍ２Ｍシステムを例示する。 Ｍ２Ｍシステムの階層構造（ｌａｙｅｒｅｄ ｓｔｒｕｃｔｕｒｅ）を例示する。 Ｍ２Ｍシステムの機能的アーキテクチャー（ｆｕｎｃｔｉｏｎａｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を例示する。 Ｍ２Ｍシステムの構成を例示する。 Ｍ２Ｍシステムで使われるリソース（ｒｅｓｏｕｒｃｅ）を例示する。 特定Ｍ２Ｍアプリケーションのためのリソースを例示する。 一般的なＭ２Ｍシステムの通信フローを例示する。 Ｍ２Ｍシステムにおいて異なるエンティティが相互連動する例を示す。 サブスクリプション資源と関連する手順を例示する図である。 通知のための手順を例示する図である。 連結状態が保障されない環境でのサブスクリプション及び通知過程を例示する図である。 連結状態が保障されない環境でのサブスクリプション及び通知過程を例示する図である。 通知政策情報による通知方法を例示する図である。 通知政策情報による通知方法を例示する図である。 通知政策情報による通知方法を例示する図である。 通知政策情報による通知方法を例示する図である。 本発明に係る通知過程を例示する図である。 本発明に係る通知過程の実施例を例示する図である。 本発明を適用し得る装置のブロック図を例示する。

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

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

本明細書で、Ｍ２Ｍデバイス（Ｍ２Ｍ ｄｅｖｉｃｅ）とは、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）通信のためのデバイスを指す。Ｍ２Ｍデバイスは、固定していたり移動性を有することができ、Ｍ２Ｍサーバーと通信してユーザデータ及び／又は制御情報を送受信することができる。Ｍ２Ｍデバイスは、端末（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、ＵＴ（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅ Ｓｔａｔｉｏｎ）、無線装置（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、無線モデム（ｗｉｒｅｌｅｓｓ ｍｏｄｅｍ）、携帯装置（ｈａｎｄｈｅｌｄ ｄｅｖｉｃｅ）などと呼ぶことができる。本発明において、Ｍ２Ｍサーバーは、Ｍ２Ｍ通信のためのサーバーを意味し、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）又は移動局（ｍｏｂｉｌｅ ｓｔａｔｉｏｎ）として具現することができる。Ｍ２Ｍサーバーは、Ｍ２Ｍデバイス及び／又は他のＭ２Ｍサーバーと通信してデータ及び制御情報を交換することができる。また、Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスが接続しているネットワークとＭ２Ｍサーバーが接続しているネットワークとが異なる場合、あるネットワークから他のネットワークに入る接続点の役目を担う装置のことを指す。また、Ｍ２Ｍゲートウェイは、Ｍ２Ｍデバイスとして機能することができ、その他にも、例えば、Ｍ２Ｍゲートウェイに接続されたＭ２Ｍデバイスを管理したり、一つのメッセージを受信し、接続されたＭ２Ｍデバイスにそのままの又は変更されたメッセージを伝達したり（ｍｅｓｓａｇｅ ｆａｎｏｕｔ）、メッセージ集積（ｍｅｓｓａｇｅ ａｇｇｒｅｇａｔｉｏｎ）を行う機能を有することができる。Ｍ２Ｍデバイスという用語は、Ｍ２ＭゲートウェイとＭ２Ｍサーバーを含む概念で使うことができ、このことから、Ｍ２ＭゲートウェイとＭ２ＭサーバーはＭ２Ｍデバイスと呼ぶことができる。

また、本明細書で、“エンティティ（ｅｎｔｉｔｙ）”という用語は、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバーのようなハードウェアを指すこともでき、又は、後述するＭ２Ｍアプリケーション層とＭ２Ｍ（共通）サービス層のソフトウェアコンポーネント（ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ）を指すこともできる。

以下では本発明がＭ２Ｍシステムを中心に説明されるが、本発明は、Ｍ２Ｍシステムに制限されず、例えば、クライアント−サーバー（又は、送信者−応答者（ｓｅｎｄｅｒ−ｒｅｓｐｏｎｄｅｒ））モデルによるシステムにも同一／類似に適用可能である。

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

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

Ｍ２Ｍサービスは、サービス能力（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ、ＳＣ）の集合の形態で提供され、Ｍ２Ｍアプリケーションはオープンインターフェース（ｏｐｅｎ ｉｎｔｅｒｆａｃｅ）を介してＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）の集合又はＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）にアクセスし、ＳＣ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ）の提供するＭ２Ｍサービス又は機能を利用することができる。ＳＣは、Ｍ２Ｍサービスを構成する機能（例えば、デバイスの管理、位置、発見、グループ管理、登録、保安など）を提供することができ、ＳＣ層（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｉｅｓ Ｌａｙｅｒ）又はＳＣエンティティ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｅｎｔｉｔｙ）は、Ｍ２Ｍアプリケーションがサービスフレームワーク上で提供される時に使用し得るＭ２Ｍサービスのための機能（ｆｕｎｃｔｉｏｎ）の集合といえる。

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

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

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

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

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

Ｍ２Ｍ ＳＣは、複数のＭ２Ｍネットワークアプリケーションで共有可能なＭ２Ｍ共通サービス機能（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ、ＣＳＦ）を提供し、Ｍ２Ｍサービスをオープンインターフェース（ｏｐｅｎ ｉｎｔｅｒｆａｃｅ）を介して露出することでＭ２ＭアプリケーションがＭ２Ｍサービスを利用できるようにする。Ｍ２Ｍ ＳＣＬ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｌａｙｅｒ）は、このようなＭ２Ｍ ＳＣエンティティ又はＭ２Ｍ共通サービス機能を含む階層を意味することができる。

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

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

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

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

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

図１に例示したように、Ｍ２Ｍシステムは、Ｍ２Ｍ通信のためにＭ２Ｍアプリケーション層とＭ２Ｍ ＳＣ層を含む階層構造として理解されてもよい。

図２にはＭ２Ｍシステムの階層構造（ｌａｙｅｒｅｄ ｓｔｒｕｃｔｕｒｅ）を例示する。

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

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

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

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

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

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

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

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

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

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

− 発見（Ｄｉｓｃｏｖｅｒｙ，ＤＩＳ）：与えられた範囲及び条件内で要請に応じて情報及びリソース（ｒｅｓｏｕｒｃｅ）のような情報を検索（ｓｅａｒｃｈｉｎｇ）する。

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

− 位置（Ｌｏｃａｔｉｏｎ、ＬＯＣ）：Ｍ２ＭアプリケーションがＭ２Ｍデバイス又はＭ２Ｍゲートウェイの位置情報を取得できるようにする役割を担う。

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

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

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

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

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

−サブスクリプション／通知（Ｓｕｂｓｃｒｉｐｔｉｏｎ／Ｎｏｔｉｆｉｃａｔｉｏｎ、ＳＵＢ）：特定リソース（ｒｅｓｏｕｒｃｅ）に対する変更をサブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ）し、当該リソース（ｒｅｓｏｕｒｃｅ）が変更されるとそれを通知（ｎｏｔｉｆｉｃａｔｉｏｎ）する役割を担う。

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

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

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

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

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

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

ケース２は、ＡＤＮとＭＮとの間の通信を例示する。ＡＤＮも、制限された能力を有するＭ２Ｍデバイスであってもよい。このため、ＡＤＮがＭＮのＣＳＥと通信する以外は、ケース１と略同様に動作することができる。すなわち、ＡＤＮはＭｃａを介してＭＮのＣＳＥと通信することができる。また、ＡＤＮは、ＣＳＥ又は共通サービス層を有しておらず、ＡＥ又はアプリケーション層で生成されたデータを他のエンティティに保存／共有することができない。このため、ＡＤＮのＡＥ又はアプリケーション層で生成されたデータは、ＭＮのＣＳＥに保存して共有することができる。

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

ケース３は、ＡＳＮとＭＮとの間の通信を例示する。ケース１又はケース２と違い、ＡＳＮはＣＳＥ又は共通サービス層を有しているため、ＡＳＮのＡＥ又はアプリケーション層で生成されたデータを自身のＣＳＥ又は共通サービス層に保存することができる。また、ＡＳＮのＡＥは、ＡＳＮのＣＳＥを介してＭＮのＣＳＥと通信することができる。

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

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

図５には、Ｍ２Ｍシステムで用いられるリソース（ｒｅｓｏｕｒｃｅ）を例示する。

Ｍ２Ｍシステムにおいてアプリケーションエンティティ（ＡＥ）、ＣＳＥ、データなどはリソース（ｒｅｓｏｕｒｃｅ）と表現することができる。Ｍ２Ｍシステムにおいて、リソースは、固有のアドレス（例えば、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ又はＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ））を用いて固有にアドレシング可能なエンティティ（ｕｎｉｑｕｅｌｙ ａｄｄｒｅｓｓａｂｌｅ ｅｎｔｉｔｙ）を意味する。Ｍ２Ｍシステムでリソースは特定データ構造と表現され、各リソースは互いに論理的に連結されてもよい。リソースは、ＣＳＥ又は共通サービス層によって管理されて保存されてもよい。このため、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサーバーのＣＳＥ又は共通サービス層ではこのようなリソースを有することができる。一方、Ｍ２ＭシステムのＡＥ又はアプリケーション層ではこのようなリソース構造を有することができない。各リソースは子リソースと属性を有する。Ｍ２Ｍリソースでルート（Ｒｏｏｔ）リソースは属性（ａｔｔｒｉｂｕｔｅ）と子リソース（ｃｈｉｌｄ ｒｅｓｏｕｒｃｅ）を有することができる。例えば、リソースをツリー構造で表現することができる。例えば、ルートリソースのタイプは、＜ｂａｓｅＵＲＩ＞又は＜ＣＳＥＢａｓｅ＞と表示することができる。リソースのタイプは、“＜”と“＞”で表示することができる。

Ｍ２Ｍシステムでは様々なリソースタイプが定義されるが、Ｍ２Ｍアプリケーションは、リソースタイプが実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）されたリソースに基づいて通信を行うことができる。例えば、アプリケーションを登録し、センサー値を読み込むなどのＭ２Ｍサービスを行うために用いられてもよい。それぞれのリソースは、該当のリソースタイプのインスタンスが生成される際に固有のアドレス情報（例えば、ＵＲＩ）が与えられ、ルートリソースと同様に、属性及び子リソースを有することができる。各リソースは、固有のアドレス情報を用いてアドレシングされてもよい。特定リソースタイプは、該当のリソースが実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）された時に有し得る子リソースと属性を定義する。特定リソース実体化（Ｉｎｓｔａｎｔｉａｔｉｏｎ）の際、リソースは、当該リソースのリソースタイプに定義された属性と子リソースを有することができる。

属性は、リソース自体に関する情報を保存し、子リソースを有することができない。子リソースは、自身の属性と自身の子リソースを有することができ、例えば、子リソースには、遠隔ＣＳＥリソース、アプリケーションエンティティリソース、アクセス制御リソース、コンテナリソース、グループリソース、サブスクリプションリソースなどがある。

− 遠隔ＣＳＥリソース：当該ＣＳＥに登録（連結）された他のＣＳＥの情報を含む。例えば、遠隔ＣＳＥリソースのタイプは、＜ｅｎｔｉｔｙ＞又は＜ｒｅｍｏｔｅＣＳＥ＞と表示することができる。

− アプリケーションエンティティリソース：ルートリソースのアプリケーションエンティティリソース（例えば、＜ｂａｓｅＵＲＩ＞／＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞）又はルートリソースの遠隔ＣＳＥリソース（例えば、＜ｂａｓｅＵＲＩ＞／＜ｅｎｔｉｔｙ＞又は＜ＣＳＥＢａｓｅ＞／＜ｒｅｍｏｔｅ ＣＳＥ＞）の下位に存在するリソースであり、ルートリソースのアプリケーションエンティティリソース（例えば、＜ｂａｓｅＵＲＩ＞／＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＣＳＥＢａｓｅ＞／＜ＡＥ＞）の下位に存在する場合、当該ＣＳＥに登録（連結）されたアプリケーションエンティティの情報を保存し、ルートリソースの遠隔ＣＳＥリソース（例えば、＜ｂａｓｅＵＲＩ＞／＜ｅｎｔｉｔｙ＞又は＜ＣＳＥＢａｓｅ＞／＜ｒｅｍｏｔｅ ＣＳＥ＞）の下位に存在する場合には、特定遠隔ＣＳＥに登録されたアプリケーションエンティティの情報を保存する。例えば、アプリケーションエンティティリソースのタイプは、＜ａｐｐｌｉｃａｔｉｏｎ＞又は＜ＡＥ＞と表示することができる。

− 接近制御リソース：接近権限に関連した情報を保存するリソースである。このリソースに含まれた接近権限情報を用いて権限付与（ａｕｔｈｏｒｉｚａｔｉｏｎ）を行うことができる。例えば、接近制御リソースのタイプは、＜ａｃｃｅｓｓＲｉｇｈｔ＞又は＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞と表示することができる。

− コンテナリソース：ＣＳＥ又はＡＥ別に生成されるデータを保存する。例えば、コンテナリソースのタイプは、＜ｃｏｎｔａｉｎｅｒ＞と表示することができる。

− グループリソース：複数のリソースを一つにまとめて一緒に処理できるようにする機能を提供する。例えば、グループリソースのタイプは、＜ｇｒｏｕｐ＞と表示することができる。

− サブスクリプションリソース：リソースの状態が変更されることを通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）にて知らせる機能を果たす。例えば、サブスクリプションリソースのタイプは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞と表示することができる。

図６には特定Ｍ２Ｍアプリケーションのためのリソースタイプを例示する。前述したように、特定Ｍ２Ｍアプリケーションのためのリソースは、Ｍ２ＭゲートウェイのＣＳＥ又は共通サービス層のリソースにおいてアプリケーションリソース（Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ）に保存することができる。特定Ｍ２Ｍアプリケーションのためのリソースは、全体リソースと類似に、属性（ａｔｔｒｉｂｕｔｅ）と子リソース（ｃｈｉｌｄ ｒｅｓｏｕｒｃｅ）を有することができる。図６の例で、子リソースはタイプ（例えば、“＜”、“＞”で表示）と定義されており、実体化の際に実の名前が与えられて保存される。

図７には一般的なＭ２Ｍシステムの通信フローを例示する。一般に、Ｍ２Ｍシステムの動作はデータ交換に基づいて行われる。例えば、特定デバイスが他のデバイスの動作を止めるために該当の命令をデータの形態として他の装置に伝達することができる。デバイス内でデータを保存するためには特定形態のデータ構造が用いられるが、これをリソース（Ｒｅｓｏｕｒｃｅ）と呼ぶ。リソースは、固有のアドレス（例えば、ＵＲＩ）を用いてアクセスすることができる。

図７を参照すると、ＡＥとＣＳＥとの連結又はＣＳＥ同士の連結において要請及び応答方式（Ｒｅｑｕｅｓｔ ａｎｄ Ｒｅｓｐｏｎｓｅ Ｓｃｈｅｍｅ）が用いられる。発信者（ｏｒｉｇｉｎａｔｏｒ）は、受信者（ｒｅｃｅｉｖｅｒ）に保存されているリソースを要請するために要請メッセージを送信し、それに対する応答として応答メッセージを受信することができる。同様に、受信者は、発信者からリソースを要請するメッセージを受信し、それに対する応答として応答メッセージを発信者に送信することができる。本明細書では簡略して、要請メッセージを要請と呼び、応答メッセージを応答と呼ぶこともできる。発信者から受信者に送信される要請メッセージは次のような情報を含むことができる。

− ｏｐ：実行される動作（Ｏｐｅｒａｔｉｏｎ）の形態
生成（Ｃｒｅａｔｅ）／回収（Ｒｅｔｒｉｅｖｅ）／更新（Ｕｐｄａｔｅ）／削除（Ｄｅｌｅｔｅ）／通知（Ｎｏｔｉｆｙ）のうち一つであってもよい。本明細書では、動作に該当する情報を命令（ｃｏｍｍａｎｄ）と呼ぶこともできる。

− ｔｏ：目的リソースのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）

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

− ｍｉ：当該要請に対する追加情報（Ｍｅｔａ ｉｎｆｏｒｍａｔｉｏｎ）

− ｃｎ：伝達されるリソースの内容

― ｅｃ：要請をハンドリングするのに用いられるイベントカテゴリー（Ｅｖｅｎｔ Ｃａｔｅｇｏｒｙ）を指示する。イベントカテゴリーは、遠隔ホスティングされた各リソースをアクセスする各要請が受信者（例えば、受信者のＣＭＤＨ ＣＳＦ）でどのように処理されるのかに対して影響を与えることができる。例えば、イベントカテゴリーは、発信者要請の重要度を示す情報を示すことができる。要請メッセージのｅｃは、例えば、「ｉｍｍｅｄｉａｔｅ」、「ｂｅｓｔＥｆｆｏｒｔ」、「ｌａｔｅｓｔ」などの値に設定することができる。ｅｃが「ｉｍｍｅｄｉａｔｅ」に設定される場合、このカテゴリーの各要請は重要な要請を意味するので、可能な限り速く伝送され、追加的なＣＭＤＨ処理が行われない。例えば、基底ネットワークを介した通信が可能である場合、これら各要請は、ＣＭＤＨバッファーに格納されずに伝送され得る。ｅｃが「ｂｅｓｔＥｆｆｏｒｔ」に設定される場合、このカテゴリーの各要請は、ＣＳＥの裁量で任意の時間の間にＣＭＤＨバッファーに格納され得、最善の努力で（ｏｎ ａ ｂｅｓｔ ｅｆｆｏｒｔ ｂａｓｉｓ）Ｍｃｃを介して伝達され得る。ｅｃが「ｌａｔｅｓｔ」に設定される場合、このカテゴリーの各要請は正常なＣＭＤＨ処理を経て、各要請が係留中である場合、最大バッファーサイズ内で古い要請が最近の要請に取り替えられる。

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

− ｔｏ：要請を生成した発信者の識別情報（又はＩＤ）

− ｆｒ：要請を受信した受信者の識別情報（又はＩＤ）

− ｍｉ：要請に対する追加情報（Ｍｅｔａ ｉｎｆｏｒｍａｔｉｏｎ）

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

− ａｉ：追加的な情報

− ｃｎ：伝達されるリソースの内容

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

− ｔｏ：要請を生成した発信者のＩＤ

− ｆｒ：要請を受信した受信者のＩＤ

− ｍｉ：要請に対する追加情報（Ｍｅｔａ ｉｎｆｏｒｍａｔｉｏｎ）

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

− ａｉ：追加的な情報

本明細書で、発信者は発信者デバイス（又は、そのＣＳＥ又はＡＥ）を表し、受信者は、受信者デバイス（又は、そのＣＳＥ又はＡＥ）を表すことができる。また、リソースを有しているデバイス（又は、そのＣＳＥ）をホスティングデバイス（又はホスティングＣＳＥ）と呼ぶ。

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

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

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

図９は、サブスクリプション資源と関連する手順を例示する。

Ｍ２Ｍシステム（例えば、ｏｎｅＭ２Ｍ）では、資源の変化に伴い、該当資源の変化に関心のあるエンティティ（Ｅｎｔｉｔｙ）が該当変化に対する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）をサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）することができる。この場合、通知をサブスクリプションするためには、サブスクリプションのための資源が設定されなければならない。サブスクリプションのための資源は、サブスクリプション資源または＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源と称することができる。サブスクリプション資源が生成／設定された場合、サブスクリプション資源が設定されたデバイス（またはエンティティ）は、サブスクリプション資源に設定された条件を満足する修正／変化がサブスクリプション対象資源（ｓｕｂｓｃｒｉｂｅｄ―ｔｏ ｒｅｓｏｕｒｃｅまたはｓｕｂｓｃｒｉｂｅｄ ｒｅｓｏｕｒｃｅ）で発生する場合、サブスクリプション資源に設定されたアドレスに通知を伝送することができる。サブスクリプション資源が設定されたり及び／またはサブスクリプション対象資源を含むデバイス（またはエンティティ）をホスティングデバイス（またはホスティングエンティティ）と称する。例えば、Ｍ２ＭゲートウェイのＣＳＥにサブスクリプション対象資源が存在し得、この場合、Ｍ２Ｍゲートウェイをホスティングデバイスと称し、Ｍ２ＭゲートウェイのＣＳＥをホスティングＣＳＥと称することができる。

サブスクリプション資源を用いて資源指向的な方式（ｒｅｓｏｕｒｃｅ―ｏｒｉｅｎｔｅｄ ｍａｎｎｅｒ）でサブスクリプション手順を行うことができる。例えば、特定のサブスクリプション対象資源に対してサブスクリプションするためにサブスクリプション資源を生成することができ、サブスクリプション資源を修正することによってサブスクリプションのための条件を変更することができ、サブスクリプションをこれ以上望まない場合はサブスクリプション資源を削除することができる。

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

サブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）資源が子資源である場合は、サブスクリプション資源の設定（属性設定）によって親資源の状態変化を指示する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）がサブスクリプション資源内のアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩまたはｃｏｎｔａｃｔ属性）に明示されたエンティティに伝達され得る。発信者がサブスクリプション可能な資源に対するＲＥＴＲＩＥＶＥ（またはＲＥＡＤ）権限（ｐｅｒｍｉｓｓｉｏｎ）を有する場合、発信者はサブスクリプション資源を生成することができる。サブスクリプション資源の発信者は資源サブスクリプション者になる。サブスクリプション対象資源に対する修正がある場合、その修正を特定の属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ ａｔｔｒｉｂｕｔｅ）と比較し、通知が資源サブスクリプション者に伝送されるか否かを決定する。

サブスクリプション資源（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源）は、多様な属性と子資源を有することができる。例えば、サブスクリプション資源（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源）は、表１の各属性を有することができる。表１において、Ｒ／Ｗは、該当属性の読み取り（ｒｅａｄ）／書き取り（ｗｒｉｔｅ）の許容有無（ｐｅｒｍｉｓｓｉｏｎ）を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表１は、例示に過ぎず、サブスクリプション資源の属性は表１と異なる形に構成することができる。

表１の例において、フィルタリング属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ）は、サブスクリプション対象資源の修正／変化に対する各条件のリストであり、各条件は、論理的ＡＮＤ関係にあり得る。例えば、フィルタリング属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ）が２個の条件を含む場合、サブスクリプション対象資源の修正／変化が２個の条件を全て満足するときに通知が伝送され得る。サブスクリプション資源にフィルタリング属性を設定することによって通知メッセージの量を調節することができ、設定したフィルタリング属性を満足するときに通知対象エンティティ（ｎｏｔｉｆｉｃａｔｉｏｎ ｔａｒｇｅｔ ｅｎｔｉｔｙ）に通知が伝送されるようにし、通知メッセージが溢れる問題を防止することができる。表２は、フィルタリング属性に含まれ得る各条件を例示する。

また、サブスクリプション資源（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源）は、子資源としてスケジューリング情報を含むスケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞）を有することができる。スケジューリング資源が特定資源の子資源として設定される場合、スケジューリング資源は、その親資源の文脈でスケジューリング情報を示す。スケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞）は、該当ノードの到達可能性スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）情報を定義する。スケジューリング資源がサブスクリプション資源の子資源に実体化される場合、通知スケジューリング資源（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源）と称することができる。本明細書において、スケジューリング資源または通知スケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞またはｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源）は、簡略してスケジューリング資源と称することができる。例えば、スケジューリング資源がサブスクリプション資源の子資源である場合、スケジューリング資源に設定されたスケジューリング情報は、サブスクリプション資源の通知のためのスケジューリング情報を示すことができる。本明細書において、スケジューリング情報は、到達可能性スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）情報と称することができる。

本明細書において、到達可能であること（ｒｅａｃｈａｂｌｅ）は、各ノード間にメッセージが送受信され得る状態を称することができ、到達可能でないこと（ｕｎｒｅａｃｈａｂｌｅまたはｎｏｎ―ｒｅａｃｈａｂｌｅ）は、各ノード間にメッセージが送受信され得ない状態を称することができる。また、特定ノードが到達可能な状態にある場合、特定ノードは、到達可能モードにあると称することができる。また、特定ノードが到達可能でない状態にある場合、特定ノードは、到達不可モードにあると称することができる。よって、到達可能性スケジュール情報は、各ノード間にメッセージ送受信が発生し得る時間を指示することができる。また、各ノード間の連結状態は到達可能性と称することができる。

スケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞）は、多様な属性を有することができる。例えば、スケジューリング資源は、ｒｅｓｏｕｒｃｅ Ｔｙｐｅ、ｒｅｓｏｕｒｃｅＩＤ、ｐａｒｅｎｔＩＤ、ｅｘｐｉｒａｔｉｏｎＴｉｍｅ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅなどの属性を含むことができる（表３参照）。表３において、ＲＷ／ＲＯ／ＷＯは、該当属性の読み取り（ｒｅａｄ）／書き取り（ｗｒｉｔｅ）の許容有無（ｐｅｒｍｉｓｓｉｏｎ）を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、ＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表３において、発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）は、該当属性が＜ｓｃｈｅｄｕｌｅ＞資源で発生可能な回数を示す。表３は、例示に過ぎなく、スケジューリング資源の属性は表３と異なる形に構成することができる。

また、例えば、スケジューリング資源は、スケジューリング時間情報のための属性（例えば、ｓｃｈｅｄｕｌｅＥｌｅｍｅｎｔ）を含むことができる。スケジューリング時間情報のための属性は、秒、分、時、日、月、年などによって定義される時間を表現することができ、時間の反復を表現することができ、ワイルドカード（ｗｉｌｄｃａｒｄ、例えば、「＊」）として表現することができる。スケジューリング時間情報のための属性は、特定ノードが到達可能モードにある期間を示したり、特定ノードが到達不可モードにある期間を示すことができる。例えば、スケジューリング時間情報のための属性は、特定ノードが到達可能モードにある期間を示す場合、スケジューリング時間情報のための属性に明示された期間の間、該当ノードはメッセージを送受信することができ、他のノードと連結状態にあり得る。他の例として、スケジューリング時間情報のための属性は、特定ノードが到達不可モードにある期間を示す場合、スケジューリング時間情報のための属性に明示された期間の間、該当ノードはメッセージを送受信することができなく、他のノードとの連結がない状態にあり得る。

図９を参照すると、デバイス１ ９１０は、デバイス２ ９２０の特定資源をサブスクリプションするために図９に例示した手順を行うことができる。デバイス１ ９１０は、サブスクリプション対象資源の変化による通知を受ける対象であってもよく、そうでなくてもよい。図９の例において、特定資源は、サブスクリプション対象資源に該当し、デバイス２ ９２０は、サブスクリプション対象資源を含んでいるのでホスティングデバイス（またはエンティティ）に該当し得る。

Ｓ９０２段階において、デバイス１ ９１０は、特定資源をサブスクリプションするためにサブスクリプション資源に対する要請をデバイス２ ９２０に伝送することができる。例えば、サブスクリプション資源に対する要請は、サブスクリプション資源の生成要請、回収要請、削除要請、及び更新要請のうちいずれか一つであり得る。各要請は、図７を参照して説明した要請―応答方式による要請メッセージの形態を有することができる。例えば、Ｓ９０２の要請が生成要請である場合、サブスクリプション資源に対する要請は、Ｃ（Ｃｒｅａｔｅ）を有するｏｐ情報、サブスクリプション資源の属性情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ、ｆｉｌｔｅｒＣｒｉｔｅｒｉａ、ｅｘｐｉｒａｔｉｏｎＴｉｍｅなど）を含むｃｎ情報、デバイス１ ９１０の識別情報を有するｆｒ情報、及び／またはデバイス２ ９２０の識別情報を有するｔｏ情報を含むことができる。他の例として、Ｓ９０２の要請が削除または更新要請である場合、サブスクリプション資源に対する要請は、図７を参照して説明した各情報の全部または一部を含むことができる。

Ｓ９０４段階において、デバイス２ ９２０は、サブスクリプション資源に対する要請を処理可能であるか否かを検査（ｖａｌｉｄａｔｅ）し、処理可能である場合、該当要請を処理する。例えば、デバイス２ ９２０が生成要請を受信する場合、ｔｏ情報に指定されたサブスクリプション対象資源がサブスクリプション可能であるか否か、要請発信者（例えば、９１０）がサブスクリプション対象資源に対してＲＥＴＲＩＥＶＥ権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否か、サブスクリプション資源のアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が要請発信者（例えば、９１０）を示さない場合、要請発信者（例えば、９１０）がサブスクリプション資源のアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に指定されたエンティティまたはデバイスに通知を送るアクセス権限（ａｃｃｅｓｓ ｒｉｇｈｔｓ）を有するか否か、ホスティングデバイスまたはエンティティ（例えば、９２０）がサブスクリプション資源のアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）に指定されたエンティティまたはデバイスに通知を送るアクセス権限（ａｃｃｅｓｓ ｒｉｇｈｔｓ）を有するか否かを検査（ｖａｌｉｄａｔｅ）する。これらを全て満足する場合、デバイス２ ９２０は、ｔｏ情報に指定されたサブスクリプション対象資源の下にサブスクリプション資源を生成することができる。

他の例として、デバイス２ ９２０が削除要請を受信する場合、デバイス２ ９２０は、要請発信者（例えば、９１０）がＤＥＬＥＴＥ権限（ｐｅｒｍｉｓｓｉｏｎ）を有するか否かを検査（ｖａｌｉｄａｔｅ）し、これを満足する場合にサブスクリプション資源を削除する。

Ｓ９０６段階において、デバイス２ ９２０は、サブスクリプション資源に対する要請を処理した後、応答メッセージをデバイス１ ９１０に伝送することができる。Ｓ９０６の応答メッセージは、図７を参照して説明した応答メッセージと同一／類似する形態を有することができる。また、回収要請の場合、応答メッセージは返還される情報を含むことができる。

図１０は、通知のための手順を例示する。通知のための手順において、発信者は、サブスクリプション資源をホスティングしているデバイスまたはエンティティ（例えば、９２０）であり得る。また、受信者は、サブスクリプション資源に設定されたアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すデバイス（またはエンティティ）であり得る。通知のための手順のために所定の政策情報を設定することができ、このような政策情報を満足するとき、発信者が通知メッセージ（例えば、ＮＯＴＩＦＹ）を伝送するように設定することができる。

通知メッセージ（例えば、ＮＯＴＩＦＹ）は、サブスクリプション資源によってトリガリングされるメッセージである。通知メッセージは、サブスクリプション資源を子資源として含むサブスクリプション対象資源の変化がサブスクリプション資源に設定されたフィルタリング属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＣｒ6ｉｔｅｒｉａ）を満足する場合、サブスクリプション資源に設定されたアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示す受信者に伝送され得る。通知メッセージの受信者は、サブスクリプション資源の設定によってサブスクリプション資源を生成／設定したデバイスまたはエンティティと同一であってもよく、互いに異なってもよい。例えば、デバイス１ ９１０は、デバイス３ ９３０と同一のエンティティであってもよく、互いに異なるエンティティであってもよい。通知メッセージは、次のような情報を含むことができる。

― ｆｒ：発信者（例えば、９２０）の識別情報またはＩＤ

― ｔｏ：サブスクリプション資源に設定されたアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）

― ｃｎ：サブスクリプション対象資源の修正内容（ｍｏｄｉｆｉｅｄ ｃｏｎｔｅｎｔ）を示すデータ及び／またはこの通知メッセージを生成したサブスクリプション参照（ｓｕｂｓｃｒｉｐｔｉｏｎ ｒｅｆｅｒｅｎｃｅ）情報（例えば、該当サブスクリプション資源のＵＲＩ）及び／またはその他の付加情報

図１０を参照すると、Ｓ１００２段階において、発信者９２０は、サブスクリプション対象資源の変化を検出／感知することができる。サブスクリプション対象資源はサブスクリプション資源の親資源であり、サブスクリプション対象資源の下でサブスクリプション資源と同一のレベルにある資源または属性が修正／変化される場合、発信者９２０（例えば、ＳＵＢ ＣＳＦまたはＣＳＥ、図３参照）はサブスクリプション対象資源の変化として認知することができる。サブスクリプション対象資源の変化が検出／感知される場合、イベントが生成され得る。

サブスクリプション対象資源の変化が検出される場合、Ｓ１００４段階において、発信者９２０は、該当変化がサブスクリプション資源に設定された特定属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ）とマッチングされるか否かを確認する。特定属性は、例えば、表２に例示した各属性のうち少なくとも一つを含むことができる。サブスクリプション対象資源の変化がフィルタリング属性に含まれた各条件を全て満足しない場合、発信者９２０は該当変化を無視することができる。

サブスクリプション対象資源の変化がフィルタリング属性に含まれた各条件を全て満足する場合、Ｓ１００６段階において、発信者９２０は、サブスクリプション資源に設定されたアドレス情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）が示すエンティティ９３０に通知メッセージを伝送することができる。Ｓ１００６の通知メッセージは、例えば、発信者９２０の識別情報、サブスクリプション対象資源の変更内容を示すデータ、及び／または通知メッセージを生成したサブスクリプション参照情報を含むことができる。サブスクリプション対象資源の変化がフィルタリング属性に含まれた各条件のうちいずれか一つでも満足しない場合、発信者９２０は、生成された通知メッセージを伝送しないこともある。

図１１は、連結状態が保障されない環境でのサブスクリプション及び通知過程を例示する。図１１の例において、２個のエンティティ（例えば、エンティティ１、エンティティ２）で構成された状況でサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）及び通知（ｎｏｔｉｆｉｃａｔｉｏｎ）過程が発生すると仮定する。

図９及び図１０を参照して説明したように、二つのエンティティ間の連結状態が保障される場合、サブスクリプションサービスは次のように行うことができる。

１．エンティティ２は、エンティティ１の特定資源（例えば、「資源ｎ」）に対してサブスクリプション過程を実施する。この過程を通じて、エンティティ２は、エンティティ１の特定資源（例えば、「資源ｎ」）に対するサブスクリプション資源を設定することができる。

２．エンティティ１は、サブスクリプション資源が設定された特定資源（例えば、「資源ｎ」）に対してモニタリングを実施し、モニタリングされている資源に変化が発生すると、エンティティ１は、資源変化を指示する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージをエンティティ２に伝送することができる。

上述したように、通知メッセージは、サブスクリプション過程で設定されたアドレス（例えば、Ｃｏｎｔａｃｔ ａｔｔｒｉｂｕｔｅ ｉｎ ＥＴＳＩ Ｍ２Ｍ、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ ａｔｔｒｉｂｕｔｅ ｉｎ ｏｎｅＭ２Ｍ）に伝送される。本例では、説明の便宜性のために、サブスクリプション過程のサブスクリプション者（ｓｕｂｓｃｒｉｂｅｒ）と通知過程の受信者（Ｒｅｃｅｉｖｅｒ）が同一のエンティティまたはデバイスであると仮定する。

図１１を参照すると、サブスクリプション過程が成功的に行われたにもかかわらず、ネットワーク障害、装置故障及び到達可能性スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）などによって各エンティティ間の連結状態が保障されない場合が発生し得る。前記のような環境で発生した各通知メッセージは、発信者（Ｏｒｉｇｉｎａｔｏｒ）（例えば、エンティティ１）から受信者（Ｒｅｃｅｉｖｅｒ）（例えば、エンティティ２）に伝送されない。そこで、従来技術では、連結状態が保障されない場合に発生した各通知メッセージを処理するために、図１２のように発生した各通知メッセージを発信者（Ｏｒｉｇｉｎａｔｏｒ）に臨時的に格納した後、連結が回復されると、これら通知メッセージを受信者（Ｒｅｃｅｉｖｅｒ）に伝送することができる。

図１２は、連結が回復された後、各メッセージを受信者に伝送する方法を例示する。

一例として、図１２（ａ）を参照すると、連結状態が保障されない状態で通知１〜通知ｎが発生した後、再び連結状態になると、発信者は、発生した通知１〜通知ｎの通知アグリゲーション（ｎｏｔｉｆｉｃａｔｉｏｎ ａｇｇｒｅｇａｔｉｏｎ）を一度に受信者に伝送することができる。

他の例として、図１２（ｂ）を参照すると、連結状態が保障されない状態で通知１〜通知ｎが発生した後、再び連結状態になると、発信者は、発生した通知１〜通知ｎを一つずつ受信者に順次伝送することができる。

以下では、図１２に例示した方法通りに連結が回復された後、メッセージを伝送する場合に発生し得る問題を説明する。まず、連結が回復された後、伝送される各通知メッセージが受信者側面で必要でない場合がある。例えば、部屋内の温度に対して特定ユーザーにサービスする環境で特定時間（例えば、午後１時から午後３時）に各エンティティ間の連結状態が切れた後、連結が復旧された。この例において、連結が回復された時点で、ユーザーが望むデータは３時以後の最新データであってもよく、または、最近の３０分間のデータであってもよい。図１２に例示した方法を使用する場合、ユーザーは、連結状態が保障されない時間の間に発生した全てのデータを受け取らなければならない。このような方式によると、発信者のみならず、受信者側面で不要なメッセージを送受信するようになり、その結果、データ伝送効率を低下させ、さらに、システム全体の性能を低下させ得る。

また、連結状態が保障されない環境で発生した各通知メッセージを選択的に処理することができない。例えば、ユーザーが部屋内の温度状態のみならず、特定値（例えば、３０度）以上である場合に緊急メッセージを設定したと仮定する。図１２に例示した方法を使用する場合、全ての通知メッセージに対する重要度（ｐｒｉｏｒｉｔｙ）が同一に設定されるので、連結状態が切れた間に発生した各メッセージのうち重要なメッセージがあるとしても、これを優先的に処理できる方法がない。

そこで、本発明では、各デバイス間の連結状態がない時間の間に発生した通知メッセージを選択的に処理するための各属性（ａｔｔｒｉｂｕｔｅ）及び伝送アルゴリズムに対して提案する。本発明に係る各例は、Ｍ２Ｍ環境を中心に記述されるが、クライアント―サーバー（または、発信者―受信者）構造を有する他のシステムにも同一／類似する形に適用することができる。

本明細書では、サブスクリプション過程において、サブスクリプション者（ｓｕｂｓｃｒｉｂｅｒ）は、サブスクリプションを要請するエンティティを称し、ホスティングエンティティ（ｈｏｓｔｉｎｇ ｅｎｔｉｔｙ）は、モニタリングされる資源（またはサブスクリプション対象資源）を有するエンティティを称することができる。また、通知過程において、発信者は、通知メッセージを伝送するエンティティを称し、受信者は、通知メッセージを最終的に受け取るエンティティを称することができる。サブスクリプション過程におけるホスティングエンティティと通知過程における発信者は同一のエンティティであり得る。

本明細書において、連結状態が保障され得ない場合は、発信者が発生した通知メッセージを受信者に伝送できない状態を含み、連結がない（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ）状態と称することができる。連結状態を保障できない場合は、ネットワーク障害、装置故障及び到達可能性スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）などのように多様な理由で発生し得る。一方、連結状態が保障される場合は、発信者が受信者に発生した通知メッセージを正常に伝送できる状態を意味し、連結がある（ｃｏｎｎｅｃｔｉｏｎ）状態または連結された（ｃｏｎｎｅｃｔｅｄ）状態と称することができる。また、本明細書において、連結状態は、到達可能性（ｒｅａｃｈａｂｉｌｉｔｙ）と称することができる。

まず、本発明に係るサブスクリプション資源の各属性を提案する。

通知動作（ｎｏｔｉｆｉｃａｔｉｏｎ ａｃｔｉｏｎ）のための属性情報

連結状態が保障されない場合、発信者の通知政策を指示する属性情報を提案する。発信者の通知政策を指示する属性情報は、制限的でない例としてｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎと称することができる。発信者の通知政策を指示する属性情報は、サブスクリプション資源の一属性に設定することができる。よって、発信者の通知政策を指示する属性情報は、表１に例示した各属性情報と共に、または別途にサブスクリプション／通知過程に用いることができる。説明の便宜上、本明細書において、発信者の通知政策を指示する属性情報は、通知政策情報と称することができ、第１の属性情報と称することができる。

通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）は、到達不可時間（ｕｎｒｅａｃｈａｂｌｅ ｐｅｒｉｏｄ）の間、通知メッセージに対して発信者が取るべき動作を指示する。例えば、到達不可時間は、スケジューリング資源または到達可能性スケジュール資源が指示するスケジューリング情報によって決定することができる（図９と関連する説明を参照）。通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がサブスクリプション資源に設定された場合、到達不可時間（ｕｎｒｅａｃｈａｂｌｅ ｐｅｒｉｏｄ）の間に発生して係留中の通知は通知政策情報によって処理することができる。表４は、本発明に係る通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）を例示する。

表４において、ＲＷ／ＲＯ／ＷＯは、該当属性の読み取り（ｒｅａｄ）／書き取り（ｗｒｉｔｅ）の許容有無（ｐｅｒｍｉｓｓｉｏｎ）を示し、ＲＥＡＤ／ＷＲＩＴＥ（ＲＷ）、及びＲＥＡＤ ＯＮＬＹ（ＲＯ）、及びＷＲＩＴＥ ＯＮＬＹ（ＷＯ）のうち一つであり得る。また、表４において、発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）は、該当属性が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞資源で発生可能な回数を示す。表４の例において、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）の発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）が０または１であるので、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）はサブスクリプション資源に選択的に（ｏｐｔｉｏｎａｌ）含ませることができる。また、読み取り／書き取りを全て許容することができる。

表４に例示したように、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）は、４つの値を有することができる。通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）に設定された値によって、発信者は、連結状態がない場合に発生する各通知メッセージを次のように処理するようになる。別途の設定がない場合、例えば、例示した４個の値のうちｓｅｎｄＮｏｎｅをデフォルト値に設定することができる。本明細書において、ｓｅｎｄＮｏｎｅは第１の値と称し、ｓｅｎｄＬａｔｅｓｔは第２の値と称し、ｓｅｎｄＡｌｌＰｅｎｄｉｎｇは第３の値と称し、ｓｅｎｄＭａｎｕａｌは第４の値と称することができる。

（１）ｓｅｎｄＮｏｎｅに設定された場合

発信者は、連結状態が保障されない時間の間に発生した全ての通知メッセージを格納しない。この場合、連結状態が保障されない時間の間に発生した全ての通知メッセージは、（伝送されずに）廃棄（ｄｉｓｃａｒｄ）され得る。発信者は、到達可能性（ｒｅａｃｈａｂｉｌｉｔｙ）を回復した場合、格納された通知メッセージがないので、連結状態が保障されない時間の間に発生した通知メッセージを受信者に伝送する必要がない。本設定は、残留通知メッセージ（ｐｅｎｄｉｎｇ ｎｏｔｉｆｉｃａｔｉｏｎ）が必要でない場合に使用することができ、例えば、現在の部屋内の温度をモニタリングする応用サービスに適用することができる。

図１３は、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＮｏｎｅに設定される場合の通知方法を例示する。

図１３を参照すると、連結状態が保障されない状態でサブスクリプション資源の変化に従って通知１〜通知ｎが発生し得るが、発信者と受信者との間の連結状態がない場合、通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）は、発信者から受信者に伝送され得ない。この場合、発生した各通知メッセージは、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理することができる。本例において、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＮｏｎｅに設定されているので、連結状態が保障されない状態で発生した各通知メッセージは、全て無視されて格納されず、その結果、連結状態を回復した後にも受信者に伝送されない。しかし、連結状態で通知メッセージ（例えば、通知ｎ＋１）が発生する場合、この通知メッセージが受信者に伝送され得る。

（２）ｓｅｎｄＬａｔｅｓｔに設定された場合

発信者は、連結状態が保障されない時間の間に発生した各通知メッセージのうち最後に発生したメッセージのみを格納する。この場合、既存に格納されている通知メッセージは削除される。すなわち、発信者は、新たな通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）を格納し、残りの通知メッセージを廃棄することができる。発信者は、到達可能性（ｒｅａｃｈａｂｉｌｉｔｙ）を回復した場合、最後に格納された通知メッセージを受信者に伝送することができる。本設定は、各残留通知メッセージのうち最後に発生した通知メッセージが必要である場合に使用することができ、例えば、装置アップデートと関連する報告を受ける応用サービスに適用することができる。また、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＬａｔｅｓｔに設定された場合、通知メッセージのｅｃ値は「ｌａｔｅｓｔ」に設定することができる（図７と関連する説明を参照）。

図１４は、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＬａｔｅｓｔに設定される場合の通知方法を例示する。

図１４を参照すると、連結状態が保障されない状態でサブスクリプション資源の変化に従って通知１〜通知ｎが発生し得、発信者と受信者との間の連結状態が保障されない場合、通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）は発信者から受信者に伝送され得ない。この場合、発生した各通知メッセージは、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理することができる。本例において、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＬａｔｅｓｔに設定されているので、連結状態が保障されない状態で発生した各メッセージのうち最後に発生したメッセージ（例えば、通知ｎ）を格納することができる。また、連結状態が保障されない期間の間に他のメッセージが発生する場合、新たに発生したメッセージが格納され、既存に格納されたメッセージは廃棄され得る。もちろん、連結状態で通知メッセージ（例えば、通知ｎ＋１）が発生する場合、この通知メッセージは受信者に伝送され得る。

（３）ｓｅｎｄＡｌｌＰｅｎｄｉｎｇに設定された場合

発信者は、連結状態が保障されない時間の間に発生した各通知メッセージを格納する。この場合、伝送される通知メッセージは、発信者が臨時に格納できる情報によって異なる形に決定することができる。発信者は、到達可能性（ｒｅａｃｈａｂｉｌｉｔｙ）を回復した場合、格納された全ての通知メッセージを受信者に伝送することができる。本設定は、発生した全ての通知メッセージが必要である場合に使用することができる。例えば、統計的なデータまたはデータ分析を要求する応用サービス（自動車のブラックボックス）に使用することができる。

図１５は、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＡｌｌＰｅｎｄｉｎｇに設定される場合の通知方法を例示する。

図１５を参照すると、連結状態が保障されない状態でサブスクリプション資源の変化に従って通知１〜通知ｎが発生し得、発信者と受信者との間に連結状態が保障されない場合、通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）は発信者から受信者に伝送され得ない。この場合、発生した各通知メッセージは、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理することができる。本例において、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＡｌｌＰｅｎｄｉｎｇに設定されているので、連結状態が保障されない状態で発生した各メッセージを格納することができる。また、連結状態を回復した後、格納された全てのメッセージが受信者に伝送され得る。図１５の例において、発生した通知１〜通知ｎが全て格納されているので、全ての格納メッセージアグリゲーション（ａｇｇｒｅｇａｔｉｏｎ）が受信者に伝送される。もちろん、連結状態で通知メッセージ（例えば、通知ｎ＋１）が発生する場合、この通知メッセージが受信者に伝送され得る。

（４）ｓｅｎｄＭａｎｕａｌに設定された場合

発信者は、連結状態が保障されない時間の間に発生した全ての通知メッセージのうちサブスクリプション者が任意に設定した通知メッセージを格納する。このとき、任意に設定される基準は、例えば、時間（例えば、１１時〜１２時）、特定の通知メッセージ指定（例えば、連結が切れた時点から１０個の通知メッセージ）などのように設定することができる。本設定は、上述したｓｅｎｄＮｏｎｅ、ｓｅｎｄＬａｔｅｓｔ及びｓｅｎｄＡｌｌＰｅｎｄｉｎｇで処理できない場合のためにサブスクリプション者の任意の基準を設定するときに使用することができ、例えば、１８時〜０６時の間に発生した通知メッセージを要請するモニタリング応用サービスに使用することができる。

図１６は、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＭａｎｕａｌに設定される場合の通知方法を例示する。

図１６を参照すると、連結状態が保障されない状態でサブスクリプション資源の変化に従って通知１〜通知ｎが発生し得、発信者と受信者との間の連結状態が保障されない場合、通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）は発信者から受信者に伝送され得ない。この場合、発生した各通知メッセージは、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理することができる。本例において、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）がｓｅｎｄＭａｎｕａｌに設定されているので、連結状態が保障されない状態で発生した各メッセージのうち設定された基準を満足する各通知メッセージのみを格納することができる。また、連結状態を回復した後、格納された各メッセージのみが受信者に伝送され得る。図１６の例において、設定された基準は時間に関するものであって、ｔ₀以後に発生した各通知メッセージを指示するので、ｔ₀以後に発生した通知２〜通知ｎを格納することができ、連結状態を回復した後、これら通知を受信者に伝送することができる。この場合、通知メッセージアグリゲーションは、設定された基準に基づいて受信者に伝送することができる。

通知重要度（ｎｏｔｉｆｉｃａｔｉｏｎ ｐｒｉｏｒｉｔｙまたはｎｏｔｉｆｉｃａｔｉｏｎ ｃａｔｅｇｏｒｙ）のための属性情報

また、本発明では、発信者で発生した通知メッセージの重要度を設定するための属性情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）を提案する。本明細書において、通知メッセージの重要度を設定するための属性情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）は、通知重要度情報と称することができ、第２の属性情報と称することができる。通知重要度情報は、サブスクリプション者によって設定することができ、任意の値ｎ（例えば、ｎ＝ｌｅｖｅｌ―１、ｌｅｖｅｌ―２、…、ｌｅｖｅｌ―ｎ）として表現することができる。通知メッセージの重要度は、特定個数のイベントカテゴリーに分けられて設定され得るので、通知メッセージの重要度は、該当イベントカテゴリーによって決定することができる。よって、通知メッセージの重要度は、発生したイベントまたはメッセージのカテゴリーを示し、（イベント）カテゴリーと称することができる。よって、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）は、サブスクリプション資源によってトリガリングされる通知メッセージのための（イベント）カテゴリーを定義する。また、通知重要度情報は、受信者が通知メッセージを正確にハンドリングできるようにするために通知メッセージに含まれるイベントカテゴリーを指示することができる。通知重要度情報は、特定システムに予め設定された政策（ｐｒｅ―ｄｅｆｉｎｅｄ ｐｏｌｉｃｙ）情報と連動して使用することができる。

通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）は、サブスクリプション資源の一属性に設定することができる。よって、発信者の通知政策を指示する属性情報は、表１に例示した各属性情報と共に、または別途にサブスクリプション／通知過程に用いることができる。また、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）はサブスクリプション者によって設定することができる。

例えば、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）は、「Ｈｉｇｈ（高い重要度）」、「Ｍｅｄｉｕｍ（普通重要度）」、「Ｌｏｗ（低い重要度）」として定義することができる。この場合、各通知メッセージのうち重要度が高く設定された特定の通知メッセージが発生する場合、発生したメッセージは、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ＝「Ｈｉｇｈ」を満足する通知メッセージであり得る。該当の通知メッセージは、他の通知メッセージに比べて優先的に処理することができる。表５は、本発明に係る通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）を例示する。

表５の例において、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）の発生回数（ｍｕｌｔｉｐｌｉｃｉｔｙ）が０または１であるので、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）は、サブスクリプション資源に選択的に（ｏｐｔｉｏｎａｌ）含ませることができる。また、読み取り／書き取りを全て許容することができる。

図１７は、本発明に係る通知過程を例示する。本発明に係る通知過程の例において、通知メッセージは、本発明で提案した各属性（ａｔｔｒｉｂｕｔｅ）情報を考慮して伝送することができる。

上述したように、各エンティティ間の連結状態が保障されない原因は、ネットワーク障害、装置故障及び到達可能性スケジュール（ｒｅａｃｈａｂｉｌｉｔｙ ｓｃｈｅｄｕｌｅ）などに分類することができる。ネットワーク及び装置故障によって連結が切れた場合は、エンティティ側面でこれを正常に復旧できる方法がない。しかし、連結状態が到達可能性スケジュールによって起因したものであると、エンティティ（例えば、発信者）は、連結状態を変更した後、発生したメッセージを伝送することができる。したがって、本発明では、サブスクリプションに対する通知過程で到達可能性スケジュールによって連結状態が切れたことを確認したとき、本発明に係る属性情報（例えば、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）及び／または通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性））を使用して解決することができる。

本発明において、サブスクリプション過程は成功的に行われたと仮定する。すなわち、本発明に係る各属性情報（例えば、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）及び／または通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性））はサブスクリプション過程で設定されたと仮定する。

以上説明したように、本発明で記述される到達可能モード（ｒｅａｃｈａｂｌｅ ｍｏｄｅ）及び到達不可モード（ｎｏｎ―ｒｅａｃｈａｂｌｅ ｍｏｄｅ）は、次のように定義することができる。到達可能モード（ｒｅａｃｈａｂｌｅ ｍｏｄｅ）は、該当エンティティが正常に動作し、他のエンティティと連結できる状態、または他のエンティティとメッセージを送受信できる状態を意味する。到達不可モード（ｎｏｎ―ｒｅａｃｈａｂｌｅ ｍｏｄｅ）は、該当エンティティの動作状態に制約があるので、他のエンティティが連結され得ない状態、または他のエンティティとメッセージを送受信できない状態を意味する。例えば、センサーネットワーク環境では、バッテリーなどの問題によって到達可能モード及び到達不可モードが存在し得る。

図１７を参照すると、Ｓ１７０２段階において、サブスクリプション過程が設定された資源（またはサブスクリプション対象資源）に変更が発生する場合、イベント（ｅｖｅｎｔ）が発生し得る。イベントは、サブスクリプション対象資源の変化が検出／感知される場合に発生し得る。このようなイベントが発生するためには、サブスクリプション対象資源の子資源としてサブスクリプション資源を予め設定することができる。

Ｓ１７０４段階において、発信者は、発生したイベントの重要度を確認する。この場合、発信者は、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）に基づいて発生したイベントの重要度を確認することができる（表５と関連する説明を参照）。例えば、重要度が高い場合は、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔがｉｍｍｅｄｉａｔｅ値に設定された場合を含むことができる。他の例として、重要度が高くない場合は、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔがｉｍｍｅｄｉａｔｅ値以外の値（例えば、ｂｅｓｔＥｆｆｏｒｔ）に設定された場合を含むことができる。

発信者は、イベントの重要度を確認した後、例えば、通知メッセージのｅｃ値を通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）が指示する値に設定することができる。また、発生イベントの重要度を確認するとき、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）の他に、サブスクリプション資源に設定された他の属性（例えば、表１参照）及び／または各条件（例えば、表２参照）のうち少なくとも一つを共に使用することができる。イベント処理のための属性と関連する過程が終了した後、通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ）が生成される。このとき、通知メッセージは、イベントで構成されるので、イベントカテゴリーが通知メッセージの重要度と同一であり得る。

Ｓ１７０４段階でイベント重要度を確認した後、発信者は、イベント重要度によってＳ１７０６段階またはＳ１７１４段階に進行することができる。Ｓ１７０４段階でイベント重要度が高い場合、発信者はＳ１７０６段階に進行することができ、Ｓ１７０４段階でイベント重要度が高くない場合、発信者はＳ１７１４段階に進行することができる。

Ｓ１７０６段階またはＳ１７１４段階において、発信者は、自分（Ｏｒｉｇｉｎａｔｏｒ）及び相手方エンティティ（または受信者）の連結状態を確認／判別することができる。発信者及び受信者の連結状態（または到達可能性）は、各エンティティまたはデバイスのためのスケジューリング資源（またはこれに設定されたスケジューリング情報）に基づいて判別することができる。

特定エンティティ（例えば、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））装置）は、バッテリー消耗などの理由で連結状態を流動的に設定することができる。したがって、Ｓ１７０６段階またはＳ１７１４段階では、発信者が自分の状態及び受信者の連結状態が到達可能モードであるのか、それとも到達不可モードであるのかを確認する過程を経る。該当エンティティの状態を確認できる情報がない場合、発信者は、該当エンティティが到達可能モードであると判断することができる。

例えば、発信者は、スケジューリング資源を通じてスケジューリング情報（または到達可能性スケジュール情報）を確認することができ、該当エンティティのスケジューリング情報を通じて連結状態（または到達可能性モード）を確認／判別することができる。発信者のためのスケジューリング資源は、サブスクリプション資源の子資源（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源）として設定することができる。受信者のためのスケジューリング資源は、別途のスケジューリング資源として設定することができる。上述したように、スケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞またはｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源）は、スケジューリング情報（またはスケジューリング時間情報のための属性（例えば、ｓｃｈｅｄｕｌｅＥｌｅｍｅｎｔ））を含むことができ、これは、該当エンティティの動作と関係し得る（年度、月、日、分、秒などの具体的な時間、または反復周期など）（図９と関連する説明を参照）。よって、発信者は、各スケジューリング資源に設定されたスケジューリング情報（またはスケジューリング時間情報のための属性（例えば、ｓｃｈｅｄｕｌｅＥｌｅｍｅｎｔ））を用いて到達可能または到達不可モード（及び／または期間）を確認することができる。例えば、発信者がサブスクリプション資源の子資源に設定されたスケジューリング資源（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＳｃｈｅｄｕｌｅ資源）を確認した結果、これに含まれたスケジューリング情報が指示する期間に該当し、スケジューリング資源が到達可能期間を示す場合、発信者は到達可能であると判別され得る。他の例として、発信者が別途に設定されたスケジューリング資源（例えば、＜ｓｃｈｅｄｕｌｅ＞資源）を確認した結果、これに含まれたスケジューリング情報が指示する期間に該当し、スケジューリング資源が到達可能期間を示す場合、受信者は到達可能であると判別され得る。これと類似する方法で、発信者または受信者が到達不可であるか否かも判別され得る。

各エンティティ間の連結状態は、次のように４つに区分することができる。

ケース１―発信者及び受信者がいずれも到達可能モード（ｒｅａｃｈａｂｌｅ ｍｏｄｅ）であるケース

ケース２―発信者が到達可能モードで、受信者が到達不可モード（ｕｎｒｅａｃｈａｂｌｅ ｍｏｄｅ）であるケース

ケース３―発信者及び受信者が到達不可モードであるケース

ケース４―発信者が到達不可モードで、受信者が到達可能モードであるケース

４つのうちケース１のみが、エンティティ間の連結状態があることを意味し得、残りのケース（ケース２、３及び４）は、両側または一側に設定された到達不可モードによって連結状態がないことを意味することができる。

Ｓ１７０６段階において、発生した通知メッセージが「重要なメッセージ」条件を満足し、連結状態がないと判別される場合（すなわち、ケース１―発信者及び受信者がいずれも到達可能モードである場合）、それぞれＳ１７０８段階に進行することができる。この場合、二つのエンティティ間の連結状態があることを意味するので、発信者は、発生した通知メッセージを受信者に即時に伝送する。このとき、発生した通知メッセージは重要なメッセージであるので、他のメッセージに比べて該当メッセージを優先的に処理することができる。

例えば、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）で通知メッセージを優先的に処理できる値を「ｉｍｍｅｄｉａｔｅ」とした場合、「重要なメッセージ」条件は、通知メッセージのｅｃ値が「ｉｍｍｅｄｉａｔｅ」に設定された通知メッセージを意味することができる。「ｉｍｍｅｄｉａｔｅ」は、例示に過ぎず、「重要なメッセージ」条件は他の値に表現することもできる。例えば、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）が「Ｈｉｇｈ（高い重要度）」、「Ｍｅｄｉｕｍ（普通重要度）」、「Ｌｏｗ（低い重要度）」に定義される場合、「重要なメッセージ」条件は、通知メッセージのｅｃ値が「Ｈｉｇｈ」に設定された通知メッセージを意味することができる。

Ｓ１７０６段階において、発生した通知メッセージが「重要なメッセージ」条件を満足し、連結状態がない場合（すなわち、ケース２―発信者が到達可能モードで、受信者が到達不可モードであるケース／ケース３―発信者及び受信者が到達不可モードであるケース）、Ｓ１７１０段階に進行することができる。

Ｓ１７１０段階において、発生した通知メッセージが重要なメッセージであるにもかかわらず、二つのエンティティの連結状態がない場合に発生した通知メッセージは伝送され得ない。したがって、Ｓ１７１０段階において、発信者は、連結状態がない間に発生した各通知メッセージに対して設定された特定動作によって（例えば、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）に設定された値によって）発生した各通知メッセージを処理することができる。通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理された通知メッセージは、受信者との連結が回復された後、受信者に伝送され得る（表４と関連する説明を参照）。このとき、発生した通知メッセージは、重要なメッセージであるので、他のメッセージに比べて優先的に処理することができる。

Ｓ１７０６段階において、発生した通知メッセージが「重要なメッセージ」条件を満足し、連結状態がない場合（ケース４―発信者が到達不可モードで、受信者が到達可能モードであるケース）、Ｓ１７１２段階に進行することができる。

Ｓ１７１２段階において、発生した通知メッセージが重要なメッセージであるにもかかわらず、二つのエンティティの連結状態がない場合に発生した通知メッセージは伝送され得ない。しかし、Ｓ１７１０段階とは異なり、Ｓ１７１２段階で連結状態がないことは、発信者側のみに設定された到達不可モードのためである。したがって、Ｓ１７１２段階において、発信者は、該当の通知メッセージを優先的に伝送するために自分（Ｏｒｉｇｉｎａｔｏｒ）の状態を一時的に到達不可モードから到達可能モードに切り替えることができる。発信者によって連結状態が一時的に復旧された後、発信者は、受信者に発生した通知メッセージを伝送し、伝送が終了すると、元々設定された装置連結状態（すなわち、到達不可モード）に切り替えることができる。

Ｓ１７０４段階において、発生した通知メッセージが「重要なメッセージ」条件を満足できず、Ｓ１７１４段階で連結状態があると判別される場合（すなわち、ケース１―発信者及び受信者がいずれも到達可能モードであるケース）、Ｓ１７１６段階に進行することができる。

Ｓ１７１６段階では、二つのエンティティ間の連結状態があることを意味するので、発信者は、発生した通知メッセージを受信者に即時に伝送することができる。このとき、発生した通知メッセージの重要度は相対的に低くなり得るので、これによって、低い優先順位で通知メッセージを処理することができる。

例えば、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）で通知メッセージを優先的に処理できる値を「ｉｍｍｅｄｉａｔｅ」とすると、「重要なメッセージ」条件を満足できないことは、通知メッセージのｅｃ値が「ｉｍｍｅｄｉａｔｅ」以外の値に設定された通知メッセージを意味することができる。「ｉｍｍｅｄｉａｔｅ」は、例示に過ぎず、「重要なメッセージ」条件は他の値として表現することもできる。例えば、通知重要度情報（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ属性）が「Ｈｉｇｈ（高い重要度）」、「Ｍｅｄｉｕｍ（普通重要度）」、「Ｌｏｗ（低い重要度）」と定義される場合、「重要なメッセージ」条件を満足できない場合、通知メッセージのｅｃ値を「Ｍｅｄｉｕｍ」、「Ｌｏｗ」に設定することができる。

Ｓ１７０４段階において、通知メッセージが「重要なメッセージ」条件を満足できず、Ｓ１７１４段階で連結状態がないと判別される場合（すなわち、ケース２―発信者が到達可能モードで、受信者が到達不可モードであるケース／ケース３―発信者及び受信者が到達不可モードであるケース／ケース４―発信者が到達不可モードで、受信者が到達可能モードであるケース）、Ｓ１７１８段階に進行することができる。

Ｓ１７１８段階において、二つのエンティティ間の連結状態がない場合に発生した通知メッセージは伝送され得ない。したがって、Ｓ１７１８段階において、発信者は、連結状態がない間に発生した各通知メッセージに対して設定された特定動作によって（例えば、通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）に設定された値によって）発生した各通知メッセージを処理することができる（表４と関連する説明を参照）。通知政策情報（例えば、ｐｅｎｄｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ属性）によって処理された通知メッセージは、受信者との連結が回復された後、受信者に伝送され得る。このとき、発生した通知メッセージの重要度は相対的に低いので、これによって、低い優先順位で通知メッセージを処理することができる。

図１８は、本発明に係る通知過程の実施例を例示する。図１８は、図１７のＳ１７１２で行われる発信者の動作に対する具体的な実施例を示すことができる。

図１８の例において、発信者によって優先的に処理されなければならない「重要なメッセージ」を意味する値を「ｉｍｍｅｄｉａｔｅ」と仮定し、予め設定された発信者の到達不可モードによってｔ０からｔ３までは連結状態がないと仮定する。この場合、受信者は到達可能モードであり得る。このような条件で、連結状態がない間に発生した通知メッセージのうち通知重要度に対する条件を満足する通知メッセージＢ（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＥｖｅｎｔＣａｔ＝「ｉｍｍｅｄｉａｔｅ」）が発生した場合、発信者は、ｔ１時点で一時的に到達不可モードから到達可能モードに切り替えられて該当の通知メッセージを伝送することができる。通知メッセージを伝送した後、発信者は、ｔ２時点で到達可能モードから到達不可モードに切り替えることができる。重要なメッセージがある場合のみに発信者の連結状態が一時的に回復され、該当メッセージを伝送し、重要メッセージを伝送した後、予め設定された連結状態に復帰することができる。

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

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

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

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

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

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

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

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

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

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

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

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

Claims (14)

1. Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）デバイスで資源サブスクリプション（ｒｅｓｏｕｒｃｅ ｓｕｂｓｃｒｉｐｔｉｏｎ）のための通知を行う方法であって、
   第１の属性情報及び第２の属性情報を含むサブスクリプション資源を子資源として含むサブスクリプション対象資源の変化を検出することと、
   前記検出された変化に基づいて通知メッセージを生成することと、
   前記Ｍ２Ｍデバイスのためのスケジューリング資源に設定されたスケジューリング情報及び受信デバイスのためのスケジューリング資源に設定されたスケジューリング情報に基づいて、前記受信デバイスへの到達可能性を判別することとを含み、
   前記第２の属性情報が即時の伝送を示す値を有し、前記Ｍ２Ｍデバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、直ちに前記受信デバイスに伝送され、
   前記第２の属性情報が即時の伝送を示す前記値以外の値を有し、前記Ｍ２Ｍデバイスのための前記スケジューリング情報又は前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、前記第１の属性情報の値によって前記Ｍ２Ｍデバイスで処理され、前記処理された通知メッセージは、前記受信デバイスが到達可能な状態を回復した後、前記受信デバイスに伝送される、方法。
2. 前記サブスクリプション資源及び前記スケジューリング資源のそれぞれは、固有のアドレスを用いて固有にアドレッシング可能なデータ構造を示す、請求項１に記載の方法。
3. 前記第２の属性情報は、前記サブスクリプション資源によってトリガリングされる前記通知メッセージのための重要度を示すイベントカテゴリーを定義し、
   前記第２の属性情報による前記イベントカテゴリーを指示する値は、前記通知メッセージに含まれる、請求項１に記載の方法。
4. 前記第１の属性情報は、前記Ｍ２Ｍデバイスのための前記スケジューリング情報及び前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスに到達可能でない期間が経過した後、前記Ｍ２Ｍデバイスが行う通知メッセージの処理動作を指示する、請求項１に記載の方法。
5. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報又は前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージを処理することは、
   前記第１の属性情報が第１の値を有する場合、前記生成された通知メッセージを廃棄することと、
   前記第１の属性情報が第２の値を有する場合、最後に生成された通知メッセージを格納し、残りの通知メッセージを廃棄することと、
   前記第１の属性情報が第３の値を有する場合、前記生成された通知メッセージを全て格納することとを含む、請求項４に記載の方法。
6. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報が到達可能であることを指示し、且つ、前記受信デバイスのための前記スケジューリング情報が到達可能であることを指示する場合、前記受信デバイスは到達可能であると判別される、請求項１に記載の方法。
7. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報が到達不可であることを指示し、又は、前記受信デバイスのための前記スケジューリング情報が到達不可であることを指示する場合、前記受信デバイスは到達不可であると判別される、請求項１に記載の方法。
8. Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）デバイスにおいて、前記Ｍ２Ｍデバイスは、
   ネットワークインターフェースユニット（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｕｎｉｔ）と、
   前記ネットワークインターフェースユニットと動作時に連結されるプロセッサとを含み、
   前記プロセッサは、
   第１の属性情報及び第２の属性情報を含むサブスクリプション資源を子資源として含むサブスクリプション対象資源の変化を検出し、
   前記検出された変化に基づいて通知メッセージを生成し、
   前記Ｍ２Ｍデバイスのためのスケジューリング資源に設定されたスケジューリング情報及び受信デバイスのためのスケジューリング資源に設定されたスケジューリング情報に基づいて、前記受信デバイスへの到達可能性を判別するように構成され、
   前記第２の属性情報が即時の伝送を示す値を有し、前記Ｍ２Ｍデバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、直ちに前記受信デバイスに伝送され、
   前記第２の属性情報が即時の伝送を示す前記値以外の値を有し、前記Ｍ２Ｍデバイスのための前記スケジューリング情報又は前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージは、前記第１の属性情報の値によって前記Ｍ２Ｍデバイスで処理され、前記処理された通知メッセージは、前記受信デバイスが到達可能な状態を回復した後、前記受信デバイスに伝送される、Ｍ２Ｍデバイス。
9. 前記サブスクリプション資源及び前記スケジューリング資源のそれぞれは、固有のアドレスを用いて固有にアドレッシング可能なデータ構造を示す、請求項８に記載のＭ２Ｍデバイス。
10. 前記第２の属性情報は、前記サブスクリプション資源によってトリガリングされる前記通知メッセージのための重要度を示すイベントカテゴリーを定義し、
    前記第２の属性情報による前記イベントカテゴリーを指示する値は、前記通知メッセージに含まれる、請求項８に記載のＭ２Ｍデバイス。
11. 前記第１の属性情報は、前記Ｍ２Ｍデバイスのための前記スケジューリング情報及び前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスに到達可能でない期間が経過した後、前記Ｍ２Ｍデバイスが行う通知メッセージの処理動作を指示する、請求項８に記載のＭ２Ｍデバイス。
12. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報又は前記受信デバイスのための前記スケジューリング情報によって前記受信デバイスが到達可能でないと判別される場合、前記通知メッセージを処理することは、
    前記第１の属性情報が第１の値を有する場合、前記生成された通知メッセージを廃棄することと、
    前記第１の属性情報が第２の値を有する場合、最後に生成された通知メッセージを格納し、残りの通知メッセージを廃棄することと、
    前記第１の属性情報が第３の値を有する場合、前記生成された通知メッセージを全て格納することとを含む、請求項８に記載のＭ２Ｍデバイス。
13. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報が到達可能であることを指示し、且つ、前記受信デバイスのための前記スケジューリング情報が到達可能であることを指示する場合、前記受信デバイスは到達可能であると判別される、請求項８に記載のＭ２Ｍデバイス。
14. 前記Ｍ２Ｍデバイスのための前記スケジューリング情報が到達不可であることを指示し、又は、前記受信デバイスのための前記スケジューリング情報が到達不可であることを指示する場合、前記受信デバイスは到達不可であると判別される、請求項８に記載のＭ２Ｍデバイス。

Images