JP2018530965A - 強化ＲＥＳＴｆｕｌ動作 - Google Patents

Abstract

ＣＲＵＤ動作のバッチが、リソース発見動作と結合され、新しいＣＲＵＤ要求を開始することなく、合致したリソースに対して直接行われることができる。発信側および受信側における新しい機能性は、発見／フィルタリング結果に含まれるリソースから基準合致が適用されるリソースを区別することができる。発信側および受信側における強化機能性は、発見を、発見されたリソースとは異なるがそれらに関連するリソース組を標的にするＲＥＳＴｆｕｌ動作と組み合わせることができる。他の強化は、フィルタに合致するそれらと規定された関係にあるリソースの発見を要求すること、または結果に基づくグループ形成を要求することを行うために使用され得る。

Description

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

近年、マシン／デバイスが互いと通信することを可能にするＭ２Ｍソリューションが、医療部門、エネルギー部門、および自動車部門のために開発されている。最適化の次のステップは、同一のプラットフォーム上で異なる部門からのマシンおよびモノを統合するソリューションを提供することである。

この目的のために、業界部門から独立したアプリケーション間のデータの交換および共有のためのホリゾンタルプラットフォームを定義する規格の単一の組が、ｏｎｅＭ２Ｍによって開始されている。「ｏｎｅＭ２Ｍは、オペレーティングシステムのような分散型ソフトウェア層を作成しており、分散型ソフトウェア層は、異なる技術とインターワーキングするためのフレームワークを提供することによってその統一を促進している。」（「Ｔｈｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｅｎａｂｌｅｒ ｆｏｒ ｔｈｅ Ｅｎｔｉｒｅ Ｍ２Ｍ ａｎｄ ＩｏＴ Ｅｃｏｓｙｓｔｅｍ」、ＯｎｅＭ２Ｍホワイトペーパからの引用）。この分散型ソフトウェア層は、アプリケーション層１０４におけるＭ２Ｍアプリケーションと、ネットワークサービス層１０６においてデータトランスポートを提供する通信ハードウェア／ソフトウェアとの間に位置する、共通サービス層で実装される（図１参照）。

サービス層１０６は、共通サービス機能（ＣＳＦ）によって機能的に有効にされる。ＣＳＦのグループは、共通サービスエンティティ（ＣＳＥ）上のグループとしてインスタンス化され得る。例示的ＣＳＥ２０２が、図２に示されている。ＣＳＦの例が、以下の段落で説明される。

アプリケーションおよびサービス層管理ＣＳＦ２０４は、ＡＥおよびＣＳＥの管理を提供する。これは、ＣＳＥの機能を構成、トラブルシューティング、およびアップグレードする能力、ならびにＡＥをアップグレードする能力を含む。

発見ＣＳＦ２０６は、フィルタ基準に基づいてアプリケーションおよびサービスについての情報を検索する。このＣＳＦについての追加の情報が、以下で説明される。

登録ＣＳＦ２０８は、ＡＥ（または他の遠隔ＣＳＥ）がＣＳＥに登録するための機能性を提供する。これは、ＡＥ（または遠隔ＣＳＥ）がＣＳＥのサービスを使用することを可能にする。

通信管理／配信ハンドリングＣＳＦ２１０は、他のＣＳＥ、ＡＥ、およびＮＳＥとの通信を提供する。このＣＳＦは、通信を配信するための時間および通信接続と、必要であり、許可される場合、それらが後に転送されることができるように通信要求をバッファすることとを決定する。

グループ管理ＣＳＦ２１２は、グループ関連要求のハンドリングを提供する。Ｍ２Ｍシステムが、複数のデバイス、アプリケーション等の上でバルク動作をサポートすることを可能にする。

セキュリティＣＳＦ２１４は、識別、認証、および承認を含む、アクセス制御等のサービス層のためのセキュリティ機能を提供する。

データ管理およびリポジトリＣＳＦ２１６は、データ記憶および仲介機能（集約のためにデータを収集すること、データを再フォーマットすること、ならびに分析およびセマンティクス処理のためにデータを記憶すること）を提供する。

場所ＣＳＦ２１８は、ＡＥが地理的場所情報を取得することを可能にする機能性を提供する。

サービス課金および会計ＣＳＦ２２０は、サービス層のための課金機能を提供する。

デバイス管理ＣＳＦ２２４は、Ｍ２ＭゲートウェイおよびＭ２Ｍデバイス上のデバイス能力の管理を提供する。

ネットワークサービスエクスポージャ、サービス実行、およびトリガＣＳＦ２２６は、ネットワークサービス機能にアクセスするために下層ネットワークとの通信を管理する。

サブスクリプションおよび通知ＣＳＦ２２８は、イベントにサブスクライブすること、このイベントが起こると通知されることを可能にする機能性を提供する。

ｏｎｅＭ２Ｍアーキテクチャは、（それぞれ）Ｍｃａ、Ｍｃｃ（およびＭｃｃ’）、ならびにＭｃｎ参照点を通してアプリケーションエンティティ（ＡＥ）２３０とインターフェースをとるＣＳＥ２０２、他のＣＳＥ、およびネットワークサービスエンティティ（ＮＳＥ）２３２、すなわち、下層ネットワークを提供する。

ｏｎｅＭ２Ｍは、サービス層アーキテクチャの仕様を開発するために、２つのアーキテクチャのアプローチ、すなわち、図３Ａに示されるリソース指向アーキテクチャ（ＲＯＡ）および図３Ｂに示されるサービス指向アーキテクチャ（ＳＯＡ）を使用する。

ＲＯＡアーキテクチャは、ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０で詳述されている。それは、リソースおよびそれらの機能性を可能にするためにＣＳＦによって行われる動作を中心として開発されている。リソースは、ユニフォームリソース識別子（ＵＲＩ）を介して一意にアドレス可能なアーキテクチャの要素である。

リソースは、ベースから生じる階層ツリーと見なされ得、いくつかの関係をが、それらの間で定義される。例えば、リソースは、子リソースおよび属性を含み得、子リソースは、親リソースと包含関係を有する。したがって、親リソース表現は、その子リソースの参照を含む。子リソースの存続期間は、親のリソース存続期間によって限定される。

属性は、リソースの情報を記憶する、アーキテクチャの要素である。ｏｎｅＭ２Ｍは、全てのリソースに共通する属性の組を定義し、他は、個々のリソースに特定であり、「リソース特定の属性」と称される。（ホスティングＣＳＥと称される）１つのＣＳＥに位置するリソースは、遠隔ＣＳＥにアナウンスされ得、これらは、「アナウンスされたリソース」と称される。アナウンスされたリソースは、オリジナルリソースの属性ならびにそれら自身の属性を含み得る。オリジナルリソースとアナウンスされたリソースとの間の同期化は、ホスティングＣＳＥの責任である。

ＳＯＡアーキテクチャは、ｏｎｅＭ２Ｍ−ＴＳ−０００７、Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ０．８．１で詳述されている。それは、サービス自体を中心として開発され、ＲＥＳＴｆｕｌベースではない旧来の展開で使用され得る。ＳＯＡサービス層は、サービスコンポーネントにグループ化され得る種々のＭ２Ｍサービスを含む。ＲＯＡアーキテクチャの中で導入される既存の参照点に加えて、ＳＯＡアーキテクチャは、サービス間参照点Ｍｓｃを導入する。

ｏｎｅＭ２Ｍにおける情報交換を統制する一般的フローは、ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０で説明され、図４に示される通信プロシージャ内の要求および応答メッセージの使用に基づく。発信側４０２は、要求メッセージを受信側４０４に送信し、受信側４０４は、応答メッセージで応答する。

このプロシージャは、（Ｍｃａ参照点を経由して）ＡＥとＣＳＥとの間、ならびに（Ｍｃｃ参照点を経由して）ＣＳＥ間の通信に適用される。メッセージによって搬送される動作に応じて、これらのプロシージャは、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ方法を介して、標準化リソース表現の中の情報を操作し得る。

要求および応答メッセージが両方とも規定され、必須、随意、または条件付きパラメータを含む。表１は、簡潔な説明を伴う要求パラメータのリストであり、完全な説明は、ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０で見出されることができる。

発見動作において重要な役割を果たす、上記の要求パラメータのうちのいくつかの使用が、以下の節で詳述される。

同様に、表２は、簡潔な説明を伴う応答パラメータのリストを提供し、完全な説明は、ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０で見出されることができる。

リソース発見は、エンティティ（発信側４０２と称される）が属性およびリソースに含まれるアプリケーションならびにサービスについての情報を検索するプロセスである。ｏｎｅＭ２Ｍでは、リソース発見の発信側４０２は、ＡＥまたはＣＳＥのいずれかであることができ、検索が開始する受信側ＣＳＥ４０４’におけるルートリソースを標的にする。

検索結果のコンテンツは、（例えば、リソースタイプ、リソース作成時間、リソースサイズ等に基づいて）ある検索パラメータを合致させることによるフィルタ基準のうちのいずれかに依存する。他のフィルタ基準パラメータ（例えば、限界）が、いくつかの動作パラメータ（例えば、Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｕｌｔ Ｔｙｐｅ）とともに、検索結果のコンテンツが発信側４０２に提供される方法において役割を果たす。発見動作は、ＣＲＵＤ動作のように、受信側ＣＳＥ４０４’におけるアクセス制御ポリシの影響下にある（すなわち、発信側４０２が「ＤＩＳＣＯＶＥＲ」アクセス権を有するか）。

検索パラメータの完全なリストは、表３の中で提供され、これは、ｏｎｅＭ２Ｍ−ＴＳ−０００１（ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０）の中の表８．１．２−１に基づく。しかしながら、ここでは、合致のために提供されるフィルタ基準と、基準使用のタイプまたは結果が返される方法を規定すること等の他の役割を伴うものとを区別する。これらのパラメータは、複合検索基準を作成するために、関係動作によって組み合わせられ得る。

ｏｎｅＭ２Ｍ ＲＯＡでは、リソース発見は、リソース発見動作と一般的読み出し動作とを区別するために受信側ＣＳＥ４０４’に示すべきｆｉｌｔｅｒＵｓａｇｅを使用するＲＥＴＲＩＥＶＥ方法を使用して実装される。

一般的リソース発見プロシージャが、図５に示されている。発信側４０２は、リソース＜ＣＳＥＢａｓｅ＞／＜ａｅ０１＞の特定の子リソースを標的にして、リソース発見要求（ステップ００１）を受信側ＣＳＥ４０４’に発行する。受信側ＣＳＥ４０４’は、要求を処理し、発見されたリソースの適切なリストを返す。受信側ＣＳＥ４０４’は、発見されたリソースのＤＩＳＣＯＶＥＲ特権に従って発見結果を限定し得、それ自身のローカルポリシに従ってフィルタ基準を変更し得る。発見されたリソースの完全リストが返されることができない場合、受信側ＣＳＥ４０４’は、（フラグを用いて）発信側４０２に警告するであろう。リソース発見応答（ステップ００３）は、フィルタ基準に合致するリソースのアドレスのリストを含む。必要である場合、アドレスによって指し示されるリソースを読み出すことは、発信側４０２の責任である。

ＣＲＵＤ動作のバッチが、リソース発見動作と結合され、新しいＣＲＵＤ要求を開始することなく、リソース発見成果に対して直接行われることができる。

