JP2013537777A - 通信ネットワークにおける自動発見の方法および装置 - Google Patents

Abstract

自動化された方法は、マシン・ツー・マシン環境においてサービスを提供するために協力するネットワーク・エンティティとクライアント・エンティティとの間の相互発見のために提供される。一実施形態においては、ネットワーク・エンティティは、クライアント・エンティティに代わってサーバからの通信において識別子を受信する。ある時点において、ネットワーク・エンティティは、クライアント・エンティティから識別子を含む通信を受信する。クライアント・エンティティ通信を受信する前に、または受信した後に、ネットワーク・エンティティは、クライアント・エンティティに対して名乗り出る。クライアント・エンティティ通信を受信した後のある時刻に、ネットワーク・エンティティは、クライアント・エンティティを認証し、クライアント・エンティティとの恒久的なセキュリティ関連付けを確立し、またサービスを開始する。

Description

本発明は、通信ネットワーク上のエンティティが互いに名乗り合うための方法に関する。

ネットワークの上のデバイスの間の自動化された通信が、ますますユビキタスになるにつれて、ますます複雑になるトランザクションの自動化への必要性が高まっている。これによって、ひいては、ネットワーク通信プロトコルの分野において、かつてないほど多くの問題の解決策が求められている。

１つのこうしたクラスの問題は、ネットワークの上の互いの存在について最初は知っていないエンティティの間の相互認識およびセキュリティ関連付け（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎｓ）の確立に関連している。以下の類似性により、そのクラスの一般化された問題は、ここでは「ホテル発見問題」と呼ばれる。

ある訪問者が、空港に到着し、到着した都市において彼の行き先のホテルに到着しようと意図している。訪問者は特定の行き先に到着することが予想されるが、また行き先のホテルは彼を期待しているが、訪問者は、行き先のホテルの身元（ｉｄｅｎｔｉｔｙ）を知らない。ホテルは、もちろん、多数の訪問者に対応しなければならない。訪問者は、１つまたは複数の行き先を訪問し、訪問したホテルのうちの１つが彼の行き先であり、また彼を認識することを期待して自己紹介することができる。しかしながら、そのようなプロセスは、多数の候補ホテルが存在する場合には、実現可能でない可能性がある。それゆえに、問題は、最小限のサード・パーティの助けを受けて、またはサード・パーティの助けなしに、正しいホテルを見つけ出す効率の良い方法を見出すことである。望ましい解決法は、訪問者に正しいホテルを見出すことにより訪問者の安全性を保証しなければならず、またホテルが期待している訪問者だけが入ることを許可することにより、ホテルの安全性を保証しなければならない。

驚いたことに、上記で概説された問題は、様々な修正を加えて、クライアントのエンティティまたはデバイス（ヒューマン・インターフェースを有する、またはヒューマン・インターフェースを有さない）と、宛先ネットワークまたはサーバ・エンティティとを伴う複数の自動化された通信環境に対して適用可能である。

例えば、自宅所有者は、小売店センタにおいて、リモートに読取り可能なユーティリティ・メータ（ｕｔｉｌｉｔｙ ｍｅｔｅｒ）を購入し、また彼の家にそれをインストールする。ユーティリティ・メータは、それが報告することになる相手のユーティリティ・ウェブサイトを発見する必要があり、また公益事業会社（ｕｔｉｌｉｔｙ ｃｏｍｐａｎｙ）は、そのメータが、オンラインになっていることを発見する必要がある。自宅所有者のプライバシーを保証するために、また乱用を防止するために、セキュリティ関連付けが、ユーティリティ・メータと、ユーティリティ・ウェブサイトとの間で確立される必要がある。従来、これらのオペレーションは、サード・パーティの介入を通して実行されている。サード・パーティからのオンライン支援をほとんど、または全く受けずに必要な発見および認証を実行できる自動化された方法が、これまで欠如している。

ＥＴＳＩ ＴＳ １０２ ６９０技術仕様：Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（Ｍ２Ｍ）；Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ ＩＥＴＦインターネット・ドラフトｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｃａｋｕｌｅｖ−ｉｂａｋｅ−０１、ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ ＩＥＴＦ ＲＦＣ ５６８３、Ｐａｓｓｗｏｒｄ−Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ（ＰＡＫ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ Ｅｘｃｈａｎｇｅ、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５６８３ 第３世代パートナーシップ・プロジェクト、３ＧＰＰ技術仕様３ＧＰＰ ＴＳ ３３．１０２ Ｖ９．０．０：Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｓｙｓｔｅｍ Ａｓｐｅｃｔｓ；３Ｇ Ｓｅｃｕｒｉｔｙ；Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ、２００９年９月 Ｎ．Ｈａｌｌｅｒ他、Ａ Ｏｎｅ−Ｔｉｍｅ Ｐａｓｓｗｏｒｄ Ｓｙｓｔｅｍ、ＲＦＣ２２８９、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２８９．ｔｘｔ Ｗ．Ｓｉｍｐｓｏｎ、ＰＰＰ Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣＨＡＰ）、ＲＦＣ １９９４、ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１９９４．ｈｔｍｌ Ｒ．Ｂｒａｄｅｎ他、ＲＦＣ １０７１、Ｃｏｍｐｕｔｉｎｇ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｃｈｅｃｋｓｕｍ、ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１０７１．ｈｔｍｌ

本願は、そのような方法を提供するものである。一実施形態においては、ネットワーク・エンティティは、サービスについて認可されたクライアント・エンティティに代わって、サーバからの通信において識別子を受信する。ネットワーク・エンティティは、クライアント・エンティティからのメッセージの、指定されない時刻における到着を識別する際に使用するために、その識別子をデジタル・ストレージ媒体に自動的に記憶する。

ある時点において、ネットワーク・エンティティは、クライアント・エンティティからデジタル通信を受信する。デジタル通信は、識別子を含んでおり、またクライアント・エンティティが、通信ネットワークに参加していることを示す。

クライアント・エンティティ通信を受信する前に、または受信した後に、ネットワーク・エンティティは、サービスを提供するための協力パーティとして、クライアント・エンティティに対して身元を明らかにする。クライアント・エンティティに対して身元を明らかにするために、ネットワーク・エンティティは、通信ネットワークの上で少なくとも１つのメッセージを自動的に生成し、また送信する。

クライアント・エンティティ通信を受信した後のある時点で、ネットワーク・エンティティは、クライアント・エンティティからのデジタル通信において受信された識別子が、サーバ通信において受信された識別子とマッチするという条件で、一連の自動化ステップを通してクライアント・エンティティを認証する。次いで、ネットワーク・エンティティは、クライアント・エンティティとの恒久的なセキュリティ関連付けを確立し、またクライアント・エンティティへのサービスを開始する。

本発明のアプローチの１つの利点は、ｎを宛先ネットワークまたはサーバ・エンティティの数として、全数探索は、Ｏ（ｎ）という最悪ケースの複雑さを有するが、本発明のアプローチの複雑さは、かなり低減されており、また一定の時間内に実行される（すなわち、Ｏ（１）である）ということである。

代表的な自動化された通信環境についての概略図である。ホテル発見問題は、とりわけ図に示されるような環境に対して適用可能である。 複雑なマシン・ツー・マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）（Ｍ２Ｍ）エコシステムにおけるエンティティの間の様々なトランザクションの関係についての概略図である。 マシン・ツー・マシン（Ｍ２Ｍ）エコシステムにおいてサービス・レイヤ・アーキテクチャの高レベルの機能の概要を提供する概略図である。 本発明の様々な実施形態による、マシン・ツー・マシン・オペレータ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｏｐｅｒａｔｏｒ）（Ｍ２ＭＯ）発見を示すメッセージ・フロー図である。 本発明の様々な実施形態による、マシン・ツー・マシン・オペレータ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｏｐｅｒａｔｏｒ）（Ｍ２ＭＯ）発見を示すメッセージ・フロー図である。 本発明の様々な実施形態による、マシン・ツー・マシン・オペレータ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｏｐｅｒａｔｏｒ）（Ｍ２ＭＯ）発見を示すメッセージ・フロー図である。 本発明の一実施形態による、Ｍ２ＭＯとＭ２Ｍデバイスとの間の加入確立のためのプロシージャを示すメッセージ・フロー図である。 いくつかの実施形態における本発明を実行するために有用な信号メッセージについての例示のデータグラム構造を示す図である。 いくつかの実施形態における本発明を実行するために有用な信号メッセージについての例示のデータグラム構造を示す図である。 いくつかの実施形態における本発明を実行するために有用な信号メッセージについての例示のデータグラム構造を示す図である。

包括的な自動化された通信環境
ホテル発見問題は、図１に示される通信環境など、自動化された通信環境に対して直接に適用可能である。この包括的な設定において、互いに安全に接続するように試みるＮ個のクライアント・エンティティ１０の組とＭ個のサーバ・エンティティ２０の組について考慮されたい。

