JP2005523505A - モバイル口座認証サービス - Google Patents

Abstract

【解決手段】 支払認証サービスは、オンライン取引の際に支払人のＩＤを認証する。この認証サービスは、カード発行者がカード所有者（１１０）のＩＤを、例えばトークンを使用するなどの様々な認証方法を使用して検証することを可能にする。オンライン取引の際に生じるカード所有者（１１０）のＩＤの認証は、カード所有者（１１０）が支払認証サービスに登録されているか否かを決定するためにアクセス制御サーバに照会する工程と、カード所有者にパスワードを要求する工程と、パスワードを検証する工程と、カード所有者（１１０）の認証性が検証されたか否かを商人に通知する工程とを含む。この認証サービスを実装するためのシステムが、カード所有者（１１０）が使用しているデバイスがインターネットを通じてメッセージを伝送できるモバイルデバイスである場合に関して説明される。また、この認証サービスを実装するためのシステムが、カード所有者（１１０）が使用しているデバイスが音声チャネル及びメッセージングチャネルを通じてメッセージを伝送できるモバイルデバイスである場合に関しても説明される。

Description

本発明は、概して、モバイル電子商取引に関する。本発明は、より具体的には、モバイル取引の際に口座所有者のＩＤを認証することに関する。

決済カード（例えばクレジットカード、デビットカード、または電子財布型カードなど）を使用した支払取引の際は、カード所有者が口座を所有しているか否かを検証することによって、無許可使用などの様々な問題を回避することが重要である。支払人の認証は、カード所有者が口座を所有しているか否かを検証するプロセスである。カード所有者が口座を所有しているか否かを検証するために最も良く用いられる方法は、いわゆる「有カード」取引の販売時点で定期的に生じる。有カード取引は、商人の代表がカード所有者のカードを受け取り、それを決済カード端末に通して口座状況及び信用限度枠を検査し、次いで、カードの裏面の署名が購入者の署名と一致するかをチェックすることを含む。署名の比較は、口座の所有の有無を認証することを可能にする。商人は、この種の取引に特有のガイドラインに従うことによって、割引額を差し引いた指定金額の支払いを保証される。これらの特有のガイドラインは、ビザ・インターナショナル・ザービス・アソーシエーション（または他のサービス組織）などのサービス会社によって提供されて良い。

一方で、モバイルトデバイス、メール、または電話を通じてオンラインで生じる「無カード」取引は、商人への保証がない支払いを伴う。オンライン取引は、例えばインターネットを通じて行われる取引を含む。保証がないのは、主に、このような非対面取引では支払人の認証が行われないからである。したがって、「無カード」取引は、多くのリスクを伴う。このようなリスクとしては、支払取引がオンライン商人に不渡りを生じる、商人及びカード所有者の両方に不正行為が行われる、銀行にとって例外小切手処理の費用が増大する、並びに、オンラインでのまたはモバイルトデバイスを通じての商品及びサービスの購入が安全性及び信頼性に欠けるという認識の広まりによってオンライン購入を控える顧客が増える、などの事例が挙げられる。また、他のリスクとして、盗んだ口座情報を無許可で使用して商品及びサービスのオンライン購入を行う、カードの口座情報を捏造して不正なオンライン購入を行う、並びに、ネットワークトラフィックから平文の口座情報を抽出する、などの事例も挙げられる。

電子商取引の継続的な高成長を見込むためには、支払人を認証する方法を提供することが重要である。これは、カード所有者、商人、及び金融機関を含む、支払システムのあらゆる参加者を利することができる。オンライン支払取引の際における支払人の認証は、不正取引、紛争、情報の取り出し、及び不渡りなどを減らし、ひいては、これらの各事例に伴って生じる費用を削減することができる。支払人の認証は、また、セキュリティ面に関する顧客の懸念にも対処しうるので、オンラインの販売またはモバイルトデバイスを通じた販売を増進させることができる。オンライン取引の際に顧客を認証するために使用されてきた従来のシステムは、使用が困難で、複雑な設計を有し、システムの参加者による大きな先行投資を必要とし、相互運用性に欠けるという理由で広く採用されなかった。また、従来のシステムのなかには、更に、商人、カード所有者、発行者、及び支払人による証明書の作成、配布、並びに使用を必要とするものがある。このような証明書の使用は、非常に負担が大きいことが知られている。

以上から、オンライン取引またはモバイル取引の際に支払人のＩＤを認証するためのシステムが望まれていることがわかる。このような認証システムは、実装及び使用が比較的容易で、必要なリソース投資が最小限で良く、尚かつ、システムの参加者の間でハイレベルな相互運用性を実現できる必要がある。

本発明は、オンライン取引及びモバイル取引の際に口座所有者のＩＤを認証するための技術に関する。本発明は、実装及び使用が比較的容易で、実装のために必要なリソース投資が最小限で良く、尚かつ、システムの参加者間でハイレベルな相互運用性を実現することができる。本発明による認証サービスは、信用者が口座所有者のＩＤを、パスワード及びトークンなどの様々の認証技術によって検証することを可能にする。本発明による認証サービスは、また、チェックアウトプロセスの際に認証結果をリアルタイムで商人に提供することができる。本発明は、口座所有者がモバイルトデバイスを使用してサービスにアクセスする場合に認証サービスを実装するプロセス及びシステムを提供する。これらのプロセス及びシステムは、インターネット、音声チャネル、及びテキストメッセージチャネルを通じてメッセージを送信するモバイルトデバイスをサポートする。

本発明の一態様は、口座所有者のＩＤを認証するための方法に関する。口座所有者は、インターネットを通じてメッセージを送受信できるモバイルトデバイスを使用する。この方法は、取引を行うために、要求者と口座所有者との間に通信接続を確立する工程と、信用者において、圧縮版の支払認証応答メッセージ（ＣＰＲＳ：condensed payment authentication response message）を作成する工程と、ＣＰＲＳを、口座所有者を介して要求者に送信する工程と、要求者に設けられたメモリデバイスから、第１のデータフィールドセットを検索する工程と、要求者において、圧縮版のＣＰＲＳを第１のデータフィールドセットと組み合わせることによって、完全版のＣＰＲＳを構成する工程と、完全版のＣＰＲＳが、口座所有者のＩＤが認証されたことを示す場合に、口座所有者と要求者との間における取引に与信する工程とを備える。

本発明の第２の態様は、上述された方法をサポートするためのシステムに関する。このようなシステムは、取引を処理するために、口座所有者と通信するように構成された商人サーバと、信用者によって制御され、圧縮版のＣＰＲＳを作成するように構成されたアクセス制御サーバと、商人メモリユニットを有した商人プラグインソフトウェアモジュールであって、圧縮版のＣＰＲＳを受信し、商人メモリユニットから第１のデータフィールドセットを検索し、圧縮版のＣＰＲＳを第１のデータフィールドセットと組み合わせることによって完全版のＣＰＲＳを構成するように構成された商人プラグインソフトウェアモジュールとを備える。

本発明の第３の態様は、口座所有者のＩＤを認証するための方法に関する。口座所有者は、音声メッセージ及びテキストメッセージの一方または両方を送受信できるモバイルデバイスを使用する。この方法は、第１の音声チャネルまたはメッセージチャネルを通じて、口座所有者と要求者との間に取引を確立して実行する工程と、支払認証要求メッセージ（ＰＡＲｅｑ：payment authentication request massage）を、インターネットを通じて要求者から信用者に送信する工程と、第２の音声チャネルまたはメッセージチャネルを通じて、口座所有者と信用者との間に接続を確立する工程と、認証トークンを、第２の音声チャネルまたはメッセージチャネルを通じて口座所有者から信用者に伝送する工程とを備える。

本発明の更に別の一態様は、上述された方法をサポートできるシステムに関する。このシステムは、取引を処理するために口座所有者と通信するように構成された商人サーバと、商人プラグインソフトウェアと、支払人認証要求メッセージを含み、インターネットを通じて商人プラグインソフトウェアモジュールから信用者に提供される第１のＨＴＭＬフォームと、商人サーバと口座所有者との間に確立され、取引を行うために使用される第１の音声チャネルまたはメッセージングチャネルと、信用者によって制御されるアクセス制御サーバと、口座所有者とアクセス制御サーバとの間に確立された第２の音声チャネルまたはメッセージチャネルと、第２の音声チャネルまたはメッセージチャネルを通じて口座所有者からアクセス制御サーバに伝送され、アクセス制御サーバによって口座所有者のＩＤの認証に使用されるように構成された認証トークンとを備える。

本発明の上記の及びその他の特徴並びに利点は、以下の詳細な発明の説明及び本発明の原理を例示した添付の図面に詳しく示される。

本発明及び本発明によって得られる更なる利点は、添付の図面と併せて行う以下の詳細な説明から最も良く理解することができる。

以下では、添付の図面に示されたいくつかの好ましい実施形態を参照にしながら本発明の詳細な説明を行う。以下の説明では、本発明の十分な理解を可能にするために数多くの詳細を特定している。しかしながら、当業者ならば承知のように、本発明は、これらの詳細の一部または全部を特定しなくても実施することができる。また、本発明の理解を不必要に曖昧にしないために、周知の動作の詳細な説明は省略した。

先ず、コア口座認証システム及びプロトコルの概要から説明する。口座認証システムは、参加者である発行者、口座所有者、及び商人に対するサービスの形で提供される。先ず、オンライン支払取引に関するコア口座認証システムの実装から説明する。オンライン支払取引の説明では、認証システム及びそれに類似したプロトコル、並びに非支払取引に使用されるプロトコルの詳細を明らかにする。なぜなら、支払取引及び非支払取引は、いずれも口座所有者のＩＤの認証を伴うからである。オンライン支払取引の説明では、支払取引それ自体、システムのセットアップ、顧客の登録、及び特定のメッセージフローを取り上げる。コア口座認証システム及びプロトコルの説明に続いて、口座認証システムの様々な態様を説明する。これらの代替の実装形態は、口座所有者または顧客が、インターネット互換性のデバイス及び非インターネット互換性のデバイスなどのモバイルデバイスを使用することを可能にする。コア口座認証システムは、モバイルデバイス実装形態の基礎を成す。

各種の実装形態のための口座認証システム
口座認証システムは、一方の参加者が特定の口座の所有者であると主張する他方の関係者のＩＤを物理的に検証できない取引の際に、カード所有者の口座所有の有無を認証するように設計される。例えば、口座認証システムは、ある個人またはエンティティのＩＤを信用者が第三者のために認証する様々な取引に使用することができる。周知のように、信用者は、一般に、個人またはエンティティの認証を行う法的責任を第三者に対して負う。口座認証システムの重要な用途の１つは、当然ながら、オンラインでまたは携帯電子デバイスを通じて行われる支払取引の分野にある。

しかしながら、口座認証システムは、支払取引以外の様々な用途でも有用である。例えば、非支払取引は、金融機関の顧客がインターネットのウェブサイトにアクセスしてオンラインフォームに記入する際にその顧客を認証するなどの取引を含む。非支払取引は、また、小売金融業務、卸売金融業務、医療業務、保険業務、及び仲買業務などの様々な態様を例として含む。小売金融業務は、デビットカード、購入カード、及び電子財布型カードなどのカードと共に使用される口座番号を伴う。非支払取引は、また、識別カードを使用する取引も含む。例えば、ＡＡＡは、口座認証システムを使用してその一顧客のＩＤを認証することができるし、テレフォンカード会社は、口座認証システムを使用して特定のカードのユーザのＩＤを認証することができる。

図１は、様々な口座認証用途に合わせて口座認証システムを実装するためのコアシステムアーキテクチャ１５００の一実施形態を示している。システムアーキテクチャ１５００は、信用者ドメイン１５０２、相互運用性ドメイン１０４、及び第三者または要求者ドメイン１５０６の３つのドメインを含む。信用者ドメイン及び第三者ドメインの中には、それぞれ信用者及び第三者によって完全に若しくは少なくとも部分的に制御されるコンポーネントを有した機能的な領域が定義されている。相互運用性ドメインの中には、信用者、第三者、及びサービス組織などの他の関係者が利用できるコンポーネントを有した機能的な領域が定義されている。

信用者ドメイン１５０２は、主に信用者によって制御されるコンポーネントを含む。信用者の一例は、顧客に決済カードを発行する金融機関であり、発行銀行として知られる。具体的に言うと、発行者、すなわちカード発行者は、カード供給者から受け取った新しいカードを個人化し、それらのカードを顧客に発行する。個人化は、あるいは、カード供給者または個人化代理機関が実施して良い。発行者は、金融機関以外にも、例えば、通信ネットワークオペレータ、サービスアソーシエーション、商人または他の組織、ひいては発行者を代行するエージェントなど、任意の適切な発行エンティティであって良い。第三者または要求者ドメイン１５０６は、主に第三者及び要求者の両方または一方によって制御されるコンポーネントを含む。要求者は、口座所有者のＩＤの認証を要求する任意の関係者であって良い。要求者は、例えば、クレジットカードの口座の所有者であることを主張する人物のＩＤの認証を望む商人であって良い。第三者は、商人を支払スキームに登録すると共にそれらの商人の口座を管理している金融機関、すなわち決済者であって良い。決済者は、また、オンライン商人からの情報を通信ネットワークに送ることも行う。他の実施形態では、商人が直接に、通信ネットワークに情報を送ることができる。

相互運用性ドメイン１０４は、インターネットによってサポートされ、信用者及び第三者の両者によって使用されるコンポーネントを含むことができる。

信用者ドメイン１５０２は、発行者のカード所有者システム１１０、登録サーバ１１２，アクセス制御サーバ（ＡＣＳ）１１４、及び口座所有者ファイル１１８を含む。信用者ドメイン１５０２は、システムが使用される分野の種類に応じて追加のコンポーネントを含む。例えば、後述される支払取引では、各ドメインが追加のコンポーネントを含む。これらの追加のコンポーネントは、支払取引に関連して口座所有者のＩＤを認証することを目的とする。

登録サーバ１１２は、口座所有者による返信及び信用者による検証を受ける一連の質問を、ウェブインターフェースを介して提示することによって、口座認証システムにおける口座所有者の登録を管理するコンピュータである。図１に示されるように、登録サーバ１１２を運用するのは信用者である。しかしながら、登録サーバ１１２は、信用者の代わりにＶｉｓａなどのサービス組織が運用しても良い。信用者は、外部エンティティによって提供されるウェブ対応型の双方向「ＩＤ認証サービス」を登録プロセスの際に使用し、口座所有者のＩＤを検査する手助けとして良い。

ＡＣＳ１１４は、口座認証システムによって提供される口座認証サービスに登録された口座所有者のデータベースを有するコンピュータである。ＡＣＳ１１４は、各口座所有者の口座情報及びパスワード情報を含む。口座認証取引の際に、ＡＣＳ１１４は、デジタル署名付きのレシートを認証要求者に提供し、口座認証システムへのアクセスを制御し、口座所有者が同サービスに参加しているか否かを検査する。ＡＣＳ１１４は、信用者の代わりに、Ｖｉｓａなどのカード発行者すなわちサービス組織が運用して良い。口座認証サービスは、追加のカード所有者ソフトウェアを利用する必要はないが、任意の口座所有者ソフトウェア及び口座所有者ハードウェアを配備することが可能である。追加の口座所有者ソフトウェアは、デジタル証明書、集積回路カード（チップカード）、及びチップカードリーダなどの追加の認証技術をサポートすることができる。なお、本発明において、証明書を必要とする唯一のシステム参加者は発行金融機関である。

口座所有者ファイル１１８は、口座所有者システム１１０に首尾良く登録された口座所有者に関する情報を格納するデータベースであり、信用者によって管理される。発行者のカード所有者システム１１０（すなわち信用者の口座所有者システム）は、信用者によって制御され、口座所有者に関する情報を含む。このような情報は、口座情報、及びカード所有者によって使用されるサービスなどに関する。発行者のカード所有者システム１１０に含まれる情報は、一部には、口座所有者を口座認証サービスに登録するために使用することができる。

第三者または要求者ドメイン１５０６の第三者または要求者１５３２は、口座所有者の認証を望むのが通常である。第三者または要求者１５３２は、認証プロトコルを容易にする要求者のプラグインソフトウェア１５３４を管理する。要求者のプラグインソフトウェアモジュール１５３４は、第三者または要求者のウェブサイトに組み込まれるソフトウェアモジュールである。プラグインソフトウェアモジュール１５３４は、口座認証システムと、第三者の処理ソフトウェアと、の間にインターフェースを提供する。第三者の処理ソフトウェアは、例えば、商人の支払処理ソフトウェアなどである。

相互運用性ドメイン１０４は、ディレクトリサーバ１２８を含み、インターネットによってサポートされ、尚かつ、信用者及び第三者の両者に使用されるコンポーネントを含む。ディレクトリサーバ１２８は、要求者からの認証要求を、ＡＣＳ１１４などの特定のＡＣＳへと送る。ディレクトリサーバ１２８は、Ｖｉｓａなどのカードスキームマネージャすなわちサービス組織によって運用される。また、相互運用性ドメイン１０４は、インターネット以外のネットワークによってサポートすることもできる。

支払取引のための口座認証システム
次に、支払取引の分野で口座所有者を認証するためのシステムアーキテクチャを説明する。なお、この節で説明される一般概念の多くは、様々な使用分野に適用可能である。これは、支払を用途とする認証プロセスが、非支払を用途とする認証プロセスに類似しているからである。

以下では、支払取引における認証システム及び認証プロトコルの典型的な使用例を説明する。認証システムは、カード所有者がオンラインでショッピングし、「ショッピングカート」に商品を入れ、オンライン商人のチェックアウトページに進み、オンライン商人のチェックアウトフォームに記入するという筋書きにおいて有用である。認証プロセスは、例えば顧客が「購入」ボタンをクリックした後など、顧客が自分の望む商品またはサービスの購入を決定した後に生じることができる。認証プロセスは、また、顧客による支払取引の様々な時点で開始することもできる。認証プロセスは、大抵は、支払ネットワークのいくつかのポイントに組み込まれたソフトウェアによって、顧客からは見えない透過モードで行われる。認証システムは、カード所有者及びカード所有者の金融機関が認証サービスに参加しているか否かを検査する。次いで、予め登録されているパスワードをカード所有者に要求するウィンドウが作成される。顧客は、このウィンドウによって、自分のＩＤを確認することができる。顧客のＩＤが確認されると、支払情報と、顧客の認証に関する通知とが商人に返される。次いで、従来技術の場合と同様に、商人による支払取引が行われる。商人は、例えば、カード所有者のブラウザに注文確認メッセージを送信することができる。

図２は、支払取引において認証サービスをサポートするシステムアーキテクチャ１００の一実施形態を図式化している。図１に示された一般的なシステムアーキテクチャ１５００と同様に、システムアーキテクチャ１００は、発行者ドメイン１０２、相互運用性ドメイン１０４、及び決済者ドメイン１０６の３つのドメインに分けられる。図２の発行者ドメイン１０２及び決済者ドメイン１０６は、図１の信用者ドメイン１５０２及び第三者または要求者ドメイン１５０６にそれぞれ類似している。

発行者ドメイン１０２は、登録サイト１０８、発行者のカード所有者システム１１０、カード所有者のクライアントデバイス１２２、登録サーバ１１２、アクセス制御サーバ（ＡＣＳ）１１４、発行者または第三者のＩＤ認証コンポーネント１１６、及び口座所有者ファイル１１８を含む。発行者ドメイン１０２は、状況に応じ、承認済みカード所有者の発行者ファイル１２０を含むことができる。登録サーバ１１２は、口座所有者による返信及び発行者による検証を受ける一連の質問を、ウェブインターフェースを介して提示することによって、口座認証システムにおける口座所有者の登録を管理するコンピュータである。登録サーバ１１２は、インターネットを通じてインターネット支払ゲートウェイサービス１２４に接続され、インターネット支払ゲートウェイサービス１２４は、例えばＶｉｓａＮｅｔなどの通信ネットワーク１２６に接続される。インターネット支払ゲートウェイサービス１２４は、登録サーバ１１２が通信ネットワーク１２６と通信することを可能にする。支払ゲートウェイサービス１２４を介した接続によって、登録サーバ１１２は、発行者の与信システム１２７に照会し、登録されているカード所有者が活動カード口座を有するか否かを決定することができる。登録サイト１０８は、インターネットウェブサイトである。このウェブサイトによって、カード所有者は、口座認証システムによって提供される口座認証サービスに参加登録することができる。

