支付信息确定方法、装置、系统和电子设备

技术领域

本发明主要涉及网络支付技术领域，尤其涉及一种支付信息确定方法、装置、系统和电子设备。

背景技术

自研电商系统接入支付时，需要对接多个第三方支付平台，对接重复且麻烦。而且支付成功严重依赖第三方支付平台的支付回调，如果第三方支付平台支付回调出现延迟或者失效，那么自研的电商系统很可能检测不到用户的支付行为，不能更快捷地响应用户。特别对于一些小的支付平台，技术能力保障不到位情况下，此类问题尤其严重。

现有技术中，往往是通过公共代码基础去接入第三方支付平台，但是支付状态的确保和及时维护支付状态还是需要业务系统自己去保证。另外就是利用消息队列保证支付回调的顺序性。此种方式是基于已经从第三方支付平台中获取了支付回调的消息，对于消息顺序的预处理通过消息队列保证，对于支付系统本身没有回调的情况并未提出解决方案。

目前企业内部的电商系统接入第三方支付平台(如支付宝、微信等)，在B2C(business to customer，企业对消费者)扫码支付场景下严重依赖第三方支付平台本身的回调支付。企业内部如果各个业务都单独对接第三方支付平台，则是各业务系统自己去维护支付状态。第三方支付平台本身支付回调出现延迟或短时间异常时，各业务系统需要单独去调用读取支付状态，每个业务侧都需要关心和处理维护支付状态的兜底机制，造成资源浪费。另外，基于各第三方支付平台做数据分析时，比如分析客户使用第三方支付平台支付的比例以及各个业务方收入情况等，需要各业务系统单独提供接口去支持数据分析业务，而财务侧使用的第三方支付平台管理端(如微信的商户平台或支付宝商户平台)不具备提供接口查询的能力。

可见，现阶段并没有统一的订单支付状态维护系统，且针对不同平台的支付状态也是在各业务系统内部，业务系统不能够及时地知晓订单支付状态。

发明内容

本发明要解决的技术问题是提供一种支付信息确定方法、装置、系统和电子设备，提升对接第三方支付平台的效率，确保订单支付成功后，业务系统能够及时地知晓订单支付状态。

为解决上述技术问题，第一方面，本发明提供了一种支付信息确定方法，包括：接收业务系统的订单支付状态的请求信息，根据所述请求信息生成未支付的中间订单；通过查询第三方支付平台获取所述中间订单的支付状态；当查询到所述中间订单处于支付成功的状态时，更新所述中间订单状态为已支付；将已支付的中间订单的支付状态通知所述业务系统。

可选地，所述通过查询第三方支付平台获取所述中间订单的支付状态包括：若获取的所述中间订单的支付状态为未支付，则再次查询所述第三方支付平台获取所述中间订单的支付状态。

可选地，多次查询所述第三方支付平台获取所述中间订单的支付状态过程中，查询所用总时间不超过支付二维码的有效期。

可选地，多次查询所述第三方支付平台获取所述中间订单的支付状态过程中，后一次查询的间隔时间大于前一次查询的间隔时间，其中所述间隔时间为两次查询之间的时间间隔。

可选地，所述后一次查询的间隔时间大于前一次查询的间隔时间包括：若查询次数大于3次，则第3次之后的每一次查询的间隔时间是相邻前两次查询的间隔时间之和。

可选地，所述方法还包括：接收所述第三方支付平台发送的所述中间订单支付成功的信息。

可选地，在所述将已支付的中间订单的支付状态通知所述业务系统之后，还包括：接收所述业务系统的应答信息，其中所述应答信息指示所述业务系统已知晓所述中间订单对应的订单为已支付的状态。

可选地，若已将已支付的中间订单的支付状态通知所述业务系统，且未收到所述业务系统的应答信息，则在所有所述中间订单中筛选出已支付但未接收到所述业务系统应答信息的中间订单。

可选地，将筛选出已支付但未接收到所述业务系统应答信息的中间订单通知所述业务系统。

