CN109087697A - 一种献血监管方法、服务器及计算机可读介质 - Google Patents

Abstract

本申请实施例公开了一种献血监管方法、服务器及计算机可读介质，其中方法包括：接收来自献血机构发送的献血者信息；在对所述献血者信息验证通过后，将所述献血者信息登记在区块链中进行全网广播；接收对所述献血者信息的调用请求，根据所述调用请求对所述献血者信息进行调用。通过本申请实施例，可以通过区块链去中心化和不可更改的加密属性来记录公民的献血信息，全国可联网在线上查询献血记录以及反馈信息，减少急需用血时验证的冗余流程。

Description

一种献血监管方法、服务器及计算机可读介质

技术领域

本申请涉及献血监管技术领域，尤其涉及一种献血监管方法、服务器及计算机可读介质。

背景技术

无偿献血就是健康适龄公民自觉自愿献出可以再生的适量血液或血液成分，去挽救危重病人的生命，而献血者不索取任何报酬的行为。长期以来，无偿献血证一直采用传统的方式，即献血者献血成功时，发给献血者一个纸质无偿献血证，该证用于记录献血者的献血记录。献血者在献血之后，若因某种原因，献血者需要用血时，献血者可以凭借献血证无偿用血。

由于献血证丢失或破损的几率很高，且补办献血证的程序也比较繁琐复杂。例如献血者需要用血，但是献血证丢失，此时献血者就需要补办献血证来无偿用血。这给过程繁琐，且会耽误献血者很多时间。因此，当献血者的献血证丢失或破损后，需要使用献血证作为证明的时候，是一个非常麻烦的问题。

发明内容

本申请实施例提供一种献血监管方法，可节省献血证书的成本，全国联网线上查询献血记录以及反馈信息，各大用血单位可通过查询认证个人献血记录，及时用血减少冗余流程。

第一方面，本申请实施例提供了一种献血监管方法，该方法包括：

接收来自献血机构发送的献血者信息；

在对所述献血者信息验证通过后，将所述献血者信息登记在区块链中进行全网广播；

接收对所述献血者信息的调用请求，根据所述调用请求对所述献血者信息进行调用。

可选的，所述对所述献血者信息验证包括：

根据所述献血者信息生成验证请求；

向所述献血者发送所述验证请求；

接收来自所述献血者对所述验证请求的确认信息。

可选的，所述方法还包括：

接收来自所述献血者发送的人员关系图表信息；

在对所述人员关系图表信息验证通过后，将所述人员图表关系信息和所述献血者信息关联，并登记在区块链中进行全网广播。

可选的，所述对所述献血者信息的调用请求包括查询请求，所述查询请求中包括查询者的身份信息和所述献血者的身份信息；

所述根据所述调用请求对所述献血者信息进行调用包括：

根据所述查询者的身份信息和所述献血者的身份信息对所述查询者进行权限验证；

若验证通过，则向所述查询者发送所述献血者信息。

可选的，所述对所述献血者信息的调用请求包括用血请求，所述用血请求中包括用血者的身份信息和献血者的身份信息；

所述根据所述调用请求对所述献血者信息进行调用包括：

根据所述用血请求中的用血者的身份信息确定所述用血者为所述献血者；

根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的可用血量信息；

或者，

根据所述用血请求中的用血者的身份信息和所述人员关系图标确定所述用血者为所述献血者的亲属；

根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的亲属的可用血量信息。

第二方面，本申请实施例提供了一种服务器，该服务器包括：

接收单元，用于接收来自献血机构发送的献血者信息；

验证单元，用于对所述献血者信息进行验证；

登记单元，用于在对所述献血者信息验证通过后，将所述献血者信息登记在区块链中进行全网广播；

调用单元，用于接收对所述献血者信息的调用请求，根据所述调用请求对所述献血者信息进行调用。

可选的，所述验证单元包括：

生成单元，用于根据所述献血者信息生成验证请求；

第二发送单元，用于向所述献血者发送所述验证请求；

所述接收单元，用于接收来自所述献血者对所述验证请求的确认信息。

可选的，所述接收单元，用于接收来自所述献血者发送的人员关系图表信息；

