CN101233535A

CN101233535A - 通信系统

Info

Publication number: CN101233535A
Application number: CNA2006800277179A
Authority: CN
Inventors: 蔡慧娜; 西蒙·亚历山大·贝德斯; 大卫·罗克斯巴勒
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2005-07-29
Filing date: 2006-07-13
Publication date: 2008-07-30
Also published as: MY179126A

Abstract

本发明提供了通信系统。一种用于在通信系统中控制支付的方法包括以下步骤：在一个或更多个用户设备中设置服务代理；从所述一个用户设备或所述更多个用户设备中的一个用户设备访问服务供应商；从所述服务供应商选择要购买的产品；所述服务代理经由支付运营商从所述服务供应商接收支付请求；以及所述服务代理经由所述支付运营商向支付供应商发出支付授权。所述服务代理可以安装在各种用户设备中并且提供了从多个所述用户设备到所述支付系统的统一接口。所述服务代理还可以提供从多个所述用户设备到定购系统的统一接口。

Description

通信系统

技术领域

本发明涉及通信系统领域，更具体地涉及用于安排(arrange)商品或服务支付的通信系统。

背景技术

从事于电子商务的服务供应商试图经由诸如互联网的通信系统远程地向消费者销售服务、内容或其他产品。典型地，这种供应商包括网络运营商、数字内容零售商和非数字商品经销商；事实上包括任何许诺向消费者进行销售的公司。支付通常是通过支付供应商来安排的，支付供应商包括诸如PayPal^TM的组织、预付和后付网络账户和网银(onlinebanking)系统。

当今的电子商务支付系统局限于两种主要系统：

基于SIM的移动系统依赖于使用移动电话SIM卡应用来认证消费者并且还将消费者的身份(典型地为安全密钥的形式)传递给卖主(vendor)。随后卖主可以利用消费者的身份向支付供应商(典型地，限于一个支付供应商，通常是移动网络运营商)发出支付请求。随后支付请求经由支付供应商被发送回设备上的SIM卡应用，供消费者进行确认。这里适用的术语“消费者”和“用户”是等同的。

这种类型的机制依赖于使用基于SIM卡的认证来进行支付。因此，该系统仅可以用于使用基于SIM的系统(即，移动电话)进行支付。必须对移动设备进行特殊设计，以将基于SIM卡的应用链接到适当的浏览器系统。对于基于扩展性的系统来说重要的是，由于支付应用是硬编码在大量使用中的移动装置的SIM中的，所以升级该系统是非常困难的。这就造成升级变得昂贵，需要向所有移动电话用户重新发布SIM卡。

基于浏览器的支付系统依赖于使用网络浏览器来处理支付。它们广泛地使用cookie和HTTP重定向来进行支付。典型地，像Paypal^TM的系统使消费者能够浏览卖主的网站，选择要购买的物品，然后去“结账”。在结账时，卖主网站将消费者的浏览器重定向到由支付供应商运营的网站，该支付供应商随后请求对消费者身份进行认证。消费者在该支付供应商的网站上输入他们的安全凭证，如果满足的话，支付供应商就获取卖主的带有每件物品的完整发票。随后支付供应商对消费者的帐户进行记帐，或者使用像VISA或Mastercard的另选记帐机制。随后将记帐量(debited amount)减去支付供应商的利润而记入供应商帐户。

对于基于浏览器的支付系统，问题在于支付体验对消费者来说是不便的(clumsy)。由于需要重定向(从服务供应商到支付系统)并且浏览器中通常都有cookie限制，所以交易有可能失败：致使消费者不能肯定他们是否已经进行了支付。在许多情况下，一旦支付成功完成，消费者就不能返回到卖主网站的起始点。此外，在对网络浏览器进行常规使用的情况下，可能在支付时获得确认的过程中遇到困难，并且可以证明登录到支付系统的过程是冗长的。

在常规的基于浏览器的会话中，支付确认和认证阶段的网络错误可能导致购买和支付的失败，这种失败对于进行管理的贸易方(服务供应商和支付供应商)来说都是高代价的，并且使消费者困惑。

典型地，基于浏览器的支付系统需要支持多种系统，包括Microsoft^TMIE、Mozilla^TM、Netscape^TM、Firefox^TM、Openwave^TM、iMode^TM以及Nokia^TM。这些浏览器中的每一个都存在多个版本并且可以有许多可变的用户设置，这增加了复杂性并且可能造成无法进行成功的支付处理。典型地，基于浏览器的支付系统不能用在移动设备上，而基于SIM的支付系统不能用在诸如PC的其他设备上。

更严重的是，假冒卖主可以建立假冒支付(所谓的网络钓鱼(phising))站点，在这些站点中，不警惕的消费者可能被吸引而输入他们的凭证，这些凭证随后可能被用于支付欺诈。

通常，对于消费者来说，整个体验是迟缓、沉闷且不安全的，并且在无线网络接入的情况下，由于较高的误比特率而更容易失败。

发明内容

本发明的第一方面提供了一种用于安装在各种用户设备中的服务代理，所述用户设备被安排用于与包括一个或更多个远程服务供应商和一个或更多个远程支付供应商的支付系统进行通信，所述远程支付供应商用于提供从多个所述用户设备到所述支付系统的统一接口。根据第二方面，所述支付系统包括支付运营商。本发明还可以扩展到包括所述服务代理的通信系统。

