CN104603809B - 在移动设备上使用虚拟卡促进交易的***和方法 - Google Patents

Abstract

提供了***和方法，其用于使用近场通信(NFC)可用的设备和支付口服务器促进使用基于云的钱包的无接触式支付，所述基于云的钱包包含支付凭证(例如维萨卡、万事达卡、美国运通卡)。用户可使用他们已有的支付卡，这里称为资金卡，进行无接触式支付。产生第二支付卡，这里称为虚拟卡。虚拟卡与资金卡在支付口服务器相关联。虚拟卡在NFC可用的移动设备上使用。当启动支付时，虚拟卡数据通过NFC***从销售点终端机发送。该信息被发送至支付口服务器，其搜索资金卡以进行支付。使用资金卡而不是虚拟卡转移金钱以进行支付。

Description

在移动设备上使用虚拟卡促进交易的***和方法

相关申请的交叉引用

本申请要求下述申请的优先权：2012年4月16日提交的、名称为“使用移动设备进行支付的***和方法(systems and methods for making a payment using a mobiledevice)”的美国临时申请61/624,947；2012年7月18日提交的、名称为“在移动设备上使用虚拟卡促进交易的***和方法(systems and methods for facilitating a transactionusing a virtual card on a mobile device)”的美国临时申请61/673,096；和2012年10月12日提交的、名称为“在移动设备上使用虚拟卡促进两方价值转移的***和方法(systems and methods for facilitating a party-to-party value transfer using avirtual card on a mobile device)”的美国临时申请61/713,302。这些申请的全部内容通过引用并入本文。

技术领域

下述一般地涉及在商业场所在移动设备上使用虚拟卡促进支付交易。

背景技术

移动设备可用于促进支付交易，例如在商店的商品或服务交易中。移动设备可装备有近场通信(NFC)***，其用于将买方的支付证明例如***信息传递至也装备有NFC兼容***的销售点终端机以完成支付交易。

发明内容

根据本发明的一方面，提供了一种计算机执行的方法，包括：注册资金卡，其包括储存资金***以及储存个人识别号，该个人识别号与访问所述资金卡相关联；从移动设备接收表示期望使用注册的资金卡进行支付的消息；计算虚拟卡的数据，其中所述虚拟卡的数据包括不同于所述资金***的虚拟***，所述虚拟卡的数据是在支付口处计算的；与所述资金***相关联储存所述虚拟卡的数据；发送与所述虚拟卡的数据相关的信息至所述移动设备，所述发送包括将所述信息而不是所述个人识别号发送至所述移动设备；从商场或商场收单方接收第一支付授权请求，所述第一支付授权请求包括请求的支付量和由所述移动设备基于所述与所述虚拟卡的数据相关的信息计算出并从所述移动设备提供的虚拟卡的数据；基于所述虚拟卡的数据，搜索所述资金***；发送第二支付授权请求至资金卡发行方，所述第二支付授权请求包括所述资金***和所述请求的支付量；从所述资金卡发行方接收支付授权响应；和发送所述支付授权响应至所述商场或所述商场收单方；将与所述第一支付授权请求一起收到的所述虚拟卡的数据与在所述支付口处计算的所述虚拟卡的数据比较；和基于所述比较，发送通知至所述移动设备，所述通知指示所述支付授权是被接受还是被拒绝。

附图说明

现在仅通过举例，参考附图描述实施方式，在附图中：

图1是支付***的一个示例实施方式的示意图。

图2是资金***(funding credit card)一面的一个示例实施方式的示意图。

图3是图2中资金***另一面的示意图。

图4是支付***的一个示例实施方式的示意图，显示了当使用虚拟卡促进支付时数据的流动。

图5是使用虚拟卡进行支付交易以促进支付的一个示例实施方式中所涉及实体的另一示意视图。

图6是移动设备的一个示例实施方式的框图。

图7是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于在支付交易中根据用户的意愿产生和使用虚拟卡，所述指令至少通过移动设备、销售点终端机和支付口服务器执行。

图8是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于使用虚拟卡促进支付交易，所述指令显示了至少在商场和支付口服务器之间的互动。

图9a是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于通过支付口服务器计算虚拟卡细节，所述指令作为图7交易过程的一部分执行。

图9b是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于通过支付口服务器批准虚拟卡细节，所述指令作为图8交易过程的一部分执行。

图10是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于移动设备和支付口服务器之间的注册过程。

图11是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于计算虚拟卡细节——包括主账号和酌定数据，这使用图10注册过程中交换的数据进行。

图12是计算机可执行或处理器执行的指令的一个示例实施方式是流程图，所述指令用于确认图11的酌定数据。

图13是示意图，显示用于使用虚拟卡促进电子商务交易的***的示例组件。

图14是用于使用虚拟卡进行电子商务交易的图形化用户界面(GUI)的一个示例实施方式的截屏。

图15是用于使用虚拟卡进行电子商务交易的GUI的另一示例实施方式的截屏。

图16是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于使用虚拟卡进行电子商务交易，所述指令至少通过移动设备、销售点终端机和支付口服务器进行。

图17是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于使用虚拟卡进行电子商务交易，所述指令显示了至少在商场和支付口服务器之间的互动。

图18是显示两方价值转移(party-to-party value transfer)的流程图。

图19是示意图，显示用于使用转移ID促进两方价值转移的***的示例组件。

图20是一个示例实施方式，图解发送者移动设备和接收者移动设备，所述发送者移动设备显示用于选择资金卡的图形化用户界面(GUI)。

图21是一个示例实施方式，图解在一起“点击(tapped)”以促进两方价值转移之前图20的发送者移动设备和接收者移动设备。

图22是一个示例实施方式，图解在图21中点击之后的发送者移动设备和接收者移动设备，两个设备都显示指示两方价值转移已经完成的GUI。

图23是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于通过支付口服务器和移动设备计算转移ID，以便转移ID用于促进价值转移。

图24是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于使转移ID生效并发行预付虚拟卡给接收者，从而完成两方价值转移，所述指令作为图23中过程的继续而执行。

图25是示意图，显示用于使用虚拟卡促进两方价值转移的***的示例组件。

图26是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于通过支付口服务器和移动设备计算虚拟卡细节。

图27是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于批准虚拟卡细节和完成两方价值转移，所述指令作为图26中过程的继续而执行。

图28是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于发送者移动设备和支付口服务器之间的注册过程。

图29是计算机可执行或处理器执行的指令的一个示例实施方式的流程图，所述指令用于计算虚拟卡细节——包括主账号和酌定数据，这使用图28注册过程中交换的数据进行。

图30是用于确认图29的酌定数据的计算机可执行或处理器执行的指令的一个示例实施方式的流程图。

具体实施方式

将理解，为了图解的简化和清楚，在认为合适的地方，参看数字在图中可重复，以指示相应或类似的元件。此外，提出了许多具体细节，以提供对本文所述示例实施方式的充分理解。然而，本领域普通技术人员将理解，本文所述示例实施方式可以在没有这些具体细节的情况下实践。在其他情况，众所周知的方法、过程和组件没有进行详细描述，以便不会使本文所述的示例实施方式不清楚。而且，说明书不被认为限制本文所述示例实施方式的范围。

图1显示持卡者101、商场102、商场收单方103、支付网络109和卡发行方104之间的典型当面支付流程的一个示例实施方式。商场102、商场收单方103、支付网络109和卡发行方均与包括处理器和存储器的计算设备相关联。作为背景，这种支付流程也称为标准4方模式或标准4方方案。卡发行方104通常是与支付网络相关联的银行。它促进持卡者使用支付卡为商品或服务付费，这基于持卡者承诺为该购买付还卡发行方。支付网络的非限制性实例包括维萨卡(Visa)、万事达卡(MasterCard)、美国运通卡(American Express)和大来卡(Diners Club)/发现卡(Discover)。卡发行方104发行与支付网络109相关联的支付卡给持卡者101(方框105)。应理解，对***的所有提及也会适用于借记卡、预付卡或其他用于在商业场所促进支付的支付凭证。术语“资金卡(funding card)”在本文用于指借记卡、***、预付卡等。

为了进行购买或支付，持卡者101(例如人)提供资金卡信息给商场102(方框106)。例如，资金卡可用磁条卡读取器设备“扫过”，或者资金***可被读取至商场102。商场102(例如计算设备)将支付授权——包括资金卡细节发送至商场收单方103(方框107)。收单方103是从商场收集支付授权请求并代表商场利用支付网络促进支付交易的一个组织。

当收单方103获得资金卡支付授权请求时，收单方将支付交易交给(方框108)支付网络109。

当支付网络109收到资金卡支付授权请求时，支付网络将支付交易送至(方框110)卡发行方104以获得支付授权。

当卡发行方104收到支付交易时，它检查交易明细的有效性。这包括检查***、有效期、资金卡限制等。卡发行方104通过支付网络109利用支付授权码响应商场收单方103(批准或拒绝的响应、交易识别号等)。商场收单方103将响应传递至商场102。然后商场102与持卡者共享支付授权结果。

应认识到，这种建立的计算机支付***是完善的并且被许多用户和大公司采用。然而，应认识到，这种计算机支付***不提供在移动设备上进行支付的数据处理手段。这种计算机支付***也要求资金卡细节经过商场102和商场收单方103，这可能暴露或披露敏感的财务数据。这种计算机支付***产生的该安全风险是不期望的。

作为背景，***201的示例实施方式显示在图2和图3中。根据图2，***的一面显示徽标202或识别卡发行方的标志。通常，卡发行方是银行。徽标203标志也显示来识别支付网络。卡201也显示信用***204。信用***204有时称为主账号(PAN)。信用***204的长度和格式根据卡发行方和支付网络而变化。一般地，信用***204的第一位确定支付网络。信用***204的最后位是校验位。校验位是用于错误检测的冗余校验形式。中间数字可以表示银行号(例如关联的卡发行方)和(例如银行的)账号。

在图2所示的实例中，根据方框207，第一位“4”确定Visa是支付网络。第二至第六位是发行银行识别号。第七至第十五位是账号。第十六位是校验位。

***201也包括***有效的日期范围205。日期范围包括***有效期。也显示持卡者姓名206。

在图3中，在***201的另一面，有磁条301、持卡者姓名的签名302和静态安全码303。静态安全码印在***201上。

磁条301，有时也称为磁条(magstripe)，通常由在塑料类膜中的细小铁类磁性颗粒构成。条301具有在其上写入的信息。

经常地，在条301上编码有关于数据的二或三个磁轨。在一个示例实施方式中，每个磁轨大约十分之一英寸宽。银行采用的ISO/IEC标准7811规定，第一磁轨是每英寸210字节(bpi)并且容纳79个6字节以上的奇偶校验位只读字符；第二磁轨是75bpi并且容纳40个4字节以上的奇偶校验位字符；以及第三磁轨是210bpi并且容纳107个4字节以上的奇偶校验位字符。可应用其他数据格式。

在一个示例实施方式中，银行业开发的第二磁轨的格式如下(最多40个字符)：·起始符-一个字符(通常是‘；’)

·主账号-最多19位

·分隔符-一个字符(通常是‘＝’)

·有效期-四位，形式为最后两位是年份，两位代表月份(例如YYMM)

·服务代码-三位。第一位规定交换法则，第二位规定授权处理，第三位规定服务范围

·酌定数据-可用空间的余下部分，用于填充第二磁轨的长度(例如10位，如果PAN是19位长)

·末字符-一个字符(通常是‘？’)

·纵向冗余检验(LRC)-一个字符

以上数据在本文一般称为第二磁轨数据。

应认识到，除了典型的塑料卡形式因素外，如图2和图3所示，存在数量不断增长的可用于支付的其他形式因素。非限制性实例包括迷你卡、离岸价(fob)、移动设备等。也应理解，除了***外，其他类型的资金卡也包括类似的信息(例如PAN、有效期、第二磁轨数据等)。

卡数据本身储存在资金卡上并与支付端共享的方式有许多变型，例如储存卡数据在磁条上并且使用磁卡读取器读取数据，或者使用芯片技术和使用芯片-读取器兼容读取器以与卡互动来储存卡数据。例如，虽然在图2和图3中未显示，但***可包括能进行计算的集成电路或逻辑芯片。芯片类卡技术的各种实例包括无接触式磁条仿真、EMV接触式、EMV无接触式等。EMV代表欧陆卡(Europay)、万事达卡(MasterCard)和维萨卡(VISA)，一种集成电路卡(IC卡或"芯片卡")和IC卡读取器的交互操作的全球标准。除了通过卡的接触界面促进信息交换外，还可以使用可用卡的无接触能力交换信息。这种无接触式卡有时称为PayPass、payWave和美国运通(ExpressPay)。

应认识到，无接触式支付特别适合于移动设备。例如，一些移动设备具有近场通信(NFC)***，其允许在相对短的距离无线传递数据，这采用ISO/IEC18092标准或其他兼容标准。NFC可用的移动设备可与另一无接触式可用的设备通过将它们接触在一起或者保持它们紧密接近建立无线通信。术语“移动设备”和“移动电话”在本文可交换使用。

NFC可用的移动设备可装备在移动设备内运行的“软件式支付卡”(例如软件执行的无接触式支付卡)应用软件。软件式支付卡利用设备的兼容性无接触式通信能力以与无接触式可用的POS端交互，促进支付交易。

在许多情况下，软件式支付卡存放在安全元件上以保护敏感支付数据，例如用于产生完成典型的无接触式支付交易所需的动态数据的敏感的支付数据。应认识到安全元件的存放能力有限。它们通常以嵌入式芯片的形式使用，例如在通用集成电路卡(UICC)中或者在客户识别模块(SIM)卡中。

部分地为了保持在安全元件中运行的各种应用软件的安全性，安全元件通常由将安全元件分配给移动设备的移动电话运营商管理。该受管理的服务的一部分包括将应该软件直接发送至安全元件，或者允许第三方组织在特定的安全元件中布置其应用软件。该受管理的服务通常使用行业称为可信服务管理(TSM)的进行发送。

在安全元件中存放和运行的所有应用软件例如个人“软件式支付卡”需要其自身的空间。支付卡由卡发行方发行给消费者。在移动电话上布置软件式支付卡需要移动电话运营商和卡发行方之间高水平的合作，其中移动电话运营商要允许发行方访问个人安全元件，一次一人。只有具有基本构造和移动电话运营商协定的来自资金卡发行方的卡能够用在移动电话上以进行接触式支付。这对于卡发行方和对于持卡者都是有限制的。

在美国，例如有成千的发行银行和数十移动电话运营商。移动电话运营商部分地利用TSM发行和管理支付证书给移动电话。TSM使移动电话运营商(也称为服务提供者)或其他控制移动电话上的安全元件的实体能够通过确保访问可实现移动的设备上的安全元件来远程分配和管理在安全元件中运行的安全应用软件。安全应用软件的实例是软件式支付卡。发行银行也通过一种服务(在一种示例实施方式中称为ISIS)与移动电话运营商交互，以管理发行给NFC有效设备的支付证书。作为非限制性实例，在加拿大，罗杰斯通信公司(Rogers Communication)是与发行银行加拿大皇家商业银行(Canadian Imperial Bankof Commerce(CIBC))处于伙伴关系的移动运营商，其将软件式支付卡在罗杰斯公司网络上发行给CIBC持卡者的电话。建立***和方法以在发行银行、移动电话运营商和移动设备之间管理安全发行和软件式支付卡管理是成本高的和复杂的。它涉及各方之间预先安排的协定以及软件和计算***的一些定制以满足所有参与实体的需要。这可能使得小尺寸卡发行方采用NFC技术促进支付变得困难。这也意味着，发行银行可能需要与需要支持的各种移动电话操作者进行许多点对点的连接，这要求进一步的软件容量以及支持和组织不同移动操作者之间数据通信的软件。本文所述的***和方法力图解决至少一个这些问题。

