JP6727376B2 - 効率を高めるためにサービス層サブスクリプションおよび通知を分析しグループ化する方法および装置 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１６４，１４６号（２０１５年５月２０日出願）の利益を主張し、上記出願の開示は、その全体が記載されている場合のように本明細書に引用される。

プロトコルスタックの視点から、サービス層１０２は、典型的には、アプリケーションプロトコル層１０４の上方に位置し、付加価値サービスをアプリケーション１０６に提供する。故に、サービス層１０２は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図１は、ＩＰネットワークスタックとアプリケーション１０６との間の例示的サービス層１０２を示す。

Ｍ２Ｍサービス層１０２は、Ｍ２Ｍタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを特に標的とする、あるタイプのサービス層の例である。最近、いくつかの産業規格団体（例えば、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１．に説明されるｏｎｅＭ２Ｍ）は、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開の中へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。

Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ指向能力の集合へのアプリケーションおよびデバイスのアクセスを提供することができる。いくつかの例として、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されるようなメッセージフォーマット、リソース構造、リソース表現、および機能コールを利用する、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能にされる。例えば、Ｍ２Ｍサービス層は、それらのアクセス権に基づいて、Ｍ２Ｍアプリケーションによって読み出されること、またはサブスクライブされることができる、大量のＭ２Ｍデータを維持し得る。サブスクリプションベースのデータアクセスは、サブスクライブされたリソースへの所望の変更が生じるまで、どんなメッセージもＭ２Ｍアプリケーションに導入しないので、読み出しベースのデータアクセスより効率的であり得るが、代償として、Ｍ２Ｍアプリケーションは、それらが自動通知をＭ２Ｍサービス層から受信することができる前に、サブスクリプションを最初に行う必要がある。

ｏｎｅＭ２Ｍは、共通Ｍ２Ｍサービス層の必要性に対処する技術的仕様を開発するための新しい規格であり、共通Ｍ２Ｍサービス層は、種々のハードウェアおよびソフトウェア内に容易に埋め込まれ、分野内の様々なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために頼りにされる。

ｏｎｅＭ２Ｍ共通サービス層は、図２に示されるように、共通サービス機能の組（ＣＳＦ）（すなわち、サービス能力）をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）２０２と称され、それは、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上にホストされることができる。

ｏｎｅＭ２Ｍは、図３に示されるリソース指向アーキテクチャ３００（ＲＯＡ）および図４に示されるサービス指向アーキテクチャ４００（ＳＯＡ）と呼ばれる、２つのアーキテクチャアプローチにおいてサービス層を開発している。

ＲＯＡアーキテクチャ３００では、リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有する、アーキテクチャ内の固有にアドレス可能な要素である。これらのリソースは、ユニフォームリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースとの包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。

ＣＳＥは、別のＣＳＥに登録することができる。例えば、Ｍ２Ｍゲートウェイ（すなわち、ＭＮ−ＣＳＥ）は、Ｍ２Ｍサーバ（例えば、ＩＮ−ＣＳＥ）に自らを登録し、Ｍ２Ｍサーバは、Ｍ２ＭゲートウェイのレジストラＣＳＥとなる。同様に、ＩＮ−ＡＥがＩＮ−ＣＳＥに登録すると、ＩＮ−ＣＳＥは、ＩＮ−ＡＥのレジストラＣＳＥと称される。

ＳＯＡアーキテクチャ４００（ｏｎｅＭ２Ｍ−ＴＳ−０００７，Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．７．０．に説明されるもの等）は、ＲＥＳＴｆｕｌベースではない旧来の展開を考慮するために開発されている。それは、概して、同一サービス層機能アーキテクチャを再使用する。サービス層は、種々のＭ２Ｍサービスを含み、複数のサービスが、サービスコンポーネントにグループ化されることができる。既存の参照点に加え、サービス間参照点Ｍｓｃも導入される。Ｍｓｃ基準点を経由してパスされる、Ｍ２Ｍサービスコンポーネント間の通信は、ウェブサービスアプローチ、例えば、ウェブサービスメッセージ交換パターン（ＭＥＰ）を利用する。

ｏｎｅＭ２Ｍ機能アーキテクチャは、Ｍ２Ｍサーバ等のＣＳＥによって他のＣＳＥまたはＡＥに提供され得るＣＳＦの組を定義する。１つのＣＳＦは、サブスクリプションおよび通知（ＳＵＢ）であり、それは、リソースに関する変更（例えば、リソースの削除）を追跡するサブスクリプションに関する通知を提供する。

ＳＵＢ ＣＳＦは、アクセス制御ポリシに従って、リソースへのサブスクリプションを管理し、リソースサブスクライバがそれらを受信することを欲するアドレスに対応する通知を送信する。ＡＥまたはＣＳＥは、サブスクリプションリソースサブスクライバである。ＡＥおよびＣＳＥは、他のＣＳＥのリソースにサブスクライブする。サブスクリプションホストＣＳＥは、リソースへの修正が行われると、通知をリソースサブスクライバによって規定されたアドレスに送信する。リソースサブスクリプションの範囲は、サブスクライブされるリソースの属性および直接の子リソースの変更および動作の追跡を含む。各サブスクリプションは、送信される通知、送信すべきとき、送信方法を規定する、通知ポリシを含み得る。

ＳＵＢ ＣＳＦは、リソースサブスクリプション要求毎に、リソースサブスクライバＩＤ、ホストＣＳＥ−ＩＤ、およびサブスクライブされるリソースアドレスを含むことをサポートする。それは、他の基準（例えば、関心リソース修正および通知ポリシ）ならびに通知を送信すべきアドレスも含み得る。

ＳＵＢ ＣＳＦはまた、単一サブスクリプションを介して単一リソースにサブスクライブする能力、または、それらが単一グループリソースとしてグループ化され、表される場合、単一サブスクリプションを介して複数のリソースにサブスクライブする能力をサポートする。

ｏｎｅＭ２Ｍでは、サブスクライバは、ＡＥまたはＣＳＥであり得る一方、ホストノードまたは通過ノードは、ＣＳＥである必要がある。例えば、サブスクライバとしてのＩＮ−ＡＥは、ＩＮ−ＣＳＥ（すなわち、ホストノード）によってホストされるリソースへのサブスクリプションを行い得る。別の例では、ＭＮ−ＣＳＥは、サブスクライバとしてのＩＮ−ＡＥがサブスクライブすることを欲するいくつかのリソースを有するが、ＩＮ−ＡＥのサブスクリプション要求は、そのＩＮ−ＣＳＥ（すなわち、通過ノード）を通過し、ＭＮ−ＣＳＥに到達しなければならない。

図５は、ｏｎｅＭ２Ｍ仕様に従う例示的プロシージャを図示し、サブスクライバとしてのＩＮ−ＡＥ１は、ＩＮ−ＣＳＥ上のリソース（すなわち、＜ｓｕｂｓｃｒｉｂｅｄ−ｔｏ−ｒｅｓｏｕｒｃｅ＞）へのサブスクリプションを行う。そのために、ＩＮ−ＡＥ１は、ＣＲＥＡＴＥ要求を発行し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを＜ｓｕｂｓｃｒｉｂｅｄ−ｔｏ−ｒｅｓｏｕｒｃｅ＞下に作成する（すなわち、図５のステップ１）。ＩＮ−ＡＥ１は、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａおよび複数のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩをこのステップにおいて示すことができる。ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、ＩＮ−ＡＥ１が関心がある＜ｓｕｂｓｃｒｉｂｅｄ−ｔｏ−ｒｅｓｏｕｒｃｅ＞についてのイベントを示す。通知は、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ（すなわち、この例では、サブスクライバのためのｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ１および別の通知受信側のためのｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ２）によって示されるようなサブスクライバ（すなわち、ＩＮ−ＡＥ１）および／または通知受信側に送信されることができる。ホストＣＳＥとしてのＩＮ−ＣＳＥは、サブスクリプション要求を図５のステップ１から受信後、最初に、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を＜ｓｕｂｓｃｒｉｂｅｄ−ｔｏ−ｒｅｓｏｕｒｃｅ＞のサブリソースとして作成するであろう。その後、イベントが生じ、ステップ１に含まれるｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａを満たすと、ＩＮ−ＣＳＥは、自動的に、２つの通知を、それぞれ、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ１およびｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ２によって示されるサブスクライバおよび通知受信側に送信するであろう（すなわち、図５のステップ５およびステップ６）。通知受信側は、ステップ１におけるｎｏｔｉｆｉｃａｔｉｏｎＵＲＩがそのＵＲＩを含む場合、サブスクライバ自体であり得ることに留意されたい。加えて、図５のステップ１におけるサブスクリプション要求は、複数のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩを含み得、それは、サブスクライバが将来の通知が複数の通知受信側に送信されることを要求するが、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、同一であり、全ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩに適用されることを意味する。図に示されないが、ｏｎｅＭ２Ｍは、ホストＣＳＥがバッチ通知を行うことをサポートし、ホストＣＳＥは、複数の通知を同一ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩに１つのメッセージで送信することができる。

ｏｎｅＭ２Ｍ仕様によると、ホストノードは、サブスクライバが複数のｎｏｔｉｆｉｃａｔｉｏｎＵＲＩをそのサブスクリプション要求内に示す場合、複数の通知を生成する必要がある。さらに、複数のサブスクライバが同一リソースに関心がある場合、それらは、別個のサブスクリプション要求を行う必要があり、ホストＣＳＥは、別個の通知を各サブスクライバまたは指定される通知受信側に送信する必要があるであろう。加えて、ｏｎｅＭ２Ｍは、異なるサブスクリプション要求間の潜在的関係を分析および／または活用する任意の機能をサポートしない。

ｏｎｅＭ２Ｍ機能アーキテクチャによると、「リソースは、１つ以上の遠隔ＣＳＥにアナウンスされ、遠隔ＣＳＥに、オリジナルリソースの存在を知らせることができる。アナウンスされるリソースは、オリジナルリソースからの限定された属性の組および限定された子リソースの組を有することができる。アナウンスされるリソースは、オリジナルリソースホストＣＳＥによってホストされるオリジナルリソースへのリンクを含む」。例えば、ＭＮ−ＣＳＥ（例えば、Ｍ２Ｍゲートウェイ）は、ＩＮ−ＣＳＥ（例えば、Ｍ２Ｍサーバ）に登録し、それは、そのローカルリソースをＩＮ−ＣＳＥにアナウンスすることができる。アナウンスされたリソースは、リソース発見を容易にし、促進するために使用されることができる。

ｏｎｅＭ２Ｍ機能アーキテクチャは、以下も規定する。
「オリジナルリソースによってアナウンスされた属性とアナウンスされたリソースとの間の同期は、オリジナルリソースホストＣＳＥの責任である」。
「アナウンスされた属性は、オリジナルリソースと同一値を有するものとし、オリジナルリソースにおけるアナウンスされた属性の値とアナウンスされたリソースとの間の同期は、オリジナルリソースホストＣＳＥの責任である」。

しかし、ｏｎｅＭ２Ｍは、ホストＣＳＥと遠隔ＣＳＥとの間のそのような同期が行われるべき方法に関する詳細を与えていない。そのような同期は、非常に頻繁であり、リソース属性の値が急速に変化する場合、高オーバーヘッドを生じさせ得る。例えば、統合されたモーションセンサを伴うセルラーベースのＭ２Ｍデバイスは、モーションセンサ読み取り値をクラウド内のそのレジストラＣＳＥ（すなわち、Ｍ２Ｍサーバ）にアナウンスする。モーションセンサ読み取り値は、高速で変化し得るため、オリジナルモーションセンサ読み取り値とアナウンスされたモーションセンサ読み取り値との間の同期を維持することは、高通信オーバーヘッドをＭ２ＭデバイスとＭ２Ｍサーバとの間に生じさせ、それは、セルラー接続によって提供される限定された帯域幅により、対応しきれなくさえなり得る。

