CN1930591A

CN1930591A - 多方受益的在线认证服务

Info

Publication number: CN1930591A
Application number: CNA2004800391796A
Authority: CN
Inventors: G·E·格尔伯; T·M·－C·李
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2004-05-03
Filing date: 2004-05-11
Publication date: 2007-03-14
Also published as: AU2004319618A2; KR20130141718A; KR101379168B1; JP2007536619A; US20140258125A1; JP2011138523A; SG185825A1; AU2004319618B2; AU2004319618A1; EP1745447A1; WO2005111957A1; KR20120112877A; CA2547604A1; BRPI0417579A; JP5118959B2; KR20070007044A; JP5140167B2; US8762283B2; US20050246278A1

Abstract

公开了一种账户认证服务，其中在在线交易期间信用方为了申请者的利益查证帐户持有者的身份。账户认证包含请求帐户持有者的口令、查证该口令以及告知申请者该帐户持有者的认证是否已经得到查证。账户认证服务的可选用实施例包括增值部分，其中关于客户的信息是与增值方共享的。客户信息关于客户的细节是充足的，因为它是由账户认证过程中的各方收集的。增值方接着可以各种方式利用该信息。所涉及的所有当事人可受益于共享客户信息。增值方可能是比如商家、托运方、安全组织或政府组织。交易标识符识别客户、商家之间的特定交易以及客户信息。

Description

多方受益的在线认证服务

技术领域

本发明通常涉及在在线交易期间认证帐户持有者的身份，具体涉及与增值方一起共享和使用与认证过程有关的信息的技术。

背景技术

在使用支付卡(如信用卡、借记卡或储值卡)的支付交易期间，查证持卡者的帐户所有权以避免各种问题(如未授权使用)是重要的。支付者认证是查证持卡者的帐户所有权的过程。认证持卡者的帐户所有权的最常用的方法日常发生在被称之为“提交卡”交易期间的销售点处。提交卡交易包括商家代理收取持卡者的卡，将卡刷过支付卡终端以查证帐户状态和信用额度的有效性，而后核对检查卡背面的签名与购物者的签名相匹配。如果商家遵循这类交易的特定准则，则商家将被保证授权的较小折扣和费用支付量。服务提供商，如Visa国际服务协会(或服务组织)，可提供这些特定准则。

另一方面，“不提交卡”交易(如那些在线发生的、通过邮寄的、或通过电话的交易)包括未向商家保证的支付。提供未保证主要是因为在这种非面对面交易中未对支付者进行认证，从而使“不提交卡”交易伴随有许多的风险。这样的风险包括的问题比如对在线商家的支付交易的扣款、对商家和持卡者的欺诈行为、增加的银行例外项目处理开支、以及增加的在线购买货物和服务是不安全可靠的感觉，而这样的感觉使某些消费者避开在线购买。风险的具体实例包括未授权使用盗窃的帐户信息在线购买货物和服务、伪造卡帐号进行欺诈的在线购物、以及从网络流量中提取明文帐户信息。

考虑到持续的预计的电子商务的高增长的条件下，提供认证支付者的方法是很重要的。考虑到在线交易类型的广度，提供认证当事人身份的方法也是很重要的，不管交易是否存在有商业特点。这将使从持卡者、商家、金融机构到政府机构的所有交易参与者受益。在在线交易期间认证客户将减低欺诈、争议、补款和扣款的程度，这随后将降低与这些事件的每一个相关联的成本。认证客户还解决了安全问题并且因此将导致增加的在线活动。现有的用来在在线交易期间认证当事人的系统已经不再被广泛采用，因为这些系统难于使用、具有复杂的设计、要求系统参与者提前投入相当大的投资并且缺少互用性。某些现有系统另外要求商家、持卡者、发行机构和让受方的证书的创建、分发和使用。这种证书的使用已知是非常繁重的。

考虑到上述的观点，要继续努力提供用于认证在线交易中的客户身份的改进的系统。此外，还要继续努力便利地利用对包括在这样的认证过程中的当事人有用的信息。

发明内容

本发明的目的在于认证在线交易期间提交者身份的帐户认证服务。认证服务使信用方为了申请方(“申请者”)的利益能够利用各种认证方法(如口令或令牌)来查证帐户持有者的身份。在在线交易期间，认证帐户持有者的身份包括请求帐户持有者输入口令、查证口令、以及告知申请者是否帐户持有者的真实性已经得到查证。帐户认证服务的可选用实施例包括增值部分，其中关于客户的信息是与增值方共享的。客户信息关于客户的细节是充足的，因为它是由帐户认证过程中的各方收集的。增值方接着可以各种方式利用这个信息。所涉及的所有当事人可受益于共享客户信息，并且各方可在他们如何能够帮助彼此增值这点上达成一致。通过使用识别客户和商家之间特定交易以及客户信息的交易标识符，各方还可审计交易和与客户信息有关的任何协议。

作为一种方法，本发明的一个实施例包括至少接收来自提交者的身份认证口令并且将身份认证口令与以前为提交者的帐户指定的口令比较。该方法还包括在收自提交者的身份认证口令与以前为该帐户指定的口令匹配时，告知申请者该提交者是真实的帐户所有者。这样，信用方为了申请者的利益认证该提交者是真实的帐户所有者。该方法还包括向增值方发送提交者的信息。在某些实施例中，该方法还包括对照一组标准评价提交者的信息，并且如果提交者的信息满足该组标准则向增值方发送提交者的信息。这使增值方能够接收想要的客户信息。同样地，在将提交者的信息发送至增值方之前，申请者和增值方中的各方可能同意将一组权利和义务作为条件。另外，交易标识符可用来追踪个别的在线交易以及有关的客户信息。

在本发明的一个实施例中，申请者是商家并且增值方为可使用客户信息来运载从商家购买的产品的运送公司。客户信息帮助运送公司确定是否以及如何将产品运至客户。

在本发明的另外一个实施例中，申请者是商家并且增值方为可使用客户信息向客户销售其货物或服务的后继商家。客户信息帮助后继商家确定是否以及如何与客户通信。

在本发明的又一个实施例中，增值方是可使用客户信息来评价安全问题的安全组织。客户信息帮助安全组织确定是否以及如何解决可能的安全问题。

将在下面的本发明的说明以及附图中更详细地呈现本发明的这些和其它特征以及优点，本发明的说明以及附图通过举例的方式说明了本发明的原则。

附图说明

通过参考下面的描述并结合所采用的附图，可以更好地理解本发明连同其中其他的优点，其中：

图1说明了实现用于各类帐户认证应用的本发明帐户认证服务的系统体系结构的一个实施例。

图2示意性地说明了支持支付交易中本发明认证服务的系统体系结构的一个实施例。

图3说明了帐户持有者向按照本发明一个实施例的帐户认证系统注册的过程。

图4说明了其中在帐户认证系统登记过程期间帐户持有者可输入信息的互联网网页的一个实施例。

图5描述了帐户认证系统上的已认证的支付交易，其中帐户持有者使用了联入互联网的计算机。

图6说明了提示帐户持有者其口令的示范窗口。

图7说明了在支付交易期间被发送的示范的消息，所述的消息被添加到帐户认证系统上，其中帐户持有者使用了联入互联网的计算机。

图8说明了涉及包括有增值方面的在线帐户认证的一组消息流和示范的系统体系结构。

图9说明了适合于实现本发明实施例的远程通信网络。

图10说明了安放于交换中心以此提供在线和离线交易处理的系统。

图11说明的是远程通信网络组成部分的另一个视图。

图12A和12B说明了适合于实现本发明实施例的计算机系统。

具体实施方式

现在将参考如在附图中所说明的若干优选实施例对本发明进行详细地描述。在下面的描述中，提出了许多特定细节以便于提供对本发明的彻底的理解。然而，对本领域的技术人员来说显而易见的是，不具有这些特定细节的某些或全部，仍可实现本发明。在其它的示例中，为了不对本发明造成不必要的混淆，未曾详细描述公知的操作。

在图1中，该描述将首先给出按照本发明的通用的帐户认证系统和协议的综述。帐户认证系统是作为一种服务为参与的发行者、帐户持有者和商家设置的。接着，在图2-7中，描述了与在线支付交易有关的账户认证系统的实施例。在线支付交易的描述包含支付交易本身、系统设置、客户注册、以及特定消息流。在线支付交易的描述类似于非支付交易的描述。支付和非支付交易都包括帐户持有者身份的认证。

接着，在图8中，该说明描述了包括增值部分的帐户认证过程的实施例。通过首先与增值方共享关于客户的信息而使价值增加。客户信息关于客户的细节是充足的，因为它是由账户认证过程中的各方收集的。接着，增值方可以各种方式利用该信息。例如，接着增值方可向客户提供集中的信息或者将货物运至客户。所涉及的所有当事人可受益于共享客户信息，并且各方可在关于他们如何能够帮助彼此增值这点上达成一致。通过使用识别客户和商家之间特定交易以及客户信息的交易标识符，各方还可审计交易和与客户信息有关的任何协议。这个应用描述了这种信息共享如何能够便利地用于有利于各式各样的当事人的大范围的应用中。

帐户认证系统

帐户认证系统被设计成可在交易期间认证帐户持有者的帐户所有权，其中一方不能物理查证声称是特定帐户所有者的另一方的身份。例如，在信用方为了申请者的利益认证提交者的身份时，账户认证系统可用于各种交易。提交者是作为具有特定身份而提交自身的任何个人或实体。申请者是请求信用方认证提交者身份的任何个人或实体。信用方是能够认证提交者身份的并且是受提交者和申请者托付来实施认证过程的实体。信用方可同意在提交者身份有错误或有欺诈行为的情形下，保护申请者的利益。帐户认证系统的重要应用是在在线或便携式电子装置上发生的支付交易领域。

然而，除了支付交易之外，系统可能在许多应用中都是有用的。本发明的系统可用于其中客户的身份需要认证的各种非支付的情形。例如，非支付交易包括比如对访问互联网站点以此完成在线表单(如注册过程)的客户进行认证这样的交易。非支付交易还包括小额银行业务、大金额银行业务、医疗业务、保险业务、以及经纪人业务的许多方面，这里仅举出了几个例子。小额银行业务包括与卡(如借记卡、购物卡和储值卡)一起使用的帐号。非支付交易还包括针对比如身份证和执照这样的事情填写在线表单。例如，美国汽车协会(AAA)可使用该系统认证它的其中一个客户的身份或者电话卡公司可使用该系统认证特定卡的用户的身份。

图1说明了实现用于各类帐户认证应用的帐户认证系统的系统体系结构100的一个实施例。系统体系结构100包括三个域：信用方域103、互操作性域104、以及申请者域105。信用方和申请者域分别定义了功能领域，在所述的功能领域内是全部或至少部分由信用方或申请者控制的部分。互操作性域定义了功能领域，在所述的功能领域内是信用方、申请者、以及其他当事人(如服务组织)可利用的部分。

信用方域103包括主要由信用方控制的部分。信用方的实例是向客户发行支付卡的金融机构，称之为发卡银行。具体地，发行机构或发卡机构使得接收自卡的供应者的新卡个人化，而后将这些卡发给它的客户。个人化还可由卡的供应者或由私有化机构(personalization bureau)来实施。除了是金融机构外，发行机构还可以是任何适合的发行实体，如远程通信网络经营者、服务协会、商家或其他组织、乃至发行机构的代理商。申请者域105包括主要由申请者控制的部分。申请者可以是请求对帐户持有者身份进行认证的任何当事人。例如，申请者可以是期望认证声称是信用卡帐户所有者的某人身份的商家。收单方可以是登记支付方案中的申请者并管理申请者账户的金融机构。收单方还将信息从在线商家路由至远程通信网络。在其他实施例中，商家可直接将信息路由至远程通信网络。

