CN107408253A

CN107408253A - 电子支付的安全处理

Info

Publication number: CN107408253A
Application number: CN201680016674.8A
Authority: CN
Inventors: 爱迪生·U·奥尔蒂斯; 特里·W·李; 加布里埃尔·Y·乌; 史蒂芬·詹姆斯·斯科特; 卫强·殷; 朱迪·丁; 柴·拉姆
Original assignee: Royal Bank of Canada
Current assignee: Royal Bank of Canada
Priority date: 2015-01-19
Filing date: 2016-01-19
Publication date: 2017-11-28
Anticipated expiration: 2036-01-19
Also published as: US20220020015A1; CN113379401A; CA2974151C; CN113379401B; CA2974151A1; US20230289793A1; EP3248159A4; AU2016208989A1; US20160210626A1; AU2022201325A1; US11687928B2; CN107408253B; US11080700B2; WO2016115620A1; AU2024200874A1; AU2022201325B2; AU2016208989B2; EP3248159A1

Abstract

用于数据处理的系统(100)、方法和机器可执行的数据结构，用于在电子支付交易和其他安全数据处理中有用的电子数据的安全创建、管理、操作、处理和存储。这种系统(100)的方面包括可信平台(120)，通过该平台，网络通信设备(110)和商家系统(130)可以注册为可信实体(110'、130)。与特定支付手段相关的信息，如账户或支付令牌，可以存储在已知为虚拟或电子钱包(112)的设备安全数据集中，或以安全支付令牌的形式存储。由设备(110)执行的公共应用程序编程接口可以方便电子钱包(112)和其他安全数据存储(136、120、160)之间的推送和提取过程。因此，用户(190)可以直接从可信设备(110')的应用程序内部发起和完成电子交易。

Description

电子支付的安全处理

免责声明

本申请中公开的材料涉及在处理支付交易中有用的数据的创建、管理、操作、处理和存储。这些创建、管理、操作、处理和存储的方面可能受到政府和其他机构的法规约束。本文的公开仅根据逻辑、功能、经济和通信的可能性做出，而不考虑法令、法规或其他法律考量。本文没有内容旨在作为一个声明或表明，本文所提出或探讨的任何材料或其用途遵守或不遵守任何法令、法律、法规或其它具有任何管辖权的法律要求。

相关申请的交叉引用

本申请要求以下每个申请的优先权等所有权利和权益：于2015年1月19日提交的名为“用于移动支付的应用程序内处理的主机卡仿真”的第62/105,061号美国临时专利申请，于2015年7月2日提交的名为“电子支付的安全处理”的第62/188,067美国临时专利申请，和于2015年8月4日提交的名为“电子支付的安全处理”的第62/200,859号美国临时专利申请，以上每个申请的全部内容通过引用并入本案。

技术领域

本发明主要涉及电子信号交换的安全执行，更具体地涉及用于多方数据处理的安全协商、授权、执行和确认的改进的系统、方法和编程结构。

背景技术

电子支付是一种给人们提供了显著益处的电子信号交换或电子数据交易。除去众多益处之外，这种交易也与多种风险相关。尽管多种不同形式的这种交易已被提出，但在包括如安全性、效率和可用性方面仍然有很大的改进空间。

移动和其他电子商务支付不同于如现金、借记卡和信用卡这类更传统的支付形式，是使用移动、桌面或其他设备进行交易的电子支付的不同分类。一些移动和电子商务支付交易使用移动或其他虚拟钱包，该移动或其他虚拟钱包是用户设备上的存储用户个人信息的程序或应用程序，该用户个人信息包括用于一个或多个被授权的支付方法的凭证。例如，用户可以输入和存储多个信用卡号码、银行账号、优惠券、忠诚度、礼品和奖励计划账号等等，并且通过使用钱包中内置的逻辑功能，选择几个支付方式中的某一个以针对交易使用，指定和确认支付金额和其他交易详情，并且以其他方式管理或控制交易以及在交易中使用的账户。安全元件、加密、令牌化以及其他技术的使用可用于增强移动和其他虚拟钱包的安全性，并保护用户的支付凭证和其他存储在内部的敏感信息。

这种虚拟钱包的一个明显的局限是迄今为止这种钱包已经与个人账户管理方如发放信用卡的金融机构(FI)、活期/存款账户的银行等相关。这对于被授权以借助于由一个以上FI管理的账户来完成交易的消费者或其他购买者来说可能导致明显的不便。

为了通过使用虚拟钱包来发起许多类型的交易，用户可以接近一个商家销售点(POS)终端并拿出移动设备以用于扫描或其他某种类型的数据交换。例如，在一个近场通信(NFC)交易中，当两者彼此靠近时，NFC读取器将向移动设备请求支付凭证和/或其他特定交易的信息。类似地，通过使用在移动设备显示以用于由商家POS终端进行扫描的可视图案，如条形码和QR码，支付凭证和交易信息可以在移动钱包和商家POS终端之间进行交换。移动支付交易还可能在它们被处理之前需要某种类型的用户认证，例如输入PIN或识别生物特征，尽管用户认证并不总是被要求。

或者，通过使用移动或固定计算设备来导航至或以其他方式访问商家的电子商务网站和/或应用程序，并在随后使用如键盘、小键盘、触摸屏等的输入设备来输入适用于发起与商家交易系统相关的通信会话的命令，电子交易可以被发起。

因此，除了在移动设备和商家POS终端之间完成的非接触式交易之外，另一种类型的移动或由台式机发起的支付可能在用户直接从与商家相关的网站、应用程序或程序中发起与商家的交易时发生。这种交易有时被称为无卡(CNP)交易，因为用户和用户的支付卡(或任何功能上的等价物)均未在商家机构或POS终端上实体到位以发起交易。最初，CNP交易最常通过电话或通过邮件发起，但现在也可以通过计算机通信网络如因特网的、公共交换电话系统(PSTN)，或者另外通过使用支持网络的交易请求通信设备发生。

在通过使用计算机通信网络处理交易和交易数据时，将用户的信用卡信息(例如发卡机构、信用卡号、有效日期等)直接提供给商家应用程序或其他接口来发起支付可能不安全。这会造成这类敏感信息被不必要的一方分享的风险。例如，这种不必要的分享可以导致信用卡信息容易受到针对用户的移动设备、商家服务器或支付网络内其他部分发起的恶意攻击的影响。除了潜在的安全问题外，在用户每次想要开始购买时都必须在移动或桌面应用程序，或可能在许多不同的应用程序中重复提供信用卡信息可能是麻烦、耗时且令人烦恼的。能够在应用程序内交易而无须每次重新输入信用卡信息，且没有可能披露敏感的个人信息，将解决或改善CNP交易的这些和其他缺点。

无论是在商家POS终端还是从能访问与商家相关的网站、应用程序或其他程序的网络移动或桌面用户请求通信设备发起，交易数据也可以经由潜在的许多不同的支付网络之一传送用于与银行或金融机构的处理、授权和结算。然而，由于每个商家或商家程序或应用程序可以与一个不同的支付网络相关，所以用户可能受到该商家或应用程序可用的支付类型和/或方式限制。例如，一个商家可能不接受某种支付类型，和/或一个或多个活期存款账户可能没有足够资金(或其他支付资源)来完成交易。作为另一个示例，与一个商家或FI相关的凭证或安全密码可能不被另一个商家接受，其结果是存储在移动或桌面设备的虚拟钱包中的安全支付令牌可能对于完成交易未必有用。

附图说明

这里参照附图参照，其中：

图1示出了根据本发明的多个方面的适用于处理数据的示例性系统的原理图；

图2示出了根据本发明的多个方面的适用于处理数据的示例性系统的另一原理图；

图3示出了根据本发明的多个方面的适用于处理数据的示例性系统的另一原理图；

图4示出了根据本发明的多个方面的适用于处理数据的示例性系统的另一原理图；

图5示出了根据本发明的多个方面的适用于处理数据的示例性系统的另一原理图；

图6示出了适用于实现本发明的各个方面和实施例的一个示例性移动设备的原理图；

图7示出了如图6所示的移动设备的一个不同的原理图；

图8示出了如图6所示的移动设备的一个不同的原理图；

图9示出了根据本发明的各个方面和实施例的用于处理移动支付的一个示例性系统的原理图；

图10示出了根据本发明的各个方面和实施例的用于处理移动支付的另一个示例性系统的原理图；

图11示出了根据本发明的各个方面和实施例的用于处理移动支付的另一个示例性系统的原理图；

图12示出了根据本发明的各个方面和实施例的用于处理移动支付的另一个示例性系统的原理图；

图13示出了根据本发明的各个方面和实施例的描述一个处理移动支付的方法的流程图；

图14A-14F示出了适用于实现本发明的各个方面和实施例的图形用户界面的实施例；以及

图15A和15B示出了根据本发明的表示系统和系统内的数据流的实施例的原理图。

图16示出了适用于实现本发明的各个方面和实施例的图形用户界面的进一步的实施例。

图17A-17C示出了根据本发明，说明了系统的进一步的方面的示意图。

为了清晰和易于描述，将在附图中使用相似的附图标记来描述相同或相似的部分。

具体实施方式

本文公开的方面提供了存储在持续(即非瞬态)计算机可读介质中的用于电子信号交换的安全执行的系统、方法和机器可执行编程结构，且更具体地，用于多方数据处理的快速及安全协商、授权、执行和确认的改进的系统、方法，以及编程结构。在各种实施例中，本发明提供了特别适用于购买和其他电子资源(包括资金)转移的协商、授权、执行和确认的系统、方法和编程结构。

根据本发明的系统和设备可以包括各种各样的组件，其包括例如用于简化、加速和改进数据处理如购买和其他金融交易的安全性的可信认证服务器或平台。在适用于金融交易处理的本发明的实施例中，这种可信平台可以，例如由银行、信用卡、忠诚度、礼品、奖励、或其他账户管理方；支付处理服务；或其他金融服务提供商来实现。还可能包括由消费者、机构购买者等使用的适当配置的请求通信设备，如移动、桌面和/或其它网络通信设备，以及适当配置的商家和支付处理设备。

除了交易安全性得到改进；认证、裁定或其他处理更快；并且通信设备(例如，数据传输带宽)的使用效率也得到提高之外，根据本发明的系统、设备和方法的使用提供了许多优点，包括特别是关于能够动用由多个金融机构和/或其他金融服务提供商持有、管理或以其他方式控制的资金和/或其他支付来源的能力的用户界面更方便或更不繁琐，以及购买者、商家和FI方完成交易的能力得到提高，这在某些情况下对他们的身体和/或经济健康状况或福利至关重要。根据本文的公开文本，许多其他优点对于相关领域的技术人员是显而易见的。

本文公开的由系统、方法和编程结构的实现来提供的许多优点中包括可信平台的使用以及通过使用由商家、FIs和其他服务或商品供应商提供的应用程序或其他编程结构对购买和其他交易的“应用程序内”处理的改进。

例如，请求通信设备如购买者或其他用户的移动或台式计算机，和/或安装在它们上面的一个或多个应用程序，包括例如一个或多个虚拟钱包和/或商家应用程序，可以通过如因特网的通信网络在可信的认证平台或“可信平台”，诸如由中央注册或认证机构操作或代表它的服务器上注册。在完成注册后，或在其后的任何时间内，这种设备和/或应用程序可以被提供对可信平台和其他设备，例如支付账户管理服务器可用的一个或多个安全电子令牌，以验证或以其他方式将请求通信设备识别为例如，被预授权用于完成各种形式的电子交易如购买的“可信设备”。如本文所述，这种令牌可以被包含或区别于可以被提供给这种请求通信设备以用于处理和完成移动支付的安全令牌。

然后，这种可信设备可以例如，被消费者或其他用户通过一个直接的互联网连接，如一个在可信设备上运行(“应用程序内支付”)的商家应用程序，来支付商品或服务。作为进一步示例，这种可信设备可用于与一个商家系统，如绑定商家的一个移动销售点或交易处理器(“mPOS”)本地通信，该商家系统本身可以在服务器上被注册为可信设备。在这种情况下，mPOS被授权为还与可信服务器关于与可信用户相关的交易或其他数据处理进行直接通信，而不必与任何另外的交易处理中介，如VisaNet或一个等效的专有支付网络(例如在购买或其他金融交易时)，进行通信。这可以是有利的，因为与这些中介的通信通常需要敏感数据的交换以便认证各方和/或以其他方式授权交易；而且这种交换可能在时间和资源处理方面是昂贵的，并且是高风险的。

应当理解，如整个本公开文本所述的本发明的方面和实施例可以被有利地实现或优化以用于移动或非移动平台。然而，应当特别注意的是，在某些情况下，虽然对于移动和非移动应用程序来说均可获得效率和其他可能性，这种可能性特别适用于增加使用移动设备的支付和其他交易的发起和执行的可能性，而不会以任何方式削弱其在非移动应用程序上的功用。

除了涉及支付的购买或其他交易之外，根据本发明的可信平台可用于认证许多类型的数据处理交易、加速其处理以及增加其安全性。例如，这种系统可以用于验证个人、实体等的身份。例如，如果根据本发明的可信平台由银行或其他金融服务提供商(FSP)实现或代表其实现，并且FSP(a)代表用户管理银行、信用卡、忠诚度、礼品、奖励或其他账户，或以其他方式信任用户，以及(b)信任用户希望与其做生意的商家或其他服务提供商，然后可以通过个人信任关系的合并来进行间接的验证/授权。

多个银行或其他FSP之间在管理单个可信平台(包括分布式虚拟平台)时协作的信任可以以类似的方式建立并使用。例如，每个银行可以用由可信平台认证的其他银行进行证实和验证。根据本发明的在请求通信设备、商家系统、以及FI和/或其他FSP的任何或全部之间的可信关系可以如本文公开的通过使用可信网络通信协议来实现。

在另外的实施例中，根据本发明的可信平台可以基于身份用于认证和/或以其它方式完成交易，使得例如用户实际上可以用个人身份来支付交易。在这种交易中，代表这种用户身份的信号数据可以通过严格的上传过程被接收和登记，或以其他方式被证实和验证，并保持在可信平台的服务器上，并在之后作为用于裁定交易的预授权被依靠。每个个体购买者或其他交易发起者(人或法律上)可以例如在不同管辖范围中或在不同的交易环境中，对于不同的社交媒体平台，尤其对于在线服务(iTunes)等具有多个身份或与多个身份相关。这种验证可以通过提供表示有效身份的数据的令牌或其它代表或链接来实现和使用，它们存储在ID卡、用户的智能电话、可穿戴设备或其他移动设备、桌面设备或其他请求通信设备上。这种卡/设备可以连通或以其他方式与POS或另一个移动设备进行通信。该身份可以由POS/设备转发到服务器，其将验证该ID进行支付或满足其他要求为可信。支付方式可以由用户和商家之间商定，被POS传达给银行。支付方式全部在银行注册，所以不再需要传送其他信息。

本发明在各个方面和实施例中提供了用于在自动数据处理系统(计算机)上实现本文所描述的各种功能和过程的方法和进一步的组件，包括持续存储的机器可执行指令集。

根据本发明的进一步的各种方面和实施例，提供了用于在移动或桌面设备环境内快速和安全地完成应用程序内支付的系统和方法。例如，在一些实施例中，一个或多个虚拟钱包应用程序可以安装在移动或桌面用户请求通信设备上，并且设置为安全地存储一个或多个支付凭证，例如主卡仿真(“HCE”)令牌，每个钱包与用户向其设备提供的所选的一种或多种支付方式相关。根据各种不同的支付协议，例如通过位于商家POS终端的NFC读取器、商家网站等，存储在这种虚拟钱包中(即，在其控制之下)的令牌和其他支付凭证通常可用于完成交易。

如相关领域的技术人员理解的，一旦他们熟悉了本发明，应用程序内、浏览器内和其他支付交易过程，包括依赖于使用虚拟钱包和/或本文公开的其它特征的基于移动或云的过程，可以通过使用可信平台架构或与其结合，使用本文所公开的可信设备和设备关系来有利地实现。然而，在各种实施例中，可能有利的是免除或部分地或完全地依赖于不包括在用户请求通信设备、商家设备和其他设备，例如可信平台、支付处理器，和/或卡或发行方系统之间建立可信关系的过程。在一些实施例中，例如，提供能够安全访问支付或其他令牌，以及在购买者设备、商家设备和由支付处理器和其他方控制的设备之间传送这种令牌的可替代的方式是足够有利的。

如相关领域的技术人员进一步理解的，一旦已经熟悉本公开的内容，本文公开的本发明的各个方面、组件和实施例除了移动设备外或替代其，可以在桌面、服务器类、和其他非移动设备上实现。适用于通信交易请求或实现本文公开的目标和过程的任何类型的通信设备都可以使用。这些可以，例如包括智能手机、平板电脑、可佩戴设备如手持电话和智能手表或珠宝、笔记本电脑、台式计算机、服务器类和大型计算机等中的任何一种或全部。

此外，除了由FSP发行的虚拟钱包应用程序外，存储在移动钱包中的HCE令牌或其他支付凭证还可以由安装在请求通信设备上的其他应用程序，例如由给定商家提供的或以其他方式与其相关的应用程序进行访问。为了访问存储在这种“商家钱包”中的令牌或支付凭证，商家应用程序可以通过适当的先前信号交流被授权以通过实现提取架构来访问虚拟钱包应用程序内的信息。在某些情况下，这可以通过在用户通信请求设备上提供一个在钱包和商家应用程序之间共同的系统级应用编程接口(API)来促进。例如，这种API可以例如通过使用单独的API(有时称为“软件开发套件”或“软件开发工具包(SDK)”)或由可信用户请求设备可访问的其他编程特征来提供，并且适用于与分开的独立钱包和可信设备提供的商家API进行通信。由于已经存储在基于FI的钱包中的令牌可以在这种实现方式中被商家应用程序提取，因此，用户为完成交易可以无需将任何信用卡信息直接输入到商家应用程序中。

