JP6612437B2 - サービス層登録 - Google Patents

Description

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

（ｏｎｅＭ２Ｍアーキテクチャ）
開発中の（その全体において参照することによって組み込まれるｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−２．１．０で提供されるような）ｏｎｅＭ２Ｍ規格は、「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。図１は、サービス層を定義する例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。サービス層は、ｅ−ヘルス、フリート管理、およびスマートホーム等の異なる「バーティカル」マシンツーマシン（Ｍ２Ｍ）システムおよびアプリケーションによって利用されることができる「ホリゾンタル」サービスを提供する。Ｍｃａ参照点１１１は、アプリケーションエンティティ（ＡＥ）１１２とインターフェースをとる。Ｍｃｃ参照点１１３は、同一のサービスプロバイダドメイン内の別のＣＳＥ１１５とインターフェースをとり、Ｍｃｃ’参照点１１６は、異なるサービスプロバイダドメイン１１７の中の別のＣＳＥ（図示せず）とインターフェースをとる。Ｍｃｎ参照点１１８は、下層ネットワークサービスエンティティ（ＮＳＥ）１１９とインターフェースをとる。ＮＳＥ１１９は、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」または「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。

（リソース指向アーキテクチャまたはＲｏＡとしても公知である）ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャ内で、ＣＳＥは、図２に示されるように、共通サービス機能（ＣＳＦ）の組のインスタンス化をサポートする。ＣＳＦ機能性は、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する、一意にアドレス可能なエンティティであるリソースを介して、実装される。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能である。リソースは、リソースについての関連情報を記憶している属性の組をサポートし、子リソースと称される他のリソースへの参照を含み得る。子リソースは、親リソースと包含関係を有し、その存続期間が親のリソース存続期間によって限定されるリソースである。

展開の観点から、図３は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を描写する。ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）を可能にする。ＡＳＮは、１つのＣＳＥを含み、かつ少なくとも１つのＡＥを含むノードである。物理的マッピングの例は、Ｍ２Ｍデバイスの中に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理的マッピングの例は、制約されたＭ２Ｍデバイスの中に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。ＭＮのための物理的マッピングの例は、Ｍ２Ｍゲートウェイの中に常駐するＭＮである。ＩＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。ＩＮのための物理的マッピングの例は、Ｍ２Ｍサービスインフラストラクチャの中に常駐するＩＮである。ｏｎｅＭ２Ｍエンティティを含まない（ＡＥもＣＳＥも含まない）ノードである非ｏｎｅＭ２Ｍノードも存在し得る。そのようなノードは、管理を含むインターワーキング目的のためにｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。

（登録）
従来、ＡＳＮ、ＭＮ、またはＩＮ上のＡＥは、対応するＣＳＥによって提供されるＭ２Ｍサービスを使用するために、ローカルでそのＣＳＥへの登録を行う。ＡＤＮ上のＡＥは、ＭＮまたはＩＮ上のＣＳＥによって提供されるＭ２Ｍサービスを使用するために、そのＣＳＥへの登録を行う。ＩＮ−ＡＥは、ＩＮ上の対応するＣＳＥによって提供されるＭ２Ｍサービスを使用するために、そのＩＮ ＣＳＥへの登録を行う。

ＡＳＮ上のＣＳＥは、ＭＮにおけるＣＳＥによって提供されるＭ２Ｍサービスを使用可能にするために、ＭＮにおけるＣＳＥへの登録を行う。ＭＮ−ＣＳＥへの成功したＡＳＮ−ＣＳＥ登録の結果として、ＡＳＮ上のＣＳＥとＭＮ上のＣＳＥとは、それらが情報を交換することを可能にする関係を確立する。

ＭＮ上のＣＳＥは、他のＭＮにおけるＣＳＥによって提供されるＭ２Ｍサービスを使用可能にするために、別のＭＮのＣＳＥへの登録を行う。他のＭＮ−ＣＳＥへの成功したＭＮ−ＣＳＥ登録の結果として、ＭＮ上のＣＳＥは、それらが情報を交換することを可能にする関係を確立する。

ＡＳＮ上またはＭＮ上のＣＳＥは、ＩＮにおけるＣＳＥによって提供されるＭ２Ｍサービスを使用可能にするために、ＩＮにおけるＣＳＥへの登録を行う。ＩＮ−ＣＳＥへの成功したＡＳＮ／ＭＮ登録の結果として、ＡＳＮ／ＭＮのＣＳＥとＩＮ上のＣＳＥとは、それらが情報を交換することを可能にする関係を確立する。

上記の場合、登録を行うＡＥまたはＣＳＥは、レジストリＡＥまたはレジストリＣＳＥと称される。ＡＥまたはＣＳＥが登録しているＣＳＥは、レジストラＣＳＥと称される。

ＣＳＥへのＡＥの成功した登録に続いて、ＡＥは、アクセス特権が付与されていることを仮定して、レジストラＣＳＥからの要求の潜在的標的である全てのＣＳＥにおけるリソースにアクセスすることができる。

以下は、いくつかの従来の登録規制である。
ＡＥは、２つ以上のＣＳＥ（ＡＳＮ−ＣＳＥ、ＭＮ−ＣＳＥ、またはＩＮ−ＣＳＥ）に登録されないものとする。
ＡＳＮ−ＣＳＥは、最大でも１つの他のＣＳＥ（ＭＮ−ＣＳＥまたはＩＮ−ＣＳＥ）に登録されることができるものとする。
ＭＮ−ＣＳＥは、最大でも１つの他のＣＳＥ（ＭＮ−ＣＳＥまたはＩＮ−ＣＳＥ）に登録されることができるものとする。
複数の一方向登録の連結（登録チェーン）は、ループを形成しないものとする。例えば、２つのＭＮ−ＣＳＥ ＡおよびＢは、互いに登録することができない。３つのＭＮ−ＣＳＥ Ａ、Ｂ、およびＣでは、ＡがＢに登録し、ＢがＣに登録している場合、ＣはＡに登録することができない。

従来、ＣＳＥ登録プロシージャは、２つのリソース（受信側ＣＳＥ上の＜ｒｅｍｏｔｅＣＳＥ＞および発信側ＣＳＥ上の＜ｒｅｍｏｔｅＣＳＥ＞）の作成を要求する。発信側は、レジストリＣＳＥであるものとする。受信側は、最初に＜ｒｅｍｏｔｅＣＳＥ＞リソースを作成するレジストラＣＳＥであるものとする。図４は、＜ｒｅｍｏｔｅＣＳＥ＞リソースを作成するための例示的プロシージャを図示する。ステップ１３１では、発信側１２１は、ＣＲＥＡＴＥ要求メッセージを送信する。ステップ１３２では、受信側１２１は、登録要求メッセージを処理する。ステップ１３３では、受信側１２１は、登録されたＣＳＥのアドレス／ＵＲＩを含む登録応答メッセージで応答する。ステップ１３４では、発信側は、ＣＲＥＡＴＥ応答メッセージの受信時、その＜ＣＳＥＢａｓｅ＞リソースの下にローカルで＜ｒｅｍｏｔｅＣＳＥ＞リソースを作成する。このリソースは、受信側１２１ ＣＳＥを表している。発信側１２０は、全ての必須パラメータに対して適切な値を提供する。ステップ１３５では、発信側１２０は、ステップ１３４に対するような受信側１２１において作成された＜ｒｅｍｏｔｅＣＳＥ＞リソースの随意のパラメータ（例えば、ｌａｂｅｌｓ、ＡｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ属性）を取得するために、受信側に向けた（ＣＲＥＡＴＥ要求メッセージのためと同じＴｏ）ＲＥＴＲＩＥＶＥ要求を発行し得る。ステップ１３６では、受信側１２１は、発信側１２０が情報にアクセスするための適切な特権を有することを検証する。ステップ１３７では、受信側１２１は、ＲＥＴＲＩＥＶＥ応答メッセージを送信する。ステップ１３８では、発信側１２０は、ステップ１３７で取得される情報を用いて、受信側１２１のための作成された＜ｒｅｍｏｔｅＣＳＥ＞リソースを更新する。

従来、ＡＥ登録のためのプロシージャは、図５で描写されるメッセージフロー説明に従う。発信側は、レジストリＡＥである。受信側（レジストラＣＳＥ）は、適用可能なサブスクリプションプロファイルの中のアクセス制御ポリシおよび情報に従って、＜ＡＥ＞リソースの作成を可能にする。受信側は、レジストラＣＳＥのＣＳＥ−ＩＤから適用可能なＭ２Ｍ−Ｓｅｒｖｉｃｅ−Ｐｒｏｆｉｌｅ−ＩＤを導出する。図５では、情報の一部が切り捨てられているが、それらは、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−２．１．０で見出され得ることに留意されたい。