互操作性域104可由互联网来支持，并且包括由信用方和申请者使用的部分。

信用方域103包括发行机构帐户持有者系统110、登记服务器112、访问控制服务器(ACS)114以及帐户持有者文件118。取决于系统将应用的特定领域，可将附加的部分包括在信用方域103内。例如，在下面的支付交易中，出于认证关于支付交易的帐户持有者身份的目的，在每个域中提供了附加的部分。

登记服务器112是借助于网络接口，通过提交将要由帐户持有者回答的并由信用方查证的一系列问题，来管理帐户持有者向账户认证系统进行登记的计算机。正如图1所示，信用方操作登记服务器112。然而，服务组织(如Visa)可以信用方的名义来操作登记服务器112。在登记过程中，信用方可使用由外部实体提供的激活网络的、交互式的“身份认证服务”以此帮助确认帐户持有者的身份。

ACS 114是具有注册了由账户认证系统提供的账户认证服务的帐户持有者的数据库的计算机。ACS 114包含每个帐户持有者的帐户和口令信息。在账户认证交易期间，ACS 114向认证申请者提供数字化签名收据、控制对账户认证系统的访问、并确认帐户持有者参与服务。发卡机构或服务组织(如Visa)可以为信用方操作ACS114。虽然账户认证服务不要求使用任何附加的帐户持有者软件，但是可使用可选的帐户持有者软件和硬件。附加的帐户持有者软件可支持附加的认证技术，如数字证书、集成电路卡(芯片卡)和芯片卡读卡器。值得注意的是，在本发明中，需要证书的唯一系统参与者是发行的金融机构。

帐户持有者文件118是用于存储与成功向账户认证系统登记的帐户持有者有关的信息的信用方管理的数据库。发行机构帐户持有者系统110(或信用方帐户持有者系统)由信用方控制，并包含关于帐户持有者的信息。这样的信息涉及账户信息、由帐户持有者使用的服务等。发行机构帐户持有者系统110中的某些信息可用于使帐户持有者登记进入账户认证服务。

申请者域105的申请者180通常期望对帐户持有者进行认证。当事人180管理有利于认证协议的请求插入式软件182。请求插入式软件模块182是被结合进第三方或申请者的网站的软件模块。插入式软件模块182提供了账户认证系统和申请者的处理软件(如商家的支付处理软件)之间的接口。

互操作性域104包含目录服务器128，由互联网支持，并且包括由信用方和申请者使用的部分。目录服务器128将认证请求从申请者路由至特定的ACS(如ACS114)。目录服务器128由卡方案管理者或服务组织(如Visa)来操作。互操作性域104还可由互联网之外的网络来支持。

用于支付交易的账户认证系统

现在将提供用于认证支付交易领域内的帐户持有者的系统体系结构的描述。值得注意的是，在这一部分中描述的许多通用的概念适用于各种应用领域，因为用于支付应用的认证过程类似于非支付应用。

支付交易中的认证系统和协议的示范用法描述如下。认证系统在帐户持有者在线购物、向“购物车”中添加项目、进入到在线商家的结账页并完成在线商家结账表单时的方案中是有用的。在客户决定购买其想要的产品或服务之后，例如在客户点击“购买”按钮之后，认证过程可发生。认证过程还可在客户支付交易中的其他不同时间开始。通过利用已经被结合进支付网络的若干点处的软件，认证过程主要以对客户来说透明的方式来进行。系统确认帐户持有者和帐户持有者所属的金融机构参与的认证服务。接着，创建窗口，在该窗口中客户通过请求来自帐户持有者以前所注册的口令可确认其身份。如果客户的身份被确认，支付信息和客户认证通知被发送回商家。接着，在便利实施时，支付交易由商家进行处理。例如，商家可将订单确认消息发送至帐户持有者的浏览器。

图2示意性地说明了支持支付交易中的认证服务的系统体系结构200的一个实施例。如同图1的通用系统体系结构100一样，体系结构200被分成三个域：发行机构域102、互操作性域104和收单方域106。图2的发行机构域102和收单方域106分别类似于图1的信用方域103和申请者域105。

发行机构域102包括登记站点108、发行机构帐户持有者系统110、帐户持有者客户装置122、登记服务器112、访问控制服务器(ACS)114、发行机构或申请者身份认证部分116和帐户持有者文件118。可选地，发行机构域102可包括核准帐户持有者120的发行机构文件。帐户持有者是提交者的另一个称谓，因为帐户持有者本身将作为一种特定身份来提供。登记服务器112是借助于网络接口通过提交将要由帐户持有者回答的并由发行机构查证的一系列问题来管理帐户持有者向账户认证系统登记的计算机。登记服务器112借助于互联网被连接到互联网支付网关服务124，其又被连接到远程通信网络126(如VisaNet)。互联网支付网关服务124使登记服务器112能够与远程通信网络126进行通信。借助于支付网关服务124的连接使登记服务器112能够询问发行机构的认证系统127，以此确定是否登记的帐户持有者具有有效的卡帐户。登记站点108是其中帐户持有者可注册参加由账户认证系统提供的账户认证服务的互联网站点。

帐户持有者客户装置122由帐户持有者用来加入帐户认证系统。具体地，帐户持有者客户装置122可以是能够访问互联网的任何装置，如个人电脑、移动电话、个人数字助理或交互式电缆电视。在某些实施例中，帐户持有者客户装置122不能连接到互联网上，然而这样的装置仍可被帐户持有者使用，因为客户装置122的输入和输出消息被路由过能够处理基于非互联网的消息的特定节点。例如，传输和接收以语音和/或文本消息为基础的消息的移动电话未连接到互联网，然而它们仍可通过以不同方式路由消息而与账户认证系统一起使用。短消息服务(SMS)是常用的通讯系统的实例。交互语音响应(IVR)单元可用于音频通道上的自动交换。这个消息路由布置将在下面的非互联网功能装置的部分中详细描述。

发行机构帐户持有者系统110是发行机构控制的系统，其包含了帐户持有者的信息。该系统信息包含了关于账户信息的信息、由帐户持有者利用的服务等信息。发行机构帐户持有者系统内的某些信息可用于帐户持有者向账户认证系统登记的过程。

发行机构或申请者身份认证数据库116包含发行机构或申请者已经具有存档相关帐户持有者的信息。数据库116被发行机构用于登记帐户持有者的过程以查证帐户持有者的身份。例如，在帐户持有者注册过程期间，由帐户持有者输入的信息应当与已经在认证数据库116中存档的信息匹配，以便于帐户持有者成功注册由账户认证系统提供的服务。第三方可以是比如Equifax这样的公司。

互操作性域104包括目录服务器128、认证历史服务器130和收据管理器131。目录服务器128将认证请求从商家路由至特定的ACS。目录服务器128由服务组织(如Visa)操作。认证历史服务器130和收据管理器131存储每项认证的支付交易的签名收据(如下面所描述的支付请求响应消息的副本)。认证历史服务器130包含了查证哪项交易被认证的信息，并在争议解决过程期间提供附加的信息。认证历史服务器130和收据管理器131由服务组织操作。发行机构、收单方、或商家还可保留数字化签名收据的副本。

收单方域106包括商家132和确认服务器136。MPI 134位于商家132的位置处。MPI 134是被结合进商家电子商务网站的软件模块。MPI 134提供了账户认证系统和商家支付处理软件之间的接口。

值得注意的是，MPI 134是与图1的请求插入式软件模块182相同的软件模块。“商家”的描述符用于MPI 134来表示正在使用插入式软件模块的申请方的类型。然而，应当理解，不管用来描述插入式软件模块134的形容词是怎样的，在整个说明中所描述的插入式软件模块基本上以相同的方式起作用。为了简化整个说明中术语的用法，“商家”的形容词将用来描述插入式软件模块。然而，这不应当被理解为将插入式软件模块134限制为唯一适用于为商家的申请方。此外，MPI将用作商家插入式软件模块的只取首字母的缩写词。

确认服务器136查证在支付交易期间用于签署由账户认证系统返回到商家的收据的卡发行机构的数字签名。在可选用的实施例中，确认服务器136的功能性可包括在MPI 134中，从而消除了对独立的确认服务器136的需要。确认服务器136由商家、收单方或服务组织操作。

在某些实施例中，帐户认证系统可同其他帐户持有者应用(如电子钱包)交互操作，并且服务可同电子商务标记语言(ECML软件)一起兼容操作。账户认证系统还提供了实现争议解决步骤的能力。例如，商家可保留充足的信息以此为了争议解决和扣款而提供帐户持有者认证的证据。

设置和注册说明

本描述现在将进一步提供用于设置支付和非支付交易的账户认证系统的细节。首先，将解释设置各个系统参与者以使他们可使用账户认证系统所需要的步骤。接着，解释帐户持有者向账户认证系统注册的过程。在描述过这些阶段之后，将提供有关实际的支付交易授权的解释。

设置账户认证系统包括针系统内所有参与者的设置步骤。对于支付和非支付交易的授权来说，设置步骤通常是相同的。这些参与者包括了比如商家或其他认证申请者、金融机构或其他信用方、以及帐户持有者这样的实体。

与账户认证系统签约的申请者(如在线商家)接受插入式软件模块，如图1的插入式软件模块128和图2的模块134。插入式软件模块对于由申请者使用的服务器软件和计算平台来说是特定的。参与账户认证系统的申请者(如金融机构)将提供他们的服务标识以及营销方案，以结合进他们的定制登记站点模板中。作为收单银行的第三方还应当向商家提供服务组织证明权限(CA)根凭证、客户认证的服务组织证明权限SSL证书和综合支持。

在设置信用方以使用账户认证系统之前，他们应当获得并安装在信用方域内指定的所有帐户认证系统硬件和软件的副本。信用方(如发行金融机构)还将向账户认证系统提供身份认证政策以及参与银行识别号(BIN)信息，用于账户持有者身份查证过程。可选地，发行机构可向账户认证系统提供账户持有者认证信息用于预载入账户持有者文件118。预载入促进了对账户持有者的大容量支持。例如，当信用方期望激活其所有或大部分的账户持有者的帐户认证服务时，信用方可向其所有的帐户持有者发送个人识别号码(PIN码)。PIN码接着可被每个帐户持有者使用以此访问他或她的预载入口令。如此，登记过程被加快，因为每个账户持有者不必经历正式的登记过程。在账户持有者首次使用其预载入口令之后，账户持有者具有指定新的和更易于记忆的口令的选择权。

账户持有者认证信息包括比如业务标识、国家代码、卡帐号、卡有效期、账户持有者名字、在“参与BIN”数据中指定的发行机构特定认证数据(如婚前姓)这样的信息，以及比如帐单地址、发货地址、社会保险号、电话号码、帐户余额、交易历史和司机驾照号码这样的其他信息。信用方还应当向目录服务器提供其卡帐户业务量的帐号范围以及ACS IP地址(URL)。至于账户认证系统的支付应用，可通过供帐户持有者注册用的、带有银行标记的网站提供服务。

图3说明了账户持有者向根据一个实施例的帐户认证系统注册的过程。如图所示，在步骤1中，账户持有者访问由信用方(如发行金融机构)维持的登记服务器互联网网站。账户持有者通过注册其帐号向帐户认证系统注册。例如，在支付交易的情况下，账户持有者可注册其信用卡、支票、或借记卡帐号。至于非支付交易，账户持有者可注册保险公司或经纪人公司同意的帐号。账户持有者可注册一个或多个卡。

