JP2009526321A - 変化する識別子を使用して販売時点情報管理端末において取引を実行するためのシステム - Google Patents

Abstract

第１のエンティティと第２のエンティティの間の取引をポイント・オブ・セール（ＰＯＳ）端末において実行する際に使用されるＰＯＳ端末。ＰＯＳ端末は第２のエンティティに関連付けられる。ＰＯＳ端末は、第２の変化識別子を記憶し、通信リンクを介して口座情報保持体デバイスから暗号化された取引情報を受け取り、暗号化された第１および第２の取引情報を認証手段へ送り、認証手段から第２の変化識別子を受け取る。プロセッサは、第２の暗号化された取引情報を生成するために、第２の変化識別子を用いて取引情報を暗号化するように構成される。

Description

関連出願
本出願は、２００６年２月８日に出願された米国仮出願第６０／７７１３６６号、および第６０／７７１３９８号の優先権を主張し、両出願の内容全体が、参照により本明細書に組み込まれる。本出願はまた、２００６年３月６日に出願された米国出願第１１／３６８９５９号の一部継続出願であり、同出願は、２００５年１１月２３日に出願された米国出願第１１／２８６８９０号の一部継続出願であり、同出願は、２００４年５月２６日に出願された米国出願第１０／８５４６０４号の一部継続出願であり、同出願は、２００３年２月２７日に出願された米国出願第１０／２４８８９４号の一部継続出願であり、同出願は、２００２年２月２７日に出願された米国仮出願第６０／３６００２３号の優先権を主張し、上記すべての出願の内容全体が、参照により本明細書に組み込まれる。

クレジット・カード、デビット・カード、および他の非現金の支払い形態を用いることが増加するにつれて、支払い口座にアクセスするために使用される口座情報は、取引に関与する主体（ｅｎｔｉｔｙ、エンティティ）の間で、安全に送信されなければならない。従来、口座情報は、売主（ベンダ）の販売時点情報管理（ＰＯＳ：ｐｏｉｎｔ−ｏｆ−ｓａｌｅ、ポイント・オブ・セール）端末により取得され、売主と支払認証手段（ｐａｙｍｅｎｔ ａｕｔｈｅｎｔｉｃａｔｏｒ、支払認証者）との間で安全な通信リンクを介して送信される。

しかし、上記のプロトコルでは、口座情報は、平文として売主へ提供され、口座情報が安全な通信リンク上で何らかの方法で盗聴者により奪取された場合、盗聴者は、その口座情報を使用して、偽取引を開始することができる。

本発明の実施形態は、ミューテーティング識別子（ＩＤ）（ｍｕｔａｔｉｎｇ ｉｄｅｎｔｉｆｉｅｒ、変化識別子）を使用して、売主のＰＯＳデバイスにおいて取引を行うための方法およびシステムを提供する。具体的には、本発明の実施形態は、セルラ電話、携帯情報端末（ＰＤＡ）、オーディオ・プレーヤ（例えば、ムービング・ピクチャ・エキスパート・グループ・レイヤ３オーディオ（ＭＰ３）プレーヤ）などの、買手に関連する口座情報保持体（ＡＩＣ：ａｃｃｏｕｎｔ ｉｎｆｏｒｍａｔｉｏｎ ｃａｒｒｉｅｒ）デバイスを使用して、１回限り使用可（ｏｎｅ−ｔｉｍｅ−ｕｓｅ）の変化するＩＤ（変化ＩＤ）を用いて口座情報を暗号化するための方法およびシステムを提供する。ＡＩＣデバイスは、買手の１または複数の口座に関する口座情報と、信用できるオーセンティケータ（認証手段）により割り当てられた１回限りの変化ＩＤを記憶する。買手が取引を開始すると、ＡＩＣデバイスは、１回限り使用可の変化ＩＤを用いて口座情報を暗号化し、暗号化された口座情報を売主のＰＯＳ端末へ送信する。売主のＰＯＳ端末は、暗号化された口座情報と、取引情報（例えば、取引価格および売主の識別子）を、検証および／または支払い承認および完了のために、認証手段へ送る。幾つかの実施形態では、ＡＩＣデバイスはまた、１回の取引のためだけに使用でき、その後は再使用できない１回限り使用可の口座情報も、認証手段（例えば、ＡＩＣデバイスのユーザの口座を管理する支払い認証手段）から取得する。

本発明の幾つかの実施形態は、第１のエンティティと第２のエンティティの間の取引を第２のエンティティに関連したＰＯＳ端末の物理位置において実行する方法を提供する。１つの方法は、暗号化された買手取引情報を生成するために、第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、買手取引情報を暗号化するステップと、暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送信するステップと、暗号化された売主取引情報を生成するために、ＰＯＳ端末に記憶された第２の変化識別子を用いて、売主取引情報を暗号化するステップと、暗号化された売主取引情報を、少なくとも１つの通信リンクを介して、ＰＯＳ端末から認証手段へ送信するステップと、口座情報保持体デバイスにおいて、第３の変化識別子を認証手段から受け取るステップと、ＰＯＳ端末において、第４の変化識別子を認証手段から受け取るステップと、認証手段において、第１の変化識別子および第２の変化識別子を使用済としてマーク付けするステップと、を含む。

本発明の他の実施形態は、認証手段により、第１のエンティティと第２のエンティティの間の取引を第２のエンティティのＰＯＳ端末の物理的位置において管理する方法を提供する。１つの方法は、第１の変化識別子を、少なくとも１つの通信リンクを介して、第１のエンティティに関連した口座情報保持体デバイスに提供するステップと、第２の変化識別子を、少なくとも１つの通信リンクを介して、ＰＯＳ端末に提供するステップと、暗号化された取引情報を、少なくとも１つの通信リンクを介して、口座情報保持体デバイスおよびＰＯＳ端末の少なくとも一つから受け取るステップと、を含む。取引情報は、第１の変化識別子および第２の変化識別子の少なくとも一つを用いて暗号化される。本方法はまた、暗号解除された取引情報を取得するために、第１の変化識別子および第２の変化識別子の少なくとも一つを用いて、暗号化された取引情報を暗号解除するステップと、暗号解除された取引情報に基づいて、支払い要求を生成するステップと、支払い要求を、少なくとも１つの通信リンクを介して、支払い認証手段に送信するステップと、第１の変化識別子および第２の変化識別子を使用済としてマーク付けするステップと、を含む。

更なる実施形態は、第１のエンティティと第２のエンティティの間の取引をＰＯＳ端末において管理するためのシステムを提供する。１つのシステムは、認証手段と、第１のエンティティに関連した口座情報保持体デバイスと、第２のエンティティに関連したＰＯＳ端末とを含む。認証手段は、第１の変化識別子を口座情報保持体デバイスに割り当て、第２の変化識別子をＰＯＳ端末に割り当て、第３の変化識別子を支払い認証手段に割り当てるように、構成される。口座情報保持体デバイスは、第１の暗号化された取引情報を生成するために、第１の変化識別子を用いて第１の取引情報を暗号化し、暗号化された第１の取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送信するように、構成される。ＰＯＳ端末は、第２の暗号化された取引情報を生成するために、第２の変化識別子を用いて第２の取引情報を暗号化し、また、暗号化された第１の取引情報を少なくとも１つの通信リンクを介して認証手段へ送信するように、構成される。認証手段はまた、第１の取引情報を取得するために、第１の変化識別子を用いて、第１の暗号化された取引情報を暗号解除し、第２の取引情報を取得するために、第２の変化識別子を用いて、第２の暗号化された取引情報を暗号解除し、第１の取引情報および第２の取引情報に基づいて、支払い要求を生成し、暗号化された支払い要求を生成するために、第３の変化識別子を用いて、支払い要求を暗号化し、暗号化された支払い要求を、少なくとも１つの通信リンクを介して、支払い認証手段へ送信し、また、第１の変化識別子および第２の変化識別子を使用済としてマーク付けするように、構成される。

本発明の更なる実施形態は、第１のエンティティと第２のエンティティの間の取引を第２のエンティティに関連したＰＯＳ端末において実行する際に使用される口座情報保持体デバイスを提供する。１つの口座情報保持体デバイスは、メモリ・モジュールと、入力／出力モジュールと、プロセッサとを含む。メモリ・モジュールは、第１の変化識別子を記憶するように構成される。入力／出力モジュールは、暗号化された取引情報を、少なくとも１つの通信リンクを介して、ＰＯＳ端末に送り、また、第１の変化識別子を認証手段から受け取るように、構成される。プロセッサは、暗号化された取引情報を生成するために、第１の変化識別子を用いて、取引情報を暗号化するように構成される。

本発明の実施形態はまた、第１のエンティティと第２のエンティティの間の取引をＰＯＳ端末において実行する際に使用されるＰＯＳ端末を提供し、ＰＯＳ端末は、第２のエンティティに関連付けられる。１つのＰＯＳ端末は、メモリ・モジュールと、入力／出力モジュールと、プロセッサとを含む。メモリ・モジュールは、第２の変化識別子を記憶するように構成される。入力／出力モジュールは、暗号化された第１の取引情報を、少なくとも１つの通信リンクを介して、第１のエンティティに関連した口座情報保持体デバイスから受け取り、暗号化された第１の取引情報および暗号化された第２の取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送り、また、第２の変化識別子を認証手段から受け取るように、構成される。プロセッサは、暗号化された第２の取引情報を生成するために、第２の変化識別子を用いて取引情報を暗号化するように構成される。

本発明の他の実施形態は、第１のエンティティと第２のエンティティの間の取引を第２のエンティティに関連したＰＯＳ端末の物理的位置において管理するための認証手段を提供する。１つの認証手段は、メモリ・モジュールと、入力／出力モジュールと、プロセッサとを含む。メモリ・モジュールは、第１のエンティティに関連した口座情報保持体デバイスに割り当てられる第１の変化識別子を記憶し、ＰＯＳ端末に割り当てられる第２の変化識別子を記憶し、また、支払い認証手段に割り当てられる第３の変化識別子を記憶するように、構成される。入力／出力モジュールは、第１の変化識別子を、少なくとも１つの通信リンクを介して、口座情報保持体デバイスに送信し、第２の変化識別子を、少なくとも１つの通信リンクを介して、ＰＯＳ端末に送り、第３の変化識別子を、少なくとも１つの通信リンクを介して、支払い認証手段に送り、また、暗号化された第１の取引情報および暗号化された第２の取引情報を、少なくとも１つの通信リンクを介して、ＰＯＳ端末から受け取るように、構成される。プロセッサは、第１の取引情報を取得するために、第１の変化識別子を用いて、第１の暗号化された取引情報を暗号解除し、第２の取引情報を取得するために、第２の変化識別子を用いて、第２の暗号化された取引情報を暗号解除し、第１の取引情報および第２の取引情報に基づいて、支払い要求を生成し、暗号化された支払い要求を生成するために、第３の変化識別子を用いて、支払い要求を暗号化し、また、第１の変化識別子および第２の変化識別子を使用済としてマーク付けするように、構成される。入力／出力モジュールはまた、暗号化された支払い要求を、支払い認証手段に送信するように構成されることができる。

本発明の実施形態を詳細に説明する前に、本発明は、その応用において、以下の説明において説明される、または図面において例示される構成要素の構造および構成に細部にわたって限定されないことを理解されたい。本発明は、更に他の実施形態が可能であり、様々な方法で実行または実施されることが可能である。

具体的には、幾つかの実施形態は、パーソナルまたはホーム・コンピュータ、サーバ、およびプロセッサを有し、またはプログラム、即ち、命令の組を実行することが可能な他のデバイスなどのような様々なコンピュータ・デバイスを使用して実施され、他のデバイスには、セット・トップ・ボックス（例えば、デジタル・ケーブルまたは衛星のデコーダ）などの専用デバイスも含まれることを理解されたい。一般に、幾つかの実施形態は、既存のハードウェア、または当業者により容易に作成され得るハードウェアを使用して、実施されることができる。従って、例示的なデバイスのアーキテクチャは、デバイスが一般に、プロセッサと、メモリ（何らかの種類）と、入力および出力機構とを有することに言及する以外は、詳細には説明されない。幾つかの場合、デバイスはまた、１または複数のオペレーティング・システムと、オペレーティング・システムにより管理される１または複数のアプリケーション・プログラムとを有することができる。幾つかの実施形態では、ハードウェア・デバイス、またはハードウェア・デバイスにより実行されるソフトウェアはまた、実施される本発明の具体的な実施形態におけるデバイスの役割に応じて、データを圧縮もしくは伸張（圧縮解除）するため、またはデータを符号化もしくは暗号化データを復号するための何らかの能力も提供する。幾つかの実例では、伸張機能は、ハードウェア実装のムービング・ピクチャ・エキスパート・グループ（ＭＰＥＧ）コーダなどのような、使用可能なコーデックを使用して提供されることができる。暗号解除機能は、特定の暗号化アルゴリズムを使用して暗号化されたデータを暗号解除することが可能な暗号解除ハードウェアまたはソフトウェア・モジュールを使用して、提供されることができる。幾つかの実施形態では、暗号化アルゴリズムは、ラインダール（Ｒｉｊｎｄａｅｌ）アルゴリズムを含み、その一例のものは、ｈｔｔｐ：／／ｗｗｗ．ｅｓａｔ．ｋｕｌｅｕｖｅｎ．ａｃ．ｂｅ／〜ｒｉｊｍｅｎ／ｒｉｊｎｄａｅｌ／ｒｉｊｎｄａｅｌｒｅｆ．ｚｉｐにおいて入手可能である。

図１は、ネットワークを介してコンテンツを配布するように構成された例示的なシステム２０を示している。実際には、当業者に明らかなように、私的ネットワーク（即ち、イントラネット）、インターネット、電話システム、無線ネットワーク、衛星ネットワーク、ケーブルＴＶネットワーク、ならびに様々な他の私的および公的ネットワークおよびシステムなど、１または複数のネットワークまたは通信システムが、本発明の実施形態または実装を行うために要望されるまたは必要とされる通信リンクを提供するために、様々な組み合わせで使用されることができる。従って、本発明は、特定のネットワークまたはネットワークの組み合わせに限定されない。しかし、幾つかの実施形態では、システム２０において使用されるネットワークまたは通信システムは、あるバージョンのラインダール暗号化を用いて暗号化されたデータを含む通信、セキュア・ソケット・レイヤ（ＳＳＬ：ｓｅｃｕｒｅｄ ｓｏｃｋｅｔ ｌａｙｅｒ）通信、デジタル署名標準（ＤＳＳ：ｄｉｇｉｔａｌ ｓｉｇｎａｔｕｒｅ ｓｔａｎｄａｒｄ）通信、または他のタイプのセキュア通信プロトコルなどの、デジタルおよび／またはセキュアな通信をサポートするための能力を有する。更に、データは、１つのエンティティから別のエンティティに、有線通信および／もしくは無線通信を用いて、または１つのエンティティから別のエンティティへ物理的に搬送される他の物理媒体を用いて、伝達されることができる。

図１に示される実施形態では、システム２０は、３つの参加者、即ち、第１のデバイス２２と、第２のデバイス２４と、認証者デバイス即ち認証手段２８とを含む。図１に示される例示的な実施形態では、第１のデバイス２２が、第２のデバイス２４に送信されるデータを保有すると仮定される。図１は、第１のデバイス２２および第２のデバイス２４を示すだけであるが、幾つかの実施形態では、システム２０には多くのデバイスが含まれ、少なくとも１つのデバイスが、別のデバイスに送信されるデータを保有する。更に、幾つかの実施形態では、システム２０は、複数の認証手段２８を含む。

第１のデバイス２２、第２のデバイス２４、および認証手段２８は、２方向リンク３０、３２、３８を介して、互いに接続される。リンク３０、３２、３８は、上述の１または複数のネットワークの全部または一部を含むことができる。幾つかの実施形態では、システム２０は、ラインダール・アルゴリズムなどのような、鍵ベースの暗号化アルゴリズムを使用する。システム２０で使用されるアルゴリズムの選択は、アルゴリズムの強度（解読に対する）とアルゴリズムのスピード（選択されたアルゴリズムにより必要とされる数学的演算を実行するためのプロセッサ能力に関する）との間のトレード・オフを含む様々な要因に依存し得る。

幾つかの実施形態では、図１に示されるように、認証手段２８は、システム２０が実施または準拠するプロトコルにより使用される数（番号）を生成するために、乱数発生器３９を使用する。乱数発生器３９は、真にランダムな数（即ち、本発明を実施するために使用される特定の技術を用いた中で可能な限りランダムな数）を生成することができる。例えば、コンテンツを取得するための顧客からの要求などの通信トラフィックは、乱数を生成するために使用されることができる。そのようなトラフィックは一般に、予測不可能に発生する。従って、アルゴリズム的方法を用いて生成される疑似乱数とは対照的に、そのようなトラフィックに基づいて生成される乱数もまた、真にランダム又はほぼ真にランダムである。

幾つかの実施形態では、第１のデバイス２２および第２のデバイス２４は、データを送信するために、変化ＩＤを使用する。例示的な変化ＩＤ３８が、図２に示されている。変化ＩＤ３８は、２つの部分、即ち、第１の部分４０と、第２の部分４２とを有する識別子である。第１の部分４０は、識別番号を含み、それは乱数である。図２に示されるように、幾つかの実施形態では、変化ＩＤの２つの部分は各々、所定数のビットを含む。例えば、第１の部分４０および第２の部分４２は各々、２５６ビットを含むことができる。他の実施形態では、第１の部分４０および／または第２の部分４２は、１メガビットや１メガバイトなどのように、より多数のビットを含む。

