身份验证系统、方法和平台与流程

本申请涉及通信技术领域，特别涉及一种身份验证系统、方法和平台。

背景技术：

随着信息技术的飞速发展，越来越多的平台类服务出现在人们的日常生活之中，用户可以利用业务平台系统享受相关的服务。例如，利用账单业务平台系统享受缴费服务，利用第三方支付平台进行转账或者提现服务。

为了保证用户通过业务平台系统享受服务的安全性和可靠性，一般情况下，业务平台系统会对用户的操作行为进行合法性验证，例如，可通过密码、短信验证、生物特征(人脸、声纹等)对用户的操作行为的合法性进行验证。

相关技术中，为了对用户的操作行为的合法性进行验证，通常业务系统将核身的业务场景(需要验证用户身份才能继续访问的业务节点)的代码中直接调用各个核身产品的rpc(remoteprocedurecallprotocol，远程过程调用协议)服务接口，然后依次完成每个核身产品(能够验证用户身份的功能模块)的验证流程，以达到用户通过核身后才能推进后续业务的目的。

然而，在实现本发明的过程中发明人发现相关技术存在以下问题：(1)业务代码中直接调用各种核身产品的接口，导致业务和核身产品直接耦合，业务方需要和每个核身产品对接，接入成本高，开发资源浪费。(2)在控制多个核身产品流程时需要消耗大量与业务需求无关的工作量，业务方容易抵触接入多个核身产品，而且各个业务方的实现方式难以统一，用户体验各不相同。(3)在核身产品更新后，对应的业务方需要对开发升级，升级成本高，且不容易管理。

技术实现要素：

本申请旨在至少在一定程度上解决上述技术问题。

为此，本申请的第一个目的在于提出一种身份验证系统，通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

本申请的第二个目的在于提出一种身份验证方法。

本申请的第三个目的在于提出一种身份验证平台。

为达上述目的，根据本申请第一方面实施例提出了一种身份验证系统，包括终端、业务系统、身份验证平台，其中：所述终端，用于向所述业务系统发送访问请求，其中，所述访问请求包括待访问业务的业务标识；所述业务系统，用于将所述业务标识发送至所述身份验证平台；所述身份验证平台，用于根据所述业务系统发送的业务标识确定对应的验证类型，并根据所述验证类型调用对应的验证规则，并通过所述对应的验证规则对用户输入的验证信息进行验证，以及将验证结果发送至所述终端。

本申请实施例的身份验证系统，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

本申请第二方面实施例提供了一种身份验证方法，包括：接收终端通过业务系统发送的待访问业务的业务标识；根据所述业务标识确定对应的验证类型；根据所述验证类型调用对应的验证规则；通过所述对应的验证规则对用户输入的验证信息进行验证；将验证结果发送至所述终端。

本申请实施例的身份验证方法，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

本申请第二方面实施例提供了一种身份验证平台，包括：第一接收模块，用于接收终端通过业务系统发送的待访问业务的业务标识；确定模块，用于根据所述业务系统发送的业务标识确定对应的验证类型；调用模块，用于根据所述验证类型调用对应的验证规则；验证模块，用于通过所述对应的验证规则对用户输入的验证信息进行验证；发送模块，用于将验证结果发送至所述终端。

本申请实施例的身份验证平台，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请一个实施例的身份验证系统的结构示意图；

图2为根据本申请一个实施例的身份验证系统中终端、业务系统和身份验证平台之间的交互流程图；

图3为根据本申请一个实施例的身份验证方法的流程图；

图4为根据本申请另一个实施例的身份验证方法的流程图；

图5为根据本申请一个实施例的身份验证平台的结构示意图；

图6为根据本申请另一个实施例的身份验证平台的结构示意图；

图7为根据本申请又一个实施例的身份验证平台的结构示意图；

图8为根据本申请再一个实施例的身份验证平台的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述根据本申请实施例的身份验证系统、方法和平台。

图1为根据本申请一个实施例的身份验证系统的结构示意图。

如图1所示，根据本申请实施例的身份验证系统包括终端10、业务系统20、身份验证平台30，其中：

终端10用于向业务系统20发送访问请求。

其中，访问请求包括待访问业务的业务标识。

其中，终端10可以为例如是电脑、平板电脑、手机等具有各种操作系统的硬件设备。

