WO2011060689A1

WO2011060689A1 - 一种应用于微件Widget的代理服务的方法及服务器

Info

Publication number: WO2011060689A1
Application number: PCT/CN2010/078438
Authority: WO
Inventors: 丘志宏; 符海芳; 张�杰
Original assignee: 华为技术有限公司
Priority date: 2009-11-18
Filing date: 2010-11-05
Publication date: 2011-05-26
Also published as: US20120102179A1; CN102065057B; US8832250B2; CN102065057A

Description

一种应用于微件 Widget的代理服务的方法 SJIL务器本申请要求于 2009 年 11 月 18 日提交中国专利局、申请号为 200910109675.9、发明名称为"一种应用于 Widget的代理服务的方法及服务器" 的中国专利申请的优先权，其全部内容通过引用结合在本申请中。技术领域

本发明涉及通信领域，特别是涉及一种应用于微件 Widget的代理服务的方法及服务器。背景技术

Widget是一种客户端的小 Web程序，通常可以称之微技或微件，它可以显示并更新本地或远程数据，通常被打包成一个文件被客户端设备下载并安装使用。

Widget的出现极大的改变了电信网络中的业务的形式。在传统的电信网中的服务种类有限，一般是运营商为每种服务提供单独的业务子网，其中包含有针对性很强的计费网元。传统电信网络中的业务的特点是种类少，每类业务运营周期长，业务的开发和运营都由运营商负责，业务开发和运营都经过严格的调研和设计。

