U.S. patent application number 15/767969 was filed with the patent office on 2018-10-04 for blockchain-based identity and transaction platform.
This patent application is currently assigned to BanQu, Inc.. The applicant listed for this patent is BanQu, Inc.. Invention is credited to Ashish Gadnis, Jeffrey A. Keiser, Michael Linton, Stanislav Natalenko.
Application Number | 20180285879 15/767969 |
Document ID | / |
Family ID | 58517745 |
Filed Date | 2018-10-04 |
United States Patent
Application |
20180285879 |
Kind Code |
A1 |
Gadnis; Ashish ; et
al. |
October 4, 2018 |
BLOCKCHAIN-BASED IDENTITY AND TRANSACTION PLATFORM
Abstract
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.
Inventors: |
Gadnis; Ashish; (Austin,
TX) ; Keiser; Jeffrey A.; (Minnetonka, MN) ;
Linton; Michael; (St. Paul, MN) ; Natalenko;
Stanislav; (Kharkiv, UA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BanQu, Inc. |
Minnetonka |
MN |
US |
|
|
Assignee: |
BanQu, Inc.
Minnetonka
MN
|
Family ID: |
58517745 |
Appl. No.: |
15/767969 |
Filed: |
September 30, 2016 |
PCT Filed: |
September 30, 2016 |
PCT NO: |
PCT/US2016/054920 |
371 Date: |
April 12, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62495574 |
Oct 17, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 16/1805 20190101;
H04L 2209/56 20130101; H04L 9/0825 20130101; G06Q 20/385 20130101;
G06Q 20/3223 20130101; G06Q 20/38215 20130101; G06Q 2220/00
20130101; G06Q 30/02 20130101; H04L 9/3231 20130101; G06Q 20/40145
20130101; H04L 2209/38 20130101; G06Q 30/06 20130101; G06Q 20/425
20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06Q 30/06 20060101 G06Q030/06; G06F 17/30 20060101
G06F017/30; H04L 9/32 20060101 H04L009/32; H04L 9/08 20060101
H04L009/08 |
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.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] 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.
BACKGROUND
[0002] In 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.
SUMMARY
[0003] Examples 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.
[0004] 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.
[0005] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 is a block diagram of an example environment in which
a blockchain-based identity and transaction platform can be
implemented.
[0007] FIG. 2 illustrates an example economic identity.
[0008] FIG. 3 is a diagram illustrating an example method of
authorizing transactions in a blockchain-based identity and
transaction platform.
[0009] FIG. 4 is a diagram illustrating an example method of
enrolling a person as a user in a blockchain-based identity and
transaction platform.
[0010] FIG. 5 is a diagram illustrating an example method of
authorizing transactions in a blockchain-based identity and
transaction platform using a multi-stage verification process.
[0011] FIG. 6 illustrates interactions in an example transaction
authorization.
[0012] FIG. 7 illustrates interactions in an example transaction
authorization in which a second code is sent to a user's mobile
device.
[0013] FIGS. 8-23 illustrate example user interfaces for
interacting with a blockchain-based identity and transaction
platform.
[0014] FIG. 24 is a diagram of an example computing system in which
some described embodiments can be implemented.
[0015] FIG. 25 is an example mobile device that can be used in
conjunction with the technologies described herein.
[0016] FIG. 26 is an example cloud-supported environment that can
be used in conjunction with the technologies described herein.
[0017] FIG. 27 is a diagram of example personas based on a secured,
blockchain-based economic identity.
DETAILED DESCRIPTION
[0018] 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.
[0019] 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 FIGS. 1-27.
[0020] FIG. 1 illustrates an example environment 100 in which a
blockchain-based identity and transaction platform can be
implemented. As used herein, "blockchain" refers to a distributed
storage platform and network in which individual "blocks" are
connected in a chain. Each block is linked to the previous block in
the blockchain by, for example, including a hash of the previous
block as a "proof of work." Various hash functions, including
functions in the Secure Hash Algorithm (SHA)-1 or -2 families, such
as SHA-256, can be used to perform a one-way hash. For a one-way
hash, it is generally considered to be impossible or impractical to
generate the input (the "message") to the hash function based on
the output (the "message digest" or "digest") of the hash
function.
[0021] 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.
[0022] 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 FIGS. 8-23. Enrollment engine 116 is
configured to create a unique identifier for the person based on
the uploaded identity information. The identity information can be
encrypted, either by computing device(s) 106 or through an
encryption service 120. Encryption services are discussed in more
detail below. The encrypted identity information can then be stored
in a blockchain 122. Blockchain 122 is implemented on a group of
distributed computing devices 124 that are accessible via network
108. Additional enrollment examples are discussed in detail below
with respect, e.g., to FIG. 4.
[0023] 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 FIGS. 5, 6, and 7.
[0024] Identity information, transaction information, and other
information for a user that is stored in blockchain 122 can form an
economic identity of the user. FIG. 2 illustrates an example
economic identity 200. Economic identity 200 includes 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. Although economic identity 200 is shown as including
each of the preceding particular categories of information, example
economic identities can also include only some of these categories
of information and/or include additional categories of information.
Identity information 202 can include, for example, an image of a
user, a name, government identifier(s), and/or fingerprint or eye
pattern information of the user (or other biometric information of
the user). Linked accounts 204 can include, for example, banking,
investment, or credit accounts associated with the user. Employment
history 206 can include employer names and/or addresses, job
titles, dates of employment, salaries, and/or other employment
information.
[0025] 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.
[0026] 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.).
[0027] Economic identity 200 is stored in blockchain 220. Blocks
222, 224, 226, and 228 of blockchain 220 are shown in FIG. 2, but
any number of blocks can form blockchain 220. As indicated by the
arrows between blocks 222, 224, 226, and 228, the respective blocks
are linked to the previous block in the blockchain. This link can
be in the form of, for example, a hash of the previous block.
[0028] FIG. 3 illustrates a method 300 of authorizing transactions
in a blockchain-based identity and transaction platform. In process
block 302, identity information for a person is encrypted, and the
encrypted identity information is stored in a blockchain as part of
enrolling the user in the blockchain-based economic identity and
transaction platform. The identity information can include, for
example, an image of the person. The identity information can
alternatively or additionally include at least one of a name,
government identifier(s), fingerprint, or eye pattern
information.
[0029] 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.
[0030] 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 FIG. 2.
[0031] 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 FIGS. 5 and 6. In some examples, method 300 further
comprises providing the economic identity of the user to a
requesting party, where the requesting party is a user in the
blockchain-based economic identity and transaction platform. As an
example, a user may wish to establish a line of credit, purchase
equipment, or perform another transaction, and prior to initiating
or authorizing the transaction, the requesting party can request
the user's economic identity (e.g., through a client-side software
application) in order to evaluate the user as a potential debtor,
purchaser, employee, etc.
[0032] 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.
[0033] FIG. 4 illustrates a method 400 of enrolling a person as a
user in a blockchain-based identity and transaction platform. In
process block 402, identity information for a person is received.
Identity information can include an image of the person (e.g., a
selfie) and/or a name, government identifier(s), fingerprint, or
eye pattern information. In process block 404, the identity
information is encrypted. Various encryption techniques can be
used. In process block 406, the encrypted identity information is
stored in a block of a blockchain. In some examples, a single
encryption key can be used and can be stored as, for example, an
environmental variable on a computer storage device associated with
the blockchain-based identity and transaction platform.
[0034] In some examples, an encryption service, such as encryption
service 120 of FIG. 1, can be used. The encryption service can
create and manage encryption keys. In such an example, software
implementing aspects of the blockchain-based identity and
transaction platform can make a call to the encryption service to
encrypt the identity information received in process block 402. The
service creates the keys, retains a private key, and provides both
a public key and the encrypted identity information to the software
that made the call to the service. The encryption service can be a
web service.
[0035] 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.
[0036] 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 FIG. 2. Transaction information representing one or more
transactions between the person and one or more additional parties,
as well as trust relationships between the person and additional
parties, can also be stored in the blockchain in association with
the unique identifier or other information indicating the user
(such as the public key, even if the public key is not used as the
unique identifier).
[0037] FIG. 5 illustrates a method 500 of verifying a transaction
in a blockchain-based identity and transaction platform. In process
block 502, a recipient for a transaction is identified. A recipient
is, for example, the person or user who will receive a funds
transfer, receive medical assistance, receive food assistance, etc.
In some examples, a recipient can be any person, and in some
examples, the recipient is limited to a user of the
blockchain-based identity and transaction platform. In some
examples in which the recipient is not a user of the platform, the
person can be sent a link or instructions for enrolling as a user
in the platform after the transaction is initiated, and the
transaction does not proceed until the person enrolls and
establishes a trust relationship with the sender. In such examples,
the recipient is a prospective recipient until the person enrolls
and establishes the trust relationship.
[0038] 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).
[0039] 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 FIG. 1. As
an example, in a refugee context, the verification agent can be a
member of a United Nations or other entity that is an assistance
provider, and when a refugee receives (e.g., via a text on the
refugee's mobile phone) a message and code indicating that a food
assistance packet is available, the refugee takes the code to the
verification agent, who can be located at a kiosk, building, or
other facility. The verification agent then enters the code through
a software application user interface. "Verification agent" as used
herein may also refer to a verification agent computing device. In
some examples, the person can enter a code into an automated
terminal.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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).
[0044] 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.
[0045] 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).
[0046] 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.
[0047] 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 FIG. 5 are also
possible.
[0048] 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.
[0049] 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.
[0050] FIG. 6 is an interaction diagram 600 illustrating a
transaction verification process such as that described with
respect to FIG. 5. FIG. 6 is discussed with reference to a specific
example in which the transaction is a funds transfer, the first
stage authentication data is a first code, the identity information
is an image, and the second stage authentication data is a second
code. A similar set of interactions applies to other scenarios,
such as authorization of food or medical assistance.
[0051] 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 FIG. 1. In
interaction 604, first stage authentication data (a first code) is
sent to the recipient's account. The first code can be sent, for
example, as a text message or email. The first code can also be
sent as an account alert that appears in a web interface (or in
client-side software running on a computing device or mobile
device). The message can also provide instructions to the recipient
for completing the transaction to claim the funds.
[0052] 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.
[0053] 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.
[0054] 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 FIG. 6, the server(s) interact with the encryption
service to decrypt the image. In FIG. 6, this is done through use
of a decryption token. The server(s) send a token request to the
encryption service in interaction 614, and a decryption token is
provided back to the server(s) in interaction 616. The decryption
token allows the server(s) to decrypt the image and provide the
decrypted image to the verification agent in interaction 618. In
some examples, the decrypted image can be sent directly from the
encryption service to the verification agent. In certain instances
when other forms of biometrics (such as fingerprints, iris
patterns, or facial recognition) are used, the decryption steps can
include matching a physically presented fingerprint, iris, or face
to stored biometric data (e.g., biometric data encrypted and stored
on the blockchain).
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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 FIG. 7.
[0059] 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).
[0060] FIG. 7 is an interaction diagram 700 illustrating a
transaction verification process such as that described with
respect to FIGS. 5 and 6. In FIG. 7, the transaction is a funds
transfer, the first stage authentication data is a 9-digit code,
the identity information is an image, and the second stage
authentication data is a 6-digit code. As with FIG. 6, a similar
set of interactions can apply to other scenarios, such as
authorization of food or medical assistance.
[0061] 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 FIG. 1. In
interaction 704, first stage authentication data (a 9-digit code)
is sent to the recipient's account. The 9-digit code can be sent,
for example, as a text message or email. The code can also be sent
as an account alert that appears in a web interface (or client-side
software running on a computing device or mobile device). The
message can also provide instructions to the recipient for
completing the transaction to claim the funds.
[0062] 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.
[0063] 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.
[0064] 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 FIGS. 6 and 7, the server(s) interact with the
encryption service to decrypt the image. In FIG. 7, this is done
through use of a decryption token. The server(s) send a token
request to the encryption service in interaction 714, and a
decryption token is provided back to the server(s) in interaction
716. The decryption token allows the server(s) to decrypt the image
and provide the decrypted image to the verification agent in
interaction 718.
[0065] 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.
[0066] 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.
[0067] FIG. 8 illustrates a user interface 800 that provides a
number of different options to sign in to a blockchain-based
identity and transaction platform, including option 802 to sign in
using a Facebook account, option 804 to sign in using a Twitter
account, option 806 to sign in using a Google account, and option
808 to sign in using a phone number or email address. User
interface 800, as well as the user interfaces discussed with
reference to FIGS. 9-23, can be presented in a web application or
client-side software executing on a client computing device.
[0068] In FIG. 9, user interface 900 displays an email sign in user
interface. FIG. 10 illustrates a user interface 1000 in which the
user has signed in. User interface 1000 includes a "Transfers" tab
1002, a "Connections" tab 1004, and a user tab 1006 (user "Ashish
Gadnis" shown). Transfers tab 1002 can display all or recent
transfers to or from the signed-in user made through the
blockchain-based identity and transaction platform. Connections tab
1004, the active tab in user interface 1000, shows connections with
whom the user has established a trust relationship.
[0069] FIG. 11 shows a user interface 1100 in which a user tab
1102, which can be similar to user tab 1006, is active. User
interface 1100 displays profile information for the user, including
the user's platform profile 1104, which can include login/password
information, birth date, text-capable mobile phone number, email
address, physical address, or other information. The profile
information can also include passport information 1106, driver
license information 1108, U.S. social security information 1110,
and non-U.S. identity information 1112. Profile information can
also include additional information such as visa or other status
information. Some or all of the profile information can also be
part of the user's economic identity.
[0070] FIG. 12 illustrates a user interface 1200 through which a
user can invite another person to either form a trust relationship
or to establish an account as a user of the platform and form a
trust relationship. User interface 1200 is presented while a
connections tab 1202 is active. Invitation information 1204 can
include the invitee's name, email address, text-capable mobile
phone number, country, address, and/or other information. Once
invitation information 1204 is entered, a message can be sent to
the invitee, and the invitee can be prompted to establish an
account and/or establish a trust relationship with the user.
[0071] FIG. 13 illustrates a user interface 1300 showing a number
of previous transactions 1302 displayed under a "My Transfers"
heading. Previous transactions 1302 include funds transfers both to
and from the user. In some examples, the user is able to filter the
types of transactions displayed (e.g., show only funds transfers,
show food and medical assistance authorization, etc.). FIG. 14
shows a user interface 1400 in which a detailed transaction view is
displayed. Transaction 1402 includes a message "Health," as well as
first authentication data "Secret Key Code: B33-99C-861," and
instructions to provide the code to the local agent to receive the
transfer. Transaction 1404 includes similarly includes a message,
code, and instructions.
[0072] FIG. 15 illustrates a user interface 1500 in which a
platform administrator is logged in, as indicated by the "BanQu
Administrator" tab 1502. The administrator can view additional
information and perform additional actions. For example, "Agent"
tab 1504 allows the administrator to act as an agent, and
"Blockchain" tab 1506 allows the administrator to access a
blockchain view of a transaction, as illustrated in FIG. 20.
[0073] In user interface 1600 of FIG. 16, agent tab 1602 is active,
and a transfer lookup interface 1604 is presented. Transfers can be
looked up by a key code (e.g., a 9-digit code) and/or additional
information such as recipient name, email address, or phone number.
User interface 1600 can be, for example, the interface through
which an agent enters first authentication data (such as a 9-digit
code). In user interface 1700 of FIG. 17, a key code has been
entered, and a transfer found interface 1702 is presented that
includes identity information 1704 for the recipient (an image)
along with the "PhotoETag" 1706, which is a private key, enabled
for one-time usage, that verifies the photo and the receiver's
identity. In some examples, transfer lookup interface 1604 is what
a verification agent can use during a transaction verification
process as discussed, for example, with respect to FIGS. 5, 6, and
7.
[0074] FIG. 18 illustrates a user interface 1800 similar to user
interface 1700 of FIG. 17, but additional information is present
(indicating a later stage in verification), including second-stage
authentication data 1802, shown as a 6-digit code, that has been
sent to a recipient's mobile device or account and presented to and
entered by a verification agent. In some examples, user interface
1700 of FIG. 17 and user interface 1800 of FIG. 18 are what an
agent sees after the first-stage authentication data is determined
to be a match (FIG. 17) and after second stage authentication data
has been entered by the agent (FIG. 18). The image (identity
information 1704) shown in transfer found user interface 1702 can
be the decrypted identity information provided to the agent. For
example, a verification agent who has entered a 9-digit code is
presented with the image of the intended recipient and can (in some
examples) confirm that a person in the agent's presence appears to
match the image. Confirmation can either be an explicit step, or
confirmation can be implicit if the agent enters a second code (or
other second stage authentication data that was generated after
verification of the first stage authentication data) provided by
the person in the agent's presence.
[0075] 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.
[0076] 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
FIG. 19.
[0077] In user interface 2000 of FIG. 20, blockchain tab 2002 is
active. User interface 2000 includes a dashboard view that includes
a current block number 2004 in the blockchain where the completed
transaction is stored. The dashboard view also includes a browser
session information 2006 that indicates how many browsers are
currently directly accessing the blockchain at the current point in
time and blockchain peer information 2008 that indicates how many
blockchain nodes are being accessed in order to display the
platform blockchain transactions. Pending view 2010 illustrates the
data stored in the current block, including the transaction.
[0078] FIG. 21 shows a user interface 2100 in which a pending view
2102 includes a transaction-by-transaction breakdown of what is
stored in the current block. Encrypted and hashed data are stored
on the blockchain. Each transaction, and the different information
describing the transaction, becomes part of the immutable blocks
that are stored on the permissioned blockchain (for example, an
Ethereum blockchain). The stored information representing ,
including the first stage authentication data ("token"), amount
transferred ("amount"), as well as sender, receiver, and agent
information.
[0079] FIG. 22 illustrates a user interface 2200 of an email
program in which a message 2202 is sent to the recipient indicating
that first-stage authentication data has been provided and
including a "Cash Out confirmation Code" (second-stage
authentication data) that is to be provided to the verification
agent to complete the transaction. In some examples, the
second-stage authentication data is sent to a mobile device
associated with the recipient, and in other examples, such as that
shown in FIG. 22, the second-stage authentication data is sent via
email, or message alert sent through a software application
associated with the platform.
[0080] FIG. 23 illustrates a user interface 2300 illustrating a
transfer complete email confirmation 2302 provided to the sender
after successful completion of a transfer.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] Example personas are illustrated in FIG. 27. A secured,
blockchain-based economic identity 2702 (which can be similar to
economic identity 200 of FIG. 2, for example) is stored on one or
more blocks in a blockchain. Different personas include or access
different aspects of economic identity 2702. For example, a health
persona 2704, accessible by a thumbprint login 2706, can include a
user's medical records or vaccination history and allows a user to
visit a medical clinic or medical aid station that has an account
in the blockchain-based identity and transaction platform, enter
contact information and/or a username, and provide a thumbprint to
allow the medical clinic to have access to the user's health
records and other information included in health persona 2704. A
medical clinic can also have a pre-defined persona established
which can access the user's information (with the user's
permission).
[0085] 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 FIG. 27 as associated with
particular personas, various different access methods can be
selected or assigned to any persona.
[0086] 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 Systems
[0087] FIG. 24 depicts a generalized example of a suitable
computing system 2400 in which the described innovations may be
implemented. The computing system 2400 is not intended to suggest
any limitation as to scope of use or functionality, as the
innovations may be implemented in diverse general-purpose or
special-purpose computing systems.
[0088] With reference to FIG. 24, the computing system 2400
includes one or more processing units 2410, 2415 and memory 2420,
2425. In FIG. 24, this basic configuration 2430 is included within
a dashed line. The processing units 2410, 2415 execute
computer-executable instructions. A processing unit can be a
general-purpose central processing unit (CPU), processor in an
application-specific integrated circuit (ASIC), or any other type
of processor. In a multi-processing system, multiple processing
units execute computer-executable instructions to increase
processing power. For example, FIG. 24 shows a central processing
unit 2410 as well as a graphics processing unit or co-processing
unit 2415. The tangible memory 2420, 2425 may be volatile memory
(e.g., registers, cache, RAM), non-volatile memory (e.g., ROM,
EEPROM, flash memory, etc.), or some combination of the two,
accessible by the processing unit(s). The memory 2420, 2425 stores
software 2480 implementing one or more innovations described
herein, in the form of computer-executable instructions suitable
for execution by the processing unit(s). For example, memory 2420
can store software 2480 implementing enrollment engine 116 and
transaction engine 118 of FIG. 1.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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 Devices
[0096] FIG. 25 is a system diagram depicting an example mobile
device 2500 including a variety of optional hardware and software
components, shown generally at 2502. Any components 2502 in the
mobile device can communicate with any other component, although
not all connections are shown, for ease of illustration. The mobile
device can be any of a variety of computing devices (e.g., cell
phone, smartphone, handheld computer, Personal Digital Assistant
(PDA), etc.) and can allow wireless two-way communications with one
or more mobile communications networks 2504, such as a cellular,
satellite, or other network.
[0097] The 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.
[0098] 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 FIG. 1.
[0099] 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.
[0100] 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.
[0101] 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).
[0102] 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 Environments
[0103] FIG. 26 illustrates a generalized example of a suitable
cloud-supported environment 2600 in which described embodiments,
techniques, and technologies may be implemented. In the example
environment 2600, various types of services (e.g., computing
services) are provided by a cloud 2610. For example, the cloud 2610
can comprise a collection of computing devices, which may be
located centrally or distributed, that provide cloud-based services
to various types of users and devices connected via a network such
as the Internet. The implementation environment 2600 can be used in
different ways to accomplish computing tasks. For example, some
tasks (e.g., processing user input and presenting a user interface)
can be performed on local computing devices (e.g., connected
devices 2630, 2640, 2650) while other tasks (e.g., storage of data
to be used in subsequent processing) can be performed in the cloud
2610.
[0104] In 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.
[0105] 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).
[0106] 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 FIG. 1, can be implemented in the cloud 2610.
Example Implementations
[0107] 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.
[0108] 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 FIG. 24,
computer-readable storage media include memory 2420 and 2425, and
storage 2440. By way of example and with reference to FIG. 25,
computer-readable storage media include memory and storage 2520,
2522, and 2524. The term computer-readable storage media does not
include signals and carrier waves. In addition, the term
computer-readable storage media does not include communication
connections (e.g., 2470, 2560, 2562, and 2564).
[0109] 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.
[0110] 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.
[0111] 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.
[0112] 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.
[0113] 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.
* * * * *