CN111598548A - 一种基于电子签名的业务审批方法、相关装置及存储介质 - Google Patents

Abstract

本申请公开了一种基于电子签名的业务审批方法，包括：通过业务审批界面展示第一业务审批信息；若第一业务审批信息满足信息审批条件，则获取电子签名，其中，电子签名为根据划动操作轨迹生成的；若存在签名备案记录，则向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；若电子签名鉴权通过，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。本申请还提供了相关装置及存储介质。本申请不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。

Description

一种基于电子签名的业务审批方法、相关装置及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种基于电子签名的业务审批方法、相关装置及存储介质。

背景技术

近年来，电子审批在企业流程、行业应用、移动支付和个人信息安全等各种场景中得到越来越多的应用。在日常管理活动中，通常会有一些业务需要由审批者进行审批后才能执行，例如，项目分配、文件审批、休假审批以及账单审批等业务。

在传统的日常管理活动中，如果业务请求者需要业务审批者认可单据中的内容，则需要先打印出纸质的审批单，然后转交给相应的业务审批者。业务审批者针对每份单据进行审核，若审核通过，则业务审批者在单据上签名，若审核不通过，则打回审批请求。

然而，现有的审批流程较为繁琐，不但需要打印审批单，造成办公资源的浪费，而且还要等待业务审批者对每张单据进行签名，导致整个审批过程效率低下，因此，现有的业务审批流程对人力和物力都造成较大的浪费。

发明内容

本申请实施例提供了一种基于电子签名的业务审批方法、相关装置及存储介质，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。

有鉴于此，本申请一方面提供一种基于电子签名的业务审批方法，包括：

通过业务审批界面展示第一业务审批信息；

若第一业务审批信息满足信息审批条件，则获取电子签名，其中，电子签名为根据划动操作轨迹生成的；

若存在签名备案记录，则向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

若电子签名鉴权通过，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

本申请另一方面提供一种基于电子签名的业务审批方法，包括：

获取业务审批信息；

若业务审批信息满足信息审批条件，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名，电子签名为根据划动操作轨迹生成的；

通过业务申请界面展示审批成功信息。

本申请另一方面提供一种基于电子签名的业务审批方法，包括：

展示审批配置界面；

通过审批配置界面获取附加签名指令，其中，附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的；

响应于附加签名指令，确定由客户端执行上述各方面所描述的业务审批方法。

本申请另一方面提供一种客户端，包括：

展示模块，用于通过业务审批界面展示第一业务审批信息；

获取模块，用于若所述第一业务审批信息满足信息审批条件，则获取电子签名，其中，所述电子签名为根据划动操作轨迹生成的；

发送模块，用于若存在签名备案记录，则向服务器发送所述电子签名，以使所述服务器根据备案电子签名对所述电子签名进行鉴权操作；

接收模块，用于若所述电子签名鉴权通过，则接收所述服务器发送的审批成功信息，其中，所述审批成功信息包括所述电子签名。

在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，

获取模块，具体用于通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

根据划动操作轨迹获取电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于通过业务审批界面所包括的手写签名区域，接收并展示第一划动操作轨迹；

若接收到轨迹清除指令，则响应于轨迹清除指令，并在手写签名区域上清除第一划动操作轨迹；

当通过手写签名区域接收第二划动操作轨迹时，展示第二划动操作轨迹；

获取模块，具体用于根据第二划动操作轨迹获取电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，客户端还包括确定模块；

接收模块，还用于在获取模块根据划动操作轨迹获取电子签名之后，通过业务审批界面接收签名复用指令，其中，签名复用指令携带签名复用标识，签名复用标识用于表示至少一个业务审批信息使用电子签名；

确定模块，用于响应于签名复用指令，确定第二业务审批信息使用电子签名，其中，第二业务审批信息属于至少一个业务审批信息中的任意一个业务审批信息；

发送模块，还用于若第二业务审批信息满足信息审批条件，则向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

接收模块，还用于若电子签名鉴权通过，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于若检测到签名复用标识，则启动图像采集装置；

通过图像采集装置采集业务审批者的人脸图像；

向服务器发送人脸图像；

若人脸图像与目标人脸图像匹配成功，则接收服务器发送的电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于若检测到签名复用标识，则启动语音采集装置；

通过语音采集装置采集业务审批者的声纹数据；

向服务器发送声纹数据；

若声纹数据与目标声纹数据匹配成功，则接收服务器发送的电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于若检测到签名复用标识，则通过指纹采集装置采集业务审批者的指纹数据；

若指纹数据与目标指纹数据匹配成功，则从本地图片集合中获取电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

接收模块，还用于获取模块获取电子签名之后，通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

获取模块，还用于根据划动操作轨迹获取更新后的电子签名；

发送模块，具体用于若存在签名备案记录，则向服务器发送更新后的电子签名，以使服务器根据备案电子签名对更新后的电子签名进行鉴权操作。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

发送模块，还用于在获取模块获取电子签名之后，若不存在签名备案记录，则向服务器发送电子签名，以使服务器根据历史电子签名的笔迹对电子签名的笔迹进行匹配，得到匹配相似度；

接收模块，还用于若匹配相似度大于或等于相似度阈值，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

展示模块，还用于若第一业务审批信息满足信息审批条件，则通过业务申请界面展示审批成功信息，其中，业务申请界面展示有备注区域；

接收模块，还用于通过业务申请界面所包括的备注区域接收备注信息；

发送模块，还用于若备注信息中包括用户关联标识，则根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息；

还可以包括如下步骤：

展示模块，还用于若第一业务审批信息不满足信息审批条件，则通过业务申请界面展示审批失败信息；

接收模块，还用于通过业务申请界面所包括的备注区域接收备注信息；

发送模块，还用于若备注信息中包括用户关联标识，则根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息。

本申请另一方面提供一种客户端，包括：

获取模块，用于获取业务审批信息；

接收模块，用于若业务审批信息满足信息审批条件，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名生成的，电子签名为根据划动操作轨迹生成的；

展示模块，用于通过业务申请界面展示审批成功信息。

在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，

接收模块，具体用于向服务器发送图片下载请求，其中，图片下载请求携带签名图片所对应的文件标识以及操作者的身份票据信息，签名图片为图片格式的电子签名；

向服务器发送图片下载请求，其中，图片下载请求携带签名图片所对应的文件标识以及操作者的身份票据信息，签名图片为图片格式的电子签名；

若身份票据信息为合法信息，则接收服务器发送的目标链接地址；

根据目标链接地址从服务器中下载签名图片；

接收服务器发送的业务审批信息以及审批关联信息，其中，业务审批信息以及审批关联信息属于审批成功信息；

展示模块，具体用于通过业务申请界面展示图片格式的电子签名、业务审批信息以及审批关联信息。

本申请另一方面提供一种客户端，包括：

展示模块，用于展示审批配置界面；

获取模块，用于通过审批配置界面获取附加签名指令，其中，附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的；

确定模块，用于响应于附加签名指令，确定由客户端执行上述各方面所述的业务审批方法。

本申请另一方面提供一种终端设备，包括：存储器、收发器、处理器以及总线系统；

其中，存储器用于存储程序；

处理器用于执行存储器中的程序，处理器用于根据程序代码中的指令执行上述各方面所述的业务审批方法；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请的另一方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，提供了一种基于电子签名的业务审批方法，在业务审批者使用的客户端上展示业务审批界面，如果第一业务审批信息满足信息审批条件，则获取电子签名，该电子签名为根据划动操作轨迹生成的。如果当前存在签名备案记录，则由业务审批者使用的客户端向服务器发送电子签名，服务器根据备案电子签名对电子签名进行鉴权操作，如果该电子签名鉴权通过，则接收服务器发送的审批成功信息，且该审批成功信息包括电子签名。通过上述方式，采用电子签名的方式代替传统的线下签名，便于业务审批者随时随地的进行业务审批，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。

附图说明

图1为本申请实施例中业务审批系统的一个架构示意图；

图2为本申请实施例中业务审批方法的一个交互流程示意图；

图3为本申请实施例中基于电子签名的业务审批方法的一个实施例示意图；

图4为本申请实施例中审批配置界面的一个示意图；

图5为本申请实施例中通过业务审批界面展示电子签名的一个示意图；

图6为本申请实施例中通过手写签名区域展示第一划动操作轨迹的一个示意图；

图7为本申请实施例中通过手写签名区域展示第二划动操作轨迹的一个示意图；

图8为本申请实施例中复用电子签名的一个界面示意图；

图9为本申请实施例中更新电子签名的一个实施例示意图；

图10为本申请实施例中基于移动端展示审批成功信息的一个示意图；

图11为本申请实施例中通过业务申请界面展示审批失败信息的一个示意图；

图12为本申请实施例中基于业务申请界面接收备注信息的一个示意图；

图13为本申请实施例中基于电子签名的业务审批方法的另一个实施例示意图；

图14为本申请实施例中基于电子签名的业务审批方法的另一个实施例示意图；

图15为本申请实施例中审批配置界面的一个示意图；

图16为本申请实施例中通过审批配置界面设置可见范围的一个示意图；

图17为本申请实施例中通过审批配置界面设置业务审批者的一个示意图；

图18为本申请实施例中通过审批配置界面设置条件审批流程的一个示意图；

图19为本申请实施例中通过审批配置界面设置相关权限的一个示意图；

图20为本申请实施例中通过审批配置界面设置抄送通知的一个示意图；

图21为本申请实施例中客户端的一个实施例示意图；

图22为本申请实施例中客户端的另一个实施例示意图；

图23为本申请实施例中客户端的另一个实施例示意图；

图24为本申请实施例中终端设备的一个结构示意图。

具体实施方式

