JP3230238U - A system for securely storing electronic data - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an advanced system for storing electronic data more safely. SOLUTION: A system receives a file of electronic information, stores it safely, and when the file is received, a hardware processor 126 that forms a fragment containing at least a first fragment and a second fragment of the file. It has a distributed data storage system having a plurality of nodes for storing blocks of information in a first non-temporary storage device, and a second non-temporary storage device outside the distributed data storage system. The processor stores the first fragment in a distributed data storage system and the second fragment in a second non-temporary storage device. The stored file is a biometric or partial biometric file, which may be encrypted or hashed. File fragments preferably make no sense until they are encrypted and completely reconstructed. [Selection diagram] Fig. 1

Description

Cross-reference of related applications

This application relates to U.S. Patent Application Nos. 15 / 335,344 and U.S. Patent Application Nos. 14 / 940, 142 filed on October 26, 2016, both of which are incorporated herein by reference.

The present disclosure relates to systems and methods for securely storing electronic data.

Safely store all forms of electronic data such as data files, graphic files, image files, video files, biometric files, biometric data, and / or safely store the information regardless of file format. There is always a need to do. The development of the Internet has made it possible for anyone in the world to gain unauthorized access to an individual or entity's computer system, no matter how tightly protected it is. For example, cunning phishing scams, online viruses, Trojan horses, worms, etc. can steal usernames and passwords. Electronic ID theft and other cybercrime are rampant, and no one can be irrelevant.

Traditionally, there are numerous ways to combat unauthorized access. For example, one method is to train an individual to be aware of fraud. But humans are not perfect. There are a wide variety of things that can be expected to have some degree of protection, including the use of security software such as firewalls and antivirus applications. However, increasing the security level can reduce computer performance. Furthermore, / or it may be difficult for the user to access due to his / her own electronic data.

Two-factor or multi-factor authentication is known as a more secure method. Multi-factor authentication is a combination of two (in this case two-factor) or more individual (user) credentials. For example, a user may be required to enter a password and provide a security token or authentication token (a small hardware device carried by the user) in order for access to be granted. Authentication tokens are often key fobs or smart cards. In many cases, the user has a PIN (Personal Identification Number) to activate the authentication token. This minimizes the possibility of security breaches if the authentication token is stolen.

Another mechanism for multi-factor authentication is to log in to the website and get a temporary password with the user's phone or email address, answer security questions, and download a valid digital certificate with a VPN client to authorize access. Login to the VPN before being done, such as fingerprint scanning, retinal scanning, face verification, voice verification, and other biometric scanning with biometric information. See, for example, U.S. Pat. Nos. 9,838,388 and U.S. Patent Application Publication No. 2016/0373440 (both by Mother) for biometric authentication protocol standards for authentication and secure communications.

Unfortunately, the stored biometric information can be stolen. For an individual, the theft of biometric information will be as serious as the theft of a Social Security number.

Conventionally, a protective measure of storing electronic data in a secure server has been adopted. However, even this well-protected server can be vulnerable to cyberattacks.

Currently, systems and methods for protecting personal information are flawed. There is a need for more sophisticated methods in the art to protect information related to documents and the like. For example, there is a need for more advanced methods related to biometric security in the art.

In recent years, a technology called "blockchain" has been developed mainly as a security measure for cryptocurrencies. Storage by blockchain is a type of distributed ledger, and refers to a distributed data store in which a user stores information in a large number of nodes, or a computer network in which a user stores information in a large number of peer network nodes. Peer network means that each user or participant in the datastore network is connected to the distributed datastore via their own computer. Each user and his computer are referred to as "nodes". Each node stores the same information and contributes to authentication and / or matching of distributed data stores. The theory is that blockchain / blockchain has a huge number of users, and in order to destroy the system, cyber attackers must change the data stored in all or most of the nodes in a short time. Above, it is impossible to falsify the information. The reason most nodes have to be modified is that in the case of cryptocurrencies, each node holds the same data and stores the data that the nodes agree to be appropriate. In the case of cryptocurrencies, blockchain data provides a ledger of all digital transactions for a particular cryptocurrency.

The blockchain / distributed ledger guarantees security against data tampering and / or destruction due to its distributed nature (all nodes store the same data). However, since the blockchain / distributed ledger stores all transactions and copies those transactions to all nodes (ledger), the blockchain / distributed ledger so that the amount of data stored in the blockchain is limited. It is very important that the operation is efficient. The storage limit for blockchain / blockchain is significantly different from the storage limit for secure servers.

This means, for example, that all nodes of a particular type of cryptocurrency store all transactions for that cryptocurrency.

The blockchain / blockchain further protects the file on the node and at the time of transmission by the encryption technology for encrypting the file in addition to the blockchain / blockchain technology. Also, the stored data is usually read-only.

More specifically, all users in the blockchain / blockchain are connected via a peer-to-peer network. The network is more secure, 10x faster, and half the cost of traditional data center cloud storage solutions. Therefore, the blockchain / blockchain makes it possible for users to store data safely and in a decentralized manner. This is realized by the characteristics of the blockchain / distributed ledger such as transaction ledger, encryption hash function, and public / private key encryption.

Since the blockchain / blockchain is decentralized, there is no central server to be compromised. Also, with client-side encryption, only the end user has full access to their unencrypted files and encryption keys.

In distributed data storage based on some embodiments of blockchain technology, only the hash of that data block is stored. The legitimacy and reliability of the data block can be sufficiently confirmed by the encrypted distributed hash. In a blockchain, data is encrypted, distributed and stored, and each block containing its own encryption hash forms a continuous chain. By linking the blocks in this way, a distributed transaction ledger is realized.

The biggest impact of blockchain / blockchain, as many data experts think, will be disintermediation. A well-designed blockchain / blockchain that can be accessed by anyone and has access restrictions can provide a reliable trading environment, fraud and processing error prevention, and reliable contracts currently provided by intermediary financial institutions. Many of the functions related to compliance and financial transactions can be replaced.

The strength of blockchain / blockchain is not limited to the strength of encryption. Due to the distribution on the computer chain, the blockchain / blockchain is less likely to be attacked. The blockchain / blockchain adopts a self-verification storage method that can be used for tamper-proof recording of transactions, ownership or ID, contract negotiation, performance, etc.

However, there are problems with the use of blockchain / blockchain. Since the blockchain / blockchain stores a copy of the ledger or transaction on all nodes and cannot delete the stored transaction, the amount of storage required immediately can be enormous. Further, in order to realize various access controls such as RBAC (role-based access control), it is preferable to use a centralized system. However, in that case, if the central system is hacked, it will allow unauthorized access to the blockchain. When storing confidential information in the blockchain / blockchain, the blockchain / blockchain data cannot be easily deleted, so it must be more sensitive to security.

As a technology other than the above security processing, there is a secure storage system that stores files in a distributed manner and reconstructs them in response to a request. For example, U.S. Patent Application Publication No. 2016/0196218 (by Kumar), U.S. Patent Application Publication No. 2017/0272100 (by Yanovsky), and U.S. Patent No. 8,694,467 (by Sun).

It is also proposed to use the blockchain in a limited way and not to store files. Examples include "Distributed Privacy: Personal Data Protection by Blockchain" (by Zyskind) and WO2017 / 145010 (by Bright).

However, due to restrictions on blockchain / blockchain and central server storage, neither of these systems has achieved the expected security and functionality.

Therefore, there is a need for more sophisticated methods for securely storing electronic data.

Some forms of the present technology are intended to improve computer functions by solving security problems using software. It is desirable for security that the information associated with an individual (user) and / or an entity can be safely stored. You may act on behalf of an entity, such as a private company, government agency, or other entity.

In one or more embodiments, systems and methods for securely storing electronic data, such as digital files, are provided. In the system and method, digital files are decomposed into file fragments, one or more fragments are stored in one or more blockchain / distributed ledgers, and the remaining (one or more) fragments are blockchain / distributed. It is stored outside the ledger, for example, in one or more secure servers and / or in one or more user devices. The stored file is a biometric file or a partial biometric file and / or any data file. The file may be encrypted or hashed. File fragments are preferably encrypted and make no sense unless they are completely reconstructed. In some or any embodiment, one or more fragments of the file may be stored offline, eg, on a USB or thumb drive, which usually does not have its own CPU, or other digital storage device. In these and / or any other embodiment, the one or more file fragments may include all or part of the file header.

