具体实施方式

为使本公开的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本公开进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

本公开，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

此外，下面所描述的本公开不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

图1是根据本公开实施例的要件数据授权方法的一流程图。如图1所示，本公开实施例提供一种要件数据授权方法，应用于要件数据授权系统，包括：请求端110，发送要件数据的授权请求信息；持证主体授权端120，接收授权请求信息，并根据授权请求信息向区块链端130发送要件数据的授权请求结果；区块链端130，根据接收的要件数据的授权请求结果，对要件数据的授权请求结果进行共识存证，并发送第一指令信息至持证主体授权端120；持证主体授权端120根据接收的第一指令信息，并发送第二指令信息至请求端110。

在一具体实施例中，请求端110为要件数据授权的请求方或使用方，持证主体授权端120可以是计算机软件、手机软件以及其它电子设备的软件或者系统，持证主体授权端120对要件数据授权请求进行授权，持证主体授权端120对要件数据的授权主体开放，区块链端130包括区块链。请求端110可以基于对特定要件数据的使用需求向持证主体授权端120发送要件数据的授权请求信息。当持证主体授权端120收到要件数据的授权请求信息后，要件数据的授权主体进入持证主体授权端120，对要件数据的授权请求信息进行授权审核。持证主体授权端120将要件数据的授权请求结果发送至区块链端130。区块链端130接收要件数据的授权请求结果，并对要件数据的授权请求结果进行共识存证。区块链端130发送第一指令信息至持证主体授权端120。持证主体授权端120接收第一指令信息，持证主体授权端120发送第二指令信息至请求端110。在一具体实施例中，持证主体授权端120独立于区块链存在。持证主体授权端120可以是一公开端，公开端的功能不限于仅实现持证主体授权端120的功能，还包括实现更多其他功能。

本公开实施例持证主体授权端200，对要件数据的授权请求进行审核确认。本公开实施例提供了一种基于区块链的要件数据使用申请和授权的互信且安全的授权方式。本公开的技术方案可有效避免相关部门或权威部门在对要件数据的授权过程繁杂工作流程，解决了无法高效准确地获取有效的要件数据授权这一问题，智能化地完成对要件数据持证主体的核验并为核验结果配备有法律效力的可信凭证，实现了要件验证的智能化授权效果，同时也提高了要件数据授权请求的效率。

图2是根据本公开实施例的要件数据授权方法中持证主体授权端身份验证的一流程图。如图2所示，在一些实施例中，在接收授权请求信息之后包括：持证主体授权端120接收第一身份信息，并验证第一身份信息是否与要件数据的授权主体匹配；持证主体授权端120发送第一身份信息的验证结果至区块链端130。在一些实施例中，验证第一身份信息是否与要件数据的授权主体匹配包括：若第一身份信息的验证结果为验证通过，则持证主体授权端120确认是否同意授权第二授权请求；若第一身份信息的验证结果为验证不通过，则持证主体授权端120接收第二身份信息，并验证第二身份信息是否与要件数据的授权主体匹配。在一些实施例中，验证第一身份信息是否与要件数据的授权主体匹配之后包括：持证主体端120发送第一身份信息的验证结果至区块链端130；区块链端130根据接收的第一身份信息的验证结果，对第一身份信息的验证结果进行共识存证。

在一具体实施例中，持证主体授权端120用于在执行数据鉴证拉取操作前获得要件数据持证主体对要件数据的使用授权，即在执行要件数据鉴证拉取前，持证主体授权端120的身份信息核验通过后，再对要件数据进行授权请求的验证。

