特許 6892445 Ｍ２Ｍサービス層のためのクロスリソースサブスクリプション

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6892445

(24)【登録日】2021年5月31日

(45)【発行日】2021年6月23日

(54)【発明の名称】Ｍ２Ｍサービス層のためのクロスリソースサブスクリプション

(51)【国際特許分類】

   H04M 11/00 20060101AFI20210614BHJP

   G06F 13/00 20060101ALI20210614BHJP

【ＦＩ】

   H04M11/00 301

   G06F13/00 353C

【請求項の数】15

【全頁数】45

(21)【出願番号】特願2018-524751(P2018-524751)

(86)(22)【出願日】2016年11月15日

(65)【公表番号】特表2018-535605(P2018-535605A)

(43)【公表日】2018年11月29日

(86)【国際出願番号】US2016061997

(87)【国際公開番号】WO2017087367

(87)【国際公開日】20170526

【審査請求日】2018年6月28日

【審判番号】不服2020-4254(P2020-4254/J1)

【審判請求日】2020年3月31日

(31)【優先権主張番号】62/255,649

(32)【優先日】2015年11月16日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】ワン， チョンガン

(72)【発明者】

【氏名】ディ ジローラモ， ロッコ

(72)【発明者】

【氏名】リ， ホンクン

(72)【発明者】

【氏名】リ， チン

(72)【発明者】

【氏名】リ， シュウ

(72)【発明者】

【氏名】ムラディン， カタリーナ エム．

【合議体】

【審判長】 佐藤 智康

【審判官】 谷岡 佳彦

【審判官】 丸山 高政

(56)【参考文献】

【文献】 国際公開第２０１５／０３１７５０（ＷＯ，Ａ１）

【文献】 国際公開第２０１５／０４６９６０（ＷＯ，Ａ１）

【文献】 特表２０１１−５２３８０７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F13/00

H03J 9/00- 9/06

H04B 7/24- 7/26

H04L12/00-12/26,12/50-12/955

H04M 1/00, 1/24- 3/00, 3/16- 3/20,

3/38- 3/58, 7/00- 7/16,

11/00-11/10,99/00

H04Q 9/00- 9/16

H04W 4/00-99/00

(57)【特許請求の範囲】

【請求項1】

監視対象となる複数の標的リソースに予め定められた変化が起こった場合に通知を行うクロスリソースサブスクリプションのための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
クロスリソースサブスクリプションのための要求メッセージを受信することであって、前記要求メッセージは、前記複数の標的リソースに関する情報および時間のウィンドウに関する情報を含み、遠隔デバイスによる、サブスクリプションのための要求を示し、前記サブスクリプションは、前記時間のウィンドウ内で基準を満たす前記複数の標的リソースの変更を通知されるべき前記遠隔デバイスのためのものであることと、
前記要求メッセージに基づいて、前記複数の標的リソースが前記装置とは異なる一又は複数のリソースホストにホストされていることを決定することと、
前記決定に基づいて、前記複数の標的リソースをホストする一又は複数のリソースホストとの間で、サブスクリプションに関するメッセージの交換を行うことと、
前記サブスクリプションに関するメッセージの交換に基づいて、前記クロスリソースサブスクリプションを実現するためのローカルサブスクリプションリソースを前記装置が生成することであって、前記ローカルサブスクリプションリソースは、前記遠隔デバイスへの通知を行う際に参照される前記基準を含むことと
を含む動作を前記プロセッサに達成させ、
前記遠隔デバイスは、前記複数の標的リソースの状態が前記基準を満たす場合に、前記装置から通知を享受可能である、
装置。

【請求項2】

前記要求メッセージは、前記複数の標的リソースのためのイベント通知基準のリストを備えている、請求項１に記載の装置。

【請求項3】

前記要求メッセージは、前記基準が満たされたときに通知が受信されることを期待されている前記複数の標的リソースの数を備えている、請求項１に記載の装置。

【請求項4】

前記要求メッセージは、前記時間のウィンドウのタイプの指示を備えている、請求項１に記載の装置。

【請求項5】

前記要求メッセージは、前記時間のウィンドウのタイプの指示を備え、前記時間のウィンドウのタイプは、スライディング時間ウィンドウを備えている、請求項１に記載の装置。

【請求項6】

前記動作は、クロスリソースサブスクリプションを承認する旨の応答メッセージを送信することをさらに含む、請求項１に記載の装置。

【請求項7】

前記動作は、前記複数の標的リソースのうちの第１のリソースへのサブスクリプションの要求を提供することをさらに含み、前記第１のリソースへのサブスクリプションの要求は、前記複数の標的リソースの状態が満たすべき前記基準のうち、前記第１のリソースの状態が満たすべき基準を備えている、請求項１に記載の装置。

【請求項8】

前記動作は、
前記複数の標的リソースの状態が満たすべき前記基準のうち前記第１のリソースの状態が満たすべき基準が満たされたという通知を受信することと、
前記通知を受信することに基づいて、前記複数の標的リソースの状態が満たすべき前記基準が満たされていることを決定することと、
前記複数の標的リソースの状態が満たすべき前記基準が満たされていることを決定することに基づいて、前記遠隔デバイスに通知することと
をさらに含む、請求項７に記載の装置。

【請求項9】

前記クロスリソースサブスクリプションは、１つ以上の特定のタイプの共通サービス機能の組を含む共通サービスエンティティによって実現される、請求項１に記載の装置。

【請求項10】

監視対象となる複数の標的リソースに予め定められた変化が起こった場合に通知を行うクロスリソースサブスクリプションのための方法であって、前記方法は、
前記クロスリソースサブスクリプションのための装置が、クロスリソースサブスクリプションのための要求メッセージを受信することであって、前記要求メッセージは、前記複数の標的リソースに関する情報および時間のウィンドウに関する情報を含み、遠隔デバイスによる、サブスクリプションのための要求を示し、前記サブスクリプションは、前記時間のウィンドウ内で基準を満たす前記複数の標的リソースの変更を通知されるべき前記遠隔デバイスのためのものであることと、
前記要求メッセージに基づいて、前記装置が、前記複数の標的リソースが前記装置とは異なる一又は複数のリソースホストにホストされていることを決定することと、
前記決定に基づいて、前記複数の標的リソースをホストする一又は複数のリソースホストとの間で、サブスクリプションに関するメッセージの交換を行うことと、
前記サブスクリプションに関するメッセージの交換に基づいて、前記クロスリソースサブスクリプションを実現するためのローカルサブスクリプションリソースを前記装置が生成することであって、前記ローカルサブスクリプションリソースは、前記遠隔デバイスへの通知を行う際に参照される前記基準を含むことと
を含み、
前記遠隔デバイスは、前記複数の標的リソースの状態が前記基準を満たす場合に、前記装置から通知を享受可能である、
方法。

【請求項11】

前記要求メッセージは、前記複数の標的リソースのためのイベント通知基準のリストを備えている、請求項１０に記載の方法。

【請求項12】

前記要求メッセージは、前記基準が満たされたときに通知が受信されることを期待されている前記複数の標的リソースの数を備えている、請求項１０に記載の方法。

【請求項13】

前記要求メッセージは、前記時間のウィンドウのタイプの指示を備えている、請求項１０に記載の方法。

【請求項14】

コンピュータプログラムが記憶されたコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、前記装置内のデータ処理ユニット内にロードされ、前記コンピュータプログラムが前記データ処理ユニットによって実行されると、請求項１０〜１３のいずれか一項に記載の方法のステップを前記データ処理ユニットに行わせるように適合されている、コンピュータ読み取り可能な記憶媒体。

【請求項15】

監視対象となる複数の標的リソースに予め定められた変化が起こった場合に通知を行うクロスリソースサブスクリプションのための装置、複数のリソースホスト、遠隔デバイスを少なくとも含むシステムであって、
前記遠隔デバイスから前記クロスリソースサブスクリプションのための装置に対して、クロスリソースサブスクリプションのための要求メッセージを送信することであって、前記要求メッセージは、前記複数の標的リソースに関する情報および時間のウィンドウに関する情報を含み、前記遠隔デバイスによる、サブスクリプションのための要求を示し、前記サブスクリプションは、前記時間のウィンドウ内で基準を満たす前記複数の標的リソースの変更を通知されるべき前記遠隔デバイスのためのものであることと、
前記クロスリソースサブスクリプションのための装置によって、前記要求メッセージに基づいて、前記複数の標的リソースが前記装置とは異なる一又は複数のリソースホストにホストされていることを決定することと、
前記決定に基づいて、前記複数の標的リソースをホストする一又は複数のリソースホストとの間で、サブスクリプションに関するメッセージの交換を行うことと、
前記サブスクリプションに関するメッセージの交換に基づいて、前記クロスリソースサブスクリプションを実現するためのローカルサブスクリプションリソースを前記装置が生成することであって、前記ローカルサブスクリプションリソースは、前記遠隔デバイスへの通知を行う際に参照される前記基準を含むこととを含み、
前記遠隔デバイスは、前記複数の標的リソースの状態が前記基準を満たす場合に、前記クロスリソースサブスクリプションのための装置から通知を享受可能である、
システム。

【発明の詳細な説明】

【背景技術】

【0001】

（関連出願の引用）
本願は、米国仮特許出願第６２／２５５，６４９号（２０１５年１１月１６日出願、名称「Ｃｒｏｓｓ−Ｒｅｓｏｕｒｃｅ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｆｏｒ Ｍ２Ｍ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

【0002】

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

【0003】

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

【0004】

Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ指向能力の集合へのアクセスをアプリケーションおよびデバイスに提供し得る。いくつかの例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。これらの能力は、Ｍ２Ｍサービス層によって定義されるようなメッセージフォーマット、リソース構造、リソース表現、および関数呼び出しを利用するアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能にされる。例えば、Ｍ２Ｍサービス層は、それらのアクセス権に基づいてＭ２Ｍアプリケーションによって読み出されること、またはサブスクライブされることができる大量のＭ２Ｍデータを維持し得る。サブスクリプションベースのデータアクセスは、それが、サブスクライブされたリソースに対する所望の変化が起こるまでメッセージをＭ２Ｍアプリケーションに導入しないので、読み出しベースのデータアクセスよりも効率的であり得る。

【0005】

（ｏｎｅＭ２Ｍサービス層アーキテクチャ）
ｏｎｅＭ２Ｍは、種々のハードウェアおよびソフトウェア内に容易に組み込まれることができる共通Ｍ２Ｍサービス層の必要性に対処する技術的仕様を提供し、その技術的仕様は、フィールド内の多種多様なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために依拠されることができる。

【0006】

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

【0007】

図３は、ｏｎｅＭ２Ｍ機能的アーキテクチャ、すなわち、リソース指向アーキテクチャ（ＲＯＡ）を図示する。ＲＯＡアーキテクチャにおいて、リソースは、アーキテクチャ内の一意にアドレス可能な要素であり、要素は、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する。これらのリソースは、ユニフォームリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、同様に一意にアドレス可能であり得る子リソースと、属性とを含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの存続期間は、親リソースの存続期間によって限定される。各リソースは、リソースの情報を記憶する、「属性」の組をサポートする。

【0008】

