互助保险投保理赔方法及相关装置

互助保险投保理赔方法及相关装置

技术领域

本申请涉及医疗技术领域，尤其涉及一种互助保险投保理赔方法及相关装置。

背景技术

互助保险是由一些具有共同要求和面临同样风险的用户自愿组织起来，是预交风险损失补偿分摊金的一种保险形式，互助保险的互助范围是以互助团体内部成员为限，互助保险是体行为，把每个投保人的个人需要汇集成体共同的需要。目前保险在理赔过程中，资金的沉淀和使用情况不透明，使得保险购买者不信任保险产品，从而引起纠纷。

发明内容

本申请实施例提供一种互助保险投保理赔方法及相关装置，有利于保证参与投保理赔的用户的利益，使得理赔更加公开公正。

第一方面，本申请实施例提供一种互助保险投保理赔方法，应用于服务器，所述方法包括：

接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点；

将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户；

接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

第二方面，本申请实施例提供一种互助保险投保理赔装置，应用于服务器，所述互助保险投保理赔装置包括接收单元、更新单元和处理单元，其中，

所述接收单元，用于接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点；

所述更新单元，用于将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户；

所述处理单元，用于接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

第三方面，本申请实施例提供一种电子设备，包括处理器、存储器、通信接口以及一个或多个程序，其中，上述一个或多个程序被存储在上述存储器中，并且被配置由上述处理器执行，上述程序包括用于执行本申请实施例第一方面任一方法中的步骤的指令。

第四方面，本申请实施例提供了一种计算机可读存储介质，其中，上述计算机可读存储介质存储用于电子数据交换的计算机程序，其中，上述计算机程序使得计算机执行如本申请实施例第一方面任一方法中所描述的部分或全部步骤。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

附图说明

为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。

图1A是本申请实施例提供的一种互助保险投保理赔方法的流程示意图；

图1B是本申请实施例提供的一种投保理赔流程的参考示例图；

图2是本申请实施例提供的另一种互助保险投保理赔方法的流程示意图；

图3是本申请实施例提供的另一种互助保险投保理赔方法的流程示意图；

图4是本申请实施例提供的一种电子设备的结构示意图；

图5是本申请实施例提供的一种互助保险投保理赔装置的功能单元组成框图。

具体实现方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

以下分别进行详细说明。

本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请提出一种基于区块链的行业互助保险平台。制定机构可以发起互助保险计划，每一个参与方都可以查看该计划投保，理赔细节，对于有能力的组织，可以在发起保险计划时加入自己的预设规则，可以对理赔细节有效监控，不符合规则理赔自动拒绝。利用区块链的共享账本记录保险投保理赔详情，保证互助保险的公开透明，避免纠纷。

基于区块链的互助保险理赔方法，具有以下优点：去中心化明主决策，投保人投保记录、理赔资料审核均由所有投保人自愿参与决策，自愿增加区块链节点，决策者节点之间采用共识算法，决策节点需要验证信息的真实性，只有大部分参与者承认整个投保过程中的信息，理赔才能完成；区块链永久记录，投保人申请基于密码学哈希hash值的个人账户，投保人个人信息、生成的保单记录、投保人提交的理赔资料等均由加密后存储在区块链中，各个节点进行同步生成永久记录；记录追踪，区块链记录具有永久性和可追溯性，用户或者组织可以追踪某一保单的整个记录，或者某个用户行为，形成用户信用的信息体系，建立公信力平台，规范投保人之间的关系，记录交易时间戳，实现交易在时间顺序上的查询追踪；信息加密，用户通过非对称加密对信息数字签名，并通过私钥对信息签名加密，其他用户获取信息后，用公钥解密信息，同时采用数字证书避免非法用户冒充获取信息，为用户隐私信息保护提供科学的保障；智能合约，保险在平台发布后，理赔规则已经发布，即智能合约发布，区块链节点验证理赔材料后执行职能合约，发放理赔。

下面对本申请实施例进行详细介绍。

请参阅图1A，图1A是本申请实施例提供了一种互助保险投保理赔方法的流程示意图，应用于服务器，本互助保险投保理赔方法包括：

S101，所述服务器接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点。

其中，服务器为保险平台的服务器，通过服务器处理多个投保用户的投保理赔事件。当目标投保用户向保险平台提交理赔申请资料之后，保险平台的服务器则会接收到来自目标投保用户的理赔申请请求，理赔申请请求可以包括理赔申请信息，例如，目标投保用户个人信息、理赔申请书、保险合同等等，此处不作任何限定。

