CN108352010A - 用于管理认证服务客户数据的方法和系统 - Google Patents

Abstract

涉及平台的方法、介质和系统，所述平台用于：从认证系统的至少一个外部用户接收记录，所述记录包含用于所述外部用户并且与所述至少一个外部用户向所述认证系统的至少一个注册相关的客户信息；由与存储历史外部用户客户信息的认证数据库连接的计算机接收包含所述外部用户的客户信息的记录；验证包含所述外部用户的客户信息和所述历史外部用户客户信息的记录；并且存储所述验证的记录的指示。

Description

用于管理认证服务客户数据的方法和系统

相关专利申请的交叉引用

本申请要求于2015年9月17日提交的美国申请序列号14/857,406的申请日的优先权和权益，其全部内容通过引用并入本文中。

背景技术

历史上，在线购物环境和其他“无卡”交易中支付设备(诸如信用卡或借记卡以及与之相关的应用程序)的商家和发行方主要担心的是尝试使用支付设备的人是否是支付设备的授权用户。当持卡人不在场时，商家或其他实体可能难以认证或验证实际授权的持卡人是否确实授权购买，而不是欺诈活动类型的某种尝试。

为了减少在线购买和其他“无卡”交易中的支付设备欺诈的发生率，已经提出并使用多个系统来验证使用支付设备的人是支付设备的授权用户。在这方面，为在线信用和借记交易增加一层额外安全性而开发的一个安全协议是3-D安全(3DS)协议，该协议使购买交易的财务授权过程与完成购买交易的用户或账户的在线认证耦合。此协议被设计成允许信用卡发行方在持卡人在网上购物或在其他“无卡”情况下购物时对其持卡人进行认证。然而，迄今为止提出的3DS和其他认证过程和系统通常是复杂、成本昂贵的闭环系统，并且主要针对认证持卡人的身份。

因此，期望提供改进的方法和系统，所述方法和系统支持获取并处理与购买交易相关的认证数据，该认证数据在操作上是稳定的、高效的和可扩展的并且包括改进的数据管理功能。

附图说明

结合附图考虑以下对本发明的详细描述，本发明的一些实施例的特征和优点以及实现它们的方式将变得更加明显，其中：

图1是用于一般持卡人认证的系统的说明性描述；

图2是根据本文的一些实施例的用于认证处理的系统的说明性描述；

图3是根据本文的一些实施例的用于认证处理的系统的说明性描述，所述认证处理包括与认证相关数据的外部源连接；

图4是根据本文的一些实施例的认证平台的逻辑架构；

图5是根据本文的一些实施例的系统的示意性框图；

图6是根据本文的一些实施例的数据交换流程的说明性描述；并且

图7是根据本文的一些实施例的装置的示意性框图。

具体实施方式

一般来说，为了引入本公开的实施例的概念，认证安全策略涉及在在线电子商务(电商)环境中的交易期间验证持卡人账户所有权的过程，该交易可能包括购买交易。如本文所使用的，术语购买交易和支付交易或仅交易可以互换使用，除非另有说明。一般来说，本文中的购买交易是指无卡交易或电子商务交易。同样地，商家或其他实体可以请求这些交易以使提供用于支付的支付设备或其账户的持卡人、用户或其他实体被验证为支付设备的授权用户，例如因为商家不能在物理上验证用户甚至拥有该支付设备。

根据本公开的一些一般方面，将描述用于认证过程、系统和方法的框架，该框架包括高效且灵活的数据管理功能和机制。本文中的认证框架或平台的数据管理功能和机制包括但不限于提供对新客户注册过程和认证平台的计费方面的有效且准确的控制和管理。在一些方面，本文的认证框架或平台提供支持客户注册/数据管理的机制以及可扩展到未来业务增长和客户期望的计费解决方案。在一些方面，本文的认证框架或平台支持并促进对与认证生态系统中的发行方、支付处理器和商家信息的方面有关的数据的准确管理。

支付设备系统、应用程序或服务从认证生态系统(包括但不限于3DS环境)内的商业、企业或组织的各种内部和外部实体(例如，应用程序、设备、服务等)收集认证数据，认证生态系统可以提供认证服务并将收集的认证数据存储在数据存储库中，诸如数据仓库、本地或分布式存储设施以及基于云的存储服务。所收集的认证数据可以用作商业分析的基础，包括例如企业或其他商业组织的内部和外部客户的商业报告。在一些方面，基于所收集的认证数据的分析可用于交易欺诈评分目的。在一些实施例中，从所收集的认证数据导出的数据可以被共享并与数据仓库内的交易数据(例如，购买授权数据)结合使用以提供端对端交易生命周期的视图。

本公开至少部分地提供用于报告交易的端对端或完整视图的过程和系统，该交易包括用于信用的授权和处理和其他类型的交易的认证数据。本文中确定、处理、收集、分析和存储的认证数据可用于提供对商业和其他实体的有价值的见解。这些见解可以涉及但不限于：交易模式，认证趋势和模式，卡发行方认证成功率和失败率，由于某些卡范围或区域内的多次故障导致的欺诈指示符，持卡人认证放弃的趋势，某些认证服务提供商的失败率以及特定交易中使用的认证方法的趋势。