ＣＳＥ（例えば、ＣＳＥ１０９）は、別のＣＳＥ（例えば、ＣＳＥ１１１）に登録することができる。例えば、Ｍ２Ｍゲートウェイ（例えば、ＭＮ−ＣＳＥ／ＣＳＥ１０９）は、それ自体をＭ２Ｍサーバ（例えば、ＩＮ−ＣＳＥ／ＣＳＥ１１１）に登録し、Ｍ２Ｍサーバは、Ｍ２ＭゲートウェイのレジストラＣＳＥになる。同様に、ＩＮ−ＡＥがＩＮ−ＣＳＥに登録するとき、ＩＮ−ＣＳＥは、ＩＮ−ＡＥのレジストラＣＳＥと称される。ＣＳＥ１１１は、登録されたＡＥ１０３またはＡＥ１１８のための＜ａｐｐｌｉｃａｔｉｏｎ＞リソースを作成し得る。

【0009】

図３では、アプリケーションエンティティ（ＡＥ）１０１およびＡＥ１１８またはＡＥ１１７およびＡＥ１０３は、異なるＭ２Ｍアプリケーションを指し、それぞれ、インフラストラクチャドメイン１０７またはフィールドドメイン１０５の中に常駐し得る。ｏｎｅＭ２Ｍ−ＴＳ−００１１−Ｄｅｆｉｎｉｔｉｏｎｓ ａｎｄ Ａｃｒｏｎｙｍｓ−Ｖ０．７．０によると、フィールドドメイン１０７が、「Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、感知および作動（Ｓ＆Ａ）機器、ならびにＭ２Ｍエリアネットワークから成る」一方、インフラストラクチャドメイン１０５は、「アプリケーションインフラストラクチャおよびＭ２Ｍサービスインフラストラクチャから成る」。ＡＥ１０１は、Ｍｃａインターフェース１０８を介して、ＣＳＥ１０９の中のＣＳＦにアクセスし、それを活用することができる。加えて、ＣＳＥ１０９は、一式のＣＳＦを提供し、ＣＳＥ１０９は、Ｍｃｃインターフェース１１０を介して別のＣＳＥ１１１と通信することができる。ＣＳＥ１０９は、Ｍｃｎインターフェース１１２を介して、下層ネットワークからネットワークサービスエンティティ（ＮＳＥ）１１３を活用することもできる。

【0010】

ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌａｌ Ａｒｃｈｎｉｔｅｃｔｕｒｅ Ｂａｓｅｌｉｎｅによると、ｏｎｅＭ２Ｍ参照点は、Ｍｃａ１０８、Ｍｃｃ１１０、Ｍｃｃ’１１４、およびＭｃｎ１１２を含む。Ｍｃａ参照点１０８（Ｍｃａインターフェースとしても公知である）は、ＡＥ（例えば、ＡＥ１０１）とＣＳＥ（例えば、ＣＳＥ１０９）との間の通信フローを指定する。Ｍｃａ参照点１０８は、ＡＥ１０１がＣＳＥ１０９によって提供されるサービスを使用することと、ＣＳＥ１０９がＡＥ１０１と通信することとを可能にする。Ｍｃｃ参照点１１０は、２つのＣＳＥ（例えば、ＣＳＥ１０９およびＣＳＥ１１１）の間の通信フローを指定する。Ｍｃｃ参照点１１０は、必要とされる機能性を提供するために、ＣＳＥ１０９がＣＳＥ１１１のサービスを使用することを可能にする。Ｍｃｃ参照点１１０を介して提供されるサービスは、ＣＳＥ１０９およびＣＳＥ１１１によってサポートされる機能性に依存する。

【0011】

Ｍｃｃ’参照点１１４は、ｏｎｅＭ２Ｍ対応であり、異なるＭ２Ｍ ＳＰドメイン内に常駐するインフラストラクチャノード内の２つのＣＳＥの間の通信フローを指定する。故に、これは、Ｍ２Ｍサービスプロバイダのネットワークドメイン内に常駐するインフラストラクチャノード１０５のＣＳＥ１１１が、別のＭ２Ｍサービスプロバイダ１１５のネットワークドメイン内に常駐する別のインフラストラクチャノード（図示せず）のＣＳＥと通信し、そのサービスを使用すること、および逆も同様に可能にする。Ｍｃｎ参照点１１２は、ＣＳＥ１０９と下層ＮＳＥ１１３との間の通信フローを指定する。Ｍｃｎ参照点１１２は、必要とされる機能性を提供するために、ＣＳＥ１０９が下層ＮＳＥ１１３によって提供されるサービス（トランスポートおよび接続性サービス以外）を使用することを可能にする。

【0012】

登録（ＲＥＧ）ＣＳＦ、アプリケーションおよびサービス層管理（ＡＳＭ）ＣＳＦ、デバイス管理（ＤＭ）ＣＳＦ、データ管理およびリポジトリ（ＤＭＲ）ＣＳＦ、通信およびメッセージ配信ハンドリング（ＣＭＤＨ）ＣＳＦ、サービス課金および会計（ＳＣＡ）ＣＳＦ等を含むいくつかのＣＳＦが、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌａｌ Ａｒｃｈｎｉｔｅｃｔｕｒｅ Ｂａｓｅｌｉｎｅで定義されている。例えば、ＣＳＥ（例えば、Ｍ２Ｍサーバ）は、ＣＳＥによって提供される他のＣＳＦを活用するために、ＡＥが最初にそれ自体をＣＳＥに登録することができるように、ＲＥＧ ＣＳＦを提供する。このアーキテクチャは、複数のＡＥが独立して同一のＣＳＥに登録することを可能にする。登録が成功した後、ＣＳＥは、各ＡＥのために別個のリソース（例えば、＜ａｐｐｌｉｃａｔｉｏｎ＞リソース）を作成する。従来のｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌａｌ Ａｒｃｈｎｉｔｅｃｔｕｒｅ Ｂａｓｅｌｉｎｅは、異なるアプリケーションの間の関係をサポートする機能を欠いている。

【0013】

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

【0014】

ＳＵＢ ＣＳＦは、アクセス制御ポリシ（ＡＣＰ）の対象である、リソースへのサブスクリプションを管理し、対応する通知を、リソースサブスクライバがそれらを受信することを欲するアドレスに送信する。ｏｎｅＭ２Ｍによると、ＡＣＰは、ｏｎｅＭ２Ｍ ＲＯＡアーキテクチャで規定されるように、リソースへのアクセスを制御するためにＣＳＥによって使用されるものとする。ＡＣＰは、アクセス制御リスト、役割ベースのアクセス制御、または属性ベースのアクセス制御等の異なるアクセス制御モデルに適合するように設計される。＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースは、種々のＡＣＰをサポートするように規定され、種々のＡＣＰは、ｐｒｉｖｉｌｅｇｅｓおよびｓｅｌｆＰｒｉｖｉｌｅｇｅｓ属性を含み、それらは、規定状況内である動作を行う特権を有するＭ２Ｍエンティティを定義するアクセス制御規則の組を表し、特定のリソースへのアクセス決定を行うことにおいてＣＳＥによって使用される。ＡＥまたはＣＳＥは、サブスクリプションリソースサブスクライバである。ＡＥおよびＣＳＥは、他のＣＳＥのリソースにサブスクライブする。サブスクリプションホスティングＣＳＥは、リソースに対する修正が行われると、通知をリソースサブスクライバによって規定されるアドレスに送信する。リソースサブスクリプションの範囲は、サブスクライブ先リソースの属性および直接の子リソースの変更および動作を追跡することを含む。それは、子リソースの属性の変更を追跡することを含まない。各サブスクリプションは、どの通知が、いつ、どのようにして送信されるかを規定する通知基準を含み得る。これらの通知基準は、ｏｎｅＭ２Ｍの通信管理および配信ハンドリング（ＣＭＤＨ）ポリシと共に機能し得る。

【0015】

サブスクリプションは、ＣＳＥリソース構造内でリソース＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞として表される。

【0016】

ＳＵＢ ＣＳＦによってサポートされる機能は、以下の通りである。
・リソースサブスクリプション要求ごとのリソースサブスクライバＩＤ、ホスティングＣＳＥ−ＩＤ、およびサブスクライブ先リソースアドレスの包含。それは、他の基準（例えば、着目リソース修正および通知ポリシ）、および通知を送信する場所のアドレスも含み得る。
・単一のサブスクリプションを介して単一のリソースにサブスクライブする能力、または、数のリソースがグループ化され、単一のグループリソースとして表される場合、単一のサブスクリプションを介して複数のリソースにサブスクライブする能力。サブスクライバがリソースのグループにサブスクリプションを行うとき、同一のイベント通知基準がグループ中の全てのリソースに使用され、次に、ホスティングＣＳＥは、（全てではないが）個々のリソースへの変更が生じる度に通知を生成し得る。

【0017】

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

【0018】

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

【発明の概要】

【発明が解決しようとする課題】

【0019】

Ｍ２Ｍ／ＩｏＴドメインでは、サブスクリプションは、サブスクライバがリソースにおける変更の自動通知を受信するための機構を提供する。従来のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）は、各要求プリミティブのための単一のリソースへのサブスクリプションをサポートする（単一リソースサブスクリプションと称される）。しかしながら、変更が複数の着目リソースに起こるときに通知を生成するためのサポート（クロスリソースサブスクリプションと称される）がない。単一の要求で複数のリソース（例えば、標的リソース）へのサブスクリプションをサポートすることが、より効率的であり得る。この問題に取り組むために、本開示は、クロスリソースサブスクリプションをサポートする機構を開示する。

【課題を解決するための手段】

【0020】

例では、サブスクライバが、複数のリソースへのサブスクリプションを要求するためのメッセージをリソースホストに発行する。リソースホストは、ローカルで維持されたこれら全てのリソースを有する。このメッセージは、これらのリソースの識別子、各個々のリソースのためのイベント通知基準を示し、時間ウィンドウタイプおよび時間ウィンドウサイズ等のクロスリソース通知基準を定義し得る。リソースホストは、標的リソースにおいて予期される変更が時間ウィンドウ内で起こるとき、クロスリソース通知をサブスクライバまたはその指定通知標的に発行する。

【0021】

別の例では、サブスクライバは、複数のリソース上のサブスクリプションを要求するためのメッセージを第１のリソースホストに発行し得る。第１のリソースホストは、これら全てのリソースを有していないこともあり、それらは、第２のリソースホスト、第３のリソースホスト等の中で維持され得る。第１のリソースホストは、各単一リソース（標的リソース）にサブスクライブするために、他のリソースホストにコンタクトし得る。第１のリソースホストは、他のリソースホストから別個の通知を受信し、クロスリソース通知を生成することができ、それをサブスクライバに送信する。提案されたクロスリソースサブスクリプションソリューションを実装するための新しいリソースおよび属性は、時間ウィンドウ機構を含む。