而在 Widget模式下， Widget形式的最终业务可由第三方，特别是自由开发者开发。运营商提供的电信能力和内容平台不再作为最终产品提供给用户，而是通过 API ( Application Programming Interface, 应用程序编程接口）的形式提供给开发者调用，开发者在 Widget业务中调用这些 API的能力创造出各式各样的新型业务。当前，在互联网和电信运营网络中，以 API的形式提供服务的服务提供商越来越多，如 Programmableweb网站上到目前为止管理的 OpenAPI超过 1000个，种类有 57种之多。

发明人在实现本发明的过程中，发现现有技术至少存在以下缺点：每个用户可能下载多个 Widget, 每个 Widget又可能使用到多个 API服务，各个 API 服务由不同的服务提供商提供，这样用户需要和众多的 API服务提供商进行分别通信交互，并且当需要进行结算时，这些众多的 API服务提供商需要分别进行收费信息的收集，再根据收集的计费信息进行分别计费结算，这种收费模式不仅不符合用户的习惯，而且增加了用户和 API服务提供商的繁杂操作量。发明内容

本发明实施例提供一种应用于 Widget的代理服务的方法及服务器。

根据本发明的一实施例，提供一种应用于 Widget的代理服务的方法，所述方法包括：

接收用户终端发起的 Widget使用 API的服务请求；

将所述服务请求转发至 API服务提供商，并将所述 API服务提供商对所述服务请求的响应转发于所述用户终端；

收集所述 Widget使用 API服务产生的计费信息，记录所述收集的计费信息，所述计费信息用于与所述 Widget注册的计费策略一起对所述 Widget使用的 API服务进行统一计费。

根据本发明的另一实施例，还提供一种服务器，应用于 Widget的代理服务，所述服务器分别与多个用户终端和多个 API服务提供商通信连接，包括：服务代理单元及计费单元；

所述服务代理单元用于接收用户终端发起的 Widget使用 API的服务请求，并将所述服务请求转发至 API服务提供商，将所述 API服务提供商对所述服务请求的响应转发于所述用户终端；

所述计费单元用于当所述服务代理单元接收所述服务请求后，收集所述

Widget使用 API服务产生的计费信息，并记录所述收集的计费信息，所述计费信息用于与所述 Widget注册的计费策略一起对所述 Widget使用的 API服务进行统一计费。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图 1为本发明实施例的应用于 Widget的代理服务的方法的总体流程图；图 1A为本发明实施例的应用于 Widget的代理服务的方法的具体流程图；图 2为本发明实施例的图 1A中步骤 S114的具体流程图；

图 3为本发明实施例的图 1中步骤 S116的实施流程图；

图 4为本发明实施例的图 3的具体实施流程图；

图 5为本发明实施例的图 1A中的步骤 S118的具体实施例流程图；图 6为本发明实施例的服务器的应用环境图；

图 7为本发明实施例的服务器的结构图。具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本实施例中，多个安装有 Widget的终端可以与一个服务器通信连接，该服务器与多个 API服务提供商通信连接，并与运营商通信连接，其中， API 服务提供商与运营商没有连接。在本实施例中，当用户在使用 Widget时，若需要使用某 API服务供应商或 API服务提供商提拱的服务时，用户通过安装 Widget 的终端向服务器发起服务请求，通过服务器将该请求转向对应的 API 服务提供商，并回传 API服务提供商针对该请求的响应至该 Widget终端。

在本实施例中，用户在使用 Widget时，使用各种收费 API所产生的费用，先由用户与该服务器进行统一代理结算。由服务器转发服务请求产生的收费 API使用费用，由该服务器与 API服务提供商之间进行结算。

在本实施例中，当开发者完成设计 Widget后，将该 Widget上传至服务器供用户下载时，需要将该 Widget在服务器上进行注册，或者是由服务器的管理员将该 Widget进行注册，其中需要注册的信息包括该 Widget ID, Widget 计费策略，及该 Widget所用到的收费 API服务。当然，该 Widget所用到的收费 API服务包括该 Widget使用的 API ID。同时，该用户也需要在该服务器上进行注册，以确保该用户拥有使用的权限。

当然，各个 API服务提供商也需要在该服务器进行注册。

在本实施例中，在统一收费的过程中，包括代理用户转发使用 API服务的服务请求，和定期触发对所涉及的使用 API的费用进行统一收费结算。在本实施例中，由于用户发起了服务请求，并当服务器回传 API服务提供商的响应后，这也就是用户正在使用该 API, 这会产生使用 API的费用。在服务器代理转发用户的服务请求的过程中，会对收集相关的计费信息。在本实施例中，在定期触发对所涉及的使用 API的费用进行统一收费结算的过程中，包括与用户进行统一结算和与 API服务提供商统一结算两个过程。

在本实施例中，图 1为本发明实施例的应用于 Widget的代理服务的方法的总体流程图。在本实施例中，

步骤 S10，接收用户终端发起 Widget使用 API的服务请求；

步骤 S20，将所述服务请求转发至 API服务提供商，并将所述 API服务提供商对所述服务请求的响应转发于所述用户终端；

步骤 S30，收集所述 Widget使用 API服务产生的计费信息，记录所述收集的计费信息，所述计费信息用于与所述 Widget注册的计费策略一起对所述 Widget使用的 API服务进行统一计费。

在本实施例中，服务器统一代理对 Widget使用 API服务时所产生的计费信息进行收集，就可以使 API服务提供商无须再针对每个 API服务进行计费信息的分别收集。通过服务器将用户使用 API服务的请求，统一代理转发至 API服务提供商，并将 API服务提供商对服务请求的响应转发至用户，从而就不需要用户与多个 API服务提供商分别进行通信交互，减少了用户繁杂的操作，带来了更好的用户体验。

在本实施例中，当收集完计费信息，还可以利用所收集的计费信息，对

Widget使用的 API服务进行统一计费。在本实施例中，还可以包括步骤：根据记录的所述收集的计费信息和 Widget 注册的计费策略对所述 Widget 使用的 API服务进行统一计费结算。当然，如果需要对 API服务提供商进行统一计费结算，还可以包括步骤：根据所述收集的计费信息和所述 API服务提供商注册的 API结算方式对所述 API服务提供商进行结算。需要说明的，以上的对 Widget使用的 API服务和 API服务提供商分别进行计费结算的步骤不是必需的步骤，服务器可以只需完成请求的转发和计费信息的收集，利用计费信息进行计费结算可以作为服务器的一个附加的功能。

图 1A为本发明实施例的应用于 Widget的代理服务的方法的具体流程图。在本实施例中，步骤 S100，用户终端的用户发起 Widget使用 API的服务请求。在本实施例中，该服务请求中包括鉴权信息，该鉴权信息包括 user ID， Widget ID, 及该 Widget使用的 API的 ID。在本实施例中，该 Widget ID为用户使用的 Widget的 ID， API ID为用户使用 Widget时，需要请求使用 API的

ID。当然，该鉴权信息可以包括该用户的 IP信息。当然，该用户终端可以安装一个 Widget或多个 Widget。

步骤 S102，服务器接收用户发起的服务请求，并对该服务请求进行鉴权。在本实施例中，鉴权的过程可以包括以下步骤：

步骤 A: 根据服务请求中的 user ID确定该用户为服务器注册用户，拥有服务器的使用权限。在本实施例中，可以查询服务器中注册的用户中是否存在该 user ID。

步骤 B:根据服务请求中的 Widget ID确定该用户使用的 Widget已经在服务器注册。在本实施例中，可以查询服务器中注册的 Widget ID中是否存在该 Widget ID。

步骤 C: 将服务请求中的 Widget ID和 API ID, 与 Widget的注册信息进行比对，确定该服务请求中的 Widget有使用该 API的权限。由于在 Widget 的注册信息中包括 Widget ID和该 Widget所用到的收费 API服务信息，该 Widget所用到的收费 API服务包括该 Widget使用的 API的 ID，因此，将服务请求中的 Widget ID与注册信息中的 Widget ID进行比对，将服务请求中的 API ID与 Widget所用到的收费 API服务中的 API ID进行比对，若都相同，则可以确定该服务请求中的 Widget有使用该 API的权限。在本实施例中，当鉴权成功后，执行步骤 S104，确定是否需要触发计费信息收集。在本实施例中，可以根据该 Widget的计费策略进行所述收集。在本实施例中， Widget 的计费策略可以包括融合计费、统一计费、按使用次数计费、按时长计费、按包月计费和免费服务。在本实施例中，若当前的该 Widget 的计费策略为按包月计费或免费服务时，不需要触发计费信息收集，则执行步骤 S108。若当前的该 Widget的计费策略为按融合计费、统一计费、按时长计费，或按使用次数计费时，需要触发计费信息收集，则执行步骤 S106。

步骤 S106，触发计费信息的收集。当触发计费信息的收集的动作后，就开始执行步骤 S108与步骤 S114。

步骤 S108，对用户的服务请求进行转换。在本实施例中，转换的方式为：去除原始用户的服务请求中的鉴权信息，加入服务器与 API服务提供商协定好的鉴权信息。可以有二种不同的方式，如下：

第一种：以用户名密码方式鉴权：在服务请求中加入服务器在 API服务商处注册的用户名和密码；

第二种：以 IP地址进行鉴权：在服务请求中去除原始用户的 IP信息，加入服务器的 IP信息。

步骤 S110，将转换后的服务请求转发至对应的 API服务提供商。在本实施例中，当 API服务提供商接收该服务请求后，会返回一个针对该服务请求的响应至该服务器。在本实施例中，当执行步骤 S110时，也可以执行步骤 S114。当是按次数收费时，需要记录步骤 S110中的转发服务请求至 API服务提供商事件流的次数。

步骤 S112，将 API服务提供商返回的该服务请求的响应转发至用户。该响应为该 API服务提供商对该服务请求处理后的信息，比如，若用户发送一个天气预报的服务请求，则 API服务提供商将该天气预报的结果返回给用户。

步骤 S114，收集所述 Widget使用 API服务产生的计费信息，记录所收集的计费信息。在本实施例中，计费信息可以包括 user ID， Widget ID, 及所述 Widget使用的 API ID，当然也可以还包括服务起始和结束时间，转发服务请求至 API服务提供商事件流的次数和转发该服务请求的响应至用户事件流的次数。

步骤 S116，根据所记录的所述收集的计费信息和 Widget 注册的计费策略对所述 Widget使用的 API服务进行计费结算。在本实施例中，通过根据所收集的计费信息和注册的计费策略，对用户使用 Widget时所使用的 API服务产生的费用进行结算，从而可以避免用户需要向各 API服务提供商进行分别结算的情况，减少了用户繁杂的操作。

在本实施例中，为实现服务器对 API服务提供商的结算，还可以包括：步骤 S 118，与 API服务提供商进行结算。

本实施例提供的技术方案，通过服务器根据所收集的计费信息和注册的计费策略，对用户使用 Widget时所使用的 API产生的费用进行代理结算，并再与 API服务提供商进行代理结算，从而可以避免用户需要向各 API服务提供商进行分别结算的情况，减少了用户繁杂的操作，带来了更好的用户体验。

图 2为本发明实施例的图 1A中步骤 S114的具体流程图。

当触发计费信息的收集后，在本实施例中，步骤 S200，获取用户所发起的服务请求中的 user ID, Widget ID, 及所述 Widget使用的 API的 ID。

步骤 S202，当服务器将 API服务提供商对该服务请求的响应转发至用户后，开始记录服务开始时间。在本实施例中，当将 API服务提供商对该服务请求的响应转发至用户后，可以理解为， API服务提供商开始提供服务。在本实施例中，也可以理解为，当执行完图 1中的步骤 S 112后，图 2中的步骤 S202 就开始执行，即开始记录服务开始时间。

步骤 S204，确定是否按服务时长计费。

在本实施例中，若确定是按服务时长计费，则执行步骤 S210，即记录服务结束时间。在本实施例中，记录服务结束时间为 API服务提供商结束提供服务的时间。

若确定不是按服务时长计费，则执行步骤 S206，即记录服务完成次数。在本实施例中，包括转发服务请求至 API服务提供商事件流的次数和转发该服务请求的响应至用户事件流的次数。在本实施例中，可以记录步骤 S110中的转发服务请求至 API服务提供商事件流的次数。可以记录步骤 S112中的转发该服务请求的响应至用户事件流的次数。在本实施例中，在不是按服务时长计费的情况下，可以按使用次数计费，此时，需要将转发服务请求至 API服务提供商事件流的次数和转发该服务请求的响应至用户事件流的次数作为计费信息。在本实施例中，当转发服务请求至 API服务提供商事件流的次数和转发该服务请求的响应至用户事件流的次数相等时，即用户的每次服务请求都得到了 API服务提供商的服务，也可以理解为，每次请求都完成了一次的服务；若二者不相等，则说明有部分的服务没有得到提供。

在本实施例中，可以将以上步骤中所获取及所记录的信息作为生成账单的原始计费信息，即所收集的计费信息。

图 3为本发明实施例的图 1A中步骤 S116的实施流程图。

在本实施例中，步骤 S300，定期或周期性触发用户账单结算。

步骤 S302，根据 user ID查询用户在一定时期内的所有原始计费信息。步骤 S304，根据 Widget ID将该用户的原始计费信息进行分类。在本实施例中，每一类的 Widget都分配与该 Widget对应的计费信息。

步骤 S306，根据 Widget ID查询该 Widget注册的计费策略。

步骤 S308，根据所述计费策略对所述 Widget使用的 API服务进行计费结算。

在本实施例中，当计费结算后，还可以包括：

步骤 S310，批价处理。在本实施例中，对所述 Widget使用的 API服务的进行计费结算后的信息进行批价处理。

步骤 S312，输出综合账单。在本实施例中，此处的账单中可以包括 user ID、使用的 widget ID，使用的 API ID，及所产生的金额费用。在本实施例中，月良务器还可以根据用户的查询账单请求，将所述用户的账单输出至用户，这样，用户就对所消费的金额一目了然。

在本实施例中，执行完步骤 S308之后，获得了对所述 Widget使用的 API 服务的结算信息，结算后的信息包括 user ID及金额数目，服务器还可以根据计费结算后的信息扣除用户使用所述 Widget产生的费用金额。在本实施例中，可以由两种实现方式：

第一种，若用户在服务器中有一个费用账户，则服务器可以从该用户的费用账户中扣除用户使用所述 Widget产生的费用金额；

第二种，将计费结算后的信息发送至所述运营商，以通知所述运营商扣除用户在所述运营商账户中的费用金额，所述结算后的信息包括 user ID、服务器 ID及金额数目；再接收所述运营商扣除用户在所述运营商账户中的费用金额。

在本实施例中，服务器可以将该扣除用户使用所述 Widget产生的费用金额，作为服务器的收入金额。

图 4为本发明实施例的图 3的具体实施流程图。

在本实施例中，步骤 S400，定期或周期性触发用户账单结算。

步骤 S402，根据 user ID查询用户在一定时期内的所有原始计费信息。步骤 S404，根据 Widget ID将该用户的原始计费信息进行分类。在本实施例中，每一类的 Widget都分配与该 Widget对应的计费信息。

步骤 S406，根据 Widget ID查询该 Widget注册的计费策略。

在本实施例中，计费策略以融合计费、统一计费和按使用次数计费进行说明。在本发明的实施例中，不限于以上三种计费策略。

若根据 Widget ID 查询该 Widget 的计费策略为融合计费时，执行步骤 S408；若根据 Widget ID查询该 Widget的计费策略为统一计费时，执行步骤 S414; 若根据 Widget ID查询该 Widget的计费策略为按次数计费时，执行步骤 S418。以下分别进行说明描述。

若为融合计费，在本实施例中，步骤 S408，查询每条原始计费信息所涉及的 API ID及该 API的计费策略。在本实施例中，融合计费的功能是指服务器向用户输出综合账单，即能够向用户输出各个 Widget的收费情况的账单。

步骤 S410，分别计算各 API的使用费用。

步骤 S412，将各 API的使用费用进行求和得到融合计费账单。在本实施例中，若有需求，可以进行相关的折扣计算。

若为统一计费，在本实施例中，统一计费是指制定按 Widget的使用情况进行计费的策略，在按 Widget进行收费后，由于使用该 Widget而产生的对 API服务的使用将不再进行收费。这种收费方式可以使得用户能够按 Widget 获得服务，同时按 Widget进行付费，可以避免服务与计费的对象不同带来的不好体验。在本实施例中，可以按 Widget的包月计费，包年计费、使用时间计费等等策略，可以理解为，对 Widget进行定购，即在该 Widget的统一计费策略中存在定购关系。

步骤 S414，根据该 Widget的统一计费策略中的定购关系对该 Widget进行计费。在本实施例中，由于按定购关系进行计费，因而对使用该 Widget而产生的对 API服务的使用将不再进行收费。

步骤 S416，输出该 Widget的计费后的账单。

若为按使用次数计费。当然，如果计费策略为按使用次数计费，若在每次使用过程中发送的服务请求中需包括 session id, 即每次使用过程中的对话包括相同的 session id，可以参考如下两个例进行说明，即可以由两种方式来实现，一种是在打开 Widget时单独发一个消息，另一种是在关闭 Widget时单独发一个消息：

打开 Widget时的消息示例：

{

"user—id": "someone@huawei.com",

"engine_id": "widbeans.com",

"ts": 1193222693000,

"type": "start—widget",

"body": { "widget—id": "rss_newsl "}

}

关闭 Widget时的消息示例：

{

"user—id": "someone@huawei.com",

"engine_id": "widbeans.com",

"ts": 1193222693000, "type": "end—widget",

"body": { "widget—id": "rss_newsl "}

}

可见，在打开和关闭 Widget的消息中的包括相同的 session id。

步骤 S418，统计使用次数，并按使用次数进行计费。在本实施例中，该次数可以为图 2中的步骤 S206和 S208中的事件流的次数。

步骤 S420，输出按使用次数计费后的该 Widget的账单。

在本实施例中，执行步骤 S412或步骤 S416或步骤 S420后，还可以执行步骤 S422。

步骤 S422，批价处理。

步骤 S424，输出综合账单。在本实施例中，用户可以根据需要查询所使用 API服务所产生的费用账单。

图 5为本发明实施例的图 1A中的步骤 S118的具体实施例流程图。

在本实施例中，服务器与 API服务提供商之间的鉴权方法和结算方法，可以由两者之间进行企业级谈判后确定。其中，所涉及的结算信息，可以由服务器进行收集，即图 2中的实施过程，也可以由 API服务提供商进行统计得到，即根据所述 API服务提供商提供的计费信息和所述 API服务提供商注册的 API 结算方式对所述 API服务提供商进行结算，所述 API服务提供商提供的计费信息包括 API ID、服务器 ID，及使用 API的完成服务次数或使用 API的时间。在本实施例中，以结算信息由服务器进行收集获得为例进行说明描述。

步骤 S500，定期或周期性的触发服务器与 API服务提供商的账单结算。步骤 S502，根据 API ID 查询使用该 API的原始计费信息。

步骤 S504，根据该 API ID查询 API服务提供商注册的该 API结算方式，并按该结算方式进行结算。

步骤 S506，累加统计该 API的结算信息。即获得累加后的该 API的结算账单，可以理解为，该 API服务提供商的该 API总的账单。

在本实施例中，当获得 API服务提供商的结算信息后，根据结算信息中的费用金额数目，从服务器中的收入中扣除该 API服务提供商的费用金额，作为该 API服务提供商的收入或者是作为服务器的开支，即从所述扣除用户使用所述 Widget产生的费用金额中，获得所述 API服务提供商的费用金额。

当然，由于 Widget的设计与开发是由开发者通过一定的努力获得的，在服务器可以让开发者也参与运营，可以从收入与开支之后的结算结果中的分发一定比例的金额给开发者。当然，可以根据所述 Widget的使用率或市场价值或用户的高评价度或受欢迎程度等等，从剩余的费用金额中分发相应的费用金额至所述 Widget的开发者。当然，这个开发者，可以是运营商本身，也可以单独的人。

本实施例提供的技术方案，通过服务器统一代理收集 Widget使用 API服务产生的计费信息，不需要 API服务提供商分别进行各自的计费信息收集，减少了 API服务提供商繁杂的操作，并通过服务器将用户使用 API服务的请求，统一代理转发至 API服务提供商，并将 API服务提供商对服务请求的响应转发至用户，从而就不需要用户与多个 API服务提供商分别进行通信交互，减少了用户繁杂的操作，带来了更好的用户体验；

另外，通过服务器将收集的计费信息和 Widget注册的计费策略，对用户使用 Widget时所使用的 API服务产生的费用进行结算，从而可以避免用户需要向各 API服务提供商进行分别结算的情况，减少了用户繁杂的操作，带来了更好的用户体验，并且不需要 API服务提供商分别进行各自的计费结算，减少了 API服务提供商繁杂的操作。服务器还可以为用户输出综合账单，可以使用户清楚得知各个 Widget与 API服务的使用收费情况，可以为用户带来更好的用户体验。

图 6为本发明实施例的服务器的应用环境图。

在本实施例中，用户终端 6通过服务器 7与 API服务提供商 8通信连接，服务器并与运营商 9通信连接。用户终端 6包括第一用户终端 61、第二用户终端 62 第 N用户终端 6N， API服务提供商 8包括第一 API服务提供商

81、第二 API服务提供商 82 第 N API服务提供商 8N，其中，每个用户终端上可以安装有多个 Widget。在本实施例中，服务器 7用于接收用户终端 6 发起的服务请求，并对该服务请求进行鉴权并转换，将转换后的服务请求转发至相应的 API服务提供商 8，并将 API服务提供商 8返回的针对该服务请求的响应转发至用户终端 6。在本实施例中，服务器 7还用于根据所收集的计费信息和注册的计费策略对用户终端 6所使用的 API服务进行结算，并再与 API 服务提供商 8进行结算。

在一些应用环境中，服务器 7和 API服务提供商 8可以是同一实际服务提供商提供的不同服务网元。首先，在这种应用对应的实施例中，服务器 7可以包含图 4对应实施例所述的 Widget的代理服务的所有功能，也可以与图 1对应实施例类似，不包含 "对 API服务提供商进行统一计费结算"的功能。其次，服务器 7与 API服务提供商 8的实际服务提供商可以相同，此时 API服务器中可不包含用户以及用户终端的应用等信息，所述用户以及用户终端的应用等信息可依赖于服务器 7提供运营。此外，服务器 7除了之前各实施例提及的各种功能外，还可包括如背景技术所述的特点，即服务器 7中所涉及的最终业务可由第三方，特别是自由开发者开发，由开发者开发后自动上传到服务器 7 中。即在该实施例中，服务器 7不仅提供面向用户终端的代理服务，而且还提供面向自由开发者的应用上传服务。

图 7为本发明实施例的服务器的结构图。

在本实施例中，服务器 7包括 Widget注册管理单元 71、 API注册管理单元 72、服务代理单元 73、计费单元 74、用户费用管理单元 75、服务器费用管理单元 76、及 API服务提供商费用管理单元 77。在本实施例中，服务代理单元 73包括服务请求鉴权子单元 731、服务请求转换子单元 732、服务请求转发子单元 733、服务应答接收子单元 734及服务应答转发子单元 735; 计费单元 74包括账号管理子单元 741、计费信息收集子单元 742、与 API服务提供商结算子单元 742、账单生成子单元 744、及与用户结算子单元 745。

在本实施例中， Widget注册管理单元 71用于接收所述 Widget的注册信息，即管理每个用户终端上的注册的 Widget, 也可以理解为，用户在使用安装有 Widget的用户终端时，需要将该 Widget在服务器进行注册，其中需要注册的信息包括该 Widget ID, Widget计费策略，及该 Widget所用到的收费 API服务。当然，该 Widget所用到的收费 API服务包括该 Widget使用的 API的 ID。同时，该用户也需要在该服务器上进行注册，以确保该用户拥有使用的权限。 API注册管理单元 72用于接收所述 API服务提供商的注册信息，所述注册信息包括 API的结算方式，即管理 API服务提供商在服务器注册的 API。

在本实施例中，当用户需要通过使用用户终端 6中的 Widget来享受服务时，需要用户终端 6发起使用 API的服务请求。在本实施例中，服务请求鉴权子单元 731用于接收用户终端 6发起的服务请求，并对该服务请求进行鉴权。在本实施例中，该服务请求中包括鉴权信息，该鉴权信息包括 user ID， Widget ID, 及 API ID。在本实施例中，该 Widget ID为用户使用的 Widget的 ID， API ID为用户需要请求使用 API的 ID。当然，该鉴权信息可以包括该用户的 IP 信息。

在本实施例中，服务请求鉴权子单元 731还用于根据服务请求中的 user ID 确定该用户为服务器注册用户，拥有服务器的使用权限。在本实施例中，可以查询服务器中注册的用户中是否存在该 user ID。之后，服务请求鉴权子单元 731还用于根据服务请求中的 Widget ID确定该用户使用的 Widget已经在服务器注册。在本实施例中，可以查询服务器中注册的 Widget中是否存在该 Widget ID。之后，服务请求鉴权子单元 731还用于将服务请求中的 Widget ID和 API ID, 与 Widget的注册信息进行比对，确定该服务请求中的 Widget有使用该 API的权限。

服务请求转换子单元 732用于当服务请求鉴权子单元 731鉴权成功后，对用户的服务请求进行转换。在本实施例中，转换的方式为：去除原始用户的服务请求中的鉴权信息，加入服务器与 API服务提供商协定好的鉴权信息。可以有二种不同的方式，如下：

服务请求转发子单元 733用于将服务请求转换子单元 732转换后的服务请求转发至对应的 API服务提供商。在本实施例中，当 API服务提供商接收该服务请求后，会返回一个针对该服务请求的响应至该服务器。

服务应答接收子单元 734还用于接收 API服务提供商针对该服务请求的响应。

服务应答转发子单元 735还用于将服务应答接收子单元 734接收的响应转发至用户终端。该响应为该 API服务提供商对该服务请求处理后的信息，比如，若用户发送一个天气预报的服务请求，则 API服务提供商将该天气预报的结果返回给用户终端。

在本实施例中，当服务请求鉴权子单元 731 鉴权成功后，计费单元 741 中的计费信息收集子单元 742用于确定是否需要触发计费信息收集，并当确定需要触发计费信息收集时，收集并记录计费信息。计费信息可以包括 user ID， Widget ID，及 API ID，当然也可以还包括服务起始和结束时间，服务完成次数。在本实施例中，可以将所收集的计费信息作为生成账单的原始计费信息。有关该具体的收集计费信息可以参考图 2，此处不再重复描述。

账号管理子单元 741用于管理在服务器注册的用户账号。

与用户结算子单元 745用于根据计费信息收集子单元 742记录收集的计费信息和 Widget注册管理单元 71中的计费策略，生成所述用户终端的账单，即对用户终端所使用的 API服务进行结算。在本实施例中，与用户结算子单元 745 还用于根据 user ID 查询用户在一定时期内的所有原始计费信息，根据 Widget ID将该用户的原始计费信息进行分类，根据 Widget ID查询该 Widget 注册的计费策略，及根据计费策略完成有关该 Widget的计费。

账单生成子单元 744用于根据与用户结算子单元 745 的结算结果输出账单。在本实施例中，账单生成子单元 744用于根据用户的查询账单请求，将所述用户的账单输出至用户。

在本实施例中，在对用户所述 Widget使用的 API服务进行计费结算后，服务器费用管理单元 76用于根据与用户结算子单元 745计费结算后的信息从所述用户费用管理单元 75中扣除用户使用所述 Widget产生的费用金额，所述结算后的信息包括 user ID及金额数目，其中，用户费用管理单元 75用于管理用户的费用金额。在本实施例中，可以将该扣除用户使用所述 Widget产生的费用金额作为服务器的收入。

在本实施例中，与用户结算子单元 745还可以将计费结算后的信息发送至所述运营商，以通知所述运营商扣除用户在所述运营商账户中的费用金额，所述结算后的信息包括 user ID、服务器 ID及金额数目；服务器费用管理单元 76 接收所述运营商扣除用户在所述运营商账户中的费用金额。在本实施例中，可以将该扣除用户使用所述 widget产生的费用金额作为服务器的收入。

与 API服务提供商结算子单元 743用于根据计费信息收集子单元 742收集的计费信息和 API注册的结算方式对所述 API进行结算。在本实施例中，具体为：根据 API ID 查询使用该 API的原始计费信息，并根据该 API ID查询该 API注册的结算方式，并按该结算方式进行结算。

在本实施例中，与 API服务提供商结算子单元 743用于还可以根据所述 API服务提供商提供的计费信息和所述 API服务提供商注册的 API结算方式对所述 API服务提供商进行结算，所述 API服务提供商提供的计费信息包括 API ID、服务器 ID，及使用 API的完成服务次数或使用 API服务的开始与结束时间。

在本实施例中，当对 API服务提供商进行结算后， API服务提供商费用管理单元 77，用于根据与 API服务提供商结算子单元 743对所述 API服务提供商进行结算后的费用金额数目，从所述服务器费用管理单元 76管理的费用金额中，扣除该 API服务提供商的费用金额，作为该 API服务提供商的收入或者是作为服务器的开支，即从所述扣除用户使用所述 Widget产生的费用金额中，获得所述 API服务提供商的费用金额。

API服务提供商费用管理单元 77还用于获得所述 API服务提供商的费用金额，并将所述获得的所述 API服务提供商的费用金额分发给所述 API服务提供商。

当然，由于 Widget的设计与开发是由开发者通过一定的努力获得的，在服务器可以让开发者也参与运营，可以从收入与开支之后的结算结果中的分发一定比例的金额给开发者。当然，可以根据所述 Widget的使用率或市场价值或用户的高评价度或受欢迎程度等等，从剩余的费用金额中分发相应的费用金额至所述 Widget的开发者。当然，这个开发者，可以是运营商本身，也可以单独的人。在本实施例中，服务器费用管理单元 76 还用于根据所述 Widget 的使用率或市场价值或用户的高评价度或受欢迎程度等等，从剩余的费用金额中分发相应的费用金额至所述 Widget的开发者。

账单生成子单元 744还用于累加统计该 API的结算信息。即获得累加后的该 API的结算账单，可以理解为，该 API的总的账单。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory, ROM )或随机存储记忆体 ( Random Access Memory, RAM )等。

