算的PAN识别，预先计算的PAN充当检索服务器数据库的索引。换言之，将收到的PAN与许多预先计算的PAN比较，如果发现与给定的预先计算的PAN匹配，则与该给定的预先计算的PAN相关联的存储数据被认为是相关的存储的关联数据。
[0167]支付口服务器506使用相关的存储的关联数据计算其自身的酌定数据。这可包括使用PIN(在用户注册过程中收到)、存储的Ksec、来自存储的证书的证书ID和ATC的渐增值(方框1203) ο
[0168]计算支付口自身的酌定数据使用下述:
[0169]酌定数据=HMAC_SHA256[Ksec+PIN, Μ] (10)
[0170]其中M =连接(PAN、证书 ID、(ATC+1))
[0171]ATC+1表示渐增的ATC值。
[0172]支付口服务器506确定其自身的酌定数据是否等于收到的酌定数据(方框1204)。如果它们不等，支付口服务器进一步将ATC增加“ I ”并重新计算其自身的酌定数据(方框1205)。该过程返回方框1204以检查酌定数据组是否相等。可重复包括方框1205的过程，以便每次ATC值都进一步增加I。这可进行直到某次数(例如10次)，其后停止交易过程。
[0173]如果APC值的范围(例如ATC+1和ATC+10之间)不产生相等的酌定数据组，则该验证不成功。该范围用于解释这样的可能性:移动设备的ATC计数器可能已经增加而没有通知支付口服务器。因此，使用缓冲或范围或ATC值。
[0174]如果支付口服务器自身的酌定数据与收到的酌定数据相同，则支付口服务器用计算其自身的酌定数据中使用的现在增加的ATC值代替前面的ATC值。以此方式，支付口服务器中存储的ATC值现在应等于移动设备上存储的ATC值。
[0175]注意，如果移动设备用来酌定数据的PIN被用户不正确地输入(例如不同于注册时提供的PIN)，则来自移动设备的酌定数据将不等于支付口服务器自身的酌定数据。这是因为其自身的酌定数据使用注册时提供的PIN计算。以此方式，用户在每次交易过程中提供到移动设备中的PIN通过支付口服务器隐藏地验证。
[0176]继续图12，在数据验证成功或不成功以后，支付口服务器最终通过发送授权响应至商场(103、502)响应至商场(方框1207)。为了更清楚，如果酌定数据验证不成功(根据方框1205在达到某一重复后)，则发送负支付授权响应至商场(方框1207)。
[0177]本文所述的方法和系统不依赖于在移动设备的安全元件上存储有软件式支付卡来促进无接触式支付交易。这是因为PAN以及资金卡的其他卡数据元素未存在在移动设备中。而是，资金卡PAN和有效期存储在安全服务器(例如支付口服务器)上。而且，虚拟卡数据在安全服务器上形成，并且对于具体移动设备加密。进一步，第二磁轨数据中的酌定数据是每次支付重新输入的PIN的函数。虚拟卡数据只在进行支付时发生，并且可仅用一次。此外，只有服务器可验证虚拟卡数据。换言之，对手不能通过移动设备上的简单算法(bruteforce)进入而不被发现。
[0178]进一步，虚拟卡加密的有效载荷不能再用。这是因为只要卡被用一次，它不能再被任何其他方使用。
[0179]也注意，在一些示例实施方式，在商场的支付授权之前实时形成一次性虚拟卡。
[0180]进一步，资金卡细节从来不提供给商场，因为是提供虚拟卡细节。
[0181]本文所述的方法和系统与标准的四方卡支付模式和系统兼容。资金卡发行方、商场、收单方或支付网络无需改变系统。
[0182]本文所述的方法和系统也允许使用“单一应用软件”，用于支持一个或多个虚拟卡以及一个或多个资金卡。这减少了安全元件上需要的存储(以及通常地移动设备上需要的存储)，以不限制消费者可以装入安全元件的卡数量。
[0183]可理解，本文所述的方法和系统使持卡者(例如终端用户)能够注册任何他们想要进入其NFC可用的移动设备的资金卡，而独立于具有基础构架或与特定移动操作者的商业关系的卡发行方。
[0184]本文所述的方法和系统可用于任何类型的资金卡。资金卡和移动设备预先注册到支付口服务器506。该注册独立于任何特定的移动电话运营商和任何特定的资金卡发行方。因此，使用移动设备促进无接触式支付，移动电话运营商和资金卡发行方不需要商业协定和额外的计算用基础构架。这又减少了资金卡发行方发行软件式支付卡至移动设备引起的费用。
[0185]在一个示例实施方式中，提供了服务器进行的促进支付的方法。该方法包括:接收来自识别资金卡的移动设备的信息；对于与识别的资金卡相关联的资金卡号，检索与移动设备相关联的多个卡的数据库；计算虚拟卡的数据，所述数据包括卡号和有效期；与资金卡号相关联，存储虚拟卡号的数据；发送虚拟卡的数据至移动设备；利用用户PIN作为输入，计算卡细节；从商场收单方接收第一支付授权请求，所述请求包括虚拟卡的数据和请求的支付量；基于虚拟卡的数据搜索资金卡号；发送第二支付授权请求至资金卡发行方，该请求包括资金卡号和所述请求的支付量；从资金卡发行方接收支付授权响应；和发送支付授权响应至商场收单方。
[0186]基于电子商务和互联网的交易
[0187]在提出的系统和方法的另一示例实施方式中，虚拟卡的上述原理也适用于基于电子商务或互联网的交易。换言之，虽然上述实例包括使用与移动设备501相互的物理的POS终端设备502，但基于电子商务或互联网的交易不使用POS终端设备502。而移动设备501可与商场收单方103或支付口服务器506 (例如通过电子商务网页或支付应用软件)通信。换言之，为了执行交易，移动设备使用互联网连接发送虚拟卡数据至商场收单方103或支付口服务器506(例如通过电子商务网页或支付应用软件)。
[0188]例如，可进行包括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浏览。在另一个示例实施方式中，移动设备通过支付应用软件⑶I连接至互联网和电子商务界面1301。
[0189]一般地，上述关于图7、8、9a、9b、10、ll和12描述的实例也用于电子商务交易，但按照图13，POS终端502被互联网和电子商务界面1301代替。
[0190]图14示出电子商务网页或支付应用软件GUI显示的示例图形化用户界面(GUI)。这由移动设备501显示，例如，当用户选择产品、项目或服务以购买时。显示了交易细节1402，其包括例如用户要付的量以及用户姓名。其他信息例如产品ID或用户ID可显示。资金卡信息1403也显示，并且在信用卡的情况下可显示资金卡1404后四位。在一个示例实施方式中，显示缺省资金卡，但可使用控制1407选择不同的资金卡。在图14的实例中，移动设备501将使用与尾数为‘4242’(1404)的Visa资金卡相关联的虚拟卡进行支付。在另一个示例实施方式中，后四位没有显示以防止攻击者看见该信息。
[0191]当显示⑶11401时，为了完成交易，用户输入PIN到区域1405中并选择“现在支付”按钮1406。当⑶11401检测到这些事件时，移动设备501通过互联网和电子商务界面1301发送虚拟资金卡数据到商场收单方103或支付口服务器506。
[0192]在另一个示例实施方式⑶I (未显示)中，未显示“现在支付”按钮1406。例如，GUI能够检测多少字符被输入到输入区域1405中的长度。在GUI检测到在输入区域1405中已经输入所需的字符数后，自动提交PIN。
[0193]在一个示例实施方式中，PIN是资金卡的卡认证值(CVV)、卡安全值(CSV)、卡安全码(CSC)、卡代码认证(CCV)、卡认证码(CVC或CVC2)等，并且该值由资金卡发行方104确定。在另一个示例实施方式中，PIN由用户确定。在另一个示例实施方式中，PIN是密码。在另一个示例实施方式中，PIN是系统“Visa认证(Verified by Visa) ”使用的密码，该系统是补充认证。
[0194]在另一个示例实施方式中，如图15所示，提供另一实例⑶I 1501，其显示交易细节1402、资金卡信息1403和“现在支付”按钮1406。换言之，当显示⑶I 1501时，用户仅需选择“现在支付”按钮1406来执行交易。这使得移动设备501通过互联网和电子商务界面1301发送虚拟资金卡数据至商场收单方103或支付口服务器506。应理解，使用图15的⑶I，不需要PIN。
[0195]转向图16，提供示例处理器执行指令组，其用于采用互联网和电子商务界面1301进行支付。图16类似于图7，所以相似的操作不再详细描述。在方框1601，互联网和电子商务界面请求移动设备在电子商务GUI (例如1401和1501)显示数据。在方框1602，移动设备501显示电子商务⑶I。任选地，但不是必需地，方框703和704由移动设备501进行。进一步，在方框706，移动设备通过电子商务⑶I任选地显示预注册的资金卡，并且用户选择资金卡707。在其他实施方式中，只有一个资金卡，或者有使用的缺省资金卡，除非用户改变。进行在方框708、709、710和711的操作。如上所述，在一些示例实施方式中，可使用以前计算的虚拟卡，并且因此不需要对每一个和每次交易计算新的虚拟卡。
[0196]继续图16，在一个示例实施方式中，电子商务⑶I请求PIN认证(方框712)以及用户提供PIN(713)。然而，在其他实施方式中，不需要提供PIN。也进行方框714和715的操作。然而，在其他实施方式中，如果以前计算的虚拟卡正在使用，不进行方框714和715。
[0197]在一个示例实施方式中，用户通过电子商务⑶I输入命令以执行交易(方框1603) ο例如，用户可选择“现在支付”按钮1406，或者提供一些理解为执行交易的其他输入。
[0198]移动设备发送虚拟卡数据至互联网和电子商务界面(方框1604)，互联网和电子商务界面发送虚拟卡数据至商场收单方103或支付口服务器506 (见图17)。当交易结束(接受或拒绝)，通过互联网和电子商务界面将确认信息发送至移动设备(方框1605)。然后可进行方框722。
[0199]图17显示示例处理器执行指令，其是图16的继续。包括方框1601、1603和1604以显示背景，并且在前面的图16中实施。图17类似于图8，但包括互联网和电子商务界面1301。方框801、802、803、804、805、806、807、808和809的操作适用于图17，不再详细描述，因为这些方框关于图8已详细描述。
[0200]两方价值转移
[0201]在提出的系统和方法的其他实施方式中，下述一般地涉及在移动设备上使用虚拟卡促进两方价值转移。
[0202]移动设备可用于转移价值，例如在两个人之间。移动设备可装备近场通信(NFC)系统，其用于转移支付凭证例如支付卡信息至另一也装备NFC系统的移动设备。
[0203]应认识到，从一个人的移动设备到另一个人的设备转移金钱是困难的，或者更一般地，使用移动设备从一方转移到另一方是困难的。在许多情况下移动电话运营商和资金卡发行方没有计算系统来支持金钱从一个移动设备转移到另一个移动设备，或者对双方而言是成本不允许的。也应认识到，在移动设备之间以安全方式转移金钱、同时仍保持便利是困难的。
[0204]也应认识到，存在这样的情形:发送用户希望转移价值到接收用户，但发送用户不了解或不相信接收用户。例如，发送用户欠接收用户的钱，但不了解或不相信接收用户。使用资金卡转移价值(例如金钱)至接收用户而不用提供关于资金卡的任何数据或信息可能是困难的。进一步，以快捷和便利的方式这样做也使得价值转移困难。
[0205]也应认识到，存在这样的情形:接收用户没有银行账户。换言之，接收用户没有已建立的账户来接收和存储来自发送用户的价值(或资金)。因此，在许多情况下接收用户不能接受或接收来自发送用户的价值(或资金)。
[0206]使用转移ID两方转移价值
[0207]本文所述的方法和系统允许发送者(例如第一人)发送价值，例如金钱，至接收者(例如第二人)。具体地，发送者的NFC可用的移动设备针对接收者的NFC可用的移动设备进行“点击”，进行价值转移，转移的价值与作为预付虚拟卡的接收者移动设备相关联进行存储。接收者然后可以使用其NFC可用的电话用预付虚拟卡进行支付，这通过NFC (例如利用商场的NFC可用的销售点终端机)或通过互联网(例如移动电子商务或电子商务)。
[0208]作为替代的示例实施方式，代替发送虚拟卡，支付口服务器506发送转移ID至给定用户，与接收用户共享。该转移ID由支付口服务器用于识别选择的资金卡和发送用户指定的量。换言之，转移ID被看做是指针，其指向支付口服务器存储的信息以识别选择的资金卡和发送用户指定的量。转移ID的非限制性实例可以是数字、字符集(包括数字)和URL0
[0209]本文所述的系统和方法也允许基于云的钱包支付口服务器与接收者的NFC可用的移动设备和应用软件同步，从促进从发送者的NFC可用的移动设备进行无接触式价值转移。发送者用户选择资金卡并通过其移动设备提供进行无接触式两方价值转移的量。转移ID由支付口服务器产生，以完成两方支付交易。转移ID由支付口服务器用于识别选择的资金卡和发送用户要转移的量。在支付口服务器上，转移ID暂时与资金卡和要转移的允许量相关联。
[0210]当启动两方价值转移时，包括转移ID数据在内的数据通过发送者移动设备上的NFC系统发送至接收者的NFC可用的移动设备。这种信息从接收者移动设备发送至基于云的钱包支付口服务器(也称为“支付口服务器”)。基于云的钱包支付口服务器验证转移IDo如果验证成功，与转移ID相关的发送用户的资金卡细节被搜索和通过支付口服务器发送至资金卡发行方服务器，以完成价值转移授权。资金卡发行方服务器验证资金卡并发送回授权代码至支付口服务器。支付口服务器然后充当虚拟卡发行方服务器并产生预付虚拟卡给接收者用户，其可被接收者移动设备使用。
[0211]当支付口服务器启动结算请求时可结算预付虚拟卡的价值转移，通常在每个工作日结束时结算一次，使用标准方法。这包括搜索在该期间收到的所有资金卡号和相应的授权代码并发送这种信息至资金卡发行方以结算。资金卡发行方验证资金卡号和授权代码，如果验证成功，通过标准的电子资金转移方法，发送金钱回到与支付口服务器相关联的银行账户。与预付虚拟卡账户相关联，存储该金钱。在一个示例实施方式中，虚拟卡发行方是支付口服务器或者支付口服务器内的模块。
[0212]在另一个示例实施方式中，在发送者移动设备发送转移ID至接收者移动设备之前，发送者移动设备请求通过支付口服务器授权给资金卡发行方。在授权完成后，转移ID形成并发送至接收者移动设备。接收者移动设备利用支付口服务器验证转移ID。支付口服务器然后进行与来自转移ID的授权请求相关的结算请求。支付口服务器然后产生预付虚拟卡给接收者用户，其可被接收者移动设备使用。
[0213]在另一个示例实施方式中，在发送者移动设备发送转移ID至接收者移动设备之前进行授权和结算二者。在资金卡发行方服务器完成授权后并且在已进行价值转移的结算和已经形成预付虚拟卡之后，然后转移ID转移至接收者移动设备。
[0214]在一个示例实施方式中，本文所述的系统和方法允许具有两方转移应用软件的NFC可用的设备转移用户限定量的价值至另一 NFC可用的设备一一其也具有两方转移应用软件，而永远不会公开发送者的资金卡细节给接收者。进一步，发送者能够设定或确定给予接收者的价值。成功的转移导致发给接收用户与发送用户发送的价值量相同的预付虚拟卡。因此，即使接收用户没有银行账户接收价值，接收用户仍能够被给予预付虚拟卡，其可被接收用户用于进行支付和交易。
[0215]可理解，任何资金卡可被使用并且不限制于或依赖于与资金卡发行方有协定的移动电话运营商。对于要用的卡，首先需要注册该服务。也可理解为，与移动设备相关联可注册许多资金卡。持卡者的移动设备包含支付应用软件(也称为价值转移应用软件)，其可与支付口服务器交互。
[0216]在注册的一个示例实施方式中，对于发送用户希望注册的每一资金卡，用户将卡细节键入移动设备(例如资金卡上印刷的姓名、资金卡上印刷的PAN、资金卡上印刷的有效期和资金卡上印刷的静态安全码)。如上提及，资金卡发行方无需具有与任何移动电话运营商已有的协定。移动设备发送该数据和移动设备ID至支付口服务器。支付口服务器计算资金卡识别符，其识别给定的资金卡。支付口服务器存储与资金卡细节相关的资金卡识别符并发送资金卡识别符至移动设备以便存储。在另一个示例实施方式中，用户简单地点击移动设备上的无接触式卡，使得移动应用软件可获得卡细节并将其发送至支付口服务器以注册。在一个示例实施方式中，资金卡识别符是不同于资金卡的PAN、有效期或静态安全码的值。例如，资金卡识别符是随机值，这样如果被对手拦截，对手不能认识任何资金卡细节。在一个示例实施方式中，移动设备不存储任何资金卡细节或存储有限的资金卡细节(例如资金卡发行方姓名和PAN后四位)。移动设备存储资金卡识别符，其发送至支付口服务器以指示具体的资金卡。可理解，存在其他获得资金信用卡细节的方法(例如在键入数据的用户旁边)，其可用于本文所述原理。
[0217]可理解，移动设备上需要单一支付应用软件，其可管理多个资金卡。如果注册多个资金卡，则每个相关的资金卡识别符存储在移动设备中，在所述单一支付应用软件内。每个单独资金卡的细节存储在支付口服务器。以此方式，支付口服务器充当基于云的服务器，其存储多个资金卡的细节。
[0218]转向图18，提供计算机可执行或处理器执行的指令的一个实例，用于促进从发送用户101至接收用户1807的价值转移。在方框1801，发送用户指定资金卡以及转移至接收用户的量。在方框1802，发送用户从支付口服务器接收转移ID，其基于所述量和资金卡。在方框1803，发送用户发送转移ID至接收用户。在方框1804，接收用户验证转移ID和量，例如通过支付口服务器。在方框1805，如果有效，接收用户被发给发送用户指定量的预付虚拟卡。
[0219]对于方框1803，虽然本文所述的许多示例实施方式使用NFC技术在移动设备之间传送数据，但可理解，可使用其他数据传送方法。例如，转移ID可通过蓝牙、红外和其他点对点(P2P)通信技术发送至接收用户的移动设备。在其他示例实施方式中，转移ID可通过其他不一定是P2P的方式传送，包括即时通讯、发送短信、条形码、2D条形码、QR码、电子邮件等。在一个示例实施方式中，