発信側および受信側における新しい機能性は、発見／フィルタリング結果に含まれるリソースから、基準合致が適用されるリソースを区別することができる。発信側は、リソース発見成果がフィルタリング結果の中で提供されることを要求し得る。フィルタリング結果は、発信側が規定したフィルタ基準を満たす合致リソース組とは異なるが、それに関連し得る。フィルタリング結果におけるリソースと合致リソース組の中のそれらとの間の関係も、発信側によって規定されることができる。

発信側および受信側における強化機能性は、ＲＥＳＴｆｕｌ動作と発見動作とをリンクすることができる。発信側は、標的リソース組に対する動作を要求し得る。標的リソース組は、発信側発見要求に基づく発見されたリソースの組（フィルタリング結果）とは異なるが、それに関連し得る。標的リソース組の中のリソースとフィルタリング結果の中のそれらとの間の関係も、発信側によって規定されることができる。

あるフィルタ基準に合致する親または子を有するリソースを発見すること等の強化フィルタ基準が、使用されることができる。

強化フィルタ指令が、例えば、フィルタ基準に合致するリソースのためのグループの作成を要求すること、またはフィルタリング結果と合致リソースとの間の関係を規定することを行うために使用されることができる。

強化例外ハンドリングが、例えば、発信側要求に基づいて、ある条件が生じるときに行われる、ＣＲＵＤ動作を含む受信側挙動を変化させるために使用されることができる。

導入されるＲＥＳＴｆｕｌ動作の新しいパラメータおよび処理は、以下のように、さらなる新しいまたは強化機能性を可能にすることができる。
・受信側のみにおいて処理を伴い、発信側と受信側との間で行き来するメッセージングを伴わずに、発見されたリソースに対するＣＲＥＡＴＥ動作が後に続くリソース発見を要求する能力
・受信側のみにおいて処理を伴い、発信側と受信側との間で行き来するメッセージングを伴わずに、発見されたリソースに対するＵＰＤＡＴＥ動作が後に続くリソース発見を要求する能力
・受信側のみにおいて処理を伴い、発信側と受信側との間で行き来するメッセージングを伴わずに、発見されたリソースに対するＤＥＬＥＴＥ動作が後に続くリソース発見を要求する能力
・同一のメッセージを使用して要求されるが、発見プロシージャのため、およびＣＲＵＤ動作用のために異なる標的を提供する能力
・リソースツリーの種々のレベルで合致させられるべき条件を使用することによって、ＣＲＵＤ動作の前に行われる発見動作またはフィルタリングを強化する能力
・所与の基準に基づいて合致させられるリソースと、フィルタリング／発見結果を構成するリソースとの間の差異／関係を規定する能力
・例えば、フィルタリング／発見結果からの動作標的の決定において、親／子、意味記述子等のリソース関係を使用することによって、フィルタリング／発見結果を構成するリソースとＣＲＵＤ動作によって標的にされるそれらとの間の差異／関係を規定する能力
・発見動作の合致またはフィルタ処理リソースから成るグループの作成を要求する能力
・ある条件／例外が生じるときに行われるべき動作の変化を要求する能力

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

より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明からもたらされ得る。
図１は、ｏｎｅＭ２Ｍ層状モデルの略図である。 図２は、共通サービス機能の略図である。 図３Ａは、リソース指向アーキテクチャ（ＲＯＡ）ｏｎｅＭ２Ｍ機能アーキテクチャの略図である。 図３Ｂは、サービス指向アーキテクチャ（ＳＯＡ）ｏｎｅＭ２Ｍ機能アーキテクチャの略図である。 図４は、ｏｎｅＭ２Ｍにおける一般的通信フローの略図である。 図５は、ｏｎｅＭ２Ｍ一般リソース発見プロシージャの略図である。 図６は、ＴａｓｋＭａｎａｇｅｒユースケースの略図である。 図７は、既存のｏｎｅＭ２Ｍ動作を伴うユースケースフローの略図である。 図８Ａ−Ｂは、グループ機能性を使用する、既存のｏｎｅＭ２Ｍ動作を伴うユースケースフローの略図である。 図８Ａ−Ｂは、グループ機能性を使用する、既存のｏｎｅＭ２Ｍ動作を伴うユースケースフローの略図である。 図９は、一般的強化動作のためのコールフローの略図である。 図１０は、ＴａｓｋＭａｎａｇｅｒユースケースのための強化ＣＲＥＡＴＥ動作を使用する、例示的コールフローの略図である。 図１１は、処理実施例のための一般的コールフローの略図である。 図１２Ａ−Ｂは、要求処理フローチャートの略図である。 図１２Ａ−Ｂは、要求処理フローチャートの略図である。 図１３は、一実施形態のグラフィカルユーザインターフェースの略図である。 図１４Ａは、通信ネットワークを含む、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システムの略図である。 図１４Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスのためのサービス、ならびに通信ネットワークを提供する、フィールドドメイン内の図示されるＭ２Ｍサービス層の略図である。 図１４Ｃは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、例示的デバイスの略図である。 図１４Ｄは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバのブロック図である。

（略語）
ＡＥ アプリケーションエンティティ
Ａｐｐ アプリケーション
ＡＣＰ アクセス制御ポリシ
ＡＳＮ アプリケーションサービスノード
ＣＲＵＤ 作成、読み取り、更新、および削除
ＣＳＥ 共通サービスエンティティ
ＣＳＦ 共通サービス機能
ＤＩＳ 発見
ＤＭＲ データ管理およびリポジトリ
ＨＷ／ＳＷ ハードウェア／ソフトウェア
ＩＮ インフラストラクチャノード
ＩｏＴ モノのインターネット
Ｍ２Ｍ マシンツーマシン
ＭＮ 中間ノード
ＲＯＡ リソース指向アーキテクチャ
ＳＯＡ サービス指向アーキテクチャ
ＵＲＩ ユニフォームリソース識別子
（定義）

（ユースケース：工業用ＴａｓｋＭａｎａｇｅｒ）
図６は、種々の固定機械、移動車両、およびロボット、ならびに可動ツール（一般的に「機器」と称される）を伴う工業フロア６００を描写する。機械上、車両上、ツール、ロボット上、およびフロア上に、種々のセンサがある。人々も、エリアを通して移動し、個々のタスクを達成している。

広々としたフロアは、種々のレベルの複雑性のサービスを提供する機器と通信する複数のゲートウェイを有する。ｏｎｅＭ２Ｍベースのプラットフォームを使用する例に対して、ゲートウェイは、ＭＮ−ＣＳＥにマップし、機器は、最近傍のゲートウェイに登録されたＡＳＮまたはＡＤＮのいずれかの上に常駐するＡＥ（例えば、ＡＥ１、２…またはＡＥｘ、ｙ、ｚ…）にマップする。したがって、個々のＭＮは、種々の周囲センサによって提供されるセンサ測定、ならびに自動フライス盤または旋盤等の静的で複雑な機械を制御するために必要なリソースをホストし得る。移動ロボットも、移行後に最近傍のゲートウェイに登録される。サービスを工場に提供し、ＭＮ−ＣＳＥを統合するＭ２Ｍプラットフォームは、場所および意味サービスも提供する。例えば、それは、対応するリソースを介して登録される各機器のための場所、動作ステータス、保守ステータス等の情報を維持する。この場合、場所および保守ステータスが、関連リソースに適用される標識を介して維持されると仮定する。

整備工が、フロアセクタのうちの１つで保守を行っており、業務を行うために、エリア内のユニットが停止するとき、それらを見出すことを欲する。例えば、整備工は、機器タイプに応じて異なり得る、いくつかのコンポーネント／アイテム（例えば、車輪、軸受、蓄積した残渣）の物理的ステータスをチェックする必要がある。整備工は、豊富な能力を伴うモバイルデバイスへのアクセスを有し、モバイルデバイスは、工業団地のＷｉ−Ｆｉネットワークに接続し、それ自身を最近傍のゲートウェイ（ＭＮ−ＣＳＥ１）６０２に登録する。

この任務のために、整備工は、「ＴａｓｋＭａｎａｇｅｒ」アプリケーション（ＡＥ＿ｔｍ）６０４を使用し、ＴａｓｋＭａｎａｇｅｒは、整備工の業務に準備ができている任意の機器を検索し、関連デバイスの動作ステータス情報にサブスクライブする。サブスクリプションは、その保守が進行中ではない、整備工の近傍の機器を標的にされる。場所および保守ステータスは、関連リソースに適用される標識（すなわち、特別なリソース属性）を介して発見可能であると仮定される。ＴａｓｋＭａｎａｇｅｒは、関連検索基準（例えば、ｌａｂｅｌ＝Ｓｅｃｔｏｒ＃４２＆＆ｌａｂｅｌ＝ｍａｉｎｔｅｎａｎｃｅＮｏｔＣｕｒｒｅｎｔ）を伴う発見要求メッセージをゲートウェイ（ＭＮ−ＣＳＥ１ ６０２）に発行することによって、この機能性を達成し、返された結果に基づいて、アプリケーションは、動作ステータス（例えば、オフ、アイドル、起動）に対するサブスクリプション通知を作成する。いくつかのセクタをハンドリングするゲートウェイは、整備工の近傍の全ての登録された機器のリストを返し、動作ステータスコンテナに対するサブスクリプションを作成する。

ＴａｓｋＭａｎａｇｅｒ ＡＥ＿ｔｍ６０４が、アイドルまたはオフである１つの機器について通知されるとすぐに、それは、機器タイプ（静的対非静的）、予期されるアイドル期間等の追加の詳細を読み出す。整備工が自分自身のステータスを対応可能として更新すると、ＴａｓｋＭａｎａｇｅｒは、点検されるべき次の機器を整備工に指示し、特定の機器のためにカスタマイズされたタスクチェックリストを提供し得る。

動作ステータスの動的性質（機械が利用可能になり、次いで、点検される前に再びビジーになり得る）により、動作ステータスの値に基づいて定期的に発見を行うのではなく、動作ステータスにサブスクライブすることがより効率的である。これは、発見要求が最小化されるであろうことを確実にするであろう。

近傍の全ての機器が点検されている場合、いずれもアイドルではないか、または長時間アイドルになることが予測されない場合、もしくは利用可能なものが位置を変更した場合、ある時間に利用可能なタスクがないこともある。これらの状況のうちのいずれかでは、ＴａｓｋＭａｎａｇｅｒは、新しい場所等の異なるパラメータを用いて、（独力で、または整備工が促すと）新しい発見を開始し得る。

現在のｏｎｅＭ２Ｍ実装においてこのシナリオを提供するために、ＴａｓｋＭａｎａｇｅｒ ＡＥ＿ｔｍ６０４アプリケーションは、エリア内の機器を見出すように発見要求を行い得、その後、発見結果に基づくサブスクリプション作成が続く。発見が多数の機器（例えば、Ｎ）を返す場合、その後、図７で描写されるように、多数のＣＲＥＡＴＥ要求が続く。

ＡＥ＿ｔｍ６０４がｏｎｅＭ２Ｍグループ作成機構を使用する場合、グループは、非常に限定された時間量のために、かつ非常に少ない動作のために文字通り作成され、その後、それは、図８Ａ−Ｂで描写されるように削除されるべきである。これは、グループ動作の単純な使用であり、現在提供されている機構は、グループ動作のために最適化されていない。

これらの機構は、したがって、要求されるメッセージングの量および／または作成される（用途が非常に限定された）短命のグループの数のいずれかにおけるオーバーヘッドにより、最適ではない。このユースケースは、ＣＲＥＡＴＥ動作を例示するが、問題は全てのＣＲＵＤ動作に有効である。

