业务申请的处理方法、装置、设备及计算机可读存储介质

本申请实施例涉及通信技术领域，尤其涉及一种业务申请的处理方法、装置、设备及计算机可读存储介质。

目前，在很多业务申请的场景中，需要用户填写资料并上传一些资料，但往往由于网络或其他等原因会导致业务申请发生中断。在业务申请发生中断后，用户再次进入业务申请，之前填写的资料和上传的资料都需要再重新填写和上传一次，导致业务申请耗时，且业务申请的效率低。

本申请实施例提供一种业务申请的处理方法、装置、设备及计算机可读存储介质，以提高业务申请的效率。

第一方面，本申请实施例提供一种业务申请的处理方法，包括：响应于用户通过客户端触发业务申请，建立标识信息；记录所述业务申请的状态信息，并与所述标识信息关联，所述业务申请的状态信息包括所述业务申请的各个流程步骤是否完成；响应于所述用户在所述业务申请发生中断后重新触发所述业务申请，基于所述标识信息确定所述业务申请的最新状态信息；基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端。

第二方面，本申请实施例提供一种业务申请的处理装置，包括：建立模块，用于响应于用户通过客户端触发业务申请，建立标识信息；记录及关联模块，用于记录所述业务申请的状态信息，并与所述标识信息关联，所述业务申请的状态信息包括所述业务申请的各个流程步骤是否完成；第一确定模块，用于响应于所述用户在所述业务申请发生中断后重新触发所述业务申请，基于所述标识信息确定所述业务申请的最新状态信息；第二确定模块，用于基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端。

第三方面，本申请实施例提供一种业务申请的处理设备，包括：

存储器；

处理器；

通讯接口；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现第一方面所述的方法。

本申请实施例提供的一种业务申请的处理方法、装置、设备及计算机可读存储介质，通过响应于用户通过客户端触发业务申请，建立标识信息；记录所述业务申请的状态信息，并与所述标识信息关联，所述业务申请的状态信息包括所述业务申请的各个流程步骤是否完成；响应于所述用户在所述业务申请发生中断后重新触发所述业务申请，基于所述标识信息确定所述业务申请的最新状态信息；基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端。由于建立了标识信息，因此，在业务申请过程中各个流程步骤是否申请完成都会与该标识信息绑定并存储在数据库中，而用户在业务申请过程中发生申请中断且重新进入业务申请时，可以通过标识信息确定业务申请的最新状态信息，从而进入相应的流程步骤，继续进行业务申请。

图1为本申请实施例提供的业务申请系统的示意图；

图2为本申请实施例提供的业务申请的处理方法流程图；

图3为本申请实施例提供的业务申请的处理装置的结构示意图；

图4为本申请实施例提供的业务申请的处理设备的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

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

本申请实施例提供的业务申请的处理方法，可以适用于图1所示的业务申请系统。如图1所示，该业务申请系统包括：客户端11、第一服务器12、第二服务器13和数据库服务器14。其中，客户端11是用户所在端，例如，电脑、IPAD、智能手机等终端设备，用户可以通过客户端11进行业务申请，例如理赔申请。客户端11与第二服务器13通信连接，第一服务器12上安装有网络文件系统(Network File System，NFS)，第二服务器13与第一服务器12通信连接，第二服务器13可以是多个。则当用户在某一台第二服务器13上发起了一个理赔申请时，关于该理赔申请的资料中的结构化数据存储在了数据库服务器14中，第二服务器13上存储的图片等需要较大存储空间的文件资料，实际上是存储在第一服务器12的NFS上了，其他的第二服务器13也同时可以看到该用户上传的文件资料。

在一个典型的应用场景中，业务申请可以是理赔申请。对于理赔申请而言，可以划分为三个步骤：

(1)填写报案资料。例如，通过填写的姓名等信息，查询该用户拥有的保单。

(2)上传资料。根据用户拥有的保单及申请理赔的类型，生成不同的导入项目。例如，申请住院费用理赔，需要提供入院出院证明和费用明细；申请意外伤残理赔，需要提供事故证明和伤残鉴定。用户上传全部资料后，进入案件审核环节。

(3)审核结果。如果用户提交的理赔申请不符合基本条件，审核结果可能是不予立案；如果资料不全或者不清晰，审核结果是“补充资料”，流程回到“上传资料”环节；如果同意赔付，则计算出赔付金额，将理赔款支付到用户提供的账户里面；如果拒赔，则进行提示。