在一具体实施例中，要件数据的授权主体发送身份信息至持证主体授权端120。持证主体授权端120可能存在未在线的状态，持证主体授权端120可以通过电话、短信或邮件等方式通知持证主体授权端120进行授权验证。持证主体授权端120会先提交身份信息用于验证并登录持证主体授权端120，持证主体授权端120对相应的身份信息进行有效性验证，验证成功后的要件数据的持证主体继续进行授权操作。在一具体实施例中，可能会因为多种原因导致身份验证失败，例如：身份验证方输入的身份信息错误、网络信号异常或服务器异常等问题。要件数据的持证主体授权端120可以设置再次接收第二身份信息的方式对身份信息再次核验。通过提供再次发送数据授权请求这一技术特征，进一步优化本公开的技术完整。不同要件数据可以根据实际情况设置不同次数的公开。对于不同要件数据持证主体授权端120的身份验证情况可根据要件数据的重要性和实际情况做出不同验证规则。例如，持证主体授权端120验证身份信息不符合条件，持证主体授权端120将发出身份验证失败的结果。在一些实施例中，持证主体授权端120验证身份信息符合后，确定是否同意授权要件数据授权请求。持证主体授权端120发送身份信息的验证结果至区块链端130。在一具体实施例中，要件数据的持证主体具有对要件数据授权请求是否通过的决定权，进一步保障了本公开要件数据授权请求的安全性。本公开实施例对要件数据授权公开的过程的完整性做出了更进一步的优化。

图3是根据本公开实施例的要件数据授权方法中持证主体授权端对使用场景验证的一流程图。如图3所示，在一些实施例中，请求端110，发送要件数据的授权请求信息包括：请求端110发送授权请求的要件数据信息；请求端110发送要件数据授权请求的使用场景信息。在一些实施例中，在请求端110发送要件数据授权请求的使用场景信息之后包括：持证主体授权端120接收使用场景信息，用于确定是否同意要件数据的授权请求。

在一具体实施例中，要件数据授权请求的要件数据安全级别高，例如，要件数据可以是身份信息或法人信息等。对于要件数据信息使用的安全保障尤为必要，保障了要件数据的安全使用。

在一具体实施例中，要件数据的提供方为权威部门，例如公安部门或民政部门等。当办理某项业务需要用到电子证照等特定类型的要件数据时，需要权威部门对要件数据进行背书，以使要件数据准确合法。在相关实施例中，部分可获取的要件数据只适用于某个小范围内，且需要责任人承担法律风险。在本公开实施例中，权威部门可以智能化对要件数据背书，例如通过统一对电子数据进行背书。本公开实施例既节省了请求端的效率，又节省了权威部门管理要件数据的效率。智能化且安全地扩大了合法有效要件数据的使用范围。

图4是根据本公开实施例的要件数据授权方法中区块链端发送第一指令信息的一流程图。如图4所示，在一些实施例中，发送第一指令信息至持证主体授权端120包括：若要件数据的授权请求结果为同意授权，则区块链端130发送第一指令至持证主体授权端120包括：区块链端130发送授权请求成功的结果和数字签名凭证至持证主体授权端120；若要件数据的授权请求结果为不同意授权，则区块链端130发送第一指令至持证主体授权端120包括：区块链端130发送授权请求失败的结果至持证主体授权端120。

在一具体实施例中，区块链底链130对要件数据的授权请求结果进行共识存证，并根据要件数据的授权请求结果，发送第一指令信息至持证主体授权端120。当要件数据的授权请求结果为同意授权时，区块链端130发送授权请求成功的结果和数字签名凭证至持证主体授权端120；当要件数据的授权请求结果为不同意授权，区块链端130发送授权请求失败的结果至持证主体授权端120。在一些实施例中，区块链端130的底链是一种用于共识管理并执行各种区块链交易所依赖的区块链节点网络。在一些实施例中，区块链端130的底链提供多端授权智能合约、监管智能合约。在一些实施例中，区块链端130发送数字签名后的有效凭证至持证主体授权端120中，数字签名的有效凭证通过使用哈希（hash）算法对要件数据进行处理，并发送至持证主体授权端120。相应地，持证主体授权端120发送数字签名凭证至请求端110。请求端110收到数字签名凭证后，再进行验签即可达到获取要件数据使用的目的。申请端110高效且便捷地获得合法有效的使用权限，继续进行后续业务处理。本公开实施例有效保障了要件数据的安全性以及本公开的完整性。

