CN101185282A

CN101185282A - 无线用户记帐和分发

Info

Publication number: CN101185282A
Application number: CNA2006800191093A
Authority: CN
Inventors: J·余; M·B·奥利弗; G·C·霍尔; P·T·恩古耶; S·L·普拉斯特; J·帕瓦里
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2005-05-31
Filing date: 2006-05-31
Publication date: 2008-05-21
Anticipated expiration: 2026-05-31
Also published as: TW200719619A; JP5680596B2; KR20080017418A; CN101620720B; EP1886440B1; WO2006130539B1; EP1886440A2; EP2288075A1; US20060270386A1; JP2013012213A; EP2288075B1; CN101185282B; EP2367318A1; JP5579383B2; EP2367318B1; BRPI0611321A2; WO2006130539A3; CN101620720A; TWI324866B; JP2008546096A

Abstract

公开了用于在无线用户记帐系统内生成和响应记帐请求的系统和方法。可以在可信服务处生成记帐请求。包括记帐信息的该记帐请求被传送给无线用户记帐系统。在无线用户记帐系统中生成对该记帐请求的确认响应，并且该确认响应被传送给可信服务。

Description

无线用户记帐和分发

发明背景

1.领域

本发明一般地涉及远程计算设备与服务器之间的通信。更具体地，本发明涉及在服务器与远程客户机设备之间记帐事件的创建和发送。

2.背景

技术进步已使得个人计算设备体积更小、更强大。例如，当前存在多种便携式个人计算设备，包括无线计算设备，例如便携式无线电话机、个人数字助理(PDA)和寻呼设备，它们都很小、轻便，并可以方便地由用户随身携带。

更具体地，便携式无线电话机例如还包括在无线网络上传送语音和数据分组的蜂窝电话机。此外，正在制造在计算能力上有相对较大提高、由此变得越来越等同于小型个人计算机和手持式PDA的许多此类蜂窝电话机。然而，这些更小且更强大的个人计算设备通常受到资源的严格限制。例如，屏幕尺寸、可用存储器和文件系统空间总量、输入和输出能力和处理能力总量可能分别受到设备的小尺寸，具体而言，诸如键盘等用户输入单元的小尺寸的限制。因为这种严格的资源限制，往往通常希望例如维持有限大小和数量的驻留在此类远程个人计算设备(客户机设备)上的软件应用和其它信息。

一些个人计算设备使用有时称作运行时环境和软件平台的应用编程接口(API)，它们被安装在其本地计算机平台上，并且例如被用于比如通过为设备专用资源提供统一调用等来简化此类设备的操作。此外，此类API中有的还可使软件开发者能够创建在此类设备上完全可执行的软件应用。此外，此类API中有一部分操作性地介于计算设备系统软件与软件应用之间，从而使该计算设备计算功能集可供软件应用使用，而不需要软件开发者拥有专用计算设备系统源代码。此外，有一些API还提供用于在使用安全密码信息的此类个人设备(即客户机)与远程设备(即服务器)之间安全通信的机制。

此类API的例子包括由加利福尼亚州圣地亚哥市高通(QUALCOMM)公司开发的无线软件版本的二进制运行时环境(BREW

)，部分例子在下文中将进行更详细地讨论。BREW

可以与计算设备(例如无线蜂窝电话机)操作系统协作，除了其它特征之外，还可以提供至个人计算设备上特有的硬件特征的接口。BREW

还能以相对于设备资源要求以及相对于消费者为包含BREW的设备支付的价格而言相对较低的成本在此类个人计算设备上提供这些接口。BREW

的其它特征包括其端对端软件分发平台，该平台为无线服务运营商、软件开放者和计算设备消费者提供多种益处。至少一个此类当前可用的端对端软件分发平台包括分布在服务器-客户机架构上的逻辑，其中服务器执行诸如记帐、安全和应用分发功能，而客户机执行诸如应用执行、安全和用户接口功能集。

上述相关技术的描述仅仅将提供API的一些公知用途的概况，并作为对可在本发明的实施例中使用的BREW

平台的介绍。然而，本发明不应解释为局限于某个具体实现、操作平台或环境。

示例性实施例的概要

本发明的示例性实施例针对一种用于在无线网络中生成和处理记帐请求的系统和方法。

因此，本发明的一个实施例可以包括一种方法，其包括：在可信服务处生成记帐请求；将包括记帐信息的该记帐请求传送给无线用户记帐系统；在该无线用户记帐系统中生成对该记帐请求的确认响应；以及将该确认响应传送给该可信服务。

本发明的另一个实施例可以包括一种设备，其包括：在无线用户记帐系统中的服务价值记帐(SVB)模块，其配置成接收来自可信服务的记帐请求并认证该可信服务；以及确认逻辑，其配置成响应于该记帐请求生成确认响应。

本发明的另一个实施例可以包括一种系统，其包括：用于在无线用户记帐系统处接收来自可信服务的包括记帐信息的记帐请求的装置；用于在无线用户记帐系统中生成对该记帐请求的确认响应的装置；以及用于将该确认响应传送给该可信服务的装置。

本发明的另一个实施例可包括一种计算机可读介质，其上存储有用于在无线用户记帐系统中处理记帐请求的计算机程序，该计算机程序包括一旦被执行就使计算设备执行下述过程的指令：接收来自可信服务的记帐请求，其中该记帐请求向该无线用户记帐系统记帐信息；在无线用户记帐系统内生成对该记帐请求的确认响应；以及将该确认响应传送给该可信服务。

本发明的另一个实施例可以包括一种在无线用户记帐系统中处理多方记帐事件的方法，该方法包括：生成包括供应商费用和收款人、及与交易相关联的至少一个源费用和收款人的记帐事件；以及处理该交易以将支付分发给供应商收款人和该至少一个源收款人。

附图简要说明

当结合附图考虑时，通过参考下述详细描述，将能更好地理解本发明的实施例及其诸多附带优点，从而就将更完整地认识这些实施例和优点，附图仅用于说明而不是限制本发明，在附图中：

图1是支持根据本发明至少一个实施例的客户机设备和服务器的无线网络架构的图；

图2是支持根据本发明至少一个实施例的客户机设备和服务器的无线网络架构的更详细的图；

图3是根据本发明至少一个实施例的应用价值记帐系统的系统级图解；

图4是根据本发明至少一个实施例的服务价值记帐系统的系统级图解；

图5是根据本发明至少一个实施例的群组分发系统的系统级图解；

图6是一种包括根据本发明至少一个实施例的系统要素的代理购买过程的系统级图解；

图7是根据本发明至少一个实施例的多方结算和CRM系统的系统级图解；以及

图8-11是图示根据本发明各实施例的方法的流程图。

优选实施例的具体说明

在涉及本发明具体实施例的以下描述和相关附图中公开了本发明的各个方面。可以设计出替换实施例而不会脱离本发明的范围。此外，将不详细描述本发明的公知要素，或者将予以省略，以免与本发明的相关细节混淆。

在此使用的措词“示例性的”是指“用作例子、实例或例证”。不必将在此描述为“示例性的”任何实施例解释为优于或胜过其它实施例。类似地，术语“本发明的实施例”并不要求本发明的全部实施例都包括所讨论的特征、优点或操作模式。

此外，以将由诸如计算设备的元件执行的动作序列的形式描述多个实施例。将认识到，在此描述的各个动作可以由具体电路(例如专用集成电路(ASIC))，通过由一个或多个处理器执行的程序指令，或者通过两者的组合来执行。此外，可以将在此描述的这些动作的序列视为完全包含在任意形式的计算机可读存储介质中，在这种介质中存储着相应的计算机指令集，一旦执行这些指令就将使相关联的处理器执行在此所描述的功能集。因而，可以以多种不同形式实施本发明的各个方面，各种形式将视为在所要求保护主题的范围内。此外，对于在此描述的每个实施例，可以将任何此类实施例的相应形式在此描述为诸如“配置成执行所述动作的逻辑”。

可以结合在计算设备上执行的运行时环境(例如API)使用本发明的一个或多个实施例。一种此类的运行时环境是先前讨论的无线软件用二进制运行时环境(BREW

)。然而，也可以结合在例如操作以控制应用在无线客户计算设备上的执行的其它类型的运行时环境或平台使用本发明的一个或多个实施例。

此外，本领域的技术人员将认识到，为了简化描述，在此描述的是被分发和执行的应用文件类型。然而，“应用”还可以包括具有可执行内容的文件，例如：目标代码、脚本、Java文件、书签文件(或PQA文件)、WML脚本、字节代码和Perl脚本。此外，在此所述的“应用”还可以包括本质上不可执行的文件，例如可能需要打开的文件或者需要被访问的其它数据文件。