也应认识到，根据用户的意愿，将其移动设备与其资金卡相关联以用于无接触式支付的过程非常依赖于预先安排的移动电话运营商和卡发行方之间的关系。因此，在决定他们的现有资金卡是否可与其移动电话相关联以用于无接触式支付时用户的选择有限或没有选择。例如，用户具有来自资金卡发行方A的资金。该用户也具有来自移动电话运营商B的实现NFC的移动电话。但是，移动电话运营商B仅具有预先安排的协定和基本构架以促进与资金卡发行方B的无接触式支付。因此即使用户需要使用其移动电话进行无接触式支付，用户也不能，因为在移动电话运营商B和资金卡发行方A之间没有预先安排的协定和计算机网络基础构架来将软件式支付卡发行到用户的电话中。计算机网络基础构架的这种局限性限制了用户用其移动设备进行NFC型支付的能力。

在使用NFC可用的移动设备进行支付的典型示例实施方式中，用户首先请求其发行方下载资金卡到其移动设备上。在完成该过程时，软件式资金卡已经被安全地发送并安装在用户移动设备的安全元件上。用户现在可在移动设备上使用资金卡以在配备以接受这种类型支付交易的商业场所促进无接触式支付交易。一旦用户试图用其移动设备在商场支付，资金卡发行服务器以与其他支付交易类似的方式发送并确认支付细节。

当无接触式资金卡凭证用于促进支付交易时，交易最经常包括来自卡的动态数据以安全地使支付凭证生效。该动态数据在每次使用凭证时改变价值。如果资金卡发行服务器上接收的动态数据与卡服务器计算的预期值匹配，则认为支付凭证的确认是成功的并且支付授权可继续。可理解，存在移动设备和资金卡发行服务器能够计算用于确认支付凭证的动态数据的多种方式。

在***的一个示例实施方式中，动态数据是旋转的卡认证值(CVV，有时也称为动态CVV或dCVV)。该旋转CVV可基于卡内的集成电路提供的变化信息计算。在另一示例实施方式中，动态数据是动态EMV数据，其使用来自资金卡的随机数据或者来自商场销售点终端机的随机数据或者二者计算。动态数据的共同执行方式采用卡上的应用交易计数器(ATC)，以便每次交易产生不同的数据流。这在ATC对于进行的每次交易递增“1”时得以实现。当用户点击、接触或放置其移动设备靠近无接触式可用的销售点(POS)终端时，资金卡数据(***、动态数据、有效期等)——后面称为卡第二磁轨数据——从移动设备发送至POS终端。然后该信息去往资金卡发行服务器，进行认证。资金卡发行方将进行多种检查以确认交易，包括将移动设备的动态数据与服务器产生的值比较。如果动态数据匹配并且资金卡发行方进行的所有其他检查和控制都成功，资金卡发行方将以正支付授权应答响应。

也应认识到，特定于给定资金卡的卡应用软件可安装在移动设备上并用于与POS终端交互，如上所述。也应认识到，卡应用软件一般安装在移动设备的安全元件上。一般地，每一资金卡具有其自身的相应的卡应用软件，位于移动设备的安全元件上。可理解为，由于每个卡应用软件占据安全元件上的储存空间并且安全元件一般具有非常有限的储存空间，因此由于储存空间不足，在一些情况下在安全元件上具有多个卡应用软件是不可能的。作为背景，安全元件可具有原本的被编程以进行各种任务和活动的操作***，包括例如仿真资金卡磁条数据的卡应用软件或仿真EMV无接触式支付中使用的数据的卡应用软件。也作为背景，并且举例而言，典型的安全元件具有256kB的内存，每个卡应用软件可用40-80kB的内存。因此，可理解为，将多个资金卡(和其每一个卡应用软件)与进行NFC支付的移动设备相关联可能是有限制的。

因此，期望减少安全元件上卡应用软件需要的存储空间的量，以便不限制用户可下载到安全元件中的软件式支付卡的数量。同样，期望移动电话运营商减少安全元件上“卡应用软件”所使用数据的量，以便其他类型的应用软件能够下载到其上。也期望减少资金卡发行方发行和操作软件式支付卡到安全元件中招致的费用。作为背景，移动电话运营商通常向应用软件提供者例如资金卡发行方索要安全元件上使用的存储空间量的费用。也期望减少资金卡发行方为移动电话发行软件式支付卡所需的基础构架的量。也期望减少资金卡发行方和移动电话运营商之间发行软件式支付卡到具体移动电话上所需的合作的量。也期望实现用户(例如持卡者)下载任何的以及他们想要的那么多的资金卡到其NFC可用的移动电话上，而与具有基础构架的资金卡发行方或者与特定的移动电话运营商的商业关系和协定无关。

本文所述的***和方法力图解决上述问题。

应理解，如在本文中描述的提出的***和方法的示例实施方式的不同特征可以以不同方式相互结合。换言之，虽然没有具体陈述，但关于移动支付***或方法的一个实施方式描述的特征可应用于移动支付***或方法的另一个实施方式。

一般地，本文所述的***和方法允许基于云的钱包支付口服务器与NFC可用的移动设备和应用软件同步以促进在接受无接触式支付的商店进行无接触式支付交易。资金卡发行方和移动电话运营商之间的预先安排的协定或额外的基础构架是不需要的。用户通过其移动设备选择资金卡进行无接触式支付。本文称为虚拟卡的第二卡与所有需要的卡数据(例如PAN、有效期、动态数据、酌定数据等)一起产生以完成支付交易。虚拟卡与资金卡在支付口服务器相关联。在一个示例实施方式中，虚拟卡和资金卡的关联限于一些时间段。

在一个示例实施方式中，计算虚拟卡数据组所需的数据被发送至移动设备，一般在每次用户想要进行支付时。例如，形成新虚拟卡用于每一和每次支付交易。在另一实例中，基于时间限制、基于某些事件或二者形成新虚拟卡，并且与一般可用数年的标准资金卡相比具有短得多的使用期。在虚拟卡可与资金卡进行数次交易的情况，计算新虚拟卡的数据不需要在每次用户进行支付时发生到移动设备。

当开始支付时，虚拟卡数据通过移动设备上NFC***发到无接触式可用的POS终端。通过支付网络，该信息从POS终端发生至商场***；从商场***到商场收单银行；以及从收单银行到基于云的钱包支付口服务器(也称为“支付口服务器”)。基于云的钱包支付口服务器充当虚拟卡发行方服务器并且验证虚拟卡。如果验证成功，则与虚拟卡相关的资金卡细节被搜索并通过支付网络发送到资金卡发行方服务器，以完成支付授权交易。资金卡发行方服务器验证资金卡并发送授权代码回到支付口服务器。支付口服务器发送相应的授权代码回到商场***。

当商场***启动结算请求时——一般地但不是必须地在每个工作日结束，可结算该支付。为了完成结算，商场***通过商场收单银行将在该期间收到的所有虚拟***和相应授权代码发送至虚拟卡发行方。虚拟卡发行方验证虚拟***和授权代码。对于所有匹配的记录，虚拟卡发行方搜索相关的资金***和授权代码并通过虚拟卡发行方收单银行将数据发至资金卡发行方以便结算。资金卡发行方验证资金***和授权代码，如果验证成功，将金钱通过标准方法送至支付交易发起者，在本情况是虚拟卡发行方。此时，虚拟卡发行方也利用标准方法将金钱送至商场收单银行。在一个示例实施方式中，虚拟卡发行方是支付口服务器，或者支付口服务器中的模块。

在一个示例实施方式中，本文所述的***和方法允许基于云的钱包(例如与资金卡相关联)与NFC可用的移动设备(例如与虚拟卡相关联)同步。在另一个示例实施方式中，本文所述的***和方法提供用于促进无接触式支付交易的主账号(PAN)和动态数据的实时循环。在另一个示例实施方式中，本文所述的***和方法使用虚拟的支付凭证完成实体的无接触式购买交易而不会公开用户的资金卡细节。

转向图4，提供了显示使用虚拟卡的支付数据流程的一个示例实施方式。卡发行方，也称为资金卡发行方104，发行标准的卡账户——如果是塑料卡的形式这最经常——至用户101(方框404)。标准卡是资金卡，并且用户成为持卡者。

虽然未显示，持卡者101向虚拟卡发行方401注册一个或多个资金卡和其移动设备。可理解为，任何资金卡可被注册，并且不受限制，或者不依赖于与资金卡发行方具有协定的移动电话运营商。换言之，即使资金卡和移动电话运营商不具有任何协定或者未连接计算机基础构架，根据提出的***和方法，用户的一个或多个资金卡和用户的移动设备可向虚拟卡发行方401注册。也可理解为，可与移动设备相关联注册许多资金卡。持卡者的移动设备包括可与虚拟卡发行方401交互的支付应用软件。

在一个注册的示例实施方式中，对于用户希望注册的资金卡，用户输入(例如键入)卡细节到移动设备中(例如卡细节包括资金卡印刷的姓名、资金卡上印刷的PAN、资金卡上印刷的有效期和资金卡上印刷的静态安全码)。移动设备将这种数据以及用户提供的PIN和移动设备ID发送至支付口服务器。对每一个资金卡，支付口服务器计算识别给定资金卡的资金卡识别符。支付口服务器存储与资金卡细节、移动设备ID和PIN相关联的资金卡识别符，并且它将资金卡识别符发送至移动设备储存。在一个示例实施方式中，资金卡识别符是不同于资金卡的PAN、有效期或静态安全码的值。例如，资金卡识别符是一个随机值，这样如果被对手拦截，不能够识别任何资金卡细节。在一个示例实施方式中，移动设备不存储任何资金卡细节而仅存储有限的资金卡细节(例如资金卡发行方姓名和PAN后4位)。移动设备储存资金卡识别符，它发送至支付口服务器以指示具体的资金卡。可理解，存在其他获得资金卡细节的方法(例如在键入数据的用户旁边)，其可与本文所述原理一起使用。

可理解，在移动设备上需要单个支付应用软件，其可管理多个资金卡。如果注册多个资金卡，每个关联的资金卡识别符存储在移动设备上，在所述单个支付应用软中。每个单个资金卡的细节存储在支付口服务器。以此方式，支付口服务器充当存储多个资金卡的细节的基于云的服务器。资金卡注册过程的另外细节在下面相对于图10描述。

继续图4，当已注册的持卡者101希望使用其移动设备进行无接触式支付时，用户选择资金卡。所选的资金卡被传送至虚拟卡发行方401，并且虚拟卡发行方401发行虚拟卡至持卡者101，更具体地，至在移动设备上运行的支付应用软件(方框405)。持卡者将其移动设备接触商场***，并且虚拟卡细节通过NFC可用的POS终端传送至商场106(方框406)。商场将虚拟卡细节发送至商场收单方103(方框407)。基于一些虚拟卡细节，商场收单方103通过支付网络将虚拟卡细节发送至虚拟卡发行方401(方框408)。虚拟卡发行方401利用虚拟卡细节确定相应的资金卡(方框409)。虚拟卡操作者402(例如现在充当“商场”的虚拟卡发行方)将相应的资金卡细节，包括原交易量，发送至其收单方403(方框410)。这与商场106将资金卡细节发送至商场收单方103的典型过程平行。虚拟卡收单方403通过标准支付授权的支付网络将资金卡细节发送至资金卡发行方104(方框411)。

然后资金卡发行方104可以批准或者不批准支付请求，并且通过支付网络以授权代码响应回至虚拟卡发行方的收单方，其又通知虚拟卡发行方。虚拟卡发行方通过支付网络使用商场***的相应授权代码通知商场收单方。

为了结算资金(未显示)，通过商场收单方，商场将启动或者商场收单方将代表商场启动结算请求至支付网络。支付网络将待结算的相应的虚拟卡交易送至虚拟卡发行方。当虚拟卡发行方收到交易时，虚拟卡发行方将发送相应资金卡交易的结算请求至其本身的收单方。结算请求通过支付网络被发送至合适的资金卡发行方。资金卡发行方收到交易的结算请求，并且将与所有匹配的交易相关的资金送至支付交易发起者，在本情况下是虚拟卡发行方。当虚拟卡发行方收到资金时，虚拟卡发行方将发送相应资金至商场。

在一个示例实施方式中，虚拟卡发行方401、虚拟卡操作者402和虚拟卡收单方403由同一实体代表，这里称为支付口服务器。支付口服务器本身可以包括一个或多个服务器。例如，每一个实体401、402、403可以是各个服务器，它们结合形成支付口服务器。

转向图5，显示了用于使用虚拟卡促进支付的***的一个示例实施方式组件。用户101具有一个或多个资金505，其预先注册到其云钱包中(过程未显示)。例如，用户具有多个资金卡。用户101也具有NFC可用的移动设备501，其包括支付应用软件。移动设备501被配置为通过NFC与商场POS终端设备502交互。商场POS终端设备502通过商场支付***与商场收单方103(例如服务器)进行数据通信。商场收单方和支付口服务器506与支付网络(例如维萨卡、万事达卡、发现卡等)通信，支付网络配置为发送与支付和交易相关的数据至相关方，包括支付口服务器506和资金卡发行方104(例如服务器)。商场POS终端设备502、商场收单方103、支付网络504、支付口服务器505和资金卡发行方104之间的通信可通过有线或无线通信网络或二者进行。

支付口服务器506也通过无线网络与移动设备501通信。例如，无线网络由移动电话运营商提供。

支付口服务器506的示例组件显示在方框507中。服务器506可包括虚拟卡发行方401、虚拟卡操作者402和虚拟卡收单方403。在用户101进行的注册过程中，支付口服务器506储存用户选择的个人识别号(PIN)、与用户的移动设备ID相关的资金卡数据(例如在数据库508中)。例如，用户PIN、资金卡1和资金卡2(以及其他资金卡)与移动设备501的移动设备ID相关联地储存。在数据库509中，给定资金卡、虚拟卡和授权代码之间的临时数据关联在适用时也储存。例如，虚拟卡1、资金卡1和授权代码1都彼此相关地储存。另一实例是虚拟卡2和资金卡2也相关但还没有为该卡对授权的授权代码。在一个示例实施方式中，由于用户还没有点击使用资金卡2(例如真正的虚拟卡2)的移动设备，或者因为商场支付授权被中断而使得支付口服务器从未收到授权代码，因此还没有授权的授权代码。

转向图6，显示移动设备501的示例组件。移动设备501包括主处理器601，其与许多组件交互，包括辅助输入/输出302、数据端口603、键盘604、扬声器605(喇叭)、麦克风606、GPS接收器607和摄像头608等等。移动设备501也包括NFC子***609、安全元件622和其他设备子***611，安全元件622可具有或可不具有与NFC子***609的直接连接。