For example, theft, copying, or hacking of one file fragment is not an effective means of stealing, copying, or stealing useful information that makes sense.

In some embodiments, the advantage of storing on a blockchain / blockchain (s) is on one or more secure servers (and / or one or more user devices). You may combine the advantages.

In one or more embodiments, the non-meaningful partial biometric file can be applied with sufficient information to prevent nonrepudiation, regardless of the storage location.

In any embodiment, distributed data storage may be provided that has some or all of the features of one or more blockchain / distributed ledgers. Such features include immutable storage, encryption, peer-to-peer, decentralized, and / or agreement. In any embodiment, a partially distributed ledger (eg, a consortium blockchain), another type of blockchain or a distributed ledger may be provided.

Regarding the above-mentioned and other characteristics and features of the present technology, the operation method and function of the combination of related components and parts, and the economic efficiency of manufacturing, the following detailed explanation and the attached utility model are described with reference to the attached drawings. It will be further clarified by examining the scope of claims for new proposal registration. All of these form part of this specification. In the present specification, similar reference numerals indicate corresponding parts in various drawings. However, it should be clearly understood that the drawings are for illustration and illustration purposes only and are not intended to be used as a definition of the limitations of the present invention. In the present specification and claims, the singular notation includes references to more than one unless otherwise specified.

FIG. 1 shows a system that provides general-purpose distributed storage combined with secure server storage for user's electronic data according to one or more forms. FIG. 2 shows an example of a process for safely storing electronic data. FIG. 2A is a schematic flowchart showing an example of storage processing of a biological feature image or an arbitrary image file. FIG. 3 shows an example of a process of dividing and storing electronic data such as a biological feature file and / or any other type of file. FIG. 3A shows a schematic flowchart showing an example of a process of storing any kind of file. This process may be part of the process of FIGS. 2A and 4A. FIG. 4 shows an example of a process of dividing and storing electronic data such as a biological feature file. FIG. 4A is a schematic flowchart showing an example of another process for storing a biological feature image or an arbitrary image file. FIG. 5 shows one method of reading and reconstructing a file such as a biological feature file that is safely stored. FIG. 6 shows one method of reading and reconstructing a safely stored file such as a split biological feature file (SPBF). FIG. 7 shows an example of a general process of reconstructing an arbitrary file. FIG. 8 shows an example of file deletion processing. FIG. 9 shows an example of biometric authentication processing using an encrypted SPBF file. FIG. 10 shows an example of biometric authentication processing using a hashed SPBF file. FIG. 11 shows an example of biometric authentication processing using the SPBF file and the biometric feature vector. FIG. 12 shows an example of biometric authentication processing using a hashed biometric feature vector file. FIG. 13 shows an example of a process for registering a user. FIG. 14 shows an example of processing a user's request to securely store electronic data. FIG. 15 shows an example of user request processing for reading out securely stored electronic data. FIG. 16 outlines an example of an applied blockchain or distributed ledger.

FIG. 1 shows a system 100 that realizes a general-purpose distributed solution for safely storing user's electronic data related to one or more forms. In some embodiments, the system 100 may include one or more servers 102. The server 102 (one or more) may be configured to communicate with one or more computing platforms 104 involved in a client-server structure, a peer-to-peer structure, and / or other structures (eg, the Internet), such as the cloud 101. Good. The user may access the system 100 via the (one or more) computing platforms 104. The access may be accompanied by an API. The server 102 (one or more) may be configured to execute the machine-readable instruction 106. The machine-readable instruction 106 may include one or more of the registration element 108, the transaction address element 110, the user interface element 114, the access control element 116, and the information management element 118. In any one or more embodiments, the identity verification element 120 may be included. Other machine-readable instructional elements may be present, as will be apparent to those skilled in the art. Each element may be split and / or integrated. Machine-readable instructions 106 may be executed to build transaction addresses for the blockchain or distributed ledger network. Generally, a blockchain or a distributed ledger is a transaction database shared by some or all of the nodes participating in the system 100. For example, there can be at least 100, 1,000, 10,000, 100,000, 1,000,000, or more nodes. Participation includes Bitcoin Protocol, Ethereum Protocol, Ripple Agreement Network (RTXP (Ripple Transaction Protocol)), Hyperleisure by Linux®, R3 Corda, Symbionto Distributed Ledger (Assembly), and / or Digital. It may be based on currencies, decentralized ledgers and / or other protocols related to blockchain. A complete copy of the blockchain or decentralized ledger includes all transactions relating to related digital currencies or all other transactions such as smart contracts to date. In addition to transactions, the blockchain may include other information, such as those described further herein.

As used herein, the term "blockchain" is also referred to as "distributed ledger" in another one or more embodiments. All types of transactions can be stored in decentralized storage, decentralized ledgers, blockchains, or decentralized networks or network datastores that include other suitable decentralized or networked transaction mechanisms. Distributed storage (or "distributed datastore") may include files or file segments stored on nodes on the network, or data streams stored on the network datastore. Distributed storage is not limited to any particular format or protocol, but any type stored on any accessible network node, including servers, desktop PCs, mobile devices, removable storage, or other suitable devices. File may be included. In one embodiment, the entire file may be stored on a single node and another file may be stored on another network node. Alternatively, a single file may be divided into a plurality of segments and stored in one or more network nodes. In one embodiment, the entire file may be stored in a single network datastore and another file may be stored in another network datastore. Alternatively, a single file may be divided into a plurality of segments and stored in one or more network data stores. Some transaction networks are configured as decentralized payment systems, partially decentralized payment systems, or central payment systems.

In one embodiment, the distributed ledger may be a database or database replica that is shared and synchronized across one or more distributed networks. Alternatively, the distributed ledger may be a data stream in a network data store. The distributed ledger allows transactions to be published or duplicated in whole or in part, making them less susceptible to cyber attacks. In addition, the distributed ledger maintains consensus on the existence and status of shared facts, even in low-credit environments (ie, where the participants hosting the shared database have independent roles and do not trust each other). It is possible. The agreement is what is needed to store the data. An agreement is not unique to a distributed ledger. Other distributed databases also utilize consensus algorithms such as Paxos or Raft. The same applies to the fact that it cannot be tampered with. Some databases (Google HDFS, Zebra, CouchDB, Datamic, etc.) used other than the distributed ledger can be tampered with.

The distributed ledger differs from a normal distributed database in the following points. (A) Read / write access control is fully or partially decentralized. For other distributed databases, it is logically concentrated. Therefore, (b) transactions can be protected even in a difficult environment in the absence of a reliable third party. The distributed ledger can have a linear structure like a blockchain. Alternatively, DAG (Directed Acyclic Graph) can be included, such as IOTA's Tangle. Blockchain, IOTA's Tangle, and Hedera's hash graph are specific examples of distributed ledgers with predetermined formats and access protocols.

A blockchain is a distributed ledger that stores transactions in chronological order. In the case of blockchain ledger, all transactions are periodically verified and stored in "blocks". The block is linked to the previous block via a cryptographic hash. Since the blockchain ledger is open to the public, transactions can be viewed and tracked by anyone. Each network node can receive and hold a copy of the blockchain.

In addition to the above, the storage described herein may be a network data store, referred to as data stored in the network. The data is stored in the network, not in the nodes of the network.

In some embodiments, the storage may be a typical digital memory or may be a quantum data storage or a quantum storage network (eg, based on the cloud). In the case of quantum storage, information is stored as energy in one or more particles and is transferred by collision of particles such as protons. Since the energy of a particle is transferred as information, when it collides with a new particle, the information disappears from the particle that had the information until then.

The registration element 108 may be configured to register (and assist in identifying) an individual user (individual or entity).

