WO2023219478A1 - Method, system and non-transitory computer-readable recording medium for managing puzzled token - Google Patents

Abstract

According to an aspect of the present invention, provided is a method for managing a puzzled token, the method comprising the steps of: an issuer node allowing a puzzled token to be generated by combining personal information of an issuance requester node and allowing a unique identifier included in the puzzled token to be privately processed; and the issuance requester node allowing a public identifier to be generated on the basis of the privately processed unique identifier and allowing a token in which the unique identifier has been replaced with the public identifier in the puzzled token to be used in a blockchain network.

Description

Method, system and non-transitory computer-readable recording medium for managing puzzled tokens

The present invention relates to a method, system, and non-transitory computer-readable recording medium for managing puzzled tokens.

Blockchain originated from a method of connecting blocks in Satoshi Nakamoto's Bitcoin: A Peer-to-Peer Electronic Cash System in 2008. Blockchain is a general term for a distributed database that shares data bound by hash links on a distributed network composed of multiple network nodes.

Data recorded on the blockchain is virtually impossible to forge or falsify, and anyone can verify data with guaranteed integrity by connecting to the blockchain, so it is being introduced into the field of data operation that requires reliability and transparency. It is becoming.

The purpose of the present invention is to build a DID (Decentralized Identity) solution based on a puzzled token generated by combining personal information of specific nodes that make up a blockchain network.

A representative configuration of the present invention to achieve the above object is as follows.

According to one aspect of the present invention, as a method for managing puzzled tokens, on the issuer node side, a puzzled token is generated by combining personal information of the issuance requester node, and the puzzled token included in the puzzled token is generated. causing a unique identifier to be deprived, and, on the issuance requester node side, causing a public identifier to be generated based on the deprived unique identifier, wherein the unique identifier is replaced with the public identifier in the puzzled token. A method is provided that includes steps for enabling it to be used in a blockchain network.

According to another aspect of the present invention, there is a system for managing puzzled tokens, wherein, on the issuer node side, a puzzled token is generated by combining the personal information of the issuance requester node, and the puzzled token included in the puzzled token is generated. An issuer node management unit that causes a unique identifier to be privately processed, and on the issuance requester node side, generate a public identifier based on the privately processed unique identifier, and replace the unique identifier with the public identifier in the puzzled token. A system is provided that includes an issuance requester node management unit that allows issued tokens to be used in a blockchain network.

In addition, another method for implementing the present invention, another system, and a non-transitory computer-readable recording medium for recording a computer program for executing the method are further provided.

According to the present invention, a DID (Decentralized Identity) solution can be built based on a puzzled token generated by combining personal information of specific nodes that make up a blockchain network.

Figure 1 is a diagram showing a schematic configuration of an entire system for managing puzzled tokens according to an embodiment of the present invention.

2A to 2C are diagrams for explaining a puzzled token according to an embodiment of the present invention.

Figure 3 is a diagram illustrating the management process of a puzzled token according to an embodiment of the present invention.

Figure 4 is a block diagram of a system for conducting a survey on a blockchain using a survey token according to some embodiments of the present invention.

Figure 5 is a data flow diagram illustrating a survey method performed on a blockchain using a survey token according to some embodiments of the present invention.

Figure 6 is a diagram for explaining survey initialization according to some embodiments of the present invention.

FIG. 7A is a diagram illustrating the creation of a survey token for a public survey according to some embodiments of the present invention.

FIG. 7B is a diagram illustrating the creation of a survey token for an anonymous survey according to some embodiments of the present invention.

FIG. 8A is a diagram illustrating the creation of a puzzled survey token for a public survey according to some embodiments of the present invention.

FIG. 8B is a diagram illustrating the creation of a puzzled survey token for an anonymous survey according to some embodiments of the present invention.

FIG. 9A is a diagram illustrating a respondent's immediate submission of answers included in a survey method according to some embodiments of the present invention.

FIG. 9B is a diagram for explaining a respondent's delayed response submission included in a survey method according to some embodiments of the present invention.

<Explanation of symbols>

100: Issuer

200: Issue requester (or responder)

300: Bender

400: Survey application

The detailed description of the present invention described below refers to the accompanying drawings, which show by way of example specific embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the present invention are different from one another but are not necessarily mutually exclusive. For example, specific shapes, structures and characteristics described herein may be implemented with changes from one embodiment to another without departing from the spirit and scope of the invention. Additionally, it should be understood that the location or arrangement of individual components within each embodiment may be changed without departing from the spirit and scope of the present invention. Accordingly, the detailed description described below is not to be taken in a limiting sense, and the scope of the present invention should be taken to encompass the scope claimed by the claims and all equivalents thereof. Like reference numbers in the drawings indicate identical or similar elements throughout various aspects.

Hereinafter, several preferred embodiments of the present invention will be described in detail with reference to the attached drawings in order to enable those skilled in the art to easily practice the present invention.

Configuration of the entire system

Figure 1 is a diagram showing a schematic configuration of an entire system for managing puzzled tokens according to an embodiment of the present invention.

As shown in FIG. 1, the entire system according to an embodiment of the present invention may be configured to include a communication network (not shown) and a plurality of nodes 100.

First, the communication network according to an embodiment of the present invention can be configured regardless of communication mode, such as wired communication or wireless communication, and can include a local area network (LAN), a metropolitan area network (MAN), and a wide area network. It can be composed of various communication networks such as a wide area network (WAN). Preferably, the communication network referred to in this specification may be the known Internet or World Wide Web (WWW). However, the communication network is not necessarily limited thereto and may include at least a portion of a known wired or wireless data communication network, a known telephone network, or a known wired or wireless television communication network.

For example, a communication network is a wireless data communication network, including radio frequency (RF) communication, WiFi communication, cellular (LTE, etc.) communication, and Bluetooth communication (more specifically, Bluetooth Low Energy (BLE) communication. )), it may be implemented at least in part of a conventional communication method such as infrared communication, ultrasonic communication, etc.

Next, a plurality of nodes 10 according to an embodiment of the present invention are contact points or connection points that can communicate with other nodes 10 through a communication network, such as servers, computers, laptops, smartphones, and tablet PCs. A physical node such as a digital device equipped with a memory means and a microprocessor equipped with computing power, or a logical node such as an application, a program module, a virtual machine, etc. (i.e. a virtual node) ) may be a concept that includes. For example, the plurality of nodes 10 according to an embodiment of the present invention may include a publisher node 100 and an issue requestor node 200, which will be described later. In some cases, in this specification, the issuer node 100 may be referred to as an issuer, etc., and the issuance requester node 200 may be referred to as an issuance requester, responder, etc.

