JP2019071052A - ネットワークトランザクションとの関連でユーザを認証するために用いるシステム及び方法 - Google Patents

Abstract

【課題】トランザクションとの関連でユーザを支払口座に対して認証する。【解決手段】支払口座と関連付けられているトークン及び暗号を含む、トランザクションについての認証リクエストを、少なくとも１つのコンピューティング装置で受信３０２し、支払口座についてのプライマリ口座番号（ＰＡＮ）にトークンをマッピング３０６する。さらに、暗号を検証３０８し、認証リクエストについてのディレクトリサーバノンス（ＤＳＮ）を生成３１０し、ＤＳＮと口座番号とを支払口座の発行者と関連付けられているアクセス制御サーバ（ＡＣＳ）へと送信３１８する。発行者認証値（ＩＡＶ）に応答してＩＡＶとＤＳＮとトランザクションの額とを含む口座所持者認証値（ＡＡＶ）をコンパイル３２６し、ＡＡＶを商人及びサーバのどちらかに送信３２８する。【選択図】図３

Description

本開示は、概して、ネットワークトランザクションとの関連でユーザを認証するために用いるシステム及び方法に関するのであり、特に、トークナイゼーションサービスとの関連でユーザのトランザクション用に認証値（authentication value）を提供するために用いるシステム及び方法に関するのであり、認証値はユーザの認証並びにトランザクションに関連付けられている暗号用の検証コード（validation code）に基づいている。

このセクションでは、本開示に関連する背景情報を提供するも先行技術に関するとは限らない。

支払口座トランザクションは、通常、消費者と関連付けられている支払口座の関与を伴い、支払口座は１つ以上の製品の購入に充てられる資金をもたらすために用いられる。これとの関連で、不正な又は無許可トランザクションを抑制及び／又は防止するために様々な機構が多くの場合設けられている。例えば、ＥＭＶ（登録商標）技術が活用されており、該技術では支払口座トランザクションを行うのに用いられる支払カードに内蔵されたチップがＰＯＳ端末と協働してトランザクション用暗号を生成し、そして対応する支払口座の発行者（或いは発行者を代理する当事者ら）によってトランザクションの承認（approval）前にそれが検証（validate）される。通常はカード臨在型トランザクション用に設計されているが、ＥＭＶ技術はオンライントランザクションにも適している。

上述に加え、支払ネットワークは、強化型認証手法を多くの場合提供するのであり、これらは一般に３−Ｄセキュア（ＴＭ）プロトコルと称されるのであり、支払口座トランザクションに関与している商人（merchant）側の商人プラグイン（ＭＰＩ、merchant plug-in）及び発行者に関連付けられているアクセス制御サーバ（ＡＣＳ、access control server）にそれは依存している。３−Ｄセキュアプロトコルは、オンライントランザクションに良く用いられるのであり、カード保持者が、トランザクション実行時に自己が商人側に物理的に存在していない局面下で自己を認証することを、可能とする。例えば、マスターカード（登録商標）は、マスターカードセキュアコード（ＴＭ）サービスを提供しているのであり、これは３−Ｄセキュアプロトコルに基づいている。このサービス内では、認証値（例えば、口座保持者認証値（ＡＡＶ、accountholder authentication value）等）がカード発行者によって生成されるのであり、認証結果が含まれている。そして、これらの値（value）は、元となっているトランザクション用の許可メッセージ（authorization message）内の汎用カード所持者認証フィールド（ＵＣＡＦ、universal cardholder authentication field）と称される特定のフィールド内に配置される。そして、この情報は、支払許可リクエスト（payment authorization request）との関連で発行者を支援するために伝達され、認証（authentication）が発行者によって完了されたことの明示的な証拠をもたらす。他の支払ネットワークは同様の認証サービスを活用するのであり、一般にこれらも３−Ｄセキュアプロトコルに基づいている。そして、これらのサービスの各々では、一般に、結果として生じる認証値を、自らの標準許可メッセージ内に、商人のアクワイアラ（或いは銀行）が追加することを要する。

説明される図面は、全ての可能な実装例ではなく選択された実施形態についての例示を目的としているにすぎず本開示の範囲を限定することは意図されていない。
また、対応する参照符号は図面の幾つかの視点における対応する部分を指す。

トランザクション用の完全な口座保持者認証値（ＡＡＶ）を提供するために用いる例示的システムを示す概略図であって、該システムはトランザクションに関連しての消費者の認証（authentication）に基づいて並びに関連付けられている暗号についての検証（validation）コードに基づいて提供をなし、本開示の１つ以上の態様を含む、概略図である。 図１のシステムにて用いられ得る例示的コンピューティング装置についてのブロック図である。 消費者の認証に基づくトランザクション用の発行者認証値（ＩＡＶ）を含む完全なＡＡＶを提供するために用いる図１のシステムを介して実装され得る例示的方法について示す流れ図である。 図１のシステム及び／又は図３の方法との関連で用いられ得る、ＩＡＶを含む完全なＡＡＶについての例示的フォーマットについてのブロック図である。

添付の図面を参照して例示的実施形態について以下詳述する。本願明細書に含まれる詳細な説明及び具体例は、例示目的で提供されているにすぎず、本開示の範囲を限定することは意図されていない。

支払口座は、商品に関して商人と対峙して行うトランザクション（例えば、商品、サービス等のためのトランザクション）に関して資金を供するために、広く使用されている。不正な及び／又は無許可のトランザクションに関する問題を回避するために、支払口座に関連付けられている発行者及びトランザクション処理に関与する支払ネットワーク事業者は、多くの場合、トランザクションを開始する消費者に対して追加の認証及び検証のための手法／サービスを課する。もっとも、伝統的には、そのような認証及び検証のための手法は、カード臨在型トランザクション（card-present transaction）のみに活用されている。

上述を前提に述べるに、本願のシステム及び方法は、異なる追加の認証及び検証用手法の活用を独特な態様で可能とするのであり、より一般化して述べれば、カード不在（ＣＮＰ、card-not-present）型トランザクションが含まれる。特に本願明細書では、ディレクトリサーバで所与のトランザクションについて認証リクエスト（authentication request）が受信された場合、ディレクトリサーバはトークンと（随意的には）暗号とをリクエストに含まれていたようにしてデジタルサービスサーバ（ＤＳＳ、digital service server）に提供するのであり、該ＤＳＳは、トランザクションに用いられている対応する支払口座に関連付けられているプライマリ口座番号（ＰＡＮ、primary account number）にトークンをマッピングするのであり、さらには、暗号を検証するか、或いは、それを後に検証するためにセキュアに格納するのであり、検証コードが生成される。そして、ディレクトリサーバはリクエストを（ＰＡＮと共に）アクセス制御サーバ（ＡＣＳ、access control server）へと伝達するのであり、該ＡＣＳはトランザクションを開始した消費者について認証がなされた後に発行者認証値（ＩＡＶ、Issuer Authentication Value）コードを提供する。そして、ＩＡＶは、別の暗号（例えば、メッセージ認証コード（ＭＡＣ、message authentication code）等）と共にトランザクション用の完全な口座保持者認証値（ＡＡＶ、accountholder authentication value）へとコンパイルされるのであり、それはトランザクション用の許可リクエスト（authorization request）に内包されるようにするために商人に提供されるのであり、それは指定された位置（例えば、汎用カード所持者認証フィールド（ＵＣＡＦ、universal cardholder authentication field））にて挿入される。許可リクエストとの関連では、支払ネットワークは、ＡＡＶ内の暗号を検証するのであり、また、その検証に基づいてトランザクションの進行を許す（permit）か否かを決する。この態様のようにして、ＡＣＳを介して提供される強化型認証と暗号によって提供されるセキュリティとは、ディレクトリサーバによって所定のトランザクションに対して課されることとなる（例えば、暗号の検証に関与する支払ネットワークの一部として等）。

図１は、消費者によってなされるトランザクションとの関連で消費者についての認証と検証とをなすために活用され得る手順を実装するための例示的システム１００を示すのであり、これは例えばＥＭＶ３−Ｄセキュアプロトコル／仕様に準拠していることができる。もっとも、ＥＭＶ３−Ｄセキュアプロトコル／仕様の全詳細が論じられているわけではない。なぜならば、ＥＭＶ３−Ｄセキュアプロトコル／仕様及び／又はそれについての議論を参照することによって、そのような情報についての完全性を伴った詳細な開示事項を知得し得るからである。追加的には、図示のシステム１００は、セキュア通信チャネル上（例えば、ＥＭＶ３−Ｄセキュアプロトコル／仕様で定義された態様（例えば、https://www.emvco.com/emv-technologies/3d-secure/を参照。）等。）で特定の態様でフォーマティングされた複数のメッセージを交換することによって相互対話する複数のエンティティを含む。したがって、理解していると思われるが、関与するエンティティやメッセージや他の必要とされる要件の個数や程度故に、図１に示した認証は複雑なものである。

