用户权益发放方法、系统、电子设备以及介质

技术领域

本公开涉及虚拟权益领域，具体地，涉及用户权益发放方法、系统、电子设备以及介质。

背景技术

当前的社交软件(例如Soul APP)中存在多个业务场景和领域需要使用到权益(Right)，如各种榜单、会员业务、群聊等级等功能场景，这些领域的权益有交叉和相互重叠。同时，用户权益体系(或会员权益体系)几乎是各大成熟应用(APP：Application)的标配，用户身份权益体系通过对用户赋予身份(会员、等级)的方式，提供不同级别的产品权限给不同的用户，是用户活跃度运营以及商业化的重要工具。

权益指的是平台的某个服务、利益或特权，其可以被发放/授予给用户，且用户可以使用该权益。比如聊天室领域的用户进场动画-坐骑、聊天室内用户相互赠送的动画礼物；再比如用户个人主页上显示的勋章；抽奖场景里的抽奖免费次数；会员领域的会员身份等。

权益商品化是指部分权益可能需要在虚拟商品平台新增商品对应，达成可以售卖的能力。但不是每个权益都是需要商品映射的，需要售卖的就可以用商品来承载。也就是说，商品是权益买卖的一个载体。

权益包是各种具体权益的一定集合，可作为权益的发放单位，比如榜单。

各业务方现有权益的发放基本都是各自为营。在业务开发中用到权益发放时，直接引入每一种权益发放的路径，业务方直接与下游的各种权益基础服务打交道。直接打交道的缺点是由于下游权益的接入规则不同，导致n种权益就有n种接入规则镶嵌在同一个业务方的代码中，造成编码不统一，维护难度大；同时业务有可能不对权益的发放到账情况做补偿处理，这样会导致用户资产损失与体验变差。

发明内容

提供该发明内容部分以便以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。该发明内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。

根据本公开的一些实施例，提供了一种用户权益发放方法，包括：提供权益注册，使得至少一个权益服务提供方能够将资源或商品注册为权益；通过封装所述至少一个权益服务提供方的发放接口，提供统一的发放契约接口；响应于业务方的权益发放请求，通过消息队列中间件对请求发放的权益进行异步解耦；将请求发放的权益的发放记录表初始化为未发放；通过所述统一的发放契约接口调用所述至少一个权益服务提供方来发放权益：以及在权益发放完成后将其发放记录表的发放状态更新为已发放。

根据本公开的一些实施例，提供了一种用户权益发放系统，包括：配置单元，被配置为提供权益注册，使得至少一个权益服务提供方能够将资源或商品注册为权益；以及逻辑实现单元，被配置为：通过封装所述至少一个权益服务提供方的发放接口，提供统一的发放契约接口；响应于业务方的权益发放请求，通过消息队列中间件对请求发放的权益进行异步解耦；将请求发放的权益的发放记录表初始化为未发放；通过所述统一的发放契约接口调用所述至少一个权益服务提供方来发放权益：以及在权益发放完成后将其发放记录表的发放状态更新为已发放。

根据本公开的一些实施例，提供了一种电子设备，包括：存储器；和耦接至存储器的处理器，所述处理器被配置为基于存储在所述存储器中的指令，执行本公开中所述的任一实施例的方法。

根据本公开的一些实施例，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时执行本公开中所述的任一实施例的方法。

根据本公开的一些实施例，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时执行本公开中所述的任一实施例的方法。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征、方面及其优点将会变得清楚。

附图说明

下面参照附图说明本公开的优选实施例。此处所说明的附图用来提供对本公开的进一步理解，各附图连同下面的具体描述一起包含在本说明书中并形成说明书的一部分，用于解释本公开。应当理解的是，下面描述中的附图仅仅涉及本公开的一些实施例，而非对本公开构成限制。在附图中：

图1示出了根据本公开的示例性实施例的用户权益发放调用结构的示意框图。

图2示出了根据本公开的示例性实施例的用户权益中心的示意结构框图。

图3示出了根据本公开的示例性实施例的配置单元提供的权益注册界面示意图。

图4示出了根据本公开的示例性实施例的配置单元提供的权益包管理界面示意图。

图5示出了根据本公开的示例性实施例的用户权益发放方法的示意流程图。