以上所述仅为本发明的几个实施例，本领域的技术人员依据申请文件公开的可以对本发明进行各种改动或变型而不脱离本发明的精神和范围。本领域普况下可以互相结合形成新的实施例。

Claims

权利要求

1、一种应用于微件 Widget的代理服务的方法，其特征在于，所述方法包括：

接收用户终端发起的 Widget使用应用程序编程接口 API的服务请求；将所述服务请求转发至 API服务提供商，并将所述 API服务提供商对所述服务请求的响应转发于所述用户终端；

收集所述 Widget使用 API服务产生的计费信息，记录所述计费信息，所述计费信息用于与所述 Widget注册的计费策略一起对所述 Widget使用的 API 服务进行统一计费。

2、根据权利要求 1所述的方法，其特征在于，所述将所述服务请求转发至 API服务提供商包括：

对所述服务请求进行鉴权；

当鉴权成功后，对所述服务请求进行转换；

将转换后的服务请求转发至 API服务提供商。

3、根据权利要求 2所述的方法，其特征在于，所述服务请求包括鉴权信息，所述鉴权信息包括用户 user ID， Widget ID,及所述 Widget使用的 API ID，所述对所述服务请求进行鉴权包括：根据所述 user ID确定所述用户终端的用户为注册用户，拥有使用权限；