例示した実施形態では、システム１００は支払口座と関連付けられた消費者１０２を含んでおり、支払口座は発行者１０４によって消費者１０２へと発行されており、支払口座は１つ以上の商人（例えば、商人１０６等）との間でなされる購買トランザクションにおいて決済資金をもたらすために消費者１０２によって用いられることができる。消費者１０２はコンピューティング装置１０８とも関連付けられており、該装置は１つ以上の仮想商人配置箇所をアクセスするように構成されている。コンピューティング装置１０８は、タブレット、スマートフォン、ラップトップ、デスクトップ、又は消費者１０２が１つ以上の商人と（例えば、商人によって提供されるウェブサイト及び／又はネットワークベースドアプリケーションを介してなされる等の）対話及び／又は通信できるようにするための他の装置を含むことができる。また、コンピューティング装置１０８は、（不図示の）ウォレットアプリケーションも含んでおり、これは、例えば支払口座トランザクションとの関連で、消費者の支払口座についての支払口座クレデンシャルを提供するように構成されている。この実施形態では、ウォレットアプリケーションは仮想ウォレットアプリケーションを含むのであり、非限定的に列挙すれば、マスターカード（登録商標）のMasterpass（登録商標）、アップル（登録商標）のApple Pay（登録商標）、Visa Checkout（登録商標）等が含まれ得る。ウォレットアプリケーションそしてより一般的にはコンピューティング装置１０８は、｛インストール及び／又はアクティベーション｝がなされると、公開鍵／秘密鍵ペア又は１つ以上の対称鍵｛を与えられる及び／又はプロビジョニングされる｝のであり、これは後述のように用いられるのであり、それによって、消費者１０２の支払口座を用いて（ウォレットアプリケーションを介して）消費者１０２によって行われたトランザクション毎に暗号が生成される。鍵はデジタルサービスサーバ（例えば、ＤＳＳ、digital service server）（例えば、ＤＳＳ１１０等）によって又は支払ネットワーク（例えば、支払ネットワーク１３６等）並びに他の態様等に即して提供され得る。コンピューティング装置１０８及び本明細書にて特定される他のコンピューティング装置（例えば、サーバ等）についての詳細は、図２を参照して以下においてより詳しく説明される。

システム１００内の商人１０６は、この例示的実施形態では、例えばウェブサイトやネットワークベースドアプリケーション等の仮想商人ロケーションを有する仮想商人を含むのであり、該箇所はコンピューティング装置１０８を介して消費者１０２によってアクセスされることができる。商人仮想ロケーションは商人１０６によって直接的に又は商人１０６を代理する別のエンティティ等によって管理及び／又は提供されていること等ができる。

一般的に述べるに、システム１００内では、消費者１０２は、仮想商人ロケーションにて以前に商人１０６｛にアクセスした及び／又はと対話した｝ことがあるのであり、商人１０６は消費者１０２についてのプロファイルを有しており、これは消費者の支払口座についての支払クレデンシャルを含む。そして、関連することを述べるに、商人１０６又は他のエンティティは、例えば商人１０６にて消費者１０２によって後になされる支払口座トランザクションとの関連で利用するための、消費者１０２のプロファイルを生成することに関連して、（トークンサービスプロバイダ（ＴＳＰ、token service provider）によって具現化されている及び／又はＴＳＰを含んでいることができる等の）ＤＳＳ１１０からのトークンを要求するように構成されている。この例示的実施形態では、ＤＳＳ１１０はマスターカードデジタル実施可能化サービス（ＭＤＥＳ、Mastercard Digital Enablement Service）サーバを含むのであるが、他の実施形態等では１つ以上の他のサーバ等を含むことができる。どの場合であれ、そのようなトークンリクエストに対して、ＤＳＳ１１０は消費者の支払口座に固有のトークンを生成し、また、（例えば、ＤＳＳ１１０等に関連付けられたデータ構造等において）トークンを支払口座のプライマリ口座番号（ＰＡＮ、primary account number）へとマッピングする。さらに、ＤＳＳ１１０はトークンを商人１０６に直接的に又はコンピューティング装置１０８における仮想ウォレットアプリケーションを介して戻すのであり、商人１０６はトークンを消費者のプロファイルと関連付けて格納するのであり、商人１０６との将来のトランザクションにおいて消費者１０２が後で使えるように格納しておく（例えば、「オンファイル（on file）」状態等）。消費者１０２との間でなされる後続のトランザクションに関しては、商人１０６は、トークンを用いて、トランザクションのために用いられる資金供出元支払口座を識別する。

代替的には、ＤＳＳ１１０は、トークンを生成してコンピューティング装置１０８内の仮想ウォレットアプリケーションにこれを提供することができ、これを受け該アプリケーションはトークンを自己の内に格納できる。そして、後のトランザクションにおいては、商人１０６において「オンファイル」状態で保たれているトークンに依存せずに、仮想ウォレットアプリケーションは自分側に格納されているトークンを提供する。さらに、後のトランザクションに関しては、消費者１０２又はコンピューティング装置１０８内の仮想ウォレットアプリケーションは、商人１０６側で「オンファイル」状態とされているトークン又は仮想ウォレットアプリケーションにプロビジョニングされているトークンに依存する代わりに、直接的に口座番号（例えば、ＰＡＮ等）を提供してさらなるトランザクションに対して資金提供をなし得る。

したがって、消費者１０２と商人１０６との間でのトランザクションは、１つ以上のトークン又は消費者１０２によって提供された口座番号（例えば、ＰＡＮ等）を伴うことができる。各タイプのトランザクションは、後述のように処理されるのであるが、示されているように若干の差異はある。

具体的には、システム１００では、消費者１０２が、コンピューティング装置１０８を介して或いは商人の仮想ロケーションにて商人１０６の１つ以上のプロダクト（例えば、商品、役務等）をブラウズする場合、消費者１０２はプロダクトの購入を選択し得るのであり、その際には、コンピューティング装置１０８にてトランザクションに関する詳細事項及び入力をさらに提供することができ、そして経路１１２を経由してチェックアウト段階へと進むことができる。消費者１０２から受信されたチェックアウト詳細事項及び入力は、例えば、商人１０６にて既に受信及び格納されたトークンに対応する支払口座の選択を含むことができる。或いは、チェックアウト詳細事項及び入力は、消費者１０２が次の事柄を提供することを含み得る：（既にトークンが受信された）同じ支払口座についてのトークン、口座番号、又は異なる支払口座についての口座番号、及び／又はトランザクションについての他の詳細事項。

チェックアウト入力（及び／又はそれとの関連で供された詳細事項）に応答して、商人１０６はコンピューティング装置１０８と対話するように構成されており、（不図示の）ウォレットアプリケーションによって構成されているコンピューティング装置１０８は暗号を生成するのであり、公開鍵―秘密鍵ペア又は対称鍵（例えば、対称アルゴリズムで生成された秘密鍵等）に基づいて暗号が生成されるのであり、それらは消費者の支払口座及びウォレットアプリケーションと関連付けられている（なお、これは例えば、ＤＳＳ１１０に知られているかそれと共有されている）。暗号は、コンピューティング装置１０８にてローカルな態様で仮想ウォレットアプリケーションによって生成されるか（例えば、ウォレットによって生成されたデジタルセキュア遠隔支払（ＤＳＲＰ、digital secure remote payment））、又は、他のシステムとの１つ以上の相互作用に基づいて生成されることができ（例えば、ＤＳＳ１１０内に統合されたＤＳＲＰサービス、又は他のシステム等）（例えば、クラウドサービス等を介してなされるのであり）、それらは仮想ウォレットアプリケーションを介して商人１０６に提供される。この例示的実施形態では、暗号はトークン暗号であり、具体的にはＤＳＲＰ暗号である。以上を述べているも、他のトークン暗号を生成して、及び／又は、他のシステムの実施形態で活用しても良いことに留意されたい。

そして、ウォレットアプリケーションによって構成されたコンピューティング装置１０８は、ＤＳＲＰ暗号を商人１０６へと送信する。

追加的に、ウォレットアプリケーションは（コンピューティング装置１０８においてローカルに、又は、１つ以上のバックエンドサーバにて）アプリケーショントランザクションカウント（ＡＴＣ、application transaction count）を管理しているのであり、消費者の支払口座に関して生成されたＤＳＲＰ暗号毎にＡＴＣをインクリメントしていく（即ち、支払口座に関してのトークンに固有なものか又はそうでないかに着目する）。例示された実施形態では、ＡＴＣはトークンに固有なものであり、支払口座が複数のトークンを有している場合であっても、各トークンは特定のＡＴＣに関連付けられるのであり、これは例えば関連性を有するreply攻撃を抑制するためになされる。

ＤＳＲＰ暗号が商人１０６にて受信されると、商人１０６と関連付けられた商人サーバプラグイン（ＭＰＩ、Merchant server Plug-In）１１４が、トランザクションについての認証リクエスト（ＡＲｅｑ、authentication request）をコンパイルするように構成される。商人１０６にプロビジョニングされたトークンがトランザクションに関与している場合、ＡＲｅｑは少なくともトークン及びＤＳＲＰ暗号を含むのでありそれはコンピューティング装置１０８によって受信されたものである。代替的には、トランザクションがトークン（或いは別のトークン）の関与を伴わない場合、ＡＲｅｑは少なくとも消費者の支払口座についての口座番号（例えば、ＰＡＮ等）及びＤＳＲＰ暗号を含む。ＭＰＩ１１４は、ＡＲｅｑを、経路１１６を介して、システム１００内に含まれるディレクトリサーバ１１８へと送信するように構成されている。例示的システム１００はＭＰＩ１１４を含んでいるものの、ＭＰＩ１１４は、本明細書に含まれる特定の強化型認証スキームに適した１つ以上の他のサーバ及び／又はサービスであることができるということにも留意されたい（ＭＰＩ１１４は（ＥＭＶ３−Ｄセキュアプロトコル仕様に関しては）３ＤＳサーバと称され得る等ということである）のでありそれ以外のこともあり得る。