所述验证单元，用于对所述人员关系图表信息进行验证；

所述服务器还包括：

关联单元，用于在对所述人员关系图表信息验证通过后，将所述人员图表关系信息和所述献血者信息关联；

所述登记单元，用于将关联后的所述人员图表关系信息和所述献血者信息登记在区块链中进行全网广播。

可选的，所述对所述献血者信息的调用请求包括查询请求，所述查询请求中包括查询者的身份信息和所述献血者的身份信息；

所述调用单元包括：

权限验证单元，用于根据所述查询者的身份信息和所述献血者的身份信息对所述查询者进行权限验证；

第一发送单元，用于若对所述查询者的权限验证通过，则向所述查询者发送所述献血者信息。

可选的，所述对所述献血者信息的调用请求包括用血请求，所述用血请求中包括用血者的身份信息和献血者的身份信息；

所述调用单元包括：

确定单元，用于根据所述用血请求中的用血者的身份信息确定所述用血者为所述献血者；

所述第一发送单元，用于根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的可用血量信息；

或者，

所述确定单元，用于根据所述用血请求中的用血者的身份信息和所述人员关系图标确定所述用血者为所述献血者的亲属；

所述第一发送单元，用于根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的亲属的可用血量信息。

第三方面，本申请实施例提供了另一服务器，包括处理器、存储器和通信模块，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码来执行上述第一方面及其任一种可选方式的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行上述第一方面及其任一种可选方式的方法。

可以看出，本申请实施例中通过创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链。然后通过献血机构采集献血者信息并上传献血机构服务器。献血机构服务器对献血者信息验证后，将其登记在区块链中进行全网广播。当需要调用上述献血者信息时，可以向上述献血机构服务器发送相应的调用请求来调用献血者信息，并根据调用请求作相应的其他操作。通过本申请实施例，可以通过区块链去中心化和不可更改的加密属性来记录公民的献血信息，全国可联网在线上查询献血记录以及反馈信息，减少急需用血时验证的冗余流程。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种献血监管方法的示意流程图；

图2是本申请实施例提供的另一种献血监管方法的示意流程图；

图3是本申请实施例提供的又一种献血监管方法的示意流程图；

图4是本申请实施例提供的一种服务器的示意框图；

图5是本申请实施例提供的一种设备；

图6是本申请实施例提供的一种服务器结构示意图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

现有的技术中，并没有全国联网可查的献血反馈系统，都是基于线下拿到的献血证书。然而献血证书丢失或破损的几率很高，补办献血证又比较繁琐和复杂。这对以后献血者需要使用献血证时造成了不便的影响。

使用区块链的去中心化和不可篡改的技术，可以通过相关的采血部门线上输入采集献血人员的献血信息记录。可在线上确认献血人员的反馈信息，然后将献血人员的献血记录信息登记在区块链中并进行全网广播。之后可通过身份证等有效信息查询；如果遇到紧急问题直系亲属或本人用血可直接通过线上查询认证，节约了部分时间及繁琐的流程；技术成熟之后可取消献血证书的书本证明。

区块链是一种按照时间顺序将数据区块相连的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。

区块链的特性有开放、共识、去中心、去信任、透明、双方匿名、不可篡改以及可追溯等。其中，开放与透明意为任何人都可以参与到区块链网络，每一台设备都能作为一个节点，每个节点都允许获得一份完整的数据库拷贝。节点基于一套共识机制，通过竞争计算共同维护整个区块链。任一节点失效，其余节点仍能正常工作。其中，去中心化与去信任意为区块链由众多节点共同组成一个端到端的网络，不存在中心化的设备和管理机构。节点之间数据交换通过数字签名技术进行验证，无需互相信任，只要按照系统既定的规则进行，节点之间不能也无法欺骗其他节点。其中，透明与双方匿名意为区块链的运行规则是公开的，所有的数据信息也是公开的，因此每一笔交易都对所有节点可见。由于节点与节点之间是去信任的，因此节点之间无需公开身份，每个参与的节点都是匿名的。其中，不可篡改和可追溯意为每个甚至多个节点对数据库的修改无法影响其他节点的数据库，除非能控制整个网络中超过51％的节点同时修改，这是几乎不可能发生的。区块链中的，每一笔交易都通过密码学方法与相邻两个区块串联，因此可以追溯到任何一笔交易记录。