図５を参照すると、ステップ１４１では、レジストリＡＥ１２３が登録を行うためにセキュリティアソシエーションを使用することを意図する場合、セキュリティアソシエーション確立プロシージャが最初に実施される。ステップ１４２では、レジストリＡＥ１２３は、ＣＲＥＡＴＥ要求メッセージにおいて以下の具体的情報とともに登録ＣＲＥＡＴＥプロシージャのための情報を送信する。
Ｆｒｏｍ：ＡＥ−ＩＤ−ＳｔｅｍまたはＮＵＬＬ
−レジストリＡＥ１２３がすでに以前に成功裏に登録し、そして、登録解除しており、以前と同一のＡＥ−ＩＤ−Ｓｔｅｍ値で再び登録することを意図する場合、レジストリＡＥ１２３は、Ｆｒｏｍパラメータの中にそのＡＥ−ＩＤ−Ｓｔｅｍ値を含むものとする。
−レジストリＡＥ１２３が以前に成功裏に登録しておらず、それ自体に割り当てられる「Ｓ」という文字から始まるＭ２Ｍ−ＳＰ割り当てＡＥ−ＩＤ−Ｓｔｅｍを得ることを意図するが、提案すべきいかなる具体的な値も有していない場合、Ｆｒｏｍパラメータを文字「Ｓ」に設定するものとする。
−レジストリＡＥ１２３が新たな登録を開始することを意図し、ＡＥ−ＩＤ−Ｓｔｅｍ値の選好を有していない場合、Ｆｒｏｍパラメータは、ＮＵＬＬに設定されるものとする。
ステップ１４３では、受信側（例えば、レジストラＣＳＥ１２４）は、レジストリＡＥ１２３を登録するための要求が以下の条件のうちのいずれかを満たすかどうかを決定するものとする。適用可能なサービスサブスクリプションプロファイルが、要求のＣｏｎｔｅｎｔパラメータの中のＡｐｐ−ＩＤ属性および要求のＦｒｏｍパラメータの中のＡＥ−ＩＤ−Ｓｔｅｍに合致する、Ｃｒｅｄｅｎｔｉａｌ−ＩＤおよびレジストラＣＳＥ−ＩＤの組み合わせ（許容ＡＥ−ＩＤ−Ｓｔｅｍ値および許容Ａｐｐ−ＩＤ値）をリストアップするかどうかというチェックがある。このチェックのための適用可能な規則は、レジストラＣＳＥに関連付けられる＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＮｏｄｅ＞リソースのｒｕｌｅＬｉｎｋｓ属性によってリンクされる、＜ｓｅｒｖｉｃｅＳｕｂｓｃｒｉｂｅｄＡｐｐＲｕｌｅ＞リソースの中に含まれる。ステップ１４４では、要求のＦｒｏｍパラメータがＡＥ−ＩＤ−Ｓｔｅｍ値を提供する場合、レジストラＣＳＥは、要求のＦｒｏｍパラメータの中で提供されるＡＥ−ＩＤ−Ｓｔｅｍ値と同じＵｎｓｔｒｕｃｔｕｒｅｄ−ＣＳＥ−ｒｅｌａｔｉｖｅ−ｒｅｓｏｕｒｃｅ−ＩＤを伴う＜ＡＥ＞リソースがすでに存在しているかどうかをチェックする。該当する場合、レジストラＣＳＥ上の同一のＡＥ−ＩＤ−Ｓｔｅｍを使用するアクティブな登録が依然として存在し、レジストラＣＳＥは、エラーで応答するものとする。

図５を継続して参照すると、プロシージャは、詳細がｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−２．１．０で見出され得る、ステップ１４９に応答して全て終了する、以下のケースａ）−ｄ）の１つを続ける。
・ケースａ）ＡＥ−ＩＤ−Ｓｔｅｍは、「Ｓ」から始まり、ＡＥは、ＡＥ−ＩＤ−Ｓｔｅｍを含まない（初期登録）−ステップ１４５ａから１４８ａ
・ケースｂ）ＡＥ−ＩＤ−Ｓｔｅｍは、「Ｓ」から始まり、ＡＥは、ＡＥ−ＩＤ−Ｓｔｅｍを含む（再登録）−ステップ１４５ｂから１４８ｂ
・ケースｃ）ＡＥ−ＩＤ−Ｓｔｅｍは、「Ｃ」から始まり、ＡＥは、ＡＥ−ＩＤ−Ｓｔｅｍを含まない（初期登録）−ステップ１４５ｃ
・ケースｄ）ＡＥ−ＩＤ−Ｓｔｅｍは、「Ｃ」から始まり、ＡＥは、ＡＥ−ＩＤ−Ｓｔｅｍを含む（再登録）−ステップ１４５ｄ

（リソースタイプｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ）
従来、＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞リソースは、Ｍ２Ｍサービスサブスクリプションを表す。それは、Ｍ２Ｍサービスサブスクリプションに関する全てのデータ、すなわち、Ｍ２ＭアプリケーションサービスプロバイダとＭ２Ｍサービスプロバイダとの間の契約の技術的部分を表すために使用される。＜ｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅ＞リソースのｓｅｒｖｉｃｅＲｏｌｅｓ属性は、このサービスサブスクリプションにおいてサブスクライブされるサービス役割ＩＤ（Ｓ−ＲｏｌｅＩＤ）のリストを含む。

（サービスオーケストレーションプロファイル）
従来、サービスオーケストレーションプロファイルの役割は、サービスオーケストレーションとサービス発見等の他の機能とのために使用されることができる、サービス関連属性（すなわち、メタデータ）の交換のための機構を提供することである。以下の属性は、サービスオーケストレーションプロファイルのいくつかの例である。「プロファイル識別子」は、プロファイルの識別子を規定する。「プロファイルセマンティクス」は、意味記述、またはプロファイル内に含まれるサービスオーケストレーション属性を説明する意味記述へのアドレス／リンクを規定する。「プロファイルタイプ」は、プロファイルのタイプを規定する。「サービスオーケストレーション標的」は、サービスオーケストレーションが行われる標的（例えば、サービスノード、サービス層、またはサービス能力インスタンス）の随意のリストを規定する。「サービスオーケストレーションスケジュール」は、サービスオーケストレーションが行われるとき、および／またはプロファイルが有効である持続時間のスケジューリング情報を規定する。「サービスオーケストレーションポリシ」は、サービスオーケストレーションを行うことを適格とするポリシを規定する。「サービスオーケストレーションコンテキスト」は、サービスオーケストレーションに適用可能であるコンテキスト情報を規定する。「所望のサービス」は、オーケストレーションクライアントが規定標的上に編成されることを要求している、サービス構成を規定する。「サポートされたサービス」は、オーケストレーション標的がサポートする、サポートされたサービスの組を規定する。

（サービス層メッセージルーティングサービス）
メッセージルーティングサービスは、ＣＳＥがそのレジストリＡＥまたはＣＳＥから標的にメッセージをルーティングして転送することを可能にするサービスである（メッセージは、レジストリＡＥもしくはＣＳＥから生じ得るか、またはメッセージは、レジストリＣＳＥによって転送され得る）。一般に、メッセージルーティングサービスは、レジストラエンティティがレジストリエンティティに提供し得るサービスであり、その逆も同様である。メッセージルーティングサービスは、デフォルトで、メッセージルーティングサービスが相互かつ双方向であるので、特殊なサービスと見なされ得る。それは、レジストラエンティティがこのメッセージルーティングサービスのアクセス許可をそのレジストリエンティティに付与するとき、レジストリエンティティも、レジストラエンティティのためのメッセージルーティングサービスを自動的に提供することを意味する。これは、メッセージルーティングサービスのデフォルト設定であるが、しかしながら、サービスは、一方向として設定され得ることに留意されたい。ＳＬエンティティによってホストされるローカルサービスの各々は、ローカルサービス間で一意である識別子を有するものとする。

従来、１つのＣＳＥに登録するとき、１つのＣＳＥ上に（必要ではないこともある）全てのリソースの対応する予約があり得る。必要とされるであろうサービスのためのリソースのみを予約することが有益であり得る。これは、ＣＳＥと接続される容量（例えば、デバイス／ＡＥの数）に関する任意の制限内での使用を調整することに役立ち得る。

