CN111815461A - 基于区块链的理赔方法、装置、系统、设备及存储介质 - Google Patents

Abstract

本公开涉及基于区块链的理赔方法、装置、系统、设备及存储介质。提供了一种基于区块链的理赔方法，包括：将第一哈希值上传至区块链，其中第一哈希值是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的；获得第二哈希值，其中第二哈希值是通过对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理得到的，业务处理机构处理与由理赔机构理赔的对象相关联的业务；将第二哈希值与区块链上的第一哈希值进行比对以确定第二用户是第一用户；将与第二用户相关联的业务数据上传至区块链；以及基于区块链上的业务数据进行理赔。

Description

基于区块链的理赔方法、装置、系统、设备及存储介质

技术领域

本公开总体上涉及区块链领域，并且更具体而言，本公开涉及基于区块链的理赔方法、装置、系统、设备及存储介质。

背景技术

保险理赔机构在用户投保时与用户基于理赔对象订立保险合同。理赔对象即保险的标的，其取决于险种而不同，例如人身保险的标的是被保险人的人身健康，财产损失保险的标的是被保险的财产，等等。投保的用户在相关业务处理机构完成相应的业务行为后可以提出理赔申请，在理赔申请通过保险理赔机构的审核后可以获得保险理赔机构的赔付。相关业务处理机构是办理与理赔对象相关联的业务的业务处理机构。例如，对于人身健康保险，业务处理机构可以包括各种医疗机构，并且相应的业务行为可以是用户在医疗机构进行的医疗行为；对于车辆保险，业务处理机构可以包括诸如车辆维修机构等之类的机构，并且相应的业务行为可以是用户在车辆维修机构进行的车辆维修行为；等等。

发明内容

根据本公开的第一方面，提供了一种基于区块链的理赔方法，包括：将第一哈希值上传至区块链，其中第一哈希值是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的；获得第二哈希值，其中第二哈希值是通过对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理得到的，业务处理机构处理与由理赔机构理赔的对象相关联的业务；将第二哈希值与区块链上的第一哈希值进行比对以确定第二用户是第一用户；将与第二用户相关联的业务数据上传至区块链；以及基于区块链上的业务数据进行理赔。

根据本公开的第二方面，提供了一种基于区块链的理赔装置，包括：一个或多个处理器；以及存储计算机可读指令的存储器，这些计算机可读指令在由一个或多个处理器执行时使得一个或多个处理器执行根据本公开的第一方面所述的理赔方法。

根据本公开的第三方面，提供了一种非暂态计算机可读存储介质，该非暂态计算机可读存储介质存储计算机可读指令，这些计算机可读指令在由处理器执行时使得处理器执行根据本公开的第一方面所述的理赔方法。

根据本公开的第四方面，提供了一种基于区块链的理赔系统。该理赔系统包括理赔机构节点设备，该理赔机构节点设备被配置为：对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理以得到第一哈希值；将第一哈希值上传至区块链；以及基于区块链上的业务数据进行理赔。该理赔系统还包括业务处理机构节点设备，该业务处理机构节点设备被配置为：对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理以得到第二哈希值，业务处理机构处理与由理赔机构理赔的对象相关联的业务；将第二哈希值与区块链上的第一哈希值进行比对以确定第二用户是第一用户；以及将与第二用户相关联的业务数据上传至区块链。

根据本公开的第五方面，提供了一种基于区块链的理赔机构节点设备，被配置为：对理赔机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值；将哈希值上传至区块链；以及基于区块链上的业务数据进行理赔。

根据本公开的第六方面，提供了一种基于区块链的业务处理机构节点设备，被配置为：对业务处理机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值，业务处理机构处理与由理赔机构理赔的对象相关联的业务；将哈希值与区块链上的哈希值进行比对以确定业务处理机构的用户是理赔机构的用户；以及将与业务处理机构的用户相关联的业务数据上传至区块链。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得更为清楚。

附图说明

从结合附图示出的本公开的实施例的以下描述中，本公开的前述和其它特征和优点将变得清楚。附图结合到本文中并形成说明书的一部分，进一步用于解释本公开的原理并使本领域技术人员能够制造和使用本公开。其中：

图1是示出了根据本公开的一些实施例的理赔方法的流程图；

图2至图4是示出了根据本公开的一些实施例的理赔方法的部分步骤的具体示例的流程图；

图5是示出了根据本公开的一些实施例的使用基于区块链的理赔方法进行理赔的示例处理的序列图；

图6是示出了根据本公开的一些实施例的监管由理赔机构提供的授权信息的示例处理的序列图；

图7是示出了根据本公开的一些实施例的使用基于区块链的理赔方法进行理赔的示例处理的序列图；

图8是示出了根据本公开的一些实施例的理赔装置的示例配置的示意性框图；

图9是示出了根据本公开的一些实施例的理赔系统的示例配置的示意性框图；以及

图10和图11是示出了根据本公开的一些实施例的示例哈希处理的示意图。

注意，在以下说明的实施方式中，有时在不同的附图之间共同使用同一附图标记来表示相同部分或具有相同功能的部分，而省略其重复说明。在一些情况中，使用相似的标号和字母表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

具体实施方式

下面将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。也就是说，本文中的结构及方法是以示例性的方式示出，来说明本公开中的结构和方法的不同实施例。然而，本领域技术人员将会理解，它们仅仅说明可以用来实施的本公开的示例性方式，而不是穷尽的方式。此外，附图不必按比例绘制，一些特征可能被放大以示出具体组件的细节。

另外，对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

在传统的理赔过程中，理赔机构与业务处理机构之间的信息共享的实现存在困难。通常，需要用户向理赔机构提供各种凭据信息并主动发起理赔，保险理赔机构的工作人员需要到相应的业务处理机构去核实这些信息然后再进行理赔，这样不仅效率低、出错率高而且成本高。即使有的理赔机构能够通过系统对接的方式与业务处理机构对接以获取用户的业务数据，但是由于理赔时业务数据并不存储在理赔机构本地并且业务数据往往较大，同时受对接双方的计算资源及能力等各方面的影响，因此系统对接要求高，对接过程耗时久，理赔效率低。此外，传统的线上或线下的理赔流程都难以追溯，并且在隐私保护、数据真实性和授权有效性等问题上难以得到有效监管。

区块链本质上是一个去中心化的数据库，是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。狭义来讲,区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。广义来讲，区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算范式。区块链上存储的数据需由全网节点共同维护，可以有效地在缺乏信任的节点之间传递价值。基于区块链的去中心化、可追溯性、不可篡改性等技术特性使其在数据共享系统天然适配，能够实现业务数据的隐私保护、权限层级控制的数据共享、用户个人信息的防泄漏等功能特性。