业务系统20用于将业务标识发送至身份验证平台30。

身份验证平台30用于根据业务系统20发送的业务标识确定对应的验证类型，并根据业务根据验证类型调用对应的验证规则，并通过对应的验证规则对用户输入的验证信息进行验证，以及将验证结果发送至终端10。

具体地，业务系统20在接收到终端10发送的访问请求后，可根据访问请求中的业务标识判断访问待访问业务是否需要身份验证，若判断出访问待访问业务需要身份验证，则将业务标识发送至身份验证平台30。

在本申请的实施例中，身份验证平台30在获取到待访问业务的业务标识后，可根据预存的业务标识和验证类型的对应关系，确定业务标识对应的验证类型。

其中，验证类型可以包括但不限于密码、短信、验证码、隐私问题、人脸、指纹、眼纹等类型。

其中，需要理解的是，待访问业务对应的验证类型可以为至少一种验证类型。

在实际应用中，可根据业务对安全性的要求设置多种验证类型，例如，待访问业务为大金额转账业务时，该业务对安全性的要求较高，为了保证用户的账号的安全，可设置使用指纹和支付密码两种验证类型，两种方式均验证成功后，执行转账业务。

再例如，在执行找回登录密码业务中，可设置使用短信验证码和隐私问题两种验证类型，以对用户的身份进行验证。

在本申请的实施例中，身份验证平台30还用于：根据接收到的更新后的验证规则对身份验证平台30中对应的验证规则进行更新。

在本申请的实施例中，在用户的身份验证通过后，终端10向业务系统20再次发送访问待访问业务的请求。

其中，业务系统20还用于在接收到终端10再次访问待访问业务的请求时，通过身份验证平台30获取待访问业务的验证结果，并根据验证结果执行后续业务逻辑。

在本申请的一个实施例中，在业务系统20使用身份验证平台30的过程中，业务方可通过身份验证平台30对待访问业务的验证类型进行更新，身份验证平台30在监控到待访问业务的验证类型更新时，根据更新后的验证类型对预存的业务标识和验证类型的对应关系进行更新。

例如，身份验证平台30中预先保存的业务1对应的验证类型为人脸和密码，业务方可通过业务系统20向身份验证平台30发送更新业务1对应的验证类型的更新请求，其中，更新请求中包括业务1的业务标识和更新后的验证类型信息，假设更新后的验证类型信息为指纹和短信验证码，身份验证平台30根据更新请求将业务1对应的验证类型更新为指纹和短信验证码。

本申请实施例的身份验证系统，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

图2为根据本申请一个实施例的身份验证系统中终端10、业务系统20和身份验证平台30之间的交互流程图。该实施例以待访问业务为业务1，且在使用业务1之前需要对用户的验证信息进行验证为例进行描述，如图2所示。

s21，终端10将访问业务1的访问请求发送至业务系统20。

具体地，在使用终端10的过程中，用户可通过10向业务系统20发起访问业务1的访问请求。

s22，业务系统20在判断出访问业务1需要身份验证时，向身份验证平台30发送创建核身任务的创建请求。

其中，创建请求中包括业务1的业务标识。

s23，身份验证平台30根据业务标识创建身份验证任务id，并将身份验证任务id发送至终端10。

其中，身份验证任务id用于唯一标识身份验证过程。

具体地，身份验证平台30在接收到业务系统20的业务标识后，根据业务标识获取业务1对应的验证类型，并根据业务标识和验证类型生成身份验证任务id。

其中，需要理解的是，在生成身份验证任务id后，可将身份验证任务id与本次身份验证所需要的相关信息进行关联，以方便根据身份验证任务id可以获取到身份验证过程中所需要的相关信息。

其中，身份验证所需要的相关信息可以包括但不限于业务场景、业务id、验证类型列表、用户id等信息。

s24，终端10根据身份验证任务id调用终端10中的核身sdk，核身sdk通过终端10向身份验证平台30发送产品渲染请求。

其中，核身sdk是指对外封装了身份认证服务的调用逻辑，并可实现和身份认证平台交互通信的模块。

其中，产品渲染请求中包括身份验证任务id。

s25，身份验证平台30根据产品渲染请求获取对应的渲染数据，并将渲染数据发送至终端10。

