CN114819961A - 用于为移动设备供应支付凭证的方法和系统 - Google Patents

Abstract

描述了一些实施例，涉及优化支付账户凭证对利用移动钱包的移动设备的供应。在一些实施例中，针对支付账户凭证供应，可基于特定供应请求所涉及的经确定的风险选择性地选择多个供应方案中的一个。低风险供应请求导致支付凭证的立即供应，而高风险的供应请求导致供应请求被拒绝。在一些实施例中，中等风险供应请求将导致在结束支付账户供应之前完成附加的用户认证。附加的用户认证可使用与接收供应请求的信道分开的通信信道来发生。

Description

用于为移动设备供应支付凭证的方法和系统

本发明申请是国际申请号为PCT/US2014/050407，国际申请日为2014年8月8日，进入中国国家阶段的申请号为201480055432.0，名称为“用于为移动设备供应支付凭证的方法和系统”的发明专利申请的分案申请。

相关申请的交叉引用

此申请是2013年8月8日提交的名为“METHODS AND SYSTEMS FOR PROVISIONINGMOBILE DEVICES WITH PAYMENT CREDENTIALS(用于为移动设备供应支付凭证的方法和系统)”的美国临时申请No.61/863,878、2013年10月31日提交的名为“METHODS AND SYSTEMSFOR PROVISIONING MOBILE DEVICES WITH PAYMENT CREDENTIALS(用于为移动设备供应支付凭证的方法和系统)”的美国临时申请No.61/898,428、2013年8月15日提交的名为“REMOTE MOBILE PAYMENT TRANSACTION WITH MOBILE APPLICATION USING SECUREELEMENT(利用使用安全元件的移动应用程序进行远程移动支付交易)”的美国临时申请No.61/866,514、2013年8月21日提交的名为“TRANSACTION ALERT SYSTEM INCORPORATINGENCRYPTION(包含加密的交易警告系统)”的美国临时申请No.61/868,487、2014年4月10日提交的名为“TRANSACTION ALERT AND TRANSACTION HISTORY DELIVERY SYSTEMINCORPORATING ENCRYPTION(包含加密的交易警告与交易历史传递系统)”的美国临时申请No.61/978,172、2013年8月26日提交的名为“TRANSACTION LOG PAYMENT APPLICATION(交易日志支付应用程序)”的美国临时申请No.61/870,153的非临时申请并要求其优先权的权益，出于所有目的引用这些申请的整体结合于此。

技术领域

本公开的各方面涉及计算技术。具体地，本公开的各方面涉及提供一些技术的设备，诸如用于为移动设备供应支付凭证的系统、方法、装置以及计算机可读介质。

背景技术

随着移动技术的连续发展和使用，越来越多的特征集成到移动设备中。例如，全球定位系统(GPS)应用程序、移动办公产品、消息系统、视频相机以及连指南针功能都已集成到移动设备中，使得它们广泛地适用于商业与个人范围两者。

为了进一步利用移动技术来更好地迎合用户的日常需要，已作出一些尝试来利用由移动设备实现的技术代替常规物理钱包。例如，提供移动钱包功能的一个方式是通过将卡发行方的账户信息直接供应到可配备有近场通信(NFC)芯片组的移动设备的安全元件(SE)上来实现的。SE可以是智能卡芯片，能够储存多种应用程序和/或账户特有信息，不可被外部方轻易访问。NFC技术普遍用于免接触短距离通信，基于射频识别(RFID)标准，使用磁场感应以能够在电子设备之间进行通信。此短距离高频率无线通信技术允许设备在短距离(例如，几厘米)上交换数据。这种移动设备因此可使用移动钱包应用程序，像常规物理钱包一样，移动钱包应用程序可“包含”支付卡(例如，信用卡、借记卡、预付卡)、会员卡、交通卡、忠诚卡等。

为此目的，用户金融凭证(例如，账户的主账号(PAN)、有效期等)可被供应在移动设备上。一旦这些金融凭证被供应在移动设备上，启用NFC的设备可与另一个启用NFC的设备通过将这些设备彼此靠近来交易(例如，传递信息、作出支付)。另外，供应有账户的移动设备还可用来利用其他无线协议(诸如经由蜂窝或无线(例如，IEEE 802.11)网络)执行与其他远程系统(例如，诸如商家的网站)的交易。

尽管将钱包功能集成在移动设备中的益处是显著的且仍在发展，但主要技术仍缺乏有效的且安全的过程与手段以将金融凭证安全地且有效率地供应到用户设备。本发明的各实施例分别地并共同地解决这些及其他问题。

发明内容

典型的支付凭证供应过程需要在第三方钱包提供商与供应服务器之间的多种消息。另外，当在供应期间认证用户账户时，通常遭遇不必要的延迟。因此，需要对在移动设备上(例如，在安全元件上)供应支付账户的过程加速并且提供更加有效的方法以用于在安全元件上供应大量的卡实例。另外，需要在供应过程期间的增强的认证服务，因为一些合法消费者可能具有可疑的初始认证结果。因此，需要不中断或延迟该供应过程的附加认证过程。

本发明的实施例涉及优化支付账户凭证对利用移动钱包的移动设备的供应。根据一些实施例，针对支付账户凭证供应，可基于特定供应请求所涉及的经确定的风险，从多个供应途径选择性地选择供应方案。

在一些实施例中，低风险供应请求可造成供应的立即开始，而高风险供应请求可造成供应请求被拒绝。在一些实施例中，那些中等风险的供应请求将导致在结束支付账户供应之前完成附加用户认证。在一些实施例中，附加用户认证包括经由与接收供应请求的信道分开的通信信道与用户通信。此通信可包括在第二通信信道上向用户发送一次性密码，可以是由发行方向用户发送的SMS消息、电子邮件或HTTP消息。

在一些实施例中，中等风险请求将导致供应到移动设备的支付账户凭证处于不活动状态，此不活动状态不允许使用此支付凭证，并且在认证过程完成时，所供应的不活动的凭证可被激活以供使用。

根据一个实施例，服务提供商为了供应账户凭证所执行的方法包括经由第一通信信道在服务器计算机处接收第一供应请求以向第一移动设备供应第一支付凭证。第一支付凭证与第一用户的第一账户相关联。确定与第一供应请求相关联的第一风险等级。响应于第一风险等级在预定的风险阈值范围内，此方法包括使认证过程由所述第一用户来执行。响应于该认证过程的成功执行，第一支付凭证被供应到第一移动设备上。此方法进一步包括经由第一通信信道在服务器计算机处接收第二供应请求以向第二移动设备供应第二支付凭证。第二支付凭证与第二用户的第二账户相关联。此方法进一步包括确定与第二供应请求相关联的第二风险等级，并且响应于第二风险等级低于预定的风险阈值范围，使第二支付凭证供应到第二移动设备上。在实施例中，非瞬态计算机可读介质储存指令，当由服务器的处理器执行该指令时使服务器执行此方法。在实施例中，描述了一种服务器计算机，包括处理器和所描述的非瞬态计算机可读介质。在实施例中，描述了一种支付账户凭证供应系统，包括该服务器计算机、一个或多个发行方计算机、钱包提供商服务器计算机以及移动设备。

本发明的实施例涉及优化在具有移动钱包的移动设备上的安全元件(“SE”)应用程序供应，该移动钱包具有消费者登记过程。一些实施例涉及通过产生并传递多个可能的个性化脚本以在一次通信中实现多个供应结果而在安全元件上供应卡数据。因此，通过在完成卡数据激活之前将所有可能的供应脚本提供给钱包提供商或其他支付账户管理方，实施例优化了安全元件应用程序供应，从而使得安全账户上的所供应的卡账户的最终激活在激活的时候需要较少的通信和/或计算资源。因此，卡应用程序数据可被供应在移动设备的安全元件上而仅需来自供应系统的单个供应消息，这可最小化移动钱包服务器与支付处理网络服务提供商之间的消息的数量。

因此，本发明的实施例提供有效率的供应过程，在单个有效率的过程中可选择性地提供增强的用户认证。

本发明的这些和其它实施例在下文中进一步详细地描述。

附图说明

图1示出包括支付交易系统中的多种实体的框图。

图2示出包括根据本发明的一些实施例的账户供应系统中的多种实体的框图。

图3示出描绘根据本发明的一些实施例的账户供应系统中的包含低风险与高风险供应的账户供应的组合序列与流程图。

图4示出描绘根据本发明的一些实施例的关于图2的账户供应系统中的中等风险账户供应的组合序列与流程图。

图5示出根据本发明的一些实施例的用于账户供应的服务器计算机的流程。

图6示出描绘根据本发明的一些实施例的账户供应系统中的两个动态验证值确认配置的组合序列与流程图。

图7示出描绘根据本发明的一些实施例的经由钱包提供商的消费者特定加密密钥供应与安全消息传输的组合序列与流程图。

图8示出描绘根据本发明的一些实施例的用于交易日志更新的唯一交易标识符的使用的组合序列与流程图。

图9是可被用于实现本文所描述的实体或部件中的任何一个的计算机系统的高级别框图。

具体实施方式

典型的支付凭证供应过程需要在第三方钱包提供商与供应网关之间的多种消息。另外，当在供应期间认证用户账户时，通常遭遇不必要的延迟。因此，需要对在安全元件上供应支付账户的过程加速并且提供更加有效的方法以用于在安全元件上供应(可能大量的)卡实例。

另外，需要供应过程期间的增强的认证服务，因为一些合法消费者可能具有可疑的初始认证结果。因此，需要不中断或延迟该供应过程的附加认证过程。

本发明的实施例涉及优化支付账户凭证对利用移动钱包的移动设备的供应。根据一些实施例，针对支付账户凭证供应，可基于特定供应请求所涉及的经确定的风险，从多个供应途径选择性地选择供应方案。

在一些实施例中，低风险供应请求可造成供应的立即开始，而高风险供应请求可造成供应请求被拒绝。在一些实施例中，那些中等风险的供应请求将导致在结束支付账户供应之前完成附加的用户认证。在一些实施例中，中等风险请求将导致供应到移动设备的支付账户凭证处于不活动状态，此不活动状态不允许使用此支付凭证，并且在认证过程完成时，所供应的不活动的凭证可被激活以供使用。

本发明的实施例涉及优化在具有移动钱包的移动设备上的安全元件(“SE”)应用程序供应，具有消费者登记过程。一些实施例涉及通过产生并传递多个可能的个性化脚本以在一次通信中实现多个供应结果而在安全元件上供应卡数据。因此，通过在完成卡数据激活之前将所有可能的供应脚本提供给钱包提供商或其他支付账户管理方，实施例优化了安全元件应用程序供应，从而使得安全账户上的所供应的卡账户的最终激活在激活的时候需要较少的通信和/或计算资源。因此，卡应用程序数据可被供应在移动设备的安全元件上而仅需来自供应系统的单个供应消息，可最小化移动钱包服务器与支付处理网络服务提供商之间的消息数量。