以下の自動化されたホテル発見問題（Ａｕｔｏｍａｔｅｄ Ｈｏｔｅｌ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｂｌｅｍ）を定義する。すなわち、各クライアント・エンティティは、まさしく１つのサーバ・エンティティと接続することを望むが、サーバ・エンティティは、多数のクライアント・エンティティにサービスしている可能性がある。クライアントは、どのサーバが、それが接続する必要があるサーバであるかについての予備知識を持っていないが、各サーバは、それが通信することを期待するクライアントのアイデンティティ（ｉｄｅｎｔｉｔｙ）を知っている可能性がある。目標は、安全に、すなわち偽物のサーバ・エンティティがクライアント・エンティティをハイジャックしないようにするように、また逆に、各サーバ・エンティティに、各サーバ・エンティティが、それが話すことを期待する相手のクライアント・エンティティだけに話していることを保証するように、各クライアント・エンティティをその対応するサーバ・エンティティと接続することである。ここで組み立てられた問題では、クライアント・エンティティと、サーバ・エンティティとが、通信ネットワークを通してリンクを確立すると仮定しており、この通信ネットワークは、ゲートウェイ３０と、バック・オフィス・サーバ４０とを、例えば、データベースに接続されたウェブ・ポータルとを含んでいる。

ホテル発見問題の実現
モバイル通信ネットワークにおけるホテル発見問題の実現。ホテル発見問題の現在の実現についての一例においては、モバイル電話（上記で組み立てられた問題において「訪問者」の役割を演じる）は、アクティブにされるとすぐに、それに関連付けられると考えられるどのネットワーク・オペレータ（「ホテル」の役割を演じる）にアクセスするかを発見する必要がある。より具体的には、ユーザが、セルラ方式電話をオンにするときに、その電話が、それに登録されると考えられるオペレータのネットワーク・アイデンティティを先験的に知らない場合に、その問題が当てはまる。（類似した問題は、公衆ホットスポットにおけるＷｉＦｉアクセスに当てはまり得る。）

いわゆるオープンなデバイス環境において動作する電子書籍リーダ（ｅ−ｒｅａｄｅｒ）などの非伝統的ワイヤレス機能対応デバイスの発展は、その問題をより差し迫ったものにしている。例えば、電子書籍リーダは、ワイヤレス・インターフェースを装備しており、ターゲット視聴者を拡大するために複数のワイヤレス技術をますます大幅にサポートしている。このアプローチにより、また、電子書籍リーダの製造業者は、彼らのデバイスを流通させるときに、１つのオペレータに焦点を絞るのではなく、信頼されるが、さらにオープンな小売店流通戦略を活用することができるようにもなる。

したがって、それによって、モバイル電話、電子書籍リーダ、または他のユーザ電気器具が、少なくともいくつかの候補のアクセス・ネットワークを認識し、また正しいアクセス・ネットワークを確実に選択することができ、またそれによって、アクセス・ネットワークは、既に知られている、または既に期待しているこれらの合法的なデバイスだけに入場を制限するための自動化された方法についての必要性が存在する。

Ｍ２Ｍ通信におけるホテル発見問題の実現。マシン・ツー・マシン（Ｍ２Ｍ）通信は、Ｍ２Ｍアプリケーションが出現し、前例のない潜在性をもたらしていることにより、広範にわたる成長を経ている。数十億個の低コストＭ２Ｍデバイスが、アクセス・ネットワークの混合物を活用する複数のＭ２Ｍオペレータ（Ｍ２ＭＯ）によって提供される数千個のアプリケーションを用いて展開されることが期待される。初期のＭ２Ｍ展開は、単一の提携したアクセス・ネットワーク・オペレータに対するそれらの密接な依存性と、それらのオペレータへの信頼とによって特徴づけられてきており、このオペレータは、一般的に、ほとんどのＭ２Ｍオペレーションを管理し、またいくつかの絶対必要なサービスを提供する。

１つの現在使用可能なサービスは、Ｍ２Ｍサービスの発見であり、このＭ２Ｍサービスの発見は、在庫があってすぐに入手可能なＭ２Ｍデバイスが、適切なアクセス・ネットワーク・プロシージャを通して、その関連のあるＭ２ＭＯについてのアイデンティティを与えられることを可能にしており、またそれがそのＭ２ＭＯにアタッチすることを可能にしている。例えば、Ｍ２Ｍデバイスは、１つの特定のアクセス・ネットワーク・プロバイダで動作するように（例えば工場において）あらかじめ構成されている可能性があるが、アクセス・ネットワーク・プロバイダは、特定の分野において、特定のＭ２ＭＯと排他的合意を有する。Ｍ２Ｍデバイスが、初めてアクセス・ネットワークに接続するときに、アクセス・ネットワークは、そのアドレスと、通信パラメータとを含めて、Ｍ２Ｍオペレータのアイデンティティをデバイスに対して通信する。その後に、Ｍ２Ｍデバイスは、この特定のＭ２ＭＯと通信する。

しかしながら、そのようなアーキテクチャ・モデルは、Ｍ２ＭＯが、アクセス・ネットワーク・オペレータから切り離され、またＭ２Ｍサービス・プロバイダとして、多数の、場合によっては数十億個さえものデバイスを独立に管理する必要がある、大規模なＭ２Ｍ展開から構成される複雑なＭ２Ｍエコシステムを（期待されるように）受け入れることができない。

図２は、ネットワーク・エンティティのオペレータとして、または他の種類の利害関係者としてのいずれかで、複雑なＭ２Ｍエコシステムに参加する様々なエンティティを一般的に接続するトランザクションの関係を概略的に表すものである。これらは、製造業者５０と、アプリケーション・プロバイダ６０と、Ｍ２Ｍオペレータ７０と、アクセス・ネットワーク・オペレータ８０と、顧客９０が所有または制御するデバイス１００とを含む。

そのような複雑なＭ２Ｍエコシステムにおいては、Ｍ２ＭＯは、Ｍ２Ｍサービスの発見オペレーションを管理するためのアクセス・ネットワーク・レイヤに頼ることができない。すなわち、Ｍ２ＭＯと、アクセス・ネットワーク・オペレータとの間のビジネス関係がかけている可能性があり、またはアクセス・ネットワーク・フレームワークは、本質的にそのようなサポートを提供することができない可能性がある。（例えば、使用可能なアクセス・ネットワークは、多くの場合に、特定の能力を持たない単純で純粋な移送手段にすぎないことになる。）

さらに、どのような決定が、Ｍ２Ｍオペレータと、Ｍ２Ｍデバイスとの間の特定の関連付けに関して行われるよりもかなり前に、Ｍ２Ｍデバイスは、多くの場合に、商用の使用可能性のために製造され、また流通される。１つの結論は、構成の後についてのユーザ・インターフェースを持たない、多数の、在庫があってすぐに入手可能なＭ２Ｍデバイスは、それらが一緒に関連付けを確立することになっているＭ２ＭＯのアイデンティティについての初期のアクティブ化について知らないことになり、またそれらは、初期のアクティブ化についてのその情報を獲得する自動化手段を持たないことになるということである。Ｍ２ＭＯがサポートする必要がある可能性がある非常に多くの個数のＭ２Ｍデバイスを仮定すると、Ｍ２ＭＯに関連した情報の手動的な事前プロビジョニングなどの非スケーラブルな解決法が、実現可能でない可能性があることが、理解されよう。

したがって、Ｍ２Ｍデバイスが、適切なＭ２ＭＯを発見し、また適切なＭ２ＭＯに関連付けることを可能にする問題に対処するためのスケーラブルな技法についての必要性が存在している。以下では、例示の目的のために、本発明者等は、本発明の技法について、Ｍ２Ｍデバイスに関連するものとして説明する。しかしながら、同じ技法はまた、例えば、ＥＴＳＩ ＴＳ １０２ ６９０技術仕様：Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（Ｍ２Ｍ）；Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅにおける「Ｍ２Ｍゲートウェイ」についての定義から理解されるように、Ｍ２Ｍゲートウェイに対しても適用可能であることに留意されたい。

広告におけるホテル発見問題の実現。広告の目標は、新しい製品に対する顧客の注意を引くことである。広告に適用されるようなホテル発見問題の実現において、顧客は、訪問者の役割を演じるが、新しい製品を広告する会社は、ホテルの役割を演じる。したがって、会社の目標は、製品の存在および価値について顧客に通知することである。それに応じて、顧客は、製品についての見込みのある購入者として、製品を販売する会社との関係を確立することが期待される。

現代のデータ・マイニング方法論は、広告主が、好ましい広告するターゲットである消費者を識別することを可能にしている。

したがって、広告主が、その好ましいターゲットに到達することを、また逆に、顧客が彼らが好む広告だけを受け取ることを確実に可能する、自動化された方法が求められている。

ホテル発見問題に対する解決法についての高レベルの記述
本発明者等は、図に示されるように、自動化され得る、またホテル発見問題に対する例示の解決法となる、３つの方法について説明する。これらの方法のどれを用いても、訪問者は、たとえ彼が、先験的に、彼の行き先についてのアイデンティティを知らないとしても、またたとえサード・パーティが、ずっと継続する形態で、彼にアドバイスすることができないとしても、適切な行き先を識別し、また適切な行き先に到着することができる。簡単に言えば、それらの解決法は、以下のようなものである。

