CN102065057B

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

Info

Publication number: CN102065057B
Application number: CN200910109675.9A
Authority: CN
Inventors: 丘志宏; 符海芳; 张�杰
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2009-11-18
Filing date: 2009-11-18
Publication date: 2014-07-16
Anticipated expiration: 2029-11-18
Also published as: US20120102179A1; CN102065057A; US8832250B2; WO2011060689A1

Abstract

本发明实施方式公开一种应用于Widget的代理服务的方法，所述方法包括：接收用户终端发起的Widget使用API的服务请求；将所述服务请求转发至API服务提供商，并将所述API服务提供商对所述服务请求的响应转发于所述用户终端；收集所述Widget使用API服务产生的计费信息，记录所述收集的计费信息，所述计费信息用于与所述Widget注册的计费策略一起对所述Widget使用的API服务进行统一计费。本发明实施方式还提供一种服务器，可以减少了用户繁杂的操作，带来了更好的用户体验。

Description

一种应用于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的代理服务的方法及服务器，以减少了用户和API服务提供商的繁杂的操作，带来了更好的用户体验。

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

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

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

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

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

所述服务器从所述用户使用所述Widget产生的费用金额中，获得所述API服务提供商的费用金额；

所述服务器将所述获得的所述API服务提供商的费用金额分发给所述API服务提供商；

所述服务器根据所述Widget的使用率，从剩余的费用金额中分发相应的费用金额至Widget的开发者；

在所述服务器接收用户终端发起的Widget使用API的服务请求之前，所述方法还包括：

所述服务器接收所述Widget的注册信息，所述注册信息包括Widget ID，Widget计费策略，及所述Widget使用的API ID；及

所述服务器接收所述API服务提供商的注册信息，所述注册信息包括API的结算方式；其中，Widget计费策略包括融合计费，统一计费及按使用次数计费。

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

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

所述计费单元用于当所述服务代理单元接收所述服务请求后，收集所述Widget使用API服务产生的计费信息，并记录所述收集的计费信息，所述计费信息用于与所述Widget注册的计费策略一起对所述Widget使用的API服务进行统一计费，还用于根据所述计费单元所收集的所述计费信息和所述API服务提供商注册的API结算方式对所述API服务提供商进行结算；

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

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

所述服务器费用管理单元，用于根据所述计费单元计费结算后的信息从所述用户费用管理单元中的费用金额中扣除用户使用所述Widget产生的费用金额，所述结算后的信息包括user ID及金额数目，还用于根据所述Widget的使用率，从剩余的费用金额中分发相应的费用金额至Widget的开发者；

所述服务器还包括：

Widget注册管理单元，用于接收所述Widget的注册信息，所述注册信息包括Widget ID，Widget计费策略，及所述Widget使用的API ID；和

API注册管理单元，用于接收所述API服务提供商的注册信息，所述注册信息包括API的结算方式。

本发明实施例提供的技术方案，通过服务器统一代理收集Widget使用API服务产生的计费信息，不需要API服务提供商分别进行各自的计费信息收集，减少了API服务提供商繁杂的操作，并通过服务器将用户使用API服务的请求，代理转发至API服务提供商，并将API服务提供商对服务请求的响应转发至用户，从而就不需要用户与多个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的服务请求。在本实施例中，该服务请求中包括鉴权信息，该鉴权信息包括userID，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中是否存在该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服务提供商的结算，还可以包括：

步骤S118，与API服务提供商进行结算。

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

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

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

步骤S202，当服务器将API服务提供商对该服务请求的响应转发至用户后，开始记录服务开始时间。在本实施例中，当将API服务提供商对该服务请求的响应转发至用户后，可以理解为，API服务提供商开始提供服务。在本实施例中，也可以理解为，当执行完图1中的步骤S112后，图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，输出综合账单。在本实施例中，此处的账单中可以包括userID、使用的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时的消息示例：

关闭Widget时的消息示例：

可见，在打开和关闭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为本发明实施例的服务器的结构图。

在本实施例中，服务器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还用于根据服务请求中的userID确定该用户为服务器注册用户，拥有服务器的使用权限。在本实施例中，可以查询服务器中注册的用户中是否存在该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 AccessMemory，RAM)等。

最后应说明的是：以上实施例仅用以说明本发明的技术方案而非对其进行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的精神和范围。

Claims

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

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

2.根据权利要求1所述的方法，其特征在于，所述服务器接收用户终端发起Widget使用API的服务请求的步骤包括：

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

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

3.根据权利要求2所述的方法，其特征在于，所述服务请求包括鉴权信息，所述鉴权信息包括user ID，Widget ID，及所述Widget使用的API ID。

4.根据权利要求3所述的方法，其特征在于，所述服务器对所述服务请求进行鉴权的步骤包括：

所述服务器根据所述user ID确定所述用户终端的用户为注册用户，拥有使用权限；

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

所述服务器将所述Widget ID和API ID，与Widget的注册信息进行比对，确定所述服务请求中的Widget有使用所述API的权限。

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

所述服务器获取所述用户终端所发起的服务请求中的user ID，Widget ID，及所述Widget使用的API的ID；

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

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

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

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

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

所述服务器根据记录的所述收集的计费信息和Widget注册的计费策略对所述Widget使用的API服务进行统一计费结算。

8.根据权利要求7所述的方法，其特征在于，所述服务器根据记录的所述收集的计费信息和Widget注册的计费策略对所述Widget使用的API服务进行统一计费结算的步骤包括：

所述服务器根据user ID查询用户终端的用户在一定时期内的计费信息；

所述服务器根据Widget ID将用户的计费信息进行分类；

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

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

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

所述服务器对所述Widget使用的API服务的进行计费结算后的信息进行批价处理；

所述服务器输出综合账单。

10.根据权利要求8所述的方法，其特征在于，所述服务器根据所述计费策略对所述Widget使用的API服务进行计费结算的步骤之后，还包括：

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

11.根据权利要求1所述的方法，其特征在于，所述服务器根据所述收集的计费信息和API注册的结算方式对所述API服务提供商进行结算的步骤包括：

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

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

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

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

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

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

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

所述服务器还包括：

Widget注册管理单元，用于接收所述Widget的注册信息，所述注册信息包括Widget ID，Widget计费策略，及所述Widget使用的API ID；

和

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

15.根据权利要求14所述的服务器，其特征在于，所述服务请求包括鉴权信息，所述鉴权信息包括user ID，Widget ID，及所述Widget使用的API ID。

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

17.根据权利要求13所述的服务器，其特征在于，所述记录的所述收集的计费信息包括user ID，Widget ID，API ID，及服务开始时间与结束时间，或所述记录的所述收集的计费信息包括user ID，Widget ID，API ID，及服务完成次数。

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

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

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

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

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