BLOCKCHAIN-BASED IDENTITY AND TRANSACTION PLATFORM
Systems, methods, and computer media implementing blockchain-based identity and transaction platforms are described herein. Identity information, such as a photo, for a person can be encrypted and stored in a blockchain as part of enrolling the person as a user in a blockchain-based identity and transaction platform. Trust relationships can be formed between the user and other users, and records of the trust relationships can also be stored in the blockchain. Transactions between the user and other users with whom the user has formed a trust relationship can also be stored in the blockchain. The transactions can be authorized, for example, through a multi-stage verification process that accesses information stored on the blockchain. The transactions and identity information, along with other information, contribute to an economic identity of the person.
Latest BanQu, Inc. Patents:
- Computer-implemented authentication platform
- MANAGING PERMISSIONS TO ACCESS USER DATA IN A DISTRIBUTED LEDGER TRUST NETWORK
- Managing permissions to access user data in a distributed ledger trust network
- TRANSACTION AUTHORIZATION AND VERIFICATION THROUGH DISTRIBUTED-LEDGER-BASED CHAIN OF CUSTODY
- TRANSACTION AUTHENTICATION AND VERIFICATION USING TEXT MESSAGES AND A DISTRIBUTED LEDGER
This application claims the benefit of U.S. Provisional Application No. 62/495,574, filed on Oct. 17, 2015, and titled “UNIVERSAL IDENTITY AND PERSONAL DATA STORAGE, UPDATE AND RETRIEVAL IN THE BLOCKCHAIN. THIS INCLUDES PERSONAL DEMOGRAPHIC INFORMATION, CREDIT HISTORY AND TRANSACTIONS, CONTACTS AND RELATED RELATIONSHIPS, PROPERTY AND ASSET RIGHTS, GENERAL PREFERENCES AND GEO-LOCATION. ALL STORED IN THE BLOCKCHAIN,” which is incorporated herein by reference in its entirety.
BACKGROUNDIn today's modern economy, individuals typically establish accounts with different institutions and entities and use these accounts to interact with others to obtain goods and services and establish histories. Accounts are typically maintained on server computers under the control of the institution or entity. Such accounts, however, are often vulnerable to security risks such as hacking and identity theft and are frequently out-of-date or inconsistent. Such accounts are also traditionally less accessible to individuals in developing countries or refugee areas.
SUMMARYExamples described herein relate to blockchain-based identity and transaction platforms. In an example approach, identity information (e.g., a photo) for a person can be encrypted and stored in a blockchain as part of enrolling the person as a user in a blockchain-based identity and transaction platform. Trust relationships can be formed between the user and other users, and records of the trust relationships can be stored in the blockchain. Transactions between the user and other users with whom the user has formed a trust relationship can be authorized. Records of the transactions can also be stored in the blockchain. Authorization can involve, for example, a multi-stage verification process that accesses information stored on the blockchain. The transactions and identity information, along with other information, can contribute to an economic identity of the person. Storing an economic identity (and the underlying information that forms the economic identity of the person) in the blockchain results in a secure platform accessible to people regardless of their economic or geographic circumstances.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.
Using the systems, methods, and computer-readable media described herein, a blockchain-based identity and transaction platform can be implemented. People can enroll as users in the platform using identity information such as an image or photo (e.g., of the person's face). Once a user profile has been established, the user can form trust relationships with other users of the platform and perform transactions. Transactions can include, for example, funds transfers, medical treatment authorization, food assistance authorization, and other transactions. The identity information, trust relationships, transactions, and other information are stored in blocks in a blockchain. Unlike conventional approaches in which a user's information is stored and maintained on centralized server computers managed by many different entities and stored behind entity-specific firewalls, each of which may be vulnerable to security threats, the blockchain-based identity and transaction platform examples described herein provide secure storage of an individual's information through a distributed network of computers.
The example blockchain-based identity and transaction platforms also allow a person to integrate various types of information to create an economic identity that can be used to access goods and services. The economic identity can include, for example, a person's history of income, employment, payments to creditors or other parties, etc. The economic identity can be used to establish the qualifications and background that allow the person to participate in a credit-based (or otherwise sophisticated) economy. As an example, individuals in developing countries or refugee areas may not have access to institutions and entities necessary to build a history (e.g., a credit score) that allows the individual to access credit that can be used to start a business, purchase necessary farming equipment, make capital improvements, etc. An economic identity established through a blockchain-based identity and transaction platform can provide evidence of a person's creditworthiness, identity, legal status, etc. that enables the person to obtain credit. Because of the distributed nature of a blockchain, such an economic identity is both portable and accessible regardless of the economic or geopolitical situation in a user's current location. In addition to providing those in the developed world with a secure, integrated platform, the examples described herein have the potential to drastically reduce poverty in developing countries and help millions of refugees establish themselves in the world economy by providing access to credit. Examples are described below with reference to
In a blockchain, the individual blocks can store a variety of data that may or may not be related (e.g., may or may not be associated with a same user). In environment 100, mobile computing devices 102 and 104 are in communication with computing device(s) 106 over a network 108. Network 108 can be the Internet, a Local Area Network (LAN), a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), or other type of network, wired or wireless. Computing device(s) 106 can be, for example, one or more server computers. Computing device(s) 106 includes processor(s) 110, local storage 112, and memory 114. Environment 100 can also include one or more additional computing devices, such as desktop computers, (not shown) in communication with computing devices(s) 106 over network 108.
Computing device(s) 106 also includes an enrollment engine 116 and a transaction engine 118. Enrollment engine 116 is configured to enroll, by processor(s) 110, a person as a user in the blockchain-based economic identity and transaction platform based on identity information for the person. As an example, a person can use mobile computing device 102 (or other computing device, such as a desktop computer) to enter a name, government-assigned identification number, etc. and/or to take an image (e.g., a “selfie”) of themselves and, using a web application or using client-side software installed on mobile computing device 102, upload the image and/or other information to computing device(s) 106 as the identity information. Example software user interfaces are illustrated in
Transaction engine 118 is configured to authorize, by processor(s) 110, transactions between users who are in a trust relationship. Trust relationships can be established, for example, by request or invitation of a user and an acceptance by another user. Transactions can be authorized, at least in part, through interaction with a verification agent computing device 126. Verification agent computing device 126 communicates with computing device(s) 106 through network 108. As an example, a first user can initiate a funds transfer to a second user through a web application or through client-side software. Transaction engine 118 can be configured to perform a verification of the funds transfer using, for example, a multi-stage verification approach that accesses information stored in blockchain 122. Transaction verification examples are discussed in detail below with respect, e.g., to
Identity information, transaction information, and other information for a user that is stored in blockchain 122 can form an economic identity of the user.
Utility information 208 can include utility accounts for the user, records of past payments, and/or other information. Education history 210 can include degrees earned, educational levels completed, courses completed, certifications obtained, test scores, etc. Aid record 212 can include food assistance (e.g., food packets distributed by a United Nations or other aid entity) or loans received, loans repaid, etc. Property ownership 214 can include property deed information, property location information, property transaction information, etc. Medical history 216 can include medical records, medical insurance information, medical aid information (e.g., vaccinations received), etc. Transaction history 218 can include funds transfers received or provided, aid or medical assistance authorizations (even if also included in aid record 212 or medical history 216), or other transaction information. The information included in identity information 202, linked accounts 204, employment history 206, utility information 208, education history 210, aid record 212, property ownership 214, medical history 216, and transaction history 218 can be presented as aggregated information or as individual items.
Economic identity 200 can also include a “trust” score similar to a credit score that indicates a level of creditworthiness or responsibility that can be used by businesses or institutions who are users in the blockchain-based identity and transaction platform. The trust score can be determined based on a weighting scheme (e.g., quantification of employment history weighted at 50%, quantification of transaction history weighted at 30%, quantification of education history weighted at 20%, etc.). In some examples, particular businesses or institutions are able to select particular criteria of interest and/or desired weightings for different criteria, and a custom trust score is determined based on those criteria. Various approaches to quantifying a particular category can be used (e.g., percentile rank of criteria, scale of 1-10, etc.).
Economic identity 200 is stored in blockchain 220. Blocks 222, 224, 226, and 228 of blockchain 220 are shown in
In process block 304, records of trust relationships between the user and other users are stored in the blockchain. For users of the blockchain-based identity and transaction platform, a trust relationship can be formed, e.g., by performing a search or lookup of registered users and sending a user identified through the search or lookup a message indicating that a trust relationship is desired. If the other user accepts the request, then a trust relationship is established. In some situations, however, a user may wish to transfer funds or perform another transaction with a person who is not a user of the blockchain-based identity and transaction platform. In such situations, a user may send an invitation to connect to the person's email address, messaging account, or other contact point, with the message including a link or instructions for creating an account with the platform and indicating that the user would like to establish a trusted relationship.
Transactions between the user and one or more of the other users with whom the user has formed a trust relationship are authorized in process block 306. The transactions are stored in the blockchain. Records of the transactions are stored in the blockchain in process block 308. At least some of the transactions and identity information contribute to the economic identity of the person. The economic identity can also include at least one of employment history information, education history information, land ownership information, or medical history information for the user. Additional information that can be part of the economic identity is illustrated, e.g., in
In process block 306, the identity information of a user can be used in the authorization. For example, when the identity information includes an image of the person, this image can be used in authorizing the transactions. Process block 306 can include a multi-stage verification approach as discussed, for example, with respect to
In some examples, businesses and institutions that establish accounts with the blockchain-based economic identity and transaction platform can access (e.g., through a web application or client-side software) a user interface to allow the business or institution to view economic identities for other users who give permission. In some examples, users can control which categories of information are included in their economic identity and/or can authorize read access of only certain categories in response to a request. For example, if a user is interested in taking out a loan from an entity, and the entity requests the user's economic identity, the user may choose not to share medical history information or other information that may not be relevant to the entity.
In some examples, an encryption service, such as encryption service 120 of
In process block 408, a unique identifier associated with the person is established based on the encrypted identity information. In some examples, process block 408 includes designating the encrypted identity information as the unique identifier. Other unique identifiers can also be used. In some examples, various actions may be taken to validate or authenticate a user's identity prior to establishing the unique identifier. As an example, various third-party sources of information can be used to verify the user's identity.
Method 400 can also further comprise associating, with the unique identifier, at least one of medical, employment, educational, property ownership, or economic information (e.g., linked accounts, transaction history, etc.) corresponding to the person and storing the medical, employment, educational, property ownership, or economic information in the blockchain. Some or all of the associated information can be used to form the economic identity of the person, as discussed, for example, above with respect to
First stage authentication data is generated in process block 504. First stage authentication data can be, for example, a code including numbers and/or letters. The first stage authentication data can be provided to the recipient and can serve as an indication to the recipient that a benefit is available to be claimed. For example, the recipient can receive a text message, email message, or application alert including: a statement that a benefit is available to be claimed; a code (e.g., a 9-digit numeric, alphanumeric, or letter code); and instructions to complete the verification process in order to claim the benefit. In some examples, the first stage authentication data is only valid for a certain amount of time (one hour, one day, one week, etc.). In some examples, the first stage authentication data is valid long enough to allow for the recipient to claim the benefit according to the recipient's schedule (e.g., until after a work shift, trip, or other event is completed).
In process block 506, an indication is received that the first stage authentication data has been provided to a verification agent. A verification agent is a user in the blockchain-based identity and transaction platform who serves in a third-party role. The verification agent can communicate with the platform through, for example, verification agent computing device 126 of
In process block 508, the first stage authentication data is verified. For example, the code provided in the initial message can be compared against the code entered by the agent (or in some examples, entered by the person). Verification of the first stage authentication data provides some confirmation that the person who provided the code to the agent is the actual recipient.
In process block 510, identity information for the recipient is retrieved from one or more blocks in a blockchain after verifying the first stage authentication data and is transmitted (e.g., to the verification agent). The identity information can be used to further confirm that the person is the actual recipient. Continuing the refugee example above, after the verification agent has entered the code provided by the person, and the code has been verified (e.g., by a remote server computer) as a match to the code provided in the original message, an image of the recipient can be provided to the agent. The image can be the image used to create the recipient's profile (and the image that is encrypted and stored in the blockchain). If the image appears to be the same person as the person in the presence of the agent who provided the code, then the agent confirms an identity match.
In some examples, facial recognition software is used to determine whether there is a match between the person and the image. In some examples, fingerprint or eye pattern matching can be performed instead of comparing the appearance of the person to an image. In examples in which an automated terminal is used, instructions can be presented for the person to place their finger, eye, or face on a scanner or in front of a camera, and comparison of the identity information can be performed by software.
In some examples, rather than affirmatively confirming an identity match, the agent can refuse to complete any further actions (e.g., entering a second code) if the person in the agent's presence does not appear to match the image (or other biometric information).
Identity information, such as an image, is stored in an encrypted form in the blockchain. In examples in which an encryption service is used, software associated with the platform can make a call to the encryption service and request a temporary token to decrypt the image. The token can be valid for a limited time, and by providing the token back to the encryption service, the decrypted image (or fingerprint, eye pattern, etc.) is provided to the software (or to the verification agent computing device). The software then provides or otherwise makes available the decrypted image to the verification agent.
Second stage authentication data (e.g., a second code such as a 6-digit code) is generated and transmitted in process block 512. In some examples, the second stage authentication data is transmitted at substantially the same time as the identity information is transmitted. In some examples, the second stage authentication data is transmitted after a match is confirmed between biometric information and the person in the presence of the verification agent. The blockchain-based identity and transaction platform account of the recipient can include an associated phone number or other information identifying a mobile device such as a smart phone, feature phone, or tablet. In some examples, the second stage authentication data is sent to the mobile device associated with the recipient, and if the person in the presence of the verification agent is in possession of the associated mobile device, then the person can provide the second code to the verification agent. In some examples, the second stage authentication data is sent in a similar manner to the first stage authentication data (e.g., via email message, application alert, or text message).
In process block 514, an indication is received that the second stage authentication data has been provided to the verification agent. The second stage authentication data and the code provided to the verification agent can then be compared to verify that the code provided to the verification agent is correct. After verifying the second stage authentication data, it is determined in process block 516 that the person in the presence of the verification agent is the actual recipient, and the transaction is authorized. In the refugee example, authorization can include the food packet being given to the refugee. In funds transfer examples, authorization can include physically handing money to the person or initiating/completing a transfer between accounts. In some examples, the blockchain-based identity and transaction platform can hold funds as an intermediary and disburse them to a linked account when the transaction is authorized. In other examples, the platform does not actually access or have control over the funds.
The multi-stage verification provides several layers of security and requires that a person attempting to claim a benefit must have the first stage authentication data (e.g., first code) associated with the benefit as well as the second stage authentication data (e.g., second code) sent after verification of the first code. Further, in some examples, the agent explicitly confirms that the person has a physical appearance or other characteristic corresponding to the actual recipient or implicitly confirms an identity match by entering the second code. Further security can be implemented by requiring that the person in the agent's presence be in physical possession of the intended recipient's mobile device. In some examples, one or more of these security layers may be omitted. In one particular example, fewer layers of security are used for lower value transactions (e.g., funds transfers under $100), and additional layers of security are provided for higher value transactions. Additional layers of security beyond those discussed with respect to
In some examples, process block 510 is omitted (and an image or biometric data of the intended recipient is not transmitted), and after the first stage authentication data is verified, second stage authentication data is generated and transmitted to the recipient's account and/or mobile device.
Method 500 can also include storing a record of the transaction (e.g., including particular transaction components, location data, technical device/network details, etc.) in the blockchain in association with the recipient and/or sender. In some examples, only authorized and completed transactions are stored. The information stored can include the recipient, the sender, and characteristics of the transaction (e.g., funds transfer, aid assistance, etc.). The first and second stage authentication data can be associated with both the recipient and the transaction.
A sender initiates a funds transfer to a recipient who has an account with the blockchain-based identity and transaction platform. The recipient has a trust relationship with the sender. In interaction 602, the details of the initiated transaction, including the recipient, type of transaction (funds transfer), and amount to transfer are submitted by the sender to a server(s) computer implementing aspects of the blockchain-based identity and transaction platform, such as server computer(s) 106 of
The recipient then provides the first code to a verification agent in interaction 606. In some examples, the code can be shown to a person serving as an agent, who then enters the code into a verification agent computing device. In other examples, the recipient can enter the code into an automated terminal or kiosk. In still other examples, the verification agent computing device can be remote, and the recipient either forwards the message to the verification agent or enters the code via a web interface.
The verification agent enters and sends the code provided by the recipient back to the server(s) in interaction 608. The server(s) verify that the code matches the first code sent in interaction 604. In some examples, if there is not a match, the transaction is cancelled. In other examples, a limited number of code entry attempts are permitted before the transaction is cancelled.
After determining that the first code matches, identity information (e.g. an image of the intended recipient) is used to further confirm that the person who provided the first code is the intended recipient. In interaction 610, the server(s) send the recipient's unique identifier (e.g., the public key corresponding to the recipient's encrypted image or other identity information) to the blockchain to retrieve the recipient's encrypted image. In transaction 612, the encrypted image is provided to the server(s). In examples in which encryption is handled by the server(s), the image is then decrypted. In examples in which an encryption service is used, such as
In examples in which the verification agent is a person interacting with a verification agent computing device, the decrypted image of the intended recipient can be presented on the verification agent computing device, and the agent can make a judgment as to whether the person in the agent's presence appears to be the same as the person pictured in the image. In examples in which the verification agent is an automated terminal, the person can present their face to allow the terminal to create an image and then compare that image to the decrypted image of the intended recipient using facial recognition or other image recognition software. In examples in which the verification agent is remote (whether a remote person or a remote computing device), the person can be instructed to take a selfie and send the selfie to a verification agent/upload the selfie. The selfie and the decrypted image can then be compared either by the remote person or by software executing on the remote computing device. In interaction 620, an identity match confirmation is provided back to the server(s) by the verification agent computing device indicating that the person appears to be the intended recipient.
At this point, both the first code and an image of the intended recipient have been used to verify that the person attempting to claim the funds is the intended recipient. It is possible that a person who is not the intended recipient could have intercepted the first code (e.g., by accessing the initial message while using the intended recipient's phone), and it is further possible that the person intercepting the first code resembles the intended recipient sufficiently to convince a verification agent (or facial recognition software). Although such situations would likely be rare, an additional layer of security can also be used—sending a second code to the recipient.
In interaction 622, the server(s) send second stage authentication data (e.g., a second code), which can be time-limited, to the recipient's account (e.g., via text message, email message, or application alert). The recipient then provides the second code back to the verification agent in interaction 624. The verification agent sends the provided second code back to the server(s) in interaction 626, and if the code matches the second code sent to the recipient's account in interaction 622, then the transaction is authorized. In examples in which the second code is time-limited, the transaction is only authorized if executed within predetermined time constraints. The funds transfer can then be completed or authorized. In examples in which the benefit is a physical item or service such as a food packet or medical aid (e.g., a vaccine, medication, supplement, procedure, etc.), then the server(s) communicate to the verification agent that release of the item/service is authorized. In a refugee context, for example, a food packet can then be handed or automatically dispensed to the recipient. The completed transaction is then stored in the blockchain in association with the recipient and/or the sender.
In some examples, interaction 620, in which the identity match confirmation is provided back to the server(s), is not performed affirmatively, but a match is implicitly confirmed when the verification agent enters the second code in interaction 626. In such examples, after the verification agent has provided the first code to the server(s) in interaction 608, and the first code has been verified by the server(s) (and after the retrieval/decryption interactions 610, 612, 614, and 616, if performed) the second code is sent to the recipient account in interaction 622 at substantially the same time as the decrypted image is sent to the verification agent in interaction 618. When the person in the verification agent's presence provides the second code to the agent in interaction 624, the agent can refuse to enter the second code (or cancel the transaction) if the person in the agent's presence does not appear to match the decrypted image. Such an example is illustrated in
In various examples, the verification agent can be implemented on the server(s) or eliminated. For example: the first code provided in interaction 604 can be provided directly back to the server(s); the decrypted image can be retained at the server(s) and not be sent to the verification agent and instead a person can provide a selfie which is compared to the decrypted image at the server(s); and the second code received at the recipient's mobile device can be provided directly back to the server(s) (e.g., by entering/uploading the code through an interface on the mobile device).
A sender initiates a funds transfer to a recipient who has an account with the blockchain-based identity and transaction platform. The recipient has a trust relationship with the sender. In interaction 702, the details of the initiated transaction, including the recipient, type of transaction (funds transfer), and amount to transfer are submitted by the sender to a server(s) computer implementing aspects of the blockchain-based identity and transaction platform, such as server computer(s) 106 of
The recipient then provides the 9-digit code to a verification agent in interaction 706. In some examples, the code can be shown to a person serving as an agent, who then enters the code into a verification agent computing device. In other examples, the recipient can enter the code into an automated terminal or kiosk. In still other examples, the verification agent computing device can be remote, and the recipient either forwards the message to the verification agent or enters the code via a web interface.
The verification agent enters and sends the 9-digit code provided by the recipient back to the server(s) in interaction 708. The server(s) verify that the code matches the code sent in interaction 704. In some examples, if the code does not match, the transaction is cancelled. In other examples, a limited number of code entry attempts are permitted before the transaction is cancelled.
After determining that the 9-digit code matches, identity information (e.g. an image of the intended recipient) is used to further confirm that the person who provided the 9-digit code is the intended recipient. In interaction 710, the server(s) send the recipient's unique identifier (e.g., the public key corresponding to the recipient's encrypted image or other identity information) to the blockchain to retrieve the recipient's encrypted image. In transaction 712, the encrypted image is provided to the server(s). In examples in which encryption is handled by the server(s), the image is then decrypted. In examples in which an encryption service is used, such as
In interaction 720, the server(s) send second stage authentication data (e.g., a 6-digit code), which can be time-limited, to the recipient's mobile device (or in some examples, to the user's account). Interaction 720 can occur substantially at the same time as the decrypted image is transmitted to the verification agent in interaction 718. The recipient then provides the 6-digit code back to the verification agent in interaction 722. If the decrypted image provided to the agent in interaction 718 does not appear to match the person in the agent's presence, the verification agent can refuse to enter the 6-digit code or otherwise cancel the transaction. This serves as an extra layer of security to ensure that the person attempting to claim a benefit is the intended recipient. If the decrypted image does match the person in the agent's presence, then the verification agent sends the provided 6-digit code back to the server(s) in interaction 724, and if the code matches the 6-digit code sent to the recipient's mobile device in interaction 720, then the transaction is authorized.
In examples in which the 6-digit code is time-limited, the transaction is only authorized if executed within predetermined time constraints. The funds transfer can then be completed or authorized. In examples in which the benefit is a physical item or service such as a food packet or medical aid (e.g., a vaccine, medication, supplement, procedure, etc.), then the server(s) communicate to the verification agent that release of the item/service is authorized. In a refugee context, for example, a food packet can then be handed or automatically dispensed to the recipient. The completed transaction is then stored in the blockchain in association with the recipient and/or the sender.
In
In user interface 1600 of
In some examples, after transfer found user interface 1702 is displayed, the agent confirms that the displayed image resembles a person in the agent's presence, and then second-stage authentication data 1802 is generated and sent to the recipient's mobile device and is displayed in user interface 1800. In some examples, confirmation of the person's identity is either not performed or is implicit in the verification agent entering a second code. In some examples, second-stage authentication data 1802 is shown in user interface 1800 at the time second-stage authentication data 1802 is sent to the mobile device of the recipient, and the agent can verify whether or not the person in the agent's presence has provided the correct code. In other examples, the agent is not provided the code, and the agent simply enters what the person in the agent's presence provides, and verification of the code is determined by the platform.
Once the recipient receives the second-stage authentication data 1802 and provides this code to the agent, the agent can either authorize the transaction if there is a match or enter the provided code, and if a match is determined, the agent is notified that the transaction is authorized and/or has been completed, as is shown in transfer complete user interface 1902 of user interface 1900 of
In user interface 2000 of
The information associated with a user can be stored in different blocks, either pre-defined by the application or created ad-hoc by the user, in the blockchain. To retrieve this information, for example when a user logs in to a web application and the user's profile is presented, a “projection” can be created by searching the blockchain for information associated with the user and retrieving that information. For example, a search based on the user's unique identifier can be performed.
Projections can be created for all information associated with a user's account and/or for different “personas.” A user can establish different personas within the user's account that can each include different types and amounts of information. For example, a user can create a “health” persona that includes identity information and health information (vaccine records, medical records, etc.) but not employment information, education information, etc. that is unrelated to the user's health. Similarly, a user can create an education persona that includes identity and education information but not health, property ownership information, etc. that is unrelated to the user's education.
The user can also establish different logins/login approaches to access the different personas. In some examples, logins of varying levels of security are available, and more secure login approaches (e.g., multi-factor authentication, thumb/fingerprints, etc.) can be used for information the user considers to be more sensitive or confidential, and less secure login approaches (e.g., pin, password, passphrase, etc.) can be used for information the user considers less sensitive or confidential. In some examples, a same login is used for some or all personas. Logins can be used, for example, when a user wishes to share a particular persona with another user or entity.
Example personas are illustrated in
Education persona 2708 can include grade reports, transcripts, or other information and can be accessible, for example, via passphrase 2710. Utility persona 2712 can include various utility records, including service addresses, payments, usage history, etc. and can be accessed by PIN code 2714. A general or default persona can also be created. The persona approach allows a user to control what information the user is releasing to various institutions and other users and to maintain other data as private. Although particular access methods (thumbprint 2706, passphrase 2710, and PIN code 2714) are shown in
The secure storage capabilities of the blockchain have been discussed herein, but the blockchain can also be capable of executing code, which can be implemented as “smart contracts,” which are programs that are stored on the blockchain and executed on the blockchain.
Example Computing SystemsWith reference to
A computing system may have additional features. For example, the computing system 2400 includes storage 2440, one or more input devices 2450, one or more output devices 2460, and one or more communication connections 2470. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system 2400. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system 2400, and coordinates activities of the components of the computing system 2400.
The tangible storage 2440 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing system 2400. The storage 2440 stores instructions for the software 2480 implementing one or more innovations described herein.
The input device(s) 2450 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system 2400. For video encoding, the input device(s) 2450 may be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing system 2400. The output device(s) 2460 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system 2400.
The communication connection(s) 2470 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.
The innovations can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing system on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing system.
The terms “system” and “device” are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on a type of computing system or computing device. In general, a computing system or computing device can be local or distributed, and can include any combination of special-purpose hardware and/or general-purpose hardware with software implementing the functionality described herein.
For the sake of presentation, the detailed description uses terms like “determine” and “use” to describe computer operations in a computing system. These terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.
Example Mobile DevicesThe illustrated mobile device 2500 can include a controller or processor 2510 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 2512 can control the allocation and usage of the components 2502 and support for one or more application programs 2514. The application programs can include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application. Functionality 2513 for accessing an application store can also be used for acquiring and updating application programs 2514.
The illustrated mobile device 200 can include memory 2520. Memory 2520 can include non-removable memory 2522 and/or removable memory 2524. The non-removable memory 2522 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 2524 can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory storage technologies, such as “smart cards.” The memory 2520 can be used for storing data and/or code for running the operating system 2512 and the applications 2514. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. The memory 2520 can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment. The memory 2520 can store instructions or code implementing enrollment engine 116 and transaction engine 118 of
The mobile device 2500 can support one or more input devices 2530, such as a touchscreen 2532, microphone 2534, camera 2536, physical keyboard 2538 and/or trackball 2540 and one or more output devices 2550, such as a speaker 2552 and a display 2554. Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touchscreen 2532 and display 2554 can be combined in a single input/output device.
The input devices 2530 can include a Natural User Interface (NUI). An NUI is any interface technology that enables a user to interact with a device in a “natural” manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls, and the like. Examples of NUI methods include those relying on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence. Other examples of a NUI include motion gesture detection using accelerometers/gyroscopes, facial recognition, 3D displays, head, eye , and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface, as well as technologies for sensing brain activity using electric field sensing electrodes (EEG and related methods). Thus, in one specific example, the operating system 2512 or applications 2514 can comprise speech-recognition software as part of a voice user interface that allows a user to operate the device 2500 via voice commands Further, the device 2500 can comprise input devices and software that allows for user interaction via a user's spatial gestures, such as detecting and interpreting gestures to provide input to a gaming application.
A wireless modem 2560 can be coupled to an antenna (not shown) and can support two-way communications between the processor 2510 and external devices, as is well understood in the art. The modem 2560 is shown generically and can include a cellular modem for communicating with the mobile communication network 2504 and/or other radio-based modems (e.g., Bluetooth 2564 or Wi-Fi 2562). The wireless modem 2560 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).
The mobile device can further include at least one input/output port 2580, a power supply 2582, a satellite navigation system receiver 2584, such as a Global Positioning System (GPS) receiver, an accelerometer 2586, and/or a physical connector 2590, which can be a USB port, IEEE 1394 (FireWire) port, and/or RS-232 port. The illustrated components 2502 are not required or all-inclusive, as any components can be deleted and other components can be added.
Example Cloud-Supported EnvironmentsIn example environment 2600, the cloud 2610 provides services for connected devices 2630, 2640, 2650 with a variety of screen capabilities. Connected device 2630 represents a device with a computer screen 2635 (e.g., a mid-size screen). For example, connected device 2630 could be a personal computer such as desktop computer, laptop, notebook, netbook, or the like. Connected device 2640 represents a device with a mobile device screen 2645 (e.g., a small size screen). For example, connected device 2640 could be a mobile phone, smart phone, personal digital assistant, tablet computer, and the like. Connected device 2650 represents a device with a large screen 2655. For example, connected device 2650 could be a television screen (e.g., a smart television) or another device connected to a television (e.g., a set-top box or gaming console) or the like. One or more of the connected devices 2630, 2640, 2650 can include touchscreen capabilities. Touchscreens can accept input in different ways. For example, capacitive touchscreens detect touch input when an object (e.g., a fingertip or stylus) distorts or interrupts an electrical current running across the surface. As another example, touchscreens can use optical sensors to detect touch input when beams from the optical sensors are interrupted. Physical contact with the surface of the screen is not necessary for input to be detected by some touchscreens. Devices without screen capabilities also can be used in example environment 2600. For example, the cloud 2610 can provide services for one or more computers (e.g., server computers) without displays.
Services can be provided by the cloud 2610 through service providers 2620, or through other providers of online services (not depicted). For example, cloud services can be customized to the screen size, display capability, and/or touchscreen capability of a particular connected device (e.g., connected devices 2630, 2640, 2650).
In example environment 2600, the cloud 2610 provides the technologies and solutions described herein to the various connected devices 2630, 2640, 2650 using, at least in part, the service providers 2620. For example, the service providers 2620 can provide a centralized solution for various cloud-based services. The service providers 2620 can manage service subscriptions for users and/or devices (e.g., for the connected devices 2630, 2640, 2650 and/or their respective users). Some or all of the functionality of enrollment engine 2660 and transaction engine 2662, which can be similar to enrollment engine 116 and transaction engine 118 of
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.
Any of the disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media and executed on a computing device (e.g., any available computing device, including smart phones or other mobile devices that include computing hardware). Computer-readable storage media are any available tangible media that can be accessed within a computing environment (e.g., one or more optical media discs such as DVD or CD, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as flash memory or hard drives)). By way of example and with reference to
Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable storage media. The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.
For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.
Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub combinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.
The technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology may be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be taken as a limitation on the scope of the disclosed technology.
Claims
1. A computing device comprising one or more processors and one or more computer-readable storage media having stored therein computer-executable instructions for causing the one or more processors, when programmed thereby, to perform operations comprising:
- encrypting identity information for a person and storing the encrypted identity information in a blockchain as part of enrolling the person as a user in a blockchain-based economic identity and transaction platform;
- storing, in the blockchain, records of trust relationships between the user and other users; and
- authorizing transactions between the user and one or more of the other users with whom the user has formed a trust relationship; and
- storing records of the transactions in the blockchain, wherein at least some of the transactions and identity information contribute to an economic identity of the user.
2. The computing device of claim 1, wherein the operations further comprise providing the economic identity of the user to a requesting party, wherein the requesting party is another user in the blockchain-based economic identity and transaction platform.
3. The computing device of claim 1, wherein the economic identity further comprises at least one of employment history information, education history information, property ownership information, or medical history information for the user, and wherein the at least one of employment history information, education history information, property ownership information, or medical history information is stored in the blockchain.
4. The computing device of claim 1, wherein the identity information comprises an image of the person, and wherein the identity information further comprises at least one of a name, government identifier, fingerprint, or eye pattern information.
5. The computing device of claim 4, wherein the image of the person is used in authorizing the transactions.
6. (canceled)
7. The computing device of claim 1, wherein the transactions comprise at least one of a funds transfer, medical treatment authorization, or food assistance authorization.
8. A computer-implemented method comprising:
- receiving identity information for a person;
- encrypting the identity information;
- storing the encrypted identity information in a block of a blockchain; and
- establishing, based on the encrypted identity information, a unique identifier associated with the person.
9. The method of claim 8, wherein the identity information comprises an image of the person, and wherein the identity information further comprises at least one of a name, government identifier, fingerprint or eye pattern information.
10. (canceled)
11. The method of claim 8, wherein establishing the unique identifier comprises designating the encrypted identity information as the unique identifier.
12. The method of claim 8, further comprising associating, with the unique identifier, at least one of medical, employment, educational, property ownership, or economic information corresponding to the person and storing the medical, employment, educational, property ownership, or economic information in the blockchain.
13. The method of claim 12, wherein at least one of economic or employment information is stored in the blockchain in association with the unique identifier and represents an economic identity of the person.
14. The method of claim 8, further comprising storing, in association with the unique identifier and in the blockchain, transaction information representing one or more transactions between the person and one or more additional parties.
15. The method of claim 8, further comprising storing, in association with the unique identifier and in the blockchain, a record of a trust relationship between the person and one or more additional parties.
16. One or more computer-readable memory or storage devices having stored thereon computer-executable instructions to cause a computer system, when programmed thereby, to perform operations comprising:
- identifying a recipient for a transaction;
- generating first stage authentication data;
- receiving an indication that the first stage authentication data has been provided to a verification agent;
- verifying the first stage authentication data;
- after verifying the first stage authentication data, retrieving identity information for the recipient from one or more blocks in a blockchain and transmitting the identity information;
- generating and transmitting second stage authentication data;
- receiving an indication that the second stage authentication data has been provided to the verification agent; and
- after verifying the second stage authentication data, determining that the person in the presence of the verification agent is the recipient and authorizing the transaction.
17. The one or more computer-readable memory or storage devices of claim 16, wherein the identity information comprises at least one of an image of the recipient, a fingerprint of the recipient, or eye pattern information for the recipient.
18. The one or more computer-readable memory or storage devices of claim 16, wherein the retrieved identity information is encrypted, and wherein the operations further comprise:
- requesting a decryption token;
- receiving a decryption token; and
- decrypting the identity information for the recipient, wherein the transmitted identity information is decrypted identity information.
19. The one or more computer-readable memory or storage devices of claim 16, wherein the operations further comprise storing a record of the transaction in the blockchain in association with the recipient.
20. The one or more computer-readable memory or storage devices of claim 16, wherein the operations further comprise, prior to generating the first stage authentication data: establishing a record of a trust relationship between the recipient and a sender; and storing the record of the trust relationship in the blockchain.
21. The one or more computer-readable memory or storage devices of claim 16, wherein the transaction is at least one of a funds transfer, medical authorization, or food assistance authorization.
22. The one or more computer-readable memory or storage devices of claim 16, wherein the first and second stage authentication data are codes comprising at least one of numbers or letters.
Type: Application
Filed: Sep 30, 2016
Publication Date: Oct 4, 2018
Applicant: BanQu, Inc. (Minnetonka, MN)
Inventors: Ashish Gadnis (Austin, TX), Jeffrey A. Keiser (Minnetonka, MN), Michael Linton (St. Paul, MN), Stanislav Natalenko (Kharkiv)
Application Number: 15/767,969