本申请实施例提供了一种基于电子签名的业务审批方法、相关装置及存储介质，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应理解，本申请提供的业务审批方法适用于不同组织结构下多种业务的申请和审批，例如，在企业中员工可以通过应用客户端申请假勤业务、行政业务、财务业务、人事业务或者其他类型的业务，由企业中的上级领导或者相关部门的人员进行审批。示例性地，假勤业务包含但不仅限于请假、出差、外出和加班等，其中，员工可在请假的业务审批信息中填写请假类型、请假事由、开始时间、结束时间、请假时长以及审批人等。员工可在出差的业务审批信息中填写出差事由、出差地点、开始时间、结束时间、出差时长以及审批人等。员工可在外出的业务审批信息中填写外出事由、外出地点、开始时间、结束时间、外出时长以及审批人等。员工可在加班的业务审批信息中填写加班事由、开始时间、结束时间、加班时长以及审批人等。

示例性地，行政业务包含但不仅限于会议室预定、物品领用、物品修理、用章、用车和公文流转。其中，员工可在会议室预定的业务审批信息中填写会议室名称、开始时间、结束时间、参会人数以及审批人等。员工可在物品领用的业务审批信息中填写物品名称、物品数量以及审批人等。员工可在物品修理的业务审批信息中填写故障设备名称、故障描述、保修日期以及审批人等。员工可在用章的业务审批信息中填写用印事由、印章类型、文件名称、文件份数、用印日期以及审批人等。员工可在用车的业务审批信息中填写用车事由、开始时间、结束时间、用户时长、用车目的地以及审批人等。员工可在公文流转的业务审批信息中填写文件名称、紧急程度、来文单位、来文日期、文件摘要以及审批人等。

示例性地，行政业务包含但不仅限于报销、费用、付款、合同审批、采购以及活动经费。其中，员工可在报销的业务审批信息中填写报销类型、费用类型、发生时间、费用金额以及审批人等。员工可在费用的业务审批信息中填写费用类型、申请事由、发生日期、费用金额以及审批人等。员工可在付款的业务审批信息中填写付款事由、付款金额、付款方式、付款日期、收款人全称、银行账号、开户行以及审批人等。员工可在合同审批的业务审批信息中填写合同名称、合同编号、签约日期以及审批人等。员工可在采购的业务审批信息中填写申请事由、期望交付日期、物品名称、数量、金额以及审批人等。员工可在活动经费的业务审批信息中填写活动名称、活动说明、活动预算以及审批人等。

示例性地，行政业务包含但不仅限于入职、转正、离职、绩效以及招聘需求。其中，员工可在入职的业务审批信息中填写部门、姓名以及审批人等。员工可在转正的业务审批信息中填写转正人、所在部门以及审批人等。员工可在离职的业务审批信息中填写离职申请人、所在部门、预计离职日期、离职原因以及审批人等。员工可在绩效的业务审批信息中填写上月工作内容、上月完成情况、完成率以及审批人等。员工可在招聘需求的业务审批信息中填写招聘部门、招聘岗位、招聘人数以及审批人等。

示例性地，其他业务包含但不仅限于补卡打卡。其中，员工可在补卡打卡的业务审批信息中填写补卡事由、补卡时间以及审批人等。

又例如，在学校中家长可以通过应用客户端为孩子申请请假业务，由学校中的班主任或者相关任课老师进行审批。其中，家长可在事假的业务审批信息中填写请假事由、开始日期、结束日期等。家长可在病假的业务审批信息中填写病假类型、开始日期、结束日期以及病假单等。

在上述各类业务中，业务审批者(即审批人)在审批通过的情况下添加自己的电子签名，该电子签名会被记录并保存在审批详情，方便查看和分享。本申请提供的基于电子签名的业务审批方法可以应用于如图1所示的系统，请参阅图1，图1为本申请实施例中业务审批系统的一个架构示意图，如图所示，假设业务审批者使用第一客户端，业务请求者使用第二客户端，业务请求者通过第二客户端填写业务审批信息，然后由第二客户端将业务审批信息上传至服务器，其中，图1所示的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，此处不做限定。服务器向业务审批者使用的第一客户端发送业务审批信息，如果业务审批者批准该业务审批信息，则在第一客户端侧手写一个电子签名，基于该电子签名生成相应的签名图片，再将签名图片上传至服务器。由服务器向业务请求者使用的第二客户端反馈携带电子签名的审批成功信息。

第一客户端和第二客户端均属于应用客户端，且部署于终端设备。需要说明的是，终端设备包含但不仅限于平板电脑、笔记本电脑、掌上电脑、手机、语音交互设备及个人电脑(personal computer，PC)，此处不做限定。其中，语音交互设备包含但不仅限于智能音响以及智能家电。

结合图1所描述的业务审批系统，下面将介绍基于图1所示业务审批系统的业务交互流程，请参阅图2，图2为本申请实施例中业务审批方法的一个交互流程示意图，如图所示，具体地：

在步骤S1中，业务管理者首先根据企业管理的需要，通过第三客户端在审批模板中配置是否需要在审批同意时进行签名，并设置可以使用该模板的员工范围。其中，第三客户端属于管理端，类似地，第三客户端也部署于终端设备。

在步骤S2中，业务请求者根据实际情况以及业务管理者的要求，通过第二客户端填写对应的业务审批信息，并且提交业务审批信息至服务器。

在步骤S3中，业务审批者通过第一客户端对业务审批信息和实际情况进行验证，采用手写电子签名的方式，做出对应的审批操作。完成审批操作后，将转换为签名图片形式的电子签名上传至服务器中的分布式文件存储系统(File Transfer Network，FTN)。

在步骤S4中，服务器向业务审批者使用的第一客户端返回签名图片对应的文件标识，即得到文件标识(file ID)。

在步骤S5中，如果业务审批信息通过审批，那么服务器会向业务管理者使用的第三客户端反馈签名图片对应的文件标识，并将该文件标识保存至业务审批信息中。由此，第二客户端能够通过业务审批信息获取相应的文件标识。

在步骤S6中，业务请求者使用的第二客户端基于文件标识，向服务器请求签名图片所对应的目标链接地址。

在步骤S7中，服务器向业务请求者使用的第二客户端返回签名图片对应的目标链接地址，使得第二客户端可使用该目标链接地址下载相应的图片格式的电子签名，以此展示该电子签名。

结合上述介绍，下面将从第一客户端的角度，对本申请中基于电子签名的业务审批方法进行介绍，其中，第一客户端为业务审批者使用的客户端，请参阅图3，本申请实施例中基于电子签名的业务审批方法一个实施例包括：

101、第一客户端通过业务审批界面展示第一业务审批信息；

本实施例中，第一客户端通过业务审批界面展示第一业务审批信息，其中，第一客户端为业务审批者使用的客户端。在企业中，业务审批者可以是上级领导或者企业的人力资源(Human Resource，HR)职员等。在学校职中，业务审批者可以是班主任、教务主任或者任课老师等。在业务审批界面上展示有第一业务审批信息，其中，第一业务审批信息是业务请求者输入的待审批的相关信息，以请假业务为例，第一业务审批信息中包含但不仅限于请假类型、请假事由、开始时间、结束时间以及请假时长。

为了便于理解，请参阅图4，图4为本申请实施例中审批配置界面的一个示意图，如图所示，假设业务请求者为姓名为“泰德”的员工，所申请的业务为补卡打卡业务，第一业务审批信息包括补卡事由、补卡时间以及说明附件。可选地，在审批配置界面上还可以展示其他的关联信息，例如，审批编号、提交时间以及异常状态，这类关联信息通常是自动生成的，无需业务请求者进行填写。

102、若第一业务审批信息满足信息审批条件，则第一客户端获取电子签名，其中，电子签名为根据划动操作轨迹生成的；

本实施例中，在第一客户端侧，需判断第一业务审批信息是否满足信息审批条件，例如，如果补卡时间与提交时间之间的时间间隔小于或等于72小时，则确定满足信息审批条件。或者，如果异常状态属于范围外打卡，则确定满足信息审批条件。或者，如果添加了说明附件，则确定满足信息审批条件。又或者，如果补卡时间与提交时间之间的时间间隔小于或等于72小时，且添加了说明附件，则确定满足信息审批条件。

具体地，在确定第一业务审批信息满足信息审批条件的情况下，第一客户端即可获取电子签名，这里的电子签名是业务审批者以手写的方式输入的，手写方式可具体表现为业务审批者在终端设备侧的触摸屏上进行划动操作。为了便于理解，请再次参阅图4，图中A1所指示为电子签名，其中，该电子签名可以是在本轮审核时，基于业务审批者手写的电子签名生成的，也可以是上一轮审核时已生成的电子签名，此处不做限定。

可选地，业务审批者还可以在业务审批界面上输入审批意见，比如，审批意见为“请下次直接提交至人事部，多谢”。在确定第一业务审批信息满足信息审批条件之后，点击“同意”按键。在确定第一业务审批信息不满足信息审批条件之后，点击“驳回”按键。此外，点击“转审”按键后，将该第一业务审批信息转发给下一位业务审批者进行审核。

103、若存在签名备案记录，则第一客户端向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

本实施例中，在业务审批者已经完成签名备案的情况下，第一客户端可以直接向服务器发送电子签名，再由服务器对该电子签名进行鉴权操作。

具体地，业务审批者在注册审批账号或者进行签名之前，可以填写一个签名备案表，在签名备案表中需要填写的内容包含但不仅限于姓名、工号、部门名称、职位以及手机号码，还需要输入一个手写签名用于备案。然后可由人工审核的方式对签名备案表中的内容进行核实，也可以通过系统自动匹配的方式对签名备案表中的内容进行核实，如果核实通过，则表示业务审批者已备案成功，并将在签名备案表中填写的签名作为备案电子签名。于是可以在第一客户端侧和/或服务器侧生成相应的签名备案记录。在后续的审批业务中，一旦获取到电子签名，则根据签名备案记录对输入该电子签名的业务审批者进行合法性验证，如果存在签名备案记录，则表示该业务审批者具有审批权限。如果不存在签名备案记录，则还需要对业务审批者的合法性进行进一步校验。