具体的，区块链可以利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。因此，区块链技术不可篡改的特性从根本上改变了中心化的信用创建方式，有效提高了数据的不可更改性以及安全性。其中，由于智能合约使得所有的条款编写为程序，这些条款可在区块链上自动执行，保证了当存在触发智能合约的条件时，区块链能强制根据智能合约中的内容执行，且不受任何外力阻挡，从而保证了合约的有效性和执行力，不仅能够大大降低成本，也能提高效率。区块链上的各个节点都有相同的账本，能够确保账本记录过程是公开透明的。区块链技术可以实现了一种点对点的、公开透明的直接交互，使得高效率、大规模、无中心化代理的信息交互方式成为了现实。

本申请实施例主要应用于区块链节点服务器，而作为区块链节点服务器的类型有很多，可以是传统服务器、大型存储系统、台式电脑、笔记本电脑、平板电脑、掌上电脑、智能手机、便携式数字播放器、智能手表以及智能手环等等。其中，区块链节点服务器为根据共识机制确定的区块链网络中的其中一个服务器。应理解，由于区块链是一个去中心化的分布式数据库，所以每次处理数据都需要选出区块链网络中的其中一个服务器作为执行者来处理数据。而每次选取服务器的规则便是共识机制，本申请实施例中共识机制可以是工作量证明机制(Proof of Work，POW)、股权证明机制(Proof of Stake，POS)、瑞波共识机制(Ripple Consensus)以及授权股权证明机制(Delegated Proof of Stake，DPOS)等，在此不作限定。本申请实施例中，终端包括但不限于带通讯功能的设备、智能手机、平板电脑、笔记本电脑、台式电脑、便携式数字播放器、智能手环以及智能手表等。

现有的技术中，并没有全国联网可查的献血反馈系统，都是基于线下拿到的献血证书。然而献血证书丢失或破损的几率很高，补办献血证又比较繁琐和复杂。这对以后献血者需要使用献血证时造成了不便的影响。

使用区块链的去中心化和不可篡改的技术，可以通过相关的采血部门线上输入采集献血人员的献血信息记录。可在线上确认献血人员的反馈信息，然后将献血人员的献血记录信息登记在区块链中并进行全网广播。之后可通过身份证等有效信息查询；如果遇到紧急问题直系亲属或本人用血可直接通过线上查询认证，节约了部分时间及繁琐的流程；技术成熟之后可取消献血证书的书本证明。

为了能够更好地理解本申请实施例，下面将对应用本申请实施例的方法进行介绍。

参见图1，图1是本申请实施例提供的一种献血监管方法的示意流程图，如图1所示该方法可包括：

101：接收来自献血机构发送的献血者信息。

其中，上述献血者信息可以包括献血者的个人信息、献血者的献血信息以及献血者的健康状况信息。献血者的个人信息包括姓名、年龄、血型、民族、国籍、身份证号码、婚姻状况、住址、手机号码、户籍等；献血者的献血信息包括献血次数、每次献血的时间、每次献血的站点、每次献血的献血量(包括全血和成分血)、每次献血的采血单位等；献血者的健康状况信息包括身高、体重、血压、心率、心肺情况、转氨酶、乙肝、血色素等信息。

在本申请实施例中，首先需要创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链，即让全国的各个献血机构以及用血单位的服务器或终端成为该区块链的节点。可以理解的是献血者也可以通过自己的终端设备(例如手机)上链加入上述献血监管查询系统作为区块链的一个节点，以便献血者通过自己的终端设备来查询自己的献血记录。

具体的，采血部门在献血者献血时记录上述献血者信息，并将上述献血者信息上传至相应的献血机构进行验证。献血机构对上述献血者信息的验证通过后，将上述献血者信息按照区块链的规则进行统一打包上传至献血机构的服务器进行验证。当上述献血机构的服务器接收到上述献血者信息后，对其进行验证，若验证通过这执行步骤102。可以理解的是上述献血机构的服务器为区块链中的一个节点服务器。

