(57)【特許請求の範囲】
【請求項１】
第三者とのオンライントランザクションの最中にアカウントを使用している顧客が前記アカウントの実際の所有者であることを、アカウントの発行者が、前記顧客との前記オンライントランザクションに進む前に前記顧客の同一性に関する検証を所望する前記第三者の利益のために認証する方法であって、
登録プロセス中に前記発行者のアクセス制御サーバ及び登録サーバが、前記顧客の同一性を前記アカウントの所有者として検証し、指定されたパスワードを前記アカウントと関連付ける第１の検証動作と、
前記オンライントランザクション中に、前記第三者のコンピュータシステムから、前記顧客の同一性の認証を要求する認証要求メッセージであって、前記オンライントランザクションで必要とされる支払いの詳細と前記顧客のアカウントとを含む認証要求メッセージを、前記発行者によって運営されているアクセス制御サーバが受信する動作と、
前記オンライントランザクション中にネットワーク上で、前記発行者のアクセス制御サーバが、前記顧客に同一性認証パスワードを要求する動作と、
前記顧客からの前記同一性認証パスワードが、前記アカウントのために事前に指定された前記パスワードと一致することを、前記発行者のアクセス制御サーバが検証する第２の検証動作と、
前記顧客によって入力された前記同一性認証パスワードが、前記アカウントのために事前に指定された前記パスワードと一致する場合に、前記顧客が前記アカウントの実際の所有者であることを、前記発行者のアクセス制御サーバが前記第三者のコンピュータシステムに通知し、これによって、前記発行者のアクセス制御サーバが、前記オンライントランザクション中に、前記第三者のために前記顧客を認証する動作と、
前記発行者が、前記顧客が前記アカウントの実際の所有者であることを前記第三者のコンピュータシステムに通知した後に、支払いシステムから前記オンライントランザクションに関連する支払い要求を受け取り、前記支払いシステムに対して前記支払い要求への応答を通知する動作と、
を備える方法。
【請求項２】
請求項１に記載の方法であって、
前記発行者は発行側金融機関であり、前記第三者はオンラインマーチャントであり、したがって、前記オンラインマーチャントは前記顧客を相手に金融トランザクションを実行し、前記顧客の前記アカウントは前記発行側金融機関によって維持される、方法。
【請求項３】
請求項１に記載の方法であって、さらに、
前記受信動作の前に、前記顧客のアカウントが認証サービスに登録されているか否かを決定するために、アクセス制御サーバに照会する動作を備える方法。
【請求項４】
請求項３に記載の方法であって、
前記アクセス制御サーバは、前記顧客のアカウントが、登録済み顧客アカウントのデータベースに含まれていることを検証することによって、前記顧客アカウントが登録されているか否かを決定する、方法。
【請求項５】
請求項３に記載の方法であって、さらに、
前記支払認証サービスに参加している発行側金融機関に前記顧客アカウントが関連付けられていることを検証するために、ディレクトリサーバに照会する動作を備え、
前記顧客アカウントが発行側金融機関に関連付けられていない場合は、前記顧客アカウントは前記支払認証サービスに登録されていないこととなる、方法。
【請求項６】
請求項５に記載の方法であって、さらに、
前記アクセス制御サーバのためのインターネットアドレスを、前記第三者のコンピュータシステムに送信する動作であって、前記インターネットアドレスは、前記第三者のコンピュータシステムに到達する前に前記ディレクトリサーバを通過する動作を備え、
前記アクセス制御サーバのための前記インターネットアドレスは、前記第三者のコンピュータシステムが前記アクセス制御サーバと直接通信することを可能にするものである、方法。
【請求項７】
請求項３に記載の方法であって、さらに、
前記認証サービスに参加している発行側金融機関に前記顧客アカウントが関連付けられていることを検証するために、前記第三者のコンピュータシステムによって制御されているメモリデバイスを調査する動作を備え、
前記顧客アカウントが発行側金融機関に関連付けられていない場合は、前記顧客アカウントは前記認証サービスに登録されていないこととなる、方法。
【請求項８】
請求項１に記載の方法であって、さらに、
前記発行者の署名キーを使用し、デジタル署名済みのトランザクション受領証を前記発行者のアクセス制御サーバが生成する動作と、
デジタル署名済みのトランザクション受領証を、前記発行者のアクセス制御サーバが前記第三者のコンピュータシステムに送信する動作と、
を備え、
前記デジタル署名済みのトランザクション受領証は、前記顧客の同一性が認証済みであることを前記第三者のコンピュータシステムに対して裏付けるものである、方法。
【請求項９】
請求項８に記載の方法であって、
前記トランザクション受領証は、前記顧客のアカウントに関連付けられた番号と、トランザクションの支払額と、トランザクションの支払日とを含む、方法。
【請求項１０】
請求項１に記載の方法であって、さらに、
前記顧客アカウントおよび特定のトランザクションに固有な値を含むカード認証検証値を、前記発行者のアクセス制御サーバが前記第三者のコンピュータシステムに送信する動作を備え、
前記カード認証検証値は、特定の認証済みトランザクションを固有に識別するものである、方法。
【請求項１１】
請求項８に記載の方法であって、さらに、
前記デジタル署名済みのトランザクション受領証を、前記第三者のコンピュータシステムによって検証することによって、前記トランザクション受領証が特定の発行者から送信されたことを、前記第三者に対して保証する動作を備える方法。
【請求項１２】
請求項１に記載の方法であって、さらに、
前記顧客アカウントが、要求された購入に対して十分なクレジットを有することを検証するために、前記第三者のコンピュータシステムによって許可メッセージを発行側金融機関に送信する動作を備える方法。
【請求項１３】
請求項１に記載の方法であって、前記第１の検証動作は、さらに、
前記顧客によって登録インターネットウェブサイトに入力された登録情報を、前記発行者の登録サーバが受信する動作と、
前記登録情報が、既存の顧客情報データベースに含まれる情報と実質的に一致することを、前記発行者の登録サーバが検証する動作と、
前記発行者のアクセス制御サーバが、前記顧客アカウント情報を、登録済み顧客アカウントのデータベースに格納する動作と、
を備える方法。
【請求項１４】
第三者とのオンライントランザクションの最中にアカウントを使用している顧客が前記アカウントの実際の所有者であることを、アカウントの発行者が前記第三者の利益のために認証する認証サービスにおいて実施される方法であって、
登録プロセス中に前記発行者のアクセス制御サーバ及び登録サーバが、前記顧客の同一性を前記アカウントの所有者として検証し、指定されたパスワードを前記アカウントと関連付ける動作と、
前記オンライントランザクション中にネットワーク上で、第三者のソフトウェアモジュールが顧客のコンピュータを介して、前記オンライントランザクションで必要とされる支払いの詳細と前記顧客のアカウントとを含む認証要求メッセージを送信する動作と、
前記発行者のアクセス制御サーバが、前記認証要求メッセージを受信する動作と、
前記ネットワーク上で、前記発行者のアクセス制御サーバが、前記顧客にパスワードを要求する動作と、
前記顧客によって入力された前記パスワードが前記アカウントのために事前に指定された前記パスワードと一致することを、前記発行者のアクセス制御サーバが検証する動作と、
前記ネットワーク上で、認証状況の標識を含んだ認証応答メッセージを、前記発行者のアクセス制御サーバが第三者のソフトウェアモジュールに送信し、これによって、前記発行者のアクセス制御サーバが、前記第三者のために前記顧客を認証する動作と、
前記発行者が、前記顧客が前記アカウントの実際の所有者であることを前記第三者のコンピュータシステムに通知した後に、支払いシステムから前記オンライントランザクションに関連する支払い要求を受け取り、前記支払いシステムに対して前記支払い要求への応答を通知する動作と、
を備える方法。
【請求項１５】
アカウントの発行者のコンピュータが第三者の利益のために顧客を認証する認証サービスにおいて実施される方法であって、
登録プロセス中に前記発行者のコンピュータが、前記顧客の同一性を前記アカウントの所有者として検証し、指定されたパスワードを前記アカウントと関連付ける動作と、
ネットワーク上で、顧客のコンピュータから要求を受信して、前記第三者のコンピュータシステムがオンライン金融トランザクションを実行する動作と、
前記発行者のコンピュータが、前記顧客が前記認証サービスに登録されていることを決定する動作と、
前記金融トランザクション中に前記ネットワーク上で、前記第三者のコンピュータシステムが前記顧客のコンピュータを介して、前記発行者のコンピュータに向けた認証要求メッセージであって、前記オンライントランザクションで必要とされる支払いの詳細と前記顧客のアカウントとを含む認証要求メッセージを送信する動作と、
前記金融トランザクション中に、前記第三者のコンピュータシステムが、前記顧客のコンピュータを介して前記発行者の前記コンピュータから前記顧客の真正性を示す認証応答メッセージを受信する動作であって、前記真正性は、前記金融トランザクション中に前記顧客によって前記発行者の前記コンピュータに提供されたパスワードと、前記アカウントのために事前に指定されたパスワードとに基づいて決定され、これによって、前記発行者のコンピュータが、前記第三者のために前記顧客を認証する動作と、
前記発行者のコンピュータが、前記顧客が前記アカウントの実際の所有者であることを前記第三者のコンピュータシステムに通知した後に、支払いシステムから前記金融トランザクションに関連する支払い要求を受け取り、前記支払いシステムに対して前記支払い要求への応答を通知する動作と、
を備える方法。
【請求項１６】
請求項１に記載の方法であって、前記オンライントランザクションは、支払トランザクションである、方法。
【請求項１７】
請求項１４に記載の方法であって、前記オンライントランザクションは、支払トランザクションである、方法。
【請求項１８】
請求項１５に記載の方法であって、前記金融トランザクションは、支払トランザクションである、方法。
【請求項１９】
請求項１４に記載の方法であって、
前記認証サービスは、集中型アーキテクチャを利用し、
前記第三者のソフトウェアモジュールは、前記顧客のコンピュータのブラウザを用いて前記認証要求メッセージを前記アクセス制御サーバに送信する、方法。
【請求項２０】
請求項１４に記載の方法であって、
前記認証サービスは、分散型アーキテクチャを利用し、
前記第三者のソフトウェアモジュールは、前記認証要求メッセージを前記顧客のコンピュータのソフトウェアモジュールに送信し、
その後、前記顧客のコンピュータは、前記認証要求メッセージを前記アクセス制御サーバに送信する、方法。
【請求項２１】
請求項１５に記載の方法であって、
前記認証サービスは、集中型アーキテクチャを利用し、
前記第三者のコンピュータシステムは、前記顧客のコンピュータのブラウザを用いて前記認証要求メッセージを前記発行者のコンピュータに送信する、方法。
【請求項２２】
請求項１５に記載の方法であって、
前記認証サービスは、分散型のアーキテクチャを利用し、
前記第三者のコンピュータシステムは、前記認証要求メッセージを前記顧客のコンピュータのソフトウェアモジュールに送信し、
その後、前記顧客のコンピュータは、前記認証要求メッセージを前記発行者のコンピュータに送信する、方法。
【請求項２３】
請求項１に記載の方法であって、さらに、
前記顧客のコンピュータのインターネットブラウザが、前記第三者のコンピュータシステムから前記発行者のアクセス制御サーバへ、前記認証要求メッセージをルーティングする動作と、
前記顧客の前記コンピュータの前記インターネットブラウザが、前記発行者のアクセス制御サーバから前記第三者のコンピュータシステムへ、前記通知をルーティングする動作と、
を備える、方法。
【請求項２４】
請求項１に記載の方法であって、さらに、
前記顧客のコンピュータのインターネットブラウザが、前記第三者のウェブサイトにアクセスする動作と、
前記第三者のコンピュータシステムが、前記ウェブサイトから前記発行者のアクセス制御サーバへ、前記コンピュータの前記インターネットブラウザをリダイレクトすることにより、前記発行者のアクセス制御サーバが、前記同一性認証パスワードを受信する動作と、
前記アクセス制御サーバが、前記アクセス制御サーバから前記第三者の前記ウェブサイトへ、前記コンピュータの前記インターネットブラウザをリダイレクトして戻す動作と、
を備える、方法。
【請求項２５】
請求項１に記載の方法であって、さらに、
前記認証方法に関わる前記顧客のコンピュータがさらなるソフトウェアを用いることなく、前記要求動作を実行する動作を備える、方法。
【請求項２６】
請求項１に記載の方法であって、さらに、
前記アクセス制御サーバが、前記登録プロセス中に、前記顧客に関する認証情報を受信する動作を備える、方法。
【請求項２７】
請求項２６に記載の方法であって、
前記アクセス制御サーバが、前記登録プロセス中に前記発行者から、前記顧客の前記認証情報と前記指定されたパスワードとを受信し、
それにより、前記顧客は、形式的な登録プロセスを経る必要がない、方法。
【請求項２８】
請求項２６に記載の方法であって、前記アクセス制御サーバが、前記登録プロセス中に前記顧客から、前記顧客の前記認証情報と前記指定されたパスワードとを受信し、
それにより、前記登録プロセスは、形式的な登録プロセスとなる、方法。
【請求項２９】
第三者とのオンライントランザクションの最中にアカウントを使用している顧客が前記アカウントの実際の所有者であることを、発行側金融機関が第三者の利益のために認証する認証サービスで利用される顧客のコンピュータによって実施される方法であって、
前記発行側金融機関のアクセス制御サーバが前記顧客の同一性を前記アカウントの所有者として検証するために、登録プロセス中に前記顧客のコンピュータが、登録情報を登録ウェブサイトに送信する動作と、
前記顧客のコンピュータが、前記登録プロセス中に前記アカウントに対して指定されるパスワードを提供する動作と、
前記顧客の同一性が認証される認証サービスの開始を要求する認証要求メッセージであって、前記オンライントランザクションで必要とされる支払いの詳細と前記顧客のアカウントとを含む認証要求メッセージを、前記オンライントランザクション中に前記顧客のコンピュータが前記第三者のコンピュータシステムから受信する動作と、
前記認証要求メッセージを、前記顧客のコンピュータが前記発行側金融機関のアクセス制御サーバに送信する動作と、
前記オンライントランザクション中に、前記顧客の同一性を検証するために使用されるパスワードを前記顧客に入力させる要求を、前記アクセス制御サーバから前記顧客のコンピュータが受信する動作と、
前記顧客のコンピュータが、同一性を検証するために使用される前記パスワードを提供する動作と、
前記顧客の同一性の前記検証に関して、前記顧客のコンピュータが、前記第三者のために前記顧客の同一性を検証した前記アクセス制御サーバから受信した認証応答メッセージを前記第三者のコンピュータシステムに送信する動作と、
を備える、方法。
【請求項３０】
請求項１５，１８，２１，２２のいずれか一項に記載の方法であって、
前記発行者は、通信ネットワークオペレータである、方法。
【請求項３１】
第三者とのオンライントランザクションの最中にアカウントを使用している顧客が前記アカウントの実際の所有者であることを、通信ネットワークオペレータが第三者の利益のために認証する認証サービスで利用される顧客のコンピュータによって実施される方法であって、
前記通信ネットワークオペレータのアクセス制御サーバが前記顧客の同一性を前記アカウントの所有者として検証するために、登録プロセス中に前記顧客のコンピュータが、登録情報を登録ウェブサイトに送信する動作と、
前記通信ネットワークオペレータのアクセス制御サーバが、前記登録プロセス中に前記アカウントに対して指定されるパスワードを提供する動作と、
前記顧客の同一性が認証される認証サービスの開始を要求する認証要求メッセージであって、前記オンライントランザクションで必要とされる支払いの詳細と前記顧客のアカウントとを含む認証要求メッセージを、前記オンライントランザクション中に前記通信ネットワークオペレータのアクセス制御サーバが前記第三者のコンピュータシステムから受信する動作と、
前記認証要求メッセージを、前記顧客のコンピュータが前記通信ネットワークオペレータのアクセス制御サーバに送信する動作と、
前記オンライントランザクション中に、前記顧客の同一性を検証するために使用されるパスワードを前記顧客に入力させる要求を、前記アクセス制御サーバから前記顧客のコンピュータが受信する動作と、
前記顧客のコンピュータが、同一性を検証するために使用される前記パスワードを提供する動作と、
前記顧客の同一性の前記検証に関して、前記通信ネットワークオペレータのアクセス制御サーバが、前記アクセス制御サーバから前記顧客のコンピュータを介して前記第三者のコンピュータシステムに送られる認証応答メッセージの送信を行う動作と、
を備え、
これによって、前記アクセス制御サーバは、前記第三者のために前記顧客の同一性を検証する、方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、金融トランザクションに関し、特に、オンライントランザクションの最中に支払人のＩＤを認証することに関する。
【０００２】
【従来の技術】
支払いカード（例えばクレジットカード、デビットカード、またはポイントカード）を使用した支払トランザクションの最中は、無許可使用などの様々な問題を回避するために、カード所有者のアカウント所有権を検証することが重要である。支払人の認証は、カード所有者のアカウント所有権を検証するプロセスである。カード所有者のアカウント所有権を認証する最も一般的な方法は、いわゆる「有カード」トランザクションの最中に、ＰＯＳ（Ｐｏｉｎｔ  ｏｆ  Ｓａｌｅ：販売時点管理）において日常的に生じる。有カードトランザクションは、アカウントの状況とクレジットラインの利用可能性とを検証するために、マーチャント（商店主）の代行者がカード所有者のカードを支払カード端末に通すことと、次いで、カードの裏面のサインが購入者のサインと一致するか否かをチェックすることを含む。マーチャントは、特別なガイドラインにしたがってこのタイプのトランザクションを実施すれば、割引および手数料無しで指定金額の支払いを保証される。これらの特別なガイドラインは、Ｖｉｓａインターナショナルサービスオーガニゼーション（すなわちサービス組織）などのサービスプロバイダによって提供して良い。
【０００３】
反対に、オンラインで、メールを通して、または電話を通して生じる「無カード」トランザクションの支払いは、マーチャントに対して保証されていない。無保証である主な原因は、このような非対面式のトランザクションが支払人を認証しないためであり、このため、多くのリスクが「無カード」トランザクションにともなう。このようなリスクとしては、オンラインマーチャントに対する支払トランザクションの入金取り消しや、マーチャントおよびカード所有者の両方に対する詐欺行為、銀行の例外項目処理費用の増大、そしてオンラインでの商品およびサービスの購入が安全性および信頼性に欠けるという認識の増大（したがって消費者がオンラインでの購入を控えるようになる）が含まれている。リスクの具体例としては、オンラインで商品およびサービスを購入する目的で、盗まれたアカウント情報を無許可で使用すること、不正なオンライン購入を行う目的で、カードのアカウント番号を作成すること、そしてネットワークトラフィックからクリアテキストのアカウント情報を抽出することが含まれている。
【０００４】
電子商取引は、今後も急成長を続けると予想されるので、支払人を認証する方法を用意することは重要である。これは、カード所有者、マーチャント、および金融機関を含む決済システムの全参加者にとって有益である。オンライン購入トランザクションの最中に支払人を認証することによって、詐欺、紛争、回収、および入金取り消しのレベルが低減され、ひいてはこれらの各事件に関連して生じる費用も低減する。支払人の認証は、また、消費者が抱くセキュリティ上の懸念にも対処でき、これは、オンライン上の売上げ増大に繋がる。オンライントランザクションの最中に消費者を認証するために使用されてきた従来のシステムは、使用が困難である、デザインが複雑である、システム参加者から相当の先行投資を必要とする、そして相互運用性に欠けるなどの理由から、広く取り入れられてこなかった。特定の従来のシステムは、さらに、マーチャント、カード所有者、発行側、および決済側で、証明書を作成し、配布し、使用する必要があった。このような証明書の使用は、極めて煩わしいことが知られている。
【０００５】
以上から、オンライントランザクションにおいて、支払人の同一性（ＩＤ）を認証するためのシステムが望まれていることがわかる。このような認証システムは、構築および使用が比較的容易であり、必要なリソース投資が最小限に抑えられ、さらに、システムの参加者間にハイレベルの相互運用性を提供することが望ましい。
【０００６】
【発明の概要】
本発明は、オンライントランザクションの最中に支払人のＩＤを認証するためのオンラインサービスに関する。本発明は、構築および使用が比較的容易であり、構築に必要なリソース投資が最小限に抑えられ、さらに、システムの参加者間にハイレベルの相互運用性を提供する。本発明による認証サービスは、カードの発行側が、パスワードの使用などの様々な認証方法を使用してカード所有者のＩＤを検証することを可能にする。また、システム参加者のうち、証明書を必要とするのは、発行側である金融機関のみである。認証サービスは、また、チェックアウトプロセスの最中に認証結果をリアルタイムでマーチャントに供給することもできる。
【０００７】
本発明の第１の実施形態は、クレジットカード、デビットカード、ＩＤカードなどの従来のカードを使用することに関する。第１の実施形態の一態様は、オンライントランザクションの最中にカード所有者のＩＤを認証するための方法に関する。この方法は、カード所有者が支払認証サービスに登録されているか否かを決定するために、マーチャントがカード発行側の管理下にあるアクセス制御サーバに照会することと、カード所有者にパスワードを要求することと、そのパスワードを検証することと、カード所有者によって入力されたパスワードが認証された場合にそのカード所有者の真正性をマーチャントに通知することとを含む。
【０００８】
本発明の第２の実施形態は、集積回路カード（スマートカードまたはチップカードとしても知られている）を使用することに関する。第２の実施形態の一態様は、チップカードを利用しているカード所有者のＩＤを認証するための方法に関する。この方法は、カード所有者クライアントデバイスがチップカードリーダを含むことを検証することと、次いで、チップカードをチップカードリーダに入れるようにカード所有者に指示することとを含む。チップカードリーダがチップカードを受け取った後、チップカードは暗号文を生成し、この暗号文は次いでアクセス制御サーバに送信される。アクセス制御サーバは、次いで、チップカード内の情報に基づいて第２の暗号文を独立して生成し、チップカード暗号文を第２の暗号文と比較する。独立して生成されたこれら２つの暗号文が一致する場合は、このカードの真正性が確認される。
【０００９】
本発明によるサービスは、多くの利点をもたらす。例えば、認証サービスは、「無カード」トランザクションに携わるマーチャントに支払保証を確立するための土台となるものである。また、認証サービスは、入金取り消し、詐欺行為、および例外項目処理を減少させる。本発明にともなうこれらおよびその他の特徴および利点が、以下で行う詳細な説明および本発明の原理を例示した添付の図面において、さらに詳細に説明される。
【００１０】
【発明の実施の形態】
次に、添付図面に例示された幾つかの好ましい実施形態に関連させて、本発明の詳しい説明を行う。以下の説明では、本発明が完全に理解されるように多くの項目を特定している。しかしながら、当業者には明らかなように、本発明は、これらの項目の一部または全てを特定しなくても実施することが可能である。そのほか、本発明が不必要に不明瞭となるのを避けるため、周知の動作の説明は省略した。
【００１１】
先ず、支払人認証サービス（ＰＡＳ）によって使用される認証プロセスの概略が説明される。認証プロセス、ならびにシステムセットアップ、顧客登録、および特定のメッセージフローなどの他のプロセスは、本明細書のなかで後ほど詳細に説明される。前述したように、ＰＡＳは、オンライン購入トランザクションの最中にカード所有者のアカウント所有権を認証するように設計されている。ＰＡＳは、例えば、カード所有者がオンラインショッピングする場合に、ショッピングカートにアイテムを追加し、オンラインマーチャントのチェックアウトページに進み、オンラインマーチャントのチェックアウトフォームに記入するために使用される。ＰＡＳは、また、信頼のおける機関が個人または主体のＩＤを第三者の利益ために認証する場合に、様々なトランザクションにおいて使用することもできる。周知のように、信頼のおける機関は、一般に、第三者のために個人または主体を認証する法的責任を負っている。例えば、ＰＡＳは、金融機関の顧客がインターネットウェブサイトにアクセスしてオンラインフォームに記入する際に、その顧客を認証するために使用することができる。ＰＡＳは、また、卸売銀行業務、医療業務、保険業務、仲介業務などはもちろん、デビットカード、購入カード、ポイントカードなどの小売銀行業務の態様にも使用することができる。また、ＩＤカードも、ＰＡＳとともに使用することができる。例えば、ＡＡＡが顧客のＩＤを認証するためにＰＡＳを使用しても良いし、またはテレフォンカード会社が特定のカードのユーザのＩＤを認証するためにＰＡＳを使用することもできる。
【００１２】
ＰＡＳは、例えば「購入」ボタンをクリックした後など、消費者が所望の製品またはサービスを購入することを決定した後に、認証プロセスを実施することができる。ＰＡＳは、また、「購入」ボタンをクリックした後だけでなく、消費者の購入トランザクションの様々な時点で認証プロセスを開始することができる。ほどんどの認証プロセスは、決済ネットワークの複数のポイントに組み込まれたソフトを利用することによって、消費者に対して透過性のモードで実施される。ＰＡＳは、カード所有者およびカード所有者の金融機関による参加の妥当性を検査し、次いで、事前に登録されたパスワードをカード所有者に要求することによって消費者がそのＩＤを確認することができるウィンドウを作成する。消費者のＩＤが確認された場合は、支払情報および消費者認証の通知がマーチャントに送り返される。次いで、これまでにも行われているように、支払トランザクションがマーチャントによって処理される。例えば、マーチャントは、オーダの確認メッセージをカード所有者のブラウザに送信して良い。
【００１３】
ハイレベルシステムの概要：
図１は、ＰＡＳをサポートすることができるインフラアーキテクチャ１００の一実施形態の概略を示している。このアーキテクチャは、発行側ドメイン１０２と、相互運用性ドメイン１０４と、決済側ドメイン１０６との３つのドメインに分割される。発行側ドメイン１０２は、発行側によって主に制御されるコンポーネントを含む。発行側は、例えば、消費者に支払カードを発行する金融機関であって良い。具体的に言うと、発行側すなわちカードの発行会社は、カード業者から受け取った新しいカードをパーソナライズ（個人情報設定）し、これらのカードを顧客に発行する。パーソナライゼーションは、カード業者またはパーソナライゼーション事務所によって実施されても良い。発行側は、金融機関だけでなく、通信ネットワークオペレータ、サービス団体、マーチャントもしくは他の組織、またはひいては発行側のために働く代理業者など、任意の適切な発行主体であって良い。決済側ドメイン１０６は、決済側によって主に制御されるコンポーネントを含む。決済側は、例えば、支払スキームにマーチャントを登録してマーチャントのアカウントを管理する金融機関であって良い。決済側は、また、オンラインマーチャントから通信ネットワークへの情報のルーティングも行う。相互運用性ドメイン１０４は、インターネットによってサポートされており、尚且つ発行側と決済側の両方によって使用されるコンポーネントを含む。相互運用性ドメイン１０４は、Ｖｉｓａなどのカードスキームマネージャによって通常的に管理される。相互運用性ドメイン１０４は、また、インターネット以外のネットワークによってサポートすることもできる。
【００１４】
発行側ドメイン１０２は、登録サイト１０８と、発行側カード所有者システム１１０と、カード所有者クライアントデバイス１２２と、登録サーバ１１２と、アクセス制御サーバ１１４と、発行側または第三者ＩＤ認証コンポーネント１１６と、アカウント所有者ファイル１１８とを含む。発行側ドメイン１０２は、認証済みカード所有者１２０の発行側ファイルを随意的に含むことができる。登録サーバ１１２は、カード所有者に答えさせ発行側に検証させる一連の質問をウェブインターフェースを介して表示することによって、ＰＡＳサービスへのカード所有者の登録を管理するコンピュータである。図１に示すように、カードの発行側は、登録サーバ１１２を運営している。しかしながら、発行側に代わってＶｉｓａなどのサービス組織が登録サーバ１１２を運営しても良い。発行側は、カード所有者のＩＤの妥当性を検査するのに役立てるために、登録プロセスの最中に第三者によって用意されるウェブ対応の対話式「ＩＤ認証サービス」を使用して良い。登録サーバ１１２は、インターネットを介してインターネット支払ゲートウェイサービス１２４に接続され、インターネット支払ゲートウェイサービス１２４は、ＶｉｓａＮｅｔなどの通信ネットワーク１２６に接続される。インターネット支払ゲートウェイサービス１２４は、登録サーバ１１２が通信ネットワーク１２６と通信することを可能にする。支払ゲートウェイサービス１２４を介した接続は、登録しようとしているカード所有者がアクティブカードアカウントを有するか否かを決定するために、登録サーバ１１２が発行側の認証システム１２７に照会することを可能にする。登録サイト１０８は、カード所有者がＰＡＳへの参加登録をすることができるインターネットウェブサイトである。
【００１５】
アクセス制御サーバ（ＡＣＳ）１１４は、ＰＡＳに登録されたカード所有者に関するデータベースを有したコンピュータであり、カード所有者アカウントとパスワード情報とを含む。オンラインの支払トランザクションの最中に、アクセス制御サーバ１１４は、デジタル署名された受領証をマーチャントに提供し、ＰＡＳへのアクセスを制御し、サービスへのカード所有者の参加の妥当性を検査する。発行側に代わってＶｉｓａなどのカード発行側すなわちサービス組織がアクセス制御サーバ１１４を運営しても良い。ＰＡＳは、追加のカード所有者ソフトを何ら必要としないが、随意的にカード所有者ソフトおよびハードを装備しても良い。カード所有者ソフトは、デジタル証明書、集積回路カード（チップカード）、およびチップカードリーダなどの追加の認証技術をサポートするために使用しても良いし、または、ＡＣＳが適切なカード所有者クライアントデバイスに適切に関連付けられていることを検証するために使用しても良い。アカウント所有者ファイル１１８は、ＰＡＳへの登録に成功したカード所有者に関する情報を格納するための、発行側によって管理されるデータベースである。
【００１６】
カード所有者クライアントデバイス１２２は、ＰＡＳに参加するためにカード所有者によって使用される。具体的に言うと、カード所有者クライアントデバイス１２２は、パソコン、携帯電話、携帯情報端末、または対話式ケーブルテレビなどの、インターネットにアクセスすることができる任意のデバイスであって良い。
【００１７】
発行側カード所有者システム１１０は、カード所有者に関する情報を含み、発行側によって制御されるシステムである。このシステム情報は、アカウント情報やカード所有者によって利用されるサービスなどに関する情報を含む。発行側カード所有者システムに含まれる情報のなかには、カード所有者をＰＡＳに登録するプロセスにおいて使用できるものもある。
【００１８】
発行側または第三者ＩＤ認証データベース１１６は、カード所有者に関して発行側または第三者が既に登録している情報を含む。データベース１１６は、カード所有者を登録するプロセスにおいて、カード所有者のＩＤを検証する目的で発行側によって使用される。例えば、カード所有者がＰＡＳへの登録に成功するためには、ＰＡＳ登録プロセスの最中にカード所有者によって入力される情報が、認証データベース１１６内のファイル上に既に存在する情報と一致しなければならない。第三者は、Ｅｑｕｉｆａｘなどの企業であって良い。
【００１９】
相互運用性ドメイン１０４は、ディレクトリサーバ１２８と、受領証ファイル１３０と、受領証マネージャ１３１とを含む。ディレクトリサーバ１２８は、マーチャントからの認証要求を特定のアクセス制御サーバへとルーティングする。ディレクトリサーバ１２８は、Ｖｉｓａなどのサービス組織によって運営される。受領証ファイル１３０および受領証マネージャ１３１は、認証済みの各購入トランザクションに関して署名付きの受領証を格納している。受領証ファイル１３０は、どのトランザクションが認証されたかを検証する情報を含み、紛争解決プロセスの最中に追加の情報を供給する。受領証ファイル１３０および受領証マネージャ１３１は、サービス組織によって運営される。デジタル署名済みの受領証は、発行側、決済側、またはマーチャントがそのコピーを保持していても良い。
【００２０】
決済側ドメイン１０６は、マーチャント１３２と資格検査サーバ１３６とを含む。マーチャントプラグインソフトモジュール１３４は、マーチャント１３２の位置にある。マーチャントプラグインソフトモジュール１３４は、マーチャントのｅコマースウェブサイトに組み込まれたＰＡＳソフトモジュールである。プラグインソフトモジュール１３４は、ＰＡＳとマーチャントの支払処理ソフトとの間にインターフェースを提供する。資格検査サーバ１３６は、カード発行側のデジタル署名を検証するものであり、このデジタル署名は、支払トランザクションの最中にＰＡＳからマーチャントに戻される受領証に署名するために使用される。本発明の代替の実施形態では、資格検査サーバ１３６の機能をマーチャントプラグインソフトモジュール１３４の中に含ませることによって、資格検査サーバ１３６を別途設ける必要性を排除して良い。資格検査サーバ１３６は、マーチャント、決済側、またはサービス組織によって運営される。
【００２１】
ＰＡＳのインフラストラクチャは、異なる２種類の体系的アプローチで構築して良い。第１のアプローチは集中型アーキテクチャであり、第２のアプローチは分散型アーキテクチャである。集中型のアプローチは、カード所有者クライアントデバイスにソフトまたはデータを格納する必要がない。分散型アーキテクチャでは、反対に、カード所有者クライアントデバイス上にＰＡＳソフトが存在する。このソフトは、登録プロセスの最中に、登録サーバによってカード所有者クライアントデバイスへとダウンロードされる。分散型のアプローチでは、マーチャントは、カード所有者システムクライアントデバイスによって提供されるメカニズムを通してＰＡＳへのカード所有者の参加の有無を決定する。なお、ベンダすなわちＰＡＳソフトサプライヤは、ベンダまたはその顧客の具体的なビジネス要請に依存して、集中型アーキテクチャ、分散型アーキテクチャ、またはこれら２種類のアーキテクチャの組み合わせを選択することができる。図７〜１０は、集中型および分散型アーキテクチャに関してさらなる詳細を示している。
【００２２】
前述したように、分散型アーキテクチャは、カード所有者クライアントデバイスにソフトを格納することが望ましい。分散型ＰＡＳは、カード所有者が支払アプリケーションおよび永続的データをあるカード所有者クライアントデバイスから別のカード所有者クライアントデバイスへと転送するためのメカニズムを提供する。このメカニズムは、カード所有者クライアントデバイスが、カード所有者が登録プロセスの最中にアクセスしたクライアントデバイスと異なるクライアントデバイスである場合に、カード所有者のＩＤを認証する能力をＰＡＳに提供する。ＰＡＳシステムは、また、現行のカード所有者クライアントデバイスが、カード所有者がこれまでに使用したことのないクライアントデバイスである場合にも、カード所有者のＩＤを認証することができる。つまり、カード所有者は、２つ以上のクライアントデバイスにおいてＰＡＳを使用することができる。カード所有者クライアントデバイス間でＰＡＳソフトを転送するためには、少なくとも２つの方法が存在する。第１の方法は、フロッピィディスクなどの携帯型の記録媒体を使用してソフトを移すことを含む。第２の方法は、カード所有者が使用できるように、ＡＣＳが追加のクライアントデバイス上に動的にソフトをダウンロードすることを含む。
【００２３】
実施形態のなかには、ＰＡＳが電子ウォレットなどの他のカード所有者アプリケーションと相互運用することができ、ＰＡＳがｅコマースマークアップ言語（ＥＣＭＬソフト）に適合して作動することができるものがある。ＰＡＳは、また、紛争解決手続きを実施する能力をも提供する。例えば、ＰＡＳは、紛争解決および入金取り消しのために、マーチャントがカード所有者の認証を裏付けするのに十分な情報を保持することを可能にする。
【００２４】
セットアップ、登録、および許可に関する詳細な説明：
以下の説明は、ＰＡＳのセットアップからオンライントランザクションの実際の許可に至る様々な段階の詳細を述べる。先ず、ＰＡＳの中で作動できるように様々なシステム参加者をセットアップするために必要な手続きが説明される。次いで、ＰＡＳに登録するためのカード所有者プロセスが説明される。これらの段階が説明された後、支払トランザクションの実際の許可が説明される。
【００２５】
ＰＡＳのセットアップは、システム内の全参加者のためのセットアップ手続きを含む。これらの参加者は、マーチャント、金融機関、およびカード所有者などの主体を含む。先ず、オンラインマーチャントおよび金融機関のセットアップ手続きが説明され、次いで、カード所有者のためのセットアップ手続きが説明される。
【００２６】
ＰＡＳに申し込むオンラインマーチャントは、図１のプラグインソフトモジュール１３４などのマーチャントプラグインソフトモジュールを受け取る。プラグインソフトモジュールは、マーチャントが使用しているコンピュータプラットフォームおよびコマースサーバに特有であることが望ましい。ＰＡＳに参加している金融機関は、カスタマイズされたＰＡＳ登録サイトテンプレートに組み込まれる銀行ロゴおよびマーケティングデザインを提供する。また、決済側は、サービス組織認証局（ＣＡ）ルート証明書と、クライアント認証のためのサービス組織認証局ＳＳＬ証明書と、統合サポートとを、マーチャントに提供することが望ましい。
【００２７】
ＰＡＳを使用できるように発行側をセットアップする前に、決済側は、発行側ドメインで指定されたすべてのＰＡＳソフトウェアのコピーを取得し、ハードウェアシステムおよびＰＡＳソフトウェアをインストールしなければならない。発行側である金融機関は、次いで、ＩＤ認証ポリシと加入ＢＩＮ情報とがカード所有者ＩＤの検証プロセスにおいて使用できるように、これらをＰＡＳに供給する。発行側は、アカウント所有者ファイル１１８にプリロードするためのカード所有者認証情報を、ＰＡＳに随意的に供給することができる。プリロードは、カード所有者の大量サポートを促進する。例えば、全部または大部分のカード所有者をＰＡＳに対してアクティブにしたいと望む場合は、発行側は、その全部のカード所有者にＰＩＮ番号を送信することができる。ＰＩＮ番号は、次いで、各カード所有者がプリロード済みの自身のパスワードにアクセスするために使用することができる。こうすると、それぞれのカード所有者が形式的なＰＡＳ登録プロセスを経る必要がなくなり、登録プロセスが効率化される。カード所有者は、プリロード済みの自身のパスワードを始めて使用した後に、覚えやすいパスワードを新たに指定する選択肢を有する。
【００２８】
カード所有者認証情報は、ビジネスＩＤ、国番号、カードのアカウント番号、カードの有効期限、カードの名義人氏名、「加入ＢＩＮ」データのなかで指定された発行側に特有の認証データ（例えば母親の旧姓など）、ならびに請求先住所、届け先住所、社会保障番号、電話番号、勘定残高、トランザクションの履歴、および運転免許証番号などのその他の情報などの情報を含む。発行側は、また、カードアカウントポートフォリオおよびアクセス制御サーバＩＰアドレス（ＵＲＬ）のためのアカウント番号の範囲をディレクトリサーバに提供することが望ましい。ＰＡＳは、銀行ブランドのウェブサイトを通して提供され、これは、カード所有者がＰＡＳに登録することを可能にする。
【００２９】
図２は、カード所有者がＰＡＳに登録するプロセスを本発明の一実施形態にしたがって示している。動作１に示すように、カード所有者は、発行側などの金融機関によって維持されている登録サーバインターネットウェブサイトを訪問する。カード所有者は、自身のクレジットカードのアカウント番号を登録することによってＰＡＳに登録する。あるいは、チェックカードおよびデビットカードなどのカードを登録しても良い。また、カード所有者は、１つまたはそれ以上のカードを登録しても良い。ステップ２に示すように、カード所有者は、カード所有者の一次アカウント番号（ＰＡＮ）、氏名、およびカードの有効期限などの情報を入力する。消費者は、この時点で追加の情報を入力しても良い。カード所有者は、例えば、住所、ｅメールアドレス、ショッパＩＤ、アカウント検証値、カード所有者に特有のパスワード、および発行側に特有の認証情報を入力しても良い。この情報は、図３に示したページ３００のように、登録ウェブサイトにあるページに入力することができる。
【００３０】
カード所有者が、要求された情報を登録サイト１０８に入力した後、ＰＡＳは、カード所有者のＰＡＮが、発行側によって相互運用性ドメイン１０４のディレクトリサーバ１２８に登録されたカード範囲に含まれるか否かを検証する。ＰＡＳは、様々な方法を使用してカード所有者ＩＤを検証することができる。先ず、前述したように、ＰＡＳは、第三者の認証データベースまたは発行側自身の認証データベースを通してカード所有者のＩＤを検証することができる。また、カード所有者ＩＤの検証は、発行側が提供する認証済みカード所有者１２０のファイルを使用することによって、ステータスチェックの許可を発行側に伝送することによって、そして金融機関によって提供されたプリロード済みの情報に対する応答を比較することによって、実施することも可能である。
【００３１】
発行側によって登録されたカード範囲にＰＡＮが含まれない場合は、登録は拒絶され、登録プロセスは終結される。登録されたカード範囲にＰＡＮが含まれる場合は、１ドルに相当する許可が、ＶｉｓａＮｅｔなどのサービス組織支払ネットワークを通して発行側の金融機関に発信される。１ドルのトランザクションの許可は、発行側が、カードアカウント状況を検証し、アドレス検証サービスを使用してアドレスを検証し、そしてカード所有者検証値２（ＣＶＶ２）を検証することを可能にする。ＣＶＶ２は、支払カードの裏面の署名記載欄に印刷された三桁の番号である。
【００３２】
カードが承認された場合は、続く動作３において、カード所有者は、リアルタイムの対話式オンラインセッションにおいてカード所有者のＩＤを検証するために、追加の認証情報を要求される。本発明の実施形態のなかには、購入トランザクションの最中にカード所有者を認証するために使用されるパスワードおよび１対の「ヒントおよび答え」を入力するように、カード所有者に対して要求できるものもある。
【００３３】
ステップ４に示すように、カード所有者のＩＤが検証され、適切な応答が戻された場合は、ＰＡＳは、発行側の金融機関に許可メッセージを送信する。続くステップ５において、登録サーバ１１２は、アカウント所有者ファイル１１８内の記録をセットアップするために、カード所有者情報をアクセス制御サーバ１１４に引き渡す。図１のアカウント所有者ファイル１１８などのアカウント所有者ファイルは、金融機関のＢＩＮ番号、アカウント番号、有効期限、氏名、運転免許証番号、請求先住所、社会保障番号、カード所有者のパスワード、カード所有者のパスワードに関する質問、カード所有者のパスワードに関する答え、カード所有者のｅメールアドレス、第三者のＩＤスコア、およびその他の情報などの情報を、格納することができる。
【００３４】
本発明の実施形態のなかには、登録プロセスの最中に、カード所有者にとって認識可能な個人保証メッセージ（ＰＡＭ）と称されるフレーズを入力するように、カード所有者に対して要求できるものもある。ＰＡＭは、後の支払トランザクションの最中に、発行側がカード所有者に提示する。カード所有者が指定したＰＡＭを知るのは発行側のみなので、カード所有者は、ＰＡＳで使用されるダイアログウィンドウがカード所有者の発行側から送信されたものであることを保証される。ＰＡＭの一例は、「空は青い」である。
【００３５】
なお、カード所有者は、ＰＡＳを使用するために新たなクライアントソフトウェアまたはデバイスを必要とすることはない。しかしながら、ＰＡＳのチップカードによる実装は、チップカードリーダなどのカード所有者コンポーネントを追加で必要とする場合もある。好ましい一実施形態では、消費者登録プロセスは、カード所有者と登録サーバとの間をインターネットで伝送されるデータを保護するために、ＳＳＬチャンネル暗号化などのセキュリティプロトコルを利用する。
【００３６】
また、各金融機関は、消費者の登録プロセスの最中に、自身の「使用に際する条件」または「データプライバシポリシ」を表示しても良い。各金融機関は、登録プロセスを完了するために、登録中のカード所有者に対して条件およびポリシに同意するか同意しないかを問うことができる。金融機関は、各消費者が同意した「使用に際する条件」および／または「データプライバシポリシ」のバージョン番号を保存しておくことが望ましい。
【００３７】
ＰＡＳシステムの参加者がセットアップされ、カード所有者が登録された後は、ＰＡＳを利用して支払トランザクションが認証される。図４は、ＰＡＳによって認証済みの支払トランザクションを例示している。図４の動作１では、カード所有者は、インターネット上にあるマーチャントのｅコマースサイトを訪問する。カード所有者は、購入したい製品またはサービスを選択した後、チェックアウトプロセスを開始し、チェックアウトフォームに記入し、次いで「購入」ボタンをクリックする。
【００３８】
「購入」ボタンが選択された後は、図４のステップ２に示すように、マーチャントプラグインソフトモジュールがアクティブにされ、次いで、カード所有者に特有のアカウントがＰＡＳに登録されているか否かを決定する検証プロセスが実施される。マーチャントプラグインソフトモジュールは、カード所有者がＰＡＳに登録されているか否かを様々な方法によって決定することができる。例えば、ディレクトリサーバとカード所有者に関連付けられたＡＣＳとをチェックする２段階のプロセス、ＡＣＳのみをチェックするプロセス、そしてディレクトリサーバに保持されたものと同じ情報を含んだキャッシュメモリをマーチャントがチェックできる方法が挙げられる。
【００３９】
次に、２段階のプロセスが説明される。第１の段階において、マーチャントプラグインソフトモジュールは、カードのアカウント番号がＰＡＳ参加者である発行銀行に関連付けられた番号の範囲に含まれるか否かを検証するために、そのカードのアカウント番号を識別してディレクトリサーバ１２８に照会する。アカウント番号が、ディレクトリサーバ１２８に規定されたアカウント番号の範囲に含まれない場合は、その発行側、および、ひいてはそのカード所有者は、ＰＡＳに登録されていないことになる。この場合、マーチャントは、アカウント番号がＰＡＳに登録されていない旨を通知され、マーチャントプラグインソフトモジュールは、トランザクションの制御をマーチャントストアフロントソフトウェアに戻す。マーチャントストアフロントソフトウェアは、この時点において、通常通りにトランザクションをすすめるか、カード所有者に対するさらなるサービスを拒絶するか、または代替の支払方法を進めることができる。
【００４０】
反対に、アカウント番号がディレクトリサーバ１２８内に存在するアカウント番号の範囲に含まれることが決定された場合は、検証プロセスの第２の段階が開始される。検証プロセスの第２の段階は、カードが登録されているか否かを決定するために、カード所有者を認証することができるＡＣＳに対して、ディレクトリが、カード番号を送信することによって開始される。カードが登録されていない場合は、登録プロセスは終結される。カードが登録されていることが示された場合は、ＡＣＳは、ディレクトリサーバを介してマーチャントプラグインにそのＵＲＬインターネットアドレスを戻す。マーチャントプラグインは、次いで、カード所有者クライアントデバイスおよびその常駐ブラウザを介してＡＣＳを呼び出す。繰り返すが、ＰＡＳには複数のＡＣＳが存在することができる。
【００４１】
カード所有者がＰＡＳに登録されているか否かをチェックする第２の方法は、先にディレクトリサーバに照会することなくマーチャントプラグインソフトウェアモジュールが直接ＡＣＳに照会する方法である。上述したように、第３の方法は、ディレクトリサーバに保持されたものと同じ情報を含んだキャッシュメモリをマーチャントに有させる方法である。こうすると、マーチャントは少なくとも仮のチェックを行うことができる。
【００４２】
なお、ＰＡＳシステムには２つ以上の物理的ディレクトリサーバが存在することもできる。しかしながら、論理ディレクトリサーバは１つのみであることが好ましい。つまり、全てのディレクトリサーバは、同じ情報を含むという点で整合性を有することが望ましい。
【００４３】
カード所有者がＰＡＳ参加者である場合は、ＡＣＳは、銀行の商標が付いたウィンドウをカード所有者に表示する。銀行の商標が付いたウィンドウは、基本的な支払トランザクション情報を含んでおり、カード所有者にそのＰＡＳパスワードを要求する。図５は、カード所有者にそのＰＡＳパスワードを要求する代表的なウィンドウ５００を示している。カード所有者が自身のパスワードを入力すると、ＡＣＳはそのパスワードを検証する。今日では周知のように、カード所有者は、パスワードを正しく入力する試行機会を一定の回数だけ与えられる。正しいパスワードを入力することができない場合、カード所有者は、登録プロセスの最中に設定されたヒント質問に答えるように指示される。カード所有者は、ヒント質問に対して正しい答えを入力する試行機会を一度のみ与えられることが好ましい。
【００４４】
正しいパスワードが直ちに入力された場合または許されている試行回数内にカード所有者がヒント質問の正しい答えを入力した場合は、支払認証が続行される。ＡＣＳは、次いで、発行側の署名キーまたはサービスプロバイダのキーを使用して受領証にデジタル署名する動作に進む。この受領証は、マーチャントの名前と、カードのアカウント番号と、支払額と、支払期日とを含む。受領ファイル１３０は、以下のトランザクションデータすなわちマーチャントの名前と、マーチャントのＵＲＬと、カードのアカウント番号と、有効期限と、支払額と、支払期日と、発行側の支払署名と、カード所有者の認証検証値とを格納している。ＡＣＳは、次いで、カード所有者のブラウザを通してカード所有者をリダイレクトしてマーチャントプラグインに戻す。ＡＣＳは、この時点において、さらに、デジタル署名された受領証と、カード所有者が認証されたか否かに関する決定とをマーチャントに引き渡す。決済側ドメイン１０６にある資格検査サーバ１３６は、支払受領証に署名するために使用されたデジタル署名をマーチャントプラグイン１３４によって検証するために使用される。デジタル署名の検証後、カード所有者は「認証済み」とみなされる。本発明の実施形態のなかには、カード所有者が、トランザクションの完了後に自身のカードアカウントを再登録し、後のオンライン購入で使用する新しいパスワードを作成できるものもある。
【００４５】
ステップ３においてカード所有者が認証された後、ステップ４は、その特定のカード所有者のアカウントに許可を与えるためのプロセスを開始する。具体的に言うと、ステップ４において、マーチャントは、マーチャントプラグインソフトモジュールを通してＶｉｓａＮｅｔなどの支払ネットワークに許可メッセージを送信する。すると、支払ネットワークは、許可メッセージとＥＣＩとを発行側の金融機関に転送する。許可メッセージは、当該分野において良く知られているメッセージである。許可メッセージを発行側に送信することによって、発行側の金融機関は、特定のアカウントが良い状態にあり、尚且つ要求された支払トランザクションの購入額に適した上限貸出額を有することを、マーチャントに対して証明することができる。ＥＣＩは、インターネットでのトランザクションが完了したことを示し、使用されたメッセージセキュリティ（すなわち明確にはチャンネル暗号化（ＳＳＬ））および認証のレベルを示す。
【００４６】
本発明の代替の実施形態では、マーチャントは、許可メッセージとともに追加の情報を提供することができる。マーチャントは、例えば、カード所有者が首尾よく認証されたか否かを示すフラグ、アカウント情報、デジタル署名、カード所有者検証値２、カード認証検証値（ＣＡＶＶ）、チップカードＥＭＶ暗号文によって認証されたオフラインＰＩＮ、およびマーチャントに対する支払保証に必要なフィールドなどの情報を、送信することもできる。ＣＡＶＶは、カード所有者を認証したＡＣＳによって作成されるデータであり、所定の支払カードおよびそのカードからの特定の支払トランザクションに固有な値である。これは、続いて紛争が生じた場合に、ＰＡＳカードの発行側が認証済みの支払トランザクションを固有に識別するために使用される。発行側の金融機関による許可トランザクションが完了した後、購入トランザクションの制御は、支払ネットワークを介してマーチャントのストアフロントソフトウェアに戻される。次いで、発行側は、支払ネットワークを介してマーチャントに許可応答を戻す。図４のステップ５において、発行側の金融機関は、トランザクションを許可するかまたはトランザクションを拒否するかのいずれかである。実施形態のなかには、許可メッセージをバッチ処理し、後で纏めて送信できるものもある。また、バッチ許可メッセージには、ＰＡＳ認証情報も含まれる。
【００４７】
アクセス制御サーバ１１４は、他の様々な機能を果たすことができる。例えば、アクセス制御サーバは、登録されたアカウントをデータベースから非アクティブにすることができる。アカウントは、カード所有者または発行側によって手動で非アクティブにすることができる。また、アクセス制御サーバ１１４は、カード所有者が代わりのカードを受け取った場合に、簡単な更新登録プロセスを提供することもできる。アクセス制御サーバ１１４は、登録済みの同じアカウントを有した複数のユーザを、固有なアクセス制御情報とともにサポートすることができる。購入トランザクションまたはアカウント更新のためのアクセス制御サーバ１１４への接続がユーザに提供される場合は、アクセス制御サーバ１１４は、パスフレーズ、デジタル署名、および／またはチップカードＥＭＶ暗号文によるオンライン／オフラインＰＩＮ認証のうちの１つまたはそれ以上のメカニズムを通して、登録済みのアカウントを有した許可済みカード所有者としてのユーザの資格を検査することができる。
【００４８】
ＰＡＳにおいて、マーチャント１３２は、マーチャントがカード所有者のアカウント情報を登録した状態で既存のシステムと相互運用し、既存のマーチャント許可・決済オンラインシステムと相互運用し、複数のマーチャントにサービスを提供する第三者をサポートし、マーチャントと決済側との間で様々な支払インターフェースをサポートし、そしてｅコマース標識（ＥＣＩ）の値を設定する際に決済側からの支払ネットワーク許可メッセージに必然的に及ぼされる影響を最小限に抑えることができる。
【００４９】
マーチャントからアクセス制御サーバへとトランザクションをルーティングする方法の１つは、カード所有者のアカウント番号に基づいてサーバのアドレスを供給するディレクトリを有する方法である。このような方法では、ルーティング情報のためのＰＡＳ要求は、認証済みのマーチャントからのみ受け取ることができる。通常のアクティビティを超えるアクティビティが、マーチャントから検出されて報告される場合に、ＰＡＳは、アクセスが無効である旨を決済側から示されたマーチャントに関し、そのマーチャントへのアクセスを拒否することができる。これは、マーチャントの詐欺行為が予想される場合の話である。ＰＡＳシステムにはマーチャントの認証を装備することができるが、これは必ずしも必要ではない。マーチャントの認証は、マーチャントによる詐欺行為を最小限に抑えるために役立つ。
【００５０】
ＰＡＳ支払トランザクションのための詳細なメッセージフロー：
図６は、支払トランザクションの最中に送信される代表的なメッセージを、ＰＡＳアーキテクチャ上に重ねて示している。上述したように、購入トランザクションは、カード所有者がブラウザを介してマーチャントウェブサイトを訪問し、購入する商品を選択する際に開始する。マーチャントの支払システムは、その支払情報を入力するようにカード所有者に要求する。一般に、支払情報の入力は、例えばＳＳＬ暗号化プロトコルを使用するなどして、機密保護機能のある環境において生じることが望ましい。トランザクションを終了する用意のあることが、カード所有者によって示される場合は、マーチャントの支払システムは、ＰＡＳマーチャントプラグインソフトウェアモジュール１３４を呼び出す。次いで、矢印１ａによって示されるように、プラグインソフトウェアモジュール１３４は、カード所有者がサービスに登録されていることの妥当性を検査するために、ＡＣＳのうちカード所有者の支払人認証番号（ＰＡＮ）を含み得る特定のＵＲＬがないかどうか、ディレクトリサーバ１２８をチェックする。あるいは、プラグインソフトウェアモジュール１３４は、この情報を含む自身のキャッシュメモリをチェックする。ソフトウェア１３４は、カード所有者のＰＡＮを使用してVerifyEnrollmentReqメッセージをフォーマット設定することによって、ＰＡＮの検索を行う。接続が確立されていない場合は、マーチャントプラグインソフト１３４は、ディレクトリサーバ１２８またはアクセス制御サーバ１１４への安全な接続を確立して自身の認証を行う。マーチャントプラグインソフト１１４は、カード所有者のＰＡＮに対応するカード範囲を様々な場所で検索する。検索される場所の１つは、ディレクトリ情報のマーチャントプラグインソフトウェアキャッシュである。マーチャントプラグインソフトウェアモジュールは、また、ディレクトリサーバおよびアクセス制御サーバをチェックすることもできる。
【００５１】
マーチャントプラグインソフトウェア１１４が検索を実施した後、VerifyEnrollmentReqメッセージは、線１ｂで示したようにアクセス制御サーバ１１４に直接伝送されるか、または線１ａで示したようにディレクトリサーバ１２８を先ず通過してからアクセス制御サーバ１１４に伝送される。VerifyEnrollmentReqメッセージが、ディレクトリサーバ１２８を介してアクセス制御サーバ１１４に伝送される場合は、ディレクトリサーバ１２８は、VerifyEnrollmentReqメッセージに含まれるカード所有者ＰＡＮに対応する記録を検索する。一致に成功しなかった場合は、ディレクトリサーバ１２８は、ＵＲＬ値を用いずにVerifyEnrollmentResメッセージのフォーマット設定を行い、ＰＡＮ登録のステータス値すなわちVerifyEnrollmentRes-Statusを「Ｎ」に設定する。VerifyEnrollmentResメッセージは、次いでマーチャントプラグインソフトウェアに戻される。一致に成功した場合は、ディレクトリサーバ１２８は、もしまだ接続が確立されていないならばアクセス制御サーバＵＲＬへの安全な接続を確立し、そのＵＲＬに対して自身の認証を行う。そして、VerifyEnrollmentReqメッセージがクセス制御サーバＵＲＬへと転送される。そのＵＲＬが使用可能でない場合は、マーチャントプラグインは、（もし使用可能ならば）次のアクセス制御サーバＵＲＬ値に進むことが望ましく、最大で５つのアクセス制御サーバＵＲＬを検索することが可能である。試行できるＵＲＬの数は、もちろん可変である。全ての試行に失敗した場合は、VerifyEnrollmentRes-Statusを「Ｎ」に設定し、その購入トランザクションがＰＡＳトランザクションとして処理できないことをマーチャントに示したうえで、VerifyEnrollmentResメッセージがマーチャントプラグインに戻される。
【００５２】
アクセス制御サーバ１１４がVerifyEnrollmentReqメッセージを受信した後、アクセス制御サーバは、VerifyEnrollmentReqメッセージからカード所有者ＰＡＮを受け取り、アカウント所有者ファイル１１８に照らしてその妥当性を検査する。アクセス制御サーバ１１４は、次いで、VerifyEnrollmentResメッセージをフォーマット設定する。一致に成功した場合は、アクセス制御サーバは、ＰＡＮ登録の状況を「Ｙ」に設定し、アクセス制御サーバ１１４において内部的にＰＡＮに関連付けられる単一使用プロキシＰＡＮを作成し、ＵＲＬフィールドをVerifyEnrollmentReqメッセージの中に取り込む。一致に成功しなかった場合は、アクセス制御サーバは、ＰＡＮ登録の状況を「Ｎ」に設定する。アクセス制御サーバは、次いで、線２ａで示したように、ディレクトリサーバ１２８を通してマーチャントプラグインにVerifyEnrollmentResメッセージを戻す。VerifyEnrollmentReqメッセージがアクセス制御サーバに直接伝送される場合は、VerifyEnrollmentResメッセージは、線２ｂで示したようにマーチャントプラグインに直接戻される。
【００５３】
ディレクトリサーバ１２８のキャッシングは、１対のメッセージCRReqおよびCRResを利用して促進することができる。CRReqメッセージは、マーチャントプラグインモジュールからディレクトリサーバへと送信され、加入カードの範囲のリストを要求することによって、プラグインがそのキャッシュを更新できるようにする。CRResメッセージは、加入範囲を含んだ応答である。
【００５４】
VerifyEnrollmentResメッセージが発行側のアクセス制御サーバから戻された後、ＰＡＳシステムは、１対のメッセージQueryCardholderReqおよびQueryCardholderResを使用して、カード所有者クライアントデバイスが認証能力を配布したか否かをチェックする。マーチャントプラグインは、配布されたＰＡＳカード所有者モジュールが常駐しているか否かを決定するために、照会であるQueryCardholderReqメッセージをフォーマット設定し、カード所有者クライアントデバイス１２２に送信する。QueryCardholderReqメッセージの送信は、図６の線３によって示される。配布済みの任意の認証オプションが、QueryCardholderResメッセージに含まれた状態で戻された場合は、マーチャントプラグインは、ＰＡＳカード所有者クライアントソフトと直接通信し、認証済みの段階を実施する。QueryCardholderResメッセージの送信は、図６の線４によって示される。
【００５５】
VerifyEnrollmentRes-Statusの値が「Ｙ」ではない場合は、マーチャントは、その購入トランザクションがＰＡＳトランザクションとして処理できないことを通知される。しかしながら、VerifyEnrollmentRes-Statusの有する値が「Ｙ」である場合は、マーチャントプラグインは、支払要求メッセージPAReqをフォーマット設定する。マーチャントプラグインは、線５で示したように、カード所有者クライアントデバイスのブラウザを介して発行側のＡＣＳサーバにRAReqメッセージを送信する。
【００５６】
また、VerifyEnrollmentReqメッセージおよびVerifyEnrollmentResメッセージは、QueryCardholderReqメッセージおよびQueryCardholderResメッセージを使用して削除して良い。カード所有者クライアントソフトウェアは、そのソフトウェアに組み込まれた発行側ＡＣＳのＵＲＬを装備することができる。マーチャントプラグインは、先ず、QueryCardholderReqメッセージおよびQueryCardholderResメッセージを完了する。ＰＡＳカード所有者クライアントソフトウェアが検出された場合は、支払人認証要求（PAReq）メッセージは、VerifyEnrollmentReqメッセージおよびVerifyEnrollmentResメッセージを実行することなくＡＣＳまたはカード所有者クライアントソフトに送信することができる。
【００５７】
マーチャントプラグインが、発行側ＡＣＳに支払人認証要求（PAReq）を引き渡した後、ＡＣＳは、カード所有者に対してウィンドウを表示する。ウィンドウは、発行側のロゴ、サービス組織のマークまたはブランドロゴ、マーチャント名、マーチャントの位置（ＵＲＬ）、購入総額および通貨、購入日、カード番号、分割払い／定期循環払いの条件、注文の詳細または詳細へのリンク、特別な販売条件またはこの情報へのリンク、個人保証メッセージ（ＰＡＭ）、ならびにカード所有者のパスワードを要求するプロンプトなど、支払人認証応答（PARes）に含まれた支払の詳細を、他の項目とともに表示する。
【００５８】
ＡＣＳは、次いで、適切なパスワードを入力するようにカード所有者に指示する。ＡＣＳは、カード所有者による入力を受け入れ、その資格をアカウント所有者ファイル１１８に照らして検査する。ＰＡＳは、例えば、正しいパスワードを入力する試行機会を一定の回数（例えば3回）だけ許可する。許可される試行回数は、もちろん可変である。最後の試行でも成功しなかった場合は、ＰＡＳはヒント質問を表示する。カード所有者は、ヒント質問に対して正しい答えを入力することがの望ましい。次いで、カード所有者に関連付けられたヒント質問が表示される。カード所有者は、正しい答えを入力する試行機会を少なくとも一度だけ与えられる。カード所有者が、正しくない答えを入力した場合は、マーチャントは、ＰＡＳトランザクションを完了できないことを通知される。カード所有者が、正しい答えを入力した場合は、トランザクションは、パスワードが一致したものとして処理されるべきである。なお、１つのアカウント番号に対して２つ以上のエントリがある場合は、様々なカード所有者名がドロップダウンウィンドウに表示される。カード所有者は、次いで、自分の名前を選択することができる。
【００５９】
パスワードを突き合わせるに当たって、ＡＣＳは、支払応答メッセージPAResを生成し、それにデジタル署名する。ＡＣＳは、また、線７で示したように、SaveReceiptメッセージを生成し、受領証ファイル１３０および受領証マネージャ１３１に送信する。線７ａで示したように、SaveReceiptメッセージは、受領証ファイル１３０から発行側の許可・清算システム１３８に引き渡されることによって、発行側が、支払の許可要求を支払人を認証済みのトランザクションに対してリアルタイムで突き合わせられるようにしても良い。SaveReceiptメッセージが、発行側の許可・清算システム１３８に送信されると、発行側は、それと同時に、許可要求が認証済みの購入のためのものであるか否かを決定することが可能になる。ＡＣＳは、次いで、線６で示したように、署名されたPAResをリダイレクトしてマーチャントサーバプラグインに戻す。
【００６０】
署名されたPAResが、マーチャントプラグインに戻された後、プラグインは、非活性化にされる。認証状況が「Ｙ」である場合は、プラグインは、PAResを資格検査サーバ１３６に送信する。資格検査サーバの機能がマーチャントプラグインによって提供される場合は、マーチャントプラグインが、PAResの署名の正当性を検査してその検査結果を戻す。署名が正当でないとされた場合は、マーチャントプラグインは、そのトランザクションをＰＡＳトランザクションとして処理できないことをマーチャントに通知する。認証状況が「Ｎ」である場合は、マーチャントは、追加情報を要求するプロンプトをカード所有者に送信するか、異なる支払カードもしくは支払形式を使用するようにカード所有者に要求するか、または支払トランザクションを非認証済みの支払トランザクションとして処理することが望ましい。
【００６１】
決済側ドメイン１０６が、資格検査サーバを含んでいる場合は、資格検査サーバ１３６が、PARes上の署名の正当性を検査する。資格検査サーバ１３６は、次いで、署名の正当性検査の結果をマーチャントプラグインに戻す。署名が正当でないとされた場合は、マーチャントプラグインは、そのトランザクションをＰＡＳトランザクションとして処理できないことをマーチャントに通知する。反対に、署名が正当であるとされた場合は、マーチャントは認証済みの支払の許可に進む。PAResメッセージは、線６ａで示したように、マーチャントからその決済側の支払プロセッサ１４０へと引き渡しても良い。RAResは、次いで、通信ネットワーク１４２を通して決済側から発行側へと引き渡して良い。したがって、支払人認証の結果は、標準的な支払許可プロセスの一部として発行側に提供される。
【００６２】
次に、様々な伝送路に関するセキュリティの問題が説明される。ベースラインとしての伝送路は、全て、１２８ビットのＳＳＬを使用して暗号化されていることが好ましい。カード所有者とマーチャントとの間の通信路は２本である。マーチャントは、カード所有者が支払情報を入力する際に使用される接続を、サービス組織によって承認済みの認証局から取得されたＳＳＬ証明書を使用して保護することが望ましい。マーチャントは、また、PAResメッセージをカード所有者からマーチャントプラグインに送すために使用される接続を、サービス組織によって承認済みの認証局から取得されたＳＳＬ証明書を使用して保護することが望ましい。
【００６３】
カード所有者とＡＣＳとの間の通信路は、サービス組織によって承認済みの認証局から取得されたＳＳＬ証明書を使用して、ＡＣＳによって暗号化することが望ましい。この通信路は、２つのことを目的として使用される。第１に、PAReqメッセージをマーチャントプラグインからＡＣＳに送信するため、第２に、署名されたPAResメッセージをＡＣＳからカード所有者に送信するためである。
【００６４】
カード所有者と登録サーバとの間の通信路は、サービス組織によって承認済みの認証局から取得されたＳＳＬ証明書を使用して、登録サーバによって暗号化することが望ましい。この通信路は、カード所有者の登録情報を受け入れるために使用される。
【００６５】
VerifyEnrollmentReqメッセージおよびVerifyEnrollmentResメッセージに含まれたＰＡＮデータと、VerifyEnrollmentResメッセージに含まれたＡＣＳのＵＲＬアドレスとを保護するためは、マーチャントとディレクトリサーバとの間の通信路と、ディレクトリサーバとＡＣＳサーバとの間の通信路とが、サービス組織によって発行済みのＳＳＬ暗号化証明書を使用して保護されることが望ましい。
【００６６】
ＡＣＳとカード所有者との間の通信路は、カード所有者のパスワードを要求するプロンプトとカード所有者が入力したパスワードとを保護するために、暗号化することが望ましい。この通信路は、サービス組織によって承認済みの認証局から取得されたＳＳＬ証明書を使用して保護することが望ましい。
【００６７】
集中型および分散型アーキテクチャの実施形態：
図７および図８は、集中型アーキテクチャを示しており、図９および図１０は、分散型アーキテクチャを示している。図７〜１０は、また、登録プロセスおよび支払プロセスの最中のメッセージフローを重ねて示している。
【００６８】
図７は、集中型のＰＡＳアークテクチャでのメッセージフローを本発明の一実施形態にしたがって示している。前述したように、集中型のアプローチは、カード所有者のシステム上にソフトウェアまたはデータを格納する必要がなく、カード所有者のパスワードは、中央データストレージサイト（ＡＨＦ）に格納される。集中型アーキテクチャ７００は、例えばパソコン（ＰＣ）７０２などのカード所有者クライアントデバイスと、ＰＡＳ７０４とからなる。カード所有者クライアントデバイス７０２は、カード所有者がＰＡＳにアクセスすることを可能にするインターネットブラウザ７０６をサポートする。ＰＡＳ７０４は、少なくとも登録サーバ７０８を含む。集中型アーキテクチャの表示を不必要に複雑化しないため、図中、ＰＡＳシステムの他の様々なコンポーネントは示されていない。集中型の登録プロセスは、ＰＡＳに登録するためにカード所有者が銀行のインターネットサイトおよび特定の登録ページに入るステップ１から開始する。カード所有者からの照会に応じ、登録サーバ７０８は、ステップ２において認証質問をカード所有者に表示する。カード所有者は、ステップ３において認証質問に答え、要求されたパスワードを提供する。
【００６９】
登録サーバは、続くステップ４において、資格検査プロセスを通して答えの正当性を検査する。資格検査プロセスの結果は、ステップ５において登録サーバ７０８に戻される。ステップ６では、データベースおよびディレクトリサーバが更新される。ステップ７において、カード所有者は、自身の登録が承認されたか否かを通知される。
【００７０】
図８は、カード所有者クライアントデバイス７０２と、ＰＡＳ７０４と、マーチャントシステム７２０との間で生じる集中型の支払フローを、本発明の一実施形態にしたがって示している。図８において、ＰＡＳ７０４は、ディレクトリサーバ７１０と、ＡＣＳサーバ７１２と、受領証データベース７１４とを含む形で示されている。マーチャントサーバは、ストアフロントソフトウェアプログラム７２２と、ＰＡＳを提供されたマーチャントプラグインソフトウェアモジュール７２４と、支払システム７２６とを含む。集中型の支払フローは、ステップ１において、カード所有者がマーチャントのｅコマースウェブサイトでショッピングするときに開始する。カード所有者がチェックアウトプロセスを開始すると、マーチャントプラグインモジュール７２４は、ステップ２において、カード所有者がディレクトリサーバ７１０に登録されているか否かをチェックする。カード所有者が登録されている場合は、ディレクトリサーバは、発行側のＡＣＳサーバのＵＲＬアドレスをマーチャントプラグインに戻す。ステップ３において、マーチャントプラグインモジュール７２４は、PAReqメッセージをＡＣＳ７１２に送信する。PAReqメッセージに応じて、カード所有者は、最終的に自分のパスワードを入力する。ＡＣＳサーバによってパスワードが正当だとみなされた場合は、ステップ４において、デジタル署名されたPAResメッセージがＡＣＳ７１２からマーチャントプラグインモジュールに送信され、トランザクションが認証されたことがマーチャントに通知される。トランザクションの状況は、ステップ５において、支払システム７２６に送信される。そして、トランザクションを終了するため、ステップ６において、マーチャントのストアフロントソフト７２２が支払データを支払システムに送信する。
【００７１】
図９は、分散型ＰＡＳアークテクチャでの登録フローを本発明の一実施形態にしたがって示している。前述したように、分散型アーキテクチャは、カード所有者のシステム上にソフトおよび／またはデータを格納する。分散型のアプローチでは、マーチャントは、カード所有者クライアントデバイス上のＰＡＳカード所有者モジュールのなかのメカニズムを通して、カード所有者がＰＡＳに参加しているか否かを決定する。分散型アーキテクチャ９００は、インターネットブラウザ９０４を含んだカード所有者クライアントデバイス９０２と、登録サーバ９０８を含んだＰＡＳ９０６とを少なくとも含む。なお、分散型のアプローチはディレクトリサーバを含まない。この登録プロセスは、ステップ１において、カード所有者がＰＡＳに登録するために銀行に特有のインターネット登録ページに入ることから開始する。ステップ２において、カード所有者は認証質問を提示される。ステップ３において、カード所有者は、認証質問の答えを登録サーバ９０８に戻す。カード所有者の答えは、ステップ４において、資格検査プロセスを通して正当性を検査される。資格検査プロセスの結果は、ステップ５において、登録サーバ９０８に戻される。カード所有者が正当であるとされた場合は、ステップ６において、カード所有者ソフトモジュール９１０および証明書がカード所有者に提供される。これらは、インターネットを介して登録サーバからダウンロードされる。
【００７２】
図１０は、分散型ＰＡＳアークテクチャでの支払フローを本発明の一実施形態にしたがって示している。マーチャントモジュール９５０は、ストアフロントソフトウェア９５２と、マーチャントプラグインソフトウェアモジュール９５４と、支払システム９５６とを含む。支払プロセスは、通常通りステップ１において、カード所有者がマーチャントのｅコマースウェブサイトでショッピングしてチェックアウトに進むことから開始する。ステップ２において、マーチャントは、カード所有者ソフトウェアモジュール９１０がカード所有者クライアントデバイスのなかに存在するか否かをチェックする。カード所有者ソフトウェアモジュール９１０が存在している場合は、マーチャントモジュール９５４は、集中型アーキテクチャと異なり、ＡＣＳにではなくカード所有者ソフトウェアモジュール９１０にPAReqメッセージを送信する。カード所有者ＰＡＳソフトウェアモジュールは、発行側ＡＣＳサーバのインターネットＵＲＬアドレスを知っており、PAReqメッセージをＡＣＳサーバに引き渡す。ＡＣＳサーバは、カード所有者にパスワードを尋ねるためにカード所有者モジュールと対話する。カード所有者によって供給されたパスワードが、ＡＨＦ上の同一のカード所有者のパスワードに等しい場合は、そのカード所有者は認証される。ＡＣＳサーバは、続くステップ４において、PAResメッセージでもってマーチャントモジュールに応答する。認証プロセスの状況およびそれに関連付けられたデータは、ステップ５において、支払システム９５６に送信される。トランザクションの受領証は、ステップ６において、受領証データベース９６０に送信される。そしてトランザクションを完了するため、ステップ７において、ストアフロントから支払システムに支払データが送信される。
【００７３】
チップカードの実施形態：
支払人認証サービス（ＰＡＳ）のチップカードの実施形態は、集積回路カード（チップカードまたはスマートカードとしても知られている）を使用しているカード所有者と、チップカードリーダとを含む。チップカードの実施形態は、オンライン購入トランザクションに対してさらに別のレベルの認証を追加する。前述したＰＡＳが、オンライン購入においてカード所有者のＩＤを認証する能力を提供する一方で、ＰＡＳのチップカードの実施形態は、カード所有者が確かに自分のチップカードを所有しているかを認証する能力も提供する。チップカードの正当性を検査するためには、様々な方法が使用可能である。１つは、チップによって生成された秘密を使用し、発行側ＡＣＳによってその正当性を検査するアプローチである。
【００７４】
チップカードの実施形態は、また、カードを認証するためだけでなく、本明細書において前述したように、カード所有者を認証するためにもＰＡＳを使用することができる。ＰＡＳのパスワードをＡＣＳに提供するためには、２つの技術が使用可能である。第１の技術では、チップカードのチップカードクレジット・デビットアプリケーションが、ＰＡＳパスワードを打ち込むようにカード所有者に指示する。カード所有者は、前述したのと同様な方法でパスワードを入力する。パスワードは、次いで、ＡＣＳに転送される。
【００７５】
第２の技術では、ＰＡＳパスワードは、チップカードによって自動的にＡＣＳに供給される。この技術は、カード所有者がチップカードを利用することを許可するために、チップカードに格納されたパスワードを使用してカード所有者を認証する。これは、カード上に常駐する「アクセス」アプレットと称される（カードへの汎用アクセスを提供できるから）アプレットとその常駐アプリケーションとを使用するアプローチであり、カード所有者を認証するために使用することができる。アクセスアプレットは、また、カード上のアプリケーションへのアクセスを不可にすることもできる。単一の汎用「アクセス」パスワードを表示してカード所有者を認証するにあたって、アクセスアプレットは、カード所有者が様々なサービスまたはアプリケーション（例えばオンラインのバンキングサイトや電子請求支払サービスへのアクセスなど）にアクセスすることを可能にする。例えば、単一の「アクセス」パスワードを表示することによって、アプレットは、カード上に格納されたあらゆるパスワードの使用を可能にする。
【００７６】
一般に、チップカードの実施形態のためのセットアップ手続きおよび認証プロセスは、従来のカードの実施形態のためのそれと同じである。チップカードの実施形態と従来のチップカードの実施形態との違いは、以下の説明から明らかになる。
【００７７】
図１０Ａ，１１，１２，１２Ａ，１３をそれぞれ参照しながら、ＰＡＳのチップカードの実施形態が説明される。図１０Ａは、チップカード支払人許可サービスアーキテクチャの一実施形態を示している。図１１は、認証済みの支払トランザクションにおけるＰＡＳチップカードおよびカード所有者の認証の概略を示している。図１２は、システムアーキテクチャのレイアウト上にプロセスフローを重ねて示している。図１２Ａは、チップカードをともなった支払人認証サービスを使用している支払トランザクション中のメッセージフローを、より詳細に示している。最後に、図１３は、チップカード支払人認証システムの別の実施形態を示している。具体的に言うと、図１３は、チップカード上に存在しえる様々なアプリケーションへのアクセスを制御するために使用されるアクセスアプリケーションを、追加の特徴として有したチップカードの実施形態を示している。
【００７８】
図１０Ａは、チップカード支払人許可サービスの一実施形態によるシステムアーキテクチャを示した概要図である。支払トランザクションは、通常通り、カード所有者がカード所有者クライアントデバイス１２２を使用してマーチャントのｅコマースウェブサイトにアクセスすることから開始する。カード所有者クライアントデバイス１２２は、チップ支払人認証ＡＣＳプラグイン１１５を有した発行側のアクセス制御サーバ１１４に接続される。発行側ＡＣＳ１１４はアカウント所有者ファイル１１８に接続され、アカウント所有者ファイル１１８は受領ファイル１３０に接続される。マーチャント１３２は、マーチャントプラグインソフトウェアモジュール１３４を使用して支払人認証サービスに参加する。マーチャント１３２は、ディレクトリサーバ１２８と、資格検査サーバ１３６と、決済側支払プロセッサ１８２とに接続される。決済側支払プロセッサ１８２は支払ネットワーク１２６に接続され、支払ネットワーク１２６は発行側１８０に接続される。
【００７９】
図１１は、チップカードシステムを使用した支払トランザクションの概要を示したフローチャートである。支払トランザクションは、カード所有者がオンラインマーチャントウェブでショッピングし、ショッピングをチェックアウトウェブページで完了しようとするブロック１１００から開始する。ブロック１１１０において、ＰＡＳは、カード所有者がＰＡＳに登録された参加者であるかどうかを、例えばカード所有者が「購入」ボタンをクリックした後に検証する。ブロック１１２０において、マーチャントプラグインモジュールが、関連付けられたアクセス制御サーバにPAReqメッセージを送信すると、ブロック１１３０において、そのアクセスサーバは、カード所有者クライアントデバイスの中のＰＡＳカード所有者モジュールを介して、カード所有者クライアントデバイスがチップカードリーダを含むかどうかを検証する。カード所有者がチップカードリーダを有さない場合は、支払トランザクションは、終了するか、または別の支払方法を使用しなければならない。
【００８０】
カード所有者クライアントデバイスがチップカードリーダを有する場合は、ブロック１１４０において、消費者は、自身のチップカードをチップカードリーダに挿入するように指示される。ブロック１１５０において、カード所有者クライアントデバイスのなかのカード所有者モジュールは、チップカードに含まれた秘密情報に基づいて暗号文を生成するように、チップカードに対して要求する。また、ブロック１１６０において、カード所有者は、登録された自身のＰＡＳパスワードを入力するように要求される。ブロック１１７０において、チップカードが生成した暗号文と、カード所有者が入力したパスワードとが、認証のために共にＡＣＳに送信される。
【００８１】
ブロック１１８０において、ＡＣＳは、図４においてチップカード無しのＰＡＳシステムに関して前述された方法と類似の方法で、ＰＡＳパスワードの正当性を検査する。ＡＣＳは、また、ＡＣＳサーバの様々なコンポーネントに含まれた情報を使用して、このチップカードのための暗号文のコピーをもう１つ別に生成する。この点に関しては、図１２を参照のこと。ＰＡＳパスワードが一致した場合は、カード所有者のＩＤが認証される。ブロック１１９０において、チップカードによって生成された暗号文とＡＣＳによって生成された暗号文とが一致する場合は、そのチップカードは、カード所有者によって実際に使用されているカードであることを承認される。ブロック１１９５において、ＡＣＳは、支払応答メッセージをマーチャントプラグインソフトモジュールに戻す。支払応答メッセージは、カード所有者が認証されたこと、そしてカード所有者クライアントデバイスにおいて実際に使用されているカードが適切なカードであることを、マーチャントに通知するために、カード許可検証値（ＣＡＶＶ）を含んでいる。購入トランザクションは、次いで、前述した場合と同様に進行する。
【００８２】
図１２は、本発明の一実施形態にしたがって支払プロセスフローをチップカードシステムアーキテクチャに重ねて示した図である。チップカード認証アーキテクチャ１５００は、カード所有者クライアントデバイス１５１０と、発行側ＡＣＳ１５２０と、カード所有者１５３０と、チップカード１５４０と、要求者１５５０とを含む。通常は、ＰＡＳ環境における要求者はマーチャントである。カード所有者クライアントデバイス１５１０は、表示デバイス１５１２と、端末ソフト１５１４と、ＰＩＮパッドまたはキー入力デバイス１５１６と、カードリーダ１５１８とを含む。カードリーダ１５２８は、端末アプリケーションで使用するためにチップカードを挿入される電気機械デバイスであり、カード受け入れデバイスまたはインターフェースデバイス（販売環境の物理地点におけるＩＦＤ）と機能的に等しい。
【００８３】
ＡＣＳ１５２０は、ＰＡＳ認証ソフトウェア１５２２と、ハードウェアセキュリティモジュール１５２４と、カード所有者データベース１５２６と、システムソフトウェア１５２８とを含む。チップカード１５４０は、Visa Smart Debit Credit Application（ＶＳＤＣ）などのチップカードクレジット・デビットアプリケーション１５４２を含む。なお、ＶＳＤＣアプリケーションに言及されている本明細書の状況は、一般的なデビット・クレジットアプリケーションを利用することもできる。
【００８４】
要求者１５５０は、特定の支払トランザクションに関連付けられたマーチャントである。発行側サーバ１５２０は、発行側または発行側を代理する第三者によって運営され、チップカードの暗号文の正当性を検査できるＡＣＳである。これは、要求側の関係者１５５０とカード所有者クライアントデバイス１５１０との間のインターフェースとして機能する。カード所有者クライアントデバイス１５１０は、コンポーネントとソフトとからなり、カード所有者１５３０と、チップカード１５４０と、発行側ＡＣＳ１５２０との間のインターフェースとして機能するシステムであり、例えば、パソコン、携帯電話、セットトップボックス、または任意の他のデバイス、または機能的に類似のコンポーネントからなる集合である。
【００８５】
カード所有者１５３０は、カード所有者クライアントデバイス１５１０を通常的に管理している関係者であり、カードを挿入する、ＰＩＮを入力する、またはカード所有者クライアントデバイス１５１０のコンポーネントが適切に作動可能であるか否かをチェックするなどの機能を実施することができる。チップカード１５４０は、発行側からの支払カードであり、Visa Smart Debit Credit Applicationなどのチップカードクレジット・デビットアプリケーション１５４２を含む。
【００８６】
以下の説明は、チップカード支払認証プロセスにおいて生じるシナリオを、プロセスステップの順番に対応する図１２の丸付きの番号を参照にしながら簡単に述べる。ステップ１において、マーチャントなどの要求者は、チップカードの認証が要求されたどうか決定し、それを実行するように発行側ＡＣＳに要請する。
【００８７】
認証したいカードのための一次アカウント番号（ＰＡＮ）を、支払要求メッセージから取得した発行側ＡＣＳは、ステップ２において、ＶＳＤＣ認証要求と称されるメッセージを、カード所有者クライアントデバイスに送信する。
【００８８】
発行側ＡＣＳからの要求に応じて作動するカード所有者クライアントデバイスは、ステップ３において、カードを認証しようと試みる。カード所有者クライアントデバイスは、先ず、必要なコンポーネントが存在していて作動可能であるか否かを決定する。次いで、カード所有者クライアントデバイスは、表示画面にメッセージを表示することによって、認証したいチップカードをカードリーダに挿入するようにカード所有者に要求する。
【００８９】
ステップ４において、カード所有者は、チップカードをカードリーダに挿入することによって応答し、カードリーダは、カードが挿入されたことを通知するメッセージをカード所有者クライアントデバイスに対して生成する。あるいは、カードリーダの機能性如何によっては、カード所有者クライアントデバイスは、番号５の経路を使用してカードリーダをポーリングし、カードを現在読み取ることが可能か否かを決定することが望ましい。
【００９０】
ステップ５において、カード所有者クライアントデバイスは、チップカードおよびチップカード上のＶＳＤＣアプリケーションを初期化し、次いでこれらと通信することによって、後の資格検査のために、チップカードから暗号文を戻すように指示する。
【００９１】
ステップ６では、チップカードとの通信中に複数回の交換が生じる。チップカードは、ＰＩＮを入力するようにカード所有者に要求して良い。この場合は、カード所有者クライアントデバイスは、ＰＩＮパッドまたは他のキー入力デバイスを介してＰＩＮを入力するように、カード所有者に通知する。
【００９２】
ステップ５およびステップ６において、メッセージ（コマンド）を送信しカードからの応答を受信する一方で、カード所有者クライアントデバイスは、ステップ７において、ＶＳＤＣ認証応答を構成するために必要な情報を収集し、この応答を発行側ＡＣＳに送信する。アクセス制御サーバは、ＶＳＤＣ認証応答メッセージによって供給された情報を使用し、パスワードを介したカード所有者の認証と暗号文を介したチップカードの認証の両方を試みる。
【００９３】
ステップ８において、発行側ＡＣＳは、支払応答メッセージを介し、マーチャントまたは要求者に、カード所有者およびチップカードの認証プロセスの結果を応答する。
【００９４】
ＶＳＤＣ認証サービスの各主体の基本機能が続いて説明される。要求者すなわちマーチャントは、チップカードＶＳＤＣ認証プロセスを開始するように、発行側ＡＣＳにシグナル通知するかまたは発行側ＡＣＳをトリガし、ＶＳＤＣ認証を実施するのに必要なデータを発行側ＡＣＳに提供し、そして発行側ＡＣＳによって提供されたＶＳＤＣ認証結果を使用するように機能する。
【００９５】
発行側ＡＣＳは、暗号文の正当性検査のために必要な暗号キーを安全に格納し、ＶＳＤＣ認証プロセスを実施するのに必要なデータを収集し、ＶＳＤＣ認証要求メッセージをカード所有者クライアントデバイスソフトウェアに送信することによってＶＳＤＣ認証プロセスを開始し、カード所有者クライアントデバイスを介してチップカードから送信された暗号文の正当性を、取り付けられたハードウェアセキュリティモジュール（ＨＳＭ）のなかで検査し、そして暗号文の正当性検査の結果を支払応答メッセージを介して要求側関係者またはマーチャントに供給するように機能する。
【００９６】
カード所有者クライアントデバイスは、発行側ＡＣＳと通信し、ＶＳＤＣ認証要求メッセージを受信し、カードの挿入／取り出しおよびＰＩＮの入力のためにカード所有者と通信し、チップカードと通信し、ＶＳＤＣ認証のために必要なデータをチップカードに送信し、ＶＳＤＣ認証のために必要なデータをチップカードから受信し、チップカードから暗号文を受信し、そしてカードによって生成された暗号文を発行側ＡＣＳに送信するように機能する。カード所有者クライアントデバイスは、また、パスワードを入力するようにカード所有者に要求し、入力されたパスワードをＡＣＳに引き渡す。
【００９７】
カード所有者は、カードリーダにチップカードを挿入し、チップカード環境の準備が整っているか否かを決定し、ＰＩＮを入力し、カードリーダからチップカードを取り出し、自身のパスワードを入力するように機能する。
【００９８】
詳細なメッセージフローの例：
図１２Ａは、チップカード１５４０と、カード所有者クライアントシステム１５１０と、発行側アクセス制御サーバ１５２０との間の詳細なメッセージフローを示している。このメッセージフローは、チップカード支払認証プロセスを実施する方式を規定している。メッセージフローは、認証プロセスの各段階を下向きに進むトップダウン方式で構成される。
【００９９】
メッセージフローの説明：
このセクションは、図に示したＶＳＤＣ認証プロセスの各段階を、それが生じる順番で簡単に説明する。
４．２．１．１  ＶＳＤＣ認証要求：発行側ＡＣＳは、ＶＳＤＣ認証プロセスを開始する。
４．３．２．１  開始：カード所有者クライアントデバイスソフトウェアは、カードリーダにチップカードを挿入するようにカード所有者に指示する。
４．３．２．２  アプリケーションの選択：カード所有者クライアントデバイスソフトウェアは、チップカードからＶＳＤＣアプリケーションを選択する。
４．３．２．３  アプリケーションの開始：カード所有者クライアントシステムデバイスおよびチップカードは、ＶＳＤＣ認証プロセスを開始する。
４．３．２．４  アプリケーションデータの読み出し：カード所有者クライアントシステムデバイスは、チップカードからアプリケーションデータを読み出す。
４．３．２．５  カード所有者の検証（随意的）：カード所有者クライアントデバイスソフトウェアは、カード所有者を認証するためにオフラインでＰＩＮを検証する。
４．３．２．６  端末アクションの分析：カード所有者クライアントシステムデバイスは、暗号文を生成するようにチップカードに要求する。
４．３．２．７  完了：カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証のためのプロセスを完了して終結させる。
４．２．１．２  ＶＳＤＣ認証応答：カード所有者クライアントデバイスソフトウェアは、暗号文およびその他のデータを発行側ＡＣＳサーバに戻す。
【０１００】
次に、カード所有者クライアントデバイスソフトウェアとチップカードとの間におけるメッセージフローおよびそのフローの生成に携わる機能とが説明される。ＶＳＤＣ認証要求は、カード所有者クライアントデバイスソフトウェアを呼び出してプロセスを開始させるために、発行側アクセス制御サーバからカード所有者クライアントデバイスソフトウェアへと必要なデータを送信するメッセージである。ＶＳＤＣ認証応答は、カード所有者クライアントデバイスソフトウェアから発行側ＡＣＳへと暗号文およびその付属データを戻すメッセージである。
【０１０１】
次に、メッセージおよびプロセスフローの詳細が説明される。
【０１０２】
ＶＳＤＣ認証要求は、カード所有者クライアントデバイスソフトウェアを呼び出してＶＳＤＣ認証プロセスを開始させるメッセージである。このメッセージは、チップカードが暗号文を生成するために必要なデータを含む。
【０１０３】
発行側ＡＣＳは、必要なデータ、すなわち、許可された金額、アプリケーションＩＤ、（ＶＳＤＣアプリケーションの）アプリケーションラベル、優先アプリケーション名（application preferred name）、端末の国別コード、トランザクションの通貨コード、トランザクションの日付、トランザクションの種類、および予測不能の番号などを、取得するまたは生成することが好ましい。
【０１０４】
これらのデータのソースは、ＶＳＤＣ認証が働いている認証環境に依存して変化する。発行側ＡＣＳは、これらのデータをカード所有者クライアントデバイスソフトウェアに送信するために、ＶＳＤＣ認証要求を構築することが好ましい。このメッセージは、カード所有者クライアントデバイスソフトウェアとチップカードとの間でプロセスを開始するために、カード所有者クライアントデバイスソフトウェアを呼び出すことが好ましい。
【０１０５】
カード所有者クライアントデバイスソフトウェアは、開始プロセスを開始することが好ましい。
【０１０６】
４．２．１．２  ＶＳＤＣ認証応答：
ＶＳＤＣ認証応答は、暗号文およびその他の付属データを発行側ＡＣＳサーバに送信するメッセージである。ＶＳＤＣ認証応答メッセージは、また、ＶＳＤＣ認証プロセスの最中にエラーおよび例外が生じた場合に状況コードを送信するためにも使用される。ＶＳＤＣ認証応答メッセージは、また、アクセス制御サーバにカード所有者のパスワードを提供するためにも使用される。
【０１０７】
カード所有者クライアントデバイスソフトウェアは、次の表１で説明されたあらゆる必要データを取得することが好ましい。
【０１０８】
【表１】
0005025875.tif 000002
【０１０９】
カード所有者クライアントデバイスソフトウェアは、これらのデータを発行側ＡＣＳサーバに送信するために、ＶＳＤＣ認証応答メッセージを構築することが好ましい。
【０１１０】
発行側のＡＣＳサーバは、ＶＳＤＣ認証応答からデータを検索し、暗号文およびカード所有者のパスワードの両方の正当性を検査することが好ましい。発行側ＡＣＳサーバは、エラーまたは例外が生じた場合およびカード所有者クライアントデバイスソフトウェアとチップカードとの間で首尾よくプロセスが完了した場合に、ステータスコードを含んだＶＳＤＣ認証応答を受信する。発行側ＡＣＳサーバは、カード所有者クライアントデバイスソフトウェアからのデータを格納することによって、エラーおよび例外が生じた場合に、発行側がそれらの情報を使用して、チップカードとカード所有者クライアントデバイスソフトウェアとの間で生じたプロセスを分析し、カード所有者からの照会に応答できるようにして良い。
【０１１１】
発行側ＡＣＳでの随意的なプロセス：認証環境によって要求された場合は、発行側ＡＣＳは、認証結果をマーチャントまたは要求者に送信する必要があって良い。環境によっては、暗号文の認証が生じたことおよびそれが成功したか否かを表す指示を、発行側ＡＣＳが送信して良い場合もある。注記：カード所有者クライアントデバイスソフトウェアが、エラーまたはその他の要因を原因として時期尚早に終結された場合であっても、ＶＳＤＣ認証応答は、常に送信される。
【０１１２】
以下の説明は、チップカード上のＶＳＤＣアプリケーションとカード所有者クライアントデバイスソフトウェアとの間におけるメッセージフローおよびそのフローの生成に携わる機能を取り扱っている。先ず、カード所有者クライアントデバイスソフトウェア機能のプロセスフローからチップカードのメッセージフローまでの概要が提供される。機能とは、開始、アプリケーションの選択、アプリケーションの開始、アプリケーションデータの読み出し、カード所有者の検証、端末アクションの分析、そして完了である。
【０１１３】
開始は、カード所有者クライアントデバイスソフトウェアが、チップカードがカードリーダに挿入されていること、そしてプロセスのための準備が整っていることを、どのようにして保証するかを記述している。アプリケーションの選択は、カード所有者クライアントデバイスソフトウェアが、ＶＳＤＣ認証プロセスのためにチップカード上のＶＳＤＣアプリケーションを選択する動作にどのように進むかを記述している。アプリケーションの開始は、カード所有者クライアントデバイスソフトウェアが、チップカード上のＶＳＤＣアプリケーションをどのように開始させるかを記述している。アプリケーションデータの読み出しは、カード所有者クライアントデバイスソフトウェアが、ＶＳＤＣアプリケーションデータをチップカードからどのように読み出すかを記述している。カード所有者の検証は、カード所有者クライアントデバイスソフトウェアがカード所有者の検証をどのように実施するかを記述している。端末アクションの分析は、カード所有者クライアントシステムデバイスが、暗号文の生成をチップカードにどのように要求するかを記述している。完了は、カード所有者クライアントデバイスソフトウェアがチップカードプロセスをどのように終結させるか、そしてプロセスをどのように終了させるかを記述している。
【０１１４】
次に、各フローおよびメッセージが詳細に説明される。
【０１１５】
４．３．２．１  開始：開始の段階は、２つの小段階からなる。１つは、カードホルダクライアントデバイス上のカード環境のための開始であり、もう１つは、チップカードのための開始である。
【０１１６】
カード所有者クライアントデバイスソフトウェアは、カードリーダとそれをイネーブルするために必要な任意の関連のデバイスサポートソフトウェアが、カードを挿入される準備が整っていることを、その環境において、可能な限りに保証することが好ましい。カード環境の準備が整っていない場合は、カード所有者クライアントデバイスソフトウェアは、カード所有者クライアントデバイスにおいて条件が正しくセットアップされているか否かを検証するために、カード所有者と通信することが好ましい。カード所有者との通信は、カードリーダが正しく取り付けられているか否か、電源が入っているか否か、そして正しいバージョンのカードリーダドライバソフトウェアがインストールされているか否かなどの質問を尋ねることを含んで良い。カード環境の準備を整えられないことが決定された場合は、カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証プロセスを終結させて良い。プロセスを終結させるとき、カード所有者クライアントデバイスソフトウェアは、後続の動作を全て省略し、適切なステータスコードとともにＶＳＤＣ認証応答メッセージを発行側サービスに戻すことが好ましい。
【０１１７】
小段階「４．３．２．１．２  チップカードのための開始」が失敗した場合は、制御はこの小段階に戻って良く、すると、カード所有者クライアントデバイスは、チップカードを挿入するようにカード所有者に指示する。カードの挿入を要求し、再び「チップカードのための開始」に戻った後に、チップカードが応答に失敗した場合は、カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証プロセスを終結させて良い。ＶＳＤＣ認証プロセスを終結させるとき、カード所有者クライアントデバイスソフトウェアは、後続の段階を全て省略し、適切なステータスコードとともにＶＳＤＣ認証応答メッセージを発行側ＡＣＳ送信することが好ましい。
【０１１８】
チップカードのための開始：この小段階において、カード所有者クライアントデバイスソフトウェアは、プロセスのための準備が整っているか否かを決定するために、チップカードと通信する。
【０１１９】
カード所有者クライアントデバイスソフトウェアは、チップカードをリセットすることが好ましい。チップカードは、リセット応答（ＡＴＲ：Answer To Reset）をカード所有者クライアントデバイスソフトウェアに戻すか、またはＡＴＲを戻すことに失敗する。
【０１２０】
ＡＴＲを受信したカード所有者クライアントデバイスソフトウェアは、次の段階すなわちアプリケーションの選択に進む。チップカードが、基準によって設定された時間内にＡＴＲを戻さない場合は、カード所有者クライアントデバイスソフトウェアは、「４．３．２．１．１  カード所有者クライアントデバイス上のカード環境のための開始」に戻るか、またはＶＳＤＣ認証プロセスを終結させて良い。ＶＳＤＣ認証プロセスを終結させるとき、カード所有者クライアントデバイスソフトウェアは、後続の段階を全て省略し、適切なステータスコードとともにＶＳＤＣ認証応答メッセージを発行側サーバに送信することが好ましい。
【０１２１】
４．３．２．２  アプリケーションの選択：
アプリケーションの選択は、カード所有者クライアントデバイスソフトウェアがチップカードからＶＳＤＣアプリケーションを選択するプロセス段階である。
【０１２２】
カード所有者クライアントデバイスソフトウェアにおけるプロセスは、以下の段階を含む。
【０１２３】
（ａ）カード所有者クライアントデバイスソフトウェアは、アプリケーションの選択を実施することが好ましい。
【０１２４】
（ｂ）セキュリティの要件に応じるため、カード所有者クライアントデバイスソフトウェアは、明示的な選択方式のみを使用し、ＶＳＤＣ認証要求によって供給されたように、SELECTコマンドをＡＩＤ（アプリケーションＩＤ）とともに送信することが好ましい。
【０１２５】
（ｃ）第１のSELECTコマンドに対する応答が、接尾部（suffix）をともなわないＡＩＤを戻す場合は、カード上の要求されたＡＩＤに関し、１つのアプリケーションインスタンスのみが存在する。プロセスは、後述する段階（ｇ）に続く。
【０１２６】
（ｄ）第１のSELECTコマンドに対する応答が、接尾部をともなったＡＩＤを戻し、カード上の要求されたＡＩＤに関し、複数のアプリケーションインスタンスが存在することが示された場合は、プロセスは、後述する段階（ｅ）〜（ｇ）に進む。
【０１２７】
（ｅ）要求されたＡＩＤに関し、戻すべきアプリケーションインスタンスがこれ以上存在しないことが、カードによって示されるまで、（ＶＳＤＣ認証要求によって供給された）ＡＩＤを使用し、一連のSELECTコマンドが発行される。各ＡＩＤが戻されるたびに、カード所有者クライアントデバイスソフトウェアは、各ＡＩＤに対応するアプリケーションラベルおよび優先アプリケーション名をともなったＡＩＤのリストを作成する。
【０１２８】
（f）ＶＳＤＣ認証要求によって供給されたアプリケーションラベルと優先アプリケーション名とを使用して、カード所有者クライアントデバイスソフトウェアは、従来の突き合わせの段階で作成されたリストを検索する。SELECTコマンドは、一致したリスト入力のＡＩＤを使用して、カードに対して発行される。一致するリストが見つからなかった場合は、後述する「例外処理」に示したように、ＶＳＤＣ認証応答によって戻すための適切なステータスコードが設定される。
【０１２９】
（ｇ）カード所有者クライアントデバイスソフトウェアのためのアプリケーションの選択が完了する。カード上に、適格なアプリケーションが１つだけ存在していた場合は、上述した段階（ｃ）において、既に選択済みである。あるいは、上述した段階（ｆ）において、複数の適格なアプリケーションのなかから１つを選択することが、既に決定済みである。
【０１３０】
（ｈ）カード所有者クライアントデバイスソフトウェアおよびチップカードが、ＶＳＤＣ以外にも複数のアプリケーションをサポートしている場合は、他のアプリケーションをどの順序で実行するかは、発行側の責任において決定される。
【０１３１】
チップカードは、アプリケーションの選択を実施する。
【０１３２】
例外処理：ＶＳＤＣアプリケーションが見つからなかった場合は、カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証プロセスを終結させることが好ましい。ＶＳＤＣ認証プロセスを終結させるとき、カード所有者クライアントデバイスソフトウェアは、後続の段階を全て省略し、適切なステータスコードとともにＶＳＤＣ認証応答を発行側サーバに送信することが望ましいことが好ましい。
【０１３３】
４．３．２．３  アプリケーションの開始：
アプリケーションの開始は、トランザクション処理が開始することを、カード所有者クライアントデバイスソフトウェアがチップカードにシグナル通知するプロセス段階である。
【０１３４】
カード所有者クライアントデバイスソフトウェアは、アプリケーションを開始することが好ましい。カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣアプリケーションを開始するために、GET PROCESSING OPTIONSコマンドをチップカードに送信することが好ましい。
【０１３５】
チップカードは、GET PROCESSING OPTIONSコマンドに応答する。
【０１３６】
カード所有者クライアントデバイスソフトウェアは、後の段階においてＶＳＤＣ認証応答を構成するために使用されるアプリケーション交換プロファイルを格納することが好ましい。地理的制約の執行は、ＶＳＤＣアプリケーションのオプション機能の１つである。
【０１３７】
チップカードが、使用条件が満たされていないことを示すエラーコードでもってGET PROCESSING OPTIONSコマンドに応答する場合は、ＶＳＤＣ認証プロセスは、終結させなければならない。
【０１３８】
カードがトランザクションを終結させるときには、カード所有者クライアントソフトウェアデバイスは、後続の段階を全て省略し、適切なステータスコードとともにＶＳＤＣ認証応答メッセージを発行側サーバに送信することが好ましい。
注記：ＶＳＤＣ認証プロセスの終結後にどのような処置を取るかを決定するのは、発行側の責任である。このような決定およびその結果として生じる処置は、本明細書の範囲外である。
【０１３９】
４．３．２．４．  アプリケーションデータの読み出し：アプリケーションデータの読み出しは、カード所有者クライアントデバイスソフトウェアがチップカード上のＶＳＤＣアプリケーションファイルの記録を読み出すプロセス段階である。
【０１４０】
カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣアプリケーションデータを読み出すことが好ましい。カード所有者クライアントデバイスソフトウェアは、必要なデータをＶＳＤＣアプリケーションから検索するために、READ RECORDコマンドを送信することが好ましい。カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証応答を構成するために後ほど使用するために、ＰＡＮシーケンス番号の値を保持することが好ましい。
【０１４１】
ＶＳＤＣアプリケーションは、READ RECORDコマンドに応答する。
【０１４２】
４．３．２．５   カード所有者の検証：カード所有者の検証は、カード所有者クライアントデバイスソフトウェアがオフラインのＰＩＮ検証方式を使用してカード所有者を検証して良いプロセス段階である。注記：カード所有者の検証は、適切なＶｉｓａセキュリティガイドラインにしたがって実装しなければならない。
【０１４３】
実行の条件：この段階は、条件付きである。つまり、カード上およびカード所有者クライアントデバイスソフトウェア内に、カード所有者の検証が実装され、利用可能である場合にのみ、この段階が必要とされる。
【０１４４】
カード所有者クライアントデバイスソフトウェアは、オフラインの非暗号化テキストＰＩＮ検証方式を使用してカード所有者を検証することが好ましい。オフラインの暗号化ＰＩＮ検証方式も、オンラインのＰＩＮ検証も、いずれもサポートされていない。
【０１４５】
チップカードは、オフラインの非暗号化テキストＰＩＮ検証を実施する。第１のGENERATE ACコマンドに応じて、チップカードは、オフラインのＰＩＮ検証結果をＣＶＲに供給する。
【０１４６】
４．３．２．６  端末アクションの分析：端末アクションの分析は、カード所有者クライアントデバイスソフトウェアが暗号文の生成をチップカードに要求するプロセス段階であり、この暗号文は、正当性検査のために発行側サーバに送信される。
【０１４７】
カード所有者クライアントデバイスソフトウェアは、端末アクションの分析を実施することが好ましい。カード所有者クライアントデバイスソフトウェアは、上述した「マーチャントＰＯＳ端末」の役割を果たし、以下の例外を除き、あたかも端末であるかのように振舞うことが好ましい。
【０１４８】
（ａ）発行側アクションコードおよび端末アクションコードの処理：カード所有者クライアントデバイスソフトウェアは、端末の正当性検査の結果を、チップカードの発行側アクションコードまたは端末アクションコードと比較しないことが好ましい。
【０１４９】
（ｂ）GENERATE ACコマンド：カード所有者クライアントデバイスソフトウェアは、ＡＲＱＣのみを要求することによってGENERATE ACコマンドを構成する、つまり、端末アクション分析の最中にＡＡＣまたはＴＣを要求してはいけないことが好ましい。
【０１５０】
端末の正当性検査の結果（ＴＶＲ）値：端末の正当性検査の結果は、カード所有者クライアントデバイスによって実施された様々なアプリケーション機能の結果の記録である。ＰＯＳ端末における標準的なＶＳＤＣプロセスと異なり、これらの値のなかには、ＶＳＤＣ認証に対して静的であるものもある。ビットに割り当てられる静的な値が、以下に示される。値を動的に設定されるビットは、ＶＳＤＣ認証プロセスの最中にカード所有者クライアントデバイスによって設定される。
【０１５１】
チップカードは、暗号文を生成する。
【０１５２】
４．３．２．７  完了：完了は、カード所有者クライアントデバイスソフトウェアがチップカードの処理を終結させるプロセス段階である。
【０１５３】
プロセスのバリエーション：カード所有者クライアントデバイスソフトウェアのプロセスは、GENERATE AC応答メッセージに基づいて変動することが好ましい。カード所有者クライアントデバイスソフトウェアは、完了を実施することが好ましい。ＶＳＤＣアプリケーションは、カード所有者クライアントデバイスソフトウェアが、オンライン許可のための第１のGENERATE ACコマンド（ＡＲＱＣ）を発行する場合であっても、トランザクションをオフラインで拒否する権限（ＡＡＣ）を、チップカードに提供する。したがって、クライアントカード所有者デバイスソフトウェアは、チップカードがＶＳＤＣ認証プロセスの最中にＡＲＱＣまたはＡＡＣのいずれを戻すかを、予測することが望ましい。発行側ＡＣＳは、GENERATE ACの結果がＡＲＱＣまたはＡＡＣのいずれであるかを決定するために、ＣＶＲをチェックすることができる。
【０１５４】
チップカードからの応答が、オフラインへ拒否（ＡＡＣ）である場合であっても、ＶＳＤＣ認証は、プロセスを続行することが好ましい。プロセスを続行することができるのは、たとえ応答によって拒否が示された場合であっても、戻された暗号文はカードの認証のために使用できるためである。ＶＳＤＣ認証は、暗号文の種類にかかわらず、カードを認証するための暗号文を必要とする。
【０１５５】
４．３．２．７．１  カードの応答がＡＲＱＣである場合：
この小セクションは、チップカードが許可要求暗号文（ＡＲＱＣ）を戻すときのプロセスフローを説明する。ＶＳＤＣ認証に関しては、許可が要求されず、尚且つＶＳＤＣ認証が常に「オンライン」プロセスであるので、このような変換処理は無関係である。GENERATE ACコマンドを発行する目的は、正当性検査のための暗号文をカードに戻させることにある。
【０１５６】
ＡＲＱＣをともなった第１のGENERATE AC応答をチップカードから受信した後、カード所有者クライアントデバイスソフトウェアは、以下のことを実施することが好ましい。
【０１５７】
発行側サーバに送信するために、カード所有者クライアントデバイスソフトウェアが保持することが望ましいのは、チップカードから送信された以下のデータエレメント以外は暗号文のみである。表２を参照のこと。
【０１５８】
【表２】
0005025875.tif 000003
【０１５９】
カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証応答を作成および送信する後続の段階のために必要な情報を、格納することが好ましい。あたかも、発行側によって承認されていないトランザクションが、オンラインの許可応答によって示されているかのように、カード所有者クライアントデバイスソフトウェアは、次いで、チップカードに対して最終のGENERATE ACコマンドを発行することが好ましい。これは、カード所有者クライアントデバイスソフトウェアがＡＡＣを要求することを意味する。注記：ＶＳＤＣ認証プロセスにおいて、与信要求／応答メッセージは存在しない。
【０１６０】
ＣＤＯＬ２に列挙されたデータのソース：カード所有者クライアントデバイスソフトウェアが、最終のGENERATE ACコマンドのデータフィールドによってチップカードに送信するデータエレメントは、次の表３に示したソースから取得することが好ましい。
【０１６１】
【表３】
0005025875.tif 000004
【０１６２】
チップカードは、最終のGENERATE ACコマンドに対する応答を、ＡＣＣとともに戻す。
【０１６３】
カード所有者クライアントデバイスソフトウェアは、チップカードから最終のGENERATE ACコマンドへの応答を無視することが好ましい。カード所有者クライアントデバイスソフトウェアは、チップカードから受信された無関係のデータをメモリから消去することによって、セキュリティの要件に従うことが好ましい。
注記：この時点では、前の段階からの全ての未使用データが、セキュリティの要件に従うために消去されたものと仮定される。
【０１６４】
カードの応答がＡＡＣである場合」
この小セクションは、チップカードがアプリケーション認証暗号文（ＡＡＣ）を戻す場合のプロセスフローを説明する。ＶＳＤＣ認証に関しては、許可が要求されないので、このような変換処理は無関係である。GENERATE ACコマンドを発行する目的は、チップカードの認証のためにカードに暗号文を戻させることにある。
【０１６５】
第１のGENERATE ACコマンドに対する応答として、チップカードからＡＡＣを受信した後、カード所有者クライアントデバイスソフトウェアは、以下の機能を実施することが好ましい。カード所有者クライアントデバイスソフトウェアは、チップカードから送信された暗号文およびその他の情報を、発効側ＡＣＳに送信するために保持することが好ましい。カード所有者クライアントデバイスソフトウェアは、ＶＳＤＣ認証応答を送信するための準備を整えることが好ましい。カード所有者クライアントデバイスソフトウェアは、チップカードから受信されたあらゆる段階のあらゆるデータを消去することが好ましい。
【０１６６】
アクセスアプリケーションをともなったチップカードの実施形態：
図１２Ａのメッセージフローの説明が完了したので、次に、アクセスアプリケーションを利用したチップカードデバイスの実施形態が開示される。
【０１６７】
チップカードシステムに関するもう１つの実施形態は、チップカードシステムの追加特徴として随意的に使用できるアクセスアプリケーションを含む。アクセスアプリケーションは、チップカードおよびチップカード上に存在し得る複数のアプリケーションへのアクセスを制御するために使用される。アクセスアプリケーションは、「アクセスアプリケーションまたはアプレット」と称することができる。アクセスアプリケーションは、チップカード上に存在する他のアプリケーションへのアクセスを制御する。アクセスアプリケーションは、このように、チップカードおよびそれに関連付けられたアプリケーションを利用しようと試みる人物のＩＤを検証することができる。チップカードを使用しようと試みる人物が、正しいユーザＩＤ番号すなわちストリングとパスワードとを入力した場合は、そのチップカードを使用しようとしているのは、許可済みの人物であることが推定される。この場合、アクセスアプリケーションは、チップカード上の全てのアプリケーションをアンロックし、それらを使用可能にする。アクセスアプリケーションは、アプリケーションをアンロックする以外に、チップカード上の使用可能なアプリケーションのためのパスワードも作成する。アクセスアプリケーションの実施形態のなかには、アクセスアプリケーションに応じて正しい情報が入力された後に、選ばれた一定数のアプリケーションのみをアンロックするものもある。
【０１６８】
カード所有者が入力し且つ／または発行側ＡＣＳがチェックするパスワードすなわち秘密値に対し、数多くの参照がなされる。表４に示したように、秘密＃１、＃２、＃３は異なる値である（そしていずれも金融ＡＴＭすなわちＰＯＳ  ＰＩＮではない）。
【０１６９】
【表４】
0005025875.tif 000005
【０１７０】
図１３は、チップカードおよび汎用アクセスアプリケーションを使用した支払人認証サービスで利用されるコンポーネントの系統図である。図１３の系統図は、チップカード１５４０と、チップカードリーダ１５１８と、カード所有者クライアントデバイス１２２と、アクセス制御サーバ１１４と、データベース１２４０とを示している。チップカード１５４０は、アクセスアプレット１２０２と、チップカードクレジット・デビットアプリケーション１２０４とを含む。アクセスアプレット１２０２は、チップカード上の様々なアプリケーションをアンロックするために使用されるパスワードすなわち秘密＃２を格納する。カード所有者クライアントデバイスは、支払人認証アプリケーション１５４２を含む。
【０１７１】
オンライン購入トランザクションを行うにあたり、アクセスアプレット１２０２は、ユーザＩＤおよびパスワードすなわち秘密＃１を入力するようにカード所有者に指示する。カード所有者が、正しいユーザＩＤおよびそれに関連付けられたパスワードを入力した場合は、チップカード上のアプリケーションをアンロックするために、秘密＃２が自動的に使用される。チップカードシステムを利用したＰＡＳシステムは、次いで、本明細書において前述したように進行することができる。
【０１７２】
次の詳細な記述は、カード所有者クライアントデバイスソフトウェアによってサポートすることが望ましいプロセスおよびコマンドに関して説明する。カード所有者クライアントデバイスソフトウェアは、チップカードリーダと、カード所有者のインターネットブラウザと、ＡＣＳとの間の通信を促進する。
【０１７３】
先ず、様々な基本プロセスおよびコマンドが説明される。第１に、カード所有者クライアントデバイスソフトウェアは、ＡＣＳサーバからのメッセージによってアクティブにされる（クライアントは、例えば３０分後にタイムアウトするなどのタイムアウト特性を実装することもできる）。次いで、カード所有者クライアントデバイスソフトウェアは、対応するチップリーダの存在をチェックし、チップに基づく支払人認証トランザクションのプロセスが可能であることをＡＣＳに応答する。カード所有者クライアントデバイスソフトウェアは、チップカードプログラム（例えばＶＳＤＣアプリケーション）による暗号文の生成をイネーブルするために、適切なマーチャントおよびＡＣＳデータを含むＡＣＳからのメッセージを受信する。このようなチップカードプログラムの一例として、ＶｉｓａによるEuropay・Mastercard・Visa（ＥＭＶ）チップカード標準の実装例であるVisa Smart Debit Creditアプリケーション（ＶＳＤＣ）が挙げられる。暗号文は、カードによって生成され、尚且つカードおよび各トランザクションに特有の暗号値である。ＡＣＳは、ハードウェアセキュリティモジュール内の暗号キーを使用している暗号文の正当性を検査することができる。なお、ＶＳＤＣアプリケーションは、レンガ＆モルタルＰＯＳマーチャントの対面トランザクションで使用されるアプリケーションと同一のアプリケーションである。
【０１７４】
ＡＣＳからメッセージを受信した後、カード所有者クライアントデバイスソフトウェアは、定義済みのデータエレメントのなかに秘密＃２およびＵＩＤが存在するかどうかをチェックする。これらが使用可能でない場合は、カード所有者クライアントデバイスソフトウェアは、チップカードを挿入し秘密＃１を入力することによって、チップカードアクセスアプリケーションに照らした正当性検査を行い、秘密＃２およびユーザＩＤ（ＵＩＤ）を検索するように、カード所有者に要求する。
【０１７５】
チップに基づく支払人認証に対してカード所有者が正当であるとされた場合は、カード所有者クライアントデバイスソフトウェアは、暗号文およびそれに関連のデータを取得してオンラインのチップカード認証を実施するために、ＶＳＤＣ購入トランザクションを実行する。
【０１７６】
ＶＳＤＣ購入トランザクションの実行は、カード所有者クライアントデバイスソフトウェアおよびＶＳＤＣチップアプリケーションのそれぞれによって実施される複数の動作を含む。カード所有者クライアントデバイスソフトウェアは、明示的な選択方式を使用し、１つまたはそれ以上のSELECTコマンドを発行することによって、アプリケーションの選択を実施する。また、アプリケーションの選択からのファイル制御情報（ＦＣＩ）のなかに、ＰＤＯＬが存在していた場合は、カード所有者クライアントデバイスソフトウェアは、ＰＤＯＬを含むGET PROCESSING OPTIONSコマンドを発行する。次いで、ＶＳＤＣチップアプリケーションは、GET PROCESSING OPTIONSコマンドに対する応答として、アプリケーションファイルロケータ（ＡＦＬ）およびアプリケーション交換プロファイル（ＡＩＰ）を戻す。
【０１７７】
カード所有者クライアントデバイスソフトウェアは、ＡＦＬによって指定されたＶＳＤＣチップアプリケーションの記録を読み出すために必要なREAD RECORDコマンドを発行する。注記：チップは、インターネットによる支払認証のために使用されるデータ以外に、ＶＳＤＣ購入トランザクションを完了するために必要なあらゆるデータも戻す。カード所有者クライアントデバイスソフトウェアは、正しいデータを構文解析することが望ましい。カード所有者クライアントデバイスソフトウェアは、次いで、プロセス制約のチェック、ＣＶＭリスト迂回プロセス、ならびに下限額および新規カードのチェックを除く端末リスク迂回管理を実施する。全てのトランザクションは、下限額を上回る。カード所有者クライアントデバイスソフトウェアは、下限額超過ＴＶＲトランザクションビット（TVR Transaction Exceeds Floor Limit ビット）を「１」に設定する。カード所有者クライアントデバイスソフトウェアは、端末アクションの分析を実施し、GENERATE ACコマンドのなかで常にＡＲＱＣ（オンライン）暗号文を要求する。このコマンドは、トランザクションの期日およびＡＣＳからの予測不能番号を含むＣＤＯＬ１データを含む。カード所有者クライアントデバイスソフトウェアは、次いで、チップによって戻された暗号文とその付属データとを、正当性検査のために、変更しないままの状態でＡＣＳに引き渡す。最後に、カード所有者クライアントデバイスソフトウェアは、ＡＡＣを要求するGENERATE ACコマンドを発行する。これは、ＶＳＤＣカードアプリケーション上のトランザクションを終結させる。第２のGENERATE ACコマンドが発行された後は、トランザクションからの全ての情報が、カード所有者クライアントデバイスソフトウェアから忘却されることが望ましい。
【０１７８】
以下のプロセスは、マーチャントプラグインがPAReqメッセージをＡＣＳに転送した後に生じる。先ず、ＡＣＳは、カード所有者のＰＣがチップ対応であるか否かを決定することが望ましい。（注記：ＰＡＮは、チップ対応のものとして登録して良いが、この動作は、トランザクションで現在使用されているＰＣがチップリーダを有さないまたはチップ対応でないような状況で必要とされる。）ＰＣがチップ対応でないまたはチップが可読でない状況において、ＡＣＳは、発行側が２つの異なるアクションを構成できるようにすることが望ましい。
【０１７９】
オプション＃１：カード所有者に秘密＃３（カード所有者のＰＡＳパスワード）を要求する。オプション＃２：カード所有者またはチップカードの認証を何ら実施せず、PAResトランザクション状況フィールドを「不適応」応答で満たす。ＡＣＳは、あらゆる適切なマーチャント情報をPAReqから抽出し、このデータと適切なＡＣＳ情報とをカード所有者クライアントデバイスソフトウェアに提供することが望ましい。これらのデータは、チップカードに暗号文の生成を要求するために必要とされる。
【０１８０】
ＡＣＳは、次いで、暗号文をサポートするための情報をカード所有者のカード所有者クライアントデバイスソフトウェアに送信し、秘密＃２と固有ＩＤ（ＵＩＤ）とを求める要求を送信する。カード所有者クライアントデバイスソフトウェアは、事前に実施されたチップ対応のチェックアウトプロセスから秘密＃２（パスワード）およびＵＩＤを取得するアプリケーションを呼び出す。この手続きを介して秘密＃２を得られない場合は、カード所有者クライアントデバイスソフトウェアは、アクセスアプレットを呼び出すことによって、チップカードから秘密＃２を取得する。このアプレットは、秘密＃１を入力してアプレットをアクティブにするようにカード所有者に要求し、チップカード上のアクセスアプレットのなかから秘密＃２およびＵＩＤを取得する。チップカード上にアクセスアプレットが存在しない場合は、カード所有者クライアントデバイスソフトウェアは、秘密＃３（カード所有者のＰＡＳパスワード）を入力するようにカード所有者に要求する。
【０１８１】
秘密＃２およびＵＩＤが取得された後、カード所有者クライアントデバイスソフトウェアは、暗号文要求を生成してチップカードから暗号文を取得するために、ＶＳＤＣトランザクションを開始する。秘密＃２が取得されなかった（すなわちカード所有者の正当性が認められなかった）場合は、カード所有者クライアントデバイスは、ＶＳＤＣアプレットを呼び出さない。
【０１８２】
カード所有者クライアントデバイスソフトウェアは、ＡＣＳがＡＣＳに照らして暗号文の正当性を検査できるように、秘密＃２と、暗号文と、付属データとをＡＣＳに戻す。ＡＣＳは、カード所有者クライアントデバイスソフトウェアの入力を受け取り、アカウント所有者データベースに照らしてその正当性を検査する。一次アカウント番号（ＰＡＮ）に対応する入力（秘密＃２）が、アカウント所有者データベースに複数存在する場合は、そのなかに、カード所有者クライアントデバイスソフトウェアによってＡＣＳに送信された秘密＃２と一致する入力（秘密＃２）があるかどうかに関し、カード所有者の正当性検査が行われる。
【０１８３】
ＡＣＳは、暗号文を複製し、それをカード所有者クライアントデバイスソフトウェアによってＡＣＳに送信されたチップカードからの暗号文と比較することによって、カードの正当性を検査する。ＡＣＳは、PAResメッセージを作成し、全てを満たし、そのPAResメッセージをカード所有者のブラウザを通した接続を介してマーチャントに戻す。
【０１８４】
ＡＣＳは、PAResにデジタル署名し、PAResトランザクション状況と、トランザクション詳細と、ＥＣＩと、値と、カードの種類を示すチップカードコードと、支払条件と、カードの認証結果とを設定し、署名済みのPAResをマーチャントに戻し、受領マネージャ１３１へのSaveReceiptメッセージ’（SaveReceiptメッセージはPATransメッセージとも称される）を生成する。
【０１８５】
２種類のチップカードが、Visa Smart Debit/Credit（ＶＳＤＣ）アプリケーションを実行する。１つ目は、アクセスパスワードまたは秘密＃１を使用しカード上のアクセスアプリケーションを介してカード所有者（支払人）の正当性をオフラインで検査することができるカードである。アクセスパスワードは、カード所有者から取得され、ブラウザ上のカード所有者クライアントデバイスソフトウェアに引き渡される。供給されたアクセスパスワードが正しい場合は、チップカードアクセスアプリケーションは、秘密＃２およびＵＩＤをカード所有者クライアントデバイスソフトウェアに戻す。２つ目は、カード所有者（支払人）の正当性をオフラインで検査することができないカードである（すなわちＶＳＤＣアプリケーションのみを含んだカードである）。この場合、ブラウザ上のカード所有者クライアントデバイスソフトウェアは、カード所有者に秘密＃３（カード所有者のパスワード）を要求し、秘密＃３は、カード所有者の認証を達成するためにＡＣＳに供給される。
【０１８６】
次に、ＡＣＳから制御を引き継いだ後（ＡＣＳがマーチャントプラグインからPAReqメッセージを受信した後）のカード所有者クライアントデバイスソフトウェアに関連したフローが開示される。カード所有者クライアントデバイスソフトウェアは、カード所有者のＰＣがチップカード対応である（チップカードリーダとクライアントソフトウェアコンポーネントとが存在している）か否かを先ず決定することが望ましい。チップカード対応でない場合は、トランザクションは、コア支払人認証を介して処理される。ＰＣがチップカード対応である場合は、動作２において、チップカード上のアクセスアプリケーションを介して秘密＃２が取得されるか、またはカード所有者に対するプロンプトを介して秘密＃３が取得される。
【０１８７】
秘密＃２およびＵＩＤすなわち秘密＃３が供給された場合は、磁気ストライプイメージ（ＭＳＩ）データエレメントを検索するため、ＡＣＳが暗号文を再生成するために必要なチップデータを検索するため、そしてＡＲＱＣ暗号文を生成するために、チップカード上のＶＳＤＣアプリケーションが呼び出される。秘密＃２または秘密＃３が供給されなかった場合は、ＶＳＤＣアプレットは呼び出されない。
【０１８８】
次のデータが、カードの認証のためにＡＣＳに送信される：ＡＲＱＣ暗号文、磁気ストライプイメージ（ＭＳＩ）、ＡＣＳによる暗号文の再生成をサポートするためのデータ。ＭＳＩデータは、随意的に読み出すこともできる。
【０１８９】
次いで、秘密＃２およびＵＩＤすなわち秘密＃３が、カード所有者の認証のためにＡＣＳに送信される。
【０１９０】
一般に、チップカード所有者は、カードが実際に存在しなくても、コア支払人認証（チップカードおよびチップカードリーダコンポーネントをともなわないＰＡＳ）を介してインターネット上で購入トランザクションを実施することが可能である。また、発行側によって配布されたカード所有者クライアントデバイスソフトウェアは、あらゆるタイプのＶＳＤＣカードをサポートすることが望ましい。認証は、フルバージョンおよびリミテッドバージョンのVisa Smart Debit/Creditアプレットを実装するチップに基づく支払アプリケーションに適合することが望ましい。先ず、配備されたチップに基づく支払アプリケーションは、限られたＶＳＤＣ特徴をオープンプラットフォームカード上でサポートする。この限られたＶＳＤＣ支払アプレットすなわち「ジャンプスタート」は、ＭＳＩ、オンラインカード認証、およびオフライン静的データ認証（ＳＤＡ）の「フル」ＶＳＤＣ特徴からなるサブセットをサポートする。しかしながら、ＳＤＡは、インターネットトランザクションの最中には実施されない。トランザクションからの情報は、トランザクションの終了時（PAResメッセージがマーチャントに送信された時点など）には、支払人認証カード所有者クライアントデバイスソフトウェアから全て忘却されることが望ましい。
【０１９１】
ＡＣＳは、カード所有者クライアントデバイスソフトウェアが使用可能でない場合またはカード所有者クライアントデバイスソフトウェアがチップカードを読み出すことができない場合に、異なるアクションを取ることができるように、発行側によって構成することができる。オプション＃１は、秘密＃３またはオプション＃２を手動で入力するように、ＡＣＳがカード所有者に指示し、オプション＃２は、認証は行われずに「不適応」応答がマーチャントに戻される。
【０１９２】
チップカード所有者は、カードが実際に存在しない場合であっても、（例えばカード所有者クライアントデバイスソフトウェアおよびチップカードリーダをともなわない異なるＰＣから）、インターネットで購入トランザクションを実行することが可能である。カード所有者は、マーチャントチェックアウトフォームに手動で記入し（または他の非チップ方式を使用し）、そして発行側が選択するアプローチに応じ、手動で秘密＃３を入力するようにＡＣＳから指示される。
【０１９３】
好ましい支払ネットワーク：
図１４は、本発明の実施形態を実現するのに適した通信ネットワーク８００を示している。本発明は、任意の適切な通信ネットワークを使用して良く、後述するものと異なるハードウェア、ソフトウェア、および／またはプロトコルを含んで良い。後述するネットワークは、図１の通信ネットワーク１２６の好ましい一実施形態である。ネットワーク８００は、任意のバンクカード、トラベルおよびエンターテイメントカード、ならびに他の自社ブランドおよび自社所有のカードを使用した購入およびキャッシュトランザクションをサポートするグローバル通信ネットワークである。また、ネットワークは、他のネットワークのためのＡＴＭトランザクション、小切手を使用したトランザクション、スマートカードを使用したトランザクション、および他の金融商品を使用したトランザクションをもサポートする。
【０１９４】
これらのトランザクションは、ネットワークの許可（オーソライゼーション）、決済、および清算のサービスを通して処理される。許可サービスは、購入が終了されるまたはキャッシュが消費される前に、発行側が販売トランザクションを承認するまたは拒否させる場合に行われる。決済サービスは、顧客のアカウントに通知するために、決済側から発行側へとトランザクションが送信される場合に行われる。清算サービスは、決済される全てのトランザクションに関し、各メンバの正味の財務状況を計算および決定するプロセスである。資金の実際の交換は、別のプロセスである。
【０１９５】
トランザクションは、デュアルメッセージまたはシングルメッセージトランザクションのいずれかのかたちで許可、決済、および清算することができる。デュアルメッセージトランザクションは、２回送信される。つまり、１回目は、許可決定のために必要とされる情報のみが送信され、２回目は、決済および清算のための追加情報が送信される。シングルメッセージトランザクションは、許可のために１回送信されるのみであり、決済および清算情報をも含んでいる。一般に、許可、決済、および清算は、全てオンラインで生じる。
【０１９６】
通信ネットワーク８００の主なコンポーネントは、交換センタ８０２、アクセスポイント８０４，８０６、および処理センタ８０８，８１０である。ネットワークには、名宛銀行および第三者の許可エージェントなどの他のエンティティが、アクセスポイントを通して接続しても良い。交換センタは、世界中の任意の場所に設けられたデータ処理センタである。一実施形態において、交換センタは、米国に２ヶ所と英国および日本国に１ヶ所ずつである。各交換センタは、ネットワークトランザクションプロセスを実施するコンピュータシステムを収容している。交換センタは、ネットワーク通信施設のための制御ポイントとして機能し、これらの通信施設は、ＩＢＭ  ＳＮＡプロトコルに基づいた高速専用回線または衛星回線を備える。交換センタを遠隔地の主体に接続する回線８２０，８２２は、ＩＢＭ  ＳＮＡ−ＬＵ０通信プロトコルに基づいた専用の高帯域電話回線または衛星回線を使用する。メッセージは、ＩＳＯ  ８５８３標準の任意の適切な実装を使用して、これらの回線内を送信される。
【０１９７】
アクセスポイント８０４または８０６は、一般に、処理センタに設けられ、処理センタのホストコンピュータと交換センタとの間のインターフェースとして機能する小型のコンピュータシステムである。アクセスポイントは、ホストと交換センタとの間でのメッセージおよびファイルの伝送を促進し、トランザクションの許可、決済、および清算をサポートする。リンク８２６，８２８は、センタ内のローカルリンクであるのが通常であり、センタが好むプロプライエタリメッセージフォーマットを使用している。
【０１９８】
（決済側、発行側、またはその他の主体の側に設けられたような）データ処理センタは、マーチャントおよびビジネスロケーションをサポートする処理システムを収容し、顧客データおよび請求システムを維持する。各処理センタは、１ヶ所または２ヶ所の交換センタにリンクされていることが好ましい。プロセッサは、最も近い交換センタに接続されており、割り込みが生じたとき、ネットワークは、トランザクションを二次の交換センタへと自動的にルーティングする。各交換センタは、また、他の全ての交換センタにもリンクされている。このリンクは、処理センタが１ヶ所またはそれ以上の交換センタを通して互いに通信しあうことを可能にする。また、処理センタは、交換センタを通して他のプログラムのネットワークにアクセスすることもできる。ネットワークは、さらに、全てのリンクが複数のバックアップを有することを保証する。ネットワークの一地点から別の地点への接続は、固定リンクではないのが一般的であり、その代わり、交換センタが、可能な経路のなかから最適な経路を任意の所定のトランザクション時に選択する。障害のある任意のリンクを避ける再ルーティングは、自動的に生じる。
【０１９９】
図１５は、交換センタのなかに収容され、オンラインおよびオフラインのトランザクション処理を提供するシステム８４０を示している。デュアルメッセージトランザクションに関し、許可システム８４２は許可を提供する。システム８４２は、オンラインおよびオフラインの機能をサポートし、そのファイルは、内部システムテーブルと、顧客データベースと、マーチャントセントラルファイルとを含む。システム８４２のオンラインの機能は、デュアルメッセージ許可プロセスをサポートする。このプロセスは、ルーティングと、カード所有者およびカードの検証および代替処理と、ファイル保守などの他の機能とを含む。オフライン機能は、報告と、請求と、リカバリ掲示板の生成とを含む。報告は、許可の報告と、例外ファイルおよび助言ファイルの報告と、ＰＯＳ報告と、請求報告とを含む。システム８４２からシステム８４６へのブリッジは、システム８４２を使用しているメンバが、システム８４６を使用しているメンバと通信し、外部ネットワークへのＳＭＳゲートウェイにアクセスすることを可能にする。
【０２００】
決済・清算システム８４４は、事前に許可済みのデュアルメッセージトランザクションを決済して清算する。システム８４４は、グローバル規模で週６日間作動することによって、金融および非金融情報を収集し、メンバのあいだで報告を配布する。システムは、また、手数料と、チャージと、清算総額との合計を計算して報告を作成し、残高調整に役立てる。ブリッジは、システム８４４の処理センタと、システム８４６の処理センタとの間で交換を形成する。
【０２０１】
シングルメッセージシステム８４６は、フルファイナンシャルトランザクションを処理する。システム８４６は、また、デュアルメッセージ許可および決済トランザクションを処理することもでき、必要に応じてネットワーク外部のブリッジおよびアクセスを使用してシステム８４２と通信する。システム８４６は、Visa、Plus Interlink、および他のカードトランザクションを処理する。ＳＭＳファイルは、システムのアクセスおよびプロセスを制御する内部システムテーブルと、ＰＩＮ検証および代替プロセス許可のために使用されるカード所有者データのファイルを含んだカード所有者データベースとを備える。システム８４６のオンライン機能は、フルファイナンシャルトランザクション以外に、リアルタイムのカード所有者トランザクションプロセスおよび許可のための例外プロセスを実施する。システム８４６は、また、残高および清算総額を累算する。システム８４６のオフライン機能は、清算および資金取引の要求を処理し、清算および活動の報告を提供する。清算サービス８４８は、Interlinkを含むシステム８４４，８４６の清算機能を、あらゆる製品およびサービスを対象としたシングルサービスに統合する。決済は、システム８４４およびシステム８４６によって引き続いて個別に実施される。
【０２０２】
図１６は、通信ネットワーク８００のコンポーネントを別の角度から見た図である。統合支払システム８５０は、あらゆるオンライン許可および金融要求トランザクションを処理するための一次システムである。システム８５０は、デュアルメッセージおよびシングルメッセージプロセスの両方を報告する。いずれの場合も、清算は別個に生じる。主要な３つのソフトウェアコンポーネントは、共通インターフェース機能８５２と、与信システム８４２と、シングルメッセージシステム８４６とである。
【０２０３】
共通インターフェース機能８５２は、交換センタで受信された各メッセージのために必要とされるプロセスを決定する。このインテーフェース機能は、メッセージのソース（システム８４２、８４４、または８４６）と、プロセス要求およびプロセスネットワークの種類とに基づいて、適切なルーティングを選択する。このコンポーネントは、初期メッセージの編集を実施し、もし必要ならばメッセージを構文解析し、そのコンテンツが基本メッセージの構成規則にしたがうことを保証する。機能８５２は、メッセージをシステム８４２またはシステム８４６の宛先へとルーティングする。
【０２０４】
コンピュータシステムの実施形態：
図１７Ａおよび図１７Ｂは、本発明の実施形態を実現するのに適したコンピュータシステム９００を示している。図１７Ａは、コンピュータシステムがとることが可能な１つの物理的形状を示している。コンピュータシステムは、もちろん、集積回路、プリント基板、小型のハンドヘルドデバイスから巨大なスーパーコンピュータに至る多くの物理的形状をとって良い。コンピュータシステム９００は、モニタ９０２と、ディスプレイ９０４と、ハウジング９０６と、ディスクドライブ９０８と、キーボード９１０と、マウス９１２とを含む。ディスク９１４は、コンピュータシステム９００との間でデータをやり取りするために使用されるコンピュータ読み取り可能な媒体である。
【０２０５】
図１７Ｂは、コンピュータシステム９００のブロック図の一例である。システムバス９２０には、様々なサブシステムが取り付けられている。プロセッサ９２２（中央演算処理装置すなわちＣＰＵとも称される）は、メモリ９２４を含んだストレージデバイスに結合される。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）および読み取り専用メモリ（ＲＯＭ）を含む。当該分野では周知のように、ＲＯＭは、ＣＰＵに一方向的にデータおよび命令を転送するように機能し、ＲＡＭは、一般に、双方向的にデータおよび命令を転送するために使用される。いずれのタイプのメモリも、上述した任意の適切なコンピュータ読み取り可能な媒体を含んで良い。また、固定ディスク９２６が、ＣＰＵ９２２に双方向的に結合されている。この固定ディスク９２６は、追加のデータストレージ容量を提供するものであり、また、上述した任意のコンピュータ読み取り可能な媒体を含んでも良い。固定ディスク９２６は、プログラムやデータなどを格納するために使用して良く、一般に、一次ストレージよりも低速な二次ストレージ（ハードディスクなど）である。固定ディスク９２６内に保持されている情報は、適切な場合には、メモリ９２４内の仮想メモリとして標準の方式で組み込んで良いことがわかる。取り外し可能ディスク９１４は、上述したコンピュータ読み取り可能な媒体のうち任意の形態をとって良い。
【０２０６】
ＣＰＵ９２２は、ディスプレイ９２４、キーボード９１０、マウス９１２、およびスピーカ９３０などの様々な入出力デバイスにも結合される。一般に、入出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロホン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気もしくは紙テープリーダ、タブレット、スタイラス、音声もしくは筆跡認識装置、バイオメトリックリーダ、または他のコンピュータのうち任意のデバイスで良い。ＣＰＵ９２２は、ネットワークインターフェース９４０を使用して別のコンピュータまたは通信ネットワークに随意的に結合して良い。ＣＰＵは、上述した方法の段階を実施するにあたって、このようなネットワークインターフェースを使用してネットワークから情報を受信するか、あるいはネットワークに情報を出力すると考えられる。さらに、本発明の方法の実施形態は、ＣＰＵ９２２においてのみ実行しても良いし、処理の一部を共用するリモートＣＰＵと協同でインターネットなどのネットワークを通して実行しても良い。
【０２０７】
また、本発明の実施形態は、さらに、コンピュータに実装された様々な動作を実施する目的でコンピュータ読み取り可能な媒体上にコンピュータコードを有したコンピュータストレージ製品に関する。メディアおよびコンピュータコードは、本発明の目的のために特別に設計および構築されたものであっても良いし、あるいは、コンピュータソフトウェアの当業者にとって周知の市販のものであっても良い。コンピュータ読み取り可能な媒体は、例えば、ハードディスク、フロッピィディスク、磁気テープなどの磁気メディア、ＣＤ−ＲＯＭ、ホログラフィックデバイスなどの光学メディア、フロプティカルディスクなどの磁気光学メディア、ならびに特定用途向け集積回路（ＡＳＩＣ）、ポログラマブルロジックデバイス（ＰＬＤ）、ＲＡＭとＲＯＭのデバイスなどの、プログラムコードを格納および実行するように特別に構成されたハードウェアデバイスを含み、これらに限定されない。コンピュータコードの例として、例えばコンパイラによって生成された機械コードや、インタープリタを使用してコンピュータによって実行される高水準コードを含んだファイルが挙げられる。
【０２０８】
以上では、いくつかの好ましい実施形態のかたちで本発明を説明したが、本発明の範囲には、変更形態、置換形態、および同等形態が含まれる。また、数多くの代替方法が、本発明の方法および装置を実現する方法として存在する。したがって、添付した以下の特許請求の範囲は、このような全ての変更形態、置換形態、および同等形態を、本発明の真の趣旨および範囲に含まれるものとして含むものと解釈される。
【図面の簡単な説明】
【図１】  支払人認証サービス（ＰＡＳ）をサポートすることができるインフラアーキテクチャの一実施形態を示した概略図である。
【図２】  カード所有者がＰＡＳに登録するプロセスを、本発明の一実施形態にしたがって示した図である。
【図３】  ＰＡＳへの登録プロセスの最中にカード所有者が情報を入力することができるインターネットウェブページの一実施形態を示した図である。
【図４】  ＰＡＳによって認証済みの支払トランザクションを、本発明一実施形態にしたがって示した図である。
【図５】  カード所有者にパスワードを要求する代表的なウィンドウを示した図である。
【図６】  支払トランザクションの最中に送信される代表的なメッセージを、ＰＡＳアーキテクチャ上に重ねて示した図である。
【図７】  集中型ＰＡＳアークテクチャ上でのメッセージフローを、本発明による集中型の一実施形態にしたがって示した図である。
【図８】  カード所有者クライアントデバイスと、ＰＡＳと、マーチャントシステムとの間で生じる集中型の支払フローを、本発明による集中型の一実施形態にしたがって示した図である。
【図９】  分散型ＰＡＳアークテクチャでの登録フローを、本発明による分散型の一実施形態にしたがって示した図である。
【図１０】  分散型ＰＡＳアークテクチャでの支払フローを、本発明による分散型の一実施形態にしたがって示した図である。
【図１０Ａ】  チップカード支払人許可サービスの一実施形態のシステムアーキテクチャを示した概要図である。
【図１１】  支払人認証サービスのチップカードの実施形態を使用した支払トランザクションの一例を示したフローチャートである。
【図１２】  チップカード認証プロセスのシステムアーキテクチャを、本発明の一実施形態にしたがって示した図である。
【図１２Ａ】  チップカードと、カード所有者クライアントシステムと、発行側のアクセス制御サーバとの間の詳細なメッセージフローを示した図である。
【図１３】  支払人認証サービスのアクセス制御システムの実施形態で利用されるコンポーネントを示した系統図である。
【図１４】  本発明の一実施形態をインプリメントするのに適した通信ネットワークを示した図である。
【図１５】  オンラインおよびオフラインのトランザクション処理を提供するために、交換センタのなかに収容されたシステムを示した図である。
【図１６】  通信ネットワークのコンポーネントを別の角度から見た図である。
【図１７Ａ】  本発明の実施形態を実現するのに適したコンピュータシステムを示した図である。
【図１７Ｂ】  本発明の実施形態を実現するのに適したコンピュータシステムを示した図である。
【符号の説明】
１００…ＰＡＳをサポートできるインフラアーキテクチャ
１０２…発行側ドメイン
１０４…相互運用性ドメイン
１０６…決済側ドメイン
１０８…登録サイト
１１０…発行側カード所有者システム
１１２…登録サーバ
１１４…アクセス制御サーバ
１１６…第三者ＩＤ認証コンポーネント
１１８…アカウント所有者ファイル
１２０・・認証済みカード所有者
１２２…カード所有者クライアントデバイス
１２４…インターネット支払ゲートウェイサービス
１２６…通信ネットワーク
１２７…発行側の認証システム
１２８…ディレクトリサーバ
１３０…受領証ファイル
１３１…受領証マネージャ
１３２…マーチャント
１３４…マーチャントプラグインソフトウェアモジュール
１３６…正当性検査サーバ
１３８…発行側の許可・清算システム
１４０…決済側の支払プロセッサ
１４２…通信ネットワーク
１８０…発行側
１８２…決済側の支払プロセッサ
３００…カード所有者が情報を入力するためのインターネットウェブページ
５００…カード所有者にＰＡＳパスワードを要求するための代表的なウィンドウ
７００…集中型アーキテクチャ
７０２…パソコン（ＰＣ）
７０４…支払人認証サービス（ＰＡＳ）
７０６…インターネットブラウザ
７０８…登録サーバ
７１０…ディレクトリサーバ
７１２…アクセス制御サーバ（ＡＣＳ）
７１４…受領データベース
７２０…マーチャントシステム
７２２…ストアフロントプログラム
７２４…マーチャントプラグインソフトウェアモジュール
７２６…支払システム
８００…通信ネットワーク
８０２…交換センタ
８０４，８０６…アクセスポイント
８０８，８１０…処理センタ
８２０，８２２…回線
８２６，８２８…リンク
８４０…トランザクション処理を提供するシステム
８４２…許可システム
８４４…決済・清算システム
８４６…シングルメッセージシステム
８４８…清算サービス
８５０…統合支払システム
８５２…共通インターフェース機能
９００…分散型アーキテクチャ
９０２…カード所有者クライアントデバイス
９０４…インターネットブラウザ
９０６…ＰＡＳ
９０８…登録サーバ
９１０…カード所有者ソフトウェアモジュール
９５０…マーチャントサーバ
９５２…ストアフロントソフトウェア
９５４…マーチャントプラグインソフトウェアモジュール
９５６…支払システム
９６０…受領データベース
９００…コンピュータシステム
９０２…モニタ
９０４…ディスプレイ
９０６…ハウジング
９０８…ディスクドライブ
９１０…キーボード
９１２…マウス
９１４…ディスク
９２０…システムバス
９２２…プロセッサ
９２４…メモリ
９２６…固定ディスク
９３０…スピーカ
９４０…ネットワークインターフェース
１２０２…アクセスアプレット
１２０４…チップカードクレジット・デビットアプリケーション
１２４０…データベース
１５００…チップカード認証アーキテクチャ
１５１０…カード所有者クライアントデバイス
１５１２…表示デバイス
１５１４…端末ソフトウェア
１５１６…キー入力デバイス
１５１８…カードリーダまたはチップカードリーダ
１５２０…発行側ＡＣＳ
１５２２…ＰＡＳ認証ソフトウェア
１５２４…ハードウェアセキュリティモジュール
１５２６…カード所有者データベース
１５２８…システムソフトウェア
１５３０…カード所有者
１５４０…チップカード
１５４２…チップカードクレジット・デビットアプリケーションまたは支払人認証アプリケーション
１５５０…要求者
【図１】
0005025875.tif 000006
【図２】
0005025875.tif 000007
【図３】
0005025875.tif 000008
【図４】
0005025875.tif 000009
【図５】
0005025875.tif 000010
【図６】
0005025875.tif 000011
【図７】
0005025875.tif 000012
【図８】
0005025875.tif 000013
【図９】
0005025875.tif 000014
【図１０】
0005025875.tif 000015
【図１０Ａ】
0005025875.tif 000016
【図１１】
0005025875.tif 000017
【図１２】
0005025875.tif 000018
【図１２Ａ】
0005025875.tif 000019
【図１３】
0005025875.tif 000020
【図１４】
0005025875.tif 000021
【図１５】
0005025875.tif 000022
【図１６】
0005025875.tif 000023
【図１７Ａ】
0005025875.tif 000024
【図１７Ｂ】
0005025875.tif 000025