JP6762368B2 - サービス層における要求処理 - Google Patents

Description

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

開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ２．６．０）は、「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層は、異なる「バーティカル」Ｍ２Ｍシステムおよびアプリケーションによって利用されることができる「ホリゾンタル」サービスを提供する。

ＣＳＥは、図１に示されるような参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一のサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。

ＣＳＥは、「発見」および「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図２は、ｏｎｅＭ２Ｍリリース１によって現在定義されているＣＳＦを図示する。

ｏｎｅＭ２Ｍは、コンテンツインスタンスが記憶されるためのコンテナを表す＜ｃｏｎｔａｉｎｅｒ＞リソースを定義する。ｏｎｅＭ２Ｍは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースも定義する。＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースは、＜ｃｏｎｔａｉｎｅｒ＞の子リソースであり、ｏｎｅＭ２Ｍサービス層の中にコンテンツを記憶するためにアプリケーションによって使用される。＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞の作成時にＣＳＥがタイムスタンプで構成するｃｒｅａｔｉｏｎＴｉｍｅ属性をサポートする。＜ｃｏｎｔａｉｎｅｒ＞リソースは、＜ｃｏｎｔａｉｎｅｒ＞の中に記憶された最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を読み出す目的のためにＲＥＴＲＩＥＶＥ要求を用いて標的化されることができる＜ｌａｔｅｓｔ＞子リソースもサポートする。

ｏｎｅＭ２Ｍは、＜ｃｏｎｔａｉｎｅｒ＞リソースの＜ｌａｔｅｓｔ＞子リソースを定義する。読み出し要求が＜ｌａｔｅｓｔ＞リソースをアドレスするとき、ホスティングＣＳＥは、＜ｃｏｎｔａｉｎｅｒ＞リソースの全ての既存の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソース間の最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースの読み出しとして、要求を処理する。

ｏｎｅＭ２Ｍは、ｃｒｅａｔｅｄＡｆｔｅｒフィルタ基準条件を定義し、この条件は、読み出しまたは発見結果をフィルタ処理するために読み出しまたは発見要求の中に含まれることができる。例えば、特定のリソースを標的化する読み出し要求とともに使用される場合、規定ｃｒｅａｔｅｄＡｆｔｅｒ時間よりも遅いｃｒｅａｔｉｏｎＴｉｍｅを有するこの標的化リソースの子リソースは、読み出し応答の中に含まれたそれらの表現を有するであろう。同様に、特定のリソースを標的化する発見要求とともに使用される場合、規定ｃｒｅａｔｅｄＡｆｔｅｒ時間よりも遅いｃｒｅａｔｉｏｎＴｉｍｅを有するこの標的化リソースの子リソースは、読み出し応答の中に含まれたそれらのＵＲＩを有するであろう。

例示的ｏｎｅＭ２Ｍ ＡＥ ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性を図示する図３を参照すると、ｏｎｅＭ２Ｍは、＜ＡＥ＞リソースタイプのためのｐｏｉｎｔＯｆＡｃｃｅｓｓを定義する。属性は、下層ネットワークによって提供されるトランスポートサービスを介し、Ｍｃａ参照点を経由して、登録されたＡＥと通信するためのアドレスのリストとして定義される。属性は、ｘｓ：ｓｔｒｉｎｇのリストとして定義され、リストの中の各ｐｏｉｎｔＯｆＡｃｃｅｓｓエントリは、下層トランスポートプロトコル方式（例えば、ｈｔｔｐ：／／）と、ＩＰアドレスおよびポート、または完全修飾ドメイン名（ＦＱＤＮ、例えば、ｍｙＡＥ．ｃｏｍ）とを含む文字列として表される。例えば、ｈｔｔｐ：／／１７２．２５．０．４３：８０００またはｈｔｔｐ：／／ｍｙＡＥ．ｃｏｍ。

ｏｎｅＭ２Ｍ再標的化は、ＣＳＥが、要求を生成または受信することと、要求のＵＲＩを評価し、それがＣＳＥによってホストされるリソースを標的化していないことを決定することと、そして、それが処理されるべき別のエンティティ（例えば、ＡＥまたは別のＣＳＥ）に要求を標的化することとを伴う。ｏｎｅＭ２Ｍは、現在、それがＡＥに再標的化することができる要求のタイプに制限を有する。ｏｎｅＭ２Ｍは、以下の３つのタイプの通知をＡＥに再標的化することをサポートする：１）ＡＥが到達可能であり、通知を受信することができることを検証する通知。これは、新しいサブスクリプションの作成中、および、ＡＥがサブスクリプションのための通知を受信するように構成されるが、そのＡＥがサブスクリプションを作成したＡＥではなかった場合、ＣＳＥによって行われる；２）サブスクリプションのための通知イベントが検出されており、ＡＥが所与のサブスクリプションのための通知を受信するように構成されることをシグナリングする通知；３）ＡＥが作成したサブスクリプションが削除されていることをシグナリングする通知。

トンネルアンカポイント（ＴＡＰ）と称される知的トンネリング機構を定義することによって、異なるサービス層技術を互いに相互作動させるための方法が定義されている。一例では、ＴＡＰは、アプリケーションリソースまたはコンテナリソース等の既存のリソースのうちの１つを使用することによって、リソース構造内でサポートされ得る。ｆｏｒｗａｒｄｉｎｇアドレス属性が、コンテナリソースのために定義され得る。図４は、コンテナリソースのための転送アドレス属性に関連してＥＴＳＩ Ｍ２Ｍトンネルアクセスポイントを使用する例示的例証である。

図５は、例示的ＣｏＲＥミラーサーバアーキテクチャを図示する。ＣｏＲＥ Ｍｉｒｒｏｒ Ｓｅｒｖｅｒ−ＩＥＴＦ ｄｒａｆｔ−ｖｉａｌ−ｃｏｒｅ−ｍｉｒｒｏｒ−ｓｅｒｖｅｒ−０１（２０１３年４月１０日）は、制約されたＲＥＳＴｆｕｌ（ＣｏＲＥ）ミラーサーバ（ＭＳ）の概念を定義する。リソース制約されたＩｏＴデバイス（スリーピーエンドポイント−ＳＥＰ）は、ミラーサーバ内にそれらのリソースの表現を記憶して維持し、ミラー化リソース表現を使用して、それらの代わりにミラーサーバサービス要求を有することができる。これは、モノのインターネット（ＩｏＴ）デバイスが、デバイスのバッテリを消耗することまたはローカルエリアデバイスネットワークを混雑させること等の有害な副作用を及ぼし得る要求で溢れさせられることを防止することができる。

本明細書では、要求の鮮度ベースの処理へのサポートを可能にするために使用され得る方法、システム、およびデバイスが開示される。鮮度ベースの処理は、サービス層が、それがホストする記憶されたコンテンツ（例えば、リソース表現）の古さを調査し、規定鮮度要件で読み出しまたは発見要求を満たすために十分に新鮮であるかどうかを決定することを伴い得る。新鮮ではない場合、サービス層は、アプリケーションにコンタクトし、コンテンツをリフレッシュし得る。加えて、鮮度ベースの処理は、サービス層が、コマンド指向型更新要求の意味状態を調査し、その状態がサービス層によって処理される事前コマンドに対して新鮮であるかどうかを決定することも含み得る。例えば、サービス層は、更新要求の意味コンテンツ（例えば、ドアを開錠する）に対して特定のアプリケーションを制御することに関連付けられる記憶されたコンテンツ（例えば、ドアが施錠されている）を比較し、それが同一であるかどうかを決定し得る。新鮮である場合、サービス層は、更新要求をアプリケーションに再標的化し、それにコマンド（例えば、ドアを開錠する）を実施させ得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
サービス層のためのコンテンツの鮮度を管理するための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、記憶された実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
要求アプリケーションからメッセージを受信することであって、前記メッセージは、サービスに関連付けられたコンテンツを取得するための要求と、前記サービスに関連付けられた前記コンテンツのための鮮度期間とを備えている、ことと、
前記メッセージの中の要件に基づいて、前記コンテンツの前記鮮度期間が許容閾値期間外であることを決定することと、
前記コンテンツの前記鮮度期間が前記許容閾値期間外であることを決定することに応答して、
非ブロック応答を前記要求アプリケーションに送信することと、
ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、前記許容閾値期間内である前記サービスの更新されたコンテンツを取得することと
を含む動作を前記プロセッサに達成させる、装置。
（項目２）
前記動作は、複数の他のサービスに関連付けられた前記コンテンツのための鮮度期間と共に前記サービスに関連付けられた前記コンテンツのための前記鮮度期間の分析に基づいて、前記コンテンツが前記装置によって更新される必要があるスケジュールを決定することをさらに含む、項目１に記載の装置。
（項目３）
前記コンテンツソースアプリケーションへの前記要求メッセージは、前記コンテンツが前記装置によって更新される必要があるスケジュールを備えている、項目１−２のいずれか１項に記載の装置。
（項目４）
前記非ブロック応答は、コールバックアドレスを備え、前記コールバックアドレスは、前記コンテンツが利用可能になったときに前記鮮度期間内のコンテンツを受信するためにサブスクライブするために、前記要求アプリケーションによって使用される、項目１−３のいずれか１項に記載の装置。
（項目５）
前記コンテンツソースアプリケーションへの前記要求メッセージは、前記鮮度期間に対応する作成後パラメータを備えている、項目１−４のいずれか１項に記載の装置。
（項目６）
前記動作は、複数の他のメッセージの中の関連付けられた前記コンテンツのための鮮度期間と共に前記メッセージの中の前記コンテンツのための前記鮮度期間の分析に基づいて、前記コンテンツが前記装置によって更新される必要があるスケジュールを決定することをさらに含む、項目１−５のいずれか１項に記載の装置。
（項目７）
前記ポイントオブコンタクト情報は、ユニフォームリソース識別子を備えている、項目１−６のいずれか１項に記載の装置。
（項目８）
サービス層のためのコンテンツの鮮度を管理する方法であって、前記方法は、
要求アプリケーションからメッセージを受信することであって、前記メッセージは、サービスに関連付けられたコンテンツを取得するための要求と、前記サービスに関連付けられた前記コンテンツのための鮮度期間とを備えている、ことと、
前記メッセージの中の要件に基づいて、前記コンテンツの前記鮮度期間が許容閾値期間外であることを決定することと、
前記コンテンツの前記鮮度期間が前記許容閾値期間外であることを決定することに応答して、
非ブロック応答を前記要求アプリケーションに送信することと、
ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、前記許容閾値期間内である前記サービスの更新されたコンテンツを取得することと
を含む、方法。
（項目９）
複数の他のサービスに関連付けられた前記コンテンツのための鮮度期間と共に前記サービスに関連付けられた前記コンテンツのための前記鮮度期間の分析に基づいて、前記コンテンツがサービス層デバイスによって更新される必要があるスケジュールを決定することをさらに含む、項目８に記載の方法。
（項目１０）
前記コンテンツソースアプリケーションへの前記要求メッセージは、前記コンテンツがサービス層デバイスによって更新される必要があるスケジュールを備えている、項目８または９のいずれか１項に記載の方法。
（項目１１）
前記非ブロック応答は、コールバックアドレスを備え、前記コールバックアドレスは、前記コンテンツが利用可能になったときに前記鮮度期間内のコンテンツを受信するためにサブスクライブするために、前記要求アプリケーションによって使用される、項目８−１０のいずれか１項に記載の方法。
（項目１２）
前記コンテンツソースアプリケーションへの前記要求メッセージは、前記鮮度期間に対応する作成後パラメータを備えている、項目８−１１のいずれか１項に記載の方法。
（項目１３）
複数の他のメッセージの中の関連付けられた前記コンテンツのための鮮度期間と共に前記メッセージの中の前記コンテンツのための前記鮮度期間の分析に基づいて、前記コンテンツがサービス層デバイスによって更新される必要があるスケジュールを決定することをさらに含む、項目８−１２のいずれか１項に記載の方法。
（項目１４）
前記ポイントオブコンタクト情報は、ユニフォームリソース識別子を備えている、項目８−１３のいずれか１項に記載の方法。
（項目１５）
コンピュータ読み取り可能な媒体を備えているコンピュータプログラム製品であって、前記コンピュータ読み取り可能な媒体は、プログラム命令を備えているコンピュータプログラムを有し、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、項目８−１４のいずれかに記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータプログラム製品。

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

図１は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図２は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図３は、例示的ｏｎｅＭ２Ｍ ＡＥ ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性を図示する。 図４は、例示的ＥＴＳＩ Ｍ２Ｍトンネルアクセスポイントを図示する。 図５は、例示的ＣｏＲＥミラーサーバアーキテクチャを図示する。 図６は、鮮度ベースのコンテンツ読み出しのための例示的ネットワークを図示する。 図７は、例示的鮮度ベースのコンテンツ読み出しタイムラインを図示する。 図８は、鮮度ベースの要求再標的化のための例示的ネットワークを図示する。 図９は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。 図１０は、例示的鮮度ベースのコンテンツ読み出しメッセージフローを図示する。 図１１は、例示的鮮度ベースのリソース発見メッセージフローを図示する。 図１２は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。 図１３は、ＯｎｅＭ２Ｍにおけるサービス層鮮度機構の例示的アーキテクチャを図示する。 図１４は、例示的ｏｎｅＭ２Ｍ鮮度ベースのコンテンツ読み出しメッセージフローを図示する。 図１５は、例示的ｏｎｅＭ２Ｍ鮮度ベースのリソース発見メッセージフローを図示する。 図１６は、例示的ｏｎｅＭ２Ｍ鮮度ベースのデバイストリガメッセージフローを図示する。 図１７は、例示的ｏｎｅＭ２Ｍ鮮度ベースの再標的化メッセージフローを図示する。 図１８は、例示的ＣｏＲＥミラーサーバ鮮度ベースのコンテンツ読み出しメッセージフローを図示する。 図１９は、例示的ｏｎｅＭ２Ｍ ｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐ属性を図示する。 図２０は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。 図２１Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２１Ｂは、図２１Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２１Ｃは、図２１Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２１Ｄは、図２１Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

本明細書では、例えば、サービス層内の要求処理のために使用され得る方法、システム、およびデバイスが開示される。鮮度ベースの処理は、サービス層が、それがホストする記憶されたコンテンツ（例えば、リソース表現）の古さを調査し、規定鮮度要件を伴う読み出しまたは発見要求を満たすために、それが十分に新鮮であるかどうかを決定することを伴い得る。

従来のＭ２Ｍ／ＩｏＴサービス層技術は、アプリケーションが、アプリケーションのコンテンツ鮮度要件を考慮する様式で、サービス層によってホストされるコンテンツを発見すること、または読み出すことを効果的に可能にしない。従来のＭ２Ｍ／ＩｏＴサービス層技術は、アプリケーションが、要求の鮮度を考慮する様式で、１つのアプリケーションから別のアプリケーションに要求を再標的化することも効果的に可能にしない。これらの欠点は、サービス層技術が、とりわけ、本明細書で議論されるユースケースのタイプを効果的にサポートすることを妨げる。このサポートが無いことは、妥協し、古くなったデータを使用すること、またはさらに悪いことに、それらが選好または要求する新鮮なデータなしで済ませることを決定する必要があるＩｏＴアプリケーションをもたらし得る。このサポートが無いことは、増加した数のコンテンツ読み出し、コンテンツ発見、ならびに他のタイプの要求が開始され、またはデバイスに再標的化される場合、ＩｏＴデバイスへのオーバーヘッドの追加をもたらし得る。

従来のＭ２Ｍ／ＩｏＴサービス層技術に照らして、より効果的にされ得るか、または可能にされ得る分野のより具体的な例が、以下で議論される。第１の例では、コンテンツソーシングアプリケーション（以降ではコンテンツソーシングアプリ）がポイントオブコンタクト情報をサービス層に提供することを可能にするサポートが無いこともある。ポイントオブコンタクト情報は、サービス層が、コンテンツ要求アプリケーション（以降ではコンテンツ要求アプリ）によって発行され入って来るコンテンツ読み出しまたは発見要求にサービス提供するために選好もしくは要求されるコンテンツの新鮮なバージョンを検出する場合において、コンテンツソーシングアプリにコンタクトする目的のために使用され得る。コンテンツソーシングアプリが、サービス層ホスト型リソースを作成することによってコンテンツを提供するアプリケーションである一方、コンテンツ要求アプリは、コンテンツソーシングアプリによって作成されるサービス層ホスト型リソースを読み出すことによってコンテンツを要求するアプリケーションである。

第２の例では、要求受信アプリケーション（以降では要求受信アプリ）が、要求開始アプリケーション（以降では要求開始アプリ）から生じ、サービス層によって新鮮であると決定される要求を要求受信アプリのポイントオブコンタクトに再標的化するために使用されることができる、ポイントオブコンタクト情報をサービス層に提供することを可能にするサポートが無いこともある。そのような特徴がないと、要求受信アプリおよび要求開始アプリは、単一のエンドツーエンド要求および応答交換を実施するために、複数のサービス層サブスクリプションならびに通知を伴う間接通信方式に依拠し得る。要求受信アプリが、サービス層再標的化要求を介して要求開始アプリから要求を間接的に受信し得る、アプリケーションである一方、要求開始アプリは、サービス層リソースを介して要求を再標的化することを介して、別のアプリケーションへの要求を開始するアプリケーションである。

第３の例では、アプリケーション（すなわち、アプリ）が、サービス層リソースにサブスクライブし、サービス層から、コンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれた他のタイプの要求を受信することを可能にするサポートが無いこともある。同様に、アプリが、対応するコンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれたサービス層に戻る他のタイプの応答を返すことを可能にするサポートが無いこともある。第４の例では、サービス層が、受信されたコンテンツ読み出し、コンテンツ発見、または他のタイプの要求をサービス提供されるべきアプリに再標的化し、次いで、そのアプリから戻る応答を受信すると、結果のローカルコピーを作成して維持し、将来の要求にサービス提供することを支援し、かつ処理される要求の履歴および追跡情報を維持することを可能にするサポートが無いこともある。第５の例では、サービス層が、要求を再標的化する権限を与えられたエンティティ、再標的化されることを可能にされる要求のタイプ、要求が再標的化されることを可能にされるスケジュールされた時間、および再標的化された要求の中に含まれることを可能にされるリソースの属性等の規則を定義する、所与のリソースのための再標的化ポリシをサポートすることを可能にするサポートが無いこともある。