変化ＩＤ３８の第２の部分４２は秘密鍵を含み、秘密鍵は、やはり乱数であり、幾つかの実施形態では、対称暗号鍵である。変化ＩＤは、１回だけ使用されることができ、その後は再使用できない。

なお、図２は、２つの部分のみを有する変化ＩＤを示しているが、変化ＩＤは、付加的な区画または部分を含むことができる。例えば、変化ＩＤは、識別番号と、第１のタイプのデータ（例えば、発見可能（ｄｉｓｃｏｖｅｒａｂｌｅ）データ）用の秘密鍵と、第２のタイプのデータ（例えば、発見不可能（ｕｎｄｉｓｃｏｖｅｒａｂｌｅ）データ）用の秘密鍵とを含むことができる。

変化ＩＤは、認証手段２８により生成され、追跡される。変化ＩＤは、１回限り使用可の機構であるので、第１のデバイス２２、第２のデバイス２４、または別のデバイスは、ひとたび、供給された変化ＩＤ（例えば、単一の変化ＩＤまたは複数の変化ＩＤ）を使用すると、そのデバイスは、認証手段２８から別の変化ＩＤ（または妥当な場合には複数の変化ＩＤ）を取得する。特定のデバイスに割り当てられる変化ＩＤに含まれるデータは、すべての変化ＩＤの場合と等しい確率で、ランダムに選択されることができる。

図３ａおよび図３ｂは、変化ＩＤが、認証手段２８から第１のデバイス２２または第２のデバイス２４へどのように配布され得るかを示している。図３ａに示されるように、幾つかの実施形態では、第１のデバイス２２または第２のデバイス２４などのデバイス４３は、認証手段２８に複数の変化ＩＤを要求する。認証手段２８は、デバイス４３が要求した数の変化ＩＤを生成し、変化ＩＤの一覧（リスト）をデバイス４３へ送る。デバイス４３は、要求した変化ＩＤの数量および各変化ＩＤのサイズを知っており、そのリストを個々の変化ＩＤへと分割する。幾つかの実施形態では、認証手段２８は、変化ＩＤのリストを個々の変化ＩＤに分割するデバイス４３を援助するために、情報または命令をデバイス４３へ提供する。例えば、認証手段２８は、拡張マークアップ言語（ＸＭＬ）などのデータ記述言語を使用して、デバイス４３が変化ＩＤのリストを分割することを援助するために、情報または命令をデバイス４３に提供することができる。

図３ｂに示されるように、幾つかの実施形態では、デバイス４３は、認証手段２８から単一の変化ＩＤを受け取ることができる。デバイス４３は、認証手段２８に変化ＩＤを要求した際に、単一の変化ＩＤを受け取ることができ、または、先に提供された変化ＩＤを使用した際に認証手段２８から新しい変化ＩＤを自動的に受け取ることができる。変化ＩＤは、デバイス４３へ送られ、先にデバイス４３に提供または割り当てられた変化ＩＤに取って代わる。

図１に示される実施形態では、認証手段２８は、第１のデバイス２２に変化ＩＤ（この例ではこれ以降「第１変化ＩＤ」と呼ばれる）を、また、第２のデバイス２４に変化ＩＤ（この例ではこれ以降「第２変化ＩＤ」と呼ばれる）をランダムに割り当て又は提供する。第１変化ＩＤは、第２変化ＩＤとは異なり、第１変化ＩＤおよび第２変化ＩＤの各々は、他の変化ＩＤを決定するための情報を提供しない。図２に関して上述したように、各変化ＩＤは、乱数４０と、対応するランダムな秘密鍵４２とを含む。幾つかの実施形態では、変化ＩＤは、モディファイド・ハッシュ（ｍｏｄｉｆｉｅｄ ｈａｓｈ、変更されたハッシュ）の形態を取る。上述したように、ランダムであることに加えて、変化ＩＤ（または妥当な場合はハッシュ）は、それぞれの使用の後に廃棄される。言い換えると、認証手段２８は、デバイスが変化ＩＤを使用した後、新しい乱数４０と新しいランダムな秘密鍵４２とを有する新しい変化ＩＤをデバイスに提供する。幾つかの実施形態では、変化ＩＤは、それを使用するデバイスとは完全に無関係である。即ち、変化ＩＤまたはハッシュは、変化ＩＤを受け取って使用するデバイスの正体に関するどのような情報も含まない。このようにして、認証手段２８を除いて、個々のデバイスは、システムに含まれる他のデバイスの正体について認識できない。

本発明の幾つかの実施形態は、対称鍵システムを実施する。対称鍵システムは一般に、システムを成すエンティティまたは関与者の数が多くなると、鍵の管理の問題に遭遇する。例えば、ｎ個のエンティティから成るネットワークは、すべてのエンティティが互いに通信することを可能にするために、ｎ（ｎ−１）／２個の鍵を必要とする。従って、１０００個のエンティティから成るシステムは、個々のエンティティがすべて、他のすべてのエンティティに同一コンテンツを送ることを望む場合、ほぼ５０万個の鍵が必要となる。

しかし、開示される実施形態は、システムを成すエンティティのすべての対ごとに別個の鍵を必要としない。説明されるように、各エンティティと、各エンティティにより配布されるコンテンツの各部分は、１つの鍵を受け取り、その鍵は、それぞれの使用の後に変化（ｍｕｔａｔｅ）させられる。従って、１０００個のエンティティから成るシステムの場合、先の対称鍵システムを用いた場合のほぼ５０万個の鍵とは対照的に、僅か２０００個の鍵が必要とされる。また、認証手段２８は、変化ＩＤのビット列全体を記憶することを要求されない。認証手段２８は、変化ＩＤの各鍵部分を変化ＩＤの対応する番号に基づいてメモリ記憶位置にマッピングするために、ハッシュ関数または単に位置インデックスを使用することができる。

本発明の実施形態と従来のセキュリティ・システムとの間の他の相違は、速度と、ある種の攻撃に対する脆弱性の低下とに関する。例えば、対称鍵の使用は、高速な計算を可能にする（公開鍵システムと比べて）。公開鍵システムの背後にある基本的考えは、一方向性関数の使用である。一方向性関数は、計算するのは容易であるが、その逆計算は困難である。公開鍵システムは、一方向性関数を逆方向で計算するために、トラップドア一方向性関数（ｔｒａｐｄｏｏｒ ｏｎｅ−ｗａｙ ｆｕｎｃｔｉｏｎ）を使用する。公開鍵システムを使用するシステムは、各参加者に公開鍵と私有鍵（秘密鍵）を提供する。公開鍵は、すべての参加者によりアクセス可能であり、関連する私有鍵は、その私有鍵に関連する参加者によってのみ知られている。参加者は、一方向性関数を使用して、ある特定の参加者に宛てたメッセージを暗号化するため、またはその特定の参加者から受け取ったメッセージを暗号解除するために、公開鍵を使用する。参加者は、他の参加者に宛てたメッセージ（その参加者用の関連する公開鍵を使用して他の参加者が暗号解除できる）を暗号化するため、または他の参加者から受け取ったメッセージ（その参加者用の関連する公開鍵を用いて暗号化された）を暗号解除するために、（公開鍵から導出することは計算的に実行不可能であると信じられている）各自の秘密の私有鍵を使用する。

公開鍵システムのセキュリティは、私有鍵は公開鍵から導出され得ないという仮定に依存している。この要件を維持するため、公開鍵システムにおいて使用される一方向性関数は複雑である。しかし、追加される複雑さは、追加される計算時間という犠牲を払うことになる。公開鍵システムはしばしば、対称鍵システムよりも１０００倍遅い。

対称鍵の使用はまた、選択平文攻撃（ｃｈｏｓｅｎ ｐｌａｉｎｔｅｘｔ ａｔｔａｃｋ）の有効性を低下させる。選択平文攻撃は、侵入者が暗号化鍵またはプロセスにアクセスし、暗号化する特定の平文を選択し、暗号化されたテキストから知識を得ようと試みるときに生じる。公開鍵システムでは、ある個人の公開鍵は、通信システムのすべての参加者に知られている。どの侵入者も、ある個人の公開鍵を使用して、数限りないメッセージを暗号化することができる。攻撃者が、ある個人の公開鍵を用いて、あり得るメッセージを暗号化し、その後、その個人に送られた暗号化メッセージを傍受した場合、侵入者は、傍受したメッセージを、自分が生成したメッセージと比較することができる。傍受メッセージが、侵入者により生成された暗号化メッセージと一致した場合、メッセージは、危険にさらされ、侵入者は、自分に宛てられたものではないメッセージを読むことができる。この攻撃は、あり得るメッセージが僅かな数しか存在しない場合、相対的に容易かつ有効であり、また、あり得るメッセージの数が、侵入者が暗号化できる数または傍受された暗号化メッセージと比較できる数を超えている場合であっても、傍受された暗号化メッセージが特定のメッセージと一致しないことを知るだけで、侵入者に有用な情報を提供することができる。どちらの状況においても、侵入者は、個人の私有鍵を推論することはできないが、その個人に送られたメッセージまたはメッセージに関する情報を推論できることがある。本発明の実施形態は対称鍵システムを使用するため、暗号化鍵は公開の知識ではないので、選択平文攻撃は適用可能ではない。

従来の対称鍵システムおよび公開鍵システムには、別の問題も存在する。無権限（無許可）のエンティティが鍵へのアクセスを取得すると、その無権限のエンティティは、その鍵を用いて暗号化されたすべてのメッセージを復号することができ、おそらく、より危険なこととして、システムの他のエンティティを欺くために、その鍵を用いて偽メッセージを暗号化することができる。変化ＩＤプロトコルは、各秘密鍵をそれが使用された後に変異させることにより、この脆弱性を低下させる。鍵が危険にさらされたとしても、その危険にさらされた鍵は、認証手段２８により「使用済」としてマーク付けされており、従って、将来のメッセージ用に使用できず、使用されないので、将来のメッセージを生成するために使用されることも、また将来のメッセージを暗号解除するために使用されることもできない。

認証手段２８はまた、システム２０を介して配布されるコンテンツまたはデータのための暗号化鍵を生成することもできる。暗号化鍵を要求するため、データを送りたいデバイス（即ち、「送信デバイス」）は、送信したいデータ、または送信したいデータのラベルもしくは関数（即ち、任意の識別ストリング）を認証手段２８に供給し、認証手段２８は、関連する暗号化鍵により応答する。暗号化鍵は、変化ＩＤと同様に、それが暗号化するデータとは無関係とすることができる。加えて、送信デバイスが、送信したいデータの識別子（例えば、ランダムな識別子）だけを認証手段２８に送る場合、認証手段２８は、特定の暗号化鍵に関連するデータについての知識を有さない。認証手段２８は、割り当てられた鍵と、関連するデータまたはデータの識別子を記録する。

認証手段２８が、暗号化鍵を生成し、それを送信デバイスに供給した後、送信デバイスは、暗号化鍵を使用して、データを暗号化する。送信デバイスは、その後、暗号化データをデバイスに送る。暗号化データを暗号解除するため、暗号化データを受け取ったデバイス（即ち、「受信デバイス」）は、対応する暗号解除鍵（例えば、データを暗号化するのに使用されたのと同じ鍵）を認証手段２８に要求する。幾つかの実施形態では、認証手段２８は、システム２０に含まれる合法的要求を行った何れのデバイスにも、暗号解除鍵を供給する。暗号解除鍵の要求は、受信デバイスが暗号解除したいデータへの参照（例えば、データのラベルまたは識別ストリング）を含むことができる。認証手段２８は、要求で指示されたデータへの参照に基づいて、関連する暗号解除鍵を決定し、適切な暗号解除鍵を受信デバイスに返す。

本発明の例示的な実施形態を、幾つかの例を使用して説明される。通信プロトコルについての多くの説明と同様に、様々なデバイス（またはそれらのデバイスに関連するコンピュータ・システム）には名前が割り当てられる。一実施形態では、アリス（Ａ）およびボブ（Ｂ）は、第１のデバイス２２および第２のデバイス２４をそれぞれ表し、トレント（Ｔ）は、認証手段２８、通信の信用できるアービタ（ａｒｂｉｔｅｒ）を表す。キャロル（Ｃ）はまた、システム２０に含まれる第３のデバイスを表す。以下の表１は、提案されるプロトコルの複数の実施形態を説明するために本文書において使用される他のシンボルのリストである。

セッション鍵
幾つかの実施形態では、２つのエンティティの間で通信やセッション鍵を交換するために、変化ＩＤが使用される。例えば、アリスとボブは、アリスとボブにより共有されるセッション鍵を使用して、安全に通信したがっていると仮定する。アリスおよびボブは、トレントを信用していること、トレントは、番号Ｎ_Ａと何らかの対称暗号用の秘密鍵Ｋ_Ａとを含む変化ＩＤをアリスに割り当て、また番号Ｎ_Ｂと何らかの対称暗号用の秘密鍵Ｋ_Ｂとを含む変化ＩＤをボブに割り当てることを仮定する。また、アリスおよびボブは各々、トレントおよび信用証明書の保有者だけが知っている信用証明書（例えば、それぞれＡ_ｃｒｅｄおよびＢ_ｃｒｅｄ）を有することを仮定する。

セッション鍵（例えば、Ｋ_ＡＢ）をトレントに要求するために、アリスは、アリスの信用証明書Ａ_ｃｒｅｄおよびボブの識別子（例えば、Ｂ_ｉｄ）をアリスの秘密鍵Ｋ_Ａを用いて暗号化し、その結果できたものへ、アリスの番号Ｎ_Ａを追加する。アリスは、ボブにメッセージを送る。

Ａ→Ｂ：Ｎ_ＡＥ（Ｋ_Ａ，Ａ_ｃｒｅｄＢ_ｉｄ）

ボブは、アリスからのメッセージに、ボブの信用証明書Ｂ_ｃｒｅｄおよびアリスの識別子（例えば、Ａ_ｉｄ）を連結し、その結果をボブの秘密鍵Ｋ_Ｂを用いて暗号化する。ボブは、暗号化の結果としてできたものへボブの番号Ｎ_Ｂを追加し、その結果のメッセージをトレントに送る。

Ｂ→Ｔ：Ｎ_ＢＥ（Ｋ_Ｂ，Ｂ_ｃｒｅｄＡ_ｉｄＮ_ＡＥ（Ｋ_Ａ，Ａ_ｃｒｅｄＢ_ｉｄ））

トレントは、番号Ｎ_Ｂがボブに関連付けられていることを知っているので、メッセージがボブから来たことを識別する。トレントは、そのメッセージをＫ_Ｂ（即ち、番号Ｎ_Ｂに関連して割り当てられた秘密鍵）を使用して暗号解除し、ボブの信用証明書Ｂ_ｃｒｅｄを検証する。トレントはまた、アリスにより構成されたメッセージの部分も暗号解除し、検証する。ボブの信用証明書Ｂ_ｃｒｅｄが、ボブの番号Ｎ_Ｂおよびアリスにより提供されたボブの識別子Ｂ_ｉｄに合致し、かつアリスの信用証明書Ａ_ｃｒｅｄが、アリスの番号Ｎ_Ａおよびボブにより提供されたアリスの識別子Ａ_ｉｄに合致した場合、トレントは、要求の正当性を認める。要求の正当性を認めた後、トレントは、アリス宛てのメッセージおよびボブのメッセージを生成する。アリス宛てのメッセージは、新しい番号Ｎ_Ａ’と、新しい秘密鍵Ｋ_Ａ’と、アリスの信用証明書Ａ_ｃｒｅｄと、セッション鍵Ｋ_ＡＢとを含む。トレントは、アリス宛てのメッセージをアリスの現在の秘密鍵Ｋ_Ａを用いて暗号化する。ボブ宛てのメッセージは、新しい番号Ｎ_Ｂ’と、新しい秘密鍵Ｋ_Ｂ’と、ボブの信用証明書Ｂ_ｃｒｅｄと、セッション鍵Ｋ_ＡＢとを含む。トレントは、ボブ宛てのメッセージをボブの現在の秘密鍵Ｋ_Ｂを用いて暗号化する。トレントは、アリスおよびボブにメッセージを送る。

Ｔ→Ａ：Ｅ（Ｋ_Ａ，Ｎ_Ａ’Ｋ_Ａ’Ａ_ｃｒｅｄＫ_ＡＢ）

Ｔ→Ｂ：Ｅ（Ｋ_Ｂ，Ｎ_Ｂ’Ｋ_Ｂ’Ｂ_ｃｒｅｄＫ_ＡＢ）