因此，本发明的实施例提供有效率的供应过程，在单个有效率的过程中可选择性地提供用户的增强认证。

I.术语

在讨论本发明的实施例以前，呈现一些术语的描述以辅助理解此公开。

如在本文中使用的，术语“包括”不旨在限制，而可以是与“包含”、“含有”或“由…表征”同义的过渡短语。术语“包括”由此在权利要求中使用时可以是包含性的或开放式的并且不排除附加的、无归属的元素或方法步骤。例如，在描述方法时，“包括”指示该权利要求是开放式的并且允许附加的步骤。在描述设备时，“包括”可表示指名的元件对于实施例可能是关键的，而其他元件可被添加并且仍形成权利要求的范围内的构造。相反，过渡短语“由...构成”排除权利要求中未指明的任何元件、步骤或成分。

这些术语的使用在整个说明书中是一致的。

在以下描述和权利要求中，可能使用术语“耦合的”和“连接的”。术语“耦合的”可用来指示两个或多个元件，这些元件可能或可能不彼此直接物理或电接触，但彼此仍然共同合作或彼此相互作用。术语“连接的”可用来指示彼此耦合的两个或多个元件之间的通信的建立。

如本文中所使用的，“移动设备”可包括任何电子和/或通信设备，可被用户运送和操作，还可经由一个或多个网络提供与资源的远程通信能力。移动设备的实例包括移动电话(例如，蜂窝电话)、个人数字助理(PDA)、平板计算机、便携式计算机(例如，上网本)、个人音乐播放器、手持电子读取设备、可穿戴计算设备等。

“服务器计算机”可包括功能强大的计算机或者两个或多个计算机的组合。例如，服务器计算机可以是大型机，微型计算机集群或充当一个单元(诸如机群)的服务器组。在一个示例中，服务器计算机可以是耦合至Web服务器的数据库服务器。服务器计算机通常执行服务器应用程序，用作客户-服务器交互中的服务器，包括但不限于数据库服务器应用程序、web服务器应用程序、应用程序服务器应用程序等。

如本文中所使用，“通信信道”可以是指用于在两个或更多个实体之间的通信的任何合适的路径。合适的通信信道可以直接存在于诸如支付处理网络和商家或发行方计算机之类的两个实体之间，或可包括多个不同的实体。任何合适的通信协议可用于生成通信信道。在一些实例中，通信信道可以包括“安全通信信道”，该安全通信信道能以任何已知的方式来建立，已知的方式包括使用相互认证和会话密钥以及安全套接字层(SSL)会话的建立。然而，可以使用创建安全信道的任何方法。通过建立安全信道，与支付设备相关的敏感信息(诸如，帐号、卡验证值(CVV)值、有效期等)可以在两个实体之间安全地传输，从而促进交易。

如本文中所使用，“风险分”可包括任意标记或等级评定，表示与交易可能是欺骗性相关联的风险。风险分可由数字(和任何标度)、概率或传达此类信息的任何其他相关方式来表示。风险分可包括关于交易的信息的聚集，该信息包括交易信息、账户信息和验证信息，如上所定义。风险分可由任何授权实体(诸如商家或发行方)使用来确定是否许可交易。风险分可包括和/或利用当前交易信息和过去交易信息，并且可以以任何适当的方式权衡这类信息。

如本文所使用，“支付账户”(可与一个或多个支付设备相关联)可涉及任何适当的支付账户，包括信用卡账户、支票账户、预付卡账户等。

如本文所使用，“识别信息”可包括与账户(例如，支付账户和/或与此账户相关联的支付设备)相关联的任何适当信息。这类信息可直接与账户相关或者可从与账户相关的信息中导出。账户信息的示例可包括PAN(主账号或“账号”)、用户名、有效期、CVV(卡验证值)、dCVV(动态卡验证值)、CVV2(卡验证值2)、CVC3卡验证值等。CVV2一般被理解为与支付设备相关联的静态验证值。CVV2值一般对用户(例如，消费者)可见，而CVV和dCVV值通常嵌入存储器或授权请求消息并且对于用户是不容易知晓的(尽管它们对于发行方和支付处理器是已知的)。

II.支付系统

图1示出包括支付交易系统100中的多个实体的框图。示出的支付交易系统100包括用户107、支付设备108、移动设备101、访问设备102、商家计算机103、收单方计算机104、支付处理网络105以及发行方计算机106。

系统100包括用户107，可操作移动设备101。用户107可使用移动设备101在连接至商家计算机103的访问设备102处进行金融交易(例如，支付交易)。用户107还可在访问设备102处使用支付设备108进行金融交易。商家计算机103可被连接至收单方计算机104。收单方计算机104可经由支付处理网络106连接至发行方计算机105。当然，示为连接的这些实体中的一些或所有可连接在一个或多个通信网络上或者可以直接连接。

如本文所使用，“商家”通常是从事交易并可出售商品和/或服务的实体。“发行方”通常可涉及商业实体(例如，银行)，为用户维持金融账户并且可发行要被储存在用户的移动设备101(例如，蜂窝电话、智能卡、平板、便携式计算机等)上的支付凭证“收单方”通常是与特定商家或其它实体具有商业关系的商业实体(例如，银行)。一些实体可同时执行发行方和收单方功能，一些实施例可包含这种单实体发行方-收单方。这些实体(例如，商家计算机103、收单方计算机104、支付处理网络105和发行方计算机106)中的每一个可包括一个或多个计算机装置以允许通信或者执行本文中所描述的功能中的一个或多个。

如本文所使用，“支付设备”108可涉及可用于进行金融交易(诸如向商家提供支付信息)的任何设备。支付设备可以是任何合适的形式。例如，合适的支付设备包括，但不限于：智能卡、磁条卡、钥匙链设备(诸如商业上可从埃克森美孚(Exxon-Mobil)公司获得的Speedpass^TM)、蜂窝电话、个人数字助理(PDA)、寻呼机、支付卡、安全卡、访问卡、智能介质、应答器、2-D条形码、电子或数字钱包等。此类设备能够以接触或免接触模式来操作。在一些配置中，支付设备108直接与访问设备102交互(即，而不需要使用任何其他设备和/或网络)，而在一些配置中，支付设备108使用中间设备和/或通信网络与访问设备102通信。移动设备101是移动设备(如上所述)，在一些实施例中可能被视为支付设备(例如，支付设备108)的类型。例如，移动设备101可包括，但不限于：蜂窝电话、便携式计算机、平板、可穿戴计算设备等，并且可与访问设备102(例如，使用NFC)和/或商家计算机103交互(例如，经由互联网访问网站或利用商家计算机103所提供的应用程序)以发起和/或进行金融交易。

支付处理网络105可包括数据处理子系统、网络和操作以用于支持并递送证书授权服务、授权服务、异常文件服务以及清算与结算服务。示例性支付处理网络可以包括VisaNet^TM。诸如VisaNet^TM之类的支付处理网络能够处理信用卡交易、借记卡交易、数字钱包交易和其他类型的商业交易。具体而言，VisaNet^TM包括处理授权请求的VIP系统(Visa集成的支付系统)以及执行清算与结算服务的Base II系统。在一些实施例中，支付处理网络105可基本上实时地(例如，小于几秒或一秒内)进行交易。支付处理网络105可包括一个或多个服务器计算机(如上所述)。支付处理网络105可使用任何适当的有线或无线网络，包括因特网。

在示例性购买交易中，用户107使用移动设备101(例如，移动电话)从商家购买商品或服务。用户的移动设备101可以和与商家计算机103相关联的商家处的访问设备102交互。例如，用户107可对着访问设备102中的NFC读取器轻触(tap)移动设备101。替代地，像这样使用数字钱包或者通过线上交易，用户107可向商家电子地指示支付详细信息。在一些购买交易中，移动设备101可能不使用访问设备102，而可与商家计算机103(例如，提供商家网站的计算机系统或者移动设备101上执行的商家应用程序208A的“后端”服务)直接交互。在这些示例中，商家计算机103可被视为实施虚拟访问设备。

为了使金融交易被执行，授权请求消息由访问设备102(或虚拟访问设备，可以在商家计算机103上)产生并转发到收单方计算机104。收单方计算机104是提供商家的账户的收单方(如上所述)的系统，将最终从提供用户107的账户的发行方接收交易的资金。这种“授权请求消息”可以是被发送至支付处理网络105和/或支付卡的发行方(例如，发行方计算机106)以请求交易的授权的电子消息。根据一些实施例，授权请求消息可兼容国际标准化组织(ISO)8583标准所限定的消息类型，该标准是用于交换与用户使用支付设备108(可以是移动设备101)或支付账户作出的支付相关联的电子交易信息的系统的标准。授权请求消息可包括可以与支付设备或支付帐户相关联的发行方帐户标识符。授权请求消息还可包括对应于“识别信息”的附加数据元素，仅作为示例，包括：服务代码、CVV(卡验证值)、dCVV(动态卡验证值)、有效期等。授权请求消息还可包括“交易信息”，诸如与当前交易相关联的任何信息，诸如交易金额、商家标识符、商家位置等，以及可被用在确定是否标识和/或授权一交易中的任何其它信息。授权请求消息还可包括其它信息，诸如生成授权请求消息的访问设备102的标识符、关于访问设备102的位置的信息等。

通常，授权请求消息将包括用于与移动设备101(或支付设备108)所提供的用户107的账户相关联的主账号(PAN)的字段。在接收到授权请求消息之后，收单方计算机104将向支付处理网络105发送授权请求消息。支付处理网络105随后将授权请求消息转发至与用户的账户的发行方相关联的发行方计算机106。包含在授权请求消息中的PAN可由支付处理网络105使用来识别适当的发行方计算机106以便于路由或处理(例如，确定授权请求的风险，可基于有关发行方的已知规则)此消息。

在发行方计算机106接收到授权请求消息之后，发行方计算机106将授权响应消息发送回支付处理网络105以指示当前交易是否被授权。“授权响应消息”可以是由发行金融机构或支付处理网络生成的对授权请求消息回复的电子消息并且可兼容ISO 8583标准。仅作为示例，授权响应消息可包括下列状态指示符中的一个或多个：“批准”--交易得到批准；“拒绝”--交易未被批准；或“呼叫中心”--响应因需更多信息而待决，商户必须呼叫免付费的授权电话号码。授权响应消息也可以包括授权代码，该授权代码可以是发行方响应于电子消息中的授权请求消息(直接地或通过支付处理网络)而返回到商家的访问设备102(例如，POS设备)的、指示对交易的许可的代码，并且可用作授权的证明。