本发明的另一方面提供了一种用于对一个或更多个用户设备、服务供应商以及支付供应商的交互进行控制的支付运营商，所述支付供应商用于对所述服务供应商提供的商品或服务的支付进行安排。

本发明的另一方面提供了一种用于在通信系统中控制支付的方法，该方法包括以下步骤：在一个或更多个用户设备中设置服务代理；从所述一个用户设备或所述更多个用户设备中的一个用户设备访问服务供应商；从所述服务供应商选择要购买的产品；所述服务代理经由支付运营商从所述服务供应商接收到支付请求；以及所述服务代理经由所述支付运营商向支付供应商发出支付授权。

本发明的另一方面提供了一种用于安装在各种用户通信设备中来提供与支付系统相关的多个所述用户通信设备的统一支付行为的服务代理。

本发明的另一方面提供了一种在通信系统中从服务供应商购买商品或服务的方法，该方法包括以下步骤：在用户设备上安装服务代理；所述服务代理将用户身份登记在支付运营商处并向所述支付运营商认证所述用户身份；所述服务代理经由所述用户设备上的客户机打开从所述用户设备到所述服务供应商的连接；以及向所述服务供应商识别所述用户和所述支付运营商；经由所述客户机进行浏览并从所述服务供应商选择服务；基于从所述服务供应商到所述支付运营商的支付请求在所述服务代理处从所述支付运营商接收支付确认请求；通过所述服务代理向所述支付运营商确认支付；以及从所述服务供应商接收所述商品或服务。

本发明的另一方面提供了一种用于对一个或更多个用户设备、服务供应商以及支付供应商的交互进行控制的支付运营商，所述支付供应商用于对所述服务供应商提供的商品或服务的支付进行安排，其中所述支付运营商包括：用于从服务供应商接收支付请求的装置；用于向用户设备发送支付确认请求和用于从所述用户设备接收响应的装置；用于将所述用户响应传送到支付供应商的装置；用于向所述服务供应商中的一个传送确认密钥以启动将商品或服务提供给所述用户的装置；用于将服务激活密钥从所述服务供应商中的一个传送到所述用户设备的装置。根据另一方面，所述支付运营商包括用于利用所述服务激活密钥生成服务确认密钥并将其传送到所述用户设备的装置。

本发明的另一方面提供了一种用于安装在各种用户设备中的服务代理，所述用户设备被安排用于与包括一个或更多个远程服务供应商和一个或更多个远程支付供应商的支付系统进行通信，所述远程支付供应商用于提供从多个所述用户设备到所述支付系统的统一接口；其中所述服务代理包括：功能激活装置，用于激活所述用户设备上的功能；其中所述功能激活装置被安排用来激活与所述服务供应商中的一个进行联系的功能；其中所述功能激活装置被安排用来激活从所述服务供应商中的一个下载内容的功能；服务激活装置，其包括用于从所述支付运营商接受服务激活密钥和用于转发所述服务激活密钥以启动服务交付的装置。

本发明的另一方面提供了一种用于在通信系统中控制支付的方法，该方法包括以下步骤：在一个或更多个用户设备中设置服务代理；从所述一个或更多个用户设备访问服务供应商；从所述服务供应商选择要购买的产品；所述服务代理经由支付运营商从所述服务供应商接收支付请求；以及所述服务代理经由所述支付运营商向支付供应商发出支付授权。根据另一方面，该方法包括以下步骤：从所述支付运营商接受服务激活密钥，并将所述服务激活密钥提供给所述用户，来提示所述用户将所述服务激活密钥发送到所述服务供应商中的一个从而启动服务交付。根据另一方面，该方法包括以下步骤：经由所述支付运营商从所述服务供应商中的一个接受支付请求并提示所述用户对所述请求采取行动。

根据另一方面，本发明提供了一种在通信系统中从服务供应商购买商品或服务的方法，该方法包括以下步骤：利用用户设备上的服务代理将用户身份登记在支付运营商处并向所述支付运营商认证所述用户身份；经由所述用户设备上的客户机打开从所述用户设备到所述服务供应商的连接；向所述服务供应商识别所述用户和所述支付运营商；经由所述客户机进行浏览并从所述服务供应商选择服务；基于从所述服务供应商到所述支付运营商的支付请求从所述支付运营商接收支付确认请求；向所述支付运营商确认支付；因此用户从所述服务供应商接收所述商品或服务。

本发明的另一方面提供了一种在通信系统中经由用户设备从服务供应商购买商品或服务的方法，该方法包括以下步骤：在支付运营商处从所述服务供应商接收支付请求；创建支付确认请求并将其发送给所述用户设备上的服务代理；获取存储在所述支付运营商处的用户偏好；以及根据所述偏好来处理所述支付请求。本发明的另一方面提供了以下步骤：根据所获取的用户偏好来阻止或允许服务供应商；根据所获取的用户偏好来识别不需要确认的支付；将所述支付确认请求发送给多个用户设备上的多个服务代理；将所述支付确认请求发送给从多个用户设备上的多个服务代理中选出的服务代理；基于所述服务代理提供给所述支付运营商的认证信息来选择所述服务代理；检测没有服务代理的用户设备、提示所述用户、从所述用户接收响应并响应于所述用户响应将服务代理下载到所述设备中；通知所述服务供应商需要服务交付确认，从所述服务供应商接收激活URL并将所述激活URL和服务确认密钥转发给所述服务代理；以及所述支付运营商据此从所述服务代理接收支付确认，检查所述支付确认，如果正确则根据所述支付请求代表所述消费者向所述服务供应商进行支付。