在上述的理赔申请过程中，目前主要存在以下几个问题：

a、用户需要上传的资料很多，由于每个文件平均有几兆，导致上传的文件比较大，有可能在传上几张文件后，某一张出现卡顿。用户在重新登录后，需要再次上传已上传过的资料。

b、系统通用的架构是多台服务器同时提供服务，具体到每个用户操作，仅能对应一台服务器，上传的资料仅保存在其中一台服务器上。如果用户重新申请理赔，那么对应的服务器很大概率不是原来的服务器，已经上传的资料不见，用户还要重新来。

c、用户理赔申请时，虽然有登录，但是仅仅在全部资料上传成功并且后台处理成功，理赔申请才算成功，用户才能在系统中查询到这次申请。而假如用户将全部资料都上传成功但后台处理未成功，则会提示用户再次上传资料，导致用户体验度不高。

本申请实施例提供的业务申请的处理方法，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的业务申请的处理方法流程图。本申请实施例针对现有技术的如上技术问题，提供了业务申请的处理方法，该方法具体步骤如下：

步骤201、响应于用户通过客户端触发业务申请，建立标识信息。

如图1所示，可以在客户端11上部署理赔申请系统的相关程序，则用户可以通过账号和密码登录进入理赔申请系统，并填写报案信息，例如姓名、身份证号码等信息，进而理赔申请系统会根据姓名和身份证号码查询该用户名下的所有保单，并根据用户的所有保单和申请理赔的类型，生成不同的导入项目，例如，申请理赔的类型为住院费用理赔，则需要用户上传入院出院证明和费用明细等材料；申请理赔的类型为意外伤残理赔，则需要用户提供事故证明和伤残鉴定等材料。

可选的，可以是用户通过账号和密码登录进入理赔申请系统，并填写报案信息，进而理赔申请系统会根据姓名和身份证号码查询该用户名下的所有保单，并根据用户的所有保单和申请理赔的类型，生成不同的导入项目之后，在数据库中为该用户发起的理赔申请建立标识信息，该标识信息用于唯一标识该用户发起理赔申请。其中，标识信息可以使用数据库中某个序列的顺序号，例如“000025”。

步骤202、记录业务申请的状态信息，并与标识信息关联，该业务申请的状态信息包括业务申请的各个流程步骤是否完成。

可选的，业务申请可以包括多个流程步骤，例如，报案信息的填写，上传资料、立案等。在实际使用时，具体的流程步骤可以参见实际的理赔申请业务的具体设置，本申请在此不做限定。

例如，用户在通过账号和密码登录进入理赔申请系统，并填写报案信息之后，则会在数据库中标识信息“000025”下，写入报案信息填写完成；进一步的，用户在上传资料时，则又会继续在数据库的标识信息“000025”下，写入上传资料中；如果资料上传完成，则又会继续在数据库的标识信息“000025”下，写入资料上传完成。而在用户上传资料时，又可以有多条状态信息，例如用户需要上传资料1、资料2和资料3，则资料1、资料2和资料3会分别对应有一条状态信息，例如，资料1上传完成，资料2上传完成，资料3上传完成。可选的，若用户在理赔申请过程中，完成了资料1和资料2的上传，在上传资料3时，由于网络卡顿或者用户不小心点击了退出导致申请中断，且资料3未上传成功，则会在数据库的标识信息“000025”下记录资料3的状态信息为上传失败。

步骤203、响应于用户在业务申请发生中断后重新触发业务申请，基于标识信息确定业务申请的最新状态信息。

可选的，业务申请发生中断是指由于网络卡顿或者用户不小心点击退出等原因造成理赔申请未完成。

例如，在上传资料3时，由于网络卡顿导致理赔申请中断，且资料3未上传成功，则数据库的标识信息“000025”下会记录资料3的状态信息为上传失败。进一步的，用户可以重新通过账号和密码登录理赔申请系统来触发该理赔申请，由于该用户的账号和标识信息之间具有关联关系，因此，可以获取到该标识信息，从而确定该标识信息下记录的关于该理赔申请的最新状态信息，例如资料3上传失败。

步骤204、基于最新状态信息，确定对应的流程步骤以提供给客户端。

可选的，在确定了该标识信息下记录的关于该理赔申请的最新状态信息后，则可以确定对应的流程步骤，并提供给用户所在的客户端，例如以页面的形式显示给用户所在的客户端。