支付处理网络105从发行方计算机106接收授权响应消息并将此授权响应消息传送回收单方计算机104。收单方计算机104然后将此授权响应消息发送回商家计算机103，其中商家可确定是否继续进行交易。在一些实施例中，诸如当在支付处理网络105处触发了欺诈规则时，支付处理网络105可拒绝由发行方计算机106先前授权的交易。在商家计算机103接收到授权响应消息之后，访问设备102随后可向用户107提供授权响应消息。响应消息可由显示器设备(例如，作为访问设备102的一部分的或者耦合到访问设备102的显示器设备)显示，打印在收据上，传递到用户的移动设备101等。可选地，如果交易是线上交易(例如，经由网站或应用)，那么商家计算机103可为移动设备101提供授权响应消息的网页、显示器模块或其他指示。

在一天结束时，支付处理网络105可进行正常的清算与结算过程。清算过程是在收单方和发行方之间交换金融明细以便于对消费者的支付帐户过帐以及对用户的结算位置的核对(reconciliation)。然而，应该注意到，本发明的实施例不限于单个结算过程。

III.使用预生成脚本供应卡凭证的系统

在一些情况下，具有移动设备101的用户107可期望移动设备101被“供应”有支付凭证(例如，支付凭证207)以被商家(例如，商家计算机103，通常经由应用程序208，诸如商家应用程序208A、web游览器208B、第三方应用程序等)使用或者用于其他交易。支付凭证207可以是由发行方240维持的账户。因此在一些实施例中，移动设备107可能需要首先被供应个性化数据，诸如支付信息和关于用户107的信息。图2示出根据本发明的一些实施例的可用来进行设备供应的系统200的示例。系统200包括移动设备107、应用程序提供商209(例如，钱包提供商210)服务器计算机211、服务提供商230(例如，支付处理网络105)服务器计算机212以及发行方240服务器计算机106。移动设备101和服务器计算机211、212与106中的每一个可使用一个或多个计算设备来实现。在一些实施例中，移动设备101包括安全元件202，安全元件202可以是支付凭证207被供应到的地方，并且移动设备101还可选择性地包括安全支付应用程序206和/或交易日志204(这两者可存在于移动设备101的安全元件202的外部)。

应用程序提供商209服务器计算机211可以是应用程序提供商209操作的或代表应用程序提供商209的服务器计算机或另一个计算设备。应用程序提供商209可以是为用户107提供应用程序(例如，应用程序208)的任何实体。应用程序提供商209的一个示例可以是数字钱包提供商210(例如，Visa Checkout^TM或Google^TM钱包)。数字钱包提供商210可为用户维持数字钱包，每一个数字钱包包括一个或多个支付账户的支付数据。应用程序提供商209可与安装在移动设备101上的应用程序相关联。例如，移动设备101上的Visa Checkout应用程序可被配置为连接到由Visa操作的应用程序提供商209服务器计算机211。

服务提供商230服务器计算机212可以是服务提供商230操作的或代表服务提供商230的服务器计算机或另一个计算设备。服务提供商230可以是提供供应或个性化服务的任何实体。例如，服务提供商230计算机可维持具有关于用户的信息的个性化数据库(本文中未示出)并且可被配置为与一个或多个发行方240通信以确定用户107的个性化支付数据。服务提供商230服务器计算机212可经由其供应服务模块225向一个或多个应用程序提供商209提供“作为服务的供应”，其中此应用程序提供商209服务器计算机211利用应用程序接口(API)以与服务提供商230服务器计算机212通信。

服务提供商230－诸如支付处理网络105－可提供供应服务模块225和/或设备供应消费者认证系统(DPCAS)214，作为其服务器计算机212的一部分。DPCAS 214可用作提供认证服务的认证服务器，并且可包括访问控制服务器216(例如，用于确定账户对于特定服务是否合法或者账户是否参与特定服务)和/或目录服务器218(例如，为账户标识相关联的发行方240和/或ACS 216)。在一些实施例中，DPCAS 214可验证用户107认证信息，诸如用户标识信息、一次性密码、挑战响应信息等。在其他实施例中，DPCAS 214的一些部分或全部可与发行方240或另一个实体相关联(或由发行方240或另一个实体提供)。例如，在一些实施例中，ACS 216可由发行方240提供。在一些实施例中，DPCAS 214被简单地配置为确定认证所使用的适当认证系统，认证可由服务提供商230、发行方、钱包提供商或其他第三方来实施。

另外，服务提供商230可提供附加的服务，包括但不限于警告服务220(例如，经由服务器计算机212处执行的或由服务器计算机212执行的一个或多个过程)，可基于用用户107的账户发生的交易产生警告并向用户107提供警告。例如，警告服务220可使用可由用户107配置的一个或多个警告规则组来分析用户107的账户的一个或多个交易，并且如果这些规则中的任何一个具有满足的条件(即，一个或多个规则被“触发”)，那么警告服务220可向用户107提供警告消息，指示和/或描述这些规则的触发。作为一个示例，用户107可配置一规则在具有超出限定阈值的值的交易发生在他们的账户上时被触发(因此，警告消息被提供)。服务提供商230还可提供可产生和/或储存“令牌”(例如，第一数据值)的令牌服务222，该令牌与另一个可能敏感的第二数据值相关联。例如，令牌服务222可为账户的主账号(PAN)产生令牌值并且提供令牌值，同时保持此令牌值与此PAN之间的储存的关联性(或映射)，以使得令牌服务222(或受限的实体组)能够将此令牌值“翻译”回实际PAN，这提供了增强的安全性。另外，服务器计算机212(诸如当它由支付处理网络105操作时)可维持/储存它处理的金融交易的交易日志224。

在一些实施例中，发行方计算机106可向服务提供商230服务器计算机212提供关于与发行方计算机106相关联的用户107的个人信息。例如，发行方计算机106可提供支付信息、用户信息、账户信息等。在一些实施例中，服务提供商230服务器计算机212可向发行方计算机106提供与供应过程有关的数据。例如，如果供应过程期间针对用户107的账户生成了支付令牌(例如，由令牌服务222)，那么此支付令牌可由服务提供商230服务器计算机212提供给账户的发行方240。

因此，在系统200的一个使用情况下，用户107可操作移动设备101以发起对移动应用程序(例如，数字钱包应用程序，可以是支付应用程序208C和/或安全支付应用程序206)的供应的请求。该供应的请求可被发送到应用程序提供商209服务器计算机211。应用程序提供商209服务器计算机211可将此请求转发到服务提供商230服务器计算机212，具体地，至供应服务模块225。供应服务模块225可使用从发行方计算机106和/或一个或多个数据库中确定的个性化数据生成供应脚本(例如，部分个性化脚本、激活脚本、删除脚本等中的一个或多个)并将这些脚本传输到应用程序提供商209服务器计算机211。应用程序提供商209服务器计算机211然后可在移动设备101发起执行这些脚本中的一个或多个。例如，应用程序提供商209服务器计算机211可使部分个性化脚本被移动设备101执行。在相同或不同的时候，服务提供商230服务器计算机212(例如，供应服务模块225)可认证用户，可能使用其DPCAS 214。一旦部分个性化脚本已被执行且用户107已被认证，供应服务模块225可命令应用程序提供商209服务器计算机211在移动设备101上执行激活脚本以完成供应，由此支付凭证207组完全“安装”在移动设备101上以供使用。

在多种实施例中，选择性地利用认证过程来避免在不需要附加认证时使用它们而在附加认证有帮助时有效率地纳入它们。

应该注意到，服务器计算机211、212和/或106中的任何一个可被相同的或不同的实体操作或者以其他方式与相同的或不同的实体相关联。例如，在一个实施例中，服务器计算机212可由支付处理网络105来操作，而在一些实施例中，DPCAS 214可由未示出的第三方实体或例如由发行方240来操作。

A.支付凭证供应

为了帮助理解图2的图示实体，描述了根据本发明的供应支付账户凭证207的示例性流程。用户107可通过使用运行在移动设备101上的移动应用程序208来发送对供应的请求。例如，在支付应用程序208C(例如，数字钱包应用程序)中，用户107可为移动设备101请求账户、信用卡或任何其他支付凭证的供应。对供应的请求消息可包括设备信息，诸如移动设备101标识符、安全元件202标识符、安全元件密钥标识符(或密钥)、用户标识符(用于识别用户或账户)以及用户认证信息(例如，密码，诸如对于基于卡验证的认证过程的CVV2、对于地理验证的ZIP码等)。应用程序提供商209服务器计算机211接收对供求的请求消息，并且可针对请求的用户107、账户、移动设备101或任何其他数据执行风险检测或风险分析，这些数据存在于所接收的对供应的请求消息中或者与对供应的请求消息相关联的用户账户绑定。例如，风险校验可包括确定已供应此用户账户多少次以及多少账户被供应在移动设备101上。风险校验例如可指示对供应的请求是欺骗性的可能性。如果风险校验指示供应的风险是可接受的，那么应用程序提供商209服务器计算机211可将对供应的请求发送到在服务提供商230服务器计算机212上执行的供应服务模块225。对供应的请求消息可包括包含于从移动设备101接收的消息中的任何信息，并且可包括由应用程序209服务器计算机211确定的附加信息，诸如与用户的账户相关联的主账号(PAN)以及与对供应的请求相关联的参考号。

供应服务模块225然后可尝试验证所提供的用户认证信息。例如，如果对供应的请求包含PAN和密码，那么供应服务模块225可检索主加密密钥，使用主加密密钥对密码解密，并确保此解密值为期望值(例如，对应于所接收的PAN值)。供应服务模块225然后可生成支付令牌以供应在使用令牌服务222的移动设备上。支付令牌代表要被供应在移动设备上的PAN或其他账号，并且可包括提供在供应请求中的实际PAN、生成的令牌、连同PAN序列号的PAN或支付信息的其他项目以用于在经由移动支付应用程序208C使用时识别账户。支付令牌可被包含在之后储存在移动设备101上的个性化数据中。

供应服务模块225然后可生成部分个性化脚本、激活脚本和删除脚本，并且在供应脚本消息中将这些“供应脚本”发送到应用程序提供商209服务器计算机211。部分个性化脚本(或“perso”脚本)可操作来在移动设备101上储存个性化数据，激活脚本可操作来激活或允许对个性化数据的访问，以及删除脚本可操作来从移动设备101删除或以其他方式移除个性化数据。供应脚本消息还可包括设备信息(可允许应用程序提供商209服务器计算机211识别哪一个移动设备101与供应脚本相关联)、参考标识符(处于类似的目的)以及卡样式(可被提供给移动设备，作为被供应的账户的图形表示)。在一些实施例中，供应脚本可被加密以使得仅移动设备101或移动设备101的安全元件202可解密脚本。例如，由移动设备101发送的对供应的原始请求可包括安全元件202的公共密钥(或共享密钥)，允许其他实体使用此公共密钥对消息加密，该消息进而只能由安全元件202使用对应私有密钥来解密。

当供应脚本消息被应用程序提供商209服务器计算机211接收到时，它可发起该部分个性化脚本在移动设备101上的执行。例如，通过向移动设备101发送部分个性化脚本消息来发起该执行，该个性化脚本消息包括部分个性化脚本和指令(即，命令)来执行该脚本。一旦接收到，移动应用程序208、安全元件202或移动设备101上的另一个适当元件可使其处理器执行部分个性化脚本。

