U.S. patent application number 14/421013 was filed with the patent office on 2015-08-20 for system and method for mobile or web-based payment/credential process.
This patent application is currently assigned to Tango Mobile, LLC. The applicant listed for this patent is Tango Mobile, LLC. Invention is credited to Himalesh Cherukuvada Kumar.
Application Number | 20150235215 14/421013 |
Document ID | / |
Family ID | 50101453 |
Filed Date | 2015-08-20 |
United States Patent
Application |
20150235215 |
Kind Code |
A1 |
Kumar; Himalesh
Cherukuvada |
August 20, 2015 |
System and Method for Mobile or Web-Based Payment/Credential
Process
Abstract
The present disclosure describes systems and methods directed
towards a highly secure and intelligent, end to end provisioning,
authentication, and transaction system which creates and/or
consolidates user data for a unified profile for the user (e.g., a
person, place, organization, object, etc.) to allow for the safe,
secure, and verifiable exchange of information.
Inventors: |
Kumar; Himalesh Cherukuvada;
(Marina Del Rey, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Tango Mobile, LLC |
Marina Del Rey |
CA |
US |
|
|
Assignee: |
Tango Mobile, LLC
Marina Del Rey
CA
|
Family ID: |
50101453 |
Appl. No.: |
14/421013 |
Filed: |
August 13, 2013 |
PCT Filed: |
August 13, 2013 |
PCT NO: |
PCT/US2013/054769 |
371 Date: |
February 11, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61779237 |
Mar 13, 2013 |
|
|
|
61753561 |
Jan 17, 2013 |
|
|
|
61683954 |
Aug 16, 2012 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
H04L 9/3226 20130101;
G06Q 20/322 20130101; G06F 21/44 20130101; G06Q 20/20 20130101;
G06F 2221/2115 20130101; G06F 21/31 20130101; H04L 63/083 20130101;
H04L 63/105 20130101; H04L 63/08 20130101; G06Q 20/425 20130101;
G06Q 20/4014 20130101; G06Q 20/3821 20130101; G06Q 20/12 20130101;
G06Q 20/4012 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; H04L 29/06 20060101 H04L029/06 |
Claims
1. A method comprising: receiving credential data at a web server
hosting a website, the credential data including a user identifier
and a password of a user; transmitting, from the web server to an
authentication server, the credential data, a payment source
identifier, a third party identifier of an entity, a web portal
identifier associated with the website, and a transaction type
identifier corresponding to a requested transaction type; at the
authentication server, authenticating the password and the web
portal identifier based on the user identifier and the third party
identifier; transmitting a confirmation request from the
authentication server to a device used by the user; receiving a
confirmation message from the user; and performing a transaction
corresponding to the requested transaction type for the user using
a payment source corresponding to the payment source
identifier.
2. The method of claim 1, further comprising: transmitting a
transaction identifier from the web server to the authentication
server; and authenticating the transaction identifier at the
authentication server.
3. The method of claim 1, wherein the confirmation message includes
a personal identification code of the user, the method further
including authenticating the personal identification code at the
authentication server.
4. The method of claim 1, wherein the user is prompted to enter the
personal identification code responsive to a determination that a
transaction amount for the requested transaction exceeds a
predetermined threshold.
5. The method of claim 1, wherein the user is prompted to enter the
personal identification code responsive to a determination that the
device is currently in one of a predetermined set of locations.
6. The method of claim 1, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of an entity, wherein the electronic message includes a
request for data; at the authentication server, receiving the
requested data from the entity computer; wherein the transaction is
performed for the user based on the received data.
7. The method of claim 1, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of the entity, wherein the electronic message includes a
request for authorization of the requested transaction; at the
authentication server, receiving an electronic authorization from
the entity computer; wherein the transaction is performed for the
user responsive to the received authorization from the entity
computer.
8. The method of claim 1, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of the entity, wherein the electronic message includes
updated transaction data for storage at the entity computer.
9. The method of claim 1, further comprising: transmitting a first
electronic message from the authentication server to an entity
computer of the entity, wherein the first electronic message
includes a notification of the requested transaction; at the
authentication server, receiving a second electronic message from
the entity computer, wherein the second electronic message includes
update data; and transmitting the update data to the device used by
the user.
10. A method comprising: receiving credential data at an
application executing on a mobile device of a user, the credential
data including a user identifier and a password of the user;
transmitting, from the mobile device to an authentication server,
the credential data, a payment source identifier, a third party
identifier of an entity, a device identifier associated with the
device, and a transaction type identifier corresponding to a
requested transaction type; at the authentication server,
authenticating the password and the device identifier based on the
user identifier and the third party identifier; transmitting a
confirmation request from the authentication server to the mobile
device; receiving a confirmation from the user; and performing a
transaction for the user corresponding to the requested transaction
type.
11. The method of claim 10, further comprising: transmitting a
transaction identifier from the mobile device to the authentication
server; and authenticating the transaction identifier at the
authentication server.
12. The method of claim 10, wherein the confirmation message
includes a personal identification code of the user, the method
further including authenticating the personal identification code
at the authentication server.
13. The method of claim 10, wherein the user is prompted to enter
the personal identification code responsive to a determination that
a transaction amount for the requested transaction exceeds a
predetermined threshold.
14. The method of claim 10, wherein the user is prompted to enter
the personal identification code responsive to a determination that
the device is currently in one of a predetermined set of
locations.
15. The method of claim 10, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of an entity, wherein the electronic message includes a
request for data; at the authentication server, receiving the
requested data from the entity computer; wherein the transaction is
performed for the user based on the received data.
16. The method of claim 10, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of an entity, wherein the electronic message includes a
request for authorization of the requested transaction; at the
authentication server, receiving an electronic authorization from
the entity computer; wherein the transaction is performed for the
user responsive to the received authorization from the entity
computer.
17. The method of claim 10, further comprising: transmitting an
electronic message from the authentication server to an entity
computer of an entity, wherein the electronic message includes
updated transaction data for storage at the entity computer.
18. The method of claim 10, further comprising: transmitting a
first electronic message from the authentication server to an
entity computer of an entity, wherein the first electronic message
includes a notification of the requested transaction; at the
authentication server, receiving a second electronic message from
the entity computer, wherein the second electronic message includes
update data; and transmitting the update data to the mobile
device.
19. A method comprising: receiving, at an authentication server, a
user identifier, a password of a user, a payment source identifier,
a third party identifier of an entity, a login source identifier,
and a transaction type identifier corresponding to a requested
transaction type; authenticating the password and the login source
identifier based on the user identifier and the third party
identifier; transmitting a confirmation request from the
authentication server to a device used by the user; receiving from
the user a confirmation message including a personal identification
code; authenticating the personal identification code at the
authentication server; and performing a transaction corresponding
to the requested transaction type for the user using a payment
source corresponding to the payment source identifier.
20. The method of claim 19, further comprising: receiving the user
identifier and the password at a web server hosting a website; and
transmitting the user identifier and the password from the web
server to the authentication server; wherein the login source
identifier is associated with the website.
21. The method of claim 19, wherein the device used by the user is
a mobile device, the method further comprising: receiving the user
identifier and the password at an application executing on the
mobile device; and transmitting the user identifier and the
password from the mobile device to the authentication server;
wherein the login source identifier is associated with the mobile
device.
Description
RELATED AND CO-PENDING APPLICATIONS
[0001] This application is a U.S. national stage application of and
claims priority to PCT application Serial Number PCT/US2013/054769
entitled "System and Method for Mobile or Web-Based
Payment/Credential Process" filed 13 Aug. 2013 which claims
priority to each of the following co-pending U.S. provisional
applications: "System and Method for a Secure Mobile Application",
Ser. No. 61/683,954 filed 16 Aug. 2012; "System and Method for a
Secure Transactional Platform", Ser. No. 61/753,561 filed 17 Jan.
2013; and "System and Method for Mobile Credentials and
Transactions", Ser. No. 61/779,237 filed 13 Mar. 2013, the entirety
of each of the above applications is hereby incorporated herein by
reference.
[0002] This application hereby incorporates by reference the
entirety of each of the following two applications which are filed
concurrently herewith: U.S. national stage application Ser. No.
______ filed 11 Feb. 2015 entitled "System and Method for Secure
Transactions" which is a U.S. national stage application of PCT
application Serial Number PCT/US2013/054759 filed 13 Aug. 2013
entitled "System and Method for Secure Transactions"; and U.S.
national stage application Ser. No. ______ filed 11 Feb. 2015
entitled "System and Method for Electronic Credentials" which is a
U.S. national stage application of PCT application Serial Number
PCT/US2013/054766 filed 13 Aug. 2013 entitled "System and Method
for Electronic Credentials".
BACKGROUND
[0003] Current systems and methods incorporating traditional
identification documents and/or credentials (referred to herein as,
"ID") include a set of defined relationships between certain
persons/entities that delineate particular expectations amongst the
certain persons/entities. These expectations may include, but are
not limited to, such things as identification, verification,
access, rights, privileges, payments, debits, credits, etc. between
at least two of the owner of the ID, the issuer of the ID, and one
who is inspecting the ID to verify the owner's proper
status/qualifications/certification.
[0004] As a simple example, a traditional ID such as a driver's
license is issued by an appropriate state department of motor
vehicles ("DMV") to a driver once the driver, typically, has met
the DMV's requirements. Therefore, the DMV is satisfied of the
driver's identity and qualifications and the driver is presented
with the license to use as a token of the DMV's confidence in the
driver's identity and qualifications. The driver may then use the
driver's license to identify himself to a third party to verify,
for example, the driver's age with the expectation that the
verifying party will accept the license and accept that the
information contained thereon is not false. The verifying party,
upon inspection of the driver's license, will acknowledge that the
driver's license is legitimate and that the driver proffering the
license is the age represented by the birth date on the driver's
license. Thus, the DMV, the driver, and the verifying party can
satisfactorily rely upon the token (driver's license) as an
authoritative and true representation of the information carried
thereon. While the traditional document token system is useful for
a limited set of conventional transaction types, the traditional
document token system is becoming outmoded in the digital
information age and cannot be effectively used for novel secure
transactions and other innovative purposes, such as, for example,
transactions that require user identification from a distance.
[0005] Current electronic ID systems and methods employ essentially
the same type of process as that described above with an ID issuer,
and ID owner, and an ID verifying party. The only difference is
that the ID is electronic rather than a physical token. Due to the
spate of computer hacking, identification theft, and other
electronic scams, the current electronic ID systems are vulnerable
to attack and unauthorized manipulation. Thus, current electronic
ID systems and methods suffer similar limitations as the
traditional document token systems and cannot be effectively used
for more innovative purposes. Furthermore, current electronic ID
systems have suffered a concomitant loss of consumer confidence in
the accuracy and reliability of the electronic IDs.
[0006] Accordingly, there is a need for secure, reliable, and
accurate electronic ID systems and methods that meet current
consumer needs as well as the demands of novel identification
techniques, secure transactions, and usages for the future.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a block diagram of a secure data/credential
storage system according to an embodiment of the present subject
matter.
[0008] FIG. 2 is a functional block diagram for a process for
performing a transaction using a user's credentials from a website
not associated with the secure data/credential storage system
according to an embodiment of the present subject matter.
[0009] FIG. 3 is a flow chart for a process for performing a
transaction from a website not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter.
[0010] FIG. 4 is a flow chart for a process for performing a
transaction, including a transaction identifier, from a website not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter.
[0011] FIG. 5 is a flow chart for a process for performing a
transaction, including a request for data, from a website not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter.
[0012] FIG. 6 is a flow chart for a process for performing a
transaction, including an electronic authorization, from a website
not associated with the secure data/credential storage system
according to an embodiment of the present subject matter.
[0013] FIG. 7 is a flow chart for a process for performing a
transaction, including updated transaction data, from a website not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter.
[0014] FIG. 8 is a flow chart for a process for performing a
transaction, including notification of a requested transaction,
from a website not associated with the secure data/credential
storage system according to an embodiment of the present subject
matter.
[0015] FIG. 9 is a functional block diagram for a process for
performing a transaction using a user's credentials from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject
matter.
[0016] FIG. 10 is a flow chart for a process for performing a
transaction from a mobile application not associated with the
secure data/credential storage system according to an embodiment of
the present subject matter.
[0017] FIG. 11 is a flow chart for a process for performing a
transaction, including a transaction identifier, from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject
matter.
[0018] FIG. 12 is a flow chart for a process for performing a
transaction, including a request for data, from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject
matter.
[0019] FIG. 13 is a flow chart for a process for performing a
transaction, including an authorization, from a mobile application
not associated with the secure data/credential storage system
according to an embodiment of the present subject matter.
[0020] FIG. 14 is a flow chart for a process for performing a
transaction, including a updated transaction data, from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject
matter.
[0021] FIG. 15 is a flow chart for a process for performing a
transaction, including a notification of the requested transaction,
from a mobile application not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter.
[0022] FIG. 16 is a flow chart for a process for performing a
transaction, including a personal identification code, from a
website and/or mobile application not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter.
[0023] FIG. 17 is a flow chart for a process for performing a
transaction, including a login source identifier, from a website
not associated with the secure data/credential storage system
according to an embodiment of the present subject matter.
[0024] FIG. 18 is a flow chart for a process for performing a
transaction, including a login source identified, from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject
matter.
DETAILED DESCRIPTION
[0025] The following description of the present subject matter is
provided as an enabling teaching of the present subject matter and
its best, currently-known embodiment. Those skilled in the art will
recognize that many changes can be made to the embodiments
described herein while still obtaining the beneficial results of
the present subject matter. It will also be apparent that for some
embodiments, some of the desired benefits of the present subject
matter can be obtained by selecting some of the features of the
present subject matter without utilizing other features.
Accordingly, those skilled in the art will recognize that many
modifications and adaptations of the present subject matter are
possible and may even be desirable in certain circumstances and are
part of the present subject matter. Thus, the following description
is provided as illustrative of the principles of the present
subject matter and not in limitation thereof and may include
modification thereto and permutations thereof. While the following
exemplary discussion of embodiments of the present subject matter
may be directed towards or reference specific systems and methods
of electronic identification and secure transactions, it is to be
understood that the discussion is not intended to limit the scope
of the present subject matter in any way and that the principles
presented are equally applicable to other systems and method of
electronic identification and secure transactions.
[0026] Those skilled in the art will further appreciate that many
modifications to the exemplary embodiments described herein are
possible without departing from the spirit and scope of the present
subject matter. Thus, the description is not intended and should
not be construed to be limited to the examples given but should be
granted the full breadth of protection afforded by the appended
claims and equivalents thereto.
[0027] With reference to the figures where like elements have been
given like numerical designations to facilitate an understanding of
the present subject matter, various embodiments of a system and
method for secure transactions are described.
[0028] Embodiments of the present system and method described
herein are directed towards a highly secure and intelligent, end to
end provisioning and authentication system (sometimes referred to
herein as the "Tango Secure Environment" or "TSE"). The TSE is
typically organized, set up, initiated, and operated by a TSE
Authority. Embodiments of the system and method are useful to
achieve, among other things, the following tasks: interactions with
people, places, organizations, and/or objects to verify their
identity/credentials accurately; create and/or consolidate data for
a unified profile for the person, place, organization, and/or
object; allow for safe/accurate exchange of information between
profiles for use within the system and with other systems; and
increase current levels of verification and security.
[0029] In certain embodiments, the present disclosure incorporates
different levels of data that are absorbed and/or used/passed
through during an exchange or verification of data. For example,
the present disclosure uses Identifiers that are composed of data
that is collected and/or created by the system and stored in the
users' profile on the system database (sometimes referred to herein
as the "Tango Secure Database" or "TSDB") to accurately identify a
user to fulfill a system process. The Identifiers may be derived
and/or tokenized from user-unique information and may be created by
using a hash function or other one-way function as is known in the
art. Identifiers may include confidential data of the user such as,
but not limited to, information from one or more of the following:
[0030] Issued IDs--physical IDs issued by another party such as
driver's license, passport, library cards, etc.; [0031]
Non-Physical IDs--virtual credentials such as username/password,
email, PIN, etc.; [0032] Financial Data--financial credentials and
account information for credit card, rewards card, bank account,
gift card, etc.; [0033] Keys--physical and/or virtual credentials
utilized by a third party to grant access; [0034] Other--all other
data known and unknown which may uniquely identify a user
independently or collectively such as social security number, date
of birth, home address, picture, biometric data, etc.
[0035] Since an electronic ID typically not only encompasses one ID
and/or Credential to one user, and since the issuer of the
ID/Credential may not want to manage electronic dissemination of
those IDs, and since there must be a provisioning of the
ID(s)/Credential(s) to the user, there must be a trusted service
manager (e.g., the "TSE Authority") to act as the "provisioner" and
manager of all ID/Credentials of one user. This creates a Universal
Electronic ID system that allows the user to securely manage all
ID/Credentials they may own, under one electronic ID account. The
account manager (e.g., TSE Authority) would act as a manager to
securely store and/or provision any of the user's approved
electronic devices(s) and/or third party electronic device(s) with
the ID/Credentials, as well as be the clearing house between the
credential issuer, the user, and any party that is requesting the
legitimacy, authority, and/or sovereignty of the ID/Credential.
[0036] It is important to note that, as used herein, using an
electronic ID/Credential encompasses more than simply placing an ID
on a user's mobile device and/or any electronic system, or issuing
an ID for placement onto a user's mobile device and/or any
electronic system, but rather embodiments of the disclosed system
and method include a complex connection and communication of
electronic systems coming together to display sovereign issuance of
ID/Credentials, prove Identity, ownership, and/or authority for a
person, place, or thing. In doing so, the outcome allows the
person, place, or thing that proved/verified its identity and/or
ownership to engage and benefit from services and/or products of
some kind offered by the party that requested the user's proof of
identity and/or ownership.
[0037] In certain embodiments, functions of the disclosed system
and method may been seen as somewhat similar to that of an issued
or created identification of a person, place, or thing by a valid
issuer such as, but not limited to, drivers licenses, passports
etc. However, the novel electronic ID/credential system and methods
discussed herein are not only an electronic version of the same
static physical ID document(s) which holds some of the same data,
but also possess dynamic properties due to the inherent and/or
designed-in technological capabilities. Some of these properties
are, but not limited to, securely provisioning the IDs remotely in
various ways, renewing an ID/credential, remotely issuing and/or
revoking an ID/credential, etc.
[0038] In addition to physical ID document(s), in certain
embodiments, electronic ID/credentials also act as "digital keys"
that give the correct credentials of a person, place, or thing to
allow access to various access-controlled environments such as, but
not limited to, home, cars, buildings, etc. Moreover, electronic
ID/credential systems may also encompass credentials that may or
may not be physical in nature, but also allow a person, place or
thing to access protected products and services such as websites,
e-mail accounts, bank account(s), computers, etc.
[0039] The electronic ID/credential system described herein not
only includes physical/non-tangible IDs and credentials, it also
stores any data of any kind associated to a particular person,
place, or thing. In certain embodiments, the novel system and
method stores tokens and other data that, although may not reveal
an identification of a person, may reveal an identification of a
person's accounts. The novel system and method may also store
payment accounts such as, but not limited to, credit cards, charge
cards, gift cards, bank accounts, PayPal accounts, etc., as well as
other closed-looped or open-looped payment schemes that identify a
user's account(s).
[0040] In certain embodiments, the present disclosure uses Response
Data which includes all data types that may be given by the TSE to
fulfill a TSE process. Response Data may include information from
one or more of the following: [0041] Actual Data--actual data
includes that data which would simply be the pass through of
unaltered Identifiers from the TSDB to necessary connections;
[0042] Universal ID (also referred to as User Unique ID or User
Universal ID)--this is a TSE-created unique code (e.g., number);
[0043] Tokenized Data--this includes Actual Data input into the
system and manipulated to put the Actual Data in a series of
indexes to thereby create a unique number that does not contain the
Actual Data; [0044] Derivative Data--this includes Actual Data
input into the system and manipulated to put Actual Data through a
series of algorithms (e.g., hashing algorithms that take the Actual
Data and Universal ID as inputs) to create new Identifiers; [0045]
Certificate ID--this contains information regarding a particular
transaction which is currently taking place or has taken place in
order to provision a certain data set with the appropriate entity,
it is provided to certain entities to provide a higher level of
authentication;
[0046] In certain embodiments, Actual Data (e.g., the actual
ID/credential of a user and/or the user's data) may not be held by
the user's mobile device. Depending on the specific need and the
user's desire, all actual data can be accessed and sent to the
user's mobile device when needed, with proper authentication. This
data may or may not be encrypted on the mobile device. If the user
wishes, the Actual Data can be given to a third party in any manner
the user sees fit. The TSE Authority may be the manager and digital
issuer of the data, however the user is the owner of the data and
the TSE is designed only to assist the user in handling the data
and in making the process of storage and provisioning the user's
data safe, secure, verifiable, and fast.
[0047] In certain embodiments, each user will be given a unique
Electronic/Digital ID identifier, the Universal ID, once the user
registers with the TSE. This unique Identifier will be linked to
the user's account(s). All ID/Credential and user data (e.g.,
Actual Data) will be linked to the unique ID identifier for that
user and their account. As a non-limiting example, if a third party
requests certain data from the user, the third party will connect
to the TSDB and provide the TSDB with its third party ID, the
user's unique Electronic/Digital ID, and the type of data being
requested. If the transaction is approved and authorized, the TSDB
will pull up the requested data and complete the transaction with
the third party.
[0048] In certain embodiments, the TSDB can also tokenize and/or
encrypt some or all ID/Credential data on the TSDB and/or the TSE
and/or the user's mobile device. In doing so, the TSDB and/or TSE
will create a token and/or public key(s) which will identify the
user and the Actual Data on the TSDB and/or TSE. This may be
accomplished by taking the Actual Data and tokenizing the Actual
data by placing it into an algorithm (e.g., hashing algorithm).
[0049] In certain embodiments, the TSDB and/or TSE may also create
and/or issue Derivative Data, where Derivative Data is a derivative
of the ID/Credential(s) (i.e., not a token based system as
described above). As a non-limiting example, Derivative Data is
created by taking the Actual Data and the User Universal ID and
placing both into an algorithm (e.g., hashing algorithm). One
purpose of creating Derivative Data, among other reasons, would be
to use the ID/Credentials while at the same time protecting the
sensitive root data of the ID/Credential itself. If needed, the
TSDB and/or TSE can create an unlimited number of unique derivative
IDs for the same ID/Credential (which may be referred to herein as
Multiple Unique Derivative IDs). As a non-limiting example,
Multiple Unique Derivative IDs may be created by taking the Actual
Data, the User Universal ID and the third party ID (which is
typically unique for each separate third party) and placing each
into an algorithm. Thus, a unique derivative ID is created for each
separate third party based on the same root data (e.g., the same
Actual Data and User Universal ID). In this way (and only if
needed), all approved third parties will be given a unique
derivative ID number of the same user ID/Credential saved on the
TSDB and/or TSE. By doing so, the Multiple Unique Derivative ID
will display the user, ID/Credential Data, and the third party to
whom the Multiple Unique Derivative ID was issued. Therefore, each
third party is provided with a unique derivative ID for the same
ID/Credential of the user, and, consequently, third parties cannot
share user data. This scheme also prevents authorized parties from
deciphering user data without first acquiring approval from the
TSDB and/or TSE. Moreover, if necessary a particular multiple
derivative ID can be connected to the specific third party.
[0050] In certain embodiments, in addition to the user unique ID
identifier, tokens, derivative, Multiple Unique Derivative ID, and
the actual ID/Credential data on the TSDB and/or the TSE, the TSDB
and/or TSE (specifically, in an embodiment, the TIS) may issue an
Electronic/Digital Issuance Certificate ID. This Electronic/Digital
Issuance Certificate ID is not part of the root data itself (e.g.,
a driver's license number, or token of the driver's license created
by the TSE and/or TSDB), but rather the Electronic/Digital Issuance
Certificate ID is a unique identifying code/number that was created
to provided authenticity and reference of the root ID/Credential
documentation from the issuer, trusted digital manager, and/or user
account to which it was provisioned as well as to the user. This
number is given to prove that the TSE and/or TSDB has provisioned
and/or created a digital copy and can be viewed as a digital finger
print of sorts of the ID/Credentials and user data.
[0051] In certain embodiments, the present disclosure uses one or
more of various Response Types. Response Types are the responses
the TSE will provide to entities. The requester of information will
also have a TSE profile which contains stored procedures allowed
for that requester by the TSE. Response Types may include
information from one or more of the following:
[0052] Authorizations--this includes a set of responses containing
a Yes/No and/or Approval/Denial-type response;
[0053] Release of Data--this is a response which includes Response
Data, multiple Response Data may be packaged together and sent to a
requester. This Response Type may be referred to as a Level
Request.
[0054] As a non-limiting example, with user and TSDB and/or TSE
approval, the user and/or a third party may request that along
with, or instead of, the data being transferred a "confirmation
response" communication be sent. The confirmation response may
include, for example, Actual Data, Token, User Universal ID,
Derivative, Multiple Unique Derivative ID, and/or
Electronic/Digital Issuance Certificate ID as well as a simple Yes
or No, or Approval or Denial indication (or binary equivalents such
as `0` or `1`). In certain embodiments, the confirmation response
only includes a Yes/No or Approval/Denial indication. Additionally,
a Level Request may optionally be included.
[0055] As a non-limiting example of a Yes/No or Approval/Denial
confirmation response, a Yes/No request and/or confirmation
response will not send any user data (e.g., actual data, tokenized
data, derivative data, etc.) but rather will only contain a simple
Yes or No to a question about user data. As a non-limiting example,
a third party data request may be "Verify the user is OLDER than 21
years, YES OR NO." The confirmation response sent to the third
party will not send the user's actual birth date, but rather the
confirmation response will only include a "YES" or "NO" response to
the question. Similarly, a third party can request an "Approval or
Denial" of a requested transaction, such as, but not limited to, a
credit card sale. The confirmation response sent to the third party
would simply include "APPROVED" or "DENIED".
[0056] Another Response Type mentioned above is a Level Request.
The TSDB and/or TSE may organize into sets ("level sets") certain
data groups. In some cases, these level sets are comprised of data
that are, e.g., most requested, user authorized, user defined, etc.
Such data may be organized into level sets corresponding to, for
example, respective security/permission settings or respective
functionality capabilities. A third party can request that a level
set of data be sent to the third party when a user connects and
approves the data transfer with the third party. This approval can
be accomplished on a mobile device, website, terminal, POS (point
of sale) device, electronic device, etc.
[0057] Tango Secure Environment ("TSE")
[0058] The hardware makeup, data, intelligent system, and process
flows/stored procedures are included in the TSE. In some
embodiments, the TSE includes:
[0059] Tango Secure Database ("TSDB")--In certain embodiments, the
TSDB is a collection of databases which contain Identifiers of an
entity, sometimes referred to herein as a "Tango Profile" for the
identified entity. Data is separated by security levels and
requires the Tango Intelligent System ("TIS") to properly locate
the data.
[0060] Tango Intelligence System ("TIS")--In certain embodiments,
the TIS is a set of stored procedures and processes which analyze
the data and requests received and communicates with the TSDB to
retrieve necessary Identifiers to fulfill a response. TIS is
responsible for the creation and communication of Response Data. In
certain embodiments, Response Data is never stored on the TSDB. The
TIS may also take in Identifiers of requesters in order to analyze
and approve the requests sent by the requesters. Highest level
authentication may require manual approval and will not be
proceeded further by the TIS.
[0061] The TIS, in certain embodiments, controls and securely
stores procedures and user data (via the TSS and/or DSS (discussed
below), and in some cases the TSDB) to interact with a user's
approved data device (mobile or otherwise) as well as other
approved electronic hardware/devices and software/systems, and
third parties through the TSDB. These third parties may include,
but are not limited to, credit/debit card companies/issuers, banks,
mobile apps, government credential-issuing organizations, etc.
Moreover, the TIS can create ID/Credentials for users to be used by
approved third parties. The TIS does not connect directly to any
outside approved or non-approved parties/devices/databases/third
parties, etc. Rather, any transaction connecting to TIS, TSS,
and/or DSS must interface through the TSDB. This architecture
prevents any direct public access to any data stored in the TIS.
Thus, the disclosed novel system and method is designed to protect
users from identity fraud and security vulnerabilities that are
prevalent today and projected to continue to be common in the
future.
[0062] All data for a user belongs to that user and the user
themselves control the transmission of the data. The TIS and/or TSE
system does not control the data dissemination, rather the TIS
and/or TSE system assists the user to securely employ the user's
data as the user directs.
[0063] Tango Secure Storage ("TSS")--In certain embodiments, the
TSS, which is controlled by the TIS, is a secure data storage
device or software module to protect user's information and allow
the user and/or owner of the stored information to be the sole
controllers of the stored information.
[0064] Data Secure Storage ("DSS")--In certain embodiments, the
DSS, which is controlled by the TIS, is used separately or in
conjunction with the TSS to securely store user/owner data.
[0065] Network Connection--In certain embodiments, processes such
as, but not limited to, APIs (i.e., application program interfaces)
and web services will be utilized from entities connecting to the
TSE via a network connection. Requests and the extracted
information will be sent to the TSE for processing and
confirmation. Higher level authentication will require real-time
connection with the TSE.
[0066] Firmware--In certain embodiments, entities not utilizing
real-time connection and network connection will utilize firmware
provided by the TSE Authority to fulfill processing and
confirmation. The firmware will utilize stored procedures and
Response Data provided by the TSE.
[0067] Provisioning
[0068] Provisioning, as used herein, includes the process of
preparing and equipping an apparatus, such as, but not limited to,
a secure storage system including a database, to allow the secure
storage system to provide information and/or services to a user
and/or third party.
[0069] The TSE Authority takes steps to provision data and
entities. If the data has been successfully verified, it will be
marked as so in the TSDB. The TSDB may still store unverified data
and this unverified data will be utilized if a requester accepts
unverified data.
[0070] In certain embodiments, the TSE provisions data in the
following ways/scenarios:
[0071] Third Party Data Provisioning--In certain embodiments, the
TSE will connect manually with third party entities to securely
transfer or verify Actual Data. As a non-limiting example, two
parties may swap IP addresses to create an exemption in the
firewall to maintain connection for authentication of Actual
Data.
[0072] Hardware Provisioning--In certain embodiments, the TSE
creates profiles and Identifiers for unique hardware
identification. Hardware from the TSE Authority may contain
certificates and Identifiers in the hardware unit itself. Third
party hardware such as mobile devices, computers, and terminals
will require provisioning from the TSE to input Identifiers into
the third party device by utilizing a Certificate Authority. As a
non-limiting example, in order to provision a mobile device, the
TSE will take in device-specific information from the third party
device and create an Identifier/profile on the TSDB. Depending on
the level of security needed, a Certificate Authority will input
Identifier or Response Data to specific hardware to be utilized in
future connections.
[0073] Third Party Provisioning Request--In certain embodiments,
third party entities may issue a request to the TSE for a creation
of an Identifier for a relationship between the TSE entity and the
third party. In this instance, the TSE will create the third party
specific Identifier and confirm with the entity if it wishes to
attach this new Identifier to the entity's existing profile. If
accepted, the information will be added to the entity's profile as
verified data. If not, the information will be added to the
entity's profile as unverified data. As a non-limiting example, a
university wishes to create a unique Student ID for a particular
TSE user when the user enrolls at the university. The TSE will
create a new ID and ask the user if he/she wishes to attach the
University Student ID into his/her profile.
[0074] User Provisioning Request--In certain embodiments, a user
may issue a request to the TSE for creation and/or storage of a
third party Identifier. This request may occur via a user device
which extracts data from the third party and sends that data to the
TSE or the request may consist of the user manually entering third
party data and transferring that data to the TSE. If the TSE has a
connection method with the third party for data verification, the
data will be added to the user's profile as verified data. If not,
the data will be added to the user's profile as unverified data. As
a non-limiting example, if a user is utilizing an RHD/NFC ("radio
frequency identification/near field communication") device, a
user's mobile device may pick up passport data and send it to the
TSE for storage for future mobile ID usage. As another non-limiting
example, if a credit card company does not wish to do over-the-air
provisioning of a credit or debit card, the credit card company may
provide the user with an activation code. When the user manually
enters the activation code with the TSE, e.g., on a TSE website,
the activation code will be taken and verified with the credit card
issuer and the TSE will provision the associated credit or debit
card into the user's profile.
[0075] Third Party User Provisions--In certain embodiments, a user
may provision a third party device utilizing TSE Identifiers and/or
Response Data. This situation may occur via a user device which
extracts data from the TSE and sends that data to a third party
device. Alternatively, third party user provisioning may include
the user manually entering TSE data that was previously inputted to
a third party device. The third party device may or may not connect
to the TSE for verification (pending security levels). The third
party device, however, will maintain the data/credential for future
authentication of the user. As a non-limiting example, a user may
tap his/her mobile device against an input device (e.g., using NFC
communication) when renting a locker. The user's Identifier is sent
to the input device for the locker and stored. When the user wishes
to open the locker once again, he/she may tap the mobile device
again against the input device thus initiating a verification of
the user's Identifier and, if verified, the locker opens. As
another non-limiting example, a user enters his/her TSE
username/password combination into a computer. The computer then
connects with the TSE to verify the user's identity. Once the user'
identity is confirmed, the TSE may download to the computer the
user's specifications and files for use.
[0076] As stated above, provisioning includes the process of
preparing and equipping an apparatus to allow it to provide
service(s) (e.g., providing and/or verifying and/or authenticating
IDs/credentials and/or the user or third parties) to its user. By
way of explanation of the provisioning concept as disclosed herein,
the following sections use and discuss simple terminology and
scenarios. Those of skill in the art will readily understand that
the terminology and/or the scenarios are exemplary only and in no
way are intended to limit the scope of the disclosure or
embodiments discussed.
[0077] For purposes of this discussion, the term "Giver" will be
used to represent a User (i.e., person or entity for which
ID/credential is created and/or stored and/or transmitted, as
appropriate) or an apparatus utilized to pass data to a "Receiver",
where the apparatus must have a network connection to a secure
storage system for user to input and verify an ID/credential.
Naturally, a user may have more than one apparatus that operates as
a Giver. The term "Receiver" will be used to represent a
network-enabled or localized apparatus which receives data from the
Giver to validate Giver and/or provide appropriate service(s). The
Receiver may have one or more Giver(s) accessed at the same
time.
[0078] A Giver and Receiver relationship is utilized to describe a
transaction of data that has or will take place. Due to the
complexity of certain use cases of ID/credentials, there may be
multiple transactions taking place in a particular use case. This
may cause a user or apparatus to take on both the role of Giver and
Receiver during portions of the entirety of a scenario.
[0079] Scenario A. Giver Provisioning Third Party Networked
Apparatus. [0080] 1. Giver connects with apparatus and passes data
[0081] 2. Apparatus connects with Server (i.e., at secure storage
system) [0082] 3. Server verifies data [0083] 4. Server (if data is
validated) opens session [0084] 5. Server connects with apparatus
to provide user with access to function allowed while session is
open [0085] 6. Session can be closed by Server, User (Giver), or
apparatus
[0086] Scenario B. Giver Provisioning Third Party Networked
Apparatus (when Apparatus Lacks Network Connection or Requires
Giver to Communicate with Server). [0087] 1. Giver connects with
apparatus and passes data [0088] 2. Apparatus does not have network
connection or requires Giver to communicate with Server [0089] 3.
Apparatus connects with Giver (i.e., data device) [0090] 4. Giver
connects with server [0091] 5. Server verifies data [0092] 6.
Server (if data is validated) opens session [0093] 7. Server
connects with Giver and passes session info [0094] 8. Giver
connects with Apparatus to provide user with access to session
[0095] 9. Session can be closed by Server, User, or Apparatus
[0096] Scenario C. Giver Network Provisioning Third Party
Apparatus. [0097] 1. Giver connects with Apparatus and passes data
[0098] 2. Apparatus connects with Giver and passes data [0099] 3.
Giver connects with Server [0100] 4. Server verifies data [0101] 5.
Server (if data is validated) opens session [0102] 6. Server
connects with Giver to provide user with access to function allowed
while session is open [0103] 7. (optional step) Giver connects with
Apparatus and passes data [0104] 8. Session can be closed by Server
or Giver
[0105] Scenario D. Giver Provisioning 3rd Party Localized
Apparatus. [0106] 1. Giver connects with Apparatus and passes data
[0107] 2. Apparatus analyze data and opens session with received
data [0108] 3. Apparatus may store the data given by Giver as
temporary data and open session, or [0109] 4. Apparatus may utilize
permanent master data and open session (key) [0110] 5. Session can
be closed by Giver or Apparatus
[0111] A session can be closed, as non-limiting examples, by the
User or User's device (whether they are the Giver or Receiver) in
the following ways: [0112] 1. User can set a time to expire session
based on time (clock time, elapsed time, etc.) [0113] 2. User can
set an instance upon which the session will expire (e.g., key can
only be used once) [0114] 3. User can manually close session
[0115] A session can be closed by the Apparatus (Receiver) in the
following ways, as non-limiting examples: [0116] 1. Apparatus can
have a set time upon which the session will expire [0117] 2.
Apparatus can have an instance upon which the session will expire
(i.e. after one time use of function) [0118] 3. Apparatus can be
manually closed (via a person with, e.g., a Master Override)
[0119] A session can be closed by the Server in the following ways,
as non-limiting examples: [0120] 1. Server can have a set time upon
which the session will expire [0121] 2. Server can have an instance
upon which the session will expire (e.g., after two times of
logging in to the Server) [0122] 3. Server can be manually closed
(via a person with, e.g., a Master Override)
[0123] Examples of provisioning use cases are presented below. One
of ordinary skill in the art will understand that these examples
are offered to aid in understanding of the disclosure and do not
limit the scope of the disclosure.
Example 1
User Provisioning his/her Own Mobile Device (Scenario A)
[0124] 1. Giver connects with Apparatus and passes data [0125] 2.
User enters username, password, PIN, email [0126] 3. Apparatus
connects with Server [0127] 4. Apparatus sends username, password,
PIN, email, Apparatus hardware ID, and Requesting Data [0128] 5.
Server verifies data (TSDB sends request to TIS) [0129] 6. TIS
verifies username, password, PIN, email, Apparatus hardware ID,
Requesting Data, and opens session (if data is validated) [0130] 7.
Server connects with Apparatus to provide User with access to
function allowed while session is open [0131] 8. Server passes
session token and User role data (i.e. accessible modules) [0132]
9. Session can be closed by Server, User, or Apparatus: [0133] a.
Server expires session token based on time [0134] b. User manually
closes session
Example 2
User Provisioning their Door Lock with Network Connection (Scenario
A)
[0134] [0135] 1. Giver connects with Apparatus and passes data
[0136] 2. Giver passes User ID, Hardware ID, Data (PIN) [0137] 3.
Apparatus connects with Server [0138] 4. Apparatus sends User ID,
Hardware ID, Data (PIN), third party ID, App ID (firmware),
Terminal ID, Requesting Data [0139] 5. Server verifies data (TSDB
sends request to TIS) [0140] 6. TIS verifies User ID, Hardware ID,
Data (PIN), third party ID, App ID (firmware), Terminal ID,
Requesting Data and opens session (if data is validated) [0141] 7.
Server connects with Apparatus to provide User with access to
function allowed while session is open [0142] 8. Server passes
session token and User role data (i.e. accessible modules) [0143]
9. Session can be closed by Server, User, or Apparatus: [0144] a.
Server expires session token based on time [0145] b. User manually
closes session [0146] c. Apparatus expires session token based on
instance (when the door closes and door automatically locks)
Example 3
User Provisioning a Treadmill to Contain Workout Detail (Normally
Scenario A), However, Treadmill Loses Network Connection in Order
to Pull Data Therefore Utilizes User's Mobile Device as a Network
Relay (Scenario B)
[0146] [0147] 1. Giver (User's mobile device) connects with
Apparatus (treadmill) and passes data [0148] 2. Giver passes User
ID, Hardware ID, Data (PIN) [0149] 3. Apparatus does not have
network connection [0150] 4. Apparatus connects with Giver (device)
[0151] 5. Treadmill passes User ID, Hardware ID, Data (PIN), third
party ID, App ID (firmware), Terminal ID, Requesting Data to User's
mobile device [0152] 6. Giver (device) connects with Server [0153]
7. User's mobile device passes User ID, Hardware ID, Data (PIN),
third party ID, App ID (firmware), Terminal ID, Requesting Data to
TSDB [0154] 8. Server verifies data (TSDB passes request to TIS)
[0155] 9. TIS verifies User ID, Hardware ID, Data (PIN), third
party ID, App ID (firmware), Terminal ID, Requesting Data and opens
session (if data is validated) [0156] 10. Server connects with
Giver (device) and passes session info [0157] 11. Server passes
session token and data (i.e., workout details in this example)
[0158] 12. Giver (device) connects with Apparatus to provide User
with access to function/data (e.g., session token and workout
details) allowed while session is open [0159] 13. Session can be
closed by Server, User, or Apparatus: [0160] a. Server expires
session token based on time [0161] b. User manually closes session
[0162] c. Apparatus expires session token based on instance (when
the machine is idle for 10 minutes)
Example 4
User Goes to Hotel where the Hotel has the Ability to Provision the
User's Mobile Device to be Utilized as a Key to Enter into the
User's Room (Scenario C)
[0162] [0163] 1. Giver (hotel computer) connects with Apparatus
(user's mobile device) and passes data [0164] 2. Request Data
(request for User ID, Hardware ID, Data, and optional credentials
(input user name, password, PIN, etc.)) [0165] 3 Apparatus connects
with Giver and passes data [0166] 4. Giver passes User ID, Hardware
ID, Data, and optional credentials [0167] 5. Giver connects with
Server [0168] 6. Passes User ID, Hardware ID, Data, and optional
credentials [0169] 7. Server verifies data [0170] 8. TSDB passes
request to TIS [0171] 9. TIS verifies User ID, Hardware ID, Data,
and optional credentials and opens session (if data is validated)
[0172] 10. Server connects with Giver to provide User with access
to function allowed while session is open [0173] 11. (Optional
Step) Server connects with Giver (device) and passes session info
[0174] 12. Server passes session token and data (i.e., door key)
[0175] 13. Session can be closed by Server or Giver: [0176] a.
Server expires session token based on time [0177] b. Giver manually
closes session (Hotel can manually disable key) [0178] c. Apparatus
expires session token based on instance (when User checks out of
the room)
Example 5
User Goes to a Free Public Locker and Provisions the Locker for
his/her Use (Scenario D)
[0178] [0179] 1. Giver connects with Receiver and passes data
[0180] 2. Giver passes User ID, Hardware ID, data [0181] 3.
Apparatus analyzes data and opens session with received data [0182]
4. Apparatus will utilize User ID, Hardware ID, data to open
session and allow access in future if User ID, Hardware ID, data is
given to verify [0183] 5. Session can be closed by Giver or
Apparatus: [0184] a. Giver manually closes session (next time User
opens and closes the locker)
Example 6
(This is an Example where an Apparatus May be Both the Giver and
Receiver and the Entire Process Contains Multiple Provisioning
Processes) User has a Home Management System which Controls
Temperature, TV Channel Settings, Starting the Bath Water, and
Changing the Security Level
[0185] Process A: User Connects with Home Management System
(Scenario A) [0186] 1. Giver (User's mobile device) connects with
Apparatus and passes data [0187] 2. User enters User ID, Hardware
ID, and data (PIN) [0188] 3. Apparatus (Home Management System)
connects with Server [0189] 4. Apparatus sends User ID, Hardware
ID, and data (PIN), App ID (firmware), Terminal ID, and Requesting
Data [0190] 5. Server verifies data (TSDB sends request to TIS)
[0191] 6. TIS verifies User ID, Hardware ID, and data (PIN), App ID
(firmware), Terminal ID, and Requesting Data and opens session (if
data is validated) [0192] 7. Server connects with Apparatus to
provide User with access to function allowed while session is open
[0193] 8. Server passes session token and User role data (i.e.
accessible modules) [0194] 9. Session can be closed by Server,
User, or Apparatus: [0195] a. User manually closes session (when
exiting the premises)
[0196] Process B: Home Management System Connects with all
Connected Hardware to Enter User's Desired Presets (Scenario D)
[0197] 10. Giver (Home Management System) connects with Receiver
(Home Climate Control) and passes data [0198] 11. Giver passes App
ID (firmware), Terminal ID, data (climate preferences) [0199] 12.
Receiver stores data and opens session with received data [0200]
13. Receiver sets the climate control in the house with the User's
preset preferences [0201] 14. Session can be closed by Giver:
[0202] a. Giver manually closes session (when Home Management
System is notified by User in Process A, step 9)
[0203] Payment may be necessary as part of any provisioning
process. The provisioning process which includes payment is the
same as Scenario A or B where the data sent will include payment
information. For the case where user data is sent from one mobile
device to another mobile device, e.g., when a User gets a new
device, the provisioning process will follow Scenario A where the
data referenced in the provisioning process will include, for
example, all information from the User's old mobile device. Where a
User attempts to gain access to a gym via his/her membership card,
the provisioning process follows Scenario A, where the open session
will be for the instance of opening the door and session will be
closed upon the door shutting. For the case where User A gives User
B access to User A's door, this process is another example of a
process which contains multiple provisioning methods. User A
provisions User B by utilizing Scenario B to create a temporary key
for User B. Then User B retrieves this key by following Scenario A.
Once User B has the key, accessing the door utilizes the processes
of Scenario D.
[0204] Payment Processing (with Additional Requests, i.e., PIN)
[0205] Certain processes will require additional information, such
as a PIN request, in order to process the transaction. During these
scenarios, additional steps are put in place for the Server to
request the additional data either from the User directly (on the
User's networked device) or to be entered on the Apparatus by the
User.
[0206] Scenario E: Payment Processing on Terminal with PIN [0207]
1. Giver (User Mobile Device) connects with Receiver (Payment
Terminal) and passes data1 including User ID, Hardware ID, Payment
ID, and Requesting Data, to Receiver [0208] 2. Receiver passes
data2 via network connection to Server, where data2 includes User
ID, Hardware ID, Payment ID, and Requesting Data, 3rd Party ID, App
ID (firmware), Terminal ID, and Requesting Data [0209] 3. Server
verifies data2 (TSDB sends request to TIS) [0210] 4. TIS verifies
data2, needs additional information (PIN)
Example 1
[0210] [0211] User (or Apparatus) is purchasing an item through a
terminal, such as a point-of-sale terminal. This purchase requires
additional verification to be entered, but the terminal in this
example does not have a input keypad, therefore User will need to
enter PIN on his/her own mobile device. [0212] 5. Server requests
additional data to Receiver, i.e., Requesting Data (Enter PIN)
[0213] 6. Receiver requests additional data to Giver (mobile
device) [0214] 7. User inputs data requested and Giver passes to
Receiver [0215] 8. Receiver connects with Server [0216] 9. Server
verifies data (TSDB sends request to TIS) [0217] 10. Server (if
data is verified) opens session [0218] 11. Server connects with
Receiver to provide Giver with access to function allowed while
session is open [0219] 12. Session can only be closed by Server
Example 2
[0219] [0220] User (or Apparatus) is purchasing an item through a
terminal. This purchase requires additional verification to be
entered on the terminal. [0221] 5. Server requests additional data
to Receiver, i.e., Requesting Data (Enter PIN) [0222] 6. Receiver
requests additional data to Giver [0223] 7. User inputs data
requested on the Receiver [0224] 8. Receiver connects with Server
[0225] 9. Server verifies data (TSDB sends request to TIS) [0226]
10. Server (if data is verified) opens session [0227] 11. Server
connects with Receiver to provide Giver with access to function
allowed while session is open [0228] 12. Session can only be closed
by Server
[0229] Payment Processing on Website (Mobile and/or Computer-Based)
with PIN
[0230] Scenario F: Website Will Connect with Tango Secure
Environment ("TSE") (Application or Portal) [0231] 1. Giver
(Website) connects with Server and passes data: third party ID, App
ID (firmware), User ID (e.g., username and password of User) [0232]
2. Server verifies data (TSDB sends request to TIS) [0233] 3.
Server (if data is verified) opens session [0234] 4. Server
connects with Receiver to provide Giver with access to function
allowed while session is open [0235] 5. Giver (Website) connects
with Receiver (TSE) and passes data: Session Token, Terminal ID,
and data (item description, amount, etc.)
[0236] Scenario G: User Will Enter Data on TSE (Application or
Portal) [0237] 1. Giver (User) connects with Receiver (TSE) and
passes data1: User ID, Hardware ID, Payment ID, and Requesting
Data, to Receiver [0238] 2. Receiver passes data2 via network
connection to Server: data1, third party ID, App ID (firmware),
Terminal ID, and Requesting Data [0239] 3. Server verifies data2
(TSDB sends request to TIS) [0240] 4. TIS verifies data2, needs
additional information (PIN) [0241] 5. Server sends request for
additional data to Receiver: Requesting Data (Enter PIN) [0242] 6.
Receiver requests additional data to Giver on TSE application or
portal [0243] 7. User inputs data requested and data is passed to
Receiver [0244] 8. Receiver connects with Server [0245] 9. Server
verifies data (TSDB sends request to TIS) [0246] 10. Server (if
data is verified) processes payment [0247] 11. Server connects with
Receiver to provide Giver with confirmation [0248] 12. Session can
only be closed by Server
[0249] With attention drawn to FIG. 1, a block diagram of a secure
data/credential storage system 100, the Tango Secure Environment
("TSE") according to an embodiment of the present subject matter is
depicted. Shown are various segments of the TSE 100. Block 110
depicts the Tango Secure Database ("TSDB"). One of the functions of
the TSDB 110 is to operate as the sole communication interface with
all data devices communicating to/from the TSE 100. These data
devices include, but are not limited to, mobile devices, websites,
terminals, POS devices, electronic devices, mobile apps, computers,
databases, network devices, etc. All information going to or coming
from the TSE 100 must be routed through the TSDB 110. Block 120
depicts the Tango Intelligence System ("TIS") which, in an
embodiment, comprises software. The TIS 120 has no direct public
access. Access to the TIS 120 must be cleared and routed through
the TSDB 110. Block 130 depicts the Tango Secure Storage ("TSS")
which, in certain embodiments, is controlled by the TIS 120. The
TSS 130 has no direct public access. Access to the TSS 130 must be
cleared and routed through the TSDB 110. Block 140 depicts the Data
Secure Storage ("DSS"). In an embodiment, the DSS 140 is an
expandable secure storage facility for entities and users requiring
secure storage and usage of data/ID/credential services, e.g., if a
private secure cloud storage facility is requested. The DSS 140 has
no direct public access. Access to the DSS 140 must be cleared and
routed through the TSDB 110.
[0250] Considering now FIG. 2, a functional block diagram 200 is
depicted for a process for performing a transaction using a user's
credentials from a website not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter. In FIG. 2, the features designated 100,
110, 120, 130, and 140 are as described above with respect to FIG.
1. Depicted in FIG. 2 are a user 250a, the user's data device 250b,
and the user's computer device 260, where either or both of these
devices may be one of the data devices described above or any
similar data device. In an embodiment discussed below, the user's
data device 250b is referred to as mobile device 250b. Those of
skill in the art will readily understand that this exemplary
embodiment is a non-limiting description of the workings of the
novel system and method described herein. The user 250a in the
presently-described embodiment has an account on the TSE 100 and
therefore the user has an ID/credential data 251a known to the TSE,
e.g., a User ID/identifier and a password. In an embodiment, the
user's computer device 260 is connected to a non-Tango website. In
other embodiments, the user's computer device 260 is connected to a
Tango website. In an embodiment, the user desires to take advantage
of products/services offered on a third-party, non-Tango website.
The user enters the user's credential data 251a on the computer
device 260, as shown by arrow 252, into an approved Tango portal
265 which appears on the third-party, non-Tango website.
[0251] After the user enters the credential data 251a, the
third-party website connects directly to the TSDB 110 via a
connection that is wired, wireless, or both. In an embodiment, the
connection to the TSDB 110 is via an API/SDK provided to the
third-party website by the Tango system. The third-party website
sends to the TSDB 110, as shown by arrow 262, the user's credential
data 251b as well as data 261 associated with the third-party
website, such as, in an embodiment, one or more of a payment source
identifier, an identifier for the third-party/entity, a web portal
identifier associated with the third-party website, and a
transaction type identifier corresponding to a requested
transaction type by the user. The TSE 100 verifies the user's
credential data 251b and the third-party data 261. In an
embodiment, the TSE 100 contacts the user's device 250b via network
270, as shown by arrow 271. In an embodiment, the payment source
identifier is one or more of a credit/debit card number, a bank
account number, an electronic payment system number, etc., that is
a verifiable number that is stored in the TSE 100. In a further
embodiment, the payment source identifier is one or more of, or may
be contained within, the device ID, the user ID, a credit/debit
card number, a bank account number, etc., that is a verifiable
number that is stored in the TSE 100.
[0252] After the user approves the transaction with the TSE 100 (if
required), the TIS 120 to pull data stored in the TSS 130 and/or
DSS 140 as necessary to complete the user's requested transaction
263. Furthermore, in an embodiment, the TSE 100 will store some or
all of the third-party data 261 in the user's profile in the TSS
130 and/or the DSS 140. The user 250a may delete and/or manage the
third party data 261 stored in his/her profile via the TSDB 110
using the mobile device 250b, a website, and/or other
device/hardware/software.
[0253] In FIG. 3, a flow chart 300 is shown for a process for
performing a transaction from a website not associated with the
secure data/credential storage system according to an embodiment of
the present subject matter. At block 310, credential data is
received at a web server hosting a website, such as the third-party
website discussed above with respect to FIG. 1. The credential data
includes a user identifier and a password of a user. At block 320,
the credential data, a payment source identifier, a third party
identifier of an entity, a web portal identifier associated with
the website, and a transaction type identifier corresponding to a
requested transaction type are transmitted from the web server to
an authentication server, such as TSE 100 in FIG. 1. At block 330,
at the authentication server, the password and the web portal
identifier are authenticated based on the user identifier and the
third party identifier. At block 340, a confirmation request is
transmitted from the authentication server to a device used by the
user, such as, in an embodiment, the user's mobile device 250b in
FIG. 2. At block 350, a confirmation message is received from the
user. At block 360, a transaction corresponding to the requested
transaction type is performed for the user using a payment source
corresponding to the payment source identifier.
[0254] In an embodiment, the confirmation message includes a
personal identification code of the user which is authenticated at
the authentication server. In a further embodiment, the user is
prompted to enter the personal identification code responsive to a
determination that a transaction amount for the requested
transaction exceeds a predetermined threshold. In a still further
embodiment, the user is prompted to enter the personal
identification code responsive to a determination that the user's
device is currently in one of a predetermined set of locations.
[0255] Now looking at FIG. 4, a flow chart 400 shows a process for
performing a transaction, including a transaction identifier, from
a website not associated with the secure data/credential storage
system according to an embodiment of the present subject matter. In
FIG. 4, blocks 310, 320, 330, 340, 350, and 360 are the same as the
corresponding blocks discussed above with respect to FIG. 3. At
block 461, a transaction identifier is transmitted from the web
server to the authentication server. At block 462, the transaction
identifier is authenticated at the authentication server.
[0256] FIG. 5 shows a flow chart 500 for a process for performing a
transaction, including a request for data, from a website not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter. In FIG. 5, blocks
310, 320, 330, 340, and 350 are the same as the corresponding
blocks discussed above with respect to FIG. 3. At block 551, an
electronic message is transmitted from the authentication server to
an entity computer of an entity, where the electronic message
includes a request for data. At block 552, the requested data is
received from the entity computer at the authentication server. At
block 553, the transaction is performed for the user based on the
received data.
[0257] In FIG. 6, a flow chart 600 illustrates a process for
performing a transaction, including an electronic authorization,
from a website not associated with the secure data/credential
storage system according to an embodiment of the present subject
matter. In FIG. 6, blocks 310, 320, 330, 340, and 350 are the same
as the corresponding blocks discussed above with respect to FIG. 3.
At block 651, an electronic message is transmitted from the
authentication server to an entity computer of the entity, where
the electronic message includes a request for authorization of the
requested transaction. At block 652, an electronic authorization is
received at the authentication server from the entity computer. At
bock 653, the transaction is performed for the user responsive to
the received authorization from the entity computer.
[0258] FIG. 7 shows a flow chart 700 for a process for performing a
transaction, including updated transaction data, from a website not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter. In FIG. 7, blocks
310, 320, 330, 340, 350, and 360 are the same as the corresponding
blocks discussed above with respect to FIG. 3. At block 761, an
electronic message is transmitted from the authentication server to
an entity computer of the entity, where the electronic message
includes updated transaction data for storage at the entity
computer.
[0259] FIG. 8 depicts a flow chart for a process for performing a
transaction, including notification of a requested transaction,
from a website not associated with the secure data/credential
storage system according to an embodiment of the present subject
matter. In FIG. 8, blocks 310, 320, 330, 340, 350, and 360 are the
same as the corresponding blocks discussed above with respect to
FIG. 3. At block 861, a first electronic message is transmitted
from the authentication server to an entity computer of the entity,
where the first electronic message includes a notification of the
requested transaction. At block 862, a second electronic message is
received at the authentication server from the entity computer,
where the second electronic message includes update data. At block
863, the update data is transmitted to the device used by the
user.
[0260] Considering now FIG. 9, a functional block diagram 900 is
depicted for a process for performing a transaction using a user's
credentials from a mobile application not associated with the
secure data/credential storage system according to an embodiment of
the present subject matter. In FIG. 9, the features designated 100,
110, 120, 130, and 140 are as described above with respect to FIG.
1. Depicted in FIG. 9 are a user 250a, the user's data device 250b,
and the user's computer device 960, where either or both of these
devices may be one of the data devices described above or any
similar data device. In an embodiment, the user's data device 250b
and the user's computer device 960 are the same device. In an
embodiment discussed below, the user's data device 250b is referred
to as mobile device 250b. Those of skill in the art will readily
understand that this exemplary embodiment is a non-limiting
description of the workings of the novel system and method
described herein. The user 250a in the presently-described
embodiment has an account on the TSE 100 and therefore the user has
an ID/credential data 251a known to the TSE, e.g., a User
ID/identifier and a password. In an embodiment, the user's computer
device 960 is connected to a non-Tango application. In other
embodiments, the user's computer device 960 is connected to a Tango
application. In an embodiment, the user desires to take advantage
of products/services offered on a third-party, non-Tango
application and/or mobile website. The user enters the user's
credential data 251a on the computer device 960, as shown by arrow
252, into an approved Tango portal 265 which appears on the
third-party, non-Tango application/website.
[0261] After the user enters the credential data 251a, the
third-party application/website connects directly to the TSDB 110
via a connection that is wired, wireless, or both. In an
embodiment, the connection to the TSDB 110 is via an API/SDK
provided to the third-party application/website by the Tango
system. The third-party application/website sends to the TSDB 110,
as shown by arrow 962, the user's credential data 251b as well as
data 961 associated with the third-party application/website, such
as, in an embodiment, one or more of a payment source identifier,
an identifier for the third-party/entity, a web portal identifier
associated with the third-party application/website, and a
transaction type identifier corresponding to a requested
transaction type by the user. The TSE 100 verifies the user's
credential data 251b and the third-party data 961. In an
embodiment, the TSE 100 contacts the user's device 250b via network
270, as shown by arrow 271.
[0262] After the user approves the transaction with the TSE 100 (if
required), the TIS 120 pulls data stored in the TSS 130 and/or DSS
140 as necessary to complete the user's requested transaction 963.
Furthermore, in an embodiment, the TSE 100 will store some or all
of the third-party data 961 in the user's profile in the TSS 130
and/or the DSS 140. The user 250a may delete and/or manage the
third party data 961 stored in his/her profile via the TSDB 110
using the mobile device 250b, a website, and/or other
device/hardware/software.
[0263] Looking at FIG. 10, a flow chart 1000 is presented for a
process for performing a transaction from a mobile application not
associated with the secure data/credential storage system according
to an embodiment of the present subject matter. At block 1010,
credential data is received at an application executing on a mobile
device of a user, where the credential data includes a user
identifier and a password of the user. At block 1020, the
credential data, a payment source identifier, a third party
identifier of an entity, a device identifier associated with the
device, and a transaction type identifier corresponding to a
requested transaction type is transmitted from the mobile device to
an authentication server. At block 1030, the process includes
authenticating the password and the device identifier at the
authentication server based on the user identifier and the third
party identifier. At block 1040, a confirmation request is
transmitted from the authentication server to the mobile device. At
block 1050, a confirmation is received from the user. At block
1060, a transaction is performed for the user corresponding to the
requested transaction type.
[0264] In an embodiment, the confirmation message includes a
personal identification code of the user which is authenticated at
the authentication server. In a further embodiment, the user is
prompted to enter the personal identification code responsive to a
determination that a transaction amount for the requested
transaction exceeds a predetermined threshold. In a still further
embodiment, the user is prompted to enter the personal
identification code responsive to a determination that the device
is currently in one of a predetermined set of locations.
[0265] FIG. 11 depicts a flow chart 1100 for a process for
performing a transaction, including a transaction identifier, from
a mobile application not associated with the secure data/credential
storage system according to an embodiment of the present subject
matter. In FIG. 11, blocks 1010, 1020, 1030, 1040, 1050, and 1060
are the same as the corresponding blocks discussed above with
respect to FIG. 10. At block 1161, a transaction identifier is
transmitted from the mobile device to the authentication server. At
block 1162, the transaction identifier is authenticated at the
authentication server.
[0266] FIG. 12 illustrates a flow chart 1200 for a process for
performing a transaction, including a request for data, from a
mobile application not associated with the secure data/credential
storage system according to an embodiment of the present subject
matter. In FIG. 12, blocks 1010, 1020, 1030, 1040, and 1050 are the
same as the corresponding blocks discussed above with respect to
FIG. 10. At block 1251, an electronic message is transmitted from
the authentication server to an entity computer of an entity,
wherein the electronic message includes a request for data. At
block 1252, the requested data is received at the authentication
server from the entity computer. At block 1253, the transaction is
performed for the user based on the received data.
[0267] Now at FIG. 13, a flow chart 1300 is shown for a process for
performing a transaction, including an authorization, from a mobile
application not associated with the secure data/credential storage
system according to an embodiment of the present subject matter. In
FIG. 13, blocks 1010, 1020, 1030, 1040, and 1050 are the same as
the corresponding blocks discussed above with respect to FIG. 10.
At block 1351, an electronic message is transmitted from the
authentication server to an entity computer of an entity, where the
electronic message includes a request for authorization of the
requested transaction. At block 1352, an electronic authorization
is received at the authentication server from the entity computer.
At block 1353, the transaction is performed for the user responsive
to the received authorization from the entity computer.
[0268] FIG. 14 depicts a flow chart 1400 for a process for
performing a transaction, including a updated transaction data,
from a mobile application not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter. In FIG. 14, blocks 1010, 1020, 1030, 1040,
1050, and 1060 are the same as the corresponding blocks discussed
above with respect to FIG. 10. At block 1461, an electronic message
is transmitted from the authentication server to an entity computer
of an entity, where the electronic message includes updated
transaction data for storage at the entity computer.
[0269] FIG. 15 shows a flow chart 1500 for a process for performing
a transaction, including a notification of the requested
transaction, from a mobile application not associated with the
secure data/credential storage system according to an embodiment of
the present subject matter. In FIG. 15, blocks 1010, 1020, 1030,
1040, 1050, and 1060 are the same as the corresponding blocks
discussed above with respect to FIG. 10. At block 1561, a first
electronic message is transmitted from the authentication server to
an entity computer of an entity, where the first electronic message
includes a notification of the requested transaction. At block
1562, a second electronic message is received at the authentication
server from the entity computer, where the second electronic
message includes update data. At block 1563, the update data is
transmitted to the mobile device.
[0270] FIG. 16 shows a flow chart 1600 for a process for performing
a transaction, including a personal identification code, from a
website and/or mobile application not associated with the secure
data/credential storage system according to an embodiment of the
present subject matter. At block 1610, a user identifier, a
password of a user, a payment source identifier, a third party
identifier of an entity, a login source identifier, and a
transaction type identifier corresponding to a requested
transaction type are received at an authentication server. At block
1620, the password and the login source identifier are
authenticated based on the user identifier and the third party
identifier. At block 1630, a confirmation request is transmitted
from the authentication server to a device used by the user. At
block 1640, a confirmation message including a personal
identification code is received from the user. At block 1650, the
personal identification code is authenticated at the authentication
server. At block 1660, a transaction corresponding to the requested
transaction type for the user is performed using a payment source
corresponding to the payment source identifier.
[0271] FIG. 17 depicts a flow chart 1700 for a process for
performing a transaction, including a login source identifier, from
a website not associated with the secure data/credential storage
system according to an embodiment of the present subject matter. In
FIG. 17, blocks 1610, 1620, 1630, 1640, 1650, and 1660 are the same
as the corresponding blocks discussed above with respect to FIG.
16. At block 1761, the user identifier and the password are
received at a web server hosting a website. At block 1762, the user
identifier and the password are transmitted from the web server to
the authentication server, where the login source identifier is
associated with the website.
[0272] Now considering FIG. 18, a flow chart 1800 is presented for
a process for performing a transaction, including a login source
identified, from a mobile application not associated with the
secure data/credential storage system according to an embodiment of
the present subject matter. In FIG. 18, blocks 1610, 1620, 1630,
1640, 1650, and 1660 are the same as the corresponding blocks
discussed above with respect to FIG. 16. At block 1861, the user
identifier and the password are received at an application
executing on the mobile device. At bock 1862, the user identifier
and the password are transmitted from the mobile device to the
authentication server, where the login source identifier is
associated with the mobile device.
[0273] Portions of the present disclosure may be implemented by a
general purpose computer programmed in accordance with the
principles discussed herein. It may be emphasized that the
above-described embodiments, particularly any "preferred"
embodiments, are merely possible examples of implementations,
merely set forth for a clear understanding of the principles of the
disclosure. Many variations and modifications may be made to the
above-described embodiments of the disclosure without departing
substantially from the spirit and principles of the disclosure. All
such modifications and variations are intended to be included
herein within the scope of this disclosure and the present
disclosure and protected by the following claims.
[0274] Embodiments of the subject matter and the functional
operations described in this specification can be implemented in
digital electronic circuitry, or in computer firmware or hardware,
including the structures disclosed in this specification and their
structural equivalents, or in combinations of one or more of them.
The term "processor" encompasses all apparatus, devices, and
machines for processing data, including by way of example a
programmable processor, a computer, or multiple processors or
computers.
[0275] To provide for interaction with a user, embodiments of the
subject matter described in this specification can be implemented
on a computer having a display device, e.g., a cathode ray tube
(CRT) or liquid crystal display (LCD) monitor, for displaying
information to the user and a keyboard and a pointing device, e.g.,
a mouse, trackpad, touchscreen, or a trackball, by which the user
can provide input to the computer. Other kinds of devices can be
used to provide for interaction with a user as well; for example,
input from the user can be received in any form, including
acoustic, speech, or tactile input.
[0276] Embodiments of the subject matter described in this
specification can be implemented in a computing system that
includes a back end component, e.g., as a data server, or that
includes a middleware component, e.g., an application server, or
that includes a front end component, e.g., a client computer having
a graphical user interface or a Web browser through which a user
can interact with an implementation of the subject matter described
is this specification, or any combination of one or more such back
end, middleware, or front end components. The components of the
system can be interconnected by any form or medium of digital data
communication, e.g., a communication network. Examples of
communication networks include a local area network (LAN) and a
wide area network (WAN), e.g., the Internet.
[0277] The computing system can include clients and servers. A
client and server are generally remote from each other and
typically interact through a communication network. The
relationship of client and server arises by virtue of computer
programs running on the respective computers and having a
client-server relationship to each other.
[0278] While this specification contains many specifics, these
should not be construed as limitations on the scope of the claimed
subject matter, but rather as descriptions of features that may be
specific to particular embodiments. Certain features that are
described in this specification in the context of separate
embodiments can also be implemented in combination in a single
embodiment. Conversely, various features that are described in the
context of a single embodiment can also be implemented in multiple
embodiments separately or in any suitable subcombination. Moreover,
although features may be described above as acting in certain
combinations and even initially claimed as such, one or more
features from a claimed combination can in some cases be excised
from the combination, and the claimed combination may be directed
to a subcombination or variation of a subcombination.
[0279] Similarly, while operations are depicted in the drawings in
a particular order, this should not be understood as requiring that
such operations be performed in the particular order shown or in
sequential order, or that all illustrated operations be performed,
to achieve desirable results. In certain circumstances,
multitasking and parallel processing may be advantageous. Moreover,
the separation of various system components in the embodiments
described above should not be understood as requiring such
separation in all embodiments, and it should be understood that the
described program components and systems can generally be
integrated together in a single software product or packaged into
multiple software products.
[0280] While some embodiments of the present subject matter have
been described, it is to be understood that the embodiments
described are illustrative only and that the scope of the invention
is to be defined solely by the appended claims when accorded a full
range of equivalence, many variations and modifications naturally
occurring to those of skill in the art from a perusal hereof.
* * * * *