JP6741853B2 - サブスクリプションおよび通知サービス - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／３６２，２６６号（２０１６年７月１４日出願、名称「ＳＵＢＳＣＲＩＰＴＩＯＮ ＡＮＤ ＮＯＴＩＦＩＣＡＴＩＯＮ ＳＥＲＶＩＣＥ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

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

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

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

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

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

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

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

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

ＳＵＢ ＣＳＦは、アクセス制御ポリシ（ＡＣＰ）の対象である、リソースへのサブスクリプションを管理し、対応する通知を、リソースサブスクライバがそれらを受信することを欲するアドレスに送信する。ＡＥまたはＣＳＥは、サブスクリプションリソースサブスクライバである。ＡＥおよびＣＳＥは、他のＣＳＥのリソースにサブスクライブする。サブスクリプションホスティングＣＳＥは、リソースへの修正が行われるとき、通知をリソースサブスクライバによって規定されるアドレス（または通知標的）に送信する。リソースサブスクリプションの範囲は、サブスクライブ先リソースの属性および直接子リソースの変更および動作を追跡することを含む。それは、子リソースの属性の変更を追跡することを含まない。各サブスクリプションは、通知が送信される種類、時間、および方法を規定する通知基準を含み得る。これらの通知基準は、ｏｎｅＭ２Ｍの通信管理および配信ハンドリング（ＣＭＤＨ）ポリシと併せて稼働し得る。サブスクリプションは、ＣＳＥリソース構造においてリソース＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞として表される。

要約すると、ＳＵＢ ＣＳＦによってサポートされる機能は、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅでは以下の通りである：１）ＩＤの包含、２）リソースにサブスクライブする能力、３）通知を送信するためのサブスクライバ要求、４）見逃した通知をキャッシュするための要求、５）通知を受信することに対する率制限要求、または、５）通知標的がＣＳＥから除去されること。

より詳細には、リソースサブスクライバＩＤ、ホスティングＣＳＥ−ＩＤ、およびサブスクライブ先リソースアドレスの包含は、リソースサブスクリプション要求ごとに行われ得る。それは、他の基準（例えば、着目リソース修正および通知ポリシ）、および通知を送信すべき場所のアドレスも含み得る。

単一のサブスクリプションを介して単一のリソースにサブスクライブする能力、または、それらがグループ化され、単一のグループリソースとして表されている場合に単一のサブスクリプションを介して複数のリソースにサブスクライブする能力がある。サブスクライバがリソースのグループにサブスクリプションを行うとき、同じイベント通知基準が、グループの中の全てのリソースに使用され、次に、ホスティングＣＳＥは、（全てではないが）個々のリソースへの変更が行われる度に通知を生成し得る。

サブスクライバは、一度に１つの代わりにバッチで通知メッセージを送信することをホスティングＣＳＥに要求することができる。サブスクライバは、一緒にバッチ処理されるべき通知メッセージの数を示すことができる。

サブスクライバは、（例えば、サブスクライバへの）利用可能でない接続性の期間に起因する見逃した通知をキャッシュすることをホスティングＣＳＥに要求することができる。接続性が利用可能になった後、ホスティングＣＳＥは、最新の保留通知または全ての保留通知をサブスクライバに送信することができる。サブスクライバは、それが通知を受信する率制限を示すことができる。そして、通知標的は、通知を受信することに対して、標的のリストからそれを除去することをホスティングＣＳＥに要求することができる。

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

Ｍ２Ｍ／ＩｏＴドメインでは、リソースサブスクリプションは、変更がサブスクライブされたリソース上で生じるときに自動通知を受信するための機構を提供する。従来のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）は、サブスクリプション通知をノードのリスト（例えば、通知標的）に送信することをサポートする。サブスクライブするエンティティは、通知標的として含まれることも、含まれないこともある。従来のＭ２Ｍサービス層は、過去の通知についての情報へのアクセスを含まず、それは、サブスクライバが通知標的の一員でないとき、問題であり得る。別の問題は、サービス層が、通知標的についての状況情報を認識していないことであり得る。前述の問題に基づいて、不必要な通知を利用不可能なまたはオーバーロードされた通知標的に送信すること等の非効率性が存在し得る。

本明細書では、サブスクリプションおよび通知サービスのための方法ならびにシステムが開示される。例えば、開示される主題は、通知標的ステータスに基づいて通知挙動の動的変化を可能にし、とりわけ、見逃したもしくは不必要な通知の数を削減し得るか、または異なる粒度で通知履歴情報へのアクセスをサポートし得る。

第１の例示的方法では、サービス層は、能動的に、またはサブスクライバの要求に応答して、新しい通知リソースを作成することによって、発行通知を記録する。サブスクライバおよび通知標的は、作成された通知リソースにアクセスし、過去の通知についての情報を取得し得る。サブスクライバは、通知記録を停止または変更する自由も有する。第２の例示的方法では、サービス層は、発行された通知の統計情報を維持する。サブスクライバは、そのような通知統計情報にアクセスし得る。この情報に基づいて、サブスクライバは、既存の通知標的を除去すること、または新しい通知標的を追加することをサービス層に要求し得る。第３の例示的方法では、サービス層は、ある条件下で、例えば、通知が発行され、通知標的に伝送された後、通知確認メッセージをサブスクライバに送信する。

第４の例示的方法では、サブスクライバは、通知標的と直接相互作用し、通知統計情報を計算すること、または通知確認をサブスクライバに返信することをそれらに要求する。第５の例示的方法では、サービス層は、通知標的にサブスクライバおよび対応するサブスクリプションを認識させるために、サブスクリプション要求が完全に実行される前に通知標的にコンタクトし得る。通知標的も、サービス層がそれらの最新のステータスを把握し、将来の通知を伝送する効率的な方法を決定することができるように、それらの状況ステータス情報をサービス層に能動的または受動的に報告し得る。
本発明はさらに、例えば、以下を提供する。
（項目１）
装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されたメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
サブスクライバデバイスによるリソースのイベント通知を受信するための第１のサブスクリプション要求を取得することと、
前記第１のサブスクリプション要求に基づいて通知メッセージを記録するためのリソースを生成することと
を含む動作を前記プロセッサに達成させる、装置。
（項目２）
前記動作は、
前記イベント通知がある期間中に生じたときに前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
前記期間に対する前記通知メッセージを備えている応答を送信することと
をさらに含む、項目１に記載の装置。
（項目３）
前記動作は、
発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
前記発見基準が満たされる場合、前記通知メッセージを備えている応答を送信することと
をさらに含む、項目１〜２のいずれか１項に記載の装置。
（項目４）
前記動作は、
発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することであって、発見基準は、送信されており、かつ前記通知標的によって取得されたとして確認されていないメッセージに対する要求を備えている、ことと、
前記発見基準が満たされる場合、前記通知メッセージを備えている応答を送信することと
をさらに含む、項目１〜３のいずれか１項に記載の装置。
（項目５）
前記動作は、
発見基準に基づいて通知標的に関連付けられた前記イベント通知を削除するための第２のサブスクリプション要求を取得することと、
前記発見基準が満たされる場合、前記第２のサブスクリプション要求を確認する応答を送信することと
をさらに含む、項目１〜４のいずれか１項に記載の装置。
（項目６）
前記動作は、
発見基準に基づいて通知標的に関連付けられた前記イベント通知を削除するための第２のサブスクリプション要求を取得することであって、発見基準は、ある期間中に送信されたメッセージを備えている、ことと、
前記発見基準が満たされる場合、前記第２のサブスクリプション要求を確認する応答を送信することと
をさらに含む、項目１〜５のいずれか１項に記載の装置。
（項目７）
前記第１のサブスクリプション要求は、ある期間中に発行される全通知を記録するための命令を備えている、項目１〜６のいずれか１項に記載の装置。
（項目８）
前記第１のサブスクリプション要求は、ある期間中に発行され、リストの中の通知標的に配信され、リストの中の条件によって生成される通知を記録するための命令を備えている、項目１〜７のいずれか１項に記載の装置。
（項目９）
前記第１のサブスクリプション要求は、ある一定の数が特定の通知標的に対して失敗したときに通知を記録するための命令を備えている、項目１〜８のいずれか１項に記載の装置。
（項目１０）
前記動作は、作成されるべき通知リソースの有効期限の指示を取得することをさらに含む、項目１〜９のいずれか１項に記載の装置。
（項目１１）
前記装置は、サービス層である、項目１〜１０のいずれか１項に記載の装置。
（項目１２）
通知にサブスクライブする方法であって、前記方法は、
サービス層によって、サブスクライバデバイスによるリソースのイベント通知を受信するための第１のサブスクリプション要求を取得することと、
前記サービス層によって、前記第１のサブスクリプション要求に基づいて通知メッセージを記録するためのリソースを生成することと
を含む、方法。
（項目１３）
前記サービス層によって、前記通知がある期間中に生じたときに前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
前記サービス層によって、前記期間に対する前記通知メッセージを備えている応答を送信することと
をさらに含む、項目１２に記載の方法。
（項目１４）
前記サービス層によって、発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することであって、発見基準は、送信されており、かつ取得されたとして確認されていないメッセージに対する要求を備えている、ことと、
前記発見基準が満たされる場合、前記通知メッセージを備えている応答を送信することと
をさらに含む、項目１２または１３に記載の方法。
（項目１５）
コンピュータプログラムを記憶しているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットの中にロード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、前記データ処理ユニットに項目１２〜１４のいずれかに記載の方法ステップを実行させるように適合されている、コンピュータ読み取り可能な記憶媒体。