移动设备101然后可向应用程序提供商209服务器计算机211发送指示是否成功安装部分个性化脚本的部分个性化确认消息，该部分个性化确认消息可被转发到服务提供商230服务器计算机212的供应服务模块225。

在较早或较晚的时候，供应服务模块225可利用DPCAS 214来认证用户107。例如，供应服务模块225可向DPCAS 214发送认证请求消息。认证请求消息可包括由移动设备101或应用程序提供商209服务器计算机211提供的用户认证信息(诸如PAN)，并且还可包括参考标识符和设备信息。DPCAS 214然后可进行进一步风险评估和认证过程并且确定用户是否被认证并且是否被授权供应移动设备101，这可包括执行详细校验(诸如用户107的账户是否先前被标记为泄露的)或过去交易的分析(例如，使用交易日志224)。因此，DPCAS 214可确定用户107被认证、未被认证，或者可从用户107寻求附加信息。例如，DPCAS 214可使被发送到移动设备101的认证请求消息请求附加的用户认证数据，然后接收认证响应消息作为回报。附加用户认证信息的一些示例可包括对挑战问题、安全性问题、一次性密码等的答案。最终，DPCAS 214可将认证响应消息提供回到供应服务模块225以指示此认证的结果。

例如，当供应服务模块225已确定它接收到部分个性化确认消息且它已作出认证决定时，供应服务模块225可向应用程序提供商209服务器计算机211发送激活消息或删除消息。例如，如果部分个性化确认消息指示脚本的成功执行并且认证结果指示用户的成功认证的话，那么供应服务模块225可发送激活消息。类似地，如果部分个性化确认消息或认证结果指示失败，那么供应服务模块225可发送删除消息。然后，应用程序提供商209服务器计算机211可发起由移动设备101执行激活脚本或删除脚本，分别取决于接收到激活消息还是删除消息。可以以与如上所述的部分个性化脚本的发起相同的方式来执行激活脚本/删除脚本的执行的发起。

在脚本执行时，移动设备101然后可向应用程序提供商209服务器计算机211发送供应确认消息，指示是否成功执行激活或删除，并且此消息可返回到供应服务模块225。成功确认已在设备上供应并激活账户，服务提供商230服务器计算机212可通过对发行方计算机106告知此激活来完全激活供应在账户上的账户。例如，如果先前为支付账户生成了支付令牌，供应服务模块225可向发行方计算机106发送包含支付令牌和账户PAN的令牌关联消息，指示被关联的令牌和PAN。

IV.用于凭证供应的适应个别差异的基于风险的认证

如之前所述，典型账户凭证供应过程需要钱包提供商210和供应服务模块225(或服务提供商230服务器计算机212)之间的多种消息。另外，当在供应期间认证用户时通常遭受不必要的延迟，因此需要对在移动设备(例如，使用安全元件)上供应支付账户的过程加速并提供更加有效率的方式以在大量移动设备101上供应大量支付账户。另外，需要供应过程期间的增强认证服务，由于一些合法消费者可能具有可疑的初始认证结果或者可能不能够容易地使用典型认证方案。因此，需要不中断或延迟供应过程的附加认证过程。

本发明的实施例部分地通过使用适应个别差异的基于风险的供应，单独地且共同地解决了这些问题。图3示出描绘根据本发明的一些实施例的账户供应系统中的包含低风险与高风险供应的账户供应的组合序列与流程图300。如本文所使用，术语“账户供应”、“支付账户供应”“卡供应”“凭证供应”等可交替使用来指将与用户107和/或用户账户相关联的信息放置(或“安装”)在移动设备101上的过程，从而使得移动设备101可利用此账户来执行金融交易，除非从该术语的用法和/或其上下文从明确得出被引用的区别。

图示的序列与流程图300示出在一组实体之间发送的消息以及由这组实体执行的行动。这组实体包括移动设备101、钱包提供商210、服务提供商230和发行方240。在一些实施例中，一个或多个计算设备(例如，服务器计算机)实现实体210、230与240中的每一个。因此，为了提供简单的理解，参考较高级别的实体来描述本文所示的行动和消息。另外，在一些实施例中，一些实体包含执行这组行动，而在一些实施例中，较少的实体被用来执行这组行动。因此，此图示仅作为一个可能实施例的说明且不旨在是排他性的或限制性的。

在框302处用户107初次登陆他们的移动设备101上的电子钱包应用程序以初次为移动设备101请求账户、信用卡、或任何其他支付凭证的供应时，图示的过程开始。

然而，在一些实施例中，支付凭证207可甚至在用户试图激活、使用或以其他方式供应卡之前安装到移动设备。因此，在用户不知情的情况下，下述过程可自动发生。此刻，用户可请求在移动设备上供应卡凭证，并且此刻，可能无进一步数据需要被发送到移动设备，并且所供应的账户可几乎立即被用户访问。因此，实施例可甚至在消费者请求在移动设备上供应卡实例之前完成卡凭证的供应过程。例如，用户107可在他们的移动设备101上下载移动钱包应用程序并且可输入所登记的他们的用户名、标识符、卡等。

此刻，钱包提供商210可发起向移动钱包登记的所有卡的所描述过程。

因此，实施例可甚至在用户请求供应特定卡之前应用供应脚本。

然而，用户107在框302处向移动设备101提供钱包凭证时，移动设备101(例如，在移动支付应用程序的请求下)就向钱包提供商210传输凭证350。在图示实施例中，在确认凭证350是正确的且针对有效账户时，就向服务提供商230传输针对用户107的一个或多个账户的校验账户消息352(例如，对卡合格性请求作出API调用)。在一些实施例中，此校验账户消息352包括用户的账户的一个或多个PAN(或其他类型的账户标识符)，可由用户107在较早的时候提供(例如，到钱包提供商)，或者可与凭证一起(即，在框302处)由用户107提供并与钱包凭证消息350一起发送。

服务提供商230可针对PAN(或针对提供在校验账户消息352中的、由校验账户消息352标识的或者以其他方式与校验账户消息352相关联的一个或多个PAN中的一个或多个)验证要供应凭证所针对的相关账户的合格性。在一些实施例中，服务提供商230在框304处验证合格性，而在一些实施例中，服务提供商230向发行方240传输账户合格性请求消息354，并且发行方240然后将在框306处验证合格性并且返回指示账户的合格性的账户合格性响应消息356。在一些实施例中，账户合格性请求消息354可包括指示与请求相关联的风险值，此风险值由服务提供商230或钱包提供商210生成，这允许发行方240在验证请求的合格性时考虑一附加因素。

例如，针对特定PAN，框304可包括识别账户的发行方240(例如，基于银行识别码(BIN))并且然后确定发行方240是否允许此供应发生。框304还可包括利用合格的和/或不合格的(例如，存在于列出那些已丢失、被盗或阻止的账户的异常文件中)账户的数据库，此数据库可由发行方240提供。在一些实施例中，框304中的此验证可包括基于发行方校验数字方案使用PAN执行校验数字计算，确定账户是否已被供应到设备(相同或不同设备)等。类似地，发行方240可在框306处根据配置偏好所决定的多种方式验证账户的合格性，诸如允许所有账户被供应凭证、不允许任何账户被供应凭证、或者仅允许一些账户被供应凭证，这可基于账户历史、在发行方240处的用户的其他账户的历史、账户是否先前被供应等。

此刻，无论经由框304还是框306，服务提供商230将已确定账户的合格性，并且将向钱包提供商210传输账户合格性响应消息358(例如，发送API响应消息)，标识一个或多个账户并针对这些账户指示各账户对于凭证供应是否合格。

在框308处，如果账户不合格，钱包提供商210可向移动设备101传输不合格性消息360，可导致此消息呈现给用户107(例如，经由显示器设备)以指示账户不合格。然后，在框310处，流程结束，并且用户107可选择性地尝试为不同的账户再次开始流程。

如果在框308处账户合格，则该流程继续，钱包提供商210发送指示账户合格的启用支付询问消息362，并且作为响应，用户107和/或钱包应用程序可使另一个启用支付询问响应消息362被发送回到钱包提供商210以指示用户107确实寻求“启用”与账户相关联的支付凭证207向移动设备101的供应(即，将他们的账户“添加”到移动设备101)。该启用支付询问消息362可使移动设备101在此服务激活阶段期间也向用户呈现用户必须接收才能继续的一组条款和条件。

钱包提供商210然后向移动设备101传输CVV2提示消息264以寻求账户的进一步卡信息(例如，信用卡的CVV2或CVV值)的输入，可针对此信息使移动设备101提示用户107。在框312处从用户107接收到此卡信息(例如，CVV2值)时，移动设备101传输供应请求消息366，可包括提供的卡信息值(例如，CVV2值)。

在一些实施例中，供应请求消息366包括设备信息(用于标识移动设备101和安全元件202，并且可包括该设备的任何唯一标识符来标识所需的安全元件密钥)、消费者凭证(例如，PAN和/或卡验证值(例如，基于卡验证的认证过程的CVV2))和/或邮编(基于地理的认证过程)。供应请求消息366由移动设备101发送到钱包提供商210，可基于此供应请求消息366在框313处生成风险分(或执行“风险校验”或“风险分析”以生成风险评估数据)。此风险分析可基于请求的用户107、账户、卡、移动设备101或存在于供应请求消息366中的任何其他数据(例如，CVV2值、邮编、用户标识符等)或者与提交此供应请求的用户107的账户绑定的任何其他数据(例如，先前登记/提供的卡数据、确定此账户已开了多久、此消费者总共使用或已经使用多少卡、过去购买的数量等)。

假设确定的风险没有过高，钱包提供商210向服务提供商230(例如，供应服务模块225)发送供应请求368。供应请求可包括设备信息、与视图被供应的账户相关联的主账号(PAN)、有效期、用户输入的CVV2值、ZIP码、与账户合格性响应消息358一起返回的时间敏感的令牌(即，如果时期过去则会过期)或可与用户账户相关联的任何其他信息以及供应请求的参考标识符。

在一些实施例中，供应请求352可包括PAN(或令牌)的参考标识符(ID)而不是PAN本身。在一些实施例中，此参考ID是由钱包提供商210和服务提供商230两者预配置的(或者以其他方式被一致同意)以使这两者都知晓参考标识符与PAN之间的映射(或者可以其他方式翻译)。

在一些实施例中，在框314处由服务提供商230确定(或“分配”)请求的风险(例如，基于由发行方240早先提供的规则和/或数据)以产生令牌激活响应372A。然而，在一些实施例中，服务提供商230标识账户的发行方240(例如，基于PAN)，向发行方240传输令牌激活请求消息370(可包括指示服务提供商分配的风险314的风险值和/或由钱包提供商210生成的风险值)以使得在框316处，发行方240将确定/分配其自己的风险并将令牌激活响应消息372B返回到服务提供商230。