As described in detail in U.S. Patent Application No. 15 / 335,344 (incorporated herein by reference) filed October 26, 2016, the system may be part of a registration element or itself. As an element of, information related to one or more authentication documents may be received from the entity in the blockchain trust utility. The one or more authentication documents may be associated with the user (for example, an individual), or may be an identification card, that is, a document certifying the identity of the user. An entity may include one or more of institutions, companies, companies, government agencies, and / or other entities.

The blockchain may be based on several blocks. The block may include one or more waiting transactions and may include a record to confirm. On a regular basis (depending on the type of transaction and the amount of users in the chain), new blocks containing transactions and / or other information may be added to the blockchain. In some forms, a given block in the blockchain contains a hash of the previous block. This has the effect of forming a chain of blocks from the origin block (ie, the first block in the blockchain) to the current block. Since a given block contains a hash of the previous block, it can be guaranteed to come after the previous block in time. After being included in the blockchain, a given block can be computationally tamper-proof due to the characteristics of the hash function. Further, in the blockchain, copies of all transactions are stored in all or at least a plurality of nodes (for example, all computers belonging to a specific blockchain area). Therefore, inconsistencies are obvious in the network unless the corresponding blocks on all (or at least most) nodes in the blockchain network are also tampered with. The contents of the block can be seen by other participants in the network of nodes that support the blockchain.

As will be described in more detail below, the transaction address element 110 may assign one or more transaction addresses to one or more individual users of the system. The transaction address is necessary for the blockchain to access the information within a particular block associated with the transaction address, in addition to the associated public and private key or other authentication and access control. May be good.

User interface element 114 may provide a user interface.

For example, the system 100 may be configured to register a user via a registration element 108. The registration process may be a typical registration process as shown in FIG. For example, in step 1302, the system may receive a user request for registration via the system API in the user interface element 114. At step 1304, the system may receive the user's ID data. Examples of ID data include names, addresses, and e-mail addresses. In a preferred embodiment described elsewhere herein, the ID data may further include a written basis that can sufficiently prove the identity of the user. At step 1306, the system may assign a user-specific identifier (one or more), such as one or more unique credentials. For example, the credential may be one or more of a username, password or username and password pair, numbers, alphanumeric characters, and / or other credentials (one or more) and / or other information associated with an individual. .. At step 1308, the system may optionally receive biometric information from the user. As a result, user authentication with a relatively high security level can be realized.