图1图示根据本发明至少一个实施例的无线系统100的一种示例实施例的方框图。系统100可以包含诸如蜂窝电话机102的客户机设备，它通过无线网络104与至少一个应用下载服务器106通信，该服务器可以选择性地将软件应用和组件经无线通信门户或去往无线网络104的其它数据门路发送给无线设备。如图所示，无线(客户机)设备可以是蜂窝电话机102、个人数字助理108、图中示为双向文本寻呼机的寻呼机110-、或者甚至是一个具有无线通信门户的单独的计算机平台112。因而，可以在包括无线通信门户或者具有无线通信能力的任意形式的客户机设备上实现本发明的实施例，所述客户机设备包括但不限于无线调制解调器、PCMCIA卡、个人计算机、接入终端、电话机、或者它们的任意组合或再组合。

在图中，应用下载服务器(ADS)106被示为位于与无线网络104通信的具有其它计算机元件的网络116上。可以存在独立服务器122，并且每个服务器可以经无线网络104向客户机设备102、108、110和112提供单独的服务和进程。最好还存在至少一个应用存储数据库118，其保存可由无线设备102、108、110和112下载的软件应用和内容。然而，本领域的技术人员将理解，图1所示的配置仅仅是示例性的。因此，本发明的实施例可以包括一个或多个服务器，所述服务器可以各自执行全部所述功能并包含全部必需硬件和软件，或者可以仅包含选定的功能集。

图2的方框图更完整地图示系统100，包括无线网络104的组件和本发明示例性的实施例的要素的相互关系。系统100仅仅是示例性的，并且可以包括允许例如无线客户计算设备102、108、110和112的远程客户机设备以无线方式在相互之间和/或在通过包括但不限于无线网络承载商和/或服务器的无线网络104连接的组件之间通信的任意系统。应用下载服务器106和应用存储数据库118以及用于提供蜂窝电信业务的诸如记帐服务器130等任何其它服务器通过诸如互联网、安全LAN或WAN或者其它网络等数据链路与承载商网络200通信。在所图示的实施例中，服务器120可以包括应用下载服务器106、记帐服务器130和应用存储数据库118。然而，这些服务器也可以是独立设备。

承载商网络200控制发送给消息收发服务控制器(“MSC”)202的消息(通常作为数据分组发送)。承载商网络200通过网络、因特网和/或公共交换电话网(PSTN)与MSC 202通信。典型地，在承载商网络200和MSC 202之间的网络或因特网连接传输数据，而PSTN传输语音信息。MSC 202可以连接到多个基站(“BTS”)204。以类似于承载商网络的方式，MSC 202通常通过用于数据传输和/或语音信息的网络、因特网和/或PSTN连接到BTS 204。BTS 204可以通过短消息收发服务(“SMS”)或者其它现有技术中公知的空中(OTA)方法将数据消息无线地广播给客户机设备，例如蜂窝电话机102。

客户机设备，在此为无线客户机计算设备，例如蜂窝电话机102，具有可接收和执行发送自应用下载服务器106、记帐服务器130和/或服务器120的软件应用或内容和/或命令的计算机平台206。计算机平台206可以包括专用集成电路(“ASIC”208)、或其它处理器、微处理器、逻辑电路或其它数据处理设备。ASIC 208或其它处理器执行与无线设备的存储器212中的任意驻留程序接口的应用编程接口(“API”)210层。存储器212可以包括只读或随机存取存储器(RAM和ROM)、EEPROM、闪存卡或者各计算机平台常用的任意存储器。API 210还包括基于应用的价值记帐扩展(AVB)310，其包含配置成处理从客户机设备到承载商网络200的特殊记帐请求的逻辑。计算机平台206还包括可保存当前没有在存储器212内使用的应用的本地数据库214。本地数据库214通常是闪存单元，但是也可以是现有技术中公知的任意次级存储设备，例如磁介质、EEPROM、光介质、磁带、软盘或硬盘、等等。

诸如蜂窝电话机102之类的无线客户机计算设备在其上安装有或者下载一个或多个软件应用，例如游戏、新闻、股票监视器、等等。例如，蜂窝电话机102可以接收从下载服务器106下载的一个或多个软件应用和内容。当不处于使用状态时，可以将该软件应用和内容存储在本地数据库214上。蜂窝电话机102或者其它无线计算设备可以将存储在本地数据库214上的驻留应用上载到存储器212以便在用户希望执行或者由另一个API调用时在API 210上执行。

在本申请中，“客户机设备”、“无线设备”或者“客户机计算设备”包括例如执行驻留配置逻辑的一个或多个处理电路，其中此类计算设备包括例如微处理器、数字信号处理器(DSP)、微控制器、便携式无线电话机、个人数字助理(PDA)和寻呼设备，或者包含配置成至少执行在此所述的涉及在客户机设备与服务器之间传送的记帐信息的操作的处理器和逻辑的硬件、软件和/或固件的任意适当组合。可以由至少一个远程服务器为客户机计算设备提供关于处理在客户机设备处生成的记帐请求的服务。根据本发明实施例可以使用的客户机设备的一些例子包括蜂窝电话机或其它无线通信单元、PDA、寻呼设备、手持式导航设备、手持式游戏设备、音乐或视频内容下载单元、和其它类似无线通信设备。

客户机设备102与BTS 204之间的无线通信可以基于不同的技术，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、全球移动通信系统(GSM)或者可以在无线通信网络或数据通信网络内使用的其它协议。数据通信通常是在客户机设备102、BTS 204和MSC 202之间。MSC 202可以连接到多个数据网络，比如承载商网络200、PSTN、因特网、虚拟专用网、等等，从而使客户机设备可访问更广阔的通信网络。如先前讨论的，除了语音传输之外，还可以通过SMS或现有技术中公知的其它OTA方法将数据传送给客户机设备。

参见图3，图示客户机设备300包括包含AVB扩展310(例如在应用内支持记帐请求和处理的API)的应用320(例如BREW

应用)。记帐请求在应用内生成。这样就可以允许将购物体验控制在应用层上，并且可以在应用的分发和定价以及在应用和/或内容的特征方面有更大的灵活性。例如，开发者可能希望提供具有各有不同价格等级的各种特征的街机类型的应用。这些特征可以包含在原始应用内(例如不同的难度等级)或者可以从远程服务器下载(例如增强背景音乐)。可以向用户显示购买每一特征的选项，用户可以使用AVB扩展310在应用层上确定是否购买附加特征。因此，一个应用320可以为开发者和承载商生成针对区别定价的递增记帐，而不需要多个应用和不同应用的多个下载。同样，因为通过应用支持附加服务，所以基于网络的应用可以动态地配置递增收费后就可获得的最新的一组服务，而不需要重新部署新的应用。这样一个例子是铃声购买应用。可以将铃声存储在服务器上，并且可以在内容服务器确定适当时进行更新。AVB应用可以访问铃声和定价的远程目录以实时地向消费者显示。这样，AVB API向开发者和运营商在数据服务提供和定价灵活性方面提供更大的灵活性。

相反，为了使用常规系统实现类似的功能，应用开发者将必需针对每个特征和/或定价等级生成不同的应用并使它们可供下载。常规系统将每个下载视为一次性购买，记录记帐信息并处理每个所下载应用的结算。该过程由承载商控制，为了购买每个应用，客户机设备将必须连接到承载商网络以浏览应用目录并购买具有期望特征的期望应用。

在本发明的实施例中，如上所述，购物体验在客户机设备300处进行。因此，当在客户机设备300处购买选项被显示并被接受之后，在客户机设备300内生成记帐请求。可以将该记帐请求和用于处理该记帐交易的其它信息(例如用户标识信息(SID)、(一个或多个)内容供应商、零售价格、等等)传送给远程记帐系统301。在远程记帐系统301处接收到该记帐请求并予以处理。响应于记帐请求，在远程记帐系统301处生成确认响应。将该确认响应传送给客户机设备300。

确认响应可以是对记帐请求的准许或者对记帐请求的拒绝。一旦客户机设备接收到该响应，它就可以相应地处理该确认。例如，如果确认响应为肯定性的，则可以启动链接到该记帐请求的特征(例如，街机游戏中的附加等级)。类似地，如果该记帐请求被拒绝，则可以在客户机设备上显示记帐请求的拒绝指示。可任择地，在拒绝内可以包括附加信息，例如拒绝该请求的原因(例如资金不足)。

在至少一个实施例中，该记帐系统可以利用现有的记帐组件以便于该系统的实现。例如，在图3中，应用分发系统(ADS)106可以接收到来自客户机设备300的记帐请求。ADS 106随后可以访问可以由记帐实体(例如承载商)确定的确认逻辑330。确认逻辑可以根据需要详尽或者有限。例如，承载商可以允许全部的记帐事件被处理，只要SID和所请求的记帐额度是有效的，并且提供的信息足以生成记帐事件(例如项目ID、供应商ID、供应商定价(例如支付供应商的价格)、等等)。此信息可以直接包括在记帐请求内或者可以与在记帐系统内的服务器内存储的信息组合来生成。例如，可以将项目ID链接到一个或多个供应商ID和相关供应商定价、该项目的描述、消费者价目表价格(CLP)、等等。然而，通常从AVB 310发送定价信息，因为在生成记帐请求的基于客户机的交易过程中显示给用户的价格应当是用于用户记帐的价格。