根据所述 Widget ID确定所述用户使用的 Widget已经注册；

将所述 Widget ID和 API ID, 与 Widget的注册信息进行比对，确定所述

Widget有使用所述 API的权限。

4、根据权利要求 1所述的方法，其特征在于，所述收集所述 Widget使用 API服务产生的计费信息，记录所述计费信息包括：

在将 API服务提供商对所述服务请求的响应转发至所述用户终端后，开始记录服务开始时间；

若按服务时长计费时，记录服务结束时间。

5、根据权利要求 4所述的方法，其特征在于，所述收集所述 Widget使用 API服务产生的计费信息，记录所述收集的计费信息还包括：

若不按服务时长计费时，记录服务完成次数。

6、根据权利要求 1至 5中任一项所述的方法，其特征在于，还包括：根据 user ID查询用户终端的用户在一定时期内的计费信息；

根据 Widget ID将所述用户在一定时期内的计费信息进行分类；

根据 Widget ID查询所述 Widget注册的计费策略；

根据所述计费策略和进行所述分类后的计费信息对所述 Widget使用的

API服务进行计费结算。

7、根据权利要求 6所述的方法，其特征在于，还包括：

对计费结算后的信息进行批价处理；

输出综合账单。

8、根据权利要求 1所述的方法，其特征在于，还包括：