Meanwhile, the plurality of nodes 10 according to an embodiment of the present invention may include a management system (not shown) according to the present invention in the form of program modules such as applications and widgets. Additionally, such program modules may be downloaded from an external application distribution server (not shown) or an external system (not shown).

A blockchain network (a blockchain network may be referred to as a blockchain in this specification) according to an embodiment of the present invention is stored on the network by a plurality of nodes 10 participating in the network. It may be a network that jointly verifies the information to be submitted, records and shares the verified information on the network, thereby securing the integrity and reliability of the above-recorded information without relying on an authorized third party. . For example, such a blockchain network may be a network that is at least partially similar to the characteristics of conventional blockchain networks such as Ethereum, Binance Smart Chain, and NiktoNet. In addition, according to an embodiment of the present invention, this blockchain network may be a private blockchain network, a public blockchain network, or a mixed network of private blockchain and public blockchain, etc. It may be a concept that includes various types of blockchain networks.

Next, the management system according to an embodiment of the present invention causes (a) the issuer node 100 to generate a puzzled token (T) by combining the personal information of the issuance requester node 200, A function to ensure that the unique identifier included in the puzzled token (T) is treated privately, (b) on the issuance requester node 200 side, to generate a public identifier based on the privately processed unique identifier, and to make the puzzled token (T) can perform functions such as allowing tokens whose unique identifiers are replaced with public identifiers to be used in the blockchain network. According to an embodiment of the present invention, the functions of the above management system may be performed based on at least one consensus algorithm operating on a blockchain network.

The configuration and functions of the management system according to the present invention will be discussed in detail through the detailed description below. Meanwhile, although the management system has been described as above, this description is illustrative, and at least some of the functions or components required for the management system are installed within the plurality of nodes 10 or an external system (not shown) as needed. It is obvious to those skilled in the art that it may be realized in or included in a plurality of nodes 10 or an external system. For example, according to one embodiment of the present invention, a user uses an application that includes at least some of the functions of the management system (or blockchain network) according to the present invention through his or her node, or uses the node to By accessing a website that provides at least some of the functions of the management system (or blockchain network) according to the present invention, the puzzled token (T) according to the present invention can be managed.

Configuration of the management system

Below, we will look at the functions of each component of the management system that performs important functions for implementing the present invention.

The management system according to an embodiment of the present invention may be configured to include a publisher node management unit and an issue requestor node management unit. According to one embodiment of the present invention, at least some of the issuer node management unit and the issue requestor node management unit may be program modules that communicate with an external system (not shown). These program modules may be included in the management system in the form of operating systems, application modules, or other program modules, and may be physically stored in various known storage devices. Additionally, these program modules may be stored in a remote storage device capable of communicating with the management system. Meanwhile, such program modules include, but are not limited to, routines, subroutines, programs, objects, components, data structures, etc. that perform specific tasks or execute specific abstract data types according to the present invention.

2A to 2C are diagrams for explaining a puzzled token according to an embodiment of the present invention.

Referring to FIG. 2A, the puzzled token (T) is attached to at least some of the personal information of the issuance requester 200, for example, personal identification data such as gender, age, country (or nationality), region, occupation, education, etc. It may be generated from the publisher 100 to include data selected for. The token created in this way can function as a type of NFT (Non Fungible Token) by becoming the unique token of the issuance requester 200.

For example, the puzzled token T may include data generated by assigning a code to the personal identification data of the issuance requester 200, as shown in FIG. 2B. When the issuance requester 200 provides personal information such as gender, age, nationality, region, occupation, and education to the issuer 100, the issuer 100 provides a code assigned to each information and a random number (Random No. .) can be given to generate a puzzled token (T) containing the combined personal identification data.

In some embodiments of the present invention, the issuer 100 may create an image file as data visualizing the puzzled token T. Referring to FIG. 2C, the issuer 100 creates a color table to correspond to the code assigned to information such as gender, age, and nationality provided by the issuance requester 200, and uses the puzzled token (T) as a personal identification. By dividing sectors to correspond to the type of data and filling the divided sectors with colors corresponding to the code, an image file as data in which the puzzled token (T) is visualized can be created.

For example, the puzzled token (T) can be divided into a plurality of sectors (t1 to t7) to correspond to six types of personal identification data and one arbitrary number. A plurality of sectors (t1 to t7) may be filled with personal identification data and a color corresponding to a code assigned to a random number and expressed as a visualized image.

However, the above visualization method is an example, and the puzzled token T may be expressed as an image through a visualization method different from that of FIGS. 2A and 2C in which the circle is divided equally. For example, the puzzled token (T) is expressed as an image by filling in color in the divided area to correspond to the code assigned to the personal identification data based on polygons, or to include an image file or shape corresponding to the assigned code. It can also be expressed.

Since the puzzled token (T) generated in this way contains the personal identification data of the issuance requester 200, it can be used in a system that requires user authentication for access or use by the issuance requester 200. For example, a puzzled token (T) can be issued as an individual's ID and password to access a service online, or it can be issued and used as a DID that includes a security key, ID card, and registration certificate for individual identification offline. there is.

Additionally, as will be explained later, the puzzled token (T) can also be used in a data collection process such as a survey in which the issuance requester 200 can participate.

Figure 3 is a diagram illustrating a management process (eg, generation and use process) of a puzzled token according to an embodiment of the present invention.

Referring to step S10, the issue requester node management unit may cause the personal information of the issue requester node 200 to be transmitted from the issue requester node 200 to the issuer node 100. At this time, the personal information of the issue requester node 200 transmitted to the issuer node 100 may include the signature of the issue requester node 200.

Referring to step S20, the issuer node management unit may generate a puzzled token (T) by combining the personal information of the issuance requester node 200 on the issuer node 100 side. Since the basic process of generating the puzzled token T has been described above with reference to FIGS. 2A to 2C, detailed description will be omitted.

Referring to step S30, the issuer node management unit may cause the puzzled token (T) to be recorded (or distributed) on the blockchain network on the issuer node 100 side. At this time, the puzzled token (T) may be encrypted based on a known encryption algorithm such as the RSA algorithm during the process of recording on the blockchain network.

