JP6126998B2 - 発見されたサービスプロバイダに属するサービスにアクセスする方法および装置 - Google Patents

Description

本発明は無線通信に関する。

本願は、２０１１年３月３日に出願された米国仮特許出願第６１／４４８９２４号、および２０１１年５月１３日に出願された米国仮特許出願第６１／４８５７１１号の優先権を主張し、参照によりその内容が本明細書に組み込まれる。

マシンツーマシン（Ｍ２Ｍ）通信サービスをサポートするエンドツーエンドシステムアーキテクチャが現在、欧州電気通信標準化機構（ＥＴＳＩ）によって定義されており、Ｍ２Ｍサービスプロバイダが、有線または無線Ｍ２Ｍ加入者通信ユニット（ＳＣＵ）、ゲートウェイおよびサーバ上に配置されたＭ２Ｍサービス能力レイヤ（service capability layer）を介してＭ２Ｍサービスをアプリケーションに配信することを可能にする。Ｍ２Ｍサービスがアプリケーションに対して利用可能となり得る前に、Ｍ２Ｍ ＳＣＵおよびゲートウェイは、少なくとも１つのＭ２Ｍサーバをブートストラップ（bootstrap）し、および当該サーバに登録して、Ｍ２Ｍネットワークを形成することができる。典型的な配置シナリオでは、Ｍ２ＭサーバはＭ２Ｍサービスプロバイダによって所有されてもよく、または当該プロバイダに属してもよい。したがって、Ｍ２Ｍ ＳＣＵもしくはゲートウェイは、Ｍ２Ｍサービスプロバイダへの加入をプロビジョニングされてもよく、またはＭ２Ｍサービスプロバイダが発見されて、Ｍ２Ｍサービスプロバイダへの加入を確立してもよい。Ｍ２Ｍサービスプロバイダ加入者は、Ｍ２Ｍサーバをブートストラップし、および当該サーバに登録する前に、Ｍ２Ｍ ＳＣＵまたはゲートウェイが適切なセキュリティ証明を取得することを可能にしてもよい。

Ｍ２Ｍネットワークが形成されると、次いでアプリケーションは、Ｍ２Ｍ ＳＣＵ、Ｍ２Ｍゲートウェイ、およびＭ２Ｍサーバ上に常駐する利用可能なＭ２Ｍ ＳＣＬを発見し、ならびにＭ２Ｍ ＳＣＬに登録して、対応するサービスにアクセスすることができる。Ｍ２Ｍサービスプロバイダ発見プロシージャ、ブートストラッププロシージャ、およびＳＣＬ発見プロシージャを提供することなく、オフラインプロビジョニングなどの機構が使用されて、ブートストラップおよび発見情報を構成することができ、ならびにＭ２Ｍ ＳＣＵ、ゲートウェイ、アプリケーション、およびＭ２Ｍサーバに配信することができる。しかし、そのような機構は、配置および管理コストを著しく増加させることがあり、ならびに、Ｍ２Ｍネットワークのスケーラビリティを制限することがある。オフラインプロビジョニングの代替として、自動化された発見は、利用可能なＭ２Ｍサービスプロバイダおよび対応するＭ２Ｍ ＳＣＬが動的に発見されることを可能にすることができる。その結果、管理コストを削減することができ、および配置プロセスを自動化することができる（例えば、ヒューマンインタラクションがほとんど、または、全くないことがあるＭ２Ｍ ＳＣＵに対して）。

サービスプロバイダに属する（affiliated with）サービスにアクセスする方法および装置を説明する。第１の発見プロシージャが実行されて、少なくとも１つのサービスプロバイダが発見されてもよく、および少なくとも１つの発見されたサービスプロバイダとともにブートストラッププロシージャが実行されてもよい。次いで、第２の発見プロシージャが実行されて、少なくとも１つのサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定してもよい。

第１の発見プロシージャは、レコードデータベースにクエリするための情報を含むサービスプロバイダ発見要求を送信して、一致するサービスプロバイダ発見レコードを判定すること、およびサービスプロバイダ発見要求におけるクエリに一致するサービス発見機能レコードリストを含むサービスプロバイダ発見応答を受信することを含んでもよい。サービス発見機能レコードリストから、ブートストラップするための少なくとも１つのサービスプロバイダが選択されてもよい。

ブートストラッププロシージャは、選択されたサービスプロバイダに要求を送信すること、およびサービスプロバイダの少なくとも１つのＳＣＬとともにブートストラッピングを開始するためにノードにより必要とされる情報を含む応答を、選択されたサービスプロバイダから受信することを含んでもよい。情報はセキュリティ証明を含んでもよい。

第２の発見プロシージャは、発行側（例えば、Ｍ２Ｍ加入者通信ユニット（ＳＣＵ）、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサーバ上に常駐するアプリケーションまたはＳＣＬ）が、レコードデータベースにクエリするための情報を含むサービス発見要求を送信して、一致するＳＣＬ発見レコードを判定すること、および発行側が、サービス発見要求におけるクエリに一致するサービス発見機能レコードリストを含むサービス発見応答を受信することを含んでもよい。発行側は、サービス発見機能レコードリストから、ブートストラップするための少なくとも１つのＳＣＬを選択してもよい。

第２の発見プロシージャは、ドメインネームシステムベースサービス発見（ＤＮＳ−ＳＤ）マシンツーマシン（Ｍ２Ｍ）サービス発見機能（ＭＳＤＦ）サーバにＳＣＬ発見レコードをプロビジョニングすること、ＤＮＳ−ＳＤ ＭＳＤＦサーバをパブリックＤＮＳ登録会社またはエンティティに登録して、パブリックＤＮＳ−ＳＤ ＭＳＤＦサービス発見ドメインを確立すること、ＤＮＳ−ＳＤ ＭＳＤＦサーバが発行側からＤＮＳ−ＳＤクエリを受信すること、およびＤＮＳ−ＳＤクエリに応答して、ＤＮＳ−ＳＤ ＭＳＤＦサーバが発行側にＳＣＬ発見レコードを送信することを含んでもよい。

第２の発見プロシージャは、発行側からＳＣＬ発見要求を受信すること、および発行側にＳＣＬ発見結果を提供するサービス発見応答を送信することを含んでもよい。ＳＣＬ発見要求は、ｓｃｌＢａｓｅ属性を使用するクエリ文字列を含んでもよい。ＳＣＬ発見応答は、クエリ文字列と一致するＳＣＬと、ＳＣＬの各々についてのｓｃｌＢａｓｅに対する絶対ユニフォームリソース識別子（ＵＲＩ）とのリストを含んでもよい。

第２の発見プロシージャは、ＤＮＳサーバのネットワークアドレスを発行側にプロビジョニングし、もしくは当該ネットワークアドレスにより発行側を構成すること、利用可能なＳＣＬを有するホストに対する少なくとも１つの完全修飾ドメイン名（ＦＱＤＮ）を発行側にプロビジョニングし、もしくは当該ＦＱＤＮにより発行側を構成すること、発行側が、ネットワークアドレスおよびＦＱＤＮを使用して、配置されたＤＮＳサーバにＤＮＳルックアップ要求を送信すること、ならびに発行側が、対応するＳＣＬホストについての解決されたネットワークアドレスを受信することを含んでもよい。

第２の発見プロシージャは、動的ホスト構成プロトコル（ＤＨＣＰ）サーバのネットワークアドレスを発行側にプロビジョニングし、または当該ネットワークアドレスにより発行側を構成すること、発行側が、配置されたＤＨＣＰサーバにＤＨＣＰ要求を送信すること、および発行側が、ＳＣＬのアドレスおよび追加のＳＣＬ情報を含む応答を受信することを含んでもよい。

配置されたドメインネームシステム（ＤＮＳ）サーバのネットワークアドレスを発行側にプロビジョニングし、もしくは、当該ネットワークアドレスにより発行側を構成することによって、利用可能なＳＣＬを有するホストについての少なくとも１つの完全修飾ドメイン名（ＦＱＤＮ）を発行側にプロビジョニングし、もしくは、当該ＦＱＤＮにより発行側を構成することによって、発行側が、ネットワークアドレスおよびＦＱＤＮを使用して、配置されたＤＮＳサーバにＤＮＳルックアップ要求を送信することによって、ならびに発行側が、対応するＳＣＬホストについての解決されたネットワークアドレスを受信することによって、サービスプロバイダに属するサービスがアクセスされてもよい。発行側は無線送信／受信ユニット（ＷＴＲＵ）であってもよい。

第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見し、少なくとも１つの発見されたサービスプロバイダとともにブートストラッププロシージャを実行し、次いで第２の発見プロシージャを実行して、少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なＳＣＬを判定するように装置が構成されてもよい。装置はＷＴＲＵ、ゲートウェイ、またはサーバであってもよい。

第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見し、少なくとも１つの発見されたサービスプロバイダとともにブートストラッププロシージャを実行し、次いで第２の発見プロシージャを実行して、少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なＳＣＬを判定するように構成されたアプリケーションを格納するように、コンピュータ可読記憶媒体が構成されてもよい。

添付の図面と共に例として与えられる以下の説明から、より詳細な理解を得ることができる。
１つまたは複数の開示される実施形態を実装することができる例示的な通信システムを示す。 図１Ａに示す通信システム内で使用することができる例示的な加入者通信ユニット（ＳＣＵ）を示す。 マシンツーマシン（Ｍ２Ｍ）サービスプロバイダ発見プロシージャを示す。 Ｍ２Ｍサービスプロバイダブートストラッププロシージャを示す。 Ｍ２Ｍサービス発見機能（ＭＳＤＦ）階層アーキテクチャの例を示す。 統合されたＭＳＤＦ／ドメインネームシステム（ＤＮＳ）サーバ階層アーキテクチャの例を示す。 ＭＳＤＦサービス能力レイヤ（ＳＣＬ）発見プロシージャを示す。 ＭＳＤＦ ＤＮＳベースのサービス発見（ＤＮＳ−ＳＤ）ＳＣＬ発見を介してサポートすることができるサービスサブタイプのタイプの例を示す。 ＭＳＤＦ ＤＮＳ−ＳＤ ＳＣＬ発見プロシージャを示す。 ｓｃｌＤｉｓｃｏｖｅｒｙリソースを含むＭ２Ｍサービス発見リソース構造を示す。 Ｍ２Ｍ既知リソースＳＣＬ発見プロシージャを示す。 ＤＮＳベースのＭ２Ｍ ＳＣＬ発見プロシージャを示す。 ＤＨＣＰベースのＭ２Ｍ ＳＣＬ発見プロシージャを示す。

図１Ａに示すように、通信システム１００は、有線または無線加入者通信ユニット（ＳＣＵ）１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、他のネットワーク１１２、ならびにゲートウェイ１４０を含んでもよいが、記載の実施形態では、任意の数の加入者通信ユニット、基地局、ネットワーク、および／またはネットワーク要素が企図されることを理解されよう。ＣＮ１０６はサーバ１５０を含んでもよい。ＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの各々は、有線または無線環境において動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、有線または無線信号を送信および／または受信するように構成されてもよく、ならびに、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ノートブック、パーソナルコンピュータ、タブレットコンピュータ、無線センサおよび家庭用電化製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａおよび１１４ｂの各々は、ＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうちの少なくとも１つとインターフェースをとり、ＣＮ１０６、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａおよび１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、ＮｏｄｅＢ、発展型ＮｏｄｅＢ（ｅＮＢ）、ホームＮｏｄｅＢ（ＨＮＢ）、ホームｅＮＢ（ＨｅＮＢ）、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａおよび１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａおよび１１４ｂは任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことを理解されよう。