移动设备501使用通信***613与无线网络612交互。存储器类型包括闪存614和随机存取存储器(RAM)615。移动设备的显示屏616可以说触摸屏型显示屏或另一类型的显示屏。

操作***617可用于管理和运行软件组件618。软件组件或应用软件包括网络浏览器或互联网浏览器619以及支付应用软件620。包括其他软件组件621。

安全元件622可用于储存信息，例如应用软件和数据元件，比如支付应用软件和移动识别符。在一个示例实施方式中，安全元件在客户识别模块(SIM)卡中。移动设备的非限制性实例包括手机、智能电话、PDA、平板电脑、上网本和便携式电脑。

将理解的是，本文举例的执行指令或操作的任何模块或组件可以包括或以其他方式有权访问计算机可读介质，例如存储介质、计算机存储介质或数据存储设备(可移除或/或不可移除的)，例如,比如磁盘、光盘或磁带。计算机存储介质可包括易失和非易失的、可移除和不可移除的介质，其以任何方法或技术执行，以存储信息，例如计算机或处理器可读指令、数据结构、程序模块或其他数据，除了短暂的传播信号本身。计算机存储介质的实例包括RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字多功能光盘(DVD)或其他光学存储器、磁盒、磁带、磁盘存储器或其他磁存储设备，或者任何其他可用于存储期望的信息并且应用软件、模块或二者可访问的介质。任何这种计算机存储介质可以是服务器103、504、104、506、401、402、403、移动设备501、POS终端502等的任一个的部分，或者可进出或连接它们。本文描述的任何应用软件或模块可使用计算机或处理器可读/可执行的指令或操作执行，该指令或操作可被这种计算机可读介质存储或以其他方式容纳。

转向图7，示例计算机可执行或处理器执行的指令被提供用于促进移动设备501和POS终端设备502之间的交易。

假定终端用户具有兼容的NFC-移动设备501。假定支付应用软件620已经安装在移动设备501上。假定终端用户已经注册该服务。

在商场将购买交易细节扑捉到其销售点***之后，NFC可用的POS终端设备502将消息显示给终端用户以“点击”进行支付(方框701)。例如，用户可点击其移动设备501或无接触式资金卡。本文所述实例涉及点击移动设备501。

终端用户101从POS终端设备502看见消息，并启动移动设备501上的支付应用软件620(方框702)。例如，用户选择移动设备501的主屏上的支付应用软件620的图标，从而启动支付应用软件620。支付应用软件620确定用户是否已经成功注册该服务(方框703)，如果是，则显示应用软件支持的动作的菜单(方框704)。如果用户未注册，则该菜单提供用户以注册该服务(例如注册一个或多个资金卡、提供PIN、链接移动设备识别符至注册记录)。

菜单上的图形化用户界面(GUI)能够接收用户的输入，以利用支付应用软件用虚拟卡启动支付(方框705)。其他的菜单项目的实例包括“增加资金卡”、“删除资金卡”等。

然后移动设备501显示用户已经预先注册的资金卡(方框706)。提供用户输入以选择资金卡之一(方框707)。在一个示例实施方式中，显示的资金卡信息在终端用户成功注册该服务并且已经注册至少一个资金卡后下载。当用户增加另外的资金卡到支付应用软件或者当删除资金卡时更新目录。对于每一注册的资金卡，在支付应用软件620上和支付口服务器数据库508上存储有相应的记录，包括用于与资金卡、资金卡识别符等相关联的支付网络的识别符。

支付应用软件620将移动设备识别符发送至支付口服务器506(方框708)。支付应用软件620也将交易类型(应用软件菜单中选择的动作，在本案中为“用虚拟卡支付”)和所需资金卡的识别符发送至支付口服务器506(方框709)。基于移动设备501收到的信息，支付口服务器506形成和计算关于虚拟卡的细节(方框710)。具体地，支付口服务器506计算虚拟PAN、虚拟卡有效期和所有或一些形成第二磁轨数据的数据元素。注意，第二磁轨数据包括PAN、服务代码、有效期、酌定数据和LRC等。在一个示例实施方式中，此时的支付口服务器506不计算性质上是动态的酌定数据(例如酌定数据是动态数据)。在一个示例实施方式中，虚拟卡有效期等于资金卡有效期，这样从商场和用户的角度看，虚拟卡等于资金卡。事实上，基于资金卡和虚拟卡之间某些相似性，商场和用户将不知道虚拟卡正在生成并使用，而是相信资金卡正在用于支付。虚拟卡细节可进一步包括内部有效期，其只有支付口服务器知道，并且具有从形成虚拟卡的那天起大约几天的时间范围。内部有效期不同于虚拟卡有效期，内部有效期的作用是给支付口提供附加指示以确定虚拟卡是否过期。支付口服务器506加密不包括内部有效期的虚拟卡数据，并且将加密的虚拟卡有效载荷(payload)发送至移动设备的支付应用软件620(方框711)。

作为一个替代的示例实施方式，不是支付口服务器506将虚拟卡PAN作为加密虚拟卡的有效载荷的一部分发送至移动设备，而是支付口服务器506发送密钥值(称为Kpan)，移动设备可使用它产生与支付口服务器506计算的相同的虚拟卡PAN。

在一个示例实施方式中，虚拟卡PAN后四位与资金卡PAN后四位相同。虚拟卡PAN后四位等于资金卡PAN，这样在PAN截断后看起来似乎是虚拟卡PAN等于资金卡PAN。换言之，用户不能发现虚拟卡正代替资金卡在使用。作为背景，PAN截断由支付行业实施，作为商场认证过程的一部分，以便接受卡支付。截断的PAN是指当打印在消费单据上时***被仅后四位的打印字代替，并且其他PAN位的剩余部分通常用星号代替。截断PAN的示例实施方式是************7777。这对于当丢弃时获得单据或者通过其他方式获得单据的任何人隐藏了***，同时还允许具有多个卡的持卡者识别使用了哪个卡并因此记录交易。

在一个示例实施方式中，虚拟卡PAN数位的第一部分是静态的，并且指向支付口服务器506。例如，前六位指支付口服务器506；商场收单方103和相关联的支付网络使用该信息将交易和支付细节发送至支付口服务器506。

在一个示例实施方式中，虚拟卡PAN是十九位长并且符合算法LUHN-10。该算法也称为“模数10”或“mod 10”算法，是用于确认各种识别号例如***的校验公式(checksumformula)。如上所述，前六位用于识别支付口服务器，后四位对于资金卡PAN后四位。其余位可用多种方式计算。在一个示例实施方式中，虚拟卡PAN其余位随机产生。在另一个示例实施方式中，其余位使用Kpan值计算；图11中描述了这方面的进一步细节。可用其他方法计算虚拟卡PAN。

移动设备501接收加密的虚拟卡有效载荷、解密该加密的通信并提取虚拟卡细节(例如虚拟卡PAN和其他卡细节)。

在另一个示例实施方式中，如果虚拟卡有效载荷包括Kpan(例如密钥值)而不是虚拟卡PAN，移动设备501使用Kpan计算虚拟卡PAN。

移动设备501上的支付应用软件620显示请求用户101输入其PIN的GUI(例如其PIN应该与用户注册服务时提供的PIN相同)(方框712)。应用软件620从用户101接收PIN(例如用户输入PIN)(方框713)。应用软件620使用PIN计算虚拟卡的酌定数据(方框714)。由于计算的酌定数据，第二磁轨数据组完整。将虚拟卡数据组(例如第二磁轨数据)传送至移动设备的安全元件622(方框715)。在一个示例实施方式中，通过NFC子***609发送的数据需要由安全元件622提供(方框716)。在另一个示例实施方式中，虽然未显示，移动设备501的操作***可直接将信息传递至NFC子***609而不用安全元件。虚拟卡数据组包括虚拟卡PAN、有效期、酌定数据以及第二磁轨数据组中所有其他因素，以完成标准的无接触式支付交易。移动设备的支付应用软件620显示消息给用户以“点击支付”(方框717)。

在该阶段，用户101触摸或将移动设备501紧密靠近POS终端设备502(方框718)。当移动设备501在POS终端设备502的通信服务中时，移动设备501发送虚拟卡数据至POS终端设备502，这使用移动设备的NFC子***609(方框719)，遵循这种无接触式支付交易的支付网络标准。数据的传递使用无线通信方法进行。在一个示例实施方式中，在终端收到它需要的所有卡数据后，POS终端设备502显示消息给用户101以“移除卡”(方框720)。用户将移动设备501从POS终端设备移走(方框721)。其他计算和过程可在完成移动设备参与交易过程的移动设备501中进行(方框722)。

虽然图7未显示，POS终端设备502将虚拟卡细节与其他交易数据(例如交易费用、商场ID等)一起发送至商场收单方。该信息最终发送至支付口服务器506，如由虚拟卡PAN字位的第一部分识别的。更多细节见图8。

在一个示例实施方式中，一个PIN可用于与移动设备相关联的所有资金卡。在另一个示例实施方式中，对于每一资金卡，注册过程可要求特定的PIN。换言之，如果用户选择不同的资金卡，用户需要输入不同PIN。

在一个优选的示例实施方式中，移动设备的支付应用软件620不验证PIN。而是，当验证虚拟卡数据组时PIN间接或隐含地由支付口服务器506验证。换言之，支付口服务器506使用在注册时储存的PIN计算虚拟卡数据组。如果交易期间用户或对手提供不正确的PIN，这将引起计算的虚拟数据与支付口服务器计算的虚拟卡数据相比产生不同的、不正确的值。在服务器将接收的虚拟卡数据组与预期值比较后，可检测到无效的PIN输入。当支付口服务器接收和验证虚拟卡数据组并检测到不期望的虚拟卡数据组(例如由于不正确的PIN)时,则可拒绝支付授权。

转向图8，提供示例计算机可执行或处理器执行的指令，由于促进移动设备501和POS终端设备502之间的交易，包括关于商场收单方103、支付口服务器506和资金卡发行方服务器104处理数据的进一步细节。

方框701、718、719、720和721再一次显示以提供该过程的背景。在POS终端设备502从移动设备501接收虚拟卡数据(方框719)后，POS终端设备502发送虚拟卡数据、交易信息(例如支付量)和其他信息(例如商场ID)至商场收单方103(方框801)。在一个示例实施方式中，POS终端设备502发送的数据是标准支付授权请求格式。

商场收单方103通过支付网络发送支付授权请求——其至少包括虚拟卡数据(例如虚拟卡的第二磁轨数据)和支付量——至支付口服务器506(方框802)。收单方103和支付网络能够通过虚拟卡PAN位的第一部分识别支付口服务器506。可理解为，PAN是第二磁轨数据的一部分。

支付口服务器506验证虚拟卡数据(方框803)。为验证从移动设备收到的虚拟卡数据(通过商场收单方103)，支付口服务器自身计算第二磁轨数据组。第二磁轨数据计算包括支付口服务器利用用户注册期间最初收到并存储的PIN计算酌定数据。在一个示例实施方式中，一些第二磁轨数据部分(如PAN和有效期)被预先计算和存储；这些预先计算的数据部分可与收到的第二磁轨数据比较。如果虚拟卡数据被成功验证(收到的卡第二磁轨数据组与支付口服务器计算的卡第二磁轨数据组匹配)，则支付口服务器搜索与虚拟卡数据卡相关联的资金卡数据(方框804)。

方框803中虚拟卡数据的验证可包括验证与虚拟卡相关的内部有效期是否已过。如果验证当日是发生在内部有效期日或之前，则虚拟卡可被认为有效，交易过程可继续。否则，虚拟卡被认为无效，支付授权请求被拒绝。

如果虚拟卡被验证，此时其作用与商场相似的支付口服务器506发送支付授权请求至其自身的收单方，其中支付授权至少包括在方框802收到的资金卡数据和相同的支付量，通过支付网络发送至资金卡发行方服务器104(方框805)。资金卡发行方104然后接收支付授权请求并按照标准处理交易。处理了交易后，资金卡发行方104通过支付网络发送支付授权代码至支付口服务器(方框806)。授权代码响应包括支付授权是否已被接受或被拒绝、交易识别号等等。

然后支付口服务器506通过支付网络发送相应的支付授权响应至商场收单方103(方框807)，收单方103也通过支付网络发送支付授权响应至POS终端设备502(方框808)。虽然未显示，支付口服务器将支付授权代码存储进数据库509。虽然也未显示，POS终端设备502可根据该响应显示消息给终端用户该支付已经被接受或被拒绝。

在一个示例实施方式中，支付口服务器506也发送确认至移动设备501，其指示是接受还是拒绝该支付(方框809)。该指示可作为支付应用软件620特定的数据发送，或作为电子邮件发送。在接收该指示后，移动设备501可根据该指示显示消息给用户。

在一个示例实施方式中，在支付口服务器506收到支付已被处理的响应后(方框806)，支付口服务器506标记虚拟卡已使用。以此方式，如果同一个虚拟卡在将来交易中再次使用，支付口服务器将拒绝交易。这是因为虚拟卡意味着只用一次。

在其他示例实施方式中，同一虚拟卡可使用不止一次交易。

转向图9a，提供计算机可执行或处理器执行的指令的一个示例实施方式，用于使用虚拟卡促进交易。在一个示例实施方式中，图9a的指令是详细说明方框710和711的执行的一个实例。在该示例实施方式，虚拟***(也称为虚拟卡PAN)、虚拟卡有效期和其他数据都通过支付口服务器506计算。也提供了说明虚拟卡发行方服务器401、虚拟卡操作者402和虚拟卡收单方403之间数据流动的细节。实体401、402、403可以是支付口服务器506的一部分。在另一个示例实施方式中，实体401、402、403是独立的实体。

方框901至908的操作是移动设备获得虚拟卡的整个过程的一部分(方框909)。

图9a中过程假定移动设备501安装了支付应用软件620并且移动设备和资金卡已经注册到支付口服务器506。也假定与商场的交易已启动。例如，POS终端设备502已显示消息“点击支付”，并且用户已经通过支付应用软件620选择资金卡。这些条件使用例如方框701、702、703、704、705、06和707实现。

在收到用户选择资金卡的输入后，移动设备501发送交易类型(在应用软件菜单中选择的动作，在本案中是“用虚拟卡支付”)和资金卡识别符。在一个优选的示例实施方式中，资金卡识别符在注册时确定。

虚拟卡操作者402通过例如确保资金卡识别符与已注册用户相关联并且选择的资金卡从注册起还没有过期，确认选择的资金卡有效(方框902)。

虚拟卡操作者402发送形成虚拟卡PAN的请求至虚拟卡发行服务器401(方框903)。虚拟卡PAN的该请求包括资金卡PAN后四位和资金卡有效期。虚拟卡发行服务器形成虚拟卡PAN，其后四位等于资金卡PAN后四位。虚拟卡也有相同的有效期和资金卡。虚拟PAN通过使用分配给虚拟卡发行方的前6位、唯一的以前从未用过的8位长随机数(以防止冲突)和mod10校验位形成。