服务器基于预先存储的备案电子签名对电子签名进行匹配，匹配成功，则表示该电子签名通过鉴权，反之，则表示该电子签名未通过鉴权。匹配的方式可以是相似度匹配，或者利用神经网络输出两者的差距，也可以通过人工核对的方式进行匹配，此处不做限定。

104、若电子签名鉴权通过，则第一客户端接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

本实施例中，如果电子签名通过鉴权，则第一客户端接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

具体地，在确定第一业务审批信息满足信息审批条件的情况下，第一客户端可以将电子签名转换为图片格式，即得到签名图片，然后向服务器发送该签名图片。其中，该电子签名可以保存于第一客户端所对应的终端设备本地，也可以在上传至服务器后，自动从第一客户端所对应的终端设备本地删除该电子签名，仅由服务器进行保存。

需要说明的是，每个电子签名对应于唯一的文件标识，服务器会将该文件标识记录在第一业务审批信息所对应的审批流中，无论是否审核通过，第二客户端都会收到相应的审批结果，如果审批通过，则从审批流中提取对应的文件标识，然后根据文件标识向服务器请求图片格式的电子签名，最后由服务器向第二客户端反馈审批成功信息。第二客户端在接收到审批成功信息之后，通过业务申请界面展示该审批成功信息，并根据审批成功信息，在业务申请界面上显示“已通过”的标识，可选地，还可以显示其他类型的提示标识，比如“审核已通过”，或者“通过”等，此处不做限定。可以理解的是，审批成功信息不但包括图片格式的电子签名以及业务审批信息，还可以包括审批关联信息，例如，审批编号、提交时间、异常状态、业务审批通过的时间、业务审批者的信息以及备注信息等。该审批成功信息中携带图片格式的电子签名。第二客户端在打印或者导出可携带文档格式(PortableDocument Format，PDF)的审批单据时，也会携带该电子签名。

本申请实施例中，提供了一种基于电子签名的业务审批方法，在业务审批者使用的客户端上展示业务审批界面，如果第一业务审批信息满足信息审批条件，则获取电子签名，该电子签名为根据划动操作轨迹生成的。如果当前存在签名备案记录，则由业务审批者使用的客户端向服务器发送电子签名，服务器根据备案电子签名对电子签名进行鉴权操作，如果该电子签名鉴权通过，则接收服务器发送的审批成功信息，且该审批成功信息包括电子签名。通过上述方式，采用电子签名的方式代替传统的线下签名，便于业务审批者随时随地的进行业务审批，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的一个可选实施例中，第一客户端获取电子签名，包括如下步骤：

第一客户端通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

第一客户端根据划动操作轨迹获取电子签名。

本实施例中，介绍了一种获取电子签名的方式，在业务审批界面上还可以展示一个手写签名区域，需要说明的是，手写签名区域可以是默认出现在业务审批界面上的一个区域，也可以是通过触发请求后弹出的一个区域，在一种实现方式中，业务审批者可点击业务审批界面上的“输入”按键，由此弹出手写签名区域。在另一种可能的实现方式中，业务审批者可通过语音指令触发“输入”功能，比如，通过麦克风说出“输入签名”，经过判别后形成语音指令，由此弹出手写签名区域。在手写签名区域内进行划动操作，从而生成并展示对应的划动操作轨迹，基于该划动操作轨迹得到电子签名，还可以将电子签名转换为图片格式，即得到签名图片，在数据传输过程中使用该签名图片。

为了便于理解，请参阅图5，图5为本申请实施例中通过业务审批界面展示电子签名的一个示意图，如图所示，图中A2所指示为手写签名区域，该手写签名区域对应于一个绘制交互接口，其中，绘制交互接口用于接收划动操作，并展示相应的划动操作轨迹。需要说明的是，绘制交互接口的类型包含但不仅限于画布(canvas)、可缩放矢量图形(ScalableVector Graphics，SVG)以及固态存储器与动画编辑器(flash)。基于此，业务审批者可使用手指或物体(例如手写笔或者触控笔等)在手写签名区域上进行划动操作。在一段时间内停止划动操作时，又或者业务审批者点击“完成”按钮时，通过探测划动操作轨迹可得到电子签名(例如，图5中所示的“陈康裕”)。在第一客户端侧将电子签名转换为图片格式的签名图片，然后将签名图片导出至服务器。

可以理解的是，签名图片的图片格式包含但不仅限于位图(Bitmap，BMP)、标签图像文件格式(Tag Image File Format，TIFF)、个人电脑交换(Personal ComputerExchange，PCX)、图形交换格式(Graphics Interchange Format，GIF)、联合照片专家组(Joint Photographic Expert Group，JPEG)、已标记的图形(Tagged Graphics，TGA)以及便携式网络图形(Portable Network Graphics，PNG)。

其次，本申请实施例中，提供了一种获取电子签名的方式，通过上述方式，业务审批者可以直接在手写签名区域上进行签名，操作简便，且通过手写签名区域同步展示相应的划动操作轨迹，由此提升方案的便利性和交互性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，通过业务审批界面所包括的手写签名区域，第一客户端接收并展示划动操作轨迹，包括如下步骤：

第一客户端通过业务审批界面所包括的手写签名区域，接收并展示第一划动操作轨迹；

若接收到轨迹清除指令，则第一客户端响应于轨迹清除指令，并在手写签名区域上清除第一划动操作轨迹；

当通过手写签名区域接收第二划动操作轨迹时，第一客户端展示第二划动操作轨迹；

第一客户端根据划动操作轨迹获取电子签名，包括如下步骤：

第一客户端根据第二划动操作轨迹获取电子签名。

本实施例中，介绍了一种修改电子签名的方式，在某些情况下，业务审批者可能会手写的电子签名不满意，比如，因为手抖造成电子签名不规整，或者因此触摸过快导致电子签名中的有些笔画不清晰，此时，需要消除手写签名区域中原本的划动操作轨迹(即第一划动操作轨迹)，并在该手写签名区域中重新进行划动操作，从而得到一个新的划动操作轨迹(即第二划动操作轨迹)，如果业务审批者确定这个新的划动操作轨迹符合要求，则无需进行修改，基于新的划动操作轨迹获取电子签名。如果业务审批者认为这个新的划动操作轨迹不符合要求，那么还可以再次消除这个划动操作轨迹，并再次在该手写签名区域中重新进行划动操作。

为了便于介绍，请参阅图6，图6为本申请实施例中通过手写签名区域展示第一划动操作轨迹的一个示意图，如图所示，在手写签名区域上展示有A3所指示的第一划动操作轨迹，基于图6所示的第一划动操作轨迹可见，业务审批者已完成自己的电子签名，此时，如果业务审批者对该电子签名的效果不满意，则可以点击A4所指示的“清除”按钮。当业务审批者点击该“清除”按钮时，即触发轨迹清除指令。第一客户端响应于该轨迹清除指令，并清除手写签名区域上原本的第一划动操作轨迹，基于此，业务审批者可以再次在手写签名区域上进行划动操作。请参阅图7，图7为本申请实施例中通过手写签名区域展示第二划动操作轨迹的一个示意图，如图所示，业务审批者在手写签名区域中重新进行划动操作，操作完成后，在手写签名区域上展示有A5所指示的第二划动操作轨迹，基于图7所示的第二划动操作轨迹可见，业务审批者已再次完成自己的电子签名。此时，如果业务审批者对该电子签名的效果满意，则第一客户端根据第二划动操作轨迹获取电子签名。

可选地，A4所指示的“清除”按钮也可以用于清除第一划动操作轨迹中最后一笔，例如，第一划动操作轨迹的最后一笔为“丿(即撇)”，而正确的笔画应该是“丨(即竖)”。业务审批者可以点击A4所指示的“清除”按钮，即触发轨迹清除指令。第一客户端响应于该轨迹清除指令，并清除手写签名区域上第一划动操作轨迹中的最后一笔为“丿”，然后在第一划动操作轨迹剩余的笔画上重新补上一笔，即补上笔画“丨”，基于此，在手写签名区域上展示有更新后得到的第二划动操作轨迹。

再次，本申请实施例中，提供了一种修改电子签名的方式，通过上述方式，如果业务审批者对第一次签名的效果不满意，则可以清除当前的电子签名，并重新进行下一次签名，以此达到自己满意的效果，从而提升签名的灵活性和操作的多样性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端根据划动操作轨迹获取电子签名之后，还可以包括如下步骤：

第一客户端通过业务审批界面接收签名复用指令，其中，签名复用指令携带签名复用标识，签名复用标识用于表示至少一个业务审批信息使用电子签名；

第一客户端响应于签名复用指令，确定第二业务审批信息使用电子签名，其中，第二业务审批信息属于至少一个业务审批信息中的任意一个业务审批信息；

若第二业务审批信息满足信息审批条件，则第一客户端向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

若电子签名鉴权通过，则第一客户端接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

本实施例中，介绍了一种复用电子签名的操作方式，在第一客户端获取到业务审批者的电子签名之后，还可以获取签名复用指令，其中，签名复用指令可以是业务审批者主动触发的，也可以是第一客户端在获取到电子签名后默认触发的。本实施例主要以业务审批者通过业务审批界面触发签名复用指令为例进行介绍。

为了便于理解，请再次参阅图5，如图所示，图中A2所指示为手写签名区域，业务审批者可使用手指或物体(例如手写笔或者触控笔等)在手写签名区域上进行划动操作，在一段时间内停止划动操作之后，或者在业务审批者点击“完成”按钮之前，业务审批者还可以选择是否触发“下次同意时继续使用此签名”的选项，如果选择该选项，即触发签名复用指令，于是在后续的业务审批中能够直接使用该电子签名，无需业务审批者再次手写一个电子签名。如果未选择该选项，即未触发签名复用指令，于是在后续的业务审批中还需要业务审批者再次手写电子签名。其中，在签名复用指令中携带签名复用标识，第一客户端可基于签名复用指令确定下一个业务审批信息将自动使用本次输入的电子签名。