可选地，将筛选出已支付但未接收到所述业务系统应答信息的中间订单通知所述业务系统过程中，若通知次数超过预定次数，则停止通知所述业务系统。

第二方面，本发明提供了一种支付信息确定装置，包括：生成模块，用于接收业务系统的订单支付状态的请求信息，根据所述请求信息生成未支付的中间订单；查询模块，用于通过查询第三方支付平台获取所述中间订单的支付状态；更新模块，用于当查询到所述中间订单处于支付成功的状态时，更新所述中间订单状态为已支付；通知模块，用于将已支付的中间订单的支付状态通知所述业务系统。

第三方面，本发明提供了一种支付信息确定系统，包括：接口层，所述接口层用于连接外部系统，所述外部系统包括业务系统和第三方支付平台；数据管理单元，所述数据管理单元用于管理接入所述支付信息确定系统的数据，所述数据包括业务标识和交易数据；支付转换单元，所述支付转换单元用于根据所述业务系统提供的订单支付类型调用不同的所述第三方支付平台；查询单元，所述查询单元用于查询未支付的中间订单及所述中间订单的支付状态，以及查询已支付但未收到所述业务系统应答信息的中间订单；回调单元，所述回调单元用于发送所述中间订单已支付的消息给所述业务系统，以及接收所述业务系统反馈的应答信息。

第四方面，本发明提供了一种电子设备，包括：处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的支付信息确定方法的步骤。

第五方面，本发明提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的支付信息确定方法的步骤。

与现有技术相比，本发明具有以下优点：首先接收业务系统的订单支付状态的请求信息，根据请求信息生成未支付的中间订单；再通过查询第三方支付平台获取中间订单的支付状态；当查询到中间订单处于支付成功的状态时，更新中间订单状态为已支付；最后将已支付的中间订单的支付状态通知业务系统，提升了对接第三方支付平台的效率，确保订单支付成功后，业务系统能够及时地知晓订单支付状态。

附图说明

包括附图是为提供对本申请进一步的理解，它们被收录并构成本申请的一部分，附图示出了本申请的实施例，并与本说明书一起起到解释本申请原理的作用。附图中：

图1是本发明一个实施例支付信息确定方法的流程示意图；

图2是本发明一个实施例中查询第三方支付平台中订单状态示意图；

图3是本发明一个实施例中第三方支付平台与支付中心的交互示意图；

图4是本发明一个实施例中支付中心与业务系统的交互示意图；

图5是本发明一个实施例中未收到应答信息时的查询示意图；

图6是本发明一个实施例中一笔订单完成支付的整个时序示意图；

图7是本发明一个实施例支付信息确定装置的结构示意图；

图8是本发明一个实施例支付信息确定系统的结构示意图；

图9是本发明一个实施例支付信息确定系统与其他系统的交互示意图；

图10是本发明提供的一种电子设备的结构示意图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

此外，需要说明的是，使用“第一”、“第二”等词语来限定零部件，仅仅是为了便于对相应零部件进行区别，如没有另行声明，上述词语并没有特殊含义，因此不能理解为对本申请保护范围的限制。此外，尽管本申请中所使用的术语是从公知公用的术语中选择的，但是本申请说明书中所提及的一些术语可能是申请人按他或她的判断来选择的，其详细含义在本文的描述的相关部分中说明。此外，要求不仅仅通过所使用的实际术语，而是还要通过每个术语所蕴含的意义来理解本申请。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，或将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

实施例一

图1是本发明一个实施例支付信息确定方法的流程示意图，参考图1，所示方法100可用于C扫B(即顾客扫描商户)支付应用场景中，也可用于相适应的其他支付场景中，执行本实施例确定方法的场所或部件可称为内部支付中心，简称支付中心。

方法100主要是通过主动查询或第三方支付平台回调以获取订单的支付状态，以支付中心作为订单支付状态的中间桥梁，查询并通知下游业务系统，保证业务系统能及时知晓订单支付状态，还可简化接入第三方支付平台的流程，包括：

S110、接收业务系统的订单支付状态的请求信息，根据所述请求信息生成未支付的中间订单。

