一种支付方法及装置、电子设备和存储介质与流程

本申请涉及计算机技术，具体涉及一种支付方法及装置、电子设备和存储介质。

背景技术：

在因公支付场景中，主要包括企业预支和员工垫支。其中，企业预支是指企业先预支员工一定的资金用于员工诸如员工出差、商务宴请、采购等因公事宜。在员工消费后可以凭发票冲抵预支账单。员工垫支主要指，员工先用自身资金进行垫付，再凭票向企业申请报销。企业经过审批后再将支付给员工。

可见，不论是企业预支或是员工垫支，因公支付流程均较为繁琐，增加了员工与企业财务人员的负担。

技术实现要素：

有鉴于此，本申请至少公开一种支付方法，应用于服务端；上述方法包括：

接收支付请求；其中，上述支付请求包括需进行支付操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户；

响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述企业账户对应的支付代扣条件；如果所述支付请求满足所述支付代扣条件，

从上述企业账户完成与上述支付请求对应的支付操作。

在示出的一些实施例中，上述企业账户与上述员工账户的绑定方法包括：

接收上述企业账户对应的企业用户通过企业客户端发起的绑定请求；其中，上述绑定请求包括上述员工账户，与上述员工账户绑定的企业账户，以及，由上述企业账户对应的企业用户为上述员工账户对应的员工设置的支付代扣条件；

响应于上述绑定请求，向上述员工客户端发起绑定确认请求，并在接收到上述员工客户端发出的针对上述绑定确认请求的确认响应后，将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

本申请还提出一种支付方法，应用于员工客户端；上述方法包括：

响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在所述支付请求满足所述支付代扣条件时，从上述企业账户完成与上述支付请求对应的支付操作；其中，上述企业账户包括与上述员工账户绑定的用于进行支付代扣的企业账户。

本申请还提出一种支付装置，应用于服务端；上述装置包括：

接收模块，接收支付请求；其中，上述支付请求包括需进行付款操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户；

验证与支付模块，响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述企业账户对应的支付代扣条件；如果所述支付请求满足所述支付代扣条件，

从上述企业账户完成与上述支付请求对应的支付操作。

在示出的一些实施例中，上述装置还包括：

绑定模块，接收上述企业账户通过企业客户端发起的绑定请求；其中，上述绑定请求的部分信息用于指示上述员工账户与上述支付代扣条件；

响应于上述绑定请求，向上述员工客户端发起绑定确认请求，并在接收到上述员工客户端发出的针对上述绑定确认请求的确认响应后，存储上述支付代扣条件，上述企业账户与上述员工账户的对应关系，以及上述支付代扣条件的与上述员工账户的对应关系。

本申请还提出一种支付装置，应用于员工客户端；上述装置包括：

发送模块，响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在所述支付请求满足所述支付代扣条件时，从所述企业账户完成与所述支付请求对应的支付操作；其中，上述企业账户包括与上述员工账户绑定的用于进行支付代扣的企业账户。

本申请还提出一种电子设备，包括：

处理器；

用于存储上述处理器可执行指令的存储器；

其中，上述处理器被配置为调用上述存储器中存储的可执行指令，实现：

接收支付请求；其中，上述支付请求包括需进行支付操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户；

响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述企业账户对应的支付代扣条件；如果所述支付请求满足所述支付代扣条件，从上述企业账户完成与上述支付请求对应的支付操作。

本申请还提出一种电子设备，包括：

处理器；

用于存储上述处理器可执行指令的存储器；

其中，上述处理器被配置为调用上述存储器中存储的可执行指令，实现：

响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在所述支付请求满足所述支付代扣条件时，从所述企业账户完成与所述支付请求对应的支付操作；其中，上述企业账户包括与上述员工账户绑定的用于进行支付代扣的企业账户。

本申请还提出一种计算机可读存储介质，上述存储介质存储有计算机程序，上述计算机程序用于执行：

接收支付请求；其中，上述支付请求包括需进行支付操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户；

响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述企业账户对应的支付代扣条件；如果所述支付请求满足所述支付代扣条件，从上述企业账户完成与上述支付请求对应的支付操作。

本申请还提出一种计算机可读存储介质，上述存储介质存储有计算机程序，上述计算机程序用于执行：

响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在所述支付请求满足所述支付代扣条件时，从所述企业账户完成与所述支付请求对应的支付操作；其中，上述企业账户包括与上述员工账户绑定的用于进行支付代扣的企业账户。

在上述技术方案中，一方面，在服务端中通过确定员工账户发起的支付请求是否满足设置的支付代扣条件，并在该请求满足该支付代扣条件时由企业代替员工进行付款，从而在企业与员工之间建立资金信任机制，以使在员工发起支付请求后由该员工绑定的企业代替完成支付，简化了因公支付流程，减少了员工与企业财务人员的负担，提升了因公支付效率。

另一方面，在员工客户端中通过提出一种应用于员工客户端的支付方法，以使员工在发生消费行为后，可以通过与员工客户端进行交互实现企业代付，简化因公支付流程，提升支付效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

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

图1为本申请示出的一种支付方法的方法流程图；

图2为本申请示出的一种绑定方法的方法流程图；

图3为本申请示出的一种支付场景示意图；

图4为本申请示出的一种绑定方法流程示意图；

图5为本申请示出的一种支付流程示意图；

图6为本申请示出的一种支付装置结构示意图；

图7为本申请示出的一种电子设备的硬件结构示意图。

具体实施方式

下面将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的设备和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“上述”和“该”也旨在可以包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。还应当理解，本文中所使用的词语“如果”，取决于语境，可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本申请的第一方面提出一种支付方法。该方法可以应用于服务端。其中，上述服务端可以是指，为对应客户端提供服务的本地服务端、远程服务端或云服务端。上述服务端可以基于若干服务器或云服务器构成。在此不对服务器或云服务器的具体类型作限定。