具体地，假设业务审批者在审批第N个业务审批信息(例如，第一业务审批信息)时，在手写签名区域上进行划动操作，停止划动操作后基于划动操作轨迹获取电子签名，可以将电子签名以图片格式存储于第一客户端侧的终端设备本地，也可以将图片格式的电子签名上传至服务器。如果业务审批者触发了签名复用指令，那么业务审批者在审批第N+1个业务审批信息(例如，第二业务审批信息)时，先检测是否存在签名复用标识，如果存在该签名复用标识，那么从第一客户端侧的终端设备本地中调用已存储的图片格式的电子签名，或者，从服务器上下载图片格式的电子签名。基于此，在业务审批者在审批第N+1个业务审批信息(例如，第二业务审批信息)时，将自动续用该图片格式的电子签名。在确定第N+1个业务审批信息(例如，第二业务审批信息)满足信息审批条件的情况下，该第一客户端可以向服务器发送图片格式的电子签名。为了防止电子签名在传输过程中被篡改，服务器还可以根据备案电子签名对电子签名进行鉴权操作，如果该电子签名通过鉴权，则第一客户端接收服务器发送的审批成功信息。

再次，本申请实施例中，提供了一种复用电子签名的操作方式，通过上述方式，业务审批者还可以选择下次同意审批时，继续使用本次的电子签名，由此解决了多单据重复操作的问题，从而提升审批的便捷性，有利于提升审批效率。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端获取电子签名，可以包括如下步骤：

若检测到签名复用标识，则第一客户端启动图像采集装置；

第一客户端通过图像采集装置采集业务审批者的人脸图像；

第一客户端向服务器发送人脸图像；

若人脸图像与目标人脸图像匹配成功，则第一客户端接收服务器发送的电子签名。

本实施例中，介绍了一种基于人脸识别的电子签名复用方式，在第一业务审批信息满足信息审批条件的情况下，先检测是否存在签名复用标识，如果存在签名复用标识，则提醒业务审批者开启图像采集装置，需要说明的是，图像采集装置可以是内置摄像头或者外置摄像头，此处不做限定。图像采集装置开启后，业务审批者通过图像采集装置拍摄自己的人脸图像，再将人脸图像发送至服务器。服务器中预先存储有至少一张目标人脸图像，于是将人脸图像与这些目标人脸图像进行匹配，即进行相似性比对，如果相似性大于相似性阈值，则表示人脸图像与目标人脸图像匹配成功，于是服务器向第一客户端发送电子签名。如果相似性小于相似性阈值，则表示人脸图像与目标人脸图像匹配失败，于是服务器不会向第一客户端发送电子签名。

其次，本申请实施例中，提供了一种基于人脸识别的电子签名复用方式，通过上述方式，只有在人脸识别成功后才能够复用电子签名，提升电子签名的使用安全性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端获取电子签名，可以包括如下步骤：

若检测到签名复用标识，则启动语音采集装置；

通过语音采集装置采集业务审批者的声纹数据；

向服务器发送声纹数据；

若声纹数据与目标声纹数据匹配成功，则接收服务器发送的电子签名。

本实施例中，介绍了一种基于声纹识别的电子签名复用方式，在第一业务审批信息满足信息审批条件的情况下，先检测是否存在签名复用标识，如果存在签名复用标识，则提醒业务审批者开启语音采集装置，需要说明的是，语音采集装置可以是内置麦克风或者外置麦克风，此处不做限定。语音采集装置开启后，业务审批者通过语音采集装置说话，再将语音所对应的声纹数据发送至服务器。服务器中预先存储有至少一段目标声纹数据，于是将声纹数据与这些目标声纹数据进行匹配，即进行相似性比对，如果相似性大于相似性阈值，则表示声纹数据与目标声纹数据匹配成功，于是服务器向第一客户端发送电子签名。如果相似性小于相似性阈值，则表示声纹数据与目标声纹数据匹配失败，于是服务器不会向第一客户端发送电子签名。

其次，本申请实施例中，提供了一种基于声纹识别的电子签名复用方式，通过上述方式，只有在声纹识别成功后才能够复用电子签名，提升电子签名的使用安全性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端获取电子签名，可以包括如下步骤：

若检测到签名复用标识，则第一客户端通过指纹采集装置采集业务审批者的指纹数据；

若指纹数据与目标指纹数据匹配成功，则第一客户端从本地图片集合中获取电子签名。

本实施例中，介绍了一种基于签名复用标识从本地获取电子签名的方式，在第一业务审批信息满足信息审批条件的情况下，先检测是否存在签名复用标识，如果存在签名复用标识，则业务审批者通过指纹采集装置输入自己的指纹，由于指纹具有私密性，因此，在第一客户端侧进行验证，由第一客户端将指纹数据与目标指纹数据进行匹配，即进行相似性比对，如果相似性大于相似性阈值，则表示指纹数据与目标指纹数据匹配成功，于是第一客户端从本地图片集合中获取电子签名。如果相似性小于相似性阈值，则表示指纹数据与目标指纹数据匹配失败，于是第一客户端不能从本地图片集合中获取电子签名。在实际应用中，需要将电子签名先转换为签名图片，然后存储于本地图片集合中。下面将介绍两种存储的签名图片的方式。一种为增量型添加签名图片，另一种为擦除型添加签名图片。

具体地，在增量型添加签名图片的过程中，需要将每个电子签名所对应的签名图片存放于本地图片集合中，且每个签名图片对应于一个存储时间。为了便于说明，请参阅表1，表1为本地图片集合中存储的签名图片的一个示意。

表1

文件标识	存储时间
		00001	2020/5/10/15:30:15
00035	2020/5/10/15:35:40
		00226	2020/5/15/09:05:30
00352	2020/5/16/23:11:02
		00779	2020/5/17/10:42:18

由表1可知，最后一次存储签名图片的时间为2020/5/17/10:42:18，因此，在检测到签名复用标识的情况下，将文件标识为“00779”的签名图片作为复用的签名图片。如果后续更新了电子签名，则将更新后的电子签名对应的签名图片添加至本地图片集合。

在擦除型添加签名图片的过程中，仅在本地图片集合中存储最后一次更新的签名图片，为了便于说明，请参阅表2，表2为本地图片集合中存储的签名图片的另一个示意。

表2

文件标识	存储时间
		00352	2020/5/16/23:11:02

由表2可知，最后一次存储签名图片的时间为2020/5/16/23:11:02，因此，在检测到签名复用标识的情况下，将文件标识为“00352”的签名图片作为复用的签名图片。如果后续更新了电子签名，则将更新后的电子签名对应的签名图片添加至本地图片集合，请参阅表3，表3为更新签名图片的一个示意。

表3

文件标识	存储时间
		00779	2020/5/17/10:42:18

由表3可知，更新后的签名图片将替换掉本地图片集合中前一个签名图片。

为了便于理解，请参阅图8，图8为本申请实施例中复用电子签名的一个界面示意图，如图所示，如果选择了复用电子签名，那么在业务审批界面上还可以直接展示上一次手写的电子签名，即为A6所示的电子签名。其中，图8所示的界面可以为电脑端的界面，类似地，在移动端所示的界面上也可以相应地展示上一次手写的电子签名。如果业务审批者不满意当前业务审批界面展示的电子签名，则可以点击A7所指示的“重新签名”按钮，由此重新手写一个新的电子签名来替换当前的电子签名。

其次，本申请实施例中，提供了一种基于签名复用标识从本地获取电子签名的方式，通过上述方式，即使在没有联网的情况下，也可以直接从终端设备本地提取电子签名，由此提升操作的便利性和可行性。此外，图片格式的电子签名占用的内存较少，保存在终端设备不会耗费过多的资源，同时还方便用户随时进行查看和使用。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端获取电子签名之后，还可以包括如下步骤：

第一客户端通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

第一客户端根据划动操作轨迹获取更新后的电子签名；

若存在签名备案记录，则第一客户端向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

存在签名备案记录，则第一客户端向服务器发送更新后的电子签名，以使服务器根据备案电子签名对更新后的电子签名进行鉴权操作。

本实施例中，介绍了一种更新电子签名的方式，如果选择了复用电子签名，则第一客户端可在手写签名区域直接展示电子签名，此时，业务审批者还可以对该电子签名进行更新，即得到更新后的电子签名。

为了便于理解，请参阅图9，图9为本申请实施例中更新电子签名的一个实施例示意图，如图9中的(a)图所示，首先在业务审批界面所包括的手写签名区域上展示复用的电子签名，如需重新改写该电子签名，则触发A8所指示的“重新签名”按钮，基于此，该手写签名区域内的电子签名将被清空，于是业务审批者可以通过第一客户端继续进行划动操作，使得第一客户端通过手写签名区域接收并展示划动操作轨迹，类似地，再基于划动操作轨迹获取更新后的电子签名，即得到如图9中(b)图所示的电子签名。然后将更新后的电子签名转换为图片格式，即生成更新后的签名图片，于是，第一客户端向服务器发送更新后的签名图片，由服务器根据更新后的签名图片向第二客户端发送更新后的审批成功信息。

再次，本申请实施例中，提供了一种更新电子签名的方式，通过上述方式，如果业务审批者对复用的电子签名不满意，则还可以重新手写电子签名，达到更新电子签名的目的，从而提升签名的灵活性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一客户端获取电子签名之后，还可以包括如下步骤：

若不存在签名备案记录，则第一客户端向服务器发送电子签名，以使服务器根据历史电子签名的笔迹对电子签名的笔迹进行匹配，得到匹配相似度；