基地局１１４ａはＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、および中継ノードなどの他の基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよい。セルはさらにセルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタに対して１つを含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用してもよく、したがって、セルの各セクタに対して複数の送受信機を利用してもよい。

図１Ａにおける基地局１１４ｂは、例えば無線ルータ、ＨＮＢ、ＨｅＮＢ、またはＡＰであってもよく、ならびにビジネス、家庭、車両、およびキャンパスの場所などの局所化されたエリアにおいて無線接続性を容易にするための任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂならびにＳＣＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂならびにＳＣＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｂならびにＳＣＵ１０２ｃおよび１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ（登録商標）、ＣＤＭＡ２０００、ＧＳＭ（登録商標）、ＬＴＥ、およびＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスする必要がないことがある。

ＲＡＮ１０４は、ＣＮ１０６と通信していてもよく、ＣＮ１０６は、ＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうちの１つまたは複数に、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを提供するように構成された任意のタイプのネットワークであってもよい。例えば、ＣＮ１０６は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイドコーリング、インターネット接続性、およびビデオ配信などを提供してもよく、ならびに／またはユーザ認証などの高レベルセキュリティ機能を実行してもよい。図１Ａでは図示されていないが、ＲＡＮ１０４および／またはＣＮ１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接的または間接的に通信していてもよいことを理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用していてもよいＲＡＮ１０４に接続されていることに加えて、ＣＮ１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信していてもよい。

ＣＮ１０６はまた、ＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしてサービスしてもよい。ＰＳＴＮ１０８は、簡易電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、伝送制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）スイートにおけるＴＣＰ、ユーザデータグラムプロトコル（ＵＤＰ）、およびＩＰなどの共通通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、１つまたは複数のＲＡＮに接続された別のＣＮを含んでもよく、当該ＲＡＮは、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用してもよい。

通信システム１００におけるＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの一部またはすべてはマルチモード機能を含んでもよく、すなわちＳＣＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、異なる有線または無線リンク上で異なる有線または無線ネットワークと通信する複数の送受信機を含んでもよい。例えば、図１Ａに示されるＳＣＵ１０２ｃは、セルラベースの無線技術を利用することができる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を利用することができる基地局１１４ｂと通信するように構成されてもよい。あるいは、ＳＣＵ１０２のうちの１つまたは複数は、複数のサブフローを提供するために有線イーサネット（登録商標）接続に加えてブロードバンド無線接続を有するラップトップであってもよい。

図１Ｂは、図１Ａに示される通信システム１００内で使用されてもよい例示的なＳＣＵ１０２を示す。図１Ｂに示されるように、ＳＣＵ１０２は、プロセッサ１１８、送受信機１２０、有線または無線インターフェース１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および周辺機器１３８を含んでもよい。ＳＣＵ１０２は、実施形態に適合したままで上記の要素の任意の部分組合せを含んでもよいことを理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、マイクロプロセッサ、およびＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＳＣＵ１０２が有線または無線環境において動作することを可能にする任意の他の機能を実行してもよい。プロセッサ１１８は送受信機１２０に結合されてもよく、送受信機１２０はインターフェース１２２に結合されてもよい。図１Ｂはプロセッサ１１８および送受信機１２０を別々の構成要素として示すが、プロセッサ１１８および送受信機１２０は電子パッケージまたはチップにおいて共に統合されてもよい。

インターフェース１２２は、エアインターフェース１１６上で基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、インターフェース１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、インターフェース１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態では、インターフェース１２２は、ＲＦ信号および光信号の両方を送信および受信するように構成されてもよい。インターフェース１２２は、有線または無線信号の任意の組合せを送信および／または受信するように構成されてもよい。

ＳＣＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、ならびにそれらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスしてもよく、ならびに当該メモリにデータを格納してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。別の実施形態では、プロセッサ１１８は、サーバやホームコンピュータ（図示せず）上などの、ＳＣＵ１０２上に物理的に配置されないメモリからの情報にアクセスしてもよく、および当該メモリにデータを格納してもよい。

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

以下では、用語「発行側」は、Ｍ２Ｍ加入者通信ユニット（ＳＣＵ）、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサーバ上に常駐するアプリケーションまたはＳＣＬを指してもよい。

ドメインネームシステム（ＤＮＳ）は、インターネットまたはプライベートネットワークに接続されたコンピュータ、サービス、または任意のリソースについての分散データベース上に構築される階層型ネーミングシステムである。ＤＮＳは、インターネットプロトコル（ＩＰ）アドレスを、参加エンティティの各々に割り当てられたドメイン名に関連付けてもよい。最も重要なことであるが、それは、世界的にこれらのデバイスを位置づけ、および、アドレッシングする目的で、ドメイン名をネットワーキング機器に関連付けられた数的識別子に変換する。

ＤＮＳベースサービス発見（ＤＮＳ−ＳＤ）は、標準ＤＮＳプログラミングインターフェース、サーバ、パケットフォーマットを使用して、ネットワークサービスの発見をサポートする。標準ＤＮＳクエリを使用して、クライアントは、標準ＤＮＳクエリを使用して所望のサービスの名前付きインスタンスのリストを発見してもよい。このことは、クライアントが探しているサービスのタイプと、クライアントがそのサービスを探しているドメインとに基づいて実施されてもよい。

動的ホスト構成プロトコル（ＤＨＣＰ）は、１つまたは複数のＤＨＣＰサーバからネットワークデバイスへのネットワークパラメータ割当てを自動化する。ＤＨＣＰにより構成されたクライアントがネットワークに接続するとき、ＤＨＣＰクライアントは、ＤＨＣＰサーバからの必要な情報を要求してもよい。

Ｍ２Ｍ ＳＣＵ、Ｍ２Ｍゲートウェイ、または別のＭ２Ｍサーバが、特定のＭ２Ｍサーバをブートストラップし、および、当該サーバに登録することができる前に、Ｍ２Ｍ ＳＣＵまたはＭ２Ｍゲートウェイが、Ｍ２Ｍサーバに属するＭ２Ｍサービスプロバイダとの関係を確立して、そのＭ２Ｍサーバをブートストラップおよび認証するのに必要とされる、必須のセキュリティ証明を取得することが重要である。Ｍ２Ｍ ＳＣＵまたはＭ２ＭゲートウェイがＭ２Ｍサービスプロバイダとの関係を確立し、セキュリティ証明を取得して、Ｍ２Ｍサーバをブートストラップし、および当該サーバに登録することを可能するいくつかの方法が存在する。非自動化オフラインプロビジョニングは、Ｍ２Ｍ ＳＣＵ、ゲートウェイ、およびサーバの間のＭ２Ｍサービスプロバイダ関係（例えば、加入）を確立すること、ならびに必要なセキュリティ証明をオフラインプロビジョニング方式において配信することに依拠する。このオフラインプロビジョニングアプローチは実行可能であるが、それに関連付けられた制限および欠点が存在する。例えば、オフラインプロビジョニングは、初期配置中、ならびに再構成または再配置のために人間の介入を必要とすることが多いので、コストがかかることがある。

Ｍ２Ｍサービス発見は、Ｍ２Ｍ ＳＣＵ、ゲートウェイ、およびサーバ上に位置するＭ２Ｍサービス能力レイヤ（ＳＣＬ）の発見と同様であることがある。ＳＣＬがアプリケーションまたは他のＳＣＬのいずれかによってアクセスされ得る前に、適切なアドレッシングに対するユニフォームリソース識別子（ＵＲＩ）を有することが重要である。加えて、ＳＣＬによってサポートされるＭ２Ｍサービスのタイプなどの属性の知識がまた有益となることがあり、それは、この情報が、アプリケーションおよびＳＣＬがどのＳＣＬに登録することを望むかを判定するために、この情報がアプリケーションおよびＳＣＬにより使用されることがあるからである。

一実施形態では、Ｍ２Ｍサービスプロバイダ発見プロシージャは、Ｍ２Ｍサービス発見機能（ＭＳＤＦ）のネットワークアドレスが、オフラインプロビジョニングされ、あるいは発見されると仮定する。例えば、ＭＳＤＦがＤＮＳ−ＳＤサーバ内で実現される場合、ＭＳＤＦネットワークアドレスはＤＮＳ−ＳＤアドレスと同等であってもよく、ＤＮＳ−ＳＤアドレスは通常、ネットワークサービスプロバイダによって構成され、および利用可能にされる。

図２は、Ｍ２Ｍサービスプロバイダ２０５、レコードデータベース２１５を有するＭＳＤＦ２１０、および発行側を含むネットワークにおいて実行されるＭ２Ｍサービスプロバイダ発見プロシージャ２００を示す。図２に示すように、Ｍ２Ｍサービスプロバイダ２０５は、ＭＳＤＦ２１０に要求２２５を送信して、Ｍ２Ｍサービスプロバイダ発見レコードを作成してもよく、Ｍ２Ｍサービスプロバイダ発見レコードはレコードデータベース２１５に格納されてもよい。要求２２５は、ＭＳＤＦレコードタイプ（例えば、Ｍ２Ｍサービスプロバイダ発見）、Ｍ２Ｍサービスプロバイダのブートストラップ機能への絶対的なＵＲＩ、加入に対してＭ２Ｍサービスプロバイダが必要とする情報のタイプ（例えば、識別またはアドレスのタイプ）、Ｍ２ＭサービスプロバイダによってサポートされるＭ２Ｍサービスのクラス（例えば、モビリティ、スケジューリング遅延、サポートされるデータレート、持続性、および優先順位レベルなど）、Ｍ２Ｍサービスプロバイダと通信するのに使用されるプロトコルのタイプ（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）／伝送制御プロトコル（ＴＣＰ）、ｃｏｎｓｔｒａｉｎｅｄ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）／ユーザデータグラムプロトコル（ＵＤＰ）など）、Ｍ２ＭサービスプロバイダによってサポートされるＭ２Ｍサービス識別子のタイプ（例えば、ビルディングオートメーション、ｅヘルス、家庭用電化製品、およびユーティリティなど）、Ｍ２ＭサービスプロバイダによってサポートされるＭ２ＭアプリケーションまたはＳＣＵのタイプ（例えば、サーモスタット、心臓モニタ、およびカメラなど）、ならびにセカンダリＭ２Ｍサービスプロバイダ（例えば、特定のユーティリティ会社、および特定のセキュリティ会社など）などの、発見レコードを作成するのに使用される様々なタイプの情報を含んでもよい。

図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００に示すように、ＭＳＤＦ２１０は、Ｍ２Ｍサービスプロバイダ発見レコード（すなわち、ＭＳＤＦレコード）が成功して作成されたか否かを示す応答２３０を、Ｍ２Ｍサービスプロバイダ２０５に送信してもよい。発行側２２０は、ＭＳＤＦ２１０にサービスプロバイダ発見要求２３５を送信することにより、利用可能なＭ２Ｍサービスプロバイダを発見してもよい。サービスプロバイダ発見要求２３５は、ＭＳＤＦ２１０のレコードデータベース２１５にクエリし、ならびにＭＳＤＦレコードタイプ（例えば、Ｍ２Ｍサービスプロバイダ発見）、ＭＳＤＦ２１０がそのレコードデータベース２１５を探索し、およびその応答をフィルタリングするのに使用することができる任意のクエリ文字列などの、一致するＭ２Ｍサービスプロバイダ発見レコードを判定するためにＭＳＤＦ２１０によって使用される様々なタイプの情報を含んでもよい。例えば、クエリ文字列は、特定のＭ２Ｍサービスプロバイダ、発行側２２０が探しているＭ２Ｍサービスのタイプもしくはクラス、または発行側２２０がサポートするプロトコルのタイプを指定してもよい。