１．ホテルは、訪問者が、ホテルに到着することを望んでいることを知っており、またそれに応じて空港に代理人を派遣して、訪問者に会い、また訪問者をピックアップする。これは、到着についての正確な時刻が知られており、また訪問者およびホテルについてのセキュリティが、確認され得るときの限られた場合に当てはまる。

２．ホテルのグループは、ピックアップ・バンを空港へと送って、様々な個人をピックアップするが、しかしながら、特定の訪問者は、明確には招待されても、または通知されてもいない。訪問者は、その乗車を受け入れ、またホテルへと向かい、そこで、安全なネゴシエーション・プロセスを通して、訪問者は、このホテルが、意図された行き先であるか否かを決定する。ホテルがそうでない場合、そのときには訪問者は、そのバンへと戻り、また別の候補の行き先へと向かう。（このシナリオの変形においては、各ホテルは、それ自体のバンを提供する。）

３．訪問者は、メディアを使用して、彼の到着を知らせる。訪問者を期待するホテルは、訪問者の到着について知り、また空港へと代理人を送って、訪問者に会い、また訪問者による、また代理人による検証の後にホテルまで訪問者を連れてくる。

以下で、本発明者等は、どのようにして、これらの解決法が、自動化された設定における特定の通信環境に対するアプリケーションのために、実装される可能性があるかについて説明する。とりわけ、本発明者等は、セキュリティおよび効率を保証するために有効であるプロトコルと、これらの解決法を実現可能にするシステム・アーキテクチャとについて説明する。

自動化された通信環境におけるフレームワークおよび解決法
一般的な問題に対する解決法。図１を参照して、本発明者等は、Ｎ個のクライアント・エンティティ１０の組と、Ｍ個のサーバ・エンティティ２０の組とが、安全に互いに接続しようと試みている自動化された通信環境を考慮する。本発明者等は、クライアント・エンティティと、サーバ・エンティティとが、ゲートウェイ３０と、バック・オフィス・サーバ４０とを含む通信ネットワークを通してリンクを確立することを仮定している。「バック・オフィス・サーバ」とは、（データベースに、またネットワークに接続されるウェブ・ポータル、または他の類似したエンティティを意味する。）

一般的に、クライアントは、非常に限られたユーザ・インターフェースを有し、または全くユーザ・インターフェースがないことさえあり、また人間の介入がほんの少ししかなく、または人間の介入なしに、ネットワークにおいてサーバと通信することができるように設計されているデバイスになる。Ｍ２Ｍ通信の技法は、例えば、クライアント・デバイスが、自動的に、また人間の介入なしに、ネットワーク・サーバなど、ネットワークにおける別のマシンと通信する助けを行うことができる。

Ｍ２Ｍシステムのいくつかの例は、すなわち、ユーティリティ・メータが、ユーティリティ・プロバイダ・サーバに対して定期的に報告すること、医療用モニタが、収集された患者のデータを病院のサーバに対して供給すること、自動化乗り物モジュールが、中央乗り物コンピュータ・システムによって制御されること、および温度湿度制御デバイス（ｃｌｉｍａｔｅ ｃｏｎｔｒｏｌ ｄｅｖｉｃｅ）が、中央物理プラント・コンピュータに対して報告し、また中央物理プラント・コンピュータによって制御されることである。

一実施形態においては、サーバ・エンティティと、クライアント・エンティティとは、一時的なパスワードを共用することができる。一時的なパスワードは、製造中にクライアントにおいてあらかじめ使えるように設定される（ｐｒｅ−ｐｒｏｖｉｓｉｏｎｅｄ）可能性もあり、または代わりに（しかもキーパッドなど、適切なユーザ・インターフェースが、使用可能である場合だけに）、クライアントのユーザは、一時的なパスワードを選択し、またそのパスワードをクライアントに入力することができる。

さらに、各クライアントについての情報は、バック・オフィス・サーバと共用される。共用された情報は、一般的に、一時的なパスワードと、クライアントについてのアイデンティティとを含むことになる。このアイデンティティは、特定のサーバに対してクライアントを一意的に識別しなければならない。共用された情報はまた、とりわけ、クライアントが接続する必要があるサーバのアイデンティティと、アイデンティティに関連した暗号プリミティブとを含むこともできる。バック・オフィス・サーバは、一般的に、認証サーバ（以下で論じられるが、図１には示されていない）とこの情報を共用することになる。

ホテル発見問題をさらに参照すると、上記で説明されるような通信環境におけるサーバ・エンティティは、ホテルの役割を演じるが、クライアント・エンティティは、訪問者の役割を演じる。クライアントと、サーバとが、互いに識別し、またサービス関連付けを確立するためには、１つまたは複数の以下の例示のアプローチ−おのおのがホテル発見問題に対する解決法−が有利である可能性がある。

（１）サーバ・エンティティは、バック・オフィス・サーバからクライアントのアイデンティティを取得する。この情報は、バック・オフィス・サーバによってサーバ・エンティティに対して知らされ、すなわちバック・オフィス・サーバに対して「プッシュ」される可能性がある。代わりに、サーバ・エンティティは、関連するバック・オフィス・サーバに、この情報を定期的に要求し、またそれに応じてこの情報を受信し、すなわち、この情報を「プル」することができる。

次いで、サーバ・エンティティは、その特定のアイデンティティを有するクライアントに対して広告メッセージを送信することにより連絡しようとする。広告を受信するとすぐに、クライアントは、サーバ・エンティティとの相互認証セッションに従事する。これは、一般的に、通信ネットワークにおいてゲートウェイを通して行われることになる。正常な認証の後に、クライアント・エンティティと、サーバ・エンティティとは、より恒久的なセキュリティ・プロトコルを実行し、また恒久的にお互いを発見する。

この点において有用とすることができるいくつかの知られているセキュリティ・プロトコルは、ＩＢＡＫＥおよびＰＡＫである。例えば、ＩＥＴＦインターネット・ドラフトｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｃａｋｕｌｅｖ−ｉｂａｋｅ−０１、ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ、およびＩＥＴＦ ＲＦＣ ５６８３、Ｐａｓｓｗｏｒｄ−Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ（ＰＡＫ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ Ｅｘｃｈａｎｇｅ、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５６８３を参照されたい。

（２）サーバ・エンティティからの広告は、任意の「興味のある」クライアント・エンティティに向かうことになっているブロードキャスト・メッセージ（「サービス・オファー」）の形態をとる。上記のように、クライアントが、そのようなブロードキャスト・メッセージ（オファー）を受信するとすぐに、そのクライアントは、発見プロセスを開始する。しかしながら、ブロードキャスト・メッセージを受信することは、必ずしも成功をもたらすとは限らない。例えば、オファーは、間違ったサービス・エンティティからクライアントによって受信される可能性もあり、または期待されなかったクライアントが、サービス・エンティティに接続しようと試みる可能性もある。いずれの場合にも、相互に認証された発見プロセスが失敗する結果になろう。失敗の場合には、クライアント・エンティティは、ブロードキャスト・メッセージをリッスンすることを再開し、また発見プロセスが、相互に認証し、また成功するまで、連続して他のサーバ・エンティティに接続しようと試みる。

（３）クライアント・エンティティは、広告を要求することによりプロセスを開始する。この要求は、例えば、ウェブ・ページ・アクセスを通して、バック・オフィス・サーバに伝えられる可能性がある。次いで、バック・オフィス・サーバは、サービング・エンティティに対してこの要求を伝えることができる。サービング・エンティティが、そのような要求を受信するとすぐに、そのサービング・エンティティは、例えば、これらの例示のアプローチのうちの第１のものに関して説明されるように、クライアントに対して広告を送信する。クライアントによる広告の受信のすぐ後に、クライアントと、サーバとは、相互にお互いを認証し、またその後に、加入に関連のある恒久的な証明書を確立する。

上記の３つの例示の各アプローチについて、以下でより詳細に説明される。

オープンなデバイス環境における問題の実現に対する解決法。
上記の３つのアプローチのおのおのは、オープンなデバイス環境において実装される可能性がある。先験的に、特定のサービス・プロバイダに関連付けられていない、すなわち特定のサービス・エンティティと一緒にだけ機能するように、また排他的に機能するようにあらかじめ構成されていない汎用デバイスは、オープンなデバイスであるように考えられることがよく理解されよう。オープンなデバイスを受け入れるように、またワーキング・システムにおいてそれらを統合するように定義されるフレームワークは、「オープンなデバイス環境」として定義される。オープンなデバイスの例は、任意の水道供給会社とともに機能することができる汎用水道メータ、または任意の警報システムと一体化され、またシステム特有の証明書を付与され得る警報センサを含んでいる。同様に、特定の、所定のネットワークに結合されていない電子書籍リーダは、オープンなデバイスであるように考えられる。