附图说明

为了帮助理解，下面将参照本发明的具体实施方式更详细地描述本发明。应该理解，只能描述有限数量的实施方式，而本发明并不旨在局限于所描述的实施方式，而应该与所附权利要求书限定的范围一致。

在附图中

图1示出了系统框图；

图2和3示出了消息序列图。

具体实施方式

图1示出了根据本发明第一方面的系统的框图。如图1中所示，每个用户通信设备上都安装了服务代理。这些设备可以包括一个或更多个移动电话、空中接口膝上型计算机或PDA、连接到电话线的台式计算机，或者经由移动电话网、常规有线电话网或以其他方式连接到诸如互联网的较大通信网络的其他处理设备。每个服务代理都与所述设备本地的客户机应用(浏览器等)进行通信并为用户处理支付交易。根据本发明的一个方面，用户设备直接与一个或更多个服务供应商进行通信，而所有支付交易都是经由远程、网络定位的支付运营商来处理的。为此，支付运营商要与服务供应商和支付供应商进行通信。尽管在图中未示出，但是在本发明的另一个方面中，服务代理可以被安排为代表用户直接与服务供应商和支付供应商进行交易。

服务代理是一种小应用，它可以以适合于安装在上面列出的多种范围的可编程用户设备上的一种或更多种形式而存在。服务代理用来将支付功能从运行在用户的设备上的常规客户机应用(例如处理、网站浏览、电子邮件、电话呼叫)中分离出来。这些功能的分离简化了消费者的浏览、支付以及购买对话，并解决了普遍的客户机应用问题(例如禁止弹出窗口的浏览器)。

服务代理一般为可安装的应用，它可以支持多个消费者对话(包括使消费者可以证明他们访问服务的身份的认证和使消费者能够确认购买的在线支付)并且可以达到向服务供应商进行支付的目的。

服务代理利用通用操作系统调用与其他基于客户机的应用(例如浏览器)进行通信。服务代理是利用适合于安装在多种范围的设备上的跨平台技术(如Java和“.Net”)的简单应用。例如，Java midlet利用传递统一资源定位符(URL-例如电话号码)的操作系统“平台请求”，设备操作系统将通过建立调用来响应该请求。另选的是，参数(URL)可以是使设备打开正确应用(例如邮件浏览器)的电子邮件地址。服务代理支持多种设备，并且作为可安装应用可以根据需要进行升级。

服务代理被实现为向支付运营商提供统一接口的应用，所述应用可以容易地安装到运行由Symbian^TM、Microsoft^TM开发的操作软件的移动通信设备和其他设备(包括移动电话、个人数字助理以及诸如个人计算机的固定通信设备)中。典型地，服务代理应用的安装可以经由移动电话网在空中进行、通过有线连接或者经由个人局域网(例如Bluetooth^TM)进行。

服务代理支持以下特征：

■认证

■客户机启动

■支付确认

■服务激活

认证功能使消费者能够向支付运营商认证服务代理。尽管认证典型地包括向支付运营商提供用户名(当事人)和密码(凭证)的服务代理，但是也可以包括其他机制，例如X.509证书。一旦用户被认证，支付运营商就能够为用户向供应商担保，不再需要用户方重复登录。对于用户希望以此方式使用的每个设备，都需要进行独立的认证。在个人设备(例如移动电话)的情况中，一旦用户登录到SA上，则依赖于正常的锁屏和PIN机制所提供的整体设备安全性，他们可以有效地登录数周。

服务代理提供了代表消费者打开客户机应用的功能。客户机启动(或激活)功能使服务代理能够用唯一的ID或令牌打开客户机(典型地为相同用户设备上的网页浏览器或另外的应用)。一旦消费者选择了服务供应商，就将唯一的令牌或ID从服务代理传递到客户机应用。在浏览器的情况下，可以将令牌/ID作为HTTP头部参数添加到服务供应商URL中。这种方法的好处在于隐藏的令牌(例如消费者的ID)可以被传递到客户机，然后被包含在客户机(浏览器)和服务供应商之间的后续对话中。当消费者访问每个服务供应商时，传统的基于浏览器的系统要求他们登录或以某种方式识别他们自己。倘若没有这种功能，消费者就必须在每次访问服务供应商时手动登录或者输入身份。

简单的URL的例子如下：

http://www.acme.com？id＝maisyT@serviceA.com

其中

1.“maisyT”是消费者的ID。

2.serviceA.com是支付运营商的名称。

另选URL的例子如下：

http://www.acme.com？id＝jkl6m83wr89d@serviceA.com

其中“jkl6m83wr89d”是可用来隐藏消费者的真实身份的唯一密钥。

安全密钥可以如下生成：

■服务代理可以在每次代理应用被打开时随机生成密钥。然后它可以使该唯一密钥与支付运营商同步；

■服务代理可以利用服务代理与支付运营商之间共享的算法来生成密钥，从而支付运营商自己可以生成相同的密钥；或者

■可能已经向服务代理提供了预先生成并在服务代理与支付运营商之间同步了的密钥候选列表(long list)。