根据所述计费信息和所述 API服务提供商注册的 API结算方式对所述 API 服务提供商进行结算。

9、根据权利要求 8所述的方法，其特征在于，所述根据所述计费信息和 API注册的结算方式对所述 API服务提供商进行结算包括：

根据所述 API ID 查询使用所述 API时收集的计费信息；

根据所述 API ID查询所述 API服务提供商注册的所述 API结算方式，并按所述结算方式对所述计费信息进行结算；

累加统计所述 API服务提供商的结算信息。

10、根据权利要求 1至 9中任一项所述的方法，其特征在于，还包括：根据所述 API服务提供商提供的计费信息和所述 API服务提供商注册的

API结算方式对所述 API服务提供商进行结算，所述 API服务提供商提供的计费信息包括 API ID、服务器 ID，及使用 API的完成服务次数，或包括 API ID、服务器 ID，及使用 API的时间。

11、根据权利要求 8或 9所述的方法，其特征在于，还包括：

根据计费结算后的信息扣除用户使用所述 Widget产生的费用金额，所述计费结算后的信息包括 user ID及金额数目；

根据对所述 API服务提供商进行结算后的费用金额数目，从所述扣除用户使用所述 Widget产生的费用金额中，获得所述 API服务提供商的费用金额；将所述获得的所述 API服务提供商的费用金额分发给所述 API服务提供商。