ADS 106可以根据项目ID生成附加记帐信息。此外，一旦确认逻辑330准许该记帐请求，ADS 106就可以执行附加检查。例如，如果客户机定价计划是预付费计划，则可以检查预付费余额以查看是否有充足资金来购买该项目。如果有充足资金，则将准许发送给客户机设备。然而，如果没有充足资金，则拒绝该记帐请求，即使该记帐请求是有效的。一旦该记帐请求最终被记帐系统301准许，就将该准许发送给客户机设备300以由AVB 310和生成该记帐请求的应用320予以处理。

除了发送准许之外，ADS 106还将交易数据传送给交易管理器(TXN)340。该TXN 340被配制成从ADS 106接收交易数据。TXN 340可将任何未包括的其它记帐信息与交易数据相关联。例如，交易数据可以包含SID、项目ID和价格ID。TXN 340可以关联附加数据以使记帐过程完整(例如供应商ID和相关供应商定价、项目描述、全定价计划、等等)。随后，TXN 340可以将此信息作为记帐事件传送给客户机记帐模块350和结算模块360。客户机记帐模块350被配制成接收来自TXN 340的记帐事件并向与客户机设备300相关联的用户生成帐单。结算模块360还被配置成接收来自TXN 340的记帐事件，给记帐实体(例如承载商/运营商)开发票，和支付供应商(例如开发者、出版者、等等)。

典型地，在生成交易数据之后，以常规方式创建和处理记帐事件。例如，可以将与项目相关的元数据存储在TXN 340和/或相关数据库内。当客户机设备300接收到针对记帐请求的准许时，可以将交易数据发往并存储在数据库内。还可以存储交易类型，以便向承载商和/或开发者生成的报告可以将该交易标识为AVB生成的记帐事件。交易数据还可以包括元数据和由其它设备和/或系统包括的附加信息的子集。通过将元数据与原始交易数据相关，在TXN 340内创建记帐事件。在题为“Transaction Processing(交易处理)”、序列号为10/222,706的本申请人拥有的美国专利申请中对该过程进行了更详细的描述，其全文通过引用结合于此。

客户机设备购买和获取应用的常规过程包括：客户机设备访问可用应用目录，选择期望应用和将该应用下载到客户机设备。该过程生成与应用下载相关的记帐事件，该事件最终导致对用户的记帐和对应用开发者的支付，如在背景技术中讨论的。然而，应用的销售和购买以及无线用户记帐系统的使用被局限在了该客户机-服务器连接上。

图4图示根据本发明至少一个实施例的允许附加服务价值记帐的系统。服务价值记帐(SVB)模块410可以包括在无线用户记帐系统400内。SVB 410提供为并非承载商网络的一部分的可信服务490(例如第三方销售商、出版者、等等)提供记帐门户。SVB 410允许可信服务490生成记帐请求，这些基站请求随后将通过记帐系统400处理。与对直接从客户机设备选择和向其下载的应用进行分发和记帐的常规系统不同，SVB允许通过已建立的无线用户记帐系统400处理非应用相关交易。

验证特征可以包含在SVB模块410内，其可以验证访问SVB模块410的可信服务490的身份。例如，可以将数字证书颁发给可信服务。该证书将与承载商/运营商和可信服务(例如内容收款人)相关联以供确认。可信服务490可以使用所颁发的证书数字向SVB模块410签署每个交易。可以将数字签名和数字证书包含在每个请求内。随后，SVB模块验证在每个记帐请求上的签名。SVB 410可以是基于环球网(web)的接口，并且到SVB 410的连接可以经因特网在可信服务490认证中使用HTTPS协议来进行。然而，本领域的技术人员将认识到本发明并不局限于因特网连接和HTTPS协议，而是可以使用有线和/或无线连接和适当的安全/认证系统的任意组合传送来自可信服务的记帐请求。

因此，无线用户记帐系统400可以接收来自记帐系统400外部的可信服务的记帐请求。记帐请求可以包括传送给记帐系统400和用于在记帐系统400处验证该请求的记帐信息。此外，记帐系统400可以生成对记帐请求的确认响应并将该确认响应传送给可信服务490。记帐信息可以包括用于确认记帐请求的信息，包括用户ID、供应商/内容收款人、内容(项目)ID、价目表价格、记帐描述等。然而，本领域的技术人员将认识到，在记帐请求内可以包括其它数据。

例如，在图4所示的配置内，可有可信服务490生成记帐请求。SVB 410可以接收来自可信服务490的记帐请求和可以认证可信服务490，如在此讨论的。确认逻辑430可以确认记帐请求。使用确认逻辑430，承载商可以执行记帐完整性检查以确定承载商是否希望接受该记帐请求以进一步处理或者拒绝该请求。因为承载商并未在控制定价和交易，但是将对该用户记帐，因而可以使用确认逻辑430作为介入点以允许承载商确定哪些记帐请求是可接受的。如果该记帐请求被确认，则SVB 410可以根据该记帐请求生成交易数据并将该交易数据传送给交易管理器440。交易管理器440可以自SVB 410接收交易数据并生成可传送给记帐模块450和结算模块460的记帐事件。记帐模块450可以接收来自交易管理器440的记帐事件，并生成给用户的帐单。结算模块460可以自交易管理器440接收该记帐事件，给承载商开发票，并支付内容供应商(例如为其记帐的应用/内容/服务的源)，如上文讨论的。因此，可以使用SVB 410来记帐和结算记帐系统400外部的交易，并且无线用户记帐系统400的使用并不限于对应用下载和/或承载商相关服务进行记帐和结算。

因为来自可信服务的基于SVB的记帐事件不是在承载商网络内或者从用户的客户机设备直接生成的，所以可以由SVB使用SID映射数据库420来唯一性地识别该用户。例如，用户可以在可信服务490处使用承载商已知的他们的移动目录(可拨号)编号(MDN)或分配的其它唯一性编号。可以将MDN(或其它唯一性编号)作为SID随记帐请求一起传送给SVB 410。随后，SVB410可以访问SID映射数据库420，并使用在记帐系统内使用的唯一性SID替代MDN或者将MDN与之相关联以处理记帐请求和交易。

此外，购买/记帐的项目可以不是通过ADS和/或承载商网络分发的应用或内容。因此，记帐请求可以包括与项目描述、零售价格和购买时间/日期等相关的附加信息。然而，还可以将该附加信息的至少一部分预加载到数据库内，并根据项目ID和/或供应商/收款人ID(例如可信源)进行访问。

包括在记帐请求内的信息可以包括用于记帐和跟踪交易的各种数据。例如，包括在记帐请求内的信息可以包括可以由可信服务规定代表用于在该可信服务处购买的项目(例如应用、内容、文章和/或服务)的唯一性标识符的项目ID。可以将其视为该项目的记帐方编号。然而，因为不保证该项目ID跨各可信服务都是唯一性的，因而可以结合供应商/收款人ID(可以是可信服务)来参考以维持唯一性。客户ID可以是运营商的用户ID(SID)或者可以与运营商/承载商的SID相关的其它唯一性ID。在记帐信息内可以包括客户ID类型(例如SID、MDN)。签名可以是由可信服务使用所颁发的数字证书的私钥数字签署的所有数据的级联串。可以将来自可信服务密钥对的数字证书用于SVB以认证该请求。收款人ID可以代表将要向其支付标准收入股份分割(例如在承载商、结算实体和内容供应商之间的收入分割)的内容部分的供应商/内容收款人，并可以等同于该项目的出版者/开发者/制造者。在许多情况下，收款人ID是可信服务。