已经提出了许多方法、系统和解决方案来提供持卡人认证过程。一种解决方案是由本专利申请的受让人发布的SecureCode^TM，其定义并提供了与持卡人认证过程有关的安全级别。SecureCode^TM过程融合了2006年4月17日生效的3-DSecure^TM协议规范核心功能(版本1.0.2)的多个方面。3-D Secure^TM(本文中也称为“3DS”)的这种特定实施方式包括在不改变3-D Secure^TM规范、消息或协议的情况下支持SPA(安全支付应用程序)算法和通用持卡人认证字段(UCAF)。虽然本文中的某些方面可能依靠、依赖于并利用3-D Secure^TM规范的多个方面，但是本文中的过程和系统不限于遵守该规范的安全认证协议或过程，或者甚至可能在3DS协议内适合的认证流程。甚至可以在与3-DSecure^TM规范的至少一些方面配合的系统和过程的上下文中描述一些实施例的本文中的一些实例中，其他或替代的认证安全协议可以在不失一般性的情况下被替换，包括现在已知的以及将来可能开发的认证安全协议。

图1是用于实施可用于根据3-D Secure^TM规范验证持卡人账户所有权(即，持卡人认证)的过程的系统100的说明图。如此，图1部分地提供了根据3-D Secure^TM规范的持卡人认证系统和过程的概览。然而，本文没有讨论说明书的所有细节，因为通过直接参考3-DSecure^TM规范和/或其讨论可以容易地理解这些信息的完整详细公开。此外，因为本文公开的概念和细节不限于特定认证协议，诸如3DS，所以3DS的详尽细节不是完整理解本公开的先决条件。

系统100包括多个实体，这些实体必须通过在安全通信信道上交换多个特别格式化的消息(如在3-D Secure^TM规范中所定义的)来彼此交互。因此，考虑到特定实体、消息以及必然涉及的其他需求的数量和范围，图1的持卡人认证过程是复杂的。

系统100包括与商家的在线存在交互的持卡人105。通常，持卡人105使用他们的选择的设备上的浏览器访问商家的网站，并选择用于购买的项目(例如，商品和/或服务)。作为在线订购过程的一部分，持卡人105通过向商家提供支付凭证来结账并完成购买交易。支付凭证可以至少包括表示要在交易中用作资金来源的账户的主账号(PAN)、与PAN相关联的截止日期以及持卡人的(账单)地址信息。PAN和其他信息被提供给商家的商家服务器插件(MPI)110，其中MPI是代表商家执行的软件模块。MPI110操作以确定支付认证是否可用于从持卡人接收的PAN。MPI格式化并发送包括PAN的验证注册请求(VEReq)消息到目录服务器(DS)115，其中DS是可以确定PAN是否在由系统100提供的认证服务中所注册的PAN的范围内的计算机服务器。DS可以包括计算机，该计算机具有至少一个处理器、存储程序指令和数据的存储器以及与其他设备连接的通信接口。

一旦收到VEReq，DS 115就查询访问控制服务器(ACS)120设备，其中在VEReq中指定ACS的地址。可以使用ACS的网址URL(全球资源定位符)来指定ACS的地址。指定的ACS可以是由PAN代表的账户的发行方。在一些实施例中，ACS可以代表PAN的发行方来行动，并且指定的URL指向除了发行方的网址之外的网址。ACS 120可以通过提供认证是否可用于VEReq中包含的PAN的指示来响应该查询。如果商家是参与的收单方并且商家是有效的商家，则ACS 120可以用验证注册请求(VERes)消息进行响应，该验证注册请求消息指示认证可用于VEReq消息中包含的PAN。ACS 120使用来自VEReq的PAN来确定持卡人是否在认证服务中被注册。

在一些情况下，MPI可以存储与认证服务中注册的PANS的范围有关的数据，并且确定PAN是否在由系统100提供的认证服务中注册的PAN的范围内。

在一些方面中，VERes可以包括认证可用于PAN的标志(例如，PAN认证可用字段可以被设置为指示认证可用的“Y”)。相反，ACS 120可以用指示认证不可用于PAN的VERes进行响应(例如，未注册的收单方BIN和/或PAN、对查询无响应的ACS等)。在一些方面，VERes可以包括认证不可用于PAN的标志(例如，PAN认证可用字段可以被设置为指示认证不可用的“N”或指示认证不能用的“U”)。如果VERes包含标志、其字段中的值或其他机制以指示认证不可用于PAN，则由系统100提供的认证过程可以终止或中止。

ACS 120进一步发送包括认证是否可用于DS 115的指示的VERes。然后DS 115将VERes转发到MPI 110。这可以推断DS参与交易认证，但认证过程远未完成。一旦接收到VERes，MPI 110就读取该响应以查看认证是否可用于交易的PAN。如果认证可用，则MPI 110利用VERes中包含的ACS URL经由持卡人的浏览器向ACS 120发送包含付款人认证请求(PAReq)消息的消息。PAReq消息请求发行方ACS对其持卡人进行认证。PAReq可能包括持卡人、商家和特定交易信息。持卡人信息可以包括仅由持卡人和发行方知道的安全信息。注意到，PAReq消息不与商家(或MPI)共享。