【0022】

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明は、例えば、以下を提供する。
（項目１）
クロスリソースサブスクリプションのための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
クロスリソースサブスクリプションのためのメッセージを受信することであって、前記メッセージは、遠隔デバイスによる、時間のウィンドウ内で基準を満たす複数の標的リソースの変更を通知されるためのサブスクリプションのための要求を示す、ことと、
前記遠隔デバイスが前記クロスリソースサブスクリプションのために承認されていることを決定することと、
ローカルサブスクリプションリソースを生成し、前記クロスリソースサブスクリプションを維持することと
を含む動作を前記プロセッサに達成させる、
装置。
（項目２）
前記メッセージは、前記複数の標的リソースのためのイベント通知基準のリストを備えている、項目１に記載の装置。
（項目３）
前記メッセージは、前記基準が満たされたときに通知が受信されることを期待されている前記標的リソースの数を備えている、項目１に記載の装置。
（項目４）
前記メッセージは、前記時間のウィンドウのタイプの指示を備えている、項目１に記載の装置。
（項目５）
前記メッセージは、前記時間のウィンドウのタイプの指示を備え、前記時間のウィンドウのタイプは、連続時間ウィンドウを備えている、項目１に記載の装置。
（項目６）
前記動作は、クロスリソースサブスクリプションの承認の指示を備えている応答メッセージを送信するための命令を提供することをさらに含む、項目１に記載の装置。
（項目７）
前記標的リソースのうちの少なくとも１つのリソースは、前記遠隔デバイス上に位置している、項目１に記載の装置。
（項目８）
前記動作は、前記複数の標的リソースのうちの第１のリソースへのサブスクリプションの要求を提供することをさらに含み、前記要求は、前記基準のうちのある基準を備えている、項目１に記載の装置。
（項目９）
前記動作は、
前記基準のうちの前記基準が満たされたという通知を受信することと、
前記通知を受信することに基づいて、前記基準が満たされていることを決定することと、
前記基準が満たされていることを決定することに基づいて、前記遠隔デバイスに通知することと
をさらに含む、項目８に記載の装置。
（項目１０）
前記装置は、共通サービスエンティティを備えている、項目１に記載の装置。
（項目１１）
クロスリソースサブスクリプションのための方法であって、前記方法は、
クロスリソースサブスクリプションのためのメッセージを受信することであって、前記メッセージは、遠隔デバイスによる、時間のウィンドウ内で基準を満たす複数の標的リソースの変更を通知されるためのサブスクリプションのための要求を示す、ことと、
前記遠隔デバイスが前記クロスリソースサブスクリプションのために承認されていることを決定することと、
ローカルサブスクリプションリソースを生成し、前記クロスリソースサブスクリプションを維持することと
を含む、方法。
（項目１２）
前記ローカルサブスクリプションリソースの情報の指示をディスプレイに公開することをさらに含む、項目１１に記載のシステム。
（項目１３）
クロスリソースサブスクリプションのための前記メッセージのパラメータをディスプレイに公開することをさらに含む、項目１１に記載の方法。
（項目１４）
前記時間のウィンドウのグラフィック表現内に基準を満たすイベントをディスプレイに公開することをさらに含む、項目１１に記載の方法。
（項目１５）
前記メッセージは、前記複数の標的リソースのためのイベント通知基準のリストを備えている、項目１１に記載の方法。
（項目１６）
前記メッセージは、前記基準が満たされたときに通知が受信されることを期待されている前記標的リソースの数を備えている、項目１１に記載の方法。
（項目１７）
前記メッセージは、前記時間のウィンドウのタイプの指示を備えている、項目１１に記載の方法。
（項目１８）
クロスリソースサブスクリプションの承認の指示を備えている応答メッセージを送信する命令を提供することをさらに含む、項目１１に記載の方法。
（項目１９）
前記標的リソースのうちの少なくとも１つのリソースは、前記遠隔デバイス上に位置している、項目１１に記載の方法。
（項目２０）
前記複数の標的リソースのうちの第１のリソースへのサブスクリプションの要求を提供することをさらに含み、前記要求は、前記基準のうちのある基準を備えている、項目１１に記載の方法。

【図面の簡単な説明】

【0023】

【図1】図１は、サービス層をサポートする例示的プロトコルスタックを図示する。

【図2】図２は、例示的共通サービスエンティティ（ＣＳＥ）および共通サービス機能（ＣＳＦ）を図示する。

【図3】図３は、例示的ｏｎｅＭ２Ｍサービス層機能的アーキテクチャ（ＲＯＡ）を図示する。

【図4】図４は、例示的ｏｎｅＭ２Ｍ一般サブスクリプションおよび通知プロシージャを図示する。

【図5】図５は、例示的スマートビルディングシナリオを図示する。

【図6】図６は、例示的ｏｎｅＭ２Ｍサブスクリプション機構を図示する。

【図7】図７は、例示的基本クロスリソースサブスクリプションを図示する。

【図8】図８は、例示的先進クロスリソースサブスクリプションを図示する。

【図9】図９は、例示的な既存のクロスリソースサブスクリプションの更新を図示する。

【図10】図１０は、例示的な既存のクロスリソースサブスクリプションの削除を図示する。

【図11】図１１は、周期的時間ウィンドウ機構がクロスリソース通知を生成するための例示的フローチャートを図示する。

【図12】図１２は、スライディング時間ウィンドウ機構がクロスリソース通知を生成するための例示的フローチャートを図示する。

【図13】図１３は、例示的時間ウィンドウ機構を図示する。

【図14】図１４は、ｏｎｅＭ２Ｍ ＲＯＡの中への例示的な新しい拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦを図示する。

【図15A】図１５Ａは、ｏｎｅＭ２Ｍにおける例示的クロスリソースサブスクリプションを図示する。

【図15B】図１５Ｂは、ｏｎｅＭ２Ｍにおける例示的クロスリソースサブスクリプションを図示する。

【図15C】図１５Ｃは、ｏｎｅＭ２Ｍにおける例示的クロスリソースサブスクリプションを図示する。

【図16】図１６は、サブスクリプションが関連リソースへの子である、例示的な従来のリソース構造を図示する。

【図17】図１７は、クロスリソースサブスクリプションおよび通知システムのための例示的リソース構造を図示する。

【図18】図１８は、サブスクライバ（例えば、ｏｎｅＭ２ＭＡＥ）のための例示的ユーザインターフェースを図示する。

【図19】図１９は、リソースホスト（例えば、ｏｎｅＭ２Ｍ ＣＳＥ）のための例示的ユーザインターフェースを図示する。

【図20A】図２０Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。

【図20B】図２０Ｂは、図２０Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。

【図20C】図２０Ｃは、図２０Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。

【図20D】図２０Ｄは、図２０Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

【発明を実施するための形態】

【0024】

従来のｏｎｅＭ２Ｍアーキテクチャでは、サブスクライバは、単一のリソースへのサブスクリプションのみを行い、そのリソースへの予期される変更が存在すると自動通知を受信することができる（本明細書では「単一リソースサブスクリプション」または「単一リソース通知」としても知られる）。本明細書では、サブスクライバが複数のリソースへのサブスクリプションを行い、通知条件が複数のリソース（本明細書では「標的リソース」と称される）への依存に基づく、クロスリソースサブスクリプションおよびクロスリソース通知（随時、同義的に使用される）が開示される。ｏｎｅＭ２Ｍで定義されるような標的リソースの例は、＜ｃｏｎｔａｉｎｅｒ＞リソースである。サブスクライバは、標的リソースに関連付けられる合致基準に基づいて通知を受信する。

【0025】

図５は、種々のタイプのセンサが、温度（例えば、温度センサ１４７）および煙（例えば、煙センサ１４８）等の建築物環境情報を監視するために展開される、スマートビルディングシナリオを図示する。センサからの読み取り値は、ローカルＭ２Ｍゲートウェイ１４４において記憶され得る。デスクトップコンピュータまたはスマートフォン上にあり得る、Ｍ２Ｍアプリケーション１４１は、必ずしも全ての個々のセンサ読み取り値に関心を持つわけではないが、「温度が２５℃よりも高く」かつ「煙が検出された」ときに自動通知を受信することを欲する。これは、本開示におけるクロスリソースサブスクリプションの例である。クロスリソースサブスクリプションは、自動通知が、単一のリソースだけではなく、２つ以上のリソースに依存するサブスクリプションと考えられ得る。換言すると、通知は、複数のリソースへの変更が起こるときに生成される。この例では、自動通知は、単一のリソースではなく、２つのリソース（例えば、各々が標的リソースである、温度読み取り値および煙読み取り値）に依存し、クロスリソース通知と称される。（図５には図示せず）別の例では、サブスクライバ（例えば、Ｍ２Ｍアプリケーション１４１）は、１）読み出し動作が第１のリソースに行われ、かつ、２）削除動作がほぼ同時に第２のリソースに行われるとき、通知を得るためにサブスクライブし得る。

【0026】

図５を参照して説明されるように、センサからの読み取り値は、リソースホストと称され得るローカルＭ２Ｍゲートウェイ１４４において記憶され得る。Ｍ２Ｍアプリケーション１４１は、サブスクライバとして、Ｍ２Ｍゲートウェイ１４４におけるリソースへのサブスクリプションを行う。ｏｎｅＭ２Ｍにおける既存のｏｎｅＭ２Ｍリソースサブスクリプション機構が、単一のリソース、または同じイベント通知基準（例えば、複数の温度センサが華氏９０度の温度を示した後に通知する）を伴うリソースのグループへのサブスクリプションのみをサポートするので、Ｍ２Ｍアプリケーション１４１は、従来、Ｍ２Ｍゲートウェイ１４４への２つの別個のサブスクリプションを行う必要がある（図６参照）。図６は、図５のユースケースを実装しようとし得る例示的な従来のｏｎｅＭ２Ｍサブスクリプション機構を図示する。ステップ１５１では、Ｍ２Ｍゲートウェイ１４４は、温度センサ読み取り値（例えば、「２５℃よりも高い温度」）に関するサブスクリプション要求を受信する。ステップ１５２では、Ｍ２Ｍゲートウェイ１４４は、煙センサ読み取り値（例えば、「煙が検出された」）に関する別のサブスクリプション要求を受信する。ステップ１５３では、Ｍ２Ｍゲートウェイ１４４は、温度センサ上で着目イベントが起こったことを決定し、ステップ１５４では、続いて、イベントに関する通知をＭ２Ｍアプリケーション１４１に送信する。ステップ１５５では、Ｍ２Ｍゲートウェイ１４４は、煙センサ上で着目イベントが起こったことを決定し、ステップ１５６では、続いて、イベントに関する通知をＭ２Ｍアプリケーション１４１に送信する。ステップ１５７では、Ｍ２Ｍアプリケーション１４１は、着目イベントが起こった（「温度が２５℃よりも高い」および「煙が検出された」）かどうかを決定するために、ステップ１５４の通知およびステップ１５６の通知を分析する。従来のｏｎｅＭ２Ｍシステムの使用は、Ｍ２Ｍアプリケーション１４１において余分な通知（例えば、ステップ１５４およびステップ１５６）ならびにオーバーヘッド（例えば、さらなる処理）を導入する。Ｍ２Ｍアプリケーション１４１は、温度センサまたは煙センサが変化を有する度に、Ｍ２Ｍゲートウェイから別個の通知を受信し、次いで、それ自身の知能に依拠して、予期されるイベントが起こったかどうかを決定する。従来のグループサブスクリプションに関して、ｏｎｅＭ２Ｍは、全てのグループメンバへの同一のイベント通知基準を伴うサブスクリプションのみをサポートし、したがって、このユースケースをサポートできないことを理解されたい。例えば、＜ｇｒｏｕｐ＞リソースは、２つのメンバ（例えば、温度センサおよび煙センサ）を伴って、Ｍ２Ｍゲートウェイ１４４において作成されることができるが、Ｍ２Ｍアプリケーションは、それが同一のタイプでなければならない（例えば、第１の温度センサおよび第２の温度センサが２５℃よりも高い）ので、本明細書で議論されるようなユースケース（例えば、「温度が２５℃よりも高く」かつ「煙が検出された」）を実現する＜ｇｒｏｕｐ＞／＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース（換言すると、グループのためのサブスクリプション機構）を作成することができない。従来、Ｍ２Ｍアプリケーション１４１は、各メンバリソースのために異なるイベント通知基準を示すことができず、クロスリソース通知が既存のｏｎｅＭ２Ｍグループサブスクリプションに基づいて生成されるであろう方法を示すことができない。

