Secure identity and profile management system

Abstract

A system for storing and managing secure information is disclosed, the system comprising a secure identity and records management system that acts as an intermediary between a user and an entity requesting personally identifiable information (PII) from the user. The system collects the PII from the user and securely stores the PII in encrypted form, for example in an alternative blockchain. The location of the PII within the alternative blockchain can be indexed using a smart contract in a main blockchain, which can be read only by an access token generated and provisioned by the user's mobile device. When an entity requests PII that has been collected and securely stored from the user, the user can provide the access token to provide permission to release the PII. The system will use the access token to locate the location storing the PII and release the PII to the requesting entity.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2017 / 059929, international application date November 3, 2017, Chinese national phase application number 201780096567.5, entitled "Secure Identity and Record Management System". Technical Field

[0002] The methods and systems disclosed herein generally relate to the secure storage, management, and retrieval of data. More specifically, the methods and systems disclosed herein relate to systems for managing the storage of personally identifiable information (PII) using blockchain technology to map and retrieve said information for allocation to requesting entities. Background Technology

[0003] In today's technological environment, users can interact with entities (or more specifically, computer systems associated with entities) that request personally identifiable information (PII) associated with them. For example, an entity may request certain key pieces of information from a user in order to execute an exchange or transaction between the entity and the user. Such transactions can include the exchange of specific resources, goods, services, financial instruments, access (e.g., access to secure resources or areas), and so on.

[0004] In many cases, a user may be requested to provide a Personal Information I (PII), such as the user's address, social security number, etc. For example, the entity could be a financial entity like a bank, and the transaction could be a user applying for a loan. In this example, the user would be requested to provide a PII, which the bank can use to make decisions about the loan (e.g., by using the PII to find the user's credit score).

[0005] Therefore, a user executing multiple transactions over time could result in the PII being provided to multiple entities associated with those transactions. This can lead to repetitive work, where the user repeatedly provides the same PII to different entities. To prevent this, a system can be implemented that stores the PII associated with the user and is capable of sharing the PII across multiple entities.

[0006] For example, a user can initiate loan applications with both the First Bank and the Second Bank to compare loan interest rates across banks. The system storing the user's PII (e.g., address, Social Security number, etc.) can share the PII with both the First Bank and the Second Bank, so the user will not need to manually enter and provide the PII to both banks.

[0007] However, this system faces several challenges related to data security. Different entities may require different subsets of user PIIs. Care must be taken to provide only the minimum number of required user PIIs to each entity and to ensure that each entity is authorized to receive user PIIs. Furthermore, the system should store each user's PII securely to prevent or mitigate the release of PIIs in the event of a system attack. Summary of the Invention

[0008] In some embodiments of this disclosure, a system and method are contemplated in which an identity and profiling system receives a request for a first set of information associated with a user from a physical computing system. The identity and profiling system may send the request for the first set of information associated with the user to a mobile device operated by the user. The identity and profiling system may receive an access token from the mobile device and determine a key associated with the user, the key being used to decrypt the access token to obtain a second set of information associated with the user. The identity and profiling system may determine at least one storage location for a third set of information associated with the user from the main blockchain, and then the identity and profiling system may locate the third set of information associated with the user off-chain based on the at least one storage location. Once the third set of information associated with the user is located and retrieved, the third set of information can be sent to the physical computing system.

[0009] In some embodiments, the first set of information associated with a user may correspond to a set of personally identifiable information (PIIs) of the user requested from the entity computing system. For example, the entity computing system may require the user's address and Social Security number for transaction or function execution. Therefore, the first set of information in this instance would be the user's address and Social Security number. In some embodiments, the second set of information associated with a user may correspond to a set of PIIs that the user is authorizing to be published to the requesting entity computing system. Generally, the second set of information would be an indication of the authorized PIIs, rather than the actual underlying value of the PIIs. For example, in the aforementioned instance, the user could grant permission to publish their address but not their Social Security number. Therefore, the second set of information in this instance would be an indication of the user's address data field, rather than the user's actual address. In some embodiments, the third set of information associated with a user may also correspond to a set of PIIs that the user is authorizing to be published to the requesting entity computing system. However, the third set of information would typically be the actual underlying value of the PIIs (e.g., stored off-chain). For example, in the aforementioned instance, the third set of information would be the user's address.

[0010] In various embodiments, off-chain can be a decentralized data storage area or an alternative blockchain. In various embodiments, a smart contract on the main blockchain indicates at least one storage location for a third set of information associated with the user. In various embodiments, the identity and profile management system can take steps to determine if the phone number of a mobile device associated with the user exists within the identity and profile management system.

[0011] In various embodiments, the identity and profile management system may take steps to determine that the phone number of a mobile device associated with a user does not exist within the identity and profile management system. Upon determining that the phone number of a mobile device associated with a user does not exist within the identity and profile management system, a request may be sent to the user's mobile device to provide a first set of information associated with the user. In various embodiments, the identity and profile management system may assign a key associated with the user to the mobile device. In some embodiments, the key associated with the user may be a shared secret (e.g., a symmetric encryption key), or an IPS public key in an IPS public / private key pair used to decrypt transmissions from the mobile device. In some embodiments, the IPS public / private key pair may be specifically associated with the user, and a public / private key pair may be generated for each user in the IPS system. In such embodiments, the IPS public key in the IPS public / private key pair may generally not be available to the public or other users, but is known only to the specific user to whom the public / private key pair is assigned. After registration, the identity and profile management system may receive the first set of information associated with the user from the mobile device and store the first set of information associated with the user off-chain. The identity and profile management system may store at least one storage location of the first set of information associated with the user in the main blockchain.

[0012] In some embodiments of this disclosure, systems and methods are contemplated in which a mobile device receives a request from an identity and profile management system to provide a first set of information associated with a user of the mobile device to a requesting entity. The mobile device may generate a user interface that allows the user to authorize the provision of the first set of information associated with the user to the requesting entity. Once the user authorizes, the mobile device may generate a second set of information associated with the user (e.g., based on granted permissions). The mobile device may retrieve a key associated with the user and generate an access token by encrypting the second set of information associated with the user using the key. Finally, the mobile device may send the access token to the identity and profile management system.

[0013] In various embodiments, the second set of information associated with the user is an access control bitmap. In various embodiments, the mobile device includes a keystore manager for storing keys associated with the user. In various embodiments, the mobile device may take steps to determine an entity identifier associated with the requesting entity from the request. The mobile device may use the entity identifier to authenticate the requesting entity by verifying the entity identifier (e.g., in conjunction with a certificate authority). Attached Figure Description

[0014] Figure 1 This diagram illustrates a system for storing and managing security information, including a secure identity and file management system, according to embodiments of the present disclosure.

[0015] Figure 2 A system diagram illustrating a client system and an identity and profile management system according to embodiments of the present disclosure is provided.

[0016] Figure 3 This document describes a flowchart illustrating an embodiment of the present disclosure for registering a user with an identity and profile management system.

[0017] Figure 4 This document describes a flowchart illustrating an embodiment of the present disclosure for collecting PII from a user through an identity and profile management system.

[0018] Figure 5 This document describes a flowchart illustrating an embodiment of the present disclosure for publishing a user's PII through an identity and profile management system. Detailed Implementation