ACS 120接收PAReq，并且可以继续验证接收到的消息以确保其被正确地格式化并且包含必要的信息，包括例如数字证书和适当的PAN认证可用标志(例如“Y”)。ACS 120可以进一步确定是否提供持卡人的认证。ACS120可以通过提供交易的状态来提供该确定的指示。根据3-D Secure^TM，状态值可以包括：表示客户被完全认证的“Y”；表示客户认证失败或取消认证(即交易被拒绝)的“N”；表示未能完成认证(例如，诸如通信故障、超时等的技术问题)的“U”；以及提供尝试认证的证据的“A”。

消息从ACS 120发送到MPI 110，该消息包含由ACS 120确定的交易状态。该消息可以包括付款人认证响应，PARes消息。如果交易状态被确定为“Y”，则PARes将包括发送到MPI110的认证令牌AAV。PARes可以被数字签名以提供关于消息本身真实性的安全级别。通过持卡人的浏览器在MPI 110处接收PARes。一旦接收到PARes，MPI 110就可以操作以验证PARes的签名，并且至少部分地基于包含VERes的值来确定是否授权交易。

如果持卡人使用上面概括描述的认证过程被认证，那么购买交易可以进行到购买或支付授权过程并且向MPI通知AAV值或令牌。在MPI通知商家支付系统认证尝试的结果之后，可以以常规方式完成购买授权。

再次注意到，如上文关于图1所解释的持卡人或账户的认证仅仅是与本公开兼容的认证流程的一个示例。这样，包括使用与上述相同或不同的消息类型相互通信的至少一些不同实体的其他认证流程和过程在本公开的范围内。

在某些情况下，如果认证不成功，那么商家仍然可以在没有认证令牌的情况下继续进行常规的交易授权，作为未认证的交易。处理未认证的交易的责任在一些这样的情况下由商家承担。根据本文的一些方面，包含不成功的持卡人认证的指示的数据将被存档并维护。

如结合图1所指出的，许多消息通常可以在众多不同实体之间通信。同样地，考虑到涉及到各方的数量、在不同实体之间交换的特定消息的数量、需要对交换消息的内容进行确定的次数以及消息的安全通信，持卡人认证过程通常可能是一个复杂的过程。根据本文的一些方面，在一个或多个有形的记录、消息或数据结构中维护认证过程的所有相关阶段。

图2公开了根据本文的一些实施例的系统200。系统200包括应用程序205。在一些实施例中，应用程序205可以在企业、商业或其他组织内部。如本文所使用的，“内部”应用程序、服务、设备或系统不暴露于特定企业、商业或其他组织之外的系统、设备、服务或通信信道。在一些实施例中，应用程序205可以是根据本文的API(应用程序接口)规范而配置的软件应用程序或服务。这里API可被称为认证API。认证API可以指定将要包括在应用程序205与另一个软件应用程序、设备、系统或服务(例如企业服务器210)之间的信息交换中的信息。企业服务器210可以操作以经由API调用从应用程序205接收对认证值或令牌的请求，并且为答复该API调用(即，请求)而经由API响应将认证值发送到软件应用程序205。

在一些实施例中，所请求的认证值可以包括与通用持卡人认证字段(UCAF)数据结构兼容的安全代码，该数据结构与认证支付环境兼容。然而，应注意的是，在本文的一些实施例中的认证值不限于UCAF数据结构或其实例。根据本文的一些方面，所请求的认证值可以与在特定交易和/或用例中利用的一个或多个认证流程兼容。

在一些实施例中，认证支付环境可以包括三域(3-D)安全协议，尽管在一些实施例中可以使用其他认证流程和协议。在一些实施例和方面中，生成并传送API调用和对其进行答复的API响应的过程以及用于执行该过程的系统和设备与安全协议是分离的并且不同的。在一些实施例中，本文的方法和过程的方面在一些情况下可以向包括安全协议但与其不同的过程和系统提供信息和/或从该过程和系统接收信息。

在一个方面，对认证值或令牌的请求可以用于具体的特定交易，其中为答复API调用而返回或发送到调用应用程序205的认证值提供对API调用中指定的交易有效且特别与其关联的认证值。在一些实施例中，在由应用程序205和/或其他应用程序、系统、设备和服务执行的一个或多个过程中，应用程序205和/或其他应用程序、系统、设备和服务可以使用从企业服务器210向应用程序205发送的认证值或令牌。作为示例，由企业服务器210生成并响应于来自应用程序的API调用而发送到应用程序205的认证值可以用作经过验证的认证的指示符(即，证据)，并且进一步被包括在支付交易授权请求或其他过程中。在一些实施例中，可以以合适的方式(例如，格式化、编码、加密等)使认证值格式化并被编码，使得包括本文中的认证值的特定授权请求不需要被改变以适应认证值并以其他方式进行处理。因此，图2的一些实施例可以配合并适应系统和过程，这些系统和过程包括可以至少部分地符合一个或多个安全协议的那些当前已知和将来开发的系统和过程。在至少一个用例中，可以在购买交易过程中进一步使用认证值，该购买交易过程至少部分地包括购买交易授权(例如，信用卡授权)。在一些其他实施例中，由企业服务器210响应于应用程序205的请求而获得的认证值可以以这样一种方式被进一步格式化和/或编码，以适应该请求并且与请求应用程序205兼容。