在本实施例中，支付中心可以作为业务系统与第三方支付平台之间的一个桥梁。业务系统，比如商城、小程序和广告等业务属性系统，与第三方支付平台之间的交互可以通过支付中心进行。各业务系统的订单的支付状态可以统一由支付中心维护。例如，在业务系统里有一笔订单产生，用户扫描二维码支付完成后，业务系统会请求支付中心，则支付中心会接收到业务系统的订单支付状态的请求信息，进而生成一笔未支付的中间订单，且该中间订单和业务系统订单是对应的，后续支付中心再查询第三方支付平台，实现业务订单的支付状态由支付中心维护。

由于业务订单的支付状态由支付中心维护，则业务系统只会面对支付中心，直接对接支付中心即可，极大简化各业务系统对接第三方支付平台的复杂度，因为若是各业务系统单独通过查询接口查询第三方支付平台，意味着业务系统要对接多个第三方支付平台，显然更为复杂。

S120、通过查询第三方支付平台获取所述中间订单的支付状态。

在本实施例中，对于一笔未支付的订单，支付中心会针对此未支付的订单查询第三方支付平台。如前述，在业务系统完成了用户的相关业务之后，业务系统具有一个新的订单，此时业务系统发送此业务订单支付状态的请求信息给支付中心，支付中心再通过查询第三方支付平台获取中间订单的支付状态，如中间订单处于已支付的状态或处于未支付的状态，进而间接地反馈业务系统中订单的支付状态。

在一些实施方式中，通过查询第三方支付平台获取中间订单的支付状态过程中，若获取的中间订单的支付状态为未支付，则可以再次查询第三方支付平台以再次获取中间订单的支付状态。由于第三方支付平台中订单支付状态的变化具有延时性，或者相关订单未支付成功等情况存在，那么支付中心在一次查询第三方支付平台获取中间订单的支付状态时，可能会得到订单处于未支付的结果，因此，一次查询的结果可能会不符合订单支付状态的实际情况。为提高获取订单状态的准确性，可以再次或多次查询第三方平台以获取中间订单的支付状态。

在一些实施方式中，多次查询第三方支付平台获取中间订单的支付状态过程中，查询所用总时间不超过支付二维码的有效期。在二维码的有效期内一直没有查询到订单的支付状态，则可以判定订单未支付或未支付成功，再继续查询已没有实际意义。例如，在C扫B支付场景下，支付二维码的有效期一般设置为2小时，当然2小时的有效期是一个相对值，也可以设置为半小时或1小时，过了有效期，此支付二维码失效，需要重新刷新支付页面请求新的支付二维码。因此多次查询第三方支付平台获取中间订单的支付状态过程应当保持在2小时之内，在2小时内若没有查询到订单的支付状态的情况下，可以多次查询。

在一些实施方式中，多次查询第三方支付平台获取中间订单的支付状态过程中，后一次查询的间隔时间大于前一次查询的间隔时间，其中间隔时间为两次查询之间的时间间隔。此种查询方式可以控制查询次数，避免多次查询带来资源浪费。

更优地，若查询次数大于3次，则第3次之后的每一次查询的间隔时间是相邻前两次查询的间隔时间之和，即以阶梯形式查询。例如，针对一笔未支付的订单，支付中心可以启动一个协程服务通过查询接口查询相应支付平台，以阶梯形式查询，若第一次查询订单处于未支付状态，等待2秒再进行第二次查询，若第二次查询订单仍处于未支付状态，等待3秒再进行第三次查询，若第三次查询订单仍处于未支付状态，等待5秒进行第四次查询，若第四次查询订单仍处于未支付状态，等待8秒进行第五次查询，以此类推。这种查询方式的好处在于可以在尽量保证查询效果的前提下减少查询次数。以有效期为2小时的支付二维码为例，一般20次的阶梯方式查询就会覆盖到2小时，如果每2秒就查询一次，要覆盖2小时的话，极端情况下需要查询3600次，显然以阶梯形式查询更具有经济性。可以理解的是，结合支付二维码有效期情况也可以采取其他策略，假如有效期设置为3分钟，则可以是每3秒就查询一次，极端情况下共查询60次。