例如，在因公支付场景中，上述客户端可以包括员工客户端，收款方客户端以及企业客户端。上述服务端可以是为上述各客户端提供诸如支付、企业与员工绑定数据存储等服务的后台服务端。

上述员工客户端，收款方客户端以及企业客户端可以是具有支付收款功能的客户端。当客户端登录不同对象账户后，则变成针对不同人群的客户端。

该方法根据企业为员工设置的支付代扣条件，对需进行支付操作的员工账户发起的支付请求进行验证，并在验证通过后从所述企业账户完成与所述支付请求对应的支付操作。

可见，该方法通过确定员工账户发起的支付请求是否满足设置的支付代扣条件，并在该请求满足该支付代扣条件时由企业代替员工进行付款，从而在企业与员工之间建立资金信任机制，以使在员工发起支付请求后由该员工绑定的企业代替完成支付，简化了因公支付流程，减少了员工与企业财务人员的负担，提升了因公支付效率。

例如，在企业预支场景中，企业需要先为员工提前准备一笔资金用于为员工支付因公费用。在员工消费后可以凭发票冲抵预支账单。

可是，在实际情形中，员工在拿到资金后如何使用对于企业来讲是很难控制的。因此，对于企业监管人员(例如财务人员)来讲需要消耗巨大的精力控制员工的消费。

而相比与企业预支场景，本申请需要在确定员工账户发起的支付请求是否满足设置的支付代扣条件，并在该请求满足该支付代扣条件时由企业代替员工进行付款，因此可以由企业设置支付代扣条件来控制员工消费，从而在企业与员工之间建立资金信任机制，以使在员工发起支付请求后由该员工绑定的企业代替完成支付，简化了因公支付流程，减少了员工与企业财务人员的负担，提升了因公支付效率。

请参见图1，图1为本申请示出的一种支付方法的方法流程图。

如图1所示，上述支付方法可以包括：

s102，接收支付请求；其中，上述支付请求包括需进行支付操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户。

上述员工账户，具体为与员工一一对应的账户。在一些例子中，员工可以通过客户端申请与自身一一对应的账户。在申请账户之后，员工可以通过与自身对应的员工账户进行付款操作。

上述企业账户，具体为与企业一一对应的账户。在一些例子中，企业可以通过客户端申请与自身一一对应的账户。在申请账户之后，企业可以通过该企业账户发起与员工的绑定操作以及设置支付代扣条件等操作。企业还可以通过该企业账户代替与该企业绑定的员工完成因公支付。其中，上述企业账户的账户类型可以是银行账户(借记账户或贷记账户)，第三方支付公司开设的账户或透支账户，在本申请中不作限定。

上述支付请求，具体为员工进行因公消费而产生的支付需求。在一些例子中，上述支付请求包括上述员工客户端发起的付款支付请求，或收款方账户对应的收款方客户端发起的收款支付请求。在一些例子中，上述支付请求通常会包括支付的发生时刻，支付流向(即付款方账户与收款方账户)，以及流转资金量等信息。

例如，当员工因公出差需要在酒店住宿时，员工可以通过员工客户端具有的扫码功能，扫描目标酒店提供的收款码。在完成扫码后，上述员工客户端内将形成该员工与该目标酒店之间的一笔消费订单。在形成上述消费订单后，上述员工客户端可以基于该消费订单向上述服务端发起支付请求以完成后续支付。其中，上述扫描功能可以是员工客户端中的小程序提供的或上述员工客户端自带的功能在本申请中不进行限定。

再例如，当员工因公出差需要在酒店住宿时，员工可以通过员工客户端提供付款码，由上述目标酒店的收款方客户端进行扫码操作。完成扫码操作后，上述收款方客户端上将形成对该员工与该目标酒店之间的一笔消费订单。在形成上述消费订单后，上述收款方客户端可以基于该消费订单向上述服务端发起收款请求以完成后续支付。

在接收到支付请求后，可以继续执行s104，响应于所述支付请求，针对所述支付请求进行支付验证，以确定所述支付请求是否满足与所述企业账户对应的支付代扣条件；如果上述支付请求满足上述支付代扣条件，从所述企业账户完成与所述支付请求对应的支付操作。

上述支付代扣条件，可以包括与上述员工账户绑定的企业账户对应的企业用户为该员工账户对应的员工创建的支付代扣条件。需要说明的是，本申请不对支付代扣条件的存储方法进行特别限定。

在一些例子中，员工在因公出差时需要获得企业批准。此时，企业可以通过企业对应的企业客户端完成该企业与该员工的绑定操作(具体绑定流程在后续实施例中说明，在此不作详述)。在绑定过程中，企业可以通过企业账户为该员工设置若干支付代扣条件，使得员工在触发的因公付满足这些支付代扣条件的情形下，由上述企业账户代替员工账户完成因公支付。

在获取上述支付代扣条件时，可以基于预先维护的支付代扣条件与企业账户的对应关系，确定与上述员工账户绑定的企业账户对应的支付代扣条件。其中，上述对应关系可以是在进行企业与员工绑定操作时维护的(具体维护过程在后续实施例中说明，在此不作详述)。

在获取上述支付代扣条件后，上述服务端可以根据上述支付代扣条件对该支付请求进行验证。

在本步骤中，可以确定上述支付请求是否满足获取的支付代扣条件。如果上述支付请求满足获取的支付代扣条件，则可以认为通过验证。反之，则可以认为验证不通过。可以理解的是，不同的支付代扣条件对应不同的验证方式。其中，验证方式的具体说明在后续实施例中进行说明，在此不作详述。

若上述验证通过，则可以从所述企业账户完成与所述支付请求对应的支付操作。

在一些例子中，上述企业账户可以包括为不同员工分配的员工子账户。上述员工子账户可以包括企业为员工分配的可用资金或可用额度。

此时，可以通过企业账户包括的若干员工子账户中与该员工对应的员工子账户完成上述支付操作。

通过这种方式，可以方便统计各员工的消费记录，便于企业做审计。