According to some forms, an individual with a certified personal identity can be considered to have a certified personal identity in various ways. For example, in some forms, an individual may be required to provide proof of his identity. The proof (the above information) can be a copy of a government-issued ID (eg passport and / or driver's license), a copy of mail received by an individual (eg utility charges), or proof by a third party. , And / or other proof of personal identity. The proof may be for an entity associated with (one or more) servers 102.

In some forms, information about one or more authentication documents associated with a user may be encrypted with a first key and a second key. The first key may be a server key (eg, a public key) stored in the backend server. The second key may be a client key, which is a hash of life authentication data associated with the first user. In some forms, the first and second keys may be applied to the blockchain's immutable ID for sensitive data formats and / or hyper-encryption of related documents. Identity verification is optional and may be done as part of the registration process.

The system 100 may be configured to use the transaction address element 110 to assign a transaction address on the blockchain to a registered individual. A given transaction address may be associated with a public and private key (this is common in blockchain-based cryptocurrencies). As an example, the first transaction address may be associated with an individual. The first transaction address may include a first public key and a first private key.

In general, a public / private key pair may be used for encryption / decryption according to one or more public key algorithms. As a non-limiting example, a key set may be used for digital signatures. The key set may include a private key for signature and a public key for digital signature authentication. The private key is private (eg, known only to the owner) and the public key may be publicly available. The keys may be mathematically associated with each other, but it is not possible to calculate the private key from the public key.

In some forms, the system 100 may be configured such that the private key is stored within (one or more) computing platforms 104. For example, the first private key may be stored on the computing platform 104 and / or other location associated with the individual. According to some embodiments, the private key may be stored in one or more of the "verify.dat" files, SIM cards, and / or other locations.

In some forms, the system 100 may be configured such that multiple transaction addresses are assigned to different individuals. For example, in addition to the first transaction address, a second transaction address may be assigned to the first individual. In one or more forms, one or more additional transaction addresses may be assigned to the first individual. The second individual registered in the system may receive the third transaction address, and so on.

The system 100 may be configured to record an identifier and biometric data associated with an individual at the corresponding transaction address. For example, the first identifier and the first biometric data associated with the first individual may be recorded at the first transaction address. Recording information at a given transaction address may include recording a hash or other representation of encrypted information. In some forms, different biometric data may be recorded at multiple transaction addresses assigned to a given individual. For example, in addition to recording the first identifier associated with the first individual (first user) and the first biometric data at the first transaction address, the first associated with the first individual. The identifier of 1 and the second biometric data may be recorded in the second transaction address.

In general, biometric data may include indicators of human characteristics. A bioidentifier is a unique and measurable feature that can identify and represent an individual. The bioidentifier typically comprises physical characteristics, but may further include behavioral and / or other characteristics. Physical characteristics may relate to an individual's body shape. Examples of physical features used as biometric data include fingerprints, palm veins, face recognition, genomic information, (1 or more) DNA sequences and (1 or more) DNA modifications, proteomics information, (1 or more). One or more of protein sequences and (one or more) protein modifications, palm prints, hand shapes, iris recognition, retina, odor or scent, and / or other physical features. Behavioral features may relate to individual behavioral patterns. Examples of behavioral features used as biometric data include one or more of typing rhythms, gait, voice, heart rate, and / or other behavioral features.

Biological feature data includes one or more of images or other visual representations of physical features, records of behavioral features, templates of physical and / or behavioral features, and / or other biometric data. It may be included. The template may include a combination of related properties extracted from the subject. A template is one or more of vectors representing physical and / or behavioral characteristics, mathematical representations of physical and / or behavioral characteristics, images with specific characteristics, and / or other information. May include.

Biometric data may be received via the computing platform 104 associated with the individual. For example, biometric data associated with a first individual may be received via a first computing platform 104 associated with a first individual. The first computing platform 104 may have an input device (not shown) configured to acquire and / or record the physical and / or behavioral characteristics of the first individual. Examples of such input devices include one or more of cameras and / or other imaging devices, fingerprint scanners, microphones, accelerometers, and / or other input devices.

System 100 may be configured to provide an interface presented to an individual via the associated computing platform 104. The interface may include a graphical user interface via the user interface element 114, which is presented via the personal computing platform 104. In some forms, the interface can add or remove storage addresses that a given individual is assigned to that given individual, as long as at least one storage address is assigned to that given individual. It may be configured to.

In some embodiments, the system 100 may be configured to access and / or manage one or more user profiles and / or user information associated with a user of the system 100. The one or more user profiles and / or user information may include information stored in (one or more) servers 102, (one or more) computing platforms 104, and / or other storage locations. Examples of user profiles include user-identifying information (eg, username, handle name, number, identifier, and / or other identifying information), security login information (eg, login code or password), system account information, etc. Browsing information, digital currency account information (eg, regarding the currency that the user holds in credit), relationship information (eg, information about relationships between users of System 100), system usage information, demographic information about users, system History of interactions between 100 users, information requested by users, purchase information of users, browsing history of users, computing platform identification associated with users, phone numbers associated with users, and / or associated with users. Other information can be mentioned.

The machine-readable instruction 106 may be executed by one or more individual identifiers and (one or more) transaction addresses so that electronic data is stored based on the blockchain or one or more secure servers.

FIG. 14 shows the processing of a user's request to securely store electronic data. The electronic data usually takes a file format or other unique format. In step 1402, the system may receive the user's sign-in request via the API. In step 1404, the system may authenticate the user with the stored biometric information of the user and other (one or more) identifiers recorded in the registration process. At step 1406, the system may receive the user's storage request. At step 1408, the system may receive stored user electronic data. At step 1410, the system may divide the electronic data into file fragments. Each fragment is preferably part of a file and preferably does not make sense as a single or as a set unless all fragments are constructed as a fully meaningful file (by machine or man). In one or more embodiments, for example, one fragment may be a file header and another one or more fragments may be file data or image data. The file header may also be divided into one or more fragments. In step 1412, the system delivers one or more file fragments in one or more locations in one or more distributed ledgers, or in one or more locations in a distributed database (preferably as a transaction). It may be stored (preferably as a transaction) in one or more blocks of the blockchain. Other one or more file fragments may be stored outside the blockchain, blockchain, or distributed database, eg, one or more secure servers and / or one or more user devices. One or more fragments may be stored online or offline. It may be stored in one or more other digital storage devices, such as a USB, SIM card, thumb drive or other suitable device that can be removed from the online environment and usually does not have its own CPU. ..

FIG. 2 shows an example of a system 100 that performs the following steps to securely store electronic data such as biometric and / or other very personal information and / or sensitive information. The system may implement this secure storage element in a secure storage system during user registration, for example making the user's biometric electronic data part of the authentication requirements. Further / or, the storage is realized when the user subsequently makes a registration request for safe storage of electronic information and wants to use the system to safely store electronic data such as the user's biometric electronic data. May be done.

In step 202, the system divides the biometric electronic information into a plurality of feature blocks during or after registering the user, assigning the user's ID, and authenticating (preferably two-factor authentication or better) and indexing each feature block. It may be numbered. The index number may be randomized by a random number generator or other suitable random number generator as an optional aspect of the indexing process.

In any step 204, the system may optionally transform one or more feature blocks by rotation, flipping, masking, and / or other methods. The conversion method is preferably random, but may be pseudo-random or may be performed in a predetermined format. If the biometric information is voice and the feature block is a voice block, each block may optionally be manipulated by inversion, masking, pitch conversion, and / or other methods. The system records the conversion data (eg, flipping / rotation information). It should be noted that the conversion is not always necessary and is not required to be performed at this stage, and may be performed at an earlier or later stage of processing in any embodiment of the present specification.

In step 206, the system may map the index number, transformation data, and geometric position of each data block.

At step 208, the system creates a mapping file of index numbers, transformation data, and geometric positions collected in the previous step.

At any step 210, the system encrypts the mapping file.

In step 211, the system also divides (optionally) the mapping file and stores it. One embodiment in which the system divides and stores the mapping file is shown in process 300 of FIG.

In step 212, the system selects and groups some of the feature blocks (eg, 30% of the feature blocks). This is preferably done randomly, but it may be pseudo-random or it may be done in a predetermined procedure. This step may be performed multiple times in steps 214,216, 300. As a result, a large number of divided biometric files are generated. In the process of selecting and grouping a part of the feature blocks, a given feature block may be selected a plurality of times.

In step 214, the system may form scrambled partial biometric features (SPBF) by reconstructing feature blocks from a group of feature blocks and generating a new file. According to one or more methods described below, this step may be performed multiple times to generate multiple SPBFs.

At any step 216, the system may encrypt the SPBF file. Encryption of SPBF files may be achieved by AES algorithm, PGP algorithm, Blowfish algorithm, or other suitable encryption algorithm.

In step 218, the system may proceed to process 300 again to divide and store the SPBF file.

It will be understood that there are many ways to divide and store biometric files. For example, as one method, the original biometric file or SPBF file (whether encrypted or not) is divided into a plurality of fragments, and a file of each fragment is generated to generate one or a plurality of storage devices. It may be stored in. This method may be applied to the storage of index files, mapping files, geometric position files, and / or other files needed to reconstruct the original electronic data.

All split files (ie, all "fragment files" obtained by splitting or decomposing a file) should be stored in order to reconstruct the original file. There should be one or more additional files to store information about how the files were split, i.e. an index file containing the order of the file fragments (index ordering) for reconstruction. .. The index file is needed later to rebuild the original file. This method can also be applied to the hash file of the original biometric file. In that case, it is not necessary to generate the SPBF file. Rather, it is preferable that it is not generated. In one embodiment, the index file itself may be arbitrarily divided like the original file, a part is stored in a blockchain, a distributed ledger, or a distributed database, and a part is a blockchain, a distributed ledger. , Or is preferably stored outside the distributed database. As a result, an index file for the (first) index file is generated. This "second" index file should be stored most securely and preferably offline and encrypted by a different encryption method than the first index file.

As another biometric feature file decomposition and storage method, different multiple feature blocks are selected, a plurality of different SPBF files (whether encrypted or not) are generated, and one or more of the different SPBF files are generated. It can be stored in the storage device of. The feature block of the SPBF file may cover all or part of the original biofeature data file (eg, when used for authentication). In the case of this method, any combination of one or more SPBF files can be used for a single biometric feature to achieve one or more types of biometrics.

For a single biological feature, multiple SPBF files (if multiple) and corresponding fragment files are separately located at different locations on one blockchain, with one or more transaction addresses, and / Or can be stored under one or more smart contract addresses and / or one or more blockchain utility addresses. For a single biological feature, multiple SPBF files (if multiple) and fragment files are separate, one or more independent blockchains and / or one or more of each blockchain. Transaction records, one or more independent distributed ledgers, and / or one or more transaction records of one or each distributed ledger, one or more independent distributed databases and / or one of each distributed database. Alternatively, it may be stored in a plurality of records. For a single biological feature, one or more SPBF or fragment files may be encrypted prior to storage. For one or more encrypted SPBF files and / or fragment files obtained from a single biometric feature, in particular the file is a blockchain, decentralized ledger, or decentralized database (whether public or secret). When stored in, only the owner of the biometric feature has the passphrase / key to decrypt the file. This makes it easier to guarantee that the encrypted file cannot be used for biometric authentication by anyone other than the owner of the biometric feature. The SPBF file may be hashed before being stored.

All the above-mentioned biological feature file decomposition and storage methods can be performed individually or in combination.

FIG. 2A shows a schematic flowchart of an example of a process for storing a biological feature image. At step 220, the system may receive an image of biological features (as the start of processing in FIG. 2). In step 222 (similar to step 202), the system may divide the image into blocks (feature blocks). At step 224 (similar to steps 204, 208, 212, 214), the system may select some feature blocks to be combined or grouped (eg, randomly selected for greater security. , Pseudo-random or non-random). In the process, the system transforms the feature blocks by, for example, rotating them at 90 ° or random angles. At step 230, the system generates a mapping file (similar to steps 206, 208, 210). The one or more mapping files may then be (optionally) split in steps 232 and 234, and the file fragments are partially stored in the blockchain, blockchain, or distributed database (at 234A). Stored in storage outside the blockchain, blockchain, or decentralized data (referred to as storage option). The storage includes one or more cloud servers, one or more secure servers (eg, entity or personally owned), and / or one or more client devices. For example, the client device is a user's mobile phone, tablet, notebook PC, desktop PC, or other user device (referred to as a storage option in steps 211 and 218 of FIG. 2 and processes 300 and 234B of FIG. 3). Storage option 234B may include a network data store.

One or more fragments may be stored in one or more other digital storage devices, such as SIM cards, USB thumb drives, etc., which usually do not have their own CPU, or other suitable devices. In step 226 (similar to step 216) or step 228 (not in process 200, but optionally performed in place of step 216), the system optionally optionally encrypts or hashes, respectively. It may be applied to a biometric file, an SPBF file, or a portion of the file generated in step 224. In one embodiment, hashing to a portion of the biometric / SPBF file is an MD5 algorithm, SHA algorithm (eg SHA-0), SHA-2 algorithm (eg SHA-256), or any other suitable hashing algorithm. Can be achieved by applying. In another embodiment, hashing of a portion of the biometric / SPBF file can be achieved by applying an AES algorithm, a PGP algorithm, a Blowfish algorithm, or any other suitable encryption algorithm. In the case of an index file, the mapping file itself can be arbitrarily divided like the original file, and it can be partially (or all) stored in the blockchain and partially stored outside the blockchain, or partially (or all). ) May be stored in the distributed ledger and partially stored outside the distributed ledger, or partially (or all) may be stored in the distributed database and partially stored outside the distributed database. .. The index file is then mapped to the (first) mapping file. This "second" mapping or index file should be stored most securely and, if possible, encrypted offline, preferably with a different encryption method than the first mapping file. Preferably, in any embodiment described herein, the mapping file or at least a portion thereof is stored on a blockchain or distributed ledger.