可以包括购买的格林尼治标准时间(GMT)戳。可以包括GMT偏移量以代表计算本地时间的偏移量。客户机交易ID可以代表记帐/交易请求的唯一性标识符。可以使用其来检查是否已经接收到该交易(重复检查以防止双重记帐)。承载商ID代表系统内的次级运营商ID(例如它可以等同于BREW

承载商ID和主承载商)。预付费标记可以指示终端用户是否是该运营商的预付费客户。零售价格可以代表内容记帐事件的消费者收费。内容费用可以代表用于根据定价条款确定内容收款人支付的价值。在大部分情况下，它与零售价格相同。货币代码可以代表在交易内规定的价目表价格、内容费用和源费用金额的货币。记帐描述可以代表内容项目的简单描述，其可以被包括在发送给承载商的报告(例如记帐XML馈送)、以及对开发者可用的报告(例如开发者XML馈送)中，并出现在消费者记帐结单上。其等同于用于该项目的记帐方名称。长描述可以代表可用于进一步描述交易(例如用于客户服务)、但是通常并不包括在记帐提取XML或开发者提取XML(即向开发者的报告)中的价值帐单内容的更长名称。销售商数据可以代表随着记帐交易传递的将由可信服务使用的附加数据。在记帐和开发者报告内可以包括销售商数据。用于开始循环记帐接口的信息可以包括可指示触发订购记帐的日期(例如以月份/日期/年份的格式)的开始帐单日期。如果开始帐单日期是在未来，则直到开始帐单日期才建立触发记帐的第一价值记帐(IB)事件。结束帐单日期可以指示订购的结束日期(例如以月份/日期/年份的格式)。在结束帐单日期之后不窗建IB事件。

提供可包括在记帐请求内和/或可与记帐事件相关联的可选记帐信息的以上描述仅仅是为了说明。在没有上述全部信息的情况下也可以处理记帐请求，类似地，为了跟踪和报告记帐事件的目的，可以添加未列出的附加信息。因此，本领域的技术人员将理解，生成记帐事件的记帐请求和相关信息可以根据所购买项目的承载商和供应商的希望而改变。

使用SVB 410，记帐系统400本质上用作来自可信服务490(即用于记帐生成的授权源)的“通过”记帐服务。可信服务490可以负责服务价值记帐交易管理，其可以包括：创建交易(例如SOAP(简单目标访问协议)接口)、提供安全性、设置有效交易属性(例如上述记帐信息)、向记帐系统400提交该交易、处理来自记帐系统400的响应并根据需要重新提交该交易。可信服务490可以使用由运营商颁发的数字证书或者其它安全交易处理将每个交易的认证(例如数字签署每个交易)提供给SVB 410。随后，SVB 410可以认证来自可信服务490的请求，确认该请求，支持价值记帐运营商接口和将有效请求(例如交易数据)传送给TXN 440。SVB 410可以返回出错代码以标识无效请求。TXN 440可以支持重复事件检查、记帐交易的转换处理、循环内容价值记帐的映射和处理，并可以将价值记帐事件传送给记帐模块450和结算模块460。

SVB 410可以支持多个运营商接口。例如，可以使用用户授权接口来验证该SID是否被授权用于该SVB服务。可以将交易确认接口(例如确认逻辑430)用于运营商以实现记帐信息的附加验证(即内容费用不超过X、客户ID有效、等等)。可以使用预付费接口来为价值记帐服务发起预付费授权(例如检查预付费余额)和借记服务。这些接口可以被实现为分立模块，或者可以被全部包括在公共逻辑模块(例如确认逻辑430)内。

如上文讨论的，常规无线系统内的应用购买由承载商/运营商控制，并且通常基于客户机设备浏览应用(例如由ADS显示的)，从承载商网络选择和下载应用。如在背景和以上公开内讨论的，交易可以被记录、记帐和结算。

然而，在记帐系统内添加SVB服务允许有除了自承载商网络直接购买之外的代理购买(Alt Buy)源。参见图5，SID定向(或者客户机设备定向的)分发结构可以允许将项目(例如应用、内容、等等)定向传递给远程客户机设备。该SID定向结构允许自承载商购买的应用和/或内容脱机地与SID相关联，以便所购买的应用/内容可供从客户机设备下载，并且该下载事件将不会生成对用户的任何附加记帐，如同常规的下载处理一样。

例如，主目录510可以包含可供从承载商/运营商购买的多个项目(例如应用、内容、服务、等等)。可以形成仅包含一个SID的SID定向群组540(例如My Apps群组)以使其包含专门定向于该SID(客户机设备)的项目。因此，可以以常规方式(例如使用来自主目录510的文件夹/项目)根据基于平台ID、运行时API和语言从主目录510为客户机设备300生成购物目录550。然而，可以根据与客户机设备300相关联的SID用SID定向群组540和与购物目录550内的SID相关联的项目(例如My Apps)来扩充购物目录550。因此，可以为每个SID定制购物目录550，并且可以使用SID定向群组540发送经AltBuy购买的项目。

除了在不同群组内呈示项目之外，可以将区别定价用于同一项目。例如，可以为在主目录510内的项目5(例如一应用)提供全价10美元。然而，在SID定向群组540(例如My Apps)内可以包含可能免费提供的相同项目5。例如，可能是通过Alt Buy购买了项目5，或者项目5可能是来自另一个用户的礼物。因此，与常规的下载发起的记帐事件不同，购买/记帐/结算处理可以与所购买项目的传递分开。

无线用户记帐系统外部的记帐信道(例如SVB 410)允许经无线用户记帐系统处理外部购买交易。一些没有任何与客户机设备相关联的下载或增强的购买也可被处理，例如购买电影票。然而，也可以处理其它类型的外部交易，包括从定向到无线系统上的一客户机设备的承载商目录购买项目(例如下载或增强应用的特征、应用购买、铃声购买、等等)。在下文的描述中，通常将定向到一客户机设备但是不由该客户机设备在常规客户机设备内向承载商网络的服务器生成的交易的这种类型的交易称作“代理购买”或“Alt Buy”。

Alt Buy区域610可以包含各种渠道，例如零售渠道612(例如运营商/第三方零售卡、自助式服务终端)、基于PC/Web的渠道614(例如运营商/第三方网站或者直接来自PC应用内，例如其中可以为无线客户机300进行相关游戏的购买的游戏)、大众媒体616(例如广告链接等等)。Alt Buy可以利用SVB 410进行记帐，并利用基于SID的群组功能(例如My Apps 540)来向与SID相关联的客户机设备300投放内容/应用。

例如，零售卡可以是在运营商或第三方零售特卖点内销售的向用户提供一个或更多应用的卡。购买者可以自己使用此卡或者将此卡作为礼物送给另一个用户。在单个卡上购买多个应用可以包含这些应用购买价格上的打折。在购买或接收礼物之后，用户可以注册该卡，此时这些应用(例如BREW

应用)被加载到它们的SID定向群组(例如My Apps目录)中以供下载或自动安装。此外，对用户记帐(可任选，如果不是预付费的)并与所有的应用和服务供应商结算来完成交易处理。

可以呈示模仿目录出价并可能纳入针对多个应用的购买或者针对在有限时间出价期间某些出价的购买的某个折扣定价的运营商/第三方web出价。网站Alt Buy可以个体地提供应用和内容，或者提供产品和服务项目的捆绑。例如，用户(或者礼物赠送者)可以提供与目标用户设备相关的信息(例如MDN)，并且运营商/第三方(即可信服务)经SVB 410接口提供用于向用户记帐和向内容供应者支付的信息。

运营商或第三方自助式服务终端可以具有应用购买能力，其模仿主目录出价并可能纳入针对多个应用的购买或者针对在有限时间出价期间某些应用的购买的某种折扣定价。用户提供关于目标用户设备(例如客户机设备300)的信息，并且运营商或第三方将所购应用的分发(例如经My Apps)定向给该设备，并提供用于向用户记帐和向内容和服务供应者支付的信息。

广告链接可以将应用提供给运营商的用户。例如，这些可能是不可对用户记帐的。用户提供关于目标用户设备的信息，并且运营商或第三方将应用的分发定向给该设备(例如通过My Apps)以供用户下载。

如上文讨论的，Alt Buy提供各种不同的购买和将应用/内容投放给用户的渠道。在这些配置中的每个配置中，将记帐和投放信息传送给SVB 410和群组管理器515以允许正确的投放和记帐。相应地，记帐和投放元数据可以作为传送给SVB 410的记帐请求的一部分被传送。

例如，可以在承载商网络/记帐系统之外(例如在运营商自助式服务终端上用现金、信用卡)购买应用。记帐和分发请求被从可信服务(例如Alt Buy区域610)传送给SVB 410。可以随记帐请求包括特殊价格句柄，以指示该交易是代理购买并且具有特殊定价基础(例如CLP＝0，从而不向用户记帐)。使用SID以定向投放目标(例如My Apps)。通常，Alt Buy服务格式化并提交记帐和分发请求，处理返回事件信息，并处理出错实例。记帐/分发请求可以是SVB交易，并且分发请求可以是群组管理者定向(SID定向)的应用请求。随着请求包含的元数据(信息)包括例如对应于与该Alt Buy相关联的每个应用的分发SID、项目ID、价格句柄、价格方法、价格基础、价格值、销售商数据和源类型。