若匹配相似度大于或等于相似度阈值，则第一客户端接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

本实施例中，介绍了一种不存在签名备案记录的处理方式，在不存在签名备案记录的情况下，则还需要对业务审批者的合法性进行进一步校验。具体地，服务器可以获取业务审批者的历史电子签名，即获取业务审批者在本次签名之前手写过的其他电子签名。在服务器侧比对历史电子签名的笔迹与电子签名的笔迹，其中，比对笔迹的方式可以是，从历史电子签名的笔迹提取T个关键点，从电子签名的笔迹也提取T个关键点，分别将两类笔迹的关键点进行比对，计算匹配相似度(例如，余弦距离)，如果匹配相似度大于或等于相似度阈值，则第一客户端接收服务器发送的审批成功信息。

如果不存在历史电子签名，则可以向第一客户端发送签名备案表，由此采集业务审批者的相关信息。

其次，本申请实施例中，提供了一种不存在签名备案记录的处理方式，通过上述方式，能够在业务审批者未进行签名备案的情况下，基于历史电子签名的笔迹对当前手写的电子签名进行匹配，一方面提升了操作的灵活性，另一方面可以基于历史笔迹匹配当前笔迹，从而认证业务审批者的身份，进而提升审批的可靠性和安全性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括如下步骤：

若第一业务审批信息满足信息审批条件，则第一客户端通过业务申请界面展示审批成功信息，其中，业务申请界面展示有备注区域；

第一客户端通过业务申请界面所包括的备注区域接收备注信息；

若备注信息中包括用户关联标识，则第一客户端根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息；

还可以包括如下步骤：

若第一业务审批信息不满足信息审批条件，则第一客户端通过业务申请界面展示审批失败信息；

第一客户端通过业务申请界面所包括的备注区域接收备注信息；

若备注信息中包括用户关联标识，则第一客户端根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息。

本实施例中，介绍了一种通过业务申请界面展示审批结果的方式，无论业务审批信息(如第一业务审批信息或第二业务审批信息)是否满足信息审批条件，在业务审批者完成审批后，都可以通过业务申请界面展示相应的审批信息。需要说明的是，无论是在业务审批者所使用的第一客户端上，还是业务请求者所使用的第二客户端上，都可以展示该业务申请界面。可以理解的是，如果第一客户端或第二客户端部署于移动端(如手机端或者平板电脑端)，那么在业务申请界面上通常不具有“打印”的按钮或者“导出”的按钮，如果第一客户端或第二客户端部署于电脑端(如台式电脑端或者笔记本电脑端)，那么在业务申请界面上还具有“打印”的按钮或者“导出”的按钮，当触发“打印”按钮时，可由联网的打印机打印业务申请界面上显示的审批信息。当触发“导出”按钮时，可以导出至当前使用的电脑上，便于后续查看。此外，在业务申请界面中还包括备注区域，业务审批者、业务申请者或者抄送人还可以在备注区域内输入文本信息，若备注信息中包括用户关联标识(例如，“@”)，则第一客户端根据“@”后的目标用户向服务器发送消息提示请求，该消息提示请求中携带目标对象的标识，于是服务器向目标用户使用的客户端发送备注信息，且目标用户使用的客户端会以高亮、提示音、震动或者其他方式提醒目标用户查看相应的备注信息。

为了便于理解，请参阅图10，图10为本申请实施例中基于移动端展示审批成功信息的一个示意图，如图所示，以第一业务审批信息为例，若该第一业务审批信息通过信息审批条件，那么业务申请者(例如“考勤小组”)可通过第一客户端输入手写的电子签名，该电子签名转换为签名图片之后存储于服务器侧。基于此，在业务申请者点击“同意”按钮之后，可通过业务申请界面展示审批成功信息。其中，审批成功信息不但包括电子签名(如图10中所示的“陈康裕”的签名)以及第一业务审批信息(例如，补卡时间、补卡事由以及说明附件)，还可以包括审批关联信息，例如，审批编号(例如，20200520010)、提交时间(例如，2020年5月20日18点02分)、异常状态(例如，范围外打卡)、业务审批通过的时间(例如，2020年5月21日19点00分)、业务审批者的信息(例如，考勤小组以及考勤小组的头像等信息)以及备注信息(例如，本月剩余补卡次数为39次)等。此外，在业务申请界面上显示“已通过”的标识。

请参阅图11，图11为本申请实施例中通过业务申请界面展示审批失败信息的一个示意图，如图所示，以第一业务审批信息为例，若该第一业务审批信息未通过信息审批条件，那么业务申请者(例如“考勤小组”)无需手写电子签名。基于此，在业务申请者点击“驳回”按钮之后，可通过业务申请界面展示审批失败信息。其中，审批失败信息不但第一业务审批信息(例如，补卡时间、补卡事由以及说明附件)，还可以包括审批关联信息，例如，审批编号(例如，20200520010)、提交时间(例如，2020年5月20日18点02分)、异常状态(例如，范围外打卡)、业务审批驳回的时间(例如，2020年5月21日19点00分)、业务审批者的信息(例如，考勤小组以及考勤小组的头像等信息)以及备注信息(例如，本月剩余补卡次数为39次)等。此外，在业务申请界面上显示“已驳回”的标识。

为了便于说明，请参阅图12，图12为本申请实施例中基于业务申请界面接收备注信息的一个示意图，与图10所示的移动端的业务申请界面类似，图12所示出的为业务申请界面，不同之处在于，该业务申请界面还具有A9所指示的“打印”按钮，当点击该“打印”按钮时，即可触发打印功能，即打印审批单据。业务申请界面还具有Q1所指示备注区域，在备注区域中可以输入备注信息，其中，备注信息中可以包括用户关联标识，用户关联标识可以为“@”，比如，备注信息为“@杰克，请尽快审核”，于是第一客户端根据用户关联标识向服务器发送消息提示请求，消息提示请求中携带“杰克”的用户标识，于是服务器向“杰克”使用的客户端发送备注信息，且“杰克”使用的客户端会以高亮、提示音、震动或者其他方式提醒目标用户查看相应的备注信息。

可以理解的是，图12中的“陈康裕”即为电子签名，图12所示的业务审批信息为补卡事由(如“测试”)、补卡时间(如“2020/05/20 17:00”)以及说明附件(如“无”附件)，图12所示的审批关联信息为审批编号(如“20200520010”)、提交时间(如“2020/05/20 18:02”)、异常状态(“范围外打卡”)、业务审批通过的时间(如“2020/05/21 17:00”)、业务审批者的信息(考勤小组)以及备注信息。

进一步地，本申请实施例中，提供了一种通过业务申请界面展示审批结果的方式，通过上述方式，对于业务审批者和业务申请者而言，都可以在业务申请界面上查看审批成功信息，或者在业务申请界面上查看审批失败信息，从而能够及时了解业务的审批情况，便于跟进，并及时进行处理。此外，还可以采用用户关联标识提醒用户查看相关备注信息，从而提升流程的交互性。

结合上述介绍，下面将从第二客户端的角度，对本申请中基于电子签名的业务审批方法进行介绍，其中，第二客户端为业务请求者使用的客户端，请参阅图13，本申请实施例中基于电子签名的业务审批方法另一个实施例包括：

201、第二客户端获取业务审批信息；

本实施例中，第二客户端接收业务请求者填写的业务审批信息，其中，第二客户端为业务申请者使用的客户端。在企业中，业务申请者可以是员工。在学校中，业务申请者可以是家长或者学生。可以理解的是，业务审批信息是业务请求者输入的待审批的相关信息，以请假业务为例，业务审批信息中包含但不仅限于请假类型、请假事由、开始时间、结束时间以及请假时长。

第二客户端在获取到业务审批信息后，将该业务审批信息发送至服务器，由服务器向业务审核者使用的第一客户端发送该业务审批信息。第一客户端通过业务审批界面展示业务审批信息，其中，第一客户端为业务审批者使用的客户端。在企业中，业务审批者可以是上级领导或者企业的HR职员等。在学校职中，业务审批者可以是班主任、教务主任或者任课老师等。在第一客户端侧除了展示业务审批信息，还可以展示其他的关联信息，例如，审批编号、提交时间以及异常状态，这类关联信息通常是自动生成的，无需业务请求者进行填写。

202、若业务审批信息满足信息审批条件，则第二客户端接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名，电子签名为根据划动操作轨迹生成的；

本实施例中，在第一客户端侧，需判断业务审批信息是否满足信息审批条件，例如，如果补卡时间与提交时间之间的时间间隔小于或等于72小时，则确定满足信息审批条件。或者，如果异常状态属于范围外打卡，则确定满足信息审批条件。或者，如果添加了说明附件，则确定满足信息审批条件。又或者，如果补卡时间与提交时间之间的时间间隔小于或等于72小时，且添加了说明附件，则确定满足信息审批条件。

具体地，在确定业务审批信息满足信息审批条件的情况下，第一客户端即可获取电子签名，这里的电子签名是业务审批者以手写的方式输入的，手写方式可具体表现为业务审批者在终端设备侧的触摸屏上进行划动操作。于是第一客户端向服务器发送图片格式的电子签名。需要说明的是，每个电子签名对应于唯一的文件标识，服务器会将该文件标识记录在业务审批信息所对应的审批流中，无论是否审核通过，第二客户端都会收到相应的审批结果，如果审批通过，则从审批流中提取对应的文件标识，然后根据文件标识向服务器请求图片格式的电子签名，最后由服务器向第二客户端反馈图片格式的电子签名。

203、第二客户端通过业务申请界面展示审批成功信息。

本实施例中，第二客户端在接收到审批成功信息之后，通过业务申请界面展示该审批成功信息，并根据审批成功信息，在业务申请界面上显示“已通过”的标识，可选地，还可以显示其他类型的提示标识，比如“审核已通过”，或者“通过”等，此处不做限定。可以理解的是，审批成功信息不但包括图片格式的电子签名以及业务审批信息，还可以包括审批关联信息，例如，审批编号、提交时间、异常状态、业务审批通过的时间、业务审批者的信息以及备注信息等。

