网络化计算机系统的激增已经打开了有关公司和个人如何经营业务的新的可 能性。例如，连接到网络(例如互联网)的终端用户，经由诸如计算机、PDA、便 携式电话等等网络化设备可以在网络上进行商业交易以便购买服务和/或商品，进 行金融交易，或经营业务或在网络上进行个人交易。与在线交易有关的固有问题是 安全性，特别是当交易中包含货币转帐、资金和/或金融、个人或其他机密信息时。
许多常规的在线交易根据两种不同但相关的模型之一进行。两种模型将浏览 器用作用于处理交易中所涉及的各方之间的信息传送的界面。在第一模型中，商家 经由浏览器在线地出售商品或服务。术语“商家”在此泛指提供供购买的商品和/ 或服务的任何实体。术语商家不用来描述任何特定的商业状态或描述特许卖方，除 非具体说明。相反，该术语一般地描述提供供购买或销售的商品和/或服务的任何 卖方或实体。术语服务提供者在本文中可以与术语商家互换地使用，除非另外说明， 具有相同的含义。
在常规的在线交易中，商家可以具有描述、显示或以其它方式提供供销售的 商品和/或服务的网站。终端用户通常通过经由浏览器界面选择产品，指示购买一 个或多个商品或服务的愿望。然后，浏览器显示允许终端用户选择一个或多个支付 类型并输入完成该交易所需的信息的交易页。例如，由浏览器显示的交易页可以允 许终端用户选择支付类型，诸如信用卡(例如VISA、MasterCard、American Express 等等)并输入交易信息，诸如信用卡号、卡的过期日等等。交易页也可向终端用户 查询个人信息，诸如姓名、帐单地址、送货地址等等。然后，终端用户提交该信息 而商家处理所提交的信息。
在该第一模型中，商家通常“拥有”网站。即，商家维护网站，负责内容， 并接收和处理由终端用户提供的交易信息。商家可在进行第一次交易之前与终端用 户开立帐户，然后在每次终端用户进行与商家的交易时，经由用户设立的登录和口 令访问该帐户。即，终端用户通常选择用于后续会话或交易的登录名和口令。在终 端用户已经提交由交易页所查询的信息后，商家处理该信息以确保该信息足以完成 该交易。例如，商家可确保信用卡号有效以及具有足以支付商品和/或服务的价格 的充足资金。
第二模型通常包括处理交易的支付部分的第三方交易提供者。第三方与终端 用户和商家形成关系。特别地，用户可以与第三方开立能经上述的登录和口令访问 的帐户。为开立该帐户，终端用户可以向第三方提供个人和支付信息(即终端用户 可以提供识别用户的个人信息和诸如一个或多个信用卡号、过期日等支付信息)。 终端用户也可通过向第三方交易提供者提供金钱，开立电子资金帐户，其余额能用 来购买在线商品和/或服务。第三方存档由终端用户提供的帐户信息和/或维护终端 用户的余额。
第三方也与商家建立关系，其中第三方处理交易的支付处理。特别地，当具 有帐户的终端用户请求转帐资金来进行购买时，第三方同意支付给商家。商家可以 通过信号告知正在出售商品和服务的网站上使用第三方的选项的可用性，来提供该 选项。例如，当用户访问商家的网站并决定购买时，向用户提供使用第三方交易提 供者支付该购买的一个选项。
当终端用户选择使用第三方交易提供者支付购买的选项时，终端用户的浏览 器被重定向到属于第三方交易提供者的网站。然后，终端用户经由登录/口令组合 登录到他/她的帐户并选择用在交易中的支付类型(例如信用卡)，或请求将资金从 用户的资金帐户转帐到商家的帐户。一旦商家确定支付已经通过交易提供者适当地 转帐，商家就能继续运送所购买的产品或向终端用户提供所购买的服务。在第二模 型中，第三方负责维护终端用户的个人和金融信息以及处理交易。
附图说明
在附图中，各个图中所示的每一相同或几乎相同的部件由相同的数字表示。 为清楚起见，在每个图中并未标记每一部件。在附图中：
图1示出根据本发明的一个实施例的用于执行在线交易的网络化计算机系统 的框图；
图2示出根据本发明的一个实施例的用于在在线交易中启动和执行身份验证 的系统和方法的示图；
图3示出根据本发明的一个实施例的用于执行支付协商、验证和/或证明的系 统和方法的示图。
图4示出根据本发明的一个实施例的用于进行在线交易的网络化计算机系统， 其中交易至少部分地通过安装在连接到网络的计算机上的交易软件处理；
图5示出根据本发明的另一实施例的用于进行在线交易的网络化计算机系统， 其中交易至少部分地通过安装在连接到网络的计算机上的交易软件处理；
图6示出根据本发明的一个实施例的用于进行对安装在终端用户计算机上的 应用程序的许可的网络化计算机系统，其中许可证经在线交易获得；
图7A示出根据示例性实施例的用于向网络认证移动模块用于建立与其的安 全通信的系统；
图7B示出根据示例性实施例的用于在建立安全通信信道时使用移动模块向 网络认证用户的系统；
图7C示出根据示例性实施例的被配置成使用移动模块来单级或多级验证各 个不同服务的系统；
图8示出根据示例性实施例的支付信息和支付联合的三方安全交换；
图9示出根据示例性实施例的商业交易子系统和帐单显示的各种用法；
图10示出根据示例性实施例的使用用于确定何种支付提供者应当用于商业交 易的支付选项和规则；以及
图11示出根据示例性实施例的配置有在用于商业交易时符合所建立的无线电 网络通信协议的防火墙的用户标识模块(SIM)设备。

常规的在线交易，例如在网络上购买商品和/或服务易受安全漏洞的攻击，从 而导致丢失个人、金融和/或其他机密信息。此外，在不受信任的网络(例如互联 网)中，商家和购买者均处于进入与不良活动者的交易的风险以致不支持议价的一 方。传统的在线交易模型也可要求商家存档购买方的机密信息，并可以要求它们处 理交易的支付方面。另外，常规的在线交易模型对购买方来说难以使用并产生普遍 不直观的交易体验。例如，经由使用混乱且难以管理的登录/口令范例的浏览器， 进行常规的在线交易。
申请人已经认识和意识到：将常规模型中由商家和浏览器处理的交易责任的 至少一部分委托给低层系统(并远离浏览器和终端用户)可便于更简单和更安全的 在线商业交易构架。例如，可由终端用户和商家的一个或两个处的操作系统处理一 个或多个交易任务，其中信息可得到更安全的保护。通过将一个或多个任务嵌入操 作系统中，可减轻用户传送交易信息的一些负担，从而使体验更直观并增强安全性。 此外，可减轻商家维护购买者信息、处理支付信息和/或处理交易。
申请人已经进一步意识到：可通过开发比登录/口令模型更安全和方便的技术， 减轻与确认购买者的身份相关联的问题。在一个实施例中，通过存储能有计划地发 布的、有关终端用户的身份信息的用户标识模块(SIM)，提供有关购买者的身份 信息，从而产生更少混乱和更直接的购买体验。此外，本文中的实施例在否则不受 信任或不安全的网络(例如互联网)上使用SIM设备，提供为单级或多级认证而 配置的协议、方法、计算系统和其他机制。
申请人已经进一步意识到：使用通常无利害关系的第三方提供在线商业交易 的各个交易元件减轻购买者和商家所陷入的风险。在本发明的一个方面中提供了商 业交易系统，其中第一网络实体提供对购买者身份的验证，并且不同的网络实体提 供对用户支付购买的能力的验证，以使得彼此是陌生人的商家和购买者可相对安全 地进行交易。
其它实施例允许商家、消费者和支付之间的三方安全商业交易以敏感记帐帐 户信息对商家或第三方不透明的方式提供。在该实施例中，经由商家与支付提供者 之间的消费者传递支付令牌。以商家和其他人不控制或获得消费者的任何敏感帐户 信息的方式，加密或签名这些支付令牌。尽管如此，商家仍然能确信地验证表示消 费者支付所提供的服务和/或商品的能力的支付令牌。
在另一实施例中，电子记帐信息用于支付授权、审核和其他目的。在该实施 例中，各种网络实体(例如消费者、商家、支付提供者等等)被供以机器可读电子 帐单，该机器可读帐单用来自动地请求和确认支付、创建交易历史、提供对服务/ 商品的支付的更准确描述、以及用于在线商业交易中的其他目的。该记帐信息也可 用于从消费者向该商家的各个业务合伙人的单笔支付的支付联合。例如，该商家可 具有与在商业交易中提供服务和/或商品的各个业务合伙人的契约关系。电子记帐 信息能包括将在各个合伙人之间分发的那些支付部分，以使得支付联合能自动地出 现而不需要用户交互作用或单独审核和支付机制。
本文中所提供的是使用由包括消费者、商家、支付提供者等等的任意数量网 络实体所制定的规则或约束来自动判断商业交易的机制。例如，由商家接受的支付 选项可与消费者可用的支付选项作比较。基于这些比较，可仅向消费者提供相匹配 的那些选项。另外，基于这一比较和/或基于另外的规则或约束，可自动地选择支 付选项。例如，消费者可基于与商家建立的信任限制支付的类型。当然，也可有确 定能在商业交易中出现的各种动作的许多其他类型的规则和/或约束。