基準合致に使用される標識が、リソースツリーの全体を通して種々のレベルで異なる管理アプリケーションによって適用されているであろう場合、別の問題が提起されるであろう。例えば、セクタ標識が＜ｌｏｃａｔｉｏｎ＞子コンテナに適用され、一方で保守ステータス標識が＜ＡＥ＞親リソースに適用されている場合。同一のリソースに対して合致させられるべきフィルタ基準を提供する現在の機構は、任意の単一の発見要求を通して取得され得る、結果の有用性における制限をもたらす。

ある場合、例えば、保守更新が行われる前に機械が前もって点検されたセクタから移動された場合、ＴａｓｋＭａｎａｇｅｒによって使用されるプロシージャは、すでにサブスクライブされている機械を発見し得る。この場合、ＴａｓｋＭａｎｇｅｒは、ＣＲＥＡＴＥ動作が、変更された名称を伴う新しいリソースの作成ではなく、既存のリソースの更新をもたらすことを命じることを欲し得る。

同時に、同一のゲートウェイを使用する他のアプリケーションは、類似ケースの異なる処理を要求し得る。例えば、新しいリソースを作成しようとし、同一の名称を伴う既存の子リソースがあるとき、他のアプリケーションは、既存のリソースが削除され、同一の名称および新しいコンテンツを伴う新しいものが作成されることを必要とし得る。しかしながら、一般に、そのような条件または例外ケースの処理は、受信側４０４におけるデフォルト処理に依拠する。これは、現在、いかなる区別も、受信側４０４における例外／条件ハンドリングにおいて達成されないこともあることを意味する。

現在、ＲＥＳＴｆｕｌプロシージャは、ＣＲＵＤ（作成、読み出し、更新、および削除）動作の実行を標的にし、ある基準または条件が生じることをチェックすることも可能にし得る。

発見要求の結果を標的にし、したがって、別個のサブプロシージャおよびステップを要求するＣＲＵＤ動作を伴う多くのユースケースがある：サブプロシージャおよびステップのいくつかは、発見を行うためであり、他は、発見ステップによって提供されるリソースに対するＣＲＵＤ動作の実行におけるものである。リソースの組（２つ以上の）をもたらす発見の結果として、いくつかの別個の要求／応答プロシージャが、組における各リソースに対して動作を実行するために必要とされるか、またはグループ作成が必要とされる。

グループ動作のために最適化された特別なプロシージャは、同一のリソースの組がグループとしてさらなるハンドリングを要求する場合のために非常に有用である改良されたメッセージング効率を提供する。しかしながら、発見結果に基づいてリソースの持続的グループを作成することが必要とされない、特別な場合がある。これらは、結果組の有効性が時間において限定される（すぐに、同一のパラメータを伴う別の発見動作が、異なる結果を生じるであろう）または結果組に対して行われる限定数の動作（おそらく１つ）がある場合が存在する。

多くの場合、最初のリソースツリー構造が発見されると、発見動作が、将来の動作に備えた検索およびフィルタリングのために使用される。連続的なメッセージングおよび処理を要求する既存のプロシージャは、非効率性をもたらす。何故なら、それらが、いくつかの検索を行う前に発信側４０２においてすでに利用可能であるリソースツリー情報を利用しないからである。同様に、受信側４０４は、個々のステップ（例えば、発見、個々のＣＲＵＤ動作等）の実行のために、別個に情報を取得するので、それらを一緒に最適化することができない。したがって、上で説明される現在の機構は、要求されるメッセージングの量、および／または限定された使用数、作成される短命のグループのいずれかのオーバーヘッドをもたらす。しかしながら、所望のＣＲＵＤ動作を伴い同時にリソース発見を要求する能力を有することが、有意な最適化を導入し得る。

加えて、複数の関連リソースに対してではなく、同一のリソースに対して合致させられる複数のフィルタ基準を提供する現在の機構は、任意の単一の発見要求を通して取得され得る結果の有用性の制限をもたらす。

最終的に、ＲＥＳＴｆｕｌ動作要求の現在の処理は、受信側４０４における例外／条件ハンドリングで区別を可能にせず、それは、区別された必要性を伴う用途によってそれらの使用を制約する。

（命名法）
上で議論されるように、多くの場合、リソース発見動作の後、リソース発見成果を標的にする新しいＣＲＵＤ要求のバッチが続く。新しいソリューションでは、ＣＲＵＤ動作のバッチは、リソース発見動作と結合され、新しい／別個のＣＲＵＤ要求を開始することなく、発見されたリソースに対して直接行われることができる。

強化は、フィルタリングおよび発見の要素を従来のＣＲＵＤ動作と組み合わせる。本節で提供される命名規則は、以下の説明で使用される用語を明確にしようとする。

フィルタベース：発見動作のための開始点として使用されるリソース。その子孫は、フィルタ基準の影響を受ける。

合致リソース：フィルタ基準が真であるリソース。

フィルタリング結果：フィルタリングまたは発見動作の結果は、動作パラメータに応じて、合致リソースもしくは合致リソースに関連するリソースから構成され得る。それは、１つ以上のリソースから成り得る。

標的リソース組：ＣＲＵＤ動作の標的である１つ以上のリソース。標的リソース組は、動作パラメータに応じて、発見動作のフィルタリング結果と同一であり得るか、またはフィルタリング結果に関連するリソースから成り得る。

動作結果：標的リソース組に対するＣＲＵＤの結果を示す。ここで説明される強化動作のために、標的リソース組が複数のリソースから成る場合、それは、複数のリソースに対する動作の結果であり得る。結果メッセージに含まれる動作結果のフォーマットは、要求の中で提供されるオプション、例えば、リソース、リソースおよび子リソース組に基づいて変動し得る。

（概観）
次の節は、ＲＥＳＴｆｕｌ動作の強化を説明する。以下を含む、要求メッセージの全体的強化が説明される。
・基準合致が適用されるリソースを発見／フィルタリング結果に含まれるリソースと区別する、発信側４０２および受信側４０４における新しい要求メッセージパラメータならびに新しい機能性。ＲＥＳＴｆｕｌ動作と発見動作とをリンクする発信側４０２および受信側４０４における強化機能性。
・フィルタ基準の強化（例えば、あるフィルタ基準に合致する親または子を有するリソースを発見するため）。それは、強化フィルタ指令も導入する（例えば、フィルタ基準に合致するリソースのためのグループの作成を要求するため、または標的リソースと合致リソースとの間の関係を規定するため）。
・強化例外ハンドリング：例えば、ある条件または例外状況が生じたとき、挙動を変化させるため。

上で要約される強化のプロシージャの効果は、発信側４０２および受信側４０４の両方におけるパラメータ使用のためのさらなる詳細を提供する。

ｏｎｅＭ２Ｍ実施形態が、説明される動作へのリソースの具体的な標準化された例を使用できることによって、処理についてのさらなる詳細とともに説明される。

（要求メッセージ強化）
（新しい要求メッセージパラメータ）
本節は、新しい動作パラメータを導入することによる要求メッセージの機能的強化を例証する。

一般に、情報交換プロシージャを統制するフローは、要求および応答メッセージの使用に基づく。要求は、発信側４０２によって受信側４０４に送信され、必須または随意であり得るパラメータを含む。あるパラメータは、要求された動作に応じて、必須または随意であり得る。

以下の要求メッセージパラメータの存在を仮定する。
・Ｏｐｅｒａｔｉｏｎ：実行されるべき正確なＲＥＳＴｆｕｌ動作、例えば、ＣＲＥＡＴＥ等を規定する。
・Ｔｏ：動作が実行されるべき標的リソースのアドレス
・ＦｉｌｔｅｒＣｒｉｔｅｒｉａ：条件合致のための基準
・Ｃｏｎｔｅｎｔ：動作で使用されるべきリソースコンテンツ、例えば、作成されるべきリソースのコンテンツ。その存在は、全ての動作のために必須であるわけではないと仮定される。

以下の応答メッセージパラメータの存在も仮定する。
・Ｒｅｓｐｏｎｓｅ Ｃｏｄｅ：動作の成功または失敗を示すパラメータ。それは、さらなる実行詳細を提供するステータス情報を含み得る。
・Ｃｏｎｔｅｎｔ：動作結果に基づくリソースコンテンツ、例えば、作成されたリソースのコンテンツ。その存在は、全ての動作のために必須であるわけではないと仮定される。

新しい動作パラメータが、ＲＥＳＴｆｕｌ要求動作のために説明される。

（新規）ＦｉｌｔｅｒＢａｓｅ：発見がホスティングＣＳＥ上で開始する場合のルートのアドレス
選択肢は、以下を含むが、それらに限定されない。
・ＦｉｌｔｅｒＣＳＥＢａｓｅ：受信側４０４がＣＳＥＢａｓｅにおいて発見を開始する。
・（ＦｉｌｔｅｒＡｄｄｒｅｓｓ）：受信側４０４がこのフィールドに含まれる規定されたアドレスにおいて発見を開始する。
・ＮＵＬＬまたはＤＥＦＡＵＬＴ（または存在しない）：いかなる強化機能性も要求されず、通常の処理が行われる。

ＦｉｌｔｅｒＢａｓｅが存在し、ＮＵＬＬまたはＤＥＦＡＵＬＴとは異なる場合、これは、動作が強化動作として扱われることを示すことができる。

ある場合、要求は、通過ＣＳＥを通して、受信側４０４である最終宛先にルーティングされる。通常の動作のために、通過ＣＳＥは、メッセージをＴｏアドレスによって指し示される受信側４０４にルーティングする。ＦｉｌｔｅｒＢａｓｅアドレスの存在によって示される強化動作のために、通過ＣＳＥは、メッセージをＦｉｌｔｅｒＢａｓｅアドレスにルーティングするであろう。全ての他の処理は、本書で提示される直接通信ケースと同様である。

ＦｉｌｔｅｒＣＳＥＢａｓｅ選択肢は、受信側４０４において対応するＵＲＩに解決される。実装は、上で説明される機能性のうちのいずれも失うことなく、実際のアドレスが提供される第２の選択肢のみを使用し得る。

（新規）ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ：結果メッセージにおけるＣｏｎｔｅｎｔフィールドの予期されるコンポーネントを発信側４０２に示す。

説明された機能性に基づく選択肢は、以下を含むが、それらに限定されない。
・ＦｉｌｔｅｒｉｎｇＲｅｓｕｌｔ：受信側４０４が、発信側４０２によって規定されるパラメータに基づいて、発見動作のフィルタリング結果を返すであろう（以下のフィルタ基準を参照）。
・ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ：受信側４０４が、標的リソース組に対するＲＥＳＴｆｕｌ動作の結果を返すであろう。
・ＦｉｌｔｅｒｉｎｇＡｎｄＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ：受信側４０４が、フィルタリング結果および標的リソース組に対するＲＥＳＴｆｕｌ動作の結果の両方を返すであろう。
・ＮｏｔｈｉｎｇまたはＤＥＦＡＵＬＴ（もしくは存在しない）：受信側４０４が結果を返さない。

（新規）ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ：ある条件または例外のハンドリングを示す。
選択肢は、以下を含むが、それらに限定されない。
・ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅ．受信側４０４がリソースを作成するときに使用される。発信側４０２が「ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅ」を要求する場合、受信側４０４は、発信側４０２によって供給される名称を使用することを必要とされる。結果として、ある動作アクションが、修正される必要があろう（例えば、ＣＲＥＡＴＥ）。
・ＮＵＬＬまたはＤＥＦＡＵＬＴ（もしくは存在しない）受信側４０４がデフォルト例外ハンドリングを使用する。

