CN110023977A - 令牌创建和提供 - Google Patents

Abstract

商家通过为当前未在钱包平台注册的消费者请求钱包账户将消费者账户数据转换为共同令牌化格式。令牌化卡号替换商家存储的个人账户号码（PAN）且允许商家使用共同通信格式用于处理所有交易。当消费者创建新钱包账户时，现有的‘影子’账户被添加到所述新钱包账户。

Description

令牌创建和提供

相关申请交叉引用

本PCT国际申请要求2016年10月28日申请的第15/337,921号美国非临时专利申请的优先权，所述美国非临时专利申请的公开内容以全文引用的方式并入本文中。

技术领域

背景技术

本文中提供的背景描述是出于大体上呈现本公开的上下文的目的。在此背景技术部分中所描述的程度上，当前署名的发明人的工作以及在提交时可能不另外作为现有技术的本说明书的各方面既不明确地也不隐含地被承认为本公开的现有技术。

商家存储的关于消费者的信息是基于获得信息的时间和方法而变化。即，在商店内或通过电话接收的消费者信息可不同于通过在线交易或当使用钱包服务时接收的消费者信息。消费者信息的这种变化使商家即使当与例如购方或发行方等同一实体通信时也基于数据类型维持不同的通信接口。

发明内容

本发明内容和以下具体实施方式描述的特征和优点并非是包含一切的。根据附图、说明书和权利要求书，许多附加的特征和优点对于本领域的普通技术人员将是显而易见的。此外，其它实施例可以省略本发明内容中描述的特征和优点中的一个或多个（或全部）。

在一些实施例中，商家的包含个人账户号码和相关信息的消费者数据在钱包平台处被转换成令牌格式，且创建“客人”钱包账户。钱包平台将包含令牌化账户信息的富集有效负载返回到商家。商家可以随后删除消费者的个人账户信息以有利于更安全的令牌化信息。此外，商家可以使用单个接口通信，因为所有消费者数据是以共同格式存储的。当消费者直接在钱包平台上创建钱包账户时，客人钱包账户自动纳入到消费者钱包中。

附图说明

图1示出根据本公开的用于令牌创建和提供的系统元件的框图；

图2是示出商家批量令牌化中的有效元件的框图；

图3是示出发行方推送令牌化中的有效元件的框图；

图4是根据本公开的钱包平台的组件的框图；以及

图5是令牌创建和提供的方法的流程图。

仅出于说明的目的，图式描绘各种实施例。本领域技术人员可以从下面的讨论中容易地认识到，在不脱离本文描述的原理的情况下，可以采用在本文中示出的结构和方法的替代实施例。

具体实施方式

图1大体上示出用于令牌创建和提供的系统100的一个实施例。在各种实施例中，所述系统可包含商家102、钱包平台104、令牌服务提供商106，以及一个或多个发行方108、110。在其它实施例中，系统100可以仅包含钱包平台104，其中商家102、令牌服务提供商106和发行方108、110与系统100通信但不是系统100的部分。

在所说明的实施例中，发行方108具有账户A 112和账户B 114，而发行方110具有账户C 116和账户D 118。出于说明起见，这些账户将在本公开中称为信用卡账户，但这些教示适用于依赖于个人可识别信息的其它种类的账户，包含但不限于借记卡、礼品卡、忠诚计划、经济账户或退休账户。账户112、114、116、118中的每一个包含个人账户号码（personalaccount number，PAN），在此实施例中，可以是压印在消费者信用卡的表面上的信用卡号。

商家102可以在商家网站上存储消费者相应的账户信息，以用于经常性交易或用于其消费者在进行常规购买时的便利性，经常被称为存档卡交易。在图1中，用消费者账户信息Apan 112'、Bpan 114'和Cpan 116'描绘此信息。账户D的商家信息可以存储为基于令牌的格式Dtok 134，其可尤其包含PAN的令牌化表示以及用以识别商家102与钱包平台104之间的交易的CallID。令牌134可以由钱包平台104响应于来自消费者在钱包平台104登记时的请求而代表消费者发出。在消费者在商家102使用他或她的钱包账户126的后续交易中，商家102可以将先前存储的令牌134（或CallID）提供到钱包平台104，以便最终完成从D的信用卡账户118的支付。