在步骤2处，账户持有者输入比如主帐号(PAN)、名字和卡有效期这样的信息。在该点处，账户持有者还可输入附加信息。例如，还可输入地址、e-mail地址、购物者标识、账户确认值、账户持有者特定口令以及发行机构特定认证信息。可在如图4所示的页面300这样的登记网站页面上输入这个信息。

账户持有者在登记站点108上输入请求信息之后，账户认证系统查证账户持有者的PAN属于由信用方在互操作性域104的目录服务器128中注册的卡范围。可利用各种方法查证账户持有者身份。首先，正如刚刚提到的，可通过申请者认证数据库或通过信用方自己的认证数据库来查证账户持有者身份。另外，可通过使用由信用方提供的核准账户持有者120的文件、通过将状态检查授权传输到信用方以及通过比较对由金融机构提供的预载入信息的响应来实施确认。

如果PAN不在已登记卡范围内，则登记被拒绝并且登记过程终止。在支付交易中，如果PAN在已登记卡范围内，一美元(或其他任何标称量)的授权将通过服务组织支付网络(如VisaNet)被提交到发行金融机构。一美元交易的授权使发行机构能够查证卡帐户状态、使用地址确认服务的地址以及账户持有者确认值2(CVV2)。CVV2是打印在支付卡背面的签名条上的三位数字号码。在非支付交易中，如果PAN在已登记卡号范围内，则不需要一美元交易。

在步骤3处，账户持有者被提示附加的认证信息以此在交互的、实时的在线对话中查证账户持有者身份。在某些实施例中，在认证交易期间，还可要求账户持有者输入口令和用来认证账户持有者的“提示问题和回答”对。

如在步骤4中所示，当查证账户持有者的身份并且返回适当的响应时，授权消息被发送至发行金融机构。接着在步骤5处，登记服务器112将账户持有者信息传递至ACS 114以此建立账户持有者文件118中的记录。账户持有者文件118可存储比如金融机构BIN码、帐号、有效期、姓名、司机驾照号码、帐单地址、社会保险号、账户持有者口令、账户持有者口令问题、账户持有者口令答案、账户持有者email地址、申请者身份评分这样的信息以及其他信息。

在某些实施例中，在注册过程期间，可要求账户持有者输入可识别账户持有者的、被称之为个人安全消息(PAM)的短语。稍后，在认证过程期间，由信用方将PAM提交给账户持有者。因为只有信用方知道由账户持有者指定的PAM，所以可向账户持有者保证与账户认证系统一起使用的对话窗口是从信用方输送来的。PAM的实例是“天空是蓝色的”。

应当注意的是，账户持有者不需要新的客户软件或装置就可使用认证系统。在优选实施例中，账户持有者注册过程利用安全协议(如SSL通道加密)来保护在互联网上于账户持有者和登记服务器之间传输的数据。

同样地，在注册或登记过程期间，每个信用方可显示其自己的“使用条款”和/或“数据保密政策”。每个信用方能够要求注册账户持有者接受或拒绝条款或政策以便于完成注册过程。每个账户持有者接受的“使用条款”和/或“数据保密政策”的版本号应当由信用方保存。

支付交易描述

在设置了所有参与者并且注册了账户持有者之后，实施账户认证。图5描述了利用核心账户认证系统的已认证的支付交易，其中账户持有者使用了被连接到互联网的计算机。在图5的步骤1中，账户持有者访问互联网上商家的电子商务站点。账户持有者还可被称为持卡者，因为在支付交易中，账户持有者所持有的最常见类型的帐户将是某类信用卡、借记卡或支票保证卡账户。在账户持有者选择了他或她期望购买的产品或服务之后，账户持有者开始结帐过程，完成结帐表单，而后点击“购买”按钮。

在如图5所示的步骤2中选择“购买”按钮之后，MPI被激活并且接着实施确认过程来确定账户持有者的特定帐户是否向账户认证系统注册。存在有各种方法，据此MPI可确定账户持有者是否向账户认证系统注册。例如，可使用其中检查与帐户持有者相关联的目录服务器而后ACS的两步过程、其中只检查ACS的过程以及其中商家可检查包含有与目录服务器中存有的相同信息的高速缓冲存储器的方法。

现在将提供对两步过程的描述。在该描述过程期间将参考图2进行。在第一步骤中，MPI识别卡帐号并询问目录服务器128以查证帐号是在与作为账户认证系统的参与者的发卡银行相关联的帐号范围内。如果帐号不属于目录服务器128上所定义的帐号范围，则发行机构以及因此其账户持有者未注册。既然是这样，告知商家该账号未注册并且MPI 134将交易控制返回到商家店面软件。在该点处，商家店面软件可处理该交易，正常的做法是拒绝对账户持有者进一步的服务或者用可选用的支付方法处理。

另一方面，如果帐号被确定是在目录服务器128提交的帐号范围内，则确认过程的第二步骤开始。在目录服务器128将帐号发送至ACS以确定帐号是否已登记时，确认的第二步骤开始。如果该卡未登记过，则登记过程终止。如果ACS表示该卡已登记，则ACS借助于目录服务器将其URL互联网地址返回到MPI。MPI接着借助于帐户持有者客户装置和其驻留的浏览器来调用ACS。再次应当注意的是，在账户认证系统中可能存在有多个ACS。

检查账户持有者是否向账户认证系统注册的第二种方法是在没有首先询问目录服务器128的情形下MPI 134直接询问ACS 114。如上所述，第三种方法是用于具有包含了与目录服务器128中存有的相同信息的高速缓冲存储器的商家的。如此，商家可至少进行初步检查。

应当注意的是，在账户认证系统中可能存在有不止一个物理的目录服务器。然而，优选地，只有一个逻辑的目录服务器。换句话说，所有目录服务器应当是一致的，因为它们包含了相同的信息。

如果账户持有者是账户认证系统的参与者，则ACS 114向账户持有者显示带有银行标记的窗口。带有银行标记的窗口包含了基本的支付交易信息并向账户持有者提示其认证口令或令牌。参见图6的示范窗口500，其向账户持有者提示了他或她的认证口令。账户持有者输入其认证口令并且ACS 114查证认证口令。窗口500的大小和布局根据账户持有者使用的装置的参数来变化。正如今天所常见的，可以给予账户持有者一定次数的正确输入认证口令的机会。如果账户持有者不能正确输入认证口令的话，则可用账户持有者注册过程期间建立的提示问题来提示账户持有者。优选地，作为对提示问题的响应，给予账户持有者一次输入正确答案的机会。

如果直接输入了正确的认证口令或令牌或者账户持有者提供了提示问题的正确答案，则支付认证继续。接着，ACS进入到利用发行机构的签名密钥或服务提供商的密钥数字化签署收据。这个收据将包含商家名称、卡帐号、支付量以及支付日期。在某些实施例中，收据是支付认证响应(PARes)消息的副本或者具有至少某些从PARes消息中复制的消息字段的消息。认证历史服务器130存储下列交易数据：商家名称、商家URL、卡帐号、有效期、支付量、支付日期、发行机构支付签名以及账户持有者认证确认值。接着ACS通过账户持有者浏览器重新引导账户持有者返回到MPI。在该点处，ACS还将数字化签名的收据以及关于账户持有者是否已经过认证的确定传递至商家。在收单方域106中，确认服务器136由MPI 134用来查证用于签署支付收据的数字签名。在查证数字签名之后，账户持有者被认为“已认证”。在某些实施例中，在交易完成之后，账户持有者还将能够重新注册其卡帐户并创建新的口令用于将来的在线购物。

账户持有者在步骤3中被认证之后，步骤4启动授权特定账户持有者的账户的过程。授权指查证账户持有者具有足够的信用并且对于特定购物信誉良好的过程。相反地，认证指查证账户持有者身份的过程。在步骤4中，商家使用MPI将授权消息发送至支付网络(如VisaNet)。支付网络又将授权消息和电子商务指示符(ECI)发送至发行金融机构。授权消息是本领域公知的消息。授权消息被发送至发行机构，以使发行金融机构可向商家查证对于请求的支付交易的购物量来说特定帐号是信誉良好的并具有足够的信用额度。ECI表示交易在互联网上完成并表示消息安全等级(即在明文中，通道加密(SSL))和所用的认证。

在可选用实施例中，商家能够提供附加的消息连同授权消息。例如，还可发送下列信息：表示账户持有者是否已成功认证的标记、账户信息、数字签名、账户持有者确认值2、交易标识符、由芯片卡Europay、Mastercard和Visa(EMV)密码所认证的离线PIN、以及为商家提供保证支付的必要字段。在发行金融机构的授权交易处理完成后，接着借助于支付网络将支付交易的控制返回到商家店面软件。而后，发行机构借助于支付网络将授权响应返回到商家。在图5的步骤5中，发行金融机构将授权或拒绝交易。在某些实施例中，授权消息被分成批并在稍后的时间以组发送。认证信息也包括在批授权消息中。

交易标识符由认证账户持有者的ACS创建，并且对于给定的支付卡以及来自该卡的特定支付交易来说是唯一的值。发行机构出于各种目的(如在后来的争议发生时)使用交易标识符来唯一地识别已认证的支付交易。值得注意的是，交易标识符可表现为适合于唯一识别记录(如与特定在线交易有关的那些记录)的多种数据形式。在一些实际应用中(如支付交易)，交易标识符是卡认证确认值(CAVV)。在下面的描述中，交易标识符可被称为CAVV，然而，应该记住，还可使用各种类型的交易标识符。

访问控制服务器(ACS)114具有各种其它的功能。例如，ACS可使数据库中的已注册账户失效。可通过账户持有者或通过发行机构人工使账户失效。当账户持有者接收到替换卡时，ACS 114还可提供简化的更新注册过程。ACS 114可支持具有唯一访问控制信息的相同注册账户的多个用户。在为了支付交易或账户更新而向用户提供到ACS 114的连接时，ACS 114可通过一个或多个下面的机制确认用户为注册账户的授权账户持有者：口令短语、数字签名、在线PIN码、或/和芯片卡EMV密码的离线PIN认证。

商家132可与其中商家具有存档的账户持有者帐户信息的现有系统交互操作、可与现有商家授权和清算系统交互操作、支持向多个商家提供服务的第三方、支持商家和收单方之间的多种支付接口、以及在设置电子商务指示符(ECI)的值时将来自收单方的支付网络授权消息的强制性影响减至最小。

将交易从商家路由至ACS的一种方法是具有基于账户持有者帐号提供服务器地址的目录。在这样的方法中，路由信息的请求只能接受已认证商家的。在商家的活动超出正常活动时，则账户认证系统可否定对其收单方表示这样的访问不再有效的商家的访问。这可能是商家欺诈被认为是有可能的情形。可部署对账户认证系统的商家认证，但是这个部署不是必需的。商家认证可有助于将商家欺诈行为降至最少。

图7说明了在支付交易期间使用根据一个实施例的核心账户认证系统所发送的特定消息，其中客户使用了被连接到互联网的计算机。图7的消息被叠加到图2所示的支付系统结构体系上。应当理解的是，即使消息以及每条消息内的数据字段给定了特定名称，这些名称不会影响认证协议的执行。因此，可将不同的名称赋给下面讨论的消息和数据字段。还要注意的是，在本发明的可选用实施例中，可改变或省略图7中所描述的特定消息和/或在不影响认证过程总目的的情况下可添加附加的消息。出于各种目的(如添加功能性和使通信顺畅)，各种消息均可被改变、添加或省略。还要注意的是，在该说明所描述的过程中消息流在可选用实施例中由于比如刚刚描述过的那些原因是可改变的。