图6示出了根据本公开的示例性实施例的电子设备的示意性框图。

图7示出了根据本公开的示例性实施例中可采用的计算机系统的示例结构的框图。

应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不一定是按照实际的比例关系绘制的。在各附图中使用了相同或相似的附图标记来表示相同或者相似的部件。因此，一旦某一项在一个附图中被定义，则在随后的附图中可能不再对其进行进一步讨论。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，但是显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。以下对实施例的描述实际上也仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值应被解释为仅仅是示例性的，不限制本公开的范围。

本公开中使用的术语“包括”及其变型意指至少包括后面的元件/特征、但不排除其它元件/特征的开放性术语，即“包括但不限于”。此外，本公开使用的术语“包含”及其变型意指至少包含后面的元件/特征、但不排除其它元件/特征的开放性术语，即“包含但不限于”。因此，包括与包含是同义的。术语“基于”意指“至少部分地基于”。

整个说明书中所称“一个实施例”、“一些实施例”或“实施例”意味着与实施例结合描述的特定的特征、结构或特性被包括在本公开的至少一个实施例中。例如，术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。而且，短语“在一个实施例中”、“在一些实施例中”或“在实施例中”在整个说明书中各个地方的出现不一定全都指的是同一个实施例，但是也可以指同一个实施例。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。除非另有指定，否则“第一”、“第二”等概念并非意图暗示如此描述的对象必须按时间上、空间上、排名上的给定顺序或任何其它方式的给定顺序。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

下面结合附图对本公开的实施例进行详细说明，但是本公开并不限于这些具体的实施例。下面这些具体实施例可以相互结合，对于相同或者相似的概念或过程可能在某些实施例不再赘述。此外，在一个或多个实施例中，特定的特征、结构或特性可以由本领域的普通技术人员从本公开将清楚的任何合适的方式组合。

现有技术中权益的发放主要有以下几点问题：1)各业务方的权益发放模块需要重复开发(包括C端的发放代码、B端的管理模块)，各业务方发放n种权益就要按各种权益的发放规则接入n种发放流程，各业务方都要这样去实现一遍，同时如果其中有一个权益发放规则变更，就要各接入业务方都要去跟着去重新开发接入；同时各业务方还要开发一套权益发放的管理配置模块，以达到权益的定义、权益发放数量、时效期的配置等。2)权益的定义不统一：对权益的定义依赖于各产品提供的业务需求而定，对某一种权益的定义在甲产品的需求中定义为商品类权益，在乙产品的需求中定义为资源类权益，这样会导致业务方在代码层面使用两种发放路径，同时增加了代码的复杂度，也让同一种权益保持了两种定义，容易造成使用者的误解。3)对权益的发放不能保证100％到账：各业务方对权益的到账情况重视程度不一，因此可能对发放过程中的不到账情况不做处理，或者做的补偿流程有缺失，进而造成发放的用户权益不到账问题。例如有的业务方由于开发工时紧张可能不对权益到账情况做核对补偿，从而不能权益100％到达用户的权益账户，这样会造成用户财产损失与体验变差。4)存在发放接口调用混乱，无法统一收口，接口调用无业务方认证及标识：由于权益基础服务存在多个权益发放接口，上游的业务方可能存在使用不同的接口发放其权益的问题，这样存在的问题就是发放同一个权益各业务方可能使用了不同的发放接口，或者使用了错误的发放接口，造成下游权益方统计数据的混乱；同时，下游权益基础服务未对权益发放方做认识及来源标识，这样一方面会导致权益发放没有许可便可以发放，造成权益的乱发及偷发问题；同时没有来源标识就不能统计某一业务方发放的权益数量及变化。5)权益发放的数据统计成本过高：对权益发放数据的统计需要到各个权益基础服务里统计，过程比较麻烦且底层数据的储存可能不统一，造成统一数据的难度加大。

为了解决现有技术中权益发放的上述问题，本公开提出了用户权益中心(也称为用户权益发放系统)的概念。权益中心作为各业务方与各权益服务提供方之间的接口，能够统一对每一种权益的定义，提供统一的权益管理配置后台，用于权益的注册和管理，保证权益发放到资源账户，规范权益发放流程，并且还引入了权益发放监控及报警功能。