以下は、とりわけ、より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る機構である。第１の例示的機構は、サービス層が、コンテンツ要求アプリによって発行され入って来るコンテンツ読み出しまたは発見要求にサービス提供するためにコンテンツの新鮮なバージョンが所望されることを検出した場合において、コンテンツソーシングアプリにコンタクトする目的のために使用されることができるポイントオブコンタクト情報を、コンテンツソーシングアプリがサービス層に提供することを可能にし得る。ポイントオブコンタクトは、とりわけ、絶対ＵＲＩ、相対ＵＲＩ、またはｏｎｅＭ２Ｍリソース識別子等のいくつかの異なるフォーマットでフォーマットされ得る。第２の例示的機構は、サービス層によってホストされるバージョンが古すぎて、コンテンツ要求アプリによって発行されるコンテンツ読み出しまたは発見要求内で定義される規定鮮度を満たすことができない場合、サービス層がコンテンツ読み出し要求をコンテンツソーシングアプリに送信し、コンテンツの新鮮なバージョンを取得する、プロシージャを含み得る。この要求は、コンテンツを直接読み出し得るか、または、要求は、サービス層がリフレッシュされることを所望するサービス層リソースのアドレスを含み、サービス層がリフレッシュされたコンテンツを要求もしくは選好する優先度またはスケジュールされた時間も含み得る。応答して、コンテンツソーシングアプリは、それがサービス層にコンテンツの新鮮なバージョンを提供し、規定アドレスへの更新を実施し得るときを適切にスケジュールし、優先し得る。

より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る機構を継続して参照すると、第３の例示的機構は、下層ネットワークデバイストリガ機能によって配信されるサービス層デバイストリガ要求の中に対応する情報要素を埋め込むことによって、サービス層がコンテンツ読み出しまたは他のタイプの要求をアプリに送信することを可能にし得る。第４の例示的機構は、アプリが、サービス層リソースにサブスクライブし、サービス層から、コンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれた他のタイプの要求を受信することを可能にし得る。同様に、アプリが、対応するコンテンツ読み出し、コンテンツ発見、または通知応答内に埋め込まれたサービス層に戻る他のタイプの応答を返すことを可能にするサポートがあり得る。第５の例示的機構は、要求受信アプリが、要求開始アプリから生じ、サービス層によって新鮮であると決定される要求を要求受信アプリのポイントオブコンタクトに再標的化するために使用され得る、ポイントオブコンタクト情報をサービス層に提供することを可能にし得る。第６の例示的機構は、サービス層が、受信されたコンテンツ読み出し、コンテンツ発見、または他のタイプの要求をサービス提供されるべきアプリに再標的化し、そして、アプリから戻る応答を受信すると、結果のローカルコピーを作成して維持し、将来の要求にサービス提供することを支援し、かつ処理される要求の履歴および追跡情報を維持することを可能にし得る。

より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る本明細書に開示される機構を継続して参照すると、第７の例示的機構は、サービス層が、サービス層が入って来る要求を処理すべきアプリに再標的化する（例えば、コンテンツの新鮮なバージョンを取得する）必要があるという検出等の非ブロック様式で入って来る要求にサービス提供するためのトリガ条件として使用することを可能にし得る。非ブロック様式で再標的化される要求にサービス提供するとき、サービス層は、新鮮なコンテンツが利用可能であろう推定時間を含む確認応答を要求側に提供し得る。第８の例示的機構は、サービス層が、要求を再標的化する権限を与えられているエンティティ、再標的化されることを可能にされる要求のタイプ、要求が再標的化されることを可能にされるスケジュールされた時間、および再標的化された要求の中に含まれることを可能にされるリソースの属性等の規則を定義する所与のリソースのためのアプリ再標的化ポリシをサポートすることを可能にし得る。

鮮度ベースのコンテンツ発見、コンテンツ読み出し、および再標的化概念等のより効果的なサービス層要求を可能にすること、またはそれを提供することを支援し得るｏｎｅＭ２Ｍ例も本明細書に開示される。加えて、鮮度ベースのコンテンツ発見、コンテンツ読み出し、および再標的化概念等のためのＣｏＲＥミラーサーバ例が本明細書に開示される。

以下は、サービス層に関連付けられる要求処理のための方法、デバイス、またはシステムに関する追加の洞察を与え得る例示的ユースケースの議論である。図６は、鮮度ベースのコンテンツ読み出しのための例示的ネットワークを図示する。図６に示されるように、医師に関連付けられるアプリ１２１は、患者の家庭内の患者の健康測定値（例えば、血中インスリン、血圧、脈拍酸素、および心拍数）を遠隔で監視している。これらの測定値は、患者に関連付けられる１つ以上の医療デバイス１２３によって収集される。医療デバイス１２３は、患者に装着され得、患者の家庭内のゲートウェイに接続し得、ゲートウェイは、種々の患者ゲートウェイおよびそれらの接続されたデバイスから健康測定値を収集するサービス層１２２（例えば、クラウドベースの健康サービスプラットフォーム）に接続し得る。アプリ１２１は、サービス層１２２にアクセスして医師の患者の健康測定値を読み出す、ウェブベースのアプリケーションであり得る。

ゲートウェイならびにクラウドサービスプラットフォームにおいて、ＩｏＴソフトウェアサービスがホストされ得る。これらのサービスは、クエリを行い、特定の患者の健康測定値を発見する能力を提供すること、ネットワークを経由して送信中の患者の健康測定値を保護すること、およびネットワークを横断してより効率的に送信されてスケジュールされ得る単一のメッセージに複数の健康測定値を集約し、ネットワーク負荷、輻輳、ならびに費用を最小化すること等の機能性を提供する。

自分の患者を効果的に監視するために、医師は、クエリを行い、規定鮮度を伴う所与の患者の健康測定値にアクセスする能力を選好し得る（例えば、測定値は、規定期間よりも古くてはならない）。測定のタイプおよび特定の患者に応じて、この鮮度期間は、変動し得る。医師は、従来のシステムを使用するとき、デバイスを伴う患者がたまたま測定し、自分のゲートウェイまたはクラウドにアップロードした健康測定値のみにアクセスすることに限定され得る。従来のシステムを使用するとき、医師の鮮度選好に応じて、これらの測定値のうちのいくつかが医師の必要性のためには古すぎ、医師が、取り込まれてアップロードされる次のスケジュールされたセンサ測定を待つ以外の選択肢を有していないこともある可能性がある。これが起こる時間まで、他の患者センサからの他の測定データは、古くなり、全体としての患者データの分析を困難または信頼できないものにし得る。

より良好な介護の質を患者に提供するとともに、自分自身が自分自身の時間をより良好に管理することを可能にするために、医師が選好するであろうことは、このユースケースでは、新しい測定値がアップロードされることを待つ必要なく、自分の鮮度選好を満たす健康測定値へのアクセスを有することである。特定の患者デバイス１２３、またはゲートウェイ、もしくは両方をトリガし、医師の規定鮮度選好を満たす新鮮な健康測定値が、医師のアプリケーション１２１がアクセスするためにクラウド内でまだ利用可能ではないとき、それをサービス層１２２に提供する強化ＩｏＴサービスをサポートする機構が、本明細書でさらに議論される。このタイプの機能性を有することは、医師が、拡張可能性、利用可能性、費用等のサービス層１２２で健康測定値をホストすることの多くの利益を依然として同時に活用しながら、自分の患者の健康測定値への新鮮なオンデマンドアクセスを効果的に有することを可能にする。サービス層１２２内の既存の測定値が特定の要求の鮮度基準をまだ満たさないとき、新鮮な測定値を提供するようにデバイスまたはゲートウェイをトリガすることによって、ネットワークを経由して送信される必要がある要求の数の節約、ゲートウェイまたはデバイスへのオーバーヘッドの削減をもたらし得る。対照的に、各要求のために測定値を提供する従来のデバイス（例えば、エンドデバイスまたはゲートウェイデバイス）のトリガは、ネットワークを経由してより多くの要求が送信され、デバイへのオーバーヘッドが追加されることをもたらし得る。このオーバーヘッドを最小化することは、本質的にリソース制約もされ得る潜在的に多数のデバイスを伴うＩｏＴタイプ展開において重要であり得る。ＩｏＴサービストリガは、新鮮な読み取り値がクラウド内で利用可能ではない場合を検出し、ひいては、後続の要求を用いてデバイスを標的化し、新鮮な読み取り値を読み出すための負担をアプリケーション（例えば、アプリ１２１）に課さないことによって、あるレベルの効率および最適化を可能にする。

図７は、例示的鮮度ベースのコンテンツ読み出しタイムラインを図示する。図７は、この鮮度ベースのコンテンツ読み出し方式の潜在的節約をより詳細に強調表示する例を提供する。この例では、医療センサデバイス１３１は、一番上の線に沿って示されるように、３時間毎に１回、センサ読み取り値をパブリッシュする。示されるような丸は、医療センサデバイス１３１のパブリッシュされたセンサ読み取り値を示す。これらのセンサ読み取り値は、次いで、異なるアプリ（アプリ１３２、アプリ１３３、アプリ１３４）によって読み出される。アプリ１３２および１３３は、わずかに異なるオフセットを伴って１時間に１回、センサ読み取り値を周期的に読み出し、センサ読み取り値が３０分よりも古くあることができないという鮮度選好を有する。図７の三角は、クラウドにキャッシュされた新鮮なバージョンがないので、医療センサデバイス１３１自体からセンサ読み取り値を読み出すことを要求する動作を示す。図７の四角は、医療センサデバイス１３１からセンサ読み取り値を読み出すことを要求しない動作を示すが、代わりに、十分に新鮮であるキャッシュされたセンサ読み取り値が、クラウドから取得され得る。アプリ１３４は、センサ読み取り値を散発的に読み出し得、センサ読み取り値が１０分よりも古くあることができないという鮮度選好を有する。例は、センサ自体へのアクセスを要求するもの（前述の正方形）と対比して、クラウドでホストされるセンサ読み取り値（前述の三角）によってサービス提供され得る、読み出し要求を強調表示する。この例から、２６個のうちの１７個の読み取り値が、クラウドでホストされるキャッシュされたセンサ読み取り値によってサービス提供され得、２６個のうちの９個は、クラウド内のキャッシュされたバージョンが入って来る要求にサービス提供するために十分に新鮮ではないので、アクセスされているセンサによってサービス提供される。これは、ありとあらゆる読み取り値についてセンサに直接アクセスすることに対する鮮度ベースの読み出しの利益を例証する。鮮度ベースの読み出しがないと、この例における要求のうちのいくつかは、入って来る要求の要件を満たした新鮮なセンサ読み取り値が無いことに起因して、サービス（すなわち、クラウド）によって拒否されたであろう。故に、鮮度ベースの読み出しは、それらが選好する新鮮なセンサ読み取り値をアプリに同時に提供しながら、センサおよびネットワークへのオーバーヘッドを削減し得る。

図８は、鮮度ベースの要求再標的化のための例示的ネットワークを図示する。図８に示されるように、制御アプリ１４１は、サービス層１４２と通信可能に接続される。サービス層１４２は、ビル内ネットワーク１４３と通信可能に接続される。ビル内ネットワーク１４３は、とりわけ、電子ドア、電子サーモスタット、センサ等のいくつかの異なるデバイスに接続されるゲートウェイ１４６を有し得る。制御アプリ１４１は、ビル内ネットワーク１４３内のデバイスを遠隔で制御する（例えば、明かりを点灯および消灯する、サーモスタットを制御する、ならびにドアを施錠および開錠する）ために使用され得る。サービス層１４２は、ビル内ネットワーク１４３のデバイスの遠隔管理および制御を可能にするクラウドベースのビル管理システムであり得る。ゲートウェイ１４６ならびにサービス層１４２は、先進ＩｏＴソフトウェアサービスをホストし得る。これらのサービスは、クエリを行い、特定のデバイスを発見する能力を提供すること、ネットワークを経由して送信中である間にコマンド（例えば、ドア施錠および開錠コマンド）を保護すること、またはＩｏＴソフトウェアサービスが処理する要求を介して特定のデバイスに発行されるコマンドの意味認識および意味等の機能性を提供し得る。制御アプリ１４１（例えば、ウェブベースの制御アプリ）を使用して、ビル内ネットワーク１４３内のデバイスは、アクセスおよび制御され得る。例えば、ビル内ネットワーク１４３に関連付けられるドアは、制御アプリ１４１から、サービス層１４２を通して、ビル内ネットワーク１４３のゲートウェイまで、最終的には、ドアロックアクチュエータデバイス自体（図示せず）までコマンドを開始することによって、遠隔で施錠および開錠され得る。

図８を継続して参照すると、ネットワークならびにゲートウェイおよびデバイスへのオーバーヘッドを最小化するために、要求がデバイスの意味状態の変化をもたらす（例えば、開錠されたドアを施錠する、または施錠されたドアを開錠する）であろう場合にのみ、制御アプリ１４１からビル内ネットワーク１４３のゲートウェイおよびデバイスまで開始される要求を送信することが望ましくあり得る。意味認識能力を有し、入って来るコマンドタイプ要求を処理し、コンテンツ意味論の視点から、それらがデバイスの状態の変化をもたらすであろうように、新鮮である要求を検出することができ、これらのコマンドのみをビル内ネットワーク１４３のゲートウェイおよびデバイスまで転送する、サービス層１４２内の強化ＩｏＴサービスをサポートすることが望ましくあり得る。本質的に古く、ビル内ネットワーク１４３のデバイスの状態の変化をもたらすことが予想されない要求は、サービス層１４２内のＩｏＴサービスによってフィルタ処理され得、ビル内ネットワーク１４３のゲートウェイおよびデバイスに送信されない。このオーバーヘッドを最小化することは、本質的にリソース制約でもあり得る潜在的に多数のデバイスを伴うＩｏＴタイプ展開で重要であり得る。ＩｏＴサービスにおける記憶された状態が、ビル内ネットワーク１４３の実際のデバイスの状態と同期しなくなる（例えば、ドアが施錠されているが、ＩｏＴサービスは、それが開錠されていると言う）場合に対して、次いで、この提案される鮮度ベースのフィルタリング機能性をオーバーライドする機構を有することが可能であることに留意されたい。例えば、サービス層１４２がドアを開錠するように５つの連続要求を受信した場合、たとえサービス層内の記憶された状態が、コマンドが新鮮ではないことを示したとしても、サービス層１４２は、要求をデバイスに転送し得る。これは、例えば、サービス層１４２への特定のタイプの要求の数、特定の要求以降の期間、オーバーライドメッセージ、または前述の組み合わせに基づいて、トリガされ得る。

図９は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。図９は、この鮮度ベースの要求再標的化方式の潜在的節約をより詳細に強調表示する例を提供する。ステップ１４９では、ビル内ネットワーク１４３と通信可能に接続されるドアは、施錠状態にある。ローカル要求が、ビル内ネットワーク１４３のドアを施錠状態にしていることもある。ステップ１５０では、メッセージが、ビル内ネットワーク１４３から送信され、ビル内ネットワーク１４３内のドアの施錠状態を示す。換言すると、ドアロックの状態が、サービス層１４２（例えば、クラウド）にパブリッシュされ、ドアロックの状態とサービス層１４２との間の同期化を保つ。ステップ１５１では、制御アプリ１４１は、ビル内ネットワーク１４３のドアを開錠する要求をサービス層１４２に送信する。ステップ１５１の要求は、ゲートウェイおよびドアロックに再標的化され、ドアを開錠する。これは、施錠されているドアを開錠するように要求しているので、（ステップ１５２で）要求が新鮮と見なされるので行われる。ステップ１５３では、ビル内ネットワーク１４３のドアは、ステップ１５１の要求に基づいて施錠される。ステップ１５４では、メッセージが、サービス層１４２に送信され、ドアが施錠されていることを示し、ステップ１５５でサービス層１４２において保存される。ステップ１５４では、制御アプリ１４１は、ステップ１５１で要求されるようにドアが施錠されているという確認を受信し得る。ステップ１５５およびステップ１５７では、制御アプリ１４４ならびに制御アプリ１４５は、それぞれ、ビル内ネットワーク１４３のドアが施錠されることを要求する。ステップ１５６およびステップ１５８では、制御アプリ１４４ならびに制御アプリ１４５は、それぞれ、すでに開錠されているドアを開錠しようとしているので、ステップ１５５およびステップ１５７における要求が古いことを示す応答を受信する。この場合、ドアロックの状態を維持するサービス層１４２は、これらの要求をフィルタ処理し、それらをビル内ネットワーク１４３のゲートウェイまたはドアロックに転送しない。ステップ１５９では、制御アプリ１４１は、ビル内ネットワーク１４３のドアを施錠する要求を送信する。ステップ１５９の要求は、ゲートウェイおよびドアロックに再標的化され、（ステップ１６０で）要求が新鮮と見なされるので、開錠されたドアを施錠する。ステップ１６１では、ドアは、施錠され、応答は、（ステップ１６２で）サービス層１４２に送信され、サービス層１４２において保存され、制御アプリ１４１に転送される。鮮度ベースの標的化は、ビル内ネットワーク１４３のデバイスと直接通信し、要求をビル内ネットワーク１４３自体のデバイスまで送信した場合と同一の機能性を制御アプリ１４１、制御アプリ１４４、および制御アプリ１４５に同時に提供しながら、デバイスおよびネットワークへのオーバーヘッドを削減し得る。

図９−図１２および図１４−図１８等の本明細書に図示されるステップを行うエンティティは、論理エンティティであり得ることが理解される。ステップは、図２１Ｃまたは図２１Ｄに図示されるもの等のデバイス、サーバ、もしくはコンピュータシステムのメモリの中に記憶され、そのプロセッサ上で実行し得る。例では、Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴うが、図１０のコンテンツソーシングアプリ２０２またはコンテンツ要求アプリが、図２１ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１０のサービス層２０４は、図２１ＡのＭ２Ｍゲートウェイデバイス１４またはＭ２Ｍサービスプラットフォーム２２上に常駐し得る。

図１０は、例示的鮮度ベースのコンテンツ読み出しメッセージフローを図示する。方法は、サービス層２０４がそのようなコンテンツをホストしない場合でさえも、コンテンツ要求アプリ２０６が、コンテンツ要求アプリ２０６の規定鮮度選好を満たすコンテンツをサービス層２０４から読み出すことを可能にする。図１０のメッセージフローは、オンザフライ機構が、要求されたコンテンツが古いとき、または存在しないときをサービス層２０４が検出することを可能にし、新鮮なバージョンのために対応するコンテンツソーシングアプリ２０２にコンタクトすることを可能にする。ステップ２１０では、コンテンツソーシングアプリ２０２およびコンテンツ要求アプリ２０６は、認証し、サービス層２０４に登録する。コンテンツ要求アプリ２０６は、次いで、利用可能なコンテンツソーシングアプリ２０２を発見する。