其中，献血机构对上述献血者信息的验证通过后，对上述献血者信息进行电子签名，然后将电子签名信息和上述献血者信息一起上传至献血机构的服务器进行验证。当上述献血机构的服务器接收到上述献血者信息和上述献血机构的电子签名信息后，则继续执行步骤102。

102：在对上述献血者信息验证通过后，将上述献血者信息登记在区块链中进行全网广播。

在本申请实施例中，在上述献血机构服务器接收到上述献血者信息后，对其进行验证。验证通过后，上述献血机构的服务器将上述献血者信息登记在区块链中进行全网广播。

具体的，当上述献血机构的服务器接收到上述献血者信息和上述献血机构的电子签名信息后，对上述电子签名信息和上述献血者信息进行验证，以便确认上述献血者信息是否为上述献血机构所发送的，以及验证上述献血者信息的真伪。当验证通过后，则将上述献血者信息登记到一个区块中并进行全网广播，当经过共识机制后将该区块作为一个新的区块添加到区块链中。可以理解的是上述区块中可以包括至少一个献血者的献血者信息。

作为一种可选的实方式，上述献血机构对上述献血者信息进行验证可以具体包括：根据上述献血者信息生成验证请求；向上述献血者发送上述验证请求；接收来自上述献血者对上述验证请求的确认信息。

具体的，在上述献血机构服务器接收到上述献血者信息，并对其验证通过后，将上述献血者信息按照预设规则进行打包生成验证请求，该验证请求用于向上述献血者进一步确认该献血者信息的真实性；然后将该验证请求发送给上述献血者进行确认。上述献血者确认过上述献血者信息之后，向上述献血机构服务器发送确认信息。当上述献血机构服务器接收到上述献血者发送的确认信息后，则确定对上述献血者信息的验证通过。

103：接收对上述献血者信息的调用请求，根据上述调用请求对上述献血者信息进行调用。

其中，上述对献血者信息的调用请求可以包括查询请求或用血请求。

在本申请实施例中，在上述献血机构服务器将上述献血信息登记到区块链中之后。上述献血机构服务器还可接收来自献血者、用血单位或其他机构对上述献血中者信息的调用指令，然后上述献血机构服务器根据接收到的各种调用指令对上述献血者信息做相应的操作。

作为一种可选的实施方式，上述对上述献血者信息的调用请求可以是对上述献血者信息的查询请求。

具体的，上述对献血者信息的查询请求中包括查询者的身份信息和上述献血者的身份信息。当上述献血机构服务器接收到对上述献血信息的查询请求后，按照预定规则解析上述查询请求得到上述查询者的身份信息和上述献血者的身份信息，然后根据上述查询者的身份信息和献血者的身份信息判断上述查询者是否有对上述献血者信息的查询权限。若上述查询者有查询权限，则根据上述查询请求中的献血者身份信息从区块链中获取和该献血者身份信息相对应的献血者信息。然后，将获取到的献血者身份信息打包发送给上述查询者。若上述查询者没有查询权限，则向上述查询者发送无权限查询的信息。

作为另一种可选的实施方式，上述对献血者信息的调用请求可以是用血请求。

具体的，上述用血请求中包括用血者的身份信息和上述献血者的身份信息。当上述献血机构服务器接收到上述用血请求后，按照预定规则解析上述查询请求得到上述用血者的身份信息，然后根据上述用血者的身份信息判断上述查询者是否有用血权限。若上述用血者有用血权限，则继续判断上述用血者的身份是献血者还是献血者的亲属。若确定上述用血者的身份为献血者，则触发相应献血者无偿用血的智能条约来确定该用血者可无偿用血的用血量信息，然后将该用血量信息打包发送给上述用血者。若确定上述用血者的身份为献血者的亲属，则触发相应的献血者亲属无偿用血的智能条约来确定上述用血者可无偿用血的用血量信息，然后将该用血量信息打包发送给上述用血者。若上述用血者没有用血权限，则向上述发送用血请求的请求方发送该用血者没有无偿用血权限的信息。