本公开的要件数据授权方法，通过验证要件数据持证主体的身份，进一步对要件数据授权请求授权，通过区块链的共识存证，解决了无法高效准确地获取合法有效的要件数据授权这一问题。智能化地完成对要件数据持证主体的核验并为核验结果配备有法律效力的可信凭证，实现了要件验证的智能化授权效果，同时也提高了数据授权请求的效率。

在一相关实施例中，共识存证主要包括：联盟节点在区块链底链中发起交易；联盟成员集体对上述交易结果进行共识，当一定范围内的成员节点的交易结果是一致的，则认为这个交易结果是有效的；把交易结果记账到账本中。

在一相关实施例中，共识存证这一步是必要的，共识存证是实现去中心化的必要步骤，共识代表交易或审核的结果是联盟成员共同做出的，所有联盟成员共同对交易或审核的结果负责和背书，存证是将联盟成员共识的结果记录下来的技术手段，这个技术手段需要保证交易及共识结果的来源是有效的，并且这个结果在保存后不能被篡改，共识存证是保证审核结果真实有效的技术基础。

本公开从官方或权威渠道发布，并且由官方或权威部门对数据内容进行背书，举例来说，数据由数据提供方直接供给并上链，数据提供方对数据内容的有效性权威性进行背书，授权需要经过数据持有主体本人的验证确认。因此，本公开的数据可以作为具备法律效力的要件使用，来源有效、内容可信、途径权威。同时，区块链联盟成员对数据提供方上链供给数据的行为进行共识存证，该存证可以证明数据来源合法有效。进一步地，数据通过发送请求的请求方的入链证书公钥加密返回，保障数据只能被发送请求的请求方解密使用。

在一具体实施例中，电子证照库会提供相应的业务模块完成对库内证照的使用场景、调取权限等的管理维护。证照类数据需要持证主体本人授权以及通过区块链技术对数据使用行为进行存证，使得普通的数据作为有效的法律证据。本公开的该实施例有效解决了中心化的模式中管理者要承担较大的数据及网络安全责任风险这一技术问题。

本公开实施例还提供一种要件数据授权系统，包括：请求端110，用于发送要件数据的授权请求信息；持证主体授权端120，用于接收授权请求信息，并根据授权请求信息向区块链端130发送要件数据的授权请求结果；区块链端，用于根据接收的要件数据的授权请求结果，对要件数据的授权请求结果进行共识存证，并发送第一指令信息至持证主体授权端120；持证主体授权端120还用于根据接收的第一指令信息，发送第二指令信息至请求端110。

本公开实施例还提供一种电子设备，包括：处理器，存储器及存储在存储器上并可在处理器上运行的程序或指令，程序或指令被处理器执行时实现上述的要件数据授权方法的步骤。

本公开实施例还提供一种可读存储介质，可读存储介质上存储程序或指令，程序或指令被处理器执行时实现上述的要件数据授权方法的步骤。

需要说明的是，本公开实施例提供的要件数据授权方法，执行主体可以为要件数据授权系统，或者该要件数据授权系统可以通过要件数据授权系统执行要件数据授权方法的控制模块。本公开实施例中以要件数据授权系统执行要件数据授权方法为例，说明本公开实施例提供的要件数据授权的系统。

本公开实施例中的要件数据授权系统可以是系统，也可以是终端中的部件、集成电路、或芯片。该系统可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本或者个人数字助理（personal digital assistant，PDA）等，非移动电子设备可以为服务器、网络附属存储器（Network Attached Storage，NAS）、个人计算机（personal computer，PC）、电视机（television，TV）、柜员机或者自助机等，本公开实施例不作具体限定。

本公开实施例中的要件数据授权系统可以为具有操作系统的系统。该操作系统可以为安卓（Android）操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本公开实施例不作具体限定。

本公开实施例提供的要件数据授权系统能够实现图1至图4的方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图5所示，本公开实施例还提供一种电子设备500，包括处理器501，存储器502，存储在存储器502上并可在所述处理器501上运行的程序或指令，该程序或指令被处理器501执行时实现上述要件数据授权方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本公开实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图6为实现本公开实施例的一种电子设备的硬件结构示意图。