在上述提出的支付方法中，通过确定员工账户发起的支付请求是否满足设置的支付代扣条件，并在该请求满足该支付代扣条件时由企业代替员工进行付款，从而在企业与员工之间建立资金信任机制，以使在员工发起支付请求后由该员工绑定的企业代替完成支付，简化了因公支付流程，减少了员工与企业财务人员的负担，提升了因公支付效率。

在一些例子中，员工在发起上述支付请求前，可以通过对应的小程序选择通过绑定企业进行代付的选项。然后，基于上述小程序提供的二维码或扫码功能发起上述支付请求。

例如，员工对应的员工客户端可以包括与企业代付对应的小程序。员工可以通过该小程序选择进行代付的企业，并通过小程序体用的扫码功能扫描商家提供的二维码，以此来发起上述支付请求。上述服务端在接收到上述支付请求后，可以执行上述s104的步骤完成企业代付。

在一些例子中，为了便于员工灵活选择支付方式，可以在通过支付验证后，向员工输出与上述企业账户对应的代扣选项，以由员工灵活选择是否由企业代付。

在一些例子中，在确定所述支付请求满足与所述企业账户对应的支付代扣条件之后，向所述员工账户对应的员工客户端发送指示消息以触发所述员工客户端输出与所述企业账户对应的代扣选项。然后，接收所述员工客户端响应于员工针对所述代扣选项的触发操作发送的支付确认指令。最后，响应于所述支付确认指令，从所述企业账户完成与所述支付请求对应的支付操作。

在一些例子中，上述指示消息可以包括服务端验证通过的验证结果。其中，上述验证结果中包括验证通过的支付代扣条款对应的企业账户标识。此时，上述员工客户端在接收到上述指示消息后，可以输出上述企业账户标识指示的企业账户对应的代扣选项。

在一些例子中，上述指示消息可以包括服务端在验证通过后向员工客户端发送的预设信号。其中，上述预设信号可以表征不同的企业账户。此时，上述员工客户端在接收到上述预设信息后，可以输出与上述预设信号表征的企业账户对应的代扣选项。

上述代扣选项，具体是预先设置的与上述企业账户对应的企业代扣选项。员工选择该代扣选项后，可由该代扣选项指示的企业代替该员工完成支付。需要说明的是，在展示上述代扣选项时，可以展示诸如企业代付、因公付等名称。本申请不对展示代扣选项的方法做特别限定。

在一些例子中，为了提升兼容性，便于用户做出选择提升用户体验，上述代扣选项可以展示于支付确认界面中。

在实际应用中，当服务端对支付请求验证通过后，可以向上述员工账户对应的员工客户端发送指示消息，以触发上述员工客户端跳转至支付确认界面，并在支付确认界面中输出与上述企业账户对应的代扣选项。

上述支付确认指令，具体可以是由员工客户端在接收到员工针对上述代扣选项的触发操作而构建的。

在实际应用中，员工可以在上述代扣选项对应的区域执行诸如点击或触碰等操作，以触发上述员工客户端构建支付确认指令，并发送至上述服务端。

例如，员工识别到员工客户端输出的代扣选项后，可以针对该代扣选项进行诸如点击的选择操作。上述员工客户端在接收到上述选择操作信号后，可以构建上述支付确认指令，并发送至上述服务端。需要说明的是，本申请不对上述支付确认指令的具体结构进行限定。可以理解的是，员工在选择代扣选项时，可能还会执行安全验证(例如，人脸识别，指纹识别，密码验证)操作，在此不作详述。

上述服务端在接收到上述支付确认指令后，可以响应于所述支付确认指令，从所述企业账户完成与所述支付请求对应的支付操作。

在一些例子中，为了便于用户或企业进行账单查询或账单核销，上述支付方法还包括，完成支付后，生成与该次支付操作对应的支付账单。然后，将上述支付账单同步至上述员工账户和/或上述企业账户，以进行账单查询或账单核销。

在此步骤中，当完成支付后，上述服务端可以根据上述支付请求指示的支付用途，资金付款方，资金收款方，付款时刻等信息，生成指示支付过程的账单。在生成该账单后，可以将该账单存储至客户端本地或远程服务端以使付款员工或绑定企业通过自身账户查询该笔账单。

在一些例子中，在生成账单后，还会为该账单设置用于指示该账单是否被核销的标识。

当账单在刚生成时，可以将账单的标识状态设置为未核销状态。当付款员工获取消费凭证(例如发票或收据)后，该付款员工或绑定企业的财务人员可以基于该消费凭证对该账单发起核销操作。在针对该账单完成上述核销操作后，可以将上述账单的标识状态置为已核销状态。

在本实施例中，通过若上述验证的验证结果为通过，根据上述支付请求，生成用于指示支付过程的账单，以通过上述企业账户和/或上述员工账户进行账单查询或账单核销为员工和企业提供了一种账单核销机制，从而便于员工或企业财务人员进行账单核销。

在一些例子中，为了便于员工与企业用户查询账单，可以将上述支付账单同步至与上述员工账户和/或上述企业账户关联的小程序。

上述小程序可以是为员工或企业开发的承载于客户端的小程序。

在一些例子中，在执行上述支付方法之前，在上述服务端中需要先对上述企业与上述员工进行绑定。在完成绑定之后，才可由于员工绑定企业完成代付。

请参见图2，图2为本申请示出的一种绑定方法的方法流程图。

如图2所示，上述绑定方法可以包括：

s202，接收上述企业账户对应的企业用户通过企业客户端发起的绑定请求；其中，上述绑定请求包括上述员工账户，与上述员工账户绑定的企业账户；以及，由上述企业账户对应的企业用户为上述员工账户对应的员工设置的支付代扣条件。

上述绑定请求，具体为上述企业客户端基于企业的绑定操作，向上述服务端发起的请求。上述绑定请求的部分信息用于指示上述员工账户，与上述员工账户绑定的企业账户，以及，由上述企业账户对应的企业用户为上述员工账户对应的员工设置的支付代扣条件。