ｏｎｅＭ２Ｍは、ホストノード（例えば、Ｍ２Ｍサーバ）によって維持されるデータまたはリソースにアクセスするためのサブスクリプション機構を提供する。基本的には、ホストノード上のリソースは、種々のサブスクライバ（例えば、Ｍ２Ｍネットワークアプリケーション）によってサブスクライブされることができる。リソースが、例えば、その値を変更し、サブスクライバのイベント通知基準を満たすと、ホストノードは、自動通知をサブスクライバに送信するであろう。複数のサブスクライバが、同一リソースおよびイベントに関心があるとき、ｏｎｅＭ２Ｍ仕様によると、最初に、複数かつ別個のサブスクリプション要求をホストノードに送信する必要がある。その結果、ホストノードは、複数の同じ通知をそれらのサブスクライバに送信する必要がある。そのようなサブスクリプション動作は、それらの複数のサブスクリプション要求および対応する通知が同じであり、オーバーヘッドを生じさせるので、非効率的である。

この問題を解決するために、本開示は、サブスクリプション分析およびグループ化機構を提案し、それは、異なるサブスクライバからの類似サブスクリプション要求をグループ化し、それらのための集約された通知を生成することができる。提案されるサブスクリプション分析およびグループ化機構は、サブスクリプション要求メッセージおよび通知メッセージの数を低減させ、次に、サブスクリプション効率を改良し、Ｍ２Ｍ／ＩｏＴサービス層をより効率的かつスケーラブルにする。具体的には、以下のアイディアが、提案される。

新しいサブスクリプション分析およびグループ化アーキテクチャ（Ａ）であり、ホストノードが、種々のサブスクライバからのサブスクリプション要求を分析し、それらを異なるサブスクリプショングループにグループ化する。次いで、ホストノードは、各サブスクリプショングループのために集約された通知を通過ノードに送信し、通知配信が、実施され、別個の通知が、オリジナルサブスクライバまたは指定される通知受信側に送信されるであろう。

新しいサブスクリプション分析およびグループ化アーキテクチャ（Ｂ）であり、サブスクリプション分析／グループ化および通知配信の両方が、通過ノードにおいて行われる。第１の通過ノード（例えば、サブスクライバのレジストラＣＳＥ）は、サブスクリプション要求を異なるサブスクライバから受信し、ある基準を満たす場合、それらを集約する。第１の通過ノードは、次いで、集約されたサブスクリプション要求をホストノードに送信する。リソースが変化すると、ホストノードは、集約された通知を第２の通過ノードに送信し、第２の通過ノードは、通知配信サービスを提供し、通知をサブスクライバに配信するであろう。サブスクライバまたは第１の通過ノードは、第２の通過ノードのアドレスをそのサブスクリプション要求内に示し得る。

新しいサブスクリプション分析およびグループ化サービス（ＳＡＧＳ１００２）であり、それは、類似サブスクリプション要求を集約し、通知配信サービス（ＮＯＤＳ１００４）をｎｏｔｉｆｉｃａｔｉｏｎＵＲＩのリストで構成し、集約された通知を通知配信サービス（ＮＯＤＳ１００４）に送信することに責任がある。

新しい通知配信サービス（ＮＯＤＳ１００４）であり、それは、ＮＯＤＳ１００４構成および集約された通知をＳＡＧＳ１００２から受信する。それは、次いで、集約された通知をオリジナルサブスクライバに配信する。

新しいプロシージャが、提案されるアーキテクチャＡを実装するためのホストノードにおけるサブスクリプション集約のために説明される。

新しいプロシージャが、提案されるアーキテクチャＢを実装するための通過ノードにおけるサブスクリプション集約のために説明される。

新しいプロシージャが、そのアナウンスされたリソースを介して間接的にオリジナルリソースへのサブスクリプションを行うために説明される。この場合、サブスクライバは、サブスクリプション要求を通過ノードによって維持されるアナウンスされたリソースに送信する。通過ノードは、次いで、それらの要求を集約し、集約された要求をオリジナルリソースが常駐するホストノードに送信するであろう。オリジナルリソースが変化すると、ホストノードは、集約された通知を通過ノードに送信し、それは、通知をサブスクライバに配信するであろう。

ｏｎｅＭ２Ｍ ＲＯＡアーキテクチャにおいて提案されるアイディアを実装するための実施形態としての新しいリソースおよび属性。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、また、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。

図１は、サービス層をサポートする例示的プロトコルスタックの略図である。 図２は、共通サービスエンティティ（ＣＳＥ）および共通サービス機能（ＣＳＦ）の略図である。 図３は、ｏｎｅＭ２Ｍサービス層機能アーキテクチャ（ＲＯＡ）の略図である。 図４は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（ＳＯＡ）の略図である。 図５は、ｏｎｅＭ２Ｍ一般的サブスクリプションおよび通知プロシージャの略図である。 図６は、道路状況サブスクリプションを伴うインテリジェント交通の略図である。 図７は、身体状態サブスクリプションを伴うスマートヘルスの略図である。 図８は、同一リソースの複数のサブスクライバの略図である。 図９は、集約されたサブスクリプションおよび通知システムのフローチャートである。 図１０は、サブスクリプション分析およびグループ化アーキテクチャＡの略図である。 図１１は、サブスクリプション分析およびグループ化アーキテクチャＢの略図である。 図１２は、ＳＡＧＳ１００２における新しいサブスクリプション要求のフローチャートである。 図１３は、ＳＡＧＳ１００２におけるサブスクリプション削除要求のフローチャートである。 図１４は、ＳＡＧＳ１００２におけるサブスクリプション更新要求のフローチャートである。 図１５は、ＮＯＤＳ１００４における動作のフローチャートである。 図１６は、イベント発生およびＳＡＧＳ１００２の集約された通知のＮＯＤＳ１００４への送信または通常通知のフローチャートである。 図１７は、ホストノードにおけるサブスクリプション分析およびグループ化のためのプロシージャのコールフローである。 図１８は、通過ノードにおけるサブスクリプション分析およびグループ化のためのプロシージャのコールフローである。 図１９は、アナウンスされたリソースを介したサブスクリプションのコールフローである。 図２０は、ｏｎｅＭ２Ｍ ＲＯＡの中への新しい拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦの略図である。 図２１は、ｏｎｅＭ２Ｍにおける新しいｅＳＵＢの展開の略図である。 図２２は、一実施形態のグラフィカルユーザインターフェース（ＧＵＩ）の略図である。 図２３Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２３Ｂは、図２３Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２３Ｃは、図２３Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２３Ｄは、図２３Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

図６は、ユーザが道路状況データにサブスクライブするインテリジェント交通シナリオを図示する。このシナリオでは、Ｔｕｒｎｐｉｋｅ Ｃｏｍｐａｎｙ Ａが、Ｍ２Ｍサーバに道路状況を報告することができる路傍カメラを展開し、Ｍ２Ｍサーバは、クラウド内に常駐し、Ｍ２ＭサービスプロバイダＢによって動作させられる。交通状況情報は、通行車両から受信されることができるが、この使用例に焦点を当てるものではない。Ｍ２ＭサービスプロバイダＢは、Ｍ２Ｍサーバ６０２（すなわち、ＩＮ−ＣＳＥ）を展開し、ほぼリアルタイムの道路状況をＭ２ＭユーザＣ、Ｄ、およびＥ（例えば、通勤者のスマートフォン上にインストールされたＩＮ−ＡＥ）に提供する。この使用例では、Ｍ２Ｍデバイスとしての路傍カメラは、Ｍ２Ｍサービス層能力（例えば、データリポジトリおよび管理）を有すると仮定される。路傍カメラによって生成される大量のビデオファイルに起因して、関心状況またはイベント（例えば、軽度の交通渋滞、中程度の交通渋滞、および重度の交通渋滞）のみが、Ｍ２Ｍサーバ６０２に報告され、最終的に、サブスクリプション／通知機構に基づいて、Ｍ２Ｍユーザに転送されるであろう。そのような交通状況（すなわち、軽度の渋滞等）は、画像処理および分析を通して路傍カメラによって結論を下されることができることに留意されたい。例えば、Ｍ２ＭユーザＣ６１０が、Ｍ２Ｍサーバを介して、交通渋滞レベルに関する路傍カメラへのサブスクリプションを行う。路傍カメラが重度の渋滞を検出すると、それは、通知をＭ２Ｍサーバに送信し、Ｍ２Ｍサーバは、Ｍ２ＭユーザＣ、Ｄ、およびＥが、Ｍ２ＭサービスプロバイダＢと取引関係さえ有し得るならば、通知をＭ２ＭユーザＣ６１０に中継するであろう（但し、路傍カメラは、Ｍ２ＭユーザＣのＵＲＩを維持する場合、通知をＭ２ＭユーザＣに同様に直接送信することができる）。加えて、通勤者ユーザは、道路状況データにおいて類似の関心（例えば、出口における渋滞レベル）を有し得る。このシナリオでは、路傍カメラに記憶される道路状況データは、サブスクリプション／通知機構に基づいて、Ｍ２Ｍユーザ６１０、６１２、および６１４によってアクセスされる。しかし、道路状況データ自体は、公共情報と見なされ、あまりプライバシー懸念を伴わずに、使用のために全ての人にアクセス可能であるが、ある使用ベースの料金が、課金され得る。

図７は、高齢者７０２が、その身体上にセンサ７０４等のいくつかのセンサを有し、リアルタイム身体状態を監視する別のシナリオを図示する。身体状態、特に、検出された異常は、その人のスマートデバイス７０６（すなわち、ＭＮ−ＣＳＥ）を介して、Ｍ２Ｍサーバ（すなわち、ＩＮ−ＣＳＥ）に報告されることができる。Ｍ２Ｍサーバは、Ｍ２ＭサービスプロバイダＦ ７０８によって動作させられる。Ｍ２Ｍデバイスとしてのスマートデバイス７０６は、Ｍ２Ｍサービス層能力も同様に有する。言い換えると、Ｍ２Ｍユーザ７１０、７１２、７１４、７１６、および７１８によってサブスクライブされ得る身体状態データを記憶する。その人は、Ｍ２ＭサービスプロバイダＦ ７０８と関係を有する。その人の身体状態データに関心があり、それへのサブスクリプションを行う何人かのユーザが存在し、例えば、その人の保護者、その人の主治医、その人の仮想医師（例えば、医師オンデマンドアプリケーション）、その人の保険会社、およびその人のフィットネスコーチである。これらのユーザは、その人と関係を有し、異なるタイプの身体状態に関心があり得、身体状態データへのそれらのサブスクリプションは、異なり得る。このシナリオでは、スマートデバイス７０６に記憶される身体状態データは、スマートヘルスエコシステムにおける異なるアクタ／ユーザによってサブスクライブされる。さらに、身体状態データについてのプライバシー懸念があり、ユーザは、その人の身体状態データへの異なるアクセス権を有する。加えて、Ｍ２ＭユーザＡ ７１０は、複数の通知受信側（例えば、Ｍ２ＭユーザＢ ７１２、Ｍ２ＭユーザＣ ７１４等）への通知を依頼するためのサブスクリプション要求を発行し得る。