Alt Buy投放表620可以填充有从Alt Buy源传递的元数据中的数据(例如610)。例如，该表可以包括SID(例如分发SID)、项目ID、用法、价格处理器、CLP字段。在上述在Alt Buy区域610支付该应用且CLP＝0的情景中，此信息可以与SID和该项目ID相关联，并与SID定向群组540(例如My Apps)相关联。当与SID相关联的客户机设备300从由ADS 106生成的购物目录550访问SID定向的(“My Apps”)群组时，所呈示的项目之一(例如应用)可以是经Alt Buy购买的项目。

ADS 106可以访问Alt Buy表620以确定是否存在与SID和项目ID相关联的Alt Buy价格句柄。随后，ADS可以用来自Alt Buy表620的本地价格句柄替换所提供的与项目ID相关联的价格句柄。假设价格是零，则可以在客户机设备300上显示0美元或“免费”的呈示(或者其它语言专用指示)。如果存在本地价格句柄，则ADS 106可以将该交易识别为Alt Buy交易以确保运营商和开发者最低额不适用，并且不应用消费者记帐，不处理开发者/内容供应商结算或者在零值上处理。如上文讨论的，ADS 106可以处理下载请求并在零值上生成交易数据，将该交易数据传递给交易处理、记帐和结算模块。然而，由于是在Alt Buy区域上经SVB执行记帐和结算，因此记帐和结算两者都将是零(CLP＝0，DAP＝0，其中DAP是对开发者/内容供应商的支付)。然而，可以在该下载事件上维持与该交易相关的其它信息，以填充运营商和/或开发者报告。例如，该信息在跟踪所下载的实际应用、下载日期等时可能是有用的，并可以与SID和客户机设备相关联以便于进行市场销售和/或客户服务。

在另一个示例性实施例中，可以按特殊价格(例如低成本或零成本促销)从运营商自助式服务终端进行一次性或者有限次数下载的Alt Buy购买。如上文讨论的，可以初始设置Alt Buy投放表620以允许与该SID关联的客户机设备按该特殊定价(例如CLP＝0)下载该应用。如上文讨论地，通过记帐系统传播该特殊定价句柄和价格等级。然而，除了Alt Buy投放表格620内的定价、项目ID和其它数据之外，还可以存储下载指示符。相应地，一旦下载了该项目(例如通过ADS 106)，就将项目ID许可投放给SID，并将该许可证的状态设置为已投放状态。为项目ID可用的每个可下载许可证保存记录。当将项目ID许可投放给SID时，将该许可证的状态设置为已投放状态。相应地，下载指示符/投放状态表示该项目已经被投放并可以从Alt Buy投放表620中移除(或者通过对下载指示符字段的逻辑检查来功能地删除)。类似地，该项目可能从SID定向(My Apps)群组540不可见的。相应地，在任一情形中，如果再次下载该项目，则可以按主目录510内定义的标准价格等级来提供该项目。因此，可以在无线记帐系统内将标准商业项目定价与Alt Buy定价混合，以允许在对应用、内容和/或服务进行促销和市场销售时有更大的灵活性。

在Alt Buy的情景中，可以在Alt Buy区域610内(例如在运营商自助式服务终端处)生成记帐和分发信息。将该记帐和分发信息传送给SVB 410和群组管理器515。通过记帐和下载交易可以传递和存储这些信息(元数据)中的至少一部分，从而允许该系统将这些交易与单个Alt Buy交易ID相关。例如，可以生成交易元数据并将其随SVB交易携带。使用例如群组管理器515、ADS106或者其它服务器或逻辑，可以将此元数据与向SID定向群组540添加的项目ID关联并随其存储。根据下载请求，可以将该元数据传递给客户机设备。此外，由交易管理器TXN可以将元数据包括在仲裁使用记录内。

Alt Buy交易可以在TXN上生成多个交易数据(例如与SVB记帐请求关联的第一交易数据和与内容向客户机设备的实际投放(例如推/挽)关联的第二交易数据)。因此，可以在整个交易处理中使用跟踪ID，以便能够实现相关交易的端对端跟踪。因而，可以在Alt Buy记帐请求内包括该跟踪ID，并可以根据记帐请求生成第一交易数据。可以通过记帐系统(例如TXN，记帐和结算模块)处理交易数据以生成用户帐单，将支付分发给项目供应商、和/或根据第一交易数据发送报告数据。可以将包括跟踪ID的第一交易数据存储在数据库内，以供随后检索、调整、客户服务、等等。

如上文讨论的，在Alt Buy交易中内容的投放可以与记帐请求分离地发生或者完全不发生(例如如果没有内容被投放)。因此，如果将要投放内容，则可以将内容从主目录添加到与客户机设备关联的SID定向群组内。跟踪ID也可以与SID定向群组内的内容关联。当将来自SID定向群组的内容被下载到客户机设备时，还应将跟踪ID传递给客户机设备。类似地，如先前讨论的，可以应包括跟踪ID的内容的下载生成第二交易数据，并通过其余的记帐、结算和/或报告处理予以处理。也可以存储包括跟踪ID的第二交易数据以供随后检索、调整、客户服务、等等。因此，可以端对端(即从Alt Buy销售到应用下载及交易记帐和结算)地映射和管理Alt Buy交易。能够端对端地跟踪这些交易允许Alt Buy销售渠道的商务智能和应用分发渗透力增强。例如，使用跟踪ID，承载商可以对照购买的应用/内容推导出执行的Alt Buy下载次数。这通过用于Alt Buy相关下载的TXN仲裁/转换过程来实现的。TXN可以使用本地价格句柄将跟踪ID的转换包括在仲裁使用记录内。使用跟踪ID将下载事件与SVB记帐事件相关。因为跟踪ID被包括在仲裁使用记录中，因此它也可被包括在在记帐报告内，而记帐报告可以被集成到承载商记帐和数据仓储解决方案内。

在本发明的另一个实施例中，交易可以包括多个开发者/出版者/销售商/源(752、754、756)，如图7所示。例如，在Alt Buy情景中，可以在同一交易(例如零售游戏包)内捆绑和销售多个应用。如根据上文可以理解的，将SVB用于记帐交易，并使用群组分发来分发所记帐的内容。因此，可以将SVB410配制成根据可以是源内容供应商的多个第三方源收款人754、756以及与每个源收款人754、756关联的源描述和源费用来规定支付结算。除了开发者和/或内容收款人752之外，一个或多个源收款人754、756也可以获得支付。换句话说，可以向内容收款人752支付收入股份分割的内容部分(其可以是内容费用的100％)。从内容费用中处理出一个或多个源收款人支付(即通常源费用不是在内容费用上外加的)。此外，源收款人754、756可以是开发者、出版者或其它内容供应商。例如，在应用捆绑背景下，源收款人754、756可以是开发在该捆绑内包含的应用的各个开发者。内容费用可以是与每个开发者协商的费用加上内容收款人752的附加费用(例如捆绑者/分发者)之和。可以将多方结算(例如支付分发)实现为源收款人扩展结算事件。SVB 410可以支持对已知内容收款人752及其授权的多方源收款人754、756中的任何一个的支付。

因此，对于多方结算，可以在记帐系统内或者通过Alt Buy源生成的记帐请求内包括附加源收款人754、756的信息。例如，可以包括至少一个源收款人ID。源收款人ID可以代表提供内容的至少一部分的第三方收款人(源收款人)。向第三方收款人支付内容收款人752支付中的某一部分。可以包括表示由源收款人754、756提供内容的简短描述的源描述。可以为每个源收款人ID提供表示内容收款人支付的第三方收款人部分的源费用。此附加信息可以包括在随交易传递的记帐元数据内。因此，可以进一步利用无线用户记帐系统来自动地记帐和结算包括多个第三方内容供应商/源的单个交易。

例如，在无线用户记帐系统内处理多方记帐事件时，生成包括与交易关联的内容收款人752、内容费用以及至少一个源收款人754、756和源费用的记帐事件(例如基于来自可信服务490的请求)。处理该交易以将支付(例如通过结算模块460)分发给内容收款人752和该至少一个源收款人754、756。存储(例如在TXN 440或者可操作地耦合到记帐系统的其它数据库上)与内容收款人752和该至少一个源收款人754、756相关的交易数据，以便随后处理(例如客户服务、记帐调整、销售/市场销售数据挖掘、等等)。如上文讨论的，内容费用大于或等于源费用之和。此外，除了存储交易数据之外，可以将该数据的至少一部分作为交易报告数据发送(例如通过结算模块460)给内容收款人752和/或每个源收款人754、756。例如，开发者可能希望使用从记帐和分发系统发送的交易报告数据来跟踪与捆绑相关的应用销售。而且，如上文讨论的，记帐事件通常将导致基于零售价格(例如CLP)为内容投放或排定投放生成用户帐单(例如通过记帐模块450)。零售价格通常大于或等于内容费用。