在一些例子中，企业需要与目标员工进行绑定操作时，可以通过在自身对应的企业客户端中的登录自身企业账户。在登录企业账户后，可以在企业账户中输入待绑定员工的员工账户信息以及为该员工设置的支付代扣条件以进行相关绑定操作。上述企业客户端在接收到上述绑定操作后，可以基于该绑定操作操作生成绑定请求，并将该绑定请求发送至上述服务端。

上述服务端在接收到上述绑定请求后，可以将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

由此即可在上述服务端中完成上述员工账户与上述企业账户的绑定。

在一些例子中，为了便于员工对绑定信息的确认，上述服务端在接收到上述绑定请求后，可以执行s204，响应于上述绑定请求，向上述员工客户端发起绑定确认请求，并在接收到上述员工客户端发出的针对上述绑定确认请求的确认响应后，将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

上述绑定确认请求，具体为由上述服务端向待绑定员工对应的业务客户端发送的，用于确认上述待绑定员工是否愿意与上述企业进行绑定的请求。例如，上述绑定确认请求可以以选项的方式通过业务客户端展示。上述待绑定员工在接收到绑定确认请求后，可以与业务客户端进行交互选择确认或否认。上述服务端在接收到确认响应后可以将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

至此则完成了上述企业账户与上述员工账户的绑定。在完成绑定之后，当上述员工发起支付请求时，可以基于存储的支付代扣条件的与企业账户的对应关系，获取与该员工账户对应的支付代扣条件，并执行后续验证支付操作。

在一些例子中，上述企业可以为上述员工设置灵活的支付代扣条件从而适应不同的业务需求。

在一些例子中，上述业务需求可以包括要求员工只有在规定的有效期和受信额度范围内进行因公付申请，才可完成企业代付。此时，上述支付代扣条件可以包括企业为员工设置的第一支付额度以及上述第一支付额度的有效期。

在进行绑定操作时，上述企业可以通过自身企业账户为上述员工设置上述支付代扣条件。

此时，在根据上述支付代扣条件对该支付请求进行验证时，上述服务端可以确定上述支付请求的发生时刻是否处于上述支付代扣条件中设置的上述第一支付额度的有效期内。

若上述发生时刻处于上述有效期内，则进一步确定上述支付请求指示的待转资金量是否达到上述支付代扣条件中设置的第一支付额度。

若上述待转资金量未达到上述第一支付额度，则确定验证结果为通过。

在本实施例中，由于上述企业可以通过上述支付代扣条件对上述支付请求进行验证，并在上述支付请求的发生时刻处于上述有效期内，以及上述支付请求的待转资金量处于上述第一支付额度内时确定验证结果为通过，因此，通过为员工设置上述支付代扣条件可以满足上述业务需求。

例如，上述第一支付额度为500，上述有效期为自支付规则设置后的10日内。在本实施例中，只有该员工的消费金额处于500内并且该员工的消费日期处于上述有效期内才被允许申请因公付。

在一些例子中，上述业务需求可以包括要求员工只有在规定的支付代扣场景下进行因公付申请，才可完成企业代付。此时，上述支付代扣条件可以包括企业为员工设置的支付代扣场景。其中，上述支付代扣场景可以表征员工支付用途。例如，上述支付代扣场景可以表征员工此次支付用途为住宿。

在进行绑定操作时，上述企业可以通过自身企业账户为上述员工设置上述支付代扣条件。

此时，在根据上述支付代扣条件对该支付请求进行验证时，上述服务端可以确定上述支付请求对应的支付场景，是否与上述支付代扣场景匹配。

若上述支付请求对应的支付场景与上述支付代扣场景匹配，则确定验证结果为通过。

在本实施例中，由于上述企业可以通过包括上述支付代扣条件对上述支付请求进行验证，并在上述支付请求指示的支付场景与上述支付代扣场景与匹配时，确定验证结果为通过，因此，通过为员工设置上述支付代扣条件可以满足上述业务需求。

例如，上述支付代扣场景为住宿。在本实施例中，只有员工发起用于支付住宿费用的因公付请求时才被允许由绑定企业进行代付。

在一些例子中，上述业务需求可以包括要求员工只有在向约定的指定收款方发起支付请求时，才可以完成企业代付。此时，上述支付代扣条件可以包括上述企业为上述员工设置的指定收款方。

在进行绑定操作时，上述企业可以通过自身企业账户为上述员工设置上述支付代扣条件。

此时，在根据上述支付代扣条件对该支付请求进行验证时，上述服务端可以确定上述支付请求指示的收款方，是否与上述指定收款方匹配。

若上述收款方与上述指定收款方匹配，则确定验证结果为通过。

在本实施例中，由于上述企业可以通过包括上述支付代扣条件对上述支付请求进行验证，并在上述支付请求指示的收款方与上述指定收款方匹配时，确定验证结果为通过，因此，通过为员工设置上述支付代扣条件可以满足上述业务需求。

例如，上述指定收款方为企业a的账户。在本实施例中，只有员工发起用于支付与上述企业a发生的支付订单时才被允许使用因公付。

在一些例子中，上述业务需求可以包括要求员工在指定支付代扣场景下或与指定收款方发生消费行为时，需要在规定的有效期以及与上述预设收款方对应的受信额度内进行因公付申请，才可完成企业代付。此时，上述支付代扣条件可以包括通过上述企业为上述员工设置的与支付代扣场景或者指定收款方对应的第二支付代扣额度以及上述第二支付代扣额度的有效期。

在进行绑定操作时，上述企业可以通过自身企业账户为上述员工设置上述支付代扣条件。

此时，在根据上述支付代扣条件对该支付请求进行验证时，如果上述支付请求对应的支付场景与上述支付代扣场景匹配，进一步确定上述支付请求的发生时刻是否处于与上述支付代扣场景对应的第二支付代扣额度的有效期内；若上述发生时刻处于上述有效期内，则进一步确定上述支付请求对应的支付金额是否达到与上述支付代扣场景对应的上述第二支付代扣额度；若是，则确定上述支付验证通过；或者，