本明細書では、以下の性質を有する柔軟なサービス層登録が開示される。ＳＬエンティティ（例えば、ＡＥ、レジストリエンティティとも称されるｏｎｅＭ２ＭにおけるＣＳＥ）は、ＳＬエンティティ（例えば、レジストラエンティティとも称されるｏｎｅＭ２ＭにおけるＣＳＥ）に登録し、レジストラエンティティによってホストされるローカルサービスへのアクセスを獲得するために積極的に要求し得る。レジストラエンティティは、レジストリエンティティの登録要求を受理するが、レジストリエンティティへその部分的サービスのアクセスのみを付与し得る。レジストリエンティティがその登録要求メッセージ内でサービスを積極的に要求する必要がない場合、レジストラエンティティは、どのようなサービスがレジストリエンティティによって必要とされ得るかを決定し、これらのサービスのアクセスをレジストリエンティティに付与する。

レジストリエンティティは、２つ以上のレジストラエンティティに登録し得る。例えば、１つのレジストラエンティティが要求されたサービスのアクセスをレジストリエンティティに付与しない場合、同一のサービスのために別のエンティティに登録することができる。複数の一方向登録の連結（登録チェーン）は、ループを形成し得る。

本明細書では、ｒｅｍｏｔｅＣＳＥリソース強化ならびに新しいリソースを用いたｏｎｅＭ２Ｍ実施例が開示される。実施例は、ＣＳＥのローカルサービス、ならびに登録されたＡＥおよびＣＳＥの付与されたサービス、拒否されたサービス、および保留中サービスを管理する方法を提供する。

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

図１は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図２は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図３は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる例示的構成を図示する。 図４は、＜ｒｅｍｏｔｅＣＳＥ＞リソースを作成するための例示的プロシージャを図示する。 図５は、＜ＡＥ＞リソースを作成するための例示的プロシージャを図示する。 図６は、例示的ユースケースサービス層登録を図示する。 図７は、例示的ユースケースサービス層登録を図示する。 図８は、柔軟なサービス層登録のための例示的メッセージフローを図示する。 図９は、柔軟なサービス層登録のための例示的メッセージフローを図示する。 図１０は、複数のレジストラエンティティへの例示的登録を図示する。 図１１は、＜ＣＳＥＢａｓｅ＞に追加される例示的子リソースを図示する。 図１２は、＜ｒｅｍｏｔｅＣＳＥ＞に追加される例示的子リソースおよび属性を図示する。 図１３は、＜ＡＥ＞に追加される例示的子リソースおよび属性を図示する。 図１４は、例示的＜ｌｏｃａｌＳｅｒｖｉｃｅ＞リソースを図示する。 図１５は、例示的＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞リソースを図示する。 図１６は、例示的＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞リソースを図示する。 図１７は、例示的＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞リソースを図示する。 図１８は、例示的＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞リソースを図示する。 図１９は、ｏｎｅＭ２Ｍにおける柔軟な登録の例示的メッセージフローを図示する。 図２０は、柔軟なサービス層登録に基づくユーザインターフェースのための例示的アーキテクチャを図示する。 図２１は、柔軟なサービス層登録に基づいて生成され得る例示的表示を図示する。 図２２Ａは、開示される主題が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２２Ｂは、図２２Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２２Ｃは、図２２Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２２Ｄは、図２２Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

従来のサービス層登録は、レジストリが唯一のレジストラに登録することのみを可能にする。例えば、ＡＥが１つのみのＣＳＥに登録し、ＣＳＥも１つのみのＣＳＥに登録する。したがって、ＡＥまたはＣＳＥは、単一の登録されたＣＳＥ上でサービスを使用することのみできる。

現在、登録関係は、レジストリが、デフォルトで、適切なアクセス権を用いてレジストラによって提供される全てのサービスを使用することを可能にする。しかしながら、レジストリは、レジストラによって提供されるサービスの一部を使用することのみを欲し得るか、またはレジストラは、そのサービスの一部をレジストリに提供することのみを所望し得る。

従来、レジストリＡＥのサブスクリプションプロファイルは、ＡＥとＭ２Ｍサービスプロバイダとの間の契約の技術的部分に基づいて設定されることができる。関連付けられるｓｅｒｖｉｃｅＲｏｌｅｓ属性は、レジストリＡＥによってアクセスされ得るサービスおよびリソースを制御するために使用されることができる。しかしながら、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−２．１．０を伴って提供される従来の機構は、以下の問題を有する。第１の問題は、サービスプロファイルがＣＳＥではなくレジストリＡＥのみに適用可能であることである。第２の問題は、サービスプロファイルが現在定義されているリソースに関連付けられるサービスのみを考慮し、したがって、ＣＳＥによって提供される全てのローカルサービス（例えば、メッセージ転送サービス）のアクセス可能性を管理することにおいて十分に一般的ではないことである。第３の問題は、サブスクリプションプロファイルが契約ベースであり（すなわち、事前構成され、静的である）、したがって、レジストリＡＥまたはＣＳＥが、登録プロセス中にレジストラＣＳＥによって提供されるサービスを柔軟に要求することを可能にされないことである。第４の問題は、全てのサブスクリプションプロファイルがＩＮ−ＣＳＥによって管理される一方で、ＭＮ−ＣＳＥがそれ自身のサービスのユーザを決定することにおいて独立性を有していないことである。第５の問題は、各ＣＳＥが、どのようなサービスがそれによって必要とされ得るかについてレジストリＡＥまたはＣＳＥのために決定を行う知性を有していないことである。

したがって、従来のサービス層登録は、レジストリが登録プロセス中にレジストラからサービスを柔軟に要求することを可能にし、レジストラがそのサービスのうちのいくつかを使用するための許可をレジストリに選択的に付与することを可能にする能力を欠いている。本明細書では、レジストリが複数のＣＳＥに登録することを可能にする方法が開示される。実施例では、ＣＳＥは、複数の通過ＣＳＥによって提供されるサービス層メッセージルーティングサービスを使用し得る。

図６は、複数のサービス層エンティティの使用のための第１の例示的環境を図示し、電話（例えば、電話／ＡＳＮ−ＣＳＥ１６１）が、複数の他のサービス層（ＳＬ）エンティティと接続し得る。図６では、ホームＷｉ−Ｆｉアクセスポイント１６３（ＭＮ−ＣＳＥ）、ＬＴＥ ｅＮＢ１６２（ＭＮ−ＣＳＥ）、およびデータサーバ１６４（ＩＮ−ＣＳＥ）等の複数のＳＬエンティティがある。電話１６１は、Ｗｉ−Ｆｉアクセスポイント１６３またはＬＴＥ ｅＮＢ１６２のサービスエリア内にあり得る。電話ＳＬ１６１は、クラウド１６５（例えば、Ａｍａｚｏｎ（登録商標）クラウドまたはＦａｃｅｂｏｏｋ（登録商標））を介して、データサーバ１６４と通信可能に接続され得る。電話１６１は、低コストに起因して通信管理および配信ハンドリングサービスのためのＷ−Ｆｉアクセスポイント１６３に登録し得る。電話１６１は、セルラーネットワークが良好な認証機構および場所情報等を提供するので、他のより安価なインターネット、アクセス、セキュリティサービス、ならびに場所サービスがないとき、あるサービス、例えば、通信管理および配信ハンドリングのために、ＬＴＥ ｅＮＢ１６２にも登録し得る。電話ＳＬ１６１は、その上で起動する多くのアプリケーション、ならびに統合センサを有し得る。クラウド１６５の中でホストされるデータサーバ１６４内のＳＬは、性質に関連するデータ（温度、湿度、雑音等）、社会生活に関連するデータ（ソーシャルアプリケーション、広告等）等を管理して記憶し得る。電話１６１のＳＬは、異なるタイプのデータおよびアプリケーションのためのデータ管理およびリポジトリ、サブスクリプションおよび通知、場所、発見等のサービスのために、クラウド１６５の中でホストされるデータサーバ１６４内のＳＬに登録する。

以下では、図６との関連で複数のＳＬエンティティの使用のための例示的シナリオが開示される。電話１６１は、朝のコーヒーのためにコーヒーマシンをオンにするために使用され得る。電話１６１は、Ｗｉ−Ｆｉアクセスポイント１６３によって提供されるデバイス管理サービスを使用し、認証のためにＬＴＥ ｅＮＢ１６２によって提供されるセキュリティサービスも使用し得る。最後に、電話１６１は、コーヒーの準備ができているという通知を受信するために、データサーバ１６４によって提供されるデータ管理サービスおよびサブスクリプションサービスを使用し得る。