图2是本发明一个实施例中查询第三方支付平台中订单状态示意图，参考图2，支付中心根据业务系统的请求信息，以确定未支付的中间订单，在通过查询第三方支付平台获取中间订单的支付状态，若在第三方支付平台得知中间订单处于支付成功(或已支付)状态，则将中间订单(对应业务系统中订单)的已支付状态通知业务系统，本次查询过程结束。若在第三方支付平台得知中间订单处于未支付成功状态，则间隔一段时间后继续查询第三方支付平台，直到获取到中间订单准确的支付状态结果。在一般情况下，若查询次数超过20次，则结束本次查询过程。

在一些实施方式中，支付中心还可以接收第三方支付平台发送的中间订单支付成功的信息。图3是本发明一个实施例中第三方支付平台与支付中心的交互示意图，参考图3，可以是支付中心向第三方支付平台查询以获取一笔订单的支付状态，也可以是第三方支付平台发送的中间订单支付成功的信息，支付中心处于信息接收方。第三方支付平台发送的中间订单支付成功的信息的方式作为获取中间订单的支付状态的一种补充方式，以提高获取中间订单支付状态的准确性和及时性。

S130、当查询到所述中间订单处于支付成功的状态时，更新所述中间订单状态为已支付。

在本实施例中，支付中心一旦在第三方支付平台中查询到中间订单是支付成功的状态，就会更新支付中心里中间订单状态为已支付。支付中心对中间订单状态的维护具有两方面的作用，一是明确中间订单的支付状态，结束本次中间订单的查询过程，二是利于后续将中间订单的支付状态及时通知业务系统。

S140、将已支付的中间订单的支付状态通知所述业务系统。

在本实施例中，当在第三方支付平台查询到中间订单已支付时，支付中心更新相应的中间订单的支付状态，且通知下游的业务系统，进而针对该笔业务系统订单的查询工作结束。当下次有新的未支付订单时，则启动一个新的中间订单支付状态查询过程。

在一些实施方式中，在将已支付的中间订单的支付状态通知业务系统之后，还接收业务系统的应答信息，其中应答信息指示业务系统已知晓中间订单对应的订单为已支付的状态。

图4是本发明一个实施例中支付中心与业务系统的交互示意图，参考图4，图中以两个业务系统(业务系统1和业务系统2)为例，当然每个业务系统与支付中心之间的交互过程是相同的。支付中心与业务系统1之间的交互关系有：1)支付中心查询第三方支付平台中订单支付状态，若查询到订单支付成功，就立即通知下游业务系统。2)第三方支付平台回调中间订单的支付状态给支付中心，支付中心获知后也会立即通知下游业务系统。3)业务系统主动查询支付中心该订单的支付状态。上述三种交互方式基本上是独立运行，确保中间订单支付状态能够及时获取，最新获取到中间订单处于已支付状态就会及时更新信息。

在一些实施方式中，若已将已支付的中间订单的支付状态通知业务系统，且未收到业务系统的应答信息，则在所有中间订单中筛选出已支付但未接收到业务系统应答信息的中间订单。进一步地，可以将筛选出已支付但未接收到业务系统应答信息的中间订单通知业务系统。业务系统收到支付中心的消息后需要给正确应答，然后该订单相关流程正常结束。业务系统发送应答信息适用于如图4所示的三种获取到中间订单已支付状态的交互方式。

在一些实施方式中，将筛选出已支付但未接收到业务系统应答信息的中间订单通知业务系统过程中，若通知次数超过预定次数，则停止通知业务系统。例如，支付中心通知10次后，业务系统依然未正确应答该笔订单，则通知过程会停止。