图1示出了根据本发明实施例的用户权益发放调用结构的示意框图。如图1所示，业务方调用权益中心，权益中心调用权益服务提供方。

图2示出了根据本发明的示例性实施例的用户权益中心200的示意结构框图。如图2所示，权益中心(即用户权益发放系统)包括配置单元210、逻辑实现单元220、旁路单元230和数据库240。逻辑实现单元220又包括权限校验单元221、权益合法性校验单元222和逻辑处理单元223。

根据本发明的实施例，配置单元210可以被配置为提供权益注册、权益包管理、业务方管理和权益手动发放。

根据本发明的实施例，提供权益注册包括提供权益注册界面，使得至少一个权益服务提供方能够通过所述权益注册界面将资源或商品注册为权益。图3示出了根据本公开的示例性实施例的配置单元210提供的权益注册界面示意图。如图3所示，权益中心在接收到权益服务提供方通过权益注册界面输入的权益名称、权益类型、权益分类，选择是否支持撤回、是否上传照片，并且在选择了上传照片的情况下还包括上传照片后，响应于权益服务提供方对“确定”交互按钮的激活(例如，点击确定按钮)，对所输入的权益进行注册。通过使得提供服务的权益服务提供方统一向权益中心注册权益，可以统一权益的定义。

根据权益的属性，所述权益包括但不限于商品类权益、资源类权益和账户类权益。商品类权益是指可用来买卖的权益，用商品来承载，例如礼物、会员身份、聊天室坐骑等。资源类权益是指勋章、聊天室上限人数等不能用来买卖的权益。账户类权益是指平台货币(例如，在Soul APP里为Soul币)、抽奖的免费次数、星际庄园的肥料等账户类权益，这类权益跟资源类权益的区别是，账户类权益可用来当平台的货币购买其它虚拟权益。

根据本发明的实施例，提供权益包管理包括提供权益包管理界面，使得业务方能够通过该权益包管理界面配置要使用的权益包。图4示出了根据本公开的示例性实施例的配置单元210提供的权益包管理界面示意图。权益中心可以通过接收业务方在图4所示的界面上创建权益包、删除权益包和/或修改权益包的操作对权益包进行管理。如图4所示，通过界面上的权益(例如权益1)右侧的“+”、“-”图标可以分别增加和删除一个权益输入框，并且通过界面上的权益(例如权益1)右侧的层叠图标可以复制当前权益框。应理解，在创建和/修改权益包的时候，带*号的内容为必填项。

根据本发明的实施例，提供业务方管理包括对要接入权益中心的业务方进行登记，给已登记的每个业务方分配接入密钥，并将所登记的每个业务方与其分配的接入密钥的对应关系存入数据库。

根据本发明的实施例，权益手动发放包括响应于用户请求，手动给用户补发权益和/或批量发放权益。权益手动发放的引入可以提高用户体验。

根据本发明的实施例，权限校验单元221可以被配置为接收业务方在请求接入时输入的密钥，并将接收的密钥与数据库中给该业务方分配的接入密钥进行比较，在接收到的密钥为数据库中存储的给该业务方分配的接入密钥时允许接入，否则拒绝接入。权限校验单元221的引入可以防止未经授权的业务乱发权益。

根据本发明的实施例，权益合法性校验单元222可以被配置为对业务方的入参做合法性校验，验证是不是根据接口契约传入的。具体地，对于业务方传过来的权益发放数据，权益合法性校验单元将其与数据库中存入的这些类型的权益发放规则进行比较以校验该权益发放数据是否合法。根据本发明的实施例，权益合法性校验单元进行的校验包括但不限于参数类型、发放权益合法性与幂等处理的校验。权益合法性校验单元222的引入可以对接入的各业务方进行进一步的规范。

根据本发明的实施例，逻辑处理单元223可以被配置为提供权益查询、查询缓存、权益日志记录和权益发放。具体地，提供权益查询包括对外提供权益相关查询，比如权益配置查询(即权益包的内容)，权益或权益包的发放状态或内容情况查询等。查询缓存是指为了提高权益查询的性能，对权益查询涉及的内容(例如包括权益包的配置内容、权益或权益包的发放情况等)进行缓存。