在计算虚拟卡PAN后，在响应中虚拟卡发行服务器401发送该信息至虚拟卡操作者402(方框904)。虚拟卡操作者将产生部分第二磁轨数据，例如PAN、卡有效期、服务代码等等(方框905)。在一个示例实施方式中，酌定数据(是第二磁轨数据一部分的)在此时不支付口服务器506计算。虚拟卡操作者402将虚拟卡PAN与资金卡PAN相关联(方框906)并将它存储在数据库509(未显示)。也增加内部有效期至数据库中的虚拟卡记录。在一个示例实施方式中，内部有效期被计算为形成虚拟卡的时间之后的一些预先确定的时间段。例如，内部有效期是从形成虚拟卡的日期和时间后的48小时。然后虚拟卡操作者402加密并发送移动应用软件需要的虚拟卡数据(例如虚拟卡PAN、外部有效期等等)，以产生最终的虚拟卡数据组卡(方框907)。结果形成加密的虚拟卡有效载荷，其被发送至移动设备501(方框908)。

移动设备501从用户接收PIN(方框925)。移动设备501然后使用PIN计算酌定数据(其是虚拟卡的第二磁轨数据的一部分)。酌定数据的计算可涉及随时间、或随每次交易变化的动态值，从而使酌定数据为动态数据。从虚拟卡有效载荷接收的数据(例如PAN、有效期和其他数据)以及酌定数据形成虚拟卡的完整的第二磁轨数据组(方框926)。

转向图9b，提供计算机可执行或处理器执行的指令的一个示例实施方式，用于验证和授权使用虚拟卡的交易。图9b中过程假定虚拟卡已经形成(例如根据图9a)并且重点关注验证虚拟卡的过程。在一个示例实施方式中，图9b的指令是方框802-807详细说明的执行的实例。实体401、402、403可以是支付口服务器506的一部分。在另一个示例实施方式中，实体401、402、403是独立的实体。

相对于方框910-923描述的过程是虚拟卡的整个授权过程的一部分(方框924)。

流程开始于移动设备501已收到加密的虚拟卡有效载荷、解密了虚拟卡有效载荷、通过GUI获得用户PIN和计算完整的虚拟卡数据组(例如完整的第二磁轨数据组)之后。此时，移动应用软件可通过NFC子***609发送虚拟卡数据组至POS终端设备502(方框910)。POS终端设备502将虚拟卡数据与交易数据一起发送至商场收单方103(方框911)。商场收单方103将包括虚拟卡数据和支付量的支付授权请求通过支付网络发送至虚拟卡发行服务器401(方框913)。

虚拟卡发行服务器401发送虚拟卡数据至虚拟卡操作者402(方框914)。虚拟卡操作者402使用虚拟卡数据例如虚拟卡PAN搜索相关用户情况和资金卡数据(例如PAN和有效期)(方框915)。虚拟卡操作者402然后验证收到的虚拟卡数据，例如，通过比较数据与预期卡数据的服务器计算形式。验证过程类似于方框803的操作。

如果虚拟卡数据验证成功，则虚拟卡操作者402使用与虚拟卡交易相关的资金卡细节并发送支付授权请求——包括资金卡数据和相应的支付量——至虚拟卡收单方403。虚拟卡收单方403通过支付网络发送所述细节至资金卡发行服务器104(方框917)。

资金卡发行服务器104接收和验证资金卡数据。如果资金卡数据验证成功，资金卡发行服务器发送支付授权代码响应至虚拟卡收单方403，其将其发至虚拟卡操作者402(方框918)，都通过支付网络。支付授权代码响应表示资金卡数据是被接受还是被拒绝以及交易识别号等等。

虚拟卡操作者402发送相应的验证授权代码响应至虚拟卡发行服务器401(方框919)。虚拟卡操作者402和虚拟卡发行服务器401标记虚拟卡正使用(方框920和方框921)。以此方式，如果同一虚拟卡后来再次使用，虚拟卡操作者402或虚拟卡发行服务器401将能够检测到可能的欺骗。

虚拟卡发行服务器401发送虚拟卡的支付授权代码响应至虚拟卡操作者402(方框922)。虚拟卡的该支付授权代码响应然后通过支付网络被发至商场收单方103(方框923)。

如前所述，在其他示例实施方式中，不对每次交易计算虚拟卡。例如，在根据方框708、709、710、711、712、713和714计算虚拟卡后，对于一个或多个后续交易，同一虚拟卡可用于交易。换言之，对于一个或多个后续交易，不进行方框708、709、710、711、712、713和714。这在进行交易时节约了处理能量并减少了计算时间。当移动设备501不能与支付口服务器506通信时这也可以是有利的。换言之，即使移动设备501不能与支付口服务器506通信，移动设备也能够使用已经计算的虚拟卡进行交易。

在同一虚拟卡用于后续交易的示例实施方式中，某些事件或时间段或二者可激发在移动设备501上计算和装载新的虚拟卡。在一个示例实施方式中，当给定数量的交易已经使用以前的虚拟卡进行并且当移动设备501能够与支付口服务器506通信时计算新虚拟卡。给定数量的交易是例如每当新虚拟卡发行到移动设备501产生的随机产生的数量。在另一个示例实施方式中，当自从计算以前的虚拟卡起已经过了给定天数并且当移动设备501能够与支付口服务器506通信时对交易计算新的虚拟卡。给定天数是例如每当新虚拟卡发行到移动设备501产生的随机产生的数量。可理解，随机产生的数量防止攻击者预测下一个新的虚拟卡何时对于移动设备进行计算。

转向图10，提供计算机可执行或处理器执行的指令的一个示例实施方式，用于向支付口服务器注册资金卡和移动设备。该实施方式可结合上述原理使用。移动设备501发送注册请求至支付口服务器506(方框1001)。该请求包括移动设备的设备ID、用户提供的PIN和资金卡细节。在收到该请求后，支付口服务器发送注册响应至移动设备(方框1002)。该响应包括证书、应用交易计数器(ATC)、产生PAN的密钥值(称为Kpan)、安全元件密钥值(称为Ksec)和识别每个已注册资金卡的资金卡识别符。证书是移动设备501的客户证书，并且在一个示例实施方式中，配置为根据RSA算法并具有2048字节长。ATC是最初设定为0到1000之间的随机值并且随每次交易增加的计数器。最初的ATC值是随机值，以防止对手预测ATC值。存储ATC的备份并且同步在支付口服务器和移动设备上。在一个示例实施方式中，ATC是10位值。在一个示例实施方式中，Kpan是128字节长，Ksec是128字节长。

支付口服务器506存储来自注册请求的数据和相互关联的注册响应(方框1003)。移动设备501也存储来自注册响应的数据(方框1004)。

转向图11，提供计算机可执行或处理器执行的指令的一个示例实施方式，用于计算虚拟卡数据。该实施方式可结合上述计算虚拟卡数据的原理使用。移动设备501发送虚拟卡请求至支付口服务器506(方框1101)。这类似于图9a中方框901。该请求包括设备ID、所选择资金卡的识别符、证书和存储的Kpan。存储的Kpan可来自注册或来自以前交易。

支付口服务器506确定收到的Kpan和证书是否和与支付口服务器数据库存储的设备ID相关联的支付口服务器(方框1102)存储的Kpan和证书匹配。如果是，则支付口服务器506发送虚拟卡响应至包括新Kpan的移动设备501(方框1103)。新Kpan用于产生不同于以前交易的PAN，并且也防止再次攻击。支付口服务器506使用新Kpan计算虚拟卡PAN(方框1104)。该新Kpan和预先计算的PAN由支付口服务器506存储以便以后使用(方框1105)。

在移动设备接收新Kpan后，用新Kpan替换已存储的Kpan(方框1106)。使用新Kpan计算虚拟卡PAN，方式同支付口服务器计算PAN(方框1107)。如果条件和数据正确，虽然移动设备计算PAN独立于支付口服务器，但移动设备计算的PAN应当与支付口服务器计算的PAN相同。

移动设备然后使用PIN、Ksec、PAN、证书以及ATC计算酌定数据(其是第二磁轨数据的一部分)(方框1108)。ATC和PAN保持随每次交易改变，这使得酌定数据是动态数据。

移动设备将ATC增加1(方框1109)。

具体地，移动设备和支付口服务器根据下述计算PAN：

PAN＝BIN(6)+SHA256[Kpan](8)+Luhn(1)+Reserved(4)

其中BIN(6)是6位二进制数以识别支付口服务器；

SHA256[Kpan](8)是8位数，通过取Kpan值的sha256、进一步包括将sha256值转化为小数并从散列值(hash value)截断为8位而产生；

Luhn(1)是单一位，用于确保虚拟卡总通过LUHN算法；

和Reserved(4)是4位数，与资金卡PAN后4位相同。

将上述值连起来形成PAN。上述计算中符号“+”指连接操作。

在计算PAN的一个示例实施方式中，其他值可以是已知的或先计算的，LUHN值后计算。例如，PAN中间形式是66666612345678X1111，从而X代表Luhn(1)。换言之，BIN(6)＝666666；SHA256[Kpan](8)＝12345678；Reserved(4)＝1111。

不同的LUHN算法可用于解X，以确保PAN满足LUHN算法。例如，一个示例实施方式算法包括(步骤1)从最右位开始加倍每个其他位的值；(步骤2)将包括步骤1的X位在内的所有各位加和；以及(步骤3)对于X位，解表达式mod 10(从步骤2的总加和)＝0。在该示例实施方式中，方程的解是X＝9。可使用其他LUHN算法。

在一个示例实施方式中，可使用满足LUHN标准的PAN后4位前的任何位。

使用下述计算酌定数据：

酌定数据＝HMAC_SHA256[Ksec+PIN,M](10)

其中M＝连接(PAN、证书ID、ATC)

通过以小数编码SHA结果，然后取最左位，进行截断。可理解为，SHA256是已知的密码杂凑函数(cryptographic hash function)，HMAC是散列式消息授权码，包括与秘密密钥(secret cryptographic key)结合的密码杂凑函数。HMAC函数的秘密密钥是Ksec和PIN的连接值。消息M是PAN、证书ID和ATC的连接值。证书ID来自证书。

转向图12，提供计算机可执行或处理器执行的指令的一个示例实施方式，用于验证虚拟卡数据，并且具体地，通过酌定数据(例如动态数据)的支付口服务器验证。该实施方式可结合上述验证虚拟卡数据的原理使用。这可以是图11所述过程的继续。

移动设备501发送虚拟卡至商场POS终端502，其然后形成和发送支付授权请求至商场收单方103(方框1201)。支付授权请求最后由支付口服务器506(方框1202)接收。支付授权请求包括虚拟卡的PAN和酌定数据等，如移动设备501计算的。

在收到请求后，支付口服务器506使用PAN发现相关的存储的关联数据(例如Kpan、证书、Ksec、资金卡识别符、设备ID和其他用户数据)。相关的存储的关联数据通过预先计算的PAN识别，预先计算的PAN充当检索服务器数据库的索引。换言之，将收到的PAN与许多预先计算的PAN比较，如果发现与给定的预先计算的PAN匹配，则与该给定的预先计算的PAN相关联的存储数据被认为是相关的存储的关联数据。

支付口服务器506使用相关的存储的关联数据计算其自身的酌定数据。这可包括使用PIN(在用户注册过程中收到)、存储的Ksec、来自存储的证书的证书ID和ATC的渐增值(方框1203)。

计算支付口自身的酌定数据使用下述：

酌定数据＝HMAC_SHA256[Ksec+PIN,M](10)

其中M＝连接(PAN、证书ID、(ATC+1))

ATC+1表示渐增的ATC值。

支付口服务器506确定其自身的酌定数据是否等于收到的酌定数据(方框1204)。如果它们不等，支付口服务器进一步将ATC增加“1”并重新计算其自身的酌定数据(方框1205)。该过程返回方框1204以检查酌定数据组是否相等。可重复包括方框1205的过程，以便每次ATC值都进一步增加1。这可进行直到某次数(例如10次)，其后停止交易过程。

如果APC值的范围(例如ATC+1和ATC+10之间)不产生相等的酌定数据组，则该验证不成功。该范围用于解释这样的可能性：移动设备的ATC计数器可能已经增加而没有通知支付口服务器。因此，使用缓冲或范围或ATC值。

如果支付口服务器自身的酌定数据与收到的酌定数据相同，则支付口服务器用计算其自身的酌定数据中使用的现在增加的ATC值代替前面的ATC值。以此方式，支付口服务器中存储的ATC值现在应等于移动设备上存储的ATC值。

注意，如果移动设备用来酌定数据的PIN被用户不正确地输入(例如不同于注册时提供的PIN)，则来自移动设备的酌定数据将不等于支付口服务器自身的酌定数据。这是因为其自身的酌定数据使用注册时提供的PIN计算。以此方式，用户在每次交易过程中提供到移动设备中的PIN通过支付口服务器隐藏地验证。

继续图12，在数据验证成功或不成功以后，支付口服务器最终通过发送授权响应至商场(103、502)响应至商场(方框1207)。为了更清楚，如果酌定数据验证不成功(根据方框1205在达到某一重复后)，则发送负支付授权响应至商场(方框1207)。

本文所述的方法和***不依赖于在移动设备的安全元件上存储有软件式支付卡来促进无接触式支付交易。这是因为PAN以及资金卡的其他卡数据元素未存在在移动设备中。而是，资金卡PAN和有效期存储在安全服务器(例如支付口服务器)上。而且，虚拟卡数据在安全服务器上形成，并且对于具体移动设备加密。进一步，第二磁轨数据中的酌定数据是每次支付重新输入的PIN的函数。虚拟卡数据只在进行支付时发生，并且可仅用一次。此外，只有服务器可验证虚拟卡数据。换言之，对手不能通过移动设备上的简单算法(bruteforce)访问而不被发现。

进一步，虚拟卡加密的有效载荷不能再用。这是因为只要卡被用一次，它不能再被任何其他方使用。

也注意，在一些示例实施方式，在商场的支付授权之前实时形成一次性虚拟卡。

进一步，资金卡细节从来不提供给商场，因为是提供虚拟卡细节。

本文所述的方法和***与标准的四方卡支付模式和***兼容。资金卡发行方、商场、收单方或支付网络无需改变***。

本文所述的方法和***也允许使用“单一应用软件”，用于支持一个或多个虚拟卡以及一个或多个资金卡。这减少了安全元件上需要的存储(以及通常地移动设备上需要的存储)，以不限制消费者可以装入安全元件的卡数量。

可理解，本文所述的方法和***使持卡者(例如终端用户)能够注册任何他们想要访问其NFC可用的移动设备的资金卡，而独立于具有基础构架或与特定移动操作者的商业关系的卡发行方。

本文所述的方法和***可用于任何类型的资金卡。资金卡和移动设备预先注册到支付口服务器506。该注册独立于任何特定的移动电话运营商和任何特定的资金卡发行方。因此，使用移动设备促进无接触式支付，移动电话运营商和资金卡发行方不需要商业协定和额外的计算用基础构架。这又减少了资金卡发行方发行软件式支付卡至移动设备引起的费用。

在一个示例实施方式中，提供了服务器进行的促进支付的方法。该方法包括：接收来自移动设备的识别资金卡的消息；对于与识别的资金卡相关联的资金***，检索与移动设备相关联的多个卡的数据库；计算虚拟卡的数据，所述数据包括***和有效期；与资金***相关联，存储虚拟***的数据；发送虚拟卡的数据至移动设备；利用用户PIN作为输入，计算卡细节；从商场收单方接收第一支付授权请求，所述请求包括虚拟卡的数据和请求的支付量；基于虚拟卡的数据搜索资金***；发送第二支付授权请求至资金卡发行方，该请求包括资金***和所述请求的支付量；从资金卡发行方接收支付授权响应；和发送支付授权响应至商场收单方。