图5是本发明一个实施例中未收到应答信息时的查询示意图，参考图5，该服务的场景是业务系统的订单已经支付，且支付中心也知晓订单的已支付状态，但业务系统还不知道该业务订单已经支付的情形。在上述情形下，该订单启动一个协程服务，查询已支付但未收到业务系统正确应答(应答信息)的订单，通知下游业务系统。具体来说，支付中心首先查询已支付但未收到正确应答的中间订单，并将上述中间订单情况通知业务系统，若之后业务系统能够正确应答，发送应答信息，则结束本次兜底机制；若支付中心通知业务系统后，业务系统仍然没有正确应答，则继续通知业务系统，直到业务系统能够正确应答。当然若通知次数超过预定次数，则停止通知业务系统，一般可以设定通知次数为10次。上述业务订单客户已经支付，支付中心已知晓已支付状态，但业务系统不知道已支付的情况，一般来说是业务侧服务出现问题，比如业务系统侧服务器出现宕机导致服务不可用，或者网络问题导致服务请求中断，或者域名解析出现问题导致网络问题等。

能够理解的是，图5中关于中间订单的查询是支付中心循环查询支付中心本地的数据，筛选出已支付但业务系统未正确应答的(中间)订单数据，业务系统未正确应答也就意味着业务系统里该订单状态是未支付，不同于图2中查询第三方支付平台。图2的查询是支付中心通过查询接口循环查询第三方支付平台，获取中间订单的支付状态。

图6是本发明一个实施例中一笔订单完成支付的整个时序示意图，参考图6，在用户购买商品后，业务系统启动了一个支付过程，并告知支付中心，支付中心再告知第三方支付平台，第三方支付平台则向用户返回一个支付二维码，而后用户扫码完成支付。为业务系统能够及时获知订单的支付状态，一种方式是第三支付平台将支付完成的状态信息回调通知给支付中心，支付中心再将支付完成的状态信息回调通知给业务系统，另一种方式是支付中心查询第三方支付平台，进而获取中间订单的支付状态，再将支付状态通知业务系统。

本实施例提供的支付信息确定方法，首先接收业务系统的订单支付状态的请求信息，根据请求信息生成未支付的中间订单；再通过查询第三方支付平台获取中间订单的支付状态；当查询到中间订单处于支付成功的状态时，更新中间订单状态为已支付；最后将已支付的中间订单的支付状态通知业务系统，提升了对接第三方支付平台的效率，确保订单支付成功后，业务系统能够及时地知晓订单支付状态。

实施例二

图7是本发明一个实施例支付信息确定装置的结构示意图，参考图7，装置700主要包括：

生成模块701，用于接收业务系统的订单支付状态的请求信息，根据所述请求信息生成未支付的中间订单。

查询模块702，用于通过查询第三方支付平台获取所述中间订单的支付状态。

在一些实施方式中，通过查询第三方支付平台获取中间订单的支付状态过程中，若获取的中间订单的支付状态为未支付，则再次查询第三方支付平台获取中间订单的支付状态。

在一些实施方式中，多次查询第三方支付平台获取中间订单的支付状态过程中，查询所用总时间不超过支付二维码的有效期。

在一些实施方式中，多次查询第三方支付平台获取中间订单的支付状态过程中，后一次查询的间隔时间大于前一次查询的间隔时间，其中间隔时间为两次查询之间的时间间隔。

在一些实施方式中，若查询次数大于3次，则第3次之后的每一次查询的间隔时间是相邻前两次查询的间隔时间之和。

在一些实施方式中，接收第三方支付平台发送的中间订单支付成功的信息。

更新模块703，用于当查询到所述中间订单处于支付成功的状态时，更新所述中间订单状态为已支付。

通知模块704，用于将已支付的中间订单的支付状态通知所述业务系统。

在一些实施方式中，在将已支付的中间订单的支付状态通知业务系统之后，接收业务系统的应答信息，其中应答信息指示业务系统已知晓中间订单对应的订单为已支付的状态。

在一些实施方式中，若已将已支付的中间订单的支付状态通知业务系统，且未收到业务系统的应答信息，则在所有中间订单中筛选出已支付但未接收到业务系统应答信息的中间订单。