一旦已经存储交易数据，就可以将其用于如上文讨论的各种目的。一种这样的使用是在客户关系管理(CRM)服务内。如图7所示，运营商710从记帐模块450和结算模块460接收记帐信息(例如内容的发票以及内容费用的源收款人754和756部分)。相应地，运营商710将使此信息可用于CRM目的。假设用户不喜欢通过运营商零售特卖点购买的应用捆绑。因为此类交易(应用捆绑的购买)通常具有在该捆绑内所包括应用的多个开发者，因而将在捆绑购买交易的设置内使用多方结算。现在，假设CRM呼叫中心或管理器720确定应当将支付的价格调整购买价格的百分之二十。到记帐系统的CRM接口730可以访问所存储的交易数据，并根据所存储的交易数据生成包含负内容费用和至少一个负源费用的调整交易。对于局部调整，该系统将成比例地调整所有的多方结算源收款人。

相应地，使用SID和交易跟踪ID等，可以访问与捆绑购买相关联的交易数据。负内容费用和至少一个负源费用可以基于调整百分比和所存储的与内容收款人752和至少一个源收款人754和756的支付相关的交易数据。例如，CRM接口730可以从CRM 720接收调整金额或百分比(例如-20％)。CRM接口730可以访问原始交易数据，随后生成针对内容收款人752和每个源收款人754和756的负支付(例如内容费用和源费用的20％)。调整百分比是没有限制的，但是范围例如可以从百分之一到百分之百(即完全退款)。此外，根据调整百分比和内容的价目表价格还可以生成用户贷记。相应地，对用户的百分之二十的退款可能导致在原始购买中的每个收款人(例如承载商/运营商710、内容收款人752、一个或多个源收款人754、756)接收成比例的百分之二十的借记。通过CRM接口730生成负记帐事件，随后将其通过记帐系统传递并以类似于在上文说明内讨论的记帐事件的方式结算，可以实现上述目的。因而，多方结算系统的CRM接口730允许通过无线用户记帐系统结算的任意多个第三方交易的自动调整。再次，可以存储调整交易数据和/或将其用于生成向运营商710、内容收款人752和/或一个或多个源费用754、756的报告数据。

尽管上述例子结合图7讨论了与SVB购买相关的多方结算和CRM服务，但本发明的实施例并不限制于此配置。使用前文讨论的上述多方结算系统，可以结算包括提供应用、内容和/或服务的多方的任意交易(例如从客户机设备下载的应用)。类似地，通过CRM 720进行的任意调整可以应用于任意记帐事件，而与记帐事件的起源无关。

鉴于上述公开内容，本领域的技术人员将认识到，本发明的实施例包括先前讨论的执行动作、操作和/或功能序列的方法。例如，参见图8，图示了根据本发明一个实施例的方法。可以在可信服务(例如零售店、网站、等等)上生成记帐请求，方框810。将包括记帐信息的记帐请求传送给无线用户记帐系统，方框820。如上文讨论的，该传送可以是任意方式的到远程可信服务的有线和/或无线通信(例如互联网、LAN、WAN、无线连接、等等)。在无线用户记帐系统内生成对记帐请求的确认响应，方框830，并将其传送给可信服务，方框840。在处理该记帐请求之前可以验证该可信服务以确保欺骗性记帐事件不会被处理，方框825。如上文讨论的，在传送记帐请求之前，作为验证来自可信服务的记帐请求传输的一部分，可以在可信服务处数字签署该记帐请求。

此外，如在上文中讨论的，在记帐请求内的记帐信息可以包括用于处理和跟踪交易的各种信息，诸如用户ID、供应商ID/内容收款人、内容/项目ID、零售价格和/或记帐描述等。然而，如本领域的普通技术人员将理解的，不是全部这些字段都是必要的，这也不是将要使用的可能字段的完整列表。例如，在赠送礼物情景内可以在记帐请求内定义向用户ID的记帐单和向用户ID的投放。替换地，根据交易类型，用户ID可以仅代表向ID的记帐或发送。例如，可以使用SVB来购买无线用户系统外部的项目/服务，但是使用无线用户记帐系统来记帐无线用户和结算该交易。替换地，在上文讨论的Alt Buy示例中，可以在无线用户系统外部购买在无线用户系统内可获得的项目(例如应用、内容、服务、等等)，并且可以将SID用于识别向设备/用户的投放的目的(例如应用将可供在零价格等级上下载)。因此，根据许多因素，例如交易类型、和在交易内涉及的各方(例如运营商、一个或多个供应商、可信服务、等等)的具体偏好，在记帐请求内包含的或者随后与记帐事件关联的信息可以变化。

再次参见图8，在接收到确认响应之后，可以在可信服务上予以处理，方框850。确认响应的处理也可以根据交易的类型而变化。例如在使用无线用户记帐系统对无线用户就在无线系统外部的购买进行记帐的SVB交易中，响应通常是准许或拒绝，并且除非接收到准许，否则将不提供所购买的项目(例如服务、文章、等等)。然而，在Alt Buy情景中，因为是在无线用户系统外部购买项目，并且通常仅通过无线用户系统投放该项目，因此确认响应可以仅仅是接收到该请求的确认。在任一种情景中，如果未接收到确认响应，则可以生成附加请求，并且通过关联记帐请求内的跟踪ID可以区分分离的交易，以便能够轻易地识别出重复交易。

参见图9，在Alt Buy情景中确认了记帐请求之后，可以将例如从无线承载商可获得(例如在主目录/商业目录内)的购买项目(例如应用)投放给与记帐请求内的SID相关联的设备/用户。例如，参见图9，可以从主目录将与记帐请求关联的项目添加到定向到与记帐请求关联的用户ID的群组(SID定向群组)，方框910。为了跟踪项目的投放，可以将投放表内的信息与在SID定向群组内的项目关联，方框920。随后可以投放该项目，方框930。例如，可以从SID定向群组下载该项目或者将其推送给与SID关联的客户机设备。然而，项目的投放可以采取多种形式，例如启动附加服务，媒体流送，而不限制于下载到客户机设备。

可应项目的下载使用投放表中的信息来生成交易数据，方框940，并且可根据交易数据生成记帐事件，方框950。如果在Alt Buy情景内支付项目，则在投放表内的信息可以包括该项目的零值零售价格，类似地，交易数据和记帐事件各自可包括对应于该项目的零值零售价格。相应地，可以在不生成给用户的帐单的情况下投放该项目并通过记帐系统跟踪和报告该投放。替换地，该值可以大于零，但是低于主目录内的全零售价格，并且可以通过记帐系统处理该折扣价格，向用户记帐打折金额。

参见图10，如上所述，替换实施例可以在记帐请求内包括跟踪ID，方框1010。可以根据记帐请求生成包括跟踪ID的第一交易数据，可以处理第一交易数据(例如向用户记帐、向供应者支付和/或生成报告)，方框1020。可以在交易数据内存储跟踪ID，方框1030，以便随后检索和与其它交易一起使用。可以从主目录中将作为记帐请求主题的项目添加到与SID/客户机设备相关的用户ID定向(SID定向)群组，并且可将跟踪ID与SID定向群组内的项目相关联，方框1040。可以从SID定向群组投放该项目和相关的跟踪ID，方框1050。例如，可以将该项目和包括跟踪ID的元数据下载到客户机设备。一旦投放了该项目，就可以生成和处理包括跟踪ID的第二交易数据，方框1060。可以用类似于第一交易数据的方式通过记帐系统处理第二交易数据，并且跟踪ID可用于关联两个交易。

因此，包括基于SVB生成的记帐事件的跟踪ID的第一交易可以引起在Alt Buy情景内例如应用的外部购买等的交易的记帐和结算。可以在记帐系统内存储交易和跟踪ID元数据。当实际将应用下载到客户机设备时，可以将跟踪ID传送给客户机设备，可以根据下载生成第二交易。第二交易可以包括来自投放表的专用定价句柄，所以在下载时不对用户记帐，如上文所讨论的。然而，可以通过记帐系统处理该事件，以便可以跟踪该项目的投递并报告给该项目(例如应用)的承载商和一个或多个供应商。再次，在第二交易数据内将包括跟踪ID，并可以将其存储在记帐系统内以便随后检索和报告等。相应地，通过项目的结算和投递，根据记帐请求，可以端对端地跟踪在无线用户记帐系统外部生成的购买/记帐请求。

如图11所示的另一个实施例可以包括在无线用户记帐系统内处理多方记帐事件的方法。生成包括供应商费用和收款人以及与交易相关联的至少一个源费用和收款人的记帐事件，方框1110。例如，出版者可以提供包括应用和内容(例如音乐和视频等)的组合的项目以供无线用户下载。如上文讨论的，当将项目下载到客户机设备时，可以生成记帐事件。与该项目关联的元数据可以包括通过无线用户记帐系统处理该交易的信息。具体而言，该信息可以包括该项目的供应商收款人(例如出版者ID和相关信息)和费用(例如支付该出版者的金额)。类似地，每个源收款人(例如开发者ID、内容供应商ID)和每个源的费用(例如为应用支付开发者和为内容支付内容供应商的金额)的相关信息也可以与该项目关联。因此，可以由记帐系统自动地记帐和结算多方交易，例如处理该交易以将支付分发给供应商收款人和每个源收款人，方框1120。

