オンライン認証サービスによる複数関係者の利益
【課題】
【解決手段】信頼機関が、オンライン取引中、要求者のために、口座保有者の同一性を検証する口座認証サービス。口座認証は、口座保有者からパスワードを要求するステップと、パスワードを検証するステップと、口座保有者の信頼性が検証されたか否かを要求者に通知するステップとを含む。口座認証サービスの代替実施形態は、顧客に関する情報が対価提供者と共有される提供対価構成要素を含む。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。関与する全ての関係者は、顧客情報を共有することで利益を享受できる。対価提供者は、例えば、販売者、出荷者、セキュリティ組織、政府機関にすることができる。取引識別子は、顧客、販売者間の特定の取引、及び顧客情報を特定する。
【解決手段】信頼機関が、オンライン取引中、要求者のために、口座保有者の同一性を検証する口座認証サービス。口座認証は、口座保有者からパスワードを要求するステップと、パスワードを検証するステップと、口座保有者の信頼性が検証されたか否かを要求者に通知するステップとを含む。口座認証サービスの代替実施形態は、顧客に関する情報が対価提供者と共有される提供対価構成要素を含む。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。関与する全ての関係者は、顧客情報を共有することで利益を享受できる。対価提供者は、例えば、販売者、出荷者、セキュリティ組織、政府機関にすることができる。取引識別子は、顧客、販売者間の特定の取引、及び顧客情報を特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン取引中に口座保有者の同一性を認証する事に関し、特に、認証処理に関連する情報を対価提供者が共有及び使用する手法に関する
【背景技術】
【０００２】
支払いカード（例えば、クレジットカード、デビットカード、又は価値格納カード）を使用した支払取引中には、カード保有者の口座の所有を検証し、不正使用等の様々な問題を回避することが重要である。支払者認証は、カード保有者の口座所有権を検証する処理である。カード保有者の口座所有権を認証する最も一般的な方法は、「カード有り」取引と呼ばれるものの間に、販売場所で日常的に発生する。カード有り取引には、販売者の代行者がカード保有者のカードを受け取り、口座の状態とクレジットラインの利用可能性とを検証するために支払カード端末に通し、カード裏面の署名が購入者の署名と一致するかを確認するためにチェックすることを含む。販売者がこの種の取引の特定の指針に従う場合、販売者は、割引額と手数料とを差し引いた、認証額の支払を保証される。ビザ インターナショナル サービス アソシエーション（Ｖｉｓａ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｅｒｖｉｃｅ Ａｓｓｏｃｉａｔｉｏｎ）等のサービスプロバイダ（又はサービス組織）は、こうした特定の指針を提供してよい。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
一方、オンライン、郵便、又は電話で発生するような「カード無し」取引には、販売者に対して保証されない支払が関与する。保証が提供されないのは、主に、こうして非対面取引では支払者が認証されず、「カード無し」取引に多数のリスクが伴うためである。こうしたリスクは、オンライン販売者に対する支払取引のチャージバック、販売者とカード保有者との両方に対する詐欺、銀行に対する例外項目処理費用の増加、一部の顧客にオンラインでの購入を回避させ得る、オンラインでの商品及びサービスの購入が安全確実ではないという認識の増加等の問題が含まれる。リスクの具体的な例には、商品及びサービスをオンラインで購入するための盗難口座情報の不正使用、不正なオンライン購入を行うためのカード口座番号の偽造、ネットワークトラフィックからの平文口座情報の抽出が含まれる。
【０００４】
電子商取引の予想される継続的な高成長を考えると、支払者を認証する方法を提供する事が重要である。オンライン取引の種類の幅広さを考えると、取引に商業的側面が存在するか否かに関係なく、関係者の同一性を認証する方法を提供することも重要である。これは、カード保有者、販売者、金融機関から、政府機関に至る全ての取引参加者に利益をもたらす。オンライン取引中に顧客を認証することで、詐欺、紛争、回収、及びチャージバックのレベルが減少し、結果として、こうした事象のそれぞれに関連するコストが減少する。顧客を認証することで、セキュリティの問題にも対処するため、オンライン活動の増加につながる。オンライン取引中に関係者を認証するために使用される従来のシステムは、使用するのが難しく、複雑な設計を有し、システム関与者に大きな事前投資が求められ、相互運用性が不足していることから、広範囲には採用されていない。特定の従来のシステムでは、追加として、販売者、カード保有者、発行者、及び取得者による証明書の作成、配布、及び使用が必要となる。こうした証明書の使用は、非常に負担となることが知られている。
【０００５】
上記を鑑みると、オンライン取引において顧客の同一性を認証する改良されたシステムを提供するために、継続的な努力がなされている。更に、こうした認証処理に関与する者に利用可能な情報を有効に使用するために、継続的な努力がなされている。
【課題を解決するための手段】
【０００６】
本発明は、オンライン取引中に利用者の同一性を認証する口座認証サービスを対象とする。認証サービスにより、信頼機関は、パスワード又はトークン等の様々な認証方法を使用して、要求する関係者（「要求者」）のために、口座保有者の同一性を検証できる。オンライン取引中における口座保有者の同一性認証は、口座保有者からパスワードを要求し、パスワードを検証し、口座保有者の信頼性が検証されたか否かを要求者に通知することを含む。口座認証サービスの代替実施形態は、顧客に関する情報が対価提供者と共有される提供対価構成要素を含む。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。関与する全ての関係者は、顧客情報を共有することで利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。顧客と販売者との間で特定の取引を識別する取引識別子と顧客情報とを使用することで、関係者のそれぞれは、取引と、顧客情報に関連する任意の合意とについて監査できる。
【０００７】
方法として、本発明の一実施形態は、少なくとも、利用者から同一性認証パスワードを受け取り、同一性認証パスワードを利用者の口座に事前指定したパスワードと比較することを含む。方法は、更に、利用者から受け取った同一性認証パスワードが口座に事前指定したパスワードと一致した場合に、利用者が口座の実際の所有者であることを要求者に通知すること含む。このようにして、信頼機関は、要求者のために、利用者が口座の実際の所有者であることを認証する。方法は、更に、利用者情報の対価提供者への送信を含む。一部の実施形態において、方法は、更に、利用者情報を一組の基準に照らして評価し、利用者情報が一組の基準を満たす場合に、利用者情報を対価提供者に送信することを含む。これにより、対価提供者は、所望の顧客情報を受け取ることができる。更に、要求者及び対価提供者のそれぞれは、利用者情報が対価提供者に送信される前に、条件として一組の権利及び義務に合意できる。追加として、取引識別子は、個別のオンライン取引と、関連づけられている顧客情報とを追跡するために使用できる。
【０００８】
本発明の一実施形態において、要求者は、販売者であり、対価提供者は、顧客情報を使用して、販売者から購入製品を出荷可能な運送会社である。顧客情報は、製品を顧客に出荷するか、どのように出荷するかについて、運送会社が判断するのを助ける。
【０００９】
本発明の別の実施形態において、要求者は、販売者であり、対価提供者は、顧客情報を使用して自分の商品又はサービスを顧客に売り込む後続販売者である。顧客情報は、顧客に連絡するか、どのように連絡するかについて、後続販売者が判断するのを助ける。
【００１０】
本発明の別の実施形態において、対価提供者は、顧客情報を使用してセキュリティ問題を評価できるセキュリティ組織である。顧客情報は、考えられるセキュリティ問題に対処するか、どのように対処するかについて、セキュリティ組織が判断するのを助ける。
【００１１】
本発明の上記及びその他の特徴及び利点について、以下の本発明の明細書と、本発明の原理を例示する添付図面とにおいて、更に詳細に提示する。
【発明を実施するための最良の形態】
【００１２】
本発明は、その更なる利点と共に、以下の説明を次の添付図面と併せて参照することにより、最も良く理解されよう。
【００１３】
本発明について、添付図面に例示した、いくつかの好適な実施形態を参照して、詳細に説明する。以下の説明では、本発明の完全な理解を提供するために、多数の具体的な詳細について述べる。しかしながら、こうした具体的な詳細の一部又は全部がなくとも、本発明を実施し得ることは、当業者には明白であろう。また、本発明を不必要に曖昧にしないために、周知の動作についての詳細な説明は省略する。
【００１４】
本説明は、図１において、本発明による一般的な口座認証システム及びプロトコルの概要から始める。口座認証システムは、関与する発行者、口座保有者、及び販売者へのサービスとして提供される。次に、図２乃至７において、オンライン支払取引に関連する口座認証システムについて説明する。オンライン支払取引の説明は、支払取引自体、システム設定、顧客登録、及び具体的なメッセージフローを対象とする。オンライン支払取引の説明は、非支払取引の説明に類似する。支払及び非支払取引は、両方とも、口座保有者の同一性の認証を含む。
【００１５】
次に図８において、提供対価構成要素を含む口座認証処理について説明する。価値は、最初に、顧客に関する情報を対価提供者と共有することで付加される。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。例えば、対価提供者は、焦点を絞った情報を顧客に提供可能であり、或いは、顧客に商品を発送可能である。関与する全ての関係者は、顧客情報を共有することで利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。顧客と販売者との間で特定の取引を識別する取引識別子と顧客情報とを使用することで、関係者のそれぞれは、取引と、顧客情報に関連する任意の合意について監査できる。本願では、こうした情報の共有を、広範な用途で、広範な関係者の利益のために、どのようして有利な形で使用できるかについて説明する。
【００１６】
口座認証システム
口座認証システムは、一方の関係者が特定の口座の所有者であると主張する別の関係者の同一性を物理的に検証できない取引中に、口座保有者の口座所有権を認証するように設計される。例えば、口座認証システムは、信頼機関が要求者のために利用者の同一性を認証する時に、様々な取引で使用できる。要求者とは、信頼機関に利用者の同一性の認証を要求する任意の個人又は団体である。信頼機関とは、利用者の同一性を認証可能で、利用者及び要求者が認証処理の実行を委ねる団体である。信頼機関は、利用者の同一性に関する誤り又は詐欺の際に、要求者の利益を保護することに合意できる。口座認証システムの重要な用途は、オンラインで、又は携帯電子機器を介して行われる、支払取引の分野である。
【００１７】
しかしながら、システムは、支払取引に加えて、多数の用途において有用となり得る本発明のシステムは、顧客の同一性の認証が必要となる様々な非支払状況において使用できる。例えば、非支払取引は、例えば、登録処理のため、インターネットｗｅｂサイトにアクセスしてオンラインフォームに記入する顧客を認証する等の取引を含む。非支払取引は、僅かな例として、小売銀行業、卸売銀行業、医療業、保険業、及び仲買業の多数の態様を含む。小売銀行業には、デビットカード、購入カード、及び価値格納カード等のカードで使用する口座番号が関与する。非支払取引には、ＩＤカード及びライセンス等のために、オンラインフォームを記入することが含まれる。例えば、米国自動車協会（ＡＡＡ）は、システムを使用して、顧客の一人の同一性を認証可能であり、電話カード会社は、システムを使用して、特定のカードのユーザの同一性を認証できる。
【００１８】
図1は、様々なタイプの口座認証用途に対して口座認証システムを実施するためのシステムアーキテクチャ１００の一実施形態を示している。システムアーキテクチャ１００は、三つの領域、即ち、信頼機関領域１０３、相互運用領域１０４、及び要求者領域１０５を含む。
【００１９】
信頼機関領域と要求者領域は、それぞれ信頼機関又は要求者により完全に又は少なくとも部分的に制御される構成要素を内部に有する機能範囲を定める。相互運用領域は、信頼機関、要求者、及びサービス組織等の他の関係者が利用し得る構成要素を内部に有する機能範囲を定める。
【００２０】
信頼機関領域１０３は、信頼機関により主に制御される構成要素を含む。信頼機関の例は、発行銀行として知られる、支払カードを消費者に発行する金融機関である。具体的には、発行者、又はカード発行者は、カード供給者から受け取った新たなカードを個人化し、こうしたカードを顧客に発行する。個人化は、カード供給者又は個人化局が実行してもよい。金融機関に加え、発行者は、電気通信ネットワークオペレータ、サービス団体、販売者その他の組織、又は発行者を代行する代理業者等、任意の適切な発行団体であってよい。要求者領域１０５は、要求者により主に制御される構成要素を含む。要求者は、口座保有者の同一性の認証を要求する任意の関係者にすることができる。例えば、要求者は、クレジットカード口座の所有者であると主張する人物の同一性の認証を希望する販売者にできる。取得者は、要求者を支払体系に加入させ、要求者の口座を管理する金融機関にできる。取得者は、更に、オンライン販売者からの情報を電気通信ネットワークへ送る。別の実施形態において、販売者は、情報を直接、電気通信ネットワークへ送る。
【００２１】
相互運用領域１０４は、インターネットでサポート可能であり、信頼機関と要求者との両方に使用される構成要素を含む。
【００２２】
信頼機関領域１０３は、発行者口座保有者システム１１０と、加入サーバ１１２と、アクセス制御サーバ（ＡＣＳ）１１４と、口座保有者ファイル１１８とを含む。システムが使用される特定の使用分野に応じて、信頼機関領域１０３には追加構成要素が含まれる。例えば、以下の支払取引では、支払取引に関して口座保有者の同一性を認証する目的で、それぞれの領域に追加構成要素が存在する。
【００２３】
加入サーバ１１２は、口座保有者が回答し、信頼機関が検証する一連の質問をｗｅｂインタフェース経由で提供することにより、口座保有者の口座認証システムへの加入を管理するコンピュータである。図１に示したように、信頼機関は、加入サーバ１１２を運用する。しかしながら、Ｖｉｓａ等のサービス組織は、信頼機関にかわって加入サーバ１１２を運用できる。信頼機関は、口座保有者の同一性の妥当性確認を支援するために、加入処理中に外部の団体が提供するｗｅｂ対応の対話式「同一性認証サービス」を使用できる。
【００２４】
ＡＣＳ１１４は、口座認証システムが提供する口座認証サービスに登録された口座保有者のデータベースを有するコンピュータである。ＡＣＳ１１４は、各口座保有者の口座及びパスワード情報を含む。口座認証処理中、ＡＣＳ１１４は、認証要求者にデジタル署名入り受取者を提供し、口座認証システムへのアクセスを制御し、口座保有者のサービスへの参加の妥当性を確認する。カード発行者、或いはＶｉｓａ等のサービス組織は、信頼機関のためにＡＣＳ１１４を運用できる。口座認証サービスでは、何らかの追加口座保有者ソフトウェアを使用する必要はないが、随意的な口座保有者ソフトウェア及びハードウェアを配置してもよい。追加口座保有者ソフトウェアは、デジタル証明書、集積回路カード（チップカード）、及びチップカードリーダ等の追加的な認証手法をサポートできる。本発明において、証明書を必要とする唯一のシステム参加者は、発行金融機関である。
【００２５】
口座保有者ファイル１１８は、口座認証システムへの加入に成功した口座保有者に関する情報を格納するために、信頼機関が管理するデータベースである。発行者口座保有者システム１１０（又は信頼機関の口座保有者システム）は、信頼機関により制御され、口座保有者に関する情報を含む。こうした情報は、口座情報、口座保有者が利用するサービス等に関連する。発行者口座保有者システム１１０内の情報の一部は、口座保有者の口座認証サービスへの加入において使用できる。
【００２６】
要求者領域１０５の要求者１８０は、通常、口座保有者の認証を希望する。関係者１８０は、認証プロトコルを円滑にする要求プラグインソフトウェア１８２を管理する。要求プラグインソフトウェア１８２は、第三の又は要求者のｗｅｂサイトに統合されるソフトウェアモジュールである。プラグインソフトウェアモジュール１８２は、口座認証システムと、要求者の処理ソフトウェア、例えば、販売者の支払処理ソフトウェアとの間のインタフェースを提供する。
【００２７】
相互運用領域１０４は、ディレクトリサーバ１２８を含み、インターネットによりサポートされ、信頼機関と要求者との両方に使用される構成要素を含む。ディレクトリサーバ１２８は、要求者からの認証要求を、ＡＣＳ１１４等の特定のＡＣＳへ送る。ディレクトリサーバ１２８は、カード体系管理者、或いはＶｉｓａ等のサービス組織により運用される。相互運用領域１０４は、インターネット以外のネットワークでもサポートできる。
【００２８】
支払取引用の口座認証システム
次に、支払取引の分野において口座保有者を認証するためのシステムアーキテクチャについて説明する。支払用途の認証処理は非支払用途に類似するため、本節において説明する多数の一般的概念は、様々な使用分野へ応用できることに留意されたい。
【００２９】
支払取引における認証システム及びプロトコルの使用例について以下に説明する。認証システムは、口座保有者がオンラインで買い物し、品目を「ショッピングカート」に追加し、オンライン販売者のチェックアウトページへ進み、オンライン販売者のチェクアウトフォームを記入する状況において有用となる。認証処理は、消費者が自分の希望する製品又はサービスの購入を決定した後、例えば、消費者が「購入」ボタンをクリックした後で行われる可能性がある。認証処理は、諸費者の支払取引における他の様々な時期に開始される可能性がある。認証処理は、支払ネットワークのいくつかのポイントに組み込まれたソフトウェアを利用することで、消費者にとって、殆どがトランスペアレントモードで実行される。システムは、認証サービスにより、口座保有者と口座保有者の金融機関との参加の妥当性確認を行う。その後、ウィンドウが作成され、ウィンドウの中で、口座保有者からの事前登録パスワードを要求することで、消費者は、自分の同一性を確認できる。消費者の同一性が確認された場合、支払情報と、消費者の認証の通知とが販売者へ返信される。その後、従来行われるように、販売者により支払取引が処理される。例えば、販売者は、注文確認メッセージを口座保有者のブラウザに送信してよい。
【００３０】
図２は、支払取引における認証サービスをサポートするシステムアーキテクチャ２００の一実施形態を模式的に示している。図１の一般的なシステムアーキテクチャ１００と同様に、アーキテクチャ２００は、三つの領域、即ち、発行者領域１０２、相互運用領域１０４、及び取得者領域１０６に分割される。図２の発行者領域１０２及び取得者領域１０６は、それぞれ図１の信頼機関領域１０３及び要求者領域１０５に類似する。
【００３１】
発行者領域１０２は、加入サイト１０８と、発行者口座保有者システム１１０と、口座保有者クライアントデバイス１２２と、加入サーバ１１２と、アクセス制御サーバ（ＡＣＳ）１１４と、発行者又は要求者同一性認証構成要素１１６と、口座保有者ファイル１１８とを含む。随意的に、発行者領域１０２は、承認口座保有者１２０の発行者ファイルを含むことができる。口座保有者は、利用者を示す別の用語であり、これは特定の同一性を有するものとして口座保有者が自らを提示するためである。加入サーバ１１２は、口座保有者が回答し、信頼機関が検証する一連の質問をｗｅｂインタフェース経由で提供することにより、口座保有者の口座認証システムへの加入を管理するコンピュータである。加入サーバ１１２は、インターネット支払ゲートウェイサービス１２４にインターネットを介して接続され、インターネット支払ゲートウェイサービス１２４は、次に電気通信ネットワーク１２６、例えば、ビザネット（ＶｉｓａＮｅｔ）に接続される。インターネット支払ゲートウェイサービス１２４により、加入サーバ１１２は、電気通信ネットワーク１２６と通信できる。支払ゲートウェイサービス１２４を介した接続により、加入サーバ１１２は、発行者の認証システム１２７に問い合わせを行い、加入中の口座保有者が有効なカード口座を有するかを判断できる。加入サイト１０８は、口座認証システムが提供する口座認証サービスに参加するために口座保有者が登録可能なインターネットｗｅｂサイトである。
【００３２】
口座保有者クライアントデバイス１２２は、口座保有者が口座認証システムに参加するために使用する。具体的には、口座保有者クライアントデバイス１２２は、パーソナルコンピュータ、携帯電話、携帯情報端末、又はインタラクティブケーブルテレビ等、インターネットにアクセス可能な任意の機器にできる。一部の実施形態において、口座保有者クライアントデバイス１２２は、インターネットに接続できないが、しかしながら、インターネットに基づかないメッセージを処理可能な特殊なノードを介して、クライアントデバイス１２２からの入力及び出力メッセージが送られるため、こうしたデバイスも口座保有者により使用可能である。例えば、音声及び／又はテキストメッセージに基づくメッセージを送受信する携帯電話はインターネットに接続できないが、しかしながら、メッセージを異なる方法で送ることにより、口座認証システムで使用できる。ショートメッセージサービス（ＳＭＳ）は、一般的に使用されるメッセージングシステムの例である。音声自動応答（ＩＶＲ）ユニットは、音声チャネルを介した自動交換に使用できる。こうしたメッセージルーティングの仕組みについては、インターネット対応デバイスに関する以下の節において更に詳細に説明する。
【００３３】
発行者口座保有者システム１１０は、口座保有者に関する情報を含む発行者制御システムである。このシステムの情報は、口座情報、口座保有者が利用するサービス等に関連する情報を含む。発行者口座保有者システム内の情報の一部は、口座保有者を口座認証システムへ加入させる処理において使用できる。
【００３４】
発行者又は要求者同一性認証データベース１１６は、発行者又は要求者が口座保有者に関するファイル上に既に有している情報を含む。データベース１１６は、口座保有者を加入させるプロセスにおいて、口座保有者の同一性を検証するために、発行者により使用される。例えば、口座認証システムが提供するサービスへの登録に口座保有者が成功するためには、口座保有者登録処理中に口座保有者が入力した情報は、認証データベース１１６のファイル上に既に存在する情報と一致するべきである。エクィファクス（Ｅｑｕｉｆａｘ）のような会社を第三者にすることができる。
【００３５】
相互運用領域１０４は、ディレクトリサーバ１２８と、認証履歴サーバ１３０と、受取マネージャ１３１とを含む。ディレクトリサーバ１２８は、要求者からの認証要求を特定のＡＣＳへ送る。ディレクトリサーバ１２８は、Ｖｉｓａ等のサービス組織により運用される。認証履歴サーバ１３０及び受取マネージャ１３１は、署名入り受取書（例えば、以下に説明する支払要求応答メッセージのコピー）を認証済み支払取引毎に格納する。認証履歴サーバ１３０は、どの取引が認証されたかを検証する情報を含み、紛争解決処理中に追加情報を提供する。認証履歴サーバ１３０及び受取マネージャ１３１は、サービス組織が運用する。発行者、取得者、又は販売者も、デジタル署名入り受取書のコピーを保持できる。
【００３６】
取得者領域１０６は、販売者１３２と、妥当性確認サーバ１３６とを含む。ＭＰＩ１３４は、販売者１３２の場所に常駐する。ＭＰＩ１３４は、販売者の電子商取引ｗｅｂサイトに統合されるソフトウェアモジュールである。ＭＰＩ１３４は、口座認証システムと、販売者の支払処理システムとの間のインタフェースを提供する。
【００３７】
ＭＰＩ１３４は、図１の要求プラグインソフトウェアモジュール１８２と同じソフトウェアモジュールであることに留意されたい。「販売者」という記述子は、ＭＰＩ１３４に対して、プラグインソフトウェアモジュールを利用している要求関係者の種類を示すために使用している。しかしながら、本明細書全体で説明されるプラグインソフトウェアモジュールは、プラグインソフトウェアモジュール１３４を説明するために使用される形容詞にかかわらず、基本的には同じ形で機能すると理解されたい。本明細書全体での用語の使用を簡略化するため、「販売者」という形容詞は、プラグインソフトウェアモジュールを説明するために使用される。しかしながら、これは、販売者である要求関係者による使用のみに適したものとして、プラグインソフトウェアモジュール１３４を限定するものではない。更に、ＭＰＩは、販売者プラグインソフトウェアモジュールの頭文字として使用される。
【００３８】
妥当性確認サーバ１３６は、支払取引中に口座認証システムが販売者に返送する受取書に署名するために使用されたカード発行者のデジタル署名を検証する。代替実施形態において、妥当性確認サーバ１３６の機能は、ＭＰＩ１３４に含めてよいため、別個の妥当性確認サーバ１３６の必要性は除去される。妥当性確認サーバ１３６は、販売者、取得者、又はサービス組織が運用する。
【００３９】
一部の実施形態において、口座認証システムは、電子ワレット等の他の口座保有者アプリケーションとの相互運用が可能であり、サービスは、電子商取引マークアップ言語（ＥＣＭＬソフトウェア）に適合して運用できる。口座認証システムは、更に、紛争解決手順を実行する能力を提供する。例えば、販売者は、紛争の解決及びチャージバックの目的で、口座保有者の認証の証拠を提供するのに十分な情報を保持できる。
【００４０】
設定及び登録の説明
次に、支払及び非支払取引の両方のための口座認証システムの設定について更に詳細に説明する。最初に、口座認証システムを使用できるように様々なシステム参加者を設定するのに必要な手順について説明する。次に、口座認証システムに登録するための口座保有者の処理について説明する。こうした段階を説明した後、支払取引の実際の認証についての説明を提供する。
【００４１】
口座認証システムの設定は、システム内の全参加者のための設定手順を含む。設定手順は、一般に、支払及び非支払取引の両方の認証で同じである。こうした参加者には、販売者又は他の認証要求者といった団体と、金融機関又は他の信頼機関と、口座保有者とが含まれる。
【００４２】
口座認証システムにサインアップしたオンライン販売者等の要求者は、図１のプラグインソフトウェアモジュール１８２及び図２のモジュール１３４のようなプラグインソフトウェアモジュールを受け取る。プラグインソフトウェアモジュールは、要求者が使用するコンピューティングプラットフォーム及びサーバソフトウェアに特有のものとするべきである。口座認証システムに参加する金融機関等の要求者は、カスタマイズした加入サイトテンプレートに組み込むべきサービスロゴ及びマーケティングデザインを提供する。取得銀行である第三者は、更に、サービス組織認証局（ＣＡ）ルート証明書と、クライアント認証用のサービス組織認証局ＳＳＬ証明書と、統合のサポートとを販売者に提供するべきである。
【００４３】
信頼機関は、口座認証システムを使用するための設定を可能とするために、信頼機関領域において指定された、全ての口座認証システムハードウェア及びソフトウェアのコピーを入手及びインストールするべきである。発行金融機関等の信頼機関は、更に、口座保有者同一性検証処理において使用されるべき同一性認証ポリシーと参加銀行識別番号（ＢＩＮ）情報とを口座認証システムに提供する。随意的に、発行者は、口座保有者ファイル１１８への先行ロードのために、口座保有者認証情報を口座認証システムに提供できる。先行ロードは、大量の口座保有者のサポートを容易にする。例えば、信頼機関が口座保有者の全部又は大部分を口座認証サービスで有効にしたい場合、信頼機関は、個人識別番号（ＰＩＮ番号）を全ての口座保有者に送ることができる。その後、ＰＩＮ番号は、先行ロード済みパスワードにアクセスするために、各口座保有者が使用できる。この方法では、各口座保有者は正式な加入処理を通過する必要がないため、加入処理が迅速化される。口座保有者が先行ロード済みパスワードを初めて使用した後、口座所有者は、新たな覚えやすいパスワードを指定するオプションを有する。
【００４４】
口座保有者認証情報は、企業ＩＤ、国コード、カード口座番号、カード有効期限、口座保有者名、「参加ＢＩＮ」データにおいて指定された発行者固有認証データ（例えば、母親の旧姓）といった情報と、請求先住所、発送先住所、社会保障番号、電話番号、勘定残高、取引履歴、及び運転免許証番号等、その他の情報とを含む。信頼機関は、更に、カード口座ポートフォリオに対する口座番号の範囲と、ＡＣＳのＩＰアドレス（ＵＲＬ）とをディレクトリサーバへ提供するべきである。口座認証システムの支払での応用に関して、サービスは、口座保有者の登録が可能な、銀行ブランドのｗｅｂサイトを介して提供できる。
【００４５】
図３は、一実施形態による、口座保有者が口座認証システムに登録する処理を示している。ステップ１に図示したように、口座保有者は、信頼機関、例えば、発行金融機関が維持する加入サーバインターネットｗｅｂサイトを訪れる。口座保有者は、自分の口座番号を登録することで、口座認証システムに登録する。例えば、支払取引により、口座保有者は、自分のクレジットカード、チェックカード、又はデビットカードの口座番号を登録できる。非支払取引に関して、口座保有者は、保険又は仲買会社で保有する口座番号を登録できる。口座保有者は、一枚以上のカードを登録できる
【００４６】
ステップ２において、口座保有者は、主要口座番号（ＰＡＮ）、名前、及びカード有効期限といった情報を入力する。この時点で、口座保有者は、追加情報を入力することもできる。例えば、住所、電子メールアドレス、買い物客ＩＤ、口座検証値、口座保有者固有パスワード、及び発行者固有認証情報を更に入力できる。この情報は、図４に示したページ３００のような加入ｗｅｂサイトのページに入力できる。
【００４７】
要求された情報を口座保有者が加入サイト１０８に入力した後、口座認証システムは、信頼機関が相互運用領域１０４のディレクトリサーバ１２８に登録したカード範囲内に口座保有者のＰＡＮが存在することを検証する。口座保有者の同一性は、様々な方法を使用して検証できる。第一に、先程述べたように、口座保有者の同一性は、要求者認証データベース、或いは信頼機関自身の認証データベースにより検証できる。追加として、検証は、信頼機関が提供する承認口座保有者１２０のファイルを使用し、状態チェック認証を信頼機関に送信し、応答を、金融機関が提供する先行ロード済み情報と比較することで実行できる。
【００４８】
ＰＡＮが加入カード範囲に含まれない場合、加入は拒否され、加入処理は終了する。支払取引において、ＰＡＮが加入カード範囲に含まれる場合、一ドル（又は他の任意の名目金額）の認証を、ＶｉｓａＮｅｔ等のサービス組織支払ネットワークを介して発行金融機関に提出する。一ドル取引の認証により、発行者は、カード口座状態を検証し、住所検証サービスを使用して住所を検証し、口座保有者検証値２（ＣＶＶ２）を検証できる。ＣＶＶ２は、支払カード裏面の署名欄に印刷された三桁の数字である。非支払取引では、ＰＡＮが加入カード範囲に含まれる場合、一ドル取引は必要ない。
【００４９】
ステップ３において、口座保有者は、口座保有者の同一性を対話式のリアルタイムオンラインセッションで検証するために、追加認証情報を求められる。一部の実施形態において、口座保有者は、認証取引中に口座保有者を認証するのに使用されるパスワードと「ヒントの質問及び回答」のペアとの入力を要求される。
【００５０】
ステップ４において、口座保有者の同一性が検証され、適切な応答が返送されると、認証メッセージが発行金融機関に送信される。次に、ステップ５において、加入サーバ１１２は、口座保有者情報をＡＣＳ１１４に渡し、口座保有者ファイル１１８内の記録を設定する。口座保有者ファイル１１８は、金融機関ＢＩＮ番号、口座番号、有効期限、姓名、運転免許証番号、請求先住所、社会保障番号、口座保有者のパスワード、口座保有者のパスワードの質問、口座保有者のパスワードの回答、口座保有者の電子メールアドレス、要求者の同一性スコア、その他の情報を格納できる。
【００５１】
一部の実施形態において、登録処理中、口座保有者には、個人保証メッセージ（ＰＡＭ）と呼ばれる語句の入力を求めることができる。ＰＡＭは、認証処理中に、信頼機関が口座保有者に後で提示する。信頼機関のみが口座保有者の指定ＰＡＭを知っているため、口座保有者に対して、口座認証システムで使用されるダイアログウィンドウが信頼機関から供給されたことを保証できる。ＰＡＭの例は、「空は青い」である。
【００５２】
口座保有者は、認証システムを使用するために、新しいクライアントソフトウェア又はデバイスを必要としないことに留意されたい。好適な実施形態において、口座保有者登録処理では、口座保有者と加入サーバとの間でインターネットを介して送信されるデータを保護するために、ＳＳＬチャネル暗号化等のセキュリティプロトコルを利用する。
【００５３】
更に、登録又は加入処理中、各信頼機関は、独自の「利用規約」及び／又は「データプライバシーポリシー」を表示できる。各信頼機関は、登録処理を完了するために、登録中の口座保有者に規約及びポリシーの承諾又は拒否のいずれかを求める能力を有する。各口座保有者が承諾した「利用規約」及び／又は「データプライバシーポリシー」のバージョン番号は、信頼機関が保存するべきである。
支払取引の説明
【００５４】
全ての参加者を設定し、口座保有者が登録した後、口座認証が実行される。図５は、口座保有者がインターネットに接続されたコンピュータを使用する、中心的な口座認証システムを使用した認証支払取引を説明している。図５のステップ１において、口座保有者は、インターネット上の販売者の電子商取引サイトを訪れる。支払取引では、口座保有者が保持する最も一般的なタイプの口座は何らかのクレジット、デビット、又はチェックカード口座であるため、口座保有者は、カード保有者と呼ぶこともできる。口座保有者が購入を希望する製品又はサービスを選択した後、口座保有者は、チェックアウト処理を開始し、チェックアウトフォームを記入し、その後、「購入」ボタンをクリックする。
【００５５】
「購入」ボタンを選択した後、図５のステップ２に図示したように、ＭＰＩが始動され、検証処理を実行して、口座保有者の固有口座が口座認証システムに登録されているかを判断する。ＭＰＩは、口座保有者が口座認証システムに登録されているかを様々な方法で判断できる。例えば、口座保有者に関連するディレクタサーバ及びＡＣＳをチェックする二段階処理と、ＡＣＳのみをチェックする処理と、ディレクトリサーバに保持されているものと同じ情報を含むキャッシュメモリを販売者がチェック可能な方法とを使用できる。
【００５６】
二段階処理について説明する。この説明では、図２を参照する。第一のステップにおいて、ＭＰＩは、カード口座番号を識別し、ディレクタサーバ１２８に問い合わせを行って、口座番号が口座認証システムの参加者である発行銀行に関連する番号の範囲内にあることを検証する。口座番号がディレクトリサーバ１２８で定義された口座番号範囲内に存在しない場合、発行者は登録されておらず、したがって口座保有者も登録されていない。この場合、口座番号が登録されていないことを販売者に通知し、ＭＰＩ１３４は、取引の制御を販売者の店頭ソフトウェアへ戻す。この時点で、販売者の店頭ソフトウェアは、通常通りに取引を進めること、口座保有者に対する更なるサービスを拒否すること、或いは、代替の支払方法で継続することが可能となる。
【００５７】
一方、口座番号がディレクトリサーバ１２８に存在する口座番号の範囲内にあると判断された場合、検証処理の第二のステップが開始される。検証処理の第二のステップは、口座番号が加入しているかを判断するためにディレクトリ１２８が口座番号をＡＣＳへ送信した時に開始される。カードが加入していない場合、加入処理は終了される。カードが加入していることをＡＣＳが示した場合、ＡＣＳは、ディレクトリサーバを介して、ＵＲＬインターネットアドレスをＭＰＩへ返送する。次に、ＭＰＩは、口座保有者クライアントデバイス及びその常駐ブラウザを介して、ＡＣＳを呼び出す。ここでも、口座認証システムに多数のＡＣＳが存在可能であることに留意されたい。
【００５８】
口座保有者が口座認証システムに登録されているかをチェックする第二の方法では、ＭＰＩ１３４が、最初にディレクトリサーバ１２８に問い合わせることなく、直接ＡＣＳ１１４に問い合わせる。第三の方法では、上記の通り、販売者は、ディレクトリサーバ１２８に保持されているものと同じ情報を含むキャッシュメモリを有する。これにより、販売者は、少なくとも予備的なチェックを実行できる。
【００５９】
二台以上の物理的ディレクトリサーバが口座認証システムに存在可能であることに留意されたい。しかしながら、論理的ディレクトリサーバが一台のみ存在することが好ましい。言い換えると、全てのディレクトリサーバは、同じ情報を含むという点において一致するべきである。
【００６０】
口座保有者が口座認証システムの参加者である場合、ＡＣＳ１１４は、口座保有者に対して銀行ブランドのウィンドウを表示する。銀行ブランドのウィンドウは、基本的な支払取引情報を含み、口座保有者に認証パスワード又はトークンを求める。口座保有者に認証パスワードを求める例示的なウィンドウ５００については図６を参照されたい。口座保有者は、自分の認証パスワードを入力し、ＡＣＳ１１４は、認証パスワードを検証する。ウィンドウ５００のサイズ及びレイアウトは、口座保有者が使用するデバイスのパラメータに応じて変化する。現在、一般的であるように、口座保有者は、認証パスワードの正確な入力を特定の回数だけ試行できる。口座保有者が認証パスワードを正確に入力できない場合には、口座保有者の登録処理中に設定されたヒント質問により、口座保有者に指示できる。好ましくは、口座保有者は、ヒント質問に対して正しい回答を入力する機会を一度与えられる。
【００６１】
正しい認証パスワード又はトークンが即座に入力された場合、或いは口座保有者がヒント質問に対して正しい応答を提供した場合、支払認証は継続する。次に、ＡＣＳは、発行者の署名キー又はサービスプロバイダのキーを使用した受取へのデジタル署名へ進む。この受取書は、販売者名、カード口座番号、支払額、及び支払日を含む。一部の実施形態において、受取書は、支払認証応答（ＰＡＲｅｓ）メッセージのコピー、或いはＰＡＲｅｓメッセージからコピーされた情報フィールドの少なくとも一部を有するメッセージである。認証履歴サーバ１３０は、取引データとして、販売者名、販売者ＵＲＬ、カード口座番号、有効期限、支払額、支払日、発行者の支払署名、及び口座保有者の認証検証値を格納する。ＡＣＳは、口座保有者のブラウザを介して、口座保有者をＭＰＩへリダイレクトする。この時点で、ＡＣＳは、販売者に対して、デジタル署名済み受取書と、口座保有者が認証された否かについての決定とを渡す。妥当性確認サーバ１３６は、取得者領域１０６において、支払受取書の署名に使用されたデジタル署名を検証するために、ＭＰＩ１３４に使用される。デジタル署名の検証後、口座保有者は、「認証済み」と見なされる。一部の実施形態において、取引完了後、口座保有者は、更に、自分のカード口座を再登録し、将来のオンライン購入で使用する新しいパスワードを作成する能力を有する。
【００６２】
ステップ３において口座保有者が認証された後、ステップ４では、特定の口座保有者の口座を許可する処理を開始する。許可とは、口座保有者が十分な信用を有し、特定の購入について良好な状態にあることを検証する処理を示す。対照的に、認証とは、口座保有者の同一性を検証する処理を示す。ステップ４において、販売者は、ＭＰＩを使用して、許可メッセージをＶｉｓａＮｅｔ等の支払ネットワークへ送信する。支払ネットワークは、次に、許可メッセージと電子商取引インジケータ（ＥＣＩ）とを、発行金融機関へ転送する。許可メッセージは、この技術で一般に知られているものと同様である。許可メッセージは、特定の口座が良好な状態にあり、支払取引の要求購入額に対して十分なクレジットラインを有することを発行金融機関が販売者に対して検証できるように、発行者へ送信される。ＥＣＩは、インターネットを介して取引が完了したことを示し、メッセージセキュリティ（即ち、心配のないチャネル暗号化（ＳＳＬ））のレベルと使用された認証とを示す。
【００６３】
代替の実施形態において、販売者は、追加情報を許可メッセージと共に提供できる。例えば、更に送信できる情報は、口座保有者が認証に成功したかを示すフラグと、口座情報と、デジタル署名と、口座保有者検証値２と、取引識別子と、チップカードＥｕｒｏｐａｙ、Ｍａｓｔｅｒｃａｒｄ、及びＶｉｓａ（ＥＭＶ）暗号文で認証されたオフラインＰＩＮと、販売者に保証された支払を提供するのに必要なフィールドとである。発行金融機関の許可取引処理が完了した後、支払取引の制御は、支払ネットワークを介して、販売者の店頭ソフトウェアへ戻される。次に、発行者は、支払ネットワークを介して、許可応答を販売者へ返送する。図５のステップ５において、発行金融機関は、取引を許可又は拒絶する。一部の実施形態において、許可メッセージは、バッチ処理を行って、後の時点でまとめて送信できる。認証情報は、バッチ許可メッセージにも含まれる。
【００６４】
取引識別子は、口座保有者を認証したＡＣＳにより作成され、一定の支払カードと、そのカードからの特定の支払取引とに固有の値である。発行者は、後に紛争が生じた時等、様々な目的で、取引識別子を使用して認証済み支払取引を一意に識別する。取引識別子は、特定のオンライン取引に関連するもの等、記録を一意に識別するのに適した多数のデータ形態を取ることが可能である。支払取引等、いくつかの実施の一つにおいて、取引識別子は、カード認証検証値（ＣＡＶＶ）である。以下の説明において、取引識別子はＣＡＶＶと呼ばれる場合があるが、しかしながら、様々な種類の処理識別子も利用できることに留意されたい。
【００６５】
アクセス制御サーバ（ＡＣＳ）１１４は、他の様々な機能が可能である。例えば、ＡＣＳは、登録口座をデータベースから無効化できる。口座は、口座保有者又は発行者が、手動で無効化できる。ＡＣＳ１１４は、口座保有者が交換用カードを受取時に、簡略化された更新登録処理を提供できる。ＡＣＳ１１４は、固有のアクセス制御情報を備えた、同じ登録口座の多数のユーザをサポートできる。支払取引又は口座更新のために、ユーザにＡＣＳ１１４への接続を提供する時、ＡＣＳ１１４は、パスフレーズ、デジタル署名、オンラインＰＩＮ番号、及び／又はチップカードＥＭＶ暗号文のオフラインＰＩＮ番号の一つ以上の機構を介して、登録口座の許可口座保有者として、ユーザの妥当性を確認できる。
【００６６】
販売者１３２は、販売者がファイル上に口座保有者の口座情報を有する既存のシステムとの相互運用を行い、既存の販売者許可及び結成システムとの相互運用を行い、多数の販売者にサービスを提供する第三者をサポートし、販売者及び取得者間の様々な支払インタフェースをサポートし、電子商取引インジケータ（ＥＣＩ）の値を設定する時に、取得者から支払ネットワーク許可メッセージに対する強制的な影響を最小化することができる。
【００６７】
取引を販売者からＡＣＳへ送る一方法は、口座保有者の口座番号に基づいてサーバのアドレスを提供するディレクトリを有することである。こうした方法において、情報を送る要求は、認証された販売者からのみ受け付けられる。販売者からのアクティビティが、正常なアクティビティを上回る場合、口座認証システムは、アクセスが有効でなくなったことを示す取得者を有する販売者に対して、アクセスを拒否できる。これは、販売者の詐欺があり得るとみなされた場合に該当する。口座認証システムには販売者認証を配備可能だが、配備は必須ではない。販売者認証は、販売者の詐欺を最小化するのに役立つ。
【００６８】
図７は、一実施形態による、消費者がインターネットに接続されたコンピュータを使用する、中心的な口座認証システムを使用した支払取引中に送信される、具体的なメッセージを示している。図７のメッセージは、図２に示した支払システムアーキテクチャに重ねている。メッセージと、それぞれのメッセージ内のデータフィールドとには、具体的な名称が記載されているが、こうした名称は認証プロトコルの性能に影響しないことを理解されたい。したがって、以下に説明するメッセージ及びデータフィールドには様々な名称を割り当て可能である。更に、本発明の代替実施形態において、図７において説明した具体的なメッセージは、変更又は省略が可能であり、及び／又は、認証プロセスの全体的な目標に影響を与えることなく、追加メッセージを追加できる。機能の追加及び通信の合理化といった様々な目的で、様々なメッセージを変更、追加、又は省略できる。更に、本明細書全体で説明するプロセスのメッセージフローは、代替実施形態において、上記のような利用で変更可能である。
【００６９】
上記のように、支払取引は、口座保有者がブラウザを介して販売者のｗｅｂサイトを訪問し、購入する品目を選択した時に開始される。販売者の支払システムは、口座保有者に支払情報の入力を求める。一般に、支払情報の入力は、安全な環境で、例えば、ＳＳＬ暗号化プロトコルを使用して行われるべきである。口座保有者が取引を確定させる準備が出来たことを示した時、販売者の支払システムは、ＭＰＩ１３４を呼び出す。次に、線１ａにより示したように、ＭＰＩ１３４は、口座保有者のＰＡＮを含み得るＡＣＳの特定のＵＲＬについてディレクトリサーバ１２８をチェックし、口座保有者がサービスに加入していることを検証する。代替として、ＭＰＩ１３４は、この情報を含む自らのキャッシュメモリをチェックする。ＭＰＩ１３４は、更にＡＣＳ１１４をチェックし、口座保有者のＰＡＮが口座認証システムに登録されていることを検証する。ＭＰＩ１３４が自分のキャッシュをチェックできる場合、ＭＰＩ１３４は、ディレクトリ１２８の内容をローカルキャッシュにコピーする能力を有するべきである。この能力を使用する場合、販売者は、口座が加入範囲の一部であるかをキャッシュから即座に判断できる。販売者がこの機能を実施する場合、キャッシュの内容は、少なくとも２４時間毎に期限切れとなり、更新されるべきである。キャッシュは、ＭＰＩ１３４がロードされた時、及びその後一定時間毎に要求されるべきである。
【００７０】
ＭＰＩ１３４は、口座保有者のＰＡＮを使用して検証加入要求（ＶＥＲｅｑ）をフォーマットすることで、ＰＡＮを検索する。既に確立されていない場合、ＭＰＩ１３４は、ディレクトリサーバ１２８又はＡＣＳ１１４との安全な接続を確立し、これらに対して自らを認証する。ＭＰＩ１３４は、様々な位置で、口座保有者のＰＡＮに対応するカード範囲エントリを検索する。
【００７１】
ＭＰＩ１３４が検索を実行した後、ＶＥＲｅｑメッセージは、線１ｂに示したように直接的に、或いは、線１ｂに示したように最初にディレクトリサーバを通過した後、ＡＣＳ１１４へ送信される。ＶＥＲｅｑメッセージがディレクトリサーバ１２８を介してＡＣＳ１１４へ送信された後、ディレクトリサーバ１２８は、ＶＥＲｅｑメッセージに含まれる口座保有者のＰＡＮに対応するレコードを検索する。一致が不成功である場合、ディレクトリサーバ１２８は、ＵＲＬ値（群）無しで検証加入応答（ＶＥＲｅｓ）メッセージをフォーマットし、ＰＡＮ加入のステータス又はＶＥＲｅｓステータスの値を「Ｎ」に設定する。ＶＥＲｅｓメッセージは、その後、ＭＰＩに戻される。一方、一致に成功した場合、既に確立されていない場合、ディレクトリサーバ１２８は、ＡＣＳのＵＲＬとの安全な接続を確立し、これに対して自らを認証する。その後、ＶＥＲｅｑメッセージは、ＡＣＳのＵＲＬに転送される。そのＵＲＬが利用できない場合、ＭＰＩは、（可能な場合）次のＡＣＳのＵＲＬ値に進み、最大五個のＡＣＳのＵＲＬの検索を可能にするべきである。当然ながら、試行されるＵＲＬの数は可変である。全ての試行で不成功となった場合、ＶＥＲｅｓメッセージは、口座認証システムを使用して支払取引が処理できないことを販売者に対して示すために、ＶＥＲｅｓステータスが「Ｎ」に設定された状態で、ＭＰＩに戻される。
【００７２】
ＶＥＲｅｑメッセージがＡＣＳ１１４に受け取られた後、ＡＣＳは、ＶＥＲｅｑメッセージから口座保有者のＰＡＮを受け付け、口座保有者ファイル１１８に照らして検証する。一致が成功した場合、ＡＣＳは、ＰＡＮ加入のステータスを「Ｙ」に設定し、ＡＣＳ１１４が内部的にＰＡＮに関連付けるシングルユースのプロキシＰＡＮを作成し、ＵＲＬフィールド（群）をＶＥＲｅｑメッセージ内に配置する。一致が不成功である場合、ＡＣＳは、ＰＡＮ加入のステータスを「Ｎ」に設定する。したがって、線２ａに示したように、ＡＣＳは、ディレクトリサーバ１２８を介して、ＶＥＲｅｓメッセージをＭＰＩへ戻される。ＶＥＲｅｑメッセージがＡＣＳへ直接送信される場合、ＶＥＲｅｓメッセージは、線２ｂに示したように、ＭＰＩへ直接返送される。
【００７３】
ディレクトリサーバ１２８のデータをＭＰＩ１３４でキャッシュすることにより、ＣＲＲｅｑ及びＣＲＲｅｓメッセージペアの利用を容易にできる。ＣＲＲｅｑメッセージは、ＭＰＩのキャッシュを更新するために、ＭＰＩからディレクトリサーバへ送信され、関与するカード範囲のリストを要求する。ＣＲＲｅｓメッセージは、関与する範囲を含む応答である。
【００７４】
一部の実施形態において、口座認証システムは、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージペアを使用して分散認証能力を口座保有者のクライアントデバイスが有するかを確認する。ＭＰＩは、クエリであるＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑメッセージを口座保有者クライアントデバイス１２２に対してフォーマット及び送信し、分散口座認証用口座保有者モジュールが常駐しているかを判断する。ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑメッセージの送信は、線３により図７に図示している。任意の分散認証オプションがＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージにより戻された場合、ＭＰＩは、口座保有者クライアントソフトウェアと直接通信し、認証ステップを実行する。ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージの送信は、線４により図７に図示している。追加として、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージを使用することで、以下に説明するＶＥＲｅｑ及びＶＥＲｅｓメッセージを除去してよい。口座保有者クライアントソフトウェアは、発行者のＡＣＳのＵＲＬをソフトウェアに埋め込んで配置できる。ＭＰＩは、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージを最初に完了させる。口座保有者クライアントソフトウェアが検出された場合、ＶＥＲｅｑ及びＶＥＲｅｓメッセージを実施することなく、ＰＡＲｅｑメッセージをＡＣＳ又は口座保有者クライアントソフトウェアに送信できる。
【００７５】
ＶＥＲｅｓステータスが「Ｙ」に等しくない値を有する場合、販売者には、口座認証システムを使用して支払取引を処理できないことが通知される。しかしながら、ＶＥＲｅｓステータスが「Ｙ」の値を有する場合、ＭＰＩ１３４は、支払認証要求メッセージ（ＰＡＲｅｑ）をフォーマットする。ＭＰＩ１３４は、線５に示したように、口座保有者クライアントデバイスブラウザを介して、ＰＡＲｅｑメッセージを発行者のＡＣＳサーバへ送信する。
【００７６】
ＭＰＩがＰＡＲｅｑメッセージを発行者のＡＣＳに渡した後、ＡＣＳは、口座保有者に対してウィンドウを表示する。ウィンドウは、支払認証応答（ＰＡＲｅｑ）メッセージに含まれる支払の詳細を、発行者のロゴ、サービス組織のマーク又はブランドロゴ、販売者名、販売者の場所（ＵＲＬ）、合計購入金額及び通貨、購入日、カード番号、分割／定期循環支払条件、注文に関する説明又は説明へのリンク、販売の特殊条件又はこの情報へのリンク、個人保証メッセージ、口座保有者のパスワード又は他の任意の種類の認証トークンの要求といった他の項目に加えて表示する。
【００７７】
ＡＣＳは、口座保有者に適切なパスワードの入力を求める。ＡＣＳは、口座保有者の入力を受け付け、口座保有者ファイル１１８に照らして検証する。口座認証システムでは、例えば、正しいパスワードを入力する試行の失敗を一定回数（例えば、三回）認める。当然ながら、認める試行回数は変更できる。最終の試行失敗後、口座認証システムは、ヒント質問を表示してよい。口座保有者は、正しいヒント質問の応答を入力する必要がある。その後、口座保有者に関連するヒント質問が表示される。口座保有者は、正しい応答の入力を少なくとも一度試行できる。口座保有者が不正確な応答を提供した場合、口座認証システムを使用した取引を完了できないことを販売者に通知できる。口座保有者が正しい応答を提供した場合、パスワードが一致したかのように取引を処理するべきである。口座番号に対して二つ以上のエントリが存在する場合には、様々な口座保有者名がドロップダウンウィンドウに表示されることに留意されたい。その後、口座保有者は、自分の名前を選択できる。
【００７８】
パスワードの一致後、ＡＣＳは、ＰＡＲｅｓメッセージを作成してデジタル署名する。ＡＣＳは、更に、ＳａｖｅＲｅｃｅｉｐｔメッセージを生成し、線７で示したように、認証履歴サーバ１３０及び受取マネージャ１３１に送信する。線７ａで示したように、ＳａｖｅＲｅｃｅｉｐｔメッセージは、発行者がリアルタイムで支払許可要求と支払者認証取引とを照合できるように、認証履歴サーバ１３０から発行者許可及び清算システム１３８へ渡してもよい。ＳａｖｅＲｅｃｅｉｐｔメッセージを発行者許可及び清算システム１３８へ送信することで、発行者は、認証要求が認証済みの購入に関するものかを同時に判断できる。次に、ＡＣＳは、線６で示したように、署名済みのＰＡＲｅｓメッセージをＭＰＩへ再びリダイレクトする。
【００７９】
署名済みＰＡＲｅｓメッセージをＭＰＩ１３４へ返送した後、ＭＰＩ１３４を再始動させる。認証ステータスが「Ｙ」である場合、ＭＰＩ１３４は、ＰＡＲｅｓメッセージを妥当性確認サーバ１３６へ送信する。妥当性確認サーバの機能がＭＰＩ１３４によって提供される場合、ＭＰＩ１３４は、ＰＡＲｅｓメッセージの署名の妥当性を確認し、署名妥当性確認の結果を戻す。署名の妥当性が確認できない場合、ＭＰＩ１３４は、口座認証システムを使用して取引を処理できないことを販売者に通知する。認証ステータスが「Ｎ」である場合、販売者は、口座保有者に追加情報を求めるプロンプトを送信するか、異なる支払カード又は支払い形態を使用することを口座保有者に要求するか、或いは非認証支払取引として支払取引を処理するべきである。
【００８０】
取得者領域１０６が妥当性確認サーバを含む場合、妥当性確認サーバ１３６は、ＰＡＲｅｓメッセージの署名の妥当性を確認する。妥当性確認サーバ１３６は、その後、署名妥当性確認の結果をＭＰＩ１３４へ戻す。署名の妥当性が確認できない場合、ＭＰＩは、口座認証システムを使用して取引を処理できないことを販売者に通知する。一方、署名の妥当性が確認された場合、販売者は、認証支払の許可を進める。ＰＡＲｅｓメッセージは、線６ａで示したように、販売者から取得者支払プロセッサ１４０に渡してもよい。ＰＡＲｅｓメッセージは、その後、取得者から電気通信ネットワーク１４２を介して、発行者へ渡してよい。したがって、支払者認証結果は、標準の支払許可プロセスの一部として、発行者が利用可能になる。
【００８１】
次に、様々な伝送チャネルに関連するセキュリティ問題について説明する。基本線として、全ての伝送チャネルは、好ましくは、１２８ビットＳＳＬを使用して暗号化される。口座保有者と販売者との間のチャネルは、二つのチャネルを含む。販売者は、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、口座保有者が支払情報を入力する時に使用される接続を確保するべきである。販売者は、更に、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、ＰＡＲｅｓメッセージを口座保有者からＭＰＩへ転送する時に使用される接続を確保するべきである。
【００８２】
口座保有者とＡＣＳとの間のチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、ＡＣＳによって暗号化されるべきである。このチャネルは二つの目的で使用される。第一に、ＰＡＲｅｑメッセージをＭＰＩからＡＣＳへ送信するためであり、第二に、署名済みＰＡＲｅｓメッセージをＡＣＳから口座保有者へ送信するためである。
【００８３】
口座保有者と加入サーバとの間のチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、加入サーバによって暗号化されるべきである。このチャネルは、口座保有者の加入情報を受け付けるのに使用される。
【００８４】
販売者とディレクトリサーバとの間、及びディレクトリサーバとＡＣＳサーバとの間のチャネルは、ＶＥＲｅｑ及びＶＥＲｅｓメッセージに含まれるＰＡＮデータと、ＶＥＲｅｓメッセージに含まれるＡＣＳのＵＲＬアドレスとを保護するために、サービス組織が発行したＳＳＬ暗号化証明書により確保するべきである。
【００８５】
ＡＣＳと口座保有者との間のチャネルは、口座保有者のパスワードに対するプロンプトと、口座保有者が入力したパスワードとを保護するために暗号化されるべきである。このチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書により保護されるべきである。
【００８６】
殆どの取引について、支払認証要求及び応答メッセージは、一部として、メッセージバージョン番号と、販売者識別子と、販売者国コードと、注文番号と、購入日と、購入額と、取引ステータスと、購入条件とを含むフィールドを含んでいる。更に、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージは、通常、一部として、メッセージバージョン番号、販売者名、注文番号、購入日、購入額、カード有効期限、取引ステイン等のフィールドを含む。こうしたメッセージは、ＸＭＬ（拡張マークアップ言語）形式にできる。
【００８７】
非購入認証取引において、支払認証要求、支払認証応答、及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージは、メッセージ拡張フィールドを含むことができる。この技術において周知であるように、メッセージ拡張フィールドは、拡張を添付するメッセージに関する追加要素を定義するデータフィールドである。こうした追加要素は、非支払取引を含む特定の取引を更に容易にするために使用できる。
【００８８】
提供対価構成要素による口座認証処理
図８は、対価提供の態様を含むオンライン口座認証に関連するシステムアーキテクチャの例と、一組のメッセージフローとを示す。対価提供の態様は、口座認証処理を介して数周した情報を対価提供者と共有することに関与する。こうした情報は、利用者に関係し、発行者又は信頼機関及び要求者が収集可能である。利用者情報は、利用者１２２の認証の根拠として供給されるため、高い完全性という価値を有する。利用者情報は、特定のオンライン取引を識別し、情報が本発明の認証処理に由来することを示す取引識別子によりマーク付けできる。対価提供情報は、一部の例として、出荷、後続販売、セキュリティチェック、及びワークフロー管理に関連する様々な目的で、対価提供者１９６が使用できる。関与する全関係者は、利用者情報を共有から利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。例えば、要求者と対価提供者とは、利用者情報の共有に基づく追加契約条項に合意できる。
【００８９】
次に、利用者情報を対価提供者１９６へ送信することを含む認証処理について、図８を参照して説明する。図８について、支払取引に基づいて説明する。この説明に続いて、図８を、非支払取引に基づくものとして更に説明する。図８は、図７のメッセージを簡略化した形態で表している。
【００９０】
図８の口座認証システムアーキテクチャは、発行者領域１０２と、相互運用領域１０４と、取得者領域１０６と、対価提供領域１０７とを含む。発行者領域１０２は、利用者１２２と、ＡＣＳ１１４と、発行者１９０とを含む。利用者１２２は、人間の利用者と、利用者クライアントデバイス、例えば、コンピュータ端末又はモバイルコンピューティングデバイスとを表す。発行者１９０は、利用者１２２に対して支払カードを発行可能なカード発行銀行を表す。相互運用領域１０４は、この例においてＶｉｓａによって制御されるディレクトリであるＶｉｓａディレクトリ１２８と、認証履歴サーバ１３０と、ＶｉｓａＮｅｔ１９４とを含む。取得者領域１０６は、要求者１３２と、ＭＰＩ１３４と、取得銀行１９２とを含む。要求者１３２は、様々な種類の関係者にできるが、しかしながら、要求者１３２は一般に販売者であるため、販売者という用語を要求者の代わりに使用できる。対価提供領域１０７は、対価提供者１９６と、価値付加制御サーバ１９８とを含む。
【００９１】
図８の支払取引は、番号１乃至１４の方向矢印により説明する。支払取引は、ステップ１において、利用者が販売者のｗｅｂサイトをブラウズし、購入を希望する品目をショッピングカートに追加し、購入を確定する時に開始される。この時点で、販売者１３２は、ＰＡＮ、有効期限、及び住所情報を含め、支払取引を続けるのに必要なデータを有している。
【００９２】
ステップ２において、ＭＰＩ１３４は、利用者の主要口座番号（該当する場合は、更にデバイス情報）をＶｉｓａディレクトリサーバ１２８へ送信し、利用者のＰＡＮが口座認証システムに加入しているかをチェックする。この処理は、販売者チェックアウト処理中、利用者からの最終の「購入」クリック確認後に発生する。「購入」クリックが行われた後、販売者のソフトウェアは、ＭＰＩ１３４を呼び出し、検証加入要求（ＶＥＲｅｑ）メッセージをフォーマットする。ＭＰＩ１３４は、現在、Ｖｉｓａディレクトリサーバ１２８との安全な接続を有しているかを判断する。安全な接続が確立されていない場合、ＭＰＩ１３４は、Ｖｉｓａディレクトリサーバ１２８とのＳＳＬ接続を確立する。販売者１３２がＳＳＬクライアント証明書を発行したことをＶｉｓａディレクトリサーバ構成が示す場合、Ｖｉｓａディレクトリサーバ１２８は、販売者１３２に対して、ＳＳＬセッションの確立中にＳＳＬクライアント証明書を提示することを求める。安全な接続が確立された後、ＭＰＩ１３４は、ＶＥＲｅｑメッセージをＶｉｓａディレクトリサーバ１２８へ送る。様々な実施形態において、様々な購入注文確認処理を使用して「購入」クリック確認を完了できることに留意されたい。
【００９３】
ＶＥＲｅｑメッセージは、認証処理中に送信される他の任意のメッセージと共に、オンライン認証処理が対価提供者との利用者情報の共有を伴うことを表すインジケータを含むことができる。
【００９４】
ステップ３において、関与するカード範囲内にＰＡＮが存在するとＶｉｓａディレクトリサーバ１２８が判断した場合、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳ１１４等の適切なＡＣＳへの問い合わせを行い、ＰＡＮについて認証（又は認証の試行の証明）が可能であるかを判断する。この処理は、Ｖｉｓａディレクトリサーバ１２８がＭＰＩ１３４からＶＥＲｅｑメッセージを受取した後で発生する。
【００９５】
関与するカード範囲内にＰＡＮが存在することをＶｉｓａディレクトリサーバ１２８が検証するために、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージデータの妥当性を確認し、特定の要件が満たされることを確定する。第一に、取得者ＢＩＮは、参加取得者を表すべきである。第二に、販売者ＩＤは、取得者ＢＩＮによって特定された取得者の参加販売者を表すべきである。第三に、取得者のＶｉｓａ領域で、口座認証サービスのために販売者のパスワードが必要となる場合、パスワードの値が受け取られているべきであり、パスワードは、取得者ＢＩＮと販売者ＩＤとの組み合わせに対して有効となるべきである。こうした要件のいずれかが満たされない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性と、無効要求メッセージとを含む検証加入応答（ＶＥＲｅｓ）をフォーマットする。このＶＥＲｅｓは、口座識別子、ＡＣＳのＵＲＬ、及び支払プロトコルのデータフィールドを含まないことに留意されたい。Ｖｉｓａディレクトリサーバ１２８がＶＥＲｅｓメッセージをＭＰＩ１３４へ返した後、支払取引は、様々な形で進む可能性がある。例えば、支払取引は完全に終了する可能性があり、支払取引は非認証取引として進む可能性があり、或いは、利用者は異なる口座番号の使用を試行できる。
【００９６】
Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージにおいて受け取った利用者ＰＡＮを含むカード範囲を指定するレコードを検索する。利用者ＰＡＮが見つからない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３４へ返送し、口座認証は、以下説明するように、再び停止可能点に達する。
【００９７】
利用者ＰＡＮがＶｉｓａディレクトリサーバ１２８において見つかった場合、Ｖｉｓａディレクトリサーバ１２８は、現在、適切なＡＣＳとの安全な接続を有しているかを判断する。安全な接続が確立されていない場合、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳとのＳＳＬ接続を確立する。Ｖｉｓａディレクトリサーバ１２８のＳＳＬクライアント証明書と、ＡＣＳのサーバ証明書とについては、ＳＳＬセッションの確立中に提示及び妥当性確認が行われるべきである。試行された第一のＵＲＬが利用できない場合、連続する各ＵＲＬ値が試行される（提供された場合）。Ｖｉｓａディレクトリサーバ１２８は、各ＡＣＳに対して随意的に構成可能な四つまでの代替ＵＲＬへの接続を試行できる。Ｖｉｓａディレクトリサーバ１２８がそれぞれの試行でＵＲＬに接続できない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含むが、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、又は無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３４へ返送し、口座認証処理は停止可能点に達する。
【００９８】
ＵＲＬとの接続に成功した後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージからパスワードフィールドを除去し、メッセージをＡＣＳのＵＲＬへ転送する。
【００９９】
ステップ４において、ＡＣＳ１１４は、ＰＡＮに関する認証が可能であるかを判断し、その後、Ｖｉｓａディレクトリサーバ１２８に対して判断を示す。この処理は、ＡＣＳがＶｉｓａディレクトリサーバ１２８を介してＶＥＲｅｑメッセージを受取後に発生する。ＡＣＳ１１４は、ＶＥＲｅｑの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。支払取引を認証できない時、代わりに認証の試行の証明を提供できる場合があることに留意されたい。ＡＣＳ１１４は、ＶＥＲｅｑメッセージからの利用者ＰＡＮを使用して、ＡＣＳ１１４内に位置する利用者データベースに問い合わせ、利用者が加入しているかを判断する。ＰＡＮが見つからない場合、ＡＣＳ１１４は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、ＡＣＳ１１４は、ＶＥＲｅｓメッセージをＶｉｓａディレクトリサーバ１２８へ送信する。
【０１００】
ステップ５において、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳ１１４の判断をＭＰＩ１３４へ転送する。Ｖｉｓａディレクトリサーバ１２８の観点では、この処理は、Ｖｉｓａディレクトリサーバ１２８がＶＥＲｅｑメッセージをＡＣＳのＵＲＬへ転送した後に発生する。ＡＣＳ１１４の観点では、この処理は、ＡＣＳ１１４がＶＥＲｅｓメッセージをＶｉｓａディレクトリサーバ１２８へ送信した後に発生する。
【０１０１】
Ｖｉｓａディレクトリサーバ１２８は、対応するＶＥＲｅｓ又はエラーを含むＶＥＲｅｓメッセージを読む。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージの構文の妥当性を確認し、妥当性確認に失敗した場合にＡＣＳ１１４へエラーを返す。ＡＣＳから受け取ったメッセージが構文的に正しい場合、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓ又はエラーをＭＰＩ１３４へ転送する。ＡＣＳから受け取ったしたメッセージが構文的に正しくない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求を含まないＶＥＲｅｓメッセージをフォーマットする。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３２へ返し、場合によっては口座認証処理を停止する。ＭＰＩ１３４の観点では、この処理は、ＭＰＩ１３４がＶＥＲｅｑメッセージをＶｉｓａディレクトリサーバ１２８へ送った直後に発生する。Ｖｉｓａディレクトリサーバ１２８の観点では、この処理は、ＶｉｓａディレクトリサーバがＶＥＲｅｓメッセージをＭＰＩへ転送した直後に発生する。ＭＰＩ１３４は、対応するＶＥＲｅｓ又はエラーを含む応答を読む。エラーメッセージが受け取られた場合、口座認証処理を停止となり得る。
【０１０２】
上記の様々な理由により口座認証が終了となり得るポイントにおいて、販売者は、チェックアウト処理から利用可能な情報を使用して、通常の支払許可を進めることができる。この場合、販売者の支払システムは、この文書の範囲から外れた非認証電子商取引処理として、取引を処理するべきである。電子商取引インジケータは、認証の結果及びチェックアウト処理の特性に対応する値に設定されるべきであることに留意されたい。チェックアウト処理中に利用者が選択した口座を使用して、販売者が認証取引を処理できない場合、販売者は、取引を中止するか、或いは代替口座を選択するオプションを顧客に与えることができる。代替口座が選択された場合には、認証処理を繰り返すことができる。
【０１０３】
代替実施形態では、Ｖｉｓａディレクトリサーバの内容を販売者１３２のローカルキャッシュメモリデバイスへコピーすることにより、各支払取引で利用者の口座認証システムへの参加を検証するためにＶｉｓディレクトリサーバに問い合わせる必要性（ステップ２乃至５）は回避できる。この機能を使用する場合、販売者１３２は、口座が加入範囲の一部であるかを、キャッシュから即座に決定できる。この販売者１３２のローカルキャッシュを使用する代替手法は、ＭＰＩ１３４がカード範囲要求（ＣＲＲｅｑ）メッセージをフォーマットし、Ｖｉｓａディレクトリサーバ１２８へ送信することで開始される。キャッシュのロードが今回初めて行われる場合（或いは、キャッシュが消去されており、再ロードする必要がある場合）、ＣＲＲｅｑにはシリアル番号要素が含まれておらず、その結果、Ｖｉｓａディレクトリサーバ１２８は、関与するカード範囲の全リストを返送する。その他の場合に、ＭＰＩ１３４は、直前に処理されたＣＲＲｅｓからのシリアル番号を含め、その結果、Ｖｉｓａディレクトリサーバは、以前のＣＲＲｅｓからの変更のみを返送する。シリアル番号は、Ｖｉｓａディレクトリサーバ１２８のカード範囲データベースの現在の状態を定義する値である。Ｖｉｓａディレクトリサーバ１２８は、ＭＰＩ１３４にシリアル番号を提供する。特定の番号は、それを返送した特定のＶｉｓａディレクトリサーバにとってのみ意味を有する。
【０１０４】
Ｖｉｓａディレクトリサーバ１２８は、ＣＲＲｅｑの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。Ｖｉｓａディレクトリサーバ１２８は、関与する範囲を含むカード範囲応答をフォーマットし、ＭＰＩ１３４へ送信する。Ｖｉｓａディレクトリサーバ１２８は、応答にシリアル番号を含める。ＭＰＩ１３４は、この値を保持し、翌日のＣＲＲｅｑメッセージに含めるべきである。ＭＰＩ１３４は、ＣＲＲｅｓの構文の妥当性を確認し、妥当性確認に失敗した場合、Ｖｉｓａディレクトリサーバ１２８にエラーを送信するべきである。ＭＰＩ１３４は、ローカルキャッシュを更新する。リストは、アクション要素が示す追加又は削除された範囲により、返送された順序で処理するべきである。ＣＲＲｅｓがシリアル番号についてエラー状態を示す場合、ＭＰＩはキャッシュを消去し、シリアル番号のないＣＲＲｅｑを提出するべきであることに留意されたい。
【０１０５】
利用者のＰＡＮについて認証が可能である時、ＭＰＩ１３４は、１２２の利用者クライアントデバイスを介して、支払者認証要求（ＰＡＲｅｑ）メッセージをＡＣＳ１１４へ送信する。ステップ６は、利用者クライアントデバイス１２２へ送信されたＰＡＲｅｑメッセージを表す。この処理は、ＭＰＩ１３４がＶｉｓａディレクトリサーバ１２８からＶＥＲｅｓメッセージを受取直後に発生する。ＭＰＩ１３４は、ＶＥＲｅｓの構文の妥当性を確認し、妥当性確認に失敗した場合、Ｖｉｓａディレクトリサーバにエラーを送信するべきである。ＭＰＩ１３４は、ＶＥＲｅｓにおいて受け取った口座識別子を含むＰＡＲｅｑメッセージをフォーマットする。
【０１０６】
この認証プロセスの実施形態は、販売者１３２と発行者１９０との間で利用者関連情報を共有することを含む。発行者１９０及び販売者１３２のそれぞれは、単一又は多数の取引において、利用者に関する広範な情報を収集できる。こうした情報は、特定の利用者の購買習慣に関する情報を含む可能性がある。こうした情報は、販売者１３２、発行者１９０、及び対価提供者１９６といった様々な関係者にとって有用となる可能性がある。こうした顧客情報は、ＰＡＲｅｑ及びＰＡＲｅｓメッセージ内にこうした情報を含めることで、認証処理中に、販売者１３２と発行者１９０との間で共有できる。したがって、ステップ６において、販売者１３２は、利用者１２２に関する情報をＰＡＲｅｑメッセージに含めることができる。
【０１０７】
ＭＰＩ１３４は、次のフィールドを含むフォームを構築する：ＰＡＲｅｑ、最終的な返答を送るべき販売者ＵＲＬであるＴｅｒｍＵｒｌ、及びＭＤ（「販売者データ」）フィールド。ＭＤフィールドは、販売者に返送するべき販売者状態データを含む。このフィールドは、販売者システムがセッション状態を扱う様々な方法に対応するために使用される。販売者システムが、何らかの更なる支援なしに、最終ポストを元のショッピングセッションに関連づけできる場合、ＭＤフィールドは空になり得る。販売者システムが一定のショッピングセッションに対する状態を維持しない場合、ＭＤは、販売者がセッションを継続するのに必要なあらゆるデータを運ぶ。このフィールドの内容は販売者の実施により変化するため、ＡＣＳは、内容に関する仮定を含まずに、フィールドを変化させずに維持するべきである。
【０１０８】
ＭＰＩ１３４は、利用者のブラウザにフォームをＡＣＳへポストさせることで、利用者のブラウザを介して、ＰＡＲｅｑをＶＥＲｅｓにおいて受け取られたＡＣＳのＵＲＬへ渡す。全ての接続は、利用者のブラウザに対応するためにＨＴＰＰＳとなる。
【０１０９】
ステップ７は、利用者クライアントデバイス１２２からＡＣＳ１１４へ送信されるＰＡＲｅｑメッセージを表す。この処理は、ＡＣＳ１１４がＭＰＩ１３４からＰＡＲｅｑを含むポストを受取後で発生する。以下の説明は、パスワードを使用して利用者認証が実行される場合に該当する。チップカード上のアプリケーションに依存するもの等、その他の方法も使用してよい。ＡＣＳ１１４は、ＰＡＲｅｑメッセージの妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。妥当性確認に失敗した場合、ＡＣＳ１１４は、「Ｎ」に設定した取引ステータスと無効要求とを有するＰＡＲｅｓメッセージをフォーマットする。
【０１１０】
ステップ８において、ＡＣＳは、ＰＡＮに適用可能な処理を使用して利用者を認証する。こうした処理は、発行者１９０と利用者１２２との間で事前に設定されたパスワード又はＰＩＮを要求すること、及び利用者にデータ課題を提示すること等の手法を一部として含む。データ課題は、例えば、利用者又は利用者クライアントデバイス１２２の同一性を認証する特定のデータ応答を利用者クライアントデバイス１２２が提供するのをＡＣＳ１１４が要求することを含む可能性がある。一シナリオにおいて、ＡＣＳ１１４は、利用者１２２を認証する特定の暗号文をクライアント利用者デバイスが作成することを要求できる。代替として、ＡＣＳ１１４は、認証の試行の証明を生成できる。その後、ＡＣＳ１１４は、適切な値でＰＡＲｅｓメッセージをフォーマットし、応答メッセージにデジタル署名を付与する。ＡＣＳ１１４は、パスワード、データ応答、又は暗号文を、ＡＣＳ内に位置する利用者データベースに照らして検証する。ＡＣＳ１１４は、更に、各オンライン取引に対して、ＣＡＶＶ等の取引識別子を生成する。取引識別子は、特定のオンライン取引に関連づけされると共に、販売者１３２と発行者１９０との間で共有される顧客情報にも関連づけされる。
【０１１１】
ステップ９において、ＡＣＳ１１４は、ＰＡＲｅｓメッセージを利用者クライアントデバイス１２２へ返送する。発行者１９０が維持する利用者１２２関連情報と、取引識別子とは、ＰＡＲｅｓメッセージに含めることで販売者へ送信できる。
【０１１２】
ＡＣＳ１１４は、ＰＡＲｅｓ及びＭＤフィールドを含むフォームを構築する。ＡＣＳ１１４は、利用者のブラウザにフォームをＭＰＩへポストさせることで、利用者のブラウザを介して、署名済みＰＡＲｅｓを販売者のＵＲＬ（ＭＰＩからのポスト内のＴｅｒｍＵｒｌ）へ渡す。この処理において、ポップアップが閉じられ、制御は、販売者のブラウザウィンドウへ戻される。
【０１１３】
この時点で、ＡＣＳ１１４は、更に、選択されたデータを認証履歴サーバ１３０へ送信できる。例えば、ＡＣＳ１１４は、認証履歴サーバ１３０へ送信される支払者認証取引（ＰＡＴｒａｎｓＲｅｑ）メッセージをフォーマットする。
【０１１４】
認証処理中に保持及び／又は転送される利用者情報は、販売者１３２及び発行者１９０のそれぞれが格納できる。各関係者は、顧客情報の一部、或いは一組の顧客情報全体を格納できる。代替として、顧客情報の一部又は全ては、認証サーバ１３０に格納できる。
【０１１５】
ステップ１０において、利用者クライアントデバイスは、ＰＡＲｅｓメッセージをＭＰＩ１３４へ送る。
【０１１６】
ステップ１１において、ＭＰＩ１３４は、ＡＣＳ１１４がＰＡＲｅｓメッセージに付与したデジタル署名の妥当性を確認する。デジタル署名の妥当性確認は、ＡＣＳ１１４自体が実行可能であり、或いは、ＰＡＲｅｓメッセージを別個の妥当性確認サーバへ渡すことで実行できる。妥当性確認処理では、Ｖｉｓａルート証明書を使用して、ＰＡＲｅｓ署名の妥当性を確認する。別個の妥当性確認サーバを使用して実施する場合、ＭＰＩ１３４は、ＰＡＲｅｓを妥当性処理へ送信し、妥当性処理では、Ｖｉｓａルート証明書を使用して、ＰＡＲｅｓ上の署名の妥当性を確認し、署名の妥当性確認の結果をＭＰＩへ返す。
【０１１７】
ステップ１２において、販売者１３２は、取得者１９２との許可の交換を進める。
【０１１８】
ステップ１３において、販売者１３２は、特定の基準一式を使用して、所有している顧客情報を評価する。一組の顧客情報が基準を満たす場合、顧客情報と取引識別子とを対価提供者１９６へ送信する。基準は、対価提供者１９６が顧客情報の受取を希望するかを判断する様々な問題を中心として、様々に変更できる。こうした基準については、認証処理がどのように動作するかの更に詳細な例を通して、更に詳細に説明する。
【０１１９】
ステップ１４において、対価提供者１９６は、顧客情報と取引識別子とを、価値付加制御サーバ１９８等のデータベースに格納する。
【０１２０】
ステップ１５は、様々な目的で発生する可能性がある、価値付加制御サーバ１９８と認証履歴サーバ１３０との間を行き来する通信を表している。こうした目的には、例えば、販売者１３２と対価提供者１９６との間の取引を終結させることと、紛争の解決と、データマイニングとが含まれる。
【０１２１】
本説明の以下の節では、本発明の様々な価値付加実施形態の更なる詳細について説明する。
【０１２２】
対価提供者としての出荷会社
次に、図８に示した認証システム及びプロセスについて、対価提供者１９６が出荷会社（「出荷者」）であり、出荷者２００ａと呼ばれる場合の実施形態により説明する。この実施形態において、利用者１２２は、利用者の住居又は他の郵送先住所へ出荷する必要のある製品を販売会社１３２から購入する。出荷者１９６へ送信される利用者又は顧客情報により、出荷者１９６は、商品を利用者１２２へ出荷できる。上記のように、顧客情報は、認証処理に由来するため、高度な完全性と豊富さとを有する。したがって、情報の価値は、販売者１３２と対価提供者１９６とが互いに取引に参加するための基盤としての役割を果たす。取引の種類の範囲は、大きく変化する可能性がある。一例において、出荷者１９６は、出荷者１９６が販売者１３２及び利用者１２２にとって低いコストで製品を進んで出荷する程度まで、顧客情報の完全性及び豊富さに依存する。こうしたケースは、利用者１２２がパッケージの販売者への返送を決して要求していないことが顧客情報に記載されているために生じ得る。追加として、販売者１３２は、利用者１２２の返送要求に伴う出荷者の責任又はコストを快く免除するほどに、こうした顧客情報に依存できる。
【０１２３】
認証及び価値付加処理は、図８の番号付きステップにより説明した認証処理により開始される。ステップ６及び７において、販売者１３２は、維持している顧客情報を、発行者１９０へ送信されるＰＡＲｅｑメッセージに含めてよい。ステップ９及び１０において、発行者１９０は、発行者１９０が維持している顧客情報を、販売者１３２へ送信されるＰＡＲｅｓメッセージに含めてよい。発行者１９０は、更に、特定のオンライン取引及び顧客情報に関連する取引識別子を生成する。
【０１２４】
顧客情報は、例えば、１）名前、郵送先住所、電子メールアドレス、電話番号、及びＦＡＸ番号といった消費者連絡先情報と、２）全額支払いの回数及び滞納の回数といった顧客支払履歴と、３）好適な出荷方法、返品サービスを要求せずに行われた出荷回数、及び定時出荷の回数といった出荷履歴とにすることができる。顧客情報は、発行者１９０及び販売者１３２が収集可能な任意の種類の情報を含むことができる。
【０１２５】
更にステップ９において、顧客情報は、販売者１３２及び発行者１９０の一方又は両方に格納される。代替として、顧客情報は、認証履歴サーバ１３０等のデータベースに格納される。
【０１２６】
ステップ１３において、販売者１３２は、顧客情報を特定の基準により評価し、こうした情報を出荷者１９６へ送信するべきかを判断する。基準は、例えば、出荷者１９６がタスクを難なく完了可能であることを顧客情報が示す場合に、顧客情報が出荷者１９６へ送信されるように策定できる。基準は、顧客に関して利用可能な履歴情報を調査することで、特定の顧客への出荷のリスクを分析するのに役立つ。基準の例には、１）顧客は、販売者との購入取引を特定の回数を超えて行っているか？、２）出荷先住所は、特定の国、例えば、米国内か？、３）顧客は、以前に購入代金を滞納したことがあるか？、４）顧客は、以前に返品を要求したことがあるか？、５）顧客は、新規顧客か？、６）特定の金額以上の取引か？、７）出荷先住所は検証済みか？、又は８）配達先の国は、低リスク又は高リスクの国か？が含まれる。販売者１３２、出荷者１９６、又は両関係者が、基準を設定できる。
【０１２７】
顧客情報が販売者の基準を満たす場合、顧客情報と取引識別子とは、出荷者１９６へ送信される。発行者１９０が取引識別子を生成するため、出荷者１９６に対して、情報の正確さが保証される。顧客情報に依存して、出荷者１９６は、難なく、したがって過剰なコストなしで、出荷可能であることが一定のレベルで保証された状態で、製品を顧客１２２に出荷する。顧客情報が提供する、出荷者１９６に対する問題のない取引の保証により、販売者１３２と出荷者１９６とは、互いに対して特別の配慮を提供し得る。例えば、出荷者１９６は、販売者１３２及び顧客１２２にとって低いコストで製品を進んで出荷し得る。更に、販売者１３２は、出荷者１９６に代わって、出荷するリスクの一部を負うことが可能であり、或いは販売者１３２は、出荷者１９６に対して運送費を部分的に補償することに合意できる。
【０１２８】
ステップ１４において、出荷者１９６は、取引識別子と共に、顧客情報を価値付加制御サーバ１９８に格納する。出荷者１９６は、出荷ラベルに取引識別子を印刷した状態で、製品を顧客１２２へ出荷できる。
【０１２９】
ステップ１５は、様々な目的で、取引識別子を関連する顧客情報と共に検索することを含む。こうした目的には、販売者１３２と対価提供者１９６との間の取引を終結させること、紛争の解決、及び／又はデータマイニングが一部として含まれる。取引識別子は、特定の取引に対応するため、発行者１９０、販売者１３２、及び対価提供者１９６が各取引の情報を検証できるように、各取引の履歴を追跡するのに有用である。本発明により、販売者は、顧客が特定の購入を行っていないと主張する購入詐欺から、自らを更に保護することも可能となる。本発明により、出荷会社は、顧客が出荷を受け取っていないと偽って主張する出荷詐欺から、自らを更に保護することも可能となる。
【０１３０】
顧客情報は、「強制」又は「引き出し」の状況において、認証履歴サーバ（ＡＨＳ）１３０から検索できる。「強制」の状況は、事象の発生が予測されるため、受取者である対価提供者１９６に顧客情報を強制する状況である。「引き出し」の状況は、不規則に起こる事象の発生時のみ、受取者が顧客情報を引き出す状況である。例えば、ＡＨＳ１３０に格納された顧客情報及び取引識別子による検証を要する紛争が発生した時のみ、顧客情報を引き出すことができる。
【０１３１】
顧客情報及び取引識別子は、取引を終結させるためにＡＨＳ１３０から検索できる。こうした取引は、顧客情報の共有に基づいており、関係者のそれぞれが合意する追加条項を含む。様々な関係者が利益を享受可能な追加取引の基盤の役割を顧客情報が果たすことから、こうした取引は、価値付加取引と呼ばれる。例えば、価値付加取引の関係者は、追加的な事業機会を得ること、より競争力のある商品又はサービスコストを得ること、及び／又は、より有利な契約条項を得ることが可能となる。一部の取引において、出荷者１９６は、特定の条項にしたがって販売者１３２の製品を出荷することに合意する。こうした条項は、販売者１３２に請求される、より低い出荷コスト、及び／又は販売者１３２によるリスク及び責任の肩代わりを含むことができる。顧客情報及び取引識別子をチェックすることで、販売者１３２及び出荷者１９６は、出荷者が特定の出荷を行うことを検証できる。その後、例えば、販売者１３２は、出荷者１９６に割引運送料を支払う。取引を終結させるために顧客情報及び取引識別子を検索することは、こうした情報の検索が取引を終結させるための通常の処理である場合、強制取引となる。
【０１３２】
顧客情報及び取引識別子は、紛争解決の状況においても有用である。紛争は、販売者１３２、顧客１２２、及び出荷者１９６のいずれかの間で発生する可能性がある。紛争は、ＡＨＳ１３０からの情報により、取引に関する事実を提供することで解決できる。紛争が発生した時には、顧客情報及び取引識別子を、こうした情報が格納されている場所から「引き出す」。販売者と出荷者との間の紛争は、各関係者間の価値付加取引の履行に関連する可能性がある。例えば、出荷サービスの支払に関する食い違いが生じた時、販売者１３２は、こうした情報を使用して、合意の上、割引運送料で出荷者１９６が出荷を行ったことを証明できる。或いは、例えば、出荷を受け取っていない、或いは出荷中に商品が損傷したと顧客が苦情を言った場合、出荷者１９６は、こうした取引の責任を販売者１３２が負うことを証明できる。一部の事例においては、発行者１９０が責任を負う場合がある。
【０１３３】
顧客情報及び取引識別子は、販売者１３２、発行者１９０、及び出荷者１９６のそれぞれがデータマイニングの目的でも使用できる。こうした関係者のそれぞれは、その取引を介して、特定の顧客について、その顧客の特色及び傾向を判断するために分析可能な情報を入手できる。こうした特色及び傾向は、販売者１３２、出荷者１９６、及び発行者１９０のそれぞれのマーケティングの目的で使用できる。販売者１３２は、顧客の特色及び傾向に関する情報を使用して、顧客に対する将来の販売及びマーケティング戦略を決定できる。出荷者１９６も、こうした情報をリスクの分析に使用して、例えば、問題に遭遇することなく顧客に製品を出荷できる確率を決定できる。発行者１９０は、こうした情報を使用して、将来、顧客に対して口座を発行することのリスクのレベルを決定可能であり、或いは、クレジットのレベルを引き上げるべきかを決定できる。
【０１３４】
追加として、任意の関係者は、情報を使用して、他の任意の関係者の特性を決定できる。例えば、出荷者は、特定の販売者と契約を結ぶことが賢い事業判断であるかを決定できる。こうした分析を行うために、顧客情報を分析して、販売者の詐欺履歴、チャージバック履歴、顧客の一般的な出荷相手国等を決定できる。こうした情報から、特定の業者との取引では、通常、出荷が容易であることが分かった場合、ある業者は、こうした業者と更に多くの仕事を行うことを判断できる。販売者は、こうしたデータを分析して、特定の出荷者により、出荷のニーズを満足させるべきかを決定できる。例えば、顧客データは、どの業者が配送成功率及び定時配送スコアを有するかを示すことができる。
【０１３５】
販売者１３２及び発行者１９０の一方又は両方が顧客情報を保持する実施形態において、顧客情報及び取引識別子は、対応する団体のそれぞれから検索できる。
【０１３６】
本発明の出荷の代替実施形態において、販売者１３２は、特定の取引の顧客データと取引識別子とのコピーを多数の出荷者へ送信できる。顧客データは認証処理に由来し、高い度合いの完全性を有するため、各出荷者１９６は、その取引のための出荷を実行することに興味を有し得る。各出荷者１９６が興味を有し得るのは、顧客情報の完全性が、取引に関する情報、例えば、出荷先住所の信頼性を保証するためである。更に重要なことに、顧客情報は販売者の基準を通過した後で各出荷者１９６へ送信されているため、各出荷者１９６では、出荷取引の問題に遭遇する確率が低いことが保証されている。代替方法において、出荷者１９６は、少なくとも、特定の取引に伴うリスクのレベルについて知識を得られる。更に、出荷者１９６は、販売者１３２又は発行者１９０が取引のリスクのコストを肩代わりすることに同意していることから、取引の製品を出荷することに興味を有し得る。こうした取引及び顧客に関する知識を有した状態で、出荷者１９６のそれぞれは、販売者１３２に出荷費用を入札できる。販売者１３２は、その後、一出荷者１９６を選択して製品を出荷できる。
【０１３７】
対価提供者としての後続販売者
図８に示した認証及び情報共有処理の代替実施形態において、対価提供者１９６は、後続販売者１９６である。この実施形態において、本発明は、後続販売者１９６について、更に一部のケースでは販売者１３２及び発行者１９０について、収入機会を増加させることができる。後続販売者１９６は、販売者１３２から顧客情報及び取引識別子を受け取り、こうした情報を使用して、自分の商品又はサービスを顧客１２２へ売り込む。後続販売者１９６は、任意の種類の商品又はサービスを提供できるが、販売者１３２が販売する商品又はサービスと何らかの関連性を有することが多い。顧客１２２が販売者１３２との取引の対象に関連する何かを購入する見込みが高くなり得ることから、販売者１３２からの顧客情報は、価値のあるものとなる。販売者１３２及び後続販売者１９６は、顧客情報に基づいて、互いに様々な契約を結ぶことができる。
【０１３８】
この処理も、図８の番号付きステップにより説明した認証処理により開始される。ステップ６、７、９、及び１０において、販売者１３２及び後続販売者１９６は、以前に説明したように情報をＰＡＲｅｑ及びＰＡＲｅｓメッセージに含めることで、顧客１２２に関する情報を共有する。更に、発行者１９０は、特定のオンライン取引及び顧客情報に関連する取引識別子を生成する。顧客情報及び取引識別子は、発行者１９０、販売者１３２のそれぞれにより格納されるか、或いは認証履歴サーバ１３０等の単一のデータベース内に格納される。
【０１３９】
ステップ１３において、販売者１３２は、顧客情報を評価して、顧客情報及び取引識別子を後続販売者１９６へ送信するべきかを判断する。こうした顧客情報は、例えば、顧客の平均出費額、顧客の最高出費額、顧客がいつ購入したか、顧客が誰から購入したか、顧客が何に出費したか、顧客の性別、及び顧客の人口統計学的情報に関連する。顧客の特性に関する分析範囲は極めて広いことを理解されたい。顧客情報が基準を通過した場合、ステップ１３において、情報は、後続販売者１９６へ送信される。
【０１４０】
顧客情報及び取引識別子を受け取ると、ステップ１４において、後続販売者１９６は、顧客情報及び取引識別子を、価値付加制御サーバ１９８等のデータベースに格納する。この時、後続販売者１９６は、顧客情報を利用して、特定の顧客に焦点を絞ったマーケティング戦略を実行できる。顧客情報により、後続販売者１９６は、様々な顧客向けにマーケティング戦略を調整する方法について知ることができる。例えば、特定の取引での顧客の出費額に関する情報から、後続販売者１９６には、顧客１２２が興味を有し得る商品又はサービスの価格水準が分かる。更に、販売者１３２が販売した商品又はサービスに関する情報から、後続販売者１９６には、顧客１２２が購入を希望し得る関連商品又はサービスの種類が分かる。例えば、顧客が販売者１３２からＣＤプレイヤを購入した場合、後続販売者１９６は、顧客１２２に特定のＣＤを販売できる。こうした取引は、「補完財」取引と呼ぶことができる。他の補完財には、例えば、コードレスドリル及び充電式電池、剃刀及び剃刀刃、芝刈り機及び肥料が含まれる。
【０１４１】
顧客情報の受取は、顧客情報により生じた後続販売者１９６の売り上げの一定のパーセンテージを販売者１３２及び／又は発行者１９０に提供するという後続販売者１９６からの合意を条件にできる。こうした販売及び類似する性質の販売は、例えば、「アップセル」及び「クロスセル」と呼ばれる。想像できるように、顧客情報の受取は、販売者１３２と後続販売者１９６との間の様々な合意を条件にできる。上記のように、顧客情報は、多数の詳細を含み、完全性が高いため、後続販売者１９６にとって独自の価値を有する。顧客情報は、販売者１３２及び発行者１９０の一方又は両方が収集したものであるため、多数の詳細を含む。販売者１３２及び発行者１９０のそれぞれは、顧客に関する特定の種類の情報を収集する独自の立場にある。最後に、顧客情報は、ステップ１乃至１２で説明した認証処理を通過したものであるため、完全性が高い。
【０１４２】
ステップ１５は、ここでも、販売者１３２と後続販売者１９６との間の取引を終結させること、紛争の解決、及び／又はデータマイニング等、様々な目的で、取引識別子を関連する顧客情報と共に検索することを含む。後続売り上げの一定のパーセンテージを販売者１３２へ送る前に、後続販売者１９６の売り上げに関する情報を検証する場合、ステップ１５は、販売者１３２と後続販売者１９６との間の契約を成立させるのに必要となり得る。例えば、顧客情報及び取引識別子は、後続販売が顧客情報の結果であることを検証するために、販売者１３２又は後続販売者１９６が検索できる。こうした検証の後、一定の金額が販売者１３２へ送られる。この状況において、顧客情報は、契約を遂行するために、通常の営業過程として一方又は両方の販売者に強制可能であり、或いは、顧客情報は、食い違いを解消する必要がある場合のみ引き出せる。
【０１４３】
紛争の解決に関して、顧客情報及び取引識別子は、販売者１３２、後続販売者１９６、又は顧客１２２のいずれかの間で紛争が生じた場合に検索される。紛争は、違反が生じた恐れのある販売者１３２と後続販売者１９６との間の契約により発生する可能性がある。ここでも、販売者１３２が後続販売者１９６に顧客情報を送ることに合意する時、後続販売者１９６は、顧客情報から得られる売り上げを分け合うことを要求される場合がある。そのため、後続販売者１９６から販売者１３２へ支払うものに関して紛争が生じた時、顧客情報を引き出すことが可能である。関係者は、顧客情報及び取引識別子を照合し、後続販売者１９６による特定の販売が顧客情報に基づいて完了されたかを検証できる。
【０１４４】
後続販売者１９６による売り上げの一部が発行者１９０にも期待できる場合、顧客情報に関する一部の合意には、発行者１９０を関与させることができる。
【０１４５】
顧客情報は、データマイニングの目的でも使用可能であり、発行者１９０、販売者１３２、及び後続販売者１９６のそれぞれは、お互いと顧客とに関する知識を得ることができる。顧客情報の分析により、関係者は、お互いの将来の取引が好ましいかを知ることができる。
【０１４６】
対価提供者としての様々な関係者
口座認証及び価値付加システムの代替実施形態では、様々な種類の関係者が、顧客１２２、販売者１３２、及び対価提供者１９６の役割を果たすことができる。顧客１２２及び販売者１３２の役割は、販売者１３２が顧客の同一性を認証する必要がある場合、互いにオンラインでやり取りする任意の関係者になり得る。販売者１３２が顧客１２２に何らかの商品又はサービスを販売する多数の商業的状況が想像できる。しかしながら、多数の非商業的状況も想像できる。一部の状況には、運転免許、入漁免許、建築免許、社会保障費、及び学校の受講登録といったオンライン登録が含まれる。関係者（販売者１３２等）が別の関係者（顧客１２２等）の同一性認証を要求するシナリオであると理解されたい。
【０１４７】
販売者１３２等の同一性認証者が評価する基準は、様々な種類の対価提供者１９６に関連する可能性がある。基準は、通常、本発明により認証された同一性を有する顧客１２２等の関係者に関する情報の受取を、対価提供者１９６が希望するかに関連する。ステップ１３で送信された顧客情報は、異なる対価提供者１９６のそれぞれに関連する可能性がある。顧客１２２が運転免許を申請する場合、顧客情報は、例えば、顧客の運転記録、運転している車、日常の運転、及び一般的な目的地に関連する可能性がある。対価提供者１９６は、運転に関連する商品又はサービスを顧客に販売することを希望する任意の関係者になり得る。例えば、対価提供者１９６は、排気ガス検査会社、修理店、又は自動車保険会社になり得る。別の実施形態において、対価提供者１９６は、運転に関連するものを何も販売しない場合もある。しかしながら、対価提供者１９６は、それでも顧客１２２が興味を持ち得る商品又はサービスを販売し得る。例えば、顧客情報は、顧客１１２が特定の種類の車を運転しており、したがって、顧客１１２が特定の種類の消費又はサービスに興味を有し得ることを示す場合がある。様々な種類の関係が顧客情報から抽出可能であり、したがって、対価提供者１９６によって有用となる可能性がある。
【０１４８】
顧客１２２が入漁免許を入手する時、対価提供者１９６は、例えば、釣り具販売店、旅行代理店、又は衣料品店となり得る。ここでも、対価提供者１９６は、釣りに直接的に関連する会社である必要はない。対価提供者１９６に送信される顧客情報は、釣りに関する顧客の好みに関連する可能性がある。販売者１２２が評価する基準により、顧客１２２がどのような釣り具を好むか、どのような釣りが好みか、顧客１２２はどこへ釣りに行くのが好きか、及び顧客１２２が使用する衣類の種類を決定できる。
【０１４９】
顧客情報は、更にワークフローの目的で対価提供者に送信できる。例えば、顧客１２２が建築許可又は免許を販売者１２２に申請した後、次のレベルの承認のために、顧客情報を別の政府機関へ送る必要が生じ得る。例えば、建物の建設中に防災安全検査を手配するために、消防署で顧客情報を受け取る必要が生じ得る。
【０１５０】
販売者１２２及び対価提供者１９６のそれぞれは、顧客情報及び取引識別子の共有に基づいて、互いに価値付加関係を結ぶことが可能である。
【０１５１】
一部の実施形態において、販売者１２２は、顧客情報及び取引識別子を多数の対価提供者に送信できる。販売者１２２は、各種類の対価提供者１９６のために、異なる又は同じ一組の基準を評価できる。各対価提供者１９６は、互いに並行して又は順番に、タスクの実行へ進む。対価提供者１９６は、顧客１２２が各対価提供者１９６から直接通知を受けるように、それぞれのタスクをリアルタイムで実行可能であり、或いはタスクはオフラインで実行可能である。
【０１５２】
上記のように、ステップ１５は、販売者１３２、対価提供者１９６、及び発行者１９０のいずれかの間で契約を結ぶために、様々な目的で使用できる。
【０１５３】
対価提供者としてのセキュリティ組織
本発明の一部の実施形態は、国家安全保障等、セキュリティの目的で使用できる。こうした実施形態において、対価提供者１９６は、安全保障問題の情報（データ）の検討を責務とする政府機関又は任意の組織にすることができる。販売者１３２は、顧客１２２との取引をオンラインで実行する任意の営利的、非営利的、政府、又は非政府機関にすることができる。例えば、販売者は、航空券予約会社、工具店、薬品供給業者、又は飛行訓練学校にすることができる。顧客情報の伝送の一部又は全部は、プライバシ及び市民権に関する法律で規制され得ることに留意されたい。
【０１５４】
販売者１３２は、セキュリティ関連の基準により顧客情報を評価し、特定の基準が満たされた時、情報を取引識別子と共に対価提供者１９６へ送信する。例えば、基準により、顧客の購入品目、免許登録、旅行目的地、旅行頻度、その他のセキュリティ関連事項を評価できる。顧客情報及び取引識別子の受取後、対価提供者１９６は、監視任務を実行できる。
【０１５５】
取引識別子は、必要な場合に、セキュリティ関連の業務監査を正確に追跡できるように顧客情報を記録する上で有用となる。これは、例えば、政府の命令によるセキュリティプロトコルの調査の際に必要となり得る。具体的には、販売者１３２は、セキュリティプロトコルに正確に従っていたことを証明する必要が生じ得る。一部の状況において、販売者１３２は、裁判所の命令による召喚状に応答する。顧客情報及び取引識別子は、ステップ１５において、認証履歴サーバ１３０からの強制又は引き出しが可能である。ステップ１５は、販売者１３２、報告者、及び対価提供者１９６間で契約を結ぶために使用することもできる。例えば、販売者１３２は、有用な情報を報告したことに対する評価又は認定を受けることができる。この評価は、取引識別子を使用して、顧客情報に関するソース、日付、その他の詳細を証明した後で受け取ることができる。ステップ１５は、更に、認証履歴サーバ１３０からデータを引き出し、セキュリティ関連問題のデータマイニングを行うために、様々な関係者が使用できる。顧客情報は、発行者１９０及び販売者１３２から収集するため、監視目的において非常に役立つ情報を多く含む可能性が高い。
【０１５６】
一部の実施形態において、対価提供者１９６及び販売者１３２は、顧客情報を受信した直後に対価提供者１９６が販売者１３２にメッセージを送信できるように、リアルタイムで互いに通信する。これにより、望ましくない状況を解決又は回避するために、即座に処置を講じることができる。
【０１５７】
好適なシステムネットワーク
図９は、本発明の実施形態を実施するのに適した電気通信ネットワーク８００を示している。本発明では、任意の適切な電気通信ネットワークを使用してよく、以下に説明するもの等の様々なハードウェア、様々なソフトウェア、及び／又は様々なプロトコルを含んでよい。下記のネットワークは、図２の電気通信ネットワーク１２６の好適な実施形態である。ネットワーク８００は、任意のバンクカード、旅行及び娯楽カード、及び他の自社ブランド及び専用カードを使用した購入及び現金取引をサポートする、世界的な電気通信ネットワークである。ネットワークは、他のネットワークのＡＴＭ取引、紙の小切手を使用した取引、スマートカードを使用した取引、及び他の金融手段を使用した取引もサポートする。
【０１５８】
こうした取引は、ネットワークの許可、決済、及び清算サービスにより処理される。許可は、販売を確定する前、或いは現金を分散させる前に、発行者が販売取引を承認又は拒否する時期である。決済は、顧客の口座へ転記するために、取引を取得者から発行者へ引き渡す時期である。清算は、決済された全取引について、各関係者の純財務状態を計算及び決定する処理である。実際の資金の交換は、別個の処理となる。
【０１５９】
取引は、二重メッセージ又は単一メッセージ取引として、許可、決済、及び清算可能である。二重メッセージ取引は二度送信され、最初は、許可の判断に必要な情報のみ送信され、その後、決済及び清算のために追加情報が再び送信される。単一メッセージ取引は、許可のために一度送信され、決済及び清算情報も含まれる。通常、許可、決済、及び清算は、全てオンラインで行われる。
【０１６０】
電気通信ネットワーク８００の主要構成要素は、交換センタ８０２と、アクセスポイント８０４、８０６と、処理センタ８０８、８１０とである。名宛銀行及び要求者認証機関といった他の実体も、アクセスポイントを介してネットワークに接続する。交換センタは、世界のどこにでも位置し得るデータ処理センタである。一実施形態では、米国に二箇所、英国及び日本に一箇所ずつ存在する。各交換センタは、ネットワーク取引処理を実行するコンピュータシステムを収容する。交換センタは、ＩＢＭ ＳＮＡプロトコルに基づく高速専用回線又は衛星接続を含む、ネットワークの電気通信設備の制御点として機能する。好ましくは、交換センタを遠隔実体に接続する回線８２０及び８２２は、ＩＢＭ ＳＮＡ−ＬＵ０通信プロトコルに基づく専用の高帯域電話回路又は衛星接続を使用する。メッセージは、ＩＳＯ８５８３規格の任意の適切な実施を使用して、これらの回線を介して送信される。
【０１６１】
アクセスポイント８０４又は８０６は、通常、処理センタに配置され、センタのホストコンピュータと交換センタとの間をインタフェースする小型コンピュータシステムである。アクセスポイントは、ホストと、取引の許可、決済、及び清算をサポートする交換センタとの間でのメッセージ及びファイルの送信を容易にする。リンク８２６及び８２８は、通常、センタ内のローカルリンクであり、センタにとって好ましい専用のメッセージ形式を使用する。
【０１６２】
データ処理センタ（取得者、発行者、又はその他の実体内に位置するようなもの）は、販売者及び事業拠点をサポートする処理システムを収容し、顧客データ及び請求システムを維持する。好ましくは、各処理センタは、一箇所又は二箇所の交換センタとリンクされる。プロセッサは、最も近い交換センタに接続され、ネットワークが障害を受けた場合、ネットワークは、取引を自動的に二次的な交換センタへ送る。各交換センタは、他の全ての交換センタにもリンクされる。このリンクにより、処理センタは、一箇所以上の交換センタを介して互いに通信できる。更に、処理センタは、交換センタを介して、他のプログラムのネットワークにアクセスできる。更に、ネットワークは、全てのリンクが複数のバックアップを有する状態を確保する。ネットワークの一点から別の点への接続は、通常は固定リンクではなく、代わりに交換センタは、任意の伝送の時点で、可能な最善の経路を選択する。何らかの障害のあるリンクを迂回するルート変更は、自動的に行われる。
【０１６３】
図１０は、オンライン及びオフライン取引処理を提供するために交換センタに収容されたシステム８４０を示している。二重メッセージ取引では、許可システム８４２が許可を与える。システム８４２は、オンライン及びオフライン機能をサポートし、そのファイルには、内部システムテーブル、顧客データベース、及び販売者中央ファイルが含まれる。システム８４２のオンライン機能は、二重メッセージ許可処理をサポートする。この処理は、ルーティングと、利用者及びカード検証及び代理処理と、ファイルメインテナンス等のその他の機能とを含む。オフライン機能は、報告と、請求と、リカバリブリテンの生成とを含む。報告は、許可報告、例外ファイル及びアドバイスファイルの報告、ＰＯＳ報告、及び請求報告を含む。システム８４２からシステム８４６へのブリッジにより、システム８４２を使用する構成要素は、システム８４６を使用する構成要素と通信し、外部ネットワークへのＳＭＳゲートウェイにアクセスできる。
【０１６４】
決済及び清算システム８４４は、事前に許可された二重メッセージ取引を決済及び清算する。週六日、世界全体で稼働し、システム８４４は、金融及び非金融情報を収集し、報告を構成要素間で配信する。更に、手数料、使用量、及び清算総額を計算し、調整を支援するために報告を作成する。ブリッジは、システム８４４の処理センタとシステム８４６の処理センタとの間の交換部を形成する。
【０１６５】
単一メッセージシステム８４６は、完全な金融取引を処理する。システム８４６は、二重メッセージ認証及び決済取引も処理可能であり、ブリッジを使用してシステム８４２と通信し、必要に応じてネットワークの外部にアクセスする。システム８４６は、ビザ プラス インターリンク（Ｖｉｓａ、Ｐｌｕｓ Ｉｎｔｅｒｌｉｎｋ）、その他のカード取引を処理する。ＳＭＳファイルは、システムのアクセス及び処理を制御する内部システムテーブルと、ＰＩＮ検証及び代理処理認証に使用される利用者データのファイルを含む提供者データベースとを含む。システム８４６のオンライン機能は、リアルタイム利用者取引処理、及び認証の例外処理と、完全な金融取引とを実行する。システム８４６は、調整及び清算の合計を蓄積する。システム８４６のオフライン機能は、清算及び資金振替要求を処理し、清算及び活動報告を提供する。清算サービス８４８は、Ｉｎｔｅｒｌｉｎｋを含め、システム８４４及び８４６の清算機能を統合し、全製品及びサービス向けの単一のサービスとする。決済は、システム８４４及びシステム８４６によって引き続き別個に実行される。
【０１６６】
図１１は、電気通信ネットワーク８００の構成要素の別の図を示している。統合支払システム８５０は、全てのオンライン認証及び金融要求取引を処理するための主要システムである。システム８５０は、二重メッセージ及び単一メッセージ処理の両方を報告する。どちらの場合においても、清算は別個に行われる。三つの主なソフトウェアコンポーネントは、共通インタフェース機能８５２、認証システム８４２、及び単一メッセージシステム８４６である。
【０１６７】
共通インタフェース機能８５２は、交換センタにおいて受け取られた各メッセージに求められる処理を決定する。メッセージのソース（システム８４２、８４４、又は８４６）、処理要求の種類、及び処理ネットワークに基づいて、適切なルーティングを決定する。このコンポーネントは、初期メッセージ編集を実行し、必要な場合、メッセージを解析して、内容が基本構成規則に従う状態を確保する。機能８５２は、メッセージをシステム８４２又はシステム８４６の送信先へ送る。
【０１６８】
コンピュータシステムの実施形態
図１２Ａ及び１２Ｂは、本発明の実施形態を実施するのに適したコンピュータシステム９００を示す。図１２Ａは、コンピュータシステムの可能な物理的形態の一つである。当然ながら、コンピュータシステムは、集積回路、プリント回路基板、及び小型ハンドヘルドデバイスから、巨大なスーパコンピュータまで、多くの物理形態を有し得る。コンピュータシステム９００は、モニタ９０２と、ディスプレイ９０４と、筐体９０６と、ディスクドライブ９０８と、キーボード９１０と、マウス９１２とを含む。ディスク９１４は、コンピュータシステム９００との間でデータを転送するために使用されるコンピュータ読み取り可能な媒体である。
【０１６９】
図１２Ｂは、コンピュータシステム９００のブロック図の例である。システムバス９２０には、広範なサブシステムが取り付けられる。プロセッサ（群）９２２（中央演算処理装置又はＣＰＵとも呼ばれる）は、メモリ９２４を含む記憶装置に結合される。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）及び読み出し専用メモリ（ＲＯＭ）を含む。この技術において周知であるように、ＲＯＭは、データ及び命令をＣＰＵへ一方向で転送する役割を果たし、ＲＡＭは、通常、データ及び命令を双方向で転送するために使用される。こうしたタイプのメモリは、両方とも、以下に説明する任意の適切なコンピュータ読み取り可能な媒体を含んでよい。固定ディスク９２６も、ＣＰＵ９２２に双方向で結合され、追加のデータ記憶容量を提供し、同じく以下に説明する任意のコンピュータ読み取り可能な媒体を含んでよい。固定ディスク９２６は、プログラム、データ、その他を格納するのに使用してよく、通常は、一次記憶装置より低速の二次記憶媒体（ハードディスク等）である。固定ディスク９２６内に保持される情報は、適切である場合には、標準的な方法で、メモリ９２４内に仮想メモリとして組み込んでよいことは理解されよう。リムーバブルディスク９１４は、以下に説明する任意のコンピュータ読み取り可能な媒体の形態を取り得る。
【０１７０】
ＣＰＵ９２２は、ディスプレイ９０４、キーボード９１０、マウス９１２、及びスピーカ９３０等の様々な入出力デバイスにも結合される。一般に、入出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロフォン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、生体認証リーダ、又は他のコンピュータのいずれかにしてよい。ＣＰＵ９２２は、随意的に、ネットワークインタフェース９４０を使用して、別のコンピュータ又は電気通信ネットワークに結合され得る。こうしたネットワークインタフェースにより、ＣＰＵは、上記の方法ステップを実行する過程で、ネットワークから情報を受け取ること、或いはネットワークへ情報を出力することが考えられる。更に、本発明の方法の実施形態は、ＣＰＵ９２２単独で実行し得るものであり、或いは、処理の一部を共有するリモートＣＰＵと連動して、インターネット等のネットワーク上で実行し得る。
【０１７１】
加えて、本発明の実施形態は、更に、様々なコンピュータ実施動作を実行するためにコンピュータコードを有するコンピュータ読み取り可能な媒体を備えたコンピュータストレージ製品に関する。媒体及びコンピュータコードは、本発明のために特別に設計及び構築されたものにしてよく、或いは、コンピュータソフトウェア技術に関する当業者に周知であり利用可能な種類のものにしてよい。コンピュータ読み取り可能な媒体の例には、一部として、ハードディスク、フレキシブルディスク、及び磁気テープといった磁気媒体と、ＣＤ−ＲＯＭ及びホログラフィックデバイスといった光学媒体と、フロプティカルディスク等の光磁気媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、及びＲＯＭ及びＲＡＭデバイスといった、プログラムコードを格納及び実行するために特別に構成されたハードウェアデバイスとが含まれる。コンピュータコードの例には、コンパイラによって生成されるようなマシンコードと、インタプリタを使用してコンピュータで実行される高レベルコードを含むファイルとが含まれる。
【０１７２】
以上、本発明について、いくつかの好適な実施形態により説明してきたが、本発明の範囲に含まれる変更、置換、及び等価物が存在する。更に、本発明の方法及び装置を実施する数多くの代替方法が存在することにも留意されたい。したがって、添付特許請求の範囲は、本発明の本来の趣旨及び範囲に入るこうした全ての変更、置換、及び等価物を含むものと解釈されるべきである。
【図面の簡単な説明】
【０１７３】
【図１】様々なタイプの口座認証用途に対して本発明の口座認証サービスを実施するためのシステムアーキテクチャの一実施形態を示す図である。
【図２】支払取引における本発明の認証サービスをサポートするシステムアーキテクチャの一実施形態を示す図である。
【図３】本発明の一実施形態による、口座保有者が口座認証システムに登録する処理を示す図である。
【図４】口座保有者が口座認証システム加入処理中に情報を入力できるインターネットｗｅｂページの一実施形態を示す図である。
【図５】口座保有者がインターネットに接続されたコンピュータを使用する、口座認証システムにおける認証支払取引を説明する図である。
【図６】口座保有者にパスワードを要求するウィンドウの例を示す図である。
【図７】消費者がインターネットに接続されたコンピュータを使用する口座認証システムに重ね合わせて、支払取引中に送信されるメッセージの例を示す図である。
【図８】対価提供の態様を含むオンライン口座認証に関連するシステムアーキテクチャの例と、一組のメッセージフローとを示す図である。
【図９】本発明の実施形態を実施するのに適した電気通信ネットワークを示す図である。
【図１０】オンライン及びオフライン取引処理を提供するために交換センタに収容されたシステムを示す図である。
【図１１】電気通信ネットワークの構成要素の別の図である。
【図１２Ａ】本発明の実施形態を実施するのに適したコンピュータシステムを示す図である。
【図１２Ｂ】本発明の実施形態を実施するのに適したコンピュータシステムを示す図である。
【技術分野】
【０００１】
本発明は、オンライン取引中に口座保有者の同一性を認証する事に関し、特に、認証処理に関連する情報を対価提供者が共有及び使用する手法に関する
【背景技術】
【０００２】
支払いカード（例えば、クレジットカード、デビットカード、又は価値格納カード）を使用した支払取引中には、カード保有者の口座の所有を検証し、不正使用等の様々な問題を回避することが重要である。支払者認証は、カード保有者の口座所有権を検証する処理である。カード保有者の口座所有権を認証する最も一般的な方法は、「カード有り」取引と呼ばれるものの間に、販売場所で日常的に発生する。カード有り取引には、販売者の代行者がカード保有者のカードを受け取り、口座の状態とクレジットラインの利用可能性とを検証するために支払カード端末に通し、カード裏面の署名が購入者の署名と一致するかを確認するためにチェックすることを含む。販売者がこの種の取引の特定の指針に従う場合、販売者は、割引額と手数料とを差し引いた、認証額の支払を保証される。ビザ インターナショナル サービス アソシエーション（Ｖｉｓａ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｅｒｖｉｃｅ Ａｓｓｏｃｉａｔｉｏｎ）等のサービスプロバイダ（又はサービス組織）は、こうした特定の指針を提供してよい。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
一方、オンライン、郵便、又は電話で発生するような「カード無し」取引には、販売者に対して保証されない支払が関与する。保証が提供されないのは、主に、こうして非対面取引では支払者が認証されず、「カード無し」取引に多数のリスクが伴うためである。こうしたリスクは、オンライン販売者に対する支払取引のチャージバック、販売者とカード保有者との両方に対する詐欺、銀行に対する例外項目処理費用の増加、一部の顧客にオンラインでの購入を回避させ得る、オンラインでの商品及びサービスの購入が安全確実ではないという認識の増加等の問題が含まれる。リスクの具体的な例には、商品及びサービスをオンラインで購入するための盗難口座情報の不正使用、不正なオンライン購入を行うためのカード口座番号の偽造、ネットワークトラフィックからの平文口座情報の抽出が含まれる。
【０００４】
電子商取引の予想される継続的な高成長を考えると、支払者を認証する方法を提供する事が重要である。オンライン取引の種類の幅広さを考えると、取引に商業的側面が存在するか否かに関係なく、関係者の同一性を認証する方法を提供することも重要である。これは、カード保有者、販売者、金融機関から、政府機関に至る全ての取引参加者に利益をもたらす。オンライン取引中に顧客を認証することで、詐欺、紛争、回収、及びチャージバックのレベルが減少し、結果として、こうした事象のそれぞれに関連するコストが減少する。顧客を認証することで、セキュリティの問題にも対処するため、オンライン活動の増加につながる。オンライン取引中に関係者を認証するために使用される従来のシステムは、使用するのが難しく、複雑な設計を有し、システム関与者に大きな事前投資が求められ、相互運用性が不足していることから、広範囲には採用されていない。特定の従来のシステムでは、追加として、販売者、カード保有者、発行者、及び取得者による証明書の作成、配布、及び使用が必要となる。こうした証明書の使用は、非常に負担となることが知られている。
【０００５】
上記を鑑みると、オンライン取引において顧客の同一性を認証する改良されたシステムを提供するために、継続的な努力がなされている。更に、こうした認証処理に関与する者に利用可能な情報を有効に使用するために、継続的な努力がなされている。
【課題を解決するための手段】
【０００６】
本発明は、オンライン取引中に利用者の同一性を認証する口座認証サービスを対象とする。認証サービスにより、信頼機関は、パスワード又はトークン等の様々な認証方法を使用して、要求する関係者（「要求者」）のために、口座保有者の同一性を検証できる。オンライン取引中における口座保有者の同一性認証は、口座保有者からパスワードを要求し、パスワードを検証し、口座保有者の信頼性が検証されたか否かを要求者に通知することを含む。口座認証サービスの代替実施形態は、顧客に関する情報が対価提供者と共有される提供対価構成要素を含む。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。関与する全ての関係者は、顧客情報を共有することで利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。顧客と販売者との間で特定の取引を識別する取引識別子と顧客情報とを使用することで、関係者のそれぞれは、取引と、顧客情報に関連する任意の合意とについて監査できる。
【０００７】
方法として、本発明の一実施形態は、少なくとも、利用者から同一性認証パスワードを受け取り、同一性認証パスワードを利用者の口座に事前指定したパスワードと比較することを含む。方法は、更に、利用者から受け取った同一性認証パスワードが口座に事前指定したパスワードと一致した場合に、利用者が口座の実際の所有者であることを要求者に通知すること含む。このようにして、信頼機関は、要求者のために、利用者が口座の実際の所有者であることを認証する。方法は、更に、利用者情報の対価提供者への送信を含む。一部の実施形態において、方法は、更に、利用者情報を一組の基準に照らして評価し、利用者情報が一組の基準を満たす場合に、利用者情報を対価提供者に送信することを含む。これにより、対価提供者は、所望の顧客情報を受け取ることができる。更に、要求者及び対価提供者のそれぞれは、利用者情報が対価提供者に送信される前に、条件として一組の権利及び義務に合意できる。追加として、取引識別子は、個別のオンライン取引と、関連づけられている顧客情報とを追跡するために使用できる。
【０００８】
本発明の一実施形態において、要求者は、販売者であり、対価提供者は、顧客情報を使用して、販売者から購入製品を出荷可能な運送会社である。顧客情報は、製品を顧客に出荷するか、どのように出荷するかについて、運送会社が判断するのを助ける。
【０００９】
本発明の別の実施形態において、要求者は、販売者であり、対価提供者は、顧客情報を使用して自分の商品又はサービスを顧客に売り込む後続販売者である。顧客情報は、顧客に連絡するか、どのように連絡するかについて、後続販売者が判断するのを助ける。
【００１０】
本発明の別の実施形態において、対価提供者は、顧客情報を使用してセキュリティ問題を評価できるセキュリティ組織である。顧客情報は、考えられるセキュリティ問題に対処するか、どのように対処するかについて、セキュリティ組織が判断するのを助ける。
【００１１】
本発明の上記及びその他の特徴及び利点について、以下の本発明の明細書と、本発明の原理を例示する添付図面とにおいて、更に詳細に提示する。
【発明を実施するための最良の形態】
【００１２】
本発明は、その更なる利点と共に、以下の説明を次の添付図面と併せて参照することにより、最も良く理解されよう。
【００１３】
本発明について、添付図面に例示した、いくつかの好適な実施形態を参照して、詳細に説明する。以下の説明では、本発明の完全な理解を提供するために、多数の具体的な詳細について述べる。しかしながら、こうした具体的な詳細の一部又は全部がなくとも、本発明を実施し得ることは、当業者には明白であろう。また、本発明を不必要に曖昧にしないために、周知の動作についての詳細な説明は省略する。
【００１４】
本説明は、図１において、本発明による一般的な口座認証システム及びプロトコルの概要から始める。口座認証システムは、関与する発行者、口座保有者、及び販売者へのサービスとして提供される。次に、図２乃至７において、オンライン支払取引に関連する口座認証システムについて説明する。オンライン支払取引の説明は、支払取引自体、システム設定、顧客登録、及び具体的なメッセージフローを対象とする。オンライン支払取引の説明は、非支払取引の説明に類似する。支払及び非支払取引は、両方とも、口座保有者の同一性の認証を含む。
【００１５】
次に図８において、提供対価構成要素を含む口座認証処理について説明する。価値は、最初に、顧客に関する情報を対価提供者と共有することで付加される。顧客情報は、口座認証処理において関係者のそれぞれから収集されるため、顧客に関する詳細を数多く含む。対価提供者は、その後、この情報を様々な形で使用できる。例えば、対価提供者は、焦点を絞った情報を顧客に提供可能であり、或いは、顧客に商品を発送可能である。関与する全ての関係者は、顧客情報を共有することで利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。顧客と販売者との間で特定の取引を識別する取引識別子と顧客情報とを使用することで、関係者のそれぞれは、取引と、顧客情報に関連する任意の合意について監査できる。本願では、こうした情報の共有を、広範な用途で、広範な関係者の利益のために、どのようして有利な形で使用できるかについて説明する。
【００１６】
口座認証システム
口座認証システムは、一方の関係者が特定の口座の所有者であると主張する別の関係者の同一性を物理的に検証できない取引中に、口座保有者の口座所有権を認証するように設計される。例えば、口座認証システムは、信頼機関が要求者のために利用者の同一性を認証する時に、様々な取引で使用できる。要求者とは、信頼機関に利用者の同一性の認証を要求する任意の個人又は団体である。信頼機関とは、利用者の同一性を認証可能で、利用者及び要求者が認証処理の実行を委ねる団体である。信頼機関は、利用者の同一性に関する誤り又は詐欺の際に、要求者の利益を保護することに合意できる。口座認証システムの重要な用途は、オンラインで、又は携帯電子機器を介して行われる、支払取引の分野である。
【００１７】
しかしながら、システムは、支払取引に加えて、多数の用途において有用となり得る本発明のシステムは、顧客の同一性の認証が必要となる様々な非支払状況において使用できる。例えば、非支払取引は、例えば、登録処理のため、インターネットｗｅｂサイトにアクセスしてオンラインフォームに記入する顧客を認証する等の取引を含む。非支払取引は、僅かな例として、小売銀行業、卸売銀行業、医療業、保険業、及び仲買業の多数の態様を含む。小売銀行業には、デビットカード、購入カード、及び価値格納カード等のカードで使用する口座番号が関与する。非支払取引には、ＩＤカード及びライセンス等のために、オンラインフォームを記入することが含まれる。例えば、米国自動車協会（ＡＡＡ）は、システムを使用して、顧客の一人の同一性を認証可能であり、電話カード会社は、システムを使用して、特定のカードのユーザの同一性を認証できる。
【００１８】
図1は、様々なタイプの口座認証用途に対して口座認証システムを実施するためのシステムアーキテクチャ１００の一実施形態を示している。システムアーキテクチャ１００は、三つの領域、即ち、信頼機関領域１０３、相互運用領域１０４、及び要求者領域１０５を含む。
【００１９】
信頼機関領域と要求者領域は、それぞれ信頼機関又は要求者により完全に又は少なくとも部分的に制御される構成要素を内部に有する機能範囲を定める。相互運用領域は、信頼機関、要求者、及びサービス組織等の他の関係者が利用し得る構成要素を内部に有する機能範囲を定める。
【００２０】
信頼機関領域１０３は、信頼機関により主に制御される構成要素を含む。信頼機関の例は、発行銀行として知られる、支払カードを消費者に発行する金融機関である。具体的には、発行者、又はカード発行者は、カード供給者から受け取った新たなカードを個人化し、こうしたカードを顧客に発行する。個人化は、カード供給者又は個人化局が実行してもよい。金融機関に加え、発行者は、電気通信ネットワークオペレータ、サービス団体、販売者その他の組織、又は発行者を代行する代理業者等、任意の適切な発行団体であってよい。要求者領域１０５は、要求者により主に制御される構成要素を含む。要求者は、口座保有者の同一性の認証を要求する任意の関係者にすることができる。例えば、要求者は、クレジットカード口座の所有者であると主張する人物の同一性の認証を希望する販売者にできる。取得者は、要求者を支払体系に加入させ、要求者の口座を管理する金融機関にできる。取得者は、更に、オンライン販売者からの情報を電気通信ネットワークへ送る。別の実施形態において、販売者は、情報を直接、電気通信ネットワークへ送る。
【００２１】
相互運用領域１０４は、インターネットでサポート可能であり、信頼機関と要求者との両方に使用される構成要素を含む。
【００２２】
信頼機関領域１０３は、発行者口座保有者システム１１０と、加入サーバ１１２と、アクセス制御サーバ（ＡＣＳ）１１４と、口座保有者ファイル１１８とを含む。システムが使用される特定の使用分野に応じて、信頼機関領域１０３には追加構成要素が含まれる。例えば、以下の支払取引では、支払取引に関して口座保有者の同一性を認証する目的で、それぞれの領域に追加構成要素が存在する。
【００２３】
加入サーバ１１２は、口座保有者が回答し、信頼機関が検証する一連の質問をｗｅｂインタフェース経由で提供することにより、口座保有者の口座認証システムへの加入を管理するコンピュータである。図１に示したように、信頼機関は、加入サーバ１１２を運用する。しかしながら、Ｖｉｓａ等のサービス組織は、信頼機関にかわって加入サーバ１１２を運用できる。信頼機関は、口座保有者の同一性の妥当性確認を支援するために、加入処理中に外部の団体が提供するｗｅｂ対応の対話式「同一性認証サービス」を使用できる。
【００２４】
ＡＣＳ１１４は、口座認証システムが提供する口座認証サービスに登録された口座保有者のデータベースを有するコンピュータである。ＡＣＳ１１４は、各口座保有者の口座及びパスワード情報を含む。口座認証処理中、ＡＣＳ１１４は、認証要求者にデジタル署名入り受取者を提供し、口座認証システムへのアクセスを制御し、口座保有者のサービスへの参加の妥当性を確認する。カード発行者、或いはＶｉｓａ等のサービス組織は、信頼機関のためにＡＣＳ１１４を運用できる。口座認証サービスでは、何らかの追加口座保有者ソフトウェアを使用する必要はないが、随意的な口座保有者ソフトウェア及びハードウェアを配置してもよい。追加口座保有者ソフトウェアは、デジタル証明書、集積回路カード（チップカード）、及びチップカードリーダ等の追加的な認証手法をサポートできる。本発明において、証明書を必要とする唯一のシステム参加者は、発行金融機関である。
【００２５】
口座保有者ファイル１１８は、口座認証システムへの加入に成功した口座保有者に関する情報を格納するために、信頼機関が管理するデータベースである。発行者口座保有者システム１１０（又は信頼機関の口座保有者システム）は、信頼機関により制御され、口座保有者に関する情報を含む。こうした情報は、口座情報、口座保有者が利用するサービス等に関連する。発行者口座保有者システム１１０内の情報の一部は、口座保有者の口座認証サービスへの加入において使用できる。
【００２６】
要求者領域１０５の要求者１８０は、通常、口座保有者の認証を希望する。関係者１８０は、認証プロトコルを円滑にする要求プラグインソフトウェア１８２を管理する。要求プラグインソフトウェア１８２は、第三の又は要求者のｗｅｂサイトに統合されるソフトウェアモジュールである。プラグインソフトウェアモジュール１８２は、口座認証システムと、要求者の処理ソフトウェア、例えば、販売者の支払処理ソフトウェアとの間のインタフェースを提供する。
【００２７】
相互運用領域１０４は、ディレクトリサーバ１２８を含み、インターネットによりサポートされ、信頼機関と要求者との両方に使用される構成要素を含む。ディレクトリサーバ１２８は、要求者からの認証要求を、ＡＣＳ１１４等の特定のＡＣＳへ送る。ディレクトリサーバ１２８は、カード体系管理者、或いはＶｉｓａ等のサービス組織により運用される。相互運用領域１０４は、インターネット以外のネットワークでもサポートできる。
【００２８】
支払取引用の口座認証システム
次に、支払取引の分野において口座保有者を認証するためのシステムアーキテクチャについて説明する。支払用途の認証処理は非支払用途に類似するため、本節において説明する多数の一般的概念は、様々な使用分野へ応用できることに留意されたい。
【００２９】
支払取引における認証システム及びプロトコルの使用例について以下に説明する。認証システムは、口座保有者がオンラインで買い物し、品目を「ショッピングカート」に追加し、オンライン販売者のチェックアウトページへ進み、オンライン販売者のチェクアウトフォームを記入する状況において有用となる。認証処理は、消費者が自分の希望する製品又はサービスの購入を決定した後、例えば、消費者が「購入」ボタンをクリックした後で行われる可能性がある。認証処理は、諸費者の支払取引における他の様々な時期に開始される可能性がある。認証処理は、支払ネットワークのいくつかのポイントに組み込まれたソフトウェアを利用することで、消費者にとって、殆どがトランスペアレントモードで実行される。システムは、認証サービスにより、口座保有者と口座保有者の金融機関との参加の妥当性確認を行う。その後、ウィンドウが作成され、ウィンドウの中で、口座保有者からの事前登録パスワードを要求することで、消費者は、自分の同一性を確認できる。消費者の同一性が確認された場合、支払情報と、消費者の認証の通知とが販売者へ返信される。その後、従来行われるように、販売者により支払取引が処理される。例えば、販売者は、注文確認メッセージを口座保有者のブラウザに送信してよい。
【００３０】
図２は、支払取引における認証サービスをサポートするシステムアーキテクチャ２００の一実施形態を模式的に示している。図１の一般的なシステムアーキテクチャ１００と同様に、アーキテクチャ２００は、三つの領域、即ち、発行者領域１０２、相互運用領域１０４、及び取得者領域１０６に分割される。図２の発行者領域１０２及び取得者領域１０６は、それぞれ図１の信頼機関領域１０３及び要求者領域１０５に類似する。
【００３１】
発行者領域１０２は、加入サイト１０８と、発行者口座保有者システム１１０と、口座保有者クライアントデバイス１２２と、加入サーバ１１２と、アクセス制御サーバ（ＡＣＳ）１１４と、発行者又は要求者同一性認証構成要素１１６と、口座保有者ファイル１１８とを含む。随意的に、発行者領域１０２は、承認口座保有者１２０の発行者ファイルを含むことができる。口座保有者は、利用者を示す別の用語であり、これは特定の同一性を有するものとして口座保有者が自らを提示するためである。加入サーバ１１２は、口座保有者が回答し、信頼機関が検証する一連の質問をｗｅｂインタフェース経由で提供することにより、口座保有者の口座認証システムへの加入を管理するコンピュータである。加入サーバ１１２は、インターネット支払ゲートウェイサービス１２４にインターネットを介して接続され、インターネット支払ゲートウェイサービス１２４は、次に電気通信ネットワーク１２６、例えば、ビザネット（ＶｉｓａＮｅｔ）に接続される。インターネット支払ゲートウェイサービス１２４により、加入サーバ１１２は、電気通信ネットワーク１２６と通信できる。支払ゲートウェイサービス１２４を介した接続により、加入サーバ１１２は、発行者の認証システム１２７に問い合わせを行い、加入中の口座保有者が有効なカード口座を有するかを判断できる。加入サイト１０８は、口座認証システムが提供する口座認証サービスに参加するために口座保有者が登録可能なインターネットｗｅｂサイトである。
【００３２】
口座保有者クライアントデバイス１２２は、口座保有者が口座認証システムに参加するために使用する。具体的には、口座保有者クライアントデバイス１２２は、パーソナルコンピュータ、携帯電話、携帯情報端末、又はインタラクティブケーブルテレビ等、インターネットにアクセス可能な任意の機器にできる。一部の実施形態において、口座保有者クライアントデバイス１２２は、インターネットに接続できないが、しかしながら、インターネットに基づかないメッセージを処理可能な特殊なノードを介して、クライアントデバイス１２２からの入力及び出力メッセージが送られるため、こうしたデバイスも口座保有者により使用可能である。例えば、音声及び／又はテキストメッセージに基づくメッセージを送受信する携帯電話はインターネットに接続できないが、しかしながら、メッセージを異なる方法で送ることにより、口座認証システムで使用できる。ショートメッセージサービス（ＳＭＳ）は、一般的に使用されるメッセージングシステムの例である。音声自動応答（ＩＶＲ）ユニットは、音声チャネルを介した自動交換に使用できる。こうしたメッセージルーティングの仕組みについては、インターネット対応デバイスに関する以下の節において更に詳細に説明する。
【００３３】
発行者口座保有者システム１１０は、口座保有者に関する情報を含む発行者制御システムである。このシステムの情報は、口座情報、口座保有者が利用するサービス等に関連する情報を含む。発行者口座保有者システム内の情報の一部は、口座保有者を口座認証システムへ加入させる処理において使用できる。
【００３４】
発行者又は要求者同一性認証データベース１１６は、発行者又は要求者が口座保有者に関するファイル上に既に有している情報を含む。データベース１１６は、口座保有者を加入させるプロセスにおいて、口座保有者の同一性を検証するために、発行者により使用される。例えば、口座認証システムが提供するサービスへの登録に口座保有者が成功するためには、口座保有者登録処理中に口座保有者が入力した情報は、認証データベース１１６のファイル上に既に存在する情報と一致するべきである。エクィファクス（Ｅｑｕｉｆａｘ）のような会社を第三者にすることができる。
【００３５】
相互運用領域１０４は、ディレクトリサーバ１２８と、認証履歴サーバ１３０と、受取マネージャ１３１とを含む。ディレクトリサーバ１２８は、要求者からの認証要求を特定のＡＣＳへ送る。ディレクトリサーバ１２８は、Ｖｉｓａ等のサービス組織により運用される。認証履歴サーバ１３０及び受取マネージャ１３１は、署名入り受取書（例えば、以下に説明する支払要求応答メッセージのコピー）を認証済み支払取引毎に格納する。認証履歴サーバ１３０は、どの取引が認証されたかを検証する情報を含み、紛争解決処理中に追加情報を提供する。認証履歴サーバ１３０及び受取マネージャ１３１は、サービス組織が運用する。発行者、取得者、又は販売者も、デジタル署名入り受取書のコピーを保持できる。
【００３６】
取得者領域１０６は、販売者１３２と、妥当性確認サーバ１３６とを含む。ＭＰＩ１３４は、販売者１３２の場所に常駐する。ＭＰＩ１３４は、販売者の電子商取引ｗｅｂサイトに統合されるソフトウェアモジュールである。ＭＰＩ１３４は、口座認証システムと、販売者の支払処理システムとの間のインタフェースを提供する。
【００３７】
ＭＰＩ１３４は、図１の要求プラグインソフトウェアモジュール１８２と同じソフトウェアモジュールであることに留意されたい。「販売者」という記述子は、ＭＰＩ１３４に対して、プラグインソフトウェアモジュールを利用している要求関係者の種類を示すために使用している。しかしながら、本明細書全体で説明されるプラグインソフトウェアモジュールは、プラグインソフトウェアモジュール１３４を説明するために使用される形容詞にかかわらず、基本的には同じ形で機能すると理解されたい。本明細書全体での用語の使用を簡略化するため、「販売者」という形容詞は、プラグインソフトウェアモジュールを説明するために使用される。しかしながら、これは、販売者である要求関係者による使用のみに適したものとして、プラグインソフトウェアモジュール１３４を限定するものではない。更に、ＭＰＩは、販売者プラグインソフトウェアモジュールの頭文字として使用される。
【００３８】
妥当性確認サーバ１３６は、支払取引中に口座認証システムが販売者に返送する受取書に署名するために使用されたカード発行者のデジタル署名を検証する。代替実施形態において、妥当性確認サーバ１３６の機能は、ＭＰＩ１３４に含めてよいため、別個の妥当性確認サーバ１３６の必要性は除去される。妥当性確認サーバ１３６は、販売者、取得者、又はサービス組織が運用する。
【００３９】
一部の実施形態において、口座認証システムは、電子ワレット等の他の口座保有者アプリケーションとの相互運用が可能であり、サービスは、電子商取引マークアップ言語（ＥＣＭＬソフトウェア）に適合して運用できる。口座認証システムは、更に、紛争解決手順を実行する能力を提供する。例えば、販売者は、紛争の解決及びチャージバックの目的で、口座保有者の認証の証拠を提供するのに十分な情報を保持できる。
【００４０】
設定及び登録の説明
次に、支払及び非支払取引の両方のための口座認証システムの設定について更に詳細に説明する。最初に、口座認証システムを使用できるように様々なシステム参加者を設定するのに必要な手順について説明する。次に、口座認証システムに登録するための口座保有者の処理について説明する。こうした段階を説明した後、支払取引の実際の認証についての説明を提供する。
【００４１】
口座認証システムの設定は、システム内の全参加者のための設定手順を含む。設定手順は、一般に、支払及び非支払取引の両方の認証で同じである。こうした参加者には、販売者又は他の認証要求者といった団体と、金融機関又は他の信頼機関と、口座保有者とが含まれる。
【００４２】
口座認証システムにサインアップしたオンライン販売者等の要求者は、図１のプラグインソフトウェアモジュール１８２及び図２のモジュール１３４のようなプラグインソフトウェアモジュールを受け取る。プラグインソフトウェアモジュールは、要求者が使用するコンピューティングプラットフォーム及びサーバソフトウェアに特有のものとするべきである。口座認証システムに参加する金融機関等の要求者は、カスタマイズした加入サイトテンプレートに組み込むべきサービスロゴ及びマーケティングデザインを提供する。取得銀行である第三者は、更に、サービス組織認証局（ＣＡ）ルート証明書と、クライアント認証用のサービス組織認証局ＳＳＬ証明書と、統合のサポートとを販売者に提供するべきである。
【００４３】
信頼機関は、口座認証システムを使用するための設定を可能とするために、信頼機関領域において指定された、全ての口座認証システムハードウェア及びソフトウェアのコピーを入手及びインストールするべきである。発行金融機関等の信頼機関は、更に、口座保有者同一性検証処理において使用されるべき同一性認証ポリシーと参加銀行識別番号（ＢＩＮ）情報とを口座認証システムに提供する。随意的に、発行者は、口座保有者ファイル１１８への先行ロードのために、口座保有者認証情報を口座認証システムに提供できる。先行ロードは、大量の口座保有者のサポートを容易にする。例えば、信頼機関が口座保有者の全部又は大部分を口座認証サービスで有効にしたい場合、信頼機関は、個人識別番号（ＰＩＮ番号）を全ての口座保有者に送ることができる。その後、ＰＩＮ番号は、先行ロード済みパスワードにアクセスするために、各口座保有者が使用できる。この方法では、各口座保有者は正式な加入処理を通過する必要がないため、加入処理が迅速化される。口座保有者が先行ロード済みパスワードを初めて使用した後、口座所有者は、新たな覚えやすいパスワードを指定するオプションを有する。
【００４４】
口座保有者認証情報は、企業ＩＤ、国コード、カード口座番号、カード有効期限、口座保有者名、「参加ＢＩＮ」データにおいて指定された発行者固有認証データ（例えば、母親の旧姓）といった情報と、請求先住所、発送先住所、社会保障番号、電話番号、勘定残高、取引履歴、及び運転免許証番号等、その他の情報とを含む。信頼機関は、更に、カード口座ポートフォリオに対する口座番号の範囲と、ＡＣＳのＩＰアドレス（ＵＲＬ）とをディレクトリサーバへ提供するべきである。口座認証システムの支払での応用に関して、サービスは、口座保有者の登録が可能な、銀行ブランドのｗｅｂサイトを介して提供できる。
【００４５】
図３は、一実施形態による、口座保有者が口座認証システムに登録する処理を示している。ステップ１に図示したように、口座保有者は、信頼機関、例えば、発行金融機関が維持する加入サーバインターネットｗｅｂサイトを訪れる。口座保有者は、自分の口座番号を登録することで、口座認証システムに登録する。例えば、支払取引により、口座保有者は、自分のクレジットカード、チェックカード、又はデビットカードの口座番号を登録できる。非支払取引に関して、口座保有者は、保険又は仲買会社で保有する口座番号を登録できる。口座保有者は、一枚以上のカードを登録できる
【００４６】
ステップ２において、口座保有者は、主要口座番号（ＰＡＮ）、名前、及びカード有効期限といった情報を入力する。この時点で、口座保有者は、追加情報を入力することもできる。例えば、住所、電子メールアドレス、買い物客ＩＤ、口座検証値、口座保有者固有パスワード、及び発行者固有認証情報を更に入力できる。この情報は、図４に示したページ３００のような加入ｗｅｂサイトのページに入力できる。
【００４７】
要求された情報を口座保有者が加入サイト１０８に入力した後、口座認証システムは、信頼機関が相互運用領域１０４のディレクトリサーバ１２８に登録したカード範囲内に口座保有者のＰＡＮが存在することを検証する。口座保有者の同一性は、様々な方法を使用して検証できる。第一に、先程述べたように、口座保有者の同一性は、要求者認証データベース、或いは信頼機関自身の認証データベースにより検証できる。追加として、検証は、信頼機関が提供する承認口座保有者１２０のファイルを使用し、状態チェック認証を信頼機関に送信し、応答を、金融機関が提供する先行ロード済み情報と比較することで実行できる。
【００４８】
ＰＡＮが加入カード範囲に含まれない場合、加入は拒否され、加入処理は終了する。支払取引において、ＰＡＮが加入カード範囲に含まれる場合、一ドル（又は他の任意の名目金額）の認証を、ＶｉｓａＮｅｔ等のサービス組織支払ネットワークを介して発行金融機関に提出する。一ドル取引の認証により、発行者は、カード口座状態を検証し、住所検証サービスを使用して住所を検証し、口座保有者検証値２（ＣＶＶ２）を検証できる。ＣＶＶ２は、支払カード裏面の署名欄に印刷された三桁の数字である。非支払取引では、ＰＡＮが加入カード範囲に含まれる場合、一ドル取引は必要ない。
【００４９】
ステップ３において、口座保有者は、口座保有者の同一性を対話式のリアルタイムオンラインセッションで検証するために、追加認証情報を求められる。一部の実施形態において、口座保有者は、認証取引中に口座保有者を認証するのに使用されるパスワードと「ヒントの質問及び回答」のペアとの入力を要求される。
【００５０】
ステップ４において、口座保有者の同一性が検証され、適切な応答が返送されると、認証メッセージが発行金融機関に送信される。次に、ステップ５において、加入サーバ１１２は、口座保有者情報をＡＣＳ１１４に渡し、口座保有者ファイル１１８内の記録を設定する。口座保有者ファイル１１８は、金融機関ＢＩＮ番号、口座番号、有効期限、姓名、運転免許証番号、請求先住所、社会保障番号、口座保有者のパスワード、口座保有者のパスワードの質問、口座保有者のパスワードの回答、口座保有者の電子メールアドレス、要求者の同一性スコア、その他の情報を格納できる。
【００５１】
一部の実施形態において、登録処理中、口座保有者には、個人保証メッセージ（ＰＡＭ）と呼ばれる語句の入力を求めることができる。ＰＡＭは、認証処理中に、信頼機関が口座保有者に後で提示する。信頼機関のみが口座保有者の指定ＰＡＭを知っているため、口座保有者に対して、口座認証システムで使用されるダイアログウィンドウが信頼機関から供給されたことを保証できる。ＰＡＭの例は、「空は青い」である。
【００５２】
口座保有者は、認証システムを使用するために、新しいクライアントソフトウェア又はデバイスを必要としないことに留意されたい。好適な実施形態において、口座保有者登録処理では、口座保有者と加入サーバとの間でインターネットを介して送信されるデータを保護するために、ＳＳＬチャネル暗号化等のセキュリティプロトコルを利用する。
【００５３】
更に、登録又は加入処理中、各信頼機関は、独自の「利用規約」及び／又は「データプライバシーポリシー」を表示できる。各信頼機関は、登録処理を完了するために、登録中の口座保有者に規約及びポリシーの承諾又は拒否のいずれかを求める能力を有する。各口座保有者が承諾した「利用規約」及び／又は「データプライバシーポリシー」のバージョン番号は、信頼機関が保存するべきである。
支払取引の説明
【００５４】
全ての参加者を設定し、口座保有者が登録した後、口座認証が実行される。図５は、口座保有者がインターネットに接続されたコンピュータを使用する、中心的な口座認証システムを使用した認証支払取引を説明している。図５のステップ１において、口座保有者は、インターネット上の販売者の電子商取引サイトを訪れる。支払取引では、口座保有者が保持する最も一般的なタイプの口座は何らかのクレジット、デビット、又はチェックカード口座であるため、口座保有者は、カード保有者と呼ぶこともできる。口座保有者が購入を希望する製品又はサービスを選択した後、口座保有者は、チェックアウト処理を開始し、チェックアウトフォームを記入し、その後、「購入」ボタンをクリックする。
【００５５】
「購入」ボタンを選択した後、図５のステップ２に図示したように、ＭＰＩが始動され、検証処理を実行して、口座保有者の固有口座が口座認証システムに登録されているかを判断する。ＭＰＩは、口座保有者が口座認証システムに登録されているかを様々な方法で判断できる。例えば、口座保有者に関連するディレクタサーバ及びＡＣＳをチェックする二段階処理と、ＡＣＳのみをチェックする処理と、ディレクトリサーバに保持されているものと同じ情報を含むキャッシュメモリを販売者がチェック可能な方法とを使用できる。
【００５６】
二段階処理について説明する。この説明では、図２を参照する。第一のステップにおいて、ＭＰＩは、カード口座番号を識別し、ディレクタサーバ１２８に問い合わせを行って、口座番号が口座認証システムの参加者である発行銀行に関連する番号の範囲内にあることを検証する。口座番号がディレクトリサーバ１２８で定義された口座番号範囲内に存在しない場合、発行者は登録されておらず、したがって口座保有者も登録されていない。この場合、口座番号が登録されていないことを販売者に通知し、ＭＰＩ１３４は、取引の制御を販売者の店頭ソフトウェアへ戻す。この時点で、販売者の店頭ソフトウェアは、通常通りに取引を進めること、口座保有者に対する更なるサービスを拒否すること、或いは、代替の支払方法で継続することが可能となる。
【００５７】
一方、口座番号がディレクトリサーバ１２８に存在する口座番号の範囲内にあると判断された場合、検証処理の第二のステップが開始される。検証処理の第二のステップは、口座番号が加入しているかを判断するためにディレクトリ１２８が口座番号をＡＣＳへ送信した時に開始される。カードが加入していない場合、加入処理は終了される。カードが加入していることをＡＣＳが示した場合、ＡＣＳは、ディレクトリサーバを介して、ＵＲＬインターネットアドレスをＭＰＩへ返送する。次に、ＭＰＩは、口座保有者クライアントデバイス及びその常駐ブラウザを介して、ＡＣＳを呼び出す。ここでも、口座認証システムに多数のＡＣＳが存在可能であることに留意されたい。
【００５８】
口座保有者が口座認証システムに登録されているかをチェックする第二の方法では、ＭＰＩ１３４が、最初にディレクトリサーバ１２８に問い合わせることなく、直接ＡＣＳ１１４に問い合わせる。第三の方法では、上記の通り、販売者は、ディレクトリサーバ１２８に保持されているものと同じ情報を含むキャッシュメモリを有する。これにより、販売者は、少なくとも予備的なチェックを実行できる。
【００５９】
二台以上の物理的ディレクトリサーバが口座認証システムに存在可能であることに留意されたい。しかしながら、論理的ディレクトリサーバが一台のみ存在することが好ましい。言い換えると、全てのディレクトリサーバは、同じ情報を含むという点において一致するべきである。
【００６０】
口座保有者が口座認証システムの参加者である場合、ＡＣＳ１１４は、口座保有者に対して銀行ブランドのウィンドウを表示する。銀行ブランドのウィンドウは、基本的な支払取引情報を含み、口座保有者に認証パスワード又はトークンを求める。口座保有者に認証パスワードを求める例示的なウィンドウ５００については図６を参照されたい。口座保有者は、自分の認証パスワードを入力し、ＡＣＳ１１４は、認証パスワードを検証する。ウィンドウ５００のサイズ及びレイアウトは、口座保有者が使用するデバイスのパラメータに応じて変化する。現在、一般的であるように、口座保有者は、認証パスワードの正確な入力を特定の回数だけ試行できる。口座保有者が認証パスワードを正確に入力できない場合には、口座保有者の登録処理中に設定されたヒント質問により、口座保有者に指示できる。好ましくは、口座保有者は、ヒント質問に対して正しい回答を入力する機会を一度与えられる。
【００６１】
正しい認証パスワード又はトークンが即座に入力された場合、或いは口座保有者がヒント質問に対して正しい応答を提供した場合、支払認証は継続する。次に、ＡＣＳは、発行者の署名キー又はサービスプロバイダのキーを使用した受取へのデジタル署名へ進む。この受取書は、販売者名、カード口座番号、支払額、及び支払日を含む。一部の実施形態において、受取書は、支払認証応答（ＰＡＲｅｓ）メッセージのコピー、或いはＰＡＲｅｓメッセージからコピーされた情報フィールドの少なくとも一部を有するメッセージである。認証履歴サーバ１３０は、取引データとして、販売者名、販売者ＵＲＬ、カード口座番号、有効期限、支払額、支払日、発行者の支払署名、及び口座保有者の認証検証値を格納する。ＡＣＳは、口座保有者のブラウザを介して、口座保有者をＭＰＩへリダイレクトする。この時点で、ＡＣＳは、販売者に対して、デジタル署名済み受取書と、口座保有者が認証された否かについての決定とを渡す。妥当性確認サーバ１３６は、取得者領域１０６において、支払受取書の署名に使用されたデジタル署名を検証するために、ＭＰＩ１３４に使用される。デジタル署名の検証後、口座保有者は、「認証済み」と見なされる。一部の実施形態において、取引完了後、口座保有者は、更に、自分のカード口座を再登録し、将来のオンライン購入で使用する新しいパスワードを作成する能力を有する。
【００６２】
ステップ３において口座保有者が認証された後、ステップ４では、特定の口座保有者の口座を許可する処理を開始する。許可とは、口座保有者が十分な信用を有し、特定の購入について良好な状態にあることを検証する処理を示す。対照的に、認証とは、口座保有者の同一性を検証する処理を示す。ステップ４において、販売者は、ＭＰＩを使用して、許可メッセージをＶｉｓａＮｅｔ等の支払ネットワークへ送信する。支払ネットワークは、次に、許可メッセージと電子商取引インジケータ（ＥＣＩ）とを、発行金融機関へ転送する。許可メッセージは、この技術で一般に知られているものと同様である。許可メッセージは、特定の口座が良好な状態にあり、支払取引の要求購入額に対して十分なクレジットラインを有することを発行金融機関が販売者に対して検証できるように、発行者へ送信される。ＥＣＩは、インターネットを介して取引が完了したことを示し、メッセージセキュリティ（即ち、心配のないチャネル暗号化（ＳＳＬ））のレベルと使用された認証とを示す。
【００６３】
代替の実施形態において、販売者は、追加情報を許可メッセージと共に提供できる。例えば、更に送信できる情報は、口座保有者が認証に成功したかを示すフラグと、口座情報と、デジタル署名と、口座保有者検証値２と、取引識別子と、チップカードＥｕｒｏｐａｙ、Ｍａｓｔｅｒｃａｒｄ、及びＶｉｓａ（ＥＭＶ）暗号文で認証されたオフラインＰＩＮと、販売者に保証された支払を提供するのに必要なフィールドとである。発行金融機関の許可取引処理が完了した後、支払取引の制御は、支払ネットワークを介して、販売者の店頭ソフトウェアへ戻される。次に、発行者は、支払ネットワークを介して、許可応答を販売者へ返送する。図５のステップ５において、発行金融機関は、取引を許可又は拒絶する。一部の実施形態において、許可メッセージは、バッチ処理を行って、後の時点でまとめて送信できる。認証情報は、バッチ許可メッセージにも含まれる。
【００６４】
取引識別子は、口座保有者を認証したＡＣＳにより作成され、一定の支払カードと、そのカードからの特定の支払取引とに固有の値である。発行者は、後に紛争が生じた時等、様々な目的で、取引識別子を使用して認証済み支払取引を一意に識別する。取引識別子は、特定のオンライン取引に関連するもの等、記録を一意に識別するのに適した多数のデータ形態を取ることが可能である。支払取引等、いくつかの実施の一つにおいて、取引識別子は、カード認証検証値（ＣＡＶＶ）である。以下の説明において、取引識別子はＣＡＶＶと呼ばれる場合があるが、しかしながら、様々な種類の処理識別子も利用できることに留意されたい。
【００６５】
アクセス制御サーバ（ＡＣＳ）１１４は、他の様々な機能が可能である。例えば、ＡＣＳは、登録口座をデータベースから無効化できる。口座は、口座保有者又は発行者が、手動で無効化できる。ＡＣＳ１１４は、口座保有者が交換用カードを受取時に、簡略化された更新登録処理を提供できる。ＡＣＳ１１４は、固有のアクセス制御情報を備えた、同じ登録口座の多数のユーザをサポートできる。支払取引又は口座更新のために、ユーザにＡＣＳ１１４への接続を提供する時、ＡＣＳ１１４は、パスフレーズ、デジタル署名、オンラインＰＩＮ番号、及び／又はチップカードＥＭＶ暗号文のオフラインＰＩＮ番号の一つ以上の機構を介して、登録口座の許可口座保有者として、ユーザの妥当性を確認できる。
【００６６】
販売者１３２は、販売者がファイル上に口座保有者の口座情報を有する既存のシステムとの相互運用を行い、既存の販売者許可及び結成システムとの相互運用を行い、多数の販売者にサービスを提供する第三者をサポートし、販売者及び取得者間の様々な支払インタフェースをサポートし、電子商取引インジケータ（ＥＣＩ）の値を設定する時に、取得者から支払ネットワーク許可メッセージに対する強制的な影響を最小化することができる。
【００６７】
取引を販売者からＡＣＳへ送る一方法は、口座保有者の口座番号に基づいてサーバのアドレスを提供するディレクトリを有することである。こうした方法において、情報を送る要求は、認証された販売者からのみ受け付けられる。販売者からのアクティビティが、正常なアクティビティを上回る場合、口座認証システムは、アクセスが有効でなくなったことを示す取得者を有する販売者に対して、アクセスを拒否できる。これは、販売者の詐欺があり得るとみなされた場合に該当する。口座認証システムには販売者認証を配備可能だが、配備は必須ではない。販売者認証は、販売者の詐欺を最小化するのに役立つ。
【００６８】
図７は、一実施形態による、消費者がインターネットに接続されたコンピュータを使用する、中心的な口座認証システムを使用した支払取引中に送信される、具体的なメッセージを示している。図７のメッセージは、図２に示した支払システムアーキテクチャに重ねている。メッセージと、それぞれのメッセージ内のデータフィールドとには、具体的な名称が記載されているが、こうした名称は認証プロトコルの性能に影響しないことを理解されたい。したがって、以下に説明するメッセージ及びデータフィールドには様々な名称を割り当て可能である。更に、本発明の代替実施形態において、図７において説明した具体的なメッセージは、変更又は省略が可能であり、及び／又は、認証プロセスの全体的な目標に影響を与えることなく、追加メッセージを追加できる。機能の追加及び通信の合理化といった様々な目的で、様々なメッセージを変更、追加、又は省略できる。更に、本明細書全体で説明するプロセスのメッセージフローは、代替実施形態において、上記のような利用で変更可能である。
【００６９】
上記のように、支払取引は、口座保有者がブラウザを介して販売者のｗｅｂサイトを訪問し、購入する品目を選択した時に開始される。販売者の支払システムは、口座保有者に支払情報の入力を求める。一般に、支払情報の入力は、安全な環境で、例えば、ＳＳＬ暗号化プロトコルを使用して行われるべきである。口座保有者が取引を確定させる準備が出来たことを示した時、販売者の支払システムは、ＭＰＩ１３４を呼び出す。次に、線１ａにより示したように、ＭＰＩ１３４は、口座保有者のＰＡＮを含み得るＡＣＳの特定のＵＲＬについてディレクトリサーバ１２８をチェックし、口座保有者がサービスに加入していることを検証する。代替として、ＭＰＩ１３４は、この情報を含む自らのキャッシュメモリをチェックする。ＭＰＩ１３４は、更にＡＣＳ１１４をチェックし、口座保有者のＰＡＮが口座認証システムに登録されていることを検証する。ＭＰＩ１３４が自分のキャッシュをチェックできる場合、ＭＰＩ１３４は、ディレクトリ１２８の内容をローカルキャッシュにコピーする能力を有するべきである。この能力を使用する場合、販売者は、口座が加入範囲の一部であるかをキャッシュから即座に判断できる。販売者がこの機能を実施する場合、キャッシュの内容は、少なくとも２４時間毎に期限切れとなり、更新されるべきである。キャッシュは、ＭＰＩ１３４がロードされた時、及びその後一定時間毎に要求されるべきである。
【００７０】
ＭＰＩ１３４は、口座保有者のＰＡＮを使用して検証加入要求（ＶＥＲｅｑ）をフォーマットすることで、ＰＡＮを検索する。既に確立されていない場合、ＭＰＩ１３４は、ディレクトリサーバ１２８又はＡＣＳ１１４との安全な接続を確立し、これらに対して自らを認証する。ＭＰＩ１３４は、様々な位置で、口座保有者のＰＡＮに対応するカード範囲エントリを検索する。
【００７１】
ＭＰＩ１３４が検索を実行した後、ＶＥＲｅｑメッセージは、線１ｂに示したように直接的に、或いは、線１ｂに示したように最初にディレクトリサーバを通過した後、ＡＣＳ１１４へ送信される。ＶＥＲｅｑメッセージがディレクトリサーバ１２８を介してＡＣＳ１１４へ送信された後、ディレクトリサーバ１２８は、ＶＥＲｅｑメッセージに含まれる口座保有者のＰＡＮに対応するレコードを検索する。一致が不成功である場合、ディレクトリサーバ１２８は、ＵＲＬ値（群）無しで検証加入応答（ＶＥＲｅｓ）メッセージをフォーマットし、ＰＡＮ加入のステータス又はＶＥＲｅｓステータスの値を「Ｎ」に設定する。ＶＥＲｅｓメッセージは、その後、ＭＰＩに戻される。一方、一致に成功した場合、既に確立されていない場合、ディレクトリサーバ１２８は、ＡＣＳのＵＲＬとの安全な接続を確立し、これに対して自らを認証する。その後、ＶＥＲｅｑメッセージは、ＡＣＳのＵＲＬに転送される。そのＵＲＬが利用できない場合、ＭＰＩは、（可能な場合）次のＡＣＳのＵＲＬ値に進み、最大五個のＡＣＳのＵＲＬの検索を可能にするべきである。当然ながら、試行されるＵＲＬの数は可変である。全ての試行で不成功となった場合、ＶＥＲｅｓメッセージは、口座認証システムを使用して支払取引が処理できないことを販売者に対して示すために、ＶＥＲｅｓステータスが「Ｎ」に設定された状態で、ＭＰＩに戻される。
【００７２】
ＶＥＲｅｑメッセージがＡＣＳ１１４に受け取られた後、ＡＣＳは、ＶＥＲｅｑメッセージから口座保有者のＰＡＮを受け付け、口座保有者ファイル１１８に照らして検証する。一致が成功した場合、ＡＣＳは、ＰＡＮ加入のステータスを「Ｙ」に設定し、ＡＣＳ１１４が内部的にＰＡＮに関連付けるシングルユースのプロキシＰＡＮを作成し、ＵＲＬフィールド（群）をＶＥＲｅｑメッセージ内に配置する。一致が不成功である場合、ＡＣＳは、ＰＡＮ加入のステータスを「Ｎ」に設定する。したがって、線２ａに示したように、ＡＣＳは、ディレクトリサーバ１２８を介して、ＶＥＲｅｓメッセージをＭＰＩへ戻される。ＶＥＲｅｑメッセージがＡＣＳへ直接送信される場合、ＶＥＲｅｓメッセージは、線２ｂに示したように、ＭＰＩへ直接返送される。
【００７３】
ディレクトリサーバ１２８のデータをＭＰＩ１３４でキャッシュすることにより、ＣＲＲｅｑ及びＣＲＲｅｓメッセージペアの利用を容易にできる。ＣＲＲｅｑメッセージは、ＭＰＩのキャッシュを更新するために、ＭＰＩからディレクトリサーバへ送信され、関与するカード範囲のリストを要求する。ＣＲＲｅｓメッセージは、関与する範囲を含む応答である。
【００７４】
一部の実施形態において、口座認証システムは、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージペアを使用して分散認証能力を口座保有者のクライアントデバイスが有するかを確認する。ＭＰＩは、クエリであるＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑメッセージを口座保有者クライアントデバイス１２２に対してフォーマット及び送信し、分散口座認証用口座保有者モジュールが常駐しているかを判断する。ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑメッセージの送信は、線３により図７に図示している。任意の分散認証オプションがＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージにより戻された場合、ＭＰＩは、口座保有者クライアントソフトウェアと直接通信し、認証ステップを実行する。ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージの送信は、線４により図７に図示している。追加として、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージを使用することで、以下に説明するＶＥＲｅｑ及びＶＥＲｅｓメッセージを除去してよい。口座保有者クライアントソフトウェアは、発行者のＡＣＳのＵＲＬをソフトウェアに埋め込んで配置できる。ＭＰＩは、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージを最初に完了させる。口座保有者クライアントソフトウェアが検出された場合、ＶＥＲｅｑ及びＶＥＲｅｓメッセージを実施することなく、ＰＡＲｅｑメッセージをＡＣＳ又は口座保有者クライアントソフトウェアに送信できる。
【００７５】
ＶＥＲｅｓステータスが「Ｙ」に等しくない値を有する場合、販売者には、口座認証システムを使用して支払取引を処理できないことが通知される。しかしながら、ＶＥＲｅｓステータスが「Ｙ」の値を有する場合、ＭＰＩ１３４は、支払認証要求メッセージ（ＰＡＲｅｑ）をフォーマットする。ＭＰＩ１３４は、線５に示したように、口座保有者クライアントデバイスブラウザを介して、ＰＡＲｅｑメッセージを発行者のＡＣＳサーバへ送信する。
【００７６】
ＭＰＩがＰＡＲｅｑメッセージを発行者のＡＣＳに渡した後、ＡＣＳは、口座保有者に対してウィンドウを表示する。ウィンドウは、支払認証応答（ＰＡＲｅｑ）メッセージに含まれる支払の詳細を、発行者のロゴ、サービス組織のマーク又はブランドロゴ、販売者名、販売者の場所（ＵＲＬ）、合計購入金額及び通貨、購入日、カード番号、分割／定期循環支払条件、注文に関する説明又は説明へのリンク、販売の特殊条件又はこの情報へのリンク、個人保証メッセージ、口座保有者のパスワード又は他の任意の種類の認証トークンの要求といった他の項目に加えて表示する。
【００７７】
ＡＣＳは、口座保有者に適切なパスワードの入力を求める。ＡＣＳは、口座保有者の入力を受け付け、口座保有者ファイル１１８に照らして検証する。口座認証システムでは、例えば、正しいパスワードを入力する試行の失敗を一定回数（例えば、三回）認める。当然ながら、認める試行回数は変更できる。最終の試行失敗後、口座認証システムは、ヒント質問を表示してよい。口座保有者は、正しいヒント質問の応答を入力する必要がある。その後、口座保有者に関連するヒント質問が表示される。口座保有者は、正しい応答の入力を少なくとも一度試行できる。口座保有者が不正確な応答を提供した場合、口座認証システムを使用した取引を完了できないことを販売者に通知できる。口座保有者が正しい応答を提供した場合、パスワードが一致したかのように取引を処理するべきである。口座番号に対して二つ以上のエントリが存在する場合には、様々な口座保有者名がドロップダウンウィンドウに表示されることに留意されたい。その後、口座保有者は、自分の名前を選択できる。
【００７８】
パスワードの一致後、ＡＣＳは、ＰＡＲｅｓメッセージを作成してデジタル署名する。ＡＣＳは、更に、ＳａｖｅＲｅｃｅｉｐｔメッセージを生成し、線７で示したように、認証履歴サーバ１３０及び受取マネージャ１３１に送信する。線７ａで示したように、ＳａｖｅＲｅｃｅｉｐｔメッセージは、発行者がリアルタイムで支払許可要求と支払者認証取引とを照合できるように、認証履歴サーバ１３０から発行者許可及び清算システム１３８へ渡してもよい。ＳａｖｅＲｅｃｅｉｐｔメッセージを発行者許可及び清算システム１３８へ送信することで、発行者は、認証要求が認証済みの購入に関するものかを同時に判断できる。次に、ＡＣＳは、線６で示したように、署名済みのＰＡＲｅｓメッセージをＭＰＩへ再びリダイレクトする。
【００７９】
署名済みＰＡＲｅｓメッセージをＭＰＩ１３４へ返送した後、ＭＰＩ１３４を再始動させる。認証ステータスが「Ｙ」である場合、ＭＰＩ１３４は、ＰＡＲｅｓメッセージを妥当性確認サーバ１３６へ送信する。妥当性確認サーバの機能がＭＰＩ１３４によって提供される場合、ＭＰＩ１３４は、ＰＡＲｅｓメッセージの署名の妥当性を確認し、署名妥当性確認の結果を戻す。署名の妥当性が確認できない場合、ＭＰＩ１３４は、口座認証システムを使用して取引を処理できないことを販売者に通知する。認証ステータスが「Ｎ」である場合、販売者は、口座保有者に追加情報を求めるプロンプトを送信するか、異なる支払カード又は支払い形態を使用することを口座保有者に要求するか、或いは非認証支払取引として支払取引を処理するべきである。
【００８０】
取得者領域１０６が妥当性確認サーバを含む場合、妥当性確認サーバ１３６は、ＰＡＲｅｓメッセージの署名の妥当性を確認する。妥当性確認サーバ１３６は、その後、署名妥当性確認の結果をＭＰＩ１３４へ戻す。署名の妥当性が確認できない場合、ＭＰＩは、口座認証システムを使用して取引を処理できないことを販売者に通知する。一方、署名の妥当性が確認された場合、販売者は、認証支払の許可を進める。ＰＡＲｅｓメッセージは、線６ａで示したように、販売者から取得者支払プロセッサ１４０に渡してもよい。ＰＡＲｅｓメッセージは、その後、取得者から電気通信ネットワーク１４２を介して、発行者へ渡してよい。したがって、支払者認証結果は、標準の支払許可プロセスの一部として、発行者が利用可能になる。
【００８１】
次に、様々な伝送チャネルに関連するセキュリティ問題について説明する。基本線として、全ての伝送チャネルは、好ましくは、１２８ビットＳＳＬを使用して暗号化される。口座保有者と販売者との間のチャネルは、二つのチャネルを含む。販売者は、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、口座保有者が支払情報を入力する時に使用される接続を確保するべきである。販売者は、更に、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、ＰＡＲｅｓメッセージを口座保有者からＭＰＩへ転送する時に使用される接続を確保するべきである。
【００８２】
口座保有者とＡＣＳとの間のチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、ＡＣＳによって暗号化されるべきである。このチャネルは二つの目的で使用される。第一に、ＰＡＲｅｑメッセージをＭＰＩからＡＣＳへ送信するためであり、第二に、署名済みＰＡＲｅｓメッセージをＡＣＳから口座保有者へ送信するためである。
【００８３】
口座保有者と加入サーバとの間のチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書を使用して、加入サーバによって暗号化されるべきである。このチャネルは、口座保有者の加入情報を受け付けるのに使用される。
【００８４】
販売者とディレクトリサーバとの間、及びディレクトリサーバとＡＣＳサーバとの間のチャネルは、ＶＥＲｅｑ及びＶＥＲｅｓメッセージに含まれるＰＡＮデータと、ＶＥＲｅｓメッセージに含まれるＡＣＳのＵＲＬアドレスとを保護するために、サービス組織が発行したＳＳＬ暗号化証明書により確保するべきである。
【００８５】
ＡＣＳと口座保有者との間のチャネルは、口座保有者のパスワードに対するプロンプトと、口座保有者が入力したパスワードとを保護するために暗号化されるべきである。このチャネルは、サービス組織が承認した認証局から入手したＳＳＬ証明書により保護されるべきである。
【００８６】
殆どの取引について、支払認証要求及び応答メッセージは、一部として、メッセージバージョン番号と、販売者識別子と、販売者国コードと、注文番号と、購入日と、購入額と、取引ステータスと、購入条件とを含むフィールドを含んでいる。更に、ＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージは、通常、一部として、メッセージバージョン番号、販売者名、注文番号、購入日、購入額、カード有効期限、取引ステイン等のフィールドを含む。こうしたメッセージは、ＸＭＬ（拡張マークアップ言語）形式にできる。
【００８７】
非購入認証取引において、支払認証要求、支払認証応答、及びＱｕｅｒｙＡｃｃｏｕｎｔ ｈｏｌｄｅｒＲｅｓメッセージは、メッセージ拡張フィールドを含むことができる。この技術において周知であるように、メッセージ拡張フィールドは、拡張を添付するメッセージに関する追加要素を定義するデータフィールドである。こうした追加要素は、非支払取引を含む特定の取引を更に容易にするために使用できる。
【００８８】
提供対価構成要素による口座認証処理
図８は、対価提供の態様を含むオンライン口座認証に関連するシステムアーキテクチャの例と、一組のメッセージフローとを示す。対価提供の態様は、口座認証処理を介して数周した情報を対価提供者と共有することに関与する。こうした情報は、利用者に関係し、発行者又は信頼機関及び要求者が収集可能である。利用者情報は、利用者１２２の認証の根拠として供給されるため、高い完全性という価値を有する。利用者情報は、特定のオンライン取引を識別し、情報が本発明の認証処理に由来することを示す取引識別子によりマーク付けできる。対価提供情報は、一部の例として、出荷、後続販売、セキュリティチェック、及びワークフロー管理に関連する様々な目的で、対価提供者１９６が使用できる。関与する全関係者は、利用者情報を共有から利益を享受可能であり、各関係者は、価値の取得を互いにどのように支援できるかについて合意できる。例えば、要求者と対価提供者とは、利用者情報の共有に基づく追加契約条項に合意できる。
【００８９】
次に、利用者情報を対価提供者１９６へ送信することを含む認証処理について、図８を参照して説明する。図８について、支払取引に基づいて説明する。この説明に続いて、図８を、非支払取引に基づくものとして更に説明する。図８は、図７のメッセージを簡略化した形態で表している。
【００９０】
図８の口座認証システムアーキテクチャは、発行者領域１０２と、相互運用領域１０４と、取得者領域１０６と、対価提供領域１０７とを含む。発行者領域１０２は、利用者１２２と、ＡＣＳ１１４と、発行者１９０とを含む。利用者１２２は、人間の利用者と、利用者クライアントデバイス、例えば、コンピュータ端末又はモバイルコンピューティングデバイスとを表す。発行者１９０は、利用者１２２に対して支払カードを発行可能なカード発行銀行を表す。相互運用領域１０４は、この例においてＶｉｓａによって制御されるディレクトリであるＶｉｓａディレクトリ１２８と、認証履歴サーバ１３０と、ＶｉｓａＮｅｔ１９４とを含む。取得者領域１０６は、要求者１３２と、ＭＰＩ１３４と、取得銀行１９２とを含む。要求者１３２は、様々な種類の関係者にできるが、しかしながら、要求者１３２は一般に販売者であるため、販売者という用語を要求者の代わりに使用できる。対価提供領域１０７は、対価提供者１９６と、価値付加制御サーバ１９８とを含む。
【００９１】
図８の支払取引は、番号１乃至１４の方向矢印により説明する。支払取引は、ステップ１において、利用者が販売者のｗｅｂサイトをブラウズし、購入を希望する品目をショッピングカートに追加し、購入を確定する時に開始される。この時点で、販売者１３２は、ＰＡＮ、有効期限、及び住所情報を含め、支払取引を続けるのに必要なデータを有している。
【００９２】
ステップ２において、ＭＰＩ１３４は、利用者の主要口座番号（該当する場合は、更にデバイス情報）をＶｉｓａディレクトリサーバ１２８へ送信し、利用者のＰＡＮが口座認証システムに加入しているかをチェックする。この処理は、販売者チェックアウト処理中、利用者からの最終の「購入」クリック確認後に発生する。「購入」クリックが行われた後、販売者のソフトウェアは、ＭＰＩ１３４を呼び出し、検証加入要求（ＶＥＲｅｑ）メッセージをフォーマットする。ＭＰＩ１３４は、現在、Ｖｉｓａディレクトリサーバ１２８との安全な接続を有しているかを判断する。安全な接続が確立されていない場合、ＭＰＩ１３４は、Ｖｉｓａディレクトリサーバ１２８とのＳＳＬ接続を確立する。販売者１３２がＳＳＬクライアント証明書を発行したことをＶｉｓａディレクトリサーバ構成が示す場合、Ｖｉｓａディレクトリサーバ１２８は、販売者１３２に対して、ＳＳＬセッションの確立中にＳＳＬクライアント証明書を提示することを求める。安全な接続が確立された後、ＭＰＩ１３４は、ＶＥＲｅｑメッセージをＶｉｓａディレクトリサーバ１２８へ送る。様々な実施形態において、様々な購入注文確認処理を使用して「購入」クリック確認を完了できることに留意されたい。
【００９３】
ＶＥＲｅｑメッセージは、認証処理中に送信される他の任意のメッセージと共に、オンライン認証処理が対価提供者との利用者情報の共有を伴うことを表すインジケータを含むことができる。
【００９４】
ステップ３において、関与するカード範囲内にＰＡＮが存在するとＶｉｓａディレクトリサーバ１２８が判断した場合、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳ１１４等の適切なＡＣＳへの問い合わせを行い、ＰＡＮについて認証（又は認証の試行の証明）が可能であるかを判断する。この処理は、Ｖｉｓａディレクトリサーバ１２８がＭＰＩ１３４からＶＥＲｅｑメッセージを受取した後で発生する。
【００９５】
関与するカード範囲内にＰＡＮが存在することをＶｉｓａディレクトリサーバ１２８が検証するために、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージデータの妥当性を確認し、特定の要件が満たされることを確定する。第一に、取得者ＢＩＮは、参加取得者を表すべきである。第二に、販売者ＩＤは、取得者ＢＩＮによって特定された取得者の参加販売者を表すべきである。第三に、取得者のＶｉｓａ領域で、口座認証サービスのために販売者のパスワードが必要となる場合、パスワードの値が受け取られているべきであり、パスワードは、取得者ＢＩＮと販売者ＩＤとの組み合わせに対して有効となるべきである。こうした要件のいずれかが満たされない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性と、無効要求メッセージとを含む検証加入応答（ＶＥＲｅｓ）をフォーマットする。このＶＥＲｅｓは、口座識別子、ＡＣＳのＵＲＬ、及び支払プロトコルのデータフィールドを含まないことに留意されたい。Ｖｉｓａディレクトリサーバ１２８がＶＥＲｅｓメッセージをＭＰＩ１３４へ返した後、支払取引は、様々な形で進む可能性がある。例えば、支払取引は完全に終了する可能性があり、支払取引は非認証取引として進む可能性があり、或いは、利用者は異なる口座番号の使用を試行できる。
【００９６】
Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージにおいて受け取った利用者ＰＡＮを含むカード範囲を指定するレコードを検索する。利用者ＰＡＮが見つからない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３４へ返送し、口座認証は、以下説明するように、再び停止可能点に達する。
【００９７】
利用者ＰＡＮがＶｉｓａディレクトリサーバ１２８において見つかった場合、Ｖｉｓａディレクトリサーバ１２８は、現在、適切なＡＣＳとの安全な接続を有しているかを判断する。安全な接続が確立されていない場合、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳとのＳＳＬ接続を確立する。Ｖｉｓａディレクトリサーバ１２８のＳＳＬクライアント証明書と、ＡＣＳのサーバ証明書とについては、ＳＳＬセッションの確立中に提示及び妥当性確認が行われるべきである。試行された第一のＵＲＬが利用できない場合、連続する各ＵＲＬ値が試行される（提供された場合）。Ｖｉｓａディレクトリサーバ１２８は、各ＡＣＳに対して随意的に構成可能な四つまでの代替ＵＲＬへの接続を試行できる。Ｖｉｓａディレクトリサーバ１２８がそれぞれの試行でＵＲＬに接続できない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含むが、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、又は無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３４へ返送し、口座認証処理は停止可能点に達する。
【００９８】
ＵＲＬとの接続に成功した後、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｑメッセージからパスワードフィールドを除去し、メッセージをＡＣＳのＵＲＬへ転送する。
【００９９】
ステップ４において、ＡＣＳ１１４は、ＰＡＮに関する認証が可能であるかを判断し、その後、Ｖｉｓａディレクトリサーバ１２８に対して判断を示す。この処理は、ＡＣＳがＶｉｓａディレクトリサーバ１２８を介してＶＥＲｅｑメッセージを受取後に発生する。ＡＣＳ１１４は、ＶＥＲｅｑの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。支払取引を認証できない時、代わりに認証の試行の証明を提供できる場合があることに留意されたい。ＡＣＳ１１４は、ＶＥＲｅｑメッセージからの利用者ＰＡＮを使用して、ＡＣＳ１１４内に位置する利用者データベースに問い合わせ、利用者が加入しているかを判断する。ＰＡＮが見つからない場合、ＡＣＳ１１４は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。その後、ＡＣＳ１１４は、ＶＥＲｅｓメッセージをＶｉｓａディレクトリサーバ１２８へ送信する。
【０１００】
ステップ５において、Ｖｉｓａディレクトリサーバ１２８は、ＡＣＳ１１４の判断をＭＰＩ１３４へ転送する。Ｖｉｓａディレクトリサーバ１２８の観点では、この処理は、Ｖｉｓａディレクトリサーバ１２８がＶＥＲｅｑメッセージをＡＣＳのＵＲＬへ転送した後に発生する。ＡＣＳ１１４の観点では、この処理は、ＡＣＳ１１４がＶＥＲｅｓメッセージをＶｉｓａディレクトリサーバ１２８へ送信した後に発生する。
【０１０１】
Ｖｉｓａディレクトリサーバ１２８は、対応するＶＥＲｅｓ又はエラーを含むＶＥＲｅｓメッセージを読む。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージの構文の妥当性を確認し、妥当性確認に失敗した場合にＡＣＳ１１４へエラーを返す。ＡＣＳから受け取ったメッセージが構文的に正しい場合、Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓ又はエラーをＭＰＩ１３４へ転送する。ＡＣＳから受け取ったしたメッセージが構文的に正しくない場合、Ｖｉｓａディレクトリサーバ１２８は、「Ｎ」に設定されたＰＡＮ認証可能性を含み、口座識別子、ＡＣＳのＵＲＬ、支払プロトコル、及び無効要求を含まないＶＥＲｅｓメッセージをフォーマットする。Ｖｉｓａディレクトリサーバ１２８は、ＶＥＲｅｓメッセージをＭＰＩ１３２へ返し、場合によっては口座認証処理を停止する。ＭＰＩ１３４の観点では、この処理は、ＭＰＩ１３４がＶＥＲｅｑメッセージをＶｉｓａディレクトリサーバ１２８へ送った直後に発生する。Ｖｉｓａディレクトリサーバ１２８の観点では、この処理は、ＶｉｓａディレクトリサーバがＶＥＲｅｓメッセージをＭＰＩへ転送した直後に発生する。ＭＰＩ１３４は、対応するＶＥＲｅｓ又はエラーを含む応答を読む。エラーメッセージが受け取られた場合、口座認証処理を停止となり得る。
【０１０２】
上記の様々な理由により口座認証が終了となり得るポイントにおいて、販売者は、チェックアウト処理から利用可能な情報を使用して、通常の支払許可を進めることができる。この場合、販売者の支払システムは、この文書の範囲から外れた非認証電子商取引処理として、取引を処理するべきである。電子商取引インジケータは、認証の結果及びチェックアウト処理の特性に対応する値に設定されるべきであることに留意されたい。チェックアウト処理中に利用者が選択した口座を使用して、販売者が認証取引を処理できない場合、販売者は、取引を中止するか、或いは代替口座を選択するオプションを顧客に与えることができる。代替口座が選択された場合には、認証処理を繰り返すことができる。
【０１０３】
代替実施形態では、Ｖｉｓａディレクトリサーバの内容を販売者１３２のローカルキャッシュメモリデバイスへコピーすることにより、各支払取引で利用者の口座認証システムへの参加を検証するためにＶｉｓディレクトリサーバに問い合わせる必要性（ステップ２乃至５）は回避できる。この機能を使用する場合、販売者１３２は、口座が加入範囲の一部であるかを、キャッシュから即座に決定できる。この販売者１３２のローカルキャッシュを使用する代替手法は、ＭＰＩ１３４がカード範囲要求（ＣＲＲｅｑ）メッセージをフォーマットし、Ｖｉｓａディレクトリサーバ１２８へ送信することで開始される。キャッシュのロードが今回初めて行われる場合（或いは、キャッシュが消去されており、再ロードする必要がある場合）、ＣＲＲｅｑにはシリアル番号要素が含まれておらず、その結果、Ｖｉｓａディレクトリサーバ１２８は、関与するカード範囲の全リストを返送する。その他の場合に、ＭＰＩ１３４は、直前に処理されたＣＲＲｅｓからのシリアル番号を含め、その結果、Ｖｉｓａディレクトリサーバは、以前のＣＲＲｅｓからの変更のみを返送する。シリアル番号は、Ｖｉｓａディレクトリサーバ１２８のカード範囲データベースの現在の状態を定義する値である。Ｖｉｓａディレクトリサーバ１２８は、ＭＰＩ１３４にシリアル番号を提供する。特定の番号は、それを返送した特定のＶｉｓａディレクトリサーバにとってのみ意味を有する。
【０１０４】
Ｖｉｓａディレクトリサーバ１２８は、ＣＲＲｅｑの構文の妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。Ｖｉｓａディレクトリサーバ１２８は、関与する範囲を含むカード範囲応答をフォーマットし、ＭＰＩ１３４へ送信する。Ｖｉｓａディレクトリサーバ１２８は、応答にシリアル番号を含める。ＭＰＩ１３４は、この値を保持し、翌日のＣＲＲｅｑメッセージに含めるべきである。ＭＰＩ１３４は、ＣＲＲｅｓの構文の妥当性を確認し、妥当性確認に失敗した場合、Ｖｉｓａディレクトリサーバ１２８にエラーを送信するべきである。ＭＰＩ１３４は、ローカルキャッシュを更新する。リストは、アクション要素が示す追加又は削除された範囲により、返送された順序で処理するべきである。ＣＲＲｅｓがシリアル番号についてエラー状態を示す場合、ＭＰＩはキャッシュを消去し、シリアル番号のないＣＲＲｅｑを提出するべきであることに留意されたい。
【０１０５】
利用者のＰＡＮについて認証が可能である時、ＭＰＩ１３４は、１２２の利用者クライアントデバイスを介して、支払者認証要求（ＰＡＲｅｑ）メッセージをＡＣＳ１１４へ送信する。ステップ６は、利用者クライアントデバイス１２２へ送信されたＰＡＲｅｑメッセージを表す。この処理は、ＭＰＩ１３４がＶｉｓａディレクトリサーバ１２８からＶＥＲｅｓメッセージを受取直後に発生する。ＭＰＩ１３４は、ＶＥＲｅｓの構文の妥当性を確認し、妥当性確認に失敗した場合、Ｖｉｓａディレクトリサーバにエラーを送信するべきである。ＭＰＩ１３４は、ＶＥＲｅｓにおいて受け取った口座識別子を含むＰＡＲｅｑメッセージをフォーマットする。
【０１０６】
この認証プロセスの実施形態は、販売者１３２と発行者１９０との間で利用者関連情報を共有することを含む。発行者１９０及び販売者１３２のそれぞれは、単一又は多数の取引において、利用者に関する広範な情報を収集できる。こうした情報は、特定の利用者の購買習慣に関する情報を含む可能性がある。こうした情報は、販売者１３２、発行者１９０、及び対価提供者１９６といった様々な関係者にとって有用となる可能性がある。こうした顧客情報は、ＰＡＲｅｑ及びＰＡＲｅｓメッセージ内にこうした情報を含めることで、認証処理中に、販売者１３２と発行者１９０との間で共有できる。したがって、ステップ６において、販売者１３２は、利用者１２２に関する情報をＰＡＲｅｑメッセージに含めることができる。
【０１０７】
ＭＰＩ１３４は、次のフィールドを含むフォームを構築する：ＰＡＲｅｑ、最終的な返答を送るべき販売者ＵＲＬであるＴｅｒｍＵｒｌ、及びＭＤ（「販売者データ」）フィールド。ＭＤフィールドは、販売者に返送するべき販売者状態データを含む。このフィールドは、販売者システムがセッション状態を扱う様々な方法に対応するために使用される。販売者システムが、何らかの更なる支援なしに、最終ポストを元のショッピングセッションに関連づけできる場合、ＭＤフィールドは空になり得る。販売者システムが一定のショッピングセッションに対する状態を維持しない場合、ＭＤは、販売者がセッションを継続するのに必要なあらゆるデータを運ぶ。このフィールドの内容は販売者の実施により変化するため、ＡＣＳは、内容に関する仮定を含まずに、フィールドを変化させずに維持するべきである。
【０１０８】
ＭＰＩ１３４は、利用者のブラウザにフォームをＡＣＳへポストさせることで、利用者のブラウザを介して、ＰＡＲｅｑをＶＥＲｅｓにおいて受け取られたＡＣＳのＵＲＬへ渡す。全ての接続は、利用者のブラウザに対応するためにＨＴＰＰＳとなる。
【０１０９】
ステップ７は、利用者クライアントデバイス１２２からＡＣＳ１１４へ送信されるＰＡＲｅｑメッセージを表す。この処理は、ＡＣＳ１１４がＭＰＩ１３４からＰＡＲｅｑを含むポストを受取後で発生する。以下の説明は、パスワードを使用して利用者認証が実行される場合に該当する。チップカード上のアプリケーションに依存するもの等、その他の方法も使用してよい。ＡＣＳ１１４は、ＰＡＲｅｑメッセージの妥当性を確認し、妥当性確認に失敗した場合にエラーを返す。妥当性確認に失敗した場合、ＡＣＳ１１４は、「Ｎ」に設定した取引ステータスと無効要求とを有するＰＡＲｅｓメッセージをフォーマットする。
【０１１０】
ステップ８において、ＡＣＳは、ＰＡＮに適用可能な処理を使用して利用者を認証する。こうした処理は、発行者１９０と利用者１２２との間で事前に設定されたパスワード又はＰＩＮを要求すること、及び利用者にデータ課題を提示すること等の手法を一部として含む。データ課題は、例えば、利用者又は利用者クライアントデバイス１２２の同一性を認証する特定のデータ応答を利用者クライアントデバイス１２２が提供するのをＡＣＳ１１４が要求することを含む可能性がある。一シナリオにおいて、ＡＣＳ１１４は、利用者１２２を認証する特定の暗号文をクライアント利用者デバイスが作成することを要求できる。代替として、ＡＣＳ１１４は、認証の試行の証明を生成できる。その後、ＡＣＳ１１４は、適切な値でＰＡＲｅｓメッセージをフォーマットし、応答メッセージにデジタル署名を付与する。ＡＣＳ１１４は、パスワード、データ応答、又は暗号文を、ＡＣＳ内に位置する利用者データベースに照らして検証する。ＡＣＳ１１４は、更に、各オンライン取引に対して、ＣＡＶＶ等の取引識別子を生成する。取引識別子は、特定のオンライン取引に関連づけされると共に、販売者１３２と発行者１９０との間で共有される顧客情報にも関連づけされる。
【０１１１】
ステップ９において、ＡＣＳ１１４は、ＰＡＲｅｓメッセージを利用者クライアントデバイス１２２へ返送する。発行者１９０が維持する利用者１２２関連情報と、取引識別子とは、ＰＡＲｅｓメッセージに含めることで販売者へ送信できる。
【０１１２】
ＡＣＳ１１４は、ＰＡＲｅｓ及びＭＤフィールドを含むフォームを構築する。ＡＣＳ１１４は、利用者のブラウザにフォームをＭＰＩへポストさせることで、利用者のブラウザを介して、署名済みＰＡＲｅｓを販売者のＵＲＬ（ＭＰＩからのポスト内のＴｅｒｍＵｒｌ）へ渡す。この処理において、ポップアップが閉じられ、制御は、販売者のブラウザウィンドウへ戻される。
【０１１３】
この時点で、ＡＣＳ１１４は、更に、選択されたデータを認証履歴サーバ１３０へ送信できる。例えば、ＡＣＳ１１４は、認証履歴サーバ１３０へ送信される支払者認証取引（ＰＡＴｒａｎｓＲｅｑ）メッセージをフォーマットする。
【０１１４】
認証処理中に保持及び／又は転送される利用者情報は、販売者１３２及び発行者１９０のそれぞれが格納できる。各関係者は、顧客情報の一部、或いは一組の顧客情報全体を格納できる。代替として、顧客情報の一部又は全ては、認証サーバ１３０に格納できる。
【０１１５】
ステップ１０において、利用者クライアントデバイスは、ＰＡＲｅｓメッセージをＭＰＩ１３４へ送る。
【０１１６】
ステップ１１において、ＭＰＩ１３４は、ＡＣＳ１１４がＰＡＲｅｓメッセージに付与したデジタル署名の妥当性を確認する。デジタル署名の妥当性確認は、ＡＣＳ１１４自体が実行可能であり、或いは、ＰＡＲｅｓメッセージを別個の妥当性確認サーバへ渡すことで実行できる。妥当性確認処理では、Ｖｉｓａルート証明書を使用して、ＰＡＲｅｓ署名の妥当性を確認する。別個の妥当性確認サーバを使用して実施する場合、ＭＰＩ１３４は、ＰＡＲｅｓを妥当性処理へ送信し、妥当性処理では、Ｖｉｓａルート証明書を使用して、ＰＡＲｅｓ上の署名の妥当性を確認し、署名の妥当性確認の結果をＭＰＩへ返す。
【０１１７】
ステップ１２において、販売者１３２は、取得者１９２との許可の交換を進める。
【０１１８】
ステップ１３において、販売者１３２は、特定の基準一式を使用して、所有している顧客情報を評価する。一組の顧客情報が基準を満たす場合、顧客情報と取引識別子とを対価提供者１９６へ送信する。基準は、対価提供者１９６が顧客情報の受取を希望するかを判断する様々な問題を中心として、様々に変更できる。こうした基準については、認証処理がどのように動作するかの更に詳細な例を通して、更に詳細に説明する。
【０１１９】
ステップ１４において、対価提供者１９６は、顧客情報と取引識別子とを、価値付加制御サーバ１９８等のデータベースに格納する。
【０１２０】
ステップ１５は、様々な目的で発生する可能性がある、価値付加制御サーバ１９８と認証履歴サーバ１３０との間を行き来する通信を表している。こうした目的には、例えば、販売者１３２と対価提供者１９６との間の取引を終結させることと、紛争の解決と、データマイニングとが含まれる。
【０１２１】
本説明の以下の節では、本発明の様々な価値付加実施形態の更なる詳細について説明する。
【０１２２】
対価提供者としての出荷会社
次に、図８に示した認証システム及びプロセスについて、対価提供者１９６が出荷会社（「出荷者」）であり、出荷者２００ａと呼ばれる場合の実施形態により説明する。この実施形態において、利用者１２２は、利用者の住居又は他の郵送先住所へ出荷する必要のある製品を販売会社１３２から購入する。出荷者１９６へ送信される利用者又は顧客情報により、出荷者１９６は、商品を利用者１２２へ出荷できる。上記のように、顧客情報は、認証処理に由来するため、高度な完全性と豊富さとを有する。したがって、情報の価値は、販売者１３２と対価提供者１９６とが互いに取引に参加するための基盤としての役割を果たす。取引の種類の範囲は、大きく変化する可能性がある。一例において、出荷者１９６は、出荷者１９６が販売者１３２及び利用者１２２にとって低いコストで製品を進んで出荷する程度まで、顧客情報の完全性及び豊富さに依存する。こうしたケースは、利用者１２２がパッケージの販売者への返送を決して要求していないことが顧客情報に記載されているために生じ得る。追加として、販売者１３２は、利用者１２２の返送要求に伴う出荷者の責任又はコストを快く免除するほどに、こうした顧客情報に依存できる。
【０１２３】
認証及び価値付加処理は、図８の番号付きステップにより説明した認証処理により開始される。ステップ６及び７において、販売者１３２は、維持している顧客情報を、発行者１９０へ送信されるＰＡＲｅｑメッセージに含めてよい。ステップ９及び１０において、発行者１９０は、発行者１９０が維持している顧客情報を、販売者１３２へ送信されるＰＡＲｅｓメッセージに含めてよい。発行者１９０は、更に、特定のオンライン取引及び顧客情報に関連する取引識別子を生成する。
【０１２４】
顧客情報は、例えば、１）名前、郵送先住所、電子メールアドレス、電話番号、及びＦＡＸ番号といった消費者連絡先情報と、２）全額支払いの回数及び滞納の回数といった顧客支払履歴と、３）好適な出荷方法、返品サービスを要求せずに行われた出荷回数、及び定時出荷の回数といった出荷履歴とにすることができる。顧客情報は、発行者１９０及び販売者１３２が収集可能な任意の種類の情報を含むことができる。
【０１２５】
更にステップ９において、顧客情報は、販売者１３２及び発行者１９０の一方又は両方に格納される。代替として、顧客情報は、認証履歴サーバ１３０等のデータベースに格納される。
【０１２６】
ステップ１３において、販売者１３２は、顧客情報を特定の基準により評価し、こうした情報を出荷者１９６へ送信するべきかを判断する。基準は、例えば、出荷者１９６がタスクを難なく完了可能であることを顧客情報が示す場合に、顧客情報が出荷者１９６へ送信されるように策定できる。基準は、顧客に関して利用可能な履歴情報を調査することで、特定の顧客への出荷のリスクを分析するのに役立つ。基準の例には、１）顧客は、販売者との購入取引を特定の回数を超えて行っているか？、２）出荷先住所は、特定の国、例えば、米国内か？、３）顧客は、以前に購入代金を滞納したことがあるか？、４）顧客は、以前に返品を要求したことがあるか？、５）顧客は、新規顧客か？、６）特定の金額以上の取引か？、７）出荷先住所は検証済みか？、又は８）配達先の国は、低リスク又は高リスクの国か？が含まれる。販売者１３２、出荷者１９６、又は両関係者が、基準を設定できる。
【０１２７】
顧客情報が販売者の基準を満たす場合、顧客情報と取引識別子とは、出荷者１９６へ送信される。発行者１９０が取引識別子を生成するため、出荷者１９６に対して、情報の正確さが保証される。顧客情報に依存して、出荷者１９６は、難なく、したがって過剰なコストなしで、出荷可能であることが一定のレベルで保証された状態で、製品を顧客１２２に出荷する。顧客情報が提供する、出荷者１９６に対する問題のない取引の保証により、販売者１３２と出荷者１９６とは、互いに対して特別の配慮を提供し得る。例えば、出荷者１９６は、販売者１３２及び顧客１２２にとって低いコストで製品を進んで出荷し得る。更に、販売者１３２は、出荷者１９６に代わって、出荷するリスクの一部を負うことが可能であり、或いは販売者１３２は、出荷者１９６に対して運送費を部分的に補償することに合意できる。
【０１２８】
ステップ１４において、出荷者１９６は、取引識別子と共に、顧客情報を価値付加制御サーバ１９８に格納する。出荷者１９６は、出荷ラベルに取引識別子を印刷した状態で、製品を顧客１２２へ出荷できる。
【０１２９】
ステップ１５は、様々な目的で、取引識別子を関連する顧客情報と共に検索することを含む。こうした目的には、販売者１３２と対価提供者１９６との間の取引を終結させること、紛争の解決、及び／又はデータマイニングが一部として含まれる。取引識別子は、特定の取引に対応するため、発行者１９０、販売者１３２、及び対価提供者１９６が各取引の情報を検証できるように、各取引の履歴を追跡するのに有用である。本発明により、販売者は、顧客が特定の購入を行っていないと主張する購入詐欺から、自らを更に保護することも可能となる。本発明により、出荷会社は、顧客が出荷を受け取っていないと偽って主張する出荷詐欺から、自らを更に保護することも可能となる。
【０１３０】
顧客情報は、「強制」又は「引き出し」の状況において、認証履歴サーバ（ＡＨＳ）１３０から検索できる。「強制」の状況は、事象の発生が予測されるため、受取者である対価提供者１９６に顧客情報を強制する状況である。「引き出し」の状況は、不規則に起こる事象の発生時のみ、受取者が顧客情報を引き出す状況である。例えば、ＡＨＳ１３０に格納された顧客情報及び取引識別子による検証を要する紛争が発生した時のみ、顧客情報を引き出すことができる。
【０１３１】
顧客情報及び取引識別子は、取引を終結させるためにＡＨＳ１３０から検索できる。こうした取引は、顧客情報の共有に基づいており、関係者のそれぞれが合意する追加条項を含む。様々な関係者が利益を享受可能な追加取引の基盤の役割を顧客情報が果たすことから、こうした取引は、価値付加取引と呼ばれる。例えば、価値付加取引の関係者は、追加的な事業機会を得ること、より競争力のある商品又はサービスコストを得ること、及び／又は、より有利な契約条項を得ることが可能となる。一部の取引において、出荷者１９６は、特定の条項にしたがって販売者１３２の製品を出荷することに合意する。こうした条項は、販売者１３２に請求される、より低い出荷コスト、及び／又は販売者１３２によるリスク及び責任の肩代わりを含むことができる。顧客情報及び取引識別子をチェックすることで、販売者１３２及び出荷者１９６は、出荷者が特定の出荷を行うことを検証できる。その後、例えば、販売者１３２は、出荷者１９６に割引運送料を支払う。取引を終結させるために顧客情報及び取引識別子を検索することは、こうした情報の検索が取引を終結させるための通常の処理である場合、強制取引となる。
【０１３２】
顧客情報及び取引識別子は、紛争解決の状況においても有用である。紛争は、販売者１３２、顧客１２２、及び出荷者１９６のいずれかの間で発生する可能性がある。紛争は、ＡＨＳ１３０からの情報により、取引に関する事実を提供することで解決できる。紛争が発生した時には、顧客情報及び取引識別子を、こうした情報が格納されている場所から「引き出す」。販売者と出荷者との間の紛争は、各関係者間の価値付加取引の履行に関連する可能性がある。例えば、出荷サービスの支払に関する食い違いが生じた時、販売者１３２は、こうした情報を使用して、合意の上、割引運送料で出荷者１９６が出荷を行ったことを証明できる。或いは、例えば、出荷を受け取っていない、或いは出荷中に商品が損傷したと顧客が苦情を言った場合、出荷者１９６は、こうした取引の責任を販売者１３２が負うことを証明できる。一部の事例においては、発行者１９０が責任を負う場合がある。
【０１３３】
顧客情報及び取引識別子は、販売者１３２、発行者１９０、及び出荷者１９６のそれぞれがデータマイニングの目的でも使用できる。こうした関係者のそれぞれは、その取引を介して、特定の顧客について、その顧客の特色及び傾向を判断するために分析可能な情報を入手できる。こうした特色及び傾向は、販売者１３２、出荷者１９６、及び発行者１９０のそれぞれのマーケティングの目的で使用できる。販売者１３２は、顧客の特色及び傾向に関する情報を使用して、顧客に対する将来の販売及びマーケティング戦略を決定できる。出荷者１９６も、こうした情報をリスクの分析に使用して、例えば、問題に遭遇することなく顧客に製品を出荷できる確率を決定できる。発行者１９０は、こうした情報を使用して、将来、顧客に対して口座を発行することのリスクのレベルを決定可能であり、或いは、クレジットのレベルを引き上げるべきかを決定できる。
【０１３４】
追加として、任意の関係者は、情報を使用して、他の任意の関係者の特性を決定できる。例えば、出荷者は、特定の販売者と契約を結ぶことが賢い事業判断であるかを決定できる。こうした分析を行うために、顧客情報を分析して、販売者の詐欺履歴、チャージバック履歴、顧客の一般的な出荷相手国等を決定できる。こうした情報から、特定の業者との取引では、通常、出荷が容易であることが分かった場合、ある業者は、こうした業者と更に多くの仕事を行うことを判断できる。販売者は、こうしたデータを分析して、特定の出荷者により、出荷のニーズを満足させるべきかを決定できる。例えば、顧客データは、どの業者が配送成功率及び定時配送スコアを有するかを示すことができる。
【０１３５】
販売者１３２及び発行者１９０の一方又は両方が顧客情報を保持する実施形態において、顧客情報及び取引識別子は、対応する団体のそれぞれから検索できる。
【０１３６】
本発明の出荷の代替実施形態において、販売者１３２は、特定の取引の顧客データと取引識別子とのコピーを多数の出荷者へ送信できる。顧客データは認証処理に由来し、高い度合いの完全性を有するため、各出荷者１９６は、その取引のための出荷を実行することに興味を有し得る。各出荷者１９６が興味を有し得るのは、顧客情報の完全性が、取引に関する情報、例えば、出荷先住所の信頼性を保証するためである。更に重要なことに、顧客情報は販売者の基準を通過した後で各出荷者１９６へ送信されているため、各出荷者１９６では、出荷取引の問題に遭遇する確率が低いことが保証されている。代替方法において、出荷者１９６は、少なくとも、特定の取引に伴うリスクのレベルについて知識を得られる。更に、出荷者１９６は、販売者１３２又は発行者１９０が取引のリスクのコストを肩代わりすることに同意していることから、取引の製品を出荷することに興味を有し得る。こうした取引及び顧客に関する知識を有した状態で、出荷者１９６のそれぞれは、販売者１３２に出荷費用を入札できる。販売者１３２は、その後、一出荷者１９６を選択して製品を出荷できる。
【０１３７】
対価提供者としての後続販売者
図８に示した認証及び情報共有処理の代替実施形態において、対価提供者１９６は、後続販売者１９６である。この実施形態において、本発明は、後続販売者１９６について、更に一部のケースでは販売者１３２及び発行者１９０について、収入機会を増加させることができる。後続販売者１９６は、販売者１３２から顧客情報及び取引識別子を受け取り、こうした情報を使用して、自分の商品又はサービスを顧客１２２へ売り込む。後続販売者１９６は、任意の種類の商品又はサービスを提供できるが、販売者１３２が販売する商品又はサービスと何らかの関連性を有することが多い。顧客１２２が販売者１３２との取引の対象に関連する何かを購入する見込みが高くなり得ることから、販売者１３２からの顧客情報は、価値のあるものとなる。販売者１３２及び後続販売者１９６は、顧客情報に基づいて、互いに様々な契約を結ぶことができる。
【０１３８】
この処理も、図８の番号付きステップにより説明した認証処理により開始される。ステップ６、７、９、及び１０において、販売者１３２及び後続販売者１９６は、以前に説明したように情報をＰＡＲｅｑ及びＰＡＲｅｓメッセージに含めることで、顧客１２２に関する情報を共有する。更に、発行者１９０は、特定のオンライン取引及び顧客情報に関連する取引識別子を生成する。顧客情報及び取引識別子は、発行者１９０、販売者１３２のそれぞれにより格納されるか、或いは認証履歴サーバ１３０等の単一のデータベース内に格納される。
【０１３９】
ステップ１３において、販売者１３２は、顧客情報を評価して、顧客情報及び取引識別子を後続販売者１９６へ送信するべきかを判断する。こうした顧客情報は、例えば、顧客の平均出費額、顧客の最高出費額、顧客がいつ購入したか、顧客が誰から購入したか、顧客が何に出費したか、顧客の性別、及び顧客の人口統計学的情報に関連する。顧客の特性に関する分析範囲は極めて広いことを理解されたい。顧客情報が基準を通過した場合、ステップ１３において、情報は、後続販売者１９６へ送信される。
【０１４０】
顧客情報及び取引識別子を受け取ると、ステップ１４において、後続販売者１９６は、顧客情報及び取引識別子を、価値付加制御サーバ１９８等のデータベースに格納する。この時、後続販売者１９６は、顧客情報を利用して、特定の顧客に焦点を絞ったマーケティング戦略を実行できる。顧客情報により、後続販売者１９６は、様々な顧客向けにマーケティング戦略を調整する方法について知ることができる。例えば、特定の取引での顧客の出費額に関する情報から、後続販売者１９６には、顧客１２２が興味を有し得る商品又はサービスの価格水準が分かる。更に、販売者１３２が販売した商品又はサービスに関する情報から、後続販売者１９６には、顧客１２２が購入を希望し得る関連商品又はサービスの種類が分かる。例えば、顧客が販売者１３２からＣＤプレイヤを購入した場合、後続販売者１９６は、顧客１２２に特定のＣＤを販売できる。こうした取引は、「補完財」取引と呼ぶことができる。他の補完財には、例えば、コードレスドリル及び充電式電池、剃刀及び剃刀刃、芝刈り機及び肥料が含まれる。
【０１４１】
顧客情報の受取は、顧客情報により生じた後続販売者１９６の売り上げの一定のパーセンテージを販売者１３２及び／又は発行者１９０に提供するという後続販売者１９６からの合意を条件にできる。こうした販売及び類似する性質の販売は、例えば、「アップセル」及び「クロスセル」と呼ばれる。想像できるように、顧客情報の受取は、販売者１３２と後続販売者１９６との間の様々な合意を条件にできる。上記のように、顧客情報は、多数の詳細を含み、完全性が高いため、後続販売者１９６にとって独自の価値を有する。顧客情報は、販売者１３２及び発行者１９０の一方又は両方が収集したものであるため、多数の詳細を含む。販売者１３２及び発行者１９０のそれぞれは、顧客に関する特定の種類の情報を収集する独自の立場にある。最後に、顧客情報は、ステップ１乃至１２で説明した認証処理を通過したものであるため、完全性が高い。
【０１４２】
ステップ１５は、ここでも、販売者１３２と後続販売者１９６との間の取引を終結させること、紛争の解決、及び／又はデータマイニング等、様々な目的で、取引識別子を関連する顧客情報と共に検索することを含む。後続売り上げの一定のパーセンテージを販売者１３２へ送る前に、後続販売者１９６の売り上げに関する情報を検証する場合、ステップ１５は、販売者１３２と後続販売者１９６との間の契約を成立させるのに必要となり得る。例えば、顧客情報及び取引識別子は、後続販売が顧客情報の結果であることを検証するために、販売者１３２又は後続販売者１９６が検索できる。こうした検証の後、一定の金額が販売者１３２へ送られる。この状況において、顧客情報は、契約を遂行するために、通常の営業過程として一方又は両方の販売者に強制可能であり、或いは、顧客情報は、食い違いを解消する必要がある場合のみ引き出せる。
【０１４３】
紛争の解決に関して、顧客情報及び取引識別子は、販売者１３２、後続販売者１９６、又は顧客１２２のいずれかの間で紛争が生じた場合に検索される。紛争は、違反が生じた恐れのある販売者１３２と後続販売者１９６との間の契約により発生する可能性がある。ここでも、販売者１３２が後続販売者１９６に顧客情報を送ることに合意する時、後続販売者１９６は、顧客情報から得られる売り上げを分け合うことを要求される場合がある。そのため、後続販売者１９６から販売者１３２へ支払うものに関して紛争が生じた時、顧客情報を引き出すことが可能である。関係者は、顧客情報及び取引識別子を照合し、後続販売者１９６による特定の販売が顧客情報に基づいて完了されたかを検証できる。
【０１４４】
後続販売者１９６による売り上げの一部が発行者１９０にも期待できる場合、顧客情報に関する一部の合意には、発行者１９０を関与させることができる。
【０１４５】
顧客情報は、データマイニングの目的でも使用可能であり、発行者１９０、販売者１３２、及び後続販売者１９６のそれぞれは、お互いと顧客とに関する知識を得ることができる。顧客情報の分析により、関係者は、お互いの将来の取引が好ましいかを知ることができる。
【０１４６】
対価提供者としての様々な関係者
口座認証及び価値付加システムの代替実施形態では、様々な種類の関係者が、顧客１２２、販売者１３２、及び対価提供者１９６の役割を果たすことができる。顧客１２２及び販売者１３２の役割は、販売者１３２が顧客の同一性を認証する必要がある場合、互いにオンラインでやり取りする任意の関係者になり得る。販売者１３２が顧客１２２に何らかの商品又はサービスを販売する多数の商業的状況が想像できる。しかしながら、多数の非商業的状況も想像できる。一部の状況には、運転免許、入漁免許、建築免許、社会保障費、及び学校の受講登録といったオンライン登録が含まれる。関係者（販売者１３２等）が別の関係者（顧客１２２等）の同一性認証を要求するシナリオであると理解されたい。
【０１４７】
販売者１３２等の同一性認証者が評価する基準は、様々な種類の対価提供者１９６に関連する可能性がある。基準は、通常、本発明により認証された同一性を有する顧客１２２等の関係者に関する情報の受取を、対価提供者１９６が希望するかに関連する。ステップ１３で送信された顧客情報は、異なる対価提供者１９６のそれぞれに関連する可能性がある。顧客１２２が運転免許を申請する場合、顧客情報は、例えば、顧客の運転記録、運転している車、日常の運転、及び一般的な目的地に関連する可能性がある。対価提供者１９６は、運転に関連する商品又はサービスを顧客に販売することを希望する任意の関係者になり得る。例えば、対価提供者１９６は、排気ガス検査会社、修理店、又は自動車保険会社になり得る。別の実施形態において、対価提供者１９６は、運転に関連するものを何も販売しない場合もある。しかしながら、対価提供者１９６は、それでも顧客１２２が興味を持ち得る商品又はサービスを販売し得る。例えば、顧客情報は、顧客１１２が特定の種類の車を運転しており、したがって、顧客１１２が特定の種類の消費又はサービスに興味を有し得ることを示す場合がある。様々な種類の関係が顧客情報から抽出可能であり、したがって、対価提供者１９６によって有用となる可能性がある。
【０１４８】
顧客１２２が入漁免許を入手する時、対価提供者１９６は、例えば、釣り具販売店、旅行代理店、又は衣料品店となり得る。ここでも、対価提供者１９６は、釣りに直接的に関連する会社である必要はない。対価提供者１９６に送信される顧客情報は、釣りに関する顧客の好みに関連する可能性がある。販売者１２２が評価する基準により、顧客１２２がどのような釣り具を好むか、どのような釣りが好みか、顧客１２２はどこへ釣りに行くのが好きか、及び顧客１２２が使用する衣類の種類を決定できる。
【０１４９】
顧客情報は、更にワークフローの目的で対価提供者に送信できる。例えば、顧客１２２が建築許可又は免許を販売者１２２に申請した後、次のレベルの承認のために、顧客情報を別の政府機関へ送る必要が生じ得る。例えば、建物の建設中に防災安全検査を手配するために、消防署で顧客情報を受け取る必要が生じ得る。
【０１５０】
販売者１２２及び対価提供者１９６のそれぞれは、顧客情報及び取引識別子の共有に基づいて、互いに価値付加関係を結ぶことが可能である。
【０１５１】
一部の実施形態において、販売者１２２は、顧客情報及び取引識別子を多数の対価提供者に送信できる。販売者１２２は、各種類の対価提供者１９６のために、異なる又は同じ一組の基準を評価できる。各対価提供者１９６は、互いに並行して又は順番に、タスクの実行へ進む。対価提供者１９６は、顧客１２２が各対価提供者１９６から直接通知を受けるように、それぞれのタスクをリアルタイムで実行可能であり、或いはタスクはオフラインで実行可能である。
【０１５２】
上記のように、ステップ１５は、販売者１３２、対価提供者１９６、及び発行者１９０のいずれかの間で契約を結ぶために、様々な目的で使用できる。
【０１５３】
対価提供者としてのセキュリティ組織
本発明の一部の実施形態は、国家安全保障等、セキュリティの目的で使用できる。こうした実施形態において、対価提供者１９６は、安全保障問題の情報（データ）の検討を責務とする政府機関又は任意の組織にすることができる。販売者１３２は、顧客１２２との取引をオンラインで実行する任意の営利的、非営利的、政府、又は非政府機関にすることができる。例えば、販売者は、航空券予約会社、工具店、薬品供給業者、又は飛行訓練学校にすることができる。顧客情報の伝送の一部又は全部は、プライバシ及び市民権に関する法律で規制され得ることに留意されたい。
【０１５４】
販売者１３２は、セキュリティ関連の基準により顧客情報を評価し、特定の基準が満たされた時、情報を取引識別子と共に対価提供者１９６へ送信する。例えば、基準により、顧客の購入品目、免許登録、旅行目的地、旅行頻度、その他のセキュリティ関連事項を評価できる。顧客情報及び取引識別子の受取後、対価提供者１９６は、監視任務を実行できる。
【０１５５】
取引識別子は、必要な場合に、セキュリティ関連の業務監査を正確に追跡できるように顧客情報を記録する上で有用となる。これは、例えば、政府の命令によるセキュリティプロトコルの調査の際に必要となり得る。具体的には、販売者１３２は、セキュリティプロトコルに正確に従っていたことを証明する必要が生じ得る。一部の状況において、販売者１３２は、裁判所の命令による召喚状に応答する。顧客情報及び取引識別子は、ステップ１５において、認証履歴サーバ１３０からの強制又は引き出しが可能である。ステップ１５は、販売者１３２、報告者、及び対価提供者１９６間で契約を結ぶために使用することもできる。例えば、販売者１３２は、有用な情報を報告したことに対する評価又は認定を受けることができる。この評価は、取引識別子を使用して、顧客情報に関するソース、日付、その他の詳細を証明した後で受け取ることができる。ステップ１５は、更に、認証履歴サーバ１３０からデータを引き出し、セキュリティ関連問題のデータマイニングを行うために、様々な関係者が使用できる。顧客情報は、発行者１９０及び販売者１３２から収集するため、監視目的において非常に役立つ情報を多く含む可能性が高い。
【０１５６】
一部の実施形態において、対価提供者１９６及び販売者１３２は、顧客情報を受信した直後に対価提供者１９６が販売者１３２にメッセージを送信できるように、リアルタイムで互いに通信する。これにより、望ましくない状況を解決又は回避するために、即座に処置を講じることができる。
【０１５７】
好適なシステムネットワーク
図９は、本発明の実施形態を実施するのに適した電気通信ネットワーク８００を示している。本発明では、任意の適切な電気通信ネットワークを使用してよく、以下に説明するもの等の様々なハードウェア、様々なソフトウェア、及び／又は様々なプロトコルを含んでよい。下記のネットワークは、図２の電気通信ネットワーク１２６の好適な実施形態である。ネットワーク８００は、任意のバンクカード、旅行及び娯楽カード、及び他の自社ブランド及び専用カードを使用した購入及び現金取引をサポートする、世界的な電気通信ネットワークである。ネットワークは、他のネットワークのＡＴＭ取引、紙の小切手を使用した取引、スマートカードを使用した取引、及び他の金融手段を使用した取引もサポートする。
【０１５８】
こうした取引は、ネットワークの許可、決済、及び清算サービスにより処理される。許可は、販売を確定する前、或いは現金を分散させる前に、発行者が販売取引を承認又は拒否する時期である。決済は、顧客の口座へ転記するために、取引を取得者から発行者へ引き渡す時期である。清算は、決済された全取引について、各関係者の純財務状態を計算及び決定する処理である。実際の資金の交換は、別個の処理となる。
【０１５９】
取引は、二重メッセージ又は単一メッセージ取引として、許可、決済、及び清算可能である。二重メッセージ取引は二度送信され、最初は、許可の判断に必要な情報のみ送信され、その後、決済及び清算のために追加情報が再び送信される。単一メッセージ取引は、許可のために一度送信され、決済及び清算情報も含まれる。通常、許可、決済、及び清算は、全てオンラインで行われる。
【０１６０】
電気通信ネットワーク８００の主要構成要素は、交換センタ８０２と、アクセスポイント８０４、８０６と、処理センタ８０８、８１０とである。名宛銀行及び要求者認証機関といった他の実体も、アクセスポイントを介してネットワークに接続する。交換センタは、世界のどこにでも位置し得るデータ処理センタである。一実施形態では、米国に二箇所、英国及び日本に一箇所ずつ存在する。各交換センタは、ネットワーク取引処理を実行するコンピュータシステムを収容する。交換センタは、ＩＢＭ ＳＮＡプロトコルに基づく高速専用回線又は衛星接続を含む、ネットワークの電気通信設備の制御点として機能する。好ましくは、交換センタを遠隔実体に接続する回線８２０及び８２２は、ＩＢＭ ＳＮＡ−ＬＵ０通信プロトコルに基づく専用の高帯域電話回路又は衛星接続を使用する。メッセージは、ＩＳＯ８５８３規格の任意の適切な実施を使用して、これらの回線を介して送信される。
【０１６１】
アクセスポイント８０４又は８０６は、通常、処理センタに配置され、センタのホストコンピュータと交換センタとの間をインタフェースする小型コンピュータシステムである。アクセスポイントは、ホストと、取引の許可、決済、及び清算をサポートする交換センタとの間でのメッセージ及びファイルの送信を容易にする。リンク８２６及び８２８は、通常、センタ内のローカルリンクであり、センタにとって好ましい専用のメッセージ形式を使用する。
【０１６２】
データ処理センタ（取得者、発行者、又はその他の実体内に位置するようなもの）は、販売者及び事業拠点をサポートする処理システムを収容し、顧客データ及び請求システムを維持する。好ましくは、各処理センタは、一箇所又は二箇所の交換センタとリンクされる。プロセッサは、最も近い交換センタに接続され、ネットワークが障害を受けた場合、ネットワークは、取引を自動的に二次的な交換センタへ送る。各交換センタは、他の全ての交換センタにもリンクされる。このリンクにより、処理センタは、一箇所以上の交換センタを介して互いに通信できる。更に、処理センタは、交換センタを介して、他のプログラムのネットワークにアクセスできる。更に、ネットワークは、全てのリンクが複数のバックアップを有する状態を確保する。ネットワークの一点から別の点への接続は、通常は固定リンクではなく、代わりに交換センタは、任意の伝送の時点で、可能な最善の経路を選択する。何らかの障害のあるリンクを迂回するルート変更は、自動的に行われる。
【０１６３】
図１０は、オンライン及びオフライン取引処理を提供するために交換センタに収容されたシステム８４０を示している。二重メッセージ取引では、許可システム８４２が許可を与える。システム８４２は、オンライン及びオフライン機能をサポートし、そのファイルには、内部システムテーブル、顧客データベース、及び販売者中央ファイルが含まれる。システム８４２のオンライン機能は、二重メッセージ許可処理をサポートする。この処理は、ルーティングと、利用者及びカード検証及び代理処理と、ファイルメインテナンス等のその他の機能とを含む。オフライン機能は、報告と、請求と、リカバリブリテンの生成とを含む。報告は、許可報告、例外ファイル及びアドバイスファイルの報告、ＰＯＳ報告、及び請求報告を含む。システム８４２からシステム８４６へのブリッジにより、システム８４２を使用する構成要素は、システム８４６を使用する構成要素と通信し、外部ネットワークへのＳＭＳゲートウェイにアクセスできる。
【０１６４】
決済及び清算システム８４４は、事前に許可された二重メッセージ取引を決済及び清算する。週六日、世界全体で稼働し、システム８４４は、金融及び非金融情報を収集し、報告を構成要素間で配信する。更に、手数料、使用量、及び清算総額を計算し、調整を支援するために報告を作成する。ブリッジは、システム８４４の処理センタとシステム８４６の処理センタとの間の交換部を形成する。
【０１６５】
単一メッセージシステム８４６は、完全な金融取引を処理する。システム８４６は、二重メッセージ認証及び決済取引も処理可能であり、ブリッジを使用してシステム８４２と通信し、必要に応じてネットワークの外部にアクセスする。システム８４６は、ビザ プラス インターリンク（Ｖｉｓａ、Ｐｌｕｓ Ｉｎｔｅｒｌｉｎｋ）、その他のカード取引を処理する。ＳＭＳファイルは、システムのアクセス及び処理を制御する内部システムテーブルと、ＰＩＮ検証及び代理処理認証に使用される利用者データのファイルを含む提供者データベースとを含む。システム８４６のオンライン機能は、リアルタイム利用者取引処理、及び認証の例外処理と、完全な金融取引とを実行する。システム８４６は、調整及び清算の合計を蓄積する。システム８４６のオフライン機能は、清算及び資金振替要求を処理し、清算及び活動報告を提供する。清算サービス８４８は、Ｉｎｔｅｒｌｉｎｋを含め、システム８４４及び８４６の清算機能を統合し、全製品及びサービス向けの単一のサービスとする。決済は、システム８４４及びシステム８４６によって引き続き別個に実行される。
【０１６６】
図１１は、電気通信ネットワーク８００の構成要素の別の図を示している。統合支払システム８５０は、全てのオンライン認証及び金融要求取引を処理するための主要システムである。システム８５０は、二重メッセージ及び単一メッセージ処理の両方を報告する。どちらの場合においても、清算は別個に行われる。三つの主なソフトウェアコンポーネントは、共通インタフェース機能８５２、認証システム８４２、及び単一メッセージシステム８４６である。
【０１６７】
共通インタフェース機能８５２は、交換センタにおいて受け取られた各メッセージに求められる処理を決定する。メッセージのソース（システム８４２、８４４、又は８４６）、処理要求の種類、及び処理ネットワークに基づいて、適切なルーティングを決定する。このコンポーネントは、初期メッセージ編集を実行し、必要な場合、メッセージを解析して、内容が基本構成規則に従う状態を確保する。機能８５２は、メッセージをシステム８４２又はシステム８４６の送信先へ送る。
【０１６８】
コンピュータシステムの実施形態
図１２Ａ及び１２Ｂは、本発明の実施形態を実施するのに適したコンピュータシステム９００を示す。図１２Ａは、コンピュータシステムの可能な物理的形態の一つである。当然ながら、コンピュータシステムは、集積回路、プリント回路基板、及び小型ハンドヘルドデバイスから、巨大なスーパコンピュータまで、多くの物理形態を有し得る。コンピュータシステム９００は、モニタ９０２と、ディスプレイ９０４と、筐体９０６と、ディスクドライブ９０８と、キーボード９１０と、マウス９１２とを含む。ディスク９１４は、コンピュータシステム９００との間でデータを転送するために使用されるコンピュータ読み取り可能な媒体である。
【０１６９】
図１２Ｂは、コンピュータシステム９００のブロック図の例である。システムバス９２０には、広範なサブシステムが取り付けられる。プロセッサ（群）９２２（中央演算処理装置又はＣＰＵとも呼ばれる）は、メモリ９２４を含む記憶装置に結合される。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）及び読み出し専用メモリ（ＲＯＭ）を含む。この技術において周知であるように、ＲＯＭは、データ及び命令をＣＰＵへ一方向で転送する役割を果たし、ＲＡＭは、通常、データ及び命令を双方向で転送するために使用される。こうしたタイプのメモリは、両方とも、以下に説明する任意の適切なコンピュータ読み取り可能な媒体を含んでよい。固定ディスク９２６も、ＣＰＵ９２２に双方向で結合され、追加のデータ記憶容量を提供し、同じく以下に説明する任意のコンピュータ読み取り可能な媒体を含んでよい。固定ディスク９２６は、プログラム、データ、その他を格納するのに使用してよく、通常は、一次記憶装置より低速の二次記憶媒体（ハードディスク等）である。固定ディスク９２６内に保持される情報は、適切である場合には、標準的な方法で、メモリ９２４内に仮想メモリとして組み込んでよいことは理解されよう。リムーバブルディスク９１４は、以下に説明する任意のコンピュータ読み取り可能な媒体の形態を取り得る。
【０１７０】
ＣＰＵ９２２は、ディスプレイ９０４、キーボード９１０、マウス９１２、及びスピーカ９３０等の様々な入出力デバイスにも結合される。一般に、入出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロフォン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、生体認証リーダ、又は他のコンピュータのいずれかにしてよい。ＣＰＵ９２２は、随意的に、ネットワークインタフェース９４０を使用して、別のコンピュータ又は電気通信ネットワークに結合され得る。こうしたネットワークインタフェースにより、ＣＰＵは、上記の方法ステップを実行する過程で、ネットワークから情報を受け取ること、或いはネットワークへ情報を出力することが考えられる。更に、本発明の方法の実施形態は、ＣＰＵ９２２単独で実行し得るものであり、或いは、処理の一部を共有するリモートＣＰＵと連動して、インターネット等のネットワーク上で実行し得る。
【０１７１】
加えて、本発明の実施形態は、更に、様々なコンピュータ実施動作を実行するためにコンピュータコードを有するコンピュータ読み取り可能な媒体を備えたコンピュータストレージ製品に関する。媒体及びコンピュータコードは、本発明のために特別に設計及び構築されたものにしてよく、或いは、コンピュータソフトウェア技術に関する当業者に周知であり利用可能な種類のものにしてよい。コンピュータ読み取り可能な媒体の例には、一部として、ハードディスク、フレキシブルディスク、及び磁気テープといった磁気媒体と、ＣＤ−ＲＯＭ及びホログラフィックデバイスといった光学媒体と、フロプティカルディスク等の光磁気媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、及びＲＯＭ及びＲＡＭデバイスといった、プログラムコードを格納及び実行するために特別に構成されたハードウェアデバイスとが含まれる。コンピュータコードの例には、コンパイラによって生成されるようなマシンコードと、インタプリタを使用してコンピュータで実行される高レベルコードを含むファイルとが含まれる。
【０１７２】
以上、本発明について、いくつかの好適な実施形態により説明してきたが、本発明の範囲に含まれる変更、置換、及び等価物が存在する。更に、本発明の方法及び装置を実施する数多くの代替方法が存在することにも留意されたい。したがって、添付特許請求の範囲は、本発明の本来の趣旨及び範囲に入るこうした全ての変更、置換、及び等価物を含むものと解釈されるべきである。
【図面の簡単な説明】
【０１７３】
【図１】様々なタイプの口座認証用途に対して本発明の口座認証サービスを実施するためのシステムアーキテクチャの一実施形態を示す図である。
【図２】支払取引における本発明の認証サービスをサポートするシステムアーキテクチャの一実施形態を示す図である。
【図３】本発明の一実施形態による、口座保有者が口座認証システムに登録する処理を示す図である。
【図４】口座保有者が口座認証システム加入処理中に情報を入力できるインターネットｗｅｂページの一実施形態を示す図である。
【図５】口座保有者がインターネットに接続されたコンピュータを使用する、口座認証システムにおける認証支払取引を説明する図である。
【図６】口座保有者にパスワードを要求するウィンドウの例を示す図である。
【図７】消費者がインターネットに接続されたコンピュータを使用する口座認証システムに重ね合わせて、支払取引中に送信されるメッセージの例を示す図である。
【図８】対価提供の態様を含むオンライン口座認証に関連するシステムアーキテクチャの例と、一組のメッセージフローとを示す図である。
【図９】本発明の実施形態を実施するのに適した電気通信ネットワークを示す図である。
【図１０】オンライン及びオフライン取引処理を提供するために交換センタに収容されたシステムを示す図である。
【図１１】電気通信ネットワークの構成要素の別の図である。
【図１２Ａ】本発明の実施形態を実施するのに適したコンピュータシステムを示す図である。
【図１２Ｂ】本発明の実施形態を実施するのに適したコンピュータシステムを示す図である。
【特許請求の範囲】
【請求項１】
オンライン取引中に信頼機関によって利用者の同一性が認証されるオンライン認証システムと対価提供者がやり取りするための方法であって、
前記利用者から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記利用者の口座に対して事前に指定されたパスワードと比較し、
前記利用者から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合に、前記信頼機関は、要求者のために、前記利用者が前記口座の実際の所有者であると認証し、前記利用者が前記口座の実際の所有者であることを前記要求者に通知し、
利用者情報を前記対価提供者へ送信する、方法。
【請求項２】
請求項１記載の方法であって、更に、
前記利用者情報を一組の基準により評価し、
前記利用者情報が前記一組の基準を満たす場合に、前記利用者情報を前記対価提供者へ送信する、方法。
【請求項３】
請求項１または請求項２に記載の方法であって、更に、
前記利用者の前記同一性の認証を前記信頼機関に要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項４】
請求項３記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する利用者情報を含む、方法。
【請求項５】
請求項４記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項６】
請求項５記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する利用者情報を含む、方法。
【請求項７】
請求項６記載の方法であって、更に、
前記オンライン取引と、前記対価提供者へ送信された前記利用者情報とに関連づけられている取引識別子を前記信頼機関が生成する、方法。
【請求項８】
請求項２記載の方法であって、
前記利用者情報は、前記オンライン取引の対象を表す情報を含む、方法。
【請求項９】
請求項８記載の方法であって、
前記利用者情報は、更に前記利用者に関する購入行動情報を含む、方法。
【請求項１０】
請求項２記載の方法であって、更に、
利用者情報の前記対価提供者への前記送信動作前の条件として、前記要求者及び対価提供者のそれぞれが一組の権利及び義務に合意する、方法。
【請求項１１】
請求項１０記載の方法であって、更に、
前記利用者情報と引き換えに貨幣価値を前記対価提供者から前記要求者へ転送する、方法。
【請求項１２】
請求項９記載の方法であって、更に、
前記対価提供者が、前記利用者情報に関連する関連情報を前記利用者へ送る、方法。
【請求項１３】
請求項７記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項１４】
請求項１３記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記要求者及び前記対価提供者間の対価提供取引を監査するために前記取引識別子を確認する、方法。
【請求項１５】
請求項１４記載の方法であって、
前記支払認証応答メッセージ及び前記取引識別子の複製は、紛争解決の目的で、前記対価提供者によって取得され、更に、
紛争を解決するために、前記支払認証応答メッセージ及び前記取引識別子の前記複製を前記要求者へ送信する、方法。
【請求項１６】
請求項１３記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記利用者情報をデータマイニングの目的で分析する、方法。
【請求項１７】
請求項１、請求項２および請求項４ないし請求項１６のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項１８】
請求項１、請求項２および請求項４ないし請求項１６のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【請求項１９】
オンライン取引中に信頼機関によって顧客の同一性が認証されるオンライン認証システムと出荷者がやり取りするための方法であって、
前記顧客から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記顧客の口座に対して事前に指定されたパスワードと比較し、
前記顧客から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合、前記信頼機関は、要求者のために、前記顧客が前記口座の実際の所有者であると認証し、前記顧客が前記口座の実際の所有者であることを前記要求者に通知し、
顧客情報を前記出荷者へ送信し、
購入製品を前記顧客へ出荷する、方法。
【請求項２０】
請求項１９記載の方法であって、更に、
前記顧客情報を一組の基準により評価し、
前記顧客情報が前記一組の基準を満たす場合に、前記顧客情報を前記出荷者へ送信する、方法。
【請求項２１】
請求項２０記載の方法であって、
前記顧客情報は、郵送先住所を含む、方法。
【請求項２２】
請求項１９記載の方法であって、更に、
前記要求者及び前記信頼機関から前記顧客情報を収集する、方法。
【請求項２３】
請求項１９ないし請求項２２のいずれかに記載の方法であって、更に、
前記信頼機関に前記顧客の前記同一性の認証を要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項２４】
請求項２３記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する顧客情報を含む、方法。
【請求項２５】
請求項２３記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項２６】
請求項２５記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する顧客情報を含む、方法。
【請求項２７】
請求項２５記載の方法であって、更に、
前記オンライン取引と、前記出荷者へ送信された前記顧客情報とに関連付けられている取引識別子を前記信頼機関が生成する、方法。
【請求項２８】
請求項２７記載の方法であって、
前記出荷作業は、前記出荷者の前記取引識別子の受取時のみ、前記出荷者によって実行される、方法。
【請求項２９】
請求項２８記載の方法であって、更に、
利用者情報の前記出荷者への前記送信動作前の条件として、前記要求者及び出荷者のそれぞれが一組の権利及び義務に合意する、方法。
【請求項３０】
請求項２８記載の方法であって、更に、
前記出荷者の前記顧客情報及び前記取引識別子の受取時に、出荷明細書を割引価格で作成する、方法。
【請求項３１】
請求項２７記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項３２】
請求項３１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記要求者及び前記出荷者間の取引を監査するために前記取引識別子を確認する、方法。
【請求項３３】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項３４】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【請求項３５】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、更に、
前記オンライン取引及び前記顧客情報に関連づけられている取引識別子を、前記信頼機関が生成し、
前記顧客情報及び前記取引識別子を複数の出荷者へ送信し、
前記出荷者の少なくとも一部から出荷見積価格を受け取り、
前記見積価格に基づいて前記購入製品を出荷する出荷者を選択する、方法。
【請求項３６】
オンライン取引中に信頼機関によって利用者の同一性が認証されるオンライン認証システムとセキュリティ組織がやり取りするための方法であって、
前記利用者から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記利用者の口座に対して事前に指定されたパスワードと比較し、
前記利用者から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合、前記信頼機関は、要求者のために、前記利用者が前記口座の実際の所有者であることを認証し、前記利用者が前記口座の実際の所有者であることを前記要求者に通知し、
利用者情報を前記セキュリティ組織へ送信する、方法。
【請求項３７】
請求項３６記載の方法であって、更に、
前記利用者情報を、セキュリティ問題が存在する場合を特定する一組の基準により評価し、
前記利用者情報が前記一組の基準を満たす場合に、前記利用者情報を前記セキュリティ組織へ送信する、方法。
【請求項３８】
請求項３６記載の方法であって、更に、
前記信頼機関に前記利用者の前記同一性の認証を要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項３９】
請求項３８記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する利用者情報を含む、方法。
【請求項４０】
請求項３９記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項４１】
請求項４０記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する利用者情報を含む、方法。
【請求項４２】
請求項４１記載の方法であって、更に、
前記オンライン取引と、前記セキュリティ組織へ送信された前記利用者情報とに関連づけられている取引識別子を前記信頼機関が生成する、方法。
【請求項４３】
請求項３７記載の方法であって、
前記利用者情報は、少なくとも前記オンライン取引の対象を表す情報を含む、方法。
【請求項４４】
請求項４３記載の方法であって、
前記利用者情報は、更に前記利用者に関する購入行動情報を含む、方法。
【請求項４５】
請求項４３記載の方法であって、更に、
前記利用者情報の受け取りに応答して、前記セキュリティ組織が前記利用者に関するセキュリティ検査を実行する、方法。
【請求項４６】
請求項４１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項４７】
請求項４１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
セキュリティ問題の証拠のために前記利用者情報を分析する、方法。
【請求項４８】
請求項３７記載の方法であって、更に、
利用者情報の前記セキュリティ組織への前記送信動作前の条件として、前記要求者及びセキュリティ組織のそれぞれが一組の権利及び義務に合意する、方法。
【請求項４９】
請求項４７記載の方法であって、
前記支払認証応答メッセージ及び前記取引識別子のコピーは、紛争解決の目的で、前記セキュリティ組織によって取得され、更に、
紛争を解決するために、支払認証応答メッセージ及び取引識別子の前記複製を前記要求者又は前記セキュリティ組織へ送信する、方法。
【請求項５０】
請求項３６ないし請求項４９のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項５１】
請求項３６ないし請求項４９のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【請求項１】
オンライン取引中に信頼機関によって利用者の同一性が認証されるオンライン認証システムと対価提供者がやり取りするための方法であって、
前記利用者から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記利用者の口座に対して事前に指定されたパスワードと比較し、
前記利用者から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合に、前記信頼機関は、要求者のために、前記利用者が前記口座の実際の所有者であると認証し、前記利用者が前記口座の実際の所有者であることを前記要求者に通知し、
利用者情報を前記対価提供者へ送信する、方法。
【請求項２】
請求項１記載の方法であって、更に、
前記利用者情報を一組の基準により評価し、
前記利用者情報が前記一組の基準を満たす場合に、前記利用者情報を前記対価提供者へ送信する、方法。
【請求項３】
請求項１または請求項２に記載の方法であって、更に、
前記利用者の前記同一性の認証を前記信頼機関に要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項４】
請求項３記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する利用者情報を含む、方法。
【請求項５】
請求項４記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項６】
請求項５記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する利用者情報を含む、方法。
【請求項７】
請求項６記載の方法であって、更に、
前記オンライン取引と、前記対価提供者へ送信された前記利用者情報とに関連づけられている取引識別子を前記信頼機関が生成する、方法。
【請求項８】
請求項２記載の方法であって、
前記利用者情報は、前記オンライン取引の対象を表す情報を含む、方法。
【請求項９】
請求項８記載の方法であって、
前記利用者情報は、更に前記利用者に関する購入行動情報を含む、方法。
【請求項１０】
請求項２記載の方法であって、更に、
利用者情報の前記対価提供者への前記送信動作前の条件として、前記要求者及び対価提供者のそれぞれが一組の権利及び義務に合意する、方法。
【請求項１１】
請求項１０記載の方法であって、更に、
前記利用者情報と引き換えに貨幣価値を前記対価提供者から前記要求者へ転送する、方法。
【請求項１２】
請求項９記載の方法であって、更に、
前記対価提供者が、前記利用者情報に関連する関連情報を前記利用者へ送る、方法。
【請求項１３】
請求項７記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項１４】
請求項１３記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記要求者及び前記対価提供者間の対価提供取引を監査するために前記取引識別子を確認する、方法。
【請求項１５】
請求項１４記載の方法であって、
前記支払認証応答メッセージ及び前記取引識別子の複製は、紛争解決の目的で、前記対価提供者によって取得され、更に、
紛争を解決するために、前記支払認証応答メッセージ及び前記取引識別子の前記複製を前記要求者へ送信する、方法。
【請求項１６】
請求項１３記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記利用者情報をデータマイニングの目的で分析する、方法。
【請求項１７】
請求項１、請求項２および請求項４ないし請求項１６のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項１８】
請求項１、請求項２および請求項４ないし請求項１６のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【請求項１９】
オンライン取引中に信頼機関によって顧客の同一性が認証されるオンライン認証システムと出荷者がやり取りするための方法であって、
前記顧客から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記顧客の口座に対して事前に指定されたパスワードと比較し、
前記顧客から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合、前記信頼機関は、要求者のために、前記顧客が前記口座の実際の所有者であると認証し、前記顧客が前記口座の実際の所有者であることを前記要求者に通知し、
顧客情報を前記出荷者へ送信し、
購入製品を前記顧客へ出荷する、方法。
【請求項２０】
請求項１９記載の方法であって、更に、
前記顧客情報を一組の基準により評価し、
前記顧客情報が前記一組の基準を満たす場合に、前記顧客情報を前記出荷者へ送信する、方法。
【請求項２１】
請求項２０記載の方法であって、
前記顧客情報は、郵送先住所を含む、方法。
【請求項２２】
請求項１９記載の方法であって、更に、
前記要求者及び前記信頼機関から前記顧客情報を収集する、方法。
【請求項２３】
請求項１９ないし請求項２２のいずれかに記載の方法であって、更に、
前記信頼機関に前記顧客の前記同一性の認証を要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項２４】
請求項２３記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する顧客情報を含む、方法。
【請求項２５】
請求項２３記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項２６】
請求項２５記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する顧客情報を含む、方法。
【請求項２７】
請求項２５記載の方法であって、更に、
前記オンライン取引と、前記出荷者へ送信された前記顧客情報とに関連付けられている取引識別子を前記信頼機関が生成する、方法。
【請求項２８】
請求項２７記載の方法であって、
前記出荷作業は、前記出荷者の前記取引識別子の受取時のみ、前記出荷者によって実行される、方法。
【請求項２９】
請求項２８記載の方法であって、更に、
利用者情報の前記出荷者への前記送信動作前の条件として、前記要求者及び出荷者のそれぞれが一組の権利及び義務に合意する、方法。
【請求項３０】
請求項２８記載の方法であって、更に、
前記出荷者の前記顧客情報及び前記取引識別子の受取時に、出荷明細書を割引価格で作成する、方法。
【請求項３１】
請求項２７記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項３２】
請求項３１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
前記要求者及び前記出荷者間の取引を監査するために前記取引識別子を確認する、方法。
【請求項３３】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項３４】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【請求項３５】
請求項１９ないし請求項２２および請求項２４ないし請求項３２のいずれかに記載の方法であって、更に、
前記オンライン取引及び前記顧客情報に関連づけられている取引識別子を、前記信頼機関が生成し、
前記顧客情報及び前記取引識別子を複数の出荷者へ送信し、
前記出荷者の少なくとも一部から出荷見積価格を受け取り、
前記見積価格に基づいて前記購入製品を出荷する出荷者を選択する、方法。
【請求項３６】
オンライン取引中に信頼機関によって利用者の同一性が認証されるオンライン認証システムとセキュリティ組織がやり取りするための方法であって、
前記利用者から同一性認証パスワードを受け取り、
前記同一性認証パスワードを、前記利用者の口座に対して事前に指定されたパスワードと比較し、
前記利用者から受け取った前記同一性認証パスワードが前記口座に対して事前に指定された前記パスワードに一致する場合、前記信頼機関は、要求者のために、前記利用者が前記口座の実際の所有者であることを認証し、前記利用者が前記口座の実際の所有者であることを前記要求者に通知し、
利用者情報を前記セキュリティ組織へ送信する、方法。
【請求項３７】
請求項３６記載の方法であって、更に、
前記利用者情報を、セキュリティ問題が存在する場合を特定する一組の基準により評価し、
前記利用者情報が前記一組の基準を満たす場合に、前記利用者情報を前記セキュリティ組織へ送信する、方法。
【請求項３８】
請求項３６記載の方法であって、更に、
前記信頼機関に前記利用者の前記同一性の認証を要求するために、支払認証要求メッセージを前記要求者から前記信頼機関へ送信する、方法。
【請求項３９】
請求項３８記載の方法であって、
前記支払認証要求メッセージは、前記要求者が維持する利用者情報を含む、方法。
【請求項４０】
請求項３９記載の方法であって、更に、
支払認証応答メッセージを前記信頼機関から前記要求者へ送信する、方法。
【請求項４１】
請求項４０記載の方法であって、
前記支払認証応答メッセージは、前記信頼機関が維持する利用者情報を含む、方法。
【請求項４２】
請求項４１記載の方法であって、更に、
前記オンライン取引と、前記セキュリティ組織へ送信された前記利用者情報とに関連づけられている取引識別子を前記信頼機関が生成する、方法。
【請求項４３】
請求項３７記載の方法であって、
前記利用者情報は、少なくとも前記オンライン取引の対象を表す情報を含む、方法。
【請求項４４】
請求項４３記載の方法であって、
前記利用者情報は、更に前記利用者に関する購入行動情報を含む、方法。
【請求項４５】
請求項４３記載の方法であって、更に、
前記利用者情報の受け取りに応答して、前記セキュリティ組織が前記利用者に関するセキュリティ検査を実行する、方法。
【請求項４６】
請求項４１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を、格納のために履歴サーバへ送信する、方法。
【請求項４７】
請求項４１記載の方法であって、更に、
前記支払認証応答メッセージ及び前記取引識別子の複製を前記履歴サーバから取得し、
セキュリティ問題の証拠のために前記利用者情報を分析する、方法。
【請求項４８】
請求項３７記載の方法であって、更に、
利用者情報の前記セキュリティ組織への前記送信動作前の条件として、前記要求者及びセキュリティ組織のそれぞれが一組の権利及び義務に合意する、方法。
【請求項４９】
請求項４７記載の方法であって、
前記支払認証応答メッセージ及び前記取引識別子のコピーは、紛争解決の目的で、前記セキュリティ組織によって取得され、更に、
紛争を解決するために、支払認証応答メッセージ及び取引識別子の前記複製を前記要求者又は前記セキュリティ組織へ送信する、方法。
【請求項５０】
請求項３６ないし請求項４９のいずれかに記載の方法であって、
前記信頼機関は、金融機関である、方法。
【請求項５１】
請求項３６ないし請求項４９のいずれかに記載の方法であって、
前記信頼機関は、前記顧客の前記口座を維持する、方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【公表番号】特表２００７−５３６６１９（Ｐ２００７−５３６６１９Ａ）
【公表日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願番号】特願２００７−５１１３３４（Ｐ２００７−５１１３３４）
【出願日】平成１６年５月１１日（２００４．５．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１４５８７
【国際公開番号】ＷＯ２００５／１１１９５７
【国際公開日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（５００３１３５９２）ビザ・インターナショナル・サービス・アソシエーション (8)
【Ｆターム（参考）】
【公表日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願日】平成１６年５月１１日（２００４．５．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１４５８７
【国際公開番号】ＷＯ２００５／１１１９５７
【国際公開日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（５００３１３５９２）ビザ・インターナショナル・サービス・アソシエーション (8)
【Ｆターム（参考）】
[ Back to top ]