より詳細な理解が、付随の図面と併せて一例として挙げられる以下の説明からもたらされ得る。
図１は、サービス層を伴う例示的ＩＰネットワークスタックを図示する。 図２は、例示的共通サービスエンティティ（ＣＳＥ）および共通サービス機能（ＣＳＦ）を図示する。 図３は、例示的ｏｎｅＭ２Ｍサービス層機能的アーキテクチャ（ＲＯＡ）を図示する。 図４は、ＩＮ−ＡＥ１がＩＮ−ＣＳＥ上のリソースにサブスクリプションを行うｏｎｅＭ２Ｍ仕様による例示的方法を図示する。 図５は、スマートヘルスケアユースケースのための例示的システムを図示する。 図６は、サブスクライバが、最初に、サービス層に対して、通知を記録し、通知統計情報を計算し、サブスクリプション要求中に通知を確認するためのその要件を示す場合の本明細書で議論される例示的方法の概要を図示する。 図７は、サブスクリプションおよび通知サービスのための方法の例示的概要を図示する。 図８は、過去の通知についての情報を記録し、それにアクセスする例示的方法を図示する。 図９は、通知記録を停止または変更する例示的方法を図示する。 図１０は、通知統計情報を維持し、それにアクセスする例示的方法を図示する。 図１１は、サービス層からサブスクライバに通知確認を送信する例示的方法を図示する。 図１２は、サブスクライバが通知統計情報を検出することを通知標的に直接要求する、例示的方法を図示する。 図１３は、サブスクライバが通知標的から通知確認を要求する例示的方法を図示する。 図１４は、通知標的とサブスクライバとの間および通知標的とサービス層との間で認識を可能にする例示的方法を図示する。 図１５は、例示的拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦを図示する。 図１６は、例示的＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースを図示する。 図１７は、例示的＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースを図示する。 図１８は、例示的ユーザインターフェースを図示する。 図１９は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。 図２０Ａは、開示される主題が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２０Ｂは、図２０Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る例示的アーキテクチャの系統図である。 図２０Ｃは、図２０Ａに図示される通信システム内で使用され得る例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２０Ｄは、図２０Ａの通信システムの側面が具現化され得る例示的コンピューティングシステムのブロック図である。

本明細書では、サブスクリプションおよび通知サービスのための機構が開示され、機構は、とりわけ、見逃したもしくは不必要な通知の数を削減するために、または異なる粒度で通知履歴情報へのアクセスをサポートするために、通知標的ステータスに基づいて通知挙動を動的に変化させることを含み得る。開示されるサブスクリプションおよび通知サービスは、サブスクライバ、サービス層、または通知標的への影響を有し得る。本明細書で議論されるように、従来のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）におけるリソースサブスクリプションおよび通知機構は、以下のような問題を有する：１）サブスクライバまたは通知標的が過去に生成された通知についての情報にアクセスする方法がないか、または非効率的な方法があること、または、２）通知標的がサブスクリプションを認識せずサービス層が、通知標的の状況情報を認識していないこと。問題は、不必要な通知を引き起こし、リソースサブスクリプションおよび通知機構を非効率的にし得る。例では、通知は、イベント通知基準を満たすサブスクライブされたリソースへの変更があるときにＭ２Ｍサービス層によって生成されるメッセージであり得る。通知メッセージは、サブスクライバまたは通知標的に変更を知らせるために、それらに送信される。

図５は、患者の身体センサ１５１からの健康データが収集されるスマートヘルスケアシナリオを図示する。健康データは、ホスティングノードと称され得るＭ２Ｍサーバ１５３にアップロードされ得る（または代替として、患者に関連付けられたモバイルデバイス１５２上にローカルに記憶される）。デバイス１５５を介して、患者の保護者は、健康データにサブスクリプション１６０を行い得、それによって、患者の医師、介護者、親戚、および保険会社の関連付けられたデバイス（それぞれ、デバイス１５６、１５７、１５８、および１５９）等は、通知標的として、患者の健康データの変更についての自動通知１６１を受信する。例えば、患者が現在自宅で治療を受けている場合、患者の心拍数の急上昇は、医師が把握するために重要であり得る。

このスマートヘルスケアシナリオでは、リソースサブスクリプションおよび通知に以下の要件が存在し得る：１）Ｒｅｑ１：着目イベントが生じる度、通知がＭ２Ｍサーバ１５３によって発行され、通知標的（例えば、デバイス１５６−１５９）によって受信されることを検証すること（本要件は、保護者デバイス１５５によって要求され得る）、２）Ｒｅｑ２：各通知標的に送信され、それによって正常に受信される通知の量（この要件は、保護者デバイス１５５によって要求され得る）、３）Ｒｅｑ３：通知標的がインターネットまたはＭ２Ｍサーバ１５３への接続を有していないとき、デバイス１５６（例えば、医師デバイス）にいかなる通知も見逃させないこと、４）Ｒｅｑ４：他の未知の患者または個人ではなく、患者（またはさらに数人の選択された患者）についての通知を受信すること（例えば、医師デバイスのみに適用され得る）、および、５）Ｒｅｑ５：各伝送された通知が、通知標的によって受信されるべきことが期待されること（これは、Ｍ２Ｍサーバ１５３を介して要求され得る）。Ｒｅｑ５は、各通知が受信されない場合、帯域幅を無駄にし、オーバーヘッドに影響し、通知有用性に有意に影響を及ぼし得るので、所望され得る。

サービス層技法としてのｏｎｅＭ２Ｍは、ヘルスケアシナリオにおける前述の５つの要件のような要件をサポートすることにおいて制限された能力を有する。例えば、従来のｏｎｅＭ２Ｍでは、ＡＥ等のサブスクライバは、通知が発行され、通知標的によって正常に受信されたかどうかを把握しない。加えて、従来のｏｎｅＭ２Ｍにおける通知標的は、サブスクリプションがどのサブスクライバからであっても、サービス層から通知（例えば、応答メッセージ）を受動的に受信する。

ｏｎｅＭ２Ｍ等の従来のＭ２Ｍサービス層内のサブスクリプションまたは通知機構は、以下の問題を有し得る。第１の問題は、Ｍ２Ｍサービス層（例えば、Ｍ２Ｍサーバ１５３）が通知を自動的に生成し得るが、それが過去に発行された通知についての情報へのいかなるアクセスもサブスクライバ（例えば、デバイス１５５）または通知標的（例えば、デバイス１５６）に提供しないことである。過去の通知にアクセスできないことは、問題であり得る。なぜなら、サブスクライバ（例えば、デバイス１５５）が、緊急通知が実際に発行され、全てまたは選択された通知標的によって受信されたかどうかを把握することを欲し得るからであり、オフライン通知標的（例えば、デバイス１５６）も、オンラインになった後、任意の欠落している通知を把握し、取得することを欲し得るからである。例えば、スマートヘルスケアシナリオでは、デバイス１５５は、患者の急な心拍数上昇についての通知がデバイス１５６によって正常に受信されているかどうかを把握することを欲するであろう。この第１の問題は、Ｒｅｑ１−Ｒｅｑ３の前述の要件に関する。

第２の問題は、Ｍ２Ｍサービス層が通知標的についての状況情報（例えば、それらの利用可能性、それらの新しいＩＰアドレス等）を認識していないことであり得る。そのような無認識は、例えば、Ｍ２Ｍサービス層からオーバーロードした通知標的への不必要な通知を引き起こし得る。この第２の問題は、Ｒｅｑ３−Ｒｅｑ５の前述の要件に関する。

図６−図１４に図示されるステップを実施するエンティティは、論理エンティティであり得ることが理解される。ステップは、図２０Ｃまたは図２０Ｄに図示されるもの等のデバイス、サーバ、もしくはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行し得る。例では、Ｍ２Ｍデバイスの相互作用に関して以下でさらに詳細に、図６−図１４のサブスクライバ１７３または通知標的１７５が、図２０ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方で、図６−図１４のサービス層１７１は、図２０ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