商家的身份和/或个体商家应用程序可以在可信平台，如认证机构上进行注册，该平台在交易期间认证商家和/或可信用户请求通信设备。在某些情况下，根据本文描述的实施例，可以提供通用的中央认证机构，使得多个商家或商家应用程序可以被注册从而完成安全的应用程序内交易。例如，共同的中央认证机构可以通过一个或多个金融机构，例如一个或多个银行以合作或协作的方式运作，来建立或经营。为了促进多个不同商家应用程序的多个不同用户的应用程序内支付，可以商定和实施用于发布用于授权商家和/或商家应用程序的凭证的全行业标准。在某些情况下，用户的请求通信设备和/或在用户请求通信设备上的一个或多个虚拟钱包应用程序也可以在认证机构上注册。

作为完成从已注册的商家应用程序中发起的移动或其他支付的一部分，表示发布给商家或商家应用程序的凭证(例如令牌)的数据可以被传送至商家应用程序，以用于在这种应用程序的控制下存储在用户请求通信设备上并由用户请求通信设备随后显示给中央认证机构，和/或其他交易处理器，以用于验证或以其他方式认证交易。例如，作为结账或支付顺序的一部分，商家应用程序可以向商家服务器或一些其他网络系统或已经存储商家凭证的资源发送请求。然后，商家应用程序可以使用商家凭证以通过公共API查询用户的移动钱包。这种查询可以由商家应用程序响应于接收到商家凭证，或者可替代地，在将手动确认提示提交给移动设备上的用户之后自动发起。

在某些情况下，响应于由商家应用程序查询，虚拟钱包应用程序可能在请求通信设备的输出屏幕上显示征求授权开始(“用于确认授权的“提示”)的用户界面。当虚拟钱包存储用于一种以上支付方式的令牌或支付凭证时，虚拟钱包还可以提示用户从被存储的支付选项中选择其一用于当前交易。如果只有单一支付方式被存储，则虚拟钱包可能或可能不提示用户选择支付方式。在一些情况下，即使有多个不同的支付选项可能被存储，用户可以在虚拟钱包中指定一个默认的支付方式，然后虚拟钱包可以自动选择来用于当前交易中，并且造成可覆盖或不可覆盖的提示的显示来确认默认选项。这种默认选项可以被指定用于所有商家应用程序或仅仅某些商家应用程序，并且在某些情况下也可被禁用。

在请求设备的用户或虚拟钱包选择支付选项后，虚拟钱包可以通过请求设备的通信子系统用表示用户所选支付方式的令牌或凭证来响应于商家应用程序。然后，商家应用程序可以将收到的令牌或凭证与完成交易所需的其他信息一起发送给商家服务器。在某些情况下，发送到商家服务器的支付信息可以被加密，使得商家可能无法查看任何用户的敏感信息。支付信息的加密可以由虚拟钱包在传输至商家应用程序之前、由商家应用程序或由一些其他应用程序或程序在请求通信设备上进行。为了完成交易并处理所选择的支付，商家服务器可以将从虚拟设备接收来的令牌或支付凭证以及其他所需的交易信息转发至支付网关或其他交易处理器。

在一些情况下，发送到商家服务器上的支付凭证可以是先前存储在移动钱包中与特定支付方法相关的令牌的一个精确副本。或者，或另外，虚拟钱包应用程序可以生成用于交易的单次令牌，其完全或部分地来自永久存储在虚拟钱包中的令牌，或以其他方式与其相关，并且用该单次令牌而不是永久令牌来响应于商家应用程序。在某些情况下，用于完成交易的支付凭证(直接或通过生成单次令牌)可以提前生成，并在交易开始之前存储在虚拟钱包中。在这种情况下，虚拟钱包在交易时可能不需要与任何可信服务器进行通信，以便获得所需的支付令牌。虽然在某些情况下，虚拟钱包也可以设置为在每次交易时获得或验证由其他系统和/或应用程序产生的支付令牌。

在一些实施例中，存储在虚拟钱包应用程序中或其以其他方式可访问的或由其控制的令牌可以表示不同的支付类型。例如，除了一个或多个单独的信用卡类型或协议外，链接到单个或多个银行账户和/或信用额度的支付令牌可以被移动钱包生成并存储以用于移动支付，包括安全的应用程序内支付。通常，每个被授权的支付方式可以与一个或多个不同的支付令牌相关。在一些情况下，用于其他资金类型如优惠券和/或忠诚度计划等的支付令牌可以被单独，或在活期、存款或贷记账户资金之外使用。无论选择哪种类型的支付，商家应用程序和虚拟钱包都可以配置交易以便可适当地由支付网关识别。根据交易类型，一旦确定，支付网关可以将令牌或支付凭证路由到适当的FSP服务器进行处理。

根据本发明的各个方面和实施例，除了不同的支付类型外，存储在虚拟钱包应用程序中或其可访问的或由其控制的令牌可以包括多个令牌，这多个令牌用于完成相同类型(例如，贷记、借记、奖励或忠诚度)支付的，但是从由独立的FI或FSP，即有独立的法定权利和义务和/或独立的所有人或管理者的FI或FSP持有、控制或以其他方式管理的账户动用或以其他方式控制。这种独立的FI或FSP可以施加不同的独特要求，包括成功提交唯一安全码和/或符合其他安全特征程序，这些都由本发明的各个方面和实施例说明。

在另外一些方面，本文所描述的本发明的实施例还可以将可信平台与移动和/或非移动环境相结合来处理电子支付。例如，在用户的请求通信设备已经被认证为可信设备后，当与商家的支付被发起时，用户的设备可以使存储在移动钱包应用程序或移动设备或安全云中其他地方的支付令牌、此令牌的编号，和/或其它加密数据，与完成支付交易想要的或需要的任何其他数据一起被传送到商家系统。商家或商家应用程序可以通过添加令牌数据或与以其它方式与其相关来对令牌的授权进行电子签名或以其它方式证明或确认，并且可以将“签名”消息转发到支付网络，其中的令牌数据表示商家的凭证状态或与其相关(通过使用由认证机构或可信平台识别的数据信号)。

由于商家和/或用户的设备已被认证为可信，无论购买者选择何种支付方式，支付消息(例如，交易授权数据集)可以由移动设备或商家配置为类似于一个被识别的支付协议，如Interac^TM，或任何其他合适的支付协议类型的数据集。在这种情况下，支付网络内的收单方可以接收该消息，并将其识别为Interac^TM或其他类型的交易，将该消息转发到发行FI，如银行，而不是另一目的地。然后，发行FI可以直接或间接地验证/解密消息并处理对商家的支付。在某些情况下，发行FI可以直接用消息中指示的所选支付方式安排支付。可选地，发行FI可以替代地用FI自己的资金支付商家，然后发行FI可以通过用户已在可信平台上注册的任何支付方式与用户单独结算。在某些情况下，如相关领域的技术人员理解的，将这种支付消息直接转发给发行FI而不是通过支付网络给第三收单方，以用于“内部”结算，可以更有效和安全，和/或有利。例如，可以减少交易裁定处理时间，并且可以消除或减少对第三方处理器的支付。

如相关领域的技术人员理解的，在本公开中使用的“令牌”是适用于敏感信息通信的安全数据设备。这种设备可以包括含有任何这类敏感信息的数据，适用于作为这种数据的代理的替代数据，和/或数据被存储并且可以被安全访问的资源如IP地址的指针。可以被包括在这类令牌和/或这类令牌编号中的一种特定的数据类型或项目是与服务器绑定的安全密钥，如用于控制对敏感数据访问的服务器(120,160)。这种安全密钥可以包括足以证明或获得访问信息的权限的任何数据，包括任何标识符。这种安全密钥不限于例如PKI密钥或凭证等。

如上所述，各种不同的支付方式可以通过电子(“虚拟”)钱包应用程序的适当实施，包括如信用额度、现金账户、忠诚度、礼品和/或奖励积分余额等，被表示。如所描述的，所选的支付方式可以以商家使用现有的支付网络和/或基础设施路由到收单方或其他授权的FSP，并且由收单方或FSP路由至发行FI的方式在消息中被指定。在电子钱包中表示的每种支付方式可以对应于在相应的发行FI和/或可信平台中注册的支付方式。商家无需知道或关心用户选择哪种支付方式来交易，也无需向商家提供设置为接受任何特定支付方式的系统或应用程序。发行FI可以用FI的资金支付商家，并通过从用户选择的支付方式偿还来与购买者或其他请求用户结算。因此，商家或其他支付处理器后台实体在实现本文所描述的本发明的各方面时没有或只有最小的变化，从而减少处理时间而且额外的支付系统和/或应用程序的需要。在某些情况下，所有可能需要的是商家从FI或可信平台接收凭证数据集，其可用于电子签署从用户或其移动或非移动设备提供的支付令牌。

在一些实施例中，本文描述的系统、方法和指令集可用于从安装在移动或其他设备上的通用浏览器内，而不是从由商家提供的或以其它方式与商家相关的应用程序或程序中，发起和处理支付。例如，当用户浏览到需要支付的网页或网站时，可能会出现选项以通过使用安装在用户请求通信设备上的虚拟或电子钱包来实现支付的选择。除了可用的其他支付类型和/方式外，这种选项还可以被显示，并且可以在任何所需的或其他合适的位置，如在支付选项的列表中，或者作为图形上或功能上有区分的用户界面目标，例如可选择的“按钮”出现。当请求用户选择通过虚拟钱包支付时，用户的浏览器应用程序可以与在请求设备上的或以其他方式可由其访问的相应的钱包应用程序进行接口，从钱包获得支付令牌并将该令牌包括在支付消息中以通过商家后台处理。根据本文所述的任何适用的实施例，电子支付处理可以然后通过支付网络或其他实体进行。

由本发明提供的显著优点在于，不论平台如何，实现支付交易的用户体验可以基本相同。例如，在每种情况下，当选择用电子钱包支付时，如前所述，多个适用的支付卡/账户的列表或其他视觉表达可以显示给用户以供选择。请求用户可以选择支付方式，并且移动设备或个人计算机可以向商家发送适当配置的令牌或者，在云钱包的情况下，银行可以将相应的令牌路由到商家或直接到商家的收单方。

如前所述，根据本发明的各个方面，电子交易可以在如个人计算机的非移动设备上的应用程序或其他编程设备内发起和完成。例如，在某些情况下，用户可能浏览可在其上从商家购买、租赁等商品或服务的网站。允许选择虚拟钱包支付选项的登录或其他提示可以在商家的结账/支付网页上向用户显示。在请求用户选择虚拟钱包支付选项时，商家的网页可显示例如，呈现在嵌套浏览环境(例如，iframe或其他图形叠加或插入)中，带有适用于使请求用户登录用户的授权银行、信用卡、忠诚度、奖励和/或其他支付账户的互动区域的安全登录。在成功登录或其他授权后，与指定的支付账户相关的FI可以通过提供一个或多个支付令牌响应于商家、或者向由商家指定的或以其他方式与其相关的收单方或其他第三方支付处理机构，该令牌表示在用户的电子钱包内进行识别并足以满足交易支付的一种或多种支付方式。这种支付令牌可以存储在用户的设备和/或安全的云资源中。当商家或商家后台接收到支付令牌后，可以根据本文所描述的任何方法来处理交易。

因此，在一些实施例中，无论用户如何或从什么程序或应用程序发起交易(应用程序内、移动或非移动浏览器)，用户的设备甚至可能不存储虚拟钱包应用程序或支付令牌(一个或多个)。作为替代，在这种情况下，设备可以提供向管理用户的支付账户的FI安全认证设备/用户的方式，如通过可信平台。一旦用户和/或设备被认证，用户的FI可以向商家/收单方发送电子支付令牌用于处理交易。各种安全认证方法可以如本文所述被使用，包括指纹或其他生物特征验证，包括如语音或面部识别、登录/密码或由用户设备的特定能力支持的任何其他安全验证方式。

现在将参照附图提供本发明各种实施例的进一步细节，包括至少一个优选实施例。本文使用的标题或次标题仅仅旨在将本发明组织为主题的逻辑组合，而不对所描述的实施例的范围有任何程度的限制。如相关领域的技术人员理解的，根据支付网络配置；用户、商家和/或FSP偏好等，本文公开的许多特征可以以各种组合和替代方案被使用。

可信平台

首先参照图1，其示出了适用于实现本发明的各个方面和实施例的系统100的示意图。在所示的示例中，系统100包括至少一个用户或请求通信设备110(也称为“网络交易通信设备”和/或“网络通信设备”)，供购买者或其他用户190使用(图3；图14A-14F)；一个可信任的认证平台(或“可信平台”)120；以及一个包括商家销售点(POS)和/或其他交易设备132、134，以及商家或其他FSP服务器136的商家系统130。

虽然图1中每种设备110、120、130、132、134、136仅示出其中一个。相关领域的技术人员容易理解，系统100可以包括任何所需的或其他有利的数量的这种设备。

在一些实施例中，用户或请求通信设备110可以包括任何适当配置的智能电话、平板电脑、可穿戴物、笔记本电脑或其他移动设备；台式或其他固定式计算机或终端等或由其组成。目前，大量多种合适的设备在商业上可用，并且毫无疑问，在本说明书准备之后，将会开发其他设备。下文将参照图6-8提供请求或用户通信设备110的进一步细节。

可信平台120可以包括任何企业、服务器、台式电脑、笔记本电脑或其他适当配置的类型或等级的电子数据处理(计算机)系统或由其组成。目前大量多种合适的设备在商业上可用，毫无疑问，在本说明书准备之后，将会开发其他设备。下文将参照图9-11提供可信平台120的进一步细节。

商家系统130和设备132、134、136可以包括任何适当配置的POS，mPOS，以及后台数据处理设备或由其组成。目前有大量多种合适的设备在商业上可用，毫无疑问，在本说明书准备之后，还会开发其他设备。下文将参照图9-11提供商家系统130和设备132、134、136的进一步细节。

设备110、120、130、132、134、136或其中任何一个可以通过无线(包括光学、RFID和红外)、有线或其他方式，使用例如适当配置的信号处理器、发射器和被配置为通过互联网、PSTN和/或其他通信网络进行通信的接收器，使用任何合适的协议或协议组合进行彼此间通信。通常，为了这种目的，这种设备与一个或多个专用通信子系统结合，在一个或多个中央处理单元(CPU)和/或其他处理器的控制下运行。

作为实现本文所实现的过程的一部分，如图1中在(1)处所示，用户190的移动设备110可以通过经由通信网络200(例如，因特网和/或PSTN)的适当配置的信号交换在可信平台服务器120上注册，并且在(2)处由可信平台120提供安全数据集，代表凭证或其他令牌，被存储在设备110的易失性(持续)或非易失性(即，瞬态或非瞬态)内存中，从而使设备110成为可信设备110'。一旦被接收并存储在设备110中，则凭证或令牌可由设备110和可信平台120用于将设备110快速并安全地识别为“可信设备”110'，例如用于发送至平台120或由平台120解释，用于快速授权和/或以其他方式验证数据处理，如与第三方，如一个或多个商家系统130的购买或其他金融交易。

设备110在可信平台120上的注册以创建可信设备110'可以包括建立与本文目的一致的适当明确且安全的通信方式的任何方式。例如，设备110的一个或多个唯一且安全的标识符和/或它的一个或多个其授权用户190可以各种各样的替代方案和组合使用。这些可以包括例如姓名、“秘密”个人信息、序列号、随机或伪随机码、账号等。

然后，这种可信设备110'可以例如在(3)处，被用于通过直接互联网连接来协商和完成一个或多个“应用程序内”支付或其他数据处理交易，该直接互联网连接例如包括，由商家/提供商130或包括通用网页浏览器等在内，使用适当配置的超文本链接被提供给可信设备110'的用户显示屏或其他I/O组件610(参见例如图6)，以及触摸屏、键盘/小键盘和/或其他用户生成的输入、信号发射器和接收器等的传送的某些其他实体提供的商家、游戏和其他应用程序('app')。

在相同和其他的实施例中，在(4)处，可信设备110'可以与逻辑上绑定至商家系统130、136的移动POS(“mPOS”)设备132进行本地通信，其本身可以在可信平台120上注册为可信实体，用于有时被称为常规支付系统的直接或“脱离rails框架”处理。换句话说，mPOS132和/或绑定的商家处理器136能够通过这种方式如在(5)处所示，被授权直接与同一个的或另一个可信平台120通信，而不必通过合适的信号交换来与第四方交易处理器150，如VisaNet的支付处理器或相当的专有支付网络进行协商。通过避免涉及第四方150，如用于更常规方式“处于rails框架”处理的支付处理器的必要性，许多优点可以被实现，包括如身份、账户标识符等通常敏感的交易数据的更快更安全的处理。

在一些实施例中，这种mPOS 132和/或绑定的商家处理器136能够代替与平台120直接通信，通过合适的信号交换来与这类的第四方交易处理器150同样和/或可替代地通信，该第四方交易处理器150如上所述可以是如VisaNet的支付处理器或其他专有支付网络。在一个mPOS 132和/或绑定的商家处理器136与一个第四方交易处理器150之间协商的交易可以随后与发卡银行160和/或与可信平台120结算，使得商家被支付且用户被借记相应的金额。这种配置的一个可能的优点为mPOS 132和/或绑定的商家处理器136可能已经配置为用于与第四方处理器150通信和/或交易处理。因此，在利用现有的商家系统架构的同时，可以在移动交易中实现基于可信平台120认证的任何和所有好处。