令牌134在安全漏洞的情况下为消费者和商家102两者提供额外安全性，因为令牌在商家102外部的价值有限，这尤其是归因于在钱包平台104执行的交易的额外验证以及用于仅在使用钱包平台104的商家102之间的交易的令牌134的有限范围。出于至少此原因，当存储令牌而不是PAN时对商家存在价值。

令牌134和具有PAN 112'、114'、116'的账户的存储和使用对于商家102具有另一不合意的副作用。如图1所示，商家102可以使用令牌定向的应用程序接口（API）140与钱包平台104通信。然而，当与购方142、不同发行方108、110通信时或甚至在商家102基于例如经由电话和经由网络等交易来源而使用不同协议与一个购方142通信的情况下，商家102还可能需要支持各种卡特定的接口，例如API 141。影响则是商家102必须基于支付工具的性质、信用卡的类型或获取信用卡数据的方式而维持多个接口。

商家批量令牌化使用情况

为了解决安全性问题和维持多个API的问题两者，钱包平台104可以暴露API 140，这允许商家102请求将具有PAN 112'、114'和116'的消费者账户转换为“客人”或“影子”钱包账户120、122、124。还参考图2，商家102可以连同PAN一起提供（“1”）商家102为相应消费者存档的额外信息，例如消费者收货地址、电子邮件等。钱包平台104从令牌服务提供商106请求和接收（“2”）令牌化卡号，且使用此信息以产生（“3”）钱包平台客人账户120、122、124。

理论上，商家102可以从令牌服务提供商106直接请求令牌化卡号，但存在防止此情况的实际考虑。为了让商家102做出此请求，商家102将必须变为“令牌请求者”。然而，当用于令牌服务的标准主体（EMV CO）建立用于令牌服务的架构时，令牌请求者的数目受到为令牌请求者指派的数目空间的限制。虽然数目是相对大的，但数目空间未大到足以让全世界成千上万或数百万的商家被认证为令牌请求者。每个商家102也不一定希望通过审查过程且纳入与变成令牌请求者相关联的安全和操作策略。

返回到图1和2，已经从令牌服务提供商106接收令牌化卡号的钱包平台104可以随后将增强型有效负载144返回（“4”）到商家102，所述增强型有效负载在一些实施例中可含有CallID、令牌化卡号、支付账户参考（payment account reference，PAR）和卡元数据。卡元数据可包含用于当做出购买时向消费者显示的卡作品、忠诚度数据或与卡相关联的其它链接优惠。CallID是可以限于特定商家和消费者的可扩展对象，且还可以具有从单次使用到几个月或更久的期满时间。商家102可以随后产生本地基于令牌的账户128、130、132，随后安全地安置（“5”）基于PAN的消费者信息112'、114'和116'。在数据漏洞的情况下商家的责任显著减少，因为商家102不再具有有效卡号，而是具有基于CallID的账户参考和/或令牌化基于卡的账户参考。

此时，商家102现在具有客人钱包账户，商家102可以当处理用于消费者的交易时代表消费者使用所述客人钱包账户。举例来说，如果消费者“A”在商家102的网站购买产品且消费者选择使用以“1234”结束的存档卡，那么商家102可以使用来自增强型账户数据128的对应于以“1234”结束的原始存储卡的令牌化卡号（或CallID）来处理交易。消费者不一定知道客人账户120存在。然而，既然所有其消费者支付信息处于令牌化格式，则商家102现在可以标准化其接口代码以使用API 140（或等效物）用于每个交易。

发行方推送令牌化

在另一实施例中，发行方108可以与商家102协同行动以为消费者呈现优惠以产生影子或客人钱包账户120。在图3中说明的此情境下，消费者可以在正常商业过程中与发行方108在线。举例来说，消费者可以与发行方在线以检查当前余额或做出支付。发行方108可能希望通过启用共同API 140的使用而简化与商家102的交互，但不希望一定强制消费者登记获得通用钱包。

类似地，商家102可能希望转变到共同交互格式以用于交易处理，且不希望执行上文所论述的批量令牌化或者具有希望消费者的至少某种水平的参与的另一原因。并且，如同发行方108，商家102可能不希望强制消费者选择特定钱包平台且注册通用钱包。在此情况下，发行方108可以向消费者呈现（“1”）优惠148以允许将保持在商家102处的他或她的信用卡账户转换为基于令牌的账户。由商家102最终做出的优惠甚至可以包含例如购物折扣或返现金奖励等激励。