如果上述支付请求对应的收款方与上述指定收款方匹配，进一步确定上述支付请求的发生时刻是否处于与上述指定收款方对应的第二支付代扣额度的有效期内；若上述发生时刻处于上述有效期内，则进一步确定上述支付请求对应的支付金额是否达到与上述指定收款方对应的上述第二支付代扣额度；若是，则确定上述支付验证通过。

在本实施例中，由于上述企业可以通过包括上述支付代扣条件对上述支付请求进行验证，并在上述支付请求对应的支付场景与上述支付代扣场景匹配或对应的收款方与上述指定收款方匹配，上述支付请求指示的发生时刻处于上述有效期内，以及上述支付请求指示的待转资金量处于上述第二支付额度内时确定验证结果为通过。因此，通过为员工设置上述支付代扣条件可以满足上述业务需求。

例如，上述指定收款方为企业b。上述第二额度为300，上述有效期为自支付规则设置后的10日内。在本实施例中，当员工与上述企业b发生消费行为时，只有该员工的消费金额处于300内并且该员工的消费日期处于上述有效期内才被允许申请因公付。

在一些例子中，如果上述支付请求对应的支付场景与上述支付代扣场景匹配，确定上述企业账户包括的子账户中，与上述支付代扣条件包括的上述支付场景对应的目标子账户；

从上述目标子账户完成与上述支付请求对应的支付操作；

或，

如果上述支付请求对应的收款方与上述指定收款方匹配，确定上述企业账户包括的子账户中，与上述收款方对应的目标子账户；

从上述目标子账户完成与上述支付请求对应的支付操作。

在本实施例中，由于当上述员工需要在指定支付代扣场景或上述指定收款方发生资金支付时，可以由与指定支付代扣场景或指定收款方对应的子账户完成支付，因此可以实现企业的专款专用。

需要说明的是，上述支付代扣条件可以根据实际业务需求进行灵活组合设置，除了本申请列出的几种支付代扣条件外，其他可被想到的支付代扣条件也属于本申请保护的范围。

在一些例子中，企业只愿意为员工支付一定额度的因公费用，多余的费用需要员工自行承担。此时，上述支付代扣条件可以包括企业在预设时间段可以为员工支付的资金额度。

其中，上述预设时间段可以由企业自行设置。例如，上述预设时间段可以为每天0点至23点59分。

上述资金额度，可以指示企业在指定支付场景下可以为员工支付的额度。例如，上述资金额度为15元，上述在指定支付场景为餐费。此时，上述支付代扣条件可以解读为企业每天可以为与员工支付15元的餐费。

在进行绑定操作时，上述企业可以通过自身企业账户为上述员工设置上述支付代扣条件。

此时，在根据上述支付代扣条件对该支付请求进行验证时，上述服务端可以确定上述支付请求指示的支付用途，是否与上述支付代扣条件中设置的指定支付场景匹配。

若上述支付用途与上述指定支付场景匹配，则查询与上述指定支付场景对应的资金额度，并将上述资金额度作为验证结果返回至员工客户端，以提醒员工此次因公付中，企业可以承担的资金额度。其他剩余额度可以由员工选择其他支付方式。上述其他支付方式可以是由另外一家企业进行代付或由员工自行支付，在此不做特别限定。

例如，企业a为员工b设置的支付代扣条件为企业a每日允许为员工b支付15元的餐费。假设员工发起的支付请求指示的用途为餐费，资金额为20元。此时，上述企业a只能为与员工b代付15元，剩余的5元需由员工选择其他支付方式。

在一些例子中，上述员工账户可以与多个企业账户绑定。此时为了支持员工可以自行选择目标企业账户进行企业代付，上述服务端在向上述员工账户对应的员工客户端发送指示消息以触发上述员工客户端输出与上述企业账户对应的代扣选项时，可以向上述员工账户对应的员工客户端返回验证通过结果以触发上述员工客户端输出与上述多个企业账户分别对应的代扣选项。

在此步骤中，上述服务端基于验证通过的支付代扣条件对应的企业账户构建指示消息，并将构建完毕的指示消息返回上述员工客户端。其中，上述指示消息指示验证通过的支付代扣条件对应的企业账户标识。上述员工客户端在接收服务端发送的指示消息后，可以解析上述指示消息，并基于解析出的多个企业账户标识，分别输出与上述多个企业账户标识指示的企业账户分别对应的代扣选项。

员工可以在员工客户端上针对需要进行代付的目标企业账户对应的代扣选项进行选择操作。上述员工客户端可以响应于该选择操作，生成支付确认指令，并将该指令发送至上述服务端。

上述服务端在接收到上述支付确认指令后，可以响应于上述支付确认指令，确定与上述目标代扣选项对应的目标企业账户。

在确定上述目标业账户之后，可以从上述目标企业账户完成与上述支付请求对应的支付操作。

以下结合具体支付场景进行实施例说明。

请参见图3，图3为本申请示出的一种支付场景示意图。

如图3所示，空心箭头表示员工c需要进行因公消费，因此需要向服务提供者商家e进行支付。实心箭头表示员工c的实际支付流程。即员工c是通过与自身绑定的企业d对应的企业账户完成企业代付。

在图3示出的支付场景中可以分为两个步骤：第一，需要将企业d与员工c进行绑定；第二，由员工c发起支付请求以完成企业代付。

以下分开两部分对上述两个步骤进行分别说明。

第一，请参见图4，图4为本申请示出的一种绑定方法流程示意图。

如图4所示，企业d需要与员工c进行绑定。企业d可以通过与自身对应企业客户端进行绑定操作。其中，在编辑绑定信息时，可以将待绑定员工的账户信息设置为，以及将支付代扣条件设置为，上述员工c在设置支付代扣条件之日起10日内，可以进行餐补、住宿、交通、商务宴请用途的企业代付；其中，住宿只能选择商家e。上述支付代扣条件还包括该员工在上述10日内具有2000消费额度。