12、一种服务器，其特征在于，应用于微件 Widget的代理服务，所述服务器分别与多个用户终端和多个 API服务提供商通信连接，包括：服务代理单元及计费单元；

所述服务代理单元用于接收用户终端发起的 Widget使用应用程序编程接口 API的服务请求，并将所述服务请求转发至 API服务提供商，将所述 API 服务提供商对所述服务请求的响应转发于所述用户终端；

所述计费单元用于当所述服务代理单元接收所述服务请求后，收集所述 Widget使用 API服务产生的计费信息，并记录所述计费信息，所述计费信息用于与所述 Widget注册的计费策略一起对所述 Widget使用的 API服务进行统一计费。

13、根据权利要求 12所述的服务器，其特征在于，所述服务代理单元还用于对所述服务请求进行鉴权，并当鉴权成功后，对所述服务请求进行转换。

14、根据权利要求 12所述的服务器，其特征在于，所述服务请求包括鉴权信息，所述鉴权信息包括 user ID， Widget ID，及所述 Widget使用的 API ID；所述服务代理单元还用于根据所述 user ID确定所述用户终端的用户为注册用户，拥有使用权限，根据所述 Widget ID确定所述用户使用的 Widget已经注册，将所述 Widget ID和 API ID，与 Widget的注册信息进行比对，确定所述 Widget有使用所述 API的权限。