类似于关于框304/306在上文描述的账户合格性的验证，在框314/316处的风险的分配可根据实施实体的偏好来执行，并且因此可基于多种因素，这些因素包括但不限于：提供的CVV2值是否存在且是否被验证为正确；早先提供的令牌是否包含在供应请求352中；请求的账户是否已经被供应在移动设备101或另一个设备上；提供的地址是否可被验证为正确；由用户107早先提供的账户配置数据；钱包提供商数据(例如，风险值)；设备信息(诸如其可用硬件或软件能力)；指纹或其他标识符等。

在一些实施例中，在发送令牌激活请求消息370之后，服务提供商230可被配置为仅在一段时期内等待对应的令牌激活响应消息372B。在这些实施例的一些中，如果时期过期，那么服务提供商230可使用其自己生成的风险评估314结果(即，令牌激活响应372A)以继续此流程，并且可选择性地(未示出)向发行方240传输另一个消息以标识它分配了什么风险评估314结果和/或服务提供商230如何选择继续进行。此实施例允许此过程以有效率的高度响应方式继续进行以避免用户107持续等待。

不管框314/316的准确风险分配规划，令牌激活响应消息372A/372B可指示风险的等级。在一些实施例中，至少三个级别的风险可被生成，包括：无条件许可供应请求的“低”风险、有条件地许可供应请求的“中等”风险、以及拒绝供应请求的“高”风险。图示的流程根据生成的这三个等级的风险而变化。

在框318处，服务提供商230确定哪个等级的风险被确定。如图所示，框318包括标识风险的等级是“高”、“中等”还是“低”。当然，尽管在一些实施例中，风险的等级可以是明确分类的(并且因此唯一地标识哪一个风险分类被确定)，在其他实施例中，风险的等级可以是其他形式(例如，生成风险分，例如风险分是0与100之间的整数，并且因此风险分类的判定可包括判定风险分是否在一些值的范围内，是否满足或超过一值，是否低于一值等)

图3针对“高”与“低”风险等级示出流程如何继续，图4针对“中等”风险等级示出流程如何继续，如由图3引导到页面的底部的线和紧挨圆圈‘A’的标签“至图4”所指示。

如果在框318处，风险等级被标识为“高”，服务提供商230可传输供应请求拒绝消息374，指示此供应请求消息368被拒绝。作为响应，钱包提供商210可向移动设备101传输拒绝消息376，移动设备101向用户107呈现指示拒绝的消息和/或命令用户107与账户的发行方联系(例如，请求发行方允许该账户以便账户供应)。此刻，“高风险”流程在框320处结束。

如果在框318处，风险等级被标识为“低”，服务提供商230可获取令牌322。在实施例中，此令牌获取322包括：供应服务模块255通过向令牌服务模块222发送PAN从令牌服务模块222(可以是服务器计算机212(如图所示)的一部分或另一个设备的一部分)请求PAN的令牌。令牌服务模块222然后可使用多种传输技术来生成并返回令牌，并且可储存令牌与PAN之间的映射以供将来的交易。例如，在实施例中，令牌可被创建有与PAN相同的尺寸(例如，具有相同数量的数字)，具有与PAN相同的BIN值(或相关BIN值的范围内的另一个BIN值)。令牌服务模块222(和/或供应服务模块225)可储存令牌的序列号(例如，0用于PAN的首次令牌创建)、令牌的有效期(例如，从请求日期起的24或36个月)并在框324处可能通过设定其记录内的值或者可能通过修改令牌值本身将令牌设定为“活动”令牌。

在框326处，供应服务模块225准备消息376并向钱包提供商210发送消息376，此消息376包括连同一个或多个供应脚本组一起的令牌(从令牌服务模块222接收的)。在一些实施例中，此消息376包括一个或多个令牌(可被加密)、令牌有效期、相关联的PAN的一部分(例如，最后四位)、相关联的卡元数据、令牌参考标识符、PAN参考标识符、与进一步消息一起返回的令牌和/或个性化脚本。然后，钱包提供商210可在另一个消息378中将来自消息376的信息中的一些或全部(例如，供应脚本和令牌)转发回到移动设备101以使账户的令牌被供应在移动设备101上(通过在框328处执行脚本)。在一些实施例中，供应脚本组包括部分个性化脚本和激活脚本，尽管在一些实施例中，部分个性化脚本和激活脚本所提供的功能被合并到一个(或多个)脚本。

在框379处，服务提供商230可向发行方240传输令牌通知消息379，此令牌通知消息379包括来自消息376的信息中的一些或全部，这些信息包括但不限于：令牌、令牌有效期、PAN的一部分或全部等，用于告知发行方240所生成的令牌。

在执行了由移动设备101在消息378中接收的供应脚本时，移动设备101可向钱包提供商返回令牌激活结果消息380以确认和/或否认令牌(即，支付凭证207)是否被成功供应(即，安装)。钱包提供商230可在令牌激活结果消息381中将此消息380转发到服务提供商230，可将此消息作为消息382进一步转发到发行方240。

返回框318，如果分配的风险值被视为“中等”风险，流程继续到图的底部并导向图4。图4示出描绘根据本发明的一些实施例的关于图2的账户供应系统中的中等风险账户供应的组合序列与流程图400。

圆‘A’指示“中等”风险流程的开始，在框402处服务提供商230以关于“低”风险流程中的框322在上文描述的令牌获取的类似方式获取令牌。因此，服务提供商230可生产令牌，检索储存的令牌，或者向另一个实体请求令牌(例如，第三方令牌提供商服务)。在框404处，令牌被设定为不活动的，可包括修改令牌(例如，对其加密)，和/或修改供应脚本以使令牌被设置为不活动的(即，当前时刻由移动设备101进行支付使用不可用)，诸如通过在移动设备101的存储器位置内设定旗标(例如，在安全元件202的存储器内设定保护旗标)等。在框406处，服务提供商230准备一个或多个供应脚本，在一些实施例中，脚本包括个性化脚本而没有激活脚本。

在消息450中将供应脚本和不活动的令牌发送到钱包提供商210。消息450可包括如关于图3的“低”风险流程中的消息376所描述的项目中的一些或全部，具体地，可包括令牌是不活动的指示符和/或钱包提供商210要从用户107获取动态验证值递送选择(在下文中描述)。然后钱包提供商210在消息中将供应脚本和不活动的令牌转发到移动设备101，其中在框407处执行脚本以使不活动的令牌被安装。类似消息379，服务提供商230可向发行方240传输令牌通知消息453以通知发行方240所生产的令牌及其对于PAN的映射。

在一些实施例中，移动设备101向钱包提供商210传输(未示出)消息以指示不活动的令牌的安装是否成功，并且作为响应，钱包提供商210将设备供应结果消息454传输回到服务提供商230，进而可将设备供应消息454作为消息456转发回到发行方240。

此刻，基于令牌是活动的和/或钱包提供商210要从用户107(从消息450)获取动态验证值递送选择的指示符，钱包提供商210将发送询问消息458以寻求用户对于用户接收动态验证值(DVV)所偏好的方式的选择。在一些实施例中，此DVV用作附加(或“加强的”)用户验证过程的元素，可被使用来增加凭证的最终供应是适当的从而较不可能是欺骗性的信心。在这些示例中，讨论了作为一次性密码的DVV；然而，可采用很多其他验证方法，包括但不限于：经由移动设备101执行关于用户挑战/响应测试(基于合法用户先前提供的或很可能知道的信息)，使用户呼叫电话号码(作为示例，发行方的消费者服务中心的电话号码)来传递一组挑战/响应测试，使用户提交声音样本或其他生物样本(例如，指纹压痕、虹膜扫描、面部图像等)以供识别，或者另一个已知的认证技术。

作为示例，对于DVV的一组递送选项可被呈现给用户，包括但不限于：经由移动支付应用程序的收据，文字消息(例如，短消息服务(SMS)或其他类似的消息服务消息)的收据，打出或接收电话呼叫以获取DVV(例如，向呼叫中心)，对用户的文件上的电子邮件地址发送的电子邮件内的DVV的收据等。用户107可选择这些选项中的一个，因此在框408处，移动设备101将接收用户所选的DVV递送选择，并且向钱包提供商210传输包含所选递送选择的消息460，钱包提供商210将此递送选择在另一个消息462(例如，在“发送OTP”消息中)中转发到服务提供商230。此外，递送选项中的一些或全部可包括模糊化信息，例如诸如部分隐藏/模糊化的电话号码(连同一个或多个错误的电话号码)或电子邮件地址。

在一些实施例中，服务提供商230将通过执行验证请求中传递的令牌参考ID是否有效，令牌对于PAN映射是否已知存在，令牌是否先前已被供应，令牌是否当前处于不活动状态，是否满足或超过OTP代码尝试的最大数量(由发行方所允许的)等中的一个或多个来验证消息462。

此刻，存在若干配置以用于生成和/或验证DVV的输入。尽管在图6中随后示出两个其他变体，在图4中示出第一DVV变体420。然而，在第一DVV变体420中，在框410处，服务提供商230将生成DVV，可包括生成一长度的随机字符/数字/值。例如，在实施例中，DVV是随机生成的四位数字。框410处的生成可进一步包括为所生成的DVV设定有效期/时间，和/或设定指示用户可尝试提供DVV多少次的“重试计数”，这两者可被发送和/或储存。

在此第一变体420，服务提供商230向发行方240传输消费者认真请求消息464(包括用户所选的DVV递送选择和所生成的DVV)。在一些实施例中，如果发行方240没有在配置的超时时期内回复消费者认知响应消息，那么服务提供商230可向钱包提供商210传输错误消息，指示钱包提供商210在特定时间量之后应该发送另一个消息(例如，消息462)。

在接收到消费者认证请求消息464之后，发行方240经由所选的递送选择机制(见消息466)联系消费者170以向用户107提供所生成的DVV。因此，所选的递送选择机制可被认为利用与用户通信的第二“信道“(例如，经由SMS)，如相对于从用户的移动设备101经过钱包提供商210至服务提供商230的第一“信道”。

此刻，DVV根据所选的递送机制被提供到用户107，并且用户可将DVV输入移动设备101(例如，经由移动钱包应用程序)，移动设备101在框412处接收DVV的输入，并在DVV消息468中将DVV传输到钱包提供商210。

此刻，钱包提供商210可传输恢复账户消息470，此恢复账户消息包括输入的DVV(从消息468)以及相应账户的标识符(例如，PAN、参考ID、不活动的令牌等)。服务提供商230可通过执行以下中的一个或多个来验证恢复账户消息470：验证消息470令牌参考ID是否有效，令牌相对于PAN映射是否已知，令牌是否已先前被发行到钱包提供商210，令牌是否处于不活动的状态等。