図６−７に図示される機能性は、以下に説明される図２３Ｃまたは２３Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークの装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

前述の使用例に説明されるように、エンドデバイスにおいて生成または収集されるデータ（すなわち、インテリジェント交通における交通状況データおよびスマートヘルスにおける身体状態データ）は、Ｍ２Ｍサーバを介して、種々のアプリケーションによってサブスクライブされる。そのようなサブスクリプションベースのデータアクセスは、図８に要約および描写され、Ｍ２Ｍユーザとしての３つ以上のＭ２Ｍアプリケーションは、Ｍ２Ｍノード１（例えば、Ｍ２Ｍサーバ）を介して、Ｍ２Ｍノード２（例えば、インテリジェント交通における路傍カメラまたはスマートヘルスにおける身体センサ）において生成されるデータへのサブスクリプションを行う。そのようなサブスクリプションは、Ｍ２Ｍノード１を通してルーティングされる。

図８が示すように、サブスクライバとしての各アプリケーションエンティティ８０２、８０４、および８０６は、別個のサブスクリプションをＭ２Ｍノード２ ８０８に発行する。関心イベントが発生すると、Ｍ２Ｍノード２ ８０８は、３つの通知を、それぞれ、各Ｍ２Ｍアプリケーションに送信する。インテリジェント交通において前述されたように、それらのＭ２Ｍアプリケーション（例えば、通勤者のスマートフォン上にインストールされたアプリケーション）は全て、交通負荷状況に関心があり、ほぼ同一サブスクリプション要求を発行する。言い換えると、ステップ１、ステップ２、およびステップ３におけるサブスクリプション要求は、同一である。次いで、Ｍ２Ｍノード２ ８０８によって発行されるそれらの３つの通知も、同一である。言い換えると、Ｍ２Ｍアプリケーションが類似サブスクリプションを有するとき、複数のサブスクリプション要求が、Ｍ２Ｍノード２ ８０８（すなわち、ホストノード）に送信され、Ｍ２Ｍノード２ ８０８も、Ｍ２Ｍノード１ ８１０（すなわち、通過ノード）を介して、複数の通知をＭ２Ｍアプリケーションに送信するであろう。通過ノード８１０とホストノード８０８との間のそれらの複数のサブスクリプション要求および通知は、非効率的であり、特に、サブスクライバとしてのＭ２Ｍアプリケーションが多数存在するとき、余分なオーバーヘッドを導入する。さらに、既存のｏｎｅＭ２Ｍサービス層は、異なるサブスクリプション要求間の関係を分析および活用する機能性を欠いている。

図８に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図８に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図８に図示されるステップを行う。図８に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

前述の問題を解決し、ｏｎｅＭ２Ｍにおける既存のサブスクリプション機構を最適化するために、本開示は、サブスクリプション分析およびグループ化を可能にするための新しいアーキテクチャおよび方法を提案する。不可欠なアイディアは、サブスクライバのサブスクリプション要求をホストノード（または通過ノード）において分析およびグループ化することである。ホストノードは、次いで、通過ノードへの集約された通知を生成し、通過ノードは、次いで、個々の通知をオリジナルサブスクライバに配信するであろう。ｏｎｅＭ２Ｍにおける既存のサブスクリプション機構と比較して、提案されるアプローチは、サブスクリプション要求および通知メッセージの数を低減させ、サブスクライバとホストノードとの間のサブスクリプションをより効率的にする。

図９は、Ｍ２Ｍノード２ ８０８が、集約されたサブスクリプション要求を受信し、集約された通知をＭ２Ｍノード１ ８１０に送信する例示的実施形態のコールフローを示す。Ｍ２Ｍノード１ ８１０は、Ｍ２Ｍ ＡＥ ８０２、８０４、および８０６からのサブスクリプション要求を集約する。Ｍ２Ｍノード１ ８１０はまた、集約された通知をＭ２Ｍノード２ ８０８から受信後、個々の通知をＭ２Ｍ ＡＥ ８０２、８０４、および８０６に送信する。

図９に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図９に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図９に図示されるステップを行う。図９に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

最初に、２つのサブスクリプション分析およびグループ化アーキテクチャオプション、すなわち、それぞれ、ホストノードおよび通過ノードにおけるサブスクリプション分析ならびにグループ化が、提示される。提案されるアーキテクチャは、２つの新しいサービス、ＳＡＧＳ１００２、ＮＯＤＳ１００４を含む。ＳＡＧＳ１００２およびＮＯＤＳ１００４の機能性が、説明される。ホストおよび通過ノードにおけるサブスクリプション分析ならびにグループ化が、議論される。新しいプロシージャが、アナウンスされたリソースを介したサブスクリプションに対して説明される。

全体的に、本開示における提案されるアイディアは、以下のシナリオに対してサブスクリプション集約を行うことができる。

複数のサブスクライバが、同一イベント通知基準を用いて、同一リソースへのサブスクリプションを行う。それらのサブスクライバからのサブスクリプション要求は、集約されることができ、それらへの通知も、集約されることができる。

複数のサブスクライバが、同一リソースへのサブスクリプションを行うが、異なるイベント通知基準を用いる。それらのサブスクライバからのサブスクリプション要求は、集約されることができ、それらへの通知も、集約されることができる。

サブスクライバは、リソースへのサブスクリプションを行い、複数の通知受信側を与える。それらの複数の受信側への通知は、集約されることができる。

図１０は、提案されるサブスクリプション分析およびグループ化アーキテクチャを図示し、２つの新しいサービス、すなわち、ＳＡＧＳ１００２およびＮＯＤＳ１００４が、提案される。ＳＡＧＳ１００２は、ホストノード内に常駐する一方、ＮＯＤＳ１００４は、通過ノード内に設置される。３つ以上のサブスクライバからのオリジナルサブスクリプション要求（例えば、ステップ１−３）が、それぞれ、ホストノードに到着する（直接または通過ノードを介して間接的にのいずれかにおいて）。各サブスクリプション要求は、通知が送信されることになる通知ＵＲＩを有することに留意されたい。ＳＡＧＳ１００２は、受信されたサブスクリプション要求を分析し、それらをサブスクリプショングループと称される異なるグループに割り当てる。例えば、ステップ１−３におけるサブスクリプション要求は、それらが類似イベント通知基準を伴う同一のサブスクライブされるリソースに関心がある場合、同一グループ内に設置されるであろう。次いで、ＳＡＧＳ１００２は、グループ化されるサブスクリプション要求と各オリジナルサブスクリプション要求の通知ＵＲＩとについての情報でＮＯＤＳ１００４（すなわち、ステップ４）を構成する必要があり得る。ＮＯＤＳ１００４は、そのような構成情報に依拠し、後に、通知をサブスクライバに配信することが可能である（すなわち、ステップ６−８）。そうでなければ、ＳＡＧＳ１００２は、ＮＯＤＳ１００４が集約された通知を解釈し、それを適切なサブスクライバに配信することが可能になるように（すなわち、図１０のステップ６−８）、そのような情報（特に、通知ＵＲＩ）を各集約された通知内に含む必要がある（すなわち、ステップ５）。オリジナルサブスクリプション要求は、ＮＯＤＳ１００４が常駐するものと異なる通過ノードを通してパスされ得ることに留意されたい。このアーキテクチャにおける各ステップの詳細は、後の節において議論されるであろう。

より多くのサブスクリプション分析およびグループ化機会を促進するために、各リソースがホストノードによって事前に構成されることができる相互排他的イベント通知基準の組を有することが提案される。次いで、サブスクライバは、それらのイベント通知基準に基づいて、サブスクリプションを行うであろう。例えば、以下の基準が、図６のインテリジェント交通使用例において交通状況リソースに対して構成されることができる。それらの構成されるイベント通知基準に従うことによって、各サブスクライバによって発行されるランダムイベント通知基準とは対照的に、サブスクライバからの類似サブスクリプション要求がグループ化されるより高い可能性およびより多くの機会が存在し得る。
イベント通知基準＃１：「交通状況」＝「無渋滞」
イベント通知基準＃２：「交通状況」＝「散発的渋滞」
イベント通知基準＃３：「交通状況」＝「軽度の渋滞」
イベント通知基準＃４：「交通状況」＝「中程度の渋滞」
イベント通知基準＃５：「交通状況」＝「重度の渋滞」

単一サブスクライバに対しても、サブスクライバが複数の通知受信側を示す場合、対応する通知は、依然として集約されることができることに留意されたい。この場合、ＳＡＧＳ１００２は、ＮＯＤＳ１００４を全通知受信側のアドレスで構成する。次いで、集約された通知をＮＯＤＳ１００４に送信する。最後に、ＮＯＤＳ１００４は、通知を全通知受信側に配信するであろう。

代替として、サブスクリプション要求も、サブスクリプション要求が中継またはルーティングされるであろう通過ノード８１０においてグループ化されることができ、それは、図１１に図示される。最初に、ホストノード８０８は、随意に、そのリソースのイベント通知基準を通過ノード８１０にパブリッシュし得る（図１１のステップ０）。次いで、サブスクライバ１００６、１００８、および１０１０は、それらのイベント通知基準を発見し、それらにサブスクライブすることができる。複数のサブスクライバが、同一イベント通知基準に関する同一リソースへのサブスクリプションを行う場合（すなわち、図１１のステップ１、ステップ２、およびステップ３）、通過ノード８１０内のＳＡＧＳ１００２は、それらのサブスクリプション要求をグループ化し、次に、１つの単一であるが集約されたサブスクリプション要求をホストノード８０８に送信することができる（すなわち、ステップ４）。ＳＡＧＳ１００２は、ＮＯＤＳ１００４に、そのようなサブスクリプショングループ化を知らせるであろう。関心イベントが発生すると、ホストノード８０８は、通常通知をＮＯＤＳ１００４に送信する（すなわち、ステップ５）。ＮＯＤＳ１００４は、通知をオリジナルサブスクライバに配信するであろう（すなわち、ステップ６、ステップ７、およびステップ８）。ＳＡＧＳ１００２およびＮＯＤＳ１００４は、図１１では、同一通過ノード８１０に示されるが、ＳＡＧＳ１００２およびＮＯＤＳ１００４は、異なる通過ノードに位置することもできる。各ステップの詳細は、以下に説明されるであろう。

アーキテクチャＢ内のＳＡＧＳ１００２は、アーキテクチャＡ（すなわち、図１０）のものと類似機能性を有するが、集約されたサブスクリプション要求をホストノードに送信するための新しい機能を伴う（すなわち、図１１におけるステップ４）ことに留意されたい。アーキテクチャＢ内のＮＯＤＳ１００４は、アーキテクチャＡ内のものと同一機能性を有する。

サブスクライバがそのサブスクリプション要求内で異なるイベント通知基準を示しても、そのサブスクリプション要求は、例えば、同一のサブスクライブされるリソースを標的にすると、依然としてグループ化されることができることに留意されたい。

３つのサブスクライバ１０００６、１００８、および１０１０が、同一の＜ｓｕｂｓｃｒｉｂｅｒ−ｔｏ−ｒｅｓｏｕｒｃｅ＞に関心があると仮定する。それらは、３つのサブスクリプション要求を通過ノード８１０に発行する。その要求では、サブスクライバ１は、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１を示し、サブスクライバ２は、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２を示し、サブスクライバ３は、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ３を示す。ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２、およびｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ３が互いに相互排他的であることも仮定される。

通過ノード８１０は、それらの３つの要求を分析およびグループ化し、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２、およびｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ３を含む集約されたサブスクリプション要求を生成する。