该电子设备600包括但不限于：射频单元601、网络模块602、音频输出单元603 、输入单元604、传感器605、显示单元606、用户输入单元607 、接口单元608、存储器609、以及处理器610等部件。

本领域技术人员可以理解，电子设备600还可以包括给各个部件供电的电源（比如电池），电源可以通过电源管理系统与处理器610逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图6中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

处理器610，用于执行请求端110、持证主体授权端120和区块链端130的功能，例如发送要件数据的授权请求信息，接收授权请求信息，发送要件数据的授权请求结果，接收的要件数据的授权请求结果，发送第一指令信息，接收第一指令信息，发送第二指令信息。

处理器610，还用于请求端110、持证主体授权端120和区块链端130的下述其他功能。例如：发送第一指令信息至持证主体授权端120包括：若要件数据的授权请求结果为同意授权，则区块链端130发送第一指令至持证主体授权端120包括：区块链端130发送授权请求成功的结果和数字签名凭证至持证主体授权端120，若要件数据的授权请求结果为不同意授权，则区块链端130发送第一指令至持证主体授权端120包括：区块链端130发送授权请求失败的结果至持证主体授权端120。

接收授权请求信息之后包括：持证主体授权端120接收第一身份信息，并验证第一身份信息是否与要件数据的授权主体匹配，持证主体授权端120发送第一身份信息的验证结果至区块链端130。

其中，验证第一身份信息是否与要件数据的授权主体匹配包括：若第一身份信息的验证结果为验证通过，则持证主体授权端120确认是否同意授权第二授权请求；若第一身份信息的验证结果为验证不通过，则持证主体授权端120接收第二身份信息，并验证第二身份信息是否与要件数据的授权主体匹配。

其中，验证第一身份信息是否与要件数据的授权主体匹配之后包括：持证主体端120发送第一身份信息的验证结果至区块链端130，区块链端130根据接收的第一身份信息的验证结果，对第一身份信息的验证结果进行共识存证。

请求端110，发送要件数据的授权请求信息包括：请求端110发送授权请求的要件数据信息；请求端110发送要件数据授权请求的使用场景信息。

其中，在请求端110发送要件数据授权请求的使用场景信息之后包括：持证主体授权端120接收使用场景信息，用于确定是否同意要件数据的授权请求。

应理解的是，本公开实施例中，输入单元604可以包括图形处理器（GraphicsProcessing Unit，GPU）6041和麦克风6042，图形处理器6041对在视频捕获模式或图像捕获模式中由图像捕获系统（如摄像头）获得的静态图片或视频的图像数据进行处理。显示单元606可包括显示面板6061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板6061。用户输入单元607包括触控面板6071以及其他输入设备6072。触控面板6071，也称为触摸屏。触控面板6071可包括触摸检测系统和触摸控制器两个部分。其他输入设备6072可以包括但不限于物理键盘、功能键（比如音量控制按键、开关按键等）、轨迹球、鼠标、操作杆，在此不再赘述。存储器609可用于存储软件程序以及各种数据，包括但不限于应用程序和操作系统。处理器610可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器610中。

本公开实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述要件数据授权方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器（Read-Only Memory， ROM）、随机存取存储器（Random Access Memory， RAM）、磁碟或者光盘等。

本公开实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述要件数据授权方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本公开实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。此外，需要指出的是，本公开实施方式中的方法和系统的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端（可以是手机，计算机，服务器，或者网络设备等）执行本公开各个实施例所述的方法。

需要注意的是，在上述的要件数据授权方法、系统、电子设备和可读存储介质的实施例中，对于普通数据的授权方法、系统、电子设备和可读取设备的保护同样适用。

上面结合附图对本公开的实施例进行了描述，但是本公开并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本公开的启示下，在不脱离本公开宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本公开的保护之内。

应当理解的是，本公开的上述具体实施方式仅仅用于示例性说明或解释本公开的原理，而不构成对本公开的限制。因此，在不偏离本公开的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。此外，本公开所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。