【0027】

以下は、従来のｏｎｅＭ２Ｍサブスクリプションに関する複数の問題の議論である。（本明細書で議論されるような）クロスリソースサブスクリプションおよび通知を実装する試行は、サブスクライバからリソースホストへの余分なサブスクリプション要求メッセージを導入し得る。試行は、リソースホストからサブスクライバへの余分な通知メッセージも導入し得る。従来のｏｎｅＭ２Ｍを使用するリソースホストは、クロスリソース通知を決定する能力を有していない。余分な処理およびオーバーヘッドが、サブスクライバにおいて必要とされる。換言すると、サブスクライバは、最初に、個々のサブスクリプション間の関係および依存関係についての論理を維持する必要がある。次いで、それは、真の着目イベントが起こっているかどうかを決定するために、各受信された個々の通知を分析する必要がある。最後に、個々の通知が伝送中に失われた場合、サブスクライバは、着目イベントがリソースホストの中で起こったことを把握することができないこともある。失われた伝送が再伝送される場合、再伝送されたメッセージは、本明細書で議論されるようなクロスリソースサブスクリプションおよび通知と比較して、有意により多くのメッセージを通信チャネルに追加し得る。

【0028】

クロスリソースサブスクリプションおよびクロスリソース通知に関して本明細書で開示されるサブスクライバは、複数のリソースにサブスクライブし得る。通知条件は、複数のリソース（標的リソースと称される）への依存に基づき、受信される通知は、標的リソース上の予期される変更に基づく。

【0029】

サブスクライバは、概して、通知標的であると仮定されるが、そうではない場合があることに留意されたい。サブスクライバが通知標的ではない場合、通知がリソースホストからサブスクライバの代わりに特定の通知標的に発行されるであろうことを除いて、本明細書の説明されるプロシージャは、類似するであろう。

【0030】

基本クロスリソースサブスクリプションのためのプロシージャが、以下で議論される。基本クロスリソースサブスクリプションに対して、サブスクライバは、複数の標的リソースへのサブスクリプションを要求するために、単一メッセージをリソースホストに発行する。リソースホストは、これらの標的リソースをローカルで維持する。リソースホストは、基準が時間ウィンドウ内で標的リソースのために満たされるとき、クロスリソース通知をサブスクライバ（または指定通知標的）に発行する。

【0031】

図７−図１２に図示されるステップを行うエンティティは、図２０Ｃまたは図２０Ｄに図示されるもの等のデバイス、サーバ、もしくはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る例示的論理エンティティであることが理解される。すなわち、図７−図１２に図示される方法は、図２０Ｃまたは図２０Ｄに図示されるデバイスまたはコンピューティングシステム等のコンピューティングデバイスのメモリの中に記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図７−図１２に図示されるステップを行う。例では、Ｍ２Ｍデバイスの相互作用に関する以下のさらなる詳細に関し、図３５のＡＥ７４１が、図２０ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図３５のＣＳＥ７３２およびＳｓｃｌ７４２は、図２０ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

【0032】

図７は、基本クロスリソースサブスクリプションのための例示的フローを図示する。Ｍ２Ｍエンティティ１６１は、リソースホスト（例えば、ｏｎｅＭ２Ｍ ＩＮ−ＣＳＥ）であり、Ｍ２Ｍエンティティ１６２は、サブスクライバ（例えば、ｏｎｅＭ２Ｍ ＩＮ−ＡＥ）である。ステップ１６４では、Ｍ２Ｍエンティティ１６２は、要求メッセージをＭ２Ｍエンティティ１６１に送信する。この要求メッセージは、Ｍ２Ｍエンティティ１６２が複数のリソース（例えば、標的リソース）の変更に関心を持ち、基準が満たされるときに単一の通知を受信することを期待することをＭ２Ｍエンティティ１６１に知らせるクロスリソースサブスクリプションのためのものである。以下のパラメータ、すなわち、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓ、ｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ、ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎ、ｔｉｍｅＷｉｎｄｏｗＴｙｐｅ、およびｔｉｍｅＷｉｎｄｏｗＳｉｚｅが、ステップ１６４のメッセージの中に含まれ得る。ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓは、Ｍ２Ｍエンティティ１６２が関心を持つ複数の標的リソース（例えば、標的リソースの識別子）のリストである。表１の中の例を参照されたい。ｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、標的リソースのためのイベント通知基準のリストである。１つのイベント通知基準が、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓの中の各リソースに適用される。各イベント通知基準は、ｏｎｅＭ２Ｍで定義されるようなｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａに類似する。全ての標的リソースが同一のイベント通知基準を有する場合、このパラメータは、全ての標的リソースに適用される１つだけのイベント通知基準を含む。ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎは、基準が満たされる（例えば、標的リソース上で変更が起こる）場合にＭ２Ｍエンティティ１６２が通知を受信することを期待する標的リソースの数である。デフォルトにより、このパラメータの値は、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓに含まれる標的リソースの数に等しい。この場合、通知は、標的リソース上で変更が起こり、基準を満たすとき、Ｍ２Ｍエンティティ１６１によって生成される。ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎの値は、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓに含まれる標的リソースの数よりも少なくあり得る。この場合、Ｍ２Ｍエンティティ１６２は、標的リソース上で変更が起こり、基準を満たすとき、通知を生成し得る。ｔｉｍｅＷｉｎｄｏｗＴｙｐｅは、Ｍ２Ｍエンティティ１６１がクロスリソース通知を決定するために使用し得る、時間ウィンドウのタイプ（例えば、周期的時間ウィンドウまたはスライディング時間ウィンドウ）を示す。ｔｉｍｅＷｉｎｄｏｗＳｉｚｅは、この時間ウィンドウ中に標的リソース上で変更が起こり、基準を満たすとき、通知をＭ２Ｍエンティティ１６２に送信するようにＭ２Ｍエンティティ１６１にアラートする時間ウィンドウ持続時間である。ｔｉｍｅＷｉｎｄｏｗＴｙｐｅおよびｔｉｍｅＷｉｎｄｏｗＳｉｚｅは、本明細書でさらに詳細に議論される。

【0033】

【表1】

ステップ１６４を継続して参照すると、Ｍ２Ｍエンティティ１６２がＭ２Ｍエンティティ１６１と個々のサブスクリプションを前もって確立している場合、Ｍ２Ｍエンティティ１６２は、クロスリソースサブスクリプションを要求するために、おいて前もって確立されたサブスクリプションのＵＲＩをステップ１６４において含み得ることが考えられる。加えて、ステップ１６４に関して上で説明されるｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓへのｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａのマッピングは、ｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａおよびｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓを（ｔａｒｇｅｔＲｅｓｏｕｒｃｅ，ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ）タプルのリストと置換する等の他のマッピングオプションを有する。さらに、別の例は、ｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａおよびｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓを、単一のイベント通知基準に割り当てられた標的リソースのリスト、例えば、（ｔａｒｇｅｔＲｅｓｏｕｒｃｅ１，ｔａｒｇｅｔＲｅｓｏｕｒｃｅ２，ｔａｒｇｅｔＲｅｓｏｕｒｃｅ３，ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ１）、（ｔａｒｇｅｔＲｅｓｏｕｒｃｅ４，ｔａｒｇｅｔＲｅｓｏｕｒｃｅ５，ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ２）等と置換することであり得る。

【0034】

ステップ１６５では、Ｍ２Ｍエンティティ１６１は、ステップ１６４のクロスリソースサブスクリプション要求メッセージを処理する。Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２が標的リソース（例えば、その全体としてｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓ）へのアクセス権を有していない場合、受信されたクロスリソースサブスクリプション要求メッセージを拒否し得る。要求が承認された場合、Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２のためのｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓ、ｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ、ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎ、およびｔｉｍｅＷｉｎｄｏｗの記録を作成し得る。換言すると、Ｍ２Ｍエンティティ１６１によって承認されるＭ２Ｍエンティティ１６２からの各クロスリソースサブスクリプション要求のために、Ｍ２Ｍエンティティ１６１は、この承認されたクロスリソース要求を維持するためにローカルサブスクリプションリソースを作成する。そのようなリソース構造についての詳細は、ｏｎｅＭ２Ｍとの関連において以降で議論される。

【0035】

ステップ１６６では、Ｍ２Ｍエンティティ１６１は、応答をＭ２Ｍエンティティ１６２に送信する。応答は、ステップ１６５で作成されるローカルサブスクリプションリソースのユニフォームリソース識別子（ＵＲＩ）、ならびにステップ１６４の要求メッセージの成功の指示を含み得る。ステップ１６７では、Ｍ２Ｍエンティティ１６１は、標的リソース上でイベントが生じることを観察する。ステップ１６８では、Ｍ２Ｍエンティティ１６１は、通知をＭ２Ｍエンティティ１６２に送信する必要があるかどうかを決定するために、時間ウィンドウアルゴリズムを行う。ステップ１６４に関して記述されるように、全てまたはいくつかの標的リソースへの変更（数がパラメータｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎによって規定される）がパラメータｔｉｍｅＷｉｎｄｏｗＳｉｚｅによる設計された時間ウィンドウ内で起こる場合、通知が生成されるであろう。リソースホストとしてのＭ２Ｍエンティティ１６１で実装される、そのような時間ウィンドウ機構は、クロスリソースサブスクリプションの知能を可能にし、それは、単一リソースサブスクリプションが使用された場合、そうでなければサブスクライバ（例えば、Ｍ２Ｍエンティティ１６２）に課され得る。

【0036】

図７のステップ１６８を継続して参照すると、基準が（ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅＦｏｒＮｏｔｉｆｉｃａｔｉｏｎによって表される）標的リソースの数で満たされる場合のみ、通知が生成され得ることが開示される。これは、論理および動作と考えられ得る。以下で議論されるような他のより先進的な動作も、Ｍ２Ｍエンティティ１６１によって適用され得る。この場合、Ｍ２Ｍエンティティ１６２は、ステップ１６４において動作タイプを要求し、Ｍ２Ｍエンティティ１６１に示し得る。Ｍ２Ｍエンティティ１６１は、任意の標的リソースが時間ウィンドウ内で予期される変更を有する（例えば、基準が満たされる）場合、クロスリソース通知を生成する。他の動作は、以下を含み得る：Ｍ２Ｍエンティティ１６１は、標的リソースのうちのいずれも時間ウィンドウ内で予期される変更を有していない場合、クロスリソース通知を生成する；Ｍ２Ｍエンティティ１６１は、いくつかの標的リソースが時間ウィンドウ内で予期される変更を有し、別のいくつかの標的リソースが同一の時間ウィンドウ内で予期される変更を有していない場合、クロスリソース通知を生成する；Ｍ２Ｍエンティティ１６１は、いくつかの標的リソースがいくつかの時間ウィンドウ内で予期される変更を連続的に有する場合、クロスリソース通知を生成する；Ｍ２Ｍエンティティ１６１は、いくつかの時間ウィンドウ内で予期される変更が連続的に存在しない場合、クロスリソース通知を生成する。別の例は、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓおよびｌｉｓｔＯｆＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａの両方が、２つの順序付けられたリストであることであり得る。よって、Ｍ２Ｍエンティティ１６１は、第１のｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎ標的リソースのためのイベント通知基準が満たされる場合、クロスリソース通知を生成するか、またはＭ２Ｍエンティティ１６１は、第１のある数のイベント通知基準が満たされる場合、クロスリソース通知を生成する。