この例示的実施形態では、ＡＲｅｑが商人１０６にプロビジョニングされたトークンを含む場合、ディレクトリサーバ１１８は、ＡＲｅｑを受信し、また、ＡＲｅｑからのトークン及びＤＳＲＰ暗号を経路１２０を介してＤＳＳ１１０へと送信するように構成されている。

転じて、ＤＳＳ１１０は、受信されたトークンを消費者の支払口座についての口座番号（例えば、ＰＡＮ等）へとマッピングし、また、ディレクトリサーバノンス（ＤＳＮ、directory server nonce）を生成するように構成されている。ＤＳＮは例えば予測不能な数値等の数値を含み得るのでありＡＡＶ内にエントロピをもたらすために活用され及び／又はそれに関連する発行者認証値（ＩＡＶ、issuer authentication value）も含まれる。追加的には、ＤＳＳ１１０は、トランザクションのために受信されたＤＳＲＰ暗号を検証するように構成されている（即ち、暗号学的鍵検証を行う）。具体的には、ＤＳＳ１１０は、発行者マスタ対称鍵からマスタ鍵を分化し（例えば、発行者１０４等のためにＤＳＳ１１０によって生成された鍵等）、また、そしてマスタ鍵から１つ以上のセッション鍵を分化するように構成されている（例えば、ＤＳＳ１１０等によって管理されたＡＴＣに基づいて等）。ＤＳＳ１１０は、セッション鍵を用いて、ディレクトリサーバ１１８から受信されたＤＳＲＰ暗号を検証するように構成されている。さらに、暗号が検証されると、ＤＳＳ１１０は、ＡＴＣをインクレメントするように構成されており、例えば、ＡＴＣ値（ATC value）が使用済みの値であることを記録する等する（これによってその反復使用を防止し得る）。追加的に又は代替的には、ＤＳＲＰ暗号が検証されなかった場合、ＤＳＳ１１０は、ＤＳＲＰデータをメモリ内においてＡＴＣ及び／又はＤＳＮと関連付けて格納するように構成されている（そして、後述のようにＤＳＲＰ暗号は後述のように後に検証される）。

ＤＳＳ１１０は、口座番号及びＤＳＮをディレクトリサーバ１１８へと戻すようにも構成されており、これも経路１２０を介してなされる。例えば、少なくとも１つの実施形態では、ＡＲｅｑがトークンも暗号も含まない場合、ディレクトリサーバ１１８は、ＤＳＳ１１０からＤＳＮを受信せずに代わりに自らＤＳＮを生成することができる。

その後、ディレクトリサーバ１１８が口座番号をＤＳＳ１１０から受信した場合、又は元のＡＲｅｑが口座番号を含んでいる場合、ディレクトリサーバ１１８は、トランザクションに関連付けられた特定のデータを圧縮するように構成されていることができる。例えば、ディレクトリサーバ１１８は、トランザクション額の対数（即ち、額の対数）を決するように構成されていることができ、それによって額を提示するために用いられるデータを圧縮できる（例えば、額についての６バイトの値は、潜在的誤差を±０．０２％等として２バイトにエンコードできる。）さらに、ディレクトリサーバ１１８は、商人１０６の商人ＩＤについての打ち切りハッシュを決するように構成されていることができ、ここでも商人ＩＤを表すのに用いられるデータが圧縮される。上述のように述べているのであるし、ディレクトリサーバ１１８は、１つ以上の手法を適用してそこにて用いられるべきデータを圧縮できるのであり、又はそうでない場合他の実施形態でもあり得ることに留意されたい。

そして、ディレクトリサーバ１１８は、例えば、口座番号とＤＳＮと額の対数と商人ＩＤについての打ち切りハッシュとを含むＡＲｅｑを経路１２２を介してシステム１００のＡＣＳ１２４に提供するように構成されていることができる。この例示的実施形態において実施されているような３−Ｄセキュア仕様において定義されているように、ＡＣＳ１２４は、発行者１０４によって操作されるものであるか、又は、発行者を代理して操作されるものである。

このようにして、ＡＣＳ１２４はトランザクションの危険性を評価するように構成されている（例えば、評価はトランザクション額、関与する商人のタイプ、消費者１０２、消費者の装置情報（例えば、反復発生する装置等）等に基づいてなされる）。（上述の分析／認証に基づいた）危険性が許容不可である場合、ＡＣＳ１２４は、従来的手法と比べて一貫性のあるチャレンジ質問をさらに提供するように構成されていることができ、消費者１０２を認証するかトランザクションを却下するか他のことをなして続行する等できるように用意されていることができる。上述の危険性評価又は追加のチャレンジ質問又は他の態様を経て、消費者１０２が認証されると、ＡＣＳ１２４は、発行者１０４と共有された鍵及び暗号学的手法（例えば、キーイングされたハッシュ（ＨＭＡＣ）関数等）及び次の１つ以上に基づいて、ＩＡＶを生成するように構成されていることができる：口座番号、ＤＳＮ、額の対数、商人ＩＤについての打ち切りハッシュ、又は他のデータ等。このようにして、ＩＡＶは消費者１０２、商人１０６及びトランザクション（例えば、額の対数等）の各側面に関して固有なものである。故に、ある１つのトランザクションに関してＩＡＶが生成されて、同一又は異なる商人に関しての別のトランザクションのための許可リクエスト（authorization request）に対してＩＡＶが提出されるということがなされることを一般的に抑止することができる。

そして、ＡＣＳ１２４は、再びＩＡＶをディレクトリサーバ１１８へと送信するように構成されており、これは経路１２２を介してなされ、これは認証応答（ＡＲｅｓ、authentication response）としてなされる。

随意的には、危険性に基づいた認証態様が然るべき兆しを示す場合には、ＡＣＳ１２４は、チャレンジ質問を通じて消費者１０２をさらに認証することができる。特に、図１の点線経路で示されているように、ＡＣＳ１２４は、経路１２６６に沿ってＡＲｅｓを用いてディレクトリサーバ１１８に応答するように構成されていることができるのであって、ＡＲｅｓはチャレンジ指標（例えば、商人１０６等によって召喚されるべきネットワークアドレス等）をさらに含む。そして、この例では、ディレクトリサーバ１１８は、ＡＲｅｓをＡＣＳ１２４から受信して、ＡＲｅｓを（ＭＰＩ１１４又は３ＤＳサーバ等を介して）商人１０６へと経路１２８を介して送信するように構成されていることができる。転じて、商人１０６は、殊に仮想商人ロケーション（例えば、ウェブサイト等）にて、チャレンジ指標を識別でき、またチャレンジをコール又は召命でき、それによって経路１３０を介して消費者のコンピューティング装置１０８とＡＣＳ１２４との間での対話がもたらされる。対話は一般的にはチャレンジ質問（例えば、あなたのパーソナルコードを入力せよ等）の提示を含み、これを受けた消費者１０２は応答を経路１３０を介して提供する。そして、ＡＣＳ１２４は、消費者１０２の応答を確認するように構成されている。その後、確認が取れたならば、ＡＣＳ１２４は、上述と一貫した態様で、次のことをなすように構成されている：ＩＡＶを生成し、そしてＩＡＶを含む応答を生成し、応答を経路１２６を経てディレクトリサーバ１１８へと送信すること。

ＡＣＳ１２４からＩＡＶを受領すると、ディレクトリサーバ１１８は、完全ＡＡＶ用のメッセージ認証コード（ＭＡＣ、message authentication code）を生成し（即ち、ＡＡＶ内に含まれるべきデータ（例えば、ＤＳＮ、額の対数、商人ＩＤについての打ち切りハッシュ、通貨コード、鍵ＩＤ等））、そして完全ＡＡＶをコンパイルするように構成されている。完全ＡＡＶは、ＩＡＶ、ＤＳＮ、額及び商人に関しての情報、及び署名情報（例えば、鍵ＩＤ及びＭＡＣ）等を含む。具体的な実装方式に応じて完全ＡＡＶに含まれるデータは変わり得るということに留意されたいのであり、完全ＡＡＶはより多くの又はより少ないデータを含み得るのであるが、一般的にはＡＣＳ１２４からのＩＡＶは含まれる。

その後、ディレクトリサーバ１１８は、ここでも経路１１６を介して、完全ＡＡＶをＭＰＩ１１４（又は３ＤＳサーバ）に提供するように構成されている。

これを受け、商人１０６は、許可リクエスト（authorization request）をコンパイルするように構成されており、該許可リクエストは、消費者の支払口座についてのトークン又は口座番号を適宜含んでおりまた完全ＡＡＶをも含む。商人１０６は許可リクエストをアクワイアラ１３２へと経路１３４を介して送信するように構成されている。これを受け、アクワイアラ１３２は許可リクエストを経路１３８を介して支払ネットワーク１３６へと送信するように構成されている。

許可リクエストを受領すると、支払ネットワーク１３６は、経路１４０を介してＤＳＳ１１０と相互作用するように構成されていることができる（もっとも、これは全ての実施形態で要されているわけではない（例えば、支払ネットワーク１３６が適切な鍵を知っている場合等））。具体的には、支払ネットワーク１３６は、完全ＡＡＶ内に含まれているＭＡＣを及び／又は完全ＡＡＶそれ自体を検証するように構成されていることができる。支払ネットワーク１３６は、完全ＡＡＶ及びその一部について他の態様で検証及び／又は確認するようにさらに構成されていることができ、例えば完全ＡＡＶ内に含まれるバージョン情報に基づいてそれがなされ得る。