サービスプロバイダ発見要求２３５に応答して、ＭＳＤＦ２１０は、発見要求２３５におけるクエリに一致するＭＳＤＦレコードリストを含むサービスプロバイダ発見応答２４０を送信してもよい。発行側２２０は、応答２４０におけるＭＳＤＦレコードリストから、ブートストラップ／登録する１つまたは複数のＭ２Ｍサービスプロバイダを選択してもよい（２４５）。

図３は、Ｍ２Ｍ ＳＣＵ、ゲートウェイ、およびアプリケーションが、Ｍ２ＭサービスプロバイダにブートストラップするＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を示す。ＳＣＵ／ゲートウェイ／アプリケーションが、Ｍ２Ｍサービスプロバイダのブートストラップ機能のアドレスをオフラインプロビジョニングされており、またはＳＣＵ／ゲートウェイ／アプリケーションが図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００中にそれを発見していると仮定する。

Ｍ２Ｍサービスプロバイダブートストラッピングが適切である一般的な例は、Ｍ２Ｍ ＳＣＵ／ゲートウェイ／アプリケーションが、Ｍ２Ｍサービスプロバイダとの加入を有さず、および、Ｍ２Ｍサービスプロバイダ発見を使用して、１つまたは複数の利用可能なサービスプロバイダを判定することである。さらに、Ｍ２Ｍ ＳＣＵ／ゲートウェイ／アプリケーションは、既存のＭ２Ｍサービスプロバイダ加入から別のＭ２Ｍサービスプロバイダ加入に変更してもよく、または追加のサービスに対して別のＭ２Ｍサービスプロバイダに加入してもよい。例えば、既存のＭ２Ｍサービスプロバイダは、ＳＣＵ／ゲートウェイが求めるサービスを提供しないことがある。

Ｍ２Ｍサービスプロバイダのブートストラップ機能は、Ｍ２ＭサービスプロバイダとともにＭ２Ｍ ＳＣＵ、ゲートウェイ、およびアプリケーションのブートストラッピングを容易にすることができる。ブートストラップ機能の重要な機能は、Ｍ２Ｍ ＳＣＵ／ゲートウェイ／アプリケーション、ならびにＭ２Ｍサービスプロバイダの管理機能（例えば、Ｍ２Ｍ認証サーバ（ＭＡＳ））およびＭ２Ｍサービスブートストラップ機能（ＭＳＢＦ）へのＭ２Ｍセキュリティ証明の配布である。次いで、これらのセキュリティ証明が、Ｍ２Ｍ機能アーキテクチャにしたがって後続のＭ２Ｍサービスブートストラッププロシージャ中に使用される。Ｍ２Ｍサービスプロバイダに応じて、そのブートストラップ機能のオフラインプロビジョニングが必要であることがある（例えば、それによってブートストラップすることが承認された各ＳＣＵのメディアアクセス制御（ＭＡＣ）アドレスなどのグローバルに一意かつ永続的な識別子によって）。

Ｍ２Ｍサービスプロバイダブートストラッププロシージャ３００に示されるように、Ｍ２Ｍサービスプロバイダ３０５は、発行側３２５のセキュリティ証明によるそのブートストラップ機能３１０のオフラインプロビジョニングを必要とすることがある（３２０）。次いで、発行側３２５は、選択されたＭ２Ｍサービスプロバイダ３０５のブートストラップ機能３１０に要求３３０を送信することにより、その選択のＭ２Ｍサービスプロバイダに対するブートストラッピングを開始してもよい。要求３３０は、グローバル一意識別子などの、ブートストラップ機能３１０にとって必要な加入者情報を含んでもよい。ブートストラップ機能３１０は、サービスプロバイダ３０５の任意のＳＣＬとのブートストラッピングを開始するのに発行側３２５によって必要とされるセキュリティ証明とともに、応答３３５を発行側３２５に送信してもよい。ブートストラップ機能３１０は、Ｍ２Ｍサービスプロバイダ３０５のＳＣＬのサブセットのみへのアクセスを許可してもよく、および、この情報はまた、応答３３５に含まれてもよい。

ブートストラップ機能３１０から発行側３２５へのセキュリティ証明の転送を、セキュアウェブインターフェースなどのセキュア転送環境を通じて行うことが必要なことがある。ブートストラップ機能３１０はまた、必要なセキュリティ証明を認証サーバ３１５およびサービスプロバイダ３０５のＭＳＢＦ（図示せず）に提供してもよい（３４０）（例えば、セキュアウェブインターフェースなどのセキュア転送環境を通じて）。発行側３２５は、ＳＣＬ発見を実行して、Ｍ２Ｍサービスプロバイダによってサポートされる利用可能なＳＣＬを判定し、および、ＳＣＬブートストラップ／登録プロシージャを実行してもよい（３４５）。

別の実施形態では、Ｍ２Ｍ ＳＣＵ／ゲートウェイは、Ｍ２Ｍサービスプロバイダとの関係を確立してもよく、および、ＳＣＬ発見を使用して、そのサービスプロバイダによって提供される利用可能なＳＣＬを判定してもよい。別の実施形態では、Ｍ２Ｍ ＳＣＵ／ゲートウェイは、Ｍ２Ｍサービスプロバイダとの関係を有さなくてもよく、ならびに、ＳＣＬ発見を使用して、それが必要とするＳＣＬのタイプを判定してもよく、そしてＭ２Ｍサービスプロバイダは、それらのＳＣＬを提供してもよい。さらに別の実施形態では、Ｍ２Ｍ ＳＣＵ／ゲートウェイは、新しいＭ２Ｍサービスプロバイダに切り替わってもよく（例えば、再配置される）、および、新しいサービスプロバイダによってサポートされるＳＣＬを発見する必要があることがある。さらに別の実施形態では、Ｍ２Ｍ ＳＣＵ／ゲートウェイは、それが登録される（例えば、再構成される）既存のＳＣＬによって現在提供されているのとは異なるサービスまたは追加のサービスを必要とすることがある。さらに別の実施形態では、アプリケーション（例えば、Ｍ２Ｍサービス可能デバイスアプリケーション（ＤＡ）、ゲートウェイアプリケーション（ＧＡ）、ネットワークアプリケーション（ＮＡ）、または非Ｍ２Ｍサービス可能デバイスアプリケーション（ＤＡ））が、そのローカルＳＣＬを発見する必要があることがある。さらに別の実施形態では、Ｍ２Ｍサーバが、他のＭ２Ｍサーバ、ゲートウェイ、およびデバイスによってサポートされるサービスを発見する必要があることがある。

ＭＳＤＦ ＳＣＬ発見が使用されて、ＳＣＬのホストのネットワークアドレスが既知でないときのＳＣＬを判定してもよい。例えば、Ｍ２Ｍ ＳＣＵ／ゲートウェイは、特定のタイプのＳＣＬを必要とすることがあるが、そのタイプのＳＣＬをホスティングするＭ２Ｍサーバのネットワークアドレスを知らないことがある。Ｍ２Ｍ ＳＣＵ／ゲートウェイは、そのタイプのＳＣＬを提供するＭ２Ｍサーバのネットワークアドレスを発見するために、ＭＳＤＦの支援を求めてもよい。

図４は、ＭＳＤＦ階層アーキテクチャ４００の一例を示す。ＭＳＤＦは、Ｍ２Ｍサービスプロバイダ（＃１および＃２）およびＭ２Ｍ ＳＣＬの自動発見を容易にすることができる。ＭＳＤＦは、Ｍ２Ｍ ＳＣＵ、ゲートウェイ、アプリケーション、およびＭ２Ｍサーバによってアクセスすることができる階層的に分散したデータベースであってもよい。図４に示すように、ＭＳＤＦ階層アーキテクチャ４００は、ただ１つの中央に位置するＭＳＤＦを有さなくてもよく、むしろ、複数のＭＳＤＦ（＃１、＃２、および＃３）を有してもよい。ＭＳＤＦ階層アーキテクチャ４００の分散されたアーキテクチャおよび非集中型のアーキテクチャは、それがスケーリングし、ならびに、Ｍ２Ｍサーバ、ゲートウェイ、およびＳＣＵ上で実装される多数のＭ２ＭサービスプロバイダおよびＳＣＬをサポートすることを可能にしてもよい。同様に、ＭＳＤＦ階層アーキテクチャ４００の所有権はまた、ドメインに分散され、および、セグメント化されて、Ｍ２Ｍサービスプロバイダに対する管理およびアクセス制御を可能にし、および、各ドメイン所有者（例えば、Ｍ２Ｍサービスプロバイダ）によってＳＣＬを制御することを可能にしてもよい。

図４に示すＭＳＤＦ階層アーキテクチャ４００の分散された性質および階層的な性質は、ドメインネームシステム（ＤＮＳ）およびＤＮＳ−サービス発見（ＤＮＳ−ＳＤ）などの既存のネーミングおよびサービス発見システムとともにそれが統合され、ならびに、相互接続ネットワークにすることを可能にしてもよい。図５は、Ｍ２ＭサービスプロバイダがそのサービスをＤＮＳインフラストラクチャに登録および広告し、ならびに、そのＭ２ＭサービスをそれぞれのローカルＭ２Ｍサービスプロバイダドメインの外部の他者にとって発見可能にすることを可能にする、統合されたＭＳＤＦ／ＤＮＳサーバ階層アーキテクチャ５００の一例を示す。

ＭＳＤＦデータベースは、複数のＭＳＤＦレコードを格納してもよく、および、ＭＳＤＦは、複数のレコードタイプをサポートしてもよい。例えば、Ｍ２ＭサービスプロバイダまたはＭ２Ｍ ＳＣＬレコードなどのレコードタイプが作成されてもよい。異なるレコードタイプをサポートすることは、必要な場合に、ＭＳＤＦが、異なるＭ２Ｍサービス発見レコードフォーマットを有することを可能にする。ＭＳＤＦがサポートする各レコードフォーマットについて、ＳＣＬホストアドレス、およびＳＣＬサービスクラスなどの情報を収容するためにレコード属性が定義されてもよい。

ＭＳＤＦは、ＭＳＤＦレコードの作成、更新、削除、または読出しをサポートしてもよい。加えて、ＭＳＤＦはまた、ＭＳＤＦレコード属性に基づいてＭＳＤＦレコードを見出すためのクエリをサポートしてもよい。例えば、ＭＳＤＦは、それぞれのドメインにおける特定のレコード属性、例えば「ｎｏ」に等しい「ｍｏｂｉｌｉｔｙ」と命名されたレコード属性、を有するタイプＭ２Ｍ ＳＣＬのすべてのＭＳＤＦレコードについてクエリされてもよい。それに応答して、ＭＳＤＦは、「ｎｏ」に等しい「ｍｏｂｉｌｉｔｙ」属性を備えるタイプＭ２Ｍ ＳＣＬのＭＳＤＦレコードのリストを返してもよい（いずれかが読み出される場合）。