FIG. 3 shows an exemplary routine 300 for partitioning and storing electronic data such as biometric files and / or any other type of file, which, like the other figures, can perform the following steps.

In step 302, the system may divide the electronic data into fragments (two or more). Each fragment is a file (“file fragment”) that is one or more blocks of stored electronic data, one or more slices, or other one or more fragments. The system may also indicate the order of the fragment files (index ordering). For biometric files, the system may divide the file into fragments such as feature blocks and index order them. Fragment files generated from electronic data may include parts of data and / or images and / or audio and / or moving images of electronic files or other electronic data. In some embodiments, the fragment file may include a file header or a portion thereof. As part of this step, the system further stores the above file fragments in one or more blockchains and stores them outside the one or more blockchains, or stores them in one or more distributed ledgers and distributes them one or more. It may be stored outside the type ledger, or stored outside the one or more distributed databases and stored outside the one or more distributed databases (see step 310 below).

In step 304, the system may generate an index file for rebuilding the original file.

At step 306, the system may optionally encrypt the index file.

At step 308, the system may store the index file (to rebuild the file later). The system may store the index file in blockchain or storage outside the blockchain, preferably using a hash table of location data distributed across all nodes on the blockchain. At this time, for example, the index file is stored outside the blockchain. In another embodiment described in this section, the index file itself is divided, preferably partially stored in the blockchain and partially stored outside the blockchain, or partially stored in the distributed ledger and partially. It may be stored outside the distributed ledger, or it may be partially stored in the distributed database and partially stored outside the distributed database.

In step 310, the system stores any selected piece of electronic data or a group of fragments (preferably randomly selected, but may be pseudo-random or selected in a predetermined manner). You may. The electronic data is securely stored in a blockchain, a blockchain, or a storage outside the distributed data. The storage includes one or more secure servers (eg, entity or personally owned) and / or one or more client devices. For example, the client device may be a user's mobile phone, tablet, notebook PC, desktop PC, or other user device. One or more fragments may be stored in one or more other digital storage devices, such as SIM cards, USB thumb drives, etc., which usually do not have their own CPU, or other suitable devices. As with all embodiments described herein, the timing at which one step is performed in connection with another can be changed as long as there is no discrepancy.

The system can store at least one fragment of electronic data in a blockchain, blockchain, or distributed database. This one or more fragments are needed to reconstruct the file (electronic data) into a file that makes sense to the machine or human (ie, there is at least some understandable part). For example, as in any embodiment described herein, this at least one fragment is a header portion or part of a header of a securely stored file, which may or may not include other parts of the file. .. The size of the at least one fragment is preferably as small as possible (in bytes), preferably on the assumption that the electronic data cannot be formed without the fragment. As a result, the storage and extraction load in the blockchain system can be minimized. The system may optionally store multiple fragments in separate storage on the blockchain, blockchain, or distributed database. Such a storage step is schematically shown in FIG. 3A described later.

In all embodiments described herein, when storing one or more fragments in a blockchain, the system may store the fragments in multiple blocks (eg, transactions) on the blockchain. .. When the system stores one or more fragments in the distributed ledger, the fragment may be stored in multiple positions (eg, transactions) on the distributed ledger. Alternatively, when storing one or more fragments in the distributed database, the system may store the fragments in multiple locations in the distributed database. The system, blockchain, blockchain and / or distributed database further decomposes one or more stored fragments and uses the resulting fragments as data streams in a network datastore for multiple blockchain nodes, distributed. It may be configured to be distributed to the type ledger node and the distributed data storage node. Preferably, authentication is required to access the blockchain node, distributed ledger node, distributed data storage node or network datastore for reconstruction using file fragments, and the private key and transaction address. Or you need a smart contract address. For security reasons, the transaction address or smart contract address may be updated periodically over time and / or with each use.

FIG. 3A is a schematic flow chart illustrating exemplary processing for storing any file type. This may be part of the process of FIGS. 2A and 4A and is captured as a detail of step 310 of FIG.

In step 312, the system can receive the files to be split and stored. At step 314, the system may split the file into fragments. In step 316, the system stores at least one of the fragments in the blockchain, blockchain, or distributed database and stores the remaining fragments in the blockchain, blockchain, and storage outside the distributed data (in box 316A). It may be stored in (collect). The storage includes one or more cloud servers, one or more secure servers (eg, entity or personally owned), and / or one or more client devices. For example, the client device may be a user's mobile phone, tablet, notebook PC, desktop PC, or other user device (collected in box 316B). One or more fragments may be stored in one or more other digital storage devices, such as SIM cards, USB thumb drives, etc., which usually do not have their own CPU, or other suitable devices.

FIG. 4 shows an example of a routine 400 for dividing and storing electronic data such as a biometric file, which can be used instead of the routine 300 in other figures.

In step 402, similar to step 202 above, the system may divide the biometric features into feature blocks and index each feature block in the biometric feature file. This index number may optionally be randomized as part of the indexing process. However, as in any embodiment of the present specification, it may be selected pseudo-randomly or may be selected by a predetermined method.

At any step 404, the system may transform feature blocks, similar to step 202 above. The system records the conversion data (eg, flip / rotation information).

In step 406, as in step 206 above, the system maps the index number, transformation data, and geometric position of each feature block.

In step 408, the system generates a mapping file (or mapping data file) of index numbers, conversion data, and geometric positions collected in the previous step 406.

At any step 410, the system encrypts the mapping data. Encryption of the mapping file may be achieved by an AES algorithm, a PGP algorithm, a Blowfish algorithm, or any other suitable encryption algorithm.

In step 411, as described above, the system divides (arbitrarily) and stores the mapping file by the process 300 shown in detail in FIG. In the other embodiments described in this section, the first mapping and / or the index file itself may be divided by the same processing as the division and storage of the original file. For greater security, some are stored online (eg, on or off the blockchain) and / or partially offline.

In step 412, the system randomly selects a portion of the feature block (eg, 30% of the feature block) and reconstructs it in a random order (or pseudo-random or predetermined order) in two or multiple dimensions. To do.

This step may be performed multiple times by steps 414, 416, 418, 300, 420, 422, 424, 300. This results in a large number of SPBFs, selected blocks and geometric data files.

Specifically, in step 414, the system may record the reconstruction order data of the feature blocks as a reconstruction order data file.

At step 416, the system may encrypt the rebuild sequence data file. Encryption of the rebuilding sequence data file may be achieved by an AES algorithm, a PGP algorithm, a Blowfish algorithm, or any other suitable encryption algorithm.

In step 418, the system may divide and store the selected block data and the geometric data file by processing 300 or the like.

In step 420, the system may generate scrambled partial biofeatures (SPBF) by reconstructing feature blocks and generating new files.

In any step 422, the system may extract the SPBF biometric vector.

In any step 424, the system may encrypt / hash the SPBF file or SPBF biometric vector file.

In step 426, as in the process 300 described above, the system may divide and store the SPBF (SPBF vector) file according to the process steps described in the process 300.