【0037】

ステップ１６９では、Ｍ２Ｍエンティティ１６１は、ステップ１６８からの決定が「はい」であると仮定して、通知をＭ２Ｍエンティティ１６２およびｎｏｔｉｆｉｃａｔｉｏｎＵＲＩによって規定される他のエンティティに送信する。

【0038】

図８は、例示的進化型クロスリソースサブスクリプションを図示する。図８は、Ｍ２Ｍエンティティ１６２（例えば、ｏｎｅＭ２Ｍ ＩＮ−ＡＥ）が、依然としてＭ２Ｍエンティティ１６１（例えば、ｏｎｅＭ２Ｍ ＩＮ−ＣＳＥ）へのクロスリソースサブスクリプションを行うが、Ｍ２Ｍエンティティ１６１が、いかなる標的リソースもホストしないシナリオである。代わりに、各標的リソースは、異なるＭ２Ｍエンティティ（例えば、図８に示される例として、Ｍ２Ｍエンティティ１６３およびＭ２Ｍエンティティ１６０（例えば、ｏｎｅＭ２Ｍ ＭＮ−ＣＳＥ））の中でホストされる。図７のステップ１６４に類似するステップ１７１では、図８のＭ２Ｍエンティティ１６２は、クロスリソースサブスクリプション要求メッセージをＭ２Ｍエンティティ１６１に送信する。Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６３およびＭ２Ｍエンティティ１６０上にオリジナルリソースのアドレスを有し得るか、またはＭ２Ｍエンティティ１６２は、それらのアドレスを直接発見し、パラメータｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓを介してＭ２Ｍエンティティ１６１に知らせ得ることが考えられる。

【0039】

図８を継続して参照すると、ステップ１７２では、Ｍ２Ｍエンティティ１６１は、サブスクリプション要求を処理する。そして、それは、ステップ１７１で示される標的リソースがローカルでホストされていないことを見出す。結果として、それは、他のリソースホストにコンタクトする必要がある。ステップ１７１は、Ｍ２Ｍエンティティ１６３およびＭ２Ｍエンティティ１６０において維持される２つの標的リソースの要求を含むことが仮定される。Ｍ２Ｍエンティティ１６２（サブスクライバ）は、ｏｎｅＭ２Ｍで定義される既存のリソース発見プロシージャを使用して、Ｍ２Ｍエンティティ１６３またはＭ２Ｍエンティティ１６０において維持されるローカルリソースを発見し得る。このステップ１７１では、Ｍ２Ｍエンティティ１６１によって承認されるＭ２Ｍエンティティ１６２からの各クロスリソースサブスクリプション要求のために、Ｍ２Ｍエンティティ１６１は、承認されたクロスリソース要求を維持するためにローカルサブスクリプションリソースを作成し得る。そのようなリソース構造についての詳細は、ｏｎｅＭ２Ｍとの関連において本明細書でさらに詳細に議論される。

【0040】

ステップ１７３では、Ｍ２Ｍエンティティ１６１は、単一の標的リソースのために、単一リソースサブスクリプション要求（例えば、ｏｎｅＭ２Ｍで定義されるようなサブスクリプション要求）をＭ２Ｍエンティティ１６３に送信する。この標的リソースのためのイベント通知基準は、ステップ１７１に由来する。ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩは、Ｍ２Ｍエンティティ１６１であり得る。ステップ１７１では、Ｍ２Ｍエンティティ１６１は、このサブスクリプションがＭ２Ｍエンティティ１６２のクロスリソースサブスクリプションのためのものであることを示し得るか、またはＭ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２のクロスリソースサブスクリプションについてのいかなる情報も示さないこともある。クロスリソースサブスクリプションの指示がある場合、Ｍ２Ｍエンティティ１６１は、このメッセージの中にＭ２Ｍエンティティ１６２の識別子を含み得る。

【0041】

図８を継続して参照すると、ステップ１７４では、Ｍ２Ｍエンティティ１６３は、応答をＭ２Ｍエンティティ１６１に送信する。Ｍ２Ｍエンティティ１６２の識別子がステップ１７３に含まれる場合、Ｍ２Ｍエンティティ１６３は、Ｍ２Ｍエンティティ１６２に対して（またはＭ２Ｍエンティティ１６１とともに）承認を行い、承認結果に基づいて、成功または失敗応答のいずれかをＭ２Ｍエンティティ１６１に送信し得る。そうでなければ、Ｍ２Ｍエンティティ１６３は、Ｍ２Ｍエンティティ１６１に対して承認を行い、応答をそれに送信するのみであり得る。ステップ１７５では、Ｍ２Ｍエンティティ１６１は、単一の標的リソースのために、単一リソースサブスクリプション要求（例えば、ｏｎｅＭ２Ｍで定義されるようなサブスクリプション要求）をＭ２Ｍエンティティ１６０に送信する。この標的リソースのためのイベント通知基準は、ステップ１６１に由来する。ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩは、Ｍ２Ｍエンティティ１６１にリンクされ得る。ステップ１７１では、Ｍ２Ｍエンティティ１６１は、このサブスクリプションがＭ２Ｍエンティティ１６２のクロスリソースサブスクリプションのためのものであることを示し得るか、またはＭ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２のクロスリソースサブスクリプションについてのいかなる情報も示さないこともある。クロスリソースサブスクリプションの指示がある場合、Ｍ２Ｍエンティティ１６１は、このメッセージの中にＭ２Ｍエンティティ１６２の識別子を含み得る。

【0042】

ステップ１７６では、Ｍ２Ｍエンティティ１６０は、応答をＭ２Ｍエンティティ１６１に送信する。Ｍ２Ｍエンティティ１６２の識別子がステップ１７５に含まれる場合、Ｍ２Ｍエンティティ１６０は、Ｍ２Ｍエンティティ１６２に対して（またはＭ２Ｍエンティティ１６１とともに）承認を行い、承認結果に基づいて、成功または失敗応答のいずれかをＭ２Ｍエンティティ１６１に送信し得る。そうでなければ、Ｍ２Ｍエンティティ１６０は、Ｍ２Ｍエンティティ１６１に対して承認を行い、応答をそれに送信するのみであり得る。ステップ１７７では、Ｍ２Ｍエンティティ１６１は、成功または失敗であり得るステップ１７１の結果を示すために、応答をＭ２Ｍエンティティ１６２に送信する。ステップ１７８では、標的リソース上のイベントが、Ｍ２Ｍエンティティ１６３において起こる。ステップ１７９では、Ｍ２Ｍエンティティ１６３は、通知をＭ２Ｍエンティティ１６１に送信する。Ｍ２Ｍエンティティ１６１は、この通知をバッファリングし、ステップ１８２において等、以降の期間で追加の処理を行い得る。ステップ１８０では、標的リソース上のイベントが、Ｍ２Ｍエンティティ１６０において起こる。ステップ１８１では、Ｍ２Ｍエンティティ１６０は、通知をＭ２Ｍエンティティ１６１に送信する。Ｍ２Ｍエンティティ１６１は、ステップ１８２における以降の処理のために、この通知をバッファリングし得る。ステップ１７９およびステップ１８１の通知は、満たされた基準に合致する、ステップ１７８およびステップ１８０のイベントに応答することが仮定される。基準は、最初に、ステップ１７１においてＭ２Ｍエンティティ１６１に提供され、次いで、続いて、Ｍ２Ｍエンティティ１６０およびＭ２Ｍエンティティ１６３等のＭ２Ｍエンティティに別個に配布され得る。図７のステップ１６５に類似するステップ１８２では、図８のＭ２Ｍエンティティ１６１は、通知がＭ２Ｍエンティティ１６２に送信されるものであるかどうかを決定するために、時間ウィンドウ機構を実施する。ステップ１７９およびステップ１８１からの両方の通知が、ステップ１７１で規定されるような指定時間ウィンドウ中に受信された場合、Ｍ２Ｍエンティティ１６１は、通知を生成し、通知をＭ２Ｍエンティティ１６２に送信する（ステップ１８３）。時間ウィンドウ機構についての詳細は、本明細書で議論される。ステップ１８３では、Ｍ２Ｍエンティティ１６１は、通知をＭ２Ｍエンティティ１６２に送信する。ステップ１８３の通知メッセージは、ステップ１７８および１８０で起こったイベントを含み得る。または、ステップ１８３の通知メッセージは、用途依存性であるが、Ｍ２Ｍエンティティ１６１によって決定される事前構成された規則に基づいて、アクションをトリガする指示のみであり得る。例えば、Ｍ２Ｍエンティティ１６２は、水道を開くためのコマンドをセンサに送信し得る（またはコマンドを受信し得る）。ステップ１８３における通知は、火災イベントの検出に関連付けられ得る。

【0043】

図８に関するいくつかの追加の考慮事項が、以下で議論される。図８では、単一リソースサブスクリプション要求（例えば、ステップ１７３またはステップ１７５）が失敗する場合があり得る。この場合、Ｍ２Ｍエンティティ１６２からのクロスリソースサブスクリプションも失敗し、それは、ステップ１７７の応答メッセージの中に含まれ得る。ステップ１７３が最初に失敗する場合、Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６０にコンタクトしないこともあり、代わりに、失敗応答をＭ２Ｍエンティティ１６２に送信し得る。ステップ１７３が成功しているが、ステップ１７５が成功していない場合、Ｍ２Ｍエンティティ１６１は、（例えば、ステップ１７７において）失敗応答をＭ２Ｍエンティティ１６２に送信し得る。さらに、Ｍ２Ｍエンティティ１６３に関連付けられる、ステップ１７３および１７４において作成されるサブスクリプションは、非アクティブに（例えば、削除）され得る。ステップ１７３およびステップ１７５が両方とも成功しているが、Ｍ２Ｍエンティティ１６３（またはＭ２Ｍエンティティ１６０）における標的リソースが後に利用不可能になるか、または既存のサブスクリプションが無効になる場合、Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２のためのそのローカルで作成されたクロスリソースサブスクリプションを除去し、失敗応答を送信し得る。加えて、Ｍ２Ｍエンティティ１６１は、他のリソースホスト（例えば、Ｍ２Ｍエンティティ１６０）との既存の単一リソースサブスクリプションを非アクティブにし得る。

【0044】

図８を継続して参照すると、別の考慮事項は、ステップ１７２に関する。ステップ１７２では、Ｍ２Ｍエンティティ１６１は、任意の数の理由により、Ｍ２Ｍエンティティ１６２のクロスリソースサブスクリプション要求を拒否し得る。１つの理由は、要求が特定の閾値を上回って処理またはメモリを増加させるであろうことであり得る。別の理由は、特定のサービスの品質が満たされることができないことであり得る。概して、理由は、要求が特定の基準に適合しないことであり得、複雑すぎること、または特定の時間ウィンドウ内に適合することができない／適合する可能性が低いことを含み得る。結果として、ステップ１７３−ステップ１７６は、省略されることができる（およびステップ１７８−ステップ１８３は、起こらないであろう）。Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６２への失敗の通知を含む応答メッセージを送信するために、ステップ１７７を使用するのみであり得る。

【0045】