如上所述，在账户持有者借助于浏览器访问商家的网站并选择了购买项目时，支付交易开始。商家的支付系统将要求账户持有者输入其支付信息。一般地，支付信息的输入应当在安全环境下发生，例如，通过使用SSL加密协议。在账户持有者表示他或她准备完成交易时，商家的支付系统调用MPI 134。接着，如线1a所示，MPI 134检查目录服务器128的可包含账户持有者PAN的ACS的特定URL以此确认账户持有者在服务中已登记。或者，MPI 134检查其自有的、包含该信息的高速缓冲存储器。MPI 134还可检查ACS 114以此查证账户持有者的PAN被以账户认证系统登记。在MPI 134可检查其自有的高速缓冲存储器的情形下，MPI 134应当能够将目录128的内容复制进它的本地高速缓冲存储器中。如果这种能力被使用，则商家可立即从它的高速缓冲存储器中确定账户是否是注册范围的部分。如果商家实现了这种能力，则高速缓冲存储器的内容应当到期并且至少每24小时被更新。在载入MPI 134时并且在此后规则的时间间隔内载入时，应当请求高速缓冲存储器。

MPI 134通过使用账户持有者PAN格式化确认登记请求(VEReq)消息来搜寻PAN。如果还未建立，MPI 134将建立与目录服务器128或ACS 114的安全连接并向目录服务器128或ACS 114认证自身。MPI 134将搜寻对应于各种位置处的账户持有者PAN的卡范围输入。

在MPI 134进行搜寻之后，VEReq消息或如线1b所示直接被传输至ACS 114或如线1a所示首先经过目录服务器128之后被传输至ACS 114。在VEReq消息借助于目录服务器128被传输至ACS114时，目录服务器128搜寻与包含在VEReq消息内的账户持有者PAN对应的记录。在不成功匹配时，目录服务器128将格式化不具有URL值的确认登记响应(VERes)消息并且设置PAN登记的状态值或设置VERes-状态为“N”。接着将VERes消息返回到MPI。另一方面，在匹配成功时，如果还未建立的话，目录服务器128将建立与ACS URL的安全连接并认证自身到ACS URL。然后，VEReq消息被转发至ACS URL。如果该URL无效，则MPI应当进入到下一个ACS URL值(如果有效的话)并考虑将要搜寻最大到五个ACSURL。当然，所尝试的URL的数目是可变的。如果所有的尝试均未成功，则将VERes消息返回到MPI同时将VERes-状态设置为“N”，以此向商家表示利用账户认证系统未能使支付交易进行下去。

在ACS 114接收VEReq消息之后，ACS接受来自VEReq消息的账户持有者PAN并对照账户持有者文件118来确认它。而后，ACS 114格式化VERes消息。在成功匹配发生的情形下，ACS将PAN登记的状态设置为“Y”、创建ACS 114将与PAN内在关联的单用途代理PAN、并且将URL字段加入VEReq消息。在未成功匹配的情形下，ACS将PAN登记的状态设置为“N”。然后，如线2a所示，ACS使VERes消息经过目录服务器128返回到MPI。对于VEReq消息被直接传输到ACS的情形，如线2b所示，VERes消息被直接传回到MPI。

通过利用CRReq和CRRes消息对，可便于在MPI 134内高速缓存目录服务器128的数据。CRReq消息从MPI被发送至目录服务器并且请求参与的卡范围列表，以便于MPI更新其高速缓冲存储器。CRRes消息是包含参与范围的响应。

在某些实施例中，账户认证系统检查账户持有者客户装置是否通过使用QueryAccount holderReq和QueryAccount holderRes消息对已经分配了认证能力。MPI将格式化并发送询问、QueryAccountholderReq消息至账户持有者客户装置122，以此确定分配的账户认证账户持有者模块是否是驻留的。QueryAccount holderReq消息的发送在图7中由线3示出。如果在QueryAccount holderRes消息内任何分配的认证选项被返回，则MPI将直接与账户持有者客户软件进行通信以此实施认证的步骤。QueryAccount holderRes消息的发送在图7中由线4示出。另外，通过使用QueryAccount holderReq和QueryAccount holderRes消息，下面所描述的VEReq和VERes消息将被消除。可利用嵌入软件内的发行机构的ACS URL来部署账户持有者客户软件。MPI将首先完成QueryAccount holderReq和QueryAccount holderRes消息。如果探测到账户持有者客户软件，则在不必引导VEReq和VERes消息的情形下可将PAReq消息发送至ACS或账户持有者客户软件。

如果VERes-状态具有不等于“Y”的值，则告知商家利用账户认证系统使支付交易不能进行下去。然而，如果VERes-状态具有等于“Y”的值，则MPI 134将格式化支付者认证请求消息(PAReq)。如线5所示，MPI 134将借助于账户持有者客户装置浏览器将PAReq消息发送至发行机构的ACS服务器。

在MPI将PAReq消息传递至发行机构的ACS之后，ACS向账户持有者显示窗口。该窗口显示了包含在支付者认证响应(PARes)消息内的支付细节，除了其他项目之外还有比如：发行机构的标识、服务组织的标志或商标标识、商家的名称、商家的位置(URL)、总的购买量和货币、购买日期、卡号、分期支付/重复支付项目、订单描述或与描述的链接、特定项目以及销售状况或与该信息的链接、个人安全消息(PAM)、和账户持有者口令的提示或任何其他类型的认证令牌。

ACS接着将提示账户持有者输入适当的口令。ACS接受账户持有者的输入并对照账户持有者文件118来确认该输入。账户认证系统将允许比如若干次未成功的输入正确口令的尝试(如三次尝试)。当然，所允许的尝试次数是可改变的。在最后的不成功尝试之后，账户认证系统可显示提示问题。账户持有者将需要输入正确的提示问题的答案。接着，显示与账户持有者相关联的提示问题。向账户持有者提供至少一次输入正确答案的尝试机会。如果账户持有者提供了错误的答案，则可告知商家利用账户认证系统未能完成交易。如果账户持有者提供了正确的答案，则交易应当作为好像口令是匹配的情况来处理。值得注意的是，如果存在不止一个帐号输入，则不同账户持有者的名字将显示在下拉窗口中。账户持有者接着可选择其名字。

在口令匹配时，ACS生成并数字化地签署PARes消息。如线7所示，ACS还生成并发送SaveReceipt消息至认证历史服务器130和收据管理器131。如线7a所示，还可将SaveReceipt消息从认证历史服务器130传送至发行机构授权和结算系统138，以此允许发行机构能够实时地使支付授权请求与支付者已认证的交易相匹配。发送SaveReceipt消息至发行机构授权和结算系统138使发行机构能够同时确定授权请求是否是针对已认证购买的。如线6所示，ACS接着将重新引导已签名的PARes消息返回到MPI。

在已签名的PARes消息被传回到MPI 134之后，MPI 134被再次激活。如果认证状态为“Y”，则MPI 134将PARes消息发送至确认服务器136。在确认服务器功能是由MPI 134提供的情形下，MPI 134确认PARes消息签名并返回签名确认的结果。如果签名未被确认，则MPI 134将告知商家利用账户认证系统未能使交易进行下去。如果认证状态为“N”，则商家应当向账户持有者发送提示以请求附加的信息、请求账户持有者使用不同的支付卡或支付形式、或者按非认证支付交易来处理该支付交易。

在收单方域106包含确认服务器的情形下，确认服务器136确认PARes消息的签名。确认服务器136接着将签名确认的结果返回到MPI 134。如果签名未被确认，则MPI告知商家利用账户认证系统未能使交易进行下去。另一方面，如果签名被确认，则商家继续进行已认证的支付交易。如线6a所示，还可将PARes消息从商家传递至它的收单方支付处理器140。接着，可将PARes消息从收单方经过远程通信网络142传递至发行机构。因此，支付者认证结果作为标准支付授权过程的部分对发行机构来说是有用的。

现在将讨论与各种传输通道有关的安全问题。作为底线，所有传输通道优选地利用128-位SSL进行加密。账户持有者和商家之间的通道包括两个通道。商家应当保护在账户持有者通过使用从服务组织核准的认证中心获得的SSL证书输入支付信息时所使用的连接。商家还应当保护用来通过使用从服务组织核准的认证中心获得的SSL证书将PARes消息从账户持有者传输到MPI时所使用的连接。

账户持有者和ACS之间的通道应当通过使用从服务组织核准的认证中心获得的SSL证书由ACS来加密。该通道用于两个目的。首先将PAReq消息从MPI发送至ACS，其次将已签名的PARes消息从ACS发送至账户持有者。

账户持有者和登记服务器之间的通道应当通过使用从服务组织核准的认证中心获得的SSL证书由登记服务器来加密。该通道用来接受账户持有者登记信息。

商家和目录服务器之间的通道以及目录服务器和ACS服务器之间的通道应当通过服务组织发行的SSL加密证书来保护，以便于保护包含在VEReq和VERes消息内的PAN数据以及包含在VERes消息内的ACS URL地址。

ACS和账户持有者之间的通道应当被加密以此保护账户持有者口令的提示以及账户持有者输入的口令。该通道应当利用从服务组织核准的认证中心获得的SSL证书来保护。

对于大多数交易来说，支付认证请求和响应消息包括但不限于下列字段：消息的版本号、商家的标识符、商家的国家代码、订单号、购买日期、购买量、交易状态、以及购买项目和条件。同样地，QueryAccount holderRes消息通常包括但不限于比如下面的字段：消息的版本号、商家的名称、订单号、购买日期、购买量、卡的有效期和交易污点。这些消息可以是XML(可扩展标记语言)格式的。

在非购买认证交易中，支付认证请求、支付认证响应和QueryAccount holderRes消息可包括消息扩展字段。正如在本领域公知的，消息扩展字段为相对于扩展所附属的消息来定义附加要素的数据字段。这些附加的要素可用来进一步方便特定的交易，包括非支付交易。

具有增值部分的账户认证过程

图8说明了涉及包括了增值方面的在线账户认证的示范系统体系结构和一组消息流。增值方面涉及在具有增值方的账户认证过程中收集的共享信息。这样的信息涉及提交者，并且可由发行机构或信用方以及申请者来收集。提交者信息因为其高度完整性而具有价值，因为其充当了提交者122认证的基础。可用交易标识符来标记提交者信息，该交易标识符识别特定的在线交易并规定该信息源于本发明的认证过程。增值信息可由增值方196用于与运送、后继销售、安全检查以及工作流程管理有关的各种用途，这里仅列举了几个例子。所涉及的所有当事人可受益于共享提交者信息，并且各方可在关于他们如何能够帮助彼此增值这点上达成一致。例如，申请者和增值方可基于提交者信息的共享而在附加的合同条款上达成一致。

现在将参考图8来描述包括将提交者信息发送至增值方196的认证过程。图8将作为基于支付交易而被描述。在这样的描述之后，图8还将作为基于非支付交易而被描述。图8以简化的形式表示了图7的消息。

图8中账户认证系统体系结构包括发行机构域102、互操作性域104、收单方域106和增值域107。发行机构域102包括提交者122、ACS 114和发行机构190。提交者122代表了人类提交者和提交者客户装置(如计算机终端或移动计算装置)。发行机构190代表了能够向提交者122发行支付卡的发卡银行。互操作性域104包括Visa目录128，在这个实施例中，Visa目录128是由Visa、认证历史服务器130和VisaNet 194控制的目录。收单方域106包括申请者132、MPI 134和收单银行192。申请者132可以是各种类型的当事人，然而，因为申请者132通常是商家，术语商家可用来替代申请者。增值域107包括增值方196和增值控制服务器198。

图8的支付交易通过编号为1-14的方向箭头来描述。支付交易在步骤1处开始，此时提交者浏览商家的网站、将他或她期望购买的项目添加到购物车中而后结束购买。在该点处，商家132拥有包括PAN、到期日以及地址信息的必要数据，以此继续进行支付交易。