第１のアプローチに従って、オープンなデバイスのユーザは、そのユーザの選択したアクセス・ネットワークとともに、一時的な証明書（例えば、一時的なパスワード）を確立することができる。言い換えれば、ユーザは、対応するネットワーク・オペレータとの一時的なビジネス関係を設定する。例えば、多くの場合に「オフライン事前プロビジョニング」と称されることもあるプロシージャにおいて、ユーザは、バック・オフィス・サーバと通信し、サービス加入を確立し、デバイス・アイデンティティを提供することなどを行う。バック・オフィス・サーバは、次には、デバイスのアイデンティティをサービス・オペレータに対して提供する。

この点において、ユーザと、選択されたネットワークとの間の通信は、興味のある特定のオープンなデバイスを必要としない可能性があることに留意されたい。とりわけ、オープンなデバイスは、一時的な証明書について知らない可能性があり、またキーパッドなど、標準的なインターフェースを通してユーザによってそれらを提供される必要がある可能性がある。しかしながら、オペレータは、デバイスの存在について知っている。

事前プロビジョニングの後で、（訪問者の役割の）デバイスは、（ホテルの役割の）オペレータから明示的なページング・メッセージを受信し、このページング・メッセージは、ネットワーク・オペレータを識別する情報と、提供されるサービスのタイプとを提供する。次に、デバイスは、加入要求をオペレータに対して送信することができる。デバイスと、オペレータとが、正常にお互いを相互に認証する場合、それらは、これらの通信するサービス・データを含めて、後続の通信のために安全なセッションをセットアップすることを可能にすることになるサービス加入を確立することを進める。

第２のアプローチに従って、ネットワーク・オペレータは、上記で説明されるように、デバイスのアイデンティティを取得する。しかしながら、明示的なページング・メッセージを送信する代わりに、オペレータは、汎用ビーコン・フレームをブロードキャストする。この汎用のブロードキャストされたビーコンは、その領域におけるすべての興味のあるデバイスに対してオペレータのサービス・エンティティの存在を知らせることになる。この点において、ビーコンは、１つの特定のデバイスを対象としてはいないが、そうではなくて、そのようなアナウンスを期待するブロードキャスト・エリアにおけるすべてのデバイスによって受信され、また理解される。このビーコンを用いて、アクセス・ネットワークは、ネットワーク・サービス・セッションを安全に確立しようと試みるように複数のデバイスをトリガする。

望ましいものは、正しいネットワークに対する所与のオープンなデバイスの取り付けである。一般的に、これは、所与のデバイスが１つまたは複数のビーコンを検査し、またいくつかの異なるオペレータのおのおのに関連付けるように試みた後に起こる。最終的には、デバイスは、正しいネットワーク・オペレータに出合い、またそれを用いて相互に認証することになる。これに続いて、デバイスと、ネットワークとは、サービス加入と、必要に応じてサービス・セッションとを確立するように進むことができる。

第３のアプローチに従って、オープンなデバイスは、適切なネットワーク・オペレータを識別する努力が、開始されているというアナウンスを送信する。そのようなアナウンスの受信のすぐ後に、そのエリアにおける１つまたは複数の使用可能なネットワークは、デバイスに対して明示的な招待を送信することができる。あらかじめ使えるように設定されたセキュリティ証明書を使用して、オープンなデバイスは、相互の認証を通して適切なネットワークを識別し、またその後に、そのオペレータに対してアタッチして、サービス加入またはサービス・セッションを確立することになる。

Ｍ２Ｍについての、ホテル発見問題を解決すべき３つの前述のアプローチについてのアプリケーション。このセクションにおいては、本発明者等は、マシン・ツー・マシン通信についての、Ｍ２ＭＯ発見の問題に対する３つの前述の関連付け戦略についての例示のアプリケーションを説明することになる。本発明者等は、Ｍ２Ｍデバイスが、Ｍ２ＭＯの発見および関連付けに関してさらなるアクションを起こす前に、アクティブ化のすぐ後にアクセス・ネットワークに正常に登録されることを仮定している。以下で説明されるべき例においては、Ｍ２ＭＯは、意図された行き先の役割を演じるが、Ｍ２Ｍデバイスは、ホテル発見問題に関連した訪問者の役割を担う。

一般に、アクセス・ネットワークは、望ましいＭ２ＭＯ、または望ましいＭ２Ｍデバイスに到達するための移送ネットワークとしてのサポートの役割を実行することになる。しかしながら、アクセス・ネットワークは、移送を提供するだけでなく、ここで説明されるようなＭ２ＭＯの機能をも担うというシナリオも存在することがある。例えば、この種の簡単なシナリオにおいては、（オープンな）クライアント・デバイスは、電子書籍リーダであり、この電子書籍リーダは、様々な電気通信サービス・プロバイダ（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒｓ）（ＴＳＰ）のうちのどれかのサービスを使用して書籍をダウンロードすることができる。バック・オフィス・サーバは、１つの特定のＴＳＰを選択し、このＴＳＰは、サービング・ネットワークとしての機能を果たすだけでなく、その後オンラインの書店からテキストのダウンロードを達成するためのＭ２Ｍオペレータとしての機能も果たす。

第１のアプローチに従って、Ｍ２ＭＯは、Ｍ２Ｍデバイスのアイデンティティと、関連したパラメータの組とを用いて使えるように設定された後に、明示的なＭ２Ｍサービス・レイヤの招待をＭ２Ｍデバイスに対して送信する。Ｍ２Ｍデバイスは、招待を受信し、またＭ２ＭＯを用いて相互に認証する。次いで、Ｍ２Ｍデバイスと、Ｍ２ＭＯとは、Ｍ２Ｍサービス加入の確立を進める。

第２のアプローチに従って、広告が、Ｍ２ＭＯからブロードキャストされる。これらの広告の目的は、それらの指定されたＭ２ＭＯを探し求めているデバイスを引きつけることである。そのような広告の受信のすぐ後に、Ｍ２Ｍデバイスは、加入要求をＭ２ＭＯに対して送信する。これは、相互認証を開始することができ、この認証は、もし成功するならば、Ｍ２ＭＯと、Ｍ２Ｍデバイスとの間のサービス加入の確立が、続いている可能性がある。

第３のアプローチに従って、Ｍ２Ｍデバイスは、ブロードキャスト・メッセージを通してＭ２ＭＯを識別すべきその意図を知らせる。Ｍ２ＭＯは、アナウンスを受信し、また明示的な招待をＭ２Ｍデバイスに対して送信することにより、応答する。招待は、どのようにしてサービス加入の確立を進めるべきかをＭ２Ｍデバイスに指示する情報を含んでいる。Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、正常な相互認証のすぐ後に加入を確立する。

広告における問題の実現に対する解決法
動機付けの例。第１のアプローチに従って、本発明者等は、製品を販売する会社が、製品を購入することに非常に興味を持つことになる特定の顧客について知っていることを仮定している。例えば、この種の情報は、顧客のトランザクション・データと、人口統計学データとに対して統計的方法を適用することにより、編集される可能性がある。高級車を広告しているローカルな自動車販売業者のリーフレットは、例えば、広く知られている高価な郊外地域において高価な家を所有する、見込みのある顧客を対象としている可能性がある。

第２のアプローチに従って、会社は、特定の顧客に対処しておらず、その代わりに、会社は、ブロードキャストする手段を使用して製品を広告している。例えば、新しいソフト・ドリンクについて興味を持つことになる多数の顧客は、テレビジョンのコマーシャルを通して通知される可能性がある。

第３のアプローチに従って、（１つまたは複数の会社によって提供される）特定の製品を購入することに興味のある顧客は、候補の会社が通知されるような方法でこの興味を知らせる。（一例は、新聞、公共的ウェブサイト、職業別電話帳などの上で、興味をポストすることである。）実際にそのようなアナウンスは、それが、高価な住宅などの項目についての購入など、他の振る舞いから推論できる可能性があるので、暗黙的である可能性がある。

自動化された環境に対するアプリケーション。電子的な広告が、ウェブ・ページの内部に埋め込まれたバナーの形で出現するオンライン広告の場合について考える。オンライン・ユーザが、ある種のリンクの上でクリックし、またはオンライン検索エンジンを使用して特定のストリングを検索するときはいつでも、そのようなアクションと、関連したデータとは、ネットワーク・オペレータと、広告エンティティとの間で監視され、また共用される。インテリジェントなソフトウェアは、ユーザの習慣と好みとをログ記録することができ、また特定のユーザに専用にされた広告を提供する際に使用するためにこの情報を処理することができる。

上記で説明されたアプローチのうちの第１のアプローチに従って、ある製品を販売することに興味がある会社は、その顧客またはユーザの習慣と好みとにマッチした広告を目に見えるようにすることにより、その特定の顧客またはユーザに対してその製品を広告する。

第２のアプローチに従って、会社は、すべての見込みのある顧客またはユーザに対してオンラインの広告をブロードキャストする。

第３のアプローチに従って、オンライン・ユーザは、ある種のリンクを意図的にクリックして、特定のタイプの製品についての広告を提供することにより応答するソフトウェア・メカニズムをトリガすることができる。これは、ユーザの振る舞い、すなわち、特定のリンクをクリックすることが、ユーザの興味と製品の必要性とについての暗黙のアナウンスを構成することができるという１つのシナリオであることに留意されたい。