ＭＳＤＦ ＳＣＬ発見プロシージャは、オフラインプロビジョニングされ、あるいは発見されることがある、ＭＳＤＦのネットワークアドレスの認識に依拠してもよい。通常、このことは、最も近いＭＳＤＦのアドレスでよい（例えば、ローカルドメインにおけるＭＳＤＦ）。例えば、ＭＳＤＦがＤＮＳ−ＳＤサーバ内で実現される場合、ＭＳＤＦネットワークアドレスは、ローカルＤＮＳ−ＳＤサーバアドレスと同等であってもよく、ローカルＤＮＳ−ＳＤサーバアドレスは、下層のネットワークサービスプロバイダまたはドメイン管理者によって構成されてもよく、および、利用可能とされてもよい。

図６は、Ｍ２Ｍサービスプロバイダ（またはホスティングＳＣＬ）６０５、ＭＳＤＦ６１０、および発行側６１５を含むネットワークにおけるＭＳＤＦ ＳＣＬ発見プロシージャ６００を示す。Ｍ２Ｍサービスプロバイダ（またはホスティングＳＣＬ）６０５は、他者に対してＳＣＬを、ＭＳＤＦルックアップを介して発見可能にするために、ＭＳＤＦ６１０に要求６２０を発行して、ＳＣＬ発見レコードを作成してもよい。ＳＣＬ発見レコードは、ＭＳＤＦレコードタイプ（例えば、Ｍ２Ｍ ＳＣＬ発見）、ＳＣＬを所有するＭ２Ｍサービスプロバイダ、ＳＣＬのｓｃｌＢａｓｅに対する絶対ＵＲＩ、他のネットワークエンティティのアドレスおよび属性（例えば、デバイス管理サーバ、およびブートストラップサーバなどのアドレスおよびサポートされるプロトコル）、ＳＣＬによってサポートされるＭ２Ｍサービス能力のタイプ、ＳＣＬによってサポートされるＭ２Ｍサービスのクラス（例えば、モビリティ、スケジューリング遅延、サポートされるデータ転送速度、永続性、および優先順位レベルなど）、ＳＣＬと通信するのに使用されるプロトコルのタイプ（例えば、ＨＴＴＰ／ＴＣＰ、ＣｏＡＰ／ＵＤＰなど）、ＳＣＬによってサポートされるＭ２Ｍサービス識別子のタイプ（例えば、ビルディングオートメーション、ｅヘルス、家庭用電化製品、およびユーティリティなど）、ならびに、ＳＣＬによってサポートされるＭ２ＭアプリケーションまたはＳＣＵのタイプ（例えば、サーモスタット、心臓モニタ、カメラなど）などの様々なタイプの属性によって構成されてもよい。

ＳＣＬ発見レコード作成要求６２０に応答して、ＭＳＤＦ６１０は、ＳＣＬ発見レコードが成功して作成されたか否かを示す応答６２５を、Ｍ２Ｍサービスプロバイダ（またはホスティングＳＣＬ）６０５に送信してもよい。発行側６１５は、ＭＳＤＦ６１０にサービス発見要求６３０を送信することにより、ＳＣＬを発見してもよい。あるいは、利用可能なサービスはＭＳＤＦ６１０によって広告されてもよい。サービス発見要求６３０は、ＭＳＤＦレコードタイプ（例えば、Ｍ２Ｍ ＳＣＬ発見）、ＭＳＤＦ６１０がそのレコードデータベースを探索するのに使用する任意のクエリ文字列、およびＭＳＤＦ６１０が提供するフィルタ応答を含んでもよい。例えば、クエリ文字列は、特定のＭ２Ｍサービスプロバイダ、発行側６１５が探しているＭ２Ｍサービスのタイプもしくはクラス、または発行側６１５がサポートするプロトコルのタイプを指定してもよい。

サービス発見要求６３０に応答して、ＭＳＤＦ６１０は、サービス発見要求６３０におけるクエリに一致するＭＳＤＦレコードリストを含むサービス発見応答６３５を、発行側６１５に送信してもよい。クエリが複数の一致するレコードをもたらす場合、ＭＳＤＦ６１０は、その応答でどのレコードを返すかを判定する追加の能力を、サービス発見応答６３５に含んでもよい。例えば、ＭＳＤＦ６１０は、各タイプのいくつのレコードが応答で返されるかを追跡することにより、同一のタイプのＳＣＬにわたって要求を負荷分散してもよい。発行側６１５は、サービス発見応答６３５で受信したＭＳＤＦレコードリストからブートストラップ／登録する１つまたは複数のＳＣＬを選択してもよい（６４０）。発行側６１５は、適切なセキュリティ証明を事前に取得した場合、ＳＣＬブートストラップ／登録プロシージャを実行してもよい（６４５）。そうでない場合、発行側６１５が最初に適切な証明を取得することが必要となることがある（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

ＭＳＤＦ ＳＣＬ発見プロシージャ６００は、ＤＮＳ−ＳＤプロトコルにバインドされてもよい。このバインディングは、ＭＳＤＦ ＤＮＳ−ＳＤサービスタイプを定義し、ｄｎｓ−ｓｄ．ｏｒｇ（http://www.dns-sd.org/ServiceTypes.html）に登録することによって開始する。例えば、「Ｍ２Ｍ」と命名されたサービスが定義され、および、適切に登録されてもよい。追加のＭＳＤＦ ＤＮＳ−ＳＤサービスサブタイプが定義されてもよい。図７は、ＭＳＤＦ ＤＮＳ−ＳＤ ＳＣＬ発見を介してサポートされてもよいサービスサブタイプのタイプの例を示す。

各ＳＣＬサービスタイプインスタンスに対して、および、任意で各ＳＣＬサービスサブタイプインスタンスに対して、ターゲットとされるＤＮＳサーバ上でＤＮＳ−ＳＤポインタ（ＰＴＲ）レコードが作成されてもよい。ＤＮＳ−ＳＤは、ＤＮＳ ＰＴＲルックアップを使用して、所与のサービスタイプの利用可能なインスタンスのリストを発見してもよい。ＤＮＳ ＰＴＲルックアップに対する応答は、一致するインスタンス名のリストである。

ＳＣＬサービスタイプインスタンスに対するＤＮＳ−ＳＤ ＰＴＲレコードは、フォーマット：service.proto.domain PTR instance.service.proto.domain、を有してもよい。ＳＣＬサービスサブタイプインスタンスに対するＤＮＳ−ＳＤ ＰＴＲレコードは、フォーマット：sub-service.service.proto.domain PTR instance.sub-service.service.proto.domainを有する。ＤＮＳ−ＳＤポインタレコードにおけるサブサービスは、その後にサブサービス名（例えば、＿ｈｄｒ）が続くアンダースコア文字であってもよい。ＤＮＳ−ＳＤポインタレコードにおけるサービスは、その後にアプリケーションプロトコル名（例えば、＿ｍ２ｍ）が続くアンダースコア文字であってもよい。ＤＮＳ−ＳＤポインタレコードにおけるｐｒｏｔｏは、アンダースコア、ならびに、「＿ｔｃｐ」（ＴＣＰ上で動作するアプリケーションプロトコルに対して）または「＿ｕｄｐ」（他のすべてに対して）のいずれかであってもよい。ＤＮＳ−ＳＤポインタレコードにおけるｄｏｍａｉｎは、サービス名がその中で登録されるＤＮＳサブドメインを指定してもよい。それは、「リンクローカルドメイン」を意味する「ｌｏｃａｌ．」であってもよく、または非ローカルＤＮＳドメイン名（例えば「ｃｏｍ」）であってもよい。ＤＮＳ−ＳＤポインタレコードにおけるＰＴＲは、ＤＮＳ ＰＴＲレコードにおいて使用されるＤＮＳキーワードであってもよい。ＤＮＳ−ＳＤポインタレコードにおけるインスタンスは、サービスインスタンスに割り当てられるユーザフレンドリな名前であってもよい（例えば、「ｐｅｃｏ」と命名されたユーティリティプロバイダなどの、Ｍ２Ｍサービスプロバイダの名前）。

タイプ「ｍ２ｍ」およびインスタンス名「ｐｅｃｏ」のＳＣＬサービスインスタンスに対する例示的なＰＴＲレコードは、_m2m._tcp.example.com.PTR peco._ m2m._tcp.comであってもよい。

インスタンス名「ｐｅｃｏ」を有するサブタイプ「ユーティリティ」およびタイプ「ｍ２ｍ」のＳＣＬサービスインスタンスに対する例示的なＰＴＲレコードは、_utility._ m2m._tcp.example.com.PTR peco._ m2m._tcp.comであってもよい。

各ＳＣＬサービスタイプインスタンスに対して、および任意で各サービスサブタイプインスタンスに対して、ターゲットとされるＤＮＳサーバ上でＤＮＳ−ＳＤサービス（ＳＲＶ）レコードが作成されてもよい。ＤＮＳ−ＳＤは、ＤＮＳ ＳＲＶレコードを使用して、サービスインスタンスが達することができるターゲットホスト名、またはアドレスおよびポートを定義してもよい。

ＳＣＬサービスタイプインスタンスに対するＳＲＶレコードは、フォーマット：_service._proto.domain time-to-live (TTL) class SRV priority weight port targetを有してもよい。

ＳＣＬサービスサブタイプインスタンスに対するＳＲＶレコードは、フォーマット：sub_service._service._proto. domain TTL class SRV priority weight port targetを有してもよい。このＳＲＶレコードでは、サブサービス（ｓｕｂ＿ｓｅｒｖｉｃｅ）は、所望のサブサービスのシンボリック名であってもよく、サービス（ｓｅｒｖｉｃｅ）は、所望のサービスのシンボリック名であってもよく、ｐｒｏｔｏは、所望のサービスの、通常はＴＣＰまたはＵＤＰのいずれかであるトランスポートプロトコルであってもよく、ドメイン（ｄｏｍａｉｎ）は、このレコードが有効であるドメイン名であってもよく、ＴＴＬは、標準ＤＮＳ存続時間フィールドであってもよく、クラス（ｃｌａｓｓ）は、標準ＤＮＳクラスフィールドであってもよく（これは常にインターネット（ＩＮ）である）、プライオリティ（ｐｒｉｏｒｉｔｙ）は、より低い値がより好ましい、ターゲットホストの優先順位であってもよく、重み（ｗｅｉｇｈｔ）は、同じ優先順位を有するレコードに対する相対的重みであってもよく、ポート（ｐｏｒｔ）は、サービスが発見されることになるＴＣＰまたはＵＤＰポートであってもよく、ならびに、ターゲット（ｔａｒｇｅｔ）は、サービスを提供するマシンのカノニカル（canonical）ホスト名であってもよい。

タイプ「ｍ２ｍ」およびインスタンス名「ｐｅｃｏ」のＳＣＬサービスインスタンスに対する例示的なＳＲＶレコードは、_m2m._tcp.example.com.86400 IN SRV 0 5 5060 peco.m2m.example.comであってもよい。

