基于区块链的理赔方法及装置、电子设备

技术领域

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的理赔方法及装置、电子设备。

背景技术

理赔是保险公司执行保险合同，履行保险义务，承担保险责任的具体体现；理赔可以保证被保人的损失得到应有的补偿。然而，现如今，骗保事件屡屡发生，如何提高理赔的安全性和可靠性，避免理赔中的重复理赔事件的发生，也就成为了亟待解决的问题。

发明内容

本说明书提出一种基于区块链的理赔方法，应用于与理赔受理方对应的理赔服务端，所述区块链部署了用于对所述区块链上存储的与用户相关的电子票据进行理赔管理的智能合约；其中，所述智能合约维护了与所述电子票据对应的理赔状态；

所述方法包括：

获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态；

如果所述目标电子票据为未理赔状态，则针对所述目标电子票据进行理赔处理。

本说明书还提出一种基于区块链的理赔方法，应用于与理赔受理方对应的理赔服务端，所述区块链用于存储与用户相关的电子票据对应的理赔数据；其中，所述理赔数据包括电子票据的标识信息；

所述方法包括：

获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录；

如果所述区块链中未存储与所述目标电子票据的标识信息对应的理赔数据，则针对所述目标电子票据进行理赔处理。

本说明书还提出一种基于区块链的理赔装置，应用于与理赔受理方对应的理赔服务端，所述区块链部署了用于对所述区块链上存储的与用户相关的电子票据进行理赔管理的智能合约；其中，所述智能合约维护了与所述电子票据对应的理赔状态；

所述装置包括：

获取模块，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

查询模块，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态；

理赔模块，如果所述目标电子票据为未理赔状态，则针对所述目标电子票据进行理赔处理。

本说明书还提出一种基于区块链的理赔装置，应用于与理赔受理方对应的理赔服务端，所述区块链用于存储与用户相关的电子票据对应的理赔数据；其中，所述理赔数据包括电子票据的标识信息；

所述装置包括：

获取模块，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

查询模块，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录；

理赔模块，如果所述区块链中未存储与所述目标电子票据的标识信息对应的理赔数据，则针对所述目标电子票据进行理赔处理。

本说明书还提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现上述方法的步骤。

本说明书还提出一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现上述方法的步骤。

在上述技术方案中，可以在区块链上部署用于对该区块链上存储的与用户相关的电子票据进行理赔管理的智能合约，并由该智能合约维护与用户相关的电子票据的理赔状态；后续，可以由理赔服务端响应于理赔受理方发起的针对理赔用户提交的理赔信息中的待理赔的电子票据的标识信息的查询操作，调用该智能合约，查询该智能合约维护的该电子票据的理赔状态，并在该电子票据的理赔状态指示该电子票据为未报销状态时，针对该电子票据进行理赔处理。采用这样的方式，针对理赔用户提交的理赔信息，可以根据该理赔信息中的电子票据的标识信息，过滤掉可能已经执行过理赔的电子票据，并仅针对未报销的电子票据进行理赔处理，从而可以提高理赔的安全性和可靠性，避免理赔中的重复理赔事件的发生。

附图说明

图1是本说明书一示例性实施例示出的一种基于区块链的理赔系统的示意图；

图2是本说明书一示例性实施例示出的一种基于区块链的理赔方法的流程图；

图3是本说明书一实例性实施例示出的一种电子票据的理赔状态的流转图；

图4是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图；

图5是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图；

图6是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图；

图7是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图；

图8是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图；

图9是一示例性实施例提供的一种电子设备的结构示意图；

图10是一示例性实施例提供的一种基于区块链的理赔装置的框图；