本公开的一方面提供了一种基于区块链的理赔方法。该理赔方法包括将第一哈希值上传至区块链，其中第一哈希值是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的。该理赔方法还包括获得第二哈希值，其中第二哈希值是通过对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理得到的。业务处理机构处理与由理赔机构理赔的对象相关联的业务。该理赔方法还包括将第二哈希值与区块链上的第一哈希值进行比对以确定第二用户是第一用户，以及将与第二用户相关联的业务数据上传至区块链。该理赔方法还包括基于区块链上的业务数据进行理赔。根据本公开的第一方面的理赔方法利用区块链的分布式账本技术以及密码学技术，不仅显著提高了理赔效率，还保证了用户的隐私数据不被泄露。

下面，将参照图1详细描述根据本公开的一些实施例的理赔方法100。

理赔方法100可以包括：在步骤S110中，将第一哈希值上传至区块链。第一哈希值可以是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的。

第一用户的识别信息可以是由第一用户在理赔机构投保时提供的与第一用户相关联的识别信息。第一用户的识别信息可以包括至少一条唯一识别该用户的信息。作为非限制性示例，第一用户的识别信息可以包括第一用户的姓名、证件号码和证件类型。例如，如图10所示，赵一在理赔机构A投保后，理赔机构A可以获得赵一的识别信息“赵一313120193005210101居民身份证”。可选地，第一用户的识别信息还可以附加地包括诸如性别、年龄等其它识别信息。

附加码可以由理赔机构生成，并且例如可以是具有预定长度的包括诸如数字、字母、符号等的字符串。该附加码可以是对外保密的，即，除非由理赔机构主动告知，否则其它各方不能知道该附加码。在一些实施例中，附加码可以与理赔机构相关联。每个理赔机构可以具有一个附加码，并且可以对其所有用户使用该附加码。例如如图10所示，与理赔机构A相关联的附加码为“Ab#cd#18”，以及与理赔机构B相关联的附加码为“abCD@806”。在另外一些实施例中，附加码可以与理赔机构的第一用户相关联。在一些示例中，理赔机构可以针对每个用户生成一个附加码，例如如图11所示。在一些实施例中，附加码可以是随机生成的。在一些实施例中，附加码可以是由理赔机构基于预定规则来确定的。

第一用户的识别信息与附加码的组合方式可以采取任何合适的方式。在一些实施例中，第一用户的识别信息与附加码可以分别是字符串，并且第一用户的识别信息与附加码的组合可以是通过将两个字符串组合而得到的组合字符串。在一些示例中，组合字符串可以是通过将两个字符串首尾衔接而得到的，例如如图10所示的“赵一313120193005210101居民身份证Ab#cd#18”等。可以理解的是，组合字符串也可以采用其它组合方式得到。在一些实施例中，可以通过预定算法将两个字符串组合得到组合字符串。

哈希处理是通过哈希算法进行的数据变换处理。哈希算法(即散列函数)是一种单向密码体制，其可以实现从明文到密文的不可逆的映射。哈希处理只有加密过程而没有解密过程。同时，哈希处理可以对任意长度的输入进行变换以得到固定长度的输出。如果两个作为输出的哈希值相同，则对应的两个输入彼此相同的概率极大。一般来说，当作为输出的哈希值的长度较长时，发生哈希碰撞(即，不同的输入通过哈希算法被变换成相同的输出)的概率极低。因此，基本上可以认为第一用户的识别信息和附加码的组合与第一哈希值之间的映射关系是唯一的。

例如如图10所示，理赔机构A在承接第一用户赵一和钱二的投保后，可以将赵一和钱二的识别信息分别与附加码“Ab#cd#18”组合并相应生成第一哈希值；理赔机构B在承接第一用户张三和钱二的投保后，可以将张三和钱二的识别信息分别与附加码“abCD@806”组合并相应生成第一哈希值。注意，图中示出的识别信息、附加码、哈希值仅仅是示意性的和示例性的，并不对本公开产生任何特别限制。

理赔方法100还可以包括：在步骤S120中，获得第二哈希值。第二哈希值可以是通过对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理得到的。

业务处理机构可以是处理与由理赔机构理赔的对象相关联的业务的机构。例如，当由理赔机构理赔的对象是人身健康时，业务处理机构可以是医疗机构；当由理赔机构理赔的对象是车辆时，业务处理机构可以是车辆维修机构。第二用户的识别信息可以是由第二用户在业务处理机构发生业务行为(例如，在医疗机构就诊等)时提供的与第二用户相关联的识别信息。第二用户的识别信息可以采取与第一用户的识别信息的形式相同的形式。也就是说，当第一用户的识别信息包括姓名、证件号码和证件类型时，第二用户的识别信息也包括姓名、证件号码和证件类型。例如，当赵一在业务处理机构a发生业务行为时，业务处理机构a可以获得赵一的识别信息“赵一313120193005210101居民身份证”。

业务处理机构可以以任何合适的方式从理赔机构处获得附加码，并且对第二用户的识别信息与附加码的组合进行哈希处理得到第二哈希值。第二用户的识别信息与附加码的组合方式可以按照第一用户的识别信息与附加码的组合方式。例如，当赵一在业务处理机构a发生业务行为时，业务处理机构a可以对赵一的识别信息与理赔机构A的附加码的组合“赵一313120193005210101居民身份证Ab#cd#18”进行哈希处理得到第二哈希值。

在一些实施例中，业务处理机构经由线下沟通的方式从理赔机构处获得附加码。在一些实施例中，理赔方法还可以包括将附加码上传至区块链。在一些实施例中，附加码可以与第一哈希值一起被上传至区块链。基于区块链的分布式账本技术，对于从区块链的任一节点上传至区块链的数据，在区块链的各个节点处都会保存一份该数据的副本，由此业务处理机构可以通过区块链获得附加码。在一些实施例中，将附加码上传至区块链包括将用业务处理机构的公钥加密的附加码上传至区块链，其中业务处理机构的公钥被预先上传至区块链。

因此，在一些实施例中，如图2所示，理赔方法100的步骤S110可以具体包括如下步骤：在步骤S111处，获得理赔机构的第一用户的识别信息；在步骤S112处，生成附加码；在步骤S113处，通过对第一用户的识别信息与附加码的组合进行哈希处理得到第一哈希值；在步骤S114处，用业务处理机构的公钥对附加码进行加密；以及在步骤S115处，将第一哈希值与加密的附加码上传至区块链。应注意，这些步骤的先后顺序不受特别限制，并且有时可以同时进行。还应注意，步骤S115可以包括将第一哈希值上传至区块链的子步骤和将加密的附加码上传至区块链的子步骤，这些子步骤可以分开进行。相应地，在一些实施例中，如图3所示，理赔方法100的步骤S120可以具体包括如下步骤：在步骤S121处，获得业务处理机构的第二用户的识别信息；在步骤S122处，通过用业务处理机构的私钥进行解密得到附加码；以及在步骤S123处，通过对第二用户的识别信息与附加码的组合进行哈希处理得到第二哈希值。