除了支付和其他金融交易外，可信平台架构100可以用于多种其他目的。例如，如上文所述，身份验证是另一个可能的应用程序(例如，银行信任我，你信任银行，所以你，任意的第三方，信任我)。在与可信平台120相关的银行或其他账户管理方或受托人160之间的信任可以以类似的方式发生作用。每个银行或FSP 160可以基于可信平台系统100中的其他银行或FSP 160进行证实和验证。

在各种实施例中，可信平台120可用于使设备110'的用户能够基于个人、设备或其他非支付标识符或与用于实现支付的一个或多个账户相关的标识符，而不是账号等来完成购买和/或处理其他交易。表示用户真实身份或可由可信平台120接受的作为完成支付或与交易相关的其他义务的保证的其它身份，例如雇主或其他机构的标识的数据，可以通过上传过程或其他过程进行接收、证实和验证：并且被保持在可信平台架构100的一个或多个服务器120上；并且一个或多个合适的令牌，包括表示认证标识符的数据，可以被返回至用户设备110以便存储在与设备110相关的内存中，使得它其后可以被用于返回到发布的可信平台120的数据(其可以是令牌或包括令牌)中，以适用于将设备110建立和/或重建为可信设备110'。

如相关领域的技术人员理解的，任何用户或请求设备110可以与多个授权的个人和/或法定用户相关，和/或与这些用户相关的多个账户相关。例如，每个这种设备可以由不同的授权用户和/或不同管辖区域中的实体或不同的数据处理环境使用，例如在实体商家场所中的不同的社交媒体平台或特定在线服务(例如，在线音乐或媒体来源)。每个经过验证的身份的显示、链接和/或与其相关的其他数据或指令可存储在ID卡如实体信用卡或借记卡上，或在设备110、110’的单独或通用内存如SD卡或其他可移动设备中，或者以其它方式与这种设备相关或可由其访问的通用内存或内存中，例如在一个或多个虚拟钱包应用程序112、专用软件、固件或硬件、或具有类似功能的单独设备如USB密钥中。包括这种可信标识符的卡或设备110、110可以被连通或以其他方式被导致与POS设备132、134或另一个移动设备110、110'等相互作用；并且在该过程中任何合适的时候，多个标识符中的任何一个可以被选择以通过使用例如设备110、110'的适当配置的I/O设备与交易相关使用。与所选标识相关的标识符可以由POS/设备110、110'转发到服务器120，其将验证该ID为可信以用于完成交易。

在适用于完成购买和涉及支付的其他交易的实施例中，用于完成交易的一种或多种支付形式可以在用户110'和商家系统130之间可以提前、在交易时和/或在交易确认后商定，并且例如由POS 132、134或服务器136等传送到银行/可信平台120、160。这种支付方式可以由银行160或其他可信平台120注册或以其他方式认证，从而可以避免或减少发送和解释识别这些方法的信息的必要性。以这种方式，例如，根据被商定的支付方式，支付可以使用对银行160或其他可信平台120的指令来完成，而不必提供与在支付消息本身中的选定的支付方式或来源相关的任何细节(其可能具有敏感特征)。

因此，例如，通过本发明实现了各种新颖的支付结算处理类型或模式。例如，交易时，设备110'的用户和商家系统130可以商定所用支付协议的类型、模式或协议(例如贷记、借记、现金银行转账、忠诚度积分兑换，包括与每种此类支付相关的一个或多个特定账户)，并且与所选协议相关的标识符可以被发送到可信平台服务器120。不管用于完成交易的支付账户为何种类型，这种协议可以被商定并指定用于交易处理。特别是在服务器120与银行或其他账户控制的FSP160相关的情况下，服务器120本身可以具有使用所选协议来处理支付的能力。从商家130的角度来看，不管所选择的支付协议如何，根据其本身或其支付系统服务提供商的偏好，交易数据流可以相同或基本相同。

本发明的显著优点之一，是可信平台120与任何一个或多个商家系统130和/或FSP160进行通信或者在完成交易时以其本身的权力充当银行或FSP，并且使用任何一种或多种各种支付类型或协议来完成交易，而对商家系统130处理的差异无任何要求的能力。

可选地或另外地，基于各种标准，包括例如用户身份、账户特征(包括与账户相关的任何FI的身份)和/或用户偏好，可信平台120可以将默认账户或其他支付协议或方法与由与特定交易请求相关的用户设备110'生成的交易请求相关联。

上述选项中的任何或全部可以由在用户设备110'上运行的可信支付应用程序来控制和/或以其它方式实施。例如，虚拟钱包应用程序112可以与特定的用户身份相关，例如个人、个人账户中的一个或多个、一个或多个不同的FI或FSP，和/或一个或多个用户/商家应用程序组合；并且设备110'的特定的被授权用户能够例如通过适当配置的用户界面来选择哪个身份/应用程序/账户或其组合用于执行交易；并且任何一个或多个这种选择可以在所需的条件下被识别为可覆盖的或不可覆盖的默认选择。例如，这种通过默认的预选可以消除在交易时用户选择、以及可信平台120和/或商家130接受特定的支付方式的必要性。

可选地，作为或代表FSP 160的可信平台120可以通过用户的设备110、110'和/或通过mPOS 132/POS 134，通过使用适当配置的用户界面和数据交换，在支付时向用户提供开启或以其它方式访问或创建新的或现有信用额度或其他新的资金来源的机会。本发明可以实现各种各样的进一步的可能性，包括创建忠诚度、奖励、礼品和其他类型的账户。

如相关领域的技术人员理解的，根据本公开，可信平台120可用于向与商家系统130相关的商家确保(其可以例如由商家协会经营或代表商家协会)在交易完成后商家将被支付一笔商家应得的金额。从商家的角度来看，只要商家能得到支付，用户方面的资金来源通常并不重要。这是本发明的另一显著优点。例如，可以使设备110'的用户能够以可信平台120和/或相关的FSP 160可接受的任何方法来支付，而不必考虑商家对于支付的偏好。例如，在许多现有技术的系统中，当商家不接受如AMEX^TM的特定形式的支付时，则用户必须寻找另一种可接受的支付方式。可信平台120可以例如适用于根据这种优选协议来接受和进行支付，并且据此将支付传送至商家，而且随后在可信平台120和使用设备110'的购买者之间可以根据任何所需的，双方可接受的支付形式进行结算。例如，这可以通过从由AMEX或任何其他所需的协议中的可信平台120本身控制的资金向商家系统130提前支付，并且单独从支付用户处获得偿还。在未将商家系统130认证为可信实体的情况下，可信平台120先与商家进行结算，然后再与用户单独进行结算可能更难或者甚至根本不可能。

在另外的实施例中，包括可信平台120与购买者的结算与商家分离的那些可信平台120或其他FSP160可以使用与一个或多个用户或者设备110'相关的资金来源的组合来提供支付，而不向商家系统130识别指定来源。例如，用户可以用一个信用卡账户支付交易的一半，而另一半使用借记或忠诚度账户支付。

在各种实施例中，无论商家是否以其它方式愿意接受积分作为支付方式，可信平台120或其他FSP 160可以允许设备110'的用户使用在可信平台120、160上注册的忠诚度积分来全部或部分地支付交易。这在积分由可信平台120、160或在其授权下兑换的情况下都是可能的，而不必考虑商家系统130的偏好或要求。因此，可信平台120,160能够使用适当配置的信号和数据交换，以商家的优选格式(包括货币的选择，例如美元、欧元、英磅、卢布或日元，或电子货币如比特币)来支付商家。例如，当设备110'的用户已经与或已经同意与可信平台/FSP 160结算25美元再加上与FSP相关或FSP以其它方式认可的积分，其数额足以在结算之前或之后补偿剩余的25美元时，可信平台120、160可以向商家系统130提供表示结算50美元的信号。商家系统只会看到它收到50美元。

当用户连通用户的移动或其他交易通信设备110'或以其它方式将设备110'置于被配置为用于完成交易支付的操作状态时，可信平台120可以直接与移动设备110'通信来确定支付选项。实时优惠，包括优惠券、兑换券、折扣、信用卡和其他选项可以，可选地与用各种方法支付的机会组合，被提交给用户，其中各种方法例如包括新的信用、忠诚度或其他账户。再者，各种这种选项和通信可以通过虚拟钱包或其他支付应用程序112,114来处理。

根据本发明，尤其在可信平台120由银行或其他FSP 160或代表其操作的情况下，由在设备之间可以建立的可信数据处理关系提供的许多优点，有使设备110'的用户能够在交易完成后，甚至在商家系统130已经从可信平台/FSP 120,160收到并处理最终支付数据后改变所选支付方式的能力。由于商家无论如何已由可信平台/FSP(银行)支付，因此可信平台/FSP(银行)可以在指定的时间限制内可选地(例如，在同一工作日内，24小时内或标准交易清算期间、或在某些其他预定义的期限内)允许用户通过用户的可信设备110'选择新的或修改的支付形式。在这样的实施例中，可信平台/FSP 120、160可以设置为向可信设备110'发送关于改变支付方式的时间限制即将到期的提醒。无论可信平台/FSP 120、160和设备110'的用户之间的支付状态如何，在该截止时间之前，可信平台120、160可与商家系统130结算。

本发明的各种实施例的优点有，支付时，可信请求通信设备110'可以不需要与可信平台120和/或FSP 160网络连接，因为可信设备110'设置为具有一个令牌(参照例如，图1中的(1)处)，该令牌在其它可能性中可以通过商家系统130，包括例如mPOS 132被转发至可信平台120以用于支付和/或其他结算，而不需要交易时在设备110'和平台120之间通信。

可信平台120还可以促进没有商家mPOS 132时各方之间，包括例如在用户通信设备110'的双方或其他多方之间的支付。例如，双方可以各自具有一个在可信平台120上注册为可信设备110'的移动设备110。只要可信平台120已经与每一方的设备110'建立了可信的数据交换关系，则可信平台120将信任每个设备110'接收的命令。由于可信平台120单独信任双方，特别当双方是同一银行160的客户时，因此双方之间可能进行即时汇款。

可信平台120还可以促进表示预授权交易值(例如，预支付值)的令牌在用户设备110'之间的传送。当网络通信可用时，这可以使用上文所述过程来处理。当网络通信不可用时，例如可以通过将这种预支付令牌与可信标识符相关来实现，该可信标识符与发送和接收设备110'中的每一个唯一相关。必要时，当网络通信恢复时可以确认发送。或者，支付令牌可以从第一设备110'删除，并且一个新的但在金融上等价的支付令牌在接收设备110'上或由其或为其生成。

图2示出了根据本发明的系统100的实施例的原理图。在图2所示的变化中有以安全数据集125(参见图1)的形式存储在由一个或多个可信平台120控制的内存中的“存储现金”或“共享现金”池170。这种安全数据集125可以以表示任何所需的实际或虚拟货币或价值或其标记的形式代表货币价值池，该货币价值池可分配至例如，如图1所示的多个可信FSP 120、160，或从、被其动用来用于安全和可能非常快速地清算在各个可信FSP 120、160上持有账户的各方110,130之间进行的交易。如相关领域的技术人员理解的，一旦他们熟悉了本发明，FSP 120,160可以包括各类实体，或以其它方式由其管理或与其相关，该实体包括银行和其他金融机构，如加拿大皇家银行(“RBC”)，蒙特利尔银行(“BMO”)，加拿大帝国商业银行(“CIBC”)等。

现在参照图3和图4，其示出了根据本发明的系统100的另外的实施例的示意图。在图3和图4所示的变化中有几个服务的特定示例，该服务通过在商家系统132、130和一个或多个FSP系统160之间放置可信平台120、160提高了其效率和有效性。这些包括例如如122处所示和在本文中说明的，“由我们支付(on-us)”上的加速结算和清算和/或都在可信平台上注册的各方(例如，用户110和商家130)之间的其他“脱离传统支付系统rails框架”的支付，作为通过第四方系统120的更常规处理的替代或补充。应注意，如302所示，如果/当交易的一方或多方110、130未向可信平台120注册时，例如，如果双方均在FSP 160持有账户，则“由我们支付(on-us)”交易可由其他FSP 160完成。

如图3和图4在124处所示的服务的另一个示例为由系统100的可信平台120提供的提高效率的增值服务，如优惠和/或优惠券、忠诚度积分、折扣的兑换以及数据集的生成，该数据集表示关于由可信平台120处理的交易的加强或其他收据。例如，如前所述，这种服务可以通过例如在解释和处理用户110'和商家系统130之间的支付交易时，使用附加的和/或替代协议，如忠诚度或礼品协议，来提供。

如在126处说明的，可信平台120可以提供或完成任何所需的辅助或其他服务，包括例如通过非支付相关应用程序等提供的服务。这些服务可以包括例如由可信平台120、商家130等提供的其他商品或服务的链接。

如前所述，根据本发明的系统100适合用于支付和其他金融交易的补充或替代的许多应用程序中。如图4中400所示，这种应用程序可以包括各种敏感或其他所需的安全数据处理，包括例如电子健康记录的维护、使用、和分析；政府记录，如身份证明记录，包括护照和其他标识、税务记录、刑事和其他法庭记录、警察和情报数据等；以及各种丰富的或其他有价值的数字内容。

图5示出了根据本发明的系统100的进一步实施例。如前所述，设备110、110'可以包括或包含适合用于实现本公开的目的的任何设备或设备组合。例如，用户设备110、110'可以包括用户的台式计算机，该台式计算机在某些情况下可能缺少通常由移动设备如智能电话、平板电脑或可穿戴设备等提供的硬件/通信资源。

在这种情况下，当用户发起与商家系统130的购买或其他交易时，由于例如通过使用PSTN/因特网和桌面商家应用程序，各种数据和/或其他信号，包括例如交易确认信号可以由任何或全部系统120、160、130生成，并且被传递给用户的注册设备110'以供设备110'用于从购买用户或财务负责方如账户持有者处获得确认。例如，当购买或其他交易请求由被注册的桌面设备110'生成时，在完成交易之前，可信平台120可以将注册移动设备110'的用户提出的确认请求路由到可信移动设备110'，如与与交易相关的账户相关智能电话。这种实施例可以显著增加交易的安全性，并且减少欺诈和其他形式的滥用、错误等。此外，通过从交易数据系统中消除FI/FSP160和第四方FSP 150，服务器之间交换的信息量可以减少并且私密性可以增强。发卡机构，例如，只需被通知最终交易额，而无需了解更多细节。

图6示出了示例性移动设备110、600的原理图，根据本发明的实施例该示例性移动设备110、600可以被注册或以其他方式被建立为可信设备110'。如前所述，设备110、600通常可以是任何便携式电子设备，包括合适外壳内的电子、结构和/或机电组件的总成，并且该总成向用户提供包括短程和/或长程网络连接在内的各种语音和/或数据功能。应当理解，如“便携”或“移动”之类的术语可以用于全部本文中，以指出设备110、600通常可以由用户在不同的实际位置之间运输而不需要实际辅助。特别地，移动设备110、600可以包括由用户的人员或服装携带的设备，如手机或其他无线电话、个人数据助理(PDA)、平板电脑、笔记本电脑、便携式计算机、智能手表或珠宝等。然而，本发明的各个方面和实施例也可以使用非移动通信设备，如笔记本电脑或个人计算机来实现。

因此，在一些实施例中，移动或其他设备110,600可以包括一个或多个CPU 602、随机存取存储器(RAM)604和其他物理存储器606，其中一个或两者可以存储非瞬态(即持续)数据和机器可读的指令集。通常，CPU602可以是设置为为控制移动设备110,600及其各种组件的总体操作的任何微处理器或其他通用或专用处理单元，通过它们，CPU 602可以与适用于在移动设备110,600上传送数据、功率和/或其他信号的总线或其他电子链接或路径连接。CPU 602的读写操作可以由与CPU 602相关或集成在其中或CPU 602可访问的RAM 604或某些其他集成电路或易失性内存存储来促进。

内存606可以包括一个或多个持续(即，非暂时)内存如闪速内存或只读存储器(ROM)，该持续内存或者物理上被嵌入在移动设备110、600内，或者替代地，可由用户可移除地加载或插入到移动设备110、600中，如用户身份模块(SIM)卡或安全数字(SD)存储卡上。内存606可用于存储任何类型的数据和/或可执行的机器指令文件，例如但不限于媒体文件(音乐和照片)以及用于实现如本文所述的移动设备操作系统(OS)608的软件和其他程序或应用程序。内存606还可以用于存储由CPU 602或移动OS 608用来执行不同的功能或控制移动设备110、600上不同组件的一个或多个文件，如联系人信息、网络偏好、应用程序数据和其他文件。

在各种实施例中，移动设备110、600还可以为用户配备一个或多个组件以与移动设备110、600进行交互。在此处通常以610表示的这些组件可以让用户将数据或命令输入到移动设备110、600中，并且也可感知移动设备110、600输出的数据或信息。在没有限制的情况下，各种可能的输入组件610可以包括触摸板、拨盘、点击轮、触摸屏、键盘、和其他按钮，以及相机、麦克风和生物识别传感器(例如，指纹扫描仪)。示例性输出组件610可以包括扬声器、屏幕和视觉显示器、振动卡及其组合。本文中未特意提到的其它I/O组件610也可以包括在不同的实施例中。

在如图6所示的一些实施例中，移动设备110、600还包括一个或多个长程网络通信组件612和/或一个或多个短程网络通信组件614，它们可为移动设备110、600提供各种不同的语音和数据通信功能。应当理解，术语“长程”和“短程”在本文中可以用于表示相对距离，并且不旨在表示任何特定的限制或范围。因此，长程通信组件612和短程通信组件614允许移动设备110、600与其他位于邻近或远程位置的目标通信，这些目标可以是其他类似或不同配置的移动设备、服务器、系统和其他网络设备。