在步骤2处，MPI 134将提交者的主账号(和用户装置信息，如果适用的话)发送至Visa目录服务器128，以此检查提交者PAN是否向账户认证系统登记。这个过程发生在商家结账过程期间来自提交者的最终“购买”点击确认之后。在点击“购买”之后，商家的软件调用MPI 134来格式化查证登记请求(VEReq)消息。MPI 134确定其当前是否具有与Visa目录服务器128的安全连接。如果安全连接还未建立，则MPI 134建立与Visa目录服务器134的SSL连接。如果Visa目录服务器配置表示已经向商家132发行了SSL客户证书，则在SSL会话建立期间，Visa目录服务器128将请求商家132提交SSL客户证书。在安全连接已经建立之后，MPI 134将VEReq消息投递至Visa目录服务器128。值得注意的是，在各种实施利中，利用各种购买订单确认过程可完成“购买”点击确认。

VEReq消息连同认证期间发送的任何其他消息可包括表示在线认证过程还将涉及与增值方共享提交者信息的指示符。

在步骤3处，如果Visa目录服务器128确定PAN在参与的卡范围内，则Visa目录服务器128询问适当的ACS(如ACS 114)来确定认证(或认证尝试的证据)是否适用于PAN。这个过程在Visa目录服务器128接收来自MPI 134的VEReq消息之后发生。

为了使Visa目录服务器128查证PAN是在参与的卡范围内，Visa目录服务器128确认VEReq消息的句法，并且如果确认失败的话将错误返回。Visa目录服务器128确认VEReq消息数据以确保某些要求被满足。首先，收单方BIN应当代表参与的收单方。其次，商家ID应当代表由收单方BIN识别的收单方的参与商家。第三，如果收单方的Visa区域要求账户认证服务的商家口令，则口令值应当已经接收并且口令应当对收单方BIN和商家ID的组合是有效的。如果任何这些要求未被满足，则Visa目录服务器128格式化包括有设置为“N”的PAN认证可用和无效请求消息的查证登记响应(VERes)。值得注意的是，这个VERes不包含账户标识符、ACS URL和支付协议的数据字段。在Visa目录服务器128将VERes消息返回到MPI 134之后，支付交易可以多种方式进行下去。例如，支付交易可到达结束的终点，支付交易可作为非支付交易继续进行，或者提交者可尝试使用不同的账号。

Visa目录服务器128搜寻指定包括有在VERes消息中被接收的提交者PAN的卡范围的记录。如果未找到提交者PAN，则Visa目录服务器128格式化包括有设置为“N”的PAN认证可用但不包括账户标识符、ACS URL、支付协议和无效请求的数据字段的VERes消息。接着，Visa目录服务器128将VERes消息返回到MPI 134，并且账户认证再次达到如下所述的、可能的停止点。

假定在Visa目录服务器128中找到了提交者PAN，Visa目录服务器128确定其当前是否具有与适当的ACS的安全连接。如果安全连接还未建立，则Visa目录服务器128建立与ACS的SSL连接。在SSL会话建立期间，Visa目录服务器128的SSL客户证书和ACS的服务器证书应当被提交并被确认。如果第一URL尝试无效，则将尝试每个连续的URL值(如果提供的话)。Visa目录服务器128可尝试连接到可选地为每个ACS配置的多达四个预备的URL。如果在每次尝试时，Visa目录服务器128不能与URL连接，则Visa目录服务器128格式化包括有设置为“N”的PAN认证可用但不包括账户标识符、ACS URL、支付协议和无效请求的数据字段的VERes消息。接着，Visa目录服务器128将VERes消息返回到MPI 134并且将账户认证过程带到可能的停止点。

在成功地与URL建立连接之后，Visa目录服务器128将口令字段从VERes消息中移去并将该消息转发至ACS URL。

在步骤4处，ACS 114确定PAN认证是否有用，而后向Visa目录服务器128指示该确定。这个过程在ACS借助于Visa目录服务器128接收VEReq消息之后发生。ACS 114确认VEReq的句法并且如果确认失败的话将错误返回。值得注意的是，在不可能认证支付交易时，作为替代，有时能够提供认证尝试的证据。ACS 114使用来自VEReq消息的提交者PAN并询问位于ACS 114内的提交者数据库来确定提交者是否登记。如果未找到PAN，则ACS 114格式化包括有设置为“N”的PAN认证可用但不包括账户标识符、ACS URL、支付协议和无效请求的数据字段的VERes消息。ACS 114接着将VERes消息发送至Visa目录服务器128。

在步骤5处，Visa目录服务器128将ACS 114的决定转发至MPI 134。从Visa目录服务器128的观点看，该过程在Visa目录服务器128将VEReq消息转发至ACS URL之后发生。从ACS 114的观点看，该过程在ACS 114将VERes消息发送至Visa目录服务器128之后发生。

Visa目录服务器128读取VERes消息，该消息包含相应的VERes或错误值。Visa目录服务器128确认VERes消息的句法并且如果确认失败的话将错误返回到ACS 114。如果从ACS接收的消息在语句构成上是正确的，则Visa目录服务器128将VERes或错误转发至MPI 134。如果从ACS接收的消息在语句构成上是不正确的，则Visa目录服务器128格式化包括有设置为“N”的PAN认证可用但不包括账户标识符、ACS URL、支付协议和无效请求的VERes消息。Visa目录服务器128将VERes消息返回到MPI 132并且可能停止账户认证过程。从MPI 134的观点看，该过程在MPI 134将VEReq消息投递至Visa目录服务器128之后立刻发生。从Visa目录服务器128的观点看，该过程在Visa目录服务器128将VERes消息转发至MPI之后立刻发生。MPI 134读取响应，该响应包含相应的VERes或错误。如果错误消息被接收，则账户认证过程可能停止。

在因为各种上述的原因使账户认证可能结束的点处，商家可利用来自结帐过程的有用信息继续进行正常的支付授权。在这种情形下，商家支付系统应当作为超出本文件范围的未认证的电子商务交易来处理该交易。值得注意的是，电子商务指示符应当被设置成与认证结果和结帐过程的特征相应的值。如果在结帐过程期间商家不能使用由提交者选择的帐户来处理未认证的交易，则商家可放弃交易或者给予客户选择可替换帐户的选择权。如果选择了可替换帐户，则可重复认证过程。

在可选用的实施例中，对于每项支付交易，通过将Visa目录服务器的内容复制进商家132的本地高速缓冲存储装置，可避免需要询问Visa目录服务器以查证提交者在账户认证系统中的参与(步骤2-5)。如果这种能力被利用，商家132可立刻从高速缓冲存储器中确定账户是否是登记范围的部分。在商家132处使用本地高速缓冲存储器的这个可选用的技术从MPI 134格式化卡范围请求(CRReq)消息并将其发送至Visa目录服务器128开始。如果这是第一次高速缓冲存储器被加载(或者如果高速缓冲存储器已经被刷新并且需要重新加载)，则序列号要素不包括在CRReq中，其将导致Visa目录服务器128返回参与的卡范围的整个列表。另外，MPI134应当包括来自最近处理的CRRes的序列号，其将导致Visa目录服务器仅返回自以前的CRRes以来的变化。序列号是定义Visa目录服务器128的卡范围数据库的当前状态的值。Visa目录服务器128向MPI 134提供序列号。特定值仅仅对返回该值的特定Visa目录服务器有意义。

Visa目录服务器128确认CRReq的句法并且如果确认失败的话将错误返回。Visa目录服务器128格式化包含有参与范围的卡范围响应(CRRes)并将其发送至MPI 134。Visa目录服务器128包括该响应中的序列号。MPI 134应当保留具有第二天的CRReq消息的要被包括的该值。MPI 134确认CRRes的句法并且如果确认失败的话应当将错误发送至Visa目录服务器128。MPI 134更新其本地高速缓冲存储器。应当以返回的顺序来处理具有如由动作要素表示的添加或删除的范围的列表。值得注意的是，如果CRRes表示关于序列号的错误条件，MPI应当清除其高速缓冲存储器并提交不带序列号的CRReq。

在认证对提交者的PAN有效时，MPI 134借助于122处的提交者客户装置将支付者认证请求(PAReq)消息发送至ACS 114。步骤6表示PAReq消息被发送至提交者客户装置122。这个过程在MPI134接收来自Visa目录服务器128的VERes消息之后立即发生。MPI134确认VERes消息的句法并且如果确认失败的话应当将错误发送到Visa目录服务器。MPI 134格式化包括有在VERes中接收的账户标识符的PAReq消息。

认证过程的这个实施例包含了商家132和发行机构190之间的提交者相关的信息的共享。发行机构190和商家132的每一方可收集单项或多项交易中的大范围的关于提交者的信息。这样的信息可包括关于某一提交者的购物习惯的信息。这样的信息对各方(如商家132、发行机构190和增值方296)可能是有用的。在认证过程期间，通过在PAReq和PARes消息内包含这样信息，这样的客户信息可在商家132和发行机构190之间共享。因此，在步骤6处，商家132可包括在涉及提交者122的PAReq消息信息内。

MPI 134构建了包含下列字段的表单：PAReq、TermUrl(其为商家的URL，最后的答复应当被投递于此)以及MD(“商家数据”)字段。MD字段包含应当被返回商家的商家状态数据。这个字段用来提供不同方式商家系统操作对话状态。如果商家系统在无任何另外的协助的情形下，可使最后的投递与最初的购物对话相关联，则MD字段可以是空的。如果商家系统未维持给定的购物对话状态，则MD可携带商家需要继续对话的无论什么数据。因为该字段的内容根据商家的实际应用而改变，所以ACS应当使之保持不变并且没有关于该内容的假设。

通过使提交者浏览器将表单投递到ACS，MPI 134通过提交者的浏览器将PAReq传递至在VERes内接收的ACS URL。所有连接均为HTTPS以此适应提交者浏览器。

步骤7表示PAReq消息从提交者客户装置122被发送至ACS114。这个过程在ACS 114接收包括来自MPI 134的PAReq的邮件之后发生。下面的描述适用于其中利用口令实施提交者认证的情形。可使用其他的方法(如依赖于芯片卡上的应用的那些方法)。ACS114确认PAReq消息并且如果确认失败的话将错误返回。如果确认失败，则ACS 114格式化具有设置为“N”的交易状态和无效请求的PARes消息。

在步骤8中，ACS利用适用于PAN的过程来认证提交者。这些过程包括比如但不限于请求以前在发行机构190和提交者之间建立的口令或PAN，以及向提交者提交数据挑战这样的技术。例如，数据挑战可包含ACS 114请求提交者客户装置122提供将认证提交者或提交者客户装置122的身分的特定数据响应。在一种方案中，ACS 114可请求客户提交者装置创建将认证提交者122的特定密码。或者，ACS 114可产生认证尝试的证据。ACS 144接着格式化具有适当值的PARes消息，而后将数字签名施加于响应消息。ACS114对照位于ACS内的提交者数据库来确认口令、数据响应或密码。ACS 114还为每项在线交易生成交易标识符(如CAVV)。连同与特定在线交易相关联，交易标识符还与在商家132和发行机构190之间共享的客户信息相关联。

在步骤9处，ACS 114将PARes消息返回到提交者客户装置122。涉及提交者122的发行机构190维持的信息和交易标识符可被包含在PARes消息内发送至商家。

ACS 114构建包含有PARes和MD字段的表单。通过使提交者浏览器将表单投递至MPI，ACS 114将签名的PARes传过提交者浏览器送至商家的URL(来自MPI的邮件中的TermUrl)。在该过程中，弹出被关闭并且控制返回到商家浏览器窗口。