当消费者批准优惠时，发行方108可以使用例如API 143以发行方标准格式将消费者/持卡人账户信息112或其相关部分传递（“2”）到钱包平台104。发行方108还可以将网络会话信息传递（“2A”）到钱包平台104以便后续使用。钱包平台104可以解密和剖析来自发行方108的有效负载，且与令牌服务提供商106通信（“3”）以产生令牌化卡号。钱包平台104可以产生（“4”）包含令牌化卡号和/或商家CallID的限制使用客人账户120。钱包平台104可以准备有效负载144，其包含CallID、令牌化卡和所需要且可用的其它账户信息。有效负载144可以用商家的预先确立的秘密密钥加密。

钱包平台104通过网络重定向和投递消息或其它机制将消费者重定向（“5A”）到商家102且传递CallID作为参数。使用CallID，商家102可以调用标准钱包API以从钱包平台104检索（“5”）加密的账户有效负载且使用商家的秘密密钥将有效负载解密。使用有效负载信息，商家102可以用CallID、令牌化卡信息等更新消费者账户，且随后移除（“6”）PAN和相关信息112'。一旦提取剩余账户细节，商家102就可以经由网络会话与消费者交互（“7”），包含在发行方站点兑换对消费者作出的任何原始优惠148

消费者可以通过上文描述的过程中的任一个而具有随着时间代表他或她产生的许多客人账户。多个商家可以将本地PAN数据112'转换为令牌化格式，从而在钱包平台104为每一商家创建单独的个别客人钱包。多个发行方108、110可以代表相同或不同商家推送激活客人钱包账户。

这些客人账户120、122、124对于消费者来说可以基于他或她的接入点来进行接入。举例来说，钱包平台104可以暴露API，所述API允许发行方108请求与特定个人账户号码（PAN）相关联的所有账户的信息。当与PAN相关联的消费者在发行方108的网站上时，消费者可以看见关于那些客人或影子账户的信息。在一实施例中，消费者也可以能够通过发行方108检索关于由消费者显式地设置的标准钱包账户的信息。

在商家102的网站上交互的消费者可能够查看关于令牌化账户128的信息。举例来说，消费者可能够接入特殊优惠和忠诚度奖励，或经由商家102更新与账户有关的个人信息。

如下文更多论述，如果消费者例如在创建钱包账户之后接入钱包平台104，那么消费者可以获得对所有他或她的钱包账户的可见性，无论是由消费者创建还是由商家102或发行方108代表他或她创建。这些账户将包含用于所有发行方的账户、用于所有商家的账户，以及由消费者保持在钱包平台的用户发起的账户。

消费者发起的账户合并

消费者可以在某一点在钱包平台104上创建钱包账户126。此时，钱包平台104通过其对可能存在的联系到消费者身份或者一个或多个PAN号码的单独客人账户的知晓，可以随后在某一水平的身份检验之后将来自代表消费者创建的客人账户的信息添加到新创建的钱包账户126。即，作为客人账户存储在钱包平台104处的标商家商标的卡和标发行方商标的卡可以随后传送到消费者的常规账户。在此转换之后，消费者可以随后查看和管理所有账户而不考虑它们是由消费者直接建立还是由另一方代表消费者建立。在‘客人’或影子账户旨在仅专用于建立账户的商家的情况下，在一实施例中，在客人钱包账户数据传送到完整消费者钱包之后，与相客人钱包账户关联的信用卡（或其它类型的金融工具）可以在由钱包平台104支持的任何设定中使用，例如在另一商家处。

图4是钱包平台104的一个实施例的简化框图。钱包平台104可包含处理器160和存储器162。存储器162可以是包含多种类型的物理易失性和非易失性存储器的物理存储器，但其可以不包含载波或传播介质。存储器162可包含消费者账户164和客人账户166两者，其中消费者账户是由消费者显式地请求且含有由消费者输入的信息的账户。客人账户166可以是并非由消费者发起而是由另一方代表有名或匿名消费者请求的账户。客人账户和消费者账户都可包含CallID 165、令牌化卡号167或这两者。