インスタンス名「ｐｅｃｏ」を有するサブタイプ「ユーティリティ（ｕｔｉｌｉｔｙ）」およびタイプ「ｍ２ｍ」のＳＣＬサービスインスタンスに対する例示的なＳＲＶレコードは、_utility._m2m._tcp.example.com.86400 IN SRV 0 5 5060 peco.m2m.example.comであってもよい。

ＭＳＤＦ ＤＮＳ−ＳＤテキスト（ＴＸＴ）レコードは、各ＳＣＬサービスおよびサブサービスインスタンスに対する、ターゲットとされるＤＮＳサーバ上で作成されてもよい。ＤＮＳ−ＳＤは、ＤＮＳ ＴＸＴレコードを使用して、命名されたサービスについての追加の情報を搬送する任意の名前／値の対を格納してもよい。各名前／値の対は、ＤＮＳ ＴＸＴレコード内の自身の構成文字列として、「名前＝値」という形式で符号化されてもよい。最初の「＝」文字までのすべては名前である。最初の「＝」文字の後から文字列の終わりまでのすべて（存在する場合、後続の「＝」文字を含む）は、値である。ＳＣＬ発見の観点からは、ＤＮＳ−ＳＤ ＴＸＴレコードが使用されて、ＳＣＬへのＵＲＩパス、ＳＣＬによってサポートされる様々なタイプの特徴、プロトコルなどの有用なＳＣＬ属性情報を格納してもよい。

例えば、ＤＮＳ−ＳＤ ＴＸＴレコードが使用されて、ＳＣＬ ＵＲＩパス部分（すなわち、ＳＲＶレコードによって提供されるＩＰアドレスまたはポートではない）scl=<uri_path_to_sclBase>を提供してもよい。

ＤＮＳ ＰＴＲおよびＳＲＶレコードを使用するのではなく、ＤＮＳ−ＳＤ ＴＸＴレコードが使用されて、ＳＣＬによってサポートされるサービスサブタイプ（図７に示すものなど）を定義してもよい。例えば、ＤＮＳ−ＳＤ ＴＸＴレコードは、utility=true、sclhttp=true、およびrates=trueなどのＳＣＬサービスサブタイプ名前／値の対を含んでもよい。

図８は、発行側８０５およびローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０を含むネットワークにおけるタイプ「ｍ２ｍ」およびサブタイプ「ユーティリティ（ｕｔｉｌｉｔｙ）」のサービスインスタンスを発見するためのＭＳＤＦ ＤＮＳ−ＳＤ ＳＣＬ発見プロシージャ８００を示す。図８を参照すると、発行側８０５は、登録されたＤＮＳ−ＳＤ Ｍ２Ｍサービスタイプ名のオフラインプロビジョニングを実行して、ＤＮＳ−ＳＤルックアップで使用してもよい（８１５）。ローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０は、ＳＣＬ発見レコードをオフラインでプロビジョニングされてもよい（８２０）。

各Ｍ２Ｍサービスプロバイダは、それ自体で所有および管理のいずれかをし、または、別のパーティに対して管理をサブコントラクト（sub-contract）するローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０において、ＳＣＬ発見レコード（例えば、ＤＮＳ−ＳＤ ＰＴＲ、ＳＲＶ、およびＴＸＴレコード）を作成してもよい。これらのＳＣＬ発見レコードは、個々のＳＣＬ（すなわち、ｓｃｌＢａｓｅ）の絶対アドレス（すなわち、ＵＲＩ）、および、ＳＣＬによってサポートされるサービスのタイプ／クラスなどの属性を含んでもよい。各Ｍ２Ｍ ＳＣＵ、ゲートウェイ、またはサーバは、ＤＮＳ−ＳＤ ＰＴＲレコードルックアップのために使用され、登録され、または標準化されたＤＮＳ−ＳＤ Ｍ２Ｍサービスタイプ名をプロビジョニングされてもよい。

ローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０は、パブリックＤＮＳ登録会社もしくはエンティティにオフラインで登録されて、パブリックＤＮＳ−ＳＤ ＭＳＤＦサービス発見ドメインを確立してもよい（８２５）。パブリックＤＮＳ登録会社もしくはエンティティは、この情報を公に利用可能にしてもよい。他のＤＮＳ−ＳＤ ＭＳＤＦサーバは、その階層レベル下で確立されている任意の新たなサービス発見サブドメインを発見してもよい。このことは、Ｍ２ＭサービスプロバイダのＤＮＳ−ＳＤ ＭＳＤＦサーバが発見され、および、既存のＤＮＳ−ＳＤ ＭＳＤＦサーバの階層に相互接続されることをもたらす。プライベートＤＮＳ−ＳＤ ＭＳＤＦ配置が好ましい場合、ステップ８２５はスキップされてもよい。

発行側８０５のＤＮＳ−ＳＤ ＭＳＤＦクライアントは、その割り当てられたローカルＤＮＳ−ＳＤ ＭＳＤＦサーバのアドレスを発見してもよく、当該アドレスにより構成されてもよく、または当該アドレスをプロビジョニングされてもよい（８３０）。下層のアクセスネットワーク技術に応じて、このプロセスが自動化されてもよく、またはマニュアルオフライン構成を必要としてもよい。発行側８０５は、「_utility._m2m._tcp.com」に対するＤＮＳ−ＳＤ ＰＴＲクエリ８４０をそのローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０に送信することにより、Ｍ２Ｍ ＳＣＬ発見プロシージャ８３５を開始してもよい。割り当てられたローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０は、対応するＳＣＬのＭ２Ｍ ＳＣＬインスタンス名をそれぞれ含む、利用可能なＤＮＳ−ＳＤ ＰＴＲレコードのリストを含むＤＮＳ−ＳＤ応答８４５によって、発行側８０５に応答してもよい。発行側８０５は、対応するＳＣＬネットワークアドレスおよび考えられる追加の発見情報を取得するために、解決を望む１つまたは複数のＰＴＲレコードを選択してもよい（例えば、peco._m2m._tcp.com）（８５０）。発行側８０５は、解決したい各ＳＣＬインスタンス名に対して、ローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０に１つまたは複数のＤＮＳ−ＳＤクエリ要求８５５を送信してもよい。各ＳＣＬインスタンス名に対して別々の要求が必要とされることがあることに留意されたい。

ローカルＤＮＳ−ＳＤ ＭＳＤＦサーバ８１０は、それぞれの対応するＤＮＳ−ＳＤクエリ要求８５５に対して、ＳＲＶおよびＴＸＴレコードとともに応答８６０を送信してもよい。ＳＲＶレコードは、ネットワーク名またはＳＣＬのアドレス（例えば、完全修飾ドメイン名（ＦＱＤＮ）またはＩＰアドレス、およびポート）を含んでもよい。ＴＸＴレコードは、ｓｃｌＢａｓｅへのＵＲＩパス、ＳＣＬによってサポートされるサービス、プロトコルなどのタイプまたはクラスなどの任意の情報を含んでもよい。ＦＱＤＮがＩＰアドレスではなくＳＲＶレコードにおいて返される場合、ＩＰアドレスへのＦＱＤＮを解決するのに追加のＤＮＳルックアップが必要とされることがある。発行側８０５は、ブートストラップするＳＣＬを選択してもよい（例えば、ＴＸＴレコードからの情報を利用して、最も適しているＳＣＬを発見する）（８６５）。

リソースＳＣＬ発見プロシージャは、ＭＳＤＦとのいかなる対話も必要としないので、ＭＳＤＦベースのプロシージャと比べて軽量のプロシージャとして特徴付けられてもよい。この軽量ＳＣＬ発見プロシージャは、特に、Ｍ２Ｍゲートウェイの後ろに常駐するリソースが制限された（例えば、非Ｍ２Ｍサービス可能な）ＳＣＵに適していてもよいが、潜在的には他のシナリオでも使用されてもよい。ＳＣＬ発見プロシージャ中にターゲットされることになるホストのネットワークアドレスは、あらかじめ知られてもよい。

図９は、ＳＣＬの自動発見を容易にするのに使用される既知のリソースである、ｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５を含むＭ２Ｍサービス発見リソース構造９００を示す。それが使用されて、ＳＣＬ発見要求に含まれるＳＣＬ発見クエリ基準に一致するＳＣＬに対するＵＲＩのリストを検索してもよい。ｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５は、本明細書に記載のＭＳＤＦ手法に比べて、より軽量かつ自動化された方法でホスティングＭ２Ｍサーバ、ゲートウェイ、またはデバイス上でＳＣＬの発見をサポートしてもよい。この軽量ＳＣＬ発見プロシージャは、Ｍ２Ｍゲートウェイの後ろに常駐するリソースが制約された非Ｍ２Ｍサービス可能デバイスに特に適していてもよいが、他のシナリオでも使用されてもよい。ＳＣＬ発見プロシージャ中にターゲットされることになるホストのネットワークアドレスは、あらかじめ知られてもよい。

例えば、非Ｍ２Ｍサービス可能デバイスは、それを発見することが可能な、対応するＭ２ＭゲートウェイのＩＰアドレスを知ってもよい。Ｍ２Ｍゲートウェイの後ろにある非Ｍ２Ｍサービス可能デバイスに対して、Ｍ２Ｍゲートウェイはこうしたタイプのネットワークに対する調整ネットワークノードであるので、Ｍ２Ｍゲートウェイのネットワークアドレスの情報が知られてもよく、その結果、非Ｍ２Ｍサービス可能デバイスは、下位レイヤネットワーク初期化および関連付けプロシージャの間にゲートウェイのネットワークアドレスを発見してもよい。

図９のＭ２Ｍサービス発見リソース構造９００におけるｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５は、Ｍ２Ｍ ｓｃｌＢａｓｅリソースツリー構造９１０の上のレベルを実装する既知のリソースであってもよい。ｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５は、Ｍ２Ｍサーバ、ゲートウェイ、またはデバイスによってホスティングされる各ｓｃｌＢａｓｅリソースに対して、絶対ＵＲＩを維持してもよい。既知のｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５の背後にある理論的根拠は、ＳＣＬを「ＲＥＳＴｆｕｌ」方式で発見することが（ＲＥＳＴｆｕｌは、再現的状態遷移（ＲＥＳＴ）制約に従うことを指す）ＳＣＬの＜ｓｃｌＢａｓｅ＞リソースの発見と同一視してもよいことである。Ｍ２Ｍサーバ、ゲートウェイ、またはデバイス上で既知のｓｃｌＤｉｓｃｏｖｅｒｙリソース９０５を維持することにより、ホスティングされるＳＣＬの発見が、自動化されることが必要とされることが多く、および、人間の対話に依拠しないことがあるＭ２Ｍユースケースに良く適している、レストフルかつ自動化された方式で実行されてもよい。

ｓｃｌＤｉｓｃｏｖｅｒｙリソースは、作成・読取・更新・削除（ＣＲＵＤ：create retrieve update and destroy）要求、ならびにｓｃｌＢａｓｅ属性を含むようなフィルタ基準をサポートしてもよい。複数のＳＣＬが同一のＭ２Ｍサーバ、ゲートウェイ、またはデバイス上でローカルに実装されてもよいことに留意することは重要である。したがって、ｓｃｌＤｉｓｃｏｖｅｒｙ応答は、ＳＣＬ発見読取要求で指定されるフィルタ基準に一致する絶対ｓｃｌＢａｓｅＵＲＩのリストを含んでもよい。

