一种任务审核方法、装置和系统与流程

本发明涉及计算机技术领域，尤其涉及一种任务审核方法、装置和系统。

背景技术：

目前，在进行保险理赔时，用户(被保险人)需自行整理与理赔项目相关的各种纸质理赔材料，然后将纸质理赔材料递交至其投保的保险公司，保险公司则根据用户提交的纸质理赔材料审核是否满足理赔条件。

由于用户并非专业人士，其准备的保险材料可能不完整或不规范，这将导致理赔失败，并需用户重新整理理赔材料后再重新审核，这不仅增加了理赔过程中用户的工作量，还将延长理赔时间。

技术实现要素：

有鉴于此，本发明实施例提供一种任务审核方法、装置和系统，能够缩短任务审核时间，并降低任务审核过程中的人为参与度，提高用户体验。

为实现上述目的，根据本发明实施例的一个方面，提供了一种任务审核方法。

本发明实施例的一种任务审核方法包括：

接收第一客户端发送的任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；

根据所述第一标识和所述待审核任务的类型，获取与所述待审核任务相关的所述用户的历史业务数据；

根据所述第二标识，将所述历史业务数据和所述待审核任务的类型发送至所述第二客户端，所述第二客户端根据所述历史业务数据和所述待审核任务的类型，对所述待审核任务进行审核；

将所述第二客户端的审核结果发送至所述第一客户端。

可选地，所述任务审核请求还包括：所述待审核任务对应的第一时间段和/或位置，所述获取所述用户对应的与所述待审核任务相关的历史业务数据，包括：

根据所述第一标识，获取所述用户在所述第一时间段内和/或所述位置生成的与所述待审核任务相关的历史业务数据。

可选地，该方法还包括：

根据所述待审核任务的类型确定所述待审核任务的审核条件，判断所述任务审核请求是否符合所述审核条件；

如果是，根据所述第一标识获取所述用户对应的审核数据，并将所述审核数据发送至所述第二客户端，以使所述第二客户端根据所述审核数据和所述历史业务数据对所述待审核任务进行审核。

可选地，

所述审核条件为所述任务审核请求包括的请求值大于预设阈值、和/或所述任务审核请求包括的第一时间段是否包含或部分包含于预设的与所述待审核任务相关的第二时间段内。

可选地，

当所述历史业务数据包括：业务项目以及所述业务项目对应的项目值时，还包括：

根据所述业务项目以及业务项目对应的项目值，计算所述待审核任务对应的审核值，并将所述审核值发送至所述第二客户端，以使所述第二客户端根据所述审核值对所述待审核任务进行审核。

可选地，当所述审核结果包括：所述历史业务数据不完整时，还包括：

向所述第一客户端发送数据补充提示，接收所述第一客户端发送的补充数据，并将所述补充数据发送至所述第二客户端，以使所述第二客户端根据所述补充数据以及所述历史业务数据，对所述待审核任务进行审核。

为实现上述目的，根据本发明实施例的又一方面，提供了一种任务审核装置。

本发明实施例的一种任务审核装置包括：请求接收模块、数据获取模块和处理模块；其中，

所述请求接收模块，用于接收第一客户端发送的任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；

所述数据获取模块，用于根据所述第一标识和所述待审核任务的类型，获取与所述待审核任务相关的所述用户的历史业务数据；

所述处理模块，用于根据所述第二标识，将所述历史业务数据和所述待审核任务的类型发送至所述第二客户端，以使所述第二客户端根据所述历史业务数据和所述待审核任务的类型，对所述待审核任务进行审核，并将所述第二客户端的审核结果发送至所述第一客户端。

为实现上述目的，根据本发明实施例的又一方面，提供了一种任务审核系统。

本发明实施例的一种任务审核系统包括：第一客户端、第二客户端和上述第二方面所述的任务审核装置；其中，

所述第一客户端，用于向所述任务审核装置发送任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；

所述第二客户端，用于根据所述任务审核装置发送的历史业务数据，按照待审核任务的类型对所述待审核任务进行审核，并将审核结果发送至所述任务审核装置；

所述任务审核装置，用于将所述审核结果发送至所述第一客户端。

为实现上述目的，根据本发明实施例的又一方面，提供了一种任务审核的电子设备。

本发明实施例的一种任务审核的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种任务审核的方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读存储介质。

本发明实施例的一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种任务审核的方法。

