KR20210017968A - Method for obtaining data through searching and merging distributed data stored using blockchain - Google Patents

Abstract

Disclosed is a data obtaining method through search and combination of data distributed and stored in a blockchain. The method, performed by a computer, comprises the steps of: obtaining a search value stored in the blockchain; obtaining pieces of data distributed and stored in a distributed storage network using the search value; combining the pieces of data; and post-processing the combined data to obtain result data.

Description

Data acquisition method through exploration and combination of data distributed in the blockchain {METHOD FOR OBTAINING DATA THROUGH SEARCHING AND MERGING DISTRIBUTED DATA STORED USING BLOCKCHAIN}

The present invention relates to a data acquisition method through search and combination of data distributedly stored in a blockchain.

Since the introduction of blockchain technology, the development of related technologies has spurred, and the implementation of the current blockchain technology has become generalized at a high level throughout the industry, and the industrial field using related technologies has also rapidly changed, making blocks in various places in society. Improved technologies using chains are active. In accordance with these changes in the environment, the center of gravity naturally shifted to what kind of business model was created using the technology rather than whether or not the blockchain technology itself was utilized or the complexity of the request of the society and the market.

In other words, what kind of business model will the recent blockchain technology create rather than the complexity of the technology itself as its high level has reached sufficient maturity, and how to solve the governance problem that enables participants to use the technology smoothly within the ecosystem built with the business model. It can be said that it is converging with two key objectives of whether to solve it.

The present invention was created based on this understanding and the changed market environment, requests from users and society. It presents a business model that allows users and companies to utilize the benefits of technology even if they do not directly build a blockchain infrastructure, and provides transparent governance that users can trust.

The problem to be solved by the present invention is to provide a data acquisition method through search and combination of data distributedly stored in a blockchain.

The problems to be solved by the present invention are not limited to the problems mentioned above, and other problems that are not mentioned will be clearly understood by those skilled in the art from the following description.

A method of obtaining data through search and combination of data distributedly stored in a block chain according to an aspect of the present invention for solving the above-described problem includes the steps of obtaining a search value stored in a block chain, and distributed storage using the search value. And obtaining data pieces distributedly stored in a network, combining the data pieces, and post-processing the combined data to obtain result data.

Further, the post-processing of the combined data may include decoding the combined data and removing a de-identification code from the decoded data.

In addition, the step of obtaining authentication request data from a user terminal, hashing the authentication request data, comparing the hashed value with the result data, and obtaining an authentication result according to the comparison result. I can.

In addition, the step of obtaining the search value stored in the blockchain may include obtaining M% of the fragment divided by the search value from the user terminal, and obtaining the remaining N% of the fragment divided by the search value from the blockchain. And restoring the search value by combining the divided fragments of the M% and the N%, and obtaining the data fragments comprises: using the restored search value to the distributed storage network It may include the step of obtaining distributedly stored data pieces.

In addition, the step of obtaining the data pieces may further include discarding the restored search value.

In addition, the step of obtaining the data pieces may include transmitting the search value to a preset IPFS system and obtaining the data pieces from the IPFS system.

In addition, the search value may be a hash value of data stored in the IPFS system.

An apparatus according to an aspect of the present invention for solving the above-described problem includes a memory for storing one or more instructions, and a processor for executing the one or more instructions stored in the memory, and the processor executes the one or more instructions. By doing so, a data acquisition method through search and combination of data distributedly stored in a block chain according to the disclosed embodiment is performed.

A computer program according to an aspect of the present invention for solving the above-described problems is combined with a computer that is hardware, so that a method of acquiring data through search and combination of data distributedly stored in a block chain according to the disclosed embodiment can be performed. It is stored in a computer-readable recording medium.

Other specific details of the present invention are included in the detailed description and drawings.

1 is a diagram illustrating an authentication system according to an embodiment.
2 is a diagram illustrating a system including a member OSP according to an embodiment.
3 is a diagram illustrating issuance of an EID and an authentication method using the EID according to an embodiment.
4 is a diagram illustrating a method of registering a device for secondary authentication according to an embodiment.
5 is a diagram showing a user registration method of an OSP for secondary authentication.
6 is a diagram illustrating a method of performing secondary authentication according to an embodiment.
7 is a conceptual diagram illustrating a method of paying a reward to a user who uses an authentication means according to an exemplary embodiment.
8 is a diagram illustrating a BaaS Currency Exchange (BCE) and a system including the same according to an embodiment.
9 is a flowchart illustrating an operation of an OSP and a system including the OSP according to an exemplary embodiment.
10 is a flowchart illustrating an operation of a wallet of a user terminal and a system including the same according to an exemplary embodiment.
11 is a diagram for explaining an account management method of a BCE according to an embodiment.
12 is a conceptual diagram illustrating a user's wallet according to an embodiment.
13 is a diagram illustrating an example of a screen providing an ID card function of a wallet.
14 is a diagram illustrating an example of a screen providing an electronic wallet function of a wallet.
15 is a diagram illustrating an example of a screen providing a drive function of a wallet.
16 is a diagram illustrating a method of distributed storage and combination of data according to an embodiment.
17 is a diagram illustrating a method of pre-processing and post-processing data according to an exemplary embodiment.
18 is a diagram illustrating an authentication system through distributed storage and combination according to an embodiment.
19 is a diagram illustrating a de-identification method according to an embodiment.
20 is a diagram illustrating a method of distributing and combining data based on a connector according to an embodiment.
21 is a diagram illustrating a data distribution storage system including a user terminal according to an embodiment.
22 is a diagram illustrating a method of acquiring data through combination in a distributed storage system including a user terminal according to an embodiment.
23 is a diagram illustrating a one-time authentication method according to an embodiment.
24 is a flowchart illustrating a method of distributedly storing and combining authentication information or files using the system according to the disclosed embodiment.
25 is a diagram illustrating a method of providing computing power and compensating for it according to an exemplary embodiment.
26 is a flowchart illustrating a method of acquiring data through searching and combining data distributedly stored in a block chain according to an embodiment.
27 is a diagram illustrating a device according to an embodiment.

Advantages and features of the present invention, and a method of achieving them will become apparent with reference to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in a variety of different forms, only the present embodiments are intended to complete the disclosure of the present invention, It is provided to fully inform the technician of the scope of the present invention, and the present invention is only defined by the scope of the claims.

The terms used in the present specification are for describing exemplary embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless specifically stated in the phrase. As used in the specification, “comprises” and/or “comprising” do not exclude the presence or addition of one or more other elements other than the mentioned elements. Throughout the specification, the same reference numerals refer to the same elements, and “and/or” includes each and all combinations of one or more of the mentioned elements. Although "first", "second", and the like are used to describe various elements, it goes without saying that these elements are not limited by these terms. These terms are only used to distinguish one component from another component. Therefore, it goes without saying that the first component mentioned below may be the second component within the technical idea of the present invention.

Unless otherwise defined, all terms (including technical and scientific terms) used in the present specification may be used as meanings that can be commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not interpreted ideally or excessively unless explicitly defined specifically.

The term "unit" or "module" used in the specification refers to a hardware component such as software, FPGA or ASIC, and the "unit" or "module" performs certain roles. However, "unit" or "module" is not meant to be limited to software or hardware. The “unit” or “module” may be configured to be in an addressable storage medium, or may be configured to reproduce one or more processors. Thus, as an example, "sub" or "module" refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, It includes procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays and variables. Components and functions provided within "sub" or "module" may be combined into a smaller number of components and "sub" or "modules" or into additional components and "sub" or "modules". Can be further separated.

In the present specification, a computer refers to all kinds of hardware devices including at least one processor, and may be understood as encompassing a software configuration operating in a corresponding hardware device according to embodiments. For example, the computer may be understood as including all of a smartphone, a tablet PC, a desktop, a laptop, and a user client and an application running on each device, but is not limited thereto.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Each of the steps described herein is described as being performed by a computer, but the subject of each step is not limited thereto, and at least some of the steps may be performed by different devices according to embodiments.

Before describing the details of the disclosed technology, definitions and backgrounds of terms used, and the purpose of the technology will be described in advance.

BaaS is an abbreviation of Blockchain as a Service, and is a concept term proposed to refer to a technology that provides an infrastructure equipped with blockchain technology to the general so that individuals or companies can easily use the benefits of blockchain technology.

In this specification, BaaSid may also be understood as a meaning representing a subject providing services and systems according to the disclosed embodiment. For example, a server that provides, operates, and manages services and systems according to an embodiment disclosed in the present specification may be referred to as a BaaSid server, and a block chain used in the disclosed embodiment may be referred to as a BaaS chain. In addition, the cryptocurrency used and provided in the blockchain system according to the disclosed embodiment may be referred to as BAAS coin.

The present invention is combined with this to form part of a collective technology that forms a single blockchain technology ecosystem. The outline of the aspect to be implemented through the above-described blockchain technology ecosystem is as follows.

Users can create account information that can be widely used in the above-described blockchain ecosystem based on personal information. Based on the personal information created in this way, the user can use the service as an authenticated user in other OSPs (Online Service Providers) connected to the BaaS ecosystem without a separate membership registration process.

The personal information and account information described above are randomly distributed after being encrypted and stored on the blockchain. Under the premise of such random distribution, user information is temporarily recombined and used only when necessary in the absence of the original, and recombination is also based on the user's biometric information or possession-based authentication tool, so other than the user can view or access the original. This impossible structure was implemented.

Based on this high level of stability, users can open wallets and manage property information on the system. Through this, services or goods provided by other OSPs can be purchased, and various cryptocurrency transactions and real money can be exchanged.

In addition, a user can distribute and store various types of digital information by using the above-described distributed storage and limited recombination techniques. Unlike generalized cloud services, such distributedly stored information cannot be accessed, viewed, modified, stored, distributed, or deleted even by a service provider unless the user authenticates and reassembles the information. This is because, as described above, it is impossible to access the original data without the user.

In the extreme, even if all the servers that provide the BaaSid system are stolen, the information distributed on the blockchain is like a roll of paper shredded letter by letter in a lost order, so it is distributed without user authentication. You cannot assemble the data in the right order and method.

In this way, users can guarantee extremely high stability with respect to various information including their own finances, and at the same time secure convenience based on their own biometric information such as fingerprints and an easy authentication process using proprietary authentication tools such as smartphones. can do.

1 is a diagram illustrating an authentication system according to an embodiment.

Referring to FIG. 1, a user terminal 300, an online service provider (OSP) 200, and an authentication server 100 are shown.

In the disclosed embodiment, the user terminal 300 may be a kind of the above-described computer, for example, a personal computer or a smart phone used by the user, but is not limited thereto.

In the disclosed embodiment, the OSP 200 may refer to a provider that provides a specific service and platform through online, and types of the provided service and platform are not limited. For example, the OSP 200 may refer to a subject providing services such as portal, finance, learning, and shopping through online, and services and platforms provided based thereon, but is not limited thereto.

In addition, BSP (Blockchain Service Provider) may mean a provider that provides a service based on a block chain, and operations and steps related to the OSP 200 described below may also be performed by the BSP.

In the disclosed embodiment, the authentication server 100 may mean a server that performs a method according to the disclosed embodiment that performs authentication based on a block chain. The server may be a kind of computer described above, but is not limited thereto, and may mean a cloud-type server.

