用户数据合并方法、装置、计算机设备及存储介质与流程

1.本发明涉及人工智能的图像识别技术领域，尤其涉及一种用户数据合并方法、装置、计算机设备及存储介质。


背景技术：

2.目前，越来越多领域的线下业务办理流程均转移至互联网线上在线办理，如在线提交用户资料、在线身份信息核验等。同一用户在进行业务的线上办理的过程中，往往需要上传多次用户数据，这就导致服务器中需对同一用户的不同批次上传的数据进行分批处理，导致处理效率低下。例如，保险领域的保险理赔案件中自助理赔的案件占比越来越高，也就是用户操作用户端上安装的应用程序并打开自助理赔的操作界面并上传各种理赔数据和信息。这样用户可随时随地提交理赔申请。而且随着人工智能及数字医疗技术的兴起，人工智能技术和数字医疗技术可以支持疾病辅助诊断、健康管理、远程会诊等功能。而且人工智能及数字医疗技术也能应用于理赔环节。
3.用户每向服务器上传一次理赔数据，就生成一次理赔任务信息并加入待人工或自动审核的任务队列中以等待进一步的资料审核，这就导致可能针对同一用户的同一理赔案件的信息是分开进行审核，不仅增加了审核人工成本和审核用时，而且不能有效针对是否存在同一用户的同一理赔案件分批次上传资料进行及时判断，未及时检测用户理赔数据的欺诈风险。


技术实现要素：

