WO2019042176A1 - 黑名单数据交换方法及应用服务器 - Google Patents

黑名单数据交换方法及应用服务器 Download PDF

Info

Publication number
WO2019042176A1
WO2019042176A1 PCT/CN2018/101265 CN2018101265W WO2019042176A1 WO 2019042176 A1 WO2019042176 A1 WO 2019042176A1 CN 2018101265 W CN2018101265 W CN 2018101265W WO 2019042176 A1 WO2019042176 A1 WO 2019042176A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
exchange
blacklist
sub
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/101265
Other languages
English (en)
French (fr)
Inventor
郭鹏程
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OneConnect Smart Technology Co Ltd
Original Assignee
OneConnect Smart Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OneConnect Smart Technology Co Ltd filed Critical OneConnect Smart Technology Co Ltd
Publication of WO2019042176A1 publication Critical patent/WO2019042176A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information

Definitions

  • the present application relates to the field of data processing technologies, and in particular, to a blacklist data exchange method and an application server.
  • the blacklist exchange sharing in the industry mainly involves the use of various operating methods by data storage center units to attract external organizations to upload blacklist data to central units, and then share them with other external organizations by the central unit.
  • External organizations have no control over the use of uploaded data.
  • the favorable rules for sharing data are not reliable enough because of the central unit operation definition. Therefore, the willingness of external organizations to upload and exchange data is weak, and data islands are difficult to break.
  • the quality of the data uploaded by external agencies received by the central unit is uneven, and it is difficult for the central unit to regulate and constrain the data, resulting in high cost of data post-processing, and the cost of external sharing and reuse is very high.
  • the present application proposes a blacklist data exchange method and an application server to solve the problem of how to standardize the exchange and management of blacklist data.
  • the present application provides a blacklist data exchange method, which is applied to an application server, where the application server is a main node and performs data communication with multiple sub-nodes, and the method includes the following steps:
  • each sub-node is assigned corresponding responsibilities
  • the sub-nodes that have passed the exchange condition check are notified to exchange data one-to-one.
  • the method further comprises the steps before monitoring:
  • the pre-verification process is performed by the primary node to verify whether the blacklist data meets requirements according to a preset rule, where the preset rule includes: the data format is correct, the user privacy cannot be written, and there is no duplication or deletion. False data.
  • the verification grading process is to set a corresponding exchange level for the corresponding node according to the degree of standardization of the blacklist data, and then authorize and allocate the corresponding transaction currency to the node.
  • the verification grading process further includes:
  • the step of assigning corresponding responsibilities to each sub-node according to the monitoring result specifically includes:
  • the exchange condition includes whether the blacklist data provided by the data provider meets the preset rule and whether the data requestor has a sufficient amount of transaction currency, and when both parties of the exchange reach the exchange condition, that is, the data provider provides When the blacklist data meets the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, it indicates that the verification is passed.
  • the step of notifying the one-to-one data exchange by the node that exchanges the condition check includes:
  • the blacklist data uploaded by the data provider is copied to the data requester.
  • the present application further provides an application server, including a memory, a processor, and a blacklist data exchange system stored on the memory and operable on the processor, the blacklist data exchange
  • an application server including a memory, a processor, and a blacklist data exchange system stored on the memory and operable on the processor, the blacklist data exchange
  • the steps of the blacklist data exchange method as described above are implemented when the system is executed by the processor.
  • the present application further provides a computer readable storage medium storing a blacklist data exchange system, the blacklist data exchange system being executable by at least one processor, The step of causing the at least one processor to perform the blacklist data exchange method as described above.
  • the blacklist data exchange method, the application server, and the computer readable storage medium proposed by the present application may use one central unit as the primary node of the blockchain, and other cooperative organizations as the sub-nodes, and utilize the based region.
  • the blockchain's smart contract technology performs blacklist data exchange and management.
  • the blacklist data uploaded by the sub-nodes is pre-verified for authenticity classification, and the sub-nodes that do not participate in the exchange are used as supervisors to verify the exchange conditions of the exchange parties, thereby ensuring the true compliance of the exchanged data. Since the exchange process is clear and transparent, the sharing of blacklist data is conducive to the business development of each organization and dispels the concerns of the cooperation agencies to upload data.
  • the central unit can escort the quality of the exchanged data and establish a data ecosystem.
  • FIG. 1 is a schematic diagram of an optional application environment of each embodiment of the present application.
  • FIG. 2 is a schematic diagram of an optional hardware architecture of the application server of FIG. 1;
  • FIG. 3 is a schematic diagram of a program module of a first embodiment of a blacklist data exchange system of the present application
  • FIG. 4 is a schematic diagram of a program module of a second embodiment of the blacklist data exchange system of the present application.
  • FIG. 5 is a schematic flowchart of a first embodiment of a blacklist data exchange method according to the present application.
  • FIG. 6 is a schematic flowchart diagram of a second embodiment of a blacklist data exchange method according to the present application.
  • first, second and the like in the present application are for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. .
  • features defining “first” and “second” may include at least one of the features, either explicitly or implicitly.
  • the technical solutions between the various embodiments may be combined with each other, but must be based on the realization of those skilled in the art, and when the combination of the technical solutions is contradictory or impossible to implement, it should be considered that the combination of the technical solutions does not exist. Nor is it within the scope of protection required by this application.
  • FIG. 1 it is a schematic diagram of an optional application environment of each embodiment of the present application.
  • the present application is applicable to an application environment including, but not limited to, the terminal device 1, the application server 2, and the network 3.
  • the application server 2, the blockchain network 3, and the plurality of terminal devices 1 together form a blockchain network system for performing blacklist data exchange and management.
  • the application server 2 is a device capable of automatically performing numerical calculation and/or information processing according to an instruction set or stored in advance, for centrally storing and managing blacklist data to be exchanged, that is, the blockchain.
  • the application server 2 may be a computer, a single network server, a server group composed of a plurality of network servers, or a cloud-based cloud composed of a large number of hosts or network servers.
  • the blockchain network 3 is used for data transmission and interaction in the blockchain network system.
  • the application server 2 performs data communication with a plurality of terminal devices 1 through the blockchain network 3, and the network may be an intranet, an Internet, or a Global System of Mobile communication.
  • GSM Global System of Mobile communication
  • WCDMA Wideband Code Division Multiple Access
  • 4G network 5G network
  • Bluetooth Wi-Fi
  • Wi-Fi Wi-Fi
  • the terminal device 1 is configured to exchange the blacklist data with each other as a sub-node of the blockchain network system.
  • the terminal device 1 may be a mobile phone, a smart phone, a notebook computer, a digital broadcast receiver, a PDA (Personal Digital Assistant), a PAD (Tablet PC), a PMP (Portable Multimedia Player), a navigation device, an in-vehicle device, or the like.
  • Mobile devices, as well as fixed terminals such as digital TVs, desktop computers, notebooks, servers, and the like.
  • the application server 2 may include, but is not limited to, the memory 11, the processor 12, and the network interface 13 being communicably connected to each other through a system bus. It is to be noted that FIG. 2 only shows the application server 2 with components 11-13, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.
  • the memory 11 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (eg, SD or DX memory, etc.), and a random access memory (RAM). , static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), magnetic memory, magnetic disk, optical disk, and the like.
  • the memory 11 may be an internal storage unit of the application server 2, such as a hard disk or memory of the application server 2.
  • the memory 11 may also be an external storage device of the application server 2, such as a plug-in hard disk equipped on the application server 2, a smart memory card (SMC), and a secure digital number. (Secure Digital, SD) card, flash card, etc.
  • the memory 11 can also include both the internal storage unit of the application server 2 and its external storage device.
  • the memory 11 is generally used to store an operating system installed in the application server 2 and various types of application software, such as program codes of the blacklist data exchange system 200. Further, the memory 11 can also be used to temporarily store various types of data that have been output or are to be output.
  • the processor 12 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments.
  • the processor 12 is typically used to control the overall operation of the application server 2, such as performing control and processing related to data interaction or communication with the terminal device 1.
  • the processor 12 is configured to run program code or process data stored in the memory 11, such as running the blacklist data exchange system 200 and the like.
  • the network interface 13 may comprise a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the application server 2 and other electronic devices.
  • the network interface 13 is mainly used to connect the application server 2 to one or more of the terminal devices 1 through the blockchain network 3, and the application server 2 and the one or A data transmission channel and a communication connection are established between the plurality of terminal devices 1.
  • the present application proposes a blacklist data exchange system 200.
  • FIG. 3 it is a program module diagram of the first embodiment of the blacklist data exchange system 200 of the present application.
  • the blacklist data exchange system 200 includes a series of computer program instructions stored in the memory 11, and when the computer program instructions are executed by the processor 12, the blacklist of the embodiments of the present application can be implemented. Data exchange operation.
  • the blockchain for blacklist data exchange one central unit is used as the primary node, and other cooperative organizations are used as the branch nodes.
  • the application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node.
  • the plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes.
  • the blockchain-based intelligent contract technology is used to exchange and manage the blacklist data according to the agreed exchange rules between the nodes to ensure that the entire data exchange process is fair and transparent, and the process of obtaining data by the cooperative organization is standardized.
  • the blacklist data exchange system 200 can be divided into one or more modules based on the particular operations implemented by the various portions of the computer program instructions. For example, in FIG. 3, the blacklist data exchange system 200 can be divided into a monitoring module 201, an allocation module 202, and a notification module 203. among them:
  • the monitoring module 201 is configured to monitor a blacklist data exchange request and response between the node nodes.
  • each of the sub-nodes having the data exchange requirement sequentially sends a blacklist data exchange request to the other sub-nodes through the blockchain network 3.
  • the request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like.
  • the sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request.
  • the response includes an identifier of the response, information of the corresponding blacklist data, an identity of the demanding node, an identity of the response node, a feedback result of the request, and the like.
  • the feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request.
  • the feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange.
  • the monitoring module 201 can monitor requests and responses between the various sub-nodes.
  • the sub-node that receives the blacklist data exchange request responds automatically, tries to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.
  • the allocating module 202 is configured to allocate corresponding responsibilities to each sub-node according to the monitoring result.
  • the distribution module 202 configures the sub-node that issues the blacklist data exchange request as the data requester, configures the sub-node that agrees to the blacklist data exchange request as the data provider, and does not issue the blacklist data exchange request and response or
  • the sub-nodes that disagree with the blacklist data exchange request (or select one or more of them) are configured as supervisors.
  • the notification module 203 is configured to notify the branch node that does not participate in the current exchange as the supervisor, and check the exchange conditions of the exchange parties.
  • each of the node nodes uploads blacklist data to the master node (the application server 2), and the master node allocates a certain number of transaction coins (bits) for each node. Currency) for subsequent exchanges.
  • the supervisor can obtain the blacklist data provided by the data provider (that is, the blacklist data uploaded by the data provider to the master node) from the master node, and perform verification.
  • the exchange condition includes whether the blacklist data provided by the data provider conforms to a preset rule and whether the data requestor has a sufficient amount of transaction currency.
  • the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.
  • the data requester needs to pay a corresponding amount of the transaction currency.
  • the exchange condition that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data
  • the verification is passed, this time The exchange can proceed.
  • the notification module 203 is further configured to notify the sub-nodes that exchange the condition check to perform data exchange one-to-one.
  • the notification module 203 notifies the data requester and the node of the data provider to start data exchange.
  • the data providing direction data requester shares its pre-stored blacklist data (synchronizes the related data to the data requester), and the data requester pays the data provider according to the exchange level corresponding to the node and the data amount of the blacklist data.
  • the notification module 203 needs to calculate the transaction currency that the data requester needs to pay according to the exchange level of the data requester and the data amount of the blacklist data, and upload the data provider after the data requester successfully sends the data.
  • the blacklist data copy is synchronized to the data requester.
  • the blacklist data exchange system 200 includes a series of computer program instructions stored in the memory 11, and when the computer program instructions are executed by the processor 12, the blacklist of the embodiments of the present application can be implemented. Data exchange operation.
  • the blockchain for blacklist data exchange one central unit is used as the primary node, and other cooperative organizations are used as the branch nodes.
  • the application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node.
  • the plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes.
  • the blacklist data exchange system 200 includes a pre-verification module 204 and a classification module 205 in addition to the monitoring module 201, the distribution module 202, and the notification module 203 in the first embodiment.
  • the pre-verification module 204 is configured to perform pre-verification on the blacklist data uploaded by the sub-node.
  • pre-verification is performed with the master node.
  • the pre-verification process is that the pre-verification module 204 verifies whether the blacklist data meets the requirements according to a preset rule.
  • the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.
  • the grading module 205 is configured to perform a grading process on the node according to the pre-verification result.
  • the grading module 205 performs a grading process on the blacklist data according to the verification result of the blacklist data, and mainly sets a corresponding exchange level according to the standardization degree of the blacklist data for the corresponding node, and then Authorize and assign the corresponding transaction currency to the sub-node. For example, when the degree of standardization of the blacklist data is high, the node can subsequently exchange more data with less transaction currency.
  • the master node authorizes the node to perform blacklist data exchange, and allocates a corresponding number of transactions to the node according to the data amount of the blacklist data and a preset ratio. currency.
  • the present application also proposes a blacklist data exchange method.
  • FIG. 5 it is a schematic flowchart of the first embodiment of the blacklist data exchange method of the present application.
  • the application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node.
  • the plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes.
  • the blockchain-based intelligent contract technology is used to exchange and manage the blacklist data according to the agreed exchange rules between the nodes to ensure that the entire data exchange process is fair and transparent, and the process of obtaining data by the cooperative organization is standardized.
  • the order of execution of the steps in the flowchart shown in FIG. 5 may be changed according to different requirements, and some steps may be omitted.
  • the method includes the following steps:
  • Step S600 monitoring a blacklist data exchange request and response between the node nodes.
  • each of the sub-nodes having the data exchange requirement sequentially sends a blacklist data exchange request to the other sub-nodes through the blockchain network 3.
  • the request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like.
  • the sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request.
  • the response includes an identifier of the response, information of the corresponding blacklist data, an identity of the demanding node, an identity of the response node, a feedback result of the request, and the like.
  • the feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request.
  • the feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange.
  • the application server 2 as a master node can monitor requests and responses between the various node nodes.
  • the sub-node that receives the blacklist data exchange request automatically responds, attempts to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.
  • Step S602 assigning respective responsibilities to each of the sub-nodes according to the monitoring result.
  • the application server 2 configures the sub-node that issues the blacklist data exchange request as the data requester, configures the sub-node that agrees to the blacklist data exchange request as the data provider, and does not issue the blacklist data exchange request and
  • the sub-nodes that answer or disagree with the blacklist data exchange request (or select one or more of them) are configured as supervisors.
  • Step S604 notifying the sub-nodes that do not participate in the current exchange as the supervisory party, and verifying the exchange conditions of the exchange parties.
  • each of the node nodes uploads blacklist data to the master node (the application server 2), and the master node allocates a certain number of transaction coins (bits) for each node. Currency) for subsequent exchanges.
  • the supervisor can obtain the blacklist data provided by the data provider (that is, the blacklist data uploaded by the data provider to the master node) from the master node, and perform verification.
  • the exchange condition includes whether the blacklist data provided by the data provider conforms to a preset rule and whether the data requestor has a sufficient amount of transaction currency.
  • the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.
  • the data requester needs to pay a corresponding amount of the transaction currency.
  • the exchange condition that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data
  • the verification is passed, this time The exchange can proceed.
  • Step S606 notifying that the sub-nodes that exchange the condition check perform one-to-one data exchange.
  • the application server 2 notifies the data requester and the node of the data provider to start data exchange.
  • the data providing direction data requester shares its pre-stored blacklist data (synchronizes the related data to the data requester), and the data requester pays the data provider according to the exchange level corresponding to the node and the data amount of the blacklist data.
  • the application server 2 needs to calculate a transaction currency that the data requester needs to pay according to the exchange level of the data requester and the data volume of the blacklist data, and when the data requester successfully pays, the data provider is
  • the uploaded blacklist data is copied to the data requester.
  • the sub-node can acquire the transaction currency again by uploading new blacklist data.
  • FIG. 6 it is a schematic flowchart of a second embodiment of the blacklist data exchange method of the present application.
  • the steps S704-S710 of the blacklist data exchange method are similar to the steps S600-S606 of the first embodiment, except that the method further includes steps S700-S702.
  • the method includes the following steps:
  • Step S700 Perform pre-verification on the blacklist data uploaded by the sub-node.
  • pre-verification is performed with the master node.
  • the pre-verification process is performed by the main node according to a preset rule to verify whether the blacklist data meets the requirements.
  • the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.
  • Step S702 performing a truth-grading process on the node according to the pre-verification result.
  • the master node performs the authentication and classification process according to the verification result of the blacklist data, and mainly sets a corresponding exchange level for the corresponding node according to the standardization degree of the blacklist data.
  • the sub-node is then authorized and assigned the corresponding transaction currency. For example, when the degree of standardization of the blacklist data is high, the node can subsequently exchange more data with less transaction currency.
  • the master node authorizes the node to perform blacklist data exchange, and allocates a corresponding number of transactions to the node according to the data amount of the blacklist data and a preset ratio. currency.
  • Step S704 monitoring a blacklist data exchange request and a response between the node nodes.
  • each of the sub-nodes having data exchange requirements sequentially sends blacklist data exchange requests to other sub-nodes through the blockchain network 3.
  • the request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like.
  • the sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request.
  • the response includes an identifier of the response, information of the corresponding blacklist data, an identity identifier of the demanding node, an identity of the response node, a feedback result of the request, and the like.
  • the feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request.
  • the feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange.
  • the application server 2 as a master node can monitor requests and responses between the various node nodes.
  • the sub-node that receives the blacklist data exchange request automatically responds, attempts to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.
  • Step S706 assigning respective responsibilities to each of the sub-nodes according to the monitoring result.
  • the application server 2 configures the sub-node that issues the blacklist data exchange request as the data requester, configures the sub-node that agrees to the blacklist data exchange request as the data provider, and does not issue the blacklist data exchange request and
  • the sub-nodes that answer or disagree with the blacklist data exchange request (or select one or more of them) are configured as supervisors.
  • Step S708 notifying the sub-nodes that do not participate in the current exchange as the supervisor, and verifying the exchange conditions of the exchange parties.
  • the supervisor may obtain blacklist data (that is, blacklist data uploaded by the data provider to the master node) provided by the data provider from the master node, and perform verification.
  • the exchange condition includes whether the blacklist data provided by the data provider conforms to the preset rule and whether the data requestor has a sufficient amount of transaction currency.
  • Step S710 notifying that the sub-nodes that exchange the condition check perform one-to-one data exchange.
  • the application server 2 notifies the data requester and the node of the data provider to start data exchange.
  • the data providing direction data requester shares its pre-stored blacklist data (synchronizes the related data to the data requester), and the data requester pays the data provider according to the exchange level corresponding to the node and the data amount of the blacklist data.
  • the application server 2 needs to calculate a transaction currency that the data requester needs to pay according to the exchange level of the data requester and the data volume of the blacklist data, and when the data requester successfully pays, the data provider is
  • the uploaded blacklist data is copied to the data requester.
  • the sub-node can acquire the transaction currency again by uploading new blacklist data.
  • the exchange level corresponding to the sub-node can be adjusted.
  • the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better.
  • Implementation Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种黑名单数据交换方法，应用于应用服务器，所述应用服务器为主节点，与多个分节点进行数据通信，该方法包括：监测所述分节点之间的黑名单数据交换请求和应答；根据监测结果为各个分节点分配相应的职责；通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验；通知通过交换条件校验的分节点一对一进行数据交换。本申请还提供一种应用服务器及计算机可读存储介质。本申请提供的黑名单数据交换方法、应用服务器及计算机可读存储介质能够利用基于区块链的智能合约技术进行黑名单数据交换及其管理。