在一些实施例中，注意到应用程序205利用单个API调用向企业服务器210发出认证请求。相反，企业服务器可以利用单个API响应向应用程序205提供答复。以这种方式，可以通过利用来自应用程序的单个API调用通过请求和接收认证值或令牌，从而以高效的过程来获得认证值。在一些方面，这与参考例如图1公开的过程的一些实施例形成对比，这些实施例涉及多个不同的实体，这些实体针对每个特定的安全协议在交换符合特定消息格式和通信会话要求的特定消息的同时必定以特定顺序彼此通信。

参照图3，示出了根据本文的一些实施例的系统300的说明图。在一些方面，图3公开了包括历史记录服务器的认证平台的逻辑方面，该历史记录服务器可以记载并记录认证过程(例如包括3-D Secure^TM，但不限于此)的每个认证请求的端对端交易流程。因此，实际系统可以包括图3中没有明确示出的布置的更少、更多或不同的设备和实体，而没有任何通用性或适用性的损失。在一些方面中，系统300可以包括平台，该平台可以利用诸如图1中公开的常规认证系统的一些方面(但不限于此)以及图3中公开的系统的一些方面。在一些方面，系统300和由此实施的过程可以运行以每一天处理数百万个交易和认证请求。系统300能够进行这样的处理范围和规模，包括是否完成认证请求以及初始购买交易是否也在相关联的购买授权中表示或者是否已完成认证请求的每个认证请求。因此，系统300必然包括改进的计算机设备、系统和网络，而不限于实施已知的过程。

在一些方面，系统300包括应用服务器310，该应用服务器可以接收付款人认证请求(PARes)消息或根据所使用的认证协议的其他消息，以及付款人认证请求(PAReq)消息或根据与来自一个或多个来源的交易相关使用的认证协议的其他消息。根据一些认证系统和过程，可以从企业环境外部的ACS 305接收PAReq或其他消息和PARes或其他消息。在一些方面，可以从至少部分类似于图1的系统100所配置的系统的发行方ACS接收PAReq消息和PARes消息。可以从外部ACS提供者请求从外部ACS接收的交易PAReq和PARes或其他数据。由服务器410接收的PAReq和PARes数据可以被发送到数据库服务器425。服务器425(在本文中也被称为“历史记录服务器”)可以操作以跟踪、存储、格式化、编码和/或加密所接收的数据，以将PAReq和PARes或其他认证数据插入到数据库表、系统、其他数据结构和数据存储服务中。

在一些方面，服务器310可以接收与来自企业环境内部的一个或多个服务器(例如来自服务器315和320)的交易相关联的PAReq和PARes数据。服务器315和320可以是至少部分充当ACS的一个或多个设备或系统。在一些实施例中，ACS 315是可以在企业环境内部的内部ACS，诸如图2的安全(ACS)服务器215。如之前关于图2所述，包括企业服务器210和其中的其他组件的系统200可以在企业环境内部操作，其中企业200响应于来自应用程序或服务205的API调用而生成认证值。根据认证值的生成，ACS 315可以根据所使用的认证协议具有交易PAReq和PARes数据或其他消息。

在一些实施例中，服务器320可以包括由企业提供的在线认证服务ACS，而在一些实施例中，服务器320可以包括其他类型的ACS服务器，这些ACS服务器可以至少偶尔与企业环境外部的应用程序、设备和/或服务通信。服务器320可具有与某些在线交易和其他类型的交易相关联的交易PAReq和PARes数据或其他认证数据。来自服务器315和320的PAReq和PARes或其他认证数据可以被传输到应用服务器310，然后被传输到历史记录服务器325。

可以从一个或多个服务器315(例如，内部ACS服务器)和目录服务器(DS)340认证过程数据的其他方面，即验证注册请求(VEReq)消息和验证注册响应(VERes)消息或根据所使用的认证协议的其他消息。在一些方面，服务器315是可促进用于交易的认证值的内部生成的内部ACS，如关于图2所讨论的。如此，与相关联的交易对应的VEReq和VERes数据由内部ACS 315存储。该VEReq和VERes或其他消息可以被传送到应用服务器340至少用于存储目的。

在一些情况下，可以在外部设备、应用程序和服务(诸如图1的系统100)的协助和配合下生成VEReq和VERes或其他消息。因此，可以经由服务器340从商家MPI接口335接收与一些交易相关联的VEReq和VERes或其他数据并将其存储在DS 340上。

在一些方面，无论从内部ACS还是从DS 340接收VEReq数据和VERes数据，服务器340都可以操作以跟踪、存储、格式化、编码和/或加密所接收的数据，以将VEReq和VERes或其他数据插入到数据库表、系统和其他数据结构中。在一些实施例中，VEReq和VERes数据或根据正在使用的认证协议的其他消息中包括提供VEReq和VERes或其他数据的设备的来源或类型的指示。该来源指示符可以提供对与特定交易相关联的认证令牌请求是由内部过程(例如，图2)还是由外部过程、设备、服务或系统生成的见解。