本申请实施例通过响应于用户通过客户端触发业务申请，建立标识信息；记录所述业务申请的状态信息，并与所述标识信息关联，所述业务申请的状态信息包括所述业务申请的各个流程步骤是否完成；响应于所述用户在所述业务申请发生中断后重新触发所述业务申请，基于所述标识信息确定所述业务申请的最新状态信息；基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端。由于建立了标识信息，因此，在业务申请过程中各个流程步骤是否申请完成都会与该标识信息绑定并存储在数据库中，而用户在业务申请过程中发生申请中断且重新进入业务申请时，可以通过标识信息确定业务申请的最新状态信息，从而进入相应的流程步骤，继续进行业务申请。

可选的，响应于用户通过客户端触发业务申请，建立标识信息之前，本申请实施例的方法还包括：设置安装有网络文件系统的第一服务器，和用于提供业务申请的两个第二服务器，两个第二服务器能够共享网络文件系统；在接收到用户通过客户端上传的业务申请的相关资料时，将业务申请的相关资料存储至客户端当前通信的第二服务器上。

可选的，所述在接收到所述用户通过客户端上传的所述业务申请的相关资料时，将所述业务申请的相关资料发送至所述客户端当前通信的所述第二服务器以进行存储，包括：在接收到所述用户通过客户端上传的所述业务申请的相关资料时，确定所述业务申请的相关资料中属于预设格式类型的资料；将所述属于预设格式类型的资料发送至所述客户端当前通信的所述第二服务器以进行存储。其中，预设格式包括各种图片的格式，例如jpg、jpeg、png等等。

可选的，在接收到所述用户通过客户端上传的所述业务申请的相关资料时，将业务申请的相关资料发送至所述客户端当前通信的所述第二服务器以进行存储，包括：在接收到所述用户通过客户端上传的所述业务申请的相关资料时，确定所述业务申请的相关资料中所需的存储空间大于预设存储空间的资料；将所述大于预设存储空间的资料发送至所述客户端当前通信的所述第二服务器以进行存储。例如，可以根据经常会发生中断的业务申请的资料来确定预设存储空间。若在业务申请中，经常遇到上传某一大小的资料时，发生中断，则可以根据多次历史数据中该资料所需的存储空间确定一个预设存储空间。

可选的，基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端，包括：若基于最新状态信息，确定对应的流程步骤为需要上传资料的流程步骤，且最新状态信息为上传资料失败，则接收用户通过客户端重新上传的关于该流程步骤的相关资料，并存储至与客户端通信的第二服务器上。

可选的，基于最新状态信息，确定对应的流程步骤以提供给客户端，包括：若基于最新状态信息，确定对应的流程步骤为需要上传资料的流程步骤，且最新状态信息为上传资料失败，则切换与客户端通信的第二服务器，接收所述用户通过客户端重新上传的关于该流程步骤的相关资料，并存储至切换后的第二服务器上。

如图1所示，第一服务器12的容量大于第二服务器13，具体可以通过为第一服务器12安装Linux操作系统，并启动NFS的协议，从而为第二服务器13提供文件共享服务。第二服务器13为用户提供理赔服务。在本实施例中，第一服务器12可以认为相当于一个“共享盘”，而第二服务器13可以认为是第一服务器12的“客户端”，与第一服务器12通信连接。在一个具体的示例中，将两个第二服务器分别记为第二服务器A和第二服务器B，第二服务器A和第二服务器B同时连接同一数据库，用户在理赔申请时，用户所在的客户端11首先连接的是第二服务器A，则用户在理赔申请过程中上传的资料会存储在第二服务器A当中，如果资料1和资料2均上传成功，则会在数据库当中的“000025”下记录资料1的状态信息为上传成功，资料2的状态信息为上传成功。如果在上传资料3的时候，网络发生了异常导致资料3上传失败，则会记录资料3的状态信息为上传失败。此时，若用户通过账号和密码再次登录理赔申请系统后，根据负载均衡原理，用户所在的客户端11在很大概率上不再与第二服务器A连接，而是切换至与第二服务器B连接，而由于第二服务器A和第二服务器B共享第一服务器12，因此，用户即使切换至第二服务器B，依然能够继续上传资料，而不需要重新上传。