既存のＲＥＳＴｆｕｌ要求パラメータの機能性は、以下のように強化されることができる。

（ＥＮＨＡＮＣＥＤ）Ｔｏ：ＣＲＵＤ動作が実行されるべき標的リソースをアドレス指定する一意のＵＲＩを解決するために現在必要とされているアドレス。

本提案では、発見されるリソース（フィルタリング結果）と、ＲＥＳＴｆｕｌ動作が行われるべきリソース（標的リソース）との間の相対関係を提供するために、Ｔｏパラメータを使用するオプションを追加する。

このオプションは、強化動作のためにのみ有効であり、この目的のために、Ｔｏフィールドは、相対的パスとして提供されなければならず、それは、標的リソース組を取得するためにフィルタリング結果と連結されることができる。Ｔｏフィールドの中で提供されるアドレスが相対的ではない場合、標的リソース組は、フィルタリング結果と同一である。

フィルタ基準の他の可能な強化が、実施形態の節で詳述される。

（フィルタリング基準および指令のための強化）
フィルタリングまたは発見目的のために使用されるために、既存のＲＥＳＴｆｕｌ動作においてフィルタ基準を提供する可能性を仮定する。既存のフィルタリングおよび発見プロセスを充実させるために、関連リソースを合致させるために（例えば、子または親リソースの属性を合致させるために）使用されるべきフィルタリング基準を示すためのいくつかの新しいパラメータの導入を提案する。

ここでは、以下の新しい検索パラメータが説明される。
・（新規）ｃｈｉｌｄＲｅｓｏｕｒｃｅＴｙｐｅ：合致リソースは、このタイプの子リソースを有する必要がある。
・（新規）ｃｈｉｌｄＲｅｓｏｕｒｃｅＮａｍｅ：合致リソースは、この名称を伴う子リソースを有する必要がある。
・（新規）ｃｈｉｌｄＬａｂｅｌｓ：合致リソースは、所与の値に合致する標識を伴う子リソースを有する必要がある。
・（新規）ｃｈｉｌｄＡｔｔｒｉｂｕｔｅ：合致リソースは、所与の値に合致する属性を伴う子リソースを有する必要がある。
・（新規）ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ：合致リソースは、その親としてこのタイプのリソースを有する必要がある。
・（新規）ｐａｒｅｎｔＲｅｓｏｕｒｃｅＮａｍｅ：合致リソースは、その親としてこの名称のリソースを有する必要がある。
・（新規）ｐａｒｅｎｔＬａｂｅｌｓ：合致リソースは、その親として所与の値に合致する標識を伴うリソースを有する必要がある。
・（新規）ｐａｒｅｎｔＡｔｔｒｉｂｕｔｅ：合致リソースは、その親として所与の値に合致する属性を伴うリソースを有する必要がある。

フィルタ基準がどのように使用されるべきかを示すパラメータ、したがって、フィルタリング指令として作用するパラメータも、使用されることができる。

（新規）ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐは、以下の関係オプションを用いて、発見の結果（フィルタリング結果）が、発見基準が適用されるリソース（合致リソース組）とどのように関連するかを受信側４０４に知らせる。
・Ｓｅｌｆ：発見されたリソースが合致リソースと同一である。
・Ｐａｒｅｎｔ：発見されたリソースが合致リソースの親である。受信側４０４は、フィルタリング結果から重複親リソースを除去するための論理を実装し得る。
・Ｓｅｍａｎｔｉｃｓ：発見されたリソースが、各合致リソースのための意味情報を含むサブリソースであり、例えば、ｏｎｅＭ２Ｍでは、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞サブリソースが、フィルタリング結果の中で返されるであろう。
・Ｓｕｂｓｃｒｉｐｔｉｏｎ：発見されたリソースは、各合致リソースのためのサブスクリプション情報を含むサブリソースであり、例えば、ｏｎｅＭ２Ｍでは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞サブリソースが、フィルタリング結果の中で返されるであろう。
・Ｌａｔｅｓｔ：発見されたリソースが各合致リソースの最新インスタンスである。これは、所与の基準が、例えば、ｏｎｅＭ２Ｍ＜ｃｏｎｔａｉｎｅｒ＞リソースにおいて複数のインスタンス化を保持するリソースを標的にするとき、適用される。
・Ｏｌｄｅｓｔ：発見されたリソースは、各合致リソースの最古インスタンスである。このオプションは、基準が、例えば、ｏｎｅＭ２Ｍ＜ｃｏｎｔａｉｎｅｒ＞リソースにおいて複数のインスタンス化を保持するリソースに適用されるとき、有効である。

全てのｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ値に対して、リソースが合致させられるが、所与の相対的関係を伴うリソースが見出されない場合、結果は、合致が見出されなかった場合のように扱われる。

ｏｎｅＭ２Ｍに基づく例：＜ＡＥ１＞リソースは、所与の基準およびｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝ｓｕｂｓｃｒｉｐｔｉｏｎに基づいて合致させられるが、＜ＡＥ１＞は、いかなる＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞サブリソースも有していない。ケースは、＜ＡＥ１＞が、第１の場所で所与の基準に合致しなかった場合のように扱われるので、これは、合致リソース組から除去される。

（新規）ｆｏｒｍＧｒｏｕｐ：フィルタリングプロセスの結果に基づいてグループを形成する。選択肢は、ＭａｔｃｈｅｄＲｅｓｏｕｒｃｅｓ、ＦｉｌｔｅｒｅｄＲｅｓｏｕｒｃｅｓ、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔを含むが、それらに限定されない。

（新規）ｇｒｏｕｐＩＤ：ｆｏｒｍＧｒｏｕｐが存在する場合、ｇｒｏｕｐＩＤが、発信側４０２によって示され得る。ｆｏｒｍＧｒｏｕｐが存在しない場合、このパラメータは無視される。

（例外ハンドリング指示）
各動作は、デフォルト例外ハンドリングを有するが、発信側４０２は、強化例外または条件付きハンドリングを規定し得る。例えば、特定の＜ＡＥ＞リソース（例えば、ＡＥ１）が、子＜ｓｕｂｓｃｒｉｐｔｉｏｎＸ＞リソース、すなわち「ｓｕｂｓｃｒｉｐｔｉｏｎＸ」と名付けられたタイプ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞の子リソースをすでに有しているｏｎｅＭ２Ｍケースを考える。そのような場合、発信側４０２が「ｓｕｂｓｃｒｉｐｔｉｏｎＸ」と名付けられた＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成（ＣＲＥＡＴＥ）しようとすると、受信側４０４の現在の挙動は、発信側４０２によって提供される名称を変更することによって、別の子リソース、例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎＡｌｔ＞を作成すること、および動作結果とともに新しい名称を返すことであり得る。

発信側４０２がＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ＝ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅを用いてサブスクリプション作成を要求し得ることを提案する。そのような場合、受信側４０４は、既存の＜ｓｕｂｓｃｒｉｐｔｉｏｎＸ＞子リソースに対するＵＰＤＡＴＥとして動作を解釈し、別のものを作成しないことを強いられる。受信側４０４は、最初に、アドレス指定されたリソース＜ＡＥ１＞における発信側４０２の作成権および更新されるリソース＜ＡＥ１／ｓｕｂｓｃｒｉｐｔｉｏｎＸ＞における発信側４０２の更新権を検証するであろう。これらの権利が動作を可能にする場合、それは、提供されたコンテンツでの＜ＡＥ１／ｓｕｂｓｃｒｉｐｔｉｏｎＸ＞のＵＰＤＡＴＥを実行するであろう。

ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇのための可能な選択肢は、実装の必要性に基づいて拡張され得る。例えば、別の値「ＩｇｎｏｒｅＥｘｉｓｔｉｎｇＮａｍｅ」が、所与の名称を伴う子リソースの存在を無視することを受信側４０４に要求するために使用され得る。したがって、受信側４０４は、古いリソースを削除し、それを新しい作成動作のコンテンツと置換するものとする。

（代替物）
上で提示される強化は、代替実装を有し得る。

既存のパラメータの修正：新しい機能性を反映するために、新しいパラメータＦｉｌｔｅｒＢａｓｅを導入する代わりに、Ｔｏパラメータの使用が、さらに修正され得る。単純なビットフラグ（例えば、Ｅｆｌａｇ）が、強化動作、およびこの場合にＦｉｌｔｅｒＢａｓｅアドレスを提供するために再利用されるＴｏフィールドを示すために、使用され得る。いかなる相対的パスもこの場合に提供されることができないので、標的リソース組は、デフォルトで、そのような実装を使用する全ての強化動作のためのフィルタ処理結果と同一と見なされ得る。代替として、ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐに類似するフィルタリング指令が使用され得る。例えば、ｔａｒｇｅｔＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐフィルタ指令が、値の同様の選択肢（例えば、Ｓｅｌｆ、Ｐａｒｅｎｔ、Ｓｅｍａｎｔｉｃｓ等）とともに導入され得る。

新しい動作タイプ：新しい機能性を反映するために、新しいＲＥＳＴｆｕｌ動作タイプ、例えば、ＤｉｓｃＣｒｅａｔｅ（発見および作成）、ＤｉｓｃＵｐｄａｔｅ（発見および更新）、ＤｉｓｃＤｅｌｅｔｅ（発見および削除）が作成され得る。同様に、通常の発見が読み出し動作を使用して実装されることを仮定して、別個のＥｎｈＤｉｓｃ（強化発見）動作が、読み出しまたは通常の発見／フィルタリング機能性を伴う読み出しとは別個である、強化（ＥＮＨＡＮＣＥＤ）発見動作を反映するために作成され得る。

新しい動作タイプは、要求メッセージのＯｐｅｒａｔｉｏｎパラメータのためのＣ、Ｒ、Ｕ、Ｄ値への追加の選択肢として実装されることができ、例えば、ＤｉｓｃＣ、ＤｉｓｃＵ、ＤｉｓｃＤ、およびＥｎｈＤｉｓｃが、有効動作値のリストに追加され得る。上記の新しい動作タイプを仮定すると、ＦｉｌｔｅｒＢａｓｅパラメータは、もはや強化機能性のためのインジケータとして必要とされないこともある。したがって、ＦｉｌｔｅｒＢａｓｅおよびＴｏパラメータは、１つのパラメータ（例えば、Ｔｏとなり得、その意義は、前の節で説明されるように、動作タイプに基づいて条件付きである。

新しい動作のために、新しいアクセス制御ポリシが定義され得るか、または受信側機能性が、以下の節で詳述されるように、個々の動作のアクセス権を使用するように規定される。

（動作プロシージャ）
図９は、１つのソリューションの一般的強化動作のコールフローを図示し、新しいパラメータに基づく受信側４０４の処理を詳述する。図１０は、詳細に説明されるであろう、ＴａｓｋＭａｎａｇｅｒユースケースのための強化ＣＲＥＡＴＥ動作を使用する例示的コールフローを図示する。図１０は、図９の一般的コールフローの一実施例を図示する。

以下の項は、ｏｎｅＭ２Ｍユースケースを使用する追加の詳細を提供し、ＴａｓｋＭａｎａｇｅｒアプリケーションは、所与のセクタおよび保守状態基準を満たす場合のみ、登録されたＡＥのＳｔａｔｕｓＣｏｎｔａｉｎｅｒにサブスクライブする。

図１０の例では、発信側４０２は、受信側４０４に向けたＣＲＥＡＴＥ（Ｃ）要求を発行するが、動作は、所与の基準を評価することによって、最初に受信側４０４によって発見されるべきリソースに対して行われる必要がある。