図７は、複数のサービス層エンティティの使用のための第１の例示的環境を図示し、車載ユニットが、複数のＳＬエンティティと接続し得る。電子通行料徴収（ＥＴＣ）は、知的輸送システムの一部である。ＥＴＣは、電子的に通行料を徴収することによって、有料道路上の遅延を低減させることに役立つ。ＥＴＣシステムは、通過する車両がプログラムに登録されているかどうかを決定し、登録されていないものに対してエンフォーサに警告し、停止するように要求することなく、登録された車両所有者の口座に電子的に負債を記入する。車載ユニット（ＯＢＵ）１７１は、車両１７１の中に位置するデバイスであり、沿道ＣＳＥ１７５または沿道ＣＳＥ１７６を介してＥＴＣサービスプラットフォーム１７３もしくはＥＴＣサービスプロバイダ１７４と通信可能に接続され得る。ＯＢＵ１７１は、ＥＴＣサービスプロバイダ１７４に登録し得、ＥＴＣサービスプロバイダ１７４は、ＥＴＣサービスを提供すること、例えば、車両１７１のＯＢＵ１７２を承認すること、または通行料等を支払うように車両１７１のＯＢＵ１７２の関連付けられる口座に負債を記入することを行う。ＯＢＵ１７２は、通信サービスを提供するように、ローカル沿道ＣＳＥ１７５および沿道ＣＳＥ１７６に登録し得る。ＯＢＵ１７２はまた、車両が１つのＣＳＥのサービス範囲から出て、別のＣＳＥのサービス範囲の中へ移動するにつれて、沿道ＣＳＥ１７５および沿道ＣＳＥ１７６に同時に登録し得る。

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

図８は、第１のシナリオのための例示的メッセージフローを図示する。要約すると、この第１のシナリオに対して、レジストリエンティティ１０１は、登録要求メッセージにおいて、それがレジストラエンティティ１０２にアクセスを付与することを欲するサービスを規定する。本開示では、ＳＬ発見機能性（本明細書では詳細に議論されていない）を通して、レジストリエンティティ１０１が登録し得るエンティティ、ならびにエンティティの各々によって提供されるサービスを見出すことができることが仮定される。ｏｎｅＭ２Ｍアーキテクチャでは、ＣＳＥによって提供されるサービスは、発見、場所、通信管理および配信ハンドリング等のＣＳＦであり得る。ＣＳＥによって提供されるサービスは、メッセージルーティングサービス等、ＣＳＦのうちの１つとしてリストアップされていないものであり得る。

図８に図示される第１のシナリオに関する詳細は、以下である。ここで、レジストリエンティティ１０１は、登録中、レジストラエンティティ１０２によってホストされるサービスを積極的に要求する。ステップ１８１では、レジストリエンティティ１０１は、登録要求を含むメッセージをレジストラエンティティ１０２に送信する。ステップ１８１のメッセージは、レジストラエンティティ１０２上で利用可能であり、レジストリエンティティ１０１によって要求されるサービスの識別子を含み得る。ステップ１８２では、ステップ１８１のメッセージを受信すると、レジストラエンティティ１０２は、とりわけ、レジストリエンティティ１０１の登録を容認すべきかどうか、要求されたサービスのアクセスをレジストリエンティティ１０１に付与すべきかどうか、またはどのようなサービスがレジストリエンティティ１０１に付与されるであろうかどうかを（要因に基づいて）決定する。

図８のステップ１８２を継続して参照すると、以下は、レジストリエンティティ１０１のサービスサブスクリプションプロファイルおよびアクセス制御ポリシに加えて、レジストラエンティティ１０２が考慮し得る要因のいくつかの例である。要因は、とりわけ、ユーザの最大数、利用可能な容量、サービス料、レジストリ１０１の優先度、またはサービスをハンドリングするレジストリ１０１の容量（例えば、処理能力、メモリ、グラフィカルインターフェース等）を含み得る。ユーザの最大数に対して、要求されたサービスは、サポートされるユーザの最大数の限界を有し得る。現在のアクティブユーザがこの数未満である場合、レジストリエンティティ１０１は、サービスへのアクセスを付与され得る。そうでなければ、レジストリエンティティ１０１は、この要求されたサービスに対して拒否され得る。利用可能な容量に対して、レジストラエンティティ１０２は、要求されたサービスのためのレジストリエンティティ１０１をサポートするために必要とされる容量を推定し得る。容量は、計算容量、バッテリ、記憶、負荷、およびスケジュール等であり得る。レジストラエンティティ１０２の利用可能な容量が低い場合、レジストリエンティティ１０１は、この要求されたサービスに対して拒否され得る。別様に、レジストリエンティティ１０１が十分な容量を有する場合、レジストリエンティティ１０１は、このサービスへのアクセスを付与されることができる。サービス料金およびレジストリ１０１の勘定残高に対して、要求されたサービスは、サービスを使用する前に支払われるそれに関連付けられるサービス料金を有し得る。レジストリ１０１の勘定残高に応じて、サービスは、付与されることも、付与されないこともある。レジストラエンティティ１０２は、課金および請求を担当するエンティティと通信する必要があり得る。レジストリ１０１の優先度に対して、各レジストリエンティティは、異なるクラスの中にあり得るか、または異なる優先度、例えば、プラチナ、ゴールド、シルバー等を伴い得る。クラスレベルは、他のレジスタもじサービスを待つ場合、要求されたサービスへのアクセスを獲得することにおいてレジストリエンティティ１０１の優先度を区別する。

図８のステップ１８２を継続して参照すると、レジストラエンティティ１０２は、レジストリエンティティ１０１のために要求されたサービスについて決定を行い得る。決定は、以下のリストに該当し得る：付与されたサービスリスト、拒否されたサービスリスト、または保留中サービスリスト。付与されたサービスリストは、レジストラエンティティ１０２によってレジストリエンティティ１０１に付与される要求されたサービスのリストである。付与されたサービスの各々は、その間にレジストリエンティティ１０１がサービスを使用する資格を与えられる、期間（または時間間隔もしくは最大許容使用量／アクセス時間のリスト）に関連付けられ得る。このフィールドが空にされた場合、デフォルトで、サービスは、レジストリエンティティ１０１が登録解除するときに終了する。付与されたサービスの各々は、相互関係属性とも関連付けられ得、それは、サービスが双方向であるか、または一方向であるかを示す。相互関係が双方向である場合、これは、レジストリエンティティ１０１も、このサービスをレジストラエンティティ１０２に提供することを意味する。例えば、メッセージルーティングサービスは、デフォルトで双方向である。相互関係が一方向である場合、サービスは、レジストラエンティティ１０２からレジストリエンティティ１０１に提供されるのみである。拒否されたサービスリストは、レジストラエンティティ１０２によって拒否される要求されたサービスのリストである。拒否されたサービスの各々は、レジストラエンティティ１０２がレジストリエンティティ１０１からのサービス要求を拒否する理由に関連付けられ得る。十分ではない容量、サービス料金のための十分ではない残高等の複数の理由があり得る。拒否されたサービスの各々は、レジストリがサービスを入手し得る推奨レジストラに関連付けられ得る。拒否されたサービスリストは、同一のサービスを同一タイプのレジストリエンティティに付与するかどうかを決定する要因として、以降で使用され得る。拒否されたサービスリスト情報は、現在のレジストリエンティティの類似タイプを有する他のエンティティによって読み出され得、例えば、それらの全ては、リソース制約デバイス（例えば、最小限のメモリ、最小限の処理、電力／エネルギーへのアクセス、不十分な無線帯域幅および通信する能力等を伴うセンサ）である。保留中サービスリストは、保留中であり、以降でレジストリエンティティ１０１に対してアクセスを付与され得る要求されたサービスのリストである。保留中サービスの各々は、レジストリエンティティ１０１の順序（いくつの他のレジストリエンティティが現在のレジストリエンティティの前に待っているかを示す順序）およびレジストリエンティティ１０１が待つ必要があり得る推定期間に関連付けられ得る。

図８を継続して参照すると、ステップ１８３では、レジストラエンティティ１０２は、応答メッセージの中で決定を返す。表１は、応答メッセージの中の新しいフィールド、ならびにこれらのフィールドの各々に関連付けられるパラメータ（斜体）を示す。

