信息处理方法、装置、设备及存储介质与流程

1.本技术涉及信息处理技术领域，尤其涉及一种信息处理方法、装置、设备及存储介质。


背景技术：

2.现有的基于中间理赔系统进行理赔的方案，通常由用户端与中间理赔系统对接，具体为用户端上传理赔凭证，中间理赔系统审核后先行垫付，然后中间理赔系统再和保险公司对接，这样的两个对接过程很容易出现数据模型不统一的问题，进而容易产生错误的赔付，降低理赔的准确性和安全性。


技术实现要素：

3.本技术实施例提供一种信息处理方法、装置、设备及存储介质，以解决相关技术存在的问题，技术方案如下：
4.第一方面，本技术实施例提供了一种信息处理方法，包括：
5.对用户端上传的多个理赔凭证进行字符识别，得到多组用户理赔数据；
6.根据多组用户理赔数据中每组用户理赔数据所属的理赔时间范围、以及预设的不同理赔时间范围和不同保单的对应关系，确定与多组用户理赔数据对应的保单的数量；
7.在多组用户理赔数据对应的保单的数量为一个的情况下，确定保单涉及的对接端服务器对应的赔付类型；
8.在对接端服务器对应的赔付类型为直付型的情况下，向对接端服务器发送对接端理赔数据，使对接端服务器针对对接端理赔数据进行审核和赔付；对接端理赔数据是根据用户理赔数据中的至少部分数据生成的。
9.第二方面，本技术实施例提供了一种信息处理装置，包括：
10.字符识别模块，用于对用户端上传的多个理赔凭证进行字符识别，得到多组用户理赔数据；
11.保单数量确定模块，用于根据多组用户理赔数据中每组用户理赔数据所属的理赔时间范围、以及预设的不同理赔时间范围和不同保单的对应关系，确定与多组用户理赔数据对应的保单的数量；
12.第一赔付类型确定模块，用于在多组用户理赔数据对应的保单的数量为一个的情况下，确定保单涉及的对接端服务器对应的赔付类型；
13.第一赔付模块，用于在对接端服务器对应的赔付类型为直付型的情况下，向对接端服务器发送对接端理赔数据，使对接端服务器针对对接端理赔数据进行审核和赔付；对接端理赔数据是根据用户理赔数据中的至少部分数据生成的。
14.第三方面，本技术实施例提供了一种信息处理设备，包括：存储器和处理器，存储器中存储指令，该指令由处理器加载并执行，以实现本技术实施例第一方面提供的信息处理方法。
15.第四方面，本技术实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现本技术实施例第一方面提供的信息处理方法。
16.上述技术方案中的优点或有益效果至少包括：
17.可根据多组用户理赔数据对应的保单的数量以及保单所涉及的对接端服务器的赔付类型，确定从用户端到对接端服务器的数据对接模式。在多组用户理赔数据对应的保单数量为一个且该保单所涉及的对接端服务器的赔付类型为直付型时，中间理赔系统将基于用户理赔数据中的至少部分数据生成的对接端理赔数据发送到对接端服务器，由对接端服务器审核并向用户赔付，可实现用户端数据与对接端服务器数据的直接对接，以提高用户端与对接端服务器之间数据模型的一致性，进而可提高理赔的准确性和安全性。
18.上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本技术进一步的方面、实施方式和特征将会是容易明白的。
附图说明
19.在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本技术公开的一些实施方式，而不应将其视为是对本技术范围的限制。
20.图1为本技术实施例提供的一种信息处理方法的流程示意图；
21.图2为本技术实施例中用户理赔数据的数据模型和对接端理赔数据的数据模型的框架图；
22.图3为本技术实施例提供的另一种信息处理方法的流程示意图；
23.图4为本技术实施例提供的一种信息处理装置的结构框架示意图；
24.图5为本技术实施例提供的另一种信息处理装置的结构框架示意图；
25.图6为本技术实施例提供的一种信息处理设备的结构框架示意图。
具体实施方式
26.在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本技术的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。
27.首先对本技术实施例涉及的几个术语作如下解释：
28.ocr：是optical character recognition的缩写名称，意思为光学字符识别，针对印刷体字符，采用光学的方式将纸质文档中的文字转换成为黑白点阵的图像文件，并通过识别软件将图像中的文字转换成文本格式，供文字处理软件进一步编辑加工的技术。
29.saas：是software-as-a-service的缩写名称，意思为软件即服务，即通过网络提供软件服务。
30.数据模型：是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。
31.下面以具体实施例对本技术的技术方案以及本技术的技术方案如何解决上述技
术问题进行详细说明。
32.本技术实施例提供了一种信息处理方法，可应用于中间理赔系统，如图1所示，该方法包括：
33.s101，对用户端上传的多个理赔凭证进行字符识别，得到多组用户理赔数据。
34.在一个示例中，可通过ocr技术对多个理赔凭证进行字符识别。识别出的每组用户理赔数据对应一个理赔凭证。
35.用户端上传的多个理赔凭证可以包括用户个人信息凭证、理赔单据凭证、理赔产品凭证和理赔责任凭证中的至少一类凭证。其中，用户个人信息包括用户的基本属性，具体可包含证件信息、联系方式、医保类型等理赔所需要的信息内容；理赔单据凭证可以是针对某类保险产品(例如医疗保险或意外保险)所上传的单据，针对保险类别的不同，可以包括不同类型的单据，以医疗保险为例，理赔单据凭证可以包括购买药品和医学检查的发票、医院开具的处方和药方、医院的等级证明等单据；理赔产品凭证可以是用户预先购买的保险产品的理赔方案、理赔条件等信息；理赔责任凭证可以是用户预先购买的保险产品所约定的保险方与被保险方之间的责任义务集合。
36.本技术实施例中的一组用户理赔数据可对应一个理赔凭证，例如对某个票据进行识别得到的数据作为该票据对应的一组用户理赔数据。本技术实施例中的多个理赔凭证的上述数据模型(即上述至少一类凭证的数据框架)是用户理赔数据的数据模型的基础。
37.在一个示例中，基于多个理赔凭证的上述数据模型得到的用户理赔数据的数据模型如图2所示，多组用户理赔数据可以存储于用户案件列表中，该用户案件列表中包括用户表、方案表、产品表和责任表以及各表之间的关联关系。其中，用户表中的数据是对用户个人信息凭证进行字符识别得到的，方案表是对理赔单据凭证进行字符识别得到的，产品表是对理赔产品凭证进行识别得到的，责任表是对理赔责任凭证进行识别得到的。
38.可选的，参照图2的示例，用户案件列表中的每一类列表均可包括多个用户案件单据表，每个用户案件单据表中的数据可以是对用户上传的至少一个单据进行字符识别得到的，每个用户案件单据表可包括多个用户案件发票表，每个用户案件发票表可以是对用户上传的某个发票进行字符识别得到的，每个用户案件发票表可以包括多个用户案件发票大项表、多个用户案件发票细项表和多个用户案件疾病表，每个表均可以根据用户上传的某个具体相应类别的发票识别得到。
39.s102，根据多组用户理赔数据中每组用户理赔数据所属的理赔时间范围、以及预设的不同理赔时间范围和不同保单的对应关系，确定与多组用户理赔数据对应的保单的数量；在与多组用户理赔数据对应的保单的数量为一个的情况下，执行步骤s103；在与多组用户理赔数据对应的保单的数量为至少两个的情况下，执行步骤s104。
40.可选地，对于没有所属的理赔时间范围的某组用户理赔数据，可在确定保单数量的过程中忽略该组用户理赔数据。
41.不同理赔时间范围和不同保单的对应关系可以通过如下方式确定：中间理赔系统从不同保险公司的保险产品中筛选合适的产品，共同形成针对同一个用户的理赔方案，以满足该用户的投保需求。
42.在一个示例中，若a用户计划在2021年全年投保医疗险，中间理赔系统可以在2021年的上半年为a用户配置b保险公司的医疗险产品，在2021年的下半年为a用户配置c保险公
司的医疗险产品，b保险公司出具上半年的保单，c保险公司出具下半年的保单。b保险公司的医疗险产品和c保险公司的医疗险产品共同形成了2021年全年的针对a用户的医疗险理赔方案，此时2021年的不同时间范围与不同的保单建立了对应关系，2021年上半年的时间范围(即2021年1月1日至6月40日)与b保险公司的保单建立了对应关系，2021年下半年的时间范围(即2021年7月1日至12月31日)与c保险公司的保单建立了对应关系。
43.基于上述示例所建立的不同时间范围与不同的保单的对应关系，若a用户上传的全部理赔凭证均是2021年上半年产生的，则识别出的每组用户理赔数据所属的时间范围均为2021年1月1日至6月40日，此时与多组用户理赔数据对应的保单的数量为一个，即b保险公司出具的保单；若a用户上传的一部分理赔凭证是2021年上半年产生的，另一部分理赔凭证是2021年下半年产生的，则识别出的多组用户理赔数据中一部分数据所属的时间范围为2021年1月1日至6月40日，另一部分数据所属的时间范围为2021年7月1日至12月31日，此时多组用户理赔数据对应的保单的数量为两个，分别为b保险公司出具的保单和c保险公司出具的保单。
44.s103，确定保单涉及的对接端服务器对应的赔付类型；在该保单涉及的对接端服务器对应的赔付类型为直付型的情况下，执行步骤s105；在该保单涉及的对接端服务器对应的赔付类型不是直付型的情况下，执行步骤s106。
45.在一个示例中，本技术实施例中的对接端服务器具体为保险公司的服务器，该服务器对应的赔付类型可根据中间理赔系统与保险公司的预先约定信息确定，若中间理赔系统与某个保险公司的预先约定信息为当用户发起理赔时由该保险公司直接向用户赔付，则可确定该保险公司的服务器是直付型，若中间理赔系统与该保险公司的预先约定信息为当用户发起理赔时由该中间理赔系统垫付，则可确定该保险公司的服务器不是直付型。
46.s104，启动针对用户理赔数据的垫付流程，并向至少两个保单对应的对接端服务器分别发送垫付流程结束后生成的、针对当前对接端服务器的垫付完成信息。
47.本技术实施例中，中间理赔系统启动的针对用户理赔数据的垫付流程的具体过程为：由中间理赔系统的付款账户向用户的收款账户发送赔付款。
48.s105，向对接端服务器发送对接端理赔数据，使对接端服务器针对对接端理赔数据进行审核和赔付。
49.中间理赔系统向对接端服务器发送的对接端理赔数据是根据用户理赔数据中的至少部分数据生成的。可选地，中间理赔系统可将所有的用户理赔数据作为对接端理赔数据向对接端服务器发送，或者，中间理赔系统可删除用户理赔数据中的无效数据后将剩余的用户理赔数据作为对接端理赔数据向对接端服务器发送。
50.无效数据可以是超出有效理赔时间范围的数据或者与当前理赔无关的数据，例如，若a用户的投保时间范围为2021年全年，则有效理赔时间范围也是2021年全年，若用户端上传的某些理赔凭证是2020年产生的，则基于该类理赔凭证识别出的用户理赔数据为无效数据；又如，若a用户投保的保险类型的医疗险，而用户端上传的某些理赔凭证是生育相关的票据，则基于该类理赔凭证识别出的用户理赔数据为无效数据。
51.可选地，对接端服务器针对对接端理赔数据进行的审核和赔付可由对接端服务器所连接的客户端来执行，例如对接端服务器将对接端理赔数据发送至负责审核数据的客户端，通过客户端用负责审核数据的工作人员展示，根据工作人员审核通过后输入的指令调
用付款账户向用户的收款账户支付赔付款，或根据工作人员审核未通过后输入的指令将赔付失败信息发送至对接端服务器，由对接端服务器转发至中间理赔系统。
52.可选地，向对接端服务器发送对接端理赔数据，包括：
53.根据保单中的理赔条件对用户理赔数据进行审核；在用户理赔数据满足保单中的理赔条件时，根据用户理赔数据中的至少部分数据生成对接端理赔数据，向对接端服务器发送对接端理赔数据。
54.可选地，中间理赔系统根据保单中的理赔条件对用户理赔数据进行审核，可以通过以下任意一种方式实现：方式一，中间理赔系统的服务器自动将保单中的理赔条件与用户理赔数据(或用户理赔数据经过预设规则的运算得到值)对比，例如对比以确定医院的等级是否符合理赔条件中的医院等级，用户理赔数据中的金额总和是否符合理赔条件中的理赔金额标准；方式二，中间理赔系统的服务器将保单中的理赔条件和用户理赔数据(或用户理赔数据经过预设规则的运算得到值)发送至中间理赔系统的客户端，由客户端向负责审核的工作人员展示，根据工作人员审核通过后输入的指令生成基于用户理赔数据的对接端理赔数据并发送至对接端服务器，根据工作人员审核未通过后输入的指令向用户端反馈审核失败的信息，以提醒用户调整理赔凭证。
55.基于用户理赔数据的至少部分数据生成对接端理赔数据，可使对接端理赔数据的数据模型与用户理赔数据的数据模型保持统一。在一个示例中，参照图2，对接端理赔数据的数据模型可以包括针对当前保险公司的保司案件列表中，保司案件列表中存储有当前保险公司相关的对接端理赔数据，该保司案件列表中可以包括用户表、方案表、产品表和责任表以及各表之间的关联关系。
56.可选的，参照图2的示例，保司案件列表中的每一类列表均可包括多个保司案件单据表，每个保司案件单据表中的数据可以是由用户案件单据表中筛选出的与当前保险公司相关的数据；每个保司案件单据表可包括多个保司案件发票表，每个保司案件发票表中的数据可以是由用户案件发票表中筛选出的与当前保险公司相关的数据；每个保司案件发票表可以包括多个保司案件发票大项表、多个保司案件发票细项表和多个保司案件疾病表，每个表中的数据均可以是由用户理赔数据的数据模型的同类表中筛选出的与当前保险公司相关的数据。
57.通过上述方式，中间理赔系统可在生成对接端理赔数据之前首先对用户理赔数据进行一次审核，然后再生成对接端理赔数据并发送至对接端服务器，实现中间理赔系统和对接端服务器的两层审核，以减少用户理赔数据和对接端理赔数据之间的偏差，避免一次审核可能出现的审核误差，提高对接端理赔数据的准确性，进而提高用户端与对接端服务器直接进行数据对接的准确性。
58.s106，启动针对用户理赔数据的垫付流程，并向保单对应的对接端服务器发送垫付流程结束后生成的垫付完成信息。
59.本技术实施例提供的上述信息处理方法可至少实现如下有益效果：
60.1)可根据多组用户理赔数据对应的保单的数量以及保单所涉及的对接端服务器的赔付类型，确定从用户端到对接端服务器的数据对接模式。在多组用户理赔数据对应的保单数量为一个且该保单所涉及的对接端服务器的赔付类型为直付型时，中间理赔系统将基于用户理赔数据中的至少部分数据生成的对接端理赔数据发送到对接端服务器，由对接
端服务器审核并向用户赔付，可实现用户端数据与对接端服务器数据的直接对接，以提高用户端与对接端服务器之间数据模型的一致性，进而可提高理赔的准确性和安全性，中间理赔系统无需进行垫付，可降低中间理赔系统的现金流压力。
61.2)实现中间理赔系统和对接端服务器的两层审核，以减少用户理赔数据和对接端理赔数据之间的偏差，提高对接端理赔数据的准确性，进而提高用户端与对接端服务器直接进行数据对接的准确性。
62.在一种可选的实施方式中，在向对接端服务器发送对接端理赔数据之后，本技术实施例提供的信息处理方法还包括：
63.在对接端服务器在指定反馈期限内进行了反馈的情况下，响应于对接端服务器反馈的赔付失败信息，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息；在对接端服务器在指定反馈期限内未进行反馈的情况下，响应于当前时刻为指定反馈期限的最晚时刻，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息。
64.可选的，对接端服务器反馈的赔付失败信息可以是对接端服务器对对接端理赔数据审核未通过生成的，也可以是对接端服务器对对接端理赔数据审核通过但支付赔付款失败生成的。
65.本技术实施例中的指定反馈期限可以根据实际需求情况，在一示例中，可以设置为中间理赔系统向对接端服务器发送对接端理赔数据的一周时间，在另一个示例中，也可根据中间理赔系统与保险公司的预先约定信息中的反馈期限设置。
66.本技术实施例通过上述方式，可在对接端服务器长时间无反馈或直付失败的情况下，由中间理赔系统向用户进行垫付，以保证中间理赔系统对用户理赔请求的响应速度，提高赔付效率，保证理赔时效。
67.在一种可选的实施方式中，在向对接端服务器发送对接端理赔数据之后，本技术实施例提供的信息处理方法还包括：
68.响应于对接端服务器反馈的赔付成功信息，向用户端发送数据更新指令；数据更新指令用于更新用户端的理赔进度数据。
69.在对接端服务器直付成功后，更新用户端的理赔进度数据，可实现用户端数据和对接端服务器数据的实时对接，提高两端数据对接的效率。
70.一种可选的实施方式中，在多组用户理赔数据对应的保单的数量为至少两个的情况下，如图3所示，本技术实施例的前述步骤s104可替换为如下的步骤s107-s111：
71.s107，确定每个保单涉及的对接端服务器对应的赔付类型；在至少两个保单中存在至少一个保单涉及的对接端服务器对应的赔付类型为直付型的情况下，执行步骤s108；在至少两个保单涉及的对接端服务器对应的赔付类型均不是直付型的情况下，执行步骤s109。
72.s108，向每个对接端服务器发送对应的对接端理赔数据，然后执行s110。
73.可选地，基于保单和对接端服务器的一一对应关系，在多组用户理赔数据对应的保单的数量为至少两个的情况下，多组用户理赔数据对应的对接端服务器也为至少两个，中间理赔系统可基于保单所对应的时间范围的不同对多组用户理赔数据进行拆分，将拆分后的用户理赔数据分别向各个保单对应的对接端服务器分发。例如将b保险公司的保单所
对应的时间范围内的用户理赔数据拆分出来并向b保险公司的服务器发送，将c保险公司的保单所对应的时间范围内的用户理赔数据拆分出来并向c保险公司的服务器发送。
74.s109，启动针对用户理赔数据的垫付流程，并向至少两个保单对应的对接端服务器分别发送垫付流程结束后生成的、针对当前对接端服务器的垫付完成信息。
75.针对用户理赔数据的垫付流程的一种可选的执行方式可参照前面的相关内容，此处不再赘述。
76.在一个示例中，对于非直付型的b保险公司和c保险公司，在针对用户理赔数据的垫付流程结束后，向b保险公司的服务器发送针对b保险公司的服务器的赔付完成信息，表示中间理赔系统已经对b保险公司应当赔付的款项进行了垫付，向c保险公司的服务器发送针对c保险公司的服务器的赔付完成信息，表示中间理赔系统已经对c保险公司应当赔付的款项进行了垫付。
77.s110，响应于每个直付型的对接端服务器对对接端理赔数据审核通过并返回的对接端待赔付信息后，向用户端发送用户端待赔付信息。
78.用户端赔付信息是将各对接端赔付信息进行汇总后生成的。
79.在一个示例中，对于直付型的b保险公司和c保险公司，b保险公司的服务器在对接收到的对接端理赔数据审核通过后返回b保险公司的待赔付信息，c保险公司的服务器在对接收到的对接端理赔数据审核通过后返回c保险公司的待赔付信息，中间理赔系统将b保险公司的待赔付信息和c保险公司的待赔付信息汇总后形成用户端赔付信息，向用户端发送该用户端赔付信息。
80.s111，响应于用户端返回的针对用户端赔付信息进行确认的确认信息后，向每个直付型的对接端理赔数据发送该确认信息。
81.确认信息用于通知每个直付型的对接端服务器向对应的用户赔付。
82.可选的，对接端服务器向对应的用户赔付可以通过以下任意一种方式实现：方式一，各个对接端服务器调用分别各自所属保险公司的付款账户向用户的收款账户支付各自应付的赔付款；方式二，各个对接端服务器均向中间理赔系统的收付款账户支付各自应付的赔付款，中间理赔系统将汇总后的赔付款统一支付给用户的收款账户。
83.本技术实施例通过上述实施方式，在多组用户理赔数据对应的保单数量为至少两个的情况，可根据至少两个保单对应的对接端服务器的赔付类型确定用户端到至少两个对接端服务器的数据对接模式，提高与不同对接端服务器数据对接的灵活性。
84.对于直付型的对接端服务器，中间理赔系统可将基于用户理赔数据中与直付型对接端服务器相关的至少部分数据生成的对接端理赔数据发送到直付型对接端服务器，由直付型对接端服务器审核并向用户赔付，以实现用户端数据与直付型对接端服务器数据的直接对接，提高用户端与直付型对接端服务器之间数据模型的一致性，进而可提高理赔的准确性和安全性；对于非直付型的对接端服务器，中间理赔系统可进行垫付，以保证中间理赔系统面向用户的理赔时效。
85.在一种可选的实施方式中，在向每个对接端服务器发送对应的对接端理赔数据之后，或在向每个直付型的对接端理赔数据发送确认信息之后，本技术实施例提供的信息处理方法还包括：
86.对于在指定反馈期限内进行了反馈的对接端服务器，响应于该对接端服务器反馈
的赔付失败信息，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息；对于在指定反馈期限内未进行反馈的对接端服务器，响应于当前时刻为指定反馈期限的最晚时刻，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息。
87.针对用户理赔数据的垫付流程的一种可选的执行方式可参照前面的相关内容，此处不再赘述。
88.本技术实施例通过上述方式，可在某些对接端服务器长时间无反馈或直付失败的情况下，由中间理赔系统向用户进行垫付，以保证中间理赔系统对用户理赔请求的响应速度，不会因个别对接服务器的问题影响整体赔付效率，可以保证理赔时效。
89.在一种可选的实施方式中，本技术实施例提供的信息处理方法可以基于saas平台实现的。通过saas平台可以较低的成本实现灵活性较高的软件运行。
90.基于同一发明构思，本技术实施例还提供了一种信息处理装置，如图4所示，该信息处理装置400可以包括：字符识别模块401、保单数量确定模块402、第一赔付类型确定模块403和第一赔付模块404。
91.字符识别模块401，用于对用户端上传的多个理赔凭证进行字符识别，得到多组用户理赔数据；
92.保单数量确定模块402，用于根据多组用户理赔数据中每组用户理赔数据所属的理赔时间范围、以及预设的不同理赔时间范围和不同保单的对应关系，确定与多组用户理赔数据对应的保单的数量；
93.第一赔付类型确定模块403，用于在多组用户理赔数据对应的保单的数量为一个的情况下，确定保单涉及的对接端服务器对应的赔付类型；
94.第一赔付模块404，用于在对接端服务器对应的赔付类型为直付型的情况下，向对接端服务器发送对接端理赔数据，使对接端服务器针对对接端理赔数据进行审核和赔付；对接端理赔数据是根据用户理赔数据中的至少部分数据生成的。
95.可选的，第一赔付模块404具体用于：根据保单中的理赔条件对用户理赔数据进行审核；在用户理赔数据满足保单中的理赔条件时，根据用户理赔数据中的至少部分数据生成对接端理赔数据，向对接端服务器发送对接端理赔数据。
96.在一种可选的实施方式中，本技术实施例提供的信息处理装置还可以包括：第二赔付模块。
97.第二赔付模块，用于在对接端服务器在指定反馈期限内进行了反馈的情况下，响应于对接端服务器反馈的赔付失败信息，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息；在对接端服务器在指定反馈期限内未进行反馈的情况下，响应于当前时刻为指定反馈期限的最晚时刻，启动针对用户理赔数据的垫付流程，并向对接端服务器发送垫付流程结束后生成的垫付完成信息。
98.在一种可选的实施方式中，如图5所示，本技术实施例提供的信息处理装置还可以包括：第二赔付类型确定模块405、理赔数据发送模块406、信息确认模块407、第三赔付模块408。
99.第二赔付类型确定模块405，用于在多组用户理赔数据对应的保单的数量为至少两个的情况下，确定每个保单涉及的对接端服务器对应的赔付类型。
100.理赔数据发送模块406，用于在至少两个保单中存在至少一个保单涉及的对接端服务器对应的赔付类型为直付型的情况下，向每个对接端服务器发送对应的对接端理赔数据。
101.信息确认模块407，用于响应于每个直付型的对接端服务器对对接端理赔数据审核通过并返回的对接端待赔付信息后，向用户端发送用户端待赔付信息；用户端待赔付信息是将各对接端待赔付信息进行汇总后生成的；
102.第三赔付模块408，用于响应于用户端返回的针对用户端待赔付信息进行确认的确认信息后，向每个直付型的对接端理赔数据发送确认信息；确认信息用于通知每个直付型的对接端服务器向对应的用户赔付。
103.在一种可选的实施方式中，本技术实施例提供的信息处理装置还可以包括：数据更新模块。
104.数据更新模块，用于向对接端服务器发送携带有对接端理赔数据的理赔请求之后，响应于对接端服务器反馈的赔付成功信息，向用户端发送数据更新指令；数据更新指令用于更新用户端的理赔进度数据。
105.在一种可选的实施方式中，本技术实施例提供的信息处理装置可基于saas平台实现。
106.本技术实施例各装置中的各模块的功能可以参见上述方法中的对应描述，在此不再赘述。
107.基于同一发明构思，本技术实施例还提供了一种信息处理设备，如图6所示，该设备包括：存储器601和处理器602，存储器601内存储有可在处理器602上运行的计算机程序。处理器602执行该计算机程序时实现上述实施例中的任意一种信息处理方法。存储器601和处理器602的数量可以为一个或多个。
108.本技术实施例提供的信息处理设备还可以包括：
109.通信接口603，用于与外界设备进行通信，进行数据交互传输。
110.如果存储器601、处理器602和通信接口603独立实现，则存储器601、处理器602和通信接口603可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(industry standard architecture，isa)总线、外部设备互连(peripheral component interconnect，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
111.可选的，在具体实现上，如果存储器601、处理器602及通信接口603集成在一块芯片上，则存储器601、处理器602及通信接口603可以通过内部接口完成相互间的通信。
112.基于同一发明构思，本技术实施例还提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本技术实施例中提供的方法。
113.基于同一发明构思，本技术实施例还提供了一种芯片，该芯片包括，包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本技术实施例提供的任意一种信息处理方法。
114.基于同一发明构思，本技术实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处
理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的任意一种信息处理方法。
115.应理解的是，上述处理器可以是中央处理器(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processing，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(fieldprogrammablegate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced risc machines，arm)架构的处理器。
116.进一步地，可选的，上述存储器可以包括只读存储器和随机存取存储器，还可以包括非易失性随机存取存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或闪存。易失性存储器可以包括随机存取存储器(random access memory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用。例如，静态随机存取存储器(static ram，sram)、动态随机存取存储器(dynamic random access memory，dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data date sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synchlink dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，dr ram)。
117.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本技术的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。
118.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本技术的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
119.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本技术的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
120.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部
分。并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。
121.在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。
122.应理解的是，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
123.此外，在本技术各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。
124.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。