図９は、既存のクロスリソースサブスクリプションを更新するための例示的メッセージフローを図示する。既存のクロスリソースサブスクリプションは、オリジナルサブスクライバ（または他の適格なエンティティ）によって更新され得る。例えば、標的リソースが除去されること、または新しい標的リソースが追加されることができる。イベント通知基準または時間ウィンドウサイズも、変更されることができる。ステップ１９１では、オリジナルサブスクライバとしてのＭ２Ｍエンティティ１６２は、例えば、図７または図８のプロシージャに従って作成されている既存のクロスリソースサブスクリプションの属性を更新するために、クロスリソースサブスクリプションのための更新メッセージをＭ２Ｍエンティティ１６１に送信する。ステップ１９１の更新メッセージは、以下のパラメータを含み得る：ｓｕｂｓｃｒｉｐｔｉｏｎＩＤ、ｌｉｓｔｏｆＴａｒｇｅｔＲｅｓｏｕｒｃｅ、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ、ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎ、ｔｉｍｅＷｉｎｄｏｗＴｙｐｅ、またはｔｉｍｅＷｉｎｄｏｗＳｉｚｅ。ｓｕｂｓｃｒｉｐｔｉｏｎＩＤは、更新されるであろう既存のクロスリソースサブスクリプションのＵＲＩと考えられ得る。ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅは、全ての新しい標的リソースのリストと考えられ得る。ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅは、単純に、削除されるべき既存の標的リソースまたは付加されるべき新しい標的リソースを示し得る。ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、新しいイベント通知基準と考えられ得る。追加される任意の新しい標的リソースがある場合、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、これらの新しい標的リソースのための通知基準を示す。ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎは、通知を生成するための要求される標的リソースの新しい数と考えられ得る。ｔｉｍｅＷｉｎｄｏｗＴｙｐｅは、新しい時間ウィンドウタイプである。ｔｉｍｅＷｉｎｄｏｗＳｉｚｅは、通知を決定するための時間ウィンドウの新しいサイズと考えられ得る。

【0046】

ステップ１９２では、Ｍ２Ｍエンティティ１６１は、既存のクロスリソースサブスクリプションを見出し、ステップ１９１に含まれるパラメータに従って、その属性を更新するために、ｓｕｂｓｃｒｉｐｔｉｏｎＩＤを使用する。ｔｉｍｅＷｉｎｄｏｗＴｙｐまたはｔｉｍｅＷｉｎｄｏｗＳｉｚｅが変化するように要求される場合、Ｍ２Ｍエンティティ１６１は、既存のイベントを無視して現在の時間ウィンドウをリセットし、新しい時間ウィンドウを再開するであろう。ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎが変更される場合、Ｍ２Ｍエンティティ１６１は、現在の時間ウィンドウを保ち得るが、クロスリソース通知は、より早く（例えば、ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎが低減させられる）、またはより遅く（例えば、ｎｕｍＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓＦｏｒＮｏｔｉｆｉｃａｔｉｏｎが増加させられる）生成され得る。

【0047】

図９を継続して参照すると、ステップ１９３では、Ｍ２Ｍエンティティ１６１は、更新されたクロスリソースサブスクリプションに関与するいくつかの標的リソースが常駐する他のリソースホスト（例えば、Ｍ２Ｍエンティティ１６３）にコンタクトし得る。Ｍ２Ｍエンティティ１６２が、Ｍ２Ｍエンティティ１６３に常駐する標的リソース上のイベント通知基準を更新することを要求する場合、Ｍ２Ｍエンティティ１６１は、新しいイベント通知基準をＭ２Ｍエンティティ１６３に知らせることができる。Ｍ２Ｍエンティティ１６２がｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｃｅから標的リソースを除去することを要求し、標的リソースがＭ２Ｍエンティティ１６３に位置する場合、Ｍ２Ｍエンティティ１６１は、この標的リソースに関連付けられる前もって作成された単一リソースサブスクリプションを削除するために、Ｍ２Ｍエンティティ１６３にコンタクトするであろう。Ｍ２Ｍエンティティ１６２が新しい標的リソースをｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅに追加することを要求し、この標的リソースがＭ２Ｍエンティティ１６３に位置する場合、Ｍ２Ｍエンティティ１６１は、Ｍ２Ｍエンティティ１６３において新しい単一リソースサブスクリプションを作成するためにＭ２Ｍエンティティ１６３にコンタクトし得る。ステップ１９４では、Ｍ２Ｍエンティティ１６１は、とりわけ、成功または失敗を示す情報等のステップ１９２およびステップ１９３における更新動作結果について、応答をＭ２Ｍエンティティ１６２に送信する。

【0048】

図１０は、既存のクロスリソースサブスクリプションを更新するための例示的メッセージフローを図示する。既存のクロスリソースサブスクリプションは、オリジナルサブスクライバ（または他の適格エンティティ）によって削除されることができる。ステップ２０１では、Ｍ２Ｍエンティティ１６２（例えば、オリジナルサブスクライバ）は、例えば、図７または図８のプロシージャに従って作成されている既存のクロスリソースサブスクリプションを削除するためのメッセージをＭ２Ｍエンティティ１６１に送信する。ステップ２０１のこの削除メッセージは、削除されるであろう既存のクロスリソースサブスクリプションのＵＲＩであり得るｓｕｂｓｃｒｉｐｔｉｏｎＩＤを含み得る。ステップ２０２では、Ｍ２Ｍエンティティ１６１は、削除すべき既存のクロスリソースサブスクリプションを見出すために、ｓｕｂｓｃｒｉｐｔｉｏｎＩＤを使用する。ステップ２０３では、Ｍ２Ｍエンティティ１６１は、削除されるクロスリソースサブスクリプションに関連付けられる既存の単一リソースサブスクリプションを削除するために、削除されるクロスリソースサブスクリプションに関与するいくつかの標的リソースが常駐する他のリソースホスト（例えば、Ｍ２Ｍエンティティ１６３）にコンタクトし得る。ステップ２０４では、Ｍ２Ｍエンティティ１６１は、とりわけ、成功または失敗を示す情報等のステップ２０２およびステップ２０３における削除動作結果について、応答をＭ２Ｍエンティティ１６２に送信する。

【0049】

以下では、クロスリソース通知を送信すべきかどうかを決定することにおいて使用される時間ウィンドウ機構について議論される。各クロスリソースサブスクリプションにおいて、複数の標的リソースが関与し、各標的リソースのためのイベントが異なる時間に起こり得る。結果として、リソースホスト（例えば、Ｍ２Ｍエンティティ１６１）は、オリジナルサブスクライバによって示されるパラメータｔｉｍｅＷｉｎｄｏｗＳｉｚｅに従って、通知をオリジナルサブスクライバに発行する必要があるかどうかを決定し得る。時間ウィンドウ機構「周期的時間ウィンドウ」および「スライディング時間ウィンドウ」が、本明細書で議論される。周期的時間ウィンドウに関して、時間は、同一のサイズを伴う時間ウィンドウに分割される。各時間ウィンドウに対して、リソースホストは、基準がその時間ウィンドウ内で標的リソースについて満たされるときに通知を発行する。スライディング時間ウィンドウに関して、時間ウィンドウの開始時間は、クロスリソース通知が生成された後、または事前設定された時間ウィンドウが満了した後、毎回動的に変化する。リソースホストは、（例えば、標的リソースのための予期されるイベントが時間ウィンドウ内で起こる場合のみ）通知を発行するために同様の論理を使用する。

【0050】

ｔｉｍｅＷｉｎｄｏｗＳｉｚｅは、ゼロに設定されることができることに留意されたい。ゼロ値を伴うそのような時間ウィンドウを実装するために、指定イベント条件のうちの１つがトリガされるとき、リソースホストは、他のイベント通知基準も満たされているかどうかをチェックする必要がある。通知は、条件が実質的に同時に満たされる場合に送信される。例えば、｛“ｅｖｅｎｔ１：（ｔｅｍｐｅｒａｔｕｒｅ＞２５）”ＡＮＤ“ｅｖｅｎｔ２：（ｓｍｏｋｅＳｅｎｓｏｒ＝’Ｄｅｔｅｃｔｅｄ’）”｝が起こるときにサブスクライバが通知を欲する場合、サブスクライバは、２つのイベントが同時に起こっている必要があることを意味するようにゼロの時間ウィンドウを規定し得る。

【0051】

図１１は、周期的時間ウィンドウのための例示的方法を図示する。ステップ２１１では、リソースホスト（例えば、Ｍ２Ｍエンティティ１６１またはＭ２Ｍエンティティ１６０）は、時間ウィンドウ（ｔＷｉｎ）と、空であり得るイベントリスト（ｅＬｉｓｔ）とを作成する。ステップ２１２では、Ｍ２Ｍエンティティ１６１は、標的リソースの次のイベントまたは時間ウィンドウ（ｔＷｉｎ）の満了を待つ。ステップ２１３では、標的リソース上で新しいイベントが起こる場合、ステップ２１４に移行し、そうでなければ、時間ウィンドウが満了する場合、ステップ２１５に移行する。ステップ２１４では、Ｍ２Ｍエンティティ１６１は、このイベントをｅＬｉｓｔにバッファリングし得る。ステップ２１５では、Ｍ２Ｍエンティティ１６１は、ｅＬｉｓｔが標的リソースのための予期されるイベントを含んでいる（すなわち、基準を満たす）かどうかをチェックする。該当する場合、ステップ２１６に移行し、そうでなければ、ステップ２１７に進む。ステップ２１６では、Ｍ２Ｍエンティティ１６１は、通知を生成し、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩによって表される標的等の標的にそれを送信し得る。ステップ２１７では、Ｍ２Ｍエンティティ１６１は、時間ウィンドウ（ｔＷｉｎ）を除去し、全てのバッファリングされたイベントを除去することによってｅＬｉｓｔを空にする。ステップ２１８では、Ｍ２Ｍエンティティ１６１は、新しい時間ウィンドウを作成し、その開始時間を現在の時間として設定する。リソースホストは、通知を送信するために時間ウィンドウの終了まで待つ必要がないことを理解されたい。リソースホストは、基準が時間ウィンドウ内で満たされると通知を送信する。例えば、通知は、図１３のｔＷｉｎ２５２におけるｔ１４において送信され得る。

【0052】

図１２は、スライディング時間ウィンドウのための例示的方法を図示する。ステップ２２０では、リソースホスト（例えば、Ｍ２Ｍエンティティ１６１またはＭ２Ｍエンティティ１６３）は、標的リソースの次のイベントまたは開始された時間ウィンドウ（ｔＷｉｎ）の満了を待つ。ステップ２２０後、ステップ２２１では、標的リソースの新しいイベントが起こる場合、起こるリソース上のイベントに関するブロック２４４の開始であるステップ２２５に移行し、そうでなければ、時間ウィンドウが満了する場合、ステップ２２２に移行する。ステップ２２２は、時間ウィンドウ満了に関するステップのブロック２４１の開始である。

【0053】

ブロック２４１内で、ステップ２２２では、Ｍ２Ｍエンティティ１６１は、ｅＬｉｓｔの中に含まれるイベントの数をチェックする。２つ以上のイベントがある場合（はい）、ステップ２２３に移行し、そうでなければ（いいえ）、ステップ２３５に移行する。ステップ２２３では、Ｍ２Ｍエンティティ１６１は、バッファリングされたイベントリスト（例えば、ｅＬｉｓｔ）のリストの中の第２のイベントに従って、現在の時間ウィンドウをスライドさせる。換言すると、時間ウィンドウの開始時間は、第２のイベントの発生時間に更新されるであろう。ｅＬｉｓｔが１つだけのイベントを含む場合、リソースホストは、単純に、現在の時間ウィンドウを除去するのみであることに留意されたい。例えば、図１３では、「スライディング時間ウィンドウ」を指す、説明図２７０の中のｔＷｉｎ２７３は、時間ｔ４で起こる１つのみのイベント（イベントリソースタイプ２８１）を有する。時間ｔ５では、ｔＷｉｎ２７３が満了し、ｅＬｉｓｔおよび時間は、１つのイベントしかなかったのでリセットされるであろう。次いで、新しい時間ウィンドウ（例えば、ｔＷｉｎ２７４）が、新しいイベント（イベントリソースタイプ２８２）が起こるときに時間ｔ６で再開されるであろう。リセットは、全ての標的リソースが時間ウィンドウ内で基準に合致しない場合にも起こり得る。ステップ２２４７では、ｅＬｉｓｔの中の第１のイベントが、除去されるであろう。ここで、第２のイベントが、ｅＬｉｓｔの中の第１のイベントになる。次いで、ステップ２２０が、次のステップである。