Referring to step S40, the issuer node management unit may ensure that the unique identifier included in the puzzled token (T) is processed privately on the issuer node 100 side. The puzzled token (T) may further include a unique identifier generated based on the personal information of the issuance requester node 200 in addition to the personal information of the issuance requester node 200. This unique identifier may prove that the puzzled token (T) was created at the request of the issuing requester node (200) or that the puzzled token (T) is owned by the issuing requester node (200).

Referring to step S50, the issue requester node management unit may cause a public identifier to be generated based on a unique identifier that has been made private on the issue requester node 200 side. Specifically, the issuance requester node management unit may cause a public identifier to be individually generated according to the purpose of use of the puzzled token (T) on the issuance requester node 200 side. That is, the public identifier may be generated in different forms (e.g., different strings) depending on the purpose of use of the puzzled token (T). Meanwhile, one of the purposes of using the puzzled token (T) may include a survey conducted on a blockchain network, which will be described later.

Referring to step S60, the issuance requester node management unit may cause the unique identifier included in the puzzled token T to be replaced with a public identifier on the issuance requester node 200 side. In addition, the issuance requester node management unit may, on the issuance requester node 200 side, replace the unique identifier with a public identifier as described above so that the token containing the public identifier can be used in the blockchain network. Here, it should be noted that the token used in the blockchain network corresponds to a token containing a public identifier, not a token containing a unique identifier that has been made private. The crossed arrows in Figure 3 indicate that tokens containing private unique identifiers are not used in the blockchain network.

Referring to step S70, in response to the completion of use of the token including the public identifier in the blockchain network, a type of conversion (or processing) process may be performed on the token including the public identifier. For example, in response to the completion of the use of a token containing a public identifier in a blockchain network, the token containing the public identifier may be decombined with the personal information of the issuance requester node 200, and further be disclosed to the public. Identifiers may be incinerated. This conversion (or processing) process may be understood as a process in which the token itself, including the public identifier, is burned. Meanwhile, the individual personal information of the issuing requester node 200, whose combination has been released from the token containing the public identifier, can be stored as big data on the blockchain network.

Above, the management process (eg, creation and use process) of the puzzled token (T) was explained in detail with reference to FIG. 3. However, in the above-mentioned steps S10 to S70, it has been explained that certain functions are performed by the issuer node management unit and the issuance requester node management unit as the main subjects, but it may also be explained that each function is performed by the publisher node and the issuance requester node as the main subjects. It is self-evident that it exists. In addition, the order of steps S10 to S70 described above is not limited to that shown in the drawings, and the order may be changed within the scope of achieving the purpose of the present invention, and further, a plurality of steps may be combined with each other. It should be noted that the steps may be separated into multiple steps.

Figure 4 is a block diagram of a token usage system 1 on a blockchain in which combined information is stored according to some embodiments of the present invention (the system may be the same system as the management system or a system including the management system). The data collection process described below may refer to a survey conducted using a puzzled token (T) generated on a blockchain.

Referring to FIG. 4, the token use system 1 on a blockchain in which combined information is stored according to some embodiments of the present invention includes an issuer 100, a responder 200, a vendor 300, and a blockchain 500. It can be included. Here, the responder 200 may be understood to perform a similar function to the requester 200 for issuance of the puzzled token (T) described in FIGS. 2A to 2C.

The components described below, such as the issuer (100), respondent (200), and vendor (300), are blockchain technology such as smartphones, personal computers (PCs), server computers, tablet PCs, and hardware wallets. (500) may include a computing device capable of generating a survey or submitting answers.

The publisher 100 can manage the overall process of the survey 110 performed in the present invention. The publisher 100 may create a survey 110, authenticate respondents 200 who wish to participate in the survey, and aggregate the results of the survey 110.

The survey 110 generated by the issuer 100 may be defined to have various characteristics depending on its purpose. For example, the survey 110 may be an open survey or an anonymous survey, and may be an immediate answer submission that allows for immediate vote counting, or an encrypted answer that allows for delayed counting. It could be submission.

Additionally, the survey 110 may include only personal information for identification of the respondent 200, or may be a vote using a puzzled survey token containing metadata of the respondent 200. .

A puzzled survey token is a survey token that can be generated by the issuer 100 conducting the survey 110 by combining only the necessary information like a puzzle as described using FIGS. 2A to 2C. means. The respondent 200 can be certified based on information previously entered about the issuer 100 and receive a puzzle-shaped survey token. When the issuer (100) generates a puzzled survey token, it can be created by combining only the information needed among the personal information for respondent identification, so each respondent (200) who receives the puzzled survey token is unique. You will be provided with a token of At this time, the token provided to the respondent 200 may include an image file as visualized data as described in FIGS. 2A to 2C.

As described later, personal information combined to create a puzzled survey token may be encrypted.

Not only can the respondent (200) use the provided puzzled survey token to participate in the survey described below, but the respondent can also provide the puzzled survey token to a third party to establish the unique qualifications of the respondent (200). Alternatively, it can be used as a kind of ID that can verify your identity.

At this time, the puzzled survey token issued from the issuer 100 includes a code assigned to each piece of information and personal identification data combined by assigning a random number, but the issuance of such token is recorded in the blockchain 500. No personally identifiable data may be stored in blockchain data.

Specifically, the respondent 200 may participate in the survey by combining the puzzled survey token with personal information about the respondent 200 expressed as metadata along with the survey results. The issuer 100 can obtain more detailed results about the survey by analyzing the metadata along with the survey results included in the puzzled survey token. The metadata provided by the respondent 200 may be generated in the form of personal identification data that is combined by assigning a code assigned to each piece of information and a random number.

The issuer 100 may generate a private key (Priv _I ), a public key (Pub _I ), etc. unique to the issuer. As described later, if the survey token 120 used in the survey 110 is a puzzled survey token, the issuer 100 provides a symmetric key (Key) for encrypting and decrypting the puzzled survey token. _I ) and a pair of keys (Enc _M , Dec _M ) required for encryption and decryption of the metadata included therein can be generated.

The publisher 100 verifies the qualifications of the respondent 200 in response to a request for participation in a survey containing personally identifiable data or metadata from the respondent 200, and sends a request to the respondent 200 who successfully passes the verification. A survey token 120 may be provided.

In this process, one or more signatures can be created using the key to generate the survey token 120, etc.

In addition, the issuer 100 announces the start and end of the survey 110, or collects valid transactions for the survey results recorded in the form of transactions on the blockchain 500 and posts them on the blockchain. A compilation of surveys can be performed.