本申请实施例中，提供了一种基于电子签名的业务审批方法，首先第二客户端获取业务审批信息，如果业务审批信息满足信息审批条件，则第二客户端接收服务器发送的审批成功信息，最后通过业务申请界面展示审批成功信息。通过上述方式，采用电子签名的方式代替传统的线下签名，便于业务审批者随时随地的进行业务审批，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的。对于业务请求者而言，可以随时随地查看审批结果，便于及时了解审批情况。

可选地，在上述图13对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二客户端接收服务器发送的审批成功信息，可以包括如下步骤：

第二客户端向服务器发送图片下载请求，其中，图片下载请求携带签名图片所对应的文件标识以及操作者的身份票据信息，签名图片为图片格式的电子签名；

若身份票据信息为合法信息，则第二客户端接收服务器发送的目标链接地址；

第二客户端根据目标链接地址从服务器中下载签名图片；

第二客户端接收服务器发送的业务审批信息以及审批关联信息，其中，业务审批信息以及审批关联信息属于审批成功信息；

第二客户端通过业务申请界面展示审批成功信息，可以包括如下步骤：

第二客户端通过业务申请界面展示图片格式的电子签名、业务审批信息以及审批关联信息。

本实施例中，介绍了一种获取审批成功信息的方式，审批成功信息主要包括两个部分，一个部分是电子签名，另一个部分则是业务审批信息以及审批关联信息。其中，业务审批信息以及审批关联信息是由服务器直接向第二客户端反馈的，而电子签名涉及到私密性和安全性的问题，因此，需要第二客户端主动向服务器发起请求。

具体地，在审批通过后，服务器可存储第一客户端上传的图片格式的电子签名，其中，每个电子签名对应于唯一一个文件标识，且每个图片格式的电子签名对应于一个用于下载的链接地址，即统一资源定位符(Uniform Resource Locator，URL)地址。服务器会将该文件标识记录在业务审批信息所对应的审批流中，无论是否审核通过，第二客户端都会收到相应的审批结果，如果审批通过，则从审批流中提取对应的文件标识，然后根据文件标识向服务器请求电子签名，即第二客户端向服务器发送图片下载请求，其中，该图片下载请求携带电子签名所对应的文件标识以及操作者的身份票据信息。需要说明的是，操作者的身份票据信息具体可以是供应商标识(Venser Identity，VID)和/或企业标识(Corporation Identity，CorpID)，VID和CorpID都是用于表示操作者身份的，只有具有操作权限的操作者，才具有身份票据信息，且身份票据信息具有唯一性，对身份票据信息进行匹配的方式为，如果该身份票据信息与预先存储在服务器中的身份票据信息一致，则表示该身份票据信息为合法信息，反之，则表示该身份票据信息不合法。

在确定第二客户端发送的身份票据信息为合法信息后，服务器将会根据文件标识确定图片格式的电子签名所对应的目标链接地址，并向第二客户端发送目标链接地址。第二客户端使用该目标链接地址，从服务器中下载所需的电子签名。可以理解的是，在实际应用中，目标链接地址还可以设置一个有效期，例如，在15分钟内可以使用目标链接地址下载图片格式的电子签名，超过有效期的情况下，则无法使用该目标链接地址下载图片格式的电子签名，也就需要重新向服务器请求一个新的链接地址。基于此，能够提升电子签名的安全性和可靠性，防止电子签名在传输期间被偷看、盗取或仿冒，进而提升电子签名的安全性。

其次，本申请实施例中，提供了一种获取审批成功信息的方式，通过上述方式，在客户端向服务器请求图片格式的电子签名时，需要对该客户端对应的身份票据信息进行验证，在验证通过之后才允许服务器向客户端下发电子签名，因此，能够提升数据传输的安全性，也增加了电子签名的可靠性。此外，服务器下发的目标链接地址还可以设置一个有效期，在有效期内，该目标链接地址是有效的，如果不在有效期内，则客户端需要重新向服务器请求一个用于下载图片格式的电子签名的链接地址，由此进一步提升电子签名的可靠性和安全性。

结合上述介绍，下面将从第二客户端的角度，对本申请中基于电子签名的业务审批方法进行介绍，其中，第二客户端为业务请求者使用的客户端，请参阅图14，本申请实施例中基于电子签名的业务审批方法另一个实施例包括：

301、第三客户端展示审批配置界面；

本实施例中，在实现上述实施例中提供的业务审批方法之前，还需要由业务管理者在第三客户端侧进行相关配置。其中，业务管理者可以为超级管理者或者分级管理者，一个企业内可以有多个超级管理者，这些超级管理者同样拥有企业的最高管理权限。分级管理者适用于企业的分级权限管理，可以给分级管理者分配相应的部分通讯录或应用的权限，分级管理者只能管辖或设置其拥有的对应权限。

302、第三客户端通过审批配置界面获取附加签名指令，其中，附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的；

本实施例中，业务管理者可在第三客户端所展示的审批配置界面上触发附加签名指令，即配置业务审批者需要在同意业务审批信息的时候进行签名，一旦配置完成，则表示业务审批者需要在同意业务审批信息时添加自己的电子签名。相应地，业务管理者还可以在第三客户端所展示的审批配置界面上触发签名去除指令，即配置业务审批者无需在同意业务审批信息的时候进行签名，一旦配置完成，则表示业务审批者无需在同意业务审批信息时添加自己的电子签名。

为了便于介绍，请参阅图15，图15为本申请实施例中审批配置界面的一个示意图，如图所示，在A10所指示的“电子签名”区域中，可勾选“审批人同意时需签名”的选项，如果勾选“审批人同意时需签名”的选项，则表示业务审批者需要在同意业务审批信息时添加自己的电子签名。如果取消勾选“审批人同意时需签名”的选项，则表示业务审批者无需在同意业务审批信息时添加自己的电子签名。此外，在A11所示的“协助管理”区域中可添加协助管理人员，协助管理人员支持在移动端查看协助管理的业务规则内成员的业务申请记录。完成对审批配置界面中各项内容的配置之后，点击“保存”，即可保存业务管理者的配置，并基于该配置实现后续的操作。

303、第三客户端响应于附加签名指令，确定由客户端执行如图3对应的各个实施例所涉及的业务审批方法。

本实施例中，业务管理者响应于附加签名指令，由此确定业务审批者需要在同意业务审批信息的情况下，通过第一客户端输入相应的电子签名，以此进行相应的审批流程。类似地，对于业务申请者而言，也会在收到的审批成功信息中查看到相应的电子签名，以此实现相应的审批流程。

可以理解的是，在实际应用中，除了可以在审批配置界面中配置“审批人同意时需签名”的选项，以及“协助管理”的协助管理人员，还可以配置其他的相关内容，下面将对审批配置界面中的其他可配置内容进行介绍。

针对审批情况可设置相关的人员，这些相关人员可以查看与审批有关的信息，能够查看到业务审批者的电子签名。请参阅图16，图16为本申请实施例中通过审批配置界面设置可见范围的一个示意图，如图所示，不同的审批模板可能有各自适用的部门和成员，因此，可以对这些审批模板设置可见范围，也就是说，仅可见范围内的成员可以使用该审批模板。例如，以图16为例，可见范围包括“考勤小组”内的所有成员、“部门一”内的所有成员、“部门二”内的所有成员以及“部门四”内的所有成员。如果需要修改可见范围，则可以点击A12所指示的“修改”按钮，由此可以增加新的可见范围，或者删除已有的可见范围，又或者将原有的可见范围修改为新的可见范围。

在实际应用中，还可以添加新的业务审批者，或者删除已有的业务审批者。请参阅图17，图17为本申请实施例中通过审批配置界面设置业务审批者的一个示意图，如图17中的(a)图所示，审批人(即业务审批者)即有资格审批员工(即业务请求者)提交申请(即业务审批信息)的成员，即包括上级“杰克”、会签标签组内的成员以及或签标签组内的成员，其中，同一级审批流程中有多个审批人时，可根据需求设置或签审批或会签审批。可选地，业务管理者还可以添加默认抄送人，默认抄送人可以收到相关的审批通知。可选地，业务管理者还可以新增默认审批人，即点击A13所指示的“+”按钮，以此进入如图17中(b)图所示的界面。基于该界面，业务管理者可选择要添加的审批人(即业务审批者)的类型，在本申请中，审批人(即业务审批者)包括三种类型，类型一为上级，即默认业务请求者的上级为业务审批者，由此实现逐级审批。类型二为标签，即通过添加通讯录中的某个标签组为业务审批者。类型三为单个成员，即指定某个成员为业务审批者。业务管理者还可以选择上级的审批方式，当选择“会签”审批时，表示该标签组内所有成员都要同意才能算通过。当选择“或签”审批时，表示该标签组内任意一个成员同意即可通过。

请参阅图18，图18为本申请实施例中通过审批配置界面设置条件审批流程的一个示意图，如图18中的(a)图所示，业务管理者可以根据不同的条件使用不同的审批流程，示例性地，可根据业务申请者提交的请假类型和请假时间的长短设置审批路径，例如，请假类型为事假或者病假的情况需尽快结束审批，请假类型为年假的情况无需加快审批。示例性地，可根据报销金额的大小，让小金额的费用报销尽快结束审批。示例性地，当业务请求者为销售部成员，且请假时长大于3天的时候，使用审批流程A，当业务请求者为销售部成员，且请假时长小于3天的时候，使用审批流程B。在业务管理者触发A14所指示的“添加”按钮时，即可进入如图18中(b)图所示的界面。基于该界面，业务管理者即可添加条件审批流程。其中，流程名称是用于区分各个条件审批流程的，通常不超过20个字符。申请人、明细外的数字、金额、单选框以及多选框等控件均可作为条件，当设置多个条件时，需同时满足所有条件才会使用对应审批流程。此外，在同一个条件审批流程中，一个控件只能设置一次条件。下面将分别进行介绍。