以下では、サブスクライバおよび通知標的が過去の通知についての情報にアクセスするための異なるアプローチ、ならびに通知標的状態認識をサポートする方法が議論される。図６は、第１の問題に関連付けられた例示的方法の概要を図示する。ステップ１８１では、サービス層１７１（例えば、Ｍ２Ｍサーバ１５３）は、サブスクライバ１７３（例えば、保護者デバイス１５５）からサブスクリプション要求を受信し得る。サブスクリプション要求１８１は、通知を記録すること、通知統計情報を維持すること、通知標的１７５（例えば、医師デバイス１５６）に関して通知を確認することに対するサービス層１７１への要求を示し得る。ステップ１８２では、サービス層１７１は、イベントの指示を受信する。ステップ１８２に応答し得るステップ１８３では、サービス層１７１は、通知を通知標的１７５に送信する。本明細書でさらに詳細に議論されるステップ１８４からステップ１８５は、ステップ１８１で送信されたサブスクライバ１７３からの要件に基づくサービス層アクションを伴う。ステップ１８４では、通知の記録がある。ステップ１８５では、通知に関連付けられた統計情報の計算がある。ステップ１８６では、サブスクライバ１７３に送信される通知の確認がある。ステップ１８７またはステップ１８８では、それぞれ、サブスクライバ１７３または通知標的１７５からの過去の通知もしくは通知統計情報のアクセスがある。

図６を継続して参照して、要約すると、本明細書で議論される方法は、サブスクライバ１７３が、最初に、要求中、サービス層が通知を記録し、通知統計情報を計算し、サブスクリプション通知を確認することに対するその要求を示す場合を含み得る。サービス層１７１は、イベントが起こり、通知メッセージが発行されるとき、アクションを行い得る（例えば、通知を記録する）。サービス層１７１が通知を記録する場合、または通知統計情報を維持する場合、サブスクライバ１７３もしくは通知標的１７５は、それらに能動的にアクセスすることができる。

第５の方法では、サブスクライバ１７１は、サービス層１７１から１つまたは複数の通知メッセージを受信したとき、通知統計情報を計算すること、または通知確認を送信することを通知標的１７５に直接要求する。図７は、方法フローの例示的概要を図示する。サブスクライバ１７３は、最初に、サブスクリプション確認についてのその要件を示し、それに基づいて、サービス層１７１は、サブスクライバからのサブスクリプション要求を確認するために通知標的１７５にコンタクトするであろう（ステップ１９１）。これは、通知標的１７５にサブスクリプションを認識させる（ステップ１９２）。ステップ１９２では、サービス層１７１は、イベントの指示を受信する。ステップ１８２に応答し得るステップ１９３では、サービス層１７１は、通知を通知標的１７５に送信する。次いで、通知標的１７５は、応答メッセージの中（ステップ１９５）または別個のメッセージの中（ステップ１９６）に含まれ得るそれらのステータスもしくは状況情報をサービス層１７１に報告し得、これ（ステップ１９５またはステップ１９６）は、サービス層１７１が通知標的１７５の状態を認識することを可能にする。

図６のステップ１８４に関連付けられた方法を参照すると、ｏｎｅＭ２ＭにおけるホスティングＣＳＥは、見逃した通知をキャッシュし得るが、ホスティングＣＳＥは、それらをサブスクライバ１７３または通知標的１７５にエクスポーズしないので、サブスクライバ１７３または通知標的１７５は、通知が見逃されたことを認識していない。換言すると、サブスクライバ１７３または通知標的１７５は、従来のｏｎｅＭ２Ｍシステムにおいて、ホスティングＣＳＥから見逃した通知を能動的に読み出さないことも、削除しないこともある。

図６のステップ１８５に関連付けられた方法を参照すると、ｏｎｅＭ２Ｍは、通知統計情報を計算し、サブスクライバ１７３または通知標的１７５にエクスポーズすることをサポートしない。図６のステップ１８６に関連付けられた方法を参照すると、ｏｎｅＭ２Ｍは、通知確認をサブスクライバ１７３に送信することをサポートしない。従来のｏｎｅＭ２Ｍは、サブスクライバ１７３または通知標的１７５の間の直接相互作用をサポートしない。図７を参照すると、従来のｏｎｅＭ２Ｍは、サブスクライバ１７３または通知標的１７５の間の認識もサポートしない。

以下では、通知に関連付けられた情報にアクセスする方法が議論される。サブスクライバ１７３または通知標的１７５は、種々の目的のために前の通知についての情報にアクセスすることを欲し得る。本明細書の方法は、サブスクリプションおよび通知に関連付けられたサービスのために、独立して、または一緒に稼働し得る。

図８は、過去の通知についての情報を記録し、それにアクセスする例示的方法を図示する。要約すると、このアプローチのために、サービス層１７１は、サブスクライバ１７３および通知標的１７５による以降の読み出しのために、各発行された通知を能動的に記録し得る。代替として、サブスクライバ１７３は、選択された通知を記録すること（例えば、特定の通知標的１７５への全ての通知を記録すること、通知メッセージを正常に受信した通知標的のリストを記録すること）をサービス層１７１に要求し得る。それは、概して、以下の方法で稼働し得る。最初に、サブスクライバ１７３は、サブスクリプション要求の中で通知を記録することについてのその要件を示す。続いて、通知がサービス層１７１によって発行される度、サービス層１７１は、それがサブスクライバ１７３からの要求に従って記録される必要があるかどうかを決定する。回答が「はい」である場合、サービス層１７１は、この通知を記録するための新しいリソースを作成する。この新しいリソースは、通知リソースと称され得る。通知リソースは、発行された通知についてのいくつかの属性を有する（例えば、その生成時間、その生成条件、対応するサブスクリプションへの参照、この通知を正常に受信した通知標的のリスト等）。最後、サブスクライバ１７３または通知標的１７５は、サービス層１７１によって作成され、サービス層１７１で維持されるそのような通知リソースにアクセスし得る。サービス層１７１は、サブスクライバ１７３、通知標的１７５、または他のサービス層エンティティが、これらの通知リソースへのアクセスを有するかどうかを認可するためのあるアクセス制御ポリシを採用し得る。サブスクライバ１７３に対して、通知リソースへのアクセスは、発行され、通知標的１７５によって正常に受信された通知の数をサブスクライバ１７３把握することを可能にし得る。通知標的１７５に対して、サービス層１７１によって提供される特徴は、通知標的１７５がオフラインまたは利用不可能（例えば、通知標的１７５が、そのアドレス変更、またはサービス層１７１への接続を失うことに起因して到達不能になる）であったときに見逃された通知を以降で読み出す機会を通知標的１７５に与える。加えて、過去の通知についての情報を読み出し、把握した後、サブスクライバ１７３は、通知標的１７５が期間内に通知を受信しない場合、通知標的１７５を除去するための要求をサービス層１７１に送信し、それによって、サービス層１７１は、将来により多くの通知を送信せず、不必要な通知を回避または削減し得る。さらに、サブスクライバ１７３は、通知を記録することを停止すること、または通知が記録されるべき方法を変更することを行うための要求メッセージをサービス層１７１に送信し得る。

図８を継続して参照すると、以下は、過去の通知についての情報を記録し、それにアクセスするための例示的なステップ毎の議論である。ステップ２０１では、サブスクライバ１７１は、サブスクリプション要求メッセージをサービス層１７１に送信し得る。イベント通知基準のような情報に加えて、このメッセージは、いくつかの他のパラメータまたはフィールドから成る複合パラメータ「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」を含み得る。複合パラメータは、複数のフィールドを含み、各フィールドは、表１で定義され、示されるようなパラメータである。このパラメータは、発行された通知が記録されるべきとき、方法、または通知のいずれかをサービス層１７１に知らせ得る。表１は、「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」を定義する。サブスクライバ１７３は、例えば、ステップ２０３後、サービス層１７１を用いてそのリソースサブスクリプションを更新し得る。そのようなリソースサブスクリプション更新では、サブスクライバ１７３は、「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」を含み得る。サービス層１７１が新しい「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」を受信する度、サービス層１７１は、記録すべき将来の通知を決定するために使用し得る。サブスクライバ１７３が通知記録要件についての十分な情報を提供しない場合、サービス層１７１は、そのローカルポリシに基づいて通知を記録することを決定し得る。ステップ２０２では、サービス層１７１は、要求を容認し、故に、サブスクリプションリソースを作成し得る。ステップ２０３では、サービス層１７１は、応答をサブスクライバ１７３に送信し、それに作成されたサブスクリプションリソースを知らせ得る。ステップ２０４では、ステップ２０１で提供されたイベント通知基準を満たすイベントが生じる。

図８を継続して参照すると、ステップ２０５では、サービス層１７１は、通知標的１７５に送信される通知メッセージを発行する。ステップ２０６では、通知標的１７５は、応答を返信する。ステップ２０６では、ステップ２０１の「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」に関連付けられた情報に従って、サービス層１７１は、ステップ２０６で送信された通知メッセージを記録するための新しい通知リソースを作成すべきかどうかを決定する。例えば、ｎｏｔｉｆＲｅｃｏｒｄＲｅｑが、ありとあらゆる通知メッセージを記録することを要求する場合、サービス層１７１は、任意の発行された通知のための通知リソースを作成し得る。各作成された通知リソースは、とりわけ、通知メッセージが発行された時間、通知メッセージをトリガした通知条件、通知メッセージに関連付けられたサブスクライブ先リソース、通知メッセージを正常に受信した通知標的１７５のリスト、または通知メッセージを見逃した通知標的１７５のリスト等の属性を有し得る。各作成された通知リソースは、有効期限を有し得、有効期限が満了したとき、作成された通知リソースは、自動的に除去されるであろう。通知リソースが作成されると、それは、サブスクライバまたは通知標的によって読み出され得る。例えば、図８のステップ２０８は、通知標的１７５がこの作成された通知リソースを読み出すことを示す。