The respondent 200 may provide a request to participate in a survey containing personal identification data or metadata to the issuer 100 and perform a survey using the survey token 120 provided in response to the request. The survey can be performed by recording a transaction on the blockchain to transmit the survey token 120 to an address on the blockchain 500.

In the embodiment of FIG. 4 , the respondent 200 is exemplarily shown using the survey application 400 to perform the survey 110 . The survey application 400 may include an application program run on a computing device such as a smartphone, tablet PC, desktop computer, or laptop computer to conduct the survey 110 and submit answers, but the present invention is not limited to this. It doesn't work.

Although FIG. 4 shows that the token usage system 1 on the blockchain in which the combined information is stored includes one responder 200, the present invention is not limited thereto. Of course, in order to meet the purpose of the survey conducted by the system 1, a survey can be conducted on a plurality of respondents 200.

Additionally, the respondent 200 may present evidence of participation in the survey to the vendor 300, and upon completion of verification of the evidence, receive the provided compensation and store it. The vendor 300 may verify the claim for compensation provided by the respondent 200 and, if the claim is valid, provide the compensation to the wallet address of the respondent 200 or the address specified in the claim.

The blockchain 500 may include a network established by connecting nodes composed of a plurality of computing devices. A plurality of nodes constituting the blockchain 500 can mutually verify transactions or smart contracts executed to proceed and record the entire survey process. The blockchain 500 may record the answers of the survey 110 created by the issuer 100, the answers of the survey created by the respondent 200, and the results of aggregating the answers.

Figure 5 is a data flow diagram illustrating a method of using tokens on a blockchain where combined information is stored according to some embodiments of the present invention.

Referring to FIG. 5, the method of using a token on a blockchain storing combined information according to some embodiments of the present invention includes a step in which a survey is created and announced by the issuer 100 (S110), and the respondent 200 is an individual. A step of registering for a survey on the issuer 100 using identification data or metadata (S120), the issuer 100 verifies the qualifications of the respondent 200, and as a result of the verification, the respondent 200 is valid. If qualified, a survey token is generated and provided to the respondent 200 (S130); a survey answer is submitted to the blockchain 500 using the survey token from the respondent 200 (S140); The issuer 100 aggregates the survey answers recorded on the blockchain 500 (S150), and the issuer 100 records the survey results on the blockchain 500 based on the aggregated survey answers. Step (S160), step (S170) in which the respondent (200) provides evidence of survey participation to the vendor (300), step (S170) in which the vendor (300) verifies the evidence of survey participation and provides compensation to the respondent's wallet on the blockchain (S180) and the like. Each step of the data collection method according to an embodiment of the present invention will be described with reference to the drawings below.

Figure 6 is a diagram for explaining survey initialization according to some embodiments of the present invention.

Referring to FIG. 6, the publisher 100 can initialize the survey by creating and announcing the survey 110. Issuer 100 may generate one or more public key and private key pairs (Pub _I , Priv _I ) to be used for signing survey tokens 120.

In addition, as described later, if the survey token 120 is a puzzled survey token containing metadata of the respondent 200, a key (Key _I ) for encrypting and decrypting the puzzled survey token can be created. The key (Key _I ) may be used in a symmetric key encryption algorithm, and this algorithm may include an Advanced Encryption Standard (AES) algorithm, but the present invention is not limited thereto.

The publisher 100 may declare an identifier (SurveyID) to identify the survey to create the survey 110. The identifier (SurveyID) may include, for example, a hash of the string included in the string identifier of the survey, and the algorithm for calculating the hash may include, for example, SHA-2, SHA-3, etc., but according to the present invention This is not limited to this.

Survey 110 generated from publisher 100 may include, for example, JSON, YAML, TOML, XML, or a structured document in a format that can be processed by survey app 400. These documents may contain at least one question. Additionally, the survey 110 may include contact point information through which respondents wishing to participate access to request a survey token along with personal data, etc.

Additionally, the survey 110 may include a structured query document (RespondentDoc) that can record personal information (described below as metadata) about the respondent 200. When the survey 110 including the document (RespondentDoc) is provided to the respondent 200 from the publisher 100, the respondent 200 can generate metadata by filling out the form of the document (RespondentDoc). The metadata may include various questions regarding personal information, such as the respondent 200's age, region of birth, and gender, for example.

At this time, the issuer 100 may impose certain conditions on eligibility for participation in the survey 110. For example, restrictions on specific gender, age group, residential area, etc. are added, and when a survey token containing metadata is provided from the respondent 200, the response results are filtered according to the above certain conditions, and the survey is aggregated. Available.

The publisher 100 may create the survey 110 and define the research method of the survey 110. Survey 110 may, for example, be a public survey where the identity of the respondent 200 is disclosed and the answers can be tracked, or it may include an anonymous survey where the respondent cannot be traced.

Additionally, the publisher 100 may specify the aggregation method of the survey 110 along with the creation of the survey 110. Aggregation of responses in the survey 110 may include immediate aggregation, which is tallied immediately after submission by the respondent 200, and delayed aggregation, which can be confirmed only after response submission by all respondents 200 is completed.

If the survey 110 aggregates answers by delayed aggregation, the respondent 200 may generate a key pair (Enc _I , Dec _I ) to encrypt the answer of the respondent 200.

The publisher 100 can announce the survey 110 by completing the creation of the survey 110 and recording the generated survey 110 in the blockchain 500. The survey 110 recorded in the blockchain 500 may be made public and accessible to any respondent.

In some embodiments of the present invention, before the survey 110 is created by the issuer 100, an unspecified number of participants who are the subject of the survey 110, that is, respondents who can receive a survey token ( 200) Certain information may be provided from the candidate. The provided information on the candidate respondents (200) can be used to verify respondent qualifications when the respondent (200) provides a request to participate in a survey for the issuer (100).

FIG. 7A is a diagram illustrating the creation of a survey token for a public survey according to some embodiments of the present invention.

Referring to FIG. 7A, the respondent 200 recognizes the survey 110 generated by the issuer 100, provides a survey participation request to the issuer 100 for the public survey, and verifies respondent qualifications. When this is completed, a survey token is shown being provided to the respondent 200.

