(57)【要約】アカウントホルダ（２０２）に対する既存のアカウント（２１４）のデータベースを管理する方法では、各アカウントホルダ（２０２）は、複数のアカウントを有する単一のデバイスの使用のための一以上のアカウントオーソリティ（２１２）を備えた複数のアカウントを有し、各アカウントホルダーの各アカウントは、そのアカウントホルダの公開−秘密鍵の対の公開鍵に関連付けられる。特定のアカウントホルダの全アカウントに属する情報の記録は、中央鍵オーソリティによって中央位置に維持される。そのアカウントのための情報は、そのアカウントホルダの公開鍵を含む。中央鍵オーソリティは、アカウントホルダに対する記録から、そのアカウントホルダーが新しいアカウントを設置することを望む新しいアカウントオーソリティへ情報を伝送する。【選択図】図２
2004506380.tif 000002
【特許請求の範囲】
【請求項１】
アカウントに関する通信媒体を通じて電子通信する方法であって、
（ａ）第１のアカウントのために、
（ｉ）第１の固有の識別子に基いて情報が取り出し可能であるようにアカウントデータベースの該第１のアカウントに関連する該情報を維持する工程と、
（ｉｉ）公開−秘密鍵の対のうちの公開鍵を該第１の固有の識別子と関連させる工程と、
（ｉｉｉ）該公開−秘密鍵の対のうちの秘密鍵を用いて、電子メッセージに対するデジタル署名を生成する工程であって、該電子メッセージは、命令および該第１の固有の識別子を含む、生成する工程と、
（ｉＶ）該第１の固有の識別子によって識別された該情報に関連させた該公開鍵を用いて該電子メッセージを認証する工程と、
（Ｖ）該電子メッセージの該成功した認証に基づいて、該第１の固有の識別子によって識別された該情報によって表された該第１のアカウントに関する命令を実行する工程と
を包含し、
（ｂ）第２のアカウントのために、
（ｉ）第２の固有の識別子に基いて情報が取り出し可能であるようにアカウントデータベースの該第２のアカウントに関連する該情報を維持する工程と、
（ｉｉ）該第１のアカウントに関連させた同じ公開鍵を該第２の固有の識別子に関連させる工程と、
（ｉｉｉ）該公開−秘密鍵の対のうちの秘密鍵を用いて、電子メッセージに対するデジタル署名を生成する工程であって、該電子メッセージは、命令および該第２の固有の識別子を含む、生成する工程と、
（ｉＶ）該第２の固有の識別子によって識別された該情報に関連させた該公開鍵を用いて該電子メッセージを認証する工程と、
（Ｖ）該電子メッセージの該成功した認証に基づいて、該第２の固有の識別子によって識別された該情報によって表された該第２のアカウントに関する命令を実行する工程と
を包含する方法。
【請求項２】
アカウントデータベースの各々は、アカウントオーソリティによって維持される、請求項１に記載の方法。
【請求項３】
アカウントデータベースの各々は、異なるアカウントオーソリティによって維持される、請求項２に記載の方法。
【請求項４】
両方のアカウントデータベースは、前記同じアカウントオーソリティによって維持される、請求項２に記載の方法。
【請求項５】
電子メッセージに対するデジタル署名を前記生成する工程の各々は、アカウントホルダーのデバイスによって実施され、該デバイスは、前記公開−秘密鍵の対のうちの前記秘密鍵を含む、請求項２に記載の方法。
【請求項６】
前記アカウントホルダーは、電子通信（「ＥＣ」）のそれぞれの電子メッセージおよびデジタル署名をアカウントオーソリティに送ることによって該アカウントと通信する、請求項５に記載の方法。
【請求項７】
前記アカウントホルダーは、それぞれのＥＣをアカウントオーソリティに直接送る、請求項６に記載の方法。
【請求項８】
前記デバイスは、固有の識別子の各々を含み、該デバイスの前記公開鍵は、該固有の識別子の各々に関連させる、請求項７に記載の方法。
【請求項９】
前記デバイスは、デバイスのインタフェースを介して前記通信媒体と通信する、請求項６に記載の方法。
【請求項１０】
前記デバイスのインタフェースは、固有の識別子の各々と、アカウントオーソリティの各々のアイデンティティーとを含み、該デバイスの前記公開鍵は、該アカウントオーソリティの各々のアイデンティティーに関連させる、請求項９に記載の方法。
【請求項１１】
前記デバイスは、前記アカウントオーソリティのアイデンティティーをさらに含み、アカウントは、該アカウントオーソリティのアイデンティティーで維持される、請求項１０に記載の方法。
【請求項１２】
前記アカウントホルダーは、それぞれのＥＣを中間者に直接送り、該中間者は、前記電子メッセージおよびデジタル署名をアカウントオーソリティに通信する、請求項６に記載の方法。
【請求項１３】
アカウントに関する前記命令を前記実行する工程の各々は、アカウントオーソリティによって実施される、請求項１２に記載の方法。
【請求項１４】
さらなる命令が前記アカウントホルダーによって前記中間者に通信される、請求項１３に記載の方法。
【請求項１５】
前記中間者は、前記アカウントに関する前記命令の前記アカウントオーソリティによる成功した実行に基づく前記さらなる命令を実行する、請求項１４に記載の方法。
【請求項１６】
前記さらなる命令は、別のＥＣにおいて前記アカウントホルダーから前記中間者に送られる、請求項１４に記載の方法。
【請求項１７】
前記さらなる命令は、前記アカウントホルダーから前記中間者に送られた前記それぞれのＥＣに含まれる、請求項１４に記載の方法。
【請求項１８】
前記さらなる命令は、前記中間者によって、前記アカウントオーソリティに転送される前に前記それぞれのＥＣから取り除かれる、請求項１７に記載の方法。
【請求項１９】
前記命令を実行する工程は、前記電子メッセージの前記成功した認証に単に基づいて実施される、請求項１に記載の方法。
【請求項２０】
アカウントに関する命令の実行は、前記アカウントの残高と通信する工程を包含する、請求項１に記載の方法。
【請求項２１】
アカウントに関する命令の実行は、特定された額を前記アカウントの借方に記入する工程を包含する、請求項１に記載の方法。
【請求項２２】
アカウントに関する命令の実行は、特定された額を前記アカウントの貸方に記入する工程を包含する、請求項１に記載の方法。
【請求項２３】
アカウントに関する命令の実行は、資金を別のアカウントに転送する工程を包含する、請求項１に記載の方法。
【請求項２４】
アカウントに関する命令の実行は、データベースへのアクセスを許可する工程を包含する、請求項１に記載の方法。
【請求項２５】
アカウントに関する命令の実行は、部屋、ビルディング、駐車場およびウェブサイト等の物理的な場所へのアクセスを許可する工程を包含する、請求項１に記載の方法。
【請求項２６】
アカウントに関する命令の実行は、ペイパービュー、音楽ダウンロードおよびウェブブロードキャスト等のデータ伝送へのアクセスを許可する工程を包含する、請求項１に記載の方法。
【請求項２７】
アカウントに関する命令の実行は、商品を提供する工程を包含する、請求項１に記載の方法。
【請求項２８】
アカウントに関する命令の実行は、サービスを提供する工程を包含する、請求項１に記載の方法。
【請求項２９】
アカウントに関する命令の実行は、前記アカウントから金銭を支払う工程を包含する、請求項１に記載の方法。
【請求項３０】
アカウントに関する命令の実行は、前記アカウントから金額のうちのいくらかを転送する工程を包含する、請求項１に記載の方法。
【請求項３１】
アカウントに関する命令の実行は、前記アカウントからセキュリティを転送する工程を包含する、請求項１に記載の方法。
【請求項３２】
アカウントに関する命令の実行は、前記アカウントへの請求金額を認可する工程を包含する、請求項１に記載の方法。
【請求項３３】
アカウントに関する命令の実行は、前記アカウントからの情報を転送する工程を包含する、請求項１に記載の方法。
【請求項３４】
アカウントオーソリティによって維持されたアカウントに関する命令を実行するための該アカウントオーソリティを要求する方法であって、
（ａ）第１のアカウントのために、
（ｉ）電子メッセージを構成する工程であって、
（Ａ）該第１のアカウントに関する命令と、
（Ｂ）第１の固有の識別子であって、第１のアカウントオーソリティは、該第１のアカウントオーソリティによって維持されたアカウントから該第１のアカウントを該第１の固有の識別子によって識別する、第１の固有の識別子と
を含む、電子メッセージを構成する工程と、
（ｉｉ）公開−秘密鍵の対のうちの秘密鍵を用いて電子メッセージにデジタル署名する工程であって、該公開鍵は、該第１のアカウントオーソリティによって該第１のアカウントに関連させる、デジタル署名する工程と、
（ｉｉｉ）通信媒体を通じて該第１のアカウントオーソリティに該電子メッセージおよびデジタル署名を送る工程と
を包含し、
（ｂ）第２のアカウントのために、
（ｉ）電子メッセージを構成する工程であって、
（Ａ）該第２のアカウントに関する命令と、
（Ｂ）第２の固有の識別子であって、第２のアカウントオーソリティは、該第２のアカウントオーソリティによって維持されたアカウントから該第２のアカウントを該第２の固有の識別子によって識別する、第２の固有の識別子と
を含む、電子メッセージを構成する工程と、
（ｉｉ）該公開−秘密鍵の対のうちの同じ秘密鍵を用いて電子メッセージにデジタル署名する工程であって、該同じ公開鍵は、該第２のアカウントオーソリティによって該第２のアカウントに関連させる、デジタル署名する工程と、
（ｉｉｉ）通信媒体を通じて該第２のアカウントオーソリティに該電子メッセージおよびデジタル署名を送る工程と
を包含する方法。
【請求項３５】
データベースのアカウントを管理する方法であって、
（ａ）該データベースの該アカウントの各々に関する情報を記録する工程と、
（ｂ）それぞれのアカウントに関する情報が該アカウントの固有の識別子に基づいて該データベースから取り出し可能なように、それぞれの固有の識別子を各アカウントに割り当てる工程と、
（ｃ）公開−秘密鍵の対のうちの該同じ公開鍵を複数の固有の識別子に関連させる工程と
包含する、データベースのアカウントを管理する方法。
【請求項３６】
アカウントに関する通信媒体を通じて電子通信する際に用いられるデバイスであって、
（ａ）公開−秘密鍵の対のうちの秘密鍵と、
（ｂ）複数の固有のアカウントの識別子であって、該固有のアカウントの識別子の各々は、アカウントオーソリティによって維持されたアカウントを識別し、該公開−秘密鍵の対のうちの該公開鍵は、該アカウントオーソリティに関連させる、複数の固有のアカウントの識別子と
を含むデバイス。
【請求項３７】
前記識別されたアカウントの各々を維持する前記アカウントオーソリティのアイデンティティーであって、これにより、前記デバイスによってデジタル署名される電子メッセージは、前記通信が関連付けられる該アカウントを維持する適切なアカウントオーソリティに関連し得る、前記アカウントオーソリティのアイデンティティーをさらに含む、請求項３６に記載のデバイス。
【請求項３８】
前記識別されたアカウントの各々を維持する前記アカウントオーソリティのアイデンティティーは、前記それぞれの固有のアカウントの識別子で判定可能であり、これにより、前記デバイスによってデジタル署名された電子メッセージは、前記通信が関連付けられる該アカウントを維持する適切なアカウントオーソリティに関連し得る、請求項３６に記載のデバイス。
【請求項３９】
前記電子メッセージの前記固有の識別子に関連する前記公開鍵をアカウントデータベースから取り出す工程をさらに包含する、請求項１または３４に記載の方法。
【請求項４０】
前記電子メッセージの拒絶の通知を通信する工程をさらに包含する、請求項１または３４に記載の方法。
【請求項４１】
メッセージの前記固有の識別子に関連する前記公開鍵は、該メッセージに含まれる、請求項１または３４に記載の方法。
【請求項４２】
固有の識別子は、関連する公開鍵を含む、請求項１、３４、３５または３６に記載の方法。
【請求項４３】
固有の識別子は、アカウントのアカウント番号を含む、請求項１、３４、３５または３６に記載の方法。
【請求項４４】
前記情報は、アカウント番号を含む、請求項１または３５に記載の方法。
【請求項４５】
前記情報は、アカウントに対する現在の残高を含む、請求項１または３５に記載の方法。
【請求項４６】
前記情報は、アカウントのための利用可能な貸金を含む、請求項１または３５に記載の方法。
【請求項４７】
前記情報は、関連するアカウントのリストを含む、請求項１または３５に記載の方法。
【請求項４８】
前記デジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスの外部で前記電子メッセージを構成する工程をさらに包含する、請求項１または３４に記載の方法。
【請求項４９】
前記デバイスの外部で前記電子メッセージに対するハッシュ値を計算する工程をさらに包含する、請求項４８に記載の方法。
【請求項５０】
前記デジタル署名の生成のために、前記電子メッセージを前記デバイス内に入力する工程をさらに包含する、請求項４８に記載の方法。
【請求項５１】
電子署名を生成するために用いられる前記秘密鍵を所有するデバイス内に電子メッセージを構成する工程をさらに包含する、請求項１または３４に記載の方法。
【請求項５２】
前記デバイス内の前記電子メッセージのためのハッシュ値を計算する工程をさらに包含する、請求項５１に記載の方法。
【請求項５３】
前記情報は、前記アカウントホルダーの名前を含む、請求項１または３５に記載の方法。
【請求項５４】
前記情報は、前記アカウントホルダーのアドレスを含む、請求項１または３５に記載の方法。
【請求項５５】
前記情報は、前記アカウントホルダーの社会保証番号を含む、請求項１または３５に記載の方法。
【請求項５６】
前記情報は、前記アカウントホルダーの税識別番号を含む、請求項１または３５に記載の方法。
【請求項５７】
前記情報は、電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスに関連付けられる、請求項１または３５に記載の方法。
【請求項５８】
前記情報は、電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスのセキュリティの特徴を含む、請求項１または３５に記載の方法。
【請求項５９】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、パーソナルコンピュータを含む、請求項１または３４に記載の方法。
【請求項６０】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、携帯電話を含む、請求項１または３４に記載の方法。
【請求項６１】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、ＰＤＡを含む、請求項１または３４に記載の方法。
【請求項６２】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、電子鍵を含む、請求項１または３４に記載の方法。
【請求項６３】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、ドングルを含む、請求項１または３４に記載の方法。
【請求項６４】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、皮下インプラントを含む、請求項１または３４に記載の方法。
【請求項６５】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、セキュリティなチップを含む、請求項１または３４に記載の方法。
【請求項６６】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、宝石類を含む、請求項１または３４に記載の方法。
【請求項６７】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、ＩＣカードを含む、請求項１または３４に記載の方法。
【請求項６８】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、クレジットカードを含む、請求項１または３４に記載の方法。
【請求項６９】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、デビットカードを含む、請求項１または３４に記載の方法。
【請求項７０】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、保証カードを含む、請求項１または３４に記載の方法。
【請求項７１】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、ＩＤバッヂを含む、請求項１または３４に記載の方法。
【請求項７２】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、デバイスのインタフェースとの物理的な接触を通して前記デジタル署名を伝送する、請求項１または３４に記載の方法。
【請求項７３】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、前記デバイスのインタフェースにプラグインする、請求項１または３４に記載の方法。
【請求項７４】
前記デバイスは、前記デバイスのインタフェースを通ってスワイプされる、請求項７３に記載の方法。
【請求項７５】
電子メッセージのデジタル署名を生成するために用いられる前記秘密鍵を所有するデバイスは、デバイスのインタフェースとの物理的な接触がなく、該デジタル署名を該デバイスのインタフェースに伝送する、請求項１または３４に記載の方法。
【請求項７６】
前記デバイスは、ワイヤレス通信を介して前記デジタル署名を伝送する、請求項７５に記載の方法。
【請求項７７】
前記デバイスは、ＲＦ伝送を介して前記デジタル署名を伝送する、請求項７５に記載の方法。
【請求項７８】
前記通信媒体は、オープンであり、かつ、安全ではない、請求項１、３４または３６に記載の方法。
【請求項７９】
前記通信媒体は、インターネットを含む、請求項１、３４または３６に記載の方法。
【請求項８０】
前記電子メッセージは、暗号化されない、請求項１、３４または３６に記載の方法。
【請求項８１】
前記電子メッセージは、暗号化される、請求項１、３４または３６に記載の方法。
【請求項８２】
前記電子メッセージは、前記アカウントの所有者に関する非個人識別情報を含む、請求項１、３４または３６に記載の方法。
【請求項８３】
アカウントの固有の識別子以外の非個人識別情報を含む、請求項１、３４または３６に記載の方法。
【請求項８４】
前記公開鍵を固有の識別子に関連させる工程は、該固有の識別子に基づいた取り出し可能な前記情報を有する該公開鍵を記録する工程を包含する、請求項１または３５に記載の方法。
【請求項８５】
前記公開鍵を固有の識別子に関連させる工程は、該公開鍵を有する該固有の識別子に基づいて取り出し可能な前記情報にインデックスを付ける工程を包含する、請求項１または３５に記載の方法。
【請求項８６】
複数のアカウントホルダーのために中央鍵オーソリティのデータベースを管理する方法であって、アカウントホルダーの各々は、該アカウントホルダーの公開−秘密鍵の対のうちの公開鍵に関連させた少なくとも一つのアカウントを有し、アカウントホルダーの各々のために該アカウントホルダーのうちの該公開鍵に関連付けられた該アカウントホルダーの該アカウントに関する情報の記録を管理する工程を包含する、方法。
【請求項８７】
アカウントホルダーの前記アカウントに関する前記情報は、該アカウントに関連する前記公開鍵を含む、請求項８６に記載の方法。
【請求項８８】
アカウントホルダーのアカウントの各々は、該アカウントホルダーの前記同じ公開鍵に関連する、請求項８６に記載の方法。
【請求項８９】
前記アカウントホルダーの前記アカウントに関する前記情報は、該アカウントホルダーの該アカウントに関連する単一の公開鍵を含む、請求項８６に記載の方法。
【請求項９０】
アカウントホルダーの前記アカウントに関する前記情報は、アカウントの各々の前記アカウントオーソリティの前記アイデンティティーを含む、請求項８６に記載の方法。
【請求項９１】
アカウントホルダーの前記アカウントに関する前記情報は、アカウントの各々の固有の識別子を含み、アカウントの各々の前記アカウントオーソリティによって維持された記録は、該アカウントの各々の固有の識別子によって、該アカウントオーソリティのアカウントデータベースから取り出し可能である、請求項８６に記載の方法。
【請求項９２】
アカウントホルダーの前記アカウントに関する前記情報は、アカウントの各々の属性を含む、請求項８６に記載の方法。
【請求項９３】
アカウントホルダーの前記アカウントに関する前記情報は、該アカウントホルダーの個人情報を含む、請求項８６に記載の方法。
【請求項９４】
アカウントホルダーの前記アカウントに関する前記情報は、該アカウントホルダーのデバイスに関する情報を含み、該アカウントホルダーの公開−秘密鍵の対のうちの秘密鍵は、該アカウントホルダーの該デバイスに保たれる、請求項９３に記載の方法。
【請求項９５】
前記デバイスに関する前記情報は、前記デバイスのセキュリティ機能を含む、請求項９４に記載の方法。
【請求項９６】
該アカウントホルダーのアカウントのアカウントオーソリティから受信されたアカウントホルダーの前記記録にある情報を記録する工程をさらに包含する、請求項８６に記載の方法。
【請求項９７】
前記アカウントホルダーのデバイスの製造者から受信されたアカウントホルダーの前記記録にある情報を記録する工程であって、該アカウントホルダーの公開−秘密鍵の対のうちの秘密鍵は、該アカウントホルダーのデバイスに保たれる、工程をさらに包含する、請求項８６に記載の方法。
【請求項９８】
前記アカウントホルダーのトークンの配給業者から受信されたアカウントホルダーの前記記録にある情報を記録する工程であって、該アカウントホルダーの公開−秘密鍵の対のうちの秘密鍵は、該アカウントホルダーのデバイスに保たれる、工程をさらに包含する、請求項８６に記載の方法。
【請求項９９】
アカウントホルダーの各々の前記公開鍵によって中央鍵オーソリティデータベースにある前記アカウントホルダーの前記記録にインデックスを付ける工程をさらに包含する、請求項８６に記載の方法。
【請求項１００】
固有の識別子によって中央鍵オーソリティデータベースにある前記アカウントホルダーの前記記録にインデックスを付ける工程をさらに包含する、請求項８６に記載の方法。
【請求項１０１】
アカウントホルダーに関連する一つの公開鍵が紛失した、盗難された、または、危ういことを特定のアカウントホルダーのために該アカウントホルダーのアカウントの各アカウントオーソリティに通告する工程をさらに包含する、請求項８６に記載の方法。
【請求項１０２】
前記アカウントホルダの別の公開−秘密鍵の対のうちの公開鍵を該アカウントソリティによって維持された該アカウントホルダーの前記アカウントに新しく関連するべき通知されたアカウントオーソリティに通信する工程をさらに包含する、請求項１０１に記載の方法。
【請求項１０３】
特定のアカウントホルダーのために、中央鍵オーソリティデータベースに維持された情報を新しいアカウントオーソリティに通信する工程であって、該アカウントホルダーは、該新しいアカウントオーソリティによってアカウントを確立することを所望し、該情報は、該新しいアカウントを有する該新しいアカウントオーソリティによって関連するべき該アカウントホルダーの公開鍵を含む、通信する工程をさらに包含する、請求項１に記載の方法。
【請求項１０４】
前記アカウントの所有者に関する非個人情報は、前記新しいアカウントオーソリティに通信される、請求項１０３に記載の方法。
【請求項１０５】
アカウントホルダーの存在するアカウントオーソリティからの情報を受信し、かつ、前記中央鍵アカウントデータベースにある該アカウントホルダーのための前記情報の記録を維持する工程であって、該情報は、該アカウントソリティの前記アカウントに関連する該アカウントホルダーの公開鍵を含む、受信し、かつ、維持する工程をさらに包含する、請求項８６に記載の方法。
【請求項１０６】
前記情報は、アカウント番号を含む、請求項８６に記載の方法。
【請求項１０７】
前記情報は、関連するアカウントのリストを含む、請求項８６に記載の方法。
【請求項１０８】
前記情報は、アカウントホルダーの名前を含む、請求項８６に記載の方法。
【請求項１０９】
前記情報は、アカウントホルダーのアドレスを含む、請求項８６に記載の方法。
【請求項１１０】
前記情報は、アカウントホルダーの社会保証番号を含む、請求項８６に記載の方法。
【請求項１１１】
前記情報は、アカウントホルダーの税識別番号を含む、請求項８６に記載の方法。
【請求項１１２】
前記情報は、電子メッセージのデジタル署名を生成するために用いられる前記アカウントホルダーの秘密鍵を所有するデバイスに関連付けられる、請求項８６に記載の方法。
【請求項１１３】
前記情報は、前記デバイスのセキュリティ機能を含む、請求項８６に記載の方法。
【請求項１１４】
中央鍵オーソリティ（ＣＫＡ）データベースを維持する方法であって、ユーザのアカウント情報を含む該ＣＫＡデータベースは、
（ａ）デジタル署名を生成するユーザデバイスの公開鍵と、
（ｂ）第三者のアカウント識別子であって、該第三者のアカウント各々は、該第三者に対して、該第三者で維持され、かつ、該第三者によって該ユーザの公開鍵に関連している該ユーザのアカウントを識別する、第三者のアカウント識別子と　を含む、中央鍵オーソリティ（ＣＫＡ）データベースを維持する方法。
【請求項１１５】
前記公開鍵とリンクされた前記情報は、前記デバイスのセキュリティ機能を含む、請求項１１４に記載の方法。
【請求項１１６】
前記公開鍵でリンクされた前記情報は、前記デバイスの製造履歴を含む、請求項１１４に記載の方法。
【請求項１１７】
前記公開鍵および該公開鍵でリンクされた前記情報は、安全なエンティティから得られる、請求項１１４に記載の方法。
【請求項１１８】
ユーザの各々のためにＣＫＡデータベースに維持された前記アカウント情報は、第三者の各々の前記アイデンティティーを含み、アカウントは、該第三者の各々の該アイデンティティーで維持され、該第三者のアカウント識別子のうちの一つによって識別される、請求項１１４に記載の方法。
【請求項１１９】
前記ユーザの前記アカウント情報は、固有のＣＫＡアカウント識別子によってＣＫＡデータベースにインデックスを付けられ、これにより、ユーザのための前記アカウント情報は、前記アカウントの識別子に基づいて前記ＣＫＡデータベースから取り出し可能である、請求項１１４に記載の方法。
【請求項１２０】
前記公開鍵は、前記ＣＫＡアカウント識別子である、請求項１１９に記載の方法。
【請求項１２１】
ユーザの各々のために前記ＣＫＡデータベースに維持される前記アカウント情報は、ユーザに特定の情報をさらに含む、請求項１１４に記載の方法。
【請求項１２２】
前記ユーザに特定の情報は、検証される、請求項１２１に記載の方法。
【請求項１２３】
ユーザアカウントの各々は、前記ユーザに特定の情報を検証する際に採用された技術の記録をさらに含む、請求項１２２に記載の方法。
【請求項１２４】
前記ユーザに特定の情報は、前記ユーザの名前およびアドレスを含む、請求項１２１に記載の方法。
【請求項１２５】
前記ユーザに特定の情報は、前記ユーザの年齢および性別を含む、請求項１２１に記載の方法。
【請求項１２６】
前記ユーザの前記公開鍵、および、該公開鍵を伴う情報を前記ＣＫＡデータベースから前記第三者へと通信することによってユーザのためにアカウントを確立する工程をさらに包含する、請求項１２１に記載の方法。
【請求項１２７】
前記ユーザの前記公開鍵、および、前記公開鍵を伴う情報は、前記第三者の要求に基づいて、第三者に通信される、第三の請求項１２６に記載の方法。
【請求項１２８】
前記ユーザの新しい公開鍵を有する少なくとも二つの独立した第三者で維持されたユーザのＰｕｋリンクのアカウントを更新する工程であって、
（ａ）ＥＣを受信する工程であって、該ＥＣは、前記ＣＫＡアカウント識別子のうちの一つを含み、メッセージは、該新しい公開鍵および該新しい公開鍵のためのデジタル署名を含む、工程と、
（ｂ）該ＣＫＡアカウントの識別子によって、該ＣＫＡアカウントの識別子の成功した認証に基づいて、識別された該ＣＫＡデータベースにある該アカウントに関連する該公開鍵を用いて該ＥＣの該メッセージを認証する工程と、
（ｃ）ＥＣを該第三者の各々に送る工程であって、ＥＣの各々は、該ＣＫＡデータベースに維持され、かつ、該ＣＫＡアカウントの識別子によって識別された該アカウントに関連する該それぞれの第三者のための該新しい公開鍵および該第三者のアカウントの識別子を含む、工程と
をさらに包含する、請求項１２１に記載の方法。
【請求項１２９】
前記ユーザおよび第三のアカウントの識別子の前記新しい公開鍵にデジタル署名する工程をさらに包含する、請求項１２１に記載の方法。
【請求項１３０】
アカウントに関する通信媒体を通って電子通信するシステムであって、
（ａ）情報が固有の識別子によって取り出し可能なようにデータベースにある該アカウントに関する該情報を維持する工程であって、該情報は、公開−秘密鍵の対のうちの公開鍵を用いてデジタル署名を生成するデバイスのセキュリティ機能を含む、工程と、
（ｂ）該デバイスの該公開鍵を該データベースにある該固有の識別子に関連させる工程と、
（ｃ）疑わしいデバイスによって生成されたメッセージに対する該固有の識別子およびデジタル署名を含む電子通信を受信する工程と、
（ｄ）該固有に関連する該公開鍵を用いて該メッセージを認証する工程と、
（ｅ）該メッセージの成功した認証に基づいて、該本物のデバイスの該セキュリティ機能であるように、該固有の識別子によって取り出し可能な該セキュリティ機能を識別する工程と、
（ｆ）前記生成されたデジタル署名が該本物のデバイスの該識別されたセキュリティ機能に基づいて不正に送られたリスクを読み取る工程と
を包含する、アカウントに関する通信媒体を通って電子通信するシステム。
【請求項１３１】
前記記録を維持する工程は、アカウントオーソリティによって実施される、請求項１３０に記載の方法。
【請求項１３２】
前記記録を維持する工程は、中央鍵オーソリティによって実施される、請求項１３０に記載の方法。
【請求項１３３】
前記デバイスの前記セキュリティ機能を識別する工程は、アカウントオーソリティによって実施される、請求項１３０に記載の方法。
【請求項１３４】
前記デバイスの前記セキュリティ機能を識別する工程は、中央鍵オーソリティによって実施される、請求項１３０に記載の方法。
【請求項１３５】
前記固有の識別子は、前記関連する公開鍵を含む、請求項１３０に記載の方法。
【請求項１３６】
前記固有の識別子は、アカウント番号を含む、請求項１３０に記載の方法。
【請求項１３７】
前記通信媒体は、オープンであり、かつ、安全ではない、請求項１３０に記載の方法。
【請求項１３８】
前記通信媒体は、インターネットである、請求項１３０に記載の方法。
【請求項１３９】
前記デジタル署名が前記識別されたセキュリティ機能に基づいて不正に生成された前記リスクを読み取る工程をさらに包含する、請求項１３０に記載の方法。
【請求項１４０】
デジタル署名を生成するデバイスのセキュリティ機能の識別のためのデータベースを管理する方法であって、
（ａ）複数のデバイスの各々のためにデータベースに記録する工程であって、
（ｉ）該デバイスの公開−秘密鍵の対のうちの公開鍵と、
（ｉｉ）該デバイスのセキュリティ機能を含む情報であって、該セキュリティ機能は、該データベースにある該公開鍵に関連する、情報と
を含む、記録する工程と、
（ｂ）該データベースから電子メッセージの受信側へのセキュリティ機能を識別する工程であって、該デバイスのうちの特定のデバイスの該公開−秘密鍵の対のうちの秘密鍵を利用することによって、デジタル署名がセキュリティ機能のために生成される、識別する工程と
を包含する、データベースを管理する方法。
【請求項１４１】
前記生成されたデジタル署名が前記識別されたセキュリティの特徴に基づいて不正に生成されたリスクを読み取る工程をさらに包含する、請求項１４０に記載の方法。
【請求項１４２】
前記電子メッセージを認証するために用いられる前記公開鍵は、前記デジタル署名を伴って受信される、請求項１４０に記載の方法。
【請求項１４３】
前記メッセージの前記固有の識別子によって識別された記録に関連する前記公開鍵は、前記メッセージに含まれる、請求項１４０に記載の方法。
【請求項１４４】
前記固有の識別子によって識別された前記記録に関連する前記公開鍵を前記アカウントデータベースから受信する工程をさらに包含する、請求項１４０に記載の方法。
【請求項１４５】
前記情報は、アカウントホルダーの名前を含む、請求項１３０または１４０に記載の方法。
【請求項１４６】
前記情報は、アカウントホルダーのアドレスを含む、請求項１３０または１４０に記載の方法。
【請求項１４７】
前記情報は、アカウントホルダーの社会保障番号を含む、請求項１３０または１４０に記載の方法。
【請求項１４８】
前記情報は、アカウントホルダーの税識別番号を含む、請求項１３０または１４０に記載の方法。
【請求項１４９】
前記情報は、前記アカウントに対するアカウント番号を含む、請求項１３０または１４０に記載の方法。
【請求項１５０】
前記情報は、前記アカウントに対する現在の残高を含む、請求項１３０または１４０に記載の方法。
【請求項１５１】
前記情報は、前記アカウントに対する利用可能な貸金を含む、請求項１３０または１４０に記載の方法。
【請求項１５２】
前記情報は、関連するアカウントのリストを含む、請求項１３０または１４０に記載の方法。
【請求項１５３】
それぞれのデバイスに対する前記セキュリティの特徴は、デバイスの公開鍵に対する前記データベースにインデックスを付けられる、請求項１３０または１４０に記載の方法。
【請求項１５４】
それぞれのデバイスに対する前記セキュリティの特徴は、固有の識別子に対する前記データベースにおいてインデックスを付けられる、請求項１３０または１４０に記載の方法。
【請求項１５５】
受信されたＥＣを前記ユーザから前記第三者の各々に送る工程をさらに包含する、請求項１５４に記載の方法。
【発明の詳細な説明】
【０００１】
（１．関連出願への相互参照）
この特許出願は、米国における特許法（３５　Ｕ．Ｓ．Ｃ）１１９条のもとに、およびパリ国際条約のもとに、２０００年８月４日に出願された、Ｗｈｅｅｌｅｒらの米国仮特許出願シリアル番号６０／２２３，０７６号の出願日の利益に対して優先権を主張する。この出願は、本明細書において参考として援用される。この出願は、さらに、本明細書において、３つの国際特許出願および３つの米国特許出願のそれぞれを参考として援用する。これらは、Ａｎｎｅ　ａｎｄ　Ｌｙｎｎ　Ｗｈｅｅｌｅｒによって米国特許商標庁に同時に出願され、シリアル番号０９／９２３，１７９（名称「Ａｃｃｏｕｔ−Ｂａｓｅｄ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ（ＡＢＤＳ）Ｓｙｓｔｅｍ」）；シリアル番号ＰＣＴ／ＵＳ０１／４１５６２（名称「Ｅｎｔｉｔｙ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｉｎ　Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｂｙ　Ｐｒｏｖｉｄｉｎｇ　Ｖｅｒｉｆｉｃａｔｉｏｎ　Ｓｔａｔｕｓ　ｏｆ　Ｄｅｖｉｃｅ」）およびシリアル番号０９／９２３，０７５（名称「Ｍｏｄｉｆｙｉｎｇ　Ｍｅｓｓａｇｅ　Ｄａｔａ　ａｎｄ　Ｇｅｎｅｒａｔｉｎｇ　Ｒａｎｄｏｍ　Ｎｕｍｂｅｒ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ｗｉｔｈｉｎ　Ｃｏｍｐｕｔｅｒ　Ｃｈｉｐ」）（以下「ＶＳ　Ａｐｐｌｉｃａｔｉｏｎ」と総称する）；シリアル番号ＰＣＴ／ＵＳ０１／２４５７２（名称「Ｌｉｎｋｉｎｇ　Ｐｕｂｌｉｃ　Ｋｅｙ　ｏｆ　Ｄｅｖｉｃｅ　ｔｏ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｄｕｒｉｎｇ　Ｍａｎｕｆａｃｔｕｒｅ」）およびシリアル番号０９／９２３，２１３（名称「Ｍａｎｕｆａｃｔｕｒｉｎｇ　Ｕｎｉｑｕｅ　Ｄｅｖｉｃｅｓ　Ｔｈａｔ　Ｇｅｎｅｒａｔｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ」）；およびシリアル番号ＰＣＴ／ＵＳ０１／２４５６３（名称「Ｔｒｕｓｔｅｄ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ（ＴＡＤＳ）Ｓｙｓｔｅｍ」）を有する。
【０００２】
（ＩＩ．発明の分野）
本発明は、アカウントに関する電子通信がデジタルによって署名される、向上された通信システムに関する。
【０００３】
（ＩＩＩ．本発明の背景）
本明細書にて用いられるように、電子通信（「ＥＣ」）は、電子形態における任意の通信であると考えられている。ＥＣは、特に、インターネットおよびｅ−コマースの成長に伴い、今日の取引ビジネスの不可欠な部分になってきている。ＥＣは、例えば、情報または物理領域へのアクセスに対する要求、資金を移転するための銀行への指示等の金融取引、または執行された契約の配信等の法的活動を提示し得る。
【０００４】
近年になってずっと、デジタル署名が、さらに、ｅ−コマースの重要な部分になってきている。デジタル署名の作成は、一般に、（１）メッセージダイジェストの計算−例えば、ハッシュ値；（２）続くそのメッセージダイジェストの暗号化を含む。メッセージダイジェストは、一般に、非対称の暗号作成において用いられる公開−秘密鍵の対の秘密鍵を用いる電子デバイスによって暗号化される。結果として生じる暗号文そのものが、通常、デジタル署名を構成し、このデジタル署名は、通常、メッセージに追加されてＥＣを形成する。デジタル署名を始めることの第二の部分（秘密鍵を用いた暗号化）は、本明細書において、デジタル署名を「生成する（ｇｅｎｅｒａｔｉｎｇ）」と参照され、組み合わされた二つのステップ（すなわち、メッセージダイジェストを計算するステップおよび秘密鍵を用いて暗号化するステップ）は、デジタル署名を「作成する（ｏｒｉｇｉｎａｔｉｎｇ）」として参照される。さらに、デジタル署名の生成がメッセージダイジェストの暗号化として都合よく理解される一方で、デジタル署名を生成することは、さらに、メッセージダイジェストでなくメッセージを簡単に暗号化することを含み得ることが本明細書において考えられる。デジタル署名が重要であるのは、ＥＣにおけるメッセージにいかなる変化が生じても、メッセージおよびデジタル署名の分析から検出可能であるからである。これに関して、デジタル署名は、ＥＣに含まれるメッセージを「認証する」ために用いられる（以下、「メッセージ認証」と称する）。
【０００５】
例えば、メッセージダイジェストは、ハッシングアルゴリズム（ｈａｓｈｉｎｇ　ａｌｇｏｒｉｔｈｍ）（例えば、ＳＨＡ−１アルゴリズム）をメッセージに適用することによって計算され得る。このようなハッシングアルゴリズムは、結果として生じるハッシュ値によって、デバイス内またはデバイスの外部でのいずれかで適用され得、結果として、ハッシュ値が、デジタル署名を生成するためにデバイスに伝達される。この例においてメッセージ認証を行うために、ＥＣの受信側は、メッセージに適用されるハッシングアルゴリズムのアイデンティティおよびメッセージダイジェストを暗号化するために用いられる秘密鍵（「ＰｒＫ」）に対応する公開鍵（「ＰｕＫ」）の両方を知るかまたは取得できる必要がある。この知識を用いて、受信側は、適切なハッシングアルゴリズムをメッセージに適用して、ハッシュ値を計算し、そして、受信側は、公開鍵を用いてデジタル署名を復号化する。受信側によって計算されたハッシュ値が復号化されたデジタル署名のハッシュ値を等しくする場合、受信側は、ＥＣに含まれるメッセージのコンテンツが、必要に応じてハッシュ値を変化させる伝達において変更されないことを決定する。
【０００６】
メッセージ認証を行う場合、受信側は、さらに、ＥＣの送信者を認証し、これにより、受信側と同じ量だけ、ＥＣの送信者がメッセージを認証するために首尾よく用いられる公開鍵に対応する秘密鍵を所有していたことを確認する。これは、エンティティ認証の一つの種類であり、送信者が何を「持つ」かに基づいている（以下、「ファクタＡのエンティティ認証」と称する）。ファクタＡエンティティ認証は、ＥＣの受信側が、秘密鍵の所有者のアイデンティティに関して信頼された情報を有する場合に有用である。
【０００７】
この信頼された情報は、都合良く、信頼された第三者によって発行されたデジタル証明書に基づいて提供される。このデジタル証明書は、デジタル署名に付随し、秘密鍵所有者のアイデンティティ（または他の特質）を公開鍵に結合する。デジタル証明書（「デジタルＩＤ」としても知られている）は、公開鍵の所有者のアイデンティティ（または他の特質）を立証する第三者（一般に、「証明オーソリティ」と称される）による証拠書類（ｖｏｕｃｈｅｒ）である。本質的に、デジタル証明書は、運転免許、パスポート、メンバーシップカード、および識別の他のペーパーベースの形態に対する電子的対応物（ｅｌｅｃｔｒｏｎｉｃ　ｃｏｕｎｔｅｒｐａｒｔ）である。デジタル証明書そのものは、公開鍵および公開鍵の所有者のアイデンティティを含む電子メッセージを備える。デジタル証明書は、また、通常、公開鍵についての満了日、証明オーソリティの名称、デジタル証明書のシリアル番号、および証明オーソリティのデジタル署名を含む。満了日についての理由の一つは、アイデンティティ以外の特質が時間の経過により変化し得る見込みに起因する証明オーソリティに対する負担を制限するためである。デジタル証明書に対して最も広く受け入れられているフォーマットが、ＣＣＩＴＴ　Ｘ．５０９国際基準によって規定されている。このため、証明書は、Ｘ．５０９に従う任意のアプリケーションによって読み出され、または、書き込まれ得る。ＥＣに含まれるデジタル証明書に基づいて、受信側は、証明オーソリティの公開鍵を用いてデジタル証明書を認証し、これによって、おそらく、本明細書で説明される所有者のアイデンティティを確認することができる。
【０００８】
デジタル証明書がＥＣに含まれるシステムは、一般に「証明オーソリティデジタル署名」（ＣＡＤＳ）システムと称される「公開鍵基礎構造」（ＰＫＩ）を備える。買い手１０２とオンライン売り手１１０との間の電子取引のコンテキストにおけるＣＡＤＳシステムの特定のインプリメンテーション１００が図１に示されている。このシステムのもとで、例えば、コンピュータ１０４を用いている買い手１０２は、購買オーダーを電子メッセージの形態で作成する。買い手１０２は、支払いが売り手１１０になされることになる金融機関１１２の関連するアカウント情報をメッセージに含む。アカウント情報は、例えば、クレジットカード番号および満了日およびカード上の名前を含む。買い手のコンピュータ１０４に関するソフトウェアは、コンピュータ１０４内に保護された買い手１０２の秘密鍵を用いてメッセージに対するデジタル署名を作成する。ソフトウェアは、さらに、証明オーソリティ１０６ａによって発行されたデジタル証明書をコンピュータ１０４上に維持する。メッセージ、デジタル署名、およびデジタル証明書は、次いで、ＥＣに結合され、ＥＣは、インターネット１０８を介して売り手１１０に通信される。
【０００９】
受信の際、売り手１１０は、デジタル証明書における公開鍵を用いてメッセージを認証する。成功した場合、売り手１１０は、次いで、証明オーソリティ１０６ａの公開鍵を用いてデジタル証明書を認証する。デジタル証明書の成功した認証は、買い手、すなわちＥＣの送信者がデジタル証明書において識別された所有者であることに売り手１１０を満足させ得る。売り手１１０がそのように満足した場合、売り手１１０は、アカウントからの売り手１１０への支払いの許可のためにアカウント情報を関連の金融機関１１２に提示する。金融機関１１２からの支払いの許可についての受信の際、売り手１１０は、買い手１０２の購買オーダーを満たす。さらに、購買オーダーの許可（または拒絶）の確認が、好適には、売り手１１０から買い手１０２に送られる。
【００１０】
不幸にも、ＣＡＤＳシステムが、別の方法で事前に存在する関係を互いに有し得ない２者が互いに、他方のアイデンティティを知っているという確信を持って通信できる間、ＣＡＤＳシステムは、欠点を有する。例えば、デジタル証明書は、通常、満了日とともに発行され、満了されたデジタル証明書は、概して、産業において認識されない。さらに、秘密鍵が紛失または盗難された場合、秘密鍵の所有者は、所有者のデジタル証明書取り消すために、証明オーソリティに通知する必要がある。しかしながら、デジタル証明書を有するＥＣの受信側は、受信側が証明オーソリティによって公開された証明書取り消しリスト（ＣＲＬ）に対してデジタル証明書のシリアル番号を相互参照する場合、デジタル証明書の取消しを知るだけである。ＣＡＤＳシステムに対する別の欠点は、デジタル証明書それ自体が、それを発行する特定のオーソリティにのみ良好であり、しばしば、複数のデジタル証明書を（すなわち、証明オーソリティ１０６ａ、１０６ｂ〜１０６ｎ）から取得して、受け入れられたまたは行動された取引または通信のために買い手１０４と売り手１１０と間の信頼の十分な「鎖」または「ネットワーク」を形成する必要があることである。さらに、全体のＣＡＤＳシステムが、デジタル証明書を発行する証明オーソリティの秘密鍵のセキュリティに依存しており、もし、漏洩すると、ＣＡＤＳシステムが崩壊する。
【００１１】
上記に説明されたオンライン購買の例等のアカウントに関するＥＣのコンテクストにおいて、ＣＡＤＳシステムの別の欠点は、インターネット１０８等の不確かな通信媒体を介して送られた場合にアカウント情報が暗号化されるか別の方法で保護される必要があることである。上記例において、アカウント情報の通信上で盗み聞きするハッカーは、特に、全ての売り手が購買オーダーを満たすためにデジタル署名およびデジタル証明を要求するわけではないので、買い手のアカウントに不正な料金を形成するのに十分な情報を取得し得る。さらに、金融機関は、買い手のデジタル証明書が、売り手による支払い要求を許可するのに先行する状態として提示される要求を標準化していない。その代わりに、実際に売り手への支払いに影響するオーソリティを有するかどうかを買い手が決定する場合、金融機関は、アカウント情報が紛失または盗難されたことを報告されたかどうかに関係なく、売り手によって提供される個人のアカウント情報を頼みにする。さらに、デジタル証明書は、重要なプライバシー問題を引き起こす。
【００１２】
したがって、デジタル署名を用いる通信の向上されたシステムに対する必要性が、特に、ＥＣが、デジタル署名する個人（またはデバイス）が活動するためのオーソリティを有するアカウントに属する場合に存在する。
【００１３】
（ＩＶ．発明の簡単な要旨）
簡単に要約すると、アカウントに関する通信媒体を介して電子通信する方法は、分離した第三者によって維持された二つの分離したアカウントのそれぞれに対して、アカウントに属する情報が固有の識別子に基づいて検索可能であるようにその情報をアカウントデータベース内に維持するステップと、公開−秘密鍵の対の公開鍵を固有の識別子に関係させるステップと、公開−秘密鍵の対の秘密鍵を用いて電子メッセージについてのデジタル署名を生成するステップであって、該電子メッセージは、命令を含む、ステップと、固有の識別子によって識別された情報に関係した公開鍵を用いて電子メッセージを認証するステップと、電子メッセージの成功した認証の際に、固有の識別子によって識別された情報によって表されるアカウントについての命令を実行するステップとを包含する。
【００１４】
本発明は、さらに、中央鍵オーソリティ（Ｃｅｎｔｒａｌ　Ｋｅｙ　Ａｕｔｈｏｒｉｔｙ）（ＣＫＡ）データベースを維持する方法を含む。ＣＫＡデータベースは、デジタル署名を生成するユーザデバイスの公開鍵等のユーザのアカウント情報、およびそれぞれが第三者に対して第三者で維持され、第三者によってユーザの公開鍵に関連付けられるユーザのアカウントを識別する第三者のアカウント識別子を含む。
【００１５】
本発明は、さらに、デジタル署名を生成するデバイスのセキュリティ機能の識別のためのデータベースを管理する方法を包含し、複数のデバイスのそれぞれに対してデバイスの一対の公開秘密鍵の公開鍵およびデバイスのセキュリティ機能を含む情報をデータベース内に記録するステップであって、該セキュリティ機能は、データベース内の公開鍵に関連付けられる、ステップと、セキュリティ機能をデータベースから、電子メッセージの受信側までのセキュリティ機能を識別するステップであって、電子メッセージは、デジタル署名がデバイスうちの特定の一つの公開−秘密鍵の対の秘密鍵を用いて開始される、ステップであって、該セキュリティ機能は、特定のデバイス用である、ステップとを包含する。
【００１６】
（Ｖ．図面の簡単な説明）
本発明のこれらの局面のさらなる機能および利点が、以下の図面とともに採られた好適な方法の詳細な説明から明らかになる。ここで、同一の参照は、同一の要素を示す。
【００１７】
（ＶＩ．好適な実施形態の詳細な説明）
予備的事項として、本発明のデバイス、システム、および方法の以下の詳細な説明を考慮して、本発明が幅広い利用および用途が可能であることが当業者によって即座に理解される。本明細書で記載されたもの以外の本発明の多くの実施形態および適応、および多くの変更、改変、および均等な構成が、本発明の本質または範囲から逸脱することなく、本発明および以下の詳細な説明からまたは本発明および以下の詳細な説明によって道理に合うように提示されることが明らかである。したがって、本発明は、本明細書において、好適な実施形態に関連して詳細に記載されるが、この詳細な説明は、本発明の例証および例示であるにすぎず、単に、本発明の十分な、且つ、実施可能な開示を提供する目的のためになされていることが理解されるべきである。本明細書において説明される詳細な説明は、本発明制限するようにまたは他の方法で本発明の任意の他の実施形態、適応、変更、改変および均等な構成を除外するように意図されず、また、解釈されず、本発明は、本明細書に添付された請求の範囲およびその均等物によってのみ制限される。
【００１８】
当業者は、本明細書において記載され主張された種々のプロセスのステップの配列（単数または複数）および／または経時的な順序は、発明者によって本発明を実行するために企図される最良のモードであるべき発明者によって考えられたものであること理解し評価する。さらに、種々のプロセスのステップが、いくつかの場合において、好適な配列または経時的な順序であるように示され、且つ、記載されるが、このようなプロセスのステップは、一つのステップまたは複数のステップが、特定の意図された結果を達成するために特定の配列または順序において実行されるべきであるという特定の指示がなければ、任意の特定の配列または順序において実行されるように制限されないことが理解されるべきである。大抵の場合、このようなプロセスのステップは、本発明の範囲内にあり、種々の異なる配列および順序において実行され得る。
【００１９】
したがって、本発明の多くが、本明細書において、コンピュータ、ネットワーク、集積回路、コンピュータチップ、およびデバイスに関して詳細に記載されるが、特定のソフトウェアまたは論理回路が意図されず、また、本発明の実施において用いられることが要求されない。実際、特定のビジネス用途において本発明を実行する場合に適切なコンピュータ、ネットワーク、集積回路、コンピュータチップ、およびデバイスを選択することは、日常業務の問題である。
【００２０】
本発明は、アカウントデータベース記録内の他の情報への非対称暗号作成を用いてデジタル署名を生じるデバイスの公開鍵の結合を幅広く含む。一般に、本発明の第一の局面による方法は、公開鍵に関連付けられるアカウントに関する通信媒体を介してメッセージを電子通信するステップであって、対応する秘密鍵は、メッセージをデジタル署名するために用いられる、ステップを包含する。本発明の第二の局面による方法は、複数のアカウントを同一の公開鍵に結合するステップを包含する。本発明の第三の局面による方法は、同一の公開鍵に結び付けられた全アカウント上の情報の中心のデータベースを維持するステップを包含する。最後に、本発明の第四の局面による方法は、動的なリスク分析を特定のメッセージに適用して、メッセージについてのデジタル署名が不正に作成されるリスクを測定し、これにより、メッセージに含まれる命令を実施するかどうかを決定するステップを包含する。
【００２１】
本明細書において用いられるように、「アカウントホルダー」は、概して、保持される秘密鍵を用いてデジタル署名を生成することができるデバイスを所有する任意の個人である。秘密鍵は、個人が活動することが認証されたアカウントに結び付けられた公開鍵に対応する。「アカウントオーソリティ」は、概して、アカウントホルダーに代わって、そのようなアカウントを維持する、個人、エンティティ、システム、または装置である。いくつかの実施形態において、「アカウントホルダー」は、それ自体、保持された秘密鍵を用いてデジタル署名を生成することができるデバイスである。秘密鍵は、デバイスが認証されたアカウントに結び付けられた公開鍵に対応する。
【００２２】
本発明の種々の局面の方法論を簡単に説明すると、二者、三者、および多数の者のアカウントベースのデジタル署名（ＡＢＤＳ）システムの一般的および特定の実行が、より詳細に記載される。
【００２３】
（１．アカウントベースのデジタル署名（ＡＢＤＳ）システム）
（ａ．一般的２者ＡＢＤＳシステム）
図２は、本発明の第一の局面による好適なアカウントベースのデジタル署名（ＡＢＤＳ）システム２００を示す。特に、図２は、アカウントホルダー２０２およびアカウントオーソリティ２１２を含む２者ＡＢＤＳシステムを示す。示されるように、アカウントホルダー２０２は、デバイス２５０を所有する個人を備え、公開−秘密鍵の対の固有の秘密鍵を安全に保護する。アカウントオーソリティ２１２は、アカウントデータベース２１４と総称され図示される、一つ以上のアカウントデータベースを維持する、エンティティまたはシステムを備える。このアカウントデータベース２１４は、アカウントホルダー２０２のアカウントを含む。好適には、アカウントは、アカウントデータベース２１４内で固有の識別子（ａｃｔＩＤ）（例えば、アカウント番号）２１６に基づいて識別される。さらに、アカウントオーソリティ２１２は、アカウントと公開鍵２１８との間の結合を維持する。この公開鍵２１８は、アカウントホルダー２０２のデバイス２５０内に安全に保持された秘密鍵と対応する。
【００２４】
アカウントホルダー２０２とアカウントホルダ２０２のアカウントに関するアカウントオーソリティ２１２との間の通信は、インターネット、イントラネット、無線ネットワーク、専用の配線によるネットワーク、その他等の任意の従来の通信媒体２０８を通じて発生する。各通信は、電子化しており、アカウントホルダ２０２からアカウントオーソリティ２１２への各電子通信（「ＥＣ」）２０６は、アカウントホルダー２０２によって、デバイス２５０内に保持された秘密鍵を用いてデジタル署名された電子メッセージ（Ｍ）を含む。デバイス２５０がアカウントオーソリティ２１２と通信する手段は、デバイス２５０の形態要因、および、デバイス２５０が、メッセージの生成または形成において、アカウントオーソリティ２１２へのＥＣの送信または通信において、または、その両方において支援するために分離Ｉ／Ｏ支援要素（図示せず）とともに用いられるかどうかによって変化する。
【００２５】
メッセージは、好適には、アカウントホルダー２０２のアカウントの固有の識別子（ａｃｃｔＩＤ）２１６およびアカウントオーソリティ２１２がアカウントに関連して実施するための命令（ｉ１）を含む。メッセージのデジタル署名は、さらに、好適には、固有の乱数またはセッションキー（例えば、日付および時間スタンプ）を含み、その結果、デバイス２５０によって作成された二つのデジタル署名は、決して同一にはならない（そして、さらに、その結果、アカウントオーソリティ２１２によって受け取られた任意の複製デジタル署名は、個々に識別され、関係を無関係であり得る。
【００２６】
固有の識別子（ａｃｃｔＩＤ）２１６を用いると、アカウントオーソリティ２１２は、結合された公開鍵２１８を検索することができる。公開鍵２１８は、ＥＣ２１６のメッセージおよび送信者を認証するために必要である（すなわち、ファクタＡのエンティティ認証）に基づく。本発明のこの第一の局面によると、メッセージおよびＥＣ２０６の送信者の成功した認証の際、アカウントオーソリティ２１２は、アカウントホルダー２０２がこのような命令（ｉ１）を個人的に提示したかのように、メッセージの命令（ｉ１）を実施する（または実施しようと試みる）。
【００２７】
有利なことに、固有の識別子（ａｃｃｔＩＤ）２１６は、ＥＣ２０６のメッセージおよび送信者を認証する目的でアカウントオーソリティ２１２が適切な公開鍵２１８をアカウントデータベース２１４から検索するため、かつメッセージに含まれる命令（ｉ１）を実施するようにアカウントホルダー２０２から十分な認可を有するために、メッセージに含まれなければならない全てである。したがって、アカウントホルダー２０２は、いかなる「アイデンティティ」情報をメッセージに含む必要がない。さらに、アカウントオーソリティ２１２は、好適には、デバイス２５０によって作成された有効なデジタル署名なしで（または、代替として、アカウントホルダー２０２の実際の、物理的な存在なしで）アカウントホルダー２０２のアカウント上でいかなる活動も実施しないので、および、「アイデンティティ」情報は、アカウントホルダー２０２とアカウントに関するアカウントオーソリティ２１２との間の電子通信に含まれる必要がないので、ＥＣ２０６を含む、このような電子通信は、暗号化されない様式で不確かな通信媒体２０８（インターネット等）を介して、アカウントホルダー２０２のプライバシーを漏洩するリスクなく伝達され得る。明らかに、アカウントホルダー２０２がＥＣ２０６内に含まれる情報のコンテンツをプライバシー、機密性、または同様の理由のために保護することを望む場合、ＥＣ２０６は、アカウントホルダー２０２によって従来の方法、例えば、ＰＧＰ型の暗号化のためにアカウントオーソリティ２１２の公開鍵を用いて、安全なソケットレイヤリング（ｌａｙｅｒｉｎｇ）（ＳＳＬ）を用いて、または、他の類似の暗号化技術を用いて、暗号化され得る。しかしながら、ＥＣのコンテンツを暗号化することは、本発明の機能化を必ずしも必要でない。
【００２８】
図２ａは、アカウントデータベース２１４内に含まれる情報間の複数の可能な関係を示す。一般に、データベース２１４内の各アカウントは、例えば、そのアカウント識別子（ａｃｃｔＩＤ）２１６によって識別され、アカウントホルダーに特有の情報（以後、「顧客特有の情報」）およびアカウントに特有の情報（以後、「アカウント特有の情報」）、および公開鍵情報２１８等のアカウント情報２４０に関連付けられる。最低限で、公開鍵情報２１８は、各特定のアカウントおよび／またはアカウント識別子２１６に結び付けられた各公開鍵（ＰｕＫ）を識別する。示されるように、データベース２１４は、複数の特定のアカウント２８１、２８２、２８３、２８４、２８５、２８８を、アカウント２８５と２８８との間に存在する複数のアカウント（図示しないが“．．．”によって示される）とともに維持する。アカウント２８１、２８８は、各アカウントが単一の顧客またはアカウントホルダーを有し、かつ、各アカウントは、使用のために結び付けられた単一の公開鍵（ＰｕＫ）を有する第一のアカウントセットアップタイプを示す。アカウント２８２は、アカウント２８２が単一の顧客またはそれに結び付けられたアカウントホルダーを有するが、アカウントホルダーはアカウント２８２を用いた使用のために結び付けられた複数（この場合、二つ）の異なる公開鍵（ＰｕＫ）を有する、第二のアカウントセットアップタイプを示す。このようなセットアップは、例えば、アカウントホルダーが、同一のアカウント２８２へのアクセスのために本発明のデバイスを１より多く使用する場合に有益である。第三のアカウントセットアップタイプは、アカウント２８３、２８４に関連して示される。これらのアカウント２８３、２８４のそれぞれは、同一のアカウントホルダーを有する。この同一のアカウントホルダーは、これらのアカウント２８３、２８４のいずれかまたは両方にアクセスするための単一の公開鍵を使用する。このようなセットアップは、例えば、アカウントホルダーが複数のアカウント（この場合、二つ）を単一のアカウントオーソリティ（例えば、同一の金融機関を有する一次および二次銀行アカウント）とともに維持する場合に有益である。この特定のセットアップは、図６４〜７０に関して本明細書において説明される「人中心のデバイス」のセクションにおいてより詳細に議論される。第四のアカウントセットアップタイプは、アカウント２８５に関連して示される。アカウント２８５は、複数の異なる顧客またはアカウントホルダー（この場合、三つ）と結合し、これらのそれぞれは、アカウント２８５にアクセスするための異なる公開鍵（ＰｕＫ）を有する。このようなセットアップは、例えば、アカウントが二以上の認可されたユーザ（例えば、ジョイントアカウントへのアクセスを有する夫婦、雇用者のアカウントへのアクセスを有する複数の従業員）を有する場合に有益である。このタイプのアカウントセットアップを用いる特定のビジネスインプリメンテーションが、図４６〜４９に関連して示されかつ議論される。
【００２９】
図２ａには示されないが、上記四つのアカウントセットアップタイプは、種々の順列でさらに互いに結合され得、それでも、本発明の範囲および意図に落ち着くことが明らかである。図２ａに示されないこのような組み合わせの一つの例として、アカウント２８５にアクセスする顧客の一人は、実際に、ジョイントアカウント２８５にアクセスするための公開鍵を１より多く有し得る。
【００３０】
ここで、図２ｂに話しを変えると、本発明のさらなる機能において、アカウントデータベース２１４は、さらに、デバイスプロファイル情報２７０を含み得る。各デバイスプロファイルは、デバイスのセキュリティプロファイルおよび取引履歴を含む。セキュリティプロファイルは、デバイスのセキュリティ機能および製造履歴を含む。セキュリティ機能は、秘密鍵およびデバイス内の他のデータを、開示（「セキュリティ特性」）およびエンティティ認証（「認証能力」）を実施する機能から保護するデバイスのこれらの機能を含む。セキュリティプロファイルに含まれる情報は、本明細書においてセクションＶＩ．４の名称「ダイナミックリスク分析の取引への適用」により詳細に記載される。アカウントデータベース２１４とともに維持される対応する公開鍵２１８に結び付けられた固有の公開鍵のみが本発明の単一のデバイスに存在することが企図されるので、各公開鍵２１８とそのそれぞれのデバイスプロファイル情報２７０との間に１対１の対応がある。さらに、追加のセキュリティがその秘密鍵を漏らすことができないデバイスを用いて取得される。
【００３１】
（ｂ．一般的３者ＡＢＤＳシステム）
図３は、好適な３者ＡＢＤＳシステム３００を示し、アカウントホルダー３０２およびアカウントオーソリティ３１２並びに中間者３１０を含む。３者ＡＢＤＳシステム３００は、２者ＡＢＤＳシステム２００（図２から）とは、アカウントホルダー３０２からアカウントオーソリティ３１２へのメッセージおよびデジタル署名がＥＣ３０５の手段によって最初に中間者３１０に通信される点で異なる。中間者３１０は、次いで、別のＥＣ３１５における同一のメッセージおよびデジタル署名をアカウントオーソリティ３１２に転送する。
【００３２】
命令（ｉ２）は、ＥＣ３０５の一部または分離ＥＣ（図示せず）のいずれかとして、アカウントホルダー３０２から中間者３１０へ通信される。中間者３１０は、命令に基づいて活動せず、むしろ、ＥＣ３１５をアカウントオーソリティ３１２に転送し、アカウントオーソリティ３１２がメッセージを許可または拒絶するのを待つ。示されるように、ＥＣ３１５におけるメッセージおよびデジタル署名は、ＥＣ３０５におけるメッセージおよびデジタル署名と同じである。
【００３３】
ＥＣ３１５の受信の際、アカウントオーソリティ３１２は、公開−秘密鍵の対の公開鍵を用いてメッセージおよびＥＣ３０５の送信者を認証することを試みる。この公開鍵は、メッセージからの固有の識別子（ａｃｃｔＩＤ）３１６に基づいてアカウントデータベース３１４から検索される。認証が成功した場合、アカウントオーソリティ３１２は、アカウントホルダー３０２が命令（ｉ１）を提示しているかのように、メッセージの命令（ｉ１）を実施する（または実施することを試みる）。メッセージおよびＥＣの送信者の試みられた認証の結果に基づき、かつ、命令（ｉ１）の試みられた実行に基づいて、アカウントオーソリティ３１２は、中間者３１０にメッセージの許可または拒絶の通知を、回答ＥＣ３１９の手段によって提供する。回答ＥＣ３１９がメッセージの許可を示す場合、中間者３１０は、アカウントホルダー３０２から受け取られた命令（ｉ２）を実行する。好適には、中間者３１０は、アカウントホルダー３０２に命令（ｉ２）の許可および実行または回答ＥＣ３０９による命令（ｉ２）の拒絶のいずれかを通知する。
【００３４】
再度、「アイデンティティ」情報が、このシステム３００のもとでアカウントホルダー３０２によってＥＣ３０５に含まれる必要がない留意されるべきである。さらに、ＥＣ３０５、３１５、３０９、３１９の全てが、図２のシステム２００に関して上記に議論されたのと同じ理由のため、暗号化されない様式で、インターネット、イントラネット、無線ネットワーク、専用の配線ネットワーク、その他等の任意の従来の通信媒体３０８ａ、３０８ｂを介して伝達され得る。さらに、上述のように者が種々のＥＣ３０５、３０９、３１５、３１９内に含まれる情報のコンテンツをプライバシー、機密性、、または類似の理由のために保護することを望む場合、このようなＥＣは、特定のＥＣの送信者によって、従来の方法、例えば、ＰＧＰ型の暗号化のための特定のＥＣの意図された受信側（単数または複数）の公開鍵用いて、安全なソケットレイヤリング（ＳＳＬ）を用いて、または、他の類似の暗号化技術で暗号化され得る。しかしながら、種々のＥＣのコンテンツを暗号化することは、本発明の機能化について必ずしも必要としない。さらに、通信媒体３０８ａ、３０８ｂは、互いに（示されるように）または同じ媒体の部分で異なり得る。
【００３５】
（ｃ．多者ＡＢＤＳシステム）
特に図２および３に示されていないが、本発明の範囲内で、１以上のさらなる者またはエンティティがアカウントホルダー、中間者、およびアカウントオーソリティ間の通信ルートに沿って導入され得ることが理解されるべきである。特に、このような付加的な者は、種々のアカウントホルダー、中間者、およびアカウントオーソリティ間の電子通信を促進する、スクリーニングする、および正しくルーティングするために有用であり得る。
【００３６】
（ｄ．ＡＢＤＳシステムにおける一般的なアカウントセットアップ）
当然、ＡＢＤＳシステム２００、３００のいずれかが実際に利用される前に、アカウントホルダー２０２、３０２は、最初に、ＡＢＤＳシステムを適切なアカウントオーソリティ２１２、２１３とともに設置する必要がある。新しいＡＢＤＳアカウントを設置する場合に含まれるステップが、図４ａおよび４ｂに説明される。事前に存在する（および従来の）アカウントを変換する際に含まれるステップが図５ａおよび５ｂに説明される。
【００３７】
（（ｉ）新しいＡＢＤＳアカウントの設置）
最初に図４ａを参照すると、新しいアカウントをＡＢＤＳシステム内に設置するステップの一つの例示的なプロセスが示されている。この特定の実施形態において、プロセスは、アカウントオーソリティによって開始される。例えば、アカウントオーソリティは、まず、名称およびアドレス等の将来のアカウントホルダーについての公的に利用可能な情報を用いて、「シェル（ｓｈｅｌｌ）」アカウントを将来のアカウントホルダーのために設置する（ステップ４０２）。アカウントオーソリティは、次に、固有のアカウント識別子を「シェル」アカウントに割り当て、それを関連付ける（ステップ４０４）。アカウントオーソリティは、次いで、公開鍵を本発明のデバイスから取得し（ステップ４０６）、公開鍵をアカウントデータベースに記録し、「シェル」アカウントまたは固有の識別子に関連付ける（ステップ４０８）。本発明のいくつかの実施形態において、固有の識別子は、実際に、デバイスからの公開鍵または、ハッシュされたバージョンの公開鍵であり得る。アカウントオーソリティは、次いで、将来のアカウントホルダーに代わって、アカウントオーソリティによって、アカウントを「開く（ｏｐｅｎ）」ことの申し出により、および、そのようにするための命令により、「シェル」アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスを将来のアカウントホルダーに、分配または送信する（ステップ４１０）。アカウントオーソリティは、次いで、将来のアカウントホルダーからの応答を待つ。
【００３８】
応答が受信された場合（ステップ４１２）、アカウントオーソリティは、従来の認証技術を使用して、それが将来のアカウントホルダーとの通信であることを確認する。アカウントオーソリティは、次いで、必要とされるように、アカウント記録を配置するために、さらなる情報を取得する（ステップ４１４）。アカウントオーソリティは、次いで、将来のアカウントホルダーが、デバイスを用いてデジタル署名されたテストメッセージを伝送することを要求する（ステップ４１６）。このようなテストメッセージは、将来のアカウントホルダーが正しいデバイスを所有することを確認する。テストメッセージを確認した場合、デバイスは、結合されたアカウントを用いた使用のために「活性化される」（ステップ４１８）。
【００３９】
代替の実施形態において、新しいＡＢＤＳアカウントのセットアップは、図４ｂに示されるように、本発明のデバイスを既に所有する将来のアカウントホルダーによって開始され得る。例えば、アカウントオーソリティは、このような将来のアカウントホルダーからの新しいＡＢＤＳアカウントを設置することの要求を受信し得る（ステップ４５０）。アカウントオーソリティがこのようなデバイスを既に所有するこのような将来のアカウントホルダーを進んで受け入れる場合、アカウントオーソリティは、十分な情報を将来のアカウントホルダーからこのようなアカウントを設置するために受信する（ステップ４５２）。いくつかのビジネスアプリケーションにおいて、このようなアカウントを設置するために、将来のアカウントホルダーが任意の「アイデンティティ」情報を漏洩することは必要ではない。アカウントオーソリティは、次いで、アカウントオーソリティのアカウントデータベースの記録内の将来のアカウントホルダーによって提供されたあらゆる情報を記録し（ステップ４５４）、アカウント番号等の固有の識別子をアカウントに割り当てる（ステップ４５６）。
【００４０】
次に、且つ、好適には同時に、アカウントオーソリティは、デバイス上に安全に保持された秘密鍵に対応する公開鍵を取得する（ステップ４５８）。いくつかのビジネスアプリケーションにおいて、公開鍵は、デバイスに提示された適切な要求に応答して、直接、デバイスから取得される。他のビジネスアプリケーションにおいて、公開鍵は、中央鍵オーソリティ（図７１ａ〜７２を参照すると以下に議論されるように）、デバイス製造者、デバイス配給業者、その他等の第三者によって維持されるデータベースから取得される。アカウントオーソリティは、次いで、公開鍵が将来のアカウントホルダーのアカウント記録に適切に結合される、または、関連付けられる方法で公開鍵を記録する（ステップ４６０）。好適には、公開鍵は、特に、アカウントの固有の識別子に関連付けられる。いくつかの実施形態において、公開鍵そのもの（または、公開鍵のハッシュ値）は、アカウントに割り当てられた固有の識別子として用いられる。
【００４１】
最後に、アカウントオーソリティが公開鍵のアカウントへの適当な結合を確認することおよびデバイスが秘密鍵を保持することを確認することも好適である。この秘密鍵は、アカウントホルダーに認証のための「テスト」ＥＣを提示させる（ステップ４６２）ことによって、アカウントに結合された公開鍵に対応する。この認証は、登録された対応する公開鍵を含み得る。一旦、アカウントオーソリティが、アカウントが正確に設置されことおよびアカウントホルダーが登録されている公開鍵に対応する適切な秘密鍵を保持するデバイスを所有すること満足すると、アカウントは、活性化され（ステップ４６４）、その結果、デバイスを用いてデジタル署名される取引は、ファクタＡエンティティ認証による適法なアカウントホルダーから来たと考えられる。
【００４２】
上記実施形態において、アカウントオーソリティは、中央鍵オーソリティまたは他の信頼できるソースから取得されたデバイスのセキュリティプロファイルによって確認されるように、または、デバイスの物理的な観察によって確認されるように、デバイスの完全性のレベルがそのビジネス標準またはそれぞれのアカウントを用いた使用のための要求に一致または超えることを確認することを所望し得る。
【００４３】
（（ｉｉ）予め存在するアカウントのＡＢＤＳアカウントへの変換）
ここで、図５ａを参照すると、アカウントオーソリティによって開始された場合の、予め存在する、従来のアカウントをＡＢＤＳアカウントに変換するステップの例示のプロセスが説明される。最初に、アカウントオーソリティは、既にアカウントホルダーのための従来のアカウントセットアップを、アカウントデータベースの記録に維持していることが仮定される。さらに、このような記録は、個人およびアカウントホルダーの他の適切な情報を含む。既存のアカウントは、すでにそれ自体の固有の識別子を有することがさらに仮定される。
【００４４】
第一に、アカウントオーソリティは、公開鍵を本発明のデバイスから取得し（ステップ５０２）、アカウントデータベースにおける公開鍵を記録し、既存のアカウントまたはアカウントの固有の識別子に結びつける（ステップ５０４）。アカウントオーソリティは、次いで、既存のアカウントに結合された公開鍵に対応する秘密鍵を保持するデバイスをそのアカウントホルダーに、既存の従来のアカウントをＡＢＤＳシステム」に「変換する」という提示とともに分配または送信する（ステップ５０６）。アカウントオーソリティは、次いで、そのアカウントホルダーからの応答を待つ。
【００４５】
応答が受け取られた（ステップ５０８）場合、アカウントオーソリティは、それは期待されたアカウントホルダーとの通信であることを確認するために従来の認証技術を使用する。アカウントオーソリティは、次いで、アカウントホルダーに、デバイスを用いてデジタル署名されたテストメッセージを伝送することを要求する（ステップ５１０）。このようなテストメッセージは、アカウントホルダーが正しいデバイスを所有すること確認する。テストメッセージを確認した場合、デバイスは、新しく変換されたＡＢＤＳアカウントを用いた使用のために「活性化される」（ステップ５１２）。
【００４６】
代替の実施形態において、従来のアカウントからＡＢＤＳアカウントへの変換は、本発明のデバイスを既に所有する既存のアカウントホルダーによって開始され得る。例えば、アカウントオーソリティは、従来のアカウントをＡＢＤＳアカウントに変換するための要求を受け取る（ステップ５５０）。このＡＢＤＳアカウントは、アカウントホルダーが、アカウントホルダーの特定されたデバイスを用いてデジタル署名された電子メッセージを用いてアカウント上で取引することを可能にする。アカウントオーソリティがこのような変換を進んで受け入れ、且つ、アカウントホルダーがこのようなデバイスを使用することを進んで可能にする場合、アカウントオーソリティは、最初に、従来のエンティティ認証技術を用いて、期待されたアカウントホルダーと通信しているまたは他の場合にはそれを処理していることを確認する（ステップ５５２）。次に、および好適には同時に、アカウントオーソリティは、デバイス上に安全に保持される秘密鍵に対応する公開鍵を取得する（ステップ５５４）。いくつかのビジネスアプリケーションにおいて、公開鍵は、デバイスに提示された適切な要求に応答して、直接、デバイスから取得される。他のビジネスアプリケーションにおいて、公開鍵は、中央鍵オーソリティ（図７１ａ〜７２を参照すると以下に議論されるように）、デバイス製造者、デバイス配給業者その他等の第三者によって維持されるデータベースから取得される。アカウントオーソリティは、次いで、公開鍵がそのアカウントホルダーの既存のアカウント記録に適切に結合されるかまたは結合される方法で公開鍵を記録する（ステップ５５６）。好適には、公開鍵は、特にアカウントの固有の識別子に結合される。いくつかの実施形態において、公開鍵そのもの（または公開鍵のハッシュ値）は、アカウントに割り当てられた固有の識別子として用いられる。
【００４７】
最後に、アカウントホルダーに「テスト」ＥＣを認証（これは、登録された対応する公開鍵を含み得る）のために提示させる（ステップ５５８）ことによって、アカウントオーソリティが公開鍵のアカウントへの適切な結合を確認することおよびデバイスが秘密鍵（これは、アカウントに結合された公開鍵に対応する）を保持することを確認することも好適である。。一旦アカウントオーソリティがアカウントが適切に設置されたことおよびアカウントホルダーが、登録された公開鍵に対応する適切な秘密鍵を保持するデバイスを所有することを満足すると、アカウントは、活性化され（ステップ５６０）、その結果、デバイスを用いてデジタル署名された取引は、ファクタＡエンティティ認証による適法なアカウントホルダーから来るように考えられる。
【００４８】
（ｅ．ＡＢＤＳシステムに有用なデバイス）
本発明の局面のすべてにしたがって、デバイスは、ハードウェア、ソフトウェア、および／またはファームウェアを備え、特に、コンピュータチップ、集積回路、適切なソフトウェアを有するコンピュータ読み出し可能な媒体、または、これらの組み合わせを備える。デバイスは、さらに、ハードウェアトークンまたは埋め込まれたトークン、コンピュータチップ、集積回路、またはソフトウェア、またはこれらの組み合わせを含むトークン等の物理的なオブジェクトを備え得る。デバイスがハードウェアトークンである場合、それは、好適には、リングまたは他の宝石類、ドングル、電子キー、ＩＣカード、スマートカード、デビットカード、クレジットカード、ＩＤバッジ、安全バッジ、パーキングカード、またはトランシットカードその他等のカードの形態をとる。デバイスが埋め込まれたトークンである場合、それは、好適には、携帯電話、電話、テレビ、パーソナルデジタルアシスタント（ＰＤＡ）、時計、コンピュータ、コンピュータハードウェアその他の形態をとる。デバイスは、好適には、ポート（無線通信ポート、シリアルポート、ＵＳＢポート、パラレルポート、または赤外ポートを含む）または外部の電子装置（接触または非接触のいずれか）と通信するためのいくつかの他の物理的なインターフェースを備えるデバイスインターフェースを含む。デバイスは、さらに、信頼されたプラットフォームモジュール（ＴＰＭ）を含み得る。このプラットフォームモジュール（ＴＰＭ）は、Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ（ＴＰＭ）　Ｓｅｃｕｒｉｔｙ　Ｐｏｌｉｃｙ　Ｖｅｒｓｉｏｎ　０．４５，ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡｌＬＩＡＮＣＥ，Ｏｃｔｏｂｅｒ　２０００およびＴＣＰＡ　ＰＣ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　０．９５，ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ，Ｊｕｌｙ　４，２００１に説明されるおよび記載されるように、増大された信頼をプラットフォームに提供するハードウェアおよびソフトウェアコンポーネントを備える。これらの両方は、本明細書において参考（集約的に「ＴＣＰＡ文書」）として援用される。
【００４９】
好適には、デバイスは、電子メッセージを受け取り、次いで、格納された秘密鍵を利用する電子メッセージのためのデジタル署名を作成することができる。デバイスは、好適には、さらに、秘密鍵を用いた暗号化に先行して、デバイスによって受け取られたメッセージに関するハッシュ機能を実施する。
【００５０】
さらに、デバイスが、例えば、英数字キーパッド、電子コンタクト、タッチ画面表示、コンピュータバスを有する標準電子インターフェース、またはアンテナ等のデバイスインターフェースを含むことが好適であり、その結果、デバイスは、メッセージを受け取り得るだけでなく、メッセージを構成し得る。デバイスインターフェースは、さらに、無線通信ポート、シリアルポート、ＵＳＢポート、パラレルポート、または赤外線ポート等のポートを備え得る。
【００５１】
上記デバイスのいくつかは、デバイスがメッセージまたは他の入力を検索することを可能にするために、Ｉ／Ｏ支援要素の使用を要求する。デバイスのいくつかは、ＥＣの受信側へのデジタル署名およびメッセージを含む、情報を伝達するために、Ｉ／Ｏ支援要素の使用を要求する。デバイスのいくつかは、独立しており、これは、それらがメッセージ、デジタル署名、および他の情報を、外部装置を使用することなく、生成および伝達し得ることを意味する。いくつかのデバイスは、独立しているが、望みであれば、Ｉ／Ｏ支援要素等のような外部装置と相互作用することができる。Ｉ／Ｏ支援要素は、用いられる特定の用途に応じて、および相互作用する形態の要因に応じて任意数の異なる装置の形態をとり得る。Ｉ／Ｏ支援要素の一つの例は、Ｆｉｎａｎｃｉａｌ　Ｔｒａｎｓａｃｔｉｏｎａｌ　ＩＣ　Ｃａｒｄ　Ｒｅａｄｅｒ　Ｐｒｏｊｅｃｔ（「ＦＩＮＲＥＡＤ」として公知である）の結果としてＣＥＮ／ＩＳＳＳによって出版された技術明細書にしたがって設計されたハードウェアおよびソフトウェアコンポーネントを備えるカードリーダを含む。
【００５２】
本発明の各局面に用いられる、好適には、デバイスの製造の間、デバイスのセキュリティに関して、固有かつランダムな公開−秘密鍵の対は、既知の製造技術を用いて、デバイス内に、好適には、コンピュータチップ、集積回路、または埋め込まれた他の暗号作成モジュール上で直接（乱数生成器を用いて）生成される。秘密鍵の大きさのため、および乱数生成器を用いてキーが生成されるため、複製の秘密鍵が異なるデバイス内に存在し得る見込みは、非常に低い。秘密鍵は、次いで、デバイス内のメモリ記憶位置内に安全に格納され、そして、好適には、デバイスの耐用期間にわたって（デジタル署名をデバイス内で内部的に生成するという目的以外に）アクセス不可になされる。さらに、デバイスは、好適には、以下のさらなる特徴を含む。それは、大荒れにされる（ｔｅｍｐｅｓｔｅｄ）（すなわち、デバイスからの電磁気放射を最小化するように設計され、そのため、電子的な盗み聞きへの傷つき易さを最小化する）；デバイスは、知られた電子的攻撃に反応を示さない。；デバイスは、ゼロ化する能力を用いて偽造されないようにする（すなわち、デバイスの物理的な偽造または侵入がデバイスのデジタル署名コンポーネントの機能性を破壊し、および／または、秘密鍵を消去する）。；デバイスは、秘密鍵が決してデバイスの外部に漏洩されないように秘密鍵を安全に維持する。；そして、デバイスは、必要なときに公開鍵をエクスポートすること可能にする。
【００５３】
さらに、デバイスは、好適には、Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄ　Ｐｕｂｌｉｃａｔｉｏｎ　１８６−２，Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ｓｔａｎｄａｒｄ，ＵＳ　ＤＯＣ／ＮＢＳ，Ｊａｎｕａｒｙ　１１，１９９４（以後、「ＦＩＰＳ　ＰＵＢ　１８６−２」）に明細に記されている楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）にしたがって、デジタル署名を作成する。この文献は、本明細書において参考として援用される。したがって、デバイスは、乱数発生器を用いてデジタル署名を作成し、ハッシュ機能は、セキュリティハッシュアルゴリズム（「ＳＨＡ−１」）を用いて実施される。このセキュリティハッシュアルゴリズムは、デバイスに入力されるメッセージの大きさに関わらず２０バイトの出力を生成する。ＳＨＡ−１自体は、Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄｓ　Ｐｕｂｌｉｃａｔｉｏｎ　１８０−１，Ｓｅｃｕｒｅ　Ｈａｓｈ　Ｓｔａｎｄａｒｄ，ＵＳ　ＤＯＣ／ＮＢＳ，Ａｐｒｉｌ　１７，１９９５（以後、「ＦＩＰＳ　ＰＵＢ　１８０−１」）に明細に記されている。この文献は、本明細書において参考として援用される。
【００５４】
本発明の局面において、デバイスは、好適には、その認可されたユーザ（単数または複数）に個人所有される。デバイスの個人所有は、個人識別番号（ＰＩＮ）、パスワード、またはパスフレーズ（以後、「シークレット」）の設置を含む。都合良く、このようなシークレットがデバイス内に予め格納され、デジタル署名を生成するために動作する前にデバイスに入力される必要がある。あるいは、しかしこれも都合良く、シークレットは、事前に受信側とともに共有され、ＥＣレターが受信側に送られたときに、シークレットも、メッセージに関連して受信側に送られる。第一の場合には、シークレットの照合は、デバイスのユーザを認証し（以後、「ユーザ認証」）、第二の場合には、シークレットの照合は、ＥＣの送信者を認証する（以後、「送信者認証」）。シークレットが共有され、そして、ＥＣの送信者と受信側との間に伝送される場合、それは通常、他のものからの秘密性を維持するために、暗号化されるか、他の場合には保護される必要がある。いずれの場合にも、シークレットの確認は、ユーザまたは送信者が何を「知っているか」（以後、「ファクタＢエンティティ認証」）に基づくエンティティ認証を表す。
【００５５】
物理的な窃盗を通じたデバイスの不正な使用に対する他のセキュリティ測定は、デバイスのユーザまたはＥＣの送信者の生物測定の特徴（例えば、指紋、網膜スキャン、ＤＮＡ、声紋その他）の照合を含む。この種の認証は、ユーザまたは送信者が何で「ある」かに基づいている（以後、「ファクタＣエンティティ認証」）。シークレットと同様に、生物測定の値は、都合良く、ユーザ認証のためにデバイス内に維持されるか、または、受信側による送信者認証のために事前に受信側と共有されるかのいずれかである。生物測定の値が共有され、かつ、ＥＣの送信者と受信側との間に伝送される場合、このような生物測定の値を、他者による妨害および発見から保護するために、よりいっそう大きい予防措置がとられる必要がある。
【００５６】
ファクタＢおよびファクタＣエンティティ認証情報をＥＣの受信側に提供する上記方法の両方と対照的に、シークレットおよび／または生物測定値（単数または複数）がデバイスに提供され、このようなシークレットおよび／または生物測定値（単数または複数）の、デバイスに事前に格納されたデータとの比較の結果を表すインジケーターがＥＣの受信側に、シークレットおよび／または生物測定値（単数または複数）を通信または漏洩することなく提供される、アカウントホルダーからアカウントオーソリティにエンティティ認証状態を提供する代替の方法が、さらに、本発明によって用いられ得る。このような方法論は、ＶＳ出願に詳細に記載される。
【００５７】
（ｆ．ＡＢＤＳシステムにおけるＥＣの種類および使用）
図２および３の両方に関連して以前に述べられたように、アカウントホルダーからアカウントオーソリティへのＥＣは、メッセージ（Ｍ）およびメッセージのデジタル署名（ＤＳ（Ｍ））の両方を含む。メッセージは、好適には、固有のアカウント識別子（ａｃｃｔＩＤ）およびアカウントオーソリティがアカウントに関連して実施するための命令（ｉ１）を含む。しかしながら、多くの環境において、メッセージが固有のアカウント識別子を含むことは必要でない。例えば、アカウントオーソリティが、固有のアカウント識別子をアカウントホルダーからの以前のメッセージから既に取得し得、アカウント識別子の再伝達は、アカウントオーソリティがそれは同一のアカウントホルダーと通信していることを知る限り（例えば、セッションキーまたは識別子によって、または連続的な、二つの間の不断の電子的接続の期間）、同一のアカウントホルダーからの後に続くメッセージのために不必要である。さらに、メッセージが、例えば、命令（ｉ１）がアカウントホルダーとアカウントオーソリティとの間の単なる通信においてインプリシットである場合等の命令（ｉ１）を含むことが常時必要なわけではない（例えば、パーキングゲートコントローラーに送られたＥＣ内の命令（ｉ１）は、「パーキングゲートを開く」ための命令を明らかに意味する）。
【００５８】
ＥＣ、そしてＥＣの送信者を認証する能力は、本発明内の少なくとも三つの異なるビジネス目的ために有用である。これらの三つの異なる目的は、一般的に、以後、「セッション認証」、「取引認証」、および「取引確認」として記載される。セッション認証および取引認証は、互いに類似する。それは、両者は、通常、アカウントホルダーが、適法なアカウントホルダーであることをアカウントオーソリティに「立証」しなければならない（エンティティ認証の強度に基づいて少なくとも可能な範囲で）状況を含むからである。対照的に、取引確認は、通常、アカウントホルダーが、適法なアカウントホルダーであることをアカウントオーソリティに既に立証した状況を含む。しかしながら、アカウントオーソリティは、メッセージ内に含まれる特別の命令（ｉ１）に応答してアカウントオーソリティが要求された活動（通常、アカウント自体上）を実施する前に、アカウントホルダーからの特別にデジタル署名されたメッセージの確認を要求する。
【００５９】
セッション認証および取引認証は、概して、アカウントオーソリティがアカウントホルダーに、アカウントホルダーのアカウントまたはアカウントホルダーが権利を有する別のリソースへのアクセスを承諾する前に必要である。このような認証はまた、概して、アカウントオーソリティが、要求された活動をアカウントまたはリソース上で実施する前に必要である。リソースは、例えば、物理的空間、データベース、コンピュータファイル、データ記録、チェッキングアカウント、コンピュータシステム、コンピュータプログラム、ウェブサイトその他である。セッション認証と取引認証との間の主要な区別は、アカウントオーソリティがこのような認証の結果として何をしたかということである。例えば、一旦アカウントホルダーがセッション認証のために認証されると、アカウントオーソリティは、アカウントホルダーに、「セッション」の間、（セッションキー、エンティティ識別子その他によって）要求されたアカウントまたはリソースへのアクセスを提供する。セッションの意味は、アクセスされたアカウントまたはリソースの種類に応じて。および、アカウントまたはリソースを保護する特定のアカウントオーソリティのビジネスルールに応じて変化する。しかしながら、セッションは、通常、アカウントホルダーが活動をアカウントまたはリソース上またはその内部で、さらなる認証をアカウントオーソリティに提供することなく実施することを許容される幾分かの期間を意味する。さらに、アカウントホルダーが承諾されたアカウントまたはリソースへのアクセスの量も、特定のアカウントオーソリティのビジネスルールによって支配され、そして、アカウントオーソリティからアカウントオーソリティおよびアカウントからアカウントに変化し得る。
【００６０】
対照的に、取引オーソリティは、通常、それが結び付けられた特定の取引に有用であるのみである。特定の取引に結び付けられた取引認証は、別の取引を用いた使用のために「持ち越され」ない。このような取引は、アカウントオーソリティが特定の活動をアカウントまたはリソース上で実施するための要求であり得る（例えば、アカウントオーソリティが「アカウント差額のチェックを提供する」、「ドアを開く」ための要求）。しかしながら、取引確認（次のパラグラフに記載される）と対照的に、取引認証は、要求された活動を実施する前にアカウントオーソリティがアカウントホルダーの「意図」を知ることを特別に必要としない場合に有用である。
【００６１】
他方、取引確認は以下の場合に有用である。すなわち、特定の取引に結び付けられた価値またはリスクが、アカウントホルダーがメッセージを送信およびデジタル署名することを意図し、これに対応して、アカウントオーソリティがそれを信頼して活動することを意図するという十分な保証を受け取らなければアカウントオーソリティが活動しないレベルに上昇する取引確認は有用である。デジタル署名は、デバイスによって、潜在的にデバイスなしで、または、所有者またはユーザがデバイスの知識すらなく、生成されることが可能であるので、上記の意図は、アカウントホルダーのデバイスからのデジタル署名の単なる受信から推定され得ない。この理由のため、特定の取引に関してアカウントホルダーの意図を確認するなんらかの手段が必要とされる。このような取引確認は、好適には、アカウントオーソリティによって受信されたメッセージで決定可能なアカウントホルダーによって実施される物理的な、明白な活動によって取得される。例えば、いくつかの例では、アカウントホルダーによるファクタＢまたはＣエンティティ認証情報の同時存在を、デジタル署名されたメッセージとともに供給することは、確認または意図を意味し得る。このような取引確認を取得する別の方法は、アカウントオーソリティによって生成された「提示された」メッセージのアカウントホルダーによる故意、かつ、認識可能な改変を介することである。このアカウントオーソリティは、次いで、アカウントホルダーによってデジタル署名される。
【００６２】
上記に照らして、多くの環境において、たとえアカウントホルダーがセッション認証のためにエンティティ認証情報に既に提供されていたとしても、例えば、特定のアカウントまたはリソースのより制限された部分への、または、別のより制限されたアカウントまたはリソースへのアクセスによって、アカウントオーソリティがアカウントホルダーを提供する前にアカウントホルダーが追加のおよび／またはより強いエンティティ認証情報を（依然としてセッション認証のために）提供することが必要であり得ることが理解されるべきである。さらに、特定のセッションの期間でさえ、取引認証の目的（取引が要求された特定のセッションより強いレベルのエンティティ認証を要求する場合）、または、取引確認の目的（要求された活動を実施する前にアカウントオーソリティがアカウントホルダーの意図の特定の保証を望む場合）のいずれかのために、アカウントホルダーがエンティティ認証情報をアカウントオーソリティに提供することが必要であり得ることも理解されるべきである。さらに、アカウントホルダーからアカウントオーソリティに通信された単一のＥＣが、多くの環境において、取引認証のためおよび取引確認のための両方の目的のために同時に用いられ得ることも理解されるべきである。
【００６３】
ここで、図７４を参照すると、セッション認証のために用いられるＥＣ７４０６の例が示されている。示されるように、アカウントオーソリティ７４１２は、三つのリソース７４４０、７４５０、７４６０のための「ゲートキーパー」のタイプとして活動する。これらの一つを、アカウントホルダー７４０２は、ＥＣ７４０６において要求されるようにアクセスするために所望する。一つのみのアカウントオーソリティ７４１２が参照を容易にするためにこの例において示されるが、各リソース７４４０、７４５０、７４６０が実際に、そこに結び付けられたそれ自体の分離アカウントオーソリティ（図示せず）を有し得ることが理解されるべきである。
【００６４】
図７４を用いて続けると、アカウントオーソリティ７４１２は、直接的または間接的に、アカウントホルダー７４０２がゲートゲート７４９４ａ、７４９４ｂ、または７４９４ｃを通って前進することを防止することによって、アカウントホルダー７４０２がアカウントオーソリティ７４１２に「十分な」レベルのエンティティ認証を提供するまで（少なくとも特定のゲート７４９４ａ、７４９４ｂ、７４９４ｃによって要求される範囲まで）リソース７４４０、７４５０、７４６０へのアクセスを制限する。即座に明らかにされるべき理由のため、各ゲートによって要求されるエンティティ認証のレベルは、保持されている特定のリソースが何を対象としているかに応じて変化する。例えば、リソースがパーキングチェックである場合、最小レベルのエンティティ認証が必要である。リソースが法人のチェッキングアカウントである場合、より強いエンティティ認証が要求される可能性がある。リソースが核弾頭を発射するための制御システムである場合、よりいっそう強いエンティティ認証が要求される。
【００６５】
いくつかの環境において、十分なレベルのエンティティ認証を提供することは、リソースへのアクセスを取得するために必要とされる全てである。例えば、ゲート７４９４ａは、アカウントホルダー７４０２へのセッション認証ハードルのみをアクセスしているリソース７４４０に提供する（しかし、当然、アカウントホルダー７４０２に提供されるアクセスの量およびアカウントホルダー７４４０がリソースにアクセスすることができるプロセスは、許可およびアクセス権によってさらに制限され得る。これは、本明細書において詳細には議論されない）。あるいは、リソース７４５０によって示されるように、ゲート７４９４ｂを通過するために十分なレベルのエンティティ認証を提供することは、アカウントホルダー７４０２がリソース７４５０全般にアクセスすることおよび（リソース７４５０の範囲内に組み込まれた）サブリソース７４５０ａ、７４５０ｂに特定的にアクセスすることを可能にする。特に、より強いエンティティ認証は、アカウントホルダー７４０２がサブリソース７４５０ｃにアクセスする前に、ゲート７４９４ｄによって表示されるように必要である。別の代替の構成において、ゲート７４９４ｃを通過するために十分なレベルのエンティティ認証を提供することは、アカウントホルダー７４０２が、リソース７４６０だけでなく独立したリソース７４７０、７４８０、７４９０にもアクセスすることを可能にする。これらのリソース７４７０、７４８０、７４９０は、リソース７４６０の保護する範囲内ではないが、ゲート７４９４ｃを通過するための十分なエンティティ認証を提供された場合にアクセスホルダー７４０２がそれらにアクセスすることを許容する。
【００６６】
以前に述べられたように、いくつかの環境において、特定のリソース７４４０、７４５０、７４６０は、アカウントオーソリティ７４１２によって保護されるだけではなく、それによって維持される（例えば、アカウントオーソリティ７４１２が金融機関であり、リソースがアカウントホルダー７４０２の銀行アカウントである場合）。他の環境において、特定のリソース７４４０、７４５０、７４６０は、アカウントオーソリティ７４１２によって単に保護される。このアカウントオーソリティ７４１２は、リソースを実際に維持する、リソースマネジャー、アクセスコントローラー、または認証コントローラー（図示せず）等の別のエンティティとの連絡および協調している（例えば、アカウントオーソリティ７４１２が単なるエンティティ認証システムであり、リソースが安全なネットワークサーバーであり、この安全なネットワークサーバへのアクセスおよび許可が分離したアクセス制御サーバによって制御される場合）。
【００６７】
図７４の例示は、取引認証目的のために用いられるＥＣに均等に適用可能である。例えば、ＥＣがリソース７４４０、７４５０、７４６０の一つからの情報のための特定の要求またはアカウントオーソリティ７４１２が特定の活動をリソース７４４０、７４５０、７４６０上またはその内部で実施するための要求を含む場合、ＥＣ７４６０は、その特定の要求のみのためにエンティティ認証に用いられる。しかしながら、特定のリソース７４４０、７４５０、７４６０への前進する、またはセッションアクセスがその結果として承諾されない。
【００６８】
ここで、図７５を参照すると、通信媒体７５０８を介するアカウントホルダー７５０２とアカウントオーソリティ７５１２との間のＥＣの三つの異なる例が示されている。すべての三つの例において、アカウントホルダー７５０２からアカウントオーソリティ７５１２への最後のＥＣが、取引確認目的のために用いられる。
【００６９】
第一のインターチェンジ（ｉｎｔｅｒｃｈａｎｇｅ）において、図７５におけるＥＣ１Ａによって指定されるように、アカウントホルダー７５０２は、ＥＣを伝送する。このＥＣは、メッセージ（Ｍ１）およびメッセージに対するデジタル署名（ＤＳ（Ｍ１））を含む。このインターチェンジにおいて、アカウントホルダー７５０２は、意図およびファクタＢまたはＣエンティティ認証の十分な証拠を提供し、その結果、アカウントオーソリティ７５１２は、引き続くＥＣ要求確認を要求しない。
【００７０】
第二のインターチェンジにおいて、ＥＣ２Ａ、２Ｂおよび２Ｃによって指定され、そして、依然として図７５を参照するように、アカウントホルダー７５０２は、ＥＣを伝送する。このＥＣは、メッセージ（Ｍ２）およびメッセージに対するデジタル署名（ＤＳ（Ｍ２））を含む。このインターチェンジにおいて、アカウントオーソリティ７５１２は、アカウントホルダーの意図の十分な証拠がメッセージ（Ｍ２）に付与されたように受信されたことを満足しない。この理由のため、アカウントオーソリティ７５１２は、このようなＥＣ２Ｂをアカウントホルダー７５０２に送信する。ＥＣ２Ｂは、アカウントホルダー７５０２が同一のおメッセージ（Ｍ２）およびデジタル署名（ＤＳ（Ｍ２）を有するが、ファクタＢまたはＣエンティティ認証のさらなる性能も有する新しいＥＣを送信することを要求する。このファクタＢまたはＣエンティティ認証のインジケーターは、アカウントホルダー７５０２がＥＣ２Ａを送信することを意図した「証拠」としてそこに含まれる。示されるように、ＥＣ２Ｃのメッセージは、エンティティ認証インジケーター（ＥＡＩ）の追加を有する元のＥＣ２Ａのメッセージと本質的に同一である。このようなエンティティ認証インジケーター（ＥＡＩ）は、好適には、デジタル署名されたメッセージ（Ｍ２）内に含まれる。
【００７１】
第三のインターチェンジにおいて、ＥＣ３Ａ、３Ｂおよび３Ｃによって指定され、依然として図７５に参照されるように、アカウントホルダー７５０２は、ＥＣを伝達する。このＥＣは、メッセージ（Ｍ３）およびデジタル署名（ＤＳ（Ｍ３）を含む。このインターチェンジにおいて、アカウントオーソリティ７５１２は、アカウントホルダーの意図の十分な証拠をメッセージ（Ｍ３）に付加されたように受信したことを満足しない。この理由のため、この例において、アカウントオーソリティ７５１２は、ＥＣ３Ｂをアカウントホルダー７５０２に送信する。ＥＣ３Ｂは、提示された新しいメッセージ（Ｍ４）をアカウントホルダー７５０２によってレビューおよびデジタル署名するために含む。メッセージ（Ｍ４）は、アカウントオーソリティ７５１２によって構成され、好適には、メッセージ（Ｍ３）に含まれる（すべてではないにしても）大抵の情報を含む。メッセージ（Ｍ４）は、さらに、メッセージ（Ｍ３）に含まれない追加の情報を含み得る。さらに、ＥＣ３Ｂは、アカウントホルダー７５０２がメッセージ（Ｍ４）のコンテンツを是認し受け入れる場合に、アカウントホルダー７５０２がメッセージ（Ｍ４）を、（ＥＣ３Ｂに示され、または、知られたプロトコールに基づく）特定の方法で変更して、変更されたメッセージ（ｍｏｄ−Ｍ４）を作成し、そして、次いで、その同一物をデジタル署名する（ＤＳ（ｍｏｄ−Ｍ４））ことを要求する。ファクタＢまたはＣエンティティ認証を実施することおよびＥＣ３Ｃ内にインジケーター（ＥＡＩ）を含むことは可能である。しかしながら、アカウントオーソリティ７５１２は、ＥＣ３Ｂにおいてそれを要求しないのでそれは要求されない。
【００７２】
（ｇ．ＡＢＤＳシステムにおけるＥＣのためのデータ構造およびフォーマット）
ここで、図７６を参照すると、本明細書において記載された本発明の種々の局面による電子通信（ＥＣ）７６０１は、種々のデータ領域、エレメント、または部分、概して、メッセージ（Ｍ）７６０３およびデジタル署名（ＤＳ）７６０５を含む。これらのコンポーネントは、概して、本明細書に記載された方法によるコンピューティングおよび通信装置を用いて格納され、通信され、または他の場合には、操作され得るデータ構造を形成する。ＥＣ７６０１は、ＩＳＯスタンダード８５８３による金融取引の一部に含まれ、および／または、それを形成し得る。このＩＳＯスタンダード８５８３は、本明細書において参考またはＸ９．５９取引として援用される。
【００７３】
既知のデータ通信フォーマットおよび／またはデータ構造協定により、ＥＣ７６０１は、通常、ヘッダー部７６０７、本体７６０９、およびトレーラー（ｔｒａｉｌｅｒ）部７６１１を含む。ヘッダー部７６０７およびトレーラー部７６１１は、性質上従来通りであり、当業者に知られているような、ＥＣの識別、ルーティング、エラー訂正、パケットカウンティングおよび他の目的等の従来の目的のために提供される。
【００７４】
本発明のこの局面の第一の構成により、本体部７６０９は、メッセージ７６０３およびデジタル署名７６０５（図においてハッシュされた線によって分離される）を備える。メッセージ７６０３は、好適には、アカウント識別子７６１６およびメッセージコンテンツ７６１８を含む。メッセージコンテンツは、さらなる識別子、アカウントに関するコマンドまたは命令（ｉ１）、アカウントに結び付けられた公開鍵（ＰｕＫ）、時間／日付スタンプ、暗号化されたメッセージその他等の種々の種類の情報を含み得る。デジタル署名７６０５は、送信者の秘密鍵で署名された、メッセージ７６０３（例えば、メッセージのハッシュ、メッセージそのもの、または圧縮物）、からの情報を備える。
【００７５】
第二の構成により、本体部７６０９は、アカウント識別子７６１６およびメッセージコンテンツ部７６１８を備える。このメッセージコンテンツ部７６１８は、デジタル署名７６０５を組み込む（ハッシュラインを無視する）。アカウント識別子７６１６は、メッセージコンテンツ７６１８から分離したコンポーネントであると考えられ得る。第一の構成に類似して、メッセージコンテンツ７６１８のデジタル署名７６０５の部分は、送信者の秘密鍵を用いて署名されたメッセージコンテンツ７６１８からの他の情報を備える。
【００７６】
上記構成のいずれかのもとで、ＥＣ７６０１は、アカウント識別子７６１６およびデジタル署名７６０５を重大なコンポーネントとして含む。
【００７７】
データエレメントの任意の構成のデジタル署名７６０５は、本発明のユーザによって企図される特定の用途に応じて、アカウント識別子、さらなる識別子、アカウントに関する命令またはコマンド、ＥＣの送信者の公開鍵（ＰｕＫ）、および／または他の情報等の情報を構成し得ることが理解される。以前に述べられたように、メッセージ７６０３は、アカウント識別子７６１６を含むことを必要とせず、例えば、アカウント識別子は、メッセージからほのめかされ、暗示され、または、取得される。例えば、ＥＣの受信側は、アカウント識別子７６１６を、ＥＣの送信者からの以前のメッセージから既に取得しておき得、アカウント識別子７６１６の再伝送は、必要とされない。さらに、例えば、命令がＥＣの送信者と受信側との間の通信においてインプリシットである場合に、メッセージ７６０３またはメッセージコンテンツ７６１８が命令またはコマンドを含むことは必要ではない。
【００７８】
最後に、本発明のこれらの電子通信およびデータ構造フォーマットはファイルフォーマット、構造、上記に記載されたコンテンツに制限されないことが留意されるべきである。異なるコンポーネントおよび構成を含む他のフォーマット、構造、およびコンテンツが、用いられ得る。
【００７９】
（ｈ．２者ＡＢＤＳシステムの特定のインプリメンテーション）
図２および３の好適なＡＢＤＳシステム２００、３００は、莫大な数の広範囲ビジネスアプリケーションにおいてインプリメントされ得る。特定のアプリケーションは、余りに多いため、以下の特定の例が、可能なインプリメンテーションの範囲および広さのみを示すために本明細書において詳細に記載され、ＡＢＤＳシステム２００、３００がインプリメントされ得るビジネスアプリケーションの種類についての制限があることは意図されない。さらに、各特定のビジネスアプリケーションを用いて使用される特定のデバイスが選択されるのは、単なる例示が目的であり、任意の他の図に示される（または示されない）他のデバイスが用いられ得ないことをほのめかすまたは提案することは意図されない。逆に、任意のデバイスが、形態に関わらず、すべてではないにしても、図２および３のＡＢＤＳシステム２００、３００を利用する大抵のビジネスアプリケーションにおいて用いられ得、このようなデバイスが操作できる利用可能な基礎構造のみによって制限される。
【００８０】
以下の例のすべてにおいて、アカウントホルダーは、ＡＢＤＳアカウントを、関連するアカウントオーソリティに既に設置している推定される。このため、アカウントオーソリティによって維持されるアカウントは、秘密鍵に対応する公開鍵をそれとともに結合している。この秘密鍵は、デバイスに安全に保護されており、このデバイスは、アカウントホルダーが所有している。以下の例のすべてにおいて、アカウントホルダーおよびアカウントオーソリティを含む、種々のエンティティ間の特定の通信のコンテンツを暗号化する必要がないことも推定される。しかしながら、エンティティのいくつかが、それらの間の種々のＥＳに含まれる情報のコンテンツをプライバシー機密性、または、任意の類似の理由のために保護するを望む場合、このようなＥＣは、従来の方法、例えば、ＰＧＰ型の暗号化のための、特定のＥＣの意図された受信側（単数または複数）の公開鍵を用いて、安全なソケット圧条法（ＳＳＬ）を用いて、または、他の類似の暗号化技術で、特定のＥＣの送信者によって暗号化され得る。しかしながら、種々のＥＣの暗号化は、本発明の機能化ために必要ではない。
【００８１】
さらに、以降に記載される特定のビジネスアプリケーションの多くにおいて、アカウントホルダーは、ファクタＢまたはファクタＣエンティティ認証を、ＥＣを構成し、それをアカウントオーソリティに伝送するプロセスの部分として実施することを促されるかまたは尋ねられる。デバイスの単なる使用は、ファクタＡエンティティ認証を提供するために十分であることが理解されるべきである（メッセージを認証すれば、本来的に、ＥＣの送信者が、メッセージを認証するために首尾よく用いられる公開鍵に対応する秘密鍵を所有することを確認することになるので）。これは、多くの環境において、アカウントオーソリティが、アカウントホルダーからのＥＣに含まれるメッセージまたは命令（ｉ１）上で活動するために十分なエンティティ認証である。ファクタＢおよび／またはファクタＣエンティティ認証の性能は、本発明のために不必要でありながら、アカウントホルダーによって提供されたエンティティ認証を強化し、そして、これに対応して、アカウントオーソリティがシステムにおいておよび適法なアカウントホルダーを扱っているという事実において有する信頼量を増加する。
【００８２】
さらに、ファクタＢおよび／またはファクタＣエンティティ認証がアカウントホルダー、デバイス、アカウントオーソリティ、および本明細書において記載されたＡＢＤＳシステム内の他のエンティティ間で管理される方法論は、これらのインプリメンテーションにおいて特に説明されない。このようなユーザまたは送信者認証が（上記のような）従来の方法または、ＶＳ出願に記載されたように操縦されることが想定されるべきである。
【００８３】
（ｉ．金融機関アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第一のビジネスアプリケーション６００が図６に示されている。この例において、個人を備えるアカウントホルダー６０２は、ＩＣカード、クレジットカード、またはＡＴＭ機６６０で用いられることできるＡＴＭカードその他等のカード６５０の形態でデバイスを所有する。カード６５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。ＡＴＭ機６６０は、ディスプレイ６６２、カードリーダ６６４、英数字キーパッド６６６、およびキャッシュディスペンサー６６８を含む。カード６５０は、金融機関６１２を含むアカウントオーソリティに維持されるデビットまたはクレジットアカウントに関連付けられる。アカウントは、当座預金、普通預金、マネーマーケットアカウント、クレジットカードアカウントその他であり得、金融機関は、銀行、貯蓄貸付組合、クレジットカード会社その他であり得る。この例では、ＡＴＭ機６６０は、安全な、内部のバンキングネットワーク６０８を介して金融機関６１２と電子通信する。
【００８４】
金融機関６１２に維持されるアカウントは、一以上のアカウントデータベース（図６にアカウントデータベース６１４によって総称されかつ例示される）内に維持されるアカウント記録に関連付けられる。図７を参照すると、各アカウントは、アカウント番号７１６を備える固有のアカウント識別子を含む。各アカウント番号７１６は、アカウントデータベース６１４内で、顧客特有の情報７４２およびアカウント特有の情報７４４を含むアカウント情報７４０を識別する。本発明により、アカウント番号７１６は、さらに、公開鍵情報７１８を識別する。この公開鍵情報７１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号７１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに関するデバイスプロファイル情報７７０を識別する。
【００８５】
図６の例において、顧客特有の情報７４２は、例えば、アカウントホルダーの名前、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報７４４は、例えば、現在の勘定残高、利用可能なクレジット、現行の計算書の閉鎖日および差額、および結び付けられたアカウント識別子を含む。アカウントホルダー６０２のアカウントの公開鍵情報７１８は、カード６５０内に保持される秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報７７０は、カード６５０に特有の情報を含む。
【００８６】
以前に述べられたように、アカウントホルダー６０２から金融機関６１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、および取引確認である。このビジネスアプリケーションでは、最も一般的なタイプのＥＣが、セッション認証ためにのみ用いられる。このセッション認証は、アカウントホルダー６０２が当初、ＡＴＭ機６６０にログインまたは他の方法でアクセスすることを試みる場合に発生する。
【００８７】
どの種類のＥＣがアカウントホルダー６０２から金融機関６１２へ通信されるかにかかわらず、メッセージを（アカウントホルダーの端部上で）構成およびデジタル署名するため、およびメッセージを認証しかつエンティティを（アカウントオーソリティ端部上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで、図８を参照すると、本発明による取引は、アカウントホルダー６０２がカード６５０をＡＴＭ機６６０のカードリーダ６６４に挿入する場合に図６および７に示されるインプリメンテーションにおいて開始される（ステップ８０２）。カード６５０の挿入は、ＡＴＭ機６６０を始動し、このＡＴＭ機６６０は、ディスプレイ６６２を用いて、アカウントホルダー６０２がエンティティ認証を実施するように指示する（ステップ８０４）。例えば、英数字キーパッド６６６を用いてＰＩＮを提供する。一旦、ＰＩＮが入力されると、電子メッセージが金融機関６１２に送信するために構成される（ステップ８０６）。
【００８８】
ＡＴＭ機６６０は、アカウントホルダー６０２が活動を実施し得る利用可能なアカウントのメニューを表示する。利用可能なアカウントは、カード６５０上のメモリ内に格納され、ＡＴＭ機６６０によってアカウントホルダー６０２に表示するために取り出される。当然、一つのアカウントのみがカード６５０上のメモリ内で利用可能である場合、アカウントは、アカウントホルダー６０２によって特定の選択を要求することなく、デフォルトによって選択される。
【００８９】
アカウントの選択の際、ＡＴＭ機６６０は、選択されたアカウント上で実施され得る操作メニューを表示する。このような操作は、例えば、金銭の引き出し、残高照会、計算書要求、振替、貨幣預金、紙幣支払いその他を含む。アカウントホルダー６０２による望みの操作の選択の際、およびそれに関する任意の追加の情報（引き出しまたは振替量その他等）がアカウントホルダー６０２から取得された後、ＡＴＭ機６６０は、アカウントホルダー６０２の望みの操作に対応する金融機関６１２への命令を含む電子メッセージを構成する。電子メッセージは、さらに、アカウントホルダー６０２によって選択されたアカウントに対応するアカウント番号７１６を含む。
【００９０】
メッセージは、次いで、アカウントホルダー６０２によってデジタル署名するためにカード６５０に伝送される（ステップ８０８）。これに関し、メッセージを表すデータの受信の際、カード６５０は、最初にデータのハッシュ値を計算し、次いで、カード６５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージについてのデジタル署名を生成する（ステップ８１０）。カード６５０は、次いで、デジタル署名をＡＴＭ機６６０に出力する（ステップ８１２）。ＡＴＭ機６６０は、次いで、ＥＣ内のメッセージおよびデジタル署名を金融機関６１２に伝送する（ステップ８１４）。
【００９１】
図９を参照すると、ＥＣは、金融機関６１２によってＡＴＭ機６６０から受信される（ステップ９０２）。金融機関６１２は、次いで、アカウントデータベース６１４からアカウント番号７１６によって識別された公開鍵を取り出す（ステップ９０４）。この公開鍵を用いて、金融機関６１２は、メッセージを認証することを試みる（ステップ９０６）。メッセージが公開鍵を用いて認証しない場合（ステップ９０８）、金融機関６１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答する（ステップ９１０）。メッセージが認証する場合（ステップ９０８）、金融機関６１２は、メッセージが、実際に、識別されたアカウント番号７１６に結び付けられた正しいカード６５０を所有する個人から来たと結論する（すなわち、ファクタＡエンティティ認証が取得される）。金融機関６１２は、次いで、ファクタＢエンティティ認証情報または提供された状態（例えば、ＰＩＮ）が特定のメッセージのさらなる処理のために十分かどうかを決定する（ステップ９１２）。十分でない場合、金融機関６１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）に応答する（ステップ９１０）。提供されたエンティティ認証が十分である場合（ステップ９１２）、金融機関６１２は、メッセージをさらに処理する（ステップ９１４）。
【００９２】
この場合、メッセージをさらに処理するステップ（ステップ９１４）は、メッセージの命令を実行するステップと、可能である場合、実行された命令に基づいてアカウントを更新するステップとを包含する。命令を実行することが可能でない場合、金融機関６１２は、メッセージの拒絶で応答する（ステップ９１０）。例えば、アカウントホルダー６０２が勘定残高を提供することを金融機関６１２に指示する場合、金融機関６１２は、アカウントホルダー６０２への提示のために勘定残高をＡＴＭ機６６０に伝送する。アカウントホルダー６０２がアカウントから金を引き出すことを金融機関６１２に指示する場合、金融機関６１２は、最初に、資金が利用可能であるかを確認し、そのようになっていれば、ＡＴＭ機６６０への要求された資金量（特定のアカウント上で許容されるおよび／または利用可能な上限まで）を分配することの認証をアカウントホルダー６０２に送信し、アカウント記録を、引き出しを反映するように更新する。場合、アカウントホルダー６０２が金融機関６１２に資金を別のアカウントに振替するように指示する場合、金融機関６１２は、最初に、資金が利用可能であること確認し、そのようになっていれば、他のアカウントへの電子資金の振替えを開始し、これにより、アカウント記録を更新する。アカウントホルダー６０２が金融機関６１２が、金融機関６１２に所有された紙幣上の支払い（クレジットライン支払い、クレジットカード支払い、抵当権者の支払いその他等）を受信することを指示する場合、金融機関６１２は、最初に、資金が利用可能であることを確認し。そのようになっていれば、アカウントから振替を開始し、これにより、アカウント記録を更新する。
【００９３】
当業者によって理解されるように、アカウントホルダー６０２が、多額の金の引き出しまたは振替またはアカウントの閉鎖等の「普通でない」取引を要求する場合、金融機関６１２は、アカウントホルダー６０２が特別な要求に対する取引確認の目的のためにＥＣをデジタル署名することを要求し得る。金融機関６１２は、さらに、アカウントホルダー６０２が追加のエンティティ認証情報または状態を、デジタル署名がカード６５０によって生成される前に提供することを要求し得る。ＡＴＭ機６６０は、イベントを正しく配列することに役立てるために用いられ得る。その結果、アカウントホルダー６０２は、最初に、ＡＴＭ機６６０のディスプレイ６６２上に表示された提案された確認メッセージ見て、次いで、シークレットまたは生物測定値を入力することを促される。その後、ＡＴＭ機６６０は、確認メッセージをカード６５０にデジタル署名のために提供する。このような取引確認ＥＣを生成および処理する残りの方法は、セッション認証のために上記に記載されたものと類似する。
【００９４】
（ｉｉ．手数料アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第二のビジネスアプリケーション１０００が、図１０に示されている。この例において、個人を備えるアカウントホルダー１００２は、携帯端末（ＰＤＡ）１０５０の形態でデバイスを所有する。ＰＤＡ１０５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。ＰＤＡ１０５０は、双方向表示画面１０５２およびユーザ入力キー１０５６を含む。さらに、ＰＤＡ１０５０は、無線通信ネットワーク１００８を介してデジタル通信するための無線モデムを適切に設けている。ＰＤＡ１０５０は、手数料会社１０１２によって表されるアカウントオーソリティを用いて維持される、手数料商取引、資産管理、およびクレジットアカウントに結び付けられている。手数料会社１０１２は、アカウントホルダー１００２の代理として売買のセキュリティのライセンスが供与され、ネットワーク１００８を介して無線通信が受信されるように装備されている。
【００９５】
手数料会社１０１２に維持されたアカウントは、図１０においてアカウントデータベース１０１４によって集約して参照されかつ示されるように、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図１１を参照すると、各アカウントは、アカウント番号１１１６を備える固有のアカウント識別子を含む。各アカウント番号１１１６は、アカウントデータベース１０１４内で、顧客特有の情報１１４２およびアカウント特有の情報１１４４を含むアカウント情報１１４０を識別する。本発明により、アカウント番号１１１６は、さらに、公開鍵情報１１１８を識別する。この公開鍵情報１１１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能によると、アカウント番号１１１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスのためのデバイスプロファイル情報１１７０を識別する。
【００９６】
図１０の例において、顧客特有の情報１１４２は、例えば、アカウントホルダーの名前、アドレス、社会保障番号および／または税識別番号を含む。アカウントに特有の情報１１４４は、例えば、アカウント状態、勘定残高、利用可能なクレジット、場合によっては、資産保有、係争中の取引、年間のキャピタルゲイン、結合されたアカウント識別子その他を含む。アカウントホルダー１００２のアカウントの公開鍵情報１１１８は、ＰＤＡ１０５０内に保持される秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報１１７０は、ＰＤＡ１０５０に特有の情報を含む。
【００９７】
以前に述べられたように、アカウントホルダー１００２から手数料会社１０１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、取引確認である。このビジネスアプリケーションにおいて、セッション認証のために用いられるＥＣは、通常、アカウントホルダー１００２が初期に、手数料会社１０１２のオンラインサイトにログインするまたは他の方法でアクセスすることを試みる場合に発生する。取引確認は、このビジネスアプリケーションにおいて、例えば、アカウントホルダー１００２が手数料会社１０１２に特別なセキュリティを売り買いするためことを特別に要求する場合に発生する。この場合、手数料会社１０１２は、ＰＤＡ１０５０を用いて（および好適には、シークレットまたは生物測定値の再投入を用いて）要求をデジタル署名することによって、アカウントホルダー１００２がこのような要求を確認することを要求する。
【００９８】
どの種類のＥＣがアカウントホルダー１００２から手数料会社１０１２に通信されるかに関わらず、メッセージを（アカウントホルダーの端部上で）構成およびデジタル署名するための、およびメッセージを認証し、そしてエンティティを（アカウントオーソリティの端部上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで図１２を参照すると、取引は、アカウントホルダー１００２が最初に、手数料会社１０１２のオンラインサイトへの無線接続を確立した場合、または、このような接続が既に確立された後、アカウントホルダー１００２がアカウントに関する情報を要求するかまたは手数料会社１０１２がアカウントに関する活動を実施すること要求する場合に開始される（ステップ１２０２）。次に、オンラインサイトは、ＰＤＡ１０５０にアカウントホルダー１００２が、ＰＩＮ等のファクタＢエンティティ認証情報を、必要な場合には、双方向ディスプレイ１０５２を用いて提供することを促させる（ステップ１２０４）。
【００９９】
一旦、ＰＩＮが入力されると、電子メッセージが手数料会社１０１２に送信するために構成される（ステップ１２０６）。最初のログインのために、メッセージは、単純に、関連するアカウント番号である。他の取引のために、メッセージは、アカウントホルダー１００２から手数料会社１０１２への命令（ｉ１）を含む。最初のログインのために、ＰＤＡ１０５０は、利用可能なアカウントのメニューを表示する。このようなアカウントは、手数料会社１０１２からまたはＰＤＡ１０５０上にこの目的のために予め格納されたソフトウェアから受信された通信に応答して表示される。好適には、利用可能なアカウントは、ＰＤＡ１０５０上のメモリ内に格納され、アカウントホルダー１００２へのディスプレイ１０５２上に選択のために提示される。当然、一つのアカウントのみがＰＤＡ１０５０上のメモリにおいて利用可能である場合、アカウントホルダー１００２によって特別の選択を要求することなく、該当するアカウントがデフォルトによって選択される。ログイン後の取引のために、ＰＤＡ１０５０は、選択されたアカウント上で実施され得る操作メニューを表示する。再度、オプションのこのメニューは、電子的接続がＰＤＡ１０５０と手数料会社１０１２との間になされる場合に、ＰＤＡ１０５０に予めプログラミングされ得るか、または、手数料会社１０１２からダウンロードされ得る。このような操作は、例えば、アカウント状態、勘定残高、利用可能なクレジット、現行の資産保有のリスト、または係争中の取引のリストについての要求またはセキュリティを購入するまたは販売する要求を含む。アカウントホルダー１００２による所望の操作の選択の際、およびそれに関する任意の追加の情報（例えば、特定のセキュリティの購入または販売の量および選択）がアカウントホルダー１００２から取得された後、ＰＤＡ１０５０は、アカウントホルダー１００２の所望の操作に対応する手数料会社１０１２への命令を含む電子メッセージを構成する。電子メッセージは、さらに、アカウントホルダー１００２によって選択されたアカウントに対応するアカウント番号１１１６を含む。
【０１００】
次に、ＰＤＡ１０５０は、最初に、データについてのハッシュ値を計算し、次いで、ＰＤＡ１０５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージのためにデジタル署名を作成する（ステップ１２０８）。ＰＤＡ１０５０は、次いで、メッセージおよびデジタル署名をＰＤＡ１０５０の無線モデムに出力する（ステップ１２１０）。このＰＤＡ１０５０は、ＥＣにおけるメッセージおよびデジタル署名を手数料会社１０１２に伝送する（ステップ１２１２）。
【０１０１】
図１３を参照すると、ＥＣは、手数料会社１０１２によってＰＤＡ１０５０から受信される（ステップ１３０２）。手数料会社１０１２は、次いで、アカウントデータベース１０１４から、アカウント番号１１１６によって識別された公開鍵を取り出す（ステップ１３０４）。公開鍵を用いて、手数料会社１０１２は、メッセージを認証することを試みる（ステップ１３０６）。公開鍵を用いてメッセージを認証しない場合（ステップ１３０８）、手数料会社１０１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）に応答する（ステップ１３１０）。メッセージを認証した場合（ステップ１３０８）、手数料会社１０１２は、メッセージが実際に、識別されたアカウント番号１１１６に結合された正しいＰＤＡ１０５０を所有する個人から来たことを結論する（すなわち、ファクタＡエンティティ認証が取得される）。手数料会社１０１２は、次いで、提供されたファクタＢエンティティ認証（例えば、ＰＩＮ）が特定のメッセージのさらなる処理のために十分であるかどうか決定する（ステップ１３１２）。十分でない場合、手数料会社１０１２は、メッセージの拒絶（例えば、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）に応答する（ステップ１３１０）。エンティティ認証が十分である場合（ステップ１３１２）、手数料会社１０１２は、メッセージをさらに処理する（ステップ１３１４）。
【０１０２】
本発明の例では、最初のセッション認証の後にメッセージをさらに処理するステップ（ステップ１３１４）は、アカウント記録の関連する部分（単数または複数）にアクセスするステップと、アカウントホルダー１００２に個人所有されたＰＤＡ上の歓迎ウェブサイト画面に表示するステップとを包含する。最初のログイン後にメッセージをさらに処理するステップは、命令を実行するステップと、（可能であれば）実行された命令に基づいてアカウント記録を更新するステップとを包含する。命令を実行することが可能でない場合、手数料会社１０１２は、メッセージの拒絶で応答する（ステップ１３１０）。例えば、アカウントホルダー１００２が手数料会社１０１２がアカウント状態、勘定残高、利用可能なクレジットの量、現行の資産保有のリスト、係争中の取引のリスト、または特定のセキュリティに関する情報を提供することを指示する場合、手数料会社１０１２は、要求された情報を取得し、ＰＤＡ１０５０の表示画面１０５２上にアカウントホルダー１００２に対して表示するために要求された情報をＰＤＡ１０５０に無線通信ネットワーク１００８を介して伝送する。アカウントホルダー１００２が手数料会社１０１２に、特定された価格での特定された数の証券の割り当て（ｓｈａｒｅ）を購入することを指示する場合、手数料会社１１０２は、最初に、購入のための資金が利用可能であることを確認し、そのようになっている場合、適切な「買い」注文を証券マーケットにおいて従来の方法で配置する。証券の購入が閉鎖している場合およびとき、アカウント記録は、これにより更新される（すなわち、購入された割り当ては、資産保有のリストに追加され、購入価格（プラス通信）は、アカウント貸方記入されるかまたは貸方記入される）。アカウントホルダー１００２が手数料会社１０１２が特定された価格での特定された数の証券の割り当て（ｓｈａｒｅ）を販売することを指示する場合、手数料会社１０１２は、最初に、特定の証券の割り当ての数がアカウントホルダー１００２によって所有され、販売されることができることを確認し、そのようになっていれば、適切な「売り」注文を証券マーケットに従来の方法で配置する。証券の販売が閉鎖している場合およびとき、アカウント記録は、これにより更新される（すなわち、販売された割り当ては、資産保有のリストから除去され、販売価格（マイナス手数料）がアカウントに貸し方記入される）。証券を売買するための命令について、手数料会社１０１２が確認取引を、要求された命令を実行する前に、上記のようにアカウントホルダー１００２から取得することは好適である。
【０１０３】
（ｉｉ．つけ払いサービスアカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第三のビジネスアプリケーション１４００が図１４に示されている。この例では、個人を含むアカウントホルダー１４０２は、携帯電話１４５０の形態でデバイスを所有する。携帯電話１４５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。携帯電話１４５０は、表示画面１４５２および番号パッド１４５６を含む。さらに、携帯電話１４５０は、無線通信ネットワーク１４０８を介する無線ボイスおよびデータ通信を適切に設けている。携帯電話１４５０は、つけ払いアカウント（これは、一以上の当座預金、クレジットカードアカウント等を含み得る）に結び付けられている。このつけ払いアカウントは、つけ払いサービス１４１２によって表されるアカウントオーソリティに維持される。つけ払いサービス１４１２は、アカウントホルダー１４０２の代理として、第三者につけを支払うことを認可され、ネットワーク１４０８を介して無線ボイスおよびデータ通信が受信されるように装備された自動化された電話センターを有する。
【０１０４】
アカウントホルダー１４０２が金を支払う義務がある種々の支払い先１４１０ａ、１４１０ｂが、さらに、図１４に示されている。好適には、支払い先１４１０ａ、１４１０ｂは、アカウントホルダー１４０２が定期的に且つ繰り返し支払うことを義務付けられた第三者である。支払い先１４１０ａ、１４１０ｂは、例えば、住宅金融専門会社、公益関係の会社、クレジットカードの会社、小売り売り手、デパートメントストア、医者の事務所、および典型的に、先月の間にアカウントホルダー１４０２によって負われた貸方記入のために一月を基礎にしてつけにする他の商品および／またはサービスプロバイダであり得る。この特定のビジネスアプリケーション１４００において、アカウントホルダー１４０２がつけ払いサービス１４１２に、記載日、つけの満期日、および各受け取り人１４１０ａ、１４１０ｂに支払わなければならないつけの量等のつけ情報を提供することが企図される。代替の実施形態において、支払い先１４１０ａ、１４１０ｂは、アカウントホルダー１４０２によってつけ情報を直接つけ払いサービス１４１２に提供することを認可され得る。このようなつけ情報は、経由専用の支払いネットワーク（ｖｉａ　ｄｅｄｉｃａｔｅｄ　ｐａｙｍｅｎｔ　ｎｅｔｗｏｒｋ）１４１１を含む任意の適切な手段によって伝送され得る。
【０１０５】
つけ払いサービス１４１２に維持されたアカウントは、図１４のアカウントデータベース１４１４によって集約して参照されかつ示された、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図１５を参照すると、各アカウントは、アカウント番号１５１６を備える固有のアカウント識別子を含む。各アカウント番号１５１６は、アカウントデータベース１４１４内で、顧客特有の情報１５４２およびアカウント特有の情報１５４４を含むアカウント情報１５４０を識別する。本発明により、アカウント番号１５１６は、さらに、公開鍵情報１５１８を識別する。この公開鍵情報１５１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能によると、アカウント番号１５１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスについてのデバイスプロファイル情報１５７０を識別する。
【０１０６】
図１４の例において、顧客特有の情報１５４２は、例えば、アカウントホルダーの名称、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報１５４４は、例えば、利用可能な支払いアカウントのリスト、それぞれのこのよう名支払アカウントに対する勘定残高、認可されたクレジットカード番号（単数または複数）、利用可能なクレジット、必要な場合、つけ払いサービス１４１２とともに、現在の貸借表、現在の状態リポート、アカウントホルダー１４０２によって登録された支払い先のリスト、各登録された支払い先に対する顧客アカウント番号およびつけアドレス、および各登録された支払い先の現在のつけ情報（利用可能な場合）その他を含む。アカウントホルダー１４０２のアカウントの公開鍵情報１５１８は、携帯電話１４５０内に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報１５７０は、携帯電話１４５０に特有の情報を含む。
【０１０７】
以前に述べられたように、アカウントホルダー１４０２からつけ払いサービス１４１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、および取引確認である。このビジネスアプリケーションにおいて、セッション認証のために用いられるＥＣは、通常、アカウントホルダー１４０２が、最初に、つけ払いサービス１４１２の自動化されたコールセンターにログインするまたは他の方法でアクセスすることを試みる発生する。取引確認は、このビジネスアプリケーションでは、例えば、アカウントホルダー１４０２が、つけ払いサービス１４１２が一定のつけを支払うことを特別に要求する場合に発生する。この場合、つけ払いサービス１４１２は、携帯電話１４５０を用いて要求をデジタル署名することによって（および、可能性としては、追加のエンティティ認証情報または状態を提供することによって）、アカウントホルダー１４０２がこのような要求を確認することを要求する。
【０１０８】
どの種類のＥＣがアカウントホルダー１４０２からつけ払いサービス１４１２に通信されたかに関わらず、メッセージを（アカウントホルダーの端部上で）構成およびデジタル署名するための、およびメッセージを認証し、そしてエンティティを（アカウントオーソリティ端部上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで、図１６を参照すると、取引は、アカウントホルダー１４０２がつけ払いサービス１４１２の自動化されたコールセンターへの無線フォンコールを設置するために携帯電話１４５０を使用する場合または、このような接続が設置された後、アカウントホルダー１４０２がアカウントに関する情報を要求するまたはつけ払いサービス１４１２がアカウントに関する活動を実施することを要求する場合に開始される（ステップ１６０２）。最初のログインのためまたは特別に要求された取引の確認のために、アカウントホルダー１４０２は、次に、携帯電話１４５０の番号パッド１４５６を用いて、ＰＩＮ等のファクタＢエンティティ認証情報を入力する（ステップ１６０４）。
【０１０９】
一旦、ＰＩＮが入力されると、つけ払いサービス１４１２に送信するために電子メッセージが構成される（ステップ１６０６）。第一のメッセージ（アカウント番号のみを含む）は、「＃」キー等の指定されたキー（または一連のキー）によって続行される携帯電話１４５０の番号パッド１４５６上のキーを押し下げるアカウントホルダー１４０２によって構成される。指定されたキーは、第一のメッセージが完全であることを示す。好適には、指定されたキー（または一連のキー）を押し下げることは、第一のメッセージが完全であることを携帯電話１４５０に通知するだけではなく、携帯電話１４５０にこの第一のメッセージについてのデジタル署名を作成させる（ステップ１６０８）。次に、携帯電話１４５０は、ＥＣにおけるメッセージおよびデジタル署名をつけ払いサーボス１４１２に無線通信ネットワーク１４０８を介して伝送する（ステップ１６１０）。
【０１１０】
ここで、図１７を参照すると、この最初のＥＣは、つけ払いサービス１４１２によって携帯電話１４５０から取り出される（ステップ１７０２）。つけ払いサービス１４１２は、アカウントデータベース１４１４から、アカウント番号１５１６によって識別された公開鍵を取り出す（ステップ１７０４）。この公開鍵を用いて、つけ払いサービス１４１２は、メッセージを認証することを試みる（ステップ１７０６）。メッセージが認証しない場合（ステップ１７０８）、つけ払いサービス１４１２は、ＥＣの拒絶とともにＥＣの送信者に応答する（ステップ１７１０）。このような応答は、つけ払いサービス１４１２によって望まれた場合、拒絶に対する理由を示し得る。他方、メッセージが認証する場合（ステップ１７０８）、つけ払いサービス１４１２は、メッセージは、実際に、識別されたアカウント番号１５１６に結び付けられた正しい携帯電話１４５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される。）つけ払いサービス１４１２は、次いで、提供されたファクタＢエンティティ認証（例えば、ＰＩＮ）が特定メッセージのさらなる処理のために十分かどうかを決定する（ステップ１７１２）。十分でない場合、つけ払いサービス１４１２は、メッセージの拒絶（例えば、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答し（ステップ１７１０）、そして、再度、このような応答が拒絶に対する理由を示し得る。エンティティ認証（ステップ１７１２における）が十分な場合、つけ払いサービス１４１２は、メッセージをさらに処理する（ステップ１７１４）。
【０１１１】
本発明の例では、メッセージをさらに処理するステップ（ステップ１７１４）は、アカウント番号１５１６のみを含むメッセージに応答して、今識別されるアカウント１５１６上で実施され得るオプションのメニューを有するアカウントホルダー１４０２への自動化された電話による応答である。
【０１１２】
図１６を再度参照すると、自動化された電話による応答の提示は、つけ払いメッセージを生成するプロセス（ステップ１６１２）を開始する。この特定の例示において、自動化された電話による応答は、アカウントホルダー１４０２に以下のことを提示する。：「つけを払うために１を押し、登録された支払い先のために新しいつけの支払い満期日をスケジューリングするために２を押し、新しい支払い先を登録するために３を押す」。アカウントホルダー１４０２は、次いで、完全なつけ払い取引がつけ払いサービス１４１２によって定式化され得るまで、携帯電話１４５０上のメニューオプションの階層を通って導かれる。好適には、デジタル署名は、メニュー選択／メッセージ生成プロセス間に生成されるまたは送信される必要はない。メニュー選択の完了の際、つけ払いサービス１４１２は、聞こえるように、アカウントホルダー１４０２に提案された支払い取引を提示する。番号（＃）キーは、単なる例示目的のための以下の例に用いられる。しかしながら、任意の他のキー、キーの配列、または電話の操作が、代替として用いられ得ることが理解されるべきである。例えば、アカウントホルダー１４０２が最初にオプション１（つけを払うため）に選択される場合、提案された命令は、「あなたは、我々が［支払い先１］に５１．００ドルの額を１９９８年１１月４日に、１９９８年１０月２２日付のつけに対して払うことを要求した。参照として、［支払い先１］顧客アカウント番号は、０１２−００００９−００３であり、あなたの支払いアカウントは、＃０１−００９０００−０１０を用いる。これが正しい場合、電話上の番号（＃）キーを押して下さい。」であり得る。アカウントホルダー１４０２が最初にオプション２（登録された支払い先に新しいつけを入力するために）を選択した場合、提案された命令は、「あなたは、我々が〔支払い先１〕への支払い予定を５１．００ドルの額で、１９９８年１１月２２日当日またはそれ以前を予定し、１９９８年１０月２２日付のつけに対してスケジューリングすることを要求した。参照として、［支払い先１］顧客アカウント番号は、０１２−００００９−００３である。これが正しい場合、電話上の番号（＃）キーを押して下さい」であり得る。アカウントホルダー１４０２が最初にオプション３（新しい支払い先を登録するために）を選択した場合、提案される命令は、「あなたは、我々が［支払い先１］をあなたの登録された支払い先のリストに加えることを要求した。あなたは、［支払い先１］を有するあなたの顧客アカウント番号は、１２−００００９−００３であり、［支払い先１］のつけのアドレスは、１２３　Ｍａｉｎ　Ｓｔ，ＡｎｙＴｏｗｎ，ＡｎｙＳｔａｔｅ０１２３４であることを示した。これが正しい場合、電話上の番号（＃）キーを押して下さい」であり得る。
【０１１３】
アカウントホルダー１４０２が、この音声案内の後に番号（＃）キー以外の任意のキーを押す場合、提案された命令は、受け入れられず（ステップ１６１４）、メニューアイテムの選択を通じたメッセージを構成するプロセス（ステップ１６１２）が継続する。他方、アカウントホルダー１４０２が上記音声案内の一つ後に携帯電話１４５０上の番号（＃）キーを押す場合、提案された支払い取引は、受け入れられ（ステップ１６１４）、携帯電話１４５０は、提案された支払い取引についてのデジタル署名を作成する（ステップ１６１６）。デジタル署名されたメッセージは、受け入れられた提案された支払い取引のデジタル音声ファイル（これは、携帯電話１４５０上のＲＡＭに一時的に格納され得る）であり得るか、または、つけ払いサービス１４１２は、メッセージを携帯電話１４５０に、最後のメニュー選択に応答して押された番号（＃）キーに応答したデジタル署名として伝送し得る。いずれの場合でも、携帯電話１４５０は、次いで、ＥＣにおけるメッセージおよびデジタル署名をつけ払いサービス１４１２に無線通信ネットワーク１４０８を介して伝送する（ステップ１６１８）。
【０１１４】
すぐ上方に記載されたように、デジタル署名されたメッセージは、番号（＃）キーを押すことによってアカウントホルダー１４０２により受け入れられたときの提案された命令のデジタル音声ファイルであり得る。本発明のこの局面の代替の実施形態において、提案された命令を受け入れるために番号（＃）キーを押すよりも、アカウントホルダー１４０２は、口頭で提案された命令を受け入れるか、または、口頭で命令を構成する。これは、デジタルファイルとして、携帯電話１４５０上のＲＡＭに一時的に格納され、この命令に対して、デジタル署名が、次いで、携帯電話１４５０によって作成される。
【０１１５】
再度、図１７を参照すると、アカウントホルダー１４０２から受信された支払い取引のＥＣに応答してつけ払いサービス１４１２によって実施されるステップは、本質的に、アカウントのみのＥＣに応答して実施されたものと同一である。しかしながら、主要な相違は、ステップ１７１４にある。このステップ１７１４の間、つけ払いサービス１４１２は、支払い命令を実施またはその実施を試みることによって、支払い取引のメッセージをさらに処理する。命令を実施するステップは、通常、アカウント記録の関連する部分（単数または複数）にアクセスするステップと、（可能であれば）命令を実行するステップと、実行された命令に基づいてアカウント記録を更新するステップとを包含する。命令を実行することが可能でない場合、つけ払いサービス１４１２は、メッセージの拒絶で応答する（ステップ１７１０）。例えば、アカウントホルダー１４０２がつけ払いサービス１４１２につけを払うことを指示する場合、つけ払いサービス１４１２は、（メールまたは支払いネットワーク１４１１を通じた電子転送によって）スケジューリングされた支払い日に支払いがなされるようにスケジューリングし、資金が現在、アカウントホルダー１４０２によって特定された支払いアカウント１５１６から利用可能であることを確認する。資金が確認時に別に取って置かれ得るか、つけ払いサービス１４１２が特定された支払いアカウント１５１６からの資金の利用可能性をスケジューリングされた支払い日に再確認し得るかのいずれかである。スケジューリングされた支払い日に、資金が利用可能である場合、つけ払いサービス１４１２は、資金を指定された支払い先にメールまたは電子的に転送し、これにより、アカウント記録を更新する。アカウントホルダー１４０２が、つけ払いサービス１４１２が、登録された支払い先に支払わなければならない新しいつけをスケジューリングすることを単に指示する場合、つけ支払いサービス１４１２は、これにより、アカウント記録を単に更新する。同様に、アカウントホルダー１４０２がつけ払いサービス１４１２が新しい支払い先をアカウントホルダーの登録された支払い先のリストに追加することを単に指示する場合、つけ払いサービス１４１２は、これにより、アカウント記録を単に更新する。
【０１１６】
（ｉｖ．クレジット事務局アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第四のビジネスアプリケーション１８００が図１８に示されている。この例では、個人を含むアカウントホルダー１８０２は、ケーブル１８６５を介してパーソナルコンピュータ１８６０の適切なポート（ＵＳＢ、シリアル、パラレル、等）に接続されたドングル１８５０の形態でデバイスを所有する。ドングル１８５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。パーソナルコンピュータ１８６０は、モニタ１８６２、キーパッド１８６４、およびマウス１８６６を含む点で従来通りである。ドングル１８５０は、他のアカウントの中で、クレジット事務局１８１２によって表わされたアカウントオーソリティによって維持されたパーソナルクレジットリポートアカウントに結び付けられている。コンピュータ１８６０は、モデムを介する、ＬＡＮライン等の従来の方法で、クレジット事務局１８１２によって主催される安全なウェブサイトに、インターネット１８０８を介して通信することが可能にするためにインストールされた適切なウェブブラウザソフトウェアを有する。
【０１１７】
クレジット事務局１８１２によって維持されたアカウントは、図１８のアカウントデータベース１８１４に集約して参照され、かつ示される一以上のアカウントデータベースにおいて維持されたアカウント記録に関連付けられる。図１９を参照すると、各アカウントは、アカウント番号１９１６を備える固有のアカウント識別子を含む。各アカウント番号１９１６は、アカウントデータベース１８１４内で、顧客特有の情報１９１４およびアカウント特有の情報１９４４を含むアカウント情報１９４０を識別する。本発明により、アカウント番号１９１６は、さらに、公開鍵情報１９１８を識別する。この公開鍵情報１９１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能によると、アカウント番号１９１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスについてのデバイスプロファイル情報１９７０を識別する。
【０１１８】
図１８の例において、顧客特有の情報１９４２は、例えば、アカウントホルダーの名称、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報１９４４は、例えば、アカウントのリスト、各アカウント上の支払い履歴、各アカウント上の過去の満期量、場合によっては、総負債、クレジットソース、全体のクレジット状態のリポートその他を含む。アカウントホルダー１８０２のアカウントの公開鍵情報１９１８は、ドングル１８５０内に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報１９７０は、ドングル１８５０に特有の情報を含む。
【０１１９】
以前に述べられたように、アカウントホルダー１８０２からクレジット事務局１８１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、および取引確認である。例えば、共通の種類のセッション認証は、このビジネスアプリケーションにおいて、アカウントホルダー１８０２が最初に、クレジット事務局１８１２によって維持された安全なウェブサイトにログインするまたは他の方法でアクセスすることを試みる場合に発生する。さらなる種類のセッションエンティティ認証は、アカウントホルダー１８０２が特定の記録へのアクセスまたはアカウントホルダー１８０２にとって非常に敏感な、安全な、機密性の、またはプライベートな情報の部分を要求する場合に発生する。この場合、クレジット事務局１８１２は、安全なウェブサイトに単にアクセスするために要求されるよりも強いレベルのエンティティ認証を要求し得る。取引確認は、例えば、アカウントホルダー１８０２がクレジット事務局１８１２に、クレジット事務局１８１２によって維持されたアカウントにおける情報を追加または変更することを要求する場合に、このビジネスアプリケーションに適用可能である。この場合、クレジット事務局１８１２は、アカウントホルダー１８０２に、ドングル１８５０を用いて要求をデジタル署名することによってこのような取引を確認することを要求する。
【０１２０】
どの種類のＥＣがアカウントホルダー１８０２からクレジット事務局１８１２に通信されたかに関わらず、メッセージを（アカウントホルダー側上で）構成およびデジタル署名するための、およびメッセージを認証し、エンティティを（アカウントオーソリティ側上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで図２０を参照すると、取引は、アカウントホルダー１８０２が最初にコンピュータ１８６０を用いるインターネット１８０８を介してクレジット事務局１８１２のウェブサイトにアクセスする場合または、このようなアクセスがすでに確立された後、アカウントホルダー１８０２が特定の情報へのアクセスを要求するかまたはクレジット事務局１８１２がアカウント上で活動を実施することを要求する場合に開始される（ステップ２００２）。次に、ウェブサイトは、コンピュータ１８６０を促して、アカウントホルダー１８０２が、キーパッド１８６４を用いて、ＰＩＮ等のファクタＢエンティティ認証情報を入力するようにさせる（ステップ２００４）。
【０１２１】
一旦、ＰＩＮが入力されると、電子メッセージが、クレジット事務局１８１２に送信するために構成される（ステップ２００６）。最初のログインのために、メッセージは、単純に、関連のアカウント番号である。続く取引のために、メッセージは、アカウントホルダー１８０２からクレジット事務局１９１２への命令（ｉ１）を含む。最初のログインのために、コンピュータ１８６０は、モニタ１８６２上に、アカウント番号データ入力領域を含むデータ入力画面を表示する。続く取引のために、コンピュータ１８６０は、モニタ１８６２上に、追加のデータ入力または「生成」選択ボタンを含むデータ入力画面を表示する。この「生成」選択ボタンを用いて、アカウントホルダー１８０２は、「クレジットリポートの提供」、「クレジットスコアを提供する」、「総負債を提供する」、「追加の情報を提示する」、または「リポートエラー」等の開始したい取引の種類を選択することができる。一旦、任意の必要なデータ領域が満たされ、命令が選択される（適用可能な場合）と、アカウントホルダー１８０２は、マウス１８６６を用いてデータ入力画面上にさらに表示される「デジタル署名」ボタンを活性にする。
【０１２２】
このボタンを選択することによって、コンピュータ１８６０は、データ入力領域に入力されたデータを束にし、メニューを単一のメッセージにプルダウンする。このメッセージは、次いで、アカウントホルダー１８０２によってデジタル署名するために、ケーブル１８６５を介してコンピュータ１８６０からドングル１８５０に伝送される（ステップ２００８）。これに関して、メッセージを表すデータの受信の際、ドングル１８５０は、最初にデータに対するハッシュ値を計算し、次いで、ドングル１８５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ２０１０）。ドングル１８５０は、次いで、デジタル署名を出力する（ステップ２０１２）。このデジタル署名は、コンピュータ１８６０によって受信される。コンピュータ１８６０は、次いで、ＥＣにおけるメッセージおよびデジタル署名をクレジット事務局１８１２に伝送する（ステップ２０１４）。
【０１２３】
図２１を参照すると、ＥＣは、クレジット事務局１８１２によってコンピュータ１８６０から受信される（ステップ２１０２）。クレジット事務局１８１２は、次いで、アカウントデータベース１８１４からアカウントホルダー１９１６（または名称または社会保障番号等の他の固有の識別子）によって識別された公開鍵取り出す（ステップ２１０４）。この公開鍵を用いて、クレジット事務局１８１２は、メッセージを認証することを試みる（ステップ２１０６）。公開鍵を用いてメッセージが認証しない場合（ステップ２１０８）、クレジット事務局１８１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答する（ステップ２１１０）。メッセージが認証する場合（ステップ２１０８）、クレジット事務局１８１２は、メッセージは、実際に、識別されたアカウント番号１９１６に結び付けられた正しいドングル１８５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される。）クレジット事務局１８１２は、次いで、提供されたファクタＢエンティティ認証（例えば、ＰＩＮ）が特定のメッセージをさらに処理するために十分かどうか決定する（ステップ２１１２）。十分でない場合、クレジット事務局１８１２は、メッセージの拒絶（例えば、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）に応答し（ステップ２１１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ２１１２における）、クレジット事務局１８１２は、メッセージをさらに処理する（ステップ２１１４）。
【０１２４】
本発明の例では、最初のセッション認証の後にメッセージをさらに処理するステップ（ステップ２１１４）は、アカウント記録の関連部分（単数または複数）にアクセスするステップと、アカウントホルダー１８０２に個人所有されたコンピュータ１８６０上に歓迎ウェブサイト画面を表示するステップとを包含する。最初のログイン後にメッセージをさらに処理するステップは、アカウント記録の関連部分（単数または複数）にアクセスするステップと、命令を（可能であれば）実行するステップと、実行された命令に基づいてアカウント記録を更新するステップとを包含する。命令を実行することが可能でない場合、クレジット事務局１８１２は、メッセージの拒絶で応答する（ステップ２１１０）。例えば、アカウントホルダー１８０２がクレジット事務局１８１２に全部のクレジットリポート、クレジットスコア、または全負債計算を提供することを指示する場合、クレジット事務局１８１２は、関連する情報を取得するためにアカウントデータベース１８１４にアクセスする。この関連する情報は、次いで、アカウントホルダー１８０２へのモニタ１８６２上の表示のためにコンピュータ１８６０に伝送される。アカウントホルダー１８０２がクレジット事務局１８１２に、アカウントデータベース１８１４に含めるための追加の情報を提示することを望むことを指示する場合、クレジット事務局１８１２は、アカウントホルダー１８０２が新しい情報を提示し得る新しいデータ加入ページを提供する。この新しいデータ加入ページは、ドングル１８５０を用いてデジタル署名され、上記と同じ方法でクレジット事務局１８１２に伝送される新しいメッセージを構成する。同様に、アカウントホルダー１８０２がクレジット事務局１８１２に、クレジットレポートまたはアカウントデータベースにおけるエラーを報告すること望むことを指示する場合、クレジット事務局１８１２は、アカウントホルダー１８０２が申し立てられたエラーを報告し得る新しいデータ加入ページを、アカウントホルダー１８０２に提供する。この新しいデータ加入ページは、ドングル１８５０を用いてデジタル署名され、上記と同じ方法でクレジット事務局１８１２に伝送された新しいメッセージを構成する。一旦、クレジット事務局１８１２が、新しい情報または申し立てられたエラー通知をアカウントホルダー１８０２から受信すると、問題への調査を開始する。情報が正確であるように見える場合、アカウントデータベース１８１４における適切な記録（単数または複数）がこれにより更新される。上記命令のいくつかのために、クレジット事務局１８１２が、要求された命令を実行する前に、上記のように確認取引をアカウントホルダー１８０２から取得することは好適である。
【０１２５】
（ｖ．患者／個人医療記録アカウント）
図２の２者ＡＢＤＳシステム２００インプリメントする第五のビジネスアプリケーション２２００が図２２に示されている。この例では、患者２２０２を含むアカウントホルダーは、ＩＣカード等のカード２２５０の形態でデバイスを所有する。カード２２５０は、公開−秘密鍵の対の秘密鍵を安全に保護し、カードリーダ２２５２に用いられることが可能である。カードリーダ２２５２は、英数字キーパッド２２５６、ディスプレイ２２５４、および親指の指紋のリーダ２２５８を含む。カードリーダ２２５２は、ケーブル２２６５を介してパーソナルコンピュータ２２６０の適切なポート（ＵＳＢ、シリアル、パラレル等）に接続される。パーソナルコンピュータ２２６０は、モニタ２２６２、キーパッド２２６４、およびマウス２２６６を含む点で従来通りである。当業者に理解されるように、デジタル署名されるメッセージを表示するためにカードリーダ２２５２のディスプレイ２２５４を用いることおよびエンティティ認証情報を患者２２０２から受信するためにカードリーダ上のキーパッド２２５６および親指の指紋のリーダ２２５８を用いることは、モニタ２２６２およびキーパッド２２６４を用いてコンピュータ２２６０上に同じ情報が表示され入力された場合より大きいセキュリティ、およびより低い不正の可能性を提供する。
【０１２６】
カード２２５０は、アカウントの中でも特に、患者２２０２に特に結び付けられ、かつ、医療記録アクセス番号２１１２によって表わされたアカウントオーソリティによって維持される医療記録のアカウントに関連付けられる。コンピュータ２２６０は、直接、医療記録アクセスマネジャー２２１２を用いて接続され、医療記録アクセスマネジャー２２１２に登録された患者にアクセスし、医療記録アクセスマネジャー２２１２によって維持された個人の医療記録の選択された部分を見ることを可能にするためにインストールされた顧客ソフトウェアを有する。
【０１２７】
医療記録アクセスマネジャー２２１２に維持されたアカウントは、図２２のアカウントデータベース２２１４に集約して参照され示された、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図２３を参照すると、各アカウントは、固有のアカウント識別子をアカウント番号２３１６として含む。各アカウント番号２３１６は、アカウントデータベース２２１４内で、顧客特有の情報２３４２およびアカウント特有の情報２３４４を含むアカウント情報２３４０を識別する。本発明により、アカウント番号２３１６は、さらに、公開鍵情報２３１８を識別する。この公開鍵情報２３１８は、それぞれのアカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号２３１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスについてのデバイスプロファイル情報２３７０を識別する。
【０１２８】
図２２の例において、図２３に示された顧客特有の情報２３４２は、例えば、患者２２０２の名称、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報２３４４は、例えば、現在の医者リスト、現在の保健情報、医療プロファイルおよび履歴、既知のアレルギー、主要な医療状況、組織ドナー情報その他を含む。患者２２０２のアカウントの公開鍵情報２３１８は、カード２２５０内に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報２３７０は、カード２２５０に特有の情報を含む。
【０１２９】
以前に述べられたように、患者２２０２から医療記録アクセスマネジャー２２１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、および取引確認である。例えば、共通の種類のセッション認証は、このビジネスアプリケーションにおいて、患者２２０２が最初に、コンピュータ２２６０上で維持された医療記録アクセスソフトウェアにログインするかまたは他の方法でアクセスすることを試みる場合に発生する。さらに、セッション認証は、患者２２０２が特定の記録または患者にとって非常に敏感な、安全な、機密性の、またはプライベートの情報の部分へのアクセスを要求する場合に発生する。この場合、医療記録アクセスマネジャー２２１２は、関連のソフトウェアに単にアクセスするために要求されたよりも強いレベルのエンティティ認証（例えば、親指の指紋のリーダ２２５８を用いるファクタＣ）を要求し得る。取引確認は、このビジネスアプリケーションにおいて（上記のいずれかのセッションの間）、例えば、医療記録データベース内に含まれる患者の情報に関する活動（例えば、更新する、追加する、削除する、またはこのような情報を転送する）を実施するために、患者２２０２が医療を記録アクセスマネジャー２２１２に要求し、医療記録アクセスマネジャー２２１２が患者２２０２に、カード２２５０を用いて要求をデジタル署名すること（および、可能性として、さらに、追加のファクタＢまたはＣエンティティ認証情報または状態を提供すること）によってこのような要求を確認することを要求する場合に適用可能である。
【０１３０】
どの種類のＥＣが患者２２０２から医療記録アクセスマネジャー２２１２へ通信されるかに関わらず、メッセージを（患者側上で）構成およびデジタル署名するための、およびメッセージを認証し、エンティティを（医療記録アクセスマネジャー側上で）認証するため基本的な方法論は、本質的に同一である。例えば、ここで、図２４を参照すると、本発明によるＥＣは、医療記録のソフトウェアにアクセスするために患者２２０２が最初にコンピュータ２２６０にログインすることを試みる場合、または、このようなログインが既に首尾よく完了した後に、患者２２０２が敏感な患者情報を要求するかまたは医療記録アクセスマネジャー２２１２が患者のアカウントに関する活動を実施することを要求する場合に開始される（ステップ２４０２）。いずれの場合にも、カードがまだ提供されていない場合に、コンピュータ２２６０は、患者２２０２を促して、カード２２５０をカードリーダ２２５２に（例えば、リーダ２２５２が「コンタクト」タイプのリーダであれば、カード２２５０を挿入することによって、または、リーダが「コンタクトレス」タイプのリーダである場合にカード２２５０をリーダ２２５２の近接位置に持っていくことによって）提供させる（ステップ２４０４）。コンピュータ２２６０は、次いで、患者２２０２を促して、英数字キーパッド２２５６および／または親指の指紋のリーダ２２５８を用いてファクタＢおよび／またはＣエンティティ認証情報を提供させる（ステップ２４０６）。一旦、このようなエンティティ認証情報が提供されると、電子メッセージが、医療記録アクセスマネジャー２２１２に送信するために構成される（ステップ２４０８）。この場合、システムへのアクセスを単に要求する最初のＥＣによって、メッセージは、医療記録アクセスマネジャー２２１２によって維持されたアカウントに結び付けられた単なるアカウント番号２３１６である。好適には、リーダ２２５２は、ディスプレイ２２５４上に、患者２２０２が選択し得る利用可能なアカウントのメニューを表示する。好適には、このような利用可能なアカウントは、カード２２５０上のメモリ内に格納され、患者２２０２による選択のためにリーダ２２５２によって取り出される。当然、一つのみのアカウントがカード２２５０上のメモリにおいて利用可能である場合、そのアカウントは、患者２２０２による特定の選択を要求することなく、デフォルトによって選択される。続く取引のために、患者２２０２は、（コンピュータ２２６０上で）何の情報を見たいか、または、医療記録アクセスマネジャー２２１２に何の活動を実施させたいかを選択することが可能である。
【０１３１】
いずれの場合にも、一旦コンピュータ２２６０がメッセージを構成すると、ディスプレイ２２５４上での表示のため、および、患者２２０２によってデジタル署名するためにカード２２５０に転送するためにそれはカードリーダ２２５２に伝送される（ステップ２４１０）。これに関して、メッセージを表すデータの受信の際、カード２２５０は、最初にデータについてのハッシュ値を計算し、次いで、カード２２５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ２４１２）。カード２２５２は、次いで、デジタル署名をメッセージと共にＥＣとしてコンピュータ２２６０に伝送する（ステップ２４１６）。このコンピュータ２２６０は、同一物を医療記録アクセスマネジャー２２１２に認証のために転送する。
【０１３２】
図２５を参照すると、ＥＣは、医療記録アクセスマネジャー２２１２によってコンピュータ２２６０から受信される（ステップ２５０２）。医療記録アクセスマネジャー２２１２は、次いで、アカウントデータベース２２１４からアカウント番号２３１６によって識別される公開鍵を取り出す（ステップ２５０４）。この公開鍵を用いて、医療記録アクセスマネジャー２２１２は、メッセージを認証することを試みる（ステップ２５０６）。メッセージが認証しない場合（ステップ２５０８において）、医療記録アクセスマネジャー２１２は、メッセージの拒絶（すなわち、ウェブサイトへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答する（ステップ２５１０）。このような応答は、拒絶に対する理由を示し得る。メッセージが認証する場合（ステップ２５０８）、医療記録アクセスマネジャー２２１２は、メッセージが、実際に、識別されたアカウント番号２３１６に結び付けられた正しいカード２２５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される。）医療記録アクセスマネジャー２２１２は、次いで、提供されたファクタＢおよび／またはＣエンティティ認証（例えば、ＰＩＮおよび／または親指の指紋）が特定のメッセージをさらに処理するために十分かどうか決定する（ステップ２５１２）。十分でない場合、医療記録アクセスマネジャー２２１２は、メッセージの拒絶で応答し（ステップ２５１０）、そして、再度、このよう応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ２５１２において）、医療記録アクセスマネジャー２２１２は、メッセージをさらに処理する（ステップ２５１４）。
【０１３３】
最初のログインのために、メッセージをさらに処理することは、患者２２０２に、コンピュータ２２６０上の記録アクセスプログラムへのアクセスおよび、患者２２０２に属するプライベートであるが慎重さが必要な情報を見る権利を提供することを単に意味する。この情報は、データベース２２１４に維持されて、適切な問い合わせに応答して、コンピュータ２２６０上の顧客のソフトウェアを用いて表示される。メッセージが患者２２０２による、患者２２０２に属する慎重さが必要な情報にアクセスする要求である場合、医療記録アクセスマネジャー２２１２は、より強いエンティティ認証情報を患者２２０２から要求し得る（このような慎重さが必要な情報を認可されていない人に表示するための、増加されたリスクおよび潜在的な負担に起因する）したがって、この状況において、コンピュータ２２６０は患者２２０２を促して（ステップ２４０６）、ＰＩＮおよび親指の指紋の両方を提供させる。決定（ステップ２５１２）がこの状況においてポジティブである場合、さらに処理するステップ（ステップ２５１４）は、患者２２０２に要求された、慎重さが必要な情報へのアクセスを提供するステップを包含する。ＥＣが、医療記録アクセスマネジャー２２１２が、アカウントに関して、または、アカウントに含まれる情報に関して活動を実施する患者２２０２による要求、例えば、特定の医療記録、リポート、または、病院、保険会社、または、医療実務家等の第三者への情報の転送する要求を含む場合、このようなＥＣは、図２４および２５に一般的に記載されるように処理され得る。しかしながら、上記二つのＥＣと対照的に、デジタル署名を患者２２０２から取得する目的は、エンティティ認証のためだけでなく、主として、要求された活動の「確認」のためである。このシナリオでは、提供されたエンティティ認証情報または状態が十分である（ステップ２５１２において決定されたように）場合、メッセージをさらに処理するステップは、要求された活動の性能を含む。
【０１３４】
（ｖｉ．（医療）診療管理アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第六のビジネスアプリケーション２６００が図２６に示されている。この例では、医療専門家２６０２を備えるアカウントホルダーは、時計（示されるような）、宝石類、キーリング等のパーソナルアイテム２６５０の形態でデバイスを所有する。このパーソナルアイテム２６５０は、無線周波数（ＲＦ）データ伝送をＲＦ受信機／送信機２６５２に送受信することが可能である。パーソナルアイテム２６５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。この例では、ＲＦ受信機／送信機２６５２は、ケーブル２６６５を介してパーソナルコンピュータ２６６０の適切なポート（ＵＳＢ、シリアル、パラレル等）に接続されている。パーソナルコンピュータ２６６０は、モニタ２６６２、キーパッド２６６４、およびマウス２６６６を含む点で従来通りである。本発明の例では、コンピュータ２６６０は、さらに、医療専門家２６０２の声等の音声入力の受信のためのマイクロフォン２６６８をエンティティ認証目的のために含む。
【０１３５】
パーソナルアイテム２６５０は、アカウントの中でも特に、医療診療管理サーバ２６１２によって表わされたアカウントオーソリティによって維持された医療診療管理アカウントに結び付けられている。コンピュータ２６６０は、適切なデータベース管理およびアクセスソフトウェアをインストールして、例えば、内部または外部ネットワーク２６０８（この場合、内部ネットワーク）を介してサーバ２６１２によって維持されるアカウントデータベースに含まれる情報を相互作用することを可能にする。
【０１３６】
サーバ２６１２によって維持されたアカウントは、図２６のアカウントデータベース２６１４によって集約して参照され示される、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図２７を参照すると、アカウントデータベース２６１４の各認可されたユーザは、アカウント番号２７１６を含む固有のアカウント識別子によって識別される。各アカウント番号２７１６は、アカウントデータベース２６１４内で、エンティティ特有の情報２７４２およびアクセス可能なデータベース２７４４を含むアカウント情報２７４０を識別する。本発明により、アカウント番号２７１６は、さらに、公開鍵情報２７１８を識別する。この公開鍵情報２７１８は、各アカウントのユーザの少なくとも公開鍵を含む。さらに、本発明の機能により、アカウント番号２７１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスについてのデバイスプロファイル情報２７７０を識別する。
【０１３７】
図２６の例において、エンティティに特有の情報２７４２は、例えば、名称、位置、診療の分野、およびアカウントホルダーが属するグループの名簿（他のデータベースおよびサブレコード（図示せず）へのアクセス権の決定のために）を含む。アクセス可能なデータベース２７４４のリストは、例えば、グループカレンダー、個人のカレンダー、グループコンテンツリスト、個人のコンテンツリスト、グループの患者リスト、個人のコンタクトリスト、受け入れられた保険証書のリストその他を含む。医療専門家２６０２のアカウントの公開鍵情報２７１８は、パーソナルアイテム２６５０に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報２７７０は、パーソナルアイテム２６５０に特有の情報を含む。
【０１３８】
以前に述べられたように、医療専門家２６０２からサーバ２６１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、および取引確認である。例えば、共通のタイプのセッション認証は、このビジネスアプリケーションにおいて、医療専門家２６０２が最初にコンピュータ２６６０上で維持されたデータベース管理およびアクセスソフトウェアにログインするまたは他の方法でアクセスすることを試みる場合に発生する。取引確認は、このビジネスアプリケーションにおいて、例えば、医療専門家２６０２がサーバ２６１２に、データベースに含まれる患者の一人の記録に関する活動（例えば、情報を更新または追加する）を実施することを要求するおよびサーバ２６１２が医療専門家２６０２に、パーソナルアイテム２６５０を用いて要求をデジタル署名する（および、可能であれば、さらに、追加のエンティティ認証情報または状態を提供する）ことによってこのような要求を確認することを要求する場合に適用可能である。
【０１３９】
どの種類のＥＣが医療専門家２６０２からサーバ２６１２へ通信されるかに関わらず、メッセージを（医療専門家側上で）構成およびデジタル署名するため、およびメッセージを認証し、エンティティを（サーバ側上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで図２８を参照すると、取引は、医療専門家２６０２が、コンピュータ２６６０を用いる内部のネットワーク２６０８を介して接続することによって、サーバ２６１２上で維持された種々の医療診療記録へのアクセスのためのログイン画面にアクセスする場合または、このようなログインが既に発生された後に、医療専門家２６０２がデータベースからの情報を要求するか、または、サーバ２６１２に、データベースにおける要求に関する活動を実施することを要求する場合に開始される（ステップ２８０２）。次に、サーバ２６１２は、コンピュータ２６６０に、医療専門家２６０２が、マイクロフォン２６６８に話すことによって声紋等のファクタＣエンティティ認証情報を入力することを促進させる（ステップ２８０４）。
【０１４０】
一旦、コンピュータ２６６０が適切な声紋を取得すると、電子メッセージが、認証およびデータベース記録へのアクセスのためにサーバ２６１２に送信するために構成される（ステップ２８０６）。最初のログインのために、コンピュータ２６６０は、医療専門家２６０２が選択できる利用可能なアカウントのメニューを表示する。好適には、このような利用可能なアカウントは、パーソナルアイテム２６５０上のメモリに格納され、コンピュータ２６６０によって医療専門家２６０２による選択のために取り出される。当然、一つのみのアカウントがパーソナルアイテム２６５０上のメモリにおいて利用可能である場合、そのアカウントは、医療専門家２６０２によって特定の選択を要求することなく、デフォルトによって選択される。あるいは、利用可能なアカウントのリストは、コンピュータ２６６０それ自体上のメモリに維持され、医療専門家２６０２による選択のために表示され得る。ログイン後の通信のために、コンピュータ２６６０は、例えば、医療専門家２６０２が概観することを許容される利用可能な患者の記録およびこのような各患者の記録に関して実施され得る活動のメニューを表示する。コンピュータ２６６０は、さらに、例えば、グループおよび個人のカレンダー、アドレスブック、および医療専門家がアクセス権を有する電子メールボックス表示する。
【０１４１】
一旦、コンピュータ２６６０がメッセージを構成すると、それは、ケーブル２６６５を介してＲＦ受信機／送信機２６５２に伝送される（ステップ２８０８）。ＲＦ受信機／送信機２６５２は、次いで、ＲＦ信号（メッセージを含む）をパーソナルアイテム２６５０に、医療専門家２６０２によりデジタル署名するために送信する。これに関し、メッセージを表すデータを含むＲＦ信号の受信の際、パーソナルアイテム２６５０は、最初にデータに対するハッシュ値を計算し、次いで、パーソナルアイテム２６５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージについてのデジタル署名を作成する（ステップ２８１０）。パーソナルアイテム２６５０は、次いで、デジタル署名を出力する（ステップ２８１２）。このデジタル署名は、ＲＦ受信機／送信機２６５２によって受信される。このＲＦ受信機／送信機２６５２は、同じデジタル署名をコンピュータ２６６０に転送する。コンピュータ２６６０は、次いで、メッセージおよびデジタル署名をＥＣでサーバ２６１２に伝送する（ステップ２８１４）。
【０１４２】
図２９を参照すると、ＥＣは、サーバ２６１２によってコンピュータ２６６０から受信される（ステップ２９０２）。サーバ２６１２は、次いで、アカウントデータベース２６１４から、アカウント番号２７１６によって識別される公開鍵取り出す（ステップ２９０４）。この公開鍵を用いて、サーバ２６１２は、メッセージを認証することを試みる（ステップ２９０６）。公開鍵を用いてメッセージが認証しない場合（ステップ２９０８）、サーバ２６１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答する（ステップ２９１０）。メッセージが認証する場合（ステップ２９０８において）、サーバ２６１２は、メッセージが、実際に、識別されたアカウント番号２７１６に結び付けられた正しいパーソナルアイテム２６５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される）。サーバ２６１２は、次いで、提供されたファクタＣエンティティ認証情報または状態（例えば、声紋）が特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ２９１２）。十分でない場合、サーバ２６１２は、メッセージの拒絶で応答し（ステップ２９１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ２９１２において）、サーバ２６１２は、メッセージをさらに処理する（ステップ２９１４）。
【０１４３】
最初のログインのためにを、メッセージをさらに処理することは、医療専門家２６０２に、コンピュータ２６６０によって表示された主要なユーザの画面へのアクセスを提供することを単に意味する。続く通信のために、さらに処理することは、コンピュータ２６６０を用いる医療専門家によってなされた適切な調査に応答してデータベース２６１４から取得された情報を表示することをしばしば意味する。いくつかの環境において、例えば、メッセージが医療専門家２６０２による、患者の一人に関係がある慎重さが必要な情報へのアクセスについての要求である場合、サーバ２６１２は、より強いエンティティ認証情報を医療専門家２６０２から要求し得る（このような慎重さが必要な情報を認可されていない個人に表示することについての増加されたリスクおよび潜在的な負担のため）。したがって、この状況では、コンピュータ２６６０は、医療専門家２６０２に、（コンピュータキーパッドを用いる）ＰＩＮおよび声紋を提供することを指示する（ステップ２８０６において）。（ステップ２９１２における）決定が、この状況においてポジティブである場合、さらに処理すること（ステップ２９１４）は、医療専門家２６０２に、要求された、慎重さが必要な情報へのアクセスを提供することを含む。ＥＣが、サーバ２６１２がアカウントに関するまたはアカウントに含まれた情報に関する活動を実施することについての医療専門家２６０２による要求（例えば、医療専門家２６０２が改変または追加する権利を有する患者記録上の情報を追加または変更する要求）を含む場合、このようなＥＣは、図２８および２９に一般的に記載されるように、処理され得る。しかしながら、上記の二つのＥＣと対照的に、サーバ２６１２は、このＥＣに対するデジタル署名を、主として、要求された活動を「確認する」ために要求し得る。このシナリオにおいて、提供されたエンティティ認証情報または状態が、（ステップ２９１２において決定されたように）十分である場合、メッセージをさらに処理するステップ（ステップ２９１４）は、要求された活動の性能を含む。
【０１４４】
（ｖｉｉ．行政給付アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第七のビジネスアプリケーション３０００が、図３０に示されている。この例では、市民３００２を含むアカウントホルダーは、時計、ネックレスまたは首輪（ｄｏｇ−ｔａｇ）、他の宝石類、キーリング（Ｋｅｙ　ｒｉｎｇ）その他等のパーソナルアイテム３０５０の形態でデバイスを所有する。このパーソナルアイテム３０５０は、無線周波数（ＲＦ）データ伝送をＲＦ受信機／送信機３０５２から送受信することができる。ネックレス３０５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。この例では、ＲＦ受信機／送信機３０５２は、ケーブル３０６５を介してパーソナルコンピュータ３０６０の適切なポート（ＵＳＢ、シリアル、パラレル等）に接続されている。パーソナルコンピュータ３０６０は、モニタを３０６２、キーボード３０６４、およびマウス３０６６を含む点で従来通りである。ネックレス３０５０は、アカウントの中でも特に、市民記録マネジャー３０１２によって表わされたアカウントオーソリティによって維持された行政記録アカウントに関連付けられる。コンピュータ３０６０は、モデム、ＬＡＮライン等を介する等の従来の方法で、市民記録マネジャー３０１２によって主催された安全なウェブサイトに、インターネット３００８を介して通信することを可能にするためにインストールされた適切なウェブブラウザソフトウェアを有する。
【０１４５】
市民記録マネジャー３０１２によって維持されたアカウントは、図３０のアカウントデータベースによって集約して参照されしめされる、一つ以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図３１を参照すると、アカウントデータベース３０１４の各認可されたユーザは、アカウント番号３１１６を備える固有のアカウント識別子によって識別される。各アカウント番号３１１６は、アカウントデータベース３１０１４内で、市民特有の情報３１４２およびアカウント特有の情報３１４４を含むアカウント情報３１４０を識別する。本発明により、アカウント番号３１１６は、さらに、公開鍵情報３１１８を識別する。この公開鍵情報３１１８は、各アカウントに結び付けられた市民の少なくとも公開鍵を含む。さらに、本発明の機能により、アカウント番号３１１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスについてのデバイスプロファイル情報３１７０を識別する。
【０１４６】
図３０の例では、市民特有の情報３１４２は、例えば、市民の名前、アドレス、社会保障番号、税識別番号、業務、出身地、年齢その他を含む。アカウント特有の情報３１４４は、例えば、社会保障給付金、福祉給付、老人医療保険／国民医療保障給付、普遍的処方医薬給付（Ｕｎｉｖｅｒｓａｌ　Ｐｒｅｓｃｒｉｐｙｉｏｎ　Ｄｒｕｇ　ｂｅｎｅｆｉｔ）、普遍的ヘルスケア給付、確定申告（前五年間の電子フォーマット）、貯金残高情報その他を含む。市民３００２のアカウントの公開鍵情報３１１８は、ネックレス３０５０に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報３１７０は、ネックレス３０５０に特有の情報を含む。
【０１４７】
このビジネスアプリケーションでは、市民３００２から市民記録マネジャー３０１２へのＥＣは、一般的に、セッション認証の目的のためにのみ用いられる。例えば、第一のセッション認証は、市民３００２が最初に、市民記録マネジャー３０１２によって維持された安全なウェブサイトにログインするまたは他の方法でアクセスすることを試みる場合に発生する。さらなるセッション認証は、市民３００２が特定の記録または市民３００２にとって非常に敏感な、安全な、機密性の、またはプライベートな情報の部分へのアクセスを要求する場合に発生する。この場合、市民記録マネジャー３０１２は、加入レベルの安全なウェブサイトに単にアクセスするために要求されるよりも強いレベルのエンティティ認証を要求する。
【０１４８】
どのセッション認証ＥＣが市民３００２から市民記録マネジャー３０１２に通信されたかに関わらず、メッセージを（市民側上で）構成およびデジタル署名するためおよびメッセージを認証し、エンティティを（市民記録マネジャー側上で）認証するための基本的な方法論は、本質的に同一である。例えば、ここで図３２を参照すると、本発明による取引は、図３０および３１に示されるインプリメンテーションでは、市民３００２が最初に、コンピュータ３０６０を用いたインターネット３００８を介して接続することによって、市民記録マネジャー３０１２によって維持された安全なウェブサイトにアクセスするためにログイン画面にアクセスする場合または、このような安全なウェブサイトが首尾よくアクセスされた後、市民３００２が、上記のように、非常に敏感な、安全な、機密性の、またはプライベートな情報へのアクセスを要求する場合に開始される（ステップ３２０２）。次に、安全なウェブサイトは、キーボード３０６４を用いてＰＩＮをコンピュータ３０６０にタイプすることによって、または、生物測定のサンプルを、コンピュータ３０６０に取り付けられるか、他の場合にはコンピュータ３０６０と電子通信している適切な生物測定のリーダ（図示せず）に提供することによって、コンピュータ３０６０を指示して（ステップ３２０４）、市民３００２が、ＰＩＮまたは生物測定の情報等のファクタＢまたはＣエンティティ認証情報を提供するようにさせる。
【０１４９】
この場合、一旦ＰＩＮが入力されると、電子メッセージが、認証および市民の個人記録へのアクセスのために市民記録マネジャー３０１２に送信するように構成される（ステップ３２０６）。ログイン目的のために、メッセージは、関連するアカウント番号を含むことのみが必要である。続く取引認証通信または情報へのアクセスについての要求のために、メッセージは、市民３００２から市民記録マネジャー３０１２へのの命令（ｉ１）を含む。最初のログインのために、コンピュータ３０６０は、市民３００２が選択できる利用可能なアカウントのメニューを表示する。好適には、このような利用可能なアカウントは、ネックレス３０５０上のメモリに格納され、ＲＦ受信機／送信機３０５２（コンピュータ３０６０によって指令されるように）によって、市民３００２による選択ために取り出される。当然、一つのみのアカウントがネックレス３０５０上のメモリにおいて利用可能である場合、そのアカウントは、市民３００２による特定の選択を要求することなく、デフォルトによって選択される。あるいは、利用可能なアカウントのリストは、コンピュータ３０６０そのものの上のメモリに維持され、市民３００２による選択のために表示され得る。ログイン後の通信のために、コンピュータ３０６０は、例えば、利用可能な市民記録および市民３００２が見ることを許可された行政給付アカウントのメニューを表示する。
【０１５０】
一旦、適切なアカウント番号またはメニューアイテムが選択されると、コンピュータ３０６０は、情報をメッセージに変換する。このメッセージは、ケーブル３０６５を介してコンピュータ３０６０からＲＦ受信機／送信機３０５２に伝送される（ステップ３２０８）。ＲＦ受信機／送信機３０５２は、次いで、市民３００２によってデジタル署名するために、ＲＦ信号（メッセージを含む）をネックレス３０５０に送信する。これに関して、メッセージを表わすデータを含むＲＦ信号の受信の際、ネックレス３０５０は、最初にデータについてのハッシュ値を計算し、次いで、ネックレス３０５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ３２１０）。ネックレス３０５０は、次いで、デジタル署名を出力する（ステップ３２１２）。このデジタル署名は、ＲＦ受信機／送信機３０５２によって受信される。このＲＦ受信機／送信機３０５２は、同一物をコンピュータ３０６０に転送する。コンピュータ３０６０は、次いで、メッセージおよびデジタル署名をＥＣにおいて市民記録マネジャー３０１２に伝送する（ステップ３２１４）。
【０１５１】
図３３を参照すると、ＥＣは、市民記録マネジャー３０１２によってコンピュータ３０６０から受信される（ステップ３３０２）。市民記録マネジャー３０１２は、次いで、アカウントデータベース３０１４から、アカウント番号３１１６によって識別される公開鍵を取り出す（ステップ３３０４）。この公開鍵を用いて、市民記録マネジャー３０１２は、メッセージを認証することを試みる（ステップ３３０６）。公開鍵を用いてメッセージが認証しない場合（ステップ３３０８において）、市民記録マネジャー３０１２は、メッセージの拒絶（すなわち、アカウントへのアクセスを認可することまたは要求された活動を実施することの拒否）で応答する（ステップ３３１０）。メッセージが認証する場合（ステップ３３０８において）、市民記録マネジャー３０１２は、メッセージが、実際に、識別されたアカウント番号３１１６に結び付けられた正しいネックレス３０５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される）。市民記録マネジャー３０１２は、次いで、提供されたファクタＢまたはＣエンティティ認証情報または状態（例えば、ＰＩＮおよび／または生物測定情報）が特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ３３１２）。十分でない場合、市民記録マネジャー３０１２は、メッセージの拒絶で応答し（ステップ３３１０）、そして、再度、このような応答は、拒絶についての理由を示し得る。エンティティ認証が十分である場合（ステップ３３１２において）、市民記録マネジャー３０１２は、メッセージをさらに処理する（ステップ３３１４）。
【０１５２】
最初のログインのために、メッセージをさらに処理することは、市民３００２に、コンピュータ３０６０によって表示された安全なウェブサイトの主要なユーザ画面へのアクセスを提供することを単に意味する。続く通信のために、さらに処理することは、市民３００２のために要求された市民記録または行政給付情報を表示することを意味する。以前に述べられたように、追加されたセキュリティのために、市民記録マネジャー３０１２は、いくつかの命令に対する追加のデジタル署名およびウェブサイト上でなされた要求（例えば、取引の確認またはさらなるセッション認証）を要求し得る。必要ならば、メッセージは、市民３００２が特定のオプションまたはウェブサイト上のメニューアイテムを選択した場合に生成される。このようなオプションまたはアイテムが選択された場合、市民記録マネジャー３０１２は、情報のデータパケットを、デジタル署名を要求する命令と共にコンピュータ３０６０に伝送する。コンピュータ３０６０は、応答時、ネックレス３０５０への情報をＲＦ受信機／送信機３０５２を介して伝送する。この情報は、新しいメッセージを構成する。不認可のまたは意図しないデジタル署名がネックレス３０５０に伝送された不要なＲＦ信号に応答して生成されることを防止するために、市民記録マネジャー３０１２は、ファクタＢまたはＣエンティティ認証が実施されない限り、ネックレス３０５０から受信されたＥＣを信頼しないことが好適である。
【０１５３】
（ｖｉｉｉ．インターネットサービスプロバイダ）
図２の２者ＡＢＤＳシステム２００をインプリメントする第八のビジネスアプリケーション３４００が、図３４に示される。この例では、個人を含むアカウントホルダー３４０２は、ドングル３４５０の形態でデバイスを所有する。このドングル３４５０は、直接、パーソナルコンピュータ３４６０の後ろ側上の適切なポート（ＵＳＢ、シリアル、パラレル等）に差し込まれる。ドングル３４５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。パーソナルコンピュータ３４６０は、モニタ３４６２、キーボード３４６４、およびマウス３４６６を含む点で従来通りである。ドングル３４５０は、特に、インターネットサービスプロバイダ３４１２によって表わされたアカウントオーソリティによって維持されたインターネットサービスプロバイダのアカウントに関連付けられる。コンピュータ３４６０は、モデム、ＬＡＮラインを介する、等の従来の方法で、インターネットサービスプロバイダ３４１２に、ネットワーク３４０８を介して通信することを可能にするためにインストールされた適切なウェブブラウザソフトウェアを有する。コンピュータは、さらに、コンピュータ３４６０が接続されたドングル３４５０に通信することを可能にされた、インストールされたソフトウェアを有する。
【０１５４】
インターネットサービスプロバイダ３４１２に維持されたアカウントは、アカウントデータベース３４１４によって集約して参照され図３４に示された、一つ以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図３５を参照すると、各アカウントは、アカウント番号３５１６を備える固有のアカウント識別子を含む。各アカウント番号３５１６は、アカウントデータベース３４１４内で、顧客特有の情報３５４２およびアカウント特有の情報３５４４を含むアカウント情報３５４０を識別する。本発明により、アカウント番号３５１６は、さらに、公開鍵情報３５１８を識別する。この公開鍵情報３５１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号３５１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報３５７０を識別する。
【０１５５】
図３４の例では、顧客特有の情報３５４２は、例えば、アカウントホルダーの名称、請求書送付先、ｅメールアドレス、クレジットカード情報その他を含む。アカウント特有の情報３５４４は、例えば、ＩＳＰ接続手段（例えば、電話モデム、ケーブルモデム、ＩＳＤＮ、Ｔ１接続等）、およびスピード、使用されかつ利用されるインターネット時間、ｅメールアカウントおよびエイリアス（ａｌｉａｓｅｓ）、ウェブページアドレス（単数または複数）その他を含む。アカウントホルダー３４０２の公開鍵情報３５１８は、ドングル３４５０に保持される秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報３５７０は、ドングル３４５０に特有の情報を含む。
【０１５６】
このビジネスアプリケーションでは、アカウントホルダー３４０２からインターネットサービスプロバイダ３４１２へのＥＣは、一般的に、セッション認証の目的のため（すなわち、最初に、インターネットにアクセスする目的のためにインターネットサービスプロバイダ３４１２のインターネットアクセスポータルにログインするまたは他の方法でアクセスするため）にのみ用いられる。この理由のため、一般的にアカウントホルダー３４０２からインターネットサービスプロバイダ３４１２に通信されるためにのみ必要とされるメッセージは、インターネットアカウントに対するアカウント番号３５１６を含むものである。命令（ｉ１）（すなわち、「私にインターネットへのアクセスを与えてください」）は、アカウント番号を含むＥＣの単なる通信において暗黙的である。
【０１５７】
図３６に示されるように、セッション認証は、アカウントホルダー３４０２が、コンピューターデスクトップ上のインターネットアクセスアイコンを従来通りの方法で「ダブルクリックする」ことによってコンピュータ３４６０上にインストールされた自動化されたログインソフトウェアを活性にする場合に開始される（ステップ３６０２）。自動化されたログインソフトウェアは、コンピュータ３４６０からのデジタル署名メッセージに対する要求を、接続されたドングル３４５０に送信する（ステップ３６０４）。これに応答して、ドングル３４５０は、アカウント番号を内部のメモリから受信し（ステップ３６０６）、アカウント番号をメッセージとして、ドングル３４５０のデジタル署名するコンポーネントに提供する（ステップ３６０８）。次に、ドングル３４５０は、最初にデータについてのハッシュ値を計算し、次いで、ドングル３４５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ３６１０）。ドングル３４５０は、次いで、デジタル署名を出力する（ステップ３６１２）。このデジタル署名は、コンピュータ３４６０によって受信される。コンピュータ３４６０は、次いで、メッセージおよびデジタル署名をＥＣにおいてインターネットサービスプロバイダ３４１２に従来の方法で伝送する（ステップ３６１４）。
【０１５８】
図３７を参照すると、ＥＣは、インターネットサービスプロバイダ３４１２によってコンピュータ３４６０から受信される（ステップ３７０２）。インターネットサービスプロバイダ３４１２は、次いで、アカウントデータベース３４１４から、アカウント番号３５１６によって識別される公開鍵を受信する（ステップ３７０４）。この公開鍵を用いて、インターネットサービスプロバイダ３４１２は、メッセージを認証することを試みる（ステップ３７０６）。メッセージが認証する場合（ステップ３７０８）、インターネットサービスプロバイダ３４１２は、メッセージは、実際に、接続された適法なドングル３４５０を有するコンピュータ３４６０（これは、おそらく、アカウントホルダー３４０２のコンピュータ３４６０である）から来たと結論し、コンピュータ３４６０に、インターネット３４０８へのアクセスを提供する（ステップ３７１２）。他方、メッセージが認証しない場合（ステップ３７０８において）、インターネットサービスプロバイダ３４１２は、メッセージの拒絶で応答する（ステップ３７１０）。このような応答は、拒絶に対する理由を含み得る。
【０１５９】
明らかに、上記プロセスは、非常に強いエンティティ認証を提供しない。それは、接続された、適切なドングル３４５０を有する任意のコンピュータは、インターネット（ステップ３７１２）へのアクセスを取得することが可能であるからである。より強いエンティティ認証が望みであれば、上記プロセスは、以前のビジネスアプリケーションにより類似するように改変され得る。これは、アカウントホルダー３４０２に、ファクタＢおよび／またはＣエンティティ認証情報を提供することを要求する。この場合、例えば、アカウントホルダー３４０２は、ＰＩＮ等のファクタＢエンティティ認証情報を入力することを要求され得る。このファクタＢエンティティ認証情報は、コンピュータ３４６０によってドングル３４５０に上記の「デジタル署名についての要求」メッセージと共に伝送される。インターネットサービプロバイダ３４１２は、次いで、アカウントホルダー３４０２によって提供されたエンティティ認証情報または状態がインターネットサービスプロバイダ３４１２にとってアカウントホルダ３４０２がコンピュータ３４６０に存在するエンティティであることを決定するのに十分であるかどうか決定する（図示しないステップにおいて）。この場合、ＥＣは、依然として、セッション認証のために用いられる。
【０１６０】
（ｉｘ．従業員データベース認証アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第九のビジネスアプリケーション３８００が、図３８に示されている。この例では、コンピュータープログラマー３８０２を含むアカウントホルダーは、電子キー３８５０の形態でデバイスを所有する。この電子キー３８５０は、電子ロック３８５２とインターフェースをとるように設計される。この電子ロック３８５２は、ケーブル３８６５を介してコンピュータ端末３８６０の適切なポート（ＵＳＢ、シリアル、パラレル等）に接続される。電子キー３８５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。パーソナルコンピュータ３８６０は、モニタ３８６２、キーボード３８６４、およびマウス３８６６を含む点で従来通りである。電子キー３８５０は、コンピュータプログラマー３８０２の雇用者（図示せず）によって経営される認証サーバ３８１２（この例において）によって表わされたアカウントオーソリティによって維持された従業員のデータベース認証アカウントに関連付けられる。雇用者は、コンピュータプログラムおよびコードの生成、設計、および書き込みのビジネスに従事する。コンピュータ３８６０は、内部のコンピュータネットワーク３８０８を介した認証サーバ３８１２への直接のアクセス、およびサーバ３８１２を通じ、そして、内部のファイヤウォール３８９４を通じた安全なサーバ３８９２への間接のアクセスを有する。この安全なサーバ３８９２上で、コンピュータプログラムのソースコードが格納される。このコンピュータプログラム上で、適法なコンピュータプログラマー３８０２が動くことが認可され、アクセスする必要がある。しかしながら、コンピュータプログラマー３８０２が安全なサーバ３８９２にアクセスしたい各時間に、コンピュータプログラマー３８０２は、最初に、認証サーバ３８１２によって認証および許可される必要がある。
【０１６１】
認証サーバ３８１２によって維持されたアカウントは、アカウントデータベース３８１４によって集約して参照され図３８に示された、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図３９を参照すると、アカウントデータベース３８１４における各認可されたユーザは、アカウント番号３９１６を備える固有のアカウント識別子（従業員ＩＤ等）によって識別される。各アカウント番号３９１６は、アカウントデータベース３８１４内で、雇用者特有の情報３９４２およびアクセス可能なデータベース３９４４を含むアカウント情報３９４０を識別する。本発明により、アカウント番号３９１６は、さらに、公開鍵情報３９１８を識別する。この公開鍵情報３９１８は、各アカウントのユーザの少なくとも公開鍵を含む。さらに、本発明の機能により、アカウント番号３９１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報３９７０を識別する。
【０１６２】
図３８の例では、従業員特有の情報３９４２は、例えば、名称、ｅメールアドレス、部門、管理者の名称、認可されたプロジェクト（単数または複数）、ビルディングの位置、部屋の位置、コンピュータのシリアル番号その他を含む。アクセス可能なデータベース３９４４のリストは、例えば、複数のプロジェクト、ここで識別されたプロジェクト１、プロジェクト２、プロジェクトｎまでを含む。コンピュータプログラマー３８０２のアカウントの公開鍵情報３９１８は、電子キー３８５０に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報３９７０は、電子キー３８５０に特有の情報を含む。このからみで、コンピュータプログラマー３８０２からのメッセージは、関連アカウントに対するアカウント番号３９１６および認証サーバ３８１２への命令（例えば、安全なサーバ３８９２へのアクセスを提供すること）を含む。
【０１６３】
このビジネスアプリケーションでは、コンピュータプログラマー３８０２から認証サーバ３８１２へのＥＣは、一般的に、セッション認証の目的のため（すなわち、最初に保護されたコンピュータプログラムまたは安全サーバ３８９２上に維持されたソースコードへのアクセスを取得するため）にのみ用いられる。この理由のため、一般的にコンピュータプログラマ３８０２から認証サーバ３８１２へ通信されるために必要なメッセージのみが、関連アカウントに対するアカウント番号３９１６およびコンピュータプログラマー３８０２が操作することを認可された、プロジェクト、プログラム、またはソースコードファイルの名称を含むものとなる。
【０１６４】
図４０に示されるように、セッション認証は、コンピュータプログラマー３８０２が安全なサーバ３８９２へのアクセス要求する場合に開始される（ステップ４００２）。このような要求は、コンピュータ３８６４上の適切なオペレーティングシステムコンピュータコマンドを用いて定式化され、認証サーバ３８１２に提示される。要求に応答して、認証サーバ３８１２は、コンピュータ３８６０を促して（ステップ４００４）、コンピュータプログラマー３８０２が電子キー３８５０を電子キーロック３８５２に挿入し、ファクタＢエンティティ認証情報を提供するようにさせる。例えば、ＰＩＮでは、キーボード３８６４を用いてＰＩＮをコンピュータ３８６０に入力する。一旦、キー３８５０がロック３８５２に挿入され、および、ＰＩＮが入力されると、電子メッセージが、安全なサーバ３８９２へのアクセスのための認証および許可のために認証サーバ３８１２に送信するように構成される（ステップ４００６）。メッセージは、例えば、以下の方法で構成される。
【０１６５】
コンピュータ３８６０は、コンピュータプログラマー３８０２に、要求されたアクセスに対する「プロジェクト名」を特定するように促す。一旦、プロジェクト名が入力されると、コンピュータ３８６０は、プロジェクト名およびアカウント番号３９１６をデジタル署名するためのメッセージに結合する。メッセージは、次いで、ケーブル３８６５を介してコンピュータ３８６０からロック３８５２へ、次いで、キー３８５０へ伝送される（ステップ４００８）。一旦、メッセージがキー３８５０によって受信されると、それは、最初にデータについてのハッシュ値を計算し、次いで、キー３８５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ４０１０）。キー３８５０は、次いで、デジタル署名を出力する（ステップ４０１２）。このデジタル署名は、ロック３８５２によって受信される。このロック３８５２は、同一物をコンピュータ３８６０に転送する。コンピュータ３８６０は、次いで、メッセージおよびデジタル署名をＥＣで認証サーバ３８１２に伝送する（ステップ４０１４）。
【０１６６】
図４１を参照すると、ＥＣは、サーバ３８１２によってコンピュータ３８６０から受信される（ステップ４１０２）。認証サーバ３８１２は、次いで、アカウントデータベース３８１４から、アカウント番号３９１６によって識別される公開鍵を取り出す（ステップ４１０４）。この公開鍵を用いて、認証サーバ３８１２は、メッセージを認証することを試みる（ステップ４１０６）。メッセージが認証しない場合（ステップ４１０８において）、サーバ３８１２は、メッセージの拒絶（すなわち、安全なサーバ３８９２へのアクセスを認可することの拒否）で応答する（ステップ４１１０）。このような応答は、拒絶に対する理由を示し得る。メッセージが認証する場合（ステップ４１０８において）、認証サーバ３８１２は、メッセージは、実際に、識別されたアカウント番号３９１６に結び付けられた正しい電子キー３８５０を所有する個人から来たと結論する（すなわち、ファクタＡエンティティ認証が取得される）。認証サーバ３８１２は、次いで、提供されたファクタＢエンティティ認証情報または状態（例えばＰＩＮ）が特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ４１１２）。十分でない場合、認証サーバ３８１２は、メッセージの拒絶に応答し（ステップ４１１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ４１１２において）、認証サーバ３８１２は、メッセージをさらに処理する（ステップ４１１４）。この場合、さらに処理することは、コンピュータプログラマー３８０２が、要求されたプログラムまたはファイルに結び付けられた任意の権利または許可を有するかどうかに関する個別の決定を含む。有していない場合、認証サーバ３８１２は、メッセージの拒絶で応答し（ステップ４１１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。コンピュータプログラマー３８０２が要求されたプログラムまたはファイルに関してなんらかの権利または許可を有する場合、コンピュータプログラマー３８０２は、その権利および許可によって制限されて、アクセスを与えられる。
【０１６７】
（ｘ．安全なエリア認証アカウント）
図２の２者ＡＢＤＳシステム２００をインプリメントする第十のビジネスアプリケーション４２００が、図４２に示される。この例では、従業員を含むアカウントホルダー４２０２は、電子キー４２５０の形態でデバイスを所有する。このデバイスは、電子ロック４２５２とインターフェースをとるように設計される。この電子ロック４２５２は、ケーブル４２６５を介して制御サーバ４２９２の適切なポートに接続される。電子ロック４２５２は、さらに、必要または望みの場合には、例えば、ＰＩＮの入力のために、英数字キーパッド４２５４に入力のために関連付けられる。電子キー４２５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。制御サーバ４２９２は、ライン４２６７を介して、ビルディング４２６０への安全扉４２６２に結び付けられた施錠および開錠機構４２６３を電気的に制御する。電子キー４２５０は、従業員４２０２の従業員（図示せず）によって操作されたセキュリティアカウントマネジャー４２１２によって表わされたアカウントオーソリティによって維持された安全エリア認証アカウントに関連付けられる。従業員４２０２がビルディング（またはこの例において図示されていない他の安全なエリア）にアクセスしたい各時間、従業員４２０２は、最初に要求されたエリアへのアクセスのために、セキュリティアカウントマネジャー４２１２によって認証および許可される必要がある。このセキュリティアカウントマネジャー４２１２は、制御サーバとライン４２６９を介して通信する。
【０１６８】
セキュリティアカウントマネジャー４２１２によって維持されたアカウントは、アカウントデータベース４２１４によって集約して参照され図４２に示された、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図４３を参照すると、アカウントデータベース４２１４内に識別された各認可されたユーザは、アカウント番号４３１６を備える固有のアカウント識別子によって識別される。各アカウント番号４３１６は、アカウントデータベース４２１４内で、従業員に特有の情報４３４２、安全にされた空間またはエリア４３４４、および各安全にされた空間に結び付けられたアクセス要求４３４６を含むアカウント情報４３４０を識別する。本発明により、アカウント番号４３１６は、さらに、公開鍵情報４３１８を識別する。この公開鍵情報４３１８は、各アカウントのユーザの少なくとも公開鍵を含む。さらに、本発明の機能により、アカウント番号４３１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報４３７０を識別する。
【０１６９】
図４２の例では、従業員に特有の情報４３４２は、例えば、名称、ｅメールアドレス、部門、管理者の名称、プロジェクト（単数または複数）の割り当て、ビルディングの位置、部屋の位置、コンピュータのシリアル番号その他を含む。安全にされた空間またはエリア４３４４のリストは、例えば、駐車場、主要なビルディングの玄関、フロア１−６、フロア７−１０、部屋６１０、他の安全な部屋、および他の特定ではないが安全にされているエリアを含む。アクセス要求４３４６のリストは、対応する安全にされた空間４３４４へのアクセスのために、どんな「タイプ」のエンティティ認証が要求されるかを識別する。（例えば、何もない（ｎｏｎｅ）−デジタル署名でさえ対応する空間へのアクセスを認可しないことを意味する；デバイス−デバイスによるデジタル署名の提示はアクセスのために十分であることを意味する；デバイス＋ＰＩＮ−デバイスからのデジタル署名と正しいＰＩＮとの加算が対応する空間へのアクセスのために要求されることを意味する；デバイス＋ＢＩＯ−デバイスからのデジタル署名と十分な生物測定の標本との加算が対応する空間へのアクセスのために要求されることを意味する；デバイス＋ＰＩＮ＋ＢＩＯ−デバイスからのデジタル署名と正しいＰＩＮと十分な生物測定の標本との加算が対応する空間へのアクセスのために要求されることを意味する）。セキュリティアカウントマネジャー４２１２によってインプリメントされる追加のビジネスルールは、ビルでリング４２６０内の要求されたエリアへのアクセスを認可するためにエンティティ認証が実際にどれくらい強くなければならないか決定する。従業員４２０２のアカウントの公開鍵情報４３１８は、電子キー４２５０に保持される秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報４３７０は、電子キー４２５０に特有の情報を含む。このからみで、従業員４２０２からのメッセージは、関連のアカウントに対するアカウント（従業員）番号４３１６およびセキュリティアカウントマネジャー４２１２への命令、例えば、特定された空間またはエリア４３４４へのアクセスを提供することを含む。
【０１７０】
このビジネスアプリケーションでは、従業員４２０２からセキュリティアカウントマネジャー４２１２へのＥＣは、一般的に、取引認証の目的のために（すなわち、要求された安全なエリアまたはリソースへのアクセスを取得するために）のみ用いられる。この理由のために、一般的に、従業員４２０２からセキュリティアカウントマネジャー４２１２へ通信されるのに必要なメッセージのみが、関連のアカウントに対するアカウント番号４３１６を含むものとなる。命令（ｉ１）（すなわち、「私にこのロック４２５２’’によって保護されたエリアへのアクセスを与えよ」）は、アカウント番号４３１６を含むＥＣの単なる通信において暗黙的である。
【０１７１】
図４４に示されるように、取引認証は、従業員４２０２が、主要なビルディング４２６０の主要なビルディングの玄関４２６２等の安全な空間またはエリアにアクセスすることを試みる場合に開始される（ステップ４４０２）。これは、場従業員４２０２が電子キー４２５０を電子ロック４２５２に物理的に挿入する場合に発生する（この特定のロック４２５２は、「非接触」の種類のものではなく、「接触」の種類のものであるため）。制御サーバ４２９２は、安全扉４２６２近くのスピーカー（図示せず）から出力される可聴式のメッセージを用いて、従業員４２０２に、ＰＩＮをキーパッド４２５４にタイプすることによって、ファクタＢエンティティ認証目的のためにＰＩＮを入力することを指示する（ステップ４４０４）。キー４２５０を挿入させたまま、かつ、ＰＩＮが入れられた後、電子メッセージは、主要ビルディング４２６０へのアクセスに対する認証および許可のためにサーバ４２１２に（制御サーバ４２９２を介して）送信するために構成される（ステップ４４０６）。メッセージは、例えば、制御サーバ４２９２によって構成される。この制御サーバ４２９２は、アカウント番号４３１６をキー４２５０から取り出し、従業員４２０２が入るためにタイプしている安全な扉４２６２の名称（またはコンピュータ識別番号）と結合する。好適には、制御サーバ４２９２は、さらに、「再生攻撃」の可能性（すなわち、キー４２５０から作成された以前のデジタル署名の再利用）を防止するために固有のセッションキーをメッセージ内に含む。
【０１７２】
制御サーバ４２９２によって構成されたメッセージは、次いで、デジタル署名の作成のためにケーブル４２６５を介してキー４２５０に逆伝送される（ステップ４４０８）。一旦、メッセージがキー４２５０によって受信されると、それは、最初に、データについてのハッシュ値を計算し、次いで、キー４２５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ４４１０）。キー４２５０は、次いで、デジタル署名をロック４２５２に出力する（ステップ４４１２）。このロック４２５２は、同一物を制御サーバ４２９２に転送する。制御サーバ４２９２は、次いで、メッセージおよびデジタル署名をＥＣでセキュリティアカウントマネジャー４２１２に伝送する（ステップ４４１４）。
【０１７３】
図４５を参照すると、ＥＣは、セキュリティアカウントマネジャー４２１２によって制御サーバ４２９２から受信される（ステップ４５０２）。セキュリティアカウントマネジャー４２１２は、次いで、アカウントデータベース４２１４から、アカウント番号４３１６によって識別される公開鍵を取り出す（ステップ４５０４）。この公開鍵を用いて、セキュリティアカウントマネジャー４２１２は、メッセージを認証することを試みる（ステップ４５０６）。メッセージが認証しない場合（ステップ４５０８において）、セキュリティアカウントマネジャー４２１２は、メッセージの拒絶（すなわち、ビルディング４２６０へのアクセスを認可することの拒否）で応答する（ステップ４５１０）。このような応答は、拒絶に対する理由を示し得る。メッセージが認証する場合（ステップ４５０８において）、セキュリティアカウントマネジャー４２１２は、メッセージは、実際に、識別されたアカウント番号４３１６に結び付けられた正しい電子キー４２５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される）。セキュリティアカウントマネジャー４２１２は、次いで、提供されたファクタＢエンティティ認証（例えば、ＰＩＮ）が（特定の扉４２６２に対して要求されたエンティティ認証の種類に基づいて、および上記の言及されたビジネスルールに基づいて）特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ４５１２）。十分でない場合、セキュリティアカウントマネジャー４２１２は、メッセージの拒絶で応答し（ステップ４５１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ４５１２において）、セキュリティアカウントマネジャー４２１２は、メッセージをさらに処理する（ステップ４５１４）。
【０１７４】
この場合、さらに処理することは、従業員４２０２が、要求された、安全な扉４２６２を通じた安全なエリアへのアクセスを取得するために任意の権利または許可を有するかどうかに関する個別の決定を含む。有しない場合、（従業員４２０２に、十分なエンティティ認証が提供されたとしても）、セキュリティアカウントマネジャー４２１２は、メッセージの拒絶（すなわち、要求されたエリアへのアクセスを認可することの拒否）で応答し（ステップ４５１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。従業員４２０２が要求されたエリアに入るための権利または許可を有する場合、セキュリティアカウントマネジャー４２１２は、従業員４２０２に要求されたエリアへのアクセスを提供する。より詳細には、セキュリティアカウントマネジャー４２１２は、適切な信号を制御サーバ４２９２に送信する。この制御サーバ４２９２は、次いで、開錠および／または玄関４２６２を開くために信号を、ライン４２６７を介して送信する。
【０１７５】
（ｘｉ．複数の買い手代理人による電子データインターチェンジ）
図２の２者ＡＢＤＳシステムをインプリメントする第十一のビジネスアプリケーション４６００が、図４６に示されている。この例では、買い手代理人４６０２ａ、４６０２ｂを含む二人のアカウントホルダーは、それぞれ、ＩＣカード等のカード４６５０ａ、４６５０ｂの形態のデバイスを所有する。このカード４６５０ａ、４６５０ｂは、カードリーダ４６５２ａ、４６５２ｂに用いられることが可能である。各カード４６５０ａ、４６５０ｂは、公開−秘密鍵の対の秘密鍵を安全に保護する。この例では、各カードリーダ４６５２ａ、４６５２ｂは、ケーブル４６６５ａ、４６６５ｂを介してパーソナルコンピュータ４６６０ａ、４６６０ｂの適切なポート（ＵＳＢ、シリアル、パラレル等）に接続されている。両パーソナルコンピュータ４６６０ａ、４６６０ｂは、モニタ４６６２ａ、４６６２ｂ、キーボード４６６４ａ、４６６４ｂおよびマウス４６６６ａ、４６６６ｂをそれぞれ含む点で従来通りである。両カード４６５０ａ，４６５０ｂは、供給会社４６１２によって表わされたアカウントオーソリティによって維持された共同の購入アカウントに結び付けられている。両コンピュータ４６６０ａ、４６６０ｂは、それらがモデム、ＬＡＮライン等を介する等の従来の方法で、供給会社４６１２によって主催されたウェブサイトに、インターネット４６０８を介して通信することを可能にするために、適切なウェブブラウザソフトウェアにインストールする。
【０１７６】
供給会社４６１２に維持されたアカウントは、アカウントデータベース４６１４によって集約して参照され図４６に示される、一以上のアカウントデータベースに維持されたアカウント記録に結び付けられている。図４７を参照すると、各アカウントは、アカウント番号４７１６を含む固有のアカウント識別子を含む。各アカウント番号４７１６は、アカウントデータベース４６１４内で、アカウント特有の情報４７４２および買い手代理人に特有の情報４７４４を含むアカウント情報４７４０を識別する。本発明により、アカウント番号４７１６は、さらに、公開鍵情報４７１８を識別する。この公開鍵情報４７１８は、各アカウントの各買い手代理人の少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号４７１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持する各デバイスに対するデバイスプロファイル情報４７７０を識別する。
【０１７７】
図４６の例では、アカウント特有の情報４７４２は、例えば、会社名、主要な会社の窓口、ｅメールアドレス、請求書送付先、請求書情報、およびアカウントに対する認可された買い手代理人のリストを含む。買い手代理人に特有の情報４７４４は、例えば、代理人名、買い手代理人識別番号、買い手代理人についてのコンタクト情報、場合によって、会社によって購入代人に負担された購入制限、その他を含む。会社のアカウントの公開鍵情報４７１８は、各買い手代理人のカード４６５０ａ、４６５０ｂに保持された秘密鍵に対応する各公開鍵を含む。デバイスプロファイル情報４７７０は、各カード４６５０ａ、４６５０ｂに特有の情報を含む。図４６は、二つのみの買い手代理人を示すが、図４７は、より多くの買い手代理人（ｎ）がさらこの特定の会社アカウントに結び付けられ得るという事実を示す。
【０１７８】
以前の述べられたように、買い手代理人４６０２ａ、４６０２ｂから供給会社４６１２へのＥＣは、三つの異なる目的のために用いられ得る。それは、セッション認証、取引認証、取引確認である。例えは、共通のタイプのセッション認証は、このビジネスアプリケーションにおいて、買い手代理人４６０２ａ、４６０２ｂが最初に、供給会社４６１２によって動作された安全なウェブサイトにログインするまたは他の方法でアクセスすることを試みる場合に発生する。取引確認は、このビジネスアプリケーションにおいて、例えば、買い手代理人４６０２ａ、４６０２ｂが、高いチケットアイテムの購入を要求する場合、および／または、買い手代理人４６０２ａ、４６０２ｂが「確認」し、購入されたアイテムのリストの代金を支払う準備ができている場合に適用可能である。このような場合、供給会社４６１２は、買い手代理人４６０２ａ、４６０２ｂに、カード４６５０ａ、４６５０ｂを用いて要求をデジタル署名する（および、可能であれば、さらに、追加のエンティティ認証情報または状態を提供する）ことによってこのような要求を確認することを要求する。
【０１７９】
どの種類のＥＣが買い手代理人４６０２ａ、４６０２ｂから供給会社４６１２に通信されるかに関わらず、メッセージを（購入代人側上で）構成およびデジタル署名するための、およびメッセージを認証し、エンティティを（供給会社側上で）認証するためのの基本的な方法論は、本質的に同一である。例えば、ここで図４８を参照すると、取引（この場合、セッション認証）は、いずれかの買い手代理人４６０２ａ、４６０２ｂが供給会社４６１２のウェブサイトにコンピュータ４６６０ａ、４６６０ｂをそれぞれ用いるインターネット４６０８を介してアクセスする場合に開始される（ステップ４８０２）。この例の残りのために、この取引は、第一の買い手代理人４６０２ａによって、開始されかつ実行されると想定する。最初に、供給会社のウェブは、コンピュータ４６６０ａを指示して（ステップ４８０４）、買い手代理人４６０２ａが、ＰＩＮ等のファクタＢエンティティ認証情報をログイン画面に入力するようにさせる。一旦、ＰＩＮがログイン画面に入力されると、電子メッセージが、供給会社４６１２に送信するために構成される（ステップ４８０６）。
【０１８０】
この例におけるメッセージは、両買い手代理人４６０２ａ、４６０２ｂの従業員に代わって、供給会社４６１２によって維持された共同のアカウントに結び付けられた単なるアカウント番号４７１６である。コンピュータ４６６０ａは、買い手代理人４６０２ａが選択できる利用可能なアカウントのメニューを表示する。好適には、このような利用可能なアカウントは、カード４６５０ａ上のメモリ内に格納され、買い手代理人４６０２ａによる選択のためにコンピュータ４６６０ａによって取り出される。当然、一つのみのアカウントがカード４６５０ａ上のメモリにおいて利用可能である場合、そのアカウントは、買い手代理人４６０２ａによる特定の選択を要求することなく、デフォルトによって選択される。あるいは、利用可能なアカウントのリストは、コンピュータ４６６０ａそれ自体上のメモリに維持され、買い手代理人４６０２ａによる選択のために表示され得る。
【０１８１】
一旦、適切なアカウント番号が選択されると、それは、メッセージとして、ケーブル４６６５ａを介してコンピュータ４６６０ａからカード４６５０ａに、買い手代理人４６０２ａによりデジタル署名するために伝送される（ステップ４８０８）。これに関して、メッセージを表わすデータの受信の際、カード４６５０ａは、最初にデータについてのハッシュ値を計算し、次いで、カード４６５０ａに保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ４８１０）。カード４６５０ａは、次いで、デジタル署名を出力する（ステップ４８１２）。このデジタル署名は、コンピュータ４６６０ａによって受信される。コンピュータ４６６０ａは、次いで、メッセージおよびデジタル署名をでＥＣで供給会社４８１２に伝送する（ステップ４８１４）。
【０１８２】
図４９を参照すると、ＥＣは、供給会社４６１２によってコンピュータ４６６０ａから受信される（ステップ４９０２）。供給会社４６１２は、次いで、アカウントデータベース４６１４から、アカウント番号４７１６によって識別される公開鍵のすべてを取り出す（ステップ４９０４）。これらの公開鍵のそれぞれを用いて、供給会社４６１２は、メッセージを認証することを経時的に試みる（ステップ４９０６）。あるいは、メッセージは、実際に、関連の買い手代理人４６０２ａの公開鍵４７１８（または、サブアカウント識別子として作用する適切な買い手代理人ＩＤ）を説明し得、その結果、供給会社４６１２は、データベース４６１４からのどの公開鍵４７１８を使用するかを「推測」する必要がない。しかしながら、供給会社４６１２は、それでも、このような公開鍵４７１８が特定のアカウント番号４７１６に対応することを確認する必要がある。メッセージが識別されたアカウント４７１６に結び付けられた公開鍵の任意によって認証しない場合（ステップ４９０８において）、供給会社４６１２は、メッセージの拒絶（すなわち、購入のためのウェブサイトへのアクセスを認可することの拒否）に応答する（ステップ４９１０）。このような応答は、拒絶に対する理由を示し得る。一旦、メッセージを認証すると（ステップ４９０８）、供給会社４６１２は、メッセージは、実際に、識別されたアカウント番号４７１６に結び付けられた正しいカード４６５０ａを所有する個人から来たと結論する（すなわち、ファクタＡエンティティ認証が取得される）。供給会社４６１２は、次いで、提供されたファクタＢエンティティ認証情報または状態（例えば、ＰＩＮ）が特定のメッセージをさらに処理するために十分であるかどうか決定する（ステップ４９１２）。十分でない場合、供給会社４６１２は、メッセージの拒絶で応答し（ステップ４９１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ４９１２において）、供給会社４６１２は、メッセージをさらに処理する（ステップ４９１４）。
【０１８３】
この場合、さらに処理することは、買い手代理人４６０２ａに、買い手代理人４６０２ａの従業員の代わりに供給物を購入するためのウェブサイトへのアクセスを提供することを含む。さらに処理することは、アカウントデータベース４６１４内の買い手代理人特有の情報４７４４からの購入制限に説明されたように特定の買い手代理人４６０２ａ上に負わされた購入制限に基づいて、買い手代理人４６０２ａの購入オーソリティ内にないアイテムの表示（または購入のための選択）を制限することをさらに含む。
【０１８４】
一旦、ウェブサイトにおいて、買い手代理人４６０２ａが自由にウェブサイト（上記説明を除く）について操縦することおよび従業員の代わりに購入することを許容されると、望む場合、供給会社４６１２は、ウェブサイト上の「高いチケット」または特定のアイテムに対するカード４６５０ａを用いた、買い手代理人４６０２ａによる追加のエンティティ認証を要求し得る。このような場合、好適には、ウェブサイトは、確認メッセージを、カード４６５０ａによる確認デジタル署名の作成のためにカード４６５０ａへの伝送のためにコンピュータ４６６０ａに逆伝送する。このようなデジタル署名を作成するプロセスは、上記に説明された手順と鏡のように同じであり、ファクタＢエンティティ認証情報の再参加またはデジタル署名の作成の前と同一の状態を提供することを含み得る。
【０１８５】
（ｉ．３者ＡＢＤＳシステムの特定のインプリメンテーション）
図２の２者ＡＢＤＳシステム２００と同様に、図３の３者ＡＢＤＳシステム３００は、莫大な数のビジネスアプリケーションにおいてインプリメントされ得る。本明細書において説明される特定の例は、そのため、このような広い範囲の可能性のサンプリングのみを表わす。
【０１８６】
（ｉ．金融機関アカウントを用いるｅビジネス取引）
図３の３者ＡＢＤＳシステム３００をインプリメントする第一のビジネスアプリケーション５０００が、図５０に示されている。この例では、買い手５００２を含むアカウントホルダーは、ＩＣカード等のカード５０５０の形態のデバイスを所有する。このデバイスは、カードリーダ５０５２に用いられることが可能である。カード５０５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。この例では、カードリーダ５０５２は、ケーブル５０６５を介してパーソナルコンピュータ５０６０の適切なポート（ＵＳＢ、シリアル、パラレル等）に接続される。パーソナルコンピュータ５０６０は、モニタ５０６２、キーボード５０６４、およびマウス５０６６を含む点で従来通りである。カード５０５０は、アカウントの中でも特に、金融機関５０１２を含むアカウントオーソリティに維持されたデビットまたはクレジットアカウントに関連付けられる。アカウントは、当座預金、普通預金、マネーマーケットアカウント、クレジットカードアカウントその他であり得、金融機関５０１２は、銀行、貯蓄貸付、クレジットカード会社その他であり得る。コンピュータ５０６０は、モデム、ＬＡＮライン等を介する等の従来の方法で、オンライン売り手５０１０を含む中間者にインターネット５００８を介して通信すること可能にするために、適切なウェブブラウザソフトウェアをインストールする
金融機関５０１２に維持されたアカウントは、アカウントデータベース５０１４によって集約して参照され図５０に示された、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図５１を参照すると、各アカウントは、アカウント番号５１１６を含む固有のアカウント識別子を含む。各アカウント番号５１１６は、アカウントデータベース５０１４内で、顧客特有の情報５１４２およびアカウント特有の情報５１４４を含むアカウント情報５１４０を識別する。本発明により、アカウント番号５１１６は、さらに、公開鍵情報５１１８を識別する。この公開鍵情報５１１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号５１１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報５１７０を識別する。
【０１８７】
図５０の例では、顧客特有の情報５１４２は、例えば、アカウントホルダーの名称、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報５１４４は、例えば、現在の勘定残高、利用可能なクレジット、閉鎖データおよび現在の計算書の差額、および結び付けられたアカウント識別子を含む。買い手５００２のアカウントの公開鍵情報５１１８は、カード５０５０内に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報５１７０は、カード５０５０に特有の情報を含む。
【０１８８】
図５２を特に参照すると、買い手５００２は、従来の方法で、コンピュータ５０６０上にインストールされたウェブブラウジングソフトウェアを用いてオンライン売り手５０１０のウェブサイトにアクセスすることによって、オンライン売り手５０１０と取引を開始する（ステップ５２０２）。コンピュータ５０６０上でウェブサイトを見る間、買い手５００２は、本等の商品を、ウェブサイト上での従来の方法で購入するために本を選択することによって、オンライン売り手５０１０から注文する（ステップ５２０６）。好適には、買い手５００２は、以前のように、カード５０５０がカードリーダ５０５２に挿入された場合にファクタＢまたはＣエンティティ認証情報をコンピュータ５０６０に入力する（ステップ５２０４において）。カード５０５０が以前のようにカードリーダ５０５２に挿入されなかった場合、コンピュータ５０６０は、買い手５００２がそのようにすることおよび関連する参加認証情報を入力することを指示する（ステップ５２０４）。
【０１８９】
メッセージを生成するステップ（ステップ５２０８）は、デジタル署名され、以下のように発生する。注文するプロセスの一部として、ウェブサイトは、モニタ５０６２上の買い手５００２に支払い選択画面を表示する。この支払い選択画面は、好適には、注文する商品を識別し、商品の価格および出荷（ｓｈｉｐｐｉｎｇ）およびハンドリング（ｈａｎｄｌｉｎｇ）を含む。買い手５００２は、支払い方法（すなわち、アカウント番号５１１６およびアカウントの種類）を特定するために、要求されたデータ参加領域およびモニタ５０６２の画面上の引き下げメニューからのマーク選択を、従来の方法（例えば、このような領域／メニューは、既知の方法で「クッキー（ｃｏｏｋｉｅｓ）」に格納された情報を用いて自動的にコンピュータ５０６０によって満たされ得る）で完了する。一般的に、金融業界は、アイデンティティが単独でアカウント番号５１１６（例えば、ＩＳＯ標準７８１２として規定される発行者識別番号（ＩＩＮ）（これは、本明細書において参考として援用される））の使用から引き出され得る慣習に従うので、金融機関５０１２の名前を識別することは必要ではない。他の支払い情報は、支払い選択画面に入れられる必要がない。むしろ暗号化された様式、例えば、セキュリティソケット圧条（ＳＳＬ）でオンライン売り手５０１０への情報を提示する必要がある。このセキュリティソケット圧条（ＳＳＬ）は、従来通りであり、買い手５００２は、単に、「ＡＢＤＳ方法」における注文を「デジタル署名する」オプションを（支払い方法画面上で）要求する。この選択に応答して、コンピュータ５０６０は、買い手５００２によって支払い選択画面（単数または複数）に表示され、および／または入力された情報を用いて、メッセージを生成する。
【０１９０】
このメッセージは、次いで、ケーブル５０６５を介してコンピュータ５０６０からカード５０５０に、買い手５００２によってデジタル署名するために伝送される（ステップ５２１０）。これに関し、メッセージを表わすデータの受信の際、カード５０５０は、最初にデータに対するハッシュ値を計算し、次いで、カード５０５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ５２１２）。カード５０５０は、次いで、デジタル署名を出力する（ステップ５２１４）。このデジタル署名は、コンピュータ５０６０によって受信される。コンピュータ５０６０は、次いで、メッセージおよびデジタル署名をＥＣでオンライン売り手５０１０に伝送する（ステップ５２１６）。
【０１９１】
この特定の例では、買い手５００２からオンライン売り手５０１０への命令（ｉ２）は、支払い方法およびメッセージに特定されたアカウント５１１６を用いて商品に対する買い手の注文を含む。アドレスに向かう配信は、場合によっては、買い手５００２によって提供される。このため、命令（ｉ２）の一部は、メッセージおよびデジタル署名を含むＥＣに先行して電子通信に含まれ得、命令（ｉ２）の追加の部分は、メッセージおよびデジタル署名を含むＥＣに含まれる。他方、買い手５００２からのメッセージは、究極的には金融機関５０１２のために意図され、特定されたアカウントにおけるアカウント５１１６からオンライン売り手５０１０への支払いをするために、特定のアカウントに対するアカウント番号５１１６および金融機関５０１２への命令（ｉ１）を含む。
【０１９２】
２者ＡＢＤＳシステム２００とは異なり、メッセージおよびデジタル署名を含むＥＣ（この場合、取引認証目的のために用いられる）は、金融機関５０１２に直接送信されず、オンライン売り手５０１０へ送信される。図５３に示されるように、オンライン売り手５０１０は、買い手５００２からのＥＣを受信し（ステップ５３０２）、買い手５００２からメッセージおよびデジタル署名を含むＥＣに含まれるオンライン売り手５０１０への任意の追加の命令（ｉ２）を抽出する（ステップ５３０４）。オンライン売り手５０１０は、次いで、メッセージおよびデジタル署名を含むＥＣを金融機関５０１２に、支払いの認証および認可のために転送する（ステップ５３０６）。オンライン売り手５０１０は、金融機関５０１２からの応答を待つ間に、次いで、これらの命令（ｉ２）（すなわち、購入要求）を金融機関５０１２からの支払いの「オンホールド（ｏｎ　ｈｏｌｄ）」の保留承認に位置づける（ステップ５３０８）。
【０１９３】
図５４を参照すると、ＥＣは、金融機関５０１２によってオンライン売り手５０１０から受信される（ステップ５４０２）。金融機関５０１２は、次いで、アカウントデータベース５０１４から、アカウント番号５１１６によって識別される公開鍵を取り出す（ステップ５４０４）。この公開鍵を用いて、金融機関５０１２は、メッセージを認証することを試みる（ステップ５４０６）。メッセージが認証しない場合（ステップ５４０８において）、金融機関５０１２は、オンライン売り手５０１０に対して、メッセージの拒絶で応答する（ステップ５４１０）。このような応答は、拒絶に対する理由を示し得る。メッセージが認証する場合（ステップ５４０８において）、金融機関５０１２は、メッセージは、実際に、識別されたアカウント番号５１１６に結び付けられた正しいカード５０５０を所有する個人から来たと結論する（すなわち、ファクタＡエンティティ認証が取得される）。金融機関５０１２は、次いで、提供されたファクタＢまたはＣエンティティ認証情報または状態は、特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ５４１２）。十分でない場合、金融機関５０１２は、メッセージの拒絶で応答し（ステップ５４１０）、そして、再度、このような応答は、拒絶に対する理由を示し得る。エンティティ認証が十分である場合（ステップ５４１２において）、金融機関５０１２は、メッセージのさらなる処理（以下に説明される）を進める。
【０１９４】
本発明の例では、メッセージをさらに処理することは、命令（ｉ１）が実施されることが可能であるかどうかについての決定（ステップ５４１４）を含む。例えば、メッセージが認証された場合でさえ、買い手は、十分な金または金融機関５０１２が取引を許可するアカウントに結び付けられたクレジットを有さない場合もある。したがって、このような決定をすることは、通常、アカウント記録の関連部分（単数または複数）にアクセスすることおよび資金が利用可能であることを確認することを含む。決定（ステップ５４１４において）が否定的である場合、金融機関５０１２は、オンライン売り手５０１０に対して、メッセージの拒絶で応答する（ステップ５４１０）。再度、このような応答は、拒絶に対する理由を示し得る。ステップ５４１４における決定が許可的な場合、金融機関５０１２は、命令（ｉ１）を実施する（ステップ５４１６）。この例では、買い手５００２からの命令（ｉ１）は、オンライン売り手５０１０に特定量の資金を、商品の購入に対するアカウントから支払うことである。したがって、命令を実施すること（ステップ５４１６）は、通常、アカウント記録の関連部分（単数または複数）にアクセスすること、買い手５００２のアカウントからオンライン売り手５０１０への特定量の資金の伝送を開始すること、およびアカウント記録を自動的に貸方記入する／更新することを含む。（資金を伝送するステップおよびアカウントを貸方記入するステップは、他のステップと同時に発生しない場合があることが留意されるべきである。）金融機関５０１２は、さらに、オンライン売り手５０１０にメッセージの許可および支払いの開始を通知する（ステップ５４１８）。
【０１９５】
再度、図５３を参照すると、一旦、オンライン売り手５０１０が金融機関５０１２からの応答を受信すると、ステップ５３１０における決定はポジティブである。オンライン売り手５０１０は、次に、応答が取引の許可または拒絶であるか決定する（ステップ５３１２）。取引が金融機関５０１２によって許可されない場合、オンライン売り手５０１０は、買い手５００２にメッセージが拒絶された（すなわち、支払いが許可されない）ことおよび命令（ｉ２）が実行されないこと（すなわち、支払い拒絶のために商品が出荷されないこと）を通知する（ステップ５３１４）。他方、ステップ５３１２における決定がポジティブである場合、オンライン買い手５０１０は、以前に待たされた命令（ｉ２）を実行する（ステップ５３１６）。この場合、オンライン売り手５０１０は、買い手５００２によって購入された商品の出荷を開始する。次に、オンライン売り手５０１０は、買い手５００２に取引（すなわち、支払い）が許可されたことおよび命令（ｉ２）が実行されているまたはすでに実行されたこと（すなわち、商品は要求されたアドレスに出荷されていること）を通知する（ステップ５３１８）。
【０１９６】
（ｉｉ．金融機関アカウントを用いるデジタルギフトチェック）
図３の３者ＡＢＤＳシステム３００をインプリメントする第二のビジネスアプリケーション５５００が、図５５に示されている。この例では、アカウントホルダーは、ギフト贈与者５５０２を含む。このギフト贈与者５５０２は、携帯端末（ＰＤＡ）５５５０の形態のデバイスを所有する。ＰＤＡ５５５０は、公開−秘密鍵の対の秘密鍵を安全に保護する。ＰＤＡ５５５０は、双方向ディスプレイ画面５５５２およびユーザ入力キー５５５６を含む。さらに、ＰＤＡ５５５０は、無線通信ネットワーク５５０８を介するデジタル通信のための無線モデムを適切に備える。ＰＤＡ５５５０は、ギフトクリアリングハウスまたはギフトプロセッサ５５１２を含むアカウントオーソリティに維持されたデビットまたはクレジットアカウントに関連付けられる。アカウントは、当座預金、普通預金、マネーマーケットアカウント、クレジットカードアカウントその他であり得、ギフトプロセッサ５５１２は、銀行、貯蓄貸付、クレジットカード会社その他等の金融機関、または、デジタルチェックまたは金銭上のギフトが電子的にＡＢＤＳシステム内に伝送されることを可能にする目的のために特別に設置された会社またはビジネスユニットであり得る。ＰＤＡ５５５０は、従来の方法で、ｅメールを生成し、およびそれをネットワーク５５０８を介してギフト受信側５５１０に伝送することを可能にするために適切なソフトウェアをインストールする。ギフト受信側５５１０は、コンピュータ５５９０を有する。このコンピュータ５５９０は、例えば、ネットワーク５５０８および／またはインターネット５５１１を介して受信されたｅメールを受信および転送することが可能である。あるいは、ＰＤＡ５５５０は、このようなｅメール（または、ｅメールにより他の電子通信読み出し可能なまたは標準ウェブソフトウェア）を構成する、生成する、および送信する目的のためにギフトプロセッサ５５１２によって特別に提供されたソフトウェアをインストールする。
【０１９７】
ギフトプロセッサ５５１２に維持されたアカウントは、アカウントデータベース５５１４によって集約して参照され図５５に示される、一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。図５６を参照すると、各アカウントは、アカウント番号５６１６を含む固有のアカウント識別子を含む。各アカウント番号５６１６は、アカウントデータベース５５１４内で、顧客特有の情報５６４２およびアカウント特有の情報５６４４を含むアカウント情報５６４０を識別する。本発明により、アカウント番号５６１６は、さらに、公開鍵情報５６１８を識別する。この公開鍵情報５６１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号５６１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報５６７０を識別する。
【０１９８】
図５５の例では、顧客特有の情報５６４２は、例えば、アカウントホルダーの名前、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報５６４４は、例えば、現在の勘定残高、利用可能なクレジット、アカウントホルダーの現在の計算書、および支払いアカウント代替物を含む。ギフト贈与者５５０２のアカウントの公開鍵情報５６１８は、ＰＤＡ５５５０に保持される秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報５６７０は、ＰＤＡ５５５０に特有の情報を含む。
【０１９９】
特に図５７に関し、買い手５００２は、ＰＤＡ５５５０上で適切なｅメールまたはギフトソフトウェア（ギフトプロセッサ５５１２によって提供される）を起動する（ステップ５７０２）ことによって、デジタルチェックまたは金銭のギフトをギフト受信側５５１０に与えることを開始する。ＰＩＮまたは生物測定の情報等のファクタＢまたはＣエンティティ認証情報がまだギフト贈与者５５０２によってＰＤＡ５５５０に入力されていない場合、ＰＤＡ５５５０は、ギフト贈与者５５０２に今そのように行うことを指示する（ステップ５７０４）。
【０２００】
一旦、このようなファクタＢまたはＣエンティティ認証情報が入力されると、ギフト贈与者５５０２は、メッセージを生成する（ステップ５７０６）。これは、事前にインストールされたソフトウェアを用いて、ｅメールを構成するかまたは適切な「デジタルチェック」を構成することのいずれかによってなされる。にも関わらず、メッセージは、以下の情報を含む必要がある。ギフト受信側５５１０の名前およびｅメールアドレス、ギフトの量、およびギフトが引き出されるアカウントのアカウント番号５６１６。ギフト贈与者５５０２が標準のｅメールプログラムを使用する場合、適切なｅメールアドレスまたはギフトプロセッサ５５１２に対するウェブアドレスが、構成されたメッセージに含まれる必要がある。その結果、ギフト受信側５５１０は、電子ギフトまたはデジタルチェックを得るために、どこに行くべきかを知る。ギフト贈与者５５０２がギフトプロセッサ５５１２からの事前にインストールされたソフトウェアを使用する場合、このようなソフトウェアは、ギフト贈与者５５０２がそれを構成した後、ギフトプロセッサ５５１２に対するこのような適切なコンタクト情報をメッセージに自動的に追加する。一旦、このようなメッセージが完了されると、ギフト贈与者５５０２は、ＰＦＡ５５５０を用いて、メッセージをデジタル署名する
ＰＤＡ５５５０は、最初にデータに対するハッシュ値を計算し、次いで、ＰＤＡ５５５０に保持された秘密鍵を用いてハッシュ値を暗号化することによって、メッセージに対するデジタル署名を作成する（ステップ５７０８）。ＰＤＡ５５５０は、次いで、デジタル署名およびメッセージを、ｅメールプログラム内の「アウトボックス（ｏｕｔ　ｂｏｘ）」に出力する（ステップ５７１０）。ＰＤＡ５５５０は、ネットワーク５５０８を介するｅメールサービスプロバイダとの無線接続を設置し、メッセージを生成したときのギフト贈与者５５０２によって提供されたギフト受信側５５１０に対するｅメールアドレスを用いて、ＥＣ内のメッセージおよびデジタル署名を、ギフト受信側５５１０へのｅメールの形態で伝送する（ステップ５７１２）。
【０２０１】
図５８に示されるように、ギフト受信側５５１０は、ギフト受信側５５１０がコンピュータ５５９０上で有する標準ｅメールソフトウェアを用いて、メッセージおよびデジタル署名（再度、この場合において、取引認証目的のために用いられる）を含むＥＣを受信する（ステップ５８０２）。ＥＣの受信の際、ギフト受信側５５１０は、識別されたｅメールまたはＥＣに含まれるウェブアドレスを用いて、認証および支払いのために、ギフトプロセッサ５５１２へのメッセージおよびデジタル署名を含むＥＣを転送することのみが必要である（ステップ５８０４）。おそらく、ギフト受信側５５１０からギフトプロセッサ５５１２へのこのようなｅメールは、インターネット５５１１または他の従来の通信ネットワークを介して伝送される。ギフト受信側５５１０は、次いで、どのようにしてギフトを取得するかについてまたはギフトがギフト受信側５５１０のアカウントに貯金されたことの通知のためのギフトプロセッサ５５１２からの命令を待つだけである。ギフト受信側５５１０とギフトプロセッサ５５１２との間の配置がすでにこのような貯金の代わりになっている場合がある。
【０２０２】
図５９を参照すると、ＥＣは、ギフトプロセッサ５５１２によってギフト受信側５５１０から受信される（ステップ５９０２）。ギフトプロセッサ５５１２は、次いで、アカウントデータベース５５１４からアカウント番号５６１６によって識別される公開鍵を取り出す（ステップ５９０４）。この公開鍵を用いて、ギフトプロセッサ５５１２は、メッセージを認証することを試みる（ステップ５９０６）。メッセージが認証しない場合（ステップ５９０８において）、ギフトプロセッサ５５１２は、ギフト受信側５５１０に対して、メッセージの拒絶で応答する（ステップ５９１０）。このような応答は、拒絶に対する理由を示し得る。メッセージが認証する場合（ステップ５９０８において）、ギフトプロセッサ５５１２は、メッセージは、実際に、識別されたアカウント番号５６１６に結び付けられた正しいＰＤＡ５５５０を所有する個人から来たと結論する。（すなわち、ファクタＡエンティティ認証が取得される。）ギフトプロセッサ５５１２は、次いで、ファクタＢまたはＣエンティティ認証情報または提供された状態は、特定のメッセージをさらに処理するために十分であるかどうかを決定する（ステップ５９１２）。十分でない場合、ギフトプロセッサ５５１２は、メッセージの拒絶に応答し（ステップ５９１０）、そして、再度、望みであれば、このような応答は、拒絶に対する理由を示し得る。ファクタＢまたはＣエンティティ認証情報または状態が十分である場合（ステップ５９１２において）、ギフトプロセッサ５５１２は、メッセージのさらなる処理（以下に議論される）を進める。
【０２０３】
本発明の例では、メッセージをさらに処理することは、命令（ｉ１）が実施されることが可能であるかどうかについての決定（ステップ５９１４）を含む。例えば、メッセージが認証された場合でさえ、ギフト贈与者５５０２は、十分な金またはギフトプロセッサ５５１２が取引を許可するためのアカウントに結び付けられたクレジットを有しない場合がある。このため、このような決定をすることは、通常、アカウント記録の関連部分（単数または複数）にアクセスすることおよび資金が利用であることを確認することを含む。決定（ステップ５９１４において）がネガティブである場合、ギフトプロセッサ５５１２は、ギフト受信側５５１０に対して、メッセージの拒絶で応答する（ステップ５９１０）。再度、このような応答は、拒絶に対する理由を示し得る。ステップ５９１４における決定がポジティブである場合、ギフトプロセッサ５５１２は、命令（ｉ１）を実施する（ステップ５９１６）。この例では、ギフト贈与者５５０２からの命令（ｉ１）は、ギフト受信側５５１０に特定量の資金をアカウントからギフトまたは場合によっては寄付として支払うことである。このため、命令を実施する（ステップ５９１６）ことは、通常、アカウント記録の関連部分（単数または複数）にアクセスすること、条件つきでギフト贈与者５５０２のアカウントからの特定量の資金を貸方記入すること、およびこれによりアカウント記録を更新することを含む。ギフトプロセッサ５５１２は、次いで、ギフト受信側５５１０にのメッセージの許可を通知し（ステップ５９１８）、必要であれば、ギフト受信側５５１０にギフトの金銭量を取得するための命令を提供する。
【０２０４】
再度図５８を参照すると、ギフト受信側５５１０は、次いで、ギフトプロセッサ５５１２からの応答（これは、ギフト受信側５５１０がこのようなギフト量を受信するためにギフトプロセッサ５５１２を有するアカウントセットアップをまだ有していない場合にギフトを取得するための命令を含む）を受信する（ステップ５８０６）。
【０２０５】
（ｉｉｉ．金融機関アカウントを用いる販売取引のポイント）
図３の３者ＡＢＤＳシステム３００をインプリメントする第三のビジネスアプリケーション６０００が、図６０に示されている。この例では、買い手６００２を含むアカウントホルダーは、ＩＣカード等のカード６０５０の形態のデバイスを所有する。このデバイスは、販売場所のポイントで用いられることが可能である。販売カードリーダ６０５２のポイントは、英数字キーパッド６０５６、ディスプレイ６０５４、および、この場合、親指の指紋のリーダ６０５８を含む。販売カードリーダ６０５２のポイントは、データコネクタ６０６４を介した売り手キャッシュレジスタ／端末６０６０と通信する。売り手キャッシュレジスタ／端末６０６０は、それ自体のディスプレイ６０６２を有する。販売カードリーダ６０５２のポイントは、さらに、標準の金融ネットワーク６００８と通信する。この標準の金融ネットワーク６００８は、売り手と、この例では、金融機関６０１２、６０２２、６０３２によって表わされる種々の金融機関との間の通信と通信し正しくルーティングする能力を有する。各金融機関６０１２、６０２２、６０３２は、例えば、銀行、貯蓄貸付、クレジットカード会社その他である。金融機関６０１２、６０２２、６０３２に維持されたアカウントは、アカウントデータベース６０１４、６０２４、６０３４それぞれによって集約して参照され図６０に示される一以上のアカウントデータベースに維持されたアカウント記録に関連付けられる。この例では、金融機関６０１２は、カード６０５０の認可されたユーザに代理して、銀行業務またはクレジットカードアカウントを維持する。この例では、カード６０５０はアカウントデータベース６０１４内のカード６０５０の認可されたユーザのアカウントに結び付けられていることがさらに想定される。
【０２０６】
図６１を参照すると、データベース６０１４内の各アカウントは、アカウント番号６１１６を含む固有のアカウント識別子を含む。各アカウント番号６１１６は、アカウントデータベース６０１４内で、顧客特有の情報６１４２およびアカウント特有の情報６１４４を含むアカウント情報６１４０を識別する。本発明により、アカウント番号６１１６は、さらに、公開鍵情報６１１８を識別する。この公開鍵情報６１１８は、各アカウントのアカウントホルダーの少なくとも一つの公開鍵を含む。さらに、本発明の機能により、アカウント番号６１１６は、アカウントに結び付けられた公開鍵に対応する秘密鍵を保持するデバイスに対するデバイスプロファイル情報６１７０を識別する。
【０２０７】
図６０の例では、顧客特有の情報６１４２は、例えば、各アカウントホルダーの名称、アドレス、社会保障番号および／または税識別番号を含む。アカウント特有の情報６１４４は、例えば、現在の勘定残高、利用可能なクレジット、閉鎖データおよび現在の計算書の差額、および結び付けられたアカウント識別子を含む。買い手６００２のアカウントの公開鍵情報６１１８は、カード６０５０に保持された秘密鍵に対応する公開鍵を含む。デバイスプロファイル情報６１７０は、カード６０６０に特有の情報を含む。
【０２０８】
図６２に特に関し、買い手６００２は、買い手６００２が売り手のキャッシュレジスタ／端末６０６０にアイテムを支払うことをを要求する場合に売り手との取引を開始する（ステップ６２０２）。売り手は、売り手キャッシュレジスタ／端末６０６０上にアイテムを「打ち込む（ｒｉｎｇ　ｕｐ）」（ステップ６２０４）。そして、全不足額が買い手６００２にディスプレイ６０６２上に表示される。支払うために、買い手６００２は、カード６０５０を販売カードリーダ６０５２のポイントに挿入する（または、カードリーダ６０５２およびカード６０５２の両方がＩＳＯ／ＩＦＣスタンダード１４４４３（これは、本明細書において参考として援用される）による非接触の近接通信を備える場合、カード６０５０をカードリーダ６０５２の近傍に持っていく）（ステップ６２０６）。挿入（またはアプローチ）の際、販売カードリーダ６０５２のポイントは、開始され（ステップ６２０８）、これは、最小限で、販売カードリーダ６０５２のポイントからカード６０５０へのパワーを提供する。
【０２０９】
次に、売り手の貸金レジスタ／ターミナル６０６０は、販売カードリーダー６０５２ポイントがあることによってデータコネクタ６０６４を介して残高を伝送する（ステップ６２１０）。販売カードリーダ６０５２のポイントは、ディスプレイ６０５４上に差引請求額を表示する（ステップ６２１２）。好ましくは、販売カードリーダー６０５２のポイント６０５２は、カード６０５０上のメモリに維持された全ての利用可能な（または、少なくとも２つまたは５つの主な）支払いアカウントのリストを取り出して（ステップ６２１４）、そして、買い手６００２による選択のためにそれらを表示する（ステップ６２１６）。選択するための一つ以上のアカウントがある場合、次いで、買い手６００２は、リストに挙げられたアカウントのうちの一つ（または、購入量が一つ以上のアカウントの間で分離される場合、複数のアカウント）を選択する（ステップ６２１８）。ディスプレイ６０５４は、買い手６００２を促進して（ステップ６２２０）、英数字キーパット６０５６および親指の指紋用のスキャナ６０５８を用いて、ＰＩＮおよび右手親指の指紋等のファクタＢおよびＣエンティティ認証情報を提供する。−しかし、（支払いのための選択されたアカウント（単数または複数）の購入量および使用量を含む）提案された取引を認める場合に限る。一旦、ＰＩＮおよび親指の指紋が入力されると、販売カードリーダー６０５２のポイントは、ＰＩＮおよび親指の指紋のデジタル版をカード６０５０に伝送する（ステップ６２２２）。カードリーダー６０５２は、次に、デジタル署名のためのカード６０５０にメッセージを表すデータを伝送する（ステップ６２２４）。
【０２１０】
これに関して、メッセージを表すデータを受信すると、カード６０５０は、最初にデータに対するハッシュ値を計算して、次にカード６０５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによってメッセージに対するデジタル署名を生成する（ステップ６２２６）。カード６０５０は、次いで、デジタル署名を出力する（ステップ６２２８）。デジタル署名は、販売カードリーダー６０５２のポイントによって受信される。販売カードリーダー６０５２のポイントは、ＥＣにあるメッセージおよびデジタル署名を金融機関６０１２に（金融ネットワーク６００８を介して）伝送して（ステップ６２３０）、金融機関６０１２からの応答を待機する（ステップ６２３２）。この場合、ＥＣは、取引認証のために用いられる。
【０２１１】
図６３を参照して、金融ネットワーク６００８が正しくＥＣをルーティングした後、ＥＣは、金融機関６０１２によって販売カードリーダ６０５２のポイントから受信される（ステップ６３０２）。金融機関６０１２は、次いで、アカウントデータベース６０１４からアカウント番号６１１６によって識別される公開鍵を取り出す（ステップ６３０４）。公開鍵を用いて、金融機関６０１２は、メッセージを認証することを試みる（ステップ６３０６）。メッセージが（ステップ６３０８において）認証しない場合、金融機関６０１２は、メッセージを拒絶して、（金融ネットワーク６００８および販売カードリーダ６０５２のポイントを介して）売り手に応答する（ステップ６３１０）。このような応答は、拒絶の理由を含む。メッセージが（ステップ６３０８において）認証する場合、金融機関６０１２は、実際に、メッセージが識別されたアカウント番号６１１６に関連する正しいカード６０５０を所有する人物に由来する、と結論づける−（すなわち、ファクタＡエンティティの認証が得られる）。次いで、金融機関６０１２は、提供されたファクタＢおよびＣエンティティの認証情報（例えば、ＰＩＮおよび親指の指紋）が特定のメッセージをさらに所有するために十分であるかどうかを判定する。十分でない場合、金融機関６０１２は、拒絶のメッセージと共に（金融ネットワーク６００８および販売カードのポイントを介して）売り手に応答する（ステップ６３１０）。このような応答は、所望ならば、拒絶の理由を含み得る。エンティティ認証が（ステップ６３１２において）十分である場合、金融機関６０１２は、（以下に説明された）メッセージのさらなる処理を進める。
【０２１２】
この例において、メッセージを処理するさらなるステップは、命令（ｉ１）が実施され得るかどうかに関する判定を含む。命令（ｉ１）を実行することが不可能である場合、金融機関６０１２は、メッセージの拒絶に応答する（ステップ６３１０）。例えば、たとえメッセージが認証されたとしても、買い手６０５０は、取引を承認するための金融機関６０１２のためのアカウントに関連する十分なお金、または、貸金を持っていない可能性がある。従って、このような判定をするステップは、典型的にアカウント記録の関連する部分（単数または複数）にアクセスするステップおよび、資金が利用可能であることを確認するステップを包含する。判定が（ステップ６３１４において）ネガティブである場合、金融機関６０１２は、（金融ネットワーク６００８および販売カードリーダ６０５２のポイントを介して）メッセージに拒絶して売り手に応答する（ステップ６３１０）。再度、このような応答は、拒絶の理由を示し得る。判定がステップ６３１４においてポジティブである場合、金融機関６０１２は、命令（ｉ１）を実施する（ステップ６３１６）。この例において、買い手６００２からの命令（ｉ１）は、商品の購入のために特定のアカウントからの特定の量の資金を売り手に支払うことである。従って、命令を実施するステップ（ステップ６３１６）は、典型的に、アカウント記録の関連部分（単数または複数）にアクセスするステップと、（公知の様式で）買い手のアカウントから売り手への資金の特定の量の転送を初期化するステップと、これに応じてアカウント記録を借方に記入する／更新するステップとを含む。（以前にビジネスの適用で述べられた様に、上記の命令を処理するステップは、必ずしも本明細書中で述べられた他のステップと同時に起こらない）金融機関６０１２は、また、（金融ネットワーク６００８および販売かカードリーダ６０５２のポイントを介して）取引の承認を売り手に通告する（ステップ６３１８）。
【０２１３】
図６２に戻って、一度売り手が金融機関６０１２からの応答を受信すると、ステップ６２３２の判定は、ポジティブである。次に、売り手は、応答が取引の承認または拒絶であるかどうかを判定する（ステップ６２３４）。次いで、売り手は、買い手６００２に取引が承認されなかったことを通告する（ステップ６２３６）。一方、ステップ６２３４の判定がポジティブである場合、売り手は、買い手に製品およびレシートを与えることによって販売を完了する。
【０２１４】
上記の例から分かるように、買い手６００２からのＥＣは、たとえ、実際に、処理および認証のための金融機関６０１２に最終的に到達する前に、（金融ネットワーク６００８を介して）多くの「手」を通過する要求された購入および支払い方法のための取引認証として作動する。
【０２１５】
２．「人中心のデバイス（Ｐｅｒｓｏｎ−Ｃｅｎｔｒｉｃ　Ｄｅｖｉｃｅ）」　本発明の第２の局面は、本発明の第１の局面のＡＢＤＳシステムを組み込み、これに加えて、一つではなく複数のアカウントを有するアカウントホルダーのデバイスの公開鍵（ＰｕＫ）の関連を含む。さらに、複数のアカウント内の、いくつかのアカウントは、同じ（図２ａとともに説明された第三のポテンシャルのセットアップによって示された）アカウントオーソリティによって維持され得る。いくつかのアカウントは、別のアカウントオーソリティによって維持され得る。同じデバイスが複数のアカウントに関連し、任意の一つのアカウントの代表ではなく、むしろ、デバイス等のアカウントホルダーの代表であるので、本明細書中で「人中心のデバイス」として参照される。
【０２１６】
人中心のデバイスによって、アカウントホルダーが、複数のアカウントを用いて使用する一つのデバイスを登録可能であり、これにより、ＩＣカード、ＩＤカード等の複数のクレジットカードを有する必要性を排除することがすぐに明らかになる。例えば、人中心のデバイスは、一つ以上のバンクアカウント、クレジットカードアカウント、頻繁に飛行機を利用する人のアカウント、頻繁に外食をする人のアカウント、ガスカードのアカウント、電話カードアカウント、ビルディングＩＤアカウント、駐車場アカウント等に関連し得る。
【０２１７】
用いられたとき、人中心のデバイスは、本発明の第１の局面に関して説明されたデバイスのようなメッセージのためのデジタル署名を作成する。詳細には、人中心のデバイスは、人中心のデバイスに保持された秘密鍵を用いてメッセージのハッシュ値を暗号化することによってデジタル署名を生成する。また、デバイスのいくつかの実施形態において、人中心のデバイスは、適切なハッシングアルゴリズムを適用することによってメッセージのハッシュ値を計算する。さらに、いくつかの実施形態において、人中心のデバイスは、また、メッセージを構成する。
【０２１８】
メッセージ自体は、本発明の第１の局面に関して説明されたものと同じである。つまり、メッセージは、アカウントに相当する命令および固有の識別子を含む。しかし、人中心のデバイスを利用するＡＢＤＳシステムにおいて、特定のメッセージの固有のメッセージは、メッセージを受信するアカウントオーソリティによって維持されるアカウントに相当する必要がある。適切なアカウントオーソリティに対して中間の通信を介して電子通信の送達を安全にするために、電子通信は、特定のアカウントオーソリティ専用の閉じた通信媒体を介して送られる。通信媒体がインターネットのようなオープンなネットワークである場合、電子通信は、メッセージの認証および承認するための電子通信を受信する必要のあるアカウントオーソリティを識別するための十分な情報を含んでいる必要がある。適切なアカウントオーソリティの識別は、多くの異なる方法によって達成され得る。例えば、アカウント番号自体は、十分な情報を有する任意の中間のまたはルーティングエンティティを提供し得、どのアカウントオーソリティが電子通信を受信するべきかを認識する。別の例において、このような情報は、メッセージの構成中にアカウントホルダーによって、メッセージ構成中にデバイスまたはＩ／Ｏ支援要素によって、または、電子通信の伝送の位置部としてメッセージ中に直接入力され得る。
【０２１９】
（ａ．人中心のデバイスを用いる二者のＡＢＤＳシステム）
ここで図６４を参照して、「一般的な」人中心のデバイス６４５０を利用するＡＢＤＳ６４００の第１の好ましいインプリメンテーションが示される。人中心のデバイス６４５０は、本発明の第１の局面に関して以前に説明された任意のデバイスに類似し、かつ、同一である。従って、人中心のデバイス６４５０は、公開／秘密鍵の対のうちの秘密鍵を中に安全に保護する。さらに、人中心のデバイス６４５０は、通信媒体６４０８を介して通信可能である。この通信媒体６４０８は、インターネットを含み、以前に説明された任意のデバイスが同じ様態で通信する。
【０２２０】
ＡＢＤＳシステム６４００は、また、一旦少なくともひとつのアカウントがアカウントオーソリティ６４１２、６４２２、６４３２のうちの一つとともに確立されると、アカウントホルダー６４０２となるデバイスユーザを含む。各アカウントオーソリティ６４１２、６４２２、６４３２は、一つ以上のアカウントデータベースを維持して、集合的には図６４に関し、アカウントデータベース６４１４、６４２４、６４３４によって図６４で示されている本発明の第一の局面に関して、これらのアカウントデータベース６４１４、６４２４、６４３４の各々は、アカウントホルダーの記録を維持して、データベースの記録は、固有の識別子によってインデックスを付けられ、好ましくは固有のアカウント番号によって表される。
【０２２１】
この図において、アカウントホルダー６４０２は、アカウントオーソリティ６４１２で一つのアカウントを確立する。このアカウントは、「ａｃｃｔＩＤ（ａ）」によって指定された固有の識別子を有する。アカウントホルダー６４０２は、また、アカウントオーソリティ６４２２で一つのアカウントを確立する。このアカウントは、「ａｃｃｔＩＤ（ｂ）」によって指定された固有の識別子を有する。さらに、アカウントホルダー６４０２は、アカウントオーソリティ６４３２で二つのアカウントを確立する。一方のアカウントは、「ａｃｃｔＩＤ（ｃ１）」によって指定された固有の識別子を有し、他方のアカウントは、「ａｃｃｔＩＤ（ｃ２）」によって指定された固有の識別子を有する。たとえアカウントホルダー６４０２が３つの異なるアカウントオーソリティで４つの異なるアカウントを有しても、アカウントデータベース記録の各々は、図６４ａ、ｂ、ｃで示されるように同じ公開鍵（ＰｕＫ）をそれらの中に含む。処理（この処理によってアカウントホルダー６４０２が人中心デバイス６４５０を登録する）、および、これに対して、それぞれのアカウントオーソリティ６４１２、６４２２、６４３２を有する人中心のデバイス６４５０の公開鍵本発明の第一の局面のために説明された登録処理と比較可能である。
【０２２２】
処理（この処理によってアカウントホルダー６４０２がアカウントオーソリティ６４１２、６４２２、６４３２のうちの任意の一つと直接通信する）は、また、図２の二者ＡＢＤＳシステム２００に関して説明された処理のうちの任意の一つ、および、図６〜４９で説明された特定の２者とＡＢＤＳビジネスアプリケーションのうちの任意と同じである、または、類似している。例えば、図６５で示されたように、アカウントホルダー６４０２は、所望のアカウントホルダーでの電子接続を確立する（ステップ６５０２）ことによって、アカウントオーソリティ６４１２、６４２２、６４３２のうちの任意の特定の一つとの通信を初期化する。次に、アカウントホルダー６４０２は、エンティティ認証情報（例えば、デバイス６４５０内へとデバイス６４５１に関連するＰＩＮ、パスワード、パスフレーズ、または、生体測定情報）を入力する（ステップ６５４０）。次に、アカウントホルダー６４０２は、メッセージを生成する（ステップ６５０６）。デバイス６４５０ではもう生成しない場合、メッセージは、人中心のデバイス６４５０内にインポートされる／伝送される（ステップ６５０８）。この人中心のデバイス６４５０は、最初にデータに対するハッシュ値を計算することによって、次いでデバイス６４５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによってメッセージに対するデジタル署名を生成する（ステップ６５１０）。別の、および、あまり好ましくない実施例において、メッセージのハッシュ値は、デバイスの外で計算され、ついで、単にデジタル署名に対するこのようなハッシュ値の暗号する目的のためにデバイスに提供される。デバイス６４５０は、次いで、デバイスのデジタル署名コンポーネントからデジタル署名を出力する（ステップ６５１２）。従って、メッセージおよびデジタル署名は、適切なアカウントオーソリティに伝送される（ステップ６５１４）。
【０２２３】
メッセージを生成する正確な処理、および、メッセージに対するデジタル署名を生成する処理が人中心デバイス６４５０の特定の形式、および、特別な環境（この環境において用いられる（例えば、Ｉ／Ｏ支援要素と用いる））に応じて変化することは、留意されたい。例えば、人中心デバイス６４５０が携帯電話またはＰＤＡである場合、メッセージおよびメッセージのハッシュ値は、好ましくは、それぞれ、人中心のデバイス６４５０で直接に生成され、かつ、計算されて、ついでデジタル署名される。人中心のデバイス６４５０がドングルである場合、電子ロックと組み合わせて用いられる電子鍵、または、カードリーダーと組み合わせて用いられるカード、これらの全ては、好ましくは、アカウントホルダーのコンピュータと連動して用いられ、次いで、メッセージは、このコンピュータで生成され、または、受信される。ハッシュ値は、コンピュータによって生成される、および、人中心のデバイス６４５０に伝送されるか、または、人中心のデバイス６４５０がメッセージを受取ってハッシュ値自体を生成するかのいずれかをした後、次いで、人中心のデバイス６４５０が、メッセージに対するデジタル署名を生成する。人中心のデバイスは、皮下インプラント、個人的なアイテム、または、公開インタフェースの場（例えば、ＡＴＭマシン、カードリーダー、ＲＦ受信器／伝送器、または、販売リーダーの場所）で用いられ得るカードである場合、メッセージおよびメッセージのハッシュ値は、好ましくは、人中心のデバイス６４５０から外で生成され、ハッシュ値は、人中心デバイス６４５０に伝送されて、次いで、人中心のデバイス６４５０は、メッセージに対するデジタル署名を生成する。
【０２２４】
好ましくは、用いられた人中心のデバイス６４５０の特別のタイプにかかわらず、アカウント番号の各々（または、関連する固有のアカウント識別子）は、人中心のデバイス６４５０内のメモリに格納される。
【０２２５】
最終的に、人中心のデバイス６４５０は、Ｉ／Ｏ支援要素または他の外の装置からの援助で、または、援助なく、通信媒体６４０８を通って電子通信のメッセージおよびデジタル署名を特定のアカウントオーソリティに伝送する。このアカウントオーソリティで、人中心のデバイス６４５０は、既に、電子接続を確立している。上記のメッセージが生成される方法にかかわらず、メッセージは、固有のアカウント識別子、および、アカウントオーソリティによって実行されるべき命令（ｉ１）を含む。さらに、人中心のデバイス６４５０がアカウントオーソリティ（このアカウントオーソリティで、その者は、秘密鍵に関連するアカウントを唯一登録している）と通信している限り、固有のアカウント識別子は、実際に、公開鍵自体である。従って、公開鍵は、アカウントホルダー６４０２とアカウントオーソリティ６４１２および６４２２との間の二者の直接的な通信のための固有のアカウント識別子として使用可能であるが、アカウントオーソリティ６４３２との通信のための固有のアカウント識別子として使用可能ではない。このアカウントオーソリティ６４３２は、アカウントホルダー６４０２のための二つの別のアカウントを維持し、両アカウントは、同じ公開鍵に関連する。
【０２２６】
アカウントホルダー６４０２から受信された電子通信に応答して、アカウントオーソリティ６４１２、６４２２、６４３２によって実施されるステップは、命令（ｉ１）、および、アカウントオーソリティが関与するビジネスのタイプ、または、アカウントオーソリティによって維持されるビジネスのタイプのコンテンツから生じるバリエーションのみを有する図６〜４９の特定の２者のＡＢＤＳビジネスアプリケーションのうちの任意にある特定のアカウントオーソリティによって実施されるステップと基本的に同じである。実施された一般的なステップは、図６６において示される。これらのステップは、電子通信を受信するステップ（ステップ６６０２）と、アカウントデータベースにある関連する記録からの公開鍵を受信するステップ（ステップ６６０４）と、そのようにして得られた公開鍵を用いてメッセージの認証を試みるステップとを包含する。メッセージが（ステップ６６０８において）認証する場合、アカウントオーソリティは、エンティティ認証が十分に提供されているかどうかを判定する（ステップ６６１２）。十分なエンティティが認証されている場合、アカウントオーソリティは、さらにメッセージを処理する（ステップ６６１４）。このステップ６６１４は、命令（ｉ１）を実施するステップを包含する（または、少なくとも実施を試みる）。メッセージが認証しない場合（ステップ６６０８）、十分なエンティティ認証が存在せず（ステップ６６１２）、（ステップ６６１４において）命令（ｉ１）の実行が不可能な場合、アカウントオーソリティは、メッセージの拒絶、および、潜在的には、拒絶の根拠または理由と通信する送信側に応答する（ステップ６６１０）。
（ｂ．人中心のデバイスを用いた第三者ＡＢＤＳシステム）
ここで図６７を参照して、人中心のデバイス６７５０を利用するＡＢＤＳシステム６７００の第２の好ましいインプリメンテーションが示される。図６７のこの第２の好ましいインプリメンテーションと図６４の第１の好ましいインプリメンテーションとの間の唯一重要な違いは、中間者６７１０、および、アカウントホルダー６７０２からアカウントオーソリティ６７１２、６７２２、６７３２のうちの一つへの電子通信が中間者６７１０に通信されるという事実である。従って、この中間者は、電子通信をアカウントホルダー６７０２によって指定された適切なアカウントオーソリティ６７１２、６７２２または６７３２に転送する。人中心のデバイス６７５０との第三者ＡＢＤＳ取引の方法は、図５０〜６３を参照する、以前に説明された第三者ＡＢＤＳ取引の方法とかなり類似している。
【０２２７】
図６８を特に参照して、アカウントホルダー６７０２は、最初に、人中心デバイス６７５０を用いて通信媒体６７０８を通る中間者６７１０との電子接続を確立することによって、中間者６７１０との取引を初期化する（ステップ６８０２）。再び、人中心のデバイス６７５０の正確な形式は、変化し得るが、本発明の第１の局面に関して説明された任意のデバイスと類似している、または、同一である。好ましくは、次に、アカウントホルダー６７０２は、エンティティ認証情報（例えば、デバイス６７５０内へとデバイス６７５０に関連するＰＩＮ、パスワード、パスフレーズ、または、生体測定情報）を入力する（ステップ６８０４）。電子接続の手段によって、アカウントホルダー６７０２は、アカウントホルダー６７０２が中間者６７１０に実施してもらいたい命令（ｉ２）を定式化する（ステップ６８０６）。中間者６７１０が命令（ｉ２）を実施するために、中間者６７１０は、アカウントホルダーのアカウント認証６７１２、６７２２、６７３２のうちの一つからの認証および承認を必要とする。この理由として、アカウントホルダー６７０２は、適切なアカウントオーソリティからのこのような認証および承認を得る目的のためにメッセージを生成する（ステップ６８０８）。
中間者６７１０がアカウントホルダーのどちらのアカウントオーソリティがメッセージを受信するかを知るために、アカウント番号自体が適切なアカウントオーソリティを識別するか、電子通信がどのアカウントオーソリティ（ＡＡ＃）が取引の認証および承認のための電子通信を受信することを必要とするかを示すかのいずれかである。
【０２２８】
一度メッセージが構成されると、メッセージは、（メッセージが実際にデバイス６７５０によって、または、デバイス６７５０内に構成されない場合）デバイス６７５０へと伝送される／提供されるべきである（ステップ６８１０）。従って、デバイス６７５０は、最初に、データに対するハッシュ値を計算することによって、次いで、デバイス６７５０内に保持された秘密鍵を用いてハッシュ値を暗号化することによってメッセージに対するデジタル署名を生成する（ステップ６８１２）。別の実施形態、および、あまり好ましくない実施形態において、メッセージのハッシュ値は、デバイス６７５０の外で計算され、次いで、デジタル署名のこのようなハッシュ値の暗号化の目的のためのみにデバイス６７５０に提供される。次いで、デバイス６７５０は、デバイス６７５０のデジタル署名コンポーネントからのデジタル署名を出力する（ステップ６８１４）。メッセージ、デジタル署名、および、命令（ｉ２）は、従って、通信媒体６７０８を介して中間者６７１０に伝送される（ステップ６８１６）。本明細書全体の至るところで説明されたように、人中心のデバイス６７５０は、電子通信を中間者６７１０に伝送するステップを完了するために、Ｉ／Ｏ支援要素または他の外部デバイス（図示せず）を必要とし得る。
図６９に示されたように、中間者は、アカウントホルダー６７０２からの電子通信を受信する（ステップ６９０２）。中間者６７１０は、転送された電子通信を受信する必要のあるアカウントオーソリティのアイデンティティーに関する情報（ＡＡ＃）を含んだ、アカウントホルダー６７０２から中間者６７１０への任意の命令（ｉ２）を抽出する（ステップ６９０４）。図６７に示されるように、命令（ｉ２）は、中間者６７１０に、アカウントオーソリティ６７１２が転送された電子通信を受信するための適切なアカウントオーソリティであることを知らせる。中間者６７１０は、メッセージおよびデジタル署名を含む電子通信を命令（ｉ１）の承認および認証に対するアカウントオーソリティ６７１２に転送する（ステップ６９０６）。次いで、中間者６７１０は、アカウントオーソリティ６７１２からの応答を待つ（ステップ６９１０）間、これらの命令（ｉ２）（例えば、購入要求）をアカウントオーソリティ６７１２からのメッセージ支払いの「オン　ホールド（ｏｎ　ｈｏｌｄ）」保留承認に位置づける。
ここで図７０を参照して、中間者６７１０を介してアカウントホルダー６７０２から受信された電子通信に応答するアカウントオーソリティ６７１２によって実施されたステップは、次でより詳細に記述される。最初に、アカウントオーソリティ６７１２は、中間者６７１０から電子通信を受信する（ステップ７００２）。電子通信に提供されたアカウント番号（ａｃｃｔＩＤ（＃））を用いて、アカウントオーソリティ６７１２は、アカウントデータベース６７１４にある関連する記録からの公開鍵を取り出す（ステップ７００４）。この公開鍵を用いて、アカウントオーソリティ６７１２は、メッセージの認証を試みる（ステップ７００６）。メッセージが（ステップ７００８で）認証しない場合、アカウントオーソリティ６７１２は、メッセージを拒絶して応答する（ステップ７０１０）。このような応答は、拒絶に対する理由を含む。メッセージが（ステップ７００８で）認証しない場合、アカウントオーソリティ６７１２は、メッセージが、実際に識別されたアカウント番号に関連する正しいデバイス６７５０を所有する人物から送られたと結論付ける−（すなわち、ファクタＡエンティティ認証が得られる）。アカウントオーソリティ６７１２は、次いで、提供されたエンティティ認証が特定のメッセージのさらなる所有に対して十分であるかどうかを判定する（ステップ７０１２）。十分ではない場合、アカウントオーソリティ６７１２は、メッセージの拒絶に応答する（ステップ７０１０）。このような応答は、拒絶の理由を示し得る。エンティティ認証が（ステップ７０１２において）十分である場合、アカウントオーソリティ６７１２は、メッセージの（以下で述べられる）さらなる処理を続ける。
【０２２９】
メッセージのさらなる処理は、命令（ｉ１）が実施され得るかどうかに関する判定（ステップ７０１４）を含む。例えば、たとえメッセージが認証しても、アカウントホルダー６７０２のアカウントは、認証され得ない、あるいは、アカウントオーソリティ６７１２が命令（ｉ１）またはメッセージを承認するこのような様態で命令（ｉ１）を取り扱い得ない。判定が（ステップ７０１４において）ネガティブである場合、アカウントオーソリティ６７１２は、メッセージに拒絶して中間者６７１０に応答する（ステップ７０１０）。再び、このような応答は、拒絶の理由を示し得る。判定がステップ７０１４においてポジティブである場合、アカウントオーソリティ６７１２は、命令（ｉ１）を実施する（ステップ７０１６）。アカウントオーソリティ６７１２はまた、中間者６７１０にメッセージおよび命令（ｉ１）の実行の承認を通告する（ステップ７０１８）。
図６９に戻り参照して、一度中間者６７１０がアカウントオーソリティ６７１２からの応答を受信すると、ステップ６９１０の判定はポジティブである。次に、中間者６７１０は、応答が取引の承認または拒絶のいずれかであるかを判定する（ステップ６９１２）。アカウントオーソリティ６７１２が取引を承認しない場合、中間者６７１０は、アカウントホルダー６７０２に、メッセージが拒絶されたこと、および、命令（ｉ２）が実行されていないことを通告する（ステップ６９１４）。一方、ステップ６９１２の判定がポジティブである場合、中間者６７１０は、以前オンホールドとされた命令（ｉ２）を実行する（ステップ６９１６）。次に、中間者６７１０は、取引が承認されたこと、および、命令（ｉ２）が実行されているまたは実行されたことをアカウントホルダー６７０２に通告する。
３．中央鍵オーソリティ
本発明の第３の局面は、本発明の第１および第２局面のＡＢＤＳシステムを組み込み、これらに加えて、デバイスのユーザの特定のＰｕＫにリンクされたアカウント情報（本明細書中では「登録情報」）のデータベースの維持を含む。言い換えると、データベースは、公開鍵が関連する複数のアカウントを識別する。データベースを維持するエンティティは、本明細書中で「中央鍵オーソリティ」として参照される。
【０２３０】
登録情報は、公開鍵（ＰｕＫ）およびデジタル署名を生成する特定のデバイスに関する情報の一つ以上の以下のタイプを含む。第三者のアイデンティティー（このアイデンティティーとともに、デバイスのユーザは、デバイスに対するＰｕＫにリンクされたアカウントを有し、それぞれの第三者に対してユーザのＰｕＫにリンクされたアカウントの各々を識別する）；本発明の他の局面に従うデバイスの公開鍵にリンクされた情報；ユーザのメールアドレス、クレジットカード情報、年齢等のユーザに特定の情報；応用可能なら、中央鍵オーソリティによって維持されたユーザに特定の情報を検証する際に適用された認証技術。さらに、中央鍵オーソリティは、登録情報が公開鍵を元に取り出し得るように好ましくは、ユーザの公開鍵に対するユーザの登録情報にインデックスを付ける。言い換えると、デバイスのユーザは、中央鍵オーソリティの「アカウントホルダー」である。
【０２３１】
本発明のこの局面に従って、中央鍵オーソリティは、第三者に対して、適切にまたは要求されたように、登録情報のいくつかまたは全てを判定する。ユーザが第三者とともにＡＢＤＳアカウントを有する、または、ユーザが第三者とともに新しいＡＢＤＳアカウントを確立することを望む−アカウントにおける取引を表す命令を含むメッセージ（デバイスを用いてデジタル署名されているこのようなメッセージ）とともにＥＣを送ることを望むとき、登録情報は流布される。例えば、第三者によって維持された登録情報が特定のアカウントとして期限切れしたときに、登録情報の流布が起きる。
【０２３２】
中央鍵オーソリティによって維持された登録情報は、様々な方法で得られる。例えば、公開鍵および公開鍵にリンクされた情報は、好ましくは、デバイスの製造業者、または、デバイスの公開鍵およびセキュリティプロフィールを所有する他の信頼できるエンティティから得られる。第三者のアイデンティティー（ユーザは、このアイデンティティーでデバイスのためのＰｕＫにリンクされたアカウント、および、各このような第三者に対するユーザのＰｕＫにリンクされたアカウントを識別するアカウント識別子を有する）は、好ましくは、ユーザから得られ、ユーザが中央鍵オーソリティで登録するとき（ユーザの命令で、中央鍵オーソリティが第三者でユーザのためにアカウントを確立するとき、または、ユーザの命令で、第三者が中央鍵オーソリティからの登録情報を要求するとき）に得られる。
【０２３３】
本発明のこの第三の局面に従う中央鍵オーソリティによって、ユーザの古い（および、期限切れした可能性のある）デバイスに代わってユーザの新しいデバイスでユーザのＰｕＫにリンクされたアカウントを更新するといった便利さが提供され得る。このような更新は、好ましくは、古いデバイスの公開鍵と、新しいデバイスの明確に識別された公開鍵を古いデバイスを用いてデジタル署名される明確に識別された第三者のアカウントに関連付けるための命令を含むメッセージ含む中央鍵オーソリティに単にＥＣを送ることによって達成される。
このようなＥＣを受け取ると、中央鍵オーソリティは、古いデバイスの識別された公開鍵を用いてＥＣのメッセージを認証する。認証が成功すると、中央鍵オーソリティは、古いデバイスに相当する公開鍵のための登録情報を取り出す。次いで、中央鍵オーソリティは、新しいデバイスの公開鍵で登録情報を更新して、ユーザに明確に識別された第三者の各々にＥＣを伝送する。このＥＣは、第三者の各々にユーザの以前の公開鍵に代わって新しいデバイスの公開鍵でユーザのそれぞれのアカウント記録を関連付けることを要求する。
【０２３４】
上記の一般的に説明されたシステムは、以下の図７１ａ〜７２でより詳細に示される。中央鍵オーソリティ７１９０およびアカウント記録のデータベース７１９４を含む本発明の第三の局面に従うシステム７１００ａは、図７１ａで示される。再度、アカウントホルダー７１０２は、デバイス７１５０を所有する。このデバイス７１５０は、公開／秘密鍵の対のうちの固有の秘密鍵を安全に守る。好ましくは、デバイスは、また、内部に公開鍵（ＰｕＫ１）７１１８を保持する。この公開鍵７１１８は、デバイス７１５０からエクスポートされ得る。図７１ａに見られるように、デバイス７１５０の公開鍵（ＰｕＫ１）は、アカウントオーソリティ７１１２で以前に登録されており、固有のアカウント識別子「ａｃｃｔＩＤ（ａ）」を有するアカウントと関連し、アカウント番号（ａｃｃｔＩＤ（ａ）の入力に応答してデータベース７１１４から取出し可能である（公開鍵（ＰｕＫ１）に基づいた）アカウントデータベース７１１４のアカウント記録に格納される。
【０２３５】
アカウントホルダー７１０２は、また、別のデバイス７１５１を所有する。この図のデバイス７１５１は、本発明の第二の局面に関して説明された人中心のデバイスである。人中心のデバイス７１５１は、内部に公開−秘密鍵のうちの異なる秘密鍵を安全に守る。好ましくは、デバイス７１５１は、内部に公開鍵（ＰｕＫ２）７１２８を保持する。この公開鍵７１２８は、デバイス７１５１からエクスポートされ得る。図７１ａの図から理解されるように、人中心のデバイス７１５１の公開鍵（ＰｕＫ２）は、二つのアカウントオーソリティで登録されている；アカウントオーソリティ７１２２では、ＰｕＫ２は、固有のアカウント識別子「ａｃｃｔＩＤ（ｂ）」に関連し、かつ、アカウントデータベース７１２４にあるアカウント記録に格納される；アカウントオーソリティ７１３２では、ＰｕＫ２は、固有のアカウント識別子「ａｃｃｔＩＤ（ｃ１）」および「ａｃｃｔＩＤ（ｃ２）」を有する少なくとも二つの別のアカウントに関連する。両アカウントａｃｃｔＩＤ（ｃ１）およびａｃｃｔＩＤ（ｃ２）は、アカウントデータベース７１３４にあるそれぞれのアカウント記録に格納される。
【０２３６】
中央鍵オーソリティ７１９０でのデータベースアカウントを確立する際に、図７１ａおよび７２を参照して、アカウントホルダー７１０２は、好ましくは、追跡されるべき各アカウントに対して中央鍵オーソリティ７１９０に以下の情報を提供する：（図７２の列に記録された）アカウントに関連するそれぞれのデバイス７１５０、７１５１にうちの公開鍵７１１８、７１２８；固有の識別子（例えば、ａｃｃｔＩＤ（ａ）；ａｃｃｔＩＤ（ｂ）；ａｃｃｔＩＤ（ｃ１）；ａｃｃｔＩＤ（ｃ２））、ならびに、（図７２の列７２４４に記録された）特定のアカウントの各々に対する、アカウントオーソリティの識別子およびアカウントのタイプ等の他のアカウントに特定の情報。アカウントホルダー７１０２は、また、好ましくは、顧客に特定の（すなわち、個人の）情報、および、（図７２の列７２４０に記録された）このようなアカウントに関連する各デバイス７１５０、７１５１に関するデバイスプロフィール情報を中央鍵オーソリティ７１９０に提供する。他のアカウント属性は、また、アカウントデータベース７１９４に記録され得、かつ、アカウントホルダー７１０２、または、直接にそれぞれのアカウントオーソリティ７１１２、７１２２、７１３２のいずれかから得られ得る。好ましくは、中央鍵オーソリティ７１９０は、アカウントホルダー７１０２を、（図７２の列７２３０に記録された）登録アカウント番号「ＲａｃｃｔＩＤ（ａ）」等の固有のアカウント識別子で割り当てる。
【０２３７】
さらに図７１ａを参照して、アカウントホルダー７１０２は、通信媒体７１０８を通って（本発明の第一の局面に関して説明された）二者のＡＢＤＳの様態で中央鍵オーソリティ７１９０と電子通信可能である。言い換えると、アカウントホルダー７１０２は、デバイス７１５０、あるいは、アカウントホルダーの中央鍵オーソリティのアカウント番号（ＲａｃｃｔＩＤ（ａ））および命令（ｉ３）を含むメッセージ（Ｍ）、ならびに、メッセージのデジタル署名（ＤＳ）を含む電子通信を中央鍵オーソリティ７１９０に送ることによって、人中心のデバイス７１５１に関連する新しいアカウントを登録し得る。
アカウントホルダー７１０２、ならびに、このようなメッセージを作る、署名する、送る、および、認証する中央鍵オーソリティ７１９０によって実施された実際のステップは、詳細には説明されない。なぜなら、このようなステップは、既にかなり長く説明されてきた二者ＡＢＤＳ通信の方法に密接に追随するからである。興味深いことに、中央鍵オーソリティ７１９０によって維持されたアカウントホルダー７１０２のアカウント７２３０が、実際、複数の公開鍵７２１８に関連しているために、メッセージを認証する処理は、中央鍵オーソリティに潜在的に一つ以上の公開鍵を用いるメッセージの認証を試みることを要求する。アカウントホルダー７１０２が中央鍵オーソリティ７１９０に送る典型的な命令（ｉ３）は、例えば、最初に、中央鍵オーソリティのアカウントを設定する；新しいデバイス７１５０または７１５１（および相当する公開鍵）を登録情報に加える；登録情報にある個人情報を加える、更新する、または、削除する；特定のアカウントに関連するアカウント識別子を加える、更新する、または、削除する；新しいアカウントオーソリティ（および、アカウント）を存在する公開鍵に加える；存在するアカウントオーソリティに関する情報を加える、または、修正する等の要求を含む。
図７２を再び参照すると、中央鍵オーソリティ７１９０によって維持されたアカウントデータベース７１９４の例が示される。ここで、データベース７１９４は、登録アカウントＩＤ番号７２３０によって統括され、登録アカウントＩＤ番号７２３０に関連する：相当する顧客に特定の情報７２４２、例えば、名前、アドレス、社会保証番号および／または税ＩＤ番号、クレジットカード情報；特定の顧客の各公開鍵を含む公開鍵情報７２１８；それぞれの公開鍵に相当する秘密鍵を保持する各デバイスのためのデバイスプロフィール情報７２７０（このようなデバイスプロフィール情報は、セキュリティの特徴、デバイスの認証能力、製造履歴、および、取引履歴を含む）；アカウントに特定の情報７２４４（例えば、アカウントオーソリティの名前、アカウントに関連する固有のアカウント識別子（ａｃｃｔＩＤ）、アカウントオーソリティのアドレス、アカウントオーソリティによって維持されたアカウントのタイプ等）を含む、公開鍵に関連するアカウント（単数または複数）の全てのリスト。
【０２３８】
中央鍵オーソリティ７１９０が特定のアカウントホルダー７１０２に関連する複数の公開鍵を追跡するための便利な様態、および、公開鍵の各々に関連するアカウントの各々を追跡する便利な様態を提供することは、直ちに理解される。このような情報に容易かつ即座のアクセスは重要である。例えば、特にアカウントホルダー７１０２の人中心のデバイス７１５１が紛失した、または、盗難されたとき、あるいは、その秘密鍵（ＰｕＫ２）が危ういとき、適切なアカウントオーソリティ７１２２、７１３２は、通告される必要がある。
【０２３９】
このような状況において、図７１ｂで示されたように、アカウントホルダー７１０２は、このような中央鍵オーソリティ７１９０に（より便利な様態において明らかに、おそらく、デバイスまたは秘密鍵（ＰｒＫ２）は、もはやメッセージのデジタル署名を生成するための利用可能ではない）通告する。中央鍵オーソリティ７１９０は、順に各オーソリティ７１２２、７１３２に連絡する。次いで、各アカウントオーソリティ７１２２、７１３２は、アカウントホルダー７１０２が新しい公開鍵（ＰｕＫ２−新）を関連するアカウント［ａｃｃｔＩＤ（ｂ）；ａｃｃｔＩＤ（ｃ１）；ａｃｃｔＩＤ（ｃ２）］に関連させるまで、使用をやめる（または、特定のデバイス７１５１および公開鍵７１２８によってアカウントの使用を少なくともやめる）。
【０２４０】
さらに、図７１ｃで示されたように、一度アカウントホルダー７１０２が新しいデバイス、および、相当する新しい公開鍵（ＰｕＫ２−新）７１０２を得ると、アカウントホルダー７１０２は、新しい公開鍵（ＰｕＫ２−新）７１３８で中央鍵オーソリティ７１９０を更新するのみ必要である。次いで、中央鍵オーソリティ７１９０は、好ましくは、関連するアカウント［ａｃｃｔＩＤ（ｂ）；ａｃｃｔＩＤ（ｃ１）；ａｃｃｔＩＤ（ｃ２）］に関連させ、かつ、それぞれのアカウント［ａｃｃｔＩＤ（ｂ）；ａｃｃｔＩＤ（ｃ１）；ａｃｃｔＩＤ（ｃ２）］を再びアクティブにするために、新しい公開鍵（ＰｕＫ２−新）７１３８を適切なアカウントオーソリティ７１２２、７１３２通信する。
【０２４１】
図７１ｄで示されたように、中央鍵オーソリティ７１９０は、また、新しいアカウントオーソリティ７１４２で新しいアカウントを確立する際に有益である。この点に関して、中央鍵オーソリティ７１９０が新しいアカウントオーソリティ７１４２でアカウントを確立することを望むアカウントホルダー７１０２のための記録を維持する場合、新しいアカウント（ａｃｃｔＩＤ（ｄ））は、好ましくは、アカウントホルダー７１０２の要求で中央鍵オーソリティ７１９０によって確立される。特に、アカウントホルダー７１０２は、アカウントホルダー７１０２に対するアカウントデータベース７１９４から新しいアカウントオーソリティ７１４２に該当する情報を伝送することを中央鍵オーソリティ７１９０に命令する。新しいアカウント（ａｃｃｔＩＤ（ｄ））に関連するべきアカウントホルダー７１０２の公開鍵（Ｐｕｋ−新）７１３８は、該当する情報内に含まれる。続いて、所望のアカウントオーソリティ７１４２は、中央鍵オーソリティ７１９０から受信された情報を用いて、所望のアカウントオーソリティ７１４２のアカウントデータベース７１４４にある初期の記録を確立する。次いで、アカウントオーソリティ７１４２によって要求され得る任意のさらなる情報は、新しいアカウントホルダー７１０２および更新されたアカウントデータベース７１４４にある新しい記録から得られ得る。
【０２４２】
中央鍵オーソリティ７１９０およびアカウントオーソリティ７１１２、７１２２、７１３２、７１４２が互いにそれら自体の公開鍵を登録すると想定すると、それらの間の上記の通信は、電子通信で、および、二者ＡＢＤＳの様態で、起こり得る。
【０２４３】
４．動的リスク解析を取引に適用する
認識されたように、上記で説明されたＡＢＤＳシステムの信用は、秘密鍵の合法的な所有および使用に依存する。ＥＣに含まれたメッセージをデジタル署名するために秘密鍵を不正に使用することは、単にメッセージの認証を通して検出され得ない。従って、デバイスが物理的に窃盗される、または、秘密鍵を発見されて、複製されて、元のデジタル署名を別のデバイスで使用可能にされることのいずれかによって、デバイスの秘密鍵が盗難される場合、上記のＡＢＤＳシステムは、潜在的に、不正に使用される疑いがある。
【０２４４】
デバイス自体の窃盗を通してのデバイスの不正使用を防ぐために、以前に説明されたファクタＢエンティティ認証、および／または、ファクタＣエンティティ認証の技術および資格が用いられる。秘密鍵を発見して、引き続いて複製されて、別のデバイスで使用されることを防ぐために、デバイスは、遮蔽、ゼロ化、タンパー（ｔａｍｐｅｒ）証拠およびタンパー応答、あるいは、内部に含まれる秘密鍵（および、他の守られたデータ）を保護する他のセキュリティ機能を用いて製造される。このようなセキュリティ機能は、ハードウェア、ソフトウェアを含み、安全なコンピュータチップおよび他の暗号モジュールを製造する分野において周知である。
【０２４５】
このような安全機能のための資格は、Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄｓ　Ｐｕｂｌｉｃａｔｉｏｎ　１４０−１，Ｓｅｃｕｒｉｔｙ　Ｒｅｑｕｉｒｅｍｅｎｔｓ　ｆｏｒ　Ｃｒｙｐｔｏｇｒａｐｈｉｃ　Ｍｏｄｕｌｅｓ，ＵＳ　ＤＯＣ／ＮＢＳ，１９９４年１月１１日（本明細書中では、「ＦＩＰＳ　ＰＵＢ　１４０−１」とする）で明確に述べられ、本明細書中で参照として援用される。Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄｓ　Ｐｕｂｌｉｃａｔｉｏｎ　１４０−２，Ｓｅｃｕｒｉｔｙ　Ｒｅｑｕｉｒｅｍｅｎｔｓ　ｆｏｒ　Ｃｒｙｐｔｏｇｒａｐｈｉｃ　Ｍｏｄｕｌｅｓ，ＵＳ　ＤＯＣ／ＮＢＳ，２００１年５月２５日（本明細書中では、「ＦＩＰＳ　ＰＵＢ　１４０−２」とする）は、本明細書中で参照として援用される。ＦＩＰＳ　ＰＵＢ　１４０−１、および、１４０−２は、また、デバイスのセキュリティ機能に基づいたデバイスによって満たされ得るセキュリティレベルを規定する。これらの各々は、難解さ−時間および費用の面において−の様々なレベルを表すセキュリティレベルを規定する。デバイスの秘密鍵を見分けようと試みる際にこれらに遭遇する。４つのセキュリティレベルは、セキュリティレベル４が利用可能なセキュリティの最も高いレベルであるように規定される。
【０２４６】
このようなセキュリティ機能に関する明細書は、また、Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ（ＴＰＭ）　Ｓｅｃｕｒｉｔｙ　Ｐｏｌｉｃｙ　Ｖｅｒｓｉｏｎ　０．４５，ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ，２０００年１０月、および、ＴＣＰＡ　ＰＣ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　０．９５，ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ，２００１年７月４日（両明細書は、本明細書中で参照（まとめて、「ＴＣＰＡ文書」）として援用される。）、ならびに、Ｃｏｍｍｏｎ　Ｃｒｉｔｅｒｉａ　ｆｏｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ　Ｓｅｃｕｒｉｔｙ　Ｅｖａｌｕａｔｉｏｎ，Ｓｍａｒｔ　Ｃａｒｄ　Ｐｒｏｔｅｃｔｉｏｎ　Ｐｒｏｆｉｌｅ，Ｄｒａｆｔ　Ｖｅｒｓｉｏｎ　２．１ｄ，ＳＭＡＲＴ　ＣＡＲＤ　ＳＥＣＵＲＩＴＹ　ＵＳＥＲ　ＧＲＯＵＰ，２００１年３月２１日（これは、本明細書中で参照として援用される（以後、「スマートカード保護プロフィール」）で示される。
【０２４７】
秘密鍵および他の保護されたデータの発見を防御するデバイスの特徴は、デバイスの「セキュリティの特徴」として本明細書中で引用される。ユーザを認証することによってデバイスの認証された使用を防御するデバイスの特徴は、デバイスの「認証能力」として本明細書中で引用される。（暗号化モジュールまたはＴＰＭを含む）デバイスの「セキュリティ機能」は、セキュリティの特徴および認証能力等の機能を含む。これらの機能の資格は、上記で引用された参考文献で明確に記述される。
【０２４８】
残念なことに、以前に触れた防御は、一般的にデジタル署名システム全体内の不正のリスクを低減するが、メッセージおよび相当するデジタル署名を含む任意の一つの特定のＥＣの受信側は、デジタル署名を生成するために用いられるデバイスに不慣れであり得、従って、デバイスの窃盗または秘密鍵の発見のいずれかを通して、デジタル署名が不正に生成され得た否かのリスクを読み取ることができない。さらに、受信側は、一般的に、秘密ではない、または、生体測定の値が送信側と受信側との間に共有されるとき、デジタル署名が不正に生成されたかどうかのリスクを読み取ることができない。このような状況において、受信側は、現在、デジタル署名を生成するために用いられたデバイスが盗難されていないことを認めることを、および、デジタル署名を生成するために用いられたデバイスが発見および使用からその秘密鍵を保護するために十分な防御を有することを認めることを盲目的に信じることに頼らなけらばならない。
【０２４９】
従って、本発明の第４の局面が次に説明される。本発明の第４の局面は、本発明の第１の局面のＡＢＤＳシステムを組み込み、これに加えて、認証するメッセージが不正に、不注意に、または、知らずに署名されていたというリスクまたは可能性を読み取る目的のために、ならびに、メッセージ内に含まれた命令（ｉ１）が実施されるべきかどうかを判定する目的のためにアカウントオーソリティによる数多くの要因の識別および評価を含む。評価および考慮される要因は、メッセージのためのデジタル署名を生成するために用いられたデバイスの認証能力、もしあれば、デバイスによって得られたまたはＥＣに提供されたエンティティ認証のタイプおよび十分さ、デバイスのセキュリティの特徴、メッセージの作成および伝送に関連する環境要因、デバイスまたはメッセージに関連する該当するアカウントに関連する取引履歴、命令（ｉ１）が識別されたアカウントで実施され得るかどうかを含む他のアカウントまたはビジネスに特定の要因（例えば、要求された払い戻しまたは転送を対象とするアカウントに十分な資金があるだろうか。アカウントホルダーは、要求された情報を閲覧するために認証されるであろうか。アカウントホルダーは、要求されたスペースを入力するために認証されるであろうか。アカウントホルダーは、要求された取引を行うために認証されるであろうか。アカウントホルダーは、特定された連絡内に入力するために認証されるであろうか。）を含む。
デバイスの認証能力は、デバイスのユーザの認証に関するファクタＢおよびＣエンティティ認証のいずれかまたは両方を実施するこれらのコンポーネントを含む。デバイスの認証能力（または、それらの欠如）を知ることによって、受信側は、認証されたユーザ以外の誰かがデバイスを利用して、デジタル署名を生成するかどうかの可能性を読み取ることが出来る。技術が時間をかけて発達し、このようなセキュリティの特徴の効果を減少させ、結果的に、デバイスの実際のセキュリティレベルの低下とするように、デバイスのセキュリティの特徴−単純に述べられたデバイスのセキュリティレベルではなく−を知ることはまた、重要である。
【０２５０】
さらに、ＥＣ内に含まれたデジタル署名を生成するために用いられたデバイスの「製造履歴」を知ることはまた、重要である。デバイスの「製造履歴」は、（デバイスの製造元；デバイスに適用可能な全ての詳細；デバイスの製造データ；製造場所；デバイスのまとまった識別子；デバイスのシリアル番号および部品番号；製造会社のセキュリティ；レイアウトおよびプロセス幾何学に関するデバイスの物理的具体化；ソフトウェアの証明書および発売データ；電圧および周波数領域を含むデバイスの動作パラメータ；デバイスの全てのイネイブルされたハードウェアおよびソフトウェアのセキュリティ機能の同一化等）デバイスの製造属性記録を含む。デバイスの製造履歴を知ることによって、デバイスのセキュリティの特徴および認証能力は、デバイスの製造中に起きて、発見されるエラー、省略、欠陥、セキュリティ破損、または、可能な不適当なこと等として修正され得る。従って、製造履歴を知ることによって、デバイスの安定レベルを判定することができる。
【０２５１】
ＥＣの作成および伝送に関連する「環境要因」は、世界のどこでＥＣが生成したか、いかにしてＥＣが通信されたか、もしあれば、Ｉ／Ｏ支援要素（単数または複数）のどのタイプまたは何のタイプがＥＣの生成および伝送に関与したか、このようなＩ／Ｏ支援要素の各々がＥＣに対するそれ自体のデジタル署名を生成したかどうか、Ｉ／Ｏ支援要素に関連するセキュリティの特徴、デジタル署名の環境全体（この環境において、例えば、エンティティ認証情報がＩ／Ｏ支援要素または他の外部装置によって盗聴され、複製され、次いで、デバイスユーザの知識無しに後に再生され得るかどうか等のデバイスの動作が行われる）を知ることを含む。デバイスの「取引履歴」、または、ＥＣに関連するアカウントは、不規則な、または、普通ではない活動、あるいは、アカウントに関連する命令を識別し、かつ、追跡すること（例えば、デバイスの典型的な地理的な（ｇｅｏｇｒａｐｈｉｃａｌ）使用法、典型的な取引量またはタイプ、使用頻度、提供された典型的なエンティティ認証、エンティティ認証を提供する間違った試みに関する履歴データ等を知ること）、デバイスが紛失したまたは盗難されたことを報告されているかどうかを知ること等に関与する。他のアカウント要因およびビジネスで考慮すべきこと、メッセージ内の命令（ｉ１）が実施されるべきかどうかを判定するＥＣの受信側によって評価される全てのさらなる基準を含む。
【０２５２】
様々なＡＢＤＳシステムの各々に関して以前に説明されたように、デバイスのデバイスプロフィール情報がデバイスの公開鍵が関連するアカウントデータベース記録にあるアカウントオーソリティによって記録されるべきであることが好ましい。デバイスプロフィール情報は、デバイスのセキュリティプロフィールおよび取引履歴を含む。セキュリティプロフィールは、デバイスのセキュリティ機能および製造履歴を含む。セキュリティ機能は、デバイスのセキュリティの特徴および認証能力を含む。セキュリティプロフィールは、好ましくは（しかし、必ずしも必要ではないが）、デバイスの製造元（好ましくは、信頼に足る、かつ、信用できるエンティティ）から直接に得られる。セキュリティプロフィールが製造元から直接に得られない場合、セキュリティプロフィールは、製造元からセキュリティプロフィールを得た信用された第三者から間接的に得られるか、アカウントオーソリティによる（または、アカウントオーソリティによって信用されたエンティティによる）デバイスの物理的な検査から得られるかのいずれかである。また、セキュリティプロフィールは、本発明の範囲内のアカウントホルダーによって提供され得る。本発明の第三の局面を考えると、セキュリティプロフィールは、また、（情報がアカウントホルダーのための新しいアカウントを確立する際に中央鍵オーソリティから受信されるときのように）中央鍵オーソリティから得られ得る。
【０２５３】
デバイスプロフィール情報にあるこの情報を備えると、アカウントオーソリティは、ＥＣ内に含まれたメッセージを認証した後、さらにメッセージを処理する。これは、認証されたメッセージに含まれた命令（ｉ１）を実行するかどうかを計算して判定するステップを包含する。あるいは、さらにメッセージを処理するステップは、命令（ｉ１）に関連する現在のリスクの解析に基づいた命令の限定された部分を実行するための決定、または、現在の命令（ｉ１）に関連するリスクを減少するためにＥＣの送信側からのさらなる情報を要求するための決定を含む。
【０２５４】
図７３に示されたように、例えば、アカウントオーソリティが主張されたアカウントホルダーからＥＣを最初に受信する（ステップ７３０２）とき、アカウントオーソリティは、ＥＣに提供されたアカウント番号に関連するＰｕＫをアカウントデータベースから取り出し（ステップ７３０４）、ＰｕＫを用いてメッセージを認証することを試みる（ステップ７３０６）。メッセージが（ステップ７３０８において）認証しない場合、アカウントオーソリティは、命令および／またはメッセージに含まれる命令（ｉ１）に対して拒絶で返答する（ステップ７３１０）−この全ては、本発明の第１の局面と一致する。メッセージが（ステップ７３０８において）認証する場合、アカウントオーソリティは、メッセージ、および、メッセージ内に含まれた命令（ｉ１）をさらに処理する（ステップ７３１２）。
【０２５５】
本発明の第１の局面に従うメッセージの認証した後にアカウントオーソリティによりメッセージをさらに処理する例は、二者および三者ＡＢＤＳシステムの特定のインプリメンテーションの各々に対する図６〜６３に関連して以前に説明されている。しかし、図７３に示されるように、本発明のこの第４の局面に従うさらなる処理（ステップ７３１２）は、メッセージ内に含まれる命令（ｉ１）を実施するかどうかを最終的に判定するための、アカウントオーソリティによって用いられる数多くの要因の評価、および、考慮（ステップ７３１４）を含む。評価および考慮（ステップ７３１４）は、デバイスの認証能力の評価（ステップ７３１６）、および、もしあれば、デバイスのＥＣまたはユーザの送り手によって提供されたエンティティ認証の解析、デバイスに関連するセキュリティの特徴の評価（ステップ７３１８）、ＥＣを取り囲む環境要因の評価（ステップ７３２０）、デバイスの取引履歴、および／または、ＥＣに関連するアカウントの考慮（ステップ７３２２）、あるいは、他のアカウントおよび／またはビジネスに特定の要因の考慮（ステップ７３２４）を含む。アカウントオーソリティが上記の要因のいくつかまたは全てを考慮するかどうか、アカウントオーソリティが任意の特定の要因、もしあれば、注文（この注文でアカウントオーソリティが上記の要因を評価または考慮する）にどの程度のウエイトまたは重要さをおくかは、各アカウントオーソリティ自体の特定のビジネスの関心、ニーズ、対象、目的、および、リスクに従って一つのアカウントオーソリティから次のアカウントオーソリティへと変化する。従って、各アカウントオーソリティは、（ステップ７３１４において）考慮された要因のうちの任意または全てに基づいて、メッセージからの命令（ｉ１）が実施されるべきかどうかを判定する（ステップ７３２６）ための各アカウントオーソリティ自体のビジネスの規則および判断を用いる。この判定が（ステップ７３２６において）ネガティブである場合、アカウントオーソリティは、メッセージおよび／またはメッセージに含まれる命令（ｉ１）に拒絶で返答する（ステップ７３１０）。この判定が（ステップ７３２６において）ポジティブである場合、アカウントオーソリティは、メッセージからの命令（ｉ１）を実施して（ステップ７３２８）、従ってアカウント記録を更新する（ステップ７３３０）。
【０２５６】
図７３で図示されないが、ステップ７３２６における判定がネガティブである場合、アカウントオーソリティは、可能なら、上記の要因の解析に基づいて、代替的に命令（ｉ１）の制限された部分のみを実行することを選択し得る。別の代替的な実施形態（これも図７３で図示せず）において、アカウントオーソリティは、現在の命令（ｉ１）に関連するリスクを減少させるために、命令（ｉ１）を実施する前にＥＣの送信側からさらなる情報を要求し得る。
【０２５７】
上記のすべてから、本発明に関して上記で説明されたデバイスが、例えば、売り手、および、デジタル署名を生成する他の商業的なエンティティのデバイスを包括し、デジタル署名を生成する個々の消費者のデバイスに制限されないことは、明らかである。例えば、本発明に従うデバイスは、例えば、安全な金融取引を確立する際の個々の消費者のＩＣカードを読むために用いられたＩＣカードリーダ（このようなＩＣカードリーダー自体がデジタル署名を生成する場合）を含むＩ／Ｏ支援要素を含む。この点に関して、このようなデバイスは、信用されたプラットフォームモジュールを含み得る。
【０２５８】
従って、本発明の好ましい実施形態の上記の詳細な説明、デバイス、および、方法を考えると、本発明が幅広く有用可能であり、かつ、幅広い応用が可能であることは、当業者に容易に理解される。多くの改変、修正、および、等価の配置と同時に、本明細書中で説明されたもの以外の本発明の様々な方法、実施形態、および、順応は、本発明の要旨または範囲から逸脱することなく、本発明および本発明の以下の詳細な説明から明らかである、または、本発明によって合理的に提案される。さらに、好ましい順序または一次的な順番で行われているように様々な処理のステップがいくつかの例で示され、かつ、説明されるが、これらの処理のステップが、このような特定の順序または順番で行われることに必ずしも制限されないことは、当業者は理解し、かつ、認識する。むしろ、多くの例において、本明細書中で説明された処理のステップは、本発明の範囲内である限り、様々な異なる順序および順番で行われ得る。従って、本発明が好ましい方法およびデバイスに関連して詳細に本明細書中で説明されるが、この詳細な説明のみは、本発明の図示および例示であり、全てを提供し、かつ、本発明の開示を可能にする目的のためのみになされることは理解されるべきである。本明細書中で示された詳細な説明は、本発明を制限するように構築すること、そうでなければ、本発明の任意のこのような他の実施形態、適応、改変、修正、および、等価の配置、添付の特許請求の範囲によって単に制限されている本発明およびその等価物を排除することを意図しない。
【図面の簡単な説明】
【図１】図１は、従来技術の証明オーソリティデジタル証明書（ＣＡＤＳ）システムを示す。
【図２】図２は、本発明の第一の局面による好適なアカウントベースのデジタル署名（ＡＢＤＳ）システムを示す。
【図２ａ】図２ａは、ＡＢＤＳシステムを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図２ｂ】図２ｂは、ＡＢＤＳシステムを用いた使用のためのアカウントオーソリティによって維持される別のアカウントデータベースを示す。
【図３】図３は、本発明の第一の局面による別の好適なＡＢＤＳシステムを示す。
【図４ａ】図４ａは、本発明の第一の局面による新しいＡＢＤＳアカウントを確立するための好適なステップの一実施形態のフローチャートを示す。
【図４ｂ】図４ｂは、本発明の第一の局面による新しいＡＢＤＳアカウントを確立するための好適なステップの別の実施形態のフローチャートを示す。
【図５ａ】図５ａは、既存のアカウントを、本発明の第一の局面によるＡＢＤＳアカウントに変換するための好適なステップの一実施形態のフローチャートを示す。
【図５ｂ】図５ｂは、既存のアカウントを、本発明の第一の局面によるＡＢＤＳアカウントに変換するための好適なステップの別の実施形態のフローチャートを示す。
【図６】図６は、本発明の第一の局面による第一のビジネスアプリケーションを示す。
【図７】図７は、図６のビジネスアプリケーションを用いた使用のためにアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図８】図８は、図６のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図９】図９は、図６のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図１０】図１０は、本発明の第一の局面による第二のビジネスアプリケーションを示す。
【図１１】図１１は、図１０のビジネスアプリケーションを用いた使用のためののアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図１２】図１２は、図１０のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図１３】図１３は、図１０のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図１４】図１４は、本発明の第一の局面による第三のビジネスアプリケーションを示す。
【図１５】図１５は、図１４のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図１６】図１６は、図１４のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図１７】図１７は、図１４のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図１８】図１８は、本発明の第一の局面による第四のビジネスアプリケーションを示す。
【図１９】図１９は、図１８のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図２０】図２０は、図１８のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図２１】図２１は、図１８のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図２２】図２２は、本発明の第一の局面による第五のビジネスアプリケーションを示す。
【図２３】図２３は、図２２のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図２４】図２４は、図２２のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図２５】図２５は、図２２のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図２６】図２６は、本発明の第一の局面による第六のビジネスアプリケーションを示す。
【図２７】図２７は、図２６のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図２８】図２８は、図２６のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図２９】図２９は、図２６のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図３０】図３０は、本発明の第一の局面による第七のビジネスアプリケーションを示す。
【図３１】図３１は、図３０のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図３２】図３２は、図３０のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図３３】図３３は、図３０のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図３４】図３４は、本発明の第一の局面による第八のビジネスアプリケーションを示す。
【図３５】図３５は、図３４のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図３６】図３６は、図３４のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図３７】図３７は、図３４のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図３８】図３８は、本発明の第一の局面による第九のビジネスアプリケーションを示す。
【図３９】図３９は、図３８のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図４０】図４０は、図３８のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図４１】図４１は、図３８のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図４２】図４２は、本発明の第一の局面による第十のビジネスアプリケーションを示す。
【図４３】図４３は、図４２のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図４４】図４４は、図４２のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図４５】図４５は、図４２のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図４６】図４６は、本発明の第一の局面による第十一のビジネスアプリケーションを示す。
【図４７】図４７は、図４６のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図４８】図４８は、図４６のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図４９】図４９は、図４６のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図５０】図５０は、本発明の第一の局面の別の好適な実施形態による第一のビジネスアプリケーションを示す。
【図５１】図５１は、図５０のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図５２】図５２は、図５０のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図５３】図５３は、図５０のビジネスアプリケーションにおける中間者によって実施されるステップのフローチャートを示す。
【図５４】図５４は、図５０のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図５５】図５５は、本発明の第一の局面の別の好適な実施形態による第二のビジネス／消費者アプリケーションを示す。
【図５６】図５６は、図５５のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図５７】図５７は、図５５のビジネスアプリケーションにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図５８】図５８は、図５５のビジネスアプリケーションにおける中間者によって実施されるステップのフローチャートを示す。
【図５９】図５９は、図５５のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図６０】図６０は、本発明の第一の局面の別の好適な実施形態による第三のビジネス／消費者アプリケーションを示す。
【図６１】図６１は、図６０のビジネスアプリケーションを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図６２】図６２は、図６０のビジネスアプリケーションにおけるアカウントホルダーおよび売り手（中間者）の両方によって実施されるステップのフローチャートを示す。
【図６３】図６３は、図６０のビジネスアプリケーションにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図６４】図６４は、本発明の第二の局面による好適なＡＢＤＳシステムを示す。
【図６４ａ】図６４ａは、図６４のシステムを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図６４ｂ】図６４ｂは、図６４のシステムを用いた使用のためのアカウントオーソリティによって維持される別のアカウントデータベースを示す。
【図６４ｃ】図６４ｃは、図６４のシステムを用いた使用のためのアカウントオーソリティによって維持される第三のアカウントデータベースを示す。
【図６５】図６５は、図６４のシステムにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図６６】図６６は、図６４のシステムにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図６７】図６７は、本発明の第二の局面による別の好適なＡＢＤＳシステムを示す。
【図６８】図６８は、図６７のシステムにおけるアカウントホルダーによって実施されるステップのフローチャートを示す。
【図６９】図６９は、図６７のシステムにおける中間者によって実施されるステップのフローチャートを示す。
【図７０】図７０は、図６７のシステムにおけるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図７１ａ】図７１ａは、本発明の第三の局面による好適なＡＢＤＳシステムを示す。
【図７１ｂ】図７１ｂは、本発明の第三の局面による別の好適なＡＢＤＳシステムを示す。
【図７１ｃ】図７１ｃは、本発明の第三の局面によるさらに別の好適なＡＢＤＳシステムを示す。
【図７１ｄ】図７１ｄは、本発明の第三の局面によるさらに好適なＡＢＤＳシステムを示す。
【図７２】図７２は、図７１ａシステムを用いた使用のためのアカウントオーソリティによって維持されるアカウントデータベースを示す。
【図７３】図７３は、本発明の第四の局面によるアカウントオーソリティによって実施されるステップのフローチャートを示す。
【図７４】図７４は、本発明の第一の局面によるセッション認証および取引認証目的のためのＥＣの使用を示す。
【図７５】図７５は、本発明の第一の局面による取引確認目的のためのＥＣの使用を示す。
【図７６】図７６は、本発明の種々の局面による電子通信フォーマットまたはレイアウトを示す。
【図１】
2004506380.tif 000003
【図２】
2004506380.tif 000004
【図２ａ】
2004506380.tif 000005
【図２ｂ】
2004506380.tif 000006
【図３】
2004506380.tif 000007
【図４ａ】
2004506380.tif 000008
【図４ｂ】
2004506380.tif 000009
【図５ａ】
2004506380.tif 000010
【図５ｂ】
2004506380.tif 000011
【図６】
2004506380.tif 000012
【図７】
2004506380.tif 000013
【図８】
2004506380.tif 000014
【図９】
2004506380.tif 000015
【図１０】
2004506380.tif 000016
【図１１】
2004506380.tif 000017
【図１２】
2004506380.tif 000018
【図１３】
2004506380.tif 000019
【図１４】
2004506380.tif 000020
【図１５】
2004506380.tif 000021
【図１６】
2004506380.tif 000022
【図１７】
2004506380.tif 000023
【図１８】
2004506380.tif 000024
【図１９】
2004506380.tif 000025
【図２０】
2004506380.tif 000026
【図２１】
2004506380.tif 000027
【図２２】
2004506380.tif 000028
【図２３】
2004506380.tif 000029
【図２４】
2004506380.tif 000030
【図２５】
2004506380.tif 000031
【図２６】
2004506380.tif 000032
【図２７】
2004506380.tif 000033
【図２８】
2004506380.tif 000034
【図２９】
2004506380.tif 000035
【図３０】
2004506380.tif 000036
【図３１】
2004506380.tif 000037
【図３２】
2004506380.tif 000038
【図３３】
2004506380.tif 000039
【図３４】
2004506380.tif 000040
【図３５】
2004506380.tif 000041
【図３６】
2004506380.tif 000042
【図３７】
2004506380.tif 000043
【図３８】
2004506380.tif 000044
【図３９】
2004506380.tif 000045
【図４０】
2004506380.tif 000046
【図４１】
2004506380.tif 000047
【図４２】
2004506380.tif 000048
【図４３】
2004506380.tif 000049
【図４４】
2004506380.tif 000050
【図４５】
2004506380.tif 000051
【図４６】
2004506380.tif 000052
【図４７】
2004506380.tif 000053
【図４８】
2004506380.tif 000054
【図４９】
2004506380.tif 000055
【図５０】
2004506380.tif 000056
【図５１】
2004506380.tif 000057
【図５２】
2004506380.tif 000058
【図５３】
2004506380.tif 000059
【図５４】
2004506380.tif 000060
【図５５】
2004506380.tif 000061
【図５６】
2004506380.tif 000062
【図５７】
2004506380.tif 000063
【図５８】
2004506380.tif 000064
【図５９】
2004506380.tif 000065
【図６０】
2004506380.tif 000066
【図６１】
2004506380.tif 000067
【図６２】
2004506380.tif 000068
【図６３】
2004506380.tif 000069
【図６４】
2004506380.tif 000070
【図６４ａ】
2004506380.tif 000071
【図６４ｂ】
2004506380.tif 000072
【図６４ｃ】
2004506380.tif 000073
【図６５】
2004506380.tif 000074
【図６６】
2004506380.tif 000075
【図６７】
2004506380.tif 000076
【図６８】
2004506380.tif 000077
【図６９】
2004506380.tif 000078
【図７０】
2004506380.tif 000079
【図７１ａ】
2004506380.tif 000080
【図７１ｂ】
2004506380.tif 000081
【図７１ｃ】
2004506380.tif 000082
【図７１ｄ】
2004506380.tif 000083
【図７２】
2004506380.tif 000084
【図７３】
2004506380.tif 000085
【図７４】
2004506380.tif 000086
【図７５】
2004506380.tif 000087
【図７６】
2004506380.tif 000088
【国際公開パンフレット】
2004506380.tif 000089
2004506380.tif 000090
2004506380.tif 000091
2004506380.tif 000092
2004506380.tif 000093
2004506380.tif 000094
2004506380.tif 000095
2004506380.tif 000096
2004506380.tif 000097
2004506380.tif 000098
2004506380.tif 000099
2004506380.tif 000100
2004506380.tif 000101
2004506380.tif 000102
2004506380.tif 000103
2004506380.tif 000104
2004506380.tif 000105
2004506380.tif 000106
2004506380.tif 000107
2004506380.tif 000108
2004506380.tif 000109
2004506380.tif 000110
2004506380.tif 000111
2004506380.tif 000112
2004506380.tif 000113
2004506380.tif 000114
2004506380.tif 000115
2004506380.tif 000116
2004506380.tif 000117
2004506380.tif 000118
2004506380.tif 000119
2004506380.tif 000120
2004506380.tif 000121
2004506380.tif 000122
2004506380.tif 000123
2004506380.tif 000124
2004506380.tif 000125
2004506380.tif 000126
2004506380.tif 000127
2004506380.tif 000128
2004506380.tif 000129
2004506380.tif 000130
2004506380.tif 000131
2004506380.tif 000132
2004506380.tif 000133
2004506380.tif 000134
2004506380.tif 000135
2004506380.tif 000136
2004506380.tif 000137
2004506380.tif 000138
2004506380.tif 000139
2004506380.tif 000140
2004506380.tif 000141
2004506380.tif 000142
2004506380.tif 000143
2004506380.tif 000144
2004506380.tif 000145
2004506380.tif 000146
2004506380.tif 000147
2004506380.tif 000148
2004506380.tif 000149
2004506380.tif 000150
2004506380.tif 000151
2004506380.tif 000152
2004506380.tif 000153
2004506380.tif 000154
2004506380.tif 000155
2004506380.tif 000156
2004506380.tif 000157
2004506380.tif 000158
2004506380.tif 000159
2004506380.tif 000160
2004506380.tif 000161
2004506380.tif 000162
2004506380.tif 000163
2004506380.tif 000164
2004506380.tif 000165
2004506380.tif 000166
2004506380.tif 000167
2004506380.tif 000168
2004506380.tif 000169
2004506380.tif 000170
2004506380.tif 000171
2004506380.tif 000172
2004506380.tif 000173
2004506380.tif 000174
2004506380.tif 000175
2004506380.tif 000176
2004506380.tif 000177
2004506380.tif 000178
2004506380.tif 000179
2004506380.tif 000180
2004506380.tif 000181
2004506380.tif 000182
2004506380.tif 000183
2004506380.tif 000184
2004506380.tif 000185
2004506380.tif 000186
2004506380.tif 000187
2004506380.tif 000188
2004506380.tif 000189
2004506380.tif 000190
2004506380.tif 000191
2004506380.tif 000192
2004506380.tif 000193
2004506380.tif 000194
2004506380.tif 000195
2004506380.tif 000196
2004506380.tif 000197
2004506380.tif 000198
2004506380.tif 000199
2004506380.tif 000200
2004506380.tif 000201
2004506380.tif 000202
2004506380.tif 000203
2004506380.tif 000204
2004506380.tif 000205
2004506380.tif 000206
2004506380.tif 000207
2004506380.tif 000208
2004506380.tif 000209
2004506380.tif 000210
2004506380.tif 000211
2004506380.tif 000212
2004506380.tif 000213
2004506380.tif 000214
2004506380.tif 000215
2004506380.tif 000216
2004506380.tif 000217
2004506380.tif 000218
2004506380.tif 000219
2004506380.tif 000220
2004506380.tif 000221
2004506380.tif 000222
2004506380.tif 000223
2004506380.tif 000224
2004506380.tif 000225
2004506380.tif 000226
2004506380.tif 000227
2004506380.tif 000228
2004506380.tif 000229
2004506380.tif 000230
2004506380.tif 000231
2004506380.tif 000232
2004506380.tif 000233
2004506380.tif 000234
2004506380.tif 000235
2004506380.tif 000236
2004506380.tif 000237
2004506380.tif 000238
2004506380.tif 000239
2004506380.tif 000240
2004506380.tif 000241
2004506380.tif 000242
2004506380.tif 000243
2004506380.tif 000244
2004506380.tif 000245
2004506380.tif 000246
2004506380.tif 000247
2004506380.tif 000248
2004506380.tif 000249
2004506380.tif 000250
2004506380.tif 000251
2004506380.tif 000252
2004506380.tif 000253
2004506380.tif 000254
2004506380.tif 000255
2004506380.tif 000256
2004506380.tif 000257
2004506380.tif 000258
2004506380.tif 000259
2004506380.tif 000260
2004506380.tif 000261
2004506380.tif 000262
2004506380.tif 000263
2004506380.tif 000264
2004506380.tif 000265
2004506380.tif 000266
2004506380.tif 000267
2004506380.tif 000268
2004506380.tif 000269
2004506380.tif 000270
2004506380.tif 000271
2004506380.tif 000272
2004506380.tif 000273
【国際調査報告】
2004506380.tif 000274
2004506380.tif 000275
2004506380.tif 000276
2004506380.tif 000277
2004506380.tif 000278