15、根据权利要求 12所述的服务器，其特征在于，所述计费单元还用于根据 user ID查询用户在一定时期内的计费信息，根据 Widget ID将所述用户在一定时期内的计费信息进行分类，根据 Widget ID查询所述 Widget注册的计费策略，根据所述计费策略和进行所述分类后的计费信息对所述 Widget使用的 API服务进行计费结算。

16、根据权利要求 12所述的服务器，其特征在于，还包括：

用户费用管理单元，用于管理用户的费用金额；

服务器费用管理单元，用于根据所述计费单元计费结算后的信息从所述用户费用管理单元管理的所述用户的费用金额中扣除用户使用所述 Widget产生的费用金额，所述计费结算后的信息包括 user ID及金额数目。

17、根据权利要求 12所述的服务器，其特征在于，所述服务器还与运营商通信连接，还包括：

所述计费单元，还用于将计费结算后的信息发送至所述运营商，以通知所述运营商扣除用户在所述运营商账户中的费用金额，所述结算后的信息包括 user ID、服务器 ID及金额数目；

所述服务器费用管理单元，还用于接收所述运营商扣除用户在所述运营商账户中的费用金额。

18、根据权利要求 12所述的服务器，其特征在于，所述计费单元还用于根据所述计费信息和所述 API服务提供商注册的 API结算方式对所述 API服务提供商进行结算。

19、根据权利要求 12所述的服务器，其特征在于，所述计费单元还用于根据所述 API服务提供商提供的计费信息和所述 API服务提供商注册的 API 结算方式对所述 API服务提供商进行结算，所述 API服务提供商提供的计费信息包括 API ID与服务器 ID，及使用 API的完成服务次数或使用 API服务的开始与结束时间。

20、根据权利要求 16所述的服务器，其特征在于，还包括：

API服务提供商费用管理单元，用于根据所述计费单元对所述 API服务提供商进行结算后的费用金额数目，从所述服务器费用管理单元管理的费用金额中，获得所述 API服务提供商的费用金额，并将所述获得的所述 API服务提供商的费用金额分发给所述 API服务提供商。