対応する処理は、他のＣＲＵＤ動作にも適用される。

同様に、処理は、他の有効値およびパラメータの組み合わせを含むように一般化されることができる。さらなる例証も、以下で提供される。

図１０のステップ０では、必須条件として、発信側４０２は、動作が行われるべきリソースの相対アドレスを把握している。これは、事前発見プロシージャまたは事前構成によって取得されていることもある。例えば、ＴａｓｋＭａｎａｇｅｒ ＡＥ＿ｔｍ６０４は、事前検索でＭＮ−ＣＳＥ１ ６０２において発見プロシージャを行っており、したがって、そのツリー構造、具体的には、機器ＡＥがＭＮ−ＣＳＥ１ ６０２に登録するときに作成されたリソース（動作ステータス情報を記憶するそれら（この場合、＜ＡＥ＞リソースの子＜ｓｔａｔｕｓＣｏｎｔａｉｎｅｒ＞）を含む）を理解している。ＭＮ−ＣＳＥ１ ６０２は、要求メッセージの受信側４０４、ならびにより一般化された用語を使用して、プロシージャの中のホスティングＣＳＥの一般的役割を有する。

図１０のステップ１では、発信側４０２は、以下のパラメータを含む、ＣＲＥＡＴＥ要求を発行する。
・（新規）ＦｉｌｔｅｒＢａｓｅ＝ＦｉｌｔｅｒＣＳＥＢａｓｅ
そのＣＳＥＢａｓｅツリーが我々のユースケースのために検索されるであろう事実を反映する。
・ＦｉｌｔｅｒＣｒｉｔｅｒｉａ：（ｌａｂｅｌ＝ｓｅｃｔｏｒ＃４２ ＡＮＤ ｌａｂｅｌ＝ｍａｉｎｔｅｎａｎｃｅＮｏｔＣｕｒｒｅｎｔ ＡＮＤ ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝ｓｅｌｆ）
我々のユースケースのためのリソース合致基準を反映する。
・Ｃｏｎｔｅｎｔ：全ての標的リソースの子として作成されるべき＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞サブリソースの表現
・（新規）ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ＝ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ
我々のユースケースのために、それは、結果の予期されるコンポーネントが全ての作成されたリソースであることを示す。
・（新規）ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ＝ＮＵＬＬ
我々のユースケースのために、いかなる特別なハンドリングも必要ではない。
・（ＭＯＤＩＦＩＥＤ）Ｔｏ＝．．．／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒ
我々のユースケースのために、強化動作処理は、ＦｉｌｔｅｒＢａｓｅの存在によって示され、Ｔｏフィールドは、相対的パスであり得る。受信側４０４は、標的リソース組の中のリソースのアドレスを決定するために、．．．／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒをフィルタリング結果におけるリソースのアドレスと連結するように指示される。

受信側４０４の処理は、受信される要求のタイプ、ならびにフィルタリング基準を含む、発信側４０２によって要求の中で提供される全てのパラメータのコンテンツに基づく。

図１０のステップ２では、受信側４０４は、動作要求を受信し、パラメータをチェックする。サブステップ２ａ−２ｇが、以下で説明される。

図１０のステップ２ａでは、受信側４０４は、ＦｉｌｔｅｒＢａｓｅに基づいて検索（すなわち、発見）のベースアドレスを見出す。我々のユースケースでは、これは／ＣＳＥＢａｓｅである。ＦｉｌｔｅｒＢａｓｅが存在しない場合、これは、強化動作ではないので、それは、動作標的の存在を検証するステップＤから進む。

図１０のステップ２ｂでは、受信側４０４は、条件（ＦｉｌｔｅｒＣｒｉｔｅｒｉａ）を満たすリソースに対して、フィルタベース／ＣＳＥＢａｓｅから検索し始める。各反復において、それは、リソース／ＡＥｋを見出し、ｋは、フィルタ基準に合致する見出されたＡＥリソースのインデックスであり、それは、各反復ｉでインクリメントされる。簡単にするために、これらの見出されたリソースは、残りの文書ではＡＥｋとして表される（ｋ番目の合致リソースのためにインクリメントされたｋ）。各ＡＥｋリソースは、合致リソースである。

図１０のステップ２ｃでは、ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝ｓｅｌｆに基づいて、各合致リソースは、フィルタリング結果に追加されるべき候補になる。受信側４０４は、ＡＥｋにおける発信側４０２の発見権をチェックした後、この候補をフィルタリング結果に追加する。発見動作がＡＣＰによって可能にされない場合、対応するエラーコードが生成される。

現在のＲＥＴＲＩＥＶＥベースの発見では、検索結果の完全ツリー表現が動作結果に対して作成されることに留意されたい。ここで説明される処理では、フィルタリング結果は、代わりに、完全ツリー表現を伴わずに、条件を満たすリソースのリストのみであり得る。

図１０のステップ２ｄでは、Ｔｏ：…／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒに基づいて、受信側４０４は、各パス／ＡＥｋ／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒが有効であること、すなわち、それがフィルタリング結果の子リソースに対応することを検証する。該当しない場合、それは、フィルタリング結果からＡＥｋを破棄し、対応するエラーコードを生成する。

図１０のステップ２ｅでは、ＡＣＰおよび／ＡＥｋ／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒにおける発信側４０２のＣＲＥＡＴＥ権に基づいて、受信側４０４は、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの／ＡＥｋ／ＳｔａｔｕｓＣｏｎｔａｉｎｅｒに対してＣＲＥＡＴＥ動作を行う。作成動作が可能にされない場合、対応するエラーコードが生成される。

図１０のステップ２ｆでは、受信側４０４は、動作要件によって命じられるように、作成されたリソースのいくつかの属性のための値を割り当て得る。例えば、動作は、新たに作成されたリソースのためにリソースＩＤを割り当てること、または値をＰａｒｅｎｔＩＤ、作成時間等のある属性に割り当てることをそれに要求し得る。

図１０のステップ２ｇでは、受信側４０４は、前のステップでの個々のエラーコードに基づいて、複合応答コードを生成する。受信側４０４は、ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔに基づいて応答のコンテンツも組み立てる。この場合、ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ＝ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔであるので、コンテンツフィールドは、作成された＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを含むであろう。ツリー検索がし尽くされたとき、それは、発信側４０２に送信される応答を生成する。

ｆｏｒｍＧｒｏｕｐインジケータ（およびおそらくｇｒｏｕｐＩＤ）が要求の中に含まれる場合、受信側４０４における処理は、以下を含む。受信側４０４は、所与のｇｒｏｕｐＩＤ（または自己選択されたＩＤ）を伴うリソースグループを形成し、各検索反復で新しいメンバを追加するであろう。追加されるべきメンバは、ｆｏｒｍＧｒｏｕｐの中で提供される値（例えば、ＭａｔｃｈｅｄＲｅｓｏｕｒｃｅｓ、ＲｅｔｕｒｎｅｄＲｅｓｏｕｒｃｅｓ、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ）に依存する。したがって、この処理は、ステップＢ、Ｃ、またはＥで、すなわち、新しい有効リソースが合致リソース組またはフィルタリング結果のために見出される度に、もしくは動作結果が決定された後、組み込まれ得る。

図１０のステップ３では、発信側４０２は、応答メッセージを受信し、複合応答コードを含む含まれる必須および随意パラメータを処理する。要求パラメータに基づいて、全ての新たに作成されたリソースのリスト等の追加の情報が含まれ得、それは、発信側４０２におけるさらなる処理に使用され得る。

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

（ｏｎｅＭ２Ｍ実施形態）
以下の節は、どのようにして上で説明される新しいパラメータがｏｎｅＭ２Ｍ実施形態で適用され得るかを示す。以降の節では、結果として生じる機能性、処理、および結果の詳細とともに、メッセージの具体的実施例を説明する。

本節は、強化のｏｎｅＭ２Ｍ実施形態のためのソリューションを説明する。

表４は、新たに導入されたパラメータ（ＦｉｌｔｅｒＢａｓｅ、ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ、およびＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ）および他のパラメータの使用の可能な変化とともに、以前に詳述されたｏｎｅＭ２Ｍ要求パラメータリストを描写する。

表５は、ＦｉｌｔｅｒＣｒｉｔｅｒｉａのための新たに導入されたパラメータとともに、対応するｏｎｅＭ２Ｍ ＦｉｌｔｅｒＣｒｉｔｅｒｉａリストを描写する。

両方の表は、既存のパラメータの使用にもたらされる、可能な修正および明確化を強調表示する。

以下で説明されるソリューションのために、ＦｉｌｔｅｒＢａｓｅパラメータの存在は、強化機能性のインジケータである。ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０で説明される発見機能性は、ＲＥＴＲＩＥＶＥ動作が発見に使用されるべきであるというインジケータとして、別のパラメータ、すなわち、ＦｉｌｔｅｒＵｓａｇｅを使用する。ＦｉｌｔｅｒＢａｓｅの存在は、既存のＲＥＴＲＩＥＶＥベースの発見動作にもＦｉｌｔｅｒＣｒｉｔｅｒｉａを使用するためのより良好なインジケータであり得る。しかしながら、いずれの方法も、この目的のために機能するであろう。

本節は、前の節で提供されるｏｎｅＭ２Ｍ実施形態およびパラメータ説明を使用し、異なる構成に基づく使用実施例を提供する。全ての可能な組み合わせが例示されていることに留意されたい。

これらの以下の例では、必須条件として、発信側４０２は、概して、事前発見プロシージャに基づいて、Ｔｏパラメータで使用される相対的パスを把握している。これは、多数のユースケースにおけるこれらの強化動作の使用と対応し、発信側４０２は、ある発見およびＣＲＵＤ動作を何回も行っているので、リソースツリー構造の予備知識がある。

この場合、フィルタリング要求は、リソースツリー構造を発見するためではなく、リソースに含まれる情報に基づいて、検索の役割を果たす。強化ＲＥＳＴｆｕｌ動作は、既存のＣＲＵＤ動作またはリソースツリー構造発見機能に取って代わるのではなく、それらを補完するように意図されている。

図１１は、一般的要求および応答フローを描写する。各ケースに特定のパラメータ値は、それぞれの節で詳述される。

実施例１：２つの階層レベルで属性条件を満たすことが見出された全てのリソースに対してサブリソースを作成する。

機能性：属性ａｐｐＮａｍｅ＝＝ｍｙＡｐｐを伴うＡＥの子である全てのより新しいコンテナ（時間「ｍｙＤａｔｅ」後に作成されたもの）に対してサブスクリプションを作成する。

多くの場合、異なるデバイス上に常駐するデバイスアプリケーション（ＡＥ）が、同一のａｐｐＮａｍｅ属性を使用して登録する。同一のＣＳＥに登録された全てのデバイスからの特定のサービスに関心があるユーザは、これらのサービスによって作成される全てのより新しいコンテナにサブスクライブすることができ、発見およびサブスクリプション作成は、一緒に行われる。

実施例１の図１１のステップ１では、要求フォーマットを使用して、要求が送信される。
Ｔｏ： ＣＳＥＢａｓｅ
Ｏｐｅｒａｔｉｏｎ： ＣＲＥＡＴＥ（Ｃ）
ＦｉｌｔｅｒＢａｓｅ： ＦｉｌｔｅｒＣＳＥＢａｓｅ
Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：
ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，ｃｒｅａｔｅｄＡｆｔｅｒ＝＝ｍｙＤａｔｅ，
ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞， ｐａｒｅｎｔＡｔｔｒｉｂｕｔｅ ａｐｐＮａｍｅ＝＝ｍｙＡｐｐ
ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｓｅｌｆ
Ｃｏｎｔｅｎｔ： ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞
ＲｅｓｕｌｔＣｏｎｔｅｎｔ： ｈｉｅｒａｒｃｈｉｃａｌ−ａｄｄｒｅｓｓ＋ａｔｔｒｉｂｕｔｅｓ
ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ： ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ： ＮＵＬＬ
実施例１の図１１のステップ２では、処理が、サブステップ２ａ−２ｇを用いて行われる。