検証されると、支払ネットワーク１３６は、許可リクエスト又はその構成要素をＤＳＳ１１０に提供するように構成されている。ＤＳＲＰ暗号が以前ＤＳＳ１１０によって検証されていた場合、ＤＳＳ１１０はＤＳＮに基づいてＤＳＲＰ暗号の検証を確認するように構成されている。他方で、ＤＳＳ１１０はＤＳＮ（又はそれに含まれるＡＴＣ）を用いてトランザクション用ＤＳＲＰデータの位置付けを決して、また、上述のようにＤＳＲＰデータを検証する。追加的に、ＤＳＳ１１０は、もしあるならば、許可リクエスト内に含まれるトークンを、対応する口座番号（例えば、ＰＡＮ等）へとマッピングするようにも構成されている。

そして、ＤＳＳ１１０は、経路１４０を介して、口座番号と検証結果とを支払ネットワーク１３６に戻すように構成されている。上述に関連して、支払ネットワーク１３６及び／又はＤＳＳ１１０は、支払口座及び／又は消費者１０２に基づいて、トランザクションについての追加的サービスを提供するようにさらに構成されていることができる。例えば、ＤＳＳ１１０は、トークンの１つ以上の利用要件が充足されているか（例えば、トークンが電子商取引において使用されることが許されているか等）を決定するように構成されていることができ、又は、随意的には、トランザクション額、商人の名称、及び通貨等をチェックすることができる。

その後、支払ネットワーク１３６は、経路１４２に沿って（口座番号及び検証結果を含む）許可リクエストを発行者１０４に提供するように構成されている。

そして、発行者１０４は、トランザクションが承認されるべきか却下されるべきかを決定するように構成されており、支払ネットワーク１３６を通じて適宜応答する。このようにするため、発行者１０４は、ＡＣＳ１２４と共有された１つ以上の共有鍵に基づいてＩＡＶを検証するように構成されている。より具体的には、ＩＡＶは精製時と同様の態様で検証され得るのであり、例えば、次の要素に基づいてなされ得る：同じ秘密鍵、ＡＣＳ１２４によって用いられたのと同じ暗号学的手法、並びに、口座番号、ＤＳＮ、額の対数、及び商人ＩＤについての打ち切りハッシュ又は／若しくは他のデータ等。追加的に又は代替的には、発行者１０４は、トランザクションを承認するために（検証結果にて示されているように）ＡＡＶを既に検証した１つ以上のネットワークサービスを（例えば、支払ネットワーク１３６を介して）活用するように構成されていることができる。さらに述べるに、発行者１０４は、ＡＡＶからの額の対数（又は、随的には、未圧縮の額）に基づいてトランザクション額（即ち、許可リクエスト（authorization request）内にて示された額）を検証し、また、ＡＡＶからの商人ＩＤについての打ち切りハッシュ等に基づいてトランザクション商人（即ち、許可リクエスト内に示された商人）をも検証すること等ができる。決定がなされると、発行者１０４は、（消費者の支払口座番号を含む）許可応答（authorization response）を経路１４２に沿って支払ネットワーク１３６へ戻すように送信するように構成されている。これを受けて、支払ネットワーク１３６は、（トークン又は口座番号を含む）許可応答を経路１３８を介してアクワイアラ１３２へと戻るようにルーティングするように構成されている。これを受けて、アクワイアラ１３２は、許可応答を、直接又はＭＰＩ１１４を介して、経路１３４に沿って商人１０６に戻すようにして提供するように構成されている。

この段階で、トランザクションは（この事例では）承認されているのであり、商人１０６は選択されたプロダクトを消費者１０２へと配送されるように差し向けることができる。

本明細書中の次のものの各々は、図２に示されたコンピューティング装置２００等の１つ以上のコンピューティング装置で実装されていることに留意されたい：発行者１０４、商人１０６、コンピューティング装置１０８、ＤＳＳ１１０、ＭＰＩ１１４、ディレクトリサーバ１１８、ＡＣＳ１２４、アクワイアラ１３２、支払ネットワーク１３６等。このことと関連して述べるに、１つ以上のコンピューティング装置は、少なくとも１つのネットワークを介してそれぞれ１つ以上の他のエンティティと通信可能とされている。一般的に述べるに、図１に含まれている経路であって上述の説明中においてメッセージが交換されるためにメッセージが沿って流れるか又はメッセージが経由していく経路の各々は、ネットワークを表すものである。非限定的に例示するに、ネットワークには１つ以上の次のものが含まれ得る：ローカルエリアネットワーク（ＬＡＮ）、広域エリアネットワーク（ＷＡＮ）（例えば、インターネット等）、モバイルネットワーク、仮想ネットワーク、本明細書中にて説明された他のネットワーク、及び／又は、２つ以上の図示された部分の間での通信を支援することが可能な他の適切な公衆及び／又は私的ネットワーク、又は、場合によってはそれらの組み合わせ。１つの例では、ネットワークは、複数のネットワークを含み、複数のネットワークの異なる個々のネットワークは図１に示された異なるコンポーネントらからアクセス可能とされる。特に、支払ネットワーク１３６及びＤＳＳ１１０は私的ネットワークを介して接続されていることができ、また別の点においては、商人１０６及びコンピューティング装置１０８はインターネット等の公衆ネットワークを通じて接続されていることができる。

図２は例示的コンピューティング装置２００を示し、これは例えば１つ以上のサーバ、ワークステーション、パソコン、ラップトップ、タブレット、スマートフォン、他の適切なコンピューティング装置等を含み得る。追加的には、コンピューティング装置２００は、単一のコンピューティング装置を含み得るのであり、或いは、コンピューティング装置が本明細書中にて説明されたように機能可能となるように具体的に構成されている限り、それは近接して配置された複数のコンピューティング装置又は地理的領域にわたって分散された複数のコンピューティング装置を含み得る。少なくとも１つの実施形態では、コンピューティング装置２００は、（本明細書中にて説明された用途との関係で）クラウド型、フォグ型及び／又はミスト型コンピューティング装置としてアクセスされる。これを前提に述べるに、異なるコンピューティング装置及び／又はコンピューティング装置の配置を用い得る故に後述のようにシステム１００はコンピューティング装置２００に限定されたものとみなされてはならない。追加的には、異なるコンポーネント及び／又はコンポーネント配置を他のコンピューティング装置にて用い得る。

図２を参照するに、例示的コンピューティング装置２００は、プロセッサ２０２と、プロセッサ２０２に（通信可能に）接続されたメモリ２０４とを含む。プロセッサ２０２は、１つ以上の処理部を含み得る（例えば、マルチコア構成等）。例えば、非限定的に述べれば、プロセッサ２０２は次のものを含み得る：中央処理装置（ＣＰＵ）、マイクロコントローラ、縮小命令セットコンピュータ（ＲＩＳＣ）プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理装置（ＰＬＤ）、ゲートアレイ、及び／又は本明細書中にて説明された機能を実現可能な任意の他の回路若しくはプロセッサ。

本明細書中にて説明されるメモリ２０４は、データや命令等の格納及び検索を許容する１つ以上の装置である。メモリ２０４は１つ以上のコンピュータ可読記憶媒体を含み得るのであり、非限定的に例示すれば次のものが含まれる：動的ランダムアクセスメモリ（ＤＲＡＭ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、ソリッドステート装置、フラッシュドライブ、ＣＤ−ＲＯＭ、サムドライブ、フロッピーディスク（登録商標）、テープ、ハードディスク、及び／又は任意の他のタイプの揮発性又は不揮発性であり物理的又は有体的なコンピュータ可読媒体。非限定的に例示すれば、メモリ２０４は次のものを格納するように構成され得る：ＩＡＶ、ＡＡＶ、認証リクエスト、鍵、ＭＡＣ、ＤＳＲＰ暗号、トークン、口座番号（例えば、ＰＡＮ等）、並びに／又は本明細書中にて説明された用途に適した他のタイプのデータ（及び／若しくはデータ構造）。さらに、様々な実施形態では、コンピュータ実行可能命令は、プロセッサ２０２によって実行されるようにメモリ２０４内に格納されることができるのであり、これによって本明細書中にて説明された１つ以上の機能をプロセッサ２０２に行わせるのであり、メモリ２０４は物理的、有体的、及び非一時的なコンピュータ可読記憶媒体である。そのような命令は、多くの場合、｛プロセッサ２０２及び／又は本明細書中にて説明された１つ以上の様々なオペレーションを行うように構成された他のコンピュータシステムコンポーネント｝の効率及び／又は性能を向上させる。メモリ２０４は異なる様々なメモリを含み得ることに留意されたいのであり、各々は本明細書中にて説明された１つ以上の機能を実現するように構成されている。

例示的実施形態では、コンピューティング装置２００は、プロセッサ２０２に（通信可能に）接続されている出力装置２０６をも含む。出力装置２０６は購入の確認やチャレンジ質問等の情報を視覚的に出力するのであり、例えばそれを消費者１０２に提示したりするのであり、又は他の情報を図１に図示された任意のエンティティに関連する他のユーザに各々のコンピューティング装置等にて提示等する。非限定的に例示すれば、出力装置２０６は、次のものを含み得る：液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、「電子インク」ディスプレイ、スピーカ等。一部の実施形態では、出力装置２０６は複数の装置を含み得る。