[0019] introduction

[0020] Users often provide varying amounts of sensitive information, such as personally identifiable information (PII), to multiple different entities (e.g., for the purpose of conducting transactions). It is inconvenient for users to manually enter this requested information each time (e.g., via a user interface on a mobile device).

[0021] To prevent users from having to manually enter the information each time, the user's information can be stored (e.g., by the system) and retrieved later when needed. However, implementations involving storing the PII through at least one entity raise problems. Specifically, entities do not trust each other by default. This prevents the sharing of stored PIIs between entities unless the user is able to provide explicit permission to share it in some way.

[0022] Furthermore, there are security concerns associated with storing user PIIs at a single entity (e.g., a centralized location) or even across multiple entities (e.g., at multiple different locations). Specifically, any user PII stored through an entity is vulnerable to hacking and security breaches. In such a scenario, the entity owns the user PII, and the user is at risk of those entities being hacked; if any of those entities is compromised, any user PII stored through those entities will be exposed. Moreover, storing user PIIs at an entity allows the entity to look up and access user data at any time, even if the user is unaware of it and has not granted the entity permission to access that information.

[0023] This disclosure relates to mitigating these problems by storing user PIIs in a location gated or facilitated by a neutral third party (e.g., a centralized or decentralized data store). However, this third party does not actually own the user PIIs; each user continues to "own" any information associated with them. The third party is only used to retrieve the relevant user PIIs from the data store and, upon receiving user permissions, publishes said information to the requesting entity. In other words, all users' PIIs become part of the user profile and are hidden from all entities, but can also be made available to entities based on demand and user permissions. For example, an entity can request access and can be granted access to retrieve some users' PIIs from a decentralized data store.

[0024] Furthermore, a data structure can be used to store the user's PII, preventing the information from being used to identify a specific user even if the data storage area and / or third party are hacked. As a result, the system allows the user to easily and seamlessly provide their PII to multiple entities associated with those transactions over time through multiple transactions. This prevents users from having to manually enter their PII and provide it to each entity, while also improving data security by reducing the chance of the user's PII falling into unauthorized hands.

[0025] Terms and Definitions

[0026] Before discussing the details of some embodiments of the present invention, the description of some terms may help to understand the various embodiments.

[0027] A “transaction” can include any exchange or interaction between two or more users and / or entities. A transaction can include the exchange of resources, goods, services, financial instruments, access (e.g., access to a secure resource or area), and so on. In some embodiments, a transaction may require a user to provide certain personally identifiable information (PII) necessary for the transaction. For example, an instance of a transaction is a loan application (e.g., where a financial entity, such as a bank, intends to provide a loan to a user, and the user is applying for a loan), which may require the user to provide certain PIIs necessary to establish the loan (e.g., a bank account number used to pay the loan amount). Another instance of a financial transaction could be a user applying for a credit card or bank account. An example of a non-financial transaction could be a user seeking healthcare treatment, which may require the user to provide certain PIIs (e.g., protected health information or PHI) to obtain treatment.

[0028] "Personally identifiable information (PII)" can refer to any data item associated with a user that can be used (e.g., alone or in combination with other data items) to identify a particular user. Examples of PII include a user's address, date of birth, social security number, bank account number, bank account balance, current salary, assets, outstanding loans, driving history, and so on.

[0029] "User" can refer to any individual who can participate in a transaction as a party. In some cases, a user may have a mobile device that can be used to communicate with an identity and profile management system to grant permission to publish the user's PII to the requesting entity. In some embodiments, an individual user may be a direct customer of financial services provided by a financial entity. In some embodiments, an individual user may be a direct customer of healthcare services provided by a healthcare institution.

[0030] An "entity" can refer to any counterparty to a user in a transaction. An entity can offer a user resources, goods, services, financial instruments, access (e.g., access to secure resources or areas), and so on. An entity may include or be associated with a computing system that electronically processes transactions. An entity may seek access to certain personally identifiable information (PII) or security profile data that the user may consent to providing. Examples of entities include financial entities with which a user interacts to perform financial operations, such as opening an account (e.g., a bank account), applying for a loan, updating personal information, and so on. Other examples of entities include insurance companies and healthcare entities, such as hospitals, healthcare providers, and so on.

[0031] A “blockchain” can be a distributed database used to maintain a growing list of records called blocks. In some implementations, each block contains a timestamp and a link to the previous block. Blockchains are typically managed by a peer-to-peer network that collectively adheres to protocols for verifying new blocks. Once recorded, data in any given block cannot be reversed without altering all subsequent blocks and colluding across the network. This allows the blockchain to act as a verifiable and permanent record of data between parties. Blockchain platforms utilizing smart contracts can be used in conjunction with Identity and Profile Management Services (IPS) to store the location of secure information (user PII), which itself can be stored on off-chain storage devices (e.g., another blockchain or a secure distributed data store). Blockchains can be propagated across multiple nodes (e.g., in a distributed computing system).

[0032] A "smart contract" can be a computer protocol designed to facilitate, verify, or enforce the negotiation or performance of a contract. The smart contract may include the technical features of a blockchain, consisting of local storage, code, and virtual currency. The local storage of the smart contract can be used to store the location of the user's PII and security profile information and to retrieve that information based on an access token.

[0033] A “node” can refer to any suitable one or more data computing devices, which typically include a processor and memory for running applications such as blockchain clients. In some embodiments, a node may have the task of updating and maintaining the blockchain.

[0034] "Identity and Profile Management Service (IPS)" can refer to a central hub of a middleware stack that intermediates between individual users (e.g., their mobile devices) and entities, and also interacts with an authorized blockchain platform that stores users' secure personal information. IPS helps manage users' secure identity and profile data by granting users permission to locate and retrieve their personal information for publication to requesting entities. In some cases, users may possess mobile devices that can be used to communicate with the IPS to grant permission to publish the user's PII to requesting entities.

[0035] An "entity identifier" can refer to any suitable data that can be used to identify an entity. In some embodiments, an entity identifier may include a public key certificate used to identify / verify the entity. An entity identifier can be used as input to construct a secure access token.

[0036] An "access control bitmap" can refer to a digital object or file that provides a mapping indicating which data items in a user's stored PII are published to the requesting entity (e.g., the mapping could indicate a user's profile attribute ID). For example, when a user is providing a PII directly to an entity, all of this information can be associated with field / attribute names (e.g., "client name" for the user's legal name). These attribute names requested by the entity can be sent to the user via a request, so the user can see what type of information is being requested. Once the user authorizes the publication of the information, the attribute names can be converted into a bitmap. In some cases, the bitmap can have 128 bits used individually as switches. For example, each bit can be set to '0' or '1', and if a bit is set to '1', the attribute associated with that bit is requested from the user. It should be noted that the bitmap can be used as input for constructing access tokens.

[0037] An "access token" can include any suitable data that can be used to grant access to certain information. The access token can refer to a digital object, file, or token constructed using a combination of a user's private key certificate, an entity identifier, and an access control bitmap. For example, the access control bitmap can be encrypted using a shared secret based on the user's private key and / or entity identifier. For example, the shared secret can be an entity identifier encrypted with the user's private key. The shared secret can then be transmitted to the IPS using a session key or a protocol such as the Diffie-Hellman protocol. The IPS can use the shared secret to decrypt the access token. This token is transferred between the user's device and the IPS. The access token can be used to indicate a variety of situations: (1) the user has specifically granted permission to access data and said permission is not from anyone else (since the shared secret is unique to the user and the entity and can be verified by the user's public key corresponding to the user's private key); and (2) only the requesting entity will receive the data, and no other entity (because no one else would have the entity's identifier). The access token is constructed on the user's mobile device (e.g., on the client side).

[0038] "Processor" can refer to any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to perform the desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0039] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transitory computer-readable media whose storage can be executed by a processor to implement desired methods. Instances of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0040] An "application" can be computer code or other data stored on a computer-readable medium (e.g., a memory element or a secure element) that can be executed by a processor to perform a task.