The respondent 200 can extract contact information that can access the issuer 100 from the survey 110 recorded in the blockchain 500. Through the contact information, the respondent 200 can request a survey token 120 from the issuer 100 by transmitting personal data and hashes. Meanwhile, before requesting the survey token 120, the respondent 200 may create a wallet address on the blockchain 500 that is used as the origin address of the transaction. Afterwards, the vendor 300 can provide compensation for participating in the survey to the wallet address of the respondent 200.

Respondent 200 may generate a public key (Pub _V ) for verifying the transaction of the survey 110 and a private key (Priv _V ) used to sign the transaction of the survey 110. The public key (Pub _V ) and private key (Priv _V ) of the respondent 200 may match each other.

The respondent 200 may provide the issuer 100 with the respondent's public key (Pub _V ) along with personal identification data that can identify the respondent 200. In addition, the respondent 200 may sign a survey participation request including the personal identification data with the respondent's private key (Priv _V ) and provide it to the issuer 100.

The personal identification data of the respondent 200 may include, for example, the respondent 200's wallet address, affiliation, title, security level, etc.

The publisher 100, which has received a request to participate in a survey from the respondent 200, can check the personal identification data of the respondent 200 included in the request and evaluate the applicant's eligibility to participate in the survey. This evaluation may be based, for example, on whether the personal identification data of the respondent 200 matches the list of respondents pre-stored by the issuer 100, but the present invention is not limited thereto.

When the evaluation of the respondent 200 is completed, the issuer 100 may generate a survey token. The survey token (SurveyToken _I ) may contain the result of signing the hash of the respondent's public key (Pub _V ) with the issuer's private key (Priv _I ) (SurveyToken _I = Sign(hash(Pub _V ), Priv _I ). Here, Sign(bytes, privKey), which performs the operation of signing the byte string bytes with the private key privKey, is, for example, a Digital Signature Algorithm (DSA) signature, an Elliptic Curve Digital Signature Algorithm (ECDSA) signature, or Ed25519 or other known A digital signature algorithm can be used.

Additionally, the issuer 100 may generate a survey token by combining the previously provided personal identification data and metadata of the respondent 200. Tokens generated in this way may include the puzzled survey tokens described above.

The generated survey token 120 may be provided to the respondent 200 through blockchain. The respondent 200 may keep the token 120 provided for later steps without any further processing.

FIG. 7B is a diagram illustrating the creation of a survey token for an anonymous survey according to some embodiments of the present invention.

The anonymous survey illustrated in FIG. 7B includes a survey process in which the identity of the respondent 200 is not revealed even by the issuer 100. That is, the following will describe a series of processes in which the issuer 100 signs with its own private key and provides the information to the respondent 200 without knowing the information about the respondent's private key provided by the respondent 200.

Referring to FIG. 7b, the respondent 200 recognizes the survey 110 created by the publisher 100, provides a survey participation request to the publisher 100 for an anonymous survey, and verifies the respondent's qualifications. When this is completed, a survey token is shown being provided to the respondent 200. As will be explained later, when conducting an anonymous survey, unlike a public survey, separate steps may be additionally taken to prevent identification of respondents.

The respondent 200 extracting the contact information of the issuer 100 and generating the private key/public key (Priv _V , Pub _V ) may be the same as in the public survey described above.

Meanwhile, the respondent 200 may generate a blind hash of the respondent's public key and provide it to the issuer 100 along with the personal identification data of the respondent 200.

Specifically, the responder 200 may calculate the hash (hpk) of the responder's public key (Pub _V ) (hpk = hash(Pub _V )). In addition, the responder 200 can calculate the result (bpk) of blinding the hash (hpk) of the public key using the issuer's public key (Pub _I ) and a randomly generated nonce (bpk = Blind) (hpk, Pub _I , nonce)).

Here, blind may refer to a protocol that can safely sign a byte string without disclosing the contents of the byte string, such as Blind RSA signature. In such blind signing, the sender's message is blinded until the recipient signs, and the signing party does not know the contents of the message. The sender can obtain a properly signed message by unblinding the signed message.

Responder 200 may provide a blind hash (bpk) of the responder's public key along with the responder's personally identifiable data to issuer 100 over a secure communication channel. When the evaluation of the respondent 200 is completed, the issuer 100 may generate a survey token (SurveyToken _I ). The survey token (SurveyToken _I ) may include the result of RSA signing the provided blind hash (bpk) with the issuer's private key (Priv _I ) (SurveyToken _I = SignRSA(bpk, Priv _I )). Here, SignRSA(bytes, privKey), which performs the operation of RSA signing the byte string bytes with the private key privKey, operates on a large integer m obtained from an array of byte strings with the exponent e and modulo N (num(bytes)^e mod N) It can mean to do.

The respondent 200 can unblind the survey token (SurveyToken _I ) provided by the issuer. In other words, an unblinded survey token (SurveyTokne _V ) is created (SurveyToken _V = Unblind(SurveyToken _I , nonce)) using the nonce previously used to generate the blind hash (bpk) of the public key.

The key feature of the series of processes through the above blind and unblind operations is that the unblinded survey token (SurveyToken _V ) obtained by the respondent 200 is SignRSA(hash(Pub _V ), Priv _I ), that is, the respondent's public key. (Pub _V ) is identical to the issuer's signature. Thanks to the blind signing process, the publisher 100 signs without knowing the value of the responder's public key (Pub _V ). If the respondent 200 uses his or her own key (Priv _V ) to sign the survey transaction, no one, including the issuer 100, will be able to track the actual respondent.

FIG. 8A is a diagram illustrating the creation of a puzzled survey token for a public survey according to some embodiments of the present invention. The puzzled survey token described in FIGS. 8A and 8B below may refer to a survey token that includes some additional information, that is, metadata, about the respondent 200, such as age, region of origin, gender, etc. As the puzzled survey token includes such metadata, verifiable information about the respondent 200 can be provided to the issuer 100 without violating the personal information of the respondent 200. In other words, it is possible to conduct a survey based on the minimum personal information voluntarily provided by the respondent 200, and as explained later, personal information leakage is prevented by using metadata that only the issuer 100 can identify and decrypt. It is possible to secure data sovereignty of personal information subjects.

Metadata may be configured to include items included in documents in structured formats, such as JSON, YAML, TOML, XML, etc., and codes assigned to each item.

Metadata may be stored in an internal database of the publisher 100, and the internal database may include an EntryID to uniquely identify the stored metadata. Puzzled survey tokens may also contain an EntryID, or oeid, encrypted as an opaque reference to the corresponding metadata.