図１０を継続して参照すると、ステップ２１１では、コンテンツソーシングアプリ２０２は、ポイントオブコンタクト情報（例えば、ＵＲＩ）をサービス層２０４にパブリッシュする。コンテンツソーシングアプリ２０２は、１つ以上のポイントオブコンタクトでサービス層２０４を構成し得る。コンテンツソーシングアプリ２０２は、個々のポイントオブコンタクトを、サービス層２０４によってホストされる１つ以上のリソースに関連付け得る。例えば、サービス層２０４は、コンテンツソーシングアプリ２０２が、コンテンツソーシングアプリ２０２がセンサ読み取り値等の特定のタイプのコンテンツを周期的にパブリッシュするサービス層２０４のリソース内に（例えば、大気質読み取り値がパブリッシュされるコンテナリソースに）ポイントオブコンタクト属性を構成することを可能にし得る。ステップ２１２では、ステップ２１１のポイントオブコンタクト情報は、サービス層２０４上に記憶される。ポイントオブコンタクト情報は、異なるシナリオ下でコンテンツソーシングアプリ２０２にコンタクトするために、サービス層２０４によって使用され得る。例えば、サービス層２０４は、コンテンツソーシングアプリ２０２にコンタクトして、コンテンツ要求アプリ２０６から要求を受信するサービス層２０４等のシナリオのための新鮮なコンテンツインスタンス（例えば、センサ読み取り値）を取得し、サービス層２０４が現在、ローカルにホストされたバージョンを有していない、または全てのバージョンが古すぎて、コンテンツ要求アプリ２０６の鮮度選好を満たすことができないセンサ読み取り値を読み出し得る。そのようなシナリオに対して、サービス層２０４は、コンテンツソーシングアプリ２１２によって提供されるポイントオブコンタクト情報を使用し、それに要求を送信し、新鮮なコンテンツを取得し得る。ステップ２１３では、サービス層２０４は、ステップ２１１のメッセージの受信を確認するための応答をコンテンツソーシングアプリ２０２に送信し得る。

ステップ２１４では、コンテンツソーシングアプリ２０２は、１つ以上のコンテンツインスタンスを、標的アドレス（例えば、ＵＲＩ）によって規定されるサービス層２０４リソースにパブリッシュする。各受信されたコンテンツインスタンスは、サービス層２０４によって記憶され（例えば、ステップ２１５）、応答を介して確認され得る（例えば、ステップ２１６）。コンテンツソーシングアプリ２０２は、コンテンツインスタンス（例えば、コンテンツ＝センサ読み取り値）がコンテンツソーシングアプリ２０２によって生成または捕捉されたときのタイムスタンプ（例えば、タイムスタンプ＝２０１６０１０４Ｔ１０４０１７）も提供し得る。サービス層２０４は、コンテンツがコンテンツソーシングアプリ２０２によって生成された時間と対比して、コンテンツインスタンスがサービス層２０４の中に記憶された時間を示すタイムスタンプもコンテンツインスタンスに割り当て得る。両方のタイムスタンプは、異なるタイムスタンプに基づいてコンテンツを検索するコンテンツ要求アプリ２０６に価値があり得る。

ステップ２１７では、コンテンツ要求アプリ２０６は、コンテンツソーシングアプリ２０２に関連付けられる特定のタイプのコンテンツをフェッチするための要求をサービス層２０４に発行し得る。コンテンツ要求アプリ２０６は、標的アドレス（例えば、ＵＲＩ）によってコンテンツソーシングアプリ２０２を規定し得る。要求の中に、コンテンツ要求アプリ２０６が、規定時間および日付以後のコンテンツを選好する（または要求する）ことを規定するために使用する時間および日付情報で構成される規定鮮度時間パラメータ（例えば、２０１６０１０３Ｔ１１２０３２）が含まれ得る。

ステップ２１８では、サービス層２０４は、サービス層２０４によってホストされ、ステップ２１７の要求の中で規定される標的アドレスを介してアクセス可能である各適用可能コンテンツインスタンスのタイムスタンプに対して、ステップ２１７の要求の鮮度時間パラメータ内の規定時間および日付情報を比較する。この比較から、サービス層２０４は、サービス層２０４によってホストされる適用可能なコンテンツインスタンスのうちのいずれかが、規定鮮度時間パラメータよりも新しいタイムスタンプを有するかどうかを決定する。何も見出されない場合、サービス層２０４は、この要求を満たすために、新鮮なコンテンツインスタンスが対応するコンテンツソーシングアプリ２０２から選好または要求されることをシグナリングするイベントを生成し得る。このイベントは、ひいては、ブロック２２１のステップで概説されるプロシージャによって定義されるように、コンテンツソーシングアプリ２０６から新鮮なコンテンツインスタンスを取得しようとするトリガとして、サービス層２０４によって使用され得る。トリガの生成は、適用可能なポイントオブコンタクトがコンテンツソーシングアプリ２０２のために構成されているかどうかに基づいて制限されることができる。いかなるポイントオブコンタクトも構成されていない場合、トリガは抑制され得る。

（ブロック２２０の中の）ステップ２１９では、サービス層２０４が規定鮮度時間パラメータよりも新しい（すなわち、許容閾値期間内の）タイムスタンプを伴うコンテンツインスタンスを見出す場合、コンテンツインスタンスを含む応答をコンテンツ要求アプリ２０６に返し得る。この場合、サービス層２０４は、そのローカルに記憶されたコンテンツをリフレッシュすることを始める必要がない。要求されたコンテンツがそれほど古くないが、間もなく古くなるであろう場合に対して、サービス層２０４は依然として、ブロック２２１内のステップを行うことを選定し、新鮮なコンテンツインスタンスを取得し得ることを留意されたい。「それほど古くない」は、多くの要因に基づき得る。このインスタンスにおいてブロック２２１のステップを続けるべきかどうかは、過去の応答（例えば、前の期間における「それほど古くない」応答の有無、連続応答等）に基づいて決定され得る。要求されたコンテンツが最近古くなった場合に対しても、サービス層２０４は依然として、コンテンツソーシングアプリ２０２が利用可能ではないか、または利用可能なコンテンツの新鮮なバージョンを有していない場合、そのコンテンツをコンテンツ要求アプリ２０６に返すことを選定し得る。この場合、サービス層２０４は、コンテンツが規定鮮度選好を満たさなかったが、利用可能な唯一のコンテンツであったという指示をコンテンツ要求アプリ２０６に提供し得る。

図１０のブロック２２１の中のステップに対して、サービス層２０４が規定鮮度時間パラメータよりも新しいタイムスタンプを伴うコンテンツインスタンスを見出さない場合、サービス層２０４は、コンテンツ要求アプリ２０６がブロックして待機することを要求されないように、確認応答をコンテンツ要求アプリ２０６に返し得る一方、サービス層２０４は、コンテンツソーシングアプリ２０２から新鮮なコンテンツインスタンスを取得しようとする（ステップ２２２）。ステップ２２２のこの確認応答メッセージは、要求が受信されたが、サービス層２０４がコンテンツ要求アプリ２０６の鮮度選好を満たしたローカルにホストされたコンテンツインスタンスを有していなかったので、依然として処理されていることを示すステータスを含み得る。ステップ２２２の確認応答メッセージは、読み出し、またはサブスクライブし、利用可能になるときに新鮮なコンテンツインスタンスを受信するためにコンテンツ要求アプリ２０６によって使用され得るサービス層コールバックアドレス（例えば、ＵＲＩ）も含み得る。この確認応答は、サービス層２０４が準備ができたコンテンツの新鮮なバージョンを有することを予期するときに関する推定時間または遅延も含み得る（例えば、サービス層２０４は、所与のコンテンツソーシングアプリ２０２から新鮮なコンテンツを取得することの過去の履歴に基づいて、期待時間または遅延を計算することが可能であり得る）。例えば、コンテンツ要求アプリ２０６は、このアドレスに周期的にポーリングまたはサブスクライブし、サービス層２０４がコンテンツソーシングアプリ２０２から新鮮なセンサ読み取り値を取得することができるときには新鮮なセンサ読み取り値を受信し得るか、またはサービス層２０４がコンテンツソーシングアプリ２０２から新鮮なセンサ読み取り値を取得することに失敗した場合にはエラー状態を受信し得る。確認応答は、随意に、新鮮なコンテンツを待っている間にコンテンツ要求アプリ２０６にある程度価値があり得るように、コンテンツの古いバージョンも含み得る。コンテンツ要求アプリ２０６が将来における鮮度時間を規定する場合に対して、サービス層２０４は、非ブロック様式でこの要求を処理し得る。サービス層２０４は、規定鮮度時間が経過するまで待機し、次いで、要求にサービス提供するコンテンツをホストしているかどうかをチェックし得る。ホストしている場合、サービス層２０４は、コンテンツでコンテンツ要求アプリ２０６に応答し得る。ホストしていない場合、それは、ステップ２２３および２２５−２３２を実施し得る。代替として、サービス層２０４は、ブロック様式で要求を処理することを選定し得、その場合、このステップでは、確認応答をコンテンツ要求アプリ２０６に返さないであろう。代わりに、サービス層２０４は、図１０のステップ２３２まで、コンテンツ要求アプリ２０６に応答することを控えるであろう。要求がブロック様式で処理されるか、非ブロック様式で処理されるかをサービス層２０４が決定することを可能にするトリガは、サービス層が要求を処理するために十分に新鮮なデータを有するかどうかに基づき得る。そうではなく、コンテンツソーシングアプリ２０２への要求を開始する場合において、サービス層２０４は、非ブロック様式で要求を処理することを選定し得る。そうでなければ、サービス層２０４は、ブロック様式で要求を処理することを選定し得る。代替として、ステップ１２４に示されるように、コンテンツ要求アプリ１２４は、サービス層２０４がブロックを使用するか、非ブロックを使用するかを要求の中で明示的に規定し得る。

図１０を継続して参照すると、ステップ１２３では、サービス層２０４が新鮮なコンテンツインスタンスを取得しようとしているとき、コンテンツソーシングアプリ２０２がサービス層２０４の要求を介して到達可能ではない場合、サービス層２０４は、新鮮なコンテンツインスタンスを取得し得るように、コンテンツソーシングアプリ２０２にサービス層２０４への接続性を再確立させるためのデバイストリガ動作を開始し得る。サービス層２０４がこの到達可能性決定を行う方法の詳細は、その全体として参照することによって組み込まれるｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ２．６．０によって定義されるように、いつサービス層２０４に到達可能であるかどうかを示すようにデバイスが更新する、コンテンツソーシングアプリ２０２のための到達可能性状態情報をサービス層２０４がサポートすること等のいくつかの異なる方法で行われ得る。サービス層２０４は、コンテンツ読み出しアプリ２０６がサービス層２０４によってサポートされる鮮度サービスを使用する権限を与えられているかどうか等のポリシに基づいて、所与の要求のための鮮度ベースのコンテンツ読み出しを行うかどうかを調整し得る。

図１０のステップ２２５では、コンテンツソーシングアプリ２０２が到達可能ではない場合、サービス層２０４は、それがサービス層２０４から要求を受信し得るように、コンテンツソーシングアプリ２０２がサービス層２０４へのその接続を再確立することを開始するためのデバイストリガ要求を生成し得る。サービス層２０４がデバイストリガをコンテンツソーシングアプリ２０２に配信する方法の詳細は、複数の方法で生じ得、例えば、１つのそのような配信方法は、３ＧＰＰ ＳＭＳベースのトリガ等の下層ネットワークトリガ機能性を利用することであり得る。トリガ要求ペイロードの一部として、サービス層２０４は、追加の情報を埋め込み、このトリガの理由が、新しいコンテンツ（例えば、センサ読み取り値）を用いてサービス層２０４をリフレッシュすることであることをコンテンツソーシングアプリ２０２に示し得る。この追加の情報は、以下のうちの１つ以上のものを含み得る：トリガタイプパラメータ（例えば、「Ｃｏｎｔｅｎｔ Ｒｅｑｕｅｓｔｅｄ」）；リフレッシュすることが選好される（もしくは要求される）特定のコンテンツを示すサービス層コンテンツ識別子またはアドレスパラメータ；サービス層２０４が要求されたコンテンツを所望する、または別様に必要とする緊急性を示す優先度パラメータ；コンテンツソーシングアプリ２０２がコンテンツインスタンスのバッファリングをサポートする場合、コンテンツが規定日時より古くあってはならないことを示す鮮度時間パラメータ、または、サービス層２０４が、コンテンツソーシングアプリ２０２がコンテンツの新鮮なバージョンを有するそれを提供することを選好するときの日時を示すスケジュールパラメータ。優先度パラメータに対して、サービス層２０４は、入って来る要求の規定優先度、コンテンツ要求アプリ２０６のサブスクリプションまたはアカウントと連携する優先度、（例えば、規定鮮度時間を過ぎた時間に対する）コンテンツの古さまたは陳腐化、または、コンテンツにおける人気、レベル、またはそれへの関心（例えば、異なるコンテンツ要求アプリの数およびコンテンツへの要求の頻度パターン）に基づいて、優先度を導出し得る。スケジュールパラメータに対して、サービス層２０４は、現在の要求の規定鮮度時間に基づいて、スケジュールを導出し得るか（例えば、要求の中の鮮度時間が将来の時間で規定された）、または代替として、導出されたスケジュールは、コンテンツに対する要求の過去の履歴に基づき得る（例えば、過去の要求のパターンを検出し、このパターンを使用して将来の要求のための推定スケジュールを導出する）。ステップ１２４のメッセージは、以下の情報、すなわち、（ｔｙｐｅ＝ＣｏｎｔｅｎｔＲｅｑｕｅｓｔ、ａｄｄｒ＝ＵＲＩ、ｐｒｉｏｒｉｔｙ＝ｈｉｇｈ、ｆｒｅｓｈｎｅｓｓ−ｔｉｍｅ＝２０１６０１０３Ｔ１１２０３２、ｓｃｈｅｄｕｌｅ＝２０１６０１０３Ｔ１１２１３２）を含み得る。

ステップ２２６では、デバイストリガ要求を受信すると、コンテンツソーシングアプリ２０２は、処理し、規定トリガタイプパラメータを分析することによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングアプリ２０２が１つ以上のタイプのコンテンツをサポートする場合、コンテンツ識別子またはアドレスパラメータをチェックし、サービス層２０４によって要求されているコンテンツのタイプを検出し得る。コンテンツソーシングアプリ２０２は、次いで、優先度またはスケジュールパラメータをチェックし、サービス層２０４に新鮮なコンテンツを提供しなければならないときを決定し得る。コンテンツソーシングアプリ２０２は、鮮度時間パラメータをチェックし、規定されるコンテンツの好ましい鮮度日付または時間があるかどうかを確認し得る。１つが規定される場合、コンテンツソーシングアプリ２０２は、それが提供する任意のコンテンツインスタンスが、この日時の前に生成されなかったことを検証し得る。

図１０のステップ２２７では、サービス層２０４によって開始されるデバイストリガ要求に応答して、コンテンツソーシングアプリ２０２は、サービス層２０４へのその接続を再確立し、その到達可能性状態を更新し、それが現在到達可能であり、サービス層２０４によって開始される要求を受信することができることをサービス層２０４に通知し得る。コンテンツソーシングアプリ２０２は、利用可能である場合、デバイストリガ応答の中にコンテンツの新鮮なバージョン（例えば、センサ読み取り値）、または代替として、新鮮なバージョンが現時点では利用可能ではないことを示すステータスを含み得る。そうすることで、これは、別個の要求を節約することによって、全体的なプロシージャを最適化し得る。代替として、コンテンツソーシングアプリ２０２は、（デバイストリガ要求および応答に続いて）サービス層２０４への別個の要求を開始し、利用可能である場合、新鮮なコンテンツ、または代替として、コンテンツの新鮮なバージョンが現時点では利用可能ではないことを示すステータスで、サービス層２０４を更新し得る。コンテンツソーシングアプリ２０２は、この新しい要求の標的として、デバイストリガ要求に埋め込まれたアドレス情報を使用し得る。ステップ２２７のメッセージは、以下の情報、すなわち、（ｔｏ＝ＵＲＩ、ｃｏｎｔｅｎｔ＝ｓｅｎｓｏｒ ｒｅａｄｉｎｇ、ｔｉｍｅｓｔａｍｐ＝２０１６０１０５Ｔ０９１４３４）を含み得る。

図１０を継続して参照すると、ステップ２２８では、コンテンツソーシングアプリ２０２が到達可能であり、サービス層２０４が別の機構（本明細書に説明されるデバイストリガベースの機構等）によってコンテンツソーシングアプリ２０２から新鮮なコンテンツインスタンスを受信していない場合、サービス層２０４は、代替として、新鮮なコンテンツインスタンスを明示的に要求する、コンテンツソーシングアプリ２０２への別個の要求をそれ自身で開始し得る。この要求は、いくつかの異なるタイプの要求のうちの１つを使用して、コンテンツソーシングアプリ２０２に配信され得る。サービス層２０４は、ステップ２１１からステップ２１３でコンテンツソーシングアプリ２０２によって規定されるポイントオブコンタクトを標的化する読み出し要求を開始し得る。代替として、サービス層２０４は、事前サブスクリプション要求の中で構成される通知アドレスを標的化するコンテンツソーシングアプリ２０２への通知要求、またはステップ２１１からステップ２１３で規定されるポイントオブコンタクトへの通知要求を開始し得る。この通知内に、サービス層２０４は、本明細書で議論されるトリガ要求（例えば、ステップ２２５からステップ２２７）の中で定義されるような類似タイプの情報を含み得る。ステップ２２８の通知は、以下のうちの１つ以上のものを含み得る：この通知（例えば、コンテンツリフレッシュ要求）の理由（例えば、トリガイベント）；リフレッシュすることが選好される特定のコンテンツを示すサービス層コンテンツ識別子またはアドレスパラメータ；サービス層２０４が要求されたコンテンツを所望する、または別様に必要とする緊急性を示す優先度パラメータ；コンテンツソーシングアプリ２０２がコンテンツインスタンスのバッファリングをサポートする場合において、規定絶対日付および時間、またはコンテンツが作成された以降の相対時間以後にコンテンツが作成されていなければならないことを示す鮮度時間パラメータ；または、サービス層２０４が、コンテンツソーシングアプリ２０２がそれにコンテンツの新鮮なバージョンを提供することを選好するときの日付および時間を示すスケジュールパラメータ。優先度パラメータに対して、サービス層２０４は、入って来る要求の規定優先度、コンテンツ要求アプリ２０６のサブスクリプションまたはアカウントと連携する優先度、コンテンツの古さまたは陳腐化（例えば、規定鮮度時間を過ぎた時間）、または、コンテンツにおける人気もしくはレベルまたはそれへの関心（例えば、異なるコンテンツ要求アプリの数およびコンテンツへの要求の頻度パターン）に基づいて、優先度を導出し得る。スケジュールパラメータに対して、サービス層２０４は、現在の要求の規定鮮度時間に基づいて、スケジュールを導出し得る（例えば、要求の中の鮮度時間が将来の時間で規定された）、または代替として、導出されたスケジュールは、コンテンツに対する要求の過去の履歴に基づき得る（例えば、過去の要求のパターンを検出し、このパターンを使用して将来の要求のための推定スケジュールを導出する）。ステップ２２８のメッセージは、以下の情報、すなわち、（ｔｙｐｅ＝ＣｏｎｔｅｎｔＲｅｆｒｅｓｈ、ａｄｄｒ＝ＵＲＩ、ｐｒｉｏｒｉｔｙ＝ｈｉｇｈ、ｆｒｅｓｈｎｅｓｓ−ｔｉｍｅ＝２０１６０１０３Ｔ１１２０３２、ｓｃｈｅｄｕｌｅ＝２０１６０１０３Ｔ１１２１３２）を含み得る。