硬件安全模块（hardware security module，HSM）168可用以存储用于加密、解密和签署的密钥，包含与一个或多个商家102、发行方108、110和令牌服务提供商106共享的秘密密钥。HSM 168可能够存储和产生密钥，包括对称和不对称密钥两者。HSM 168还可以具有用于执行用于签署、签名检验、加密和解密的各种加密算法的硬件和软件，其中已知算法包含但不限于DES、TDES、AES、椭圆曲线和RSA。

在一实施例中，HSM 168可以对消费者账户164和客人账户166进行加密以使得即使它们存储于无保护的存储器162中，数据当存储时也被加密。用于本地数据加密的密钥可以在本地产生和使用，以使得在装置外复制用于账户164、166的数据将没有价值，因为存储于HSM 168中的密钥将是不可接入的。在另一实施例中，HSM 168可以使用用于本地加密密钥的导出过程，以使得可以在灾难的情况下恢复消费者账户。HSM 168可以是特殊硬件元件，其包含防篡改、篡改检测、温度传感器、光传感器等以阻止和检测为了从装置提取密钥的目的而篡改HSM 168的努力。

网络接口174可用于与外部实体通信，包含但不限于商家102、令牌服务提供商106和发行方108、110。与网络接口174相关联的是可基于当前会话的性质而存在的各种接口。在一个例子中，消费者会话可以连接到支持例如网页等消费者接口176的代码，所述代码允许消费者创建、管理和引退尤其用于购买交易的钱包账户126。与例如商家102等商家的会话可以由商家API 140支持。商家API 140可以暴露允许商家请求客人账户的调用，如上文所论述。商家API 140还可以支持各种交易和维护调用，包含交易意图和生命周期更新，例如持卡人地址改变或卡期满时间。

图5是根据本公开的令牌创建和提供的一般化方法200的流程图。任选地，在框202处，钱包平台104可以暴露一个或多个应用程序接口（API）140、143以用于创建客人（影子）钱包账户120、122、124。API 140、143可以由商家102或发行方108使用以请求客人钱包账户的创建，请求关于客人钱包账户的信息，发送包含交易意图信息的交易信息，或发送和接收与客人钱包账户有关的生命周期数据。

在框204处，钱包平台104可以接收将消费者的个人账户号码（PAN）112'（例如存档卡数据）转换为具有可用的相关联账户信息的令牌化卡号的请求。在框206处可以例如借助于接收到请求的通道来确定请求的起源。在各种实施例中，请求可以经由API 143从发行方108接收，经由API 140从商家102接收，或经由网络通过直接消费者交互接收。

如果请求是来自发行方108，那么可以取从框206到框208的“发行方”分支，其中做出过程中是否涉及商家优惠的决策。如果是，那么取从框208的“是”分支到框210且可以向消费者呈现优惠148，且在框212处继续执行。如果在框208处，不涉及商家优惠，那么可以从框208到框212取“否”分支。返回到框206，如果请求的起源是来自商家102，那么在框212处执行继续。

如可见，用于创建客人钱包账户120的一般步骤对于执行到达框212的每一路径来说是相同或相似的。此处，钱包平台104可以接收大体上基于对请求者已知的PAN为特定消费者创建客人钱包账户120的请求，无论请求者是发行方108还是商家102。如上文所论述，钱包平台104从令牌服务提供商号码106请求令牌化卡号，且通过将数据添加到令牌化卡号而创建客人钱包账户120，所述数据例如从请求者接收的消费者信息和/或在钱包平台104产生的CallID。

在框216处，从钱包平台104将有效负载发送到商家102，所述有效负载含有至少CallID且还可以包含令牌化卡号。还如上文所论述，一旦经由发行方108接收到请求，就还可以将网络重定向会话从钱包平台104传递到商家102。在框218处，商家102可以使用从钱包平台104接收的与客人钱包账户120有关的CallID和任何其它信息以将消费者账户112'更新为基于令牌的账户128，确切地说，从其本地记录移除用于消费者A的PAN。