例示のシステム・アーキテクチャ
ホテル発見問題を解決することに対する前述の３つのアプローチのおのおのが、どのようにしてＭ２Ｍの場合において適用され得るかについての分析を進める前に、本発明者等は、例示のサービス・レイヤ・アーキテクチャについての概説を提供する。アーキテクチャは、図３において挿し絵を用いて表されており、次にこの図３に対して注意が向けられる。ここで説明されるシステム・アーキテクチャは、Ｍ２Ｍ環境の特定の文脈で説明されているのに対して、当業者なら、ここで説明されるアイデアを他の環境に対しての簡単に拡張することができることが理解されよう。

図３に示されるように、Ｍ２ＭＯ１１０は、３つの基本的な機能エンティティ、すなわちＭ２Ｍデバイスのデバイス・アイデンティティとセキュリティ証明書とを記憶し、また登録されたデバイスのリストも記憶するＭ２Ｍ認証サーバおよびデータベース１２０（例えば、ＡＡＡサーバ）と、デバイスとＭ２ＭＯとの間で情報を通信するＭ２ＭＯサービス・エージェント１３０と、いくつかの異なる役割を有することができるアプリケーション・サーバ・エンティティ１４０とを含む。例えば、アプリケーション・サーバは、恒久的なセキュリティ・キーについてのパラメータを生成するＭ２Ｍデバイス１５０を用いてブートストラップ・オペレーションを実行することができ、またそれは、認証サーバに対してこれらのパラメータを伝えることができる。信頼されたプロビジョニング・エンティティ（ｔｒｕｓｔｅｄ ｐｒｏｂｉｓｉｏｎｉｎｇ ｅｎｔｉｔｙ）（ＴＰＥ）１６０は、認証サーバに対してＭ２Ｍデバイス証明書を使えるように設定する。そのような証明書は、デバイスに対して招待を送信するために、ならびに加入要求をセキュリティ保護されるように受け入れるために、Ｍ２ＭＯによって使用される。この点については、デバイスと、Ｍ２ＭＯとの間のどのような情報交換もＭ２ＭＯサービス・エージェントを通して進むことに留意されたい。

当業者によって理解されるように、認証サーバは、一般的に、標準的な１Ｕサーバ、またはサーバのクラスタの上で実行される。もちろん、在庫があってすぐに入手可能なサーバから、特注で構築された使用可能性の高いＡＴＣＡハードウェア・プラットフォーム（これは、例えば、高いトランザクション量が存在するネットワークのために有用であり得る）までのデバイスの範囲を含めて、多数の代替案が可能である。サービス・エージェントは、一般的に、適切なプラットフォームの上で実行されるソフトウェアの形で実装される。アプリケーション・サーバをサポートすることができるデバイスの範囲は、認証サーバをサポートすることができる範囲に類似している。しかしながら、一般的なルールとして、データ・センタ・サーバ・ハードウェアが、認証サーバと、アプリケーション・サーバとをサポートするためには好ましい。

次に、上記で論じられた一般的なアプローチのそれぞれを、Ｍ２Ｍ通信にどのように適用できるかについての一例について説明する。

第１のアプローチ：Ｍ２ＭＯは、Ｍ２Ｍデバイスに対して明示的な招待を送信する。このアプローチは、Ｍ２ＭＯからＭ２Ｍデバイスへと送信される明示的な招待メッセージを必要とする。より具体的には、在庫があってすぐに入手可能に購入され、また初めてアクティブにされるＭ２Ｍデバイスは、どのＭ２ＭＯに関連付けられることになっているか知らない。低コストＭ２Ｍデバイスは、ユーザ・インターフェースを有していない可能性があり、このユーザ・インターフェースからそのような情報を得ることができる可能性があることを思い出して欲しい。

Ｍ２ＭＯが、Ｍ２Ｍデバイスの存在と、Ｍ２Ｍサービスについて関連付けるべきその意図とについて通知されるとすぐに、Ｍ２ＭＯは、Ｍ２Ｍ招待を構築し、またそれをデバイスに対して送信することになる。Ｍ２ＭＯが、デバイスの存在について知るようになることができる様々な典型的なプロシージャが存在している。一例においては、デバイスの、または関連のあるＭ２Ｍアプリケーション・プロバイダの所有者は、Ｍ２ＭＯに（直接に、またはサード・パーティを通してのいずれかで）連絡を取り、また（以下で考察されるべき）パラメータのオプションの組と一緒にデバイスのアイデンティティを提供する。図３の例示のアーキテクチャに関して、ＴＰＥは、Ｍ２ＭＯに対して（また具体的には、認証サーバ・データベースに対して）そのような情報を使えるように設定するタスクが割り当てられる。

このアプローチに従って、Ｍ２ＭＯは、特定のＭ２Ｍデバイスに明示的に向かうようになっているＭ２Ｍ招待（ホテル発見問題についての本発明者等のステートメントにおける空港へ送られた代理人に類似している）を送信することによりデバイスを明示的にトリガすることになる。そのような招待は、本発明者等が後で説明することになるパラメータの組と一緒に、Ｍ２ＭＯアイデンティティと、Ｍ２Ｍデバイス・アイデンティティとを示す、アプリケーション・レイヤ・ページング・メッセージとして考えられる可能性がある。

上記プロシージャのステップは、図４に図示され、また以下でより詳細に説明される。

１．ＴＰＥは、Ｍ２Ｍデバイス・アイデンティティについて知っており、またデバイス・アタッチメント・プロセスに関連しており、また以下に続く特定のアタッチメント・プロセスに特有である１組の証明書とパラメータとを含めて、Ｍ２ＭＯに対して（具体的に認証サーバ・データベースに対して）デバイスについてのブランド提携と、アイデンティティとを使えるように設定する。ＴＰＥは、例えば、製造業者から、またはウェブ・インターフェースを通してＭ２Ｍデバイスのユーザまたは所有者によって入力されるデータから、この情報を取得している可能性がある。その情報を獲得するための他の可能性のある手段は、当業者には簡単に明らかになろう。デバイス・アイデンティティは、例えば、デバイスのＭＡＣアドレスによって、電子的シリアル番号によって、または製造中にデバイスに対してあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。

ちょうど、デバイスについての識別する情報がＴＰＥに対して伝えられる可能性があるように、期待されたデバイス・ロケーションもまた、伝えられる可能性があることが理解されよう。それは、Ｍ２ＭＯとデバイスとの間のより焦点の合わされた領域的に制限された通信を潜在的に可能にするので、これは、有利である可能性がある。

２．Ｍ２ＭＯは、今や、Ｍ２Ｍデバイスが、関連付けとさらなるサービス登録とについての招待を進んで受け入れることを知っている。Ｍ２ＭＯが、アクセス・ネットワーク・アタッチメントの論理ロケーションに関する（近似の、または明示的な）情報を用いて使えるように設定される場合、Ｍ２ＭＯは、明示的なＭ２Ｍ招待メッセージ１７０をそのロケーションに向かって方向づけることができる。そうでなければ、Ｍ２ＭＯは、招待をブロードキャストすることができる。Ｍ２ＭＯが、あらかじめ定義された時間間隔内においてＭ２Ｍデバイスからの応答を受信するか否かに応じて、それは、応答が受信されるまで、招待の伝送を反復することができる。Ｍ２ＭＯが、複数のＭ２Ｍデバイスを招待したいと望む場合に、Ｍ２Ｍ招待メッセージは、有利に、特定のエリアの中に横たわる可能性があるすべての招待されたデバイスについてのアイデンティティを有するリストを含むことに留意されたい。そのような場合には、Ｍ２Ｍデバイスは、単に応答をＭ２ＭＯに対して送信する前にそのアイデンティティがリストの中に含まれるかどうかを決定する必要がある。

３．Ｍ２Ｍデバイスは、アクティブにされ、またアクセス・ネットワークに登録する。デバイスは、今や、Ｍ２Ｍサービス加入についての招待を受け取ることができる。Ｍ２Ｍデバイスが、明示的なＭ２Ｍ招待だけに応答するようにオプションを用いてあらかじめ構成されている場合、デバイスは、特定のデバイス・アイデンティティを含むＭ２Ｍ招待メッセージに対してだけ応答することになる。そのような招待を受信するとすぐに、デバイスは、Ｍ２Ｍ加入要求１８０を用いて対応するＭ２ＭＯに対して応答することになる。

４．Ｍ２ＭＯは、加入要求を受信する。Ｍ２ＭＯと、Ｍ２Ｍデバイスとの間の正常な相互認証１９０のすぐ後に、Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、加入２００を相互に確立することになる。このプロシージャのある種の態様については、以下でより詳細に説明されよう。

上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ１つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。