权益日志记录是指权益中心的发放订单(也即后面提到的发放记录表)。权益中心在接受业务方的发放权益请求后会在数据库里记录这一笔发放的订单，根据发放的过程来更新订单的状态：未发放、正在发放、已发放，这三个状态记录了权益中心的发放过程。除了状态，还记录业务方(谁发放)、收权益方、发放时间、权益发放的是什么等信息。

因此，提供权益日志记录包括在发放初期初始化包括状态、收发方、时间、权益内容等信息的一笔发放订单(即发放记录表)到数据库，然后根据发放的过程去更新这笔发放订单(即发放记录表)的发放状态。

根据本发明的实施例，提供权益发放包括：通过封装所述至少一个权益服务提供方的发放接口，提供统一的发放契约接口；响应于业务方的权益发放请求，通过消息队列中间件对请求发放的权益进行异步解耦；将请求发放的权益的发放记录表初始化为未发放；通过所述统一的发放契约接口调用所述至少一个权益服务提供方来发放权益：以及在权益发放完成后将其发放记录表的发放状态更新为已发放。虽然图中未示出，但是应理解，可以在逻辑处理单元223中构建一个权益发放器(图中未示出)来实现上述权益发放的各项操作。

根据本发明的实施例，旁路单元230可以被配置为提供权益的补偿、监控及报警。

具体地，关于提供权益的补偿，旁路单元230可以被配置为：在逻辑处理单元233通过该统一的发放契约接口调用所述至少一个权益服务提供方来发放权益(单权益或权益包)之后，通过消息队列中间件发放延迟消息；以及核实请求发放的权益的发放记录表的发放状态，在请求发放的权益的发放记录表的发放状态为未发放的情况下，指示所述逻辑实现单元通过所述统一的发放契约接口调用所述至少一个权益服务提供方来再次发放权益。

此外，关于提供监控及报警，所述旁路单元230还可以被配置为统计并监控预定时间(例如，一天)内各权益的发放情况，并在所述预定时间内有权益发放超过预定阈值的情况下发出报警。

根据本发明的实施例，数据库240可以被配置为存储已注册的权益、已登记的业务方、每个已登记的业务方与其分配的接入密钥的对应关系、每一笔发放订单的发放记录表(包括订单的实时发放状态、收发方、时间、权益内容等信息)。

图5示出了根据本发明的示例性实施例的用户权益发放方法的流程图500。根据本公开实施例的用户权益发放方法可以由图2所示的权益中心(即用户权益发放系统)来实现。

如图5所示，在步骤S501处，提供权益注册，使得至少一个权益服务提供方能够将资源或商品注册为权益。根据本发明的实施例，可以通过图2中所示的权益中心的配置单元210来提供所述权益注册。根据所述权益的属性，所述权益包括商品类权益、资源类权益和账户类权益。

在步骤S502处，通过封装所述至少一个权益服务提供方的发放接口，提供统一的发放契约接口。

在步骤S503处，响应于业务方的权益发放请求，通过消息队列中间件对请求发放的权益进行异步解耦。

在步骤S504处，将请求发放的权益的发放记录表初始化为未发放。

在步骤S505处，通过所述统一的发放契约接口调用所述至少一个权益服务提供方来发放权益。

在步骤S506处，在权益发放完成后将其发放记录表的发放状态更新为已发放。

根据本发明的实施例，可以通过图2中所示的权益中心的逻辑实现单元220(具体地，由逻辑实现单元220的逻辑处理单元223)来实现步骤S502-S506。

根据本发明的优选实施例，所述方法500还可以包括进行权益补偿的步骤S507和S508。根据本发明的实施例，图5中所示的方法500的步骤S507和S508可以通过图2中所示的旁路单元230来执行。

如图5所示，在步骤S507处，通过消息队列中间件发放延迟消息。在步骤S508处，核实请求发放的权益的发放记录表的发放状态是否为已发放。在请求发放的权益的发放记录表的发放状态为未发放的情况下，回到步骤S505(即，通过图2中所示的所述逻辑实现单元220通过所述统一的发放契约接口调用所述至少一个权益服务提供方来再次发放权益)，否则在请求发放的权益的发放记录表的发放状态为已发放的情况下，结束流程。

