安全な電話およびコンピュータのトランザクションのためのシステムおよび方法
安全な電子支払いシステム、および認証を使用して、安全なトランザクション(112)を行なう方法を提供する。商人コンピュータ(104)はアクセス制御サーバ(112)に許可（承認）要求を送出する。アクセス制御サーバ(112)は、購入者の同一性を確認するために、例えば、電子フォームあるいは対話型の音声応答システムによって認証(130)を得る。その後、アクセス制御サーバは、商人のコンピュータに対する応答を送出する。購入者がアカウントにアクセスすることを承認された場合には、決済が商人コンピュータ(104)によって処理され、トランザクション（取引）が終わる。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、米国特許出願10/764,099号「音声認証を使用する安全な電話およびコンピュータトランザクションのためのシステムおよび方法」（2004年1月23日出願）(さらにこの出願は、米国仮特許出願60/442,143号（2003年1月23日出願）の優先権を要求する。)の一部継続出願であり、これの全てを参照によって本明細書に合体させるものとする。また、本出願は、米国仮特許出願60/538,761号（2004年1月23日出願）の優先権を要求し、参照によって当該出願の全体を本明細書に合体させるものとする。
【背景技術】
【０００２】
クレジットカードおよび決済（支払）カードのその他のフォーム（形式）は、対面トランザクション（取引）における使用にために元来は設計されたものであり、その対面トランザクションの間にカードが決済手段、および、カード所有者（名義人）の認証手段を与えることができる。カードを実際に保持していることに加えて、購入者は、さらにカードの裏側の署名と比較され得る署名を提供しなければならない。
【０００３】
電話注文トランザクションでの大きな欠点は、大部分の者が、上述した方法では認証されることがないということである。従って、クレジット／決済カードに関連した不正トランザクションおよび払い戻しの数が、増大する結果となっている。さらに、消費者は、電話上で恐らく未知・身元不詳の個人に個人決済（支払い）情報を与えることの潜在的な危険について関心を持っているかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
オンラインショッピング、即ち、電子商取引は、多くの同じ問題に悩まされている。オンラインショッピングでは、商人（小売業者）がコストを低減し、かつ、新しい顧客を得ることを可能にしながら、消費者に、今までにはない容易さおよび便宜を与えるものである。しかしながら、多くの消費者が、クレジットカード番号のような慎重に扱う必要がある情報の窃盗の恐れのため、これらの恩恵を利用するのに躊躇していた。インターネットを介して送信されたそのような情報のセキュリティを増加させる努力がなされてきた。例えば、セキュアソケットレイヤー(SSL)技術では、消費者と商人との間で送られたメッセージは暗号化され、それによって、第三者が情報をインターセプト（横取り）し、使用することを、より困難にしている。しかしながら、この方法は、商人に、消費者の同一性（本人識別）のいかなる検証も提供しない。従って、第三者が、物理的なクレジットカードの窃盗のような他の不正行為によってクレジットカード番号を得た場合には、SSL技法は、第三者が盗んだ情報を不正に使用するのを防ぐことができなかった。
【０００５】
セキュアー・エレクトロニック・トランザクション(SETTM)技術は、消費者／口座所有者（名義人）、商人およびカード発行会社を認証するためにディジタル証明書を使用することによって、前述した問題を解決することを試みている。各証明書は、それぞれ信頼される認証機関によって出される。SETTMが、現在インターネット上の支払いを扱う最も安全な方法であるが、一方で、それは、口座所有者のコンピュータにインストールされ操作される暗号ソフトウェアおよびディジタル証明書を必要とする。
【０００６】
実際、安全な電子商取り引きシステムのほとんどの先行技術が、消費者のコンピュータに特別なソフトウェアをインストールすることを必要とするものである。しかしながら、多くの消費者がそのようなソフトウェアをインストールすることに抵抗感がある。また、場合によっては、特別な口座所有者アプリケーションは、種々、様々な口座所有者アクセス・デバイス（例えばパーソナルコンピュータ、携帯情報端末、携帯電話機のような移動通信デバイス）と互換性を持たないこともあり得る。その結果、これらの安全な電子商取り引きシステムが、消費者に幅広く受け入れられることは困難であった。
【０００７】
従って、当該技術分野では、より安全にトランザクションを処理するため、電話、即ち、オンライン購入と共に、顧客の同一性を確認する方法が必要とされている。
【課題を解決するための手段】
【０００８】
したがって、本発明の目的は、安全な電話およびオンライントランザクションを実行する方法を提供することである。
【０００９】
本目的およびさらなる目的は、下記システムおよび方法によって達成される。即ち、安全なトランザクションを行なうシステムおよび方法は、好適には、決済口座の所有者（名義人）に関連付けられた第１の認証情報を含むデータベースを提供するステップと、決済口座に関連付けられた決済口座情報を提供するステップと、この決済口座情報がトランザクションを実行するのに使用される、決済口座情報を含む認証要求をアクセス制御サーバに送信するステップと、認証命令を含む情報が商人によって受け取られるステップと、顧客から第２の認証情報を受け取るステップと、第１の認証情報と第２の認証情報とを比較して、トランザクションが決済口座所有者によって承認されるか否かを判定するステップとを含むものである。
【００１０】
本目的およびさらなる目的は、さらに下記システムおよび方法によって達成される。即ち、安全なトランザクションを行なうシステムおよび方法は、好適には、決済口座に関連付けられた決済口座情報であって、トランザクションを行なうために使用されるような決済口座情報を受け取るステップと、アクセス制御サーバへ前記決済口座情報を含む認証要求を送出するステップであって、前記認証要求が、電子フォームを表示するために使用されるデータの伝送を、前記サーバに自動的に動作させるようなステップと、前記所有者から前記電子フォームによって前記認証情報を受け取るステップと、前記トランザクションを承認する目的のために前記所有者を認証するステップと、前記トランザクションを承認するステップとを含むものである。
【００１１】
本目的およびさらなる目的は、さらに下記方法によって達成される。即ち、安全なトランザクションを行なう方法は、好適には、前記決済口座の所有者に関連した認証情報の少なくとも第１のセットを含むデータベースを提供するステップと、前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用される決済口座情報を受け取るステップと、前記トランザクションを行なうことに関連して、少なくとも前記決済口座情報を含む認証要求を受け取るステップと、電子フォームの表示を自動的に作動させるステップと、前記決済口座の前記所有者から認証情報の第２のセットを受け取るステップと、前記電子フォームに認証情報の前記第２のセットを入力するステップと、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが、前記決済口座の前記所有者によって承認されるか否かを判定するステップとを含むものである。
【００１２】
本目的およびさらなる目的は、さらに下記システムによって達成される。即ち、安全なトランザクションを行なうシステムは、好適には、決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも１つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、自動化された音声応答サブシステムと、認証サブシステムと、を具え、前記自動化された音声応答サブシステムが、前記口座所有者に電話を接続して、認証情報の第２のセットを取得し、さらに、前記認証サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定することを特徴とする。
【００１３】
本目的およびさらなる目的は、さらに下記システムによって達成される。即ち、安全なトランザクションを行なうシステムは、好適には、決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも1つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、仮想電子フォームサブシステムと、を具え、前記仮想電子フォームサブシステムが、前記商人から認証情報の第２のセットを受け取るような電子フォームを前記商人に供給し、前記サーバコンピュータ・サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定することを特徴とする。
【発明を実施するための最良の形態】
【００１４】
本発明のさらなる目的、特徴および利点は、発明の実例となる実施例を示す図と共に得られる詳細な説明から明白になるであろう。図の全体にわたって、特に断らない限り、同じ参照符号（数字および文字）を用いて、図示した実施態様の同様の特徴、構成要素や部分を指し示す。
【００１５】
図1は、本発明による安全な決済トランザクション（支払取引）を行なう典型的な方法を示す。本システムは、消費者102、品物および／またはサービスを売る商人104、アクワイアラー（加盟店獲得業者）106（典型的には、商人（加盟店）獲得銀行）、および発行人108（典型的には銀行などの金融機関であり、商人がトランザクションを実行するときに使用される決済口座を発行したもの）を含む。本システムは、また、さらにカード所有者の口座（アカウント）に関する情報を格納するカード所有者ディレクトリ/データベース110を含むこともできる。データベース110は、マスターカード（登録商標）決済機関のような決済組織によって操作され、インターネットのようなネットワークに接続されたサーバコンピュータとすることが好適である。本発明の実施態様によれば、本システムは、発行人システム108の一部として、発行人仮想認証サービス114と結合されている発行人アクセス制御サーバ112を含むことが有利である。
【００１６】
消費者102は電話によって商人104とトランザクション120を行なっているかもしれない。本発明のシステムおよび方法は、ユーザーと商人との間のトランザクションが行なわれる手段にかかわらず、実現し得るものであり、従って、本発明は、電話トランザクション（取引）に制限されるものではない。商人104によって提供される品物またはサービスの代価を払うために使用される決済口座は、典型的にクレジットカード口座、デビットカード口座、および／または、他の何らかのタイプの決済カード口座（アカウント）である。口座は、必須ではないないが、物理的なカードに関連付けられているものである。例えば、決済口座は、消費者102によって使用されるコンピューティング装置上に電子的に格納することができる仮想カードに関連付けることができる。消費者は、必須ではないが、口座所有者（名義人）とすることができ、また、本明細書で使用するように、用語「所有者（名義人）」は、決済口座または支払いのカードを使用することを許可され、関連付けられている1人または複数の個人を含む。
【００１７】
本発明による方法の1つの典型的な実施態様では、トランザクション120は、マスターカードクレジットカードのような決済カードを使用して、消費者102と商人104との間で行なわれる。消費者102は、購入するべき品物／サービスを選択し、商人104に注文を出し、それによって、カード所有者の口座番号、満了日付、および、名前のようなマスターカード・クレジットカード情報を含む決済口座情報を商人104に提供する。カード所有者の認証サービスへの参加を決定するために、ネットワークに接続されたコンピュータシステムを使用する商人104は、マスターカード・ディレクトリのようなディレクトリ110にキュエリー（質問）122を送信することができる。
【００１８】
その後、ディレクトリ110は、カード所有者の参加（登録）を検証(124)するために発行人108と通信する。この検証124は、発行人システム108の一部とすることが好適であるような発行人アクセス制御サーバ112で行なうことができる。本発明に従って記述されたもののような認証サービスを利用するように、カード所有者が検証（承認）されると仮定して、ディレクトリ110は、商人104にカード所有者の認証サービスのための登録を確認する登録検証メッセージ126を送出することができる。商人104がディレクトリ110から登録検証メッセージを受け取った後、商人104は、認証は行なわれるであろうということ、および、トランザクションは承認の受信で終わるであろうことを、消費者102に通知することができる。その後、商人104は、発行人認証サービス114を介して認証130の要求を送出する。
【００１９】
認証は、本発明の具体的な実施態様に依存するいくつかの方法のうちの1つによってこのときに行なうことができる。例えば、電話注文認証システムの状況では、商人104は、電話回線（あるいはオンライントランザクションの場合にはインターネット）上でカード所有者にデータを入れることを促すこともでき、このデータは、認証を行なうために使用することができる。しかしながら、認証のための他のいくつかのプロシージャ（手続き）も本発明の範囲内で実行することができる。
【００２０】
例えば、1つの典型的な実施態様では、トランザクションのコア・プロトコル（例えば、詳細は後述するが3Dセキュアプロトコルなどであり、以降、参照される関連アプリケーションと称する）に対する拡張を実現することができる。また、認証に必要なデータは、非標準3Dセキュアートランザクションの間に交換されるメッセージの拡張タグ（VEReq、或いはVERes、PAReqメッセージなど）内で運搬することができる。
【００２１】
本発明のシステムおよび方法による別の典型的な実施態様では、コア・プロトコルは改良なしで実装することができる。そのような１つの実施態様では、3Dセキュアプロトコルによる、データおよびタグはすべて変えずにそのまま使用することができる。しかしながら、認証ステップを行なうために、商人は、発行人が認証に参加する否かを独立して決定する第２のディレクトリにキュエリーを出すことができる。発行人が認証に参加する場合、商人は、認証を完了するために対話型の音声応答(「IVR」)システムに電話するようカード所有者に指示することもできる。
【００２２】
さらに別の典型的な実施態様では、上に議論されるように、本発明のシステムおよび方法によれば、コア・プロトコルは、カード所有者の代わりに、商人が認証システムへデータを入力することを可能にするような小さな修正を伴うが、大部分はそのままにすることができる。トランザクション（取引）が終わるまで商人（発行人に必要な認証データを供給するため）と通話を終了したくないかもしれないような、また、カード所有者がコンピュータにアクセスしないかもしれないような電話トランザクションにはこのようなシステムが有益である。そのようなものの１つの実施態様では、3Dセキュアプロトコルに修正をすることができ、例えば、VEResメッセージ中のアクセス制御サーバURLフィールドに修正を加えて、カード所有者の代わりに認証データを入力するように商人に促すことができる。特に、カード所有者は、消費者102であることが好適であるが、あるいは、消費者は、商人とのトランザクションに支払いを行うカード所有者によって許可された購入者であるかもしれない。後者は、例えば、カード所有者の代理人がカード所有者の代わりに品物またはサービスを購入するように指示される場合に当てはまるかもしれない。本明細書で使用されるように、用語「所有者」はこれらの個人のうちのいずかを含む。
【００２３】
カード所有者から必要な情報を得るために使用されるプロシージャにかかわらず、認証目的のためのカード所有者から要求される情報は、発行人108が持つファイル上の情報を含むことができ、これを使って、電話をかけてきた者（Caller）／購入者の同一性（本人であること）、即ち、電話をかけてきた者（Caller）／購入者がカード所有者であることを検証することができる。1つそのような例は、EMVチップカードおよびカード読取り装置を利用して、商人、発行人あるいは自動コール・センターにカード所有者のセキュアーコード（登録商標）を提供することである。
当業者に知られるような検証のその他のプロシージャは、ダイナミックセキュリティ質問、電話をかけたもの／購入者によるデュアルトーンマルチ周波数（ＤＴＭＦ）ユーザ入力、音声生体認証分析、或いは、電話をかけたもの／購入者カード所有者であることを確認する何らかの他の方法などを含むものである。
【００２４】
本発明によるシステムの典型的な実施態様の説明を継続するが、トランザクションが適切に検証（承認）されたと発行人アクセス制御サーバ112が判定した場合、アクセス制御サーバ112はトランザクションが検証されたことを示して、商人104に発行人認証サービス114を通じて認証応答メッセージ132を送出することが好適である。その後、当該分野で知られるように、例えば、商人104とアクワイアラー106の間の通信134、およびアクワイアラー106と発行人108の間の通信136を通じてそのトランザクションを完了させることができる。本発明の典型的な実施例は、3D（即ち３次元）セキュア認証プロトコルのようなセキュリティ・プロトコルと共に実現することができる。3Dセキュア認証プロトコルは当該技術分野で知られており、決済産業全体に亘って一般に採用され、実装されているものである。本発明は3Dセキュアのマスターカード'の実装と共に実装することができ、この３Ｄセキュアは、米国仮特許出願60/477,187号、「安全な決済アプリケーションで使用されるアルゴリズム」（2003年6月10日出願）に記載されるものであり、参照によってその全体および関連出願を本明細書に合体させるものとする。しかしながら、3Dセキュアプロトコルを使用して、システムおよび安全なトランザクションのための方法のこの実装に本発明の範囲が制限されないものであることに注意されたい。また、本明細書に記述された概念は、多数の方法で広く適用され得るものであり、このことは当業者に自明であろう。
【００２５】
3Dセキュアプロトコルのマスターカード実装を使用するトランザクションの完了に関するさらなる詳細は、次の出願に見ることができる。それらの全ても、参照によってそれらの全体を本明細書に合体させるものとする。米国特許出願09/963,274号、「認証データ収集および確認のためのユニバーサルなカード所有者認証フィールド(UCAF)を利用するユニバーサルで相互運用可能なシステムおよび方法」（2001年9月26日出願）、米国仮特許出願60/280,776号、「システム、および安全な決済アプリケーション(SPA)およびユニバーサルなカード所有者認証のための方法」（2001年4月2日出願）、米国仮特許出願60/295,630号、「ユニバーサルカード所有者認証フィールドを使う安全な決済アプリケーションのためのシステムおよび方法」（2001年6月4日出願）、米国仮特許出願60/307,575号、「安全な決済アプリケーションを用いて通信ネットワークを越えてトランザクションを実行するためめのシステムおよび方法」（2001年7月24日出願）、米国特許出願09/886,486号、「擬似或いはプロキシー口座番号を使わずに安全な決済アプリケーションを用いて通信ネットワークを越えてトランザクションを実行するためめのシステムおよび方法」（2001年6月22日出願）、米国特許出願09/886,485号、「通信ネットワークを越えて安全な決済を実行するためめのシステムおよび方法」（2001年6月22日出願）、米国特許出願10/096,271号、「安全な決済を実行するためめのシステムおよび方法」（2002年3月11日出願）、米国仮特許出願60/352,968号、「マスターカードＵＣＡＦ ＴＭおよびＳＰＡ ＴＭクライアントレスソリューション」（2002年1月30日出願）などである。
【００２６】
図２Ａ、２Ｂは、３Ｄセキュア認証プロトコルと共に、認証を使う、図１に示した決済トランザクションシステムを操作するための典型的な方法を示す。はじめに、消費者は、トランザクションの対象となる品物および／またはサービスを選択する（ステップ２０２）。次に、商人（小売店）コンピュータシステムは、カード所有者が音声認証システムに参加しているを検証するために、マスターカードディレクトリ（登録簿）にキュエリーを出す（質問する）（ステップ２０４）。好適にはこのキュエリーは、３Ｄセキュア検証登録登録要求（ＶＥＲｅｑ）メッセージの形式にすることができ、これの詳細は本明細書に合体させた上記の出願明細書に記載されている。特に、商人システムは、例えば発行人（発行人仮想ポップアップサービスなどの発行人側のプラグインなどを介して）およびディレクトリシステムと互換性を持たせ、効率的な相互運用性を持たせるソフトウェアプラグインと共に構成させることができる。このプラグインを使用して、商人からのデータを発行人による使用に適したフォーマットに変換することができ、また、その逆もできる。このようなプラグインは、本発明によるシステムや方法の使用のため現行の商人システムをアップグレイドするのに便利であるが、このようなアップグレイドは本発明の範囲のなかでは必ずしも必要ではない。さらに、プラグインはソフトウェア、ハードウェア、或いはこれらの組み合わせから構成させることができる。
【００２７】
次に、マスターカードディレクトリは、カード所有者の参加を検証するために発行人アクセス制御サーバと通信する（ステップ２０６）。カード所有者の参加が（成功裏に）検証されたと仮定すると、その後、マスターカードディレクトリは、商人コンピュータシステムに登録検証メッセージを送信し（ステップ２０８）、認証が実行されるであろうことを示す（ステップ２１４）。登録検証メッセージは、上で参照したように３Ｄセキュアのマスターカード実装に準拠した検証登録応答（ＶＥＲｅｓ）メッセージの形式にすることが好適である。また、上述したように、このメッセージは、商人システムのソフトウェアプラグインによって受信することができ、このプラグインは商人の現行システムに相互運用性を与えるものである。
【００２８】
商人が、カード所有者の参加を確認したマスターカードディレクトリからＶＥＲｅｓを受信した後、商人は認証要求メッセージ（ステップ２１０）を発行人システムに送信することができる。この要求メッセージは、好適には、３Ｄセキュア支払人許可（承認）要求メッセージ（ＰＡＲｅｑ）にすることができ、発行人アクセス制御サーバによって受信することができる。ＰＡＲｅｑメッセージは、好適には、複数のデータフィールド、例えば、発行人が許可（承認）を実行することを可能にするような情報を含むようなデータフィールドを含み、「満了要求」フィールドを含むこともでき、これを使って、支払人認証応答（ＰＡＲｅｓ）が、商人プラグインによって発行人アクセス制御サーバから何も受信されない場合に、商人プラグインがトランザクションのタイムアウトにすることを可能にする時間と日付を指し示す。
【００２９】
商人アクセス制御サーバがＰＡＲｅｑメッセージを受信した後、認証を開始することができる。本発明の1つの典型的な実施例では、発行人認証サービスは、カード所有者(ステップ212)のために電子フォームを準備し、カード所有者のデータの入力のためのフォームを商人に送信する「仮想ポップ・アップ」サービスとすることができる。その後、商人は電話で、電話をかけてきた者／購入者の適切なデータを要求し、フォームへ情報を入力し、カード所有者(ステップ214)(この典型的な実施態様は、商人代表、即ち「MOBO」アプローチと称するが、その詳細は図3Aに関して以下でより詳細に説明する。)の認証のために発行人にデータを送信することができる。認証プロシージャ（手続き）の完了に基づき（下記の図3A、3Bを参照して後で詳述する）、認証応答が発行人アクセス制御サーバによって生成され、商人(ステップ222)に送信され、認証プロシージャの結果を示す。認証応答は、例えば、3Dセキュアプロトコルに従う支払人認証応答(PARes)のフォーム、即ち、形式にすることができる。
【００３０】
認証が失敗する、或いは、タイムアウトになる場合、トランザクションは、本発明によるシステムの特別の実施態様の構成および失敗の理由に依存して、なお始めることができる。しかしながら、認証が明白な認証問題、潜在的な不正トランザクションの兆候を示すなどの理由により失敗した場合、認証を拒否して(ステップ218)、トランザクションをキャンセルすることができる。対照的に、認証が成功裡に(ステップ220)完了した場合、アクセス制御サーバは商人に対する認証応答を送信することができる(ステップ222)。また、トランザクションは、3Dセキュアプロトコル(ステップ224)に従って従来の方法で終わることもできる。
【００３１】
認証（図2Aのステップ214）を行なうための典型的なプロシージャ（手続き）は、図3Aに図示する。この典型的な実施態様では、商人代理(「MOBO」)アプローチが実現され、即ち、商人が、カード所有者(例えば電話トランザクションの間の電話をかけている)に認証情報を要求し、電子フォームあるいは他の手段によってシステムへ認証情報を入力する。カード所有者の購入に際して、カード所有者が認証サービス(ステップ302)で登録されるか否か判断するために、商人は、発行人アクセス制御サーバを伴う商人プラグインを介して通信することができる。これを受けて、発行人は、ACS(アクセス制御サーバ)ＵＲＬエレメント(ステップ304)内にキュエリー・ストリング・パラメーター「IVRNO」を含んでいるVEResメッセージを送信することができる。例えば、次のサンプルURLがVEResメッセージに含まれているかもしれない。
https://securecode,issuer.com/authenticate.asp?IVRNO=MOBO
【００３２】
ACS URLに追加されたこの付加的な質問（キュエリ）ストリング（文字列）パラメータは、商人プラグインに検知され、カード所有者が電話認証のために登録されたこと、および、商人が認証（セキュアコード）のために規定された手段を使用して、MOBO認証を行なわなければならないことを商人に示す。
【００３３】
次に、商人プラグインはPAReqメッセージを生成し、商人データ("##認証タイプ=MOBO##")内に名前/値ペアを追加することができる。その後、商人は、発行人アクセス制御サーバに商人データを送信することができる(ステップ306)。この名前/値ペアは、商人によって送信されたPAReqが電子商取引/オンライントランザクション認証に対立するものとしての電話認証向けであることをアクセス制御サーバに示す。その後、商人は、発行人アクセス制御サーバ(ステップ308)によって提供される認証ウェブ・ページ上で提供される指示に従い、カード所有者から必要な認証情報を集めることができる。その後、商人は、アクセス制御サーバ電子フォームに認証信用証明情報を入力することができる(ステップ310)。電子フォーム(あるいは「仮想ポップ・アップ」)は、発行人認証サービスによって提供されることが好適である。電子フォームはウェブ・インターフェースを使用して、インターネットによって提供することもできるが、あるいは、商人と発行人との間の安全なデータ転送を促進する何らかのソフトウェアアプリケーションを使用して提供することもできる。
【００３４】
次に、好適には、発行人アクセス制御サーバはPAResを生成し(ステップ312)、PAReqのTermＵＲＬエレメントに定義されたURLにPAResを送出する。商人のプラグインは暗号化されたPAResを受け取り、デジタル署名を抽出し、妥当でるか否かを検証することができる(ステップ314)。3Dセキュアプロトコルに従って、その後、商人はPAResからアプリケーション認証値(AAV)を取得し、認証メッセージでAAVを渡すことができる(ステップ316)。最後に、商人は、3Dセキュアプロトコルあるいは他の既知のトランザクション・プロトコルに従ってトランザクションを終えることができる(ステップ318)。
【００３５】
認証（図2Aのステップ214）を行なうための別の典型的なプロシージャは、図3Bに示す。この典型的な実施態様では、対話型の音声応答(「IVR」)アプローチが実現され、ここでは、商人は電話をかけた者（caller）/購入者と電話でトランザクションを行ない、認証目的のために認証情報を入力することを購入者に促すIVRシステムに電話をかけてきた者/購入者を転送し、必要な認証ステップを行なう。
【００３６】
カード所有者の購入に際して、カード所有者が認証サービス(ステップ320)で登録されるか否か判断するために、商人はアクセス制御サーバと商人プラグインを介して通信を行うことができる。次に、発行人は、ACS(アクセス制御サーバ)ＵＲＬエレメント(ステップ322)内にキュエリーストリング・パラメーター「IVRNO」を含んでいるVEResメッセージを送出することができる。例えば、次のサンプルURLがVEResメッセージに含まれているかもしれない。
https://securecode,issuer.com/authenticate.asp?IVRNO=IVR
ACS URLに追加されたこのキュエリーストリング・パラメーターが、商人のプラグインによって検知され、カード所有者が電話認証のために登録され、商人がIVR認証を行なわなければならないことを商人に示す。
【００３７】
次に、商人のプラグインはPAReqメッセージを生成し、例えば、認証用パラメーターを示すために商人のデータ・エレメント内の名前/値ペアを追加するかもしれない。
"##認証タイプ=IVR；電話発信者ＩＤ＝14403528444；転送戻し=Y；転送番号=18004681512##"
【００３８】
その後、商人が、PAReqを発行人アクセス制御サーバに送出することができる(ステップ324)。例えば、上記の値は、商人によって送信されたPAReqは電子商取引/オンライン認証に対立するものとしての電話認証向けのものであること、および、認証手順はIVRであることをアクセス制御サーバに示すことができ、そして、好適には、電話発信者識別情報のような情報、顧客が転送されることとなるＩＶＲ認証の電話番号に関する指示、IVR認証が完了した後で、IVRシステムが商人に電話発信者を転送して戻すか否かをIVRシステムに示す転送戻しフラグを提供する。その後、商人は、IVR認証(ステップ326)を始めるためにキュエリーストリング内で提供された電話番号に電話をかけてきた者（発呼者）を転送することができる。その後、電話をかけてきた者／購入者は、認証のために発行人IVRに転送することができる(ステップ328)。認証は本発明の範囲内の多数の異なる手続きを使用して、行なうことができ、例えば、購入情報を確認するように電話発信者/購入者に促し、カード所有者のセキュアコードのような認証情報を入力する／話すように発呼側／購入者に促すことを含むことができる。次に、発行人アクセス制御サーバは電話をかけてきた者／購入者を認証し、PAResを生成し、TermＵＲＬエレメントに定義されたURLにPAResを送出することもできる(ステップ330)。商人データのパラメーターにそのように指示されている場合、カード所有者を商人に転送して戻すこともできる。その後、商人のプラグインは暗号化された（コード化された）PAResを受け取り、デジタル署名を抽出する／確認することができる(ステップ332)。3Dセキュアプロトコルに従って、その後、商人はPAResからAAVを取得し、認証メッセージでAAVを渡すことができる(ステップ334)。最後に、3Dセキュアプロトコルあるいは他の既知のプロトコルに従って正常なものとして、商人はトランザクションを終えることができる(ステップ336)。
【００３９】
図１−３で示した方法やシステムは、適切なソフトウェアの管理の下で作動する様々な標準的なコンピュータ・プラットフォームを使用して実現することができることは当業者には自明である。ある場合には、従来のパーソナルコンピュータ中の周辺装置カードのような専用コンピュータハードウェアが上記の方法の効率性を向上させるために使用すしてもよい。
【００４０】
図4、5は、本発明を実行するのに適した典型的なコンピュータハードウェアを示す。図4を参照すると、コンピュータシステムは処理セクション410、ディスプレイ420、キーボード430、およびモデムなどの通信周辺機器440を含んでいる。システムはさらにプリンタ460を含むことができる。コンピュータシステムは、データとアプリケーション・ソフトを格納するためのコンピュータが読んだり書き込んだりできる媒体などの磁気媒体(即ちディスケット)のようなおよび／または光学媒体（例えばCD-ROMあるいはDVD）などの1つ以上のディスクドライブ470を典型的には含んでいる。システムは、さらに典型的には、ハード・ディスク・ドライブのような内部コンピュータ可読媒体480を含んでいる。ディジタル・ポインター490（例えばマウス）、決済カード400を読むためのカード読取り装置450のような他の入力装置も含むことができる。図４，５に図示したコンピュータハードウェアを使用して図１−３に図示したソフトウェアを実行することができ、および／または、これらのコンピュータハードウェアを使用して、消費者102、商人104(また、上記に記述した関連する商人プラグイン)、アクワイアラー106、発行人システム108およびディレクトリシステム110によって利用されるコンピュータプロセッサの機能を実行することもできる。
【００４１】
図5は、さらに処理セクション410を示す機能ブロック図である。処理セクション410は、一般に、演算処理ユニット510、制御ロジック520および記憶装置550を含んでいる。好適には、処理セクション410はさらにタイマー530および入出力ポート540を含むことができる。処理セクション410はさらに演算処理ユニットで使用されるマイクロプロセッサーに依存するが、コプロセッサ560を含むことができる。制御ロジック520は、処理ユニット510と共に、記憶装置530と入出力ポート540との間の通信を扱うのに必要な制御を提供する。タイマー550は、演算処理ユニット510および制御ロジック520に対してタイミング基準信号を与える。コプロセッサ560は、暗号アルゴリズムによって要求されるもののようなリアルタイムの複雑な計算を実行するような機能向上を与える。
【００４２】
記憶装置530は、揮発性および不揮発性メモリおよび読み出し専用でプログラム可能なメモリのような異なるタイプのメモリを含むことができる。例えば、図5で示されるように、記憶装置530は読み取り専用メモリ(ROM)531、EEPROM532およびランダムアクセス記憶装置(RAM)533を含むことができる。異なるコンピュータ・プロセッサ、メモリー構成、データ構造およびその他同種のものは、本発明を実行するために使用することができる。また、発明は特定のプラットフォームへ制限されていない。例えば、処理セクション410は、コンピュータシステムの一部として図4および5で示してあるが、コンピュータシステム、処理セクション410、および／または、そのコンポーネントの一部は、PDAまたは携帯電話機に組み入れることができる。
【００４３】
本発明を特定の典型的な実施態様に関して説明してきたが、付属の請求の範囲に示した本発明の範囲および本質から逸脱することなく、開示した実施態様には、当業者であれば様々な変更、置換、代替を施すことができるものと理解すべきである。
【図面の簡単な説明】
【００４４】
【図１】本発明による決済トランザクションを実行するために付加的な典型的なシステムを示すブロック図である。
【図２Ａ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図２Ｂ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図３Ａ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図３Ｂ】本発明による決済トランザクションを実行するための典型的なシステムを示すフローチャートである。
【図４】本発明による決済トランザクションを実行するために典型的なシステムを示すブロック図である。
【図５】本発明による決済トランザクションを実行するために典型的なシステムを示すブロック図である。
【技術分野】
【０００１】
関連出願の相互参照
本出願は、米国特許出願10/764,099号「音声認証を使用する安全な電話およびコンピュータトランザクションのためのシステムおよび方法」（2004年1月23日出願）(さらにこの出願は、米国仮特許出願60/442,143号（2003年1月23日出願）の優先権を要求する。)の一部継続出願であり、これの全てを参照によって本明細書に合体させるものとする。また、本出願は、米国仮特許出願60/538,761号（2004年1月23日出願）の優先権を要求し、参照によって当該出願の全体を本明細書に合体させるものとする。
【背景技術】
【０００２】
クレジットカードおよび決済（支払）カードのその他のフォーム（形式）は、対面トランザクション（取引）における使用にために元来は設計されたものであり、その対面トランザクションの間にカードが決済手段、および、カード所有者（名義人）の認証手段を与えることができる。カードを実際に保持していることに加えて、購入者は、さらにカードの裏側の署名と比較され得る署名を提供しなければならない。
【０００３】
電話注文トランザクションでの大きな欠点は、大部分の者が、上述した方法では認証されることがないということである。従って、クレジット／決済カードに関連した不正トランザクションおよび払い戻しの数が、増大する結果となっている。さらに、消費者は、電話上で恐らく未知・身元不詳の個人に個人決済（支払い）情報を与えることの潜在的な危険について関心を持っているかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
オンラインショッピング、即ち、電子商取引は、多くの同じ問題に悩まされている。オンラインショッピングでは、商人（小売業者）がコストを低減し、かつ、新しい顧客を得ることを可能にしながら、消費者に、今までにはない容易さおよび便宜を与えるものである。しかしながら、多くの消費者が、クレジットカード番号のような慎重に扱う必要がある情報の窃盗の恐れのため、これらの恩恵を利用するのに躊躇していた。インターネットを介して送信されたそのような情報のセキュリティを増加させる努力がなされてきた。例えば、セキュアソケットレイヤー(SSL)技術では、消費者と商人との間で送られたメッセージは暗号化され、それによって、第三者が情報をインターセプト（横取り）し、使用することを、より困難にしている。しかしながら、この方法は、商人に、消費者の同一性（本人識別）のいかなる検証も提供しない。従って、第三者が、物理的なクレジットカードの窃盗のような他の不正行為によってクレジットカード番号を得た場合には、SSL技法は、第三者が盗んだ情報を不正に使用するのを防ぐことができなかった。
【０００５】
セキュアー・エレクトロニック・トランザクション(SETTM)技術は、消費者／口座所有者（名義人）、商人およびカード発行会社を認証するためにディジタル証明書を使用することによって、前述した問題を解決することを試みている。各証明書は、それぞれ信頼される認証機関によって出される。SETTMが、現在インターネット上の支払いを扱う最も安全な方法であるが、一方で、それは、口座所有者のコンピュータにインストールされ操作される暗号ソフトウェアおよびディジタル証明書を必要とする。
【０００６】
実際、安全な電子商取り引きシステムのほとんどの先行技術が、消費者のコンピュータに特別なソフトウェアをインストールすることを必要とするものである。しかしながら、多くの消費者がそのようなソフトウェアをインストールすることに抵抗感がある。また、場合によっては、特別な口座所有者アプリケーションは、種々、様々な口座所有者アクセス・デバイス（例えばパーソナルコンピュータ、携帯情報端末、携帯電話機のような移動通信デバイス）と互換性を持たないこともあり得る。その結果、これらの安全な電子商取り引きシステムが、消費者に幅広く受け入れられることは困難であった。
【０００７】
従って、当該技術分野では、より安全にトランザクションを処理するため、電話、即ち、オンライン購入と共に、顧客の同一性を確認する方法が必要とされている。
【課題を解決するための手段】
【０００８】
したがって、本発明の目的は、安全な電話およびオンライントランザクションを実行する方法を提供することである。
【０００９】
本目的およびさらなる目的は、下記システムおよび方法によって達成される。即ち、安全なトランザクションを行なうシステムおよび方法は、好適には、決済口座の所有者（名義人）に関連付けられた第１の認証情報を含むデータベースを提供するステップと、決済口座に関連付けられた決済口座情報を提供するステップと、この決済口座情報がトランザクションを実行するのに使用される、決済口座情報を含む認証要求をアクセス制御サーバに送信するステップと、認証命令を含む情報が商人によって受け取られるステップと、顧客から第２の認証情報を受け取るステップと、第１の認証情報と第２の認証情報とを比較して、トランザクションが決済口座所有者によって承認されるか否かを判定するステップとを含むものである。
【００１０】
本目的およびさらなる目的は、さらに下記システムおよび方法によって達成される。即ち、安全なトランザクションを行なうシステムおよび方法は、好適には、決済口座に関連付けられた決済口座情報であって、トランザクションを行なうために使用されるような決済口座情報を受け取るステップと、アクセス制御サーバへ前記決済口座情報を含む認証要求を送出するステップであって、前記認証要求が、電子フォームを表示するために使用されるデータの伝送を、前記サーバに自動的に動作させるようなステップと、前記所有者から前記電子フォームによって前記認証情報を受け取るステップと、前記トランザクションを承認する目的のために前記所有者を認証するステップと、前記トランザクションを承認するステップとを含むものである。
【００１１】
本目的およびさらなる目的は、さらに下記方法によって達成される。即ち、安全なトランザクションを行なう方法は、好適には、前記決済口座の所有者に関連した認証情報の少なくとも第１のセットを含むデータベースを提供するステップと、前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用される決済口座情報を受け取るステップと、前記トランザクションを行なうことに関連して、少なくとも前記決済口座情報を含む認証要求を受け取るステップと、電子フォームの表示を自動的に作動させるステップと、前記決済口座の前記所有者から認証情報の第２のセットを受け取るステップと、前記電子フォームに認証情報の前記第２のセットを入力するステップと、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが、前記決済口座の前記所有者によって承認されるか否かを判定するステップとを含むものである。
【００１２】
本目的およびさらなる目的は、さらに下記システムによって達成される。即ち、安全なトランザクションを行なうシステムは、好適には、決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも１つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、自動化された音声応答サブシステムと、認証サブシステムと、を具え、前記自動化された音声応答サブシステムが、前記口座所有者に電話を接続して、認証情報の第２のセットを取得し、さらに、前記認証サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定することを特徴とする。
【００１３】
本目的およびさらなる目的は、さらに下記システムによって達成される。即ち、安全なトランザクションを行なうシステムは、好適には、決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも1つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、仮想電子フォームサブシステムと、を具え、前記仮想電子フォームサブシステムが、前記商人から認証情報の第２のセットを受け取るような電子フォームを前記商人に供給し、前記サーバコンピュータ・サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定することを特徴とする。
【発明を実施するための最良の形態】
【００１４】
本発明のさらなる目的、特徴および利点は、発明の実例となる実施例を示す図と共に得られる詳細な説明から明白になるであろう。図の全体にわたって、特に断らない限り、同じ参照符号（数字および文字）を用いて、図示した実施態様の同様の特徴、構成要素や部分を指し示す。
【００１５】
図1は、本発明による安全な決済トランザクション（支払取引）を行なう典型的な方法を示す。本システムは、消費者102、品物および／またはサービスを売る商人104、アクワイアラー（加盟店獲得業者）106（典型的には、商人（加盟店）獲得銀行）、および発行人108（典型的には銀行などの金融機関であり、商人がトランザクションを実行するときに使用される決済口座を発行したもの）を含む。本システムは、また、さらにカード所有者の口座（アカウント）に関する情報を格納するカード所有者ディレクトリ/データベース110を含むこともできる。データベース110は、マスターカード（登録商標）決済機関のような決済組織によって操作され、インターネットのようなネットワークに接続されたサーバコンピュータとすることが好適である。本発明の実施態様によれば、本システムは、発行人システム108の一部として、発行人仮想認証サービス114と結合されている発行人アクセス制御サーバ112を含むことが有利である。
【００１６】
消費者102は電話によって商人104とトランザクション120を行なっているかもしれない。本発明のシステムおよび方法は、ユーザーと商人との間のトランザクションが行なわれる手段にかかわらず、実現し得るものであり、従って、本発明は、電話トランザクション（取引）に制限されるものではない。商人104によって提供される品物またはサービスの代価を払うために使用される決済口座は、典型的にクレジットカード口座、デビットカード口座、および／または、他の何らかのタイプの決済カード口座（アカウント）である。口座は、必須ではないないが、物理的なカードに関連付けられているものである。例えば、決済口座は、消費者102によって使用されるコンピューティング装置上に電子的に格納することができる仮想カードに関連付けることができる。消費者は、必須ではないが、口座所有者（名義人）とすることができ、また、本明細書で使用するように、用語「所有者（名義人）」は、決済口座または支払いのカードを使用することを許可され、関連付けられている1人または複数の個人を含む。
【００１７】
本発明による方法の1つの典型的な実施態様では、トランザクション120は、マスターカードクレジットカードのような決済カードを使用して、消費者102と商人104との間で行なわれる。消費者102は、購入するべき品物／サービスを選択し、商人104に注文を出し、それによって、カード所有者の口座番号、満了日付、および、名前のようなマスターカード・クレジットカード情報を含む決済口座情報を商人104に提供する。カード所有者の認証サービスへの参加を決定するために、ネットワークに接続されたコンピュータシステムを使用する商人104は、マスターカード・ディレクトリのようなディレクトリ110にキュエリー（質問）122を送信することができる。
【００１８】
その後、ディレクトリ110は、カード所有者の参加（登録）を検証(124)するために発行人108と通信する。この検証124は、発行人システム108の一部とすることが好適であるような発行人アクセス制御サーバ112で行なうことができる。本発明に従って記述されたもののような認証サービスを利用するように、カード所有者が検証（承認）されると仮定して、ディレクトリ110は、商人104にカード所有者の認証サービスのための登録を確認する登録検証メッセージ126を送出することができる。商人104がディレクトリ110から登録検証メッセージを受け取った後、商人104は、認証は行なわれるであろうということ、および、トランザクションは承認の受信で終わるであろうことを、消費者102に通知することができる。その後、商人104は、発行人認証サービス114を介して認証130の要求を送出する。
【００１９】
認証は、本発明の具体的な実施態様に依存するいくつかの方法のうちの1つによってこのときに行なうことができる。例えば、電話注文認証システムの状況では、商人104は、電話回線（あるいはオンライントランザクションの場合にはインターネット）上でカード所有者にデータを入れることを促すこともでき、このデータは、認証を行なうために使用することができる。しかしながら、認証のための他のいくつかのプロシージャ（手続き）も本発明の範囲内で実行することができる。
【００２０】
例えば、1つの典型的な実施態様では、トランザクションのコア・プロトコル（例えば、詳細は後述するが3Dセキュアプロトコルなどであり、以降、参照される関連アプリケーションと称する）に対する拡張を実現することができる。また、認証に必要なデータは、非標準3Dセキュアートランザクションの間に交換されるメッセージの拡張タグ（VEReq、或いはVERes、PAReqメッセージなど）内で運搬することができる。
【００２１】
本発明のシステムおよび方法による別の典型的な実施態様では、コア・プロトコルは改良なしで実装することができる。そのような１つの実施態様では、3Dセキュアプロトコルによる、データおよびタグはすべて変えずにそのまま使用することができる。しかしながら、認証ステップを行なうために、商人は、発行人が認証に参加する否かを独立して決定する第２のディレクトリにキュエリーを出すことができる。発行人が認証に参加する場合、商人は、認証を完了するために対話型の音声応答(「IVR」)システムに電話するようカード所有者に指示することもできる。
【００２２】
さらに別の典型的な実施態様では、上に議論されるように、本発明のシステムおよび方法によれば、コア・プロトコルは、カード所有者の代わりに、商人が認証システムへデータを入力することを可能にするような小さな修正を伴うが、大部分はそのままにすることができる。トランザクション（取引）が終わるまで商人（発行人に必要な認証データを供給するため）と通話を終了したくないかもしれないような、また、カード所有者がコンピュータにアクセスしないかもしれないような電話トランザクションにはこのようなシステムが有益である。そのようなものの１つの実施態様では、3Dセキュアプロトコルに修正をすることができ、例えば、VEResメッセージ中のアクセス制御サーバURLフィールドに修正を加えて、カード所有者の代わりに認証データを入力するように商人に促すことができる。特に、カード所有者は、消費者102であることが好適であるが、あるいは、消費者は、商人とのトランザクションに支払いを行うカード所有者によって許可された購入者であるかもしれない。後者は、例えば、カード所有者の代理人がカード所有者の代わりに品物またはサービスを購入するように指示される場合に当てはまるかもしれない。本明細書で使用されるように、用語「所有者」はこれらの個人のうちのいずかを含む。
【００２３】
カード所有者から必要な情報を得るために使用されるプロシージャにかかわらず、認証目的のためのカード所有者から要求される情報は、発行人108が持つファイル上の情報を含むことができ、これを使って、電話をかけてきた者（Caller）／購入者の同一性（本人であること）、即ち、電話をかけてきた者（Caller）／購入者がカード所有者であることを検証することができる。1つそのような例は、EMVチップカードおよびカード読取り装置を利用して、商人、発行人あるいは自動コール・センターにカード所有者のセキュアーコード（登録商標）を提供することである。
当業者に知られるような検証のその他のプロシージャは、ダイナミックセキュリティ質問、電話をかけたもの／購入者によるデュアルトーンマルチ周波数（ＤＴＭＦ）ユーザ入力、音声生体認証分析、或いは、電話をかけたもの／購入者カード所有者であることを確認する何らかの他の方法などを含むものである。
【００２４】
本発明によるシステムの典型的な実施態様の説明を継続するが、トランザクションが適切に検証（承認）されたと発行人アクセス制御サーバ112が判定した場合、アクセス制御サーバ112はトランザクションが検証されたことを示して、商人104に発行人認証サービス114を通じて認証応答メッセージ132を送出することが好適である。その後、当該分野で知られるように、例えば、商人104とアクワイアラー106の間の通信134、およびアクワイアラー106と発行人108の間の通信136を通じてそのトランザクションを完了させることができる。本発明の典型的な実施例は、3D（即ち３次元）セキュア認証プロトコルのようなセキュリティ・プロトコルと共に実現することができる。3Dセキュア認証プロトコルは当該技術分野で知られており、決済産業全体に亘って一般に採用され、実装されているものである。本発明は3Dセキュアのマスターカード'の実装と共に実装することができ、この３Ｄセキュアは、米国仮特許出願60/477,187号、「安全な決済アプリケーションで使用されるアルゴリズム」（2003年6月10日出願）に記載されるものであり、参照によってその全体および関連出願を本明細書に合体させるものとする。しかしながら、3Dセキュアプロトコルを使用して、システムおよび安全なトランザクションのための方法のこの実装に本発明の範囲が制限されないものであることに注意されたい。また、本明細書に記述された概念は、多数の方法で広く適用され得るものであり、このことは当業者に自明であろう。
【００２５】
3Dセキュアプロトコルのマスターカード実装を使用するトランザクションの完了に関するさらなる詳細は、次の出願に見ることができる。それらの全ても、参照によってそれらの全体を本明細書に合体させるものとする。米国特許出願09/963,274号、「認証データ収集および確認のためのユニバーサルなカード所有者認証フィールド(UCAF)を利用するユニバーサルで相互運用可能なシステムおよび方法」（2001年9月26日出願）、米国仮特許出願60/280,776号、「システム、および安全な決済アプリケーション(SPA)およびユニバーサルなカード所有者認証のための方法」（2001年4月2日出願）、米国仮特許出願60/295,630号、「ユニバーサルカード所有者認証フィールドを使う安全な決済アプリケーションのためのシステムおよび方法」（2001年6月4日出願）、米国仮特許出願60/307,575号、「安全な決済アプリケーションを用いて通信ネットワークを越えてトランザクションを実行するためめのシステムおよび方法」（2001年7月24日出願）、米国特許出願09/886,486号、「擬似或いはプロキシー口座番号を使わずに安全な決済アプリケーションを用いて通信ネットワークを越えてトランザクションを実行するためめのシステムおよび方法」（2001年6月22日出願）、米国特許出願09/886,485号、「通信ネットワークを越えて安全な決済を実行するためめのシステムおよび方法」（2001年6月22日出願）、米国特許出願10/096,271号、「安全な決済を実行するためめのシステムおよび方法」（2002年3月11日出願）、米国仮特許出願60/352,968号、「マスターカードＵＣＡＦ ＴＭおよびＳＰＡ ＴＭクライアントレスソリューション」（2002年1月30日出願）などである。
【００２６】
図２Ａ、２Ｂは、３Ｄセキュア認証プロトコルと共に、認証を使う、図１に示した決済トランザクションシステムを操作するための典型的な方法を示す。はじめに、消費者は、トランザクションの対象となる品物および／またはサービスを選択する（ステップ２０２）。次に、商人（小売店）コンピュータシステムは、カード所有者が音声認証システムに参加しているを検証するために、マスターカードディレクトリ（登録簿）にキュエリーを出す（質問する）（ステップ２０４）。好適にはこのキュエリーは、３Ｄセキュア検証登録登録要求（ＶＥＲｅｑ）メッセージの形式にすることができ、これの詳細は本明細書に合体させた上記の出願明細書に記載されている。特に、商人システムは、例えば発行人（発行人仮想ポップアップサービスなどの発行人側のプラグインなどを介して）およびディレクトリシステムと互換性を持たせ、効率的な相互運用性を持たせるソフトウェアプラグインと共に構成させることができる。このプラグインを使用して、商人からのデータを発行人による使用に適したフォーマットに変換することができ、また、その逆もできる。このようなプラグインは、本発明によるシステムや方法の使用のため現行の商人システムをアップグレイドするのに便利であるが、このようなアップグレイドは本発明の範囲のなかでは必ずしも必要ではない。さらに、プラグインはソフトウェア、ハードウェア、或いはこれらの組み合わせから構成させることができる。
【００２７】
次に、マスターカードディレクトリは、カード所有者の参加を検証するために発行人アクセス制御サーバと通信する（ステップ２０６）。カード所有者の参加が（成功裏に）検証されたと仮定すると、その後、マスターカードディレクトリは、商人コンピュータシステムに登録検証メッセージを送信し（ステップ２０８）、認証が実行されるであろうことを示す（ステップ２１４）。登録検証メッセージは、上で参照したように３Ｄセキュアのマスターカード実装に準拠した検証登録応答（ＶＥＲｅｓ）メッセージの形式にすることが好適である。また、上述したように、このメッセージは、商人システムのソフトウェアプラグインによって受信することができ、このプラグインは商人の現行システムに相互運用性を与えるものである。
【００２８】
商人が、カード所有者の参加を確認したマスターカードディレクトリからＶＥＲｅｓを受信した後、商人は認証要求メッセージ（ステップ２１０）を発行人システムに送信することができる。この要求メッセージは、好適には、３Ｄセキュア支払人許可（承認）要求メッセージ（ＰＡＲｅｑ）にすることができ、発行人アクセス制御サーバによって受信することができる。ＰＡＲｅｑメッセージは、好適には、複数のデータフィールド、例えば、発行人が許可（承認）を実行することを可能にするような情報を含むようなデータフィールドを含み、「満了要求」フィールドを含むこともでき、これを使って、支払人認証応答（ＰＡＲｅｓ）が、商人プラグインによって発行人アクセス制御サーバから何も受信されない場合に、商人プラグインがトランザクションのタイムアウトにすることを可能にする時間と日付を指し示す。
【００２９】
商人アクセス制御サーバがＰＡＲｅｑメッセージを受信した後、認証を開始することができる。本発明の1つの典型的な実施例では、発行人認証サービスは、カード所有者(ステップ212)のために電子フォームを準備し、カード所有者のデータの入力のためのフォームを商人に送信する「仮想ポップ・アップ」サービスとすることができる。その後、商人は電話で、電話をかけてきた者／購入者の適切なデータを要求し、フォームへ情報を入力し、カード所有者(ステップ214)(この典型的な実施態様は、商人代表、即ち「MOBO」アプローチと称するが、その詳細は図3Aに関して以下でより詳細に説明する。)の認証のために発行人にデータを送信することができる。認証プロシージャ（手続き）の完了に基づき（下記の図3A、3Bを参照して後で詳述する）、認証応答が発行人アクセス制御サーバによって生成され、商人(ステップ222)に送信され、認証プロシージャの結果を示す。認証応答は、例えば、3Dセキュアプロトコルに従う支払人認証応答(PARes)のフォーム、即ち、形式にすることができる。
【００３０】
認証が失敗する、或いは、タイムアウトになる場合、トランザクションは、本発明によるシステムの特別の実施態様の構成および失敗の理由に依存して、なお始めることができる。しかしながら、認証が明白な認証問題、潜在的な不正トランザクションの兆候を示すなどの理由により失敗した場合、認証を拒否して(ステップ218)、トランザクションをキャンセルすることができる。対照的に、認証が成功裡に(ステップ220)完了した場合、アクセス制御サーバは商人に対する認証応答を送信することができる(ステップ222)。また、トランザクションは、3Dセキュアプロトコル(ステップ224)に従って従来の方法で終わることもできる。
【００３１】
認証（図2Aのステップ214）を行なうための典型的なプロシージャ（手続き）は、図3Aに図示する。この典型的な実施態様では、商人代理(「MOBO」)アプローチが実現され、即ち、商人が、カード所有者(例えば電話トランザクションの間の電話をかけている)に認証情報を要求し、電子フォームあるいは他の手段によってシステムへ認証情報を入力する。カード所有者の購入に際して、カード所有者が認証サービス(ステップ302)で登録されるか否か判断するために、商人は、発行人アクセス制御サーバを伴う商人プラグインを介して通信することができる。これを受けて、発行人は、ACS(アクセス制御サーバ)ＵＲＬエレメント(ステップ304)内にキュエリー・ストリング・パラメーター「IVRNO」を含んでいるVEResメッセージを送信することができる。例えば、次のサンプルURLがVEResメッセージに含まれているかもしれない。
https://securecode,issuer.com/authenticate.asp?IVRNO=MOBO
【００３２】
ACS URLに追加されたこの付加的な質問（キュエリ）ストリング（文字列）パラメータは、商人プラグインに検知され、カード所有者が電話認証のために登録されたこと、および、商人が認証（セキュアコード）のために規定された手段を使用して、MOBO認証を行なわなければならないことを商人に示す。
【００３３】
次に、商人プラグインはPAReqメッセージを生成し、商人データ("##認証タイプ=MOBO##")内に名前/値ペアを追加することができる。その後、商人は、発行人アクセス制御サーバに商人データを送信することができる(ステップ306)。この名前/値ペアは、商人によって送信されたPAReqが電子商取引/オンライントランザクション認証に対立するものとしての電話認証向けであることをアクセス制御サーバに示す。その後、商人は、発行人アクセス制御サーバ(ステップ308)によって提供される認証ウェブ・ページ上で提供される指示に従い、カード所有者から必要な認証情報を集めることができる。その後、商人は、アクセス制御サーバ電子フォームに認証信用証明情報を入力することができる(ステップ310)。電子フォーム(あるいは「仮想ポップ・アップ」)は、発行人認証サービスによって提供されることが好適である。電子フォームはウェブ・インターフェースを使用して、インターネットによって提供することもできるが、あるいは、商人と発行人との間の安全なデータ転送を促進する何らかのソフトウェアアプリケーションを使用して提供することもできる。
【００３４】
次に、好適には、発行人アクセス制御サーバはPAResを生成し(ステップ312)、PAReqのTermＵＲＬエレメントに定義されたURLにPAResを送出する。商人のプラグインは暗号化されたPAResを受け取り、デジタル署名を抽出し、妥当でるか否かを検証することができる(ステップ314)。3Dセキュアプロトコルに従って、その後、商人はPAResからアプリケーション認証値(AAV)を取得し、認証メッセージでAAVを渡すことができる(ステップ316)。最後に、商人は、3Dセキュアプロトコルあるいは他の既知のトランザクション・プロトコルに従ってトランザクションを終えることができる(ステップ318)。
【００３５】
認証（図2Aのステップ214）を行なうための別の典型的なプロシージャは、図3Bに示す。この典型的な実施態様では、対話型の音声応答(「IVR」)アプローチが実現され、ここでは、商人は電話をかけた者（caller）/購入者と電話でトランザクションを行ない、認証目的のために認証情報を入力することを購入者に促すIVRシステムに電話をかけてきた者/購入者を転送し、必要な認証ステップを行なう。
【００３６】
カード所有者の購入に際して、カード所有者が認証サービス(ステップ320)で登録されるか否か判断するために、商人はアクセス制御サーバと商人プラグインを介して通信を行うことができる。次に、発行人は、ACS(アクセス制御サーバ)ＵＲＬエレメント(ステップ322)内にキュエリーストリング・パラメーター「IVRNO」を含んでいるVEResメッセージを送出することができる。例えば、次のサンプルURLがVEResメッセージに含まれているかもしれない。
https://securecode,issuer.com/authenticate.asp?IVRNO=IVR
ACS URLに追加されたこのキュエリーストリング・パラメーターが、商人のプラグインによって検知され、カード所有者が電話認証のために登録され、商人がIVR認証を行なわなければならないことを商人に示す。
【００３７】
次に、商人のプラグインはPAReqメッセージを生成し、例えば、認証用パラメーターを示すために商人のデータ・エレメント内の名前/値ペアを追加するかもしれない。
"##認証タイプ=IVR；電話発信者ＩＤ＝14403528444；転送戻し=Y；転送番号=18004681512##"
【００３８】
その後、商人が、PAReqを発行人アクセス制御サーバに送出することができる(ステップ324)。例えば、上記の値は、商人によって送信されたPAReqは電子商取引/オンライン認証に対立するものとしての電話認証向けのものであること、および、認証手順はIVRであることをアクセス制御サーバに示すことができ、そして、好適には、電話発信者識別情報のような情報、顧客が転送されることとなるＩＶＲ認証の電話番号に関する指示、IVR認証が完了した後で、IVRシステムが商人に電話発信者を転送して戻すか否かをIVRシステムに示す転送戻しフラグを提供する。その後、商人は、IVR認証(ステップ326)を始めるためにキュエリーストリング内で提供された電話番号に電話をかけてきた者（発呼者）を転送することができる。その後、電話をかけてきた者／購入者は、認証のために発行人IVRに転送することができる(ステップ328)。認証は本発明の範囲内の多数の異なる手続きを使用して、行なうことができ、例えば、購入情報を確認するように電話発信者/購入者に促し、カード所有者のセキュアコードのような認証情報を入力する／話すように発呼側／購入者に促すことを含むことができる。次に、発行人アクセス制御サーバは電話をかけてきた者／購入者を認証し、PAResを生成し、TermＵＲＬエレメントに定義されたURLにPAResを送出することもできる(ステップ330)。商人データのパラメーターにそのように指示されている場合、カード所有者を商人に転送して戻すこともできる。その後、商人のプラグインは暗号化された（コード化された）PAResを受け取り、デジタル署名を抽出する／確認することができる(ステップ332)。3Dセキュアプロトコルに従って、その後、商人はPAResからAAVを取得し、認証メッセージでAAVを渡すことができる(ステップ334)。最後に、3Dセキュアプロトコルあるいは他の既知のプロトコルに従って正常なものとして、商人はトランザクションを終えることができる(ステップ336)。
【００３９】
図１−３で示した方法やシステムは、適切なソフトウェアの管理の下で作動する様々な標準的なコンピュータ・プラットフォームを使用して実現することができることは当業者には自明である。ある場合には、従来のパーソナルコンピュータ中の周辺装置カードのような専用コンピュータハードウェアが上記の方法の効率性を向上させるために使用すしてもよい。
【００４０】
図4、5は、本発明を実行するのに適した典型的なコンピュータハードウェアを示す。図4を参照すると、コンピュータシステムは処理セクション410、ディスプレイ420、キーボード430、およびモデムなどの通信周辺機器440を含んでいる。システムはさらにプリンタ460を含むことができる。コンピュータシステムは、データとアプリケーション・ソフトを格納するためのコンピュータが読んだり書き込んだりできる媒体などの磁気媒体(即ちディスケット)のようなおよび／または光学媒体（例えばCD-ROMあるいはDVD）などの1つ以上のディスクドライブ470を典型的には含んでいる。システムは、さらに典型的には、ハード・ディスク・ドライブのような内部コンピュータ可読媒体480を含んでいる。ディジタル・ポインター490（例えばマウス）、決済カード400を読むためのカード読取り装置450のような他の入力装置も含むことができる。図４，５に図示したコンピュータハードウェアを使用して図１−３に図示したソフトウェアを実行することができ、および／または、これらのコンピュータハードウェアを使用して、消費者102、商人104(また、上記に記述した関連する商人プラグイン)、アクワイアラー106、発行人システム108およびディレクトリシステム110によって利用されるコンピュータプロセッサの機能を実行することもできる。
【００４１】
図5は、さらに処理セクション410を示す機能ブロック図である。処理セクション410は、一般に、演算処理ユニット510、制御ロジック520および記憶装置550を含んでいる。好適には、処理セクション410はさらにタイマー530および入出力ポート540を含むことができる。処理セクション410はさらに演算処理ユニットで使用されるマイクロプロセッサーに依存するが、コプロセッサ560を含むことができる。制御ロジック520は、処理ユニット510と共に、記憶装置530と入出力ポート540との間の通信を扱うのに必要な制御を提供する。タイマー550は、演算処理ユニット510および制御ロジック520に対してタイミング基準信号を与える。コプロセッサ560は、暗号アルゴリズムによって要求されるもののようなリアルタイムの複雑な計算を実行するような機能向上を与える。
【００４２】
記憶装置530は、揮発性および不揮発性メモリおよび読み出し専用でプログラム可能なメモリのような異なるタイプのメモリを含むことができる。例えば、図5で示されるように、記憶装置530は読み取り専用メモリ(ROM)531、EEPROM532およびランダムアクセス記憶装置(RAM)533を含むことができる。異なるコンピュータ・プロセッサ、メモリー構成、データ構造およびその他同種のものは、本発明を実行するために使用することができる。また、発明は特定のプラットフォームへ制限されていない。例えば、処理セクション410は、コンピュータシステムの一部として図4および5で示してあるが、コンピュータシステム、処理セクション410、および／または、そのコンポーネントの一部は、PDAまたは携帯電話機に組み入れることができる。
【００４３】
本発明を特定の典型的な実施態様に関して説明してきたが、付属の請求の範囲に示した本発明の範囲および本質から逸脱することなく、開示した実施態様には、当業者であれば様々な変更、置換、代替を施すことができるものと理解すべきである。
【図面の簡単な説明】
【００４４】
【図１】本発明による決済トランザクションを実行するために付加的な典型的なシステムを示すブロック図である。
【図２Ａ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図２Ｂ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図３Ａ】本発明による決済トランザクションを実行するための典型的なプロシージャを示すフローチャートである。
【図３Ｂ】本発明による決済トランザクションを実行するための典型的なシステムを示すフローチャートである。
【図４】本発明による決済トランザクションを実行するために典型的なシステムを示すブロック図である。
【図５】本発明による決済トランザクションを実行するために典型的なシステムを示すブロック図である。
【特許請求の範囲】
【請求項１】
決済口座から支払いを処理して商人と顧客との間で安全なトランザクションを行なう方法であって、
前記決済口座の所有者に関連付けられた第１の認証情報を含むデータベースを提供するステップと、
前記決済口座に関連付けられた決済口座情報が前記トランザクションを行なうために使用される前記決済口座情報を規定するステップと、
前記決済口座情報を含む認証要求をアクセス制御サーバへ送出するステップと、
商人によって認証命令を含む情報を受け取るステップ、
前記顧客から第２の認証情報を受け取るステップ、
前記第１の認証情報と前記第２の認証情報とを比較して、前記トランザクションが前記決済口座の前記所有者によって承認されるか否かを判定するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法において、
前記認証要求に応答する認証応答を送出するステップ、
をさらに含むことを特徴とする方法。
【請求項３】
請求項２に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
前記決済口座情報が、電話を介して提供される、
ことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項６】
請求項２に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
前記認証命令が、IVR認証に関連する情報を含む、
ことを特徴とする方法。
【請求項８】
請求項１に記載の方法において、
前記認証命令が、MOBO認証に関連する情報を含む、
ことを特徴とする方法。
【請求項９】
所有者の決済口座から支払いが処理され、認証を使用して安全なトランザクションを行なう方法であって、
前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用されるような決済口座情報を受け取るステップと、
アクセス制御サーバへ前記決済口座情報を含む認証要求を送出するステップであって、前記認証要求が、電子フォームを表示するために使用されるデータの伝送を、前記サーバに自動的に作動させるようなステップと、
前記所有者から前記電子フォームによって前記認証情報を受け取るステップと、
前記トランザクションを承認する目的のために前記所有者を認証するステップと、
前記トランザクションを承認するステップと、
を含む方法。
【請求項１０】
請求項９に記載の方法において、
前記認証要求に応答する認証応答を受け取るステップ、
をさらに含むことを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項１２】
請求項９に記載の方法において、
前記決済口座情報が電話によって提供される、
ことを特徴とする方法。
【請求項１３】
請求項９に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項１４】
請求項１０に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項１５】
請求項９に記載の方法において、
前記認証命令が、IVR認証に関連する情報を含む、
ことを特徴とする方法。
【請求項１６】
請求項９に記載の方法において、
前記認証命令が、MOBO認証に関連する情報を含む、
ことを特徴とする方法。
【請求項１７】
決済口座から支払いが処理され、認証を使用して安全なトランザクションを行なう方法であって、
前記決済口座の所有者に関連した認証情報の少なくとも第１のセットを含むデータベースを提供するステップと、
前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用される決済口座情報を受け取るステップと、
前記トランザクションを行なうことに関連して、少なくとも前記決済口座情報を含む認証要求を受け取るステップと、
電子フォームの表示を自動的に作動させるステップと、
前記決済口座の前記所有者から認証情報の第２のセットを受け取るステップと、
前記電子フォームに認証情報の前記第２のセットを入力するステップと、
前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが、前記決済口座の前記所有者によって承認されるか否かを判定するステップと、
を含む方法。
【請求項１８】
請求項１７に記載の方法において、
前記認証要求に応答する認証応答を提供するステップ、
をさらに含むことを特徴とする方法。
【請求項１９】
請求項１８に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項２０】
請求項１７に記載の方法において、
前記決済口座情報が、電話によって提供される、
ことを特徴とする方法。
【請求項２１】
請求項１７に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項２２】
請求項１８に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項２３】
安全にトランザクションを行なうシステムであって、
決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも１つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、
自動化された音声応答サブシステムと、
認証サブシステムと、を具え、
前記自動化された音声応答サブシステムが、前記口座所有者に電話を接続して、認証情報の第２のセットを取得し、
さらに、前記認証サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定する、
ことを特徴とするシステム。
【請求項２４】
請求項２３に記載のシステムにおいて、
前記トランザクションが、3Dセキュアプロトコルに従って行なわれる、
ことを特徴とするシステム。
【請求項２５】
商人と口座所有者の間で安全なトランザクションを行なうシステムであって、
決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも1つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、
仮想電子フォームサブシステムと、を具え、
前記仮想電子フォームサブシステムが、前記商人から認証情報の第２のセットを受け取るような電子フォームを前記商人に供給し、
前記サーバコンピュータ・サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定する、
ことを特徴とするシステム。
【請求項２６】
請求項２５に記載のシステムにおいて、
前記トランザクションが、3Dセキュアプロトコルに従って行なわれる、
ことを特徴とするシステム。
【請求項１】
決済口座から支払いを処理して商人と顧客との間で安全なトランザクションを行なう方法であって、
前記決済口座の所有者に関連付けられた第１の認証情報を含むデータベースを提供するステップと、
前記決済口座に関連付けられた決済口座情報が前記トランザクションを行なうために使用される前記決済口座情報を規定するステップと、
前記決済口座情報を含む認証要求をアクセス制御サーバへ送出するステップと、
商人によって認証命令を含む情報を受け取るステップ、
前記顧客から第２の認証情報を受け取るステップ、
前記第１の認証情報と前記第２の認証情報とを比較して、前記トランザクションが前記決済口座の前記所有者によって承認されるか否かを判定するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法において、
前記認証要求に応答する認証応答を送出するステップ、
をさらに含むことを特徴とする方法。
【請求項３】
請求項２に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
前記決済口座情報が、電話を介して提供される、
ことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項６】
請求項２に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
前記認証命令が、IVR認証に関連する情報を含む、
ことを特徴とする方法。
【請求項８】
請求項１に記載の方法において、
前記認証命令が、MOBO認証に関連する情報を含む、
ことを特徴とする方法。
【請求項９】
所有者の決済口座から支払いが処理され、認証を使用して安全なトランザクションを行なう方法であって、
前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用されるような決済口座情報を受け取るステップと、
アクセス制御サーバへ前記決済口座情報を含む認証要求を送出するステップであって、前記認証要求が、電子フォームを表示するために使用されるデータの伝送を、前記サーバに自動的に作動させるようなステップと、
前記所有者から前記電子フォームによって前記認証情報を受け取るステップと、
前記トランザクションを承認する目的のために前記所有者を認証するステップと、
前記トランザクションを承認するステップと、
を含む方法。
【請求項１０】
請求項９に記載の方法において、
前記認証要求に応答する認証応答を受け取るステップ、
をさらに含むことを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項１２】
請求項９に記載の方法において、
前記決済口座情報が電話によって提供される、
ことを特徴とする方法。
【請求項１３】
請求項９に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項１４】
請求項１０に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項１５】
請求項９に記載の方法において、
前記認証命令が、IVR認証に関連する情報を含む、
ことを特徴とする方法。
【請求項１６】
請求項９に記載の方法において、
前記認証命令が、MOBO認証に関連する情報を含む、
ことを特徴とする方法。
【請求項１７】
決済口座から支払いが処理され、認証を使用して安全なトランザクションを行なう方法であって、
前記決済口座の所有者に関連した認証情報の少なくとも第１のセットを含むデータベースを提供するステップと、
前記決済口座に関連付けられた決済口座情報であって、前記トランザクションを行なうために使用される決済口座情報を受け取るステップと、
前記トランザクションを行なうことに関連して、少なくとも前記決済口座情報を含む認証要求を受け取るステップと、
電子フォームの表示を自動的に作動させるステップと、
前記決済口座の前記所有者から認証情報の第２のセットを受け取るステップと、
前記電子フォームに認証情報の前記第２のセットを入力するステップと、
前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが、前記決済口座の前記所有者によって承認されるか否かを判定するステップと、
を含む方法。
【請求項１８】
請求項１７に記載の方法において、
前記認証要求に応答する認証応答を提供するステップ、
をさらに含むことを特徴とする方法。
【請求項１９】
請求項１８に記載の方法において、
前記認証応答に応じて、前記トランザクションを完了させるために前記決済口座からの支払いを処理するステップ、
をさらに含むことを特徴とする方法。
【請求項２０】
請求項１７に記載の方法において、
前記決済口座情報が、電話によって提供される、
ことを特徴とする方法。
【請求項２１】
請求項１７に記載の方法において、
前記決済口座情報が、コンピュータネットワークを介して提供される、
ことを特徴とする方法。
【請求項２２】
請求項１８に記載の方法において、
前記認証要求および前記認証応答が、3Dセキュア認証プロトコルによってフォーマットされる、
ことを特徴とする方法。
【請求項２３】
安全にトランザクションを行なうシステムであって、
決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも１つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、
自動化された音声応答サブシステムと、
認証サブシステムと、を具え、
前記自動化された音声応答サブシステムが、前記口座所有者に電話を接続して、認証情報の第２のセットを取得し、
さらに、前記認証サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定する、
ことを特徴とするシステム。
【請求項２４】
請求項２３に記載のシステムにおいて、
前記トランザクションが、3Dセキュアプロトコルに従って行なわれる、
ことを特徴とするシステム。
【請求項２５】
商人と口座所有者の間で安全なトランザクションを行なうシステムであって、
決済口座の口座所有者に関連する認証情報の第１のセットを少なくとも含む、少なくとも1つの決済口座に関連する情報を含むサーバコンピュータ・サブシステムと、
仮想電子フォームサブシステムと、を具え、
前記仮想電子フォームサブシステムが、前記商人から認証情報の第２のセットを受け取るような電子フォームを前記商人に供給し、
前記サーバコンピュータ・サブシステムが、前記認証情報の第１のセットと、前記認証情報の第２のセットとを比較して、前記トランザクションが前記口座所有者によって承認されるか否かを判定する、
ことを特徴とするシステム。
【請求項２６】
請求項２５に記載のシステムにおいて、
前記トランザクションが、3Dセキュアプロトコルに従って行なわれる、
ことを特徴とするシステム。
【図１】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【公表番号】特表２００７−５２３４０５（Ｐ２００７−５２３４０５Ａ）
【公表日】平成１９年８月１６日（２００７．８．１６）
【国際特許分類】
【出願番号】特願２００６−５５１４７１（Ｐ２００６−５５１４７１）
【出願日】平成１７年１月２４日（２００５．１．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００２５９１
【国際公開番号】ＷＯ２００５／０７２３８２
【国際公開日】平成１７年８月１１日（２００５．８．１１）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
【公表日】平成１９年８月１６日（２００７．８．１６）
【国際特許分類】
【出願日】平成１７年１月２４日（２００５．１．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００２５９１
【国際公開番号】ＷＯ２００５／０７２３８２
【国際公開日】平成１７年８月１１日（２００５．８．１１）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
[ Back to top ]