図１０のステップ２２９では、サービス層２０４からステップ２２８の要求を受信すると、コンテンツソーシングアプリ２０２は、要求のタイプ（例えば、読み出しまたは通知）を処理して検出し得る。要求が読み出しである場合、コンテンツソーシングアプリ２０２は、要求の中の規定アドレスを分析し、要求されているコンテンツを決定し、ひいては、利用可能である場合、それがサービス層２０４に応答を返すことを所望するコンテンツインスタンス、または代替として、新鮮なバージョンが現時点では利用可能ではないことを示すステータスを準備し得る。要求が通知である場合、コンテンツソーシングアプリ２０２は、規定通知タイプパラメータを分析することによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングアプリ２０２が２つ以上のタイプのコンテンツをサポートする場合、コンテンツ識別子またはアドレスパラメータをチェックし、サービス層２０４によって要求されているコンテンツのタイプを検出し得る。それは、次いで、優先度またはスケジュールパラメータをチェックし、サービス層２０４に新鮮なコンテンツを提供しなければならないときを決定し得る。それは、鮮度時間パラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。１つが規定される場合、コンテンツソーシングアプリ２０２は、それが提供する任意のコンテンツインスタンスが、この日付および時間の前に生成されなかったことを検証し得る。

ステップ２３０では、コンテンツソーシングアプリ２０２は、いくつかの方法のうちの１つにおいて、新鮮なコンテンツインスタンスで、または、新鮮なコンテンツインスタンスが現時点では利用可能ではないことを示すステータスでサービス層２０４を更新し得る。サービス層２０４が、新鮮なコンテンツインスタンスを要求する明示的読み出し要求をコンテンツソーシングアプリ２０２に発行する場合、コンテンツソーシングアプリ２０２は、読み出し応答の中に新鮮なコンテンツインスタンスを含み得る。サービス層２０４が、新鮮なコンテンツインスタンスが所望されること、または別様に必要とされることを示す通知をコンテンツソーシングアプリ２０２に発行する場合、コンテンツソーシングアプリ２０２は、通知応答の中に新鮮なコンテンツインスタンスを含み得るか、または代替として、コンテンツソーシングアプリ２０２は、サービス層２０４内で新鮮なコンテンツインスタンスを作成するための別個の要求（例えば、作成要求）を継続することができる。ステップ２３０のメッセージは、以下の情報、すなわち、（ｔｏ＝ＵＲＩ、ｃｏｎｔｅｎｔ＝ｓｅｎｓｏｒ ｒｅａｄｉｎｇ、ｔｉｍｅｓｔａｍｐ＝２０１６０１０５Ｔ０９１４３４）を含み得る。

図１０を継続して参照すると、ステップ２３１では、新鮮なコンテンツインスタンスがサービス層２０４に正常にパブリッシュされた場合、サービス層２０４は、新鮮なコンテンツインスタンスのローカルバージョンが、将来の要求にサービス提供するために活用され得るか、または課金および分析等の目的のために使用され得るように、それを記憶し得る。サービス層２０４は、随意に、対応するタイムスタンプを割り当て、コンテンツインスタンスがサービス層２０４にパブリッシュされたときも記録し得る。ステップ２３２では、新鮮なコンテンツインスタンスがサービス層２０４に正常にパブリッシュされた場合、それは、コンテンツ要求アプリ２０６に返され、そうでなければ、新鮮なコンテンツが利用可能ではない場合、サービス層２０４は、エラーを返し得るか、または代替として、サービス層２０４は、その陳腐化の指示（例えば、それが作成された時間）とともに、コンテンツの（古いが）直近のバージョンを返し得る（これが依然としてある程度有用であり得るので）。

図１１は、例示的鮮度ベースのリソース発見メッセージフローを図示する。コンテンツ要求アプリ２０６は、サービス層２０４がそのようなコンテンツをホストしない場合でさえも、コンテンツ要求アプリ２０６の鮮度選好を満たすコンテンツをサービス層２０４から発見する。プロシージャは、サービス層２０４が、コンテンツが古い、またはサービス層２０４の中に存在しないときを検出することを可能にする、オンザフライ機構を定義する。これが起こるとき、サービス層２０４は、次に、対応するコンテンツソーシングアプリ２０２にコンタクトし、それに、サービス層２０４がコンテンツ要求アプリ２０６に返す発見応答の中にこのコンテンツの参照を含み得るように、コンテンツをリフレッシュさせ得る。

図１１のブロック２４１の中のステップは、図１０のステップ２１０からステップ２１６と同一に機能する。図１１のステップ２４２では、コンテンツ要求アプリ１０６は、コンテンツソーシングアプリ２０２に関連付けられる特定のタイプのコンテンツを発見するための要求をサービス層２０４に発行する。要求の中に、コンテンツ要求アプリ２０６が、規定時間および日付以後のコンテンツを発見することを所望することを規定するために使用する時間および日付情報で構成される規定鮮度時間パラメータが含まれる。ステップ２４２の要求は、他の発見フィルタ基準（例えば、コンテンツのタイプ）も含み得る。

ステップ２４３では、サービス層２０４は、サービス層２０４によってホストされる各適用可能コンテンツインスタンスのタイムスタンプに対して、ステップ２４２のコンテンツ発見要求の鮮度時間パラメータ内の規定時間および日付情報を比較する。この比較から、サービス層２０４は、サービス層２０４によってホストされる適用可能なコンテンツインスタンスのうちのいずれかが、規定鮮度時間パラメータよりも新しい（すなわち、許容閾値期間内の）タイムスタンプを有するかどうかを決定する。何も見出されない場合、サービス層２０４は、新鮮なコンテンツインスタンスが対応するコンテンツソーシングアプリ２０２から選好されることをシグナリングするイベントを生成し得、サービス層２０４は、コンテンツ要求アプリ２０６に送信する発見応答の中に、このコンテンツの参照（例えば、ＵＲＩ）と、コンテンツ要求アプリ２０６がコンテンツにアクセスする後続の要求を送信するとき、サービス層２０４が準備完了して利用可能であるコンテンツを有していることとを含み得る。このイベントは、図１０のブロック２２１のフローおよび対応する説明で概説されるように、コンテンツソーシングアプリ２０２から新鮮なコンテンツインスタンスを取得することを試みるためのトリガとして、サービス層２０４によって使用され得る。トリガの生成は、適用可能なポイントオブコンタクトがコンテンツソーシングアプリ２０２のために構成されているかどうかに基づいて制限され得る。いかなるポイントオブコンタクトも構成されていない場合、トリガは、抑制され得る。サービス層２０４は、ステップ２４２によって要求され、ステップ２４３で処理されるように、この鮮度ベースの発見特徴を利用することを可能にされる、コンテンツ要求アプリ２０６を制限するアクセス制御ポリシをサポートし得る。コンテンツ要求アプリ２０６が所与の標的コンテンツインスタンスのために定義される鮮度ベースの発見のための特権を有するかどうかは、サービス層２０４が、続いて、コンテンツソーシングアプリ２０２への鮮度ベースの読み出し要求を開始するかどうかを制限するために使用され得る。

ブロック２４５のステップ２４４では、サービス層２０４が、規定鮮度時間パラメータよりも新しい（すなわち、許容閾値期間内の）タイムスタンプを伴うコンテンツインスタンスを見出す場合、発見応答の中にこのコンテンツの参照（例えば、ＵＲＩ）を含む応答をコンテンツ要求アプリ２０６に返し得る。この場合、サービス層２０４は、そのローカルに記憶されたコンテンツをリフレッシュすることを開始しないこともある。しかしながら、サービス層２０４は、この場合でさえも、そのコンテンツを依然としてリフレッシュすることを選定し得る。例えば、コンテンツが古くなることが近い場合、サービス層２０４は、この状態を検出し、コンテンツを積極的にリフレッシュすることを選定し得る。ステップ２２２からステップ２３１および図１０の付随する説明は、図１１のブロック２４７の中のステップと同一であり得る。ステップ２４８では、新鮮なコンテンツインスタンスがサービス層２０４に正常にパブリッシュされた場合、このコンテンツの参照（例えば、ＵＲＩ）は、発見応答の中で返され、そうでなければ、エラーが代わりに返され得る。ステップ２４９では、コンテンツ要求アプリ２０６は、発見応答を処理し、続いて、（応答の中の規定参照に基づいて）その鮮度要件を満たす発見コンテンツインスタンスのうちの１つ以上のものを読み出し得る。

図１２は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。要求受信アプリ２０３は、サービス層２０４が所与のリソースのために受信するある要求を、サービス提供されるべき要求受信アプリ２０３に再標的化するようにサービス層２０４を構成し得る。この再標的化機能性は、要求および応答が、要求開始アプリ２０５と要求受信アプリ２０３との間でサービス層２０４を通ってエンドツーエンドでフローすることを可能にする透過性のレベルを有する。そのような特徴がないと、要求受信アプリ２０３および要求開始アプリ２０５は、単一のエンドツーエンド要求および応答交換を実施するために、複数のサービス層サブスクリプションならびに通知を伴うあまり効果的ではない、または好ましくない間接通信方式に依拠し得る。

例えば、図１２の方法は、サービス層２０４によって受信される更新要求を要求受信アプリ２０３に再標的化するために使用され得る。これは、要求受信アプリ２０３がアクチュエータタイプのデバイス（例えば、明かりのスイッチ）であるシナリオのために有用であり得る。要求受信アプリ２０３が再標的化されることを所望する要求のタイプは、プログラム可能なサービス層再標的化ポリシによって構成され得る。ＣＲＥＡＴＥ（例えば、子リソースの作成）、ＲＥＴＲＩＥＶＥ、ＤＥＬＥＴＥ、およびＳＵＢＳＣＲＩＢＥ等の他のタイプの要求も、図１２に示されるように、このプロシージャに適用可能であり得るが、プロシージャを簡潔に保つために明示的に示されていない。加えて、他のポリシが、サービス層２０４が要求を要求受信アプリ２０３に再標的化するときを制限し得る。例えば、サービス層２０４は、要求のフィルタリングをサポートし、所与の標的リソースのために要求の一部を要求受信アプリ２０３に再標的化するのみ（例えば、特定の要求開始アプリ２０５からの要求を再標的化するのみ）であり得る。サービス層は、鮮度フィルタリングリングおよび再標的化を実施するときにサービス層２０４が分析するであろう（および分析しないであろう）リソース表現の中の属性を制御するポリシもサポートし得る。この特徴は、要求受信アプリ２０３が、要求受信アプリ２０３に重要性を有する属性にその比較の焦点を合わせ、他のものを無視するようにサービス層２０４を構成することを可能にし得る。さらに別のタイプの再標的化ポリシは、再標的化された要求の中に含まれる属性および含まれないものを定義し得る。さらに別のタイプの再標的化ポリシは、それらの要求をコンテンツソーシングアプリ２０２に再標的化させる特権を伴う特定のコンテンツ要求アプリ２０６を定義し得る。

サービス層２０４が実施し得る再標的化のタイプは、鮮度ベースの再標的化である。標的リソースへのＵＰＤＡＴＥ要求を受信すると、サービス層２０４は、更新されるべきリソースの現在の表現を、ＵＰＤＡＴＥ要求の中で提供される表現と比較し得る。それらが同じである場合、サービス層２０４は、現在のリソースが新鮮かつ最新であることを推測し、要求受信アプリ２０３上の要求の数および負荷を最小化するために、ＵＰＤＡＴＥ要求を要求受信アプリ２０３に再標的化しないことを選定し得る。そのような場合において、サービス層２０４は、ステータスコードを要求開始アプリ２０５に返し、この状況をそれに通知し得る。逆に、比較された表現が同じではない場合、サービス層２０４は、要求受信アプリ２０３が処理するためにＵＰＤＡＴＥ要求をそれに再標的化し得る。加えて、サービス層２０４は、リソースのそのローカルバージョンを更新し、要求受信アプリ２０３の表現との同期化を維持し、潜在的な将来の要求のために更新されたバージョンを活用し得る。図１２に（図８−図９にも）示されるようなこの鮮度ベースの再標的化特徴は、経時的に重複要求を受信し得るリソース制約されたＩｏＴデバイスおよびネットワークを伴うもの等のいくつかのユースケースに価値があり得る構成可能オプションとしてサポートされ得ることに留意されたい。重複要求が機能的重要性を有し得る他のユースケースに対して、この特徴は、無効にされ得る。特徴を選択的に有効または無効にする１つの例示的方法は、ポイントオブコンタクトを使用することによるものである（例えば、いかなるポイントオブコンタクトも構成されない場合、その再標的化は無効にされる）。特徴を選択的に有効または無効にする第２の例示的方法は、再標的化ポリシを使用することによるものである。

ステップ２６１では、要求受信アプリ２０３および要求開始アプリ２０５は、認証し、サービス層２０４に登録する。要求開始アプリ２０５は、次いで、要求受信アプリ２０３を発見する。ステップ２６２では、要求受信アプリ２０３は、所与のリソースのためのサービス層２０４内のポイントオブコンタクト構成アドレスおよび再標的化ポリシを備えているメッセージを送信する。ステップ２６２のメッセージは、以下のうちの１つ以上のものを含み得る：（ｔｏ＝ＵＲＩ、ｐｏｉｎｔ−ｏｆ−ｃｏｎｔａｃｔ＝Ａｐｐ Ａｄｄｒ Ｉｎｆｏ、ｒｅｔａｒｇｅｔＰｏｌｉｃｉｅｓ＝ｐｏｌｉｃｉｅｓ）。ステップ２６３では、サービス層２０４は、規定リソースのために要求受信アプリ２０３に関連付けられるポイントオブコンタクト情報および再標的化ポリシを構成する。ステップ２６４では、サービス層２０４は、とりわけ、ステップ２６２のメッセージの受信を確認し得る応答を送信し得る。図１２のステップ２６２からステップ２６４は、鮮度ベースのコンテンツ読み出しで定義される図１０のステップ２１１−２１３に類似するが、しかしながら、加えて、要求受信アプリ２０３は、所与のリソースのために再標的化ポリシを構成し得る。代替として、再標的化ポリシは、ネットワーク内の管理エンティティ等の他のエンティティによって構成され得る。これらのポリシは、要求を要求受信アプリ２０３に発行することを可能にされる要求開始アプリ２０５のリスト、要求受信アプリ２０３がサービス提供するであろう許容要求タイプのリスト、要求受信アプリ２０３が利用可能であり、自発的に要求にサービス提供する時間を定義するスケジュール、および要求受信アプリ２０３に着目される要求関連属性のリスト／マスク等の再標的化規則を含み得る。

ステップ２６５では、要求開始アプリ２０５は、標的アドレス（例えば、ＵＲＩ）によって規定されるような特定の要求受信アプリに関連付けられる特定のリソースを更新するためのＵＰＤＡＴＥ要求をサービス層２０４に発行する。要求の中に、更新されるべきリソースの完全または部分表現が含まれ得る。この例では、ＵＰＤＡＴＥは、要求受信アプリ２０３によってサポートされるスイッチの状態を「ＯＮ」の値に変更するために使用される。メッセージは、以下のうちの１つ以上のものを含み得る：（ｔｏ＝ＵＲＩ、ｃｏｎｔｅｎｔ＝‘ＯＮ’）。

図１２を継続して参照すると、ステップ２６６では、サービス層２０４は、ステップ１６５のＵＰＤＡＴＥ要求を処理する。要約すると、再標的化ポリシに基づいて、要求の中のコンテンツに対して標的リソースの現在の表現を比較し、それらが異なることを決定し、したがって、要求を要求受信アプリ２０３に再標的化することがあり得る。さらに詳細に、サービス層１０４は、要求開始アプリ２０５の要求によって標的化されるリソースの再標的化ポリシを分析し得る。これらのポリシを使用して、サービス層２０４は、要求開始アプリ２０５が要求を要求受信アプリ２０３に発行する権限を与えられているかどうか、要求が要求受信アプリ２０３によってサポートされるものであるかどうか、規定スケジュールまたは規定条件に基づいて、要求をバッファし、ひいては、要求受信アプリ２０３に再標的化するときの決定等のチェックを実施し得る。サービス層２０４は、次いで、ＵＰＤＡＴＥ要求の中に含まれる表現に対して、（該当する場合）サービス層２０４の中に記憶されたリソースの現在の表現を比較する。この比較は、ある属性のみが互いと比較されるように、比較する（または比較しない）複数のリソース属性のうちの一部を定義するマスクを考慮し得る。比較がいかなる不一致ももたらさない場合、サービス層２０４は、ＵＰＤＡＴＥ要求を要求受信アプリ２０３に再標的化しないことを決定し得る。しかしながら、（この例のように）不一致が見出される場合、サービス層２０４は、ＵＰＤＡＴＥ要求を再標的化することを決定し得る。サービス層２０４内の記憶された状態が要求受信アプリ２０３の状態と同期しなくなる（例えば、明かりが「ＯＮ」であるが、サービス層状態はそれが「ＯＦＦ」であることを示す）場合に対して、次いで、この提案される鮮度ベースのフィルタリング機能性をオーバーライドする機構を有することが可能である。例えば、サービス層１４２が明かりを消灯するように５つの連続要求を受信した場合、たとえ記憶された状態が、ＵＰＤＡＴＥ要求が新鮮ではないことを示したとしても、サービス層１４２は、要求を要求受信アプリ２０３に転送し得る。