4.本发明实施例提供了一种用户数据合并方法、装置、计算机设备及存储介质，旨在解决现有技术中若用户将多次目标信息分开上传，导致针对同一用户的同一理赔案件的信息是分开进行审核，不仅增加了审核人工成本和审核用时，而且不能有效针对是否存在同一用户的同一理赔案件分批次上传资料进行及时判断的问题。
5.第一方面，本发明实施例提供了一种用户数据合并方法，其包括：
6.响应于目标信息上传指令，获取与所述目标信息上传指令相应的目标信息；
7.根据预设的信息检索策略在目标数据库中获取所述目标信息相应的近似信息；其中，所述信息检索策略用于在目标数据库中获取与所述目标信息具有相同预设参数且为未处理状态的近似信息；
8.根据所述近似信息相应的检索结果及预设的通知信息模板生成信息合并确认通知信息，将所述信息合并确认通知信息发送至用户端；
9.若确定接收到与所述信息合并确认通知信息相应的同意合并指令，根据预设的信息合并策略将所述目标信息与所述近似信息进行信息合并，得到合并后目标信息；以及
10.获取所述近似信息的信息上报时间，将所述信息上报时间作为所述合并后目标信息的合并信息上报时间。
11.第二方面，本发明实施例提供了一种用户数据合并装置，其包括：
12.目标信息获取单元，用于响应于目标信息上传指令，获取与所述目标信息上传指令相应的目标信息；
13.近似信息获取单元，用于根据预设的信息检索策略在目标数据库中获取所述目标信息相应的近似信息；其中，所述信息检索策略用于在目标数据库中获取与所述目标信息具有相同预设参数且为未处理状态的近似信息；
14.合并信息生成单元，用于根据所述近似信息相应的检索结果及预设的通知信息模板生成信息合并确认通知信息，将所述信息合并确认通知信息发送至用户端；
15.数据合并单元，用于若确定接收到与所述信息合并确认通知信息相应的同意合并指令，根据预设的信息合并策略将所述目标信息与所述近似信息进行信息合并，得到合并后目标信息；以及
16.合并时间获取单元，用于获取所述近似信息的信息上报时间，将所述信息上报时间作为所述合并后目标信息的合并信息上报时间。
17.第三方面，本发明实施例又提供了一种计算机设备，其包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的用户数据合并方法。
18.第四方面，本发明实施例还提供了一种计算机可读存储介质，其中所述计算机可读存储介质存储有计算机程序，所述计算机程序当被处理器执行时使所述处理器执行上述第一方面所述的用户数据合并方法。
19.本发明实施例提供了一种用户数据合并方法、装置、计算机设备及存储介质，先是获取用户所上传目标信息的近似信息，然后在确定接收到与信息合并确认通知信息相应的同意合并指令后将所述目标信息与所述近似信息进行信息合并，得到合并后目标信息，最后获取近似信息的信息上报时间，将信息上报时间作为合并后目标信息的合并信息上报时间。实现了将针对同一用户在不同时段上传的目标信息及时进行检测和合并，降低了信息审核量，提高了数据处理效率。
附图说明
20.为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1为本发明实施例提供的用户数据合并方法的应用场景示意图；
22.图2为本发明实施例提供的用户数据合并方法的流程示意图；
23.图3为本发明实施例提供的用户数据合并装置的示意性框图；
24.图4为本发明实施例提供的计算机设备的示意性框图。
具体实施方式
25.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
26.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
27.还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
28.还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
29.请参阅图1和图2，图1为本发明实施例提供的用户数据合并方法的应用场景示意图；图2为本发明实施例提供的用户数据合并方法的流程示意图，该用户数据合并方法应用于服务器中，该方法通过安装于服务器中的应用软件进行执行。
30.如图2所示，该方法包括步骤s101～s105。
31.s101、响应于目标信息上传指令，获取与所述目标信息上传指令相应的目标信息。
32.在本实施例中，是以服务器为执行主体来描述技术方案。用户可以操作其使用的用户端并打开相应的app(即应用程序)上传目标信息，若本技术的具体应用场景是理赔场景，则目标信息可以理解为理赔信息，上传理赔信息一般需要填写被保险人姓名(被保险人姓名也可以理解为关联姓名)、理赔申请类型、受理保单号(受理保单号也可以理解为受理业务编号)、接收理赔金的转账账户、申请人/代办人姓名等信息，并上传监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片、医疗费用原始凭证图片、医疗费用明细清单/处方图片、购药增值税发票图片、门(急)病历图片、住院病历(出院小结)图片、病理/血液/影像检查报告图片、其他证明(出差/休假/职级等)图片、基金集体账户申请证明图片、意外事故证明或说明图片、代办委托电子签名(含手持身份证拍照)图片、代办委托纸质授权图片、授权委托书图片、理赔申请书图片等图片，这些信息被上传至服务器后，自动组合成目标信息。通过在线上传理赔资料的方式，便于进行在线审核资料。
33.在一实施例中，步骤s101包括：
34.获取用户账户信息，并获取所述用户账户信息的关联姓名和受理业务编号；
35.将所述关联姓名和受理业务编号填充至目标信息模板，得到初始填充目标信息；
36.获取用户端上传的补充信息和业务关联图片，将所述补充信息和业务关联图片填充至所述初始填充目标信息，得到目标信息。
37.在本实施例中，当用户打开app上传目标信息时，一般是先输入用户账号和密码登录服务器，当登录成功后，服务器可获取到与该用户相应的用户账号信息，并自动获取到该用户的关联姓名和受理业务编号(这里的受理业务编号是基于用户之前投保的若干个保单中，自动检索出可进行自助理赔保单的受理业务编号)，然后基于后台数据库检索出来的与用户账户信息相应的关联姓名和受理业务编号自动填充至目标信息模板，得到初始填充目标信息，此时目标信息模板中的其他信息还未上传。此时服务器接收用户端至上传的补充信息(例如理赔申请类型、接收理赔金的转账账户、申请人/代办人姓名等)和业务关联图片(例如上述列举的监护关系证明图片、监护人身份证明图片等)，当完成了补充信息和业务关联图片的接收后，也是填充到目标信息模板中相应的位置，从而得到了用户此次上传的
完整的目标信息。通过这一结合自动填充和半自动填充的方式，能够更加快速的获取完整的目标信息以进行后续数据处理。
38.当服务器获取了此次用户上传了完整的目标信息后，还需解析获取其中包括的受理业务信息(可以理解为理赔案件信息)，也就是自动获取关联姓名、受理业务申请类型(也可以理解为理赔申请类型)、受理业务编号、关联账号(也可以理解为接收理赔金的转账账户)、申请人/代办人姓名这些字段对应的具体取值，从而进行后续是否有相同被保险人的近似保单检索。
39.s102、根据预设的信息检索策略在目标数据库中获取所述目标信息相应的近似信息；其中，所述信息检索策略用于在目标数据库中获取与所述目标信息具有相同预设参数且为未处理状态的近似信息。
40.在本实施例中，仍以在线理赔为具体场景，服务器中有一目标数据库，用于存储多个为未处理状态的目标信息，这些目标信息都是用户操作用户端填写理赔案件信息后上传至服务器以待审核的信息。为了提高目标信息分配至下一步人工审核或自动审核的效率，可以将一些明显是针对同一被保险人的目标信息进行合并后再审核，有效降低目标数据库中目标信息的总数量，提升审核效率。
41.在一实施例中，步骤s102包括：
42.以所述目标信息中的预设的一个或多个参数为检索条件，若确定目标数据库中存在近似信息与所述目标信息具有相同的关联姓名、受理业务编号、受理业务申请类型及关联账号，获取所述近似信息。
43.其中，所述信息检索策略是以所获取到的理赔案件信息中关联姓名、受理业务申请类型、受理业务编号、关联账号、为检索条件，判断在目标数据库中是否检测到具相同的关联姓名、受理业务编号、受理业务申请类型及关联账号，当满足上述条件时即可判断满足信息检索策略，从而在目标数据库中获取所述目标信息相应的近似信息。
44.由于目标数据库中各目标信息都是对应一个加入目标数据库的加入时间，一般近似信息的入池时间是早于所述目标信息的入池时间，将两者进行合并之后，可以使得后入池的目标信息与其近似的近似信息进行合并，从而起到了降低目标数据库中案件总数提升处理效率的作用。
45.s103、根据所述近似信息相应的检索结果及预设的通知信息模板生成信息合并确认通知信息，将所述信息合并确认通知信息发送至用户端。
46.在本实施例中，当在目标数据库中检索到与所述目标信息最近似的近似信息后，可以直接生成一个信息合并确认通知信息，并发送至用户端以在用户端的界面上进行显示。例如所生成的信息合并确认通知信息如“您有相同类型未结理赔申请(申请号*****，报案号******)，本次理赔申请将合并至前次申请，处理优先顺序按前次申请为准。”47.在一实施例中，步骤s103包括：
48.接收用户端根据回复确认信息触发生成的同意合并指令；
49.或者接收用户端在预设的回复时限阈值内未回复信息生成的同意合并指令。
50.其中，当用户端接收到如上述的信息合并确认通知信息后，可以回复确认信息以触发生成同意合并指令。也可以是在用户端接收到如上述的信息合并确认通知信息后若在指定回复时限(如在用户端接收到该信息合并确认通知信息的2小时内)未回复任何信息，
也可以视为默认同意从而自动生成同意合并指令。
51.s104、若确定接收到与所述信息合并确认通知信息相应的同意合并指令，根据预设的信息合并策略将所述目标信息与所述近似信息进行信息合并，得到合并后目标信息。
52.在本实施例中，当服务器接收到与所述信息合并确认通知信息相应的同意合并指令，则表示用户同意将该目标信息与所述近似信息进行合并，此时可以获取到预先设置的信息合并策略，以将所述目标信息与所述近似信息进行信息合并得到合并后目标信息。为了确保合并后的信息不会出现错误数据，在信息合并的过程中需遵循信息合并策略对应的合并规则，从而确保合并数据的准确性。
53.在一实施例中，所述信息合并策略为将所述目标信息与所述近似信息中相同字段对应的取值或图片进行合并，步骤s104包括：
54.获取所述目标信息中的关联姓名、受理业务编号、补充信息和业务关联图片；
55.获取所述近似信息中的历史关联姓名、历史受理业务编号、历史补充信息和历史业务关联图片；
56.将所述历史关联姓名作为与所述关联姓名相应的合并关联姓名，将所述历史受理业务编号作为与所述受理业务编号相应的合并受理业务编号，将所述历史补充信息作为与所述补充信息相应的合并补充信息，将所述历史业务关联图片与所述业务关联图片合并保存作为合并业务关联图片；
57.由所述合并关联姓名、所述合并受理业务编号、所述合并补充信息及所述合并业务关联图片组成合并后目标信息。
58.在本实施例中，由于关联姓名与历史关联姓名相同，且受理业务编号与历史受理业务编号相同，所述历史补充信息与所述补充信息相同，此时可以任选关联姓名与历史关联姓名之一作为合并关联姓名，同样的可以任选受理业务编号与历史受理业务编号之一作为合并受理业务编号，也可以任选所述历史补充信息与所述补充信息之一作为合并补充信息。由于用户在多次上传业务关联图片时可能上传的图片不完全相同，为了在合并目标信息确保无信息丢失，可以将各业务关联图片均进行合并后再保存即可。
59.在一实施例中，所述将所述历史业务关联图片与所述业务关联图片合并保存作为合并业务关联图片，包括：
60.通过图像识别获取所述业务关联图片中的第一类型子图片集和第二类型子图片集；其中，所述第一类型子图片集的图片合并属性为不可合并图片，所述第二类型子图片集的图片合并属性为可合并图片；
61.通过图像识别获取所述历史业务关联图片中的历史第一类型子图片集和历史第二类型子图片集；其中，所述历史第一类型子图片集的图片合并属性为不可合并图片，所述历史第二类型子图片集的图片合并属性为可合并图片；
62.将所述第一类型子图片集与所述历史第一类型子图片集进行图片拼接，得到合并第一类型子图片集；
63.若确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片，将所述历史第二类型子图片集作为合并第二类型子图片集；
64.由所述合并第一类型子图片集及所述合并第二类型子图片集组成合并业务关联图片。
65.在本实施例中，具体实施时所述第一类型子图片集包括监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片；所述第二类型子图片集包括医疗费用原始凭证图片、医疗费用明细清单/处方图片、购药增值税发票图片、门诊病历图片、住院病历图片、病理/血液/影像检查报告图片、出差/休假/职级证明图片、基金集体账户申请证明图片、意外事故证明或说明图片、代办委托电子签名图片、代办委托纸质授权图片、授权委托书图片、理赔申请书图片；所述历史第一类型子图片集包括历史监护关系证明图片、历史监护人身份证明图片、历史代办人身份证明图片、历史被保险人身份证图片、历史结婚证明图片；所述历史第二类型子图片集包括历史医疗费用原始凭证图片、历史医疗费用明细清单/处方图片、历史购药增值税发票图片、历史门诊病历图片、历史住院病历图片、历史病理/血液/影像检查报告图片、历史出差/休假/职级证明图片、历史基金集体账户申请证明图片、历史意外事故证明或说明图片、历史代办委托电子签名图片、历史代办委托纸质授权图片、历史授权委托书图片、历史理赔申请书图片。由于监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片对应的第一类型子图片集在每一次目标信息上传时，都是要完整保存以供后续查验的，故第一类型子图片集每上传一次是与前一次的历史第一类型子图片集进行图片拼接，从而完成的保存上传历史记录。
66.而第二类型子图片集对应的图片在每一次目标信息上传时，基本都是相同的，可以多次共用同一张图片，为了节省服务器中的存储空间，可以在确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片时，将所述历史第二类型子图片集作为合并第二类型子图片集。通过这一方式，可以确保合并后图片占用更少存储空间。
67.在一实施例中，所述若确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片，将所述历史第二类型子图片集或所述历史第二类型子图片集作为合并第二类型子图片集，包括：
68.若确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片，将对应相同照片的子图片中照片清晰度较大者的子图片保存作为合并第二类型子图片，组成合并第二类型子图片集。
69.其中，在进行所述第二类型子图片集中每一子图片与所述历史第二类型子图片集的合并存储时，可以选择其中图片清晰度更高的图片进行保留和存储，例如可以第二类型子图片集中医疗费用原始凭证图片对应图片大小是100kb，历史第二类型子图片集中历史医疗费用原始凭证图片对应图片大小是80kb，一般图片大小更大的图片是更清晰的，故可以选择第二类型子图片集中医疗费用原始凭证图片作为合并医疗费用原始凭证图片，所述第二类型子图片集中其他只图片的合并也可以参照上述方式，直至图片合并完毕。
70.s105、获取所述近似信息的信息上报时间，将所述信息上报时间作为所述合并后目标信息的合并信息上报时间。
71.在本实施例中，由于将近似且针对相同被保险人的目标信息进行了合并，为了更加合理的在目标数据库中针对各目标信息进行排序，可以采用以下原则：即是当后上传的b目标信息与之前已进入目标数据库且为未处理状态的a目标信息互为近似目标信息并可以合并，则b目标信息与a目标信息进行合并之后，合并后目标信息是继承a目标信息的信息上
报时间，这样该合并后目标信息再基于该a目标信息的信息上报时间在目标数据库中参与信息先后顺序的排列。
72.该方法应用于医学应用场景中，在医学应用场景中，门诊病历图片、住院病历图片、病理/血液/影像检查报告图片中包括有医学影像，医学影像包含的对象所属类型为病灶，即机体上发生病变的部分。医学影像是指为了医疗或医学研究，以非侵入方式取得的内部组织，例如，胃部、腹部、心脏、膝盖、脑部的影像，比如，ct(computed tomography，电子计算机断层扫描)、mri(magnetic resonance imaging，磁共振成像)、us(ultrasonic，超声)、x光图像、脑电图以及光学摄影灯由医学仪器生成的图像。
73.该方法实现了将针对同一用户在不同时段上传的目标信息及时进行检测和合并，降低了信息审核量，提高了数据处理效率。
74.本发明实施例还提供一种用户数据合并装置，该用户数据合并装置用于执行前述用户数据合并方法的任一实施例。具体地，请参阅图3，图3是本发明实施例提供的用户数据合并装置的示意性框图。该用户数据合并装置100可以配置于服务器中。
75.如图3所示，用户数据合并装置100包括：目标信息获取单元101、近似信息获取单元102、合并信息生成单元103、数据合并单元104、合并时间获取单元105。
76.目标信息获取单元101，用于响应于目标信息上传指令，获取与所述目标信息上传指令相应的目标信息。
77.在本实施例中，用户可以操作其使用的用户端并打开相应的app(即应用程序)上传目标信息，若本技术的具体应用场景是理赔场景，则目标信息可以理解为理赔信息，上传理赔信息一般需要填写关联姓名、理赔申请类型、受理业务编号、接收理赔金的转账账户、申请人/代办人姓名等信息，并上传监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片、医疗费用原始凭证图片、医疗费用明细清单/处方图片、购药增值税发票图片、门(急)病历图片、住院病历(出院小结)图片、病理/血液/影像检查报告图片、其他证明(出差/休假/职级等)图片、基金集体账户申请证明图片、意外事故证明或说明图片、代办委托电子签名(含手持身份证拍照)图片、代办委托纸质授权图片、授权委托书图片、理赔申请书图片等图片，这些信息被上传至服务器后，自动组合成目标信息。通过在线上传理赔资料的方式，便于进行在线审核资料。
78.在一实施例中，目标信息获取单元101包括：
79.用户账号信息获取单元，用于获取用户账户信息，并获取所述用户账户信息的关联姓名和受理业务编号；
80.初始填充单元，用于将所述关联姓名和受理业务编号填充至目标信息模板，得到初始填充目标信息；
81.补充填充单元，用于获取用户端上传的补充信息和业务关联图片，将所述补充信息和业务关联图片填充至所述初始填充目标信息，得到目标信息。
82.在本实施例中，当用户打开app上传目标信息时，一般是先输入用户账号和密码登录服务器，当登录成功后，服务器可获取到与该用户相应的用户账号信息，并自动获取到该用户的关联姓名和受理业务编号(这里的受理业务编号是基于用户之前投保的若干个保单中，自动检索出可进行自助理赔保单的受理业务编号)，然后基于后台数据库检索出来的与用户账户信息相应的关联姓名和受理业务编号自动填充至目标信息模板，得到初始填充目
标信息，此时目标信息模板中的其他信息还未上传。此时服务器接收用户端至上传的补充信息(例如理赔申请类型、接收理赔金的转账账户、申请人/代办人姓名等)和业务关联图片(例如上述列举的监护关系证明图片、监护人身份证明图片等)，当完成了补充信息和目标信息的接收后，也是填充到目标信息模板中相应的位置，从而得到了用户此次上传的完整的目标信息。通过这一结合自动填充和半自动填充的方式，能够更加快速的获取完整的目标信息以进行后续数据处理。
83.当服务器获取了此次用户上传了完整的目标信息后，还需解析获取其中包括的理赔案件信息，也就是自动获取关联姓名、理赔申请类型、受理业务编号、接收理赔金的转账账户、申请人/代办人姓名这些字段对应的具体取值，从而进行后续是否有相同被保险人的近似保单检索。
84.近似信息获取单元102，用于根据预设的信息检索策略在目标数据库中获取所述目标信息相应的近似信息；其中，所述信息检索策略用于在目标数据库中获取与所述目标信息具有相同预设参数且为未处理状态的近似信息。
85.在本实施例中，服务器中有一目标数据库，用于存储多个为未处理状态的目标信息，这些目标信息都是用户操作用户端填写理赔案件信息后上传至服务器以待审核的信息。为了提高目标信息分配至下一步人工审核或自动审核的效率，可以将一些明显是针对同一被保险人的目标信息进行合并后再审核，有效降低目标数据库中目标信息的总数量，提升审核效率。
86.在一实施例中，近似信息获取单元102还用于：
87.以所述目标信息中的预设的一个或多个参数为检索条件，若确定目标数据库中存在近似信息与所述目标信息具有相同的关联姓名、受理业务编号、受理业务申请类型及关联账号，获取所述近似信息。
88.其中，所述信息检索策略是以所获取到的理赔案件信息中关联姓名、理赔申请类型、受理业务编号、接收理赔金的转账账户、申请人/代办人姓名为检索条件，判断在目标数据库中是否检测到具有同一关联姓名，具有同一受理业务编号，具有同一理赔申请类型，具有同一接收理赔金的转账账户，且具有同一申请人/代办人姓名的目标信息，当满足上述条件时即可判断满足信息检索策略，从而在目标数据库中获取所述目标信息相应的近似信息。
89.由于目标数据库中各目标信息都是对应一个加入目标数据库的加入时间，一般近似信息的入池时间是早于所述目标信息的入池时间，将两者进行合并之后，可以使得后入池的目标信息与其近似的近似信息进行合并，从而起到了降低目标数据库中案件总数提升处理效率的作用。
90.合并信息生成单元103，用于根据所述近似信息相应的检索结果及预设的通知信息模板生成信息合并确认通知信息，将所述信息合并确认通知信息发送至用户端。
91.在本实施例中，当在目标数据库中检索到与所述目标信息最近似的近似信息后，可以直接生成一个信息合并确认通知信息，并发送至用户端以在用户端的界面上进行显示。例如所生成的信息合并确认通知信息如“您有相同类型未结理赔申请(申请号*****，报案号******)，本次理赔申请将合并至前次申请，处理优先顺序按前次申请为准。”92.在一实施例中，合并信息生成单元103还用于：
93.接收用户端根据回复确认信息触发生成的同意合并指令；
94.或者接收用户端在预设的回复时限阈值内未回复信息生成的同意合并指令。
95.其中，当用户端接收到如上述的信息合并确认通知信息后，可以回复确认信息以触发生成同意合并指令。也可以是在用户端接收到如上述的信息合并确认通知信息后若在指定回复时限(如在用户端接收到该信息合并确认通知信息的2小时内)未回复任何信息，也可以视为默认同意从而自动生成同意合并指令。
96.数据合并单元104，用于若确定接收到与所述信息合并确认通知信息相应的同意合并指令，根据预设的信息合并策略将所述目标信息与所述近似信息进行信息合并，得到合并后目标信息。
97.在本实施例中，当服务器接收到与所述信息合并确认通知信息相应的同意合并指令，则表示用户同意将该目标信息与所述近似信息进行合并，此时可以获取到预先设置的信息合并策略，以将所述目标信息与所述近似信息进行信息合并得到合并后目标信息。为了确保合并后的信息不会出现错误数据，在信息合并的过程中需遵循信息合并策略对应的合并规则，从而确保合并数据的准确性。
98.在一实施例中，所述信息合并策略为将所述目标信息与所述近似信息中相同字段对应的取值或图片进行合并，数据合并单元104包括：
99.理赔具体信息获取单元，用于获取所述目标信息中的关联姓名、受理业务编号、补充信息和业务关联图片；
100.近似具体信息获取单元，用于获取所述近似信息中的历史关联姓名、历史受理业务编号、历史补充信息和历史业务关联图片；
101.多类型数据合并单元，用于将所述历史关联姓名作为与所述关联姓名相应的合并关联姓名，将所述历史受理业务编号作为与所述受理业务编号相应的合并受理业务编号，将所述历史补充信息作为与所述补充信息相应的合并补充信息，将所述历史业务关联图片与所述业务关联图片合并保存作为合并业务关联图片；
102.合并信息组合单元，用于由所述合并关联姓名、所述合并受理业务编号、所述合并补充信息及所述合并业务关联图片组成合并后目标信息。
103.在本实施例中，由于关联姓名与历史关联姓名相同，且受理业务编号与历史受理业务编号相同，所述历史补充信息与所述补充信息相同，此时可以任选关联姓名与历史关联姓名之一作为合并关联姓名，同样的可以任选受理业务编号与历史受理业务编号之一作为合并受理业务编号，也可以任选所述历史补充信息与所述补充信息之一作为合并补充信息。由于用户在多次上传业务关联图片时可能上传的图片不完全相同，为了在合并目标信息确保无信息丢失，可以将各业务关联图片均进行合并后再保存即可。
104.在一实施例中，所述多类型数据合并单元，包括：
105.第一图像识别单元，用于通过图像识别获取所述业务关联图片中的第一类型子图片集和第二类型子图片集；其中，所述第一类型子图片集的图片合并属性为不可合并图片，所述第二类型子图片集的图片合并属性为可合并图片；
106.第二图像识别单元，用于通过图像识别获取所述历史业务关联图片中的历史第一类型子图片集和历史第二类型子图片集；其中，所述历史第一类型子图片集的图片合并属性为不可合并图片，所述历史第二类型子图片集的图片合并属性为可合并图片；
107.图片拼接单元，用于将所述第一类型子图片集与所述历史第一类型子图片集进行图片拼接，得到合并第一类型子图片集；
108.图片合并单元，用于若确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片，将所述历史第二类型子图片集作为合并第二类型子图片集；
109.图片组合单元，用于由所述合并第一类型子图片集及所述合并第二类型子图片集组成合并业务关联图片。
110.在本实施例中，具体实施时所述第一类型子图片集包括监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片；所述第二类型子图片集包括医疗费用原始凭证图片、医疗费用明细清单/处方图片、购药增值税发票图片、门诊病历图片、住院病历图片、病理/血液/影像检查报告图片、出差/休假/职级证明图片、基金集体账户申请证明图片、意外事故证明或说明图片、代办委托电子签名图片、代办委托纸质授权图片、授权委托书图片、理赔申请书图片；所述历史第一类型子图片集包括历史监护关系证明图片、历史监护人身份证明图片、历史代办人身份证明图片、历史被保险人身份证图片、历史结婚证明图片；所述历史第二类型子图片集包括历史医疗费用原始凭证图片、历史医疗费用明细清单/处方图片、历史购药增值税发票图片、历史门诊病历图片、历史住院病历图片、历史病理/血液/影像检查报告图片、历史出差/休假/职级证明图片、历史基金集体账户申请证明图片、历史意外事故证明或说明图片、历史代办委托电子签名图片、历史代办委托纸质授权图片、历史授权委托书图片、历史理赔申请书图片。由于监护关系证明图片、监护人身份证明图片、代办人身份证明图片、被保险人身份证图片、结婚证明图片对应的第一类型子图片集在每一次目标信息上传时，都是要完整保存以供后续查验的，故第一类型子图片集每上传一次是与前一次的历史第一类型子图片集进行图片拼接，从而完成的保存上传历史记录。
111.而第二类型子图片集对应的图片在每一次目标信息上传时，基本都是相同的，可以多次共用同一张图片，为了节省服务器中的存储空间，可以在确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片时，将所述历史第二类型子图片集作为合并第二类型子图片集。通过这一方式，可以确保合并后图片占用更少存储空间。
112.在一实施例中，所述图片合并单元还用于：
113.若确定所述第二类型子图片集中每一子图片与所述历史第二类型子图片集中相应子图片为相同图片，将对应相同照片的子图片中照片清晰度较大者的子图片保存作为合并第二类型子图片，组成合并第二类型子图片集。
114.其中，在进行所述第二类型子图片集中每一子图片与所述历史第二类型子图片集的合并存储时，可以选择其中图片清晰度更高的图片进行保留和存储，例如可以第二类型子图片集中医疗费用原始凭证图片对应图片大小是100kb，历史第二类型子图片集中历史医疗费用原始凭证图片对应图片大小是80kb，一般图片大小更大的图片是更清晰的，故可以选择第二类型子图片集中医疗费用原始凭证图片作为合并医疗费用原始凭证图片，所述第二类型子图片集中其他只图片的合并也可以参照上述方式，直至图片合并完毕。
115.合并时间获取单元105，用于获取所述近似信息的信息上报时间，将所述信息上报
时间作为所述合并后目标信息的合并信息上报时间。
116.在本实施例中，由于将近似且针对相同被保险人的目标信息进行了合并，为了更加合理的在目标数据库中针对各目标信息进行排序，可以采用以下原则：即是当后上传的b目标信息与之前已进入目标数据库且为未处理状态的a目标信息互为近似目标信息并可以合并，则b目标信息与a目标信息进行合并之后，合并后目标信息是继承a目标信息的信息上报时间，这样该合并后目标信息再基于该a目标信息的信息上报时间在目标数据库中参与信息先后顺序的排列。
117.该装置实现了将针对同一用户在不同时段上传的目标信息及时进行检测和合并，降低了信息审核量，提高了数据处理效率。
118.上述用户数据合并装置可以实现为计算机程序的形式，该计算机程序可以在如图4所示的计算机设备上运行。
119.请参阅图4，图4是本发明实施例提供的计算机设备的示意性框图。该计算机设备500是服务器，服务器可以是独立的服务器，也可以是多个服务器组成的服务器集群。
120.参阅图4，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括存储介质503和内存储器504。
121.该存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032被执行时，可使得处理器502执行用户数据合并方法。
122.该处理器502用于提供计算和控制能力，支撑整个计算机设备500的运行。
123.该内存储器504为存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行用户数据合并方法。
124.该网络接口505用于进行网络通信，如提供数据信息的传输等。本领域技术人员可以理解，图4中示出的结构，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
125.其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现本发明实施例公开的用户数据合并方法。
126.本领域技术人员可以理解，图4中示出的计算机设备的实施例并不构成对计算机设备具体构成的限定，在其他实施例中，计算机设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。例如，在一些实施例中，计算机设备可以仅包括存储器及处理器，在这样的实施例中，存储器及处理器的结构及功能与图4所示实施例一致，在此不再赘述。
127.应当理解，在本发明实施例中，处理器502可以是中央处理单元(central processing unit，cpu)，该处理器502还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field
‑
programmable gatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
128.在本发明的另一实施例中提供计算机可读存储介质。该计算机可读存储介质可以为非易失性的计算机可读存储介质，也可以是易失性的计算机可读存储介质。该计算机可
读存储介质存储有计算机程序，其中计算机程序被处理器执行时实现本发明实施例公开的用户数据合并方法。
129.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
130.在本发明所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为逻辑功能划分，实际实现时可以有另外的划分方式，也可以将具有相同功能的单元集合成一个单元，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
131.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
132.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
133.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read
‑
only memory)、磁碟或者光盘等各种可以存储程序代码的介质。
134.以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。