在框414处，服务提供商230然后基于DVV的储存副本(从它在框410中被生成时)或者通过生成DVV的副本(例如，在DVV是基于限定的而生成时并且可被重新生成的实施例中)来验证DVV。在一些实施例中，服务提供商230还基于DVV提交时间来验证DVV是否已过期和/或验证用户尝试提交DVV的数量是否超过配置的可允许的尝试数量。

如果在框414处DVV未被验证，基于系统实施者的需要存在继续进行的若干(未示出)选项。在一些实施例中，DVV变体中的一个可被执行一个或多个额外的次数，直到DVV被验证或者满足了尝试的数量。在其他实施例中，服务提供商230向钱包提供商210简单地传输错误代码。

然而，当(在框414处)DVV被验证时，服务提供商230可更新其记录以指示令牌现在活动(例如，更新令牌服务模块222为令牌维持的状态)，并且可在消息472中为钱包提供商210生成和/或提供激活脚本，此消息472作为消息474被转发到模块设备101。移动设备101然后可通过执行令牌激活脚本在框416处激活令牌，可使(例如，安全元件102内)令牌的保护旗标被禁用(在框418处)或者可对先前加密的令牌(在框419处)解密。在一些实施例中，移动设备101向钱包提供商210报告令牌激活是否成功的指示符(为图示出，可包括账户/令牌的标识符和是/否或者令牌的激活成功或失败的其他描述)，钱包提供商210然后向服务提供商230传输令牌激活结果消息476，服务提供商230可向发行方240转发此结果。此刻，“中等”流程在框422处结束。

图5示出根据本发明的一些实施例的用于账户供应的服务器计算机的流程500。在一些实施例中，流程500的操作可由服务提供商230服务器计算机212执行，而在一些实施例中，流程500的操作由供应服务模块225执行。

流程500在框502处包括在第一通信信道上接收供应请求以向移动设备供应用户的账户的支付凭证207。第一通信信道可包括从服务提供商230服务器计算机212到钱包提供商210的连接。供应请求可包括账户的PAN，而在一些实施例中可包括PAN的参考标识符而不是实际PAN本身。账户可以信用卡账户、借记卡账户、支票或储蓄账户、预付账户等。支付凭证207可包括以下中的一个或多个：账户的账号、与账户相关联的令牌、令牌或账号的有效期、与账户相关联的个人信息、被用于对与关于账户的交易相关联的信息加密和/或解密的公共和/或私有密钥、账户的卡样式(例如，诸如实际借记卡或支付设备的描绘之类的图像)、与账户相关联的用户的标识符和/或名称、与账户相关联的发行方的标识符和/或名称等。

在框504处，流程500包括确定与供应请求相关联的风险等级。风险等级的此确定可包括对请求的用户、卡、移动设备或存在于接收的供应请求中的任何其他数据(例如，CVV2值、ZIP码、用户标识符等)或与供应请求相关联的消费者的账户绑定的任何其他数据(例如，先前登记/供应的卡数据等)执行风险校验或风险分析风险分析所使用的模型可根据操作者的期望来配置，并且可考虑到钱包提供商在每一次请求中提供的历史信息(例如，账户已开户多久，消费者使用此卡的次数，过去的购买的数字或数量等)。模型也可将关于账户上的消费模式的支付处理网络数据与网络等级欺骗趋势(例如，数据妥协趋势、消费的共同商家/目录)相结合。

在判决框506处，流程500包括风险等级低于预定的风险阈值范围，在预定的风险阈值范围内还是在预定的风险阈值范围以上的确定。在一些实施例中，风险等级被设定为“高”(即，风险阈值范围以上)、“中等”(即，风险阈值范围内)或“低”(即，风险阈值范围以下)。在一些实施例中，风险阈值范围限定描写风险值的至少三个类别的值的范围。例如，在生成的风险值是0与100之间的数字的实施例中，预定的风险阈值范围可被配置为[0025,50]，因此，大于或等于25以及小于或等于50的任何生成的风险值分数将被视为“中等”风险，在该范围以上(即，大于50)的任何风险值被视为“高”风险，低于此范围(即，小于25)的任何风险分被视为“低”风险。当然，可使用其他范围/截点来配置其他预定的风险阈值范围，并且可根据生成的风险分的不同类型(例如，整数、实数、字母等)和方案来配置。

在图示的实施例中，如果风险等级被视为低于预定的风险阈值范围(即，“低”风险)，那么流程500包括在框508处使支付凭证207被供应到移动设备。在一些实施例中，这包括由移动设备执行的一个或多个供应脚本组以使支付凭证207以激活的状态供应。在一些实施例中，此传输由作为目的地的钱包提供商作出，并且钱包提供商然后将此供应脚本组转发到移动设备以供执行。在一些实施例中，供应脚本组包括包含账户供应数据的个性化脚本和激活脚本，当执行这些脚本时，使供应的账户凭证207以活动状态(即，能够由移动设备使用以便于支付交易)被供应。在其他实施例中，供应脚本组包括供应账户凭证的仅一个脚本。

在图示的实施例中，如果风险等级被视为在预定的风险阈值范围以上(即，“高”风险)，那么流程500包括在框510处传输指示供应请求被拒绝的供应请求拒绝消息。在一些实施例中，供应请求拒绝消息被传输到钱包提供商，钱包提供商然后在供应请求拒绝消息上转发到用户的移动设备或者以其他方式将消息传输到移动设备以指示已拒绝供应请求。

如果在图示的实施例中风险等级被视为在预定的风险阈值范围内(即，“中等”风险)，流程500继续，在框512处可选地优化下列：传输要由移动设备执行的供应脚本组以使支付凭证207以不活动状态储存在移动设备上。在一些实施例中，供应脚本组包括个性化脚本，当执行此个性化脚本时，供以不能被移动设备使用的非活动状态供应支付账户凭证207。例如，在一些实施例中，供应的令牌被模糊化(加密的或以其他方式转变的)为无效的，在一些实施例中，保护旗标被设定(例如，在移动设备101安全元件202内)以使得移动设备101不能访问支付凭证207。在一些实施例中，框512的执行允许一些凭证-供应工作被“提早”执行(即，在实际允许凭证被激活的时间之前)，通过允许这些可能的相对计算昂贵的步骤被提前执行并且使用之后执行的(例如，在框530处)相对计算轻量脚本来激活预供应但不活动的账户凭证，可从时间的角度分配所需要的工作负载然而，在一些实施例中，不执行此框512，并且所有支付账户凭证供应随后发生在框526处。

在框514处，流程500包括使认证过程由用户107来执行。在一些实施例中，此认证过程包括在框516处使动态验证值(DVV)经由第二通信信道被提供到用户。在一些实施例中，第二通信信道包括账户的发行方240与用户107之间的通信，并且可不包括服务提供商230与用户107或者服务提供商230与钱包提供商210之间的任何直接通信。在一些实施例中，此通信信道包括发行方传输SMS消息、电子邮件，打出或接收与用户的电话呼叫，向用户传输网页等。在一些实施例中，DVV包括一次性密码(OTP)。在一些实施例中，OTP由服务提供商230生成，而在一些实施例中，OTP由发行方240生成。在一些实施例中，服务提供商230服务器计算机212生成(或获取)OTP并将其提供(在框518处)到管理用户的账户的发行方计算机106以便传递给用户。在一些实施例中，发行方计算机106生成OTP并将OTP传输到用户107(经由第二通信信道)以及服务提供商230服务器计算机212以使服务器计算机212能够在之后验证OTP的用户输入。然而，在一些实施例中，发行方计算机106生成OTP但不需要向服务提供商230服务器计算机212提供OTP。例如，发行方计算机106可根据确定的算法生成OTP从而使得可基于服务器计算机212使用相同的算法再次生成OTP由服务提供商230服务器计算机212来验证OTP。因此，在经由第二通信信道向用户107提供DVV之后的某时刻，用户107可经由移动设备101返回DVV。这可使移动设备101向钱包提供商210发送输入的DVV，钱包提供商210进而可在框520处为服务提供商230服务器计算机212生成并提供包含输入的DVV的消费者验证响应消息。

在框522处，流程500包括确定认证过程是否成功。例如，确定可包括消费者验证响应消息内的用户输入的DVV是否是“正确的”动态验证值的确定。在一些实施例中，此确定包括查找DVV的储存副本(例如，由服务提供商230、发行方240或第三方生成的)并将其与接收的DVV相比较以确定他们是否是相同的。在一些实施例中，此确定包括使用DVV-生成算法(例如，先前用来生成DVV的)来生成DVV并将所生成的DVV与接收的用户输入的DVV相比较。在一些实施例中，当消费者验证响应消息内的用户输入的DVV与“正确的”DVV不同时，认证过程被示为失败并且流程继续进行到框524处，其中发送错误消息。在一些实施例中，此消息被传输到钱包提供商210和/或发行方计算机106。

然而，在一些实施例中，当认证过程被视为已成功(例如，用户提供的DVV与“正确的”DVV相同)，流程500继续进行框526，包括使支付凭证207被供应到移动设备上。在一些实施例中，这包括使(先前)供应到移动设备上的支付凭证207从不活动状态切换为活动状态，可包括对账户的令牌解密/去模糊化，改变数据保护流程(例如，安全元件202内)等。在一些实施例中，此供应包括在框530处传输由移动设备执行的激活脚本。在一些实施例中，激活脚本被发送到钱包提供商210，钱包提供商210进而向移动设备101提供激活脚本，使激活脚本被执行从而支付凭证207被安装/激活。在一些实施例中，服务提供商230服务器计算机212还从钱包提供商210接收令牌激活结果消息381，指示供应是否成功，并且可将此信息382转发到发行方240。在一些实施例中，服务提供商230服务器计算机212还可向发行方240传输令牌通知消息379以通知发行方240令牌以及与其相关联的账户。

V.生成并验证动态验证值的变体

图6示出描绘根据本发明的一些实施例的账户供应系统中的两个动态验证值确认配置600A-600B的组合序列与流程图。在一些实施例中，图4的第一DVV变体420被替换为第二DVV变体600A或第三DVV变体600B中的一个。然而，这只是少数可能的DVV变体，可利用可能或可能不包括来自这些变体的特征的其他变体。在服务提供商230服务器计算机212从钱包提供商210接收到DVV递送选择消息462之后，第二与第三DVV变体600A-600B开始。

第二DVV变体600A包括：(代替如在图4的框410中生成DVV)向发行方240传输DVV请求消息650(包括DVV递送选择消息462中指示的递送选择)，发行方240本身将在框602处生成DVV；根据第二通信信道上的递送选择在框466处向用户提供DVV；以及在消息652中将生成的DVV返回到服务提供商230。在框604处，服务提供商230可储存此DVV。在用户在第二通信信道上接收到DVV之后，用户将此DVV输入移动设备101(例如，使用移动钱包应用)，移动设备101将向钱包提供商210在消息468中发送输入的DVV。钱包提供商210然后将向服务提供商230传输包含DVV的恢复账户消息470，服务提供商230可通过在框606处验证DVV确定认证的有效性，这包括将储存的DVV(来自框604)与接收的用户输入的DVV(来自消息470)相比较。如果值匹配或以其他方式被视为等效，那么DVV被验证从而认证成功；否则，DVV不被验证且认证失败。