其中，服务器接收到目标投保用户的理赔信息之后，将理赔申请信息加密后存储在目标投保用户在区块链中对应的目标区块链节点中。区块链的特性是数据无法删除和修改，只能新增，保证了历史的可追溯，同时将作恶的成本提高，作恶行为将被永远记录。而基于区块链技术的智能合约不仅可以发挥智能合约在成本效率方面的优势，而且可以避免恶意行为对合约正常执行的干扰。将智能合约以数字化的形式写入区块链中，有区块链技术的特性保障存储、读取、执行整个过程透明可追踪、不可篡改。同时，由区块链自带的共识算法构建出一套状态机系统，使智能合约能够高效地运行。

S102，所述服务器将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户。

其中，目标投保用户的理赔申请信息加密后存储在目标区块链节点中，区块链中的其他节点同步存储该理赔申请信息，每一个区块链对应一个投保用户，区块链中的所有区块链节点用于存储互助投保用户团体中每个投保用户的投保理赔信息。当增加投保用户时，可以增加区块链节点，每个区块链节点都可以成为一个决策节点，决策节点之间采用共识算法。

S103，所述服务器接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

其中，区块链中的每个投保用户对应一个区块链节点，用于存储用户的数据信息，相当于是个人账户，每个投保用户持有一个参考终端，例如可以是手机，通过参考终端在自己的区块链节点中上传和查看数据。

其中，服务器接收来自多个参考终端的多个反馈信息，反馈信息由多个区块链节点对应的多个用户输入，根据多个反馈信息可以处理目标投保用户的理赔申请请求，可以是同意目标投保用户的理赔申请请求，也可以是拒绝目标投保用户的理赔申请请求。由于参与互助保险的用户都参与到可投保理赔的决策过程，从而使得互助保险的投保理赔过程公开透明，公平公正。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

在一个可能的示例中，所述将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，包括：使用哈希加密算法对所述理赔申请信息进行加密；将所述加密后的理赔申请信息存储在所述目标投保用户在所述区块链中对应的目标区块链节点。

其中，参与互助保险的每个用户都有一个基于密码学哈希hash加密算法的个人账户，投保人的个人信息、生成的保单记录、提交的理赔申请请求等都可以使用哈希加密算法进行加密后存储在对应的区块链节点中的个人账户中，同时，区块链的其他节点可以同步生成新增的永久记录。

可见，本示例中，在目标投保用户提交理赔申请请求之后，使用哈希加密算法对理赔申请请求进行加密，并将加密后的理赔申请信息存储在目标投保用户在区块链对应的目标区块链节点中，从而提高用户数据的安全性。

在一个可能的示例中，所述将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点之后，所述方法还包括：通知所述多个区块链节点对应的多个投保用户查看所述理赔申请信息并对所述理赔申请信息进行投票。

其中，在将目标投保用户的理赔申请信息更新到区块链中出目标区块链节点的多个区块链节点后，则需要通知多个区块链节点对应的多个投保用户查看理赔申请信息，从而多个用户可以对理赔申请进行审核和决策，表达自己的意见，是否通过目标投保用户的理赔申请请求。通知方式可以是以通过投保用户的额参考终端，以投保用户绑定的方式进行通知，如通过软件、短信、电话等方式通知投保用户。

其中，将理赔申请信息在区块链中的每个区块链节点中同步进行更新，此时每个区块链节点中都存储有目标投保用户的理赔申请信息的永久记录。区块链中的其他投保用户验证该理赔申请信息是否真实可靠，如果同意目标投保用户的投保理赔，可以投保表示赞同，相当于其他投保用户对目标投保用户的投保理赔具有决策性作用，保证了投保理赔的公开公平。

可见，本示例中，目标用户的理赔申请信息可以被参与互助保险的其他投保用户看到的，在将理赔信息更新待区块链中的每个区块链节点之后，其他投保用户可以对该投保理赔信息进行查看和决策，从而有利于保证投保理赔的公开透明。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，包括：根据所述多个反馈信息，确定投票结果为同意理赔的第一用户数目，以及投票结果为不同意理赔的第二用户数目；在检测到所述第一用户数目大于所述第二用户数目时，确认同意所述目标投保用户的理赔申请请求。

其中，在接收到多个区块链节点发送的多个反馈信息之后，由于反馈信息包括投保用户的投票结果，投票结果包括同意理赔和不同意理赔，因此可以根据多个反馈信息确定如何处理目标投保用户的理赔申请请求。反馈信息可以是投保用户针对目标投保用户的理赔申请请求的投票结果，因此，多个反馈信息代表了多个投保用户的意见和建议，具有可靠性和公正性。