イベントが発生し、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２、またはｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ３のいずれかを満たすと、通知を通過ノード８１０に送信する。この通知は、対応するイベント通知基準を含むであろう。通過ノード８１０は、そのイベント通知基準に基づいて、この通知を受信するためのサブスクライバを把握する。ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２、およびｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ３が、互いに相互排他的ではないとき、通過ノード８１０は、いくつかの相互排他的ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａを決定し、それらをホストノードへの集約されたサブスクリプション内に含むことができる。次いで、通知をホストノードから受信すると、依然としてこの通知を受信するための正しいサブスクライバを判断することが可能である。

図１０および１１に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１０および１１に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１０および１１に図示されるステップを行う。図１０および１１に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

ＳＡＧＳ１００２およびＮＯＤＳ１００４の機能性ならびに動作は、図１２−１６に関して以下に説明される。

ＳＡＧＳ１００２は、以下を含む、いくつかの機能性を有する。

図１２は、ＳＡＧＳ１００２が新しいサブスクリプション要求ＳＲ（ｉ）を受信するときの動作を示す。

図１３は、ＳＡＧＳ１００２が既存のサブスクリプション要求ＳＲ（ｉ）を削除するための要求を受信するときの動作を示す。

図１４は、ＳＡＧＳ１００２が既存のサブスクリプション要求ＳＲ（ｉ）を更新するための要求を受信するときの動作を示す。

図１６は、イベントが発生し、ＳＡＧＳ１００２が集約された通知をＮＯＤＳ１００４に送信する必要があるときの動作を示す。

ＮＯＤＳ１００４機能性は、図１５に与えられる。

図１２は、新しいサブスクリプション要求ＳＲ（ｉ）を受信するときのＳＡＧＳ１００２の動作を図示する。

図１２のステップ１では、新しいサブスクリプション要求ＳＲ（ｉ）が到着する。

図１２のステップ２では、ＳＡＧＳ１００２が、ＳＲ（ｉ）を分析し、サブスクライブされるリソースｒ（ｉ）、イベント通知基準ｅｎｃ（ｉ）、および通知ＵＲＩ ｎｕ（ｉ）等の情報を得る。受信されたＳＲ（ｉ）から、ＳＡＧＳ１００２は、通過ノード８１０のアドレス（すなわち、ｔｎ（ｉ））も把握および記録し得る。

ＳＡＧＳ１００２がホストノード内に常駐するアーキテクチャＡに対して、通過ノード８１０が、ＳＡＧＳ１００２に転送する前にそのアドレスをＳＲ（ｉ）に挿入することができるか、または、サブスクライバが、通過ノード８１０アドレスをそれらのサブスクリプション要求内に含むことができる。

ＳＡＧＳ１００２が通過ノード８１０内に常駐するアーキテクチャＢに対して、ｔｎ（ｉ）は、同一通過ノード８１０、またはサブスクライバによってサブスクリプション要求内に示され得る異なる通過ノードであり得る。

図１２のステップ３では、ＳＡＧＳ１００２が、そのローカルデータベース（すなわち、以前に作成された全サブスクリプショングループ）を検索し、ＳＲ（ｉ）を収容し得る、既存のサブスクリプショングループＳＧ（ｊ）を見出す。本開示におけるサブスクリプショングループは、類似サブスクリプション要件（例えば、同一のサブスクライブされるリソースおよび同一通過ノード８１０ならびに類似イベント通知基準等）を有するサブスクリプション要求の組として定義されることに留意されたい。サブスクリプショングループの各メンバは、受信されたサブスクリプション要求である。言い換えると、各サブスクリプショングループは、全てのそのメンバサブスクリプション要求によって共有される３つの共通属性：サブスクライブされるリソース、通過ノード８１０、およびイベント通知基準を有する。ＳＡＧＳ１００２は、サブスクリプショングループが有することができるサブスクリプション要求の数の限界を設定し得る。

ＳＧ（ｊ）が見出される場合、ＳＲ（ｉ）がＳＧ（ｊ）内の他の要求と同一のサブスクライブされるリソースおよび類似イベント通知基準を有することを意味する。次いで、ステップ６に進み、ＳＧ（ｊ）が依然として新しい要求を収容することができる場合、ＳＲ（ｉ）をＳＧ（ｊ）にグループ化する。ＳＧ（ｊ）が新しい要求をもはや収容することができない場合、ステップ４に進む。

そのようなＳＧ（ｊ）が存在しない場合、ステップ４に進む。

図１２のステップ４では、ＳＡＧＳ１００２が、そのローカルデータベース（すなわち、以前に受信されたが、まだグループ化されていない、全サブスクリプション要求）を検索し、ＳＲ（ｉ）と同一のサブスクライブされるリソース、ＳＲ（ｉ）と同一通過ノード８１０、およびＳＲ（ｉ）と類似イベント通知基準を有するグループ化されていないサブスクリプション要求（ＵＳＲ）を見出す。

ＵＳＲが見出される場合、それは、ＳＲ（ｉ）およびＥＳＲが一緒にグループ化され、新しいサブスクリプショングループを編成することができることを意味する。次いで、ステップ８に進む。

そのようなＵＳＲが見出されない場合、ステップ５に進む。

図１２のステップ５では、ＳＡＧＳ１００２が、どんなサブスクリプション集約も伴わずに、ＳＲ（ｉ）をバッファする。次いで、このＳＲ（ｉ）を処理するためのプロシージャは、完了する。

図１２のステップ６では、ステップ４から、ＳＡＧＳ１００２は、ＳＲ（ｉ）をＳＧ（ｊ）によって含まれるサブスクリプション要求のリストに追加する。ＳＧ（ｊ）は、ここで変更されるので、ＳＡＧＳ１００２は、更新を対応するＮＯＤＳ１００４に送信し、この変更（すなわち、追加されるＳＲ（ｉ）、特に、その通知ＵＲＩ ｎｕ（ｉ））をそれに知らせる必要があり得る。ステップ９は、新しく作成されたサブスクリプショングループのための適切なＮＯＤＳ１００４を決定する方法を議論することに留意されたい。

図１２のステップ７では、ＳＡＧＳ１００２が、メッセージをＮＯＤＳ１００４に送信し、新しいＳＲ（ｉ）がＳＧ（ｊ）に追加されることを通知する。基本的に、ＮＯＤＳ１００４は、ＳＧ（ｊ）の全サブスクリプション要求の通知ＵＲＩを維持する。ここで、ＳＡＧＳ１００２は、ＮＯＤＳ１００４に、ＳＲ（ｉ）の通知ＵＲＩを伝える。次いで、このＳＲ（ｉ）を処理するためのプロシージャは、完了される。

図１２のステップ８では、ＳＡＧＳ１００２が、２つのサブスクリプション要求ＳＲ（ｉ）およびＵＳＲを含む新しいサブスクリプショングループＳＧ（ｋ）を作成する。ＳＲ（ｉ）およびＵＳＲは両方とも、同一のサブスクライブされるリソース、同一通過ノード８１０、および類似イベント通知基準を有することに留意されたい。この共通通過ノード８１０は、ＮＯＤＳ１００４が常駐すべきノードとして選択されるであろう。

図１２のステップ９では、ＳＡＧＳ１００２が、ＳＲ（ｉ）およびＵＳＲの共通通過ノード８１０をＳＧ（ｋ）にサービスを提供するためのＮＯＤＳ１００４をホストすべきノードとして選択する。

ＳＲ（ｉ）は、ＮＯＤＳ１００４のアドレスを示し得ることに留意されたい。同様に、ＵＳＲも、ＮＯＤＳ１００４アドレスを含み得る。ＳＲ（ｉ）およびＵＳＲは両方とも、同一ＮＯＤＳ１００４アドレスを有すると仮定される。そうでなければ、それらは、集約されないであろう。言い換えると、サブスクリプション要求がＮＯＤＳ１００４アドレスを示す場合、サブスクリプショングループ内のサブスクリプション要求の共通ＮＯＤＳ１００４アドレスは、このサブスクリプショングループのためのＮＯＤＳ１００４として選択されるであろう。

図１２のステップ１０では、ＳＡＧＳ１００２が、メッセージをＮＯＤＳ１００４に送信し、新しく作成されたＳＧ（ｋ）を知らせる。基本的に、ＳＡＧＳ１００２は、ＮＯＤＳ１００４に、ＳＲ（ｉ）およびＵＳＲの通知ＵＲＩを伝える。そのような情報は、ＮＯＤＳ１００４によって維持され、ＮＯＤＳ１００４によって後に活用され、通知をＳＲ（ｉ）およびＵＳＲのサブスクライバに配信するであろう。

図１２のステップ１１では、ＳＡＧＳ１００２が、新しいサブスクリプション要求ＳＲ（ｉ）の処理を終了する。

図１２に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１２に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１２に図示されるステップを行う。図１２に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１３は、既存のサブスクリプション要求ＳＲ（ｉ）を削除するための要求を受信するときのＳＡＧＳ１００２の動作を図示する。

図１３のステップ１では、ＳＡＧＳ１００２が、既存のサブスクリプション要求ＳＲ（ｉ）を削除するための要求を受信する（例えば、サブスクライバから）。

図１３のステップ２では、ＳＡＧＳ１００２が、以前に編成され、ＳＲ（ｉ）を含む、既存のサブスクリプショングループＳＧ（ｊ）を見出すことを試みる。

そのようなＳＧ（ｊ）が見出される場合、ステップ３に進む。そうでなければ、ステップ５に進む。

図１３のステップ３では、ＳＡＧＳ１００２が、ＳＲ（ｉ）をＳＧ（ｊ）から除去する。

図１３のステップ４では、ＳＡＧＳ１００２が、更新をＮＯＤＳ１００４に送信し、ＳＲ（ｉ）の除去を知らせる。基本的に、ＮＯＤＳ１００４が維持しているＳＲ（ｉ）の通知ＵＲＩは、削除されるであろう。

ＳＧ（ｊ）が、ＳＲ（ｉ）を除去後、１つのみのサブスクリプション要求を含む場合、ＳＡＧＳ１００２は、単に、ＳＧ（ｊ）をそのローカルデータベースから削除し、また、ステップ４において、ＮＯＤＳ１００４に、全ＳＧ（ｊ）情報を除去するように伝えてもよい。

図１３のステップ５では、ＳＡＧＳ１００２が、ＮＯＤＳ１００４からの応答の受信を待つ。しかし、ＳＡＧＳ１００２は、ＮＯＤＳ１００４からの応答が成功または失敗であるかどうかにかかわらず、ＳＲ（ｉ）を削除する必要があるであろう。

図１３のステップ６では、ＳＡＧＳ１００２が、ＳＲ（ｉ）をそのローカルデータベースから削除する。

図１３のステップ７では、ＳＡＧＳ１００２が、ステップ１において受信された要求の処理を終了する。

図１３に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１３に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１３に図示されるステップを行う、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。図１３に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１４は、既存のサブスクリプション要求ＳＲ（ｉ）を更新するための要求を受信するときのＳＡＧＳ１００２の動作を図示する。

図１４のステップ１では、ＳＡＧＳ１００２が、既存のサブスクリプション要求ＳＲ（ｉ）を更新するための要求（例えば、その通知ＵＲＩの変更）を受信する。

図１４のステップ２では、ＳＡＧＳ１００２が、以前に編成され、ＳＲ（ｉ）を含む、既存のサブスクリプショングループＳＧ（ｊ）を見出すことを試みる。