レジストラエンティティ１０２は、表２に示されるように、それに登録したレジストリエンティティの記録をローカルで維持する。記録は、以下のフィールドを有する。「Ｒｅｇｉｓｔｒｅｅ ＩＤ」は、同じＳＰドメイン内のレジストリエンティティ１０１の一意の識別子である。「Ｒｅｑｕｅｓｔｅｄ Ｓｅｒｖｉｃｅ Ｆｒｏｍ」は、登録メッセージにおけるレジストリエンティティ１０１から要求されるサービスの識別子のリストである。「Ｇｒａｎｔｅｄ Ｓｅｒｖｉｃｅ Ｔｏ」は、レジストラエンティティ１０２によってレジストリエンティティ１０１に付与されたサービスの識別子のリストである。ステップ１８２で議論されるように、各付与されたサービスは、レジストラエンティティ１０２がレジストリエンティティ１０１に提供するサービスの有効な期間を示すｖａｌｉｄＴｉｍｅと呼ばれる属性に関連付けられ得る。各付与されたサービスは、サービスが双方向であるか、一方向であるかを示すｍｕｔｕａｌｉｔｙと呼ばれる属性に関連付けられ得る。「Ｒｅｊｅｃｔｅｄ Ｓｅｒｖｉｃｅ Ｔｏ」は、レジストリエンティティ１０１に対してレジストラエンティティ１０２によって拒否されたサービスの識別子のリストである。ステップ１８２で議論されるように、各拒否されたサービスは、レジストラエンティティ１０２がレジストリエンティティ１０１からのサービス要求を拒否する理由を説明するｒｅａｓｏｎと呼ばれる属性に関連付けられ得る。各拒否されたサービスは、ｒｅｃｏｍｍｅｎｄｅｄＲｅｇｉｓｔｒａｒと呼ばれる属性にも関連付けられ得、それは、現在のレジストラエンティティがレジストリエンティティ１０１に推奨する他のエンティティを示し、レジストリエンティティ１０１は、それからサービスを要求し得る。

図８のステップ１８３を継続して参照すると、「Ｐｅｎｄｉｎｇ Ｓｅｒｖｉｃｅ Ｔｏ」は、レジストラエンティティ１０２がレジストリエンティティ１０１へのアクセスを付与するために保留中であるサービスの識別子のリストである。ステップ１８２で議論されるように、各保留中サービスは、以下の属性を有する。ｅｓｔｉｍａｔｅｄＷａｉｔＴｉｍｅは、レジストラエンティティ１０２がサービスのアクセスをレジストリエンティティ１０１に付与するための推定待ち時間を示す。ａｌｌｏｗｅｄＷａｉｔＴｉｍｅは、レジストリエンティティ１０１からの許容待ち時間を示し、それは、ステップ１８４で議論されるであろう。ｐｒｉｏｒｉｔｙＯｒｄｅｒは、同じサービスを要求している他のレジストリエンティティ間のレジストリエンティティ１０１の優先度を示す。Ｓｔａｔｕｓは、保留中サービスのステータスを示し、それは、最初に「待ち」に設定される。サービスが許容待ち時間前に付与される場合、ステータスが「付与」に変更される。サービスが許容待ち時間前に拒否される場合、ステータスが「拒否」に変更される。許容待ち時間が満了したときにサービスが依然として待っている場合、ステータスが「満了して拒否」に変更される。随意に、レジストラエンティティ１０２は、付与されている保留中サービスリスト中のサービスを付与されたサービスリストに移動させ、拒否されている保留中サービスリスト中のサービスを拒否されたサービスリストに移動させ得る。

図８を継続して参照すると、ステップ１８４では、レジストリエンティティ１０１は、応答メッセージを処理する。レジストリエンティティ１０１が、双方向タイプを伴う付与されたサービスがあることを見出す場合、このサービスがそれ自体によってサポートされ、レジストラエンティティ１０２に付与されることができることを確認する。レジストリエンティティ１０１が、拒否されたサービスがあることを見出す場合、随意に、登録し、拒否されたサービスを要求するために、別のＳＬエンティティを選定し得る。レジストリエンティティ１０１が、保留中サービスがあることを見出す場合、レジストリエンティティ１０１は、以下のアクションのうちの１つをとり得る。第１のアクションは、レジストリエンティティ１０１が登録する別のＳＬエンティティを選定し、保留中サービスを要求し得ることであり得る。それは、ステップ１８５で、許容待ち時間を０に設定することによって、サービス要求を終了させるために登録確認メッセージを送信するであろう。第２のアクションでは、レジストリエンティティ１０１は、保留中サービスが付与されることを自発的に待ち得る。それは、ステップ１８５で、許容待ち時間を設定することによって、それが待ち得る時間を示すために、登録確認メッセージを送信することができる。

図８を継続して参照すると、ステップ１８５では、レジストリエンティティ１０１は、登録確認メッセージを送信し得る。表３は、確認メッセージ中の新しいフィールド、ならびにこれらのフィールドの各々に関連付けられるパラメータ（斜体）を示す。

図８を継続して参照すると、ステップ１８６では、レジストラエンティティ１０２は、登録確認メッセージをハンドリングし、レジストリエンティティ１０１の各保留中サービスの許容待ち時間を設定する。ａｌｌｏｗｅｄＷａｉｔＴｉｍｅが０以下である場合、保留中サービス要求は、キャンセルされる。保留中サービスは、レジストリエンティティ１０１記録のために削除される。ａｌｌｏｗｅｄＷａｉｔＴｉｍｅが空白ではなく、０より大きい場合、保留中サービスのａｌｌｏｗｅｄＷａｉｔＴｉｍｅは、レジストリエンティティ１０１記録のために更新される。ａｌｌｏｗｅｄＷａｉｔＴｉｍｅが空白である場合、保留中サービスのａｌｌｏｗｅｄＷａｉｔＴｉｍｅは、レジストリエンティティ１０１のために無限であると仮定される。換言すると、レジストリエンティティ１０１は、常に、サービスの保留中リストの中にあり、その順番を待つであろう。ステップ１８７では、レジストラエンティティ１０２は、保留中サービスのステータスを監視する。レジストラエンティティ１０２が、保留中サービスがしばらく経ってからレジストリエンティティ１０１に付与されることができることを見出す場合、それは、依然としてレジストリエンティティ１０１の許容待ち時間内にあるかどうかをチェックするであろう。該当する場合、それは、ステップ１８８のような保留中サービス更新メッセージをレジストリエンティティ１０１に送信するであろう。許容待ち時間が満了する場合、保留中サービスは、レジストラエンティティ１０２によって拒否される。そのうちに、レジストラエンティティ１０２は、ローカルで維持される保留中サービスのステータスを更新する。保留中サービスが付与された場合、レジストラエンティティ１０２は、サービスＩＤを付与されたサービスＩＤフィールドに追加する。保留中サービスが拒否された場合、レジストラエンティティ１０２は、サービスＩＤを拒否されたサービスＩＤフィールドに追加する。

図８を継続して参照すると、ステップ１８８では、レジストラエンティティ１０２は、保留中サービスのステータスが更新されると、保留中サービス更新メッセージをレジストリエンティティ１０１に送信する。表４は、確認メッセージ中の新しいフィールド、ならびにこれらのフィールドの各々に関連付けられるパラメータ（斜体）を示す。ステータスは、付与されるか、拒否されるかのいずれかであり得る。ステータスが付与される場合、サービスのタイプが、ステップ１８２で説明されるように示される。

サービス要求への初期登録後、以下のアクションが、レジストリエンティティ１０１とレジストラエンティティ１０２との間で起こり得る。レジストリエンティティ１０１は、サービス識別子を含むであろうサービス解約要求を送信することによって、レジストラエンティティ１０２から付与されたサービスをキャンセルする資格を与えられる。レジストラエンティティ１０２は、レジストリエンティティ１０１へのサービスを終了し、サービスの付与されたユーザリストからレジストリエンティティ１０１を除去するであろう。レジストリエンティティ１０１はまた、サービスの識別子を含むであろうサービス要求を送信することによって、レジストラエンティティ１０２から１つまたは複数の新しいサービスを要求する資格を与えられる（フィルタ基準ベースの発見またはより高度な発見機構、例えば、セマンティクスベースのクエリによって実施されることができるサービス発見プロシージャが、事前に起こり得ることに留意されたい）。レジストラエンティティ１０２は、上で説明される類似プロシージャに従い、要求サービスを付与／拒否するであろう。レジストラエンティティ１０２は、レジストリエンティティ１０１に付与されるサービスを終了することを選定し得る。レジストラエンティティ１０２は、サービスの識別子を含むサービス終了通知のためのメッセージをレジストリエンティティ１０１に送信し得る。サービス終了通知のためのメッセージは、サービス終了の猶予期間も含み得る。