例如，长程通信组件612可以由移动设备110、600使用以通过蜂窝或其他分布式网络，使用适当的语音和/或数据通信协议，例如但不限于时分多址(TDMA)、码分多址(CDMA)、全球移动通信系统(GSM)、无线应用程序协议(WAP)等与合适的目标通信。按照这样的协议，移动设备110、600能够将通信发送到各种类型的任意远程设备，包括语音、数据和基于文本的消息而不受限制。为了实现长程通信，组件612可以包括各种硬件和/或软件组件，如天线、发射器、接收器和数字信号处理器。长程通信612的特定配置可以通常取决于所实施的通信协议。

短程通信组件614可以实现移动设备110、600与其他相对邻近位置的设备、服务器或系统之间的通信。例如，短程通信614可以包括如用于连接到Wi-Fi(802.11标准)或蓝牙网络，以及诸如RFID的红外线或光学等短程通信的其他模式的一个或多个短程收发器。在一些实施例中，短程通信614除了各种不同的目的或功能外，可以专门包括用于与NFC读取器进行通信的近场通信(NFC)子系统616，以便如下文所述发起与商家移动POS终端的非接触式支付。

在一些实施例中，如下文进一步的描述，移动设备110、600还可以包括一个或多个安全元件618，其被配置为用于敏感数据和其他信息，如支付凭证或加密数据和编程结构的防篡改且限制访问的存储环境。例如，安全元件618可以包括任何或全部集成电路(IC)、操作系统(OS)以及应用程序或程序，包括虚拟钱包应用程序112、622、商家应用程序114、卡仿真应用程序628等。安全元件618可以实体嵌入(集成在)移动设备110、600中或者，替代地，配备在可插入移动设备110、600的卡如SIM卡或SD卡上。如图所示，CPU 602和NFC子系统616在某些情况下都可以访问安全元件616的内容。或者，根据移动设备110、600的应用程序或配置，仅限于访问CPU 602和NFC子系统616中的一个或另一个。

移动设备110、600还可以包括一个或多个电源620，其被配置有适合向CPU 602以及移动设备110、600的其他组件生成、接收或发送功率的任何组件或电路。例如，当移动设备110、600插入或以其他方式连接到这种外部电源时，电源620可以包括用于处理从外部电源，如电力公用设施或电网接收的电力的电路。在一些情况下，电源620还可以包括一个或多个电池，如镍金属氢化物、镍镉、和锂离子电池，当移动设备110、600无法连接外部电源时它们可提供功率来源。还可以包括如太阳能电池板或感应线圈之类的其它发电或处理电路，使得电源620可将能量传送至移动设备110、600内的不同组件。应当注意，电源620和移动设备110、600内其它组件的单独连接未在图6中示出，而为了方便起见，仅将电源620显示为隔离元件。

如前所述，在许多实施例中，请求通信设备110、110'不是“移动”设备。因此，例如，用户设备110、110'的大小、形状和/或重量使用户在没有一些实际帮助或辅助的情况下将其搬运超过一般距离变得困难、不方便或不切实际。尤其是非移动用户设备110、110'可能是用户本人或其着装实际上无法携带的设备。非移动设备110、110'的示例包括用户的台式计算机和其他计算设备。

根据所述实施例的非移动设备110、110在通信能力、安全内存等方面可能与图6所示的移动设备600相同或不同。例如，非移动设备110、110'可能(或可能不)缺少图6所示的一个或多个组件。或在某些情况下，可能包括附加的或不同配置的组件。在一些情况下，非移动设备110、110'可能缺少安全元件618，因为这种设备110、110'未被配置为接收SIM卡或SD卡。在某些情况下，长程通信612和短程通信614中的至少一个可能不同。例如，用户设备110、110'可能包括一个用于连接至分布式网络如因特网而不是蜂窝天线的调制解调器或其他网络组件，来代替设置为用于远距离无线通信的长程通信612。在一些情况下，短程通信614可以不包括NFC接收器616，但是可以包括WI-FI和/或蓝牙天线或其他。本文描述的系统和过程的实施例可以使用移动设备600或非移动设备而不受限制。

参照图7，如本文所述，根据各种实施例，移动设备110、600可以用于向商家POS终端，在某些情况下结合可信平台120，发起表示基于邻近的支付交易的非接触式信号交换。这种非接触式支付可以使用存储在安全元件618内的支付凭证，或者使用存储在配置为HCE环境的钱包应用程序112、622中的支付令牌。在另外的实施例中，支付令牌可以存储在移动设备110、600可访问的安全云中。

因此，在一些实施例中，NFC子系统616可以包括任何合适的基于邻近的通信组件或组件的组合，它们使与相应的NFC读取器132、134、700或其它类似的启用的目标设备的非接触式基于邻近的通信成为可能。例如，NFC子系统616可以包括天线或收发器624和控制器626，它们被配置为在全球可用的、13.56MHz的无需许可的射频ISM频带上运行(按照在相关标准，如ISO/IEC 14443和ISO/IEC 18092中规定)。在一些情况下，NFC子系统616可以根据其他通信技术或标准可替代地运行。

在发起非接触式支付之前，用户可以向移动设备110、600提供一个或多个支付凭证或支付凭证集，它们可能存储在安全元件618和/或移动设备110、600中的其他地方。例如，在某些情况下，用户可以直接输入支付凭证至钱包应用程序112、622中用于将其存储在安全元件618中。当存储在安全元件618中时，这种支付凭证可能在不令牌化的情况下直接输入和存储。

或者，移动设备110、600可以由发卡银行或其他实体，如可信平台提供对应于授权的支付方式的令牌化的支付凭证。例如，可以使用钱包应用程序112、622或某些其他程序或应用程序，包括不在移动设备110、600上的那些，来请求来自用户发卡银行或其他实体的支付令牌。这种支付令牌，可以是多次或一次性使用或受其他使用限制或限定，一旦在移动设备110、600上被接收到，就可存储在钱包应用程序112、622内或移动设备110、600的其他地方。在某些情况下，支付令牌可以存储在安全元件616中，并且可通过CPU602对钱包应用程序进行访问。

为了发起非接触式支付，移动设备110、110'、600可以被置于NFC读取器132、134、700的范围内，其可用作或形成为商家POS终端或系统130的一部分。在其范围内时，NFC读取器132、134、200可以将信号传送到移动设备110、600上，该信号由NFC收发器624接收，并请求发起交易和提供支付凭证。根据在移动设备110、600上实施的协议的配置和类型，NFC控制器626可以以不同的方式响应和处理非接触式交易。

例如，在一些实施例中，移动设备110、110'、600可以被配置为以卡仿真(CE)模式工作，借此移动设备110、600通过在安全元件内存储支付凭证来模拟非接触式支付卡。在这种处理模式下，NFC控制器626可以将由NFC收发器624接收到的交易请求路由到安全元件618，用户的支付凭证可以存储在其中的仿真应用程序628中。检索到的支付凭证然后可以由NFC控制器626路由返回到NFC收发器624来传送到NFC读取器132、134、700。该交易然后可以通过与商家POS终端相关的后台或支付网络来处理。

或者，如本文所述，移动设备110、600可以配置为通过提供存储在钱包应用程序112、622，而不是安全元件618中的支付令牌来用于HCE。因此，在这种处理模式下，NFC控制器626可以将由NFC收发器624接收到的交易请求路由到CPU 602而不是安全元件618，以便从钱包应用程序112,622中检索支付凭证。检索到的支付凭证然后由CPU602返回至NFC控制器626并路由回到NFC收发器624来传送至NFC读取器132、134、700。该交易可以再次通过与商家POS终端相关的后台或支付网络进行处理。

如图8所示，根据本发明的实施例的移动或其他设备110、110'、600还可被配置为从与商家相关的应用程序或程序内，或者如下进一步所述的，从一些其它非专用的应用程序或程序，如一个或多个网页浏览器或商家应用程序114，直接发起移动支付。因此，与使用移动设备110、600和商家POS终端之间的NFC通信完成的非接触式支付不同，这种电子支付不要求实际接近商业POS终端，并且可以在移动、桌面或其他设备110、600具有网络连接的任何地方的商家应用程序中发起。

因此，设备110、110'、600的用户可以将一个或多个不同的商家应用程序114、630或其他程序安装到移动或其他OS 608中。图8出于便利仅示出一个这种商家应用程序114、630，但是根据用户的偏好，在不同的实施例中可安装任何数量。除了其他可能的功能，商家应用程序114、630可以允许用户从商家应用程序114、630中购买商家向用户展示或推销的产品或服务。不同的可能的商家应用程序114、630可以包括专注于商家的商品和/或服务的那些商家应用程序，以及间接向客户提供商品和/或服务的第三方应用程序，如拍卖网站。

在一些实施例中，如下文进一步描述的，商家应用程序114、630可以被配置，使得存储在一个或多个钱包应用程序112、622中的支付凭证或其他信息可以由商家应用程序114、630提取，而不必打开或启动任何相应的钱包应用程序112、662。例如，当在商家应用程序114,630内发起支付交易时，一个屏幕或提示会提交给用户，该屏幕或提示向用户提供提取存储在任何一个或多个钱包应用程序112、622中的哪个支付凭证用于执行交易的一个选择。或者，商家应用程序114、630可以不提示用户，自动地从钱包应用程序112、622中提取默认或预选的支付凭证。

这种设备的轮询以及HCE和其他支付凭证的提取可以具有显著的优点。例如，这种过程可以大大增加完成交易时对购买者和其他用户190开放的支付选项的数量，因此增加了商家和FI/FSP的交易机会。为了便于设备110以及可选的FI/FSP120、160的轮询，以及支付凭证的提取，一些或全部商业应用程序114、130、630、钱包应用程序112、622，和FI/FSP系统120、150、160中可以设置为根据共同标准来处理支付和交易数据，包括例如公共通信和数据记录生成以及处理协议。如图12所示并在下文进一步讨论，根据本发明，这样的协议可以，例如，通过使用共用或通用的API 116以便于应用程序间数据交换的实现。使用这样的通用API具有显著的优点：通过，例如根据共用或通用令牌和/或HCE凭证协议进行工作，通用API116可在执行交易时向购买者如用户190提供广泛的支付选项。因此，这种API116在多数情况下可以被称为支付选项API。本发明的这些方面和实施例的适当实施方式将在下文进一步讨论。

在交易发起之前或期间，商家应用程序114、630和/或一个或多个钱包应用程序112、622可以通过网络850(通过通信组件632、612中的一个或两者)，如蜂窝网络或因特网，或不同网络类型的组合，与一个或多个远程服务器800，如与中央认证机构或可信平台相关的一个或多个服务器800通信。例如，商家应用程序114、630可以设置为从与出售的商品和/或服务相关的商家服务器提取信息或数据，例如价格和可获得性。另外，如下文进一步所解释的，商家应用程序114、630以及钱包应用程序112、622也可以例如以凭证或其他加密数据的形式与远程服务器800通信以获得授权，用于用户在移动设备110、600上发起的未完成的或将来的交易。

因此，在一些实施例中，移动OS 608可以与长程通信612和短程通信614中的一个或两者结合，以便为钱包应用程序112、622和/或商业应用程序114、630或其他应用程序115提供网络连接。长程通信612可以例如通过实现WAP通信协议来提供蜂窝数据网络的连接。或者，网络连接可以通过WI-FI天线632提供，其中移动设备110、600可以通过该天线632连接到无线网络和热点。其他通信协议，例如蓝牙，也可用于钱包应用程序112、622和商家应用程序114、630以提供至网络350的连接。

如图8中进一步的示例所示，在一些实施例中，移动OS 608还可以合并或以其它方式支持从其中可能发起电子交易的一个或多个非商家应用程序或程序115，如游戏、通用网络浏览器、读取器等。这种非商家应用程序可以与一个或多个移动钱包应用程序112、622结合，以便检索可以存储在其中的支付令牌或其他凭证，并且通过CPU 602，与网络通信组件如短程通信614或长程通信612结合，，或与任何其他网络组件如安装在非移动用户设备110、110'中的调制解调器结合。

为了发起电子交易，用户可以使用例如本文所述的任何可用的I/O设备来导航到网页或网站。在用户190通过例如选择项目添加至商品应用程序的虚拟购物车中来生成适当配置的交易请求数据集(或“请求的交易数据集”)，该数据集包括例如表示用户希望购买的一个或多个物品，以及可能全部或部分其描述，连同项目、小计和/或总购买价格的数据，并发起支付(例如“结账”)处理后，商家应用程序115向用户显示用安装在移动OS 608中的钱包应用程序112、612进行支付交易的一个选项。或者，选择用于交易的支付令牌可以位于移动设备110、110'、600中或其上的内存或其他位置中，或在某些情况下，位于虚拟钱包112或安全云资源中的其他内存或应用程序中。当用户选择通过钱包应用程序112、612支付时，浏览器可以与这种应用程序112、612交互，以便根据所选择的支付方式获得合适的支付令牌。获得的支付令牌可以通过短程通信614或长程通信612发送，以供商家后台进行处理。或者，用户可以使用某种形式的识别信息从用户设备110、110'的应用程序或程序内安全登录到银行账户，并且一旦被认证，用户的银行可以向商家/收单方传送电子支付令牌来处理交易，然后可以如本文所述通过支付网络或其他实体处理电子支付。

因此，例如，在各个方面和实施例中，本发明提供了系统、过程和持续存储的机器可访问和机器可读的编程结构，它们使得一个或多个请求设备110，如智能电话、平板电脑、可穿戴设备或其他移动设备，能够通过通信网络200以适当配置的信号交换在可信平台服务器120上注册，并且，作为这种注册的结果，能够被提供一个安全数据集，如凭证或令牌数据集，该安全数据集被存储在设备110的易失性或非易失性内存中从而使设备110在处理稍后的购买或交易时被可信平台服务器120授权为可信设备110’。例如，一个凭证数据集可以包括与设备110'中的任何一个或多个唯一相关的任何数据和/或与该设备相关的特定支付账户。这种认证/识别数据可以包括，例如姓名、“私密”的个人信息、序列号、随机或伪随机码、账号等。

在各个方面和实施例中，本发明进一步提供了系统、过程和持续存储的机器可访问和机器可读的编程结构，它们使得一个或多个商家设备132、134、136、130，包括例如POS和后台处理系统能够通过通信网络200以适当配置的信号交换在相同的和/或其他可信平台服务器120上注册。并且作为这种注册的结果，能够被提供一个安全数据集，如凭证或令牌集数据，该安全数据集被存储在设备132、134、136、130的易失性或非易失性内存中从而使商家设备在处理稍后的购买或交易时被可信平台服务器120识别为可信设备130'。例如，这种凭证数据集可以包括与设备132、134、136、130中的任何一个或多个唯一相关的任何数据和/或与该设备相关的特定支付账户。这种认证/识别数据可以包括例如姓名、“秘密”个人信息、序列号、随机或伪随机码、账号等。

可以将这种凭证数据集的副本提供给设备132、134、136、130并且存储在与可信平台120相关的安全内存中，与另外的标识符相关，这些另外的标识符与设备132、134、136、130、与设备132、134、136、130相关的一个或多个商家与实体、和/或与这些实体相关的一个或多个账户相关。如相关领域的技术人员理解的，这类数据处理设备如电子表格、关系数据库、查找表和其它表格可以用于这一目的。

一旦被接收并存储在设备110中，所有这种凭证或令牌可由设备110、商家设备132、134、136、130和可信平台120用于快速和安全地将设备110识别为“可信任”，例如用于将被配置为用于数据处理的授权和/或验证的数据集传送至可信平台120并由其解释，该数据处理例如购买或与如一个或多个商家系统130的第三方的其他金融交易。例如，支付令牌数据集可以由可信平台110从可信设备110'、130'接收，该令牌包括可以在数据库125中查找的凭证数据集连同相关的用户和/或账户信息，以用于处理支付和其他交易。

在这些方面和实施例中，本发明的还提供了可信设备110'的使用以通过直接互联网连接来协商和完成一个或多个“应用程序内”支付或其他数据处理交易，该直接互联网连接例如包括，由商家/供应商130或包括通用网页浏览器等在内，使用适当配置的超文本链接被提供给可信设备110'的用户显示屏或其他I/O组件610(例如见图6)，以及触摸屏、键盘/小键盘和/或其他用户生成的输入、信号发射器和接收器等的传送的某些其他实体提供的商家、游戏或其他应用程序(app)。

因此，例如，在各个方面和实施例中，本发明提供了系统、过程和持续存储的表示机器可执行指令的机器可访问和机器可读的编程结构，它们使得可信平台120能够注册一个或多个可信的请求或用户设备110'和一个或多个可信商家系统130'，从而通过与(a)请求设备110'和(b)商家系统130'直接通信来处理购买和/或其他交易，而不需要在可信设备110'和商家系统130'之间进行敏感账户信息如用作支付资金来源的账户、购买者身份等的通信。在这种实施例中，与交易相关的支付可以由可信平台以这种使交易有条件地或最终关闭的方式来处理。例如，当交易系统120和可信请求设备110'两者都与由可信平台120管理的账户相关时，交易可以被立即且最终关闭。如果可信设备110'、130'中的任一个或两者未与这类账户相关，则可信平台120可以离线工作来完成最终确认及交易的清算，或者通过将这种交易的一天或其他天的累积相互补偿，并且与第四方平台160结算余额，或者简单地与一个或多个第四方平台160进行协作，以在一天结束时或其他会计期间平衡收支。