根据上述参考图2对权益发放请求的描述可知，业务方的权益发放请求可以包括单权益发放请求和权益包发放请求。

虽然图中未示出，但是在业务方的权益发放请求为权益包发放请求的情况下，所述方法500还可以包括：通过图2中所示的权益中心的配置单元210提供权益包管理，使得业务方能够配置要使用的包括多个权益的权益包。

虽然图中未示出，但是方法500还可以包括通过图2中所示的旁路单元230统计并监控预定时间(例如，一天)内各权益的发放情况，以及在所述预定时间内有权益发放超过预定阈值的情况下，发出报警。

虽然图中未示出，但是方法500还可以包括：通过图2中所示的配置单元210提供业务方管理以对要接入权益中心的业务方进行登记，给已登记的每个业务方分配接入密钥，并将所登记的每个业务方与其分配的接入密钥的对应关系存入数据库。

虽然图中未示出，但是方法500还可以包括：通过图2中所示的配置单元210，响应于用户请求手动给用户补发权益和/或批量发放权益。权益手动发放的引入可以提高用户体验。

虽然图中未示出，但是方法500还可以包括：通过图2中所示的权限校验单元221，接收业务方在请求接入时输入的密钥，并将接收的密钥与数据库中给该业务方分配的接入密钥进行比较，在接收到的密钥为数据库中存储的给该业务方分配的接入密钥时允许接入，否则拒绝接入。权限校验单元221的引入可以防止未经授权的业务乱发权益。

虽然图中未示出，但是方法500还可以包括：通过图2中所示的权益合法性校验单元222，对业务方的入参做合法性校验，验证是不是根据接口契约传入的。具体地，对于业务方传过来的权益发放数据，权益合法性校验单元将其与数据库中存入的这些类型的权益发放规则进行比较以校验该权益发放数据是否合法。根据本发明的实施例，权益合法性校验单元进行的校验包括但不限于参数类型、发放权益合法性与幂等处理的校验。

虽然图中未示出，但是方法500还可以包括：通过图2中所示的逻辑处理单元223，提供权益查询、查询缓存和权益日志记录。具体地，提供权益查询包括对外提供权益相关查询，比如权益配置查询(即权益包的内容)，权益或权益包的发放状态或内容情况查询等。提供查询缓存包括对权益查询涉及的内容(例如包括权益包的配置内容、权益或权益包的发放情况等)进行缓存以加快查询接口的性能。提供权益日志记录包括在发放初期初始化一笔包括状态、收发方、时间、权益内容等信息的发放订单(即发放记录表)到数据库，然后根据发放的过程去更新这笔发放订单(即发放记录表)的状态和内容。

本申请公开的用户权益发放系统及方法统一并规范了权益的定义与发放，提供了可靠便利的权益发放功能，无须业务方重复开发、即接即用，且能够保证权益100％发放到资源账户，解放各业务方重复写补偿模块的工作，同时能够按业务调用方来监控权益的发放及预警权益的超发，还提供了便利的权益管理配置后台，引入业务标识，规范权益发放流程，提升了运营及产品维护权益的工作效率，也减少了因配置问题导致的线上事故。

本公开的一些实施例还提供一种电子设备。图6示出了本公开的电子设备6的一些实施例的框图。该电子设备可用来实现根据本公开的任一实施例所述的方法。

例如，在一些实施例中，电子设备6可以为各种类型的设备，例如可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。例如，电子设备6可以包括显示面板，以用于显示根据本公开的方案中所利用的数据和/或执行结果。例如，显示面板可以为各种形状，例如矩形面板、椭圆形面板或多边形面板等。另外，显示面板不仅可以为平面面板，也可以为曲面面板，甚至球面面板。

如图6所示，该实施例的电子设备6包括：存储器61以及耦接至该存储器61的处理器62。应当注意，图6所示的电子设备6的组件只是示例性的，而非限制性的，根据实际应用需要，该电子设备6还可以具有其它组件。处理器62可以控制电子设备6中的其它组件以执行期望的功能。

在一些实施例中，存储器61用于存储一个或多个计算机可读指令。处理器62用于运行计算机可读指令时，计算机可读指令被处理器62运行时实现根据上述任一实施例所述的方法。关于该方法的各个步骤的具体实现以及相关解释内容可以参见上述的实施例，重复之处在此不作赘述。