在一些实施例中，业务处理机构可以包括处理与由理赔机构理赔的第一对象相关联的业务的第一业务处理机构以及处理与由理赔机构理赔的第二对象相关联的业务的第二业务处理机构，第一对象可以不同于第二对象。在一些实施例中，当第一用户的能够由理赔机构理赔的对象包括第一对象而不包括第二对象时，将附加码上传至区块链可以包括将用第一业务处理机构的公钥加密的附加码上传至区块链，其中第一业务处理机构和第二业务处理机构的公钥可以被预先上传至区块链。在一些实施例中，当第一用户的能够由理赔机构理赔的对象包括第一对象和第二对象时，将附加码上传至区块链可以包括分别将用第一业务处理机构的公钥加密的附加码和用第二业务处理机构的公钥加密的附加码上传至区块链，其中第一业务处理机构和第二业务处理机构的公钥可以被预先上传至区块链。在一些实施例中，当第一用户的能够由理赔机构理赔的对象包括第一对象并且第一业务处理机构包括第三业务处理机构和第四业务处理机构时，将附加码上传至区块链可以包括分别将用第三业务处理机构的公钥加密的附加码和用第四业务处理机构的公钥加密的附加码上传至区块链，并且其中，第三业务处理机构和第四业务处理机构的公钥可以被预先上传至区块链。

具体地，在一些情况下，理赔机构可以对多种对象进行理赔(即，提供多个险种的保险服务)，并且区块链可以包括处理相应业务的多家业务处理机构(例如，业务处理机构a、业务处理机构b)。例如，理赔机构A可以提供人身健康保险和车辆保险的服务，作为医疗机构的业务处理机构a可以处理与由理赔机构理赔的第一对象(即，人身健康)相关联的业务，作为车辆维修机构的业务处理机构b可以处理与由理赔机构理赔的第二对象(即，车辆)相关联的业务。由于赵一只在理赔机构A办理了人身健康保险而没有办理车辆保险，因此作为第一用户的赵一的能够由理赔机构A理赔的对象包括第一对象(即，人身健康)而不包括第二对象(即，车辆)。在这种情况下，在上述步骤S114中，理赔机构A可以只将用业务处理机构a的公钥加密的附加码上传至区块链。另外，由于钱二在理赔机构A办理了人身健康保险和车辆保险，因此作为第一用户的钱二的能够由理赔机构A理赔的对象包括第一对象(即，人身健康)和第二对象(即，车辆)。在这种情况下，在上述步骤S114中，理赔机构A可以分别将用业务处理机构a的公钥加密的附加码和用业务处理机构b的公钥加密的附加码上传至区块链。另外，在参与区块链的医疗机构除了业务处理机构a之外还包括业务处理机构c的情况下，理赔机构A可以分别将用业务处理机构a的公钥加密的附加码和用业务处理机构c的公钥加密的附加码上传至区块链。

这样，可以适当减少附加码的不必要的上传次数。而且，由于与用户未投保的对象相关联的业务处理机构不能获得附加码，因而即使用户在与该用户未投保的对象相关联的业务处理机构发生业务行为时，业务处理机构也不会通过稍后描述的步骤将用户确定为理赔机构的用户而将用户的业务数据暴露给理赔机构。例如，赵一只在理赔机构A办理了人身健康保险而没有办理车辆保险，如果理赔机构A还将用业务处理机构b的公钥加密的附加码上传至区块链，那么当赵一在业务处理机构b修理车辆时，业务处理机构b能够获得赵一的识别信息和附加码，由此可通过稍后描述的步骤将赵一确定为理赔机构A的用户并把赵一的车辆维修数据上传至区块链，使得理赔机构A能够了解到赵一对车辆保险存在需求并且可以作为潜在用户发展。

理赔方法100还可以包括：在步骤S130中，将第二哈希值与区块链上的第一哈希值进行比对。第二哈希值被与区块链上的第一哈希值进行比对，以确定第二用户是第一用户。在一些实施例中，确定第二用户是第一用户可以包括确定第二哈希值与第一哈希值相同。具体地，业务处理机构可以将获得的第二哈希值与本地的第一哈希值副本进行比对，如果存在与第二哈希值相同的第一哈希值，则说明与该第二哈希值相关联的第二用户对应于与该第一哈希值相关联的第一用户。例如，业务处理机构a可以将对赵一的识别信息与理赔机构A的附加码的组合“赵一313120193005210101居民身份证Ab#cd#18”进行哈希处理得到的第二哈希值与区块链上的第一哈希值进行比对，发现存在相同的哈希值，则可以确定赵一是理赔机构A的投保用户。在一些情况下，区块链可以包括多家理赔机构(例如，理赔机构A、理赔机构B)，而用户可能只在其中一家或一些理赔机构投保(例如，赵一只在理赔机构A而没有在理赔机构B投保)。在这些情况下，业务处理机构a能够获得与理赔机构A相关联的附加码为“Ab#cd#18”和与理赔机构B相关联的附加码为“abCD@806”，并且分别对赵一的识别信息与这些附加码的组合“赵一313120193005210101居民身份证Ab#cd#18”、“赵一313120193005210101居民身份证abCD@806”进行哈希处理得到两个第二哈希值。然后，业务处理机构a通过比对后发现只存在与“赵一313120193005210101居民身份证Ab#cd#18”的第二哈希值相同的第一哈希值，而不存在与“赵一313120193005210101居民身份证abCD@806”的第二哈希值相同的第一哈希值，因此业务处理机构a可以确定赵一是理赔机构A的投保用户，而不是理赔机构B的投保用户。

理赔方法100还可以包括：在步骤S140中，将业务数据上传至区块链。业务处理机构在确定第二用户是第一用户后，可以将与第二用户相关联的业务数据上传至区块链。在一些实施例中，业务数据在被上传至区块链之前被用理赔机构的公钥进行加密，其中理赔机构的公钥被预先上传至区块链。在一些实施例中，业务数据在被上传至区块链之前被用随机对称密钥通过对称加密算法进行加密，随机对称密钥被用理赔机构的公钥通过非对称加密算法进行加密并被上传至区块链，其中理赔机构的公钥被预先上传至区块链。例如，如图4所示，理赔方法100的步骤S140可以具体包括如下步骤：在步骤S141处，生成随机对称密钥；在步骤S142处，用随机对称密钥对与第二用户相关联的业务数据进行加密；在步骤S143处，用理赔机构的公钥对随机对称密钥进行加密；以及在步骤S144处，将加密的业务数据和随机对称密钥上传至区块链。对称加密算法的特点是计算量小、加密速度快、加密效率高，而非对称加密算法的特点是如果用公钥对数据进行加密，只有用对应的私钥才能解密。因此，通过用对称加密算法对数据量庞大的业务数据进行加密，并用非对称加密算法对随机对称密钥进行加密，可以实现迅速高效且保密性好的数据加密。