第三DVV变体600B与第二DVV变体600A类似，除了几个关键的差异。首先，在第三DVV变体600B中，发行方240不将生成的DVV报告回服务提供商(见第二DVV变体600A的消息652)。相反，当服务提供商230接收包含用户输入的DVV的恢复账户消息470时，服务提供商230可在框608处根据算法验证DVV。在一些实施例中，发行方240使用服务提供商230已知的特定算法生成DVV 602，从而使得服务提供商230可重新生成DVV本身(使用相同算法)或者反转算法以使得它能“复原”用户提供的DVV值以达到明文值，并且随后测试此明文值以确定它是否正确地格式化。例如，在实施例中，发行方240可通过对明文值加密(利用发行方240私有密钥)来生成DVV 602，例如，该明文值是基于与用户相关联的值(例如，账户的PAN、用户标识符等)并且进一步基于当前日期或时间值(当然，对于创建明文值存在很多其他可能性，并且此提供的示例仅仅说明一个可能使用情况)。因此，服务提供商230可访问发行方240的公共密钥，对用户提供的DVV解密，并且确定所得明文值是否包括正确的PAN和正确的日期/时间值。

VI.使用消费者特定加密密钥的安全通信

在所公开的实施例中的很多中，信息经由钱包提供商210在用户107(和移动设备101)与服务提供商230或发行方240之间流动。然而，消费者具有显著的隐私担忧，并且当消费者数据从信息源传递到消费者时，第三方(诸如钱包提供商210)通常可在传输中持有消费者数据。例如，用户107的大量可能敏感的金融/交易数据流过钱包提供商210。因此，在第三方系统可向消费者设备(例如，移动设备101)路由交易警告、交易历史、支付凭证等的情况下，需要保护敏感数据。

当服务提供商230(例如，支付处理网络105)与移动通信设备101不直接通信时，向移动通信设备提供加密密钥是一个问题，因为加密密钥被传递经过第三方计算机(例如，服务器计算机211)并且第三方计算机可访问并使用密钥以对将来的通信解密。如此，经由第三方服务器向移动设备101递送交易历史数据的传统方法不能使用TLS/SSL隧道来实施以充分保护数据，由于TLS/SSL隧道终止在第三方服务器计算机处，因此给予第三方服务器计算机对数据不受阻碍的访问。

然而，通过将唯一的消费者特定的密钥合并到设计为被供应到用户的移动通信设备101上的供应脚本(早先关于支付凭证供应所描述)中，加密密钥可被保护免受第三方的截取，因为可用与移动通信设备101的安全元件202上的安全存储区相关联的安全元件密钥对此脚本加密。因此，利用第三方计算机无法访问的密钥对供应脚本加密，并且嵌入式消费者特定密钥可在具有用户的支付令牌或其他支付凭证的移动支付应用程序的个性化过程期间被供应到安全元件上。之后，唯一的消费者特定加密密钥可通过与移动通信设备上的移动支付应用程序的通信来访问并且用于对移动通信设备处接收的加密通信信息解密。

因此，本发明的实施例为敏感数据(例如，交易警告、其他消费者数据、交易历史等)提供更好的安全性。例如，具有特定消费群的第三方可能想要为其消费者提供交易警告，但可能不期望第三方能够查看警告消息中的数据，由于该信息可被视为对于消费者是机密的，并且第三方可能不想要访问交易警告数据。本发明的实施例可在数据源(例如，服务提供商230/支付处理器105)和数据目的地(例如，在终端用户的移动设备101中)纳入加密密钥。因此，敏感消息可从服务提供商230经过第三方计算机系统(例如，钱包提供商210服务器计算机211)传递到用户的移动设备101。用户的移动设备101可包括加密密钥从而它们可对敏感数据解密。

图7示出描绘根据本发明的一些实施例的经由钱包提供商的消费者特定加密密钥供应与安全消息传输的组合序列与流程图700。在此图示的实施例中，利用公共/私有密钥的非对称密码学技术被用于数据保护，尽管在其他实施例中可类似地使用其他模糊化技术。

图7示出消费者特定加密密钥(CSEK)供应方案760以安全地供应CSEK以供使用。在此实施例中，移动设备101在消息750A中提供安全元件加密密钥(SEEK)，可以是允许其他实体对消息加密的公共密钥，仅可由移动设备101的安全元件202(例如，使用相关联的私有密钥)读取(即，解密)。在其他实施例中，此密钥不与安全元件202相关联，然而，它只是与移动设备101的私有密钥相关联的公共密钥。钱包提供商210可在消息750B中将此SEEK转发到服务提供商230。

在框702处，服务提供商230可获取或生成一组消费者特定加密密钥。例如，服务提供商230可生成公共密钥和私有密钥以被使用在与移动设备101的通信中。此密钥可以是

服务提供商230然后可在框704处在包(package)中包含公共CSEK与供应脚本，并使用由移动设备101最初提供的SEEK对此包加密。因此，即使此包通过钱包提供商210在消息752A和752B(以及其他实体的潜在计算设备)路由/转发，这些实体不能访问包中的公共CSEK或供应脚本，由于仅移动设备101具有对应的私有密钥以允许它“打开”此包。尤其注意的是此包(在消息752A和752B)(包含公共CSEK)可以是当在图3和4的任一个中生成/发送供应脚本所发送的。例如，在框326(在图3的“低”风险流程中)处的供应脚本的准备可包括准备包含脚本和公共CSEK的包。类似地，例如，框406(图4的“中等”风险流程中)处的供应脚本的准备和/或令牌激活脚本的传输(见消息472)可类似地包括发送包含供应脚本和/或公共CSEK的公共SEEK加密的包。当然，在一些实施例中，公共SEEK加密的包可不包括供应脚本(例如，诸如当它们不包含敏感信息时)但可包括诸如公共CSEK之类的其他数据。

转回图7，在CSEK供应方案760之后，经由CSEK密钥的使用，服务提供商230和移动设备101因此被启用以安全地通信，而钱包提供商210或另一个实体不会知晓所传输的数据。例如，在框716处，服务提供商230可产生一消息，诸如账户警告消息(例如，基于违反配置规则的金融交易事件)或交易历史消息(例如，列举用户的账户的一个或多个先前交易)。然后在框718处服务提供商230可使用私有CSEK对此消息加密以产生加密的消息。此加密的消息可作为消息754A从服务提供商230发送到钱包提供商210，到达移动设备101(作为消息754B)。移动设备101然后可在框720处使用公共CSEK对加密的消息解密，它可能已在加密的包752B中接收到该消息，作为支付凭证207供应脚本的收到的一部分。移动设备101然后可在内部利用此消息，和/或可在框722处向用户107显示此消息。类似地，在某一时间点，移动设备101可在框720处使用公共CSEK对用于服务提供商230的消息加密，然后可向服务提供商230安全地传输此消息。

在一些实施例中，加密和/或解密可通过安全移动支付应用程序206发生在移动设备101的安全元件202处，安全移动支付应用程序206嵌入或安装在移动设备101的安全元件202上。通过在安全元件202处执行加密/解密，在消息中接收到的加密密钥和信息可被进一步保护免受恶意第三方影响，恶意第三方可能在移动设备101的通用存储器中安装恶意软件。因此，可在一些实施例中实现加密和解密过程的更加安全的实施方式。

VII.唯一的交易标识符

来源于移动设备101的支付交易为消费者提供方便的支付选项，但会导致不完全的且复杂的交易处理和报告问题。例如，移动设备101仅可在发起交易的时候访问部分交易数据，因此位于移动设备101上的移动支付应用程序208C、206可能不能访问完整的交易细节而仅可具有部分交易日志204。因此，由移动设备101上的近场通信(NFC)芯片发起的支付可导致数个不成功的支付尝试，由于复杂的射频环境或过期的终端软件和/或硬件。然而，当NFC支付不成功时，储存在移动设备101上的交易日志204中的信息可能不匹配储存在交易处理系统内的不同实体处的交易信息(例如，支付处理网络105、商家103、收单方104、发行方240等处的交易日志224)。因此，需要一种使交易处理系统的后端上接收的交易与移动设备101处发起的那些交易相匹配的方法。因此，需要容易且有效地标识交易处理系统的前端与后端之间的唯一交易。本发明的各实施例分别地并共同地解决这些及其他问题。

一个实施例涉及一种使用共享摘要在移动设备101上生成唯一交易标识符的方法。此方法包括从移动设备101发起支付交易。此方法通过以下步骤继续进行：根据共享摘要选择与支付交易相关联的交易元素，根据预定散列算法散列所选的交易元素，以及连接所散列的交易元素。唯一交易标识符然后储存在交易日志204中。另一个实施例涉及一种使用唯一交易标识符匹配交易的方法。此方法包括接收来源于移动设备101的交易的授权请求消息并生成此交易的唯一交易标识符。使用授权请求消息中的共享摘要和预定交易元素生成唯一交易标识符。服务器计算机(例如，服务器计算机212)向移动设备发送包含唯一交易标识符的交易匹配信息。移动设备101在交易日志204内搜索与唯一交易标识符相关联的交易，标识与唯一交易标识符相关联的交易信息，以及用交易匹配信息更新交易日志。此外，其他实施例可涉及使用本文所述的交易标识技术以供数个不同的用途，包括：交易报告、忠诚度计划监测以及期望在前端系统与后端系统之间匹配交易数据的任何其他用途。

为了这些目的，图8示出描绘根据本发明的一些实施例的用于交易日志更新的唯一交易标识符的使用的组合序列与流程图800。图示的实施例涉及将完整交易信息提供到位于移动设备101处的交易日志204。

例如，在框802处，由移动设备101使用支付应用程序发起交易。此刻，移动设备101仅可访问部分交易信息。在框804处，移动设备101根据算法生成用于交易的第一唯一交易标识符(UTI)。在框806处，移动设备101在交易日志204的记录中储存第一UTI连同交易的部分交易信息，可储存在“通用”存储器或仅可由安全元件202访问的存储器中。

因此，服务提供商230(例如，支付处理网络105)服务器计算机212在框808处接收授权请求消息或授权响应消息。服务提供商230在框810处根据算法生成用于交易的第二UTI，并且此第二UTI将具有与移动设备101所生成的第一UTI相同的值。服务提供商230可通过经由具有完整交易信息的消息850和851(即，从而包含还不属于交易日志204的“额外”交易信息)向移动设备101发送交易匹配信息(例如，第二UTI)来更新移动设备101交易日志204的交易信息。