追加的に、コンピューティング装置２００は、ユーザからの入力（即ち、ユーザ入力）を受信する入力装置２０８を含むのであり、例えば、消費者１０２からのチャレンジ質問への回答、チェックアウト時入力、支払口座クレデンシャル等や、システム内の他のユーザ等からの他の情報を含む等できる。入力装置２０８は、単一の入力装置又は複数の入力装置を含み得る。入力装置２０８はプロセッサ２０２に（通信可能に）接続されており、例えば次の１つ以上を含み得る：キーボード、ポインティングデバイス、マウス、タッチ感応式パネル（例えば、タッチパッドやタッチスクリーン等）、別のコンピューティング装置、及び／又は音声入力装置。さらに、様々な例示的実施形態では、例えばタブレットやスマートフォンや類似の装置に含まれるタッチスクリーンは、出力装置２０６及び入力装置２０８の双方として振る舞うことができる。

さらに、図示されたコンピューティング装置２００は、プロセッサ２０２とメモリ２０４とに（通信可能に）接続されたネットワークインタフェース２１０をも含む。非限定的に例示すれば、ネットワークインタフェース２１０は、次のものを含み得る：有線ネットワークアダプタ、無線ネットワークアダプタ、モバイルネットワークアダプタ、又は１つ以上の異なるネットワーク及び／若しくは本明細書に挙げる１つ以上の他のコンピューティング装置と通信することができる他の装置。

図３は例示的方法３００について示すのであり、該方法は消費者が商人にてなすトランザクションとの関連で消費者に提供するサービスに関するのであり、強化した消費者認証をさらに組み合わせたものに関する。例示的方法３００は、（図１を参照して）一般的にはＤＳＳ１１０、ディレクトリサーバ１１８、及びシステム１００の支払ネットワーク１３６を用いて実装されるものとして説明されており、さらにはコンピューティング装置２００への言及を伴って説明される。もっとも、勿論のことであるが、本明細書中の方法は、例示的システム１００又は例示的コンピューティング装置２００に限定して理解されるべきものではなく、また、本明細書中のシステム及びコンピューティング装置は例示的方法３００に限定して理解されるべきものではない、ということに留意されたい。

図示の方法３００においては、消費者１０２が開始した商人１０６とのトランザクションに関して、３０２にてディレクトリサーバ１１８は、ＡＲｅｑを、商人１０６と関連付けられたＭＰＩ１１４（又は３ＤＳサーバ）からまず受信する。この例示的実施形態では、ＡＲｅｑは、（トランザクションに用いられる）消費者１０２の支払口座用のトークンと、トランザクション用のＤＳＲＰ暗号（図３においては、「クリプト」と称する）とを含む。これを受けて、３０４にてディレクトリサーバ１１８は、トークン及びＤＳＲＰ暗号をＤＳＳ１１０へと送信する。トークンが、本明細書中にて説明する方法と関連付けられているトークン範囲（又はＰＡＮについてのＢＩＮ範囲）内にある故に、ディレクトリサーバ１１８はこのように振る舞う。

そして、３０６にてＤＳＳ１１０がトークンを消費者の支払口座についての口座番号（即ち、この例ではＰＡＮ）へとマッピングする。そして、３０８にてＤＳＳ１１０は（随意的に）ＤＳＲＰ暗号を検証する。この実施形態では、ＤＳＲＰ暗号の検証は、消費者の支払口座及び／又は支払口座のトークンと共にプロビジョニングされたウォレットアプリケーションとＤＳＳ１１０との間で共有される対称鍵に基づいてなされている。より具体的には、ＤＳＳ１１０は、発行者マスタ対称鍵からマスタ鍵を分化し（例えば、発行者１０４等のためにＤＳＳ１１０によって生成された鍵等）、また、そしてマスタ鍵から１つ以上のセッション鍵を分化する（例えば、ＤＳＳ１１０等によって管理されたＡＴＣに基づいて等）。そして、ＤＳＳ１１０は、セッション鍵を用いてＤＳＲＰ暗号を検証する。

代替的には、ＤＳＲＰ暗号を検証する代わりに、ＤＳＳ１１０は、再度の呼び出しのためにＤＳＲＰ暗号を（例えば、メモリ２０４等の）メモリ内に格納することができるのであり、（例えばＤＳＮ等に基づく等して）後述のようにする。

ＤＳＲＰ暗号検証が失敗した場合、ＤＳＳ１１０はトランザクション失敗メッセージをもってディレクトリサーバ１１８に応答を返すのであり、これは商人１０６及び／又はＭＰＩ１１４（又は３ＤＳサーバ）に戻されるように与えられるか（この場合トランザクションは停止される）、又は、発行者１０４によって指定されるようにして他の態様で処理され得る（例えば、発行者１０４は検証無し等でトランザクションが進行することを許し得る等）。他方で、ＤＳＲＰ暗号検証が成功した場合、３１０にてＤＳＳ１１０はＤＳＮを生成する。ＤＳＮは、例えば、ＡＴＣについての連結文字列若しくはその一部と（例えば、最下位バイト等）予測不可能な値（例えば、ランダムに生成された値、ＤＳＳ１１０の秘密鍵に基づいたハッシュ関数、又は秘密鍵に基づいたＭＡＣ計算、又は、他の適切な値等）とを含む。ＤＳＮは任意の適切な長さ及び／又はフォーマットとすることができるも、図３の例示的実施形態では、ＤＳＮは４バイトフォーマット（即ち、３２ビット）である（例えば、ＡＴＣの最下位バイト及びランダムに生成された値についての３バイト等）。上述にかかわらず、随意的には、方法３００に関して３０８にて検証する代わりに、ＤＳＲＰ暗号が格納された際には、３１０にてＤＳＳ１１０はＤＳＮを生成することができる。

３０８にてＤＳＲＰ暗号が検証されると、ＤＳＳ１１０はＡＴＣが使用済み又は「進行中」であるとさらに指定し、方法３００が進行するに際しては後の許可リクエスト（authorization request）において後述のように用いられ得るが、他の任意の目的には用いることができないものとされる（例えば、同じＤＳＲＰ暗号を伴う別のＡＲｅｑを防止する等）。そして、方法３００においては、３１２にてＤＳＳ１１０は、ＤＳＮ及びトークンと関連付けられた口座番号をディレクトリサーバ１１８へと送信する。

３１４にてディレクトリサーバ１１８は、トランザクションの額の対数（即ち額の対数）を計算し、また、３１６では商人ＩＤ（例えば、名称及び／又は所在等）についての打ち切りハッシュをも計算する。額の対数が計算されるものの（例えば、それによって額を表す４乃至６バイトを対数とした額についての２バイトにまで削減する等）、他の実施形態では他の手法を用いて額を圧縮したり圧縮しなかったりすることができるということに留意されたい。同様に、他の実施形態では、商人ＩＤを圧縮したり圧縮しなかったりすることができ、その場合には打ち切り及び／又はハッシング等の技術を超える手法やそれらとは異なる１つ以上の手法を用い得る。もっとも、一般的には、圧縮された額及び商人ＩＤ（存在する場合）は、未圧縮の額及び／又は商人ＩＤを提供する場合に比してデータ（又は領域的）削減をもたらすことになる。

その後、３１８にてディレクトリサーバ１１８は、ＡＲｅｑをＡＣＳ１２４へと送信するのであり、ＡＲｅｑは、消費者の支払口座についての口座番号とＤＳＮと計算された額についての対数と商人ＩＤについての打ち切りハッシュとを含む。それをなすに際して、ディレクトリサーバ１１８は具体的なＡＣＳ１２４を識別するのであり、消費者の支払口座番号に基づいて識別がなされ、また、特に口座番号のＢＩＮが特定範囲内にあることに基づいてなされ、又は、ＡＲｅｑの全部若しくは一部に含まれる他の指標に基づいてなされる。様々な実施形態では、ＡＲｅｑは脱トークナイゼーションフラグをさらに含み得るのであり、該フラグは、ＡＲｅｑが（トークンからＤＳＳ１１０によって変換された）口座番号を含んでいることをＡＣＳ１２４に示すものである。

そして上述したように、ＡＣＳ１２４は、危険性に基づいた（リスクベースドな）財務アセスメントをトランザクションに関して行うのであり、それにおいては、ＡＣＳ１２４が消費者１０２を認証したり認証しなかったりすることができる。慣例的でもあり得るが、随意的には、ＡＣＳ１２４は、ディレクトリサーバ１１８を用いて、消費者１０２に対して課すチャレンジ質問を開始することができ、それにおいてはＡＣＳ１２４との対話を通じて消費者１０２が認証される。そして、一旦消費者１０２が認証されると、それがリスクベースドな評価によってなされたかチャレンジ質問によってなされたか他の態様によってなされたかを問わずに、３２０においてＡＣＳ１２４はトランザクションについてのＩＡＶを生成するのであり、該ＩＡＶは例えば次のことを含む：額についての対数又は未圧縮表現、商人ＩＤについての打ち切りハッシュ、及びトランザクションについての通貨コード等。一般に、この例示的実施形態では、ＩＡＶは暗号学的に生成されたＨＭＡＣ値を含む４バイト分の値を格納している。とはいっても、他の実施形態では、異なる暗号学的手法を用いてＩＡＶを生成できるということにも留意されたい。そして、３２２にてＩＡＶはＡＣＳ１２４によってディレクトリサーバ１１８へと送信される（これによってディレクトリサーバ１１８がＩＡＶを受信する）。

他方で、消費者１０２の認証が失敗した場合、ＡＣＳ１２４は認証の失敗をディレクトリサーバ１１８へと伝達するのであり（或いは潜在的には、発行者１０４によって別異に規定されている場合には他の態様で応答するのであり）、伝達事項はＭＰＩ１１４（又は３ＤＳサーバ）及び商人１０６へと渡される（これによって商人１０６はトランザクションを停止又は却下等できる）。