在一些实施方式中，将筛选出已支付但未接收到业务系统应答信息的中间订单通知业务系统。

在一些实施方式中，将筛选出已支付但未接收到业务系统应答信息的中间订单通知业务系统过程中，若通知次数超过预定次数，则停止通知业务系统。

本实施例中各模块执行的其他操作的细节可以参考前述实施例，在此不再展开。

本实施例提供的支付信息确定装置，首先接收业务系统的订单支付状态的请求信息，根据请求信息生成未支付的中间订单；再通过查询第三方支付平台获取中间订单的支付状态；当查询到中间订单处于支付成功的状态时，更新中间订单状态为已支付；最后将已支付的中间订单的支付状态通知业务系统，提升了对接第三方支付平台的效率，确保订单支付成功后，业务系统能够及时地知晓订单支付状态。

实施例三

图8是本发明一个实施例支付信息确定系统的结构示意图，图9是本发明一个实施例支付信息确定系统与其他系统的交互示意图，参考图8和图9，所示系统800包括：接口层801、数据管理单元802、查询单元803、支付转换单元804和回调单元805，其中：

接口层801连接外部系统，外部系统包括业务系统和第三方支付平台。接口层801统一对外部业务系统开放，提供一套支付、查询的API接口供业务系统使用。

数据管理单元802管理接入支付信息确定系统的数据，数据包括业务标识和交易数据(包括业务订单及其支付交易情况)。

查询单元803查询未支付的中间订单及中间订单的支付状态，以及查询已支付但未收到业务系统应答信息的中间订单。查询单元803查询出未支付的业务订单，主动查询第三方支付平台订单的实际交易状态，一旦订单成功支付，交易数据中该业务订单支付状态置为已支付，针对本条订单的查询过程结束。在本实施例中，查询单元803可以执行实施例一所示支付信息确定方法，因此查询单元803执行的其他操作的细节可以参考实施例一，在此不再展开。

支付转换单元804根据业务系统提供的订单支付类型(哪种支付平台)调用不同的第三方支付平台。

回调单元805发送中间订单已支付的消息给业务系统，以及接收业务系统反馈的应答信息。回调单元805一般配合查询单元803，一旦交易数据中该业务订单支付状态为成功，那么就会将支付成功的消息回调(通知)给下游的业务系统，使业务系统知晓该订单状态。回调请求业务系统的接口失败后可以重试。

本实施例提供的支付信息确定系统，首先接收业务系统的订单支付状态的请求信息，根据请求信息生成未支付的中间订单；再通过查询第三方支付平台获取中间订单的支付状态；当查询到中间订单处于支付成功的状态时，更新中间订单状态为已支付；最后将已支付的中间订单的支付状态通知业务系统，提升了对接第三方支付平台的效率，确保订单支付成功后，业务系统能够及时地知晓订单支付状态。

本申请实施例中的一种支付信息确定装置可以是装置，也可以是终端中的部件、集成电路、或芯片。本申请实施例中的一种支付信息确定装置可以为具有操作系统的装置。该操作系统可以为安卓操作系统，可以为iOS操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

如图10所示，本申请实施例还提供一种电子设备1000，包括处理器1001，存储器1002，存储在存储器1002上并可在所述处理器1001上运行的程序或指令，该程序或指令被处理器1001执行时实现上述支付信息确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述支付信息确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，处理器为上述实施例中所述的电子设备中的处理器。可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

计算机可读介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等等、或合适的组合形式。计算机可读介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、射频信号、或类似介质、或任何上述介质的组合。

显然，对于本领域技术人员来说，上述发明披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

本申请的一些方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。处理器可以是一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理器件(DAPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器或者其组合。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。例如，计算机可读介质可包括，但不限于，磁性存储设备(例如，硬盘、软盘、磁带……)、光盘(例如，压缩盘CD、数字多功能盘DVD……)、智能卡以及闪存设备(例如，卡、棒、键驱动器……)。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

虽然本申请已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本申请，在没有脱离本申请精神的情况下还可作出各种等效的变化或替换，因此，只要在本申请的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。