上記のプロトコルは、より多くのエンティティを含むように拡張されることができる。例えば、アリスが、ボブおよびキャロルに関連するセッション鍵を欲しい場合、アリスは、ボブの識別子Ｂ_ｉｄおよびキャロルの識別子（例えば、Ｃ_ｉｄ）などのようなボブおよびキャロルの既知の識別子を、アリスのメッセージ中に列挙することができる。同様に、ボブは、アリスおよびキャロルの識別子を列挙することができ、キャロルは、アリスおよびボブの識別子を列挙することができる。各エンティティはまた、各自の信用証明書を各自のメッセージ中に含めることができる。上で示されたように、各エンティティは、要求されたセッション鍵に関連する別のエンティティに、各自のメッセージを送ることができ、各エンティティは、受け取ったメッセージに、各自のメッセージを追加することができる。すべての意図されたエンティティが、各自のメッセージを要求に追加すると、最後のエンティティは、その要求をトレントへ送る。トレントは、各エンティティの信用証明書が、各エンティティに割り当てられた変化ＩＤ（例えば、変化ＩＤ内の番号）と合致すること、および各エンティティにより指定された識別子のリストが、提供された信用証明書と合致することを検証する。要求の正当性を認めた後、トレントは、新しい変化ＩＤ（例えば、新しい番号および新しい秘密鍵）と、列挙されたエンティティに関連するセッション鍵を、各エンティティに送る。

コンテンツ使用ライセンス
変化ＩＤはまた、エンティティがコンテンツを取得し、復号するために使用し得る、ライセンスを提供するためにも使用することができる。例えば、アリスは、ボブに安全に送りたいコンテンツまたはメッセージＰを有していると仮定する。アリスおよびボブは、トレントを信用していること、トレントは、番号Ｎ_Ａと何らかの対称暗号用の秘密鍵Ｋ_Ａとを含む変化ＩＤをアリスに割り当て、また番号Ｎ_Ｂと何らかの対称暗号用の秘密鍵Ｋ_Ｂとを含む変化ＩＤをボブに割り当てることを仮定する。また、アリスおよびボブは各々、トレントおよび信用証明書の保有者だけが知っている信用証明書（例えば、それぞれＡ_ｃｒｅｄおよびＢ_ｃｒｅｄ）を有することを仮定する。

メッセージＰのためのライセンスを取得するため、アリスは、メッセージＰのハッシュ（例えば、Ｈ（Ｐ））を生成し、そのメッセージのハッシュＨ（Ｐ）をアリスの信用証明書Ａ_ｃｒｅｄと連結し、その結果としてできたものをアリスの秘密鍵Ｋ_Ａを用いて暗号化する。アリスはまた、アリスの番号Ｎ_Ａを暗号化結果に追加する。アリスは、結果としてできたライセンス要求をトレントに送る。

Ａ→Ｔ：Ｎ_ＡＥ（Ｋ_Ａ，Ａ_ｃｒｅｄＨ（Ｐ））

トレントは、アリスからのライセンス要求を暗号解除し、アリスへの応答を生成する。アリスへの応答は、アリス用の新しい番号Ｎ_Ａ’および新しい秘密鍵Ｋ_Ａ’を含む新しい変化ＩＤと、ライセンス番号（例えば、Ｎ_Ｈ（Ｐ））およびライセンス秘密鍵（例えば、Ｋ_Ｈ（Ｐ））を含む、メッセージＰのためのライセンスに関連する変化ＩＤと、メッセージＰのための暗号化鍵（例えば、Ｋ_Ｐ）とを含む。幾つかの実施形態では、トレントはまた、メッセージが改ざん（例えば、詐称者により提供）されていないことをアリスが保証できるように、アリスへの応答にメッセージ・ハッシュＨ（Ｐ）も含める。トレントは、応答をアリスの現在の秘密鍵Ｋ_Ａを用いて暗号化し、暗号化された応答をアリスに送る。

Ｔ→Ａ：Ｅ（Ｋ_Ａ，Ｎ_Ａ’Ｋ_Ａ’Ｎ_Ｈ（Ｐ）Ｋ_Ｈ（Ｐ）Ｋ_ＰＨ（Ｐ））

アリスは、トレントから応答を取得すると、その応答を暗号解除し、鍵Ｋ_Ｐと、メッセージＰのためのライセンスに関連する変化ＩＤとを取得する。アリスは、Ｋ_Ｐを用いてメッセージＰを暗号化し、暗号化メッセージＰのためのライセンスを生成する。暗号化メッセージＰのためのライセンスは、アリスの信用証明書Ａ_ｃｒｅｄと、メッセージ・ハッシュＨ（Ｐ）とを含む。幾つかの実施形態では、ライセンスはまた、ライセンスの受取手の識別子も含む。例えば、アリスがライセンスをボブへ送ろうとする場合、ライセンスは、ボブの識別子（例えば、Ｂ_ｉｄ）を含むことができる。幾つかの実施形態では、受取手の識別子は、プロトコルの複雑さを低減するために、ライセンスから除外される。例えば、デジタル媒体製作会社は、コンテンツの潜在的な受取手を事前に知り得ず、または追跡し得ないであろう。

アリスは、ライセンス秘密鍵Ｋ_Ｈ（Ｐ）を用いてライセンスを暗号化し、その暗号化結果に、関連するライセンス番号Ｎ_Ｈ（Ｐ）を追加する。アリスは、暗号化メッセージＰと、関連するライセンスとをボブに送る。

Ａ→Ｂ：Ｅ（Ｋ_Ｐ，Ｐ）

Ａ→Ｂ：Ｎ_Ｈ（Ｐ）Ｅ（Ｋ_Ｈ（Ｐ），Ａ_ｃｒｅｄＨ（Ｐ）Ｂ_ｉｄ）

暗号化メッセージＰおよび関連ライセンスを受け取った後の何れかの時点で、ボブは、暗号化メッセージＰのための暗号解除鍵を要求する。暗号解除鍵の要求を生成するため、ボブは、ボブの信用証明書Ｂ_ｃｒｅｄをアリスが提供したライセンスに連結し、その結果としてできたものをボブの秘密鍵Ｋ_Ｂを用いて暗号化する。ボブはまた、ボブの番号Ｎ_Ｂを暗号化連結に追加し、結果としてできた要求をトレントへ送る。

Ｂ→Ｔ：Ｎ_ＢＥ（Ｋ_Ｂ，Ｂ_ｃｒｅｄＮ_Ｈ（Ｐ）Ｅ（Ｋ_Ｈ（Ｐ），Ａ_ｃｒｅｄＨ（Ｐ）Ｂ_ｉｄ））

トレントは暗号を開き、ボブの識別子がライセンスに含まれている場合、トレントは、要求内において提供された信用証明書Ｂ_ｃｒｅｄおよび番号Ｎ_Ｂが、アリスが生成したライセンス内の識別子と合致することを検証する。トレントはまた、要求に含まれるメッセージのハッシュＨ（Ｐ）が、ライセンス番号Ｎ_Ｈ（Ｐ）およびライセンス秘密鍵Ｋ_Ｈ（Ｐ）と合致することを検証する。ボブからのメッセージの正当性を認めた後、トレントは、暗号化メッセージＰを暗号解除するために使用され得る暗号解除鍵（例えば、Ｋ_Ｐ）と、ボブ用の新しい番号Ｎ_Ｂ’および新しい秘密鍵Ｋ_Ｂ’を含む変化ＩＤと、ボブの信用証明書Ｂ_ｃｒｅｄを、すべてボブの現在の秘密鍵Ｋ_Ｂを用いて暗号化して、ボブに送る。

Ｔ→Ｂ：Ｅ（Ｋ_Ｂ，Ｎ_Ｂ’Ｋ_Ｂ’Ｋ_ＰＢ_ｃｒｅｄ）

オプションとして、トレントはまた、ボブが暗号解除鍵を要求したことをアリスに通知することができる。

Ｔ→Ａ：Ｅ（Ｋ_Ａ’，“ボブが、識別子Ｈ（Ｐ）に関連する鍵を要求”）

暗号解除鍵をボブに提供した後、メッセージＰのためのライセンスに関連する１回限り使用可の変化ＩＤに関連するライセンス秘密鍵Ｋ_Ｈ（Ｐ）およびライセンス番号Ｎ_Ｈ（Ｐ）をトレントはすでに見ているので、アリスがボブに提供したライセンスはもはや有効ではない。

先の例でのように、このプロトコルは、各エンティティに各自の信用証明書をライセンスに追加させ、その結果を各自に割り当てられた変化ＩＤを用いて暗号化させ、その変更したライセンスを次のエンティティに転送させることにより、複数のエンティティを含むように拡張されることができる。例えば、アリスがライセンスを生成し、それをキャロルに送り、キャロルがそのライセンスをデイビッドに送り、次にデイビッドがそのライセンスをボブに送った場合、トレントにより受け取られる結果的なライセンスは以下のようになる。

Ｔ→Ａ：Ｎ_ＢＥ（Ｋ_Ｂ，Ｂ_ｃｒｅｄＮ_ＤＥ（Ｋ_Ｄ，Ｄ_ｃｒｅｄＮ_ＣＥ（Ｋ_Ｃ，Ｃ_ｃｒｅｄＮ_Ｈ（Ｐ）Ｅ（Ｋ_Ｈ（Ｐ），Ａ_ｃｒｅｄＨ（Ｐ）Ｂ_ｉｄ））））

デジタル署名
ここまで、セキュア通信用のセッション鍵を確立するため、ならびに暗号化データおよび対応ライセンスを送り届けるための、変化ＩＤの使用について説明してきた。別の実施形態では、変化ＩＤは、デジタル署名として使用される。アリスおよびボブが各々、アリスとボブの間の合意を必要とする情報Ｐを含む文書Ｓのコピーを有すると仮定する。例えば、文書Ｓは、売買証書を含むことができ、アリスとボブの間の合意を必要とする情報Ｐは、その売買証書に関する最終価格を含むことができる。また、キャロルは、情報Ｐについて知る必要があるかもしれないが、文書Ｓについては必ずしも知る必要のない、合意の仲裁者（例えば、クレジット・カード会社または銀行）である。アリス、ボブ、およびキャロルは各々、トレントを信用していること、トレントは、番号Ｎ_Ａと何らかの対称暗号用の秘密鍵Ｋ_Ａとを含む変化ＩＤをアリスに割り当て、番号Ｎ_Ｂと何らかの対称暗号用の秘密鍵Ｋ_Ｂとを含む変化ＩＤをボブに割り当て、また番号Ｎ_Ｃと何らかの対称暗号用の秘密鍵Ｋ_Ｃとを含む変化ＩＤをキャロルに割り当てることを仮定する。また、アリス、ボブ、およびキャロルは各々、トレントおよび信用証明書の保有者だけが知っている信用証明書（例えば、それぞれＡ_ｃｒｅｄ、Ｂ_ｃｒｅｄ、およびＣ_ｃｒｅｄ）を有することを仮定する。

文書Ｓの署名を開始するため、アリスは、文書Ｓまたは文書Ｓのハッシュ（例えば、Ｈ（Ｓ））と、アリスの信用証明書（例えば、Ａ_ｃｒｅｄ）とを含む、メッセージを生成する。幾つかの実施形態では、アリスは、メッセージを仮装（ｄｉｓｇｕｉｓｅ）させたり、符号化する。例えば、アリスは、文書のハッシュＨ（Ｓ）と信用証明書のハッシュＨ（Ａ_ｃｒｅｄ）のＸＯＲを生成することができる。メッセージはまた、情報Ｐを含むこともできる。アリスは、アリスの秘密鍵Ｋ_Ａを用いてメッセージを暗号化し、その結果としてできたものにアリスの番号Ｎ_Ａを追加し、その結果的なメッセージをボブへ送る。

Ａ→Ｂ：Ｎ_ＡＥ（Ｋ_Ａ，ＸＯＲ（Ｈ（Ｓ），Ｈ（Ａ_ｃｒｅｄ））Ｐ）

ボブは、文書のハッシュＨ（Ｓ）とボブの信用証明書のハッシュ（例えば、Ｈ（Ｂ_ｃｒｅｄ））のＸＯＲを含む、同様のメッセージを生成する。幾つかの実施形態では、ボブはまた、情報Ｐをメッセージに追加する。ボブは、ボブのメッセージをアリスから受け取ったメッセージに追加し、その結果をボブの秘密鍵Ｋ_Ｂを用いて暗号化する。ボブは、その結果的なメッセージにボブの番号Ｎ_Ｂを追加し、その結果としてできたものをトレントに送る。

Ｂ→Ｔ：Ｎ_ＢＥ（Ｋ_Ｂ，ＸＯＲ（Ｈ（Ｓ），Ｈ（Ｂ_ｃｒｅｄ））ＰＮ_ＡＥ（Ｋ_Ａ，ＸＯＲ（Ｈ（Ｓ），Ｈ（Ａ_ｃｒｅｄ））Ｐ））

トレントは、ボブからのメッセージを暗号解除し、アリスおよびボブにより生成された文書のハッシュＨ（Ｓ）が等しいことを検証する。アリスおよびボブが、各自のメッセージに情報Ｐを含めている場合、トレントはまた、アリスおよびボブから提供された情報Ｐが等しいことを検証する。メッセージの正当性が認められた後、トレントは、アリスおよびボブのための受領証（ｒｅｃｅｉｐｔ）を生成する。アリスの受領証は、ボブの識別子（例えば、Ｂ_ｉｄ）と、文書のハッシュＨ（Ｓ）と、オプションとして情報Ｐとを含む。トレントは、アリスおよびボブのための受領証に関連する変化ＩＤの一部であるが、トレントだけが知っている受領証秘密鍵Ｋ_{ｒｅｃｅｉｐｔ}を用いて、アリスの受領証を暗号化する。トレントはまた、アリスおよびボブのための受領証に関連する変化ＩＤに含まれる関連受領証番号Ｎ_{ｒｅｃｅｉｐｔ}を、アリスの受領証に追加する。トレントは、その後、アリスの受領証と、新しい番号Ｎ_Ａ’および新しい秘密鍵Ｋ_Ａ’を含むアリスの新しい変化ＩＤと、アリスの信用証明書Ａ_ｃｒｅｄとを、アリスの現在の秘密鍵Ｋ_Ａを用いて暗号化し、その結果としてできたものをアリスに送る。

Ｔ→Ａ：Ｅ（Ｋ_Ａ，Ｎ_Ａ’Ｋ_Ａ’Ａ_ｃｒｅｄＮ_{ｒｅｃｅｉｐｔ}Ｅ（Ｋ_{ｒｅｃｅｉｐｔ}，Ｂ_ｉｄＨ（Ｓ）Ｐ））

トレントは、アリスの識別子（例えば、Ａ_ｉｄ）と、文書のハッシュＨ（Ｓ）と、オプションとして情報Ｐとを含む、ボブのための同様の受領証を生成する。トレントは、アリスの受領証を暗号化したのと同じ受領証鍵Ｋ_{ｒｅｃｅｉｐｔ}を用いて、ボブの受領証を暗号化し、アリスの受領証に追加したのと同じ受領証番号Ｎ_{ｒｅｃｅｉｐｔ}を追加する。トレントは、ボブの受領証と、新しい番号Ｎ_Ｂ’および新しい秘密鍵Ｋ_Ｂ’を含むボブの新しい変化ＩＤと、ボブの信用証明書Ｂ_ｃｒｅｄとを、ボブの現在の秘密鍵Ｋ_Ｂを用いて暗号化し、その結果としてできたものをボブへ送る。

Ｔ→Ｂ：Ｅ（Ｋ_Ｂ，Ｎ_Ｂ’Ｋ_Ｂ’Ｂ_ｃｒｅｄＮ_{ｒｅｃｅｉｐｔ}Ｅ（Ｋ_{ｒｅｃｅｉｐｔ}，Ａ_ｉｄＨ（Ｓ）Ｐ））

アリスおよびボブのための受領証をトレントだけが知っている鍵を用いて暗号化することにより、アリスおよびボブは、受領証を改ざんすることができない。仲裁者により正当性を認められた各自の受領証を取得すると、アリスおよびボブは、各自の受領証をキャロルに提示し、キャロルは、その受領証の一方または両方を検証のためにトレントに送る。例えば、アリスがキャロルにアリスの受領証を提供すると仮定する。キャロルは、アリスの受領証にキャロルの信用証明書を追加し、その結果としてできたものをキャロルの秘密鍵Ｋ_Ｃを用いて暗号化する。キャロルは、その結果としてできたものにキャロルの番号Ｎ_Ｃを追加し、そのメッセージをトレントに送る。

Ｃ→Ｔ：Ｎ_ＣＥ（Ｋ_Ｃ，Ｃ_ｃｒｅｄＮ_{ｒｅｃｅｉｐｔ}Ｅ（Ｋ_{ｒｅｃｅｉｐｔ}，Ｂ_ｉｄＨ（Ｓ）Ｐ））

トレントは、キャロルからのメッセージを暗号解除し、そして、受領証を暗号解除して（即ち、トレントだけがＫ_{ｒｅｃｅｉｐｔ}知っているので）、キャロルに受領証の詳細を提供することにより、アリスの受領証を検証する。例えば、トレントは、新しい番号Ｎ_Ｃ’および新しい秘密鍵Ｋ_Ｃ’を含むキャロルの新しい変化ＩＤと、キャロルの信用証明書Ｃ_ｃｒｅｄと、アリスの識別子Ａ_ｉｄと、ボブの識別子Ｂ_ｉｄと、文書のハッシュＨ（Ｓ）と、オプションとして情報Ｐとを含む、キャロル宛てのメッセージを生成することができる。トレントは、そのメッセージをキャロルの現在の秘密鍵Ｋ_Ｃを用いて暗号化し、その結果としてできたものをキャロルへ送る。