例如，参考图10，继续刚才的例子，在业务处理机构a通过哈希值的比对确定赵一是理赔机构A的投保用户而不是理赔机构B的投保用户后，业务处理机构a可以用理赔机构A的公钥加密与赵一相关联的业务数据并上传至区块链，但是不会用理赔机构B的公钥加密与赵一相关联的业务数据并上传至区块链。这样，理赔机构B并不能获得与赵一相关联的业务数据。另外，在业务处理机构a通过哈希值的比对确定赵一是理赔机构A的投保用户以及张三是理赔机构B的投保用户后，业务处理机构a可以用理赔机构A的公钥加密与赵一相关联的业务数据并上传至区块链，以及用理赔机构B的公钥加密与张三相关联的业务数据并上传至区块链。另外，在业务处理机构a通过哈希值的比对确定钱二既是理赔机构A的投保用户又是理赔机构B的投保用户后，业务处理机构a可以用理赔机构A的公钥加密与钱二相关联的业务数据并上传至区块链，以及用理赔机构B的公钥加密与钱二相关联的业务数据并上传至区块链。在结合对称加密算法与非对称加密算法对业务数据进行加密的实施例中，例如，在业务处理机构a通过哈希值的比对确定钱二既是理赔机构A的投保用户又是理赔机构B的投保用户后，业务处理机构a可以用随机对称密钥加密与钱二相关联的业务数据并上传至区块链，以及用理赔机构A和B的公钥分别加密随机对称密钥并将加密的随机对称密钥的列表上传至区块链。

理赔方法100还可以包括：在步骤S150中，基于区块链上的业务数据进行理赔。在一些实施例中，理赔方法还可以包括将理赔结果上传至所述区块链。在一些实施例中，理赔结果包括唯一标识业务数据的信息。该唯一标识业务数据的信息例如可以是发票号码等。在一些实施例中，理赔结果可以被明文上传至区块链。当其它理赔机构通过区块链获得该理赔结果时，可以确定与该理赔结果对应的业务数据已被理赔，由此可以避免重复理赔的发生。因此，在一些实施例中，在步骤S150之前，理赔方法100还可以包括确定区块链上的理赔结果的步骤。当区块链上还没有出现相应的理赔结果时，理赔机构可以继续进行理赔。当区块链上出现相应的理赔结果时，理赔机构可以不进行理赔。

在根据本公开的实施例的理赔方法中，用于进行比对的哈希值是对用户的识别信息与附加码的组合进行哈希处理得到的。相比于对通过仅对用户的识别信息进行哈希处理得到的哈希值进行比对的方案，可以更好地保护用户的隐私。具体地，在对通过仅对用户的识别信息进行哈希处理得到的哈希值进行比对的情况下，用户可能在某些具有保险业务的理赔机构办理过非保险业务，而这些理赔机构在获得用户的识别信息后可以对用户的识别信息进行哈希处理获得哈希值。如果这些理赔机构在区块链上找到相同的哈希值，则这些理赔机构可以确定该用户在其它机构办理过保险业务并且对保险业务存在需求，因而可能会向用户推销本机构的相关业务。但是，在根据本公开的理赔方法中，用于进行比对的哈希值是对用户的识别信息与附加码的组合进行哈希处理得到的。由于理赔机构之间不知道对方的附加码，因而即使掌握了用户的识别信息，也无法确定用户的具体投保情况。因此，可以更好地保护用户的隐私，并且防止用户被打扰。

在一些实施例中，理赔方法还可以包括将与理赔机构的第一用户相关联的授权信息上传至区块链，以及在确定第二用户是第一用户并且确定与第一用户相关联的授权信息有效时，将与第二用户相关联的业务数据上传至区块链。图5是示出了根据本公开的一些实施例的使用基于区块链的理赔方法进行理赔的示例处理200的序列图。区块链210例如可以是联盟链，理赔机构211和业务处理机构212是该联盟链的成员节点。在示例处理200中，在以上讨论的理赔方法100及其实施例的基础上，还考虑了与第一用户相关联的授权信息的有效性。

在步骤S2011中，理赔机构211可以将它的公钥上传至区块链210，以及在步骤S2012中，业务处理机构212可以将它的公钥上传至区块链210。通过这些步骤，在理赔机构211的节点处存在业务处理机构212的公钥的副本，而在业务处理机构212的节点处存在理赔机构211的公钥的副本。

理赔机构211可以在步骤S2021中生成附加码并在步骤S2031中获得第一用户的识别信息，然后在步骤S2051中通过对第一用户的识别信息与附加码的组合进行哈希处理得到第一哈希值并在步骤S2061中将第一哈希值和用业务处理机构212的公钥加密的附加码上传至区块链210。

附加地，理赔机构211还可以在步骤S2041中生成与第一用户相关联的授权信息，并且在步骤S2061中将授权信息上传至区块链210。在一些实施例中，授权信息可以包括第一授权信息和第二授权信息，其中第一授权信息可以包括指示授权信息的有效性的信息并且被明文上传至区块链，第二授权信息不同于第一授权信息并且被加密上传至区块链。在一些示例中，第一授权信息可以包括指示授权状态及有效期限的信息，例如可以被表示为“有效，2022/12/31到期”等。在一些示例中，第二授权信息可以包括诸如第一用户的具体投保信息等信息。

业务处理机构212可以在步骤S2022中用它的私钥进行解密以获得附加码并且在步骤S2032中获得第二用户的识别信息，然后在步骤S2042中通过对第二用户的识别信息与附加码的组合进行哈希处理得到第二哈希值。业务处理机构212可以在步骤S2052中将第二哈希值与第一哈希值进行比对以确定第二用户是第一用户。附加地，业务处理机构212可以在步骤S2062中通过查看被明文上传至区块链210的第一授权信息来确定与第一用户相关联的授权信息有效。在确定第二用户是第一用户并且确定与第一用户相关联的授权信息有效后，业务处理机构212可以在步骤S2072中用随机对称密钥加密与第二用户相关联的业务数据，并用理赔机构的公钥加密随机对称密钥，然后在步骤S2082中将加密的业务数据和加密的随机对称密钥上传至区块链210。

理赔机构211可以在步骤S2071中用它的私钥解密得到随机对称密钥，进而得到业务数据，并在步骤S2081中基于业务数据进行理赔。最后理赔机构211可以在步骤S2091中将理赔结果上传至区块链210。如前所述，在一些实施例中，理赔机构211可以在进行步骤S2081之前先确定区块链210上尚未上传有理赔结果。

可以看到，整个示例处理200无需用户参与，业务处理机构和理赔机构在彼此之间自行进行数据传递。这样，在理赔机构完成投保的用户在业务处理机构完成相应业务行为后，无需主动发起理赔申请并提供相关凭据，只需要等待理赔结果即可。由此，可以极大地便利用户从而改善用户体验。另外，基于区块链的特点，业务处理机构和理赔机构之间直接进行数据传递保证了数据的真实性、可靠性、保密性，降低了理赔机构的审核成本，提高了理赔效率。

在一些实施例中，与第一用户相关联的授权信息中的第二授权信息在被上传至区块链之前可以被用监管机构的公钥进行加密，其中监管机构的公钥被预先上传至区块链。在一些实施例中，第二授权信息在被上传至区块链之前被用随机对称密钥通过对称加密算法进行加密，随机对称密钥被用监管机构的公钥通过非对称加密算法进行加密并被上传至区块链，其中监管机构的公钥被预先上传至所述区块链。在一些实施例中，理赔方法还可以包括审核第二授权信息并且基于审核的结果来更新第一授权信息。