基于电子商务和互联网的交易

在提出的***和方法的另一示例实施方式中，虚拟卡的上述原理也适用于基于电子商务或互联网的交易。换言之，虽然上述实例包括使用与移动设备501相互的物理的POS终端设备502，但基于电子商务或互联网的交易不使用POS终端设备502。而移动设备501可与商场收单方103或支付口服务器506(例如通过电子商务网页或支付应用软件)通信。换言之，为了执行交易，移动设备使用互联网连接发送虚拟卡数据至商场收单方103或支付口服务器506(例如通过电子商务网页或支付应用软件)。

例如，可进行包括POS终端设备502的上述操作，但使用电子商务网页或支付应用软件而不是POS终端设备502。如图13所示，提供了在使用虚拟卡促进支付的支付交易的一个示例实施方式中涉及的实体的示意视图，其类似于图5。但是，不同于显示POS终端设备502的图5，在图13中显示互联网和电子商务界面1301，其与移动设备501和商场收单方103交互。在另一个示例实施方式中，附加地或替代地，移动设备501直接通过连接1302所示的互联网和电子商务界面与支付网络504交互。应理解，移动设备501不需要NFC子***609进行交易，而使用互联网和电子商务界面1301。换言之，移动设备501可以有或可以没有NFC子***609，而不影响安全元件622上信息的存储和搜索，并且不影响互联网或电子商务交易。移动设备通过网页连接至互联网和电子商务界面1301，该网页可通过移动设备上的互联网浏览器应用软件619浏览。在另一个示例实施方式中，移动设备通过支付应用软件GUI连接至互联网和电子商务界面1301。

一般地，上述关于图7、8、9a、9b、10、11和12描述的实例也用于电子商务交易，但按照图13，POS终端502被互联网和电子商务界面1301代替。

图14示出电子商务网页或支付应用软件GUI显示的示例图形化用户界面(GUI)。这由移动设备501显示，例如，当用户选择产品、项目或服务以购买时。显示了交易细节1402，其包括例如用户要付的量以及用户姓名。其他信息例如产品ID或用户ID可显示。资金卡信息1403也显示，并且在***的情况下可显示资金卡1404后四位。在一个示例实施方式中，显示缺省资金卡，但可使用控制1407选择不同的资金卡。在图14的实例中，移动设备501将使用与尾数为‘4242’(1404)的Visa资金卡相关联的虚拟卡进行支付。在另一个示例实施方式中，后四位没有显示以防止攻击者看见该信息。

当显示GUI1401时，为了完成交易，用户输入PIN到区域1405中并选择“现在支付”按钮1406。当GUI1401检测到这些事件时，移动设备501通过互联网和电子商务界面1301发送虚拟资金卡数据到商场收单方103或支付口服务器506。

在另一个示例实施方式GUI(未显示)中，未显示“现在支付”按钮1406。例如，GUI能够检测多少字符被输入到输入区域1405中的长度。在GUI检测到在输入区域1405中已经输入所需的字符数后，自动提交PIN。

在一个示例实施方式中，PIN是资金卡的卡认证值(CVV)、卡安全值(CSV)、卡安全码(CSC)、卡代码认证(CCV)、卡认证码(CVC或CVC2)等，并且该值由资金卡发行方104确定。在另一个示例实施方式中，PIN由用户确定。在另一个示例实施方式中，PIN是密码。在另一个示例实施方式中，PIN是***“Visa认证(Verified by Visa)”使用的密码，该***是补充认证。

在另一个示例实施方式中，如图15所示，提供另一实例GUI 1501，其显示交易细节1402、资金卡信息1403和“现在支付”按钮1406。换言之，当显示GUI 1501时，用户仅需选择“现在支付”按钮1406来执行交易。这使得移动设备501通过互联网和电子商务界面1301发送虚拟资金卡数据至商场收单方103或支付口服务器506。应理解，使用图15的GUI，不需要PIN。

转向图16，提供示例处理器执行指令组，其用于采用互联网和电子商务界面1301进行支付。图16类似于图7，所以相似的操作不再详细描述。在方框1601，互联网和电子商务界面请求移动设备在电子商务GUI(例如1401和1501)显示数据。在方框1602，移动设备501显示电子商务GUI。任选地，但不是必需地，方框703和704由移动设备501进行。进一步，在方框706，移动设备通过电子商务GUI任选地显示预注册的资金卡，并且用户选择资金卡707。在其他实施方式中，只有一个资金卡，或者有使用的缺省资金卡，除非用户改变。进行在方框708、709、710和711的操作。如上所述，在一些示例实施方式中，可使用以前计算的虚拟卡，并且因此不需要对每一个和每次交易计算新的虚拟卡。

继续图16，在一个示例实施方式中，电子商务GUI请求PIN认证(方框712)以及用户提供PIN(713)。然而，在其他实施方式中，不需要提供PIN。也进行方框714和715的操作。然而，在其他实施方式中，如果以前计算的虚拟卡正在使用，不进行方框714和715。

在一个示例实施方式中，用户通过电子商务GUI输入命令以执行交易(方框1603)。例如，用户可选择“现在支付”按钮1406，或者提供一些理解为执行交易的其他输入。

移动设备发送虚拟卡数据至互联网和电子商务界面(方框1604)，互联网和电子商务界面发送虚拟卡数据至商场收单方103或支付口服务器506(见图17)。当交易结束(接受或拒绝)，通过互联网和电子商务界面将确认消息发送至移动设备(方框1605)。然后可进行方框722。

图17显示示例处理器执行指令，其是图16的继续。包括方框1601、1603和1604以显示背景，并且在前面的图16中实施。图17类似于图8，但包括互联网和电子商务界面1301。方框801、802、803、804、805、806、807、808和809的操作适用于图17，不再详细描述，因为这些方框关于图8已详细描述。

两方价值转移

在提出的***和方法的其他实施方式中，下述一般地涉及在移动设备上使用虚拟卡促进两方价值转移。

移动设备可用于转移价值，例如在两个人之间。移动设备可装备近场通信(NFC)***，其用于转移支付凭证例如支付卡信息至另一也装备NFC***的移动设备。

应认识到，从一个人的移动设备到另一个人的设备转移金钱是困难的，或者更一般地，使用移动设备从一方转移到另一方是困难的。在许多情况下移动电话运营商和资金卡发行方没有计算***来支持金钱从一个移动设备转移到另一个移动设备，或者对双方而言是成本不允许的。也应认识到，在移动设备之间以安全方式转移金钱、同时仍保持便利是困难的。

也应认识到，存在这样的情形：发送用户希望转移价值到接收用户，但发送用户不了解或不相信接收用户。例如，发送用户欠接收用户的钱，但不了解或不相信接收用户。使用资金卡转移价值(例如金钱)至接收用户而不用提供关于资金卡的任何数据或信息可能是困难的。进一步，以快捷和便利的方式这样做也使得价值转移困难。

也应认识到，存在这样的情形：接收用户没有银行账户。换言之，接收用户没有已建立的账户来接收和存储来自发送用户的价值(或资金)。因此，在许多情况下接收用户不能接受或接收来自发送用户的价值(或资金)。

使用转移ID两方转移价值

本文所述的方法和***允许发送者(例如第一人)发送价值，例如金钱，至接收者(例如第二人)。具体地，发送者的NFC可用的移动设备针对接收者的NFC可用的移动设备进行“点击”，进行价值转移，转移的价值与作为预付虚拟卡的接收者移动设备相关联进行存储。接收者然后可以使用其NFC可用的电话用预付虚拟卡进行支付，这通过NFC(例如利用商场的NFC可用的销售点终端机)或通过互联网(例如移动电子商务或电子商务)。

作为替代的示例实施方式，代替发送虚拟卡，支付口服务器506发送转移ID至给定用户，与接收用户共享。该转移ID由支付口服务器用于识别选择的资金卡和发送用户指定的量。换言之，转移ID被看做是指针，其指向支付口服务器存储的信息以识别选择的资金卡和发送用户指定的量。转移ID的非限制性实例可以是数字、字符集(包括数字)和URL。

本文所述的***和方法也允许基于云的钱包支付口服务器与接收者的NFC可用的移动设备和应用软件同步，从促进从发送者的NFC可用的移动设备进行无接触式价值转移。发送者用户选择资金卡并通过其移动设备提供进行无接触式两方价值转移的量。转移ID由支付口服务器产生，以完成两方支付交易。转移ID由支付口服务器用于识别选择的资金卡和发送用户要转移的量。在支付口服务器上，转移ID暂时与资金卡和要转移的允许量相关联。

当启动两方价值转移时，包括转移ID数据在内的数据通过发送者移动设备上的NFC***发送至接收者的NFC可用的移动设备。这种信息从接收者移动设备发送至基于云的钱包支付口服务器(也称为“支付口服务器”)。基于云的钱包支付口服务器验证转移ID。如果验证成功，与转移ID相关的发送用户的资金卡细节被搜索和通过支付口服务器发送至资金卡发行方服务器，以完成价值转移授权。资金卡发行方服务器验证资金卡并发送回授权代码至支付口服务器。支付口服务器然后充当虚拟卡发行方服务器并产生预付虚拟卡给接收者用户，其可被接收者移动设备使用。

当支付口服务器启动结算请求时可结算预付虚拟卡的价值转移，通常在每个工作日结束时结算一次，使用标准方法。这包括搜索在该期间收到的所有资金***和相应的授权代码并发送这种信息至资金卡发行方以结算。资金卡发行方验证资金***和授权代码，如果验证成功，通过标准的电子资金转移方法，发送金钱回到与支付口服务器相关联的银行账户。与预付虚拟卡账户相关联，存储该金钱。在一个示例实施方式中，虚拟卡发行方是支付口服务器或者支付口服务器内的模块。

在另一个示例实施方式中，在发送者移动设备发送转移ID至接收者移动设备之前，发送者移动设备请求通过支付口服务器授权给资金卡发行方。在授权完成后，转移ID形成并发送至接收者移动设备。接收者移动设备利用支付口服务器验证转移ID。支付口服务器然后进行与来自转移ID的授权请求相关的结算请求。支付口服务器然后产生预付虚拟卡给接收者用户，其可被接收者移动设备使用。

在另一个示例实施方式中，在发送者移动设备发送转移ID至接收者移动设备之前进行授权和结算二者。在资金卡发行方服务器完成授权后并且在已进行价值转移的结算和已经形成预付虚拟卡之后，然后转移ID转移至接收者移动设备。

在一个示例实施方式中，本文所述的***和方法允许具有两方转移应用软件的NFC可用的设备转移用户限定量的价值至另一NFC可用的设备——其也具有两方转移应用软件，而永远不会公开发送者的资金卡细节给接收者。进一步，发送者能够设定或确定给予接收者的价值。成功的转移导致发给接收用户与发送用户发送的价值量相同的预付虚拟卡。因此，即使接收用户没有银行账户接收价值，接收用户仍能够被给予预付虚拟卡，其可被接收用户用于进行支付和交易。

可理解，任何资金卡可被使用并且不限制于或依赖于与资金卡发行方有协定的移动电话运营商。对于要用的卡，首先需要注册该服务。也可理解为，与移动设备相关联可注册许多资金卡。持卡者的移动设备包含支付应用软件(也称为价值转移应用软件)，其可与支付口服务器交互。

在注册的一个示例实施方式中，对于发送用户希望注册的每一资金卡，用户将卡细节键入移动设备(例如资金卡上印刷的姓名、资金卡上印刷的PAN、资金卡上印刷的有效期和资金卡上印刷的静态安全码)。如上提及，资金卡发行方无需具有与任何移动电话运营商已有的协定。移动设备发送该数据和移动设备ID至支付口服务器。支付口服务器计算资金卡识别符，其识别给定的资金卡。支付口服务器存储与资金卡细节相关的资金卡识别符并发送资金卡识别符至移动设备以便存储。在另一个示例实施方式中，用户简单地点击移动设备上的无接触式卡，使得移动应用软件可获得卡细节并将其发送至支付口服务器以注册。在一个示例实施方式中，资金卡识别符是不同于资金卡的PAN、有效期或静态安全码的值。例如，资金卡识别符是随机值，这样如果被对手拦截，对手不能认识任何资金卡细节。在一个示例实施方式中，移动设备不存储任何资金卡细节或存储有限的资金卡细节(例如资金卡发行方姓名和PAN后四位)。移动设备存储资金卡识别符，其发送至支付口服务器以指示具体的资金卡。可理解，存在其他获得资金***细节的方法(例如在键入数据的用户旁边)，其可用于本文所述原理。

可理解，移动设备上需要单一支付应用软件，其可管理多个资金卡。如果注册多个资金卡，则每个相关的资金卡识别符存储在移动设备中，在所述单一支付应用软件内。每个单独资金卡的细节存储在支付口服务器。以此方式，支付口服务器充当基于云的服务器，其存储多个资金卡的细节。

转向图18，提供计算机可执行或处理器执行的指令的一个实例，用于促进从发送用户101至接收用户1807的价值转移。在方框1801，发送用户指定资金卡以及转移至接收用户的量。在方框1802，发送用户从支付口服务器接收转移ID，其基于所述量和资金卡。在方框1803，发送用户发送转移ID至接收用户。在方框1804，接收用户验证转移ID和量，例如通过支付口服务器。在方框1805，如果有效，接收用户被发给发送用户指定量的预付虚拟卡。

对于方框1803，虽然本文所述的许多示例实施方式使用NFC技术在移动设备之间传送数据，但可理解，可使用其他数据传送方法。例如，转移ID可通过蓝牙、红外和其他点对点(P2P)通信技术发送至接收用户的移动设备。在其他示例实施方式中，转移ID可通过其他不一定是P2P的方式传送，包括即时通讯、发送短信、条形码、2D条形码、QR码、电子邮件等。在一个示例实施方式中，额外的数据或替代的数据从发送用户的移动设备发送至接收用户的移动设备以促进价值转移，产生接收用户可用的预付虚拟卡。在一个示例实施方式中，转移ID被安全产生，例如，当它在任何的服务器、发送用户的移动设备和接收用户的移动设备之间传送时。

转向图19，显示促进两方资金转移的***的示例实施方式组件，其使用转移ID。显示了发送用户101。该用户具有一个或多个资金卡505。例如，该用户具有多个资金卡。用户101也具有NFC可用的移动设备501，其包含支付应用软件(也称为价值转移应用软件)。发送者移动设备1901配置为通过NFC与接收者的NFC可用的移动设备1901交互。应理解，接收者移动设备1901可具有与发送者移动设备类似的硬件和软件组件，如图6中所示。发送者移动设备501和接收者移动设备1901与支付口服务器506交互。支付口服务器506也与资金卡发行服务器104进行数据通信。