Ｔ→Ｃ：Ｅ（Ｋ_Ｃ，Ｎ_Ｃ’Ｋ_Ｃ’Ｃ_ｃｒｅｄＡ_ｉｄＢ_ｉｄＨ（Ｓ）Ｐ）

キャロルは、アリスとボブの間の合意を裁定するために、トレントからの情報を使用する。例えば、キャロルは、アリスとボブが文書Ｓに含まれる情報Ｐについて合意したことを検証するために、トレントからの情報を使用することができる。

上記のプロトコルは、他の数のエンティティを含むように拡張され得ることを理解されたい。

ブラック・プロトコル（ｂｌａｃｋ ｐｒｏｔｏｃｏｌ）
変化ＩＤの秘密鍵（例えば、Ｋ_Ａ、Ｋ_Ｂ、およびＫ_Ｃ）は、秘密鍵を用いて暗号化された送信データのセキュリティを保護するために、秘密であり続けなければならない。例えば、トレントが、アリスの現在の秘密鍵（例えば、Ｋ_Ａ）を用いて暗号化された新しい変化ＩＤをアリスに提供する場合、アリスの現在の秘密鍵を特定することができた盗聴者は、アリスの新しい変化ＩＤを取得することができる。盗聴者は、その後、偽データを送るため、および／またはアリスとトレントの間で交換される将来のデータの平文を取得するために、新しい変化ＩＤを使用することができる。

盗聴者は、攻撃を実行することにより、特定のデータを暗号化するために使用された鍵を特定する（または特定しようと試みる）ことができる。例えば、盗聴者は、力づく攻撃（ｂｒｕｔｅ ｆｏｒｃｅ ａｔｔａｃｋ、ブルート・フォース・アタック）を実行することができる。力づく攻撃では、筋の通った又は認識可能なデータ（例えば、人が読めるデータ）を生成する鍵が見つかるまで、あらゆる可能な鍵を用いて暗号文の暗号解除を行う。盗聴者が、取得した暗号文に対応する平文（またはその部分もしくはパターン）を取得した場合、あるいは知っている場合、盗聴者は、正しい候補鍵が見つかったかどうかをより容易に決定することができる。例えば、盗聴者が、暗号文を取得し、暗号文が個人名とそれに続く数字４桁の個人識別情報（ＰＩＮ：ｐｅｒｓｏｎａｌ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ）とを含むことを知っている場合、盗聴者は、候補鍵により個人名を含む平文が生成されるまで、候補鍵を適用する。盗聴者は、その後、ある程度の確実性をもって、生成された平文に含まれる残りの情報がＰＩＮに対応すると推定することができる。

しかし、盗聴者が、平文または平文のパターンについての知識を有さない（即ち、コンテンツのヒントを有さない）場合、正しい候補鍵が見つかったかどうかを決定する盗聴者の能力は、大きく損なわれるか、おそらくは失われる。例えば、平文が特定の鍵を用いて暗号化された乱数を含む場合、盗聴者が力づく攻撃で多くの鍵を試してみても、盗聴者は、候補平文が暗号文に対応する真の平文であるかどうかを決定する方法をもたない。暗号化された乱数の暗号解除は、どの候補鍵を用いても、他のすべての候補鍵により生成された他のすべての乱数と同様に、元の乱数と同様な乱数を生成する。

アリス、ボブ、およびトレントを含む上述のセッション鍵の例を参照すると、暗号化メッセージの何らかの部分が、認識可能である、既知である、既知になる、または何らかのコンテンツのヒントを含む場合、盗聴者はおそらく、暗号化メッセージに対して平文攻撃または部分平文攻撃を実行し、メッセージを暗号化するために使用されたアリスまたはボブの秘密鍵を暴くことができる。例えば、アリスが以下のメッセージをボブに送り、それが盗聴者により傍受されると仮定する。

Ａ→Ｂ：Ｎ_ＡＥ（Ｋ_Ａ，Ａ_ｃｒｅｄＢ_ｉｄ）

ボブの識別子Ｂ_ｉｄおよび上記のメッセージのフォーマットは既知であるか、または公開されているので、盗聴者は、傍受したメッセージに対して力づく攻撃を実行することができる。従って、盗聴者は、アリスの秘密鍵Ｋ_Ａおよび信用証明書Ａ_ｃｒｅｄを取得することができる。更に、盗聴者は、アリスの現在の秘密鍵Ｋ_Ａを取得すると、アリスの現在の秘密鍵Ｋ_Ａを使用して、アリスの次の変化ＩＤ（例えば、Ｎ_Ａ’およびＫ_Ａ’）などのような、アリスの現在の秘密鍵Ｋ_Ａを用いて暗号化されるすべてのデータを取得することができる。

盗聴者は、暗号化メッセージについての、または暗号化メッセージを生成するために使用される通信プロトコルについての他の知識を使用して、力づく攻撃を実行することができる。例えば、盗聴者は、平文で渡される変化ＩＤ内の番号（例えば、Ｎ_Ａ）を使用して、力づく攻撃を実行することができる。盗聴者はまた、変化ＩＤ内の番号を生成するために使用されるアルゴリズムについての知識を使用して、力づく攻撃を実行することができる。

上記で指摘されたように、発見不可能データ（即ち、ランダムである、またはコンテンツのヒントをもたないデータ）を暗号化するために使用される鍵については、盗聴者は正しい候補鍵が見つかったということを決定することができないので、力づく攻撃を使用して容易に特定または発見することができない。しかし、発見可能データ（即ち、既知である、後で開示されるかもしれない、認識可能である、または既知もしくは容易に推測できるフォーマットを有するデータ）を暗号化するために使用される鍵については、力づく攻撃を使用して特定されることができる（理論的には）。発見可能データと発見不可能データが、一緒に、または同じ暗号化鍵を用いて暗号化される場合（例えば、認識可能な名前と、対応するおそらくはランダムなＰＩＮとが同じ鍵を用いて暗号化される場合）、発見可能データを使用しての力づく攻撃により特定される鍵は、発見不可能データを暗号化するために使用される鍵でもあるので、従って、発見不可能データは発見され得る。

発見不可能または秘密のデータのセキュリティを高めるため、異なるタイプのデータを暗号化するために、別個の鍵を使用することができる（これ以降、「個別暗号化プロトコル（ｓｅｐａｒａｔｅ ｅｎｃｒｙｐｔｉｏｎ ｐｒｏｔｏｃｏｌ）」と呼ばれる）。例えば、１または複数の鍵（例えば、１または複数の変化ＩＤ）を、発見不可能データ（例えば、秘密鍵Ｋ_Ａ、Ｋ_Ｂ、およびＫ_Ｃ）を暗号化するために使用することができ、また１または複数の鍵（例えば、１または複数の変化ＩＤ）を、発見可能データ（例えば、Ｂ_ｉｄ）を暗号化するために使用することができる。発見不可能データおよび発見可能データを暗号化するために同じ鍵は決して使用されないので、盗聴者が発見不可能データを特定する可能性は低下する。

電子商取引
変化ＩＤはまた、電子商取引プロトコルにおいても使用することができる。図４は、電子商取引を実行するように構成された例示的なシステム２００を示している。図４に示される実施形態では、システム２００は、４つの参加者、即ち、売主（ベンダ）２２０と、支払い認証デバイスまたはクレジット・カード会社もしくは金融機関などの支払い認証手段（支払い認証者）２４０と、買手（購買者）２６０と、認証手段（認証者）２８０とを含む。１つのみの売主２２０、支払い認証手段２４０、および買手２６０が示されている、他の実施においては、多数の売主、支払い認証手段、および買手が含まれる。更に、１つのみを必要とするが、複数の認証手段２８０が存在することもできる。現実には、［認証手段の数］＜［支払い認証手段の数］＜［売主の数］＜［買手の数］という関係が存在する可能性が高いが、参加者の数や、様々なタイプの参加者の数の間の特定の関係についての要件に対する制約はない。

幾つかの実施形態では、売主２２０、支払い認証手段２４０、および買手２６０は、２方向リンク３００、３２０、３４０を介して、認証手段２８０に接続される。売主２２０と買手２６０もまた、２方向リンク３６０を介して接続される。これらのリンクは、上述のネットワークの全部または一部から構成されてよい。幾つかの実施形態では、リンク３６０は、セキュアではないハイパーテキスト転送プロトコル（ＨＴＴＰ）リンクを含む。システム２０に関して上述したように、システム２００は、ラインダール・アルゴリズムなどの鍵ベースの暗号化アルゴリズムを使用することができる。

売主２２０は、商品および／またはサービスを電子的に販売することを望む小売会社などのエンティティである。売主２２０は、システム２０を使用して交換される、これ以降共に商品と呼ばれる商品および／またはサービスに対して、公正に返済を受けることを望んでいると仮定する。従って、本発明の一実施形態では、システム２００は、売主２２０が、買手に販売した商品および／またはサービスに対する売買証書を生成できるように構成される。売買証書は、取引識別子を含むことができる。幾つかの実施形態では、取引識別子は、売主識別子を含む。

買手２６０と売主２２０は、売買証書および関連する価格に合意する。買手２６０は、支払い認証手段２４０により管理される口座から、合意価格で売買証書に列挙された品目を取引するための資金を調達することを認可することができる。取引が完了した後、買手２６０、売主２２０、および支払い認証手段２４０は、デジタル署名の例に関して上述したように、偽造されていない取引の受領証を認証手段２８０から受け取ることができる。

少なくとも幾つかの買手２６０は、支払いを行うことなく、または買手２６０が管理する権限を与えられていない口座からの資金を用いて、電子的に商品を購入することを望む又は試みることができると仮定する。また、買手２６０は、支払い情報（例えば、口座番号）が危険にさらされることのない安全な取引を要求すると仮定する。従って、本発明の実施形態は、変化ＩＤの使用を通して、未認可の商品購入を防止し、安全な取引を提供するための方策を提供する。

支払い認証手段２４０は、取引に資金供給する（金または他の支払い形式もしくは機構の形で）ために使用することができる口座を管理するクレジット・カード会社や金融機関などのエンティティである。支払い認証手段２４０は、口座識別子を含む有効な要求を受け取ったときに、特定の口座から電子取引に資金供給することを同意し、従って、口座識別子は、要求が口座保有者によってのみ生成され得ることを保証するために、支払い認証手段と口座保有者の間で秘密に保たれる。従って、本発明の幾つかの実施形態では、買手２６０と支払い認証手段２４０が、支払い認証手段２４０により管理される買手２６０の口座に関する秘密の口座識別子に合意するように、システム２００が構成される。更に、口座からの取引の支払いに対する許可は、支払い要求の改ざんや再使用などを防止するために、変化ＩＤを用いて暗号化される。

認証手段２８０は、安全な電子取引を実行するのに必要なデータを保有する。幾つかの実施形態では、認証手段２８０は、電子商取引を行うことを許可する前に、売主２２０、支払い認証手段２４０、および買手２６０を、それぞれの変化ＩＤに基づいて検証する。認証手段２８０はまた、買手、売主、および支払い認証手段の受領証を検証することができる。加えて、認証手段２８０は、買手の口座情報や取引の詳細を知ることなく、上記のアクションを実行することができる。認証手段２８０はまた、変化ＩＤの発行元でもあり、そのようなＩＤをデータベースまたは類似の機構を使用して追跡する。幾つかの実施形態では、認証手段２８０および支払い認証手段２４０の機能は、組み合わされ、単一のエンティティとして提供されることができる。

本発明の例示的な実施形態が、幾つかの例を使用して今から説明される。プロトコルの一実施形態は、４つの参加者を含む。エンティティ・ボブ（例えば、Ｂ）は、買手２６０の役割を実行し、エンティティ・ヴェラ（例えば、Ｖ）は、売主２２０の役割を実行し、エンティティ・キャロル（例えば、Ｃ）は、支払い認証手段２４０の役割を実行し、エンティティ・トレント（例えば、Ｔ）は、認証手段２８０の役割を実行する。プロトコルは、ボブがヴェラから商品を購入することに関する。ボブは、キャロルにより管理される口座を使用して、商品を購入し、または商品の代金を支払う。トレントは、ボブ、ヴェラ、およびキャロルの間の通信を仲裁する。提案されるプロトコルは信用できる権威者に依存するので、ボブ、ヴェラ、およびキャロルは各々、トレントを信用する。更に、プロトコルにおいて使用されるすべての変化ＩＤは、トレントにより割り当てられ、トレントに知られている。各変化ＩＤは、トレントおよび変化ＩＤの保有者だけに知られている。ボブ、ヴェラ、およびキャロルは各々、トレントにより発行された変化ＩＤ、即ち、番号／鍵ペア（例えば、それぞれ（Ｎ_Ｂ，Ｋ_Ｂ）、（Ｎ_Ｖ，Ｋ_Ｖ）、および（Ｎ_Ｃ，Ｋ_Ｃ））を保有する。

この例のためのみであるが、ボブはヴェラから商品を購入したいと仮定する。ボブとヴェラは、売買証書（例えば、Ｓ）および関連価格（例えば、Ｐ）に合意する。ボブは、キャロルがボブのために管理する口座から資金を引き落として、取引の価格Ｐをヴェラに支払うことを望む。口座は、信用証明書（例えば、Ｂ_ｃｒｅｄ）により識別される。信用証明書Ｂ_ｃｒｅｄは、ボブ、キャロル、およびトレントにだけ知られた又は認識可能な、秘密である。幾つかの実施形態では、以下で説明されるように、信用証明書Ｂ_ｃｒｅｄは、ボブの口座用にキャロルにより割り当てられた口座番号を表す。他の実施形態では、信用証明書Ｂ_ｃｒｅｄは、トレントにより割り当てられる。信用証明書Ｂ_ｃｒｅｄがトレントおよびキャロルに知られている場合、トレントおよびキャロルは共に、ボブがある特定のメッセージを生成したことを検証するために、信用証明書Ｂ_ｃｒｅｄを使用することができる。キャロルはまた、ボブの口座番号を検証するために、ボブの信用証明書Ｂ_ｃｒｅｄを使用することができる。

トレントは、プロトコルが機能するために、買手の信用証明書を、アプリオリ（ａ ｐｒｉｏｒｉ）に又は前もって「知る」必要がないことに留意されたい。幾つかの実施形態では、トレントは、検証および使用のために、信用証明書をキャロルに送るだけである。更に、幾つかの実施形態では、トレントは、ある特定の買手から受け取った信用証明書に含まれるまたは信用証明書で表される、口座番号などのデータを取得することができない。例えば、キャロルが、ボブおよびキャロルにだけ知られている秘密データ（例えば、ボブの口座番号、有効期限、社会保障番号など）に基づいた信用証明書Ｂ_ｃｒｅｄをボブに提供する場合、トレントは、ボブから信用証明書Ｂ_ｃｒｅｄを受け取っても、ボブの秘密データを割り出すことができない。このことは、プロトコルのセキュリティを高めるのに役立つことができる。

例えば、信用証明書Ｂ_ｃｒｅｄは、ボブおよびキャロルにだけ知られている秘密（例えば、ボブの口座番号）から構成される。信用証明書Ｂ_ｃｒｅｄはまた、現在の取引に関する詳細から構成されることもできる。幾つかの実施形態では、信用証明書Ｂ_ｃｒｅｄは、以下のように決定される。

Ｂ_ｃｒｅｄ＝Ｅ（Ｈ（ｘ），Ｈ（Ｓ）Ｐ）

上記の式において、ｘは、ボブおよびキャロルにだけ知られている秘密（ボブの口座番号など）であり、Ｓは、売買証書であり、Ｐは、売買証書Ｓに関連する合意価格Ｐである。幾つかの実施形態では、ボブは、ハッシュからではなく、売買証書Ｓの平文バージョンおよび／または関連価格Ｐから、ボブの信用証明書Ｂ_ｃｒｅｄを構成する。しかし、ハッシュを使用すると、取引の詳細を抽象化できる。追加の式または機構を、信用証明書を決定するために使用できることを理解されたい。

ボブおよびキャロルは、ｘ（および妥当な場合はハッシュ関数）を知っているので、信用証明書Ｂ_ｃｒｅｄを暗号解除することができ、ボブの口座に関するセキュア（安全）な情報を取得することができる。しかし、トレントは、ボブの口座に関する安全な情報を取得することができず、また、幾つかの実施形態では、価格などの取引の詳細を取得することができない。

ボブは、それぞれの取引のために信用証明書Ｂ_ｃｒｅｄを生成することができ、キャロル（ボブの口座番号を知っており、Ｈ（ｘ）を生成することができる）は、売買証書Ｓおよび対応する価格Ｐを取得するために、信用証明書Ｂ_ｃｒｅｄを暗号解除する。幾つかの実施形態では、キャロルが、各々が口座番号ｘ_１、ｘ_２、．．．、ｘ_ｎを有するボブ用の複数の口座を管理する場合、キャロルは、各口座番号に対してハッシュを生成する。ハッシュの１つが、ボブにより生成された信用証明書Ｂ_ｃｒｅｄを暗号解除することができた場合、キャロルは、どの口座から資金を引き落とすべきかを知る。ボブはまた、特定の口座を識別するために、信用証明書Ｂ_ｃｒｅｄに口座識別子を追加することもできる。