In an embodiment, the user terminal 300 may receive an EID (Electrical ID: Electronic Identifier) through the authentication server 100.

In the disclosed embodiment, the EID may mean a kind of online identification card that allows users to log in to a site affiliated with the authentication server 100 and other general sites without a separate membership registration.

The user terminal 300 may use the issued EID as an authentication means in different OSPs 200.

When the OSP 200 obtains an EID-based authentication request from the user terminal 300, the OSP 200 transmits the request to the authentication server 100 to request authentication. When authentication is completed in the authentication server 100 and information about authentication is obtained from the authentication server 100, the OSP 200 trusts the authentication result of the authentication server 100 to determine that authentication for the user is completed. I can.

For example, the user terminal 300 may request a login to use the service of the OSP 200 and use EID-based authentication as a login means. When the authentication for the user terminal 300 is completed through the authentication server 100, the OSP 200 may approve the login request of the user terminal 300.

Depending on the embodiment, the user terminal 300 creates an OSP account to use the service provided by the OSP 200 (i.e., registers as a member of the OSP), and performs EID-based authentication as a login method for the account. It may be your choice.

In this case, the user terminal 300 first performs a login based on the information on which the user subscribes to the OSP 200, and then the user terminal 300 subscribed to the OSP 200 through secondary authentication based on the EID. EID-based authentication can also be used as a means to strengthen the security of the user's account. Details of this will be described later.

In another embodiment, the user terminal 300 may not register as a separate member for the OSP 200, and instead, when first logging in to the OSP 200 through EID-based authentication, the OSP 200 An account corresponding to the terminal 300 may be created, and the created account may be assigned to the user terminal 300. Thereafter, when the user terminal 300 logs in through EID-based authentication, the OSP 200 acquires an account of the user terminal 300 that is previously allocated, and may provide a service based thereon.

2 is a diagram illustrating a system including a member OSP according to an embodiment.

In an embodiment, the OSP 200 may receive an EID (Electrical ID: Electronic Identifier) through an authentication server.

In the disclosed embodiment, the OSP to which the EID has been issued may be referred to as the member OSP 210.

The member OSP 210 can issue its own EID using the issued EID, which generates a sub-EID using its issued EID. In this case, the places where EID can be used may be limited, and for example, an EID issued by a specific OSP may be configured so that only the corresponding OSP can use it for authentication.

In an embodiment, the member OSP 210 may be configured to issue a sub-EID, but not verify it. In this case, the member OSP 210 issues a sub-EID, but may have to request the authentication server 100 to verify this. In another embodiment, the member OSP 210 may be configured to perform both issuance and verification of the sub-EID.

3 is a diagram illustrating issuance of an EID and an authentication method using the EID according to an embodiment.

Referring to FIG. 3, a non-member terminal 330, an OSP member terminal 320, and a BaaSid member terminal 310 are illustrated.

The non-member terminal 330 refers to a terminal of a non-member who has never been subscribed or issued an EID anywhere.

The OSP member terminal 320 refers to a terminal of a member who has subscribed to the OSP, and the membership subscription method is not limited. For example, an OSP member may have subscribed to the OSP based on an ID and password, or may have subscribed in the form of receiving a sub-EID using the OSP's EID as described above.

The BaaSid member terminal 310 may mean a member who has been issued an EID from the BaaSid authentication server 100 according to the disclosed embodiment.

In the disclosed embodiment, the BaaSid member terminal 310, which has received an EID from the BaaSid authentication server 100, can log in to different OSPs 200 using the EID without separate membership registration. That is, in the disclosed embodiment, the EID issued from the BaaSid authentication server 100 may function as an online integrated identification card that can be used without registering as a member in all web services.

In addition, the OSP member terminal 320 may log in to the OSP 200 by presenting the EID issued from the OSP 200 when logging in to the OSP 200 or by presenting the EID issued from the BaaSid authentication server 100. . According to an embodiment, the EID issued from the BaaSid authentication server 100 may be used as a secondary authentication means for OSP login.

In addition, the non-member terminal 310 may receive an EID from the BaaSid authentication server 100 or log in to the OSP 200 after signing up as a member of the OSP 200.

In an embodiment, the BaaSid authentication server 100 may obtain information for issuing EID from a subject who wishes to obtain an EID, verify the obtained information, and then generate and issue an EID based on the obtained information.

For example, the BaaSid authentication server 100 may determine whether to generate an EID by verifying the obtained information, and determine whether to generate or reject the generation according to the determination. The creation rejection message or the generated EID is delivered to the user, OSP, or BSP who applied for issuance of the EID.

For example, when a user wants to obtain an EID, the BaaSid authentication server 100 provides the user's personal identification information (for example, personal information such as name, phone number, social security number, date of birth, sensitive information, biometric information, etc.) EID can be generated by using, and the specific method is not limited. For example, the EID may be a character string of a specific length including letters and numbers, but is not limited thereto.

In one embodiment, the EID must be uniquely generated so as not to overlap with other users, and for this purpose, a unique value generated based on the user's personal information may be inserted at a specific location.

According to an embodiment, the BaaSid authentication server 100 may obtain device information of a user terminal and generate an EID by using the user's personal information and the device information of the user terminal together. In this case, when the user terminal is changed, the EID may need to be regenerated, but is not limited thereto.

In addition, various information can be used to generate the user's EID.

Details of the EID generation method will be described later.

In an embodiment, the authentication server 100 may perform an authentication procedure to generate an account and an EID of a user.

The authentication procedure may include a plurality of steps, and the specific configuration is not limited. For example, the authentication procedure may include step 1 email authentication, step 2 SMS authentication, step 3 residence authentication, step 4 KYC (Know Your Customer) authentication, and step 5 account information authentication. In an embodiment, when the first-step email authentication is completed, the authentication server 100 generates and issues a user's account, and when four or more steps of authentication are completed, the authentication server may issue an EID.

In addition, when the user's sub-EID is generated by the member OSP 210, which has been issued an EID from the BaaSid authentication server 100, the OSP 210 can generate the user's sub-EID by using its EID together. .

The sub-EID issued through the member may be different from the EID issued through the BaaSid authentication server 100 (for example, the length or the arrangement of characters). For example, the EID of the member who issued the sub EID An area in which information is recorded may be included in the sub EID.

Through this, the authentication step can be configured so that the sub-EID in the authentication step is used only by a member OSP having an EID that matches the EID information of the member who issued the EID.

The user stores the issued EID in the user terminal, and an electronic wallet for storing the EID may be installed in the user terminal. The wallet according to the disclosed embodiment may not only store various information but also perform various functions. A wallet according to the disclosed embodiment will be described later.

As another example, when a service provider such as the OSP 200 wants to obtain an EID, the BaaSid authentication server 100 obtains information on the OSP 200 from the OSP.

The BaaSid authentication server 100 verifies the acquired OSP information to determine whether to generate an EID, and when the EID generation is determined, transmits the generated EID to the OSP 200.

The OSP 200 may store the EID issued from the BaaSid authentication server 100 in equipment such as a server or a security token, but is not limited thereto.

Hereinafter, the structure of the EID and a method of generating the EID according to the disclosed embodiment will be described in detail.

EID is managed by two blockchains, consisting of a blockchain for managing EID issuance information and a blockchain for disposal management.

In one embodiment, the blockchain for EID issuance management is configured in the form of a private blockchain or a consortium blockchain, and the blockchain for EID disposal management is configured in a public, private, or consortium form. Can be.

DPoS (Delegated Proof of Stake) can be used for EID issuance. The issued EID is distributed in the form of distributed storage on the blockchain.

Email authentication, SMS authentication, and KYC authentication are performed to generate EID. All information used for EID issuance is de-identified, encrypted, and partitioned on a private or consortium blockchain and stored distributed in a number of unspecified nodes.

In an embodiment, the authentication server 100 may prevent duplicate serial numbers from being generated by generating and managing serial numbers for EID generation. Accordingly, the authentication server can verify the validity of the EID only with the serial number included in the EID.

The authentication server 100 may register the public key generated in the wallet of the user terminal 300 in the blockchain, and use the SPLIT engine to separate and distribute user information in the blockchain. When a user requests to provide an EID, the authentication server may generate an OTP value using the SPLIT engine, and provide the EID to the user terminal by combining the generated OTP value and the EID.

The form of providing the EID is not limited, but may be provided as an EID value in the form of a QR code image or string, for example. The use of OTP values for EID provision is to eliminate the risk that may occur due to forgery or delegation through image capture or value stealing. In addition to the OTP value, any random number may be combined with the EID.

In order to register the user public key, the authentication server 100 may generate a challenge value and transmit it to the wallet of the user terminal 300. The user terminal 300 may digitally sign (encrypt) the challenge value using the private key stored in the wallet and transmit it to the authentication server. The authentication server 100 decrypts the digital signature value (encrypted challenge value) received from the user terminal 300 with a public key, compares it with the challenge value generated by the authentication server 100, and registers the public key if it matches. I can. If they do not match, the authentication server 100 does not register the user's public key.

In one embodiment, the wallet of the user terminal 300 generates a user's key pair using the BIP39 algorithm. Among the generated key pairs, the public key is registered in the blockchain through the authentication server 100. For public key registration, the user terminal 300 encrypts the challenge value transmitted from the authentication server 100 using a wallet with a private key and transmits it to the authentication server 100 together with the public key. As described above.

In one embodiment, the EID has a structure including the following components.

-Serial No: It consists of a combination of the issuing agency's identification number and serial number. For example, the serial number includes 34 bytes (long serial), which may mean the number of digits required to issue a non-overlapping number based on about 7.78 billion people worldwide (as of the present time). In addition, the serial number includes 12 bytes (int issue_auth), which may include the number of digits required to assign a unique personalization agent code and a digital signature value.

-EID identity: A service according to the disclosed embodiment and an integrated ID provided through the authentication server, which may be an online integrated ID composed of 64 bytes of hexadecimal number, but is not limited thereto.

-Name: As a user name, for example, it is composed of 20 bytes (string name), and the number of digits may be excessively increased to indicate all user names in global languages, so the maximum number of Korean characters can be limited to 5 characters. It does not become.

-Date of Birth: It means the date of birth of the user and can be composed of 8 bytes.

-Issuance Date: The issuance date of the EID, which can consist of 8 bytes.

-Extension Field: The extension field may include various pieces of information, and may include, for example, the following components.

i) Country code: This is 10-bit information, which means the number of digits required to issue a unique code for each country when the number of countries around the world is about 228 countries as of the present time. For example, you can refer to the phone number and country code.

ii) Mobile phone number: 12-byte digits can be used to indicate the user's mobile phone number.

iii) E-mail: It is used to enter the user's e-mail address, which can also be used to find the user's EID when lost.

iv) SMS or KYC: As 2bit information, 1bit information may be included as a True/False value depending on whether SMS or KYC authentication is successful, and 1bit may be additionally included in consideration of exceptions.

-Result value: In an embodiment, a value calculated according to a preset criterion from information included in the EID may be input as the result value, but is not limited thereto.