返回到框206，如果请求是在账户创建过程期间从消费者接收，那么执行可以在框220处继续。钱包平台104可以常规方式创建钱包账户。在框222处，钱包平台104可以经由个人可识别信息或与同一金融工具相关联的PAN来搜索与同一消费者相关联的客人钱包账户。如果不存在此类客人钱包账户，那么过程可以在框224处结束。如果客人钱包账户确实存在，那么执行可以在框226处继续，其中将客人钱包账户合并到消费者的新钱包账户中。

解决使用呈令牌化格式形式的技术解决方案来转换例如金融工具个人账户号码等个人信息的存档卡数据库的技术难题的能力有益于商家、发行方和消费者。消费者的信息受到保护以免于在可能不如其它位置那么安全的位置处的数据漏洞造成的泄密。举例来说，其中在上述过程中存储PAN信息的令牌服务提供商106没有面向消费者的接入，且可以通过面向供应商、消费者和雇员的接入点来维持与大型在线零售商相比显著更高安全性的资料档。

发行方108受益于经由钱包平台104的标准化接入，并且还受益于与失窃PAN数据相关联的风险降低。最后，商家还受益于消费者账户信息的保护以及对于每一不同类型的存档卡数据必须开发和维持的交易接口的数目的减少。

根据存储为机器存储器（例如，计算机存储器）内的位或二进制数字信号的数据上的操作的算法或符号表示而呈现本说明书的一些部分。这些算法或符号表示是数据处理领域的一般技术人员用来向本领域其它技术人员传达其工作的实质内容的技术的实例。如本文中所使用，“算法”是产生所需结果的操作或类似处理的自一致性序列。在此上下文中，算法和操作涉及对物理量的物理操纵。通常但不一定，此类量可以呈电、磁或光学信号的形式，所述电、磁或光学信号能够由机器存储、访问、传送、组合、比较或以其它方式控制。主要出于常用的原因，有时使用例如“数据”、“内容”、“位”、“值”、“元素”、“符号”、“字符”、“项”、“数目”、“数字”等词语来提及此类信号是很方便的。然而，这些词语仅为方便的标记并将与适当物理量相关联。

除非另外特别指出，否则本文中使用例如“处理”、“计算”、“运算”、“确定”、“呈现”、“显示”等词进行的讨论可以指机器（例如，计算机）的动作或过程，所述机器控制或转换表示为一个或多个存储器（例如，易失性存储器、非易失性存储器或其组合）、寄存器或者接收、存储、传输或显示信息的其它机器组件内的物理（例如，电、磁或光）量的数据。

如本文所使用，对“一些实施例”或“实施例”或“教示”的任何参考表示结合实施例所描述的特定元件、特征、结构或特性包含在至少一个实施例中。在本说明书的不同位置中出现短语“在一些实施例中”或“教示”未必都指同一个实施例。

此外，仅出于说明的目的，图式描绘优选实施例。本领域技术人员将从下面的讨论中容易地认识到，在不脱离本文描述的原理的情况下，可以采用在本文中示出的结构和方法的替代实施例

在阅读本公开后，本领域技术人员将通过本文公开的原理理解本文中描述的系统和方法的额外替代结构设计和功能设计。因此，虽然已经指令和描述了特定实施方案和应用，但是应所述理解，所公开的实施方案不限于在本文中公开的精确构造和组件。在不脱离任何所附权利要求限定的精神和范围的情况下，可以对本文公开的系统和方法的布置、操作和细节做出各种修改、改变和变化，这对于本领域技术人员而言是显而易见的。

Claims (20)

1.一种系统，包括：

网络接口，其发送和接收信息；

处理器和存储器，所述处理器和存储器执行致使所述系统进行以下操作的指令：

经由网络接口接收消费者个人账户号码，从与所述个人账户号码相关联的消费者之外接收所述消费者个人账户号码；

获得对应于所述消费者个人账户号码的令牌化卡号；

代表所述消费者创建客人钱包账户；

将所述客人钱包账户更新为包含所述令牌化卡号；

建置包含所述令牌化卡号的有效负载；以及

将所述有效负载发送到商家以由所述商家用于以来自所述有效负载的数据替换存储的消费者个人账户信息。

2.根据权利要求1所述的系统，其中所述指令还致使所述处理器和存储器将CallID指派给代表所述消费者创建的所述客人钱包账户，所述CallID将所述令牌化卡号绑定到所述商家。