用于网络化商业交易的常规模型集中在作为用于请求和提交终端用户购买者 与商家或业务提供者之间的个人和金融信息的界面的浏览器上，不管是直接通过商 家还是经由第三方交易提供者。在第一实例中，商家承担创建和维护通常具有某最 低安全级的能查询、获得、操纵和处理个人与金融信息的基础结构的压力。此外， 商家可负责维护针对其消费者的每一个的帐户和帐户信息(通常包括机密的个人和 金融信息)。
购买者必须放弃个人信息(例如姓名、地址、电话号码等等)和金融信息(例 如借记卡和信用卡号以及过期日、银行帐号等等)来完成交易。在某级别，购买者 必须相信商家是诚实的经纪人以及仅将信息用作获授权的，将以良好诚信经营。同 样地，商家必须相信购买者是他/她代表的，并且所提供的支付信息确实与进行购 买的终端用户相关联。可能不存在商家确认购买者的身份和/或支付信息的有效性 的可靠方法。在分布式网络化环境中，购买者可能必须信赖商家的信誉，这会限制 购买者有意进行交易的来源。商家可能必须甚至通过购买者是良好诚信、真诚购买 者的较低确信经营。在不受信任的网络中，该模型可能在一方或双方呈现过度风险。
即使当已经在购买者和商家之间形成确定和值得的信任时，存储由商家维护 的消费者信息的数据库也可能易于受到黑客攻击、信息偷窃、甚至否则会是诚实和 可信的企业内的不良活动者。第三方交易提供者也易于受到电子窃取、安全漏洞等 等影响。更复杂的“间谍”程序使黑客能记录击键并获得已受损害的计算机的屏幕 截图，从而使得基于浏览器的交易特别易于被电子窃取。因此，根据传统的方法和 模型进行在线商业交易的购买者可能易于遭受其机密个人和金融信息的传播和未 授权使用。
常规的商业交易模型通常要求购买者与他想要与之进行商业交易的每一商家 设立帐户。通常，帐户经由登录名和口令得到保护和访问，从而要求购买者管理多 个登录和口令并维护哪一登录/口令组合对应于哪一帐户。一些消费者可能诉诸于 将其登录/口令组合本地地存储在他们的计算机上，或将相同的登录/口令组合用于 所有帐户。管理多个帐户的两种尝试均易于被窃取、黑客攻击和/或其他安全漏洞。
例如，如果通过电子窃取将会获得单个登录/口令组合，则消费者处于他/她的 所有帐户受到破坏的风险。除了与常规的登录/口令范例有关的固有安全风险外， 购买者可能发现帐户登录过程是难用的交易体验。特别地，当购买者需要时必须登 录到帐户使得交易不方便，因为在能完成交易前购买者必须以一种或另一种方式产 生该信息。此外，通过第三方交易提供者，购买者从商家的网站重定向到第三方交 易提供者的网站。该步骤不直观，并且至少对购买者来说是麻烦和混乱的。
申请人已经认识和意识到：将在常规模型中由购买者和浏览器处理的至少一 些交易责任委托给低层系统(并远离浏览器和终端用户)可便于更简单和更安全的 在线商业交易框架。在一个实施例中，由处于终端用户和商家的一个或两个处的操 作系统处理一个或多个交易任务，其中信息得到更安全的保护。通过将一个或多个 任务嵌入操作系统，可减轻用户传送交易信息的一些负担，从而使得体验更为直观 并增强安全性。此外，可使商家免于维护购买者信息、处理支付信息和/或处理交 易。
申请人已经进一步意识到：通过开发比登录/口令模型更安全和方便的技术， 可减轻与验证用户的身份有关的问题。在一个实施例中，由存储有计划发布的、有 关终端用户的身份信息的用户标识模块(SIM)卡提供有关购买者的身份信息。在 另一实施例中，通过嵌入或以其它方式耦合到购买者进行在线商业交易的网络设备 的智能卡提供标识信息。使用各种基于芯片或卡的识别装置允许购买者将他或她的 身份与诸如便携式电话或网络化计算机的特定设备相链接。
术语“有计划地”和/或“自动地”是指基本上无需手动或操作者参与执行的 动作。特别地，有计划或自动是指通过一个或多个计算机程序启动和/或执行的动 作。例如，通过请求用户(例如购买者)提供登录和/或口令信息来提供标识信息 将不被视为有计划，因为是由用户执行动作内容的。然而，程序发出标识信息(例 如SIM号、网络地址硬件ID等等)而不请求用户输入信息的动作将被视为有计划。 注意，这些自动操作可通过软件或硬件组件实现。
申请人已经进一步意识到：将在线商业交易的各个交易要素分布在不同的网 络设备上便于不受信任网络上更安全的商业交易。在一个实施例中，身份提供者和 支付提供者，来自终端用户、商家的单独和不同的网络实体彼此在商业交易期间提 供验证支持。术语“网络实体”在本文中是指网络存在，并且可以是终端用户/购 买者、身份提供者、支付提供者、商家等等的一个或组合。网络实体可经由一个或 多个网络节点存在于网络上。例如，多个网络化设备可在单个网络实体的保护下操 作，诸如利用多个服务器进行在线业务的身份提供者，或经由蜂窝式电话和个人计 算机连接到网络的终端用户。网络实体可以是诸如银行或零售商的企业，或诸如终 端用户的个人。
在一个实施例中，在线交易的各个要素分布在单独和独立的网络实体上。例 如，身份提供者可以商家能用来验证购买者身份的身份令牌的形式提供身份确认。 身份令牌可以包括终端用户的一个或多个身份凭证。可基于由终端用户/购买者提 供的身份信息，诸如来自SIM卡的用户号、网络地址(例如网络接口卡(NIC)标 识、全球名称(WWN)等等)、登录信息等等，发出身份令牌。类似地，支付提 供者可以支付令牌的形式提供对终端用户支付的能力的验证。另外，支付提供者可 代表购买者处理支付交易，以偿还从商家购买商品和/或服务。上述框架尤其允许 作为陌生人的购买者和商家在不受信任网络环境中以相对的信任进行在线商业交 易，如在下文提供的各个示例性实施例中进一步详细所述。
另外，一个实施例提供在线或零售环境中在购买服务和/或商品的商业交易期 间商家、消费者和支付提供者之间的三方安全通信。如在下文中将更详细论述地， 支付令牌从支付提供者经由消费者传递给商家。这些支付令牌通过允许商家直接向 支付提供者验证令牌的真实性，来提供消费者支付服务和/或商品的能力的证明。 尽管这些支付令牌唯一地识别服务和/或商品的支付授权，但有关用于消费者的记 帐帐户的敏感信息既不包括在令牌中，也会以其它方式被加密以致对商家不可见。 因此，消费者敏感信息对商家不透明，从而允许消费者即使在他们之间存在不可信 关系时，也能从商家放心地购买物品。另外，因为商家能向支付提供者直接验证支 付令牌，因此商家能放心地为有能力支付这些服务和/或商品的消费者递送物品， 而不用维护有关消费者的金融信息(例如信用卡号、帐户信息等等)。另外，因为 支付提供者能验证来自消费者的支付令牌的真实性，因此支付提供者能向商家放心 地转帐资金，从而完成三方安全商业交易。
如前所述，用于本文中提供的框架的其他实施例将部分交易转移到计算设备 的更安全子系统(例如操作系统)。这有利地允许许多性能，包括：用于允许合法 应用程序提供带内在线商业交易体验的抽象模型；另外类型的欺诈保护；用于审核、 支付联合和其他支付或验证目的的帐单俘获和呈现；用于另外的安全性和商家专用 功能性的服务提供者代码执行；多级认证；以及其他特征。例如，一些抽象模型允 许合法和其他应用程序向用户提供在线购买和支付能力，就象这些交易直接在应用 程序内发生一样，尽管部分商业交易是在带外执行的。示例包括：目录购买(例如 Amazon、Sears等等)、直接购买来自多媒体应用内的多媒体内容、以试验模式下 载软件/游戏、以及通过带内支付模型自动地解锁它们、允许支持基于预订的服务， 诸如通过电子邮件的短消息服务等等。
另外，在另一实施例中，框架俘获和呈现上述三方安全(和其它)商业交易 中的电子帐户，作为在下文中将更详细描述的用于另外的验证、审核、支付联合以 及其他目的的机制。此外，通过将商业交易转移到子系统的更安全部分，其他实施 例允许商家在机器上运行专用代码(例如另外的用户验证、支付规则/机制、用户 体验等等)，同时信任这些代码将不会黑客攻击或损坏。当然，如在下文更详细所 述地，申请人通过使用在此提供的抽象模型已经进一步认识到其它有利特征。
在又一实施例中，申请人还提供一种使用移动模块来安全传送并认证身份和 对各种不同服务的支付能力的的整体系统和协议。例如，能使用用户标识模块 (SIM)(或其他类似的移动模块)来在多级验证环境中向服务或服务器认证用户 和/或设备。在该实施例中，在与用于移动模块的网络移动基础结构无关的网络上 认证移动模块(以及甚至可能终端用户)。因此，该系统通过向移动基础结构认证 有效记帐帐户，确认拥有移动模块。这使用现有的安全协议(例如WS-认证、WS- 安全、和其他类似的协议)建立了与连接到移动模块和服务(例如Web服务(WS)) 的计算设备的安全通信。这种安全通信也能用来通过其他协议和移动模块与移动基 础结构之间的数据交换认证用户-如下文更详细描述地。另外，其他实施例提供从 移动基础结构抽象计算设备(用在独立网络上的通信中)的协议和状态机。因此， 移动模块本身变为移动终端而计算设备变为外围设备，从而符合当前的无线标准， 诸如3GPP(第三代合作伙伴项目)。
图1示出由多个网络节点组成的商业交易系统100的框图，这些网络节点包 括：终端用户(购买者)计算机110、商家计算机140、身份提供者计算机120和 支付提供者计算机130。上述节点的每一个可包括经由网络105互连的一个或多个 计算设备。应当意识到：终端用户计算机、商家140、身份提供者120和支付提供 者130可与诸如个人、公司或企业的网络实体相关联。例如，终端用户计算机110 通常与采用该计算机来访问网络上的资源的个人相关联，以及商家计算机140可与 提供商品和/或提供服务的公司或企业关联。形成商业交易系统100中的每一上述 部件的一个或多个计算设备可作为相关网络实体在该网络上通信的入口点、计算平 台和/或载体操作。
注意，尽管可在在线购买环境中描述在此提供的实施例，但这些实施例也能 用在直销交易中。例如，商业交易的以上和以下描述能应用于消费者在零售店购买 产品，其中使用支付、识别、授权和其他实施例。因此，将在线体验用于描述本文 中的实施例仅用于示例目的，而不旨在限制或以其它方式变窄实施例的范围，除非 另有明确声明。
注意，网络105可以是互连并允许连接到该网络的节点通信的任何类型配置 中的任何类型网络。节点或设备可经由铜(例如类型5)电缆、光学连接、无线或 其任意组合连接到网络。可以使用诸如以太网的任何低级协议和/或诸如TCP/IP的 任何信息协议传送信息。网络105可以具有与之相连的任意数量的设备，并且可以 是信任(例如内联网)或不受信任网络(例如LAN/WAN、互联网等等)或两者的 组合。连接到该网络的计算机可以是任意类型的设备，包括但不限于移动电话、台 式计算机、平板个人计算机、服务器、工作站等等的一个或任意组合。
图2示出根据本发明的一个实施例的用于在在线交易中启动和执行身份验证 的系统和方法的示图，而图3示出根据本发明的一个实施例的用于在在线交易中执 行支付协商、验证和/或证明的系统和方法的示图。可以单独或组合地使用这些方 法来执行终端用户/购买者与商家之间的在线交易。在下述描述中，除非具体指出， 网络实体及其相关联网络化设备之间不做区分。例如，“身份提供者”通常用来将 身份提供者描述为实体(例如银行、政府机构、代理等等)，并描述为该实体用来 执行各种网络功能的计算设备，诸如提供终端用户的身份验证、或以其它方式代表 实体操作。
终端用户计算机110可以与商家140下订单242。订单242可以是终端用户想 从商家140购买一个或多个商品和/或服务的任何表示。另外，订单242可以由终 端用户经由显示驻留在商家网站上的页面的Web浏览器选择商品或服务而产生， 或可以由从本地运行的应用程序选择选项而产生，如在下文更详细所述地。作为第 一实例的例子，商家140可提供一网站来显示或出售它提供的商品和/或服务，或 可以提供商品的在线目录。订单242可以是终端用户想从商家140购买一个或多个 商品和/或服务的任何类型的表示。
作为第二实例的例子并作为从商家的网站选择一个或多个商品和服务的替代 方案，订单242可源自终端用户计算机110本地的应用程序或其他程序。例如，终 端用户可经由字处理应用程序创建、产生或编辑文档，使用演示应用程序设计幻灯 片、和/或使用图像处理应用程序处理用于海报或宣传册的图像或图形。应用程序 可包括打印菜单下的选项，这些想像允许由第三方打印文档，例如，利用局部不可 用的打印特征，或以其它方式采用专业打印服务。当选择该选项时，应用程序可经 由网络将订单242发送给商家140。应意识到，订单242可以是购买任何商品和/ 或服务的任何表示，因为本发明的各方面并不限于这一点。
响应于订单242，商家140可请求终端用户110提供终端用户的身份和/或终 端用户的确是他/她声称的验证的表示(步骤205)。例如，商家140可能不知道有 关订单242的来源的任何信息，以及可能需要有关终端用户的身份的信息和/或确 保终端用户未欺瞒他/她的身份。另外，商家140可以发送要求支付服务的通知或 表示，并要求提供支付令牌。为获得支付令牌，有必要首先经由身份令牌建立身份， 如在下文更详细所述地。在任一情况下，终端用户110可以通过支持身份提供者 120的服务(步骤215)响应商家140的请求。
为获得身份令牌，终端用户140向身份提供者120提供身份信息。身份信息 可以包括使身份提供者120能区分利用终端用户计算机110的终端用户和身份提供 者可能向其提供服务的各种其他终端用户的任何信息。例如，身份信息可以包括与 终端用户计算机110的硬件相关联的唯一标识符。在一个实施例中，身份信息通过 发出该用户唯一的标识符的SIM卡提供。身份信息可以包括提供终端用户计算机 110的网络接口卡(NIC)的唯一硬件号、终端用户计算机110的全球名称(WWN) 或其他网络地址，或可以识别终端用户计算机110的任何其他手段，包括(在一些 实施例中)所建立的登录名/口令组合。
身份提供者120使用身份信息来定位与终端用户相关联的身份凭证。例如， 身份提供者120可以包括存储有关多个终端用户的身份信息和凭证的数据库。身份 信息可用来索引到数据库中以获得正确的身份凭证。身份提供者120可以是任何类 型的实体。例如，身份提供者120可以是使用由终端用户的SIM卡提供的用户号 码来定位适当标识信息的移动电话公司。在一个实施例中，用户号码被用来在预订 采用SIM技术的移动电话或其他设备时，定位和获得由终端用户提供的信息。身 份提供者120可以是银行、政府机关(诸如机动车登记处(RMV))，或维护与终 端用户相关联的标识信息或凭证的任何其他机构。
响应于由终端用户提供的身份信息，身份提供者120向提供有关终端用户的 身份认证和/或凭证的终端计算机110提供身份令牌(步骤225)。身份信息可以是 另一网络设备能用来认证、验证和/或确定终端用户身份的任何类型的电子消息。 例如，身份令牌可包括终端用户的身份凭证。身份凭证可以包括但不限于姓名、地 址、生日、地址、电话号码、电子邮件地址等等的任何一个或组合。
身份令牌可包括来自身份提供者120的电子签名，从而证明该身份凭证是正 确的。用这种方式，商家和/或支付提供者可以信赖无利益关系的第三方(即身份 提供者)，而不是任意终端用户的代表。在网络上传送前可加密身份令牌，并在由 期望网络设备(例如商家、支付提供者等等，如在下文更详细所述地)接收时解密， 以便防止网络上的偷听。在其他实施例中，支付令牌仅是终端用户身份的凭证，而 不附随身份信息。
身份提供者120可将身份令牌传送到终端用户计算机110，以便转发给商家 140(步骤235)，和/或身份提供者120可以将身份令牌直接传送到商家140。然后， 商家140然后可处理身份令牌以识别终端用户和/或验证终端用户是他/她声称的 人。身份令牌可以用来认证可能影响交易的、有关终端用户的某些信息。例如，商 家140可以提供要求终端用户处于某一年龄的服务。与身份令牌一起传送的身份凭 证可用来确保终端用户处于适当年龄并满足该要求。商家140可对作为常客，或接 收优惠券、促销等等的特定终端用户提供折扣。商家140可以索引终端用户数据库 来基于所提供的身份凭证，确定终端用户是否有资格或应当专门处理。
可任选地，商家140可以通过将请求发送到身份提供者120，请求确认身份令 牌(步骤245)。用于确认身份令牌的请求可以包括将身份信息从商家140转发到 身份提供者120。在接收确认身份令牌的请求后，身份提供者120可以确认该身份 令牌，由此确定身份令牌是否真实。然后，身份提供者120可以将身份令牌的真实 性的表示转发给商家140(步骤255)。可选择地，商家140自身可简单地确认身份 令牌(步骤265)(例如通过假定身份令牌有效或以其它方式处理该令牌)。可任选 地，将响应从商家140返回给终端用户计算机110，其中，响应可包括身份令牌是 否有效的消息、任何可行折扣或促销的消息和/或任何其他类型的消息，因为本发 明不限于这一方面(步骤265)。
在商家140已经处理了身份令牌和/或已经从身份提供者120接收身份令牌的 确认后，商家140可请求终端用户提供支付能力的验证或确认，和/或提供终端用 户希望如何支付商品或服务的表示。商家140可以经支付令牌请求作出请求(图3 中的步骤305)。响应于支付令牌请求，终端用户计算机110可获得支付提供者130 的服务。支付提供者130可以与维护有关各种终端用户的金融和支付信息的第三 方，诸如金融机构、或处理金融事务和支付过程的第三方经纪人相关联。
终端用户计算机110可以通过将身份令牌传送到支付提供者130，从支付提供 者请求支付令牌(步骤315)。或者，终端用户可以用与结合身份提供者120描述 的类似方式(即通过提供标识符，诸如SIM用户号、NIC地址和/或使用登录/口令 组合)，通过登录到支付提供者130上来请求支付令牌。应当意识到：终端用户可 以用其他方式请求支付令牌，因为本发明不限于这一方面。另外，终端用户可以发 送有关购买的信息，诸如购买的价格和性质，以使得支付提供者能验证终端用户能 支付。然而提供购买信息并非是必需的，因为它可能是不必要的或者可在交易的后 续步骤中处理。
支付提供者130处理身份令牌(或其他所提供的标识符)以定位有关终端用 户的信息。例如，支付提供者130可基于与身份令牌一起传送的身份凭证访问支付 信息数据库。支付提供者130可确定什么支付能力和选项为所识别的终端用户所 有。然后，支付提供者130可验证终端用户具有支付的能力，并作为响应生成支付 令牌并将其传送到终端用户计算机110(步骤325)。支付令牌可以表示终端用户的 支付能力、和/或支付提供者130愿意代表终端用户处理交易的证明。然后，终端 用户计算机110可以将支付令牌转发到商家140(步骤335)。
商家140处理支付令牌，以使得商家140确信终端用户能支付商品或服务(步 骤365)。例如，商家140可以要求支付提供者130确认支付令牌(步骤345、355) 或可自身简单地确认它(步骤365)(例如通过假定支付令牌有效或者以其它方式 处理该令牌)。然后，商家140开始将商品和/或服务提供给终端用户的过程。因为 支付提供者130可以是无利益关系的第三方，商家140可以将支付令牌基本上视为 支付，并且不必等待直到完全处理该交易为止。
当在传统的交易模型中商家直接与终端用户交易时，商家可能必须确保由终 端用户提供的支付信息正确并且足够。例如，商家可能必须通过信用卡系统运行所 提供的信用卡号，以查询该号码是否有效、该卡是否有效、是否有足够的资金、和 /或该卡是否正确地与由终端用户提供的身份相关联。如果一些信息不合格，则可 能不得不取消、终止或放弃交易。此外，在终端用户感到交易完成、并且不再访问 该网络和/或不再访问商家的网站等等之后，交易终止可能发生。
然后商家必须通知终端用户该交易存在问题，并且终端用户将不得不再次线 径该交易来校正问题(例如通过正确地输入支付信息，指定具有足够资金的不同卡 等等)。在一些实例中，可能不通知终端用户，并且该商业交易永不会完成。
在本文中所述的不同实施例中，因为除非终端用户支付信息正确、足够资金 可用和/或提供者证明将代表终端用户支付将不发出支付令牌，所以商家能立即继 续交易。交易中的任何缺陷可以实时地识别和解决，以使得所有各方能相对地确信 关于交易完成是满足预期的。
另外，因为支付提供者可处理金融交易(例如处理信用卡、转帐等等)，商家 可以免于建立和维护例如处理信用卡号、或以其它方式处理支付过程和资金转帐所 需的基础结构。在一些情况下，支付令牌操作为支付提供者能通过电汇或通过向商 家电子资金转帐传送所指定资金的保证。支付令牌也可以是将通过非电子手段进行 支付的保证，诸如承诺向商家发出支票或其他可流通票据。
从商家的观点看商业交易基本上无风险，因为终端用户的身份和支付验证是 由第三方处理的，因此较不易于受欺诈、哄欺并且甚至在提供个人和金融信息时的 无知错误。因此，商家可能更愿意在不受信任网络上与未知终端用户进行在线商业 交易。从终端用户的观点看，个人和金融信息属于已经维护该信息和/或终端用户 已经与其建立关系的实体。机密的个人和金融终端用户信息不必提供给商家，从而 减少机密信息被误用或盗用的弱点。因此，终端用户可能更愿意与未知商家进行商 业交易，而不必担心商家是否可信。
在一些常规的商业交易模型中，身份信息和支付信息由用户输入，并由第三 方或商家处理。如上所述，这些模型对用户来说是难用、不足和耗时的。另外，常 规的模型呈现有关终端用户的保密信息的安全性、以及商家易受欺诈和/或终端用 户易发生支付故障的各种问题。申请人已经意识到：在各种商业交易中利用的计算 机的每一个所安装的商业交易软件可以减少或消除有关安全和欺诈的问题。另外， 可通过商业交易软件执行常规模型中由终端用户和商家处理的许多动作，从而使交 易更简单并且对终端用户更直观。
图8示出将如上所述的一些特征用于可以在商业交易期间建立的三方安全通 信和各种信任界限的一个例子。如下文更详细描述地，该模型允许单一或预订支付 以及支付联合，以使得服务或商家能聚集更小公司的支付，从而允许消费者支付单 一帐单。如途所示，分布式系统800被配置成便于消费者810、商家830和支付提 供者805之间的商业交易。支付信任界限815将商家830与消费者810/支付提供者 805分开，以使得在支付提供者805和消费者810或消费者计算设备(即使用如本 文中所述的可用机制的任何一个向支付提供者适当地识别或自身验证消费者)之间 存在信任关系。因此，消费者810能利用该信任关系来对各种类型的支付和各种服 务授权对商家830的支付。
例如，假定商家830要求预付消费者810想购买的产品(例如要求预付的消费 品，如汽车、计算机等等)。然而在请求支付授权前，如本文中所述，消费者810 计算设备的用户可以要求适当地验证。只要用户认证，消费者810计算设备能通过 如本文中所述的任何不同机制适当地请求支付提供者805支付。例如，消费者810 可向支付提供者提供由消费者810的计算系统签名或加密的其他请求信息。这认证 了对帐户拥有者(即消费者)适当支付能力的确认的请求(即，用户具有预付帐户、 信用额或其他记帐帐户，诸如如下所述的移动用户)。如果成功，则发出支付令牌， 然后预留用于保证支付的资金。通常由支付提供者(例如本文中所述的移动网络服 务器)签名和/或以其它方式加密该支付令牌，并传递到消费者810客户机。消费 者810将该支付令牌传送回商家830，商家830向支付提供者验证该令牌，并且如 果成功则完成该订单。
一旦准备递送物品(例如已经确立消费物品)，商家830就能使用该预留支付 令牌来请求支付提供者830支付。注意，用于支付请求的金额可以不同于所预留的 金额。尽管如此，支付提供者805验证并向商家830和/或消费者810返回支付响 应。如果被核准，则商家830能向消费者810运送(或者提供)该订单，并提供其 支付。另一方面，如果拒绝支付或要求进一步的用户交互，则商家830、支付提供 者805和/或消费者810能选择采取什么动作。例如，如果由商家830请求的金额 不与预留的资金匹配，则支付提供者805和/或商家830可以请求消费者810授权 新的金额。另外，支付提供者805可要求授权转帐资金的用户输入，不管预留和请 求的支付金额有任何变化。当然，在此也可构想用于完成商业交易的其他动作和过 程。
注意，尽管上述三方安全支付机制用于购买预订物品，但整笔支付也可以应 用于其他服务和/或商品。例如，整笔支付机制可以应用于准备立即下载的软件程 序。可选择地或连同地，整笔支付可解锁下载的各级程序(例如学生版本、专家版 本或其他单独的功能性)。事实上，将意识到上述整笔支付能用于各种不同类型的 购买，一部分以略有改进的支付形式。
例如，假定消费者810想与商家830建立预订以继续服务(例如报纸或杂志预 订、电影预订、游戏应用程序、或其他到期即付商品和/或服务)。因此，商家830 将向消费者810询问支付令牌，由此消费者810客户机可以与请求授权以继续的用 户交互，如本文中所述。与上文相类似，消费者810签名或以其它方式加密支付请 求(例如使用电子记帐信息，如下文所述)并将该请求发送到支付提供者805(例 如移动运营商、信用卡公司、预付或其他类型的第三方服务等等)。这认证该请求 并验证帐户持有者(即消费者或顾客)具有足够的初始资金。如果成功，则发出、 签名和/或加密支付令牌，并返回给消费者810客户机，该客户机将支付令牌传递 回预订商家830。商家830然后验证令牌的确认并完成预订设置。
注意，通常支付令牌存储在商家830，并且在由支付提供者805请求预订支付 时定期使用。因此，当处理预订支付时，商家830检索支付令牌并将其发送到支付 提供者805，用于支付结算。支付提供者805验证并向商家830和/或消费者810 返回支付响应。如果返回准许响应，则预订商家830将在下一支付提供者805帐户 支付运行期间接收支付。然而，如果支付请求被拒绝，则支付提供者8705和/或商 家830可以适当地响应。例如，商家830(或支付提供者805)可以与用户或消费 者810联系(例如经由电子邮件)，告知他们未付清支付。消费者810然后能执行 如上所述的整笔支付，或通过同一或不同支付提供者805设置另一预订支付。当然， 商家830、支付提供者805和/或消费者810可以具有用于处理这些和其他支付授权 的其他规则或要求，如在下文更详细所述地。
如前所示，其他实施例允许单个消费者810支付与具有契约安排的多个业务 伙伴或子公司的联合。通常业务关系是复杂的，并且要求分配对在特定企业模型内 所提供的各种服务和/或商品的支付。例如，当从旅行社830购买旅游时，可为消 费者810提供一揽子交易，包括航班安排、酒店住宿、护照服务等等。因此，通常 包出许多这些服务和/或商品的商家830必须保存这些商业交易的详细帐目，以便 对其业务伙伴进行适当的支付。为减轻这些记帐和其他任务的复杂性，本文中的实 施例基于每一交易向特定类型关系内的业务伙伴提供自动支付联合。
例如，汽车租赁服务(例如业务伙伴“A”820)可要求商家830支付，作为 假日捆绑销售的一部分。保险公司(例如业务伙伴“B”825)可以基于每一交易 费向商家830收费。基于业务伙伴信任界限835，在对商家830进行单一支付时， 可以将支付自动地与每一业务伙伴(例如“A”820和“B”825)结盟。换句话说， 消费者810或支付提供者805对商家830进行单一支付，然而能适当地支付具有根 据业务模型835的信任界限的业务关系的所有子公司。注意，这种支付将通常依赖 于电子记帐报告书，如在下文更详细所述地。更具体地，用于俘获、呈现和其他目 的的电子帐单的各个部分能对应于支付的什么部分应当联合到每一业务伙伴。另 外，可以签名和/或加密这些部分的每一个以使得有关支付的特定信息对消费者 810、支付提供者805、或在如由不同信任边界815、825定义的不同业务伙伴820、 825之间是不透明的。
注意，尽管相对于旅行社体验描述了上述支付联合模型，但也存在能使用该 实施例的其它业务关系。例如，构建具有通过不同供应商购买的多个部件的物品的 公司、购买用于这些产品的材料并基于每一物品进行支付的产品提供者、基于每一 销售支付版税的多媒体产品的支付、或捆绑或能以其它方式基于每一物品计算并对 业务伙伴进行支付的任何其他类型的业务模型也可使用在此所述的实施例。同样 地，将旅行社用于描述本文中的各个实施例仅用于示例目的，且并不旨在限制或变 窄在此所述的实施例。
图4示出根据本发明的一个实施例的用于处理商业交易的网络化计算机系统。 网络化计算机系统400可以与图1所示的计算机系统100类似。然而，在图4中， 系统400中的每一计算机包括本地安装的商业交易软件485。特别地，终端用户或 消费者计算机410、身份提供者420、支付提供者430和商家440分别包括商业交 易软件485a-485d。本地地安装在系统中的每一计算机上的商业交易软件可以是相 同的，或鉴于计算机在交易中所起的作用(即计算机是操作为终端用户节点、商家 节点、身份提供者节点、支付提供者节点等等还是上述的一些组合)可以对特定计 算机定制。在任一情况下，将每一安装配置成与其他网络化计算机上的安装件通信 以便执行在线交易。例如，可以将每一安装件配置成与网络化计算机上的安装件通 信，以便执行图2和/或图3所示的方法。
在一个实施例中，在身份提供者420上本地安装商业交易软件485a能创建利 用终端用户计算机410识别终端用户的身份令牌。此外，身份提供者420上的商业 交易软件485a能将该身份令牌转发给终端用户计算机410、支付提供者430、商家 440和/或任何其它计算机，因为本发明不限于这一方面。在终端用户计算机410 上本地安装商业交易软件485b能响应在终端用户和商家间进行在线交易的表示， 发出身份信息(以便于识别终端用户)。本地安装在支付提供者430上所安装的商 业交易软件485c能接收身份令牌和生成验证终端用户支付(例如支付令牌)在线 交易的能力的支付令牌。本地安装在商家440上所安装的商业交易软件485d能接 收终端用户的能力的验证以便在继续进行在线交易前支付。
在一个实施例中，系统400中的每一计算机使用相同或类似的操作系统495 的本地安装操作。例如，系统400中的每一计算机可以使用Microsoft Windows 操作系统操作。商业交易软件485可以是操作系统的子系统。用这种方式，用在商 业交易中的各个计算机以一致和已知的方式通信。由于商业交易软件在网络上直接 通信并处理确认、验证和安全性，因此终端用户和商家不必知道有关彼此的任何信 息，并且更重要的是不必建立任何信任关系。另外，因为交易的某些部分是由操作 系统处理的，所以大部分交易可以基本对用户不可见地执行，而不需要终端用户的 混淆并且常常困难的参与。
通过在每一计算机上具有商业交易软件，各种加密技术可在将信息从一个计 算机传送到另一个期间使用。此外，可以包括在有限时间周期内有效的其它安全特 征，诸如身份令牌和/或支付令牌。例如，身份令牌可以包括指定时间的时间分量， 在该时间之后接收和处理令牌的任何组件应当视为无效，以及将该令牌视为身份和 /或支付的验证。商业交易软件组件可以有计划地处理与令牌有关的任何时限。这 可以防止通过从在稍后时间不适当使用“钓鱼”获得令牌。
应意识到：商业交易软件不必是操作系统的一部分，但可以是参与能在网络 上彼此通信的商业交易的计算机的任何本地程序或程序组。例如，商业交易软件可 以是由第三方开发的应用程序，它能安装在计算机上以在安装于计算机上的操作系 统上操作或与之无关地操作。可以将应用程序配置成与操作系统的任何一个或组合 操作，以便于对广泛性能和配置的计算机或设备可用，并且不限于任何特定的操作 系统、处理器、指令集等等。
图5示出由选择一个或多个所需商品和/或服务的终端用户发起的商业交易， 其中购买的交易部分至少部分地由分布为参与一个或多个交易的各个计算机的操 作系统的一部分的交易软件子系统处理。通过终端用户计算机510连接到网络505 的终端用户可以运行应用程序555。应用程序555可以是显示提供商品或服务的企 业网站的浏览器。应用程序555可以是提供参与在线交易的选项的应用程序，诸如 允许用户操纵图像的图像处理编辑程序。
终端用户可以经由应用程序555选择一个或多个商品或服务来购买。例如， 终端用户可能希望使经编辑的图像专业地打印在照片质量纸上。应用程序555可在 打印菜单下包括此选项。打印选项在被选择时可生成列出所有可用打印选项，包括 可在网络上使用的服务的窗口或对话框。例如，打印选项可以列出服务提供者 540a、540b、540c，作为用于提供打印服务的选项。当用户选择服务提供者之一时， 可启动如上所述的在线商业交易。特别地，业务提供者可以请求终端用户提供身份 令牌。作为响应，应用程序555(或嵌入商业交易软件585中的应用程序)可以生 成列出可用身份提供者的对话框或界面。例如，如在下文更详细所述地，对话框可 以列出身份提供者520a、520b、520c，作为用户能选择以处理身份验证的可能身 份提供者。
图9示出分布系统中并根据示例性实施例的受信任商业子系统和其他特征的 使用。如所示，分布式系统900内的本地计算设备920被配置成根据本文中所述的 实施例提供在线或本地零售交易。注意，尽管受信任商业交易子系统965仅示为本 地计算设备920的一部分，但类似子系统也可以驻留在其他网络实体上。另外注意， 尽管本文中将各个组件或模块描述为驻留在任何特定网络实体上，但这些组件或模 块可分布在整个计算系统上，并驻留在任意数量的网络实体上(即，各个部分可以 存在于一个或多个网络实体上)。因此，网络设备或实体对特定模块的特定美学布 局和使用在此仅用于示例目的，并且不旨在限制或变窄在此的实施例的范围。
不管计算系统900的分布和美学布局如何，如前所述，存在分离各个组件之 间的信任关系的信任边界906。尽管可以不同地划分该关系，但在本例子中，信任 关系存在于支付提供者900于信任商业交易子系统965之间。这有利地容许当前商 业系统不能提供的许多特征。例如，信任边界906从与商家的商业交易中抽象应用 程序925。因此，早先版本和其它的应用程序925可向终端用户940提供带内体验， 尽管大部分功能出现在带外。例如，在允许在照片质量纸上打印专业图像的上述例 子中，下拉菜单内的选择、身份确认、支付选项和用于帮助用户进行这种服务购买 的其他组件显现为应用程序925的一部分。另外，应用程序925在接收购买服务和 /或商品的输入时可对信任商业交易子系统965进行购买呼叫930，然后使用该购买 呼叫来生成对话框，接收用户940输入935，或者以其它方式自动地与商家905和 /或支付提供者990通信，如本文中所述。
换句话说，在商业交易中用户940并非必需信任应用程序925或商家905。相 反，信任限于当前框架的子系统965，这降低秘密和安全地执行商业交易所需的信 任度或等级。即，经由子系统965的直接用户输入935，或从安全960帐户信息存 储945访问用户940的帐户明细950，该帐户明细包括用户不愿或不方便公开分享 的敏感信息955(例如信用卡信息、个人信息、用户名/口令等等)。同样地，从受 子系统965控制的金融和其他记帐帐户明细955中抽象应用程序925、商家905和 其他组件，如在本文中所述。这与如上所述的当前商业交易非常不同，其中应用程 序925或商家905维护和控制帐户信息。因此，本文中所述的该实施例和其他实施 例在商业交易期间有利地提供另外的安全级。这是直接得多的信任关系，以便于最 小化有权存取或接触非常敏感的金融数据的组件或机构的数量。
如图9所示，与上述三方安全商业交易类似，信任边界906还表示支付提供 者与受信任商业交易子系统965之间的安全通信。因此，子系统965以在此所述的 各种方式向支付提供者900验证，从而允许与其的安全通信。与上述类似，本地计 算设备(可以是本地零售交易中的如下所述的手持便携式设备，在线交易中的个人 计算机，或如本文中所述的其他类似设备)想要由商家905提供的各种服务和/或 商品。在该例子中，记帐信息910被提供给本地计算设备920，用于认证、审核和 如在此所述的示例性实施例中所使用的其他目的。这种记帐信息可以包括但不限 于：商品和/或服务的价格、商业交易的详细描述、商家905特定信息、联合支付 信息、交易类型(例如整笔支付、预订等等)或其他类型的记帐信息。帐单信息 910也可包括其它信息，诸如商家约束和支付选项，如在下文更详细所述地。
在一个实施例中，帐单信息910是配置成机器可读的电子帐单，它为当前商 业交易系统提供许多有利能力。例如，一个实施例提供记帐信息910能是支付令牌 请求980的一部分(或以其它方式在另一通信中传送给支付提供者990)，如前所 述。同样地，该帐单信息可由支付提供者990用于支付令牌确认940。更具体地， 在支付令牌确认904中，由消费者或本地计算设备920提供的帐单信息910能与由 商家905提供的支付令牌985信息相比。因此，如果用于支付令牌确认904的帐单 信息910与来自令牌请求980的帐单信息910匹配，则支付提供者990能进一步确 保支付令牌985的真实性和商家的可靠性。
注意，来自商家的帐单信息910如何中继到支付提供者990(以及本文中的其 他组件)可以改变。例如，从商家905发送到支付提供者990的帐单信息910可以 是发送给受信任商业交易子系统965或客户920的帐单信息910的副本。可选择地， 或者连同地，帐单信息910可以是经由消费者或本地计算设备920路由的来自支付 提供者990的签名和/或加密版本。在任一情况下，支付提供者能进行前述比较， 用于认证支付令牌985。
进一步注意：如由支付提供者990使用的这种帐单信息910也能用来提供与 帐单有关的费用的更详细描述，该帐单后来将提供给用户以便在用户帐户上收费。 因为这也可以是机器可读帐单910，所以本地计算设备920可将该帐单信息910与 由商家905先前接收的帐单进行比较，用于进一步授权对商家905的支付。换句话 说，如果来自支付提供者990的帐单内的帐单信息910不与从商家905接收的任何 帐单相匹配，则该收费将视为欺诈。
在另一实施例中，商家905能将该帐单信息910用于审核用户和其他验证目 的、支付联合等等。例如，商家能签名或以其它方式加密帐单信息910的一部分。 这允许本文中所述的实施例中的多个有利特征。例如，帐单信息910可以是由支付 提供者经由本地计算设备920接收的支付令牌985的一部分。商家905能校验帐单 信息910的真实性，用于认证支付令牌985来自客户机920或受信任商业交易子系 统965。类似地，在支付令牌确认904期间，商家905能使用从支付提供者990接 收的帐单信息910来确认或认证支付提供者990和/或本地计算设备920。换句话说， 因为帐单信息910经由子系统965或消费者920路由到支付提供者，所以与发送到 客户机920的相匹配的、从支付提供者接收的记帐信息能认证客户机920和来自支 付提供者990的支付令牌985。
注意：在另一实施例中，如上简短所述地，帐单信息910也可由商家用于支 付联合。在该实施例中，帐单信息910的不同部分可以是机器可读的，用于确定来 自支付提供者990的资金的哪些部分(在成功支付验证后)应当分配给如前所述的 业务伙伴。注意在该实施例中，通常帐单信息910的一部分将被加密或以其它方式 对用户940(或消费者客户机920)、支付提供者990或不是与商家905的业务关系 的一部分的其他组件不透明。这也唯一地识别记帐联合中的业务伙伴，以及能由此 用于认证目的。更具体地，专用于业务伙伴的帐单信息910的各个部分能使用该业 务伙伴专用的密钥加密，从而该记帐信息仅可被商家905和特定业务伙伴看见。然 而，在其他实施例中，用于支付分配或联合的帐单部分仅由商家905签名，由此对 系统900中的其他组件不透明。
当然，如将认识到，帐单信息910的其他用途也能用于各种目的。例如，记 帐信息910能用于审核目的、产品分发核对，或任何其它众所周知的业务和其他目 的。因此，用于授权、识别、支付联合或任何其它目的的帐单信息910的上述用法 仅用于示例性目的，并且并不旨在限制或者变窄实施例的范围，除非另外明确要求。
注意，信任边界906和子系统965也具有本文中所述的其他实施例中的其他 有利特征。例如，如图9所示，子系统965中的支付提供者代码970允许安全地运 行专用于一个或多个支付提供者990的代码。这种代码能用于专用于支付提供者的 进一步授权，例如生物测定、射频标识(RFID)、用户名/口令或任意多个另外的 验证技术。换言之，由于支付提供者990具有与子系统965的受信任关系，因此支 付提供者能运行受信任代码，用于其专用业务目的。
使用这一代码970也允许可受与子系统970具有信任关系的支付提供者990 或任何其他组件控制的更综合的带内用户体验。例如，尽管未示出，但受信任关系 可以存在于一些商家905和子系统965之间，用于允许受信任代码由子系统965 运行。同样地，参与商业交易的商家905、支付提供者990或任何其他组件可提供 综合用户体验，就象显现为在应用程序925(早先版本等等)内运行一样。然而， 许多事件出现在带外。例如，在由专业服务对图像进行照片质量打印的上述例子中， 可通过各个受信任网络实体(例如支付提供者990、商家905等等)专门提供的代 码970控制呈现给用户的对话框、支付选项或任何其他数量的特征或应用程序功能 (例如响应于用户输入)。因此，如下文更详细所述地，当由商家905和/或支付提 供者990评价支付选项和其他约束时，也能使用该代码。
如上所述，在一个实施例中，所选服务提供者或商家将任何要求和身份验证 请求传送给身份提供者。例如，服务提供者可以出售要求最小年龄或限定于某一地 理位置的商品或服务。因此，可以将身份提供者的清单限定到能提供满足服务提供 者的要求的身份凭证的那些身份提供者。例如，身份提供者的清单可以限定到能提 供年龄验证或当前地址信息(诸如RMV)的那些身份提供者。
同样地，可以生成列出支付提供者的选项的对话框。例如，对话框可以列出 支付提供者530a、530b和530c，它们可分别包括信用卡公司、提供电子借记服务 的银行、或提供金融服务的私人第三方。关于身份请求，所选服务提供者可包括与 购买相关联的任何支付请求。例如，服务提供者可以仅接受某种类型的信用卡。然 后，在支付提供者选择对话框中列出或使能的可用支付提供者中反映这些支付要 求。在选择支付提供者后，支付证明可以继续进行并且可以完成交易。
注意，其他实施例也提供商家约束(例如可用支付选项、年龄限制等等)与 消费者规则的比较，用于确定可采取的各个动作。图10示出这一实施例，其中分 布式系统1000被配置成有计划地基于诸如商家约束1010和/或消费者规则1035的 这种信息确定动作。例如，商家1020可在商家约束1010内定义购买其服务和/或 商品可接受的支付提供者1005或支付类型。然后，判定模块可以向用户提供这种 约束，例如在请求用户输入1040的用户界面中用于选择一个或多个可用支付选项。 基于用户输入1040，可联系适当的支付提供者1005来适当地资助服务和/或商品。
在另一实施例中，除了或代替商家约束1010，也能使用消费者规则1035。例 如，消费者规则1035可表示对某些类型的商家1020仅可进行某些类型的支付。更 具体地，消费者规则1035可表示：如果未注册或以其它方式信任商家1020，则能 返还的支付可用于从商家1020的购买。
当然，如上所述，当确定在商业交易中采取的动作时，能由判定模块1030使 用其他商家规则1010和消费者约束1035。事实上，为了兼容性和其他目的，可以 比较商家约束1010和消费者规则1035。例如，当向用户提供支付提供者1005的 选择时，可将来自商家1020的可用支付选项与消费者可获得或允许的支付提供者 1005进行比较。当然，基于诸如缺省设置、提供者额定值或喜好，或任何其它数 量的选项设定值，也可自动进行支付选择。事实上，基于各个商家1010和/或消费 者1035规则的实现，可进行任何数量的动作。例如，如果规则(商家1010或消费 者1035)失败或者以其它方式被违背，则可能需要来自商家1020或用户1040(自 动地基于另外的规则或设定值)的附加输入来解决冲突或其他差异。因此，实现所 定义的约束和/或规则时所采取的任何特定动作在此仅用于示例目的，并且不旨在 限制或者变窄在此提供的实施例的范围。
另外注意，如上所述，商家约束1010可被包括在记帐信息内或单独地提供给 消费者。同时还注意到，比较各个规则和由此采取的动作均可以在这些范围下进行， 即，无需用户知识和/或其他系统组件。另外，注意本系统不限于仅由消费者或商 家定义的约束或规则。例如，支付提供者也可以定义能结合或代替消费者和/或商 家规则考虑的各种限制。因此，将商家和消费者约束用于确定各种动作(诸如支付 提供者选项)在本文中仅用于示例目的，并且不旨在限制或者变窄在此所述的实施 例，除非另有明确要求。
在常规的在线交易中，终端用户和/或服务提供者均难以肯定地了解交易何时 结束以及是否已成功地递送商品或服务。例如，终端用户可以选择用于在网络上下 载的软件包，或终端用户可以购买歌曲、电影或其他电子媒体。有时网络连接可能 在下载完成前断开。在这些情况下，可能吸引终端用户再次选择商品，但也可能犹 豫，因为终端用户不知道他或她是否将为此购买付双倍费用。同样地，服务提供者 也可能不知道下载是否成功地完成，以及当用户尝试通过再次选择该商品补救该破 坏时是否可能收取双倍费用。
申请人已经意识到在商业交易软件中提供记录或审核能力可以消除有关电子 下载的一些不确定性。例如，最终执行支付选项可取决于来自下载完成的审核特征 的信号。那样，如果下载中断，则终端用户能确定所选支付选项未通过。例如，来 自图5的商业交易软件585(或在此所述的其他子系统或网络实体组件)可以包括 记录由机器进行的商业交易的所有各个步骤的记录功能部件。记录信息可用作购买 的证据或用来记忆交易。另外，商业交易软件585可包括对电子下载的监视能力， 该软件仅在将进行最终支付后发送成功下载的确认。通过视在成功完成商品或服务 的传送的信号而定进行支付，可以解决和基本上消除双倍记帐的问题。
可以由公司开发软件来处理各种任务，包括常见的字处理和文档处理、电子 表格、图像编辑、甚至更专业的任务，诸如视频编辑、计算机图形软件、网络内容 开发应用程序、证券管理软件等等。然而，拥有处理终端用户可以希望执行的每一 任务的软件可能贵得惊人。软件包能花费大概几百、几千、到几十甚至上万美元之 间，以获得单一许可。此外，终端用户可能需要偶尔或零星地需要特定应用的服务， 从而购买该应用的价格可能是不合理的。
申请人已经意识到允许终端用户在帐单到期即付环境中利用软件的优点。特 别地，可以仅对使用该应用程序所花费的时间量向终端用户收费，而不是支付该软 件的零售价(其中，基本上不使用许多功能部件和/或应用程序)。图6示出具有允 许终端用户支付使用该应用程序所花费的时间量的商业交易框架的网络化计算机 系统。网络化计算机系统600包括将终端用户节点610与多个身份提供者620、多 个支付提供者630和多个服务提供者640互连的网络605。
终端用户节点610可以是在操作系统695上运行的计算机。可以在终端用户 计算机上安装多个软件应用程序655。软件应用程序可在购买时与计算机捆绑，可 以在网络上免费下载，或者由应用程序的销售者分行(通常免费或极少费用，或用 于向供应商注册)。应用程序655可以是任何类型的应用程序，并且任意数量的应 用程序可以安装在计算机上。服务提供者640可以与安装在终端用户计算机610 上的一个或多个应用程序相关联。例如，服务提供者640a可以是由应用程序655a 的开发者和销售者所拥有的一个或多个计算机。类似地，服务提供者640b和640c 可以分别与应用程序655b和655c相关联。
在到期即付的模型中，由服务提供者提供的服务是使用安装在计算机上的相关联应 用程序的许可。例如，当免费分发软件(例如应用程序655)时，它首先被禁用， 从而在首先未获得来自应用程序的销售方的许可的情况下，用户不能运行该应用。 可通过启动与一个或多个服务提供者640的商业交易获得该许可。例如，应用程序 655a可以是终端用户想使用几小时来设计卡或小册子的桌面出版应用程序。当终 端用户打开应用程序655a时，终端用户被告知该终端用户需要购买许可来使用该 应用程序。例如，可以显现对话框，列出各种使用许可能力的特征和价格。
许可可用于特定时间量，例如一小时或一天。一旦关闭应用程序，许可就可 能过期，或者许可能仍然有效，直到期限届满为止。许可可基于允许终端用户完成 一个或多个作业或采用一个或多个所需功能部件的操作或任务。将使用的附加功能 部件可以增加许可的价格。应意识到，可以协商具有任何所需期限的许可，因为本 发明的各方面不限于这一方面。
一旦终端用户已选择了许可选项，就可以指示终端用户选择身份提供者和/或 支付提供者，或者可以缺省地选择一个或另一个来启动在线交易。可以通过基本上 如在以上或以下实施例的任何一个中所述的商业交易软件685处理交易。当服务提 供者从支付提供者620的一个接收支付令牌时，服务提供者可以根据在发起交易时 达成的期限传送许可。
可由总许可服务690处理所接收的许可，以使得对该应用程序的适当可访问 性可被调用。总许可服务然后可向应用程序655发出使能密钥，以使用户能根据许 可运行该软件并利用其功能。使能密钥可包括应用程序可能需要的任何信息，以便 在许可中所示的期限内提供所需服务。使能密钥可包括由服务提供者提供的口令， 以使应用程序知道该许可有效和/或可简单地由能获得有效许可的总许可服务690 依赖该代表。一旦应用程序运行，就可以通知计量引擎694跟踪时间并向应用程序 表示许可何时过期。或者，可编程该应用程序以定期地查询计量引擎，然后在许可 已过期时禁用自身。此外，通过查询计量引擎，如果许可包括一期限，则应用程序 可以向用户提供有关所购买的许可中剩余的时间量的定期警告或更新。
当终端用户结束时，他可选择专业地打印整个产品、并选择启动另一在线交 易，诸如结合图5所述交易的打印选项。到期即付许可可向用户提供多得多的灵活 性，以及使他们有权访问由于购买具有生存期许可的软件包的价格而在先前未访问 过的软件。另外，软件供应商能利用来自不愿意支付全部零售价格、但愿意支付有 限使用和/或有限功能的用户的利润。
软件盗版影响整个软件行业的利润。每年非许可软件的用户令企业损失相对 大量金额。一旦已购买软件产品，销售者就对在何处安装软件和多少计算机安装该 软件几乎没有控制。在互联网上非法提供软件下载提供更普遍的方法来分发和获取 终端用户未付费的软件。申请人已经意识到：提供具有到期即付方案的相对安全和 简单的商业交易框架，例如在图6中所示实施例中所述的框架可以减轻或消除盗版 问题。由于销售者免费分行软件，因此终端用户能盗用该软件，只要他们认为合适。 由于仅通过支付期限许可或任务许可使能该软件，因此基本上限制终端用户误用该 软件的能力。
如前所述，本文中的实施例允许使用与移动基础结构或操作系统的特定记帐 帐户相连的移动模块(例如用户标识模块(SIM))认证身份和/或支付。与经由受 信任无线电网络产生的移动通信的典型标准不同(例如全球移动通信系统(GSM)、 第三代合作伙伴项目和其他类似协议)，根据本文中实施例的验证在独立的不受信 任数据网络(例如互联网)上进行。因此，本文中的实施例解决由在网络服务和其 他独立的网络协议环境中使用该移动模块(SIMs)引起的许多另外的安全问题。 这些安全问题包括：确定用于认证服务器的受信任网络端点、向移动模块或SIM 设备认证客户机、认证SIM设备的用户、认证SIM和认证服务器、在移动模块与 网络认证服务器之间建立安全网络连接、以及认证网络认证服务器的用户。
此外，为了符合GSM、3GPP和其他标准在终端设备上设置另外的要求，该 终端设备将与移动模块或SIM设备交互。更具体地，GSM、3GPP和其他类似标准 要求SIM限制移动终端对某些类型的信息，包括加密密钥的访问。为满足这些要 求，本文中的实施例提供将某些消息和安全性的处理和解码委托给SIM设备本身 的抽象安全配置。例如，如图11所示，防火墙1090定义用于当在独立网络1060 上通信时从主机设备1070抽象SIM 1085的状态机和协议消息。更具体地，防火墙 1090使用限制或限定从主机1075内的读取驱动器发送到SIM 1085本身的命令的 数量和/或顺序的正式状态机。因此，SIM设备1080(例如蜂窝式电话、SIM接口 等等-注意“移动模块”表示用于“SIM”的总术语，但在此可互换地使用，除 非另有特别声明)变为移动终端，而主机设备1075变为符合移动网络1050的通信 协议1055的外围设备。下文更详细地描述用来解决上文概述的一些另外的安全要 求和问题的一些状态机和协议。
本文中的实施例根据给定安全令牌可代表的各个安全级，定义用于在不受信 任独立网络(即与对应于移动模块的基础结构或营运商系统的无线电网络无关的网 络)上认证的安全配置。这些包括但不限于设备安全级、网络安全级、用户安全级 和服务安全级。在每一层上，具有用于获得安全令牌的不同要求和过程。因此，如 在下文更详细所述地，每一安全级表示安全模型中的不同认证等级并分别具有某些 要求和/或保证。另外，应注意到每一安全级可以或可以不独立于其它等级。另外， 在能实现网络或用户安全级前，可能不必建立设备安全级；然而，为适当保证，这 种分层过程可能是合乎期望的。
设备安全级表示物理拥有移动模块，例如诸如便携式电话的SIM设备。通常 在由用户适当认证后，由移动模块或SIM设备本地地发行设备令牌(即具有设备 安全级的SIM安全令牌)。通常由移动基础结构或移动运营商正常设置用于认证移 动模块的用户的这种要求。另外，通常由SIM设备实施设备认证，然而，其他实 施例可提供其他组件在认证过程中的使用。例如，SIM或其他设备可以在移动模块 或其他设备将发出设备令牌前要求口令。当然，在此也可预期用于在设备级上认证 的其他形式的凭证。
在一个实施例中，SIM设备要求客户机或主机计算机在设备安全令牌发出前 对移动模块认证或识别本身。另外，通常使用由移动基础结构设置的策略，由移动 模块或SIM设备控制设备令牌的使用期。在一个实施例中，由移动运营商设置的 使用期或其他要求可通过独立和/或无线电网络动态地配置。如果设备令牌不具有 使用期或其他限制，那么通常该SIM不要求用户向移动模块重新认证一次以上。
网络安全级表示在不受信任独立网络上，移动模块或SIM与移动基础结构或 网络之间的加密连接。假定可由客户机或主机访问解锁SIM设备，就能建立网络 安全级，而不用用户存在或用户交互。通常，网络安全级是单一因素认证，向移动 基础结构或运营商断言拥有SIM设备的证据。通常，在将网络安全令牌发给客户 机或主计算设备前，移动基础结构将经认证服务器和通过询问应答型机制发出网络 安全令牌。因此，该网络安全级令牌能用在后续认证阶段并提供传输层安全，以加 密和/或签名客户机与认证服务器和/或移动基础结构之间的进一步交互。
图7A示出配置成发出网络级安全令牌的独立网络700，用于在客户机与认证 服务器之间建立传输层安全通信。通常，客户机或主计算设备710(可以是个人计 算机、移动电话或其他便携式或非移动计算设备)通过经由认证/信任服务器715 将网络安全令牌请求725发送到移动基础结构720，来启动认证请求(然而，注意， 该请求也可以由另一设备，诸如SIM705本身启动)。通常，当由认证服务器715 接收时将不签名该请求725，然后，在发送到用于确认该请求来自认证服务器715 的移动基础结构720之前签名和/或加密该请求。然后，受信任服务器715能向移 动基础结构720或移动运营商查询询问730，然后将该询问730发送到移动模块 705。移动模块705使用在它与移动基础结构720之间共享的秘密740，用于生成 询问应答735，然后将询问应答735转发到客户机710-注意通常该秘密将是SIM 705专用的并由移动运营商720设置。
客户机710将使用询问应答735来生成请求安全令牌响应，它也可以包括SIM 身份和询问730，用于认证目的。通常，客户机将请求移动模块705用设备705的 共享秘密740或诸如SIM设备令牌的其他密钥来签名和/或加密-尽管这可以是或 可以不是必要的。能使用例如共享秘密740确认其中的请求安全令牌响应和询问应 答735。注意，如前所示，可以或可以不通过用来生成询问应答735的同一密钥签 名和/或加密请求安全令牌响应。在任一情况下，如果移动基础结构720确认询问 应答735(即询问应答有效并且移动模块具有有效的记帐帐户)，移动基础结构720 和/或认证服务器715能通过生成包含具有使用共享秘密740签名和/或加密的加密 会话密钥的网络安全令牌745的消息应答。该消息能使用认证服务器715’自己的 安全令牌(例如X.509证书、Kerberos证书等等)或使用移动基础结构720’的安 全令牌进一步签名。因此，客户机710能认证该签名消息并将加密网络会话密钥传 送到SIM705，用于解密。使用共享秘密740，则移动模块705能将未加密的会话 密钥750返回给客户机710。
注意，在上述发出网络安全令牌745之时，移动模块705通常需要在移动基 础结构720上声誉良好的有效记帐帐户。因此，在验证询问应答735和该有效记帐 帐户信息后，可在SIM 705与产生虚拟安全信道的移动基础结构720之间建立信任。 然后，将会话密钥750从移动模块705委托或传递到主计算设备710的软件平台或 堆栈，以及从移动运营商720到认证服务器715(如果需要的话)。注意移动模块 705与主计算设备710的物理邻近程度(可以经由USB端口、蓝牙或其他无线或 有线连接与其连接)以及移动基础结构720与认证服务器715之间的信任关系。然 后，由客户机710和信任服务器715使用这些会话密钥，用于建立安全通信755。
注意，可以存在用于认证移动模块705的第二操作模式，它可以由移动基础 结构720使用。在这种情况下，客户主机710可以请求SIM 705生成和签名它自己 的询问(通常以Nonce形式)。然后，当从受信任服务器715或移动基础结构720 请求网络安全令牌725时，客户机710可附加作为设备令牌的一部分的信息。如果 移动运营商720能验证设备令牌包含有效询问应答735，则可将网络令牌745直接 发回到客户机710，用于解密上述的会话密钥。
如在下文更详细地描述地，通常需要该网络级安全令牌745来允许对能用来 从第三方服务请求服务和/或商品的经认证服务令牌的客户机访问。还注意，为了 获得网络令牌，上文假定了客户机或主机计算设备710已经成功地确定了用于认证 服务器715和/或移动基础结构720的网络端点。另外，假定客户机710和用户(未 示出)已经向SIM设备705进行了认证。如上所述，网络安全级令牌745被用于 后续认证阶段中，并且提供传输层安全性来加密和签名客户机710与受信任服务器 715之间的进一步交互。由认证服务器715或移动运营商720控制网络令牌745(和 其他令牌)的使用期。因为网络令牌745用作SIM设备705与移动基础结构720 之间的会话环境，所以可将使用期限定到几小时或几天、传递的字节数，和/或仅 当移动模块705适当地连接到客户机710时有效。
如前所述，用户安全级表示用户已经通常通过提供在SIM705或主机计算设备 710外存储的信息，向网络(受信任服务器715、移动基础结构720或其他服务) 认证。因此，结合网络安全级的用户安全级基于拥有SIM 705的证明和一些外部知 识(例如用户名/口令)，建立多因素认证。通常，受信任服务器715或移动基础结 构720仅是签发用户级安全的组件，然而，在一些实例中第三方服务也可以签发这 种用户令牌。因此，移动基础结构720(或视具体情况而定的其他服务)在将用户 安全级令牌发送回客户机710前，将通过询问应答机制验证用户。注意，由客户机 使用用户安全令牌来签名和/或加密对服务令牌的请求，如下所述。除受信任服务 器外，不推荐客户机将用户安全令牌发送到任何服务(因为通常无其他服务将能验 证/使用它)。与上述网络令牌745一样，用户令牌可以具有受移动运营商720控制 的有限使用期，并可受持续时间、传递的字节数和/或移动模块705和客户机710 之间的连接存在的限制。
图7B示出配置成发出用于在客户机710和认证服务器715间建立多级安全通 信的用户级安全令牌的独立网络700。用户网络认证阶段允许移动运营商720(或 其他服务器)验证已知的人是否拥有已知设备705。有效地，用户网络阶段是一两 因素认证阶段，并且使网络免受分布式拒绝服务攻击。另外，通过防止不适当地使 用被偷SIM设备705来保护用户。
主机计算设备710可以发出用户令牌765的请求，该请求经由受信任服务器 715发送到移动基础结构720。通常，当由认证/受信任服务器715接收时将不签名 请求765，然后在发送到移动基础结构720前认证/受信任服务器715可签名和/或 加密该请求，用于确认该请求来自认证服务器715。然后，受信任服务器715可向 移动基础结构720或移动运营商查询询问770，然后将该查询770发送到移动模块 705。注意，可以使用不同于用于向网络认证设备705的询问730的算法来生成询 问770。客户机710将从令牌消息提取询问770并将其传递到移动模块705，表示 这是用户认证。因此，SIM 705将从客户机710请求用户凭证775。然后，主机计 算机710向用户760查询用户输入780，并将其返回移动模块705。SIM 705或客 户机710可以可任选地判定用户输入780或凭证应当用先前获得的网络安全密钥 (即会话密钥)750加密。
使用用户输入780，移动模块705将生成询问应答785并将其返回给客户机 710，客户机710将生成和发送请求安全令牌应答，包括例如SIM标识符、询问770 和询问应答785。通常，客户机710将请求移动模块705用网络安全令牌745、共 享密钥740或SIM 705专用密钥来签名和/或加密请求安全令牌响应。与上文类似 地，使用例如共享秘密740，或其他移动模块705专用密钥，能确认其中的请求安 全令牌应答和询问应答785。注意，如上所述，可以或可以不通过用来生成询问应 答785的同一密钥来签名和/或加密请求安全令牌应答。在任一情况下，如果移动 基础结构720确认询问应答785(即所提供的用户凭证是正确的)，则移动基础结 构720和/或认证服务器715能通过生成包含具有使用共享秘密740或其他设备705 专用密钥签名和/或加密的加密用户密钥的用户安全令牌795的消息来应答。该消 息能使用认证服务器715’自己的安全令牌(例如X.509证书、Kerberos证书等等) 或使用移动基础结构720的安全令牌来进一步签名。然后，客户机710能验证签名 消息并将加密用户密钥传递到SIM 705，用于解密。使用共享秘密740(或视具体 情况而定，其他密钥)，移动模块705然后可将未加密的用户密钥790返回给客户 机710，从而向网络795认证用户。
用户服务认证阶段向移动网络运营商720提供代表第三方服务的认证。与用 户网络安全级类似，用户服务阶段是多因素认证阶段，并在认证的至少一个阶段期 间，防止在用户760不存在的情况下网络发出服务令牌。与如何发出服务令牌有关， 通常存在认证服务器715的两种操作模式。首先，如果用户760先前已经获得用户 令牌，则受信任服务器715可以将用户760视为认证过，并自动发出服务令牌(假 定使用用户令牌790、795适当地签名对服务令牌的请求)。另一方面，如果移动基 础结构720尚未发出用户令牌790、795，则将要求用户760以与上文概述相同的 方式认证，用于请求用户令牌790、795。
图7C示出当在客户机710与第三方服务器728之间建立安全通信时，不同网 络实体如何在独立网络700上通信。如上所示，移动设备705和用户760能向移动 运营商系统720认证，如前所述。因此，在适当确认移动设备705的记帐帐号以及 认证用户760拥有它之后，在认证服务器715与客户机710之间存在安全通信。然 后，当例如客户机710希望从第三方服务728购买服务和/或商品时，受信任服务 器715(或移动基础结构720，视具体情况而定)能发出用于不同服务的服务令牌 724。因此，客户机710能将服务令牌726发送到第三方服务器，然后通过认证服 务器715确认该令牌722。注意，第三方服务器728可以或可以不要求另外的认证， 并可使用如前所述的、用于执行这种确认的各种机制。还注意，使用服务令牌726 不仅在客户机710与第三方服务器728之间建立了安全通信，而且还可以以与前述 类似的方式，表示用户760’支付一个或多个服务和/或商品的能力。
注意，通常直到将服务令牌发送到客户机710为止，所发出的安全令牌对除 认证服务器715外的任何其他服务是无价值的。原因在于安全分层结构能防止任何 外部用户准确地解码设备令牌、网络令牌或甚至用户令牌，因为它们均由仅为SIM 设备705和移动基础结构720所了解的根或共享密钥740导出。这通常在认证服务 器715发出任意第三方728网络服务能利用安全令牌724的服务令牌724之后。还 注意到，上述安全令牌和消息(例如询问、询问应答等等)可以采用各种格式和方 案。例如，令牌和/或消息可以是XML、二进制或其他类似的编码格式，能由可能 或可能不希望将网络SIM通信的某些要素展现给中间方的移动运营商720发出。
上述将便携式硬件设备705用于认证、识别和/或支付确认能用于购买在线或 本地零售服务和/或商品(例如在线报纸、音乐、软件应用程序或其他商品和服务)， 或用于允许访问在本地PC或客户机710上运行的应用程序(例如Word、Abode Photoshop、Print程序、到期即付软件等等)。因此，上述实施例对自由解锁多个主 机设备710上的分布式保护软件或内容(例如音乐、视频、游戏等等)特别有利。 换句话说，许可现在变为依赖于便携式移动设备705，它能被如上所述认证，从而 允许便携式数字识别不与有限计算设备集相牵连。同样地，用户706进入朋友的房 间且不必携带所有他/她的节目或其他保护内容，而可经由便携式设备705存取和 认证。
如应当从上文意识到地，本文中所述的本发明存在多个方面，能彼此无关地 使用，包括涉及身份令牌、支付令牌，选择多个身份提供者中的一个、选择多个支 付提供者中的一个，以及商业交易软件在终端用户系统上的存在、服务提供者系统、 身份提供者系统、以及支付提供者系统的各个方面。还应当意识到：在一些实施例 中，能一起使用所有上述功能部件，或在特定实现中能一起采用上述功能部件的任 意组合或子集，因为本发明的各方面不限于这一方面。
本发明的上述实施例能够以多种方法的任一个实现。例如，可以使用硬件、 软件或其组合实现这些实施例。当用软件实现时，软件代码能在任何适当的处理器 或处理器集上执行，不管在单一计算机还是分布在多个计算机中提供。应意识到， 执行上述功能的任何组件或组件集通常能视为控制上述功能的一个或多个控制器。 能以各种方式实现一个或多个控制器，诸如通过专用硬件，或通过使用微代码或软 件编程来执行上述功能的通用硬件(例如一个或多个处理器)。
应意识到，在此概述的方法可以编码为可在采用多种操作系统或平台的任一 个的一个或多个处理器上执行的软件。另外，该软件可使用多种适当的编程语言和 /或传统的编程或脚本工具编写，也可以编译为可执行机器代码。在这一方面，应 当意识到，本发明的一个实施例针对计算机可读介质或多个计算机可读介质(例如 计算机存储器、一个或多个软盘、压缩盘、光盘、磁带等等)，其上编码一个或多 个程序，当在一个或多个计算机或其他处理器上执行这些程序时执行实现上述本发 明的各个实施例的方法。计算机可读介质或媒介是可运送的，以使得在其上存储的 程序或多个程序能加载到一个或多个不同的计算机或其他处理器上，以实现如上所 述的本发明的各个方面。
应理解：在一般意义上使用术语“程序”来表示能用来编程计算机或其他处 理器实现如上所述的本发明的各个方面的任何类型的计算机代码或指令集。另外， 应意识到：根据本发明的一个方面，在被执行时，执行本发明的方法的一个或多个 计算机程序不需要驻留在单一计算机或处理器上，而是可以以模块方式分布在多个 不同计算机或处理器中，以便实现本发明的各个方面。
可以单独、结合或以在上文实施例中未具体论述的各种配置来使用本发明的 各个方面，以及在此所述的本发明的方面在其应用方面不限于上文中阐述或在图中 示出的组件的细节和配置。本发明的各方面能是其他实施例，并且能以各种方法实 施或执行。本发明的各个方面能结合任何类型的网络、群集或结构实现。对网络实 现无限制。因此，上述描述和附图仅作为示例。
在权利要求书中使用序数术语，诸如“第一”、“第二”、“第三”等等修改权 利要求要素本身不暗示任何优先级、先后次序或一个权利要求要素在另一个上，或 执行方法动作的时间顺序，而仅用作将具有某一名称的一个权利要求要素与具有相 同名称(若非使用序数术语)的另一要素区分开来以便区分权利要求要素的标记。
同时，本文中使用的措辞和术语用于描述目的，并且不应当视为限制。使用 “包括”、“由…组成”或“具有”、“包含”、“涉及”和本文中的变体旨在包含此后 列出的项及其等效项，以及另外的项。