可选的，在接收到用户通过客户端上传的业务申请的相关资料时，将业务申请的相关资料存储至客户端当前通信的第二服务器上之后，本申请实施例的方法还包括：每间隔预设时间扫描各个所述第二服务器上存储的所述业务申请的相关资料以及所述业务申请的状态信息；在检测到业务申请的相关资料已上传且后台对业务申请的相关资料处理失败时，自动对业务申请的相关资料进行相应处理。例如，在理赔申请的流程中，用户上传的资料通常为图片，且后台在用户上传图片成功后，还要做图片压缩、生成PDF文件、发送至影像系统等一系列操作。现有技术中，当用户点击上传图片后，即使图片已经上传成功，然而用户还必须等待后台做图片压缩等一系列操作，后台如果操作失败，也会发送提示信息给用户，要求用户必须重传该图片。本实施例是建立了“自动轮询”机制。即对于每台第二服务器，每间隔预设时间，例如每间隔2分钟自动对比数据库的理赔申请和共享盘中的文件，判断是否有用户上传成功而后台处理失败的情况，如果有该情况发生，则后台自动重新启动图片压缩、合成PDF等操作。由此，当用户在将图片上传成功后，不再需要等待后台的处理操作，如果后台处理失败，也不会发送提示信息给用户，提高了理赔效率，以及提升了用户体验。

下面通过一个完整的示例对本申请实施例进行详细说明：请继续参考图1，该示例流程具体如下：

(1)安装一台Linux操作系统的第一服务器12，假设IP地址为192.168.1.100。

(2)第一服务器12上，启动NFS文件共享服务，并将/data目录设置为共享目录。

(3)安装4台Linux操作系统的第二服务器13，编号分别为A-D，分别采用Tomcat应用服务器，并部署通用理赔的程序及“自动轮询”程序。通用理赔的程序和“自动轮询”程序，均访问集中的一台数据库服务器14。

(4)第二服务器A-D上，执行mount-t nfs 192.168.1.100:/data/mnt/data，即将本地的一个目录/mnt/data的目录，指向了第一服务器12。则在第二服务器13上的/mnt/data目录下保存一个文件，实际上保存到了第一服务器12上，并且能自动被第二服务器B、C、D同时查询到。

通过上述4个步骤，安装环境搭建完毕，下面通过一个用户的访问过程来描述本申请实施例的具体实施过程。

(1)用户“张三”，通过注册名zhangsan，通过客户端11登录通用理赔系统，发起一项“报案”。

(2)为注册名为zhangsan的用户“张三”自动分配一个标识信息，例如案件号，该案件号可以使用数据库服务器14中某个序列的顺序号，假设自动为用户“张三”分配案件号为000025。

(3)张三在理赔申请的页面中填写报案信息，同时，数据库服务器14中会产生一条标识信息为000025的理赔申请信息。需要说明的是，在传统的理赔申请中，用户需要先报案，待同意立案之后才有“案件号”，而用户报案及上传资料等一系列操作属于报案过程，这时候没有立案，也就没有案件号产生。而本申请实施例将从用户报案开始一系列操作，视为一个流程，先产生“案件号”，并增设填写报案信息、资料上传中、上传完成资料、立案成功等一系列状态。

(4)张三点击下一页，该页面提示张三上传身份证、银行卡、住院记录等资料。

(5)第二服务器13，接收到张三上传的资料后，在/mnt/data目录下创建000025目录，如果张三上传身份证成功，则身份证图片保存到/mnt/data/000025目录，并且数据库服务器14的000025标识信息下会记录状态信息为“已经上传身份证”。

(6)张三继续上传资料，当上传到住院记录的时候，由于网络较慢，不小心点击了退出。张三重新登录后，切换至与第二服务器B连接，则张三当前访问的第二服务器是第二服务器B。进一步的，根据注册名zhangsan在数据库中到000025这一标识信息对应的理赔申请信息，并获取到最新的状态信息是“已经完成身份证上传”，张三继续上传住院资料，这时候由于共享盘的机制，第二服务器B的/mnt/data/000025目录，与第二服务器A上面访问的/mnt/data/000025的内容完全一样。

(7)张三继续上传资料，有一张图片是需要从手机中选取的，该图片比手机拍摄的还要大，正常上传成功后，后台继续压缩并合成PDF，但由于图片较大，出现了内存溢出，合成失败。本申请实施例改变了以往的处理方法，不发送这个错误的提示信息给用户，而是提示用户已上传成功。