第２のアプローチ：Ｍ２ＭＯは、すべての興味のあるＭ２Ｍデバイスに対して広告をブロードキャストする。この場合には、Ｍ２ＭＯは、どのような明示的な招待も送信しないが、それは、どのＭ２Ｍデバイスが、Ｍ２ＭＯを識別したいと、またそれに関連付けたいと望むかについて知っている。代わりに、Ｍ２ＭＯは、一般的な（アプリケーション・レベルの）アナウンス、または広告メッセージを定期的にブロードキャストすることもでき、このメッセージは、ホテル発見問題についての本発明者等のステートメントにおける「ピックアップ・バン」に類似している。ブロードキャスティングの頻度は、オペレータのポリシーに依存している。そのような定期的な広告を用いて、Ｍ２ＭＯは、その存在についてデバイスに通知するように要求し、その結果、デバイスは、Ｍ２ＭＯについて知るようになり、またそれに関連付けようと試みる可能性がある。明らかに、Ｍ２ＭＯは、それが、既にそれらを用いて使えるように設定されているので、そのアイデンティティがＭ２ＭＯに知られているＭ２Ｍデバイスからの加入要求だけを受け入れることになる。

このアプローチによるステップのシーケンスが、図５に示され、また以下でより詳細に説明される。

１．第１のアプローチにおけるように、ＴＰＥは、デバイス証明書を用いて、またデバイス・アタッチメント・プロセスに関連しており、また以下に続く特定のアタッチメント・プロセスに特有のパラメータの組を用いて、Ｍ２ＭＯを使えるように設定する。ＴＰＥは、製造業者から、ウェブ・インターフェースを通してＭ２Ｍデバイスのユーザまたは所有者によって入力されるデータから、あるいは他のソースからそのような情報を取得することができる。アイデンティティは、例えば、デバイスのＭＡＣアドレスによって、電子的シリアル番号によって、または製造中にデバイスにあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。

２．Ｍ２ＭＯは、Ｍ２Ｍデバイスのアイデンティティのリストを用いて使えるように設定される。Ｍ２ＭＯは、１つまたは複数のＭ２Ｍデバイスが、加入関連付けをまだ確立していないこのリストの上に留まっている限り、Ｍ２Ｍ広告２１０を定期的にブロードキャストする。このアプリケーション・レベルの広告は、Ｍ２ＭＯのアイデンティティと、場合によっては１組のさらなるパラメータとを含む。Ｍ２ＭＯが、Ｍ２Ｍデバイスが１つまたは複数のアクセス・ネットワークに、アタッチされる可能性がある場合の近似的な論理的ロケーションについて知っている場合、Ｍ２Ｍ広告の伝送と転送とは、ある種の論理領域だけに限定される可能性がある。代わりに、Ｍ２ＭＯは、１つまたは複数のアクセス・ネットワークを広告で「氾濫させる」ように決定することができる。

３．Ｍ２Ｍデバイスは、広告を受信し、それを処理し、またＭ２Ｍデバイスが、Ｍ２Ｍサービスに対する加入プロセスを開始しようと試みるべきかどうかを決定する。Ｍ２Ｍデバイスは、広告の中に含まれるある種のパラメータに、また同様にインストール中にデバイスの中へとあらかじめ使えるように設定されているある種のパラメータ値に、この決定の基礎を置くことができる。（あらかじめ使えるように設定され得るパラメータの一例は、提供されるサービスのタイプである。）デバイスが、広告されたＭ２ＭＯが加入についての候補であることを決定する場合、デバイスは、Ｍ２Ｍ加入要求２２０に応答する。

４．Ｍ２ＭＯは、加入要求を受信する。Ｍ２ＭＯとＭ２Ｍデバイスとの間の正常な相互認証２３０のすぐ後に、Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、加入２４０を相互に確立する。このプロシージャのある種の態様については、以下でさらに詳細に説明される。

上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ１つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。

第３のアプローチ：Ｍ２Ｍデバイスは、Ｍ２ＭＯを見出すことにおけるその興味を知らせる。第３のアプローチは、適切なＭ２ＭＯを識別し、また適切なＭ２ＭＯに関連付けるべきその意図をＭ２Ｍデバイスに広告させることにより実現される。この場合には、Ｍ２ＭＯは、Ｍ２Ｍデバイスに起源を有する広告の受信を受動的に待つ。そのような広告の受信と処理とのすぐ後に、Ｍ２ＭＯは、デバイスに連絡を取り、またそれとの関連付けを確立しようと試みる。

このアプローチによるステップのシーケンスが、図６に示されており、また以下でより詳細に説明される。

１．ＴＰＥは、デバイス証明書を用いて、またデバイス・アタッチメント・プロセスに関連しており、また以下に続く特定のアタッチメント・プロセスに特有であるパラメータの組を用いてＭ２ＭＯを使えるように設定する。ＴＰＥは、製造業者から、ウェブ・インターフェースを通してＭ２Ｍデバイスのユーザまたは所有者によって入力されるデータから、あるいは他のソースからそのような情報を取得することができる。デバイス・アイデンティティは、例えば、デバイスのＭＡＣアドレスによって、電子的シリアル番号によって、または製造中にデバイスに対してあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。

２．Ｍ２Ｍデバイスが、アクティブにされ、またアクセス・ネットワークに登録されるとすぐに、デバイスは、Ｍ２Ｍデバイス導入メッセージ（Ｍ２Ｍ ｄｅｖｉｃｅ ｉｎｔｒｏｄｕｃｔｉｏｎ ｍｅｓｓａｇｅ）２５０の定期的ブロードキャストを開始し、このＭ２Ｍデバイス導入メッセージは、デバイスのアイデンティティを含んでいる。

３．Ｍ２Ｍ導入メッセージは、１つまたは複数のＭ２Ｍオペレータに到達し、このＭ２Ｍオペレータは、メッセージを処理し、またＭ２Ｍデバイスに連絡を取るべきか否かを決定する。一般に、１つのＭ２ＭＯは、それが既にあらかじめ使えるように設定されているときに用いるものとしてＭ２Ｍ導入広告の中に含まれるアイデンティティを認識することになる。そのＭ２ＭＯは、明示的なＭ２Ｍ招待メッセージをデバイスに対して送信する。この招待メッセージは、第１のアプローチに関連して上記で考察されたＭ２Ｍ招待メッセージに類似している。

４．明示的なＭ２Ｍ招待メッセージ２６０の受信のすぐ後に、デバイスは、Ｍ２Ｍ加入要求２７０で対応するＭ２ＭＯに応答する。

５．Ｍ２ＭＯは、加入要求を受信する。Ｍ２ＭＯと、Ｍ２Ｍデバイスとの間の正常な相互認証２８０のすぐ後に、Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、加入２９０を相互に確立する。このプロシージャのある種の態様は、以下でさらに詳細に考察される。

上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ１つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。

すべての３つのアプローチについてのサポート。デバイスとＭ２ＭＯ装置とについてのあらかじめ構成されたソフトウェアとオペレーションのモードとに応じて、Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、個々に、または平行な組合せにおいてのいずれかで、上記で説明される３つのアプローチのおのおのに従ってオペレーションをアクティブにすることができる。アプローチの平行な組合せにおけるオペレーションの場合には、Ｍ２Ｍデバイスは、３つのアプローチのうちのどれにも従ってＭ２ＭＯに起源を発するメッセージを処理し、また応答することができる。同様に、Ｍ２ＭＯは、アプローチのうちのどれにも従って、明示的な招待と、定期的な広告との両方を送信することができる。

デバイスの加入確立。Ｍ２Ｍサービスの加入確立は、Ｍ２ＭデバイスからＭ２ＭＯへのＭ２Ｍ加入要求メッセージの伝送の後に、またＭ２ＭＯと、Ｍ２Ｍデバイスとの間の相互認証の後に、開始される。（以下で説明されるように、相互認証は、一般的に、一時的なパスワードを使用して達成されることになる。）加入確立プロシージャは、図７において示されており、この図に対して、次に注意が向けられる。

加入確立のプロセスは、いくつかのプロセスを含んでいる。１つの構成要素となるプロセスは、サービス登録のために使用されるべき恒久的なセキュリティ証明書のブートストラッピングである。別の可能性のある構成要素となるプロセスは、サービス加入に関連したある種のパラメータについての合意した値の設定である。

加入確立プロシージャは、Ｍ２Ｍデバイスと、Ｍ２ＭＯに属するブートストラップ機能エンティティ（例えば、適切なサーバ）との間で実行される。例えば、ブートストラップ機能エンティティは、例えば、図３において見られるようなアプリケーション・サーバとすることができ、このアプリケーション・サーバは、Ｍ２Ｍ認証サーバに対して相互に生成された恒久的なセキュリティ証明書をセキュリティ保護されるように通信する。