【0054】

ステップ２２５では、Ｍ２Ｍエンティティ１６１は、すでに作成されている時間ウィンドウがあるかどうかをチェックする。該当する場合、ステップ２２６に移行し、そうでなければ、時間ウィンドウが存在する場合、ステップ２２８に移行する。ステップ２２６では、Ｍ２Ｍエンティティ１６１は、所定の基準に合致したイベントの指示を受信するおよその時間であり得る現在の時間として、その開始時間を設定する時間ウィンドウ（本明細書ではｔＷｉｎと称される）を作成する。ステップ２２７では、Ｍ２Ｍエンティティ１６１は、イベントリスト（ｅＬｉｓｔと称される）を作成し、このイベントを第１のイベントとしてそれに挿入する。ｅＬｉｓｔが作成された後、次いで、ステップ２２０が起こり得る。ステップ２２８では、すでに作成されているｅＬｉｓｔがある。リソースホストは、このイベントをｅＬｉｓｔの最後に付加する。ステップ２２９では、Ｍ２Ｍエンティティ１６１は、このイベントが標的リソースのための第１のイベントであるかどうかをチェックする。該当しない場合、ステップ２３０に移行し、そうでなければ、該当する場合、ステップ２３３に移行する。ステップ２３０では、同一の標的リソースのためのより古いイベントが、ｅＬｉｓｔから除去される。ステップ２３１では、リソースホストは、除去されたより古いイベントがｅＬｉｓｔの中の第１のイベントであったかどうかをチェックする。ステップ２３１が該当する場合、ステップ２３２に移行し、そうでなければ、ステップ２２０に進む。ステップ２３２では、Ｍ２Ｍエンティティ１６１は、更新されたｅＬｉｓｔに従って時間ウィンドウをスライドさせ得る。換言すると、時間ウィンドウの開始時間は、更新されたｅＬｉｓｔの中の第１のイベントの発生時間に設定される。ステップ２３３では、Ｍ２Ｍエンティティ１６１は、ｅＬｉｓｔが標的リソースのための予期されるイベントを含むかどうかをチェックする。該当する場合、ステップ２３４に移行し、そうでなければ、ステップ２２０に進む。ステップ２３４では、Ｍ２Ｍエンティティ１６１は、通知を生成し、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩによって表されるような通知標的にそれを送信する。ステップ２３５では、Ｍ２Ｍエンティティ１６１は、時間ウィンドウおよびｅＬｉｓｔを除去し、次いで、ステップ２２０に進む。

【0055】

図１３は、周期的時間ウィンドウおよびスライディング時間ウィンドウのための例を図示する。この例では、２つの標的リソース、すなわち、イベントリソースタイプ２８１およびイベントリソースタイプ２８２があることが仮定される。示されるイベントリソースタイプは、少なくとも１つの基準が時間段階（例えば、ｔ１１、ｔ１２、ｔ１３、ｔ１４、ｔ１５）において１つの標的リソースのために満たされていることを示す。周期的時間ウィンドウは、新しい時間ウィンドウの開始時間が、通常、固定された時間段階または時限において出現する時間ウィンドウ機構である。図１３に示されるように、説明図２５０（周期的時間ウィンドウ）に対して、３つの連続時間ウィンドウ（例えば、ｔＷｉｎ２５１、ｔＷｉｎ２５２、およびｔＷｉｎ２５３）が作成されるが、ｔＷｉｎ２５２およびｔＷｉｎ２５３のみが、両方のリソースのイベントを含む。結果として、ｔＷｉｎ２５１における通知はないが、通知は、ｔＷｉｎ２５２およびｔＷｉｎ２５３のために生成されるであろう。換言すると、ｔＷｉｎ２５１が、標的リソースのための基準を満たさないことに基づいてトリガされる通知を伴わない時間ウィンドウである一方、ｔＷｉｎ２５２およびｔＷｉｎ２５３は、標的リソースのための基準を満たすことに基づいてトリガされる通知を有する時間ウィンドウである。図１３に示されるように、説明図２７０（スライディング時間ウィンドウ）に関して、４つの時間ウィンドウ（例えば、ｔＷｉｎ２７１、ｔＷｉｎ２７２、ｔＷｉｎ２７３、およびｔＷｉｎ２７４）が生成される。各時間ウィンドウは、実際には、標的リソースのための基準に合致するイベントの発生によって時間段階（例えば、ｔ１、ｔ２、ｔ３、ｔ４、ｔ６、ｔ７）において開始されることに留意されたい。説明図２７０は、ｔＷｉｎ２７２およびｔＷｉｎ２７４が標的リソースの各々の所定の基準を満たすイベントを含み、通知を生成するであろうことを示す。図１３では、イベントリソースタイプ２８１およびイベントリソースタイプ２８２のみが通知をトリガするために必要とされる標的リソースであることが、ここで仮定される。

【0056】

以下は、ｏｎｅＭ２Ｍアーキテクチャでクロスリソースサブスクリプションを実装するための例である。以下では、高レベルアーキテクチャオプション、新しいリソースおよび属性、ならびに対応するコールフローについて議論される。ユーザインターフェースも、クロスリソースサブスクリプション関連パラメータおよび情報の例示的表示または構成に関して議論される。

【0057】

ｏｎｅＭ２Ｍに関して、リソースホスト（例えば、Ｍ２Ｍエンティティ１６１）に関連するプロシージャおよびプロセスは、ＣＳＥ（例えば、図２０ＡのＭ２Ｍサービス層２２）で実装され得る。そして、プロシージャおよびプロセスは、ＡＥ（またはサブスクライバである場合はＣＳＥ）の中のサブスクライバ（例えば、図８のＭ２Ｍエンティティ１６２）に関連する。

【0058】

図１４は、ｏｎｅＭ２Ｍに基づく拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦ２９２を形成するために、既存のＳＵＢ ＣＳＦに対してクロスリソースサブスクリプションまたは通知に関して開示されるものを実装するための例を図示する。この新しいｅＳＵＢ２９２は、本明細書に説明されるようなリソースホストに関連するプロシージャおよびプロセスをサポートする。ｅＳＵＢ２９２は、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＡＳＮ−ＣＳＥの中に常駐し得る。

【0059】

図１５は、ｏｎｅＭ２Ｍにおけるクロスリソースサブスクリプションの３つの例示的展開を図示する。図１５Ａは、リソースホストがｅＳＵＢを伴うホスティングＣＳＥである一方、ＡＥ（例えば、ＩＮ−ＡＥ、ＭＮ−ＡＥ、ＡＳＮ−ＡＥ、またはＡＤＮ−ＡＥ）としてサブスクライバを伴う例を図示する。本明細書で議論されるプロシージャは、ホスティングＣＳＥ２９４（リソースホスト）とＡＥ２９６（サブスクライバ）との間のＭｃａ参照点２９５に適用される。提案される新しいリソース＜ｘＲｓｒｃＳｕｂ＞は、ｅＳｕｂを伴うホスティングＣＳＥ（例えば、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＡＳＮ−ＣＳＥ）の中に常駐するであろう。図１５Ｂは、リソースホストがｅＳＵＢを伴うホスティングＣＳＥ２９７である一方、ＣＳＥ２９９（例えば、ＭＮ−ＣＳＥ、ＩＮ−ＣＳＥ）としてサブスクライバを伴う例を図示する。本明細書で議論されるプロシージャは、ホスティングＣＳＥ２９７とサブスクライバであるＣＳＥ２９９との間のＭｃｃ／Ｍｃｃ’参照点２９８に適用される。開示される新しいリソース＜ｘＲｓｒｃＳｕｂ＞は、ｅＳｕｂを伴うホスティングＣＳＥ（例えば、ＩＮ−ＣＳＥ）の中に常駐するであろう。図１５Ｃは、その標的リソースが３つのＣＳＥ（例えば、ｅＳＵＢを伴うホスティングＣＳＥ３０３、ＭＮ−ＣＳＥ３０５、およびＭＮ−ＣＳＥ３０７）の中で分配されている一方、ＡＥ（例えば、ＩＮ−ＡＥ）としてサブスクライバを伴う例を図示する。本明細書で議論されるプロシージャは、ｅＳＵＢを伴うホスティングＣＳＥとサブスクライバＡＥ３０１との間のＭｃａ参照点３０２に適用される。この場合、ＭＮ−ＣＳＥ３０５およびＭＮ−ＣＳＥ３０７は、ｅＳＵＢをサポートしないが、ｏｎｅＭ２Ｍにおける既存のＳＵＢ機能性のみを有する。開示される新しいリソース＜ｘＲｓｒｃＳｕｂ＞は、ｅＳｕｂを伴うホスティングＣＳＥ３０３（例えば、ＩＮ−ＣＳＥ）の中に常駐するであろう。

【0060】

図７−図１０に関するプロシージャをサポートするために、新しいサブスクリプションリソース（＜ｘＲｓｒｃＳｕｂ＞と称される）が、例えば、ｏｎｅＭ２Ｍのために本明細書で議論される。＜ｘＲｓｒｃＳｕｂ＞は、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａおよび表１に示されるようないくつかの新しい属性を除いて、既存のリソース＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞の全ての子リソースおよび属性（例えば、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）を有し得る。表１は、新しい属性の例である。標的リソースが専用の属性ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓによって表されるので、＜ｘＲｓｒｃＳｕｂ＞が＜ｓｃｌＢａｓｅ＞リソースツリーの下に作成される場場合、問題にならないであろう。図１７は、本明細書で議論されるようなクロスリソースサブスクリプションおよび通知システムの効果の例を図示する。種々の場所（例えば、＜ＡＥ＞の子リソース、＜ＣＳＥ＞の子リソース、＜ＣＳＥＢａｓｅ＞の子リソース、または＜ｇｒｏｕｐ＞の子リソース）に設置されることができ、それは、基本的に、＜ｘＲｓｒｃＳｕｂ＞は、ｏｎｅＭ２Ｍアーキテクチャにおける従来の＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースと異なる。図１６は、従来のリソース構造の例を図示し、サブスクリプションは、関連リソースに対する子である。

【0061】

【表1-1】

＜ｘＲｓｒｃＳｕｂ＞リソースプロシージャは、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓによって表される複数の標的リソースの修正のために通知されるべき新しい＜ｘＲｓｒｃＳｕｂ＞リソースの作成を要求するために、使用され得る。一般的な作成プロシージャは、ｏｎｅＭ２Ｍ（ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ，Ｖ−２．３．０、以降では［１］）の中の第１０．１．１．１節で説明される。表２は、例示的＜ｘＲｓｒｃＳｕｂ＞ＣＲＥＡＴＥを図示する。

【0062】

【表2】