次に、３２４にてディレクトリサーバ１１８はＭＡＣを生成し、３２６にて完全ＡＡＶをトランザクションのためにコンパイルする。具体的には、この例示的実施形態では、ディレクトリサーバ１１８は、（ＡＣＳ１２４から受信された）ＩＡＶとＤＳＮと額の対数と通貨コードと商人ＩＤについての打ち切りハッシュ（と潜在的には他の管理データ）とを組み合わせるのであり、また、（例えば、上述のデータ、対称鍵及び暗号学的関数等に基づいて）ＭＡＣを生成等する。ディレクトリサーバ１１８は、上述のデータ及びＭＡＣを完全ＡＡＶへとコンパイルする。図４は、例示的な完全ＡＡＶ４００についてのブロック図であり、２１バイト分のバイナリデータが含まれる。具体的には、ＩＡＶが４バイトを占め、ＤＳＮが４バイトを占め、額の対数が２バイトを占め、商人ＩＤについての打ち切りハッシュが４バイトを占め、通貨コードが１．５バイトを占め、（ＭＡＣを生成するのに用いられた共有鍵の識別子である）鍵ＩＤが０．５バイトを占め、また、ＭＡＣが３バイトを占める。完全ＡＡＶ４００はさらに２バイトのバージョン情報を含み、これは例えば次の事柄を示す：完全に認証されたものとしてのＩＡＶのタイプ、商人試行及びフォーマット、又は他のこと等。上述の通りであるが、他の実施形態では完全ＡＡＶ４００は同じ又は異なるデータを含み得るのであり、１つ以上の異なるフォーマット及び／又は１つ以上の異なるサイズを伴い得るのであるが、一般的には少なくともＩＡＶとＤＳＮとを含むことによってさらなる（後述の）オペレーションを促進する。

そして、３２８にてディレクトリサーバ１１８は、完全ＡＡＶを商人１０６へと、具体的に述べればＭＰＩ１１４（又は３ＤＳサーバ）へと、送信する。

これを受けて、図３に不図示であるも、商人１０６は、トランザクション用の許可リクエストをコンパイルしてアクワイアラ１３２へと送信するのであり、これは完全ＡＡＶを含んでいる。１つの特定の例では、完全ＡＡＶはＵＣＡＦ内に含まれており、これはＩＳＯ８５８３許可リクエストのデータエレメント（ＤＥ、data element）４８に所在している。コンパイルされた許可リクエストは一般的には、許可リクエストにおいて慣例的にみられる他のデータを含む（例えば、商人ＩＤ、消費者の氏名、トランザクション額、支払口座クレデンシャル等）。そして、許可リクエストはアクワイアラ１３２から渡されて、３３０において支払ネットワーク１３６で受信される。

３３２にての許可リクエストの受領に際して支払ネットワーク１３６は完全ＡＡＶを検証するのであり、具体的には完全ＡＡＶ内に含まれるＭＡＣを検証することによってこれをなす。具体的には、支払ネットワーク１３６は、完全ＡＡＶ内の鍵ＩＤに基づいて、ディレクトリサーバ１１８によってＭＡＣが生成された際の共有鍵を見つける。そして、支払ネットワーク１３６は、共有鍵及び完全ＡＡＶ内に含まれたデータに基づいてＭＡＣを生成する（３２４にてＭＡＣを生成する際にディレクトリサーバ１１８によって依拠されたデータと整合する）。一旦生成されると、支払ネットワーク１３６は、ＭＡＣを完全ＡＡＶ内に含まれたＭＡＣにマッチングさせて、それによってＭＡＣ及び／又は完全ＡＡＶを検証する。この実施形態では、許可リクエストが発行者１０４へ渡ることが許される前に、ＭＡＣが検証される。上述の通りであるが、他の実施形態では、完全ＡＡＶについての更なる検証及び／又はテストをここにて含めることも可能である、という点に留意されたい（例えば、完全ＡＡＶ内のバージョン情報に基づく場合等）。

一旦検証されると、３３４にて支払ネットワーク１３６は、トークン（又は場合によっては口座番号）及びＤＳＮを含む許可リクエストを、そして随意的には完全ＡＡＶを、ＤＳＳ１１０へと送信する。受領されると、３３６にてＤＳＳ１１０は、（３０８にて検証されると）ＤＳＮに基づいてＤＳＲＰ暗号の検証を確認するか、又は、（例えば、メモリ２０４等の）メモリ内に含まれるＤＳＲＰデータに基づいてＤＳＲＰ暗号を検証してＤＳＮに基づいて位置を特定する。追加的には、３３８にてＤＳＳ１１０は、許可リクエスト内に含まれたトークンを、関連付けられた口座番号（例えば、ＰＡＮ等）へとマッピングする。その後、３４０にてＤＳＳ１１０は、口座番号及び検証結果を支払ネットワーク１３６に戻す。これを受けて、３４２にて支払ネットワーク１３６は許可リクエストを発行者１０４へと送るのであり、これは少なくとも口座番号とＤＳＲＰ暗号の検証についての確認（confirmation of validation）と、ＩＡＶを含む完全ＡＡＶからのデータとを含む。

これを受けて、３４４にて発行者１０４は、発行者１０４とＡＣＳ１２４との間で共有された共有鍵（即ち、ＩＡＶを生成するのに用いられた鍵）に基づいてＩＡＶを検証し、また、可能性としては、トランザクションに関して１つ以上の金融評価をなす。追加的な金融評価は従来的な又は他の基準に基づいて提供され得る（例えば、消費者の支払口座が良好な状態にあるか否かや、支払口座が十分な資金／クレジットを含んでいるか或いは不正スコア等）。トランザクションが検証及び／又は承認（approve）されると、発行者１０４はトランザクションについての許可応答（authorization response）をコンパイルして、３４６にて許可応答を支払ネットワーク１３６に戻すように送信する。そして、３４８にて支払ネットワーク１３６は、許可応答をアクワイアラ１３２を介して商人１０６へと送信する。他方で、検証が失敗した場合、発行者１０４は、リスクを負ってでもして適切な許可応答を介してトランザクションを進行させるか、又は、上述のようにして許可応答を商人１０６へと戻すように送信することによってトランザクション却下を行う。

方法３００はトランザクションにおいてトークンを用いることとの関連で説明されるが、方法３００は次のようなトランザクションにも適用可能であることに留意されたい：即ち、許可リクエストがＰＡＮ又は他の口座番号をトークンの代わりに含んでおり、方法３００におけるトークンの取り扱い及び／又はトークンのアカウントへのマッピングに具体的に関連する特定のステップが省略され得る場合。さらに述べるに、ディレクトリサーバ１１８及び／又はＤＳＳ１１０にとってトークンが未知のものであるか未登録のものである場合であってトークン−口座番号マッピング行為が行えない場合、代わりに発行者１０４及び／又はＡＣＳ１２４がトークンを扱うことができる。上述の説明と一般的には整合しているものの、このバリエーションでは、暗号が一旦提供されると、ＡＣＳ１２４は所与のトークンと関連付けられた別のＤＳＳ（不図示）と通信して暗号検証及び他のトークンサービスを執り行う。追加的に、（ディレクトリサーバ１１８に依存する代わりに）ＡＣＳ１２４はＤＳＮを生成でき、これがＩＡＶと共にディレクトリサーバ１１８へと戻されるのであり、上述した用途に供される。

上述のように、本明細書中のシステム及び方法は、完全ＡＡＶを通じて２つの異なるドメインでの検証機能をもたらす。例えばＡＡＶについて具体的に述べるに、ＡＡＶはＩＡＶと他のデータとに分離されるのであり、前者たるＩＡＶはＡＣＳ／発行者ドメインにて生成及び検証され、後者たる他のデータは支払ネットワークドメインにて生成及び検証される。ＡＡＶをこのような態様によって分離することによって、本明細書中のシステム及び方法は、次のことを可能とする：発行者１０４及びＡＣＳ１２４がＩＡＶを通じて不正トランザクションを抑止すること（ＩＡＶはＡＡＶと関連付けられている他のデータの生成及び検証オペレーションとは独立に扱われる）。このようにして、一般的には発行者１０４及びＡＣＳ１２４の動作及び／又は相互作用に影響を与えずにして本件対象のセキュリティ及び／又は機能性を変更及び／又は向上させるようにして、支払ネットワーク１３６、ディレクトリサーバ１１８、及び／又はＤＳＳ１１０に変更を加えることができる（例えば、ＩＡＶを、フォーマット変更やＵＣＡＦ詳細事項の変更等から隔離すること）。さらに述べるに、支払ネットワーク１３６は、上述のようなトランザクション検証を提供できるのであり、また、そのような検証を更なるデータとして発行者１０４に提供できるのであり、該更なるデータはトランザクションの承認又は却下に関連付けられている。

上述は、ＡＣＳ１２４がＡＡＶの全体を生成しこれは発行者１０４によってのみ検証できるものとされる伝統的なＡＡＶから離れる構成であることに留意されたい（ＡＣＳが発行者の鍵を用いてそのような生成を行ったからである）。また、上述から明らかなように、ＩＡＶを生成及び検証するのに用いられた共有鍵（即ち、発行者鍵及びＡＣＳ鍵）は、ディレクトリサーバ１１８（又は支払ネットワーク１３６）と共有されることは必要とされておらず、他方では、ＭＡＣを生成及び検証するのにディレクトリサーバ１１８及び／又は支払ネットワーク１３６によって用いられた鍵もＡＣＳ１２４及び／又は発行者１０４と共有されることを要さない。このようにして、本明細書中のシステム及び方法においての鍵管理は合理化及び単純化される。