上述发明中的一个实施例具有如下优点或有益效果：在接收到第一客户端发送的任务审核请求后，可根据任务审核请求包括的用户的第一标识和待审核任务的类型，获取与待审核任务相关的用户的历史业务数据，然后根据任务审核请求包括的第二客户端的第二标识，将历史业务数据发送至第二客户端，使得第二客户端可根据历史业务数据对待审核任务进行审核，并将第二客户端的审核结果发送至第一客户端。由此，可根据任务审核请求自动获取与待审核任务相关的历史业务数据，并使得第二客户端可基于历史业务数据对待审核任务进行审核，从而无需用户整理业务材料，降低任务审核过程中的人为参与度，提高用户体验，并有利于提高任务审核时间。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的一种任务审核方法的主要步骤的示意图；

图2是根据本发明实施例的一种任务审核方法在第一客户端侧的主要步骤的示意图；

图3是根据本发明实施例的一种任务审核方法在第二户端侧的主要步骤的示意图；

图4是根据本发明实施例的另一种任务审核方法的主要步骤的示意图；

图5是根据本发明实施例的一种任务审核装置的主要模块的示意图；

图6是根据本发明实施例的一种任务审核系统的主要模块的示意图；

图7是本发明实施例可以应用于其中的示例性系统架构图；

图8是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

需要指出的是，在不冲突的情况下，本发明的实施例以及实施例中的技术特征可以相互结合。

图1是根据本发明实施例的一种任务审核方法的主要步骤的示意图。

如图1所示，本发明实施例的一种任务审核方法主要包括以下步骤：

步骤s101：接收第一客户端发送的任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型。

以待审核的任务为待审核的保险理赔任务为例，第一客户端为用户(被保险人)所使用的客户端，用户可通过第一客户端向任务审核装置发送任务审核请求，该任务审核请求即可对应保险理赔中针对某个保单(即某个保险项目)的理赔请求，该任务审核请求包括的用户的第一标识可以为用户的身份证号和/或医保卡号，还可以为用户的姓名和性别等其他标识信息，第二客户端的第二标识可以为用户所投保的保险公司对应的标识信息，待审核任务的类型可以为所申请理赔的保单对应的保险险种。

为了便于任务审核装置获取历史业务数据，以提高历史业务数据的获取效率，从而提高任务审核的效率，所述任务审核请求还可以包括所述待审核任务对应的第一时间段和/或位置，则在获取历史业务数据时，任务审核装置可根据第一标识，获取用户在第一时间段内和/或所述位置生成的与所述待审核任务相关的历史业务数据。

在此实施例中，用户在发送任务审核请求时，可通过任务审核请求携带待审核任务对应的第一时间段和/或位置，也就是说，使得任务审核请求中包括待审核任务对应的第一时间段和/或位置。例如，当待审核任务为医疗类保险理赔任务时，用户可在通过第一客户端发送任务审核请求时，携带其就医的时间段以及就诊医院，以便于任务审核装置根据该就医时间段和就诊医院获取用户的就诊数据。

用户在通过第一客户端发送任务审核请求时，用户首先可通过姓名、身份证号和医保卡号等注册信息登录第一客户端，可以理解的是，用户的注册信息已预先存储于任务审核装置中。用户在通过注册信息登录第一客户端后，第一客户端可与任务审核装置建立连接，使得任务审核装置可根据用户的注册信息查询用户的投保记录，并将用户对应的保单列表返回给第一客户端，使得用户可从第一客户端展示的保单列表中选择待理赔保单。

为了便于用户选择待审核任务，当同一用户向多个保险公司投保时，任务审核装置在向第一客户端返回保单列表时，可将各个保单按照保险公司进行排序，即将同一个保险公司的多个保单排列在一起，以便于用户按照保险公司对待理赔保单进行选择。可以理解的是，当用户选择了待理赔保单后，即确定了该待理赔保单对应的保险公司，也就确定了用于审核该保单的第二客户端，同时也确定了待审核任务的类型(医疗类或车险类等多种类型)。用户在选择待理赔保单之后，可进一步选择就诊时间段和就诊医院，然后第一客户端可根据用户的注册信息、用户所选择的待审核保单、就诊时间段和就诊医院等信息，向任务审核装置发送任务审核请求。

根据上述实施例，当待审核的任务为待审核的保险理赔任务时，如图2所示，用户通过第一客户端向任务审核装置发送任务审核请求的过程可包括以下步骤s201至步骤s204：

步骤s201：选择待理赔保单所对应的保险公司。