そのようなＳＧ（ｊ）が見出される場合、ステップ３に進む。そうでなければ、ステップ５に進む。

図１４のステップ３では、ＳＡＧＳ１００２が、ステップ１において受信された要求に従って、ＳＲ（ｉ）を更新する。

図１４のステップ４では、ＳＡＧＳ１００２が、更新されたＳＲ（ｉ）を新しいサブスクリプション要求と見なし、図１２における全ステップに従う。次いで、ステップ１０に進む。

図１４のステップ５では、ＳＡＧＳ１００２が、ステップ１において受信された要求に従って、ＳＲ（ｉ）を更新する。

図１４のステップ６では、ＳＡＧＳ１００２が、ＳＲ（ｉ）が依然としてその現在のグループＳＧ（ｊ）内に含まれることができるかどうかを決定する。回答が「はい」である場合、ステップ９に進む。回答が「いいえ」である場合、ステップ７に進む。

図１４のステップ７では、ＳＡＧＳ１００２が、ＳＲ（ｉ）をＳＧ（ｊ）から除去する。

図１４のステップ８では、ＳＡＧＳ１００２が、更新をＮＯＤＳ１００４に送信する。基本的に、ＮＯＤＳ１００４が維持するＳＲ（ｉ）についての情報、例えば、ＳＲ（ｉ）の通知ＵＲＩは、除去されるであろう。次いで、ステップ４に進む。

図１４のステップ９では、ＳＡＧＳ１００２が、更新をＮＯＤＳ１００４に送信する必要があるかどうかを決定する。例えば、ステップ１における要求がＳＲ（ｉ）の通知ＵＲＩの更新を求める場合、ＳＡＧＳ１００２は、ＮＯＤＳ１００４を新しい通知ＵＲＩで更新する必要がある。

更新が必要とされる場合、ステップ１０に進む。そうでなければ、ステップ１１に進む。

図１４のステップ１０では、ステップ８と同様に、ＳＡＧＳ１００２が、更新をＮＯＤＳ１００４に送信する。

図１４のステップ１１では、ＳＡＧＳ１００２が、ステップ１において受信された要求の処理を終了する。

図１４に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１４に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１４に図示されるステップを行う、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。図１４に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図１５は、ＮＯＤＳ１００４の動作を図示する。

図１５のステップ１では、ＮＯＤＳ１００４が、メッセージをＳＡＧＳ１００２から受信する。

図１５のステップ２では、このメッセージは、集約された通知またはＮＯＤＳ１００４構成であり得る。前者である場合、ステップ５に進む。そうでなければ、ステップ３に進む。

図１５のステップ３では、ＮＯＤＳ１００４が、サブスクリプショングループ情報（すなわち、ＳＧ（ｉ））をステップ１において受信されたメッセージから抽出し、対応する通知グループＮＧ（ｉ）を構成する。ＮＧ（ｉ）は、以下の情報または属性を含む。

ＮＧ（ｉ）の識別子。

ＳＧ（ｉ）が含む全サブスクリプション要求の通知ＵＲＩのリスト。各通知ＵＲＩは、ＮＧ（ｉ）のメンバと見なされ得る。

図１５のステップ４では、ＮＯＤＳ１００４が、ＮＧ（ｉ）の識別子またはＵＲＩをＳＡＧＳ１００２に送信する。ＳＡＧＳ１００２は、ＮＧ（ｉ）の識別子またはＵＲＩをＳＧ（ｉ）の新しい属性として追加するであろう。次いで、ステップ１１に進む。

図１５のステップ５では、ＮＯＤＳ１００４が、ステップ１において受信された集約された通知を分析し、既存のＮＧ（ｉ）の識別子またはＵＲＩを含むかどうかを決定する。回答が「はい」である場合、ステップ６に進む。そうでなければ、ステップ８に進む。

図１５のステップ６では、ＮＯＤＳ１００４が、ＮＧ（ｉ）をそのローカルデータベースから特定し、そのメンバ（すなわち、オリジナルサブスクライバのための通知ＵＲＩ）を見出す。

図１５のステップ７では、ＮＯＤＳ１００４が、通知コンテンツ（ステップ１において受信されたメッセージ内に含まれるような）を各通知ＵＲＩに配信する。次いで、ステップ１１に進む。

図１５のステップ８では、ＮＯＤＳ１００４が、通知ＵＲＩ情報を受信された集約された通知メッセージから抽出する。

図１５のステップ９では、ＮＯＤＳ１００４が、通知コンテンツを各通知ＵＲＩまたはサブスクライバに配信する。

図１５のステップ１０では、ＮＯＤＳ１００４が、サブスクライバからの応答を待つ。応答が返されない場合、ＮＯＤＳ１００４は、ステップ９に進み、通知を再伝送し得る。

図１５のステップ１１では、ＮＯＤＳ１００４が、ステップ１において受信されたメッセージの処理を終了する。

図１５に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１５に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１５に図示されるステップを行う、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。図１５に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図１６は、イベントが発生し、ＳＡＧＳ１００２が集約された通知をＮＯＤＳ１００４に送信する必要があるときのＳＡＧＳ１００２の動作を図示する。このプロシージャは、提案されるアーキテクチャＡ、または、ＳＡＧＳ１００２およびＮＯＤＳ１００４が共同設置されない場合の提案されるアーキテクチャＢのために要求される。

図１６のステップ１では、ホストノード上のサブスクライブされるリソースに関連するイベントが発生する。

図１６のステップ２では、その結果、ＳＡＧＳ１００２が、このイベントに関連する任意のサブスクリプショングループが存在するかどうかをチェックする必要がある必要があり、必要とされる場合、集約された通知をＮＯＤＳ１００４に送信する。

回答が「はい」である場合、図１６のステップ３に進む。そうでなければ、ステップ８に進む。

図１６のステップ３では、ＳＡＧＳ１００２が、各見出されたサブスクリプショングループＳＧ（ｉ）を処理し、ＳＧ（ｉ）の以下の情報を得る。

対応するＮＯＤＳ１００４のアドレス。

該当する場合、ＳＡＧＳ１００２がＮＯＤＳ１００４内で以前に構成した対応するＮＧ（ｉ）のＵＲＩの識別子。

ＳＧ（ｉ）が含む、全サブスクリプション要求の通知ＵＲＩ。

図１６のステップ４では、ＳＡＧＳ１００２が、ＳＧ（ｉ）がＮＯＤＳ１００４内で以前に構成されている対応するＮＧ（ｉ）を有するかどうかをチェックする。

回答が「はい」である場合、図１６のステップ５に進む。そうでなければ、図１６のステップ６に進む。

図１６のステップ５では、ＳＡＧＳ１００２が、集約された通知をこのＳＧ（ｉ）に関連付けられたＮＯＤＳ１００４に送信する。このメッセージは、対応するＮＧ（ｉ）の識別子またはＵＲＩに向けられる。次いで、図１６のステップ７に進む。

図１６のステップ６では、ＳＡＧＳ１００２が、集約された通知をこのＳＧ（ｉ）に関連付けられたＮＯＤＳ１００４に送信する。ＳＡＧＳ１００２は、ＮＧ（ｉ）をＮＯＤＳ１００４内で構成していなかったので、このメッセージは、ＳＧ（ｉ）内に含まれるように全サブスクリプション要求の通知ＵＲＩを含むであろう。

図１６のステップ７では、ＳＡＧＳ１００２が、ＳＧ（ｉ）が図１６のステップ２において見出された最後のサブスクリプショングループであるかどうかをチェックする。

回答が「はい」である場合、図１６のステップ２において見出される全サブスクリプショングループが処理されたことを意味し、図１６のステップ１０に進む。そうでなければ、図１６のステップ３に戻る。次いで、図１６のステップ１０に進む。

図１６のステップ８では、ＳＡＧＳ１００２が、図１６のステップ１におけるイベントに関連する任意のグループ化されていないサブスクリプション要求が存在するかどうかを見出すことを試みる。

回答が「はい」である場合、図１６のステップ９に進む。そうでなければ、図１６のステップ１０に進む。

図１６のステップ９では、ＳＡＧＳ１００２が、通常通知を図１６のステップ８において見出される各サブスクリプション要求に関連付けられたサブスクライバに送信する。

図１６のステップ１０では、ＳＡＧＳ１００２が、ステップ１において発生したイベントの処理を終了する。

図１６に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１６に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１６に図示されるステップを行う、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。図１６に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図１７では、複数のサブスクライバ（例えば、Ｍ２Ｍアプリケーション）が、ホストノード（例えば、Ｍ２Ｍゲートウェイ）における同一のサブスクライブされるリソースへのサブスクリプションを行う。ホストノードは、ＳＡＧＳ１００２を有し、ＳＡＧＳ１００２は、これらのサブスクリプションをグループ化し、通知グループを通過ノード８１０内のＮＯＤＳ１００４において構成し、順に、集約された通知を通過ノード８１０内のＮＯＤＳ１００４に送信する。ＮＯＤＳ１００４は、最終的に、別個の通知を各サブスクライバに配信するであろう。詳細なプロシージャは、以下に説明される。

図１７のステップ１では、サブスクライバ１が、サブスクリプション要求をホストノードに送信する。このメッセージは、以下のパラメータを含み得る。

ｒｅｓｏｕｒｃｅＩＤ：サブスクライバ１がサブスクリプションを行っているサブスクライブされるリソースの識別子を表す。

ｎｏｔｉｆＵＲＩ：サブスクライバ１が通知が送信されることを欲するＵＲＩまたはアドレスを表す。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：ｎｏｔｉｆＵＲＩへの通知の送信をトリガするための条件を表す。

ａｇｇｒｇＦｌａｇ：このサブスクリプション要求が集約されることができるかどうかを示す。

ＮＯＤＳ１００４ＵＲＩ：サブスクライバ１が集約された通知が送信されることを欲するＮＯＤＳ１００４のＵＲＩを表す。例えば、サブスクライバ１は、ＮＯＤＳ１００４ＵＲＩをそのレジストラＣＳＥに設定することができる。

ａｇｇｒｇＦｌａｇ＝ＦＡＬＳＥの場合、それは、サブスクライバ１は、サブスクリプション集約を欲せず、次に、ＮＯＤＳ１００４ＵＲＩは、必要とされなくてもよいことを意味する。

図１７のステップ２では、サブスクライバ２が、サブスクリプション要求をホストノードに送信する。メッセージは、図１７のステップ１におけるメッセージと同一パラメータを含む。

図１７のステップ３では、ホストノード内のＳＡＧＳ１００２が、同一ｒｅｓｏｕｒｃｅＩＤ、類似ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ、および同一ＮＯＤＳ１００４ＵＲＩを有するので、ステップ１およびステップ３において受信されたサブスクリプション要求の両方を集約する。その結果、ＳＡＧＳ１００２は、両要求のためのサブスクリプショングループを作成する。

例証を容易にするために、２つのみのサブスクライバおよび２つのみのサブスクリプション要求が図１７に示されることに留意されたい。しかし、ＳＡＧＳ１００２は、より多くのサブスクライバおよびそのサブスクリプション要求を集約することができる。

図１７のステップ４では、ＳＡＧＳ１００２が、ＮＯＤＳ１００４において通知グループを作成または更新するために、メッセージをＮＯＤＳ１００４に送信する（ＮＯＤＳ１００４のアドレスは、図１７のステップ１および図１７のステップ２に示されることに留意されたい）。メッセージは、以下のパラメータを含み得る。

図１７のステップ１に含まれるｎｏｔｉｆＵＲＩ１。