图11是一示例性实施例提供的另一种基于区块链的理赔装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(PrivateBlockchain)和联盟链(Consortium Blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。

其中，去中心化程度最高的是公有链。加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且，各节点可自由加入或者退出网络，并进行相关操作。

私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。

联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；节点通过授权加入网络并组成利益相关联盟，共同维护区块链运行。

基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。

对于链外产生的数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备对该交易进行共识，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。

区块链上部署的智能合约，通常只能访问区块链上存储的数据内容；而在实际应用中，对于一些基于智能合约技术实现的复杂的业务场景，智能合约可能还需要访问链外的数据实体上存储的外部数据。

在这种场景下，区块链上部署的智能合约，可以通过Oracle预言机，来访问链外的数据实体上的数据，进而实现智能合约与真实世界的数据实体之间的数据交互。其中，链外的数据实体，可以包括诸如部署在链外的中心化的服务器或者数据中心，等等。

在实际应用中，在为区块链上的智能合约部署预言机时，可以先在区块链上部署一个与预言机对应的预言机智能合约；其中，该预言机智能合约用于维护预言机发给区块链上的智能合约的外部数据；例如，预言机发给区块链上的智能合约的外部数据，可以存储在预言机智能合约的账户存储空间中。

当区块链上的目标智能合约被调用时，可以从该预言机智能合约的账户存储空间中，来读取该目标智能合约所需的外部数据，来完成智能合约的调用过程。

需要说明的是，预言机在向区块链上的智能合约发送外部数据时，可以采用主动发送的方式，也可以采用被动发送的方式。

智能合约的事件机制，是智能合约与链外实体进行交互的一种方式。

对于区块链上部署的智能合约来说，通常无法直接与链外实体进行交互；例如，智能合约在调用完成后，通常无法将智能合约的调用结果，点对点的发送给智能合约的调用发起方。

智能合约在调用的过程中产生的调用结果(包括中间结果和最终的调用结果)，通常都会以事件(Event)的形式，记录到调用该智能合约的那笔交易的交易日志(transaction logs)，在节点设备的存储空间中进行存储。而需要与智能合约进行交互的链外实体，则可以通过监听节点设备的存储空间中存储的上述交易日志的方式，来获取智能合约的调用结果。

在跨链场景下，多个区块链可以通过跨链中继实现跨链对接。

其中，跨链中继，可以通过桥接接口与多个区块链分别进行对接，并基于实现的数据搬运逻辑，完成该多个区块链之间的跨链数据同步。

在实现上述跨链中继时所采用的跨链技术，在本说明书中不进行特别限定；例如，在实际应用中，可以通过侧链技术、公证人技术等跨链机制，将多个区块链连接起来。

当多个区块链通过跨链中继实现对接之后，区块链之间就可以去读取并认证其它区块链上的数据，也可以通过跨链中继去调用其它区块链上部署的智能合约。

需要说明的是，跨链中继仅用于多个区块链之间搬运数据，并不需要对搬运的数据进行持久化存储，也不需要维护所搬运的数据的数据状态。在实际应用中，跨链中继可以配置在其所连接的多个区块链之外的设备、节点或平台等处，也可以配置在其所连接的多个区块链的节点设备上，在本说明书中不进行特别限定。

请参考图1，图1是本说明书一示例性实施例示出的一种基于区块链的理赔系统的示意图。

在如图1所示的基于区块链的理赔系统中，可以包括与理赔用户对应的理赔客户端，与理赔受理方(保险公司A或者保险公司B)对应的理赔服务端，蚂蚁baas(baas，blockchain as a service)平台(也被称为baas云)，以及区块链形式的理赔链。

在示出的一种实施方式中，与理赔用户对应的理赔客户端所在的设备，可以包括各种不同类型的客户端侧终端设备；例如，客户端侧终端设备可以包括诸如PC终端设备、移动终端设备、物联网设备，以及其它形式的具有一定的计算能力的智能设备，等等。

与理赔受理方对应的理赔服务端所在的设备，可以包括用户侧服务器或者用户侧服务器集群。

具体地，该用户侧服务器或者用户侧服务器集群可以由搭建了用户账户体系的理赔受理方来实现；理赔受理方可以面向用户提供各种线上和/或线下理赔服务的服务载体；其中，该服务载体可以包括提供线上互联网服务的各种客户端软件；例如，网站、网页、APP等。

区块链形式的理赔链，可以包括用于承载该区块链的多个区块链节点；例如，如图1中示出的区块链节点1、区块链节点2、区块链节点3、区块链节点4、区块链节点i等可以共同承载该区块链。

其中，区块链节点可以包括全节点和轻节点；全节点可以全量下载区块链中的每个区块所包含的区块链交易，并可以根据搭载的区块链共识算法，对每个区块链中所包含的区块链交易进行共识验证；而轻节点可以不下载完整的区块链，而是可以只下载区块链中的每个区块的区块头数据，并将区块头所包含的数据作为验证根，用于以验证区块链交易的真实性。轻节点可以依附于全节点来访问区块链的更多功能。

区块链节点可以是物理设备，也可以是在服务器或者服务器集群中实现的虚拟设备；例如，区块链节点设备可以是服务器集群中的一台物理主机，也可以是基于虚拟化技术对服务器或者服务器集群搭载的硬件资源进行虚拟化后，创建的虚拟机。每个区块链节点之间，可以通过各种类型的通信方法(比如TCP/IP)连接在一起形成网络，来承载上述区块链。

在示出的一种实施方式中，baas平台可以通过为区块链上发生的活动(诸如订阅和通知、用户验证、数据库管理和远程更新)，提供预先编写的软件的方式，面向与baas平台连接的设备，提供简单易用，一键部署，快速验证，灵活可定制的区块链服务，进而可以加速区块链业务应用开发、测试、上线，助力各行业区块链商业应用场景的落地。

例如，在一个例子中，与baas平台可以提供诸如MQ(Message Queue，消息队列)服务之类的软件；与baas平台连接的设备，可以订阅baas平台连接的区块链中某一区块链上部署的智能合约，在触发执行后在区块链上产生的合约事件；而baas平台可以监听该智能合约在触发执行后在区块链上产生的事件，再基于MQ服务相关的软件，将该合约事件以通知消息的形式添加到消息队列中，使得订阅该消息队列的设备，能够得到与上述合约事件相关的通知。

baas平台还可以提供基于区块链技术的企业级平台服务，以帮助企业级客户构建安全且稳定的区块链环境，并轻松管理区块链的部署、操作、维护和开发。

例如，在一个例子中，baas平台可以基于云技术实现丰富的安全策略和多租户的隔离环境、基于芯片加密技术来提供高级的安全保护、基于高度可靠的数据存储，提供可以快速扩展，而不会中断的端到端的高可用性服务；

在另一个例子中，还可以提供增强的管理功能，以帮助客户构建企业级区块链网络环境；以及，还可以为标准区块链应用和数据提供本地支持，支持例如HyperledgerFabric和Enterprise Ethereum-Quorum的主流开源区块链技术，以构建开放且包容的技术生态系统。

在示出的一种实施方式中，与理赔用户对应的理赔客户端所在的电子设备，可以通过各种通信网络连接到与理赔受理方对应的理赔服务端，而与理赔受理方对应的理赔服务端，可以进一步通过各种通信网络与蚂蚁baas平台进行连接；蚂蚁baas平台可以通过各种通信网络连接到上述理赔链，或者包括该理赔链在内的多个区块链。

其中，上述通信网络可以包括有线和/或无线通信网络；例如，可以是基于运营商提供的有线接入网络或者无线接入网络(比如移动蜂窝网络)实现的局域网(Local AreaNetwork，LAN)、广域网(Wide Area Network，WAN)、因特网或其组合。

请参考图2，图2是本说明书一实例性实施例示出的一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端，例如：如图1所示的与保险公司对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤202，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

在本实施例中，上述区块链可以包括联盟链；该联盟链的联盟成员可以包括若干理赔受理方。该区块链可以作为理赔链，用于存储与理赔业务相关的数据。

为了提高与用户相关的电子票据的数据真实性和数据安全性，可以将与用户相关的电子票据存储在上述区块链上。例如，用户可以在作为受票方获得了开票方开具的某张电子票据后，主动将该电子票据发布至该区块链上进行存储；或者，开票方可以在为作为受票方的用户开具了某张电子票据后，自动将该电子票据发布至该区块链上进行存储。

在实际应用中，也可以将与用户相关的电子票据存储在与上述区块链进行跨链对接的另一个区块链；其中，与该区块链进行跨链对接的另一个区块链可以作为票据链，用于存储与用户相关的电子票据。

用户在需要申请针对上述区块链中存储的某张电子票据(称为目标电子票据)执行理赔时，可以作为理赔用户，通过与该理赔用户对应的理赔客户端向理赔受理方提交理赔信息，以使与该理赔受理方对应的理赔服务端可以获取到该理赔信息；其中，该理赔信息可以包括该目标电子票据的标识信息。

在实际应用中，上述理赔客户端可以是上述理赔受理方向理赔用户提供的理赔APP(Application，应用程序)；对于某张电子票据而言，该电子票据的标识信息可以包括该电子票据的发票号码，或者该电子票据的发票号码和发票代码，等等用于唯一标识该电子票据的信息。

以图1所示的基于区块链的理赔系统为例，保险公司A或者保险公司B可以作为理赔受理方；理赔用户可以通过与该理赔用户对应的理赔客户端，向该理赔受理方提交上述理赔信息，以申请针对上述目标电子票据执行理赔，并使与该理赔受理方对应的理赔服务端可以获取到该理赔信息。

在示出的一种实施方式中，上述理赔用户发起的理赔可以包括医疗保险理赔；上述电子票据可以包括与用户的就医记录相关的电子票据。

步骤204，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态。

在本实施例中，可以预先在上述区块链上部署用于对该区块链上存储的与用户相关的电子票据进行理赔管理的智能合约，以通过调用该智能合约实现针对与用户相关的电子票据的理赔。

为了避免出现针对同一张电子票据进行重复理赔的问题，上述智能合约还可以维护该区块链上存储的与用户相关的电子票据的理赔状态。例如，用户可以在作为受票方获得了开票方开具的某张电子票据后，通过上述区块链中的节点设备向该区块链发布合约调用交易，以由该区块链中的节点设备响应于该合约调用交易，调用该智能合约中的存证逻辑，在该智能合约的合约存储空间中维护该电子票据的理赔状态；或者，开票方可以在需要为作为受票方的用户开具某张电子票据时，通过上述区块链中的节点设备向该区块链发布合约调用交易，以由该区块链中的节点设备响应于该合约调用交易，调用该智能合约中的存证逻辑，在该智能合约的合约存储空间中维护该电子票据的理赔状态。

上述理赔受理方在上述理赔用户申请了针对上述目标电子票据执行理赔的情况下，可以通过上述理赔服务端发起针对该目标电子票据的重复理赔查询操作；此时，该理赔服务端可以响应于该重复理赔查询操作，调用上述智能合约中的查询逻辑，查询该智能合约维护的与上述理赔信息中的电子票据的标识信息对应的电子票据(即为该目标电子票据)的理赔状态。

具体地，上述理赔服务端可以响应于上述重复理赔查询操作，通过上述区块链中的节点设备向该区块链发布与上述智能合约对应的合约调用交易，该合约调用交易中包括上述理赔信息中的电子票据的标识信息(即为上述目标电子票据的标识信息)，以由该区块链中的节点设备响应于该合约调用交易，调用该智能合约中的查询逻辑，查询该智能合约维护的该目标电子票据的理赔状态。

进一步地，上述智能合约在查询到上述目标电子票据的理赔状态时，可以生成与该目标电子票据的理赔状态对应的查询事件；上述理赔服务端则可以通过对该智能合约产生的事件进行监听，获取到该查询事件，并基于该查询事件获取到该目标电子票据的理赔状态。

以图1所示的基于区块链的理赔系统为例，可以预先在区块链形式的理赔链上部署上述智能合约，并由该智能合约维护该理赔链上存储的电子票据的理赔状态；上述理赔服务端可以响应于上述理赔受理方发起的上述重复理赔查询操作，向蚂蚁baas平台发送重复理赔查询请求，以由蚂蚁baas平台响应于该重复理赔查询请求，向该理赔链发布上述合约调用交易，以由该理赔链中的节点设备(即为区块链节点)响应于该合约调用交易，调用该智能合约中的查询逻辑，查询该智能合约维护的上述目标电子票据的理赔状态；该智能合约在查询到该目标电子票据的理赔状态时，可以在该理赔链上生成上述查询事件；蚂蚁baas平台可以通过对该智能合约产生的事件进行监听，获取到该查询事件，并将该查询事件转发给该理赔服务端，以使该理赔服务端基于该查询事件获取到该目标电子票据的理赔状态。

需要说明的是，如果上述理赔服务端直接接入上述区块链，即该理赔服务端作为区块链节点直接连接到该区块链，则该理赔服务端可以响应于上述理赔受理方发起的上述重复理赔查询操作，向该理赔链发布上述合约调用交易，以由该理赔链中的节点设备响应于该合约调用交易，调用该智能合约中的查询逻辑，查询该智能合约维护的上述目标电子票据的理赔状态；该智能合约在查询到该目标电子票据的理赔状态时，可以在该理赔链上生成上述查询事件；该理赔服务端可以通过对该智能合约产生的事件进行监听，获取到该查询事件，并基于该查询事件获取到该目标电子票据的理赔状态。

在示出的一种实施方式中，为了提高针对电子票据执行理赔的可靠性，上述理赔服务端在查询上述目标电子票据的理赔状态之前，可以先调用上述智能合约中的票据核验逻辑，核验该目标电子票据是否满足预设的理赔条件，并在该目标电子票据核验通过时，再调用该智能合约中的查询逻辑，查询该智能合约维护的该目标电子票据的理赔状态。

具体地，上述理赔服务端可以通过上述区块链中的节点设备向该区块链发布与上述智能合约对应的合约调用交易，该合约调用交易中包括上述目标电子票据的标识信息，以由该区块链中的节点设备响应于该合约调用交易，先调用该智能合约中的票据核验逻辑，从该区块链上获取该目标电子票据，或者从与该区块链进行跨链连接的票据链上获取该目标电子票据，核验该目标电子票据是否满足预设的理赔条件，并在该目标电子票据核验通过时，再调用该智能合约中的查询逻辑，查询该智能合约维护的该目标电子票据的理赔状态。

需要说明的是，如果上述目标电子票据核验未通过，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

进一步地，在示出的一种实施方式中，为了避免由智能合约执行较为复杂的计算，在调用上述智能合约中的票据核验逻辑，核验上述目标电子票据是否满足预设的理赔条件时，具体可以由该智能合约通过预言机(Oracle)程序，将获取到的该目标电子票据提交至链外的第三方票据核验服务端，以由该第三方票据核验服务端核验该目标电子票据是否满足预设的理赔条件，相应地，该智能合约可以通过该预言机程序，接收该第三方票据核验服务端返回的针对该目标电子票据的票据核验结果。

在实际应用中，上述第三方票据核验服务端具体可以包括与财政局对应的服务端；上述理赔条件可以由上述理赔受理方预先设置，具体可以包括：发起针对该目标电子票据的理赔的上述理赔用户为该目标电子票据中记载的受票方；该目标电子票据的开票日期与当前日期之间的时间间隔在允许理赔的时长阈值内；等等。

在示出的另一种实施方式中，为了提高针对电子票据执行理赔的可靠性，上述理赔服务端在查询上述目标电子票据的理赔状态之前，可以先调用上述智能合约中权限校验逻辑，校验上述理赔用户是否将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，如果是，再调用该智能合约中的查询逻辑，查询该智能合约维护的该目标电子票据的理赔状态。

具体地，上述理赔服务端可以通过上述区块链中的节点设备向该区块链发布与上述智能合约对应的合约调用交易，该合约调用交易中包括上述目标电子票据的标识信息，以由该区块链中的节点设备响应于该合约调用交易，先调用上述智能合约中权限校验逻辑，校验上述理赔用户是否将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，如果是，再调用该智能合约中的查询逻辑，查询该智能合约维护的该目标电子票据的理赔状态。

需要说明的是，如果确定上述理赔用户未将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

进一步地，在示出的一种实施方式中，用户在将上述区块链上存储的电子票据的查询权限授权给上述理赔受理方时，可以将与该区块链上存储的该电子票据对应的查询权限授权信息在该区块链上进行存储；其中，该查询权限授权信息可以包括该用户的身份标识和该理赔受理方的标识信息(即为用于唯一标识该理赔受理方的信息)。

在这种情况下，在校验上述理赔用户是否将该区块链上存储的上述目标电子票据的查询权限授权给该理赔受理方时，具体可以查询该区块链上是否存储了与该区块链上存储的该目标电子票据对应的查询权限授权信息，该查询权限授权信息应当包括该理赔用户的身份标识和该理赔受理方的标识信息，如果是，则可以确定该理赔用户已经将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方。

进一步地，在示出的另一种实施方式中，可以由上述理赔受理方维护与用户将上述区块链上存储的电子票据的查询权限授权给该理赔受理方的授权行为对应的可校验凭证；其中，该可校验凭证可以作为查询权限授权凭证，用于对该理赔受理方是否被用户授予了该区块链上存储的该电子票据的查询权限进行校验。

在这种情况下，该理赔受理方提交的针对上述智能合约的调用参数可以包括查询权限授权凭证，该查询权限授权凭证应当包括与上述理赔用户将该区块链上存储的上述目标电子票据的查询权限授权给该理赔受理方的授权行为对应的可校验凭证；在校验该理赔用户是否将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方时，具体可以针对该可校验凭证进行校验，如果校验通过，则可以确定该理赔用户已经将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方。

在实际应用中，上述可校验凭证可以是基于上述理赔用户的密钥进行hash计算得到的hash值；在这种情况下，上述智能合约中可以维护该理赔用户的密钥，并在校验该理赔用户是否将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方时，先基于维护的该理赔用户的密钥进行hash计算，再比较计算得到的hash值与该可校验凭证中的hash值是否一致，如果是，则确定该可校验凭证校验通过。

在示出的一种实施方式中，上述理赔服务端在完成针对上述目标电子票据的理赔状态的查询时，可以进一步调用上述智能合约中的计费逻辑，生成与本次查询对应的计费金额，以使上述理赔受理方基于该计费金额向上述区块链的运营方支付对应的查询费用。

或者，上述智能合约在生成了与本次查询对应的计费金额后，可以进一步生成与该计费金额对应的计费事件；第三方支付系统则可以通过对该智能合约产生的事件进行监听，获取到该计费事件，并响应于该计费事件，代替上述理赔受理方向上述区块链的运营方支付对应的查询费用。

步骤206，如果所述目标电子票据为未理赔状态，则针对所述目标电子票据进行理赔处理。

在本实施例中，上述理赔服务端在获取到上述目标电子票据的理赔状态的情况下，如果确定该目标电子票据的理赔状态指示该目标电子票据处于未理赔状态，则说明此前尚未针对该目标电子票据执行过理赔，因此，可以针对该目标电子票据进行理赔处理。

相应地，上述理赔服务端如果确定上述目标电子票据的理赔状态指示该目标电子票据不处于未理赔状态，则说明此前可能已经针对该目标电子票据执行了理赔，因此，为了避免重复理赔，可以不再针对该目标电子票据进行理赔处理。

在示出的一种实施方式中，为了对电子票据的理赔状态进行进一步区别，以便于对电子票据进行理赔管理，除了可以将电子票据设置为未理赔状态之外，还可以将电子票据设置为正在理赔状态和已完成理赔状态。也即，电子票据的理赔状态可以包括未理赔状态、正在理赔状态、已完成理赔状态。

请参考图3，图3是本说明书一实例性实施例示出的一种电子票据的理赔状态的流转图。

如图3所示，在将开票方为作为受票方的用户开具的某张电子票据发布至上述区块链上进行存储时，该电子票据的理赔状态为未理赔状态，即可以将该电子票据的初始的理赔状态设置为未理赔状态。在针对该电子票据进行理赔处理的过程中，该电子票据的理赔状态为正在理赔状态，即可以将该电子票据的理赔状态由未理赔状态更新为正在理赔状态。在完成了针对该电子票据的理赔处理后，该电子票据的理赔状态为已完成理赔状态，即可以将该电子票据的理赔状态由正在理赔状态更新为已完成理赔状态。

在这种情况下，上述理赔服务端如果确定上述目标电子票据的理赔状态指示该目标电子票据处于已完成理赔状态或者正在理赔状态，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

进一步地，在示出的一种实施方式中，上述理赔服务端在确定了上述目标电子票据为未报销状态的情况下，可以先调用上述智能合约中的状态维护逻辑，将该目标电子票据切换为正在理赔状态，并在将该目标电子票据切换为正在理赔状态后，再针对该目标电子票据进行理赔处理。

在示出的一种实施方式中，上述理赔服务端在针对上述目标电子票据进行理赔处理时，具体可以调用上述智能合约中的理赔逻辑，计算该目标电子票据对应的理赔金额，以使上述理赔受理方基于该理赔金额向上述理赔用户支付理赔资金。

或者，上述智能合约在计算得到上述目标电子票据对应的理赔金额后，可以生成与该理赔金额对应的理赔事件；第三方支付系统则可以通过对该智能合约产生的事件进行监听，获取到该理赔事件，并响应于该理赔事件，代替上述理赔受理方向上述理赔用户支付理赔资金。

在示出的一种实施方式中，上述理赔服务端在完成了针对上述目标电子票据的理赔处理时，可以调用上述智能合约中的存证逻辑，将与该目标电子票据对应的理赔记录发布至上述区块链进行存证，并在存证完成后进一步调用该智能合约中的状态维护逻辑，将该目标电子票据切换为已完成理赔状态。

在上述技术方案中，可以在区块链上部署用于对该区块链上存储的与用户相关的电子票据进行理赔管理的智能合约，并由该智能合约维护与用户相关的电子票据的理赔状态；后续，可以由理赔服务端响应于理赔受理方发起的针对理赔用户提交的理赔信息中的待理赔的电子票据的标识信息的查询操作，调用该智能合约，查询该智能合约维护的该电子票据的理赔状态，并在该电子票据的理赔状态指示该电子票据为未报销状态时，针对该电子票据进行理赔处理。采用这样的方式，针对理赔用户提交的理赔信息，可以根据该理赔信息中的电子票据的标识信息，过滤掉可能已经执行过理赔的电子票据，并仅针对未报销的电子票据进行理赔处理，从而可以提高理赔的安全性和可靠性，避免理赔中的重复理赔事件的发生。

请参考图4，图4是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤402，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

步骤404，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的票据核验逻辑，核验所述目标电子票据是否满足理赔条件。

步骤406，如果所述目标电子票据核验通过，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态。

步骤408，如果所述目标电子票据为未理赔状态，则调用所述智能合约中的状态维护逻辑，将所述目标电子票据切换为正在理赔状态，并在将所述目标电子票据切换为正在理赔状态后，进一步针对所述目标电子票据进行理赔处理。

步骤410，在完成针对所述目标电子票据的理赔处理时，调用所述智能合约中的存证逻辑，将与所述目标电子票据对应的理赔记录发布至所述区块链进行存证，并在存证完成后进一步调用所述智能合约中的状态维护逻辑，将所述目标电子票据切换为已完成理赔状态。

步骤412，如果所述目标电子票据核验未通过，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

步骤414，如果所述目标电子票据的理赔状态指示所述目标电子票据为已完成理赔状态或者正在理赔状态，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

上述步骤402至414的具体实施方式可以参考如图2所示的实施例，本说明书在此不再赘述。

请参考图5，图5是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤502，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

步骤504，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的权限校验逻辑，校验所述理赔用户是否将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方。

步骤506，如果所述理赔用户已经将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态。

步骤508，如果所述目标电子票据为未理赔状态，则调用所述智能合约中的状态维护逻辑，将所述目标电子票据切换为正在理赔状态，并在将所述目标电子票据切换为正在理赔状态后，进一步针对所述目标电子票据进行理赔处理。

步骤510，在完成针对所述目标电子票据的理赔处理时，调用所述智能合约中的存证逻辑，将与所述目标电子票据对应的理赔记录发布至所述区块链进行存证，并在存证完成后进一步调用所述智能合约中的状态维护逻辑，将所述目标电子票据切换为已完成理赔状态。

步骤512，如果所述理赔用户未将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

步骤514，如果所述目标电子票据的理赔状态指示所述目标电子票据为已完成理赔状态或者正在理赔状态，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

上述步骤502至514的具体实施方式可以参考如图2所示的实施例，本说明书在此不再赘述。

请参考图6，图6是本说明书一实例性实施例示出的另一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端，例如：如图1所示的与保险公司对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤602，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

在本实施例中，上述区块链可以包括联盟链；该联盟链的联盟成员可以包括若干理赔受理方。

为了提高与用户相关的电子票据的数据真实性和数据安全性，可以将与用户相关的电子票据存储在上述区块链上。例如，用户可以在作为受票方获得了开票方开具的某张电子票据后，主动将该电子票据发布至该区块链上进行存储；或者，开票方可以在为作为受票方的用户开具了某张电子票据后，自动将该电子票据发布至该区块链上进行存储。

在实际应用中，也可以将与用户相关的电子票据存储在与上述区块链进行跨链对接的另一个区块链；其中，与该区块链进行跨链对接的另一个区块链可以作为票据链，用于存储与用户相关的电子票据。

用户在需要申请针对上述区块链中存储的某张电子票据(称为目标电子票据)执行理赔时，可以作为理赔用户，通过与该理赔用户对应的理赔客户端向理赔受理方提交理赔信息，以使与该理赔受理方对应的理赔服务端可以获取到该理赔信息；其中，该理赔信息可以包括该目标电子票据的标识信息。

在实际应用中，上述理赔客户端可以是上述理赔受理方向理赔用户提供的理赔APP(Application，应用程序)；对于某张电子票据而言，该电子票据的标识信息可以包括该电子票据的发票号码，或者该电子票据的发票号码和发票代码，等等用于唯一标识该电子票据的信息。

以图1所示的基于区块链的理赔系统为例，保险公司A或者保险公司B可以作为理赔受理方；理赔用户可以通过与该理赔用户对应的理赔客户端，向该理赔受理方提交上述理赔信息，以申请针对上述目标电子票据执行理赔，并使与该理赔受理方对应的理赔服务端可以获取到该理赔信息。

在示出的一种实施方式中，上述理赔用户发起的理赔可以包括医疗保险理赔；上述电子票据可以包括与用户的就医记录相关的电子票据。

步骤604，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录。

在本实施例中，为了避免出现针对同一张电子票据进行重复理赔的问题，上述理赔受理方在上述理赔用户申请了针对上述目标电子票据执行理赔的情况下，可以通过上述理赔服务端发起针对该目标电子票据的重复理赔查询操作；此时，该理赔服务端可以响应于该重复理赔查询操作，查询上述区块链中是否存储了与上述理赔信息中的电子票据的标识信息(即为该目标电子票据的标识信息)对应的理赔记录。

以图1所示的基于区块链的理赔系统为例，上述理赔服务端可以响应于上述理赔受理方发起的上述重复理赔查询操作，向蚂蚁baas平台发送重复理赔查询请求，以由蚂蚁baas平台响应于该重复理赔查询请求，查询上述区块链中是否存储了与上述目标电子票据的标识信息对应的理赔记录；蚂蚁baas平台可以将对应的查询结果发送给该理赔服务端，以使该理赔服务端基于该查询结果确定该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

需要说明的是，如果上述理赔服务端直接接入上述区块链，即该理赔服务端作为区块链节点直接连接到该区块链，则该理赔服务端可以响应于上述理赔受理方发起的上述重复理赔查询操作，查询该区块链中是否存储了与上述目标电子票据的标识信息对应的理赔记录，并基于对应的查询结果确定该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

在示出的一种实施方式中，可以预先在上述区块链上部署用于对该区块链上存储的与用户相关的电子票据进行理赔管理的智能合约，以通过调用该智能合约实现针对与用户相关的电子票据的理赔。

为了提高针对电子票据执行理赔的可靠性，上述理赔服务端在查询上述区块链中是否存储了与上述目标电子票据的标识信息对应的理赔记录之前，可以先调用上述智能合约中的票据核验逻辑，核验该目标电子票据是否满足预设的理赔条件，并在该目标电子票据核验通过时，再查询该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

具体地，上述理赔服务端可以通过上述区块链中的节点设备向该区块链发布与上述智能合约对应的合约调用交易，该合约调用交易中包括上述目标电子票据的标识信息，以由该区块链中的节点设备响应于该合约调用交易，先调用该智能合约中的票据核验逻辑，从该区块链上获取该目标电子票据，或者从与该区块链进行跨链连接的票据链上获取该目标电子票据，核验该目标电子票据是否满足预设的理赔条件，并在该目标电子票据核验通过时，再查询该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

需要说明的是，如果上述目标电子票据核验未通过，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

进一步地，在示出的一种实施方式中，为了避免由智能合约执行较为复杂的计算，在调用上述智能合约中的票据核验逻辑，核验上述目标电子票据是否满足预设的理赔条件时，具体可以由该智能合约通过预言机(Oracle)程序，将获取到的该目标电子票据提交至链外的第三方票据核验服务端，以由该第三方票据核验服务端核验该目标电子票据是否满足预设的理赔条件，相应地，该智能合约可以通过该预言机程序，接收该第三方票据核验服务端返回的针对该目标电子票据的票据核验结果。

在实际应用中，上述第三方票据核验服务端具体可以包括与财政局对应的服务端；上述理赔条件可以由上述理赔受理方预先设置，具体可以包括：发起针对该目标电子票据的理赔的上述理赔用户为该目标电子票据中记载的受票方；该目标电子票据的开票日期与当前日期之间的时间间隔在允许理赔的时长阈值内；等等。

在示出的另一种实施方式中，为了提高针对电子票据执行理赔的可靠性，上述理赔服务端在查询上述区块链中是否存储了与上述目标电子票据的标识信息对应的理赔记录之前，可以先调用上述智能合约中权限校验逻辑，校验上述理赔用户是否将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，如果是，再查询该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

具体地，上述理赔服务端可以通过上述区块链中的节点设备向该区块链发布与上述智能合约对应的合约调用交易，该合约调用交易中包括上述目标电子票据的标识信息，以由该区块链中的节点设备响应于该合约调用交易，先调用上述智能合约中权限校验逻辑，校验上述理赔用户是否将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，如果是，再查询该区块链中是否存储了与该目标电子票据的标识信息对应的理赔记录。

需要说明的是，如果确定上述理赔用户未将上述区块链上存储的该目标电子票据的查询权限授权给上述理赔受理方，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

进一步地，在示出的一种实施方式中，用户在将上述区块链上存储的电子票据的查询权限授权给上述理赔受理方时，可以将与该区块链上存储的该电子票据对应的查询权限授权信息在该区块链上进行存储；其中，该查询权限授权信息可以包括该用户的身份标识和该理赔受理方的标识信息(即为用于唯一标识该理赔受理方的信息)。

在这种情况下，在校验上述理赔用户是否将该区块链上存储的上述目标电子票据的查询权限授权给该理赔受理方时，具体可以查询该区块链上是否存储了与该区块链上存储的该目标电子票据对应的查询权限授权信息，该查询权限授权信息应当包括该理赔用户的身份标识和该理赔受理方的标识信息，如果是，则可以确定该理赔用户已经将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方。

进一步地，在示出的另一种实施方式中，可以由上述理赔受理方维护与用户将上述区块链上存储的电子票据的查询权限授权给该理赔受理方的授权行为对应的可校验凭证；其中，该可校验凭证可以作为查询权限授权凭证，用于对该理赔受理方是否被用户授予了该区块链上存储的该电子票据的查询权限进行校验。

在这种情况下，该理赔受理方提交的针对上述智能合约的调用参数可以包括查询权限授权凭证，该查询权限授权凭证应当包括与上述理赔用户将该区块链上存储的上述目标电子票据的查询权限授权给该理赔受理方的授权行为对应的可校验凭证；在校验该理赔用户是否将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方时，具体可以针对该可校验凭证进行校验，如果校验通过，则可以确定该理赔用户已经将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方。

在实际应用中，上述可校验凭证可以是基于上述理赔用户的密钥进行hash计算得到的hash值；在这种情况下，上述智能合约中可以维护该理赔用户的密钥，并在校验该理赔用户是否将该区块链上存储的该目标电子票据的查询权限授权给该理赔受理方时，先基于维护的该理赔用户的密钥进行hash计算，再比较计算得到的hash值与该可校验凭证中的hash值是否一致，如果是，则确定该可校验凭证校验通过。

步骤606，如果所述目标电子票据为未理赔状态，则针对所述目标电子票据进行理赔处理。

在本实施例中，如果确定上述区块链中未存储与上述目标电子票据的标识信息对应的理赔数据，则说明此前尚未针对该目标电子票据执行过理赔，因此，上述理赔服务端可以针对该目标电子票据进行理赔处理。

相应地，如果确定上述区块链中已经存储了与上述目标电子票据的标识信息对应的理赔数据，则说明此前可能已经针对该目标电子票据执行了理赔，因此，为了避免重复理赔，可以不再针对该目标电子票据进行理赔处理。

在示出的一种实施方式中，上述理赔服务端如果确定上述区块链中已经存储了与上述目标电子票据的标识信息对应的理赔数据，则一方面，可以不再针对该目标电子票据进行理赔处理，另一方面，可以向上述理赔客户端返回该目标电子票据无法进行理赔处理的提示信息，以提示上述理赔用户无法针对该目标电子票据执行理赔。

在示出的一种实施方式中，可以预先在上述区块链上部署用于对该区块链上存储的与用户相关的电子票据进行理赔管理的智能合约，以通过调用该智能合约实现针对与用户相关的电子票据的理赔。

上述理赔服务端在针对上述目标电子票据进行理赔处理时，具体可以调用上述智能合约中的理赔逻辑，计算该目标电子票据对应的理赔金额，以使上述理赔受理方基于该理赔金额向上述理赔用户支付理赔资金。

或者，上述智能合约在计算得到上述目标电子票据对应的理赔金额后，可以生成与该理赔金额对应的理赔事件；第三方支付系统则可以通过对该智能合约产生的事件进行监听，获取到该理赔事件，并响应于该理赔事件，代替上述理赔受理方向上述理赔用户支付理赔资金。

在示出的一种实施方式中，上述理赔服务端在完成了针对上述目标电子票据的理赔处理时，可以将与该目标电子票据对应的理赔记录发布至上述区块链进行存证。

在上述技术方案中，可以由理赔服务端响应于理赔受理方发起的针对理赔用户提交的理赔信息中的待理赔的电子票据的标识信息的查询操作，查询区块链上是否存储了与该电子票据对应的理赔记录，并在该区块链上未存储与该电子票据对应的理赔记录时，针对该电子票据进行理赔处理。采用这样的方式，针对理赔用户提交的理赔信息，可以根据该理赔信息中的电子票据的标识信息，过滤掉可能已经执行过理赔的电子票据，并仅针对未报销的电子票据进行理赔处理，从而可以提高理赔的安全性和可靠性，避免理赔中的重复理赔事件的发生。

请参考图7，图7是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤702，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

步骤704，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的票据核验逻辑，核验所述目标电子票据是否满足预设的理赔条件。

步骤706，如果所述目标电子票据核验通过，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录。

步骤708，如果所述区块链中未存储与所述目标电子票据的标识信息对应的理赔数据，则针对所述目标电子票据进行理赔处理。

步骤710，在完成针对所述目标电子票据的理赔处理时，将与所述目标电子票据对应的理赔记录发布至所述区块链进行存证。

步骤712，如果所述目标电子票据核验未通过，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

步骤714，如果所述区块链中已经存储了与所述目标电子票据的标识信息对应的理赔数据，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

上述步骤702至714的具体实施方式可以参考如图6所示的实施例，本说明书在此不再赘述。

请参考图8，图8是本说明书一示例性实施例示出的另一种基于区块链的理赔方法的流程图。

上述基于区块链的理赔方法可以应用于与理赔受理方对应的理赔服务端；该基于区块链的理赔方法可以包括以下步骤：

步骤802，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息。

步骤804，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的权限校验逻辑，校验所述理赔用户是否将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方。

步骤806，如果所述理赔用户已经将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录。

步骤808，如果所述区块链中未存储与所述目标电子票据的标识信息对应的理赔数据，则针对所述目标电子票据进行理赔处理。

步骤810，在完成针对所述目标电子票据的理赔处理时，将与所述目标电子票据对应的理赔记录发布至所述区块链进行存证。

步骤812，如果所述理赔用户未将所述区块链上存储的所述目标电子凭证的查询权限授权给所述理赔受理方，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

步骤814，如果所述区块链中已经存储了与所述目标电子票据的标识信息对应的理赔数据，则向所述理赔客户端返回所述目标电子票据无法进行理赔处理的提示信息。

上述步骤802至814的具体实施方式可以参考如图6所示的实施例，本说明书在此不再赘述。

与前述基于区块链的理赔方法的实施例相对应，本说明书还提供了基于区块链的理赔装置的实施例。

本说明书基于区块链的理赔装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图9所示，为本说明书基于区块链的理赔装置所在电子设备的一种硬件结构图，除了图9所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该基于区块链的理赔的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图10，图10是本说明书一示例性实施例示出的一种基于区块链的理赔装置的框图。该基于区块链的理赔装置100可以应用于如图9所示的电子设备，该电子设备可以作为与理赔受理方对应的理赔服务端，所述区块链部署了用于对所述区块链上存储的与用户相关的电子票据进行理赔管理的智能合约；其中，所述智能合约维护了与所述电子票据对应的理赔状态；该基于区块链的理赔装置100可以包括：

获取模块1001，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

查询模块1002，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，调用所述智能合约中的查询逻辑，查询所述智能合约维护的与所述标识信息对应的目标电子票据的理赔状态；

理赔模块1003，如果所述目标电子票据为未理赔状态，则针对所述目标电子票据进行理赔处理。

请参考图11，图11是本说明书一示例性实施例示出的另一种基于区块链的理赔装置的框图。该基于区块链的理赔装置110可以应用于如图9所示的电子设备，该电子设备可以作为与理赔受理方对应的理赔服务端，所述区块链用于存储与用户相关的电子票据对应的理赔数据；其中，所述理赔数据包括电子票据的标识信息；该基于区块链的理赔装置110可以包括：

获取模块1101，获取理赔用户通过理赔客户端提交的理赔信息；其中，所述理赔信息包括待理赔的目标电子票据的标识信息；

查询模块1102，响应于理赔受理方发起的针对所述目标电子票据的重复理赔查询操作，查询所述区块链中是否存储了与所述目标电子票据的标识信息对应的理赔记录；

理赔模块1103，如果所述区块链中未存储与所述目标电子票据的标识信息对应的理赔数据，则针对所述目标电子票据进行理赔处理。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。