作为进一步的示例，在各个方面和实施例中，根据本发明的系统、过程和持续存储的机器可访问和机器可读的编程结构可以使一个或多个可信请求或用户设备110'和商家设备132,134,136,130,130’能够协商交易并建立交易执行数据集，该交易执行数据集包括表示商家数字凭证的数据，以及可选地标识交易的进一步数据，包括例如数字凭证或与购买相关的其他标识符，一个或多个用于满足交易的账户，和/或购买或与交易相关的其他金额。这种交易数据集或者可以直接使用“脱离常规rails框架”的路由方式，或者通过一个或多个第四方交易处理器150，如其他银行、信用卡处理器等更传统的支付系统路由到可信平台120。

在这种交易数据集被路由到被授权结算或以其他方式裁定交易的可信平台120的示例中，可信平台使用与可信平台本身(例如，银行自己的账户)直接相关的资金，而不是由购买者控制的账户，将足以完成交易的支付路由返回商家系统130来与商家系统130,130'进行结算，使得在可信平台120与由与可信设备110'相关的应用程序指定的账户之间的最终结算可在较晚时间，如一天结束时或其他交易周期内进行。如相关领域的技术人员理解的，在可信平台120和与可信设备110'相关的账户之间的这种后续交易可以使用交易数据集来结算，该交易数据集适用于在可信平台自身的网络之间根据合适的加密和其他安全手段进行内部通信，这些安全手段可以与适合跨公共网络使用的安全手段不同，比其更快和/或更有效。

此外，无论是在可信设备110'、可信商家130'和可信平台120之间直接路由，还是通过公共或其他现有或不太可信的支付网络，这类交易可以根据任何所需的支付协议，如VISA、万事达卡等来完成。作为特定示例，通过更传统的(不太可信的)支付网络路由的支付交易可以被格式化为交互支付，并且根据交互协议进行处理。

在交易最初在商家系统130、130'和可信平台120之间结算，并且之后在可信平台120和与授权的可信设备110'相关的应用程序指定的账户之间结算的示例中，与可信设备110'相关的用户可以被提供一个绝对的、定时的或相对的时间以在该时间内最终指定哪个账户或哪几个账户将用于结算交易。例如，这种用户可被提供一到两个小时，直到一天中的指定时间，一天结束时或交易报告期间，或月末等以在该时间内最终指定支付账户。为这些用户抽出时间以在该时间内更改或确认要使用哪个账户，可以向用户提供时间以确保收费将清算指定账户，决定是否使用奖励或忠诚度积分来交易，或以其它方式决定使用的账户数量以及从每个账户扣除的金额。这种功能可以为用户和可信平台等提供相当大的灵活性、便利性和其他优势。

在由根据本发明的可信平台、可信设备和其他系统、设备和过程提供的许多优点中，有他们提供的适应技术发展的能力。例如，一个或多个可信的设备，包括例如一个或多个mPOS，可以参与各种形式的公共分类账簿如区块链或以其他方式与其相关。例如，在一些实施例中，可以将一个或多个mPOS或其他可信设备110'可以被建立为区块链分类账簿系统中的节点。在这种实施中，每个可信设备110'，包括任何可信的mPOS 134，可以在遵守适用的区块链/公共分类账簿协议的情况下将交易数据集从商家系统130安全地路由到FSP系统160,120。

如相关领域的技术人员理解的，区块链是用作虚拟的交易的公共分类账簿的分布式和通常加密的或以其它方式的安全数据存储，并且在实施如比特币的加密货币时特别有用。在这种分类账簿方案中，多个设备被实施为节点，每个节点控制或以其他方式访问分类账簿的不同的、完整的或部分存储的副本；分类账簿包括表示合法或以其他方式由交易招标认可的数据集。随着交易的进行，每个涉及的网络节点可以验证交易或其一部分，并生成表示合适的分类账簿注释的数据，在节点的部分或分类账簿的副本中输入注释，并推送或制造可用的更新的分类账簿注释给其他节点。

支付处理

现在参照图9，其示出了根据本发明的实施例的用于处理移动或其他支付的示例系统100、900。在各种不同的实施例中，系统900可以包括至少一个用户设备110、600，例如如图6-8所示的，可信平台或认证机构120、905，商家后台136、910，和支付网关915。如本文所描述的，系统900可以提供网络环境，在该网络环境中可信或不可信设备110、110'、600可与一个或多个可信或不可信商家系统130、130'发起与商品和/或服务有关的无卡(CNP)交易。这种CNP交易对于设备110、110、600的用户来说可获得以作为由商家POS终端(如图7中的NFC读取器132、134、700)发起的非接触式交易的替代，或补充。尽管可以主要以移动设备110、110'、600为参照，但是应当理解，在可替代的实施例中，如本文所描述的，除非环境明显不一致，非移动设备110、110'、600也可用于所有交易和其他过程中。

因此，在一些实施例中，一个或多个虚拟钱包应用程序112、622可以安装在移动或其他设备110、110'、600上，并且被提供表示至少一个支付凭证的数据。如本文所述，这种支付凭证可以由不同的实体，包括银行、信用卡公司以及其他FI或FSP发行，并且通常可以包括不同类型的HCE令牌，如单次使用或多次使用的令牌。虚拟钱包应用程序112、622可以被提供HCE令牌以根据用户偏好或其他因素仅用于单个被授权的支付方式，或者可替代地，多个被授权的支付方式。在一些情况下，HCE令牌可以被提供给用户设备110、110'、600的其他内存或存储组件。在一些情况下，支付令牌还可以被改为存储在设备110、110'、600可访问的安全云中。

此外，一个或多个商家应用程序114、630或其他游戏、通用浏览器等115,可以安装在移动或其他设备110、600上。这种商家应用程序114、630的类型和功能可以变化，但通常可以包括至少能让移动设备110、600的用户发起交易以用于购买商家应用程序114、630提供销售的一些商品和/或服务的能力。尽管图9仅描述了移动设备110、600上的单个商家应用程序114、630，但在不同的实施例中，其数量和类型通常不受限制并且可以有所变化。

在一些实施例中，商家应用程序114、630可以向认证机构120、905或可信平台注册，使得例如与商家应用程序114、630相关的商家本身将被认证和/或授权使用存储在钱包应用程序114、630或其他地方的用户的支付凭证来完成CNP交易。例如，这种商家可以通过商家后台136、910与认证机构120、905提前通信，以请求认证机构120、905向商家发出凭证，该凭证随后可以通过任何或所有商家设备132、134、136、130、130'用于认证设备110、110'，600上的交易。这种凭证可以，例如由适于本文公开的目的的任何类型的安全数据集来表示，包括例如唯一识别或以其它方式表示认证状态的代码或令牌。一旦被发布，这种商家凭证可以存储在商家后台136、910或商家应用程序114、630可访问的某些其他网络资源中。

认证机构120、905在某些情况下可以仅是认证商家系统130'的多个认证实体中的一个，每个这种认证机构120、905特别地与一个或多个不同的商家应用程序114、630，或其变体和/或组合相关。或者，在一些情况下，认证机构120、905可以是在系统100、900内的所有商家应用程序114、630共同的一个单个的中央注册或认证机构，因此，除其他优点外，发布给商家应用程序的凭证(s)114、630可以遵循公共或标准的格式或协议，这可以有助于横跨各种行业、平台等的电子支付的执行和处理。例如，所有商家应用程序114、630共同的中央认证机构120、905可以由一个或多个FI或FSP如银行，共同合作或协作并且商定处理移动和/或其他交易的标准规范和格式，来建立或操作。然而，中央认证机构120、905也可以由独立的第三方实体建立和操作。

在一些情况下，用户设备110、600和/或用户设备110、600上的钱包应用程序112、622也可以在同一个或另一个认证机构120、905上注册。因此，钱包应用程序112、622和/或设备110、600可以成为可信设备110'。例如，钱包应用程序112、622可被配置以用于与认证机构120、905进行通信来请求针对用户设备110、600，而不是商家应用程序114、630的凭证或其他加密凭证。当用户稍后在商家应用程序114、630内发起移动或电子商务交易时，除了任何其他凭证或加密处理外，这种设备专用凭证还可用来认证交易的来源。任何或所有用户、设备110、600和/或钱包应用程序112、622以及商家系统或应用程序114、630在单个中央认证机构120、905上的注册可在交易处理的安全性和效率方面提供许多优点：这种布置可以显著减少在机构120、905、商家系统136、910、发行方920和收单方925之间所需的网络通信的数量，并且从而减少或消除通信风险和延迟。

为了发起交易，用户可以在设备110、600上执行商家应用程序114、630并且选择要购买的项目(商品或服务)。例如，在访问商家应用程序114、630时，用户可以结合适当配置的用户界面显示屏使用任何适当配置的键盘、小键盘、指针、触摸屏设备、和/或其他输入/输出设备610来指定这种商品或服务。作为结算顺序的一部分，商家应用程序114、630然后可以向商家后台136、910发送(直接通过任何其他合适的组件，如mPOS或POS设备132、134)请求，用于提供由认证机构120、905向商家发出的凭证。在请求已经得到满足后，商家应用程序114、630然后可以使用收到的商家凭证来查询钱包应用程序114、630来获得访问支付凭证的许可，如HCE令牌。在一些情况下，商家应用程序114、630可以在从商家后台136、910收到商家凭证之后自动查询钱包应用程序112、622。或者，商家应用程序114、630可以向用户显示提示，该提示要求明示查询钱包应用程序112、622的授权。

或者，用户可以从商家应用程序114、630以外的，安装在设备110、110'、600上的任何其他应用程序或程序115内选择要购买的项目(商品或服务)而发起交易。作为结账顺序的一部分，例如，用户可以使用任何适当配置的I/O设备610结合适当配置的用户界面I/O显示屏来选择用于支付的钱包应用程序114、630。该选择可以响应于呈现的多个不同的支付选项，包括那些不使用钱包应用程序114、630的支付选项。

在收到来自商家应用程序114、630或某些其他应用程序或程序114、115的查询后，钱包应用程序112、622可以配置为验证被包括查询中的商家凭证的来源或以其他方式认证该商家凭证。例如，钱包应用程序112、622可以被提供用于确保商家凭证有效的私人密钥和/或其他加密数据。如果钱包应用程序112、622不能验证商家凭证，则由商家应用程序114、630发送的查询可以被拒绝；可选地，钱包应用程序112、622可以生成针对设备110、110'、600的用户和商家136、136'、910中的任一或两者的请求，以重试或覆盖授权的否定。如果钱包应用程序能够验证该凭证，则钱包应用程序112、622可能回复商家应用程序114、630可以被授权访问存储在其中的支付凭证的指示或信号。

在成功查询钱包应用程序112、622后，商家应用程序114、630可以从钱包应用程序112、622中提取钱包接口授权，其可有效地让商家应用程序114、630访问和控制至少部分支付凭证和存储在钱包应用程序112、622中的其他数据。因此，商家应用程序114、630能够与从钱包应用程序112、622内可能进行的相同的方式来处理或操作用户的支付凭证。

例如，根据提供的HCE令牌或其他支付凭证的数量和/或类型，商家应用程序114、630或者可以自动选择一个支付凭证用于所发起的交易，或者可以改为提示用户从商家应用程序114、630内选择一种支付方法。例如，当只用于一种支付类型的HCE令牌被提供，或者用于多种不同支付方式的HCE令牌被提供，但是用户已经在钱包应用程序112、622中指定其中一种可用支付方式作为默认项时，自动选择可能会发生。另一方面，如果没有如上所述的默认项被指定，则商家应用程序114、630可以使用如前所述的设备110、110'、600的I/O组件来提示用户选择支付方法。

无论是通过提示还是自动选择，商家应用程序114、630都可以从表示用于交易的支付方法的钱包应用程序112、622中提取支付凭证。然后，商家应用程序114、630可以将表示HCE令牌或其他支付凭证的信号连同完成交易所需要的或使用的其他信息(日期、商家标识、金额等)一起发送到商家后台136、136'、910。在某些情况下，发送到商家后台136、136'、910的支付信息可以被加密，使得即使商家可能也无法查看用户的任何敏感信息。在不同的实施例中，支付信息的加密可以由商家应用程序114、630或由设备110、110'、600上的某些其他应用程序或程序来执行。然后，商家后台136、136'、910可以将从移动设备110、110'、600接收的HCE令牌或支付凭证连同任何其他要处理的交易信息一起转发到支付网关150、915。

在一些实施例中，即使支付令牌没有存储在其中而是存储在安全云中，交易也可以从设备110、110'、600上发起。例如，用户可以导航至应用程序或程序，如通用网络浏览器，并且决定发起支付或结账的顺序。在这种情况下，用户可以被提交用户银行或可信平台120、160、905的安全登录，并被提示用户输入认证信息，如密码或生物特征。如果用户能够成功认证，则银行或可信平台120、160、905可以使支付令牌被发送到商家后台136、136'、910来用于处理该交易。

在一些实施例中，商家凭证不用于查询移动或其他钱包应用程序112、622以检索支付令牌，而是这种商家凭证只用于对支付令牌数字签名，该支付令牌被从钱包应用程序112、622或设备110、110'、600上或以其他方式可由其访问的或从安全云上的一些其他内存上取回。因此，在这种情况下，用户可以在商家应用程序114、630或某些其他应用程序或程序115，如网络浏览器中操作，并且可以发起电子交易。在这种情况下，用户当前正在访问的应用程序或程序可以直接访问支付令牌，以用于作为支付信息的一部分传送到商家后台136、136'、910。在一些情况下，如本文所描述，在用户或用户的移动设备110,600进行身份验证后，支付令牌可以被直接从银行或可信平台120、905提供给商家后台136、136'、910。

支付网关150、915通常可以是，或者包括任何FSP或应用程序服务提供商，该服务提供商代表电子商务、线上零售商或其他传统实体零售商授权信用卡和其他交易。因此，支付网关150、915可以是一些实体，该实体代表指定商家或商家群体处理所有移动和/或其他交易，包括从商家应用程序114、630内发起的移动交易。尽管为了方便仅示出每个支付网关中的一个，每个商家或商家应用程序114、630因此可以与一个或多个不同的支付网关150、915相关。除了促进移动或其他交易的处理之外，支付网关150、915还可以完成服务，如敏感信息的加密或进一步加密、欺诈检测等。

如图9所示，在一些实施例中，系统100、900可以被配置，使得支付网关150、915可以根据被选择以用于交易的支付方式并且，在某些情况下，根据可信平台120,905是否授权交易，而有区别地处理移动交易。例如，支付网关150、915可以被配置为检测基于已被接收到的HCE令牌或支付凭证来选择的支付方法，然后将交易相应地路由到一个或多个其他下游实体。为了确保HCE令牌或其他支付凭证为可识别，在某些情况下，支付网关150、915和/或此类HCE令牌或其他支付的配置可以与中央认证机构120、905共同与其相结合进行或，该机构已被授权进行认证交易。在这种方式下，无论哪个用户或商家应用程序130已经发起了交易，支付网关150、915可以因此能够检测各种不同的令牌。

例如，在一些情况下，支付网关150、915可以设置为检测到收到的HCE令牌表示或以其他方式显示Interac^TM(借方)交易，在这种情况下，支付网关150、915可以将交易直接路由到与所选支付方法相关的发行方160、920，例如控制用户持有的活期或定期存款账户的银行。这种发行方160、920然后能够通过从在令牌中被指定的账户借记正确的金额来结算交易。这种交易实际上可能是Interac^TM交易，或者如下文进一步描述的，可能是已经被编码为显得像Interac^TM交易的一些其他类型的交易，使得它将直接由发行方银行，而不是一些其他的中间或第四方处理商，如收单银行，处理。

支付网关150、915还可以检测到收到的HCE令牌表示信用卡交易，在这种情况下，支付网关150、915然后可以查询来确定交易将如何被结算。一些发行方160、920可能同意直接从支付网关150、915将交易路由用于结算。或者，表示信用卡支付的一些移动或其他交易可以先由支付网关150、915路由到收单方150、925或收单方的处理器，然后再到发行方920用于进行结算。

因此，在一些实施例中，发送到商家后台136、136'、910的支付令牌可以使用商家凭证来签名，这些商家凭证已经由认证机构120、905或某些其他可信平台发行和提供给商家。当支付信息通过支付网关150、915转发时，在某些情况下，它将被检测为Interac^TM交易，因为已经被设备110、110'、600或商家后台136、136'、910配置为呈现这个外观。因此，取代于被转发到收单方150、925或其处理器，这可能另外为支付网关150、915的决定，该支付消息可能改为被直接中继到发行方160、920。支付消息然后在处理商家支付之前被验证和/或解密。在某些情况下，发卡银行160、920可以直接以消息中指示的支付方式安排支付。然而，可选地，在一些情况下，发卡银行160、920可以从银行的资金向商家支付，然后通过本文所述的任何手段与移动设备110、110'、600的用户结算。

在一些实施例中，当发送到商家后台136、136'、910的支付令牌使用商家凭证被“签名”或以其他方式被认证时，支付网关150、915可以完全被绕开，而商家后台136、136'、910改为可以直接与发行方160、920通信来处理交易。在这种情况下，发行方160、920可以使用支付消息中指定的支付类型和/或资金与商家结算。或者，如本文所述，发行方160、920可以在某些情况下先用发行方提供的资金与商家136、136'结算，随后再根据商定的结算方式与用户进行结算。

现在参照图10，其示出了根据本发明的实施例的用于处理移动支付的示例系统100、1000。与如图9所示的系统900类似，在各种不同的实施例中，如本文所述，系统1000可以包括至少一个移动设备110、110'、600，认证机构120、905以及商家后台136、136'、910。因此，为了方便且易于说明，除了可能特别显著的某些差异外，对于这些元件的描述可能略有缩减。