FIG. 4A shows a schematic flow chart of another exemplary process for storing biometric images. At step 428, the system receives an image of biological features (as the start of processing in FIG. 4). In step 430 (similar to step 402 in FIG. 4), the system may divide the image into blocks (feature blocks). In step 432 (similar to steps 404, 406, 421, 420, 422), the system may select some feature blocks to be collected (eg, random selection provides high security, but pseudo Random or non-random choice). In the process, the system transforms the feature blocks (eg by rotating them at 90 ° or random angles). At step 438, the system generates selected biometric blocks and reconstruction order data files (similar to steps 414 and 416 of FIG. 4). The one or more selected biometric blocks and reconstruction order data files may then be split in steps 442 and 444, with the file fragments partially stored in the blockchain, distributed ledger, or distributed database. , Partially stored in blockchain, distributed ledger, or storage outside of distributed data. The storage includes one or more cloud servers, one or more secure servers, and / or one or more client devices. For example, the client device may be a user's mobile phone, tablet, notebook PC, desktop PC, or other user device. Box 444A represents a blockchain, blockchain, or decentralized database storage option. Box 444B represents a storage option outside the blockchain, blockchain, and / or distributed database. One or more fragments may be stored in one or more other digital storage devices, such as SIM cards, USB thumb drives, etc., which usually do not have their own CPU, or other suitable devices. In (arbitrary) step 433, the system can extract a biofeature vector from the partial biofeature file. Then, in step 434 (similar to step 424 in FIG. 4) or in step 436 (similar to step 424 in FIG. 4), the system selectively optionally encrypts or hashes the SPBF file and SPBF biometric vector file, respectively. , Or it may be applied to the file generated in step 432. At step 440, the system may generate a biometric mapping file (optionally encrypted) (similar to steps 408 and 410 in FIG. 4). At step 442, the system may divide the mapping file into fragments (similar to steps 411, 418, 426 of FIG. 4 and process 300 of FIG. 3). In step 444, the system may partially store the file fragment in the blockchain, blockchain, or decentralized database and partially in the blockchain, decentralized ledger, or storage outside the decentralized data. Good. The storage includes one or more cloud servers, one or more secure servers, and / or one or more client devices (similar to steps 411, 418, 426 of FIG. 4, process 300 of FIG. 3). One or more fragments may be stored in one or more other digital storage devices, such as SIM cards, USB thumb drives, etc., which usually do not have their own CPU, or other suitable devices.

Once the biometric file is securely stored, either the user wants access to the biometric feature or the system needs to access the biometric feature or SPBF file and authenticate the user by comparing it to the user's biometric feature or SPBF. There can be.

FIG. 15 shows the processing of a request for a user to acquire securely stored electronic data. In step 1502, the system may receive the user's sign-in request via the API. At step 1504, the system may authenticate the user using, for example, biometric information stored by the user and other (one or more) identifiers recorded during the registration process. At step 1506, the system may receive a user acquisition request. At step 1508, the system may retrieve fragments of the user's electronic data from storage. At step 1510, the system may reconstruct the file fragment into one or more files. In step 1512, the system may return the file (one or more) to the user, eg, by display or read-only, downloadable, and / or by other means.

FIG. 5 shows one of the methods of acquiring and reconstructing a safely stored file such as a biological feature file. In step 502, the system may obtain a mapping file and a position index file.

At step 504, the system may decrypt the mapping file position index file.

In step 506, the system may read the mapping split file and the mapping index file using the mapping file position index file.

At any step 508, the system may decrypt the mapping index file.

At step 510, the system may reconstruct the mapping file using the mapping index file and the mapping split file.
At any step 512, the system may decrypt the mapping file.

At step 514, the system may read the SPBF index file and the SPBF split file.

At any step 516, the system may decrypt the SPBF index file.

In step 518, the system may reconstruct the SPBF file using the SPBF index file and the SPBF split file.

At any step 520, the system may decrypt the SPBF file.

In step 522, the system may use the mapping file and the SPBF file to reconstruct the partial biocharacteristics.

In step 524, the system may use more than one partial biometric feature to reconstruct the complete biometric feature.

Alternatively, the original SPBF may be reconstructed by the process shown in FIG.

At step 602, the system may obtain a mapping file position index file.

At any step 604, the system may decrypt the mapping file position index file.

In step 606, the system may use the mapping file position index file to obtain the mapping split file and the mapping index file.

At any step 608, the system may decrypt the mapping index file.

At step 610, the system may reconstruct the mapping file using the mapping index file and the mapping split file.

At any step 612, the system may decrypt the mapping file.

At step 614, the system may read the SPBF split file position index file.

At any step 616, the system may decode the SPBF split file position index file.

In step 618, the system may use the SPBF split file position index file to obtain the SPBF index file and the SPBF split file.

At any step 620, the system may decrypt the SPBF index file.

At step 622, the system may reconstruct the SPBF file using the SPBF index file and the SPBF split file.

At any step 624, the system may decrypt the SPBF file.

In step 626, the system may use the mapping file and the SPBF file to reconstruct the partial biocharacteristics. The biometric mapping file should contain enough information to reconstruct the biometric features.

At step 628, the system may use more than one partial biometric feature to reconstruct the complete biometric feature.

FIG. 7 shows an example of a general reconstruction process of an arbitrary file.

At step 702, the system may obtain a file position index file. At any step 704, the system may decrypt the file position index file. At step 706, the system may obtain a file index file. At any step 708, the system may decrypt the file index file. At step 710, the system may obtain a file split file. In step 712, the system may reconstruct the file using a split file and an index file. At any step 714, the system may decrypt the file.

FIG. 8 shows an example of the file deletion process. At step 802, the system may obtain a file index file. At any step 804, the system may decrypt the file index file. In step 806, the system may use the file index file to optionally delete one or more fragment files (eg, cloud storage outside the blockchain, corporate server, or client device).

FIG. 9 shows an example of biometric authentication processing using an encrypted SPBF file. This biometric can be performed to identify the user and make (one or more) files securely stored accessible or given access. When the SPBF file is used to reconstruct all or part of the original biometric file, it is preferable that the SPBF file is not hashed before it is stored. This is because the hashing is irreversible and cannot be reconstructed. Optionally, a biofeature vector may be extracted from the SPBF (which is neither encrypted nor hashed). When using biofeature vectors, preferably hashing should be done for unencrypted or hashed biofeature vector files (any), not SPBF files. This is because usually useful biometric vectors can only be obtained from one or more unencrypted or hashed SPBF files or one or more unencrypted or hashed original biometric files. is there.

In step 902 of FIG. 9, the system may receive a biometric capture of a person (user). This is confirmed by the biometric authentication device. In step 904, the system may acquire the SPBF by process 500 of FIG. 5 or process 600 of FIG. In step 906, the system may compare the input biological features with the image or pattern reconstructed from the stored SPBF. At step 908, the system returns a match or mismatch as a result of the comparison.

FIG. 10 shows an example of biometric authentication processing using a hashed SPBF file (eg, executed for user authentication and / or access request). In step 1002, the system receives the input biological features from the user using, for example, a biological feature acquisition device, and transmits the acquired biological feature information to the system.

In step 1004, the system can convert the input biometrics into an SPBF file by the same conversion method as for storing the user's SPBF file (eg, FIGS. 2, 4, 4A). That is, the system reads the mapping data, conversion data, construction order, and index file used during the original SPBF file generation, selects the same feature block, and performs any conversion and any conversion performed during the original storage. You may perform the build.

In step 1006, the system may hash the SPBF file with the same hashing routine that was hashed when the user's SPBF file was stored (eg, FIGS. 2, 4, 4A).

In step 1008, the system may compare the SPBF hash file with the stored SPBF hash file.

In step 1010, the system may return a comparison result, i.e. match or disagreement, and use the result as a biological feature portion of the authentication routine.

FIG. 11 shows an example of biometric authentication processing using the SPBF biometric feature vector. In step 1102, the system receives the input biological features from the user using, for example, a biological feature acquisition device, and transmits the acquired biological feature information to the system.

In step 1104, the system can convert the input biometrics into an SPBF file by the same conversion method as for storing the user's SPBF file (eg, FIGS. 4, 4A). That is, the system reads the mapping data, conversion data, construction order, and index file used during the generation of the original biometric SPBF file, selects the same feature block, and is arbitrary that was executed during the original storage. Conversions and builds may be performed.

In step 1106, the system may extract the SPBF biofeature vector by the same biofeature vector extraction routine as when the biofeature vector was extracted during storage.

In step 1108, the system may compare the SPBF biometric vector file with the stored SPBF biometric vector file.

At step 1110, the system may return a comparison result, i.e. match or disagreement, and use the result as a biological feature portion of the authentication routine.

FIG. 12 shows an example of biometric authentication processing using a hashed biometric feature vector file. In this process, steps 1202, 1204, 1206 are the same as steps 1102, 1104, 1106 of FIG.

In step 1208, the system has the same hashing function as storing the original SPBF biofeature vector obtained from the biofeature vector file obtained from the newly formed SPBF (eg, newly obtained from the user). May be used for hashing.