カード所有者のクライアントデバイス１２２は、カード所有者が口座認証システムに参加するために使用される。具体的に言うと、カード所有者のクライアントデバイス１２２は、パソコン、移動電話、携帯情報端末、または双方向ケーブルテレビなど、インターネットにアクセスすることができる任意のデバイスである。いくつかの実施形態では、カード所有者のクライアントデバイス１２２は、インターネットに接続できない。しかしながら、カード所有者は、このようなデバイスを使用することができる。なぜなら、クライアントデバイス１２２からの入力メッセージ及び出力メッセージは、非インターネットベースのメッセージを扱うことのできる特別なノードを通じて送られるからである。例えば、音声メッセージ及びテキストメッセージの両方または一方に基づいてメッセージの送受信を行う移動電話は、インターネットに接続しない。しかしながら、これらのデバイスは、異なる方法によるメッセージの経路を使用すれば、口座認証システムに使用することが可能である。ショートメッセージサービス（ＳＭＳ）は、良く使用されるメッセージシステムの一例である。音声自動応答（ＩＶＲ）装置は、音声チャネルを通じて自動交換を行うために使用することができる。このメッセージ経路構成は、インターネット接続不可のデバイスに関する後続の節において詳細に説明される。

発行者のカード所有者システム１１０は、カード所有者に関する情報を含むシステムであり、発行者によって制御される。このシステム情報は、口座情報、及びカード所有者によって使用されるサービスなどに関する情報を含む。発行者のカード所有者システムに含まれる情報は、一部には、カード所有者を口座認証システムに登録するプロセスで使用することができる。

発行者または第三者のＩＤ認証データベース１１６は、発行者または第三者がカード所有者に関して既に有している情報を含む。データベース１１６は、カード所有者の登録プロセスにおいて、カード所有者のＩＤを検証するために発行者によって使用される。例えば、カード所有者が、口座認証システムによって提供されるサービスへの登録に成功するためには、口座所有者の登録プロセスの際にカード所有者によって入力される情報が、認証データベース１１６の中に既に存在する情報に一致しなければならない。第三者は、イクイファックス社などの企業であって良い。

相互運用性ドメイン１０４は、ディレクトリサーバ１２８、認証履歴サーバ１３０、及びレシートマネージャ１３１を含む。ディレクトリサーバ１２８は、商人からの認証要求を特定のＡＣＳへと送る。ディレクトリサーバ１２８は、Ｖｉｓａなどのサービス組織によって運用される。認証履歴サーバ１３０及びレシートマネージャ１３１は、認証された各支払取引に関する署名付きレシート（例えば後述される支払要求応答メッセージのコピーなど）を格納する。認証履歴サーバ１３０は、どの取引が認証されたかを検証するための情報を含み、紛争解決プロセスの際に追加の情報を提供することができる。認証履歴サーバ１３０及びレシートマネージャ１３１は、サービス組織によって運用される。発行者、支払人、または商人も、デジタル署名されたレシートのコピーを維持することができる。

決済者ドメイン１０６は、商人１３２及び検査サーバ１３６を含む。商人１３２には、商人プラグインソフトウェアモジュール１３４が常駐している。商人プラグインソフトウェアモジュール１３４は、商人の電子商取引ウェブサイトに組み込まれるソフトウェアモジュールである。商人プラグインソフトウェアモジュール１３４は、口座認証システムと、商人の支払処理ソフトウェアと、の間にインターフェースを提供する。検査サーバ１３６は、口座認証システムから商人へと返されたレシートの署名に使用された、カード発行者のデジタル署名を、支払取引の際に検証する。代替の実施形態では、検査サーバ１３６の機能を商人プラグインソフトウェアモジュール１３４に含ませることによって、検査サーバ１３６を別途に設ける必要をなくすことができる。検査サーバ１３６は、商人、支払人、またはサービス組織によって運用される。

いくつかの実施形態では、口座認証システムは、例えば電子財布などのカード所有者の他の用途と相互運用することができ、口座認証サービスは、電子商取引マークアップ言語（ＥＣＭＬソフトウェア）と矛盾なく動作することができる。口座認証システムは、また、紛争解決の手続きを実装する能力を提供することもできる。例えば、商人は、カード所有者の認証証明を提供するのに十分な情報を保持することによって、紛争解決及び不渡りに備えることができる。

セットアップ及び登録の説明
次に、支払取引及び非支払取引の両者に関して口座認証システムのセットアップを詳細に説明する。先ず、システムの各参加者をセットアップし、各参加者が口座認証システムを使用できるようにする手続きを説明する。次いで、口座所有者が口座認証システムに登録するためのプロセスを説明する。その後、実際に支払取引に与信するプロセスの詳細を説明する。

口座認証システムのセットアップは、システムのあらゆる参加者をセットアップする手続きを含む。これらのセットアップ手続きは、一般に、支払取引及び非支払取引のいずれに与信する場合も同様である。これらの参加者は、商人または他の認証要求者、金融機関または他の信用者、及び口座所有者またはカード所有者を含む。

口座認証システムに加入しているオンライン商人などの要求者は、図１のプラグインソフトウェアモジュール１５３４及び図２のモジュール１３４などのプラグインソフトウェアモジュールを受信する。プラグインソフトウェアモジュールは、要求者が使用する計算プラットフォーム及びサーバソフトウェアに固有であることが好ましい。口座認証システムに参加している金融機関などの要求者は、サービスロゴ及びマーケティングデザインなどを提供し、カスタマイズされた自身の登録サイトテンプレートにそれを組み込む。また、決済銀行である第三者は、クライアントを認証するためのサービス組織認証局（ＣＡ）ルート証明書及びサービス組織認証局ＳＳＬ証明書、並びに組み込み機能を商人に提供することが好ましい。

口座認証システムの使用に向けてセットアップされる前に、信用者は、信用者ドメインで指定されたあらゆる口座認証システムハードウェア及びソフトウェアのコピーを取得及びインストールしなければならない。発行者である金融機関などの信用者は、そのほかにも、カード所有者のＩＤを検証するプロセスで使用されるＩＤ認証ポリシー及び参加ＢＩＮ情報を口座認証システムに提供する。発行者は、また、状況に応じ、口座所有者ファイル１１８にプリロードされるカード所有者認証情報を口座認証システムに提供することができる。プリロードは、カード所有者の大量サポートを容易にする。例えば、ある信用者が、口座認証サービスに備えて全部または大部分のカード所有者をアクティブ化することを望む場合は、その信用者は、全てのカード所有者に個人識別番号（ＰＩＮ番号）を送信することができる。こうすれば、各カード所有者は、自分のＰＩＮ番号を使用して、プリロードされた自分のパスワードにアクセスすることができる。このように、各カード所有者は、正式な登録プロセスを経る必要がないので、結果として、登録プロセスは迅速化される。カード所有者は、プリロードされたパスワードを最初に使用した後、記憶しやすい新しいパスワードを指定することもできる。

カード所有者認証情報は、業種識別番号、国別コード、カードの口座番号、カードの有効期限、カード所有者の氏名、及び「加入者ＢＩＮ」データに定義された発行者に固有の認証データ（例えば母親の旧姓など）などの情報、並びに請求書送付先、商品届け先、社会保障番号、電話番号、勘定残高、取引履歴、及び運転免許証番号などの他の情報を含む。信用者は、また、カードの口座を一覧するための口座番号範囲及びＡＣＳのＩＰアドレス（ＵＲＬ）も、ディレクトリサーバに提供することが好ましい。口座認証システムの支払用途に関しては、銀行ブランドのウェブサイトを通じて口座認証サービスを提供することができ、これは、カード所有者の登録を可能にする。

図３は、本発明の一実施形態にしたがって、口座所有者が口座認証システムに登録するプロセスを示している。ステップ１に示されるように、口座所有者は、先ず、発行者である金融機関などの信用者に維持されている登録サーバインターネットウェブサイトを訪れる。口座所有者は、自分の口座番号を登録することによって、口座認証システムに登録する。例えば支払取引の場合は、口座所有者は、自分のクレジットカード、チェックカード、またはデビットカードの口座番号を登録することができる。非支払取引の場合は、口座所有者は、保険会社または仲買会社に管理されている口座番号を登録することができる。口座所有者は、１枚またはそれ以上のカードを登録することができる。

ステップ２において、口座所有者は、主要口座番号（ＰＡＮ）、氏名、及びカードの有効期限などの情報を入力する。口座所有者は、このとき、追加の情報を入力することもできる。口座所有者は、例えば、住所、メールアドレス、ショッパＩＤ、口座検証値、カード所有者に固有なパスワード、及び発行者に固有な認証情報などの情報を入力することができる。これらの情報は、図４に示されたページ３００などの登録ウェブサイトのページに入力することができる。

口座所有者が、要求された情報を登録サイト１０８に入力し終えると、口座認証システムは、口座所有者のＰＡＮが、信用者によって相互運用性ドメイン１０４のディレクトリサーバ１２８に登録されたカード範囲に含まれるか否かを検証する。口座所有者のＩＤは、様々な方法で検証することができる。先ずは、先ほど言及したように、第三者の認証データベースまたは信用者自身の認証データベースを通じて口座所有者のＩＤを検証することができる。また、信用者から提供された承認済みカード所有者のファイル１２０を使用する、状況チェックの承認を信用者に伝送する、及び金融機関から提供されたプリロード情報に応答を照らし合わせるなどの方法によって、口座所有者のＩＤを検証することもできる。

ＰＡＮが登録カード範囲に含まれない場合は、登録は拒絶され、登録プロセスは終了する。支払取引において、もしＰＡＮが登録カード範囲に含まれる場合は、１ドル（または他の任意の額面価額）に相当する与信が、ＶｉｓａＮｅｔなどのサービス組織支払ネットワークを通じて発行者である金融機関にサブミットされる。１ドル取引の与信によって、発行者は、カードの口座状況、アドレス検証サービスを使用しているアドレス、及びカード所有者検証値２（ＣＶＶ２）を検証することが可能になる。ＣＶＶ２は、決済カードの裏面の署名欄に印刷された３桁の数字である。非支払取引において、もしＰＡＮが登録カード番号の範囲に含まれる場合は、１ドル取引の与信は不要である。

ステップ３において、口座所有者は、リアルタイムの対話式オンラインセッションにおける口座所有者のＩＤの検証のために、追加の認証情報を提供するように促される。いくつかの実施形態では、口座所有者は、口座所有者を認証するために使用される、パスワード及び一対の「ヒント付きの質問及び応答」を、認証取引の際に入力するように要求される。

ステップ４に示されるように、口座所有者のＩＤが検証され、妥当な応答が返された場合は、発行者である金融機関に与信メッセージが送信される。次に、ステップ５において、登録サーバ１１２は、口座所有者情報をＡＣＳ１１４に引き渡すことによって、口座所有者ファイル１１８の記録をセットアップする。口座所有者ファイル１１８は、金融機関のＢＩＮ番号、口座番号、有効期限、フルネームの氏名、運伝免許証番号、請求書送付先、社会保障番号、カード所有者のパスワード、カード所有者のパスワードに関する質問、カード所有者のパスワードに関する答え、カード所有者のメールアドレス、第三者のＩＤスコア、及び他の情報などの情報を格納することができる。

いくつかの実施形態では、口座所有者は、個人保証メッセージ（ＰＡＭ）と称される、自分ですぐにわかるフレーズを、登録プロセスの際に入力するように求められる。ＰＡＭは、のちの認証プロセスの際に、信用者によって口座所有者に提示される。口座所有者によって指定されたＰＡＭを知るのは信用者のみであるので、口座所有者は、口座認証システムで使用されている対話ウィンドウが確かに信用者から送られたものであることを確認することができる。ＰＡＭの一例は、「空は青い」である。

なお、口座所有者は、認証システムを使用するに当たって、新しいクライアントソフトウェアまたはクライアントデバイスを必要としない。好ましい一実施形態では、口座所有者の登録プロセスは、口座所有者と登録サーバとの間でインターネットを通じて伝送されるデータを保護するために、ＳＳＬチャネル暗号化などのセキュリティプロトコルを使用して行われる。

また、各信用者は、自身の「利用規約」及び「データプライバシーに関する方針」の一方または両方を、登録プロセスの際に表示することができる。登録プロセスを完了させるに当たって、各信用者は、登録しようとしている口座所有者に、規約及び方針に同意するまたは同意しないのいずれかを選択するように要求することができる。信用者は、各口座所有者が同意した「利用規約」及び「データプライバシーに関する方針」の一方または両方のヴァージョン番号を保管しておくことが好ましい。

支払取引の説明
全ての参加者がセットアップされ、尚かつ、口座所有者が登録された後は、口座の認証が実施される。口座の認証は、参加者が使用するシステムの種類に応じ、様々な方法で実施することができる。以下で説明される３つの実装形態は、それぞれ、インターネットに接続された従来のコンピュータ（図５〜８）、インターネットに接続するモバイルデバイス（図９）、及びインターネットに接続できないモバイルデバイス（図１０〜１２）に関する。後述されるように、これらの３つの形態の主な相違は、（要求者ドメインの中の）プラグインソフトウェアモジュールと、（信用者ドメインの中の）アクセス制御サーバと、の間で支払要求及び支払応答のメッセージがどのように作成され伝送されるかという点にある。なお、図５〜１２が示しているのは、支払取引において口座所有者のＩＤを認証するプロセスである点に留意せよ。

口座所有者が、インターネットにリンクされた従来のコンピュータを使用する筋書きに関し、図５は支払取引の大まかな概略を示し、図７は取引の際に伝送される特定のメッセージを詳しく示し、図８は支払取引をある程度詳しく示している。これらの支払取引に関する説明は、非支払取引のための認証プロセスをも十分に説明することができる。非支払取引に特有な説明は、以下の説明の至る所に適宜挿入されるものとする。

図５は、口座所有者がインターネットに接続されたコンピュータを使用する場合に関し、コア口座認証システムを使用して行われる認証された支払取引を説明している。図５のステップ１において、口座所有者は、インターネット上にある商人の電子商取引サイトを訪れる。口座所有者は、カード所有者と称することもできる。なぜなら、支払取引では、口座所有者が保持している最も一般的な口座は、何らかのクレジットカード、デビットカード、またはチェックカードの口座であるからである。カード所有者は、購入したい商品またはサービスを選択した後、チェックアウトプロセスを開始し、チェックアウトフォームに記入し、次いで、「購入」ボタンをクリックする。

図５のステップ２に示されるような「購入」ボタンの選択後、商人プラグインソフトウェアモジュールはアクティブ化され、カード所有者に固有な口座が口座認証システムに登録されているか否かを決定する検証プロセスを実施する。商人プラグインソフトウェアモジュールは、カード所有者が口座認証システムに登録されているか否かを様々な方法で決定することができる。例えば、最初にディレクトリサーバがチェックされ、次いでカード所有者に関連付けられたＡＣＳがチェックされる二段構えのプロセス、ＡＣＳのみがチェックされるプロセス、及びディレクトリサーバに保持されているのと同じ情報を含むキャッシュメモリを商人がチェックできる方法などを使用することができる。

以下では、二段構えのプロセスを説明する。この説明は、図２を参照にする。第１のステップにおいて、商人プラグインソフトウェアモジュールは、カードの口座番号を識別し、尚かつ、ディレクトリサーバ１２８に照会することによって、その口座番号が、口座認証システムの参加者である発行銀行に関連付けられた番号範囲に含まれるか否かを検証する。口座番号が、ディレクトリサーバ１２８上に定義された口座番号の範囲に含まれない場合は、その発行者ひいてはそのカード所有者は、登録されていない。このとき、商人は、口座番号が登録されていない旨の通知を受け、商人プラグインソフトウェアモジュール１３４は、取引の制御を商人店舗ソフトウェアに返す。この時点で、商人店舗ソフトウェアは、通常の通りに取引を進めるか、カード所有者に対するこれ以上のサービスの提供を拒否するか、または別の支払方法に移行するかのいずれかの方法を採ることができる。

反対に、口座番号がディレクトリサーバ１２８の口座番号の範囲に含まれるものと決定された場合は、検証プロセスの第２のステップが開始する。検証プロセスの第２のステップは、ディレクトリサーバ１２８が、口座番号をその登録の有無を決定する目的でＡＣＳに送信した時点で開始する。カードが登録されていない場合は、登録プロセスは終了する。カードが登録されている旨が示された場合は、ＡＣＳは、ディレクトリサーバを介して自分のＵＲＬインターネットアドレスを商人プラグインソフトウェアモジュールに返す。商人プラグインソフトウェアモジュールは、次いで、カード所有者のクライアントデバイス及びその常駐ブラウザを介してＡＣＳを起動する。なお、繰り返しになるが、ＰＡＳには複数のＡＣＳが存在可能である。

口座認証システムにおけるカード所有者の登録の有無をチェックする第２の方法では、商人プラグインソフトウェアモジュール１３４は、最初にディレクトリサーバ１２８に照会することなく直接にＡＣＳ１１４に照会する。前述されたように、第３の方法では、商人は、ディレクトリサーバ１２８に保持されているのと同じ情報を含むキャッシュメモリを有する。こうすれば、商人は、少なくとも予備のチェックを行うことができる。

なお、口座認証システムには、２つ以上の物理ディレクトリサーバが存在可能である。ただし、論理ディレクトリサーバは、１つのみであることが好ましい。つまり、どのディレクトリサーバも、同じ情報を含むという点で首尾一貫している必要がある。

カード所有者が口座認証システムの参加者である場合は、ＡＣＳ１１４は、カード所有者に対して銀行ブランドのウィンドウを提示する。銀行ブランドのウィンドウは、基本的な支払取引情報を含むウィンドウであり、カード所有者に自分の認証パスワードまたはトークンを入力するように促す。図６を参照せよ。図６は、カード所有者に自分の認証パスワードを入力するように促す代表的なウィンドウ５００を示している。カード所有者が自分の認証パスワードを入力すると、ＡＣＳ１１４は、その認証パスワードを検証する。ウィンドウ５００の大きさ及びレイアウトは、カード所有者が使用するデバイスのパラメータに応じて様々に異なる。今日普通に見られるように、カード所有者は、認証パスワードを正しく入力する機会を一定の回数だけ与えられる。もし認証パスワードを正しく入力できない場合は、カード所有者は、その登録プロセスの際に確立されたヒント付き質問に答えるように促される。カード所有者は、ヒント付き質問に正しい答えを入力する機会を一度のみ与えられることが好ましい。

正しい認証パスワードまたはトークンが直ちに入力された場合、または、カード所有者がヒント付き質問に正しい答えを入力した場合は、支払認証は継続する。ＡＣＳは、次いで、発行者の署名キーまたはサービスプロバイダのキーを使用して、レシートにデジタル署名する。このレシートは、商人名、カード口座番号、支払額、及び支払期日を含む。いくつかの実施形態では、このレシートは、支払認証応答（ＰＡＲｅｓ）メッセージのコピー、または、ＰＡＲｅｓメッセージから少なくとも情報フィールドの一部をコピーしたメッセージのコピーである。認証履歴サーバ１３０は、商人名、商人ＵＲＬ、カード口座番号、有効期限、支払額、支払期日、発行者の支払署名、及びカード所有者認証検証値などの取引データを格納する。ＡＣＳは、次いで、カード所有者のブラウザを通じてカード所有者を商人プラグインソフトウェアモジュールにリダイレクトする。このとき、ＡＣＳは、デジタル署名されたレシート及びカード所有者が認証されたか否かに関する決定結果も商人に引き渡す。決済者ドメイン１０６にある検査サーバ１３６は、商人プラグイン１３４によって使用され、支払レシートの署名に使用されたデジタル署名を検証する。デジタル署名の検証後、カード所有者は、「認証された」とみなされる。いくつかの実施形態では、カード所有者は、今後のオンライン購入に備え、取引の完了後に自分のカード口座を登録し、新しいパスワードを作成することができる。

ステップ３におけるカード所有者の認証後、ステップ４は、カード所有者の特定の口座に与信するプロセスを開始する。与信とは、カード所有者が特定の購入に適した適切な信用及び優良な資産状態を有するか否かを検証するプロセスをいう。ステップ４において、商人は、商人プラグインソフトウェアモジュールを使用して、ＶｉｓａＮｅｔなどの支払ネットワークに与信メッセージを送信する。すると、支払ネットワークは、発行者である金融機関に与信メッセージ及び電子商取引インジケータ（ＥＣＩ）を転送する。与信メッセージは、当該分野において良く知られたメッセージである。発行者である金融機関は、与信メッセージを受け取って、要求された購入額の支払取引に適した優良な資産状態及び適切な信用枠をその特定の口座が有することを、商人に対して証明することができる。ＥＣＩは、インターネットを通じた取引が完了したことを示すと共に、使用されたメッセージセキュリティ（即ち具体的にはチャネル暗号化（ＳＳＬ））及び認証のレベルを示す。