上述企业客户端在接收到上述企业d的绑定操作后，可以执行s402，构建企业d与员工c的绑定请求，并将该绑定请求发送至服务端。

上述服务端在接收到上述绑定请求后，可以执行s404，向员工c对应的员工客户端发送绑定确认请求。

上述员工客户端在接收到上述绑定确认请求后可以向员工c展示。

员工c可以在接收到上述绑定确认请求后，在上述员工客户端上进行确认操作。

上述员工客户端在接收到员工c的确认操作后，可以执行s406，构建确认响应，并将上述确认响应返回至上述服务端。

上述服务端在接收到上述确认响应后，可以将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

在上述绑定操作完成后，上述服务端可以执行s408，向上述企业客户端和/或员工客户端返回绑定完成的信息以通知上述企业d已经与上述员工c完成绑定。

至此则完了企业d与员工c的绑定工作。

第二，请参见图5，图5为本申请示出的一种支付流程示意图。

当员工c需要在商家e住宿时，可以通过搭载员工客户端的终端设备扫描商家e对应的收款码，从而获取商家e提供的支付订单。假设支付金额为200。

如图5所示，上述员工客户端在获取上述支付订单后可以执行s502，生成支付请求并将上述支付请求发送至服务端。

上述服务端在接收到上述支付请求后，可以执行s504，在本地或从远程服务端中，获取在绑定操作时存储的与员工c账户绑定的企业账户对应的支付代扣条件。在获取上述支付代扣条件后可以根据上述支付代扣条件，对上述支付请求进行验证。

在本实施中，由于与员工c账户绑定的支付代扣条件包括，上述员工c在设置支付代扣条件之日起10日内，可以进行餐补、住宿、交通、商务宴请用途的企业代付；其中，住宿只能选择商家e。上述支付代扣条件还包括该员工在上述10日内具有2000消费额度。因此在基于获取的支付代扣条件对上述支付请求进行验证时，上述支付请求携带的各项支付信息均满足支付代扣条件，所以该条支付请求满足该支付代扣条件。

在完成支付请求验证后，上述服务端一方面可以执行s506，获取设置该支付代扣条件的企业d账户，并将该账户打包至指示消息中发送至上述员工客户端。另一方面，可以根据支付请求生成账单，并将该账单存储起来以供员工或企业进行查询或核销。

上述员工客户端在接收到上述验证结果信息后可以执行s508，响应与上述指示消息，确定上述验证结果中包括的企业账户信息。

在本例中，上述员工客户端将获取企业d的账户信息。

上述员工客户端在获取企业d账户信息后，可以基于该d账户信息生成与企业d对应的代扣选项，并通过终端显示屏向员工c显示。

上述员工c可以在上述员工客户端上进行选择操作，选择确定通过上述企业d对应的代扣选项进行企业代付。需要说明的是，上述选择操作中还可以包括员工c输入密码等安全验证操作，在此不作限定。

上述员工客户端在接收到上述选择操作后，可以执行s510，构建支付确认指令并将上述支付确认指令发送至上述服务端。需要说明的是，上述支付确认指令中还可以包括用于保证安全支付的安全性验证信息等信息，在此不做限定。

上述服务端在接收到上述支付确认指令后，可以执行s512，确定上述支付确认指令指示的企业账户信息，并由确定的企业账户代替员工完成订单支付。

在本例中，由于企业账户为企业d账户，因此既可以通过企业d的账户代替员工c完成订单支付。

在一些例子中，在执行s512时，上述服务端可以向上述企业账户发送订单代付确认请求。上述企业账户在接收到上述订单代付请求后可以向企业做出相关展示，以使企业做出是否代付的选择。如果上述企业选择确认代付，则可以由上述企业代替员工完成订单代付；否则终止代付流程并通知员工企业代付失败。

至此则完成企业代付。

在本申请中，一方面，该方法通过确定员工账户发起的支付请求是否满足设置的支付代扣条件，并在该请求满足该支付代扣条件时由企业代替员工进行付款，从而在企业与员工之间建立资金信任机制，以使在员工发起支付请求后由该员工绑定的企业代替完成支付，简化了因公支付流程，减少了员工与企业财务人员的负担，提升了因公支付效率。

另一方面，通过提供了一种企业为员工设置支付代扣条件的机制，以使上述企业可以为上述员工设置灵活的支付代扣条件从而适应不同的业务需求。

比如，在员工福利场景中，企业为员工在商家f处购买了300的消费券。此时该企业可以为其员工设置额度为300，指定收款方为商家f的支付规则，以使员工可以在商家f享受300的额度。

在本申请的第二方面提出一种支付方法。该方法应用于员工客户端。

上述支付方法可以包括：

响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在所述支付请求满足所述支付代扣条件时，从上述企业账户完成与上述支付请求对应的支付操作；其中，上述企业账户包括与上述员工账户绑定的用于进行支付代扣的企业账户。

可以理解的是，针对该支付方法的理解可以参照前述任一实施例，在此不作详述。

在该方法中，通过提出一种应用于员工客户端的支付方法，以使员工在发生消费行为后，可以通过与员工客户端进行交互实现企业代付，简化因公支付流程，提升支付效率。

在一些例子中，为了提升便于员工灵活做出选择，在所述支付请求满足所述支付代扣条件时，上述服务端可以向上述员工客户端发送指示消息。之后，上述员工服务端可以接收上述服务端在确定上述支付请求满足与上述企业账户对应的支付代扣条件时发送的指示消息。

然后，响应于上述指示消息，输出与上述企业账户对应的代扣选项，并响应于员工针对上述代扣选项的触发操作向上述服务端发起支付确认指令，以使上述服务端响应于上述支付确认指令，从上述企业账户完成与上述支付请求对应的支付操作。

通过上述方案可以在支付验证通过后，向员工提供上述代扣选项，以使员工灵活地选择是否进行企业代付。