In step 1210, the system may compare the SPBF biometric hash file with the stored biometric SPBF hash file.

At step 1212, the system may return a comparison result, ie a match or mismatch, and use the result as a biometric portion of the authentication routine.

As described in this section, there are many applications for secure storage systems. As one such application, the system 100 may be configured to receive one or more identifiers in response to one or more requests to authenticate the identities of one or more individuals. The system may respond to the request using the identity verification element 120 shown in FIG. For example, the first identifier described above may be received in response to a request for personal identity of the first individual. A personal identification request may be made in response to and / or for financial transactions, information exchanges, and / or other interactions. Requests may be received from other individuals and / or other third parties.

The system 100 may be configured to extract biometric data associated with one or more individuals from the corresponding authentication address. For example, the first biometric data associated with the first individual may be extracted from the first authentication address. Extraction of information (eg, biometric data) from an authentication address may include encryption of the information.

According to some forms, the system 100 responds to the first individual's receipt of an identity verification request by matching the first individual with biometric data matching the first biometric data and the first private key. It may be configured to require the provision of a private key to be provided. The request may be communicated via the computing platform 104 associated with the first individual. The request may be communicated via a graphical user interface and / or other user interface provided by the computing platform 104 associated with the first individual. The requirement may include a sign that is one or more of a visual sign, an auditory sign, a tactile sign and / or other sign.

In some embodiments, the system 100 may be configured to provide a request to the computing platform 104 associated with the first individual upon receipt of an identity verification request for the first individual. The request causes the computing platform 104 to automatically provide the (one or more) servers 102 with biometric data matching the first biometric data and / or a private key matching the first private key. It may be a thing.

The system 100 may be configured to authenticate the identities of one or more individuals upon or depending on the receipt of matching biometric data and private keys. For example, the personal identity of the first individual may be authenticated upon receipt of (i) biometric data matching the first biometric data and (ii) private key matching the first private key. Authentication of the personal identity of the first individual may include comparing the stored information with the newly received information. According to some forms, the identification system 100 provides biometric data in which the personal identity of the first individual matches (i) first biometric data or second biometric data and (ii) first biometric data. It may be configured to be authenticated upon receipt of a private key that matches the private key. In such a form, a so-called "M-of-N" signature can be realized, which requires a larger subset of identification information groups for personal authentication.

In some forms, the system 100 is smart in that the biometric data matching the first biometric data and the private key matching the first private key are used to authenticate the personal identity of the first individual. It may be configured to be used for signing contracts.

In some forms, at least one dedicated node performs smart contract signing to authenticate the personal identity of the first individual or user. A given dedicated node may include one or more servers 102. A given dedicated node may be a public or private node configured for smart contract signing to generate new transactions and / or authenticate.

FIG. 16 shows an overview 1600 of examples of applied blockchains relating to one or more forms. As illustrated, a private layer 1602 may be used that can act as an authorization management layer for blockchain access, distributed ledger access, or distributed database access. It may be built on an Ethereum blockchain (eg blockchain), hyperledger distributed ledger (eg distributed ledger 1606) for management purposes, for example. As shown, there may be a mechanism for storing files (eg, biometric data and other files). These elements may be connected to an API (application programming interface) 1604 such as a RESTful API, and a blockchain database 1608, for example, to provide and / or improve storage such as a bigchain DB. It can be connected to, for example, biometric appliqués or websites. Yet another configuration can be adopted.

Illustrative forms may facilitate access to personal data. There can be different levels of access to personal data on the blockchain. Access control can be enabled at the public / private key set level. Examples of access levels are network administrators (unlimited access to blockchain), national-level authorities (unlimited read-only access), state / local-level authorities (restricted read-only access), and emergency response police. And other services, including paramedics (access to the corresponding given personal data by personal fingerprint / retina), participating stores (limited access), and / or other access levels.

These aspects may relate to mobile data processed, collated, and / or retained within the blockchain (whether or not relating to the biometric identity of the individual and / or client).

This technique has been illustrated in detail based on what is currently considered to be the most practical and preferred form. However, this detail is merely exemplary, and the present technology is not limited to the disclosed form, but also covers modifications included in the spirit and scope of the attached claims and the same configuration. Is. For example, it will be appreciated that the present technology assumes that one or more features of any form can be combined with one or more features of any other form.

Claims (60)