支付口服务器506存储特定于发送用户的数据元件(方框1903)和特定于接收用户的数据元件(方框1902)。例如，特定于发送用户的数据元件(方框1903)包括注册的数据关联1904，其将一个或多个资金卡与发送者移动设备ID关联。例如，资金卡1和资金卡2(以及其他资金卡)与发送者移动设备501的移动设备ID相关联地存储。也存在暂时的数据关联1905，其包括与用户的资金卡1906之一暂时关联的转移ID1907。转移ID1907可被发送用户101用于进行两方价值转移。

与接收用户相关的数据元件(方框1902)包括注册的数据关联1908，其指定零或更多资金卡与接收者移动设备ID相关联。例如，与接收者移动设备ID相关联的资金卡可包括两个资金卡和支付口服务器506发行的预付虚拟卡1909。可理解，接收用户1807的预付虚拟卡1909可用于对商场进行支付或者进行另一两方价值转移至另一用户。

支付口服务器506通过无线网络与移动设备501、1901通信。例如，无线网络由移动电话运营商提供。支付口服务器506通过有线或无线方法或二者与资金卡发行服务器104数据通信。

转向图20、21和22，发送移动设备501和移动设备1901显示为在通过NFC发送资金时相互交互。

转向图20，接收者移动设备1901显示允许用户发送或接收资金的图形化用户界面(GUI)的示例实施方式。虽然未显示，发送者移动设备501可能已经显示相似的GUI，然后基于用户选择发送资金，将移动设备501置于发送资金的模式。在“发送资金”模式，发送者移动设备501显示用于促进资金发送的GUI。图20中发送者移动设备501上显示的GUI是这种用于促进资金发送的GUI的一个示例实施方式。

继续图20，发送者移动设备501上的GUI包括包括输入区域2001，其允许发送者指定以两方转移发送多少金钱。例如，可指定为$100。也包括可选择来进行两方转移的资金卡的菜单。一个选择是例如使用CIBC(例如第一发行银行的名称)的Visa***2002；另一选择是使用蒙特利尔银行或BMO(例如第二发行银行的名称)的万事达***2003。用户选择2004Visa***2002作为资金卡。

接收者移动设备1901也具有支付应用软件，其显示GUI，具有接收资金2006的控制和发送资金2005的控制。接收用户通过选择控制2006提供选择输入2007，这将移动设备1091置于接收资金的模式。

转向图21，在将需要的信息输入各移动设备501、1901的支付应用软件后，准备转移资金。发送者移动设备501显示消息为“点击电话以使用CIBC Visa发送$100资金”。接收者移动设备1901显示消息为“点击电话以接收资金”。在该阶段，两个移动设备501、1901被放置足够近(例如接触)以允许通过NFC成功转移数据。

转向图22，在金钱已从发送者转到接收者后，发送者移动设备501显示信息“您已发送$100至鲍勃(647-667-1234)”。该消息例如包括转移量、接收用户姓名和接收者移动设备的电话号码。接收者移动设备1901显示消息“您已从爱丽丝(416-333-4321)收到$100预付虚拟卡”。该消息例如包括收到量、发送用户姓名和发送者移动设备的电话号码。

转向图23，提供示例计算机可执行或处理器执行的指令，用于促进发送用户和接收用户之间的两方资金转移。

在一个示例实施方式中，假定发送和接收用户都具有NFC可用的设备。也假定两个移动设备已安装了支付应用软件。也假定两个用户已注册其移动设备到支付口服务器。也假定发送用户也已预先注册一个或多个资金卡到支付口服务器，每个都通过资金卡识别符识别。换言之，支付口服务器具有与发送者移动设备ID相关联地存储的资金卡细节。

发送用户101启动其移动设备501上的支付应用软件620(方框2301)。支付应用软件620确定用户是否成功注册该服务(方框2302)，如果是，显示应用软件菜单，并显示选项以给出使用支付应用软件(方框2303)。用户101选择该选项以使用支付应用软件给出金钱。注意，各种用户经验可用于本文所述原理。

例如，菜单上的GUI能够接受用户的输入以使用支付应用软件启动利用虚拟卡的两方资金转移。其他菜单项目的实例包括“增加资金卡”、“删除资金卡”等。

移动设备501然后显示用户已经预先注册的资金卡(方框2305)。接收用户输入以指定要转移的量(例如给定的)以及接收输入以选择一个资金卡(方框2306)。在一个示例实施方式中，在终端用户成功注册该服务以及已注册至少一个资金卡后装载显示的资金卡信息。当用户增加额外的资金卡到支付应用软件中或者当选择了资金卡时更新目录。对于每个注册的资金卡,在支付应用软件620和支付口服务器数据库506上存储相应的记录，其包括与资金卡相关联的支付网络识别符、资金卡识别符等。

支付应用软件620发送移动设备识别符至支付口服务器506以进行设备认证(方框2307)。支付应用软件620也发送交易类型(应用软件菜单中选择的动作，在本案中为“进行两方转移”)、要转移的量(例如给定的)和选择的资金卡的资金卡识别符至支付口服务器506(方框2308)。支付口服务器506存储移动设备501发送的信息并且也计算关于转移ID的细节(方框2309)。转移ID与资金卡和指定的量相关联。有效期也与转移ID相关联，这样，在一段时间之后，转移ID不再有效。例如，从形成转移ID开始几分钟、几小时、一天或某一其他时间之后，转移ID不再有效。换言之，如果发送用户要转移价值至接收用户，在该时间期间失效之前这样做。支付口服务器506发送转移ID至发送用户的移动设备501(方框2310)。在一个示例实施方式中，转移ID被加密并且能够被发送用户的移动设备应用软件620解密。

作为替代的示例实施方式，不是支付口服务器506发送转移ID至移动设备，而是支付口服务器506发送密钥值，移动设备可用其产生与支付口服务器506产生的相同的转移ID。如果攻击者拦截密钥值，发送密钥值可能更安全。应理解，移动设备501最终获得转移ID。

移动设备支付应用软件620任何显示消息，请求用户对于接收者移动设备1901点击发送者移动设备501(方框2311)。发送用户101告知接收用户1807准备接收资金，例如，通过一起“点击”移动设备(方框2312)。在其他示例实施方式中，附加地或替代地，发送用户通过其他通信手段发送转移ID至接收用户，包括蓝牙、红外、电子邮件、即时通讯、发送短信和其他无线和有线的手段。

在一个示例实施方式中，在将转移ID传递至移动设备501上的支付应用软件620之前，移动设备501显示GUI，其请求发送用户输入其PIN(例如其应当与发送用户注册服务时提供的PIN相同)。在一个示例实施方式中，首先验证PIN。在另一个示例实施方式中，代替地，支付口服务器506发送密钥值以产生转移ID，发送用户再次提供的PIN与密钥值一起用于产生转移ID。如果发送用户提供的PIN正确，则移动设备501产生的转移ID应等于支付口服务器506产生的转移ID。

转向图24，在发送用户告知接收用户进行准备后，接收用户启动接收者移动设备1901上的支付应用软件(方框2401)。接收者移动设备1901确定用户是否已成功注册该服务(方框2402)，如果是，显示菜单(方框2403)。接收用户提供输入以使用支付应用软件启动两方资金接收(方框2404)。然后接收用户1807和发送用户101都一起点击其移动设备501、1901(方框2405和2406)。

该基(或更具体地紧密靠近移动设备)启动发送者移动设备501提供NFC发送转移ID(方框2407)。在另一个示例实施方式中，转移ID通过其他方式(例如条形码、2D条形码、QR码、发短信、电子邮件等)被传送至接收者移动设备1901。在一个示例实施方式中，转移ID从移动设备的安全元件622发送。在另一个示例实施方式中，转移ID的发送不涉及移动设备的安全元件622。

继续图24，在接收者移动设备1901从发送者移动设备501接收转移ID后，移动设备1901将其发送至支付口服务器506(方框2408)。支付口506验证转移ID(方框2409)，如果转移验证成功，则支付口服务器506搜索与该转移ID相关联的发送用户的资金卡细节和指定的量(方框2410)。

为了验证转移ID，支付口服务器可确认转移ID本身是否正确(例如匹配支付口服务器上储存的转移ID)。也可检查看转移ID是否过期，如果是，将拒绝转移。也检查看转移ID是否以前使用过，如果是，将拒绝转移。

支付口服务器506然后产生价值转移支付授权请求，其包括资金卡细节和要转移到接收用户1807的量(方框2411)。虽然未显示，支付口服务器506然后发送该标准的支付授权请求至资金卡发行服务器104。资金卡发行服务器104验证支付授权请求(例如验证足够的资金是否可用、验证资金卡数据等)并提供支付授权响应至支付口服务器506。该响应指示价值转移是被接受还是被拒绝。

假定使用资金卡的支付被接受，支付口服务器506标记使用的转移ID(方框2412)。注意，转移ID是一次性使用。换言之，当发送者希望进行另一次两方转移时，新的(例如不同的)转移ID将针对该另一两方转移形成，即使使用的是相同的资金卡和数量。以此方式，安全性提高，并且接收用户从不会得到发送用户的资金卡的细节。

支付口服务器506要发行给接收用户的预付虚拟卡以及与其相关的细节(方框2413)。预付虚拟卡与接收者移动设备ID相关联地存储。转移的金钱量(来自发送用户)在预付虚拟卡上相关联的(例如可用的)金钱量。支付口服务器506然后发送关于预付虚拟卡的细节(例如预付虚拟卡识别符)至接收者移动设备(方框2414)。

具体而言，支付口服务器计算预付识别预付虚拟卡账户的虚拟卡识别符。支付口服务器储存与预付虚拟卡细节相关联的预付虚拟卡识别符，并发送预付虚拟卡识别符至接收用户的移动设备以存储。在一个示例实施方式中，预付虚拟卡识别符是不同于预付虚拟卡的PAN、有效期或静态安全码的值。例如，预付虚拟卡识别符是随机值，这样如果被对手拦截，其不能认识任何预付虚拟卡细节。在一个示例实施方式中，接收用户的移动设备不储存任何的预付虚拟卡细节或储存有限的预付虚拟卡细节(例如预付虚拟卡发行方的姓名和PAN后4位)。在一个示例实施方式中，接收用户的移动设备至少储存预付虚拟卡识别符，其发送到支付口服务器以指示相关的预付虚拟卡。

在接受预付虚拟卡识别符后，接收者移动设备存储该信息(方框2415)并向接收用户显示新的预付虚拟卡可用的消息(方框2416)。

支付口服务器506也可发送确认消息至发送者移动设备501，指示新的预付虚拟卡已发行给接收者(方框2417)。

在接收者1807有了预付虚拟卡后，接收者可使用预付虚拟卡在商场进行购买。

使用虚拟卡在两方转移价值

在另一个示例实施方式中，不是使用转移ID，发送虚拟卡而非转移ID来促进从发送用户至接收用户的价值转移。虚拟卡与资金卡相关联。当使用虚拟卡时，接收用户不能获得发送用户的资金卡的信息。这提高了安全性。转移的结果是，接收用户具有可用于支付或另一两方转移的预付虚拟卡。虚拟卡有时在图中被称为“V卡”。

作为背景，安全元件通常由分配安全元件给移动设备的移动电话运营商管理。其部分用于维持在安全元件内运行的各应用软件的安全性。部分被管理的服务包括直接发送应用软件至安全元件中，或者许可第三方组织布置其应用软件在特定的安全元件上。被管理的服务通常使用行业上称为可信服务管理(TSM)的进行传送。

安全元件内存储和运行的所有应用软件例如单独的“软件式支付卡”需要它们自己的储存空间。支付卡由卡发行方发行给消费者。将软件式支付卡布置在移动电话上需要移动电话运营商和卡发行方之间高水平的合作，其中移动电话运营商向发行方提供对单独安全元件的访问，一次一个。只有来自具有基础构架和与移动电话运营商有协定的卡可在移动电话上传送和用于无接触式支付。这对于卡发行方和持卡者都是有限制的。

也应认识到，从用户的角度，将其移动设备与其要用于无接触式支付的资金卡相关联的过程非常依赖于预先安排的移动电话运营商和卡发行方之间的关系。因此，当确定其现有的资金卡能否与其移动电话相关联用于无接触式支付时，用户的选择有限或者没有选择。例如，用户具有来自资金卡发行方A的资金卡。用户也具有来自移动电话运营商B的NFC可用的移动电话。然而，移动电话运营商B仅具有与资金卡发行方B的促进无接触式支付的预先安排的协定和基本构架。因此即使用户想要使用其移动电话进行无接触式支付，用户也不能够，因为移动电话运营商B和资金卡发行方A之间没有预先安排的协定和基本构架来发行软件式支付卡到用户电话中。这限制了用户用其移动设备进行NFC型支付的能力。

在另一个示例实施方式中，支付卡动态数据是循环的卡认证值(CVV，有时也称为动态CVV或dCVV)。该循环的CVV可基于卡内集成电路提供变化的信息计算。在另一个示例实施方式中，动态数据是动态的EMV数据，其使用资金卡的随机数据、商场销售点终端机的随机数据或二者计算。动态数据的一般执行使用卡上的应用交易计数器(ATC)，以便每一交易产生不同的数据流。这在ATC对于进行的每一交易增加1时实现。

也应认识到，特定于给定的资金卡的卡应用软件可安装在移动设备上并且用于与POS终端交互，如上所述。也应认识到，卡应用软件通常安装在移动设备的安全元件上。通常，每一资金卡具有其自己的相应卡应用软件，其位于移动设备的安全元件上。可理解，因为每一卡应用软件占据安全元件上的存储空间，并且安全元件存储空间通常非常有限，由于存储空间不足，在一些情况下在安全软件上具有多个卡应用软件是不可能的。作为背景，安全元件可具有本来的操作***，其被编程以进行各种任务和活动，包括例如仿真资金卡的磁条数据的卡应用软件，或者仿真用于EMV无接触式支付的数据的卡应用软件。也作为背景，并且举例而言，典型的安全元件具有256kB的内存，每一卡应用软件可使用40-80kB的内存。因此，可以理解，关联多个资金卡(和每个其卡应用软件)与移动设备已进行NFC支付可能是有限制的。

因此期望减少安全元件上卡应用软件需要的所需存储空间的量，以便不限制用户可以装到安全元件上的软件式支付卡的数量。同样，期望移动电话运营商减少安全元件上“卡应用软件”使用的数据的量，使得其他类型的应用软件可以装在其上。也期望减少资金卡发行方发行和操作软件式支付卡到安全元件中引起的费用。作为背景，移动电话运营商通常付费给应用软件提供者例如资金卡发行方以在安全元件上使用存储空间量。也期望减少资金卡发行方发行软件式支付卡给移动电话所需的基础构架的量。也期望减少资金卡发行方和移动电话运营商之间发行软件式支付卡在具体移动电话上所需的合作量。也期望实现用户(例如持卡者)下载任何的以及他们想要的那么多的资金卡到其NFC可用的移动电话上，而与具有基础构架的资金卡发行方或者与特定的移动电话运营商的商业关系和协定无关。也期望实现用户(例如持卡者)下载任何的以及他们想要的那么多的资金卡到其NFC可用的移动电话上，而与具有基础构架的资金卡发行方或者与特定的移动电话运营商的商业关系和协定无关。也期望促进两个用户之间以两方方式使用他们的NFC可用的移动设备进行金钱转移。