図１２のステップ２６７では、サービス層２０４は、ＵＰＤＡＴＥ要求を、サービス提供されるべき要求受信アプリ２０３に再標的化する。この要求の中に、要求開始アプリ２０５からのオリジナル要求の中に含まれる更新されるべきリソースの表現が含まれ得る。ステップ２６７のメッセージは、以下のうちの１つ以上のものを含み得る：（ｔｏ＝ｐｏｉｎｔ ｏｆ ｃｏｎｔａｃｔ、ｃｏｎｔｅｎｔ＝“Ｓｗｉｔｃｈ ＯＮ”）。ステップ２６８では、要求受信アプリ２０３は、サービス層２０４からＵＰＤＡＴＥ要求を受信して処理する。それは、リソースのそのローカルバージョンを更新することによって、これを行い得る。この例では、ＵＰＤＡＴＥは、要求受信アプリ２０３によってサポートされるスイッチの状態を「ＯＮ」の値に変更するために使用される。ステップ２６９では、要求受信アプリ２０３は、サービス層２０４に応答し、それがリソースのそのローカルバージョンを正常に更新したことを示す。ステップ２７０では、サービス層２０４は、ステップ２６９のメッセージを受信することに応答し得る。ステップ２７１では、リソースのそのローカルバージョンに同じ更新（例えば、状態を「ＯＮ」の値に変更する）を実施し、それは、サービス層２０４は、ＵＰＤＡＴＥ要求が正常に処理されたことを示すメッセージを要求開始アプリ２０５に送信する。

図１２を継続して参照すると、ステップ２７２では、異なる要求開始アプリ２０５（以降では第２の要求開始アプリ２０５）が、第１の要求開始アプリからの（すなわち、要求２６５に関連付けられる）ＵＰＤＡＴＥと意味的に同じである（例えば、要求ペイロードの中に同一のリソース表現を含む）ＵＰＤＡＴＥ要求を発行する。ステップ２７３では、サービス層２０４は、ステップ２６６で説明されるものに類似する処理を実施する。サービス層２０４は、比較結果が合致する（例えば、「ＯＮ」の更新された値が現在の値と同じである）ことを検出し、ＵＰＤＡＴＥ要求を要求受信アプリ２０３に再標的化しないことを決定する。ステップ２７４では、サービス層２０４は、第２の要求開始アプリ２０５からのＵＰＤＡＴＥ要求が、たとえ要求受信アプリ２０３に再標的化されなかったとしても処理されたという事実を追跡するためにそのローカルメタデータを更新し得る。これは、課金、分析、および要求への後続の反応の決定等の目的のために、要求開始アプリ２０５の要求履歴を追跡するために有用であり得る。ステップ２７５では、サービス層２０４は、第２の要求開始アプリ２０５に応答し、ＵＰＤＡＴＥ要求が正常に処理されたことを示す。

以下は、本明細書で議論される方法、システム、およびデバイスのうちのいくつかのための考慮事項であった。第１の考慮事項は、現在のｏｎｅＭ２Ｍアーキテクチャが、リソースがＡＥではなくＣＳＥによってホストされるという原理に基づくと考えられることである。したがって、ＡＥによってホストされるリソースも、ＡＥホスト型リソースにアクセスするメッセージまたはプロシージャも、ｏｎｅＭ２Ｍによって定義されない。ＡＥを標的化することができる、ｏｎｅＭ２Ｍによって定義される要求のタイプは、ＮＯＴＩＦＹ要求である。ＡＥは、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＳＵＢＳＣＲＩＢＥ、またはＤＩＳＣＯＶＥＲ ｏｎｅＭ２Ｍ要求によって標的化されることができない。したがって、ｏｎｅＭ２Ｍシステムの一部として機能するために、ＡＥは、ＣＳＥに登録し、ＣＳＥがこれらのリソースをホストし、それらを他のＡＥに発見可能かつアクセス可能にし得るように、ＣＳＥ内でそのリソースをパブリッシュまたはミラー化しなければならない。

第２の考慮事項は、ｏｎｅＭ２Ｍが現在、ＡＥが所与のコンテナのためにポイントオブコンタクトを規定するための能力をサポートしないことである。加えて、ＣＳＥが要求を処理する代わりに、ＣＳＥが、入って来るコンテナ要求を、処理されるべき対応するＡＥに再標的化するための能力が、サポートされていない。ＣＳＥが、標的コンテナの中の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースが古すぎて入って来る要求にサービス提供することができないことを検出し、次に、ＡＥから新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得して要求を満たす能力もサポートされない。

第３の考慮事項は、ホスティングＣＳＥが、それがたまたま現在ホストしている最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースのみを使用して、＜ｌａｔｅｓｔ＞への読み出しにサービス提供することに限定されていることである。要求の発信側が、最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のｃｒｅａｔｉｏｎＴｉｍｅよりも遅いタイムスタンプを有するｃｒｅａｔｅｄＡｆｔｅｒフィルタ基準条件も規定する場合、これは、いかなる合致ももたらさないであろう。ｏｎｅＭ２Ｍは、現在、このシナリオではＡＥから新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースを取得する機構およびプロシージャをサポートしていない。

第４の考慮事項は、規定ｃｒｅａｔｅｄＡｆｔｅｒフィルタ基準条件がいかなる合致ももたらさない場合、ｏｎｅＭ２Ｍが、現在、規定ｃｒｅａｔｅｄＡｆｔｅｒフィルタ基準を満たす新鮮なコンテンツをＡＥから取得する機構およびプロシージャをサポートしていないことである。第５の考慮事項は、ｏｎｅＭ２Ｍが、現在、ＡＥが作成して使用されることを可能にされる他のリソースタイプ（例えば、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞、＜ｍｇｍｔＯｂｊ＞、＜ｍｇｍｔＣｍｄ＞等）のためにｐｏｉｎｔＯｆＡｃｃｅｓｓを構成することをサポートしていないことである。ｏｎｅＭ２Ｍは、ＣＳＥによるｐｏｉｎｔＯｆＡｃｃｅｓｓ属性の使用を、ＣＳＥが通知をＡＥに送信している場合のみにさらに制限する。ｏｎｅＭ２Ｍが、ｏｎｅＭ２Ｍを介してアドレス指定されることができるＡＥホスト型リソースをサポートしないので、ｏｎｅＭ２Ｍは、ＡＥがｐｏｉｎｔＯｆＡｃｃｅｓｓの中へのＵＲＩパス等の他のアドレス情報を構成することを可能にしない。ｏｎｅＭ２Ｍはまた、複数のｐｏｉｎｔＯｆＡｃｃｅｓｓエントリがＡＥによって構成される場合、ＣＳＥがそれらを使用する方法も定義しない。第６の考慮事項は、ｏｎｅＭ２Ｍが、現在、ＣＳＥが任意の他のタイプの要求を上でリストアップされるもの以外、ＡＥに開始または再標的化することを可能にしないことである。例えば、ＣＳＥは、アプリケーションの中に記憶されたリソースを読み出すこと、または更新することができない。第７の考慮事項は、アプリケーションサービス層に対処し得る従来のシステムが、ｆｏｒｗａｒｄｉｎｇＡｄｄｒｅｓｓが要求の鮮度ベースの処理をサポートするために使用される方法を定義しないことである。第８の考慮事項は、ＣｏＲＥ Ｍｉｒｒｏｒ Ｓｅｒｖｅｒ−ＩＥＴＦ ｄｒａｆｔ−ｖｉａｌ−ｃｏｒｅ−ｍｉｒｒｏｒ−ｓｅｒｖｅｒ−０１（２０１３年４月１０日）が、クライアントがミラー化リソースへのそのＧＥＴ要求の中で鮮度時間（例えば、標的リソースがある日付または時間より古くあることができない）を特定することを可能にする能力をサポートしないことである。加えて、とりわけ、ＣｏＲＥ Ｍｉｒｒｏｒ Ｓｅｒｖｅｒ−ＩＥＴＦ ｄｒａｆｔ−ｖｉａｌ−ｃｏｒｅ−ｍｉｒｒｏｒ−ｓｅｒｖｅｒ−０１（２０１３年４月１０日）は、ミラー化リソースが古い（例えば、ミラーリソース表現がクライアントＧＥＴ要求で規定される規定日付または時間よりも古い）場合のために、それがミラー化リソースのために受信するＧＥＴ要求をＳＥＰ上でホストされる対応するリソースに条件付きで転送する能力をサポートしない。

本明細書で議論される概念を考慮して適用し得るｏｎｅＭ２Ｍ例が以下で開示される。図１３は、ＯｎｅＭ２Ｍにおけるサービス層鮮度機構の例示的アーキテクチャを図示する。鮮度能力は、ＣＳＥの中のデータ管理およびリポジトリＣＳＦ、発見ＣＳＦ、またはサブスクリプションおよび通知ＣＳＦの特徴として実現され得る。鮮度能力は、例えば、データ管理およびリポジトリＣＳＦ２８０、発見ＣＳＦ２８１、またはサブスクリプションおよび通知ＣＳＦ２８２に追加され得る。

本明細書に開示される鮮度機構およびプロシージャを実現するために、ｏｎｅＭ２Ｍリソースへの強化が本明細書で定義される。

ｏｎｅＭ２ＭリソースがＡＥのアドレス情報で構成されることを可能にするｐｏｉｎｔＯｆＣｏｎｔａｃｔ共通リソース属性が、本明細書に開示される。所与のリソースのためのこの属性の存在は、このリソースと連携するＡＥ（例えば、リソースを作成したＡＥ、すなわち、コンテンツソーシングＡＥ３０２）が、ＣＳＥによってそれに送信される要求にサービス提供する能力をサポートするという、ホスティングＣＳＥ（例えば、図１０のサービス層２０４または図１４のＣＳＥ３０４）への指示であり得る。これらの要求は、ＣＳＥがＡＥに向けて再標的化し、他のエンティティ（例えば、他のＡＥまたはＣＳＥ）によって開始される要求、またはＣＳＥが（例えば、古いリソース表現をリフレッシュするために）それ自身で開始する要求であり得る。このｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性は、種々のタイプのｏｎｅＭ２Ｍ定義リソースによってサポートされ得る。例えば、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘｃｏｎｔａｉｎｅｒ＞、＜ｍｇｍｔＯｂｊ＞、＜ｍｇｍｔＣｍｄ＞、＜ｔｉｍｅＳｅｒｉｅｓ＞等のリソースタイプ。

提案されるｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性は、対応するＡＥの異なるタイプのアドレス情報をサポートし得る。一例では、ｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性は、ＡＥがホストするリソースの絶対ＵＲＩ（例えば、ｈｔｔｐ：／／１７２．３０．０．５５：３４７８／ｔｅｍｐｅｒａｔｕｒｅ）で構成され得る。この場合、ＣＳＥは、要求をＡＥに送信するための完全アドレスとしてこのｐｏｉｎｔＯｆＣｏｎｔａｃｔを使用し得る。第２の例では、ｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性は、ＣＳＥによってホストされるＡＥの＜ＡＥ＞リソースのｏｎｅＭ２Ｍ定義ｒｅｓｏｕｒｃｅＩＤで構成され得る。この場合、ＣＳＥは、ｒｅｓｏｕｒｃｅＩＤを使用し、サポートされた方式、すなわち、＜ＡＥ＞リソースのｏｎｅＭ２Ｍ定義ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性内で構成されるＡＥのＦＱＤＮまたはＩＰアドレスおよびポートにアクセスし得る。この情報は、次に、ＣＳＥによって要求をＡＥに送信するために使用され得る（例えば、ｈｔｔｐ：／／１７２．３０．０．５５：３４７８）。第３の例では、ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性は、ＡＥがホストするリソースの相対ＵＲＩ（例えば、／ｔｅｍｐｅｒａｔｕｒｅ）で構成され得る。この場合、ＣＳＥは、部分アドレスとしてこのｐｏｉｎｔＯｆＡｃｃｅｓｓを使用し得る。ＣＳＥは、次いで、ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性を有するリソースと連携する親＜ＡＥ＞リソースのｐｏｉｎｔＯｆＡｃｃｅｓｓ属性の中で構成されるＦＱＤＮまたはＩＰ／ポートを使用することによって、完全アドレスを形成することをサポートし得る。ＣＳＥは、ＵＲＩのパス部分としてｐｏｉｎｔＯｆＡｃｃｅｓｓ相対ＵＲＩ（例えば、／ｔｅｍｐｅｒａｔｕｒｅ）を使用し、方式およびホスト部分（例えば、ｈｔｔｐ：／／１７２．３０．０．５５：３４７８）としてｐｏｉｎｔＯｆＡｃｃｅｓｓ情報を使用し、絶対ＵＲＩ（例えば、ｈｔｔｐ：／／１７２．３０．０．５５：３４７８／ｔｅｍｐｅｒａｔｕｒｅ）を形成し得る。

表１は、開示されるｐｏｉｎｔＯｆＣｏｎｔａｃｔ ｏｎｅＭ２Ｍ共通属性のさらなる詳細を提供する。

本開示は、新しいｏｎｅＭ２Ｍ通知イベントおよびコンテンツタイプを提案する。これらは、ＣＳＥが、本明細書に開示される鮮度ベースのコンテンツ読み出し、コンテンツ発見、および要求再標的化機能性をサポートすることを可能にし得る。読み出しに加えて、ｏｎｅＭ２Ｍ通知コンテンツタイプ特徴は、作成、更新、または削除等のＣＳＥからＡＥへの他のタイプの要求の再標的化をサポートするために使用され得る。

新しいタイプの通知イベントが、ｏｎｅＭ２Ｍサブスクリプションイベント通知基準のために定義される。新しいイベントは、ｓｕｂｓｃｒｉｂｅｄ−ｔｏ＜ｃｏｎｔａｉｎｅｒ＞リソースの最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を読み出す試みがあり、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースが存在しないか、またはそのｃｒｅａｔｉｏｎＴｉｍｅが読み出し要求のｃｒｅａｔｅｄＡｆｔｅｒｆｉｌｔｅｒＣｒｉｔｅｒｉａ内で規定される時間よりも古いかのいずれかであるとき、トリガされ得る。これは、本明細書の表２に示される。

新しいタイプの通知コンテンツが、ｏｎｅＭ２Ｍ通知のために定義される。
新しいコンテンツタイプは、ｓｕｂｓｃｒｉｂｅｄ−ｔｏ−ｐａｒｅｎｔリソースを標的化し入って来る要求が通知にカプセル化されることを可能にする。これは、本明細書の表３に示される。

これらの新しい通知イベントおよびコンテンツタイプは、ｏｎｅＭ２ＭサブスクリプションがＣＳＥからＡＥへの要求の再標的化に使用されることを可能にする。ＡＥは、これらを使用して、ＣＳＥが所与のリソースのために受信する要求をサービス提供されるべきＡＥに再標的化するようにＣＳＥを構成し得る。トリガされると、新しいイベントは、ＣＳＥが通知要求を生成し、サブスクリプションのｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性によって定義される規定標的（例えば、ＡＥ）に通知要求を送信することをもたらし得る。通知のコンテンツは、サブスクリプションの親リソースをもともと標的化する１つ以上の埋め込まれた要求と、ＣＳＥが再標的化していることとを含み得る。通知を受信すると、受信側（例えば、ＡＥ）は、通知のコンテンツに埋め込まれた再標的化された要求を処理し得、応答は、通知応答のコンテンツ内に埋め込まれたＣＳＥに返され得る。通知応答を受信すると、ＣＳＥは、通知応答を処理し、通知応答のコンテンツに埋め込まれた応答を要求の発信側に戻るように再標的化し得る。

別の例では、新しいタイプのイベントが、ｏｎｅＭ２ＭサブスクリプションｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ条件のために定義される。この新しいタイプのイベントは、ｏｎｅＭ２ＭサブスクリプションがＣＳＥからＡＥへの要求の再標的化に使用されることを可能にする。ＡＥは、この新しいタイプのイベントを使用し、ＣＳＥが所与のリソースのために受信する要求をサービス提供されるべきＡＥに再標的化するように、ＣＳＥを構成し得る。トリガされると、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａは、ＣＳＥが通知要求を生成し、サブスクリプションのｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性によって定義される規定標的（例えば、ＡＥ）に通知要求を送信することをもたらし得る。通知のコンテンツは、サブスクリプションの親リソースをもととも標的化する１つ以上の埋め込まれた要求と、ＣＳＥが再標的化していることとを含み得る。通知を受信すると、受信側（例えば、ＡＥ）は、通知のコンテンツに埋め込まれた再標的化された要求を処理し得、応答は、通知応答のコンテンツ内に埋め込まれてＣＳＥに返され得る。通知応答を受信すると、ＣＳＥは、通知応答を処理し、通知応答のコンテンツに埋め込まれた応答を要求の発信側に戻るように再標的化し得る。

図１９に図示されるような＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースタイプのための新しいｏｎｅＭ２Ｍ属性、すなわち、ｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐが、本明細書に開示される（表４も参照）。この属性は、ＡＥが、それがＣＳＥにパブリッシュするコンテンツのためのＡＥ定義タイムスタンプを構成することを可能にする。これは、ＡＥが、コンテンツがＡＥによって実際にパブリッシュされ、ＣＳＥ上で作成された時間と異なり得るコンテンツがＡＥによって作成された時間をパブリッシュすることを可能にする。これは、ＡＥがコンテンツをバッファし、以降のある時にそれをＣＳＥにパブリッシュし得るユースケースのために重要であり得る。ＡＥがこの時間をＣＳＥにパブリッシュすることを可能にすることは、コンテンツがＣＳＥにパブリッシュされたときと対比して、それが発信元ＡＥによって実際に生成または収集されたときに関する追加の情報を、このコンテンツへのアクセスを要求する他のＡＥに提供する。