-Digital Signature (DS): The digital signature value may include the user's digital signature value and the issuing agency's digital signature value. The user's digital signature value is a value encrypted with the user's private key, the personalization agency's digital signature value may be a value encrypted with the issuing agency's private key, and each data may be composed of 256 bits, but is not limited thereto.

The EID as described above may be generated and registered based on the DPoS method. The DPoS method is a method in which a decision is made by voting of elected BPs (Block Producers). For example, an EID may be generated when 15 or more of 21 BPs approve. BP operation and policy setting may be performed by a system administrator according to the disclosed embodiment.

BPs may approve or reject EID generation after checking whether SMS and KYC are authenticated, but are not limited thereto, and EID may be generated if there is a majority of BPs' approval or more than a preset number of votes without SMS and KYC authentication. However, a penalty may be given to the BP for an accident caused by the generated EID, and the BP may take this into account and decide whether to approve the EID generation.

After all BPs vote for EID creation, the last BP can finally collect all BPs' signatures and finally digitally sign. The signed data is attached to the EID, there is no set order of the BPs, and the results processed first can be sequentially accumulated.

4 is a diagram illustrating a method of registering a device for secondary authentication according to an embodiment.

Hereinafter, a method of performing secondary authentication according to the disclosed embodiment will be described with reference to the drawings, but this may be used equally or similarly to not only secondary authentication, but also to single authentication or multiple authentication of two or more orders.

In the disclosed embodiment, the secondary authentication is configured to be usable only in a registered device. Therefore, the process of registering the device must be preceded before performing the secondary authentication, and if the device is changed, the device must be registered through the registration procedure.

Referring to FIG. 4, a system for secondary authentication includes a user terminal 300, an app market 500, an authentication platform 100, and an authentication chain 400.

In the disclosed embodiment, the app market 500 is understood to encompass all kinds of platforms through which applications can be purchased and downloaded.

In addition, the authentication platform 100 is a platform that provides a secondary authentication service according to the disclosed embodiment, and may mean a server that provides a secondary authentication service according to the disclosed embodiment.

According to an embodiment, the authentication platform 100 may correspond to the authentication server described above in FIGS. 1 to 3.

In the disclosed embodiment, the authentication chain 400 may mean a block chain used to store information necessary for authentication and secondary authentication based on the disclosed authentication platform 100. The structure of the authentication chain 400 and a specific method of storing information in the authentication chain will be described later.

In one embodiment, the user terminal 300 may download and install an application for secondary authentication from the app market 500. However, the path through which the user terminal 300 acquires an application is not limited to the app market 500.

In one embodiment, the application downloaded and installed by the user terminal 300 may be the above-described wallet application, but is not limited thereto.

The user terminal 300 may generate an account using the installed application, and may generate a wallet corresponding to the account according to an embodiment. In an embodiment, the account may mean the address of the electronic wallet according to the disclosed embodiment, but is not limited thereto.

In an embodiment, the account may be composed of a character string (eg, 12 digits) of a preset length consisting of a combination of letters and numbers, but is not limited thereto.

In an embodiment, when an account is created, a user's public key and a private key may be generated together with the user's public key and a private key, and a recovery code used for account recovery may be generated and provided.

In an embodiment, a mnemonic code including 12 words based on the BIP 39 standard may be used for recovering an account, but is not limited thereto. For example, a seed key may be obtained based on 12 words provided, and a user's public key and a private key may be generated using the obtained seed key.

The generated private key is securely stored in a safe zone of the wallet according to the disclosed embodiment, and the public key can be distributed through a block chain.

In addition, in the process of creating an account, an identity verification process using a separate channel may be performed. For example, identity verification can be performed based on email authentication, and the authentication server 100 sends six authentication codes to the user's email address for identity verification, and the user authenticates by entering the corresponding authentication code. Can be done.

After the account creation is completed, a pattern, PIN, text, biometric information, etc. may be selectively input as a simple authentication means, and a user may execute an application using the simple authentication means.

In an embodiment, the method for generating an account performed by the user terminal may use the above-described method of obtaining the EID of the user terminal, but is not limited thereto.

In one embodiment, the user terminal 300 may create an account, obtain an EID from the above-described authentication server using the created account, and store the EID in a wallet managed by the created account. have.

In an embodiment, the user terminal 300 may generate a push key.

The user terminal 300 may transmit the generated push key and device information of the user terminal 300 to the authentication platform, and request device registration from the authentication platform 100.

The authentication platform 100 may register device information in the authentication chain 400 and store a corresponding push key.

5 is a diagram showing a user registration method of an OSP for secondary authentication.

In one embodiment, the OSP 200 and the authentication platform 100 share ticket information. For example, the authentication platform 100 may generate a ticket number and issue the generated ticket number to the OSP 200. As another example, the OSP 200 may issue a ticket and transmit it to the authentication platform 100.

In the disclosed embodiment, a ticket is used to register device information in the authentication platform 100 in response to the OSP 200. The form and type of the ticket is not limited, and may be composed of, for example, a predetermined character string or number.

In an embodiment, the ticket may be configured as an identifier of an OSP used to distinguish a specific OSP from other OSPs, but is not limited thereto.

The authentication platform 100 or OSP 200 may generate a QR code using ticket information. The generated QR code is transmitted to the user, and the user terminal 300 may scan the transmitted QR code. For example, the generated QR code may be transmitted to the user and displayed on a monitor of a computer used by the user, and the user terminal 300 may obtain information included in the QR code by scanning it.

However, the method of transmitting the ticket information to the user terminal 300 is not limited thereto, and various electronic codes or data encryption and transmission/reception means may be used in addition to the QR code.

In an embodiment, the QR code may include link information (eg, URL) for device registration along with ticket information.

According to an embodiment, the QR code includes ticket information and link information together, and the user terminal 300 transmits the ticket information obtained through the QR code and the device information of the user terminal 300 to the connected target through the link information. I can.

In another embodiment, link information corresponding to ticket information is stored in a QR code, and the user terminal 300 accesses a target (for example, a web page) corresponding to the ticket information through the link information. Device information may be provided to the authentication platform 100. In this case, the authentication platform 100 may acquire ticket information corresponding to the web page from which the device information is obtained, together with the device information.

The authentication platform 100 may acquire ticket information of the OSP 200 and device information of the user terminal 300, and may generate authentication information using the acquired ticket information and device information.

A method of generating authentication information is not limited, and various methods of combining ticket information and device information may be used.

The authentication platform 100 may store the generated authentication information in an authentication chain and generate an authentication token corresponding thereto.

The type of information stored in the authentication token is not limited, and for example, ticket information and device information, or information generated based on ticket information and device information may be stored. In addition, the authentication token may store information necessary to obtain authentication information stored in the authentication chain.

The authentication platform 100 delivers the generated token to the OSP 200.

The OSP 200 may link and store the token received from the authentication platform with the OSP account of the user terminal 300 and complete the device registration process. The OSP account may refer to an account of the OSP created by the user terminal 300 through membership registration to the OSP, but is not limited thereto.

The device registration process as described above may be initially performed once per OSP, and may be performed again when a predetermined period elapses or when a user terminal is changed to another device.

6 is a diagram illustrating a method of performing secondary authentication according to an embodiment.

In one embodiment, the user terminal 300 requests login or authentication for the OSP 200. The user terminal 300 may request login or authentication for the OSP 200 using the primary authentication means. For example, the user terminal 300 logs in or authenticates the OSP 200 using account information. May be requested, but is not limited thereto.

The OSP 200 searches for an authentication token through the user's account information, and waits without completing the authentication process until the second authentication is completed.

The OSP 200 transmits an authentication token to the authentication platform 100 to request authentication, and the authentication platform 100 performs authentication using the authentication token transmitted from the OSP 200, and then transmits the authentication result to the OSP ( 200). The OSP 200 completes authentication or requests re-authentication according to the authentication result transmitted from the authentication platform 100.

Specifically, when a user authentication request is received, the OSP 200 may acquire an authentication token corresponding to the user's account information, and transmit it to the authentication platform 100.

In addition, the authentication platform 100 may verify an authentication request from the OSP 200 including an authentication token. When verification of the authentication request is completed, the authentication platform 100 may search for device information corresponding to the user terminal in the authentication chain 400 based on information included in the authentication token.

When the device information of the user terminal 300 that is previously registered in the authentication chain 400 is obtained, the authentication platform 100 obtains the push key of the user terminal 300 stored in advance, and sends the obtained push key to the push server ( 600) to transmit a push message to the user terminal 300.

The user terminal 300 executes the wallet in which the EID is stored according to the received push message and initiates the EID-based authentication process, or immediately starts the EID-based authentication process if the wallet is already running.

When authentication based on the EID of the user terminal 300 is completed in the authentication platform 100, the authentication platform 100 may transmit (Call Back) the authentication result to the OSP.

The OSP may complete the authentication process or request re-authentication according to the authentication result transmitted from the authentication platform 100.

The authentication means according to the disclosed embodiment and the authentication procedure using the same may be used for secondary authentication of the OSP 200 as described above, but is not limited thereto, and, for example, is used for primary authentication in different OSPs. , It may be used to implement Single Sign On (SSO) based on the EID stored in the user terminal 300.

7 is a conceptual diagram illustrating a method of paying a reward to a user who uses an authentication means according to an exemplary embodiment.

Referring to FIG. 7, an authentication system as shown in FIG. 1 is shown.

In the disclosed embodiment, BAAS is BAAS Coin, which means a cryptocurrency provided in a service according to the disclosed embodiment.

In addition, BIDT stands for BaaS ID Token, and refers to a token used for user compensation in the authentication system according to the disclosed embodiment.

In one embodiment, the OSP 200 purchases BIDT from the authentication server 100. The OSP 200 may directly receive and hold the BIDT purchased from the authentication server 100, or purchase the right to pay the BIDT to the user, but may not directly store the corresponding BIDT.

In the disclosed embodiment, the OSP 200 may purchase BIDT in exchange for using the authentication system provided through the authentication server 100. The OSP 200 may purchase BIDT and pay BIDT as a reward for the use of the authentication service to a user who requests authentication through the authentication server 100 from the OSP 200. The amount of BIDT paid is not limited, but for example, 0.01 BIDT may be paid per authentication request.

When the purchased BIDT is exhausted, the OSP 200 must additionally purchase a BIDT to use the authentication service.

In an embodiment, there may be an excessive authentication request for obtaining BIDT. Accordingly, the number or amount of BIDT that can be obtained through an authentication request per person may be limited.

For example, it may be limited to a maximum of 0.05 BIDT per person per day.

As another example, the number of times a BIDT can be acquired per person may be limited for each OSP or for each individual, but is not limited thereto.

In addition, it is possible to set a limit on the number of repetitions within a predetermined time range, such as setting not to pay additional BIDT when re-login or authentication is requested up to 3 times per person within 1 hour.

The user terminal 300 includes the wallet 700 as described above, and receives BIDT from the OSP 200 or the authentication server 100 whenever an authentication request is made to the OSP 200. The user terminal 300 may store the received BIDT in the wallet 700.

When a predetermined BIDT is collected, the user terminal 300 may request the authentication server 100 to exchange it for BAAS. The authentication server 100 may receive BIDT from the user terminal 300 and provide BAAS corresponding thereto to the user terminal 300.