其他应用可以按多种方式来使用该信息用户身份。服务供应商可以利用该信息来跟踪用户的行为，例如浏览动作或者在请求收费内容之前的用户交互。这使得可以维持与消费者进行的可识别会话，从而在进行购买时，不必提示消费者进行身份的认证。同样，可以利用跟踪来生成消费者行为的使用和浏览统计。于是，服务供应商可以依靠接收到的服务代理令牌/ID来识别服务代理和消费者。令牌或ID可以由服务代理本地生成，或者可以与支付运营商共同创建。

支付确认功能使服务代理能够提示用户对输入的支付请求作出动作。典型地，将通过可听见的信号、振动或视觉方法来通知用户支付需要确认。典型地，服务供应商的身份和各种所列项目(商品)、单价与总价的细节包含在呈现给消费者的支付请求中。同时，向用户呈现潜在的支付方法，例如Paypal、预付或后付电话帐号以及其他在线支付系统。消费者可以选择确认支付并选择支付方法。

服务激活功能使支付运营商能够将服务激活URL(来自于服务供应商)交付给服务代理。然后，服务代理随后可以提示消费者在浏览器或其它适当的客户机应用中打开所述URL。这促成了客户机与服务供应商的网站进行联系并对服务交付进行初始化。

服务激活URL的一个例子如下：

http://www.acme.com？activationCode＝09df0934mdf

其中“09df0934mdf”是服务供应商提供的激活码。

支付运营商可以将唯一的服务确认密钥添加到服务激活URL中。服务供应商可以从用来访问它的网站的URL中获取该唯一的密钥。所获取的密钥给出了服务供应商可以用来向支付运营商或消费者证实消费者访问过该服务的证据。

带有唯一密钥的服务激活URL的例子如下：

http://www.acme.com？activationCode＝09df0934mdf&deliveryConf＝kld f8934c

其中

1.“09df0934mdf”是服务供应商提供的激活码；

2.“kldf8934c”是支付运营商创建的唯一服务交付密钥。

支付运营商提供对来自服务供应商的支付请求进行处理的能力。支付运营商持有消费者支付偏好信息。偏好信息可用来自动阻止或允许服务供应商，而无需来自消费者的确认。在大多数情况下，支付运营商将请求消费者通过服务代理中的对话来确认支付。一旦被确认，支付运营商就代表消费者进行支付。支付运营商支持多种支付机制，从而隐藏了来自消费者和服务供应商的复杂性。在针对消费者的情况下，支付运营商存储了多个必要的URL和凭证，以使支付运营商能够经由多个支付供应商进行支付。支付运营商还为消费者的收据提供了单个存储库。

典型地，支付运营商将被实现为企业计算系统(例如支持网络服务、消息传递的Windows企业或J2EE计算组件)以及运行在一个或更多个计算设备上的数据库，并且支持以下特征：

■服务代理支付接口

■服务供应商支付接口

■支付处理引擎

■消费者支付基本信息(profile)

■服务交付确认

支付运营商支付接口使服务代理能够向支付处理引擎发送支付确认。支付处理引擎可以被实现为网络服务。

服务供应商支付接口提供了使服务供应商能够发出支付请求并激活服务的接口。该接口将被实现为如2.4.1节定义的网络服务。

支付处理引擎实现了从服务供应商接收支付请求的支付逻辑。然后，它对与服务代理、服务供应商以及支付系统的后续对话进行处理。支付处理引擎与消费者支付基本信息协同工作。

消费者支付基本信息被用来决定如何处理来自服务供应商的请求，即识别哪些支付需要确认。消费者支付基本信息将决定阻止它不想进行的支付；允许与用户的交互以允许用户作出决定，或者允许在不涉及用户的情况下自动确认支付。

服务交付确认功能被支持以减小在消费者和服务供应商之间出现争议的风险。在所有情况下，该机制都这样工作：停止向服务供应商进行最后支付，直到可以证明服务已经被交付。根据本发明的另外方面：

J2EE或Java 2平台(企业版)是广泛用于开发和运行分布式应用的编程平台，它很大程度上基于运行在应用服务器上的模块组件。Java EE包括几种API规范并且包括Servlet和几种网络服务技术。这使得开发者能够创建出可跨平台并且可升级(同时集成了遗留技术)的企业应用。Windows服务器系统提供了企业计算特征，例如编程模块、交易管理、数据库连接、网络服务、XML解析、虚拟主机(web hosting)、邮件(mall)和当前状态(presence)服务器等。

支付运营商是能够为多个服务代理支持支付对话并执行所需支付行为的单个组件。服务代理可以利用在客户机设备上可获得的常用网络服务工具包(toolkit)(例如Microsoft网络服务工具包、Java网络服务工具包、SOAP以及Apache AXIS)来与支付运营商进行通信。

在本发明的另一方面，在消费者所选的设备上没有安装服务代理的情况下，通过使消费者接收到包含URL的电子邮件、SMS或即时信息来提示消费者从支付运营商下载服务代理。在由于任何原因不能进行下载的情况下，可以为消费者提供另选的基于网络的接口，通过该接口将不会提供服务代理方法的所有优势。

这给用户带来了好得多的控制，清晰地表示了他们要买什么以及他们支付的实际量。如果消费者无意间选择了他们不希望购买的产品，则他们可以利用支付确认过程中的“拒绝”选项来终止支付进而终止购买。支付及之后的服务激活功能不干扰常用的浏览功能，使消费者可自由地进行浏览。

服务代理通过生成购买请求并作为应答处理从支付运营商接收到确认请求来与支付运营商进行交互。支付运营商检测购买请求并确保确认请求被发送到正确的服务代理。在大多数情况下，“正确的”SA将是生成请求的那个SA，但是如果该SA在支付处理期间不可获得时应该选择另一个SA。这是经由多个提供标准接口的设备访问消费者的另一个优势。