可以看出，本申请实施例中通过创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链。然后通过献血机构采集献血者信息并上传献血机构服务器。献血机构服务器对献血者信息验证后，将其登记在区块链中进行全网广播。当需要调用上述献血者信息时，可以向上述献血机构服务器发送相应的调用请求来调用献血者信息，并根据调用请求作相应的其他操作。通过本申请实施例，可以通过区块链去中心化和不可更改的加密属性来记录公民的献血信息，全国可联网在线上查询献血记录以及反馈信息。

参见图2，图2是本申请实施例提供的另一种献血监管方法的示意流程图，如图2所示该方法可包括：

201：接收来自献血机构发送的献血者信息。

在本申请实施例中，首先需要创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链，即让全国的各个献血机构以及用血单位的服务器或终端成为该区块链的节点。然后献血机构的服务器接收来自献血机构发送的献血者信息。

202：对上述献血者信息进行验证。

在本申请实施例中，在上述献血机构服务器接收到上述献血者信息，并对其验证通过后，将上述献血者信息按照预设规则进行打包生成验证请求，该验证请求用于向上述献血者进一步确认该献血者信息的真实性；然后将该验证请求发送给上述献血者进行确认。上述献血者确认过上述献血者信息之后，向上述献血机构服务器发送确认信息。当上述献血机构服务器接收到上述献血者发送的确认信息后，则确定对上述献血者信息的验证通过。

203：在对上述献血者信息验证通过后，将上述献血者信息登记在区块链中进行全网广播。

在本申请实施例中，在上述献血机构服务器接收到上述献血者信息后，对其进行验证。验证通过后，上述献血机构的服务器将上述献血者信息登记在区块链中进行全网广播。

204：接收对上述献血者信息的查询请求。

其中，上述对献血者信息的查询请求中包括查询者的身份信息和上述献血者的身份信息。

在本申请实施例中，在上述献血机构服务器将献血者信息登记在区块链中进行全网广播之后，献血者如果想要查询自己的献血记录信息，则该献血者可以通过自己的用户终端(例如手机)向上述献血机构服务器发送查询请求来查询自己的献血信息记录。

作为一种可选的实施方式，上述查询请求的查询方也可以是献血者的亲属或其他和献血相关的单位(例如用血单位)等。

205：根据上述查询者的身份信息和上述献血者的身份信息对上述查询者进行权限验证。

在本申请实施例中，当上述献血机构服务器接收到对上述献血信息的查询请求后，按照预定规则解析上述查询请求得到上述查询者的身份信息和上述献血者的身份信息，然后根据上述查询者的身份信息和献血者的身份信息判断上述查询者是否有对上述献血者信息的查询权限。若上述查询者有查询权限，则继续执行步骤206。

206：若对上述查询者的权限验证通过，则向上述查询者发送上述献血者信息。

在本申请实施例中，当上述献血机构服务器对上述查询者的权限验证通过，则将上述献血者信息发送给上述查询者。

具体的，当上述献血机构服务器对上述查询者的权限验证通过，即上述查询者有查询权限，则根据上述查询请求中的献血者身份信息从区块链中获取和该献血者身份信息相对应的献血者信息。然后，将获取到的献血者身份信息打包发送给上述查询者。

可以看出，本申请实施例中通过创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链。然后通过献血机构采集献血者信息并上传献血机构服务器。献血机构服务器对献血者信息验证后，将其登记在区块链中进行全网广播。当献血者或者其亲属想要查询上述献血者的献血记录信息时，可以向上述献血机构服务器发送查询请求来获取上述献血者信息。通过本申请实施例，可以通过区块链去中心化和不可更改的加密属性来记录公民的献血信息，全国可联网在线上查询献血记录。

参见图3，图3是本申请实施例提供的又一种献血监管方法的示意流程图，如图3所示该方法可包括：

301：接收来自献血机构发送的献血者信息。

在本申请实施例中，首先需要创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链，即让全国的各个献血机构以及用血单位的服务器或终端成为该区块链的节点。然后献血机构的服务器接收来自献血机构发送的献血者信息。

302：对上述献血者信息进行验证。