代替の実施形態では、商人は、与信メッセージと共に追加情報を提供することができる。商人は、例えば、カード所有者が成功裏に認証されたか否かを示すフラグ、口座情報、デジタル署名、カード所有者検証値２、カード認証検証値（ＣＡＶＶ）、チップカードＥＭＶ（Ｅｕｒｏｐａｙ、ＭａｓｔｅｒＣａｒｄ、及びＶｉｓａ）暗号文によって認証されたオフラインのＰＩＮ、及び商人に対する支払の保証に必要なフィールドなどの情報を送信することもできる。ＣＡＶＶは、ＡＣＳによって作成されるカード所有者を認証するデータであり、所定の決済カード及びそのカードによる特定の支払取引に固有な値である。ＣＡＶＶは、のちほど何らかの紛争が生じた場合に発行者によって使用され、認証された支払取引を固有に識別することができる。発行者である金融機関によって与信取引の処理が完了した後、支払取引の制御は、支払ネットワークを介して商人の店舗ソフトウェアに返される。したがって、発行者は、支払ネットワークを介して与信応答を商人に返す。図５のステップ５において、発行者である金融機関は、取引に与信するまたは却下する。いくつかの実施形態では、与信メッセージはひとまとめにされて、のちほど一括して送信される。認証情報は、これらのバッチ与信メッセージにも含まれる。

アクセス制御サーバ（ＡＣＳ）１１４は、その他にも様々に機能することができる。例えば、ＡＣＳは、登録された口座を非アクティブ化して、データベースから排除することができる。口座の非アクティブ化は、カード所有者または発行者によって手動で行うことができる。ＡＣＳ１１４は、また、カード所有者が代わりのカードを受け取った際に、簡単な更新登録プロセスを行うこともできる。ＡＣＳ１１４は、同一の登録口座を有する複数のユーザを、固有のアクセス制御情報によってサポートすることができる。ユーザが、支払取引または口座更新のためにＡＣＳ １１４への接続を得たとき、ＡＣＳ １１４は、パスフレーズ、デジタル署名、オンラインＰＩＮ番号、及びチップカードＥＭＶ暗号文によるオフラインＰＩＮ認証のうちの１つまたはそれ以上のメカニズムを通じて、そのユーザが登録口座のカード所有者として与信を受けるのが妥当であるか否かを検査することができる。

商人１３２は、自身のカード所有者口座情報が記録されている既存のシステムと相互運用すること、既存の商人与信システム及び商人クリアリングシステムと相互運用すること、複数の商人にサービスを提供する第三者をサポートすること、自身と支払人との間で様々な支払インターフェースをサポートすること、及び電子商取引インジケータ（ＥＣＩ）の値を設定する際に支払人によって支払ネットワーク与信メッセージに必然的に及ぼされる衝撃を最小化することができる。

商人からＡＣＳへと取引を送る方法の１つは、カード所有者の口座番号に基づいてサーバのアドレスを提供するディレクトリを設けることである。このような方法では、経路情報を求める要求は、認証された商人からのみ受け入れ可能である。商人からのアクティビティが通常のアクティビティを超える場合は、口座認証システムは、決済者によってアクセスが有効期限切れである旨を示された商人へのアクセスを拒否することができる。これは、商人による不正行為が考えられる場合に該当する。口座認証システムは、商人の認証を配備することができるが、これは必ずしも必須ではない。商人の認証は、商人による不正行為を最小限に抑えるのに有用である。

図７は、一実施形態にしたがって、顧客がインターネットに接続されたコンピュータを使用する場合に関し、支払取引の際にコア口座認証システムを使用して伝送される特定のメッセージを示している。図７のメッセージは、図２に示された支払システムアーキテクチャに重ねて示されている。なお、たとえメッセージ及び各メッセージに含まれるデータフィールドが所定の名称を有する場合でも、これらの名称が認証プロトコルのパフォーマンスに影響を及ぼすことはない点に留意せよ。したがって、後述されるメッセージ及びデータフィールドは、様々に異なる名称で呼ぶことが可能である。

上述されたように、支払取引は、カード所有者がブラウザを介して商人のウェブサイトを訪れ、購入したい商品を選択した時点で開始する。商人の支払システムは、カード所有者にその支払情報を入力するように求める。一般に、支払情報の入力は、例えばＳＳＬ暗号化プロトコルを通じてなどの安全な環境で行う必要がある。カード所有者が、自分が取引を確定できる旨を示すと、商人の支払システムは、商人プラグインソフトウェアモジュール１３４を起動する。すると、線１ａで示されるように、プラグインソフトウェアモジュール１３４は、カード所有者の支払人認証番号（ＰＡＮ）を含み得る特定のＡＣＳのＵＲＬを求めてディレクトリサーバ１２８をチェックして、カード所有者がサービスに登録しているか否かを検査する。プラグインソフトウェアモジュール１３４は、あるいは、このような情報を含む自身のキャッシュメモリをチェックする。プラグインソフトウェアモジュール１３４は、また、ＡＣＳ １１４をチェックして、カード所有者のＰＡＮが口座認証システムに登録されているか否かを検証することもできる。自身のキャッシュをチェックできる場合は、プラグインモジュール１３４は、ディレクトリサーバ１２８のコンテンツを自身のローカルキャッシュにコピーする能力が必要である。商人は、この能力を使用することによって、口座が登録範囲に含まれるか否かをキャッシュから直ちに決定することができる。商人がこの能力を実装している場合は、キャッシュのコンテンツは、２４時間ごとに失効及びリフレッシュを必要とする。キャッシュは、商人プラグインソフトウェアモジュール１３４が読み込まれた時点及びその後は一定時間ごとにリフレッシュする必要がある。

プラグインソフトウェアモジュール１３４は、カード所有者のＰＡＮを使用して登録検証要求（ＶＥＲｅｑ）メッセージをフォーマットし、それによってＰＡＮを検索する。商人プラグインソフトウェアモジュール１３４は、もしまだならばディレクトリサーバ１２８またはＡＣＳ １１４との間にセキュア接続を確立し、ディレクトリサーバ１２８またはＡＣＳ１１４に対して自身の有効性を証明する。商人プラグインソフトウェアモジュール１１４は、カード所有者のＰＡＮに対応するカード範囲入力を求めて様々な場所を検索する。

商人プラグインソフトウェアモジュール１１４による検索後、ＶＥＲｅｑメッセージは、線１ｂで示されるようにＡＣＳ１１４に直接伝送される、または、線１ａで示されるように先ずディレクトリサーバ１２８を経てからＡＣＳ１１４に伝送される。ＶＥＲｅｑメッセージがディレクトリサーバ１２８を介してＡＣＳ１１４に伝送された場合は、ディレクトリサーバ１２８は、ＶＥＲｅｑメッセージに含まれるカード所有者のＰＡＮに対応する記録を検索する。上手く一致しなかった場合は、ディレクトリサーバ１２８は、ＵＲＬ値を含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットし、ＰＡＮの登録状況を示す値を、すなわちＶＥＲｅｓ−Ｓｔａｔｕｓを「Ｎ」に設定する。ＶＥＲｅｓメッセージは、次いで、商人プラグインソフトウェアモジュールに返される。他方、上手く一致した場合は、ディレクトリサーバ１２８は、もしまだならばＡＣＳのＵＲＬとの間にセキュア接続を確立し、ＡＣＳに対して自身の有効性を証明する。ＶＥＲｅｑメッセージは、次いで、ＡＣＳのＵＲＬに転送される。もしそのＵＲＬが使用不可である場合は、商人プラグインソフトウェアモジュールは、（もし可能ならば）次のＡＣＳのＵＲＬ値を試みることが好ましい。商人プラグインソフトウェアモジュールは、最大で５つのＡＣＳ ＵＲＬを検索することができる。試みることのできるＵＲＬの数は、もちろん可変である。いずれの試みにも失敗した場合は、ＶＥＲｅｓ−Ｓｔａｔｕｓを「Ｎ」に設定されたＶＥＲｅｓメッセージが商人プラグインソフトウェアモジュールに返され、商人は口座認証システムを使用した支払取引の処理が不可能である旨を知らされる。

ＶＥＲｅｑメッセージを受信した後、ＡＣＳ１１４は、ＶＥＲｅｑメッセージからカード所有者のＰＡＮを受け入れて、それを口座所有者ファイル１１８に照らして検査する。ＡＣＳ１１４は、次いで、ＶＥＲｅｓメッセージをフォーマットする。もし上手く一致した場合は、ＡＣＳは、ＰＡＮの登録状況を「Ｙ」に設定し、ＡＣＳ１１４と内部で関連付けられる単用のプロキシＰＡＮを作成し、ＶＥＲｅｑメッセージにＵＲＬフィールドを投入する。上手く一致しなかった場合は、ＡＣＳは、ＰＡＮの登録状況を「Ｎ」に設定する。次いで、ＡＣＳは、線２ａで示されるように、ディレクトリサーバ１２８を通じてＶＥＲｅｓメッセージを商人プラグインソフトウェアモジュールに返す。ＶＥＲｅｑメッセージがＡＣＳに直接送られた場合は、ＶＥＲｅｓメッセージは、線２ｂで示されるように、商人プラグインソフトウェアモジュールに直接返される。

ＣＲＲｅｑ及びＣＲＲｅｓのメッセージ対を使用すると、ディレクトリサーバ１２８のデータをＭＰＩ １３４にキャッシュすることが容易になる。ＣＲＲｅｑメッセージは、商人プラグインソフトウェアモジュールからディレクトリサーバに送信されるメッセージである。ＣＲＲｅｑメッセージは、参加カード範囲のリストを要求することによって、商人プラグインソフトウェアモジュールによる自身のキャッシュの更新を可能にする。ＣＲＲｅｓメッセージは、参加カード範囲を含む応答である。

いくつかの実施形態では、口座認証システムは、ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｑ及びＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓのメッセージ対を使用することによって、カード所有者のクライアントデバイスが分散型の認証能力を有するか否かをチェックする。商人プラグインソフトウェアモジュールは、照会を、すなわちＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｑメッセージをフォーマットし、それをカード所有者のクライアントデバイス１２２に送信することによって、分散型の口座認証モジュールがカード所有者のクライアントデバイスに常駐しているか否かを決定する。ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｑメッセージの送信は、図７の線３によって示される。もし何らかの分散型認証オプションが、ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージに含まれる形で返された場合は、商人プラグインソフトウェアモジュールは、カード所有者クライアントソフトと直接通信することによって、認証されたステップを実施する。ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージの送信は、図７の線４によって示されている。また、ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｑメッセージ及びＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージの使用は、後述されるＶＥＲｅｑメッセージ及びＶＥＲｅｓメッセージを排除することができる。カード所有者クライアントソフトウェアは、発行者のＡＣＳ ＵＲＬを組み込まれることができる。商人プラグインソフトウェアモジュールは、先ず、ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｑメッセージ及びＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージを完了させる。カード所有者クライアントソフトが検出された場合は、ＡＣＳまたはカード所有者クライアントソフトにＰＡＲｅｑメッセージを送信することができ、このとき、ＶＥＲｅｑメッセージ及びＶＥＲｅｓメッセージの実施は不要である。

ＶＥＲｅｓ−Ｓｔａｔｕｓの値が「Ｙ」でない場合は、商人は、その支払取引が口座認証システムによって処理できない旨を通知される。しかしながら、もしＶＥＲｅｓ−Ｓｔａｔｕｓの値が「Ｙ」である場合は、ＭＰＩ １３４は、支払人認証要求メッセージ（ＰＡＲｅｑ）をフォーマットする。ＭＰＩ １３４は、線５によって示されるように、ＰＡＲｅｑメッセージを、カード所有者のクライアントデバイスのブラウザを介して発行者のＡＣＳサーバに送信する。

商人プラグインソフトウェアモジュールによって、発行者のＡＣＳにＰＡＲｅｑメッセージが引き渡されると、ＡＣＳは、カード所有者にウィンドウを表示する。ウィンドウは、発行者のロゴ、サービス組織のマークまたはブランドロゴ、商人名、商人の場所（ＵＲＬ）、総購入額及び通貨、購入日、カード番号、分割払いまたは定期循環払いの支払条件、注文に関する説明またはその説明へのリンク、販売に関する特別な契約条件またはその情報へのリンク、個人保証メッセージ（ＰＡＭ）、並びに、カード所有者のパスワードまたは他の任意の認証トークンを促すプロンプトなどの項目に加えて、支払人認証応答（ＰＡＲｅｓ）メッセージに含まれる支払の詳細も表示する。

ＡＣＳは、次いで、適切なパスワードを入力するようにカード所有者を促す。ＡＣＳは、カード所有者による入力を受信し、それを口座所有者ファイル１１８に照らして検査する。口座認証システムは、例えば、正しいパスワードを入力するまでに一定の回数（例えば三度）の失敗を許容することができる。試みられる機会の回数は、もちろん可変である。最後の機会が失敗に終わったとき、口座認証システムは、ヒント付きの質問を表示することができる。カード所有者は、このヒント付きの質問に正しい答えを入力する必要がある。したがって、次は、カード所有者に関連付けられたヒント付きの質問が表示される。カード所有者は、正しい答えを入力する少なくとも一度の機会を有する。もしカード所有者による答えが正しくない場合は、商人は、口座認証システムを使用して取引を完了させることが不可能である旨を通知される。もしカード所有者による答えが正しい場合は、その取引は、パスワードが一致した場合と同様に扱われることが好ましい。なお、１つの口座番号に２つ以上のエントリがある場合は、それらのカード所有者の名前がドロップダウン方式のウィンドウに表示される。カード所有者は、その中から自分の名前を選択することができる。

パスワードを突き合わせる際に、ＡＣＳは、ＰＡＲｅｓメッセージを生成し、それにデジタル署名する。ＡＣＳは、また、線７で示されるように、ＳａｖｅＲｅｃｅｉｐｔメッセージを作成し、それを認証履歴サーバ１３０及びレシートマネージャ１３１に送信する。また、線７ａで示されるように、ＳａｖｅＲｅｃｅｉｐｔメッセージは、認証履歴サーバ１３０から発行者の与信・決済システム１３８に引き渡されても良い。こうすると、発行者は、支払与信要求を、支払人を認証された取引とリアルタイムで突き合わすことが可能になる。ＳａｖｅＲｅｃｅｉｐｔメッセージを発行者の与信・決済システム１３８に送信することによって、発行者は、その与信要求が、認証された購入に関するものであるか否かを決定することが可能になる。ＡＣＳは、次いで、線６で示されるように、署名付きのＰＡＲｅｓメッセージを商人プラグインソフトウェアモジュールへとリダイレクトして返す。

署名付きのＰＡＲｅｓメッセージがＭＰＩ １３４に返されると、ＭＰＩ １３４は、再びアクティブ化される。認証状況が「Ｙ」である場合は、ＭＰＩ １３４は、ＰＡＲｅｓメッセージを検査サーバ１３６に送信する。検査サーバの機能をＭＰＩ １３４が提供している場合は、ＭＰＩ １３４は、ＰＡＲｅｓメッセージの署名を検査し、その署名の検査結果を返す。もし署名の有効性が認められなかった場合は、ＭＰＩ １３４は、その取引が口座認証システムによって処理できない旨を商人に通知する。認証状況が「Ｎ」である場合は、商人は、追加情報を求めるプロンプトをカード所有者に送信する、異なる決済カードまたは異なる決済方法を使用するようにカード所有者に要求する、または、その支払取引を認証されていない支払取引として処理する、のいずれかの措置を採ることが好ましい。

決済者ドメイン１０６が検査サーバを含む場合は、その検査サーバ１３６は、ＰＡＲｅｓメッセージ上の署名を検査する。検査サーバ１３６は、次いで、署名の検査結果をＭＰＩ １３４に返す。もし署名の有効性が認められなかった場合は、商人プラグインソフトウェアモジュールは、その取引が口座認証システムによって処理できない旨を商人に通知する。反対に、もし署名の有効性が認められた場合は、商人は認証された支払与信に進む。ＰＡＲｅｓメッセージは、また、線６ａで示されるように、商人から決済者の支払プロセッサ１４０に引き渡され、次いで、通信ネットワーク１４２を通じて決済者から発行者に引き渡されても良い。したがって、支払人の認証結果は、標準的な支払与信プロセスの一部として発行者によって使用可能である。

次に、各種チャネルに関連したセキュリティ問題を検討する。基線としては、どの伝送チャネルも１２８ビットのＳＳＬを使用して暗号化されることが好ましい。カード所有者と商人との間のチャネルは２本である。商人は、カード所有者が支払情報を入力する際に使用される接続を、サービス組織によって承認され認証局から得られたＳＳＬ証明書を使用して、セキュアに維持することが好ましい。商人は、また、カード所有者から商人プラグインソフトウェアモジュールにＰＡＲｅｓメッセージを移送するために使用される接続を、サービス組織によって承認された認証局から得られたＳＳＬ証明書を使用して、セキュアに維持することが好ましい。

カード所有者とＡＣＳとの間のチャネルは、サービス組織によって承認された認証局から得られたＳＳＬ証明書を使用して、ＡＣＳが暗号化することが好ましい。このチャネルは、２つの目的のために使用される。第１の目的は、商人プラグインソフトウェアモジュールからＡＣＳにＰＡＲｅｑメッセージを送信するためであって、第２の目的は、ＡＣＳからカード所有者に署名付きのＰＡＲｅｓメッセージを送信するためである。

カード所有者と登録サーバとの間のチャネルは、サービス組織によって承認された認証局から得られたＳＳＬ証明書を使用して、登録サーバが暗号化することが好ましい。このチャネルは、カード所有者の登録情報を受け入れるために使用される。

商人とディレクトリサーバとの間及びディレクトリサーバとＡＣＳサーバとの間のチャネルは、ＶＥＲｅｑメッセージ及びＶＥＲｅｓメッセージに含まれるＰＡＮデータ並びにＶＥＲｅｓメッセージに含まれるＡＣＳのＵＲＬアドレスを保護するために、サービス組織によって発行されたＳＳＬ暗号化証明書によってセキュアに維持することが好ましい。

ＡＣＳとカード所有者との間のチャネルは、カード所有者にパスワードの入力を促すプロンプト及びカード所有者によって入力されたパスワードを保護するために暗号化することが好ましい。このチャネルは、サービス組織によって承認された認証局からのＳＳＬ証明書によって保護することが好ましい。

大抵の取引に関し、支払認証要求メッセージ及び支払認証応答メッセージは、メッセージのヴァージョン番号、商人ＩＤ、商人の国別コード、注文番号、購入日、購入額、取引状況、及び購入の諸条件のフィールドを含むがこれらに限定されない。また、ＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージは、一般に、メッセージのヴァージョン番号、商人の名前、注文番号、購入日、購入額、カードの有効期限、及び取引の汚れなどのフィールドを含むがこれらに限定されない。これらのメッセージは、ＸＭＬ（拡張可能なマークアップ言語）フォーマットで記述することができる。

非購入認証取引において、支払認証要求メッセージ、支払認証応答メッセージ、及びＱｕｅｒｙＣａｒｄｈｏｌｄｅｒＲｅｓメッセージは、メッセージ拡張フィールドを含むことができる。当該分野において周知のように、メッセージ拡張フィールドは、拡張子の取り付け先のメッセージに関して追加のエレメントを定義するデータフィールドである。これらの追加のエレメントは、非支払取引を含む特定の取引を更に容易にする目的で使用することができる。

図８は、コア口座認証システムを使用した支払取引を別の角度から示している。図８は、伝送されるメッセージを単純化することによって簡略化されている。図８によって、読者は、後述される２種類のモバイル実施形態をより良く理解することができる。図８に続くこれらの２種類のモバイル実施形態は、口座所有者がインターネット互換性及び非インターネット互換性のモバイルトデバイスを使用することを含む。

図８の口座認証システムアーキテクチャは、発行者ドメイン１０２、相互運用性ドメイン１０４、及び決済者ドメイン１０６を含む。発行者ドメイン１０２は、カード所有者１２２、ＡＣＳ１１４、及び発行者１６１０を含む。カード所有者１２２は、カードを所有する人間と、例えばコンピュータ端末または携帯電話などのカード所有者のクライアントデバイスとを表している。発行者１６１０は、カード所有者に決済カードを発行することができるカード発行銀行を表している。相互運用性ドメイン１０４は、Ｖｉｓａディレクトリ１６１２、認証履歴サーバ１３０、及びＶｉｓａＮｅｔ１６１６を含む。この場合のＶｉｓａディレクトリ１６１２は、Ｖｉｓａによって制御されるディレクトリである。決済者ドメイン１０６は、商人１３２、商人プラグインソフトウェアモジュール（ＭＰＩ）１３４、及び決済銀行１６２２を含む。

図８の支払取引は、１〜１２の符号で示された矢印を通じて説明される。支払取引は、ショッパが商人のウェブサイトをブラウズし、購入したい商品をショッピングカートに入れて購入を確定するステップ１から開始する。この時点で、商人１３２は、主要口座番号（ＰＡＮ）、有効期限、及び住所情報などを含む、支払取引を進めるにあたって必要なデータを有している。ＰＡＮは、チェックアウトプロセスの際に、カード所有者による入力またはウォレット機能を通じて商人１３２に提供されることが好ましい。有効期限は、現月よりも前であってはならない。