新しいタイプのＲＥＴＡＲＧＥＴ動作のためのサポートを追加するためのｏｎｅＭ２Ｍ＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースへの強化が本明細書に開示され、ＲＥＴＡＲＧＥＴ動作は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの特権属性のｏｎｅＭ２Ｍ定義ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓパラメータによってサポートされ得る。表５は、新しいＲＥＴＡＲＧＥＴ動作を捕捉する。このＲＥＴＡＲＧＥＴ動作は、特定の発信側からの要求がＣＳＥによって再標的化されるための特権を有するかどうかを定義するために使用され得る。ＲＥＴＡＲＧＥＴ動作がａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓリスト内で定義される場合、再標的化が有効にされ、そうでなければ無効にされる。有効にされた場合、ＣＳＥは、要求をＡＥ等の規定エンティティに再標的化し得る。本明細書で議論されるように、再標的化された要求を受信するエンティティを規定するためのいくつかの方法がある。例えば、ｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性が、１つの方法であり、ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩが、別の方法である。

本明細書に開示される提案される鮮度機構を実現することに役立つために、ｏｎｅＭ２Ｍ要求および応答メッセージへの以下の強化が定義される。ｏｎｅＭ２Ｍ通知要求の構造は、ｍ２ｍ：ｎｏｔｉｆｉｃａｔｉｏｎデータタイプおよび対応する通知スキーマファイルによって定義され得る。

本開示は、ｃｏｎｔｅｎｔＲｅｑｕｅｓｔ、ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ、ｆｒｅｓｈｎｅｓｓＴｉｍｅ、ｃｏｎｔｅｎｔＰｒｉｏｒｉｔｙ、およびｃｏｎｔｅｎｔＳｃｈｅｄｕｌｅ要素を、ｍ２ｍ：ｎｏｔｉｆｉｃａｔｉｏｎデータタイプならびに対応する通知スキーマファイルに追加することと、通知をＡＥに送信して、ＡＥに、鮮度ベースのプロシージャによって定義されるように新鮮なコンテンツをＣＳＥに提供させることをサポートすることとを議論する。要求されたコンテンツは、通知応答を介して、要求ＣＳＥに返され得るか、または代替として、ＡＥは、要求ＣＳＥ上でコンテンツを更新または作成するための別個の要求を継続し得る。本明細書では、ｃｏｎｔｅｎｔＳｃｈｅｄｕｌｅが、コンテンツの鮮度が期待される期待期間を含み得ることが考慮される。例えば、ｃｏｎｔｅｎｔＳｃｈｅｄｕｌｅは、周期的スケジュール（例えば、５分の間隔で出現もしくは発生する）、または特定の時間および日付等の非周期的スケジュール（例えば、５月５日の１３時、７月７日の１０時等）であり得る。ＣＳＥは、受信される要求のパターン（例えば、１つ以上のコンテンツ要求アプリケーションから特定のＣＳＥまたは同様に位置するＣＳＥへの要求の中の複数の鮮度期間を分析すること）を介して、スケジュール（例えば、閾値期間）に基づいてコンテンツソースアプリケーションから新鮮な読み取り値を受信する必要があろうことを決定し得る。これは、コンテンツソースアプリケーションがスケジュールに基づいてコンテンツ更新を積極的に送信するであろうため、ＣＳＥからの要求の数を削減し得る。スケジュールは、コンテンツソース（例えば、コンテンツソーシング２０２）からの更新の頻度を増加または減少させ得る。コンテンツソースが議論されるが、これらの原理は、要求受信アプリケーションを伴う状況にも適用され得る（例えば、アクチュエータを伴い得る図１２）。

ＣＳＥが、ｏｎｅＭ２Ｍ通知要求を介して、ＡＥへの作成、読み出し、更新、削除、サブスクライブ、および発見要求を開始または再標的化することを可能にするｃｒｅａｔｅＲｅｑｕｅｓｔ、ｒｅｔｒｉｅｖｅＲｅｑｕｅｓｔ、ｕｐｄａｔｅＲｅｑｕｅｓｔ、ｄｅｌｅｔｅＲｅｑｕｅｓｔ、ｄｉｓｃｏｖｅｒＲｅｑｕｅｓｔ、および、ｓｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔ要素の追加も本明細書で議論され、ＡＥは、これらの要求にサービス提供し、ｏｎｅＭ２Ｍ通知応答を介して応答をＣＳＥに返し得る。

ｏｎｅＭ２Ｍは、現在、そのリリース１仕様（その全体として参照することによって組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ２．６．０）でデバイストリガ特徴を定義している。しかしながら、ｏｎｅＭ２Ｍは、ＣＳＥから３ＧＰＰ等の下層ネットワーク機能によってサポートされるデバイストリガ機能に送信されるデバイストリガ要求メッセージのメッセージフォーマットをまだ定義していない。

表６で定義されるものに類似する要素も、新しいデバイストリガ要求要素としても見なされるべきである。そうすることで、ｏｎｅＭ２Ｍデバイストリガ要求は、本開示で定義される鮮度ベースのコンテンツ読み出しおよび発見プロシージャのために読み出しまたは通知要求を使用することの別の代替物として、使用され得る。これは、鮮度ベースのコンテンツ読み出しまたは発見要求が、現在ＣＳＥに到達可能ではないデバイス上でホストされるコンテンツソーシングＡＥに対して開始されるために好ましい（または開始される必要がある）ユースケースに特に適用可能であり得る。この場合、ＣＳＥは、コンテンツソーシングＡＥへのデバイストリガ要求を開始し、同時に、トリガ要求に鮮度ベースのコンテンツ読み出し要素を埋め込み得る。同様に、同一の機能性が、要求を要求受信ＡＥに転送するために使用され得る。

開示される鮮度機構を実現するために、ｏｎｅＭ２Ｍプロシージャへの以下の強化が、図１４を参照して定義される。

ｏｎｅＭ２Ｍ ＣＳＥ（例えば、ＣＳＥ３０４）は、ＡＥが、随意に、所与のリソースのためのｐｏｉｎｔＯｆＣｏｎｔａｃｔアドレスを規定することを可能にする能力をサポートするように強化され得る。例えば、ＡＥは、＜ｃｏｎｔａｉｎｅｒ＞リソースのｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性を構成し得る。ｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性を構成することによって、ＡＥは、ＡＥが所与のリソースに関連付けられる要求を受信し、サービス提供する能力をサポートすることを、ＣＳＥ３０４に示し得る。例えば、ＡＥは、所与の＜ｃｏｎｔａｉｎｅｒ＞リソースのための新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を作成する要求を受信し得る。

ＣＳＥ３０４は、ＣＳＥ３０４が、標的リソースのローカルに記憶された表現を使用して、それ自身で要求にサービス提供するときと対比して、サービス提供すべきコンテンツソーシングＡＥ３０２に要求を送信するときを決定する異なる方法をサポートし得る。１つのそのような方法は、ｏｎｅＭ２Ｍ定義ｃｒｅａｔｅｄＡｆｔｅｒフィルタパラメータを使用して読み出し要求内で規定される鮮度時間を伴い得る。この要求パラメータを使用して、要求側は、要求の中で鮮度タイムスタンプを規定し得る。ＣＳＥ３０４は、このｃｒｅａｔｅｄＡｆｔｅｒフィルタパラメータに対して、標的リソースの１つ以上のローカルに記憶された表現のｃｒｅａｔｉｏｎＴｉｍｅ（および／または提案されるｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐ属性）を比較し得る。ｃｒｅａｔｉｏｎＴｉｍｅがｃｒｅａｔｅｄＡｆｔｅｒタイムスタンプよりも新しい（より最近または適時である）ことが見出された場合、ＣＳＥ３０４は、コンテンツソーシングＡＥ３０２を伴うことなく、それ自身で要求にサービス提供し得る。しかしながら、ｃｒｅａｔｉｏｎＴｉｍｅがより古い場合、ＣＳＥ３０４は、読み出し要求にサービス提供するリソース表現の新鮮なバージョンを取得し、その規定鮮度選好または要件を満たそうとして、対応するコンテンツソーシングＡＥ２０２のｐｏｉｎｔＯｆＣｏｎｔａｃｔへの要求を開始し得る。

図１４は、例示的ｏｎｅＭ２Ｍ鮮度ベースのコンテンツ読み出しメッセージフローを図示する。このプロシージャは、ｏｎｅＭ２Ｍ＜ｃｏｎｔａｉｎｅｒ＞および＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースタイプを使用して示されているが、類似プロシージャは、＜ｆｌｅｘＣｏｎｔａｉｎｅｒｓ＞、ｍｇｍｔＯｂｊ、ｍｇｍｔＣｍｄ等の他のｏｎｅＭ２Ｍリソースタイプにも使用され得る。

ステップ３１０では、コンテンツソーシングＡＥ３０２およびコンテンツ要求ＡＥ３０６は、認証し、次いで、ＣＳＥ３０４に登録する。コンテンツ要求ＡＥ３０６は、次いで、コンテンツソーシングＡＥ３０２を発見する。ステップ３１１−３１３では、コンテンツソーシングＡＥ３０２は、＜ｃｏｎｔａｉｎｅｒ＞リソースを作成し、そのｐｏｉｎｔＯｆＣｏｎｔａｃ情報（例えば、ＵＲＩ）を構成する。ステップ３１１では、コンテンツソーシングＡＥ３０２は、＜ｃｏｎｔａｉｎｅｒ＞作成を送信し、ｐｏｉｎｔＯｆＣｏｎｔａｃｔメッセージを構成し、メッセージは、以下のうちの１つ以上のものを有し得る、：（ｔｏ＝＜ＡＥ＞、ｐｏｉｎｔＯｆＣｏｎｔａｃｔ＝Ｓｏｕｒｃｅ ＡＥ Ａｄｄｒ Ｉｎｆｏ）。ステップ３１２では、ＣＳＥ２０４は、＜ｃｏｎｔａｉｎｅｒ＞リソースを作成し、ステップ３１１に基づいて、ソースＡＥのｐｏｉｎｔＯｆＣｏｎｔａｃｔ情報を構成する。ステップ３１３では、ＣＳＥ３０４は、要求の一般的確認応答または要求の完了を含み得る応答メッセージを送信し得る。

図１４のステップ３１４−３１６では、コンテンツソーシングＡＥ３０２は、＜ｃｏｎｔａｉｎｅｒ＞リソース内で１つ以上の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞子リソースを作成する。各＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞は、ＣＳＥ３０４によって作成および記憶される（ステップ３１５）。コンテンツソーシングＡＥ３０２は、コンテンツインスタンス（例えば、センサ読み取り値）がコンテンツソーシングＡＥ３０２によって生成または捕捉されたときのｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐも提供し得る。加えて、ＣＳＥ３０４は、コンテンツインスタンスがＣＳＥ３０４の中で作成された時間を示すｃｒｅａｔｉｏｎＴｉｍｅを＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞に割り当て得る。

図１４を継続して参照すると、ステップ３１７−３１９では、コンテンツソーシングＡＥ３０２は、＜ｃｏｎｔａｉｎｅｒ＞にサブスクライブすることにより、読み出し要求がｓｕｂｓｃｒｉｂｅｄ−ｔｏ＜ｃｏｎｔａｉｎｅｒ＞リソースの最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を読み出すために試行され、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースが存在しないか、またはそのｃｒｅａｔｉｏｎＴｉｍｅが読み出し要求のｃｒｅａｔｅｄＡｆｔｅｒｆｉｌｔｅｒＣｒｉｔｅｒｉａ内で規定される時間よりも古いかのいずれかである度に、ＣＳＥ３０４から通知を受信し得る。これを行うために、コンテンツソーシングＡＥ３０２は、本明細書で定義される新しいフォーマット通りに、サブスクリプションの通知ｅｖｅｎｔＴｙｐｅおよびコンテンツタイプを構成し得る。ステップ３１７では、コンテンツソーシングＡＥは、サブスクリプションを作成するメッセージを送信し、メッセージは、以下の情報、（ｔｏ＝＜ｃｏｎｔａｉｎｅｒ＞）を有し得る。ステップ３１８では、ＣＳＥ３０４は、（ステップ３１７に応答して）＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成する。ステップ３１９では、応答が送信され得る。

図１４のステップ３２０では、コンテンツ要求ＡＥ３０６は、コンテンツソーシングＡＥ３０２の標的＜ｃｏｎｔａｉｎｅｒ＞の中に記憶された最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースを読み出すための要求をＣＳＥ３０４に発行する。要求の中に、時間および日付情報を含み得る規定ｃｒｅａｔｅｄＡｆｔｅｒパラメータが含まれる。コンテンツ要求ＡＥ３０６は、このパラメータを使用して、それが規定時間および日付以後のコンテンツを要求することを規定し得る。ステップ３２１では、ＣＳＥ３０４は、＜ｃｏｎｔａｉｎｅｒ＞リソース内に記憶された最新の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞（存在する場合）のｃｒｅａｔｉｏｎＴｉｍｅ（またはｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐ）に対して、要求のｃｒｅａｔｅｄＡｆｔｅｒパラメータ内の規定時間および日付情報を比較する。この比較から、ＣＳＥ３０４は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が利用可能であるかどうかを決定し、該当する場合、コンテンツ要求ＡＥ３０６の鮮度要件を満たすかどうかを決定する。図のブロック３２３内のステップ３２２では、ＣＳＥ３０４が規定ｃｒｅａｔｅｄＡｆｔｅｒ要件を満たす＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を見出す場合、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を含む応答をコンテンツ要求ＡＥ３０６に返し得る。この場合、ＣＳＥ３０４は、コンテンツソーシングＡＥ３０２への要求を開始し、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得する必要がない。

図１４を継続して参照すると、記憶されたコンテンツインスタンスが鮮度選好または要件を満たさない場合、ブロック３２４に進む。ステップ３２５では、ＣＳＥ３０４が規定ｃｒｅａｔｅｄＡｆｔｅｒ要件（すなわち、閾値期間）を満たす＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を見出さない場合、ＣＳＥ３０４がコンテンツソーシングＡＥ３０２から新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得しようとしている間に、コンテンツ要求ＡＥ３０６がブロックして待機することを要求されないように、ＣＳＥ３０４は、確認応答（すなわち、非ブロック応答）をコンテンツ要求ＡＥ３０６に返し得る。ステップ３２５のこの確認応答（すなわち、非ブロック応答）は、要求が受信され、ＣＳＥ３０４がコンテンツ要求ＡＥ３０６の鮮度要件を満たしたローカルにホストされた＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を有していなかったので、依然として処理されていることを示すステータスを含み得る。ステップ３２５の確認応答は、ＣＳＥコールバックアドレス（例えば、ＵＲＩ）も含み得、それは、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を読み出すために、または、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が利用可能になったときにそれを受信するためにサブスクライブするために、コンテンツ要求ＡＥ３０６によって使用され得る。例えば、コンテンツ要求ＡＥ３０６は、このアドレスに周期的にポーリングするか、またはこのアドレスにサブスクライブし（ステップ３２６参照）、ＣＳＥ３０４がコンテンツソーシングＡＥ３０２から新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得することができた場合、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を受信するか、または、ＣＳＥ３０４がコンテンツソーシングＡＥ３０２から新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得することに失敗した場合、エラー状態を受信し得る。代替として、ＣＳＥ３０４は、ブロック様式で要求を処理することを選定し得、その場合、ステップ３２５では確認応答をコンテンツ要求ＡＥ３０６に返さないであろう。代わりに、それは、図１４で表示されるようなこのプロシージャにおけるステップ３３１まで、コンテンツ要求ＡＥ３０６に応答することを控えるであろう。

図１４のステップ３２７では、ＣＳＥ３０４は、コンテンツソーシングＡＥ３０２への要求を開始し、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を要求する。この要求は、いくつかの異なるタイプの提案される要求のうちの１つを使用して、コンテンツソーシングＡＥ３０２に配信され得る。第１の提案される要求を参照すると、ＣＳＥ３０４は、ステップ３１１でコンテンツソーシングＡＥ３０２によって規定されたｐｏｉｎｔＯｆＣｏｎｔａｃｔを標的化する読み出し要求を開始し得る。この要求は、コンテンツ要求ＡＥ３０６からのオリジナル要求の中の１つと同一のタイムスタンプで構成され得るｃｒｅａｔｅｄＡｆｔｅｒパラメータを含み得る。代替として、ＣＳＥ３０４は、ステップ３１７で説明されるサブスクリプション要求がコンテンツソーシングＡＥ３０２によって実施された場合、コンテンツソーシングＡＥ３０２への通知要求を開始し得る。この通知は、表６に関連付けられる議論等の本明細書に開示されるもの等の要素を含み得る。

図１４のステップ３２８では、ＣＳＥ３０４からステップ３２７の要求を受信すると、コンテンツソーシングＡＥ３０２は、要求のタイプ（例えば、読み出しまたは通知）を処理して検出し得る。ステップ３２７の要求が読み出しである場合、コンテンツソーシングＡＥ３０２は、要求の中に存在する場合、規定アドレスおよびｃｒｅａｔｅｄＡｆｔｅｒパラメータを分析し、要求されているコンテンツを決定し、次に、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を準備し、読み出し応答の中でＣＳＥ３０４に返し得る。要求が通知である場合、コンテンツソーシングＡＥ３０２は、ｃｏｎｔｅｎｔＲｅｑｕｅｓｔ要素が存在し、ＴＲＵＥに構成されているかどうかをチェックすることによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングＡＥ３０２が、２つ以上のタイプのコンテンツをサポートする場合、ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ要素をチェックし、ＣＳＥ３０４によって要求されているコンテンツのタイプを検出し得る。それは、次いで、ｃｏｎｔｅｎｔＰｒｉｏｒｉｔｙまたはｃｏｎｔｅｎｔＳｃｈｅｄｕｌｅ要素をチェックし、ＣＳＥ３０４に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を提供しなければならないときを決定し得る。コンテンツソーシングＡＥ３０２は、ｃｏｎｔｅｎｔＦｒｅｓｈｎｅｓｓパラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。１つが規定される場合、コンテンツソーシングＡＥ３０２は、それが提供する任意の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が、この日付および時間の前に生成されなかったことを確認し得る。

図１４のステップ３２９では、コンテンツソーシングＡＥ３０２は、いくつかの方法のうちの１つにおいて、新鮮なコンテンツインスタンスでＣＳＥ３０４を更新し得る。ＣＳＥ３０４が、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を要求する明示的読み出し要求をコンテンツソーシングＡＥ３０２に発行する場合、コンテンツソーシングＡＥ３０２は、読み出し応答の中に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を含み得る。ＣＳＥ３０４が、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が必要とされることを示す通知をコンテンツソーシングＡＥ３０２に発行する場合、コンテンツソーシングＡＥ３０２は、通知応答の中に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を含み得るか、または代替として、コンテンツソーシングＡＥ３０２は、別個の要求（例えば、作成要求）を継続し、通知要求の中でｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃ要素によって規定される＜ｃｏｎｔａｉｎｅｒ＞リソースの中で新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を作成し得る。ステップ３３０では、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が正常に返された場合、または作成された場合、ＣＳＥ３０４は、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のローカルバージョンが、将来の要求にサービス提供するために活用され得るか、またはとりわけ、課金および分析等の目的のために使用され得るように、それを記憶する。ＣＳＥ３０４は、随意に、対応するタイムスタンプを割り当て、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞がＣＳＥ３０４の中で作成されたときを記録し得る。ステップ３３１では、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞がＣＳＥ３０４に正常にパブリッシュされた場合、コンテンツ要求ＡＥ３０６に返され、そうでなければ、エラーが代わりに返される。