図１７のステップ２に含まれるｎｏｔｉｆＵＲＩ２。

随意に、サブスクライバ１およびサブスクライバ２の識別子。

図１７のステップ５では、故に、ＮＯＤＳ１００４が、２つのメンバ（すなわち、ステップ１およびステップ２において受信されたｎｏｔｉｆＵＲＩ１ならびにｎｏｔｉｆＵＲＩ２）を有する通知グループを作成する。ＮＯＤＳ１００４は、識別子をこの通知グループに割り当てる。

図１７のステップ６では、ＮＯＤＳ１００４が、作成された通知グループの識別子をＳＡＧＳ１００２に送信する。

図１７のステップ７では、ステップ１およびステップ２におけるｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａを満たすイベントが、発生する。

図１７のステップ８では、発生したイベントに起因して、ＳＡＧＳ１００２が、集約された通知をＮＯＤＳ１００４に送信する。このメッセージは、ステップ６において受信されるような通知グループを標的化する。言い換えると、このメッセージは、標的化された通知グループの識別子を含む。

ＮＯＤＳ１００４のアドレスは、ステップ１およびステップ２で示されることに留意されたい。

図１７のステップ９では、ＮＯＤＳ１００４が、図１７のステップ５において作成されるような標的化された通知グループおよびそのメンバ（すなわち、ｎｏｔｉｆＵＲＩ１ならびにｎｏｔｉｆＵＲＩ２）を特定する。

図１７のステップ１０では、ＮＯＤＳ１００４が、集約された通知をｎｏｔｉｆＵＲＩ２に転送する。

図１７のステップ１１では、ＮＯＤＳ１００４が、集約された通知をｎｏｔｉｆＵＲＩ１に転送する。

図１７のステップ１２では、ＮＯＤＳ１００４が、応答をＳＡＧＳ１００２に送信し、ＮＯＤＳ１００４が通知を正常に送達しなかったｎｏｔｉｆＵＲＩ（すなわち、サブスクライバ）の通知またはリストを正常に受信したｎｏｔｉｆＵＲＩ（すなわち、サブスクライバ）のリストを知らせる。

図１７について、いくつかのオプションまたは代替が存在する。

注記１：サブスクライバ１およびサブスクライバ２は、そのサブスクリプション要求をそのレジストラＣＳＥ（例えば、図中の通過ノード８１０）を介して送信し得る。随意に、両サブスクライバは、ＮＯＤＳ１００４ＵＲＩをそのサブスクリプション要求内に示さないが、レジストラＣＳＥ自体が、そのアドレスをＮＯＤＳ１００４ＵＲＩとして各サブスクリプション要求の中に挿入することができる。

図１７に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１７に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１７に図示されるステップを行う、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。図１７に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

サブスクリプション分析およびグループ化はまた、通過ノード（例えば、図１８における通過ノード２）においても行われることができる。この場合、通過ノードは、ＳＡＧＳ１００２およびＮＯＤＳ１００４の両方を有する。通過ノードにおけるサブスクリプション分析およびグループ化を促進するために、ホストノードは、最初に、そのイベント通知基準を通過ノードにパブリッシュする必要があり得る。次いで、サブスクライバは、それらのイベント通知基準に従って、サブスクリプションを行うであろう。詳細なプロシージャは、以下に説明され、それは、３段階：サブスクリプション分析およびグループ化（すなわち、図１８のステップ１−１０）、既存のサブスクリプショングループへの新しいサブスクリプションの追加（すなわち、図１８のステップ１１−１４）、および通知配信（すなわち、図１８のステップ１５−２３）から成る。

図１８のステップ１では、ホストノードが、そのリソースおよび関連付けられたイベント通知基準を、ホストノードのレジストラＣＳＥであり得る通過ノード２にパブリッシュする。このメッセージは、以下の３つのパラメータのリストを含む。

ｒｅｓｏｕｒｃｅＩＤ：サブスクライブされることができるソースの識別子。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：ｒｅｓｏｕｒｃｅＩＤによって示されるようなリソースに関連付けられたイベント通知基準。

ｗｈｉｔｅＳｕｂＬｉｓｔ：ｒｅｓｏｕｒｃｅＩＤによって示されるようなリソースへのサブスクリプションを行うことが許可されるサブスクライバのリスト。

ｂｌａｃｋＳｕｂＬｉｓｔ：ｒｅｓｏｕｒｃｅＩＤによって示されるようなリソースへのサブスクリプションを行うことが許可されないサブスクライバのリスト。

サブスクライバを許可または却下するためのアクセス制御基準。アクセス制御基準は、サブスクライバの場所、サブスクライバのサービスまたはアプリケーションタイプ等に基づき得ることに留意されたい。

図１８のステップ２では、通過ノード２が、ｒｅｓｏｕｃｅＩＤおよびそのｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａのリストを維持する。応答をホストノードに返信する。

図１８のステップ３では、サブスクライバ１が、サブスクリプション要求を通過ノード２に送信する。ｒｅｓｏｕｒｃｅＩＤ、ｎｏｔｉｆＵＲＩ、およびｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａに加え、このメッセージは、随意に、２つの新しいパラメータａｇｇｒｇＦｌａｇおよびＮＯＤＳ１００４ＵＲＩを含み得る。このメッセージの宛先が通過ノード２であることに留意されたい。

ａｇｇｒｇＦｌａｇ：サブスクライバ１が、このサブスクリプション要求が集約されることを欲するか（例えば、ａｇｇｒｇＦｌａｇ＝ＴＲＵＥの場合）または欲しないか（例えば、ａｇｇｒｇＦｌａｇ＝ＦＡＬＳＥの場合）を示すためのフラグ。

ＮＯＤＳ ＵＲＩは、サブスクライバ１が集約された通知が送信されることを欲する、ＮＯＤＳ１００４のＵＲＩを表す。例えば、サブスクライバ１は、ＮＯＤＳ１００４ＵＲＩをそのレジストラＣＳＥに設定することができる。このパラメータは、随意である。

ａｇｇｒｇＦｌａｇ＝ＦＡＬＳＥの場合、サブスクライバ１は、サブスクリプション集約を欲せず、次に、ＮＯＤＳ ＵＲＩは、必要とされないことを意味する。

図１８のステップ４では、サブスクライバ２が、サブスクリプション要求を通過ノード２に送信する。このメッセージは、ステップ３に類似する。このメッセージの宛先は、通過ノード２であることに留意されたい。

図１８のステップ５では、通過ノード２内のＳＡＧＳ１００２が、ステップ３およびステップ４における両要求が集約されることができる（例えば、同一ｒｅｓｏｕｒｃｅＩＤおよびｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａを有し、両方とも、ステップ１において受信されるようなｗｈｉｔｅＳｕｂＬｉｓｔ内にある）ことを見出す。次いで、両要求を集約し、サブスクリプショングループＳＧ（ｉ）を作成する。

図１８のステップ６では、通過ノード２ １８０２内のＳＡＧＳ１００２が、メッセージを通過ノード１ ８１０に送信し、通過ノード１ ８１０は、通知グループを作成または更新するＮＯＤＳ１００４を有する。このメッセージは、ｎｏｔｉｆＵＲＩ１（サブスクライバ１ １００６から）およびｎｏｔｉｆＵＲＩ２（サブスクライバ２から）を含む。通過ノード１ ８１０は、サブスクライバまたはそれらの通知受信側により近接し得る。したがって、それがＮＯＤＳ１００４を行うことがより効率的である。

ＳＡＧＳ１００２およびＮＯＤＳ１００４は、同一通過ノード内に共同設置され得ることに留意されたい。例えば、Ｍ２Ｍネットワークアプリケーションは、サブスクリプション要求をそのレジストラＭ２Ｍサーバに送信する。レジストラＭ２Ｍサーバは、ＳＡＧＳ１００２およびＮＯＤＳ１００４の両方を有する。Ｍ２Ｍネットワークアプリケーションは、ＮＯＤＳ１００４ＵＲＩもａｇｇｒｇＦｌａｇも示す必要はない。レジストラＭ２Ｍサーバは、そのサブスクリプション要求を集約することができる。

通過ノード１は、通過ノード２によって選択され得、通過ノード２は、例えば、通過ノード２における高交通負荷または通過ノード１がサブスクライバにより近接することに起因して、そのＮＯＤＳ１００４を通過ノード１に委任することに留意されたい。ステップ６は、そのようなＮＯＤＳ１００４委任を同時に行うことができ、追加のメッセージの必要性はない。

図１８のステップ７では、通過ノード１内のＮＯＤＳ１００４が、対応する通知グループＮＧ（ｉ）を作成／更新する。ＮＧ（ｉ）は、２つのメンバ（すなわち、ｎｏｔｉｆＵＲＩ１およびｎｏｔｉｆＵＲＩ２）を有する。

図１８のステップ８では、ＮＯＤＳ１００４が、応答をＳＡＧＳ１００２に送信し、ＮＧ（ｉ）の識別子を知らせる。

図１８のステップ９では、通過ノード２ １８０２が、集約されたサブスクリプション要求をホストノードに送信する。このメッセージは、ＳＧ（ｉ）に関連付けられた以下のパラメータを含み得る。加えて、ＳＡＧＳ１００２は、ＳＧ（ｉ）とＮＧ（ｉ）との間のマッピング関係を維持する。

ｒｅｓｏｕｒｃｅＩＤ：サブスクライバ１ １００６およびサブスクライバ２ １００８の両方が関心があるリソースの識別子。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：サブスクライバ１ １００６およびサブスクライバ２ １００８の両方が示すイベント通知基準。

ｎｅｗＮｏｔｉｆＵＲＩ：ホストノード８０８が通知を送信すべきアドレスを示す。通過ノード２ １８０２がこのパラメータを設定するための２つのオプションが、存在する。

オプション１：ｎｅｗＮｏｔｉｆＵＲＩを通過ノード２に設定するか、またはＳＧ（ｉ）の識別子がサブスクライバ１ １００６およびサブスクライバ２ １００８のために作成される。図１８は、このオプションを示す。

オプション２：ｎｅｗＮｏｔｉｆＵＲＩをＮＯＤＳ１００４のアドレス（すなわち、ＮＯＤＳ１００４ＵＲＩ）に設定する。このオプションが使用される場合、ステップ１６は、直接、ホストノード８０８からＮＯＤＳ１００４となるであろう。

ｓｕｂｓｃｒｉｂｅｒＬｉｓｔ：ＳＧ（ｉ）内に含まれるオリジナルサブスクライバのリスト。このパラメータは、随意である。

図１８のステップ１０では、ホストノードが、応答を通過ノード２に返信する。

ｓｕｂｓｃｒｉｂｅｒＬｉｓｔが図１８のステップ９に含まれる場合、ホストノードは、一部のサブスクライバを承認しないこともある。これが生じる場合、通過ノード２内のＳＡＧＳ１００２は、図１８のステップ６−８を繰り返し、ＮＯＤＳ１００４内のＮＧ（ｉ）を更新するであろう。

図１８のステップ１１では、別のサブスクライバ３が、ステップ３およびステップ４に類似する、サブスクリプション要求を行う。

図１８のステップ１２では、ＳＡＧＳ１００２が、この要求がＳＧ（ｉ）に集約されることができる（例えば、同一ｒｅｓｏｕｒｃｅＩＤおよび同一ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａを伴う）ことを見出す。その結果、サブスクライバ３をＳＧ（ｉ）に追加する。

図１８のステップ１３では、ＳＡＧＳ１００２が、メッセージを送信し、ＮＯＤＳ１００４をサブスクライバ３のｎｏｔｉｆＵＲＩ３で更新する。