步骤s202：选择待理赔保单。

步骤s203：选择就诊时间段和就诊医院。

步骤s204：根据选择的保险公司、待理赔保单、就诊时间段和就诊医院，向任务审核装置提交理赔申请。

可以理解是，若用户在提交理赔申请时，还有其他附加材料，如在申请生育保险类保单的理赔时，可主动提供结婚证和出生证明等附加材料。

步骤s102：根据所述第一标识和所述待审核任务的类型，获取与所述待审核任务相关的所述用户的历史业务数据。

仍以待审核任务为医疗类保险理赔任务为例，任务审核装置在获取历史业务数据(即用户的历史就诊数据)时，可根据用户的身份证号和/或医保卡号从就诊医院对应的数据库或自身系统维护的数据中获取相关的历史业务数据。当任务审核请求中包括就诊时间段和/或就诊医院时，可根据就诊时间段和/或就诊医院获取用户相应的就诊数据。

当任务审核装置从自身系统维护的数据中获取用户的就诊数据时，可直接拉取数据；当任务审核装置从就诊医院对应的数据库中获取就诊数据时，可调取就诊医院提供的外部接口，根据调取的外部接口获取相应的就诊数据，该就诊数据可以包括病因、住院费、住院明细、药品明细、药品费用、门诊明细和门诊费用以及费用合计等。可以理解的是，当任务审核请求未包括就诊医院时，任务审核装置可根据各个医院的外部接口，获取用户在不同医院的就诊数据。

另外，任务审核装置还可根据待审核任务的类型确定所述待审核任务的审核条件，并判断所述任务审核请求是否符合所述审核条件；如果是，根据所述第一标识获取所述用户的审核数据，并将所述审核数据发送至所述第二客户端，以使所述第二客户端根据所述审核数据和所述历史业务数据对所述待审核任务进行审核。其中，所述审核条件为所述任务审核请求包括的请求值大于预设阈值、和/或所述任务审核请求包括的第一时间段包含或部分包含于预设的与所述待审核任务相关的第二时间段内。

仍以待审核任务为医疗类保险理赔任务为例，任务审核装置确定的待理赔保单的审核条件可以为待理赔保单的风险校验条件，也就是说，可以根据该审核条件，校验用户提起的任务审核请求是否具有较高风险。

例如，医疗保单a的审核条件为理赔金额大于1万且理赔时间距投保时间小于3个月，也就是说，第二时间段为用户的投保时间至投保时间之后的3个月所对应的时间段。当第一客户端发送的任务审核请求是针对医疗保单a时，则任务审核装置可先判断任务审核请求所包括的请求值(理赔金额)是否大于1万或任务审核请求所包括的就诊时间段是否包含或部分包含于投保时间至投保时间之后3个月的时间段内，如果是，则说明该任务审核请求有较高风险，此时任务审核装置可根据用户的身份证号和/或医疗卡号获取用户对应的审核数据。

当待审核任务为医疗类保险理赔任务时，该审核数据可以为用户的历史就诊数据，该历史就诊数据可以为用户在任务审核请求所对应的就诊时间段之前就诊时所产生的就诊数据，例如，用户发送的任务审核请求对应的就诊时间段为2000年1月1日，那么用户对应的审核数据可以为用户在2000年1月1日之前就诊时所产生的就诊数据。也就是说，当任务审核请求符合审核条件时，任务审核装置不仅要获取对应于任务审核请求的历史业务数据，还需获取用户对应的审核数据，并将审核数据和历史业务数据均发送至第二客户端，使得第二客户端可以结合审核数据和历史业务数据对待审核任务进行审核，以提高任务审核的安全性，在保险理赔场景中，可降低保险欺诈等风险。

可以理解的是，用户的就诊时间段(第一时间段)可以为一天，也可以为多天，例如，用户选择的第一时间段可以为2000年1月1日这一天，也可以为包括2000年1月1日至2000年1月5日的多天。当就诊时间段为一天时，就诊时间仅存在包含或不包含于第二时间段两种情况。

当就诊时间段为多天时，例如就诊时间段包括2000年1月1日至2000年1月5日，第二时间段为2000年1月1日至2000年4月1日时，则就诊时间段包含于第二时间段。当就诊时间段包括2000年4月1日至2000年4月15日，第二时间段为2000年1月3日至2000年4月3日时，就诊时间段部分包含于第二时间段。当就诊时间段包括2000年5月15日至2000年6月1日，第二时间段为2000年2月1日至2000年5月1日时，就诊时间段不包含于第二时间段。