[0041] Schematic

[0042] Figure 1 This diagram illustrates a system for storing and managing security information, including a secure identity and file management system, according to embodiments of the present disclosure.

[0043] In various embodiments, one or more users 102 may exist, including user 1 through user N. User 102 may operate mobile devices 104 (e.g., smartphones), including device 1 through device N. Each user may have their own mobile device through which the user communicates with the identity and record management system 120. Therefore, users 102 collectively operate mobile devices 104 to communicate with the identity and record management system 120.

[0044] In some embodiments, the identity and profile management system 120 may communicate with one or more entities 110, including entities 1 through N. These various entities 110 may be counterparties to interactions or transactions with user 102. For example, user 1 may interact with entity 1, which requests certain information from user 1 to continue the interaction.

[0045] In some embodiments, the identity and profile management system 120 may act as a communication intermediary between user 102 and entity 110. For example, if entity 1 requests certain information (e.g., personally identifiable information, or PII) from user 1 in order to continue the interaction, the identity and profile management system 120 may send the request to the mobile device (e.g., device 1) used by user 1.

[0046] In some embodiments, the identity and record management system 120 can also be used to collect, store, and manage any PII from user 102. For example, if user 1 receives a request from entity 1 for certain information associated with user 1 that has not yet been collected by the identity and record management system 120, the identity and record management system 120 can receive said information from user 1. The identity and record management system 120 can then store user 1's PII in user PII storage device 130.

[0047] In some embodiments, the user PII storage device 130 may be a centralized or decentralized data storage area for storing user PIIs. User PIIs may be cataloged in the user PII storage device 130 for later retrieval by the identity and profile management system 120. For example, if entity 1 requests certain information from user 1 for the first time, user 1 may provide the information to the identity and profile management system 120 to be stored in the user PII storage device 130. If entity 2 later requests the information from user 1, user 1 may provide the identity and profile management system 120 with permissions to retrieve the information from the user PII storage device 130 and publish the information to entity 2.

[0048] In some embodiments, the user PII storage device 130 may be implemented using a combination of a main blockchain 132 and an off-chain blockchain 134. In some embodiments, the off-chain blockchain 134 may refer to an alternative blockchain branched off from the main blockchain 132, while in other embodiments, the off-chain blockchain 134 may be any form of secure decentralized data storage (e.g., distributed across one or more nodes in a cloud computing cluster). In some embodiments, the identity and profile management system 120 may manage the security information (user PII) by storing it in the off-chain blockchain 134. For example, the off-chain blockchain 134 may be an alternative blockchain and the user's PII may be stored across various blocks of the off-chain blockchain 134. The off-chain blockchain 134 may store the user's PII without storing any information about the user associated with the PII. Thus, the user's PII can be 'anonymized' by being broken down and distributed across various blocks. For example, this could result in a block containing only the user's current salary, which itself is not sufficient information to identify which user the data is associated with. In such embodiments, transaction identifiers or other data may be used to link different types of data that extend across the various blocks.

[0049] In some embodiments, the main blockchain 132 can be used to store the user's PII at various locations off-chain 134. In some embodiments, the main blockchain 132 can be implemented on a blockchain platform using smart contracts, and the location data of the user's PII can be stored on the smart contracts in the main blockchain 132. For the identity and profile management system 120 to read the smart contract associated with a specific user, the identity and profile management system 120 may require some information, such as an access token, an access control bitmap, and / or the user's public key. When this information is available, the identity and profile management system 120 may be able to read the smart contract to map the location where the user's PII is stored. Subsequently, the identity and profile management system 120 can retrieve the user's PII from those locations and publish the PII to the requesting entity.

[0050] An additional layer of security is added by storing the user's PII in off-chain 134 in an 'anonymized' manner (e.g., where all locations of the user's PII are indexed using the main blockchain 132). In the event of a hack on off-chain 134, the data within off-chain 134 cannot be associated with a specific user. Furthermore, in the event of a hack on the main blockchain 132, the main blockchain 132 only contains the locations of the user's PII, and those locations can only be read by someone possessing the user's private key.

[0051] In summary, the identity and profile management system 120 can store user data off-chain 134 (which may be a blockchain) and retrieve the stored user data from off-chain 134. Entity 110 itself cannot directly access off-chain 134 or even the main blockchain 132, which indicates the location of the user data stored off-chain 134. In order for entity 110 to obtain the user data, the identity and profile management system 120 must retrieve the requested user data from off-chain 134 and publish the user data to the requesting entity.

[0052] As an example use case, one of Entities 110 could be a financial entity, such as a bank. If a user applies for a loan from a bank, the bank may request certain information associated with the user necessary to make a loan decision. For example, the bank might need information such as the user's address and the bank account number to which the loan will be deposited. Additionally, the bank might want to know the user's current salary and total current debt to determine whether providing a loan to the user is prudent. However, the bank would not request this information directly from the user. Instead, the user could provide the bank with their mobile device's phone number. The bank could then send the request to an identity and record management system 120, where the request would specify the user's phone number and all the different information items requested (these items could be in the form of attribute IDs or field names, such as "salary," "total debt," etc.). In some cases, the request may also include an entity identifier associated with the bank (e.g., the bank's public key).

[0053] The identity and record management system 120 will receive the request from the bank. In some embodiments, the identity and record management system 120 may authenticate the bank by verifying an entity identifier. For example, the entity identifier may be sent to a certificate authority for verification (e.g., whether the entity identifier is a public key). Subsequently, the identity and record management system 120 may check whether the user's phone number exists in the records of the identity and record management system 120 (e.g., whether the user's phone number exists in the data storage). If the user's phone number exists in the records, it means that the user has registered with the identity and record management system 120 and the requested information may have been collected and stored.

[0054] Alternatively, if the user's phone number is not in the records, it means the user has not yet registered with the Identity and Records Management System 120. The Identity and Records Management System 120 can then contact the user via phone number (e.g., by sending a text message to the number), instructing the user to download a mobile application associated with the Identity and Records Management System 120 (in some cases, this application may be referred to as a "client system," which is related to...). Figure 2(To be discussed in more detail). The user will then instruct their mobile device to download and install the corresponding mobile application. In some embodiments, a user private key (which may be generated by the mobile device or provided by the identity and profile management system 120) may be assigned to the user and sent to the application to be stored. In some embodiments, the identity and profile management system 120 may provide the user with an IPS public key, which may be stored by the application. After installation, the mobile application will set up the user's profile to be associated with the mobile device phone number by having the user manually enter their personal information into the application. Subsequently, the identity and profile management system 120 will collect and store all users' PIIs off-chain 134, the location of which is indexed by smart contracts in the main blockchain 132. The identity and profile management system 120 may also provide the bank with the user data it requests.