幾つかの実施形態では、口座のハッシュの生成は、Ｈ（ｘ_ｉ）＝Ｈ（ｘ_ｊ）およびｘ_ｉがｘ_ｊに等しくない、というハッシュ衝突（hash collision）を引き起こし得る。ハッシュ衝突は、口座生成時に検出されることができ、衝突する口座番号は、ハッシュ衝突を防止するために、再生成されることができる。

図５に示されるように、購入プロセスを開始するため、ヴェラは、ボブに売主取引データを送る。幾つかの実施形態では、売主取引データは、売買証書Ｓおよび／または売買証書Ｓに対応する価格Ｐを含む。幾つかの実施形態では、売主取引データは、売買証書Ｓの平文バージョンおよび／または対応するＰを含む。他の実施形態では、売主取引データは、売買証書Ｓのハッシュ（例えば、Ｈ（Ｓ））および／または価格のハッシュ（例えば、Ｈ（Ｐ））を含む。売主取引データはまた、ヴェラの信用証明書（例えば、Ｖ_ｃｒｅｄ）を含むこともできる。ヴェラの信用証明書Ｖ_ｃｒｅｄは、ヴェラ、キャロル、およびトレントにだけ知られた又は認識可能な秘密とすることができる。幾つかの実施形態では、上述のように、ヴェラの信用証明書Ｖ_ｃｒｅｄは、キャロルにより割り当てられた口座番号などのような、ヴェラおよびキャロルにだけ知られた秘密から構成される。他の実施形態では、トレントが、ヴェラに信用証明書Ｖ_ｃｒｅｄを割り当てる。キャロルおよび／またはトレントは、売主取引データがヴェラにより生成されたことを検証するために、ヴェラの信用証明書Ｖ_ｃｒｅｄを使用することができる。売主取引データはまた、取引に関連する買手の識別子（例えば、Ｂ_ｉｄ）および／または支払い認証手段の識別子（例えば、Ｃ_ｉｄ）を含むこともできる。ヴェラは、ヴェラの秘密鍵Ｋ_Ｖを用いて売主取引データを暗号化し、その結果にヴェラの秘密番号Ｎ_Ｖを追加することにより、売主取引データの全部または一部に「署名」する。ヴェラは、署名された売主取引データをボブに送る。

Ｖ→Ｂ：Ｎ_ＶＥ（Ｋ_Ｖ，Ｈ（Ｓ）Ｐ））

一つの変形形態では、以下に示すように、ヴェラはまた、売主取引データの全部または一部を平文でボブに送ることができる。例えば、ヴェラは、売買証書Ｓおよび／または対応する価格Ｐを平文としてボブに送ることができる。ボブは、買手取引データを生成するために、平文の売主取引データを使用することができる。

Ｖ→Ｂ：ＳＮ_ＶＥ（Ｋ_Ｖ，Ｈ（Ｓ）Ｐ）

ヴェラから売主取引データを受け取ると、ボブは、買手取引データを生成する。買手取引データは、ボブが正しくかつ正直に行為する場合、ヴェラにより提供された売買証書Ｓおよび／または価格Ｐと同一または等しい売買証書Ｓおよび／または対応する価格Ｐを含むことができる。幾つかの実施形態では、ボブは、ヴェラにより提供された平文の売買証書および価格から、売買証書Ｓおよび価格Ｐを生成する。ボブは、売買証書Ｓおよび／または価格Ｐを、平文として、またはハッシュ（例えば、Ｈ（Ｓ）および／またはＨ（Ｐ））として、買手取引データに含めることができる。

ボブはまた、ボブの信用証明書Ｂ_ｃｒｅｄを買手取引データに含め、幾つかの実施形態では、自分以外の取引の参加者の識別子（例えば、Ｖ_ｉｄおよびＣ_ｉｄ）も買手取引データに含める。ボブは、ボブの秘密鍵Ｋ_Ｂを用いて買手取引データを暗号化し、その結果としてできたものにボブの秘密番号Ｎ_Ｂを追加することにより、買手取引データの全部または一部に署名する。ボブは、署名された買手取引データをヴェラの署名された売主取引データに連結し、連結されたメッセージをトレントへ送る。

Ｂ→Ｔ：Ｎ_ＢＥ（Ｋ_Ｂ，Ｈ（Ｓ）Ｐ）Ｂ_ｃｒｅｄＶ_ｉｄＣ_ｉｄＮ_ＶＥ（Ｋ_Ｖ，Ｈ（Ｓ）Ｐ）

ボブもまた購入プロセスを開始し得ることを理解されたい。幾つかの実施形態では、ボブは、ヴェラおよびキャロルの識別子含む署名された買手取引データをヴェラへ送る。ヴェラは、ボブから提供された署名された買手取引データに署名された売主取引データを追加し、連結されたメッセージをトレントへ送る。

トレントは、連結されたメッセージを開く（メッセージに含まれるボブおよびヴェラの秘密番号Ｎ_ＢおよびＮ_Ｖによりそれぞれ識別されるボブおよびヴェラの秘密鍵を知っているので）。一つの実施では、トレントは、ボブから送信された買手取引データまたはその一部（例えば、売買証書、価格、ならびに／または売買証書および／もしくは価格のハッシュ）が、ヴェラから送信された売主取引データまたはその一部と合致することを検証する。データが合致しない場合、ヴェラとボブは共通の売買証書および／または関連価格に合意していないことがあり得、トレントは、ボブおよびヴェラに不一致を通知する。トレントはまた、提供された関与者の識別子が一致することを検証することもできる。例えば、トレントは、売主により識別された買手が、買手取引データを提供した買手の識別情報と合致すること、また買手により識別された売主が、売主取引データを提供した売主の識別情報と合致することを検証することができる。

データが合致した場合、トレントは、支払い要求を生成し、ボブとヴェラの間の取引に対する支払いを要求するために、その支払い要求をキャロルに送信する。幾つかの実施形態では、支払い要求は、買手および売主の識別子Ｂ_ｉｄおよびＶ_ｉｄと、買手および売主の信用証明書Ｂ_ｃｒｅｄおよびＶ_ｃｒｅｄと、売買証書Ｓと、対応する価格Ｐとを含む。支払い要求は、取引を検証し、買手から売主への支払いを処理するために、支払い認証手段２４０により必要とされる情報に応じて、付加的な情報またはより少ない情報を含むことができる。例えば、キャロルは、支払い要求を検証および処理するために、売買証書またはヴェラおよび／もしくはボブの識別子を必要としなくてもよい。

幾つかの実施形態では、トレントは、ボブおよびヴェラの信用証明書Ｂ_ｃｒｅｄおよびＶ_ｃｒｅｄを取得するが、その信用証明書を復号することはできず、従って、キャロルにより管理されるボブまたはヴェラの口座に関する秘密情報を取得することはできないことに留意されたい。

トレントは、キャロル以外の誰かが支払い要求に含まれるデータを取得することを防止するために、キャロルの秘密鍵Ｋ_Ｃを用いて支払い要求を暗号化する。幾つかの実施形態では、トレントはまた、キャロルの秘密番号Ｎ_Ｃを暗号化された支払い要求に追加する。トレントは、結果としてできた支払い要求をキャロルに送る。

Ｔ→Ｃ：Ｎ_ＣＥ（Ｋ_Ｃ，Ｂ_ｉｄＶ_ｉｄＢ_ｃｒｅｄＶ_ｃｒｅｄＳＰ）

キャロルは、支払い要求を受け取り、売買証書Ｓに対する支払いを承認するかどうかを決定する。幾つかの実施形態では、キャロルは、ボブの口座（Ｂ_ｃｒｅｄにより識別される）が、売買証書Ｓに関連する価格Ｐをまかなうのに十分な資金を含むかどうかを判定することにより、支払いを承認するかどうかを決定する。キャロルはまた、ヴェラの口座（Ｖ_ｃｒｅｄにより識別される）およびボブの口座（Ｂ_ｃｒｅｄにより識別される）が、有効な口座であることも検証する。ボブの口座が価格Ｐをまかなうのに十分な資金を含み、かつボブおよびヴェラの口座が有効である場合、キャロルは、価格Ｐに基づいて、ボブの口座からヴェラの口座に資金を移転させる。幾つかの実施形態ではでは、キャロルは、第三者預託（ｅｓｃｒｏｗ、エスクロー）としてふるまい、売買証書Ｓに含まれる商品および／またはサービスがボブに出荷または提供されたことをヴェラがキャロルに通知するまで、ボブの口座からの資金を保有する。商品および／またはサービスがボブに提供されると、キャロルは、資金をヴェラの口座に移転させる。

支払いを承認すると、キャロルは、支払い応答をトレントへ送る。支払い応答は、支払い要求に含まれる情報の全部または一部を含むことができる。例えば、支払い応答は、売主および買手の識別子と、売買証書Ｓと、価格Ｐとを含むことができる。幾つかの実施形態では、支払い応答はまた、キャロルにより生成された取引番号または参照番号も含む。取引が承認および処理されたことを示すため、支払い応答はまた、承認のインジケータまたはメッセージを含む。キャロルは、キャロルの秘密鍵Ｋ_Ｃを用いて支払い応答を暗号化し、幾つかの実施形態では、その暗号化した結果としてできたものにキャロルの識別番号Ｎ_Ｃを追加する。キャロルは、支払い応答をトレントへ送る。

Ｃ→Ｔ：Ｎ_ＣＥ（Ｋ_Ｃ，Ｂ_ｉｄＶ_ｉｄＳＰ“承認”）

支払い要求の承認を示す支払い応答をキャロルから受け取った後、トレントは、１または複数の参加者のための取引受領証を生成する。これらの受領証は、取引が承認され、完了されたことの証拠として使用することができる。一つの実施では、各受領証は、３つの参加者のうちの２つについての鍵（例えば、受領証の対象ではない参加者の鍵）と、売買証書と、価格とを含む。各受領証はまた、受領証の受取手および／または他の参加者の信用証明書を含むこともできる。受領証の受取手は、受領証がトレントにより生成されたことを検証するために、信用証明書を使用することができる。取引のセキュリティおよび機密性を更に高めるために、鍵、売買証書Ｓ、価格Ｐ、および／または信用証明書のハッシュが、平文データの代わりに含まれ得ることを理解されたい。ハッシュが提供される場合、トレントは、ハッシュを取得するが、取引の詳細を解読することはできない。ヴェラ、ボブ、およびキャロルの例示的な受領証は、以下の通りである。

Ｔ→Ｖ：Ｅ（Ｋ_Ｖ，Ｈ（Ｋ_ＢＫ_ＣＰ）Ｈ（Ｓ）Ｐ）

Ｔ→Ｂ：Ｅ（Ｋ_Ｂ，Ｈ（Ｋ_ＶＫ_ＣＰ）Ｈ（Ｓ）Ｐ）

Ｔ→Ｃ：Ｅ（Ｋ_Ｃ，Ｈ（Ｋ_ＢＫ_ＶＰ）Ｈ（Ｓ）Ｐ）

ボブ、ヴェラ、および／またはキャロルは、各自がこの取引で使用した番号（例えば、Ｎ_Ｂ、Ｎ_Ｖ、またはＮ_Ｃ）と、価格と、取引検証用の各自の受領証をトレントに提示することができる。例えば、トレントは、受領証が同一であることを検証することができる。

トレントはまた、ヴェラ、ボブ、およびキャロルに新しい変化ＩＤも提供する。トレントは、各関与者用の新しい変化ＩＤをその関与者の現在の秘密鍵を用いて暗号化する。

Ｔ→Ｖ：Ｅ（Ｋ_Ｖ，Ｎ_Ｖ’Ｋ_Ｖ’）

Ｔ→Ｂ：Ｅ（Ｋ_Ｂ，Ｎ_Ｂ’Ｋ_Ｂ’）

Ｔ→Ｃ：Ｅ（Ｋ_Ｃ，Ｎ_Ｃ’Ｋ_Ｃ’）

幾つかの実施形態では、トレントは、新しい変化ＩＤを別に送る代わりに、それらをボブ、キャロル、およびヴェラ用の受領証内に含める。

ボブの口座が価格Ｐをまかなうのに十分な資金を含まない場合、またはボブもしくはヴェラの口座が有効ではない場合、キャロルは、支払い要求を拒絶し、ボブの口座からヴェラの口座に資金を移転させない。支払い要求の拒絶を示すため、キャロルは、支払い応答をトレントへ送る。上述のように、支払い応答は、支払い要求に含まれる情報の全部または一部を含むことができる。例えば、支払い応答は、売主および買手の識別子と、売買証書Ｓと、価格Ｐとを含むことができる。幾つかの実施形態では、支払い応答はまた、キャロルにより生成された取引番号または参照番号を含むこともできる。支払い応答はまた、取引が拒絶または拒否されたかどうかを示す拒否のインジケータまたはメッセージも含む。キャロルは、キャロルの秘密鍵Ｋ_Ｃを用いて支払い応答を暗号化し、幾つかの実施形態では、その暗号化の結果としてできたものにキャロルの識別番号Ｎ_Ｃを追加する。キャロルは、支払い応答をトレントへ送る。

Ｃ→Ｔ：Ｎ_ＣＥ（Ｋ_Ｃ，Ｂ_ｉｄＶ_ｉｄＳＰ“拒否”）

拒否された支払い要求を示す支払い応答をキャロルから受け取った後、トレントは、上述のように、ヴェラ、ボブ、および／またはキャロルのための取引受領証を生成する。受領証は、支払い要求がキャロルにより拒否されたことを示す。代替例として、トレントは、取引が処理されなかったことをヴェラおよびボブに警告する拒絶または拒否のメッセージをヴェラおよびボブに送ることもできる。拒否された支払い要求を示す支払い応答をキャロルから受け取った後、トレントはまた、上述のように、ヴェラ、ボブ、およびキャロルへ新しい変化ＩＤを提供することもできる。

上述された、図５に示される電子商取引プロトコルのステップおよび／または順序は、変更され得ることを理解されたい。例えば、ヴェラおよびボブは、取引を安全に取り決めるために、トレントにセッション鍵を要求し、受け取ることができる。代替または追加の例として、ヴェラおよびキャロル、および／または、ボブおよびキャロルは、ヴェラおよび／またはボブが、信用証明書などの取引情報を、トレントを介して渡すことなく、キャロルへ直接に提供することができるように、トレントにセッション鍵を要求して受け取ることができる。幾つかの実施形態では、トレントはまた、支払い要求の承認または拒絶時にキャロルがヴェラおよび／またはボブへ直接に送ることができる受領証、メッセージ、および／または新しい変化ＩＤを生成し、キャロルへ提供することもできる。キャロルはまた、支払い要求の承認または拒絶の時に、受領証および／またはメッセージ（例えば、平文として）をヴェラおよび／またはボブへ直接に提供することもできる。認証手段および支払い認証手段の役割は、組み合わされることもできる。例えば、それぞれの支払い認証手段は、それ独自の変化ＩＤを各自のクライアント（支払い認証手段が口座を管理する個人）に提供することができる。

加えて、上記の通信および商取引プロトコル（またはその一部）は、組み合わされることができる。例えば、電子商取引は、コンテンツ・プロバイダまたはサービス・プロバイダからのデジタル・コンテンツの購入に含まれることができる。更に、電子商取引は、一意性を保証するために、取引データおよび対応する受領証に透かしを入れることができる。更に、上述された、図５に示される商取引プロトコルは、ヴェラ、ボブ、トレント、およびキャロルの間で渡されるメッセージに対する力づく攻撃の有効性を低下させるために、上述のような個別暗号化プロトコルを使用し、発見可能データおよび発見不可能データを別々の無関係な鍵を用いて暗号化することができる。更なる組み合わせおよび構成も可能である。

ＰＯＳ（ポイント・オブ・セール）取引
電子商取引において変化ＩＤを使用するのに加えて、変化ＩＤはまた、ポイント・オブ・セール（ＰＯＳ）端末においても使用することができ、買手は、売主のＰＯＳ端末の物理的位置において取引を開始する。図６および図７は、売主のＰＯＳ端末において取引を実行するように構成された例示的なシステム４００を示している。

図７に示される実施形態では、システム４００は、４つの参加者またはエンティティ、即ち、売主ＰＯＳ端末４２０と、クレジット・カード会社や金融機関などの支払い認証手段４４０と、口座情報保持体（ＡＩＣ、account information carrier）デバイス４６０と、認証手段４８０とを含む。図６は、磁気およびスマート・カード・リーダ（Ｖｅｒｉｆｏｎｅ，Ｉｎｃ．から入手可能なものなど）の形態を取るＰＯＳ端末と、セルラ電話、スマート・カード、またはクレジット・カードの形態を取るＡＩＣデバイス４６０とを示している。１つのみの売主ＰＯＳ端末４２０、支払い認証手段４４０、ＡＩＣデバイス４６０を示しているが、ほとんどの実施においては、多数の売主ＰＯＳ端末、支払い認証手段、およびＡＩＣデバイスが含まれる。更に、１つのみを必要とするが、複数の認証手段４８０が存在することもできる。現実には、［認証手段の数］＜［支払い認証手段の数］＜［売主ＰＯＳ端末の数］＜［ＡＩＣデバイスの数］という関係が存在する可能性が高いが、参加者の数に対する制約や、様々なタイプの参加者の数の間の特定の関係についての要件に対する制約はない。