図９は、第２のシナリオのための例示的メッセージフローを図示する。要約すると、この第２のシナリオに対して、レジストリエンティティ１０１は、登録メッセージ内で、レジストラエンティティ１０２の中でホストされるサービスを積極的に要求しない。したがって、既存の登録メッセージは、このシナリオでは修正される必要はない。ステップ１９１では、レジストリエンティティ１０１は、登録メッセージ（修正が既存の登録メッセージには必要とされない）をレジストラエンティティ１０２に送信する。

図９を継続して参照すると、ステップ１９２では、レジストラエンティティ１０２は、要因をチェックし、どのようなサービスがレジストリエンティティ１０１に付与されるべきかを決定する。図８に関してステップ１８２でリストアップされる要因が、適用可能である。レジストラエンティティ１０２は、レジストリエンティティ１０１タイプを考慮し得る（以下の要因に関連する情報は、レジストリのセマンティクス情報、例えば、レジストリのタイプとして、登録メッセージに含まれ得ることに留意されたい）。レジストリエンティティ１０１は、データを感知して報告するのみであるリソース制約型デバイスであり得、したがって、レジストリエンティティ１０１は、データ管理およびリポジトリサービス、デバイス管理サービス、場所サービス等のあるサービスのみを必要とし得る。レジストリエンティティ１０１は、発見サービス、サービス課金および会計サービス等を必要としないタイプであり得る。レジストリエンティティ１０１は、レジストラエンティティ１０２によって記憶されたデータを読み出して使用するアプリケーションをホストするデバイスのタイプであり得る。したがって、レジストリエンティティ１０１は、データ管理およびリポジトリサービス、発見サービス、サブスクリプションおよび通知サービス等のあるサービスのみを必要とし得る。レジストリエンティティ１０１は、デバイス管理、ネットワークサービスエクスポージャサービス等を必要としないこともある。レジストリエンティティ１０１は、そこから発信されないメッセージを主に転送するゲートウェイタイプデバイスであり得る。したがって、レジストリエンティティ１０１は、通信管理および配信ハンドリングサービス、メッセージルーティングサービス等のあるサービスのみを必要とし得る。レジストリエンティティ１０１は、データ管理およびリポジトリサービス、デバイス管理サービス等を必要としないこともある。ステップ１９３では、レジストラエンティティ１０２は、付与されたサービスリストを伴う登録応答をレジストリエンティティ１０１に返す。

図１０は、複数のレジストラエンティティへの例示的登録を図示する。複数の一方向登録の連結（登録チェーン）は、ループを形成し得る。例えば、ｏｎｅＭ２Ｍでは、２つのＭＮ−ＣＳＥ ＡおよびＢは、互いに登録することができる。３つのＭＮ−ＣＳＥ Ａ、Ｂ、およびＣでは、ＡがＢに登録し、ＢがＣに登録し、Ｃも、Ａに登録し得る。図１０は、１つのレジストリエンティティ（レジストリエンティティ１０１）から複数のレジストラエンティティ（レジストラエンティティ１０２、レジストラエンティティ１０３、およびレジストラエンティティ１０４）への例を図示する。レジストラエンティティ１０２、レジストラエンティティ１０３、およびレジストラエンティティ１０４は、すでにそれらの間に登録ループを形成している。レジストラエンティティ１０３およびレジストラエンティティ１０４は、互いに登録している。これは、従来のＳＬ登録とは対照的である。

図１０を参照すると、任意のレジストリおよびレジストラエンティティ対の間の登録は、第１のシナリオ（例えば、図８および関連付けられる議論）または第２のシナリオ（例えば、図９および関連付けられる議論）に従い得る。換言すると、レジストリエンティティは、第１のシナリオで説明されるようにレジストラエンティティに登録し得るが、第２のシナリオで説明されるように別のレジストラエンティティに登録し得る。第１のシナリオおよび第２のシナリオを含む状況を仮定すると、例では、複数のレジストラエンティティへの登録が、同一のレジストリエンティティから生じるマルチキャスト登録メッセージにおいて実行され得る。

ＳＬエンティティに対して、ＳＬエンティティが別のＳＬエンティティからあるサービスへのアクセスを付与され得る複数の方法がある。第１の方法では、ＳＬエンティティは、第１のシナリオまたは第２のシナリオで議論されるように別のＳＬエンティティに登録する。したがって、ＳＬエンティティは、レジストリエンティティとしてサービスのアクセスを付与される。第２の方法では、ＳＬエンティティは、あるサービスのために別のＳＬエンティティによって登録されている。しかし、サービスは、双方向のタイプを有する。レジストラエンティティとしてのＳＬエンティティも、レジストリエンティティからのサービスのアクセスを付与される。

各ＳＬエンティティはまた、表５に示されるように、それ自体がサービスを受信するＳＬエンティティの記録も維持する。ＳＬ Ｅｎｔｉｔｙ ＩＤは、あるサービスをローカルＳＬエンティティに提供するＳＬエンティティの一意の識別子を示す。「Ｇｒａｎｔｅｄ Ｓｅｒｖｉｃｅ Ｆｒｏｍ」は、ＳＬエンティティからローカルＳＬエンティティに付与されるサービスの識別子のリストである。各付与されたサービスは、ＳＬエンティティがローカルＳＬエンティティに提供するサービスの有効な期間を示す、ｖａｌｉｄＴｉｍｅと呼ばれる属性に関連付けられ得る。

ｏｎｅＭ２Ｍ実施例が、以下でさらに詳細に議論される。ＡＥは、２つ以上のＣＳＥ（例えば、ＡＳＮ−ＣＳＥ１６１、ＭＮ−ＣＳＥ１６２、またはＩＮ−ＣＳＥ１６４）に登録され得る。ＡＳＮ−ＣＳＥ１６１は、２つ以上の他のＣＳＥ（例えば、ＭＮ−ＣＳＥ１６３またはＩＮ−ＣＳＥ１６４）に登録され得る。ＭＮ−ＣＳＥ１６３は、２つ以上の他のＣＳＥ（ＭＮ−ＣＳＥ１６２またはＩＮ−ＣＳＥ１６４）に登録され得る。ＩＮ−ＣＳＥは、２つ以上の他のＣＳＥ（ＩＮ−ＣＳＥ）に登録され得る。複数の一方向登録の連結（登録チェーン）は、ループを形成し得る。例えば、２つのＭＮ−ＣＳＥ ＡおよびＢ（例えば、レジストラ１０３およびレジストラ１０４）は、互いに登録し得る。３つのＭＮ−ＣＳＥ Ａ、Ｂ、およびＣ（例えば、それぞれ、レジストラ１０３、レジストラ１０２、およびレジストラ１０４）があり得、ＡがＢに登録し、ＢがＣに登録し、次いで、ＣがＡに登録し得る。

ＡＥまたはＣＳＥは、ＣＳＥに登録し、レジストラＣＳＥによってホストされるローカルサービスへのアクセスを獲得することを積極的に要求し得る。レジストラＣＳＥは、レジストリＡＥまたはＣＳＥの登録要求を容認し得るが、全てのそのサービスの代わりに、サービスの部分組へのアクセスのみをレジストリＡＥまたはＣＳＥに付与し得る。

レジストリＡＥまたはＣＳＥは、その登録要求メッセージ内でサービスを積極的に要求する必要がないこともある。レジストラＣＳＥは、どのようなサービスがレジストリＡＥまたはＣＳＥによって必要とされ得るかを決定し、それらのサービスのアクセスをレジストリＡＥまたはＣＳＥに付与し得る。

本明細書で要約される柔軟なサービス層登録をサポートするために、以下で議論されるような新しい属性および新しい子リソースが、ｒｅｍｏｔｅＣＳＥおよびＡＥリソースに追加されるべきである。

＜ＣＳＥＢａｓｅ＞リソース強化
図１１は、＜ＣＳＥＢａｓｅ＞に追加される例示的な新しい子リソースを図示する。＜ＣＳＥＢａｓｅ＞２２０は、表６に示されるような新しい子リソース、すなわち、＜ｌｏｃａｌＳｅｒｖｉｃｅ＞２２１および＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞２２２を含み得る。

＜ｒｅｍｏｔｅＣＳＥ＞リソース強化
図１２は、＜ｒｅｍｏｔｅＣＳＥ＞２２４に追加される例示的な新しい子リソースおよび属性を図示する。＜ｒｅｍｏｔｅＣＳＥ＞２２４は、表７に示されるように、新しい子リソース、すなわち、＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞２２６、＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞２２７、＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞２２８を含み得る。＜ｒｅｍｏｔｅＣＳＥ＞２２４は、表８に示されるように、新しい属性、すなわち、ｒｅｑｕｅｓｔｅｄＳｅｒｖｉｃｅＦｒｏｍ２２５を含み得る。