尽管在系统900中，支付凭证可以横跨不同的支付方式(借方，信贷)和/或方案进行标准化，系统1000可以设置为处理其中支付令牌尚未被标准化的移动和其他交易。因此，例如，移动交易仍然可以被发起，该交易的发起通过例如商家应用程序114、630从钱包应用程序112、622提取钱包接口以用于选择特定的支付方法，或是通过用户从网络浏览器或移动设备110、110'、600上的其他应用程序中发起交易。然而，存储在钱包应用程序112、622或内存中的别处的令牌可以由多个不同的令牌服务提供商(TSP)，而不是单个授权机构如中央认证机构120、905，来提供。

因此，系统1000还可以包括插入在支付网关915、150和发行方160、920之间的一个或多个令牌服务提供商925、160。当从商家后台136、136'、910接收交易时，支付网关150、915可以确定哪个TSP 150、925发行接收到的令牌，然后相应地路由该交易。例如，每个TSP150、925可以根据不同的信用卡方案(Visa^TM，Mastercard^TM)以及其他支付方法如Interac^TM(借方)交易，来操作。然后，这种TSP 150、925可以将交易认证并路由到发行方920、160。

现在参照图11，其示出了根据本发明的实施例的用于处理移动和其他支付的示例系统100、1100。与如图9所示的系统900相似，在各种不同的实施例中，如本文所述，系统1100可以包括至少一个移动设备110、110'、600，认证机构120、905以及商家后台136、136'、910。因此，为了方便且易于说明，除了可能特别显著的某些差异外，对于这些元件的描述可能略有缩减。

如前所述，除了贷记和借记交易外，本发明能够对各种可替代的支付方法令牌化。例如，发行方120、160、920(例如银行或其他金融机构)可以扩展顾客的信贷额度或其他有价值的资产。通常顾客无法用这些资产进行支付。然而，根据本发明，发行方160、920可以为移动或其他设备100、110'、600提供令牌，其表示顾客的信用额度或其他资产或与其相关的一个或多个数值。这种令牌可以以任何所需的形式数量和/或形式变化存储在一个或多个钱包应用程序112、622中，以用于后续的移动支付。这种支付令牌被存储在其中的移动设备110、600在某些情况下可以是可信设备110'。

因此，当交易被发起时，由商家应用程序114、630提取的令牌在某些情况下可能表示发行方920的信用额度。当交易从商家后台136、136'、910被收到时，作为编码支付消息的可信移动设备110、600或商家后台136、136'、910被如此检测的的结果，支付网关915然后可以检测到收到的令牌表示信用额度或其他资产，然后将交易直接路由到与令牌相关的发行方920。发行方920然后可以通过从顾客的可用信用中扣除适当的金额来结算交易。

因此，在通过本发明能够实现的其他改进中还有移动和其他设备，每个设备包括一个或多个显示屏、一个或多个用户输入设备以及一个或多个短程/或长程网络通信系统；一个或多个数据处理器；和一个或多个内存设备；所述内存设备包括持续的、被存储的表示至少一个或多个安全支付令牌的数据，每个支付令牌包括与被授权的支付金额以及该被授权的支付金额被其授权的金融服务提供商相关的数据。内存设备还包括内存，该内存包括持续的、被存储的表示一组或多组机器可读的或以其他方式可执行的指令的数据的内存，并且数据处理器在执行所述一组或多组存储的机器可读指令时设置为从安装在移动通信设备上的一个或多个应用程序内发起支付或其他交易；从所述至少一个用户输入设备接收表示在所述显示屏上显示的支付选项的用户选择的数据，并且作为响应，访问所述持续内存设备并将所选的支付令牌提取到所述应用程序中；以及通过所述网络通信系统将所选的支付令牌从应用程序内路由到交易处理系统，以用于处理所发起的交易。

本发明还提供了这样的设备，其中支付选项从应用程序内显示，该应用程序包括例如由商家交易处理系统提供的应用程序，并且该应用程序适用于促进移动通信设备和商家处理系统之间的通信。

本发明还提供相应的过程；持续存储的机器可执行指令集；以及适用于这种设备使用的系统100、900、1000。

现在参照图12，如上所述，存储在设备110、110'的虚拟钱包112中的HCE令牌和其他支付或交易凭证可以由安装在设备上或以其他方式可由其访问的其他应用程序114、115以各种方式来访问，该应用程序包括由一个或多个商家提供或与其相关的应用程序114。例如，商家应用程序114可以被授权或以其它方式被授权通过实施提取架构以访问来自可信设备110'的钱包应用程序112内的信息，该提取架构的实施可以通过在可信设备110'上提供系统级的应用程序编程接口(API)116来促进，该接口是钱包和商家应用程序两者共同的或以其他方式可由这两者访问。例如，如图12所示，这种API可以以单独的支付选项应用程序API 116(“由您的银行SDK”支付)的形式被提供；或者，这种API 116本身可以通过轮询应用程序112、114和服务器120、160等，以查找设备110的已验证的授权用户190可用的支付资源，并且将它们呈现在输出设备610上适当配置的GUI中来起到一个共同、或通用钱包112的作用。这种特征可以为用户190、商家130和FI/FSP120、160等提供显著的优点。例如，由于在这种实现方式中，已经存储在这种移动钱包112中的令牌和/或其他支付凭证可以由商家应用程序114提取，因此用户可以免除直接将任何信用卡或其他敏感信息，如机密标识符输入商家应用程序的任何必要性。这样一个实施例的实现方式和用途的示例结合如图13所示的过程1300在下文被提供。应当注意的是，除了其他优点，不同的安全支付选项API 116的使用可以为设备110、110'的用户提供对于各种支付选项和偏好组合的增强且极其灵活的控制。

如上所述，例如，轮询任何或所有设备110，包括已安装的应用程序112、114；FI/FSP120、160；商家设备和系统132、134、136、136'；以及任选的其他资源，并且提取支付凭证，可以通过将这种设备配置为根据共同标准来生成、存储和以其他方式处理表示支付令牌、HCE凭证和其他交易相关信息的数据来完成，其中共同标准包括例如公共通信以及数据记录生成和处理协议。一般来说，这种协议的确切格式不是最重要：更重要地，相关数据，如支付和/或存款账号(或其他标识符)，被授权和/或被请求的交易金额，以及与账户持有者、被授权的账户用户、账户管理员以及支付人和收款人相关的标识符，可以以任何合适和被商定的格式被嵌入到交易数据记录中。

使用这种适当调整的令牌和/或凭证格式，支付选项或通用钱包API 112、116可以设置为与每个其他商家系统和/或设备130、132、134、136、136'和/或FI/FSP系统120、160之间的任何、一些或全部通话。

在实现这种支付选项或通用钱包API 116时，例如结合图1-5、9-12和15A-15B示出和描述的可信架构可以是极其有益的。例如，如本文所述的认证/注册过程的使用可以极大地促进采用如本文所述的共同或通用协议的接受度、安全性和效率。

现在参照图13，其示出了根据本发明的各个方面和实施例的处理移动支付或其他交易的方法1300。方法1300可以由任何或所有系统100(图1-5、图12)、900(图9)、1000(图10)和/或1100(图11)执行或与其相关，并且通常可允许请求通信设备110、110'的用户从与已经安装在移动设备上的商家相关的应用程序或程序内发起和完成移动交易。尽管在如图13所示的实施例中，方法1300被描绘为离散事件或动作的顺序，相关领域的技术人员应当理解，这种表示仅仅是为了清晰和方便，而且可替代的实施例也是有可能的。例如，在变体的实施例中，可以重新排列被描述的动作的顺序、包括进一步的动作、省略某些被描述的动作和/或将一个或多个动作结合在一起，等等。所描述的特定顺序仅仅是多种可能性的一个示例。

因此，在一些情况下，方法1300可以开始于为移动、桌面、或其它用户设备110、110，提供1305一个或多个表示用于设备110、110'的用户的各种授权支付选项的HCE令牌或其他支付凭证的任何一个或多个。HCE令牌或支付凭证可以由不同的实体120、160，包括绑定到一个或多个特定支付方法或方案的令牌服务提供商160、920提供，但在某些情况下也可由提供横跨多种不同支付的标准令牌和/或方案的中央认证机构120、905来提供。在某些另外的情况下，支付令牌可以被提供给可由移动或桌面设备110、110'访问的安全云，而不是用户的设备本身。

商家和商家应用程序中的其一或两者可以由例如中央认证机构或可信平台120、905来验证1310，使得涉及提供HCE令牌或其他支付凭证的移动和/或其他交易被认证。例如，商家和/或一个或多个相关的商家系统130、910可以通过在认证机构120、905上注册商家应用程序或程序114、630来被验证1310为移动或其他类型的支付可在其中被授权的商家应用程序或程序114、630。认证机构或可信平台120、905作为过程的一部分可以通过商家应用程序，以包括任何合适的标识符和/或安全码等的商家认证数据集的形式向相关的商家系统130'、910提供用于处理移动支付的凭证。

可选地，在一些情况下，用户还可以使用认证机构或可信平台120、905来验证1310移动或其他设备110。例如，认证机构120、905可以注册一些关于用户设备110、110'的唯一的识别信息，例如序列号、网络地址、或随机或其他任意标识符。然后，如果这种交易源于与被注册的识别信息匹配的设备110'或以其他方式与其适当相关，则涉及提供给这种注册设备110'的HCE令牌或支付凭证的所有移动交易也可作为可信的来处理。

为了发起支付或其他交易，用户可以启动商家应用程序或程序114、630。例如，移动设备110、110'的用户可以接近具有用户希望购买的一个或多个商品或服务的商家POS132、134，将项目提交给商家以用于扫描，并从而自动或半自动地导致存在于移动设备上的商家应用程序114、630的启动；或者桌面设备110、110'的用户可以使用通用浏览器导航到商家网站，并使用已知技术选择一个或多个项目或服务放置在虚拟购物车中，并且在准备好时发起“结账”程序或其他支付过程。作为程序化的支付或结算顺序的一部分，商家应用程序114、630可以请求从相关的后台系统136、910中的网络位置提供商家凭证。一旦被接收到，商家应用程序可以使用被接收到的凭证来查询安装在用户的移动或桌面设备110、110'上的钱包应用程序112、622。当被查询时，钱包应用程序可以通过使用私钥或其他加密信息验证商家凭证的可靠性，并根据验证结果进行响应。或者，商家应用程序或程序114、630可以查询用户支付选项应用程序116或直接从钱包应用程序112、622请求令牌，以用于向商家系统630提供凭证信息。

相关领域技术人员应当即刻理解的是，用于通过设备110,110'的使用来实现访问商家应用程序114、630和/或商家系统130，例如包括如本文所述的使用这种系统和应用程序来识别用户默认选项的方法或过程，可以包括任何各种合适的编程设备、结构或方法。例如，移动设备110、110'的用户可以使用在他/她的移动设备上适当配置的网站浏览器以类似于他/她在桌面设备上操作的方式，来导航到商家系统130、132等；并且根据所描述的方式cookies和其他自动或半自动设备可以被使用来指定默认选项和选择。作为另一特定示例，在移动设备110、110'上实现的浏览器可以设置为，例如使用插件应用程序或其他适当配置的代码，通过商家API114、630来与移动钱包112、622通信，以便从钱包中提取标识符和/或其他支付数据和凭证以用于商家系统130、132、136等或与其一起使用。这种实现方式可能具有特别的优势，因为例如，并不是所有商家都可以选择提供用于移动设备上的专用或其他应用程序114，而且使用这种通用浏览器、cookies等可以为它们有效且高效地实现本发明的这些方面提供重要机会。

能够访问这些应用程序和系统的所有设备、机构、途径、程序和方法都被认为属于本发明相应方面的范围。

在验证商家的凭证数据后，用户的钱包112、622和/或支付选项API 116可以允许商家应用程序从钱包应用程序112、622提取1320钱包接口到商家应用程序114、630中。如在图14A中所示例性地示出，钱包接口112、116可以包括一组程序指令，该程序指令在进行这种验证(或者在交易过程中的任何其他适当时候)时完全或部分地导致用户设备110、110'生成和显示允许用户选择哪个存储的支付令牌和/或多个支付选项中的哪一个用于处理发起的交易的用户存储的支付凭证的图形用户界面(GUI)或其他视觉显示1402。

例如，由设备110'的用户在POS 132、134处或在桌面系统110的网站浏览器中选择显示在设备显示屏610上的交互式GUI设备“结账”或“准备支付”，可以导致设备110'生成并显示GUI，该GUI包括表示由设备110'的用户可用的支付选项的项目1404、1406。在如图14A所示的示例中，例如，用户已经被提交了提供两种支付选项的选择的GUI 1402：一个由商家控制的“结账”选项1404以及一个由钱包或可信平台控制的过程“用您的银行支付”选项1406。

由用户选择如图14A所示的交互式GUI“结账”单元1404可以导致设备110'发起由商家应用程序114、630控制的过程，以使用户能够通过使用支付过程来完成交易，该支付过程由商家后台系统136、910授权或以其他方式控制以生成交易授权请求数据集。这种过程可以，如图1示例性地示出，例如通过使用第四方支付处理器150来完全或部分地实现。这种过程可以，例如根据已知和广泛商业化的电子结账程序进行。如本文通常所述的，通过使用这些过程生成的交易授权请求数据集可以包括由一个或多个FI/FSP 120、160必需的或所需的任何信息，包括例如总购买金额，与用作支付资源的账户相关的标识符和/或被指定用于接收支付的商家或其他账户，以及任何路由、确认和/或安全数据或设备，这些信息必需批准以用于完成交易。

例如，由用户选择GUI单元1406“用您的银行支付”可以使设备钱包112、630和/或支付选项API 116继续或发起由任何或全部钱包114、630、API 116和/或可信平台(TP)120、905控制的支付过程。例如，通过使用触摸屏设备610选择项目1406可以导致生成和显示(例如，通过使用由支付选项API 116提供的数据)GUI 1407，如图14B、14E所示，该GUI示出了由用户190可用作资源的一个或多个选项1486，该资源用于根据由钱包112、622提供且由支付选项API 116提取的数据和或指令来完成支付。在如图14B所示的示例中，移动设备110'的用户190已经被提供在1471处以列表的形式显示部分相应的请求交易数据集的GUI 1407，其中列表包括确认至少一个要购买的项目(博世30”平顶炉台)的信息以及与该项目相关的价格。用户还以交易支付来源的形式为提供表示第一支付选项的图标1408，该交易支付来源被识别为由可信FI 120、160管理的贷记账户“加拿大皇家银行维萨AVION卡(RBC VISAAVION)”。

如图14C和14D所示，在图14B中提供的GUI 1407可以以交互式“覆盖”屏幕1409的形式提供，或者通过导致显示器生成新的GUI 1407并完全覆盖前一屏幕，或者例如通过使用“渐变”或“灰色”成像技术来允许用户190与支付选项116和/或钱包114交互，而不另外终止或中断由商家系统130执行的结账阶段或过程，包括由如图14A所示的GUI 1402管理的商家的默认结账过程。这可以例如，使用户能够滚动GUI 1407以便通过钱包114、选项应用程序116和/或相关的FI 120、160查看可用的进一步的支付选项；并且可选地通过使用账户或资金来源的组合来控制支付。

例如，通用钱包或支付选项API 116可以轮询设备110、110'以获得所有存储在设备上的钱包112、支付令牌和/或其他支付凭证集的完整或部分列表，并通过这种GUI显示它们以供用户查看和选择。这种列表可以由默认项完全或部分填充，由用户、商家或与设备110、110'相关的FSP，或与设备相关的任何支付令牌和或交易凭证设定。例如，可由设备访问以应用于交易的所有卡、账户或其他价值来源的列表，连同识别包括品牌标志的全部或部分信息可以被显示，以供用户查看和选择。例如，卡片或账户详细信息，以及卡号、账户持有者姓名和/或省略地址所有、一些或大部分的列表可以被显示，使得用户190能够在不公开披露敏感信息的情况下选择所需的支付来源。

在由本发明的这些方面和实施例提供的许多有利特征中，有允许用户使用一个或多个支付账户和/或其他价值来源来支付交易，并且可选地，控制这样组合的哪些部分将用于这样做的简洁的、用户可控的机构。例如，如图14C所示，用户190已经通过触摸屏、点击设备和/或其他I/O组件610的使用来滚动查看GUI 1407的一部分，其显示总购买金额为40.25美元，并且使用户能够用“Avion忠诚度余额”项目1420以使用忠诚度积分或美元来支付所需的购买；其余部分通过使用其他账户，如“加拿大皇家银行维萨AVION卡”账户支付。在所示的示例中，用户被展示以启用触摸屏的滑块1422为形式的交互式设备1420，它可以由用户使用来增加或减少使用忠诚度账户来支付的总计$40.25的金额。在所示的示例中，用户已经调整了滑块1422，使得如果项目“支付”被选择，则将导致总金额$40.25通过使用来自Avion忠诚度余额的价值18美元的积分来支付，并导致余额($22.25)被应用于加拿大皇家银行维萨AVION卡贷记账户或其他指定的资金来源。

本发明实现了组合的支付来源的交易的各种变体。例如，由商家或其他应用程序控制的应用程序内过程114、115可以向用户190提供界面屏幕1407，该界面屏幕1407显示了关于用户可用于交易的现金金额、奖励或其他价值的信息，例如多少可由用户使用的忠诚度积分被应用于所请求的交易。用户190可以，例如通过使用视觉滑块或其他界面1420来指定可用积分被兑换以用于所提出的交易的数量。可选地，一旦用户通过应用程序114、115完成了交易，则应用程序可以向另外指定的用户账户收取全部交易金额，而不对所使用的积分应用任何折扣。应用程序114、115还可以通知与交易相关的指定钱包112兑换所选择的积分数量，并且对所述用户选择的支付卡贷记兑换积分所得的美元金额。