在本发明的一个方面，购买运营商将消息复制到多个服务代理中，以利用适当的安全措施更好地应对用户改变设备的可能性，以确保检测到消费者相同的支付确认了两次的情形。根据另一方面，向优选的服务代理发送该请求，但是如果在设定的时间段(如30秒)内没有响应，则向其他服务代理发送确认请求。

当服务代理向支付运营商进行登记和认证时，它可以使用各种端点寻址系统。选择取决于所期望的通信系统开放性，即实施者选择了公共寻址系统(例如SIP)还是使用私有系统。例如，如果使用SIP-Simple消息收发来实现系统，则服务代理将自身登记在位于支付运营商处的SIP代理服务器中。SIP代理服务器实际上使用来自SIP登记的IP&端口号，从而它可以与服务代理进行联系。尽管SIP可以支持TCP，但是它通常登记UDP端口。

针对服务代理的SIP地址的一个例子包括SIP URL，例如：

sip://hjkroi34h34@service-agent.com

其中：

“hjkroi34h34”是与服务代理相关联的唯一登记密钥的例子。服务代理的SIP栈将监听用于从支付运营商输入消息的特定端口。典型的端口号位于5060以上的范围内。通常，IP和端口号将在登记消息中被传送到支付运营商中的SIP代理服务器。

一种另选方案是例如开发一种登记IP地址或端口的私有系统。类似于SIP登记，使用了具有对于服务代理唯一的密钥(例如“hjkroi34h34”)的XML登记消息。由于伴随网络地址转换的问题和移动网络中的防火墙问题，看上去可取的是，服务代理登记并维持与支付运营商的TCP连接。支付运营商在数据库中保持了指向TCP连接的句柄以及唯一服务代理密钥。这类似于当今用于即时消息传送系统中的系统，例如Yahoo、AIM以及Jabber。

服务代理模型仅需要支付运营商提供单个接口。典型地，支付运营商将利用常规机制(例如WSDL或网页)来宣传单个网络服务。所述网络服务监听IP地址和端口并且可以一次接受许多请求。在缓和极端需求的情况下，支付运营商可以使用TCP/Web负载平衡器的标准网络实践，所述平衡器将网络服务请求分洒(spray)到许多网络服务服务器上。多个网络服务服务器主机导致多个支付运营商实例。

尽管支付运营商要处理的各种服务代理的实现可能不同，根据需要适应不同的消费者设备，但是它无需处理多个客户机行为，而仅仅需要支持所述单个、统一的代理服务接口行为。支付运营商提供了简单的网络服务，所述网络服务支持XML文档的交换或曝光使用诸如SOAP的机制的远程过程调用。

服务供应商需要能够确定消费者的身份。服务供应商将看到正常的消费者浏览，而对于支付来说将与支付运营商进行交易。典型地，服务供应商通过初始地向支付运营商发送服务激活URL来交付内容。该URL被传送到服务代理，然后服务代理打开浏览器应用来访问服务。这些都是服务供应商的标准功能，实际上，所有服务供应商都非常善于应对各种支付和交付系统。

■支付逻辑

■身份提取器

■确认提取器

■服务

服务供应商可随意使用他们已有的互联网风格的交付系统，例如MMS、网络下载、媒体流或空中规定(air provision)上的开放移动联盟，他们仅需要提供这里描述的基本功能。典型地，服务供应商针对每个销售渠道/伙伴具有一组这样的功能，因此将能够容易地提供一种额外功能集。

支付逻辑与服务供应商的访问控制机制协同工作，以确定支付请求是何时以及如何作出的。

身份提取器功能被设计为提取身份/令牌，并且在HTTP/HTML会话的情况下应用它作出响应以维持会话。

确认提取器功能被设计为提取所述唯一确认令牌，所述唯一确认令牌被应用于跟踪消费者是否已经尝试过访问该服务。典型地，该功能将从HTTP中移除所述唯一令牌。一旦被服务供应商提取，所述唯一令牌就被应用回支付运营商来完成支付处理。

服务是内容或网络服务本身，例如待售的产品。

到其他组件的连接。

服务代理通过使用包括网络服务和专有消息传送系统的机制进行的远程过程调用和XML消息传送来与支付运营商进行通信。合适的专有消息传送系统可以使用Jabber协议或TCP套接字来交换消息。合适的标准消息传送系统可以包括SIP-Simple或JMS。

XML文档在服务代理和支付运营商之间流动。这些文档可以被封装到SOAP封包(envelope)内，并且可以使用SOAP RPC或者经由消息传送机制(例如SIP、MMS、JMS以及TCP)或专有系统被发送。典型地，使用SSL或VPN技术对链路进行加密。

可以将支付请求确认从支付运营商发送到服务代理，如下面的XML代码所示：

<？Xml version＝″1.0″encoding＝″ISO-8859-1″？>

<SAtransactionlD>hjkfd8934</>

<name>My Mobile Shop</name>

<url>http://www.mymobileshop.com</url>

</serviceproviderName>

<item>

<name>Advanced Java for Mobile Devices</name>

<description>A best-seller the world over</description>

<type>Non-Digital</type>

<image>http://www.mymobileshop.com/imageslbookl.gif</image>

</item>

<item>

<name>Cadbury Easter Egg</name>