図８において、ステップ２０８では、例えば、通知標的１７５が、ある時間にわたってオフラインになると仮定すると、通知標的１７５がオンラインに戻るとき、それは、サービス層１７１から任意の欠落している通知を能動的に読み出し得る。通知標的１７５が、作成されている通知リソースがあるかどうかを把握しない場合があるので、それは、例えば、過去の時間間隔内にそれ（通知標的１７５）のために発行された通知があったかどうかを尋ねるために、リソース発見要求をサービス層１７１に単に送信し得る。通知標的がオフラインであり、ステップ２０５を受信しなかった場合には、通知リソースがステップ２０７で作成されているかどうかを把握していない。通知標的１７５は、（例えば、ある通知条件によってトリガされた、任意の発行されたが、正常に受信されなかった通知メッセージを発見するために）追加の発見基準も提供し得る。ステップ２０９では、サービス層１７１は、応答メッセージを通知標的１７５に送信し得る。応答メッセージは、発行されたが、通知標的１７５によってまだ正常に受信されていない複数の通知メッセージ、または、ステップ２０８で通知標的１７５によって示されるような発見基準を満たす通知メッセージのリストを含み得る。ステップ２１０では、サブスクライバ１７３は、サービス層１７１によって作成された通知リソースを能動的に読み出す（または削除する）ための要求を送信する。このステップは、ステップ２０８に類似する。違いは、ステップ２１０では、サブスクライバ１７３が、いくつかの条件下でサービス層１７１から通知リソースを発見した（例えば、対応する通知メッセージが全てのまたは好ましい通知標的１７５によって正常に受信された）後、サブスクライバ１７３が、通知リソースを削除し、サービス層１７１における記憶を削減することを要求し得ることである。ステップ２１１では、サービス層１７１は、応答をサブスクライバ１７３に送信する。ステップ２１０における要求が通知リソースを読み出すことである場合、ステップ２１１は、ステップ２０９に類似し、応答は、複数の通知メッセージを含み得る。ステップ２１０における要求が通知リソースを削除することである場合、ステップ２１１における応答は、削除要求の結果（例えば、承認または拒否）を単に知らせ得る。

図８は、サブスクライバ１７３が、サービス層１７１が通知を記録することを要求し得ることを図示する。サブスクライバ１７３は、図９に図示されるように、通知記録を停止または変更することをサービス層１７１に要求し得る。他のエンティティも、それらがアクセス権を有するとき、通知記録を停止または変更することを要求し得ることが理解される。あるプライバシー問題等、アクセスを制限すべき異なる理由があり得る。

図９を継続して参照すると、ステップ２２１では、サブスクライバ１７３は、通知を記録することを停止するための要求メッセージをサービス層１７１に送信する。このメッセージは、対応するまたは関連付けられたサブスクリプションのみを示し得る。代替として、サブスクライバ１７３は、通知記録の停止を示すメッセージの中、ｎｏｔｉｆＲｅｃｏｒｄＲｅｑの一部（例えば、［−２０，−１０］）として無効ｎｏｔｉｆＲｅｃｏｒｄＴｉｍｅＤｕｒａｔｉｏｎ等のパラメータを含み得る。ステップ２２２では、サービス層１７１は、ステップ２２１における要求が承認されたか、拒否されたかを示す応答をサブスクライバ１７３に送信する。ステップ２２３では、サブスクライバ１７３は、将来の通知が記録されるべき方法を変更するための要求メッセージもサービス層１７１に送信し得る。このメッセージは、パラメータ「ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ」のための新しい値を含み得る。通知記録が以前に停止された場合、ステップ２２３におけるこの要求は、通知記録を間接的に再開し得る。記録された通知リソースは、サブスクライバ１７３によって能動的に削除され得るか、または各通知リソースが関連付けられた満了時間を有することにより満了し得る。ステップ２２４では、サービス層１７１は、ステップ２２３における要求が承認されたか、拒否されたかを示す、応答をサブスクライバ１７３に送信する。

以下では、サービス層１７１において通知統計情報を維持する方法およびシステムが議論される。サービス層１７１は、各単一通知の代わりに、時間窓中に発行された過去の通知についての統計情報を維持し得る。時間窓は、通知メッセージが発行された時間に基づくリアルタイム窓、または固定数の通知メッセージのみを含む仮想時間窓であり得ることに留意されたい。統計情報の例は、とりわけ、時間窓内の発行された通知の平均数、時間窓内の通知標的１７５による正常に受信された通知の数、時間窓内の通知標的１７５への連続的に不成功であった通知の最大数、または特定の通知標的１７５への不成功通知試行の数を含み得る。サブスクライバ１７３は、サブスクリプション要求中に通知統計情報の１つ以上のパラメータを計算することをサービス層１７１に要求し得る。次いで、サービス層１７１は、新しい通知が発行され、通知標的１７５に伝送される度、通知統計情報を再計算し続け得る。通知統計情報がサービス層１７１によって生成されると、サブスクライバ１７３は、それを読み出し得、通知統計情報に基づいて、（例えば、通知標的１７５が最近発行された全てまたは高い割合の通知を見逃した場合）通知標的１７５を除去するか、または（例えば、全てまたは高い割合の通知標的１７５がいかなる通知も受信できない場合）新しい通知標的１７５を追加することを決定し得る。したがって、別個の要求メッセージが、通知標的１７５を調節する（除去または追加する）ために、サブスクライバ１７３からサービス層１７１に送信されるであろう。別の例では、サービス層１７１は、サブスクライバ１７３または他のエンティティからの要求に基づいて、特定のサブスクリプションについての通知統計情報の１回限りのオンデマンド計算を実施し得、このオンデマンド通知統計情報計算は、通知統計情報に対して非常に少ない要求しかない場合、より効率的であり得る。

図１０は、通知統計情報を維持し、それにアクセスする例示的方法を図示する。ステップ２３１では、サブスクライバ１７３は、サブスクリプション要求メッセージをサービス層１７１に送信する。ステップ２３１の要求は、イベント通知基準等の情報ならびにパラメータ「ｎｏｔｉｆＳｔａｔＲｅｑ」を含み得る。このｎｏｔｉｆＳｔａｔＲｅｑパラメータは、計算または維持すべき通知統計情報のための命令を含み得る。表２は、ｎｏｔｉｆＳｔａｔＲｅｑを定義する。サブスクライバ１７３は、ステップ２３３後、サービス層１７１を用いてそのリソースサブスクリプションを更新し得る。リソースサブスクリプション更新では、サブスクライバ１７３は、それがたとえステップ２３１で含まれていたとしても「ｎｏｔｉｆＳｔａｔＲｅｑ」を含み得る。サービス層１７１が新しい「ｎｏｔｉｆＳｔａｔＲｅｑ」を受信する度、サービス層１７１は、将来の通知統計情報を計算するためにそれを使用するであろう。ステップ２３２では、サービス層１７１は、要求を容認し、故に、サブスクリプションリソースを作成する。ステップ２３３では、サービス層１７１は、サブスクリプションリソースの作成についての情報を提供する応答をサブスクライバ１７３に送信する。応答メッセージは、ステップ２３７において（再）計算されるべきであるが、「ｎｏｔｉｆＳｔａｔＩｎｆｏ」のアドレスも含み得、それによって、サブスクライバ１７３は、このアドレスを使用し、ステップ２３８において「ｎｏｔｉｆＳｔａｔＩｎｆｏ」を直接読み出すことができる。

ステップ２３４では、ステップ２３１で提供されるイベント通知基準を満たすイベントが生じる。ステップ２３５では、サービス層１７１は、通知メッセージを通知標的１７５に送信する。ステップ２３６では、通知標的１７５は、応答を返信する。ステップ２３７では、サービス層１７１は、パラメータ「ｎｏｔｉｆＳｔａｔＲｅｑ」によって示されるサブスクライバ１７３の要件に従って、通知統計情報を（再）計算する。計算された通知統計情報は、新しいリソースとして作成され得るか、またはステップ２３２で作成されているサブスクリプションリソースに新しい属性として追加され得る新しいパラメータ「ｎｏｔｉｆＳｔａｔＩｎｆｏ」の中で維持される。代替として、サービス層１７１は、例えば、十分な記憶を有する場合、最新のものだけではなく、全ての計算された通知統計情報を維持し得る。