在本申请实施例中，在上述献血机构服务器接收到上述献血者信息，并对其验证通过后，将上述献血者信息按照预设规则进行打包生成验证请求，该验证请求用于向上述献血者进一步确认该献血者信息的真实性；然后将该验证请求发送给上述献血者进行确认。上述献血者确认过上述献血者信息之后，向上述献血机构服务器发送确认信息。当上述献血机构服务器接收到上述献血者发送的确认信息后，则确定对上述献血者信息的验证通过。

303：接收来自上述献血者发送的人员关系图表信息。

在本申请实施例中，当上述献血机构服务器接收献血者信息并对其进行验证通过后，可以向上述献血者发送是否需要上传献血者人员关系图表信息的提示信息。若上述献血机构服务器接收到上述献血者发送的人员关系图表信息，则继续执行步骤304。若接收到献血者发送的不上传人员关系图表信息的提示信息，则上述献血机构服务器直接将上述献血者信息登记在区块链中进行全网广播。

304：在对上述人员关系图表信息验证通过后，将上述人员图表关系信息和上述献血者信息关联，并登记在区块链中进行全网广播。

在本申请实施例中，当上述献血机构服务器接收到上述献血者发送的人员关系图表信息后，对其进行验证。当对上述人员关系图表信息的验证通过后，上述献血机构服务器将上述人员关系图表信息与上述献血者信息进行关联，然后将关联后的上述人员图表关系信息和上述献血者信息登记到一个区块中并进行全网广播，当经过共识机制后将该区块作为一个新的区块添加到区块链中。

作为一种可选的实施方式，上述对上述人员关系图表信息验证具体可以包括根据上述献血者信息中献血者的个人信息获取上述献血者的户口数据，然后根据获取到的户口数据来验证上述人员关系图表信息的真伪性。

305：接收和上述献血者信息相关的用血请求。

其中，上述用血请求中包括用血者的身份信息和上述献血者的身份信息。

在本申请实施例中，在上述献血机构服务器将献血者信息登记在区块链中进行全网广播之后，如果献血者或献血者的直系亲属需要无偿用血时，献血者、献血者的直系亲属或用血单位可以向上述献血机构服务器发起用血请求。然后献血机构接收用血请求并对其进行验证来确认上述用血请求中的用血者是否有无偿用血的权限。

306：根据上述用血请求中的用血者的身份信息确定上述用血者的身份。

在本申请实施例中，当上述献血机构接收到用血请求后，对用血请求解析得到用血请求中的用血者身份信息以及献血者的身份信息，然后需要根据上述用血请求中的用血者的身份信息确定上述用血者的身份，以便确定用血者是否具有无偿用血的权限。

307：若上述用血者的身份为上述献血者，则根据无偿献血的用血规则和上述献血者信息向请求方发送上述献血者的可用血量信息。

在本申请实施例中，若确定上述用血者的身份为献血者，则触发相应献血者无偿用血的智能条约来确定该用血者可无偿用血的用血量信息，然后将该用血量信息打包发送给上述用血者。

308：若上述用血者的身份为上述献血者的亲属，则根据无偿献血的用血规则和上述献血者信息向请求方发送上述献血者的亲属的可用血量信息。

在本申请实施例中，若确定上述用血者的身份为献血者的亲属，则触发相应的献血者亲属无偿用血的智能条约来确定上述用血者可无偿用血的用血量信息，然后将该用血量信息打包发送给上述用血者。

可以看出，本申请实施例中通过创建全国公信献血监管查询系统，并让全国各个献血机构以及用血单位上链加入该献血监管查询系统形成区块链。然后通过献血机构采集献血者信息并上传献血机构服务器。献血机构服务器对献血者信息验证后，将其登记在区块链中进行全网广播。当献血者或者其亲属需要无偿用血时，可以通过向上述献血机构服务器发送用血请求，来进行快速验证。通过本申请实施例，可以通过区块链去中心化和不可更改的加密属性来记录公民的献血信息，减少急需用血时验证的冗余流程。