以下は、図１５を参照して、開示される鮮度ベースのコンテンツ発見側面を追加することによって、既存のｏｎｅＭ２Ｍ定義リソース発見プロシージャを強化する。機構は、ＣＳＥ３０４が、コンテンツ要求ＡＥ３０６に着目される＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースが、古いとき、またはそうではないときを検出し、対応するコンテンツソーシングＡＥ３０２にコンタクトし、それに新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を提供させ、そして、ＣＳＥ３０４が発見応答の中で新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を参照し得ることを可能にする。図１５は、例示的ｏｎｅＭ２Ｍ鮮度ベースのリソース発見メッセージフローを図示する。このプロシージャは、ｏｎｅＭ２Ｍ＜ｃｏｎｔａｉｎｅｒ＞および＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースタイプを使用して示されているが、類似プロシージャは、＜ｆｌｅｘＣｏｎｔａｉｎｅｒｓ＞、ｍｇｍｔＯｂｊ、ｍｇｍｔＣｍｄ等の他のｏｎｅＭ２Ｍリソースタイプにも使用され得る。

図１５のブロック３４０は、図１４に関して示され、議論されるものと同一のステップ３１０−３１９を有する。図１５のステップ３４１では、コンテンツ要求ＡＥ３０６は、特定の＜ｃｏｎｔａｉｎｅｒ＞リソースに関連付けられる＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースを発見するためにＣＳＥ３０４に要求する。要求の中に、コンテンツ要求ＡＥ３０６が規定時間および日付以後のコンテンツを発見することを所望することを規定するために使用する時間および日付情報で構成される規定ｃｒｅａｔｅｄＡｆｔｅｒパラメータが含まれ得る。加えて、要求は、他の発見フィルタ基準（例えば、コンテンツのタイプ）も含み得る。ステップ３４２では、ＣＳＥ３０４は、標的＜ｃｏｎｔａｉｎｅｒ＞リソース内のＣＳＥ３０４によってホストされる各適用可能＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースのタイムスタンプに対して、コンテンツ発見要求のｃｒｅａｔｅｄＡｆｔｅｒパラメータ内の規定時間および日付情報を比較する。この比較から、ＣＳＥ３０４は、適用可能な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースのうちのいずれかが、規定ｃｒｅａｔｅｄＡｆｔｅｒパラメータよりも新しいｃｒｅａｔｉｏｎＴｉｍｅまたはｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐを有するかどうかを決定する。何も見出されない場合、ＣＳＥ３０４が、コンテンツ要求ＡＥ３０６に送信する発見応答の中にこのコンテンツの参照（例えば、ＵＲＩ）を含み得、ＣＳＥ３０４が、コンテンツ要求ＡＥ３０６が＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞にアクセスする後続の要求を送信するときに準備完了して利用可能であるコンテンツを有するように、ＣＳＥ３０４は、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が対応するコンテンツソーシングＡＥから要求されることをシグナリングするイベントを生成し得る。このイベントは、ひいては、図１４に関して規定されるｏｎｅＭ２Ｍ鮮度ベースのコンテンツ読み出しプロシージャにおけるステップ３２５−３３０で概説される提案されるプロシージャによって定義されるように、コンテンツソーシングＡＥ３０２から新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を取得することを試みるためのトリガとして、ＣＳＥ３０４によって使用され得る。トリガの生成は、適用可能なｐｏｉｎｔＯｆＣｏｎｔａｃｔ属性が標的＜ｃｏｎｔａｉｎｅｒ＞リソースの中で構成されているかどうかに基づいて制限され得る。いかなるｐｏｉｎｔＯｆＣｏｎｔａｃｔも構成されていない場合、トリガは抑制され得る。

図１５を継続して参照すると、ブロック３４４のステップ３４３では、ＣＳＥ３０４がｃｒｅａｔｅｄＡｆｔｅｒタイムスタンプを満たす＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を見出す場合、発見応答の中にこのコンテンツの参照（例えば、ＵＲＩ）を含む応答をコンテンツ要求ＡＥ３０６に返し得る。この場合、ＣＳＥ３０４は、そのローカルに記憶された＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースをリフレッシュすることを開始する必要がない。

ブロック３４５は、記憶されたコンテンツインスタンスが、鮮度選好または要件を満たさないときに起こり、これは、オンデマンドリフレッシュを開始し得る。ブロック３４６は、図１４のステップ３２５−３３０と同一のステップを含む。ステップ３４７では、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞がコンテンツソーシングＡＥ３０２からＣＳＥ３０４に正常にパブリッシュされた場合、このコンテンツの参照（例えば、ＵＲＩ）は、発見応答の中で返され、そうでなければ、エラーが代わりに返される。ステップ３４８では、コンテンツ要求ＡＥ３０６は、発見応答を処理し、続いて、（応答の中の規定参照に基づいて）その鮮度選好または要件を満たす発見されたコンテンツインスタンスのうちの１つ以上のものを読み出す。

以下のプロシージャは、図１６を参照して、本明細書に開示される鮮度ベースのコンテンツ読み出し側面を追加することによって、既存のｏｎｅＭ２Ｍ定義デバイストリガプロシージャを強化する。機構は、ＣＳＥが、コンテンツ要求ＡＥに着目される＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースが、古いとき、またはそうではないときを検出し、ひいては、（デバイストリガを介して）対応するコンテンツソーシングＡＥ３０２にコンタクトし、ＣＳＥ３０４が読み出し要求のその処理を完了し得るように、コンテンツソーシングＡＥ３０２に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を提供させることを可能にする。このプロシージャは、ｏｎｅＭ２Ｍ＜ｃｏｎｔａｉｎｅｒ＞および＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースタイプを使用して示されているが、類似プロシージャは、＜ｆｌｅｘＣｏｎｔａｉｎｅｒｓ＞、ｍｇｍｔＯｂｊ、ｍｇｍｔＣｍｄ等の他のｏｎｅＭ２Ｍリソースタイプにも使用され得る。図１７のブロック３５０は、図１４および図１５の非シナリオＢブロック３５１のステップ（例えば、図１４のステップ３１０−３２２）に類似するステップを含む。

図１６を継続して参照すると、ステップ３５２では、ＣＳＥ３０４は、コンテンツソーシングＡＥ３０２へのデバイストリガ要求を開始し、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を要求する。ステップ３５２のデバイストリガ要求は、ＣＳＥ３０４から、下層ネットワーク（例えば、３ＧＰＰ ＭＴＣ−ＩＷＦ）によってサポートされるデバイストリガ機能３０３に送信され得る。ステップ３５２のデバイストリガ要求メッセージは、デバイストリガに関して本明細書に開示されるような要素を含み得る。ステップ３５３では、デバイストリガ要求を受信することに応答して、コンテンツソーシングＡＥ３０２は、それを処理し得る。コンテンツソーシングＡＥ３０２は、ｃｏｎｔｅｎｔＲｅｑｕｅｓｔ要素が存在し、ＴＲＵＥに構成されているかどうかをチェックすることによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングＡＥ３０２が２つ以上のタイプのコンテンツをサポートする場合、ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ要素をチェックし、ＣＳＥ３０４によって要求されているコンテンツのタイプを検出し得る。それは、次いで、ｃｏｎｔｅｎｔＰｒｉｏｒｉｔｙまたはｃｏｎｔｅｎｔＳｃｈｅｄｕｌｅ要素をチェックし、ＣＳＥ３０４に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を提供しなければならないときを決定し得る。それは、ｃｏｎｔｅｎｔＦｒｅｓｈｎｅｓｓパラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。１つが規定される場合、コンテンツソーシングＡＥ３０２は、それが提供する任意の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が、この日付および時間の前に生成されなかったことを確認し得る。

ステップ３５５では、コンテンツソーシングＡＥ３０２は、いくつかの方法のうちの１つにおいて、新鮮なコンテンツインスタンスでＣＳＥ３０４を更新し得る。コンテンツソーシングＡＥ３０２は、デバイストリガ応答の中に新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を含み得るか、または代替として、コンテンツソーシングＡＥ３０２は、ＣＳＥ３０４への別個の要求（例えば、作成要求）を継続し、トリガ要求の中でｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃ要素によって規定される＜ｃｏｎｔａｉｎｅｒ＞リソースの中で新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を作成し得る。ステップ３５７では、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が正常に返された場合、または作成された場合、ＣＳＥ３０４は、新鮮な＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のローカルバージョンが、将来の要求にサービス提供するために活用され得るように、それを記憶する。図１６のブロック２５９は、図１４のステップ３３１または図１５のステップ２４７および２４８で規定される、鮮度ベースのコンテンツ読み出しならびに発見プロシージャで定義されるものと同一のステップを有する。

以下のプロシージャは、図１７を参照して、本明細書に開示される、とりわけ、再標的化機能性に基づいて既存のｏｎｅＭ２Ｍ定義リソースプロシージャを強化する。機構は、ＣＳＥ３０４が、標的リソースが更新されるときを検出し、要求を対応する要求受信ＡＥに再標的化し、要求受信ＡＥにそのローカルバージョンを更新させることを可能にする。このプロシージャは、ｏｎｅＭ２Ｍ＜ｍｇｍｔＯｂｊ＞リソースタイプを使用して示されているが、類似プロシージャは、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒｓ＞、＜ｍｇｍｔＣｍｄ＞等の他のｏｎｅＭ２Ｍリソースタイプにも使用され得る。

図１７を継続して参照すると、ステップ３６０では、要求受信ＡＥ３０７および要求開始ＡＥ３０９は、認証し、次いで、ＣＳＥ３０４に登録する。要求開始ＡＥ３０９は、次いで、要求受信ＡＥ３０７を発見する。ステップ３６１−３６３では、要求受信ＡＥ３０７は、ソフトウェア＜ｍｇｍｔＯｂｊ＞リソースを作成し、そのｐｏｉｎｔＯｆＣｏｎｔａｃｔ情報（例えば、ＵＲＩ）およびそのａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｉｅｓを構成する。これらのポリシは、要求を要求受信ＡＥ３０７に発行することを可能にされる要求開始ＡＥ２０９のリスト、再標的化されることを可能にされる許容要求タイプのリスト、要求が再標的化され得る時間を定義するスケジュール等の再標的化規則を含み得る。ステップ３６４−３６６では、要求受信ＡＥ３０７は、＜ｍｇｍｔＯｂｊ＞にサブスクライブすることにより、ＵＰＤＡＴＥ要求が試行され、ＵＰＤＡＴＥが、（ｒｅ−ｔａｒｇｅｔＰｏｌｉｃｉｅｓで規定されるように）要求受信ＡＥ３０７が着目する＜ｍｇｍｔＯｂｊ＞リソース属性のうちの１つの状態を変化させる度に、ＣＳＥ３０４から通知を受信し得る。これを行うために、要求受信ＡＥ３０７は、本明細書で定義される、新たに提案されるフォーマット通りに、サブスクリプションの通知ｅｖｅｎｔＴｙｐｅおよびコンテンツタイプを構成し得る。ステップ３６７では、要求開始ＡＥは、ａｃｔｉｖａｔｅ属性を＜ｍｇｍｔＯｂｊ＞リソースの中の「ＴＲＵＥ」の値に更新（ＵＰＤＡＴＥ）するための要求をＣＳＥ３０４に発行する。

図１７のステップ３６８では、ＣＳＥ３０４は、要求開始ＡＥ３０９の要求によって標的化されるリソースの再標的化ポリシを分析する。これらのポリシを使用して、ＣＳＥ３０４は、とりわけ、要求開始ＡＥ３０９が要求を要求受信ＡＥ３０７に発行する権限を与えられているかどうか、要求タイプが再標的化される権限を与えられているものであるかどうか、および規定スケジュールに基づいて要求を要求受信ＡＥ３０７に再標的化するときの決定等のチェックを実施し得る。ＣＳＥ３０４は、次いで、ＵＰＤＡＴＥ要求の中に含まれる表現に対して、サービス層の中に記憶された＜ｍｇｍｔＯｂｊ＞リソースの現在の表現を比較する。この比較は、ある属性のみが互いと比較されるように、比較する（または比較しない）複数のリソース属性のうちの一部を定義するマスクを考慮し得る。比較は、ａｃｔｉｖａｔｅ属性の状態の変化に起因して、不一致をもたらす。故に、ＣＳＥ３０４は、ＵＰＤＡＴＥ要求を要求受信ＡＥ３０７に再標的化する必要があることを決定する。

図１７のステップ３６９では、ＣＳＥ３０４は、ＵＰＤＡＴＥ要求を、サービス提供されるべき要求受信ＡＥ３０７に再標的化する。この要求は、いくつかの異なるタイプの提案される要求のうちの１つを使用して、要求受信ＡＥ３０７に配信され得る。ＣＳＥ３０４は、ステップ３６１で要求受信ＡＥ３０７によって規定されるｐｏｉｎｔＯｆＣｏｎｔａｃｔを標的化するＵＰＤＡＴＥ要求を開始し得る。第２に、サービス層（ＣＳＥ２０４）は、ステップ３６４で説明されるサブスクリプション要求が要求受信ＡＥ３０７によって実施された場合、要求受信ＡＥ３０７への通知要求を開始し得る。この通知は、本明細書に開示されるような要素を含み得る。第３に、ＣＳＥ３０４は、要求受信ＡＥ３０７が到達可能ではない場合、要求受信ＡＥ３０７へのデバイストリガ要求を開始し得る。このデバイストリガ要求は、本明細書に開示されるもの等の要素を含み得る。ステップ３７０では、ＣＳＥ３０４から要求を受信すると、要求受信ＡＥ３０７は、要求のタイプ（例えば、ＵＰＤＡＴＥまたはＮＯＴＩＦＹもしくはＤＥＶＩＣＥ ＴＲＩＧＧＥＲ）を処理して検出し得る。例えば、要求がＵＰＤＡＴＥである場合、要求受信ＡＥ３０７は、規定アドレスを分析し、ＡＥのローカル＜ｍｇｍｔＯｂｊ＞に対して更新を実施し、ＵＰＤＡＴＥ応答の中で応答をＣＳＥ３０４に返し得る。要求がＮＯＴＩＦＹまたはＤＥＶＩＣＥ ＴＲＩＧＧＥＲである場合、要求受信ＡＥ３０７は、ｕｐｄａｔｅＲｅｑｕｅｓｔ要素が存在し、ＴＲＵＥに構成されているかどうかをチェックすることによって、それがＵＰＤＡＴＥに対する要求であることを検出し得る。要求受信ＡＥ３０７が２つ以上のタイプのコンテンツをサポートする場合、ｒｅｑｕｅｓｔＲｅｆｅｒｅｎｃｅ要素をチェックし、ＣＳＥ３０４によって要求されている更新を検出し得る。

図１７のステップ３７１では、要求受信ＡＥ３０７は、いくつかの提案される方法のうちの１つでＣＳＥ３０４に応答し得る。ＣＳＥ３０４が明示的ＵＰＤＡＴＥ要求を要求受信ＡＥ３０７に発行する場合、要求受信ＡＥ３０７は、ＵＰＤＡＴＥ応答で応答し得る。ＣＳＥ３０４がＮＯＴＩＦＹまたはＤＥＶＩＣＥ ＴＲＩＧＧＥＲを要求受信ＡＥ３０７に発行する場合、要求受信ＡＥ３０７は、それぞれ、通知またはデバイストリガ応答で応答し得る。ステップ３７２では、要求受信ＡＥ３０７から応答を受信すると、ＣＳＥ３０４は、リソースのそのローカルバージョンに対して同じ更新を実施する（例えば、状態を「ＯＮ」の値に変更する）。ステップ３７３では、ＣＳＥ３０４は、要求開始ＡＥ３０９に応答し、ＵＰＤＡＴＥ要求が正常に処理されたことを示す。ステップ３７４では、要求開始ＡＥ３０９は、第１のＵＰＤＡＴＥと同じである第２のＵＰＤＡＴＥ要求を送信する。ステップ３７５では、ＣＳＥは、ステップ３６８で説明されるものと類似する処理を実施する。ＣＳＥは、比較が合致をもたらす（「ＯＮ」の更新された値が現在の値と同一である）ことを検出し、ＵＰＤＡＴＥ要求を要求受信ＡＥ３０７に再標的化しないことを決定する。ステップ３７６では、ＣＳＥ３０４は、要求開始ＡＥ３０９からのＵＰＤＡＴＥ要求が、たとえ要求受信ＡＥ３０７に再標的化されなかったとしても処理されたという事実を追跡するためにそのローカルメタデータを更新する。これは、課金および分析等の目的のために、要求開始ＡＥ３０９の要求履歴を追跡するために有用であり得る。ステップ３７７では、ＣＳＥ３０４は、要求開始ＡＥ３０９に応答し、ＵＰＤＡＴＥ要求が正常に処理されたことを示す。

図１８は、鮮度ベースのコンテンツ発見、コンテンツ読み出し、および要求再標的化の概念が、ＣｏＲＥミラーサーバ（すなわち、ミラーサーバ４０４）の中に統合される、例示的ＣｏＲＥミラーサーバ鮮度ベースのコンテンツ読み出しメッセージフローを図示する。ミラーサーバ４０４は、鮮度ベースのコンテンツ発見および読み出し要求をサポートし得、ミラーサーバ４０４は、ミラー化リソースの表現がＧＥＴ要求で規定される鮮度要件を満たす限り、ミラーサーバ４０４が、ミラー化リソース表現を使用して、これらの要求にサービス提供し得る。そうでなければ、ミラーサーバ４０４は、標的リソースの新鮮な表現を取得するための対応するデバイスへのＧＥＴ要求を開始し得、次いで、それを、以下の図１８で捕捉されるプロシージャに図示されるように、オリジナル要求にサービス提供するために使用し得る。本実施形態のための１つの提案されるプロトコルレベル強化は、ＧＥＴ要求が標的化しているリソース表現の要求される鮮度（例えば、日付および時間値）を特定するように、ＧＥＴ要求内で構成され得る（ステップ４１６に示されるような）新しい鮮度パラメータの定義を含む。鮮度パラメータは、ＵＲＩクエリ文字列の中に含まれ得るクエリ文字列パラメータとして実現され得る。代替として、鮮度パラメータは、新しいＣｏＡＰヘッダオプション（または代替として、それがミラーサーバ４０４によって使用されている場合はＨＴＴＰ）として実現され得る。

