通信システム1に接続された第1のデバイス20において、通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第1のヘッダ情報を提供するステップと、前記通信メッセージを前記通信システム1に接続された第2のデバイス10に伝送するステップとを含む、通信システム1におけるデバイスタイプの認証方法であって、さらに、前記第1のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第1のデバイス20で不正使用防止可能なように第1の署名を作成するステップと、前記第1のデバイス20において、前記署名を含む前記通信メッセージの第2のヘッダ情報を提供するステップと、前記通信ステップの後に前記第1の署名を検証することにより前記第1のヘッダ情報を認証するステップとを有することを特徴とする方法。前記通信システム1が、HyperTextTransferProtocolHTTPおよびSimpleMailTransferProtocolSMTPから構成されるグループから選択された転送プロトコルに基づくことを特徴とする請求項1に記載の方法。前記デバイスタイプ関連コミットメントが、デジタル著作権管理DRMに準拠する旨のコミットメントであることを特徴とする請求項2に記載の方法。前記第1のデバイスがユーザ端末20であることを特徴とする請求項1から3のいずれか1項に記載の方法。前記第2のデバイスがサーバ10であることを特徴とする請求項1から4のいずれか1項に記載の方法。前記デバイスタイプに固有の情報が、前記署名を作成する際に従うアルゴリズムの定義を含むことを特徴とする請求項1または5に記載の方法。前記デバイスタイプに固有の情報が、それぞれの特定のデバイスタイプに対し一意であるデータ列を含むことを特徴とする請求項1から6のいずれか1項に記載の方法。署名を作成する前記ステップが、時刻、日付、およびヘッダ情報から構成されるグループの内の少なくとも1つの項目にさらに基づくことを特徴とする請求項1から7のいずれか一項に記載の方法。認証する前記ステップがさらに、前記第2のデバイス10で、前記第1のヘッダ情報に基づく前記第1のデバイスのデバイスタイプを決定するステップと、少なくとも前記決定されたデバイスタイプと関連する不正使用防止情報に基づいて前記第2のデバイス10で第2の署名を作成するステップと、前記第1および第2の署名が一致した場合に前記決定されたデバイスタイプを本物であると認めるステップとを含むことを特徴とする請求項1から8のいずれか一項に記載の方法。認証する前記ステップがさらに、前記第1のヘッダ情報および前記第1の署名に関する情報を前記第2のデバイス10から前記通信システム1に接続された第3のデバイス50~53に転送するステップと、前記第3のデバイス50~53により前記第1のヘッダ情報の真偽の検証を要求するステップと、前記第3のデバイス50~53の検証で本物と確認されたら前記第1のヘッダ情報を本物として認めるステップとを含むことを特徴とする請求項1から8のいずれか1項に記載の方法。前記第3のデバイス50~53は、前記第1のデバイス20のメーカーと関連していることを特徴とする請求項10に記載の方法。通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第1のヘッダ情報を供給する手段25と、前記通信メッセージを前記通信システム1に接続された他のデバイス10に伝送する通信手段21とを備えた、通信システム1に接続可能な通信デバイス20であって、前記通信デバイスのデバイスタイプに固有の情報24の不正使用防止対策済み記憶装置23と、少なくとも前記デバイスタイプに固有の情報24に基づいて第1の署名を作成するように構成された不正使用防止署名作成器26と、前記署名を含む前記通信メッセージの第2のヘッダ情報を供給するための手段25とを特徴とする通信デバイス。前記通信手段21が、HyperTextTransferProtocolHTTPおよびSimpleMailTransferProtocolSMTPから構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項12に記載の通信デバイス。さらに、デジタル著作権管理DRM手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理DRMに準拠する旨のコミットメントであることを特徴とする請求項13に記載の通信デバイス。前記通信デバイスがユーザ端末であることを特徴とする請求項12から14のいずれか1項に記載の通信デバイス。前記通信システム1に接続された送信デバイスから通信メッセージを受信する通信手段11を備え、前記通信メッセージは、デバイスタイプ関連コミットメントと関連付けられた第1のヘッダ情報を含む、通信システム1に接続可能な通信デバイス10であって、前記通信メッセージがさらに第1の署名を含む第2のヘッダ情報を含み、前記第1の署名を検証するように構成された認証手段15を備えることを特徴とする通信デバイス10。前記認証手段15がさらに、前記第1のヘッダ情報に基づいて前記送信デバイスのデバイスタイプを決定する手段と、通信デバイスのデバイスタイプに固有な情報の記憶装置13と、前記決定されたデバイスタイプに対応するデバイスタイプに固有の情報を取り出すように構成され、前記取り出されたデバイスタイプに固有の情報に基づき第2の署名を作成するようにさらに構成された署名作成器16と、前記第1および第2の署名が一致した場合に前記決定されたデバイスタイプは本物であると認める手段とを備えることを特徴とする請求項16に記載の通信デバイス。前記認証手段15がさらに、前記第1のヘッダ情報および前記第1の署名に関する情報を前記通信システム1に接続された他のデバイスに転送する手段と、前記他のデバイスにより前記第1のヘッダ情報の真偽の検証を要求する手段と、前記他のデバイスの検証で本物と確認されたら前記第1のヘッダ情報を本物として認める手段とを備えることを特徴とする請求項16に記載の通信デバイス。前記通信手段11が、HyperTextTransferProtocolHTTPおよびSimpleMailTransferProtocolSMTPから構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項16から18のいずれか一項に記載の通信デバイス。さらに、デジタル著作権管理DRM手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理DRMに準拠する旨のコミットメントであることを特徴とする請求項19に記載の通信デバイス。前記通信デバイスがサーバ10であることを特徴とする請求項16から20のいずれか1項に記載の通信デバイス。しかし、従来技術のデバイスの問題点は、どのような端末でも、たとえサポートしていなくてもDRMをサポートしているという合図を送ることが容易にできることである。DRM仕様に従ってその能力に関する情報を送信するか、または偽りのデバイス識別情報を送りさえすればよいのである。従来技術のシステムでは、コンテンツプロバイダは、デバイスによって主張されたことが本当に真実なのかを確実に知ることはできない。つまり、コンテンツプロバイダが貴重なコンテンツを、それとは知らずにDRM規則を課さない端末に送信するような状況も起こりえる。これらの端末は、したがって、DRM保護をたやすく破ることができ、コンテンツを制御されずに取り扱うことも可能である。そこで、本発明の一般的な目的は、通信システムにおいてデバイスタイプ認証を実現することである。本発明の他の目的は、信号を発する広範囲に及ぶ試みを回避するような方法およびデバイスを実現することである。上記の目的は、添付の特許請求項による方法およびデバイスによって達成される。要するに、情報を含む、好ましくはデバイスタイプ関連コミットメントと関係するヘッダに、さらにその情報用の署名を付与する。署名により、ヘッダ情報の信憑性が保証される。好ましくはそのデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、受信デバイスで不正使用防止になるように署名を作成する。ヘッダ情報および署名はコンテンツプロバイダへ伝送され、そこで、署名の検証が行われてから、デバイスタイプ関連コミットメントが有効であると認められる。このような署名をシステムで使用する場合には、HTTPまたはSMTPSimpleMailTransferProtocolを使用するのが好ましい。本発明の一実施形態では、署名の実際の検証は、通信システム内の別のデバイス、例えば、受信端末のメーカーに関係するデバイスで実行される。本発明の1つの利点は、信頼できるデバイスタイプ認証に冗長なデバイスタイプログイン手順を必要としないことである。ここで提案しているような署名は、現在のヘッダ構造に容易に組み込むことができる。本発明は、本発明の他の目的および利点とともに、以下の説明および添付の図面を参照することより最もよく理解できる。従来技術による解決方法の問題点を詳述するために、現在利用可能なさまざまなDRM手法について簡単に検討することからこの説明を始める。これ以降、本発明による解決方法について、多数の実施例を用いて説明する。図1は、一般的な通信システム1を示している。第1のデバイス、つまりこの説明ではコンテンツプロバイダとして動作するサーバ10は、第2のデバイス、つまり端末20に永続的にまたは一時的に確立された接続30により接続される。この例では、端末20のユーザは、メディアオブジェクト40をサーバ10からダウンロードすることを望んでいる。このために、HTTPGETメッセージが端末20からサーバ10に送信され、サーバ10が受信した情報と関連する状態を受け入れれば、メディアオブジェクト40を返すことができる。DRM仕様に関するOMAの提案では、3つの異なるDRMレベルがあり、図2~4に概略が示されている。DRMを使用することにより、コンテンツプロバイダはメディアオブジェクトを使用する際の規則または権利を定義することができる。さまざまな権利を単一のメディアオブジェクトに関連付けることが可能である。権利が異なれば、料金も異なるであろう。コンテンツプロバイダは、メディアオブジェクトを無料でプレビューする権利をユーザに付与し、完全な使用権についてのみユーザに課金するようにできる。価値はメディアオブジェクト自体を使用する権利にあるので、DRMによれば、メディアオブジェクト自体を販売するのではなく、メディアオブジェクトを使用する権利を販売することができる。特別な場合について、最初に、図2の順方向ロックに示されている。特定のコンテンツ44を含むメディアオブジェクト42からなるDRMメッセージ46は、コンテンツプロバイダから消費者デバイス20にWAPダウンロードされる。ここでは、別の権利オブジェクトは存在していない。その代わりに、権利はメディアオブジェクト42自体と組み合わされ、一組のデフォルトの権利がメディアオブジェクト42に与えられる。消費者が異なれば、配信されるメディアオブジェクトの権利に対する要求も異なることが多いため、このようなケースは採用しにくい場合が多い。図3には、組合せ配信が示されている。ここでは、メディアオブジェクト42のコンテンツ44および関連する権利48は、端末20によりダウンロードされた全く同一のDRMメッセージ46を使用して配信される。この解決方法は、権利48と実際のコンテンツ44との間で接続を維持しやすいためかなり容易である。図4には、別の配信方法が示されている。メディアオブジェクト43は不正使用ができないようにロックされ、コンテンツ44は関連する権利47が利用できる場合にのみユーザに利用を許可できる。したがって、関連する権利47は、ロックされたメディアオブジェクト43の鍵として動作する。セキュリティレベルを高めるために、ロックされたメディアオブジェクト43および権利47は、別々に端末に送信される。メディアオブジェクト43は、端末20によってダウンロードされる。権利は、未確認プッシュにより、端末20に供給することができる。端末20では、メディアオブジェクト43および権利47は、互いに関連付けられ、メディアオブジェクト43のコンテンツ44は、権利47の規則に応じてユーザに利用を許可することができる。WAPダウンロードDRM適用範囲では、2つの主要な問題が解決される。第1に、メディアオブジェクトの転送が禁止されることである。第2に、メディアオブジェクトの使用に対して特定の規則を定義することができる、つまり、あらゆる種類のプレビュー、アクセス回数制限、有効期間制限などを全く同じ概念で解決することができるということである。しかし、上で説明したように、端末が実際にDRMコミットメントに従っているという仮定にDRM概念全体が基づいているという点に大きな問題がある。DRM付きのコンテンツが端末に送信される前に、メディアオブジェクトを保持しているサーバが端末の能力に関する情報を受信する。これは、例えば、Accept、UserAgent、またはUAProfなどのHTTPヘッダを使用して実行する。端末では、DRM使用に従って能力に関する情報を送信するだけで、DRMをサポートしていることを主張する信号をサーバに送信することができる。しかし、サーバ側では、主張内容が本当に真実であるかどうかを見分けられない。つまり、コンテンツプロバイダが貴重なコンテンツを、それと知らずにDRM規則を課さない端末に送信する場合もありえるということである。そのため、これらの端末は、DRM保護をたやすく破り、自分の判断でコンテンツを使用することができる。上述のように、本発明による問題の解決方法は、ヘッダ情報自体の署名を導入することである。署名は、さまざまなデータオブジェクト、例えば、テキスト、実行可能ファイル、またはメディアファイルが本物かどうかの検証のため、さまざまなアプリケーションで使用されている。この場合、署名で保護されるのは実際のデータ内容ではなく、ヘッダ情報である。したがって、この署名を使用することにより、ヘッダ情報が正しいかどうかを検証することができる。この概念は、さまざまなアプリケーションで使用することも可能であるが、特に、デバイスタイプ関連コミットメントに関係するヘッダ情報の認証に特に適している。このようなコミットメントの代表的な例として、特定のDRMスキームに従うコミットメントがある。端末がapplication/vnd.oma.drm.messageという部分を含むHTTPヘッダを送信すると、暗黙のうちに、受信サーバに、端末がOMADRM規制に従うことを認めたと通知することになる。同様に、HTTPヘッダ情報にUserAgent:SEM4.6が含まれていると、端末がSonyEricssonMobile4.6ソフトウェアをベースとしていることを主張することになる。受信サーバはそのようなソフトウェアがDRMをサポートしていることを容易に知ることができ、したがってUserAgentヘッダは暗黙のうちにDRMに従うというコミットメントになる。さらに、HTTPヘッダUAProf:www.sem.com/phones/t68は暗黙のコミットメントである、というのも、T68携帯電話の主張するサポート内容を結論できるからである。本発明によれば、デバイスのサポートする能力を通知するヘッダには端末による署名が入る。その後、サーバは、署名の妥当性を確認し、送信者側が信頼できるデバイスであることを確認することができる。署名を作成する実際のプロセスは、従来技術の原理に従って実行することができる。しかし、ヘッダ情報の署名はまだ使用されたことがない。上記のヘッダの例では、HTTPはモデル通信プロトコルとして使用されていた。しかし、デバイス関連情報を含むヘッダを使用する、SMTPなどの他のプロトコルも使用することができる。本発明では、第1のヘッダ情報を使って、例えば、デバイスタイプ関連コミットメントを定義する。第2のヘッダ情報にその署名を入れる。第1のヘッダ情報と第2のヘッダ情報は、別々のヘッダに入れることもできるし、また全く同一のヘッダにまとめて入れることもできる。例えば、ヘッダUserAgentSignatureの代わりに、ヘッダUserAgentを修正して署名も入れられるようにできる。ほとんどの場合、第1のヘッダ情報と第2のヘッダ情報を両方とも全く同じ実際のメッセージに含めるのが便利である。しかし、第1のヘッダ情報を一方のメッセージに入れ、第2のヘッダ情報を他のメッセージ、好ましくは後のメッセージに入れて送ることも可能である。これら2つのメッセージは1つのまとめられたメッセージとしてみなし、2回に分けて伝送することが可能である。このようにヘッダ情報の伝送を分けることで、セキュリティのレベルが高まるが、その一方で、これらの部分メッセージを関連付ける付加的手段が受信側に必要になる。本開示では、メッセージという用語は、単一のメッセージを含むだけでなく、この段落の前のほうで述べたようなまとめられたメッセージを含むものとして解釈する。以下では、本発明の実装例をいくつか説明する。図5には、通信システム1が示されている。端末20は、ダウンロードエージェントSEM4.6を使用するダウンロード手段22および共有秘密情報24用の不正使用防止記憶装置23を備える。共有秘密情報24は、この実施形態では、SEM4.6ダウンロードエージェントを備える端末に固有の秘密データ文字列である。ダウンロード手段22により適切に指定されたルーチンでないと、この不正使用防止記憶装置23の内容を読み出すことはできない。次に、ダウンロード手段22は、通信システム1で他の当事者と通信する役割を果たす通信手段21、および通信手段21により送信されるメッセージのヘッダを作成するヘッダプロバイダ25を備える。本発明の一実施形態によれば、ダウンロード手段22は、さらに、署名作成器26も備える。端末20のユーザは、メディアオブジェクトをサーバ10を備えるコンテンツプロバイダからダウンロードすることを望んでいる。端末20は、対象となるメディアオブジェクト用にHTTPGETメッセージを用意し、ヘッダプロバイダ25は、ヘッダUserAgent:SEM4.6を作成する。ダウンロード手段22は、記憶装置23の共有秘密情報24の内容を読み出し、HTTPUser-Agentヘッダからデータを追加し、署名作成器26を通じて実行する。署名作成器は、この実施形態では、鍵付きメッセージダイジェスト、例えば、MD5である。HTTPヘッダから追加されたデータは、この特定の例では、SEM4.6というテキスト文字列である。MD5は、あるデータの128ビット固有表現を生成する一方向関数となっている。署名作成器26の計算からの出力結果はヘッダの署名を構成し、ヘッダプロバイダ25により、例えば、新しいヘッダUserAgentSignature:897y65ghdra48内に追加される。この実施形態では、ヘッダプロバイダ25は、元のヘッダ情報と、その署名からなるヘッダ情報の両方を作成する役割を果たす。今署名付きヘッダを有するHTTPGETメッセージは、サーバ10に送信される。サーバ10は、この実施形態では、共有秘密情報14-端末20と同じ共有秘密情報24-を含む。また、この共有秘密情報14は、不正使用が防止され記憶装置13に格納される。通信手段11がメッセージを受信する。サーバ10は、User-Agentヘッダに気づき、それをヘッダ情報の認証が必要なケースに関連付ける。ヘッダ情報は、User-Agent部分と署名部分を備えており、認証手段15に転送される。記憶装置13は、認証手段15に含まれるか、または接続されている。認証手段15内の署名作成器16は、記憶装置13からこのUserAgentと関連付けられた共有秘密情報14を読み出す。この共有秘密情報に対して、HTTPヘッダから得られるデータが追加され、端末20の署名作成器26と同じデータが追加される。署名作成器16は、このデータをMD5ルーチンに通し、独立した結果を得る。MD5からの計算された出力の値がHTTPヘッダの署名と同じであれば、元のHTTPUser-Agentヘッダは信頼できるものである。そこで、サーバは、検証済みのUser-Agentをマッピングし、端末がサポートしているDRMクラスを確認し、適当なDRMクラスに応じて要求されたメディアオブジェクトとともに返信する。当業者であれば、端末およびサーバ内のさまざまな手段は物理的デバイスというよりは機能手段であることを認識するであろう。端末およびサーバのさまざまな部分手段をソフトウェア、ハードウェア、またはそれらを混合したものとして実現できる。さらに、一体として実装するだけでなく、分散手段としても実装することができる。さらに、当業者であれば、さまざまな手段を互いに分離した状態に置くことも、一体化できることも理解するであろう。したがって、本開示の図に示されたブロック構造は、物理的なブロック構造であるというよりは、手段の機能を理解しやすくすることのみを目的としている。本発明の上記の実施形態では、共有秘密情報とHTTPヘッダ情報との混合をMD5手順の入力として使用されている。しかし、他の入力も可能である。HTTPヘッダ情報は完全に無視されることもありえるため、署名は共有秘密情報にのみ基づく。ただし。そのように生成された署名は、侵入者を引き寄せ、その侵入者の目的のために使用される可能性もある。以上で、端末とサーバとの間の通信について説明した。このような通信はもちろん、通信システム内の任意のデバイス間で実行することも可能である。しかし、通常の場合、サーバはメディアオブジェクトを提供する側であり、コンピュータ、携帯電話、オーディオプレーヤなどの端末は受信側である。署名作成は、端末とサーバの両方に知られている他の情報に基づくことも可能である。例えば、時刻と共有秘密情報とを混ぜて署名を生成することができる。これは、ある時刻にヘッダとともに送信した署名が、別の時刻に無効になるということを意味する。同様に、日付を使用して、明らかにランダムにすることもできる。また、特にはUser-Agentに接続されていない他のヘッダ情報をこのような目的に使用することも可能である。これらのすべての場合において、署名は、サーバがヘッダを受信したときに端末とサーバの両方に共通の情報に基づく。本発明の他の実施形態は図6に示されている。ここでは、記憶装置23および署名作成器26は一体化されている。この実施形態では、共有秘密情報24はアルゴリズムの定義を含み、これに基づき、署名が作成される。代表例の1つでは、ヘッダ情報SEM4.6および時刻が署名作成器26に入力される。署名作成器26は、記憶装置23から秘密アルゴリズム定義を読み込んで、それに従い、署名生成を実行する。サーバ側では、署名の検証を同様にして実行する。入力データ、つまりヘッダ情報と時刻が署名作成器16に入力されるが、これは、記憶装置13から取り出したアルゴリズム情報に依存する。結果とヘッダ署名との比較により、真偽が検証される。もちろん、図5および図6の実施形態を組み合わせることも可能であり、その場合、記憶装置13、23は共有データ秘密情報と共有アルゴリズム定義秘密情報の両方を格納している。当業者であれば、署名の信頼性は共有秘密情報の機密性に依存することを理解するであろう。共有秘密情報および署名アルゴリズムが知られている場合、侵入者は正しい署名もまたシミュレートすることができる。端末の場合、共有秘密情報は端末の製造時にメーカーによって用意され、この情報の不正取得を禁止する手段が存在する。実際にこの秘密情報を秘密に保つことがメーカーの利益につながっているため、メーカー側で強力な保護対策を講じるものと思われる。しかし、この手順を図5および図6の実施形態に従って運用する場合、共有秘密情報もまた、サーバ内に置かなければならない。この概念を利用するであろう関係企業、コンテンツプロバイダなどが多数存在するため、共有秘密情報を各サーバに分散させなければならない。つまり、重要情報を膨大な数のデバイスと膨大な数の関係企業に分散させなければならないということである。関与するサーバの共有秘密情報保護対策が不十分であったり、関与する関係企業のそのような秘密情報の日常的取り扱いが不完全であれば、署名保護の保全性は損なわれる可能性がある。図7では、共有秘密情報を多数の当事者に分散する危険性を減じる、本発明の他の実施形態を示している。端末側は、図5に示されているのと同様である。しかし、サーバ10の認証手段15は、共有秘密情報自体を含まない。その代わりに、本発明では、認証手段15は第三者に認証要求を転送する手段、つまりセーフサーバ50を備える。認証手段15は、User-Agentヘッダ情報を読み込んで、このユーザエージェントに認証サービスを提供するセーフサーバ50を調べる。セーフサーバ50は、注意深く管理された共有秘密情報を取り扱うためのハードウェアおよびルーチンを含む。例えば、端末20のメーカーは、このようなセーフサーバ50をきちんと用意し、共有秘密情報を不正使用防止策を講じたうえで提供していることを保証することができる。認証手段15からの認証要求には、サーバ10に届いたヘッダ情報、特に、署名の作成および署名自体で使用される部分が含まれる。セーフサーバ50は、この情報を受信すると、不正使用防止策が講じられている署名検証手順を実行する。署名検証では、共有秘密情報に関する知識を利用する。署名が検証されれば、そのヘッダ情報が本物であることを知らせる返信が認証手段15に送り返される。検証されなければ、偽の署名であることを通知する返信が送り返される。セーフサーバ50が検証を行って本物であることが確認されれば、そのヘッダ情報はサーバ10によって本物であると認められ、例えば、適当なDRMルーチンに従って、メディアオブジェクトを安全に配布することができる。サーバ10は、異なるセーフサーバ51~53にさらに接続可能であることが好ましく、各サーバは1つまたはいくつかのユーザエージェント、アプリケーション定義、またはデバイスタイプの共有秘密情報を保証する。元のヘッダ情報から、真偽検証の要求を行うためセーフサーバ50~53のうちの1つとコンタクトをとらなければならないと結論される。同様に、他のコンテンツプロバイダの所有する他のサーバ60、61も同じセーフサーバ50~53に接続可能である。この構成では、共有秘密情報が1つまたは少数の非常に信頼できるサーバで利用可能であれば十分である。したがって完全に異なるレベルまでの機密性を保証できる。この概念は、セーフサーバとコンテンツプロバイダとの間の信頼できる関係に基づいている。コンテンツプロバイダは、メディアオブジェクトを配布するリスクを負う側の当事者である。しかし、セーフサーバの事業者、例えば、端末メーカーは、不正使用を目的にその秘密情報にアクセスし得ないことを保証する。図8は、本発明による方法の実施形態の主要なステップの流れ図である。手順は、ステップ200から始まる。ステップ202では、通信メッセージの第1のヘッダ情報が第1のデバイスにおいて供給される。第1のヘッダ情報は、デバイスタイプ関連コミットメントと関連付けられている情報を含むのが好ましい。ステップ204で、第1の署名は不正使用防止策を講じたうえで第1のデバイスにおいて作成される。署名作成は、少なくとも、第1のヘッダ情報の少なくとも一部と関連付けられている不正使用防止情報に基づく。ステップ206で、通信メッセージの第2のヘッダ情報として署名が供給される。ステップ208で、メッセージは、第1のデバイスの接続先の通信システムの他のデバイスに伝送される。最後に、ステップ210で、メッセージが第2のデバイスに届いた後に前記第1の署名を検証することにより、第1のヘッダ情報が認証される。ステップ212で手順は終了する。本発明による方法の他の好ましい実施形態は、前の説明から容易に推論できる。当業者であれば、付属の請求項で定義された、本発明の範囲を逸脱することなく、さまざまな修正および変更を本発明に加えられることを理解するであろう。