3. 根据权利要求2所述的系统，还包括致使所述处理器进行以下操作的指令：

接收所述消费者针对新钱包账户的登记；以及

使代表所述消费者创建的所述客人钱包账户与所述新钱包账户关联。

4.根据权利要求1所述的系统，其中经由所述网络接口接收所述消费者个人账户号码包含从存储所述消费者个人账户号码的商家接收所述消费者个人账户号码。

5.根据权利要求1所述的系统，其中所执行指令致使所述系统经由所述网络接口从与所述消费者个人账户号码相关联的发行方接收所述消费者个人账户号码。

6.根据权利要求1所述的系统，其中所述有效负载还包含CallID，所述CallID绑定所述消费者和所述商家且充当用于由所述商家发送的对应于在所述商家处的消费者活动的数据的未来识别符。

7. 根据权利要求1所述的系统，其中所述系统在缺乏所述消费者的任何动作的情况下代表所述消费者创建所述客人钱包账户。

8.根据权利要求1所述的系统，其中获得所述令牌化卡号包括向令牌服务请求所述令牌化卡号；以及

从所述令牌服务接收所述令牌化卡号。

9.一种方法，包括：

在钱包平台处接收消费者个人账户号码；

在所述钱包平台处获得对应于所述消费者个人账户号码的令牌化卡号；

在所述钱包平台处代表与所述消费者个人账户号码相关联的消费者创建钱包账户，所述钱包账户包含所述令牌化卡号；

建置包含所述令牌化卡号的有效负载；以及

将包含所述令牌化卡号的所述有效负载发送到商家以允许所述商家替换在所述商家处的所述消费者个人账户号码的任何副本。

10.根据权利要求9所述的方法，其中接收所述消费者个人账户号码包括从商家接收所述消费者个人账户号码。

11.根据权利要求10所述的方法，其中从所述商家接收所述消费者个人账户号码包括在缺乏当前消费者交易的情况下将所述消费者个人账户号码发送到所述钱包平台。

12.根据权利要求9所述的方法，其中接收所述消费者个人账户号码包括从与所述个人账户号码相关联的发行方接收所述消费者个人账户号码。

13.根据权利要求9所述的方法，其中创建所述有效负载还包含以CallID和支付账户参考（PAR）创建所述有效负载。

14. 根据权利要求9所述的方法，其中在所述钱包平台处获得所述令牌化卡号包括：

向令牌服务请求所述令牌化卡号；以及

从所述令牌服务接收所述令牌化卡号。

15.一种方法，包括：

经由由钱包平台暴露的API接收来自消费者之外的请求以代表所述消费者创建客人钱包账户，所述请求包含所述消费者的个人账户号码；

在所述钱包平台处从令牌服务获得对应于所述个人账户号码的令牌化卡号；

代表所述消费者创建所述客人钱包账户；以及

经由所述钱包平台的API调用向与所述消费者相关联的商家发送有效负载，所述有效负载含有对应于代表所述消费者创建的所述客人钱包账户的客人钱包账户信息。

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

在所述钱包平台处接收来自所述消费者的创建新钱包账户的请求；

响应于来自所述消费者的所述请求而为所述消费者创建所述新钱包账户；以及

将代表所述消费者创建的所述客人钱包账户纳入到所述新钱包账户中。

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

接收来自所述消费者的针对所述客人钱包账户的状态的请求；以及

根据接收到所述请求所通过的通道来提供对应于所述客人钱包账户的信息。

18.根据权利要求17所述的方法，其中根据接收到所述请求所通过的所述通道来提供对应于所述客人钱包账户的信息包括针对通过所述商家接收的请求返回关于与所述商家相关联的客人账户的信息。

19.根据权利要求17所述的方法，其中根据接收到所述请求所通过的所述通道来提供对应于所述客人钱包账户的信息包括针对通过发行方接收的请求返回关于与持有用于来自所述发行方的PAN的令牌的商家相关联的所述消费者的所有客人账户的信息。

20.根据权利要求17所述的方法，其中根据接收到所述请求所通过的所述通道来提供对应于所述客人钱包账户的信息包括针对经由所述钱包平台接收的请求返回来自与任何商家相关联的所有发行方的PAN的信息。