実施例１の図１１のステップ２ａでは、ホスティングＣＳＥは、検索ベースＦｉｌｔｅｒＢａｓｅ、すなわち、ＣＳＥＢａｓｅを見出す。

実施例１の図１１のステップ２ｂでは、ホスティングＣＳＥは、条件（ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ｃｒｅａｔｅｄＡｆｔｅｒ＝＝ｍｙＤａｔｅ、ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞、ｐａｒｅｎｔＡｔｔｒｉｂｕｔｅ ａｐｐＮａｍｅ＝ｍｙＡｐｐ）を満たす全てのリソースに対して、検索ベースＣＳＥＢａｓｅから検索し始める。それは、合致リソースとしてＣＳＥＢａｓｅ／ＡＥｋ／ｃｏｎｔａｉｎｅｒＸを見出す。

実施例１の図１１のステップ２ｃでは、ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｓｅｌｆに基づいて、同一のリソースは、ＡＣＰおよび発信側４０２の発見権に応じて、フィルタリング結果に追加される候補である。発信側４０２がＣＳＥＢａｓｅ／ＡＥｋ／ｃｏｎｔａｉｎｅｒＸの発見権を有すると仮定する。

実施例１の図１１のステップ２ｄでは、相対的パスではないＴｏアドレスに基づいて、標的リソース組は、フィルタリング結果と同一である。ホスティングＣＳＥは、パスＣＳＥＢａｓｅ／ＡＥｋ／ｃｏｎｔａｉｎｅｒＸが標的リソース組の中の各リソースのために有効であることを検証する。

実施例１の図１１のステップ２ｅでは、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋ／ｃｏｎｔａｉｎｅｒＸにおける発信側４０２のＣＲＥＡＴＥ権に基づいて、ホスティングＣＳＥは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのＣＲＥＡＴＥ動作を行う。発信側４０２が作成権を有すると仮定する。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ：ＮＵＬＬに基づいて、ＲＥＳＴｆｕｌ動作のいかなる特殊なハンドリングも必要とされない。

実施例１の図１１のステップ２ｆでは、ホスティングＣＳＥは、通常の動作要件によって命じられるように、作成されたリソースのいくつかの属性のための値を割り当て得る。

実施例１の図１１のステップ２ｇでは、ホスティングＣＳＥは、複合応答コードおよび応答コンテンツを生成する。ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ、すなわち、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔおよびＲｅｓｕｌｔＣｏｎｔｅｎｔ：ｈｉｅｒａｒｃｈｉｃａｌ−ａｄｄｒｅｓｓ＋ａｔｔｒｉｂｕｔｅｓに基づいて、結果コンテンツは、作成される全てのサブスクリプションリソースのアドレス、すなわち、ＳＥＢａｓｅ／ＡＥｋ／ｃｏｎｔａｉｎｅｒＸ／ｓｕｂｓｃｒｉｐｔｉｏｎおよびそれらの属性を含むであろう。

実施例２：２つの階層的に相対的なレベル（親および子）におけるフィルタに基づく合致である、各合致リソースの具体的な子へのサブリソースを作成する。

機能性：いくつかのネスト化されるとともに並列のコンテナが含まれ得るように、多くのプラットフォーム／センサからの温度読み取り値のためのコンテナを形成するアプリケーションＡＥ１を与えられる。Ｚｉｇｂｅｅ（登録商標）温度センサオントロジを指し示すコンテナのｏｎｔｏｌｏｇｙＲｅｆによって説明されるように、Ｚｉｇｂｅｅ（登録商標）温度情報を有する、全ての測定記憶コンテナを見出す。次いで、フィルタリング結果の意味記述リソースへのサブスクリプションを作成し、意味記述の変化を監視する。作成されるサブスクリプションリソースの階層アドレスを返す。

実施例２の図１１のステップ１では、要求フォーマットを使用して、要求が送信される。
Ｔｏ： ＣＳＥＢａｓｅ
Ｏｐｅｒａｔｉｏｎ： ＣＲＥＡＴＥ（Ｃ）
ＦｉｌｔｅｒＢａｓｅ： ／ＣＳＥＢａｓｅ／ＡＥ１
Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：
ｐａｒｅｎｔＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，
ａｔｔｒｉｂｕｔｅ ｏｎｔｏｌｏｇｙＲｅｆ＝＝ｈｔｔｐ：／／［Ｚｉｇｂｅｅ（登録商標）Ｏｎｔｏｌｏｇｙ］＃ＴｅｍｐｅｒａｔｕｒｅＳｅｎｓｏｒ
ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｓｅｍａｎｔｉｃｓ
Ｃｏｎｔｅｎｔ： ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞
ＲｅｓｕｌｔＣｏｎｔｅｎｔ： ｈｉｅｒａｒｃｈｉｃａｌ−ａｄｄｒｅｓｓ
ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ： ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ： ＮＵＬＬ
実施例２の図１１のステップ２では、処理サブステップ２ａ−２ｇが行われる。

実施例２の図１１のステップ２ａでは、ホスティングＣＳＥは、検索ベース、すなわち、ＦｉｌｔｅｒＢａｓｅ＝／ＣＳＥＢａｓｅ／ＡＥ１を見出す。

実施例２の図１１のステップ２ｂでは、ホスティングＣＳＥは、条件（ｐａｒｅｎｔＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ａｔｔｒｉｂｕｔｅｏｎｔｏｌｏｇｙＲｅｆ＝＝ｈｔｔｐ：／／［Ｚｉｇｂｅｅ（登録商標）Ｏｎｔｏｌｏｇｙ］＃ＴｅｍｐｅｒａｔｕｒｅＳｅｎｓｏｒ）を満たす全てのリソースに対して、検索ベース／ＣＳＥＢａｓｅ／ＡＥ１から検索を始め、全ての合致するコンテナを見出すであろう、すなわち、全ての…／ｃｏｎｔａｉｎｅｒＫ合致（ＣＳＥＢａｓｅ／ＡＥ１に基づくツリーの中の種々のレベルにあり得る）を見出す。

実施例２の図１１のステップ２ｃでは、ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｓｅｍａｎｔｉｃｓに基づいて、…／ｃｏｎｔａｉｎｅｒＫ／ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒリソースは、ＡＣＰおよび発信側４０２の発見権に応じて、フィルタリング結果に追加される候補である。発信側４０２が発見権を有すると仮定する。

実施例２の図１１のステップ２ｄでは、相対的パスではないＴｏアドレスに基づいて、標的リソース組は、フィルタリング結果と同一である。ホスティングＣＳＥは、…／ｃｏｎｔａｉｎｅｒＫ／ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒへのパスが標的リソース組の中の各リソースのために有効であることを検証する。

実施例２の図１１のステップ２ｅでは、ＡＣＰおよび…／ｃｏｎｔａｉｎｅｒＫ／ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒにおける発信側４０２のＣＲＥＡＴＥ権に基づいて、ホスティングＣＳＥは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのＣＲＥＡＴＥ動作を行う。発信側４０２が作成権を有すると仮定する。

実施例２の図１１のステップ２ｆでは、ホスティングＣＳＥは、通常の動作要件によって命じられるように、作成されたリソースのいくつかの属性のための値を割り当て得る。

実施例２の図１１のステップ２ｇでは、ホスティングＣＳＥは、複合応答コードおよび応答コンテンツを生成する。ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ、すなわち、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔおよびＲｅｓｕｌｔＣｏｎｔｅｎｔ：ｈｉｅｒａｒｃｈｉｃａｌ−ａｄｄｒｅｓｓに基づいて、結果コンテンツは、作成される全てのサブスクリプションリソースのアドレス、すなわち、属性を伴わない…／ｃｏｎｔａｉｎｅｒＫ／ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ／ｓｕｂｓｃｒｉｐｔｉｏｎを含むであろう。

実施例３：フィルタリング結果におけるリソースと所与の関係を伴う全てのリソースの属性を更新する。

機能性：最近（すなわち、時間「ｍｙＴｉｍｅ」以降）更新された場所コンテナを伴う全てのデバイス（ＡＥ）を見出し、次いで、それらのｔｅｍｐＭｅａｓｕｒｅｍｅｎｔリソースのみの将来のフィルタリングのために、全てのこれらのＡＥの中に存在することが既知であるｔｅｍｐＭｅａｓｕｒｅｍｅｎｔコンテナ上の標識を更新する。この機能性は、新たに更新された場所を伴うデバイスを効果的に発見し、同時に、容易な将来の識別のために容易に発見可能であるように測定コンテナを標識する。

実施例３の図１１のステップ１では、要求フォーマットを使用して、要求が送信される。
Ｔｏ： ．．．／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ
Ｏｐｅｒａｔｉｏｎ： ＵＰＤＡＴＥ （Ｕ）
ＦｉｌｔｅｒＢａｓｅ： ＦｉｌｔｅｒＣＳＥＢａｓｅ
Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：
ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝ ＜ＡＥ＞，ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，
ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒ，ｍｏｄｉｆｉｅｄＳｉｎｃｅ＝＝ｍｙＴｉｍｅ
ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｐａｒｅｎｔ
Ｃｏｎｔｅｎｔ： ｌａｂｅｌｓ＝ｔｅｍｐＳｅｎｓｏｒＭｏｖｅｄ
ＲｅｓｕｌｔＣｏｎｔｅｎｔ： ｎｏｔｈｉｎｇ
ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ： ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ： ＮＵＬＬ
実施例３の図１１のステップ２では、処理サブステップ２ａ−２ｇが行われる。

実施例３の図１１のステップ２ａでは、ホスティングＣＳＥは、検索ベースＦｉｌｔｅｒＢａｓｅ＝ＣＳＥＢａｓｅを見出す。

実施例３の図１１のステップ２ｂでは、ホスティングＣＳＥは、条件（ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞、ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒ、ｍｏｄｉｆｉｅｄＳｉｎｃｅ＝＝ｍｙＴｉｍｅ）を満たす全てのリソースに対して、検索ベースＣＳＥＢａｓｅから検索し始める。

これは、合致リソースとして対応するｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒｃｏｎｔａｉｎｅｒｓ、すなわち、ＣＳＥＢａｓｅ／ＡＥｋ／ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒを見出すであろう。

ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｐａｒｅｎｔに基づいて、各ＣＳＥＢａｓｅ／ＡＥｋは、フィルタリング結果のための候補になる。

実施例３の図１１のステップ２ｃでは、各反復に対して、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋにおける発信側４０２の発見権に応じて、ホスティングＣＳＥは、このリソースをフィルタリング結果に追加する。発信側４０２が発見権を有すると仮定する。

実施例３の図１１のステップ２ｄでは、Ｔｏ＝＝．．．／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔに基づいて、ホスティングＣＳＥがＵＰＤＡＴＥ動作のための標的リソース組を形成するので、組は、全てのＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔリソースから成るであろう。

ホスティングＣＳＥは、パスＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔが標的リソース組の中の各リソースのために有効であることを検証する。