ステップ２３８では、サブスクライバ１７３は、サービス層１７１から「ｎｏｔｉｆＳｔａｔＩｎｆｏ」を読み出す（または「ｎｏｔｉｆＳｔａｔＩｎｆｏ」のアドレスを把握しない場合、発見する）。ステップ２３９では、サービス層１７１は、応答（例えば、「ｎｏｔｉｆＳｔａｔＩｎｆｏ」の値）をサブスクライバ１７３に返信する。ステップ２４０では、サブスクライバ１７３は、通知統計情報に基づいて、任意の通知標的１７５を除去すべきか、または追加すべきかを決定し得る。例では、通知標的１７５が、現在の時間窓内に発行された全てまたは高い割合の通知を見逃した場合、サブスクライバ１７３は、通知標的１７５を除去することを決定し得る。別の例では、全てまたは閾値割合の通知標的が、現在の時間窓内にいかなる通知も受信することができない場合、新しい通知標的１７５が追加され得る。ステップ２４１では、サブスクライバ１７３は、ステップ２４０で行われる決定に従って、通知標的１７５を調節する（例えば、除去する、追加する、または別様に調節する）ための要求をサービス層１７１に送信し得る。ステップ２４２では、サービス層１７１は、結果（例えば、調節を容認または拒否した）をサブスクライバ１７３に送信する。

以下では、サービス層１７１からサブスクライバ１７３への通知確認が議論される。通知を記録すること、または通知統計情報を計算することの代わりに、別のアプローチは、サブスクライバ１７３に過去の通知についての情報にアクセスさせることである。サービス層１７１は、通知が１つまたは全ての通知標的に伝送されるとき、通知確認をサブスクライバ１７３に能動的に送信し得る。基本的に、通知メッセージが通知標的１７５によって正常に受信された後、サービス層１７１は、通知確認メッセージをサブスクライバ１７３に送信し、それにこの通知メッセージを知らせ得る。複数の通知標的がある場合、同じ通知メッセージが、複数回伝送され得る。通知確認メッセージの数を削減するために、サービス層１７１は、同じ通知メッセージが全ての通知標的に伝送された後、１つだけの通知確認メッセージをサブスクライバ１７３に送信し得る。さらに、サブスクライバ１７３は、ある数の通知メッセージが１つまたは全ての通知標的に伝送されたとき、通知確認メッセージを送信するようにサービス層１７１に要求し得る。上記アプローチと同様、サブスクライバ１７３は、通知確認からの情報に基づいて、通知標的を調節し得る（例えば、除去する、追加する、または別様に調節する）。

図１１は、サービス層１７１からサブスクライバ１７３に通知確認を送信する例示的方法を図示する。ステップ２５１では、サブスクライバ１７３は、サブスクリプション要求メッセージをサービス層１７１に送信する。イベント通知基準のような情報に加えて、ステップ２５１のメッセージは、パラメータ「ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑ」を含み得る。このｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑパラメータは、サブスクライバ１７３によって確認されるべき通知をサービス層１７１に告げる。表３は、この複合パラメータを定義する。サブスクライバ１７３は、ステップ２５３後、サービス層１７１を用いてそのリソースサブスクリプションを更新し得る。リソースサブスクリプション更新では、サブスクライバ１７３は、たとえステップ２５１で含まれたとしても「ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑ」も含み得る。サービス層１７１が新しい「ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑ」を受信する度、サービス層１７１は、将来の通知を確認するためにそれを使用し得る。ステップ２５２では、サービス層１７１は、要求を容認し、故に、サブスクリプションリソースを作成する。ステップ２５３では、サービス層１７１は、応答をサブスクライバ１７３に送信し、それに作成されたサブスクリプションリソースを知らせる。

図１１を参照すると、ステップ２５４では、ステップ２５１に含まれるイベント通知基準を満たすイベントが生じる。ステップ２５５では、サービス層１７１は、通知メッセージを通知標的１７５に送信する。ステップ２５６では、通知標的１７５は、ステップ２５５における通知が正常に受信されたことをサービス層１７１に告げる応答を返信する。ステップ２５７では、サービス層１７１は、通知メッセージを記憶し、「ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑ」に基づいて、通知確認をサブスクライバ１７３に送信する必要があるかどうかを決定する。ステップ２５８では、サービス層１７１は、通知確認メッセージをサブスクライバ１７３に送信する。このメッセージは、通知標的に正常に送信された１つ以上の通知メッセージを含み得る。

ステップ２５９では、サブスクライバ１７３は、応答をサービス層１７１に返信する。ステップ２５９における応答は、単純に、ステップ２５８における通知確認が正常に受信されたことをサービス層１７５に告げるのみである。ステップ２６０では、サブスクライバ１７３は、通知標的１７５を除去または追加することを決定し得る。通知標的１７５を除去することに関する例では、通知標的１７５は、時間窓内に発行された全てまたは閾値割合の通知を見逃した場合に除去され得る。通知標的１７５を追加することに関する例では、全てまたは高い割合の他の通知標的が現在の時間窓内にいかなる通知も受信することができない場合に追加され得る。ステップ２６１では、サブスクライバ１７３は、ステップ２６０で行われる決定に従って通知標的を調節するための要求をサービス層１７１に送信する。ステップ２６２では、サービス層１７１は、結果（例えば、調節を容認または拒否する）をサブスクライバ１７３に送信する。

前の方法は、新しい特徴をサービス層１７１に導入し、それに依拠して、サブスクライバ１７３または通知標的への通知についての情報へのアクセスを提供する。以下では、サブスクライバと通知標的との間の直接相互作用が開示される。これらの相互作用は、サブスクライバ１７３および通知標的が殆どの場合にアプリケーションであろうため、アプリケーションレベル相互作用と見なされ得る。しかしながら、この代替的アプローチは、サービス層１７１が不必要な通知を送信することを回避することに役立たないこともありあり、通知標的１７５が欠落している通知を読み出すための命令を提供しないこともある。サブスクライバ１７３と通知標的１７５との間の直接相互作用は、以下を含み得る：１）サブスクライバ１７３は、それがサービス層１７１から受信した通知についての統計情報を計算することを通知標的１７５に要求し、計算された統計情報は、サブスクライバ１７３に能動的に折り返し報告され得るか、または、サブスクライバ１７３が読み出すことを受動的に待ち得る。２）サブスクライバ１７３は、それがサービス層１７１から受信した各または複数の通知に対する通知確認を送信することを通知標的１７５に要求する。

図１２は、サブスクライバ１７３が通知統計情報を計算することを通知標的１７５に直接要求する例示的方法を図示する。ステップ２７０では、サブスクリプション要求がサブスクライバ１７３とサービス層１７１との間で完了したと仮定される。ステップ２７１では、サブスクライバ１７３は、要求メッセージを通知標的１７５に送信し、計算される必要がある通知統計情報の種類をそれに知らせる。このメッセージの中で、パラメータｎｏｔｉｆＳｔａｔＲｅｑが、通知統計計算のためのサブスクライバ１７３の要件を示すために含まれる。ｎｏｔｉｆＳｔａｔＲｅｑは、表２で定義される。ステップ２７１では、通知標的１７５は、応答をサブスクライバ１７３に返信する。ステップ２７１のこのメッセージの中で、通知標的１７５は、サブスクライバ１７３が以降で（例えば、ステップ２７７で）通知統計情報を能動的に読み出し得るように、ステップ２７４で計算される通知統計情報のＵＲＩを含み得る。ステップ２７３では、着目イベントがサービス層１７１におけるサブスクライブされたリソースに生じると、サービス層１７１は、通知メッセージを通知標的１７５に送信する。

ステップ２７４では、通知標的１７５は、ステップ２７１で受信されたｎｏｔｉｆＳｔａｔＲｅｑに従って通知統計情報を（再）計算する。計算された通知統計情報は、「ｎｏｔｉｆＳｔａｔＩｎｆｏ」と称される複合パラメータまたはプレースホルダの中に記憶され得る。ステップ２７５では、通知標的１７５は、計算された統計情報をサブスクライバ１７３に報告する。このメッセージの中で、通知標的１７５は、サブスクライバ１７３が以降で（例えば、ステップ２７７で）通知統計情報を能動的に読み出し得るように、通知統計情報のＵＲＩを含み得る。

図１２を継続して参照すると、ステップ２７６では、サブスクライバ１７３は、確認として応答を通知標的１７５に返信する。ステップ２７７では、サブスクライバ１７３は、ステップ２７２またはステップ２７５から取得されるようなそのＵＲＩを使用して、通知標的１７５から通知統計情報を能動的に読み出す。ステップ２７７では、通知標的１７５は、応答をサブスクライバ１７３に返信する。