ステップ２において、ＭＰＩ １３２は、カード所有者の主要口座番号（及びもし該当する場合はユーザデバイス情報）をＶｉｓａディレクトリ１６１２に送信することによって、カード所有者のＰＡＮが口座認証システムに登録されているか否かをチェックする。このプロセスは、商人チェックアウトプロセスの際に、カード所有者が最終的に「購入」をクリックして確認を行った後に生じる。「購入」のクリックがなされた後、商人のソフトウェアは、登録検証要求（ＶＥＲｅｑ）メッセージをフォーマットするために、商人サーバプラグイン（ＭＰＩ）１３４を起動する。ＭＰＩ １３４は、この時点で自身とＶｉｓａディレクトリサーバ１６１２との間にセキュア接続があるか否かを決定する。もしセキュア接続がまだ確立されていない場合は、ＭＰＩ １３４は、Ｖｉｓａディレクトリサーバ１３４との間にＳＳＬ接続を確立する。Ｖｉｓａディレクトリサーバの構成が、商人１３２がＳＳＬクライアント証明書の発行を受けた旨を示した場合は、Ｖｉｓａディレクトリサーバ１６１２は、ＳＳＬセッションの確立の際に、ＳＳＬクライアント証明書を提示するように商人１３２に要求する。セキュア接続が確立されると、ＭＰＩ １３４は、Ｖｉｓａディレクトリサーバ１６１２にＶＥＲｅｑメッセージを提供する。なお、「購入」のクリックによる確認は、実施形態ごとに様々に異なる購入注文確認プロセスによって完了できる点に留意せよ。

ＰＡＮが参加カード範囲に含まれると決定された場合は、Ｖｉｓａディレクトリサーバ１６１２は、ステップ３において、ＡＣＳ １１４などの適切なＡＣＳに照会することによって、そのＰＡＮの認証（または認証を試みた証拠）が可能であるか否かを決定する。このプロセスは、Ｖｉｓａディレクトリサーバ１６１２がＭＰＩ １３４からのＶＥＲｅｑメッセージを受信した後に生じる。

Ｖｉｓａディレクトリサーバ１６１２は、ＰＡＮが参加カード範囲に含まれるか否かを検証する目的で、ＶＥＲｅｑメッセージの構文を検査し、もし検査が不合格である場合はエラーを返す。Ｖｉｓａディレクトリサーバ１６１２がＶＥＲｅｑメッセージデータを検査するのは、以下の特定の要件が満たされることを保証するためである。すなわち、第１に、決済者ＢＩＮは、参加決済者を表していること、第２に、商人ＩＤは、決済者ＢＩＮによって識別される決済者の参加商人を表していること、第３に、もし決済者のＶｉｓａ領域が口座認証サービス用の商人パスワードを求める場合は、パスワードの値が受信され、そのパスワードは決済者ＢＩＮ及び商人ＩＤの組み合わせに対して有効であること、である。もしいずれかの要件が満たされない場合は、Ｖｉｓａディレクトリサーバ１６１２は、「Ｎ」に設定されたＰＡＮ認証可能値及び無効要求メッセージを含む登録検証応答（ＶＥＲｅｓ）をフォーマットする。なお、このＶＥＲｅｓは、口座ＩＤ、ＡＣＳ ＵＲＬ、及び支払プロトコルのデータフィールドを含まない。Ｖｉｓａディレクトリサーバ１６１２からＭＰＩ １３４にＶＥＲｅｓメッセージが返された後、支払取引は、様々な方向に進むことができる。例えば、支払取引は完全に終了しても良いし、非認証取引として先に進んでも良いし、あるいは、異なる口座番号の使用をカード所有者が試みても良い。これらの様々な方法は、以下で詳述される。

Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｑメッセージに含まれる形で受信されたカード所有者ＰＡＮを含むカード範囲を指定する記録を検索する。もしカード所有者ＰＡＮが見つからなかった場合は、Ｖｉｓａディレクトリサーバ１６１２は、「Ｎ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。次いで、Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｓメッセージをＭＰＩ １３４に返し、口座の認証は、後述されるように、予想される停止点に再び到達する。

カード所有者ＰＡＮがＶｉｓａディレクトリサーバ１６１２の中から見つかったと仮定すると、Ｖｉｓａディレクトリサーバ１６１２は、この時点で自身が適切なＡＣＳとの間にセキュア接続を有するか否かを決定する。セキュア接続がまだ確立されていない場合は、Ｖｉｓａディレクトリサーバ１６１２は、自身とＡＣＳとの間にＳＳＬ接続を確立する。ＳＳＬセッションを確立する際は、Ｖｉｓａディレクトリサーバ１６１２のＳＳＬクライアント証明書及びＡＣＳのサーバ証明書の提示並びに検査が行われなければならない。最初に試されたＵＲＬが使用不可である場合は、（もしあるならば）次に続く各ＵＲＬ値が試される。Ｖｉｓａディレクトリサーバ１６１２は、各ＡＣＳのために随意に構成された最大で４種類の代替のＵＲＬに接続を試みることができる。試されたどのＵＲＬにも接続できなかった場合は、Ｖｉｓａディレクトリサーバ１６１２は、「Ｎ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、または無効要求のデータフィールドを含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。次いで、Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｓメッセージをＭＰＩ １３４に返し、口座の認証を、予想される停止点に持ってくる。

ＵＲＬとの接続に成功した後、Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｑメッセージからパスワードフィールドを削除し、その削除後のメッセージをＡＣＳ ＵＬＲに転送する。

ステップ４において、ＡＣＳ １１４は、ＰＡＮの認証が可能であるか否かを決定し、その決定結果をＶｉｓａディレクトリサーバ１６１２に示す。このプロセスは、ＡＣＳがＶｉｓａディレクトリサーバ１６１２を介してＶＥＲｅｑを受信した後に生じる。ＡＣＳ １１４は、ＶＥＲｅｑの構文を検査し、もし検査が不合格である場合はエラーを返す。なお、たとえ支払取引の認証が不可能な場合でも、代わりに認証を試みた証拠を提供できる場合がある点に留意せよ。ＡＣＳ １１４は、ＶＥＲｅｑメッセージから得られたカード所有者ＰＡＮを使用し、ＡＣＳ １１４の中に設けられた口座所有者データベースに照会することによって、カード所有者が登録されているか否かを決定する。もしＰＡＮが見つからなかった場合は、ＡＣＳ １１４は、「Ｎ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。

もしＤｅｖｉｃｅＣａｔｅｇｏｒｙが存在する場合は、ＡＣＳ １１４は、その値が示すカテゴリのデバイスによって送信された取引を処理することができない。あるいは、もしＡＣＳ １１４がデバイスカテゴリ値を認識しない場合は、ＡＣＳは、「Ｕ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、及び無効要求のデータフィールドを含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。

もしＡｃｃｅｐｔＨｅａｄｅｒまたはＵｓｅｒＡｇｅｎｔが存在する場合は、ＡＣＳ １１４は、これらのエレメント値が示すカード所有者デバイスまたはユーザエージェントによって送信された取引を処理することができない。ＡＣＳ １１４は、「Ｕ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、または無効要求のデータフィールドを含まないＶＥＲｅｓメッセージをフォーマットする。ＡＣＳ １１４は、「Ｙ」に設定されたＰＡＮ認証可能値、ＡＣＳが内部でＰＡＮに関連付けられる口座ＩＤ（ただし、このＩＤはＰＡＮまたはＡＣＳに有用な任意のストリングのいずれでもない）、ＰＡＲｅｑメッセージの伝送に使用されるＡＣＳ ＵＲＬ、及び特定の支払プロトコルを含む登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。このＶＥＲｅｓメッセージに無効要求は含まれない。

ＡＣＳ １１４は、次いで、ＶＥＲｅｓメッセージをＶｉｓａディレクトリサーバ１６１２に送信する。

ステップ５において、Ｖｉｓａディレクトリサーバ１６１２は、ＡＣＳ １１４の決定をＭＰＩ １３４に転送する。Ｖｉｓａディレクトリサーバ１６１２の視点から見ると、このプロセスは、Ｖｉｓａディレクトリサーバ１６１２がＡＣＳ ＵＲＬにＶＥＲｅｑメッセージを転送した後に生じる。ＡＣＳ １１４の視点から見ると、このプロセスは、ＡＣＳ １１４がＶｉｓａディレクトリサーバ１６１２にＶＥＲｅｓメッセージを送信した後に生じる。

Ｖｉｓａディレクトリサーバ１６１２は、対応するＶＥＲｅｓまたはエラーを含むＶＥＲｅｓメッセージを読み出す。Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｓメッセージの構文を検査し、もし検査が不合格である場合はＡＣＳ １１４にエラーを返す。ＡＣＳから受信されたメッセージが構文的に正しい場合は、Ｖｉｓａディレクトリサーバ１６１２は、ＶＥＲｅｓまたはエラーをＭＰＩ １３４に転送する。ＡＣＳから受信されたメッセージが構文的に正しくない場合は、Ｖｉｓａディレクトリサーバ１６１２は、「Ｎ」に設定されたＰＡＮ認証可能値を含み尚かつ口座ＩＤ、ＡＣＳ ＵＲＬ、支払プロトコル、または無効要求のデータフィールドを含まない登録検証応答（ＶＥＲｅｓ）メッセージをフォーマットする。Ｖｉｓａディレクトリサーバ１６１２は、そのＶＥＲｅｓメッセージをＭＰＩ １３２に返し、場合によっては口座認証プロセスを停止させる。ＭＰＩ １３４の視点から見ると、このプロセスは、ＭＰＩ １３４がＶｉｓａディレクトリサーバ１６１２にＶＥＲｅｑメッセージを提供した直後に生じる。Ｖｉｓａディレクトリサーバ１６１２の視点から見ると、このプロセスは、ＶｉｓａディレクトリサーバがＭＰＩにＶＥＲｅｓメッセージを転送した直後に生じる。ＭＰＩ １３４は、対応するＶＥＲｅｓまたはエラーを含む応答を読み出す。エラーメッセージが受信された場合は、口座認証プロセスは停止する可能性がある。

上述された様々な原因の結果として口座認証が終了したとき、商人は、チェックアウトプロセスから入手可能な情報を使用する通常の支払与信に進むことができる。このとき、商人支払システムは、その取引を、認証されていない電子商取引として進めなければならない。これは、本文献で取り扱う範囲外である。なお、電子商取引インジケータは、認証の結果及びチェックアウトプロセスの特性に応じた値に設定される必要がある。チェックアウトプロセスの際にカード所有者によって選択された口座を使用して認証取引を処理することが不可能なとき、商人は、その取引を放棄する、または、代替の口座を選択する選択肢を顧客に与えることができる。代替の口座が選択された場合は、認証プロセスは繰り返される必要がある

代替の一実施形態では、Ｖｉｓａディレクトリサーバのコンテンツを商人１３２にあるローカルキャッシュメモリデバイスにコピーすることによって、支払取引ごとにＶｉｓａディレクトリサーバに照会して口座所有者が口座認証システムに加入しているか否かを検査する（ステップ２〜５）必要を回避することができる。この能力を使用すれば、商人１３２は、口座が登録範囲の一部であるかどうかをキャッシュに基づいて直ちに決定することができる。商人１３２にあるローカルキャッシュを使用するこの代替の技術は、ＭＰＩ １３４がカード範囲要求（ＣＲＲｅｑ：Card Range Request）メッセージをフォーマットし、それをＶｉｓａディレクトリサーバ１６１２に送信することから開始する。これがキャッシュの初の読み込みである場合（またはキャッシュがフラッシュ済みで、再読込の必要がある場合）は、ＣＲＲｅｑにシリアル番号エレメントが含まれないので、Ｖｉｓａディレクトリサーバ１６１２は、加入カード範囲の全リストを返してくる。そうでない場合は、ＭＰＩ １３４は、最後に処理されたＣＲＲｅｓから得られたシリアル番号を含むはずなので、Ｖｉｓａディレクトリサーバは、前のＣＲＲｅｑからの変更部分のみを返してくる。シリアル番号は、Ｖｉｓａディレクトリサーバ１６１２にあるカード範囲データベースの現状況を定義した値である。Ｖｉｓａディレクトリサーバ１６１２は、このシリアル番号をＭＰＩ １３４に提供する。この特定の値は、それを返してくる特定のＶｉｓａディレクトリサーバに対してのみ意味を持つ。

Ｖｉｓａディレクトリサーバ１６１２は、ＣＲＲｅｑの構文を検査し、もし検査が不合格である場合はエラーを返す。Ｖｉｓａディレクトリサーバ１６１２は、加入範囲を含むカード範囲応答（ＣＲＲｅｓ：Card Range Response）をフォーマットし、それをＭＰＩ １３４に送信する。Ｖｉｓａディレクトリサーバ１６１２は、応答の中にシリアル番号を含ませる。ＭＰＩ １３４は、この値を、翌日のＣＲＲｅｑメッセージに含ませるために保持しておく必要がある。ＭＰＩ １３４は、ＣＲＲｅｓの構文を検査し、もし検査が不合格である場合は、Ｖｉｓａディレクトリサーバ１６１２にエラーを返すことが好ましい。ＭＰＩ １３４は、自分のローカルキャッシュを更新する。リストは、追加されるまたは削除される範囲をアクションエレメントで示している返送されてきた順序にしたがって処理しなければならない。なお、もしＣＲＲｅｓがシリアル番号に関してエラー状態を示す場合は、ＭＰＩは、自分のローカルキャッシュをクリアし、シリアル番号を伴わないＣＲＲｅｑをサブミットしなければならない。

カード所有者のＰＡＮの認証が可能であるとき、ＭＰＩ １３４は、支払人認証要求（ＰＡＲｅｑ：Payer Authentication Request）メッセージを、カード所有者のクライアントデバイス１２２を介してＡＣＳ １１４に送信する。ステップ６は、カード所有者のクライアントデバイス１２２に送信されるＰＡＲｅｑメッセージを表している。このプロセスは、ＭＰＩ １３４が、Ｖｉｓａディレクトリサーバ１６１２からＶＥＲｅｓメッセージを受信した直後に生じる。ＭＰＩ １３４は、ＶＥＲｅｓの構文を検査し、もし検査が不合格である場合は、Ｖｉｓａディレクトリサーバにエラーを送信することが好ましい。ＭＰＩ １３４は、ＶＥＲｅｓに含まれる形で受信された口座ＩＤを含む支払人認証要求メッセージ（ＰＡＲｅｑ）をフォーマットする。ＭＰＩ １３４は、ＰＡＲｅｑメッセージのデフレート及びＢａｓｅ６４エンコードを行う。得られた結果は、ＰａＲｅｑ（大文字と小文字の違いに留意）と称される。

ＭＰＩ １３４は、ＰａＲｅｑ（大文字と小文字の違いに留意）、最終応答の提供先として好ましい商人ＵＲＬであるＴｅｒｍＵｒｌ、及びＭＤ（「商人データ」）の３つのフィールドを含むフォームを作成する。ＭＤフィールドは、商人に返されることが好ましい商人状態データを含む。このフィールドは、商人システムによるセッション状態の扱い方法の違いに対応するために使用される。商人システムが更なる補助なしに、最終な提供を元のショッピングセッションに関連付けられる場合は、ＭＤフィールドは空で良い。商人システムが、所定のショッピングセッションのための状態維持を行えない場合は、ＭＤは、商人がそのセッションを続けるために必要とするあらゆるデータを運ぶことができる。このフィールドのコンテンツは、商人の実装形態に応じて異なるので、ＡＣＳは、このフィールドのコンテンツを無条件で不変に保たなければならない。このフィールドは、０×２０から０×７ＥまでのＡＣＳII文字のみを含み、他のデータが必要な場合はＢａｓｅ６４エンコードしなければならない。フィールドの（もし該当する場合はＢａｓｅ６４エンコード後の）大きさは、１０２４バイトに限られる。ＭＤは、もし（ＰＡＮなどの）機密データを含む場合は暗号化することが好ましい。

ＭＰＩ １３４は、ＰＡＲｅｑを、ＶＥＲｅｓに含まれる形で受信されたＡＣＳ ＵＲＬに、カード所有者のブラウザを通じて引き渡す。この引き渡しは、カード所有者のブラウザが、ＡＣＳにフォームをＰＯＳＴすることによって行われる。これは、通常は、ＪａｖａＳｃｒｉｐｔを使用して実現される。カード所有者のブラウザに対応できるように、どの接続もＨＴＴＰＳである。

ステップ７は、カード所有者のクライアントデバイス１２２からＡＣＳ １１４に送信される支払人認証要求メッセージを表している。このプロセスは、ＭＰＩ １３４からのＰＡＲｅｑを含む提供をＡＣＳ １１４が受信した後に生じる。以下の説明は、カード所有者の認証がパスワードを使用して実施されるケースに該当する。チップカード上のアプリケーションに依存した方法など、他の方法も使用可能である。ＡＣＳは、ＰａＲｅｑフィールドのＢａｓｅ６４デコード及びインフレートによってＰＡＲｅｑ（大文字と小文字の違いに留意）を得る。ＡＣＳ １１４は、ＰＡＲｅｑの構文を検査し、もし検査が不合格である場合はエラーを返す。ＡＣＳ １１４は、下記の各要件が真であることを保証するためにＰＡＲｅｑデータを検査する。すなわち、１）ＡＣＳ １１４は、「Ｙ」のＰＡＮ認証可能値を有するＶＥＲｅｓにＰＡＲｅｑをリンクさせることができる、２）検査は、例えば、これらの２つのメッセージに含まれる形で提供された口座ＩＤを比較する、または、メッセージの提供先であったＵＲＬを、ＶＥＲｅｓに含まれる形で提供されたカスタマイズされたＡＣＳ ＵＲＬに関連付けるなど、ＡＣＳ １１４によって選択されるあらゆるメカニズムを通じて行うことができる、３）商人の国別コードは、有効なＩＳＯ ３１６６国別コードである、４）購入通貨は、有効なＩＳＯ ４２１７数字通貨コードである、並びに、５）購入額は表示額に等しい、という要件が真であることを保証するためである。いずれかの検査結果が不合格であるとき、ＡＣＳ １１４は、取引状況を「Ｎ」に設定され尚かつ無効要求を含む支払人認証応答（ＰＡＲｅｓ：Payer Authentication Response）メッセージをフォーマットする。

ステップ８において、ＡＣＳは、ＰＡＮに適用可能なプロセスを使用してカード所有者を認証する。これらのプロセスは、発行者１６１０とカード所有者１２２との間で予め設定されたパスワードまたはＰＩＮを要求する技術及びカード所有者にデータ質問を提示する技術などを含むが、これらに限定されない。データ質問は、例えば、ＡＣＳ １１４がカード所有者クライアントデバイス１２２に対し、カード所有者またはカード所有者クライアントデバイス１２２のＩＤを認証すると考えられる特定のデータ応答を提供するように要求することを含むことができる。ある筋書きでは、ＡＣＳ １１４は、カード所有者クライアントデバイスに対し、カード所有者１２２を認証すると考えられる特定の暗号文を作成するように要求することができる。あるいは、ＡＣＳ １１４は、認証を試みた証拠を作成することができる。ＡＣＳ １１４は、次いで、適切な値を含む支払人認証応答（ＰＡＲｅｓ）メッセージをフォーマットし、次いで、その応答メッセージにデジタル署名を施す。ＡＣＳ １１４は、パスワード、データ応答、または暗号文を、ＡＣＳ内に設けられた口座所有者データベースに照らして検査する。

ステップ９において、ＡＣＳ １１４は、支払人認証応答メッセージをカード所有者クライアントデバイス１２２に返す。ＡＣＳ １１４は、この時点で、選択されたデータを認証履歴サーバ１３０に送信することもできる。ＰＡＲｅｓメッセージを返すために、ＡＣＳ １１４は、ＰＡＲｅｓメッセージのデフレート及びＢａｓｅ６４エンコードを行う。得られた結果はＰａＲｅｓ（大文字と小文字の違いに留意）と称される。ＡＣＳ １１４は、ＰａＲｅｓ及びＭＤフィールドを含むフォームを作成する。ＡＣＳ １１４は、署名付きのＰＡＲｅｓを、カード所有者のブラウザを通じて商人ＵＲＬ（ＭＰＩからの提供に含まれるＴｅｒｍＵｒｌ）に引き渡す。この引き渡しは、カード所有者のブラウザがＭＰＩにフォームをＰＯＳＴすることによって行われる。このプロセスでは、ポップアップが閉じられ、制御が商人のブラウザのウィンドウに返される。これは、通常は、ＪａｖａＳｃｒｉｐｔを使用して実現される。また、ＡＣＳ １１４は、認証履歴サーバ１３０に送信される支払人認証取引（ＰＡＴｒａｎｓＲｅｑ：Payer Authentication Transaction）メッセージをフォーマットする。

