技术领域
[0001] 本
发明涉及互联网健康保障领域，尤其是一种互助保障服务器、系统及互助保障方法。
背景技术
[0002] 传统保险是指投保人根据合同约定向保险机构支付额度较高的保险费，保险机构对于合同约定的可能发生的事故因其发生所造成的财产损失承担赔偿保险金责任，或者被保险人死亡、伤残、
疾病或者达到合同约定的年龄、期限等条件时承担给付保险金责任的商业保险行为。
[0003] 对于普通收入的人群，面对重疾和意外问题，社保和新农合只能解决一部分问题，还需额外的保险保障才能顶住压
力渡过难关，但是，当前传统保险的模式
门槛高、性价比低，而且，传统保险通过人工进行办理，
申请办理保险或申请理赔时，手续相对比较繁琐，办理效率比较低；而且，用户缴纳保险
费用之后也完全不知道保险机构如何使用保费，针对用户来说，资金处理透明度较低。
[0004] 有鉴于此，如何让用户以低廉的价格享受优质高效、高性价比、公开透明的健康保障，成了当前社会急需解决的一大问题。
发明内容
[0005] 本发明
实施例所要解决的一个技术问题是如何提供一种互助保障服务器、系统及互助保障方法，让人们以低廉的价格享受优质高效、高性价比、公开透明的健康保障。
[0006] 本发明提供一种互助保障服务器，包括：接收模
块，用于接收用户发送的加入设定互助计划的消息；第一处理模块，与所述接收模块相连接，用于根据用户发送的加入设定互助计划的消息判断所述用户是否符合加入设定互助计划的第一设定条件；若用户确认符合加入设定互助计划的第一设定条件，则将用户加入到设定互助计划的等待
数据库中；第二处理模块，与所述第一处理模块相连接，用于判断加入到设定互助计划的所述等待数据库中的所述用户是否满足第二设定条件；若所述等待数据中的所述用户满足第二设定条件，则将所述用户加入到设定互助计划的互助保障数据库中以便所述用户享受互助保障。
[0007] 进一步地，所述第一设定条件包括：所述用户确认符合所选设定互助计划的对应协议；用户支付的互助金满足加入到所选设定互助计划的设定金额条件。
[0008] 进一步地，所述服务器还包括发送模块，所述发送模块与所述第一处理模块、第二处理模块相连接，用于根据所述接收到的用户发送的加入设定互助计划的消息向所述用户发送相应的设定互助计划的协议以便用户的终端展示给用户；第一处理模块包括第一处理单元和第二处理单元，
[0009] 其中，
[0010] 第一处理单元用于判断所述用户是否确认符合所选互助计划的对应协议；
[0011] 第二处理单元与所述第一处理单元相连接，用于若所述用户确认符合所选互助计划的对应协议之后，判断所述用户是否支付了不小于所选设定互助计划的设定金额的互助金；若确定所述用户支付了不小于所选设定互助计划的设定金额的互助金，则将所述用户的加入到设定互助计划的等待数据库中；
[0012] 所述服务器还包括支付处理模块，所述支付处理模块与所述接收模块、所述第一处理模块、第二处理模块相连接，用于将所述用户支付的互助金存入所述用户的资金存管账户中。
[0013] 进一步地，所述第二设定条件包括：所述用户的互助金金额不小于设定互助计划的享受互助保障的互助金
阈值；所述加入到设定互助计划的所述等待数据库中的所述用户满足设定互助计划享受互助保障的设定时限条件，其中，所述设定时限条件设定时限条件包括所述加入到设定互助计划的等待数据库中用户的等待时间大于设定等待时间；所述加入到设定互助计划的所述等待数据库中的所述用户满足设定互助计划享受互助保障的设定时限条件还包括所述用户不处于休眠期或惩罚期；所述第二处理模块包括第三处理单元、第四处理单元、第五处理单元；其中，第三处理单元用于判断所述用户的互助金金额是否小于设定互助计划的享受互助保障的互助金阈值；第四处理单元用于判断加入到设定互助计划的所述等待数据库中的所述用户是否满足设定互助计划享受互助保障的设定时限条件，其中，所述设定时限条件包括所述加入到设定互助计划的等待数据库中用户的等待时间大于设定等待时间；第五处理单元用于判断所述用户是否处于休眠期或惩罚期；
[0014] 其中，
[0015] 若用户的互助金小于设定的互助金阈值的时间小于或等于第一设定时间，所述用户处于休眠期；
[0016] 若用户的互助金小于设定的互助金阈值时间大于第一设定时间且小于或等于第二设定时间，所述用户处于惩罚期；
[0017] 若用户的互助金小于设定的互助金阈值的时间大于第二设定时间，则将所述用户从所述设定互助计划的等待数据库中删除，若用户申请加入互助保障数据库，需要重新计算以便判断所述加入到设定互助计划的等待数据库中用户的等待时间是否满足设定互助计划享受互助保障的设定时限条件。
[0018] 进一步地，所述服务器还包括理赔模块，所述理赔模块与所述接收模块、所述第二处理模块、支付模块、发送模块相连接，所述理赔模块包括理赔条件判断单元、内审单元；理赔条件判断单元用于判断所述用户是否是加入到设定互助计划的互助保障数据库中用户，若所述用户是互助保障数据库中的享受互助保障的用户，判断所述用户提交的理赔
请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围；内审单元，用于如果所述用户提交的理赔请求的案件信息符合所述用户对应的互助计划的设定的理赔案件范围，对所述用户提交的案件信息进行内审审核以确认用户的理赔请求是否符合要求，其中，所述内审审核包括通过光学字符识别OCR、
人工智能AI、
大数据风险控制对用户资料进行审核；其中，所述内审审核还包括将通过OCR、AI、大数据风险控制对所述用户的资料进行审核确定的有疑点的、无法确认的案件展示给管理人员以便管理人员进行人工审核，并将人工审核的结果通过大数据的方式进行
迭代；所述发送模块用于若用户提交的案件信息进行内审审核通过，将用户的案件信息提交第三方公估机构服务器以便第三方公估机构核实，通过接收模块接收第三方公估机构核实结果。
[0019] 进一步地，所述服务器还包括公示模块，用于若经过内审或公估核实确认所述用户的理赔请求是符合要求理赔请求后，将所述发起理赔请求的用户审核结果进行公示。
[0020] 进一步地，所述服务器还包括互助金均摊处理模块，用于如果公示结果无
异议，根据设定互助计划的设定均摊互助金方式对所述用户的进行理赔。
[0021] 进一步地，所述理赔条件判断单元用于判断所述用户是否满足加入时签订的所选设定互助计划的对应协议；判断用户提交的案件信息中的所患疾病信息是否协议所规定的理赔疾病的信息。
[0022] 进一步地，所述内审单元还用于对提交理赔案件的所述用户进行AI方法进行
活体检测、
人脸识别，确定所述用户是否加入到设定互助计划的享受互助的有效用户。
[0023] 进一步地，所述内审单元还用于通过OCR识别用户提交的资料。
[0024] 进一步地，所述内审单元还用于根据敏感词模型Match-LSTM识别用户资料中的关键词判断所述用户的理赔请求是否符合要求；其中，所述用户的资料包括：身份证信息、
银行卡信息、病历信息、诊断报告信息、医学检测报告信息；所述判断所述用户的理赔请求是否符合要求包括根据提交的病历信息、诊断报告信息、医学检测报告信息判断所述用户的请求理赔的疾病是否是符合设定互助计划的对应协议所规定的疾病。
[0025] 进一步地，所述内审单元还用于以大数据风险控制方式通过分析数据库内的数据和第三方的数据，对发起理赔请求的用户进行审核。
[0026] 进一步地，互助金均摊处理模块用于：在公示结束后的设定时间段内，计算设定互助计划需要提供互助保障服务的理赔用户人数，总互助金额；将申请理赔的享受互助保障的用户设置为保护状态，不需要履行均摊义务；
[0027] 在公示结束后的设定时间段内确定需要均摊的用户，计算设定互助计划内每个需要均摊的用户的均摊金额，将需要均摊的用户在对应计划内的均摊额进入冻结状态，即使用户退出，冻结金额也无法退款；其中，参与均摊的用户每次均摊额不超过设定分摊金额，和\或，参与均摊的每个用户每个设定时间段内为每个患病的用户的均摊额不超过设定分摊金额，和\或，用户每个设定时间段内的均摊额的总金额不超过设定分摊总额。
[0028] 进一步地，在计算得到应发给所述互助用户的互助金后，将所述发送资金的指令发送给资金托管方，资金托管方根据指令均摊额从用户账户、资金池中扣除均摊额度，资金托管方对所述申请理赔的用户进行理赔拨款。
[0029] 进一步地，所述服务器还包括退出处理模块，用于在进行均摊后，记录设定互助计划内每个用户的当前金额，将余额低于设定金额的用户从所述互助保障数据库中删除，并记录失去互助保障资格的时间，根据失去互助保障资格的时间将用户设置为休眠期用户、惩罚期用户或将所述用户从所述设定互助计划的数据库中删除。
[0030] 进一步地，退出处理模块还用于用户申请并或获得理赔之后，将所述获得理赔拨款的用户从所述享受互助保障的互助保障数据库中删除。
[0031] 进一步地，所述退出处理模块还用于：判断是否收到数据库中用户的申请退出互助保障的信息，所述数据库包括等待数据库、互助保障数据库；若接收到用户申请退出互助保障的信息，将用户的信息从其对应的设定互助计划的数据库中移除，将所述用户账户中的剩余的互助金返还给用户。
[0032] 进一步地，所述第一设定条件还包括：用户的信用值满足设定条件并且用户绑定了用户的支付账户；第一处理模块用于通过第三方信用平台判定用户的信用值，若用户的信用值满足设定的信用条件，则免除用户的支付所述设定金额互助金的义务，在进行均摊的时候从用户的银行卡或理财账户中扣款。
[0033] 进一步地，所述设定互助计划包括少儿健康互助计划、中青年抗癌计划、中老年抗癌计划、百万终身抗癌计划、综合意外互助计划、大爱互助计划，所述各个设定互助计划包括预先设定的与各个设定互助计划相适应的第一设定条件、第二设定条件以及事件范围、最高获助规则、分摊规则、余额要求规则、等待期规则。
[0034] 本发明还提供一种互助保障系统，包括：如上所述的互助保障服务器；第三方公估机构服务平台；第三方资金管理平台；以及用户终端。
[0035] 本发明还提供一种互助保障方法，包括：根据用户发送的加入设定互助计划的消息判断所述用户是否符合加入设定互助计划的第一设定条件；若用户确认符合加入设定互助计划的第一设定条件，则将用户加入到设定互助计划的等待数据库中；判断加入到设定互助计划的所述等待数据库中的所述用户是否满足第二设定条件；若所述等待数据中的所述用户满足第二设定条件，则将所述用户加入到设定互助计划的互助保障数据库中以便所述用户享受互助保障。
[0036] 进一步地，所述第一设定条件包括：所述用户确认符合所选设定互助计划的对应协议；用户支付的互助金满足加入到所选设定互助计划的设定金额条件。
[0037] 进一步地，所述方法还包括：接收到用户发送的加入设定互助计划的消息；根据所述接收到的用户发送的加入设定互助计划的消息向所述用户展示相应的设定互助计划的协议；判断所述用户是否确认符合所选互助计划的对应协议；若所述用户确认符合所选互助计划的对应协议之后，判断所述用户是否支付了不小于所选设定互助计划的设定金额的互助金；若确定所述用户支付了不小于所选设定互助计划的设定金额的互助金，则将所述用户的加入到设定互助计划的等待数据库中；将所述用户支付的互助金存入所述用户的资金存管账户中。
[0038] 进一步地，所述第二设定条件包括：所述用户的互助金金额不小于设定互助计划的享受互助保障的互助金阈值；所述加入到设定互助计划的所述等待数据库中的所述用户满足设定互助计划享受互助保障的设定时限条件，其中，所述设定时限条件包括所述加入到设定互助计划的等待数据库中用户的等待时间大于设定等待时间；所述加入到设定互助计划的所述等待数据库中的所述用户满足设定互助计划享受互助保障的设定时限条件还包括所述用户不处于休眠期或惩罚期；
[0039] 其中，
[0040] 若用户的互助金小于设定的互助金阈值的时间小于或等于第一设定时间，所述用户处于休眠期；
[0041] 若用户的互助金小于设定的互助金阈值时间大于第一设定时间且小于或等于第二设定时间，所述用户处于惩罚期；
[0042] 若用户的互助金小于设定的互助金阈值的时间大于第二设定时间，则将所述用户从所述设定互助计划的等待数据库中删除，若用户重新申请加入互助保障数据库，需要重新计算所述加入到设定互助计划的等待数据库中用户的等待时间是否大于设定等待时间。
[0043] 进一步地，所述方法还包括：在接收到用户的理赔请求之后，判断所述用户是否是加入到设定互助计划的互助保障数据库中用户，其中包括：判断所述用户是否符合第二设定条件；若所述用户是互助保障数据库中的享受互助保障的用户，判断所述用户提交的理赔请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围；如果所述用户提交的理赔请求的案件信息符合所述用户对应的互助计划的设定的理赔案件范围，对所述用户提交的案件信息进行内审审核以确认用户的理赔请求是否符合要求，其中，所述内审审核包括通过光学字符识别OCR、人工智能AI、大数据风险控制对用户资料进行审核；其中，所述内审审核还包括对通过OCR、AI、大数据风险控制对所述用户的资料进行审核确定的有疑点的、无法确认的案件展示给管理人员以便管理人员进行人工审核，并将人工审核的结果加入到
算法数据库中进行迭代；若用户提交的案件信息进行内审审核通过，则将用户的案件信息提交第三方公估机构核实；若经过内审或公估核实确认所述用户的理赔请求是符合要求请求后，将所述发起理赔请求的用户审核结果进行公示；若公示结果无异议，根据设定互助计划的设定均摊互助金方式对所述用户的进行理赔。
[0044] 进一步地，所述判断所述用户提交的理赔请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围包括：判断所述用户是否满足加入时签订的所选设定互助计划的对应协议；判断用户提交的案件信息中的所患疾病信息是否协议所规定的理赔疾病的信息。
[0045] 进一步地，所述通过光学字符识别OCR、人工智能AI、大数据风险控制对用户资料进行审核包括：对提交理赔案件的所述用户进行AI方法进行活体检测、人脸识别，确定所述用户是否加入到设定互助计划的享受互助的有效用户；通过OCR识别用户提交的资料，根据敏感词模型Match-LSTM识别用户资料中的关键词判断所述用户的理赔请求是否符合要求；其中，所述用户的资料包括：身份证信息、银行卡信息、病历信息、诊断报告信息、医学检测报告信息；所述判断所述用户的理赔请求是否符合要求包括根据提交的病历信息、诊断报告信息、医学检测报告信息判断所述用户的请求理赔的疾病是否是符合设定互助计划的对应协议所规定的疾病；以大数据风险控制方式通过分析数据库内的数据和第三方的数据，对发起理赔请求的用户进行审核。
[0046] 进一步地，若公示结果无异议，根据设定互助计划的设定均摊互助金方式对所述用户的进行理赔包括：在公示结束后的设定时间段内，计算设定互助计划需要提供互助保障服务的理赔用户人数，总互助金额；将申请理赔的享受互助保障的用户设置为保护状态，不需要履行均摊义务；在公示结束后的设定时间段内确定需要均摊的用户，计算设定互助计划内每个需要均摊的用户的均摊金额，将需要均摊的用户在对应计划内的均摊额进入冻结状态，即使用户退出，冻结金额也无法退款；其中，参与均摊的用户每次均摊额不超过设定分摊金额，和\或，用户每个设定时间段内的均摊额的总金额不超过设定分摊总额；在计算得到应发给所述互助用户的互助金后，将所述发送资金的指令发送给资金托管方，资金托管方根据指令均摊额从用户账户、资金池中扣除均摊额度，资金托管方对所述申请理赔的用户进行理赔拨款。
[0047] 进一步地，所述方法还包括：在进行均摊后，记录设定互助计划内每个用户的当前金额，将余额低于设定金额的用户从所述互助保障数据库中删除，并记录失去互助保障资格的时间，根据失去互助保障资格的时间将用户设置为休眠期用户、惩罚期用户或将所述用户从所述设定互助计划的数据库中删除。
[0048] 进一步地，用户申请并或获得理赔之后，将所述获得理赔拨款的用户从所述享受互助保障的互助保障数据库中删除。
[0049] 进一步地，还包括：判断是否收到数据库中用户的申请退出互助保障的信息，所述数据库包括等待数据库和互助保障数据库；若接收到用户申请退出互助保障的信息，将用户的信息从其对应的设定互助计划的数据库中移除，将所述用户账户中的剩余的互助金返还给用户。
[0050] 进一步地，所述第一设定条件还包括：用户的信用值满足设定条件并且用户绑定了用户的支付账户；其中，通过第三方信用平台判定用户的信用值，若用户的信用值满足设定的信用条件，则免除用户的支付所述设定金额互助金的义务，在进行均摊的时候从用户的银行卡或理财账户中扣款。
[0051] 进一步地，所述设定互助计划包括少儿健康互助计划、中青年抗癌计划、中老年抗癌计划、百万终身抗癌计划、综合意外互助计划、大爱互助计划，所述各个设定互助计划包括预先设定的与各个设定互助计划相适应的第一设定条件、第二设定条件、理赔案件范围，以及最高获助规则、分摊规则、余额要求规则、等待期规则。
[0052] 进一步地，所述在公示结束后的设定时间段内确定需要均摊的用户，计算设定互助计划内每个需要均摊的用户的均摊金额，包括：参与均摊的用户每次均摊额不超过设定分摊金额。
[0053] 进一步地，参与均摊的每个用户每个设定时间段内为每个患病的用户的均摊额不超过设定分摊金额。
[0054] 进一步地，用户每个设定时间段内的均摊额的总金额不超过设定分摊总额。
[0055] 本发明实施例提供的互助保障服务器、系统及互助保障方法，可以基于互联网技术为用户提供互助保障服务，使得用户可以通过移动终端等方便的加入互助保障，系统对用户资金的使用完全公示公开，资金使用公开透明，而且一旦用户不幸患病，互助保障系统提供的理赔服务效率较高，可以让更多的人以低廉的价格享受优质高效、高性价比、公开透明的健康保障。
[0056] 下面通过
附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
[0057] 构成
说明书的一部分的附图描述了本发明的实施例，并且连同描述一起用于解释本发明的原理。
[0058] 参照附图，根据下面的详细描述，可以更加清楚地理解本发明，其中：
[0059] 图1为本发明互助保障方法的一个实施例的
流程图。
[0060] 图2为本发明互助保障方法的另一个实施例的流程图。
[0061] 图3为本发明互助保障方法的又一个实施例的流程图。
[0062] 图4为本发明互助保障方法的再一个实施例的流程图。
[0063] 图5为本发明互助保障方法的一个实施例的用户加入中青年互助保障系统的流程图。
[0064] 图6为本发明互助保障方法的一个实施例的中青年互助保障系统中对用户理赔处理的流程图。
[0065] 图7为本发明互助保障服务器的一个实施例的结构
框图。
[0066] 图8为本发明互助保障服务器的另一个实施例的结构框图。
[0067] 图9为本发明互助保障服务器的又一个实施例的结构框图。
具体实施方式
[0068] 现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
[0069] 同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
[0070] 以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。
[0071] 对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
[0072] 应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
[0073] 本发明实施例可以应用于
计算机系统/服务器，其可与众多其它通用或专用计算系统环境或配置一起操作。适于与计算机系统/服务器一起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于
微处理器的系统、机顶盒、可编程
消费电子产品、网络个人电脑、小型计算机系统﹑大型计算机系统和包括上述任何系统的分布式
云计算技术环境，等等。
[0074] 计算机系统/服务器可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。
[0075] 本发明基于互联网技术提供了一种互助保障方法。图1为本发明互助保障方法的一个实施例的流程图，如图1所示，该方法包括：
[0076] 步骤101，根据用户发送的加入设定互助计划的消息判断所述用户是否符合加入设定互助计划的第一设定条件；若用户确认符合加入设定互助计划的第一设定条件，则将用户加入到设定互助计划的等待数据库中。
[0077] 在一个实施例中，用户发送的加入设定互助计划的消息可以包括注册信息、确认信息、支付信息等。举例而言，用户通过微信、支付宝、link、facebook、twitter、微博等互联网
软件或互助保障软件的App如
水滴互助APP或水滴互助的
网站填写个人信息，进行互助保障的用户注册。
[0078] 在一个实施例中，所述设定的互助计划包括并不限于抗癌互助计划、综合意外互助计划。所述抗癌互助计划包括针对健康用户的抗癌互助计划、以及针对疾病用户的抗癌互助计划；所述针对健康用户的抗癌互助计划包括少儿抗癌互助计划(可选的，可以为出生后28天-17岁)、中青抗癌互助计划(可选的，18岁-50岁)、中老抗癌互助计划(可选的，可以为51-65岁)、百万终身抗癌计划。所述针对疾病用户的计划包括大爱互助计划，如果用户曾经不幸罹患相关疾病，可以申请加入大爱互助计划。
[0079] 在一个实施例中，第一设定条件包括：所述用户确认符合所选设定互助计划的对应协议；所述设定互助计划的对应协议包括用户的年龄、用户的健康情况、用户确认认同遵守《互助会员公约》及计划条款。
[0080] 在一个实施例中，第一设定条件还包括：用户支付的互助金满足加入到所选设定互助计划的设定金额条件。举例而言，该设定金额条件可以为最低9元，交纳9元互助金，最高可以获得30万或100万互助保障；相对于传统保险，用户需要交的互助金远远低于传统保险的保费，可以大大缓解用户的经济压力。
[0081] 在一个实施例中，互助保障系统还可以通过第三方信用平台判定用户的信用值，如果用户的信用值满足设定的条件，则可以免除用户的支付所述设定金额互助金的义务，在进行均摊的时候可以从用户的银行卡或理财账户中扣款，并且每年约定一个最大扣款额度。进一步地，参与均摊的每个用户每个设定时间段内为每个患病的用户的均摊额不超过设定分摊金额。
[0082] 举例而言，如果信用值大于85分(百分制)的信用值等，可以享受绑定银行卡、免除加入时候支付互助金的义务；一旦互助保障数据库中有用户发生疾病进行理赔，其他每个用户为每个发生疾病的用户的分摊金额不超过0.01元。
[0083] 在一个实施例中，等待数据库可以是服务器端的
存储器，将用户加入到设定互助计划的等待数据库，即是将用户的信息加入添加到该存储器中，所述用户的信息包括用户姓名、身份证、用户加入的设定互助计划、用户加入的设定互助计划的时间、用户的当前金额、用户分摊过的金额等。
[0084] 在一个实施例中，少儿健康互助计划、中青年抗癌计划、中老年抗癌计划、百万终身抗癌计划、综合意外互助计划、大爱互助计划的首次加入的充值金额、每次分摊的均额，加入年龄、保障范围、总费用预估如下表所示。
[0085]
[0086]
[0087] 步骤102，判断加入到设定互助计划的所述等待数据库中的所述用户是否满足第二设定条件；若所述等待数据中的所述用户满足第二设定条件，则将所述用户加入到设定互助计划的互助保障数据库中以便所述用户享受互助保障，具体地，如果互助保障数据库中的用户不幸发生属于设定互助保障的事件范围的事情情况，互助保障平台根据用户的情况、获助规则进行理赔。
[0088] 在一个实施例中，所述第二设定条件包括：所述用户的互助金金额不小于设定互助计划的享受互助保障的互助金阈值，举例而言，所述互助金阈值可以为1元、2元、5元等。
[0089] 在一个实施例中，所述第二设定条件包括：将所述加入到设定互助计划的等待数据库中用户的等待时间满足设定互助计划享受互助保障的设定时限条件。其中，用户需要度过一定的等待期才能平台提供的享受互助保障，且用户所述用户不处于休眠期或惩罚期，才可以享受互助保障，。
[0090] 在一个实施例中，设定时限条件可以为30天、90天、180天，用户加入到设定的互助计划通过设定的等待期30天、90天、或180天等。
[0091] 在一个实施例中，若用户的互助金小于设定的互助金阈值的时间小于或等于第一设定时间，所述用户处于休眠期，其中，该第一设定时间可以为7天或15天，或者不大于30天的任何一个值。
[0092] 在一个实施例中，可以设置多个第一设定时间，可以根据第一设定时间的时长确定休眠期时长。
[0093] 在一个实施例中，可以设置互助金阈值为1元或者2元。
[0094] 在一个实施例中，若用户的互助金小于设定的互助金阈值时间大于第一设定时间且小于或等于第二设定时间，所述用户处于惩罚期，其中，该第二设定时间可以为30天、45天或60天。
[0095] 在一个实施例中，若用户的互助金小于设定的互助金阈值的时间大于第二设定时间，则将所述用户从所述设定互助计划的等待数据库中删除，若用户重新申请加入互助保障数据库，需要重新计算以便判断将所述加入到设定互助计划的等待数据库中用户的等待时间满足设定互助计划享受互助保障的设定时限条件。在一个实施例中，可以设置多个第二设定时间，根据第二设定时间的时长确定惩罚期时长。
[0096] 在一个实施例中，用户账户余额低于互助金阈值1元，用户得权利进入休眠期，所述休眠期为15天。提示用户“您账户余额低于1元，已进入休眠期，请充值后再进行申请”。惩罚期可以为用户超过15天充值会产生惩罚期，充值时间越晚惩罚期越长，具体可以为根据不同互助计划协议设置不同的惩罚期。
[0097] 在一个实施例中，不同的互助计划的获得互助的规则是不相同的，举例而言，不同年龄段段的用户可以获得不同额度的互助金。
[0098] 在一个实施例中，如果用户如果已经加入了互助保障的会员服务，系统可以根据用户的年龄自动调整用户的互助计划以与互助规则相适配，例如，如果加入的时候，用户是18岁-50岁，用户可以享受中青抗癌互助计划的互助保障；但是，如果互助会员的年龄超过了50岁，那么自动将用户享受的互助保障更改为中老抗癌互助计划。
[0099] 在一个实施例中，针对不同互助计划、不同年龄段的人群，用户获得互助金额是不相同的。举例而言，中老年抗癌互助计划的最高额度可以为10万元，针对中青年抗癌互助计划可以为30万元，具体地，针对中青年抗癌互助计划，不同年龄段会员可获得的最高互助金额也可以设置为不相同，具体如下：
[0100]年龄(周岁) 重度癌症 低度
恶性肿瘤18-30 30万元 5万元
31-40 25万元 5万元
41-50 20万元 5万元
[0101] 本发明实施例的提供的互助保障方法，用户可以通过互联网、移动互联网便捷的加入互助保障系统中，一旦用户通过等待期即可享受保障，该互助保障方法可以让更多的人以非常低廉的价格享受优质高效的互助保障。
[0102] 图2为本发明互助保障方法的另一个实施例的流程图，如图2所示，该方法包括：
[0103] 步骤201，接收到用户发送的加入设定互助计划的消息。
[0104] 步骤202，根据所述接收到的用户发送的加入设定互助计划的消息向所述用户展示相应的设定互助计划的协议。
[0105] 步骤203，判断所述用户是否确认符合所选互助计划的对应协议，如果用户确认不符合所选互助计划的对应协议，则退出流程。举例而言，可以是返回用户客户端APP主界面。
[0106] 步骤204，若所述用户确认符合所选互助计划的对应协议之后，判断所述用户是否支付了不小于所选设定互助计划的设定金额的互助金。如果用户未支付设定金额的互助金，则提示用户或退出流程。
[0107] 步骤205，若确定所述用户支付了不小于所选设定互助计划的设定金额的互助金，则将所述用户的加入到设定互助计划的等待数据库中。
[0108] 步骤206，将所述用户支付的互助金存入所述用户的资金存管账户中。
[0109] 本发明实施例的互助保障方法，用户加入互助计划时支付的互助金以及用户患病申请的互助金存入在资金存管账户中，并且资金完全受第三方公益机构监管，资金管理安全。
[0110] 图3为本发明互助保障方法的又一个实施例的流程图，如图3所示，该方法包括：
[0111] 步骤301，在接收到用户的理赔请求之后，判断所述用户是否是加入到设定互助计划的互助保障数据库中的用户。
[0112] 在一个实施例中，判断所述用户是否是加入到设定互助计划的互助保障数据库中用户可以是判断所述用户是否符合第二设定条件。
[0113] 步骤302，若所述用户是互助保障数据库中的享受互助保障的用户，判断所述用户提交的理赔请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围。
[0114] 在一个实施例中，判断所述用户提交的理赔请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围包括：判断所述用户是否满足加入时签订的所选设定互助计划的对应协议；判断用户提交的案件信息中的所患疾病信息是否协议所规定的理赔疾病的信息。
[0115] 在一个实施例中，所述理赔案件范围可以表示事件范围信息，例如中青年抗癌计划的事件范围：胃癌、肝癌等各种癌症，所有恶性肿瘤(癌症)，但是可以设定一些特殊情况不属于可理赔的癌类疾病。
[0116] 在一个实施例中，不同的互助计划可以设置不同的理赔案件信息，用户申请理赔的时候，需要按照相关要求提供完整的信息，例如会员姓名、身份证号码、互助计划、疾病名称、联系人电话互助会员信息、收款信息、互助申请表、病历报告、住院病历、已付医疗费发票信息等；如果用户不按照互助系统规定的方式提供资料，审核无法通过。
[0117] 步骤303，如果所述用户提交的理赔请求的案件信息符合所述用户对应的互助计划的设定的理赔案件范围，对所述用户提交的案件信息进行内审审核以确认用户的理赔请求是否符合要求。
[0118] 在一个实施例中，所述内审审核包括通过OCR、AI、大数据风险控制对所述用户的资料进行审核。
[0119] 在一个实施例中，对提交理赔案件的所述用户进行AI方法进行活体检测、人脸识别，确定所述用户是否加入到设定互助计划的享受互助的有效用户。
[0120] 在一个实施例中，通过OCR识别用户提交的资料，根据敏感词模型Match-LSTM识别用户资料中的关键词判断所述用户的理赔请求是否符合要求。
[0121] 在一个实施例中，所述用户的资料包括但是不限于：身份证信息、银行卡信息、病历信息、诊断报告信息、医学检测报告信息。
[0122] 在一个实施例中，所述判断所述用户的理赔请求是否符合要求包括根据提交的病历信息、诊断报告信息、医学检测报告信息判断所述用户的请求理赔的疾病是否是符合设定互助计划的对应协议所规定的疾病。
[0123] 在一个实施例中，以大数据风险控制方式通过分析数据库内的数据和第三方的数据，对发起理赔请求的用户进行审核。
[0124] 在一个实施例中，所述内审审核还包括对通过OCR、AI、大数据风险控制对所述用户的资料进行审核确定的有疑点的、无法确认的案件展示给管理人员以便管理人员进行人工审核，并将人工审核的结果加入到算法数据库中进行迭代。
[0125] 步骤304，若用户提交的案件信息进行内审审核通过，则将用户的案件信息提交第三方公估机构核实。
[0126] 步骤305，若经过内审或公估核实确认所述用户的理赔请求是符合要求请求后，将所述发起理赔请求的用户审核结果进行公示。
[0127] 步骤306，若公示结果无异议，根据设定互助计划的设定均摊互助金方式对所述用户的进行理赔。在一个实施例中，可以根据用户的情况进行一次性理赔或分期理赔。
[0128] 本发明实施例的互助保障方法，用户如果不幸患病发起理赔后，系统通过含有OCR、AI、大数据分析的内审系统快速审核用户提供的理赔材料，相对于传统的保险人工审核的方式，可以通过人工智能方法快速智能审核，对通过内部核准通过的理赔订单交给第三方机构进行公估，如果内审和第三方公估机构公估通过，通过公示系统公示理赔信息接收全平台用户的监督，相对于传统的保险，本发明提供的互助保障方法，处理理赔的速度更快，更有利于保障用户利益。
[0129] 图4为本发明互助保障方法的再一个实施例的流程图，如图4所示，该方法包括：
[0130] 步骤401，在公示结束后的设定时间段内，计算设定互助计划需要提供互助保障服务的理赔用户人数，总互助金额；将申请理赔的享受互助保障的用户设置为保护状态，不需要履行均摊义务。
[0131] 步骤402，在公示结束后的设定时间段内确定需要均摊的用户，计算设定互助计划内每个需要均摊的用户的均摊金额，将需要均摊的用户在对应计划内的均摊额进入冻结状态，即使用户退出，冻结金额也无法退款。
[0132] 步骤403，在计算得到应发给所述互助用户的互助金后，将所述发送资金的指令发送给资金托管方，资金托管方根据指令均摊额从用户账户、资金池中扣除均摊额度，资金托管方对所述申请理赔的用户进行理赔拨款。
[0133] 在一个实施例中，患者提交互助申请、身份证明材料、医疗证明材料；内部审核、公估并出具报告向所有会员公示后，公示结束第一天凌晨，进行均摊互助金理赔。具体包括：每个计划需要互助的患者人数，总互助金额；需要互助的患者在申请互助的计划中，进入保护状态，不需要履行均摊义务；凌晨某一时刻计算该计划内，每个当前有效用户的均摊金额，并记录(计划，用户，均摊金额)；需要均摊的用户在对应计划内的均摊额进入冻结状态，即使用户退出，冻结金额也无法退款；当天某个时刻进行划款，均摊额从用户账户、资金池中扣除；余额低于1元的用户失去保障资格，并记录失去保障资格的时间；15天以内充值，可以恢复保障；但是这段失去保障的时段，是不算入等待期的。
[0134] 在一个实施例中，均摊金额的计算算法如下：
[0135] 枚举每一个有需要进行互助均摊的计划，对其中每一个计划进行均摊计算；
[0136] 假设互助计划A中有P个需互助的患者(p1,p2,p3...)，每个人所需的金额是(m1,m2,m3...)，总金额和记为M:
[0137] 计算每个互助计划需要均摊的金额：
[0138] 统计符合条件的订单量N，过滤订单条件(余额>＝1且认证通过，且排除P个需要互助的患者、排除已经互助过的患者)会员。
[0139] 每人均摊金额si＝M/N，精确到分，向上取整，每个会员的每个订单均摊金额不超过3元。
[0140] 均摊总金额S＝si*N，S大于等于M时，将S-M放入结余资金；S小于M时，从结余里补足。每位患者的实际可得互助金：如果S大于等于M，金额充足，每人获取所需的金额；如果S小于M，按每个人申请金额与总金额的比例分配；不足额时，多余的金额放入结余。
[0141] 冻结用户金额：冻结用户应该均摊的金额；用户退款时，冻结金额不退。
[0142] 扣除用户金额：7天后公示无疑问将用户均摊金额从订单余额中扣除。
[0143] 重复上述步骤，计算每一个互助计划，得出每个计划内：1、(计划id，用户id，需要均摊金额)；2、(计划id，患者id，实际可得到的互助金)。
[0144] 在一个实施例中，可以按照期限进行互助金分摊，举例而言，假如每人加入互助系统的最低金额为9元，系统内有1亿人。在一个分摊期限，有100人申请癌症互助计划，那么按照每人理赔30万，需要支付3000万互助金，每个人扣除的互助金为30000000÷(1亿人-100人)，每人约扣款0.3元。
[0145] 在一个实施中，可以约定每个用户在每个理赔周期的均摊扣款均不超过设定值，如中青年抗癌计划每次不超过3元。这样，可以降低互助理赔额度，保障公平合理的赔付同时保证互助平台内用户的权利。
[0146] 在一个实施例中，在进行均摊后，记录设定互助计划内每个用户的当前金额，将余额低于设定金额的用户从所述互助保障数据库中删除，并记录失去互助保障资格的时间，根据失去互助保障资格的时间将用户设置为休眠期用户、惩罚期用户或将所述用户从所述设定互助计划的数据库中删除。
[0147] 在一个实施例中，用户申请理赔之后，将所述获得理赔拨款的用户从所述享受互助保障的互助保障数据库中删除。
[0148] 在一个实施例中，判断是否收到数据库中用户的申请退款的信息，所述数据库包括等待数据库和互助保障数据库；若接收到用户申请退款的消息，根据用户的申请退款的消息则将用户的信息从其对应的设定互助计划的数据库中移除，将所述用户账户中的剩余的互助金返还给用户。
[0149] 在一个实施例中，所述各个设定互助计划包括预先设定的与各个设定互助计划相适应的第一设定条件、第二设定条件、理赔案件范围，以及最高获助规则、分摊规则、余额要求规则、等待期规则。
[0150] 以中青年抗癌计划举例，中青年抗癌计划的加入条件：1、加入年龄：18-50周岁；2、受助年龄：18-50周岁，年满51周岁后将自动转入中老年抗癌计划，继续享受受助资格；3、为保障公平性，加入者还需要保证加入计划时身体健康；4、认同并承诺遵守《会员公约》及计划条款。
[0151] 在一个实施例中，中青年抗癌计划的事件范围：胃癌、肝癌等各种癌症，所有恶性肿瘤(癌症)，但下列疾病不可互助：
[0152] 1)原位癌及癌前病变；
[0153] 2)相当于Binet分期方案A期程度的慢性淋巴细胞白血病；
[0154] 3)相当于Ann Arbor分期方案I期程度的何杰金氏病；
[0155] 4)
皮肤癌(不包括恶性黑色素瘤及己发生转移的皮肤病)；
[0156] 5)TNM分期为T1N0M0期或者更轻分期的
前列腺癌；
[0157] 6)感染
艾滋病病毒或者患艾滋病期间所患恶性肿瘤。
[0158] 在一个实施例中，中青年抗癌计划的最高获助：30万元，不同年龄段会员可获得的最高互助金额不同，具体如下：
[0159]年龄(周岁) 重度癌症 低度恶性肿瘤
18-30 30万元 5万元
31-40 25万元 5万元
41-50 20万元 5万元
[0160] 其中，低度恶性肿瘤是指出经医学专家认定属于
预后较好、生存期长、
治疗费用低的恶性肿瘤。
[0161] 在一个实施例中，中青年抗癌计划的分摊规则：单次不超过3元。如有会员不幸患癌，其他会员会均摊帮助，每个互助事件单次分摊不超过3元。
[0162]
[0163]
[0164] 具体地，1)如上表，会员数量越多，单次分摊金额越低；2)会员账户余额归本人所有，只有发生互助时才会扣除相应金额；3)根据全民自然发病率计算出来的预估年度费用约为150元。当前由于会员较年轻，癌症发生率低，年度费约为30元，随着空气
质量、
食品安全等影响国民健康的因素的变化，癌症发病率可能会变得更高，相应的年费用可能也会有提升。
[0165] 在一个实施例中，中青年抗癌计划的余额要求：账户余额不低于1元即可；为保证会员能及时获得互助金，每位会员的账户余额不得低于1元。
[0166]
[0167]
[0168] 具体地，余额低于6元时，互助保障服务器会通过微信或短信提醒充值。
[0169] 在一个实施例中，中青年抗癌计划的等待期：180天(为防止带病加入)；需要说明的是，设置等待期的目的是为了防止己患病或者即将患病的人加入，即常说的逆选择。在等待期内，若患病不可以申请互助金，但须履行分摊义务。等待期过后，会员如不幸罹患癌症，本计划项下的其他互助会员会为其发起互助。
[0170] 以中老年抗癌计划举例，中老年抗癌计划的加入条件：1、加入年龄：51-65周岁2、受助年龄：终身。年龄超过65周岁后，只要账户余额不低一1元即可持续享受受助资格。3、为保障公平性，加入者还需要保证加入计划时身体健康。4、认同并承诺遵守《水滴互助会员公约》及计划条款。
[0171] 在一个实施例中，中老年抗癌计划的事件范围：胃癌、肝癌等各种癌症，所有恶性肿瘤(癌症)，但下列疾病不可互助：
[0172] 1)原位癌及癌前病变；
[0173] 2)相当于Binet分期方案A期程度的慢性淋巴细胞白血病；
[0174] 3)相当于Ann Arbor分期方案I期程度的何杰金氏病；
[0175] 4)皮肤癌(不包括恶性黑色素瘤及己发生转移的皮肤病)；
[0176] 5)TNM分期为T1N0M0期或者更轻分期的前列腺癌；
[0177] 6)感染艾滋病病毒或者患艾滋病期间所患恶性肿瘤。
[0178] 在一个实施例中，中老年抗癌计划的最高获助：30万元，不同年龄段会员可获得的最高互助金额不同，具体如下：
[0179]
[0180] 在一个实施例中，中老年抗癌计划的分摊规则：单次不超过3元；如有会员不幸患癌，其他会员会分摊帮助，每个互助事件单次分摊不超过3元。
[0181]会员总数 分摊金额 互助金
5万人 2.0元 10万元
10万人 1.0元 10万元
100万人 0.1元 10万元
[0182] 具体地，1)如上表，会员数量越多，单次分摊金额越低。2)会员账户余额归本人所有，只有发生互助时才会扣除相应金额。3)根据全民自然发病率计算出来的预估年度费用约为150元。当前由于会员较年轻，癌症发生率低，年度费约为30元，随着空气质量、食品安全等影响国民健康的因素的变化，癌症发病率可能会变得更高，相应的年费用可能也会有提升。
[0183] 在一个实施例中，中老年抗癌计划的余额要求：账户余额不低于1元即可；为保证会员能及时获得互助金，每位会员的账户余额不得低于1元。
[0184]
[0185]
[0186] 中老年互助计划的用户的余额低于9元时，互助保障服务器会通过微信或短信提醒充值。
[0187] 在一个实施例中，中老年抗癌计划的等待期：180天(为防止带病加入)；设置等待期的目的是为了防止己患病或者即将患病的人加入，即常说的逆选择，在等待期内，若患病不可以申请互助金，但须履行分摊义务。等待期过后，会员如不幸罹患癌症，本计划项下的其他互助会员会为其发起互助。
[0188] 图5为本发明互助保障方法的一个实施例的用户加入中青年互助保障系统的流程图，如图5所述:
[0189] 步骤501，用户发送加入互助的注册请求信息。
[0190] 具体地，用户通过微信公众号或水滴互助App进行注册，填写个人信息，申请加入设定互助计划。
[0191] 步骤502，判断用户是否确认符合加入互助的协议；如果用户确认符合了所选互助计划的对应协议，则执行步骤503，如果用户确认不符合所选互助计划的对应协议，则执行步骤513结束注册流程，返回程序主界面。
[0192] 具体地，根据用户选择的互助计划，提供所述互助计划的对应协议，并提示用户确认所述是否符合所述互助计划的协议。
[0193] 步骤503，用户确认符合了所选互助计划的对应协议之后，判断用户是否支付了至少9元的互助金；若用户支付至少9元的互助金之后，则执行步骤504；如果用户未支付至少9元的金额的互助金，则执行步骤513，结束注册流程，返回主界面。
[0194] 步骤504，将用户的添加到加入相应的计划的等待数据库中，用户成为互助会员。
[0195] 具体地，刚加入的注册会员用户暂不享受保障但是需要履行互助义务，此时的互助会员需要经过一定时间之后且在余额满足情况的下才会成为享受互助保障的会员。
[0196] 步骤505，判断用户余额是否满足账户中最低有1元的余额要求，如果用户的当前账户的余额满足余额要求，则执行步骤506，如果用户的余额不满足余额要求，则需要通知用户及时充值。
[0197] 步骤506，判断用户是否满足时限要求。
[0198] 具体地，加入中青年互助的时间是否大于180天，且用户在休眠期和惩罚期内。
[0199] 具体地就中青年抗癌计划举例而言，如果没有度过等待期只参与均摊，不享受保障；用户度过等待期后，如果经过均摊后互助会员账户余额小于1元时，用户将暂时失去享受保障的资格，账户低于1元的会员用户将不参与互助分摊，也不享有受助权利，根据以下情况分别处理：1)、自失去会员资格之日起15日内(含)充值的，为休眠期，无惩罚，则自余额补足后次日零时恢复会员资格；2)、自失去会员资格之日超15日(不含)至30日内(含)充值的，惩罚期为15天，自余额补足之日起15日后恢复会员资格；3)、自失去会员资格之日超30日(不含)至60日内(含)充值的，惩罚期为30天，自余额补足之日起30日后恢复会员资格；4)、超过60日(不含)仍未补足余额的，则视为退出计划；如再次加入，需要重新计算等待期，等待期为180天。
[0200] 步骤507，用户成为享受互助保障的会员，并履行均摊义务。
[0201] 具体地，如果等待数据库中的用户加入的时间超过设定时限且用户的互助金满足设定的条件，不属于休眠期、惩罚期用户即可享受互助保障，则将所述用户加入互助保障数据库，所述用户的属性设置为可以享受保障。
[0202] 具体而言，用户余额大于1元，度过等待期且不属于休眠期、惩罚期用户即可享受互助保障。针对互助保障数据库可以进行以下判定以确定用户是否可以继续享受保障。
[0203] 步骤508，判断用户是否申请退出互助，如果收到用户的申请的退出互助的消息退款的信息，则执行步骤S511将用户的信息从其对应的设定互助计划的数据库中移除，将所述用户账户中的剩余的互助金返还给用户。
[0204] 步骤509，判断用户是否申请过理赔并获得过互助保障服务，如果用户申请理赔并获得理赔之后，则执行步骤511，将该获得理赔拨款的用户从所述享受互助保障的互助保障数据库中删除。
[0205] 步骤510，判断用户余额是否充足，如果用户余额小于1元，则执行步骤512通知余额不足的用户进行充值。如果用户的余额充足、没有获得过理赔则用继续享受保障。具体地，中青年抗癌计划中如果发生理赔后，用户均摊之后用户账户中的资金会减少，此时需要判断用户的账户余额是否大于最低余额要求1元，如果余额不大于1元，则需要通知用户互助金余额不足，需要进行充值。
[0206] 图6为本发明互助保障方法的一个实施例的中青年互助保障系统中对用户理赔处理的流程图，如图6所述:
[0207] 步骤601，用户是享受互助保障的会员，并履行均摊义务，如果用户不幸罹患疾病，通过报案系统报案并提交资料，此时互助保障系统根据系统设定进行理赔处理。
[0208] 步骤602，系统监控数据库中的用户，判断用户是否提交理赔请求。
[0209] 步骤603，通过案件理赔审核系统判断理赔是否通过审核。
[0210] 具体地，在接收到用户的理赔请求之后，判断用户提交的理赔请求的案件信息符合系统设定的条件。所述系统设定的申请条件包括：1)、判断用户提交的案件信息是否符合加入时签订的《健康要求》协议的要求。2)、判断用户提交的案件信息的确诊时间点是否是有效的时间点。所述案件信息中用户的订单的状态必须是有效且已度过等待期，且不在休眠期和惩罚期内。3)、判断用户提交的案件信息中的所患疾病信息是否协议所规定的疾病的信息。申请理赔的案件信息中的疾病需要是用户加入的在《互助计划条款》规定的范围。如果医学的情况很复杂，需要将案件信息推送给专业专家；专业人员对住院记录和病理报告进行仔细的审核，才能决定是否通过互助金的申请，则将案件信息发送给管理员用户进行审核。
[0211] 如果用户提交的理赔请求的案件信息符合系统设定的条件，将用户的案件进入内审系统。如果用户提交的理赔请求的案件信息不符合系统设定的条件，则将不符合的信息反馈给用户。内审系统通过OCR、AI、大数据风险控制对用户资料进行审核，审核通过之后，提交第三方公估机构进行核实。OCR识别用户提交的资料，所述用户的资料包括身份证、银行卡、病历、诊断书、医学检测报告等。通过OCR进行识别，判断用户提交的案件是否有问题。AI算法可以是Match-LSTM敏感词模型，识别用户资料中的关键词，如既往病史的识别等。
[0212] 具体地，可以判断用户提交的病历和诊断报告是否是互助系统数据库中的有效用户。
[0213] 具体地，可以判断用户的疾病是否是符合要求的疾病，例如，如果用户加入的抗癌计划，但是提交的是感冒发烧的诊断报告，则确认为审核不通过。
[0214] 具体地，对提交理赔案件的用户需要进行AI方式进行活体检测、人脸识别，确定用户是合法的用户。
[0215] 在一个实施例中，大数据风险控制即大数据风控，指的是通过互助保障系统的数据库内的数据和第三方的数据，对
申请人进行审核，降低风险；通过OCR、AI和大数据风控等方式进行审核，可以快速的判断用户提交的案件是否有疑点；可以极大的降低对材料审核的人工要求，降低人力资源成本，提高审核效率。
[0216] 步骤605，是否通过第三方公估机构公估，所述第三方公估机构可以包括泛华保险公估、民太安保险公估，天衡保险公估等；此处保险公估是根据保险监管法律设置的，给出的公估机构仅为一种示例。如果通过第三方公估机构评估，则执行步骤606，如果没有通过第三方公估机构评估，则需要将案件情况通知用户的内部审核平台。
[0217] 步骤606，公示理赔案件，并确定是否有异议。
[0218] 具体地，如果所述内审系统的调查结果和第三方公估结果显示所述用户的案件无问题，则提交至公示平台进行全平台公示进入异议期；如果公示结果无异议，则执行步骤607计算理赔均摊并由于资金托管方进行划款；如果公示结果有异议，则通知用户和审核平台，并进入异议调查流程。
[0219] 步骤607，确定有效均摊用户，均摊互助金，进行理赔，被理赔人员退出，计算均摊后的会员用户余额。
[0220] 步骤608，均摊后的用户的余额是否充足。
[0221] 步骤609，通知余额不足的用户充值。
[0222] 步骤610，根据用户余额小于设定值的时间是时间差值确定用户所在期。
[0223] 本发明还提供一种互助保障服务器。图7为本发明互助保障服务器的一个实施例的结构框图，如图7所示，该互助保障服务器包括：
[0224] 接收模块701，用于接收用户发送的加入设定互助计划的消息；第一处理模块702，与所述接收模块701相连接，用于根据用户发送的加入设定互助计划的消息判断所述用户是否符合加入设定互助计划的第一设定条件；若用户确认符合加入设定互助计划的第一设定条件，则将用户加入到设定互助计划的等待数据库中；第二处理模块703，与所述第一处理模块702相连接，用于判断加入到设定互助计划的所述等待数据库中的所述用户是否满足第二设定条件；若所述等待数据中的所述用户满足第二设定条件，则将所述用户加入到设定互助计划的互助保障数据库中以便所述用户享受互助保障。
[0225] 图8为本发明互助保障服务器的另一个实施例的结构框图，如图8所示，所述服务器还包括发送模块804，所述发送模块804与所述第一处理模块802、第二处理模块803相连接，用于根据所述接收到的用户发送的加入设定互助计划的消息向所述用户发送相应的设定互助计划的协议以便用户的终端展示给用户。
[0226] 在一个实施例中，第一处理模块802包括第一处理单元8021和第二处理单元8022，其中，第一处理单元8021用于判断所述用户是否确认符合所选互助计划的对应协议；第二处理单元8022与所述第一处理单元8021相连接，用于若所述用户确认符合所选互助计划的对应协议之后，判断所述用户是否支付了不小于所选设定互助计划的设定金额的互助金；若确定所述用户支付了不小于所选设定互助计划的设定金额的互助金，则将所述用户的加入到设定互助计划的等待数据库中。
[0227] 所述服务器还包括支付处理模块805，所述支付处理模块与所述接收模块801、所述第一处理模块802、第二处理模块803相连接，用于将所述用户支付的互助金存入所述用户的资金存管账户中。
[0228] 在一个实施例中，所述第二处理模块803包括第三处理单元8031、第四处理单元8032、第五处理单元8033；其中，第三处理单元8031用于判断所述用户的互助金金额是否小于设定互助计划的享受互助保障的互助金阈值；第四处理单元8032用于判断加入到设定互助计划的所述等待数据库中的所述用户是否满足设定互助计划享受互助保障的设定时限条件，其中，所述设定时限条件包括所述加入到设定互助计划的等待数据库中用户的等待时间大于设定等待时间。
[0229] 在一个实施例中，第五处理单元8033用于判断所述用户是否处于休眠期或惩罚期。若用户的互助金小于设定的互助金阈值的时间小于或等于第一设定时间，所述用户处于休眠期；若用户的互助金小于设定的互助金阈值时间大于第一设定时间且小于或等于第二设定时间，所述用户处于惩罚期；若用户的互助金小于设定的互助金阈值的时间大于第二设定时间，则将所述用户从所述设定互助计划的等待数据库中删除，若用户申请加入互助保障数据库，需要重新计算以便判断将所述加入到设定互助计划的等待数据库中用户的等待时间满足设定互助计划享受互助保障的设定时限条件。
[0230] 图9为本发明互助保障服务器的又一个实施例的结构框图，如图9所示，该互助保障服务器还包括：理赔模块901，所述理赔模块与接收模块801、所述第二处理模块803、支付模块805、发送模块804相连接，所述理赔模块包括理赔条件判断单元9011、内审单元9012。
[0231] 理赔条件判断单元9011用于判断所述用户是否是加入到设定互助计划的互助保障数据库中用户，若所述用户是互助保障数据库中的享受互助保障的用户，判断所述用户提交的理赔请求的案件信息是否符合所述用户对应的互助计划的设定的理赔案件范围。
[0232] 内审单元9012用于如果所述用户提交的理赔请求的案件信息符合所述用户对应的互助计划的设定的理赔案件范围，对所述用户提交的案件信息进行内审审核以确认用户的理赔请求是否符合要求，其中，所述内审审核包括通过光学字符识别OCR、人工智能AI、大数据风险控制对用户资料进行审核；其中，所述内审审核还包括将通过OCR、AI、大数据风险控制对所述用户的资料进行审核确定的有疑点的、无法确认的案件展示给管理人员以便管理人员进行人工审核，并将人工审核的结果通过大数据的方式进行迭代。
[0233] 所述发送模块804用于若用户提交的案件信息进行内审审核通过，将用户的案件信息提交第三方公估机构服务器以便第三方公估机构核实，通过接收模块接收第三方公估机构核实结果。
[0234] 所述服务器还包括公示模块902，用于若经过内审或公估核实确认所述用户的理赔请求是符合要求理赔请求后，将所述发起理赔请求的用户审核结果进行公示。
[0235] 所述服务器还包括互助金均摊处理模块903，用于如果公示结果无异议，根据设定互助计划的设定均摊互助金方式对所述用户的进行理赔。
[0236] 在一个实施例中，所述理赔条件判断单元9011用于判断所述用户是否满足加入时签订的所选设定互助计划的对应协议；判断用户提交的案件信息中的所患疾病信息是否协议所规定的理赔疾病的信息。
[0237] 在一个实施例中，所述内审单元9012还用于对提交理赔案件的所述用户进行AI方法进行活体检测、人脸识别，确定所述用户是否加入到设定互助计划的享受互助的有效用户。
[0238] 在一个实施例中，所述内审单元还用于通过OCR识别用户提交的资料。
[0239] 在一个实施例中，所述内审单元还大用于根据敏感词模型Match-LSTM识别用户资料中的关键词判断所述用户的理赔请求是否符合要求；其中，所述用户的资料包括但是不限于：身份证信息、银行卡信息、病历信息、诊断报告信息、医学检测报告信息；所述判断所述用户的理赔请求是否符合要求包括根据提交的病历信息、诊断报告信息、医学检测报告信息判断所述用户的请求理赔的疾病是否是符合设定互助计划的对应协议所规定的疾病。
[0240] 在一个实施例中，所述内审单元还用于以大数据风险控制方式通过分析数据库内的数据和第三方的数据，对发起理赔请求的用户进行审核。
[0241] 在一个实施例中，互助金均摊处理模块用于：在公示结束后的设定时间段内，计算设定互助计划需要提供互助保障服务的理赔用户人数，总互助金额；将申请理赔的享受互助保障的用户设置为保护状态，不需要履行均摊义务；在公示结束后的设定时间段内确定需要均摊的用户，计算设定互助计划内每个需要均摊的用户的均摊金额，将需要均摊的用户在对应计划内的均摊额进入冻结状态，即使用户退出，冻结金额也无法退款；其中，参与均摊的用户每次均摊额不超过设定分摊金额，和\或，参与均摊的每个用户每个设定时间段内为每个患病的用户的均摊额不超过设定分摊金额，和\或，用户每个设定时间段内的均摊额的总金额不超过设定分摊总额；在计算得到应发给所述互助用户的互助金后，将所述发送资金的指令发送给资金托管方，资金托管方根据指令均摊额从用户账户、资金池中扣除均摊额度，资金托管方对所述申请理赔的用户进行理赔拨款。
[0242] 在一个实施例中，该互助保障服务器还包括退出处理模块，用于在进行均摊后，记录设定互助计划内每个用户的当前金额，将余额低于设定金额的用户从所述互助保障数据库中删除，并记录失去互助保障资格的时间，根据失去互助保障资格的时间将用户设置为休眠期用户、惩罚期用户或将所述用户从所述设定互助计划的数据库中删除；退出处理模块还用于用户申请并或获得理赔之后，将所述获得理赔拨款的用户从所述享受互助保障的互助保障数据库中删除。
[0243] 在一个实施例中，所述退出处理模块还用于：判断是否收到数据库中用户的申请退出互助保障的信息，所述数据库包括等待数据库和互助保障数据库；若接收到用户申请退出互助保障的信息，将用户的信息从其对应的设定互助计划的数据库中移除，将所述用户账户中的剩余的互助金返还给用户。
[0244] 在一个实施例中，所述第一设定条件还包括：用户的信用值满足设定条件并且用户绑定了用户的支付账户；第一处理模块802用于通过第三方信用平台判定用户的信用值，若用户的信用值满足设定的信用条件，则免除用户的支付所述设定金额互助金的义务，在进行均摊的时候从用户的银行卡或理财账户中扣款。
[0245] 在一个实施例中，所述设定互助计划包括少儿健康互助计划、中青年抗癌计划、中老年抗癌计划、百万终身抗癌计划、综合意外互助计划、大爱互助计划，所述各个设定互助计划包括预先设定的与各个设定互助计划相适应的第一设定条件、第二设定条件以及事件范围、最高获助规则、分摊规则、余额要求规则、等待期规则。
[0246] 本发明还提供一种互助保障系统，该互助保障系统包括：如上所述的互助保障服务器；第三方公估机构服务平台；第三方资金管理平台；以及用户所用的用户终端，用户通过用户终端向互助保障服务器申请加入互助保障、理赔、或退出互助保障，用户所缴纳的互助金放置的第三方的资金管理平台内，该资金监管可以是银行的资金账户或保险公司设置的受监管的账户中，若用户发生理赔，通过互助保障服务器组成的互助保障平台内部审核和第三方公估机构服务平台审核通过后，第三方资金管理平台可以向用户进行理赔。
[0247] 本发明的互助保障系统是基于互联网技术提供的
预防性的抗癌与防意外伤害的健康互助管理系统，如果用户加入健康互助管理系统，即可享受保障；如果用户不幸患癌或者遭遇意外，健康互助管理系统可以通过大数据、AI等方式审核用户提交的案件信息，如果确认用户案件属实，可以按照“一人患病，众人均摊”的既定规则提供一笔医疗资金，用户在保障别人的同时，也受到了别人的保障。
[0248] 本发明所提供的健康互助管理系统包括用户注册模块、加入模块、互助理赔申请模块、互助履约模块、互助公示模块等，并引入电子签、活体检测、AI智能识别、大数据风控等先进技术，提高用户体验，降低风险。
[0249] 本发明中，用户加入互助计划时支付的互助金，以及用户患病申请的互助金，完全受第三方公益机构监管，同时通过公示系统接收全平台用户的监督，完全的公开和透明。
[0250] 本发明健康互助管理系统主要功能模块：用户系统：包括用户注册、登录等，这是整个系统的入口；互助主系统：包括信息的录入、认证，加入互助计划等功能；用户登录系统之后可以使用该系统加入互助；报案系统：包括申请互助金、提交审核材料、查看审核进度等功能，用户加入计划并度过等待期后，如果不幸患病，可以使用该系统进行报案；公示系统：对申请到互助金的用户进行全平台公示；消息系统：各系统之间进行通信的
中间件；
支付系统：在线支付，用户加入互助计划时，通过该系统进行支付；AI系统：包括用户材料OCR内容识别、人脸识别，人脸对比、语义分析等，应用了基于Gated-Attention Reader
抽取算法，基于Match-LSTM的敏感词模型等先进算法，为审核人员提供准确的参考依据；内审系统：包括案件的审核、调查、公示资料编辑等；大数据风控系统：包括本公司大数据统计和第三方系统，对用户的资料进行甄别，对用户的信用风险进行评估等功能，比如用户的社保、治疗医院等信息是否正常；存储系统：包括数据库系统、文件系统、缓存系统等。负责所有数据的存储和备份。
[0251] 本发明实施例一种互助保障方法、互助保障服务器、互助保障系统，基于互联网技术为用户提供互助保障服务，可以让更多的人以低廉的价格享受优质高效、高性价比、公开透明的健康保障。
[0252] 本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0253] 可能以许多方式来实现本发明的方法和系统。例如，可通过软件、
硬件、
固件或者软件、硬件、固件的任何组合来实现本发明的方法和系统。用于所述方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还
覆盖存储用于执行根据本发明的方法的程序的记录介质。
[0254] 本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多
修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。