For example, 1,000 BIDT may be exchanged for 1BAAS, but is not limited thereto.

The user terminal 300 may store the acquired BAAS in the wallet 700.

8 is a diagram illustrating a BaaS Currency Exchange (BCE) and a system including the same according to an embodiment.

In the disclosed embodiment, cryptocurrencies managed and provided through the BCE 800 may include BAAS (BAAS Coin), BIDT (BaaS ID Token), and BRC (BaaS Reward Coin).

Referring to FIG. 8, a BCE 800, a user terminal 300, an OSP 200, a BP (Block Producer, 900) and a BAAS management unit 810, a BRC management unit 820, and a BIDT that manage each cryptocurrency. The management unit 830 is shown.

In one embodiment, BP means a Block Producer, that is, a block producer. For example, in the case of a DPoS (Delegated Proof of Stake) type of blockchain, a set number (for example, 21) of block producers is determined through voting.

A reward is paid to the block producer, and in the disclosed embodiment, the BRC may be paid to the block producer as a reward.

In addition, various DApps based on the system according to the disclosed embodiment may be produced and distributed to be used. In this case, each DApp may pay compensation using BRC.

BCE (800) manages the purchase, payment and exchange of each cryptocurrency.

In one embodiment, BAAS is the main cryptocurrency of the system according to the disclosed embodiment, and BIDT and BRC may be cryptocurrencies used to compensate for system users and members.

BIDT and BRC may be exchanged with BAAS when a certain number of them is collected, and such exchange may be performed through BCE.

BaaS Relay mediates the user terminal, OSP and BP and each cryptocurrency management unit, and plays a role of mediating the purchase request and exchange request for cryptocurrency.

In one embodiment, the BCE 800 may transmit a BRC purchase request from the user terminal 300 to the BRC coin management unit 820, and transmit the BRC received from the BRC coin management unit 820 to the user terminal 300. .

In addition, when a BAAS exchange request based on the BIDT of the user terminal 300 is received, the BCE 800 transmits it to the BIDT management unit 830, and the BIDT management unit 830 exchanges the BIDT of the user terminal 300 with BAAS. give. The BCE 800 may transmit the BAAS received from the BIDT management unit 830 to the user terminal 300. In an embodiment, the BIDT management unit 830 may hold a BAAS for exchanging BIDT into BAAS.

In addition, the BCE 800 may obtain a BIDT purchase request from the OSP 200, directly hold and manage it, or transmit it to the BIDT management unit 830.

Thereafter, when the authentication request and the BIDT payment request are obtained from the OSP 200, the BCE 800 transmits the request to the BIDT management unit 830, and receives the BIDT from the BIDT management unit 830 to the user terminal 300. I can deliver.

In this process, the BCE 800 or the BIDT management unit 830 determines whether or not BIDT is paid within the BIDT limit purchased by the OSP 200, and requests the OSP 200 to purchase additional BIDT if the limit is exceeded. I can.

In addition, the BCE 800 may receive a BRC exchange request from the BP 900 and transmit it to the BRC management unit 820. The BRC management unit 820 may exchange BRC for BAAS and pay, and the BCE 800 may pay the BAAS paid from the BRC management unit 820 to the BP. The BRC management unit 820 may hold a BAAS for exchanging BRC into BAAS.

In the above-described embodiment, the purchase of BAAS and BRC may be made through cash (eg, USD), but is not limited thereto.

In addition, the purchase of BIDT may also be directly purchased through cash. However, according to the embodiment, the purchase of BIDT is to acquire a corresponding BIDT through the purchase of BAAS, or obtain the right to pay a corresponding BIDT. I can.

9 is a flowchart illustrating an operation of an OSP and a system including the OSP according to an exemplary embodiment.

In one embodiment, the OSP 200 applies for service subscription and use to the authentication server 100. The authentication server 100 checks the Account _OSP , which is the account of the OSP 200, and _responds to the service use request.

In one embodiment, the authentication server 100 requests the OSP 200 to charge BAAS for service use.

In one embodiment, the OSP 200 transmits, to the authentication server 100, an amount (eg, USD) for purchasing BAAS along with information on the Account _OSP .

In one embodiment, the authentication server 100 checks the information on the Account _OSP and the deposit of USD. When the verification is completed, the authentication server 100 requests the BCE 800 to charge BAAS, and transmits information on the Account _OSP and deposit information of USD.

The BCE 800 may create an Account _{OSP_BAAS} account, an account for managing BAAS of the Account _OSP , after checking the received information about the Account _OSP , deposit of USD, and policy information.

The BCE 800 may transmit information on the Account _{OSP_BAAS} account and the deposited USD to the BAAS management unit 810, and request the BAAS to be charged.

The BAAS management unit 810 may complete the charging process by checking the information on the Account _{OSP_BAAS} account and the deposited USD, and charging BAAS to the Account _{OSP_BAAS} account.

Furthermore, the BCE 800 may create an Account _{OSP_BIDT} account to charge BIDT required for service use of the OSP 200.

In addition, BCE (800) is about the BIDT manager 830 provides the charging information and the BAAS Account _{OSP_BIDT} account for the Account _{OSP_BIDT} account and may request the charge (purchase) of BIDT.

BIDT management unit 830 may pay BIDT to make a deposit from BAAS Account _{OSP_BIDT} account information and Account _{OSP_BAAS} accounts, corresponding to the Account _{OSP_BIDT} account.

Thereafter, the BCE 800 transmits the fact that the BIDT charging has been completed to the authentication server 100, and the authentication server 100 may notify the OSP 200 that preparation for service use is complete.

10 is a flowchart illustrating an operation of a wallet of a user terminal and a system including the same according to an exemplary embodiment.

In an embodiment, the user terminal 300 may apply for a service use to the OSP 200 using an Account _USER , which is a user's account created through the installed wallet 700.

The OSP 200 may request the authentication server 100 to check the information of the Account _USER .

The authentication server 100 may check Account _USER information and transmit the result of the check to the OSP 200 and the user terminal 300. The verification result may include information on whether authentication succeeds or fails.

In addition, the authentication server 100 may perform a BIDT payment request to the BCE 800 according to authentication. In one embodiment, the authentication server 100 may transmit the account _user information and the account _OSP information to the BCE (800).

The BCE 800 may check the balance and policy charged in the Account _{OSP_BIDT} account, and accordingly, may pay BIDT to the user terminal 300.

In an embodiment, the BCE 800 may request the BIDT management unit 830 for a cost corresponding to the BIDT paid to the user terminal 300. The BIDT management unit 830 may pay the BCE 800 by paying the BAAS charged to the Account _{OSP_BAAS} account.

In an embodiment, the BCE 800 may receive a request from the user terminal 300 to exchange BIDT for BAAS. In this case, the BCE 800 may check the currency exchange policy and pay BAAS to the user terminal 300.

Thereafter, the BCE 800 may provide the BIDT to the BIDT management unit 830, and the BIDT management unit 830 may pay the corresponding BAAS to the BCE 800.

11 is a diagram for explaining an account management method of a BCE according to an embodiment.

Referring to FIG. 11, a structure of the BCE 800 as shown in FIG. 8 is shown.

In one embodiment, the OSP 200 transmits the Account _OSP to the BCE 800, and the BCE 800 may create sub accounts, Account _{OSP_BAAS} and Account _{OSP_BIDT} , using the Account _OSP of the _OSP 200.

The BCE 800 may create sub accounts for the OSP 200 and then store the OSP's BAAS and BIDT in each sub account.

Similarly, BCE (800) can acquire the account Account of _BP BP (900) from the BP (900), and generate a sub-account of Account Account _{BP_BAAS} and _{BP_BRC.} Likewise, the BCE 800 may store the BAAS and BRC of the BP in each sub-account.

In one embodiment, BaaS Relay verifies OSP account and USD deposit.

For example, BaaS Relay can manage different OSP accounts such as Account1 _OSP , Account2 _OSP , and Account3 _OSP .

In addition, when an external request is obtained, the BaaS Relay may transmit the request to a subject corresponding to each request among the BAAS management unit 810, the BRC management unit 820, and the BIDT management unit 830.

The BAAS management unit 810 may _manage sub accounts such as Account1 _{OSP_BAAS} , Account2 _{OSP_BAAS} , and Account3 _{OSP_BAAS} .

The BRC management unit 820 may _manage sub accounts such as Account1 _{BP_BRC} , Account2 _{BP_BRC} , and Account3 _{BP_BRC} .

The BIDT management unit 830 may manage sub accounts such as Account1 _{OSP_BIDT} , Account2 _{OSP_BIDT} , and Account3 _{OSP_BIDT} .

12 is a conceptual diagram illustrating a user's wallet according to an embodiment.

As described above, an application for using a service and system according to the disclosed embodiment is installed in the user terminal 300. In this specification, the wallet 700 may refer to a series of electronic wallets that are created and stored by the above-described application and used to store authentication information and cryptocurrency.

In addition, in this specification, the wallet 700 may refer to the above-described application itself, which is a kind of “super wallet that includes not only user authentication information but also various cryptocurrency storage functions, cloud storage space (drive) functions, etc. It may mean ”, and the specific configuration and function of the wallet are not limited.

In an embodiment, a BaaSid corresponding to an account for using a service provided by the system according to the disclosed embodiment by logging into an application installed in the user terminal 300 may be granted to the user. The user can log in to the application using BaaSid, and then can use the service of the application according to the disclosed embodiment.

In an embodiment, as a simple authentication means for BaaSid authentication, a pattern, PIN, text, biometric information, etc. may be selectively input, and the user may execute an application using the simple authentication means.

Referring to FIG. 12, functions that can be provided by the wallet 700 according to the disclosed embodiment are illustrated. For example, functions that can be provided by the wallet 700 may include an electronic identification card 710, an electronic wallet 720, a drive 730, and various other functions 740, but are limited thereto. no.

The existing blockchain wallet (wallet) simply performed functions such as transfer, remittance, and balance check, but the wallet 700 according to the disclosed embodiment stores and transacts various cryptocurrencies, EID and ID functions, website login, and It can perform various functions such as cloud drive.

In particular, Drive provides a security function based on blockchain and distributed storage, and unlike the existing Drive, it is characterized in that the server administrator cannot check the contents without the authentication means stored in the user terminal and wallet. The contents will be described later.

Furthermore, wallets can store all information that needs security, such as user's personal information, authentication information, and card payment information, and provide various services based on this, but provide a higher level of security compared to other services. It is characterized.

13 is a diagram illustrating an example of a screen providing an ID card function of a wallet.

Referring to FIG. 13, an example of a screen on which a wallet application is executed in the user terminal 300 is shown.

In an embodiment, the wallet application may include an ID tab 710, a wallet tab 720, a drive tab 730, and a personal setting tab, but is not limited thereto.

The screen shown in FIG. 13 is an example of a screen displayed when the ID tab 710 is selected.

In an embodiment, an electronic identification card including personal authentication information may be displayed on the ID tab screen. The information included in the electronic identification card is not limited, but information on the user's photo, name, nationality, date of birth and issue date may be included.

In addition to the information displayed on the screen, the wallet application may store user account information and authentication information such as EID, and if authentication information is required for website login or user authentication, the wallet application is required for the stored authentication information and authentication. Other information can be transmitted to the authentication subject.