历史记录服务器325(即，PAReq和PARes或其他数据)和DS服务器345(即，VEReq和VERes或其他数据)中的数据可以被同步并且以其他方式处理、组合或聚类，用于包含在数据仓库、存储设施、设备或系统330中。在一些实施例中，数据仓库330可以包括数据库管理系统或数据库管理系统的节点的实例。在一些方面，组合的PAReq/PARes或其他数据以及VEReq/VERes或其他数据可以包括单个数据记录或其数据结构表示。除了其他交易细节之外，组合数据记录可以提供交易流程的端对端视图，包括商家是否请求认证、发行方是否提供认证、认证是被批准还是被拒绝、以及是否请求交易的支付授权以及该支付授权是被批准还是被拒绝。

在一些方面，数据仓库330中的数据可以被其他系统和设备(未示出)访问并用于提供对交易的见解。在某些情况下，可以使用企业级分析来分析数据以例如生成报告、演示文稿和仪表板。在一些方面，数据仓库330中的数据可以被企业的各种组织用于例如解决交易争议，管理并响应发行方或商家投诉，管理合规计划，管理放弃率等。在一些实施例中，系统300促进并允许功能以确定交易中的独特模式，并且比交易数据收集的先前方法更好地确定用户和商家的做法(例如欺诈等)。

在一些实施例中，根据本文中的一些方面处理和收集的认证数据可以用于过程、系统和设备中，以基于例如账户或身份的历史认证模式和/或历史认证速度来评价特定交易的风险级别或提供风险级别的指示。在这里和其他上下中，历史认证活动可能至少部分地与当前请求进行比较，以确定认证数据是否落在观察的、期望的、希望的、计算的或预测的模式、范围和“规范”之外(之内)。在一些方面中，为了便于使用数据实现分析、存储、检索和报告功能，可以将本文中处理并存储的认证数据进行聚类。

作为本文中的认证生态系统或平台500的一部分，访问控制服务器(ACS)或一些其他系统可以调用代表性认证服务505，从而以“带外”方法提供实际认证，其可以包括例如一次性密码生成和验证服务、移动应用程序、生物识别验证服务以及其他类型的服务、流程、应用程序和用例。所有这些请求和其他请求的结果也可以输入到数据仓库中的数据存储库中，该数据储存库可与其他数据配合以提供详细的交易报告和分析。

在一些实施例中，根据本文的一些方面的认证API可以包括一个或多个数据字段。以下表1是根据本文的一些实施例的列出一些数据字段的表格，这些数据字段可以被指定用于实施可以由网络服务或应用程序使用的API。在一些实施例中，表1中列出的数据字段可以用接口描述语言(例如，网络服务描述语言，WSDL)描述，并被提供给网络服务或应用程序的开发人员，以供开发人员或其他实体使用以生成可使用适当定义的API有效通信的网络服务或应用程序。

在一些实施例中，认证API可以要求或期望为表1中列出的所有数据字段指定值。也就是说，API调用可以包括用于表中列出的每个数据字段的对应值。在一些其他实施例中，表1中指定的一些但不一定是全部的数据字段可以具有在API调用中提供的对应值。例如，本文中的认证API的一些实例可以指定PAN(即，支付账户号码)的值、商家名称以及与该PAN相对应的失效日期。这些最小值可以被包括在API调用中，并且在本文中的一些实施例中可以足够用于的认证值的请求。根据本文中的一些实施例，本文中接收到的或被提供给认证历史记录服务器的数据包含至少一些以下组件：

商家名称
	商家国家代码
商家全球资源定位符
	商家ID
收单方BIN
	购买日期
交易标识符
	购买量
购买货币
	货币指数
连续付款数据
	分期付款数据
PAN
	卡到期日
帐户标识符
	交易时间
交易状态
	认证值
交易指示符
	客户IP地址
使用的认证方法

表1

表1包括用于本文中的一些实施例的数据的说明性示例列表。列出的数据可能不全面或详尽。因此，在本文的一些实施例中，诸如高级持卡人信息和其他交易数据的其他数据也可以由认证历史记录服务器存储或接收和/或被提供给认证历史记录服务器。

在一些实施例中，根据过程300操作的应用程序可以包括代表发行方开发的电子支付钱包应用程序。作为电子钱包的开发和部署的一部分，电子钱包的认证可被分配或传递给支付网络提供商或其他实体。在登录钱包应用程序时，可能存在某种级别的认证，该认证向钱包的发行方验证钱包应用程序的真实性或身份。因此，由于钱包应用程序已经向发行方进行认证，因此可能不需要商家在牵涉到客户的购买时在结账时对钱包进行认证。在某些情况下，钱包认证是作为钱包启动过程的一部分完成的。

尽管与该示例的钱包应用程序相关联的用户已经向发行方认证达到这样一种认证水平，该认证水平被确定并设计为满足发行方和/或其他人的关注(即，“预认证的”)，特定认证可以不提供通常可以由安全协议和/或根据安全协议生成的认证值或令牌，诸如AAV值。为了获得认证值或令牌(例如，AAV值)，根据本公开，电子钱包应用程序可以经由API调用来请求认证值。API调用可以直接呈现给服务以从中提取认证值。在一些方面，来自应用程序的API调用可以获得认证值，而不需要满足一个或多个安全协议的所有要求，因为例如发行方或代表其行动的实体已同意在满足某些条件的情况下的API调用的处理。在一些实施例中，在本文的企业服务器接收到API调用之前(例如，在过程300的操作305之前)确定接受并处理来自根据本公开的应用程序的API调用的协议。在一些方面中，可以说本示例中的电子钱包的认证包括预授权认证。