当申请人(即业务请求者)属于所设置的部门或成员时，即满足条件。当申请人(即业务请求者)在数字控件中填写内容大于、大于等于、等于、小于、小于等于或者介于(介于表示大于等于某数值且小于等于某数值)指定数值时，即满足条件。当申请人(即业务请求者)在金额控件中填写内容大于、大于等于、等于、小于、小于等于或者介于(介于表示大于等于某数值且小于等于某数值)指定数值时，即满足条件。当申请人(即业务请求者)在单选框控件中选中的选项(例如，选择“礼品”选项)，属于设置的选项之一时，即满足条件。当申请人(即业务请求者)在多选框控件中，选中的选项完全包含设置的所有选项(例如，选择“电子产品”选项以及“充值卡”选项)时，即满足条件。

请参阅图19，图19为本申请实施例中通过审批配置界面设置相关权限的一个示意图，如图所示，在“查看权限”的选项中，可选择是否勾选“仅管理员、申请人、审批人、抄送人可查看审批详情”的选项，若勾选该选项，则表示只有业务管理者、业务审批者、业务申请者和默认抄送人可以查看与业务审批信息相关的审批详情，而其他人没有查看的权限。在“修改权限”的选项中，可选择是否勾选“提交申请时，员工不可修改审批人”的选项，若勾选该选项，则表示业务申请者提交业务审批信息时不能修改业务审批者。在“修改权限”的选项中，还可选择是否勾选“提交申请时，员工不可修改抄送人”的选项，若勾选该选项，则表示业务申请者提交业务审批信息时不能修改抄送人。在“撤销权限”的选项中，可选择是否勾选“通过后允许撤销，审批通过后，经审批人同意，可撤销申请”的选项，若勾选该选项，则表示业务申请者提交的业务审批信息审批通过之后，经过业务审批者同意，业务请求者可以撤销本次申请。

请参阅图20，图20为本申请实施例中通过审批配置界面设置抄送通知的一个示意图，如图所示，业务管理者可选择一种抄送方式，而本申请提供了三种可选地的抄送方式，下面将分别进行介绍。第一种抄送方式为“提交申请时抄送”，在申请人(即业务申请者)提交业务审批信息后，抄送人就会收到审批抄送，若第一级审批人和抄送人有重复时，抄送人的抄送列表不出现该业务审批信息。第二种抄送方式为“审批通过后抄送”在审批人(即业务审批者)全部审核通过后，抄送人会收到审批抄送；审批单通过前或被驳回，抄送人看不到审批单。第三种抄送方式为“提交申请时和审批通过后都抄送”，申请人(即业务申请者)提交审批后，以及审批人(即业务审批者)全部审核通过后，抄送人都会收到审批抄送，若第一级审批人和抄送人有重复，当审批单为“审批中”时，抄送人的抄送列表不出现该审批，当审批单“已通过”后，抄送人才会收到审批抄送。

本申请实施例中，提供了一种基于电子签名的业务审批方法，首先第三客户端展示审批配置界面，然后通过审批配置界面获取附加签名指令，该附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的，最后第三客户端响应于附加签名指令，确定由第一客户端和第二客户端分别执行相应的业务审批方法。通过上述方式，采用电子签名的方式代替传统的线下签名，便于业务审批者随时随地的进行业务审批，不但能够提升业务审批效率，而且实现了无纸化办公，从而在业务审批的流程中达到了节省人力和物力的目的，增加了审批流程的正式性和丰富性。对于业务请求者而言，可以随时随地查看审批结果，便于及时了解审批情况。对于业务管理者而言，可以对需要签名确认的审批单据进行的统一管理，实现灵活的自动化管理模式。

下面对本申请中的第一客户端进行详细描述，请参阅图21，图21为本申请实施例中客户端的一个实施例示意图，客户端40包括：

展示模块401，用于通过业务审批界面展示第一业务审批信息；

获取模块402，用于若所述第一业务审批信息满足信息审批条件，则获取电子签名，其中，所述电子签名为根据划动操作轨迹生成的；

发送模块403，用于若存在签名备案记录，则向服务器发送所述电子签名，以使所述服务器根据备案电子签名对所述电子签名进行鉴权操作；

接收模块404，用于若所述电子签名鉴权通过，则接收所述服务器发送的审批成功信息，其中，所述审批成功信息包括所述电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

获取模块402，具体用于通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

根据划动操作轨迹获取电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

获取模块402，具体用于通过业务审批界面所包括的手写签名区域，接收并展示第一划动操作轨迹；

若接收到轨迹清除指令，则响应于轨迹清除指令，并在手写签名区域上清除第一划动操作轨迹；

当通过手写签名区域接收第二划动操作轨迹时，展示第二划动操作轨迹；

获取模块402，具体用于根据第二划动操作轨迹获取电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，客户端40还包括确定模块405；

接收模块404，还用于在获取模块402根据划动操作轨迹获取电子签名之后，通过业务审批界面接收签名复用指令，其中，签名复用指令携带签名复用标识，签名复用标识用于表示至少一个业务审批信息使用电子签名；

确定模块405，用于响应于签名复用指令，确定第二业务审批信息使用电子签名，其中，第二业务审批信息属于至少一个业务审批信息中的任意一个业务审批信息；

发送模块403，还用于若第二业务审批信息满足信息审批条件，则向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

接收模块404，还用于若电子签名鉴权通过，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

获取模块402，具体用于若检测到签名复用标识，则启动图像采集装置；

通过图像采集装置采集业务审批者的人脸图像；

向服务器发送人脸图像；

若人脸图像与目标人脸图像匹配成功，则接收服务器发送的电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

获取模块402，具体用于若检测到签名复用标识，则启动语音采集装置；

通过语音采集装置采集业务审批者的声纹数据；

向服务器发送声纹数据；

若声纹数据与目标声纹数据匹配成功，则接收服务器发送的电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

获取模块402，具体用于若检测到签名复用标识，则通过指纹采集装置采集业务审批者的指纹数据；

若指纹数据与目标指纹数据匹配成功，则从本地图片集合中获取电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

接收模块404，还用于获取模块402获取电子签名之后，通过业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

获取模块402，还用于根据划动操作轨迹获取更新后的电子签名；

发送模块403，具体用于若存在签名备案记录，则向服务器发送更新后的电子签名，以使服务器根据备案电子签名对更新后的电子签名进行鉴权操作。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

发送模块403，还用于在获取模块402获取电子签名之后，若不存在签名备案记录，则向服务器发送电子签名，以使服务器根据历史电子签名的笔迹对电子签名的笔迹进行匹配，得到匹配相似度；

接收模块404，还用于若匹配相似度大于或等于相似度阈值，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

可选地，在上述图21所对应的实施例的基础上，本申请实施例提供的客户端40的另一实施例中，

展示模块401，还用于若第一业务审批信息满足信息审批条件，则通过业务申请界面展示审批成功信息，其中，业务申请界面展示有备注区域；

接收模块404，还用于通过业务申请界面所包括的备注区域接收备注信息；

发送模块403，还用于若备注信息中包括用户关联标识，则根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息；

展示模块401，还用于若第一业务审批信息不满足信息审批条件，则通过业务申请界面展示审批失败信息；

接收模块404，还用于通过业务申请界面所包括的备注区域接收备注信息；

发送模块403，还用于若备注信息中包括用户关联标识，则根据用户关联标识向服务器发送消息提示请求，以使的服务器向用户关联标识所对应的客户端发送备注信息。

下面对本申请中的第二客户端进行详细描述，请参阅图22，图22为本申请实施例中客户端的一个实施例示意图，客户端50包括：

获取模块501，用于获取业务审批信息；

接收模块502，用于若业务审批信息满足信息审批条件，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名生成的，电子签名为根据划动操作轨迹生成的；

展示模块503，用于通过业务申请界面展示审批成功信息。

可选地，在上述图22所对应的实施例的基础上，本申请实施例提供的客户端50的另一实施例中，

接收模块502，具体用于向服务器发送图片下载请求，其中，图片下载请求携带签名图片所对应的文件标识以及操作者的身份票据信息；

若身份票据信息为合法信息，则接收服务器发送的目标链接地址；

根据目标链接地址从服务器中下载签名图片；

根据所述签名图片获取电子签名；

接收服务器发送的业务审批信息以及审批关联信息，其中，业务审批信息以及审批关联信息属于审批成功信息；

展示模块503，具体用于通过业务申请界面展示电子签名、业务审批信息以及审批关联信息。

下面对本申请中的第三客户端进行详细描述，请参阅图23，图23为本申请实施例中客户端的一个实施例示意图，客户端60包括：

展示模块601，用于展示审批配置界面；

获取模块602，用于通过审批配置界面获取附加签名指令，其中，附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的；

确定模块603，用于响应于附加签名指令，确定由客户端执行上述实施例的业务审批方法。

本申请实施例还提供了另一种图像显示控制装置，如图24所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端设备可以为包括手机、平板电脑、个人数字助理(personal digital assistant，PDA)、销售终端设备(point of sales，POS)、车载电脑等任意终端设备，以终端设备为手机为例：

图24示出的是与本申请实施例提供的终端设备相关的手机的部分结构的框图。参考图24，手机包括：射频(radio frequency，RF)电路710、存储器720、输入单元730、显示单元740、传感器750、音频电路760、无线保真(wireless fidelity，WiFi)模块770、处理器780、以及电源790等部件。本领域技术人员可以理解，图24中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图24对手机的各个构成部件进行具体的介绍：