例如，处理器62和存储器61之间可以直接或间接地互相通信。例如，处理器62和存储器61可以通过网络进行通信。网络可以包括无线网络、有线网络、和/或无线网络和有线网络的任意组合。处理器62和存储器61之间也可以通过系统总线实现相互通信，本公开对此不作限制。

例如，处理器62可以体现为各种适当的处理器、处理装置等，诸如中央处理器(CPU)、图形处理器(Graphics Processing Unit，GPU)、网络处理器(NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。中央处理元(CPU)可以为X86或ARM架构等。例如，存储器61可以包括各种形式的计算机可读存储介质的任意组合，例如易失性存储器和/或非易失性存储器。存储器61例如可以包括系统存储器，系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)、数据库以及其它程序等。在存储介质中还可以存储各种应用程序和各种数据等。

另外，根据本公开的一些实施例，根据本公开的各种操作/处理在通过软件和/或固件实现的情况下，可从存储介质或网络向具有专用硬件结构的计算机系统，例如图7所示的计算机系统700安装构成该软件的程序，该计算机系统在安装有各种程序时，能够执行各种功能，包括诸如前文所述的功能等等。图7示出了根据本公开的实施例中可采用的计算机系统的示例结构的框图。

在图7中，中央处理单元(CPU)701根据只读存储器(ROM)702中存储的程序或从存储部分708加载到随机存取存储器(RAM)703的程序执行各种处理。在RAM 703中，也根据需要存储当CPU 701执行各种处理等时所需的数据。中央处理单元仅仅是示例性的，其也可以是其它类型的处理器，诸如前文所述的各种处理器。ROM 702、RAM 703和存储部分708可以是各种形式的计算机可读存储介质，如下文所述。需要注意的是，虽然图7中分别示出了ROM702、RAM 703和存储部分708，但是它们中的一个或多个可以合并或者位于相同或不同的存储器或存储模块中。

CPU 701、ROM 702和RAM 703经由总线704彼此连接。输入/输出接口705也连接到总线704。

下述部件连接到输入/输出接口705：输入部分706，诸如触摸屏、触摸板、键盘、鼠标、图像传感器、麦克风、加速度计、陀螺仪等；输出部分707，包括显示器，比如阴极射线管(CRT)、液晶显示器(LCD)，扬声器，振动器等；存储部分708，包括硬盘，磁带等；和通信部分709，包括网络接口卡比如LAN卡、调制解调器等。通信部分709允许经由网络比如因特网执行通信处理。容易理解的是，虽然图7中示出的计算机系统700中的各个装置或模块是通过总线704来通信的，但它们也可以通过网络或其它方式进行通信，其中，网络可以包括无线网络、有线网络、和/或无线网络和有线网络的任意组合。

根据需要，驱动器710也连接到输入/输出接口705。可拆卸介质711比如磁盘、光盘、磁光盘、半导体存储器等等根据需要被安装在驱动器710上，使得从中读出的计算机程序根据需要被安装到存储部分708中。

在通过软件实现上述系列处理的情况下，可以从网络比如因特网或存储介质比如可拆卸介质711安装构成软件的程序。

根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置709从网络上被下载和安装，或者从存储装置708被安装，或者从ROM 702被安装。在该计算机程序被CPU 701执行时，执行本公开实施例的方法中限定的上述功能。

需要说明的是，在本公开的上下文中，计算机可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是，但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

在一些实施例中，还提供了一种计算机程序，包括：指令，指令当由处理器执行时使处理器执行上述任一个实施例的方法。例如，指令可以体现为计算机程序代码。

在本公开的实施例中，可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言，诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络(，包括局域网(LAN)或广域网(WAN))连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的模块、部件或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块、部件或单元的名称在某种情况下并不构成对该模块、部件或单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示例性的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

以上描述仅为本公开的一些实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

在本文提供的描述中，阐述了许多特定细节。然而，理解的是，可以在没有这些特定细节的情况下实施本公开的实施例。在其它情况下，为了不模糊该描述的理解，没有对众所周知的方法、结构和技术进行详细展示。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。