図１３は、サブスクライバ１７３が通知標的１７５からの通知確認を要求する例示的方法を図示する。主要概念は、通知標的１７５がサービス層１７１から１つ以上の通知メッセージを受信すると、通知確認メッセージをサブスクライバ１７３に送信するであろうことである。ステップ２８０では、サブスクリプション要求がサブスクライバ１７３とサービス層１７１との間で完了したと仮定される。ステップ２８１では、サブスクライバ１７３は、通知メッセージがサービス層１７１から受信されるときに通知確認を返信することをそれに要求するメッセージを通知標的１７５に送信する。このメッセージは、通知確認に対するサブスクライバ１７３の要件を示すパラメータｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑを含み得る。ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑは、表３で定義されている。この例に対して、１つの通知標的１７５があり、ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑの「ｌｉｓｔＯｆＮｏｔｉｆＴａｒｇｅｔｓＦｏｒＣｏｎｆｉｒｍ」フィールドは、このステップでメッセージを受信している通知標的１７５であろう。ステップ２８２では、通知標的１７５は、確認として応答メッセージをサブスクライバ１７３に送信する。ステップ２８３では、着目イベントがサービス層１７１におけるサブスクライブされたリソースに生じると、サービス層１７１は、通知メッセージ（例えば、イベント通知メッセージ）を通知標的１７５に送信する。ステップ２８４では、通知標的１７５は、通知確認をサブスクライバ１７３に送信する。このメッセージは、図１１のステップ２５８に類似し得る。通知標的１７５は、受信されたパラメータｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑの中で指定される１つの通知または複数の通知をサービス層１７１から受信した後、このメッセージを発行し得る。ステップ２８５では、サブスクライバ１７３は、確認として応答を通知標的１７５に返信する。

ここで説明される問題は、通知標的の状態についてのサービス層１７１の無認識である。以下では、サービス層１７１を認識している状態に保つことに関連付けられた方法およびシステムが開示される。要約すると、最初、サービス層１７１は、サブスクライバ１７３から新しいサブスクリプション要求を受信した後、対応する通知標的をチェックし、この新しいサブスクリプションが作成されることを認識させる。このプロセス中、通知標的１７５は、この新しいサブスクリプションからそれを除去することをサービス層１７１に求めるか、または通知がそれに適切に送信されるべき方法をサービス層１７１に指示し得る。これは、サブスクリプションについての通知標的１７５の認識の不足を解決することに役立つ。第２に、新しいサブスクリプションが作成された後、通知標的は、それらのステータス（例えば、利用可能性、予期される通知率等）をサービス層１７１に能動的に報告し、サービス層１７１への応答メッセージの中でそれらのステータスをピギーバックし得る。次に、サービス層１７１は、通知標的の最新のステータスに従って、将来の通知が伝送されるべき方法を調節し得る。

図１４は、通知標的とサブスクライバ１７３との間、および通知標的とサービス層１７１との間で認識を可能にする例示的方法を図示する。ステップ２９１では、サブスクライバ１７３は、サブスクリプション要求メッセージをサービス層１７１に送信する。通知（例えば、イベント通知）基準のような情報に加えて、このメッセージは、パラメータ「ｓｕｂＣｏｎｆｉｒｍＲｅｑ」を含み得る。このｓｕｂＣｏｎｆｉｒｍＲｅｑパラメータは、サブスクリプション要求を確認するためにコンタクトされるべき通知標的１７５をサービス層１７１に告げる。表４は、ｓｕｂＣｏｎｆｉｒｍＲｅｑを定義する。ステップ２９２では、ｓｕｂＣｏｎｆｉｒｍＲｅｑの中のｓｕｂＣｏｎｆｉｒｍＴｙｐｅがゼロに等しくない場合、サービス層１７１は、サブスクリプション確認メッセージを対応する通知標的に送信する。このメッセージは、以下のパラメータ、またはステップ２９１におけるサブスクリプション要求メッセージのみを含み得る：１）サブスクライバ１７３のアドレスまたは識別子、２）サブスクライブされたリソースのアドレスまたは識別子、３）通知標的１７５が通知を受信するためのアドレス、または、４）イベント通知基準。

ステップ２９３では、通知標的１７５は、応答をサービス層１７１に返信する。通知標的１７５が自発的にこのサブスクリプションの通知を受信しない場合、それは、ステップ２９１でサブスクライバ１７３によって与えられる通知標的のリストからそれを除去することをサービス層１７１に求め得る。加えて、通知標的１７５は、この応答メッセージの中でその現在のステータス（例えば、「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」）をさらにピギーバックし得る。「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」は、通知標的１７５についての以下の状況情報を含み得る：１）将来の通知を受信するための通知標的１７５の新しいネットワーク（例えば、ＩＰ）アドレス、２）許容最大通知到着率（例えば、２つの通知／秒）、または、３）この通知標的１７５のスケジュール情報（例えば、次の３０分間に利用可能であろう、次の２日間に利用不可能であろう等）。ステップ２９４では、サービス層は、サブスクリプションリソースを作成する。ステップ２９５では、サービス層１７１は、応答をサブスクライバ１７３に送信し、作成されたサブスクリプションリソースをそれに知らせる。通知標的１７５がステップ２９３中に除去されることを要求する場合、サービス層１７１は、このステップ２９５においてその通知標的１７５のアドレスまたは識別子を含み得る。ステップ２９６では、ステップ２９１に含まれるイベント通知基準を満たすイベントが生じる。ステップ２９７では、サービス層１７１は、通知メッセージを通知標的１７５に送信する。通知標的１７５がステップ２９３において「許容最大通知率」を示す場合、サービス層１７１は、「許容最大通知率」が違反される場合、この通知メッセージをそれに送信しないこともあることに留意されたい。ステップ２９２におけるサブスクリプション確認メッセージは、代替として、この通知が通知標的１７５に発行される第１の通知である場合、ステップ２９７に含まれ得ることにも留意されたい。この場合、ステップ２９２およびステップ２９３は、省略され得る。

図１４を継続して参照すると、ステップ２９８では、通知標的１７５は、通知標的１７５ステータス情報（例えば、ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ）を含み得る応答を返信する。ステップ２９９では、通知標的１７５のステータスは、変化し得る。例えば、通知を受信するためのその前のアドレスが、利用不可能になる。ステップ３００では、通知標的１７５は、その新しいステータスについてサービス層１７１を更新する。このメッセージは、「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」を含む。ステップ３００は、能動的と見なされ得、ステップ２９８は、受動的と見なされ得る。ステップ２９８が、受信するステップ２９７の結果である一方で、ステップ３００は、ほぼいかなる時間にも生じ得る。ステップ３０１では、サービス層１７１は、応答を通知標的１７５に返信する。ステップ３０２では、サービス層は、各通知標的１７５のステータスを維持し、故に、将来、通知がそれらに伝送されるべき方法を調節する。

以下は、本明細書に開示されるようなサブスクリプションおよび通知のためのｏｎｅＭ２Ｍアーキテクチャ方法を実装するための例である。

図１５は、従来のｏｎｅＭ２Ｍ機能的アーキテクチャに基づいて拡張サブスクリプションおよび通知（ｅＳＵＢ）ＣＳＦ３０５を形成する、従来のｏｎｅＭ２Ｍ ＳＵＢ ＣＳＦへのサブスクリプションおよび通知サービスのための方法を実装するための例示的ＣＳＦを図示する。このｅＳＵＢは、本明細書に説明されるようなサービス層１７１、サブスクライバ１７３、および通知標的１７５の間のプロシージャならびにプロセスをサポートする。ｅＳｕｂは、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＡＳＮ−ＣＳＥの中に常駐し得る。サービス層１７１に関連するリソースおよびプロシージャは、ＣＳＥで実装され得、サブスクライバ１７３は、ＡＥまたはＣＳＥ（例えば、それぞれ、図２０ＡのＭ２Ｍ端末デバイス１８および図２０Ａのゲートウェイデバイス１４）であり得る。

以下は、展開例である。サービス層における記録通知方法に対して、サービス層１７１が、ＣＳＥ（例えば、ＩＮ−ＣＳＥ）であり得る一方で、サブスクライバ１７３は、ＡＥ（例えば、ＩＮ−ＡＥ）またはＣＳＥ（例えば、ＡＳＮ−ＣＳＥ）であり得る。サービス層において通知統計情報を維持することに基づく方法に対して、サービス層１７１が、ＣＳＥ（例えば、ＭＮ−ＣＳＥ）であり得る一方で、サブスクライバ１７３は、ＡＥ（例えば、ＡＤＮ−ＡＥ）であり得る。サービス層からの通知確認に基づく方法に対して、サービス層が、ＣＳＥ（例えば、ＩＮ−ＣＳＥ）であり得る一方で、サブスクライバ１７３は、ＡＥ（例えば、ＩＮ−ＡＥ）であり得る。通知標的ステータス認識に基づく方法に対して、サービス層１７１が、ＣＳＥ（例えば、ＩＮ−ＣＳＥ）であり得る一方で、サブスクライバ１７３は、ＡＥ（例えば、ＩＮ−ＡＥ）またはＣＳＥ（例えば、ＭＮ−ＣＳＥ）であり得る。本明細書に開示されるように、通知標的認識のための方法（例えば、図１４）は、サブスクライバから、サブスクライバデバイスによるリソースのイベント通知を受信するための第１のサブスクリプション要求を取得することであって、第１のサブスクリプション要求は、第１のサブスクリプション要求を確認するためにコンタクトされるべき通知標的を告げる第１のパラメータを備えている、ことと、第１のサブスクリプション要求に基づいて、メッセージを通知標的に送信することであって、メッセージは、サブスクライバの識別子、サブスクライブされたリソースの識別子、通知標的が通知を受信するための識別子、またはイベント通知基準を備えている、ことと、リソースを生成し、第１のサブスクリプション要求に基づいて通知メッセージを記録することとを含み得る。