<description>A perfect gift for Easter</description>

<type>Non-Digital</type>

<image>http://www.mymobileshop.com/images/food1.gif</mage>

</item>

<total>

<total>

<name>PayPal</>

</paymentmethod>

</paymentmethod>

</paymentrequestconfirmation>

其中：

■SAtransactionID是支付运营商创建的全球交易ID。

■item是各个所列项目。

■total是总支付量。

■paymentmethod是可接受的支付方法。

可以使用类似的机制将响应从服务代理发送回支付运营商，如下面的XML代码所示：

<？xml version＝″1.0″encoding＝″ISO-8859-1″？>

<SAtransactionID>hjkfd8834</>

<confirm>accept</>

</paymentmethod>

</paymentconfirmationresponse>

其中：

■SAtransactionlD是全球交易ID

■confirm是用于确认支付的关键词

■paymentmethod是建议的支付方法

可以将服务激活URL从支付运营商交付到服务代理，如下面的XML代码所示：

<？xml version＝″1.0″encoding＝″ISO-8859-1″？>

<SAtransactionID>hjkfd8934</>

<url>http://www.acme.com？activationCode＝09df0934mdf&</>

</serviceactivation>

其中：

■SAtransactionID是全球交易ID

■url是供消费者访问内容的唯一URL

■serviceDeliveryConfirmationKey是支付运营商验证用户已经访问过服务而创建的密钥

这将导致客户机应用浏览器打开：

http://www.acme.com？activationCode＝09df0934mdf&deliveryConf＝kld f8934c

服务代理通过操作系统调用或通过TCP套接字与客户机应用进行通信。

在内容交付机制支持嵌入式交付确认的情况下，由支付运营商执行交付确认。这是通过服务供应商对确认请求进行编码以包含支付运营商的URL并包含交易的细节而实现的。最后的支付执行不被执行，直到确认到达为止。

在数字内容的超级分发(super distribution)的情况(即数字版权被分开交付给媒体，例如媒体在没有安全性的情况下被交付但是保留为不可用，直到提供了分开的版权激活码为止)下，服务供应商可以请求支付运营商充当版权和确认服务的交付代理。一旦数字版权被交付，就可以进行支付。

在网络服务的情况下并且对于某些内容服务来说，服务供应商可以请求支付运营商转发服务初始URL。支付运营商将唯一确认ID添加到URL中并将其转发给消费者的服务代理。服务代理在浏览器中打开经编码的URL并连接到服务供应商。一旦服务供应商接收到了服务初始请求，就可以提取该唯一确认ID并作为服务已经被交付的证据呈现给支付运营商(在后面的“操作模式”说明中详述这种机制)。

服务供应商经由使用包括网络服务和专有消息传送系统的机制进行的远程过程调用和XML消息传送来与支付运营商进行通信。参见前面的描述。

XML文档在服务供应商和支付运营商之间流动。这些文档可以被封装到SOAP封包内，并且可以使用SOAP RPC或者经由消息传送机制(例如SIP、MMS、JMS以及TCP)或专有系统被发送。典型地，使用SSL或VPN技术对链路进行加密。

诸如paymentrequestconfirmation和serviceactivation的服务供应商消息等同于服务代理消息paymentrequestconfirmation和serviceactivation。它们的细微差别例如为：

■paymentrequest消息不使用SAtransactionID。

■paymentrequest消息使用额外字段serviceProviderUniqueId来将服务代理SAtransactionID和它们自己的内部处理绑在一起。

■serviceactivation消息不使用serviceDeliveryConfirmationKey。

唯一消息是如下的支付响应：

<？xml version＝″1.0″encoding＝″ISO-8859-1″？>

<SAtransactionID>hjkfd8934</>

<confirm>accept</>

</paymentmethod>

</paymentresponse>

其中：

■serviceProviderUniqueId是在原始paymentrequest中传送的唯一ID。

■SAtransactionID是全球交易ID。

■paymentmethod是建议的支付方法

操作模式

现在将参照图2来描述未经服务交付确认的支付消息序列。消费者访问存储在服务代理中的服务供应商的细节。为了联系上服务供应商，服务代理获取令牌并创建诸如http://www.acme.com？id＝ maisyT@serviceA.com的URL。客户机打开到服务供应商的连接。服务供应商接收请求。消费者可以通过客户机浏览器来浏览服务。服务供应商通过所提供的ID来维持会话。在购买时，消费者选择服务。如果令牌/ID初始时未提供或者不可获得，则可以提示消费者添加他们的细节。

服务供应商将支付请求发送到支付运营商；支付运营商处的支付处理引擎获取消费者的支付偏好，创建支付确认请求并将其发送给消费者的服务代理。如果消费者已经访问了一个以上的设备，则支付运营商可以(例如从之前的认证信息)推测出服务代理的选择。

由支付运营商进行最后的支付执行(即与支付供应商的支付的安排和完成)，并且通知服务供应商。就此，服务供应商可以使用服务激活功能向消费者发送激活消息。服务激活消息通过服务激活接口被交付到服务代理。(消费者控制下的)服务代理打开客户机应用来访问服务。

现在将参照图3来描述经服务交付确认的支付消息序列。支付运营商通知服务供应商需要服务交付确认。服务供应商经由支付运营商来发送激活URL。支付运营商将激活URL和服务确认密钥发送给服务代理。服务代理打开将请求发送到服务供应商的客户机应用。服务供应商提取交付确认密钥并向支付运营商发送服务交付确认消息(包含该密钥)。支付运营商检查该密钥，如果正确则代表消费者按照请求向服务供应商进行支付。