图6是示出了根据本公开的一些实施例的监管由理赔机构提供的授权信息的示例处理300的序列图。区块链210的成员节点还可以包括监管机构213。在步骤S3013中，监管机构213可以将它的公钥上传至区块链210，从而在理赔机构211的节点处存在监管机构213的公钥的副本。

理赔机构211可以在步骤S3011中生成与第一用户相关联的授权信息，该授权信息包括第一授权信息和第二授权信息(对应于示例处理200的步骤S2041)。然后，理赔机构211可以在步骤S3021中用随机对称密钥加密第二授权信息，并用监管机构213的公钥加密随机对称密钥，然后在步骤S3031中将明文的第一授权信息、加密的第二授权信息和加密的随机对称密钥上传至区块链。如前所述，第二授权信息的数据量也可能较大，因此结合对称加密算法和非对称加密算法进行加密可以兼顾数据加密的速度、效率和安全性。

监管机构213可以在步骤S3023中用它的私钥解密得到随机对称密钥，进而得到第二授权信息，然后在步骤S3033中审核第二授权信息并基于审核的结果更新第一授权信息，最后在步骤S3043中将更新的第一授权信息上传至区块链210。监管机构213可以监管区块链上的授权信息的有效性，从而监督理赔以合法合规的方式进行。

在一些实施例中，前述附加码可以是第一附加码，并且其中，第一哈希值可以是通过对理赔机构的第一用户的识别信息、第一附加码以及不同于第一附加码的第二附加码的组合进行哈希处理得到的，第二哈希值可以是通过对业务处理机构的第二用户的识别信息、第一附加码以及第二附加码的组合进行哈希处理得到的。第二附加码例如可以是具有预定长度的包括诸如数字、字母、符号等的字符串。在一些实施例中，第二附加码可以与由理赔机构理赔的对象相关联。作为非限制性示例，第二附加码可以是险种代码或基于险种代码得到的衍生码。在一些实施例中，第二附加码可以与业务处理机构相关联。作为非限制性示例，第二附加码可以是业务处理机构的行业代码或基于行业代码得到的衍生码。

第一用户的识别信息、第一附加码与第二附加码的组合方式可以采取任何合适的方式。在一些实施例中，第一用户的识别信息、第一附加码与第二附加码可以分别是字符串，并且第一用户的识别信息、第一附加码与第二附加码的组合可以是通过将三个字符串组合而得到的组合字符串。在一些示例中，组合字符串可以是通过将三个字符串首尾衔接而得到的，例如如图11所示的“赵一313120193005210101居民身份证A12C*567H12405”等。可以理解的是，组合字符串也可以采用其它组合方式得到。在一些实施例中，可以通过预定算法将三个字符串组合得到组合字符串。第二用户的识别信息、第一附加码与第二附加码的组合方式可以按照第一用户的识别信息、第一附加码与第二附加码的组合方式。

在一些实施例中，理赔方法还可以包括将第二附加码上传至区块链。在一些实施例中，第二附加码可以由业务处理机构生成并上传。当然，第二附加码也可以通过除区块链以外的其它线上方式或线下方式进行传递。在一些实施例中，将第二附加码上传至区块链包括将用理赔机构的公钥加密的第二附加码上传至区块链，并且其中，理赔机构的公钥被预先上传至区块链。在一些实施例中，业务处理机构可以用对与业务处理机构的业务相关联的对象进行理赔的理赔机构的公钥加密第二附加码并上传至区块链。例如，如果理赔机构A和B都提供人身健康保险服务但是理赔机构C不提供人身健康保险服务，那么作为医疗机构的业务处理机构a可以将用理赔机构A的公钥加密的第二附加码和用理赔机构B的公钥加密的第二附加码上传至区块链，但是不用理赔机构C的公钥加密第二附加码并上传。所以，理赔机构C不能获得业务处理机构a的第二附加码。

在一些实施例中，不同业务处理机构可以生成不同的第二附加码。在一些实施例中，业务处理机构可以包括处理与由理赔机构理赔的第一对象相关联的业务的第一业务处理机构以及处理与由理赔机构理赔的第二对象相关联的业务的第二业务处理机构，第一对象不同于第二对象，并且其中，与第一业务处理机构相关联的第二附加码不同于与第二业务处理机构相关联的第二附加码。例如，如图11所示，与医疗机构相关联的第二附加码为“H12405”，与车辆维修机构相关联的第二附加码为“V27516”。在一些实施例中，第一业务处理机构可以包括第三业务处理机构和第四业务处理机构，其中与第三业务处理机构相关联的第二附加码和与第四业务处理机构相关联的第二附加码相同。也就是说，处理的业务与由理赔机构理赔的同一对象相关联的业务处理机构可以具有相同的第二附加码。例如，与均作为医疗机构的业务处理机构a和c相关联的第二附加码可以相同。

在一些实施例中，当第一用户的能够由理赔机构理赔的对象包括第一对象而不包括第二对象时，第一哈希值是通过对理赔机构的第一用户的识别信息、第一附加码以及与第一业务处理机构相关联的第二附加码的组合进行哈希处理得到的。例如，在这种情况下，由于赵一在理赔机构A仅投保人身健康而没有投保车辆，所以理赔机构A可以得到对应于赵一的识别信息、第一附加码以及与医疗机构相关联的第二附加码的组合“赵一313120193005210101居民身份证A12C*567H12405”的第一哈希值。

在一些实施例中，当第一用户的能够由理赔机构理赔的对象包括第一对象和第二对象时，分别将通过对理赔机构的第一用户的识别信息、第一附加码、与第一业务处理机构相关联的第二附加码的组合进行哈希处理得到的第一哈希值以及通过对理赔机构的第一用户的识别信息、第一附加码、与第二业务处理机构相关联的第二附加码的组合进行哈希处理得到的第一哈希值上传至区块链。例如，在这种情况下，由于钱二在理赔机构A投保人身健康和车辆，所以理赔机构A可以得到对应于钱二的识别信息、第一附加码以及与医疗机构相关联的第二附加码的组合“钱二311200195812111507居民身份证B765cd21H12405”的第一哈希值，还可以得到对应于钱二的识别信息、第一附加码以及与车辆维修机构相关联的第二附加码的组合“钱二311200195812111507居民身份证B765cd21V27516”的第一哈希值。

这样，当赵一在车辆维修机构维修车辆时，即使车辆维修机构能够获得赵一的识别信息和理赔机构的第一附加码，由于它不能知道与医疗机构相关联的第二附加码而只知道与自己相关联的第二附加码，因此该车辆维修机构只能获得对应于赵一的识别信息、第一附加码以及与车辆维修机构相关联的第二附加码的组合“赵一313120193005210101居民身份证A12C*567V27516”的第二哈希值，因此它无法在区块链上找到具有相同哈希值的第一哈希值，也就不会将赵一的车辆维修数据上传至区块链，从而避免赵一的车辆维修数据被暴露给理赔机构。