図１６に示されるように、本明細書で議論される方法をサポートするために、新しいリソース（＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７）が開示される。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソース３０７は、通知メッセージが発行され、通知標的１７５に伝送される（またはパラメータｎｏｔｉｆＲｅｃｏｒｄＲｅｑに依存する他の状況下で作成される）とき、サービス層１７１によって自動的に作成され得る。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソース３０７が作成されると、サブスクライバ１７３または通知標的によって読み出され得る。サブスクライバ１７３は、＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７メッセージを削除し得る。

＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソース３０７は、図１６に図示され、表５に説明される、いくつかの新しい属性を有する。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７は、あるタイプのｏｎｅＭ２Ｍ＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞または＜ｃｏｎｔａｉｎｅｒ＞リソースとしても実装され得、したがって、図１６に示される＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７の属性は、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞または＜ｃｏｎｔａｉｎｅｒ＞のための新しい属性として導入され得る。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソース３０７は、種々の場所に設置され得る（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの子リソース、＜ＡＥ＞リソースの子リソース、＜ｒｅｍｏｔｅＣＳＥ＞リソースの子リソース等）。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７がその子リソースとして＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの下に設置されるとき、＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７は、実際に、この＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのために生成されている通知メッセージを記録する。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞３０７がその子リソースとして＜ＡＥ＞リソースの下に設置され、この＜ＡＥ＞リソースがサブスクライバ１７３であるとき、＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソース３０７は、この場合、サブスクライバ１７３としてのこの＜ＡＥ＞からの＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのために生成されている通知メッセージを表す。

前述のように、＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースは、通知メッセージが発行されるとき、または、通知メッセージがサブスクリプション要求中にｎｏｔｉｆＲｅｃｏｒｄＲｅｑパラメータによって示されるようなサブスクライバ１７３の要件に依存するとき、サービス層１７１によって自動的に作成され得る。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースが作成された後、これは、サブスクライバ１７３もしくは通知標的１７５によって読み出され得るか、またはサブスクライバ１７３によって削除され得る。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースへの許容動作が、表６にリストアップされる。

サブスクライバ１７３からの要件（例えば、サブスクリプション要求中にサブミットされるｎｏｔｉｆＲｅｃｏｒｄＲｅｑパラメータ）に従って、サービス層１７１（例えば、ＣＳＥ）は、それが通知を通知標的１７５に発行するとき、新しい＜ｎｏｔｉｆｉｃａｔｉｏｎ＞メッセージを作成することを自動的に決定する。＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースが作成されるとき、表５にリストアップされるような全てのその属性が、サービス層１７１によって生成されるであろう。

このプロシージャは、（例えば、サブスクライバ１７３または通知標的によって）＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースの属性を読み出すために使用され得る。一般的な読み出しプロシージャは、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ，Ｖ−２．６．０（以降ではｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）の中の第１０．１．２節で説明される。

＜ｎｏｔｉｆｉｃａｔｉｏｎ＞ＤＥＬＥＴＥ方法は、＜ｎｏｔｉｆｉｃａｔｉｏｎ＞リソースを除去するためにサブスクライバ１７３によって使用され得る。一般的な削除プロシージャは、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅの中の第１０．１．４．１節で説明される。

図１８に示されるように、新しいリソース（＜ｎｏｔｉｆＴａｒｇｅｔ＞３１５）が、各通知標的１７５についてのステータス情報を維持するために開示される。サブスクライバ１７３または通知標的は、サービス層１７１（例えば、対応する＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースをホストするＣＳＥ）において＜ｎｏｔｉｆＴａｒｇｅｔ＞リソース３１５を作成することを要求し得る。＜ｎｏｔｉｆＴａｒｇｅｔ＞リソース３１５が作成されると、それは、サブスクライバ１７３または通知標的によって（他のＡＥおよびＣＳＥによってさえも）読み出され／更新され／削除され得る。

＜ｎｏｔｉｆＴａｒｇｅｔ＞リソース３１５は、図１７に図示され、表９に説明されるいくつかの新しい属性を有し、種々の場所に設置され得る（例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの子リソース、＜ＡＥ＞リソースの子リソース、＜ｒｅｍｏｔｅＣＳＥ＞リソースの子リソース等）。＜ｎｏｔｉｆＴａｒｇｅｔ＞３１５がその子リソースとして＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの下に設置されるとき、＜ｎｏｔｉｆＴａｒｇｅｔ＞３１５は、この＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースに関連付けられた通知標的１７５を表す。＜ｎｏｔｉｆＴａｒｇｅｔ＞３１５がその子リソースとして＜ＡＥ＞リソースの下に設置され、この＜ＡＥ＞リソースがサブスクライバ１７３であるとき、＜ｎｏｔｉｆＴａｒｇｅｔ＞リソース３１５は、この＜ＡＥ＞サブスクライバからの＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースに関連付けられた通知標的１７５を表す。

ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥを含む、動作は、表１０で要約されるように、サブスクライバ１７３、サービス層１７１、および通知標的間の開示される相互作用を実現するために、＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースに対して可能にされる。

Ｃｒｅａｔｅ＜ｎｏｔｉｆＴａｒｇｅｔ＞は、＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースを作成するために使用され得る。

Ｒｅｔｒｉｅｖｅ＜ｎｏｔｉｆＴａｒｇｅｔ＞は、（例えば、サブスクライバ１７３または通知標的１７５によって）＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースの属性を読み出すために使用され得る。一般的な読み出しプロシージャは、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅの中の第１０．１．２節で説明される。

Ｕｐｄａｔｅ＜ｎｏｔｉｆＴａｒｇｅｔ＞は、属性および＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースの実際のデータを更新するために使用され得る。

Ｄｅｌｅｔｅ＜ｎｏｔｉｆＴａｒｇｅｔ＞は、＜ｎｏｔｉｆＴａｒｇｅｔ＞リソースを除去するために使用され得る。一般的な削除プロシージャは、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅの中の第１０．１．４．１節で説明される。

ｏｎｅＭ２Ｍにおける既存の＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースは、表１５に説明されるようないくつかの新しい属性を追加することによって、開示されるサブスクリプションおよび通知方法ならびにシステムをサポートするために拡張され得る。＜ｎｏｔｉｆＴａｒｇｅｔ＞および＜ｎｏｔｉｆｉｃａｔｉｏｎ＞は、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞のための新しい子リソースを追加され得ることに留意されたい。代替として、これらの新しい属性は、既存の＜ｎｏｔｉｆｉｃａｔｉｏｎＴａｒｇｅｔＰｏｌｉｃｙ＞リソースの新しい属性または新しい子リソースとして追加され得る。

ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ属性（表１５）の中で捕捉される、通知標的１７５のステータス（例えば、利用可能性）は、サブスクリプションホスティングＣＳＥ、サブスクライバ、またはアクセス制御権を有する任意の他のエンティティ（通知標的１７５自体を含む）のいずれかによるＵＰＤＡＴＥ動作を介して、維持され得る。通知標的１７５がそのステータス（すなわち、ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ属性）を更新するための追加の機構は、以下の新しい仮想リソース（＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの子リソースとして提案される）を使用する。これらの機構は、互いに対して代替であり得るか、または所与の実装で共存し得る。

＜ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓＲｅｆｅｒｅｎｃｅ＞：通知標的１７５は、その新しいステータス（例えば、表１５の中の「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」属性の項目）を含むペイロードを伴うＵＰＤＡＴＥ動作要求を、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのこの仮想リソースに発行し得、次に、サービス層１７１は、この＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」属性を更新する。

＜ｎｏｔｉｆＴａｒｇｅｔＯｎｌｉｎｅ＞：通知標的は、それがオンラインになることをサービス層１７１に知らせるためのＵＰＤＡＴＥ動作要求を＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのこの仮想リソースに発行し得、次に、サービス層１７１は、オンラインであり、通知を受信するために利用可能であるとしてこの通知標的１７５をマークする。

＜ｎｏｔｉｆＴａｒｇｅｔＯｆｆｌｉｎｅ＞：通知標的は、それがオフラインになることをサービス層１７１に知らせるためのＵＰＤＡＴＥ動作要求を＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのこの仮想リソースに発行し得、次に、サービス層１７１は、オフラインであり、通知を受信するために利用不可能であるとしてこの通知標的１７５をマークする。

代替として、上記の３つの新しい属性は、既存のｏｎｅＭ２Ｍ仮想リソース＜ｎｏｔｉｆｉｃａｔｉｏｎＴａｒｇｅｔＳｅｌｆＲｅｆｅｒｅｎｃｅ＞を用いて実装され得る。換言すると、通知標的１７５は、その新しいステータスを含むペイロードとともに、ＵＰＤＡＴＥ動作要求を＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの＜ｎｏｔｉｆｉｃａｔｉｏｎＴａｒｇｅｔＳｅｌｆＲｅｆｅｒｅｎｃｅ＞に発行することができる。故に、サービス層１７１は、同じ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの「ｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ」属性を更新する。