在一些实施例中，管理电子钱包或其他调用应用程序的认证的策略可以根据调用应用程序、调用应用程序对认证值或令牌的预期用途以及其他考量而变化。

继续电子钱包的示例，在客户持卡人登录商家的钱包服务的实例中，已注册钱包服务的客户可以被认为已被认证(即，预授权认证)。然而，在这种情况下，在与客户的购买交易相关联的支付授权请求中可能希望使用认证值或令牌。在一些实施例中，发行方(或代表其行动的实体)将预期支付授权请求以包括认证值或令牌。在一些方面，在没有预期的认证值或令牌的情况下，可能不会处理支付授权。

在一些实施例中，在支付授权请求中包含认证值或令牌可以根据已知的、预定的或将来开发的处理流程促进支付授权的处理。在支付授权请求中缺少预期的认证值或令牌可以根据替代或“例外”处理流程或处理流程的终止来触发对支付授权的处理。

参考图2，在一些实施例中，安全服务器215可以将由企业服务器210生成的认证值或令牌的记录或表示转发到历史记录服务器220。历史记录服务器220可以进一步将交易细节发送到数据库225。交易细节可用于进一步的处理、报告和分析。

图4是根据本文的一些实施例的系统400的框图。系统400可以包括认证数据管理平台405，该认证数据管理平台与一个或多个认证系统、设备、应用程序、服务415连接或以其他方式与之通信。在一些实施例中，认证管理平台405可以支持并促进与认证服务相关的客户数据和其他数据的获取、更新和分析。在一些方面，认证系统415可以包括或涉及3DS认证系统、服务和应用程序，尽管包括认证管理平台405的本公开的实施例不限定或局限于与实现3DS认证协议的认证系统通信或连接。在一些实施例中，一个或多个认证系统可以彼此互相操作或不可互相操作。无论一个或多个认证系统415是否彼此可互相操作，认证系统415中的每一个可以与认证管理平台405通信或以其他方式连接。在一些情况下，可以通过一个或多个通信接口或其他设备、服务或应用程序(未示出)来促进认证系统415和认证管理平台405之间发送和接收的通信消息、命令和/或指令，以确保这些消息在认证系统415和认证管理平台405之间的兼容性。

认证管理平台405可以包括或者至少具有对一个或多个数据存储设施或储存库410的访问权限。在一些实施例中，数据储存库410可以包括关系数据库，该关系数据库包括一个或多个数据库节点并且管理用于商业企业的数据，在一些情况下，商业企业提供与认证服务相关的数据管理功能，包括但不限于客户注册和客户数据管理(即，在本文中也称为客户注册/数据管理)和结算解决方案方面。储存库410可以容纳并管理各种数据结构的数据的所有方面和类型，诸如与企业的组织、部门或其他商业实体内的一个或多个不同组织中的客户有关的客户联系人数据。认证管理平台400可以进一步包括后端系统420以支持认证平台405的数据获取、数据处理和数据管理功能。在一些实施例中，后端系统可以与商业企业的商业组织至少在逻辑上组织在一起。

图5是根据本文的一些实施例的用于系统的逻辑架构500的说明性图示。在一些实施例中，由系统500提供、支持和促进的功能可以由认证管理平台(例如平台400)提供或实施。系统500的实际实施方式可以包括比图5中明确描绘的部件更多或不同的部件，并且可以以其他配置来布置，而不仅仅是图5所示的配置。其他拓扑可以与其他实施例结合使用。此外，本文中描述的每个系统可以由通过任何数量的其他公共和/或专用网络进行通信的任何数量的设备来实施。两个或更多个这样的计算设备可以位于彼此远离并且可以通过任何已知的网络连接方式和/或专用连接方式彼此通信。每个设备可以包括适合于提供本文描述的功能以及任何其他功能的任何数量的硬件和/或软件元件。例如，在一些实施例的实施方式中使用的任何计算设备可以包括处理器以执行程序代码，使得计算设备如本文所述进行操作。

系统500包括认证门户505。新型认证门户505为一个或多个外部用户(即，在提供系统500的服务或功能的企业或商业组织外部的用户)提供机制以与本文中的认证管理平台通信并且以其他方式访问由其管理的认证信息。在一些方面，外部用户515可以经由外部客户主门户510与认证门户505连接。在一些实施例中，外部客户主门户510可以至少部分地包括面向外的图形用户界面，该图形用户界面可以通过运行适用的应用程序(例如，“应用”)的计算机或处理器使能设备(诸如计算机、平板电脑或智能手机)进行访问。在一些实施例中，外部客户主门户510可以经由浏览器、浏览器扩展或应用编程接口(API)来实施和/或访问。在一些情况下，外部用户515可以包括在本文的认证平台的认证服务和应用程序中注册或可能注册的发行方、收单方和授权的第三方(例如，发行方和收单方服务提供商)。在一些实施例中，外部客户515的联系信息可以由外部客户主门户510的一些实施方式来存储和管理。