Description

黑名单数据交换方法及应用服务器
本申请要求于2017年8月31日提交中国专利局、申请号为201710773975.1、发明名称为“黑名单数据交换方法及应用服务器”的中国专利申请的优先权，其全部内容通过引用结合在申请中。
技术领域
本申请涉及数据处理技术领域，尤其涉及一种黑名单数据交换方法及应用服务器。
背景技术
目前业界的黑名单交换分享，主要是数据存储中心单位利用各种运营方法，吸引外部机构向中心单位上传黑名单数据，然后由中心单位分享给其他的外部机构。外部机构对上传数据的用途没有控制，分享数据带来的有利规则因由中心单位运营定义显得不够可靠，因此外部机构上传交换数据的意愿很弱，数据孤岛很难打破。此外，中心单位收到的外部机构上传数据，其质量参差不齐，中心单位很难予以规范约束，导致数据后期处理的成本很高，对外分享再利用的代价很大。
发明内容
有鉴于此，本申请提出一种黑名单数据交换方法及应用服务器，以解决如何规范黑名单数据的交换和管理的问题。
首先，为实现上述目的，本申请提出一种黑名单数据交换方法，应用于应用服务器，所述应用服务器为主节点，与多个分节点进行数据通信，该方法包括步骤：
监测所述分节点之间的黑名单数据交换请求和应答；
根据监测结果为各个分节点分配相应的职责；
通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验；及
通知通过交换条件校验的分节点一对一进行数据交换。
可选地，该方法在进行监测之前还包括步骤：
对分节点上传的黑名单数据进行预校验；
根据预校验结果对所述分节点进行验真分级处理。
可选地，所述预校验过程为主节点根据预设规则验证所述黑名单数据是否符合要求，所述预设规则包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据。
可选地，所述验真分级处理为根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。
可选地，所述验真分级处理还包括：
设置当所述黑名单数据的规范度较高时，所述分节点以较少的交易币交换到较多的数据；
根据所述黑名单数据的数据量和预设比例为所述分节点分配对应数量的交易币。
可选地，所述根据监测结果为各个分节点分配相应的职责的步骤具体包括：
将发出黑名单数据交换请求的分节点配置为数据请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或所述应答中的反馈结果为不同意所述黑名单数据交换请求的分节点或者选取其中一个或多个配置为监督方。
可选地，所述交换条件包括数据提供方提供的黑名单数据是否符合所述 预设规则及数据请求方是否有足量的交易币，当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过。
可选地，所述通知通过交换条件校验的分节点一对一进行数据交换的步骤具体包括：
根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币；
当所述数据请求方支付成功后，将所述数据提供方上传的黑名单数据复制同步给所述数据请求方。
此外，为实现上述目的，本申请还提供一种应用服务器，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的黑名单数据交换系统，所述黑名单数据交换系统被所述处理器执行时实现如上述的黑名单数据交换方法的步骤。
进一步地，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有黑名单数据交换系统，所述黑名单数据交换系统可被至少一个处理器执行，以使所述至少一个处理器执行如上述的黑名单数据交换方法的步骤。
相较于现有技术，本申请所提出的黑名单数据交换方法、应用服务器及计算机可读存储介质，可以将一个中心单位作为区块链的主节点，其他合作机构作为分节点，利用基于区块链的智能合约技术进行黑名单数据交换及其管理。通过对分节点上传的黑名单数据进行预校验作验真分级处理，不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验，从而保证交换数据的真实合规。由于交换过程清晰透明，黑名单数据分享有利于每家机构的业务开展，打消合作机构上传数据的顾虑。中心单位可以为交换数据的质量保驾护航，建立数据生态圈。
附图说明
图1是本申请各个实施例一可选的应用环境示意图；
图2是图1中应用服务器一可选的硬件架构的示意图；
图3是本申请黑名单数据交换系统第一实施例的程序模块示意图；
图4是本申请黑名单数据交换系统第二实施例的程序模块示意图；
图5是本申请黑名单数据交换方法第一实施例的流程示意图；
图6是本申请黑名单数据交换方法第二实施例的流程示意图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
参阅图1所示，是本申请各个实施例一可选的应用环境示意图。
在本实施例中，本申请可应用于包括，但不仅限于，终端设备1、应用服务器2、网络3的应用环境中。所述应用服务器2、区块链网络3以及多个终端 设备1共同构成一个区块链网络系统，以进行黑名单数据的交换和管理。
其中，应用服务器2是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备，用于集中存储和管理待交换的黑名单数据，即为所述区块链网络系统的主节点。所述应用服务器2可以是计算机、也可以是单个网络服务器、多个网络服务器组成的服务器组或者基于云计算的由大量主机或者网络服务器构成的云。
区块链网络3用于在所述区块链网络系统中进行数据传输和交互。所述应用服务器2通过所述区块链网络3与多个终端设备1进行数据通信，该网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，GSM)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。
终端设备1用于相互之间进行所述黑名单数据的交换，为所述区块链网络系统的分节点。所述终端设备1可以是移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置、车载装置等等的可移动设备，以及诸如数字TV、台式计算机、笔记本、服务器等等的固定终端。
参阅图2所示，是图1中应用服务器2一可选的硬件架构的示意图。本实施例中，所述应用服务器2可包括，但不仅限于，可通过系统总线相互通信连接存储器11、处理器12、网络接口13。需要指出的是，图2仅示出了具有组件11-13的应用服务器2，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
其中，所述存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性 存储器、磁盘、光盘等。在一些实施例中，所述存储器11可以是所述应用服务器2的内部存储单元，例如该应用服务器2的硬盘或内存。在另一些实施例中，所述存储器11也可以是所述应用服务器2的外部存储设备，例如该应用服务器2上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器11还可以既包括所述应用服务器2的内部存储单元也包括其外部存储设备。本实施例中，所述存储器11通常用于存储安装于所述应用服务器2的操作系统和各类应用软件，例如黑名单数据交换系统200的程序代码等。此外，所述存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。
所述处理器12在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述应用服务器2的总体操作，例如执行与所述终端设备1进行数据交互或者通信相关的控制和处理等。本实施例中，所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据，例如运行所述的黑名单数据交换系统200等。
所述网络接口13可包括无线网络接口或有线网络接口，该网络接口13通常用于在所述应用服务器2与其他电子设备之间建立通信连接。本实施例中，所述网络接口13主要用于通过所述区块链网络3将所述应用服务器2与一个或多个所述终端设备1相连，在所述应用服务器2与所述一个或多个终端设备1之间的建立数据传输通道和通信连接。
至此，己经详细介绍了本申请各个实施例的应用环境和相关设备的硬件结构和功能。下面，将基于上述应用环境和相关设备，提出本申请的各个实施例。
首先，本申请提出一种黑名单数据交换系统200。
参阅图3所示，是本申请黑名单数据交换系统200第一实施例的程序模块图。
本实施例中，所述的黑名单数据交换系统200包括一系列的存储于存储器11上的计算机程序指令，当该计算机程序指令被处理器12执行时，可以实现本申请各实施例的黑名单数据交换操作。在进行黑名单数据交换的区块链中，将一个中心单位作为主节点，其他合作机构作为分节点。所述应用服务器2为进行黑名单数据交换的区块链中的一个中心单位，即主节点。所述多个终端设备1为进行黑名单数据交换的区块链中的其他合作机构，即分节点。利用基于区块链的智能合约技术，在各个节点之间按照约定的交换规则进行所述黑名单数据的交换和管理，保证整个数据交换过程公平透明，合作机构获取数据的过程规范合理。
在一些实施例中，基于该计算机程序指令各部分所实现的特定的操作，黑名单数据交换系统200可以被划分为一个或多个模块。例如，在图3中，所述黑名单数据交换系统200可以被分割成监测模块201、分配模块202、通知模块203。其中：
所述监测模块201，用于监测所述分节点之间的黑名单数据交换请求和应答。
具体地，每个有数据交换需求的分节点通过所述区块链网络3依次向其他分节点发出黑名单数据交换请求。所述请求中包括该次请求的标识、所请求的黑名单数据的信息、需求分节点的身份标识等。收到所述黑名单数据交换请求的分节点，根据自身需求和剩余交易币数量判断是否同意进行本次的黑名单数据交换，然后针对所述黑名单数据交换请求作出应答。所述应答中包括该次应答的标识、所对应的黑名单数据的信息、需求分节点的身份标识、应答分节点的身份标识、对该次请求的反馈结果等。所述反馈结果包括同意所述黑名单数据交换请求和不同意所述黑名单数据交换请求。所述反馈结果为不同意所述黑名单数据交换请求或未发出所述应答的分节点不参与本次数据交换。所述监测模块201可以监测各个分节点之间的请求和应答。收到黑名单数据交换请求的分节点自动响应，尝试和数据提供方开始数据交换，并向 其他分节点公开广播此次交换行为。
所述分配模块202，用于根据监测结果为各个分节点分配相应的职责。
例如，分配模块202将发出黑名单数据交换请求的分节点配置为数据请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或不同意所述黑名单数据交换请求的分节点(或者选取其中一个或多个)配置为监督方。
所述通知模块203，用于通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验。
具体地，在进行所述黑名单数据的交换之前，每个分节点会向主节点(所述应用服务器2)上传黑名单数据，同时主节点为会各个分节点分配一定数量的交易币(比特币)，用于后续进行交换。所述监督方可以从所述主节点中获取数据提供方提供的黑名单数据(即数据提供方上传至主节点的黑名单数据)，并进行校验。所述交换条件包括数据提供方提供的黑名单数据是否符合预设规则及数据请求方是否有足量的交易币。在本实施例中，所述预设规则可以包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据等。另外，根据所述黑名单数据的数据量和预设比例(数据量和交易币数量之间的比例)，数据请求方需要支付相应数量的交易币。当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过，本次交换才能继续进行。
所述通知模块203还用于通知通过交换条件校验的分节点一对一进行数据交换。
具体地，当交换双方的交换条件均校验通过后，所述通知模块203通知数据请求方和数据提供方的分节点开始进行数据交换。数据提供方向数据请求方分享其预先存储的黑名单数据(将相关数据复制同步给数据请求方)，数据请求方根据该分节点对应的交换级别和该黑名单数据的数据量向数据提供方 支付相应数量的交易币。通知模块203需要根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币，当所述数据请求方支付成功后，将所述数据提供方上传的该黑名单数据复制同步给所述数据请求方。
参阅图4所示，是本申请黑名单数据交换系统200第二实施例的程序模块图。本实施例中，所述的黑名单数据交换系统200包括一系列的存储于存储器11上的计算机程序指令，当该计算机程序指令被处理器12执行时，可以实现本申请各实施例的黑名单数据交换操作。在进行黑名单数据交换的区块链中，将一个中心单位作为主节点，其他合作机构作为分节点。所述应用服务器2为进行黑名单数据交换的区块链中的一个中心单位，即主节点。所述多个终端设备1为进行黑名单数据交换的区块链中的其他合作机构，即分节点。
本实施例中，所述的黑名单数据交换系统200除了包括第一实施例中的所述监测模块201、分配模块202、通知模块203之外，还包括预校验模块204和分级模块205。
所述预校验模块204用于对分节点上传的黑名单数据进行预校验。
具体地，当一个分节点向主节点(所述应用服务器2)上传黑名单数据时，与所述主节点进行预校验。所述预校验过程为预校验模块204根据预设规则验证所述黑名单数据是否符合要求。在本实施例中，所述预设规则可以包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据等。
所述分级模块205用于根据预校验结果对所述分节点进行验真分级处理。
具体地，分级模块205根据对所述黑名单数据的验证结果，对其进行验真分级处理，主要是根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。例如当所述黑名单数据的规范度较高时，所述分节点后续可以以较少的交易币交换到较多的数据。当所述黑名单数据验证通过后，所述主节点授权所述分节点可以进行黑名单数据交换，并根据所述黑名单数据的数据量和预设比例为所述 分节点分配对应数量的交易币。
此外，本申请还提出一种黑名单数据交换方法。
参阅图5所示，是本申请黑名单数据交换方法第一实施例的流程示意图。在进行黑名单数据交换的区块链中，将一个中心单位作为主节点，其他合作机构作为分节点。所述应用服务器2为进行黑名单数据交换的区块链中的一个中心单位，即主节点。所述多个终端设备1为进行黑名单数据交换的区块链中的其他合作机构，即分节点。利用基于区块链的智能合约技术，在各个节点之间按照约定的交换规则进行所述黑名单数据的交换和管理，保证整个数据交换过程公平透明，合作机构获取数据的过程规范合理。
在本实施例中，根据不同的需求，图5所示的流程图中的步骤的执行顺序可以改变，某些步骤可以省略。该方法包括以下步骤：
步骤S600，监测所述分节点之间的黑名单数据交换请求和应答。
具体地，每个有数据交换需求的分节点通过所述区块链网络3依次向其他分节点发出黑名单数据交换请求。所述请求中包括该次请求的标识、所请求的黑名单数据的信息、需求分节点的身份标识等。收到所述黑名单数据交换请求的分节点，根据自身需求和剩余交易币数量判断是否同意进行本次的黑名单数据交换，然后针对所述黑名单数据交换请求作出应答。所述应答中包括该次应答的标识、所对应的黑名单数据的信息、需求分节点的身份标识、应答分节点的身份标识、对该次请求的反馈结果等。所述反馈结果包括同意所述黑名单数据交换请求和不同意所述黑名单数据交换请求。所述反馈结果为不同意所述黑名单数据交换请求或未发出所述应答的分节点不参与本次数据交换。作为主节点的所述应用服务器2可以监测各个分节点之间的请求和应答。收到黑名单数据交换请求的分节点自动响应，尝试和数据提供方开始数据交换，并向其他分节点公开广播此次交换行为。
步骤S602，根据监测结果为各个分节点分配相应的职责。
例如，所述应用服务器2将发出黑名单数据交换请求的分节点配置为数据 请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或不同意所述黑名单数据交换请求的分节点(或者选取其中一个或多个)配置为监督方。
步骤S604，通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验。
具体地，在进行所述黑名单数据的交换之前，每个分节点会向主节点(所述应用服务器2)上传黑名单数据，同时主节点为会各个分节点分配一定数量的交易币(比特币)，用于后续进行交换。所述监督方可以从所述主节点中获取数据提供方提供的黑名单数据(即数据提供方上传至主节点的黑名单数据)，并进行校验。所述交换条件包括数据提供方提供的黑名单数据是否符合预设规则及数据请求方是否有足量的交易币。在本实施例中，所述预设规则可以包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据等。另外，根据所述黑名单数据的数据量和预设比例(数据量和交易币数量之间的比例)，数据请求方需要支付相应数量的交易币。当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过，本次交换才能继续进行。
步骤S606，通知通过交换条件校验的分节点一对一进行数据交换。
具体地，当交换双方的交换条件均校验通过后，所述应用服务器2通知数据请求方和数据提供方的分节点开始进行数据交换。数据提供方向数据请求方分享其预先存储的黑名单数据(将相关数据复制同步给数据请求方)，数据请求方根据该分节点对应的交换级别和该黑名单数据的数据量向数据提供方支付相应数量的交易币。所述应用服务器2需要根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币，当所述数据请求方支付成功后，将所述数据提供方上传的该黑名单数据复制同步给所述数据请求方。
当所述交易币用完之后，分节点可以通过上传新的黑名单数据再次获取交易币。
如图6所示，是本申请黑名单数据交换方法的第二实施例的流程示意图。本实施例中，所述黑名单数据交换方法的步骤S704-S710与第一实施例的步骤S600-S606相类似，区别在于该方法还包括步骤S700-S702。
该方法包括以下步骤：
步骤S700，对分节点上传的黑名单数据进行预校验。
具体地，当一个分节点向主节点(所述应用服务器2)上传黑名单数据时，与所述主节点进行预校验。所述预校验过程为主节点根据预设规则验证所述黑名单数据是否符合要求。在本实施例中，所述预设规则可以包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据等。
步骤S702，根据预校验结果对所述分节点进行验真分级处理。
具体地，所述主节点根据对所述黑名单数据的验证结果，对其进行验真分级处理，主要是根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。例如当所述黑名单数据的规范度较高时，所述分节点后续可以以较少的交易币交换到较多的数据。当所述黑名单数据验证通过后，所述主节点授权所述分节点可以进行黑名单数据交换，并根据所述黑名单数据的数据量和预设比例为所述分节点分配对应数量的交易币。
步骤S704，监测所述分节点之间的黑名单数据交换请求和应答。
具体地，每个有数据交换需求的所述分节点通过所述区块链网络3依次向其他分节点发出黑名单数据交换请求。所述请求中包括该次请求的标识、所请求的黑名单数据的信息、需求分节点的身份标识等。收到所述黑名单数据交换请求的分节点，根据自身需求和剩余交易币数量判断是否同意进行本次的黑名单数据交换，然后针对所述黑名单数据交换请求作出应答。所述应答中包括该次应答的标识、所对应的黑名单数据的信息、需求分节点的身份标 识、应答分节点的身份标识、对该次请求的反馈结果等。所述反馈结果包括同意所述黑名单数据交换请求和不同意所述黑名单数据交换请求。所述反馈结果为不同意所述黑名单数据交换请求或未发出所述应答的分节点不参与本次数据交换。作为主节点的所述应用服务器2可以监测各个分节点之间的请求和应答。收到黑名单数据交换请求的分节点自动响应，尝试和数据提供方开始数据交换，并向其他分节点公开广播此次交换行为。
步骤S706，根据监测结果为各个分节点分配相应的职责。
例如，所述应用服务器2将发出黑名单数据交换请求的分节点配置为数据请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或不同意所述黑名单数据交换请求的分节点(或者选取其中一个或多个)配置为监督方。
步骤S708，通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验。
具体地，所述监督方可以从所述主节点中获取数据提供方提供的黑名单数据(即数据提供方上传至主节点的黑名单数据)，并进行校验。所述交换条件包括数据提供方提供的黑名单数据是否符合所述预设规则及数据请求方是否有足量的交易币。当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过，本次交换才能继续进行。
步骤S710，通知通过交换条件校验的分节点一对一进行数据交换。
具体地，当交换双方的交换条件均校验通过后，所述应用服务器2通知数据请求方和数据提供方的分节点开始进行数据交换。数据提供方向数据请求方分享其预先存储的黑名单数据(将相关数据复制同步给数据请求方)，数据请求方根据该分节点对应的交换级别和该黑名单数据的数据量向数据提供方支付相应数量的交易币。所述应用服务器2需要根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币，当所述数 据请求方支付成功后，将所述数据提供方上传的该黑名单数据复制同步给所述数据请求方。
当所述交易币用完之后，分节点可以通过上传新的黑名单数据再次获取交易币。
另外，根据分节点后续上传的黑名单数据的预校验情况和数据交换过程中的表现，可以调整该分节点对应的交换级别。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (20)

  1. 一种黑名单数据交换方法，应用于应用服务器，所述应用服务器为主节点，与多个分节点进行数据通信，所述方法包括步骤：
    监测所述分节点之间的黑名单数据交换请求和应答；
    根据监测结果为各个分节点分配相应的职责；
    通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验；及
    通知通过交换条件校验的分节点一对一进行数据交换。
  2. 如权利要求1所述的黑名单数据交换方法，其特征在于，该方法在进行监测之前还包括步骤：
    对分节点上传的黑名单数据进行预校验；
    根据预校验结果对所述分节点进行验真分级处理。
  3. 如权利要求2所述的黑名单数据交换方法，其特征在于，所述预校验过程为主节点根据预设规则验证所述黑名单数据是否符合要求，所述预设规则包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据。
  4. 如权利要求2所述的黑名单数据交换方法，其特征在于，所述验真分级处理为根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。
  5. 如权利要求4所述的黑名单数据交换方法，其特征在于，所述验真分级处理还包括：
    设置当所述黑名单数据的规范度较高时，所述分节点以较少的交易币交 换到较多的数据；
    根据所述黑名单数据的数据量和预设比例为所述分节点分配对应数量的交易币。
  6. 如权利要求2所述的黑名单数据交换方法，其特征在于，所述根据监测结果为各个分节点分配相应的职责的步骤具体包括：
    将发出黑名单数据交换请求的分节点配置为数据请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或所述应答中的反馈结果为不同意所述黑名单数据交换请求的分节点或者选取其中一个或多个配置为监督方。
  7. 如权利要求3所述的黑名单数据交换方法，其特征在于，所述交换条件包括数据提供方提供的黑名单数据是否符合所述预设规则及数据请求方是否有足量的交易币，当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过。
  8. 如权利要求2所述的黑名单数据交换方法，其特征在于，所述通知通过交换条件校验的分节点一对一进行数据交换的步骤具体包括：
    根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币；
    当所述数据请求方支付成功后，将所述数据提供方上传的黑名单数据复制同步给所述数据请求方。
  9. 一种应用服务器，其特征在于，所述应用服务器为主节点，与多个分节点进行数据通信，所述应用服务器包括存储器、处理器及存储在所述存储 器上并可在所述处理器上运行的黑名单数据交换系统，所述黑名单数据交换系统被所述处理器执行时实现如下步骤：
    监测所述分节点之间的黑名单数据交换请求和应答；
    根据监测结果为各个分节点分配相应的职责；
    通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验；及
    通知通过交换条件校验的分节点一对一进行数据交换。
  10. 如权利要求9所述的应用服务器，其特征在于，所述黑名单数据交换系统被所述处理器执行时，在进行监测之前还包括步骤：
    对分节点上传的黑名单数据进行预校验；
    根据预校验结果对所述分节点进行验真分级处理。
  11. 如权利要求10所述的应用服务器，其特征在于，所述预校验过程为主节点根据预设规则验证所述黑名单数据是否符合要求，所述预设规则包括：数据格式正确、不能写入用户隐私，不能有重复、缺失、虚假数据。
  12. 如权利要求10所述的应用服务器，其特征在于，所述验真分级处理为根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。
  13. 如权利要求12所述的应用服务器，其特征在于，所述验真分级处理还包括：
    设置当所述黑名单数据的规范度较高时，所述分节点以较少的交易币交换到较多的数据；
    根据所述黑名单数据的数据量和预设比例为所述分节点分配对应数量的 交易币。
  14. 如权利要求10所述的应用服务器，其特征在于，所述根据监测结果为各个分节点分配相应的职责的步骤具体包括：
    将发出黑名单数据交换请求的分节点配置为数据请求方，将同意所述黑名单数据交换请求的分节点配置为数据提供方，将未发出黑名单数据交换请求和应答或所述应答中的反馈结果为不同意所述黑名单数据交换请求的分节点或者选取其中一个或多个配置为监督方。
  15. 如权利要求11所述的应用服务器，其特征在于，所述交换条件包括数据提供方提供的黑名单数据是否符合所述预设规则及数据请求方是否有足量的交易币，当交换双方均达到交换条件，即数据提供方提供的黑名单数据符合所述预设规则且数据请求方有与所述黑名单数据对应的足量的交易币时，表示校验通过。
  16. 如权利要求10所述的应用服务器，其特征在于，所述通知通过交换条件校验的分节点一对一进行数据交换的步骤具体包括：
    根据所述数据请求方的交换级别和黑名单数据的数据量计算所述数据请求方需要支付的交易币；
    当所述数据请求方支付成功后，将所述数据提供方上传的黑名单数据复制同步给所述数据请求方。
  17. 一种计算机可读存储介质，所述计算机可读存储介质存储有黑名单数据交换系统，所述黑名单数据交换系统可被至少一个处理器执行，以使所述至少一个处理器执行如下步骤：
    监测分节点之间的黑名单数据交换请求和应答；
    根据监测结果为各个分节点分配相应的职责；
    通知不参与本次交换的分节点作为监督方，对交换双方的交换条件进行校验；及
    通知通过交换条件校验的分节点一对一进行数据交换。
  18. 如权利要求17所述的计算机可读存储介质，其特征在于，所述黑名单数据交换系统被所述处理器执行时，在进行监测之前还包括步骤：
    对分节点上传的黑名单数据进行预校验；
    根据预校验结果对所述分节点进行验真分级处理。
  19. 如权利要求18所述的计算机可读存储介质，其特征在于，所述验真分级处理为根据所述黑名单数据的规范度为对应的所述分节点设置对应的交换级别，然后向所述分节点进行授权和分配相应的交易币。
  20. 如权利要求19所述的计算机可读存储介质，其特征在于，所述验真分级处理还包括：
    设置当所述黑名单数据的规范度较高时，所述分节点以较少的交易币交换到较多的数据；
    根据所述黑名单数据的数据量和预设比例为所述分节点分配对应数量的交易币。