ステップ１０において、カード所有者クライアントデバイスは、支払人認証応答メッセージをＭＰＩ １３４へと送る。このプロセスは、商人サーバプラグインがＡＣＳにＰＡＲｅｑを提供した後に生じる。ＭＰＩ １３４は、ＰａＲｅｓフィールド（大文字と小文字の違いに留意）を含む応答を読み出す。ＭＰＩは、ＰａＲｅｓフィールドをＢａｓｅ６４デコード及びインフレートすることによって、ＰＡＲｅｓまたはエラーを得る。ＭＰＩ １３４は、ＰＡＲｅｓの構文を検査し、もし検査が不合格である場合は（ＶＥＲｅｓに含まれる形で受信されたＡＣＳ ＵＲＬを介して）ＡＣＳにエラーを送信することが好ましい。

ステップ１１において、ＭＰＩ １３４は、ＡＣＳ １１４によって支払人認証応答メッセージ上に施されたデジタル署名を検査する。デジタル署名の検査は、ＡＣＳ １１４が自身で行う、または、支払人認証応答メッセージを別個の検査サーバに引き渡すことによって行うことができる。検査プロセスは、Ｖｉｓａルート証明書を使用してＰＡＲｅｓの署名を検査する。もし別個の検査サーバで検査が行われる場合は、ＭＰＩ １３４は、ＰＡＲｅｓを検査プロセスに送信し、検査プロセスは、Ｖｉｓａルート証明書を使用してＰＡＲｅｓ上の署名を検査し、その検査結果をＭＰＩに返す。

ステップ１２において、商人１３２は、決済者１６２２との与信交換に進む。

モバイル実装形態：インターネットデバイス
この節は、本発明による口座認証システムにおいて、インターネット接続可能なモバイルデバイスをサポートするために必要とされる、プロトコルの変更に関して説明する。この設計の意図は、モバイル対応のデバイスが、標準的なＰＣベースの実装形態をサポートすること並びに標準的な口座認証の実装形態と共存及び相互運用することを可能にすることにある。インターネット接続可能なモバイルデバイスは、ＷＡＰ電話としても知られている無線アプリケーションプロトコル対応の電話などのデバイスを含むが、それに限定されない。

モバイルインターネットデバイスのための口座認証は、通常は、パスワードをベースにした認証を使用する。しかしながら、他の認証方法も使用可能である。ＷＡＰ環境では、モバイルインターネットデバイスとＡＣＳとの間の接続及び同デバイスとＷＡＰゲートウェイとの間の接続を、様々なセキュリティプロトコルによってセキュア化することができる。そのうちの１つが、無線トランスポート層セキュリティ（ＷＴＬＳ）である。ゲートウェイとＡＣＳとの間の接続も、例えばセキュアソケット層（ＳＳＬ）またはトランスポート層セキュリティ（ＴＬＳ）などの様々なプロトコルによってセキュア化することができる。これは、パスワードが接続の両側で暗号化され、ゲートウェイで（一時的に）平文化されることを意味する。ゲートウェイは通常的に配備されるので、この変換は高度にセキュアな環境で生じ、これによって、内部のスタッフも外部からの侵入者も機密情報にアクセスできないことが保証される。ゲートウェイは、ＡＣＳによって（コスト対リスク評価に基づいて）選択された配備の形態に応じ、顧客の無線オペレータによって配備されても良いし、あるいは、ＡＣＳと同一場所に配備されても良い。

口座認証システムは、標準ブラウザのプラットフォーム上で動作するように構成することができる。しかしながら、将来の実施形態としては、様々なプラットフォーム上で動作できることを想定している。

ＷＡＰ電話などのモバイルインターネットデバイスは、コンピューティング環境及びネットワーク環境が更に限られるという点で、大きな課題である。これは、口座認証プロトコルを制約すると共にユーザエクスペリエンスを若干異ならせる。また、モバイルインターネットデバイスは、標準的なＰＣと比べてインターネットへの接続速度が一般に遅く、大抵の場合は１４，４００ボーまたはそれ未満である。また、ゲートウェイ及びモバイルユーザエージェントの多くは、メッセージごとに扱えるデータ総量に限界がある。データ総量の限界は一貫した基準を持たず、今後もばらつきが増しつづけることが予想されるが、現時点では８００〜１２００バイトの範囲に収まると考えられる。このように、メッセージの大きさは、ユーザエージェントまたはカード所有者を通る必要のあるメッセージにとって、重要な問題である。一般に、支払人認証要求（ＰＡＲｅｑ）メッセージ及び支払人認証応答（ＰＡＲｅｓ）メッセージは、非常に大きい。したがって、大抵のモバイルインターネットデバイスのブラウザは、これらのメッセージを伝送することが困難である。携帯用のデバイスは、一般に、その大きさに合わせてユーザインターフェース及びディスプレイウィンドウが小型に縮小されているという点で、ユーザエクスペリエンスが異なる。

これらの障害を念頭に置くと、モバイルインターネットデバイスを口座認証システムに組み込むためには、口座認証プロセスにいくつかの変更を加える必要がある。これらの変更は、ＣＰＲＱ及びＣＰＲＳと称されるメッセージの圧縮版を作成し、ＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージの大きさをそれぞれ減らすことを主眼とする。ある変更形態は、各メッセージのタグの大きさを減らすこと含む。例えば、各データフィールドのヘッダ及びフッタは、累積すると多大なデータ量を占めるようになる。したがって、これらを圧縮して小型版にすることができる。

一実施形態において、ＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージはＸＭＬメッセージとして定義され、メッセージの読み出し及び拡張を容易にする。ＸＭＬメッセージは、識別用の名前タグを有する複数のエレメントで構成される。しかしながら、タグ名は各メッセージのかなりの部分を占有する。更に不都合なことに、各タグ名はブラケット付きで二度現れる。ｎ文字のタグ名は、合計で２ｎ＋５の文字をメッセージに追加する。したがって、口座認証システムのモバイルインターネット実装形態は、ＰＡＲＥｑメッセージ及びＰＡＲｅｓメッセージを圧縮版の支払人認証要求（ＣＰＲＱ）及び圧縮版の支払人認証応答（ＣＰＲＳ）でそれぞれ置き換える。最大で１４文字の長さのタグ名を使用するＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージに対し、ＣＰＲＱメッセージ及びＣＰＲＳメッセージが使用するタグ名はわずか２文字ずつに過ぎない。

第２の変更形態は、認証プロセスで必要とされないデータを、ＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージから排除することを含む。また、ＭＰＩによって回復できるデータまたは他の情報をもとに回復できるデータは、必要の際には検索できるので、やはり、ＰＡＲｅｓメッセージに含まれる形で伝送する必要はない。一実施形態において、データフィールドの排除は、１）支払取引の認証で必要とされないフィールドをＰＡＲｅｑから排除してＣＰＲＱを作成する、及び２）商人サーバプラグイン（ＭＰＩ）の中のメモリまたは他の情報源から検索できるあらゆるデータエレメントをＰＡＲｅｓメッセージから排除してＣＰＲＳを作成する、というルールにしたがって実施される。

別の一変更形態は、データフィールドそれ自体の大きさを選択的に減らすことを含む。商人システム及びＡＣＳは、自由裁量のコンテンツを有するＣＰＲＱ及びＣＰＲＳのフィールドに含まれるデータの量を最小限に抑えることが好ましい。これは、ＣＰＲＱに含まれる商人ＵＲＬ及びＣＰＲＳに含まれるベンダコードに特に当てはまる。

さらに別の一変更形態は、選択されたデータを、インターネットを通じて発行者からＭＰＩに直接送信することを含む。例えば、ＡＣＳのデジタル証明書は、認証プロトコルによるカード所有者ＰＡＮの認証が可能であるか否かを検証するプロセスの際に、ＶＥＲｅｓメッセージを通して送信されることができる。このようにすれば、デジタル証明書は、カード所有者のモバイルインターネットデバイスを経由して伝送されるＣＰＲＳメッセージを通して引き渡されなくて良い。デジタル証明書は、ＶＥＲｅｓメッセージの拡張フィールドの中に配置することができる。一実施形態では、デジタル署名の特定のエレメント、すなわちＫｅｙＩｎｆｏエレメントが、ＶＥＲｅｓを通して送信される。デジタル署名のＫｅｙＩｎｆｏエレメントは、あらゆる取引を通じて不変の静的エレメントである発行者による署名付きの証明書チェーンを含む。このようにすれば、ＫｅｙＩｎｆｏエレメントは、ＣＰＲＳの一部として送信されなくて良い。代わりに、ＫｅｙＩｎｆｏエレメントは、ＶＥＲｅｓメッセージに含まれる形でＭＰＩに送信される。ＭＰＩは、このデータを、ＰＡＲｅｓメッセージを再構成する際の将来の使用に備えて保持する。

これらの方法は、図９に示された支払取引の説明の際に更に説明する。

図９は、本発明のモバイルインターネットデバイス実装形態に関し、口座認証プロトコルをシステムアーキテクチャに重ねて示した図である。図９に示された口座認証システムアーキテクチャは、発行者ドメイン１０２、相互運用性ドメイン１０４、及び決済者ドメイン１０６を含む。発行者ドメイン１０２は、カード所有者１２２、アクセス制御サーバ（ＡＣＳ）１１４、及び発行者１６１０を含む。カード所有者１２２は、カードを所有する人間と、例えばコンピュータ端末などのカード所有者のクライアントデバイスとを表している。カード所有者１２２は、ＡＣＳ １１４及び商人などの外側のエンティティに、ＷＡＰゲートウェイ１７０７を通じて接続されている。発行者１６１０は、カード所有者に決済カードを発行できるカード発行銀行を表している。相互運用性ドメイン１０４は、Ｖｉｓａディレクトリ１６１２、認証履歴サーバ１３０、及びＶｉｓａＮｅｔ１６１６を含む。この場合のＶｉｓａディレクトリ１６１２は、Ｖｉｓａによって制御されるディレクトリである。決済者ドメイン１０６は、商人１３２、商人プラグインソフトウェアモジュール（ＭＰＩ）１３４、及び決済銀行１６２２を含む。

図９の支払取引は、１〜１１の符号で示された矢印を通して説明される。支払取引は、ステップ１において、口座所有者すなわちカード所有者が、商人１２３との間でショッピング及び必要なあらゆる対話を行って、購入したい商品を決定し、購入を確定するために必要な任意の情報を提供する時点で開始する。

ステップ２において、ＭＰＩ １３４は、ＶＥＲｅｑメッセージをＶｉｓａディレクトリサーバ１６１２に送信する。ＶＥＲｅｑメッセージは、Ｖｉｓａディレクトリサーバ１６１２に宛てた、カード所有者の主要口座番号（ＰＡＮ）、チャネル、及びユーザデバイス情報を含む。ＭＰＩ １３４によってユーザデバイス情報が送信されるので、ＡＣＳは、モバイルインターネットデバイスで必要とされる圧縮メッセージをユーザデバイスが送受信できるか否かを決定することができる。具体的には、モバイルインターネットデバイスの場合はＢｒｏｗｓｅｒ．ｄｅｖｉｃｅＣａｔｅｇｏｒｙフィールドが１に設定されている。

ステップ３において、もしＰＡＮが加入カード範囲に含まれる場合は、Ｖｉｓａディレクトリサーバ１６１２は、適切なＡＣＳに照会し、その特定のＰＡＮの認証が可能であるか否かを決定する。

ステップ４において、ＡＣＳ １１４は、カード所有者１６１６が使用しているデバイス及びチャネルの情報に基づいて、ＰＡＮが口座認証サービスに登録されているか否か及び認証が実行可能であるか否かを示すＶＥＲｅｓメッセージを、Ｖｉｓａディレクトリサーバ１６１２に返す。前述のように、もし認証が実施可能である場合は、ＶＥＲｅｓメッセージのメッセージ拡張フィールドに、発行者のデジタル証明書が含まれる。このメッセージ拡張フィールドは、また、暗号化されたメッセージを復号化するためのキーを含むこともできる。このキー（例えばＫｅｙＩｎｆｏエレメント）は、ＰＡＲｅｓメッセージをアンロックするために使用することができる。

ステップ５において、Ｖｉｓａディレクトリサーバ１６１２は、ＡＣＳからの応答をＭＰＩ １３４に転送する。

ステップ６において、ＭＰＩ １３４は、ＰＡＲｅｑメッセージを作成する代わりに圧縮版の支払人認証要求（ＣＰＲＱ）メッセージを作成し、それをカード所有者１２２のデバイスを介してＡＣＳ １１４に送信する。図１０を参照せよ。図１０は、一実施形態にしたがって、圧縮版の支払人認証要求メッセージを構成するデータフィールドを示した表である。前述のように、いくつかの実施形態では、ＣＰＲＱは、口座認証プロセスで必要とされるデータフィールドのみを含む。

ＰＡＲｅｑには、注文記述フィールドが含まれるのが通常である。これは、認証プロセスの際にカード所有者に表示できる希望注文に関する追加データをＡＣＳに提供するためである。このフィールドは、ＣＰＲＱでは省略される。なぜなら、このフィールドは長いデータストリングを含む傾向があるうえ、大抵のモバイルインターネットデバイスは能力に限界があって大量のテキストを表示できないからである。また、注文記述フィールドは、認証に必要ではない。

定期循環頻度（ｒｆ）データフィールド及び定期循環有効期限（ｅｒ）データフィールドは任意である。ただし、いずれか一方のエレメントが含まれるならば、必然的に両方とも含まれなければならない。商人ＵＲＬフィールドは、モバイルインターネットデバイス実装形態では任意である。商人は、ＣＰＲＱの伝送を容易にするために、商人ＵＲＬの大きさを最小限に抑えることができる。商人ＵＲＬは、このプロトコル拡張では任意であるが、認証履歴サーバに送信されるメッセージでは必須である。このデータがＣＰＲＱに含まれる形で受信されなかった場合は、ＡＣＳは、ＰＡＴｒａｎｓＲｅｑの中の商人ＵＲＬフィールドを、ＨＴＴＰ＿ＲＥＦＥＲＥＲヘッダのコンテンツで満たすように試みることが好ましい。ブラウザがこのヘッダを提供しない場合は、商人ＵＲＬは、空フィールドの形でＰＡＴｒａｎｓＲｅｑの中に含まれなければならない。

いくつかの実施形態において、ＭＰＩ １３４は、圧縮変更版のＣＰＲＱを作成する。使用できる圧縮アルゴリズムの１つは、ＤＥＦＬＡＴＥアルゴリズムである。ＣＰＲＱメッセージは、ウェブブラウザによるメッセージの扱いをより容易にするために、Ｂａｓｅ６４エンコードによって変更することができる。ＤＥＦＬＡＴＥアルゴリズムは、ＲＦＣ１９５０に記述され、結果として得られるデータストリームは、ＲＦＣ１９５０に明記されるようにＺＬＩＢ圧縮データフォーマットで表される。結果として得られるデータストリームは、Ｂａｓｅ６４エンコードも経ている。したがって、一実施形態において、ＭＰＩ １３４は、ＣＰＲＱメッセージのデフレート及びＢａｓｅ６４エンコードによってＣ６４Ｑメッセージを作成する。ＭＰＩ １３４は、また、Ｃ６４Ｑ（またはＣＰＲＱ）、ＴｅｒｍＵｒｌ、及びＭＤの３つの隠しフィールドを含むフォームを構成する。ＭＰＩは、次いで、（例えばＯｎＥｎｔｅｒＦｏｒｗａｒｄまたはＯｎＴｉｍｅｒＦｏｒｗａｒｄなどの標準的なＷＭＬスクリプトを使用している）ＡＣＳへとユーザをリダイレクトする。ＭＰＩ １３４は、次いで、Ｃ６４Ｑ（またはＣＰＲＱ）を含むフォームをＡＣＳ １１４に送信する。

ステップ７において、ＡＣＳ １１４は、ＣＰＲＱメッセージまたはＣ６４Ｑメッセージを受信する。なお、ＡＣＳ １１４では、完全版の支払認証要求メッセージが再作成されることはない。ステップ８において、ＡＣＳ １１４は、ＰＡＮ及びチャネルに適用可能なプロセスを使用してカード所有者１２２を認証し、適切な値を含むＰＡＲｅｓメッセージをフォーマットし、次いで、前述のようにそれに署名を施す。

ステップ８において、ＡＣＳ １１４は、ＩＤ認証のプロセスを実施する。

次いで、ＡＣＳ １１４は、先ずは完全なＰＡＲｅｓメッセージを構成し、次いでＣＰＲＳを構成する。ＡＣＳ １１４は、ＰＡＲｅｓメッセージの値に基づいて、圧縮版の支払人認証応答（ＣＰＲＳ）メッセージを作成する。図１１を参照せよ。図１１は、一実施形態にしたがって、圧縮版の支払人認証応答メッセージを構成するデータフィールドを示した表である。いくつかの実施形態では、ＡＣＳ １１４は、ＣＰＲＳのデフレート及びＢａｓｅ６４エンコードによってＣ６４Ｓメッセージを作成する。ＡＣＳ １１４は、また、Ｃ６４Ｓ（またはＣＰＲＳ）フィールド及びＣＰＲＱメッセージに含まれる形で受信されたＭＤフィールドという２つの隠しフィールドを含むフォームを構成する。ＡＣＳ １１４は、次いで、（例えばＯｎＥｎｔｅｒＦｏｒｗａｒｄまたはＯｎＴｉｍｅｒＦｏｒｗａｒｄなどの標準的なＷＭＬスクリプトを使用している）ＴｅｒｍＵｒｌへとユーザをリダイレクトする。

ＰＡＲｅｓに含まれるエレメントは、ＣＰＲＱから意図的に排除されたエレメント以外はどれも、変更されたタグ及び未変更のコンテンツを伴う形でＣＰＲＳに含まれることが好ましい。例えば、ある任意のフィールドが、空エレメントの形でＰＡＲｅｓに含まれる場合は、そのフィールドは、変更されたタグを伴う空エレメントの形でＣＰＲＳにも含まれることが好ましい。下記のフィールドは、ＰＡＲｅｓで定義されているがＣＰＲＳからは排除されているフィールドである。

なお、これらのフィールドは、ＣＰＲＳには含まれないものの、ＭＰＩのメモリでは使用することができる。ＭＰＩは、ＣＰＲＳの全てのフィールドをＣＰＲＱに含ませたので、これらのデータは、ＰＡＲｅｓを再構成する際に使用可能である。

ステップ９において、ＡＣＳ １１４は、カード所有者１２２のデバイスを介し、ＣＰＲＳまたはＣ６４Ｓ及びフォームをＭＰＩ １１４に返す。それと同時に、ＡＣＳ １１４は、完全版のＰＡＲｅｓを含むデータを認証履歴サーバ１３０に送信する。認証履歴サーバに完全版のＰＡＲｅｓが送信されるので、紛争解決及び報告の際にはあらゆるフィールドが使用可能である。

ステップ１０において、ＭＰＩ １３２は、ＣＰＲＳを受信し、完全版のＰＡＲｅｓを再構成する目的でＭＰＩ １３４のメモリからデータフィールドを検索し、その署名を検査し、次いで、残りのフィールドを処理する。

ＭＰＩ １３２は、以下のステップを経ることによって、ＣＰＲＳメッセージからＰＡＲｅｓメッセージを再構成する。ＭＰＩ １３２は、ＣＰＲＳメッセージから除外されていたデータフィールドを、自身の記録の中から検索する。ＡＣＳによって作成されたＰＡＲｅｓとＭＰＩによって再構成されたＰＡＲｅｓとを厳密に一致させるためには、ＣＰＲＳから除外されたＰＡＲｅｓエレメントのコンテンツがＰＡＲｅｑに含まれるそれと厳密に同じであることが好ましい。

ＭＰＩ １３２は、特定のステップを経ることによってＡＣＳの署名を検査する。ここで、ＰＡＲｅｓが署名付きのメッセージであるのに対し、ＣＰＲＳはそうでない点に留意せよ。その代わりに、ＣＰＲＳは、ＰＡＲｅｓのデジタル署名から得られたＳｉｇｎａｔｕｒｅＶａｌｕｅエレメントを含む。デジタル署名の他の２つのエレメント、すなわち、ＳｉｇｎｅｄＩｎｆｏ及びＫｅｙＩｎｆｏは省略されている。ＳｉｇｎａｔｕｒｅＶａｌｕｅを検査するために、ＭＰＩは、１）ＣＰＲＳに含まれる形で提供されたデータと、２）ＣＰＲＱに含まれる形で送信された検索データと、３）ＶＥＲｅｓから検索されたＫｅｙＩｎｆｏエレメント（発行者が署名した証明書チェーンを含む）と、を使用してＰＡＲｅｓを再構成する。

ステップ１１において、商人１３２は、決済者との与信交換に進む。