系统500中包括电子数据储存库(EDR)520。EDR 520可以包括数据存储设施，诸如关系数据库管理系统，以存储、维护和管理例如与本文的认证平台的现有外部客户515有关的历史数据。EDR 520可以至少部分地包括云端存储服务、系统或应用程序。在一些实施例中，EDR 520可以是包括一个或多个数据库节点或实例的集中式或分布式数据库系统。EDR520可以用作输入到系统500中或者系统一直努力从外部客户500以其他方式获得的数据的验证点，以确保这些数据与已知且由企业管理的数据一致并精确对应。在一些实施例中，EDR 520可以基于一个或多个规则或可操作触发器自动更新并验证本文中的数据。

在一些方面，系统500还包括决策管理平台或服务525。决策管理平台525可以是数据管理设备或系统(例如，关系数据库系统)，该数据管理设备或系统存储外部客户515(发行方、收单方和授权的第三方)的外部客户信息。在一些特定实施例中，决策管理平台或服务525可以包括认证数据库530。认证数据库530可以存储并维护表示客户数据的记录、文件和其他数据结构，客户数据包括但不限于合同、笔记(例如消息、文档、非结构化数据等)、认证信息、信用卡范围、支付设备BIN(银行识别码)、商家信息和其他数据。

系统500可以包括认证数据库用户界面535，该认证数据库用户界面在企业内部提供用于内部认证用户540的界面以访问决策管理平台525并且以其他方式与之通信。在一些方面，认证数据库用户界面535提供用于内部认证用户540访问认证平台的认证信息的机制，以提供或至少促进客户支持功能以及商业或分析师对外部客户认证相关数据(例如，联系人信息，账单信息等)的访问。根据内部认证用户的角色，经由认证数据库用户界面535访问认证数据库可以限于内部认证用户。

图6是根据本文的一些实施例的可以由认证平台执行的数据交换的说明性逻辑描述。图6的数据通常可由数据库610存储并维护，该数据库可由外部用户经由外部用户界面604访问并由内部认证用户通过内部用户界面615访问。可以经由外部UI 605向数据库610提供多种不同类型的数据，包括卡范围信息602、商家信息604、外部用户联系人信息606、测试和证明数据608以及发行方信息612。除了或替代图6所示的外部用户信息之外，在本文的一些实例和实施例中可以包含与认证平台的一个或多个外部用户有关的数据的其他方面和类型。

在一些实施例中，可以经由内部UI 615向数据库610提供多个不同类型的数据，包括历史卡范围信息624、商家信息626、外部用户联系人信息628、测试和证明数据630以及发行方信息632。除了或替代图6所示的特定外部用户信息之外，在本文的一些实例和实施例中可以包含与本文的认证平台的一个或多个外部用户有关的数据的其他方面和类型。

在一些方面，外部客户主门户618提供与图5的外部客户主门户510类似的功能，并且图6中所示的认证数据库614、616、620和622的实例可以提供与图5所示的认证数据库530类似的功能。在本文的一些方面中，EDR(诸如图5的EDR 520)为在图6中表示的外部用户、内部用户和数据库之间交换的数据提供了许多验证点。

图7是根据一些实施例的系统或设备700的框图概览。系统700可以例如与本文所述的任何设备相关联，包括例如企业服务器、认证数据库服务器以及根据本文公开的过程的类似功能。系统700包括与通信设备715连接的处理器705，诸如单芯片微处理器或多核处理器形式的一个或多个商业可用的中央处理器(CPU)，该通信设备被配置为经由通信网络(图7中未示出)与另一个设备或系统进行通信。在实例中，系统700包括服务器(例如，支持由本文的认证平台提供的功能和服务)，通信设备715可以提供使系统700与另一设备、系统或服务(例如，认证系统的实例)连接的机制。系统700还可以包括本地存储器710，诸如RAM存储器模块。该系统还包括输入设备720(例如，用于输入内容的触摸屏、鼠标和/或键盘)和输出设备725(例如，触摸屏、用于显示的计算机显示器、LCD显示器)。

处理器705与存储设备730通信。存储设备730可以包括任何适当的信息存储设备，包括磁存储设备(例如，硬盘驱动器)、光存储设备、固态驱动器和/或半导体存储设备的组合。在一些实施例中，存储设备630可以包括数据库系统。

根据本文的过程，存储设备730可以存储程序代码或指令735，程序代码或指令可以提供用于更新和验证客户认证数据并存储其数据记录以供进一步处理、分析和报告目的的计算机可执行指令。处理器705可以执行程序指令735的指令，从而根据本文描述的任何实施例进行操作。程序代码735可以以压缩、未编译和/或加密格式存储。此外，程序代码735可以包括其他程序元件，诸如操作系统、数据库管理系统和/或处理器705用于与例如外围设备连接的设备驱动程序。存储设备730还可以包括数据740，诸如数据库记录或查找表，包括例如参与特定认证程序或服务的商家、发行方和收单方的记录以及这些实体实施该服务所使用的设备的地址。在一些方面，系统700可以使用数据740来执行本文中的一个或多个过程，包括单独的过程、这些过程的单独的操作以及单独的过程和单独的过程操作的组合。