此外，通过为所有被用户190授权使用的钱包、账户、令牌和/或HCE凭证数据轮询设备110、110'和/或一个或多个FI/FSP 160，根据本发明的钱包应用程序114、116可以使用户能够选择用户可能通常用于交易的任何借记、贷记或积分账户，而不仅仅是，例如，与特定商家相关的忠诚度计划或以其他方式由商家偏好的支付形式。

特别是在需要使用忠诚度或奖励积分进行全部或部分支付时，POS交易也可以通过由本发明实现的支付过程的应用来改进，该支付过程包括能够从多个用户账户支取的那些支付过程。希望以这种方式支付的设备110、110'的用户190可以下载与FI/FSP120、160相关的钱包应用程序，其中FI/FSP120、160与资金账户和忠诚度或奖励账户两者相关，选择兼容HCE的资金账户用于支付，并且如果积分可用并且有资格在交易中兑换时，则积分滑块1420或类似设备可自动显示。用户190使用设备1420可以选择兑换多少积分，和/或支付的哪个部分要通过兑换的积分支付；并且当用户在POS终端上连通设备以支付或以其他方式授权交易完成时，钱包112可以以这种商家系统既不被告知也不负责于积分正被用于支付部分或全部交易价格的事实的方式，将包括表示被透露的积分数的数据项目的交易支付数据集路由至商家系统136、136'，并提供对于数据字段中附加信息的访问，该数据字段仅向用户190显示关于多少积分要兑换。这种功能，例如有时可作为包括EMV标准的标准支付协议的一部分。当交易数据集被路由至与正常过程中的现金和积分支付账户相关的FI时，隐藏字段可以被解析。如果它包含兑换积分的指示，FI可以根据其内部会计原则应用积分，而不要求商家系统136、136'以基于现金以外的任何方式处理支付，FI 120、160可以通过使用设备110、110的通信系统，直接确认与用户190的交易。

如图14C所示，沿着界面显示屏1407向下滚动可以导致GUI设备1430显示关于在1432处说明的忠诚度账户的更多信息；在这种情况下，在剩余积分被用户兑换应用于交易之前指示需要购买的进一步数量。如相关领域的技术人员理解的，横跨多个FI平台120、160的支付选项API 116的使用可以使认证机构120、905或其他可信平台能够跟踪与信贷、借记和其他支付账户等相关的多个奖励计划、账户余额，并且将这些信息以联合且有序的显示1407提供给用户190。

由本发明提供的另一个有利特征是无论这些账户是否由公共实体持有或是管理，允许用户190从任意数量的账户和/或账户类型中选择来指定哪些账户将用于完成交易的能力。例如，支付选项API 116或钱包112可以适用于使用户能够通过如GUI 1407在由用户控制但由FI 160持有或以其他方式控制的账户之间进行选择。例如，如图12和图14E所示，选择支付选项1406(图14A)可以导致支付选项应用程序116或第一钱包112轮询一个或多个(第二)钱包112和/或认证机构120以获得用于识别可由授权用户190使用的多个支付选项的信息，并且导致适当配置的显示屏610在GUI 1484上呈现包括一个或多个对应的可选GUI图标1486的GUI 1407。选择项目1486'，例如，可以导致如图14C所示的“加拿大皇家银行维萨AVION卡”选项由如图14F中在1489处所示的与折扣账户“TD折扣奖励卡”相关的支付选项替换。如相关领域的技术人员理解的，一旦他们熟悉了本发明以及本文公开的本发明的优点，图形项目1486等就可以以与相应账户相关的具有独特品牌图像的缩略图或其他图像，或其他标识符的形式提供。

在支付选项API 116和/或钱包112使用户190能够从用于完成交易的多个账户或资金来源中进行选择的各种实施例中，用户190能够在选择支付选项项目1406时选择显示的一个或多个默认项或默认项组合。例如，如关于图14A和图14B所示和先前描述的，当一个默认项被用户190和/或一个被授权的FI 120,160中的任一或两者预先指定时，选择这种项目1406可导致一个或多个可覆盖的支付选项，如优先的借记、贷记、忠诚度、礼品和/或奖励账户的显示。在这种实施例中，先前指示的默认偏好可以由，例如凭借在屏幕上相对放置包括文本、颜色、阴影或其他图形设备等相关的的标识符来使用如图14E所示的项目1477，来指定。在如图14E所示的示例中，选择图14A中的支付选项图标1406可以导致使用“TD折扣奖励维萨卡”账户支付的选项，而不是如图14A所示的“加拿大皇家银行维萨AVION卡”的显示。

在本发明中适用于实现指定默认账户的选择的实施例中，默认项可以通过使用任何一个或多个所需的或其他合适的机构来识别。例如，设备110、110'的用户190可以在建立商家购物应用程序114和公共HCE支付选项SDK/API 116、(有时称为通用钱包应用程序)API112、116中的一个或两者时，或任何晚些时间，指定一个或多个默认项；和/或相关的FI120、160可以提供或要求各种默认配置。或者，默认项可以基于用户动作和/或用户动作趋势，在交易期间，通过使用例如在已完成交易期间生成或以其他方式关于已完成的交易提供的cookies，来自动或半自动地指定。

在这种和其他实施例的进一步变体中，本发明提供使用令牌和其他支付凭证的新的和有利的方式，该方式可以例如由一个或多个特定用户或设备指定和/或以其他方式与其相关，以用于各种目的，包括例如指定默认支付来源和用于处理交易的其他选择。例如，通过使用先前由特定用户输入的或以其他方式与其相关的，且用于识别或以其他方式认证其的数据，商家应用程序114可以向钱包应用程序112提供相同或其他标识符，以便在交易处理期间指定一个或多个默认选项显示给设备110'的用户190。例如，在交易时，商家应用程序114可以将表示与授权用户190相关的电话号码或其他信息的数据提供给与由该授权用户使用的设备110'相关的钱包应用程序114。例如，商家POS 132或商家系统130可以向钱包112提供先前由用户190提供的电话号码，或将从其他获得的、先前提供的数据提供给钱包112，供钱包112用于识别处理交易时用做默认项的账户。此外，在各种实施例中，这种用户可能需要单独提供用户名/密码、PIN和/或其他标识符以完成交易。

过程1300、1500的进一步的变体可以在使用时具有特别的优点，该特别的优点在于，用户190具有安装在他/她的设备110、110'上与多个FI/FSP 120、160相关的钱包应用程序112，但是主要依赖于其中一个钱包应用程序112以用于购买交易。为了用于完成POS购买和其他购买，优选的钱包应用程序112可以设置为导致可选择的GUI项目1406“用您的银行支付”的生成和显示，这将允许用户启动在设备上具有相似功能的任何其他钱包112。例如，用户190在实体店中排队结账，并且调用了优选的钱包应用程序112，因为这是用户最初希望使用的，但是随后决定改为使用表示由不同的FI/FSP 120、160持有的账户的HCE凭证来支付。例如，用户能够仅仅从优选的钱包应用程序112内点击“按钮”1406，导致优选钱包应用程序112和SDK/API 116中的任一或两者生成并显示包括在中央认证机构120注册的所有FI的列表的GUI 1407。用户可以选择与所需的FI相关的GUI项目1486，并且如果相应的钱包应用程序112安装在相应的钱包应用程序112被启动的设备110、110'上，用户可以进一步选择与该FI相关的个人账户(例如，在贷记、借记和忠诚度账户之间进行选择)，并且将设备110'，100连通到启用NFC的POS设备132、134POS上以支付。与所选钱包应用程序112相关存储的令牌或其他合适的凭证数据集可以直接发送到POS终端，或者可以通过SDK/API 116“用您的银行支付”通信标准被发回(提取)到最初优选的钱包应用程序112，并且第一FI钱包112可以将适当配置的交易支付数据集路由到POS终端。类似过程也可用于从商家或其他应用程序114、115生成的应用程序内支付。

如前所述，本发明的许多方面和实施例可以在桌面或其他非移动或半移动设备110上，以及在智能电话、智能首饰或其他可穿戴设备、平板计算机或其他移动设备110上实现。在这种实现方式中，如图16所示，网站浏览器可以与商家系统130、钱包112和支付选项API 116等结合使用以生成和显示支付选项GUI 1407、1402。这种GUI可以适用于提供例如结合图14A-F所描述的任何或全部功能。

在例如钱包应用程序程112仅存储一个支付凭证或者默认支付方法已经被设定的其他情况下，在商家凭证验证后，商家应用程序114可以从钱包应用程序中自动提取1320这种支付令牌。然而，在一些情况下，商家凭证可能不用于作为认证过程的一部分查询移动钱包应用程序来检索和/或获取支付令牌，并且商家或应用程序可以直接访问移动钱包应用程序或其他令牌被存储的地点。

仍然参照图13，在选择由用户190指定用于完成移动或其他支付的一个或多个支付令牌和/或支付资源凭证后，商家应用程序114可以生成一个交易授权请求数据集，该交易授权请求数据集包括例如形式为表示指定令牌的数据的一个支付(安全)令牌编号(或令牌可能位于的IP地址的编码)和/或其他支付来源(例如，支付账户标识符)，以及识别被指定用于接收支付的商家账户的数据，任何路由或特殊指令等；并且在1325处，交易授权请求数据集可与其他交易特定信息一起通过商家后台到支付网关。支付网关可以根据不同的因素，例如由被包含的令牌表示的支付方法，以及用户的设备和/或商家是否已经被可信平台认证，来对交易进行不同的处理1330。例如，借记交易可以直接路由至发行方，并与用户银行结算1335。或者，一些信用卡交易在最终与发行方结算1335之前可以先路由至收单方。在某些情况下，例如，在这种授权是由可信平台授予的情况下，信用卡交易可以改为直接路由给发行方来结算1335。这可以例如由可信设备110'或商家来完成，它们导致表示信用卡支付的支付消息显示为表示替代的支付形式，如Interac^TM交易的支付消息，从而被直接路由至发卡银行，而不是至中间或第四方处理器，如收单方。用于处理和结算移动或桌面交易的其他选项，包括可信商家绕过整个支付网络直接将支付路由至发行方的情况如本文所述。

用于启用和以其他方式实现支付交易的支付过程1500的另一个示例如图15A所示。与过程1300一样，过程1500使购买者190能够选择完成支付交易时的任何一个或多个各种支付选项。

过程1500可以从1502处开始，如本文所述，商家可以在一个或多个FSP 160和/或可信平台120上注册或验证商家系统136，以创建可信商家系统136'。商家系统136'的注册可以包括通过认证FSP 160向商家系统136提供认证数据集136'，该认证数据集136'包括任何有用的或以其他方式合适的标识符、公共/私人或其他担保等，以便商家将其状态认证为注册或可信商家。

如本文所述，在商家系统136'被注册(即，认证)后，在1504处商家可以创建或以其他方式获得一个或多个适当配置的商家购物应用程序114和/或公共HCE支付选项SDK/API116，其被配置为使设备110、110'的用户190能够在商家网站或实体店购物并从而生成交易请求授权数据集。如本文所述，商家系统136'还可以导致这种商家购物应用程序114和/或公共HCE功能API 116在1506处被提供至一个或多个用户请求通信设备110、110'。除了使用户能够购买商家的产品并生成交易授权请求数据集外，应用程序114和/或SDK/API 116还可以，除其它事项外，使被提供的用户设备110、110'在本文描述的情况和条件下生成和显示交互的“用您的银行支付”图形设备1406。商家应用程序114设置为与通用钱包SDK/API116和商家的POS、mPOS以及网站系统132、134、136、136'联合操作，以方便如本文所述的用户购物过程。

在许多情况下，过程1502、1504可以通过访问与银行或其他FSP相关的服务器120、160并输入合适的标识符和数据，以手动或半自动的方式完成。在这种情况下，商家系统136、136'可以被提供公共和/或私人安全密钥，用于生成SDK/API 116并将其提供给用户设备110、110'。

如上所述，在1508处，被注册/被认证的商家系统136'可由认证/注册平台120提供包括适当调整的认证/注册标识符的认证数据集，以用于提供给商家和与商家相关的FI和/或FSP、设备110、110'的用户190和/或可信平台120。

在1510处，移动或非移动请求通信设备110、110'的用户190使用商家应用程序114在商家网站和/或实体店购物，通过使用所提供的商家应用程序114来组合一个交易授权请求数据集，该交易授权请求数据集包括表示要购买、租赁等的一个或多个项目和/或服务的数据。当准备结账(即，完成交易)时，用户190可以通过向商家应用程序114适当输入来发起结账过程，由此导致用户通过他/她的设备110、110'被显示如图14A所示的结账GUI 1402，该结账GUI 1402可以例如包括由交易授权请求数据集表示的所有或部分信息，如要购买的项目的列表、价格、税费、发运/快递信息等，以及一个或多个可选择的或以其他方式可交互的项目1404、1406。

如本文所述，在1512处，用户190可以选择“用您的银行支付”项目1406，从而通过通用钱包API 116调用或发起处理，如本文所述，这反过来导致默认或其他被选择的指定成为用于支付的一个或多个支付资金或价值来源(“支付资源”)。对于与被指定的支付资源相关的每个FI/FSP 120、160来说，SDK/API 116可以在1516处导致与所提出的交易有关的信息，例如购买价格或其中的部分由指定的支付资源支付，以及可选地，导致购买价格小计、适用的税金、运输成本和项目标识符等(例如，包括在所生成的交易请求数据集中一些或全部数据)，作为交易授权数据集的一部分被转发到相应的FI或FSP 120、160。或者，如在1518处所示，关于来自可信请求通信设备110'的交易授权请求，用于生成交易授权请求数据集的一些或所有数据项可以由FI或FSP 120、160通过使用与用户190相关的数据和/或指定的交易资金账户来提供。作为另一个选项，用户190和/或用户设备110、110'能够提供存储在与用户相关的用户配置文件中的信息以供将来使用，和/或更新特定的数据项。如在1520处所示，如本文所述，这种自动化的数据集合和/或配置文件更新过程可以通过用户登录、使用密码/PIN输入、设备连通、生物过程等来保护。

仍在1512处，FI 120、160可以与相应商家共享在1516处接收、生成和/或更新的“购物车”(即，交易授权请求数据集)信息中的一些或全部，用于验证过程等。

在1524处，SDK/API 116可以导致交易授权请求数据集，响应于使用指定资金来支付的交易价格的全部或部分购买金额，以安全的方式转发到负责支付资源账户的FSP 120、160。在由负责的FI/FSP 120、160验证，指定的支付账户内就有足够的资金或信贷等可用的条件下；FI/FSP可以生成(安全)交易授权数据集返回至SDK/API 116。这种优选为安全的交易授权数据集可以包括由商家136、136'和/或负责管理商家收据账户的FI/FSP可接受的任何数据，以用于确认该支付被授权。这种信息可以，例如包括任何或全部安全支付令牌、安全支付令牌编号、FI内支付确认(对于“由我们支付(on-us)”交易)或作为指令的结算确认。

因此，在1526处，一个被验证的交易支付数据集，包括例如被授权的支付金额和可选地，与注册商家136,136'相关的标识符可以被生成，并且在1528处，在1524处生成的被验证的交易数据集可以通过SDK/API 116返回至设备110、110'，并由SDK/API 116转发给商家应用程序114，并然后在1530处转发给商家系统136、136'，以用于在1540处的解密和/或其他处理，包括申请交易；并且在1542处，商家系统136、136'可以将订单确认数据集返回至商家应用程序114，以用于通过设备上存储的输出显示设备610或其他过程显示给用户。

在过程1500的一些实施例中，如图14E所示并如上所述，在1512-1514处，商家应用程序114可以向用户190显示各种支付选项。

在如图14C和14D所示并如上下文所描述的相同和其它实施例中，可以向用户190显示交互式GUI 1407，其使得用户能够使用多个支付来源来指定、选择和控制支付。

图15B示出了如图15A所示的过程1500的变体1500'。在如图15B所示的实施例中，过程1500、1500'以与图15A中大致相似的方式被进行，除了生成和显示GUI 1407的包括步骤1514A和1514B的过程1514由SDK/API 116而不是商业应用程序114执行，，该GUI 1407显示了可用于用户的多个支付选项1486。如在图15A中在1514C处进一步地示出，表示多个可用支付选项的数据可以安全存储在可信服务器120、161中，并通过SDK/API 116提供给设备110、110'。

在由如本文所描述的方法1300授予的许多优点和/或优势中，有移动设备的用户可以直接从商家应用程序内发起交易，而不必为每笔被发起的交易输入或重新输入敏感的个人信息。相当于商家应用程序可以通过使用凭证和程序接口从钱包应用程序中提取支付凭证。此外，由于商家应用程序提取了提供给移动钱包的HCE令牌而不是实际的账号或其他敏感信息，因此移动交易无需与支付网络内的商家或其他可能不安全的实体共享这种敏感信息就可以被处理。移动支付的其他方法可能无法共享所述实施例的这些和其他特征。

因此，如图17A-17C所示例性地示出，在各个方面和实施例中，本发明提供了设置为处理兼容HCE的支付令牌和凭证的系统100。