フィルタ基準を含むＳＣＬ発見要求の一例は、「Retrieve coap://m2m.myoperator.org:<well_known_m2m_port>/discovery?attrib1=val1&attrib2=val2...」であってもよい。

既知のポートの使用はさらに、ＳＣＬ発見の自動化を可能にしてもよい。既知のｓｃｌＤｉｓｃｏｖｅｒｙリソースとともに既知のポートを定義することにより、ＳＣＬ発見を実行するのに必要とされる唯一の残りの情報は、ターゲットとされるＭ２Ｍサーバ、ゲートウェイ、またはデバイスのネットワークアドレス（例えば、ＩＰアドレス）であってもよい。

図１０は、Ｍ２Ｍの既知のリソースＳＣＬ発見プロシージャ１０００を示す。各Ｍ２Ｍサーバ、ゲートウェイ、およびデバイスは、それ自体のｓｃｌＤｉｓｃｏｖｅｒｙ既知リソース１００５を維持する。それらの責務は、各ホスティングされるｓｃｌＢａｓｅリソースへの絶対ＵＲＩを維持すること、およびクエリ文字列とともにｓｃｌＤｉｓｃｏｖｅｒｙ既知リソースにＣＲＵＤ要求をサービスすることを含んでもよい。発行側１０１０は、ターゲットとされるＭ２Ｍサーバ、ゲートウェイ、またはデバイスｓｃｌＤｉｓｃｏｖｅｒｙ既知リソース１００５にＳＣＬ発見要求１０１５を送信してもよい。サービス発見要求は、ａｃｃｅｓｓＲｉｇｈｔＩＤ、ｓｅａｒｃｈＳｔｒｉｎｇｓ、ｃｒｅａｔｉｏｎＴｉｍｅ、ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ、Ｐｏｃｓ、およびｓｃｈｅｃｕｌｅなどのｓｃｌＢａｓｅ属性を利用するクエリ文字列、ならびに、ＳＣＬを所有するＭ２Ｍサービスプロバイダ、ＳＣＬのｓｃｌＢａｓｅに対する絶対ＵＲＩ、ＳＣＬによってサポートされるＭ２Ｍサービスのクラス（例えば、モビリティ、スケジューリング遅延、サポートされるデータ転送速度、永続性、優先順位レベルなど）、ＳＣＬと通信するのに使用されるプロトコルのタイプ（例えば、ＨＴＴＰ／ＴＣＰ、ＣｏＡＰ／ＵＤＰなど）、ＳＣＬによってサポートされるＭ２Ｍサービス識別子のタイプ（例えば、ビルディングオートメーション、ｅヘルス、コンシューマエレクトロニクス、ユーティリティなど）、ＳＣＬによってサポートされるＭ２ＭアプリケーションまたはＳＣＵのタイプ（例えば、サーモスタット、心臓モニタ、カメラなど）、およびセカンダリＭ２Ｍサービスプロバイダ（例えば、特定のユーティリティ会社、特定のセキュリティ会社など）などの、ＳＣＬ発見をサポートするための新たなｓｃｌＢａｓｅ属性に対する提案を備える。

図１０に示すように、Ｍ２Ｍサーバ、ゲートウェイ、またはデバイスｓｃｌＤｉｓｃｏｖｅｒｙ既知リソース１００５は、ＳＣＬ発見結果を発行側１０１０に提供するサービス発見応答１０２０を送信してもよい。応答１０２０は、ＳＣＬ発見要求１０１５におけるクエリ文字列と一致するＳＣＬのリストを含んでもよい。さらに、応答１０２０はまた、各ＳＣＬに対するｓｃｌＢａｓｅへの絶対ＵＲＩを含んでもよい。次いで発行側１０１０は、応答１０２０におけるＳＣＬリストから、ブートストラップまたは登録する１つまたは複数のＳＣＬを選択してもよい（１０２５）。発行側１０１０は、適切なセキュリティ証明を事前に取得した場合、ＳＣＬブートストラップ／登録プロシージャを実行してもよい（１０３０）。あるいは、発行側１０１０が最初に適切な証明を取得する必要があることがある（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

ＳＣＬのホストのドメイン名が既知であるが、ネットワークアドレスが既知ではないとき、ＤＮＳ ＳＣＬ発見が使用されて、Ｍ２Ｍ ＳＣＬを発見してもよい。そのような場合、Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバは、対応するドメイン名を有するホストのネットワークアドレスを発見するために、ＤＮＳサーバの支援を求めてもよい。ホストのネットワークアドレスが既知となると、図１０の既知のリソースＳＣＬ発見プロシージャ１０００などの機構が使用されて、ホスト上に常駐するＳＣＬの絶対ＵＲＩを発見してもよい。

図１１は、ＤＮＳベースのＭ２Ｍ ＳＣＬ発見プロシージャ１１００を示す。ＤＮＳベースのＭ２Ｍ ＳＣＬ発見プロシージャ１１００は、オフラインプロビジョニングされ、および／またはアクセスネットワークブートストラッピング、ＤＨＣＰ、デバイス管理構成、もしくは何らかの他の類似の方法などのプロシージャを介して、あらかじめ発見されることがある、ＤＮＳサーバのネットワークアドレスの認識に依拠してもよい。

Ｍ２Ｍサービスプロバイダ１１０５は、そのＳＣＬホスト（例えば、ＳＣＬをホスティングするＭ２Ｍサーバ）の各々のドメイン名を登録して、それらを公にしてもよい。プライベートＤＮＳ配置が望ましい場合、ステップ１１１０はスキップされてもよい。Ｍ２Ｍサービスプロバイダ１１０５は、ＤＮＳサーバ１１１５を配置してもよく、および、ＳＣＬをホスティングするそのＭ２Ｍサーバのうちの１つまたは複数のそれぞれに対して、ＤＮＳサーバ１１１５上にＤＮＳレコードをインストールしてもよい（１１２０）。

Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１１２５は、配置されたＤＮＳサーバ１１１５のネットワークアドレスをプロビジョニングされてもよく、または、ＤＮＳサーバ１１１５のネットワークアドレスによって動的に構成されてもよい（例えば、アクセスネットワークブートストラッピング、ＤＨＣＰ、デバイス管理構成、または何らかの他の類似の方法などのプロシージャを介して）（１１３０）。Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１１２５は、利用可能なＳＣＬを有するホストに対する１つもしくは複数の完全修飾ドメイン名（ＦＱＤＮ）をプロビジョニングされてもよく、または、アクセスネットワークブートストラッピング、ＤＨＣＰ、デバイス管理構成、もしくは何らかの他の類似の方法などのプロシージャを介したこの情報によって動的に構成されてもよい（１１３５）。

Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１１２５は、そのプロビジョニング／構成されたＦＱＤＮ、および配置されたＤＮＳサーバ１１１５のネットワークアドレスを使用して、配置されたＤＮＳサーバ１１１５にＤＮＳルックアップ要求１１４０を送信することによってＳＣＬを発見してもよい。配置されたＤＮＳサーバ１１１５は、対応するＳＣＬホストに対する解決されたネットワークアドレスとともに応答１１４５を送信してもよい。

解決されたネットワークアドレスのフォーマットに応じて、追加の発見ステップが必要とされることがある。解決されたネットワークアドレスが、ＳＣＬのホストのＩＰアドレスであり、ホスト上に位置するＳＣＬへの完全ＵＲＩパスではない場合、追加の発見が必要となることがある（例えば、ＳＣＬホストのＩＰアドレスを使用して、図１０のＭ２Ｍ既知ＳＣＬリソース発見プロシージャ１０００が使用されて完全なＵＲＩを発見してもよい）。Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１１２５が既に適切なセキュリティ証明を有する場合、それらはＳＣＬブートストラップ／登録プロシージャを実行してもよい。あるいは、Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１１２５は、最初に適切な証明を取得してもよい（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

図１２は、ＤＨＣＰベースのＭ２Ｍ ＳＣＬ発見プロシージャ１２００を示す。ＤＨＣＰベースのＭ２Ｍ ＳＣＬ発見プロシージャ１２００が使用されて、ＤＨＣＰサーバへの要求を介してＭ２Ｍ ＳＣＬを発見してもよい。そのような場合、Ｍ２Ｍデバイス／ゲートウェイは、ＤＨＣＰサーバへの要求を行って、ＤＨＣＰサーバに事前にプログラムされている１つまたは複数の利用可能なＭ２Ｍ ＳＣＬのアドレスを発見してもよい（例えば、ＤＨＣＰサーバ管理者によって）。ＤＨＣＰサーバがまた使用されて、ＳＣＬのアドレス以外の追加のＳＣＬ情報を提供してもよい（例えば、ＳＣＬによってサポートされるＭ２Ｍサービス能力のタイプなど）。

ＤＨＣＰベースのＭ２Ｍ ＳＣＬ発見プロシージャ１２００は、オフラインプロビジョニングされ、および／またはブロードキャスティング、アクセスネットワークブートストラッピング、デバイス管理構成、もしくは何らかの他の類似の方法などのプロシージャを介してあらかじめ発見されることがある、ＤＨＣＰサーバのネットワークアドレスの認識に依拠してもよい。

Ｍ２Ｍサービスプロバイダ１２０５は、そのＳＣＬの各々のアドレス（例えば、ＳＣＬのＵＲＩ）、またはそのＳＣＬホストの各々のアドレス（例えば、ＳＣＬをホスティングするＭ２ＭサーバのＩＰアドレス）によってＤＨＣＰサーバ１２１０を構成してもよい（１２１５）。Ｍ２Ｍサービスプロバイダ１２０５は、ＤＨＣＰサーバ１２１０を配置して、他者がアクセスするのに利用可能にしてもよい（１２２０）。

Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１２２５は、ＤＨＣＰサーバ１２１０のネットワークアドレスをプロビジョニングされてもよく、ＤＨＣＰサーバ１２１０のネットワークアドレスを動的に発見してもよく（例えば、ブロードキャスティングを介して）、または、アクセスネットワークブートストラッピング、デバイス管理構成、もしくは何らかの他の類似の方法などのプロシージャを通じてＤＨＣＰサーバ１２１０のアドレスによって動的に構成されてもよい（１２３０）。Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１２２５は、ＤＨＣＰサーバ１２１０にＤＨＣＰ要求１２３５を送信することによってＳＣＬを発見してもよい。異なるＤＨＣＰ要求１２３５が活用されてもよいことに留意されたい（例えば、ＤＨＣＰ通知タイプ要求が使用されてもよい）。

ＤＨＣＰサーバ１２１０は、ＳＣＬのアドレス（例えば、ＳＣＬの絶対ＵＲＩ、またはＳＣＬのホストのＩＰアドレス）、およびＳＣＬのアドレス以外の追加のＳＣＬ情報（例えば、ＳＣＬによってサポートされるＭ２Ｍサービス能力のタイプ）とともに応答１２４０を送信してもよい。

返されるＳＣＬアドレスのフォーマットに応じて、追加の発見ステップが必要となることがある。返されるＳＣＬアドレスが、ＳＣＬのホストのＩＰアドレスであり、ホスト上に位置するＳＣＬへの完全ＵＲＩパスではない場合、追加の発見が必要とされることがある（例えば、ＳＣＬホストのＩＰアドレスを使用して、図１０のＭ２Ｍ既知リソースＳＣＬ発見プロシージャ１０００が使用されて完全なＵＲＩを発見してもよい）。Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１２２５が既に適切なセキュリティ証明を有する場合、それはＳＣＬブートストラップ／登録プロシージャを実行してもよい。あるいは、Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバ１２２５は、最初に適切な証明を取得してもよい（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