本文讨论的所有系统和过程可以体现在存储在一个或多个非暂时性计算机可读的处理器可执行的介质上的程序指令中。这样的介质可以包括例如固态驱动器、软盘、CD-ROM、DVD-ROM、磁带以及固态随机存取存储器(RAM)或只读存储器(ROM)存储单元。根据一些实施例，存储器存储单元可以与访问模式相关联并且可以独立于设备(例如，磁性、光电子、半导体/固态设备等)此外，可以使用内存技术，使得可以在处理器的RAM存储器中完全操作数据库等。因此实施例不限于硬件和软件的任何特定组合。

本文中仅仅出于说明的目的描述了实施例。本领域的技术人员将从该描述认识到，实施例不限于所描述的那些实施例，而是可以通过仅由所附权利要求的精神和范围限制的修改和变化来实现。

Claims (21)

1.一种计算机实施的方法，所述方法包括：

由计算机从认证系统的至少一个外部用户接收记录，所述记录包含用于所述外部用户并且与所述至少一个外部用户向所述认证系统的至少一个注册相关的客户信息；

由与存储历史外部用户客户信息的认证数据库连接的计算机接收包含用于所述外部用户的客户信息的记录；

验证包含用于所述外部用户的客户信息和所述历史外部用户客户信息的记录；并且

存储所验证的记录的指示。

2.根据权利要求1所述的方法，其中，在接收包含用于所述外部用户的客户信息的所述记录时，自动执行包含用于所述外部用户的客户信息的所述记录的验证。

3.根据权利要求1所述的方法，其中，所述外部用户是发行方、收单方和被授权代表发行方或收单方行动的第三方实体中的至少一个。

4.根据权利要求1所述的方法，其中，所述认证数据库包括关系数据库系统。

5.根据权利要求1所述的方法，其中，对从所述至少一个外部用户接收的所有数据执行验证。

6.根据权利要求1所述的方法，其中，从内部认证用户获得所述历史数据，并且针对包含从所述外部用户接收的客户信息的记录进一步验证所述历史数据。

7.根据权利要求1所述的方法，其中，所述认证数据库存储用于实施第一认证协议的认证系统的数据，并且包含所述客户信息的所述记录至少包含用于实施所述第一认证协议的认证系统的所述至少一个外部用户的注册信息。

8.一种系统，包括：

认证服务器；以及

设备，所述设备包括：

处理器；以及

与所述处理器通信并在其上存储有程序指令的存储器设备，所述处理器利用所述程序指令操作以：

从认证系统的至少一个外部用户接收记录，所述记录包含用于所述外部用户并且与所述至少一个外部用户向所述认证系统的至少一个注册相关的客户信息；

从存储历史外部用户客户信息的认证数据库接收包含用于所述外部用户的客户信息的记录；

验证包含用于所述外部用户的客户信息和所述历史外部用户客户信息的记录；并且

存储所验证的记录的指示。

9.根据权利要求8所述的系统，其中，在接收包含用于所述外部用户的客户信息的所述记录时，自动执行包含用于所述外部用户的客户信息的所述记录的验证。

10.根据权利要求8所述的系统，其中，所述外部用户是发行方、收单方和被授权代表发行方或收单方行动的第三方实体中的至少一个。

11.根据权利要求8所述的系统，其中，所述认证数据库包括关系数据库系统。

12.根据权利要求8所述的系统，其中，对从所述至少一个外部用户接收的所有数据执行验证。

13.根据权利要求8所述的系统，其中，从内部认证用户获得所述历史数据，并且针对包含从所述外部用户接收的客户信息的记录进一步验证所述历史数据。

14.根据权利要求8所述的系统，其中，所述认证数据库存储用于实施第一认证协议的认证系统的数据，并且包含所述客户信息的所述记录至少包含用于实施所述第一认证协议的认证系统的所述至少一个外部用户的注册信息。

15.一种其上存储有程序指令的介质，所述介质包括：

从认证系统的至少一个外部用户接收记录的程序指令，所述记录包含用于所述外部用户并且与所述至少一个外部用户向所述认证系统的至少一个注册相关的客户信息；

从存储历史外部用户客户信息的认证数据库接收包含用于所述外部用户的客户信息的记录的程序指令；

验证包含用于所述外部用户的客户信息和所述历史外部用户客户信息的记录的程序指令；以及

存储所验证的记录的指示的程序指令。

16.根据权利要求15所述的介质，其中，在接收包含用于所述外部用户的客户信息的所述记录时，自动执行包含用于所述外部用户的客户信息的所述记录的验证。

17.根据权利要求15所述的介质，其中，所述外部用户是发行方、收单方和被授权代表发行方或收单方行动的第三方实体中的至少一个。

18.根据权利要求15所述的介质，其中，所述认证数据库包括关系数据库系统。

19.根据权利要求15所述的介质，其中，对从所述至少一个外部用户接收的所有数据执行验证。

20.根据权利要求15所述的介质，其中，从内部认证用户获得所述历史数据，并且针对包含从所述外部用户接收的客户信息的记录进一步验证所述历史数据。

21.根据权利要求15所述的介质，其中，所述认证数据库存储用于实施第一认证协议的认证系统的数据，并且包含所述客户信息的所述记录至少包含用于实施所述第一认证协议的认证系统的所述至少一个外部用户的注册信息。