実施例３の図１１のステップ２ｅでは、ＡＣＰおよびＢａｓｅ／ＡＥｋ／ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒにおける発信側４０２のＵＰＤＡＴＥ権に基づいて、ホスティングＣＳＥは、標識属性を更新する（すなわち、「ｔｅｍｐＳｅｎｓｏｒＭｏｖｅｄ」を追加する）ことによって、ＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔリソースのＵＰＤＡＴＥ動作を行う。発信側４０２が更新権を有すると仮定する。

実施例３の図１１のステップ２ｆでは、ホスティングＣＳＥは、通常の動作要件によって命じられるように、更新されたリソースのいくつかの属性のための値を割り当て得る。

実施例３の図１１のステップ２ｇでは、ホスティングＣＳＥは、複合応答コードおよび応答コンテンツを生成する。ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ、すなわち、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔおよびＲｅｓｕｌｔＣｏｎｔｅｎｔ、すなわち、Ｎｏｔｈｉｎｇに基づいて、いかなるコンテンツも応答とともに返送されない。

実施例４：３つの階層レベルで条件を満たすことが見出された合致に対してリソースインスタンスを削除する。

機能性：特定の宛先がサブスクリプションを有する＜ｃｏｎｔａｉｎｅｒ＞リソースを伴う全てのＡＥを見出し、次いで、ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔコンテナの最新＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を削除する。

これは、通知へのサブスクライバが、ある条件が起こることを認識し（例えば、最新の測定が無効であることが知られる）、全ての関連リソースを発見すること、および最新の結果を削除することを行うために、１つの動作を使用し得る場合であり得る。

実施例４の図１１のステップ１では、要求フォーマットを使用して、要求が送信される。
Ｔｏ： ＣＳＥＢａｓｅ
Ｏｐｅｒａｔｉｏｎ： ＤＥＬＥＴＥ（Ｄ）
ＦｉｌｔｅｒＢａｓｅ： ＦｉｌｔｅｒＣＳＥＢａｓｅ
Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ：
ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ，
ｃｈｉｌｄＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞，ｃｈｉｌｄＡｔｔｒｉｂｕｔｅ ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ＝＝ｍｙＵＲＩ
ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞
ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｌａｔｅｓｔ
Ｃｏｎｔｅｎｔ： Ｎ／Ａ
ＲｅｓｕｌｔＣｏｎｔｅｎｔ： Ｎ／Ａ
ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ： Ｎｏｔｈｉｎｇ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ： ＮＵＬＬ
実施例４の図１１のステップ２では、処理サブステップ２ａ−２ｇが行われる。

実施例４の図１１のステップ２ａでは、ホスティングＣＳＥは、検索ベース、すなわち、ＦｉｌｔｅｒＢａｓｅ＝ＣＳＥＢａｓｅを見出す。

実施例４の図１１のステップ２ｂでは、ホスティングＣＳＥは、条件（ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ、ｃｈｉｌｄＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞、ｃｈｉｌｄＡｔｔｒｉｂｕｔｅ ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ＝＝ｍｙＵＲＩ、ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞）を満たす全てのリソースに対して、検索ベースＣＳＥＢａｓｅから検索し始め、それは、サブスクリプションにおいて対応する属性を伴う全てのコンテナを見出すであろう。すなわち、合致リソースとして全てのＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔを見出す。ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｌａｔｅｓｔに基づいて、各ＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔの最新＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞は、フィルタリング結果への候補である。

実施例４の図１１のステップ２ｃでは、各反復に対して、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ／ｌａｔｅｓｔにおける発信側４０２の発見権に応じて、ホスティングＣＳＥは、このリソースをフィルタリング結果に追加する。発信側４０２が発見権を有すると仮定する。

実施例４の図１１のステップ２ｄでは、Ｔｏ＝＝ＣＳＥＢａｓｅに基づいて、ホスティングＣＳＥは、フィルタリング結果と同一であるように、ＤＥＬＥＴＥ動作のための標的リソース組を設定する。ホスティングＣＳＥは、パスＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ／ｌａｔｅｓｔが標的リソース組の中の各リソースのために有効であることを検証する。

実施例４の図１１のステップ２ｅでは、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ／ｌａｔｅｓｔにおける発信側４０２のＤＥＬＥＴＥ権に基づいて、ホスティングＣＳＥは、最新＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースのＤＥＬＥＴＥ動作を行う。発信側４０２が削除権を有すると仮定する。

実施例４の図１１のステップ２ｆでは、ホスティングＣＳＥは、複合応答コードを生成する。ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ＝＝Ｎｏｔｈｉｎｇに基づいて、いかなるコンテンツも応答に含まれる必要がない。ツリー検索がし尽くされたとき、それは、発信側４０２への応答を生成する。

ｏｎｅＭ２Ｍ ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０では、仮想リソース＜ｃｏｎｔａｉｎｅｒ＞／ｌａｔｅｓｔを標的にする動作が、＜ｃｏｎｔａｉｎｅｒ＞リソースの＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞子の最新インスタンス化に適用される。したがって、この例では、ＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ／ｌａｔｅｓｔに対する動作が、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースに対して実行される。

実施例５：ｅｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇを使用して、フィルタリング結果におけるリソースに対してリソースを選択的に作成または更新し、将来の使用のためにグループを作成する。

機能性：最近（すなわち、時間「ｍｙＴｉｍｅ」以降）更新された場所コンテナを伴う全てのデバイス（ＡＥ）を見出し、次いで、特定のコンテナに対してサブスクリプションを作成または更新する。合致リソースのグループが、可能な将来の使用のために形成される。

この機能性は、新たに更新された場所を伴うデバイスを発見し、新しい通知標的でサブスクリプションを更新するか、または新しいサブスクリプションを作成するために使用され得る。同時に、それは、将来の使用のためのｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒサブリソースのグループを形成する（例えば、将来の全てに対する場所更新をグループとして要求するために）。

実施例５の図１１のステップ１では、要求フォーマットを使用して、要求が送信される。
Ｔｏ： ．．．／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔ
Ｏｐｅｒａｔｉｏｎ： ＣＲＥＡＴＥ（Ｃ）
ＦｉｌｔｅｒＢａｓｅ： ＦｉｌｔｅｒＣＳＥＢａｓｅ
ＦｉｌｔｅｒＣｒｉｔｅｒｉａ：
ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞，ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞，
ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒ，ｍｏｄｉｆｉｅｄＳｉｎｃｅ＝＝ｍｙＴｉｍｅ
ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｐａｒｅｎｔ
ｆｏｒｍＧｒｏｕｐ＝＝ＭａｔｃｈｅｄＲｅｓｏｕｒｃｅｓ
ｇｒｏｕｐＩＤ： ３５
Ｃｏｎｔｅｎｔ： ＜ｍｙＳｕｂｓｃｒｉｐｔｉｏｎ＞
ＲｅｓｕｌｔＣｏｎｔｅｎｔ：ｎｏｔｈｉｎｇ
ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ：ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ：ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅ
注記：現在のｏｎｅＭ２Ｍ ＣＲＥＡＴＥプロシージャは、受信側４０４における処理に対して、ｏｎｅＭ２Ｍ−ＴＳ−０００１、ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．１．０、第１０．１．１．１節では、以下を規定する。
「コンテンツパラメータの中のｒｅｓｏｕｒｃｅＮａｍｅ属性として提案されるような作成されるリソースのための名称が、ＣＲＥＡＴＥ要求メッセージの中で発信側４０２によって提供された場合、標的リソースの子リソースの間でまだ存在していないことを検証する。標的リソース内の子が発信側４０２によって提案されるものと同一のｒｅｓｏｕｒｃｅＮａｍｅを伴って存在しない場合、作成されるリソースにその名称を使用する。子がｒｅｓｏｕｒｃｅＮａｍｅをすでに使用している場合、受信側４０４は、新しい名称を割り当て、それは、発信側４０２に返されるものとする。名称が発信側４０２によって提案されなかった場合、受信側４０４によって生成される名称を作成されるリソースに割り当てる。」
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ：ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅを使用することによって、受信側４０４は、このデフォルト挙動を以下のように修正するように指示されることができる：
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇがＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅを示し、子がｒｅｓｏｕｒｃｅＮａｍｅをすでに使用している場合、受信側４０４は、新しい名称を生成せず、新しいリソースを作成しない。代わりに、受信側４０４は、与えられたコンテンツを使用して既存の子リソースに対して更新動作を実行することを続ける。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇがＮＵＬＬまたは空である場合、デフォルト処理が起こる。

実施例５の図１１のステップ２では、処理サブステップ２ａ−２ｇが行われる。

実施例５の図１１のステップ２ａでは、ホスティングＣＳＥは、検索ベースＦｉｌｔｅｒＢａｓｅ＝ＣＳＥＢａｓｅを見出す。

実施例５の図１１のステップ２ｂでは、ホスティングＣＳＥは、条件（ｐａｒｅｎｔＲｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ＡＥ＞、ｒｅｓｏｕｒｃｅＴｙｐｅ＝＝＜ｃｏｎｔａｉｎｅｒ＞、ｒｅｓｏｕｒｃｅＮａｍｅ＝＝ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒ、ｍｏｄｉｆｉｅｄＳｉｎｃｅ＝＝ｍｙＴｉｍｅ）を満たす全てのリソースに対して、検索ベースＣＳＥＢａｓｅから検索し始める。

それは、合致リソースとして対応するｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒコンテナ、すなわち、ＣＳＥＢａｓｅ／ＡＥｋ／ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒを見出すであろう。

ｆｏｒｍＧｒｏｕｐ＝＝ＭａｔｃｈｅｄＲｅｓｏｕｒｃｅｓおよびｇｒｏｕｐＩＤ：３５に基づいて、ホスティングＣＳＥは、ｇｒｏｕｐＩＤ３５を伴うグループを形成し、各ＣＳＥＢａｓｅ／ＡＥｋ／ｌｏｃａｔｉｏｎＣｏｎｔａｉｎｅｒ合致リソースをそれが見出されるとグループに追加する。

ｒｅｔｕｒｎＲｅｌａｔｉｖｅＲｅｌａｔｉｏｎｓｈｉｐ＝＝Ｐａｒｅｎｔに基づいて、各ＣＳＥＢａｓｅ／ＡＥｋは、フィルタリング結果のための候補になる。

実施例５の図１１のステップ２ｃでは、各反復に対して、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋにおける発信側４０２のＣＲＥＡＴＥ権に基づいて、ホスティングＣＳＥは、このリソースをフィルタリング結果に追加する。発信側４０２が発見権を有すると仮定する。

実施例５の図１１のステップ２ｄでは、Ｔｏ＝＝．．．／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔに基づいて、ホスティングＣＳＥは、ＣＲＥＡＴＥ動作がＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔに対して行われる必要があることを把握する。

ホスティングＣＳＥは、パスＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔが標的リソース組の中の各リソースのために有効であることを検証する。

実施例５の図１１のステップ２ｅでは、ＡＣＰおよびＣＳＥＢａｓｅ／ＡＥｋ／ｔｅｍｐＭｅａｓｕｒｅｍｅｎｔにおける発信側４０２の作成権に基づいて、ホスティングＣＳＥは、＜ｍｙＳｕｂｓｃｒｉｐｔｉｏｎ＞リソースのＣＲＥＡＴＥ動作を行う。発信側４０２が更新権を有すると仮定する。

ＥｘｃｅｐｔｉｏｎＨａｎｄｌｉｎｇ：ＵｐｄａｔｅＥｘｉｓｔｉｎｇＮａｍｅに基づいて、＜ｍｙＳｕｂｓｃｒｉｐｔｉｏｎ＞と名付けられたサブスクリプションリソースが存在する場合、ホスティングＣＳＥは、既存の＜ｍｙＳｕｂｓｃｒｉｐｔｉｏｎ＞リソースを更新する。