在一些例子中，为了提升便于展示代扣选项，方便用户选择，上述员工客户端响应于上述指示消息，输出与上述企业账户对应的代扣选项时，可以响应于上述指示消息，跳转至支付确认界面，并在支付确认界面中输出与上述企业账户对应的代扣选项。

在本申请的第三方面提出一种支付方法。该方法应用于企业客户端。

上述支付方法可以包括：

响应于企业通过企业账户进行的绑定操作，向服务端发起绑定请求，一方面使上述服务端执行如前述任一实施例示出的绑定方法；另一方面在上述企业账户与员工账户完成上述绑定操作后，使上述员工账户对应的员工客户端执行如前述任一实施例示出的支付方法。

可以理解的是，针对该支付方法的理解可以参照前述任一实施例，在此不作详述。

在该方法中，通过提出一种应用于企业客户端中支付方法，使企业可以通过企业客户端完成与员工的绑定，以使员工在发生消费行为后，可以通过与员工客户端进行交互实现企业代付，简化因公支付流程，提升支付效率。

与上述任一实施例相对应的，本申请还提出一种应用于服务端的支付装置。

请参见图6，图6为本申请示出的一种支付装置结构示意图。

如图6所示，上述装置600包括：

接收模块610，接收支付请求；其中，上述支付请求包括需进行付款操作的员工账户的账户标识；上述员工账户绑定了用于进行支付代扣的企业账户；

验证与支付模块620，响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述企业账户对应的支付代扣条件；如果所述支付请求满足所述支付代扣条件，

从上述企业账户完成与上述支付请求对应的支付操作。

在示出的一些实施例中，上述验证与支付模块620具体包括：

在确定所述支付请求满足与所述企业账户对应的支付代扣条件之后，向所述员工账户对应的员工客户端发送指示消息以触发所述员工客户端输出与所述企业账户对应的代扣选项；

接收所述员工客户端响应于员工针对所述代扣选项的触发操作发送的支付确认指令；

响应于所述支付确认指令，从所述企业账户完成与所述支付请求对应的支付操作。在示出的一些实施例中，上述验证与支付模块620具体包括：

向上述员工账户对应的员工客户端发送指示消息，以触发上述员工客户端跳转至支付确认界面，并在支付确认界面中输出与上述企业账户对应的代扣选项。

在示出的一些实施例中，上述支付请求包括上述员工客户端发起的付款支付请求，或收款方账户对应的收款方客户端发起的收款支付请求。

在示出的一些实施例中，上述装置600还包括：

生成模块，完成支付后，生成与该次支付操作对应的支付账单；

同步模块，将上述支付账单同步至上述员工账户和/或上述企业账户，以进行账单查询或账单核销。

在示出的一些实施例中，上述同步模块具体包括：

将上述支付账单同步至与上述员工账户和/或上述企业账户关联的小程序。

在示出的一些实施例中，上述验证与支付模块620具体包括：

响应于上述支付请求，获取与上述支付请求中包括的上述员工账户的账户标识绑定的企业账户对应的支付代扣条件；

基于上述支付代扣条件对该支付请求进行支付验证。

在示出的一些实施例中，上述支付代扣条件包括：上述企业账户对应的企业用户为上述员工账户对应的员工设置的第一支付代扣额度以及上述第一支付代扣额度的有效期；

上述验证与支付模块620，包括：

确定上述支付请求的发生时刻是否处于上述支付代扣条件中设置的上述第一支付代扣额度的有效期内；

若上述发生时刻处于上述有效期内，则进一步确定上述支付请求对应的支付金额，是否达到上述第一支付代扣额度；

若上述支付金额未达到上述第一支付代扣额度，则确定验证结果为通过。

在示出的一些实施例中，上述支付代扣条件包括上述企业账户对应的企业用户为上述员工账户对应的员工设置的支付代扣场景；

上述验证与支付模块620，包括：

确定上述支付请求对应的支付场景，是否与上述支付代扣场景匹配；

如果上述支付请求对应的支付场景与上述支付代扣场景匹配，则确定验证结果为通过。

在示出的一些实施例中，上述支付代扣条件包括上述企业账户对应的企业用户为上述员工账户对应的员工设置的指定收款方；

上述验证与支付模块620，包括：

确定上述支付请求对应的收款方，是否与上述指定收款方匹配；

如果上述支付请求对应的收款方，与上述指定收款方匹配，则确定验证结果为通过。

在示出的一些实施例中，支付代扣条件包括：上述企业账户对应的企业用户为上述员工账户对应的员工设置的与支付代扣场景或者指定收款方对应的第二支付代扣额度以及上述第二支付代扣额度的有效期；

上述验证与支付模块620，包括：

如果上述支付请求对应的支付场景与上述支付代扣场景匹配，进一步确定上述支付请求的发生时刻是否处于与上述支付代扣场景对应的第二支付代扣额度的有效期内；若上述发生时刻处于上述有效期内，则进一步确定上述支付请求对应的支付金额是否达到与上述支付代扣场景对应的上述第二支付代扣额度；若是，则确定上述支付验证通过；或者，

如果上述支付请求对应的收款方与上述指定收款方匹配，进一步确定上述支付请求的发生时刻是否处于与上述指定收款方对应的第二支付代扣额度的有效期内；若上述发生时刻处于上述有效期内，则进一步确定上述支付请求对应的支付金额是否达到与上述指定收款方对应的上述第二支付代扣额度；若是，则确定上述支付验证通过。

在示出的一些实施例中，上述验证与支付模块620，包括：

如果上述支付请求对应的支付场景与上述支付代扣场景匹配，确定上述企业账户包括的子账户中，与上述支付代扣条件包括的上述支付场景对应的目标子账户；

从上述目标子账户完成与上述支付请求对应的支付操作；

或，

如果上述支付请求对应的收款方与上述指定收款方匹配，确定上述企业账户包括的子账户中，与上述收款方对应的目标子账户；

从上述目标子账户完成与上述支付请求对应的支付操作。