PCT/CN2018/101265 2017-08-31 2018-08-20 黑名单数据交换方法及应用服务器 Ceased WO2019042176A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710773975.1A CN107896157B (zh) 2017-08-31 2017-08-31 黑名单数据交换方法及应用服务器
CN201710773975.1 2017-08-31

Publications (1)

Publication Number Publication Date
WO2019042176A1 true WO2019042176A1 (zh) 2019-03-07

Family

ID=61803438

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/101265 Ceased WO2019042176A1 (zh) 2017-08-31 2018-08-20 黑名单数据交换方法及应用服务器

Country Status (2)

Country Link
CN (1) CN107896157B (zh)
WO (1) WO2019042176A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110533286A (zh) * 2019-07-23 2019-12-03 平安科技（深圳）有限公司 基于区块链的联盟成员管理方法、装置以及计算机设备
CN111221903A (zh) * 2019-12-18 2020-06-02 中思博安科技（北京）有限公司 数据追责方法、系统和计算机存储介质
CN111694899A (zh) * 2020-06-12 2020-09-22 中国银行股份有限公司 一种基于区块链的黑名单共享方法及系统

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107896157B (zh) * 2017-08-31 2020-11-03 深圳壹账通智能科技有限公司 黑名单数据交换方法及应用服务器
CN110532786A (zh) * 2018-05-23 2019-12-03 深圳崀途科技有限公司 采用哈希脱敏处理的区块链黑名单共享方法
CN109858272A (zh) * 2018-05-23 2019-06-07 深圳崀途科技有限公司 基于区块链的黑名单数据处理系统
CN109496406A (zh) * 2018-07-27 2019-03-19 袁振南 基于区块链系统的节点管理方法、装置和存储介质
WO2020019343A1 (zh) * 2018-07-27 2020-01-30 袁振南 区块链系统中的消息传输方法、装置及存储介质
CN111385322B (zh) * 2018-12-28 2023-11-21 中国移动通信集团山西有限公司 黑名单号码共享系统、方法、装置、设备及存储介质
CN109803023A (zh) * 2019-01-31 2019-05-24 北京融链科技有限公司 数据处理方法及系统
CN110032573A (zh) * 2019-03-26 2019-07-19 中山大学 一种基于区块链的黑名单共享方法、仲裁方法及装置
CN110413853A (zh) * 2019-07-22 2019-11-05 中国气象局气象探测中心 一种基于观测数据的黑名单生成方法、装置、设备及介质
CN111768294B (zh) * 2020-06-29 2023-08-29 中国银行股份有限公司 一种收费名单处理方法、装置及系统
CN114328413A (zh) * 2021-12-30 2022-04-12 中国民航信息网络股份有限公司 数据处理方法及装置、存储介质及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101252506A (zh) * 2007-12-29 2008-08-27 中国建设银行股份有限公司 一种数据传输系统
US20160191540A1 (en) * 2014-12-30 2016-06-30 International Business Machines Corporation Authentication based on proximate devices
CN106651346A (zh) * 2016-11-28 2017-05-10 上海凯岸信息科技有限公司 基于区块链的征信数据共享与交易系统
CN107896157A (zh) * 2017-08-31 2018-04-10 上海壹账通金融科技有限公司 黑名单数据交换方法及应用服务器

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106097006A (zh) * 2016-06-09 2016-11-09 杭州复杂美科技有限公司 区块链计费模式
CN106897902A (zh) * 2017-02-21 2017-06-27 中链科技有限公司 基于区块链技术的服务交易方法、系统和交易服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101252506A (zh) * 2007-12-29 2008-08-27 中国建设银行股份有限公司 一种数据传输系统
US20160191540A1 (en) * 2014-12-30 2016-06-30 International Business Machines Corporation Authentication based on proximate devices
CN106651346A (zh) * 2016-11-28 2017-05-10 上海凯岸信息科技有限公司 基于区块链的征信数据共享与交易系统
CN107896157A (zh) * 2017-08-31 2018-04-10 上海壹账通金融科技有限公司 黑名单数据交换方法及应用服务器

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110533286A (zh) * 2019-07-23 2019-12-03 平安科技（深圳）有限公司 基于区块链的联盟成员管理方法、装置以及计算机设备
CN110533286B (zh) * 2019-07-23 2023-04-18 平安科技（深圳）有限公司 基于区块链的联盟成员管理方法、装置以及计算机设备
CN111221903A (zh) * 2019-12-18 2020-06-02 中思博安科技（北京）有限公司 数据追责方法、系统和计算机存储介质
CN111694899A (zh) * 2020-06-12 2020-09-22 中国银行股份有限公司 一种基于区块链的黑名单共享方法及系统

