下订单方案的制作方法

专利名称：下订单方案的制作方法
技术领域：
本发明涉及一种下订单方案(ordering scheme)，诸如用于移动通信设备的下订 单和支付(payment)方案。
背景技术：
远程购物近年来已大大扩增。例如，因特网购物已变得平常。从诸如移动电话的 移动通信设备发送的购物订单也变得平常。诸如因特网购物的远程购物存在的第一个问题是为服务/产品提供商和最终消 费者两者提供采取的动作的证据。例如，如果产品未被交付，则消费者将希望证明已经下了 订单并进行了支付。如果消费者下了订单，但支付比经过协商的少，那么服务或产品提供商 将希望证明所订立的协议条款。远程购物存在的第二个问题是隐私。消费者不愿意为服务和产品提供商提供诸如 全名、地址、信用卡细节和口令的安全信息。当提供商不是著名且可信任的商标时情况尤其 如此。此外，虽然已知的是电信服务运营商向其客户提供预付费系统及其它计费 (charging)服务系统，但通常，这些计费系统局限于由特定电信服务运营商提供的服务。虽 然电信服务运营商具有向第三方服务提供商提供金融服务的能力，但实现此类系统已被证 明是困难的。一个问题是每个第三方服务提供商需要与每个运营商的服务建立技术和合同 关系。这导致高度复杂且昂贵的基础设施。此基础设施的一部分涉及处理安全和用户隐私 的问题。

