CN1340784A

CN1340784A - 允许通过消费者设备使用智能卡进行网络商务

Info

Publication number: CN1340784A
Application number: CN01125140A
Authority: CN
Inventors: M·H·里内汉
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-08-31
Filing date: 2001-08-30
Publication date: 2002-03-20
Anticipated expiration: 2021-08-30
Also published as: US7103575B1; TW591459B; AU6188201A; CN1193313C

Abstract

允许通过消费者设备使用智能卡进行网络商务的方法、系统和计算机可读代码。这是通过将现有的“应用支付系统用集成电路卡规范”标准(通常称为“EMV”标准)与U.S.专利中提出的扩增的4方网络信用卡/借记卡协议集成起来而达到的。集成的结果使消费者能够使用智能卡从个人计算机系统进行信用卡或借记卡交易,同时还保留了信用卡组织和银行所需的安全级别和其它特性。对现有的EMV标准或现有的EMV智能卡不需要进行修改。

Description

允许通过消费者设备使用智能卡进行网络商务

发明背景

发明领域

本发明涉及一种计算机系统，更特别涉及一种允许通过消费者设备使用智能卡进行网络商务的方法、系统和计算机程序产品。这是通过将已有的EMV标准与扩增的4方网络信用卡/借记卡协议集成起来而完成的。

相关技术描述