具体地，身份验证平台30根据产品渲染请求中的身份验证任务id确定出验证类型，并确定验证类型对应的验证规则，以及获取验证规则所对应的渲染数据，以及将所获取的渲染数据返回终端10。

s26，终端10中的核身sdk根据渲染数据展示产品界面。

s27，终端10向身份验证平台30发送验证请求。

其中，验证请求中包括用户在产品界面中输入的验证信息和身份验证任务id。

s28，身份验证平台30对用户输入的验证信息的合法性进行验证。

具体地，身份验证平台30接收到验证请求后，根据身份验证任务id获取验证类型所对应的验证规则，并将用户输入的验证信息与预先保存的该用户的验证信息进行验证，如果用户输入的验证信息与预先保存的该用户的验证信息匹配，则身份验证成功。另外，如果用户输入的验证信息与预先保存的该用户的验证信息不匹配，则身份验证失败。

举例而言，如果业务1为转账业务，在执行转账业务时需要验证的验证类型为支付密码，在身份验证平台30接收到用户输入的支付密码后，可根据身份验证任务id调用支付密码对应的验证规则，并根据验证规则比较用户输入的支付密码与会员系统存储的支付密码是否一致，若一致，则身份验证成功，若不一致，则身份验证失败。

s29，身份验证平台30将验证结果发送至终端10。

s30，终端10在根据验证结果确定出身份验证成功时，终端10再次向业务系统20提交访问业务1的再次访问请求。

其中，再次访问请求中包括身份验证任务id。

其中，需要理解的是，再次访问请求中还可以包括与执行业务1相关的数据。例如，在用户1向用户2进行转账的过程中，再次访问请求中还包括用户1的账号标识和用户2的账号标识，以及转账金额等信息。

另外，作为一种示例性的实施方式，在终端10中的核身sdk在确定出身份验证失败后，终端10可判断用户的验证次数是否达到预设次数，如果未达到预设次数，则再次加载产品界面，以使用户再次输入指纹信息进行验证。

s31，业务系统20向身份验证平台30发送获取业务1的验证结果的获取请求。

其中，获取请求中包括身份验证任务id。

s32，身份验证平台30根据获取请求中的身份验证任务id获取验证结果，并向业务系统20返回验证结果。

s33，业务系统20根据验证结果执行业务逻辑。

其中，需要理解的是，该实施例中的身份验证任务id用于对同一个业务的多个验证类型进行标识。

例如，如果访问待访问业务要先对指纹进行验证，再对支付密码进行验证，在监控到用户要访问该待访问业务时，业务系统20将该待访问业务的业务标识发送至身份验证平台，身份验证平台根据业务标识获取到该待访问业务的验证类型为指纹类型和支付密码，并根据业务标识和验证类型信息生成身份验证任务id，身份验证任务id与身份验证过程中所需的相关进行关联，然后，终端根据身份验证任务id唤醒核身sdk，核身sdk向身份验证平台发起产品渲染请求，身份验证平台根据产品渲染请求中的身份验证任务id调度出当前需要渲染的验证类型为指纹类型，并调用指纹类型对应的渲染数据，并将指纹类型对应的渲染数据返回至终端，终端根据渲染书数据展示对应的产品界面，此时，用户可根据产品界面中的提示输入指纹信息，终端10将用户输入的指纹信息发送至身份验证平台，身份验证验证平台身份验证任务id调度出指纹类型对应的身份验证规则，并根据身份验证规则对用户输入的指纹信息进行验证。在指纹验证成功后，身份验证验证平台根据身份验证任务id确定出还需要对支付密码进行验证，然后通过与指纹验证过程类似的过程对用户输入的支付密码进行验证，此处不再赘述。

下面以客户端为支付宝，待访问业务为余额提现，即，以支付宝中的余额提现业务场景为例对通过身份验证系统进行身份验证的过程进行描述。

在客户端监控到用户输入提现金额，并监控到用户点击提现按钮时，客户端发送提现业务请求到提现系统，提现系统调用身份验证平台初始化接口，身份验证平台根据提现业务场景查询所需验证的验证类型，比如支付密码，生成身份验证任务id，关联此次核身上下文(包括业务场景、业务id、验证类型列表、用户id等)，然后返回给提现系统，提现系统再返回给客户端。