发明内容
本发明设法解决上述的至少某些问题。本发明提供了一种方法，包括步骤服务提供商(诸如因特网商店)向用户设备(诸 如计算机或移动通信设备)发布要约(offer)，其中，该要约包括包含与提供的项目有关的 信息(诸如产品/服务描述和价格)的第一消息；以及用户设备向服务提供商发送该要约的 承诺(acceptance)，其中，该承诺包括第二消息，并且其中，使用用户设备的私钥来对该承 诺加密。然后，所述服务提供商可以确认由用户设备(使用用户设备的公钥)签署(sign) 了 该承诺。本发明还提供了一种系统，包括服务提供商(诸如因特网商店)和用户设备(诸如 计算机或移动通信设备)，其中所述服务提供商被配置为向用户设备发布要约，其中，所述 要约包括包括与提供的项目有关的信息(诸如产品/服务价格和描述)的第一消息；以及用 户设备被配置为向所述服务提供商发送所述要约的承诺，其中，所述承诺包括第二消息，并 且其中，使用用户设备的私钥来对所述第二消息进行加密。然后，所述服务提供商可以确认 由用户设备(使用用户设备的公钥)签署了该承诺。从所述用户设备到所述服务提供商进行的所述要约的加密承诺的发送为所述服务提供商提供授权客户下了订单的密码安全的证据。该证据是强有力且安全的，因为只 有用户设备应知道相关私钥。如下文进一步讨论的，服务提供商可以不知道用户的身份 (identity)，但是应当知道用户经过认证，并且用户对于相关网络运营商而言应是可识别 的(例如，经由假名)。在不存在此类证据的情况下，所述服务提供商可能必须显示其自己的 日志文件以说服第三方已经下了订单(order was made)，并且还证明该日志文件反映用户 实际上所做的事。在本发明的某些形式中，所述第一和第二消息是相同的，因此，为了接受(accept) 要约，用户设备简单地对第一消息加密并将加密消息返回到服务提供商。可以对所述要约进行加密；例如，可以使用服务提供商的私钥来对第一消息加密。 因此，要约的从服务提供商到用户设备的发送为用户提供作出(make)要约的密码安全证据 和作出要约的项目(例如，价格)。该证据是强有力且安全的，因为只有服务提供商应知道相 关私钥。然后，可以将从用户设备接收到的订单信息从服务提供商发送到支付经纪人 (broker)。在本发明的某些形式中，将订单信息直接从服务提供商发送到支付经纪人，使用 服务提供商的私钥或用户的私钥进行加密。在本发明的其它实施例中，经由用户设备将订 单信息从服务提供商发送到支付经纪人；再次地，可以用服务提供商的私钥或用户的私钥 对订单信息进行加密。在其中将订单信息发送给支付经纪人的本发明的许多形式中，被发送给支付经纪 人的信息包含少于包括在要约中的信息。特别地，在本发明的许多形式中，未包括关于被购 买的货物或服务的数据。其背后的原因是支付经纪人在确定是否应进行支付时不需要知道 所涉及的货物或服务的性质。如果不需要此数据，则优选的是在数据最小化方面和用户隐 私方面，不将此类数据包括在给支付经纪人的消息中。在本发明的某些实施例中，在所述服务提供商与所述用户设备之间发送的订单消 息包括第一和第二部分，其中，所述第二部分用于发送给支付经纪人，但是所述第一部分不 用于发送给支付经纪人。举例来说，从所述服务提供商发送到所述用户设备的要约数据可以包括以下各项 中的至少某些用户的假名、服务提供商的标识符、被提供的货物和/或服务的价格和描 述、当前时间和可以使用服务提供商的私钥对数据进行加密的随机量(nonce)。从所述用户 设备到所述服务提供商的承诺可以包含相同的数据，虽然可以使用用户设备的私钥对此数 据进行加密。发送给支付经纪人的数据可以省略关于货物和/或服务的数据。进一步举例来说，从所述服务提供商发送到所述用户设备的要约数据可以包括以 下各项中的至少某些用户的假名、服务提供商的标识符、被提供的货物和/或服务的价格 和描述、以及正在讨论中的所有货物和/或服务的总价格。从所述用户设备到所述服务提 供商的承诺可以包含相同的数据，虽然可以使用用户设备的私钥对此数据进行加密。发送 给支付经纪人的数据可以省略各个货物和/或服务的数据和价格。在本发明的某些形式中，支付数据被发送到计费服务。在其中支付信息被发送到 计费服务的本发明的许多形式中，被发送到计费服务的信息包含少于包括在要约中的信息 和/或被发送到支付经纪人的信息。特别地，在本发明的许多形式中，未包括关于被购买的 货物或服务的数据且未包括识别服务提供商的数据。其背后的原因是计费服务在确定是否应进行支付时不需要知道所涉及的货物或服务的性质或正在讨论中的服务提供商。在本发明的某些形式中，生成三个单独消息，形成由服务提供商作出的要约的第 一消息、用于发送给支付经纪人的第二消息和用于发送给计费服务的第三消息。在本发明 的一种形式中，在服务提供商处生成所述第一、第二和第三消息。可以使用服务提供商的私 钥分别地对三个消息中的每一个加密。所述第一消息可以包括用户的假名、服务提供商的标识符、被提供的货物和/或 服务的价格和描述、以及总价格。或者，所述第一消息可以包括用户的假名、服务提供商的 标识符、被提供的货物和/或服务的价格和描述、当前时间和随机量。还可以有其它消息格 式。所述第二消息可以包括用户的假名、服务提供商的标识符以及总价格。或者，所述 第二消息可以包括用户的假名、服务提供商的标识符、被提供的货物和/或服务的价格、当 前时间和随机量。还可以有其它消息格式。所述第三消息可以包括用户的假名和总价格。或者，所述第三消息可以包括用户 的假名、被提供的货物和/或服务的价格、当前时间和随机量。还可以有其它消息格式。在本发明的一种形式中，所述支付经纪人确定支付是否依照用户的信贷限额 (credit limit)。订单细节可以包括用户的信贷限额。在本发明的一种形式中，由身份提 供商来提供信贷限额。如果提供了，则可以使用支付经纪人的公钥对信贷限额进行加密，以 便只有支付经纪人能够查看信贷限额数据。所述支付经纪人可以通过使用服务提供商的公钥对数据解密来确认向其发送的 数据是由服务提供商发送的。应注意的是无论是直接从服务提供商还是经由用户设备接收 到数据，都可以执行此步骤，因为在任一种情况下，可以使用服务提供商的私钥在服务提供 商处对数据进行加密。或者，可以由诸如身份管理系统的另一模块来执行被发送给支付经 纪人的数据被服务提供商签署的验证。在本发明的替换形式中，可以使用身份管理系统或 用户设备的私钥来对发送给支付经纪人的数据进行加密，在这种情况下，支付经纪人将需 要使用适当的公钥对该数据解密。支付经纪人可以向服务提供商确认订单数据的收据(receipt)。可以使用支付经 纪人的私钥来对该收据加密。服务提供商可以向用户设备发布支付收据(例如使用服务提 供商的私钥而被加密)。在本发明的一种形式中，支付经纪人使用支付经纪人的私钥对订单信息加密并将 所加密订单信息发送到身份管理系统。此外，可以经由用户设备从支付经纪人向身份管理 系统发送所加密订单信息。在本发明的一种形式中，所述身份管理系统对从其发送所加密订单信息的支付经 纪人和用户设备两者进行认证。如果支付经纪人和用户设备两者经过认证，则身份管理系 统可以告知计费系统将进行支付。替换地，或另外，如果支付经纪人和用户设备两者经过认 证，则可以向用户设备发送支付收据。在其中订单信息被直接从支付经纪人发送到身份管 理系统的本发明的替换形式中，身份管理系统可以仅仅对支付经纪人(而不同样地对用户 设备)进行认证。在本发明的许多形式中，当支付已被确认时，向用户发布支付收据。可以例如使用 服务提供商的私钥对此支付收据进行加密。服务提供商可以将订单收据和支付收据两者发送给用户，可以使用服务提供商的私钥对其中的任一者或两者进行加密。可以一起或分别 地发送订单和支付收据。当然，本发明还可以包括用于履行所下的任何订单的手段，诸如与服务提供商相 关联的物流操作。此类物流操作可以以与本文所述的系统的其它模块类似的方式来接收已
签署消息。本发明还可以提供用于使得用户能够向服务提供商注册的装置。举例来说，可以 提供在身份管理系统的控制下的单点登陆(single-sign-on)装置。