Depending on the embodiment, the electronic identification card shown in FIG. 13 may be used both online and offline, but may be used only online and its use may be limited. Further, the use of the authentication information stored in the electronic ID card and wallet shown in FIG. 13 may be restricted so that it can be used only for login of the website, and in this case, the use may be restricted so that it cannot be used for other authentication such as identity authentication.

In addition, the targets and uses for which the electronic identification card can be used may be restricted according to preset standards.

In addition, referring to the drawing shown in FIG. 13, notices or notification information to be provided to the user, and usage history of past applications, identification cards, and authentication information may be displayed.

The type of information displayed on the screen is not limited, and information selected by the user within a preset list may be selectively displayed on the screen.

In an embodiment, a rating may be assigned for each user's account. For example, the user's rating may be calculated and assigned based on various criteria, such as the amount of BAAS or BIDT possessed, the number and duration of service use according to the disclosed embodiment, but is not limited thereto.

In another embodiment, the grade may refer to the level of authentication performed by the user. For example, as described above, the user's authentication includes e-mail authentication, SMS authentication, KYC authentication, etc. step by step, and the level of authentication previously performed by the user may be displayed as a grade.

In an embodiment, different benefits may be given to each user for each level. For example, as the user's rating increases, the amount of BIDT that can be acquired as a reward per day or the number of times that BIDT can be acquired may increase, but the present invention is not limited thereto. As another example, the higher the user's rating, the lower the fees for cryptocurrency transactions.

Also, as the user's rating increases, the number of targets that can use the electronic identification card according to the disclosed embodiment may be expanded. For example, in the case of a low grade, an electronic identification card can be used only for logging in on a specific website, but as the grade increases, the types of websites that can be logged in using an electronic identification card may vary. In addition, when the grade increases, not only login but also user authentication may be performed using an electronic identification card. In addition, the field in which the electronic identification card can be used may expand, but is not limited thereto.

14 is a diagram illustrating an example of a screen providing an electronic wallet function of a wallet.

Referring to FIG. 14, information on one or more cryptocurrencies that may or may be stored in a wallet is displayed on the screen. The type of cryptocurrency displayed on the screen is not limited, and a list of cryptocurrencies selected by the user among one or more cryptocurrencies that can be stored or stored in the wallet may be displayed.

In addition, according to an embodiment, a list of cryptocurrencies that have been stored in the wallet more than once may be displayed on the screen, and cryptocurrencies may be displayed on the screen according to various criteria.

In one embodiment, the above-described BAAS coin may be displayed on the screen, and the amount of holding the coin and the corresponding cash value or the current price per coin may be displayed, and the type of displayed information is not limited.

In addition, tokens such as BIDT and their holdings may be displayed in the wallet.

In one embodiment, even in a form of cryptocurrency that cannot be directly exchanged for cash, such as BIDT, the cash value may be displayed on the screen by calculating the exchange value.

Depending on the embodiment, even the cryptocurrency held by the user may be hidden without being displayed on the screen, and the amount of each cryptocurrency may also be displayed on the screen, but may not be displayed according to the user's selection.

15 is a diagram illustrating an example of a screen providing a drive function of a wallet.

Referring to FIG. 15, categories of one or more items provided through a wallet drive may be displayed on a screen.

For example, categories of items that can be stored and provided through the drive may include memos, passwords, documents, photos, credit cards, and videos, but are not limited thereto.

As described above, since information stored through the drive is distributed and stored based on a block chain, it provides high security compared to general storage media or cloud storage space.

A method for distributed storage of data based on the blockchain will be described later.

In addition, if there is no information stored in the user terminal 300, it is impossible to check the contents in the drive manager and the server, and the information stored in the user terminal 300 is provided with authentication information (e.g., biometric information, etc.) ), access is impossible without it.

For example, when executing an application according to the disclosed embodiment, the user terminal 300 may request the user to provide authentication information. In addition, when performing application-based authentication for website login, user authentication, and drive access, the user terminal 300 may request the user to provide authentication information.

Therefore, even when the user terminal 300 is lost or when the user terminal 300 is used by another person, information stored in the drive is set to be impossible to obtain, and only when the user himself or herself directly uses the user terminal 300 It is configured to only check the information stored on the drive.

Accordingly, in addition to general documents, files, and memos, the user may safely store confidential information that cannot be disclosed to the outside, personal ID and password information, credit card, and other payment information in the drive according to the disclosed embodiment.

However, there may be cases in which it is impossible to access at least some of the data distributed and stored in different nodes. For example, communication with at least some of the nodes may be difficult, at least some of the nodes may fail, or at least some of the nodes may cease to function as nodes.

In order to prepare for such a case, in the disclosed embodiment, a safe node may be provided so that all data stored in the drive may be stored together in the safe node.

Accordingly, when it is difficult to obtain specific data from a node included in the distributed storage network, the data may be obtained from a safe node and provided to the user terminal 300.

As described above with reference to FIGS. 12 to 15, the wallet application according to the disclosed embodiment may provide an integrated service including a user's authentication information, an electronic ID card, an electronic wallet, and a drive storing various types of information.

Accordingly, it is possible to increase the user's convenience in use and at the same time provide a service having high security that is safe from leakage of personal information or hacking, etc., thereby providing a user experience differentiated from existing services.

16 is a diagram illustrating a method of distributed storage and combination of data according to an embodiment.

As described above, the system according to the disclosed embodiment is characterized in that it is configured to safely store data by distributing and storing data, and to make it impossible to check the stored data without the user's authentication through the user terminal 300. .

Each of the steps of the embodiments described below may be performed by the server of the system according to the disclosed embodiment, but is not limited thereto. In one embodiment, the server mentioned in this embodiment may correspond to the above-described authentication server 100.

In an embodiment, the server 100 obtains input data 1000 for storage in the system from the user terminal 300. The type of input data 1000 stored in the system is not limited, and may include authentication data such as personal identification information, payment information, and file information such as text, image, video, voice, and document. . In the disclosed embodiment, a file refers to all types of data usable in a computer, and for example, a document may include hwp, doc, pdf, etc., but is not limited thereto.

That is, the distributed storage method according to the present embodiment may be used to provide the electronic identification card shown in FIG. 13 and the drive service shown in FIG. 15.

In one embodiment, the server 100 performs preprocessing on the input data 1000. A detailed preprocessing method of the input data 1000 will be described later.

In one embodiment, the server 100 calls the SPLIT module, and the SPLIT module divides the input data 1000 into a plurality of pieces. A specific method of dividing data into a plurality of pieces and the number of pieces into which the input data 1000 is divided are not limited.

In an embodiment, the server 100 stores the divided pieces by using the IPFS (Inter-Planetary File System) system 1100. The IPFS system 1100 divides and stores data in the distributed storage network 1200, and stores the hashed value 1002 in the blockchain 1110. The data divided and stored in the distributed storage network 1200 may be searched and acquired based on the hash value 1002 of the data.

In one embodiment, the IPFS system 1100 divides and stores data fragments divided by the SPLIT module in the distributed storage network 1200, and stores the hashed data 1002 in the blockchain 1110. .

In an embodiment, the distributed storage network 1200 is composed of a plurality of nodes, and pieces of data may be distributed and stored in each node. In an embodiment, the IPFS system 1100 may store information on a location where pieces of data are distributed and stored, which may be searched based on a hash value 1002 of data. According to an embodiment, each of the nodes included in the distributed storage network 1200 may store information on other nodes that store different pieces of data of the same data.

In another embodiment, the IPFS system 1100 divides the data fragment itself divided by the SPLIT module again using the partitioning tool of the IPFS system 1100, hashes each of the divided data pieces, and uses the You can also save it.

The IPFS system 1100 returns the hash value 1002 stored in the block chain 1110, and the server 100 may store at least a portion of the returned hash value 1002. According to an embodiment, the server 100 may re-distributedly store the returned hash value 1002, and detailed information about this will be described later.

Thereafter, in the case of obtaining distributedly stored data, the server 100 may obtain pieces of data stored in the distributed storage network 1200 based on the hash value 1002.

The server 100 may obtain data by calling the MERGE module and merging pieces of data obtained from the distributed storage network 1200.

The server 100 may obtain the final data 1010 through post-processing corresponding to the pre-processing performed on the data, and a detailed post-processing method performed to obtain the final data 1010 will be described later.

In one embodiment, the input data 1000 and the acquisition data 1010 shown in FIG. 16 may be the same data, or the input data 1000 according to a pre-processing and post-processing method performed on the input data 1000 And the acquired data 1010 may be different from each other.

For example, when the input data 1000 is authentication data, the input data 1000 and the acquired data 1010 may be different from each other, which will be described later with reference to FIG. 18.

17 is a diagram illustrating a method of pre-processing and post-processing data according to an exemplary embodiment.

Referring to FIG. 17, a distributed storage system as shown in FIG. 16 is shown.

In an embodiment, the server 100 may perform de-identification of the input data 1000 obtained from the user terminal 300. For example, the server 100 may de-identify the user's personal identification information obtained from the user terminal 300. In the disclosed embodiment, personally identifiable information refers to information about a surviving individual, which can identify an individual by the information. That is, it includes information capable of identifying an individual by combining with one or more other information, and may include, for example, personal information, sensitive information, biometric information, and the like.

De-identification is to process and alter the original data so that the contents of the original data cannot be directly grasped, and is performed in the preprocessing stage of data storage. In general, it is used to make it impossible to identify personal information included in data, but is not limited thereto.

The de-identification method for the input data 1000 is not limited to a specific method, but an example of a specific de-identification method that can be used in the disclosed embodiment will be described later.

In one embodiment, the server 100 may encrypt data that has been de-identified. The specific technique or algorithm used for encryption is not limited, but encryption may be performed by, for example, the AES256 algorithm.

The encrypted data may be divided into data pieces after a division setting including whether or not to be divided, a division size, and the number of divisions is determined by the SPLIT module. A method of performing the division setting is not limited, but a division setting preset by the user may be applied. In this case, the division setting may be transmitted to the SPLIT module by a configuration file. Further, the division setting may be automatically determined by the SPLIT module based on the size and type of data.

The data fragments divided by the SPLIT module are transferred to the IPFS system 1100, and the IPFS system 1100 stores the divided data fragments in nodes of the distributed storage network 1200, and hash result ( 1002) is returned.

When attempting to obtain distributedly stored data, the server 100 acquires pieces of data from the IPFS system 1100 based on the hash value of the data as described above, and then calls the MERGE module to combine the data.

The server 100 decrypts the combined data, and the algorithm used for decryption is not limited, but as described above, when the data is encrypted based on the AES256 algorithm, the data may be decrypted using the same method.

The server 100 may obtain the final data 1010 by removing the de-identification code from the decoded data.

The server 100 may be configured to remove the de-identification code from the de-identified data by storing information on a method used to de-identify data or by storing a de-identification rule of data. .

According to the embodiment illustrated in FIG. 17, the input data 1000 illustrated in FIG. 17 and the finally acquired acquired data 1010 may be identical to each other. This may be different when the system according to the disclosed embodiment is used for storing and authenticating authentication information.