当然，当待审核任务不具有审核条件，也就说明待审核任务不需要进行风险校验，此时任务审核装置可仅获取与待审核任务相关的历史业务数据，而无需再获取用户对应的审核数据。另外，当任务审核请求不符合审核条件时，说明任务审核请求的风险较低，此时任务审核装置也可仅获取历史业务数据，而无需获取审核数据。

可以理解的是，审核条件可预先对应记录于用户所投保的保单中。另外，由于不同医院对应的历史业务数据的格式可能有所不同，为了便于第二客户端读取数据，任务审核装置还可对获取的历史业务数据的格式进行标准化，以将历史业务数据的格式转换成第二客户端便于读取的格式。

另外，当历史业务数据包括：业务项目以及所述业务项目对应的项目值时，任务审核装置还可根据所述业务项目以及业务项目对应的项目值，计算所述待审核任务对应的审核值，并将所述审核值发送至所述第二客户端，以使所述第二客户端根据所述审核值对所述待审核任务进行审核。

例如，当待审核任务为医疗类保险理赔任务时，历史业务数据即为用户的就诊数据，业务项目即为用户就诊时的项目，如住院项目、检查项目和各项药品等，业务项目对应的项目值即每项所对应的费用，任务审核装置可根据各个业务项目及其项目值以及待理赔保单上的理赔率，计算出待审核的审核值，该审核值即表示待理赔的金额，然后任务审核装置将计算出的审核值发送至第二客户端，从而便于第二客户端快速判断待理赔的金额是否正确，进而提高待审核任务的审核效率。

步骤s103：根据所述第二标识，将所述历史业务数据和所述待审核任务的类型发送至所述第二客户端，所述第二客户端根据所述历史业务数据和所述待审核任务的类型，对所述待审核任务进行审核。

步骤s104：将所述第二客户端的审核结果发送至所述第一客户端。

当任务审核装置根据第二客户端的第二标识，将历史业务数据发送至第二客户端后，第二客户端可根据历史业务数据对待审核任务进行审核。其中，任务审核装置与第二客户端之间可使用socket通信，当任务审核装置为服务器节点时可使用socket.io，第二客户端可使用websocket接收历史业务数据。

仍以待审核任务为医疗类保险理赔任务为例，在审核时，第二客户端可首先判断代理赔保单是否具有审核条件，如果有，则确定是否存在相应的审核数据，若不存在审核数据，则第二客户端通知任务审核装置获取相应的审核数据，若存在审核数据，则可结合审核数据和历史业务数据对待审核任务进行审核。例如，当审核数据为用户在任务审核请求所对应的就诊时间段之前，就诊时所产生的就诊数据时，而就诊数据是针对某种疾病的就诊记录，第二客户端可首先根据审核数据判断用户是否在就诊时间段之前甚至是投保时间之前就已对该种疾病进行过诊断或治疗，进而根据判断结果审核用户此次的就诊数据是否有理赔资格(也就是确定待审核任务是否可通过审核)。

进一步地，当第二客户端审核出历史业务数据不完整时，例如，待理赔保单为生育保险保单，而历史业务数据仅有用户的生产数据，而不存在出生证明等数据时，第二客户端可向任务审核装置发送历史业务数据不完整的审核结果。任务审核装置可根据审核结果，进一步获取缺失的历史业务数据，也可根据审核结果，向所述第一客户端发送数据补充提示，接收所述第一客户端发送的补充数据，并将所述补充数据发送至所述第二客户端，以使所述第二客户端根据所述补充数据以及所述历史业务数据，对所述待审核任务进行审核；其中，所述补充数据是所述用户根据所述数据补充提示所输入的。

例如，任务审核装置向第一客户端发送关于补充出生证明的补充提示，然后用户可根据该补充提示，通过第一客户端上传出生证明，然后第一客户端将用户补充的出生证明发送至任务审核装置，任务审核装置再将出生证明发送至第二客户端，使得第二客户端结合补充的出生证明以及生产数据，审核用户申请的生育保险是否可通过审核。

进一步地，第二客户端还可根据理赔规则和就诊数据中的各个项目值，计算出正确的理赔金额，并判断任务审核装置所发送的审核值是否与正确的理赔金额相等，如果是，则向任务审核装置发送审核通过的审核结果，任务审核装置可进一步将该审核结果转发给第一客户端，以通知发送理赔请求的用户。