図１８を継続して参照すると、ステップ４１０では、ＳＥＰ４０２は、ミラーサーバ４０４に登録し、ＳＥＰ４０２がローカルに記憶し、それの代わりにミラーサーバ４０４がミラー化することを所望するサポートされたリソースのリストを提供する。ステップ４１１では、ミラーサーバ４０４は、ＳＥＰ４０２のリソースのミラー化バージョンを作成し、ＳＥＰ４０２によってローカルにホストされる情報のディレクトリ（例えば、各リソースのＵＲＩ）も維持する。ステップ４１２では、ミラーサーバ４０４は、ＳＥＰ４０２に応答し、ミラー化リソースのリストを含む。ステップ４１３−４１５では、ＳＥＰ４０２は、ミラーサーバ４０４上の１つ以上のミラー化リソースを更新する。各更新は、ミラーサーバ４０４によって記憶される。ＳＥＰ４０２は、コンテンツ（例えば、センサ読み取り値）がＳＥＰ４０２によって生成または捕捉されたときのｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐも提供し得る。ミラーサーバ４０４も、コンテンツインスタンスがミラーサーバ４０４において更新された時間を示すｃｒｅａｔｉｏｎＴｉｍｅをミラー化リソースに割り当て得る。ステップ４１６では、クライアント４０６は、ミラーサーバ４０４によってホストされるミラー化リソースを読み出すための要求をミラーサーバ４０４に発行する。要求の中に、時間および日付情報で構成される規定鮮度パラメータが含まれ得る。クライアント４０６は、それが規定時間および日付以後のコンテンツを要求することを規定するこのパラメータを含み得る。

図１８のステップ４１７では、ミラーサーバ４０４は、ミラーサーバ４０４によってホストされるミラー化リソースＡ（存在する場合）のｃｒｅａｔｉｏｎＴｉｍｅ（またはｃｏｎｔｅｎｔＴｉｍｅｓｔａｍｐ）に対して、要求の鮮度パラメータ内の規定時間および日付情報を比較する。この比較から、ミラーサーバ４０４は、リソースＡが利用可能であるかどうかを決定し、該当する場合、クライアント４０６の鮮度要件を満たすかどうかを決定する。ブロック４１９内のステップ４１８では、ミラーサーバ４０４が規定鮮度要件を満たすミラー化リソースＡを見出す場合、リソースＡの表現を含む応答をクライアント４０６に返し得る。この場合、ミラーサーバ４０４は、ＳＥＰ４０２への要求を開始し、リソースＡの新鮮な表現を取得する必要がない。

ブロック４２０は、ミラー化リソースが鮮度要件を満たさないときに起こり、これは、オンデマンドリフレッシュを開始する。ステップ４２１では、ミラーサーバ４０４が規定鮮度要件を満たすミラー化リソースＡを見出さない場合、随意に、クライアント４０６がブロックして待機することを要求されない一方、ミラーサーバ４０４が、ＳＥＰ４０２から新鮮なリソースを取得しようとするように、確認応答をクライアント４０６に返し得る。この確認応答は、要求が受信され、ミラーサーバ４０４がクライアント４０６の鮮度選好または要件を満たしたリソースＡのローカルにホストされたミラー化バージョンを有していなかったので、依然として処理されていることを示すステータスを含み得る。確認応答は、利用可能になるとき、新鮮なリソースＡを受信するためにクライアント４０６によって使用され得るミラーサーバ４０４コールバックアドレス（例えば、ＵＲＩ）を含み得る。例えば、クライアント４０６は、このアドレスに周期的にポーリングし、またはそれを観察し、ミラーサーバ４０４がＳＥＰ４０２から新鮮なリソースＡを取得することができるとき、新鮮なリソースＡを受信し、ミラーサーバ４０４がＳＥＰ４０２から新鮮なリソースＡを取得することに失敗した場合、エラー状態を受信し得る。代替として、ミラーサーバ４０４は、ブロック様式で要求を処理することを選定し得、その場合、このステップでは確認応答をクライアント４０６に返さないであろう。代わりに、それは、このプロシージャにおけるステップ４２６まで、クライアント４０６に応答することを控えるであろう。

図１８を継続して参照すると、ステップ４２２では、ミラーサーバ４０４は、ＳＥＰ４０２への要求を開始し、新鮮なリソースＡを要求する。この要求は、ＧＥＴ要求を使用して、ＳＥＰ４０２に配信され得る。ミラーサーバ４０４は、ステップ４１０におけるＳＥＰ４０２によって規定されたＵＲＩを標的化する読み出し要求を開始し得る。この要求は、クライアント４０６からのオリジナル要求の中の１つと同一のタイムスタンプで構成され得る随意の鮮度パラメータも含み得る。ステップ４２３では、ステップ４２２の要求を受信すると、ＳＥＰ４０２は、要求を処理し得る。ＳＥＰ４０２は、要求の中に存在する場合、規定アドレスおよび鮮度パラメータを分析し、要求されているコンテンツを決定し、ひいては、リソースＡを準備し、読み出し応答の中でミラーサーバ４０４に返し得る。ステップ４２４では、ＳＥＰ４０２は、読み出し応答の中の新鮮なリソースＡでミラーサーバ４０４を更新し得る。ステップ４２５では、新鮮なリソースＡが正常に返された場合、ミラーサーバ４０４は、新鮮なリソースＡのローカルバージョンが、将来の要求にサービス提供するために活用され得るか、または課金および分析等の目的のためにも使用され得るように、それを記憶する。ミラーサーバ４０４は、随意に、対応するタイムスタンプを割り当て、リソースＡがミラーサーバ４０４の中で作成されたときを記録し得る。ステップ４２６では、新鮮なリソースＡがミラーサーバ４０４に正常にパブリッシュされた場合、クライアント４０６に返され、そうでなければ、エラーが代わりに返される。

同様に、ミラーサーバ４０４は、ミラーサービスがＰＵＴまたはＣＲＥＡＴＥ要求のペイロードを評価し、意味リソース表現がミラー化リソース表現と同一であるかどうかを決定し得る鮮度ベースの要求再標的化をサポートし得る。同一である場合、ミラーサーバ４０４は、ＰＵＴまたはＣＲＥＡＴＥ動作を古いと見なし、要求をデバイスに再標的化しないこともある。同一ではない場合、ミラーサーバ４０４は、要求を新鮮と見なし、それをデバイスに再標的化してサービス提供し得る。

本明細書に出現する請求項の範囲、解釈、または用途を過度に限定することなく、以下は、とりわけ、要求がＭ２Ｍ／ＩｏＴ環境で処理される方法に関連付けられる、本明細書に開示される例のうちの１つ以上のものの例示的な技術的効果である。本明細書に開示される例のうちの１つ以上のものの技術的効果は、ＩｏＴデバイスへの低減された負荷であり得る。なぜなら、対応するコンテンツ要求アプリがサービス層の中に記憶されたバージョンよりも新鮮であるリソースのバージョンを選好するであろうとき、または、要求開始アプリが要求を特定のデバイスに再標的化することを選好するであろうとき、コンテンツソーシングアプリもしくは要求受信アプリをホストするデバイスが、通常、トリガまたは通知されるからである。本明細書に開示される例のうちの１つ以上のものの別の技術的効果は、従来の実装と比較して、サービス層が、そうでなければコンテンツ要求アプリがアクセスを有さないであろう新鮮なコンテンツへの増加した利用可能性を提供し得ることである。これは、コンテンツ要求アプリがサービス層の中に記憶されるコンテンツのみにアクセスし得るという制限を除去する。これは、より柔軟かつ強力なサービス層フレームを作成し、新鮮なコンテンツを要求するより多くのユースケースをサポートする。本明細書に開示される例のうちの１つ以上のものの別の技術的効果は、従来の実装と比較して、コンテンツ要求アプリまたは要求開始アプリが、サービス層によって現在ホストされていない新鮮なコンテンツにアクセスすること、もしくはその現在の状態と異なる状態にコンテンツを更新することを所望するまで、コンテンツソーシングアプリまたは要求受信アプリをホストするデバイスが、スリープすることを可能にされ得ることである。新鮮なコンテンツの必要性がないことは、デバイスがスリープした状態のままであることを可能にする。

別の技術的効果は、メッセージの数を削減することによって、ネットワーク帯域幅を節約し、おそらく、不必要な要求（例えば、重複要求）を処理していないので、受信デバイス（例えば、図８の作動または他のエンドデバイス）のためのバッテリ寿命を節約することであり得る。例では、同一のドアを開錠しようとしている複数のユーザがいる場合、それらのうちの１人だけがドアを開錠する必要があり、ドアを開錠しようとする他の要求は、実際には重複と見なされることができ、それらは実際には「新鮮」ではないので、フィルタ処理されることができる。そして、それを行うことによって、サービス層は、付加価値を提供する。過去のコマンドのある比較と、要求をアクチュエータタイプデバイスに転送または再標的化するかどうかの決定とがあり得る。

図２０は、鮮度ベースのコンテンツ読み出しサービス等の本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９０１（例えば、タッチスクリーンディスプレイ）は、結果を含む要求処理に関連付けられるテキストをブロック９０２の中で提供し得る。ブロック９０２の部分は、選択されたとき、表１から表６のパラメータ等の追加の情報を与え得る。別の例では、本明細書で議論されるステップのうちのいずれかの進捗（例えば、送信されたメッセージまたはステップの成功）が、ブロック９０２の中に表示され得る。加えて、グラフィカル出力９０３が、ディスプレイインターフェース９０１上に表示され得る。グラフィカル出力９０３は、要求処理におけるデバイスのトポロジ、本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力等であり得る。ディスプレイインターフェース９０１は、本明細書で議論されるデバイスから発見されて読み出されるコンテンツの要求される鮮度を構成またはプログラムするために実装され得る。例えば、図６を参照したユースケースでは、医師は、図２０に示されるように、医師が、特定の患者の血中インスリン、血圧、血液酸素、および心拍数読み取り値の選好または要求される鮮度を規定することを可能にするアプリケーション１２１を介して、ユーザインターフェースを提供され得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新鮮なコンテンツは、とりわけ、時間ベースまたは状態ベースであり得る。例えば、時間ベースの新鮮なコンテンツは、コンテンツ読み出しまたは発見要求の中に含まれる鮮度パラメータで規定される日付および時間よりも新しい作成時間を有するサービス層ホスト型コンテンツに関連付けられ得る。状態ベースの新鮮なコンテンツは、その現在の意味状態と異なる意味状態にサービス層ホスト型コンテンツを更新する要求に関連付けられ得る。

とりわけ、本明細書に説明されるような方法、システム、および装置は、サービス層のためのコンテンツ（サービス層内の要求処理）の鮮度を管理する手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、要求アプリケーションからメッセージを受信する手段であって、メッセージは、サービスに関連付けられたコンテンツおよびービスに関連付けられるコンテンツのための鮮度期間を取得するための要求を備えている、手段と、メッセージの中の要件に基づいて、コンテンツの鮮度期間が許容閾値期間外であることを決定する手段と、コンテンツの鮮度期間が許容閾値期間外であることを決定するステップに応答して、１）非ブロック応答を要求アプリケーションに送信し、２）ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、許容閾値内であるサービスの更新されたコンテンツを取得する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、複数の他のサービスに関連付けられたコンテンツのための鮮度期間と共にサービスに関連付けられたコンテンツのための鮮度期間の分析に基づいて、コンテンツがサービス層デバイスによって更新される必要があるスケジュールを決定する手段を有する。コンテンツソースアプリケーションへの要求メッセージは、コンテンツがサービス層デバイスによって更新される必要があるスケジュールを備え得る。非ブロック応答は、コンテンツが利用可能になったときにサブスクライブして鮮度期間内のコンテンツを受信するために要求アプリケーションによって使用されるコールバックアドレスを備え得る。コンテンツソースアプリケーションへの要求メッセージは、鮮度期間に対応する作成後パラメータを備え得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、複数の他のメッセージの中で関連付けられるコンテンツのための鮮度期間と共にメッセージの中のコンテンツのための鮮度期間の分析に基づいて、コンテンツが装置によって更新される必要があるスケジュールを決定する手段を有する。ポイントオブコンタクト情報は、ユニフォームリソース識別子を備え得る。この段落内の全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一致する様式で考慮される。

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

Claims (15)

1. サービス層においてコンテンツの鮮度を管理するための装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、記憶された実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   前記サービス層がホストする複数のアプリケーションのうち要求アプリケーションからメッセージを受信することであって、前記メッセージは、サービスに関連付けられたコンテンツを取得するための要求と、前記サービスに関連付けられた前記コンテンツのための規定鮮度時間パラメータとを備えている、ことと、
   前記メッセージの中の要件に基づいて、前記コンテンツが取得された際のタイムスタンプが前記規定鮮度時間パラメータで規定される時刻より古いことを決定することと、
   前記コンテンツが取得された際のタイムスタンプが前記規定鮮度時間パラメータで規定される時刻より古いことを決定することに応答して、
   非ブロック応答を前記要求アプリケーションに送信することであって、前記非ブロック応答は、コールバックアドレスを備え、前記コールバックアドレスは、前記コンテンツが利用可能になったときに前記規定鮮度時間パラメータで規定される時刻より新しいコンテンツを受信するために前記サービス層にサブスクライブするために、前記要求アプリケーションによって使用される、ことと、
   ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、前記規定鮮度時間パラメータで規定される時刻より新しい前記サービスの更新されたコンテンツを取得することと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記動作は、複数の他のサービスに関連付けられた前記コンテンツのための前記規定鮮度時間パラメータと共に前記サービスに関連付けられた前記コンテンツのための前記規定鮮度時間パラメータの分析に基づいて、前記コンテンツが前記装置によって更新される必要があるスケジュールを決定することをさらに含む、請求項１に記載の装置。
3. 前記コンテンツソースアプリケーションへの前記要求メッセージは、前記コンテンツが前記装置によって更新される必要があるスケジュールを備えている、請求項１または２のいずれか１項に記載の装置。
4. 前記要求メッセージは、優先度を備え、前記コンテンツソースアプリケーションは、前記コンテンツソースアプリケーションが新鮮なコンテンツを提供するときを優先させるために前記優先度を使用する、請求項１または２のいずれか１項に記載の装置。
5. 前記コンテンツソースアプリケーションへの前記要求メッセージは、前記規定鮮度時間パラメータに対応する作成後パラメータを備えている、請求項１または２のいずれか１項に記載の装置。
6. 前記動作は、複数の他のメッセージの中の関連付けられた前記コンテンツのための前記規定鮮度時間パラメータと共に前記メッセージの中の前記コンテンツのための前記規定鮮度時間パラメータの分析に基づいて、前記コンテンツが前記装置によって更新される必要があるスケジュールを決定することをさらに含む、請求項１または２のいずれか１項に記載の装置。
7. 前記ポイントオブコンタクト情報は、ユニフォームリソース識別子を備えている、請求項１または２のいずれか１項に記載の装置。
8. サービス層を実現するデータ処理ユニットによって実行される、コンテンツの鮮度を管理する方法であって、前記データ処理ユニットは、
   前記サービス層がホストする複数のアプリケーションのうち要求アプリケーションからメッセージを受信することであって、前記メッセージは、サービスに関連付けられたコンテンツを取得するための要求と、前記サービスに関連付けられた前記コンテンツのための規定鮮度時間パラメータとを備えている、ことと、
   前記メッセージの中の要件に基づいて、前記コンテンツが取得された際のタイムスタンプが前記規定鮮度時間パラメータで規定される時刻より古いことを決定することと、
   前記コンテンツが取得された際のタイムスタンプが前記規定鮮度時間パラメータで規定される時刻より古いことを決定することに応答して、
   非ブロック応答を前記要求アプリケーションに送信することであって、前記非ブロック応答は、コールバックアドレスを備え、前記コールバックアドレスは、前記コンテンツが利用可能になったときに前記規定鮮度時間パラメータで規定される時刻より新しいコンテンツを受信するために前記サービス層にサブスクライブするために、前記要求アプリケーションによって使用される、ことと、
   ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、前記規定鮮度時間パラメータで規定される時刻より新しい前記サービスの更新されたコンテンツを取得することと
   を実行する方法。
9. 前記データ処理ユニットは、
   複数の他のサービスに関連付けられた前記コンテンツのための前記規定鮮度時間パラメータと共に前記サービスに関連付けられた前記コンテンツのための前記規定鮮度時間パラメータの分析に基づいて、前記コンテンツを更新する必要があるスケジュールを決定することをさらに実行する、請求項８に記載の方法。
10. 前記コンテンツソースアプリケーションへの前記要求メッセージは、前記コンテンツが前記データ処理ユニットによって更新される必要があるスケジュールを備えている、請求項８または９のいずれか１項に記載の方法。
11. 前記要求メッセージは、優先度を備え、
    前記コンテンツソースアプリケーションは、前記コンテンツソースアプリケーションが新鮮なコンテンツを提供するときを優先させるために前記優先度を使用する、請求項８または９のいずれか１項に記載の方法。
12. 前記コンテンツソースアプリケーションへの前記要求メッセージは、前記規定鮮度時間パラメータに対応する作成後パラメータを備えている、請求項８または９のいずれか１項に記載の方法。
13. 複数の他のメッセージの中の関連付けられた前記コンテンツのための前記規定鮮度時間パラメータと共に前記メッセージの中の前記コンテンツのための前記規定鮮度時間パラメータの分析に基づいて、前記コンテンツが前記データ処理ユニットによって更新される必要があるスケジュールを決定することをさらに含む、請求項８または９のいずれか１項に記載の方法。
14. 前記ポイントオブコンタクト情報は、ユニフォームリソース識別子を備えている、請求項８または９のいずれか１項に記載の方法。
15. コンピュータ読み取り可能な媒体を備えているコンピュータプログラム製品であって、前記コンピュータ読み取り可能な媒体は、プログラム命令を備えているコンピュータプログラムを有し、前記コンピュータプログラムは、前記データ処理ユニットにロード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、請求項８から１４のいずれかに記載の方法を前記データ処理ユニットに実行させるように適合されている、コンピュータプログラム製品。