18 is a diagram illustrating an authentication system through distributed storage and combination according to an embodiment.

In an embodiment, the server 100 may obtain the authentication data 1000 from the user terminal 300. For example, the authentication data 1000 may include the above-described EID or personal identification information of the user, but is not limited thereto.

In an embodiment, the server 100 may hash the authentication data 1000.

In the case of authentication data, it is common to store a hash value other than the original for security. In addition, in the case of authentication data, since only the identity with the stored authentication data during authentication needs to be checked, the server 100 performs a hash on the authentication data 1000.

Subsequent procedures are as described with reference to FIG. 17. In one embodiment, the server 100 de-identifies the hash value of the authentication data 1000 and encrypts the de-identified data. The server divides the encrypted data using the SPLIT module, and the divided data pieces are distributed and stored based on the IPFS system 1100.

In an embodiment, the server 100 may receive an authentication request from the user terminal 300. The server may hash the authentication information 1020 received together with the authentication request, and according to an embodiment, the hashed authentication information 1030 may be received from the server together with the authentication request.

The server acquires data pieces in which the user's authentication data 1000 is distributed and stored from the IPFS system 1100, and combines the acquired data pieces using the MERGE module. The server decrypts the combined data and obtains the hashed authentication data 1010 by removing the de-identification code from it.

The server may compare the hash value 1030 of the authentication data 1020 obtained together with the authentication request with the data 1010 obtained from distributedly stored data, and determine whether or not the authentication is successful.

19 is a diagram illustrating a de-identification method according to an embodiment.

In the disclosed embodiment, the server performs de-identification of data as one of the preprocessing steps before distributed storage of the data. In an embodiment, de-identification of data may be performed before encryption of data. In addition, de-identification of data may be performed in a step after hashing of data.

In the disclosed embodiment, the de-identification of data is performed by processing the data in a manner that combines the data 1300 and characters randomly extracted from a random character set (Random Character Set) 1350.

The types of characters included in the random character set 1350 are not limited, and the random character set 1350 may be commonly used or may be changed according to a preset criterion. According to an embodiment, the random character set 1350 is different for each user. ) May be used.

Also, a method of combining the characters extracted from the random character set 1350 and the data 1300 is not limited. For example, the server 100 may determine the location where the characters extracted from the random character set 1350 are combined in the data 1300 to be de-identified, which may be determined according to a preset rule, or It may be decided. The server 100 may combine characters extracted from the random character set 1350 at the determined location, and the order in which the extracted characters are combined may also be determined in various ways.

In addition, the method in which the de-identification code (character extracted from the random character set) is combined with the data 1300 is not limited, and data is calculated using the de-identification code as well as simple insertion as shown in FIG. By doing so, a method of processing the data can also be used.

Information on a location or a combination rule to which the de-identified data is combined may be stored separately to remove the de-identification code of the de-identified data later.

20 is a diagram illustrating a method of distributing and combining data based on a connector according to an embodiment.

Referring to FIG. 20, a data distributed storage system as shown in FIG. 16 is shown. However, in FIG. 20, instead of the IPFS system shown in FIG. 16, a distributed storage network 1200, a blockchain 1400, and a connector 1250 are shown.

In an embodiment, the server 100 may generate data fragments by performing preprocessing on the input data 1000 and then calling the SPLIT module to divide the data.

The divided data pieces are distributedly stored in nodes of the distributed storage network 1200, and a connector 1250 is generated as information for tracking distributed stored data. According to an embodiment, a fragment distribution map indicating a relationship between the connector 1250 and nodes in which data is distributed and stored may be generated and stored.

In an embodiment, the fragment distribution map may include information on a node in which data fragments are stored in the distributed storage network 1200 and information on an order in which the data fragments are stored. The server 100 may use the connector 1250 to search for information on data to be tracked in the fragment distribution map, and track data pieces based on the searched information.

In addition, the connector 1250 may be distributed and stored in the blockchain 1400. For example, the connector 1250 may be divided into two or more pieces, and distributed and stored in two or more nodes of the blockchain 1400.

In an embodiment, a connector distribution map including information on the location of a node in which the connector 1250 is stored may be generated and stored.

When it is necessary to obtain distributedly stored data, the server 100 may obtain the connector 1250 from the blockchain 1400 based on the connector distribution map. In addition, the server 100 may acquire pieces of data stored in the distributed storage network 1200 by using a connector and a piece distribution map.

Thereafter, the server 100 may call the MERGE module to combine data pieces and post-process the data to obtain data.

In the embodiment shown in FIG. 20, the distributed storage network 1200 is in the distributed storage network 1200 shown in FIG. 16, and the blockchain 1400 is in the block chain 1110 inside the IPFS system shown in FIG. Each may correspond, and according to an embodiment, the connector 1250 may correspond to the hash value 1002 of data shown in FIG. 16.

21 is a diagram illustrating a data distribution storage system including a user terminal according to an embodiment.

Referring to FIG. 21, a distributed storage system for data similar to that shown in FIG. 16 is shown.

However, according to the embodiment shown in FIG. 21, by participating the user terminal 300 in the distributed storage process, the distributed storage data cannot be obtained without the user terminal 300.

In an embodiment, the server 100 performs pre-processing on the input data 1000, divides the data into a plurality of data pieces based on the SPLIT module, and then distributes and stores the data through the IPFS system 1100.

The server 100 may return a hash value 1002 of data from the IPFS system 1100, and may search for and obtain pieces of data from the IPFS system 1100 using the hash value 1002 of the data.

The server 100 divides the returned hash value 1002 into M:N, transmits M% to the user terminal 300, and distributes and stores N% to the blockchain 1500. The type and composition of the blockchain in which N% of hash values are stored are not limited.

In one embodiment, the sum of M% and N% is configured to be 100%, and the specific ratio is not limited, but for example, the hash value is divided so that M% is 51% and N% is 49%. I can. However, the ratio of M% and N% for dividing the hash value is not limited thereto, and may be variously set according to the user's setting or the characteristics of the data, and may be changed flexibly.

The user terminal 300 stores a hash value of M% received from the server 100 based on the above-described application. For example, the hash value of M% may be stored through the application together with the user's authentication data.

M% of data stored in the user terminal 300 is not stored in the server 100 or the blockchain 1500, or is stored in a form that cannot be accessed without user authentication, so that the user does not provide M% of data. Otherwise, the server 100 may be configured so that the stored data cannot be obtained.

In one embodiment, the user may lose the user terminal 300 in which M% of data is stored, or the user terminal 300 may be damaged without being backed up.

In preparation for such a case, the server 100 separately stores data related to the user's account, and when information for recovering the user's account is obtained through the user terminal 300, the recovery data may be transmitted to the user terminal. .

In an embodiment, a mnemonic code including 12 words based on the BIP 39 standard may be used to restore a user account, but is not limited thereto.

In one embodiment, the mnemonic code may be stored in a safe node in order to prepare for a case in which the mnemonic code used for recovery of a user account is lost. In an embodiment, the secure node may be configured in the form of a private blockchain, and data stored in the secure node may be distributed and stored through a partitioning method according to the disclosed embodiment. In another embodiment, data for recovery may be stored or some information may be backed up through a user's private cloud configured in the form of a private blockchain separate from the safety node.

The safety node is managed by a plurality of administrators, and when a user requests recovery, the mnemonic code is provided to the user terminal 300 from the safety node only after approval of all administrators.

When a single administrator manages the safety node, the administrator can arbitrarily leak the mnemonic code of a specific user, and it is configured so that the user terminal 300 can acquire the mnemonic code stored in the safety node only when all the administrators have signed it.

In addition, when the user terminal 300 creates an account and installs a wallet, a one-time key pair may be generated for later recovery. The disposable key pair includes a private key and a public key, the private key is stored in the user terminal 300, and the public key can be distributed in a blockchain.

When a user wants to recover an account, the user terminal 300 may request a mnemonic code from the secure node. When approval and signature of a plurality of administrators managing the secure node are completed, the mnemonic code stored in the secure node is encrypted with the user's public key and transmitted to the user terminal 300.

In other words, the administrator only has the authority to approve recovery, but does not hold the user's private key, so the authority to check the contents is not granted.

The user terminal 300 may obtain a mnemonic code by decrypting the encrypted data using the private key, and recover the account using this. When account recovery is complete, the disposable key pair can no longer be used and discarded.

Depending on the embodiment, the user's private key may be stored in the secure node.

In addition, as described above, M% of data stored in the user terminal 300 may also be stored in the safe node and recovered using the above-described method.

The above-described mnemonic code and private key are divided by the method according to the disclosed embodiment, and M% of the divided data may be stored in a secure node of the OSP, and N% of the data may be distributed and stored in a private blockchain.

Distributed-stored data is acquired and combined at the time of a recovery request, and data used for recovery can be discarded (deleted) without being stored in the system.

In an embodiment, for restoring a user account or backed up data, verification based on user information and secondary verification using biometric information of the user may be essentially performed. For example, it may be set so that secondary authentication based on FIDO (Fast Identity Online) is essentially performed for account recovery. Biometric information of a user may be used for FIDO authentication, but is not limited thereto.

As described above, in that the secure node is managed by a plurality of administrators, requires approval and signature of all the plurality of administrators, and data transmission is performed based on a user's asymmetric key pair, the user terminal 300 It plays the same role as a private storage space that is directly connected 1:1 with each other. In other words, since the administrator cannot arbitrarily approve the data export or check the contents of the data, it is possible to provide security such as a storage space (for example, a storage token or user terminal, etc.) physically held by the user. have.

Accordingly, the user's private key, M% data, mnemonic code, etc. according to the disclosed embodiment may be stored not only in the user terminal 300 but also in the secure node.

In addition, information stored in the safe node may be distributed and stored through a partitioning method according to the disclosed embodiment, and may be combined and used when used.

In one embodiment, a cold wallet service using a safety node may be provided. A cold wallet generally stores the wallet in a physical storage device owned by a user, but according to the disclosed embodiment, a cold wallet may be implemented using a safety node that provides the same level of security as a physical storage device.

For example, a user's private key may be distributed and stored in a cold wallet. When a user requests a transaction, as described above, the use of the private key can be permitted through the approval and signature of multiple administrators, and the private key distributed in the secure node is combined and used to sign the transaction, and then the private key Both the information used to combine and the combined private key can be discarded.

22 is a diagram illustrating a method of acquiring data through combination in a distributed storage system including a user terminal according to an exemplary embodiment.

In an embodiment, the server 100 may obtain M% of information distributed and stored in the user terminal 300 from the user terminal 300.

In addition, the server 100 may obtain the remaining N% of information corresponding to this from the blockchain 1500.

The server 100 may obtain result data by combining M% of data and N% of data. In an embodiment, the result data may be a hash value 1002 of data used to acquire data in the IPFS system 1100, but is not limited thereto.

The server may obtain data pieces stored in the distributed storage network 1200 through the IPFS system 1100 and merge the obtained data pieces to obtain data.

23 is a diagram illustrating a one-time authentication method according to an embodiment.

As described with reference to FIG. 22, the server 100 obtains M% of data from the user terminal 300 and N% of data from the block chain 1500.

The server 100 acquires information for data acquisition (eg, hash value of data) by combining M% data and N% data, and is distributed and stored from the IPFS system 1100 based on the obtained information. Acquire the data.