其中，根据多个反馈信息，确定投票结构为同意理赔的第一用户数据，以及投票结果为不同意理赔的第二用户数据。当有未发送反馈信息的区块链节点时，表明对应的投保用户可能是弃票，也可能是为看到目标投保用户的理赔申请信息，可再次通知该投保用户查看理赔申请信息。

其中，在检测到第一用户数目大于第二用户数目时，则表情同意理赔的用户数目大于不同意理赔的用户数目，即参与互助保险的大多数用户都同意目标投保用户的理赔申请请求，则确认同意该理赔申请请求。

可见，本示例中，根据参与互助保险的多个投保用户的输入的反馈信息，确定同意理赔的第一用户数目和不同意理赔的第二用户数目，在检测到第一用户数目大于第二用户数目时，即可确定同意目标投保用户的理赔申请请求，从而实现了投保用户可以对理赔申请请求进行决策，保证了投保理赔的公开透明。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，包括：根据所述多个反馈信息，确定参与投票的第三用户数目，以及其中投票结果为同意理赔的第四用户数目；在检测到所述第四用户数目和所述第三用户数目的比值大于预设阈值时，确定同意所述目标投保用户的理赔申请请求。

其中，由于参与互助保险的投保用户可能有部分未参与到投票中，对于为参与投票的投保用户，其对应的区块链节点可以不发送反馈信息或者发送值为0的反馈信息。

其中，可根据多个反馈信息，确定参与到投票中的第三用户数目，以及参与到投票的投保用户中，投票结果为同意理赔的第四用户数目，在检测到第四用户数据和第三用户数目的闭会大于预设阈值时，即可确认同意目标投保用户的理赔申请请求。预设阈值可由参与投保的用户设定。

举例说明，如图1B所示，本申请提供的理赔申请方法包括了提交理赔、信息披露、投票验证、发放理赔和信息披露等步骤，在投保人提交理赔申请请求之后，即提交理赔；将理赔申请信息更新到区块链中除目标区块链节点的多个区块链节点，即信息披露；确定投票结果为同意理赔的第一用户数目，以及投票结果为不同意理赔的第二用户数目，在检测到第一用户数目大于第二用户数目时，确认同意所述目标投保用户的理赔申请请求，即投票验证；计算目标投保用户的理赔金额后，向目标投保用户发送理赔处理结果并在目标区块链节点中记录理赔处理结果，即发放理赔；将理赔处理结果更新到区块链中除目标区块链节点的多个区块链节点，并通知多个投保用户查看理赔处理结果，即信息披露。

可见，本示例中，根据接收到的多个反馈信息，确定参与到投票中，多个投保用户中同意理赔的投保用户占所述参与投保用户的比值，并在该比值大于预设阈值时，才可确定同意目标投保用户的理赔申请请求，从而保证了投保理赔的可靠性。

在一个可能的示例中，所述确定同意所述目标投保用户的理赔申请请求之后，所述方法还包括：计算所述目标投保用户的理赔金额后，向所述目标投保用户发送理赔处理结果并在所述目标区块链节点中记录所述理赔处理结果，所述理赔处理结果包括所述理赔金额；将所述理赔处理结果更新到所述区块链中除所述目标区块链节点的多个区块链节点，并通知所述多个投保用户查看所述理赔处理结果。

其中，在确认同意目标投保用户的理赔申请请求之后，即审核通过后即可计算目标投保用户的理赔金额，从而向目标投保用户发送理赔处理结果并在目标区块链节点中记录理赔处理结果，目标用户可查看到理赔处理结果为同意理赔，以及理赔金额。

其中，将目标投保用户的理赔处理结果更新到区块链中出目标区块节点的多个区块链节点，并通知多个投保用户查看理赔处理结果，从而，其他投保用户可以知晓目标投保用户是否得到理赔金额以及理赔金额数据，在遇到相似情况时，可以对自己理赔情况进行预估。

可见，本示例中，在计算出目标投保用户的理赔金额后，将理赔处理结果记录到目标区块链节点并同步到区块链中的其他区块链节点中，从而其他用户完整的参与到了目标投保用户的整个投保理赔过程中，并对理赔过程进行了监控，实现了投保理赔的公开透明，有利于提高投保用户对投保理赔的信任感。

在一个可能的示例中，所述计算所述目标投保用户的理赔金额，包括：在所述目标区块链节点中获取所述目标投保用户的投保信息；根据所述投保信息计算所述目标投保用户的理赔金额。