実施例５の図１１のステップ２ｆでは、ホスティングＣＳＥは、通常の動作要件によって命じられるように、更新されたリソースのいくつかの属性のための値を割り当て得る。

実施例５の図１１のステップ２ｇでは、ホスティングＣＳＥは、複合応答コードおよび応答コンテンツを生成する。ＣｏｍｐｏｓｉｔｅＲｅｓｕｌｔ、すなわち、ＯｐｅｒａｔｉｏｎＲｅｓｕｌｔおよびＲｅｓｕｌｔＣｏｎｔｅｎｔ、すなわち、Ｎｏｔｈｉｎｇに基づいて、いかなるコンテンツも応答とともに返送されない。

図１２Ａ−Ｂは、例示的要求処理フローチャートを図示する。

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

（ｏｎｅＭ２Ｍ実施形態の代替物）
本節は、上で説明されるものの代替ソリューションを説明する。最初に、要求パラメータの代替物を提示し、その後、フィルタ基準の代替物が続く。

本節では、上で説明される新しい属性のうちのいくつかが、いくつかの異なるフィールド／パラメータを使用する一方で、開始点として同一のｏｎｅＭ２Ｍ要求フォーマットを使用して実装される。実装は、異なるが、対処される問題およびユースケースは、同一である。

（多重論理的ネスト化フィルタ基準）
このソリューションのための新しいパラメータが、既存のパラメータの使用にもたらされるべき可能な修正および明確化とともに、表６で強調表示される。この例では、要求の中の３つの異なるフィルタ基準パラメータの使用の例を示し、２つ以上のものが同様に機能するであろう。

多重ネスト化フィルタ基準が使用されるとき、ホスティングＣＳＥは、以下のように図１１のフローのステップ０００２を行う。
（Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ １が存在する）場合
｛
ホスティングＣＳＥは、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ １を満たす全てのリソースに対して、サーチベースＦｉｌｔｅｒＢａｓｅから検索を始め、フィルタ結果 １を形成する
（Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ ２が存在する）場合
｛
ホスティングＣＳＥは、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ ２を満たす全てのリソースに対して、フィルタ結果 １から検索を始め、フィルタ結果 ２を形成する
（ＦｉｌｔｅｒＣｒｉｔｅｒｉａ ３が存在する）場合
｛
ホスティングＣＳＥは、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ ３を満たす全てのリソースに対して、フィルタ結果 ２から検索を始め、フィルタ結果 ３＝＝最終フィルタ結果を形成する
｝
｝
｝
（異なる階層レベルで適用される多重フィルタ基準）
このソリューションのための新しいパラメータが、既存のパラメータの使用にもたらされるべき可能な修正および明確化とともに、表７で強調表示される。この例では、要求の中の３つの異なるフィルタ基準パラメータの使用の例を示し、２つ以上のものが同様に機能するであろう。

多重レベルフィルタ基準が使用されるとき、ホスティングＣＳＥは、以下のように図１１のフローのステップ０００２を行う。
（ＢａｓｅＦｉｌｔｅｒＣｒｉｔｅｒｉａがＮＵＬＬでない）の場合
｛
（リソ−スＸがＢａｓｅＦｉｌｔｅｒＣｒｉｔｅｒｉａを満たす）間、ホスティングＣＳＥは、検索ベースＦｉｌｔｅｒＢａｓｅから検索を始める
｛
（（ＣｈｉｌｄＦｉｌｔｅｒＣｒｉｔｅｒｉａがＮＵＬＬでなく）、かつ、（リソースＸの子ＹがＣｈｉｌｄＦｉｌｔｅｒＣｒｉｔｅｒｉａを満たす））場合、
または、（ＣｈｉｌｄＦｉｌｔｅｒＣｒｉｔｅｒｉａ＝＝ＮＵＬＬ）
｛
（（ＰａｒｅｎｔＦｉｌｔｅｒＣｒｉｔｅｒｉａがＮＵＬＬでなく）、かつ、（リソースＸの親ＺがＰａｒｅｎｔＦｉｌｔｅｒＣｒｉｔｅｒｉａを満たす））場合、
または、（ＰａｒｅｎｔＦｉｌｔｅｒＣｒｉｔｅｒｉａ＝＝ＮＵＬＬ）
｛
リソースＸ＝ｍａｔｃｈＣａｎｄｉｄａｔｅ
ホストＣＳＥは、リソースＸをフィルタ結果に追加する
｝
｝
｝ツリーを通して検索する
｝
（追加のフィルタ基準検索パラメータ）
表８のパラメータが、上で議論されるものに加えて使用され得る。

（ユーザインターフェース）
グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、強化ＲＥＳＴｆｕｌ動作に関連する機能性を制御および／または構成するためにユーザを支援するために使用されることができる。図１３は、インターフェース１３０２を図示する略図である。強化ＲＥＳＴｆｕｌ動作は、通信効率を改良するために、ユーザまたはアプリケーションによって有効にされ得、表４、表５、表６、表７、および表８にリストアップされるパラメータのうちのいくつかも、インターフェース１３０２に示されるようなデフォルト値のために、ユーザまたはアプリケーションによって事前構成され得る。インターフェース１３０２は、以下で説明される図１４Ｃ−Ｄに示されるもの等のディスプレイを使用して、生成され得ることを理解されたい。

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

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

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

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

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

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

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

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

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

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

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

一実施形態では、発信側４０２、受信側４０４、受信側ＣＳＥ４０４’、ＡＥ＿ｔｍ６０４、ＭＮ−ＣＳＥ１ ６０２、およびインターフェース１３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、図１４Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、発信側４０２、受信側４０４、受信側ＣＳＥ４０４’、ＡＥ＿ｔｍ６０４、ＭＮ−ＣＳＥ１ ６０２、およびインターフェース１３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

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

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

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

さらに、発信側４０２、受信側４０４、受信側ＣＳＥ４０４’、ＡＥ＿ｔｍ６０４、ＭＮ−ＣＳＥ１ ６０２、およびインターフェース１３０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態で一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
発見動作を示す要求を送信することであって、前記要求は、作成動作も示す、ことと、
前記作成動作が行われたことを示す応答を受信することと
を前記装置に行わせる、装置。
（項目２）
前記作成動作は、前記発見動作に起因するリソース組に対して行われる、項目１に記載の装置。
（項目３）
前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、項目１に記載の装置。
（項目４）
前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記作成動作が行われるべきことを示す、項目１に記載の装置。
（項目５）
前記要求は、動作標的とは異なるフィルタベース指示を含む、項目１に記載の装置。
（項目６）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
発見動作を示す要求を受信することであって、前記要求は、作成動作も示す、ことと、
前記要求によって示されるように前記発見動作を行うことと、
前記要求によって示されるように前記作成動作を行うことと
を前記装置に行わせる、装置。
（項目７）
前記作成動作は、前記発見動作に起因するリソース組に対して行われる、項目６に記載の装置。
（項目８）
前記装置は、前記作成動作が行われたことを示す応答を送信する、項目６に記載の装置。
（項目９）
前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、項目６に記載の装置
（項目１０）
前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記作成動作が行われるべきことを示す、項目６に記載の装置。
（項目１１）
前記要求は、動作標的とは異なるフィルタベース指示を含む、項目６に記載の装置。
（項目１２）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
発見動作、リソース関係、およびＣＲＵＤ動作を示す要求を受信することと、
前記発見動作に起因し、前記リソース関係を適用することによって修正されたリソース組に対して前記ＣＲＵＤ動作を行うことと
を前記装置に行わせる、装置。
（項目１３）
前記装置は、前記作成動作が行われたことを示す応答を送信する、項目１２に記載の装置。
（項目１４）
前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、項目１２に記載の装置。
（項目１５）
前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記ＣＲＵＤ動作が行われるべきことを示す、項目１２に記載の装置。
（項目１６）
前記要求は、動作標的とは異なるフィルタベース指示を含む、項目１２に記載の装置。
（項目１７）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
ＣＲＵＤ動作を示す要求を受信することであって、前記要求は、例外ハンドリングも示す、ことと、
前記要求によって示されるように前記ＣＲＵＤ動作を行うことを試みることと、
例外の場合、前記例外ハンドリングに従って動作することと
を前記装置に行わせる、装置。
（項目１８）
前記要求は、発見動作を示す、項目１７に記載の装置。
（項目１９）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
フィルタを介した発見およびリソース関係を示す要求を送信することと、
フィルタ合致に基づき、かつ前記リソース関係を適用することによって修正された前記リソース組を含む応答を受信することと
を前記装置に行わせる、装置。
（項目２０）
前記要求は、前記結果として生じるリソース組に基づくグループの作成を示す、項目１９に記載の装置。

Claims (20)

1. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
   発見動作を示す要求を送信することであって、前記要求は、作成動作も示す、ことと、
   前記作成動作が行われたことを示す応答を受信することと
   を前記装置に行わせる、装置。
2. 前記作成動作は、前記発見動作に起因するリソース組に対して行われる、請求項１に記載の装置。
3. 前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、請求項１に記載の装置。
4. 前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記作成動作が行われるべきことを示す、請求項１に記載の装置。
5. 前記要求は、動作標的とは異なるフィルタベース指示を含む、請求項１に記載の装置。
6. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
   発見動作を示す要求を受信することであって、前記要求は、作成動作も示す、ことと、
   前記要求によって示されるように前記発見動作を行うことと、
   前記要求によって示されるように前記作成動作を行うことと
   を前記装置に行わせる、装置。
7. 前記作成動作は、前記発見動作に起因するリソース組に対して行われる、請求項６に記載の装置。
8. 前記装置は、前記作成動作が行われたことを示す応答を送信する、請求項６に記載の装置。
9. 前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、請求項６に記載の装置
10. 前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記作成動作が行われるべきことを示す、請求項６に記載の装置。
11. 前記要求は、動作標的とは異なるフィルタベース指示を含む、請求項６に記載の装置。
12. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
    発見動作、リソース関係、およびＣＲＵＤ動作を示す要求を受信することと、
    前記発見動作に起因し、前記リソース関係を適用することによって修正されたリソース組に対して前記ＣＲＵＤ動作を行うことと
    を前記装置に行わせる、装置。
13. 前記装置は、前記作成動作が行われたことを示す応答を送信する、請求項１２に記載の装置。
14. 前記要求は、フィルタ基準に合致するリソースのためのグループの作成を示す、請求項１２に記載の装置。
15. 前記要求は、前記要求の発見結果組に関連するが、それとは異なる標的リソース組に対して前記ＣＲＵＤ動作が行われるべきことを示す、請求項１２に記載の装置。
16. 前記要求は、動作標的とは異なるフィルタベース指示を含む、請求項１２に記載の装置。
17. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
    ＣＲＵＤ動作を示す要求を受信することであって、前記要求は、例外ハンドリングも示す、ことと、
    前記要求によって示されるように前記ＣＲＵＤ動作を行うことを試みることと、
    例外の場合、前記例外ハンドリングに従って動作することと
    を前記装置に行わせる、装置。
18. 前記要求は、発見動作を示す、請求項１７に記載の装置。
19. プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
    フィルタを介した発見およびリソース関係を示す要求を送信することと、
    フィルタ合致に基づき、かつ前記リソース関係を適用することによって修正された前記リソース組を含む応答を受信することと
    を前記装置に行わせる、装置。
20. 前記要求は、前記結果として生じるリソース組に基づくグループの作成を示す、請求項１９に記載の装置。