However, when information obtained by combining M% of data and N% of data is stored in the server 100, there is a problem that the advantages of the distributed storage system according to the disclosed embodiment disappear.

Therefore, when the use of information obtained by combining M% of data and N% of data is completed (that is, when the acquisition of data distributed and stored in the IPFS system is completed), the server 100 is It is configured to discard the information obtained by combining% data.

In particular, the M% information obtained from the user terminal 300 must be discarded, and through this, the M% information obtained from the user terminal 300 is used once in the server 100 and must be discarded after use. Points must be guaranteed.

This may mean that the authentication is performed once in the user authentication method using the system according to the disclosed embodiment. For example, when the user terminal 300 requests authentication from the server 100, the user terminal 300 may provide the authentication data and M% of information corresponding thereto to the server 100.

The server 100 may perform authentication by obtaining distributedly stored authentication data using M% information and comparing it with authentication data provided from the user terminal 300. When authentication is complete, the server 100 may be configured to discard M% information provided from the user terminal 300 and not perform authentication more than once using the information provided from the user terminal 300.

Through this one-time authentication method, the server 100 is configured to access the distributedly stored user authentication information only once only when an authentication request through the user terminal 300 is received. By preventing access to user authentication information, user authentication information can be more securely stored.

24 is a flowchart illustrating a method of distributedly storing and combining authentication information or files using the system according to the disclosed embodiment.

In an embodiment, the server 100 may obtain a request from the user terminal 300.

The server 100 may determine the type of request, for example, the type of request may include an authentication request and a file request.

When it is determined that the type of request is an authentication request, the server 100 may initiate an authentication step. The server 100 may determine whether the type of the authentication request is a request to store authentication data or a request to perform authentication.

When the type of the authentication request is a storage request for authentication data, the server 100 may call the SPLIT module after pre-processing the data to store the data distributedly in the IPFS module. When the type of the authentication request is a request to perform authentication, the server 100 may call the MERGE module to obtain the combination of authentication data distributed and stored in IPFS, and perform authentication.

Similarly, when it is determined that the type of the request is a file request, the server 100 may initiate a file management step. The server 100 may determine whether the type of the file request is a file storage request or a file acquisition (view or download) request.

When the type of the file request is a file storage request, the server 100 may call the SPLIT module after pre-processing of data to store the data distributedly in the IPFS module. When the type of the file request is a file acquisition request, the server 100 may call the MERGE module to obtain a combination of file data distributed and stored in IPFS, and provide it to the user terminal 300.

In the process of storing and acquiring a file, the server 100 may check whether the file is damaged. In addition, the server 100 may check the type of file through the properties of the file and determine a specific distributed storage method according to the type of file.

25 is a diagram illustrating a method of providing computing power and compensating for it according to an exemplary embodiment.

Referring to FIG. 25, a BaaSid system 1600 and user terminals 1700 providing computing power to the BaaSid system according to the disclosed embodiment are illustrated.

In an embodiment, the user terminals 1700 may entrust at least a portion of each computing power to the BaaSid system 1600 according to the disclosed embodiment. For example, computing power may refer to CPU, RAM, and network resources, but is not limited thereto.

The BaaSid system 1600 may pay a compensation to a user terminal in exchange for providing computing power. Although the form and amount of the reward to be paid are not limited, for example, the server 100 may quantitatively measure the amount of computing power entrusted by the user, and may provide a reward in proportion to the amount. Reward may be paid in BRC or BIDT described above.

The user terminal may determine the amount of computing power to be entrusted and the entrusted period, and compensation may be set differently according to the amount of computing power and the entrusted period. For example, as the user terminal sets the consignment period longer, the amount of compensation per unit period may increase.

However, if the user terminal terminates the deferral of computing power before the contracted consignment period expires, the amount of compensation paid may be adjusted.

The computing power provided from the user terminals 1700 may be utilized to improve storage space, processing capability, and communication capability of the system according to the disclosed embodiment.

According to an embodiment, a compensation may be paid to each user terminal corresponding to a node constituting the distributed storage network 1200 shown in FIG. 16. For stable storage and maintenance of information stored in each user terminal, the server 100 may pay a compensation, and similarly, the compensation may be paid in the form of BRC or BIDT.

In one embodiment, when a node storing specific information wants to end its role, the server 100 must request termination in advance so that the server 100 transfers the information to another node and stores the information stably. Can be managed.

In one embodiment, in order to induce the end of the role of the node, the server 100 notifies the end of the role of the node, and after the information stored in the node is transferred to another node and stored, the compensation for the node is calculated and paid, or Rules such as paying additional rewards to nodes can be set.

In addition, the server 100 may also pay compensation for the BP 900 maintaining the blockchain system as described in connection with FIG. 8. Rewards can be paid in the form of BRC, and in the case of a DPoS-based blockchain system, a preset number (for example, 21) of BPs can be elected based on the votes of members. The elected BP plays a role in maintaining the stable blockchain system and obtains rewards for it.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the drawings.

26 is a flowchart illustrating a method of obtaining data through search and combination of data distributedly stored in a block chain according to an embodiment.

The following embodiments are based on the contents described above with respect to FIGS. 1 to 25, and even though the contents are omitted with respect to FIG. 26, the contents described with respect to FIGS. 1 to 25 may be applied to the present embodiment. have.

In step S110, the computer may acquire the search value stored in the blockchain.

In an embodiment, the computer may obtain the M% of the segment divided by the search value from the user terminal. The computer may obtain the remaining N% of the segment divided by the search value from the blockchain, and restore the search value by combining the M% and the N% divided pieces.

In step S120, the computer may acquire pieces of data distributedly stored in the distributed storage network by using the search value.

In an embodiment, the computer may obtain pieces of data distributedly stored in the distributed storage network using a search value restored by combining pieces obtained from the user terminal and the block chain, respectively.

In one embodiment, the computer may discard the restored search value so that it cannot be reused.

In an embodiment, the computer may transmit the search value to a preset IPFS system and obtain the data pieces from the IPFS system. In this case, the search value may mean a hash value of data stored in the IPFS system.

In step S130, the computer may assemble the data pieces.

In step S140, the computer may post-process the combined data to obtain result data.

In an embodiment, the computer may decode the combined data and remove the de-identification code from the decoded data.

In an embodiment, the computer may obtain authentication request data from the user terminal. The computer may hash the authentication request data, and compare the hashed value with the result data.

The computer may obtain an authentication result according to the comparison result. For example, if the result data and the hashed authentication request data match, it may be determined that authentication is successful, but the present invention is not limited thereto.

27 is a block diagram of an apparatus according to an embodiment.

In one embodiment, device 10 includes a processor 12 and a memory 14.

The processor 12 may include one or more cores (not shown) and a graphic processing unit (not shown), and/or a connection path (eg, a bus) for transmitting and receiving signals with other components. .

The processor 12 according to an embodiment executes one or more instructions stored in the memory 14 to perform the method described with reference to FIGS. 1 to 26.

On the other hand, the processor 12 is a RAM (Random Access Memory, not shown) and a ROM (ROM: Read-Only Memory) that temporarily and/or permanently store signals (or data) processed inside the processor 12. , Not shown) may further include. In addition, the processor 12 may be implemented in the form of a system on chip (SoC) including at least one of a graphic processing unit, RAM, and ROM.

The memory 14 may store programs (one or more instructions) for processing and controlling the processor 12. Programs stored in the memory 14 may be divided into a plurality of modules according to functions.

Hereinafter, another embodiment of the present invention will be described. The embodiments described below are for explaining examples of the technical field to which the present invention can be applied or to which the present invention can be applied, and the following components are not necessarily included in the present invention or the configuration of the present invention is not limited thereto.

In an embodiment, the server 100 may transmit a push message to the user terminal 300 to initiate an authentication procedure. For example, reference may be made to the embodiment shown in FIG. 6.

However, in some embodiments, it may be difficult to receive a push message from the user terminal 300.

For example, the application installed in the user terminal 300 may be in a state in which the reception of the push message is rejected, or the application may not be in a state in which it is operating in the background so that the push message can be received.

In one embodiment, the server 100 determines whether the user terminal 300 is in a state in which the push message reception is possible, and when it is determined that the user terminal 300 is in a state in which it is difficult to receive the push message, an SMS, Text messages such as LMS and MMS may be transmitted to the user terminal 300.

In another embodiment, when the user terminal 300 cannot receive the push message, the server 100 may send a text message to the user terminal 300 through another terminal.

In one embodiment, the terminals capable of sending text messages to each other by the server 100 may be terminals previously registered with the server 100 based on an application or application and approval from each terminal.

For example, when a second user terminal is registered with the server 100 based on mutual application and approval for a first user terminal, the first user terminal is a terminal that cannot receive a push message or sends a push message. When in a state where it cannot be received, the server 100 transmits a push message to a second user terminal in a state capable of receiving the push message, and the second user terminal generates a text message corresponding to the push message, and Can be transmitted to the terminal.

In this case, the message includes only a command for executing an application to start an authentication procedure, so that the personal information of the first user terminal is not shared or exposed to the second user terminal.

It may be difficult in the system for the server 100 to send a text message to each user terminal. Therefore, when the first user terminal cannot receive the push message, the server 100 sends a text message to the first user terminal through the second user terminal, and instead, the server 100 sends a predetermined message to the second user terminal. Reward can be provided. The provided compensation may be provided by the above-described BIDT or BRC, but is not limited thereto.

As another example, the terminals capable of sending text messages to each other by the server 100 may be terminals registered in a specific pool by approving the request of the server 100.

For example, unlike the one-to-one registration as in the above-described example, according to the present embodiment, a plurality of user terminals may be registered as a pool in the server 100 based on prior approval.

For example, the pool may include user terminals configuring nodes of a distributed storage network or block chain according to the disclosed embodiment, and may also include user terminals that provide computing power to the BaaSid system according to the disclosed embodiment. However, it is not limited thereto.

As another example, the pool may be composed of at least some of the managers managing the BP or the safe node according to the disclosed embodiment.

In one embodiment, the server 100 transmits a query message to check whether the push message reception is possible to the first user terminal, and when a reply to the query message is received from the first user terminal, the first user terminal When a push message is transmitted to the user terminal and a reply is not received from the first user terminal, at least one terminal capable of receiving a push message is selected from among the user terminals registered in the pool, and the push message is transmitted to the terminal. You can request to send a text message to the user terminal.

In an embodiment, the server 100 may transmit a push message requesting to send a text message to the user terminal 300 to another user terminal even when the text message transmission failure information is received from the user terminal 300.

In one embodiment, the server 100 may pay a predetermined reward to user terminals registered in the pool. The frequency, degree and method of compensation payments are not limited.