可以存储交易数据用于进一步处理、数据挖掘和CRM服务，方框1130。为了CRM调整目的，可以访问所存储的交易数据，方框1140。可以根据所存储的交易数据生成包含负供应商费用和至少一个负源费用的调整交易，方框1150。可根据该负供应商费用和该至少一个负源费用来处理该调整交易以向该供应商收款人和该至少一个源收款人借记，方框1160。该调整交易可以对于从初始多方交易提取收入的每方都是成比例的。类似地，可以根据调整比例和该项目的零售价格生成用户贷记，方框1170。例如，假设在给定零售价格上购买项目。运营商、供应商和源可以各自在预先确立的比例(例如如由与该项目关联的相应费用定义的)上从零售价格提取收入。根据与该项目关联的费用，无线用户记帐系统可以自动地对该用户记帐并向各方支付，并可以存储该信息以供随后访问，如先前讨论的。一旦由CRM代表确定用户应当被贷记或者退还购买的一部分，则可以将调整交易作为负记帐事件处理。因而，无线用户记帐系统可以访问所存储的交易数据，并与从原始交易支付的相应费用成比例地对每方(例如运营商、供应商和源)借记。相应地，调整可以通过记帐系统自动地传播，并与所有各方成比例，这可以显著地降低结算和CRM服务的人工成本。

在其它实施例中，本领域的技术人员将理解，可以通过执行在诸如计算机平台的存储器等计算机可读介质上实施的程序来实现上述方法。指令可以驻留在各种类型的信号承载或数据存储一级、二级或三级介质内。该介质可以包括例如由客户机设备和/或服务器访问的RAM，或者驻留其内。无论是包含在RAM、磁盘还是其它次级存储介质内，指令都可以存储在各种机器可读数据存储介质内，例如DASD存储器(例如常规“硬盘驱动器”或者RAID阵列)、磁带、电子只读存储器(例如ROM或EEPROM)、闪存卡、光存储设备(例如CD-ROM、WORM、DVD、数字光带)、纸质“穿孔”卡或者包含数字和模拟传输介质在内的其它适当数据存储介质。

虽然上述公开内容示出了本发明的说明性实施例，但是应当注意到，在此可以进行各种改变和修改而不会脱离由权利要求定义的本发明的范围。根据在此描述的本发明实施例的方法权利要求的功能、步骤和/或动作不需要以任何特定次序执行。此外，尽管可能是以单数形式描述或要求保护本发明的要素，但是也构想了复数形式，除非明确地陈述限制为单数。

权利要求书(按照条约第19条的修改)

1. 一种方法，包括：

在可信服务(490)处生成记帐请求，所述记帐请求与一客户机设备(300)关联；

将包括记帐信息的所述记帐请求传送至无线用户记帐系统；

在所述无线用户记帐系统内生成对所述记帐请求的确认响应；

将所述确认响应传送至所述可信服务(490)；

从主目录创建定向到所述客户机设备(300)的群组，所述群组包括至少一个项目；以及

向所述客户机设备(300)呈示包括所述至少一个项目的所述群组。

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

在处理所述记帐请求之前认证所述可信服务(490)。

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

在传送所述记帐请求之前在所述可信服务处数字地签署所述记帐请求。

4. 如权利要求1所述的方法，其中所述记帐信息包括用户ID、供应商收款人、项目ID、零售价格和记帐描述中的至少一项。

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

响应于所述记帐请求的无效，返回一个出错代码。

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

在所述可信服务(490)处处理所述确认响应。

7. (删除)

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

从所述群组投放所述至少一个项目。

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

将投放表内的信息与所述群组内的所述至少一个项目相关联。

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

在所述至少一个项目投放之际使用所述投放表内的信息生成交易数据；以及

根据所述交易数据生成记帐事件。

11. 如权利要求10所述的方法，其中所述投放表内的信息包括所述至少一个项目的零值零售价格，并且其中所述交易数据和记帐事件各自包括所述至少一个项目的零值零售价格。

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

在所述投放表内记录已投放状态来指示所述至少一个项目的投放。

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

当所述投放表内与所述群组内的所述至少一个项目关联的信息被设置为所述已投放状态时，禁止进一步下载。

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

在所述记帐请求内包括跟踪ID；

根据所述记帐请求生成包括所述跟踪ID的第一交易数据；以及

处理所述第一交易数据。

15. 如权利要求14所述的方法，其中处理所述第一交易数据还包括：

生成用户帐单；

将支付分发给供应商；以及

将根据所述第一交易数据的报告数据发送给运营商和所述供应商中的至少之一。

16. 如权利要求14所述的方法，其中处理所述第一交易数据还包括：

在所述交易数据内存储所述跟踪ID。

17. 如权利要求14所述的方法，其中所述创建群组是基于所述客户机设备(300)的属性执行的。

18. 如权利要求17所述的方法，还包括：

将所述跟踪ID与所述群组内的所述至少一个项目关联；以及

从所述群组投放所述至少一个项目和所述跟踪ID。

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

在所述至少一个项目投放之际生成包括所述跟踪ID的第二交易数据；以及

处理所述第二交易数据。

20. 如权利要求19所述的方法，其中处理所述第二交易数据还包括：

当处理所述第一交易数据包括生成用户帐单时，禁止向用户记帐。

21. 一种设备，包括：

在无线用户记帐系统内的服务价值记帐(SVB)(410)模块，配置成从可信服务(490)接收记帐请求并验证所述可信服务(490)，所述记帐请求与一客户机设备(300)相关联；以及

确认逻辑，配置成响应于所述记帐请求生成确认响应；

配置成从主目录创建定向到所述客户机设备(300)的群组的逻辑，所述群组包括至少一个项目；以及

配置成向所述客户机设备(300)呈示包括所述至少一个项目的所述群组的逻辑。

22. 如权利要求21所述的设备，还包括：

交易管理器(TXN)(440)，配置成接收与所述记帐请求关联的交易数据并生成记帐事件；

客户机记帐模块(450)，配置成从所述交易管理器(440)接收所述记帐事件并生成帐单；以及

结算模块(460)，配置成从所述交易管理器(440)接收所述记帐事件，给承载商开发票，并向供应商支付。

23. 如权利要求22所述的设备，其中所述TXN(440)将附加记帐信息与所述记帐请求关联以生成所述记帐事件。

24. 如权利要求21所述的设备，其中所述可信服务(490)被配置成生成所述记帐请求。

25. 如权利要求24所述的设备，其中所述可信服务(490)被配置成数字地签署所述记帐请求。

26. 如权利要求21所述的设备，其中所述记帐请求包括用户ID、供应商收款人、项目ID、零售价格、和记帐描述中的至少之一。

27. (删除)

28. 如权利要求21所述的设备，还包括：

投放表，包括与所述群组内的所述至少一个项目关联的信息。

29. 如权利要求28所述的设备，其中所述投放表内的信息包括所述至少一个项目的零值零售价格。

30. 如权利要求28所述的设备，还包括：

配置成将所述至少一个项目的投放记录在所述投放表内的逻辑；以及

配置成当所述投放表内与所述群组内的所述至少一个项目关联的信息被设置为已投放状态时禁止进一步下载的逻辑。

31. 一种系统，包括：

用于在无线用户记帐系统处从可信服务(490)接收包括记帐信息的记帐请求的装置，所述记帐请求与一客户机设备(300)相关联；

用于在所述无线用户记帐系统内生成对所述记帐请求的确认响应的装置；

用于将所述确认响应传送给所述可信服务(490)的装置；

用于从主目录创建定向到所述客户机设备(300)的群组的装置，所述群组包括至少一个项目；以及

用于向所述客户机设备(300)呈示包括所述至少一个项目的所述群组的装置。

32. 如权利要求31所述的系统，还包括：

用于在处理所述记帐请求之前认证所述可信服务(490)的装置。

33. 如权利要求31所述的系统，其中所述记帐信息包括用户ID、供应商收款人、项目ID、零售价格、和记帐描述中的至少一项。

34. (删除)

35. 如权利要求31所述的系统，还包括：

用于从所述群组投放所述至少一个项目的装置；以及

用于将投放表内的信息与所述群组内的所述至少一个项目关联的装置。

36. 如权利要求35所述的系统，还包括：

用于在所述至少一个项目投放之际使用所述投放表内的信息生成交易数据的装置；以及

用于根据所述交易数据生成记帐事件的装置。