本申请实施例还提供一种服务器，该服务器用于执行前述任一项上述的方法的单元。具体地，参见图4，图4是本申请实施例提供的一种服务器的示意框图。本实施例的服务器包括：接收单元410、验证单元420、登记单元430以及调用单元440。

接收单元410，用于接收来自献血机构发送的献血者信息；

验证单元420，用于对上述献血者信息进行验证；

登记单元430，用于在对上述献血者信息验证通过后，将上述献血者信息登记在区块链中进行全网广播；

调用单元440，用于接收对上述献血者信息的调用请求，根据上述调用请求对上述献血者信息进行调用。

可选的，上述验证单元包括：

生成单元421，用于根据上述献血者信息生成验证请求；

第二发送单元422，用于向上述献血者发送上述验证请求；

上述接收单元410，用于接收来自上述献血者对上述验证请求的确认信息。

可选的，上述接收单元410，用于接收来自上述献血者发送的人员关系图表信息；

上述验证单元420，用于对上述人员关系图表信息进行验证；

上述服务器还包括：

关联单元450，用于在对上述人员关系图表信息验证通过后，将上述人员图表关系信息和上述献血者信息关联；

上述登记单元430，用于将关联后的上述人员图表关系信息和上述献血者信息登记在区块链中进行全网广播。

可选的，上述对上述献血者信息的调用请求包括查询请求，上述查询请求中包括查询者的身份信息和上述献血者的身份信息；

上述调用单元包括：

权限验证单元441，用于根据上述查询者的身份信息和上述献血者的身份信息对上述查询者进行权限验证；

第一发送单元442，用于若对上述查询者的权限验证通过，则向上述查询者发送上述献血者信息。

可选的，上述对上述献血者信息的调用请求包括用血请求，上述用血请求中包括用血者的身份信息；

上述调用单元包括：

确定单元443，用于根据上述用血请求中的用血者的身份信息确定上述用血者为上述献血者；

上述第一发送单元442，用于根据无偿献血的用血规则和上述献血者信息向请求方发送上述献血者的可用血量信息；

或者，

上述确定单元443，用于根据上述用血请求中的用血者的身份信息和上述人员关系图标确定上述用血者为上述献血者的亲属；

上述第一发送单元442，用于根据无偿献血的用血规则和上述献血者信息向请求方发送上述献血者的亲属的可用血量信息。

参见图5，图5是本申请实施例提供的一种设备，该设备可以为服务器，如图5所示设备包括：一个或多个处理器501；一个或多个输入设备502，一个或多个输出设备503和存储器504。上述处理器501、输入设备502、输出设备503和存储器504通过总线505连接。存储器502用于存储指令，处理器501用于执行存储器502存储的指令。

其中，该设备作为服务器使用的情况下，处理器501用于：接收来自献血机构发送的献血者信息；在对上述献血者信息验证通过后，将上述献血者信息登记在区块链中进行全网广播；接收对上述献血者信息的调用请求，根据上述调用请求对上述献血者信息进行调用。

应当理解，在本申请实施例中，所称处理器501可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

输入设备502可以包括触控板、指纹采传感器(用于采集用户的指纹信息和指纹的方向信息)、麦克风等，输出设备503可以包括显示器(LCD等)、扬声器等。

该存储器504可以包括只读存储器和随机存取存储器，并向处理器501提供指令和数据。存储器504的一部分还可以包括非易失性随机存取存储器。例如，存储器504还可以存储设备类型的信息。

具体实现中，本申请实施例中所描述的处理器501、输入设备502、输出设备503可执行本申请实施例提供的一种献血监管方法的第一实施例中所描述的实现方式、第二实施列以及第三实施例中的实现方式，也可执行本申请实施例所描述的服务器的实现方式，在此不再赘述。

在本申请的另一实施例中提供一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现：接收来自献血机构发送的献血者信息；在对上述献血者信息验证通过后，将上述献血者信息登记在区块链中进行全网广播；接收对上述献血者信息的调用请求，根据上述调用请求对上述献血者信息进行调用。

上述计算机可读存储介质可以是前述任一实施例上述的终端的内部存储单元，例如终端的硬盘或内存。上述计算机可读存储介质也可以是上述终端的外部存储设备，例如上述终端上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，上述计算机可读存储介质还可以既包括上述终端的内部存储单元也包括外部存储设备。上述计算机可读存储介质用于存储上述计算机程序以及上述终端所需的其他程序和数据。上述计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