本文所述的***和方法也允许基于云的钱包支付口服务器与接收者的NFC可用的移动设备和应用软件同步以促进从发送者的NFC可用的移动设备无接触式转移价值。发送者用户通过其移动设备选择资金卡和提供进行无接触式两方价值转移的量。第二卡，本文称为虚拟卡，与所有需要的卡数据一起产生(例如PAN、有效期、动态数据、酌定数据等)，以促进两方支付交易。在支付口服务器，虚拟卡暂时与资金卡和要转移的价值允许量相关联。发送用户发送虚拟卡数据和要转移的量至接收用户(例如通过NFC或其他通信手段)。接收用户发送该数据至支付口服务器并验证虚拟卡数据。如果得到验证，支付口服务器搜索资金卡细节并用其转移指定量从资金卡到新预付虚拟卡。预付虚拟卡可由接收用户用于进行支付、交易、两方转移等。

转向图25，显示使用虚拟卡促进两方资金转移的***的组件的示例实施方式。图25类似于图19，然而不同在于暂时数据关联1905包括虚拟卡(例如虚拟卡1)2501，其暂时与用户资金卡505之一关联。虚拟卡1101可由发送用户101用于进行两方价值转移。

转向图26和27，提供示例计算机可执行或处理器执行的指令，其用于促进发送用户和接收用户之间的两方资金转移。图26和27类似于图23和24，但使用虚拟卡而不是转移ID。因此，在图26和27的讨论中不再重复类似的元件或步骤。

假定发送者移动设备已进行注册过程，其包括提供PIN。该过程的实例在后面关于图28描述。

转向图26，进行方框2301至2308。在收到请求2308后，基于移动设备502发送的信息，支付口服务器404形成和计算关于虚拟卡的细节(方框2601)。具体地，支付口服务器506包括虚拟PAN、虚拟卡有效期和其他形成第二磁轨数据的数据。注意，第二磁轨数据包括PAN、服务代码、有效期、酌定数据和LRC等等。在一个示例实施方式中，支付口服务器506此时不计算本质上是动态的酌定数据(例如酌定数据是动态数据)。虚拟卡细节可进一步包括内部有效期，其仅支付口服务器知晓，并且具有从形成虚拟卡日起大约几天的短时间范围。内部有效期不同于虚拟卡有效期，内部有效期的功能是提供额外的指示给支付口，以确定虚拟卡是否已经过期。支付口服务器506加密虚拟卡数据，这不包括内部有效期，并且发送加密的虚拟卡有效载荷至移动设备的支付应用软件620(方框2602)。

作为替代的示例实施方式，不是支付口服务器506发送虚拟卡PAN作为加密的虚拟卡有效载荷的一部分至移动设备，而是支付口服务器506发送密钥值(称为Kpan)，移动设备可使用该密钥值产生与支付口服务器506计算的相同的虚拟卡PAN。该实例在图29中描述。

在一个示例实施方式中，虚拟卡PAN的位数的第一部分是静态的，并且指支付口服务器506。例如，前六位指支付口服务器506；商场或支付网络或其他任何实体可使用该信息发送交易和支付细节至支付口服务器506。

在一个示例实施方式中，虚拟卡PAN是十九位长，并且符合算法LUHN-10。该算法也称为“模数10”或“mod 10”算法，是用于确认各种识别号例如***的校验公式。如上所述，前六位用于识别支付口服务器。其余位可用多种方式计算。在一个示例实施方式中，虚拟卡PAN其余位随机产生。在另一个示例实施方式中，其余位使用Kpan值计算；图29中描述了这方面的进一步细节。可用其他方法计算虚拟卡PAN。移动设备501接收加密的虚拟卡有效载荷，它解密该加密的通信并且提取虚拟卡细节(例如虚拟卡PAN和其他卡细节)。

在另一个示例实施方式中，如果虚拟卡有效载荷包括Kpan(例如密钥值)而不是虚拟卡PAN，移动设备501使用Kpan计算虚拟卡PAN。

继续图26，移动设备501上的支付应用软件620显示请求发送用户输入其PIN的GUI(例如其应该是发送用户注册服务时提供的同一PIN)(方框2603)。应用软件620从发送用户接收PIN(例如发送用户输入PIN)(方框2604)。应用软件620使用PIN计算虚拟卡的酌定数据(方框2605)。下面关于图30描述计算酌定数据的示例实施方式。用计算的酌定数据，完成第二磁轨数据组。移动设备的支付应用软件620然后显示请求用户用接收者移动设备1901点击发送者移动设备402的消息(方框2311)。发送用户101告知接收用户1807准备接收资金(方框2312)。

在一个示例实施方式中，所有与移动设备相关的资金卡可使用一个PIN。在另一个示例实施方式中，对每一资金卡，注册过程可请求特定的PIN。换言之，如果用户选择不同的资金卡，用户需要输入不同的PIN。

在一个示例实施方式中，移动设备的支付应用软件620不验证PIN。相反，当验证虚拟卡数据组时PIN间接或隐蔽地由支付口服务器506验证。换言之，支付口服务器506使用注册时储存的PIN计算虚拟卡数据组，并且如果在交易期间用户或对手提供不正确的PIN，将使计算的虚拟数据导致与支付口服务器计算的虚拟卡数据相比不同的不正确的值。将收到的虚拟卡数据组与支付口服务器预测的值比较之后，可检测无效的PIN输入。当支付口服务器接收并验证虚拟卡数据组以及检测到未预期的虚拟卡数据组时(例如由于不正确的PIN)，则价值转移授权可被拒绝。

转向图27，在发送用户告知接收用户准备后，接收用户启动接收者移动设备1901上的支付应用软件(方框2401)。进行方框2401-2406，使得两个用户的移动设备一起点击其电话以通过NFC转移数据。

这种点击(或更具体地紧密靠近移动设备)激发发送者移动设备501在移动设备的安全元件622上发送授权的量和虚拟卡的第二磁轨数据(方框2701)。移动设备501设计第二磁轨数据以仿真虚拟卡，并且提供该仿真的虚拟卡数据和授权的量至移动设备的NFC子***609(方框2702)。该仿真的虚拟卡数据包括完整的第二磁轨数据组。要转移的量和虚拟卡数据然后通过NFC转移至接收用户的移动设备1901(方框2703)。在另一个示例实施方式中，虽然未显示，移动设备501的操作***可直接转移信息至NFC子***609而不使用安全元件。虚拟卡数据组在第二磁轨数据组中包括虚拟卡PAN、有效期、酌定数据和所有其他元素以完成标准的无接触式价值转移。

继续图27，在接收者移动设备1901从发送者移动设备501收到虚拟卡数据和授权的量之后，移动设备1901将其发送至支付口服务器506(方框2704)。支付口506验证虚拟卡数据和授权的量(方框2705)，如果数据被成功验证，则支付口服务器506搜索与发送者的虚拟卡相关联的资金卡细节(方框2706)。

为了验证从发送者移动设备收到的虚拟卡数据，支付口服务器自己计算第二磁轨数据组。该第二磁轨数据计算包括支付口服务器使用在发送用户注册期间最初收到和存储的PIN计算酌定数据。在一个示例实施方式中，第二磁轨数据部分的一些(如PAN和有效期)被预先计算并储存；这些预先计算的数据部分可与收到的第二磁轨数据比较。如果虚拟卡数据被成功验证(收到的卡第二磁轨数据组与支付口服务器计算的卡第二磁轨数据组匹配)，则支付口服务器搜索与虚拟卡数据相关联的资金卡数据。

在方框2705验证虚拟卡数据可包括验证与虚拟卡相关联的内部有效期是否已过。如果验证当日在内部有效期之前或当天发生，则虚拟卡可被认为通过验证并且交易过程可继续。如果得到验证，支付口服务器506搜索资金卡细节2706。否则虚拟卡被认为无效，并且价值转移授权请求被拒绝。

当验证后，支付口服务器506然后产生价值转移授权支付请求，其包括资金卡细节和要转移至接收用户1807的量(方框2707)。虽然未显示，支付口服务器506然后发送该标准支付授权请求至资金卡发行服务器104。资金卡发行服务器104验证支付授权请求(例如验证足够的资金可用、验证资金卡数据等等)并提供支付授权响应至支付口服务器506。该响应指示价值转移是被接收还是拒绝。

假定接受了使用资金卡的支付，支付口服务器506标记发送者的虚拟卡为正使用(方框2708)。注意，虚拟卡是一次性使用。换言之，当发送者希望进行另一两方转移时，新的(例如不同的)虚拟卡将为另一两方转移形成，即使使用相同的资金卡和量。以此方式，安全性增加，并且接收用户永远不会得到发送用户资金卡的细节。

支付口服务器506计算要发行至接收用户的预付虚拟卡以及与之相关的细节(方框2709)。

产生预付虚拟卡后，进行方框2414、2415、2416和2417。这些在前面关于图24已描述。

转向图28，提供计算机可执行或处理器执行的指令的示例实施方式，其用于通过支付口服务器注册资金卡和移动设备。这样的实施方式可与本文所述原理结合使用。发送者移动设备发送注册请求至支付口服务器(方框2801)。该请求包括移动设备的设备ID、用户提供的PIN以及资金卡细节。在收到该请求后，支付口服务器发送注册响应至发送者移动设备(方框2802)。该响应包括证书、应用交易计数器(ATC)、用于产生PAN的密钥值(称为Kpan)、安全元件密钥值(称为Ksec)、以及识别资金卡的资金卡识别符。该证书是发送者移动设备的客户证书，并且在一个示例实施方式中，其根据RSA算法配置，并具有2048字节长。ATC是最初设定为“0”或“1000”之间的随机值且每次交易增加的计数器。初始ATC值是随机值以防止对手预测ATC值。存储ATC的备份，并且同步在支付口服务器和移动设备上。在一个示例实施方式中，ATC是10位值。在一个示例实施方式中，Kpan是128字节长和Ksec是128字节长。

支付口服务器404存储来自相互关联的注册请求和注册响应的数据(方框2803)。发送者移动设备402也存储来自注册响应的数据(方框2804)。

转向图29，提供计算机可执行或处理器执行的指令的一个示例实施方式，其用于计算虚拟卡数据。该实施方式可结合上述的计算虚拟卡数据的原理使用。发送者移动设备发送虚拟卡请求至支付口服务器(方框2901)。该请求包括设备ID、资金卡识别符、证书和储存的Kpan。储存的Kpan可来自注册或来自以前的交易。

支付口服务器确定收到的Kpan和证书是否匹配于与支付口服务器数据库中存储的设备ID相关联的存储在支付口服务器(方框2902)上的Kpan和证书。如果是，则支付口服务器发送虚拟卡响应至发送者移动设备，其包括新的Kpan(方框2903)。对于每次交易，使用新的Kpan产生新的或不同的PAN，并且也防止再次攻击。支付口服务器使用新的Kpan计算虚拟卡的PAN(方框2904)。该新的Kpan和预先计算的PAN由支付口服务器储存，以后使用(方框2905)。

在移动设备收到新的Kpan后，它用新的Kpan替代储存的Kpan(方框2906)。它使用新的Kpan计算虚拟卡PAN，方式同支付口服务器计算PAN(方框2907)。如果条件和数据正确，虽然移动设备独立于支付口服务器计算PAN，但移动设备计算的PAN应与支付口服务器计算的PAN相同。

然后移动设备使用PIN、Ksec、PAN、证书和ATC计算酌定数据(其是第二磁轨数据的一部分)(方框2908)。ATC和PAN保持每次交易都改变，这使得酌定数据是动态数据。

移动设备将ATC增加1(方框2909)。

具体地，PAN由移动设备和支付口服务器根据下述计算：

PAN＝BIN(6)+SHA256[Kpan](12)+Luhn(1)

其中BIN(6)是6位二进制数，以识别支付口服务器；

SHA256[Kpan](12)是12位数，通过取Kpan值的sha256、进一步包括将sha256值转化为小数并从散列值截断为12位而产生；

和Luhn(1)是单一位，用于保证虚拟卡总通过LUHN算法。

将上述值连起来形成PAN。上述计算中符号“+”指连接操作。

酌定数据使用下述计算：

酌定数据＝HMAC_SHA256[Ksec+PIN,M](10)

其中M＝连接(PAN、证书ID、ATC)

通过以小数编码SHA结果，然后取最左位数，进行截断。可理解，SHA256是已知的密码杂凑函数(cryptographic hash function)，HMAC是散列式消息授权码，包括与秘密密钥(secret cryptographic key)结合的密码杂凑函数。HMAC函数的秘密密钥是Ksec和PIN的连接值。消息M是PAN、证书ID和ATC的连接值。证书ID来自证书。

转向图30，提供了计算机可执行或处理器执行的指令的一个示例实施方式，用于验证虚拟卡数据，并且具体地是提供酌定数据(例如动态数据)的支付口服务器验证。这种实施方式可结合本文所述的验证虚拟卡数据的原理使用。这可以是图26中所述过程的继续。

发送者移动设备501发送虚拟卡至接收者移动设备1901(方框3001)。接收者移动设备1901然后形成和发送价值转移授权请求至支付口服务器506(方框3002)。价值转移授权请求包括虚拟卡的PAN和酌定数据等等，如发送者移动设备计算的。也包括要从发送者转移到接收者的金钱或资金的量。

在收到请求后，支付口服务器506使用PAN找到相关的储存的相关联数据(例如Kpan、证书、Ksec、资金卡识别符、设备ID和其他用户数据)。该相关的储存的相关联数据由充当索引的预先计算的PAN识别。换言之，将收到的PAN与许多预先计算的PAN比较，如果发现与给定的预先计算的PAN匹配，则与该给定的预先计算的PAN相关联的储存数据被认为是相关的储存的相关联数据。

支付口服务器506使用该相关的储存的相关联数据计算其自身的酌定数据。这可包括使用PIN(用户注册过程中接收的)、储存的Ksec、来自储存的证书的证书ID和ATC的增加值ATC(方框3003)。

支付口自身的酌定数据的计算使用下述：

酌定数据＝HMAC_SHA256[Ksec+PIN,M](10)

其中M＝连接(PAN、证书ID、(ATC+1))

ATC+1表示增加的ATC值。

支付口服务器506确定其自身的酌定数据是否等于收到的酌定数据(方框3004)。如果它们不相等，支付口服务器进一步将ATC增加“1”并重新计算其身的酌定数据(方框3005)。该过程返回方框3004组是否相等。涉及方框3005的过程可重复，使得每次ATC值进一步增加1。这可进行至多某一次数(例如10次)，之后交易过程停止。

如果ATC值的范围(例如ATC+1和ATC+10之间)没有产生相同的酌定数据组，则验证不成功。该范围用于解释这样的可能性：移动设备的ATC计数器可能已经增加而没有通知支付口服务器。因此，使用缓冲或范围或ATC值。

如果支付口服务器自身的酌定数据与收到的酌定数据相同，则支付口服务器用计算其自身的酌定数据中使用的现在增加的ATC值代替前面的ATC值(方框3006)。以此方式，支付口服务器中存储的ATC值现在应等于移动设备上存储的ATC值。这导致授权请求被接受并且因此支付口服务器为接收者移动设备发行虚拟预付卡。

注意，如果移动设备用来酌定数据的PIN被用户不正确地输入(例如不同于注册时提供的PIN)，则来自移动设备的酌定数据将不等于支付口服务器自身的酌定数据。这是因为支付口服务器自身的酌定数据使用注册时提供的PIN计算。以此方式，用户在每次交易过程中提供到移动设备中的PIN通过支付口服务器隐藏地验证。