In order to perform the above-described embodiment, the user terminal 300 receives a text message transmission approval request from the server 100 to the first user terminal, and transmits approval information for the approval request to the server. , Storing information on the first user terminal, including the phone number of the first user terminal, receiving a first push message including message transmission request information for the first user terminal from the server Steps, acquiring content included in the first push message, generating a first text message using content included in the first push message, and receiving a first phone number included in the first push message Obtaining, comparing the first phone number with the phone number of the first user terminal, and when the first phone number and the phone number of the first user terminal match, the first phone number 1 Transmitting a text message, transmitting a transmission result of the first text message to the server, acquiring a point corresponding to the transmission result of the first text message from the server, from the server to a first pool Receiving a registration request for, transmitting approval information for the registration request to the server, receiving an encryption key corresponding to the first pool from the server, included in the first pool from the server Receiving a second push message including message transmission request information to a second user terminal, acquiring content included in the second push message, and using content included in the second push message. Generating a text message, encrypting the second text message using the encryption key, obtaining a second phone number included in the second push message, and sending the encrypted second text message to the second text message. 2 Transmitting to a phone number, transmitting a transmission result of the second text message to the server, and a point corresponding to the transmission result of the second text message from the server The step of acquiring the data may be performed.

In addition, the user terminal 300 may transmit a failure to send the text message to the server 100 when the text message transmission fails.

In addition, the user terminal 300 includes receiving a third text message from a third user terminal when receiving a text message, confirming whether the third text message is encrypted, and the third text message is encrypted. If present, decrypting the third text message using an encryption key, comparing the content of the push message with the content included in the third text message, and the content of the push message and the third text message If the included content matches, transmitting the fact that the third text message was acquired to the server may be performed.

The encryption key according to the present embodiment may be stored in the wallet of each user terminal, but is not limited thereto. For example, the encryption key may be stored in a secure node or distributedly stored in a distributed storage system according to the disclosed embodiment.

When the encryption key is stored in the secure node, and the pool for sending text messages according to the disclosed embodiment is composed of administrators of the secure node, the text message to the user terminal may be sent only when approval and signature of all administrators are made. have.

In addition, the server 100 encrypts the contents of the message with a public key corresponding to the private key stored in the user terminal 300 and delivers it to an intermediate forwarder through a push message, and the intermediate forwarder to the user terminal 300 through a text message. By transmitting, only the user terminal 300 can check the contents of the message.

In an embodiment, the server 100 or the OSP 200 may transmit ticket information to the user terminal 300 using a QR code. In an embodiment, when the QR code is transmitted to another terminal and displayed through a display, the user terminal 300 may acquire ticket information by photographing and scanning the QR code, and initiate a device registration procedure.

In another embodiment, when the QR code is directly transmitted to the user terminal 300, the user terminal 300 captures the QR code image, analyzes the captured image, and obtains information stored in the QR code based on this. have.

In one embodiment, the QR code transmitted to the user terminal 300 may be divided, rotated, and reassembled into preset pieces to prevent information leakage due to image leakage. For example, the QR code may be divided into a plurality of pieces, rotated and recombined according to a preset rule. The user terminal 300 may obtain a final QR code image by dividing, rotating, and recombining the obtained QR code image according to a preset rule, and analyzing the obtained image to obtain information included therein.

For example, the QR code may be transmitted to the user terminal 300 by dividing the original QR code image by nine, rotating at least a part of each divided image by 90 degrees, rearranging the divided image.

These division and recombination rules may be determined based on a preset rule table, which may vary over time. For example, by searching the index of the rule table, a corresponding rule may be obtained, and the index of the rule table may be calculated based on the OTP value. That is, the OTP value changes over time, and the rules for dividing, rotating, and combining codes change accordingly. Even if the QR code image is leaked, information leakage based on this can be prevented.

In addition, data stored in the QR code may also be encrypted or de-identified based on the OTP value as described above.

In the method of de-identifying data according to the disclosed embodiment, a method in which a character extracted from a random character set is inserted in an arbitrary position of data as shown in FIG. 19 may be used.

The configuration of the random character set, a method of extracting a character from the random character set, and a method of determining a location of data to insert the extracted character are not limited, but the following method may be used according to embodiments.

In an embodiment, the server may analyze data to be de-identified and generate m strings of n characters that do not appear in target data to be de-identified. According to an embodiment, n characters may be determined as the minimum number of characters for acquiring m character strings that do not appear in target data to be de-identified, but is not limited thereto.

The server may generate a random character set including the determined m character strings.

In an embodiment, the random character set may include m strings determined and strings in which a preset number of random characters are combined before and after m strings.

In one embodiment, m strings may consist of only strings included in 12 mnemonic code words used to create a user's account, and n and m may be determined as numbers satisfying this condition, but are limited thereto. It does not become.

In an embodiment, the server may perform de-identification by inserting a character string included in the random character set into an arbitrary position of data. Depending on the embodiment, the character string may be inserted in a continuous form, but may be inserted at a preset interval or a position calculated based on a preset rule.

The server may store the rules used for de-identification, and perform de-identification code removal based on the stored rules later.

In an embodiment, the server may perform de-identification code removal by searching for character strings included in the random character set from de-identified data and removing the searched character strings.

Depending on the embodiment, a specific number of characters may be combined before or after the character string according to the result of calculating each character string. For example, a character corresponding to a specific value calculated using a first equation based on ASCII codes of characters included in the character string may be inserted before or after the character string. Also, the position and number of characters to be inserted may be determined through a value calculated using the second equation.

That is, by storing information on strings belonging to the random character set and formula information for string operation, the de-identification code can be removed without directly storing the location where the de-identification code is stored or information on the corresponding code. I can.

According to an embodiment, information on character strings belonging to the random character set may also be reconstructed based on the user's mnemonic code. For example, strings belonging to the random character set are configured to be extracted from strings belonging to the user's mnemonic code, and by sharing the rules for extracting strings including how many characters from the number of characters of each word, The random character set can be reconstructed without storing it separately. The rule for extracting the character string may be calculated to satisfy the calculation conditions of n and m, stored and shared, as described above, but is not limited thereto.

In one embodiment, in dividing the hash value returned from the IPFS system into M:N, the M:N division ratio may be variously set, and a method of dividing the hash value returned from the IPFS system into the M:N ratio is also not limited.

For example, the division may be performed based on the number of characters, or may be performed by dividing the hash value into a plurality of character strings in units of a preset number of characters and then storing each character string in a distributed manner. Distributed stored information can be recombined and restored in sequence.

As another example, the partitioning of the hash value may be performed based on the ASCII code constituting it, not a character or string. For example, the number of ASCII codes constituting a specific character can be divided by M:N ratio and stored in the user terminal and the blockchain, respectively, and a method of recovering the original character by summing the values obtained from both can also be used. I can.

In an embodiment, a user may perform distributed storage using a plurality of terminals. For example, the M% value stored in the user terminal according to the user's setting may be distributed and stored in two different terminals again.

In this case, when a user requests stored data through the first terminal, authentication and data transmission through the second terminal must be performed together. This may be done for the type of data to be stored, or for specific data for which the user has chosen to enhance security.

For example, when a user selects security using multiple terminals for specific data, M% of the value for searching the data is distributed and stored in multiple terminals, authentication is performed from all terminals, and distributed stored M If the value of% is collected, it may be configured to allow access to the desired data.

In an embodiment, after M% and N% are collected and used for data acquisition, the collected data is discarded, thereby preventing recycling.

In an embodiment, a means may be provided to ensure the destruction of the collected data.

For example, a series of processes including data collection, search based on the collected data, and deletion of the collected data can be performed based on the smart contract of the blockchain.

In this case, as long as there is no problem with the integrity of the smart contract, it can be guaranteed that the collected data is necessarily discarded after use. This can also be used to externally guarantee that the used data will be discarded by disclosing the contents of the smart contract.

In addition, in the system for receiving computing power according to the embodiment shown in FIG. 25 and paying compensation in response thereto, each terminal providing computing power will be configured to receive a compensation corresponding to the actual amount of computing power provided. May be. In this case, the server may calculate the amount of computing power that can be provided by each terminal based on the performance of each terminal providing computing power and an upper limit of the set amount of provision when there is a total amount of computing power required.

The server may calculate an amount of computing power that each of the contracted terminals can provide, and may distribute and use computing power proportional to the calculated amount. Accordingly, the more a user contracts to provide a high-performance terminal and to provide more computing power, the more rewards can be obtained.

Also, according to an embodiment, a dedicated terminal used only to provide computing power to the system may be registered.

The dedicated terminal may refer to a terminal having a performance equal to or greater than a preset standard and contracted to provide all computing power to the system according to the disclosed embodiment. The compensation ratio according to the dedicated terminal setting may be set differently from the general terminal.

In an embodiment, as compensation for payment of computing power, the cost of using the wallet application and all services according to the disclosed embodiment may be discounted or replaced. According to an embodiment, when the amount of compensation exceeds the cost of using the service, a BIDT or BRC-based compensation may be paid for the excess amount.

The steps of a method or algorithm described in connection with an embodiment of the present invention may be implemented directly in hardware, implemented as a software module executed by hardware, or a combination thereof. Software modules include Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), Flash Memory, hard disk, removable disk, CD-ROM, or It may reside on any type of computer-readable recording medium well known in the art to which the present invention pertains.

Components of the present invention may be implemented as a program (or application) and stored in a medium in order to be executed in combination with a computer that is hardware. Components of the present invention may be implemented as software programming or software elements, and similarly, embodiments include various algorithms implemented with a combination of data structures, processes, routines or other programming elements, including C, C++ , Java, assembler, etc. may be implemented in a programming or scripting language. Functional aspects can be implemented with an algorithm running on one or more processors.

In the above, embodiments of the present invention have been described with reference to the accompanying drawings, but those of ordinary skill in the art to which the present invention pertains can be implemented in other specific forms without changing the technical spirit or essential features. You can understand. Therefore, the embodiments described above are illustrative in all respects, and should be understood as non-limiting.

Claims (9)

In the method performed by a computer,
Obtaining a search value stored in the blockchain;
Obtaining pieces of data distributedly stored in a distributed storage network by using the search value;
Combining the pieces of data; And
Post-processing the combined data to obtain result data; Containing,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 1,
Post-processing the combined data,
Decoding the combined data; And
Removing a de-identification code from the decrypted data; Containing,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 2,
Obtaining authentication request data from a user terminal;
Hashing the authentication request data;
Comparing the hashed value with the result data; And
Obtaining an authentication result according to the comparison result; Further comprising,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 1,
The step of obtaining the search value stored in the blockchain,
Acquiring M% of the segment divided by the search value from the user terminal;
Acquiring the remaining N% of the fragment divided by the search value from the blockchain; And
Restoring the search value by combining the M% and N% divided pieces; Including,
Acquiring the data pieces,
Obtaining pieces of data distributedly stored in the distributed storage network by using the restored search value; Containing,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 4,
Acquiring the data pieces,
Discarding the restored search value; Further comprising,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 1,
Acquiring the data pieces,
Transmitting the search value to a preset IPFS system; And
Obtaining the data pieces from the IPFS system; Containing,
A method of acquiring data through exploration and combination of data distributed in the blockchain. The method of claim 6,
The search value is,
Characterized in that the hash value of the data stored in the IPFS system,
A method of acquiring data through exploration and combination of data distributed in the blockchain. A memory for storing one or more instructions; And
And a processor that executes the one or more instructions stored in the memory,
The processor executes the one or more instructions,
An apparatus for performing the method of claim 1. A computer program that is combined with a computer as hardware and stored in a recording medium readable by a computer to perform the method of claim 1.

Images