プロシージャは、＜ｘＲｓｒｃＳｕｂ＞リソースの属性および子リソース情報を読み出すために使用され得る。一般的な読み出しプロシージャは、［１］の中の第１０．１．２節で説明される。表３は、例示的＜ｘＲｓｒｃＳｕｂ＞ＲＥＴＲＩＥＶＥである。

【0063】

【表3】

プロシージャが、既存のクロスリソースサブスクリプション（例えば、＜ｘＲｓｒｃＳｕｂ＞リソース）、例えば、ｌｉｓｔＯｆＴａｒｇｅｔＲｅｓｏｕｒｃｅｓ等のその属性の修正を更新するために使用され得る。一般的な更新プロシージャは、［１］の中の第１０．１．３節で説明される。表４は、例示的＜ｘＲｓｒｃＳｕｂ＞ＵＰＤＡＴＥである。

【0064】

【表4】

プロシージャが、既存のクロスリソースサブスクリプション（すなわち、＜ｘＲｓｒｃＳｕｂ＞リソース）をサブスクライブ解除するために使用され得る。一般的な削除プロシージャは、［１］の中の第１０．１．４．１節で説明される。表５は、＜ｘＲｓｒｃＳｕｂ＞ＤＥＬＥＴＥの例である。

【0065】

【表5】

ホスティングＣＳＥが＜ｘＲｓｒｃＳｕｂ＞ｃｒｅａｔｉｏｎ（または＜ｘＲｓｒｃＳｕｂ＞ｕｐｄａｔｅ）を受信した後、通知が発行される必要があるかどうかを決定するために、それは、本明細書に説明されるような時間ウィンドウ機構を実施する。標的リソース上の予期される変更が時間ウィンドウ内で起こるときのみ、ホスティングＣＳＥが通知を発信側またはその指定通知受信側に発行する。

【0066】

ｏｎｅＭ２Ｍにおける従来の＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースは、例えば、表６に説明されるようないくつかの新しい属性を追加することによって、開示されるクロスリソースサブスクリプションをサポートするように拡張され得る。換言すると、これらの新しい属性を使用することによって、サブスクライバ（例えば、作成側または＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞）は、クロスリソースサブスクリプションをトリガし得るか、またはそれを可能にし得る。例では、ＩＮ−ＣＳＥが、２つのメンバ＜ｃｏｎｔａｉｎｅｒ１＞および＜ｃｏｎｔａｉｎｅｒ２＞を有する＜ｇｒｏｕｐ＞リソース（例えば、＜ｉｎＣＳＥＢａｓｅ＞／＜ｇｒｏｕｐ＞）を有することを仮定されたい。ＩＮ−ＡＥが、両方のコンテナリソースの値が閾値を超えるときに自動通知を受信することを欲する場合、この＜ｇｒｏｕｐ＞リソースの子リソースとして＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を作成し、以下のＣＲＥＡＴＥコマンドを使用して、新しい属性のための適切な値を設定し得る。次いで、ＩＮ−ＣＳＥは、両方のコンテナリソースの値がｔｉｍｅＷｉｎｄｏｗＳｉｚｅ（例えば、６０秒）内で閾値を超えるように変更される場合に通知を発行する。例示的ＣＲＥＡＴＥコマンド：ＣＲＥＡＴＥ＜ｉｎＣＳＥＢａｓｅ＞／＜ｇｒｏｕｐ＞／＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞；ｐａｙｌｏａｄ：ｓｕｂＴｙｐｅ＝１（クロスリソースサブスクリプション）、ｔｉｍｅＷｉｎｄｏｗＴｙｐｅ＝１（例えば、周期的時間ウィンドウ）、ｔｉｍｅＷｉｎｄｏｗＳｉｚｅ＝６０秒である。

【0067】

【表6-1】

【0068】

【表6-2】

＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースへの提案される新しい属性を用いて、ｏｎｅＭ２Ｍにおいて＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を作成するためのプロシージャが更新され得る。しかし、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を読み出し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を更新し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を削除するためのプロシージャは、ｏｎｅＭ２Ｍ［１］の中の既存のものと同一であり得る。

【0069】

（＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を作成する）
このプロシージャは、複数の標的リソースにわたる修正のために通知される新しい＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの作成を要求するために、使用されるものとする。一般的な作成プロシージャは、［１］の中の第１０．１．１．１節で説明される。

【0070】

【表7】

ホスティングＣＳＥが＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞ｃｒｅａｔｉｏｎを受信した後、通知が発行される必要があるかどうかを決定するために、本明細書に説明されるような時間ウィンドウ機構を実施する。標的リソース上の予期される変更が時間ウィンドウ内で起こるときのみ、ホスティングＣＳＥが通知を発信側またはその指定通知受信側に発行する。

【0071】

ユーザインターフェースは、標的リソースのリスト、イベント通知基準のリスト、および時間ウィンドウサイズ等のクロスリソースサブスクリプションのパラメータを構成または表示するために、サブスクライバ（例えば、ＡＥ）と相互作用し得る（図１８参照）。図１９は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。図１９を参照すると、リソースホストに関して、ユーザインターフェース３２１は、ブロック３２２のクロスリソースサブスクリプションパラメータに加えて、（例えば、ほぼリアルタイムで）標的リソース情報３２３の発生イベントを表示し得る。ディスプレイインターフェース３２１（例えば、タッチスクリーンディスプレイ）は、表１から表７のパラメータ等のクロスリソースサブスクリプションに関連付けられる他のテキストをブロック３２２の中で提供し得る。別の例では、本明細書で議論されるステップのうちのいずれかの進捗度（例えば、送信されたメッセージまたは図７−図１２のステップの成功）が、ディスプレイ３２１によって表示され得る。加えて、グラフィカル出力３２４が、ディスプレイインターフェース３２４上に表示され得る。グラフィカル出力３２４は、デバイスのトポロジ、本明細書で議論される任意の方法もしくはシステムの進捗度のグラフィカル出力等であり得る。

【0072】

図２０Ａは、クロスリソースサブスクリプションに関連付けられる１つ以上の開示される概念が実装され得る（例えば、図７−図１９および付随する議論）、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

【0073】

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

【0074】

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

【0075】

図２０Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２（例えば、本明細書に説明されるようなホスティングＣＳＥ２９４）は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

【0076】

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

【0077】

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

【0078】

いくつかの例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に議論されるようなクロスリソースサブスクリプションに関連付けられる方法を使用して通信する、所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

【0079】

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

【0080】

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

【0081】

図２０Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図２０Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、Ｍ２Ｍエンティティ１６１、Ｍ２Ｍエンティティ１６０、Ｍ２Ｍエンティティ１６３、Ｍ２Ｍエンティティ１６２、ホスティングＣＳＥ２９４、ＡＥ２９６、ＭＮ−ＣＳＥ３０５、およびその他）は、クロスリソースサブスクリプションのための開示されるシステムおよび方法を行う、例示的実装であり得る。

【0082】

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る送受信機３４に結合され得る。図２０Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップの中に一緒に統合され得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）または無線アクセス層（ＲＡＮ）プログラムもしくは通信を実施し得る。プロセッサ３２は、例えば、アクセス層またはアプリケーション層等で、認証、セキュリティキー一致、もしくは暗号化動作等のセキュリティ動作を実施し得る。

【0083】

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

【0084】

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

【0085】

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

【0086】

プロセッサ３２は、非取り外し可能メモリ４４または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、本明細書に説明される例のうちのいくつかでは、クロスリソースサブスクリプションが成功または不成功であるかどうか（例えば、サブスクリプション設定、受信される通知、更新された時間ウィンドウ等）に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色を制御する、または別様にクロスリソースサブスクリプションおよび関連付けられるコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、もしくは色は、本明細書に図示または議論される図（例えば、図７−図１９等）の方法フローもしくはコンポーネントのうちのいずれかのステータスを反映し得る。本明細書では、クロスリソースサブスクリプションのメッセージおよびプロシージャが開示される。メッセージおよびプロシージャは、ユーザが入力ソース（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して関連リソースを要求し、ディスプレイ４２上に表示され得るものの中でも、リソースのクロスリソースサブスクリプション情報を要求する、構成する、またはクエリを行うためのインターフェース／ＡＰＩを提供するように拡張されることができる。

【0087】

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

【0088】

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

【0089】

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

【0090】

伝送／受信要素３６は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。

【0091】

図２０Ｄは、例えば、図２０Ａおよび図２０ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４）は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意のプロセッサである。ＣＰＵ９１またはコプロセッサ８１は、複数の標的リソースに関連付けられる１つ以上の基準を満たすことに基づいて通知を生成すること等のクロスリソースサブスクリプションのための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

さらに、コンピューティングシステム９０は、図２０Ａおよび図２０Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

【0097】

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施もしくは実装することが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。本明細書の説明から明白であるように、記憶媒体は、合衆国法典第３５編第１０１条（３５ Ｕ．Ｓ．Ｃ．§１０１）の下の法定主題であると解釈されるべきである。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる、任意の他の物理媒体を含む。

【0098】

図に例証されるように、本開示の主題の好ましい方法、システム、または装置、すなわち、クロスリソースサブスクリプションのためのシステムおよび方法を説明することにおいて、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各特定の要素は、類似目的を達成するように同様に動作する全ての技術的均等物を含むことを理解されたい。

【0099】

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。本装置は、本明細書に説明される方法を達成するように、単独で、または相互と組み合わせて動作し得る。本明細書で使用されるように、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」等という用語は、同義的に使用され得る。加えて、「または」という言葉の使用は、概して、本明細書で別様に提供されない限り、包含的に使用される。

【0100】

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

【0101】

とりわけ、本明細書に説明されるような方法、システム、および装置は、クロスリソースサブスクリプションのための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、クロスリソースサブスクリプションのためのメッセージを受信する手段であって、メッセージは、遠隔デバイスによる、サブスクリプションが時間のウィンドウ内で基準を満たす複数の標的リソースの変更を通知されるための要求を示す、手段と、遠隔デバイスがクロスリソースサブスクリプションのために承認されていることを決定する手段と、ローカルサブスクリプションリソースを生成し、クロスリソースサブスクリプションを維持する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、クロスリソースサブスクリプションの承認の指示を備えている応答メッセージを送信する手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、複数の標的リソースのうちの第１のリソースへのサブスクリプションを要求する手段を備え、要求は、基準のうちのある基準を備えている。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、基準のうちの基準が満たされたという通知を受信する手段と、通知を受信することに基づいて、基準が満たされていることを決定する手段と、基準が満たされていることを決定することに基づいて、遠隔デバイスに通知する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、ローカルサブスクリプションリソースの情報の指示をディスプレイに公開する手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、クロスリソースサブスクリプションのためのメッセージのパラメータをディスプレイに公開する手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、時間のウィンドウのグラフィック表現内に基準を満たすイベントをディスプレイに公開する手段を有する。装置は、共通サービスエンティティを含み得る。標的リソースのうちのリソースは、遠隔デバイス上に位置し得る。メッセージは、時間のウィンドウのタイプの指示を含み得、時間のウィンドウのタイプは、連続時間ウィンドウを備えている。メッセージは、時間のウィンドウのタイプの指示を含み得る。メッセージは、基準が満たされたときに通知が受信されることを期待されている標的リソースの数を含み得る。メッセージは、複数の標的リソースのためのイベント通知基準のリストを含み得る。本段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で考慮される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15A】

【図15B】

【図15C】

【図16】

【図17】

【図18】

【図19】

【図20A】

【図20B】

【図20C】

【図20D】