前述のように、ＭＤフィールドは、特定の取引を、すなわちショッピングセッションを記述した情報を含む。ＭＤフィールドは、認証要求及び認証応答のメッセージに添付されているので、商人は、認証応答メッセージを元のショッピングセッションに関連付けて状態を復元することができる。ＣＰＲＱと共に送信され、続いてＣＰＲＳと共に返されるＭＤフィールドは、可能な限り短く維持されることが好ましい。取引ＩＤなどの別のフィールドを状態管理のために使用するためには、このフィールドは空であることが好ましい。

モバイル実装形態：インターネット接続不可のデバイス
これまでは、カード所有者がインターネット対応のデバイスを使用してショッピングを行い尚かつ認証がインターネットを通じて行われる「インターネットショッピング」に焦点を当てて、本発明による口座認証プロトコルの説明を行ってきた。前の節では、インターネット接続可能なモバイルインターネットデバイス（具体的にはＷＡＰ電話など）を使用してインターネットショッピングをサポートする実装形態に関してプロトコルの説明を行った。しかしながら、ショッピング及び認証は、いずれも、能力の限られた携帯電話を使用して実施することができる。本発明では、例えば、ショートメッセージサービス（ＳＭＳ）または非構造付加サービスデータ（ＵＳＳＤ）に基づく双方向メッセージングを使用するデバイスを使用することもできる。また、音声自動応答（ＩＶＲ）システムに代表される標準の音声チャネルを使用するデバイスを使用することもできる。いくつかの実施形態では、メッセージングチャネル及び音声チャネルの両方を、認証プロセスの異なる段階で同時にまたは交互に利用することができる。この節は、ショッピング及び認証におけるＳＭＳ、ＵＳＳＤ、または音声／ＩＶＲの使用をサポートするために本発明による口座認証プロトコルで必要とされるプロトコルの変更を明確にする。

口座認証プロトコルは、一般に、ＨＴＭＬまたはＷＭＬに基づくメッセージをカード所有者のデバイスを通じてＡＣＳとＭＰＩとの間で送信することによって動作する。これらの動作は、支払人認証要求及び支払人認証応答をＨＴＭＬフォームまたはＷＭＬフォームに組み込むことによって実現される。これらのフォームは、次いで、カード所有者デバイスのブラウザによるリダイレクトを経て交換される。これらの基本的なステップを、ここにまとめて列挙する。１）商人サーバプラグイン（ＭＰＩ）は、支払人認証の要求（ＰＡＲｅｓ）を発行者のＡＣＳに送信し、応答（ＰＡＲｅｓ）を受信する。なお、これらのメッセージは、いずれもカード所有者のデバイスを経由する点に留意せよ。２）カード所有者及びＡＣＳは、互いに接続してチャネルを確立することができる。ＡＣＳは、このチャネルを通じてカード所有者との間で認証対話を行うことができる。３）カード所有者は、支払処理を完了させるために商人に再接続することができる。

しかしながら、カード使用者が使用するアクセスデバイスが、インターネットに接続する能力を有さず、とりわけウェブブラウザを使用しない場合は、ＭＰＩとＡＣＳとの間における支払人認証要求及び支払人認証応答の転送、並びにＡＣＳとカード所有者との間における認証対話は、代替のメカニズムによって行われることが好ましい。

音声及びメッセージングデバイスの使用を取り入れるためのこれらの代替のメカニズムは、以下の動作を伴う。先ず第１に、ＭＰＩ及びＡＣＳは、支払人認証要求メッセージ及び支払人認証応答メッセージ（ＰＡＲｅｑ／ＰＡＲｅｓ）を、カード所有者のデバイスを経由してではなくインターネットを通じて直接的に交換する。一実施形態では、ＰＡＲｅｑ及びＰＡＲｅｓをＭＰＩとＡＣＳとの間で直接的に伝送するために、ＭＰＩは、支払人認証要求（ＰＡＲｅｑ）を含むＨＴＭＬフォームを構成し、そのフォームをＡＣＳに直接ＰＯＳＴする。次いで、ＡＣＳは、応答（ＰＡＲｅｓ）を含むフォームを構成し、そのフォームをＭＰＩにＰＯＳＴし返す。ただし、ＭＰＩは、ＡＣＳからＰＡＲｅｓを受信するまでに一定期間のあいだ待機しなければならない。これは、固有の待ち時間を有するＳＭＳを介して認証が実施される場合に特に当てはまる。この実装形態では、カード所有者とＡＣＳとの間及びカード所有者とＭＰＩとの間ではＳＭＳ、ＵＳＳＤ、またはＩＶＲのシステムが利用され、それ以外の伝送ではインターネットが使用される。第２に、ＰＡＲｅｑメッセージ、ＰＡＲｅｓメッセージ、ＶＥＲｅｑメッセージ、及びＶＥＲｅｓメッセージに変更が加えられる。

図１２は、音声及びメッセージングデバイスが使用される代表的な支払取引を説明している。図１２の説明後は、ＰＡＲｅｑメッセージ、ＰＡＲｅｓメッセージ、ＶＥＲｅｑメッセージ、及びＶＥＲｅｓメッセージの変更に関する詳細を述べる。

図１２は、インターネット接続不可のデバイスを取り入れた口座認証システムアーキテクチャに支払取引を重ねて示した図である。図１２の口座認証システムアーキテクチャは、発行者ドメイン１０２、相互運用性ドメイン１０４、及び決済者ドメイン１０６を含む。発行者ドメイン１０２は、カード所有者１２２、ＡＣＳ １１４、及び発行者１６１０を含む。カード所有者１２２は、カードを所有する人間と、例えばコンピュータ端末などのカード所有者クライアントデバイスとを表している。発行者１６１０は、カード所有者に決済カードを発行できるカード発行銀行を表している。相互運用性ドメイン１０４は、Ｖｉｓａディレクトリ１６１２、認証履歴サーバ１３０、及びＶｉｓａＮｅｔ１６１６を含む。この場合のＶｉｓａディレクトリ１６１２は、Ｖｉｓａによって制御されるディレクトリである。決済者ドメイン１０６は、商人１３２、商人プラグインソフトウェアモジュール（ＭＰＩ）１３４、及び決済銀行１６２２を含む。

ステップ１において、カード所有者１２２は、商人１３２との間に音声チャネルまたはメッセージングチャネルを確立する。カード所有者１２２は、商人１３２との間で対話を行い、購入したい商品を決定し、購入を確定するために必要な情報を提供することによって、商人１３２によって提供される商品またはサービスをショッピングすることができる。このようなショッピング遊覧は、プリペイド式通話料の計算及び補充を含む。ある一実施形態では、カード所有者１２２と商人１３２との間の接続は、双方向メッセージングチャネルである。双方向メッセージングを介してショッピングが行われるとき、カード所有者と商人との間に永続的なセッションは確立されない。したがって、電話などのカード所有者デバイスは、他のメッセージを受信することもできる。簡易メッセージは、その電話が音声通話中であっても使用することができる。これは、ＭＰＩからの支払人認証要求（ＰＡＲｅｑ）の受信後に、ＡＣＳが直ちにＳＭＳ、ＵＳＳＤ、または音声を通じてカード所有者との間に認証対話を開始させられることを意味する。

別の一実施形態において、カード所有者１２２と商人１３２との間の接続は、音声チャネルである。顧客は、例えば音声自動応答装置（ＩＶＲ）にダイアルすることによって、プリペイド式の料金の補充を開始することができる。発行者のＡＣＳが、メッセージングチャネルを使用した認証を予定している場合は、それが、商人による音声チャネルの使用とかちあうことはない。携帯電話によって、発行者は、商人との間で音声通話を維持しつつ、カード所有者との間でメッセージングによる通信を行うことができる。しかしながら、ＡＣＳは、商人がＰＡＲｅｑの送信前にカード所有者との通話を終了させない限りは、音声チャネルを使用した認証を行うことはできない。したがって、音声チャネルの使用を予定している場合は、ＡＣＳは、１）ショッピングがメッセージングチャネル上で行われているか否か、または、２）もし音声チャネルが必要ならば、商人に通話を終了する意志があることをＭＰＩがＶＥＲｅｑの中で示しているか否か、を決定しなければならない。音声チャネルの使用を予定しておらず、尚かつ、メッセージングチャネルを使用した認証対話を行うことができない場合は、ＡＣＳは、認証が不可能であることをＶＥＲｅｓの中で示さなければならない。

ステップ２において、ＭＰＩ １３４は、Ｖｉｓａディレクトリサーバ１６１２にＶＥＲｅｑメッセージを送信する。ＶＥＲｅｑメッセージは、Ｖｉｓａディレクトリサーバ１６１２に宛てた、カード所有者の主要口座番号（ＰＡＮ）、チャネル、及びユーザデバイス情報を含む。このプロセスにおいて、ＶＥＲｅｑ及びＶＥＲｅｓは、カード所有者のデバイスによって使用されるプロトコルを確認するために使用される情報を含む。

ステップ３において、もしＰＡＮが加入カード範囲に含まれる場合は、Ｖｉｓａディレクトリサーバ１６１２は、適切なＡＣＳに照会し、そのＰＡＮの認証が可能であるか否かを決定する。

ステップ４において、ＡＣＳは、カード所有者のデバイス及びチャネルの情報に基づいて、ＰＡＮが口座認証サービスに登録されているか否か及び認証が実施可能であるか否かをＶｉｓａディレクトリサーバ１６１２に応答する。

ステップ５において、Ｖｉｓａディレクトリサーバは、ＡＣＳの応答（またはそれ自体）をＭＰＩ １３４に転送する。カード所有者１２２が口座認証システムに登録されていない場合または認証が不可能である場合は、商人、決済者、または支払プロセッサは従来方式の与信要求をサブミットし、処理は終了する。

ステップ６において、ＭＰＩは、支払人認証要求（ＰＡＲｅｑ）を作成し、それをインターネットを通じてＡＣＳに直接送信する。繰り返しになるが、ＰＡＲｅｑは、カード所有者１２２を介してＡＣＳに送信されるのではない。ＭＰＩは、クライアントとして機能することによって、適切なＡＣＳ ＵＲＬとの間にセキュア接続を確立する。ステップ７において、ＡＣＳは、支払人認証要求を受信する。

ステップ８において、ＡＣＳは、ＰＡＮ及びチャネルに適用可能なプロセスを使用してカード所有者１２２を認証し、適切な値を含むＰＡＲｅｓメッセージをフォーマットし、それにデジタル署名を施す。このためには、ＡＣＳは、ＭＰＩからのＰＡＲｅｑの受信後に、カード所有者との間に接続を確立する必要がある。具体的に言うと、ＡＣＳは、この接続を確立するために、カード所有者の電話番号を必要とする。電話番号は、ＡＣＳに予め登録することができる。或いは、ＡＣＳは、カード所有者から電話番号を受信した商人を通じてカード所有者の電話番号を取得することができる。プロトコルの代替の一実装形態では、パスワードなどの認証情報は、カード所有者１２２からＡＣＳに送信することができる、または、カード所有者１２２から商人１３２に送信し、次いで、商人１３２からＡＣＳ １１４に送信することができる。

双方向メッセージングチャネル及び音声チャネルは、いずれも認証処理に使用することができる。双方向メッセージングチャネルが認証に使用される場合は、発行者は、１つまたはそれ以上のメッセージを顧客の電話に送信する。顧客の電話は、発行者及び取引情報を表示して顧客の承認を求める。メッセージは、単純にパスワード／ＰＩＮの入力を求める場合もあるし、ユーザのデバイス上で例えばＳＭＩツールキットアプリケーションなどのアプリケーションを起動させる場合もある。ＡＣＳは、メッセージングチャネルを通じて様々な認証メカニズムを使用することができる。このメカニズムは、１）単純なパスワード／ＰＩＮ、２）暗号化されたパスワード／ＰＩＮ、３）対称暗号方式（Ｔｒｉｐｌｅ−ＤＥＳ ＭＡＣ）を使用した質問／応答、４）公開鍵に基づいた質問／応答メカニズム（ＰＫＩ）、及び４）ＥＭＶ暗号文を含む。電話で使用できるアプリケーションがない場合は、パスワードに基づいた単純な認証が使用される。

メッセージングチャネルまたは音声チャネルを使用した認証は、カード所有者がショッピング用のチャネルとして自分のパソコンからのインーネット接続を使用している場合でも可能である。（カード所有者の電話及び携帯電話会社の能力によっては、カード所有者がＷＡＰブラウザを使用してショッピングしている場合でも可能である。）このとき、支払人認証要求及び支払人認証応答は、カード所有者のブラウザによるリダイレクトを経てＭＰＩとＡＣＳとの間で交換される。発行者が、ＳＭＳ／ＵＳＳＤまたはＩＶＲのシステムを使用してカード所有者を認証したいと望む場合は、これらは、要求を受信した時点で呼び出しを開始することができる。ＡＣＳは、あらかじめ登録されている電話番号を使用しても良いし、あるいは、カード所有者のパソコンにインターネット接続することによってカード所有者に電話番号を要求しても良い。

このようなアプローチを採る前に、発行者及びＡＣＳプロバイダは、待ち時間に関する問題を考慮することが好ましい。これは、ＳＭＳを使用した認証が予定されている場合に特に必要である。ＳＭＳの待ち時間は長いので、たとえカード所有者とのブラウザ接続がその期間中ずっと維持されていても、商人は認証の完了前に取引を「時間切れ」にする可能性がある。

ステップ９において、ＡＣＳは、ＭＰＩにＰＡＲｅｓを返す。ＡＣＳは、また、選択されたデータを認証履歴サーバ１３０に送信する。ＡＣＳは、認証が完了したときに、下記のようにＭＰＩにＰＡＲｅｓを返す。先ず、ＡＣＳは、クライアントとして機能することによって、適切なＵＲＬへのセキュア（ＨＴＴＰＳ）接続を確立する。ｐａＲｅｓ ＵＲＬフォームフィールドが提供された場合は、ＡＣＳは、ｐａＲｅｓ ＵＲＬに接続する。なお、プロキシサーバプロバイダは、ＴＬＳ／ＳＳＬセッションを確立するためにプロキシサーバによって使用されるルート証明書を定義している。これは、相互運用性ドメインにあるプロキシサーバの場合はＶｉｓａのルート証明書である。このとき、プロキシサーバは、ＰＡＲｅｑと共にＭＰＩから提供されたＴｅｒｍＵｒｌに応答が転送されることを保証することが好ましい。それ以外の場合は、ＡＣＳがＴｅｒｍＵｒｌに接続する。ＴＬＳ／ＳＳＬセッションを確立するために使用されるルート証明書は、ＰＡＲｅｑを含むＨＴＭＬフォームの中のＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔとして提供される。前述のように、ＡＣＳは、ＭＤ及びＲａＲｅｓ（文字の種類に留意せよ）を含むフォームを構成し、確立された接続を通じてそのフォームをＰＯＳＴする。

ＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔフィールドは、ＰＡＲｅｓを返すためのセッションをＡＣＳが続いて確立する際にＭＰＩによって使用される、ルートＳＳＬ証明書を含む。ＭＰＩは、この証明書を、ＰＡＲｅｑを含んでいたＨＴＭＬフォームの中に、ＴｅｒｍＵｒｌと共に含ませることが好ましい。この証明書は、ＰＡＲｅｓと同様に、デフレート及びＢａｓｅ６４エンコードされることが好ましい。このフィールドを必要とし尚かつこのフィールドを使用するＡＣＳの実装形態は、信頼できるＳＳＬルート証明書に関する明確な知識をＳＳＬ接続の確立前に必要とする。商人サーバとの間にＨＴＴＰＳセッションを確立するに当たって、ＡＣＳは、セッションを確立する間にＭＰＩサーバの証明書を検査しないことを選択して良い。あるいは、ＡＣＳは、ＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔフィールドに含まれる形でＭＰＩによって事前に提供されたルート証明書を使用してサーバの証明書を検査することを選択して良い。いくつかの実装形態では、ＡＣＳは、商人サーバ証明書の検証に使用するための証明書用キャッシュを維持して良い。これは、（ブラウザと同様に）ひとそろいのよく使用される市販のルート証明書を含むと考えられる。ＡＣＳは、このキャッシュを独占的に使用する場合は、商人サーバへの接続を確立できない場合がある。ＡＣＳは、このようなキャッシュを使用する場合は、キャッシュを維持及び更新する方法を必要とする。ＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔフィールドに含まれる形で受信された証明書は、後続の使用に備えてキャッシュに追加されることが好ましい。

ステップ１０において、ＭＰＩは、支払人認証応答を受信する。ステップ１１において、ＭＰＩは、支払人認証応答の署名を検査する。ステップ１２において、商人は、決済者との与信交換に進む。

次に、ＰＡＲｅｑメッセージ、ＰＡＲｅｓメッセージ、ＶＥＲｅｑメッセージ、及びＶＥＲｅｓメッセージに加えられる変更に関して更に説明する。これらのメッセージに加えられる変更は、新しいデータフィールドの追加を含む。ある一実施形態において、これらの新しいフィールドは、拡張エレメント（拡張フィールド）に含まれるＸＭＬエレメントとして実装される。これらの変更の一部または全部は、口座認証システムの特定のパラメータに応じてメッセージに加えられる。

認証を完了したＡＣＳは、ＰＡＲｅｓをＭＰＩに返す。次いで、商人システムは、支払確認を（商人の商習慣に応じてＳＭＳ、ＵＳＳＤ、または他の方法で）カード所有者に送信する。

先ず、ＶＥＲｅｑメッセージから各メッセージの説明を始める。ＭＰＩは、ＡＣＳによる特定の一カード番号の認証が可能であるか否か及びどのチャネルを通して認証が行われるかを知るために、登録検証要求（ＶＥＲｅｑ）を送信する。ＶＥＲｅｑメッセージは、ＭＰＩが以下の機能を実施できるように変更される。第１に、ＭＰＩは、使用されているショッピングチャネルが双方向メッセージングチャネル及び音声チャネルのいずれであるかを特定することが好ましい。これは、カード所有者によって使用されるデバイスの種類を特定するデータフィールドの中に定義された加算値を使用して示すことができる。これらの加算値は、例えば、口座認証システムに含まれる標準的なフィールドであるＢｒｏｗｓｅｒ．ｄｅｖｉｃｅＣａｔｅｒｇｏｒｙフィールドの中に配置することができる。一実施形態では、値２が双方向メッセージング（ＳＭＳまたはＵＳＳＤ）を指定し、値３が音声チャネルを指定する。

第２に、ＭＰＩは、ＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージがどのチャネルを通して送信されるかを示すことが好ましい。メッセージ認証技術及び音声認証技術のためには、直接チャネルが確立され示されることが好ましい。この表示は、ｐａＲｅｑＣｈａｎｎｅｌと称されるＶＥＲｅｑメッセージの拡張フィールドに含ませることができる。ｐａＲｅｑＣｈａｎｎｅｌの中には、例えば、「ブラウザ」や「直接」などの値を設定することができる。値「ブラウザ」は、支払人認証要求／支払人認証応答のメッセージ対がカード所有者のブラウザによるリダイレクトを経て交換されることを示す。値「直接」は、ＰＡＲｅｑメッセージ及びＰＡＲｅｓメッセージがインターネットを通じて直接交換されることを示す。ショッピングチャネルが双方向メッセージングチャネルまたは音声チャネルである場合は、値は「直接」に特定されることが好ましい。このフィールドに何のインスタンスも含まれない場合は、値は「ブラウザ」であると想定することができる。

第３に、ＭＰＩは、カード所有者の電話番号のハッシュを含むことが好ましい。ＡＣＳは、このハッシュを活用することによって、認証が可能であるか否かを決定することができる。この表示は、ＣｈｐｈｏｎｅＨａｓｈと称されるＶＥＲｅｑメッセージの拡張フィールドに含ませることができる。ＭＰＩは、カード所有者の電話番号のＳＨＡ−１ハッシュを作成することができる。ハッシュ化された電話番号は、ＰＡＲｅｑメッセージの中のＣＨｐｈｏｎｅ拡張フィールド用に定義されたものと同じフォーマットを採ることが好ましい。ＡＣＳは、もし必要ならば、このフィールドを使用することによって、カード所有者がＡＣＳに既に知られている電話番号を使用しているか否かを決定して良い。一実施形態において、ＣＨｐｈｏｎｅフィールドは２８バイトのフィールドであり、２０バイトのハッシュのＢａｓｅ６４エンコードを含む。