其中，目标区块链节点中存储有目标投保用户的投保信息，根据目标投保用户的投保信息，如投保档次，投保种类，理赔规则等结算目标投保用户的理赔金额。

其中，区块链中的各个区块包括智能合约和分布式账本，理赔规则可以以智能合约的方式发布，投保用户投保之后，便签订了智能合约，投保用户在自己发生损失时，提交理赔申请请求，经区块链节点验证理赔申请请求后，执行智能合约并发放理赔。

其中，由于区块链中每个区块链节点记录的信息具有永久性和可追溯性，其他投保用户可以追踪到目标投保用户的理赔记录以及查看理赔金额，在对应的区块链节点的信息更新后，即可获取目标投保用户的理赔处理结果。

可见，本示例中，根据目标投保用户的投保信息计算理赔金额，从而按照理赔金额对目标投保用户进行理赔，并且通过区块链，所有投保用户都可以查看到理赔金额以及理赔详情，有利于提高投保理赔的效率和可靠性。

与所述图1A所示的实施例一致的，请参阅图2，图2是本申请实施例提供的一种互助保险投保理赔方法的流程示意图，应用于服务器。如图所示，本互助保险投保理赔方法包括：

S201，所述服务器接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点。

S202，所述服务器将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户。

S203，所述服务器通知所述多个区块链节点对应的多个投保用户查看所述理赔申请信息并对所述理赔申请信息进行投票。

S204，所述服务器将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

此外，目标用户的理赔申请信息可以被参与互助保险的其他投保用户看到的，在将理赔信息更新待区块链中的每个区块链节点之后，其他投保用户可以对该投保理赔信息进行查看和决策，从而有利于保证投保理赔的公开透明。

与所述图1A、图2所示的实施例一致的，请参阅图3，图3是本申请实施例提供的一种互助保险投保理赔方法的流程示意图，应用于服务器，所述电子设备包括一个麦克风。如图所示，本互助保险投保理赔方法包括：

S301，所述服务器接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点。

S302，所述服务器将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户。

S303，所述服务器通知所述多个区块链节点对应的多个投保用户查看所述理赔申请信息并对所述理赔申请信息进行投票。

S304，所述服务器接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

S305，所述服务器根据所述多个反馈信息，确定投票结果为同意理赔的第一用户数目，以及投票结果为不同意理赔的第二用户数目。

S306，所述服务器在检测到所述第一用户数目大于所述第二用户数目时，确认同意所述目标投保用户的理赔申请请求。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

此外，目标用户的理赔申请信息可以被参与互助保险的其他投保用户看到的，在将理赔信息更新待区块链中的每个区块链节点之后，其他投保用户可以对该投保理赔信息进行查看和决策，从而有利于保证投保理赔的公开透明。

此外，根据参与互助保险的多个投保用户的输入的反馈信息，确定同意理赔的第一用户数目和不同意理赔的第二用户数目，在检测到第一用户数目大于第二用户数目时，即可确定同意目标投保用户的理赔申请请求，从而实现了投保用户可以对理赔申请请求进行决策，保证了投保理赔的公开透明。

与所述图1A、图2、图3所示的实施例一致的，请参阅图4，图4是本申请实施例提供的一种电子设备400的结构示意图，该电子设备400运行有一个或多个应用程序和操作系统，如图所示，该电子设备400包括处理器410、存储器420、通信接口430以及一个或多个程序421，其中，所述一个或多个程序421被存储在所述存储器420中，并且被配置由所述处理器410执行，所述一个或多个程序421包括用于执行以下步骤的指令；

接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点；

将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户；

接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

在一个可能的示例中，在所述将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点方面，所述程序中的指令具体用于执行以下操作：使用哈希加密算法对所述理赔申请信息进行加密；将所述加密后的理赔申请信息存储在所述目标投保用户在所述区块链中对应的目标区块链节点。

在一个可能的示例中，所述将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点之后，所述程序中的指令具体用于执行以下操作：通知所述多个区块链节点对应的多个投保用户查看所述理赔申请信息并对所述理赔申请信息进行投票。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；在所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求方面，所述程序中的指令具体用于执行以下操作：根据所述多个反馈信息，确定投票结果为同意理赔的第一用户数目，以及投票结果为不同意理赔的第二用户数目；在检测到所述第一用户数目大于所述第二用户数目时，确认同意所述目标投保用户的理赔申请请求。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；在所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求方面，所述程序中的指令具体用于执行以下操作：根据所述多个反馈信息，确定参与投票的第三用户数目，以及其中投票结果为同意理赔的第四用户数目；在检测到所述第四用户数目和所述第三用户数目的比值大于预设阈值时，确定同意所述目标投保用户的理赔申请请求。