（＜ＡＥ＞リソース強化）
図１３は、＜ＡＥ＞２３０に追加される例示的な新しい子リソースおよび属性を図示する。＜ＡＥ＞２３０は、表９に示されるように、新しい子リソース、すなわち、＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞２２６、＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞２２７、および＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞２２８を含み得る。＜ＡＥ＞は、表１０に示されるように、新しい属性、すなわち、ｒｅｑｕｅｓｔｅｄＳｅｒｖｉｃｅＦｒｏｍ２２５を含み得る。

＜ｌｏｃａｌＳｅｒｖｉｃｅ＞リソース
図１４は、発見、場所、通信管理および配信ハンドリング等のＣＳＦであり得る、ホスティングＣＳＦによって提供されるサービスを保持する、例示的＜ｌｏｃａｌＳｅｒｖｉｃｅ＞２２１リソースを図示する。ローカルサービスは、それが中間ノードであるときに各ＣＳＥによって暗示的に提供される本明細書に説明されるようなメッセージ転送サービス、またはＣＳＥの中で保持されるデータによって可能にされるサービス（例えば、温度サービス、交通監視サービス等）等、ＣＳＦ以外のサービスでもあり得る。表１１は、＜ｌｏｃａｌＳｅｒｖｉｃｅ＞２２１の属性を示す。一般的な属性は、表に示されていない。＜ｌｏｃａｌＳｅｒｖｉｃｅ＞２２１リソースのａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ属性が、サービスへのアクセスを付与されるＡＥまたはＣＳＥを示すアクセス権ポリシの識別子のリストを含むことに留意されたい。

＜ｌｏｃａｌＳｅｒｖｉｃｅ＞２２１リソースは、＜ＣＳＥＢａｓｅ＞２２０の親を有する。

＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞リソース
図１５は、ホスティングＣＳＥによるｒｅｍｏｔｅＣＳＥまたはＡＥへの付与されたサービスを保持する、例示的＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞２２６リソースを図示する。表１２は、＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞２２６の属性を示す。

＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ＞２２６リソースは、＜ＡＥ＞２３０または＜ｒｅｍｏｔｅＣＳＥ＞２２４の親を有する。このリソースは、サービスを提供することにおいてローカルＣＳＥと協力することができるように、別のＣＳＥが同一のＡＥまたはｒｅｍｏｔｅＣＳＥへの付与されたサービスを把握することを所望するとき、標的にされるであろう。

（＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞リソース）
図１６は、ホスティングＣＳＥがアクセスをＣＳＥまたはＡＥに付与することを拒否する、サービスを保持する、例示的＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞２２７リソースを図示する。表１３は、＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞２２７の属性を示す。

＜ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ＞２２７リソースは、＜ＡＥ＞２３０または＜ｒｅｍｏｔｅＣＳＥ＞２２４の親を有する。ＡＥ／ＣＳＥは、拒否され得るリスト全体を含むことなく、どのようなサービスがレジストラＣＳＥによって付与され得るかを理解するように、類似タイプのＡＥ／ＣＳＥのこの情報を読み出し得る。

（＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞リソース）
図１７は、ＡＥまたはＣＳＥがホスティングＣＳＥによって付与されることを待っている保留中サービスを保持する、例示的＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞２２８リソースを図示する。表１４は、＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞２２８の属性を示す。

＜ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏ＞２２８リソースは、＜ＡＥ＞２３０または＜ｒｅｍｏｔｅＣＳＥ＞２２４の親を有する。

（＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞リソース）
図１８は、ＣＳＥからホスティングＣＳＥへの付与されたサービスを保持する、例示的＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞２２２リソースを図示する。表１５は、＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞の属性を示す。

＜ｇｒａｎｔｅｄＳｅｒｖｉｃｅＦｒｏｍ＞２２２リソースは、＜ＣＳＥＢａｓｅ＞２２０の親を有する。

図１９は、柔軟な登録のための例示的メッセージフローを図示する。ステップ２１１では、発信側２０１は、ＣＲＥＡＴＥ要求メッセージを受信側２０２に送信する。ｒｅｑｕｅｓｔｅｄＳｅｒｖｉｃｅパラメータが、ステップ２１１のメッセージに含まれ得る。発信側２０１は、ｒｅｑｕｅｓｔｅｄＳｅｒｖｉｃｅパラメータを用いたｒｅｍｏｔｅＣＳＥリソースの作成を要求する。ステップ２１２では、受信側２０２は、＜ｒｅｍｏｔｅＣＳＥ＞リソースの作成を行う。受信側２０２は、要因をチェックし、要求されたサービスのアクセスを付与し、ｒｅｍｏｔｅＣＳＥリソースを作成すべきかどうかを決定する。保留中サービスがある場合、受信側２０２は、発信側２０１が保留中サービスのステータス変更の通知を受信するために、発信側２０１のためのｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏリソースへのサブスクリプションを作成する。ステップ２１３では、受信側２０２は、応答メッセージで応答する。ステップ２１３の応答メッセージは、ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ、ｒｅｊｅｃｔｅｄＳｅｒｖｉｃｅＴｏ、およびｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏを含み得る。ステップ２１４では、発信側２０１は、ＣＲＥＡＴＥ応答メッセージの受信時、その＜ＣＳＥＢａｓｅ＞リソースの下にローカルで＜ｒｅｍｏｔｅＣＳＥ＞リソースを作成する。このリソースは、受信側２０２（ホスティングＣＳＥ）を表している。発信側２０１は、ｇｒａｎｔｅｄＳｅｒｖｉｃｅＴｏ、ｐｅｎｄｉｎｇＳｅｒｖｉｃｅＴｏを処理し、それに応じて、本明細書（例えば、図８）で議論されるようなアクションをとる。ステップ２１５では、発信側２０１は、ｐｅｎｄｉｎｇＳｅｒｖｉｃｅのａｌｌｏｗｅｄＷａｉｔＴｉｍｅ属性を更新するために、受信側２０２に向けた（ＣＲＥＡＴＥ要求メッセージのためと同一のＴｏ）ＵＰＤＡＴＥ要求を発行し得る。ステップ２１６では、受信側２０２は、対応するｐｅｎｄｉｎｇＳｅｒｖｉｃｅのａｌｌｏｗｅｄＷａｉｔＴｉｍｅ属性を更新する。ステップ２１７では、受信側２０２は、発信側２０１に利用可能なｐｅｎｄｉｎｇＳｅｒｖｉｃｅを見出し、それに応じて、ｐｅｎｄｉｎｇＳｅｒｖｉｃｅステータスを更新する。ステップ２１８では、受信側２０２は、発信側２０１に向けたＮＯＴＩＦＹ要求を発行し、サービスのステータス変更を通知する。ステップ２１９では、発信側２０１は、通知を処理し、ｇｒａｎｔｅｄＳｅｒｖｉｃｅリソースを更新する。