下層のアクセスネットワークブートストラップ／登録プロシージャが使用されて、Ｍ２Ｍ ＳＣＬを割り当ててもよい。そのような場合、アクセスネットワークブートストラップ／登録プロシージャの間に、割り当てられたＳＣＬによってＭ２Ｍデバイス／ゲートウェイ／サーバが構成されてもよい。アクセスネットワークブートストラッピングおよび登録が完了するまでＭ２Ｍサービス登録が実行されないので、この手法は、アクセスネットワークブートストラップ／登録時にＳＣＬ構成情報が利用可能である場合に実行可能であってもよい。

アクセスネットワークブートストラップ／登録ベースのＭ２Ｍ ＳＣＬ発見プロシージャは、事前のアクセスネットワークプロバイダによるＳＣＬアドレスの認識に依拠してもよい（例えば、ＳＣＬのホストのＦＱＤＮまたはＩＰアドレス、および、＜ｓｃｌＢａｓｅ＞のＵＲＩなど）。Ｍ２Ｍサービスプロバイダは、ＳＣＬアドレスをアクセスネットワークプロバイダと共有してもよい（例えば、それらは確立された関係を有する）。Ｍ２Ｍデバイス／ゲートウェイ／サーバは、アクセスネットワークブートストラップ／登録プロシージャを実行してもよく、その間に、アクセスネットワークプロバイダは、割り当てられたＳＣＬによってデバイス／ゲートウェイ／サーバを構成してもよい。

ＳＣＬアドレスのフォーマットに応じて、追加の発見ステップが必要とされることがある。ＳＣＬアドレスが、ＳＣＬのホストのＩＰアドレスまたはＦＱＤＮの形式であり、ホスト上に位置するＳＣＬへの完全ＵＲＩパスではない場合、追加の発見が必要とされることがある（例えば、ＳＣＬホストのＩＰアドレスを使用して、図１０のＭ２Ｍ既知リソースＳＣＬ発見プロシージャ１０００が使用されて完全なＵＲＩを発見してもよい）。Ｍ２Ｍデバイス／ゲートウェイ／サーバが既に適切なセキュリティ証明を有する場合、それはＳＣＬブートストラップ／登録プロシージャを実行してもよい。あるいは、Ｍ２Ｍデバイス／ゲートウェイ／サーバは、最初に適切な証明を取得してもよい（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

下層のアクセスネットワーク管理機能（例えば、オープンモバイルアライアンスデバイス管理（ＯＭＡ−ＤＭ：Open Mobile Alliance-device management）が使用されて、Ｍ２Ｍ ＳＣＬを割り当ててもよい。そのような場合、ネットワーク管理機能を介して、割り当てられたＳＣＬによってＭ２Ｍデバイス／ゲートウェイ／サーバが構成されてもよい。この手法の利点は、アクセスネットワーク管理機能が、アクセスネットワークブートストラップ／登録の間のみ、Ｍ２Ｍデバイス／ゲートウェイ／サーバを構成することに限定されないことがあることである。代わりに、アクセスネットワーク管理機能は、複数の更新を発行して、割り当てられたＳＣＬをより動的な方法で構成／再構成してもよい。

デバイス管理ベースのＭ２Ｍサービス発見プロシージャは、事前のネットワーク管理サーバによるＳＣＬアドレスの認識に依拠してもよい（例えば、ＳＣＬのホストのＦＱＤＮまたはＩＰアドレス、および、＜ｓｃｌＢａｓｅ＞のＵＲＩなど）。

Ｍ２Ｍサービスプロバイダは、ＳＣＬアドレスをネットワーク管理サーバと共有してもよい。Ｍ２Ｍデバイス／ゲートウェイ／サーバは、アクセスネットワークブートストラップ／登録プロシージャを実行してもよい。このプロシージャの間に、デバイス／ゲートウェイ／サーバは、アクセスネットワークに常駐するネットワーク管理サーバによって、割り当てられたＳＣＬのアドレスにより構成されてもよい。あるいは、ネットワーク管理サーバは、デバイス／ゲートウェイ／サーバのアドレスによってプロビジョニングされてもよく、またはそれを動的に発見してもよい（例えば、ブロードキャスト、および、局所化されたブロードキャストなどの何らかのアクセスネットワーク発見機構を使用することによって）。

Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバは、ネットワーク管理サーバからＳＣＬアドレス情報を要求してもよい。あるいは、ネットワーク管理サーバは、デバイス／ゲートウェイ／サーバＳＣＬにＳＣＬアドレス情報を送信してもよい。ＳＣＬアドレスのフォーマットに応じて、追加の発見が必要とされることがある。ＳＣＬアドレスが、ＳＣＬのホストのＩＰアドレスまたはＦＱＤＮの形式であり、ホスト上に位置するＳＣＬへの完全ＵＲＩパスではない場合、追加の発見が必要とされることがある（例えば、ＳＣＬホストのＩＰアドレスを使用して、図１０のＭ２Ｍ既知リソースＳＣＬ発見プロシージャ１０００が使用されて完全なＵＲＩを発見してもよい）。Ｍ２Ｍアプリケーション／ＳＣＵ／ゲートウェイ／サーバが既に適切なセキュリティ証明を有する場合、それはＳＣＬブートストラップ／登録プロシージャを開始してもよい。そうでない場合、デバイス／ゲートウェイ／サーバは、最初に適切な証明を取得してもよい（例えば、オフラインプロビジョニングを通じて、または図２のＭ２Ｍサービスプロバイダ発見プロシージャ２００、および図３のＭ２Ｍサービスプロバイダブートストラッププロシージャ３００を完了することを通じて）。

Ｍ２Ｍデバイス／ゲートウェイ／アプリケーションがＭ２Ｍサービスプロバイダとの加入を有さず、および、Ｍ２Ｍサービスプロバイダ発見を使用して、１つまたは複数の利用可能なプロバイダを発見するとき、Ｍ２Ｍサービスプロバイダ発見が必要とされることがある。さらに、Ｍ２Ｍデバイス／ゲートウェイ／アプリケーションが既存のＭ２Ｍサービスプロバイダ加入を新しいＭ２Ｍサービスプロバイダ加入に変更する必要があるとき、または場合によっては追加のサービスのために別のＭ２Ｍサービスプロバイダに加入するとき、それが必要とされることがある。例えば、既存のＭ２Ｍサービスプロバイダが、デバイス／ゲートウェイが必要とするサービスを提供しないとき、Ｍ２Ｍデバイス、ゲートウェイ、およびアプリケーションは、適切かつ利用可能なＭ２Ｍサービスプロバイダを発見するために発見プロシージャを実行してもよい。

実施形態
１．サービスプロバイダに属するサービスにアクセスする方法であって、
第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見するステップと、
第２の発見プロシージャを実行して、少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定するステップと
を備える方法。
２．少なくとも１つのサービスプロバイダとともにブートストラッププロシージャを実行するステップをさらに備える実施形態１に記載の方法。
３．第１の発見プロシージャは、
レコードデータベースにクエリするための情報を含むサービスプロバイダ発見要求を送信して、一致するサービスプロバイダ発見レコードを判定することと、
サービスプロバイダ発見要求におけるクエリと一致するサービス発見機能レコードリストを含むサービスプロバイダ発見応答を受信することと
を備える実施形態２のいずれか１つに記載の方法。
４．サービス発見機能レコードリストから、ブートストラップするための少なくとも１つのサービスプロバイダを選択するステップをさらに備える実施形態３に記載の方法。
５．ブートストラッププロシージャは、
選択されたサービスプロバイダに要求を送信することと、
サービスプロバイダから、ノードによって必要とされる情報を含む応答を受信して、サービスプロバイダの少なくとも１つのＳＣＬとともにブートストラッピングを開始することとを備える実施形態４に記載の方法。
６．情報は、セキュリティ証明を含む実施形態５に記載の方法。
７．第２の発見プロシージャは、
発行側が、レコードデータベースにクエリするための情報を含むサービス発見要求を送信して、一致するＳＣＬ発見レコードを判定することと、
発行側が、サービス発見要求におけるクエリに一致するサービス発見機能レコードリストを含むサービス発見応答を受信することと
を備える実施形態１〜６のいずれか１つに記載の方法。
８．サービス発見機能レコードリストは、複数のＳＣＬアドレスを含み、
方法は、
発行側が、既知のリソースにＳＣＬ発見要求を送信して、ホスト上に位置するＳＣＬへの完全ユニフォームリソース識別子（ＵＲＩ）パスを示さない、ＳＣＬアドレスの各々のＵＲＩを発見することと、
発行側が、既知のリソースから、発見されたＵＲＩを含むＳＣＬ発見応答を受信することと、
発行側が、サービス発見機能レコードリストから、ブートストラップするための少なくとも１つのＳＣＬを選択することと
をさらに備える実施形態７に記載の方法。
９．第２の発見プロシージャは、
ドメインネームシステムベースサービス発見（ＤＮＳ−ＳＤ）マシンツーマシン（Ｍ２Ｍ）サービス発見機能（ＭＳＤＦ）サーバにＳＣＬ発見レコードをプロビジョニングすることと、
ＤＮＳ−ＳＤ ＭＳＤＦサーバをパブリックＤＮＳ登録会社またはエンティティに登録して、パブリックＤＮＳ−ＳＤ ＭＳＤＦサービス発見ドメインを確立することと、
ＤＮＳ−ＳＤ ＭＳＤＦサーバが、発行側からＤＮＳ−ＳＤクエリを受信することと、
ＤＮＳ−ＳＤ ＭＳＤＦサーバが、ＤＮＳ−ＳＤクエリに応答して、発行側にＳＣＬ発見レコードを送信することと
を備える実施形態１〜６のいずれか１つに記載の方法。
１０．第２の発見プロシージャは、
発行側からＳＣＬ発見要求を受信することと、
発行側にＳＣＬ発見結果を提供するサービス発見応答を送信することと
を備える実施形態１〜６のいずれか１つに記載の方法。
１１．ＳＣＬ発見要求は、ｓｃｌＢａｓｅ属性を使用するクエリ文字列を含む実施形態１０に記載の方法。
１２．ＳＣＬ発見応答は、クエリ文字列に一致するＳＣＬと、各ＳＣＬの各々に対するｓｃｌＢａｓｅへの絶対ユニフォームリソース識別子（ＵＲＩ）とのリストを含む実施形態１１に記載の方法。
１３．第２の発見プロシージャは、
配置されたドメインネームシステム（ＤＮＳ）サーバのネットワークアドレスを発行側にプロビジョニングし、または、ネットワークアドレスにより発行側を構成することと、
利用可能なＳＣＬを有するホストに対する少なくとも１つの完全修飾ドメイン名（ＦＱＤＮ）を発行側にプロビジョニングし、または、ＦＱＤＮにより発行側を構成することと、
発行側が、ネットワークアドレスおよびＦＱＤＮを使用して、配置されたＤＮＳサーバにＤＮＳルックアップ要求を送信することと、
発行側が、対応するＳＣＬホストに対する解決されたネットワークアドレスを受信することと
を備える実施形態１〜６のいずれか１つに記載の方法。
１４．第２の発見プロシージャは、
動的ホスト構成プロトコル（ＤＨＣＰ）サーバのネットワークアドレスを発行側にプロビジョニングし、または、ネットワークアドレスにより発行側を構成することと、
発行側が、配置されたＤＨＣＰサーバにＤＨＣＰ要求を送信することと、
発行側が、ＳＣＬのアドレスおよび追加のＳＣＬ情報を含む応答を受信することと
を備える実施形態１〜６のいずれか１つに記載の方法。
１５．サービスプロバイダに属するサービスにアクセスする方法であって、
配置されたドメインネームシステム（ＤＮＳ）サーバのネットワークアドレスを発行側にプロビジョニングし、または、ネットワークアドレスにより発行側を構成するステップと、
利用可能なサービス能力レイヤ（ＳＣＬ）を有するホストに対する少なくとも１つの完全修飾ドメイン名（ＦＱＤＮ）を発行側にプロビジョニングし、または、ＦＱＤＮにより発行側を構成するステップと、
発行側が、ネットワークアドレスおよびＦＱＤＮを使用して、配置されたＤＮＳサーバにＤＮＳルックアップ要求を送信するステップと、
発行側が、対応するＳＣＬホストに対する解決されたネットワークアドレスを受信するステップと
を備える方法。
１６．発行側は、無線送信／受信ユニット（ＷＴＲＵ）である実施形態１５の記載の方法。
１７．第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見し、少なくとも１つの発見されたサービスプロバイダとともにブートストラッププロシージャを実行し、および、第２の発見プロシージャを実行して、少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定するように構成された装置。
１８．装置は、無線送信／受信ユニット（ＷＴＲＵ）である実施形態１７の記載の装置。
１９．装置は、ゲートウェイである実施形態１７に記載の装置。
２０．装置は、サーバである実施形態１７に記載の装置。
２１．第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見し、少なくとも１つの発見されたサービスプロバイダとともにブートストラッププロシージャを実行し、および、第２の発見プロシージャを実行して、少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定するように構成されたアプリケーションを格納するように構成されたコンピュータ可読記憶媒体。