Ｍ２ＭデバイスとＭ２ＭＯとが、相互認証３００の後に加入確立を進めることを決定する場合、Ｍ２Ｍデバイスは、図７に示されるように、Ｍ２Ｍサービス・ブートストラップ要求３１０をＭ２ＭＯに対して送信する。Ｍ２ＭＯは、Ｍ２Ｍサービス・ブートストラップ応答３２０をＭ２Ｍデバイスに対して送信することによって、応答する。このメッセージの正常な受信のすぐ後に、Ｍ２Ｍデバイスは、Ｍ２Ｍサービス・ブートストラップ完了３３０をＭ２ＭＯに対して送信し、このＭ２ＭＯは、加入ハンドシェイクを終了させる。Ｍ２Ｍデバイスと、Ｍ２ＭＯとの間のこの３ステップのハンドシェイクは、セキュリティ証明書をブートストラップするための様々なプロトコルのうちのどれでも容易にすることができる。適切なそのようなプロトコルは、とりわけ、ＩＢＡＫＥと、ＰＡＫと、証明書に基づいた加入確立とを含む。

ブートストラップした後に、Ｍ２ＭＯは、オプションとして、検証メッセージ３４０をＭ２Ｍデバイスに対して送信することができる。次いで、Ｍ２Ｍデバイスは、恒久的なセキュリティ証明書についての正常なブートストラップを肯定応答する３５０。Ｍ２ＭＯは、サービス登録パラメータを含むメッセージ３６０を用いて肯定応答メッセージに対して応答することができる。

一般に、サービス・パラメータと加入パラメータとは、アプリケーションに依存している。Ｍ２Ｍアプリケーションとして、ユーティリティ・メータで計ることについての特定の例を例証として取ると、パラメータは、（限定することなく）、恒久的アイデンティティと、グループ・アイデンティティと、ホスト・サーバ・アイデンティティと、デバイスからの伝送のための周波数およびタイム・スロットと、管理インターフェースについてのブロードキャスト・パラメータとを含むことができる。

セキュリティの考慮。Ｍ２Ｍデバイスのアイデンティティは、ただ１つの合法的なＭ２ＭＯに対してあらかじめ使えるように設定されており、この合法的なＭ２ＭＯは、それに応じてＭ２Ｍ加入要求に応答することが、Ｍ２ＭＯ識別技法と加入確立技法との上記考察において仮定されている。さらに、加入確立の前に、また加入確立中に続けられるべきある種のセキュリティ・プロシージャにより、Ｍ２Ｍデバイスは、候補のＭ２ＭＯが、合法的であるかどうかと、候補のＭ２ＭＯが、サービス加入についての適切なＭ２ＭＯであるかどうかとを決定することができるようになる可能性がある。それが、「適切な」Ｍ２ＭＯであるかどうかは、そのアイデンティティと、相互認証の成功とに基づいて決定される。

Ｍ２Ｍデバイスは、それが、Ｍ２ＭＯのアイデンティティを検証する場合だけに、加入を確立すること、およびサービスについて登録することに合意することになり、それによってそれが、面倒を起こすＭ２ＭＯではないことを保証している。同様に、Ｍ２ＭＯは、加入確立を進める前にＭ２Ｍデバイスの証明書を最初に検証する必要がある。

必要とされる検証を実行する１つのやり方は、Ｍ２Ｍデバイスのアイデンティティに関連する一時的なパスワードを使用する。このパスワードは、オフライン・ステップ中に、Ｍ２Ｍデバイスと、Ｍ２ＭＯとの両方に対して使えるように設定される。より具体的には、一時的なパスワードは、製造中にＭ２Ｍデバイスに対してあらかじめ使えるように設定される。デバイスの初期アクティブ化の前に、パスワードは、Ｍ２Ｍデバイスのアイデンティティと一緒に、Ｍ２ＭＯに対してＴＰＥによって（オフラインで）使えるように設定される。（ＴＰＥは、デバイス製造業者から、または他のソースから、パスワードと識別情報データとを取得することができる。）

Ｍ２ＭＯと、Ｍ２Ｍデバイスとは、一時的なパスワードを使用して、加入確立の前に互いに相互に認証することができる。様々な知られている認証プロシージャのうちの任意のものが、認証オペレーションのために使用される可能性がある。１つのそのようなプロシージャは、例えば、第３世代パートナーシップ・プロジェクト、３ＧＰＰ技術仕様３ＧＰＰ ＴＳ ３３．１０２ Ｖ９．０．０：Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｓｙｓｔｅｍ Ａｓｐｅｃｔｓ；３Ｇ Ｓｅｃｕｒｉｔｙ；Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ、２００９年９月において説明されるＡＫＡ（認証およびキー合意（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ））プロトコルである。

適切な認証プロシージャとともに一時的なパスワードを使用して、Ｍ２Ｍデバイスは、Ｍ２ＭＯが、正しいものであることを保証することができる。認証プロシージャはまた、他のＭ２ＭオペレータがＭ２Ｍデバイスを意図的に引きつける不正な実行を行うことから思いとどまらせて、それを拒絶、すなわち適切なＭ２ＭＯに関連付ける機会を拒絶する。

この点において、一時的なパスワードに基づいた認証は、ただの一例にすぎないこと、および様々な代替案もまた使用される可能性があることに留意されたい。

例えば、１つの代替案は、Ｍ２ＭＯによって生成され、またＭ２Ｍデバイスのアイデンティティを用いてＩＢＥ−暗号化されたワン・タイム・パッド（Ｏｎｅ Ｔｉｍｅ Ｐａｄ）である。Ｍ２Ｍデバイスは、ワン・タイム・パッドを暗号解読し、またそれをＭ２ＭＯに対して戻し、このようにしてＭ２ＭＯに対してＯＴＰを暗号解読するその能力を立証し、またそれによってＭ２ＭＯに対してそれ自体を認証している。ＯＴＰの考察のためには、Ｎ．Ｈａｌｌｅｒ他、Ａ Ｏｎｅ−Ｔｉｍｅ Ｐａｓｓｗｏｒｄ Ｓｙｓｔｅｍ、ＲＦＣ２２８９、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２８９．ｔｘｔを参照されたい。

別の代替的プロシージャにおいては、Ｍ２Ｍデバイスは、パスワードを保持し、またＭ２ＭＯに対してそれ自体を認証するためのＣＨＡＰ ＰＷについてのダイジェストとしてそれを使用する。ＣＨＡＰ ＰＷの考察のためには、Ｗ．Ｓｉｍｐｓｏｎ、ＰＰＰ Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣＨＡＰ）、ＲＦＣ １９９４、ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１９９４．ｈｔｍｌを参照されたい。

理想的なトランザクションにおいては、合法的な、また欠陥のないＭ２ＭＯは、そのアイデンティティが、Ｍ２ＭＯに対して既に知られているＭ２ＭデバイスからのＭ２Ｍ加入要求だけに応答する。合法的なＭ２ＭＯは、知られていないデバイスを用いてサービス加入を確立しようと試みることにより、ビジネスに関連した利点を獲得することにならないので、合法的なＭ２ＭＯは、そのアイデンティティが、先験的に使えるように設定されていないすべてのＭ２Ｍデバイスからの加入要求を（理想的に）無視し、または拒絶することになる。

正常な相互認証のすぐ後に、ＩＢＡＫＥやＰＡＫなどのセキュリティ・プロトコルを呼び出すことがなぜ有利であるかという以下の理由を指摘しておくが、すなわちこれらのプロトコルは、確立された恒久的なキーが、Ｍ２Ｍデバイスと、Ｍ２ＭＯとだけに知られることを保証する。とりわけ、ＴＰＥおよびデバイス製造業者は、恒久的なブートストラップされたキーについて学習しない。

メッセージ内容およびフォーマット
以下で、Ｍ２ＭＯ発見フェーズの間に、Ｍ２ＭＯとＭ２Ｍデバイスとの間で交換されるメッセージのために使用され得るフォーマットの例を提供する。

（１）Ｍ２Ｍ招待：このメッセージは、以下の２つの場合においてＭ２ＭＯからＭ２Ｍデバイスへと送信される。

（ａ）Ｍ２ＭＯは、デバイスのアイデンティティについて知っており、またそれゆえにそれは、デバイスに対して（またはデバイスのリストに対して）明示的なＭ２Ｍ招待を積極的に送信する。

（ｂ）Ｍ２ＭＯは、Ｍ２ＭデバイスからＭ２Ｍデバイス導入メッセージ（下記参照）を受信し、またそのデバイスに対して（またはデバイスのリストに対して）Ｍ２Ｍ招待を用いて応答する。

例示のＭ２Ｍ招待メッセージ・データグラムは、図８に示されるように構築される。例証された構造は、例えば、ＴＣＰ／ＵＤＰ／ＩＰパケットの中のペイロードとして埋め込まれる可能性がある。Ｍ２Ｍ招待は有利には、他の通信パラメータのうちでも以下の情報を含む。

バージョン：このパケットについてのアプリケーション・レイヤ・プロトコル・バージョンを指定するためのもの。

タイプ：このパケットについてのタイプ、例えば、「Ｍ２Ｍ＿招待（Ｍ２Ｍ＿ＩＮＶＩＴＡＴＩＯＮ）」を指定するためのもの。

Ｍ２ＭＯアイデンティティ：採用される特定の規格（単数または複数）によって定義されるように、Ｍ２Ｍオペレータを識別するためのもの。