在这个时间点处，ACS 114还可将选择的数据发送至认证历史服务器130。例如，ACS 114格式化被发送至认证历史服务器130的支付者认证交易(PATransReq)消息。

在认证过程期间所持有的和/或所传输的提交者信息可由商家132和发行机构190的每一方来存储。各方可存储部分或其拥有的全部客户信息的集合。或者，可将部分或全部客户信息存储在认证服务器130中。

在步骤10处，提交者客户装置将PARes消息路由至MPI 134。

在步骤11处，MPI 134通过ACS 114确认放置在PARes消息上的数字签名。通过ACS 114本身或通过将PARes消息传送至独立的确认服务器，可实施数字化签名的确认。确认过程利用Visa根凭证来确认PARes签名。如果利用独立的确认服务器实现这一点，则MPI 134将PARes发送至确认过程，确认过程利用Visa根凭证来确认PARes上的签名，并且认证过程将签名确认的结果返回到MPI。

在步骤12处，商家132继续进行与收单方192之间的授权交换。

在步骤13处，商家132使用某一组标准来评价所拥有的客户信息。如果客户信息集合满足该标准，则客户信息和交易标识符被发送至增值方196。该标准可以围绕确定增值方196是否期望接收客户信息的各种问题来考虑。这样的标准将通过有关认证过程如何操作的更详细的实例来进行详细描述。

在步骤14处，增值方196将客户信息和交易标识符存进数据库，如增值控制服务器198。

步骤15表示可能因为各种目的而发生的增值控制服务器198和认证历史服务器130之间的往返通信。这样的目的包括比如推断商家132和增值方196之间的交易、争议解决和数据挖掘。

下面描述的部分将描述本发明各种增值实施例的另外的细节。

作为增值方的运送公司

现在将根据实施例描述图8所示的认证系统和过程，在该实施例中，增值方196是被称为托运方200a的运送公司(“托运方”)。在这个实施例中，提交者122从商家132手中购买需要运送到提交者居住地或其他邮寄地址的产品。被发送至托运方196的提交者或客户信息使托运方196能够将货物运至提交者122。如上所述。客户信息具有高度的完整性和丰富度，因为它来源于认证过程。因此，信息值成为商家132和增值方196的基础以此进入彼此交易。这些交易类型的范围可以大大改变。在一个示例中，托运方196依靠客户信息的完整性和丰富度到达如此的程度，即托运方196原意以更小的成本将产品运至商家132和提交者122。这可能是因为客户信息声明，提交者122从不要求将包裹送回至商家的情形。另外，商家132还可依靠这样的客户信息到达如此的程度，即托运方196舒适的是从涉及提交者122的回运请求的责任或代价中解脱出来。

认证和增值过程从图8所示的编号的步骤所描述的认证过程开始。在步骤6和7中，商家132可包括维持在被发送至发行机构190的PAReq消息中的客户信息。在步骤9和10中，发行机构190可包括发行机构190维持在被发送至商家132的PARes消息中的客户信息。发行机构190还产生交易标识符，其与特定的在线交易和客户信息相关联。

客户信息可以是比如：1)客户联系信息，如名字、邮寄地址、e-mail地址、电话号码和传真号码；2)客户支付历史，如全部付清的数量和拖欠支付的数量；以及3)运送历史，如优选的运送方法、在没有返回服务请求的情形下的装运次数和准时装运的次数。客户信息可包括由发行机构190和商家132收集的任何类型的信息。

还是在步骤9处，客户信息由商家132和发行机构190的一方或双方来存储。或者，客户信息被存储在数据库中，如认证历史服务器130。

在步骤13处，商家132对照某个标准评价客户信息以确定这样的信息是否应当被发送至托运方196。标准可用公式表示，以使如果客户信息表示比如托运方196可以没有困难地完成其任务，则将客户信息发送至托运方196。通过检查关于客户的有效历史信息，该标准有助于分析运至某一客户的风险。示范的标准包括：1)客户已经同商家进行了大于一定数量的购物交易了吗？2)装运地址是在某国家(比如美国)内吗？3)客户以前曾经未能支付购买吗？4)客户以前曾经请求过返回装运吗？5)客户是新客户吗？6)交易至少是某一货币量的吗？7)运送地址经过查证吗？以及8)运送的国家是低或高风险国家吗？商家132、托运方196或双方均可设置标准。

如果客户信息满足商家的标准，则客户信息和交易标识符被发送至托运方196。因为发行机构190生成了交易标识符，所以托运方196被保证信息的真实性。依赖于客户信息，在某种程度的装运无困难并且因此无额外费用的担保下，托运方196将产品运至客户122。由于客户信息所提供的对托运方196的无麻烦交易的担保，商家132和托运方196可相互提供额外需要考虑的事项。例如，托运方196可能原意以更小的成本将产品运至商家132和客户122。同样地，商家132可代表托运方196假设进行装运的某些风险或者商家132可同意部分补偿托运方196的运送成本。

在步骤14处，托运方196将客户信息连同交易标识符存进增值控制服务器198中。托运方196可利用打印在运送标签上的交易标识符将产品运至客户122。

步骤15包含因为各种目的取回交易标识符连同相关的客户信息。这样的目的包括但不限于推断商家132和增值方196之间的交易、争议解决和/或数据挖掘。交易标识符对应于特定的交易并且因此对于追踪每项交易的历史是有用的，以使发行机构190、商家132和增值方196可查证关于每项交易的信息。本发明还可使商家能够更好地保护自己免遭其中客户会辩解他或她未进行某次购买的购买欺诈行为。本发明还可使运送公司能够更好地保护自己免遭其中客户也许会虚伪地声明未接收到发送的货物的运送欺诈行为。

在“推”或“拉”的情形下，可从认证历史服务器(AHS)130中取回客户信息。“推”情形是其中事件期望要发生并且因此客户信息被推给接受者(即增值方196)的情形。“拉”情形是其中仅仅根据不规则发生的事件由接受者拉出客户信息的情形。例如，仅在需要对照存储在AHS 130内的客户信息和交易标识符进行确认的争议出现时，可拉出客户信息。

可从AHS 130中取回客户信息和交易标识符以此推断交易。这些交易是以共享客户信息为基础的，并且包括各方同意的附加项目。这些交易被称为增值交易，因为客户信息成为各方受益的附加交易的基础。例如，增值交易的一方可接受额外的业务机会、接受更有竞争力的货物或服务价钱、和/或接受更有利的合同条款。某些交易包括托运方196根据某些条款为商家132运载产品的协议。这样的条款可包括支付给商家132的更低的运送价钱和/或商家132承担的责任和风险。通过检查客户信息和交易标识符，商家132和托运方196可查证托运方196进行了某些装运。接着，比如，商家132向托运方196支付折扣的运送费用。在取回这样的信息是用于推断这样的交易的正规过程时，取回推断交易的客户信息和交易标识符为推交易。

客户信息和交易标识符还对争议解决情形是有用的。争议可出现在任何商家132、客户122和托运方196之间。通过利用来自AHS130的信息证明关于交易的事实可解决争议。在争议出现时，客户信息和交易标识符从存储这种信息的位置处被“拉出”。商家和托运方之间的争议可能涉及各方之间增值交易的履行。例如，运送服务支付上出现分歧时，商家132可使用这种信息来证明装运是托运方196在同意的和折扣的运送费用的基础上进行的。或者在客户抱怨比如运货未收到或者商品在运送期间被损坏时，托运方196可证明这种交易的责任由商家132来承担。在某些实例中，责任可由发行机构190来承担。

客户信息和交易标识符还可由商家132、发行机构190和托运方196中的每一个用于数据挖掘的目的。这些当事人的每一方通过他们的交易可获得关于特定客户的信息，对其进行分析以此确定这些客户的特点和癖好。这样的特点和癖好对各商家132、托运方196和发行机构190的销售目的是有用的。商家132可使用关于客户特点和癖好的信息来确定针对客户的未来的销售和市场策略。托运方196还可将这样的信息用于比如风险分析，以此确定在未遭遇困难的情形下将产品运至客户的可能性。发行机构190可使用这样的信息来确定向客户发行未来帐户的风险等级或者确定信用等级是否应当增加。

另外，信息可由任何一方用来确定关于任何另外当事人的特征。例如，托运方可确定加入与某一商家的协议是否将是明智的业务决策。为了实施这种分析，可分析客户信息以此确定商家的欺诈历史、扣款历史、其客户的装运的共同国家等。当这种信息表明与特定商家的交易通常是易于装运的，则商家可决定与这样的商家进行更多的业务。商家可分析这样的数据以此确定他们是否期望特定托运方满足其运送需求。例如，客户数据可表明哪些商家具有较高的交货成功率和按时交货评分。

在商家132和发行机构190的一方或双方持有客户信息的实施例中，可从各自实体取回客户信息和交易标识符。

在本发明的运送实际应用的可选用实施例中，商家132可将特定交易的客户数据和交易标识符的副本发送至多个托运方。因为客户数据来源于认证过程而具有高度的完整性，每个托运方196可能对实施交易运送感兴趣。每个托运方196可能感兴趣，因为客户信息的完整性确保了与交易相关的信息的真实性，如运送地址。更重要的是，因为客户信息在通过商家的标准之后被发送至每个托运方196，所以确保每个托运方196遭遇运送交易问题的低的可能性。在可选用实施例中，托运方196将至少了解到涉及特定交易的风险等级。而且，托运方196可能对运送用于交易的产品感兴趣，因为商家132或发行机构190可能已经同意承担与交易有关的风险成本。已经了解交易和客户之后，每个托运方196可接着向商家132报出其运送成本的出价。商家132可因此选择其中一个托运方196来运送产品。

作为增值方的后继商家

在图8所示的认证和信息共享过程的可选用实施例中，增值方196是后继商家196。在这个实施例中，本发明可增加后继商家196的收入机会，并且在某些情形下，可增加商家132和发行机构190的收入机会。后继商家196接收来自商家132的客户信息和交易标识符，并使用这样的信息将其自己的货物和/或服务销售给客户122。后继商家196可提供任何类型的货物或服务，但是它们可能多少与商家132销售的货物或服务有关。来自商家132的客户信息是有价值的，因为客户122很可能购买与商家132的交易主题有关的某些东西。商家132和后继商家196可互相基于客户信息加入各种协议。

这个过程还可从图8所示的编号的步骤所描述的认证过程开始。在步骤6、7、9和10中，商家132和后继商家196通过在如前所述的PAReq和PARes消息中包括这样的信息来共享关于客户122的信息。同样地，发行机构190产生交易标识符，其与特定的在线交易和客户信息相关联。客户信息和交易标识符还由发行机构190、商家132的各方来存储或者存储在单个数据库中，如认证历史服务器130。

在步骤13处，商家132评价客户信息以确定该信息和交易标识符是否应当被发送至后继商家196。这样的客户信息可能涉及比如客户花费的平均钱数、客户花费的最大数、客户什么时间进行购物、客户从谁那儿购买、客户把钱花在什么上、客户的性别以及客户的人口统计信息。应当理解，关于客户特征的分析范围是非常大的。如果客户信息通过了标准，则在步骤13中将该信息发送至后继商家196。

在步骤14处，在接收到客户信息和交易标识符时，后继商家196将客户数据和交易标识符存进其数据库中，如增值控制服务器198。此时，后继商家196可利用客户信息着手针对特定客户的销售策略。客户信息可告知后继商家196关于如何针对各种客户编制其销售策略。例如，关于客户花费在特定交易上的量的信息将告知后继商家196有关客户122可能感兴趣的货物或服务的价格水平。同样地，关于商家132销售的货物或服务的信息告知后继商家196有关客户122可能想购买的有关货物或服务的类型。例如，如果客户从商家132购买了CD播放器，则后继商家196可向客户122销售某种CD。这样的交易可被称为“互补商品”交易。其他互补商品包括比如无绳钻和可再充电电池、剃刀和剃刀刀片、以及割草机和化肥。