移动设备101在框814处可基于所接收的第二UTI识别此交易的交易日志204的记录。在实施例中，移动设备101将通过在交易日志内搜索具有与所接收的第二UTI相同的值的储存的UTI的记录来执行此识别。在发现匹配时，此记录被选为交易记录，并且移动设备101可在框818处基于在消息851中接收的额外交易信息来更新记录。因此，服务提供商230可使用共享摘要(或索引)以生成唯一交易标识符，服务提供商230和移动设备101可使用共享摘要来识别与交易匹配相关联的交易。

使用类似的方案，本发明的实施例还使移动设备101能够向服务提供商230报告UTI。例如，另一个实施例允许服务提供商230通过接收关于移动设备101所尝试的不成功交易的信息来确定具有故障或过期终端(例如，访问设备102)的商家。因此，当服务提供商230在交易处理系统中接收授权请求消息时，服务器计算机能够使用授权请求消息中的数据元素上的散列算法生成唯一交易标识符并且可向移动设备发送唯一交易标识符。移动设备101然后可标识与所接收的唯一交易标识符相关联的交易并且可向服务提供商230报告自从上次报告的交易起的任何不成功交易。因此，服务提供商230能够确定不成功交易的数量，与这些交易相关联的商家，以及来自交易日志的任何其他相关信息。

VIII.示例性计算机系统

本文所述的多种参与方和成分可操作一个或多个计算机装置来促进本文所述的功能。上述图1-8中的任何元件，包括任何服务器或数据库，可使用任何适当数量的子系统来促进本文所描述的功能。

这些子系统或组件的示例在图9中示出。图9中示出的子系统经由系统总线902互相连接，系统总线902可包含一个或多个总线。示出了附加的子系统，诸如打印机910、键盘918、固定盘920(或包含计算机可读介质的其他存储器，可包括非瞬态计算机可读存储介质)、耦合到显示器适配器914的监视器912(或“显示器设备”)等。耦合到I/O控制器904(可以是处理器或其他适当的控制器)的外围设备和输入/输出(I/O)设备可通过本领域已知的任何数量的装置(诸如串行端口916(或USB端口、并行端口等))连接到计算机系统。例如，串行端口916或外部接口922可被用于将计算机装置连接到诸如因特网之类的广域网(WAN)、鼠标输入设备、或者扫描仪。经由系统总线902的互连允许中央处理器908(可包括一个或多个处理单元、处理器核心、其组合等)与每一子系统通信，且允许控制来自系统存储器906或固定盘920的指令的执行以及各子系统之间的信息的交换。系统存储器906和/或固定盘920可包括计算机可读介质，诸如非瞬态计算机可读存储介质。

本申请中所描述的软件组件或功能中的任何一个都可以实现为软件代码，处理器使用例如常规的或面向对象的技术，并使用任何合适的计算机语言(诸如例如，Java、C++、C、Python、JavaScript或Perl)来执行的这些软件代码。软件代码可以作为一系列指令或命令被存储在计算机可读介质上，计算机可读介质诸如，随机存取存储器(RAM)、只读存储器(ROM)、诸如硬驱动器或软盘之类的磁介质，或诸如CD-ROM之类的光介质。任何此类计算机可读介质都可以驻留在单个的计算装置上或单个的计算装置内，并可以存在于系统或网络内的不同的计算装置上或不同的计算装置内。

上文的描述仅是说明性的，而不是限制性的。在本领域技术人员阅读了本公开时，本发明的许多变体对于他们会变得显而易见。因此，可不参考以上描述来确定本发明的范围，相反，可以参考待审查的权利要求书以及它们的完整范围或等效方案来确定本发明的范围。

来自任何实施例的一个或多个特征可以与任何其他实施例的一个或多个特征相结合而不背离本发明的范围。

对一(“a”、“an”)或“所述”(“the”)的引用旨在是指“一个或多个”，除非特别指示为相反的情况。

以上提及的所有专利、专利申请、出版物、以及描述出于所有目的通过引用整体纳入于此。没有任何内容被承认为是现有技术。

Claims (20)

1.一种用于为移动装置配置支付凭证的方法，包括：

从所述移动装置向服务器计算机发送在所述移动装置上配置所述支付凭证的配置请求，其中所述支付凭证与用户的账户相关联；

当与所述配置请求相关联的风险等级在预定风险阈值范围内时：

由所述移动装置接收第一组配置脚本；

由所述移动装置执行所述第一组配置脚本以使所述支付凭证以非活动状态存储在所述移动装置处；

由所述移动装置以所述非活动状态存储所述支付凭证，其中所述非活动状态不允许所述移动装置在对所述用户执行认证过程之前利用所述支付凭证进行金融交易；

响应于所述认证过程的成功执行，由所述移动装置接收激活脚本；

由所述移动装置执行所述激活脚本，以将所述支付凭证从所述非活动状态切换到允许所述移动装置使用所述支付凭证进行金融交易的活动状态；

当与所述配置请求相关联的所述风险等级低于所述预定风险阈值范围时：

由所述移动装置接收第二组配置脚本；

由所述移动装置执行所述第二组配置脚本，以使所述支付凭证以所述活动状态存储在所述移动装置处，而无需对所述用户进行所述认证过程；以及

由所述移动装置使用所述支付凭证发起金融交易。

2.根据权利要求1所述的方法，还包括：

当所述风险等级达到或超过所述预定风险阈值范围时，

由所述移动装置接收指示所述配置请求被拒绝的配置请求拒绝消息。

3.根据权利要求1所述的方法，其中执行所述激活脚本还包括：

由所述移动装置基于执行所述第一组配置脚本，将与所述支付凭证相关联的保护标志存储在所述移动装置的存储器中，所述保护标志表示所述支付凭证的所述非活动状态；以及

由所述移动装置禁用与所述移动装置的安全元件内的所述支付凭证相关联的所述保护标志。

4.根据权利要求1所述的方法，其中：

所述认证过程包括经由单独的通信信道提供给所述用户的动态验证值；并且

所述认证过程的所述成功执行包括所述用户提供包括所述动态验证值的消费者验证响应。

5.根据权利要求1所述的方法，还包括：

由所述移动装置从所述服务器计算机接收所述第一组配置脚本或所述第二组配置脚本中的一组消费者特定加密密钥中的至少一个；

由所述移动装置从钱包应用程序提供商接收由所述服务器计算机使用所述一组消费者特定加密密钥之一加密的加密通信消息，其中所述钱包应用程序提供商不具有所述一组消费者特定加密密钥中的任一个；以及

由所述移动装置使用所述一组消费者特定加密密钥中的所述至少一个来解密所述加密通信消息。

6.根据权利要求1所述的方法，其中所述第一组配置脚本或所述第二组配置脚本使用与所述移动装置的安全元件上的安全存储器区域相关联的安全元件密钥加密。

7.根据权利要求1所述的方法，还包括：

在与交易实体的所述金融交易期间，由所述移动装置将所述活动状态的所述支付凭证发送到所述交易实体。

8.根据权利要求1所述的方法，其中所述第一组配置脚本或所述第二组配置脚本由所述移动装置在所述用户的所述账户被激活之前接收。

9.根据权利要求1所述的方法，还包括：

由所述移动装置从所述服务器计算机接收涉及与所述用户的所述账户相关联的所述支付凭证的所述金融交易的唯一交易标识符和额外交易信息；

由所述移动装置基于所述唯一交易标识符标识交易日志的记录；以及

由所述移动装置基于所述额外交易信息更新所述记录。

10.根据权利要求1所述的方法，其中所述配置请求包括所述用户的所述账户的主账号(PAN)的参考标识符而非所述PAN。

11.一种移动装置，包括：

一个或多个处理器；以及

非瞬态计算机可读存储介质，其与所述一个或多个处理器通信地耦合并且存储指令，所述指令在由所述一个或多个处理器执行时使所述移动装置执行包括以下项的操作：

向服务器计算机发送在所述移动装置上配置支付凭证的配置请求，其中所述支付凭证与用户的账户相关联；

当与所述配置请求相关联的风险等级在预定风险阈值范围内时：

接收第一组配置脚本；

执行所述第一组配置脚本以使所述支付凭证以非活动状态存储在所述移动装置处；

以所述非活动状态存储所述支付凭证，其中所述非活动状态不允许所述移动装置在对所述用户执行认证过程之前利用所述支付凭证进行金融交易；

响应于所述认证过程的成功执行，接收激活脚本；

执行所述激活脚本，以将所述支付凭证从所述非活动状态切换到允许所述移动装置使用所述支付凭证进行金融交易的活动状态；

当与所述配置请求相关联的所述风险等级低于所述预定风险阈值范围时：

接收第二组配置脚本；

执行所述第二组配置脚本，以使所述支付凭证以所述活动状态存储在所述移动装置处，而无需对所述用户进行所述认证过程；以及

使用所述支付凭证发起金融交易。

12.根据权利要求11所述的移动装置，其中所述操作还包括：

当所述风险等级达到或超过所述预定风险阈值范围时，

接收指示所述配置请求被拒绝的配置请求拒绝消息。

13.根据权利要求11所述的移动装置，其中执行所述激活脚本还包括：

基于执行所述第一组配置脚本，将与所述支付凭证相关联的保护标志存储在所述移动装置的存储器中，所述保护标志表示所述支付凭证的所述非活动状态；以及

禁用与所述移动装置的安全元件内的所述支付凭证相关联的所述保护标志。

14.根据权利要求11所述的移动装置，其中：

所述认证过程包括经由单独的通信信道提供给所述用户的动态验证值；并且

所述认证过程的所述成功执行包括所述用户提供包括所述动态验证值的消费者验证响应。

15.根据权利要求11所述的服务器计算机，其中所述操作还包括：

从所述服务器计算机接收所述第一组配置脚本或所述第二组配置脚本中的一组消费者特定加密密钥中的至少一个；

从钱包应用程序提供商接收由所述服务器计算机使用所述一组消费者特定加密密钥之一加密的加密通信消息，其中所述钱包应用程序提供商不具有所述一组消费者特定加密密钥中的任一个；以及

使用所述一组消费者特定加密密钥中的所述至少一个来解密所述加密通信消息。

16.根据权利要求11所述的服务器计算机，其中所述第一组配置脚本或所述第二组配置脚本使用与所述移动装置的安全元件上的安全存储器区域相关联的安全元件密钥加密。

17.根据权利要求11所述的移动装置，其中所述操作还包括：

在与交易实体的所述金融交易期间，将所述活动状态的所述支付凭证发送到所述交易实体。

18.根据权利要求11所述的移动装置，其中所述第一组配置脚本或所述第二组配置脚本由所述移动装置在所述用户的所述账户被激活之前接收。

19.根据权利要求11所述的移动装置，其中所述操作还包括：

从所述服务器计算机接收涉及与所述用户的所述账户相关联的所述支付凭证的所述金融交易的唯一交易标识符和额外交易信息；

基于所述唯一交易标识符标识交易日志的记录；以及

基于所述额外交易信息更新所述记录。

20.根据权利要求11所述的移动装置，其中所述配置请求包括所述用户的所述账户的主账号(PAN)的参考标识符而非所述PAN。

Images