図１８は、例示的ユーザインターフェースを図示する。サブスクライバ１７３（例えば、ｏｎｅＭ２Ｍ ＡＥまたはＭ２Ｍ端末デバイス１８）の視点から、ユーザインターフェース３２５が、表示され、ｎｏｔｉｆＲｅｃｏｒｄＲｅｑ（通知を記録することについての要件）、ｎｏｔｉｆＳｔａｔＲｅｑ（通知統計情報を計算することについての要件）、ｎｏｔｉｆＣｏｎｆｉｒｍＲｅｑ（通知確認についての要件）、およびｓｕｂＣｏｎｆｉｒｍＲｅｑ（サブスクリプション確認についての要件）等のパラメータを構成し、ｎｏｔｉｆＳｔａｔＩｎｆｏ（計算された通知統計情報）およびｎｏｔｉｆＴａｒｇｅｔＳｔａｔｕｓ（取得された通知標的１７５状態）についての結果を表示するために使用され得る。これらのパラメータは、本明細書に説明および定義されていることに留意されたい。同じユーザインターフェース３２５は、アプリケーションとしてサービス層１７１（例えば、ホスティングＣＳＥまたはＭ２Ｍゲートウェイデバイス１４）にも追加され得る。

図１９は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９０１（例えば、タッチスクリーンディスプレイ）は、表１から表１５のパラメータの値等のサブスクリプションおよび通知サービスに関連付けられたテキストをブロック９０２の中で提供し得る。別の例では、本明細書で議論されるステップのうちのいずれかの進捗度（例えば、送信されたメッセージまたはステップの成功）が、ブロック９０２の中に表示され得る。加えて、グラフィカル出力９０３が、ディスプレイインターフェース９０１上に表示され得る。グラフィカル出力９０３は、サブスクリプションおよび通知サービスに関連付けられたデバイスのトポロジ、本明細書で議論される任意の方法もしくはシステムの進捗度のグラフィカル出力等であり得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とりわけ、本明細書に説明されるような方法、システム、および装置は、サブスクリプションまたは通知サービスのための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のサブスクリプション要求を取得し（例えば、受動的に受信し、または能動的に読み出し）、サブスクライバデバイスによるリソースのイベント通知を受信する手段と、リソースを生成し、第１のサブスクリプション要求に基づいて通知メッセージを記録する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第２のサブスクリプション要求（例えば、後続のサブスクリプション要求）を取得し、発見基準に基づいて通知標的に関連付けられたイベント通知を読み出す手段と、発見基準が満たされる場合、通知メッセージを備えている応答を送信する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第２のサブスクリプション要求を取得し、発見基準に基づいて通知標的に関連付けられたイベント通知を読み出す手段であって、発見基準は、送信されており、かつ通知標的によって取得されたとして確認応答されていないメッセージの要求を備えている、手段と、発見基準が満たされる場合、通知メッセージを備えている応答を送信する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第２のサブスクリプション要求を取得し、発見基準に基づいて通知標的に関連付けられたイベント通知を削除する手段と、発見基準が満たされる場合、第２のサブスクリプション要求を確認する応答を送信する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第２のサブスクリプション要求を取得し、発見基準に基づいて通知標的に関連付けられた通知を削除する手段であって、発見基準は、ある期間中に送信されたメッセージを備えている、手段と、発見基準が満たされる場合、第２のサブスクリプション要求を確認する応答を送信する手段とを有する。第１のサブスクリプション要求は、ある期間中に発行される全通知を記録するための命令を含み得る。第１のサブスクリプション要求は、ある期間中に発行され、リストの中の通知標的に配信され、リストの中の条件によって生成される通知を記録するための命令を含み得る。第１のサブスクリプション要求は、ある一定の数が特定の通知標的に対して失敗したときに通知を記録するための命令を備えている。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、作成されるべき通知リソースの有効期限の指示を取得する手段とを有する。装置は、サービス層であり得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、サブスクライバから、第１のサブスクリプション要求を取得し、サブスクライバデバイスによるリソースのイベント通知を受信する手段であって、第１のサブスクリプション要求は、第１のサブスクリプション要求を確認するためにコンタクトされるべき通知標的を告げる第１のパラメータを備えている、手段と、第１のサブスクリプション要求に基づいて、メッセージを通知標的に送信する手段であって、メッセージは、サブスクライバの識別子、サブスクライブされたリソースの識別子、通知標的が通知を受信するための識別子、またはイベント通知基準を備えている、手段と、リソースを生成し、第１のサブスクリプション要求に基づいて通知メッセージを記録する手段とを有する。この段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で考慮される。

Claims (14)

1. サブスクリプションおよび通知サービスを伴う装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されたメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   サブスクライバデバイスによる第１のリソースのイベント通知を受信するための第１のサブスクリプション要求を取得することと、
   前記要求された第１のサブスクリプションを前記装置上の第２のリソースに記録することと、
   前記第１のサブスクリプション要求から取得されるイベント条件が満たされることに基づいて、
   前記イベント条件に関連付けられた通知メッセージを前記サブスクライバデバイスに伝送することと、
   前記イベント条件に関連付けられた前記通知メッセージを前記装置上の第３のリソースに記録することと、
   前記記録された通知メッセージを読み出すための通知要求を受信することと、
   前記通知要求に基づいて、応答を送信することであって、前記応答は、前記通知メッセージのコンテンツを備えている、ことと、
   発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
   前記発見基準が満たされる場合、前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記動作は、
   前記イベント通知がある期間中に生じたときに前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
   前記期間に対する前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
   をさらに含む、請求項１に記載の装置。
3. 前記動作は、
   発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することであって、発見基準は、送信されており、かつ前記通知標的によって取得されたとして確認されていないメッセージに対する要求を備えている、ことと、
   前記発見基準が満たされる場合、前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
   をさらに含む、請求項１に記載の装置。
4. 前記動作は、
   発見基準に基づいて通知標的に関連付けられた前記イベント通知を削除するための第２のサブスクリプション要求を取得することと、
   前記発見基準が満たされる場合、前記第２のサブスクリプション要求を確認する応答を送信することと
   をさらに含む、請求項１に記載の装置。
5. 前記動作は、
   発見基準に基づいて通知標的に関連付けられた前記イベント通知を削除するための第２のサブスクリプション要求を取得することであって、発見基準は、ある期間中に送信されたメッセージを備えている、ことと、
   前記発見基準が満たされる場合、前記第２のサブスクリプション要求を確認する応答を送信することと
   をさらに含む、請求項１に記載の装置。
6. 前記第１のサブスクリプション要求は、ある期間中に発行される全通知を記録するための命令を備えている、請求項１に記載の装置。
7. 前記第１のサブスクリプション要求は、ある期間中に発行され、リストの中の通知標的に配信され、リストの中の条件によって生成される通知を記録するための命令を備えている、請求項１に記載の装置。
8. 前記第１のサブスクリプション要求は、ある一定の数が特定の通知標的に対して失敗したときに通知を記録するための命令を備えている、請求項１に記載の装置。
9. 前記動作は、作成されるべき通知リソースの有効期限の指示を取得することをさらに含む、請求項１に記載の装置。
10. 前記装置は、サービス層である、請求項１に記載の装置。
11. 通知にサブスクライブする方法であって、前記方法は、
    サブスクライバデバイスによる第１のリソースのイベント通知を受信するための第１のサブスクリプション要求を取得することと、
    前記要求された第１のサブスクリプションを装置上の第２のリソースに記録することと、
    前記第１のサブスクリプション要求から取得されるイベント条件が満たされることに基づいて、
    前記イベント条件に関連付けられた通知メッセージを前記サブスクライバデバイスまたは通知標的に伝送することと、
    前記イベント条件に関連付けられた前記通知メッセージを前記装置上の第３のリソースに記録することと、
    前記記録された通知メッセージを読み出すための通知要求を受信することと、
    前記通知要求に基づいて、応答を送信することであって、前記応答は、前記通知メッセージのコンテンツを備えている、ことと、
    発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
    前記発見基準が満たされる場合、前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
    を含む、方法。
12. サービス層によって、前記通知がある期間中に生じたときに前記イベント通知を読み出すための第２のサブスクリプション要求を取得することと、
    前記サービス層によって、前記期間に対する前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
    をさらに含む、請求項１１に記載の方法。
13. サービス層によって、発見基準に基づいて通知標的に関連付けられた前記イベント通知を読み出すための第２のサブスクリプション要求を取得することであって、発見基準は、送信されており、かつ取得されたとして確認されていないメッセージに対する要求を備えている、ことと、
    前記発見基準が満たされる場合、前記通知メッセージを備えている前記第２のサブスクリプション要求への応答を送信することと
    をさらに含む、請求項１１または１２に記載の方法。
14. コンピュータプログラムを記憶しているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットの中にロード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、前記データ処理ユニットに請求項１１〜１３のいずれかに記載の方法を実行させるように適合されている、コンピュータ読み取り可能な記憶媒体。