可根据来自后继商家196的协议支配客户信息的接收，以此向商家132和/或发行机构190提供由客户信息产生的后继商家196的任何销售百分比。这样的销售以及类似性质的销售被称为比如“提升销售”和“交叉销售”。正如可以想象的，可根据商家132和后继商家196之间的各种协议支配客户信息的接收。如上所述，客户信息是唯一对后继商家196有价值的，因为其在细节上是充足的并且具有高度完整性。客户信息在细节上是充足的，因为商家132和发行机构190的一方或双方已经对其进行收集。商家132和发行机构190的各方均处于独特的位置，以此收集某类关于客户的信息。最后，客户信息具有高度完整性，因为其通过了步骤1-12所描述的认证过程。

步骤15再次包含了为了各种目的而取回交易标识符连同相关联的客户信息，例如为了推断商家132和后继商家196之间的交易、争议解决、和/或数据挖掘的目的。步骤15可能要求推断商家132和后继商家196之间的协议，其中关于后继商家196销售的信息在向商家132发送后继销售的百分比之前被查证。例如，客户信息和交易识别符可由商家132或后继商家196取回以此查证后续销售是客户信息的结果。接着，根据这样的查证，货币量被发送至商家132。在这种情形下，客户信息可作为用于始终贯彻该协议的规则的业务过程被推给一个或两个商家，或者可以只在需要解决矛盾时拉出客户信息。

在争议解决方面，在任何的商家132、后继商家196或客户122之间存在争议的情形下，取回客户信息和交易识别符。由于商家132和后继商家196之间协议可能已经被违犯，可发生争议。再次，在商家132同意向后继商家196发送客户信息时，后继商家196可能被要求分享是从客户信息中得出的任何销售。接着，在关于后继商家196给商家132的支付发生争议时，可拉出客户信息。各方可匹配客户信息和交易标识符，以此查证后继商家196的某些销售是否是基于客户信息而完成的。

关于客户信息的某些协议可涉及发行机构190，其中发行机构190还可预期后继商家196所进行的任何销售的一部分。

客户信息还可用于数据挖掘目的，其中发行机构190、商家132和后继商家196的各方可获得对彼此和客户的了解。他们对客户信息的分析可告知各方将来彼此的交易是否将是有利的。

作为增值方的各种当事人

在账户认证和增值系统的可选用实施例中，各种类型的当事人可表现为客户122、商家132和增值方196的角色。客户122和商家132的角色可以是彼此在线互相作用的任何当事人，其中商家132要求客户身份的认证。可以想象其中商家132向客户122出售某类货物或服务的许多商业情形。然而，还可想象许多非商业情形。某些情形包含针对若干事情(如司机驾照、钓鱼许可证、建筑许可证、社会保险支付和学校班级注册)的在线注册。应当理解，其中当事人(如商家132)将要求另一当事人(如客户122)身份认证的情况。

由身份认证当事人(如商家132)评价的标准可能涉及各种类型的增值方196。标准通常将涉及增值方196是否将期望接收关于其身份已经由本发明认证的当事人(如客户122)的信息。在步骤13中被发送的客户信息可能涉及每个不同的增值方196。客户122申请司机驾照时，客户信息可涉及比如客户的驾驶纪录、所驾驶的汽车、驾驶程序和共同目的地。增值方196可以是期望向与驾驶有关的客户122销售货物或服务的任何当事人。例如，增值方196可以是烟雾检查公司、维修车间或汽车保险公司。在另外的实施例中，增值方196可以不销售与驾驶有关的任何东西。然而，增值方196仍然可能正在销售客户122可能感兴趣的货物或服务。例如，客户信息可揭示客户122驾驶某类汽车，并且因此客户122可能对某一类货物或服务感兴趣。可从客户信息中提取出各类关系，并且因此对增值方196是有用的。

在客户122获得钓鱼许可证时，增值方196可以是比如钓鱼用具商店、旅行社或服装店。此外，增值方196不必是直接与钓鱼有关的公司。发送至增值方196的客户信息可涉及客户关于钓鱼的喜好。由商家122评价的标准可确定客户122喜欢哪一类钓鱼用具、最喜欢哪种钓鱼方式、客户122喜欢去哪里钓鱼、以及客户122使用的服装种类。

同样出于工作流程的目的，可将客户信息发送至增值方。例如，在客户122向商家122申请建筑许可证或执照之后，有必要将客户信息发送至另一个政府机构获得下一步批准。例如，消防代表可能需要接收客户信息以便于在房屋建造期间安排消防安全检查。

商家122和增值方196的各方还可相互基于客户信息和交易标识符的共享而加入增值关系。

在某些实施例中，商家122可以向多个增值方发送客户信息和交易标识符。商家122可评价针对每类增值方196的不同的或相同的标准集合。每个增值方196接着将继续或并行或依次一个接一个地实施其任务。增值方196可实时地执行其相应的任务，以使客户122接收来自各增值方196的即刻通知或者可离线执行该任务。

如上所述，步骤15可用于推断任何商家132、增值方196和发行机构190之间的协议的各种目的。

作为增值方的安全组织

本发明的某些实施例可用于安全目的，如国家安全。在这样的实施例中，增值方196可以是负责检查有关安全事务的情报(数据)的政府机构或任何组织。商家132可以是与客户122进行在线交易的任何商业的、非商业的、政府的、或非政府机构。例如，商家可以是航空预定公司、硬件商店、化学品供应商、或飞行训练学校。值得注意的是，某些或全部客户信息的传输可由涉及私权或民事权利的法律来管制。

商家132对照与安全有关的标准来评价客户信息，并且在某一标准满足时向增值方196发送该信息连同交易标识符。例如，该标准可评价客户的购买项目、许可注册、旅行目的地、旅行的频率、以及其他与安全有关的事物。一旦接收客户信息和交易标识符，增值方196可实施其监视任务。

交易标识符对于证明客户信息是有用的，以使如果必要的话可精确追踪安全性能审计。这在比如政府制定的安全协议调查的情况中可能是必要的。尤其是，可能要求商家132证明他们正确地遵守了安全协议。在某些情形下，商家132要对法院指令的传票作出反应。在步骤15中，客户信息和交易标识符可从认证历史服务器130推或拉出。步骤15还可用于推断商家132、报告方和增值方196之间的协议。例如，商家132可接收用于报告有用信息的识别或信用。在利用交易标识符证明来源、日期和其他有关客户信息的细节之后，可接受这个信用。步骤15还可由各方用来从认证历史服务器130中拉出数据用于安全有关的事务的数据挖掘。因为客户信息由发行机构190和商家132收集，所以客户信息很可能在对于监视目的很有用的信息方面是充足的。

在某些实施例中，增值方196和商家132彼此实时地通信，以使增值方196在接收到客户信息之后可向商家132立即发送消息。如此，可采取即刻行动以解决或避免不想要的情形。

优选系统网络

图9说明了适合于实现本发明实施例的远程通信网络800。本发明可利用任何适当的远程通信网络并可包含接着在下面讨论的不同的硬件、不同的软件和/或不同的协议。下述的网络是图2的远程通信网络126的优选实施例。网络800是支持使用任何银行卡、旅行和娱乐卡以及其他私人标签和私人拥有的卡的购物和现金交易的全球远程通信网络。该网络还支持其他网络的ATM交易、使用纸质支票的交易、使用智能卡的交易以及使用其他金融工具的交易。

这些交易通过网络授权、清算和结算服务进行处理。授权在购物结束或付出现金之前发行机构批准或拒绝销售交易时发生。清算在交易从收单方传递至发行机构用于投递到客户帐户时发生。结算是计算和确定所有已被清算的交易的每个成员的净财务状况的过程。资金的实际交流是独立的过程。

交易可作为双消息或单消息交易被授权、清算和结算。双消息交易被发送两次一第一次发送的只是授权决策所需要的信息，稍后一次发送的是用于清算和结算的附加信息。单消息交易只为了授权而被发送一次并且同样包含清算和结算信息。一般地，授权、清算和结算都是在线发生的。

远程通信网络800的主要组成部分是交换中心802、访问点804、806和处理中心808、810。其他实体(如票据支付银行和申请者授权代理)也可通过访问点连接到网络。交换中心是可以位于世界任何地方的数据处理中心。在一个实施例中，有两个在美国，一个在英国，一个在日本。每个交换中心安放有实施网络交易处理的计算机系统。交换中心成为网络的远程通信设施的控制点，其包含了基于IBM SNA协议的卫星连接或高速租用线路。优选地，将交换中心连接到远程实体的线路820和822使用基于IBM SNA-LU0通信协议的卫星连接或专用的高带宽电话电路。利用任何适合的ISO8583标准的装备，在这些线路上发送消息。

访问点804或806通常是位于处理中心的小型计算机系统，处理中心在中心主机和交换中心之间进行接口。访问点便于消息和文件在主机和支持交易的授权、清算、结算的交换中心之间的传输。链接826和828通常是中心内的本地链接并使用中心所推荐的专用消息格式。

数据处理中心(如位于收单方、发行机构和其他实体内)安放有支持商家和业务点的处理系统，并且维持客户数据和开单系统。优选地，每个处理中心被链接到一个或两个交换中心。处理器被连接到最近的交换，并且如果网络遇到中断，则网络自动将交易路由至次级交换中心。每个交换中心还被链接至所有其他的交换中心。这个链接使处理中心能够通过一个或多个交换中心彼此通信。同样地，处理中心可通过交换中心访问其他程序的网络。另外，网络确保了所有链接具有多个备份。从网络的一点到另一点的连接通常不是固定链接；相反，在任何给定的传输时间，交换中心选择最可能的路径。在任何错误链接周围，重新路由自动发生。

图10说明了安放于交换中心的、提供在线和离线交易处理的系统840。对于双消息交易，授权系统842提供授权。系统842支持在线和离线功能，并且其文件包括内部系统表格、客户数据库和商家中心文件。系统842的在线功能支持双消息授权处理。这个处理包含路由、提交者和卡查证、替代处理和其他功能(如文件维护)。离线功能包括报告、开帐单、以及生成恢复公告。报告包括授权报告、例外文件和通知文件报告、POS报告和开帐单报告。从系统842到系统846的网桥使得使用系统842的成员与使用系统846的成员通信，并访问SMS网关到外部网络成为可能。

清算和结算系统844清算和结算以前授权的双消息交易。在全球基础上，一周工作六天，系统844收集财务或非财务信息并在成员之间分发报告。它还计算税、费用和结算总额并且产生报告以此帮助对帐。网桥构成了系统844处理中心和系统846处理中心之间的交换。

单消息系统846处理全部财务交易。系统846还可处理双消息授权和清算交易，并且利用网桥与系统842通信以及根据需要访问外部网络。系统846处理Visa、Plus Interlink和其他卡交易。SMS文件包含内部系统表格和提交者数据库，所述内部系统表格控制系统访问和处理，提交者数据库包含了用于PIN查证和替代处理授权的提交者数据的文件。系统846在线功能实施用于授权以及全部财务交易的实时提交者交易处理和例外处理。系统846还积累对帐和结算总额。系统846离线功能处理结算和资金转移请求并提供结算和活动报告。结算服务848将系统844和846的结算功能(包括Interlink)合并成针对所有产品和服务的单项服务。清算继续由系统844和系统846单独实施。