Also Published As

Publication number Publication date
CN107896157A (zh) 2018-04-10
CN107896157B (zh) 2020-11-03

Similar Documents

Publication Publication Date Title
WO2019042176A1 (zh) 黑名单数据交换方法及应用服务器
CN112153085B (zh) 一种数据处理方法、节点及区块链系统
US20200320220A1 (en) Personal Data Management System
WO2019024161A1 (zh) 基于区块链的数据管理方法、区块链系统、服务器及可读存储介质
WO2020057016A1 (zh) 基于区块链的保险理赔方法、电子装置及存储介质
CN113064744B (zh) 任务处理方法、装置、计算机可读介质及电子设备
WO2019011179A1 (zh) 证书管理方法、系统、网络设备及计算机可读存储介质
CN110599275B (zh) 一种基于区块链网络的数据处理方法、装置及存储介质
CN113761552B (zh) 一种访问控制方法、装置、系统、服务器和存储介质
CN108171083A (zh) 区块链可信数据管理方法、系统及计算机可读存储介质
US11770456B1 (en) System and method for distributed management of storage systems based on subscription changes
CN107430666A (zh) 租户锁箱
WO2020119536A1 (zh) 联盟链信息发布控制方法及终端设备
US11831706B1 (en) System and method for distributed management of storage systems based on intent
CN109669955A (zh) 一种基于区块链的数字资产查询系统和方法
CN109299333B (zh) 区块链网络账本成员管理方法、装置、设备及存储介质
US12598187B2 (en) System and method for managing privileged account access
CN110516417A (zh) 一种智能合约的权限验证方法及装置
CN114331428A (zh) 一种非同质化通证分配方法及装置
US12309162B2 (en) System and method for distributed management of hardware with intermittent connectivity
KR101059058B1 (ko) 위치 기반 서비스 접근 제어 장치, 방법 및 시스템
TWI637339B (zh) 將電子購買之內容項目指派給使用者
CN116671060A (zh) 分散式广播加密和密钥生成设施
CN110662210B (zh) 基于区块链的二次或多次手机号的识别方法、系统及设备
US11929891B1 (en) System and method for distributed management of hardware through relationship management

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18851266

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08/09/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18851266

Country of ref document: EP

Kind code of ref document: A1