图6是本申请实施例提供的一种服务器结构示意图，该服务器600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processingunits，CPU)622(例如，一个或一个以上处理器)和存储器632，一个或一个以上存储应用程序642或数据644的存储介质630(例如一个或一个以上海量存储设备)。其中，存储器632和存储介质630可以是短暂存储或持久存储。存储在存储介质630的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器622可以设置为与存储介质630通信，在服务器600上执行存储介质630中的一系列指令操作。

服务器600还可以包括一个或一个以上电源626，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口658，和/或，一个或一个以上操作系统641，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图6所示的服务器结构。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、服务器、终端设备和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种献血监管方法，其特征在于，包括：

接收来自献血机构发送的献血者信息；

在对所述献血者信息验证通过后，将所述献血者信息登记在区块链中进行全网广播；

接收对所述献血者信息的调用请求，根据所述调用请求对所述献血者信息进行调用。

2.根据权利要求1所述的方法，其特征在于，所述对所述献血者信息验证包括：

根据所述献血者信息生成验证请求；

向所述献血者发送所述验证请求；

接收来自所述献血者对所述验证请求的确认信息。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

接收来自所述献血者发送的人员关系图表信息；

在对所述人员关系图表信息验证通过后，将所述人员图表关系信息和所述献血者信息关联，并登记在区块链中进行全网广播。

4.根据权利要求3所述的方法，其特征在于，所述对所述献血者信息的调用请求包括查询请求，所述查询请求中包括查询者的身份信息和所述献血者的身份信息；

所述根据所述调用请求对所述献血者信息进行调用包括：

根据所述查询者的身份信息和所述献血者的身份信息对所述查询者进行权限验证；

若验证通过，则向所述查询者发送所述献血者信息。

5.根据权利要求3所述的方法，其特征在于，所述对所述献血者信息的调用请求包括用血请求，所述用血请求中包括用血者的身份信息和献血者的身份信息；

所述根据所述调用请求对所述献血者信息进行调用包括：

根据所述用血请求中的用血者的身份信息确定所述用血者为所述献血者；

根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的可用血量信息；

或者，

根据所述用血请求中的用血者的身份信息和所述人员关系图标确定所述用血者为所述献血者的亲属；

根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的亲属的可用血量信息。

6.一种服务器，其特征在于，所述服务器包括：

接收单元，用于接收来自献血机构发送的献血者信息；

验证单元，用于对所述献血者信息进行验证；

登记单元，用于在对所述献血者信息验证通过后，将所述献血者信息登记在区块链中进行全网广播；

调用单元，用于接收对所述献血者信息的调用请求，根据所述调用请求对所述献血者信息进行调用。

7.根据权利要求6所述的服务器，其特征在于，

所述接收单元，用于接收来自所述献血者发送的人员关系图表信息；

所述验证单元，用于对所述人员关系图表信息进行验证；

所述服务器还包括：

关联单元，用于在对所述人员关系图表信息验证通过后，将所述人员图表关系信息和所述献血者信息关联；

所述登记单元，用于将关联后的所述人员图表关系信息和所述献血者信息登记在区块链中进行全网广播。

8.根据权利要求7所述的服务器，其特征在于，所述对所述献血者信息的调用请求包括用血请求，所述用血请求中包括用血者的身份信息和献血者的身份信息；

所述调用单元包括：

确定单元，用于根据所述用血请求中的用血者的身份信息确定所述用血者为所述献血者；

第一发送单元，用于根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的可用血量信息；

或者，

所述确定单元，用于根据所述用血请求中的用血者的身份信息和所述人员关系图标确定所述用血者为所述献血者的亲属；

所述第一发送单元，用于根据无偿献血的用血规则和所述献血者信息向请求方发送所述献血者的亲属的可用血量信息。

9.一种服务器，其特征在于，所述服务器包括处理器、存储器和通信模块，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码来执行如权利要求1-5任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1-5任一项所述的方法。