Patent ID: 12210598

DETAILED DESCRIPTION

Embodiments of the present disclosure and its advantages are best understood by referring toFIGS.1through6Cof the drawings, like numerals being used for like and corresponding parts of the various drawings.

Users provide information (e.g., name, address, telephone number, email address, social security number, etc.) in a variety of contexts (e.g., mortgage applications, credit card applications, financial account applications, air travel ticket orders, medical office visits, etc.). If this information were exposed to or taken by a malicious user, then the malicious user would be able to use this information to impersonate the users to conduct undesired or unwanted transactions.

In conventional systems, the users have very little control over their information. The users provide their information to a provider to gain access to goods or services from the provider. The provider maintains the information (e.g., on a server). If that server were to be breached by a malicious user, the information would be exposed to the malicious user. Additionally, some providers even sell the information to other providers, often unbeknownst to the users. This sale and movement of the information further exposes the information to malicious users and lessens the control that the users have over such information.

This disclosure contemplates an unconventional system for securing any type of information (e.g., a user's personally identifiable information (PII)). Generally, the system allows the user to store his PII on a personal device, such as a smartphone. When a third party wants to access the user's PII (e.g., to update the PII or to retrieve the PII), a notification will be presented to the user on the personal device seeking consent to the access. The notification may inform the user as to what information is being requested and which entity is requesting the access. The requested access will be denied unless the user consents to the access. In this manner, the user is given control over the dissemination of his PII. Additionally, the system alters or adjusts the PII that is stored in third-party servers so that even if these servers are breached, the user's actual PII is not exposed. The security tool will be described in more detail usingFIGS.1through6F. Although the following embodiments describe a security tool protecting PII, the security tool may be used to secure any type of information.

I. System Overview

FIG.1illustrates an example system100for protecting information (e.g., PII). As seen inFIG.1system100includes one or more devices104, a network106, a data originator108, a database110, a cloud service112, and a token handler114. Generally, system100protects PII by storing a user's102PII in that user's102device104. Access to that PII is denied unless the user102consents to the access.

Devices104interact with other components of system100. Generally, users102use devices104to receive and/or transmit messages to other components of system100. Devices104may store a user's102PII116. User102may use devices104to grant or deny access to PII116. In this manner, user102controls who has access to PII116and when.

Devices104include any appropriate device for communicating with components of system100over network106. For example, devices104may be a telephone, a mobile phone, a computer, a laptop, a tablet, an automated assistant, and/or a cash register. This disclosure contemplates device104being any appropriate device for sending and receiving communications over network106. As an example and not by way of limitation, device104may be a computer, a laptop, a wireless or cellular telephone, an electronic notebook, a personal digital assistant, a tablet, or any other device capable of receiving, processing, storing, and/or communicating information with other components of system100. Device104may also include a user interface, such as a display, a microphone, keypad, or other appropriate terminal equipment usable by user102. In some embodiments, an application executed by device104may perform the functions described herein.

Network106allows communication between and amongst the various components of system100. For example, user102may use devices104to communicate over network106. This disclosure contemplates network106being any suitable network operable to facilitate communication between the components of system100. Network106may include any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. Network106may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network, such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof, operable to facilitate communication between the components.

Data originator108is a third party who may want access to PII116. For example, data originator108may be a credit card company, a medical office, a bank, a brokerage, etc. Data originator108may use PII116to provide and/or apply for goods and services for user102. Generally, when data originator108wants to access PII116, data originator108first seeks approval from user102to access PII116. If user102does not grant access to PII116, then data originator108may not be provided access to PII116. In this manner, it may be more difficult for a malicious user to take PII116from data originator108.

Database110stores information for data originator108. Generally, database110stores tokens representing PII116and/or altered versions of PII116, also referred to as anonymized data. Data originator108can present the tokens and/or the anonymized data to indicate a request for PII116. By storing tokens and/or anonymized data in database110, the security of PII116is improved because a malicious user can only take tokens and anonymized data, rather than PII116, from data originator108and/or database110.

Cloud service112operates a storage system accessible through network106. Generally, cloud service112can be used to store anonymized data and/or encrypted versions of PII116. Various components of system100such as devices104, data originator108, and/or token handler114may access cloud service112to move information to and from other components of system100.

Token handler114facilitates access to PII116. As seen inFIG.1, token handler114includes a processor118and a memory120. This disclosure contemplates processor118and memory120being configured to perform any of the functions of token handler114described herein.

Processor118is any electronic circuitry, including, but not limited to microprocessors, application specific integrated circuits (ASIC), application specific instruction set processor (ASIP), and/or state machines, that communicatively couples to memory120and controls the operation of token handler114. Processor118may be 8-bit, 16-bit, 32-bit, 64-bit or of any other suitable architecture. Processor118may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components. Processor118may include other hardware that operates software to control and process information. Processor118executes software stored on memory to perform any of the functions described herein. Processor118controls the operation and administration of token handler114by processing information received from devices104, network106, and memory120. Processor118may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding. Processor118is not limited to a single processing device and may encompass multiple processing devices.

Memory120may store, either permanently or temporarily, data, operational software, or other information for processor118. Memory120may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory120may include random access memory (RAM), read only memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. The software represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, the software may be embodied in memory120, a disk, a CD, or a flash drive. In particular embodiments, the software may include an application executable by processor118to perform one or more of the functions described herein.

Generally, token handler114processes requests to store and/or access PII116. If user102consents to such storage and/or access, token handler114facilitates the movement of PII116through system100. The information communicated in system100may be encrypted. The various components of system100(e.g., device104, data originator108, and/or token handler114) may store or may be provided the public encryption keys of the other components such that each component of system100can encrypt messages intended for the other components of system100. In certain embodiments, a component of system100receives the public encryption key of another component in response to a request for the public encryption key of that component. For example, data originator108and/or device104may request and receive the public encryption key of token handler114. As another example, token handler114and device104may request and receive the public encryption key of data originator108. The operation of system100will be described in more detail usingFIGS.2A through6C.

II. Initial Device Registration

FIGS.2A and2Bshow an example of initial device registration in system100ofFIG.1. Generally, user102registers device104to gain access to the various components of system100. The registration process creates an account for user102and allows token handler114to recognize user102and device104in the future.

FIG.2Ashows an example device104registration in system100. As seen inFIG.2A, device104includes a processor202and a memory204. This disclosure contemplates processor202and memory204being configured to perform any of the functions of device104described herein. Generally, device104registers with token handler114by providing particular information about user102to token handler114.

Processor202is any electronic circuitry, including, but not limited to microprocessors, application specific integrated circuits (ASIC), application specific instruction set processor (ASIP), and/or state machines, that communicatively couples to memory204and controls the operation of device104. Processor202may be 8-bit, 16-bit, 32-bit, 64-bit or of any other suitable architecture. Processor202may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components. Processor202may include other hardware that operates software to control and process information. Processor202executes software stored on memory to perform any of the functions described herein. Processor202controls the operation and administration of device104by processing information received from devices104, network106, and memory204. Processor202may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding. Processor202is not limited to a single processing device and may encompass multiple processing devices.

Memory204may store, either permanently or temporarily, data, operational software, or other information for processor202. Memory204may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory204may include random access memory (RAM), read only memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. The software represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, the software may be embodied in memory204, a disk, a CD, or a flash drive. In particular embodiments, the software may include an application executable by processor202to perform one or more of the functions described herein.

User102installs application206to device104. For example, user102may download application206to device104and then install application206. After installing application206, device104may execute application206to perform any of the functions of device104described herein. For example, memory204may store application206and processor202may retrieve application206from memory204and execute application206.

When user102launches application206for the first time, user102may provide information to application206to register. For example, user102may provide a username and/or passphrase208that authenticates user102. User102may also provide other information during the registration process such as, for example, a phone number210and an email address212. Device104uses this information to generate a salted passphrase214specific to user102. For example, device104may hash passphrase208with phone number210and email address212to generate salted passphrase214.

During the registration process device104may also generate a key pair for user102. The key pair includes the public key216and the private key218for device104. Public key216may be shared with other components of system100so that these components can encrypt information intended for device104. Device104uses private key218to decrypt information encrypted using public key216. Device104continues the registration process by communicating salted passphrase214and public key216to token handler114. When token handler114receives the salted passphrase214and public key216, token handler114may understand that user102is attempting to register. Token handler114uses salted passphrase214and public key216to generate additional information that will be used in the future to protect the PII116of user102.

Token handler114generates a key pair for token handler114using public key216. The key pair for token handler114includes public key220and private key222. Public key220may be used by components of system100to encrypt messages intended for token handler114. Token handler114uses private key222to decrypt information encrypted using public key220. In some embodiments, public key220and private key222may be generated independent of public key216. Thus, token handler114generates public key220and private key222without using public key216. In this disclosure, when a public keypair is referenced, an asymmetric key can be substituted, or a symmetric key protected by an asymmetric keypair (e.g., a public key encodes a symmetric key) can be used.

In some embodiments, device104may encrypt passphrase208and other personal information (e.g., phone number210and email address212) using public key220and send the encrypted information to token handler114. Token handler114then hashes the encrypted information to generate salted passphrase214. Token handler114then stores salted passphrase214in a table (e.g., device registration table228).

Token handler114may generate a user ID226for user102. In some instances, user102may have created user ID226and provided user ID226to token handler114. User ID226may be an identifier for user102.

Token handler114creates a repository224that stores information for user102. For example, repository224may store tokens, anonymized data, and/or certain types of PII116for user102. Token handler114may generate a repository name232for repository224.

Token handler114adds certain information to a device registration table228to identify future requests from or to user102. For example, token handler114may add public key220, repository name232, user ID226, and a hash of salted passphrase214to device registration table228. In certain embodiments, token handler114salts a provided passphrase encrypted with a public key of the token hander114in an authentication request. The token handler114constructs the salted passphrase and performs the hash, then looks for an entry matching this hash in its tables. If such an entry is found, the user is authenticated. Any of this information may be used as an index into device registration table228to locate any of the other information. For example, if public key220is provided, token handler114may retrieve user ID226and salted passphrase214from device registration table228.

After token handler114has added the user's102information to device registration table228, token handler114communicates certain information back to device104. In the illustrated example ofFIG.2A, token handler114communicates a consent object230, repository name232, public key220, and user ID226. When device104receives this information, device104may consider that registration was successful. Device104may store this information for future use.

After device104receives information from token handler114device104may create a local repository234. Device104may maintain repository234to store PII116of user102. In some embodiments, device104may encrypt PII116using public key220and a key derived from salted passphrase214before storing PII116in repository234. In this manner, even if a malicious user were to gain access to device104, the malicious user will not be able to access PII116without getting token handler114and user102to decrypt PII114.

In certain embodiments, device104may push repository234to cloud service112. In this manner, a copy of repository234may be maintained and accessed over network106. As a result, even if repository234and device104were to become corrupted, a correct copy of repository234may be retrieved from cloud service112.

In some embodiments, user102may lock out an account if user102believes that the account has been compromised. User102may use device104or a web portal to request that the account of user102be locked out. In response, token handler114may lock out the account of user102so that future requests to access PII116of user102are rejected. In this manner, even if all of the security features provided by system100are breached by a malicious user, user102may still lock out the account as a final fail safe.

FIG.2Billustrates a method240of registering a device104. Generally, device104and token handler114perform the steps of method240. By performing method240device104may be registered to system100.

In step242, device104installs application206. Device104then provides passphrase208, phone number210, and email address212in step244. Device104generates salted passphrase214in step246. In some embodiments, device104generates salted passphrase214by combining and hashing passphrase208, phone number210, and email address212. In step248, device104generates public key216and private key218. Device104then communicates salted passphrase214and public key216to token handler114.

When token handler114receives hashed salted passphrase214and public key216, token handler114may understand that device104is attempting to register. In another embodiment, device104may pass salted passphrase214to token handler114, allowing token handler114to hash salted passphrase214. In step250, token handler114generates public key220and private key222. In some embodiments, token handler114generates public key220and/or private key222based on public key216. Token handler114generates user ID226in step252. In some embodiments, token handler114may receive user ID226from user102and/or device104rather than generating user ID226. In step254, token handler114creates repository224. Token handler114then adds user ID226, public key220, repository name232, and hashed, salted passphrase214to device registration table228. Token handler114communicates consent object230, repository name232, public key220, and user ID226to device104.

When device104receives consent object230, repository name232, public key220, and user ID226, device104may understand that registration has been successful. In step260, device104creates local repository234. Device104may store consent object230, public key220, and user ID226in local repository234in step262. Device104may then request PII116from user102. As user102provides PII116, device104may store that PII116in repository234. In some embodiments device104may first encrypt PII116using public key220and a key derived from salted passphrase214before storing in repository234.

Modifications, additions, or omissions may be made to method240depicted inFIG.2B. Method240may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method240.

III. Storing and Updating PII

FIGS.3A-3Gshow examples of storing and updating PII using system100.FIGS.3A and3Bshow user102using device104to store or update PII in system100.FIGS.3C-3Eshow data originator108storing or updating PII in system100.FIGS.3F and3Gshow token handler114storing or updating certain portions of PII. Generally, system100stores PII in device104after user102gives consent, and system100provides a token and/or anonymized data to other components (e.g., data originator108). In this manner, user102controls access to the PII using device104, and a malicious user can take only tokens and/or anonymized data from the other components of system100.

A. Storing and Updating PII with a User Device

FIG.3Ashows the storing and/or updating of PII116using device104in system100. Generally, user102can create or update PII116using device104. Device104can store PII116for future redemption. Token handler114generates anonymized data for PII116that can be maintained by third parties and used by third parties in the future to redeem PII116. In this manner, user102and device104control access to PII116.

Device104receives PII116from user102. User102may have created new PII116and inputted PII116into device104. User102may have updated existing PII116by inputting PII116into device104. Device104then encrypts PII116using public key220of token handler114to create payload302. In some embodiments, device104may store PII116that has been encrypted using public key220for future redemption. Device104communicates payload302to token handler114to generate anonymized data and/or a token. Token handler114receives payload302from device104. Token handler114may decrypt payload302with private key222of token handler114.

In some embodiments, after encrypting PII116using public key220, device104encrypts PII116using a key derived from salted passphrase214to create payload302, which is PII116encrypted by public key220and then salted passphrase214. In other words, payload302is a doubly encrypted version of PII116. In this manner, even if a malicious user were to access a private encryption key of token handler114and to intercept payload302, the malicious user would not be able to fully decrypt payload302to access PII116without salted passphrase214. Additionally, if the malicious user were to access device104, the malicious user would not be able to decrypt payload302without salted passphrase214. Device104then writes payload302to the repository234. The repository234changes would then be replicated in the cloud112. This would bypass the data authenticity mechanism, and the device104would request an additional step to generate tokens309and anonymized data304.

Token handler114generates one or more tokens309that represent stored information (e.g., PII116, anonymized data304, and/or ledger ID308). A token309may indicate certain characteristics associated with the stored information. For example, token309may govern the entities that are allowed to access the information. As another example, token309may govern when access may be granted to and/or the manner in which access is provided to the information. As yet another example, token309may indicate where the information is stored (e.g., on device104, on a server, and/or in the cloud) and/or for how long token309is valid and/or how many times the token can be redeemed, or how many times it can be redeemed during a prescribed interval of time. As yet another example, tokens309may specify how long redeemed data may reside in token handler's114cache memory. Tokens309may be provided to different components of system100and/or different users so that these components and users can later redeem and/or access the information (e.g., PII116) by presenting token309. Token309further protects the information because even if a malicious user were to access token309, the malicious user would not be able to determine or derive the information from token309. Additionally, user102may prevent access to the information by deleting or instructing the deletion of token309from system100. In this manner, if token309is subsequently presented for redemption, token handler114may prevent access to the information.

In particular embodiments, token309may indicate the logging requirements as token309and/or PII116is moved through system100. For example, token309may indicate that logging should be performed each time token309and/or PII116is stored and/or redeemed. The resulting logs may be stored and/or redeemed in the same way that PII116is stored and/or redeemed, as described herein. The logging will allow user102and system administrators to track which entities have performed which operations using token309and/or PII116. The logs may not reveal the actual PII116, thus protecting the user's102information. Additionally, by putting control of access to the log in the user's102hands, a reduction in log data volume and storage needs may result. Furthermore, by storing the log on device104where data is co-located, log searches may be performed by device104rather than by other components of system100, thus reducing processing and I/O bandwidth relative to conventional server-side logging techniques.

In certain embodiments, token handler114generates anonymized data304representing PII116. Token handler114may generate anonymized data304in any suitable manner. For example, token handler114may pre-generate a table of unique, suitable values and allocate and map values from the table to PII116to produce anonymized data304. Importantly, if a malicious user were to take anonymized data304, the malicious user would not be able to glean PII116from anonymized data304. In some instances, the malicious user may even believe that anonymized data304is PII116, because anonymized data304may have the same format as PII116. Importantly, anonymized data304is not a transformation of PII116. In other words, it is not possible to determine or derive PII116from anonymized data304(e.g., by decrypting anonymized data304or by applying a reverse function to anonymized data304).

As an example, if PII116were a social security number of user102, token handler114may generate anonymized data304by generating a table of random social security numbers and allocating one of them in response to a request to generate an anonymized social security number. In this manner, anonymized data304still appears to be a social security number but is not a social security number of user102. As another example, if PII116is the name of user102, anonymized data304may use a sequence of random character values of PII116. As a result anonymized data304may be a random string of characters. In both examples, if a malicious user were to access anonymized data304, the malicious user would not be able to glean the user's social security number or name from anonymized data304.

Token handler114stores anonymized data304in a ledger306. Ledger306is identified by a ledger ID308. Token handler114may have generated ledger ID308if ledger306was also newly generated. In this manner, anonymized data304and ledger ID308uniquely identify PII116. As discussed further below, when token handler114is presented with anonymized data304and ledger ID308, token handler will be able to determine that PII116and/or token309is being requested. Token handler114communicates anonymized data304and ledger ID308to other components of system100, such as for example, device104and data originator108so that these components can later redeem PII116by presenting anonymized data304and ledger ID308.

Device104receives token309and/or anonymized data304and ledger ID308from token handler114. Device104stores token309and/or anonymized data304and ledger ID308in repository234. In some embodiments, device104may further push repository234to cloud service112for storage on a cloud. As a result of this operation, device104stores a local copy of token309and/or anonymized data304and ledger ID308. Additionally, device104stores a local copy of PII116encrypted using public key220.

In some embodiments, device104may not store or maintain a local copy of PII116, token309, anonymized data304, and/or ledger ID308. Rather, device104stores this information on a server or in a cloud. In other words, device104may store payload302, token309, anonymized data304, and/or ledger ID308in repository234. Device104may then push repository234to the cloud or to a remote server for storage. Device104may then delete or erase local copies of PII116, token309, payload302, anonymized data304, and/or ledge ID308. In this manner, this information may not be compromised if device104is taken by a malicious user.

As discussed previously, system100is not limited to the storage and/or updating of personally identifiable information. Rather, any type of information may be handled by system100to protect that information. For example, confidential information of a business or enterprise (e.g., database credentials) may be protected using system100. Token309and/or anonymized data304and ledger ID308that correspond to the confidential information may be generated and stored in a similar manner that PII116is secured by system100(e.g., as described inFIGS.3A-3G).

In some embodiments, token handler114further encrypts PII116with certain information (e.g., an identifier for user102, an identifier for token handler114, and/or an identifier for data originator108) and stores the encrypted PII116for subsequent validation of PII116during redemption. For example, token handler114may store the encrypted PII116in a Merkle tree. During redemption, if requested PII116is provided using device104in response to a redemption request, token handler114can first verify the provided PII116by comparing it against the encrypted PII116stored in the Merkle tree. Token handler114may decrypt the encrypted PII116and then compare the two versions of PII116to see if the provided PII116has been altered. In this manner, even if user102decides to maliciously alter the provided PII116, token handler114can detect and prevent that altered PII116from being provided.

FIG.3Bshows an example method310for storing and/or updating PII116using device104. By performing method310, device104is given control over access to PII116. Device104receives PII116in step312. User102may have inputted PII116into device104. The user102may be creating PII116and/or updating PII116in device104. In step314, device104encrypts PII116with public key220to create a payload302. In some embodiments, device104further encrypts PII116with a key based on salted passphrase214to form payload302. In this manner, payload302is a doubly encrypted version of PII116. Device104then communicates payload302to token handler114.

Token handler114decrypts payload302with private key222of token handler114to produce PII116. Token handler114generates token309that represents PII116in step317. In step318, token handler114generates anonymized data304for PII data116. Token handler114may generate anonymized data304by generating random character sequences (for names) or nine digit numbers (for social security numbers), for example. In this manner, anonymized data304may resemble the format of PII116, but not have the actual values of PII116. As a result, a malicious user who gains access to anonymized data304will not be able to glean PII116from anonymized data304. In some embodiments, token handler114scrambles PII116or generates a random string of characters and/or symbols to generate anonymized data304.

In step320, token handler114stores anonymized data304in a ledger306. Ledger306may be identified by ledger ID308. In the event that token handler114generated ledger306to store anonymized data304, token handler114may also generate ledger ID308that identifies ledger306. Token handler114then communicates token309and/or anonymized data304and ledger ID308to other components of system100, such as device104.

Device104may store token309and/or anonymized data304corresponding ledger ID308. As a result, device104may store a local copy of token309, anonymized data304, ledger ID308, and PII116encrypted using public key220.

Modifications, additions, or omissions may be made to method310depicted inFIG.3B. Method310may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method310.

B. Storing and Updating PII with a Data Originator

FIG.3Cshows the creation and/or updating of PII116by a third party, such as data originator108. Data originator108may be any entity separate from user102and token handler114. For example, data originator108may be an entity that provides a good or service to user102after user102has provided PII116. Data originator108may be a medical office, financial institution, etc. Data originator108may include a number of agents that interact with user102and/or device104. As seen inFIG.3C, data originator108may include a processor326and a memory328. Processor326and memory328may be configured to perform any of the functions of data originator108and/or its agents described herein.

Processor326is any electronic circuitry, including, but not limited to microprocessors, application specific integrated circuits (ASIC), application specific instruction set processor (ASIP), and/or state machines, that communicatively couples to memory328and controls the operation of data originator108. Processor326may be 8-bit, 16-bit, 32-bit, 64-bit or of any other suitable architecture. Processor326may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components. Processor326may include other hardware that operates software to control and process information. Processor326executes software stored on memory to perform any of the functions described herein. Processor326controls the operation and administration of data originator108by processing information received from devices104, network106, and memory328. Processor326may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding. Processor326is not limited to a single processing device and may encompass multiple processing devices.

Memory328may store, either permanently or temporarily, data, operational software, or other information for processor326. Memory328may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory328may include random access memory (RAM), read only memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. The software represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, the software may be embodied in memory328, a disk, a CD, or a flash drive. In particular embodiments, the software may include an application executable by processor326to perform one or more of the functions described herein.

Data originator108receives PII116from user102and/or device104. User102may have provided PII116to data originator108so that data originator108can provide a good or service to user102. For example, if data originator108is a medical office, user102may have provided a name and/or address to the medical office to receive medical treatment. If data originator is a financial institution, user102may have provided PII116such as a name, address, and social security number to open an account with the financial institution.

After receiving PII116, data originator108does not store PII116permanently. Rather, data originator108prepares PII116for handling by token handler114. Data originator108encrypts PII116using public key220of token handler114to create payload330. Data originator108then communicates payload330to token handler114. In this manner, data originator108does not store PII116, which improves the security of PII116. For example, a malicious user will not be able to access PII116through data originator108.

Token handler114receives payload330from data originator108. Payload330may also include an identifier of data originator108(DO ID332). Payload330may also include a consent ID334. Payload330may also include information about user102. Token handler114uses that information to index into device registration table228to determine the user102corresponding to PII116. For example, token handler114may retrieve a user ID226from device registration table228using that information. Token handler114may also decrypt payload330using private key222of token handler114to access PII116(e.g., to generate token309and/or anonymized data304).

Token handler114implements a polling system by which other components of system100may be notified of pending tasks. In other words, when token handler114needs device104and/or data originator108to perform a particular task, token handler114does not initiate contact with data originator108or device104. Rather, token handler114waits for device104or data originator108to establish a connection with token handler114before token handler114informs device104or data originator108of any pending tasks. It is the responsibility of device104and data originator108to periodically establish a connection with token handler114to check if there are any pending tasks. In this manner, even if a malicious user were to acquire contact information for device104and/or data originator108, the malicious user would not be able to spoof or impersonate token handler114and initiate contact with device104or data originator108and hijack device104and data originator108. As a result, the security of device104and data originator108is improved.

Generally, token handler114uses one or more queues (e.g., instruction queue340and status queue342) to manage the polling process. When device104and data originator108establish a connection with token handler114, device104and data originator108check particular queues to determine any pending tasks and performs any of the pending tasks that token handler114wants device104and data originator108to perform. As seen inFIG.3C, token handler114maintains an instruction queue340and a status queue342. Token handler114uses these queues to let device104and/or data originator108know of pending tasks.

Token handler114generates a payload336using information from payload330and device registration table228. Payload336indicates a request to store PII116. Token handler114may also generate a request ID338that identifies the request to store PII116. Token handler114may also use consent ID334to look up a token creation template and include it in the payload336. The token creation template may include a description of what data will be written, a description of who may retrieve PII116, and a description of the purposes for which PII116may be used. Token handler114inserts payload336into instruction queue340to inform other components of system100that the storage of PII116is requested. Token handler114may also update a status of the request in status queue342to requested or pending. Token handler114communicates request ID338to other components of system100such as data originator108so that those components can check on the status of the pending storage task. In this manner, components of system100, such as data originator108, may reference request ID338through a connection with token handler114to check the status of the pending storage task. For example, if data originator108sees that the status of a request corresponding to request ID338in status queue342is pending, then data originator108may determine that the request is still pending and wait.

After inserting payload336into instruction queue340, token handler114waits for device104to establish a connection with token handler114. As discussed above, device104establishes a connection with token handler114periodically according to the polling scheme. When device104establishes a connection with token handler114, device104may see that payload336is waiting for device104in instruction queue340. Token handler114may update the status of the request in status queue342to pending or in contact.

In response to seeing payload336in instruction queue340, device104retrieves payload336from instruction queue340. Device104generates a notification346that seeks consent from user102to allow the storage task from data originator108. Notification346may include or be generated from anonymized data304included in payload336. Notification346may include or be generated from consent language included in payload336. Device104may generate notification346using the information in payload336such as, for example, the data originator ID332, the user ID226, and the consent ID334. Device104may then present notification346to user102such as, for example, through a display. User102can give consent or deny consent. If user102denies consent, then device104and/or token handler114may reject the pending storage task. Token handler114may then update the status of the request in status queue342to rejected.

If user102gives consent for the pending storage task, then device104encrypts portions of payload336using salted passphrase214(or a key based on salted passphrase214) to produce payload348. In other words, payload348includes a doubly encrypted version of PII116that has been first encrypted using public key220and then encrypted using salted passphrase214. Device104then stores payload348in repository234. Before committing portions of payload348to repository234, device104may include an encryption schedule describing what steps must be undertaken to decrypt portions of payload348. Device104may further push repository234to cloud service112.

Additionally, if user102gives consent, device104communicates a request349to token handler114indicating a request to generate token309and/or anonymized data304. Request349may include a token creation template extracted from payload348. Token handler114receives request349from device104and generates token309and/or anonymized data304in response. Token handler114then stores anonymized data304in ledger306. As discussed previously, token handler114may generate or use ledger ID308to identify ledger306. Token handler114may then store token309and/or anonymized data304and ledger ID308in a database or memory120(e.g., a cache of memory120) for subsequent retrieval. Token handler114then updates the status of the storage request in status queue342to ready. In some embodiments, token handler114may store token309and/or anonymized data304and ledger ID308in status queue342. As discussed previously, token309may indicate the access privileges and the manner and time in which the stored information is to be accessed.

Data originator108may poll token handler114to check the status of the pending storage task. When data originator108sees that the status is ready, data originator108may determine that the storage task is ready or complete. Data originator108may then retrieve token309and/or anonymized data304and ledger ID308from token handler114(e.g., from memory120or status queue342). Data originator108may then store token309and/or anonymized data304and ledger ID308into database110for future use. For example, data originator108may present token309and/or anonymized data304and ledger ID308to token handler114, to retrieve PII116in the future. In this manner, device104controls the storage of PII116in system100.

In certain instances, token handler114may also initiate communication with other components of system100(e.g., device104and data originator108) rather than waiting for these components to initiate communication with token handler114through the polling system. For example, token handler114may initiate communication when a request is urgent or in emergency situations. As another example, token handler114may initiate communication when token handler114knows that the component is ready and expecting a communication from token handler114(e.g., when the component has already initiated data storage or redemption).

FIGS.3D and3Eshows a method350for storing PII116using data originator108. Generally, when data originator108wants to store PII116, device104should first give consent to the storage. If consent is given, anonymized data304and/or token309is generated using PII116and provided to data originator108.

In step352, data originator108receives PII116. A user102may have used device104to provide PII116. As another example, a user102may have provided PII116directly to data originator108. Data originator108encrypts PII116with public key220of token handler114in step354. Data originator108then creates payload330using the encrypted PII116in step356. Payload330may also include identifying information for data originator108and user102. Payload may also include a consent ID230. Data originator108communicates payload330to token handler114.

Token handler114receives payload330and retrieves a user ID226from a device registration table228using the information in payload330in step358. Token handler114then validates the data originator in step360. Validation may involve (1) authenticating the device of data originator108(2-way TLS) and retrieving registration data for data originator108, (2) retrieving a consent object230and determining if data originator108has permission to use consent object230, and (3) confirming that data originator108has sufficient privileges and authorization to store PII116of user102for subsequent retrieval or use as specified by consent object230. User102may have previously provided such authorization. User102may also approve storage of some, all, or none of PII116. Token handler114then creates payload336in step362. Payload336may indicate the pending storage task. Token handler114inserts payload336into instruction queue340in step364. Token handler114then waits for device104to establish a connection with token handler114.

In step366, device104establishes a connection with token handler314. Device104may see that payload336is in instruction queue340indicating a pending request to store PII116. Device104then retrieves payload336from token handler114. In step368, device104presents notification346seeking consent to store PII116. Token handler114may update the status of the storage task in status queue342to pending in step370. In step372, device104receives consent from user102to store PII116. Device104encrypts payload336using salted passphrase214to produce payload348in step374. Device104then communicates request349to token handler114. Device104may also write payload348to repository234in step376. In certain embodiments, device104generates an unsigned token and adds the unsigned token to request349. In some embodiments, user102may select which portions of PII116will be referenced by token309.

Token handler114generates and/or signs token309representing portions of PII116in step379. In step380, token handler114generates anonymized data304representing PII116. In some embodiments, token handler114generates a random string of characters and/or symbols to form anonymized data304. In step382, token handler114stores anonymized data304in ledger306. Ledger306may be identified using ledger ID308. In step384, token handler114updates status queue342to indicate that the data is ready.

Token handler114then waits for data originator108to establish a connection with token handler114. When data originator108establishes a connection with token handler114, data originator108may see that the status of the storage task is ready. In response, data originator108retrieves token309and/or anonymized data304and ledger ID308from token handler114. In step386, data originator108stores token309and/or anonymized data304and ledger ID308to database110for future use.

In some embodiments, token handler114may push data to data originator108using, for example, a webhook called by the token handler114when token309and/or anonymized data304and ledger ID308are ready.

When device104establishes a connection with token handler114, device104may retrieve token309and/or anonymized data304and ledger ID308from token handler114. In step388, device104stores pseudo-anonymized data304and ledger ID388for future use.

In this manner, user102and device104are given control over when PII116may be stored or updated. As a result, a malicious user will not be able to create fake PII116for user102because user102would not provide consent in response to notification346generated for storing the fake PII116.

Modifications, additions, or omissions may be made to method350depicted inFIGS.3D and3E. Method350may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method350.

C. Storing, Updating, and Redeeming Permanent Data

FIG.3Fshows token handler114handling permanent data. Permanent data is a type of PII that is governed by particular laws and/or regulations. Typically, these laws or regulations may require that access be given to certain types of PII for certain purposes. To comply with these laws or regulations, token handler114would grant access to these types of PII without receiving consent from a user102. Generally, token handler114identifies these types of PII and stores encrypted versions of this PII in a cloud so that token handler114can access this PII without first being granted permission by a user102. In certain embodiments, token handler114may still seek consent from user102before accessing this PII, but in the event that the user102does not give consent, token handler114may still access the PII to comply with the laws or regulations.

Token handler114receives payload330. As discussed above, payload330may include PII116that has been encrypted using public key220of token handler114. Data originator108may have provided payload330to token handler114. Token handler114decrypts payload330using private key222of token handler114to produce PII116.

PII116may include certain types of PII116that are governed by laws or regulations. For example, these laws or regulations may require that access be given to PII116even without user consent. Token handler114may identify portions390of PII116that are governed by these laws or regulations. Token handler114may encrypt these portions390using a public key392of data originator108and then a public key220of token handler114to form a payload394. As a result, portion390is doubly encrypted using keys of data originator108and token handler114. Token handler114then stores payload394in a cloud for future retrieval and use. Because portion390has been encrypted using the keys of token handler114and data originator108, token handler114and data originator108may decrypt portion390without intervention from device104.

When data originator108requests the portion390of PII116(e.g., by communicating a request for portion390to token handler114), token handler114may retrieve payload394from the cloud and decrypt payload394using private key222of token handler114to produce portion390encrypted using public key392of data originator108. Token handler may then communicate portion390encrypted using public key392of data originator108to data originator108. Data originator108may then decrypt, using a private key of data originator108, portion390encrypted using public key392to produce portion390. In this manner, data originator108can retrieve portion390even without user consent.

In some embodiments, token handler114still gives user102an opportunity to consent to the retrieval of portion390. If user102consents, then the regular redemption of PII116can occur, as described below. If user102does not consent, then token handler114may provide portion390to data originator108using the process discussed above.

FIG.3Gshows an example method396for storing permanent data. In certain embodiments, token handler114performs method396. By performing method396, token handler114stores PII116that is governed by laws or regulations requiring access without consent.

In step396A, token handler114receives payload330. Token handler114decrypts payload330with private key222to produce PII116in step396B. In step396C, token handler114identifies a portion390of PII116that is governed by laws or regulations. These laws or regulations may require that access be given to portions390without user consent.

In step396D, token handler114encrypts portion390with public key392of data originator108, and then public key220of token handler114to produce a payload394. Token handler114then stores payload394in the cloud in step396E. Token handler114may also store payload394on the user's102device104. In this manner, the data repository in the cloud112can remain consistent with the data repository234on the user's102device104.

Modifications, additions, or omissions may be made to method396depicted inFIG.3G. Method396may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method396.

IV. Redeeming PII

FIGS.4A and4Bshow an example of redeeming PII116in system100. Generally, data originator108presents a token309and/or anonymized data304to indicate a request to obtain or use the PII116. After user102consents to the request, token handler114performs a series of steps so that data originator108can receive the PII116or allow a third party to provide a service with the PII116. In this manner, user102controls access to the PII116.

FIG.4Ashows redemption of PII116in system100. The process begins when token handler114receives token309and/or anonymized data304and ledger ID308, indicating a request to redeem PII116. As discussed previously, token309and anonymized data304and ledger ID308may uniquely identify PII116. In addition, token309identifies data originator108and user102. Data originator108may have retrieved token309and/or anonymized data304and ledger ID308from database110. Data originator108communicates token309and/or anonymized data304and ledger ID308to token handler114to indicate a request to redeem PII116. In some embodiments, the process begins with device104communicating token309and/or anonymized data304and ledger ID308to data originator108and/or directly to token handler114. For example, data originator108may have asked user102to provide PII116, and in response, user102uses device104to communicate token309and/or anonymized data304and ledger308to data originator108and/or token handler114.

Token handler114receives token309and/or anonymized data304and ledger ID308. Token handler114generates a payload402using token309and/or anonymized data304and ledger ID308. Payload402indicates a request to redeem PII116corresponding to token309and/or anonymized data304and ledger ID308. Token handler114inserts payload402into instruction queue340. Token handler114may then wait for device104to poll token handler114.

In certain embodiments, token handler114validates token309to determine whether data originator108is allowed to access PII116before further requesting consent from device104. Token309is signed with a signature created with a private key222of token handler114, and in this way, may guarantee that token309has not been altered by data originator108or a malicious user. Also, token309may designate data originator108as the legitimate user of token309. Further, token309designates how PII116can be accessed or used. For example, token309may stipulate that PII116must be presented to another server rather than being made available to data originator108.

While anonymized data304may map to token309, token309may reference additional PII data elements for which data originator108did not supply a corresponding anonymized data item. Token handler114may exclude a missing data item from payload402to indicate to device104that the missing data item is not to be redeemed. In this manner, token handler114prevents device104from being presented with illegitimate redemption requests in the event that a malicious user accesses token309and/or anonymized data304and/or ledger ID308, and further restricts data originator108from gaining access to data outside the purview of data originator108, in the event that tokens are shared by multiple data originators. By designating data originator108as the legitimate user of token309, token handler114prevents another user from intercepting or accessing and redeeming a token issued for use by data originator108.

In some embodiments, data originator108presents token309and not anonymized data304and ledger ID308to request access to PII116. Token handler114identifies from token309the PII116that is being requested. Token handler114may further refer to token309to determine whether certain security checks have passed (e.g., whether token309indicates that data originator108may request PII116at this time or in a particular manner or for a particular purpose by including, for example, a redirect URL for another service to receive PII116). Token handler114performs the series of steps described below to redeem or provide PII116to data originator108.

In some embodiments, data originator108presents anonymized data304and ledger ID308instead of token309. Token handler114identifies from anonymized data304and ledger ID308a token309that corresponds to anonymized data304and ledger ID308. Token handler114then identifies from token309that PII116is being requested. Token handler114may further refer to token309to determine whether certain security checks have passed (e.g., whether token309indicates that data originator108may request PII116at this time or in a particular manner). Token handler114performs the series of steps described below to redeem or provide PII116to data originator108or provide PII116to another service.

As discussed previously, device104periodically polls token handler114to see if there are any pending tasks waiting for device104. When device104establishes a connection with token handler114, device104may see payload402in instruction queue340and in response, determine that token handler114has received token309and/or anonymized data304and ledger ID308, indicating a request to redeem PII116. Token handler114may update a status for the request to redeem PII116in status queue342to pending. When device104sees payload402in pending queue340, device104generates and presents notification404to user102. Notification404requests consent from user102to redeem PII116. User102may consent to revealing to or allowing data originator108to use all, some, or none of the PII116described in notification404. If user102does not consent to reveal to or allow use of any portions of PII116to data originator108, then the request to redeem PII116is denied and the status for the request to redeem PII116in status queue342is updated to denied.

If the user102consents, then device104retrieves payload302. As described previously, payload302represents PII116encrypted using public key220of token handler114and then an encryption key derived from salted passphrase214of user102. Device104may have retrieved payload302from the cloud, a server, or from a local repository234. If payload302is stored on the cloud or a server, then device104effectively acts as a consent mechanism for gaining access to some or all of PII116.

In some embodiments, consent to store and/or redeem PII116(or to perform any other task) may be required from and given by entities other than user102. For example, token309may indicate other users102or other entities that need to provide consent before certain tasks (e.g., logging, redeeming, storing) can be performed. If these tasks are requested, token handler114may seek consent from these other users102or entities. Consent may be provided on devices of those other users102or entities. Consent may also be provided if those other users102or entities provide to token handler114tokens309that were generated for those users102and/or entities. When the required consent has been given, token handler114may commence the task.

Device104retrieves encrypted data from payload302according to the wishes of the user. Device104decrypts payload302using salted passphrase214. Device104then encrypts the resulting payload302using public key392of data originator108to create payload406. In other words, payload406represents PII116encrypted using public key220of token handler114and then public key392of data originator108. Device104communicates payload406to token handler114. In certain embodiments, token handler114may have retrieved public key392based on token309and/or anonymized data304and ledger ID308. Token handler then communicates public key392to device104. In some embodiments, device104decrypts payload302using salted passphrase214to produce PII116encrypted using public key220of token handler114. Token handler114then applies encryption using public key392of data originator108to produce payload406.

In some embodiments, token309may specify that data originator108receive certain items of anonymized data from payload302in place of corresponding data items from PII116. Thus, payload409may include real data from PII116intermixed with portions of anonymized data304.

Token handler114receives payload406from device104. Token handler114stores payload406in memory120(e.g., in a cache of memory120) and updates the status of the request for PII116in status queue342to ready. Token handler114may then wait for data originator108to poll token handler114. In some embodiments, token handler114may store payload406in status queue342. When data originator108establishes a connection with token handler114, data originator108may see the status of the request in status queue342is ready indicating that the request to redeem has been approved and is ready. Data originator108may retrieve payload406from memory120or status queue342of token handler114. Data originator108then decrypts payload406using private key408of data originator108to generate payload410. Payload410may represent PII116encrypted using public key220of token handler114. Data originator108then communicates payload410to token handler114.

In some embodiments, when token handler114receives payload406from device104, token handler114calls an internal or external service indicated in token309and stores the result of this service call in memory120. When data originator108establishes a connection with token handler114, data originator108may see the status of the request in status queue342indicating that the request to the internal or external services has completed and results or response, if any, are ready.

If the token309specifies that PII116should be made available to data originator108, token handler114decrypts payload410using private key222of token handler114to produce PII116. Token handler114then provides PII116to data originator108. In certain embodiments, token handler114may provide PII116to data originator108by encrypting PII116using public key392of data originator108and then communicating the encrypted PII116to data originator108. In this manner, data originator108is provided PII116after user102consents to the redemption of PII116.

In certain embodiments, when token handler114receives payload410from device104, it decrypts payload410with a private key222of the token handler114and encrypts payload410with a public key392of data originator108and places it into a cache and notifies data originator108that payload410is ready. In certain embodiments, token handler114encrypts payload410a second time with public key220of token handler114before placing PII116twice encrypted into the cache. Data originator108then requests PII116from the cache, and in response token handler114decrypts PII116, now encrypted with only a public key392of the data originator108, and presents it to data originator108.

In certain embodiments, token309is redeemed to accomplish tasks other than redeeming PII116. For example, token309may be redeemed for another token309that is associated with different privileges and rights. Data originator108and/or device104may communicate token309to token handler114along with a request412. Request412may indicate the type of task that is being requested (e.g., redeem PII116, store PII116, generate new token309, etc.). If request412indicates that a new token309is to be generated, token handler114may determine the features of the new token309based on other information within request412. For example, request412may indicate the changes between token309and new token309. In response, token handler114may insert request412and/or token309into instruction queue340. When device104notices that request412and/or token309is in instruction queue340, device104may request consent from user102for the generation of new token309. When consent is given, token handler114may generate new token309that includes the changes to token309and update the status of request412in status queue342. Device104and/or data originator108may retrieve new token309from token handler114in response to the updated status of request412in status queue342. The ability to request generation of new token309may allow access rights and/or privileges to be altered without altering or accessing PII116or any other sensitive information of user102. For example, user102may change information such as access rights, membership subscription, and/or logging requirements without having other components of system100accessing PII116or other sensitive information of user102.

FIG.4Bshows a method420for redeeming PII116in system100. Generally, PII116is redeemed after user102consents to the redemption of PII116.

Token handler114receives token309and/or anonymized data304and ledger ID308in step422. Token handler114may have received token309and/or anonymized data304and ledger ID308from data originator108. In some embodiments, token handler114received token309and/or anonymized data304and ledger ID308from device104. For example, data originator108may have asked user102to provide PII116. In response, device104communicates token309and/or anonymized data304and ledger ID308to token handler114.

Token handler114generates payload402in step424. Payload402may be generated using token309and/or anonymized data304and ledger ID308. Token handler114inserts payload402into instruction queue340in step426. Token handler114then waits for device104to poll token handler114.

In step428, device104establishes a connection with token handler114. Token handler114then updates status queue342to pending in step430. Device104may establish a connection with token handler114and determine that payload402is in instruction queue340indicating a request for PII116. Device104generates notification404in step432to seek consent from user102to the redemption of PII116. Device104receives consent in step434. In response, device104decrypts payload302with salted passphrase214and then encrypts with public key392of data originator108to produce payload406in step436. Device104communicates payload406to token handler114. In some embodiments, device104decrypts payload302with salted passphrase214and then communicates the result to token hander114. Token handler114then encrypts using public key392of data originator108to produce payload406.

Token handler114updates status queue342to ready and stores payload406in step438. Token handler114then waits for data originator108to poll token handler114. After data originator108establishes a connection with token handler114, data originator108determines that the status of the request in status queue342is ready and retrieves payload406from token handler114. Data originator108then decrypts payload406with private key408of data originator108to produce payload410in step440. Data originator108then communicates payload410to token handler114. Token handler114then decrypts payload410using private key222of token handler114to produce PII116in step442. Token handler114then provides PII116to data originator108. For example, token handler114may encrypt PII116using public key392of data originator108and communicate the result to data originator108. As another example, token handler114may request that data originator108call a dispatch who can provide PII116over the telephone. As yet another example, token handler114may communicate the result (e.g., an encrypted telephone number of user102) to another service, such as a telephone carrier, to allow data originator108to contact user102.

Modifications, additions, or omissions may be made to method420depicted inFIG.4B. Method420may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method420.

V. Subsequent Device Registration

FIGS.5A and5Bshow an example of subsequent device registration. Generally, user102can register additional devices104into system100. Each registered device104is given a copy of the repository234.

FIG.5Ashows an example of subsequent device registration in system100. As seen inFIG.5A, user102maintains two devices104A and104B. Device104A has been previously registered with system100. User102is attempting to register the second device104B in the example ofFIG.5A.

User102downloads application206to device104B. User102may then install application206to device104B. When device104B executes application206, user102may provide account credentials to application206. For example, user102may provide passphrase208and/or user ID226. Device104B then generates a public key502and a private key504for device104B. Device104B communicates public key502to token handler114.

Token handler114receives public key502from device104B. Token handler114then generates public key506and private key508for token handler114based on public key502. Token handler114then adds information about device104B to device registration table228. In this manner, device registration table228may associate device104B with user102. Device registration table228thus shows that user102is associated with two devices:104A and104B.

Token handler114then initiates the process for duplicating repository234onto device104B. In some embodiments, cloud service112maintains a copy of repository234. In these embodiments, device104B downloads a copy of repository234from cloud service112. In some embodiments cloud service112does not maintain a copy of repository234. In these embodiments, token handler114and/or device104A uploads a temporary copy of repository234to cloud service112. Device104B then downloads a copy of repository234from cloud service112. After the download is complete, device104B and/or token handler114deletes the copy of the repository234from cloud service112. In this manner device104B, is registered to system100and user102may use device104A or device104B to interact with other components of system100.

FIG.5Bshows an example method510for registering subsequent devices104in system100. In step512, device104installs application206. Device104then receives passphrase208in step514. In step516, device104generates public and private keys502and504. Device104then communicates public key502to token handler114. Token handler114generates public and private keys506and508in step518. Token handler114then retrieves information for user102from a device registration table228in step520. Token handler114determines whether a cloud image of repository234exists in step522. If the cloud image does not exist, token handler114asks device104to upload a temporary cloud repository in step524. In step526, device104downloads repository234from the cloud. In step528, token handler114deletes the temporary repository234in the cloud if it was determined in step522that no cloud image of the repository234existed. In some embodiments, device104deletes the temporary repository234in the cloud after downloading temporary repository234.

Modifications, additions, or omissions may be made to method510depicted inFIG.5B. Method510may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method510.

VI. Key Management

FIGS.6A-6Cshow an example key management scheme in system100. Generally, token handler114uses a set of keys to encrypt PII such that different keys are used to encrypt different portion of the PII. In this manner, even if a malicious user takes a key, the malicious user would not be able to decrypt all of the PII. Additionally, token handler114generates new set of keys periodically and also deletes old sets of keys periodically. As a result, even if a malicious user takes a key, the usefulness of that key is time limited.

FIG.6Ashows an example of the key management scheme. As seen inFIG.6A, token handler114generates and maintains multiple sets of keys602. In the example ofFIG.6A, token handler114has generated and maintained a first set of keys602A, a second set of keys602B, and a third set of keys602C. Token handler114may have generated each set of keys602at different times. For example, token handler114may generate a new set of keys602every month. In the first month, token handler114generated set602A. In the second month, token handler114generated set602B. In the third month, token handler114generated set602C. Token handler114communicates these sets602of keys to other components of system100, such as device104and data originator108.

These components use keys606from the set602to encrypt PII116. These components then send the encrypted PII116to token handler114. In certain embodiments, these components use different keys606to encrypt different portions of PII116. In the example ofFIG.6A, the components encrypt first portion604of PII116using public key606A. The components encrypt second portion608of PII116using a second public key606B. Public keys606A and606B belong to the same set602. For example, public key606A and606B may belong to set602A. Portions604and608may be different attributes of PII116. For example, first portion604may be an email address and second portion608may be a social security number. By encrypting different portions604and608of PII116using different keys606, the impact of a key606being taken by a malicious user is reduced. For example, if public key606A or its corresponding private key were taken by a malicious user, the malicious user would not be able to access second portion608of PII116using those keys. In certain embodiments, the components of system100, such as data originator108and device104, randomly select keys606from the most current set602of keys to encrypt information. In this manner, it may be more difficult for a malicious user to determine which key606was used to encrypt a piece of information.

Token handler114adds to an encryption schedule610information about which keys606were used to encrypt the various portions604and608of PII116. In the example ofFIG.6A, encryption schedule610shows that first portion604was encrypted using public key606A and second portion608was encrypted using public key606B. Token handler114may refer to encryption schedule610when PII116is requested to determine the keys606that were used to encrypt the various portions604and608of PII116. Token handler114may then select the correct corresponding key to decrypt first portion604and second portion608. Token handler114may communicate encryption schedule610to other components of system100, such as device104and data originator108, so that these components can refer to the encryption schedule610to determine which keys were used to encrypt certain information. For example, token handler114may communicate encryption schedule610to device104and/or data originator108when device104and/or data originator108establish a connection with token handler114. In some embodiments, token handler114communicates one or more applicable keys606to a requesting component of system100rather than communicating encryption schedule610to these components. In other words, token handler114determines which keys606are applicable in response to a request and communicates those keys606to the requesting component. In this manner, the requesting component is not tasked with maintaining the encryption schedule610and with determining the applicable keys.

Token handler receives token309and/or anonymized data304and ledger ID308, which indicates a request to redeem PII116. As a result token handler114refers to encryption schedule610to determine how to decrypt the various portions of PII116. In the example ofFIG.6A, token handler114determines that first portion604of PII116was encrypted using public key606A. As a result, token handler114uses private keys612A that corresponds to public key606A to decrypt first portion604of PII116. Token handler114determines from the encryption schedule610that second portion608of PII116was encrypted using public key606B. In response, token handler114uses private key612B which corresponds to public key606B to decrypt second portion608of PII116.

Token handler114may maintain a key vault611that stores the various keys606and612used to encrypt and/or decrypt information. Alternatively, token handler114may use an external or third-party key management system, referencing and caching keys stored in that system. Each key in key vault611is identified by an ordinal. The key vault611also maintains the key value for each ordinal. By referring to key vault611and specific ordinals, token handler114may retrieve the keys that are used to encrypt and decrypt PII116. In some embodiments, the ordinals identify references to keys. The references may be used to identify keys stored in key vault611. If a malicious user were to gain access to the ordinals, the malicious user would need to map the ordinals to their appropriate references and then use the references to access the keys in key vault611. Thus, an additional layer of security is added by using ordinals and references. In certain embodiments, token handler114determines whether the age of a set602of keys exceeds a threshold based on the ordinals of the keys in that set602. For example, if each set602includes ten keys, then ordinals1through10belong to a first set602and ordinals11through20belong to a second set602. The second set602would have been generated a time period after the first set602. When the ordinals indicate that the set602is older than another threshold, that set602can be deleted. In some embodiments, token handler114also identifies keys based on their ordinals. For example, encryption schedule610may identify which key was used to encrypt certain information using the ordinals of those keys.

In certain embodiments, token handler114generates a new set602of keys periodically. For example, token handler114may generate set602A in the first month, set602B in the second month, and set602C in the third month. When token handler114generates a new set602of keys, token handler114may use keys from that set602to encrypt information moving forward until another set602of keys is generated. Token handler may use set602A to encrypt information until the age of set602A exceeds a threshold (e.g., one month). When the age of set602A exceeds one month, token handler114may generate set602B and begin using set602B to encrypt information. When the age of set602B exceeds one month, token handler114may generate set602C and begin using set602C to encrypt information.

In some embodiments, token handler114re-encrypts previously encrypted information (e.g., first portion604and second portion608) when a new set of keys is generated. For example, if public keys606A and606B were in first set602A, then when token handler114generates set602B, token handler114may use public keys in set602B to re-encrypt first portion604and second portion608. In this manner, the encryption of the first portion604and the second portion608are kept up-to-date. In certain embodiments, token handler114may first verify that first portion604and second portion608are unchanged or untampered before re-encrypting using the newly generated set of keys. In this manner, the generation of a new set of keys does not present an opportunity for a malicious actor to change the PII116.

For example, when device104connects to token handler114to request instructions (e.g., from instruction queue340), token handler114may provide device104with an ordinal. Device104may then compare that ordinal with stored ordinals to determine if any of the stored ordinals are expired or outdated. For example, if the provided ordinal is greater than a stored ordinal, then the stored ordinal may be expired or outdated. Device104may then initiate an operation that is equivalent to a data redemption and then a data push for data that corresponds to a key for the expired or outdated ordinal. This operation may be handled at a lower priority by token handler114, which may result in the data being re-encrypted with keys from the latest key windows. The re-encrypted data may then be stored on device104with ordinals for the latest encryption keys. This operation may include the steps: (1) device104uses the active passphrase208to partially decrypt the data; (2) device104passes the partially decrypted data as a payload to the special key rotation queue; the payload includes the old encryption schedule and the new one; (3) token handler114removes the payload from queue; (4) token handler114decrypts the data with the corresponding old token handler114private key(s); (5) if the data is permanent data, then the data is supplied to data originator108for decryption and re-encryption with a new key; (6) token handler114encrypts the data with a new key from the current window; (7) token handler114removes the old encryption schedule from the payload and places the resulting payload into instruction queue340for device104; (8) when connected and executing instructions, device104re-encrypts and stores the data and new encryption schedule. In one embodiment, data is processed one data push payload or redemption schedule at a time. In some embodiments, many push payloads are processed at once.

In one embodiment, system100takes a lazy approach to re-encrypting the data. Device104does not proactively determine which data should be encrypted and initiate data re-encryption. Instead, when a data redemption request comes in, device104compares the ordinals in the encryption schedule with the ordinal provided by token handler114. If the provided ordinal is greater than a corresponding ordinal in the encryption schedule, then a data push request is placed into instruction queue340, causing the data to be re-encrypted. If the ordinals in the current encryption schedule correspond to keys that have been deleted, then system100returns an error. In some embodiments, the data on device104encrypted with out-of-date keys is destroyed, making it impossible for an attacker to decrypt data using captured keys, thus further enhancing the security of system100.

In certain embodiments, data re-encryption also occurs when user102changes passphrases208. The user's102passphrases208are also represented by ordinals. In one embodiment, the user's102old passphrase208is encrypted with the new passphrase208and stored into the user's102repository. Device104submits requests for all obsolete data to be re-encrypted with the new passphrase208. A marker instruction is added to instruction queue340. When device104reaches this instruction, it marks the old passphrase208“obsolete”; thereafter, redemption requests for data encrypted with the old passphrase208are rejected. In one embodiment, such invalid requests are detected by, and rejected at, device104; in another embodiment, device104communicates the ordinal of the current passphrase208to token handler114, and token handler114rejects invalid data redemptions before they reach device104. In one embodiment, when all data has been re-encrypted with the new passphrase208, the obsolete passphrase208encrypted with the new passphrase208is deleted and/or all data encrypted with the old passphrase208is deleted, making it impossible to find data encrypted with a captured passphrase208and further enhancing the security of system100.

In some embodiments, token handler114deletes sets602of keys when the age of the set602exceeds a predetermined threshold. For example, token handler114may delete a set602of keys after six months. In this manner if a malicious user were to take keys or a set602of keys, the usefulness of those keys would be time limited. For example, if token handler114receives a request to redeem PII116that was encrypted using a key that has been deleted due to age, token handler114may know to reject that request. Using the previous example, token handler114may keep set602A until the age of set602A exceeds a threshold (e.g., six months). When the age of set602A exceeds six months, token handler114may delete set602A. Similarly, when the age of sets602B and/or602C exceeds six months, token handler114may delete sets602B and/or602C.

If the security of data originator108or token handler114is compromised, after the attacker is barred from further access to system100, token handler114or data originator108can generate a new key or key flight, and the provided ordinal can be set to this new value or to the origin of the key flight. In this way, even if an attacker gains access to data originator108or token handler114and captures private encryption keys, data cannot be redeemed using the captured encryption keys, thus enhancing the security of system100.

FIG.6Bshows an example method620of managing keys in system100. In step622, token handler114generates a set602of keys. Token handler114then communicates that set602of keys to data originator108. Data originator108may use keys from that set602of keys to encrypt PII116in step624. For example, data originator108may encrypt a first portion604of PII116using a first public key606A and a second portion608of PII116using a second public key606B to create a payload. Data originator108may communicate the payload to token handler114.

Token handler114receives the payload from data originator108and adds encryption information to an encryption schedule610in step626. The encryption schedule610may indicate that first portion604was encrypted using public key606A and that second portion608was encrypted using public key606B.

Data originator108then communicates token309and/or anonymized data304and ledger ID306to token handler114indicating a request to redeem PII116. Token handler114selects first and second private keys612A and612B in step628. Token handler114may have selected first and second private keys612A and612B based on the information in the encryption schedule610. Token handler114decrypts first portion604of PII116using first private key612A in step630. Token handler114decrypts second portion608of PII116using second private key612B in step632.

Modifications, additions, or omissions may be made to method620depicted inFIG.6B. Method620may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method620.

FIG.6Cshows an example method640of managing keys in system100. In certain embodiments, token handler114performs method640. In step642, token handler114determines that an age of a set602of keys exceeds a first predetermined time threshold. In step644, token handler114generates a new set of keys602. For example, the first predetermined time threshold may have been one month. In response to determining that the set602of keys was generated over a month ago, token handler114regenerates the new set602of keys.

In step646, token handler114encrypts data using the new set602of keys. Token handler114then determines that an age of the set602of keys exceeds a second predetermined time threshold in step648. A second predetermined time threshold may be a longer period, such as, for example, six months. In step650, token handler114deletes the set602of keys. In this manner, it is no longer possible for token handler114to encrypt or decrypt information using the set602of keys. In step652, token handler114receives token309and/or anonymized data304and a ledger ID308indicating a request for data encrypted using the set602of keys.

Token handler114rejects the request in step654because the set602of keys has been deleted. In this manner, token handler114improves the security of PII116because even if a malicious user were to take a set602of keys, the usefulness of that set602of key was time limited.

Modifications, additions, or omissions may be made to method640depicted inFIG.6C. Method640may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. Any suitable component of system100may perform one or more steps of the method640.

Generally, system100provides several advantages over conventional security systems, as discussed above. For example, when PII116is to be stored or updated, system100first seeks consent from user102for the PII116store or update. If the user102grants consent, then the system100stores the PII116in the user's102personal device104or updates the PII116stored in the user's personal device104, then generates a data access token309and anonymized data304mapped to the data access token309. If the anonymized data304were to be captured by a malicious user, it would not be possible for the malicious user to determine the user's102actual PII116from the anonymized data304. Similarly, if the malicious user were to capture a data access token309, it would not be possible for the malicious user to determine the user's102actual PII116from the token309. If the system100or the user102learn that a malicious user has captured a data access token309, and/or wish to block access to PII116by means of the anonymized data304, the token309can be removed from the token handler114, guaranteeing that the PII116can no longer be accessed using the specific anonymized data304, while allowing other anonymized data304mapped to other data access tokens309continued access to the PII116.

If an undetected malicious user penetrates the token handler114and captures a private key222of the token handler114, the malicious user will not be able to decrypt the data without also learning the user's102passphrase and the data used to salt the passphrase and to encrypt the information. Alternatively, a malicious user who has gained access to the token handler114may try simulating a request to redeem the user's102data and obtaining the user's102explicit consent. If the request doesn't match similar requests, the user102has reason to withhold this consent, allowing the user102a means to thwart a malicious user from accessing their data. Similarly, if the malicious user gains control of the user's102device104and attempts to decrypt the information from the device104, the malicious user will fail without the user's102salted passphrase214and the token handler114private key222. If the malicious user attempts to trigger a redemption flow from the device104, the malicious user runs the risk of detection by either the user102or the token handler114, resulting in lockdown of the account. Additionally, use restrictions placed on tokens309, such as a token309can only be used one time, or limited number of times, or may be used a limited number of times in a specific interval of time, allow the token handler114to mark a user's102account with an “at-risk” status, causing the token handler114to automatically reject requests to redeem data. In these ways, the security of the PII116is improved over conventional systems.

Although the present disclosure includes several embodiments, a myriad of changes, variations, alterations, transformations, and modifications may be suggested to one skilled in the art, and it is intended that the present disclosure encompass such changes, variations, alterations, transformations, and modifications as fall within the scope of the appended claims.