继续图30，在数据验证成功或不成功以后，支付口服务器最终通过发送响应至接收者移动设备响应接收者移动设备1901。该响应可表示转移被拒绝，或者可表示虚拟预付卡已经发行。

具体地，按照方框3005，存在一个重复上限，当达到时其表示酌定数据验证不成功。如果验证不成功，则将拒绝的转移响应发送至接收者移动设备1901(方框3008)。如果验证成功，如上所述，启动发行虚拟预付卡的过程，并传送至接收者移动设备1901(方框3007)。

因此可理解，发送用户可以以多种方式，包括使用转移ID或虚拟卡转移价值至接收用户。成功转移的结果是接收用户具有预付虚拟卡。

在一个示例实施方式中，在接收用户收到预付虚拟卡后，接收用户可使用预付虚拟卡与商场进行支付。例如，预付虚拟卡可用于使用POS终端502或电子商务以及互联网基础界面1301进行支付。

本文所述的方法和***可用于任何类型的资金卡。发送者的资金卡和移动设备预先注册于支付口服务器506。这种注册不依赖任何特定的移动电话运营商和任何特定的资金***发行方。结果，为了使用移动设备促进无接触式(例如NFC)支付，在移动电话运营商和资金卡发行方之间不需要商业协定和额外的基础构架。这又减少了资金卡发行方发行软件卡至移动设备引起的费用。

在一个示例实施方式中，提供服务器进行的促进两方价值转移的方法。该方法包括：从发送者移动设备接收消息，以使用资金卡识别符转移指定的量；针对与资金卡识别符相关联的资金卡细节和量，检索与发送者移动设备相关联的多个卡的数据库；产生转移ID并将转移ID与资金***和指定的量相关联；发送转移ID至发送者移动设备；从接收者移动设备接收价值转移授权请求，该请求包括转移ID；基于该转移ID，识别资金***和授权的量；发送支付授权请求至资金卡发行方，该请求包括资金***和指定的量；从资金卡发行方接收支付授权响应；以及发送价值转移授权响应在接收者移动设备。

在一个示例方面，该方法进一步包括：如果价值转移授权响应为正值，形成与接收者移动设备相关联的预付虚拟卡并具有指定的量。

在另一个示例实施方式中，提供一种服务器进行的促进两方价值转移的方法。该方法包括：从发送者移动设备接收消息，识别资金卡和量；针对与识别的资金卡相关联的资金卡细节和量，检索与发送者移动设备相关联的多个卡的数据库；计算虚拟卡的数据，该数据包括***和有效期；储存于资金***相关联的虚拟***的数据；发送虚拟卡的数据至发送者移动设备；使用PIN作为输入计算卡细节；从接收者移动设备接收价值转移授权请求，该请求包括虚拟卡的数据和请求的价值转移量；基于虚拟卡的数据和量搜索资金卡细节；发送支付授权请求至资金卡发行方，该请求包括资金***和请求的支付量；从资金卡发行方接收支付授权响应；以及发送价值转移授权响应至接收者移动设备。

本文所述的流程图中的步骤或操作仅仅是举例。对于这些步骤或操作可能存在许多变化，而不背离本发明的精神。例如，可以不同顺序进行所述步骤，或者可增加、删除或修改所述步骤。

虽然在本文与显示的示例实施方式一起阐释了本发明的基本原理，但本领域技术人员将理解，对公开的布置——其细节和这些细节的组织——可进行改变，而不背离其精神和范围。因此，前述公开和附图中进行的显示意欲仅仅被看作是本发明原理的示例，而不以限制性意义解释。

Claims (42)

1.一种计算机执行的方法，包括：

在支付口服务器处注册资金卡，所述注册包括：

储存资金***；以及

储存个人识别号，该个人识别号与访问所述资金卡相关联；

从移动设备接收表示期望使用注册的资金卡进行支付的消息；

在所述支付口服务器处至少使用所述个人识别号计算虚拟卡的数据，其中所述虚拟卡的数据包括不同于所述资金***的虚拟***，并且还包括磁轨数据，所述磁轨数据包括来自所述资金卡的第二磁轨数据的酌定数据；

与所述资金***相关联储存所述虚拟卡的数据；

发送与所述虚拟卡的数据相关的信息至所述移动设备，所述发送包括将所述信息而不是所述个人识别号也不是所述酌定数据发送至所述移动设备；

从商场或商场收单方接收第一支付授权请求，所述第一支付授权请求包括请求的支付量、以及由所述移动设备基于所述与所述虚拟卡的数据相关的信息和用户输入的所述个人识别号计算出并从所述移动设备提供的虚拟卡数据组；

将与所述第一支付授权请求一起收到的所述虚拟卡数据组与在所述支付口服务器处计算的所述虚拟卡的数据比较；

基于所述比较，发送通知至所述移动设备，所述通知指示所述支付授权是被接受还是被拒绝；

在所述虚拟卡数据组与所述虚拟卡的数据匹配的情况下，基于所述虚拟卡的数据，搜索所述资金***；

发送第二支付授权请求至资金卡发行方，所述第二支付授权请求包括所述资金***和所述请求的支付量；

从所述资金卡发行方接收支付授权响应；和

发送所述支付授权响应至所述商场或所述商场收单方。

2.根据权利要求1所述的计算机执行的方法，其中注册资金卡的步骤进一步包括：

产生资金卡识别符；

与所述资金***相关联储存所述资金卡识别符；和

发送所述资金卡识别符至所述移动设备。

3.根据权利要求2所述的计算机执行的方法，其中从移动设备接收表示期望使用注册的资金卡进行支付的消息的步骤包括接收与注册的资金卡相关联的所述资金卡识别符。

4.根据权利要求1所述的计算机执行的方法，其中注册资金卡的步骤进一步包括储存与所述资金卡相关联的资金卡有效期，并且进一步包括：

发送通知至所述移动设备，所述通知指示对于在所述资金卡有效期之后收到的所有第二支付授权请求，所述第二支付授权请求被拒绝。

5.根据权利要求4所述的计算机执行的方法，其中所述虚拟卡的数据进一步包括虚拟卡有效期，并且进一步包括：

发送通知至所述移动设备，所述通知指示对于在所述虚拟卡有效期之后收到的所有第一支付授权请求，所述第一支付授权请求被拒绝。

6.根据权利要求5所述的计算机执行的方法，其中所述虚拟卡有效期与所述资金卡有效期相同。

7.根据权利要求5所述的计算机执行的方法，其中所述虚拟卡有效期与所述资金卡有效期不同。

8.根据权利要求7所述的计算机执行的方法，其中所述虚拟卡有效期是在计算所述虚拟卡的数据之后预先确定的天数。

9.根据权利要求1所述的计算机执行的方法，其中所述虚拟卡的数据用于单次支付。

10.根据权利要求1所述的计算机执行的方法，其中所述虚拟卡的数据用于多次支付。

11.根据权利要求1所述的计算机执行的方法，其中所述虚拟卡的数据以加密形式发送至所述移动设备。

12.根据权利要求1所述的计算机执行的方法，其中发送与所述虚拟卡的数据相关的信息至所述移动设备的步骤包括将加密密钥值发送至所述移动设备，所述加密密钥值允许所述移动设备确定所述虚拟卡的数据。

13.根据权利要求1所述的计算机执行的方法，其中所述虚拟***的至少一部分识别所述第一支付授权请求的接收者。

14.根据权利要求1所述的计算机执行的方法，其中所述虚拟***的后四位与所述资金***的后四位相同。

15.一种用于促进交易的***，包括：

计算机可读介质，其上储存有指令；和

处理器，其配置来执行所述指令以进行操作，所述操作包括：

在所述***处注册资金卡，所述注册包括：

储存资金***；以及

储存个人识别号，该个人识别号与访问所述资金卡相关联；

从移动设备接收表示期望使用注册的资金卡进行支付的消息；

在所述***处至少使用所述个人识别号计算虚拟卡的数据，其中所述虚拟卡的数据包括不同于所述资金***的虚拟***，并且还包括磁轨数据，所述磁轨数据包括来自所述资金卡的第二磁轨数据的酌定数据；

与所述资金***相关联储存所述虚拟卡的数据；

发送与所述虚拟卡的数据相关的信息至所述移动设备，所述发送包括将所述信息而不是所述个人识别号也不是所述酌定数据发送至所述移动设备；

从商场或商场收单方接收第一支付授权请求，所述第一支付授权请求包括请求的支付量、以及由所述移动设备基于所述与所述虚拟卡的数据相关的信息和用户输入的所述个人识别号计算出并从所述移动设备提供的虚拟卡数据组；

将与所述第一支付授权请求一起收到的所述虚拟卡数据组与在所述处理器处计算的所述虚拟卡的数据比较；

基于所述比较，发送通知至所述移动设备，所述通知指示所述支付授权是被接受还是被拒绝；

在所述虚拟卡数据组与所述虚拟卡的数据匹配的情况下，基于所述虚拟卡的数据，搜索所述资金***；

发送第二支付授权请求至资金卡发行方，所述第二支付授权请求包括所述资金***和所述请求的支付量；

从所述资金卡发行方接收支付授权响应；和

发送所述支付授权响应至所述商场或所述商场收单方。

16.根据权利要求15所述的***，其中注册资金卡的步骤进一步包括：

产生资金卡识别符；

与所述资金***相关联储存所述资金卡识别符；和

发送所述资金卡识别符至所述移动设备。

17.根据权利要求16所述的***，其中从移动设备接收表示期望使用注册的资金卡进行支付的消息的步骤包括接收与注册的资金卡相关联的所述资金卡识别符。

18.根据权利要求15所述的***，其中注册资金卡的步骤进一步包括储存与所述资金卡相关联的资金卡有效期，并且进一步包括：

发送通知至所述移动设备，所述通知指示对于在所述资金卡有效期之后收到的所有第二支付授权请求，所述第二支付授权请求被拒绝。

19.根据权利要求18所述的***，其中所述虚拟卡的数据进一步包括虚拟卡有效期，并且进一步包括：

发送通知至所述移动设备，所述通知指示对于在所述虚拟卡有效期之后收到的所有第一支付授权请求，所述第一支付授权请求被拒绝。

20.根据权利要求19所述的***，其中所述虚拟卡有效期与所述资金卡有效期相同。

21.根据权利要求19所述的***，其中所述虚拟卡有效期与所述资金卡有效期不同。

22.根据权利要求21所述的***，其中所述虚拟卡有效期是在计算所述虚拟卡的数据之后预先确定的天数。

23.根据权利要求15所述的***，其中所述虚拟卡的数据用于单次支付。

24.根据权利要求15所述的***，其中所述虚拟卡的数据用于多次支付。

25.根据权利要求15所述的***，其中所述虚拟卡的数据以加密形式发送至所述移动设备。

26.根据权利要求15所述的***，其中发送与所述虚拟卡的数据相关的信息至所述移动设备的步骤包括将加密密钥值发送至所述移动设备，所述加密密钥值允许所述移动设备确定所述虚拟卡的数据。

27.根据权利要求15所述的***，其中所述虚拟***的至少一部分识别所述第一支付授权请求的接收者。

28.根据权利要求15所述的***，其中所述虚拟***的后四位与所述资金***的后四位相同。

29.一种用于促进交易的***，所述***包括：

用于注册资金卡的装置，所述注册资金卡包括储存资金***以及储存个人识别号，该个人识别号与访问所述资金卡相关联；

用于从移动设备接收表示期望使用注册的资金卡进行支付的消息的装置；

用于至少使用所述个人识别号计算虚拟卡的数据的装置，其中所述虚拟卡的数据包括不同于所述资金***的虚拟***，并且还包括磁轨数据，所述磁轨数据包括来自所述资金卡的第二磁轨数据的酌定数据；

用于与所述资金***相关联储存所述虚拟卡的数据的装置；

用于发送与所述虚拟卡的数据相关的信息至所述移动设备的装置，所述发送包括将所述信息而不是所述个人识别号也不是所述酌定数据发送至所述移动设备；

用于从商场或商场收单方接收第一支付授权请求的装置，所述第一支付授权请求包括请求的支付量、以及由所述移动设备基于所述与所述虚拟卡的数据相关的信息和用户输入的所述个人识别号计算出并从所述移动设备提供的虚拟卡数据组；

用于将与所述第一支付授权请求一起收到的所述虚拟卡数据组与在用于计算虚拟卡的数据的装置处计算的所述虚拟卡的数据比较的装置；

用于基于所述比较，发送通知至所述移动设备的装置，所述通知指示所述支付授权是被接受还是被拒绝；

用于在所述虚拟卡数据组与所述虚拟卡的数据匹配的情况下，基于所述虚拟卡的数据，搜索所述资金***的装置；

用于发送第二支付授权请求至资金卡发行方的装置，所述第二支付授权请求包括所述资金***和所述请求的支付量；

用于从所述资金卡发行方接收支付授权响应的装置；和

用于发送所述支付授权响应至所述商场或所述商场收单方的装置。

30.根据权利要求29所述的***，其中用于注册资金卡的装置进一步包括：

用于产生资金卡识别符的装置；

用于与所述资金***相关联储存所述资金卡识别符的装置；和

用于发送所述资金卡识别符至所述移动设备的装置。

31.根据权利要求30所述的***，其中用于从移动设备接收表示期望使用注册的资金卡进行支付的消息的装置包括用于接收与注册的资金卡相关联的所述资金卡识别符的装置。

32.根据权利要求29所述的***，其中用于注册资金卡的装置进一步包括用于储存与所述资金卡相关联的资金卡有效期的装置，并且进一步包括：

用于发送通知至所述移动设备的装置，所述通知指示对于在所述资金卡有效期之后收到的所有第二支付授权请求，所述第二支付授权请求被拒绝。

33.根据权利要求32所述的***，其中所述虚拟卡的数据进一步包括虚拟卡有效期，并且进一步包括：

用于发送通知至所述移动设备的装置，所述通知指示对于在所述虚拟卡有效期之后收到的所有第一支付授权请求，所述第一支付授权请求被拒绝。

34.根据权利要求33所述的***，其中所述虚拟卡有效期与所述资金卡有效期相同。

35.根据权利要求33所述的***，其中所述虚拟卡有效期与所述资金卡有效期不同。

36.根据权利要求35所述的***，其中所述虚拟卡有效期是在计算所述虚拟卡的数据之后预先确定的天数。

37.根据权利要求29所述的***，其中所述虚拟卡的数据用于单次支付。

38.根据权利要求29所述的***，其中所述虚拟卡的数据用于多次支付。

39.根据权利要求29所述的***，其中所述虚拟卡的数据以加密形式发送至所述移动设备。

40.根据权利要求29所述的***，其中用于发送与所述虚拟卡的数据相关的信息至所述移动设备的装置包括用于将加密密钥值发送至所述移动设备的装置，所述加密密钥值允许所述移动设备确定所述虚拟卡的数据。

41.根据权利要求29所述的***，其中所述虚拟***的至少一部分识别所述第一支付授权请求的接收者。

42.根据权利要求29所述的***，其中所述虚拟***的后四位与所述资金***的后四位相同。