再度であるが、先述したように、本明細書にて説明した機能は、一部の実施形態では、コンピュータ可読媒体上に格納されたそして１つ以上のプロセッサによって実行可能なコンピュータ実行可能命令として記述され得る。コンピュータ可読媒体は、非一時的なコンピュータ可読記憶媒体である。限定を伴わずに例示するに、そのようなコンピュータ可読媒体は次のものを含み得る：ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ若しくは他の光学ディスク記憶域、磁気ディスク記憶域若しくは他の磁気記憶装置、又は、所望のプログラムコードを命令又はデータ構造としてキャリー又は格納できまたコンピュータによってアクセスされ得る任意の他の媒体。上述についての組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。

本開示の１つ以上の観点によれば、説明した機能、方法、及び／又は処理を行うように構成された場合、汎用用途コンピューティング装置が専用用途コンピューティング装置へと転換されることになり得ることにも留意されたい。

先述の詳細な説明の記載から了知されるように、本開示について上述の実施形態は、以下のオペレーションの少なくとも１つを行うことによって技術的効果を奏することができるのであり、その際には（例えば、コンピュータソフトウェア、ファームウェア、ハードウェア又はそれらの任意の組み合わせ若しくは部分集合を含む）コンピュータプログラミング手法又はコンピュータエンジニアリング手法を用いてこれらを実装できる：（ａ）少なくとも１つのコンピューティング装置によって、支払口座に関連付けられたトランザクションについての認証リクエストを受信するステップであって、認証リクエストは支払口座と関連付けられたトークン及び暗号を含むステップ；（ｂ）少なくとも１つのコンピューティング装置によって、トークンを支払口座についてのプライマリ口座番号（ＰＡＮ、primary account number）へとマッピングするステップ；（ｃ）少なくとも１つのコンピューティング装置によって、暗号を検証するステップ；（ｄ）少なくとも１つのコンピューティング装置によって、認証リクエストについてディレクトリサーバノンス（ＤＳＮ、directory server nonce）を生成するステップ；（ｅ）少なくとも１つのコンピューティング装置によって、ＤＳＮと口座番号とを、支払口座の発行者と関連付けられたアクセス制御サーバ（ＡＣＳ、access controller server）へと送信するステップ；（ｆ）発行者認証値（ＩＡＶ、issuer authentication value）に応答して、少なくとも１つのコンピューティング装置によって、口座所持者認証値（ＡＡＶ、accountholder authentication value）をコンパイルするステップであって、ＡＡＶはＩＡＶとＤＳＮとトランザクションの額とを含む、ステップ；（ｇ）ＡＡＶを商人及びサーバの一方へと送信することによって、商人がＡＡＶを含むトランザクションについての許可リクエストをコンパイル及び送信することを許し、また、発行者がトランザクションを承認する前にＩＡＶを検証することを許す、ステップ；（ｈ）トランザクションの額及び商人と関連付けられた商人ＩＤの少なくとも１つを圧縮するステップ；（ｉ）少なくとも１つのコンピューティング装置によってメッセージ認証コード（ＭＡＣ、message authentication code）を生成するステップであってＡＡＶはＭＡＣを含むステップ；（ｊ）ＡＡＶを含む許可リクエストに応答して、ＭＡＣを検証するステップ；（ｋ）ＭＡＣ検証後にトークンをＰＡＮへとマッピングするステップ、及び、ＰＡＮ及び検証結果を伴う許可リクエストを支払口座の発行者へと送信するステップ；（ｌ）鍵及び少なくともＰＡＮ及びＤＳＮに基づいてＡＣＳによってＩＡＶを生成するステップ；（ｍ）共有鍵及び少なくともＰＡＮ及びＤＳＮに基づいて発行者コンピューティング装置によってＩＡＶを検証するステップ。

本開示が十分に詳細なものとなるようにし、また、当業者に全容を知らしめるために、例示的実施形態が提供されている。本開示の実施形態についての十分な理解をもたらすために、例えば具体的なコンポーネント、装置、及び方法についての例等の幾つもの具体的詳細事項が提示されている。当業者にとっては次のことが自明である：具体的な詳細事項を踏襲しなくても良い場合があること、例示的実施形態は多くの異なる形態をもって実施され得ること、及び、両者は本開示の範囲を限定するものとして解されてはならないこと。幾つかの例示的実施形態では、周知の処理、周知の装置構造、及び周知の技術に関しては、詳細までは述べない。

本明細書にて用いられる用語は、特定の例示的実施形態を説明するためのものにすぎず、限定的に解されることは意図されていない。文脈が逆を明示していない限り、本明細書で用いられている「a」、「an」、及び「the」を冠した単数形は、複数形をも含むものとして意図され得る。「備える」、「備えている」、「含む」、及び「有する」との用語は、包含的な意義を有し故に提示された特徴、要素、ステップ、オペレーション、構成要素、及び／又はコンポーネントの存在を指定するのであるが、１つ以上の他の特徴、要素、ステップ、オペレーション、構成要素、コンポーネント、及び／又はそれらの群の存在又は追加を除外はしない。遂行順序が具体的に指定された場合を除き、本明細書で説明された方法のステップ、処理、及びオペレーションは、論じられたか例示された特定の順序でなされることを要するとは解されない。また、追加的又は代替的ステップを伴うことも可能であることに留意されたい。

要素が他の要素との関係で「の上にある」、「と係合している」、「と接続している」、「と結合している」、「と関連付けられている」、「と共に含まれている」、「と通信可能に連なっている」と説明されている場合は、要素は他の要素との関係で直接乗っていたり、係合していたり、接続していたり、結合していたり、関連付けられていたり、一緒に含まれていたり、通信可能に連なっていたりするのであり、又は、他の介在する要素が存在し得る。本明細書で用いられる場合、「及び／又は」との用語は、１つ以上の関連付けられて列挙された事項についての全ての任意の組み合わせを含む。

第１、第２、第３等の用語を用いて本明細書にて様々な要素について説明することができるも、これらの要素はそれらの用語によって限定されてはならない。これらの用語は、要素に関しての互いの区別のために限って用いられるものと了解されたい。「第１」、「第２」及び他の数についての用語は、文脈によって明示されていない限り、序列又は順序を示唆するものではない。したがって、例示的実施形態の教示事項から逸脱せずに、第１の要素を第２の要素と呼び変えることもできる。

構成要素が「のための手段」とのフレーズを伴って、又は、方法クレームの場合は「のためのオペレーション」若しくは「のためのステップ」とのフレーズを伴って明示的に記載されていない限り、請求項中に記載された構成要素は合衆国法典第３５巻第１１２条（ｆ）にいうミーンズプラスファンクション式構成要素と解されることが意図されていない。

例示的実施形態についての上述の説明は、例示及び説明目的で供されている。網羅的であることは意図されておらず、開示を限定することは意図されていない。特定の実施形態の個々の構成要素及び特徴は、一般にはその特定の実施形態に限られていないのであり、該当する場合には可換であり、具体的に示されているか説明されていなくても選択された実施形態で用いられることができる。そしてそれは様々な態様で変更されることもできる。そのようなバリエーションは、本会時からの逸脱とみなされるべきではなく、また、そのような変更の全ては本開示の範囲内に含まれるものとして意図されている。

１００ システム
１０２ 消費者
１０４ 発行者
１０６ 商人
１１０ ＤＳＳ
１１４ ＭＰＩ
１１８ ディレクトリサーバ
１２４ ＡＣＳ
１３２ アクワイアラ
１３６ 支払ネットワーク
２００ コンピューティング装置
２０２ プロセッサ
２０４ メモリ
２０６ 出力装置
２０８ 入力装置
２１０ ネットワークインタフェース
４００ ＡＡＶ

Claims (20)

1. ネットワークトランザクションとの関連でユーザを口座に対して認証するに際して用いるためのシステムであって、該システムは、
   ディレクトリサーバと、
   前記ディレクトリサーバと通信可能に接続されたデジタルサービスサーバ（ＤＳＳ、digital service server）とを備え、
   前記ディレクトリサーバは、
   支払口座と関連付けられたトランザクションについての認証リクエストを受信するステップであって、前記支払口座は口座番号と関連付けられており、前記認証リクエストは前記支払口座と関連付けられたトークン及び前記口座番号の少なくとも１つを含んでいる、ステップと、
   前記トークン及び前記口座番号の前記少なくとも１つを前記ＤＳＳへと送信するステップとを行うように構成されており、
   前記ＤＳＳは、
   前記認証リクエストについてディレクトリサーバノンス（ＤＳＮ、directory server nonce）を生成するステップと、
   前記ＤＳＮと前記口座についての前記口座番号とを前記ディレクトリサーバへと送信するステップとを行うように構成されており、
   前記ディレクトリサーバは、
   前記ＤＳＮと前記口座番号とを、前記支払口座の発行者と関連付けられたアクセス制御サーバ（ＡＣＳ、access controller server）へと送信するステップと、
   発行者認証値（ＩＡＶ、issuer authentication value）に応答して、口座所持者認証値（ＡＡＶ、accountholder authentication value）をコンパイルするステップであって、前記ＡＡＶは前記ＩＡＶと前記ＤＳＮと前記トランザクションの額とを含む、ステップと、
   前記ＡＡＶを、前記トランザクションに関与しているエンティティと関連付けられたサーバへと送信するステップであって、前記エンティティは前記ＡＡＶを許可リクエスト内に含めることを許されており、また、前記発行者は前記トランザクションを承認する前に前記ＩＡＶを検証することを許されている、ステップとを行うように構成されている、システム。
