Multiple encryption data storage and retrieval system
Patent Information
- Application Number
- BR112025021331
- Authority / Receiving Office
- BR · BR
- Patent Type
- Applications
- Publication Date
- 2026-09-01
Smart Images

Figure 00000000_0000_ABST
Description
1 / 22 MULTIPLE ENCRYPTION DATA STORAGE AND RETRIEVAL SYSTEM PRIORITY CLAIM
[001] This application claims priority and the benefit of the filing date of the jointly and jointly assigned provisional application entitled MULTIPLE ENCRYPTION DATA STORAGE AND RETRIEVAL SYSTEM, which was assigned serial number 63 / 456,709, filed on April 3, 2023 and is incorporated herein by reference. BACKGROUND OF THE INVENTION 1. Field of the Invention
[002] The present invention relates generally to computer systems for secure data storage. More particularly, the present invention is for a system and method that encrypts data in multiple ways for secure storage and retrieval, with complete decryption possible only by the end user. 2. Description of the State of the Art
[003] Multiple encryption is the process of encrypting an already encrypted message one or more times. Multiple encryption can be done using the same algorithm or a different one. This methodology is also called cascade encryption, cascade ciphering, and superencryption. Superencryption refers to the outer layer of encryption of multiple encryption.
[004] One advantage of multiple encryption is that using two different cryptomodules and keying processes from two different sources requires both sources to be compromised for the security to fail completely. A cryptanalyst must break both encryptions to obtain any information. However, this will have the disadvantage of causing the encrypted data file to be up to twice the size of the data. Petition 870250109332, dated 11 / 28 / 2025, page 13 / 41 2 / 22 originals.
[005] Additionally, if the encryption key used is the same for both, the second cipher could possibly undo the first cipher, partially or entirely. This is true for ciphers where the decryption process is the same as the encryption process, and the second cipher would completely undo the first. If an attacker recovered the key through cryptanalysis of the first encryption layer, the attacker could possibly decrypt all remaining layers, assuming the same key was used for all layers. To avoid this risk, the use of statistically independent keys for each layer is known.
[006] Ideally, each key should have separate and different generation, sharing, and management processes. In existing multi-encryption systems, for encryption processes that require sharing an Initialization Vector (IV), these are typically shared openly or disclosed to the recipient (and everyone else). It is common practice to share keys, such as in PGP message transmission.
[007] The “Rule of Two” is a data security principle of the NSA’s Commercial Solutions for Classified Programs (CSfC). It specifies two completely independent layers of encryption to protect data. For example, data can be protected by both hardware encryption at its lowest level and software encryption at the application layer. This could mean using two FIPS-validated cryptomodule software from different vendors to encrypt or decrypt data.
[008] The importance of supplier and / or model diversity across component layers revolves around removing the possibility that Petition 870250109332, dated 11 / 28 / 2025, page 14 / 41 3 / 22 manufacturers or models will share a vulnerability. This way, if one component is compromised, there will still be an entire layer of encryption protecting the information at rest or in transit.
[009] A problem arises if the keys for each encryption layer are accessible or known by a data storage system; the system will ultimately have direct access to the data. In existing storage systems, even hashed data may be unencrypted, as the hash key is stored somewhere within the verification system, either in the admission device or in some data storage accessible to the system. Consequently, the entity controlling the data storage may be compelled to provide the fully decrypted data to third parties, such as a court, a law enforcement authority, or a government entity. SUMMARY OF THE INVENTION
[010] As seen in the discussion above, there is a need to provide a system and method for secure data storage that allows data to be stored in a way that does not violate or imply privacy laws and regulations. Furthermore, it would be advantageous to store the data in a way that is not accessible to any other person or entity besides the user. This would minimize the risk of data theft and coerced data production.
[011] In general, the present invention is for a computer system and method for storing and retrieving encrypted user data that allows the confidential storage of data that is accessible only with the user's permission. The system and method include a data admission device that admits original user data and communicates with a management system. Petition 870250109332, dated 11 / 28 / 2025, page 15 / 41 4 / 22 data for encryption, storage, and retrieval of data. The data management system may have a resident data storage or a remote storage in communication with it for selective storage and retrieval of multi-encrypted data.
[012] The system and method allow a user to first encrypt data in such a way that the user possesses only one of the encryption keys necessary for the complete decryption of the stored and encrypted data. The encrypted data is then at least double-encrypted and stored in such a secure manner that it can be stored in a public blockchain architecture, if desired. Complete decryption of the original user data can only be performed with access to the user's encryption key.
[013] In one embodiment, the system includes a data admission device that selectively admits user data, with the device communicatively connected to a network, such as the Internet, WAN, or other public or private network. A data management system is also connected to the network and in selective communication with the data admission device, with the data management system in communication with at least one data store for the selective storage and retrieval of multi-encrypted data. Upon a request from the data admission device for the admission of new user data, the data management system transmits an initial encryption key to the data admission device for the admission of original user data.
[014] The data admission device then receives the first encryption key from the data management system and obtains a user key from a user and then creates a second encryption key from Petition 870250109332, dated 11 / 28 / 2025, page 16 / 41 5 / 22 of the first encryption key and the user key, either by hashing or another mathematical operation. After the second key is created on the device, the device admits and encrypts the original user data with the second encryption key to create the first encrypted user data and then transmits the first encrypted user data to the data management system across the network. In one embodiment, the device stores the second encryption key on a user device and deletes the second encryption key (and the user key and the first encryption key) from the data admission device.
[015] After receiving the first encrypted user data, the data management system generates a third encryption key, further encrypts the first encrypted user data with the third encryption key to create a second encrypted user data, and stores the second encrypted user data in a data storage. The data storage can be local, remote, or cloud-based, and can be public or private.
[016] In one embodiment, the data management system additionally creates a verification token and embeds the verification token with the first encrypted user data before encrypting the second encrypted user data with the third encryption key, such that the second encrypted user data contains the verification token embedded within it. The system then stores the second encrypted user data. In this embodiment, when the system receives a user request for the user data, with the request including the second encryption key, the system retrieves the second encrypted user data from the data storage, decrypts the second encrypted user data with the third key, such that the data becomes the Petition 870250109332, dated 11 / 28 / 2025, page 17 / 41 6 / 22 initial unencrypted user data and the verification token. The system then verifies the integrity of the verification token, which indicates that the initial encrypted user data was successfully stored and retrieved. A plurality of verification tokens may also be used within the stored data. The system then decrypts the initial encrypted user data with the second encryption key received from the user to become the original user data.
[017] The present system and method for the secure admission and storage of data therefore provides an advantage, as it allows data to be stored in a way that is not accessible without a key from the user. The system and method can therefore store data in a way that minimizes the risk of data theft and coerced production. Only with the user's permission (with the key) can the stored encrypted data be retrieved and unencrypted in its original form. BRIEF DESCRIPTION OF THE DRAWINGS
[018] Fig. 1 is a representative diagram that illustrates a data management system embodiment in selective communication with a data intake device, represented here by a smartphone mobile device.
[019] Fig. 2 is a representative diagram that illustrates one embodiment of the data management system with a dedicated data input device, a user device, and a point-of-sale device for a cryptocurrency purchase transaction.
[020] Fig. 3A is a data flow diagram that illustrates the data flow and processes between the user data admission device, virtual data management system servers, and a storage device. Petition 870250109332, dated 11 / 28 / 2025, page 18 / 41 7 / 22 of data modalized as a Hyperledger Fabric.
[021] Fig. 3B is a data flow diagram that illustrates the data flow and processes between a user's mobile device, a point-of-sale device, the virtual servers of the data management system, and the data storage modalized as a Hyperledger Fabric.
[022] Fig. 4 is a flowchart of one embodiment of a process for a user to admit data into a data device.
[023] Fig. 5 is a flowchart of one embodiment of a process for initial preparation and admission of encrypted user data into the data management system, including the use of a verification token embedded in the doubly encrypted data.
[024] Fig. 6 is a flowchart of one embodiment of a process for a user to request the decryption of a cryptocurrency at a point of sale.
[025] Fig. 7 is a flowchart of one mode of a process for verifying a user purchase transaction by the data management system.
[026] Fig. 8 is a flowchart of one embodiment of a process for complete decryption of stored user data using a verification token for data integrity. DETAILED DESCRIPTION OF THE INVENTION
[027] With reference to figures in which like numbers represent like elements, Fig. 1 is a representative diagram illustrating one embodiment of a system architecture 10 for data management. Here, a data management system 12 is modeled as virtual servers connected to a network 18, shown here as the Internet, and the data management system 12 is in Petition 870250109332, dated 11 / 28 / 2025, page 19 / 41 8 / 22 selective communication with the data admission device 14, which is modalized here as a smartphone / mobile device for an end user 16 that will store encrypted data in the data management system 12. As modalized here, the data management system 12 is in additional communication with at least one data store for selective storage and retrieval of encrypted data. The data store shown in this embodiment is a private Hyperledger Fabric database 20, as well as a public ledger 22, such as ETHEREUM, NFT, or another public blockchain architecture.
[028] In the embodiment of Fig. 1, the data intake device, modalized here by a smartphone / mobile device 14, is configured to selectively admit data from a user 16, such as admitting a data file, and will selectively communicate across the network to encrypt and store this data in the data management system 12, as further described in the present invention.
[029] Fig. 2 is a representative diagram illustrating another embodiment of the system 30 for data management that allows the use of cryptocurrency stored at the point of sale, such as in an online cryptocurrency wallet. In this embodiment, there is a data input device 34, a user device 46 (e.g., an end-user mobile device), and a point-of-sale device 48 (also referred to as a point-of-sale verification device or verification point device) that are used for cryptocurrency purchases. Here, an embodiment of the data management system 32 is modalized with virtual servers connected to a network 38, shown here as the Internet, but it could be any private or public data communication network, wired or wireless. The data management system 32 is in selective communication with various Petition 870250109332, dated 11 / 28 / 2025, page 20 / 41 9 / 22 devices across the network 38.
[030] The data admission device 34 that will initially admit cryptocurrency from an end user 36, which may be a computer, laptop or other specialized equipment sent to admit data such as fingerprints, retina scans, facial scans and DNA. In this configuration, the end user 44 at a point of sale 48 who wishes to use the stored cryptocurrency for a transaction will have a mobile device 46 with him, here modalized as a smartphone / mobile device 46, which will contain the user key necessary to authorize the decryption of the stored cryptocurrency, as further described in the present invention.
[031] As shown in Fig. 2, the data management system 32 is in additional communication with at least one data storage for selective storage and retrieval of encrypted data, here being a cryptocurrency or a cryptocurrency wallet. The data storage shown in this embodiment is a private Hyperledger Fabric database 40, as well as a public ledger 42, such as ETHEREUM, NFT, or another public blockchain architecture. In this embodiment, the point of sale 48 and the computer device on it can perform the final retrieval of the end-user cryptocurrency 44 for a desired transaction. The cryptocurrency is encrypted multiple times by the system and cannot be completely decrypted without the end-user key 44.
[032] Fig. 3A is a data flow diagram that illustrates the data flow and processes between the user data admission device 50, virtual data management system servers 52, and a data store 54, modeled as a Hyperledger Fabric. In this Petition 870250109332, dated 11 / 28 / 2025, page 21 / 41 In embodiment 10 / 22, upon request from the data admission device for user data admission, the user data admission device 50 sends a data admission request for user creation to the virtual servers 52, which then transmit a first encryption key (K1) to the data admission device 50 for original user data admission. The key K1, or any key described in the present invention, can be any random or pseudo-random standard session number of any size. In one embodiment, the key K1 is a randomly generated 256-bit hexadecimal prime number.
[033] The data admission device 50 then receives the first encryption key (K1) from the virtual servers 52 and admits user data and then obtains a user key from a user. This user key can be any data provided by the user, such as a PIN, an answer to a question, a word, a key sent from a user device, such as a mobile device, or data. The data admission can be a data file in any format, including cryptocurrencies, multimedia, documents, and other keys. The data can be stored in open source or other formats, so that it can be used on common data platforms.
[034] The data admission device 50 then creates a second encryption key (K2) from the first encryption key and the user key, either by hashing or another mathematical operation between the keys. By doing so, it allows the creation of the second key (K2) to be unknown to the virtual servers 52, especially since the local copies of the user key, the first key (K1) and the second key (K2) are deleted from the admission device 50, as further described in the present invention. Once the second key (K2) is created, the device Petition 870250109332, dated 11 / 28 / 2025, page 22 / 41 11 / 22 Data Admission 50 admits the user's original user data or can be done simultaneously with or before the creation of the second key (K2). The data admission device 50 then encrypts the original user data with the second encryption key (K2) to create the first encrypted user data (K2 encrypted data). If modalized only with the user's mobile device, such as the smartphone / mobile device 14 in Fig. 1, as the data admission device, the admission process can occur only on the mobile device 14, as described in the present invention.
[035] Each step of the encryption can be by hashing, multiplication of primary key pairs, elliptic curve cryptography, or any other satisfactory one-way mathematical cryptography. K2 encryption means that user data will not be accessible to the data management system without K2 being provided by the user. This allows the system to remain secure against internal theft or attacks to access unencrypted user data stored on or through the system.
[036] The data admission device 50 then transmits the first encrypted user data to the virtual server 52 of the data management system (32 in Fig. 2) over the network (38 in Fig. 2). In one embodiment, the device then stores the second encryption key (K2) on a user device (46 in Fig. 2) and deletes the second encryption key (and the user key) and the first encryption key (K1) from the data admission device 50. If modalized only with the user's mobile device on the data admission device, such as the smartphone / mobile device 14 in Fig. 1, the mobile device 14 will store the second encryption key (K2) and delete the first encryption key (K1) and the user key. The mobile device 14 can also be modalized Petition 870250109332, dated 11 / 28 / 2025, page 23 / 41 12 / 22 to transfer K1 to other devices and locations securely, under the guidance of the end user 16.
[037] After receiving the first encrypted user data, the virtual servers 52 of the data management system generate a verification token (T) for encrypting and decrypting the first encrypted data. In some examples, the verification token (T) is an encryption key. The verification token (T) can be any number of any size, but it must be sufficient to provide the belief that a verification token error will indicate a compromise / error of the first encrypted data. One or more verification tokens (T) can also be used and placed with a selected block of first encrypted data (K2 encrypted data) before being encrypted with a third key (K3).Virtual servers 52 then create an additional key (K3) which they use to further encrypt the first encrypted user data with the verification token to create second encrypted user data (K3 encrypted data). Virtual servers 52 then store the second encrypted user data in a data store 54, shown here as a Hyperledger Fabric. Virtual servers 52 then send a data storage confirmation to the data admission device 50.
[038] Fig. 3B is a data flow diagram illustrating one embodiment of the data flow and processes for using a cryptocurrency stored and protected by an end user. In this embodiment, which can utilize system 30 as architected in Fig. 2, the process uses a user's mobile device 60, a point-of-sale device 62, the virtual servers 64 of the data management system, and the data storage 66 modalized as a Hyperledger Fabric. The Petition 870250109332, dated 11 / 28 / 2025, page 24 / 41 13 / 22 The user's mobile device 60 sends a request for the user's cryptocurrency to both the point-of-sale system 62 and the virtual servers 64 of the data management system (32 in Fig. 2), with the authorization request from system 30 (Fig. 2) including the second encryption key (K2). The point-of-sale device 62 similarly sends a request for the cryptocurrency to the virtual servers 64, such that the virtual servers 64 can match the request from mobile device 60 to the request from point-of-sale device 62.
[039] As soon as the user authorization request is received, virtual servers 64 identify the specific storage block(s) of the user-stored doubly encrypted cryptocurrency (K3 encrypted data) in Hyperledger 66 and then request that block from Hyperledger 66 to retrieve the second encrypted user cryptocurrency from the Hyperledger 66 data storage. Hyperledger 66 then sends the block(s) of the second encrypted user cryptocurrency (K3 encrypted data). In this mode, virtual servers 64 then request a new storage block for the second encrypted data, and Hyperledger 66 consequently moves the K3 encrypted data to the new storage block(s) and sends the new block position(s) to virtual servers 64.In this mode, storage blocks can be in a public and accessible Hyperledger, since third parties will not know in which specific block the user's data is kept or will have the encryption keys to decrypt the block.
[040] Virtual servers 64 then decrypt the second encrypted user data with the third key (K3) so that the data becomes the first unencrypted user data and the verification token(s) (T). Virtual servers 64 can then verify the integrity Petition 870250109332, dated 11 / 28 / 2025, page 25 / 41 14 / 22 of the verification token(s) (T). Then, if incorporated into the receipt of the second encryption key (K2) from the user device, as shown, the virtual servers 64 do not encrypt the first encrypted user data with the second encryption key (K2) to become original user data, i.e., the cryptocurrency. The virtual servers 64 then send the unencrypted data as a reference set to the point-of-sale device 62. The point-of-sale device 62 can then compare the new user data with the reference set to verify the user's identity. The point-of-sale device 62 can then send a confirmation or failure to the mobile device 60 to inform the user about the confirmation or failure of the purchase transaction and can also send the confirmation or failure to the virtual servers 64 so that the system 30 is aware of the transaction destination.
[041] In this mode, the point-of-sale device 62 also discards all cached copies, as does the user's K1. The point-of-sale device 62 can also store a transaction log and can interact with the virtual servers 64 to record transaction details, including confirmation of user identity verification. The virtual servers 64 can discard the first user data encrypted with the second encryption key (K2).
[042] Fig. 4 is a flowchart of one embodiment of a process for a user to admit data from a user data device, such as the admission device 34 in Fig. 2. The process in Fig. 4 is similar to that shown in the data flow of Fig. 3A. The device receives a request to create a new user and admit information into the system (30 in Fig. 2), as shown in step 70, and then a determination is made as to whether the first encryption key (K1) has been received from the data management system. Petition 870250109332, dated 11 / 28 / 2025, page 26 / 41 15 / 22 (virtual servers 32 in Fig. 2), as shown in decision 72. If the first encryption key (K1) has not been received in decision 72, then the process advances to the end, in termination 92. Otherwise, if the first encryption key (K1) has been received in decision 72, then the device will admit the user data (end user 36 in Fig. 2), as shown in step 74, and then a determination will be made as to whether a personal user key has been received from the user, as shown in decision 76.
[043] If the personal user key has not been received in decision 76, then the process advances to the end, in termination 92. Otherwise, the device then combines the personal user key with the first encryption key (K1) to create a second encryption key (K2), as shown in step 78, and the user data is encrypted with the second encryption key (K2), as shown in step 80. Then the first encrypted data is sent to the data management system (virtual servers 32 in Fig. 2), as shown in step 82, and then a determination is made as to whether the data management system received the first set of encrypted user data, as shown in decision 84. If the system does not receive the first set of encrypted data in decision 84, then the process advances to the end in termination 92.Otherwise, if the first set of encrypted user data has been received in the data management system in decision 84, then the second encryption key (K2) will be stored on the user's device (46 in Fig. 2), as shown in step 86.
[044] Then a determination is made as to whether confirmation was received from the data management system as to whether the first encrypted user data was successfully stored by the system, as shown in decision 88. If confirmation is not received in the decision Petition 870250109332, dated 11 / 28 / 2025, page 27 / 41 16 / 22 88, then the process advances to the end at termination 92. Otherwise, if confirmation is received at decision 88, then the first encrypted key (K1), the personal user key and the second encryption key (K2) will be discarded (i.e., deleted) from the data admission device (34 in Fig. 2), as shown in step 90, and then the process ends at termination 92.
[045] Fig. 5 is a flowchart of one embodiment of a process for initial preparation and admission of encrypted user data into the data management system, such as virtual servers 32 in Fig. 2, including the use of a verification token embedded in the double-encrypted data. The process in Fig. 5 is similar to that shown in the data flow of Fig. 3A. The process begins with the virtual servers 32 receiving a request to admit new user data from the data admission device (50 in Fig. 3A), as shown in step 100. Then a determination is made as to whether an adequate verification of the data admission device (50 in Fig. 3A) has been received, as shown in decision 102.Proper device verification may involve a key, PIN, or other security check to ensure the device can correctly accept user data and upload it to the data management system (virtual servers 52 in Fig. 3A) for the session.
[046] If verification does not occur at decision 102, then the process advances to the end at termination 114. Otherwise, if verification occurs at decision 102, then a determination is made as to whether the first encrypted user data (K2 encrypted data or K2 data) was received from the data intake device (50 in Fig. 3A), as shown by decision 104. If the first encrypted user data is not received at decision 104, then the process advances to the end at Petition 870250109332, dated 11 / 28 / 2025, page 28 / 41 17 / 22 termination 114. Otherwise, if the first encrypted user data is received in decision 104, then the data management system (virtual servers 52 in Fig. 3A) generates (i.e., creates) one or more verification tokens (T) and joins (i.e., incorporates) them into the first encrypted user data, as shown in step 106. Then, the first encrypted user data and the verification token (T) are encrypted with a third encryption key (K3), as shown in step 108, to create second encrypted user data.
[047] Next, the second encrypted user data (K3 encrypted data) is sent to a data store, such as Hyperledger Fabric 54 in Fig. 3A, for storage in one or more blocks, as shown in step 110. The storage can be private or open, depending on preference. Then the data management system sends confirmation to the data admission device of the user preparation and storage of the second encrypted data store, as shown in step 112, and then the process finishes in termination 114.
[048] In one embodiment, the first layer of encryption (K2) of the original data is hashed, and subsequently, the symmetric keys are encrypted via an asymmetric key (e.g., deploying the RSA algorithm). In an intermediate step, the first encrypted data and the hash digest are combined into a capsule and compressed together. To ensure the ciphertext has not been tampered with, the digest is computed before a retrieved data file is fully decrypted. Optionally, it is possible to encrypt the first layer capsule in addition with AES-256, comparable to a commonly shared 32-character symmetric password. Hybrid Encryption can then Petition 870250109332, dated 11 / 28 / 2025, page 29 / 41 18 / 22 can be added to create multiple encryption.
[049] Fig. 6 is a flowchart of one embodiment of a process for a user (end user 44 in Fig. 2) to request the decryption of encrypted cryptocurrency stored at a point of sale (48 in Fig. 2). The process in Fig. 6 is similar to that shown in the data flow of Fig. 3B. The process begins when the user (end user 44), via their mobile user device (46 in Fig. 2) in this embodiment, sends an authorization to use the stored cryptocurrency to the point of sale (62 in Fig. 3B), as shown in step 120, and then sends a transaction authorization and the second encryption key (K2) to the data management system (virtual servers 64 in Fig. 3B), as shown in step 122. Next, the mobile user device 60 accepts the transaction data from end user 44 locally for use in a comparison with the local transaction, as shown in step 124.Next, a determination is made as to whether the user verification was approved on point-of-sale device 62, as shown in decision 126.
[050] If verification authorization has not been received in decision 126, then the process advances to the end in termination 130. If authorization has been received in decision 126, then the local record of the data management system (virtual servers 64) will be updated and the process ends in termination 130. Step 128 is merely an embodiment and is not required to perform the process described in the present invention.
[051] Fig. 7 is a flowchart of one embodiment of a process for a cryptocurrency purchase transaction sent from the data management system (such as virtual server 32 in Fig. 2) to a point of sale (such as point of sale 48 in Fig. 2). The process in Fig. 7 is similar to that shown in the data flow of Fig. 3B. The process begins with the receipt of a Petition 870250109332, dated 11 / 28 / 2025, pages 30 / 41 19 / 22 A user's mobile device (60 in Fig. 3B) requests the system to make a purchase at the point of sale (POS), as shown in step 140. Then the point-of-sale device 62 sends a cryptocurrency request for that user to the data management system (virtual servers 64 in Fig. 3B), as shown in step 142.
[052] A determination is then made as to whether transaction authorization has been received by the user, as shown in decision 144. If authorization has not been received in decision 144, then the process proceeds to the end in termination 156. Otherwise, if the authorization set has been received in decision 144, then local data will be received from the user (end user 44 in Fig. 2) on the user's mobile device (46 in Fig. 2; mobile device 60 in Fig. 3B), as shown in step 146. User data can be obtained from the point-of-sale device 62 if it is modulated with the equipment required for this. A person skilled in the art can therefore reconfigure the devices and data flow to have different stages of the processes described in the present invention performed on different devices and locations in the system.
[053] After step 146, a determination is then made as to whether the transaction is authorized, thus confirming or refuting the user's identity, as shown in decision 148. If the data does not match in decision 148, that is, the requested cryptocurrency belongs to the user, then the process advances to the end in termination 156. Otherwise, if a match is confirmed in decision 148, then a confirmation or failure will be sent to the data management system (virtual servers 64), as shown in step 150, and a confirmation or failure will also be sent to the user's device 60, as shown in step 152. Then, all data is discarded from the point of sale 62, as shown in step 154, and the Petition 870250109332, dated 11 / 28 / 2025, pp. 31 / 41 20 / 22 process ends at termination 156.
[054] Fig. 8 is a flowchart of one embodiment of a process for complete decryption of stored user data using a verification token for data integrity in the data management system (such as virtual servers 32 in Fig. 2 or virtual servers 64 in Fig. 3b). The process in Fig. 8 is similar to that shown in the data flow of Fig. 3B. The process begins with the data management system (virtual servers 64) receiving a request from a user, either from user device 60, point-of-sale device 62, or both, as shown in step 160. Then, the data management system requests the second encrypted user data from the user (K3 encrypted data, also referred to as K3 data) from the data storage, such as Hyperledger Fabric 64 in Fig. 3B, as shown in step 162.In this mode, this request includes the encrypted user data stored in one or more blocks where the data is stored. A determination is then made to verify whether the second encrypted user data was received, as shown in decision 164.
[055] If the second encrypted user data is not received at decision 164, then the process advances to the end at termination 182. Otherwise, if the data was received at decision 164, then a storage block reset request is sent to the data store (a Hyperledger Fabric 66 in Fig. 3B) so that the stored data is moved, as shown in step 166. This step allows the storage of the second encrypted user data to be on a public blockchain or other publicly accessible storage medium. After step 166, a determination is made as to whether confirmation was received from the data store. Petition 870250109332, dated 11 / 28 / 2025, pages 32 / 41 21 / 22 data (Hyperledger Fabric 66) confirms that the data block(s) were successfully moved and the new location of the block(s), as shown in decision 168. If confirmation and the new location are not received in decision 168, then the process advances to the end in termination 182. Otherwise, if confirmation and the new location are received in decision 168, then the data management system (virtual servers 64) decrypts the second encrypted user data to become the first unencrypted user data (encrypted data K2) and the verification token (T), as shown in step 170.
[056] A determination is then made as to whether the intact verification token (T) is present in the unencrypted data, as shown in decision 172. If multiple verification tokens are present in multiple blocks of unencrypted data, then decision 172 may iterate through all data integrity checks on the newly decrypted data. If the verification token is not intact in decision 172, then the process advances to the end in termination 182.Otherwise, if the verification token(s) is / are intact at decision 172, then the second encrypted user data is decrypted with the user's sent key (K2) to become the original unencrypted user data (K2 data), as shown in step 174, and then the original data will be sent to point-of-sale device 62 for comparison with the new user data and verification of the user's identity, as shown in step 176. In this case, point-of-sale device 62 can be referred to as a third-party comparison device. Thus, the data management system can be configured to transmit the original user data to the third-party comparison device over the network.
[057] In another mode, the management system itself Petition 870250109332, dated 11 / 28 / 2025, pp. 33 / 41 22 / 22 data can retrieve new user data for comparison, such as from virtual servers 32, and send the results to other devices across the network. For example, the data management system can retrieve new user data from a point-of-sale device (e.g., point-of-sale device 62) across the network. The data management system can compare the new user data against the original unencrypted user data to determine a matching status. The data management system can then transmit the matching status to the point-of-sale device across the network.
[058] After step 176, a determination is then made as to whether the user was confirmed or failed at the point-of-sale device 62, as shown in decision 178. If confirmation / failure was not received at decision 178, then the process advances to the end at termination 182. Otherwise, if confirmation / failure is received at decision 178, then the data management system (virtual servers 64) discards the second encryption key (K2) and all original user data is deleted from the system, as shown in step 180, and the process ends at termination 182.
[059] It should be appreciated that a person skilled in the art would be able to have different parts of the processes described in the present invention performed by different devices in different locations, either locally or remotely. For example, data can be collected on the user device 46, the data input device 34, or the point of sale 48. Furthermore, the use of keys can be done individually or in multiples, with keys distributed in data blocks for encryption or data integrity verification, as known in the prior art. Petition 870250109332, dated 11 / 28 / 2025, pages 34 / 41
Claims
1 / 8 CLAIMS 1. Encrypted data storage and retrieval system, characterized in that it comprises: a data admission device configured to selectively admit data from a user, the data admission device selectively communicatively connected to a network, the data network device sending and receiving data over the network; and a data management system connected to the network and in selective communication with the data admission device, the data management system in further communication with at least one data storage for the selective storage and retrieval of encrypted data, wherein the data management system is selectively configured to transmit a first encryption key to the data admission device for admission of original user data;wherein the data admission device receives the first encryption key from the data management system and is further configured to: receive a user key from a user; create a second encryption key from the first encryption key and the user key; admit original user data from the user; encrypt the original user data with the second encryption key to create first encrypted user data; transmit the first encrypted user data to the data management system; store the second encryption key on a user device; and delete the second encryption key from the data admission device; wherein the data management system is further configured to: generate a third encryption key;To further encrypt the first encrypted user data with a third encryption key to create a second encrypted user data; and to store the second encrypted user data in a data storage device.
2. System, according to claim 1, characterized in that the data management system is further configured to: create a verification token; embed the verification token with the first encrypted user data before encrypting the encrypted user data with the third encryption key to become second encrypted user data; and store the second encrypted user data with the verification token embedded therein.
3. System according to claim 2, characterized in that the data management system is further configured to: receive a user request for the original user data, the user request including the second encryption key; retrieve the second encrypted user data from the data storage; decrypt the second encrypted biometric user data with the third key, so that the data becomes the first unencrypted user data and the verification token; verify the integrity of the verification token; and decrypt the first encrypted user data with the second encryption key to become the original user data.
4. System according to claim 3, characterized in that the data management system is additionally configured to transmit the original user data to a third-party comparison device over the network.
5. System according to claim 3, characterized in that the data management system is further configured to: retrieve new user data from a point-of-sale device across the network; compare the new user data with the original unencrypted user data to determine a matching status; and transmit the matching status to the point-of-sale device across the network.
6. System according to claim 1, characterized in that the data management system is additionally configured to store second encrypted user data in a data storage across the network.
7. System according to claim 1, characterized in that the data management system is additionally configured to store second encrypted user data in Hyperledger Fabric.
8. System, according to claim 7, characterized in that the data management system is additionally configured to store the second encrypted user data in a public blockchain. Petition 870250089993, dated 10 / 02 / 2025, pp. 106 / 114 4 / 8 9. A method for storing and retrieving encrypted data, characterized in that it comprises the steps of: communicating a request for admission of original data from a data admission device to a biometric data management system, the data admission device selectively connected in a communicable manner to a network, and the data admission device sending and receiving data over the network; transmitting a first encryption key from the data management system to the data admission device, the data management system connected to the network and in selective communication with the data admission device; the data admission device further: receiving the first encryption key from the data management system; receiving a user key from a user; creating a second encryption key from the first encryption key and the user key;admitting, into the data admission device, original user data from the user; encrypting the original user data with the second encryption key to create first encrypted user data; transmitting the first encrypted user data to the data management system; storing the second encryption key on a user device; and deleting the second encryption key from the data admission device; and the data management system additionally: Petition 870250089993, dated 10 / 02 / 2025, pp. 107 / 114 5 / 8 generating a third encryption key; encrypting the first encrypted user data with the third encryption key to create second encrypted user data; and storing the second encrypted user data in a data storage.
10. A method according to claim 9, characterized in that, in the data management system, it additionally: creates a verification token; incorporates the verification token with the first encrypted user data before encrypting the encrypted user data with the third encryption key to become second encrypted user data; and stores the second encrypted user data with the verification token embedded therein.
11. A method according to claim 10, characterized in that, in the data management system, it additionally: receives a user request for the original user data, the user request including the second encryption key; retrieves the second encrypted user data from the data storage; decrypts the second encrypted biometric user data with the third key, so that the data becomes the first unencrypted user data and the verification token; verifies the integrity of the verification token; and decrypts the first encrypted user data with the second encryption key to become the original user data. Petition 870250089993, dated 10 / 02 / 2025, pp. 108 / 114 6 / 8 12. Method, according to claim 11, characterized in that, in the data management system, it additionally transmits the original data to a third-party comparison device over the network.
13. A method according to claim 11, characterized in that, in the data management system, it additionally: retrieves new user data from a point-of-sale device across the network; compares the new user data with the original unencrypted user data to determine a matching status; and transmits the matching status to the point-of-sale device across the network.
14. Method according to claim 9, characterized in that, in the data management system, it additionally stores encrypted second user data in a data storage across the network.
15. Method according to claim 9, characterized in that, in the data management system, it additionally stores second encrypted user data in Hyperledger Fabric.
16. Method, according to claim 15, characterized in that, in the data system, it additionally stores the second encrypted user data in a public blockchain.
17. A system for storing and retrieving encrypted data, characterized in that it comprises: a data admission medium for selectively admitting original user data from a user, the data admission medium selectively and communicatively connected to a network, and the data admission medium for sending and receiving data over the network;Petition 870250089993, dated 10 / 02 / 2025, pp. 109 / 114 7 / 8 a data management medium for managing the storage and retrieval of encrypted data, the data management medium connected to a network and in selective communication with the data admission medium, the data management medium in additional communication with at least one data storage medium for the selective storage and retrieval of encrypted data, wherein the data management medium is additionally configured to transmit a first encryption key to the data admission medium for admission of original user data; wherein the data admission medium is additionally configured to: receive the first encryption key from the data management medium by receiving a user key from a user; create a second encryption key from the first encryption key and the user key;receive original user data from the user; encrypt the original user data with the second encryption key to create first encrypted user data; transmit the first encrypted user data to the data management medium; store the second encryption key on a user device; and delete the second encryption key from the data intake device; and wherein the data management medium is further configured to: generate a third encryption key; encrypt the first encrypted user data with the third encryption key to create second encrypted user data; and store the second encrypted user data on a data storage medium for data storage.
18. System according to claim 17, characterized in that the data management means is further configured to: create a verification token; embed the verification token with the first encrypted user data before encrypting the encrypted user data with the third encryption key to become second encrypted user data; and store the second encrypted user data with the verification token embedded therein.
19. System according to claim 17, characterized in that the data management medium is further configured to: receive a user request for the original user data, the user request including the second encryption key; retrieve the second encrypted user data from the data storage medium; decrypt the second encrypted biometric user data with the third key, so that the data becomes the first unencrypted user data and the verification token; verify the integrity of the verification token; and decrypt the first encrypted user data with the second encryption key to become the original user data.
20. System, according to claim 19, characterized in that the data management medium is additionally configured to transmit the original user data to a third-party comparison medium for comparing new user data with the original user data. Petition 870250089993, dated 10 / 02 / 2025, pp. 111 / 114