客户端通过身份验证任务id启动核身sdk，核身sdk根据身份验证任务id向身份验证平台发送核身产品渲染请求，身份验证平台根据身份验证任务id查询出核身上下文，分析出当前需要渲染的验证类型，即支付密码，此时会调用支付密码产品的渲染接口获取支付密码渲染数据(标题文案、是否六位简单密码、加密公钥、时间戳等)，返回给核身sdk，核身sdk根据渲染数据展示出支付密码界面，核身sdk接收用户输入的支付密码后提交验证。

为了保证数据传输的安全性，核身sdk将用户输入数据加密后发送验证请求。对应地，身份验证平台接收到验证请求后，身份验证平台根据验证请求中的身份验证任务id调用支付密码的验证接口，比对用户输入的支付密码是否和会员系统存储的支付密码一致，如果一致，则身份验证成功，否则身份验证失败。

然后，身份验证平台保存该验证类型的验证结果到核身上下文中，同时将验证结果返回给核身sdk，核身sdk根据验证结果展示文案，然后回调客户端，客户端收到核身回调后，如果失败，则业务提示密码验证不通过，提现失败。

如果成功，则携带身份验证任务id再次发送提现业务请求，提现系统收到请求后，根据身份验证任务id调用身份验证平台查询接口查询此次核身结果。如果核身失败，则直接返回身份验证不通过，不用再执行提现业务逻辑。如果核身成功，则正常执行提现业务，将用户的余额资金转到指定的银行卡中。至此，整个提现核身过程结束。

图3为根据本申请一个实施例的身份验证方法的流程图。

如图3所示，本申请实施例的身份验证方法包括以下步骤：

s301，接收终端通过业务系统发送的待访问业务的业务标识。

其中，终端可以为例如是电脑、平板电脑、手机等具有各种操作系统的硬件设备。

具体地，在使用终端的过程中，业务系统接收到终端发送的访问请求后，可根据访问请求中的业务标识判断访问待访问业务是否需要身份验证，若判断出访问待访问业务需要身份验证，则将业务标识发送至身份验证平台，以通过身份验证平台进行身份验证。

s302，根据业务标识确定对应的验证类型。

其中，验证类型可以包括但不限于密码、短信、验证码、隐私问题、人脸、指纹、眼纹等类型。

其中，需要理解的是，待访问业务对应的验证类型可以为至少一种验证类型。

在实际应用中，可根据业务对安全性的要求设置多种验证类型，例如，待访问业务为大金额转账业务时，该业务对安全性的要求较高，为了保证用户的账号的安全，可设置使用指纹和支付密码两种验证类型，两种方式均验证成功后，执行转账业务。

再例如，在执行找回登录密码业务中，可设置使用短信验证码和隐私问题两种验证类型，以对用户的身份进行验证。

在本申请的实施例中，在接收到待访问业务的业务标识时，可根据预存的业务标识和验证类型的对应关系，确定业务标识对应的验证类型。

s303，根据验证类型调用对应的验证规则。

s304，通过对应的验证规则对用户输入的验证信息进行验证。

s305，将验证结果发送至终端。

在本申请的一个实施例中，如图4所示，该方法还可以包括：

s306，接收业务系统发送的获取待执行业务的验证结果的获取请求。

其中，获取请求包括待执行业务的业务标识。

在终端根据验证结果确定出身份验证成功，终端向业务系统再次发送访问待访问业务的请求，业务系统向身份验证平台发送获取待执行业务的验证结果的获取请求。

s307，根据待执行业务的业务标识获取待执行业务的验证结果，并向业务系统返回验证结果，以使业务系统根据验证结果执行后续业务逻辑。

例如，在用户1向用户2进行转账的过程中，再次访问请求中还包括用户1的账号标识和用户2的账号标识，以及转账金额等信息，在业务系统从身份验证平台获取用户1转账业务的身份验证成功后，业务系统将根据用户1的转账业务完成用户1与用户2之间的转账。

本申请实施例的身份验证方法，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

通常对于待访问业务，业务方可根据业务需求可对待访问业务对应的验证类型进行修改，在本申请的一个实施例中，当身份验证平台监控到待访问业务的验证类型更新时，身份验证平台根据更新后的验证类型对预存的业务标识和验证类型的对应关系进行更新。