下面结合图7描述根据本公开的一些实施例的结合使用第二附加码生成哈希值进行理赔的示例处理400。

理赔机构211和业务处理机构212可以分别在步骤S4011和S4012中将各自的公钥上传至区块链，并且可以分别在步骤S4021和S4022中各自生成第一附加码和第二附加码。然后，业务处理机构212可以在步骤S4032中将用理赔机构211的公钥加密的第二附加码上传至区块链210。

理赔机构211可以在步骤S4031中用它的私钥解密得到第二附加码，在步骤S4041中获得第一用户的识别信息，以及在步骤S4051中通过对第一用户的识别信息、第一附加码和第二附加码的组合进行哈希处理得到第一哈希值。之后，理赔机构211可以在步骤S4061中将第一哈希值以及用业务处理机构212的公钥加密的第一附加码上传至区块链210。

业务处理机构212可以在步骤S4042中用它的私钥解密得到第一附加码，在步骤S4052中获得第二用户的识别信息，以及在步骤S4062中通过对第二用户的识别信息、第一附加码与第二附加码的组合进行哈希处理得到第二哈希值。业务处理机构212可以在步骤S4072中将第二哈希值与第一哈希值进行比对以确定第二用户是第一用户之后，在步骤S4082中用随机对称密钥加密与第二用户相关联的业务数据，并用理赔机构211的公钥加密随机对称密钥，然后在步骤S4092中将加密的业务数据以及加密的随机对称密钥上传至区块链210。

理赔机构211可以在步骤S4071中用它的私钥解密得到随机对称密钥，进而得到业务数据，然后在步骤S4081中基于业务数据进行理赔。最后，理赔机构211可以在步骤S4091中将理赔结果上传至区块链。如前所述，在一些实施例中，理赔机构211还可以在进行步骤S4081之前先确定区块链210上尚未上传有理赔结果。

在一些实施例中，根据本公开的实施例的理赔方法还包括当新数据被上传至区块链时，向区块链的所有节点推送通知以提示新数据被上传至区块链。如前所述，区块链的节点可以包括理赔机构、业务处理机构、监管机构等，新数据可以是各个机构的公钥、第一附加码、第二附加码、第一哈希值、业务数据、随机对称密钥、授权信息、理赔结果等。通过这种配置，可以在第一时间通知参与区块链的各个节点机构查看区块链上的数据并进行相应操作，从而优化处理时效。

图8示出了根据本公开的一些实施例的基于区块链的理赔装置500。理赔装置500可以包括一个或多个处理器510和存储器520。一个或多个处理器510可以被耦接至存储器510。存储器520可以存储在由一个或多个处理器510执行时使得一个或多个处理器510执行根据本公开的任一实施例所述的理赔方法的计算机可读指令。

在本公开中，“处理器”可以指具有计算处理能力的任何计算处理单元或设备，包括但不限于单核处理器；具有软件多线程执行能力的单处理器；多核处理器；具有软件多线程执行能力的多核处理器；具有硬件多线程技术的多核处理器；并行平台；以及具有分布式共享存储器的并行平台。此外，处理器可以指被设计为执行本文所述的功能的集成电路、专用集成电路(ASIC)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑控制器(PLC)、复杂可编程逻辑设备(CPLD)、分立的门或晶体管逻辑、分立的硬件部件或其任意组合。处理器也可以被实现为计算处理单元的组合。在本公开中，“存储器”可以是或者易失性存储器或者非易失性存储器，或者可以包括易失性存储器和非易失性存储器两者。作为说明而非限制，非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦式可编程ROM(EEPROM)、闪存或非易失性随机存取存储器(RAM)(例如，铁电RAM(FeRAM))。作为说明而非限制，易失性存储器可以包括RAM，RAM可以以诸如同步RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双倍数据速率SDRAM(DDR SDRAM)、增强SDRAM(ESDRAM)、同步链接DRAM(SLDRAM)、直接Rambus RAM(DRRAM)、直接Rambus动态RAM(DRDRAM)和Rambus动态RAM(RDRAM)之类的许多形式得到。

另外，本公开的一个方面还提供了一种非暂态计算机可读存储介质，该非暂态计算机可读存储介质可以存储计算机可读指令，这些计算机可读指令在由处理器执行时使得处理器执行根据本公开的任一实施例所述的理赔方法。这里所描述的计算机可读指令可以从计算机可读存储介质下载到各个计算处理设备，或者通过网络(例如因特网、局域网、广域网和/或无线网)下载到外部计算机或外部存储设备。每个计算处理设备中的网络适配卡或者网络接口从网络接收计算机可读指令，并转发该计算机可读指令，以供存储在各个计算处理设备中的计算机可读存储介质中。计算机可读存储介质的示例包括但不限于只读存储器、随机存取存储器、CD-ROM、DVD、磁带、硬盘驱动器、固态驱动器和光学数据存储设备等。计算机可读存储介质还可分布在网络耦接的计算机系统中使得计算机可读指令以分布式方式来存储和执行。

图9是示出了根据本公开的一些实施例的基于区块链的理赔系统600的示例配置的示意性框图。理赔系统600可以包括理赔机构节点设备610和业务处理机构节点设备620。如前所述，区块链可以例如是联盟链，理赔机构节点设备610和业务处理机构节点设备620可以是该联盟链的成员节点设备。理赔机构节点设备610可以被配置为对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理以得到第一哈希值，将第一哈希值上传至区块链，以及基于区块链上的业务数据进行理赔。业务处理机构节点设备620可以被配置为对业务处理机构的第二用户的识别信息与附加码的组合进行哈希处理以得到第二哈希值，将第二哈希值与区块链上的第一哈希值进行比对以确定第二用户是第一用户，以及将与第二用户相关联的业务数据上传至区块链。业务处理机构可以是处理与由理赔机构理赔的对象相关联的业务的机构。

理赔机构节点设备610还可以被配置为执行以上关于理赔方法描述的多个步骤中的可以在理赔机构处进行的一个或多个步骤，以及业务处理机构节点设备620还可以被配置为执行以上关于理赔方法描述的多个步骤中的可以在业务处理机构处进行的一个或多个步骤，在此不再赘述。

如在此所使用的，词语“示例性的”意指“用作示例、实例或说明”，而不是作为将被精确复制的“模型”。在此示例性描述的任意实现方式并不一定要被解释为比其它实现方式优选的或有利的。而且，本公开不受在技术领域、背景技术、发明内容或具体实施方式中所给出的任何所表述的或所暗示的理论所限定。

另外，仅仅为了参考的目的，还可以在本文中使用“第一”、“第二”等类似术语，并且因而并非意图限定。例如，除非上下文明确指出，否则涉及元素的词语“第一”、“第二”和其它此类数字词语并没有暗示顺序或次序。

还应理解，“包括/包含”一词在本文中使用时，说明存在所指出的特征、整体、步骤、操作、单元和/或组件，但是并不排除存在或增加一个或多个其它特征、整体、步骤、操作、单元和/或组件以及/或者它们的组合。