在一个可能的示例中，所述确定同意所述目标投保用户的理赔申请请求之后，所述程序中的指令具体用于执行以下操作：计算所述目标投保用户的理赔金额后，向所述目标投保用户发送理赔处理结果并在所述目标区块链节点中记录所述理赔处理结果，所述理赔处理结果包括所述理赔金额；将所述理赔处理结果更新到所述区块链中除所述目标区块链节点的多个区块链节点，并通知所述多个投保用户查看所述理赔处理结果。

在一个可能的示例中，在所述计算所述目标投保用户的理赔金额方面，所述程序中的指令具体用于执行以下操作：在所述目标区块链节点中获取所述目标投保用户的投保信息；根据所述投保信息计算所述目标投保用户的理赔金额。

上述实施例主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据所述方法示例对电子设备进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。所述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

下面为本发明装置实施例，本发明装置实施例用于执行本发明方法实施例所实现的方法。如图5所示的互助保险投保理赔装置500，应用于该电子设备，所述电子设备包括一个麦克风，所述互助保险投保理赔装置包括接收单元501、更新单元502和处理单元503，其中，

所述接收单元501，用于接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点；

所述更新单元502，用于将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户；

所述处理单元503，用于接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。

可以看出，在本申请实施例中，服务器首先接收来自目标投保用户的理赔申请请求，所述理赔申请请求包括所述目标投保用户的理赔申请信息，将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点，其次，将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点，得到更新后的区块链，其中，所述多个区块链节点中的每个区块链节点对应一个投保用户，最后，接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求，其中，所述多个参考终端中的每个参考终端对应一个投保用户。由于服务器基于区块链记录了参与互助保险的每个投保用户的数据信息，使得目标用户提交理赔申请请求之后，每个投保用户都可对该理赔申请请求进行决策，有利于保证理赔的公开透明，有限防止骗保等违法行为。

在一个可能的示例中，在所述将所述理赔申请信息加密后存储在所述目标投保用户的目标区块链节点方面，所述处理单元503具体用于：使用哈希加密算法对所述理赔申请信息进行加密；以及用于将所述加密后的理赔申请信息存储在所述目标投保用户在所述区块链中对应的目标区块链节点。

在一个可能的示例中，所述将所述理赔申请信息更新到所述区块链中除所述目标区块链节点的多个区块链节点之后，所述更新单元502具体用于：通知所述多个区块链节点对应的多个投保用户查看所述理赔申请信息并对所述理赔申请信息进行投票。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；在所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求方面，所述处理单元503具体用于：根据所述多个反馈信息，确定投票结果为同意理赔的第一用户数目，以及投票结果为不同意理赔的第二用户数目；以及用于在检测到所述第一用户数目大于所述第二用户数目时，确认同意所述目标投保用户的理赔申请请求。

在一个可能的示例中，所述反馈信息包括所述投保用户的投票结果，所述投票结果包括同意理赔和不同意理赔；在所述接收多个参考终端根据所述更新后的区块链发送的多个反馈信息，根据所述多个反馈信息处理所述目标投保用户的理赔申请请求方面，所述处理单元503具体用于：根据所述多个反馈信息，确定参与投票的第三用户数目，以及其中投票结果为同意理赔的第四用户数目；以及用于在检测到所述第四用户数目和所述第三用户数目的比值大于预设阈值时，确定同意所述目标投保用户的理赔申请请求。

在一个可能的示例中，所述确定同意所述目标投保用户的理赔申请请求之后，所述处理单元503具体用于：计算所述目标投保用户的理赔金额后，向所述目标投保用户发送理赔处理结果并在所述目标区块链节点中记录所述理赔处理结果，所述理赔处理结果包括所述理赔金额；以及用于将所述理赔处理结果更新到所述区块链中除所述目标区块链节点的多个区块链节点，并通知所述多个投保用户查看所述理赔处理结果。

在一个可能的示例中，在所述计算所述目标投保用户的理赔金额方面，所述处理单元503具体用于：在所述目标区块链节点中获取所述目标投保用户的投保信息；以及用于根据所述投保信息计算所述目标投保用户的理赔金额。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤，上述计算机包括电子设备。

本申请实施例还提供一种计算机程序产品，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤。该计算机程序产品可以为一个软件安装包，上述计算机包括电子设备。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

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

上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例上述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取器(英文：Random Access Memory，简称：RAM)、磁盘或光盘等。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。