Referring to FIG. 8A, the respondent 200 recognizes the survey 110 generated by the issuer 100, provides a survey participation request to the issuer 100 for the public survey, and verifies respondent qualifications. Once this is completed, the puzzled survey token is shown being provided to the respondent 200.

If the survey 110 is a public survey, the respondent 200 may provide the publisher 100 with personal information that may be included in metadata along with personal data for identification. The publisher 100 may refer to the provided personal information to complete the metadata of the respondent 200 and store it in an internal database.

The respondent 200 can extract the contact information of the issuer 100 included in the survey 110 and complete a structured query document (RespondentDoc) in which personal information about the respondent 200 can be recorded.

The respondent (200) signs the request to participate in the survey with the respondent's private key (Priv _V ), along with his or her public key (PubV), a document (RespondentDoc) containing personal identification data, and metadata, and sends it to the publisher (100). can be provided to. As described above, metadata included in the document (RespondentDoc) may include codes assigned to each piece of information and data combined by assigning an arbitrary number.

The publisher 100 can check the personal data of the respondent 200 among the provided data and evaluate their eligibility to participate in the survey. In addition, the metadata of the respondent 200 may be stored in the internal database of the issuer 100 so that it can be identified with a unique EntryID.

The issuer 100 can generate an opaque metadata ID (oeid) by encrypting the EntryID (oeid = Enc(EntryID, Key _I ). Here, asymmetric encryption of the bytes string is calculated using the specified key. Enc(bytes, key) may include using a known encryption algorithm.

In addition, the issuer 100 signs the hash of the respondent's public key (Pub _V ) with the issuer's private key (Priv _I ) (sk = Sign(hash(Pub _V ), Priv _I ) to proceed with the public survey. The hash (hd) of the data structure of the puzzled survey key (sk) can be calculated (hd = hash(oeid || sk). Finally, the publisher 100 creates a pair of data containing the publisher's digital signature. You can create a puzzled survey token (PuzzSurveyToken _I ) containing (PuzzSurveyToken _I = [oeid, sk, Sign(hd, Priv _I ).

The issuer 100 can store the generated puzzled survey token (PuzzSurveyToken _I ) as the issuer's puzzled survey token (PuzzSurveyToken _V = PuzzSurveyToken _I ).

FIG. 8B is a diagram illustrating the creation of a puzzled survey token for an anonymous survey according to some embodiments of the present invention.

Using a hash blinded by the respondent 200 to conduct an anonymous survey using a puzzled survey token containing metadata is similar to the previous explanation using FIG. 7B.

Specifically, referring to FIG. 8B, the respondent 200 extracts the contact information of the publisher 100 included in the survey 110 and generates metadata (md) using personal information about the respondent 200. You can create it yourself. In other words, unlike the previous public survey in which the publisher 100 composed metadata from the personal information of the respondent 200, in the anonymous survey using a puzzled survey token, the respondent 200 composed his/her metadata (md ) can be created directly. The metadata (md) generated here may include a code assigned to each piece of information, as described above, and data combined by assigning an arbitrary number.

Subsequently, the respondent 200 may construct a Merkel tree (mt) using metadata (md) and the respondent's public key (Pub _V ) (mt = hash(hash(Pub _V ) || hash (md))). In other words, the respondent 200 constructs a Merkle tree (mt) by combining the hash of the respondent's public key (Pub _V ) and the hash of the metadata (md) into a hash.

The respondent 200 generates a value (bmt) by blinding the Merkle tree (mt) of the respondent's public key (Pub _V ) and metadata (md). Specifically, the respondent generates two random nonces (nonce1, nonce2), and uses the issuer's public key (Pub _I ) and the nonce (nonce1) to blind the hash (hpk) of the respondent's public key (bpk). ) can be calculated (bpk = Blind(hpk, Pub _I , nonce1).

Subsequently, the responder 200 can calculate the result (bmt) of blinding the Merkle tree root (mt) using the issuer's public key (Pub _I ) and nonce (nonce2) (bmt = Blind(mt, Pub _I , nonce2).

Responder 200 provides a package containing a blinded hash of the public key (bpk), a blinded Merkle tree root (bmt), metadata (md), and the respondent's personal data to publisher 100 over a secure communication channel. can do.

The publisher 100 may check the personally identifiable data of the respondent 200 and evaluate the qualifications of the respondent 200 by comparing it with the provided metadata (md). Once the qualifications of the respondent 200 are verified, the issuer 100 may issue a puzzled survey token (PuzzSurveyToken _I ) signed by the issuer and provide it to the respondent 200. The signed puzzled survey token (PuzzSurveyToken _I ) is generated using the issuer's private key (Priv _I ), respectively, through an RSA-signed hash (sbpk = SignRSA(bpk, Priv _I )) and a Merkle tree (sbmt = SignRSA(bmt, Priv _I )) and signed metadata (smd = Sign(hash(md), Priv _I )) and the signature of the above three values combined (Sign(hash(sbpk || sbmt || smd), Priv _I ) ) may include.

The respondent 200 may generate a puzzled survey token (PuzzSurveyToken _V ) using the puzzled survey token (PuzzSurveyToken _I ) signed by the issuer.

Specifically, the puzzled survey token (PuzzSurveyToken _V ) unblinds the hash (sbpk) of the RSA signed public key and the blind Merkle tree root (sbmt) using the nonce (nonce1, nonce2) used when blinding. The result (spk = Unblind(sbpk, nonce1), smt = Unblind(sbmt, nonce2)), the signed metadata (smd), and a random AES key for reading the metadata (Key _V ) are combined with the publisher's encryption key ( It can include the result of encryption with Enc _M ) (ekey = Enc(Key _V , Enc _M )) and the result of symmetric key encryption using an AES key (Key _V ) (emd = EncSym(md, Key _V )). there is.

What is noteworthy here is that the values of spk, smt, smd, ekey, emd of the puzzled survey token (PuzzSurveyToken _V ) generated by the respondent 200 are SignRSA(hpk, Priv _I ), SignRSA(mt, Priv _I ) and Sign(hash(md), Priv _I ) are encrypted metadata that only the issuer (100) can decrypt. That is, the signature of the respondent's public key by the issuer and the Merkle tree root of the public key combined with metadata are included in the puzzled survey token (PuzzSurveyToken _V ). Thanks to blind signing, the publisher 100 can sign the hashes of the public keys of the respondent and the publisher without knowing the data itself. Accordingly, if the respondent 200 signs the survey transaction with the respondent's private key (Priv _V ), no one can trace the actual respondent.

The rationale for metadata encryption is to keep the metadata private from external observers so that only the publisher 100 can access the metadata of the responder 200. To this end, the issuer 100 generates a result (key') of decrypting the ekey using the issuer's private key (Priv _I ) (key' = Dec(ekey, Priv _I )).

Subsequently, the publisher 100 generates a result (md') of decrypting the metadata using the decrypted key (key') (md' = DecSym(emd, key')).

The publisher 100 can verify the decrypted metadata (md'). Specifically, the issuer 100 sends smd (metadata (md) signed using the private key (Priv _I ) of the issuer's puzzled survey token (PuzzSurveyToken _I ) confirmed using the issuer's public key (Pub _I ). It is possible to verify whether the hash of ) matches the hash of the decrypted metadata (md') (Verify(hash(md'), smd, Pub _I ). If the verification result matches, the issuer 100 decrypts The metadata (md') can be stored in the internal database.

In summary, since there is no link that can connect from the respondent 200's public key (Pub _V ) to the actual respondent 200's personal information or metadata, the metadata (md') is anonymous, and the respondent 200 ) may not reveal information that can identify the person.

The respondent (200) can combine the answers of the survey into a structured document, sign the resulting data structure with a survey token (SurveyToken _V or PuzzSurveyToken _V ) attached, and record it as a transaction on the blockchain (500). there is. At this time, submission of responses can be classified into two types: immediate response submission that can be counted immediately after submission, or encrypted response submission that can be counted immediately.

FIG. 9A is a diagram illustrating a respondent's immediate response submission included in a method of using a token storing combined information according to some embodiments of the present invention.

Referring to FIG. 9A, the respondent 200 sends transaction data (VoteTx_Data) including a survey token (SurveyToken _V ) and a transaction (VoteTx) including the result of signing this with the respondent's private key (Priv _V ). can be created. The respondent 200 may provide a transaction (VoteTx) to the blockchain 500.

Meanwhile, transaction data (VoteTx_Data) may include answers to a survey, and the answers are a combination of codes assigned to each item and random numbers similar to the metadata of the respondent 200. You can have For example, answers are a combination of three survey questions 1 to 3, codes assigned to each survey answer item, and random numbers (for example, '0001 (number 1). 'answer to question 2)', '1100 (answer to question 2)', '0111 (answer to question 3)', '0001010 (random number)'). Additionally, answers included in transaction data (VoteTx_Data) can be expressed as an image file as visualized data. This is similar to the visualization of personally identifiable data or metadata of the puzzled token (T) described above, where the answers are represented as a visualized image by filling in the colors assigned to the answers and random numbers of survey items. You can.

Each node included in the blockchain 500 can verify the validity of the transaction (VoteTx) submitted by the respondent 200.

First, it can be confirmed whether a survey with an identifier (SurveyID) is currently in progress. If the transaction (VoteTx) is submitted ahead of the progress period or after the end of the progress period, the transaction (VoteTx) may be rejected.

In addition, whether the answers included in the transaction (VoteTx) correspond to the document (SurveyDoc) included in the survey 110 released by the respondent, and the public key (pk = Pub _V ) included in the transaction data (VoteTx_Data) It can be confirmed whether the signature of the transaction (VoteTx) can be verified (Verify(data, sign, pk)).

Alternatively, a process may proceed in which the public key (Pub _V ) of the respondent 200 is approved by the issuer 100. Specifically, in the case of a public survey, the survey token (SurveyToken _V ) is a signature of the hash of the respondent's public key (Pub _V ), so it can be verified by the public key (Pub _I ) announced by the issuer. For anonymous surveys, the survey token (SurveyToken _V ) may contain an RSA signature (SignRSA(hash(Pub _V ), Priv _I ) of the respondent's public key (Pub _V ) by the issuer's key (Priv _I) . , which can be verified by the issuer's public key (Pub _I ).

Finally, the transaction (VoteTx) must be the first transaction (VoteTx) signed by the respondent's private key (Priv _V ). If there is another transaction signed with the private key (Priv _V ) for the given survey identifier (SurveyID), it corresponds to double answering and may be rejected.

If the transaction (VoteTx) completes validation by the above-described procedure, the blockchain 500 can record the transaction (VoteTx).

FIG. 9B is a diagram for explaining a respondent's delayed response submission included in a survey method according to some embodiments of the present invention.

Referring to FIG. 9b, the respondent 200 receives encrypted transaction data (EncryptedVoteTx_Data) including a survey token (SurveyToken _V ) and the result of signing this with the respondent's private key (Priv _V ). A transaction (EncryptedVoteTx) can be created.

Here, the encrypted transaction data (EncryptedVoteTx_Data) may include the encrypted answer of the respondent 200. The respondent's answers may be included in the transaction data (EncryptedVoteTx_Data) encrypted by one of the key pairs (Enc _I , Dec _I ) generated from the issuer (100) in the survey creation stage to encrypt the answers (Enc _I ). there is. Once encrypted answers are submitted, delayed counting begins after the survey ends. As encrypted answers are submitted, the subjects involved in voting will not be able to know the counting status during voting.

The respondent 200 may provide an encrypted transaction (EncryptedVoteTx) to the blockchain 500.

Each node included in the blockchain 500 can verify the validity of the encrypted transaction (EncryptedVoteTx) submitted by the respondent 200. That is, the survey progress period, answer format, signature verification of the delayed transaction, approval by the issuer 100 of the respondent's public key (Pub _V ), which are the validation steps of the transaction (VoteTx) previously described using FIG. 9a, It can be verified whether the encrypted transaction (EncryptedVoteTx) is the first transaction signed with the respondent's private key (Priv _V ).

The issuer 100 may perform aggregation of the survey by tallying transactions of responses submitted by respondents 200 and recorded in the blockchain 500 (S150).

In the case of immediate response submission explained through FIG. 9A, when the survey progress period ends, the issuer 100 can count valid transactions and collect and process response documents included in the transactions.

In the case of delayed response submission explained through FIG. 9b, since the answer is encrypted by the key (Enc _I ), a procedure to decrypt it is necessary. When the survey period ends, the issuer 100 records another key (Dec _I ) on the blockchain 500 so that other participants with access to the blockchain 500 can decrypt the encrypted answers. . Other participants with access to the blockchain 500 can repeat all encrypted transactions (EncryptedVoteTx) in the blockchain and decrypt the encrypted answer document included in each transaction using the key (Dec _I ). The publisher 100 may collect decrypted response documents and generate aggregate results. The aggregate result may be signed by the issuer 100 and recorded in the blockchain 500 (S160).

Additionally, the issuer 100 may aggregate metadata included in the survey token, including the aggregate results collected through the decrypted response document. As described above, the issuer 100 can impose conditions on specific gender, age group, residential area, etc. when creating the survey 110, and can filter the survey results based on the above conditions when compiling the survey results. there is. In addition, the publisher (100) can separately aggregate the metadata of the respondents (200) who participated in the survey and use it as a type of big data. When analyzing the survey results, the information entered in advance by the participant is additionally used to provide more accurate respondent data. Analysis and survey results analysis can be performed.

The respondent 200 may present evidence of participation in the survey to the vendor 300 (S170). When a public survey is conducted, the respondent 200 sends the identifier (txID) generated by recording the survey transaction (VoteTx or DelayedVoteTx) to the blockchain 500 and a message signed with his or her private key (Priv _V ) to the vendor. It can be provided at (300). Vendor 300 can verify the signed message using respondent 200's public key (pk = Pub _V ) included in the survey transaction (VoteTx or DelayedVoteTx). Once verification is complete, the vendor 300 can transmit the reward to the wallet on the blockchain 500 linked to the user's public key (Pub _V ).

In the case of an anonymous survey, if the respondent 200 simply presents his or her public key (Pub _V ) and the survey transaction (VoteTx or DelayedVoteTx) to the vendor 300, a direct link is created between the respondent 200 and the answer. Because you are exposed, your anonymity may disappear. Therefore, a group signature can be used to ensure anonymity.

Group signatures are a class of cryptographic protocols that ensure secure group membership without revealing the identity of the signature. A group signature consists of a set of public keys (Pub ₁ , Pub ₂ , ..., Pub _n ) and a private key (Priv _i ) corresponding to one of those public keys. The group signature (GS(Priv _i , Pub ₁ , …, Pub _n )(bytes)) is a private key (Priv) whose byte string (bytes) corresponds to one of the public keys (Pub ₁ , Pub ₂ , …, Pub _n ). You can check whether it was signed by _i ), but which one it was signed by is not disclosed. The validity of the signature can be verified if it is comprised of a private key that corresponds to one of the public keys.

The respondent 200 can read the random transactions (tx ₁ ,..., tx _n ) recorded in the blockchain 500 and extract the public keys (Pub ₁ ,..., Pub _n ) of other respondents. For example, n may be around 20. The respondent 200 adds its own transaction (tx) to the random transactions (tx ₁ , ..., tx _n ), shuffles these transactions, and provides them to the vendor 300.

The compensation request provided to the vendor 300 includes the wallet address to provide compensation (dst), the shuffled transaction set (tx ₀ , tx ₁ , ..., tx _n ), the wallet address and transaction set to provide compensation, and the respondent's personal information. It can include a group signature using a key (sign=GS(Priv _V , Pub _V , Pub ₁ , …, Pub _n )(hash(dst||tx ₀ , …, tx _n )))).

The vendor 300 verifies each of the transaction sets (tx ₀ , tx ₁ , ..., tx _n ) included in the claim, confirms whether the transactions are included in the same survey, and verifies the public key (Pub) included in the claim. Extract ₀ , …, Pub _n ) and verify the group signature (GV(hash(dst, txs), sign, {Pub ₀ , …, Pub _n }).

Through this process, the vendor 300 can confirm that the respondent 200 participated in the survey through a transaction without any knowledge of the respondent 200's actual answer, and provide compensation.

The embodiments according to the present invention described above can be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and usable by those skilled in the computer software field. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium), and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. A hardware device can be converted into one or more software modules to perform processing according to the invention and vice versa.

In the above, the present invention has been described in terms of specific details, such as specific components, and limited embodiments and drawings, but this is only provided to facilitate a more general understanding of the present invention, and the present invention is not limited to the above embodiments. Anyone with ordinary knowledge in the technical field to which the invention pertains can make various modifications and changes from this description.

Therefore, the spirit of the present invention should not be limited to the above-described embodiments, and the scope of the patent claims described below as well as all scopes equivalent to or equivalently changed from the scope of the claims are within the scope of the spirit of the present invention. It will be said to belong to

Claims (9)

1. As a method for managing puzzled tokens,

   (a) on the issuer node side, combining the personal information of the issuing requester node to generate a puzzled token, and ensuring that the unique identifier included in the puzzled token is made private, and

   (b) On the issuance requester node side, cause a public identifier to be generated based on the deprived unique identifier, and ensure that the token in which the unique identifier is replaced with the public identifier in the puzzled token is used in the blockchain network. containing the steps of

   method.
2. According to paragraph 1,

   In step (b), on the issuance requester node side, the public identifier is individually generated according to the purpose of use of the puzzled token.

   method.
3. According to paragraph 1,

   In step (b), on the issuance requester node side, only tokens containing the public identifier, not tokens containing the privately processed unique identifier, are used in the blockchain network.

   method.
4. According to paragraph 1,

   In response to the completion of use of the token containing the public identifier in the blockchain network, the combination of the personal information of the issuing requester node in the token containing the public identifier is released and the public identifier is burned.

   method.
5. A non-transitory computer-readable recording medium recording a computer program for executing the method according to claim 1.
6. As a system for managing puzzled tokens,

   On the issuer node side, a publisher node management unit that combines the personal information of the issuance requester node to generate a puzzled token and ensures that the unique identifier included in the puzzled token is privately processed, and

   On the issuance requester node side, an issuance requester that causes a public identifier to be generated based on the privately processed unique identifier, and causes the token in which the unique identifier in the puzzled token is replaced with the public identifier to be used in a blockchain network. Contains node management unit

   system.
7. According to clause 6,

   The issuance requester node management unit, on the issuance requester node side, causes the public identifier to be individually generated according to the purpose of use of the puzzled token.

   system.
8. According to clause 6,

   The issuance requester node management unit, on the issuance requester node side, ensures that only tokens containing the public identifier, not tokens containing the privately processed unique identifier, are used in the blockchain network.

   system.
9. According to clause 6,

   In response to the completion of use of the token containing the public identifier in the blockchain network, the combination of the personal information of the issuing requester node in the token containing the public identifier is released and the public identifier is burned.

   system.

Images