根据上述实施例，如图3所示，第二客户端在对待审核任务的审核过程可以包括以下步骤：

步骤s301：接收任务审核装置发送的关于待审核任务的历史业务数据。

步骤s302：判断历史业务数据是否完整，如果是，执行步骤s304，否则执行步骤s303；

步骤s303：向任务审核装置发送历史业务数据不完整的审核结果，并执行步骤s301。

步骤s304：当根据待审核任务的类型确定出待审核任务的审核条件时执行步骤s305，否则执行步骤s307；

步骤s305：判断是否接收到用户对应的审核数据，如果是，执行步骤s306，否则执行步骤s308。

步骤s306：根据审核数据和完整的历史业务数据，对待审核任务进行审核，并将审核结果发送至任务审核装置，并结束当前流程。

步骤s307：根据完整的历史业务数据，对待审核任务进行审核，并将审核结果发送至任务审核装置，并结束当前流程。

步骤s308：向任务审核装置发送补充审核数据的提示，以使任务审核装置发送审核数据，并执行步骤s305。

可以理解的是，第二客户端所执行的任务的审核过程也可以是任务审核人员根据第二客户端所展示的历史业务数据和审核数据所进行的。也就是说，第二客户端侧的任务审核过程，既可以由第二客户端执行，也可以由任务审核人员来执行。

综上所述，如图4所示，本发明实施例提供的任务审核方法可以包括以下步骤：

步骤s401：第一客户端向任务审核装置发送任务审核请求。

该任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型。其中，第一客户端为用户使用的客户端，第二客户端为任务审核的人员所使用的客户端。

步骤s402：任务审核装置根据第一标识和待审核任务的类型，获取与待审核任务相关的历史业务数据。

步骤s403：任务审核装置根据第二标识，将历史业务数据发送至第二客户端。

步骤s404：第二客户端根据历史业务数据对待审核任务进行审核。

步骤s405：第二客户端将审核结果发送至任务审核装置。

步骤s406：任务审核装置将审核结果发送至第一客户端。

根据本发明实施例的任务审核方法可以看出，在接收到第一客户端发送的任务审核请求后，可根据任务审核请求包括的用户的第一标识和待审核任务的类型，获取与待审核任务相关的用户的历史业务数据，然后根据任务审核请求包括的第二客户端的第二标识，将历史业务数据发送至第二客户端，使得第二客户端可根据历史业务数据对待审核任务进行审核，并将第二客户端的审核结果发送至第一客户端。由此，可根据任务审核请求自动获取与待审核任务相关的历史业务数据，并使得第二客户端可基于历史业务数据对待审核任务进行审核，从而无需用户整理业务材料，降低任务审核过程中的人为参与度，提高用户体验，并有利于提高任务审核时间。

图5是根据本发明实施例的任务审核装置的主要模块的示意图。

如图5所示，本发明实施例的任务审核装置500包括：请求接收模块501、数据获取模块502和处理模块503；其中，

所述请求接收模块501，用于接收第一客户端发送的任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；

所述数据获取模块502，用于根据所述第一标识和所述待审核任务的类型，获取与所述待审核任务相关的所述用户的历史业务数据；

所述处理模块503，用于根据所述第二标识，将所述历史业务数据和所述待审核任务的类型发送至所述第二客户端，所述第二客户端根据所述历史业务数据和所述待审核任务的类型，对所述待审核任务进行审核，并将所述第二客户端的审核结果发送至所述第一客户端。

在本发明一个实施例中，所述任务审核请求还包括：所述待审核任务对应的第一时间段和/或位置，所述数据获取模块502，用于根据所述第一标识，获取所述用户在所述第一时间段内和/或所述位置生成的与所述待审核任务相关的历史业务数据。

在本发明一个实施例中，所述数据获取模块502，还用于根据所述待审核任务的类型确定所述待审核任务审核条件，判断所述任务审核请求是否符合所述审核条件；如果是，根据所述第一标识获取所述用户对应的审核数据，并将所述审核数据发送至所述第二客户端，以使所述第二客户端根据所述审核数据和所述历史业务数据对所述待审核任务进行审核。

在本发明一个实施例中，所述审核条件为所述任务审核请求包括的请求值大于预设阈值、和/或所述任务审核请求包括的第一时间段包含或部分包含于预设的与所述待审核任务相关的第二时间段内。