図１８のステップ１４では、ＮＯＤＳ１００４が、ｎｏｔｉｆＵＲＩ３をＮＧ（ｉ）に新しいメンバとして追加する。

図１８のステップ１５では、ステップ３／４／１１におけるｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａに対応するイベントが、発生する。

図１８のステップ１６では、ホストノード８０８が、通知をステップ９に示されるｎｅｗＮｏｔｉｆＵＲＩに送信する。

図１８のステップ１７では、通過ノード２が、この通知を受信し、通知をＮＧ（ｉ）に転送する。

図１８のステップ１８では、通過ノード１ ８１０内のＮＯＤＳ１００４が、通知を受信する。この通知から標的ＮＧ（ｉ）を見出し、その結果、通知をＮＧ（ｉ）の全メンバ（すなわち、ｎｏｔｉｆＵＲＩ１、ｎｏｔｉｆＵＲＩ２、およびｎｏｔｉｆＵＲＩ３）に配信する。

図１８のステップ１９−２１では、ＮＯＤＳ１００４が、通知を、それぞれ、３つのサブスクライバに配信する。

図に示されないが、各サブスクライバは、応答をＮＯＤＳ１００４に返信し、通知の受信を肯定応答し得る。ＮＯＤＳ１００４への応答メッセージでは、各サブスクライバはまた、将来の通知を受信するための新しいｎｏｔｉｆＵＲＩを示し得る。

図１８のステップ２２では、ＮＯＤＳ１００４が、応答をＳＡＧＳ１００２に送信し、オリジナルサブスクライバが通知を正常に受信したことを知らせる。

図１８のステップ２３では、ＳＡＧＳ１００２が、応答をホストノードに返信する。

図１８に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１８に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１８に図示されるステップを行う。図１８に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

既存のｏｎｅＭ２Ｍでは、各アナウンスされたリソースは、対応するオリジナルリソースを有し、アナウンスされたリソースは、サブスクライブされることができる。言い換えると、Ｍ２Ｍエンティティは、アナウンスされたリソースの変更についての通知を得るためのサブスクリプション要求をアナウンスされたリソースに発行することができる。しかし、この要求は、オリジナルリソースのイベントまたは変更についての通知を得ることができない。図１９は、Ｍ２Ｍエンティティがサブスクリプション要求をアナウンスされたリソースに送信するが、意図がオリジナルリソースの変更についての将来的通知を得ることである場合を示す。

図１９のステップ１では：ホストノード８０８が、修正リソースアナウンスメントメッセージを通過ノードに送信する。オリジナルリソースの識別子（すなわち、ｒｅｓｏｕｒｃｅＩＤ）に加え、このメッセージは、図１９のステップ４におけるサブスクリプションを促進するための以下の新しいパラメータを含む。これらの新しいパラメータは、図１９のステップ２において作成されるべきアナウンスされたリソースのための新しい属性として追加されるであろう。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：アナウンスされているリソースのイベント通知基準を表す。

ｓｕｂＰｏｌｉｃｙ：アナウンスされているリソースに対するサブスクリプションポリシを表す（例えば、前述の節において定義されるようなｗｈｉｔｅＳｕｂＬｉｓｔおよびｂｌａｃｋＳｕｂＬｉｓｔ）。

ｓｕｂＴｏＯｒｉｇｉｎａｌＲｅｓｏｕｒｃｅＥｎａｂｌｅ：このパラメータがＴＲＵＥである場合のみ、オリジナルリソースが、通過ノードにおいて図１９のステップ２において作成されるべきそのアナウンスされたリソースを介してサブスクライブされることができる。

図１９のステップ２では：通過ノードは、対応するアナウンスされたリソース（例えば、＜ｒｓｃ１Ａｎｎｃ＞）を作成する。このリソースは、図１９のステップ１において伝達されるような３つの新しい属性ｓｕｂＴｏＯｒｉｇｉｎａｌＲｅｓｏｕｒｃｅＥｎａｂｌｅ、ｓｕｂＰｏｌｉｃｙ、ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａを有する。

ｓｕｂＴｏＯｒｉｇｉｎａｌＲｅｓｏｕｒｃｅＥｎａｂｌｅ＝ＴＲＵＥの場合、サブスクライバは、このアナウンスされたリソースを介して、オリジナルリソースへのサブスクリプションを行うことができる（例えば、ステップ４、ステップ５、およびステップ８）。

図１９のステップ３では、通過ノードが、応答をホストノードに返信する。

図１９のステップ４では、サブスクライバ１が、サブスクリプション要求を通過ノードに送信する。このメッセージは、以下のパラメータを含む。

ｒｅｓｏｕｒｃｅＩＤ：例として、＜ｒｓｃ１Ａｎｎｃ＞に設定する。それは、サブスクリプション要求がこのアナウンスされたリソース（ｓｕｂＴｙｐｅ＝ＡＮＮＮＯＵＮＣＥのとき）またはそのオリジナルリソース（ｓｕｂＴｙｐｅ＝ＯＲＩＧＩＮＡＬのとき）を標的化することを意味する。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：このサブスクリプションに関連付けられたイベント通知基準を示す。このパラメータは、図１９のステップ１に含まれる「ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ」の一部である。

ｓｕｂＴｙｐｅ：サブスクライバがオリジナルリソースの変更（ｓｕｂＴｙｐｅ＝ＯＲＩＧＩＮＡＬのとき）またはアナウンスされたリソースの変更（ｓｕｂＴｙｐｅ＝ＡＮＮＮＯＵＮＣＥのとき）に関心があるかどうかを示す。

ｎｏｔｉｆＵＲＩ１：サブスクライバ１が将来的通知を受信することを期待するアドレスを示す。

図１９のステップ５では、サブスクライバ２ １００８が、サブスクリプション要求を通過ノード８１０に送信する。このメッセージは、図１９のステップ４に類似する。

図１９のステップ６では、通過ノードが、図１９のステップ１において受信されたｓｕｂＰｏｌｉｃｙを使用して、サブスクライバ１ １００６およびサブスクライバ２ １００８からのサブスクリプション要求が承認されるべき（例えば、サブスクライバ１ １００６およびサブスクライバ２ １００８の両方がｗｈｉｔｅＳｕｂＬｉｓｔ内にある）かどうかを決定する。この例では、両要求を承認する。次いで、通過ノードは、図１９のステップ４およびステップ５における要求が同一ｒｅｓｏｕｒｃｅＩＤならびにｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａを有することを見出す。次いで、サブスクリプショングループをアナウンスされたリソースの子リソース（すなわち、＜ｒｓｃ１Ａｎｎｃ＞／＜ｓｕｂＧｒｏｕｐ１＞）として作成する。＜ｓｕｂＧｒｏｕｐ１＞は、２つのメンバ（すなわち、図１９のステップ４およびステップ５において受信されるようなｎｏｔｉｆＵＲＩ１ならびにｎｏｔｉｆＵＲＩ２）および仮想リソース「論理出力数」を有する。仮想リソース「論理出力数」は、＜ｓｕｂＧｒｏｕｐ１＞の各メンバへの通知の配信をトリガするために使用されるであろう。

図１９のステップ７では、通過ノードが、通常サブスクリプション要求をホストノードに以下のパラメータとともに送信する。

ｒｅｓｏｕｒｃｅＩＤ：図１９のステップ４およびステップ５における同一ｒｅｓｏｕｒｃｅＩＤに設定する。

ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａ：図１９のステップ４およびステップ５における同一ｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａに設定する。

ｎｏｔｉｆＵＲＩ：「＜ｒｓｃ１Ａｎｎｃ＞／＜ｓｕｂＧｒｏｕｐ１＞／論理出力数」に設定する。

図１９のステップ８では、サブスクライバ３ １０１０が、サブスクリプション要求を通過ノードに送信する。このメッセージは、図１９のステップ４に類似するが、異なるｎｏｔｉｆＵＲＩ３を伴う。

図１９のステップ９では、通過ノードが、図１９のステップ８における要求が図１９のステップ４およびステップ５におけるものに類似することを見出す。その結果、ｎｏｔｉｆＵＲＩ３を＜ｓｕｂＧｒｏｕｐ１＞に追加する。しかし、通過ノード８１０は、図１９のステップ７においてサブスクリプション要求をホストノード８０８にすでに送信しているので、要求を再び送信せず、したがって、それとホストノード８０８との間のメッセージオーバーヘッドを節約するであろう。

図１９のステップ１０では、ステップ７におけるｅｖｅｎｔＮｏｔｉｆＣｒｉｔｅｒｉａに対応するイベントが、発生する。

図１９のステップ１１では、ホストノード８０８が、通知を通過ノード８１０における「＜ｒｓｃ１Ａｎｎｃ＞／＜ｓｕｂＧｒｏｕｐ１＞／論理出力数」に送信する。キーワード「論理出力数」は、通過ノード８１０が通知を＜ｓｕｂＧｒｏｕｐ１＞の各メンバ（すなわち、ｎｏｔｉｆＵＲＩ１、ｎｏｔｉｆＵＲＩ２、およびｎｏｔｉｆＵＲＩ３）に配信することをトリガするために使用される。

図１９のステップ１２では、通過ノード８１０が、通知をｎｏｔｉｆＵＲＩ１に転送する。

図１９のステップ１３では、通過ノード８１０が、通知をｎｏｔｉｆＵＲＩ２に転送する。

図１９のステップ１４では、通過ノード８１０が、通知をｎｏｔｉｆＵＲＩ３に転送する。

図１９に図示されるステップを行うエンティティは、図２３Ｃまたは図２３Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１９に図示される方法は、図２３Ｃまたは図２３Ｄに図示される装置もしくはコンピュータシステム等のネットワーク装置のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１９に図示されるステップを行う。図１９に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

前述のように、既存のｏｎｅＭ２Ｍは、オリジナル属性とアナウンスされた属性との間の同期を可能にする機構（アナウンスメント同期と称される）を説明する。しかし、そのようなアナウンスメント同期を実装する方法に関する詳細を与えていない。図１９における構成を例として検討すると、アナウンスメント同期は、リソースサブスクリプションと一緒に統合され得る。

代替実施形態のステップ１では、ホストノード（例えば、ＭＮ−ＣＳＥ）が、そのリソース（すなわち、オリジナルリソース）を通過ノード（例えば、ＩＮ−ＣＳＥ）にアナウンスする。

代替実施形態のステップ２では、通過ノード８１０が、対応するアナウンスされたリソースを作成する。

代替実施形態のステップ３では、サブスクライバ１ １００６（例えば、ＩＮ−ＡＥ１）が、通過ノード上のアナウンスされたリソースにサブスクライブする。

代替実施形態のステップ４では、ホストノード８０８が、そのオリジナルリソースとアナウンスされたリソースとの間の同期を維持する。言い換えると、ホストノード８０８は、アナウンスされたリソースがオリジナルリソースと同期されたままであろうように、オリジナルリソースに変更がある度に、通知を通過ノード８１０に送信することができる。

代替実施形態のステップ５では、通過ノード８１０が、ホストノード８０８から受信された通知に基づいて、アナウンスされたリソースを更新する。次いで、その最新値を使用して、サブスクライバ１ １００６からのサブスクリプションにサービスを提供する。例えば、アナウンスされたリソースの新しい値がサブスクライバ１ １００６によって示されるイベント通知基準を満たす場合、通過ノード８１０は、通知をサブスクライバ１ １００６に送信するであろう。