支付运营商在用户的设备(可能为多个)、多个服务供应商以及各种支付系统之间提供单个、统一的接口。

服务代理向支付运营商提供统一的接口；包含嵌入在各种用户设备中的多种类似功能，从而降低了支付运营商的复杂性；在客户机启动的情况下，对支付确认和服务激活(从常用的基于浏览器的会话中移除的功能)进行处理。

该系统使服务供应商能够通过ID/令牌跟踪在购买请求支付之前跟踪消费者。

该系统可以支持多个支付供应商。这是通过支付运营商针对每个支付供应商实现定制驱动而进行的。对于开发、安装了支付驱动的每个服务供应商，或者更坏的情况下对于必须与多个支付供应商进行通信的客户机来说，这种方法是优选的。

以上描述的并在后面的权利要求书中要求保护的本发明使所有的支付都可以由用户确认，从而减小了欺诈的机会；与支付供应商无关地向消费者呈现单个支付确认对话；与支付供应商无关地为消费者记录所有电子收据；在消费者控制之下进行服务激活，从而消费者可以请求服务、接收激活密钥并等待稍后激活它；可用来支持关于请求的支付或关于激活的支付；允许消费者指定不需要确认的优选服务供应商和价格限制；快速并且容易使用。根据本发明，消费者从他们的服务代理中选择服务供应商，服务代理打开浏览器并将他们带到服务供应商的站点，他们选择想要的服务，并且服务代理打开支付确认提示窗口。结果，本发明减小了使用集中信任式支付运营商进行欺诈的风险。通过使支付和服务或内容浏览分离开，网络导航对消费者来说变得简单了。

本发明有益地提供了一种通信系统，其中控制操作的逻辑被分布在基于用户设备的驻留服务代理、潜在的许多设备供应商与支付供应商以及在一个方面基于网络的支付运营商之间。

Claims

1.一种用于安装在各种用户设备中的服务代理，所述用户设备被安排用于与包括一个或更多个远程服务供应商和一个或更多个远程支付供应商的支付系统进行通信，所述远程支付供应商用于提供从多个所述用户设备到所述支付系统的统一接口；其中所述服务代理包括：

功能激活装置，用于激活所述用户设备上的功能；

其中所述功能激活装置被安排用来激活与所述服务供应商中的一个进行联系的功能；

其中所述功能激活装置被安排用来激活从所述服务供应商中的一个下载内容的功能；

服务激活装置，其包括用于从所述支付运营商接受服务激活密钥和用于转发所述服务激活密钥以启动服务交付的装置。

2.根据权利要求1所述的服务代理，其中被激活的功能是浏览器。

3.根据以上权利要求中任意一项所述的服务代理，其中所述用户设备被安排用于与包括一个或更多个远程服务供应商的定购系统进行通信，所述远程服务供应商用于提供从多个所述用户设备到所述定购系统的统一接口。

4.根据以上权利要求中任意一项所述的服务代理，其中被激活的功能是浏览器。

5.根据以上权利要求中任意一项所述的服务代理，其中所述功能激活装置包括用于将用户标识符传送到被激活的功能的装置。

6.根据以上权利要求中任意一项所述的服务代理，其中所述激活装置被安排用来激活被调用的功能，以将所述用户标识符传送给所述服务供应商中的一个。

7.根据以上权利要求中任意一项所述的服务代理，其中该服务代理包括用于将所述服务激活密钥传送给被激活的功能的装置。

8.根据以上权利要求中任意一项所述的服务代理，该服务代理被安排为代表所述用户来执行所有与支付相关的功能。

9.根据以上权利要求中任意一项所述的服务代理，其中所述支付系统包括支付运营商。

10.根据以上权利要求中任意一项所述的服务代理，该服务代理包括用于将所述服务激活密钥提供给所述服务供应商中的一个以启动服务交付的装置。

11.根据以上权利要求1到9中任意一项所述的服务代理，该服务代理包括用于将所述服务激活密钥提供给所述用户来提示所述用户将所述服务激活密钥发送给所述服务供应商中的一个以启动服务交付的装置。

12.根据以上权利要求中任意一项所述的服务代理，该服务代理包括用于支付确认的装置。

13.根据以上权利要求中任意一项所述的服务代理，该服务代理包括用于从所述支付运营商接受确认密钥和用于将所述确认密钥提供给所述服务供应商中的一个的装置。

14.根据以上权利要求中任意一项所述的服务代理，该服务代理包括用于经由所述支付运营商从所述服务供应商中的一个接受支付请求和用于提示所述用户对所述请求采取行动的装置。

15.根据以上权利要求中任意一项所述的服务代理，该服务代理包括用于对所述用户的身份进行认证的装置。

16.一种包括以上权利要求中任意一项所述的服务代理的通信系统。

17.一种用于对一个或更多个用户设备、服务供应商以及支付供应商的交互进行控制的支付运营商，所述支付供应商用于对所述服务供应商提供的商品或服务的支付进行安排，其中所述支付运营商包括：

用于从服务供应商接收支付请求的装置；

用于向用户设备发送支付确认请求和用于从所述用户设备接收响应的装置；

用于将所述用户响应传送到支付供应商的装置；

用于向所述服务供应商中的一个传送确认密钥以启动将商品或服务提供给所述用户的装置；