在如图17A所示的实施例中，示出了由支付选项应用程序116A实现的过程，该支付选项应用程序116A设置为与用户设备(例如，交易请求通信设备)110、110'上的商家应用程序114合作。设备110、110'包括至少一个输出显示设备610；至少一个用户输入设备610；至少一个网络通信系统612、614、616；至少一个数据处理器602；和至少一个持续内存设备604、608、618。所述至少一个持续内存设备604、608、618包括被存储的数据，该数据至少代表：至少一个安全支付令牌，所述至少一个安全支付令牌包括与一个被授权的支付金额和一个被授权的支付金额经其授权的金融服务提供商120、160相关的数据；以及一组或多组机器可读的指令。所述至少一个数据处理器602通过执行一组或多组被存储的机器可读指令来适用于，响应于由所述至少一个用户输入设备610生成的第一组信号，发起由(即，调用)商家交易应用程序141进行的处理，该商家交易应用程序与商家136、136'相关，并且包括存储在交易请求通信设备110、110'的所述至少一个持续内存设备604、608、618中的一组或多组机器可读指令；根据由所述商家交易应用程序114包含的所述机器可读指令和由所述至少一个用户输入设备610生成的至少第二组信号，生成一个被请求的交易数据集，所述被请求的交易数据集包括至少一个与商家136相关的标识符以及应付给商家的交易金额；并且导致所述至少一个输出显示屏610显示一个适用于征求商家结账过程和虚拟钱包应用程序支付过程的用户选择的人类可读的用户界面1407；所述虚拟钱包应用程序过程与虚拟钱包应用程序112相关，所述虚拟钱包应用程序包括一组或多组机器可读指令和所述至少一个安全支付令牌；响应于从所述至少一个用户输入设备610接收的第三组信号，所述第二组信号表示虚拟钱包应用程序支付处理的用户选择，导致商家交易应用程序114轮询对应的虚拟钱包应用程序并获取与所述至少一个安全支付令牌相关的支付凭证并且生成一个交易授权请求数据集，所述交易授权请求数据集至少包括所述支付凭证、与所述商家相关的标识符以及应付给所述商家的交易金额；以及，通过使用所述至少一个网络通信系统612、614、616将所述交易授权请求数据集路由到与支付资源来源相关的服务器120、160，其中支付资源来源与所述支付凭证相关。

在如图17B所示的实施例中，示出了由与第一FI/FSP120、160相关的虚拟钱包112、116B实现的过程，其设置为与与一个第二FI/FSP 120相关，不是通常由用户设备(即，交易请求通信设备)110、110'上的第二FI/FSP120控制或以其他方式与其相关的虚拟钱包应用程序112协作。设备110、110'包括至少一个用户输入和/或输出设备610；至少一个网络通信系统612、614、616；至少一个数据处理器602；以及至少一个持续内存设备604、608、618。所述至少一个持续内存设备604、608、618包括被存储的数据，该数据至少代表：多个安全支付令牌编号，每个安全支付令牌编号包括表示与多个交易支付资源来源中的一个相关的标识符的数据；以及一组或多组机器可读的指令。所述至少一个数据处理器602通过执行一组或多组被存储的机器可读指令来适用于：响应于由所述至少一个用户输入设备610生成的第一组信号，发起(即，“调用”)由支付交易处理进行的操作执行，所述支付交易处理生成一个被请求的交易数据集，所述被请求的交易数据集包括至少一个与商家相关的标识符以及一个应付给所述商家的交易金额；响应于由所述至少一个用户输入设备610生成的第二组信号，启动第一钱包应用程序112、116B，所述第一钱包应用程序112、116B至少包括多个安全支付令牌编号中的第一个，以及被存储的机器可读指令，其设置为：导致所述至少一个输出显示屏610显示人类可读的用户界面1407，该用户界面1407适用于征求用户选择多个支付资源来源中的一个以用于满足所请求的交易，至少一个所述支付资源来源与由所述多个安全支付令牌中的第一个识别的支付资源来源相关，并且至少第二个所述支付资源来源与由多个安全支付令牌中的第一个识别的的支付资源来源不相关；从所述至少一个用户输入设备610接收表示用户选择所述多个支付资源来源中的一个以用于满足相关交易的信号；并且如果所述用户选择的所述多个支付资源来源中的一个对应于由所述多个安全支付令牌中的第一个识别的所述支付资源来源，则生成一个交易授权请求数据集，该交易授权请求数据集至少包括所述多个安全支付令牌编号中的第一个，并且，通过使用所述至少一个网络通信系统，将所述交易授权请求数据集路由至与由所述多个安全支付令牌中的第一个识别的所述支付资源来源相关的一个服务器120、160。如果所述用户选择的多个支付资源来源中的一个不对应于由所述安全支付令牌中的第一个识别的所述支付资源来源，则网络请求通信设备110、110’可以进一步设置为发起一个第二钱包应用程序112，所述第二钱包应用程序112包括多个安全支付令牌编号中的至少第二个以及被存储的机器可读指令，该机器可读指令设置为使同一个或另一个数据处理器602生成一个交易授权请求数据集，该交易授权请求数据集包括所述多个安全支付令牌编号中的至少第二个，并且通过使用所述至少一个网络通信系统将由第一和第二钱包应用程序的任一生成的一个交易授权请求数据集路由到一个与所述商家相关的交易处理系统。

在如图17C所示的实施例中，示出了由网络请求通信设备110、110'的通用(或“公共”)虚拟钱包112、116C来实现的过程，其设置为与虚拟钱包应用程序112和/或与多个FI/FSP120、160相关的FI/FSP服务器120、160协作。设备110、110'包括至少一个用户输入和/或输出设备610；至少一个网络通信系统612、614、616；至少一个数据处理器602；以及至少一个持续内存设备604、608、618。所述至少一个持续内存设备604、608、618包括被存储的数据，该数据至少代表：多个安全支付令牌编号，每个安全支付令牌编号包括表示与交易支付资源的多个来源120、160中的一个相关的标识符的数据以及与所述交易支付资源来源唯一相关的安全密钥；以及一组或多组机器可读指令。所述至少一个数据处理器602通过执行一组或多组被存储的机器可读指令来适用于：响应于由所述至少一个用户输入设备610生成的第一组信号，发起支付交易处理的执行或“调用”支付交易处理，所述支付交易处理生成一个被请求的交易数据集，所述被请求的交易数据集包括至少一个与商家136,136'相关的标识符和一个应付给商家的交易金额；响应于由所述至少一个用户输入设备610生成的第二组信号，启动一个通用(或“公共”)钱包应用程序112、116C，所述通用钱包应用程序116C包括设置为生成交易授权请求数据集的被存储的机器可读指令，每个交易授权请求数据集包括至少一个安全支付令牌编号，和至少一个交易支付金额；并且响应于由所述至少一个用户输入设备610生成的第三组信号，所述第三组信号表示识别所述多个交易支付资源来源中的一个的至少一个用户选择，生成一个交易授权请求数据集，所述生成的交易授权请求数据集包括与所选的交易支付资源来源相关的至少一个安全支付令牌编号和应付给商家136的交易金额；并且通过使用所述至少一个网络通信系统610、612、614、616将生成的交易授权数据集路由到与所识别的支付资源来源相关的服务器120、160。

在根据图17C的一些实施例中，交易授权请求数据集的生成和路由是以所述至少一个数据处理器接收由所述至少一个用户输入设备生成的第四组信号为条件的，所述第四组信号至少包括与设备的授权用户相关的至少一个安全标识符。

在根据图17C的一些实施例中，通过执行相同或其他组的被存储的机器可读指令，数据处理器602适用于：通过使用同一个或另一个网络通信系统610、612、614、616从同一个或另一个与识别的支付资源来源相关的服务器120接收一个安全交易授权数据集；并且通过使用同一个或另一个所述至少一个通信系统610、612、614、616将所述安全交易授权数据集路由到与商家相关的交易处理系统136、136'。

在如图17A-17C所示的任一个实施例中被处理的支付资源，同由本文描述的其他实施例处理的那些一样，可以包括实际或虚拟货币的任何形式的，或可兑换的忠诚度或奖励积分的任一或两者的资源。

由本发明的这些方面和实施例提供的其他优点包括发行方FI/FSP、商家等提供给用户190对支付选项的简化的访问以及统一的“客户体验”的能力，该统一的“客户体验”横跨包括移动和桌面设备等的各种平台并且在由商家、FI、FSP等定义的横跨大范围的环境的购买和其他交易期间。在一些实施例中，设备110、110'的用户190可以根据她/他的偏好定制所有或部分体验。如前所述，客户体验可以横跨传统边界，如由商家、FI、FSP等偏好的支付方式来扩展。

上文描述旨在提供对一个或多个发明的各个方面和示例性实施例的全面的描述。因此，这些发明的各个方面和/或组件已经在多个不同的抽象层次上进行了全面描述。在一些情况下，实施例可以在一个特定的和一个相对通用或通用的级别上进行描述，例如，其中实施例的方面或组件可能以不同于所提出的特定结构和/或操作的方式发生变化。在这些情况下，本文中提出的具体实施方案可能不是唯一的预期的实施方案，而是可以仅进是更一般或通用配置的示例。因此，适当考虑到为了解释其意义的适用原则，本文所描述的本发明的范围仅仅由这里的从属权利要求的语言来来限定。

Claims

1.一种网络交易通信设备，包括：

至少一个用户输入设备；

至少一个网络通信系统；

至少一个数据处理器；以及

至少一个持续内存设备，所述至少一个持续内存设备包括被存储的数据，该数据至少表示：

多个安全支付令牌，每个安全支付令牌包括表示与多个交易支付资源来源中的一个相关的标识符的数据和与所述交易支付资源来源唯一相关的安全密钥；以及

一组或多组机器可读的指令；

所述至少一个数据处理器通过执行所述一组或多组被存储的机器可读的指令，来适用于：

响应于由所述至少一个用户输入设备生成的第一组信号，发起支付交易处理，所述支付交易处理生成被请求的交易数据集，所述被请求的交易数据集包括与商家相关的至少一个标识符以及应付给商家的交易金额；

响应于由所述至少一个用户输入设备生成的第二组信号，启动通用钱包应用程序，所述通用钱包应用程序包括设置为生成交易授权请求数据集的被存储的机器可读指令，每个交易授权请求数据集包括至少一个安全支付令牌和至少一个交易支付金额；以及

响应于由所述至少一个用户输入设备生成的第三组信号，所述第三组信号表示识别所述多个交易支付资源来源中的一个的至少一个用户选择，生成交易授权请求数据集，所述生成的交易授权请求数据集包括与所选择的交易支付资源来源相关的至少一个安全支付令牌和应付给商家的交易金额；以及

通过使用所述至少一个网络通信系统，将生成的交易授权数据集路由到与所识别的支付资源来源相关的服务器。

2.根据权利要求1所述的网络交易通信设备，其特征在于，所述交易授权请求数据集的生成和路由是以所述至少一个数据处理器接收到所述至少一个用户输入设备生成的第四组信号为条件的，所述第四组信号包括与设备的授权用户相关的至少一个安全标识符。

3.根据权利要求1所述的网络交易通信设备，其特征在于，所述至少一个数据处理器通过执行所述相同或其他组的被存储的机器可读指令来适用于：

通过使用同一个或另一个网络通信系统，从与所识别的支付资源来源相关的同一个或另一个服务器接收安全交易授权数据集；以及

通过使用所述至少一个通信系统中的同一个或另一个，将所述安全交易授权数据集路由到与所述商家相关的交易处理系统。

4.根据权利要求1所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示货币。

5.根据权利要求1所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示非货币的可兑换积分。

6.一种网络交易通信设备，包括：

至少一个输出显示设备；

至少一个用户输入设备；

至少一个网络通信系统；

至少一个数据处理器；以及

至少一个持续内存储设备，所述至少一个持续内存设备包括被存储的数据，该数据至少表示：

多个安全支付令牌，每个安全支付令牌包括表示与多个交易支付资源来源中的一个相关的标识符的数据；以及

一组或多组机器可读的指令；

所述至少一个数据处理器通过执行所述一组或多组被存储的机器可读指令来适用于：

响应于由所述至少一个用户输入设备生成的第一组信号，发起支付交易处理，所述支付交易处理生成被请求的交易数据集，所述被请求的交易数据集包括至少一个与商家相关的标识符以及应付给商家的交易金额；

响应于由所述至少一个用户输入设备生成的第二组信号，启动第一钱包应用程序，所述第一钱包应用程序包括所述多个安全支付令牌中的至少第一个，以及被存储的机器可读指令，该机器可读指令设置为：

导致所述至少一个输出显示屏显示人类可读的用户界面，该界面适用于征求用户选择多个支付资源来源中的一个以用于满足被请求的交易，至少一个支付资源来源与由多个安全支付令牌中的第一个识别的支付资源来源相关，以及至少第二个支付资源来源与由多个安全支付令牌中的第一个识别的支付资源来源不相关；

从所述至少一个用户输入设备接收表示用户选择的所述多个支付资源来源中的一个以用于满足相关交易的信号；以及

如果用户选择的多个支付资源中的一个对应于由多个安全支付令牌中的第一个识别的支付资源来源，则生成交易授权请求数据集，该交易授权请求数据集至少包括所述多个安全支付令牌中的第一个，并将所述交易授权请求数据集路由到与由所述多个安全支付令牌中的第一个识别的所述支付资源来源相关的服务器。

7.根据权利要求6所述的网络交易通信设备，其特征在于，所述至少一个数据处理器通过执行所述相同或其他组的被存储的机器可读指令来适用于：

如果用户选择的多个支付资源来源中的一个不对应于由所述多个安全支付令牌中的第一个标别的所述支付资源来源，则启动第二钱包应用程序，所述第二钱包应用程序包括所述多个安全支付令牌中的至少第二个和被存储的机器可读指令，该机器可读指令设置为使得同一个或另一个数据处理器生成包括所述多个安全支付令牌中的至少第二个的交易授权请求数据集。

8.根据权利要求6所述的网络交易通信设备，其特征在于，所述至少一个数据处理器通过执行所述相同或其他组的被存储的机器可读指令来适用于：

通过使用至少一个网络通信系统，将由第一或第二钱包应用程序生成的交易授权请求数据集路由到与商家相关的交易处理系统。

9.根据权利要求6所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示货币。

10.根据权利要求6所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示非货币的可兑换积分。

11.一种网络交易通信设备，包括：

至少一个输出显示设备；

至少一个用户输入设备；

至少一个网络通信系统；

至少一个数据处理器；以及

至少一个安全支付令牌，所述至少一个安全支付令牌包括与被授权的支付金额相关的数据和被授权的支付金额经其授权的金融服务提供商；以及

一组或多组机器可读的指令；

所述至少一个数据处理器通过执行所述一组或多组存储的机器可读指令，来适用于：

响应于由所述至少一个用户输入设备生成的第一组信号，启动商家交易应用程序，该商家交易应用程序与商家相关并且包括存储在所述交易请求通信设备中所述至少一个持续内存设备中的一组或多组机器可读指令，

根据由所述商家交易应用程序包括的所述机器可读指令以及由所述至少一个用户输入设备生成的至少第二组信号，生成被请求的交易数据集，所述被请求的交易数据集包括至少一个与商家相关的标识符以及应付给商家的交易金额；并且导致所述至少一个输出显示屏显示适用于征求商家结账过程和虚拟钱包应用程序的用户选择的人为可读的用户界面；所述虚拟钱包应用程序处理与虚拟钱包应用程序相关，所述虚拟钱包应用程序包括一组或多组机器可读指令以及所述至少一个安全支付令牌；

响应于从所述至少一个用户输入设备接收到的第三组信号，所述第二组信号表示用户选择的虚拟钱包应用程序支付处理，使得商家交易应用程序轮询对应的虚拟钱包应用程序并获取与所述至少一个安全支付令牌相关的支付凭证并生成交易授权请求数据集，所述交易授权请求数据集包括至少所述支付凭证、与所述商家相关的所述标识符以及应付给所述商家的交易金额；以及

将所述交易授权请求数据集路由到与支付资源来源相关的服务器，其中支付资源来源与支付凭证相关。

12.根据权利要求11所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示货币。

13.根据权利要求11所述的网络交易通信设备，其特征在于，所述交易支付资源的至少一部分表示非货币可兑换积点。

14.一种交易请求通信装置，包括：

至少一个输出显示设备；

至少一个用户输入设备；

至少一个网络通信系统；

至少一个数据处理器；以及

至少一个持续内存设备，所述至少一个持续内存储设备包括被存储的数据，该数据至少表示：

至少一个安全支付令牌，所述至少一个安全支付令牌包括与授权支付金额相关的数据和授权支付金额的经其授权的金融服务提供商；以及

一组或多组机器可读的指令；

所述至少一个数据处理器通过执行所述一组或多组存储的机器可读指令来适用于：

响应于由所述至少一个用户输入设备生成的第一组信号，启动商家交易应用程序，其与商家相关并且包括存储在所述交易请求通信设备中所述至少一个持续内存设备中的一组或多组机器可读指令，

根据所述商家交易应用程序包括的所述机器可读指令以及由所述至少一个用户输入设备生成的至少第二组信号，生成请求的交易数据集，所述请求的交易数据集包括与商家相关的至少一个标识符以及应付给商家的交易金额；并且使得所述至少一个输出显示屏显示适用于征求商家结账过程和虚拟钱包应用程序的用户选择的人为可读的用户界面；所述虚拟钱包应用程序过程与虚拟钱包应用程序相关，所述虚拟钱包应用程序包括一组或多组机器可读指令以及所述至少一个安全支付令牌；

响应于从所述至少一个用户输入设备接收到的第三组信号，其中所述第二组信号表示用户选择的虚拟钱包应用程序支付处理，使得商家交易应用程序轮询相应的虚拟钱包应用程序并获取与所述至少一个安全支付令牌相关的支付凭证并生成交易授权请求数据集，所述交易授权请求数据集至少包括所述支付凭证、与所述商家相关的所述标识符以及应付给所述商家的交易金额；以及

将所述交易授权请求数据集路由到与支付资金来源相关的服务器，其中支付资金来源与所述支付凭证相关。

15.根据权利要求14所述的交易请求通信设备，其特征在于，所述设备、所述与支付资金来源相关的服务器以及所述商家已经相互接受了可信网络通信协议，其中支付资金来源与所述支付凭证相关。