優先順位：このメッセージについての送信する優先順位をオプションとして示すためのもの。

カウントＩＤ：このメッセージに含まれる（招待が向かうことになっている）Ｍ２Ｍデバイス・アイデンティティの数を識別するためのもの。

認証タイプ：この招待を受信するＭ２Ｍデバイス（単数または複数）が、Ｍ２ＭＯが合法的であることを検証することができる認証方法を示すためのもの。知られていない認証タイプを有するパケットが、Ｍ２Ｍデバイスによって切り捨てられるべきである。

招待間隔：招待の間の時間間隔をオプションとして識別するためのもの。誤って構成されたＭ２Ｍデバイスを有するある種の場合は、この値を必要とする可能性があり、それは、サービス拒否攻撃に対する対抗手段として使用される可能性もある。

チェックサム：Ｍ２Ｍ招待メッセージの中のデータの破損を検出する際に受信デバイスを支援するためのもの。チェックサムに関連した知られている実行についての説明は、例えば、Ｒ．Ｂｒａｄｅｎ他、ＲＦＣ １０７１、Ｃｏｍｐｕｔｉｎｇ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｃｈｅｃｋｓｕｍ、ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１０７１．ｈｔｍｌにおいて見られる。

Ｍ２Ｍデバイス・アイデンティティ（ｘ）：Ｍ２ＭＯが、引きつけようとする意図されたＭ２Ｍデバイス受信側を識別するためのもの。アイデンティティのリストは、Ｍ２ＭＯがこのメッセージを通して到達したいと望むすべてのデバイスについてのＭ２Ｍ招待に含まれる可能性がある。Ｍ２Ｍデバイスの初期のアクティブ化中のロケーション情報についての使用可能性に応じて、異なる（同時の可能性がある）Ｍ２Ｍ招待（異なるロケーションに向かって転送される）は、Ｍ２Ｍデバイス・アイデンティティの異なるリストを含むことができる。

Ｍ２Ｍサービス・パラメータ：加入に先立ってＭ２Ｍデバイスにとって有用な可能性がある予備パラメータをオプションとして識別するためのもの。一例として、フィールドは、提供されるＭ２Ｍサービスのタイプに関する情報などを含むことができる。

認証データ：Ｍ２Ｍデバイスが、招待を送信するＭ２ＭＯのアイデンティティを検証することができる認証方法とパラメータとに関する、認証タイプ・フィールドに関連した情報を含むためのもの。

（２）Ｍ２Ｍ広告：このメッセージは、Ｍ２ＭＯから定期的に送信され、それは、ブロードキャストの性質であり、またどのような特定のＭ２Ｍデバイスにも特に対処してはいない。

例示のＭ２Ｍ広告メッセージ・データグラムが、図９に示されるように構築される。

Ｍ２Ｍ広告メッセージは、バージョンと、タイプと、Ｍ２ＭＯアイデンティティと、優先順位と、認証タイプと、広告間隔と、チェックサムと、認証データと、他のＭ２Ｍサービス・パラメータとを含むことができる。

上記のメッセージは、ＴＣＰ／ＵＤＰ／ＩＰパケットの中へとペイロードとして埋め込まれる可能性がある。構造を構成するフィールドは、Ｍ２Ｍ招待メッセージのフィールドに類似している。しかしながら、広告は、特にどのようなＭ２Ｍデバイスにも明示的に向かうことになっていないので、メッセージは、どのようなＭ２Ｍデバイス・アイデンティティ、またはカウントＩＤフィールドも含んでいない。代わりに、Ｍ２Ｍ招待のデータグラム・フォーマットは、ここで再使用される可能性があり、そこでは、タイプ・フィールドは、これがＭ２Ｍ広告であることを指定することになり、カウントＩＤ値は、ゼロという「デフォルト」値に設定されることになるが、Ｍ２Ｍデバイス・アイデンティティ・フィールド（単数または複数）は、ヌル（ＮＵＬＬ）に設定されることにもなり、これがブロードキャスト・メッセージであることを示している。

（３）Ｍ２Ｍデバイス導入：Ｍ２Ｍデバイス導入は、アクセス・ネットワークに登録するとすぐに、Ｍ２Ｍデバイスに起源を発するブロードキャスト・メッセージである。このメッセージは、１つまたは複数の候補のＭ２Ｍオペレータに到達するその試みにおいて、Ｍ２Ｍデバイスによって使用される。例示のＭ２Ｍデバイス導入メッセージ・データグラムは、図１０に示されるように構成される。

Ｍ２Ｍデバイス導入メッセージは、バージョンと、タイプと、Ｍ２Ｍデバイス・アイデンティティと、優先順位と、認証タイプと、伝送間隔と、チェックサムと、認証データと、他のＭ２Ｍサービス・パラメータとを含むことができる。

上記のメッセージは、ＴＣＰ／ＵＤＰ／ＩＰパケットの中へとペイロードとして埋め込まれる可能性がある。構造は、Ｍ２Ｍ広告メッセージの構造に類似している。ただ１つの違いは、Ｍ２Ｍデバイス・アイデンティティ・フィールドが、Ｍ２ＭＯアイデンティティ・フィールドを置き換えていることである。（しかしながら、Ｍ２Ｍデバイス導入メッセージは、Ｍ２Ｍ広告メッセージの中で使用されることになるＭ２Ｍサービス・パラメータとは異なるＭ２Ｍサービス・パラメータを−または異なるパラメータ値を−含むことができることに留意されたい。）この場合にもやはりここでも、代わりにＭ２Ｍ招待のデータグラム・フォーマットは、ここで再使用される可能性があり、そこではタイプ・フィールドは、これがＭ２Ｍデバイス導入であることを指定することになり、Ｍ２Ｍデバイス・アイデンティティは、Ｍ２ＭＯアイデンティティを置き換えることになり、カウントＩＤ値は、ゼロという「デフォルト」値に設定されることになるが、Ｍ２Ｍデバイス・アイデンティティ・フィールド（単数または複数）は、ヌルに設定されることにもなり、これが、ブロードキャスト・メッセージであることを示している。

ここで説明される方法は、Ｍ２Ｍ環境をサポートする任意のネットワークの上の実装のために適していることが理解されよう。そのようなネットワークは、固定されていても、ワイヤレスでも、または固定されたものとワイヤレスとの組合せであってもよい。ここで説明されるように、本発明者等の方法は、とりわけ、プロトコルのＩＰスイートによるパケット通信をサポートするネットワークに対して適用可能であるが、本発明者等の方法は、その種のネットワークだけに用途が限定されてはいない。さらに、「サーバ」は、その用語がここで使用される場合、ネットワーク・インターフェースを有する任意の適切なコンピューティング・マシンの上で実行され得るソフトウェア機能であり、そのようなマシンは、例えば、汎用または専用のデジタル・コンピュータ、あるいは一連のそのようなコンピュータとすることができることが、理解されよう。

Claims (6)

1. ネットワーク・エンティティによって実行されるべき方法であって、
   サービスについて認可されたクライアント・エンティティに代わって、サーバからの通信において識別子を受信するステップと、
   前記クライアント・エンティティからのメッセージの、指定されない時刻における到着を識別する際に使用するために、前記識別子をデジタル・ストレージ媒体に自動的に記憶するステップと、
   前記クライアント・エンティティからデジタル通信を受信するステップであって、前記クライアント・エンティティ通信は、前記識別子を含んでおり、また前記クライアント・エンティティが、通信ネットワークに参加していることを示す、受信するステップと、
   前記クライアント・エンティティ通信を受信する前に、または受信した後に、前記サービスを提供するための協力パーティとして、前記クライアント・エンティティに対する前記ネットワーク・エンティティを発見するステップであって、前記通信ネットワークの上で少なくとも１つのメッセージを自動的に生成し送信することにより実行される、発見するステップと、
   前記クライアント・エンティティ通信を受信した後に、前記クライアント・エンティティ通信において受信された前記識別子が、前記サーバ通信において受信された前記識別子とマッチするという条件で、一連の自動化ステップを通して前記クライアント・エンティティを認証するステップと、
   前記クライアント・エンティティとの恒久的なセキュリティ関連付けを確立するステップと、
   前記クライアント・エンティティへの前記サービスを開始するステップと
   を備える方法。
2. 前記発見するステップは、前記クライアント・エンティティ通信を受信する前に、前記クライアント・エンティティを識別する情報を含む複数の反復メッセージを前記通信ネットワークの上で送信することによって実行される、請求項１に記載の方法。
3. 前記複数の反復メッセージは、複数のクライアント・エンティティに対して送信される、請求項２に記載の方法。
4. 前記複数の反復メッセージは、単一のクライアント・エンティティに対して送信される、請求項２に記載の方法。
5. 前記発見するステップは、前記クライアント・エンティティ通信を受信するステップに応じて実行される、請求項１に記載の方法。
6. 前記ネットワーク・エンティティは、マシン・ツー・マシン・オペレータであり、また前記クライアント・エンティティは、マシン・ツー・マシン・デバイスである、請求項１に記載の方法。

Images