A system that securely stores electronic data
Upon receiving the meaningful electronic information file associated with the user, storing it securely, and receiving the electronic information file, at least the first fragment (# 1) and the second fragment of the electronic information file A hardware processor (126) configured to form a fragment (232, 314, 442) containing (# 2) and
A distributed data storage system (234A, 316A, 444A) having a plurality of nodes for storing blocks of information in a first non-temporary storage device.
It has a second non-temporary storage device (234B, 316B, 444B) outside the distributed data storage system.
The processor further stores at least the first fragment (# 1) of the file in the distributed data storage system (234A, 316A, 444A) and at least the second fragment (# 2) of the file. A system configured to be stored outside the distributed data storage system (234B, 316B, 444B). The processor includes location data for at least the first fragment and at least the second fragment of the file, including at least the first fragment of the file and reconstruction data of the second fragment. The system according to claim 1, wherein a mapping file for storing the above is generated, and at least a part of the mapping file or the mapping file is stored in the distributed ledger storage. The system of claim 1, wherein each of the fragments of the file makes no sense until it is partially or completely reconstructed into the file. The system of claim 1, wherein the processor is configured to receive digital biometric files that include at least a portion of biometric information associated with the user as electronic information. The system of claim 1, wherein the processor is configured to receive, as the file, a digital file associated with the user. The system according to claim 1, wherein the distributed data storage system is a reliable utility for storing tamper-proof data. The processor receives the graphic or image file associated with the user as the electronic information, divides the graphic or image into a feature block group, and maps the position of the feature block constituting the graphic or image. A mapping file is generated, at least the first block of the feature blocks is stored in the distributed data storage system, and at least the second block of the feature blocks is stored outside the distributed data storage system. The system according to claim 1, which is configured in 1. The processor converts at least the first and second blocks in the feature block before storing at least the first and second blocks in the feature block, and stores the conversion result in the mapping file. 7. The system of claim 7. The processor divides the mapping file into at least a first mapping file fragment and a second mapping file fragment, stores at least the first mapping file fragment in the distributed data storage system, and at least said first. The system according to claim 8, wherein the mapping file fragment of 2 is configured to be stored outside the distributed data storage system. The system of claim 8, wherein the processor is configured to encrypt at least the first block of the feature blocks and at least the second block of the feature blocks. The system of claim 9, wherein the processor is configured to encrypt at least the first block of the feature blocks and at least the second block of the feature blocks. The system of claim 8, wherein the processor is configured to at least encrypt the mapping file. The system of claim 8, wherein the set of feature blocks is a subset of the feature blocks that form the graphic or image. The system according to claim 8, wherein the graphic or image file is a file containing at least a part of biometric information associated with the user. The processor encrypts the subset of the feature blocks, decomposes the subset of the encrypted feature blocks into at least a first fragment and a second fragment, and at least the first fragment is the distributed data storage system. 13. The system of claim 13, configured to store at least the second fragment outside the distributed data storage system. The processor generates a hash of the subset of the biometric graphics, stores at least a portion of the hash in the distributed data storage system, and stores at least the other portion of the hash outside the distributed data storage system. 13. The system of claim 13, configured to store. The processor is configured to authenticate the user in response to a user request associated with the user to access information stored in the system before granting access. At least a portion of the hash of the biometric graphic file newly received by the system from the user is the at least the first fragment in the distributed data storage system and at least the second fragment outside the distributed data storage system. Matching is required as at least part of the conditions under which the user is authenticated, including comparison with a hash obtained from the fragment, and the processor is stored in the system associated with the user. In response to a user request to access the information, the user is configured to authenticate the user before granting access, which authenticates the subset of the feature blocks of the biometric graphic from the user. 15. The 15th aspect of claim 15, wherein the system is required to match as at least a part of the conditions under which the user is authenticated, including comparing the newly received biometric file with a subset of the corresponding feature blocks. system. 13. The system of claim 13, wherein the subset of the feature blocks is a grouping of continuous or discontinuous blocks of the biofeature graphic. 13. The system of claim 13, wherein the feature blocks within the subset of the feature blocks are transformed before being stored. The processor stores a second graphic or image file associated with the user, divides the graphic or image in the second graphic or image file into feature blocks, and constitutes the graphic or image. A mapping file that maps the position of the block is generated, at least the first block in the feature block is stored in the distributed data storage system, and at least the second block in the feature block is stored in the distributed data storage system. The system according to claim 7, which is configured to be stored outside of. The processor stores a second graphic or image file associated with the user, divides the graphic or image in the second graphic or image file into feature blocks, and constitutes the graphic or image. A mapping file that maps the position of the block is generated, at least the first block in the feature block is stored in the distributed data storage system, and at least the second block in the feature block is stored in the distributed data storage system. 17. The system of claim 17, configured to be stored externally to. The system of claim 1, wherein the processor is configured by a machine-readable instruction to further form an index file indicating how the fragment is reconstructed into the file. The processor further generates fragments of the index file, including at least a first fragment and a corresponding second fragment.
At least the first fragment of the index file is stored in a distributed data storage system.
22. The system of claim 22, wherein at least the second fragment of the index file is configured to be stored outside the distributed data storage system. The processor further generates at least a third fragment of the file and puts the third fragment into the distributed data storage system separately from the first fragment stored in the distributed data storage system. The system according to claim 1, which is configured to be stored. The system of claim 1, wherein the processor is further configured to store at least the first fragment as a transaction in the distributed data storage system. 24. The system of claim 24, wherein the processor is further configured to store at least the first fragment and the third fragment as different transactions in the distributed data storage system. The system according to claim 1, wherein the processor is further configured to reconstruct the file fragment into the file in response to a request from the user by the machine-readable instruction. The system of claim 1, wherein the processor is configured to further generate the first file fragment, including at least a portion of the header of the file, by the machine-readable instruction. The system according to claim 1, wherein the external storage of the distributed data storage is a digital storage device that does not have its own CPU. The system according to claim 1, wherein the distributed data storage is a distributed ledger storage. A safe way to store electronic data
Upon receiving a request by the processor to store a file of meaningful electronic information associated with the user,
Upon receiving the electronic information file, forming a fragment containing at least the first fragment of the electronic information file and the corresponding second fragment.
To provide a distributed data storage system having a plurality of nodes for storing blocks of information in the first non-temporary storage device.
A second non-temporary storage device is provided outside the distributed data storage system, and
The processor includes storing at least the first fragment of the file in the distributed data storage system and storing at least the second fragment of the file outside the distributed data storage system. Method. The processor includes position data including at least the first fragment of the file and at least the second fragment, and at least the first fragment of the file and at least the reconstruction data of the second fragment. 31. The method of claim 31, wherein a mapping file for storing the mapping file is generated, and the mapping file or at least a part of the mapping file is stored in the distributed ledger storage. 31. The method of claim 31, wherein each of the fragments of the file makes no sense until it is partially or completely reconstructed into the file. 31. The method of claim 31, wherein in the receiving step, the processor receives, as the electronic information, a digital biometric file that includes at least a portion of the biometric information associated with the user. 31. The method of claim 31, wherein in the receiving step, the processor receives the digital file associated with the user as the file. 31. The method of claim 31, wherein the distributed data storage system is a trusted utility for storing tamper-proof data. In the receiving step, the processor receives the graphic or image file associated with the user as the electronic information, divides the graphic or image into a feature block group, and constitutes the graphic or image. A mapping file that maps the position of the block is generated, at least the first block in the feature block is stored in the distributed data storage system, and at least the second block in the feature block is stored in the distributed data storage system. 31. The method of claim 31, which is stored outside of. Before the processor stores at least the first and second blocks in the feature block, at least the first and second blocks in the feature block are converted and the conversion result is stored in the mapping file. 37. The method of claim 37, further comprising the steps of The mapping file is divided into at least a first mapping file fragment and a second mapping file fragment, at least the first mapping file fragment is stored in the distributed data storage system, and at least the second mapping file. 38. The method of claim 38, further comprising storing the fragment outside the distributed data storage system. 38. The method of claim 38, further comprising the step of encrypting at least the first block of the feature blocks and at least the second block of the feature blocks. 39. The method of claim 39, further comprising the step of encrypting at least the first block of the feature blocks and at least the second block of the feature blocks. 38. The method of claim 38, further comprising at least the step of encrypting the mapping file. 38. The method of claim 38, wherein the set of feature blocks is a subset of the feature blocks that form the graphic or image. 38. The method of claim 38, wherein the graphic or image file is a file that includes at least a portion of biometric information associated with the user. The subset of the feature blocks is encrypted, the subset of the encrypted feature blocks is decomposed into at least a first fragment and a second fragment, and at least the first fragment is stored in the distributed data storage system. 43. The method of claim 43, further comprising storing at least the second fragment outside the distributed data storage system. A step of generating a hash of the subset of the biometric graphic, storing at least a portion of the hash in the distributed data storage system, and storing at least the other portion of the hash outside the distributed data storage system. The method of claim 43, further comprising. In response to a user request associated with the user to access information stored in the system, the user is authenticated before granting access, and the authentication is newly received by the system from the user. At least a part of the hash of the biometric feature graphic file is a hash obtained from at least the first fragment in the distributed data storage system and at least the second fragment outside the distributed data storage system. In response to a user request to access information stored in the system associated with the user that is required to match, including comparison, as at least part of the conditions under which the user is authenticated. Authenticates the user before granting access, which authenticates the subset of the feature blocks of the biometric graphic of the corresponding feature block of the biometric file newly received by the system from the user. 45. The method of claim 45, comprising comparing with a subset and further comprising a step that is required to match as at least part of the conditions under which the user is authenticated. 43. The method of claim 43, wherein the subset of the feature blocks is a grouping of continuous or discontinuous blocks of the biofeature graphic. 43. The method of claim 43, further comprising transforming feature blocks within the subset of feature blocks prior to storage. The feature that the processor stores a second graphic or image file associated with the user, divides the graphic or image in the second graphic or image file into feature blocks, and constitutes the graphic or image. A mapping file that maps the position of the block is generated, at least the first block of the feature blocks is stored in the distributed data storage system, and at least the second block of the feature blocks is stored in the distributed data storage system. 37. The method of claim 37, further comprising a step of storing externally. The feature that the processor stores a second graphic or image file associated with the user, divides the graphic or image in the second graphic or image file into feature blocks, and constitutes the graphic or image. A mapping file that maps the position of the block is generated, at least the first block of the feature blocks is stored in the distributed data storage system, and at least the second block of the feature blocks is stored in the distributed data storage system. 47. The method of claim 47, further comprising a step of storing externally. 31. The method of claim 31, further comprising forming an index file showing how the processor reconstructs the fragment into the file. The processor generates a fragment of the index file that includes at least a first fragment and a corresponding second fragment.
At least the first fragment of the index file is stored in a distributed data storage system.
52. The method of claim 52, further comprising storing at least the second fragment of the index file outside the distributed data storage system. The processor generates at least a third fragment of the file and stores the third fragment in the distributed data storage system separately from the first fragment stored in the distributed data storage system. 31. The method of claim 31, further comprising the steps of 31. The method of claim 31, wherein the processor further comprises storing at least the first fragment as a transaction in the distributed data storage system. 31. The method of claim 31, wherein the processor further comprises storing at least the first fragment and the third fragment as different transactions in the distributed data storage system. 31. The method of claim 31, wherein the processor further comprises reconstructing the file fragment into the file in response to a request from the user. 31. The method of claim 31, wherein the processor further comprises the step of generating the first file fragment that includes at least a portion of the header of the file. 31. The method of claim 31, wherein the storage outside the blockchain is a digital storage device that does not have its own CPU. 31. The method of claim 31, wherein the distributed data storage is a distributed ledger storage.

Images