(57)【要約】安全な電子支払いにおいて、支払い口座発行者（４０６）から、購入者の操作するユーザソフトウェア（４０２）へ認証データを送信する。ユーザソフトウェアは、販売業者（４０４）のウェブページ上の隠れたフィールドを使って、認証データを販売業者（４０４）へ送信する。販売業者（４０４）は認証データに基づいて認証要求メッセージを生成する。直接販売業者（４０４）からか又は販売業者の取得者を介して、認証要求メッセージを決済機関（４０８）に送信する。決済機関（４０８）は、支払い要求メッセージを照合する口座発行者（４０６）に認証要求メッセージを転送することによって、決済機関（４０８）に送信する認証応答メッセージを生成する。決済機関（４０８）は、直接販売業者（４０４）からか又は販売業者の取得者を介して、認証応答メッセージを転送する。
2004535619.tif 000002
【特許請求の範囲】
【請求項１】
ユーザのソフトウェアによって、ウェブページを表示するためのウェブページデータのセットを受信し、
ユーザのソフトウェアによって、前記ウェブページが少なくとも１つの隠れたフィールドを含むか否か判別し、
前記ウェブページが少なくとも１つの隠れたフィールドを含む場合、隠れたデータを販売業者に送信するユーザのソフトウェアによって、少なくとも１つの隠れたフィールドを隠れたデータで満たすことを含む第一の支払い手順を、特定の決済取引を行うのに利用するために選択し、
前記ウェブページが少なくとも１つの隠れたフィールドを含まない場合、少なくとも１つのウェブページに含まれる可視フィールドを購入データで満たすことを含む購入データを販売業者に送信するための第二の支払い手順を、特定の決済取引を行うのに利用するために選択することを特徴とする決済取引を行う方法。
【請求項２】
前記第一の支払い手順は、更に、ユーザのソフトウェアによって、支払い口座発行者からの認証データを受信することを含み、前記隠れたデータは前記認証データから構成され、前記認証データは、支払い口座発行者の発行した支払い口座の口座名義人の身元を認証するためのものであることを特徴とする請求項１に記載の方法。
【請求項３】
前記第一の支払い手順は、更に、前記口座名義人の身元を認証するための要求と、前記口座名義人の身元を認証するための要求に応答して、支払い口座発行者からユーザのソフトウェアに送る前記認証データとを、前記ユーザのソフトウェアから前記支払い口座発行者へ送ることを特徴とする請求項２に記載の方法。
【請求項４】
前記第一の支払い手順は、更に、
前記認証データから得る許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信するステップと、
前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージのうちの少なくとも１つを処理する照合手順を、許可応答メッセージを生成するために、前記支払い口座発行者によって利用するステップと、
前記支払い口座発行者から前記決済機関へ、前記許可応答メッセージを送信するステップと、
前記許可応答メッセージと前記認証応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信するステップとを有することを特徴とする請求項３記載の方法。
【請求項５】
前記第一の支払い手順は、更に、
前記販売業者から取得者へ、前記認証データから得た第一の許可要求メッセージを送信するステップと、
前記取得者から決済機関へ、前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを送信するステップと、
前記決済機関から前記支払い口座発行者へ、第一と第二の許可要求メッセージと、前記第一と第二の許可要求メッセージのうちの少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを送信するステップと、
前記第一と第二の認証要求メッセージと前記第三の許可要求メッセージの少なくとも１つを処理する照合手順を、第一の許可応答メッセージを生成するために前記支払い口座発行者が利用するステップと、
前記支払い口座発行者から前記決済機関へ、前記第一の許可応答メッセージを送信するステップと、
前記決済機関から前記取得者へ、前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージのうちの少なくとも１つを送信するステップと、
前記取得者から前記販売業者へ、前記第一と第二の許可応答メッセージと、前記第一と第二の許可応答メッセージのうちの少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを送信するステップとを有することを特徴とする請求項３記載の方法。
【請求項６】
前記第一の支払い手順は、更に、
前記認証データから得る許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信するステップと、
前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージのうちの少なくとも１つを処理する照合手順を、許可応答メッセージの生成のために前記支払い口座発行者が利用するステップと、
前記支払い口座発行者から前記決済機関へ、前記許可応答メッセージを送信するステップと、
前記決済機関から前記販売業者へ、前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを送信するステップとを有することを特徴とする請求項２記載の方法。
【請求項７】
前記第一の支払い手順は、更に、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信するステップと、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージのうちの少なくとも１つを、前記取得者から決済機関へ送信するステップと、
前記第一と第二の許可要求メッセージのうちの少なくとも１つと前記第一と第二の許可要求メッセージの少なくとも１つから得た第三の許可要求メッセージのなかから少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信するステップと、
前記第一と第二の許可要求メッセージの少なくとも１つと前記第三の許可要求メッセージのなかから少なくとも１つを処理する照合手順を、第一の許可応答メッセージ生成するために、前記支払い口座発行者が利用するステップと、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信するステップと、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージのうちの少なくとも１つを、前記決済機関から前記取得者へ送信するステップと、
前記第一と第二の許可応答メッセージの少なくとも１つと、前記第一と第二の許可応答メッセージの少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信するステップとを有することを特徴とする請求項２記載の方法。
【請求項８】
前記第一の支払い手順は、更に、
前記隠れたデータから得た前記許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から支払い口座発行者へ送信するステップと、
前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージのうちの少なくとも１つを処理する照合手順を、許可応答メッセージを生成するために、前記支払い口座発行者が利用するステップと、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信するステップと、
前記許可応答メッセージと前記許可応答メッセージから得るメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信するステップとを有することを特徴とする請求項１記載の方法。
【請求項９】
前記隠れたデータは、少なくとも前記特定の決済取引と関連したデータを含み、
前記照合手順は、
前記特定の決済取引と関連した前記データを以前にいずれかの決済取引を認証するのに利用したか否かを、前記支払い口座発行者が判別するステップと、
前記特定の決済取引と関連した前記データを以前にいずれかの決済取引を認証するのに利用した場合、前記許可応答メッセージの認証を断るステップとを有することを特徴とする請求項８記載の方法。
【請求項１０】
前記第一の支払い手順は、
前記隠れたデータから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信するステップと、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージのうちの少なくとも１つを、前記取得者から決済機関へ送信するステップと、
前記第一と第二の許可要求メッセージのうちの前記少なくとも１つと、前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から支払い口座発行者へ送信するステップと、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用するステップと、
第一の許可応答メッセージを、支払い口座発行者から前記決済機関へ送信するステップと、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信するステップと、
前記第一と第二の許可応答メッセージの前記少なくとも１つと、前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記取得者から前記販売業者へ送信するステップとを有することを特徴とする請求項１記載の方法。
【請求項１１】
前記隠れたデータは、前記特定の決済取引と関連したデータの少なくとも１つを含み、
前記照合手順は、
前記特定の決済取引と関連したデータがいずれかの決済取引の認証に以前使われたか否か、前記支払い口座発行者が判断するステップと、
前記特定の決済取引と関連したデータがいずれかの決済取引の認証に以前使われた場合、前記第一の許可応答メッセージの認証を断るステップとを有することを特徴とする請求項１０記載の方法。
【請求項１２】
前記第一の支払い手順は、更に、
前記隠れたデータから得る許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
許可応答メッセージを生成するために、前記許可要求メッセージを処理する照合手順を前記決済機関が利用するステップと、
前記許可応答メッセージを、前記決済機関から前記販売業者へ送信するステップとを有することを特徴とする請求項１記載の方法。
【請求項１３】
前記第一の支払い手順は、更に、
前記隠れたデータから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信するステップと、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信するステップと、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの少なくとも１つを処理する照合手順を、前記決済機関が利用するステップと、
前記第一の許可応答メッセージを、前記決済機関から前記取得者へ送信するステップと、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージを、前記取得者から前記販売業者へ送信するステップとを有することを特徴とする請求項１記載の方法。
【請求項１４】
隠れたフィールドの少なくとも１つを含むウェブページを表示するウェブページデータのセットを、ユーザのソフトウェアが受信し、
前記支払い口座発行者の発行する支払い口座の口座名義人の身元を認証するための、支払い口座の発行者からの前記認証データを、前記ユーザのソフトウェアが受信し、
前記認証データを販売業者に送信するために、前記少なくとも１つの隠れたフィールドを、前記ユーザのソフトウェアが前記認証データで満たすことを特徴とする決済取引を行う方法。
【請求項１５】
前記口座名義人の身元を認証するための要求を、前記ユーザのソフトウェアから前記支払い口座発行者へ送信し、前記口座名義人の身元を認証するための前記要求に応じて、前記認証データを前記支払い口座発行者から前記ユーザのソフトウェアへ送信することを特徴とする請求項１４記載の方法。
【請求項１６】
前記認証データから得る許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者を利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項１５記載の方法。
【請求項１７】
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者を利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項１５記載の方法。
【請求項１８】
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項１４記載の方法。
【請求項１９】
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと第三の許可要求メッセージのうちの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、記取得者から前記販売業者へ送信することを特徴とする請求項１４記載の方法。
【請求項２０】
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージを処理する照合手順を前記決済機関が利用し、
前記許可応答メッセージを、前記決済機関から前記販売業者へ送信することを特徴とする請求項１４記載の方法。
【請求項２１】
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つを処理する照合手順を、前記決済機関が利用し、
前記第一の許可応答メッセージを、前記決済機関から前記取得者へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項１４記載の方法。
【請求項２２】
第一のウェブページを表示するウェブページデータの第一のセットを、ユーザのソフトウェアが受信し、
前記第一のウェブページが１回のクリックによる支払い手順を行うために利用できることを前記ユーザのソフトウェアに示す第一の隠れたフィールドを含むか否かを、前記ユーザのソフトウェアが判別し、
前記第一のウェブページが前記第一の隠れたフィールドを含む場合、前記ユーザのソフトウェアが前記第一の隠れたフィールドを、前記ユーザのソフトウェアを少なくとも１つの決済取引を行うのに利用することを販売業者に通知するデータで満たすことを特徴とする決済取引を行う方法。
【請求項２３】
前記第一のウェブページを利用するために行う前記１回のクリックによる支払い手順を、口座名義人が選択することを特徴とする請求項２２記載の方法。
【請求項２４】
第二の隠れたフィールドと隠れたボタンを含む第二のウェブページを表すウェブページデータの前記第二のセットを、前記ユーザのソフトウェアが受信するステップと、
前記口座名義人の身元を認証するための前記認証データを前記販売業者に送信するために、前記ユーザのソフトウェアが、前記第二の隠れたフィールドを認証データで満たすステップと、
前記認証データの前記販売業者への送信を開始するために、前記隠れたボタン上を前記ユーザのソフトウェアがクリックするステップとを更に有することを特徴とする請求項２３記載の方法。
【請求項２５】
支払い口座を前記口座名義人に発行する支払い口座発行者からの前記認証データを、前記ユーザのソフトウェアが受信することを特徴とする請求項２４記載の方法。
【請求項２６】
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項２５記載の方法。
【請求項２７】
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項２５記載の方法。
【請求項２８】
ウェブページを表示するウェブページデータのセットを受信する第一のユーザプロセッサと、
前記ウェブページが隠れたフィールドの少なくとも１つを含むか否かを判別する第二のユーザプロセッサと、
前記ウェブページが前記隠れたフィールドの少なくとも１つを含む場合、特定の決済取引を行うのに利用し前記隠れたデータを販売業者に送信するために、前記少なくとも１つの隠れたフィールドを隠れたデータで満たす第三のユーザプロセッサから構成される前記第一の決済システムを選択するプロセッサと、
前記ウェブページが前記隠れたフィールドの少なくとも１つを含まない場合、前記特定の決済取引を行うのに利用し前記ウェブページに含まれる少なくとも１つの可視フィールドを前記購入データから前記販売業者へ送信するために、前期少なくとも１つの可視フィールドを購入データで満たすプロセッサから構成される第二の決済システムを選択するプロセッサとを備えることを特徴とする決済取引を行う装置。
【請求項２９】
前記第一の決済システムは、更に、
支払い口座を、口座名義人に発行する支払い口座発行者と、
前記支払い口座発行者からの認証データと、前記認証データから構成される前記隠れたデータと、前記口座名義人の身元を認証する前記認証データとを受信する第四のユーザプロセッサとを備えることを特徴とする請求項２８記載の装置。
【請求項３０】
前記第一の決済システムは、更に、
前記口座名義人の身元を認証する要求と、前記支払い口座発行者から前記第四のユーザプロセッサへ前記口座名義人の身元を認証する前記要求に応答して送信する前記認証データとを、前記支払い口座発行者へ送信する第五のユーザプロセッサとを備えることを特徴とする請求項２９記載の装置。
【請求項３１】
前記第一の決済システムは、更に、
前記販売業者からの前記認証データから得た許可要求メッセージを受信する決済機関と、
を備え、
前記決済機関は更に、前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記支払い口座発行者へ送信し、
前記支払い口座発行者は、許可応答メッセージを生成するために前記許可要求メッセージと前記許可要求メッセージから得たメッセージの前記少なくとも１つを照合する照合プロセッサから構成され、前記許可応答メッセージを前記決済機関へ送信し、
前記決済機関は更に、前記支払い口座発行者と前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを前記販売業者へ送信することを特徴とする請求項３０記載の装置。
【請求項３２】
前記第一の決済システムは、更に、
前記販売業者からの前記認証データから得た第一の許可要求メッセージを受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から受信する決済機関と、
を備え、
前記決済機関は更に、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記支払い口座発行者へ送信し、
前記支払い口座発行者は、第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを照合する照合プロセッサから構成され、
前記支払い口座発行者は更に前記第一の許可応答メッセージを前記決済機関に送信し、前記決済機関は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記取得者へ送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記販売業者に送信することを特徴とする請求項３０記載の装置。
【請求項３３】
前記第一の決済システムは、更に、
前記販売業者から前記認証データから得た許可要求メッセージを受信する決済機関と、
を備え、
前記決済機関は更に、前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１を前記支払い口座発行者へ送信し、
前記支払い口座発行者は、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを照合する照合プロセッサから構成され、許可応答メッセージを生成し、
前記支払い口座発行者は更に前記許可応答メッセージを前記決済機関へ送信し、
前記決済機関は更に、前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを前記販売業者へ送信することを特徴とする請求項２９記載の装置。
【請求項３４】
前記第一の決済システムは、更に、
前記認証データから得る第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関と、
を備え、前記決済機関は更に前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの前記少なくとも１つを照合する照合プロセッサから構成され、第一の許可応答メッセージを生成し、前記支払い口座発行者は更に前記第一の許可応答メッセージを前記決済機関へ送信し、前記決済機関は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記取得者に送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記販売業者に送信することを特徴とする請求項２９記載の装置。
【請求項３５】
前記第一の決済システムは、更に、
支払い口座発行者と、
前記隠れたデータから得た許可要求メッセージを前記販売業者から受信する決済機関と、
を備え、前記決済機関は更に前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを前記支払い口座発行者に送信し、前記支払い口座発行者は前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを照合する照合プロセッサから構成され、許可応答メッセージを生成し、前記支払い口座発行者は前記許可応答メッセージを前記決済機関に送信し、前記決済機関は更に前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを前記販売業者に送信することを特徴とする請求項２８記載の装置。
【請求項３６】
前記隠れたデータは前記特定の決済取引と関連したデータを少なくとも含み、前記照合プロセッサは、
前記特定の決済取引に関連した前記データが以前いずれかの決済取引に利用されたか否かを判別するプロセッサと、
前記特定の決済取引に関連した前記データが以前いずれかの決済取引に利用されている場合、前記許可応答メッセージの認証を断るプロセッサとを備えることを特徴とする請求項３５記載の装置。
【請求項３７】
前記第一の決済システムは、更に、
支払い口座発行者と、
前記隠れたデータから得る第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関と、
を備え、前記決済機関は更に前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを前記支払い口座発行者に送信し、前記支払い口座発行者は前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの前記少なくとも１つを照合する照合プロセッサから構成され、第一の許可応答メッセージを生成し、前記支払い口座発行者は前記第一の許可応答メッセージを前記決済機関に送信し、前記決済機関は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記取得者に送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記販売業者に送信することを特徴とする請求項２８記載の装置。
【請求項３８】
前記隠れたデータは少なくとも前記特定の決済取引に関連したデータを含み、前記照合プロセッサは、
前記特定の決済取引に関連したデータが以前いずれかの決済取引の認証に利用したか否かを判定するプロセッサと、
前記特定の決済取引に関連したデータが以前いずれかの決済取引の認証に利用した場合、前記第一の許可応答メッセージの認証を断るプロセッサとを備えることを特徴とする請求項３７記載の装置。
【請求項３９】
前記第一の決済システムは、更に、前記隠れたデータから得た許可要求メッセージを前記販売業者から受信する決済機関を備え、前記決済機関は前記許可要求メッセージを照合する照合プロセッサを備え、許可応答メッセージを生成し、前記決済機関は更に前記許可応答メッセージを前記販売業者に送信することを特徴とする請求項２８記載の装置。
【請求項４０】
前記第一の決済システムは、更に、前記隠れたデータから得た第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関とを備え、前記決済機関は、前記第一と第二の許可要求メッセージの前記少なくとも１つを照合する照合プロセッサを備え、第一の許可応答メッセージを生成し、前記決済機関は更に前記第一の許可応答メッセージを前記取得者に送信し、前記取得者は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記販売業者に送信することを特徴とする請求項２８記載の装置。
【請求項４１】
少なくとも１つの隠れたフィールドを含むウェブページを表示するウェブページデータのセットを受信する第一のユーザプロセッサと、
支払い口座を口座名義人に発行する支払い口座発行者と、
前記口座名義人の身元を認証する認証データを前記支払い口座発行者から受信する第二のユーザプロセッサと、
前記少なくとも１つの隠れたフィールドを販売業者に送信するための前記認証データで満たす第三のユーザプロセッサとを備えることを特徴とする決済取引を行う装置。
【請求項４２】
前記口座名義人の身元を認証するための要求を前記支払い口座発行者へ送信する第四のユーザプロセッサを更に備え、前記認証データを、前記口座名義人の身元を認証する前記要求に応答して前記支払い口座発行者から前記第二のユーザプロセッサへ送信することを特徴とする請求項４１記載の装置。
【請求項４３】
前記認証データから得た許可要求メッセージを、前記販売業者から受信する決済機関を更に備え、前記決済機関は更に前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを照合する照合プロセッサを備え、許可応答メッセージを生成し、前記支払い口座発行者は更に前記許可応答メッセージを前記決済機関へ送信し、前記決済機関は前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを前記販売業者へ送信することを特徴とする請求項４２記載の装置。
【請求項４４】
前記認証データから得た第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関とを更に備え、
前記決済機関は更に、前記第一許可要求メッセージから得られた前記第一と第二の許可要求メッセージの前記少なくも１つと前記第一と第二の許可要求メッセージから得られた第三の許可要求メッセージの前記少なくも１つのうち、少なくとも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記第一と第二の許可要求メッセージの前記少なくも１つと前記第三の許可要求メッセージのうちの少なくも１つを照合する照合プロセッサを備え、第一の許可応答メッセージを生成し、前記支払い口座発行者は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージのうちの少なくも１つを前記取得者へ送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくも１つと前記第一と第二の許可応答メッセージの前記少なくも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記販売業者へ送信する
ことを特徴とする請求項４２記載の装置。
【請求項４５】
前記認証データから得た許可要求メッセージを前記販売業者から受信する決済機関を更に備え、前記決済機関は更に前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくも１つを照合する照合プロセッサを備え、許可応答メッセージを生成し、前記支払い口座発行者は更に前記許可応答メッセージを前記決済機関に送信し、前記決済機関は前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを前記販売業者へ送信することを特徴とする請求項４１記載の装置。
【請求項４６】
前記認証データから得た第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関とを更に備え、前記決済機関は更前記第一と第二の許可要求メッセージの前記少なくも１つと前記第一と第二の許可要求メッセージの前記少なくも１つから得た第三の許可要求メッセージのうちの少なくも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は、前記第一と第二の許可要求メッセージの前記少なくも１つと前記第三の許可要求メッセージのうちの少なくも１つを照合する照合プロセッサを備え、第一の許可応答メッセージを生成し、前記支払い口座発行者は更に前記第一の許可応答メッセージを前記決済機関へ送信し、前記決済機関は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくも１つを前記取得者へ送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくも１つと前記第一と第二の許可応答メッセージの前記少なくも１つから得た第三の許可応答メッセージのうちの少なくも１つを前記販売業者へ送信することを特徴とする請求項４１記載の装置。
【請求項４７】
前記認証データから得た許可要求メッセージを前記販売業者から受信する決済機関とを更に備え、前記決済機関は前記許可要求メッセージを照合する照合プロセッサを備え、許可応答メッセージを生成し、前記決済機関は更に前記許可応答メッセージを前記販売業者へ送信することを特徴とする請求項４１記載の装置。
【請求項４８】
前記認証データから得た第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくも１つを前記取得者から受信する決済機関とを更に備え、前記決済機関は前記第一と第二の許可要求メッセージの前記少なくも１つを照合する照合プロセッサを備え、第一の許可応答メッセージを生成し、前記決済機関は更に、前記第一の許可応答メッセージを前記取得者へ送信し、前記取得者は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記販売業者へ送信することを特徴とする請求項４１記載の装置。
【請求項４９】
第一のウェブページを表示するウェブページデータの第一のセットを受信する第一のユーザプロセッサと、
決済取引を行うために、１回のクリックによる決済システムによって使用可能であることを前記ユーザのソフトウェアへ示す第一の隠れたフィールドを第一のウェブページが含むか否かを判別する第二のユーザプロセッサと、
前記第一のウェブページが前記第一の隠れたフィールドを含む場合、前記ユーザプロセッサが、前記第一の隠れたフィールドを前記少なくとも１つの決済取引を行うために利用する旨販売業者へ通知するためのデータで満たす第三のユーザプロセッサとを備えることを特徴とする決済取引を行う配置。
【請求項５０】
前記第一のウェブページを利用して行う前記１回のクリックによる支払い手順を選択する口座名義人を更に備えることを特徴とする請求項４９記載の配置。
【請求項５１】
第二の隠れたフィールドと隠れたボタンを含む第二のウェブページを表すウェブページデータの第二のセットを受信する第四のユーザプロセッサと、
前記第二の隠れたフィールドを前記口座名義人の身元を認証するための認証データで満たし、前記認証データを前記販売業者へ送信する第五のユーザプロセッサと、
前記認証データの前記販売業者への送信を開始するための前記隠れたボタン上をクリックする第六ユーザプロセッサとを更に備えることを特徴とする請求項５０記載の配置。
【請求項５２】
支払い口座を前記口座名義人に発行する支払い口座発行者と、
前記認証データを前記支払い口座発行者から受信する第七ユーザプロセッサとを更に備えることを特徴とする請求項５１記載の配置。
【請求項５３】
前記認証データから得た許可要求メッセージを前記販売業者から受信する決済機関を更に備え、前記決済機関は更に前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを照合する照合プロセッサを備え、許可応答メッセージを生成し、前記支払い口座発行者は更に前記許可応答メッセージを前記決済機関へ送信し、前記決済機関は更に前記許可応答メッセージと前記許可応答メッセージから得た少なくとも１つを前記販売業者へ送信することを特徴とする請求項５２記載の配置。
【請求項５４】
前記認証データから得る第一の許可要求メッセージを前記販売業者から受信する取得者と、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを前記取得者から受信する決済機関とを更に備え、前記決済機関は更に前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを前記支払い口座発行者へ送信し、前記支払い口座発行者は前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを照合する照合プロセッサを備え、第一の許可応答メッセージを生成し、前記支払い口座発行者は更に前記第一の許可応答メッセージを前記決済機関へ送信し、前記決済機関は更に前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記取得者へ送信し、前記取得者は更に前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを前記販売業者へ送信することを特徴とする請求項５２記載の配置。
【請求項５５】
ウェブページを表示するウェブページデータのセットをユーザプロセッサが受信するステップと、
前記ウェブページが隠れたフィールドの少なくとも１つを含むか否か、前記ユーザプロセッサが判別するステップと、
前記ウェブページが隠れたフィールドの少なくとも１つを含む場合、特定の決済取引を行うために利用するために、前記少なくとも１つの隠れたフィールドを前記隠れたデータを販売業者へ送信するための隠れたデータで満たすステップを含む第一の支払い手順を、前記ユーザプロセッサが選択するステップと、
前記ウェブページが隠れたフィールドの少なくとも１つを含む場合、前記特定の決済取引を行うために利用するために、前記ウェブページに含まれる少なくとも１つの可視フィールドを、前記購入データを前記販売業者へ送信するための購入データで満たすステップを含む前記第二の支払い手順を選択するステップとを有することを特徴とするプロセッサを指図可能な指示のセットを有するコンピュータで読み取り可能な媒体。
【請求項５６】
前記第一の支払い手順は更に、支払い口座発行者から前記ユーザプロセッサが認証データと前記隠れたデータ受信するステップを含み、前記隠れたデータは前記認証データから構成され、前記認証データは前記支払い口座発行者の発行する支払い口座の口座名義人の身元を認証するためのもでのであることを特徴とする請求項５５記載のコンピュータで読み取り可能な媒体。
【請求項５７】
前記第一の支払い手順は更に、記口座名義人の前記身元を認証するという要求を前記ユーザプロセッサから前記支払い口座発行者へ送信するステップを含み、前記認証データを前記支払い口座発行者から前記ユーザプロセッサへ前記口座名義人の前記身元を認証するという前記要求に応じて送信することを特徴とする請求項５６記載のコンピュータで読み取り可能な媒体。
【請求項５８】
前記第一の支払い手順は、更に、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を前記支払い口座発行者が利用し、
前記許可応答メッセージを前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項５７記載のコンピュータで読み取り可能な媒体。
【請求項５９】
前記第一の支払い手順は、更に、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを利用するために、前記第一と第二の認証要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセーを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項５７記載のコンピュータで読み取り可能な媒体。
【請求項６０】
前記第一の支払い手順は、更に、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項５６記載のコンピュータで読み取り可能な媒体。
【請求項６１】
前記第一の支払い手順は、更に、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項５６記載のコンピュータで読み取り可能な媒体。
【請求項６２】
前記第一の支払い手順は、更に、
前記隠れたデータから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、許可要求メッセージと許可要求メッセージから得たメッセージのうち前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得た許可応答メッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項５５記載のコンピュータで読み取り可能な媒体。
【請求項６３】
前記隠れたデータは前記特定の決済取引と関連したデータを少なくとも含み、前記照合プロセッサは、
前記特定の決済取引に関連した前記データが以前いずれかの決済取引に利用されたか否かを判別するプロセッサと、
前記特定の決済取引に関連した前記データが以前いずれかの決済取引に利用されている場合、前記許可応答メッセージの認証を断るプロセッサとを備えることを特徴とする請求項６２記載の装置。
【請求項６４】
前記第一の支払い手順は、更に、
前記隠れたデータから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージのうちの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項５５記載のコンピュータで読み取り可能な媒体。
【請求項６５】
前記隠れたデータは、少なくとも前記特定の決済取引と関連するデータを含み、前記照合手順は、
前記特定の決済取引と関連する前記データが以前、いずれかの決済取引の認証に利用されたか否かを、前記支払い口座発行者が判別するステップと、
前記特定の決済取引と関連する前記データが以前、いずれかの決済取引の認証に利用された場合、前記第一の許可応答メッセージの認証を断るステップとを有することを特徴とする請求項６４記載のコンピュータで読み取り可能な媒体。
【請求項６６】
前記第一の支払い手順は、更に、
前記隠れたデータから得た許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
許可応答メッセージを生成するために、前記許可要求メッセージを処理する照合手順を前記決済機関が利用するステップと、
前記許可応答メッセージを前記決済機関から前記販売業者へ送信するステップとを有することを特徴とする請求項５５記載のコンピュータで読み取り可能な媒体。
【請求項６７】
前記第一の支払い手順は、更に、
前記隠れたデータから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つを処理する照合手順を、前記決済機関が利用し、
前記第一の許可応答メッセージを、前記決済機関から前記取得者へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを前記取得者から前記販売業者へ送信することを特徴とする請求項５５記載のコンピュータで読み取り可能な媒体。
【請求項６８】
少なくとも１つの隠れたフィールドを含むウェブページを表示するウェブページデータのセットを、ユーザプロセッサが受信し、；
前記支払い口座発行者の発行する支払い口座の口座名義人の身元を認証するための認証データを、前記ユーザプロセッサが支払い口座発行者から受信し、
前記認証データを販売業者へ送信するための前記認証データで、前記少なくとも１つの隠れたフィールドを、前記ユーザプロセッサが満たすことを特徴とする、プロセッサを指図可能な指示のセットを有するコンピュータで読み取り可能な媒体。
【請求項６９】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記口座名義人の前記身元の認証のための要求と前記口座名義人の前記身元の認証のための前記要求に応じて前記支払い口座発行者から前記ユーザプロセッサへ送信する前記認証データとを、前記ユーザプロセッサから前記支払い口座発行者へ送信することを特徴とする請求項６８記載のコンピュータで読み取り可能な媒体。
【請求項７０】
前記第一の支払い手順は、更に、前記指示のセットは、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項６９記載のコンピュータで読み取り可能な媒体。
【請求項７１】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージのうちの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の許可応答メッセージの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項６９記載のコンピュータで読み取り可能な媒体。
【請求項７２】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
前記許可要求メッセージと前記許可要求メッセージから得たメッセージを、前記決済機関から前記支払い口座発行者へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記許可応答メッセージを、前記支払い口座発行者から前記決済機関を送信し、
前記許可応答メッセージと前記許可応答メッセージから得たメッセージの少なくとも１つを、前記決済機関から前記販売業者へ送信することを特徴とする請求項６８記載のコンピュータで読み取り可能な媒体。
【請求項７３】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージを、前記取得者から決済機関へ送信し、
前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第一と第二の許可要求メッセージの前記少なくとも１つから得た第三の許可要求メッセージの少なくとも１つを、前記決済機関から前記支払い口座発行者へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの前記少なくとも１つを処理する照合手順を、前記支払い口座発行者が利用し、
前記第一の許可応答メッセージを、前記支払い口座発行者から前記決済機関へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記決済機関から前記取得者へ送信し、
前記第一と第二の許可応答メッセージの前記少なくとも１つと前記第一と第二の許可応答メッセージの前記少なくとも１つから得た第三の認証応答メッセージの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項６８記載のコンピュータで読み取り可能な媒体。
【請求項７４】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信し、
許可応答メッセージを生成するために、前記許可要求メッセージを処理する照合手順を、前記決済機関が利用し、
前記許可応答メッセージを、前記決済機関から前記販売業者へ送信することを特徴とする請求項６８記載のコンピュータで読み取り可能な媒体。
【請求項７５】
前記指示のセットは、更に、前記少なくとも１つのプロセッサが以下のステップを行うために指図可能で、
前記認証データから得た第一の許可要求メッセージを、前記販売業者から取得者へ送信し、
前記第一の許可要求メッセージと前記第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、取得者から決済機関へ送信し、
第一の許可応答メッセージを生成するために、前記第一と第二の許可要求メッセージの前記少なくとも１つを処理する照合手順を、前記決済機関が利用し、
前記第一の許可応答メッセージを、前記決済機関から前記取得者へ送信し、
前記第一の許可応答メッセージと前記第一の許可応答メッセージから得た第二の許可応答メッセージの少なくとも１つを、前記取得者から前記販売業者へ送信することを特徴とする請求項６８記載のコンピュータで読み取り可能な媒体。
【請求項７６】
第一のウェブページを表示するウェブページデータの第一のセットをユーザプロセッサが受信するステップと、
前記第一のウェブページが１回のクリックによる支払い手順を行うのに利用できることを前記ユーザのソフトウェアに通知するために、前記第一のウェブページが第一の隠れたフィールドを含むか否か前記ユーザプロセッサが判別するステップと、
前記第一のウェブページが前記第一の隠れたフィールドを含む場合、少なくとも１つの決済取引を行うために前記ユーザのソフトウェアを使うことを販売業者に通知するためのデータで、前記第一の隠れたフィールドを前記ユーザプロセッサが満たすステップとを有することを特徴とする、プロセッサを指図可能な指示のセットを有するコンピュータで読み取り可能な媒体。
【請求項７７】
前記指示のセットは、更に、前記第一のウェブページを利用して行う前記１回のクリックによる支払い手順を選択する信号を、口座名義人から受信するステップを行うために、前記少なくとも１つのプロセッサが指図可能であることを特徴とする請求項７６記載の方法。
【請求項７８】
前記指示のセットは、更に、
第二の隠れたフィールドと隠れたボタンを含む第二のウェブページを表すウェブページデータの第二のセットを、前記ユーザプロセッサが受信ステップと、
前記認証データを前記販売業者へ送信するために、前記第二の隠れたフィールドを口座名義人の身元を認証するための認証データで、前記ユーザプロセッサが満たすステップと、
前記認証データの前記販売業者への送信を開始するために、前記ユーザプロセッサが、前記隠れたボタン上をクリックするステップを、前記少なくとも１つのプロセッサが行うために指図可能であることを特徴とする請求項７７記載の方法。
【請求項７９】
前記指示のセットは、更に、
支払口座を前記口座名義人へ発行した支払い口座発行者から、前記認証データを、前記ユーザプロセッサが受信するステップを、前記少なくとも１つのプロセッサが行うために指図可能であることを特徴とする請求項７８記載の方法。
【請求項８０】
前記指示のセットは、更に、
前記認証データから得た許可要求メッセージを、前記販売業者から決済機関へ送信するステップと、
前記許可要求メッセージとから得たメッセージの少なくとも１つを、決済機関から支払い口座発行者へ送信するステップと、
許可応答メッセージを生成するために、前記許可要求メッセージと前記許可要求メッセージから得た前記メッセージの前記少なくとも１つを処理する照合手順を、前記支払い口座発行が利用するステップと、
支払い口座発行者から決済機関へ許可応答メッセージを送信するステップと、
許可応答メッセージと許可応答メッセージから得たメッセージの少なくとも１つを、決済機関から販売業者へ送るステップとを、前記少なくとも１つのプロセッサが行うために指図可能であることを特徴とする請求項７９記載のコンピュータで読み取り可能な媒体。
【請求項８１】
認証データから獲得した第一の許可要求メッセージを販売業者から取得者へ送信するステップと、
第一の許可要求メッセージと第一の許可要求メッセージから得た第二の許可要求メッセージの少なくとも１つを、取得者から決済機関へ送信するステップと、
第一と第二の許可要求メッセージと第一と第二の許可要求メッセージのうちの少なくと１つから獲得した第三の許可要求メッセージのうちの少なくと１つを決済機関から支払い口座発行者へ送信するステップと、
第一の許可応答メッセージを生成するために、支払い口座発行者が、前記第一と第二の許可要求メッセージの前記少なくとも１つと前記第三の許可要求メッセージのうちの前記少なくとも１つを処理するための照合手順を利用するステップと、
第一の許可応答メッセージを支払い口座発行者から決済機関に送るステップと、
第一の許可応答メッセージと第一の許可応答メッセージから得た第二の許可応答メッセージのうちの少なくと１つを決済機関から取得者へ送るステップと、
第一と第二の許可応答メッセージと第一と第二の許可応答メッセージのうちの少なくと１つから獲得した第三の許可応答メッセージのうちの少なくと１つを、取得者から販売業者へ送信するステップとを行う前記少なくとも１つのプロセッサを導くように、更に、指示のセットは動作することを特徴とする請求項７９記載のコンピュータで読み取り可能な媒体。
【発明の詳細な説明】
【関連出願へのクロスリファレンス】
【０００１】
本出願は、ここでは全体のなかで参照によって含まれる２００１年９月２６日出願の米国特許出願０９−９６３、２７４号“認証データ収集と有効化のための一般カード保持者認証フィールド（ＵＣＡＦ）を利用した共通相互操作システムと方法”の一部継続出願である。本出願は以下の追加的出願に対する優先権を主張している。追加的出願のすべてが、参照によって含まれ、それは以下のとおりである。２００１年４月１日出願の米国仮特許出願６０−２８０、７７６号“安全な支払いアプリケーション（ＳＰＡ）と一般カード保持者認証フィールド（ＵＣＡＦ）ためのシステムと方法”、２００１年６月４日出願の米国仮特許出願６０−２９５、６３０号“一般カード保持者認証フィールドを利用した安全な支払いアプリケーションのための方法とプロセス”、２００１年７月２４日出願の米国仮特許出願６０−３０７、５７５号“安全な支払いアプリケーションを利用した通信ネットワークを介した取引を行うための方法とシステム”、２００１年６月２２日出願の米国特許出願０９−８８６、４８６号“擬似的又はプロキシ口座番号のないコンピュータネットワークを介した安全な支払いを行うための方法とシステム”、２００１年６月２２日出願の米国特許出願０９−８８６、４８５号“コンピュータネットワークを介した安全な支払いを行うための方法とシステム”。
【技術分野】
【０００２】
オンラインショッピングは、販売業者にとっては経費を削減し新たな消費者を獲得しながらも、消費者にとってはかつてないほど手軽で便利になっている。しかし、多くの消費者はクレジット番号のような機密情報の盗用を恐れ、これらの利点を利用しようとしていない。このような情報の安全性を高めるために努力がなされている。例えば、セキュア・ソケット・レイヤー（ＳＳＬ）技術において、消費者と販売業者間で送るメッセージを暗号化することによって、第三者が情報を傍受して利用することができないようにしている。しかし、この方法では、販売業者は消費者の身元照合ができない。その結果、第三者が物理的なクレジットカードの盗用のような他の不正手段によってクレジットカード番号を入手しようとする場合、ＳＳＬ手法では、第三者は盗んだ情報を不正利用できない。
【０００３】
セキュア・エレクトロニクス・トランザクション（登録商標ＳＥＴ）技術では、消費者／カード保持者、販売業者、クレジットカード発行者を認証するデジタル証明書を利用して上記問題の解決を試みている。各証明書は、委託された認証機関が発行している。現在、ＳＥＴ（登録商標）は、インターネット上の決済扱い方法としては最も安全ではあるが、カード保持者のコンピュータにデジタル証明書と暗号化ソフトウェアをインストールしなければならない。
【発明の開示】
【０００４】
よって、本発明のひとつの目的は、顧客の口座番号のような機密情報を脅かされることなく、顧客がオンラインで買い物ができる決済システムを提供することである。
【０００５】
本発明の別の目的は、数多くの電子証明の発行なしで、顧客の身元を認証する決済システムを提供することである。
【０００６】
本発明のさらに別の目的は、消費者が大きいソフトウェアファイルをダウンロードする必要なく、そして消費者のコンピュータのスピードを遅くしてしまう集中的計賛を必要とせず、情報の安全性を保持してオンライン上の消費者の身元を認証できる決済システムを提供することである。
【０００７】
これらのそして他の目的は、次の本発明のアスペクトによって達成する。
【０００８】
本発明の一つの態様によれば、ユーザのソフトウェアは、ウェブページの表示に利用するウェブページデータの１セットを受信する。ユーザのソフトウェアは、ウェブページが１つ以上の隠れたフィールドを含むか否かを判断する。ウェブページが隠れたフィールドを含む場合、ユーザのソフトウェアは、行うべき第一の支払い手順を選択する。隠れたデータを販売業者に送信するために、第一の支払い手順は、隠れたフィールドを隠れたデータで満たすことを含む。ウェブページが隠れたフィールドを含まない場合、ユーザのソフトウェアは、行うべき第二の支払い手順を選択する。購入データを販売業者に送信するために、第二の支払い手順は、ウェブページの１個以上の可視フィールドを購入データで満たすことを含む。
【０００９】
本発明の別の態様によれば、ユーザのソフトウェアは、１個以上の隠れたフィールドを含むウェブページの表示に利用するウェブページデータの１セットを受信する。ユーザのソフトウェアは、支払い口座発行者の発行する支払い口座の口座名義人身元の認証する、支払い口座発行者からの認証データを受信する。認証データを販売業者に送信するために、ユーザのソフトウェアは、隠れたフィールドを認証データで満たす。
【００１０】
本発明の別の態様によれば、ユーザのソフトウェアは、第一のウェブページに表示するのに使用するウェブページデータの第一のセットを受信する。ユーザのソフトウェアは、第一のウェブページが第一の隠れたフィールドを含んでいるか否かを判断する。第一の隠れたフィールドは、ウェブページが１回のクリックによる支払い手順を行うのに利用可能であることを示す。ユーザのソフトウェアは、第一の隠れたフィールドを、ユーザのソフトウェアを少なくとも１つの決済取引を行うのに利用する旨、販売業者に通知するためデータで満たす。
【発明を実施するための最良の形態】
【００１１】
図４は、本発明の安全な決済取引を行う典型的システムを図示している。このシステムは、ユーザのソフトウェア４０２、商品及び／又はサービスを売る販売業者４０４、マスターカード（登録商標）決済機関のような決済機関４０８、支払い口座発行者４０６を含んでいる。ユーザのソフトウェア４０２は、購入者、すなわち、ソフトウェア４０２のユーザである購入者の操作するアクセスデバイス上で作動する。アクセスデバイスは、例えば、コンピュータ、携帯情報端末（ＰＤＡ）、又は携帯電話でよい。アクセスデバイスは、ユーザのソフトウェア４０２に付加した、又はその一部としてウェブブラウザ上で作動するのが好ましい。
【００１２】
多数の販売業者と口座名義人にとって共通の名前を使った隠れたフィールドと可視フィールドが識別できるように、ウェブブラウザはウェブページのフィールドの名前に基づく宛先を支援するのが、好ましい。一般的には、発行者４０６は、商品及び／又はサービス購入に利用する販売業者からのクレジットカードあるいは他の支払い口座を購入者に発行する銀行である。購入者は、銀行口座の口座名義人と言える。システムは、後で詳述するように、発行者４０６からはじまって、ユーザのソフトウェア４０２、販売業者４０４、決済機関４０８へ、そして発行者４０６に戻るループを効果的に巡る認証データ４１４を利用している。発行者４０６の受信したデータ４２０は、元の認証データ４１４から獲得すべきで、ループ上を巡っている間、認証データ４１４上で不正操作が行われていないとする。それゆえに、発行者４０６は、認証データ４１４と決済機関４０８から受信したデータ４２０に基づいて口座名義人の身元を認証し、取引の真偽を照合できる。
【００１３】
図８は、図４で示した認証データ４１４として利用可能な口座名義人の認証値（ＡＡＶ）としてここでは参照するデータ構造８０２の例を示している。ＡＡＶ８０２は、３２個の６４エンコードベースの文字を表す２値データのうちの２４バイトで構成される。第一の１４バイト８０８は、通常、システムデータを表すことができ、制御バイト８０４と他のシステムデータ８０６を含む。データのうち、残りの１０バイト８１０は、発行者４０６が定義する。制御バイト８０４は、行われるべき認証の種類に関する情報を提供する。例えば、制御バイト８０４は、口座名義人の最初の認証又は事前認証のための“８２”という１６進法表記値と続く口座名義人の認証のための“０２”値を含む。追加的認証のアプローチは、それ自身の制御バイト値によって割り当てられる。例えば、認証手順に基づく計量生物学は、制御バイト８０４のための独自の値を持っている。表Ｉは、ＡＡＶ８０２の様々な箇所を示している。
【００１４】
表Ｉ
2004535619.tif 000003
【００１５】
表Ｉは、データ構成要素番号を示している。データ構成要素番号１、即ち、制御バイト８０４は、初期認証に関連する全てのＡＡＶのための１６進法表記“８２”と設定され、これは事前認証を示す。構成要素２〜６は、システムデータ８０６であり、販売業者のウェブサイトで提供する取引の具体的内容である。構成要素番号７は、発行者の定義するデータ８１０で構成される。この構成要素は、口座名義人を特定の取引とリンクさせるデータを含んでいる。
【００１６】
発行者４０６の操作するＡＡＶ生成プロセッサ４４０が、ＡＡＶ８０２のシステムデータ８０６と発行者の定義するデータ８１０を生成し、特殊な支払いアウントにリンクさせる。口座名義人の身元の認証の要求４１２を受信したときには、ＡＡＶ生成プロセッサ４４０がシステムデータ８０６と発行者の定義するデータ８１０を２値形式で生成する。ＡＡＶ８０２の２４バイトの２値バージョンを作成するために、制御バイト８０４のみならず、データ８０６と８１０の２セットが結合する。２４バイトの２値データバージョンのベース６４のコード化では、３２文字であるＡＡＶ８０２のベース６４バージョンを生成する。
【００１７】
制御バイト８０４と販売業者の確認ページから供される情報をもとに、システムデータ８０６を生成する。データ８０６は、以下の手順で生成する。
【００１８】
１．制御バイト８０４は、ＡＡＶ８０２のために生成する。制御バイト８０４は、例えば、１６進表示値である“８２．”の２値コード化の桁表示でもよい。
【００１９】
２．売上高は、以下のステップによって生成する。
ａ）ゼロに続く８までを売上高から削除する。
ｂ）第一の残りの売上高の４桁は、４つの２値コード化した桁として売上高フィールドに置く。
【００２０】
３．ステップ２ｂで切り捨てた売上高の右端の桁数が決まる。この数は、ただ一つで、２値コード化した桁であり、売上高切捨てフィールドに置く。
【００２１】
４．３桁の通貨コードは、２値化データに変換し、残り１０ビットを１２ビットフィールド中に右に位置調整し、左に２値データ“００．”を当てる。
【００２２】
５．販売業者名は、１６進法表記のユニコード制御値のセットで示し、以下のルールを使って編集する。販売業者名がラテン文字１として表現する場合があるが、他の文字はすべて編集の必要はない。
ａ）すべてのラテン１の制御文字は削除する。これは、００００から００１Ｆと００７Ｆから００９Ｆの１６進法表記範囲のユニコード文字である。
ｂ）“＆”（１６進法表記の００２６）と、“＠“（１６進法表記の００４０）と、“１／４”（１６進法表記の００ＢＣ）と、“１／２”（１６進法表記の００８Ｄ）と、“３／４”（１６進法表記の００ＢＥ）を除き、残りのラテン１の非アルファベット文字をスペース文字で置き換える（１６進法表記の００２０）。ユニコードの非制御文字と非アルファベット文字は、００２１から００２Ｆまで、００３Ａから００４０まで、００５Ｂから００６０まで、０００７Ｂから０００７Ｅまで、００Ａ０から００ＢＦまで、００Ｄ７、と００Ｆ７のセットにある。
ｃ）通常の厳密な文字セット中（２０００から２０６Ｆまで）のどんな文字も、スペース文字（００２０）と置き換える。
ｄ）販売業者名の中の第一の３桁だけを含むため、前述第三の桁を超える、（００３０）から（００３９）のラテン１のいずれの桁も削除する。
ｅ）前のステップ（ａ）から（ｄ）までを完了した後、全ての連続するスペース文字（００２０）は、ひとつのスペース文字（００２０）と置き換える。
ｆ）前のステップ全てを完了後、前後全てのスペース文字を削除する。
【００２３】
６．編集した（又は無編集の）販売業者名のＳＨＡ−１のハッシュを生成し、表Ｉ中のデータ構成要素５を満たすのに利用する。
【００２４】
７．販売業者の支払い画面からのＭＴＳを２値化コード桁としてファイルしたＭＴＳに挿入する。
【００２５】
処理結果である１４バイトの２値化した値は、発行者の定義するデータ８１０とＡＡＶ８０２を生成するためにエンコードしたベース６４と結合する予定のシステムデータ８０６である。
【００２６】
発行者の定義するデータ８１０の生成に利用する手順は、最終的にはどのアプローチをＡＡＶ８０２の照合に利用するかによる。例えば、暗号的アプローチでは、発行者の定義するデータ８１０は、発行者４０６の選んだ数、テキスト列、あるいは他のデータを暗号化することによって生成する。例えば、暗号化するデータは、販売業者名、取引高、日付、購入に利用した口座の口座番号の一連のデータでありうる。メッセージ認証コード（ＭＡＣ）を生成するために、データを、後に詳述する秘密の鍵を使って暗号化する。ＩＳＯ認証の暗号化アルゴリズムを使って、ＭＡＣを生成するのが好ましい。ＭＡＣは、ＡＡＶ８０２からのシステムデータ構成要素８０４と８０６と共に結合する発行者の定義するデータ８１０に含まれている。認証中、発行者４０６は、真偽の照合のための発行者の定義するデータ要素８１０を、暗号を使って照合する。暗号を使ったアプローチは、ある１つの機能でＡＡＶ８０２を生成し、別の機能で照合し、その２つの機能はリアルタイム通信ではないシステムにおいて特に有益である。この暗号を使ったアプローチのために、ＡＡＶ８０２中の発行者の定義するデータ８１０は、表ＩＩ記載のデータ構成要素を含む。
【００２７】
表ＩＩ
2004535619.tif 000004
【００２８】
発行者の定義するデータ８１０は、１０バイナリ・バイトに限定されるので、上記各データ構成要素の場所のみ含めばよい。データ８１０は、ＭＡＣの４バイト、取引順序番号の４バイト、鍵表示データの１バイト、ＡＡＶフォーマットインジケータとＡＡＶ生成プロセッサインジケータの結合した合計データ量の１バイトを含むのが好ましい。
【００２９】
不正改ざんがあるか否かを、ＭＡＣは暗号を使ってチェックする。取引の照合に使うＡＡＶ生成プロセッサ４４０とＡＡＶ照合プロセッサ４４２は共に、ＭＡＣ生成に利用する秘密鍵へアクセスできる。
【００３０】
ＡＡＶ生成プロセッサ４４０は、各取引のために以下のステップを行う。
【００３１】
１．以下のＡＡＶデータ構成要素を生成する。
ＡＡＶフォーマット数、ＡＡＶ生成機能インジケータ、鍵表示データ
【００３２】
２．前のＡＡＶで使った取引順序番号を、発行者４０６の選択した所定量増加させる。増加数の右端ビットのうち、１又はそれ以上のビットを、ＡＡＶ取引順序番号のデータ構成要素として利用する。
【００３３】
３．鍵表示データで表示した鍵を使い、以下のデータを連結し暗号化してＭＡＣを生成する。すなわち、そのデータとは、（１）販売業者に提供されている口座番号、（２）ＭＡＣサブフィールド自身を除く、全てのＡＡＶ、（３）他の発行者の選択したデータ、である。暗号を使って計算したＭＡＣの左端の場所を、ＡＡＶ・ＭＡＣデータ構成要素として発行する。
【００３４】
暗号を使ったアプローチでは、ＭＡＣを生成するために、ＡＡＶ生成プロセッサ４４０の利用する秘密の暗号鍵をＡＡＶ照合プロセッサ４４２は判別する。２つのプロセッサ４４０と４４２は、秘密の暗号鍵を生成する鍵を共有するのが好ましい。ＭＡＣ生成鍵の多く（数百、数千、あるいは数百万）を、その共有鍵から得る。何年にもわたり、鍵生成のための鍵は利用できるが、ＭＡＣ生成鍵は、ＭＡＣ生成アルゴリズムと発行者の鍵管理方針の必要条件によっては比較的頻繁に変更するのが好ましい。いずれにせよ、鍵生成のための鍵が脅かされているという疑いがある場合には、その鍵を変更すべきである。
【００３５】
複数の制御（３つの制御が好ましい）の下、分割した知識を利用して、その共有した鍵生成のための鍵を、ＡＡＶ照合プロセッサ４４２が生成し、１つ又はそれ以上の鍵構成要素としてＡＡＶ生成プロセッサ４４０まで運ぶ。暗号鍵の生成と分散は、ＩＳＯ安全基準に適合すべきである。同様に、鍵生成のための鍵からＭＡＣ生成鍵を得るための仕組みも、ＩＳＯ安全基準に準じるべきである。更に、好ましくは、ＡＡＶ生成プロセッサ４４０又はＡＡＶ照合プロセッサ４４２に結合する記憶媒体に格納したいずれの暗号鍵も、ＩＳＯ基準に従って物理的脅威から鍵を保護する物理的に安全なハードウェアのみに存在する。
【００３６】
ＡＡＶ照合プロセッサが、ＡＡＶを１個以上のＡＡＶ生成プロセッサから受信すると、照合プロセッサがＡＡＶ生成プロセッサと共有するいずれの暗号鍵も、他のＡＡＶ生成プロセッサと共有するいずれの鍵とも関連性をもつべきではない。
【００３７】
以下は、初期取引用ＡＡＶの暗号を使った生成例である。
初期認証取引例のデータ：
制御バイトの値：８２
売上高：＄８７６５４．３２
通過コード：８４０
販売業者名（ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．のユニコード表示）：
００５３ ００５０ ００４１ ００２０ ００４Ｄ ００６５ ００７２
００６３ ００６８ ００６１ ００６Ｅ ００７４ ００２Ｃ ００２０ ００４９ ００６Ｅ ００６３ ００２Ｅ
ＭＴＳ：ＦＯＢ
発行者の定義したデータ：５５３９０９００４００４８６４７１２３４
販売業者名のＳＨＡ−ｌのハッシュ（上記編集後）＝３１ ９８ ＢＥ ３０ ＩＦ ＢＤ ７４ ＯＦ Ｅ２ ＡＤ ７Ｅ Ｄ２ ＥＤ ８２ ９Ｅ ６９ ０６ ＥＣ Ｅ３ ６Ｆ
２４バイナリ・バイト・ソースの結果：
８２ ８７ ６５ ３８ ４０ ３１ ９８ ＢＥ ３０ １Ｆ ＢＤ ７４ Ｆ０ ＡＢ ５５ ３９ ０９ ００ ４０ ０４ ８６ ４７ １２ ３４
３２文字のベース６４のコード化列へ変換：
ｇｏｄＩＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
【００３８】
本例の詳細は以下のとおりである。
マップ：ＡＡＡＡＡＡＡＡＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＣＣＣＣＤＤＤＤＤＤＤＤＤＤＤＤ
ソース：０２８７６５３８４０
２値：１０００００１０１００００１１１０１１００１０１００１１１００００１００００００
６ビット：
ワード：００ ４０ ２９ ３７ １４ ０４
ベース６４：Ａ ｏ ｄ ｌ ０ Ｅ
マップ：
ＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ソース：３ １ ９ ８ Ｂ Ｅ ３ ０ １ Ｆ Ｂ Ｄ ７ ４ Ｆ ０ Ａ Ｂ
２値：
００１１０００１１００１１０００１０１１１１１０００１１０００００００１１１１１１０１１１１０１０１１１０１００１１１１００００１０１０１０１１
６ビット：
ワード：００ ４９ ３８ １１ ５６ ４８ ０７ ５９ ５３ ５２ ６０
ベース６４：Ａ ｘ ｍ Ｌ ４ ｗ Ｈ ７ １ ０ ８ Ｋ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：５５３９０９００４０
２値：０１０１０１０１００１１１００１００００１００１０００００００００１００００００
６ビット：
ワード：４５ ２１ １４ １６ ３６ ００ １６
ベース６４：ｔ Ｖ ０ Ｑ ｋ Ａ Ｑ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：０ ４ ８ ６ ４ ７ １ ２ ３ ４
２値：０００００１００１００００１１００１０００１１１０００１００１０００１１０１００
６ビット：
ワード：００ １８ ０７ １７ ４９ ０８ ５２
ベース６４：Ａ Ｓ Ｈ Ｒ ｘ Ｉ ０
結果：
２４バイト・ソース：８２ ８７ ６５ ３８ ４０ ３１ ９８ ＢＥ ３０ ＩＦ ＢＤ ７４Ｆ０ ＡＢ ５５ ３９ ０９ ００ ４０ ０４ ８６ ４７ １２ ３４
３２文字のベース６４のコード化列へ変換：ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
【００３９】
以下は、暗号を使って、次の取引に対するＡＡＶ生成の例である。
次の取引例の期日：
制御バイト値：８２
売上高：＄８７６５４．３２
通貨コード：８４０
販売業者名（ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．のユニコード表示）：
００５３ ００５０ ００４１ ００２０ ００４Ｄ ００６５ ００７２
００６３ ００６８ ００６１ ００６Ｅ ００７４ ００２Ｃ ００２０
００４９ ００６Ｅ ００６３ ００２Ｅ
ＭＴＳ：ＦＯＡＢ
発行者の定義したデータ：５５３９０９００４００４８６４７１２３４
販売業者名のＳＨＡ−ｌのハッシュ（上記編集後）＝３１ ９８ ＢＥ ３０ ＩＦ ＢＤ ７４ ＯＦ Ｅ２ ＡＤ ７Ｅ Ｄ２ ＥＤ ８２ ９Ｅ ６９ ０６ ＥＣ Ｅ３ ６Ｆ
２４バイナリ・バイトのソースの結果：
０２ ８７ ６５ ３８ ４０ ３１ ９８ ＢＥ ３０ ＩＦ ＢＤ ７４ Ｆ０ ＡＢ ５５ ３９ ０９ ００ ４０ ０４ ８６ ４７ １２ ３４
３２文字のベース６４のコード化列へ変換：
ＡｏｄＩＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲＩ０
本例の詳細は以下のとおり。
マップ：ＡＡＡＡＡＡＡＡＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＣＣＣＣＤＤＤＤＤＤＤＤＤＤＤＤ
ソース：８２８７６５３８４０
２値：１０００００１０１００００１１１０１１００１０１００１１１００００１００００００
６ビット：
ワード：３２ ４０ ２９ ３７ １４ ０４
ベース６４：ｇｏｄ１ＯＥ
マップ：ＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＦＦＦＦＦＦＦ
ソース：３１９８ＢＥ３０１ＦＢＤ７４Ｆ０ＡＢ
２値：００１１０００１１００１１０００１０１１１１１０００１１０００００００１１１１１１０１１１１０１０１１１０１００１１１１００００１０１０１０１１
６ビット：
ワード：００ ４９ ３８ １１ ５６ ４８ ０７ ５９ ５３ ５２ ６０ １０
ベース６４：Ａ ｘ ｍ Ｌ ４ ｗ Ｈ ７ １ ０ ８ Ｋ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：５５３９０９００４０
２値：０１０１０１０１００１１１００１００００１００１００００９００００１００００００
６ビット：
ワード：４５ ２１ １４ １６ ３６ ００ １６
ベース６４：ｔ Ｖ Ｏ Ｑ ｋ Ａ Ｑ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：０４８６４７１２３４
２値：０００００１００１００００１１００１０００１１１０００１００１０００１１０１００
６ビット：
ワード：００ １８ ０７ １７ ４９ ０８ ５２
ベース６４：Ａ Ｓ Ｈ Ｒ ｘ Ｉ ０
結果：
２４バイト・ソース：８２ ８７ ６５ ３８ ４０ ３１ ９８ ＢＥ ３０ ＩＦ ＢＤ ７４Ｆ０ ＡＢ ５５ ３９ ０９ ００ ４０ ０４ ８６ ４７ １２ ３４
３２文字のベース６４のコード化列へ変換：ｇｏｄＩＯＥＡｘｍＬ４ｗＨ７Ｉ０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
マップ凡例：
Ａ―２値コードの桁（ＢＣＤ）として表した制御バイト値
Ｂ―売上高―ＢＣＤとして表した４つの最上位桁
Ｃ―売上高切捨てフィールド―ＢＣＤとして表した１桁
Ｄ―通貨コード―２値化して表した３桁
Ｅ―販売業者名のＳＨＡ−１のハッシュ―ＳＨＡ−１のハッシュ値のはじめの７バイト
Ｆ―ＭＴＳ―２バイト値
Ｇ―ＢＣＤとして表した発行者の定義するデータ、１０バイト
【００４０】
比較アプローチは、ＡＡＶ生成と照合機能は、例えば、共通データ記憶システムを介するなど相互にリアルタイムで通信するシステムに好適である。比較アプローチでは、ランダム値又は発行者４０６の選択した他のアルゴリズムを使って、発行者の定義するデータ８１０を生成する。結果の値８１０は、ＡＡＶ８０２への／からのシステムデータ８０６と結合する。その場合、ＡＡＶ８０２を、取引真偽を照合するためのＡＡＶ照合プロセッサ４４２の利用する共通データベースへ保存する。照合中、認証要求４２０の受信したＡＡＶをデータベースに格納したＡＡＶと比較することによって、発行者４０６は取引の真偽を照合する。比較アプローチ陽のＡＡＶを生成し、以下の手順に従って格納する。
【００４１】
１．発行者の定義、例えば、ランダム数ジェネレータなどに従って、発行者の定義するデータ８１０を生成する。
【００４２】
２．発行者の定義するデータ８１０を、少なくとも特定の口座番号とリンクするデータベースに格納する。
【００４３】
３．販売業者の隠れたフィールドデータを、少なくとも発行者の定義するデータ８１０とリンクするデータベースに格納する。
【００４４】
４．データベースを、ＡＡＶ照合プロセッサ４４２で利用可能にする。
【００４５】
５．発行者の定義するデータ構成要素８１０を、２４バイトの２値への／からのシステムデータ構成要素８０８と結合する。２４バイトの２値化の値は、３２文字７０２生成のために、ベース６４でコード化する。
【００４６】
図１は、上記ＡＡＶ８０２を含む認証データ４１４を使った図４で示した決済取引システムの操作の典型的手順を図示している。図中の手順においては、販売業者４０４の操作するサーバ４４８で利用可能なウェブサイトの様々なページを口座名義人が見る（ステップ１３２）。購入者が、自分が販売業者４０４から購入したいと思う商品及び／又はサービスを見つけて選択する（ステップ１１４）。商品及び／又はサービスを選択すると、口座名義人が販売業者の精算手順を開始する（ステップ１１６）。例えば、一般的に利用されている“ショッピングカート”方法では、仮想ショッピングカート、すなわち、買い物客が仮に購入しようと考えたアイテムのリストに置く商品及び／又はサービスを買い物客が選択する。買い物客がアイテムのリストに完全に満足すれば、どの時点でショッピングカートのアイテムについて精算手順を開始するかを販売業者のウェブページ上の可視的な“精算”ボタンでクリックして買い物客は精算の開始を行う。他の可能な方法では、１回のクリックによる精算手順を利用している。その１回のクリックによる精算手順では、販売業者４０４が口座名義人の情報を格納し、情報を多数取引のために利用している。格納した情報は、口座名義人の請求先と出荷先のアドレス、Ｅメールアドレス、口座番号、口座有効期限を含む。その場合、アイテムに関連した可視的“購入”ボタンをクリックすることによって、口座名義人は即座にアイテムの精算の開始が行える（ステップ１１６）。
【００４７】
発行者４０６の普及した基準に従って、販売業者のウェブサイトが１回のクリックで購入できるように構成されている場合、１回のクリックで購入ができる各販売業者のウェブページは、“ＵＣＡＦ使用可能インジケータフィールド”とも言える特定の隠れたフィールドを含んでいる。この特定の隠れたフィールドは後に詳述する。ウェブページ上のこの隠れたフィールドの存在は、ユーザのソフトウェアにウェブページが１回のクリックによるショッピングを行えるよう構成されている旨知らせるものである。
【００４８】
精算フェーズが開始されると（ステップ１１６）、ＵＣＡＦ使用可能インジケータフィールドがウェブページ上には存在しない場合（ステップ１２８）、ユーザのソフトウェア４０２は、販売業者４０４からの新たなウェブページデータ４１０をネットワーク４３４の場所４２６を介して要求・受信する（ステップ１０２）。ネットワーク４３４は、例えば、インターネットでもよい。ウェブページデータは、口座名義人のコンピュータ画面上の“精算”ウェブページ（別名、“注文確認”ウェブページ）を表示するのに利用する。口座名義人及び／又はユーザのソフトウェア４０２は、いくつかのあるいは全てのこの情報を確認ページ上のフィールドに入れることによって、請求先アドレス、出荷先アドレス、及び／又は支払い口座の詳細を販売業者４０４に提供する（ステップ１３０）。請求及び出荷アドレス情報は、口座名義人によって手動で入力するか、ユーザのソフトウェア４０２によって自動的に満たすか、又は特定の口座名義人のための販売業者のサーバに格納した情報に基づいて自動的に満たす。注文を確認するために、口座名義人は、可視的確認ページ上の“提出”ボタンをクリックする（ステップ１３２）。上記のように認証データ４１４を使って作動するように販売業者４０４のウェブサイトを構成している場合、販売業者の注文確認ページは、以下の１個以上の隠れたフィールドを含む。
【００４９】
（１）ユーザのソフトウェア４０２に情報を配信する隠れたフィールド、（２）ユーザのソフトウェア４０２からのＡＡＶのような情報を受信する隠れたフィールド。これらの隠れたフィールドは、ここではまとめて“一般カード保持者認証フィールド（ＵＣＡＦ）”と呼び、これは以下で詳述する。確認ページ上のＵＣＡＦを介して、ユーザのソフトウェア４０２は以下の情報のいくつか又は全てを受信する。
【００５０】
表ＩＩＩ
2004535619.tif 000005
【００５１】
販売業者の注文確認ページ中に含まれるこれら隠れたフィールドの具体的な値は、以下のとおり与えられる。具体的な値は、以下取引詳細に基づく。
販売業者名：ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．
販売業者の所在地：購入場所は、ニューヨーク
取引高：ＵＳ＄８７６５４．３２
販売業者の所有するフィールド：
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｍｅｒｃｈａｎｔ＿Ｎａｍｅ”ｖａｌｕｅ＝”００５３００５０００４１００２０００４Ｄ００６５００７２００６３００６８００６１００６Ｅ００７４００２Ｃ００２０００４９００６Ｅ００６３００２Ｅ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｃｉｔｙ”ｖａｌｕｅ＝”Ｐｕｒｃｈａｓｅ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｓｔａｔｅ＿Ｃｏｕｎｔｒｙ”ｖａｌｕｅ＝”ＮＹ”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｃｕｒｒｅｎｃｙ＿Ｃｏｄｅ”ｖａｌｕｅ＝”８４０”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｓａｌｅ＿Ａｍｏｕｎｔ”ｖａｌｕｅ＝００００８７６５４３２１”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿ＭＴＳ”ｖａｌｕｅ＝”Ｆ０ＡＢ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｂｒａｎｄ”ｖａｌｕｅ”０１”
発行者サーバの所有するフィールド
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿Ｄａｔａ”ｖａｌｕｅ＝”
ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１Ｏ８ＫｔＶＯＱｋＡＱＡＳＲＲｘＩ０”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿Ｎｕｍｂｅｒ”ｖａｌｕｅ＝”
１２３４５６７８９９８７４５６３”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＥｘｐＤａｔｅ＿Ｍｏｎｔｈ”ｖａｌｕｅ＝”０２”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＥｘｐＤａｔｅ＿Ｙｅａｒ”ｖａｌｕｅ＝”２００４＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＪＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＣＶＣ２”ｖａｌｕｅ＝”２５６”＞
【００５２】
特定の口座名義人からの経常的支払いの受信を希望する販売業者のために、以下の情報をＵＣＡＦ構造内にて収集する。
【００５３】
取引頻度−これは、経常的支払いの頻度を示す。販売業者の割り当てる有効値は、週が“Ｗ”、月が“Ｍ”、四半期が“Ｑ”、年が“Ａ”である。
【００５４】
支払い回数−口座名義人と販売業者間の経常的支払いの合計を判定するためのもの。このフィールドに、支払い不履行の最大限度値がないのが好ましい。この経常的支払い機能を利用する各ブランドは、自身の実行限度値を設定してもよい。例えば、支払いの最適最大数は、２６０である。
【００５５】
第一回目の支払い−このフィールドは、第一回目の経常的支払いのＤＤＭＭＹＹＹＹと表現した期日と経常的支払い関係とに口座名義人が同意するか否かを伝えるものである。
【００５６】
販売業者取消し方針−このフィールドは、口座名義人が経常的支払いをキャンセルできるか否かを示している。値が“１”は、「はい」、“０”は「いいえ」である。経常的支払いの構成要素は、ＵＣＡＦのために定義した１つの隠れたフィールドと選択的に結合できる。この新たな隠れたフィールドは、Ｕｃａｆ＿Ｒｅｃｕｒ＿Ｐａｙｍｅｎｔと名づけられ、以下の場所を含む。
【００５７】
“ＦＮＮＮＤＤＭＭＹＹＹＹＣ”において、
・Ｆは、経常的支払いの頻度。有効値は以下の通り。
Ｗ−週、Ｍ−月、Ｑ−四半期、Ａ−年
・ＮＮＮは、経常的支払い数。
・ＤＤＭＭＹＹＹＹは、第一の経常的支払いの期日。例えば、２０００年５月２９日は、“２９０３２００２”と表す。
・Ｃ−販売業者キャンセル方針。これは、カード保持者が経常的支払いをキャンセルできるか否かを示している。値が“１”は、「はい」、“０”は「いいえ」である。
【００５８】
例えば、販売業者４０４が１年間に毎月という内容で２００１年３月１日に第一の支払いを行うという経常的支払いを支援する場合や、口座名義人が取引のキャンセルを許される場合に、Ｕｃａｆ＿Ｒｅｃｕｒ＿Ｐａｙｍｅｎｔの値は、“Ｍ１２０１０３２００１１”となる。このアプローチでは、経常的支払いのための複数の隠れたフィールドを販売業者４０４が繰返し満たさなければならない。何故なら、１つの隠れたフィールドに情報が集約されるからである。
【００５９】
販売業者４０４は、販売業者の支払いページの隠れたフィールドの１つに、販売業者取引スタンプ（ＭＴＳ）を選択的に含むことができる。ＭＴＳは、各取引に固有であり、よって、追加的な安全フォームとして利用できる。特に、ＭＴＳは、口座名義人が販売業者のウェブサイトに実際アクセスしたことを示すのに利用して、取引が正当なものであって、不正な販売業者の再取引や正当な販売業者と見せかける他者ではないという証拠を提供する。
【００６０】
１回のクリックによる購入以外の取引のために、販売業者名や売上高などの口座名義人情報を表示するための可視的フィールドを、注文確認ページは含む。買い物客が確認ボタンをクリックする前に、販売業者名と取引高は確認ページ上で見ることができるという事実は（後に説明する図２のステップ２１０）、口座名義人が実際取引を確認・了承したという追加的証拠を提供する。この特徴は、口座名義人による取引拒否を発行者４０６が厳密に調べる際の助けとなる。
【００６１】
図１を再び参照すると、販売業者４０４の注文確認ウェブページが、上記隠れたフィールドを含む場合（ステップ１０４）、この場合、発行者４０６から始まってユーザのソフトウェア４０２、販売業者４０４、決済機関４０８へと続き発行者４０６へと戻るループ中に認証データ４１４を送る上記技術を利用する認証手順１０６を使って、購入を行う。一方、注文確認ウェブページが隠れたフィールドを含まない場合（ステップ１０４）、続いて、ユーザのソフトウェア４０２は、クレジットカード番号や有効期限などの購入データを伴うウェブページの可視的フィールドを満たすことを含む従来の支払い手順１０８を行い（ステップ１１０）、購入データを販売業者４０４へ認証目的に送信するために、データで満たされたウェブページフィールドを利用する（ステップ１１２）。
【００６２】
ステップ１２８では、口座名義人が“購入”ボタンをクリックしたウェブページにＵＣＡＦ使用可能インジケータフィールドが存在する場合、ユーザのソフトウェア４０２は、ＵＣＡＦ使用可能インジケータフィールドを、口座名義人がＵＣＡＦ使用可能な決済取引を行うユーザのソフトウェア４０２を利用していることを販売業者４０４に通知するコード（例えば、“０１”）で満たす（ステップ１３４）。コードで満たしたＵＣＡＦ使用可能インジケータフィールドを含むウェブページを、販売業者４０４に提示する（ステップ１３６）。販売業者４０４は、確認ページデータをユーザのソフトウェア４０２に送信する（ステップ１３８）。しかし、購入者は、例えば、“注文を処理しています。”という簡単なメッセージを含んだページ又はウィンドウを見るにすぎない。このメッセージを表示している間に、ユーザのソフトウェア４０２は、口座名義人のアドレス情報と口座番号を有する確認ページ上の様々な隠れたフィールドを自動的に満たす（ステップ１４０）。
【００６３】
次に、認証手順１０６を行う。
【００６４】
いずれの場合でも、認証手順１０６又は認証手順１０８において、認証が付与されれば（ステップ１１８）、商品及び／又はサービスを出荷し配達するか、そうでなければ、購入者に提供する（ステップ１２０）。精算と決済手順は、発行者４０６と決済機関４０８間の精算と決済を行うために利用できる（ステップ１２２）。販売業者４０４は取得者と取引があれば（以下説明する図５のアイテム５１４）、支払いを発行者４０６と取得者５１４間で精算・決済する（ステップ１２２）。
【００６５】
一方、認証が拒否されれば（ステップ１１８）、口座名義人は拒否を通知される（ステップ１２４）、そして取引を終える（ステップ１２６）。
【００６６】
取引を認証するための認証データ４１４を利用する手順１０６の例を図２に示す。販売業者の注文確認ページ中の隠れたフィールドから受信した及び／又は口座名義人の提供した情報を含みながら、ユーザのソフトウェア４０２は発行者４０６に口座名義人の身元認証の要求４１２を送信する（ステップ２０２）。ネットワーク４３４の場所４２８を介して要求４１２を送る。口座名義人の身元認証の要求４１２に応答して、発行者４０６はＡＡＶのような認証データ４１４をユーザのソフトウェア４０２へネットワーク４２８を介して送信する。ユーザのソフトウェア４０２が発行者４０６からの認証データ４１４を受け取ると（ステップ２０４）、ソフトウェア４０２は隠れたデータ４１６中の認証データ４１４を含み（ステップ２０６）、販売業者４０４のウェブページ上の隠れたフィールドを満たすために隠れたデータ４１６を利用する（ステップ２０８）。例えば、ＡＡＶは、確認ページ上で隠れた認証データフィールドに入れる。
【００６７】
各取引ごとに各口座名義人を認証するのが好ましい。口座名義人の認証に失敗すれば、失敗の旨、口座名義人に通知する。口座名義人であることが確認できれば、発行者のＡＡＶ−生成プロセッサ４４０は、ＡＡＶ８０２を生成する。この場合、発行者４０６は認証データ４１４中のＡＡＶ８０２を含み、データ４１４をユーザのソフトウェア４０２に送る。
【００６８】
ユーザのソフトウェア４０２の入力した確認ページ上の隠れたフィールドにある他の情報は、口座名義人の支払い口座の詳細、例えば、彼（女）の口座番号、有効期限、そして任意にカード有効性確認（ＣＶＣ２）値などを含む。更に、隠れたフィールドは上記ＵＣＡＦ使用可能インジケータフィールドを含むのが好ましい。状況によっては、販売業者の供給した口座番号（口座名義人が書かれている場合）と隠れた口座番号フィールドに挿入された口座番号間の相違点をユーザのソフトウェア４０２は確認できる。ユーザのソフトウェア４０２は口座名義人に相違点を警告し確認を要求する。場合によっては、口座名義人が発行者４０６と共に登録された複数の口座を持つ。このような場合、口座名義人は支払いに利用する口座番号を選択する。
【００６９】
確認用ウェブページの隠れたフィールドがデータで満たされれば、そのページは認証データ４１４（ＡＡＶ８０２を有する）、支払い口座情報、他の関連情報を有する隠れたデータ４１６を含む。ページ上の“提示”ボタンをクリックして、確認ページを販売業者４０４に提示する（ステップ２１０）。これが例えばショッピングカート型取引の場合、この提示ボタンが口座名義人には見えて、口座名義人がこれをクリックする。しかし、１回のクリックによる取引においては、提示ボタンは隠れたままで、ユーザのソフトウェア４０２が提示ボタンを自動的にクリックする。
【００７０】
販売業者４０４は、確認ページ上の隠れたデータ４１６を受信し、制御バイト８０４とＡＡＶ８０２に含まれる販売業者名のハッシュを有効化する。状況によっては、販売業者４０２は販売業者取引スタンプ（販売業者が生成していれば）と売上高の照合も行える。
【００７１】
好ましくは、販売業者４０４が、口座名義人を特定の取引へリンクに利用するＡＡＶを獲得し保持する。分割出荷の次の認識を行うのに、そのデータを使うことができ、例外的処理の間はそのデータを販売業者４０４の値としてもよい。
【００７２】
販売業者４０４が不正なＡＡＶ８０２を受信していないこと確認するため、最上位ビットが“１”であることを確認して、制御バイト８０４を照合する。これは、ベース６４でエンコード化したＡＶＶ８０２の最左端の文字が小文字の“ｇ”であることを照合することによって行われる。
【００７３】
ＡＡＶに含まれる販売業者名のハッシュが正確には隠れたフィールドの１つに含まれる販売業者名のハッシュと一致することを確認して、販売業者名の照合を行う。これを達成するために、ベース６４でコード化したＡＶＶ８０２の７〜１６文字が、正確に前計算値と一致するかを販売業者４０４は照合する。販売業者名のＳＨＡ−１のハッシュの処理を行うことによって、この前計算値が得られる。
【００７４】
例えば、ＡＡＶは以下のデータであってよい。
ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘ１０
【００７５】
販売業者照合プロセスでは、７から２６文字を分析する。
ＡｘｍＬ４ｗＨ７１０
【００７６】
販売業者４０４は、この前計算値と既知の販売業者名のＳＨＡ−１のハッシュを比較する。この値の有効化に成功しない場合、販売業者４０４は取引を断る。
【００７７】
状況によっては、隠れたフィールドの１つに示した売上高に基づいて、販売業者４０４はＡＡＶ売上高を有効化する。販売業者４０４はベース６４でコード化したＡＶＶ８０２を２４バイナリ・バイトのソースに変換し、売上高、売上高切捨てフィールド、取引通貨コードを識別する。表Ｉのデータ内容と隠れたフィールドを介して示した売上高と通貨コードに従って、販売業者４０４は売上高、売上高切捨てフィールド、取引通貨コードを有効化させていく。値の有効化に成功しなかった場合、販売業者４０４は取引を断る。
【００７８】
販売業者４０４はＡＡＶ８０２で得られたＭＴＳを任意に有効化させる。ＭＴＳを有効化した場合、販売業者４０４はＡＡＶ８０２のＭＴＳ構成要素を識別し、それを注文確認ページの隠れたフィールドに示したＭＴＳと比較する。この値の有効化に成功しなかった場合、販売業者４０４は取引を断る。何故なら、ＡＡＶ８０２はおそらく不正だからである。
【００７９】
販売業者４０４は隠れたデータ４１６から許可要求メッセージ４１８を獲得し（ステップ２２２）、許可要求メッセージ４１８を決済機関４０８に追加的ネットワーク又はネットワーク部４３０を介して送る（ステップ２１２）。なぜなら、隠れたデータ４１６は、認証データ４１４を含み、許可要求メッセージ４１８は最終的には認証データ４１４から得るからである。
【００８０】
許可要求メッセージ４１８は、少なくとも以下のデータ構成要素を含むのが好ましい。
・販売業者に送る口座名義人の支払い口座番号
・販売業者名
・通貨コード
・売上高
・販売業者取引スタンプ（この構成要素が使われていない場合、販売業者４０４がデフォルト値を１６進法表記の“００００”に設定する）
状況に応じて、以下のデータ構成要素が含まれる。
・カード引受人の市
・カード引受人の州／国
【００８１】
何故なら、隠れたデータ４１６と許可要求メッセージ４１８は、機密の取引特定データを含み、それをインターネットのような公のネットワークを通じて送信してもよいので、隠れたデータ４１６と許可要求メッセージ４１８は、データが脅かされないよう、例えば、１２８ビットのＳＳＬ又はそれと同等の安全な暗号化方法を利用して保護するのが好ましい。
【００８２】
決済機関４０８は、別のネットワーク又はネットワーク部４３２を介して、許可要求メッセージ４２０を発行者４０６に送信する（ステップ２１４）。決済機関４０８から発行者４０６に送る許可要求メッセージ４２０は、一般的には販売業者４０４から決済機関４０８に送った許可要求メッセージ４１８と同じか、又はこれから獲得する。許可応答メッセージ４２２を生成するため、発行者４０６は、許可要求メッセージ４２０を処理するための照合手順２１６を利用する。
【００８３】
図６は、許可要求メッセージ４２０を生成するため、図１と図２を参照して説明した許可応答メッセージ４２２を処理するのに発行者４０６が利用する典型的な手順２１６を示している。図６に示した典型的な手順２１６は、上記のとおり暗号を使って生成したＡＡＶ８０２の利用に適し、暗号を使った照合アブローチを利用している。図示した手順２１６では、発行者４０６の操作する暗号を使ったＡＡＶ照合プロセッサ４４２が、機能によって受信した各許可要求メッセージ４２０のための以下のステップを行う。
【００８４】
安全レベルのルーティング
１．安全レベルインジケータが１という値に設定されると（ステップ６０２）、照合プロセッサ４４２は、ＵＸＡＦベースの照合システムのために、口座番号が登録されていることを照合する（ステップ６０４）。口座が登録されていれば（ステップ６０４）、プロセッサ４４２は取引を断る（ステップ６０６）。何故なら、このようなシナリオは以下の（ｉ）口座名義人が、決済取引を処理するための自分のＵＣＡＦ使用可能なソフトウェア４０２を使っていなかったから又は（２）非認証の第三者が取引を開始していたからである。
ａ）口座が、ＵＣＡＦベースで登録されてない場合（ステップ６０４）、認証要求を、従来の（即ち、非ＵＣＡＦベース）支払い処理用に構成された認証システムに転送する（ステップ６０８）。
【００８５】
２．安全レベルインジケータが２に設定されている場合、（ステップ６０２）、プロセッサ４４２は、以下のとおり、ＡＡＶ照合処理をすすめる。
【００８６】
ＡＡＶ照合
１．示されていたデータフォーマットに基づいて、ＡＡＶを許可要求メッセージから抽出し、ベース６４でデコードし、解釈する（ステップ６１０）。
【００８７】
２．ＡＡＶの鍵識別データ、そのＡＡＶ生成プロセッサインジケータ、その取引順序番号を使って、照合プロセッサ４４２は、ＭＡＣ照合に利用する暗号鍵を判別する（ステップ６１２）。
【００８８】
３．適当なＭＡＣアルゴリズムを使って、プロセッサ４４２は、ＡＡＶ８０２内でＭＡＣの照合を試みる（ステップ６１４）。ＭＡＣの照合に不成功の場合（ステップ６１６）、取引を断る（ステップ６１８）。何故なら、ＡＡＶ８０２は有効ではなく、よって取引は不正とみられるからである。
【００８９】
４．ＡＡＶの制御バイトが、これが初期認証要求であることを示している場合（ステップ６２０）、
ａ）プロセッサ４４２は、（ＡＡＶ生成プロセッサ４４０からの）同じ取引順序番号か否かチェックし、“ｎ”秒以上前に受信した前の初期認証において、売上高が既に生じている（ここでは、“ｎ”は発行者が特定し、代表的に６０とする）（ステップ６２６）。
ｉ）注：対応する許可応答メッセージが失われている場合、許可要求メッセージの自動再送のために、例えば、秒という具合に、選択的に遅延が可能である。
ｂ）取引順序番号が、“ｎ”以上秒前に受信した前の許可要求メッセージにおいて既に発生したものである場合（ステップ６２６）、そのときは、取引を断る、即ち、このＡＡＶ生成プロセッサ４４０からのこの取引順序番号は、“コピーとして検出したもの”である（ステップ６２８）。試みられた取引は、以前の有効ＡＡＶの不正な再生を含んでいる。
ｃ）取引順序番号がまだ発生していない場合（ステップ６２６）、そのときは、ＡＡＶの取引順序番号を、将来の取引に“利用する”ものとして識別する（ステップ６３２）。
ｄ）この初期認証要求のＡＡＶ８０２を照合した後、発行者４０６は、状況に応じて口座名義人の登録状況を確認でき、自動的に口座名義人を登録する（ステップ６３４）。
ｅ）ＡＡＶが有効であると確認したので、この取引の照合は成功である（ステップ６３０）。成功した照合の表示は、許可応答メッセージ４２２に含まれる。
【００９０】
５．このＡＡＶの制御バイト８０４が、これは次の認証要求であることを示している場合（ステップ６２０）、またＡＡＶの取引順序番号が、使用しているＡＡＶ生成プロセッサ４４０に対する“コピーとして検出したもの”である場合（ステップ６２２）、取引を断る（ステップ６２４）。これは、販売業者に由来する既に再生したＳＰＡ取引の再提示である。
【００９１】
６．一方、ＴＳＮがコピーとして検出したものでない場合（ステップ６２２）、ＡＡＶは有効で、それゆえに取引の照合は成功している（ステップ６３０）。照合成功の表示は、それゆえに許可応答メッセージ４２２に含まれる。
【００９２】
照合を行うため、発行者４０６のＡＡＶ照合プロセッサ４４２は、ＵＣＡＦベース認証のために登録した口座番号毎の記録を維持するのが好ましい。更に、ＡＡＶ照合プロセッサ４４２は、各ＡＡＶ生成プロセッサ４４０と共有する鍵生成のための鍵（又は複数の鍵）を格納している。また、口座番号とそれと関連したＡＡＶの不正な再生を検出するために、ＡＶＶ照合プロセッサ４４２は、どのＡＡＶを既に受信したかを示す記録を格納している。
【００９３】
また、ＡＡＶ照合は比較アプローチを利用して行える。例えば、図７に示した照合手順２１６において、ＡＡＶ照合プロセッサ４４２は、各許可要求メッセージのため以下のステップを行う。
【００９４】
１．安全レベルインジケータが“１”に設定されている場合（ステップ６０２）
ａ）プロセッサ４４２は、口座番号がＵＣＡＦベースのシステムに登録されているか否かを判別する（ステップ６０４）。口座が登録されている場合（ステップ６０４）、取引は断られる（ステップ６０６）、何故なら、このようなシナリオでは、口座名義人が決済取引を処理するための自分のＵＣＡＦの可能なソフトウェア４０２を使っていなかったこと、又は非認証の第三者がこの取引を開始したことを示しているからである。
ｂ）口座がＵＣＡＦベースで登録されていない場合（ステップ６０４）、認証要求を、従来の（即ち、非ＵＣＡＦベースの）支払い処理のための発行者の認証システムに転送する（ステップ６０８）。
【００９５】
２．安全レベルインジケータが“２”に設定されている場合（ステップ６０２）
ａ）プロセッサ４４２は、口座番号がＵＣＡＦベースのシステムに既に登録されているか否かを判別する（ステップ７０２）。登録されている場合（ステップ７０２）、発行者４０６は、認証要求からのＡＡＶを抽出し（ステップ７０６）、以下説明する更なる処理を続ける。
ｂ）口座が登録されていない場合（ステップ７０２）、この取引は断られる（ステップ７０４）。
【００９６】
３．この口座が登録されている場合（ステップ７０２）、ステップ７０６の後に、許可要求メッセージのＡＡＶ８０２は、ベース６４でデコードする（ステップ７０８）。
【００９７】
４．これが初期認証要求であることをＡＡＶのコントロールバイトが示している場合（ステップ７１０）、許可要求メッセージ４２０に含まれる取引データを有する発行者のデータベースに格納したＡＡＶ取引情報の比較に基づいて、以下のＡＡＶ手順が行われる。
ａ）認証要求中に受信したＡＡＶが、発行者のデータベースの登録に一致していることをプロセッサ４４２が認証する（ステップ７１２）。一致する登録がない場合（ステップ７１２）、取引は断られる（ステップ７１４）。
ｂ）受信したＡＡＶが、一致していることに基づいて有効であると判別した場合（ステップ７１２）、発行者の定義するデータ８１０が以前の取引において受信されていないことをプロセッサ４４２は照合し、発行者の定義するデータ８１０を“ｎ”秒以上前の以前の取引において受信している場合（ここでは、“ｎ”は代表的に６０に等しい）（ステップ７１６）、その取引は断られ、ＡＡＶ８０２はコピーとして検出されたものとなる（ステップ７１８）。
ｃ）発行者の定義するデータ構成要素を以前に受信している場合、（ステップ７１６）、そのときは、発行者の定義するデータ８０２は“利用した”となり（ステップ７２０）、発行者の定義するデータ８１０を追加的に有効化する（ステップ７２２）。
ｄ）追加的なデータの有効化は、許可要求メッセージ４２０に含まれるデータを有する販売業者隠れたフィールドから獲得したデータの比較を含むことができる（ステップ７２２）。これによって、発行者４０６は口座番号や販売業者名などの追加的なフィールドを有効化できる。データの照合に成功した場合（ステップ７２２）、このＡＡＶ８０２の照合は成功である（ステップ７２６）。照合成功の表示は、それ故に許可応答メッセージ４２２に含まれる。データが一致しない場合（ステップ７２２）、そのとき、取引は断られる（ステップ７２４）。
【００９８】
５．ＡＡＶのコントロールバイトが、これが次の認証要求であることを示す場合（ステップ７１０）、以下のステップを行う。
ａ）発行者の定義するデータ８１０が、“コピーしたものとして疑わしい”データセットである場合（ステップ７２８）、プロセッサ４４２は取引を断る（ステップ７３０）。
ｂ）発行者の定義するデータ８１０が初期認証において受信されておらず、“コピーしたものとして疑わしい”データセットでない場合（ステップ７２８）、プロセッサ４４２は、許可要求メッセージ４２０中に含まれるデータを有する販売業者の隠れたフィールドから獲得したデータを比較することによって、追加的な有効化の確認を行う（ステップ７２２）。これによって、発行者４０６は口座番号と販売業者名を有効化できる。データが一致する場合（ステップ７２２）、この照合は成功であり（ステップ７２６）、それ故に、照合成功の表示が許可応答メッセージ４２２に含まれる。
【００９９】
暗号を使った又は比較による照合アプローチが許可応答メッセージ４２２の生成に利用されたか否かに関わらず、発行者４０６は、許可応答メッセージ４２２を決済機関４０８へネットワーク又はネットワーク部４３２を介して送信する（ステップ２１８）。決済機関４０８は、許可応答メッセージ４２４を販売業者４０４へネットワーク又はネットワーク部４３０を介して送信する（ステップ２２０）。許可応答メッセージ４２２は、代表的に発行者４０６から決済機関へ送信した許可応答メッセージ４２２と同じか、又はこれから得たものである。
【０１００】
状況によっては、決済機関４０８は、発行者４０６に代わって、照合手順２１６を行うことができ、その場合、決済機関４０８は、認証メッセージ４２４を生成するための許可要求メッセージ４１８を処理する自身の照合プロセッサ４４６を含む。換言すれば、決済機関４０８は、許可応答メッセージを生成するための許可要求メッセージを処理する役割において、発行者４０６の“代理を務める”ことができる。発行者の認証システムが一時的に使用できない場合、このような“代行処理”は、特に有益である。何故なら、この“代行処理”によって、許可応答メッセージ４２２を生成するために処理する許可要求メッセージ４２０を発行者４０６へ送信する必要がなくなる、即ち、発行者４０６からの許可応答メッセージ４２２が不要になるからである。
【０１０１】
いずれにせよ、発行者４０６又は決済機関４０８が照合手順２１６を行ったか否かに関わらず、販売業者４０４が受信する許可応答メッセージ４２４が取引の承認を含む場合（図１のステップ１１８）、取引の完了を確認するために、口座名義人への領収書のページに基づいて、販売業者４０４がＨＴＭＬベースのページを提示する。このページは、顧客の問合せに利用する参照番号を含むのが好ましい。さらに、口座名義人には見えないが、完了した取引を確認するために、ユーザのソフトウェア４０２が読める隠れた取引識別フィールドを、領収書のページは提供している。このとき、商品を出荷し及び／又は、サービスを提供する（ステップ１２０）。従来の精算及び決済のいずれもが、発行者４０６と決済機関４０８間の支払いを精算し決済するのに利用できる（ステップ１２２）。
【０１０２】
図５は、本発明に関する安全な決済取引を行う別のシステムを示している。図４に示したシステムと同様に、図５に示すシステムは、ユーザのソフトウェア４０２と、販売業者４０４と、決済機関４０８と、支払い口座発行者４０６とを含んでいる。しかし、図５に示すシステムはまた、取得者５１４も含んでいる。取得者５１４は、一般的には販売業者４０４の口座の取得銀行である。発行者４０６から、ユーザのソフトウェア４０２、販売業者４０４、取得者５１４、決済機関４０８に至り発行者４０６に戻るループを巡るデータ中に、認証データ４１４は含まれる。そこでは、発行者が、認証データ４１４が不正に改ざんされていないかあるいは不法に変更されていないかを確認する。図４に示したシステムと同様に、図５に示すこのシステムは、図１に示した手順に従って動作する。しかし、図５に示すこのシステムにと関連して利用する支払い手順１０６は、以下更に詳しく述べるように、認証データ４１４と他のデータ／メッセージが巡るループ中の取得者５１４を含む。
【０１０３】
図３は、図５に示したシステムに利用する典型的な支払い手順１０６を示している。図示した手順１０６において、販売業者４０４からの商品及び／又はサービスの購入を行う口座名義人の身元を認証するための要求４１２を、ユーザのソフトウェア４０２がネットワーク部４２８を介して発行者４０６へ送信する（ステップ２０２）。認証のための要求４１２に応答して、発行者４０６は、ネットワーク部４２８を介して認証データ４１４を送信し、認証データ４１４をユーザのソフトウェア４０２が受信する（ステップ２０４）。ユーザのソフトウェア４０２は、隠れたデータ４１６中の認証データ４１４を含み（ステップ２０６）、販売業者４０４のウェブページ中の隠れたフィールドを満たすための隠れたデータ４１６を利用する（ステップ２０８）。図２に示す手順について述べたように、ユーザのソフトウェア４０２が、隠れたデータ４１６を販売業者４０４へネットワーク部４２６を介して送信する（ステップ２１０）。販売業者４０４が許可要求メッセージ５０６を認証データ４１６から得て（ステップ２２２）、許可要求メッセージ５０６を取得者５１４へ別のネットワーク又はネットワーク部５０２を介して送信する（ステップ３０２）。取得者５１４は、許可要求メッセージ５０８を決済機関４０８へさらに別のネットワーク又はネットワーク部５０４を介して送信する（ステップ３０４）。取得者５１４から決済機関４０８へ送信した許可要求メッセージ５０８は、一般的には、販売業者４０４から取得者５１４へ送信したメッセージ５０６と同じか、このメッセージ５０６から得る。決済機関は、許可要求メッセージ４２０を発行者４０６へネットワーク又はネットワーク部４３２を介して送信する（ステップ３０６）。決済機関４０８から発行者４０６へ送信した許可要求メッセージ４２０は、販売業者４０４から取得者５１４へ送信したメッセージ５０６と同じか又はこのメッセージ５０６から得ることができ、及び／又は、取得者５１４から決済機関４０８へ送信したメッセージ５０８と同じか又はこのメッセージ５０８から得ることができる。許可応答メッセージ４２２を生成するために、発行者４０６は、決済機関４０８から受信した許可要求メッセージ４２０を処理する照合手順２１６を利用する。発行者４０６は、許可応答メッセージ４２２を決済機関４０８へネットワーク又はネットワーク部４３２を介して送信する（ステップ３０８）。決済機関４０８は、許可応答メッセージ５１０を取得者５１４へネットワーク又はネットワーク部５０４を介して送信する（ステップ３１０）。決済機関４０８から取得者５１４へ送信した許可応答メッセージ５１０は、一般的には、発行者４０６から決済機関４０８へ送信したメッセージ４２２と同じか、このメッセージ４２２から得る。
【０１０４】
状況によっては、図４で示したシステムについての説明のように、決済機関４０８は、発行者４０６の代わりに任意に、照合手順２１６を行える。このような代行処理は、決済機関４０８が行い、この場合、決済機関４０８は、許可応答メッセージ５１０を生成するための許可要求メッセージ５０８を処理する。
【０１０５】
いずれせよ、発行者４０６又は決済機関４０８が照合手順２１６を行ったか否かに関わらず、取得者５１４は、許可応答メッセージ５１２を販売業者４０４へネットワーク又はネットワーク部５０２を介して送信する（ステップ３１２）。取得者５１４から販売業者４０４へ送信した許可応答メッセージ５１２は、発行者４０６から決済機関４０８へ送信したメッセージ４２２と同じかこのメッセージ４２２から得ることができ、及び／又は、決済機関４０８から取得者５１４へ送信したメッセージ５１０と同じかこのメッセージ５１０から得ることができる。
【０１０６】
ユーザのソフトウェア４０２をＡＡＶベースの取引に利用するためにダウンロードする前に、口座名義人は発行者４０６を登録するのが好ましい。
【０１０７】
登録処理は、以下の有益な特徴を提供する。
・口座名義人を強力に認証する
・発行者４０６とともに口座名義人を登録する
・口座名義人のコンピュータへユーザのソフトウェア４０２をダウンロードする。
【０１０８】
ユーザのソフトウェア４０２を得るために、口座名義人はまず、発行者のオンラインバンキングのウェブサイトへアクセスする。この発行者のオンラインバンキングのウェブサイトは、発行者のウェブサーバ４４４からアクセスできる。口座名義人が既に発行者のオンラインバンキングサイトに登録されている場合、口座名義人は自分の既存のアクセス資格を利用してログする。この資格は、従来のオンラインバンキング口座名義人の認証方法のいずれを利用しても照合できる。
【０１０９】
発行者のオンラインバンキングサイトへのアクセスのために、口座名義人がまだ登録されていない場合、発行者４０６は、ユーザのソフトウェア４０２を得る前に口座名義人に登録を要求する。ユーザのソフトウェア４０２を使って行う次の取引の安全性を確保するために、登録前又は登録中に、発行者４０６が強力に口座名義人の身元を認証するのが好ましい。口座名義人の認証に成功すれば、登録処理は、口座名義人のプロファイルの開始へすすむ。口座名義人は、ユーザのソフトウェア４０２の登録継続の選択肢と共に提示される。登録の選択継続を選択すると、口座名義人のウェブブラウザをユーザのソフトウェア登録ページに案内する。このページは、ソフトウェア４０２へ登録可能な口座のリストと共に、口座名義人を提示し、口座名義人のプロファイルを発行者の照合プロセッサ４４２内に設けるために口座名義人からの様々な情報を要求する。この情報は、少なくとも以下を含むのが好ましい。
【０１１０】
・口座番号
・口座満期日
・口座ＣＶＣ２照合値
【０１１１】
以下の追加的情報は、プロファイルの開始中に収集できる。
・口座名義人名
・口座名義人請求先住所
・口座名義人出荷先住所
【０１１２】
状況によっては、発行者４０６は、発行者のオンラインバンキングサイトから利用できる口座名義人情報に基づいて、プロファイルの設置を自動的に行える。この処理のいくつか又は全てを自動化することによって、この情報の再入力を口座名義人に要求することを回避でき、その結果、口座名義人に便利な登録技術を提供できる。
【０１１３】
口座名義人から又は自動化したインターフェースから集めたデータを、口座名義人の登録要求の一部として、発行者の照合プロセッサ４４２へ送信する。照合プロセッサ４４２を発行者の外部にある機関が操作するシステムのために、この要求とその結果である応答は、機関間の送信中に、十分に保護すべきである。例えば、これらのメッセージを保護した私的ネットワーク結合を介して送信するか、インターネットのような公的ネットワークを介した送信前にメッセージを暗号化することによって、要求と応答の安全性を確保できる。発行者の照合プロセッサ４４２は登録要求を処理し、以下（ａ）か（ｂ）のどちらによって応答する。
【０１１４】
（ａ）登録が成功して終了したことを確認する、又は（ｂ）失敗した登録を、その失敗の理由を記載したメッセージに沿って示す。
【０１１５】
発行者は、オンライン上に登録した口座名義人が正しく認識・確認されたことを保証する強力な認証装置を選択すべきである。発行者が登録処理を実行する場合、認証目的に利用できる共有する秘密を認識する際には以下のガイドライン／選択を維持すべきである。
【０１１６】
・ただ１つよりは複数の情報を、共有する秘密に利用すべきである。例えば、口座名義人の母親の旧姓と彼（彼女）の社会保障番号の最後の４桁を、発行者の生成するパスワードと結合して利用できる。
【０１１７】
・共有する秘密は、確認可能なものにすべきである。例えば、口座名義人の母親の旧姓を使う場合、認証システムをこの情報を確認できるものにすべきである。
【０１１８】
・共有する秘密全ての認識には、複数の出所へのアクセスを必要とすべきである。１つの文書内及び／又は公的情報から完全に利用できる共有の秘密を使うのは避けるのが好ましい。例えば、発行者４０６は使用限度額と住所情報を利用することを利用すべきであり、この共有の秘密の両方とも、口座名義人の毎月の預金取引明細書上で利用できる。この明細書が盗み見られた場合、この共有の秘密は脅かされる。
【０１１９】
・発行者４０６は、状況によって、共有の秘密を判別するためのいくつかの情報を利用できる。例えば、以下の情報が利用できる。
【０１２０】
・明細とは別にした、メーラー中の口座名義人の請求先の住所へ送った銀行の生成したパスワード
・カードの署名パネル上のみ利用可能なＣＶＣ２
・口座名義人の社会保障番号の最後の４桁のような、確認可能な非公的番号。
・口座での使用限度額（毎月の預金取引明細書上で利用可能）
登録の成功後、口座名義人は、ユーザのソフトウェア４０２を彼（女）のアクセスデバイス〜代表的には、コンピュータ、ＰＤＡ、あるいは携帯電話など〜のダウンロードとインストールができる。口座名義人が販売業者の購入ページへ案内される際、ユーザのソフトウェア４０２を自動的に起動するために、口座名義人のアクセスデバイスは、装置の開始／代理手続の一部分としてユーザのソフトウェア４０２が操作されるように構成されるのが好ましい。
【０１２１】
起動と表示の際、購入取引中に口座名義人の身元を認証するために、ユーザのソフトウェア４０２は、口座名義人のアクセス資格を要求する。このアクセス資格は、一般的には発行者４０２が管理し、以下のいくつか又は全てを含むのが好ましい。
・ユーザｉｄ／パスワード
・スマートカード／ＰＩＮ
・解除したパスワードの残高の機密事項
・生物学的測定による照合
・電子証明書
・他の安全な発行者の承認した認証機構
【０１２２】
カード保持者の安全性を最大限に確保し、カード保持者の強力な認証を発行者に供与するために、認証は、各取引に対し発行者の照合プロセッサ４４２を通じて行うのが好ましい。
【０１２３】
状況によって、発行者４０６は、ＡＡＶ生成と口座名義人取引を追跡するデータの格納を選択できる。ＡＡＶ、カードの市、カードの州／国、ブランドを含むＡＡＶ生成の履歴の追跡は、議論による管理と料金返還処理の支援において、発行者４０６への助けとなりうる。更に、発行者４０６は、その認証結果の記録と取引における口座名義人の確認に基づいて、口座名義人への拒否をためすことができる。そのような拒否は、主として、各取引に関連したＡＡＶ、カードの市、カードの州／国、ブランドに基づいて行われる。発行者４０６は、売上げ履歴を口座名義人へのオンラインで利用可能とすることを選択でき、その結果、顧客サービスの問合せの数を減らすことができる。
【０１２４】
分割発送を含む購入の場合、販売業者４０４は、各発送に対する認証を要求し獲得するのが好ましい。分割発送による次の認証を行う場合、販売業者４０４は、初期認証ＡＡＶ８０２に含まれる制御バイト８０４を６進法表記の“８２”から６進法表記の“０２”へ変える。次の認証のための制御バイト８０４の変更に失敗すると、発行者４０６は認証を断ることになる。
【０１２５】
初期発行者の拒否の後、販売業者４０４は、認証要求の再送を希望してもよい。その場合、６進法表記の“８２”から“０２”まで変更した制御バイト８０４と共に、ＡＡＶ８０２を次の認証として送信する。
【０１２６】
いくつかのケースにおいては、所与の取引のために、元の要求中のＡＡＶと同じ値を有するＡＡＶを持った第二の認証要求を、販売業者４０４が生成してもよい。第二の認証要求は、ビットのような元の要求と一致している。例えば、要求は、異なるシステムの形跡のＩＤ番号を有することもある。一般的には、販売業者４０４は、以下の場合に第二の認証要求を生成してもよい。
・販売業者４０４が、所定のタイムアウト期間内の元の認証要求への応答を受信しない、又は、
・販売業者４０４は元の認証を完全に取消すが、後に元に戻すよう判別する。
【０１２７】
販売業者４０４は、制御バイト８０４の最上位ビットを読み取って、そのような認証要求を次の認証要求として取り扱うのが好ましい。これによって、そのような要求を発行者４０６が起こりうる再攻撃として誤って拒否する。
【０１２８】
図１から図７で説明した適正なソフトウェアの制御の下で動作する様々な標準的コンピュータブラットフォーム上で、図１から図７の方法を実行できることは、当業者によって明らかになるであろう。場合によっては、従来のパーソナルコンピュータ中の周辺カードのような、専用のコンピュータハードウェアが上記方法の操作上の効率を高めることができる。
【０１２９】
図９と図１０は、本発明の実用化に適した代表的なコンピュータハードウェアを示す。図９を参照すると、このコンピュータシステムは、処理部９１０と、ディスプレイ９２０、キーボード９３０と、モデムのような周辺通信デバイス９４０とを含む。このシステムは、またプリンタ９６０も含む。
【０１３０】
一般的には、磁気メディアのような（即ち、ディスケット）のようなコンピュータで読み取り可能なメディア及び／又は光学メディア（例えば、ＣＤ−ＲＯＭ又はＤＶＤ）へ読込み及び書込みができる、データとアプリケーションソフトウェアを格納する１つ以上のディスクドライブ９７０をこのコンピュータシステムは含む。図示はしていないが、デジタルポインタ（例えば、“マウス”）などの他の入力デバイスも含まれる。図９と図１０に示したコンピュータハードウェアは、図４と図５の示したユーザのソフトウェア４０２を動作するのに利用でき及び／又は販売業者４０４、販売業者のサーバ４４８、取得者５１４、支払い及び／又は決済機関４０８、照合プロセッサ４４６、発行者４０６、ＡＡＶ生成プロセッサ４４０、照合プロセッサ４４２、及び／又は発行者のサーバ４４４の機能を実行するのに利用できる。
【０１３１】
図１０は、更に処理部９１０を説明する機能的ブロック図である。処理部９１０は、通常、処理部１０１０と、制御ロジック１０２０と、メモリユニット１０３０とを備える。処理部９１０は、また、タイマ１０５０と、入出力ポート１０４０を備えることが好ましい。処理部９１０は、また、処理部で利用するマイクロプロセッサによっては、共通プロセッサ１０６０を含む。制御ロジック１０２０は、処理部１０１０と協力して、メモリユニット１０３０と入出力ポート１０４０間の通信を扱うのに必要な制御を行う。タイマ１０５０は、処理部１０１０と制御ロジック１０２０のためのタイミング参照信号を供給する。共通プロセッサ１０６０は、暗号アルゴリズムが必要とするような複合的な計算をリアルタイムに行う能力を拡張する。
【０１３２】
メモリユニット１０３０は、揮発性及び非揮発性のメモリやＲＯＭのような異なる種類のメモリを含む。例えば、図１０に示すように、メモリユニット１０３０は、ＲＯＭ１０３１と、ＥＥＰＲＯＭ１０３２と、ＲＡＭ１０３３とを含む。本発明の実用化に、異なるコンピュータプロセッサ、メモリ構成、データ構成等を利用でき、また本発明は、特定のプラットフォームに制限されない。例えば、処理部９１０は、図９と図１０にコンピュータシステムの一部として示されているが、処理部９１０及び／又はこの構成要素は、ＰＤＡ又は携帯電話組み入れることができる。
【０１３３】
本発明は具体的な実施例と連結して説明してきたが、添付した請求項に記載した発明の主旨や範囲を逸脱しない範囲内において様々な変形や代用が可能であることは、当業者にとっては明らかである。
【図面の簡単な説明】
【０１３４】
【図１】本発明の決済取引を行う典型的手順を説明するためのフロー図である。
【図２】図１で説明した手順で利用するひとつの典型的支払い手順を説明するためのフロー図である。
【図３】図１で説明した手順で利用する別の典型的支払い手順を説明するためのフロー図である。
【図４】本発明の決済取引を行うひとつの典型的システムを説明するためのブロック図である。
【図５】本発明の決済取引を行う別の典型的システムを説明するためのブロック図である。
【図６】図２と図３で示した手順で利用するひとつの典型的な許可要求メッセージ照合手順を説明するためのフロー図である。
【図７】図２と図３で示した手順で利用する別の典型的な許可要求メッセージ照合手順を説明するためのフロー図である。
【図８】本発明の典型的な口座名義人認証値（ＡＡＶ）を説明するためのブロック図である。
【図９】本発明の決済取引を行う典型的なコンピュータシステムを説明するための図である。
【図１０】図９で示したコンピュータシステムで利用する典型的処理部を説明する
【図１】
2004535619.tif 000006
【図２】
2004535619.tif 000007
【図３】
2004535619.tif 000008
【図４】
2004535619.tif 000009
【図５】
2004535619.tif 000010
【図６】
2004535619.tif 000011
【図７】
2004535619.tif 000012
【図８】
2004535619.tif 000013
【図９】
2004535619.tif 000014
【図１０】
2004535619.tif 000015
【国際公開パンフレット】
2004535619.tif 000016
2004535619.tif 000017
2004535619.tif 000018
2004535619.tif 000019
2004535619.tif 000020
2004535619.tif 000021
2004535619.tif 000022
2004535619.tif 000023
2004535619.tif 000024
2004535619.tif 000025
2004535619.tif 000026
2004535619.tif 000027
2004535619.tif 000028
2004535619.tif 000029
2004535619.tif 000030
2004535619.tif 000031
2004535619.tif 000032
2004535619.tif 000033
2004535619.tif 000034
2004535619.tif 000035
2004535619.tif 000036
2004535619.tif 000037
2004535619.tif 000038
2004535619.tif 000039
2004535619.tif 000040
2004535619.tif 000041
2004535619.tif 000042
2004535619.tif 000043
2004535619.tif 000044
2004535619.tif 000045
2004535619.tif 000046
2004535619.tif 000047
2004535619.tif 000048
2004535619.tif 000049
2004535619.tif 000050
2004535619.tif 000051
2004535619.tif 000052
2004535619.tif 000053
2004535619.tif 000054
2004535619.tif 000055
2004535619.tif 000056
2004535619.tif 000057
2004535619.tif 000058
2004535619.tif 000059
2004535619.tif 000060
2004535619.tif 000061
2004535619.tif 000062
2004535619.tif 000063
2004535619.tif 000064
2004535619.tif 000065
2004535619.tif 000066
2004535619.tif 000067
2004535619.tif 000068
2004535619.tif 000069
2004535619.tif 000070
2004535619.tif 000071
2004535619.tif 000072
2004535619.tif 000073
2004535619.tif 000074
2004535619.tif 000075
2004535619.tif 000076
2004535619.tif 000077
2004535619.tif 000078
2004535619.tif 000079
2004535619.tif 000080
2004535619.tif 000081
2004535619.tif 000082
2004535619.tif 000083
2004535619.tif 000084
2004535619.tif 000085
2004535619.tif 000086
2004535619.tif 000087
2004535619.tif 000088
2004535619.tif 000089
2004535619.tif 000090
2004535619.tif 000091
2004535619.tif 000092
2004535619.tif 000093
2004535619.tif 000094
2004535619.tif 000095
2004535619.tif 000096
2004535619.tif 000097
2004535619.tif 000098
2004535619.tif 000099
2004535619.tif 000100
2004535619.tif 000101
2004535619.tif 000102
2004535619.tif 000103
【国際公開パンフレット（コレクトバージョン）】
2004535619.tif 000104
2004535619.tif 000105
【国際調査報告】
2004535619.tif 000106
2004535619.tif 000107