使用信用卡或借记卡通过因特网和万维网(其中万维网，下文中称为“网络”，它是因特网的一个子集)进行“在线购物”，在今天消费者能够从街角的零售商那里购买商品，也可以从全球以及中间任何地方的零售商购买，完全由消费者自家的舒适情况而定。(在下文中，如果没有特别指出，词语“因特网”和“网络”是互换使用的。)消费者来到零售商的网站，典型情况是浏览一个或多个网页来选择要购买的商品或服务。消费者通过为交易的数量提供卡号给零售商来使用信用卡或借记卡来进行在线购物交易。提供消费者的卡信息有多种方法，包括使用在很多系统中日渐普遍的“电子钱包”软件。电子钱包，通常简称为“钱包”，是安全存储消费者卡信息的软件(也可以存储其它信息，例如消费者姓名和邮寄帐单的地址)。当通过网络进行购买时，钱包软件将消费者的个人信息作为购买交易的一部分提供给零售商，从而减轻了消费者记忆和为每次交易重新输入已存储信息的负担。钱包软件典型情况下在消费者计算设备处执行，消费者表示他或她希望进行购买后调用此软件作为对来自零售商的消息的响应。使用钱包软件的结果在本质上与使用电话从零售商处订购商品和口头交换如卡号、姓名、地址等信息的效果相同。(基于服务器的钱包软件实现在技术中也是已知的，其中钱包软件可以完全或部分的在基于网络的服务器上运行。这些钱包通过网络使用消费者浏览器或使用至少能确保消费者验证的小客户端软件来访问。

美国专利_______(序列号09/221,869,12/29/1998申请)，命名为“4方网络信用卡/借记卡协议”，在这里按参考资料被合并，为消费者在网上购物的时候提供了一种有效授权信用卡和借记卡交易的技术。(此发明在下文中称之为“相关发明”，其中提出的协议在下文中称之为“4方协议”。)授权过程在消费者(使用他或她的信用卡或借记卡以及消费者设备，如个人计算机，或“PC”)和发行消费者的卡的银行(下文中称之为“发行银行”或“发行方”)之间进行。如现在要描述的，这与已有的技术有差异。

不使用这个4方协议，授权会更为复杂，需要更多的系统开销(如在相关发明中所描述的)。在相关发明之前，这种在现有技术中已存在的技术以消费者向零售商表示他或她要购买商品作为开始，在此之后零售商或者直接，或者通过发送一个初始化消息来启动消费者的钱包软件以索要消费者的信用卡或借记卡信息(举例来说，发送一个页面给消费者，让消费者填充其中的空格)。当零售商收到卡的信息，不管是来自返回的页面或是来自钱包软件，接下来会将授权请求通过零售商用来进行卡交易的银行(下文中称之为“获款银行”)，私有卡网络(由MasterCard、Visa或类似的公司或卡组织运营)，最后发送到发行银行，向发行银行请求交易的授权。一旦交易被发行银行授权，授权会经过卡网络、获款银行，然后返回到零售商处。接下来零售商向消费者表示购买通过。在稍后期限之前的某一时间，零售商会发送必要的信息给获款银行，从发行银行收取资金。(“MasterCard”是MasterCard International Incorporated的注册商标，“Visa”是Visa international Service Association的注册商标。)

使用4方协议的一个主要优点是从消费者钱包发送“预授权”的支付消息给零售商的能力。通过使用4方协议，消费者的计算设备(为便于提及，下文中称之为PC)直接与发行银行相互作用来进行授权，而不是象现有技术那样由零售商请求授权。当发行银行授权了交易，会发送一个“授权标记”(即预授权的支付消息)到消费者PC，然后作为消费者钱包支付响应的一部分发送给零售商。因为交易已经为发行银行批准，所以零售商不需要执行独立的卡信息实时授权。(零售商在稍后的时候将授权标记转送到获款银行，用于从发行银行索取资金。)

近些年出现了一种新型卡，其设计比现有的信用卡和借记卡更为安全。这种卡称之为“智能卡”。这种智能卡包括一个逻辑芯片，包含存储的所有者信息，例如所有者的姓名、地址和帐号；卡发行方(如MasterCard、Visa等等)；个人识别号(PIN)；以及所有对卡用途的限制(例如用于个人购物的最大数额)。一个名为“支付系统用集成电路卡应用规范”的标准定义了信用卡和借记卡系统可以如何使用智能卡进行销售点终端系统(POS)的零售和自动取款机(ATM)交易。这个标准由三个信用卡产业的领导机构所发布：欧洲国际组织、MasterCard和Visa。因为在制定标准中涉及了这些团体，所以卡标准通常称之为“EMV”标准。(最新版本的EMV标准于1998年3月发布，使用网址http：//www.europay.com/smartcard可在网上找到。)

智能卡设计用于连接到放置在零售商商店的POS终端(或ATM)上的设备。除了“刷”卡(如使用当前带有磁条的信用卡和借记卡)，零售商或消费者可以将智能卡插入智能卡读卡机。接下来POS终端(或ATM)将卡加电，在终端和智能卡之间交换信息以允许消费者执行交易。(在下文中，智能卡会结合在POS终端上的使用来进行讨论。如果没有另外提到，这些讨论同样应用于ATM上的智能卡使用。)

根据EMV标准，在智能卡和零售商之间会发生两种类型的授权行为。第一种授权是“离线”授权，卡上逻辑芯片直接使用得自智能卡和POS终端的可用信息来认可交易。这种方式可以发生在，例如当交易数量和其它参量处于卡发行方、零售商和获款方确立的风险管理方针范围之内的时候。第二种授权是“在线授权”，交易必须由发行银行使用卡发送的，通过POS终端、获款银行、适合的卡网络(也就是MasterCard、Visa等等)，最后到达发行银行的消息来授权。响应消息从发行银行通过卡网络到获款银行、零售商的POS终端，最终发送到消费者的智能卡，认可或拒绝交易。在成功交易之后(也就是授权消费者进行交易)，消息最终由零售商传输到获款银行，从发行银行真正的收取与交易关联的资金。)

如前面所述，EMV标准是为在放置在零售商商店里的POS终端上使用而设计的。标准假定可以依赖POS终端来执行许多重要的安全功能，例如交易授权。因为消费者设备处于消费者控制之下，这些安全功能的履行必须移往他处，因此已有的EMV标准不直接适用于使用智能卡进行网上购物(这里不存在POS终端)。此外，已有的EMV标准在执行交易授权的时候没有很好的利用网络的全球连通性。

因此所需的是一种技术，允许消费者使用智能卡技术从消费者计算设备通过网络购买商品，但不需要现有的EMV标准或现有的智能卡。

发明概述

本发明的目的是提供一种技术，用于结合消费者计算设备使用智能卡通过网络从零售商处购买货物或服务。

本发明的另一个目的是提供这种不需要修改现有EMV标准的技术。

本发明还有另外一个目的是提供这种不需要修改现有智能卡的技术。

本发明还有另外一个目的是通过将由EMV标准描述的功能与4方协议结合起来以提供这种技术。

本发明的深层目的是提供这种技术，由此执行可信功能的责任被移到了智能卡发行方。

本发明还有另外一个目的是通过利用消费者直接连接到智能卡发行方的能力来提高授权网上在线购物智能卡交易的效率。

本发明其它的目的和优点一部分由后续的描述和附图给出，一部分可由描述给出或可以通过本发明的应用来获知。

为了达到上述目的，以及根据这里概括描述的本发明的目的，本发明提供了一个计算机程序产品、系统和方法，用于允许通过消费者设备使用智能卡进行网络商务。这种技术包括：初始化与零售商进行的，使用可以由消费者设备直接访问的智能卡的交易；通过消费者设备，将已验证的授权请求消息由智能卡发送到智能卡发行方；通过消费者设备，直接由智能卡发行方获取已验证的交易授权；核实授权验证；将授权包含在响应交易并由消费者设备发送给零售商的支付消息之中。

初始化更进一步包括：将交易请求从消费者设备发送给零售商；在零售商处接收交易请求；作为对交易请求的响应，从零售商处发送支付初始化消息到消费者设备，其中支付初始化消息包括智能卡所需的交易数量、时戳、随机场合(random nonce)和数据；以及接收由消费者设备发送的支付初始化消息。

发送已验证的授权请求消息更进一步包括：从消费者设备发送消息到智能卡，使智能卡使用在线授权；通过消费者设备从智能卡接收授权请求(AR)，其中AR包括用于交易的卡帐号、交易数量、交易日期和智能卡序列号；通过将接收到的支付初始化消息与AR合成来生成已验证的授权请求消息；以及直接从消费者设备发送已验证授权请求消息到发行方。获取已验证授权更进一步包括：在发行方接收发送的已验证授权请求；在发行方生成用于交易的授权标记，作为对接收到已验证授权请求消息的响应；由发行方生成发行方授权数据，以及可选发行方命令；从发行方将授权标记伴同发行方授权日期和可选的发行方命令发送到消费者设备；通过消费者设备接收发送的授权标记、发行方授权日期和可选的发行方命令。生成授权标记更进一步包括：核实卡的帐号；核实对应于智能卡的帐号能满足的交易数量的能力；如果核实得到肯定的结果就授权交易。

包含的授权更进一步包括：将接收到的发行方授权数据和可选的发行方命令由消费者设备传递到智能卡；通过消费者设备从卡处接收交易证明(TC)；将TC和接收到的授权标记作为支付消息由消费者设备发送到零售商；在零售商处接收支付消息；将获得的请求与支付消息一起由零售商发送给获款银行，作为对接收的支付消息的响应；在获款银行接收记录请求和支付消息；以及从用于交易的智能卡对应帐号中收费，作为对接收的记录请求和支付消息的响应。

支付消息还可以进一步包括授权标记。作为选择，支付消息还可以进一步包括一个或多个对可选发行方命令的响应。

现在将结合附图来讲述本发明，在附图中同样的引用数字表示相同的要素。

附图简述

图1说明了现有技术的EMV环境。

图2说明了根据本发明集成了EMV和4方协议的环境。

图3A说明了在现有技术的EMV环境中用于动态数据授权的消息流程。

图3B说明了根据本发明的用于动态数据授权的消息流程。

图4说明了在现有技术的EMV环境中用于在线授权的消息流程。

图5说明了根据本发明用于在线授权的过程。

图6说明了现有发明的4方协议的交易流程；以及

图7说明了当EMV和4方协议根据本发明集成起来时的交易流程。

优选实施例描述

本发明使消费者能够通过网络使用智能卡进行购物(和进行其它类型的在线金融交易)，智能卡由连接到PC一类的消费者计算设备的智能卡读卡机来处理。(注意，在结合使用PC来描述本发明的过程中，其目的是用于说明，而不是限制。其它消费者设备倘若带有智能卡读卡机、处理器、存储器、键盘和显示器，那么可以替代使用。在很多消费者设备上可以找到这些性能，其中任何一个都可以支持本发明的功能。示例包括用于电缆或微型电视接收的置顶盒、可视电话、蜂窝电话和个人数字助理或“PDA”。)这是通过将智能卡EMV协议与在相关发明中定义的4方协议集成起来而达成的。通过扩充在4方协议中传输的信息，本发明能够使用现有的智能卡，并且避免了更改现有的EMV标准。在现有的EMV环境中智能卡用在零售商的POS终端或ATM上，由POS或ATM提供的功能具有固有的信用(举例来说，要正确评估风险参数)。当用消费者的计算设备替换了POS或ATM时，由于消费者误用设备相对要容易一些，这种固有的信用不再存在。因此要像即将展示的那样，根据本发明将重要功能的执行移到其它的地方。

现在结合图1到7来讨论本发明的优选实施例。

在优选实施例中，本发明是作为一个或多个计算机软件程序中的一个或多个模块(在面向对象编程语言中还称之为“对象”)来实现的。这种计算机软件会用在消费者通过网络使用智能卡购买商品(或进行其它金融交易)而与零售商相互作用的环境中。所适用的消费者计算设备必须如EMV标准定义的，提供使用智能卡的界面。

在详细讨论本发明之前，现在先讲述现有的EMV环境。接下来再解释本发明提供同等功能和达到同等安全性的方法。

EMV卡或智能卡由银行发行给其持有者以减少消费者信用卡和借记卡购物中的欺骗行为。EMV标准定义了用来实现很多功能的智能卡应用，包括：

-信用卡或借记卡支付的离线授权，这时支付的数量和其它参数要

在卡发行方、零售商和获款方所建立的风险管理方针的范围之

内。“授权”意思是卡发行方向零售商担保了支付，而不管卡持

有者是否支付给卡发行方。“离线授权”意思是只使用智能卡和

零售商终端中的可用数据来实行授权。(在使用本发明时，不需

也不支持离线授权。)

-在风险管理方针范围之外的在线授权支付。在线授权意思是零售

商的POS终端从发行银行获取支付认可。(在使用本发明时支

持在线授权。)

-智能卡验证，目的是防止造假。对于这种数据验证功能EMV有

两种变化形式：静态数据验证和动态数据验证。静态数据验证使

用卡放行方在将信用卡或借记卡帐号放置在卡内时所生成的数

字签名。动态数据验证使用由智能卡自身在每次支付时动态生成

的数字签名。(注意，卡授权是由EMV在线授权暗中进行的，

因此静态和动态数据验证在本发明的上下文的环境中不是完全

必需的。但是，两种数据验证都是受支持的。)

-卡持有者验证，使用几种卡持有者核实方法(CVM)之一来进

行。常用的CVM是离线PIN处理，其中卡持有者输入一个由智

能卡本地核实的PIN。另外一种做法是在线PIN处理，卡持有

者输入PIN，PIN加密后发送给发行方进行核实。其它方法包括

书面签名或生物鉴定。(在使用本发明时，离线PIN处理、在

线PIN处理和生物鉴定都受其支持。书面签名不受支持。)

-PIN加密，用于由安全的PIN键盘通过终端发送到智能卡的

PIN。这确保PIN不会在键盘和卡之间的传输路径中被截获。(在

使用本发明时不支持PIN加密。)

-发行方脚本，是由发行银行，通过获款银行和零售商，传输到卡

持有者的命令。这些命令可以执行不同的功能，例如重新设置离

线PIN的重试次数，禁用卡，以及禁用卡的各个功能。发行方

脚本中的命令为发行方提供了一种管理其全体EMV卡的方法。

(在使用本发明时支持发行方脚本处理。)

现在使用协议的处理步骤来更为详细的讲述当现有EMV标准定义的协议用在POS终端或ATM上时所运行的方式。步骤包括：

A.初始化应用程序：卡持有者将智能卡插入到POS终端。终端感

应到卡的存在，将其加电。卡生成对重置消息的响应，提供关于

卡功能的详细信息。终端和卡互相交换信息，其中终端核实卡具

有EMV支付应用程序，选择应用程序进行进一步处理，并从卡

中读取各种数据。终端初始化应用程序，发出一个GET

PROCESSING OPTIONS命令以将处理数据选项列表(PDOL)传送

到卡中，并从卡中重新获得各种数据。PDOL包含有卡所请求的

数据，例如交易的数量、终端容量、获款方标识符、零售商标识

符等等。

B.读取应用程序数据：终端根据卡所提供的不同参数从卡中读取不

同的数据。

C.数据验证：终端可以执行静态数据验证或动态数据验证来核实卡

是合法的。选择哪一种来执行取决于卡和终端容量两者。

在静态数据验证中，发行方对卡所承载的不同数据进行数字签名。终端读取此数据和发行方的签名，使用由几个已知的证明权威机构之一提供的发行方证明来核实发行方的签名。已知证明权威机构的公开密钥必须预先存储在终端之中。这证明卡包含有有效的发行方数据。

下面结合图3A详细讲述根据现有技术的动态数据验证。

D.处理限制：终端核实各种处理限制，例如检查智能卡中EMV应

用程序的兼容性，检查卡应用程序的版本号，特定用法控制和卡

过期日期。在标准EMV中，处理限制由零售商POS终端来实

施。

E.卡持有者核实：卡持有者核实是一个可选的过程，可以用来核实

授权卡持有者是存在的。它可以由离线PIN处理、在线PIN处

理、书面签名或生物鉴别来执行。

如果卡请求离线PIN处理，终端提示用户输入PIN。PIN可以通过PC键盘或组合在智能卡读卡机中的安全PIN键盘来输入。PIN传送到卡中，核实是使用了正确的PIN。接下来卡肯定或否定的响应POS终端。(如果卡支持，可以在将PIN传送到卡之前加密以确保PIN不会从终端中被读出。)

如果卡要求在线PIN处理，终端提示用户输入PIN。PIN被加密，由零售商POS终端经过获款方和卡网络传送到发行银行。根据ISO(国际标准化组织)标准9564，使用DES(数据加密标准)对称密钥来进行加密和PIN处理。(ISO9564名为“银行--个人识别号管理与安全”，1996年作为标准发布。)出于这个目的，零售商POS终端必须与获款方共用一个预先安排的对称密钥。

F.终端风险管理：这是由终端执行的一组测试以决定是否需要在线

授权。例如，如果交易数量超过指定界限，那么可能会需要在线

授权。(在使用本发明时，PC一直执行在线授权，而不是执行

典型的EMV终端风险管理步骤。)

G.终端动作分析：终端初步决定是拒绝交易，在线授权还是尝试离

线授权。终端发给卡一个GENERATE AC命令。这个命令中的参

数指出终端希望如何继续操作。终端可以通过GENERATE AC命

令中的参数来强制在线授权。(注意，对于所有的交易来说，这

个强制在线授权的功能需要所有现有的智能卡和所有现有的

EMV实现支持在线授权处理，所以在使用本发明时，所需的在线

授权不需要具有额外特性的实现。强制在线授权将授权或拒绝交

易的任务交给有支付义务的发行方。

H.卡动作分析：卡基于终端的输入和发行方的政策来决定如何继续

进行。在在线授权的情况下，卡返回一个授权请求密码(ARQC)

给终端。卡可以使用非对称的或对称的加密技术对ARQC进行数

字签名。它包括的数据有卡帐号、交易数量、日期、卡序列号和

其它信息。

I.在线处理：终端通过获款方和卡网络发送ARQC到发行方。发行

方核实ARQC上的数字签名，确认交易中的真正智能卡的存在。

发行方检查它的帐号记录以确定交易数量是否在帐号限制范围

之内，然后以发行方验证数据的形式发送认可或拒绝消息。发行

方可以使用非对称的或对称的加密技术对发行方验证数据进行

数字签名。

J.发行方验证：终端使用第二个Generate AC或External

Authenticate命令将发行方验证数据传送到卡中，如果卡可接

受发行方验证数据，就使用交易证明(TC)作为响应。另外，如

果发行方验证数据不可接受，卡生成一个应用验证密码(AAC)。

K.发行方脚本：发行方也可以在对终端的响应中加入发行方脚本。

如前所述，这些脚本被用来执行卡管理功能，例如解锁PIN。在

使用时，发行方脚本与消息中的发行验证数据一起由发行方，经

过卡组织网络、获款方和零售商POS终端。终端将这些脚本传

递给卡进行处理。卡会生成发行方脚本结果，在随后的记录消息

中传递回发行方。

L.完成：如果交易成功结束，零售商得到来自卡的表示结果的TC

和AAC(见上面的步骤J)。零售商将TC和发行方脚本结果

包含在任一发送给获款方的记录消息中。

现在结合图1来讲述现有技术中的EMV运行的环境，图1讲述了主要组成和这些组成之间的消息流程。要进行购物，需将消费者的智能卡100插入零售商POS终端105的读卡机中。象使用信用卡和借记卡一样，使用智能卡购物必须在它完成之前进行证实。如前所述，EMV标准支持两种不同的银行证实每个交易的方法：离线授权处理和在线授权处理。

当卡自身证实交易的时候使用离线授权处理。如上所述，这通常用于风险处于零售商和银行愿意接收的门限之内的小额款项的交易。因为在消费者的智能卡100和零售商POS终端105之间只发生了需要完成授权的相互作用101、102，所以这典型加快了全部的交易时间。接下来，零售商将记录的请求传递给获款银行110，获款银行指示发行银行120以收取与交易关联的资金。(记录请求通知获款银行对消费者的帐号收费。)

因为消费者的PC没有足够的信用来履行离线授权这一职责，所以在本发明的环境中不支持离线授权。此外，由于根据定义，消费者PC是在网上进行通信，因而是在线的，所以在使用本发明的时候，离线授权不是必需的。

在现有技术中需要对支付授权进行在线处理的情况下，智能卡100通过发送请求101到零售商POS终端105，再将请求发送106到获款银行110，从发行银行请求授权。接下来获款银行110使用适合的卡网络115(例如MasterCard或Visa网络)来发送111消息(例如授权请求)到发行银行120以获得授权。然后发行银行120授权购买或拒绝购买，将其响应通过网络115发送回112获款银行110，获款银行再将响应发送107到零售商POS终端，再发送回102智能卡100。如果认可了交易，那么零售商就传递记录的请求108(接下来被发送到发行银行)以收取与交易关联的资金。(在图3A和图4中更为详细的讲述了发生在图1环境中的验证和授权功能。)

图2说明了根据本发明而结合的EMV和4方协议运行所处的环境。如早些讨论的，4方协议利用了因特网的全球互联性，允许消费者PC直接从消费者发行银行获得支付预授权，而不是使用上面结合图1讲述的卡授权过程。这使得消费者设备可以将卡授权(如授权标记)与支付消息一起呈送给零售商。将这种授权标记与支付消息一起发送的一个好处是可以不必发送消费者帐号给零售商。这减少了帐号的暴露，因此可以减少在零售商处工作的不道德职员行窃的潜在危险。还有一个好处是预授权显著简化了支付协议的很多方面，使得很多消费者功能可以在发行银行远程执行。

根据本发明，直接与发行银行执行在线授权的技术克服了消费者计算设备的不可信地位。(注意，在使用本发明时，零售商、获款方和卡网络不参与授权过程。)

如图2所示，消费者PC205在本发明的集成EMV环境中是一个新组件。PC必须装有智能卡读卡机、合适的软件，并通过网络210连接到零售商225和消费者发行银行220(或发行方网关215)。智能卡读卡机可以带有安全PIN键盘；作为选择，PIN可以通过PC键盘输入。消费者PC205必须作为到EMV智能卡的POS终端，实现使EMV卡按照这里讲述的集成EMV和4方协议进行工作所需要的功能(举例来说，响应来自零售商225的请求)。如已经描述的，因为PC205处于最终用户而不是零售商或银行的控制之下，所以PC不能与POS终端或ATM一样的方式来信任。因此本发明避免了对执行信任相关的功能的PC205的任何依赖。这样的功能或交给发行方网关215或发行银行220执行，或交给零售商225执行，或进行简化以使PC205不产生重要的处理结果。

现在结合图3A、3B、4和5来讲述现有技术中用于EMV处理的数据验证功能和授权功能运行的方式，以及这些功能根据本发明如何运行。

图3A更为详细的说明了根据现有技术在EMV中对动态数据验证的处理。智能卡300使用动态数据验证可以为提供给它的数据进行数字签名。POS终端305如消息310所示为卡提供不可预知的数字和其它数据。智能卡300使用不可预知的数字来随机化计算过程，对POS终端数据和智能卡承载数据的组合体进行数字签名，然后将结果发送315到POS终端305。(对消息数字签名以确保消息可靠性的技术，以及使用数字证明来保护电子消息安全性所使用的技术在技术中是已知的，这里就不详细讲述了。)POS终端使用由发行银行提供的智能卡证明和由几个已知证明授权机构之一提供的发行银行的证明来核实智能卡的签名。已知证明授权机构用来执行这个证明的公开密钥必须预先存储在POS终端之中。成功完成证明意味着智能卡不是伪造的。

图3B说明了用于动态数据验证的类似处理根据本发明是如何执行的。为完成与现有BMV中的动态数据验证相同的功能，零售商305在消息306中将用于验证的数据发送到(如结合图3A所述的那样)消费者PC335。这发生在集成协议的消息流程705的过程中，下面将结合图7更为详细的进行讲述。接下来消费者PC335在消息307中将验证用数据发送到智能卡300。然后智能卡300签名数据(如结合图3A所述的)，将它通过308返回到消费者PC335。用于静态数据验证的数据也从智能卡300发送到消费者PC335。因为消费者PC335不可信(从安全的角度讲)，所以得自消息308的已签名的动态应用数据(和静态授权数据)在消息309中通过发行方网关345发送到发行银行350。(这里描述的本发明用于执行授权的功能可以在连接在发行银行和消费者之间的发行方网关中实现，如图3B所示。另外一种做法是可以省去发行方网关，在这种情况下这个功能在发行银行实现。不管功能是在发行银行还是在发行方网关进行，下面的描述都是等同的。)这个消息309在图7中集成协议的消息流程710过程中产生。在发行方网关345处使用得自消息309的信息来执行证明过程，并为授权请求生成一个肯定或否定的响应。然后这个响应消息310被发送到消费者PC335(其中这个消息流程310对应于图7的消息流程710)。

因此，消费者PC335执行类似于现有EMV中的零售商POS终端的验证功能。特别是，消费者PC中的软件接收零售商的验证用数据，发送验证用数据到智能卡，接收已签名的动态应用数据，发送已签名的动态应用数据(和静态验证数据)到发行方网关，并接收来自发行网关的响应。使用集成协议处理的结果是智能卡为发行方网关或发行银行(而不是象现有技术中由零售商)所核实，而不需要依赖于PC软件的信任度。

图4说明了根据现有技术EMV中的在线授权处理。在线授权的标准EMV处理包括智能卡400生成传输430a到POS终端405的授权请求密码(ARQC)。这个ARQC由POS终端发送430b到获款银行410。然后ARQC由通过适当的私有卡网络(也就是MasterCard或Visa网络等等)被发送430c到发行银行420。发行银行用发行方验证数据来进行响应，数据通过卡网络415被发送到获款银行410。获款银行将发行方验证数据431b发送到POS终端405。然后将发行方验证数据发送431c到智能卡400。智能卡400确认发行方验证数据，如果接受交易，就生成一个交易证明(TC)作为授权交易的证据。在效果上TC替代了用在书面交易上的卡持有者签名。智能卡400将TC发送432a到POS终端405。随后POS终端405将TC作为记录请求发送432b到获款银行410(前面讲述的)。获款银行410在期限前的某一时间将TC发送432c到发行银行420以转移交易所用的资金。

图5说明了使用本发明集成协议进行在线授权的相似处理是如何发生的，其中授权在消费者PC505和发行方网关510(或发行银行515，是等价的)之间执行。ARQC(如图4所述)530a由消费者EMV智能卡500发送到消费者PC505，而不是象现有技术中那样直接发送到零售商POS终端520。消费者PC505将ARQC转送530b到发行方网关510进行处理。发行方网关510(或发行银行515)处理ARQC并生成要发送到消费者PC505的发行方验证数据531a。消费者PC505将发行方验证数据531b发送到智能卡500进行处理。卡生成一个要传送530a到消费者PC505的TC，然后转送532b到零售商520。因此零售商接收到预授权的支付消息，该消息与现有技术中的TC具有相同的资格：TC作为支付的证据，可以在随后的记录消息中使用。

零售商520在期限前的某一时间将TC发送530c给获款银行525。然后获款银行525将TC转送530d到发行银行515索取付款。

图6说明了用来实现在相关发明中定义的4方协议的消息流程。4方协议设计用于消费者使用信用卡或借记卡进行远程购物的时候，其中消费者PC要通过网络连接到零售商。下面讲述的图7接着说明了本发明如何将这个4方协议与EMV集成起来以支持消费者使用智能卡进行交易。

相关发明的4方协议处理由消费者使用，例如他或她个人计算机上的浏览器通过网络购买零售商商品来进行初始化。一旦确定了选择，消费者接下来会选择“购买”按钮或“付费”按钮或其它类型的选项来表明消费者希望购买商品或服务。

接下来“购买”指示600被发送到零售商的网站。零售商处理该信息(也就是消费者的选择)，并生成钱包初始化消息。这个消息典型的包括支付数量、定单描述、时戳、随机标识以及可能根据特定选购要求附加的数据。根据现有技术，随机标识是一个为了唯一标识这个交易而生成的随机数字。(这个标识用在生成ARQC和授权标记中，目的是确保它们的唯一性。这个标识由零售商，而不是消费者设备生成，因此为使用该标识的消息更加难以伪造提供了保证。)零售商使用由获款银行提供的数字证明来对这个初始化消息进行数字签名。接下来将已签名的初始化消息和数字证明605发送给消费者。

钱包初始化消息605的接收促使消费者浏览器(或同等意义的软件)启动消费者钱包(或同等意义的)程序。根据现有技术，消费者被提示登录钱包程序，其中登录过程一般需要用户输入用户标识和密码，或智能卡，和/或使用其它一些验证消费者的适当方式(可以包括生物测定和/或特定的硬件)。(注意，虽然相关发明的4方协议表明可以使用包括智能卡在内的不同方式来验证卡持有者，但是在相关发明中没有提及使用智能卡用于真正的消费者交易。后者是本发明的研究对象。)已签名的初始化消息由钱包软件进行核实。假设核实成功，那么钱包程序发送消息610给发行银行，其中这个消息包括得自钱包初始化消息605的所有数据，以及来自登录过程的消费者标识和验证数据。典型的，这个消息在传输之前由消费者钱包程序进行数字签名以确保信息不能被更改。消费者的数字证明也可以与消息610一起传输。(另外一种做法是，发行银行可以使用消费者的标识从证明注册记录中取得消费者的公共密钥来查找消费者的密钥和/或证明。)作为钱包软件对消息610进行数字签名的替代作法，可以使用其它方式来验证卡持有者，例如使用智能卡或密码。(如上所述，这种使用智能卡来进行卡持有者验证不是本发明的研究对象。)

注意，图6和图7中消息流程的描述涉及到在发行银行和获款银行之间消息的发送。它可以在下列特定情况下发生：描述的功能在连接在发行银行和消费者之间的发行方网关中和/或在连接零售商和获款银行之间的获款方网关中实现。为了简化说明，这些网关没有显示在图6或图7之中。但显然，下面涉及在各个银行中执行的，现有技术中的功能的描述可以同样应用于这些网关中的功能实现。

发行银行在接收消息610之后，使用零售商的数字证明来核实零售商的签名，确认零售商和发行方享有共同的金融装置，例如与MasterCard、Visa、ATM网络或类似金融机构相关联的装置。然后发行银行核实消费者标识及其帐户信息(举例来说，确保帐户仍是开放的，能够接受此次收费等等)，核实消费者的数字签名(或替代的验证方式)。在成功核实之后，发行银行生成一个已签名的授权标记，并与发行银行的数字证明一起发送615给消费者钱包程序。典型的授权标记包括来自消息605的所有数据，再加上零售商标识符和对消费者信用卡号或借记卡号的引用。(如在相关发明中所述的，引用是发行银行与卡号相互关联的某些类型的值。发送消费者卡号的引用避免了通过网络来传输卡号，因此增加了交易的安全性。)

消费者钱包程序将620授权标记转送到零售商，零售商可以核实授权标记中的发行银行的数字签名和数据。因为发行银行已经生成了这个支付消费者购买的授权，零售商不需要单独请求信用卡信息的授权。

在随后的某一时间，可能是在一天结束时或甚至在一周结束时，零售商将记录请求中的授权标记提交625给获款银行，通知获款银行将收费630发送到消费者信用卡或其借记卡帐户。如在635处所示，获款银行将记录响应消息发送给零售商。这个记录的响应用来认可记录的请求625。(注意，一个记录响应635可以认可多个记录请求，因此可以过一段时间之后再来传输消息635。)

在典型的EMV实现中，安全消息功能确保了在EMV卡和发行方之间交换的消息是密码验证的。特别是，ARQC、发行方验证数据和TC使用键入的消息验证码(MAC)来进行验证。在本发明中，MAC确保了可信度不足的PC不能够修改这些消息。

现在结合图7来讲述当相关发明的4方协议根据本发明为支持智能卡与EMV集成时进行扩充所采取的方式。

消费者使用消息700来表明他或她希望购买商品或服务，或者执行金融交易，方式与图6中的消息600相同。

卡核实必须要执行，以确保使用智能卡的消费者是授权的卡持有者。前面讲述的除书面签名之外所有的卡核实形式在集成协议中都被支持。使用消费者PC替代POS终端，集成协议使用同样的，上面讲述的用于离线PIN处理的现有技术EMV过程。即PIN传递给卡进行核实：如果使用了错误的PIN，卡拒绝交易，消费者必须重新开始；否则，卡允许处理继续进行。PIN加密选项也以与现有技术中相同的方式工作。

如果使用了在线PIN处理，消费者被提示通过标准PC键盘或通过特殊的安全PIN键盘输入PIN。为了安全传输到发行银行，PIN必须加密。根据优选实施例，用于加密要传输到发行方进行在线PIN处理的PIN的技术改变了在现有EMV实现中使用的技术。如前所述，现有的EMV使用了标准ISO9564 PIN安全管理来进行在线PIN处理。因此在这个现有的方法中使用了DES对称密钥加密方法，其中传输的每一方都保存此共用密钥，并使用此密钥对传输的数据进行加密和解密。从安全角度讲，因为存在消费者PC，所以本发明的优选方法是使用非对称(公开密钥)加密算法。(即，对称加密方法需要在可信度不足的设备上长期存储密钥。如果使用了公开密钥加密方法，就不是这种情况了。)

对于本发明可以执行公开密钥加密的一个方法是通过加在4方协议中的两个消息流程来获取密钥。消费者PC在新消息710中将密钥请求发送到发行银行。发行银行在新消息702中返回一个密钥响应，响应中包含一个新的、在所使用证明层中证明了的发行方加密证明。消费者PC核实这个证明，提示用户输入PIN，使用包含在发行方加密证明中的公开密钥加密PIN。消费者PC将这个加密的PIN包含在4方授权请求中，并在消息710中将此请求发送到发行银行。发行银行进行解密，然后核实PIN。如果PIN不正确，它就拒绝授权(在消息流程715中)。(注意，虽然消息701和702按讲述是在消息700之后发生，但在不超出本发明范围的情况下，他们也可以在消息700之前或消息705之后发生。)

另外一种做法是，用于在线PIN处理的密钥可以通过直接在钱包软件中静态的、永久性的提供一个发行方公开密钥的方式来获得(因此就省略了消息701和702)。在这种情况下，钱包可以使用发行方公开密钥来加密在线PIN，然后按照上面讲述的对消息710和715的方式进行处理(其中发行方使用相匹配的私有密钥对PIN进行解密)。

在由本发明使用的扩增钱包初始化消息705中，钱包初始化消息预先准备和包含EMV卡处理数据选项列表(PDOL)中所需的所有数据，PDOL在前面已有描述。支付数量和时戳也已经包括在4方钱包初始化消息中。商标、零售商标识符和获款方标识符可以作为附加域包括在钱包初始化消息705之中，或者从零售商数字证明(最好是已经包含在其中)中获得。但是因为这些标识符是特定商标，消费者在按下支付或购买按钮之前最好是通过零售商在线售货屏幕的一个组件来指定他或她想要使用的卡的商标。(对于消费者用来选择支付标记的不同方法，请参看下面所讲述的优选实施例的可选变化。)

在钱包初始化消息705启动消费者钱包程序之后，消费者被提示将EMV智能卡插入智能卡读卡机。钱包初始化EMV应用程序，从卡中读取应用数据，包括主帐号。钱包核实包含在从卡中得到的主帐号中的编码商标与钱包初始化消息705中的商标是匹配的。

注意，消费者PC必须要知道发行方网关的网络地址以传输消息701和702。达到这一目的的一个方法是在智能卡中存储发行银行的全球资源定位符(URL)或网络地址。作为一个选择，消费者PC软件可以使用帐号从网站或网络目录查找这个URL。(后一概念在“基于ISO7812/7816的卡号和主域名系统(DNS)”中有定义，工程任务组草案由Donald Eastlake起草，并于8/19/1999申请。)

因为消费者PC不能寄予信任来执行标准EMV的数据验证、处理限制和终端风险管理的步骤，所以本发明将这些任务放置在发行方。用于执行这些功能的附加信息在消息710中(与前面讲述的钱包初始化消息705一起)传输给发行方。特别是，EMV签名的静态应用数据、动态应用数据和鉴别处理限制所需的所有数据被加入到消息710中。如果卡执行动态数据验证，那么钱包首选使用得自钱包初始化消息的随机标记作为唯一号码。钱包通过GENERATE AC命令发送的参数来强制智能卡使用在线授权。然后卡生成一个ARQC，钱包也将ARQC包含在请求消息710中发送到发行银行。发行银行使用这个ARQC来验证卡持有者。

钱包在消息710中将得自钱包初始化消息705的数据再加上已讲述过的EMV数据发送给发行银行。

发行方在接收的消息710的基础上执行核实处理，类似于对图6中的消息610所描述的。另外，发行方确认来自消息710中扩增信息的已签名的静态或动态应用数据的有效性。对于动态数据验证，发行方使用来自在消息710中传递给发行方的钱包初始化消息705的数据来确认已签名动态应用数据的有效性。然后发行方鉴别所有的处理限制，作为决定用消息流程715对PC作出肯定还是否定响应的一部分。发行方还象现有技术中那样确认ARQC的有效性。

如果使用在线PIN处理，发行方解密PIN，再根据ISO9564重新进行加密以满足接口要求，然后将加密后的PIN包含在到发行方卡处理系统的授权请求中。如果发行方的卡处理系统证明了交易，那么发行方生成已签名授权标记，并将其与发行方证明一起在消息715中发送给消费者钱包。授权标记包括开始时在钱包初始化消息705中传递的数据，以及零售商标识符和消费者智能卡号的引用。发行方还生成发行方验证数据，可选的生成发行方脚本并将这个信息包含在消息715中。(注意，所有由发行银行生成的发行方脚本在消息715中直接传递回消费者PC，然后传到EMV卡，因此使用了比在标准EMV中更为直接的通信路径来支持发行方脚本功能。

在接收消息715的基础之上，消费者钱包将发行方验证数据和所有的发行方脚本传递给卡。接下来，如果发行方验证数据是可接受的，卡生成一个TC，否则生成一个AAC。卡根据现有技术处理所有的发行方脚本，可以产生发行方脚本结果。钱包从智能卡取回TC和发行方脚本结果(如果有的话)，传递给零售商。然后钱包在消息720中将TC、所有的发行方脚本结果和授权标记发送给零售商。接下来零售商核实发行方签名、授权标记中的数据和TC。注意，因为支付在它到达零售商之前是预先授权的，所以不需要单独的实时授权。此外，TC表征的是消费者支付的证据，应该阻止进行交易。零售商可以将这些标识看作是支付的保证，对于授权不需要其它的证明。

零售商在稍后的某一时间提交记录请求725中的授权标记和/或TC，将其发送到获款方的支付网关(或获款银行)。记录请求告知获款方向消费者帐户收费，如上面结合图6中消息625讲述的一样。消息730通过卡网络发送到发行银行，通知发行方进行转帐。由卡产生并在消息720中发送给零售商的所有发行方脚本结果也在消息725中传递给获款方，并被包含在消息730中。最后如上面对消息635的讲述，获款银行发送一个记录响应消息735给零售商，告知收到记录请求735。

在已讲述的优选实施例中，消费者通过零售商在线售货屏幕显式的选择他或她想要使用的商标，因此在钱包初始化消息中可以包括商标相关的数据。(这个商标相关的数据包括零售商标识符、获款方标识符，可能还包括如上面所述的零售商证明和签名。)在优选实施例的可选变化形式中，消费者对智能卡的选择可以是在暗中选择消费者希望使用的商标。有几种其它技术可以用来实现这一点。

在第一种技术中，零售商可以发送多个数据数组给消费者钱包，零售商所接受的商标各有一个数组。每个数组会包括商标名、零售商标识符和获款方标识符。在消费者将智能卡插入卡槽之后，钱包会从卡中读取帐号，并使用ISO帐号规则来匹配标记的帐号。(例如，如果帐号以数字“4”开头，那么它是一个Visa帐户；如果以“5”开头，那么是一个MasterCard帐户；等等。)钱包会从匹配商标的数组中选择零售商标识符和获款方标识符。

在第二种技术中，上面讲述的数组会包括商标名的前缀ISO帐号。该帐号前缀与卡帐号的第一个或更多的数位匹配。这种技术提供了另外一种方法来将零售商和消费者知晓的商标与提供的关于EMV卡的帐号进行匹配。

在第三种技术中，要在钱包和零售商之间进行一次额外的消息交换。首先，零售商会象原始4方设计中讲述的那样发送钱包初始化消息(参看上面对消息605的讲述)。第二，消费者插入EMV卡，钱包会从卡中读取帐号。第三，钱包会就商标名或帐号的前几位发送一个新消息给零售商。最后，零售商会发送一个新响应消息回钱包。这个响应消息会根据EMV卡的商标包含适当的零售商标识符和获款方标识符。如果零售商证明和签名是商标相关的，那么这些数据也可以在这个附加的响应消息中发送给钱包。

在第四个技术中，称之为“应用标识符”或“AID”的EMV特性可以用来选择商标。AID表示在特定的智能卡上装有哪种应用(也就是可选功能)。特定商标分配有独特的AID。例如，一个表示“此卡用于MasterCard”的AID。因此，零售商可以在关联数组中传输适合的卡商标的AID，这样一个或多个这种形式的数组(AID、零售商标识符、获款方标识符)被发送给钱包软件。零售商接受的商标最好各送一个这样的数组。接下来，钱包读取由智能卡支持的AID，并将这些AID与由零售商接收到的数组进行匹配以寻找交集。如果交集为空，那么智能卡不能用于该零售商。如果交集有一个条目，那么钱包选择该条目。如果交集有多个条目，那么零售商最后询问消费者要使用哪一种商标。

虽然已经讲述了本发明的优选实施例，但对于那些有才能的人来说一旦掌握了本发明的基本概念，就能够对实施例进行其它的变化和修改。因此将解释附加的权利要求以包含优选实施例和所有符合本发明原理和范围的变化形式和修改。

Claims

1.一种计算机程序产品，允许通过消费者设备使用智能卡在网络环境中进行可信的交易，计算机程序产品包含在一个或多个计算机可读介质中，可由网络环境中的一个或多个计算机系统读取，包括：

用于初始化使用智能卡与零售商进行的交易的计算机可读程序代码装置，智能卡可以从不可信的消费者设备中直接访问；以及

用于使用扩增的4方网络信用卡/借记卡协议完成交易的计算机可读程序代码装置，进一步包括：

用于从智能卡通过消费者设备发送已验证的授权请求消息到智能卡发行方的计算机可读程序代码装置；

用于使用消费者设备直接从智能卡发行方获取交易的已验证授权的计算机可读程序代码装置；

用于核实授权验证的计算机可读程序代码装置；以及

用于将授权包含在对应于该交易并由消费者设备发送到零售商的支付消息中的计算机可读程序代码装置。

2.根据权利要求1的计算机程序产品，其中用于初始化的计算机可读程序代码装置进一步包括：

用于从消费者设备发送交易请求到零售商的计算机可读程序代码装置；

用于在零售商处接收交易请求的计算机可读程序代码装置；

用于从零售商发送交易用支付初始化消息到消费者设备的计算机可读程序代码装置，其中支付初始化消息是对用于接收交易请求的计算机可读程序代码装置的响应，包括交易数量、时戳、随机场合和智能卡需要的数据；以及

用于接收由消费者设备发送的支付初始化消息的计算机可读程序代码装置。

3.根据权利要求2的计算机可读程序产品，其中用于发送已验证的授权请求消息的计算机可读程序代码装置进一步包括：

用于从消费者设备发送消息到智能卡的计算机可读程序代码装置，这使得智能卡能使用在线授权；

用于消费者设备从智能卡接收授权请求(AR)的计算机可读程序代码装置，其中AR包括智能卡的卡帐号、交易数量、交易日期和智能卡序列号；

用于通过将接收到的支付初始化消息加入到AR来创建已验证的授权请求消息的计算机可读程序代码装置；以及

用于直接从消费者设备发送已验证的授权请求消息到发行方的计算机可读程序代码装置，其中用于获取已验证授权的计算机可读程序代码装置进一步包括：

用于在发行方接收发送的已验证授权请求消息的计算机可读程序代码装置；

在发行方可用的计算机可读程序代码装置，用于响应接收发送的已验证授权请求消息的计算机可读程序代码装置，以生成交易用授权标记，进一步包括：

用于核实卡帐号的计算机可读程序代码装置；

用于核实对应于智能卡的帐户满足交易数量的能力的计算机可读程序代码装置；以及

如果用于核实卡帐号和满足交易数量的能力的计算机可读程序代码装置得到肯定的结果，用于授权交易的计算机可读程序代码装置；

用于发行方生成发行方验证数据和可选发行方命令的计算机可读程序代码装置；

用于从发行方将授权标记与发行方验证数据、可选发行方命令一起发送给消费者设备的计算机可读程序代码装置；以及

用于消费者设备接收发送的授权标记、发行方验证数据和可选发行方命令的计算机可读程序代码装置。

4.根据权利要求3的计算机程序产品，其中用于包含授权的计算机可读程序代码装置进一步包括：

用于将接收到的发行方验证数据和可选发行方命令从消费者设备传递给智能卡的计算机可读程序代码装置；

用于消费者设备从卡中接收交易证明(TC)的计算机可读程序代码装置；

用于将TC和接收到的授权标记作为支付消息从消费者设备传递到零售商的计算机可读程序代码装置；

用于在零售商处接收支付消息的计算机可读程序代码装置；

用于将记录请求与支付消息一起从零售商发送到获款银行的计算机可读程序代码装置，作为对用于接收支付消息的计算机可读程序代码装置的响应；

用于在获款银行接收记录请求和支付消息的计算机可读程序代码装置；以及

用于向交易使用的智能卡所对应的帐户收费的计算机可读程序代码装置，是对用于接收记录请求和支付消息的计算机可读程序代码装置的响应。

5.根据权利要求4的计算机程序产品，其中支付消息进一步包括授权标记。

6.根据权利要求4的计算机程序产品，其中支付消息进一步包括一个或多个对可选发行方命令的响应。

7.根据权利要求2的计算机程序产品，其中支付初始化消息是钱包初始化消息，进一步包括：

用于消费者设备在接收发送的支付初始化消息之后激活钱包程序的计算机可读程序代码装置；

用于消费者使用交易用消费者设备登录钱包程序的计算机可读程序代码装置；以及

用于发行银行验证消费者的计算机可读程序代码装置。

8.根据权利要求3的计算机程序产品，其中零售商使用零售商的数字证明对支付初始化消息进行数字签名，发行银行使用发行银行的数字证明对授权标记进行数字签名，产品进一步包括：

用于使用零售商的数字证明来核实已数字签名的支付初始化消息的计算机可读程序代码装置；以及

用于使用发行银行的数字证明核实已数字签名的授权标记的计算机可读程序代码装置。

9.根据权利要求4的计算机程序产品，进一步包括：

用于智能卡使用智能卡数字证明对TC进行数字签名的计算机可读程序代码装置；以及

用于核实使用智能卡数字证明数字签名的TC的计算机可读程序代码装置。

10.根据权利要求3的计算机程序产品，进一步包括：

用于消费者设备从发行方请求发行方公开密钥的计算机可读程序代码装置；

用于使用发行方公开密钥对要从发行方传输到消费者设备的个人识别号(PIN)进行加密的计算机可读程序代码装置；以及

用于发行方使用对应于发行方公开密钥的发行方私有密钥解密PIN的计算机可读程序代码装置。

11.根据权利要求3的计算机程序产品，进一步包括

用于使用在消费者设备中静态和永久性提供的发行方公开密钥对要从消费者设备传输到发行方的个人识别号(PIN)进行加密的计算机可读程序代码装置；以及

12.一个允许通过消费者设备使用智能卡在网络环境中进行可信交易的系统，包括：

用于使用从消费者设备直接访问的智能卡初始化与零售商进行的交易的装置；

用于消费者设备直接从智能卡发行方获取已验证的交易用授权的装置，进一步包括：

用于使智能卡使用在线授权的装置；

用于消费者设备从智能卡接收授权请求(AR)的装置，其中AR包括智能卡的卡帐号、交易数量、交易日期和智能卡序列号；

用于通过将接收到的支付初始化消息与AR相结合来生成已验证授权请求消息的装置；

用于直接从消费者设备将已验证授权请求消息发送到发行方的装置；

用于在发行方接收发送的已验证授权请求消息的装置；

在发行方可操作的，用于生成交易用授权标记的装置，是对接收发送的已验证授权请求消息的装置的响应；

用于从发行方将授权标记发送到消费者设备的装置；以及

用于消费者设备接收发送的授权标记的装置；以及用于将已验证授权包含在响应交易并从消费者设备发送到零售商的支付消息中。

13.根据权利要求12的系统，其中用于初始化的装置进一步包括：

用于从消费者设备将交易请求发送到零售商的装置；

用于在零售商处接收交易请求的装置；

用于从零售商将交易用支付初始化消息发送到消费者设备的装置，其中支付初始化消息包括交易数量、时戳、随机标记和智能卡所需的数据；以及

用于消费者设备接收发送的支付初始化消息的装置。

14.根据权利要求13的系统，其中：

用于使智能卡使用在线授权的装置，进一步包括从消费者设备发送消息到请求在线授权的智能卡的装置；

用于生成交易用授权标记的装置，进一步包括：

用于核实卡帐号的装置；

用于核实智能卡对应帐户满足支付数量的能力的装置；以及

如果用于核实卡帐号和满足交易数量的能力的装置有肯定的结果，用于授权交易的装置；

以及在系统中用于获取已验证授权的装置，进一步包括：

用于发行方生成发行方验证数据和可选发行方命令的装置；

用于将发行方验证数据、可选发行方命令与授权标记一起发送的装置；以及

用于消费者设备将发行方验证数据、可选发行方命令与授权标记一起发送的装置。

15.根据权利要求14的系统，其中用于包含已验证授权的装置进一步包括：

用于从消费者设备将接收到的已验证数据和可选发行方命令传递给智能卡的装置；

用于消费者设备从卡里接收交易证明(TC)的装置；

用于将TC和接收到的授权标记作为支付消息从消费者设备转送到零售商的装置；

用于在零售商处接收支付消息的装置；

用于将记录请求与支付消息一起从零售商发送到获款银行的装置，作为对接收支付消息的装置的响应；

用于在获款银行接收记录请求和支付消息的装置；以及

用于向交易用智能卡对应帐户收费的装置，是对接收记录请求和支付消息的装置的响应。

16.根据权利要求15的系统，其中支付消息进一步包括授权标记。

17.根据权利要求15的系统，其中支付消息进一步包括一个或多个对可选发行方命令的响应。

18，根据权利要求13的系统，其中支付初始化消息是钱包初始化消息，进一步包括：

用于消费者设备在接收发送的支付初始化消息后激活钱包程序的装置；

用于消费者使用交易用消费者设备登录钱包程序的装置；以及

用于发行银行验证消费者的装置。

19.根据权利要求14的系统，其中零售商使用零售商数字证明对支付初始化消息进行数字签名，发行银行使用发行银行数字证明对授权标记进行数字签名，进一步包括：

用于使用零售商数字证明核实数字签名的支付初始化消息的装置；以及

用于使用发行银行数字证明核实数字签名的授权标记的装置。

20.根据权利要求15的系统，进一步包括：

用于智能卡使用智能卡数字证明对TC进行数字签名的装置；以及

用于使用智能卡数字证明核实数字签名的TC的装置。

21.根据权利要求14的系统，进一步包括：

用于消费者设备从发行方请求发行公开密钥的装置；

用于使用发行方公开密钥对要从消费者设备传输到发行方的个人识别号(PIN)进行加密的装置；以及

用于发行方使用发行方公开密钥对应的发行方私有密钥解密PIN的装置。

22.根据权利要求14的系统，进一步包括：

用于使用在消费者设备中静态和永久性提供的发行方公开密钥对要从消费者设备传输到发行方的个人识别号(PIN)进行加密的装置；以及

23.一种允许通过消费者设备使用智能卡进行可信交易的方法，包括下列步骤：

使用可直接从消费者设备访问的智能卡初始化与零售商的交易；

消费者设备直接从智能卡发行方获取已验证的交易用授权；以及

将已验证授权包含在响应交易并从消费者设备发送到零售商的支付消息中。

24.根据权利要求23的方法，其中初始化步骤进一步包括步骤：

将交易请求从消费者设备发送到零售商；

在零售商处接收交易请求；

将响应接收交易请求步骤的、用于交易的支付初始化消息从零售商发送给消费者设备，其中支付初始化消息包括交易数量、时戳、随机标记和智能卡所需的数据；以及

消费者设备接收发送的支付初始化消息。

25.根据权利要求24的方法，其中获取已验证授权的步骤进一步包括：

将消息从消费者设备发送给智能卡，使智能卡使用在线授权；

消费者设备从智能卡接收授权请求(AR)，其中AR包括智能卡的卡帐号、交易数量、交易日期和智能卡序列号；

通过将接收到的支付初始化消息与AR相结合来生成已验证授权请求消息；

将已验证授权请求消息直接从消费者设备发送给发行方；

在发行方接收发送的已验证授权请求消息；

在发行方生成交易用授权标记，作为对接收发送的已验证授权请求消息步骤的响应，进一步包括步骤：

核实卡帐号；

核实智能卡对应帐户满足交易数量的能力；以及

如果核实卡帐号和满足交易数量的能力的步骤给出肯定的结

果，授权交易；

发行方生成发行方验证数据和可选发行方命令；

将授权标记与发行方验证数据、可选发行方命令一起从发行方发送给消费者设备；以及

消费者设备接收发送的授权标记、发行方验证数据和可选发行方命令。

26.根据权利要求25的方法，其中包含已验证授权的步骤进一步包括步骤：

将接收到的发行方验证数据和可选发行方命令从消费者设备传递给智能卡；

消费者设备从卡中接收交易证明(TC)；

将TC和接收到的授权标记作为支付消息从消费者设备转送给零售商；

在零售商处接收支付消息；

将记录请求与支付消息一起从零售商发送到获款银行，是对接收支付消息步骤的响应；

在获款银行接收记录请求和支付消息；以及

向进行交易的智能卡所对应的帐户收费，是对接收记录请求和支付消息步骤的响应。

27.根据权利要求26的方法，其中支付消息还包括授权标记。

28.根据权利要求26的方法，其中支付消息进一步包括一个或多个对可选发行方命令的响应。

29.根据权利要求26的方法，其中支付初始化消息是钱包初始化消息，进一步包括步骤：

消费者设备在接收发送的支付初始化消息之后激活钱包程序；

消费者使用交易用消费者设备登录钱包程序；以及

发行银行验证消费者。

30.根据权利要求25的方法，其中零售商使用零售商数字证明对支付初始化消息进行数字签名，发行银行使用发行银行数字证明对授权标记进行数字签名，进一步包括步骤：

使用零售商数字证明核实数字签名的支付初始化消息；以及

使用发行银行数字证明核实数字签名的授权标记。

31.根据权利要求26的方法，进一步包括步骤：

智能卡使用智能卡数字证明对TC进行数字签名；以及

使用智能卡数字证明核实数字签名的TC。

32.根据权利要求25的方法，进一步包括步骤：

消费者设备从发行方请求发行方公开密钥；

使用发行方公开密钥对要从消费者设备传输给发行方的个人识别号(PIN)进行加密；以及

发行方使用发行方公开密钥对应的发行方私有密钥解密PIN。

33.根据权利要求25的方法，进一步包括步骤：

使用在消费者设备中静态和永久性提供的发行方公开密钥对要中消费者设备传输到发行方的个人识别号(PIN)进行加密的计算机可读程序代码装置；以及

发行方使用对应于发行方公开密钥的发行方私有密钥解密PIN。

34.根据权利要求23的方法，进一步包括选择用于交易的支付商标的步骤，进一步包括步骤：

零售商发送一个或多个描述零售商接受的商标的信息数组；

消费者设备接收一个或多个信息数组；以及

消费者设备将该数组与一个或多个由消费者设备所支持的商标进行比较以找到匹配的商标。

35.用于在公用网络环境中用不可信计算设备使用智能卡进行可信交易的方法，包括步骤：

为不可信计算设备提供智能卡读卡机的功能；

计算设备的用户初始化与零售商的交易；

使用智能卡读卡机功能读取选中的智能卡，其中选中的智能卡用于借记卡或信用卡交易；

从零售商接收零售商信息作为对初始化的响应，其中零售商信息包括零售商标识符和零售商数字签名；

使计算设备将零售商信息与关于智能卡和交易的授权信息一起直接发送给智能卡的发行方，而不是首先将授权信息发送给零售商，其中授权信息包括交易数量、信用卡或借记卡的帐号或对帐号的引用、交易日期和智能卡序列号；

发行方核实零售商数字签名；

发行方决定是否使用授权信息来授权交易；

如果决定是肯定的，那么从发行方将授权标记返回给计算设备，其中授权标记包括授权信息和零售商信息，其中授权信息是由发行方数字签名的；

将授权标记从计算设备转送到智能卡；

如果智能卡接受授权标记，那么它生成交易完成标志；

通过将交易完成标志和授权标记转送给零售商，因此为交易提供一个预授权；

零售商接收交易完成标志和授权标记；以及

如果成功核实了授权标记中的发行方数字签名，那么零售商接受交易。

36.根据权利要求35的方法，进一步包括步骤：

零售商将记录请求发送给获款方，提示获款方去收取授权给交易的资金，其中记录请求包括(1)授权标记和(2)交易完成标志中的一个或两个；

获款方通知发行方转帐到零售商的帐户，这是对记录请求的响应；以及

获款方转帐到零售商帐户，该转帐必须是已经由授权标记预先授权的。