如本文所使用的，术语“和/或”包括相关联的列出项目中的一个或多个的任何和所有组合。本文中使用的术语只是出于描述特定实施例的目的，并不旨在限制本公开。如本文中使用的，单数形式“一”、“一个”和“该”也旨在包括复数形式，除非上下文另外清楚指示。

本领域技术人员应当意识到，在上述步骤或操作之间的边界仅仅是说明性的。多个步骤或操作可以结合成单个步骤或操作，单个步骤或操作可以分布于附加的步骤或操作中，并且步骤或操作可以在时间上至少部分重叠地执行。而且，另选的实施例可以包括特定步骤或操作的多个实例，并且在其它各种实施例中可以改变步骤或操作的顺序。但是，其它的修改、变化和替换同样是可能的。可以以任何方式和/或与其它实施例的方面或元件相结合地组合以上公开的所有实施例的方面和元件，以提供多个附加实施例。因此，本说明书和附图应当被看作是说明性的，而非限制性的。

附图中的流程图和框图显示了根据本公开的多个实施例的方法、系统、装置、设备和计算机可读存储介质的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本公开还可以包括如下示例：

1、一种基于区块链的理赔方法，包括：

将第一哈希值上传至所述区块链，其中所述第一哈希值是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的；

获得第二哈希值，其中所述第二哈希值是通过对业务处理机构的第二用户的识别信息与所述附加码的组合进行哈希处理得到的，所述业务处理机构处理与由所述理赔机构理赔的对象相关联的业务；

将所述第二哈希值与所述区块链上的所述第一哈希值进行比对以确定所述第二用户是所述第一用户；

将与所述第二用户相关联的业务数据上传至所述区块链；以及

基于所述区块链上的所述业务数据进行理赔。

2、根据示例1所述的理赔方法，其中，所述附加码与所述理赔机构相关联。

3、根据示例1所述的理赔方法，其中，所述附加码与所述理赔机构的第一用户相关联。

4、根据示例1所述的理赔方法，其中，所述附加码是随机生成的。

5、根据示例1所述的理赔方法，还包括将所述附加码上传至所述区块链。

6、根据示例5所述的理赔方法，其中，将所述附加码上传至所述区块链包括将用所述业务处理机构的公钥加密的所述附加码上传至所述区块链，其中所述业务处理机构的所述公钥被预先上传至所述区块链。

7、根据示例5所述的理赔方法，其中，所述业务处理机构包括处理与由所述理赔机构理赔的第一对象相关联的业务的第一业务处理机构以及处理与由所述理赔机构理赔的第二对象相关联的业务的第二业务处理机构，所述第一对象不同于所述第二对象。

8、根据示例7所述的理赔方法，其中，当所述第一用户的能够由所述理赔机构理赔的对象包括所述第一对象而不包括所述第二对象时，将所述附加码上传至所述区块链包括将用所述第一业务处理机构的公钥加密的所述附加码上传至所述区块链，其中所述第一业务处理机构和所述第二业务处理机构的公钥被预先上传至所述区块链。

9、根据示例7所述的理赔方法，其中，当所述第一用户的能够由所述理赔机构理赔的对象包括所述第一对象和所述第二对象时，将所述附加码上传至所述区块链包括分别将用所述第一业务处理机构的公钥加密的所述附加码和用所述第二业务处理机构的公钥加密的所述附加码上传至所述区块链，其中所述第一业务处理机构和所述第二业务处理机构的公钥被预先上传至所述区块链。

10、根据示例7所述的理赔方法，其中，当所述第一用户的能够由所述理赔机构理赔的对象包括所述第一对象并且所述第一业务处理机构包括第三业务处理机构和第四业务处理机构时，将所述附加码上传至所述区块链包括分别将用所述第三业务处理机构的公钥加密的所述附加码和用所述第四业务处理机构的公钥加密的所述附加码上传至所述区块链，并且其中，所述第三业务处理机构和所述第四业务处理机构的公钥被预先上传至所述区块链。

11、根据示例1所述的理赔方法，其中，所述附加码是第一附加码，并且其中，所述第一哈希值是通过对所述理赔机构的第一用户的识别信息、所述第一附加码以及不同于所述第一附加码的第二附加码的组合进行哈希处理得到的，所述第二哈希值是通过对所述业务处理机构的第二用户的识别信息、所述第一附加码以及所述第二附加码的组合进行哈希处理得到的。

12、根据示例11所述的理赔方法，还包括将所述第二附加码上传至所述区块链。

13、根据示例12所述的理赔方法，其中，所述第二附加码与由所述理赔机构理赔的对象相关联。

14、根据示例12所述的理赔方法，其中，所述第二附加码与所述业务处理机构相关联。

15、根据示例14所述的理赔方法，其中，将所述第二附加码上传至所述区块链包括将用所述理赔机构的公钥加密的所述第二附加码上传至所述区块链，并且其中，所述理赔机构的所述公钥被预先上传至所述区块链。

16、根据示例14所述的理赔方法，其中，所述业务处理机构包括处理与由所述理赔机构理赔的第一对象相关联的业务的第一业务处理机构以及处理与由所述理赔机构理赔的第二对象相关联的业务的第二业务处理机构，所述第一对象不同于所述第二对象，并且其中，与所述第一业务处理机构相关联的第二附加码不同于与所述第二业务处理机构相关联的第二附加码。

17、根据示例16所述的理赔方法，其中，当所述第一用户的能够由所述理赔机构理赔的对象包括所述第一对象而不包括所述第二对象时，所述第一哈希值是通过对所述理赔机构的第一用户的识别信息、所述第一附加码以及与所述第一业务处理机构相关联的第二附加码的组合进行哈希处理得到的。

18、根据示例16所述的理赔方法，其中，当所述第一用户的能够由所述理赔机构理赔的对象包括所述第一对象和所述第二对象时，分别将通过对所述理赔机构的第一用户的识别信息、所述第一附加码、与所述第一业务处理机构相关联的第二附加码的组合进行哈希处理得到的第一哈希值以及通过对所述理赔机构的第一用户的识别信息、所述第一附加码、与所述第二业务处理机构相关联的第二附加码的组合进行哈希处理得到的第一哈希值上传至区块链。

19、根据示例16所述的理赔方法，其中，所述第一业务处理机构包括第三业务处理机构和第四业务处理机构，并且其中，与所述第三业务处理机构相关联的第二附加码和与所述第四业务处理机构相关联的第二附加码相同。

20、根据示例1所述的理赔方法，其中，所述业务数据在被上传至所述区块链之前被用所述理赔机构的公钥进行加密，其中所述理赔机构的所述公钥被预先上传至所述区块链。

21、根据示例1所述的理赔方法，其中，所述业务数据在被上传至所述区块链之前被用随机对称密钥通过对称加密算法进行加密，所述随机对称密钥被用所述理赔机构的公钥通过非对称加密算法进行加密并被上传至所述区块链，其中所述理赔机构的所述公钥被预先上传至所述区块链。

22、根据示例1所述的理赔方法，还包括将理赔结果上传至所述区块链。