图11说明了远程通信网络800的组成部分的另一个视图。集成支付系统850是用于处理所有在线授权和财务请求交易的主要系统。系统850报告双消息和单消息处理。在两种情形下，结算独立发生。三个主要的软件部分是公用接口功能852、授权系统842和单消息系统846。

公用接口功能852确定在交换中心接收的每个消息所需要的处理。它基于消息来源(系统842、844或846)选择适当的路由、处理请求的类型以及处理网络。这个组成部分实施最初的消息编辑，并且在必要时解析消息以及确保内容符合基本消息构造规则。功能852将消息路由至它们的系统842或系统846目的地。

计算机系统实施例

图12A和12B说明了适合于实现本发明实施例的计算机系统900。图12A示出的是计算机系统的一个可能的物理形式。当然，计算机系统可具有许多物理形式，其范围从集成电路、电路印刷板和小巧的手握装置直到大型超级计算机。计算机系统900包括监视器902、显示器904、外壳906、盘驱动器908、键盘910以及鼠标912。盘914是计算机可读介质，用来向计算机系统900或从计算机系统900传输数据。

图12B是计算机系统900的框图的实例。附加到系统总线920的是大量的子系统。处理器922(还称为中央处理单元或CPU)耦合至包括存储器924的存储装置。存储器924包括随机存取存储器(RAM)和只读存储器(ROM)。正如本领域公知的，ROM表现为将数据和指令单方向地转移至CPU以及RAM通常用来在两个方向上转移数据和指令。这些类型的存储器都包括下述的任何适合的计算机可读介质。固定盘926还在两个方向上耦合至CPU 922；它提供了额外的数据存储容量并且还可包括下述的任何计算机可读介质。固定盘926可用来存储程序、数据和类似物，并且通常是比主要存储器更慢的次级存储介质(如硬盘)。将会意识到，在任何适当的情形下，保留在固定盘926内的信息可以标准方式作为虚拟内存被结合进存储器924。可移动盘914可采用下述的任何计算机可读介质的形式。

CPU922还耦合至多种输入/输出装置，如显示器904、键盘910、鼠标912和扬声器930。通常，输入/输出装置可以是下列任何装置：视频显示器、跟踪球、鼠标、键盘、麦克风、触敏显示器、传感器读卡器、磁带或纸带阅读器、输入板、输入笔、语音或手写体识别器、生物统计学阅读器、或其他计算机。利用网络接口940，CPU 922可选地耦合至另一台计算机或远程通信网络。利用这样的网络接口，预计在实施上述的方法步骤的过程中CPU可接收来自网络的信息或者可向网络输出信息。而且，本发明的方法实施例可单独在CPU 922上执行或者可在网络(如互联网)上和远程的、共享处理部分的CPU一起执行。

另外，本发明的实施例还涉及具有计算机可读介质的计算存储产品，所述计算机可读介质其上具有用于实施各种计算机实现的操作的计算机代码。介质和计算机代码可以是为了本发明的目的特别设计和构造的，或者它们可以是公知的类型并且对计算机软件领域的技术人员来说是可得到的。计算机可读介质的实例包括但不限于：磁介质(如硬盘、软盘和磁带)、光学介质(如CD-ROM和全息照相装置)、磁光介质(如光磁软盘)以及特别被配置成可存储和执行程序代码的硬件装置(如特定用途集成电路(ASIC)、可编程逻辑装置(PLD)和ROM、RAM装置)。计算机代码的实例包括比如由编译器产生的机器代码和包含由计算机利用解译器执行的高级代码的文件。

虽然已经通过优选实施例对本发明进行了描述，但是存在有属于本发明范围的变更、置换和等同物。应当注意的是，存在有许多实现本发明的方法和设备的可选用的方式。因此，根据申请者的意愿，后面所附的权利要求将被认为是包括了属于本发明真实精神和范围的所有这样的变更、置换和等同物。

Claims

1.一种用于增值方与在线认证系统进行相互作用的方法，其中提交者的身份在在线交易期间由信用方来认证，所述方法包含：

接收来自所述提交者的身份认证口令；

将所述身份认证口令与以前为所述提交者的帐户指定的口令进行比较；

在接收自所述提交者的所述身份认证口令与以前为所述账户指定的口令匹配时，告知申请者所述提交者是所述帐户的真实所有者，据此所述信用方为了所述申请者的利益认证所述提交者是所述帐户的真实所有者；以及

将提交者信息发送至所述增值方。

2.如权利要求1所述的方法，还包含：

对照一组标准来评价所述提交者信息，并且如果所述提交者信息满足所述组的标准，则将所述提交者信息发送至所述增值方。

3.如权利要求1-2中的一个所述的方法，还包含：

将支付认证请求消息从所述申请者发送至所述信用方，以此请求所述信用方认证所述提交者的所述身份。

4.如权利要求3所述的方法，其中所述支付认证请求消息包括由所述申请者维持的提交者信息。

5.如权利要求4所述的方法，还包含：

将支付认证响应消息从所述信用方发送至所述申请者。

6.如权利要求5所述的方法，其中所述支付认证响应消息包括由所述信用方维持的提交者信息。

7.如权利要求6所述的方法，还包含：

由所述信用方生成交易标识符，其中所述交易标识符与所述在线交易相关联并且与被发送至所述增值方的所述提交者信息相关联。

8.如权利要求2所述的方法，其中所述提交者信息包括描述所述在线交易主题的信息。

9.如权利要求8所述的方法，其中所述提交者信息还包括关于所述提交者的购买行为信息。

10.如权利要求2所述的方法，还包含：

在将提交者信息发送至增值方的操作之前，由所述申请者和所述增值方的各方同意一组权利和义务。

11.如权利要求10所述的方法，还包含：

在交换所述提交者信息中，将货币值从所述增值方转移至所述申请者。

12.如权利要求9所述的方法，还包含：

由所述增值方将与所述提交者信息有关的信息发送至所述提交者。

13.如权利要求7所述的方法，还包含：

将所述支付认证响应消息和所述交易标识符的副本发送至历史服务器以供存储。

14.如权利要求13所述的方法，还包含：

从所述历史服务器取回所述支付认证响应消息和所述交易标识符的副本；以及

查证所述交易标识符以此审计所述申请者和所述增值方之间的增值交易。

15.如权利要求14所述的方法，其中为了争议解决目的所述支付认证响应消息和所述交易标识符的副本由所述增值方取回，还包含：

将支付认证响应消息和交易标识符的所述副本发送至所述申请者以便于解决争议。

16.如权利要求13所述的方法，还包含：

分析所述提交者信息用于数据挖掘目的。

17.如权利要求1、2或4-16中的一个所述的方法，其中所述信用方是金融机构。

18.如权利要求1、2或4-16中的一个所述的方法，其中所述信用方维持所述客户的所述账户。

19.一种用于托运方与在线认证系统进行相互作用的方法，其中客户的身份在在线交易期间由信用方来认证，所述方法包含：

接收来自所述客户的身份认证口令；

将所述身份认证口令与以前为所述客户的帐户指定的口令进行比较；

在接收自所述客户的所述身份认证口令与以前为所述账户指定的口令匹配时，告知申请者所述客户是所述帐户的真实所有者，据此所述信用方为了所述申请者的利益认证所述客户是所述帐户的真实所有者；

将客户信息发送至所述托运方；以及

将购买的产品运至所述客户。

20.如权利要求19所述的方法，还包含：

对照一组标准来评价所述客户信息，并且如果所述客户信息满足所述组的标准，则将所述客户信息发送至所述托运方。

21.如权利要求20所述的方法，其中所述客户信息包括邮寄地址。

22.如权利要求19所述的方法，还包含：

从所述申请者和所述信用方收集所述客户信息。

23.如权利要求19-22中的一个所述的方法，还包含：

将支付认证请求消息从所述申请者发送至所述信用方，以此请求所述信用方认证所述客户的所述身份。

24.如权利要求23所述的方法，其中所述支付认证请求消息包括由所述申请者维持的客户信息。

25.如权利要求23所述的方法，还包含：

将支付认证响应消息从所述信用方发送至所述申请者。

26.如权利要求25所述的方法，其中所述支付认证响应消息包括由所述信用方维持的客户信息。

27.如权利要求25所述的方法，还包含：

由所述信用方生成交易标识符，其中所述交易标识符与所述在线交易相关联，并且与被发送至所述托运方的所述客户信息相关联。

28.如权利要求27所述的方法，其中如果所述托运方接收到所述交易标识符，则所述运送操作仅由所述托运方实施。

29.如权利要求28所述的方法，还包含：

在将提交者信息发送至所述托运方的操作之前，由所述申请者和托运方的各方同意一组权利和义务。

30.如权利要求28所述的方法，还包含：

在所述托运方接收所述客户信息和所述交易标识符时，以折扣价格生成运送发票。

31.如权利要求27所述的方法，还包含：

32.如权利要求31所述的方法，还包含：

查证所述交易标识符以此审计所述申请者和所述托运方之间的交易。

33.如权利要求19-22或24-32中的一个所述的方法，其中所述信用方是金融机构。

34.如权利要求19-22或24-32中的一个所述的方法，其中所述信用方维持所述客户的所述账户。

35.如权利要求19-22或24-32中的一个所述的方法，还包含：

由所述信用方生成交易标识符，其中所述交易标识符与所述在线交易相关联并且与所述客户信息相关联；

将所述客户信息和所述交易标识符发送至多个托运方；

接收来自至少某些所述托运方的运送价格报价；以及

基于所述价格报价选择托运方来运送所述购买的产品。

36.一种用于安全组织与在线认证系统进行相互作用的方法，其中提交者的身份在在线交易期间由信用方来认证，所述方法包含：

接收来自所述提交者的身份认证口令；

将提交者信息发送至所述安全组织；

37.如权利要求36所述的方法，还包含：

对照一组标准来评价所述提交者信息，并且如果所述提交者信息满足所述组的标准，则将所述提交者信息发送至所述安全组织，其中所述组的标准确定什么时候存在安全事务。

38.如权利要求36所述的方法，还包含：

将来自所述申请者的支付认证请求消息发送至所述信用方，以此请求所述信用方认证所述提交者的所述身份。

39.如权利要求38所述的方法，其中所述支付认证请求消息包括由所述申请者维持的提交者信息。

40.如权利要求39所述的方法，还包含：

将支付认证响应消息从所述信用方发送至所述申请者。

41.如权利要求40所述的方法，其中所述支付认证响应消息包括由所述信用方维持的提交者信息。

42.如权利要求41所述的方法，还包含：

由所述信用方生成交易标识符，其中所述交易标识符与所述在线交易相关联，并且与被发送至所述安全组织的所述提交者信息相关联。

43.如权利要求37所述的方法，其中所述提交者信息包括至少描述所述在线交易主题的信息。

44.如权利要求43所述的方法，其中所述提交者信息还包括关于所述提交者的购买行为信息。

45.如权利要求43所述的方法，还包含：

响应接收所述提交者信息，由所述安全组织对所述提交者实施安全检查。

46.如权利要求41所述的方法，还包含：

47.如权利要求41所述的方法，还包含：

为安全事务的证据，分析所述提交者信息。

48.如权利要求37所述的方法，还包含：

在将提交者信息发送至所述安全组织的操作之前，由所述申请者和安全组织各方同意一组权利和义务。

49.如权利要求47所述的方法，其中为了争议解决目的所述支付认证响应消息和所述交易标识符的副本由所述安全组织取回，还包含：

将支付认证响应消息和交易标识符的所述副本发送至所述申请者或所述安全组织，以便于解决争议。

50.如权利要求36-49中的一个所述的方法，其中所述信用方是金融机构。

51.如权利要求36-49中的一个所述的方法，其中所述信用方维持所述客户的所述账户。