在示出的一些实施例中，上述员工账户与多个企业账户绑定；上述支付确认指令为上述员工客户端响应于员工针对与上述多个企业账户分别对应的代扣选项中的目标代扣选项的触发操作发送的支付确认指令；

上述验证与支付模块620，包括：

向上述员工账户对应的员工客户端返回验证通过结果以触发上述员工客户端输出与上述多个企业账户分别对应的代扣选项；

响应于上述支付确认指令，确定与上述目标代扣选项对应的目标企业账户；

从上述目标企业账户完成与上述支付请求对应的支付操作。

在示出的一些实施例中，上述装置600还包括：

绑定模块，接收上述企业账户对应的企业用户通过企业客户端发起的绑定请求；其中，上述绑定请求包括上述员工账户，与上述员工账户绑定的企业账户，以及，由上述企业账户对应的企业用户为上述员工账户对应的员工设置的支付代扣条件；

响应于上述绑定请求，向上述员工客户端发起绑定确认请求，并在接收到上述员工客户端发出的针对上述绑定确认请求的确认响应后，将上述企业账户与上述员工账户进行绑定，并存储上述员工账户、上述企业账户与上述支付代扣条件的对应关系。

与上述任一实施例相对应的，本申请还提出一种应用于员工客户端的支付装置。

上述装置700包括：

发送模块710，响应于员工通过员工账户进行的支付操作，向服务端发起支付请求，以使上述服务端响应于上述支付请求，针对上述支付请求进行支付验证，以确定上述支付请求是否满足与上述支付请求包括的企业账户对应的支付代扣条件，并在上述支付请求满足与上述支付代扣条件时，从上述企业账户完成与上述支付请求对应的支付操作。

与上述任一实施例相对应的，本申请还提出一种应用于企业客户端的支付装置800，包括：

发送模块810，响应于企业通过企业账户进行的绑定操作，向服务端发起绑定请求，一方面使上述服务端执行如前述任一实施例示出的绑定方法；另一方面在上述企业账户与员工账户完成上述绑定操作后，使上述员工账户对应的员工客户端执行如前述任一实施例示出的支付方法。

本申请示出的支付装置的实施例可以应用于电子设备上。相应地，本申请公开了一种电子设备，该设备可以包括：处理器。

用于存储处理器可执行指令的存储器。

其中，上述处理器被配置为调用上述存储器中存储的可执行指令，实现如上述任一实施例示出的支付方法。

请参见图7，图7为本申请示出的一种电子设备的硬件结构示意图。

如图7所示，该电子设备可以包括用于执行指令的处理器，用于进行网络连接的网络接口，用于为处理器存储运行数据的内存，以及用于存储图像处理装置对应指令的非易失性存储器。

其中，支付装置的实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，除了图7所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。

可以理解的是，为了提升处理速度，支付装置对应指令也可以直接存储于内存中，在此不作限定。

本申请提出一种计算机可读存储介质，上述存储介质存储有计算机程序，上述计算机程序用于执行上述任一实施例示出的支付方法。

本领域技术人员应明白，本申请一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本申请一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(可以包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请中的“和/或”表示至少具有两者中的其中一个，例如，“a和/或b”可以包括三种方案：a、b、以及“a和b”。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于数据处理设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的行为或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请中描述的主题及功能操作的实施例可以在以下中实现：数字电子电路、有形体现的计算机软件或固件、可以包括本申请中公开的结构及其结构性等同物的计算机硬件、或者它们中的一个或多个的组合。本申请中描述的主题的实施例可以实现为一个或多个计算机程序，即编码在有形非暂时性程序载体上以被数据处理装置执行或控制数据处理装置的操作的计算机程序指令中的一个或多个模块。可替代地或附加地，程序指令可以被编码在人工生成的传播信号上，例如机器生成的电、光或电磁信号，该信号被生成以将信息编码并传输到合适的接收机装置以由数据处理装置执行。计算机存储介质可以是机器可读存储设备、机器可读存储基板、随机或串行存取存储器设备、或它们中的一个或多个的组合。

本申请中描述的处理及逻辑流程可以由执行一个或多个计算机程序的一个或多个可编程计算机执行，以通过根据输入数据进行操作并生成输出来执行相应的功能。上述处理及逻辑流程还可以由专用逻辑电路—例如fpga(现场可编程门阵列)或asic(专用集成电路)来执行，并且装置也可以实现为专用逻辑电路。

适合用于执行计算机程序的计算机可以包括，例如通用和/或专用微处理器，或任何其他类型的中央处理单元。通常，中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的基本组件可以包括用于实施或执行指令的中央处理单元以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将可以包括用于存储数据的一个或多个大容量存储设备，例如磁盘、磁光盘或光盘等，或者计算机将可操作地与此大容量存储设备耦接以从其接收数据或向其传送数据，抑或两种情况兼而有之。然而，计算机不是必须具有这样的设备。此外，计算机可以嵌入在另一设备中，例如移动电话、个人数字助理(pda)、移动音频或视频播放器、游戏操纵台、全球定位系统(gps)接收机、或例如通用串行总线(usb)闪存驱动器的便携式存储设备，仅举几例。

适合于存储计算机程序指令和数据的计算机可读介质可以包括所有形式的非易失性存储器、媒介和存储器设备，例如可以包括半导体存储器设备(例如eprom、eeprom和闪存设备)、磁盘(例如内部硬盘或可移动盘)、磁光盘以及cdrom和dvd-rom盘。处理器和存储器可由专用逻辑电路补充或并入专用逻辑电路中。

虽然本申请包含许多具体实施细节，但是这些不应被解释为限制任何公开的范围或所要求保护的范围，而是主要用于描述特定公开的具体实施例的特征。本申请内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上上述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

类似地，虽然在附图中以特定顺序描绘了操作，但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。

由此，主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下，权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外，附图中描绘的处理并非必需所示的特定顺序或顺次顺序，以实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。

以上所述仅为本申请一个或多个实施例的较佳实施例而已，并不用以限制本申请一个或多个实施例，凡在本申请一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请一个或多个实施例保护的范围之内。