幾つかの実施形態では、売主ＰＯＳ端末４２０、支払い認証手段４４０、およびＡＩＣデバイス４６０は、リンク５００、５２０、５４０を介して、認証手段４８０に接続される。リンク５００、５２０、５４０は、２方向リンクとすることができ、上述のネットワークの全部または一部から構成されてよい。図７に示されるように、売主ＰＯＳ端末４２０およびＡＩＣデバイス４６０はまた、リンク５６０を介して接続される。リンク５６０は、無線周波数リンク、赤外線リンク、ワイヤレス・ネットワーク・リンク、ダイレクト・ドック（ｄｉｒｅｃｔ ｄｏｃｋ）もしくは有線リンク、またはセル電話リンクを含むことができる。一実施形態では、セル電話は、スマート・カードで使用されるものと同じ物理コネクタまたはプラグ（おそらくフリップ・アウト拡張（ｆｌｉｐ ｏｕｔ ｅｘｔｅｎｓｉｏｎ）の形態）を有するように構成されることができ、それにより、図６に示されるリーダのような既存のリーダが、セル電話から情報を取得したり、セル電話と通信するために使用され得る。

図８は、本発明の一実施形態によるシステム４００に含まれる、売主ＰＯＳ端末４２０と、ＡＩＣデバイス４６０と、支払い認証手段４４０と、認証手段４８０とを概略的に示している。図８に示されるように、各装置は、プロセッサ６００（例えば、６００ａ、６００ｂ、６００ｃ、６００ｄ）と、メモリ・モジュール６１０（例えば、６１０ａ、６１０ｂ、６１０ｃ、６１０ｄ）と、入力／出力モジュール６２０（例えば、６２０ａ、６２０ｂ、６２０ｃ、６２０ｄ）とを含む。図８に示される構成要素は例示的なものであり、様々な配置および構成で組み合わされ、また分散され得ることを理解されたい。例えば、メモリ・モジュール６１０は、別個の構成要素として含まれる代わりに、または含まれるのに加えて、プロセッサ６００および／または入力／出力モジュール６２０に含まれることができる。入力／出力モジュール６１０はまた、対応するプロセッサ６００を収容する装置の外部のデバイス内に配置されることもできる。

プロセッサ６００は、変化ＩＤを使用して売主ＰＯＳ端末において取引を実行するための１または複数のプロセッサまたは類似の回路を含むことができる。一実施形態では、メモリ・モジュール６１０は、図９に関して以下で説明されるように、変化ＩＤを使用して売主ＰＯＳ端末において取引を実行するために、プロセッサ６００により取り出され、実行される命令およびデータを記憶する。メモリ・モジュール６１０はまた、取引を実行するために使用される変化ＩＤも記憶することができる。具体的には、売主ＰＯＳ端末４２０、支払い認証手段４４０、およびＡＩＣデバイス４６０にそれぞれ含まれるメモリ・モジュール６１０ａ、６１０ｂ、６１０ｃは、認証手段４８０により各装置に割り当てられた１または複数の変化ＩＤを記憶するように構成されることができる。同様に、認証手段４８０に含まれるメモリ・モジュール６１０ｄは、各装置に以前割り当てられた、また現在割り当てられている変化ＩＤを記憶することができる。幾つかの実施形態では、メモリ・モジュール６１０ｄはまた、ある特定の装置への割り当てを待っている将来の変化ＩＤも記憶することができる。

各プロセッサ６００により実行される機能、従って、各装置のメモリ・モジュール６１０に記憶された命令およびデータは、取引を実行する際にある特定の装置が演じる役割に基づいて構成されることができる。メモリ・モジュール６１０はまた、入力／出力モジュール６２０を介してある特定の装置により受信または送信されるデータも記憶することができる。

図８に示されるように、各装置は、少なくとも１つの通信リンクとインタフェースする入力／出力モジュール６２０を含む。各装置は単一の直接接続により他のすべての装置に接続されるように示されているが、各装置は、上述のように、１または複数のネットワークまたは通信システム上の１または複数の有線または無線の接続を介して、別の装置に接続され得ることを理解されたい。各入力／出力モジュール６２０はまた、同じ通信リンクまたは更なる通信リンクを介して更なる装置とインタフェースすることもできる。

プロセッサ６００により指令されたように、各入力／出力モジュール６２０は、データを別の装置へ出力することができる。同様に、各入力／出力モジュール６２０は、別の装置からデータを受け取り、関連するプロセッサ６００および／またはメモリ・モジュール６１０へデータを送ることができる。上述のように、ある特定の装置の入力／出力モジュール６２０は、プロセッサ６００および／またはメモリ・モジュール６１０を収容する装置の外部の装置内に配置されることができる。

図８に示され、図１により説明されたように、認証手段４８０はまた、乱数発生器６３０も含む。認証手段４８０は、変化ＩＤを使用して売主ＰＯＳ端末において取引を実行するためにシステム４００が実施または準拠するプロトコルにおいて使用される乱数を生成するために、乱数発生器６３０を使用することができる。上述のように、乱数発生器６３０は、真にランダムな数（即ち、本発明を実施するために使用される特定の技術を用いた中で可能な限りランダムな数）を生成することができる。

売主ＰＯＳ端末４２０において取引を完了するため、買手は、ＡＩＣデバイス４６０を介して売主ＰＯＳ端末４２０と通信する。ＡＩＣデバイス４６０は、口座番号などの買手の口座情報と、その口座番号に関連する支払い認証手段（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄなど）と、口座の有効期限などを記憶することができる。ＡＩＣデバイス４６０は、クレジット・カード、セル電話、スマート・カードなどを含むことができ、売主ＰＯＳ端末４２０は、その売主ＰＯＳ端末４２０に関連するクレジット・カード・リーダ、キーパッド、キーボード、スマート・カード・リーダ、無線周波受信機、無線インターネット受信機、赤外線受信機、固定配線ドックなどを介して、ＡＩＣデバイス４６０から口座情報を取得することができる。幾つかの実施形態では、ＡＩＣデバイス４６０は、新しい口座情報を用いて再プログラムすることのできないクレジット・カードなどのスタティックＡＩＣデバイスを含む。他の実施形態では、ＡＩＣデバイス４６０は、新しい口座情報を用いて再プログラムすることのできる再プログラム可能なメモリを有するセル電話、スマート・カード、または他のデバイスなどのような、再プログラム可能なＡＩＣデバイスを含む。以下の実施形態の目的では、取引に含まれるＡＩＣデバイス４６０は、再プログラム可能なＡＩＣデバイスを含む。ＡＩＣデバイス４６０は、口座、建物、車両、部屋、サービス、製品、連絡先個人（例えば、電話番号および／または電子メール・アドレス）などにアクセスするために使用される追加のデータを記憶し得ることを理解されたい。

幾つかの実施形態では、ＡＩＣデバイス４６０は、支払い認証手段４４０により提供または割り当てられた口座情報を記憶することができる。支払い認証手段４４０は、取引に資金供給する（金または他の支払い形式もしくは機構の形で）ために使用することができる買手の１または複数の口座を管理するクレジット・カード会社や金融機関などのエンティティである。支払い認証手段４４０は、有効な要求を受け取ったときに、取引に口座から資金供給することを同意し、従って、口座識別子は、権限のあるエンティティが有効な支払い要求を生成するように、秘密に保たれることが仮定される。従って、本発明の幾つかの実施形態では、システム４００は、ＡＩＣデバイス４６０および支払い認証手段４４０が、買手の口座に関する秘密の口座識別子に合意するように構成される。例えば、電子商取引の例に関して上述されたように、ＡＩＣデバイス４６０および支払い認証手段４４０は、売主ＰＯＳ端末４２０に提供される信用証明書を生成するためのハッシュ関数に合意することができる。他の実施形態では、支払い認証手段４４０は、ＡＩＣデバイス４６０に送信され得かつ／またはプログラムされ得る（例えば、ワイヤレス・インターネット・リンク、セル電話リンク、無線周波リンク、赤外線リンク、新しいメモリ・モジュール、直接配線再プログラミング・ドックなどを介して）１または複数の１回限り使用可の口座番号を生成することができる。それぞれの１回限り使用可の口座番号は、ＡＩＣデバイス４６０により１回だけ使用されることができる（１つの取引のために１つの売主ＰＯＳ端末４２０に提供される）。１回限り使用可の口座番号の使用は、１回限り使用可の口座番号が盗聴者により取得されたとしても、１回限り使用可の口座番号はすでに使用されており、再使用することはできないので、盗聴者は、不法な取引を実行するためにその１回限り使用可の口座番号を使用することができないため、口座情報のセキュリティを高める。代替例として、ＡＩＣデバイス４６０は、カード（例えば、クレジットまたはデビット・カード）上に従来のように視覚的に表示された口座番号などのような、ＡＩＣデバイス４６０に関連するそれぞれの口座用の単一の口座番号を含む口座情報を記憶することができる。

加えて、ＡＩＣデバイス４６０および売主ＰＯＳ端末４２０は各々、認証手段４８０および変化ＩＤの保有者だけが知っている、認証手段４８０により割り当てられた変化ＩＤを記憶する。ＡＩＣデバイス４６０および売主ＰＯＳ端末４２０は、情報（例えば、口座情報）を、互いの間でおよび／または認証手段４８０へ送る前に、情報を暗号化するために変化ＩＤを使用する。認証手段４８０だけが変化ＩＤを知っているので、売主ＰＯＳ端末４２０は、ＡＩＣデバイス４６０に割り当てられた変化ＩＤを用いて暗号化またはパッケージ化された、ＡＩＣデバイス４６０から提供された情報を取得することができず、また、ＡＩＣデバイス４６０は、売主ＰＯＳ端末４２０に関連する変化ＩＤを用いて暗号化またはパッケージ化された、売主ＰＯＳ端末４２０から提供された情報を取得することができない。加えて、認証手段４８０は、ＡＩＣデバイス４６０および売主ＰＯＳ端末４２０に割り当てられた変化ＩＤを知っているので、ＡＩＣデバイス４６０および売主ＰＯＳ端末の両方から受け取った暗号化情報を暗号解除することができ、取引を続けることを許可する前に、各エンティティにより提供された情報を検証することができる。

幾つかの実施形態では、取引を完了するため、売主ＰＯＳ端末４２０は、売主情報をＡＩＣデバイス４６０に提示し、ＡＩＣデバイス４６０は、買手情報と、売主ＰＯＳ端末４２０から受け取った売主情報を、認証手段４８０に提示する。他の実施形態では、売主ＰＯＳ端末４２０が、ＡＩＣデバイス４６０から買手情報を取得し、ＡＩＣデバイス４６０から受け取った買手情報と、売主情報を、認証手段４８０に提示する。また他の実施形態では、売主ＰＯＳ端末４２０およびＡＩＣデバイス４６０は別々に、認証手段４８０および／または支払い認証手段４４０に情報を提示する。

幾つかの実施形態では、売主ＰＯＳ端末４２０および／または認証手段４８０へ情報を送る前に、ＡＩＣデバイス４６０は、買手が、個人識別番号（ＰＩＮ）や生体測定情報などの認証情報を入力することを要求する。ＡＩＣデバイス４６０は、ＡＩＣデバイス４６０に記憶された口座情報に関連する買手がＡＩＣデバイス４６０を使用しており、詐称者ではないことを保証するために、認証情報を使用する。ＡＩＣデバイス４６０は、買手の認証情報を記憶することができ、取引中にＡＩＣデバイス４６０のユーザにより提供された認証情報を、記憶された認証情報と比較することができる。提供された認証情報が記憶された認証情報と一致する場合、ＡＩＣデバイス４６０は、売主ＰＯＳ端末４２０および／または認証手段４８０に暗号化された口座情報を送る。認証情報が一致しない場合、ＡＩＣデバイス４６０は、取引を拒絶し、売主ＰＯＳ端末４２０および／または認証手段４８０へ口座情報を送らない。ユーザは、ＡＩＣデバイス４６０の１または複数の選択機構または入力機構を介して認証情報を入力することができ、または、売主ＰＯＳ端末４２０の１または複数の選択機構もしくは入力機構を介して認証情報を入力することができる。

認証手段４８０は、売主ＰＯＳ端末４２０およびＡＩＣデバイス４６０から情報を受け取ると、支払い認証手段４４０に対する支払い要求を生成する。電子商取引の例に関して上述したように、支払い要求は、ＡＩＣデバイス４６０および売主ＰＯＳ端末４２０から受け取った口座情報および／または取引情報を含むことができる。幾つかの実施形態では、認証手段４８０はまた、支払い認証手段４４０に変化ＩＤを割り当て、支払い認証手段４４０に割り当てた変化ＩＤを用いて支払い要求を暗号化する。

支払い認証手段４４０は、支払い要求を検証し、要求を承認または拒否することができる。支払い認証手段４４０は、直接的に、または認証手段４８０を介して間接的に、売主ＰＯＳ端末４２０および／またはＡＩＣデバイス４６０に応答を送る。

以下で詳細に説明されるように、支払い要求を支払い認証手段４４０へ送ることに加えて、認証手段４８０はまた、新しい変化ＩＤを各エンティティへ提供することができる。認証手段４８０は、割り当てた変化ＩＤをデータベースまたは類似の機構を使用して追跡する。

幾つかの実施形態では、認証手段４８０および支払い認証手段４４０の機能は、組み合わされ、単一のエンティティにより提供されることができ、従って、認証手段４８０は、別個の支払い要求を支払い認証手段に送信することなく、取引に対する支払いを直接的に拒否または承認することができる。

図７に示されるシステム４００を含む、取引を完了するためのプロトコルの一例を説明する。この例では、アリス（例えば、Ａ）は、ＡＩＣデバイス４６０を表し、買手の１または複数の口座（例えば、クレジット口座、デビット口座、ロイヤルティ口座（ｌｏｙａｌｔｙ ａｃｃｏｕｎｔ）、ストアド・バリュー口座（ｓｔｏｒｅｄ ｖａｌｕｅ ａｃｃｏｕｎｔ）など）に関する情報を管理する。ヴェラ（例えば、Ｖ）は、売主ＰＯＳ端末４２０を表す。トレント（例えば、Ｔ）は、認証手段４８０、すなわち、販売の信用できる仲裁者を表す。キャロル（例えば、Ｃ）は、ＡＩＣデバイス４６０に記憶された口座情報に関連する口座にアクセスする、クレジット・カード会社や他の口座提供者などの支払い認証手段４４０を表す。上記の表１は、提案されるプロトコルの実施形態を説明するために使用される他の符号のリストである。

この例については、アリスは、小売販売取引において、クレジット・カード口座番号をヴェラに安全に伝えたいものと仮定する。加えて、アリスは、キャロルのもとに記録されているクレジット・カード口座番号を表す口座情報Ａｃｃｏｕｎｔ_Ａをキャロルから先に受け取っており、また秘密鍵Ｋ_Ａおよび識別番号Ｎ_Ａ（即ち、変化ＩＤ）をトレントから先に受け取っているものと仮定する。更に、トレントは、キャロルに秘密鍵Ｋ_Ｃおよび識別番号Ｎ_Ｃを先に割り当てており、ヴェラに秘密鍵Ｋ_Ｖおよび識別番号Ｎ_Ｖを先に割り当てているものと仮定する。幾つかの実施形態では、トレントはまた、アリス、ヴェラ、および／またはキャロルに、各エンティティがメッセージに含めることができる信用証明書（例えば、それぞれＡ_ｃｒｅｄ、Ｖ_ｃｒｅｄ、Ｃ_ｃｒｅｄ）を割り当てる。トレントは、メッセージが本当にアリス、ヴェラ、および／またはキャロルにより構成されたことを検証するために、信用証明書を使用することができる。

取引を開始するため、アリスは、アリスの秘密鍵Ｋ_Ａを用いて、取引情報（例えば、口座情報Ａｃｃｏｕｎｔ_Ａおよび価格Ｐ）を暗号化する。幾つかの実施形態では、アリスはまた、アリスの秘密鍵Ｋ_Ａを用いて、キャロルの識別子（例えば、Ｃ_ｉｄ）および／またはアリスの信用証明書Ａ_ｃｒｅｄも暗号化する。アリスは、その暗号化の結果としてできたものにアリスの識別番号Ｎ_Ａを追加し、そのメッセージをヴェラに送る。

Ａ→Ｖ：Ｎ_ＡＥ（Ｋ_Ａ，Ａｃｃｏｕｎｔ_ＡＰＣ_ｉｄ）

上述のように、ＡＩＣデバイス４６０は、買手に関連する口座番号に関する口座情報を記憶することができる。一実施では、ＡＩＣデバイス４６０は、使用可能な口座情報または使用可能な口座情報の識別子（例えば、買手により設定された説明）をＡＩＣデバイス４６０のディスプレイ上で買手に表示し、買手は、ＡＩＣデバイス４６０上の１または複数の選択機構（例えば、キーパッド、タッチスクリーンなど）を使用して、現在の取引のための特定の口座情報を選択する。ＡＩＣデバイス４６０は、選択された口座情報を売主ＰＯＳ端末４２０へ送る。代替例として、ＡＩＣデバイス４６０は、ＡＩＣデバイス４６０により管理されるすべての使用可能な口座情報またはすべての使用可能な口座情報の識別子を売主ＰＯＳ端末４２０へ送信することができ、売主ＰＯＳ端末４２０は、使用可能な口座情報を買手に表示することができる。買手は、その後、キーパッド、タッチスクリーンなどのような、売主ＰＯＳ端末４２０上の１または複数の選択機構を使用して、特定の口座情報を選択することができる。例えば、買手は、現在の取引の支払い元として、Ｖｉｓａ（登録商標）クレジット・カード口座ではなく、ＭａｓｔｅｒＣａｒｄ（登録商標）クレジット・カード口座を使用するように選択することができる。

