专利名称：电子商务交易的客户验证的制作方法
技术领域：
本发明涉及用于验证在诸如因特网的开放式电子网络上各方之间进行的交易，尤其涉及客户以信用卡或借记卡支付的因特网交易的验证。
背景技术：
现在电子商务是流行的。在诸如因特网的电子网络上进行交易对商家和客户而言都具有常常提及的方便、低成本、市场覆盖面大和选择多的优点。然而，因特网的匿名性给商家或零售商带来欺骗和错用的问题。交易商家需要验证销售、认证销售、确认销售、确保销售的不抵赖、确保支付、并控制匿名。类似地，买家需要控制销售的验证、销售的完整性、不良销售的追索、销售的确认、私密性和匿名。
在此全部引入作为参考的共同发明和共有的国际专利申请WO03073389描述了一种网络支付系统，用于在因特网上进行的客户-商家交易中验证客户。因特网将商家服务器和客户终端链接到支付服务器。客户将集成电路卡(ICC)用作标识设备。ICC通过读卡器与客户终端通信。ICC响应于有关未决交易的信息产生密码。该信息可以是客户终端产生的质询消息。读卡器将ICC产生的一部分密码转换成唯一的验证令牌，然后在例如因特网上将该验证令牌传送给支付服务器以验证客户。
另一种依赖于“智能”卡来为因特网上购买的商品和/或服务支付的因特网支付系统，在Davis等人的美国专利6,282,522号中描述。ICC和其它智能卡可基于共同的行业规范(例如，由Europay International、Mastercard International和VisaInternational联合开发的EMV标准)来支持跨各种支付系统的互操作性。
发卡机构和其它金融机构现在提供或使用标准化的因特网交易协议来改进在线交易性能并加速电子商务的增长。在某些标准化协议中(例如，Visa International开发的3D SecureTM协议)，发卡机构或发行银行可验证交易，从而降低由于持卡人未授权交易造成的欺骗以及关联的退款的可能性。验证的交易的出现可使发卡机构对尽管于在线购买期间验证了持卡人但仍然出现欺骗的情形承担责任。发卡机构或发行银行确保商家能得到经发卡机构验证的交易的支付。3-D SecureTM协议与发卡机构(例如通过Visa或MasterCard SecureCodeTM校验)提供的验证程序一致，并成为它们的基础，以在诸如关联于因特网的远程交易期间为商家验证客户。3-DSecureTM协议发挥现有安全套接字协议层(SSL)的加密功能，并通过在线购物会话期间发卡机构对持卡人的验证来提供增强的安全性。称为商家插件(MPI)的一种软件由参与的商家用来交换消息、传递信息和查询参与者，以便于在线购买期间建立持卡人及其发卡机构之间的验证会话。
3-D Secure协议服务是基于三域模型的一发卡机构域、收单银行(acquirer)和互操作性域。发卡机构负责管理持卡人在服务中的登记，并负责于在线交易期间验证持卡人。收单银行负责定义过程，使参与因特网交易的商家在与收单银行的协议下运行，并负责对验证的交易提供后端处理。互操作性域便于交易在另两个域之间交换共用协议和共享服务。持卡人及其银行可归入“发卡机构域”，而商家及其银行可归入“收单银行域”。发卡或收单银行或金融机构、以及发卡机构基础结构之间的通信可归入“互操作性域”。在与符合3-D安全的银行和商家交易时，除了会有一个来自发卡银行的独立验证窗口或弹出屏幕来确定交易方是否的确是所记录的持卡人之外，消费者可有与以前一样的因特网购物体验。在该协议下在线因特网购买交易的交易流程可如下(1)客户通过加密安全套接字协议层(SSL)连接，以常用方式在商家网站上填入支付数据。
(2)然后商家通过MPI向目录发送消息，而目录向发卡机构查询，来发现客户是否在3-D安全程序中登记。
(3)发卡机构用表示持卡人是否登记的消息对目录作出响应，且如果登记则提供发卡银行的web地址。然后处理该消息，并将响应转发给商家。
(4)然后商家通过持卡人设备发送消息到发卡银行，以启动并验证持卡人和发卡机构之间的会话，其中还可向持卡人提供诸如商家名称和交易量的交易细节用于确认。
(5)发卡银行然后向验证窗口填入与交易相关的持卡人详细信息，诸如商家名称和金额、个人安全消息、以及可由持卡人输入验证细节的响应区域。
(6)取决于发卡银行选择如何实现系统，客户以各种方法之一来认可交易。选项可在输入静态密码或PIN、使用智能卡和个人读卡器(PCR)来产生验证令牌之中选择。
(7)如果验证有效，则发卡机构向商家签发送表示验证成功的消息。如果验证失败或不能完成，则发卡机构也会通知商家。
现在考虑增强用于验证在电子交易中使用信用卡或借记卡支付的客户的方案的方法。注意力导向用于通过在交互点(POI)验证持卡人来保护商家的因特网销售通道，以及产生卡和持卡人同时在POI出现的明确证据的方案。所需方案应当与像3-D安全的公用协议的行业实现和其它诸如智能卡的EMV标准的行业标准兼容，以在简单和静态的密码或PIN之外增强验证。
发明内容
根据本发明，提供了基于3-D安全协议的芯片验证程序(CAP)，用于验证电子商务中的客户交易。可层叠在现有电子商务基础结构和技术之上的CAP的实现，提供了EMV和3-D安全技术的无缝集成，以获得比常规静态密码方案更强的验证。CAP实现向在线商家提供一种从支付发卡机构接收全球支付保证的机制，该保证类似于实体零售商所欢迎的物理销售点交易的保证，其中客户的身份马上就能验证。
在CAP中，发卡机构(例如支付发卡机构)在逐次交易基础上向各方提供验证服务。发卡机构可运行访问控制服务器和相关联的验证请求服务器，用于由已在程序中登记的客户来验证交易。验证令牌在每次交易的交互点(POI)上创建，对该交易基于唯一标识客户和交易的加密信息来请求验证。交易客户使用嵌在集成电路芯片卡(ICC)之内的基于EMV的验证应用，作为POI上用于创建令牌的个人标识符。包括在令牌中的商家或交易特定信息可由发卡机构例如通过填充POI上常用因特网浏览器的网页来直接提供给POI。有利地，CAP实现不需要POI(例如客户的访问设备)上各自的商家特定软件下载或显示(例如applet(小程序))。
POI上产生的验证令牌由ARS评估，来验证客户和/或卡在交易POI上的出现。在完成评估时，AAV由ACS产生。该AAV以UCAF用与3-D安全协议一致的格式在电子网络上传输。
本发明的用于验证电子网络上客户交易的系统，最好包括网络访问设备、签发给客户并包含客户标识数据的集成电路芯片、可与访问设备连接(物理地、电子地、或通过持卡人的手动介入)并与芯片通信的读卡器、与电子网络链接并能与请求交易验证的一方通信的验证请求服务器(ARS)和访问控制服务器(ACS)。ACS被配置成直接与客户的访问设备通信(例如通过持卡人验证页面)，用于验证交易。该直接通信使得不需要验证软件(例如商家特定applet)从请求方(例如商家)下载到客户访问设备。ARS通过客户的访问设备从请求方接收交易信息，并将交易数据传送给读卡器。读卡器可处理交易数据并将基于交易数据的值传送给芯片。芯片具有验证应用，该应用能够基于芯片上交易数据的至少一部分和客户标识数据的至少一部分来产生密码。读卡器可基于密码产生验证令牌并将其传送给ARS，ARS被配置成评估验证令牌中的客户标识数据，并相应地使验证令牌生效。验证令牌可以是与3-D安全协议消息格式兼容的格式。在成功完成验证令牌的评估之后，ACS产生以UCAF在电子网络上传输的20字节长度的AAV。
ARS首先通过重建由芯片用来产生密码的数据，然后根据重建的数据产生副本或再生密码，再使验证令牌与副本密码匹配，来评估验证令牌中的客户标识数据。
本发明的用于远程验证使用网络访问设备参与电子交易的客户的方法，最好包括向客户提供具有客户标识数据的集成电路芯片，并提供可与客户的网络访问设备链接并与芯片通信的读卡器。该方法还包括使用与电子网络相连并可向读卡器传送数据的验证请求服务器(ARS)，来接收交易特定信息并向读卡器传送交易特定信息；使用读卡器来向芯片传送交易特定数据，并指示芯片基于交易特定数据的至少一部分和客户标识数据的至少一部分产生密码；以及使用读卡器来基于芯片产生的密码的至少一部分产生验证令牌。该方法还包括使用ARS来使验证令牌生效，并相应地产生用于在电子网络上以UCAF消息向发卡机构传输的AAV。
从附图和以下详细描述中，本发明的其它特征、其本质和各种优点将更加显而易见。
从附图和以下详细描述中，本发明的其它特征、其本质和各种优点将更加显而易见，在附图中相同标号表示相同元件，且其中图1和2是根据本发明各原理的芯片验证程序和处理流程的示例性实现的示意图。
图3和4是根据本发明各原理的产生质询号以及分别用于不相连和相连的个人卡读卡器的PIN校验中所包括的PCR处理和数据流的示意图。
图5是根据本发明各原理的示例性8位质询的示图。
图6是根据本发明各原理的示例性IIPB数据令牌的示图。
图7示出根据本发明各原理的示例性压缩技术，用于将密码比特模式视为二进制数，并执行从基数2到基数10的数学转换。
图8(结合图1和2)示出根据本发明各原理在3-D SecureTM环境中的示例性CAP(经芯片验证的)交易所包括的步骤或各个实体之间的消息流。
图9是根据本发明各原理的示例性IIPB数据结构的示图。
图10是根据本发明各原理的3-D安全兼容UCAF结构的示图。
图11示出根据本发明各原理在电子商务环境中客户的在线购买中包括的过程步骤，在该电子商务环境中商家可选择性地请求为交易作持卡人验证。
图12是根据本发明各原理的示例性集成设备的示意图，该集成设备中ICC、PCR和/或PC设备的功能被集成到一个便利的物理包中。
通过附图，除非另外注明，相同标号和标注用来表示相同的特征、元件、组件或所示实施例的各个部分。
具体实施例方式
本发明提供用于在电子交易中验证远程各方的方案。特别地，这些方案涉及验证远程参与电子交易的持卡人。这些方案还涉及在诸如符合3-D安全的电子商务平台的行业标准电子商务平台上进行的电子商务上下文中的验证，并且还涉及在诸如邮购和会话订购的非电子商务上下文中的交易，其中验证令牌可由发卡机构用来验证持卡人。
“芯片验证程序”(CAP)方案给予发卡机构或发卡银行作为验证实体的重要性。该实体可运行访问控制服务器和相关联的验证请求服务器来验证已在程序中登记的客户。CAP使用内嵌于签发给已登记持卡人的集成电路芯片(例如ICC)的基于EMV的验证应用。持卡人可于在线交易期间使用ICC中的基于EMV的验证应用来获得对特定交易的远程验证。验证应用可独立于或附加于芯片中其它传统的EMV支付应用，那些应用是为面对面的商家客户交易设计的。
持卡人可使用ICC连同个人卡读卡器(PCR)来产生一次性使用的动态“安全代码”或验证令牌。出于该目的(例如为了接收安全代码)，持卡人验证页面可在持卡人因特网访问设备上产生并显示。持卡人验证页面可完全由发卡机构的访问控制服务器控制，而没有对持卡人设备上其它预先安装或附加软件的任何特别需要。CAP可实现为另一用于验证持卡人的安全方案，或除其它用于验证持卡人的安全方案之外的方案。这些其它安全方案可包括例如通过静态密码进行验证。可以理解，CAP可使用任何智能卡的标准芯片技术来实现。然而，该实现最好使用标准的EMV芯片技术来完成。
CAP可提供受信任的机制来验证电子商务支付和发卡服务。CAP可利用传统的通过公用支付系统网络的验证路线来进行支付交易验证。CAP的一个版本与3-D安全版本1.0.2基础结构兼容，用于商家、收单银行和发卡银行系统之间的端对端互操作，这三者现在根据共同协商的行业标准都必须支持3-D安全基础结构。
引入作为参考的国际专利申请WO03073389描述了使用个人卡读卡器(PCR)的ICC验证程序，该程序在全球持卡人验证字段(UCAF)中产生向发卡机构传输的验证令牌，UCAF发挥商家上一系列MasterCard定义的隐藏超文本标记语言(HTML)字段的作用而不采用3-D安全技术来在发卡机构、持卡人和商家之间交换验证数据。可以理解，通常在参考申请中定义的相同术语、首字母简略词和缩写也应用于本说明书中。为帮助理解本发明，在此重现参考申请中的术语列表和其它部分。
术语AAC应用验证密码AAV帐户持有人验证值AC 验证密码AFL应用文件定位符，标识ICC中何处有什么记录可用AID应用标识符，标识ICC中给定应用的十六进制字符串AIP应用互换概况文件，显示ICC支持特定功能的能力APDU 应用处理数据单元，消息在ICC和一些外部应用之间发送ARQC 应用请求密码ATC应用交易计数器BDC二进制编码十进制数Big-Endian编码样式，其中值首先存储其最有效字节，然后是每个后续字节，最后存储最不有效的字节。
CAP芯片验证程序CDOL 卡风险管理CID密码信息数据
CSN卡序列号CVC2 卡验证代码CVM持卡人校验方法，该方法用来校验卡的持有人。
DAC动态验证密码DOM文档对象模型，由浏览器提供给插件的当前HTML页面的编程视图HHD手持式设备，例如读卡器EMVEuropay(欧陆)、MasterCard(万事达)、Visa(维萨)IA 界面应用IAD发卡机构应用数据IAF因特网验证标记，IIPD的第一个字节ICC集成电路卡，也称为芯片卡或智能卡IIPB 发卡机构因特网专用位图，标识需要发送给发卡机构的比特，以便验证ACIIPD 发卡机构因特网专用数据，由发卡机构使用的有关为了因特网相关交易计算密码的专用数据。
ITV交互式电视LATC 应用交易计数器的较低(字节)Little-endian编码样式，值首先存储其最不有效字节，然后是每个后续字节，最后存储最有效的字节。
MAC消息验证代码。在消息中数据项上计算的密码签名，以证实消息的来源并允许检测这些数据项是否曾被更改。
MCD主要持卡人设备，在其上执行浏览和/或订购和/或支付的设备。
Nibble 半个字节，即4个比特。
PI APDU的参数I，它有效地定制发送给ICC的命令PAN主要帐号PC 个人计算机PCR个人卡读卡器Cardholder IA持卡人接口应用，在MCD上运行的应用，作为验证请求者、持卡人和PCR之间的接口。
PDA个人数字助理PDOL 处理选项数据对象列表，终端(即PCR)可用和/或支持的处理选项列表PIN个人标识号SPA安全支付应用TLV标签长度值UCAF 全球持卡人验证字段UN 不可预测数字WO03073389中所述的验证方案是全球持卡人验证字段(UCAF)的一种用途。它包括以下元素发卡机构提供的支持芯片-UCAF的接口应用、芯片-UCAF帐户持有人验证值(AAV)产生、持卡人验证、商家呈现、UCAF中AAV数据的收集和处理、验证数据字段、收单银行接受和处理包含在UCAF中的AAV数据、银行网络开发以包括支持在UCAF验证数据字段中运送AAV数据、以及UCAF验证数据字段中AAV数据的验证支持。
以下实体包括在芯片-UCAF验证交易的生命期中持卡人—持卡人发起交易，并负责将数据输入商家的支付网页、持卡人接口应用和个人卡读取器。
商家—商家例如从与因特网通信的商家服务器中提供发起验证交易所需的数据，并接收作为结果的UCAF数据以通过其收单银行转发给发卡机构来作出许可。
持卡人接口应用—持卡人IA检测由商家提供的相关数据，并直接和间接地与持卡人交互，并通过持卡人与个人卡读卡器交互。持卡人IA创建AAV和UCAF，并用适当数据填充商家页面。
例如，持卡人IA可作为因特网浏览器的一部分在用于访问因特网上商家的主要持卡人设备(MCD)上运行。
个人卡读卡器—PCR与持卡人和ICC交互，以产生间接传送给发卡机构的验证令牌。ICC—芯片卡通过使用所提交的PIN校验来验证持卡人，并基于PCR提供的数据产生适当的密码。
收单银行—收单银行在例如收单银行服务器上接受来自商家的格式化UCAF数据，并通过适当的远程通信网络向发卡银行转发该数据，以及指示UCAF数据的使用和出现的指示符。
Mastercard是一个收单银行。
发卡机构—发卡机构向注册到芯片-UCAF方案的那些持卡人分发PCR。发卡机构维护与因特网通信的发卡机构服务器平台。根据本发明，发卡机构服务器根据该发卡机构的规则使编码到UCAF中的、通过收单银行的验证请求传输的验证令牌生效。
根据WO03073389，UCAF(全球持卡人验证字段)数据字段是数字消息中多用途的数据传输区域，使验证数据能在任何形式的远程通信网络上从收单银行传送到发卡机构。例如，UCAF可以是32-字符字段(24个字节-1个控制字节和23个数据字节-经base-64编码变成32个字符)，它具有灵活的可定制以支持各种发卡机构安全和验证要求的需要的数据结构。例如，ISO 8583数据元48、子元43可被指定为包含UCAF。术语UCAF还扩展成为指一种接口，该接口定义为在商家和MCD之间往返传送数据，即规范中任何给定信道的字段名。UCAF可包含24-字节的用户验证令牌。这24个字节最好由持卡人IA进行例如Base64的编码，以给出返回给商家的32个ASCII字符的数据。商家在与收单银行的专用通信中传送UCAF数据，然后收单银行可在发送给发卡机构的验证请求消息中填充UCAF。
帐户持有人验证值(AAV)是赋予UCAF应用特定数据的一部分(例如23个字节)的术语。每个UCAF应用负责确定其AAV的适当结构。给定UCAF应用的实现的每个实例必须以一致方式使用该应用的AAV结构，即AAV格式对给定UCAF应用标准化。
为了使用芯片-UCAF持卡人验证方案，持卡人需要具有适当的ICC支付卡和个人卡读卡器。PCR将由其发卡机构提供给持卡人，发卡机构将登记该持卡人具有PCR并在芯片-UCAF持卡人验证方案中“登记”。由商家提供的UCAF交易数据用于显示目的，且其一部分用于传输交易相关的PCR质询。商家不需要对UCAF响应内的AAV数据执行其它处理。这通过被设置成芯片-UCAF值的UCAF控制字节值来向商家指示。持卡人接口应用(持卡人IA)提供验证收单银行(商家)、持卡人和PCR之间的交互。接口应用向持卡人呈现现有UCAF方案的安全外观。它负责向持卡人呈现交易数据、产生传送给PCR的质询、接收PCR令牌响应、格式化UCAF、并向给定信道填充返回数据。为了实现芯片-UCAF交易，持卡人IA具有它必须符合的最小要求集。
在本发明的上下文中，支持UCAF的收单银行与支持UCAF的商家有关系。收单银行使它们的商家能将额外的UCAF数据传送给收单系统，使它们的系统能识别所提供UCAF数据的出现，并将所提供UCAF数据传送给发卡银行。方案中的发卡银行主机，或作为发卡银行主机的一些其它元素负责取得验证网络消息中传送的数据，包括UCAF中的数据，并使验证令牌生效。
根据本发明符合3-D安全协议的UCAF，最多可包含20-字节的用户验证令牌。这种符合3-D安全的UCAF如图10所示。
图1和2示出本发明CAP的示意实现。除持卡人他或她自己，各个系统组件或参与者都涉及CAP实现。物理或逻辑的各个系统组件，包括验证请求服务器、持卡人的PC设备、安全代码验证应用(SCAA)、以及相连和不相连的PCR。这些系统组件可使用例如有线或无线网络来方便地链接或配置。
验证请求服务器是一逻辑实体，它可被配置成在独立于另一实体/组件的Web服务器环境中向该实体/组件提供验证请求服务。这种验证请求服务器可随不同的电子商务环境和需要而简便地调整和进化。一旦验证请求服务器验证持卡人，服务器可向请求实体/组件返回肯定或否定的验证结果。
持卡人的个人计算设备可以是另一计算机平台或访问设备，持卡人在其上执行要求验证的动作。该计算机平台可以是与PCR相连的PC平台。或者，该计算机平台可以是能够访问因特网的任何设备，包括例如PDA或其它移动Wi-Fi设备。持卡人可分配到智能支付卡(例如ICC)和PCR。在CAP的较佳实现中，在产生安全代码并将其提供给验证请求服务器进行验证之前，持卡人必须将个人标识号(PIN)输入他或她的PCR。
PCR可以是任何适当的符合EMV的读卡设备，它被设计成与持卡人和ICC交互以产生安全代码。常规密码技术(例如密钥技术)可用来产生安全代码。PCR可具有显示屏和键盘，以支持有限的持卡人交互。适当的PCR可以是例如低成本的具有数字键盘和显示屏的手持式智能卡读卡器。PCR可以是单机的，不需要与持卡人的个人计算设备有物理连接。在这种实例中，持卡人必须手动地在PCR和PC设备之间传送全部数据。
PCR还可以是与持卡人的PC设备物理地相连的设备。在这种实例中，持卡人仅需在PCR上输入他们的PIN来发起验证过程，因为安全代码由PCR自动地传送给相连计算设备上的用户界面。相连PCR可在PIN输入过程期间提供对PIN的常规安全或保护。PCR上的显示屏能显示PIN验证结果，并且对于不相连设备，显示由持卡人在PC或PDA上输入的“安全代码”。如果连接不可用，则相连读卡器可用作不相连读卡器。用于CAP实现的PCR可以是一般设计的，它可支持各种卡的实现。持卡人可由验证请求服务器(通过PC设备显示界面)提示是否要在PCR中输入质询。当作出这种指示时，PCR能使持卡人输入质询，然后将该质询包括在安全代码的计算中。
安全代码验证应用(SCAA)连同标准支付应用一起可驻留在多应用信用卡、借记卡或其它卡(例如ICC)中。SCAA可以是支付应用的单独实例，在该情形中发卡机构具有使用单独的安全环境支付和远程验证的选项。该应用可支持“一次性密码”的产生和“交易接受证明”代码的创建。发卡机构还可任选地选择将SCAA应用于其它服务。SCAA可包括格式化信息或模板，它向PCR指示各个发卡机构所期望的安全代码格式类型。因而，单个PCR设计可用来支持广泛范围的卡类型。
在较佳实现中，一个或多个持卡人的个人计算设备、ICC和PCR的功能可集成到单个设备中，该设备可由客户用来访问因特网并执行验证的交易。适当的集成设备可以是例如带有显示的卡，它将ICC和不相连PCR的功能集成到一个用户便利包中。另一种将ICC和不相连PCR的功能集成到一个用户便利包中的适当集成设备可以是钥匙链(fob)。PDA或其它个人因特网访问设备还可被配置成执行分配给持卡人的ICC和PCR的功能。图12是卡230、钥匙链240和PDA250的示意图，它们都包括执行PCR和ICC功能的电路。PDA 250还可用作因特网访问设备。
图1示意性地示出可用于为在线因特网交易验证持卡人180的示例性CAP验证过程100。可发给持卡人180用于进行在线交易的个人ICC 170和不相连的PCR160。可以理解，ICC 170和PCR 160都可以是具有显示屏的集成卡(图12卡230)。过程100可响应于由外部实体110发送给验证请求服务器120的验证请求150而发起。在过程100中，验证请求服务器120通过显示在持卡人的PC设备140上的卡验证页面130(例如HTML页面)作为媒介而与持卡人180交互。验证请求服务器120产生HTML页面130并可直接提供它。或者，HTML页面130可取决于在电子网络中使用的特定web服务器基础结构或技术，通过验证请求器(实体110)提供。对验证的请求(例如请求150)可以是HTTP查询的结果，该查询能处理由验证请求服务器120产生的响应(例如结果150’)中的HTML。在过程100中，对验证的请求(150)可能需要包括或以其它方式提供以下信息或数据●个人帐号(PAN)—在验证过程中要使用的卡的PAN●持卡人的个人担保消息(PAM)—登记到CAP程序中的持卡人可能需要提供在请求验证时将显示的任选个人担保消息。
●交易细节—请求验证的交易细节必须向持卡人显示，不管是对网站商品的支付还是对帐户的访问。
参照图1的整数编号步骤，在过程100的步骤1，验证请求或控制服务器120产生用于显示给持卡人的持卡人验证页面130。持卡人验证页面130可以是在持卡人PC设备140上显示的HTML页面。持卡人验证页面130可显示由请求实体110提供的交易细节。16位的PAN可分三组X标记(即“XXXX”)显示，随后是PAN中的最后四位，以帮助持卡人180识别或使用要验证的正确卡。当持卡人在CAP登记时提供的持卡人的PAM也可以显示。接着在步骤2，持卡人180可发起对用于远程支付或标识的安全令牌(即安全代码)的请求。持卡人可被提示使他或她的ICC 170通过PCR 160来读取。持卡人可得到请求不同类型安全代码的选择(步骤2a)。不同类型的安全代码可对应于例如远程支付的签名验证，或对应于银行帐户访问的标识验证。对于第一类安全代码(Bruce、Alfred，请确认)，持卡人可任选地得到提示，将显示在网页130上的质询输入PCR 160。如果未提供质询，则持卡人可通过激活PCR 160上任何适当指定的按键(如继续按钮)继续。此外，对于ICC 170具有指示必须签名或验证的交易金额的因特网验证标记(IAF)的交易，交易金额可在网页130上向持卡人180显示。持卡人180可得到提示，以从内嵌列表中选择交易货币，然后输入显示在网页上的金额。在该输入后，持卡人可通过激活PCR 160上的适当指定按键来继续到下一步骤3。
在步骤3，持卡人180可得到输入持卡人PIN的提示。如果PIN未正确输入，则持卡人可得到再次输入PIN的提示。持卡人180被允许进行有限次的尝试，以正确地输入PIN。该有限次数可以是在ICC 70中内部重试计数器中设置的预选数字。如果持卡人180不能在所允许尝试次数中输入正确PIN，则拒绝交易。然后持卡人180可任选地被请求提交不同的或其它的支付方式。
在输入正确的PIN之后，在步骤4，PCR 160与卡进行最优化的EMV交易对话，以产生应用密码。该密码可以是EMV标准术语中的验证请求密码(ARQC)。在某些实例中，ICC 170可具有使它产生应用验证密码(AAC)而不产生ARQC的内部风险管理例程。每种类型的密码对PCR 160都是可接受的。在步骤5a，PCR160将ARQC或AAC转换成数字安全代码以显示给持卡人180。该数字安全代码可以是例如8位长的。在步骤5b，读取PCR 160产生的安全代码，并由持卡人180手动输入到持卡人PC识别140上HTML页面130中的适当输入字段中。在步骤6，具有安全代码输入的HTML页面130可由持卡人180提交给验证请求服务器120以便许可或生效。接着在步骤7，验证请求服务器120可访问持卡人数据库190，以检索或更新卡特定的静态和动态数据。可由验证请求服务器120跟踪的卡特定动态数据可包括应用交易计数器(ATC)。最新知晓的ATC副本可保存在持卡人数据库190中，从而完整的ATC可结合安全代码中返回的部分ATC(低位)来正确地重建。
在步骤8，验证请求服务器120可通过重建由ICC产生密码时使用的输入数据来使安全代码生效。所重建的输入数据可包括已知静态数据、由PCR 160提交给ICC 170的任何交易特定数据(质询、金额/货币)、以及从卡数据库190中检索的数据。在各个实例中，当在步骤3上不使用质询时，PCR 160可被配置成对不可预测数字使用空值。相似地，如果在步骤3不使用金额和货币值，则PCR 160可被配置成对两个变量都使用0的缺省值。从重建的输入数据中，应用密码(AQRC或AAC)可重新计算，并与由应用请求服务器120在步骤6接收的安全代码中的部分应用密码(AC)作比较。如果所重新计算和接收的AC匹配，则可在卡数据库190中更新ATC值。
在过程100中的最后步骤195，应用请求服务器120向请求实体110提供验证测试的结果。
图2示意地示出另一个示例性验证过程200，该过程可应用于持卡人180分配了相连PCR 160’的实例。除了任何质询和金额/货币数据通过HTML页面130中的内嵌软件组件直接或自动地传送到PCR 160’之外，过程200与过程100大致相似。类似地，在持卡人180正确地输入他或她的PIN(在步骤3)以便校验之后，安全代码可自动地输入到适当数据字段中。像过程100一样，过程200可通过PCR 160’向持卡人180提供签名或标识操作的选择。在交易金额需要由持卡人170签名的实例中，过程200可在启用PIN输入之前在PCR 160’上显示金额。验证请求服务器120以与由PCR 160产生的安全代码处理一致的方式(图1)来处理由过程200产生的安全代码。
在过程100和200中，EMV安全特征是CAP安全的基础。更具体地，CAP依赖于通过ICC产生的密码(即应用密码(AC))，来建立出现卡和持卡人的证明以用于产生一次性安全代码。对持卡人认可的交易的证明基于质询的使用。交易特定密码的使用提供了保护，防止真实交易的重复提交和欺骗交易的产生。
ICC(例如ICC 170)被编程为响应于标准EMV命令产生用于特定交易的密码(例如GENERATE AC命令)。由ICC 170对GENERATE AC(产生AC)命令产生的响应可包括以下数据元密码信息数据(CID)、应用交易计数器(ATC)、由ICC计算的密码(AC)和发卡机构应用数据(IAD)。这些数据元获得对特定交易唯一的数据以及可从其它源获得的非唯一数据。对特定交易唯一的数据(以密码形式)从PCR被传送到接口应用(例如作为安全代码通过HTML页面130)作进一步处理。可从其它源获得的数据，不需要包括在安全代码中。这种非唯一数据可假设具有对发卡机构给定卡方案的特定值，该值对特定ICC唯一、且通过其持卡人数据库为发卡机构主机所知(或至少可导出)。
ICC 170可包括一数据对象或掩码(例如带有标记‘0x9F56’的发卡机构因特网专用位图(IIPB))，它被PCR用来确定必须使用ICC响应的哪些部分(即比特)来产生验证数据或密码。所使用比特的数量可由发卡机构定义或选择。比特数量可例如基于对可由持卡人方便地从未相连PCR 160手动传送到PC设备140的有限数量数据比特的人体工程学的考虑来选择。IIPB可由PCR 160或160’用作比特-掩码以导出“IIPB数据令牌”，它在压缩时形成传送给验证请求者的安全代码令牌。
图9示出示例性IPPB结构900。组成IIPB 900的比特可视为传送标记，表示来自Generate AC响应的哪些比特为发卡机构所需，用于包括在安全代码中。这些标记可在逐个比特基础上对应于必须从PCR发送的比特(例如CID一个字节、ATC两个字节、AC八个字节、以及IAD 0～32个字节)。在不太可能的未定义IAD的情形中，IIPB 900最多可约为11字节。在发卡机构应用技术使用发卡机构应用数据(IAD)可用的全部32个字节的情形中，IIPB 900最多可达43个字节。因而，针对数据元CID、ATC、AC和IAD的串联用作掩码的IIPB 900，可导致长度在11和43个字节之间的结构。PCR 160和160’可被适当配置成确定IIPB 900的长度与在ICC 170’的Generate AC响应中返回的数据项长度匹配。
有效的IIPB长度指(由IIPB定义的)在IIPB数据令牌内传送的比特数量(由IIPB中的比特数量决定，当它们设定为1时表示需要比特传送)。在示例性CAP实现中，安全代码不超过26个比特，是可用8位十进制数传送的比特的最大数量(即，67,108,863)。因此，有效的IIPB不能超过26个比特，因为对令牌而言这将需要超过8位数。
ICC 170通过使用离线PIN确认来建立持卡人出现的证明。EMV标准规范要求在产生AC之前执行离线PIN确认。因此，持卡人出现需要产生一有效AC，且有效密码的存在足以表示持卡人出现。AC通常是基于ARQC的，但如果卡的内部风险管理例程确定要拒绝支付交易，则可基于AAC。
交易被持卡人接受或认可的证明基于使用由验证请求服务器提供的数据来产生密码和安全代码。由验证请求服务器提供的数据被用作显示给持卡人的交易特定质询。该质询是从仅对验证请求服务器已知的信息形成的数据值。该数据值可基于发卡机构认为相关或有关的任何适当数据(例如交易金额和货币代码)。不同的质询将产生不同的安全代码，且没有可预知的方法来得知可使用什么质询来创建特定的安全代码。因此，交易特定质询的使用向发卡机构和验证请求服务器提供持卡人的确认可特定交易，因为所示质询包括在PCR产生的密码中，而密码包括在安全代码中。为了确保防止真正交易的欺骗性再次进行或再次提交，CAP的实现可被配置成检查从ICC接收的应用交易计数器(ATC)值，与该特定ICC上次接收的ATC值成对照。可将使用先前接收ATC值的交易作为再次进行而拒绝。此外，由ICC产生的AC可计算成它作为ATC的函数在变化。这可通过将ATC包括为用于AC计算的输入数据的一部分来实现。
只有由ICC产生的AC的截取部分被传送给发卡机构。每个由发卡机构因特网专用位图(IIPB)指定的密码被截取。发卡机构可例如以来自AC的16个比特被包括在PCR返回的安全代码中的方法来定义IIPB。因为所截取密码的缩减尺寸，发卡机构可实现欺骗检测系统来检测失败密码确认的异常数量。
图3和4示出产生质询号以及分别用于不相连和相连的个人卡读卡器的PIN校验中所包括的示例性PCR处理和数据流。使用相连PCR和不相连PCR的主要差异是用户的方便性。在相连PCR的情形中，PC设备和PCR之间的链接在两者之间传送数据。在不相连PCR的情形中，数据必须由持卡人手动复制应用于在两者之间传送。可以理解，图5.3和3.4不是发送给ICC的准确命令或PCR上准确执行步骤的详细说明。为了清晰起见，只示意地示出有助于说明系统的那些元素、其数据结构和一般处理原理。
参照图3所示的整数编号步骤，PIN校验和显示给持卡人的相应提示的处理步骤序列可如下1.持卡人被请求插入他们的卡。持卡人将支持其发卡机构验证的卡(ICC)插入个人卡读卡器。
插入具有不相连读卡器的卡，插入卡的动作可使PCR上电，或者持卡人需要按压按钮来打开电源。
2.持卡人被请求选择所需PCR功能的类型。
ign(签名)或[I]d3.持卡人通过功能键或菜单系统对PCR功能作出他或她的选择。
4.PCR使用适合所请求功能的选择列表，以搜索并选择在产生适当安全代码时要使用的应用。
5.PCR从ICC读取选定的数据元，包括IIPB和IAF。
如果持卡人已选择了签名操作，则6.PCR提示持卡人输入质询。
质询的产生是发卡机构所有的；质询将用于EMV交易处理中的不可预测数字(UN)。
Challenge＞(质询＞)7.持卡人必须在PCR的键盘上输入该质询，并按[继续]键以表示质询输入的完成。
558581581158113581139581139658113967[继续]当验证请求服务器不需要质询时，持卡人可简单地按下[继续]键，而不输入任何质询数字。PCR将响应于后面的GENERATE AC命令对UN使用零值(0)。
8.如果ICC指示金额和货币要包括在密码中，则PCR显示货币的标准列表以便于持卡人选择1.EUR2.USD3.GBP4.其它＞1[继续]9.然后持卡人得到输入金额的提示＞？？？？？？？？.？？EUR持卡人输入金额并按下[继续]。
要求金额和货币包括在密码中的发卡机构可在IAF的设置中表示该要求。金额和货币在持卡人验证页面上向持卡人显示。
10.PCR向持卡人显示输入他们的PIN的提示enter PIN(输入PIN)
11.持卡人输入其PIN数字，并按下[继续]键以表示PIN输入的完成，如以下4-位PIN示例所示**********[继续]12.PCR向ICC提交用于校验的PIN。
出错检查如果ICC报告无效PIN输入，则PCR通知持卡人剩余的PIN尝试次数Bad PIN，2 left(PIN不对，剩两次)然后持卡人输入正确的PIN，按下[继续]键，然后PCR报告有效的PIN输入。
****[继续]PIN OK！使用相连读取器(图3、4)的PIN校验过程310一般类似于使用不相连读取器(图5、3)的PIN校验过程300。然而，在过程310中，接收适当的APDU命令可发起交易处理流程，而不必像过程300一样插入卡或打开读卡器的电源。过程310还可在接收任何质询数据的方式上与过程300不同。持卡人不需要输入质询，因为任何必要的质询数据都用发起该交易的APDU提供。
在过程300和310中，PCR可以相同方式来计算安全代码。在过程310中，所计算的安全代码会需要在APDU响应中返回。该要求确保验证请求服务器在处理响应时用相同方式来处理相连和不相连PCR。
CAP将应用密码(AC)用作用于验证ICC和持卡人的机制。EMV命令GENERATE AC用来请求ICC产生应用请求密码(ARQC)。必须在该命令中提供的数据由通常标识为CDOL1的EMV数据元指定。不可预测数字(UN)是在GENERATE AC命令中传送给ICC的数据的4-字节(32-比特)部分。它是与应用相对的ICC不可预测的数(或数据)传送给PCR的质询被用作用于产生密码的不可预测数字(UN)。8位的最大数可用作发送给ICC时的BCD(二进制编码十位数)形式的质询。少于8位的任何质询可涉及在创建UN时对最多达8位的常规填充的使用(例如在前面插入零)。图5示出一示例性8位质询。
在CAP实现中，PCR被配置成处理来自ICC的对GENERATE AC命令的响应，以便于得到必须返回给接口应用的安全代码或令牌。PCR对GENERATE AC命令的完整响应会太大而不能发送给发卡机构。因此，PCR使用IIPB来执行数据提取和压缩处理以产生IIPB数据令牌，该令牌是从PCR(经加密后)传送给接口应用的数据。相连PCR可将该数据直接传送到接口应用，而对于不相连PCR而言，持卡人必须手动传送该数据。
IIPB中‘1’的比特设置(参见图9)表示响应数据中的相应比特位置是‘必需’的，并需要发送。
‘0’的比特设置表示发卡机构知道或能够以其它方式导出比特设置应该是什么，因而该比特不需要作为安全代码的一部分来发送。
IIPB数据令牌从右到左地建立，其中要提取的第一个比特置入输出数据的最后一个字节的比特1中，而第二个在比特2中等等。用这种方法填充直到没有其它比特要传送的示例性IIPB数据令牌3700在图7中示出。
从PCR传送到接口应用的数据(即示例性IIPB数据令牌)被首先加密成安全代码。在CAP实现中，PCR被配置成用适当算法来计算表示要传送数据的比特模式的数。然后不相连读卡器将显示该数—安全代码—，从而持卡人能将其输入由持卡人验证页面显示的适当字段。
用于将所需比特转换成显示数位的PCR加密算法最好在验证请求服务器上是可互操作并可逆的。用来从比特转换成令牌的同一算法可反向为从令牌转换成比特。适当的‘压缩’技术涉及将比特模式视为二进制数，并执行图6所示的从基数2到基数10的数学转换。
CAP的实现被设计成与交易链中包括商家、收单银行、发卡机构和持卡人的全部各方的3-D安全平台、系统和方法一致或兼容。CAP有利地标准化了发卡机构定义的芯片验证数据的使用。CAP实现可有利地利用新的和现有的3-D安全平台、系统和方法的标准消息基础结构，以支持广泛范围的持卡人验证方案和交易通道。
在CAP芯片验证交易(图8)的生命期中，涉及以下逻辑或物理3-D安全实体●持卡人—持卡人发起交易，并负责将数据输入到商家的支付网页、个人卡读卡器和持卡人验证页面。持卡人必须将其PIN输入PCR，以便于PCR使用安全代码验证应用(SCAA)来创建安全代码。
●商家—商家提供必要数据来发起验证交易，并接收结果验证数据以通过其收单银行向发卡机构转发以作校验。商家运行正常的3-D安全过程。
●持卡人验证页面-持卡人验证页面是ACS的页面呈现。该页面显示由ACS提供的相关数据和指令，并与持卡人交互。持卡人验证页面由ACS返回给持卡人并作为因特网浏览器的一部分运行(即作为‘弹出’窗口)。除了3-D安全的Mastercard实现的标准显示信息之外，如果发卡机构需要，该页面还可包括质询。
●个人卡读卡器-个人卡读卡器与持卡人和ICC交互，以产生通过ACS间接传送给发卡机构的安全代码。取决于读卡器类型和交易类型，持卡人在输入所需PIN之前需要输入质询和可能在发卡机构产生的验证弹出窗口显示的金额/货币。持卡人必须将(在不相连PCR上显示的)安全代码输入持卡人验证页面网页。(除了PIN输入和可能的金额/货币确认之外，对相连读取器而言数据输入是不必要的。)●ICC-符合EMV智能卡通过PIN验证来验证持卡人，并基于个人卡读卡器提供的数据产生适当密码。
●收单银行-收单银行接受来自商家的交易数据，并通过适当网络将其转发给发卡机构。收单银行可遵从标准的或互相协议的过程来从发卡机构获得验证。
●发卡机构-发卡机构向持卡人分发个人卡读卡器，持卡人为3D安全向MasterCard芯片验证程序登记。重要的是，发卡机构可任选地根据该发卡机构规则确认DCAF字段中传送的验证数据—在来自收单银行的验证请求内。
●访问控制服务器-发卡机构用附加能力运行为3-D安全指定的访问控制服务器，以呈现持卡人验证页面并接收来自PCR的安全代码(直接或间接地来自持卡人)。ACS通过使用验证请求服务确认安全代码的有效性，其中○仅从安全代码提取仅为芯片所知的数据(ATC和密码类型的指示符)。
○再生密码。
○将结果和安全代码中的部分密码作比较。
●登记服务器-登记服务器和登记过程与正常的3-D安全过程相同。可要求持卡人指示PAN引用智能卡，而芯片将用来创建安全代码来代替非静态密码。这可以是持卡人的决定或发卡机构的决定，或者是配置选项。发卡机构必须指示安全代码的格式，以及是否对PCR中的持卡人条目显示质询。理想地，大多数这些决定是发卡机构可选择的配置选项。
●目录服务器-目录服务器以正常3-D安全模式运行。
图8示出在例如3-D安全版本1.0.2环境的3-D SecureTM环境中示例性CAP(经芯片验证的)交易中的部分步骤和其中涉及各方之间的消息流500。CAP提供卡/持卡人和发卡机构的访问控制服务器(ACS)510之间的验证机制。所示示例性消息流假设在进行交易之前，持卡人580已为服务向发卡机构作了登记，并具有智能卡和兼容PCR。此外，想要购买的持卡人580已选择了所需商品或服务，并已在商家网站上发起了“结账”过程。商家已请求持卡人580提供他或她的支付卡的细节，这些细节由持卡人580以受保护方法输入到商家网站上。基于CAP的验证仅影响步骤8-安全代码的创建和输入。
标准3-D安全版本1.0.2消息格式和数据格式可用于所有消息流500。具体地，ACS 510创建并返回给商家用于最终包括在UCAF中的CAVV为28个字符长，并包含以base 64编码的为3-D安全定义的20-字节字段(参见例如图10)。CAP验证应用(SCAA)的使用可在“验证模式”字段中表示(值‘2’)。AAV的相同格式可用于动态安全代码CAP操作中，并用于传统的3-D安全静态密码操作模式。
参照图8，整数编号的步骤或消息流500如下1.支付细节持卡人向商家提供(HTTPS/POST形式)已使浏览并选定的各物‘结账’的持卡人向商家提供个人细节，包括(该范围内特定兴趣的)支付卡细节，即凸起的卡号(PAN)。
2.VEReq(校验登记请求)商家向目录服务器(DS)提供(HTTPS/POST)商家的3-D安全处理软件向适当的品牌目录服务器发送VEReq，以确定PAN是否在安全的3-D安全程序中登记。
商家可得到鼓励来每天维护目录服务器的本地高速缓存，以避免为每次支付查询目录服务器。高速缓存可包含参与程序的所有入选品牌的卡范围。使用高速缓存选项将防止在持卡人PAN没有资格参与程序时调用那些实例的目录。
3.VEReq目录服务器向访问控制服务器(ACS)提供(HTTPS/POST)基于卡范围，目录服务器向适当ACS传送VEReq。ACS确定该卡(持卡人PAN)是否在3-D安全中登记。
4.VERes(校验登记响应)ACS向DS提供(对HTTPS/POST的响应)ACS返回特定PAN是否在系统中登记的指示，且如果作了登记，则URL将用来将持卡人的浏览器重定向ACS，以便于执行验证。
ACS返回唯一的帐户标识符(一定不是该PAN)，它由ACS在持卡人用PAReq与之联系时用来标识讨论中的支付卡。该帐户标识符必须在一对一基础上匹配所使用实际卡的PAN，从而密钥可正确产生使安全代码得以校验。
5.VEResDS向商家提供(对HTTPS/POST的响应)DS向商家返回该响应。
6.PAReq(支付者验证请求)商家向持卡人提供(HTML页面)商家的3-D安全处理软件构建一PAReq，对其采取Base64编码并将其置入一HTML表单字段(PaReq)。持卡人的浏览器在验证之后必须重定向的商家URL被置入一HTML表单字段(TermUrl)，并且在通过TermUrl联系时可能需要的任何商家状态数据也被置入一HTML表单字段(MD)。然后HTML页面被返回给持卡人，作为对其支付细节的发送的响应。按照VERes，该表单的POST地址是ACS的URL。
7.PAReq持卡人向ACS提供(HIT/POST)由商家返回的页面可打开一附加的小‘弹出’窗口，然后将商家填入的表单数据发送给ACS。
ACS查询持卡人细节并确定验证细节以用于该特定支付卡，并且在芯片验证的情形中，确定验证所需的质询类型。
8.持卡人验证ACS到持卡人到ACS(HTML页面，然后是HTTPS/POST)步骤8可以对特定发卡机构和/或持卡人适合的方式进行。在CAP实现中，验证过程可使用验证请求服务器执行，如图1、2和附录A所述。ACS 510可支持一种以上类型的持卡人验证，但每种卡仅允许一种方法。ACS 510可从为卡/持卡人存储的信息中确定卡的允许方法。ACS控制与持卡人的接口，并引导持卡人对PCR的使用。基于ACS内的配置参数，发卡机构可实现“一次性密码”安全代码，或者可实现“交易接受”安全代码。不同之处在于为了接受特定交易，持卡人在输入其PIN之前必须在不相连PCR上输入质询。
9.产生CAVYACS在通过所采用验证机制成功确认时，ACS构建符合所实现3D安全体系结构的安全支付应用(SPA)AAV。该值将置于PARes的CA VV子字段中用于返回给商家。
10.PARes(支付者验证响应)ACS向持卡人提供(HTML页面)ACS构建包括AAV和消息签名的PARes，且对其采用Base64编码并将其置入HTML表单字段(PaRes)。在PAReq中接收的商家数据也在HTML表单字段(MD)中被返回给商家。根据PAReq的TermUrl字段，用于该页面中表单的POST地址是商家的URL。
11.PARes持卡人向商家提供(HTTPS/POST)由ACS返回的页面然后将ACS填充的表单数据传送(POST)给商家，其中商家的3-D安全处理软件可校验由ACS产生的消息签名。
12.授权请求商家向收单银行提供(专用通信)商家包括在发送给其收单银行的授权请求的PARes中所接收的AAV，以及标准授权请求数据。
13.MT0100/0200收单银行提供给发卡机构(BankNet)收单银行提取验证数据，并将其插入验证消息内的UCAF字段，并发送给适当的MasterCard授权网络。
14.校验SPA AAV发卡机构发卡机构可校验授权消息的UCAF字段中所包含的AAV值，以确保对给定卡进行持卡人验证。
15.MT0110/0210发卡机构向收单银行提供(BankNet)执行标准授权处理，且响应被返回给收单银行。
16.授权响应收单银行向商家提供(专用)商家从其收单银行接收授权响应。
17.响应/接收商家向持卡人提供(HTML)商家向持卡人返回是否已接受其支付的指示。
图11示出具有CAP实现的3-D安全环境中的客户在线购买中所涉及的过程步骤的示例性序列。CAP实现可被设计成层叠在现有电子商务系统上，从而交易可用(或不用)商家和/或登记持卡人所请求的持卡人验证服务进行。
在步骤2200，客户例如在商家网页上购物并选择要购买的商品。为此目的，客户可例如使用集成式PDA250(图12)。在步骤2210，响应于客户输入一卡号，商家可向客户提示支付信息。在步骤2230，商家可显示一确认请求，并要求客户点击提交按键。在步骤223，MPI可检查卡号是否在缓存的卡范围中。如果在步骤223卡号不在缓存的卡范围内，MPI可(在步骤2270)提交一未获验证的授权请求。如果在步骤223卡号在缓存的卡范围内，则MPI可产生VEreq以查看持卡人是否在CAP程序中登记(步骤2240)，然后等待校验。在步骤224，如果在预定等待时间内未收到肯定的校验结果，则MPI可继续到步骤2270以提交未获验证的授权请求。此外在步骤224，如果在预定等待时间内收到肯定的校验结果，则MPI可继续到步骤2250，以产生向发卡机构请求持卡人验证的消息。
在步骤225，如果在超时时段内未接收到对请求的肯定响应，则MPI将继续到步骤2270以提交一未获验证的授权请求。此外在步骤225，如果在超时时段内接收到了对请求的肯定响应，则过程可分别连续进行到步骤226和227，用于确认是否获得签名确认，以及是否持卡人验证过程已成功完成(通过ACS)。如果两个步骤中的任何一个未成功，则MPI可回到步骤2210，其中商家可向持卡人再次提示支付信息。如果这些步骤都表示持卡人验证过程的成功完成，则在步骤228，MPI接收肯定或否定并具有各种原因代码的验证结果。
此外在步骤228，MPI可询问验证结果，并相应地继续提交已获验证授权请求，其中UCAF数据在UCAF传输字段中(步骤2260)，或者继续到步骤2270提交未获验证授权请求。在步骤228，MPI或者还可以继续到步骤229，以询问收到验证结果中的原因代码。根据原因询问的结果，MPI可有选择地再次向客户提示支付信息(步骤2210)，或继续到步骤2270以提交未获验证的授权请求。MPI在分别于步骤2270或步骤2260上提交未获验证和已获验证的授权请求之后，可继续向客户显示接收页面(步骤2280)。
尽管本发明已结合特定示例性实施例进行了描述，应理解可对各公开实施例作对本领域技术人员显而易见的各种改变、替换和更改，而不背离本发明的精神和范围。
权利要求
1.一种用于验证电子网络上客户交易的系统，所述系统包括访问设备，用于对所述电子网络的客户访问；集成电路芯片，被发给所述客户并包含客户标识数据；读卡器，可与访问设备链接并可与所述芯片通信；以及验证请求服务器(ARS)，连同访问控制服务器(ACS)链接到电子网络，并可与请求验证所述交易的一方通信，其中所述ACS被配置成直接与客户的访问设备通信用于所述交易验证，而不需要将验证软件从所述请求方下载到客户的访问设备，其中所述ARS被配置成通过所述客户的访问设备接收来自所述请求方的交易信息，并向读卡器传送交易数据，其中所述读卡器被配置成接收所述交易数据，并将基于所述交易数据的值传送给芯片，其中所述芯片被配置成基于所述交易数据的至少一部分和芯片上客户标识数据的至少一部分来产生密码，其中读卡器还被配置成将基于密码的验证令牌传送给所述ARS，以及其中所述ARS还被配置成评估来自所述验证令牌的客户标识数据，并确认用于验证所述客户交易的验证令牌。
2.如权利要求1所述的系统，其特征在于，传送给所述读卡器的交易数据包括基于所述交易信息的质询。
3.如权利要求1所述的系统，其特征在于，所述验证令牌具有与3-D安全协议消息格式兼容的验证令牌。
4.如权利要求1所述的系统，其特征在于，所述验证令牌由ARS成功评估导致帐户持有人验证值(AAV)通过ACS产生，所述AAV在20字节长的全球持卡人验证字段(UCAF)中经电子网络传输。
5.如权利要求1所述的系统，其特征在于，所述芯片和读卡器被共同置入单个物理包中。
6.如权利要求1所述的系统，其特征在于，所述访问设备、芯片和读卡器被共同置入单个物理包中。
7.如权利要求1所述的系统，其特征在于，所述ARS被配置成通过首先重建所述芯片用来产生密码的数据，然后从重建数据产生副本密码，再匹配所述验证令牌与所述副本密码，来评估所述验证令牌中的客户标识数据。
8.如权利要求1所述的系统，还包括可由ARS访问来检索所存储客户信息的持卡人数据库。
9.如权利要求1所述的系统，其特征在于，所述ARS还被配置成将验证结果传送给所述请求实体。
10.如权利要求1所述的系统，其特征在于，所述ARS还被配置成匹配从所述芯片接收的应用交易计数器值与从所述芯片接收的应用交易计数器的先前值，从而验证所述交易。
11.一种用于验证在符合3-D安全的电子网络环境中的客户交易的系统，所述系统包括商家；发卡机构；收单银行，用于接受来自所述商家的交易特定数据，并将数据传送给所述发卡机构；验证请求服务器(ARS)，连同访问控制服务器(ACS)由发卡机构操作；持卡人验证页面，提供ACS和所述客户之间的界面；符合EMV的芯片卡，由发卡机构发给客户，所述芯片卡具有客户标识数据；以及读卡器，用于与所述芯片通信，其中所述读卡器可与持卡人验证页面链接，其中所述芯片卡和读卡器被配置成基于由所述读卡器通过持卡人验证页面接收的客户标识数据的至少一部分和交易特定数据的至少一部分的密码，来产生验证令牌，其中所述ARS被配置成评估用于确认的验证令牌，以及其中验证令牌的确认导致产生在20字节长的UCAF中在电子网络上传输的AVV。
12.如权利要求11所述的系统，其特征在于，所述芯片和读卡器被共同置入单个物理包中。
13.如权利要求11所述的系统，其特征在于，所述持卡人验证页面、芯片和读卡器被共同置入单个物理包中。
14.如权利要求11所述的系统，其特征在于，所述芯片卡响应于所述读卡器发出的EMV标准命令来产生所述密码。
15.如权利要求11所述的系统，其特征在于，所述芯片卡包括由发卡机构选择的位图掩码，用以标识由所述读卡器包括在所述验证令牌中的密码的特定比特。
16.如权利要求11所述的系统，其特征在于，所述ICC被编程为在校验由所述客户输入的个人标识代码之后，连同所述读卡器产生所述验证令牌。
17.如权利要求11所述的系统，其特征在于，所述ICC被编程为在客户校验交易金额之后，连同所述读卡器产生所述验证令牌。
18.如权利要求11所述的系统，其特征在于，所述ACS被配置成将卡的验证页面显示为弹出或内联网页，用于将数据和指令传送给所述持卡人。
19.如权利要求11所述的系统，其特征在于，所述发卡机构通过使用所述ARS来校验所述验证令牌的有效性。
20.如权利要求11所述的系统，其特征在于，所述ARS被配置成从所述验证令牌中提取只为所述芯片所知的数据、再生所述密码、并对再生的密码和所述验证令牌作比较。
21.如权利要求11所述的系统，还包括用于向发卡机构提交已获验证的交易授权请求和未获验证的交易授权请求。
22.一种用于远程验证使用网络访问设备参与电子交易的客户的方法，所述方法包括向所述客户提供具有客户标识数据的集成电路芯片；提供可链接到所述客户的网络访问设备并能与所述芯片通信的读卡器；使用与电子网络链接的并可向读卡器传送数据的验证请求服务器(ARS)，来接收交易特定信息并将交易特定数据传送给所述读卡器；使用所述读卡器来将所述交易特定数据传送给所述芯片，以指示所述芯片基于所述交易特定数据的至少一部分和所述客户标识数据的至少一部分产生密码；使用所述读卡器来基于由所述芯片产生的密码的至少一部分产生验证令牌；使用所述ARS来确认验证令牌；基于所述验证令牌的确认产生AAV，并在全球持卡人验证字段(UCAF)消息中经电子网络向所述发卡机构传输所述AAV。
23.如权利要求22所述的方法，其特征在于，传送给所述读卡器的所述交易特定数据包括基于所述交易特定信息的质询。
24.如权利要求22所述的方法，其特征在于，使用所述读卡器来产生验证令牌包括用与3-D安全协议消息格式兼容的格式产生验证令牌。
25.如权利要求22所述的方法，其特征在于，所述AAV在电子网络上在具有20字节长度的UCAF中传输。
26.如权利要求22所述的方法，其特征在于，向所述客户提供集成电路芯片并提供读卡器包括提供共同置入单个物理包中的芯片和读卡器。
27.如权利要求22所述的方法，其特征在于，所述ARS上的确认包括通过首先重建所述芯片用来产生密码的数据，然后从重建数据产生副本密码，再匹配所述验证令牌与所述副本密码，来评估所述验证令牌中的客户标识数据。
28.如权利要求27所述的方法，还包括访问可由ARS访问的持卡人数据库来检索所存储客户信息。
29.如权利要求27所述的方法，还包括将确认结果传送给所述请求方。
30.如权利要求27所述的方法，其特征在于，所述ARS上的确认还包括使从所述芯片接收的应用交易计数器值匹配从所述芯片接收的应用交易计数器的先前值，从而验证所述交易。
全文摘要
提供了基于3－D安全协议的芯片验证程序，用于验证客户(180)的在线交易。可以是支付卡发卡机构的发卡机构运行访问控制和验证请求服务器(120)，用于验证由其个人的符合EMV的智能卡(170)标识的各个客户(180)进行的交易。基于来自客户智能卡(170)的信息、以及直接由发卡机构发送的用以填充POI上网页的交易特定信息，验证令牌在交互点(POI)上对每个交易产生。POI上产生的验证令牌由验证请求服务器(120)评估，以验证在交易POI上出现的各个客户和/或卡。验证值在与3－D安全协议一致的指定全球持卡人验证字段中在线传输。
文档编号G07F7/10GK1853189SQ200480019632
公开日2006年10月25日 申请日期2004年6月4日 优先权日2003年6月4日
发明者B·鲁特福德, A·达格, M·威斯曼, D·J－M·C·派伊, J－P·E·兰斯, F·阿特斯, J·万克姆勒 申请人:运通卡国际股份有限公司