在本发明一个实施例中，所述处理模块503，还用于根据所述业务项目以及业务项目对应的项目值，计算所述待审核任务对应的审核值，并将所述审核值发送至所述第二客户端，以使所述第二客户端根据所述审核值对所述待审核任务进行审核。

在本发明一个实施例中，所述处理模块503，还用于当所述审核结果包括：所述历史业务数据不完整时，向所述第一客户端发送数据补充提示，接收所述第一客户端发送的补充数据，并将所述补充数据发送至所述第二客户端，以使所述第二客户端根据所述补充数据以及所述历史业务数据，对所述待审核任务进行审核。

根据本发明实施例的任务审核装置可以看出，在接收到第一客户端发送的任务审核请求后，可根据任务审核请求包括的用户的第一标识和待审核任务的类型，获取与待审核任务相关的用户的历史业务数据，然后根据任务审核请求包括的第二客户端的第二标识，将历史业务数据发送至第二客户端，使得第二客户端可根据历史业务数据对待审核任务进行审核，并将第二客户端的审核结果发送至第一客户端。由此，可根据任务审核请求自动获取与待审核任务相关的历史业务数据，并使得第二客户端可基于历史业务数据对待审核任务进行审核，从而无需用户整理业务材料，降低任务审核过程中的人为参与度，提高用户体验，并有利于提高任务审核时间。

如图6所示，本发明实施例还提供了一种任务审核系统600，包括：第一客户端601、第二客户端602和上述任一实施例所述的任务审核装置500；其中，

所述第一客户端601，用于向所述任务审核装置发送任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；

所述第二客户端602，用于根据所述任务审核装置500发送的历史业务数据，按照待审核任务的类型对所述待审核任务进行审核，并将审核结果发送至所述任务审核装置500；

所述任务审核装置500，用于将所述审核结果发送至所述第一客户端601。

图7示出了可以应用本发明实施例的任务审核方法或任务审核装置的示例性系统架构700。

如图7所示，系统架构700可以包括终端设备701、702、703，网络704和服务器705。网络704用以在终端设备701、702、703和服务器705之间提供通信链路的介质。网络704可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备701、702、703通过网络704与服务器705交互，以接收或发送消息等。终端设备701、702、703上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备701、702、703可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器705可以是提供各种服务的服务器，例如对用户利用终端设备701、702、703所浏览的购物类网站提供支持的后台管理服务器。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息)反馈给终端设备。

需要说明的是，本发明实施例所提供的任务审核方法一般由服务器705执行，相应地，任务审核装置一般设置于服务器705中。

应该理解，图7中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图8，其示出了适于用来实现本发明实施例的终端设备的计算机系统800的结构示意图。图8示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(cpu)801，其可以根据存储在只读存储器(rom)802中的程序或者从存储部分808加载到随机访问存储器(ram)803中的程序而执行各种适当的动作和处理。在ram803中，还存储有系统800操作所需的各种程序和数据。cpu801、rom802以及ram803通过总线804彼此相连。输入/输出(i/o)接口805也连接至总线804。

以下部件连接至i/o接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(cpu)801执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括请求接收模块、数据获取模块和处理模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，请求接收模块还可以被描述为“接收第一客户端发送的任务审核请求的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收第一客户端发送的任务审核请求，所述任务审核请求包括：用户的第一标识、用于审核任务的第二客户端的第二标识、以及待审核任务的类型；根据所述第一标识和所述待审核任务的类型，获取与所述待审核任务相关的所述用户的历史业务数据；根据所述第二标识，将所述历史业务数据和所述待审核任务的类型发送至所述第二客户端，所述第二客户端根据所述历史业务数据和所述待审核任务的类型，对所述待审核任务进行审核；将所述第二客户端的审核结果发送至所述第一客户端。

根据本发明实施例的技术方案，在接收到第一客户端发送的任务审核请求后，可根据任务审核请求包括的用户的第一标识和待审核任务的类型，获取与待审核任务相关的用户的历史业务数据，然后根据任务审核请求包括的第二客户端的第二标识，将历史业务数据发送至第二客户端，使得第二客户端可根据历史业务数据对待审核任务进行审核，并将第二客户端的审核结果发送至第一客户端。由此，可根据任务审核请求自动获取与待审核任务相关的历史业务数据，并使得第二客户端可基于历史业务数据对待审核任务进行审核，从而无需用户整理业务材料，降低任务审核过程中的人为参与度，提高用户体验，并有利于提高任务审核时间。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。