RF电路710可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器780处理；另外，将设计上行的数据发送给基站。通常，RF电路710包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noiseamplifier，LNA)、双工器等。此外，RF电路710还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystem of mobile communication，GSM)、通用分组无线服务(general packet radioservice，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband code division multiple access，WCDMA)、长期演进(long term evolution，LTE)、电子邮件、短消息服务(short messaging service，SMS)等。

存储器720可用于存储软件程序以及模块，处理器780通过运行存储在存储器720的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器720可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器720可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元730可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元730可包括触控面板731以及其他输入设备732。触控面板731，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板731上或在触控面板731附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板731可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器780，并能接收处理器780发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板731。除了触控面板731，输入单元730还可以包括其他输入设备732。具体地，其他输入设备732可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元740可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元740可包括显示面板741，可选的，可以采用液晶显示器(liquid crystaldisplay，LCD)、有机发光二极管(organic light-emitting diode，OLED)等形式来配置显示面板741。进一步的，触控面板731可覆盖显示面板741，当触控面板731检测到在其上或附近的触摸操作后，传送给处理器780以确定触摸事件的类型，随后处理器780根据触摸事件的类型在显示面板741上提供相应的视觉输出。虽然在图24中，触控面板731与显示面板741是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板731与显示面板741集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器750，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板741的亮度，接近传感器可在手机移动到耳边时，关闭显示面板741和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路760、扬声器761，传声器762可提供用户与手机之间的音频接口。音频电路760可将接收到的音频数据转换后的电信号，传输到扬声器761，由扬声器761转换为声音信号输出；另一方面，传声器762将收集的声音信号转换为电信号，由音频电路760接收后转换为音频数据，再将音频数据输出处理器780处理后，经RF电路710以发送给比如另一手机，或者将音频数据输出至存储器720以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块770可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图24示出了WiFi模块770，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器780是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器720内的软件程序和/或模块，以及调用存储在存储器720内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器780可包括一个或多个处理单元；可选的，处理器780可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器780中。

手机还包括给各个部件供电的电源790(比如电池)，可选的，电源可以通过电源管理系统与处理器780逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端设备所包括的处理器780还具有以下功能：

通过业务审批界面展示第一业务审批信息；

若第一业务审批信息满足信息审批条件，则获取电子签名，其中，电子签名为根据划动操作轨迹生成的；

若存在签名备案记录，则向服务器发送电子签名，以使服务器根据备案电子签名对电子签名进行鉴权操作；

若电子签名鉴权通过，则接收服务器发送的审批成功信息，其中，审批成功信息包括电子签名。

在本申请实施例中，该终端设备所包括的处理器780还具有以下功能：

展示审批配置界面；

通过审批配置界面获取附加签名指令，其中，附加签名指令用于请求针对业务审批信息添加电子签名的操作，电子签名为根据划动操作轨迹生成的；

响应于附加签名指令，确定由客户端执行如上述实施例的业务审批方法。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如前述各个实施例描述的基于电子签名的业务审批方法。

本申请实施例中还提供一种包括程序的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例描述的基于电子签名的业务审批方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种基于电子签名的业务审批方法，其特征在于，包括：

通过业务审批界面展示第一业务审批信息；

若所述第一业务审批信息满足信息审批条件，则获取电子签名，其中，所述电子签名为根据划动操作轨迹生成的；

若存在签名备案记录，则向服务器发送所述电子签名，以使所述服务器根据备案电子签名对所述电子签名进行鉴权操作；

若所述电子签名鉴权通过，则接收所述服务器发送的审批成功信息，其中，所述审批成功信息包括所述电子签名。

2.根据权利要求1所述的业务审批方法，其特征在于，所述获取电子签名，包括：

通过所述业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

根据所述划动操作轨迹获取所述电子签名。

3.根据权利要求2所述的业务审批方法，其特征在于，所述通过所述业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹，包括：

通过所述业务审批界面所包括的手写签名区域，接收并展示第一划动操作轨迹；

若接收到轨迹清除指令，则响应于所述轨迹清除指令，并在所述手写签名区域上清除所述第一划动操作轨迹；

当通过所述手写签名区域接收第二划动操作轨迹时，展示所述第二划动操作轨迹；

所述根据所述划动操作轨迹获取所述电子签名，包括：

根据所述第二划动操作轨迹获取所述电子签名。

4.根据权利要求2所述的业务审批方法，其特征在于，所述根据所述划动操作轨迹获取所述电子签名之后，所述方法还包括：

通过所述业务审批界面接收签名复用指令，其中，所述签名复用指令携带签名复用标识，所述签名复用标识用于表示至少一个业务审批信息使用所述电子签名；

响应于所述签名复用指令，确定第二业务审批信息使用所述电子签名，其中，所述第二业务审批信息属于所述至少一个业务审批信息中的任意一个业务审批信息；

若所述第二业务审批信息满足所述信息审批条件，则向所述服务器发送所述电子签名，以使所述服务器根据所述备案电子签名对所述电子签名进行鉴权操作；

若所述电子签名鉴权通过，则接收所述服务器发送的审批成功信息，其中，所述审批成功信息包括所述电子签名。

5.根据权利要求1所述的业务审批方法，其特征在于，所述获取电子签名，包括：

若检测到签名复用标识，则启动图像采集装置；

通过所述图像采集装置采集业务审批者的人脸图像；

向所述服务器发送所述人脸图像；

若所述人脸图像与目标人脸图像匹配成功，则接收所述服务器发送的所述电子签名。

6.根据权利要求1所述的业务审批方法，其特征在于，所述获取电子签名，包括：

若检测到签名复用标识，则启动语音采集装置；

通过所述语音采集装置采集业务审批者的声纹数据；

向所述服务器发送所述声纹数据；

若所述声纹数据与目标声纹数据匹配成功，则接收所述服务器发送的所述电子签名。

7.根据权利要求1所述的业务审批方法，其特征在于，所述获取电子签名，包括：

若检测到签名复用标识，则通过指纹采集装置采集业务审批者的指纹数据；

若所述指纹数据与目标指纹数据匹配成功，则从本地图片集合中获取所述电子签名。

8.根据权利要求5至7中任一项所述的业务审批方法，其特征在于，所述获取电子签名之后，所述方法还包括：

通过所述业务审批界面所包括的手写签名区域，接收并展示划动操作轨迹；

根据所述划动操作轨迹获取更新后的电子签名；

所述若存在签名备案记录，则向服务器发送所述电子签名，以使所述服务器根据备案电子签名对所述电子签名进行鉴权操作，包括：

若存在所述签名备案记录，则向所述服务器发送所述更新后的电子签名，以使所述服务器根据所述备案电子签名对所述更新后的电子签名进行鉴权操作。

9.根据权利要求1所述的业务审批方法，其特征在于，所述获取电子签名之后，所述方法还包括：

若不存在所述签名备案记录，则向所述服务器发送所述电子签名，以使所述服务器根据历史电子签名的笔迹对所述电子签名的笔迹进行匹配，得到匹配相似度；

若所述匹配相似度大于或等于相似度阈值，则接收所述服务器发送的所述审批成功信息，其中，所述审批成功信息包括所述电子签名。

10.根据权利要求1所述的业务审批方法，其特征在于，所述方法还包括：

若所述第一业务审批信息满足所述信息审批条件，则通过业务申请界面展示所述审批成功信息，其中，所述业务申请界面展示有备注区域；

通过所述业务申请界面所包括的所述备注区域接收备注信息；

若所述备注信息中包括用户关联标识，则根据所述用户关联标识向所述服务器发送消息提示请求，以使所述的服务器向所述用户关联标识所对应的客户端发送所述备注信息；

所述方法还包括：

若所述第一业务审批信息不满足所述信息审批条件，则通过所述业务申请界面展示审批失败信息；

通过所述业务申请界面所包括的所述备注区域接收备注信息；

若所述备注信息中包括用户关联标识，则根据所述用户关联标识向所述服务器发送消息提示请求，以使所述的服务器向所述用户关联标识所对应的客户端发送所述备注信息。

11.一种基于电子签名的业务审批方法，其特征在于，包括：

展示审批配置界面；

通过所述审批配置界面获取附加签名指令，其中，所述附加签名指令用于请求针对业务审批信息添加电子签名的操作，所述电子签名为根据划动操作轨迹生成的；

响应于所述附加签名指令，确定由客户端执行如上述权利要求1至10中任一项所述的业务审批方法。

12.一种客户端，其特征在于，包括：

展示模块，用于通过业务审批界面展示第一业务审批信息；

获取模块，用于若所述第一业务审批信息满足信息审批条件，则获取电子签名，其中，所述电子签名为根据划动操作轨迹生成的；

发送模块，用于若存在签名备案记录，则向服务器发送所述电子签名，以使所述服务器根据备案电子签名对所述电子签名进行鉴权操作；

接收模块，用于若所述电子签名鉴权通过，则接收所述服务器发送的审批成功信息，其中，所述审批成功信息包括所述电子签名。

13.一种客户端，其特征在于，包括：

展示模块，用于展示审批配置界面；

获取模块，用于通过所述审批配置界面获取附加签名指令，其中，所述附加签名指令用于请求针对业务审批信息添加电子签名的操作，所述电子签名为根据划动操作轨迹生成的；

确定模块，用于响应于所述附加签名指令，确定由客户端执行如上述权利要求1至10中任一项所述的业务审批方法。

14.一种终端设备，其特征在于，包括：存储器、收发器、处理器以及总线系统；

其中，所述存储器用于存储程序；

所述处理器用于执行所述存储器中的程序，所述处理器用于根据所述程序代码中的指令执行如权利要求1至10中任一项所述的方法，或，执行如权利要求11所述的方法；

所述总线系统用于连接所述存储器以及所述处理器，以使所述存储器以及所述处理器进行通信。

15.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至10中任一项所述的方法，或，执行如权利要求11所述的方法。

Images