上述のように、幾つかの実施形態では、ＡＩＣデバイス４６０は、ＡＩＣデバイス４６０が取引情報（例えば、口座情報）を売主ＰＯＳ端末４２０へ送信する前に、認証情報（例えば、ＰＩＮ、パスワード、フィンガプリント、網膜スキャンなど）を入力するように買手に要求することができる。買手は、ＡＩＣデバイス４６０上の１または複数の選択または入力の機構を使用して、認証情報を入力することができる。他の実施形態では、買手は、認証情報を提供するために、売主ＰＯＳ端末４２０の１または複数の選択または入力の機構を使用することができる。買手が認証情報を提供するために売主ＰＯＳ端末４２０を使用する場合、売主ＰＯＳ端末４２０は、認証情報を検証すること、認証情報を検証のために第三者機関に送ること、および／または入力された認証情報を検証のためにＡＩＣデバイス４６０に送ることができる。

一実施では、買手は、キーパッドまたはタッチスクリーンなどのような、ＡＩＣデバイス４６０および／または売主ＰＯＳ端末４２０の１または複数の選択機構を使用して、取引に含まれる商品およびサービスの価格Ｐを入力する。代替例として、売主ＰＯＳ端末４２０は、アリスが取引の処理を開始する前に、価格Ｐを（例えば、平文として）ＡＩＣデバイス４６０へ送信する。ＡＩＣデバイス４６０は、アリスおよびヴェラが共通価格に合意したことをトレントが認証し得るように、暗号化された取引データに価格Ｐを含める。

幾つかの実施形態では、取引情報はまた、ヴェラ、即ち、取引に関連する売主の識別子（例えば、Ｖ_ｉｄ）を含むこともできる。買手は、ＡＩＣデバイス４６０に含まれる１または複数の選択機構を使用して、売主の識別子Ｖ_ｉｄを入力することができ、また、ＡＩＣデバイス４６０は、売主ＰＯＳ端末４２０または第三者のデバイスもしくはシステムから、売主の識別子を取得することができる。ＡＩＣデバイス４６０は、トレントが取引に関与するエンティティを検証し、買手の代わりと偽って売主が取引を開始することを防止し得るように、暗号化された取引情報に売主の識別子を含めることができる。

アリスから暗号化情報を受け取ると、ヴェラは、取引の価格Ｐなどの取引情報とヴェラの識別子または口座識別子Ｖ_ｉｄとを、アリスから提供された暗号化情報に連結し、その結果としてできたものをヴェラの秘密鍵Ｋ_Ｖを用いて暗号化する。ヴェラは、暗号化の結果としてできたものにヴェラの識別番号Ｎ_Ｖを追加し、そのメッセージをトレントへ送る。

Ｖ→Ｔ：Ｎ_ＶＥ（Ｋ_Ｖ，ＰＶ_ｉｄＮ_Ａ（Ｋ_Ａ，Ａｃｃｏｕｎｔ_ＡＰＣ_ｉｄ））

幾つかの実施形態では、ヴェラはまた、アリス、即ち、取引に関連する買手の識別子（例えば、Ａ_ｉｄ）を取引情報に含めることもできる。売主ＰＯＳ端末４２０は、識別子を入力するように買手を促すことができ、買手は、ＡＩＣデバイス４６０または売主ＰＯＳ端末４２０に含まれる１または複数の選択機構を使用して、識別子を入力することができる。売主ＰＯＳ端末４２０は、トレントが取引に関与するエンティティを検証し得るように、暗号化取引情報に識別子を含めることができる。

上述のように、ヴェラはまた、取引情報を暗号化し、暗号化取引情報をアリスへ送ることにより、取引を開始することもできる。アリスは、アリスの取引情報とヴェラから受け取った暗号化取引情報とを連結し、その結果としてできたものをアリスの変化ＩＤを用いて暗号化し、結果的なメッセージをトレントへ送る。他の実施形態では、ヴェラおよびアリスは別々に、各自の情報をトレントへ送ることができる。

トレントは、ヴェラに関連する番号Ｎ_Ｖおよびアリスに関連する番号Ｎ_Ａを知っているので、メッセージがヴェラおよびアリスから来たことを識別する。トレントは、Ｋ_ＶおよびＫ_Ａを使用してメッセージを暗号解除する。幾つかの実施形態では、アリスおよび／またはヴェラが信用証明書を提供した場合、トレントは、その信用証明書を検証する。信用証明書が有効ではない（例えば、アリスおよび／またはヴェラに現在割り当てられている信用証明書と一致しない）場合、トレントは、取引を拒否し、拒否応答をヴェラおよび／またはアリスへ送る。トレントはまた、ヴェラおよびアリスから受け取った取引情報またはその一部が一致することも検出する。例えば、トレントは、ヴェラおよびアリスから受け取った価格Ｐが一致することを検出することができる。価格が一致しない場合、トレントは、取引を拒否し、拒否応答をヴェラおよび／またはアリスへ送る。加えて、トレントが取引を拒否する場合、トレントは、以下で説明するように、新しい変化ＩＤをアリスおよびヴェラに提供することができる。

トレントがアリスおよびヴェラから受け取った情報の正当性を認めた場合、トレントは、キャロルに対する支払い要求を生成する。支払い要求は、口座情報Ａｃｃｏｕｎｔ_Ａと、取引情報（例えば、関連商品およびサービスの価格Ｐ）と、ヴェラの識別子Ｖ_ｉｄとを含むことができる。幾つかの実施形態では、支払い要求は、付加的な情報またはより少ない情報を含み得る。例えば、支払い要求はまた、アリスの識別子および／またはヴェラの口座情報を含むこともできる。支払い要求はまた、キャロル用の新しい変化ＩＤ（例えば、Ｎ_Ｃ’およびＫ_Ｃ’）を含むこともできる。トレントは、支払い要求をキャロルの現在の秘密鍵Ｋ_Ｃを用いて暗号化することができる。トレントはまた、その暗号化の結果としてできたものにキャロルの現在の識別番号Ｎ_Ｃを追加することもできる。トレントは、結果的の支払い要求をキャロルに送る。

Ｔ→Ｃ：Ｎ_ＣＥ（Ｋ_Ｃ，Ａｃｃｏｕｎｔ_ＡＰＶ_ｉｄ）

幾つかの実施形態では、ある特定の取引に対する支払いが複数の支払い元（例えば、複数の口座）を含む場合、トレントは、支払い要求を生成し、その支払い要求を、取引を完了するために資金が引き落とされる口座を管理する各支払い認証手段へ送信することができる。

キャロルは、支払い要求を暗号解除し、支払い要求を承認するか拒否するかを決定するために、要求に含まれる情報を使用する。キャロルが支払い要求を承認する（例えば、Ａｃｃｏｕｎｔ_Ａにより識別される口座が価格Ｐをまかなうのに十分な資金を含み、売主の識別子Ｖ_ｉｄが有効な売主識別子である）場合、キャロルは、承認応答を生成することができる。承認応答は、承認メッセージまたは識別子（例えば、ＡＣＣＥＰＴ）と、取引識別子（例えば、Ｔｒａｎ_ｉｄ）とを含むことができる。承認応答はまた、価格Ｐなどの取引情報および売主識別子Ｖ_ｉｄを含むこともできる。

キャロルは、キャロルの秘密鍵Ｋ_Ｃを用いて承認応答を暗号化し、キャロルの識別番号Ｎ_Ｃを追加し、その結果としてできたものをトレントへ送る。幾つかの実施形態では、キャロルはまた、承認応答にキャロルの信用証明書Ｃ_ｃｒｅｄも含める。

Ｃ→Ｔ：Ｎ_ＣＥ（Ｋ_Ｃ，ＡＣＣＥＰＴ ＰＶ_ｉｄＣ_ｃｒｅｄ）

トレントは、暗号化した承認応答を暗号解除し、キャロルの信用証明書Ｃ_ｃｒｅｄを検証する（提供された場合）。次に、トレントは、ヴェラおよびアリス宛ての承認メッセージを生成する。例えば、ヴェラ宛ての承認メッセージを生成するため、トレントは、キャロルからの暗号解除された承認応答（キャロルの信用証明書Ｃ_ｃｒｅｄが提供された場合は、それを伴わずに）をヴェラの秘密鍵Ｋ_Ｖを用いて暗号化することができ、その暗号化の結果としてできたものにヴェラの識別番号Ｎ_Ｖを追加することができる。幾つかの実施形態では、トレントは、承認メッセージを暗号化する前に、承認メッセージに情報を追加することができる。例えば、トレントは、ヴェラ用の新しい変化ＩＤ（例えば、Ｎ_Ｖ’およびＫ_Ｖ’）を承認メッセージに追加することができる。トレントは、承認メッセージをヴェラへ送る。

Ｔ→Ｖ：Ｎ_ＶＥ（Ｋ_Ｖ，ＡＣＣＥＰＴ ＰＶ_ｉｄＮ_Ｖ’Ｋ_Ｖ’）

トレントはまた、暗号解除されたキャロルからの承認応答（キャロルの信用証明書Ｃ_ｃｒｅｄが提供された場合、それを伴わずに）をアリスの秘密鍵Ｋ_Ａを用いて暗号化し、その暗号化の結果としてできたものにアリスの識別番号Ｎ_Ａを追加することにより、アリス宛ての承認メッセージも生成する。トレントはまた、アリス用の新しい変化ＩＤ（例えば、Ｎ_Ａ’、Ｋ_Ａ’）などの追加情報を承認メッセージに追加することができる。トレントは、承認メッセージをアリスへ送る。

Ｔ→Ａ：Ｎ_ＡＥ（Ｋ_Ａ，ＡＣＣＥＰＴ ＰＶ_ｉｄＮ_Ａ’Ｋ_Ａ’）

代替例として、別個の承認メッセージをヴェラおよびアリスへ直接に送る代わりに、トレントは、アリス宛ての承認メッセージを含む承認メッセージをヴェラへ送ることができ、ヴェラは、承認メッセージをアリスへ送ることができる。

キャロルが支払い要求を拒否する（例えば、Ａｃｃｏｕｎｔ_Ａが価格Ｐをまかなうのに十分な資金を含まず、口座情報Ａｃｃｏｕｎｔ_Ａが有効な口座を識別せず、または売主の識別子Ｖ_ｉｄが有効な売主識別子でない）場合、キャロルは、拒否応答を生成することができる。拒否応答は、拒否メッセージまたは識別子（例えば、ＤＥＣＬＩＮＥ）と、取引識別子（例えば、Ｔｒａｎ_ｉｄ）とを含むことができる。拒否応答はまた、取引情報（例えば、価格Ｐ）および／または売主識別子Ｖ_ｉｄを含むこともできる。キャロルは、拒否応答をトレントへ送る。

Ｃ→Ｔ：Ｎ_ＣＥ（Ｋ_Ｃ，ＤＥＣＬＩＮＥ ＰＶ_ｉｄＣ_ｃｒｅｄ）

承認応答に関して上述したように、トレントは、拒否応答を検証し、キャロルから受け取った拒否応答に基づいて、ヴェラおよびアリス宛ての拒否メッセージを生成する。

トレントから承認メッセージまたは拒否メッセージを受け取った後、ヴェラおよび／またはアリスは、受領証を生成すること、および／または取引情報を記憶することができる。受領証および／または情報は、キャロルにより提供された取引識別子Ｔｒａｎ_ｉｄを含むことができ、取引識別子は、取引情報にアクセスするため、または取引情報をキャロルから取得するために使用することができる。

上述のように、ＡＩＣデバイス４６０は、ある特定の口座に関する１または複数の１回限り使用可の口座番号を記憶することができる。それぞれの１回限り使用可の口座番号は、１回だけ使用される（１つの取引のために１つの売主ＰＯＳ端末４２０に提供される）ことができる。アリスが取引を実行するために１回限り使用可の口座番号を使用した場合、取引が完了した（例えば、承認または拒否された）後、アリスは、１または複数の新しい１回限り使用可の口座識別子をキャロルに要求すること、および／またはキャロルから取得することができる。例えば、アリスは、将来の取引用の１または複数の新しい１回限り使用可の口座識別子を受け取るために、キャロルに電話を掛けることができる。新しい１回限り使用可の口座識別子は、上述のように、１または複数の通信リンクを介してＡＩＣデバイス４６０に送信されること、および／またはプログラムされることができる。

上記のプロトコルは、口座情報が盗まれる可能性または不法に使用される可能性を大きく低下させる。例えば、アリスは、アリスおよびトレントだけが暗号解除し得る暗号化された口座情報を提供するので、ヴェラが、実際の口座情報を所有することは決してない。加えて、口座情報は１つの取引だけで使用し得る変化ＩＤを用いて暗号化されるので、取引は再実行されることはできない。

更に、上記のプロトコルは、ＡＩＣデバイス４６０が盗難にあった又は紛失したことが報告された場合、ＡＩＣデバイス４６０が認証手段から特定の無効の変化ＩＤを受け取ることを可能にするための機構などのような、付加的なセキュリティ機能を提供するために拡張されることができる。盗難にあった又は紛失したと報告されたＡＩＣデバイス４６０の使用、従って、無効の変化ＩＤを割り当てられたＡＩＣデバイス４６０の使用は、無効の変化ＩＤの使用を生じさせ、ＡＩＣデバイス４６０が不法に使用されていることを認証手段４８０に警告する。ＡＩＣデバイス４６０が紛失した又は盗難にあったと報告された場合、ＡＩＣデバイス４６０に記憶された口座情報はまた、遠隔操作で削除または無効化されることもできる（例えば、認証手段、支払い認証手段、および／またはＡＩＣデバイス４６０のユーザにより発行されるコマンドを介して）。例えば、買手は、ＡＩＣデバイスが紛失した後または盗難にあった後、ＡＩＣデバイス４６０が不法に使用され得ないように、支払い認証手段４４０に要求を送信して（例えば、通報して）、ＡＩＣデバイス４６０に記憶された口座情報を無効化することができる。

上述した、図８に示されるＰＯＳ取引プロトコルのステップおよび／または順序は、変更され得ることを理解されたい。例えば、ヴェラおよびアリスは、取引を安全に取り決めるために、トレントにセッション鍵を要求し、受け取ることができる。代替例または追加例として、ヴェラおよびキャロル、および／または、アリスおよびキャロルは、ヴェラおよび／またはアリスが、口座情報などの取引情報を、トレントを介して渡すことなく、キャロルへ直接に提供することができるように、トレントにセッション鍵を要求し、受け取ることができる。幾つかの実施形態では、トレントはまた、支払い要求の承認または拒絶時にキャロルがヴェラおよび／またはアリスへ直接に送ることができる受領証、メッセージ、および／または新しい変化ＩＤを生成し、キャロルに提供することもできる。更に、キャロルは、承認または拒否メッセージを平文としてヴェラおよび／またはアリスへ直接に送ることもできる。認証手段４８０および支払い認証手段４６０の役割は、組み合わされることもできる。例えば、各支払い認証手段４６０は、変化ＩＤを各自のクライアント（支払い認証手段が口座を管理する個人）に提供することができる。

更に、セッション鍵、コンテンツ使用ライセンス、デジタル署名、発見可能データおよび発見不可能データ、ならびに電子取引に関して上述された通信および取引プロトコル（またはその一部）は、提案されたＰＯＳ取引プロトコルと組み合わされ得ることも理解されたい。例えば、ＰＯＳ取引は、コンテンツ・プロバイダまたはサービス・プロバイダからのデジタル・コンテンツの購入に含まれることができる。加えて、ＰＯＳ取引は、一意性を保証するために、取引データおよび対応する受領証に透かしを入れることができる。更に、ＰＯＳ取引は、ヴェラ、ボブ、トレント、およびキャロルの間で渡されるメッセージに対する力づく攻撃の有効性を低下させるために、上述のような個別暗号化プロトコルを使用し、発見可能データおよび発見不可能データを別々の無関係な鍵を用いて暗号化することができる。他の組み合わせおよび構成も可能である。

本発明の実施形態の様々な特徴は、添付の特許請求の範囲において説明される。

図１は、本発明の一実施形態による、ネットワーク内でデータを送信するためのシステムを概略的に示す。 図２は、本発明の一実施形態による、ビット・ストリーム（「変化ＩＤ」と呼ばれる）を示す。 図３のＡおよびＢは、変化ＩＤを配布する方法を示す。 図４は、電子商取引を実行するための通信に４つのエンティティが含まれる、本発明の例示的な一実施形態のシステムの概略図である。 図５は、本発明の一実施形態による、図４のシステムにおいて使用されるプロトコルの概略図である。 図６は、例示的なＰＯＳ端末と、２つの例示的な口座情報保持体デバイス、（セル電話、スマート・カード、およびクレジット・カード）を示す。 図７は、ＰＯＳ端末において取引を実行するための通信に４つのエンティティが含まれる、本発明の例示的な一実施形態のシステムの概略図である。 図８は、本発明の一実施形態による、図７のシステムに含まれる装置の概略図である。 図９は、本発明の一実施形態による、図７のシステムにおいて使用される通信プロトコルの概略図である。