例如，身份验证平台中预先保存的业务1对应的验证类型为人脸和密码，业务方可通过业务系统向身份验证平台发送更新业务1对应的验证类型的更新请求，其中，更新请求中包括业务1的业务标识和更新后的验证类型信息，假设更新后的验证类型信息为指纹和短信验证码，身份验证平台根据更新请求将业务1对应的验证类型更新为指纹和短信验证码。

由此，可以看出，在业务方使用身份验证平台的过程中，业务方可根据需求对需要身份验证才能访问的业务的验证类型进行调整，方便了用户设置业务的验证类型，避免了业务方通过修改代码中身份验证接口来调整验证类型的麻烦，减少了用户调整业务的验证类型的麻烦，进而可提高业务方调整业务的验证类型的效率。

在本申请的一个实施例中，通常身份验证平台中的验证规则会随着技术发展进行更新，身份验证平台在接收到更新后的验证规则后，身份验证平台可根据接收到的更新后的验证规则对身份验证平台中对应的验证规则进行更新。

由于业务方中的业务和验证规则不是直接耦合，因此，在身份验证平台中的验证规则的过程中，业务方不需要做任何改动，这相对于业务和验证规则直接耦合的方式来说，大大减少了业务方的升级成本，降低了维护成本。

与上述实施例提供的身份验证方法相对应，本申请还提出一种身份验证平台。

图5为根据本申请一个实施例的身份验证平台的结构示意图。

如图5所示，根据本申请实施例的身份验证平台30包括第一接收模块110、确定模块120、调用模块130、验证模块140和发送模块150，其中：

具体地，第一接收模块110用于接收终端通过业务系统发送的待访问业务的业务标识。

确定模块120用于根据业务系统发送的业务标识确定对应的验证类型。

其中，其中，验证类型可以包括但不限于密码、短信、验证码、隐私问题、人脸、指纹、眼纹等类型。

其中，需要理解的是，待访问业务对应的验证类型可以为至少一种验证类型。

在实际应用中，可根据业务对安全性的要求高的业务，可以设置多种验证类型，例如，待访问业务为大金额转账业务时，可设置使用指纹和支付密码两种验证类型，两种方式均验证成功后，执行转账业务。

再例如，在执行找回登录密码业务中，可设置使用短信验证码和隐私问题两种验证类型，以对用户的身份进行验证。

具体地，在第一接收模块110接收到待访问业务的业务标识时，确定模块120可根据预存的业务标识和验证类型的对应关系，确定业务标识对应的验证类型。

调用模块130用于根据验证类型调用对应的验证规则。

验证模块140用于通过对应的验证规则对用户输入的验证信息进行验证。

发送模块150，用于将验证结果发送至终端。

本申请实施例的身份验证平台，在业务系统判断出访问待访问业务需要身份验证时，业务系统将待访问业务的业务标识发送至身份验证平台，通过身份验证平台完成用户身份验证，身份验证平台将验证结果发送至终端。由此，该实施例通过身份验证平台降低了业务系统和验证规则之间的耦合度，业务系统接入身份验证平台即可根据业务需求使用身份验证平台中任意一种或者多种验证类型，方便业务系统设置业务的验证类型，并且通过统一的身份验证系统对业务进行身份验证，提供统一的用户体验。

在本申请的一个实施例中，在图5所示的实施例的基础上，如图6所示，上述身份验证平台还可以包括：

第一更新模块160用于根据接收到的更新后的验证规则对身份验证平台中对应的验证规则进行更新。

在本申请的一个实施例中，在图6所示的实施例的基础上，如图7所示，上述身份验证平台还可以包括：

第二接收模块170用于接收业务系统发送的获取待执行业务的验证结果的获取请求，其中，获取请求包括待执行业务的业务标识；

处理模块180用于根据待执行业务的业务标识获取待执行业务的验证结果，并向业务系统返回验证结果，以使业务系统根据验证结果执行后续业务逻辑。

在本申请的一个实施例中，在图7所示的实施例的基础上，如图8所示，上述身份验证平台还可以包括：

第二更新模块190用于当监控到待访问业务的验证类型更新时，根据更新后的验证类型对预存的业务标识和验证类型的对应关系进行更新。

其中，需要说明的是，前述对身份验证方法实施例的解释说明也适用于该实施例的身份验证平台，其实现原理类似，此处不再赘述。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本申请的实施例，本领域的普通技术人员可以理解：在不脱离本申请的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本申请的范围由权利要求及其等同限定。