図２０は、本明細書の方法、デバイス、およびシステムに使用され得る、例示的グラフィカルユーザインターフェースを図示する。ユーザインターフェースは、登録メッセージ３２１に含まれるであろうサービス、またはメッセージ３２２等のレジストラエンティティ２０５からの付与されたサービス、レジストラエンティティ２０５からの拒否されたサービス、もしくはレジストラエンティティ２０５からの保留中サービス等の登録に関連する情報を表示して構成するように、（例えば、ＡＥまたはＣＳＥの形態で）レジストリエンティティ２０４としてユーザ端末に追加されることができる。ユーザインターフェースはまた、とりわけ、レジストラエンティティに登録される全てのレジストリエンティティ、各レジストリエンティティへの付与されたサービス、各レジストリエンティティへの拒否されたサービス、または各レジストリエンティティへの保留中サービス等のレジストリエンティティに関連する情報を表示するように、（例えば、ＣＳＥの形態で）レジストラエンティティ２０５に追加されることもできる。レジストラエンティティ２０５では、要求されたサービスの許可を付与し、登録を容認するかどうかを決定し得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とりわけ、本明細書に説明されるような方法、システム、および装置は、本明細書で議論されるような柔軟なサービス層登録のための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、デバイスの第１のアプリケーションによって、サービス層の第１のサービスに対する登録要求を備えている第１のメッセージを第１のレジストラエンティティに送信する手段と、第１のメッセージに応答する第２のメッセージであって、第１のアプリケーションのために第１のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第１のリストを備えている、第２のメッセージを受信する手段と、第２のメッセージに応答して、付与される１つ以上のサービスの１つ以上の識別子の第１のリストのための第１のレジストラエンティティへの登録を確認する第３のメッセージを送信する手段と、第１のアプリケーションによって、サービス層の第２のサービスに対する登録要求を備えている第４のメッセージを第２のレジストラエンティティに送信する手段と、第４のメッセージに応答する第５のメッセージであって、第１のアプリケーションのために第２のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第２のリストを備えている、第５のメッセージを受信する手段と、第５のメッセージに応答して、付与される１つ以上のサービスの１つ以上の識別子の第２のリストのための第２のレジストラエンティティへの登録を確認する第６のメッセージを送信する手段とを有し、第１のアプリケーションは、第１のレジストラエンティティおよび第２のレジストラエンティティに同時に登録される。第２のメッセージは、有効時間を備え得、有効時間は、第１のサービスの有効な期間を示す。第２のメッセージは、最大使用量を備え得、最大使用量は、第１のアプリケーションのための第１のサービスの使用の最大数を示す。第２のメッセージは、相互関係を備え得、相互関係は、第１のサービスが双方向であるか、一方向であるかを示す。第２のメッセージは、推奨レジストラをさらに備え、推奨レジストラは、第１のレジストラエンティティが拒否された第３のサービスのために推奨する第３のレジストラエンティティを示し、第３のサービスは、第１のメッセージの中で要求される。第２のメッセージは、許容待ち時間を備え得、許容待ち時間は、デバイスが、保留中のサービスが付与されることを自発的に待つ時間を示す。第２のメッセージは、優先順位をさらに備え、優先順位は、デバイスの優先度を示す。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第２のメッセージに基づいてディスプレイ上にグラフィックを表示する手段を有する。グラフィックは、有効時間、最大使用量、相互関係、または推奨レジストラに関連付けられているテキストを備え得る。（ステップの除去または追加を含む）本段落内の全ての組み合わせは、発明を実施するための形態の他の部分と一致する様式で考慮される。

Claims (19)

1. サービス層登録のためのデバイスであって、前記デバイスは、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   前記デバイスの第１のアプリケーションによって、第１のメッセージを第１のレジストラエンティティに送信することであって、前記第１のメッセージは、サービス層の第１のサービスに対する登録要求を備えている、ことと、
   前記第１のメッセージに応答する第２のメッセージを受信することであって、前記第２のメッセージは、前記第１のアプリケーションのために前記第１のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第１のリストを備えている、ことと、
   前記第１のアプリケーションによって、第４のメッセージを第２のレジストラエンティティに送信することであって、前記第４のメッセージは、前記サービス層の第２のサービスに対する登録要求を備えている、ことと、
   前記第４のメッセージに応答する第５のメッセージを受信することであって、前記第５のメッセージは、前記第１のアプリケーションのために前記第２のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第２のリストを備えている、ことと
   を含む動作を前記プロセッサに達成させ、
   前記第１のアプリケーションは、前記第１のレジストラエンティティと前記第２のレジストラエンティティとに同時に登録されている、デバイス。
2. 前記第２のメッセージは、有効時間をさらに備え、前記有効時間は、前記第１のサービスの有効な期間を示す、請求項１に記載のデバイス。
3. 前記第２のメッセージは、最大使用量をさらに備え、前記最大使用量は、前記第１のアプリケーションのための前記第１のサービスの使用の最大数を示す、請求項１に記載のデバイス。
4. 前記第２のメッセージは、相互関係をさらに備え、前記相互関係は、前記第１のサービスが双方向であるか、一方向であるかを示す、請求項１に記載のデバイス。
5. 前記第２のメッセージは、推奨レジストラをさらに備え、前記推奨レジストラは、前記第１のレジストラエンティティが拒否された第３のサービスのために推奨する第３のレジストラエンティティを示し、前記第３のサービスは、前記第１のメッセージの中で要求されている、請求項１に記載のデバイス。
6. 前記第２のメッセージは、許容待ち時間をさらに備え、前記許容待ち時間は、保留中サービスが付与されることを前記デバイスが自発的に待つ時間を示す、請求項１に記載のデバイス。
7. 前記第２のメッセージは、優先順位をさらに備え、前記優先順位は、前記デバイスの優先度を示す、請求項１に記載のデバイス。
8. サービス層登録のための方法であって、前記方法は、
   デバイスの第１のアプリケーションによって、第１のメッセージを第１のレジストラエンティティに送信することであって、前記第１のメッセージは、サービス層の第１のサービスに対する登録要求を備えている、ことと、
   前記第１のメッセージに応答する第２のメッセージを受信することであって、前記第２のメッセージは、前記第１のアプリケーションのために前記第１のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第１のリストを備えている、ことと、
   前記第１のアプリケーションによって、第４のメッセージを第２のレジストラエンティティに送信することであって、前記第４のメッセージは、前記サービス層の第２のサービスに対する登録要求を備えている、ことと、
   前記第４のメッセージに応答する第５のメッセージを受信することであって、前記第５のメッセージは、前記第１のアプリケーションのために前記第２のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第２のリストを備えている、ことと
   を含み、
   前記第１のアプリケーションは、前記第１のレジストラエンティティと前記第２のレジストラエンティティとに同時に登録されている、方法。
9. 前記第２のメッセージは、有効時間をさらに備え、前記有効時間は、前記第１のサービスの有効な期間を示す、請求項８に記載の方法。
10. 前記第２のメッセージは、最大使用量をさらに備え、前記最大使用量は、前記第１のアプリケーションのための前記第１のサービスの使用の最大数を示す、請求項８に記載の方法。
11. 前記第２のメッセージは、相互関係をさらに備え、前記相互関係は、前記第１のサービスが双方向であるか、一方向であるかを示す、請求項８に記載の方法。
12. 前記第２のメッセージは、推奨レジストラをさらに備え、前記推奨レジストラは、前記第１のレジストラエンティティが拒否された第３のサービスのために推奨する第３のレジストラエンティティを示し、前記第３のサービスは、前記第１のメッセージの中で要求されている、請求項８に記載の方法。
13. 前記第２のメッセージは、許容待ち時間をさらに備え、前記許容待ち時間は、保留中サービスが付与されることを前記デバイスが自発的に待つ時間を示す、請求項８に記載の方法。
14. 前記第２のメッセージは、優先順位をさらに備え、前記優先順位は、前記デバイスの優先度を示す、請求項８に記載の方法。
15. サービス層登録のためのシステムであって、前記システムは、
    第１のレジストリエンティティと、第１のレジストラエンティティと、第２のレジストラエンティティとを備え、
    第１のアプリケーションによって、第１のメッセージを前記第１のレジストリエンティティから前記第１のレジストラエンティティに送信することであって、前記第１のメッセージは、サービス層の第１のサービスに対する登録要求を備えている、ことと、
    前記第１のメッセージに応答する第２のメッセージを前記第１のレジストリエンティティで受信することであって、前記第２のメッセージは、前記第１のアプリケーションのために前記第１のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第１のリストを備えている、ことと、
    前記第１のアプリケーションによって、第４のメッセージを前記第１のレジストリエンティティから第２のレジストラエンティティに送信することであって、前記第４のメッセージは、前記サービス層の第２のサービスに対する登録要求を備えている、ことと、
    前記第４のメッセージに応答する第５のメッセージを受信することであって、前記第５のメッセージは、前記第１のアプリケーションのために前記第２のレジストラエンティティによって付与される１つ以上のサービスの１つ以上の識別子の第２のリストを備えており、
    前記第１のアプリケーションは、前記第１のレジストラエンティティと前記第２のレジストラエンティティとに同時に登録されている、ことと
    を含む、システム。
16. 前記第２のメッセージは、有効時間をさらに備え、前記有効時間は、前記第１のサービスの有効な期間を示す、請求項１５に記載のシステム。
17. 前記第２のメッセージは、最大使用量をさらに備え、前記最大使用量は、前記第１のアプリケーションのための前記第１のサービスの使用の最大数を示す、請求項１５に記載のシステム。
18. 前記第２のメッセージは、相互関係をさらに備え、前記相互関係は、前記第１のサービスが双方向であるか、一方向であるかを示す、請求項１５に記載のシステム。
19. 前記第２のメッセージは、推奨レジストラをさらに備え、前記推奨レジストラは、前記第１のレジストラエンティティが拒否された第３のサービスのために推奨する第３のレジストラエンティティを示し、前記第３のサービスは、前記第１のメッセージの中で要求されている、請求項１５に記載のシステム。