Claims (56)

1. 第１のエンティティと第２のエンティティの間の取引を、前記第２のエンティティのＰＯＳ端末において実行する方法であって、
   暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化するステップと、
   暗号化された前記買手取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送信するステップと、
   暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化するステップと、
   暗号化された前記売主取引情報を、少なくとも１つの通信リンクを介して、前記認証手段へ送信するステップと、
   前記認証手段において、前記第１の変化識別子および前記第２の変化識別子を使用済としてマーク付けするステップと
   備える方法。
2. 請求項１に記載の方法であって、前記暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送信する前記ステップが、前記暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスから認証手段へ送信するステップを含む、方法。
3. 請求項１に記載の方法であって、前記暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスから前記ＰＯＳ端末へ送信するステップを更に備える方法。
4. 請求項３に記載の方法であって、前記暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、認証手段へ送信する前記ステップが、前記暗号化された買手取引情報を、少なくとも１つの通信リンクを介して、前記ＰＯＳ端末から前記認証手段へ送信するステップを含む、方法。
5. 請求項４に記載の方法であって、暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化する前記ステップが、連結された取引情報を生成するために、暗号化された前記買手取引情報と前記売主取引情報とを連結するステップと、前記暗号化された取引情報を生成するために、前記第２の変化識別子を用いて、前記連結された取引情報を暗号化するステップとを含む、方法。
6. 請求項１に記載の方法であって、前記口座情報保持体デバイスにおいて前記認証手段から第３の変化識別子を受け取るステップが、前記口座情報保持体デバイスにおいて前記認証手段から第３の変化識別子を受け取るステップを含み、前記口座情報保持体デバイスが、セルラ電話、スマート・カード、クレジット・カード、ＰＤＡ、およびオーディオ・プレーヤのうちの少なくとも１つを含む、方法。
7. 請求項１に記載の方法であって、暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化する前記ステップが、前記第１の変化識別子を用いて買手口座識別子を暗号化するステップを含み、前記買手口座識別子は、前記第１のエンティティに関連する口座を識別する、方法。
8. 請求項７に記載の方法であって、前記第１のエンティティから口座の選択を受け取るステップを更に備える方法。
9. 請求項８に記載の方法であって、前記第１の変化識別子を用いて買手口座識別子を暗号化する前記ステップが、前記第１の変化識別子を用いて、前記口座の選択に関連する買手口座識別子を暗号化するステップを含む、方法。
10. 請求項１に記載の方法であって、暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化する前記ステップが、前記第１の変化識別子を用いて、前記取引に関連する価格を暗号化するステップを含む、方法。
11. 請求項１０に記載の方法であって、前記価格を、前記ＰＯＳ端末から、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
12. 請求項１０に記載の方法であって、前記価格を、前記第１のエンティティから、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
13. 請求項１に記載の方法であって、暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化する前記ステップが、前記第１の変化識別子を用いて前記第２のエンティティの識別子を暗号化するステップを含む、方法。
14. 請求項１３に記載の方法であって、前記第２のエンティティの前記識別子を、前記ＰＯＳ端末から、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
15. 請求項１３に記載の方法であって、前記第２のエンティティの前記識別子を、前記第１のエンティティから、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
16. 請求項１に記載の方法であって、暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化する前記ステップが、前記第１の変化識別子を用いて前記第１のエンティティの信用証明書を暗号化するステップを含む、方法。
17. 請求項１６に記載の方法であって、前記信用証明書を、前記認証手段から、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
18. 請求項１に記載の方法であって、暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化する前記ステップが、前記第２の変化識別子を用いて売主口座識別子を暗号化するステップを含み、前記売主口座識別子は、前記第２のエンティティに関連する口座を識別する、方法。
19. 請求項１に記載の方法であって、暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化する前記ステップが、前記第２の変化識別子を用いて、前記取引に関連する価格を暗号化するステップを含む、方法。
20. 請求項１に記載の方法であって、暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化する前記ステップが、前記第２の変化識別子を用いて前記第１のエンティティの識別子を暗号化するステップを含む、方法。
21. 請求項２０に記載の方法であって、前記第１のエンティティの前記識別子を、前記買手から、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つにおいて受け取るステップを更に備える方法。
22. 請求項１に記載の方法であって、認証情報を前記第１のエンティティから受け取るステップを更に備える方法。
23. 請求項２２に記載の方法であって、認証情報を前記第１のエンティティから受け取る前記ステップが、個人識別番号、パスワード、フィンガプリント、および網膜スキャンのうちの少なくとも１つを前記第１のエンティティから受け取るステップを含む、方法。
24. 請求項２２に記載の方法であって、認証情報を前記第１のエンティティから受け取る前記ステップが、認証情報を、前記第１のエンティティから、前記口座情報保持体デバイスにおいて受け取るステップを含む、方法。
25. 請求項２２に記載の方法であって、認証情報を前記第１のエンティティから受け取る前記ステップが、認証情報を、前記第１のエンティティから、前記ＰＯＳ端末において受け取るステップを含む、方法。
26. 請求項２２に記載の方法であって、前記暗号化された買手取引情報を前記認証手段へ送信する前に、前記認証情報を前記口座情報保持体デバイスにおいて検証するステップを更に備える方法。
27. 請求項２６に記載の方法であって、前記口座情報保持体デバイスが前記認証情報の正当性を認めない場合、前記暗号化された買手取引情報の前記認証手段への送信を防止するステップを更に備える方法。
28. 請求項１に記載の方法であって、前記第１の変化識別子を、前記認証手段から、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスにおいて受け取るステップを更に備え、前記第１の変化識別子は番号および鍵を含む、方法。
29. 請求項２８に記載の方法であって、暗号化された買手取引情報を生成するために、前記第１のエンティティに関連付けられた口座情報保持体デバイスに記憶された第１の変化識別子を用いて、前記買手取引情報を暗号化する前記ステップが、暗号化データを生成するために前記鍵を用いて前記買手取引情報を暗号化するステップと、前記暗号化された買手取引情報を生成するために、前記暗号化データに前記番号を追加するステップとを含む、方法。
30. 請求項１に記載の方法であって、前記第２の変化識別子を、前記認証手段から、少なくとも１つの通信リンクを介して、前記ＰＯＳ端末において受け取るステップを更に備え、前記第２の変化識別子は番号および鍵を含む、方法。
31. 請求項３０に記載の方法であって、暗号化された売主取引情報を生成するために、前記ＰＯＳ端末に記憶された第２の変化識別子を用いて、前記売主取引情報を暗号化する前記ステップが、暗号化データを生成するために前記鍵を用いて売主取引情報を暗号化するステップと、前記暗号化された売主取引情報を生成するために、前記暗号化データに前記番号を追加するステップとを含む、方法。
32. 請求項１に記載の方法であって、第３の変化識別子を、前記認証手段から、前記口座情報保持体デバイスにおいて受け取るステップを更に備える方法。
33. 請求項１に記載の方法であって、第４の変化識別子を、前記認証手段から、前記ＰＯＳ端末において受け取るステップを更に備える方法。
34. 第１のエンティティと第２のエンティティとの間の取引を認証手段により前記第２のエンティティのＰＯＳ端末において管理する方法であって、
    第１の変化識別子を、少なくとも１つの通信リンクを介して、前記第１のエンティティに関連した口座情報保持体デバイスへ提供するステップと、
    第２の変化識別子を、少なくとも１つの通信リンクを介して、前記ＰＯＳ端末へ提供するステップと、
    暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つから受け取るステップであって、暗号化された前記取引情報は、前記第１の変化識別子および前記第２の変化識別子の少なくとも一つを用いて暗号化される、ステップと、
    暗号解除された取引情報を取得するために、前記第１の変化識別子および前記第２の変化識別子の少なくとも一つを用いて、前記暗号化された取引情報を暗号解除するステップと、
    暗号解除された前記取引情報に基づいて支払い要求を生成するステップと、
    前記支払い要求を、少なくとも１つの通信リンクを介して、支払い認証手段へ送信するステップと、
    前記第１の変化識別子および前記第２の変化識別子を使用済としてマーク付けするステップと
    を備える方法。
35. 請求項３４に記載の方法であって、第１の変化識別子を、少なくとも１つの通信リンクを介して、前記第１のエンティティに関連した口座情報保持体デバイスへ提供する前記ステップが、番号および鍵を含む第１の変化識別子を、少なくとも１つの通信リンクを介して、前記第１のエンティティに関連した口座情報保持体デバイスへ提供するステップを含む、方法。
36. 請求項３５に記載の方法であって、前記鍵を記憶するステップを更に備える方法。
37. 請求項３４に記載の方法であって、第２の変化識別子を、少なくとも１つの通信リンクを介して、前記第２のエンティティに関連したＰＯＳ端末へ提供する前記ステップが、番号および鍵を含む第２の変化識別子を、少なくとも１つの通信リンクを介して、前記第２のエンティティに関連付けられたＰＯＳ端末へ提供するステップを含む、方法。
38. 請求項３７に記載の方法であって、前記鍵を記憶するステップを更に備える方法。
39. 請求項３４に記載の方法であって、暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つから受け取る前記ステップが、暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスから受け取るステップを含み、前記暗号化された取引情報が、前記第１の変化識別子を用いて暗号化された第１のメッセージと、前記第２の変化識別子を用いて暗号化された第２のメッセージとを含む、方法。
40. 請求項３９に記載の方法であって、暗号解除された取引情報を取得するために、前記第１の変化識別子および前記第２の変化識別子の少なくとも一つを用いて、前記暗号化された取引情報を暗号解除する前記ステップが、前記第１の変化識別子を用いて前記第１のメッセージを暗号解除するステップと、前記第２の変化識別子を用いて前記第２のメッセージを暗号解除するステップとを含む、方法。
41. 請求項３４に記載の方法であって、暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つから受け取る前記ステップが、暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記ＰＯＳ端末から受け取るステップを含み、前記暗号化された取引情報が、前記第２の変化識別子を用いて暗号化された第１のメッセージと、前記第１の変化識別子を用いて暗号化された第２の部分とを含む、方法。
42. 請求項４１に記載の方法であって、暗号解除された取引情報を取得するために、前記第１の変化識別子および前記第２の変化識別子の少なくとも一つを用いて、前記暗号化された取引情報を暗号解除する前記ステップが、前記第２の変化識別子を用いて前記第１のメッセージを暗号解除するステップと、前記第１の変化識別子を用いて前記第２のメッセージを暗号解除するステップとを含む、方法。
43. 請求項３４に記載の方法であって、前記暗号解除された取引情報を検証するステップを更に備える方法。
44. 請求項４３に記載の方法であって、前記暗号解除された取引情報に基づいて、支払い要求を生成する前記ステップが、前記暗号解除された取引情報の正当性が認められた場合に、前記暗号解除された取引情報に基づいて支払い要求を生成するステップを含む、方法。
45. 請求項４４に記載の方法であって、前記暗号解除された取引情報の正当性が認められなかった場合、拒否メッセージを生成し、前記口座情報保持体および前記ＰＯＳ端末の少なくとも一つへ送信するステップを更に備える、方法。
46. 請求項３４に記載の方法であって、第３の変化識別子を、少なくとも１つの通信リンクを介して、前記支払い認証手段へ提供するステップを更に備える方法。
47. 請求項４６に記載の方法であって、前記第３の変化識別子を用いて前記支払い要求を暗号化するステップを更に備える方法。
48. 請求項３４に記載の方法であって、支払い応答を、少なくとも１つの通信リンクを介して、前記支払い認証手段から受け取るステップを更に備え、前記支払い応答が、支払い承認メッセージおよび支払い拒否メッセージの少なくとも一つを含む、方法。
49. 請求項４８に記載の方法であって、前記支払い応答が支払い承認メッセージを含む場合、承認メッセージを生成し、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つへ送信するステップを更に備える方法。
50. 請求項４８に記載の方法であって、前記支払い応答が支払い拒否メッセージを含む場合、拒否メッセージを生成し、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスおよび前記ＰＯＳ端末の少なくとも一つへ送信するステップを更に備える方法。
51. 請求項３４に記載の方法であって、第４の変化識別子を、少なくとも１つの通信リンクを介して、前記口座情報保持体デバイスへ提供するステップを更に備える方法。
52. 請求項３４に記載の方法であって、第５の変化識別子を、少なくとも１つの通信リンクを介して、前記ＰＯＳ端末へ提供するステップを更に備える方法。
53. 第１のエンティティと第２のエンティティの間の取引を、前記第２のエンティティに関連したＰＯＳ端末において管理するためのシステムであって、
    前記第１のエンティティに関連した口座情報保持体デバイスへ第１の変化識別子を割り当て、前記ＰＯＳ端末へ第２の変化識別子を割り当て、支払い認証手段へ第３の変化識別子を割り当てるように構成される認証手段を備え、
    前記口座情報保持体デバイスは、第１の暗号化された取引情報を生成するために、前記第１の変化識別子を用いて第１の取引情報を暗号化し、前記第１の暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記認証手段へ送信するように構成され、
    前記ＰＯＳ端末は、第２の暗号化された取引情報を生成するために、前記第２の変化識別子を用いて、第２の取引情報を暗号化し、前記第１の暗号化された取引情報を、少なくとも１つの通信リンクを介して、前記認証手段へ送信するように構成され、
    前記認証手段は、前記第１の取引情報を取得するために前記第１の変化識別子を用いて前記第１の暗号化された取引情報を暗号解除し、前記第２の取引情報を取得するために前記第２の変化識別子を用いて前記第２の暗号化された取引情報を暗号解除し、前記第１の取引情報および前記第２の取引情報に基づいて支払い要求を生成し、暗号化された支払い要求を生成するために前記第３の変化識別子を用いて前記支払い要求を暗号化し、前記暗号化された支払い要求を少なくとも１つの通信リンクを介して前記支払い認証手段へ送信し、前記第１の変化識別子および前記第２の変化識別子を使用済としてマーク付けするように構成される、
    システム。
54. 第１のエンティティと第２のエンティティとの間の取引を前記第２のエンティティに関連したＰＯＳ端末において実行する際に使用される口座情報保持体デバイスであって、
    第１の変化識別子を記憶するように構成されるメモリ・モジュールと、
    暗号化された取引情報を少なくとも１つの通信リンクを介して前記ＰＯＳ端末へ送るように、および前記第１の変化識別子を少なくとも１つの通信リンクを介して認証手段から受け取るように構成される入力／出力モジュールと、
    暗号化された取引情報を生成するために、前記第１の変化識別子を用いて前記取引情報を暗号化するように構成されるプロセッサと
    を備える口座情報保持体デバイス。
55. 第１のエンティティと第２のエンティティとの間の取引を実行する際に使用されるＰＯＳ端末であって、前記ＰＯＳ端末は前記第２のエンティティと関連しており、
    第２の変化識別子を記憶するように構成されるメモリ・モジュールと、
    暗号化された第１の取引情報を、少なくとも１つの通信リンクを介して、前記第１のエンティティに関連した口座情報保持体デバイスから受け取り、暗号化された前記第１の取引情報および暗号化された前記第２の取引情報を少なくとも１つの通信リンクを介して認証手段へ送り、前記第２の変化識別子を少なくとも１つの通信リンクを介して認証手段から受け取るように構成される入力／出力モジュールと、
    第２の暗号化された取引情報を生成するために、前記第２の変化識別子を用いて取引情報を暗号化するように構成されるプロセッサと
    を備えるＰＯＳ端末。
56. 第１のエンティティと第２のエンティティとの間の取引を前記第２のエンティティに関連したＰＯＳ端末において管理するための認証手段であって、
    前記第１のエンティティに関連した口座情報保持体デバイスへ割り当てられる第１の変化識別子を記憶し、前記ＰＯＳ端末へ割り当てられる第２の変化識別子を記憶し、支払い認証手段へ割り当てられる第３の変化識別子を記憶するように構成されるメモリ・モジュールと、
    前記第１の変化識別子を少なくとも１つの通信リンクを介して前記口座情報保持体デバイスへ送信し、前記第２の変化識別子を少なくとも１つの通信リンクを介して前記ＰＯＳ端末へ送信し、前記第３の変化識別子を前記ＰＯＳ端末へ送信し、暗号化された第１の取引情報および暗号化された第２の取引情報を少なくとも１つの通信リンクを介して前記ＰＯＳ端末から受け取るように構成される入力／出力モジュールと、
    前記第１の取引情報を取得するために、前記第１の変化識別子を用いて、暗号化された前記第１の取引情報を暗号解除し、前記第２の取引情報を取得するために、前記第２の変化識別子を用いて、暗号化された前記第２の取引情報を暗号解除し、前記第１の取引情報および前記第２の取引情報に基づいて支払い要求を生成し、暗号化された前記支払い要求を生成するために前記第３の変化識別子を用いて前記支払い要求を暗号化し、前記第１の変化識別子および前記第２の変化識別子を使用済としてマーク付けするように構成されるプロセッサと
    を備え、
    前記入力／出力モジュールは、前記暗号化された支払い要求を前記支払い認証手段へ送信するように構成される、
    認証手段。

Images