2. 請求項１に記載のシステムにおいて、前記認証リクエストは前記口座についての前記トークンを含み、
   前記ＤＳＳは、前記口座番号を前記ディレクトリサーバへと送信する前に、前記トークンを前記口座の前記口座番号へとマッピングするようにさらに構成されている、システム。
3. 請求項１に記載のシステムにおいて、前記認証リクエストは暗号を含み、
   前記ＤＳＳは、前記ＤＳＮを前記ディレクトリサーバへと送信する前に、前記暗号を検証するように構成されている、システム。
4. 請求項１に記載のシステムにおいて、前記認証リクエストは暗号を含み、
   前記ＤＳＳは、
   前記ＤＳＮを前記ディレクトリサーバへと送信する前に、前記暗号をメモリ内に格納し、
   前記ＤＳＮに基づいて前記メモリ内で前記暗号を位置付けて、
   前記完全なＡＡＶを含む許可リクエストに応答して前記暗号を検証するように構成されている、システム。
5. 請求項１に記載のシステムにおいて、前記トランザクションの前記額は前記トランザクションの額の対数を含み、
   前記ＡＡＶは商人ＩＤをさらに含む、システム。
6. 請求項１に記載のシステムにおいて、前記ディレクトリサーバは少なくとも前記ＤＳＮに基づいてメッセージ認証コード（ＭＡＣ、message authentication code）を生成するようにさらに構成されており、前記ＡＡＶは前記ＭＡＣを含み、
   前記システムは、
   前記ＡＡＶを含む前記許可リクエストを受信し、
   前記ディレクトリサーバと共有されている共有鍵に基づいて前記ＭＡＣを検証し、
   前記許可リクエスト又はその一部を前記ＤＳＳへと送信するように構成された支払ネットワークをさらに含む、システム。
7. 請求項６に記載のシステムにおいて、前記ＤＳＳは、前記認証リクエストに含まれたデジタルセキュア遠隔支払（ＤＳＲＰ、digital secure remote payment）暗号を検証し、また、前記ＤＳＲＰ暗号についての検証結果を前記支払ネットワークに対して提供するようにさらに構成されており、
   前記支払ネットワークは、前記検証結果を含む前記許可リクエストを、前記支払口座の前記発行者へと送信するように構成されている、システム。
8. 請求項１に記載のシステムにおいて、前記ＤＳＮは、アプリケーショントランザクションカウント（ＡＴＣ、application transaction count）及びランダムに生成された値を少なくとも含む、システム。
9. 請求項１に記載のシステムにおいて、前記トランザクションの前記額は前記トランザクションの額の対数を含み、
   前記ＡＡＶは、前記ＩＡＶと前記ＤＳＮと前記額の対数と前記エンティティについての商人ＩＤの打ち切りハッシュと通貨コードと共有鍵についての鍵ＩＤと前記共有鍵によって生成されたＭＡＣとを、含む、システム。
10. トランザクションとの関係でユーザを支払口座に対して認証するに際して用いるためのコンピュータ実施方法であって、該方法は、
    少なくとも１つのコンピューティング装置によって、支払口座に関連付けられたトランザクションについての認証リクエストを受信するステップであって、前記認証リクエストは前記支払口座と関連付けられたトークン及び暗号を含むステップと、
    前記少なくとも１つのコンピューティング装置によって、前記トークンを前記支払口座についてのプライマリ口座番号（ＰＡＮ、primary account number）へとマッピングするステップと、
    前記少なくとも１つのコンピューティング装置によって、前記暗号を検証するステップと、
    前記少なくとも１つのコンピューティング装置によって、前記認証リクエストについてディレクトリサーバノンス（ＤＳＮ、directory server nonce）を生成するステップと、
    前記少なくとも１つのコンピューティング装置によって、前記ＤＳＮと前記口座番号とを、前記支払口座の発行者と関連付けられたアクセス制御サーバ（ＡＣＳ、access controller server）へと送信するステップと、
    発行者認証値（ＩＡＶ、issuer authentication value）に応答して、前記少なくとも１つのコンピューティング装置によって、口座所持者認証値（ＡＡＶ、accountholder authentication value）をコンパイルするステップであって、前記ＡＡＶは前記ＩＡＶと前記ＤＳＮと前記トランザクションの額とを含む、ステップと、
    前記ＡＡＶを商人及びサーバの一方へと送信することによって、前記商人が前記ＡＡＶを含む前記トランザクションについての許可リクエストをコンパイル及び送信することを許し、また、前記発行者が前記トランザクションを承認する前に前記ＩＡＶを検証することを許す、ステップとを含む、コンピュータ実施方法。
11. 請求項１０に記載のコンピュータ実施方法において、前記ＤＳＮは、アプリケーショントランザクションカウント（ＡＴＣ、application transaction count）及びランダムに生成された値を少なくとも含む、コンピュータ実施方法。
12. 請求項１０に記載のコンピュータ実施方法において、該方法は、前記トランザクションの額及び前記商人と関連付けられた商人ＩＤの少なくとも１つを圧縮するステップをさらに含み、
    前記ＡＡＶは、前記額及び前記商人ＩＤの少なくとも１つについての圧縮されたものを含む、コンピュータ実施方法。
13. 請求項１０に記載のコンピュータ実施方法において、該方法は、前記少なくとも１つのコンピューティング装置によってメッセージ認証コード（ＭＡＣ、message authentication code）を生成するステップであって前記ＡＡＶは前記ＭＡＣを含むステップと、
    前記ＡＡＶを含む許可リクエストに応答して、前記ＭＡＣを検証するステップとをさらに含む、コンピュータ実施方法。
14. 請求項１１に記載のコンピュータ実施方法において、該方法は、前記ＭＡＣの検証後に前記トークンを前記ＰＡＮへとマッピングするステップと、前記ＰＡＮ及び検証結果を伴う前記許可リクエストを前記支払口座の前記発行者へと送信するステップとをさらに含む、コンピュータ実施方法。
15. 請求項１４に記載のコンピュータ実施方法において、前記ＡＡＶは、前記ＩＡＶと前記ＤＳＮと前記トランザクションの額の対数の値と前記商人についての商人ＩＤの打ち切りハッシュと通貨コードと前記ＭＡＣを生成するのに用いられた共有鍵についての鍵ＩＤと前記ＭＡＣとを、含む、コンピュータ実施方法。
16. 請求項１４に記載のコンピュータ実施方法において、該方法は、
    鍵及び少なくとも前記ＰＡＮ及び前記ＤＳＮに基づいて前記ＡＣＳによって前記ＩＡＶを生成するステップと、
    前記共有鍵及び少なくとも前記ＰＡＮ及び前記ＤＳＮに基づいて発行者コンピューティング装置によって前記ＩＡＶを検証するステップとをさらに含む、コンピュータ実施方法。
17. ネットワークトランザクションとの関連でユーザを口座に対して認証するに際して用いるためのシステムであって、該システムは、
    ディレクトリサーバであって、
    支払口座と関連付けられたトランザクションについての認証リクエストを受信するステップであって、前記支払口座はプライマリ口座番号（ＰＡＮ、primary account number）によって識別され、前記認証リクエストは暗号とトークン及び前記ＰＡＮの少なくとも１つとを含む、ステップと、
    前記ＰＡＮと前記トランザクションについてのＤＳＮと前記トランザクションについての額とを、前記口座の発行者に関連付けられたアクセス制御サーバ（ＡＣＳ、access controller server）へと送信するステップと、
    発行者認証値（ＩＡＶ、issuer authentication value）を前記ＡＣＳから受信するステップと、
    口座所持者認証値（ＡＡＶ、accountholder authentication value）をコンパイルするステップであって、前記ＡＡＶは前記ＩＡＶと前記ＤＳＮと前記トランザクションの前記額とを含む、ステップと、
    前記ＡＡＶを、前記トランザクションに関与している商人と関連付けられたサーバ及び／又は前記商人へと送信するステップであって、発行者は、前記トランザクションを承認する前に前記トランザクションについての前記ＡＡＶを含む許可リクエストを受領すると、共有鍵に基づいて前記ＩＡＶを検証することを許されている、ステップとを行うように構成されたディレクトリサーバ、を含む、システム。
18. 請求項１７に記載のシステムにおいて、前記ディレクトリサーバは、前記ＤＳＮを前記ＡＣＳへと送信する前に、デジタルサービスサーバ（ＤＳＳ、digital service server）から前記ＤＳＮを受信するように構成されている、システム。
19. 請求項１８に記載のシステムにおいて、前記ディレクトリサーバは、少なくとも前記ＤＳＮに基づいて前記トランザクションについてのメッセージ認証コード（ＭＡＣ、message authentication code）を生成して、前記ＭＡＣを前記ＡＡＶへとコンパイルするように構成されており、
    前記システムはサーバを更に含み、当該サーバは、前記許可リクエストが前記発行者へと通過していくことを許す前に、前記トランザクションについての前記許可リクエスト内にて前記ＡＡＶが受信されると前記ＭＡＣを検証するように構成される、システム。
20. 請求項１９に記載のシステムにおいて、前記ディレクトリサーバは、前記トランザクションの額についての対数値を決定しまた前記商人についての商人ＩＤの打ち切りハッシュを決定するようにさらに構成されており、
    前記トランザクションの前記額は前記対数値を含み、
    前記ＡＡＶは前記対数値と前記商人ＩＤの打ち切りハッシュとを含む、システム。

Images