多方受益的在线认证服务

技术领域

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

背景技术

在使用支付卡(如信用卡、借记卡或储值卡)的支付交易期间， 查证持卡者的帐户所有权以避免各种问题(如未授权使用)是重要 的。支付者认证是查证持卡者的帐户所有权的过程。认证持卡者的 帐户所有权的最常用的方法日常发生在被称之为“提交卡”交易期 间的销售点处。提交卡交易包括商家代理收取持卡者的卡，将卡刷 过支付卡终端以查证帐户状态和信用额度的有效性，而后核对检查 卡背面的签名与购物者的签名相匹配。如果商家遵循这类交易的特 定准则，则商家将被保证授权的较小折扣和费用支付量。服务提供 商，如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)可以为信用方操作ACS 114。虽然账户认证服务不要求使用任何附加的帐户持有者软件， 但是可使用可选的帐户持有者软件和硬件。附加的帐户持有者软件 可支持附加的认证技术，如数字证书、集成电路卡(芯片卡)和芯 片卡读卡器。值得注意的是，在本发明中，需要证书的唯一系统参 与者是发行的金融机构。

帐户持有者文件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被传输至ACS 114时，目录服务器128搜寻与包含在VEReq消息内的账户持有者 PAN对应的记录。在不成功匹配时，目录服务器128将格式化不具 有URL值的确认登记响应(VERes)消息并且设置PAN登记的状 态值或设置VERes-状态为“N”。接着将VERes消息返回到MPI。 另一方面，在匹配成功时，如果还未建立的话，目录服务器128将 建立与ACS URL的安全连接并认证自身到ACS URL。然后，VEReq 消息被转发至ACS URL。如果该URL无效，则MPI应当进入到下 一个ACS URL值(如果有效的话)并考虑将要搜寻最大到五个ACS URL。当然，所尝试的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将格式化并发送询问、QueryAccount holderReq消息至账户持有者客户装置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返回参与的卡范围的整个列表。另外，MPI 134应当包括来自最近处理的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。这个过程在MPI 134接收来自Visa目录服务器128的VERes消息之后立即发生。MPI 134确认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被发送至ACS 114。这个过程在ACS 114接收包括来自MPI 134的PAReq的邮件 之后发生。下面的描述适用于其中利用口令实施提交者认证的情 形。可使用其他的方法(如依赖于芯片卡上的应用的那些方法)。ACS 114确认PAReq消息并且如果确认失败的话将错误返回。如果确认 失败，则ACS 114格式化具有设置为“N”的交易状态和无效请求 的PARes消息。

在步骤8中，ACS利用适用于PAN的过程来认证提交者。这 些过程包括比如但不限于请求以前在发行机构190和提交者之间建 立的口令或PAN，以及向提交者提交数据挑战这样的技术。例如， 数据挑战可包含ACS 114请求提交者客户装置122提供将认证提交 者或提交者客户装置122的身分的特定数据响应。在一种方案中， ACS 114可请求客户提交者装置创建将认证提交者122的特定密 码。或者，ACS 114可产生认证尝试的证据。ACS 144接着格式化 具有适当值的PARes消息，而后将数字签名施加于响应消息。ACS 114对照位于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之间。通过利用来自AHS 130的信息证明关于交易的事实可解决争议。在争议出现时，客户 信息和交易标识符从存储这种信息的位置处被“拉出”。商家和托 运方之间的争议可能涉及各方之间增值交易的履行。例如，运送服 务支付上出现分歧时，商家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 通信协议的卫星连接或专用的高带宽电话电路。利用任何适合的ISO 8583标准的装备，在这些线路上发送消息。

访问点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装置)。计算机代码的实例包 括比如由编译器产生的机器代码和包含由计算机利用解译器执行的 高级代码的文件。

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