しかしながら、そのようなアナウンスメント同期は、図１９に提示されるソリューションと比較して、いくつかの不利点または短所を有する。

第１に、ｏｎｅＭ２Ｍ仕様は、そのようなアナウンスメント同期が実装されるであろう方法に関する詳細を与えていない。

第２に、ｏｎｅＭ２Ｍ仕様では、「オリジナルリソースによってアナウンスされた属性とアナウンスされたリソースとの間の同期は、オリジナルリソースホストＣＳＥの責任である」と定めている。それは、ホストＣＳＥがアナウンスメント同期が行われるであろう方法を決定することを含意する。したがって、それは、リソースサブスクリプションから独立する。言い換えると、アナウンスされたリソースに対するリソースサブスクリプションは、独立し、アナウンスメント同期によって影響されないであろう。

そのようなアナウンスメント同期は、オリジナルリソースの新しい値がどんなサブスクライバによっても関心が示されなくとも、ホストＣＳＥ８１０が通知を通過ノード８０８に送信し続ける必要があるであろう。図１９に提示されるソリューションと比較して、そのようなアナウンスメント同期は、より多くの通知およびオーバーヘッドをホストＣＳＥ８１０と通過ＣＳＥとの間に生じさせる。

一部のサブスクライバは、イベントに関心があり得る（例えば、オリジナルリソースに関するＵＰＤＡＴＥ動作が存在する）。アナウンスメント同期を単に使用することでは、アナウンスメント同期がそのようなイベントをアナウンスされたリソースに報告しないので、この目標を達成することはできない。

３つの新しい属性が、表４に列挙されるように、既存のｏｎｅＭ２Ｍ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのために提案される。

３つの新しい属性が、表５に列挙されるように、既存のｏｎｅＭ２Ｍアナウンスリソースのために提案される。

新しい共通属性が、サブスクライバによってサブスクライブされ得る任意のリソースのために提案される（表６）。

前述のように、ＳＡＧＳ１００２からＮＯＤＳ１００４への集約された通知は、各オリジナルサブスクライバへの全ｎｏｔｉｆＵＲＩを含み得る。この特徴をサポートするために、既存のｏｎｅＭ２Ｍ通知メッセージが、通知がＳＡＧＳ１００２からＮＯＤＳ１００４に送信される集約された通知であるとき、以下のパラメータ／情報を含むことが提案される。

ｎｏｔｉｆＵＲＩＬｉｓｔ：各オリジナルサブスクライバへのｎｏｔｉｆＵＲＩのリストを示す。言い換えると、このリスト内の各アイテムは、異なるサブスクライバへのｎｏｔｉｆＵＲＩである。ＮＯＤＳ１００４が集約通知をＳＡＧＳ１００２から受信すると、ＮＯＤＳ１００４は、このパラメータ内に含まれる全ｎｏｔｉｆＵＲＩを抽出し、通知を各ｎｏｔｉｆＵＲＩに配信するであろう。

サブスクライバが通知メッセージを受信すると、サブスクライバは、応答を返信する必要がある。この通知応答メッセージは、新しいパラメータｎｏｔｉｆＵＲＩを含むことが提案される。新しいｎｏｔｉｆＵＲＩは、基本的に、ホストノード（または通過ノード）に、将来的通知を受信するためのアドレスを伝える。

図２０は、提案されるアイディアを既存のＳＵＢ ＣＳＦに実装し、現在のｏｎｅＭ２Ｍ機能アーキテクチャに基づいて、拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦ２００２を形成するための一例示的実施形態を示す。

この新しいｅＳＵＢ２００２は、提案されるＳＡＧＳ１００２および／またはＮＯＤＳ１００４サービスをサポートする。それは、アナウンスされたリソースを介したサブスクリプションもサポートする。ｅＳＵＢ２００２は、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、および／またはＡＳＮ−ＣＳＥ内に常駐することができる。図２１は、ｏｎｅＭ２ＭにおけるｅＳＵＢ２００２の２つの例示的展開を図示し、提案されるｅＳＵＢは、ＭｃｃおよびＭｃａ参照点上のメッセージング相互作用に影響を及ぼすであろう。

図２１Ａでは、サブスクライバは、ＩＮ−ＡＥであり、ホストノードは、ＭＮ−ＣＳＥであり、通過ノードは、ＩＮ−ＡＥのレジストラＣＳＥであるＩＮ−ＣＳＥである。ｅＳＵＢ２００２は、ＭＮ−ＣＳＥおよびＩＮ−ＣＳＥの両方内に含まれる。ＭＮ−ＣＳＥ内のｅＳＵＢは、ＳＡＧＳ１００２のみをサポートする一方、ＩＮ−ＣＳＥ内のｅＳＵＢは、ＳＡＧＳ１００２およびＮＯＤＳ１００４の両方をサポートし得る。通知受信側は、ＩＮ−ＡＥである。

図２１Ｂでは、サブスクライバは、ＡＤＮ−ＡＥであり、ホストノードは、ＩＮ−ＣＳＥであり、通過ノードは、ＡＤＮ−ＡＥのレジストラＣＳＥであるＭＮ−ＣＳＥである。ＩＮ−ＣＳＥは、ＭＮ−ＣＳＥのレジストラＣＳＥである。ｅＳＵＢは、ＭＮ−ＣＳＥおよびＩＮ−ＣＳＥの両方内に含まれる。ＩＮ−ＣＳＥ内のｅＳＵＢは、ＳＡＧＳ１００２のみをサポートする一方、ＭＮ−ＣＳＥ内のｅＳＵＢは、ＳＡＧＳ１００２およびＮＯＤＳ１００４の両方をサポートし得る。通知受信側は、ＡＤＮ−ＡＥである。

図２０−２１に図示される機能性は、以下に説明される図２３Ｃまたは２３Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークの装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、サブスクリプション集約に関連するパラメータおよび／または結果を表示ならびに／もしくは調節するために使用されることができる。図２２は、インターフェース２２０２および２２０４を図示する略図である。

ユーザインターフェース２２０２は、ホストノード（例えば、Ｍ２Ｍゲートウェイ）に追加され、ＳＡＧＳ１００２によって作成されるサブスクリプショングループおよび各グループのメンバ等のサブスクリプション集約に関連する情報を表示することができる。

ユーザインターフェース２２０４も、通過ノード（例えば、Ｍ２Ｍサーバ）に追加され、以下等のサブスクリプション集約および通知配信に関連する情報を表示することができる。
ＳＡＧＳ１００２によって作成されるサブスクリプショングループおよびそのメンバ
ＮＯＤＳ１００４によって作成される通知グループおよびそのメンバ
各通知グループについての統計（例えば、各メンバに正常に配信された通知の数）

インターフェース２２０２および２２０４は、以下で説明される図２３Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用される場合、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は、同義的に使用され得る。

用語「サービス層」は、ネットワークサービスアーキテクチャ内の機能層を指す。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはＳＣＬと称され得る、サービス層によってサポートされる前述の能力または機能性の集合もしくは組へのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する機能エンティティ（例えば、そのような機能エンティティ間の機能インターフェース）である。

図２３Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の機能性ならびに論理エンティティを含むことができる。

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

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

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２３Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２３Ｃおよび２３Ｄで図示されるデバイスを含む１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

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

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

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、他の開示されるシステムおよび方法と併せて使用され得る。

一実施形態では、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティは、図２３Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健ならびに健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。前述のように、本システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、もしくは１つ以上の既存のノードの一部としてのいずれかで実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２３Ｃまたは図２３Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で作動するソフトウェアの形態において実装され得る。

さらに、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２３Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。デバイス３０は、図２３Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部または非Ｍ２Ｍネットワークの一部であり得る。図２３Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させてもよい。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

図２３Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御し得る。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図２３Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内に一緒に統合され得ることが理解されるであろう。

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させる、もしくはノードのセッション移行または共有能力、もしくは設定についての入力をユーザから得るように、または情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にし得る。

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

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

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

図２３Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等、Ｍ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４
１００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、例えば、図２３Ａおよび図２３Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にし得る。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。それは、携帯電話、モバイルブロードバンドアダプタを装備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図２３Ａ−ＢのＭ２Ｍ端末デバイス１８または図２３Ｃのデバイス３０として実装されることができる。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。ＣＳＥ２０２、Ｍ２Ｍサーバ６０２、７０８、通過ノード８１０および１８０２、ホストノード８０８、Ｍ２Ｍ ＡＥ８０２、８０４、および８０６、ＳＡＧＳ１００２、ＮＯＤＳ１００４ １００４、サブスクライバ１００６、１００８、および１０１０、ｅＳＵＢ ＣＳＦ２００２を含むＣＳＦ、ならびにインターフェース２２０２および２２０４を生成するための論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されるコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形または物理媒体を含むが、それらに限定されない。

図に図示されるような本開示の主題の好ましい実施形態を説明することにおいて、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図しておらず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (4)

1. プロセッサとメモリとを備えた装置であって、前記装置は、前記装置の前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記装置のプロセッサによって実行されると、
   第１のリソースにサブスクライブするための第１の要求を第１のサブスクライバデバイスから受信することであって、前記第１の要求は、前記第１のサブスクライバデバイスに関連付けられた第１の識別子を含む、ことと、
   前記第１のリソースにサブスクライブするための第２の要求を第２のサブスクライバデバイスから受信することであって、前記第２の要求は、前記第２のサブスクライバデバイスに関連付けられた第２の識別子を含む、ことと、
   前記第１のリソースをホストする第１のノードに対して、前記第１の要求と前記第２の要求を送信することと、
   前記第１のノードから、リソースの更新に関する集約された通知を受信することであって、前記集約された通知は、前記リソースの更新に関する通知が前記第１のサブスクライバデバイス及び前記第２のサブスクライバデバイスに配布されることを示す指示を含み、
   前記指示に応答して、前記リソースの更新の通知を前記第１のサブスクライバデバイスに送信し、前記リソースの更新の通知を前記第２のサブスクライバデバイスに送信することと
   を前記装置に行わせる、装置。
2. 前記コンピュータ実行可能な命令は、前記第１のノードから、前記第１のサブスクライバデバイス及び前記第２のサブスクライバデバイスを第１のグループとして設定するための設定情報を受信することを前記装置に行わせ、
   前記集約された通知に含まれる前記指示は、前記第１のグループを参照する情報を含む、
   請求項１に記載の装置。
3. 前記装置は、前記第１のノードにおける前記第１のリソースにリンクするようアナウンスされたリソースを含む、請求項１に記載の装置。
4. 通信ネットワークの装置によって使用される方法であって、
   第１のリソースにサブスクライブするための第１の要求を第１のサブスクライバデバイスから受信することであって、前記第１の要求は、前記第１のサブスクライバデバイスに関連付けられた第１の識別子を含む、ことと、
   前記第１のリソースにサブスクライブするための第２の要求を第２のサブスクライバデバイスから受信することであって、前記第２の要求は、前記第２のサブスクライバデバイスに関連付けられた第２の識別子を含む、ことと、
   前記第１のリソースをホストする第１のノードに対して、前記第１の要求と前記第２の要求を送信することと、
   前記第１のノードから、リソースの更新に関する集約された通知を受信することであって、前記集約された通知は、前記リソースの更新に関する通知が前記第１のサブスクライバデバイス及び前記第２のサブスクライバデバイスに配布されることを示す指示を含み、
   前記指示に応答して、前記リソースの更新の通知を前記第１のサブスクライバデバイスに送信し、前記リソースの更新の通知を前記第２のサブスクライバデバイスに送信することと
   を含む方法。