37. 如权利要求35所述的系统，其中所述投放表内的信息包括所述至少一个项目的零值零售价格，并且其中所述交易数据和记帐事件各自包括所述至少一个项目的零值零售价格。

38. 如权利要求37所述的系统，还包括：

用于在所述投放表内记录已投放状态以指示所述至少一个项目的投放的装置；以及

用于在所述投放表内与所述群组内的所述至少一个项目关联的信息被设置为已投放状态时禁止进一步下载的装置。

39. 一种其上存储有指令的计算机可读介质，所述指令在被执行之际使所述计算设备执行操作，所述指令包括：

至少一条用于接收来自可信服务(490)的记帐请求的指令，其中所述记帐请求与一客户机设备(300)相关联；

至少一条用于在所述无线用户记帐系统内生成对所述记帐请求的确认响应的指令；

至少一条用于将所述确认响应传送给所述可信服务(490)的指令；

至少一条用于从主目录创建定向到所述客户机设备(300)的群组的指令，所述群组包括至少一个项目；以及

至少一条用于向所述客户机设备(300)呈示包括所述至少一个项目的所述群组的指令。

40. (删除)

41. 一种在无线用户记帐系统内处理多方记帐事件的方法，所述方法包括：

生成包括供应商费用和收款人以及与交易关联的至少一个源费用和收款人的记帐事件；以及

处理所述交易以将支付分发给所述供应商收款人和所述至少一个源收款人；

存储交易数据；

访问所存储的交易数据；

根据所存储的交易数据生成包含负供应商费用和至少一个负源费用的调整交易；以及

处理所述调整交易以根据所述负供应商费用和所述至少一个负源费用对所述供应商收款人和所述至少一个源收款人借记。

42. 如权利要求41所述的方法，其中所述供应商费用大于或等于所述至少一个源费用。

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

将交易报告数据发送给所述供应商收款人和所述至少一个源收款人中的至少一个。

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

根据所提供的项目的零售价格生成用户帐单，其中所述零售价格大于或等于所述供应商费用。

45. (删除)

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

根据比例基础以及所存储的与所述供应商收款人和所述至少一个源收款人的支付相关的交易数据，确定所述负供应商费用和所述至少一个负源费用。

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

根据所述调整比例和所述项目的零售价格，生成用户贷记。

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

存储所述调整交易。

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

将调整交易报告数据发送给所述供应商收款人和所述至少一个源收款人中的至少一个。

Claims

1.一种方法，包括：

在可信服务处生成记帐请求；

将包括记帐信息的所述记帐请求传送至无线用户记帐系统；

在所述无线用户记帐系统内生成对所述记帐请求的确认响应；以及

将所述确认响应传送至所述可信服务。

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

在处理所述记帐请求之前认证所述可信服务。

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

4.如权利要求1所述的方法，其中所述记帐信息包括用户ID、供应商收款人、项目ID、零售价格和记帐描述中的至少一项。

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

响应于所述记帐请求的无效，返回一个出错代码。

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

在所述可信服务处处理所述确认响应。

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

将与所述记帐请求相关联的项目从主目录添加至指向与所述记帐请求关联的用户ID的群组(SID定向群组)。

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

从所述SID定向群组投放所述项目。

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

将投放表内的信息与所述SID定向群组内的项目相关联。

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

在所述项目投放之际使用所述投放表内的信息生成交易数据；以及

根据所述交易数据生成记帐事件。

11.如权利要求10所述的方法，其中所述投放表内的信息包括所述项目的零值零售价格，并且其中所述交易数据和记帐事件各自包括所述项目的零值零售价格。

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

在所述投放表内记录已投放状态来指示所述项目的投放。

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

当所述投放表内与所述SID定向群组内的所述项目关联的信息被设置为所述已投放状态时，禁止进一步下载。

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

在所述记帐请求内包括跟踪ID；

处理所述第一交易数据。

15.如权利要求14所述的方法，其中处理所述第一交易数据还包括：

生成用户帐单；

将支付分发给供应商；以及

16.如权利要求14所述的方法，其中处理还包括：

在所述交易数据内存储所述跟踪ID。

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

将一项目从所述主目录添加到与一客户机设备关联的用户ID定向(SID定向)群组；以及

将所述跟踪ID与所述SID定向群组内的所述项目关联。

18.如权利要求17所述的方法，还包括：

从所述SID定向群组投放所述项目和所述跟踪ID。

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

在所述项目投放之际生成包括所述跟踪ID的第二交易数据；以及

处理所述第二交易数据。

20.如权利要求19所述的方法，其中处理所述第二交易数据还包括：

21.一种设备，包括：

在无线用户记帐系统内的服务价值记帐(SVB)模块，配置成从可信服务接收记帐请求并验证所述可信服务；以及

确认逻辑，配置成响应于所述记帐请求生成确认响应。

22.如权利要求21所述的设备，还包括：

交易管理器(TXN)，配置成接收与所述记帐请求关联的交易数据并生成记帐事件；

客户机记帐模块，配置成从所述交易管理器接收所述记帐事件并生成帐单；以及

结算模块，配置成从所述交易管理器接收所述记帐事件，给承载商开发票，并向供应商支付。

23.如权利要求22所述的设备，其中所述TXN将附加记帐信息与所述记帐请求关联以生成所述记帐事件。

24.如权利要求21所述的设备，其中所述可信服务被配置成生成所述记帐请求。

25.如权利要求24所述的设备，其中所述可信服务被配置成数字地签署所述记帐请求。

26.如权利要求21所述的设备，其中所述记帐请求包括用户ID、供应商收款人、项目ID、零售价格、和记帐描述中的至少之一。

27.如权利要求21所述的设备，还包括：

配置成将与所述记帐请求关联的项目从主目录添加到定向到与所述记帐请求关联的用户ID的群组(SID定向群组)的逻辑。

28.如权利要求27所述的设备，还包括：

投放表，包括与所述SID定向群组内的所述项目关联的信息。

29.如权利要求28所述的设备，其中所述投放表内的信息包括所述项目的零值零售价格。

30.如权利要求28所述的设备，还包括：

配置成将所述项目的投放记录在所述投放表内的逻辑；以及

配置成当所述投放表内与所述SID定向群组内的所述项目关联的信息被设置为已投放状态时禁止进一步下载的逻辑。

31.一种系统，包括：

用于在无线用户记帐系统处从可信服务接收包括记帐信息的记帐请求的装置；

用于在所述无线用户记帐系统内生成对所述记帐请求的确认响应的装置；以及

用于将所述确认响应传送给所述可信服务的装置。

32.如权利要求31所述的系统，还包括：

用于在处理所述记帐请求之前认证所述可信服务的装置。

33.如权利要求31所述的系统，其中所述记帐信息包括用户ID、供应商收款人、项目ID、零售价格、和记帐描述中的至少一项。

34.如权利要求31所述的系统，还包括：

用于将与所述记帐请求关联的项目从主目录添加到用户ID(SID)定向群组的装置。

35.如权利要求34所述的系统，还包括：

用于从所述SID定向群组投放所述项目的装置；以及

用于将投放表内的信息与所述SID定向群组内的所述项目关联的装置。

36.如权利要求35所述的系统，还包括：

用于在所述项目投放之际使用所述投放表内的信息生成交易数据的装置；以及

用于根据所述交易数据生成记帐事件的装置。

37.如权利要求35所述的系统，其中所述投放表内的信息包括所述项目的零值零售价格，并且其中所述交易数据和记帐事件各自包括所述项目的零值零售价格。

38.如权利要求37所述的系统，还包括：

用于在所述投放表内记录已投放状态以指示所述项目的投放的装置；以及

用于在所述投放表内与所述SID定向群组内的所述项目关联的信息被设置为已投放状态时禁止进一步下载的装置。

39.一种其上存储有用于在无线用户记帐系统内处理记帐请求的计算机程序的计算机可读介质，所述计算机程序包括在被执行之际使所述计算设备执行以下过程的指令：

接收来自可信服务的记帐请求，其中所述记帐请求向所述无线用户记帐系统记帐信息；

将所述确认响应传送给所述可信服务。

40.所述的计算机可读介质，还包括在被执行之际使所述计算设备执行以下过程的指令：

将与所述记帐请求关联的项目从主目录添加到定向到与所述记帐请求关联的用户ID的群组(SID定向群组)。

41.一种在无线用户记帐系统内处理多方记帐事件的方法，所述方法包括：

处理所述交易以将支付分发给所述供应商收款人和所述至少一个源收款人。

42.如权利要求41所述的方法，其中所述供应商费用大于或等于所述至少一个源费用。

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

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

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

存储交易数据；

访问所存储的交易数据；

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

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

根据所述调整比例和所述项目的零售价格，生成用户贷记。

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

存储所述调整交易。

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