上記では特徴および要素を特定の組合せで説明したが、各特徴および要素を単独で、または他の特徴および要素のいずれかと組み合わせて使用できることを当業者は理解されよう。さらに、本明細書に記載の実施形態は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続を介して送信される）、およびコンピュータ可読記憶媒体を含む。コンピュータ記憶可読媒体の例は、限定はしないが、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体（例えば、内部ハードディスクまたは着脱可能ディスク）、光磁気媒体、およびコンパクトディスク（ＣＤ）やデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ、ＳＣＵ、ＵＥ、端末、基地局、Ｎｏｄｅ−Ｂ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、無線ルータ、または任意のホストコンピュータで使用される無線周波数送受信機を実装してもよい。

Claims (16)

1. サービスプロバイダに属するサービスにアクセスする方法であって、
   発行側デバイスが、第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見するステップと、
   前記発行側デバイスが、前記少なくとも１つの発見されたサービスプロバイダとのブートストラッププロシージャを実行するステップと、
   前記発行側デバイスが、第２の発見プロシージャを実行して、前記少なくとも１つの発見されたサービスプロバイダによってサポートされる、利用可能なサービス能力レイヤ（ＳＣＬ）を判定するステップであって、前記第２の発見プロシージャは、
   前記発行側デバイスが、ドメインネームシステムベースサービス発見（ＤＮＳ−ＳＤ）クエリをＤＮＳ−ＳＤマシンツーマシン（Ｍ２Ｍ）サービス発見機能（ＭＳＤＦ）サーバに送信するステップであって、前記ＤＮＳ−ＳＤ ＭＳＤＦサーバは、ＳＣＬ発見レコードがプロビジョニングされ、および前記ＤＮＳ−ＳＤ ＭＳＤＦサーバは、パブリックＤＮＳサーバに登録される、ステップと、
   前記発行側デバイスが、前記ＤＮＳ−ＳＤクエリに応答して、前記ＤＮＳ−ＳＤ ＭＳＤＦサーバから、ＳＣＬ発見レコードを受信するステップと
   を備えている、ステップと
   を備えたことを特徴とする方法。
2. 前記第１の発見プロシージャは、
   前記発行側デバイスが、レコードデータベースをクエリするための情報を含むサービスプロバイダ発見要求を送信して、一致するサービスプロバイダ発見レコードを判定するステップと、
   前記発行側デバイスが、前記サービスプロバイダ発見要求におけるクエリと一致するサービス発見機能レコードリストを含むサービスプロバイダ発見応答を受信するステップと
   を備えていることを特徴とする請求項１に記載の方法。
3. 前記発行側デバイスが、前記サービス発見機能レコードリストから、ブートストラップする少なくとも１つのサービスプロバイダを選択するステップをさらに備えたことを特徴とする請求項２に記載の方法。
4. 前記ブートストラッププロシージャは、
   前記発行側デバイスが、前記選択されたサービスプロバイダに要求を送信するステップと、
   前記発行側デバイスが、前記選択されたサービスプロバイダから、前記サービスプロバイダの少なくとも１つのＳＣＬとブートストラッピングを開始するのに、ノードによって必要とされる情報を含む応答を受信するステップと
   を備えていることを特徴とする請求項３に記載の方法。
5. 前記情報は、セキュリティ証明を含むことを特徴とする請求項４に記載の方法。
6. 前記第２の発見プロシージャは、
   前記発行側デバイスが、レコードデータベースをクエリするための情報を含むサービス発見要求を送信して、一致するＳＣＬ発見レコードを判定するステップと、
   前記発行側デバイスが、前記サービス発見要求におけるクエリと一致するサービス発見機能レコードリストを含むサービス発見応答を受信するステップと
   を備えていることを特徴とする請求項１に記載の方法。
7. 前記サービス発見機能レコードリストは、複数のＳＣＬアドレスを含み、
   前記方法は、
   前記発行側デバイスが、既知リソースにＳＣＬ発見要求を送信して、ホスト上に位置するＳＣＬへの完全ユニフォームリソース識別子（ＵＲＩ）パスを示さない、前記ＳＣＬアドレスの各々のＵＲＩを発見するステップと、
   前記発行側デバイスが、前記既知リソースから、前記発見されたＵＲＩを含むサービス発見応答を受信するステップと、
   前記発行側デバイスが、前記サービス発見機能レコードリストから、ブートストラップする少なくとも１つのＳＣＬを選択するステップと
   をさらに備えたことを特徴とする請求項６に記載の方法。
8. 前記第２の発見プロシージャは、
   前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスからＳＣＬ発見要求を受信するステップと、
   前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスにＳＣＬ発見結果を提供する、ＳＣＬ発見応答を送信するステップと
   をさらに備えていることを特徴とする請求項１に記載の方法。
9. 前記ＳＣＬ発見要求は、ｓｃｌＢａｓｅ属性を使用するクエリ文字列を含むことを特徴とする請求項８に記載の方法。
10. 前記ＳＣＬ発見応答は、前記クエリ文字列と一致するＳＣＬと、前記ＳＣＬの各々に対するｓｃｌＢａｓｅへの絶対ユニフォームリソース識別子（ＵＲＩ）とのリストを含むことを特徴とする請求項９に記載の方法。
11. 前記第２の発見プロシージャは、
    前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスに、配置されたドメインネームシステム（ＤＳＮ）サーバのネットワークアドレスをプロビジョニングし、または、前記発行側デバイスを、配置されたＤＳＮサーバのネットワークアドレスで構成するステップと、
    前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスに、利用可能なＳＣＬを有するホストに対する完全修飾ドメイン名（ＦＱＤＮ）をプロビジョニングし、または、前記発行側デバイスを、利用可能なＳＣＬを有するホストに対するＦＱＤＮで構成するステップと、
    前記発行側デバイスが、前記ネットワークアドレスおよびＦＱＤＮを使用して、前記配置されたＤＳＮサーバにＤＳＮルックアップ要求を送信するステップと、
    前記発行側デバイスが、対応するＳＣＬホストに対する解決されたネットワークアドレスを受信するステップと
    をさらに備えていることを特徴とする請求項１に記載の方法。
12. 前記第２の発見プロシージャは、
    前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスに、動的ホスト構成プロトコル（ＤＨＣＰ）サーバのネットワークアドレスをプ
    ロビジョニングし、または、発行側デバイスを、ＤＨＣＰサーバのネットワークアドレスで構成するステップと、
    前記発行側デバイスが、前記ＤＨＣＰサーバにＤＨＣＰ要求を送信するステップと、
    前記発行側デバイスが、ＳＣＬのアドレスおよび追加ＳＣＬ情報を含む応答を受信するステップと
    をさらに備えていることを特徴とする請求項１に記載の方法。
13. 前記発行側デバイスは、無線送信／受信ユニット（ＷＴＲＵ）であることを特徴とする請求項１に記載の方法。
14. 請求項１乃至１３のいずれか一項に記載された前記第１の発見プロシージャおよび前記ブートストラッププロシージャを実行するように構成されているアプリケーションを記憶するように構成されていることを特徴とするコンピュータ可読記憶媒体。
15. サービスプロバイダに属するサービスにアクセスする方法であって、
    発行側デバイスが、第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見するステップと、
    前記発行側デバイスが、前記少なくとも１つの発見されたサービスプロバイダとのブートストラッププロシージャを実行するステップと、
    前記発行側デバイスが、第２の発見プロシージャを実行して、前記少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定するステップであって、前記第２の発見プロシージャは、
    前記少なくとも１つの発見されたサービスプロバイダが、前記発行側デバイスに、動的ホスト構成プロトコル（ＤＨＣＰ）サーバのネットワークアドレスをプロビジョニングし、または、発行側デバイスを、ＤＨＣＰサーバのネットワークアドレスで構成するステップと、
    前記発行側デバイスが、前記ＤＨＣＰサーバにＤＨＣＰ要求を送信するステップと、
    前記発行側デバイスが、ＳＣＬのアドレスおよび追加ＳＣＬ情報を含む応答を受信するステップと
    を備えている、ステップと、
    を備えたことを特徴とする方法。
16. 第１の発見プロシージャを実行して、少なくとも１つのサービスプロバイダを発見する手段と、
    前記少なくとも１つの発見されたサービスプロバイダとのブートストラッププロシージャを実行する手段と、
    第２の発見プロシージャを実行して、前記少なくとも１つの発見されたサービスプロバイダによってサポートされる利用可能なサービス能力レイヤ（ＳＣＬ）を判定する手段であって、前記第２の発見プロシージャは、
    ドメインネームシステムベースサービス発見（ＤＮＳ−ＳＤ）クエリをＤＮＳ−ＳＤマシンツーマシン（Ｍ２Ｍ）サービス発見機能（ＭＳＤＦ）サーバに送信することであって、前記ＤＮＳ−ＳＤ ＭＳＤＦサーバは、ＳＣＬ発見レコードがプロビジョニングされ、および前記ＤＮＳ−ＳＤ ＭＳＤＦサーバは、パブリックＤＮＳサーバに登録される、ことと、
    前記ＤＮＳ−ＳＤクエリに応答して、前記ＤＮＳ−ＳＤ ＭＳＤＦサーバから、ＳＣＬ発見レコードを受信することと
    を備えている、手段と
    を備えたことを特徴とする無線送信／受信ユニット（ＷＴＲＵ）。

Images