第４に、ＭＰＩは、商人が音声チャネルの使用をＡＣＳに譲り渡す意志があるか否かを示すことが好ましい。この表示は、ＶｏｉｃｅＣｈａｎＴｒａｎｓｆｅｒと称される拡張フィールドに含ませることができる。このフィールドは、ショッピングチャネルが音声チャネルである場合にＭＰＩによって使用される。ＶｏｉｃｅＣｈａｎＴｒａｎｓｆｅｒは、商人が音声チャネルの使用を発行者に譲り渡すことができるか否か及びどのような方法で譲り渡すかを、ＡＣＳに対して示すことができる。例えば、商人から発行者に音声チャネルの使用を譲り渡す技術の１つは、商人がカード所有者の電話との通話を終了し、発行者のシステムがカード所有者の電話と通話できるようにすることを含む。ＶｏｉｃｅＣｈａｎＴｒａｎｓｆｅｒの代表的な値は、「なし」及び「通話終了」である。値「なし」は、商人がチャネルを譲り渡せず、したがって発行者がそのチャネルを使用できないことを示す。値「通話終了」は、商人が通話を終了できることを示す。値「なし」はデフォルトであるので、このエレメントがメッセージに含まれない場合は「なし」であると想定される。値「なし」が受信され、尚かつ、ＡＣＳが音声チャネルの使用を必要とする場合は、ＡＣＳは、ＶＥＲｅｓメッセージにＰＡＮ認証可能値「Ｕ」を含ませて返さなければならない。

第５に、ＭＰＩは、必要に応じて、カード所有者が使用できる追加のデバイスまたはデバイス機能に関する情報を提供することが好ましい。この情報は、ＣＨＤｅｖＣａｐと称される拡張フィールドに含ませることができる。このフィールドは、カード所有者が（ショッピングチャネルそれ自体に内在するもの以外に追加で）使用できるデバイスまたはデバイス機能に関する追加情報を商人システムがＶＥＲｅｑに含ませる必要があるような、口座認証システムのリージョナルな実装形態において、すなわちローカルな実装形態において使用することができる。このような特定の実装形態においてこの情報が必要とされる場合は、このエレメントはＭＰＩを使用して提供される。このような実装形態においてこのフィールドが必要とされない場合は、ＡＣＳは、このフィールドのコンテンツを、もし存在するならば無視して良い。ＭＰＩは、このフィールドのインスタンスを、適用可能な数だけ含んで良い。このフィールドのために定義された値は、例えば、１）ＤＰ＝ＤＴＭＦトーンを生成できるデジタル固定電話または携帯電話、２）ＳＭＳ＝ＳＭＳをサポートする携帯電話またはＰＤＡ、及び３）ＵＳＳＤ＝ＵＳＳＤをサポートする携帯電話またはＰＤＡである。

次に、ＶＥＲｅｓメッセージに加えられる変更を説明する。ＶＥＲｅｓメッセージの拡張は、ＡＣＳ及びＶｉｓａディレクトリサーバが追加データの伝送を扱えるようにすることを目的とする。ＡＣＳに関し、ＶＥＲｅｓメッセージは、ＡＣＳがＶＥＲＥｑメッセージに追加された拡張フィールドに応答できるように拡張することができる。ある一実施形態において、ＶＥＲｅｓは、追加のｐａＲｅｑＣｈａｎｎｅｌフィールド及びＶｏｉｃｅＣｈａｎＴｒａｎｓｆｅｒフィールドを有する。

ＰａＲｅｑＣｈａｎｎｅｌ拡張フィールドは、ＭＰＩが支払人認証要求／支払人認証応答のメッセージ対の交換用に１本またはそれ以上の代替チャネルを提供した場合に使用される。ＶＥＲｅｓに含まれるＰａＲｅｑＣｈａｎｎｅｌの値は、ＰＡＲｅｑ及びＰＡＲｅｓの交換用に選択された方法を示している。ＶＥＲｅｓに含まれるＰａＲｅｑＣｈａｎｎｅｌのインスタンスは１つのみで良い。ＰａＲｅｑＣｈａｎｎｅｌフィールドは、ＶＥＲｅｑの中に列挙された最初のサポートチャネルに一致することが好ましい。ＶＥＲｅｑの中のＤｅｖｉｃｅＣａｔｅｇｏｒｙが双方向メッセージングチャネルまたは音声チャネルを示す場合は、ＰＡＲｅｑ／ＰＡＲｅｓのメッセージ対の交換用に選択されるチャネルは「直接」チャネルでなければならない。ＡＣＳが、提供されたどの方法もサポートしない場合は、このフィールドは応答に含まれず、ＰＡＮ認証可能値は「Ｕ」に設定されることが好ましい。

ＶｏｉｃｅＣｈａｎＴｒａｎｓｆｅｒ拡張フィールドは、ＡＣＳが認証のために音声チャネルの使用を望んでおり、尚かつ、その音声チャネルがショッピングに使用中であることをＭＰＩが示した場合に、ＡＣＳによって使用される。ＡＣＳは、たった１つのインスタンスからなるこのエレメントをＶＥＲｅｓの中に含ませれば良く、そのインスタンスは、ＶＥＲｅｑに含まれる形で受信されたインスタンスに一致することが好ましい。ＡＣＳが、（値「通話終了」を送信することによって）通話の終了を商人に要求した場合は、商人は、ＰＡＲｅｑを送信する前にカード所有者との通話を終了させることが好ましい。ＡＣＳが、このエレメントを含ませないまたは値「なし」を送信する場合は、商人は、何の動作も起こさなくて良い。

Ｖｉｓａディレクトリサーバに関し、ＶＥＲｅｓメッセージは、ＶｉｓａディレクトリサーバがＰＡＲｅｑ／ＰＡＲｅｓの交換の最中にＭＰＩとＡＣＳとの間でプロキシサーバの使用を特定できるように拡張することができる。一実施形態において、この拡張フィールドは、ｐａＲｅｑＵＲＬフィールドと称される。このフィールドは、ＰＡＲｅｑを含むフォームの提供先であるプロキシサーバのＵＲＬを特定する。後述されるように、プロキシサーバは、システムファイアウォールによって提供されるセキュリティを維持しつつ、必要なデータ交換を許可するために使用することができる。

次に、ＰＡＲｅｑメッセージに加えられる変更を説明する。ＰＡＲｅｑメッセージは、ＭＰＩがカード所有者の電話番号をＡＣＳに提供できるように拡張することができる。一実施形態では、ＣＨｐｈｏｎｅ拡張フィールドを使用することができる。ＰＡＲｅｑは、また、ＡＣＳからＰＡＲｅｓが受信されなかった場合に、ＭＰＩによって取引の口座認証プロセスの時間切れが認められたときの日付及び時間を示せるように拡張することができる。この日付及び時間は、グリニッジ標準時を使用して特定されることが好ましい。この目的のためには、オプションのｐａＲｅｑＥｘｐ拡張フィールドを使用することができる。

ＡＣＳは、Ｃｈｐｈｏｎｅフィールドのコンテンツを使用することによって、カード所有者との「プッシュ」認証セッションを開始して良い。メッセージングチャネルまたは音声チャネルがショッピングに使用されている場合は、商人は、もし可能ならばこのフィールドを提供することが好ましい。Ｃｈｐｈｏｎｅフィールドは、国別コードを含む全桁の電話番号を含むことが好ましい。電話番号は、スペースまたは他の文字を組み込まれていない数値ストリングの形で含まれることが好ましい。

ＭＰＩが、少なくとも２種類の追加データを提供できるようにするため、ＰＡＲｅｑメッセージのトランスポートに使用されるＨＴＭＬフォームには、新しいフォームフィールドが定められる。第１に、ＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔなどのフィールドは、ＰＡＲｅｓが返されるセッションの間にＭＰＩによって使用されるルートＳＳＬ証明書を提供する。第２に、ＡＣＳＵＲＬなどのフィールドは、ＶＥＲｅｓ．ｕｒｌの値を（もし使用されるならば）プロキシサーバに提供する。また、プロキシサーバが、ＡＣＳからのＰＡＲｅｓメッセージの送信先として好ましい場所を示すＵＲＬを提供できるようにするためには、追加のフォームフィールドすなわちｐａＲｅｓＵＲＬの使用が可能である。

ＭＰＩは、以下の３つのステップにしたがって、ＡＣＳにＰＡＲｅｑメッセージを送信する。第１に、ＭＰＩは、クライアントとして機能することによって、適切なＵＲＬとの間にセキュア（ＨＴＴＰＳ）接続を確立する。ＶＥＲｅｓにｐａＲｅｑＵＲＬ拡張フィールドが含まれる場合は、それを使用することが好ましい。それ以外の場合は、ＶＥＲｅｓ．ｕｒｌから得られたＡＣＳ ＵＲＬが使用される。第２に、ＭＰＩは、ＭＤ、ＴｅｒｍＵｒｌ、及びＰａＲｅｑ（大文字と小文字の違いに留意）のフィールドと、更に、ＶＥＲｅｓ．ｕｒｌのコンテンツを含む追加のＴｅｒｍＵＲＬＲｏｏｔＣｅｒｔフィールド及びＡＣＳ ＵＲＬフィールドと、を含むＨＴＭＬフォームを構成する。第３に、ＭＰＩは、確立された接続を通してそのフォームをＰＯＳＴする。ＰＡＲｅｑを受信したプロキシサーバは、ｐａＲｅｓＵＲＬと称されるフィールドをフォームに追加して良い。ｐａＲｅｓＵＲＬは、ＰＡＲｅｓの返送先として好ましいＵＲＬを含む。次いで、プロキシサーバは、そのフォームを、ＰＡＲｅｑを含んでいたＨＴＭＬフォームから得られたＡＣＳ ＵＲＬを使用してＡＣＳに転送する。

ＡＣＳは、（ＭＰＩから直接に、或いは、プロキシサーバによる転送を経て）ＰＡＲｅｑを受信した際に、適切な認証チャネルを使用して認証を開始する。ＡＣＳは、予め登録された電話番号を使用しても良いし、あるいは、（もしＣＨｐｈｏｎｅ拡張フィールドに含まれる形で提供され尚かつ発行者のリスク管理ポリシーが許す場合は）ＰＡＲｅｑに含まれる形で提供された電話番号を使用しても良い。

音声及びメッセージングの実装形態のセキュリティ問題
このプロトコル拡張は、ＭＰＩが、ＡＣＳとの間に接続を確立し、ＰＡＲｅｑを含むフォームをＰＯＳＴできることを必要とする。しかしながら、ファイアウォールの多くは、このようなアウトバウンド接続の作成能力を制限しており、特別にリストアップされた信頼できる既知のＩＰアドレスへの接続のみを許可している。この制限は、商人システム上の「トロイの木馬」ソフトによって詐欺師のサーバへの接続が開かれて機密データが送信されるのを阻止することを目的としている。

セキュリティ／ファイアウォールの制限に対しては、システムアーキテクチャの２種類の変更形態を利用することができる。第１の変更形態は、ファイアウォールの有する既知の信頼できるＩＰアドレスからなるリストを更新することを含む。第２の変更形態は、信頼できるプロキシサーバを使用することを含む。完全に実装された口座認証システムは、可能性のあるＡＣＳシステムの候補を多数有しており、そのうちのどのＩＰアドレスへの接続が必要になるかを予め知ることはできない。多数のＡＣＳシステムに接続するという要件に対応するためには、１つまたはそれ以上の信頼できるプロキシサーバを確立し、それによってセキュリティ手続きを簡略化すれば良い。ＶＥＲｅｓに含まれる形でＭＰＩに返されたｐａＲｅｑＵＲＬ拡張フィールドは、信頼できるこれらのプロキシサーバの１つを識別する。プロキシサーバによって、ＡＣＳは、商人にＰＡＲｅｓを返送する一方で、これらの商人に戻る接続のみが確立されていることを保証することができる。商人システムは、定義されたこれらのサーバのＩＰアドレスへの接続のみを許可する必要がある。

プロキシサーバが使用される場合は、Ｖｉｓａディレクトリサーバは、プロキシサーバのＵＲＬをＶＥＲｅｓのｐａＲｅｑＵＲＬ拡張フィールドに入れることによって、ＭＰＩからのＰＡＲｅｑがこのプロキシサーバに送信されることを保証する。プロキシサーバは、好ましくは、ＰＡＲｅｓもやはりこのプロキシサーバに提供されることを保証する。（これは、ｐａＲｅｓＵＲＬフォームフィールドを使用して実現できる。）プロキシサーバは、ＰＡＲｅｓを含むフォームが、ＰＡＲｅｑの送信時にＭＰＩによって特定されたＴｅｒｍＵｒｌに提供されるように保証することが好ましい。他の接続は確立されず、他のデータは伝送されないことが好ましい。

図１３及び図１４は、口座認証システムにおける音声チャネル及びメッセージングチャネルを通じた基本的なメッセージ交換を対比して示した図である。図１３は、プロキシサーバを使用しない場合を示し、図１４は、プロキシサーバを使用する場合を示している。図１３及び図１４の各図において、口座認証プロセスは上から下に進むものとして示され、メッセージの伝送は矢印で示されている。大きな相違は、図１４に示されているように、ＰＡＲｅｑ及びＰＡＲｅｓがＡＣＳとＭＰＩとの間で直接伝送されるのではなくプロキシサーバを通じて伝送されるという点にある。

図１５は、双方向メッセージ処理に使用される代表的なアーキテクチャを示している。ＡＣＳは、カード所有者にＳＭＳメッセージまたはＵＳＳＤメッセージを送信することによって、取引に関する情報を提供すると共に、カード所有者パスワードなどの識別情報を要求することが好ましい。ＡＣＳは、また、カード所有者からの応答を受信して、それを一義的に要求に関連付けられることが好ましい。ＡＣＳの開発者は、この能力を開発することを試みても良いし、あるいは、必要な能力及び関連オペレータとの間に関係を有する統合サービスと連携することを試みても良い。

認証に使用されるチャネルの種類によらず、発行者は、自分の身元をカード所有者に明らかにできる必要がある。「従来の」インターネットチャネルでは、発行者は、ブランドロゴ及びカード所有者登録において定義された「個人保証メッセージ」（ＰＡＭ４）など、比較的大量の情報を表示することができた。双方向メッセージングが使用される場合は、やはりＰＡＭを使用して、個人の何らかの身元保証を提供することができる。しかしながら、発行者が使用しているサービス番号（ショートコードとして知られている場合もある）をカード所有者が知るためには、更に賢固な方法が必要である。着信メッセージの発信元を定めているこのサービス番号は、携帯電話会社によって提供される番号であり、改ざんまたは送信偽装が容易でない。

好ましいシステムネットワーク
図１６は、本発明の一実施形態を実装するのに適した通信ネットワーク８００を示している。本発明は、任意の適切な通信ネットワークを使用することが可能であると共に、後述されるものと異なるハードウェア、ソフトウェア、及び／またはプロトコルを伴うことも可能である。後述されるネットワークは、図１の通信ネットワーク１２６の好ましい一実施形態である。ネットワーク８００は、クレジットカード、交通及び接待用の法人用カード、並びに自社ブランドの専用カードなどの任意のカードを使用した購入取引及び現金取引をサポートするグローバル通信ネットワークである。ネットワークは、また、他のネットワークのＡＴＭ取引、小切手を使用した取引、スマートカードを使用した取引、及び他の金融商品を使用した取引もサポートする。

これらの取引は、ネットワークによる与信、交換（クリアリング）、及び決済のサービスを経て処理される。与信は、購入の確定または現金の分散に先立って、発行者が売買取引を承認または否認する段階である。交換は、顧客の口座に提供する目的で、決済者から発行者に取引が送られる段階である。決済は、交換された全ての取引に関し、各メンバの純金融状態を計算及び決定するプロセスである。実際の資金交換は別個のプロセスである。

取引の与信、交換、及び決済は、デュアルメッセージ取引及びシングルメッセージ取引のいずれの形態でも行うことができる。デュアルメッセージ取引では、二度の送信がなされる。すなわち、先ずは与信決定に必要な情報のみを送信し、後ほど交換及び決済のための追加情報を送信しなおす。シングルメッセージ取引では、与信のための送信が一度になされ、それに交換及び決済のための情報も含まれる。与信、交換、及び決済は、オンラインで生じるのが一般的である。

通信ネットワーク８００の主なコンポーネントは、交換センタ８０２、アクセスポイント８０４，８０６、及び処理センタ８０８，８１０である。名宛銀行及び第三者与信エージェントなどの他のエンティティも、アクセスポイントを通じてネットワークに接続可能である。交換センタは、世界のどこにでも設けられるデータ処理センタである。一実施形態では、米国に２箇所、イギリス及び日本に１箇所ずつある。各交換センタは、ネットワーク取引の処理を実施するコンピュータシステムを保管している。交換センタは、ネットワークの通信機能の制御ポイントとして機能し、ＩＢＭ社によるＳＮＡプロトコルに基づいた高速専用回線または衛生接続を備える。交換センタを遠隔エンティティに接続する回線８２０，８２２は、ＩＢＭ社によるＳＮＡ−ＬＵ０通信プロトコルに基づいた専用の高帯域電話回線または衛生接続を使用することが好ましい。メッセージは、これらの回線上をＩＳＯ ８５８３規格の任意の適切な実装形態を使用して送信される。

アクセスポイント８０４，８０６は、一般に、処理センタに設けられた小型のコンピュータシステムであり、処理センタのホストコンピュータと交換センタとをインターフェースで接続する。アクセスポイントは、ホストコンピュータと交換センタとの間におけるメッセージ及びファイルの伝送を促進することによって、取引の与信、交換、及び決済をサポートする。リンク８２６，８２８は、一般に、センタ内に設けられたローカルリンクであり、同センタに好まれる独自のメッセージフォーマットを使用している。

（決済者、発行者、または他のエンティティ内に設けられたなどの）データ処理センタは、商人拠点及びビジネス拠点をサポートする処理システムを保管すると共に、顧客データ及び請求システムを維持する。各処理センタは、１箇所またはそれ以上の交換センタにリンクしていることが好ましい。処理装置は最も近い交換センタに接続されており、もしネットワークに割り込みが生じた場合は、ネットワークは取引を自動的に第２の交換センタに送る。各交換センタは、また、自分以外の他の全ての交換センタにもリンクしている。このリンクは、処理センタが１箇所またはそれ以上の交換センタを通じて通信し合うことを可能にする。また、処理センタは、交換センタを通じて他のプログラムのネットワークにアクセスすることもできる。更に、ネットワークは、全てのリンクが多重バックアップを有することを保証する。ネットワーク上のあるポイントから別のポイントへの接続は、固定リンクではないのが通常である。その代わりに、交換センタが、所定の伝送ごとに最善の経路を選択する。欠陥のあるリンクを避けた再経路指定は自動的に行われる。

図１７は、オンライン取引及びオフライン取引を処理するために交換センタ内に保管されているシステム８４０を示している。デュアルメッセージ取引では、与信システム８４２が与信を行う。与信システム８４２は、オンライン機能及びオフライン機能をサポートしており、そのファイルは、内部システムテーブル、顧客データベース、及び商人セントラルファイルを含む。与信システム８４２のオンライン機能は、デュアルメッセージ与信処理をサポートする。この処理は、経路指定、カード所有者及びカードの検証、代替処理、並びにファイル保守などの他の機能を伴う。オフライン機能は、報告、請求、及びリカバリ掲示の作成を含む。報告は、与信報告、例外ファイル及び助言ファイルの報告、ＰＯＳ報告、並びに請求報告を含む。システム８４２からシステム８４６へのブリッジは、システム８４２の使用メンバが、システム８４６の使用メンバと通信すること及び外部ネットワークへのＳＭＳゲートウェイにアクセスすることを可能にする。

交換・決済システム８４４は、事前に与信されたデュアルメッセージ取引の交換及び決済を行う。交換・決済システム８４４は、グローバルレベルで週６日間作動し、メンバ間において金融情報及び非金融情報の収集及び報告の分散を行う。システムは、また、料金、請求額、及び決済総額の計算並びに報告の作成を行って調整に役立てる。ブリッジは、システム８４４の処理センタとシステム８４６の処理センタとの間に交換を形成する。

シングルメッセージシステム８４６は、純金融取引を処理する。シングルメッセージシステム８４６は、また、デュアルメッセージの与信取引及び交換取引を処理することもでき、ブリッジを使用してシステム８４２と通信し、必要に応じて外部のネットワークにアクセスする。システム８４６は、Ｖｉｓａカード取引、ＰｌｕｓＩｎｔｅｒｌｉｎｋカード取引、及び他のカード取引を処理する。ＳＭＳファイルは、システムのアクセス及び処理を制御する内部システムテーブルと、ＰＩＮの検証及び代替処理の与信に使用されるカード所有者データのファイルを含むカード所有者データベースとを備える。システム８４６のオンライン機能は、与信のためのリアルタイムなカード所有者取引処理及び例外処理はもちろんのこと、純金融取引も実施する。システム８４６は、また、調整及び決済の総額を累算する。システム８４６のオフライン機能は、決済及び資金振替の要求を処理し、決済及び活動の報告を提供する。決済サービス８４８は、インターリンクを含むシステム８４４，８４６の決済機能を、あらゆる商品及びサービスに対応したシングルサービスに統合する。交換は、システム８４４及びシステム８４６によって引き続き個別に実施される。