[0055] If a user's phone number exists in the records, the identity and records management system 120 can forward the request to an application on the user's mobile device. The application will notify the user that the bank is requesting their information and provide a list of all the information requested by the bank. The user may have the authority to publish all requested information to the bank, or in some embodiments, the user may have additional options to select which items to publish to the bank (e.g., the user may choose to publish their current salary instead of their total debt).

[0056] Once the user indicates which data items are permitted to be published to the bank, the mobile application can generate an access control bitmap corresponding to those permissions. The access control bitmap can be used to generate an access token (e.g., by encrypting the bitmap with a shared secret, which can be a combination of the user's private key and / or entity identifier, or by encrypting the bitmap with an IPS public key provided by the IPS), which is then sent back to the identity and records management system 120. About Figure 2 A more detailed description of the access control bitmap and access token.

[0057] The identity and profile management system 120 can decrypt the access token to determine which data items the user has authorized to be published to the bank. Furthermore, the identity and profile management system 120 can use the access token to locate the smart contract on the main blockchain 132 and read the smart contract to determine the location of the user's PII stored off-chain 134. The identity and profile management system 120 can retrieve the requested data from off-chain 134 and publish those data items back to the bank. If the bank has requested certain data items not stored off-chain 134 (which can be determined by checking the available data in the smart contract), the identity and profile management system 120 can prompt the user for additional information (similar to a user registration process) and store that information off-chain 134 after providing it to the bank.

[0058] Figure 2 A system diagram illustrating a client system and an identity and profile management system according to embodiments of the present disclosure is provided.

[0059] As shown in the figure, client system 200 (e.g., used by a user) can be configured to interact with identity and profile management system 220 (e.g., a third-party system for relaying requested user PII to various entities).

[0060] In some embodiments, client system 200 may be a hardware and / or software (e.g., application) package installed on a user's mobile device (e.g., a smartphone). For example, client system 200 may include a software application containing all the various components of client system 200, and a user can install the application on their mobile device by navigating to an 'application store' on their browser.

[0061] In some embodiments, the client system 200 may include user interface (UI) component feature 202 and / or SDK feature 212. In some embodiments, the user interface (UI) component feature 202 may include a renderer module 204, a data obfuscator module 206, and / or a secure channel module 208. In some embodiments, the SDK feature 212 may include a keystore management module 214, a bitmap computer module 216, and / or a token resolver module 218.

[0062] In some embodiments, the presenter module 204 may be a graphics engine that presents a graphical user interface (GUI) of a query or request from a display entity to a user’s PII on the user’s mobile device.

[0063] In some embodiments, the data obfuscation module 206 can be configured to encrypt user data (e.g., the user's PII) before the user data is transmitted by the mobile device (e.g., via a wireless communication protocol). For example, when a user initially supplies their PII to the identity and profile management system 220 for storage for later use, the data obfuscation module 206 can encrypt the PII as an additional security precaution. This may help prevent intermediary attacks, where malicious entities are attempting to intercept the user's PII. The data obfuscation module 206 can use any suitable encryption scheme.

[0064] In some embodiments, the secure channel module 208 may be a component that allows the establishment of a secure call or communication channel between the client system 200 and the Identity and Records Management Service (IPS) 230 of the Identity and Records Management System 220. For example, in embodiments where the client system 200 includes a software application installed on a user's mobile device, the secure channel module 208 within that application may function to ensure that other applications on the mobile device (e.g., running in the background) cannot inspect any service requests or communications with the Identity and Records Management Service (IPS) 230. In some embodiments, the secure channel module 208 may also prevent mediation attacks by establishing a secure channel to prevent the interception of any communications with the Identity and Records Management Service (IPS) 230. This secure channel may also be used to 'hide' data sent from the user's mobile device to an entity (via the IPS).

[0065] In some embodiments, the keystore management module 214 may be a user's private key store or a secure location (e.g., a trusted execution environment) in the user's mobile device where the user's private key certificate is stored. This private key may be used as one of three inputs for creating an access token required to locate and access the user's stored PII.

[0066] In some embodiments, bitmap computing module 216 may be a component for generating an access control bitmap that can be understood by the IPS (e.g., an IPS-understandable bitmap). The bitmap can be used to indicate which data items / fields of a user's PII or profile attributes an entity is requesting. For example, a user's PII may include hundreds of data items (e.g., the user's address, birth data, Social Security number, bank account number, etc.). If a transaction with an entity requires only a subset of these data items (e.g., the entity only requests the user's address and date of birth, and not other items such as the user's Social Security number, bank account number, etc.), then for security reasons, care should be taken to ensure that only the required data items are provided to the entity, without providing any 'extra' PIIs (e.g., only the user's address and date of birth are provided to the entity as requested). Therefore, the bitmap serves as a mapping or indication of which data items are permitted to be published to the requesting entity. In some embodiments, the bitmap may be conceptually viewed as a simple list of available data fields. In some implementations, the bitmap may contain a '0' or '1' value corresponding to each data field, where a '1' indicates that the user's PII corresponding to said data field is permitted to be published to the requesting entity. In some cases, a bitmap can have 128 bits used individually as switches. For example, each bit can be set to '0' or '1', and if a bit is set to '1', the user can request the attributes associated with that bit.

[0067] In some embodiments, the token resolver module 218 may be configured to generate access tokens. In some embodiments, the access token may be generated based on a combination of three inputs: the user's private key (e.g., stored by the keystore management module 214), the entity's public key or any other suitable identifier of the entity (e.g., an entity identifier verified by a certificate authority), and an access control bitmap (e.g., generated by the bitmap computing module 216). In some embodiments, the token resolver module 218 may also be configured to verify an entity (e.g., a financial entity such as a bank) using the entity's public key or the entity's identifier received by the client system 200. The access token may be used to indicate a number of situations: (1) a user has specifically granted permission to access data and said permission has not come from anyone else (this can be inferred from the encryption used and the return of the entity identifier supplied to the mobile device); and (2) the correct requesting entity will receive the data, and no other entity is involved (this can be confirmed using the entity's identifier). In some embodiments, the token resolver module 218 can generate an access token by taking three inputs: a user's private key, an entity's public key, and an access control bitmap, and then binding all said information together to create an access token (e.g., by encrypting the bitmap with a shared secret based on a combination of the user's private key and the entity's public key). Additional examples of techniques for generating access tokens are disclosed herein.

[0068] In some embodiments, the access token may also impose additional restrictions on how a requesting entity can access the published information (e.g., the duration of access). Options may be presented to the user within a mobile application to limit access restrictions on the requesting entity, such as duration. Various access restrictions for different entities associated with a particular user can be defined and managed within a smart contract on the main blockchain associated with that user. For example, if a user only wants bank 'X' to access its PII for 48 hours, the user can specify that the access restrictions will be included in the mobile application and the generated access token.

[0069] In summary, a user's mobile device can initially receive a request to provide the user's PII to the IPS. This request can be displayed via a graphical user interface (GUI) presented on the mobile device's screen (e.g., by the presenter module 204). If the user accepts the request, they can manually enter their PII (which may include multiple data items) directly into the GUI. The PII can then be encrypted (e.g., by the data obfuscator module 206) and sent to the IPS (e.g., via a secure channel established by the secure channel module 208) for storage on the backend. When an entity requests certain items from the user's PII, the request can be similarly displayed via a GUI presented on the mobile device's screen (e.g., by the presenter module 204). In some cases, the mobile device can receive the entity's identifier via a request, which can be used to authenticate the requesting entity (e.g., by verifying the identifier with a Certificate Authority). If the user accepts the request, an access control bitmap (e.g., by the bitmap computer module 216) can be generated indicating which items of the user's PII are permitted to be published to the entity. Access tokens can be generated on the client side using a bitmap, the user's private key, and the entity's identifier (e.g., by token resolver module 218). Once the access token is created, a secure connection is initiated through the IPS, and the access token is sent back to the IPS. The IPS can decrypt and read the bitmap, which can be used to identify the data item being published, locate the user's requested PII, and provide the user's requested PII to the requesting entity.

[0070] In some embodiments, the identity and records management system 220 may include an identity and records management service (IPS) 230 and / or a blockchain wrapper service 260.

[0071] In some embodiments, the identity and profile management service 230 may utilize a REST / socket interface and may include core features 232, appearance features 242, and / or a state data storage area 252. In some embodiments, core features 232 may include a token inferrer / parser module 234 and / or a data structure module 236. In some embodiments, appearance features 242 may include a smart contract communication module 244 and / or a BaaS marshaling processing module 246.

[0072] In some embodiments, the token inferrer / parser module 234 may be configured to receive and parse any access token received from a user's mobile device. As previously mentioned, the access token signifies a user's intention to share certain attributes or data items within their PII with a requesting entity. In some embodiments, the token inferrer / parser module 234 component interacts with an underlying blockchain service to obtain or store the user's PII. In some embodiments, the token inferrer / parser module 234 may be aware of a specific decryption mechanism required to decode the access token. The token inferrer / parser module 234 may decrypt the access token based on an appropriate decryption mechanism of the implementation. In some embodiments, for example, the token inferrer / parser module 234 may decrypt the access token using a shared secret (e.g., based on the user's private key and the entity's public key) and examine an access control bitmap supplied by the client system 200 to determine the attributes for which the user has granted read permissions. Alternatively, as another example, the token deducer / resolver module 234 can decrypt the access token using the IPS private key (if the access token is encrypted using the IPS public key provided to the mobile device) in order to view the access control bitmap supplied by the client system 200 and determine the attributes for which the user has granted read permissions.

[0073] In some embodiments, data structure module 236 may be configured to define how a user's PII is stored and constructed on the backend. In some embodiments, data structure module 236 may include a set of categories defining data structures associated with users, entities, and any other downstream systems.

[0074] In some embodiments, the smart contract communication module 244 can act as the interface for managing connections to blockchain services (e.g., if blockchain technology is used to implement the storage of user PII). This component can be configured to translate hardware-level language into a language compatible with smart contract parties. In other words, this component can be a converter that retrieves objects and transforms them into smart contracts.

[0075] In some embodiments, the BaaS marshaling module 246 can be configured to transform data structures between the IPS 230 and the blockchain wrapping service 260. In some embodiments, the BaaS marshaling module 246 can be configured to transform the data as a callback service after the user's data to be sent to the requesting entity (e.g., user PII) has been located off-chain. The callback service can output the data to the requesting entity, so the entity can continue to perform its interaction with the user. Sending data to the requesting entity as a callback service can take only a few seconds and can be implemented using asynchronous API calls.

[0076] In some embodiments, the state data storage area 252 may be a local state database that stores the service call states of various users, without storing any PII associated with those users. For example, in some embodiments, the state data storage area 252 may store the phone numbers associated with the mobile devices of various users. If a user's mobile device phone number is stored in the state data storage area 252, it means that a user profile exists and the user's PII has been collected and stored. Otherwise, if a user's mobile device phone number does not exist in the state data storage area 252, a user profile must be created and the user's PII must be collected for storage. Therefore, IPS 230 can be configured to check the existence of a user in the system by checking the phone number of the mobile device associated with the user.

[0077] In some embodiments, the blockchain packaging service 260 may include off-chain features 262 and / or smart contract features 272. In some embodiments, off-chain features 262 may include a blockchain linker module 264, an instant storage module 266, and / or an encryptor module 268. In some embodiments, smart contract features 272 may include a locator module 274, an entity authenticator module 276, and / or a performance measurement module 278.

[0078] In some embodiments, the blockchain linker module 264 can be configured to create a link between each user's profile state and the user's PII stored on a separate blockchain via a smart contract. The separate blockchain may store the user's anonymized PII data in the form of transactions.

[0079] In some embodiments, the timely storage module 266 may be a component that allows retrieval of user data from multiple segments over a short period of time. Users may have stored different attributes through different entities at different times. Over time, attribute data may change, and entity access to said attribute may change or expire. For example, a user's address may change over time as the user moves, and the timely storage module 266 may be configured to allow retrieval of the user's address at different points in time. For this type of dynamic data, the timely storage module 266 may be configured to manage the time when data will be available to each entity. For example, in one embodiment, for each PII data item of a user, an access timer may exist for each entity. This access timer may be an event-based timer (e.g., entity 'X''s access to this particular data item will expire in 5 days). In some embodiments, even if all different attributes have different time settings, only one access timer may be triggered at a time. However, it should be noted that not all user PIIs will be inherently dynamic. For example, a user's Social Security number does not change over time, so it is not necessary to retrieve the user's Social Security number at different points in time.

[0080] In some embodiments, the encryptor module 266 can be configured to encrypt a user's PII before storing it (e.g., entirely off-chain, which could be a decentralized data store or a separate blockchain). This encryption provides an additional layer of security for the stored data fields. Therefore, if someone hacks off-chain, encrypted data will be presented to these individuals, which must first be decrypted to be understood. In some embodiments, the encryptor module 266 can encrypt a user's PII using an IPS public key. In some embodiments, the encryptor module 266 can encrypt a user's PII using a user's public key. Therefore, all data off-chain (for all different users) can be encrypted using a changing user public key. To decrypt data associated with a specific user, the user's private key will be required. Therefore, if someone hacks off-chain, the IPS private key will be further required to decrypt and understand any data associated with that user.

[0081] In some embodiments, locator module 274 can act as a smart contract locator for finding a suitable smart contract associated with a user's PII based on user and entity parameters. Locating a smart contract can be a first step in writing, retrieving, or updating a user's PII, because in some embodiments, the location of the user's PII and any access restrictions associated with the PII can be stored on a smart contract on the main blockchain. For example, a smart contract can identify the location where certain data items of a user are stored (e.g., at an off-chain location) and any authorizations granted to those data items (e.g., which entities have accessed those data items). Locator module 274 can also be configured to interpret the appropriate smart contract, thereby allowing locator module 274 to locate the actual location where the requested data item is stored based on what the data item is (e.g., a bitmap) and who the user is (e.g., based on a phone number associated with the user's mobile device).

[0082] In some embodiments, locating the appropriate smart contract associated with a user may involve information contained within an access token. In some embodiments, reading the information contained within a smart contract associated with a user may involve decryption based on a key associated with the access token (e.g., a shared secret based on the user's private key). Therefore, it is not possible for an entity to directly access the smart contract associated with a user to attempt to locate the user's PII off-chain without possessing the access token and any information necessary to decode it.

[0083] In some embodiments, the entity authenticator module 276 can be configured to authenticate the entity submitting the request for a user's PII. As previously mentioned, each entity can be assigned and associated with an entity identifier. In some embodiments, the entity identifier can be a public key certificate assigned to the entity during login. The entity authenticator module 276 can be used to verify this public key certificate relative to a certificate authority in order to authenticate the entity. Therefore, the entity authenticator module 276 can be used to prevent malicious entities from gaining access to user data.

[0084] In some embodiments, the performance metrics module 278 can be configured to record in detail (eliminating any user PII data) any transaction time, transaction path, success / error rate, and other metrics associated with storing, retrieving, and relaying user PIIs. The performance metrics module 278 can be configured to determine certain steps in the data relay process and compile all metrics to identify the time spent on improving areas.

[0085] Figure 3 This document describes a flowchart illustrating an embodiment of the present disclosure for registering a user with an identity and profile management system.

[0086] At block 302, a user can initiate a transaction or interaction with an entity. In some embodiments, a user can do this via their mobile device, for example, by directing a browser on their mobile device to the entity's webpage and selecting an option associated with the transaction on the webpage. In some embodiments, a user can initiate the transaction in person. For example, if the entity is a bank, the user might be able to appear at a branch of the bank to apply for a loan.

[0087] At box 304, the entity can send a user identifier to the IPS. The user may supply their user identifier to the entity during transaction initiation, or in some cases, the entity may know the user identifier in advance. In some embodiments, the user identifier may be a phone number associated with the user's mobile device.

[0088] At box 306, the IPS can acquire the received user identifier and use it to look up whether a user profile exists for the IPS. For example, the IPS may have a data storage area (e.g., a status data storage area) containing user identifiers associated with users registered with the IPS. This data storage area will not contain any other user PIIs that will be stored off-chain. This data storage area can be used for user registration checks. In some embodiments, this data storage area may also list the available attribute IDs or fields of a user's available PIIs without providing the actual values ​​of those PIIs. For example, the data storage area may indicate that the PIIs collected for user 'X' include the user's address, Social Security number, and current salary, without specifying the actual content of each of those items.

[0089] At box 308, if the IPS determines that a user's profile does not exist and the user has not yet registered with the IPS, the IPS can send a registration notification to the user. For example, if the user identifier is the phone number of the mobile device associated with the user, the IPS can check the data storage to determine that the phone number is not stored in the data storage. The IPS can then send a text message to the phone number, thereby notifying the user that they need to register. The text message may include a link that takes the mobile device's browser to a webpage (or a page in a mobile application store) that will provide a mobile application to be downloaded and installed (e.g., client system 200).

[0090] At box 310, a user can download and install a mobile application on their mobile device. The application guides the user through a registration process, after which the IPS saves the user's identifier (e.g., their phone number) to track user registration. In some embodiments, the registration process may involve the user manually entering and providing some PII via the mobile application, which is received and saved by the IPS (e.g., along with...). Figure 4The steps shown in boxes 416, 418, 420, and 422 are similar to those in the off-chain storage. Upon successful completion of the registration process, the IPS can generate and distribute the user's private key to the user. This may require the user's mobile device to store the private key (e.g., in a keystore on the mobile device) for future use. The IPS does not store the user's private key, but in some embodiments, the IPS may store a hash of the user's private key, which can be used to generate a shared secret to decrypt transmissions from the mobile device. In some embodiments, the user's mobile device may generate its own private key independently, rather than receiving it from the IPS. In other embodiments, the IPS may have an IPS public / private key pair and may transmit the IPS public key to the mobile device for storage and use for cryptographic purposes. The IPS can then use the IPS private key to decrypt any data sent from the mobile device that has been encrypted with the IPS public key.

[0091] Figure 4 This document describes a flowchart illustrating an embodiment of the present disclosure for collecting PII from a user through an identity and profile management system.

[0092] As shown in the figure, boxes 402, 404, and 406 can be similar to Figure 3 Boxes 302, 304, and 306 in the text. Figure 4 The main emphasis is on requesting users to provide PII for storage. In some embodiments, access controls (e.g., time limits and other access restrictions) are established during this process.

[0093] At box 402, a user can initiate a transaction or interaction with an entity. In some embodiments, a user can do this via their mobile device, for example, by directing a browser on their mobile device to the entity's webpage and selecting an option associated with the transaction on the webpage. In some embodiments, a user can initiate the transaction in person. For example, if the entity is a bank, the user might be able to appear at a branch of the bank to apply for a loan.

[0094] At box 404, the entity can send a user identifier to the IPS. The user may supply their user identifier to the entity during transaction initiation, or in some cases, the entity may know the user identifier in advance. In some embodiments, the user identifier may be a phone number associated with the user's mobile device.

[0095] At box 406, the IPS can acquire the received user identifier and use it to check if a user profile exists for the IPS. For example, the IPS may have a data storage area (e.g., a status data storage area) containing user identifiers associated with users registered with the IPS. This data storage area will not contain any other user PIIs that will be stored off-chain. This data storage area can be used for user registration checks. In some embodiments, this data storage area may also list available attribute IDs or fields for a user's available PIIs without providing the actual values ​​of those PIIs. For example, the data storage area may indicate that the PIIs collected for user 'X' include the user's address, Social Security number, and current salary, without specifying the actual content of each of those items. If the IPS determines that a user profile exists (e.g., the user identifier exists in the system), the IPS can bypass [the restrictions / restrictions]. Figure 3 The registration process is shown and the entity is notified.

[0096] At box 408, an entity can send a request for a user's PII to the IPS. The requested user PII can be transaction-specific. For example, if a user applies for a loan through a financial entity, the financial entity may need to know certain information, such as the user's bank account number, current salary, and current total debt, to determine whether it is wise to provide the loan to the user. The request can specify different information items requested for the user (these can be in the form of attribute IDs or field names, such as "salary," "total debt," etc.). In some cases, the request may also include an entity identifier associated with a bank (e.g., the bank's public key).

[0097] At box 410, the IPS can forward the entity's request to the user's mobile device. In some embodiments, the IPS can construct a bitmap indicating the different items of the PII requested by the user. In some embodiments, the user's mobile device can construct this bitmap based on the items that the user has authorized to be published to the requesting entity's PII.

[0098] At box 412, the user's mobile device can authenticate the entity submitting the request. In some embodiments, this can be done by verifying the entity identifier that submitted the request. For example, the entity identifier could be a public key associated with the entity, and the request could be digitally signed with a certificate authority's private key.

[0099] At box 414, the user can input the requested PII into an application on their mobile device, and the mobile device can send the PII to the IPS. In some embodiments, the mobile device may first encrypt the PII with the IPS public key or a shared symmetric key as an additional security layer.

[0100] At box 416, the IPS can receive the PII provided by the user and associate the PII with the user. In some embodiments, the data storage area associated with the IPS can be updated to reflect the items (e.g., attribute IDs or fields) of the PII collected from the user. For example, if the user provides their address and Social Security number, the data storage area can be updated to indicate that the user's address and Social Security number have been collected. This will allow all available PIIs for the user to be determined based on the user identifier associated with the user.

[0101] At box 418, the IPS can marshal the received PII, fork the received PII, and convert it into instructions to execute smart contracts on the main blockchain (e.g., in an embodiment using a combination of the main blockchain and off-chain components). The IPS, acting as a third-party intermediary, does not store data itself, but instead provides data and data storage instructions to the blockchain platform.

[0102] At box 420, the blockchain platform used for the main blockchain will locate and execute the smart contract. In practice, the smart contract will instruct the user and the different items of PII collected from the user. The PII will be indexed within the smart contract, but the actual value of the PII will be stored off-chain. The smart contract will calculate the location off-chain where the actual value of the PII is stored.

[0103] At box 422, the value of PII will be stored off-chain for later retrieval. In some embodiments, the PII may be stored off-chain in an encrypted format.

[0104] It should be noted that, Figure 4 In this scenario, the user only provides a PII after being prompted to do so. In some embodiments, the user will not be able to arbitrarily initiate a process to provide a PII for storage. There may be several reasons for this. First, it may not be necessary to provide the user with access to the API used to store the PII. Second, to create an access token, an entity identifier (e.g., a public key) is required as input. The user, without receiving the entity identifier, will not know the entity identifier and therefore will not be able to create an access token. Furthermore, it may be necessary for an entity to perform a check to verify the PII provided by the user before the information is added to the storage device (e.g., off-chain) by the IPS. This verification may be performed by an entity, for example, before boxes 416 or 418. An example of this verification could include a Know Your Customer (KYC) process, which may include collecting and analyzing basic identity information from the user. This verification may be highly desirable because allowing the user to arbitrarily store a PII could result in the storage of unverified information, as no entity would be assigned to verify the information.

[0105] Figure 5This document describes a flowchart illustrating an embodiment of the present disclosure for publishing a user's PII through an identity and profile management system.

[0106] As shown in the figure, boxes 502, 504, 506, 508, 510, and 512 can be similar to... Figure 4 Boxes 402, 404, 406, 408, 410, and 412. However, Figure 5 Describe the process by which an entity retrieves the user PII that has been collected and stored.

[0107] At box 502, a user can initiate a transaction or interaction with an entity. In some embodiments, a user can do this via their mobile device, for example, by directing a browser on their mobile device to the entity's webpage and selecting an option associated with the transaction on the webpage. In some embodiments, a user can initiate a transaction in person. For example, if the entity is a bank, the user may be able to go to a branch of the bank to apply for a loan. In some embodiments, a user can initiate a transaction through a self-service terminal at the entity. For example, a bank may have automated self-service terminals that a user can use to apply for a loan.

[0108] At box 504, the entity may send a user identifier to the IPS. The user may supply their user identifier to the entity during transaction initiation, or in some cases, the entity may know the user identifier in advance. In some embodiments, the user identifier may be a phone number of a mobile device associated with the user.

[0109] At block 506, the IPS can acquire the received user identifier and use it to check if a user profile exists for the IPS. For example, the IPS may have a data storage area (e.g., a status data storage area) containing user identifiers associated with users registered with the IPS. In some embodiments, the data storage area may also contain the name of the user associated with the corresponding user identifier. For example, if the user identifier is a phone number associated with a registered user, then for each registered user, the data storage area will contain their phone number and name. This data storage area will not contain any other user PIIs, which will be stored off-chain and primarily used for user registration checks.

[0110] In some embodiments, this data store may also list the available attribute IDs or fields of a user's available PIIs without providing the actual values ​​of those PIIs. For example, the data store may indicate that the PIIs collected for user 'X' include the user's address, Social Security number, and current salary, without specifying the actual content of each of those items. If the IPS determines that a user profile exists (e.g., a user identifier exists in the system), the IPS can bypass [the restrictions]. Figure 3 The registration process is shown and the entity is notified.

[0111] At box 508, an entity may send a request for a user's PII to the IPS. The requested user PII may be transaction-specific. For example, if a user applies for a loan through a financial entity, the financial entity may need to know certain information, such as the user's bank account number, current salary, and current total debt, to determine whether it is wise to provide the loan to the user. The request may indicate different information items requested for the user (these may be in the form of attribute IDs or field names, such as "salary," "total debt," etc.). In some cases, the request may also include an entity identifier associated with a bank (e.g., the bank's public key). In some embodiments, the set of user PIIs requested by the entity may be included in a 'first set of information' associated with the user.

[0112] At box 510, the IPS can forward the entity's request to the user's mobile device. In some embodiments, the IPS can construct a bitmap indicating different items of the PII requested from the user. In some embodiments, the user's mobile device can construct this bitmap based on items that the user has permitted to be published to the requesting entity's PII. The bitmap can represent a set of bits, where each bit represents or corresponds to an attribute of user data. If a bit is set to '1', the attribute of the user's PII corresponding to that bit is requested. In some embodiments, the entity can actually construct the bitmap and send the bitmap and the request to the IPS of the user's PII (e.g., at box 508). Thus, the request will include the bitmap and an entity identifier associated with the entity, such as the entity's public key. At box 510, the IPS can again forward the bitmap and the entity's public key to the user's mobile device.

[0113] At box 512, the user's mobile device can authenticate the entity submitting the request. In some embodiments, this can be done by verifying the entity identifier that submitted the request. For example, the entity identifier may be a public key certificate or a public key associated with the entity, and the request may be digitally signed with said public key, which can be verified by a certificate authority.

[0114] At box 514, a user can grant permission to publish all or part of a PII requested by an entity (e.g., via a mobile application). An access control bitmap can be generated (or an existing bitmap can be updated) to indicate which items of the user's PII are permitted to be published. This bitmap can be used to generate an access token by combining the user's private key and an entity identifier (e.g., the entity's public key). As an example, the access token may include the bitmap and can be encrypted using a shared secret generated based on a combination of the user's private key and the entity identifier (e.g., a hash of the combination of the user's private key and the entity identifier). At box 514, the access token can be constructed and sent to the IPS. In some embodiments, the bitmap is "bound" to the user's key and the entity's key. Additionally, the access token can be encrypted by the mobile device to create it. In some embodiments, the set of user PIIs that the user is permitted to publish to the requesting entity may be included in a 'second set of information' associated with the user.

[0115] At box 516, the IPS can receive and decode the access token. The access token can be decoded based on an appropriate decryption method used in the implementation. For example, in some embodiments, the access token has been generated by the user's mobile device using a shared secret (e.g., a symmetric key), which is based on the user's private key and the entity's public key. For example, to form the shared secret, the entity's public key can be signed by the user's private key (or a hash of the user's private key), or both the entity's public key and the user's private key can be hashed, etc. Therefore, the shared secret can be known to the IPS and the user's mobile device, and the IPS can use the shared secret to decrypt the access token. In some embodiments, the IPS may also be able to generate the shared secret. For example, without having the user's private key, the IPS may be able to derive the shared secret using the entity's public key. If the shared secret involves signing or modifying the entity's public key using a hash of the user's private key, the IPS may be able to generate the shared secret from the entity's public key and a hash of the user's private key, even though the IPS does not actually know the user's private key.

[0116] In some embodiments, the Diffie-Hermann exchange scheme can be used to exchange shared secrets between the IPS and the user's mobile device.

[0117] Alternatively, as another approach, the IPS may have only provided the IPS public key to the user's mobile device (e.g., during the registration process). The IPS can store the IPS private key, which it can use to decrypt the access token that has been encrypted by the user's mobile device using the IPS public key. The IPS can then use the bitmap associated with the access token to determine which items are permitted to publish the user's PII. The IPS can also use the access token to determine the location of the smart contract on the main blockchain associated with the user's PII.

[0118] At box 518, the IPS instructs the blockchain platform to locate and execute a smart contract on the main blockchain to obtain the location of the user's PII stored off-chain. Generally, a smart contract on the blockchain platform can have a transaction identifier or an address that can be used to locate the smart contract. Therefore, an address can be used to locate a smart contract corresponding to a specific user. For example, an access token can be parsed and a checksum can be calculated (e.g., to confirm the access token is valid). The checksum can point to a specific transaction identifier or address that can be used to find the smart contract corresponding to the user associated with the access token. In this instance, a hash table storing various checksums and corresponding transaction identifiers as key-value pairs can exist. Alternatively, as another instance, checksum calculation can produce the transaction identifier itself, thus providing the location of the smart contract itself. In this instance, it is not necessary to store the relationship between the checksum and the transaction identifier used to locate the smart contract, thereby eliminating a potentially weak link in the event of an IPS attack. Once the user's smart contract is located (e.g., using the transaction identifier), the smart contract can be executed (e.g., by providing an access token if the smart contract's logic requires it), and the smart contract will return the location of the user's PII stored off-chain.

[0119] At box 520, the item for the authorized user's PII is retrieved from off-chain using the determined location of the PII via IPS. In some embodiments, the value of the user's PII retrieved from off-chain may include in the 'third set of information' associated with the user.

[0120] At box 522, the IPS collects data items from the PII of the authorized user retrieved from outside the chain. The IPS sends a callback (e.g., an API call) to the entity to publish the data items to the entity. This informs the entity that the IPS has the requested information and that the entity can gain access to the information for a specific period of time.

[0121] At box 524, the entity can proceed and retrieve the requested user's PII. In some embodiments, the entity can retrieve the user's PII from the IPS. In some embodiments, the IPS can grant entity access to the user's PII for a limited time period. This time period can be specified in a smart contract, or this event can be specified by the user (e.g., when the user grants permission to publish their PII, triggering the transmission of an access token). In the latter case, the IPS (not a smart contract) can track the time window in which the entity will access the user's PII. In either case, once the time window for granting the entity access to the user's PII expires, the IPS can deny the entity access to the information.

[0122] Specific details regarding some of the foregoing aspects have been provided above. These specific details may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention.

[0123] It should be understood that the present invention described above can be implemented in a modular or integrated manner using computer software (stored in a tangible physical medium) in the form of control logic. Based on this disclosure and the teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing the present invention using hardware and combinations of hardware and software.

[0124] Any software component or function described in this application may be implemented using, for example, conventional or object-oriented techniques and in any suitable computer language, such as Java, C++, or Perl, as software code to be executed by a processor. The software code may be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on different computing devices or within different computing devices.

[0125] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims and their full scope or equivalents.

[0126] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0127] Unless explicitly indicated otherwise, the use of “a,” “one,” or “the” is intended to mean “one or more.”

[0128] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method comprising: The mobile device receives a request from the identity and profile analysis system to provide a first set of information associated with the user of the mobile device to the requesting entity; The mobile device generates a user interface that allows the user to authorize the provision of the first set of information associated with the user to the requesting entity; Based on the user authorization, the first set of information associated with the user is provided to the requesting entity, and the mobile device generates a second set of information associated with the user; The mobile device retrieves the key associated with the user; The mobile device generates an access token by encrypting the second set of information associated with the user using the key associated with the user. as well as The mobile device sends the access token to the identity and profile analysis system, wherein the first set of information is stored off-chain in a distributed manner, and wherein information identifying the storage location of the first set of information off-chain is maintained in the blockchain.

2. The method of claim 1, wherein the second set of information associated with the user is an access control bitmap.

3. The method of claim 1, wherein the mobile device includes a keystore manager for storing the key associated with the user.

4. The method of claim 1, wherein the method further comprises: The mobile device determines the entity identifier associated with the requesting entity based on the request; as well as The mobile device authenticates the requesting entity by verifying the entity identifier.

5. The method of claim 1, wherein the first set of information includes the user's personally identifiable information.

6. The method of claim 1, wherein the second set of information includes personally identifiable information that the user is willing to publish.

7. The method of claim 1, wherein the mobile device is a mobile phone.

8. The method of claim 1, wherein the key is a combination of a user key and an entity identifier.

9. The method of claim 1, further comprising: The requesting entity is authenticated before the access token is sent.

10. The method of claim 1, further comprising: The requesting entity is authenticated by verifying its digital signature using its public key before sending the access token.

11. The method of claim 1, wherein the identity and profile analysis system uses the key to decode the access token.

12. A mobile device, comprising: processor; as well as A computer-readable medium comprising code that can be executed by the processor to perform operations including: Receive a request from the identity and profile analysis system to provide the requesting entity with a first set of information associated with the user of the mobile device; Generate a user interface that allows the user to authorize the provision of the first set of information associated with the user to the requesting entity; Based on the user authorization, the first set of information associated with the user is provided to the requesting entity, and a second set of information associated with the user is generated; Retrieve the key associated with the user; The mobile device generates an access token by encrypting the second set of information associated with the user using the key associated with the user. as well as The mobile device sends the access token to the identity and profile analysis system, wherein the first set of information is stored off-chain in a distributed manner, and wherein information identifying the storage location of the first set of information off-chain is maintained in the blockchain.

13. The mobile device of claim 12, wherein the second set of information associated with the user is an access control bitmap.

14. The mobile device of claim 12, wherein the mobile device includes a keystore manager for storing the key associated with the user.

15. The mobile device of claim 12, wherein the operation further comprises: The mobile device determines the entity identifier associated with the requesting entity based on the request; as well as The mobile device authenticates the requesting entity by verifying the entity identifier.

16. The mobile device of claim 12, wherein the first set of information includes the user's personally identifiable information.

17. The mobile device of claim 12, wherein the second set of information includes personally identifiable information that the user is willing to publish.

18. The mobile device of claim 12, wherein the mobile device is a mobile phone.

19. The mobile device of claim 12, wherein the operation further comprises: The requesting entity is authenticated before the access token is sent.

20. The mobile device of claim 12, wherein the operation further comprises: The requesting entity is authenticated by verifying its digital signature using its public key before sending the access token.

Images