(8)“轮询系统”在2分钟后扫描到了标识信息为000025的理赔申请记录和/mnt/data/000025下的文件，发现有一条未合成的PDF，则后台自动重新启动合成，直至合成成功。从而实现基于“案件号”重试后台处理失败的图片，而不是让用户反复上传。

图3为本申请实施例提供的业务申请的处理装置的结构示意图。该业务申请的处理装置具体可以是上述实施例中的业务申请系统10。本申请实施例提供的业务申请的处理装置可以执行业务申请的处理方法实施例提供的处理流程，如图3所示，业务申请的处理装置30包括：建立模块31、记录及关联模块32、第一确定模块33和第二确定模块34；其中，建立模块31，用于响应于用户通过客户端触发业务申请，建立标识信息；记录及关联模块32，用于记录所述业务申请的状态信息，并与所述标识信息关联，所述业务申请的状态信息包括所述业务申请的各个流程步骤是否完成；第一确定模块33，用于响应于所述用户在所述业务申请发生中断后重新触发所述业务申请，基于所述标识信息确定所述业务申请的最新状态信息；第二确定模块34，用于基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端。

可选的，该系统还包括：设置模块35、发送模块36；其中，设置模块35，用于设置安装有网络文件系统的第一服务器，和用于提供所述业务申请的第二服务器，所述第二服务器能够共享所述网络文件系统；发送模块36，用于在接收到所述用户通过客户端上传的所述业务申请的相关资料时，将所述业务申请的相关资料发送至所述客户端当前通信的所述第二服务器以进行存储。

可选的，所述发送模块36在接收到所述用户通过客户端上传的所述业务申请的相关资料，将所述业务申请的相关资料发送至所述客户端当前通信的所述第二服务器以进行存储时，具体包括：在接收到所述用户通过客户端上传的所述业务申请的相关资料时，确定所述业务申请的相关资料中属于预设格式类型的资料；将所述属于预设格式类型的资料发送至所述客户端当前通信的所述第二服务器以进行存储。其中，预设格式包括各种图片的格式，例如jpg、jpeg、png等等。

可选的，所述发送模块36在接收到所述用户通过客户端上传的所述业务申请的相关资料时，将业务申请的相关资料发送至所述客户端当前通信的所述第二服务器以进行存储，包括：在接收到所述用户通过客户端上传的所述业务申请的相关资料时，确定所述业务申请的相关资料中所需的存储空间大于预设存储空间的资料；将所述大于预设存储空间的资料发送至所述客户端当前通信的所述第二服务器以进行存储。例如，可以根据经常会发生中断的业务申请的资料来确定预设存储空间。若在业务申请中，经常遇到上传某一大小的资料时，发生中断，则可以根据多次历史数据中该资料所需的存储空间确定一个预设存储空间。

可选的，第二确定模块34在基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端时，具体用于：若基于所述最新状态信息，确定对应的流程步骤为需要上传资料的流程步骤，且所述最新状态信息为上传资料失败，则接收所述用户通过所述客户端重新上传的关于该流程步骤的相关资料，并存储至与所述客户端通信的所述第二服务器上。

可选的，第二确定模块34在基于所述最新状态信息，确定对应的流程步骤以提供给所述客户端时，具体用于：若基于所述最新状态信息，确定对应的流程步骤为需要上传资料的流程步骤，且所述最新状态信息为上传资料失败，则切换与所述客户端通信的所述第二服务器，接收所述用户通过所述客户端重新上传的关于该流程步骤的相关资料，并存储至切换后的所述第二服务器上。

可选的，该系统还包括：扫描模块37和处理模块38；其中，扫描模块37，每间隔预设时间扫描各个所述第二服务器上存储的所述业务申请的相关资料以及所述业务申请的状态信息；处理模块38，用于在检测到所述业务申请的相关资料已上传且后台对所述业务申请的相关资料处理失败时，自动对所述业务申请的相关资料进行相应处理。

图3所示实施例的业务申请的处理装置可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图4为本申请实施例提供的业务申请的处理设备的结构示意图。本申请实施例提供的业务申请的处理设备可以执行业务申请的处理方法实施例提供的处理流程，如图4所示，业务申请的处理设备40包括：存储器41、处理器42、计算机程序和通讯接口43；其中，计算机程序存储在存储器41中，并被配置为由处理器42执行上述方法实施例的步骤。

图4所示实施例的业务申请的处理设备可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

另外，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的业务申请的处理方法。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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