现在将仅仅以示例的方式参考以下编号附图来描述本发明。图1是依照本发明的第一方面的系统的方框图； 图2是举例说明依照本发明的方面的算法的流程图； 图3举例说明依照本发明的方面的消息序列；
图4是示出图2的算法的进一步细节的流程图； 图5是依照本发明的另一方面的系统的方框图； 图6是举例说明依照本发明的方面的算法的流程图；以及 图7举例说明依照本发明的方面的消息序列。
具体实施例方式图1示出依照本发明的方面的一般用参考标号2指示的系统。系统2包括用户设 备4 (诸如计算机或移动通信设备)、服务提供商6 (诸如因特网商店)、身份管理系统8、支 付经纪人10、以及计费系统12 (诸如电信服务运营商的计费系统)。图2是示出一般用参考标号20指示的示例性算法的流程图，用于使得使用用户设 备4的用户能够从服务提供商6购买产品或服务并经由支付经纪人10和计费系统12为那 些产品/服务进行支付。算法20在步骤22处开始，在那里，用户尝试使用用户设备4来访问服务提供商6。 作为响应，算法20移动到步骤24，该步骤询问用户是否是为身份管理系统(IDM)S所知的。 如果用户是已知的，则在步骤28对其进行认证。如果用户是未知的，则算法移动到步骤26， 在该点处，要求用户向IDM 8进行注册。如果用户在IDM处成功地注册，则算法20移动到 步骤28，在那里，对用户进行认证；否则，算法在步骤38处终止。从步骤28开始，算法20移动到步骤30，在那里，用户例如通过以本领域中众所周 知的方式填充在线购物车来在服务提供商处进行购买。一旦用户已完成购物，则生成订单并在步骤32处要求用户确认该订单。如果订单 得到确认，则算法20移动到步骤34。否则，算法20在步骤38处终止。在步骤34处，用户设法对经确认的订单进行支付。如果支付是成功的，则在步骤 36处履行该订单，并且算法20在步骤38处终止。如果支付步骤34是不成功的，则省略步 骤36，并且算法20在步骤38处终止。下面更详细地描述算法20的各种元素。在此阶段，应注意的是本文所述的算法20 假设用户用具有浏览器的设备登录到网络上并判定使用(向身份管理系统8注册的)假名来在因特网上购物，访问一个或多个服务提供商6以便这样做。计费系统12以某种方式与 身份管理系统8合作。身份管理系统8、服务提供商6和支付经纪人10每个都拥有用于对 其消息进行签署的私钥和公钥对，并已公开其公钥以使得能够由消息的接收机进行其签名 (signature )的验证以便证明消息的来源。图3示出用户设备4、服务提供商6和身份管理系统8之间的一般用参考标号40 指示的示例性消息序列。消息序列40是算法20的步骤22、24和28的示例性实施方式。首先，用户设备4通过发布访问请求来设法访问服务提供商6。在此阶段，用户设 备尚未登录到服务提供商6中，因此服务提供商向用户设备发布认证请求。使用服务提供 商的私钥来签署该认证请求。该认证请求被用户设备4连同用于对用户进行认证的会话 cookie (信息段)一起转送到身份管理系统8，如果此类cookie先前已被存储在用户设备 处的话。当用户尝试访问服务提供商6时，可以自动地执行这些步骤，从而实现单点登陆算 法。如果用户为身份管理系统8所知，则身份管理系统向用户设备4发送授权消息以 便由用户设备转送给服务提供商6。用户设备4将该授权转送给服务提供商6，并且服务提 供商允许用户设备访问服务提供商并通过向用户设备转送成功消息来对此进行确认。在用户设备4对于身份管理系统而言未知的情况下，则否定地回答算法20的步骤 24，并且算法移动到步骤26。已知用于使得用户设备能够向身份管理系统进行注册的多种 方法。例如，可以使用以下示例性过程
1.用户设备4生成RSA私钥/公钥对；
2.将用户设备4的公钥发送到身份管理系统8;
3.身份管理系统8要求用户提供其证书(credential)；
4.用户经由用户设备4来提供要求的证书(例如，用户名和口令)；
5.身份管理系统8识别该用户证书并通过向用户设备发送会话cookie以供在稍后认 证中使用来进行响应。已知有其它机制且其可以用于向身份管理系统8注册用户设备4。图4是示出用于执行算法20的步骤32和34的一般用参考标号41指示的示例性 算法的流程图。因此，在算法41开始之前，用户已经选择要购买的项目(步骤30)。算法41在步骤42处开始，在这里，服务提供商生成包含支付信息、用户的假名和 已被订购的产品/服务的细节的三个消息(例如，开放式反式编码(open Trans encoded) XML消息，虽然当然可以使用其它消息格式)。这些消息在下文中称为订单A、订单B和订单 C并包括以下数据
订单 A:Srv，ps, g, ρ, t; 订单 B:Srv, ps, t; 订单 C:ps，t. 其中
Srv标识服务提供商；
ps是用户的假名；
g是货物或服务的描述，或货号；
P是正在讨论中的各个货物或服务的价格；以及
8 t是用于订购的货物和服务的总价格
因此，如下文进一步讨论的，消息订单B省略了包含在订单A中的正在讨论中的货物和 服务的描述和价格，并且消息订单C还省略了包含在消息订单A和订单B中的服务提供商 的细节。服务提供商6生成包括被发送给用户的订单的细节的确认页面、以及消息订单A、 订单B和订单C。确认页面表示由服务提供商向用户作出的有约束力的(binding)要约(可 能具有有限的持续时间)。确认页面向用户呈现要求用户确认应处理的订单的对话框。由 用户进行的确认(算法41的步骤44)得到由用户设备的私钥签署的消息订单A、订单B和订 单C。此类确认表示用户对服务提供商的要约的有约束力的承诺。加密消息被送回给服务提供商6。然后，服务提供商6使用用户设备的公钥针对三 个消息中的每一个确认用户的签名(步骤46)。如果用户的签名得到确认，则算法移动到步 骤40 ；否则，算法41在步骤62处终止。在步骤48处，服务提供商用其私钥以密码方式签署消息订单B和订单C，并将适当 的消息转送到用户设备4，用户设备4又将加密消息转送到支付经纪人10。支付经纪人10从用户设备4接收加密消息订单B和订单C并使用服务提供商的 公钥来确认消息(步骤50)。如果服务提供商的签名得到确认，则算法41移动到步骤52 ；否 则算法41在步骤62处终止。(应注意的是在本发明的替换形式中，加密消息订单B和订单 C经由身份管理系统8被发送到支付经纪人；在此类装置中，身份管理系统可以验证消息订 单B和订单C的签名而不是支付经纪人10)。在步骤52处，支付经纪人10使用其私钥来签署消息订单C并经由用户设备4将 加密消息发送到身份管理系统8。在步骤M处，身份管理系统8检查支付经纪人10签署了消息订单C(使用支付经 纪人的公钥)，并且还对用户(该用户的浏览器正在传送支付请求)进行认证。如果支付经纪 人和用户两者都得到验证，则算法41移动到步骤56 ；否则，算法41在步骤62处终止。在步骤56处，身份管理系统8联系计费系统12以在计费系统处从用户的账户扣 除所请求的量。如果计费系统确认已发生这种情况，则算法移动到步骤58 ；否则，算法在步 骤62处终止。在步骤58处，身份管理系统生成经签署的支付确认并将其发送到支付经纪人。支 付经纪人10使用身份管理系统的公钥来验证身份管理系统的签名。如果签名得到验证，则 算法41移动到步骤60 ；否则，算法41在步骤62处终止。在步骤60处，支付经纪人10触发经确认的金额(confirmed sum)到服务提供商 的账户的转移(transfer)，并向商店发送收据。然后，算法移动到步骤64，在那里，向用户 设备4发送成功消息并履行该订单。因此，算法41生成在步骤42处、服务提供商对用户的有约束力的要约和在步骤44 处、用户的有约束力的承诺。用户获得(并可以出于证据的目的保留)要约的加密版本，并且 服务提供商可以同样地保留承诺的加密版本。在服务提供商、支付经纪人、身份管理系统和 计费系统之间转移加密订单数据。所发送的数据受到约束，因此支付经纪人未接收到关于 订购的货物或服务的数据或各个项目的价格(仅总价格)，并且计费系统仅接收到用户的假 名和要转移的总金额。
下面将参考图5至7来描述本发明的第二实施例。图5示出依照本发明的方面的一般用参考标号102指示的系统。系统102包括身 份提供商104、用户设备106、服务提供商108、支付经纪人110和计费系统112 (诸如网络
运营商服务提供商108提供用户可能感兴趣的产品或服务。在用户希望从服务提供商 108处进行购买的情况下，由身份提供商104对用户设备106进行认证，并且如果服务提供 商108接受了此认证过程，则产品或服务被出售给用户。服务提供商108通过将相关数据发送给支付经纪人110来获得对出售的产品或服 务的支付。支付经纪人110又与计费服务112保持联络，其例如通过借助于电话帐单对用 户进行计费来从用户收回(recover)支付。图6示出依照本发明的第二实施例的算法120。算法120在步骤122处开始，在步骤122处，用户设备106选择由服务提供商108 提供的用户感兴趣的产品或服务。接下来，算法移动到步骤124，在这里，从服务108向用 户106发送关于所选产品和/或服务的有约束力的要约。如下文进一步描述的，例如通过 用私钥来签署要约而对其进行密码保护。然后，算法移动到步骤126，在这里，用户设备要求用户指示要约是否被接受，即是 否应购买产品和/或服务。如果用户设备106指示不应购买该产品和/或服务，则算法120 在步骤128处终止。如果用户设备106指示应购买该产品和/或服务，则算法120移动到 步骤130。在步骤130处，用户设备向服务提供商108发送受到密码保护的订单。如下文进 一步描述的，用户还可以发送附加字段，其也可以是密码安全的，但是其包含比完整订单少 的信息。然后，服务提供商108可将相关数据转送到支付经纪人110和/或计费系统112 以证明用户的确订购了项目。如下文进一步描述的，可以将此过程布置为通过省略与用户 的身份有关的信息来保护用户的隐私。一旦已在步骤130处发送了订单，则算法120移动到步骤132，在这里，受到密码保 护的订单和支付收据被从服务提供商108发送到用户106。根据本发明的任何特定实施例 中的消息流，可以分别地或一起发送订单和支付收据。一旦已发布收据，则算法120在步骤 128处终止。在可以在系统102中处理由用户设备106下的任何订单之前，必须在系统102的 元件之间建立信任。最初假设身份提供商104、服务提供商108、支付经纪人110和计费系 统112使用公根(common root)证书授权机构(certificate authority, CA)的证书，或 者，至少系统102的所有这些元件都具有由被系统中的所有元件认可的证书授权机构签署 的证书。用户105可以生成证书，诸如公钥/私钥对和假名并要求身份提供商104对其进 行认证。假设用户已具有其它证书以向身份提供商对其本身进行认证。可能的证书包括存 储在SIM卡或UICC上的口令和共享密钥。此机制的优点是用户能够定期地修改其证书。由 于以同一组证书进行的所有用户活动由于包含在证书中的唯一用户ID或唯一密钥而可以 被链接，所以定期地修改证书防止服务提供商在较长的时间段内跟踪用户。图7示出本发明的示例性实施例中的一般由参考标号140指示的消息序列。序列140示出在身份提供商104、用户设备106、服务提供商108、支付经纪人110和计费系统112 之间发送的消息。假设在图7中所示的消息流之前，用户设备106已创建私钥/公钥对(PKU、K)，并 且身份提供商104已安全地接收到或验证了用户的信贷限额(L)并已创建或验证了用户的 假名(ps)。用参考标号142指示的第一消息被从用户设备106发送到身份提供商104，并且如 下{U，%，t, Κ}Ρκυ，其中
U标识用户；
Iiu是关于用户的随机量(使用一次的号码)； t是时间戳；
K是用户的公钥；以及
PKU是用户的私钥。发送消息142以向身份提供商登记用户106及其公钥K ；对于每个用户，这只需做 一次。为了进行认证，用户106使用其已具有的证书(未示出)。在此布置中，身份提供商104 已经知道用户设备106的公钥并因此能够对消息142进行解密。第二消息144是从身份提供商104发送到用户设备106的令牌1\。令牌T1如下 {ps、L、K、tt}IDP，其中
ps是用户的假名(例如，xyziNO)；
L是用户的当前信贷限额(可能用支付经纪人的公钥加密)；
K是用户的公钥；
tt是用于令牌的最大有效时间；以及
IDP是身份提供商的私钥。令牌T1被用户发送到服务提供商108 (消息146)。因此，服务提供商108接收包 含用户的假名、用户的信贷限额、用户的公钥和用于令牌的最大有效时间的加密消息。服务 提供商108知道身份提供商104的公钥，并因此能够将消息146解密。作为响应，服务提供商发送消息148，消息148定义由服务提供商向用户作出的有 约束力的要约(由此实现流程图120的步骤124)。消息148内容如下{ps、Srv、p、g、t、n} s，其中
ps是用户的假名；
Srv标识服务提供商；
P是正在讨论中的货物或服务的价格；
g是货物或服务的描述，或货号； t是当前时间；
η是随机量；以及
S是服务提供商的私钥。在消息148中，服务提供商108发送所作出的要约的确认，向用户要求授权并向其 询问第二消息146的令牌T1的拥有证据。用户设备106知道服务提供商的公钥并因此能 够将消息148解密。作为响应，用户设备106向服务提供商108发送消息150。消息150如下{ps、31^、？^3、11}_，其中，？1^是用户的私钥(即，由用户设备将订单148的确认解密并随后使 用用户设备的私钥再次简单地进行加密)。这样，用户设备106通过用其私钥PKU来签署详 细的交易信息而接受要约(由此完成流程图120的步骤130)。除发送包括详细交易信息的消息150之外，用户106还向服务提供商108发送令 牌T2。令牌1~2如下{ 8、51^、？、111}·。因此，令牌T2省略所订购的产品或服务的细节。替换地，或另外，用户可以向服务提供商发送令牌Τ3。令牌T3如下{pS、p、t、n}s。 因此，令牌T3省略关于所订购的产品或服务的信息和关于服务提供商108的信息二者。当服务提供商接收到消息150时，从服务提供商108向用户106发送消息152。消 息125如下{Srv、t、n、l}s。消息152充当订单收据，从而实现流程图120的步骤132的一 部分。用经确认的订单，服务提供商108向支付经纪人110发送消息154。消息154包 括令牌T1和T2,并且可选地还包括令牌T3。在接收到令牌T1和T2时，支付经纪人检查用户 (由其假名PS标识)是否仍在其信贷限额内。为此，支付经纪人110可以代表此用户保持所 进行的支付的列表。如果此测试的结果是肯定的(或令牌T1根本不包含信贷限额)，则支付 经纪人向服务提供商108发送支付收据。在示例性消息序列140中，此支付收据采取包括 使用支付经纪人110的私钥加密的令牌T2的消息156的形式。支付经纪人110还通过向网络运营商发送令牌T2或T3来向计费系统112告知支 付(消息158)。(发送令牌1~3可以是优选的，因为其省略了关于服务提供商的信息，从而使被 发送到计费系统112的信息仅仅局限于计费系统需要知道以便完成订单的信息。)然后， 计费系统112的记帐(billing)服务能够为用户开帐单并可能调整用户的剩余信贷限额。最后，当服务提供商已接收到确认支付的消息156时，从服务提供商向用户发送 消息160。消息160如下{Srv、t、n、2}s。消息160是加密支付收据，从而完成流程图120 的步骤132。因此，用户接收使用服务提供商的私钥加密的消息(消息148)，其可以被用作服务 提供商在一定条件(包括价格)下提供了产品或服务的证据。此外，服务提供商接收使用用户的私钥加密的消息(消息150)，其可以被用作用户 订购了特定产品或服务的证据。此外，用户接收使用服务提供商的私钥加密的消息(消息152和160)，其可以被用 作服务提供商确认了订单的接收且服务提供商确认了支付的接收的证据。如上文所讨论的，本发明包括信贷限额的传输。用户的信贷限额可以是由身份提 供商发布的令牌的一部分。如果存在，则其向服务提供商或支付经纪人告知此用户在某个 时间范围内能够花费的最大量。如果出于隐私的原因，服务提供商不应能够读取该信贷 限额，则可以用支付经纪人的公钥将其加密。根据协议的细节，服务提供商或支付经纪人 可以检查用户仍在其信贷限额内，这意味着保证网络运营商针对当前交易向服务提供商 进行支付。应注意的是由服务提供商进行的信贷限额的检查可能对包含信贷限额的声明 (assertion)的有效期限有影响。上文所述的算法120采取许多步骤来保护用户的隐私。在算法120中，支付经纪 人Iio需要知道要转移的金额量，但是不需要知道产品或服务或由用户设备106订购的产 品或服务的类型。因此，令牌不包括关于产品的信息。另一方面，服务提供商108需要知道例如用户的IP地址，但不知道消费者的身份。因此，服务提供商发送假名PS，而不 是用户细节U。图5的布置示出单个身份提供商104、用户设备106、服务提供商108、支付经纪人 10和计费系统112。当然，在本发明的许多实施方式中，可能存在系统102的这些元件中 的不止一个。例如，系统102的许多实施方式将包括多个身份提供商104、多个支付经纪人 110、多个计费系统112、许多服务提供商108和非常多的用户106。同样地，图1的布置可 以包括多个身份管理系统8、多个支付经纪人10、多个计费系统12、许多服务提供商6和非 常多的用户设备4。上文已参考两个详细实施例描述了本发明。如对于技术人员来说将显而易见的， 可以将参考一个实施例描述的特征结合到另一实施例中。除非不可能这样做，否则本发明 包括两个实施例的所有组合。上文描述的本发明的实施例是说明性而不是限制性的。对于本领域的技术人员 来说显而易见的是在不脱离本发明的一般范围的情况下，上述设备和方法可以结合许多修 改。意图是将所有此类修改包括在本发明的范围内，只要其落在所附权利要求的范围内即可。
权利要求
1.一种方法，包括步骤服务提供商向用户设备发布要约，其中，所述要约包括第一消息，该第一消息包括与被 提供的项目有关的信息；以及所述用户设备向所述服务提供商发送所述要约的承诺，其中，所述承诺包括第二消息， 并且其中，使用所述用户设备的私钥来对所述承诺进行加密。
2.如权利要求1所述的方法，其中，所述第一和第二消息是相同的。
3.如权利要求1或权利要求2所述的方法，其中，使用所述服务提供商的私钥对所述要 约进行加密。
4.如任何前述权利要求所述的方法，还包括向支付经纪人发送订单信息的步骤。
5.如权利要求4所述的方法，其中，被发送给所述支付经纪人的订单信息包含比所述 要约少的信息。
6.如权利要求4或权利要求5所述的方法，其中，所述第一消息包括第一部分和第二部 分，其中，所述第二部分用于发送给所述支付经纪人。
7.如权利要求6所述的方法，其中，所述第二消息包括第一部分和第二部分，其中，所 述第二部分用于发送给所述支付经纪人，并且其中，使用所述用户设备的私钥分别地对所 述第一和第二部分进行加密。
8.如权利要求4至7中的任一项所述的方法，还包括确认使用所述服务提供商的私钥 对被发送给支付经纪人的订单信息进行了加密的步骤。
9.如权利要求8所述的方法，还包括所述支付经纪人使用所述支付经纪人的私钥对订 单信息进行加密并将所加密订单信息发送到身份管理系统的步骤。
10.如权利要求9所述的方法，其中，经由所述用户设备从所述支付经纪人向所述身份 管理系统发送所述所加密订单信息。
11.如权利要求10所述的方法，其中，所述身份管理系统对从其发送所加密订单信息 的支付经纪人和用户设备两者进行认证。
12.如权利要求11所述的方法，其中，如果所述支付经纪人和所述用户设备两者被认 证，则所述身份管理系统告知计费系统将进行支付。
13.如权利要求11或权利要求12所述的方法，其中，如果所述支付经纪人和所述用户 设备两者被认证，则向所述用户设备发送支付收据。
14.一种包括服务提供商和用户设备的系统，其中所述服务提供商被配置为向所述用户设备发布要约，其中，所述要约包括第一消息，该 第一消息包括与被提供的项目有关的信息；以及所述用户设备被配置为向所述服务提供商发送所述要约的承诺，其中，所述承诺包括 第二消息，并且其中，使用所述用户设备的私钥来对所述第二消息进行加密。
15.如权利要求14所述的系统，其中，所述服务提供商被配置为使用所述服务提供商 的私钥来对所述第一消息进行加密。
16.如权利要求14或权利要求15所述的系统，还包括支付经纪人，其中，所述服务提供 商被配置为向所述支付经纪人发送订单信息。
17.如权利要求16所述的系统，其中，所述服务提供商被配置为从被发送给所述支付 经纪人的订单信息中省略关于被购买的项目的信息。
18.如权利要求16或权利要求17所述的系统，其中，所述支付经纪人适合于确认由所 述服务提供商发送了所述订单信息。
19.如权利要求14至18中的任一项所述的系统，还包括身份管理系统，其中，所述支付 经纪人适合于使用所述支付经纪人的私钥来对订单信息进行加密并将所加密订单发送到 所述身份管理系统。
20.如权利要求19所述的系统，其中，所述身份管理系统被配置为对从其发送所加密 订单信息的支付经纪人和用户设备两者进行认证。
21.如权利要求14至20中的任一项所述的方法，还包括用于履行被接受的要约的装置。
全文摘要
描述了一种下订单方案，例如用于移动通信设备的下订单和支付方案。该下订单方案使得因特网商店或另一服务提供商能够向移动通信设备等发布有约束力的要约并从移动设备接收该要约的承诺。使用移动设备的私钥来对该承诺进行加密并可以使用服务提供商的私钥来对要约进行加密。服务提供商与支付经纪人和计费系统保持联络以便控制从用户到服务提供商的资金转移。可以提供身份管理系统以控制对下订单方案的模块的访问。
文档编号G06Q30/00GK102077224SQ200980124025
公开日2011年5月25日 申请日期2009年6月15日 优先权日2008年6月26日
发明者A·A·希里拉, J·库拉尔, K·韦伯, M·弗兰茨, M·马霍费尔, W·迪特曼 申请人:诺基亚西门子通信公司