用于将服务激活密钥从所述服务供应商中的一个传送到所述用户设备的装置。

18.根据权利要求17所述的支付运营商，该支付运营商包括用于利用所述服务激活密钥来生成服务确认密钥并将其传送给所述用户设备的装置。

19.根据权利要求17到18中所述的支付运营商，该支付运营商包括用于对所述一个或更多个用户设备、服务供应商以及支付供应商之间的消息交换进行控制的装置。

20.根据权利要求17到19中任意一项所述的支付运营商，该支付运营商包括用于从所述支付系统接收所述确认密钥的装置。

21.根据权利要求17到20中任意一项所述的支付运营商，该支付运营商包括用于检测是否从所述服务供应商中的一个接收到了供应给所述用户设备的所述服务确认密钥的装置。

22.根据权利要求17到21中任意一项所述的支付运营商，该支付运营商包括用于基于所接收到的服务确认密钥来启动支付的装置。

23.一种用于在通信系统中控制支付的方法，该方法包括以下步骤：在一个或更多个用户设备中设置服务代理；从所述一个用户设备或所述更多个用户设备中的一个用户设备访问服务供应商；从所述服务供应商选择要购买的产品；所述服务代理经由支付运营商从所述服务供应商接收支付请求；以及所述服务代理经由所述支付运营商向支付供应商发出支付授权。

24.根据权利要求23所述的方法，该方法包括以下步骤：所述服务代理激活所述用户设备上的功能。

25.根据权利要求23到24中任意一项所述的方法，该方法包括以下步骤：向被激活的功能传送用户标识符并安排所述被激活的功能将所述用户标识符传送到所述服务供应商中的一个。

26.根据权利要求23到25中任意一项所述的方法，该方法包括以下步骤：安排所述被激活的功能从所述服务供应商中的一个下载内容。

27.根据权利要求23到26中任意一项所述的方法，该方法包括以下步骤：从所述支付运营商接受服务激活密钥，并将所述服务激活密钥提供给所述用户，来提示所述用户将所述服务激活密钥发送给所述服务供应商中的一个以启动服务交付。

28.根据权利要求23到27中任意一项所述的方法，该方法包括以下步骤：经由所述支付运营商从所述服务供应商中的一个接受支付请求并提示所述用户对所述请求采取行动。

29.一种在通信系统中从服务供应商购买商品或服务的方法，该方法包括在用户设备上使用服务代理进行以下步骤：

(a)将用户身份登记在支付运营商处并向所述支付运营商认证所述用户身份；

(b)经由所述用户设备上的客户机打开从所述用户设备到所述服务供应商的连接；

(c)向所述服务供应商识别所述用户和所述支付运营商；

(d)经由所述客户机进行浏览并从所述服务供应商选择服务；

(e)基于从所述服务供应商到所述支付运营商的支付请求从所述支付运营商接收支付确认请求；

(f)向所述支付运营商确认支付；从而

(g)所述用户从所述服务供应商接收所述商品或服务。

30.根据权利要求29所述的方法，所述服务代理通过该方法打开在步骤(d)从所述服务供应商选择所述服务的客户机应用。

31.根据权利要求29所述的方法，所述服务代理根据该方法打开从所述服务供应商购买服务的客户机应用。

32.根据权利要求29到31中任意一项所述的方法，该方法包括以下步骤：在步骤(e)，在多个设备上的多个服务代理处接收所述支付确认请求并选择所述服务代理中的一个来处理所述请求。

33.根据权利要求29到32中任意一项所述的方法，该方法包括以下步骤：在多个设备上设置多个服务代理并在所述支付运营商选择的所述多个服务代理中的一个处接收所述支付确认请求。

34.一种在通信系统中经由用户设备从服务供应商购买商品或服务的方法，该方法包括以下步骤：在支付运营商处从所述服务供应商接收支付请求；创建支付确认请求并将其发送给所述用户设备上的服务代理；获取存储在所述支付运营商处的用户偏好；以及根据所述偏好来处理所述支付请求。

35.根据权利要求34所述的方法，该方法包括以下步骤：根据所获取的用户偏好来阻止或允许服务供应商。

36.根据权利要求34或35所述的方法，该方法包括以下步骤：根据所获取的用户偏好来识别不需要确认的支付。

37.根据权利要求34到36中任意一项所述的方法，该方法包括以下步骤：将所述支付确认请求发送给多个用户设备上的多个服务代理。

38.根据权利要求34到37中任意一项所述的方法，该方法包括以下步骤：将所述支付确认请求发送给从多个用户设备上的多个服务代理中选出的服务代理。

39.根据权利要求38所述的方法，该方法包括以下步骤：基于所述服务代理提供给所述支付运营商的认证信息来选择服务代理。

40.根据权利要求34到39中任意一项所述的方法，该方法包括以下步骤：检测没有服务代理的用户设备；提示所述用户；从所述用户接收响应；以及响应于用户响应将服务代理下载到所述设备中。

41.根据权利要求34到40中任意一项所述的方法，该方法包括以下步骤：通知所述服务供应商需要服务交付确认；从所述服务供应商接收激活URL；以及将所述激活URL和服务确认密钥转发给所述服务代理。

42.根据权利要求41所述的方法，所述支付运营商根据该方法从所述服务代理接收支付确认，检查所述支付确认，如果正确则根据所述支付请求代表所述消费者向所述服务供应商进行支付。