23、根据示例22所述的理赔方法，其中，所述理赔结果包括唯一标识所述业务数据的信息。

24、根据示例1所述的理赔方法，其中，确定所述第二用户是所述第一用户包括确定所述第二哈希值与所述第一哈希值相同。

25、根据示例1所述的理赔方法，还包括：

将与所述理赔机构的第一用户相关联的授权信息上传至所述区块链；以及

在确定所述第二用户是所述第一用户并且确定与所述第一用户相关联的授权信息有效时，将与所述第二用户相关联的业务数据上传至所述区块链。

26、根据示例25所述的理赔方法，其中，所述授权信息包括第一授权信息和第二授权信息，所述第一授权信息包括指示授权信息的有效性的信息并且被明文上传至所述区块链，所述第二授权信息不同于所述第一授权信息并且被加密上传至区块链。

27、根据示例26所述的理赔方法，其中，所述第二授权信息在被上传至所述区块链之前被用监管机构的公钥进行加密，其中所述监管机构的所述公钥被预先上传至所述区块链。

28、根据示例26所述的理赔方法，其中，所述第二授权信息在被上传至所述区块链之前被用随机对称密钥通过对称加密算法进行加密，所述随机对称密钥被用监管机构的公钥通过非对称加密算法进行加密并被上传至所述区块链，其中所述监管机构的所述公钥被预先上传至所述区块链。

29、根据示例26所述的理赔方法，还包括审核所述第二授权信息并且基于审核的结果来更新所述第一授权信息。

30、根据示例1所述的理赔方法，还包括当新数据被上传至所述区块链时，向所述区块链的所有节点推送通知以提示所述新数据被上传至所述区块链。

31、根据示例1至30中任一项所述的理赔方法，其中，所述理赔机构包括其理赔的对象包含人身健康的保险机构，所述业务处理机构包括医疗机构。

32、一种基于区块链的理赔装置，包括：

一个或多个处理器；以及

与所述一个或多个处理器耦接并且存储计算机可读指令的存储器，所述计算机可读指令在由所述一个或多个处理器执行时使得所述一个或多个处理器执行根据示例1至31中任一项所述的理赔方法。

33、一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机可读指令，所述计算机可读指令在由处理器执行时使得所述处理器执行根据示例1至31中任一项所述的理赔方法。

34、一种基于区块链的理赔系统，包括：

理赔机构节点设备，被配置为：

对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理以得到第一哈希值；

将所述第一哈希值上传至所述区块链；以及

基于所述区块链上的业务数据进行理赔；以及

业务处理机构节点设备，被配置为：

对业务处理机构的第二用户的识别信息与所述附加码的组合进行哈希处理以得到第二哈希值，所述业务处理机构处理与由所述理赔机构理赔的对象相关联的业务；

将所述第二哈希值与所述区块链上的所述第一哈希值进行比对以确定所述第二用户是所述第一用户；以及

将与所述第二用户相关联的业务数据上传至所述区块链。

35、一种基于区块链的理赔机构节点设备，被配置为：

对理赔机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值；

将所述哈希值上传至所述区块链；以及

基于所述区块链上的业务数据进行理赔。

36、一种基于区块链的业务处理机构节点设备，被配置为：

对业务处理机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值，所述业务处理机构处理与由理赔机构理赔的对象相关联的业务；

将所述哈希值与所述区块链上的哈希值进行比对以确定所述业务处理机构的用户是所述理赔机构的用户；以及

将与所述业务处理机构的用户相关联的业务数据上传至所述区块链。

虽然已通过示例对本公开的一些特定实施例进行了详细说明，但本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。在此公开的各实施例可以任意组合，而不脱离本公开的精神和范围。本领域的技术人员还应理解，可以对实施例进行多种修改而不脱离本公开的范围和精神。本公开的范围由所附权利要求来限定。

Claims (10)

1.一种基于区块链的理赔方法，包括：

将第一哈希值上传至所述区块链，其中所述第一哈希值是通过对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理得到的；

获得第二哈希值，其中所述第二哈希值是通过对业务处理机构的第二用户的识别信息与所述附加码的组合进行哈希处理得到的，所述业务处理机构处理与由所述理赔机构理赔的对象相关联的业务；

将所述第二哈希值与所述区块链上的所述第一哈希值进行比对以确定所述第二用户是所述第一用户；

将与所述第二用户相关联的业务数据上传至所述区块链；以及

基于所述区块链上的所述业务数据进行理赔。

2.根据权利要求1所述的理赔方法，还包括将所述附加码上传至所述区块链。

3.根据权利要求2所述的理赔方法，其中，将所述附加码上传至所述区块链包括将用所述业务处理机构的公钥加密的所述附加码上传至所述区块链，其中所述业务处理机构的所述公钥被预先上传至所述区块链。

4.根据权利要求1所述的理赔方法，其中，所述附加码是第一附加码，并且其中，所述第一哈希值是通过对所述理赔机构的第一用户的识别信息、所述第一附加码以及不同于所述第一附加码的第二附加码的组合进行哈希处理得到的，所述第二哈希值是通过对所述业务处理机构的第二用户的识别信息、所述第一附加码以及所述第二附加码的组合进行哈希处理得到的。

5.根据权利要求4所述的理赔方法，还包括将所述第二附加码上传至所述区块链。

6.一种基于区块链的理赔装置，包括：

一个或多个处理器；以及

与所述一个或多个处理器耦接并且存储计算机可读指令的存储器，所述计算机可读指令在由所述一个或多个处理器执行时使得所述一个或多个处理器执行根据权利要求1至5中任一项所述的理赔方法。

7.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机可读指令，所述计算机可读指令在由处理器执行时使得所述处理器执行根据权利要求1至5中任一项所述的理赔方法。

8.一种基于区块链的理赔系统，包括：

理赔机构节点设备，被配置为：

对理赔机构的第一用户的识别信息与附加码的组合进行哈希处理以得到第一哈希值；

将所述第一哈希值上传至所述区块链；以及

基于所述区块链上的业务数据进行理赔；以及

业务处理机构节点设备，被配置为：

对业务处理机构的第二用户的识别信息与所述附加码的组合进行哈希处理以得到第二哈希值，所述业务处理机构处理与由所述理赔机构理赔的对象相关联的业务；

将所述第二哈希值与所述区块链上的所述第一哈希值进行比对以确定所述第二用户是所述第一用户；以及

将与所述第二用户相关联的业务数据上传至所述区块链。

9.一种基于区块链的理赔机构节点设备，被配置为：

对理赔机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值；

将所述哈希值上传至所述区块链；以及

基于所述区块链上的业务数据进行理赔。

10.一种基于区块链的业务处理机构节点设备，被配置为：

对业务处理机构的用户的识别信息与附加码的组合进行哈希处理以得到哈希值，所述业务处理机构处理与由理赔机构理赔的对象相关联的业务；

将所述哈希值与所述区块链上的哈希值进行比对以确定所述业务处理机构的用户是所述理赔机构的用户；以及

将与所述业务处理机构的用户相关联的业务数据上传至所述区块链。

Images