ネットワークエンティティによって実行されるべき方法であって、サービスについて認可されたクライアントエンティティに代わって、サーバからの通信において識別子を受信するステップと、前記クライアントエンティティからのメッセージの、指定されない時刻における到着を識別する際に使用するために、前記識別子をデジタルストレージ媒体に自動的に記憶するステップと、前記クライアントエンティティからデジタル通信を受信するステップであって、前記クライアントエンティティ通信は、前記識別子を含んでおり、また前記クライアントエンティティが、通信ネットワークに参加していることを示す、受信するステップと、前記クライアントエンティティ通信を受信する前に、または受信した後に、前記サービスを提供するための協力パーティとして、前記クライアントエンティティに対する前記ネットワークエンティティを発見するステップであって、前記通信ネットワークの上で少なくとも1つのメッセージを自動的に生成し送信することにより実行される、発見するステップと、前記クライアントエンティティ通信を受信した後に、前記クライアントエンティティ通信において受信された前記識別子が、前記サーバ通信において受信された前記識別子とマッチするという条件で、一連の自動化ステップを通して前記クライアントエンティティを認証するステップと、前記クライアントエンティティとの恒久的なセキュリティ関連付けを確立するステップと、前記クライアントエンティティへの前記サービスを開始するステップとを備える方法。前記発見するステップは、前記クライアントエンティティ通信を受信する前に、前記クライアントエンティティを識別する情報を含む複数の反復メッセージを前記通信ネットワークの上で送信することによって実行される、請求項1に記載の方法。前記複数の反復メッセージは、複数のクライアントエンティティに対して送信される、請求項2に記載の方法。前記複数の反復メッセージは、単一のクライアントエンティティに対して送信される、請求項2に記載の方法。前記発見するステップは、前記クライアントエンティティ通信を受信するステップに応じて実行される、請求項1に記載の方法。前記ネットワークエンティティは、マシンツーマシンオペレータであり、また前記クライアントエンティティは、マシンツーマシンデバイスである、請求項1に記載の方法。本願は、そのような方法を提供するものである。一実施形態においては、ネットワークエンティティは、サービスについて認可されたクライアントエンティティに代わって、サーバからの通信において識別子を受信する。ネットワークエンティティは、クライアントエンティティからのメッセージの、指定されない時刻における到着を識別する際に使用するために、その識別子をデジタルストレージ媒体に自動的に記憶する。ある時点において、ネットワークエンティティは、クライアントエンティティからデジタル通信を受信する。デジタル通信は、識別子を含んでおり、またクライアントエンティティが、通信ネットワークに参加していることを示す。クライアントエンティティ通信を受信する前に、または受信した後に、ネットワークエンティティは、サービスを提供するための協力パーティとして、クライアントエンティティに対して身元を明らかにする。クライアントエンティティに対して身元を明らかにするために、ネットワークエンティティは、通信ネットワークの上で少なくとも1つのメッセージを自動的に生成し、また送信する。クライアントエンティティ通信を受信した後のある時点で、ネットワークエンティティは、クライアントエンティティからのデジタル通信において受信された識別子が、サーバ通信において受信された識別子とマッチするという条件で、一連の自動化ステップを通してクライアントエンティティを認証する。次いで、ネットワークエンティティは、クライアントエンティティとの恒久的なセキュリティ関連付けを確立し、またクライアントエンティティへのサービスを開始する。本発明のアプローチの1つの利点は、nを宛先ネットワークまたはサーバエンティティの数として、全数探索は、Onという最悪ケースの複雑さを有するが、本発明のアプローチの複雑さは、かなり低減されており、また一定の時間内に実行されるすなわち、O1であるということである。包括的な自動化された通信環境ホテル発見問題は、図1に示される通信環境など、自動化された通信環境に対して直接に適用可能である。この包括的な設定において、互いに安全に接続するように試みるN個のクライアントエンティティ10の組とM個のサーバエンティティ20の組について考慮されたい。以下の自動化されたホテル発見問題AutomatedHotelDiscoveryProblemを定義する。すなわち、各クライアントエンティティは、まさしく1つのサーバエンティティと接続することを望むが、サーバエンティティは、多数のクライアントエンティティにサービスしている可能性がある。クライアントは、どのサーバが、それが接続する必要があるサーバであるかについての予備知識を持っていないが、各サーバは、それが通信することを期待するクライアントのアイデンティティidentityを知っている可能性がある。目標は、安全に、すなわち偽物のサーバエンティティがクライアントエンティティをハイジャックしないようにするように、また逆に、各サーバエンティティに、各サーバエンティティが、それが話すことを期待する相手のクライアントエンティティだけに話していることを保証するように、各クライアントエンティティをその対応するサーバエンティティと接続することである。ここで組み立てられた問題では、クライアントエンティティと、サーバエンティティとが、通信ネットワークを通してリンクを確立すると仮定しており、この通信ネットワークは、ゲートウェイ30と、バックオフィスサーバ40とを、例えば、データベースに接続されたウェブポータルとを含んでいる。ホテル発見問題の実現モバイル通信ネットワークにおけるホテル発見問題の実現。ホテル発見問題の現在の実現についての一例においては、モバイル電話上記で組み立てられた問題において訪問者の役割を演じるは、アクティブにされるとすぐに、それに関連付けられると考えられるどのネットワークオペレータホテルの役割を演じるにアクセスするかを発見する必要がある。より具体的には、ユーザが、セルラ方式電話をオンにするときに、その電話が、それに登録されると考えられるオペレータのネットワークアイデンティティを先験的に知らない場合に、その問題が当てはまる。類似した問題は、公衆ホットスポットにおけるWiFiアクセスに当てはまり得る。いわゆるオープンなデバイス環境において動作する電子書籍リーダe-readerなどの非伝統的ワイヤレス機能対応デバイスの発展は、その問題をより差し迫ったものにしている。例えば、電子書籍リーダは、ワイヤレスインターフェースを装備しており、ターゲット視聴者を拡大するために複数のワイヤレス技術をますます大幅にサポートしている。このアプローチにより、また、電子書籍リーダの製造業者は、彼らのデバイスを流通させるときに、1つのオペレータに焦点を絞るのではなく、信頼されるが、さらにオープンな小売店流通戦略を活用することができるようにもなる。したがって、それによって、モバイル電話、電子書籍リーダ、または他のユーザ電気器具が、少なくともいくつかの候補のアクセスネットワークを認識し、また正しいアクセスネットワークを確実に選択することができ、またそれによって、アクセスネットワークは、既に知られている、または既に期待しているこれらの合法的なデバイスだけに入場を制限するための自動化された方法についての必要性が存在する。M2M通信におけるホテル発見問題の実現。マシンツーマシンM2M通信は、M2Mアプリケーションが出現し、前例のない潜在性をもたらしていることにより、広範にわたる成長を経ている。数十億個の低コストM2Mデバイスが、アクセスネットワークの混合物を活用する複数のM2MオペレータM2MOによって提供される数千個のアプリケーションを用いて展開されることが期待される。初期のM2M展開は、単一の提携したアクセスネットワークオペレータに対するそれらの密接な依存性と、それらのオペレータへの信頼とによって特徴づけられてきており、このオペレータは、一般的に、ほとんどのM2Mオペレーションを管理し、またいくつかの絶対必要なサービスを提供する。1つの現在使用可能なサービスは、M2Mサービスの発見であり、このM2Mサービスの発見は、在庫があってすぐに入手可能なM2Mデバイスが、適切なアクセスネットワークプロシージャを通して、その関連のあるM2MOについてのアイデンティティを与えられることを可能にしており、またそれがそのM2MOにアタッチすることを可能にしている。例えば、M2Mデバイスは、1つの特定のアクセスネットワークプロバイダで動作するように例えば工場においてあらかじめ構成されている可能性があるが、アクセスネットワークプロバイダは、特定の分野において、特定のM2MOと排他的合意を有する。M2Mデバイスが、初めてアクセスネットワークに接続するときに、アクセスネットワークは、そのアドレスと、通信パラメータとを含めて、M2Mオペレータのアイデンティティをデバイスに対して通信する。その後に、M2Mデバイスは、この特定のM2MOと通信する。しかしながら、そのようなアーキテクチャモデルは、M2MOが、アクセスネットワークオペレータから切り離され、またM2Mサービスプロバイダとして、多数の、場合によっては数十億個さえものデバイスを独立に管理する必要がある、大規模なM2M展開から構成される複雑なM2Mエコシステムを期待されるように受け入れることができない。図2は、ネットワークエンティティのオペレータとして、または他の種類の利害関係者としてのいずれかで、複雑なM2Mエコシステムに参加する様々なエンティティを一般的に接続するトランザクションの関係を概略的に表すものである。これらは、製造業者50と、アプリケーションプロバイダ60と、M2Mオペレータ70と、アクセスネットワークオペレータ80と、顧客90が所有または制御するデバイス100とを含む。そのような複雑なM2Mエコシステムにおいては、M2MOは、M2Mサービスの発見オペレーションを管理するためのアクセスネットワークレイヤに頼ることができない。すなわち、M2MOと、アクセスネットワークオペレータとの間のビジネス関係がかけている可能性があり、またはアクセスネットワークフレームワークは、本質的にそのようなサポートを提供することができない可能性がある。例えば、使用可能なアクセスネットワークは、多くの場合に、特定の能力を持たない単純で純粋な移送手段にすぎないことになる。さらに、どのような決定が、M2Mオペレータと、M2Mデバイスとの間の特定の関連付けに関して行われるよりもかなり前に、M2Mデバイスは、多くの場合に、商用の使用可能性のために製造され、また流通される。1つの結論は、構成の後についてのユーザインターフェースを持たない、多数の、在庫があってすぐに入手可能なM2Mデバイスは、それらが一緒に関連付けを確立することになっているM2MOのアイデンティティについての初期のアクティブ化について知らないことになり、またそれらは、初期のアクティブ化についてのその情報を獲得する自動化手段を持たないことになるということである。M2MOがサポートする必要がある可能性がある非常に多くの個数のM2Mデバイスを仮定すると、M2MOに関連した情報の手動的な事前プロビジョニングなどの非スケーラブルな解決法が、実現可能でない可能性があることが、理解されよう。したがって、M2Mデバイスが、適切なM2MOを発見し、また適切なM2MOに関連付けることを可能にする問題に対処するためのスケーラブルな技法についての必要性が存在している。以下では、例示の目的のために、本発明者等は、本発明の技法について、M2Mデバイスに関連するものとして説明する。しかしながら、同じ技法はまた、例えば、ETSITS102690技術仕様:Machine-to-MachineCommunicationsM2M;FunctionalArchitectureにおけるM2Mゲートウェイについての定義から理解されるように、M2Mゲートウェイに対しても適用可能であることに留意されたい。広告におけるホテル発見問題の実現。広告の目標は、新しい製品に対する顧客の注意を引くことである。広告に適用されるようなホテル発見問題の実現において、顧客は、訪問者の役割を演じるが、新しい製品を広告する会社は、ホテルの役割を演じる。したがって、会社の目標は、製品の存在および価値について顧客に通知することである。それに応じて、顧客は、製品についての見込みのある購入者として、製品を販売する会社との関係を確立することが期待される。現代のデータマイニング方法論は、広告主が、好ましい広告するターゲットである消費者を識別することを可能にしている。したがって、広告主が、その好ましいターゲットに到達することを、また逆に、顧客が彼らが好む広告だけを受け取ることを確実に可能する、自動化された方法が求められている。ホテル発見問題に対する解決法についての高レベルの記述本発明者等は、図に示されるように、自動化され得る、またホテル発見問題に対する例示の解決法となる、3つの方法について説明する。これらの方法のどれを用いても、訪問者は、たとえ彼が、先験的に、彼の行き先についてのアイデンティティを知らないとしても、またたとえサードパーティが、ずっと継続する形態で、彼にアドバイスすることができないとしても、適切な行き先を識別し、また適切な行き先に到着することができる。簡単に言えば、それらの解決法は、以下のようなものである。1.ホテルは、訪問者が、ホテルに到着することを望んでいることを知っており、またそれに応じて空港に代理人を派遣して、訪問者に会い、また訪問者をピックアップする。これは、到着についての正確な時刻が知られており、また訪問者およびホテルについてのセキュリティが、確認され得るときの限られた場合に当てはまる。2.ホテルのグループは、ピックアップバンを空港へと送って、様々な個人をピックアップするが、しかしながら、特定の訪問者は、明確には招待されても、または通知されてもいない。訪問者は、その乗車を受け入れ、またホテルへと向かい、そこで、安全なネゴシエーションプロセスを通して、訪問者は、このホテルが、意図された行き先であるか否かを決定する。ホテルがそうでない場合、そのときには訪問者は、そのバンへと戻り、また別の候補の行き先へと向かう。このシナリオの変形においては、各ホテルは、それ自体のバンを提供する。3.訪問者は、メディアを使用して、彼の到着を知らせる。訪問者を期待するホテルは、訪問者の到着について知り、また空港へと代理人を送って、訪問者に会い、また訪問者による、また代理人による検証の後にホテルまで訪問者を連れてくる。以下で、本発明者等は、どのようにして、これらの解決法が、自動化された設定における特定の通信環境に対するアプリケーションのために、実装される可能性があるかについて説明する。とりわけ、本発明者等は、セキュリティおよび効率を保証するために有効であるプロトコルと、これらの解決法を実現可能にするシステムアーキテクチャとについて説明する。自動化された通信環境におけるフレームワークおよび解決法一般的な問題に対する解決法。図1を参照して、本発明者等は、N個のクライアントエンティティ10の組と、M個のサーバエンティティ20の組とが、安全に互いに接続しようと試みている自動化された通信環境を考慮する。本発明者等は、クライアントエンティティと、サーバエンティティとが、ゲートウェイ30と、バックオフィスサーバ40とを含む通信ネットワークを通してリンクを確立することを仮定している。バックオフィスサーバとは、データベースに、またネットワークに接続されるウェブポータル、または他の類似したエンティティを意味する。一般的に、クライアントは、非常に限られたユーザインターフェースを有し、または全くユーザインターフェースがないことさえあり、また人間の介入がほんの少ししかなく、または人間の介入なしに、ネットワークにおいてサーバと通信することができるように設計されているデバイスになる。M2M通信の技法は、例えば、クライアントデバイスが、自動的に、また人間の介入なしに、ネットワークサーバなど、ネットワークにおける別のマシンと通信する助けを行うことができる。M2Mシステムのいくつかの例は、すなわち、ユーティリティメータが、ユーティリティプロバイダサーバに対して定期的に報告すること、医療用モニタが、収集された患者のデータを病院のサーバに対して供給すること、自動化乗り物モジュールが、中央乗り物コンピュータシステムによって制御されること、および温度湿度制御デバイスclimatecontroldeviceが、中央物理プラントコンピュータに対して報告し、また中央物理プラントコンピュータによって制御されることである。一実施形態においては、サーバエンティティと、クライアントエンティティとは、一時的なパスワードを共用することができる。一時的なパスワードは、製造中にクライアントにおいてあらかじめ使えるように設定されるpre-provisioned可能性もあり、または代わりにしかもキーパッドなど、適切なユーザインターフェースが、使用可能である場合だけに、クライアントのユーザは、一時的なパスワードを選択し、またそのパスワードをクライアントに入力することができる。さらに、各クライアントについての情報は、バックオフィスサーバと共用される。共用された情報は、一般的に、一時的なパスワードと、クライアントについてのアイデンティティとを含むことになる。このアイデンティティは、特定のサーバに対してクライアントを一意的に識別しなければならない。共用された情報はまた、とりわけ、クライアントが接続する必要があるサーバのアイデンティティと、アイデンティティに関連した暗号プリミティブとを含むこともできる。バックオフィスサーバは、一般的に、認証サーバ以下で論じられるが、図1には示されていないとこの情報を共用することになる。ホテル発見問題をさらに参照すると、上記で説明されるような通信環境におけるサーバエンティティは、ホテルの役割を演じるが、クライアントエンティティは、訪問者の役割を演じる。クライアントと、サーバとが、互いに識別し、またサービス関連付けを確立するためには、1つまたは複数の以下の例示のアプローチ-おのおのがホテル発見問題に対する解決法-が有利である可能性がある。1サーバエンティティは、バックオフィスサーバからクライアントのアイデンティティを取得する。この情報は、バックオフィスサーバによってサーバエンティティに対して知らされ、すなわちバックオフィスサーバに対してプッシュされる可能性がある。代わりに、サーバエンティティは、関連するバックオフィスサーバに、この情報を定期的に要求し、またそれに応じてこの情報を受信し、すなわち、この情報をプルすることができる。次いで、サーバエンティティは、その特定のアイデンティティを有するクライアントに対して広告メッセージを送信することにより連絡しようとする。広告を受信するとすぐに、クライアントは、サーバエンティティとの相互認証セッションに従事する。これは、一般的に、通信ネットワークにおいてゲートウェイを通して行われることになる。正常な認証の後に、クライアントエンティティと、サーバエンティティとは、より恒久的なセキュリティプロトコルを実行し、また恒久的にお互いを発見する。この点において有用とすることができるいくつかの知られているセキュリティプロトコルは、IBAKEおよびPAKである。例えば、IETFインターネットドラフトhttp://tools.ietf.org/html/draft-cakulev-ibake-01、IBAKE:Identity-BasedAuthenticatedKeyAgreement、およびIETFRFC5683、Password-AuthenticatedKeyPAKDiffie-HellmanExchange、http://tools.ietf.org/html/rfc5683を参照されたい。2サーバエンティティからの広告は、任意の興味のあるクライアントエンティティに向かうことになっているブロードキャストメッセージサービスオファーの形態をとる。上記のように、クライアントが、そのようなブロードキャストメッセージオファーを受信するとすぐに、そのクライアントは、発見プロセスを開始する。しかしながら、ブロードキャストメッセージを受信することは、必ずしも成功をもたらすとは限らない。例えば、オファーは、間違ったサービスエンティティからクライアントによって受信される可能性もあり、または期待されなかったクライアントが、サービスエンティティに接続しようと試みる可能性もある。いずれの場合にも、相互に認証された発見プロセスが失敗する結果になろう。失敗の場合には、クライアントエンティティは、ブロードキャストメッセージをリッスンすることを再開し、また発見プロセスが、相互に認証し、また成功するまで、連続して他のサーバエンティティに接続しようと試みる。3クライアントエンティティは、広告を要求することによりプロセスを開始する。この要求は、例えば、ウェブページアクセスを通して、バックオフィスサーバに伝えられる可能性がある。次いで、バックオフィスサーバは、サービングエンティティに対してこの要求を伝えることができる。サービングエンティティが、そのような要求を受信するとすぐに、そのサービングエンティティは、例えば、これらの例示のアプローチのうちの第1のものに関して説明されるように、クライアントに対して広告を送信する。クライアントによる広告の受信のすぐ後に、クライアントと、サーバとは、相互にお互いを認証し、またその後に、加入に関連のある恒久的な証明書を確立する。上記の3つの例示の各アプローチについて、以下でより詳細に説明される。オープンなデバイス環境における問題の実現に対する解決法。上記の3つのアプローチのおのおのは、オープンなデバイス環境において実装される可能性がある。先験的に、特定のサービスプロバイダに関連付けられていない、すなわち特定のサービスエンティティと一緒にだけ機能するように、また排他的に機能するようにあらかじめ構成されていない汎用デバイスは、オープンなデバイスであるように考えられることがよく理解されよう。オープンなデバイスを受け入れるように、またワーキングシステムにおいてそれらを統合するように定義されるフレームワークは、オープンなデバイス環境として定義される。オープンなデバイスの例は、任意の水道供給会社とともに機能することができる汎用水道メータ、または任意の警報システムと一体化され、またシステム特有の証明書を付与され得る警報センサを含んでいる。同様に、特定の、所定のネットワークに結合されていない電子書籍リーダは、オープンなデバイスであるように考えられる。第1のアプローチに従って、オープンなデバイスのユーザは、そのユーザの選択したアクセスネットワークとともに、一時的な証明書例えば、一時的なパスワードを確立することができる。言い換えれば、ユーザは、対応するネットワークオペレータとの一時的なビジネス関係を設定する。例えば、多くの場合にオフライン事前プロビジョニングと称されることもあるプロシージャにおいて、ユーザは、バックオフィスサーバと通信し、サービス加入を確立し、デバイスアイデンティティを提供することなどを行う。バックオフィスサーバは、次には、デバイスのアイデンティティをサービスオペレータに対して提供する。この点において、ユーザと、選択されたネットワークとの間の通信は、興味のある特定のオープンなデバイスを必要としない可能性があることに留意されたい。とりわけ、オープンなデバイスは、一時的な証明書について知らない可能性があり、またキーパッドなど、標準的なインターフェースを通してユーザによってそれらを提供される必要がある可能性がある。しかしながら、オペレータは、デバイスの存在について知っている。事前プロビジョニングの後で、訪問者の役割のデバイスは、ホテルの役割のオペレータから明示的なページングメッセージを受信し、このページングメッセージは、ネットワークオペレータを識別する情報と、提供されるサービスのタイプとを提供する。次に、デバイスは、加入要求をオペレータに対して送信することができる。デバイスと、オペレータとが、正常にお互いを相互に認証する場合、それらは、これらの通信するサービスデータを含めて、後続の通信のために安全なセッションをセットアップすることを可能にすることになるサービス加入を確立することを進める。第2のアプローチに従って、ネットワークオペレータは、上記で説明されるように、デバイスのアイデンティティを取得する。しかしながら、明示的なページングメッセージを送信する代わりに、オペレータは、汎用ビーコンフレームをブロードキャストする。この汎用のブロードキャストされたビーコンは、その領域におけるすべての興味のあるデバイスに対してオペレータのサービスエンティティの存在を知らせることになる。この点において、ビーコンは、1つの特定のデバイスを対象としてはいないが、そうではなくて、そのようなアナウンスを期待するブロードキャストエリアにおけるすべてのデバイスによって受信され、また理解される。このビーコンを用いて、アクセスネットワークは、ネットワークサービスセッションを安全に確立しようと試みるように複数のデバイスをトリガする。望ましいものは、正しいネットワークに対する所与のオープンなデバイスの取り付けである。一般的に、これは、所与のデバイスが1つまたは複数のビーコンを検査し、またいくつかの異なるオペレータのおのおのに関連付けるように試みた後に起こる。最終的には、デバイスは、正しいネットワークオペレータに出合い、またそれを用いて相互に認証することになる。これに続いて、デバイスと、ネットワークとは、サービス加入と、必要に応じてサービスセッションとを確立するように進むことができる。第3のアプローチに従って、オープンなデバイスは、適切なネットワークオペレータを識別する努力が、開始されているというアナウンスを送信する。そのようなアナウンスの受信のすぐ後に、そのエリアにおける1つまたは複数の使用可能なネットワークは、デバイスに対して明示的な招待を送信することができる。あらかじめ使えるように設定されたセキュリティ証明書を使用して、オープンなデバイスは、相互の認証を通して適切なネットワークを識別し、またその後に、そのオペレータに対してアタッチして、サービス加入またはサービスセッションを確立することになる。M2Mについての、ホテル発見問題を解決すべき3つの前述のアプローチについてのアプリケーション。このセクションにおいては、本発明者等は、マシンツーマシン通信についての、M2MO発見の問題に対する3つの前述の関連付け戦略についての例示のアプリケーションを説明することになる。本発明者等は、M2Mデバイスが、M2MOの発見および関連付けに関してさらなるアクションを起こす前に、アクティブ化のすぐ後にアクセスネットワークに正常に登録されることを仮定している。以下で説明されるべき例においては、M2MOは、意図された行き先の役割を演じるが、M2Mデバイスは、ホテル発見問題に関連した訪問者の役割を担う。一般に、アクセスネットワークは、望ましいM2MO、または望ましいM2Mデバイスに到達するための移送ネットワークとしてのサポートの役割を実行することになる。しかしながら、アクセスネットワークは、移送を提供するだけでなく、ここで説明されるようなM2MOの機能をも担うというシナリオも存在することがある。例えば、この種の簡単なシナリオにおいては、オープンなクライアントデバイスは、電子書籍リーダであり、この電子書籍リーダは、様々な電気通信サービスプロバイダtelecommunicationsserviceprovidersTSPのうちのどれかのサービスを使用して書籍をダウンロードすることができる。バックオフィスサーバは、1つの特定のTSPを選択し、このTSPは、サービングネットワークとしての機能を果たすだけでなく、その後オンラインの書店からテキストのダウンロードを達成するためのM2Mオペレータとしての機能も果たす。第1のアプローチに従って、M2MOは、M2Mデバイスのアイデンティティと、関連したパラメータの組とを用いて使えるように設定された後に、明示的なM2Mサービスレイヤの招待をM2Mデバイスに対して送信する。M2Mデバイスは、招待を受信し、またM2MOを用いて相互に認証する。次いで、M2Mデバイスと、M2MOとは、M2Mサービス加入の確立を進める。第2のアプローチに従って、広告が、M2MOからブロードキャストされる。これらの広告の目的は、それらの指定されたM2MOを探し求めているデバイスを引きつけることである。そのような広告の受信のすぐ後に、M2Mデバイスは、加入要求をM2MOに対して送信する。これは、相互認証を開始することができ、この認証は、もし成功するならば、M2MOと、M2Mデバイスとの間のサービス加入の確立が、続いている可能性がある。第3のアプローチに従って、M2Mデバイスは、ブロードキャストメッセージを通してM2MOを識別すべきその意図を知らせる。M2MOは、アナウンスを受信し、また明示的な招待をM2Mデバイスに対して送信することにより、応答する。招待は、どのようにしてサービス加入の確立を進めるべきかをM2Mデバイスに指示する情報を含んでいる。M2MOと、M2Mデバイスとは、正常な相互認証のすぐ後に加入を確立する。広告における問題の実現に対する解決法動機付けの例。第1のアプローチに従って、本発明者等は、製品を販売する会社が、製品を購入することに非常に興味を持つことになる特定の顧客について知っていることを仮定している。例えば、この種の情報は、顧客のトランザクションデータと、人口統計学データとに対して統計的方法を適用することにより、編集される可能性がある。高級車を広告しているローカルな自動車販売業者のリーフレットは、例えば、広く知られている高価な郊外地域において高価な家を所有する、見込みのある顧客を対象としている可能性がある。第2のアプローチに従って、会社は、特定の顧客に対処しておらず、その代わりに、会社は、ブロードキャストする手段を使用して製品を広告している。例えば、新しいソフトドリンクについて興味を持つことになる多数の顧客は、テレビジョンのコマーシャルを通して通知される可能性がある。第3のアプローチに従って、1つまたは複数の会社によって提供される特定の製品を購入することに興味のある顧客は、候補の会社が通知されるような方法でこの興味を知らせる。一例は、新聞、公共的ウェブサイト、職業別電話帳などの上で、興味をポストすることである。実際にそのようなアナウンスは、それが、高価な住宅などの項目についての購入など、他の振る舞いから推論できる可能性があるので、暗黙的である可能性がある。自動化された環境に対するアプリケーション。電子的な広告が、ウェブページの内部に埋め込まれたバナーの形で出現するオンライン広告の場合について考える。オンラインユーザが、ある種のリンクの上でクリックし、またはオンライン検索エンジンを使用して特定のストリングを検索するときはいつでも、そのようなアクションと、関連したデータとは、ネットワークオペレータと、広告エンティティとの間で監視され、また共用される。インテリジェントなソフトウェアは、ユーザの習慣と好みとをログ記録することができ、また特定のユーザに専用にされた広告を提供する際に使用するためにこの情報を処理することができる。上記で説明されたアプローチのうちの第1のアプローチに従って、ある製品を販売することに興味がある会社は、その顧客またはユーザの習慣と好みとにマッチした広告を目に見えるようにすることにより、その特定の顧客またはユーザに対してその製品を広告する。第2のアプローチに従って、会社は、すべての見込みのある顧客またはユーザに対してオンラインの広告をブロードキャストする。第3のアプローチに従って、オンラインユーザは、ある種のリンクを意図的にクリックして、特定のタイプの製品についての広告を提供することにより応答するソフトウェアメカニズムをトリガすることができる。これは、ユーザの振る舞い、すなわち、特定のリンクをクリックすることが、ユーザの興味と製品の必要性とについての暗黙のアナウンスを構成することができるという1つのシナリオであることに留意されたい。例示のシステムアーキテクチャホテル発見問題を解決することに対する前述の3つのアプローチのおのおのが、どのようにしてM2Mの場合において適用され得るかについての分析を進める前に、本発明者等は、例示のサービスレイヤアーキテクチャについての概説を提供する。アーキテクチャは、図3において挿し絵を用いて表されており、次にこの図3に対して注意が向けられる。ここで説明されるシステムアーキテクチャは、M2M環境の特定の文脈で説明されているのに対して、当業者なら、ここで説明されるアイデアを他の環境に対しての簡単に拡張することができることが理解されよう。図3に示されるように、M2MO110は、3つの基本的な機能エンティティ、すなわちM2Mデバイスのデバイスアイデンティティとセキュリティ証明書とを記憶し、また登録されたデバイスのリストも記憶するM2M認証サーバおよびデータベース120例えば、AAAサーバと、デバイスとM2MOとの間で情報を通信するM2MOサービスエージェント130と、いくつかの異なる役割を有することができるアプリケーションサーバエンティティ140とを含む。例えば、アプリケーションサーバは、恒久的なセキュリティキーについてのパラメータを生成するM2Mデバイス150を用いてブートストラップオペレーションを実行することができ、またそれは、認証サーバに対してこれらのパラメータを伝えることができる。信頼されたプロビジョニングエンティティtrustedprobisioningentityTPE160は、認証サーバに対してM2Mデバイス証明書を使えるように設定する。そのような証明書は、デバイスに対して招待を送信するために、ならびに加入要求をセキュリティ保護されるように受け入れるために、M2MOによって使用される。この点については、デバイスと、M2MOとの間のどのような情報交換もM2MOサービスエージェントを通して進むことに留意されたい。当業者によって理解されるように、認証サーバは、一般的に、標準的な1Uサーバ、またはサーバのクラスタの上で実行される。もちろん、在庫があってすぐに入手可能なサーバから、特注で構築された使用可能性の高いATCAハードウェアプラットフォームこれは、例えば、高いトランザクション量が存在するネットワークのために有用であり得るまでのデバイスの範囲を含めて、多数の代替案が可能である。サービスエージェントは、一般的に、適切なプラットフォームの上で実行されるソフトウェアの形で実装される。アプリケーションサーバをサポートすることができるデバイスの範囲は、認証サーバをサポートすることができる範囲に類似している。しかしながら、一般的なルールとして、データセンタサーバハードウェアが、認証サーバと、アプリケーションサーバとをサポートするためには好ましい。次に、上記で論じられた一般的なアプローチのそれぞれを、M2M通信にどのように適用できるかについての一例について説明する。第1のアプローチ:M2MOは、M2Mデバイスに対して明示的な招待を送信する。このアプローチは、M2MOからM2Mデバイスへと送信される明示的な招待メッセージを必要とする。より具体的には、在庫があってすぐに入手可能に購入され、また初めてアクティブにされるM2Mデバイスは、どのM2MOに関連付けられることになっているか知らない。低コストM2Mデバイスは、ユーザインターフェースを有していない可能性があり、このユーザインターフェースからそのような情報を得ることができる可能性があることを思い出して欲しい。M2MOが、M2Mデバイスの存在と、M2Mサービスについて関連付けるべきその意図とについて通知されるとすぐに、M2MOは、M2M招待を構築し、またそれをデバイスに対して送信することになる。M2MOが、デバイスの存在について知るようになることができる様々な典型的なプロシージャが存在している。一例においては、デバイスの、または関連のあるM2Mアプリケーションプロバイダの所有者は、M2MOに直接に、またはサードパーティを通してのいずれかで連絡を取り、また以下で考察されるべきパラメータのオプションの組と一緒にデバイスのアイデンティティを提供する。図3の例示のアーキテクチャに関して、TPEは、M2MOに対してまた具体的には、認証サーバデータベースに対してそのような情報を使えるように設定するタスクが割り当てられる。このアプローチに従って、M2MOは、特定のM2Mデバイスに明示的に向かうようになっているM2M招待ホテル発見問題についての本発明者等のステートメントにおける空港へ送られた代理人に類似しているを送信することによりデバイスを明示的にトリガすることになる。そのような招待は、本発明者等が後で説明することになるパラメータの組と一緒に、M2MOアイデンティティと、M2Mデバイスアイデンティティとを示す、アプリケーションレイヤページングメッセージとして考えられる可能性がある。上記プロシージャのステップは、図4に図示され、また以下でより詳細に説明される。1.TPEは、M2Mデバイスアイデンティティについて知っており、またデバイスアタッチメントプロセスに関連しており、また以下に続く特定のアタッチメントプロセスに特有である1組の証明書とパラメータとを含めて、M2MOに対して具体的に認証サーバデータベースに対してデバイスについてのブランド提携と、アイデンティティとを使えるように設定する。TPEは、例えば、製造業者から、またはウェブインターフェースを通してM2Mデバイスのユーザまたは所有者によって入力されるデータから、この情報を取得している可能性がある。その情報を獲得するための他の可能性のある手段は、当業者には簡単に明らかになろう。デバイスアイデンティティは、例えば、デバイスのMACアドレスによって、電子的シリアル番号によって、または製造中にデバイスに対してあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。ちょうど、デバイスについての識別する情報がTPEに対して伝えられる可能性があるように、期待されたデバイスロケーションもまた、伝えられる可能性があることが理解されよう。それは、M2MOとデバイスとの間のより焦点の合わされた領域的に制限された通信を潜在的に可能にするので、これは、有利である可能性がある。2.M2MOは、今や、M2Mデバイスが、関連付けとさらなるサービス登録とについての招待を進んで受け入れることを知っている。M2MOが、アクセスネットワークアタッチメントの論理ロケーションに関する近似の、または明示的な情報を用いて使えるように設定される場合、M2MOは、明示的なM2M招待メッセージ170をそのロケーションに向かって方向づけることができる。そうでなければ、M2MOは、招待をブロードキャストすることができる。M2MOが、あらかじめ定義された時間間隔内においてM2Mデバイスからの応答を受信するか否かに応じて、それは、応答が受信されるまで、招待の伝送を反復することができる。M2MOが、複数のM2Mデバイスを招待したいと望む場合に、M2M招待メッセージは、有利に、特定のエリアの中に横たわる可能性があるすべての招待されたデバイスについてのアイデンティティを有するリストを含むことに留意されたい。そのような場合には、M2Mデバイスは、単に応答をM2MOに対して送信する前にそのアイデンティティがリストの中に含まれるかどうかを決定する必要がある。3.M2Mデバイスは、アクティブにされ、またアクセスネットワークに登録する。デバイスは、今や、M2Mサービス加入についての招待を受け取ることができる。M2Mデバイスが、明示的なM2M招待だけに応答するようにオプションを用いてあらかじめ構成されている場合、デバイスは、特定のデバイスアイデンティティを含むM2M招待メッセージに対してだけ応答することになる。そのような招待を受信するとすぐに、デバイスは、M2M加入要求180を用いて対応するM2MOに対して応答することになる。4.M2MOは、加入要求を受信する。M2MOと、M2Mデバイスとの間の正常な相互認証190のすぐ後に、M2MOと、M2Mデバイスとは、加入200を相互に確立することになる。このプロシージャのある種の態様については、以下でより詳細に説明されよう。上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ1つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。第2のアプローチ:M2MOは、すべての興味のあるM2Mデバイスに対して広告をブロードキャストする。この場合には、M2MOは、どのような明示的な招待も送信しないが、それは、どのM2Mデバイスが、M2MOを識別したいと、またそれに関連付けたいと望むかについて知っている。代わりに、M2MOは、一般的なアプリケーションレベルのアナウンス、または広告メッセージを定期的にブロードキャストすることもでき、このメッセージは、ホテル発見問題についての本発明者等のステートメントにおけるピックアップバンに類似している。ブロードキャスティングの頻度は、オペレータのポリシーに依存している。そのような定期的な広告を用いて、M2MOは、その存在についてデバイスに通知するように要求し、その結果、デバイスは、M2MOについて知るようになり、またそれに関連付けようと試みる可能性がある。明らかに、M2MOは、それが、既にそれらを用いて使えるように設定されているので、そのアイデンティティがM2MOに知られているM2Mデバイスからの加入要求だけを受け入れることになる。このアプローチによるステップのシーケンスが、図5に示され、また以下でより詳細に説明される。1.第1のアプローチにおけるように、TPEは、デバイス証明書を用いて、またデバイスアタッチメントプロセスに関連しており、また以下に続く特定のアタッチメントプロセスに特有のパラメータの組を用いて、M2MOを使えるように設定する。TPEは、製造業者から、ウェブインターフェースを通してM2Mデバイスのユーザまたは所有者によって入力されるデータから、あるいは他のソースからそのような情報を取得することができる。アイデンティティは、例えば、デバイスのMACアドレスによって、電子的シリアル番号によって、または製造中にデバイスにあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。2.M2MOは、M2Mデバイスのアイデンティティのリストを用いて使えるように設定される。M2MOは、1つまたは複数のM2Mデバイスが、加入関連付けをまだ確立していないこのリストの上に留まっている限り、M2M広告210を定期的にブロードキャストする。このアプリケーションレベルの広告は、M2MOのアイデンティティと、場合によっては1組のさらなるパラメータとを含む。M2MOが、M2Mデバイスが1つまたは複数のアクセスネットワークに、アタッチされる可能性がある場合の近似的な論理的ロケーションについて知っている場合、M2M広告の伝送と転送とは、ある種の論理領域だけに限定される可能性がある。代わりに、M2MOは、1つまたは複数のアクセスネットワークを広告で氾濫させるように決定することができる。3.M2Mデバイスは、広告を受信し、それを処理し、またM2Mデバイスが、M2Mサービスに対する加入プロセスを開始しようと試みるべきかどうかを決定する。M2Mデバイスは、広告の中に含まれるある種のパラメータに、また同様にインストール中にデバイスの中へとあらかじめ使えるように設定されているある種のパラメータ値に、この決定の基礎を置くことができる。あらかじめ使えるように設定され得るパラメータの一例は、提供されるサービスのタイプである。デバイスが、広告されたM2MOが加入についての候補であることを決定する場合、デバイスは、M2M加入要求220に応答する。4.M2MOは、加入要求を受信する。M2MOとM2Mデバイスとの間の正常な相互認証230のすぐ後に、M2MOと、M2Mデバイスとは、加入240を相互に確立する。このプロシージャのある種の態様については、以下でさらに詳細に説明される。上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ1つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。第3のアプローチ:M2Mデバイスは、M2MOを見出すことにおけるその興味を知らせる。第3のアプローチは、適切なM2MOを識別し、また適切なM2MOに関連付けるべきその意図をM2Mデバイスに広告させることにより実現される。この場合には、M2MOは、M2Mデバイスに起源を有する広告の受信を受動的に待つ。そのような広告の受信と処理とのすぐ後に、M2MOは、デバイスに連絡を取り、またそれとの関連付けを確立しようと試みる。このアプローチによるステップのシーケンスが、図6に示されており、また以下でより詳細に説明される。1.TPEは、デバイス証明書を用いて、またデバイスアタッチメントプロセスに関連しており、また以下に続く特定のアタッチメントプロセスに特有であるパラメータの組を用いてM2MOを使えるように設定する。TPEは、製造業者から、ウェブインターフェースを通してM2Mデバイスのユーザまたは所有者によって入力されるデータから、あるいは他のソースからそのような情報を取得することができる。デバイスアイデンティティは、例えば、デバイスのMACアドレスによって、電子的シリアル番号によって、または製造中にデバイスに対してあらかじめ使えるように設定された、他の任意の固有の識別子によって表される可能性がある。2.M2Mデバイスが、アクティブにされ、またアクセスネットワークに登録されるとすぐに、デバイスは、M2Mデバイス導入メッセージM2Mdeviceintroductionmessage250の定期的ブロードキャストを開始し、このM2Mデバイス導入メッセージは、デバイスのアイデンティティを含んでいる。3.M2M導入メッセージは、1つまたは複数のM2Mオペレータに到達し、このM2Mオペレータは、メッセージを処理し、またM2Mデバイスに連絡を取るべきか否かを決定する。一般に、1つのM2MOは、それが既にあらかじめ使えるように設定されているときに用いるものとしてM2M導入広告の中に含まれるアイデンティティを認識することになる。そのM2MOは、明示的なM2M招待メッセージをデバイスに対して送信する。この招待メッセージは、第1のアプローチに関連して上記で考察されたM2M招待メッセージに類似している。4.明示的なM2M招待メッセージ260の受信のすぐ後に、デバイスは、M2M加入要求270で対応するM2MOに応答する。5.M2MOは、加入要求を受信する。M2MOと、M2Mデバイスとの間の正常な相互認証280のすぐ後に、M2MOと、M2Mデバイスとは、加入290を相互に確立する。このプロシージャのある種の態様は、以下でさらに詳細に考察される。上記で提示されるようなステップのシーケンスは、単に例示的なものにすぎないこと、およびとりわけ1つまたは複数の列挙されたステップは、組み合わされ、または再分割されてもよいことに留意されたい。すべての3つのアプローチについてのサポート。デバイスとM2MO装置とについてのあらかじめ構成されたソフトウェアとオペレーションのモードとに応じて、M2MOと、M2Mデバイスとは、個々に、または平行な組合せにおいてのいずれかで、上記で説明される3つのアプローチのおのおのに従ってオペレーションをアクティブにすることができる。アプローチの平行な組合せにおけるオペレーションの場合には、M2Mデバイスは、3つのアプローチのうちのどれにも従ってM2MOに起源を発するメッセージを処理し、また応答することができる。同様に、M2MOは、アプローチのうちのどれにも従って、明示的な招待と、定期的な広告との両方を送信することができる。デバイスの加入確立。M2Mサービスの加入確立は、M2MデバイスからM2MOへのM2M加入要求メッセージの伝送の後に、またM2MOと、M2Mデバイスとの間の相互認証の後に、開始される。以下で説明されるように、相互認証は、一般的に、一時的なパスワードを使用して達成されることになる。加入確立プロシージャは、図7において示されており、この図に対して、次に注意が向けられる。加入確立のプロセスは、いくつかのプロセスを含んでいる。1つの構成要素となるプロセスは、サービス登録のために使用されるべき恒久的なセキュリティ証明書のブートストラッピングである。別の可能性のある構成要素となるプロセスは、サービス加入に関連したある種のパラメータについての合意した値の設定である。加入確立プロシージャは、M2Mデバイスと、M2MOに属するブートストラップ機能エンティティ例えば、適切なサーバとの間で実行される。例えば、ブートストラップ機能エンティティは、例えば、図3において見られるようなアプリケーションサーバとすることができ、このアプリケーションサーバは、M2M認証サーバに対して相互に生成された恒久的なセキュリティ証明書をセキュリティ保護されるように通信する。M2MデバイスとM2MOとが、相互認証300の後に加入確立を進めることを決定する場合、M2Mデバイスは、図7に示されるように、M2Mサービスブートストラップ要求310をM2MOに対して送信する。M2MOは、M2Mサービスブートストラップ応答320をM2Mデバイスに対して送信することによって、応答する。このメッセージの正常な受信のすぐ後に、M2Mデバイスは、M2Mサービスブートストラップ完了330をM2MOに対して送信し、このM2MOは、加入ハンドシェイクを終了させる。M2Mデバイスと、M2MOとの間のこの3ステップのハンドシェイクは、セキュリティ証明書をブートストラップするための様々なプロトコルのうちのどれでも容易にすることができる。適切なそのようなプロトコルは、とりわけ、IBAKEと、PAKと、証明書に基づいた加入確立とを含む。ブートストラップした後に、M2MOは、オプションとして、検証メッセージ340をM2Mデバイスに対して送信することができる。次いで、M2Mデバイスは、恒久的なセキュリティ証明書についての正常なブートストラップを肯定応答する350。M2MOは、サービス登録パラメータを含むメッセージ360を用いて肯定応答メッセージに対して応答することができる。一般に、サービスパラメータと加入パラメータとは、アプリケーションに依存している。M2Mアプリケーションとして、ユーティリティメータで計ることについての特定の例を例証として取ると、パラメータは、限定することなく、恒久的アイデンティティと、グループアイデンティティと、ホストサーバアイデンティティと、デバイスからの伝送のための周波数およびタイムスロットと、管理インターフェースについてのブロードキャストパラメータとを含むことができる。セキュリティの考慮。M2Mデバイスのアイデンティティは、ただ1つの合法的なM2MOに対してあらかじめ使えるように設定されており、この合法的なM2MOは、それに応じてM2M加入要求に応答することが、M2MO識別技法と加入確立技法との上記考察において仮定されている。さらに、加入確立の前に、また加入確立中に続けられるべきある種のセキュリティプロシージャにより、M2Mデバイスは、候補のM2MOが、合法的であるかどうかと、候補のM2MOが、サービス加入についての適切なM2MOであるかどうかとを決定することができるようになる可能性がある。それが、適切なM2MOであるかどうかは、そのアイデンティティと、相互認証の成功とに基づいて決定される。M2Mデバイスは、それが、M2MOのアイデンティティを検証する場合だけに、加入を確立すること、およびサービスについて登録することに合意することになり、それによってそれが、面倒を起こすM2MOではないことを保証している。同様に、M2MOは、加入確立を進める前にM2Mデバイスの証明書を最初に検証する必要がある。必要とされる検証を実行する1つのやり方は、M2Mデバイスのアイデンティティに関連する一時的なパスワードを使用する。このパスワードは、オフラインステップ中に、M2Mデバイスと、M2MOとの両方に対して使えるように設定される。より具体的には、一時的なパスワードは、製造中にM2Mデバイスに対してあらかじめ使えるように設定される。デバイスの初期アクティブ化の前に、パスワードは、M2Mデバイスのアイデンティティと一緒に、M2MOに対してTPEによってオフラインで使えるように設定される。TPEは、デバイス製造業者から、または他のソースから、パスワードと識別情報データとを取得することができる。M2MOと、M2Mデバイスとは、一時的なパスワードを使用して、加入確立の前に互いに相互に認証することができる。様々な知られている認証プロシージャのうちの任意のものが、認証オペレーションのために使用される可能性がある。1つのそのようなプロシージャは、例えば、第3世代パートナーシッププロジェクト、3GPP技術仕様3GPPTS33.102V9.0.0:TechnicalSpecificationGroupServicesandSystemAspects;3GSecurity;SecurityArchitecture、2009年9月において説明されるAKA認証およびキー合意AuthenticationandKeyAgreementプロトコルである。適切な認証プロシージャとともに一時的なパスワードを使用して、M2Mデバイスは、M2MOが、正しいものであることを保証することができる。認証プロシージャはまた、他のM2MオペレータがM2Mデバイスを意図的に引きつける不正な実行を行うことから思いとどまらせて、それを拒絶、すなわち適切なM2MOに関連付ける機会を拒絶する。この点において、一時的なパスワードに基づいた認証は、ただの一例にすぎないこと、および様々な代替案もまた使用される可能性があることに留意されたい。例えば、1つの代替案は、M2MOによって生成され、またM2Mデバイスのアイデンティティを用いてIBE-暗号化されたワンタイムパッドOneTimePadである。M2Mデバイスは、ワンタイムパッドを暗号解読し、またそれをM2MOに対して戻し、このようにしてM2MOに対してOTPを暗号解読するその能力を立証し、またそれによってM2MOに対してそれ自体を認証している。OTPの考察のためには、N.Haller他、AOne-TimePasswordSystem、RFC2289、http://www.ietf.org/rfc/rfc2289.txtを参照されたい。別の代替的プロシージャにおいては、M2Mデバイスは、パスワードを保持し、またM2MOに対してそれ自体を認証するためのCHAPPWについてのダイジェストとしてそれを使用する。CHAPPWの考察のためには、W.Simpson、PPPChallengeHandshakeAuthenticationProtocolCHAP、RFC1994、http://www.faqs.org/rfcs/rfc1994.htmlを参照されたい。理想的なトランザクションにおいては、合法的な、また欠陥のないM2MOは、そのアイデンティティが、M2MOに対して既に知られているM2MデバイスからのM2M加入要求だけに応答する。合法的なM2MOは、知られていないデバイスを用いてサービス加入を確立しようと試みることにより、ビジネスに関連した利点を獲得することにならないので、合法的なM2MOは、そのアイデンティティが、先験的に使えるように設定されていないすべてのM2Mデバイスからの加入要求を理想的に無視し、または拒絶することになる。正常な相互認証のすぐ後に、IBAKEやPAKなどのセキュリティプロトコルを呼び出すことがなぜ有利であるかという以下の理由を指摘しておくが、すなわちこれらのプロトコルは、確立された恒久的なキーが、M2Mデバイスと、M2MOとだけに知られることを保証する。とりわけ、TPEおよびデバイス製造業者は、恒久的なブートストラップされたキーについて学習しない。メッセージ内容およびフォーマット以下で、M2MO発見フェーズの間に、M2MOとM2Mデバイスとの間で交換されるメッセージのために使用され得るフォーマットの例を提供する。1M2M招待:このメッセージは、以下の2つの場合においてM2MOからM2Mデバイスへと送信される。aM2MOは、デバイスのアイデンティティについて知っており、またそれゆえにそれは、デバイスに対してまたはデバイスのリストに対して明示的なM2M招待を積極的に送信する。bM2MOは、M2MデバイスからM2Mデバイス導入メッセージ下記参照を受信し、またそのデバイスに対してまたはデバイスのリストに対してM2M招待を用いて応答する。例示のM2M招待メッセージデータグラムは、図8に示されるように構築される。例証された構造は、例えば、TCP/UDP/IPパケットの中のペイロードとして埋め込まれる可能性がある。M2M招待は有利には、他の通信パラメータのうちでも以下の情報を含む。バージョン:このパケットについてのアプリケーションレイヤプロトコルバージョンを指定するためのもの。タイプ:このパケットについてのタイプ、例えば、M2M_招待M2M_INVITATIONを指定するためのもの。M2MOアイデンティティ:採用される特定の規格単数または複数によって定義されるように、M2Mオペレータを識別するためのもの。優先順位:このメッセージについての送信する優先順位をオプションとして示すためのもの。カウントID:このメッセージに含まれる招待が向かうことになっているM2Mデバイスアイデンティティの数を識別するためのもの。認証タイプ:この招待を受信するM2Mデバイス単数または複数が、M2MOが合法的であることを検証することができる認証方法を示すためのもの。知られていない認証タイプを有するパケットが、M2Mデバイスによって切り捨てられるべきである。招待間隔:招待の間の時間間隔をオプションとして識別するためのもの。誤って構成されたM2Mデバイスを有するある種の場合は、この値を必要とする可能性があり、それは、サービス拒否攻撃に対する対抗手段として使用される可能性もある。チェックサム:M2M招待メッセージの中のデータの破損を検出する際に受信デバイスを支援するためのもの。チェックサムに関連した知られている実行についての説明は、例えば、R.Braden他、RFC1071、ComputingtheInternetChecksum、http://www.faqs.org/rfcs/rfc1071.htmlにおいて見られる。M2Mデバイスアイデンティティx:M2MOが、引きつけようとする意図されたM2Mデバイス受信側を識別するためのもの。アイデンティティのリストは、M2MOがこのメッセージを通して到達したいと望むすべてのデバイスについてのM2M招待に含まれる可能性がある。M2Mデバイスの初期のアクティブ化中のロケーション情報についての使用可能性に応じて、異なる同時の可能性があるM2M招待異なるロケーションに向かって転送されるは、M2Mデバイスアイデンティティの異なるリストを含むことができる。M2Mサービスパラメータ:加入に先立ってM2Mデバイスにとって有用な可能性がある予備パラメータをオプションとして識別するためのもの。一例として、フィールドは、提供されるM2Mサービスのタイプに関する情報などを含むことができる。認証データ:M2Mデバイスが、招待を送信するM2MOのアイデンティティを検証することができる認証方法とパラメータとに関する、認証タイプフィールドに関連した情報を含むためのもの。2M2M広告:このメッセージは、M2MOから定期的に送信され、それは、ブロードキャストの性質であり、またどのような特定のM2Mデバイスにも特に対処してはいない。例示のM2M広告メッセージデータグラムが、図9に示されるように構築される。M2M広告メッセージは、バージョンと、タイプと、M2MOアイデンティティと、優先順位と、認証タイプと、広告間隔と、チェックサムと、認証データと、他のM2Mサービスパラメータとを含むことができる。上記のメッセージは、TCP/UDP/IPパケットの中へとペイロードとして埋め込まれる可能性がある。構造を構成するフィールドは、M2M招待メッセージのフィールドに類似している。しかしながら、広告は、特にどのようなM2Mデバイスにも明示的に向かうことになっていないので、メッセージは、どのようなM2Mデバイスアイデンティティ、またはカウントIDフィールドも含んでいない。代わりに、M2M招待のデータグラムフォーマットは、ここで再使用される可能性があり、そこでは、タイプフィールドは、これがM2M広告であることを指定することになり、カウントID値は、ゼロというデフォルト値に設定されることになるが、M2Mデバイスアイデンティティフィールド単数または複数は、ヌルNULLに設定されることにもなり、これがブロードキャストメッセージであることを示している。3M2Mデバイス導入:M2Mデバイス導入は、アクセスネットワークに登録するとすぐに、M2Mデバイスに起源を発するブロードキャストメッセージである。このメッセージは、1つまたは複数の候補のM2Mオペレータに到達するその試みにおいて、M2Mデバイスによって使用される。例示のM2Mデバイス導入メッセージデータグラムは、図10に示されるように構成される。M2Mデバイス導入メッセージは、バージョンと、タイプと、M2Mデバイスアイデンティティと、優先順位と、認証タイプと、伝送間隔と、チェックサムと、認証データと、他のM2Mサービスパラメータとを含むことができる。上記のメッセージは、TCP/UDP/IPパケットの中へとペイロードとして埋め込まれる可能性がある。構造は、M2M広告メッセージの構造に類似している。ただ1つの違いは、M2Mデバイスアイデンティティフィールドが、M2MOアイデンティティフィールドを置き換えていることである。しかしながら、M2Mデバイス導入メッセージは、M2M広告メッセージの中で使用されることになるM2Mサービスパラメータとは異なるM2Mサービスパラメータを-または異なるパラメータ値を-含むことができることに留意されたい。この場合にもやはりここでも、代わりにM2M招待のデータグラムフォーマットは、ここで再使用される可能性があり、そこではタイプフィールドは、これがM2Mデバイス導入であることを指定することになり、M2Mデバイスアイデンティティは、M2MOアイデンティティを置き換えることになり、カウントID値は、ゼロというデフォルト値に設定されることになるが、M2Mデバイスアイデンティティフィールド単数または複数は、ヌルに設定されることにもなり、これが、ブロードキャストメッセージであることを示している。ここで説明される方法は、M2M環境をサポートする任意のネットワークの上の実装のために適していることが理解されよう。そのようなネットワークは、固定されていても、ワイヤレスでも、または固定されたものとワイヤレスとの組合せであってもよい。ここで説明されるように、本発明者等の方法は、とりわけ、プロトコルのIPスイートによるパケット通信をサポートするネットワークに対して適用可能であるが、本発明者等の方法は、その種のネットワークだけに用途が限定されてはいない。さらに、サーバは、その用語がここで使用される場合、ネットワークインターフェースを有する任意の適切なコンピューティングマシンの上で実行され得るソフトウェア機能であり、そのようなマシンは、例えば、汎用または専用のデジタルコンピュータ、あるいは一連のそのようなコンピュータとすることができることが、理解されよう。