図１８は、通信ネットワーク８００のコンポーネントを別の観点から示した図である。統合支払システム８５０は、オンラインのあらゆる与信要求取引及び金融要求取引を処理するための基本システムである。統合支払システム８５０は、デュアルメッセージ処理及びシングルメッセージ処理のいずれの報告も行う。いずれの場合も、決済は個別に生じる。３つの主要なソフトウェアコンポーネントは、共通インターフェース機能８５２、与信システム８４２、及びシングルメッセージシステム８４６である。

共通インターフェース機能８５２は、交換センタで受信された各メッセージで必要とされる処理を決定する。共通インターフェース機能８５２は、メッセージの送信元（システム８４２，８４４，または８４６）、処理要求の種類、及び処理ネットワークの種類に基づいて、適切な経路を選択する。このコンポーネントは、初期メッセージの編集を行い、必要の際にはメッセージを解析することによって、メッセージのコンテンツがメッセージ構成の基本ルールを満たすことを保証する。共通インターフェース機能８５２は、メッセージをそれらの宛先へと、すなわちシステム８４２またはシステム８４６へと送る。

コンピュータシステムの実施形態
図１９Ａ及び図１９Ｂは、本発明の実施形態を実装するのに適したコンピュータシステム９００を示している。図１９Ａは、コンピュータシステムが採ることが可能な１つの物理的形態を示している。コンピュータシステムは、もちろん、集積回路、プリント基板、小型のハンドヘルドデバイスから巨大なスーパーコンピュータに至るまで、多数の物理的形態を採ることが可能である。コンピュータシステム９００は、モニタ９０２、ディスプレイ９０４、ハウジング９０６、ディスクドライブ９０８、キーボード９１０、及びマウス９１２を含む。ディスク９１４は、コンピュータシステム９００との間でデータをやり取りするために使用されるコンピュータ読み取り可能媒体である。

図１９Ｂは、コンピュータシステム９００のブロック図の一例である。システムバス９２０には、様々なサブシステムが取り付けられている。プロセッサ９２２（中央演算処理装置、即ちＣＰＵとも称される）は、メモリ９２４を含むストレージデバイスに結合される。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）及び読み取り専用メモリ（ＲＯＭ）を含む。当該分野では周知のように、ＲＯＭは、ＣＰＵに一方向的にデータおよび命令を転送するように機能し、ＲＡＭは、一般に、双方向的にデータおよび命令を転送するために使用される。いずれのタイプのメモリも、後述されるどの適切なコンピュータ読み取り可能媒体を含んでも良い。また、ＣＰＵ９２２には、固定ディスク９２６も双方向的に結合されている。固定ディスク９２６は、追加のデータストレージ容量を提供し、また、後述される任意のコンピュータ読み取り可能媒体を含んで良い。固定ディスク９２６は、プログラムやデータなどの格納に使用されて良く、一般に、一次ストレージよりも低速な二次ストレージ（ハードディスクなど）である。なお、固定ディスク９２６内に保持されている情報は、それにふさわしい場合には、メモリ９２４内の仮想メモリとして標準の方式で組み込むことができる。取り外し可能ディスク９１４は、後述される任意の形態のコンピュータ読み取り可能媒体であって良い。

ＣＰＵ９２２は、また、ディスプレイ９０４、キーボード９１０、マウス９１２、及びスピーカ９３０などの様々な入出力デバイスにも結合される。一般に、入出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロホン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気若しくは紙テープリーダ、タブレット、スタイラス、音声若しくは筆跡レコグナイザ、バイオメトリックリーダ、または他のコンピュータのうち、どのデバイスでも良い。ＣＰＵ９２２は、状況に応じ、ネットワークインターフェース９４０を使用して別のコンピュータまたは通信ネットワークに任意で結合することができる。ＣＰＵは、上述された方法の各ステップを実施する際に、このようなネットワークインターフェースを使用して、ネットワークから情報を受信するか、或いはネットワークに情報を出力すると考えられる。更に、本発明による方法の実施形態は、ＣＰＵ９２２においてのみ実行されても良いし、或いは、処理の一部を共用するリモートＣＰＵとの協同で、インターネットなどのネットワーク上で実行されても良い。

本発明の実施形態は、更に、コンピュータに実装された各種動作を実施するためのコンピュータコードをコンピュータ読み取り可能媒体上に有するコンピュータストレージ製品に関する。このような媒体及びコンピュータコードは、本発明の目的のために特別に設計及び構築されたものでも良いし、或いは、コンピュータソフトウェアの当業者にとって周知の市販のものでも良い。コンピュータ読み取り可能媒体は、例えば、ハードディスク、フロッピィディスク、及び磁気テープなどの磁気媒体、ＣＤ−ＲＯＭ及びホログラフィックデバイスなどの光学媒体、フロプティカルディスクなどの磁気光学媒体、並びに特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、ＲＡＭデバイス、及びＲＯＭデバイスなど、プログラムコードの格納及び実行のために特別に構成されたハードウェアデバイスを含み、これらに限定されない。コンピュータコードとしては、例えば、コンパイラによって生成された機械コード、及びインタープリタの使用によってコンピュータで実行される高水準コードを含むファイルなどの例が挙げられる。

以上では、いくつかの好ましい実施形態に基づいて本発明の説明を行ったが、本発明は、変更形態、置換形態、及び同等形態をその範囲に含む。また、本発明による方法及び装置は、多数の代替方法によって実装することができる。したがって、添付した以下の特許請求の範囲は、このようなあらゆる変更形態、置換形態、及び同等形態を、本発明の真の趣旨及び範囲に含まれるものとして含むと解釈される。

様々な口座認証用途のために本発明による口座認証サービスを実装するためのコアシステムアーキテクチャの一実施形態を示した図である。 支払取引において本発明による認証サービスをサポートするシステムアーキテクチャ１００の一実施形態を図式化した図である。 本発明の一実施形態にしたがって、口座所有者が口座認証システムに登録するプロセスを示した図である。 口座所有者が口座認証システムの登録プロセスの際に情報を入力するために使用できるインターネットウェブページの一実施形態を示した図である。 口座所有者がインターネットに接続されたコンピュータを使用する場合に関し、コア口座認証システム上の認証された支払取引を説明した図である。 カード所有者にパスワードの入力を促す代表的なウィンドウを示した図である。 顧客がインターネットに接続されたコンピュータを使用する場合に関し、支払取引の際に送信される代表的なメッセージをコア口座認証システムに重ねて示した図である。 一実施形態にしたがって、コア口座認証システムアーキテクチャ上で生じる支払取引を口座認証システムアーキテクチャに重ねて別の視点から示した図である。 本発明のモバイルインターネットデバイス実装形態に関し、口座認証プロトコルをシステムアーキテクチャに重ねて示した図である。 一実施形態にしたがって、圧縮版の支払人認証要求メッセージを構成するデータフィールドを示した表である。 一実施形態にしたがって、圧縮版の支払人認証応答メッセージを構成するデータフィールドを示した表である。 音声及びメッセージングデバイスが使用される場合に関し、代表的な支払取引を説明した図である。 プロキシサーバが使用されない場合に関し、口座認証システムにおける音声チャネル及びメッセージングチャネルを使用した基本的なメッセージ交換を対比のために示した図である。 プロキシサーバが使用される場合に関し、口座認証システムにおける音声チャネル及びメッセージングチャネルを使用した基本的なメッセージ交換を対比のために示した図である。 双方向メッセージ処理に使用される代表的なアーキテクチャを示した図である。 本発明の一実施形態を実装するのに適した通信ネットワークを示した図である。 オンライン取引及びオフライン取引を処理するために交換センタ内に保管されたシステムの図である。 通信ネットワークのコンポーネントを別の視点から示した図である。 本発明の実施形態を実装するのに適したコンピュータシステムを示した図である。 本発明の実施形態を実装するのに適したコンピュータシステムを示した図である。

Claims (37)

1. 信用者が、口座所有者のＩＤを、前記口座所有者と要求者との間における取引の際に認証するための方法であって、
   前記取引を行うために、前記要求者と前記口座所有者との間に通信接続を確立する工程と、
   前記信用者において、圧縮版の支払認証応答メッセージを作成する工程と、
   前記圧縮版の支払認証応答メッセージを、前記口座所有者を介して前記要求者に伝送する工程と、
   前記要求者のところに設けられたメモリデバイスから、第１のデータフィールドセットを検索する工程と、
   前記要求者において、前記圧縮版の支払認証応答メッセージを前記第１のデータフィールドセットと組み合わせることによって、完全版の支払認証応答メッセージを構成する工程と、
   前記完全版の支払認証応答メッセージが、前記口座所有者のＩＤが認証されたことを示す場合に、前記口座所有者と前記要求者との間における前記取引を与信する工程と
   を備える方法。
2. 請求項１に記載の方法であって、更に、
   前記要求者において、圧縮版の支払認証要求メッセージを作成する工程と、
   前記圧縮版の支払認証要求メッセージを、前記口座所有者を介して前記要求者から前記信用者に伝送する工程と、
   前記信用者において、前記口座所有者からＩＤ認証トークンを受信する工程と、
   前記ＩＤ認証トークンを、前記口座所有者の口座用に予め指定されたトークンと比較し、前記信用者において、前記口座所有者のＩＤを認証する、工程と
   を備える方法。
3. 先行する請求項のうちの任意の１つに記載の方法であって、
   前記要求者に設けられた前記メモリデバイスは、商人プラグインモジュールである、方法。
4. 請求項２に記載の方法であって、更に、
   前記口座所有者の口座番号を含む登録検証要求メッセージを、前記要求者から前記信用者に伝送する工程と、
   前記口座所有者の口座番号が、前記信用者によって認証可能である口座所有者の登録リストに含まれるか否かを、前記信用者によって決定する工程と、
   前記前記口座番号が前記口座所有者の登録リストに含まれるか否かを示す登録検証応答メッセージを、インターネットを通じて前記信用者から前記要求者に伝送する工程と、
   前記登録検証応答メッセージに、信用者デジタル証明書のチェーンを含む拡張フィールドを含ませる工程と、
   を備える方法。
5. 請求項２に記載の方法であって、
   前記各メッセージは、複数のエレメントで構成されたインターネットメッセージであって、前記各エレメントは、第１のタグサイズを有するエレメント名前タグをそれぞれに有し、
   前記方法は、更に、前記各エレメント名前タグを、第１のタグサイズよりも小さい第２のタグサイズを有する短縮版のエレメント名前タグでそれぞれに置き換える工程を備える方法。
6. 請求項１，請求項２，請求項４及び請求項５のうちの任意の１つに記載の方法であって、更に、
   前記信用者において、前記完全版の支払認証応答メッセージのコピーを作成する工程と、
   アーカイブを目的として、前記完全版の支払認証応答メッセージのコピーを前記信用者から認証履歴サーバに伝送する工程と
   を備える方法。
7. 請求項１，請求項２，請求項４及び請求項５のうちの任意の１つに記載の方法であって、
   前記信用者は金融機関である、方法。
8. 請求項１，請求項２，請求項４及び請求項５のうちの任意の１つに記載の方法であって、
   前記要求者はオンライン商人であり、前記口座所有者の前記口座は前記信用者によって維持され、
   前記方法は、更に、前記要求者と前記口座所有者との間で金融取引を行う工程を備える、方法。
9. 信用者が、口座に関する口座所有者のＩＤを、前記口座所有者と要求者との間における取引の際に認証する口座認証システムであって、
   前記取引を処理するために、前記口座所有者と通信するように構成された要求者サーバと、
   前記信用者によって制御され、圧縮版の支払認証応答メッセージを作成するように構成されたアクセス制御サーバと、
   要求者メモリユニットを有した要求者プラグインソフトウェアモジュールであって、前記圧縮版の支払認証応答メッセージを受信し、前記要求者メモリユニットから第１のデータフィールドセットを検索し、前記圧縮版の支払認証応答メッセージを前記第１のデータフィールドセットと組み合わせることによって完全版の支払認証応答メッセージを構成するように構成された要求者プラグインソフトウェアモジュールと
   を備えるシステム。
10. 請求項９及び請求項１０のうちの任意の１つに記載の口座認証システムであって、
    前記要求者プラグインソフトウェアモジュールは、更に、圧縮版の支払認証要求メッセージを作成して前記アクセス制御サーバに伝送するように構成される、口座認証システム。
11. 請求項１０に記載の口座認証システムであって、
    前記アクセス制御サーバは、更に、前記口座所有者からＩＤ認証トークンを受信し、前記ＩＤ認証トークンに基づいて前記口座所有者のＩＤを認証するように構成される、口座認証システム。
12. 請求項９及び請求項１０のうちの任意の１つに記載の口座認証システムであって、更に、
    前記口座所有者が認証サービスに登録されているか否かを示し、信用者デジタル証明書のチェーンを含む拡張フィールドを含む登録検証応答メッセージを備え、
    前記アクセス制御サーバは、インターネットを通じて前記登録検証応答メッセージを前記要求者プラグインソフトウェアモジュールに伝送するように構成される、口座認証システム。
13. 請求項９及び請求項１０のうちの任意の１つに記載の口座認証システムであって、更に、
    前記アクセス制御サーバから前記完全版の支払認証応答メッセージのコピーを受信するように構成された認証履歴サーバを備える口座認証システム。
14. 請求項９及び請求項１０のうちの任意の１つに記載の口座認証システムであって、
    前記信用者は金融機関であり、前記口座所有者の前記口座を維持する、口座認証システム。
15. 請求項１４に記載の口座認証システムであって、
    前記要求者は、前記口座所有者との間で金融取引を行うオンライン商人である、口座認証システム。
16. 信用者が、口座所有者のＩＤを、前記口座所有者と要求者との間における取引の際に認証する方法であって、
    第１の音声チャネルまたはメッセージングチャネルを通じて、前記口座所有者と前記要求者との間で前記取引を行う工程と、
    支払認証要求メッセージを、インターネットを通じて前記要求者から前記信用者に送信する工程と、
    前記第２の音声チャネルまたはメッセージングチャネルを通じて、前記口座所有者から前記信用者に認証トークンを伝送する工程と
    を備える方法。
17. 請求項１６に記載の方法であって、更に、
    前記認証トークンに基づいて、前記口座所有者のＩＤを認証する工程と、
    支払認証応答メッセージを、インターネットを通じて前記信用者から前記要求者に送信する工程と
    を備える方法。
18. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、
    前記支払認証要求メッセージは、前記要求者から前記信用者に直接送信される、方法。
19. 請求項１８に記載の方法であって、
    前記支払認証要求メッセージを前記要求者から前記信用者に送信する工程は、更に、
    前記支払人認証要求メッセージを含む第１のＨＴＭＬフォームを構成する工程と、
    前記第１のＨＴＭＬフォームを前記信用者に直接提供する工程と
    を備える、方法。
20. 請求項１７に記載の方法であって、
    前記支払認証応答メッセージは、前記信用者から前記要求者に直接送信される、方法。
21. 請求項２０に記載の方法であって、
    前記支払認証応答メッセージを前記信用者から前記要求者に送信する工程は、更に、
    前記支払人認証応答メッセージを含む第２のＨＴＭＬフォームを構成する工程と、
    前記第２のＨＴＭＬフォームを前記要求者に直接提供する工程と
    を備える、方法。
22. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、
    前記支払認証要求メッセージを送信する工程は、
    前記支払認証要求メッセージを前記要求者からプロキシサーバに送信する工程と、
    前記支払認証要求メッセージを前記プロキシサーバから前記アクセス制御サーバに転送する工程と
    を含む、方法。
23. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、
    前記支払認証応答メッセージを送信する工程は、
    前記支払認証応答メッセージを前記信用者からプロキシサーバに送信する工程と、
    前記支払認証応答メッセージを前記プロキシサーバから前記要求者に転送する工程と
    を含む、方法。
24. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、
    前記第１の音声チャネルまたはメッセージングチャネル及び前記第２の音声チャネルまたはメッセージングチャネルは、ショートメッセージサービス、非構造付加サービスデータ、及び音声自動応答からなる群より選択される、方法。
25. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、更に、
    前記信用者が前記口座所有者のＩＤを認証する能力を有するかどうかに関する照会と、前記口座所有者が使用しているデバイスが使用している通信プロトコルに関する情報とを含む登録検証要求メッセージを作成する工程と、
    前記登録検証要求メッセージを前記要求者から前記信用者に伝送する工程と
    を備える方法。
26. 請求項２５に記載の方法であって、更に、
    前記信用者が前記口座所有者のＩＤを認証する能力を有するか否かを示す登録検証応答メッセージを作成する工程と、
    前記登録検証応答メッセージを前記信用者から前記要求者に伝送する工程と
    を備える方法。
27. 請求項１６及び請求項１７のうちの任意の１つに記載の方法であって、更に、
    前記支払認証応答メッセージが前記口座所有者のＩＤの認証に成功した場合に、前記取引のための与信プロセスを開始する工程を備える方法。
28. 信用者が、口座所有者のＩＤを、前記口座所有者と商人との間における取引の際に認証する口座認証システムであって、
    前記取引を処理するために、前記口座所有者と通信するように構成された商人サーバと、
    商人プラグインソフトウェアモジュールと、
    前記支払人認証要求メッセージを含み、インターネットを通じて前記商人プラグインソフトウェアモジュールから前記信用者に提供される第１のＨＴＭＬフォームと、
    前記商人サーバと前記口座所有者との間に確立され、前記取引を行うために使用される第１の音声チャネルまたはメッセージングチャネルと、
    前記信用者によって制御されるアクセス制御サーバと、
    前記口座所有者と前記アクセス制御サーバとの間に確立された第２の音声チャネルまたはメッセージングチャネルと、
    前記第２の音声チャネルまたはメッセージングチャネルを通じて前記口座所有者から前記アクセス制御サーバに伝送され、前記アクセス制御サーバによって前記口座所有者のＩＤの認証に使用されるように構成された認証トークンと
    を備える口座認証システム。
29. 請求項２８に記載の口座認証システムであって、更に、
    前記支払人認証応答メッセージを含み、インターネットを通じて前記商人プラグインソフトウェアモジュールに提供される第２のＨＴＭＬフォームを備える口座認証システム。
30. 請求項２８及び請求項２９のうちの任意の１つに記載の口座認証システムであって、更に、
    前記支払人認証要求メッセージ及び前記支払人認証応答メッセージを、前記商人プラグインソフトウェアモジュールと前記アクセス制御サーバとの間で送るプロキシサーバを備える口座認証システム。
31. 請求項２８及び請求項２９のうちの任意の１つに記載の口座認証システムであって、更に、
    前記アクセス制御サーバと通信する認証履歴サーバと、
    紛争解決を目的として前記認証履歴サーバに送信される前記支払人認証応答メッセージのコピーと
    を備える口座認証システム。
32. 請求項２８及び請求項２９のうちの任意の１つに記載の口座認証システムであって、
    前記第１の音声チャネルまたはメッセージングチャネル及び前記第２の音声チャネルまたはメッセージングチャネルは、ショートメッセージサービス、非構造付加サービスデータ、及び音声自動応答からなる群より選択される、口座認証システム。
33. 請求項２８及び請求項２９のうちの任意の１つに記載の口座認証システムであって、更に、
    前記信用者が前記口座所有者のＩＤを認証する能力を有するかどうかに関する照会と、前記口座所有者が使用しているデバイスが使用している通信プロトコルに関する情報とを含む登録検証要求メッセージを備え、
    前記登録検証要求メッセージは、前記商人プラグインソフトウェアモジュールから前記信用者に伝送される、口座認証システム。
34. 請求項３３に記載の口座認証システムであって、
    前記登録検証要求メッセージは、更に、前記支払人認証要求メッセージが前記アクセス制御サーバに、インターネットを通じて直接送信されるか或いは前記口座所有者が使用している前記デバイスを介して送信されるかを示す拡張フィールドを含む、口座認証システム。
35. 請求項３３に記載の口座認証システムであって、
    前記登録検証要求メッセージは、更に、前記口座所有者の電話番号のハッシュを含み、前記アクセス制御サーバは、前記口座所有者のＩＤが認証可能であるか否かを決定するために前記ハッシュを使用する、口座認証システム。
36. 請求項２８及び請求項２９のうちの任意の１つに記載の口座認証システムであって、更に、
    前記信用者が前記口座所有者のＩＤを認証する能力を有するか否かを示し、前記信用者から前記商人プラグインソフトウェアモジュールに伝送される登録検証応答メッセージを備える口座認証システム。
37. 請求項３０に記載の口座認証システムであって、更に、
    前記信用者が前記口座所有者のＩＤを認証する能力を有するか否かを示し、前記信用者から前記商人プラグインソフトウェアモジュールに伝送され、前記プロキシサーバのＵＲＬを特定する拡張フィールドを含む登録検証応答メッセージを備える口座認証システム。

Images