US20150207789A1 - System and method for electronic credentials - Google Patents

System and method for electronic credentials Download PDF

Info

Publication number
US20150207789A1
US20150207789A1 US14/421,005 US201314421005A US2015207789A1 US 20150207789 A1 US20150207789 A1 US 20150207789A1 US 201314421005 A US201314421005 A US 201314421005A US 2015207789 A1 US2015207789 A1 US 2015207789A1
Authority
US
United States
Prior art keywords
data
user
party
authentication server
data item
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/421,005
Other languages
English (en)
Inventor
Himalesh Cherukuvada Kumar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tango Mobile LLC
Original Assignee
Tango Mobile LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tango Mobile LLC filed Critical Tango Mobile LLC
Priority to US14/421,005 priority Critical patent/US20150207789A1/en
Publication of US20150207789A1 publication Critical patent/US20150207789A1/en
Assigned to CORT reassignment CORT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: Kumar, Himalesh Cherukuvada
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN

Definitions

  • ID identification documents and/or credentials
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a block diagram of a secure data/credential storage system according to an embodiment of the present subject matter.
  • FIG. 2 is a functional block diagram of provisioning an ID/credential system illustrating a process where an ID is created by a third party, stored in a secure storage device, and then sent to a user's device according to an embodiment of the present subject matter.
  • FIG. 3 is a functional block diagram of a process for creating an ID/credential that has been requested for use by a third party by a user or by the third party according to an embodiment of the present subject matter.
  • FIG. 4 is a flow chart for a method for provisioning an authentication system according to an embodiment of the present subject matter.
  • FIG. 5 is a flow chart for a method for provisioning an authentication system including requesting a digital certificate according to another embodiment of the present subject matter.
  • FIG. 6 is a flow chart for a method for provisioning an authentication system including creating a digital certificate according to yet another embodiment of the present subject matter.
  • FIG. 7 is a flow chart for a method for provisioning an authentication system including sending an acknowledgement of the provisioning according to still another embodiment of the present subject matter.
  • FIG. 8 is a flow chart for a method for provisioning an authentication system including generating additional data using a one-way function according to yet still another embodiment of the present subject matter.
  • FIG. 9 is a flow chart for a method for provisioning an authentication system including sending an acknowledgement of the provisioning according to a further embodiment of the present subject matter.
  • FIG. 10 is a flow chart for a method for provisioning an authentication system including sending a second acknowledgement of the provisioning according to yet a further embodiment of the present subject matter.
  • FIG. 11 is a functional block diagram of an ID/credential system illustrating provisioning a third party device using a user's approved data device with the ID/credential system according to still a further embodiment of the present subject matter.
  • FIG. 12 is a functional block diagram of an ID/credential system illustrating the user provisioning a third party device according to yet still a further embodiment of the present subject matter.
  • FIG. 13 is a functional block diagram of an ID/credential system illustrating provisioning a third party device according to even a further embodiment of the present subject matter.
  • FIG. 14 is a flow chart of a process for provisioning low priority data to a third party database according to yet an even further embodiment of the present subject matter.
  • FIG. 15 is a flow chart of a process for provisioning high priority data to a third party database according to still an even further embodiment of the present subject matter.
  • FIG. 16 is a flow chart of a process for a user provisioning low priority data to a third party database according to yet still an even further embodiment of the present subject matter.
  • FIG. 17 is a flow chart of a process for a user provisioning high priority data to a third party database according to an embodiment of the present subject matter.
  • FIG. 18 is a functional block diagram of an ID/credential system illustrating creating an ID/credential and transmitting to a user's data device according to another embodiment of the present subject matter.
  • FIG. 19 is a flow chart for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device according to yet another embodiment of the present subject matter.
  • FIG. 20 is a flow chart for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device and generating additional data using a one-way function according to still another embodiment of the present subject matter.
  • FIG. 21 is a flow chart for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device and sending an acknowledgement of the provisioning according to yet still another embodiment of the present subject matter.
  • FIG. 22 is a functional block diagram of an ID/credential system illustrating storing in a secure storage device an ID/credential created by a third party according to a further embodiment of the present subject matter.
  • FIG. 23 is a functional block diagram of an ID/credential system illustrating a user manually storing in a secure storage device an ID/credential created by a third party according to yet a further embodiment of the present subject matter.
  • FIG. 24 is a flow chart for a method for provisioning an authentication system according to still a further embodiment of the present subject matter.
  • FIG. 25 is a flow chart for a method for provisioning an authentication system including displaying a notification of the provisioning according to yet still a further embodiment of the present subject matter.
  • FIG. 26 is a flow chart for a method for provisioning an authentication system including receiving an activation code according to even a further embodiment of the present subject matter.
  • FIG. 27 is a flow chart for a method for provisioning an authentication system including receiving an activation code and sending a success message according to yet even a further embodiment of the present subject matter.
  • 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”).
  • 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.
  • the present disclosure incorporates different levels of data that are absorbed and/or used/passed through during an exchange or verification of data.
  • 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:
  • 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.
  • TSE Authority the “TSE Authority”
  • the account manager e.g., TSE Authority
  • 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.
  • 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.
  • 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.
  • a valid issuer such as, but not limited to, drivers licenses, passports etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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:
  • Actual 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.
  • 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.
  • ID/Credential and user data e.g., Actual Data
  • 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.
  • 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).
  • an algorithm e.g., hashing algorithm
  • 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).
  • 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 would be to use the ID/Credentials while at the same time protecting the sensitive root data of the ID/Credential itself.
  • 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).
  • 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.
  • 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.
  • 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.
  • the TSDB and/or TSE 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.
  • 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:
  • 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’).
  • the confirmation response only includes a Yes/No or Approval/Denial indication.
  • a Level Request may optionally be included.
  • 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.
  • 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.
  • 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”.
  • 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.
  • TSE Tango Secure Environment
  • the TSE includes:
  • 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.
  • TIS Tango Intelligent System
  • TIS Tango Intelligence System
  • 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.
  • 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.
  • the TIS 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.
  • third parties may include, but are not limited to, credit/debit card companies/issuers, banks, mobile apps, government credential-issuing organizations, etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • DSS Data Secure Storage
  • the DSS which is controlled by the TIS, is used separately or in conjunction with the TSS to securely store user/owner data.
  • 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.
  • APIs i.e., application program interfaces
  • 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.
  • 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.
  • Provisioning 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.
  • an apparatus such as, but not limited to, a secure storage system including a database
  • 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.
  • the TSE provisions data in the following ways/scenarios:
  • the TSE will connect manually with third party entities to securely transfer or verify Actual Data.
  • third party entities may swap IP addresses to create an exemption in the firewall to maintain connection for authentication of Actual Data.
  • 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.
  • the TSE 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.
  • a Certificate Authority will input Identifier or Response Data to specific hardware to be utilized in future connections.
  • 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.
  • 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.
  • 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.
  • 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.
  • a user's mobile device may pick up passport data and send it to the TSE for storage for future mobile ID usage.
  • the credit card company may provide the user with an activation code.
  • the 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.
  • 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.
  • 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 will maintain the data/credential for future authentication of the user.
  • 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.
  • the user 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.
  • 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.
  • 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.
  • service(s) e.g., providing and/or verifying and/or authenticating IDs/credentials and/or the user or third parties
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • a session can be closed by the Apparatus (Receiver) in the following ways, as non-limiting examples:
  • a session can be closed by the Server in the following ways, as non-limiting examples:
  • User has a home management system which controls temperature, TV channel settings, starting the bath water, and changing the security level.
  • 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.
  • 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.
  • 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.
  • 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.
  • Certain processes will require additional information, such as a PIN request, in order to process the transaction.
  • 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.
  • User 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.
  • Block 110 depicts the Tango Secure Database (“TSDB”).
  • TSDB Tango Secure Database
  • 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.
  • TIS Tango Intelligence System
  • 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 .
  • 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”).
  • 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 .
  • FIG. 2 a functional block diagram 200 is presented for provisioning an ID/credential system illustrating a process where an ID is created by a third party (such as 260 a , 260 b , and/or 260 c ), stored in a secure storage device 100 , and then sent 261 to a user's device 250 according to an embodiment of the present subject matter.
  • a third party such as 260 a , 260 b , and/or 260 c
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above.
  • the third party 260 b creates an ID and/or credential 262 b , which can be pre-existing ID and/or credential data for the user or the user can ask the third party to create ID/credential data on the spot to be sent to the TSE 100 .
  • the third party 260 b can be a state department of motor vehicles (“DMV”) and the ID data 262 b can be the user's driver's license information.
  • the DMV 260 b sends the user's ID data 262 b to the TSE 100 via the TSDB 110 through an API (application programming interface) database-to-database communication and/or connection 261 .
  • API application programming interface
  • the TSE 100 typically provides the correct communication, technology, and integration needed to connect the third party database 260 b to the TSDB 110 .
  • the TSDB 110 receives the user's data 263 b , passes the user's data to the TIS 120 which may store the user's data in the TSS 130 and/or DSS 140 .
  • the TIS 120 may determine that the user's data 263 b is not to be stored in which case the TIS creates a procedure to contact the third party database 260 b via the API communication and/or connection 261 to check the user's ID every time the user requests it.
  • the user via the user's device 250 , can access 251 the user's data 262 b via an approved mobile application, an approved website, an approved electronic device, an approved computer, and/or an approved database.
  • approved indicates that the software/firmware/hardware/device has been given access to connect to the TSDB 110 for or by the user and/or the original creator of the user's ID/credential (which, in this example, is the DMV 260 b ).
  • approved third parties 260 d may, in place of the user's device 250 , access the user's data via the TSDB 110 to verify the user's ID/credentials 263 b or 262 b , as appropriate.
  • the approved third parties 260 d can use the ID/credential access to support various services they may have created.
  • the approved third party 260 d may be a door lock manufacturer that created a door lock that only opens upon verification of the user's ID/credentials by connecting to the TSDB 110 via an API running, for example, on the user's mobile device 250 .
  • the door lock company 260 d can connect to the TSDB 110 via a network connection and performing a real time verification or can have the ID/credential data provisioned on the door lock/device itself.
  • FIG. 3 depicts a functional block diagram 300 of a process for creating an ID/credential 262 c that has been requested for use by a third party 260 c (of third parties 260 a , 260 b , and 260 c ) by a user 250 or by the third party 260 c according to an embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above.
  • the TSE 100 creates and stores for the user 250 the user's ID/credential 263 c on the TSS 130 and/or DSS 140 .
  • the ID/credential may have been created for the user based on a request 251 from, e.g., third party 260 c such as a university, bank, employer, etc., associated with the user.
  • the user's ID/credential 262 c is based on information about the user known by the third party 260 c .
  • the third party 260 c has access to the TSDB 110 and will be approved by the user for such a connection and for a request associated with the user's ID/credentials.
  • the TSDB 110 need not send 251 a digital or electronic ID/credential to the user's device 250 if not needed to connect to the third party 260 c .
  • the TSDB 110 may only send 251 a notification to the user/user's device 250 to inform the user of the link with the third party 260 c .
  • the connection between the third party 260 c and the TSE 100 may require information 363 c on user's device 250 in order to complete the information exchange with the third party 260 c.
  • FIG. 4 represents a flow chart 400 for a method of provisioning an authentication system according to an embodiment of the present subject matter.
  • first data such as a user's ID/credential data 262 b in FIG. 2
  • a data device of a first entity such as third party 260 b in FIG. 2
  • an authentication server such as TSE 100 via a TSDB 110 in FIG. 2 .
  • the first data 262 b includes a first entity identifier (which, in an embodiment, may be data indicating a state DMV), a confidential data item of a second entity, such as user 250 in FIG.
  • the confidential data item is generated at a data device of the first entity 260 b .
  • the method includes processing the first data at, e.g., TSE 120 in FIG. 2 , to determine that a security protocol is associated with the confidential data item and determine that the request to process the confidential data item is a storage request.
  • the method includes generating second data at the authentication server 100 where the second data is generated by operating on the confidential data item with a one-way function.
  • the one-way function is a hash function, as is known in the art.
  • the confidential data item and the second data are stored at a database, such as TSS 130 and/or DSS 140 in FIG. 2 .
  • FIG. 5 a flow chart 500 is shown for a method for provisioning an authentication system including requesting a digital certificate according to another embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • the method includes determining, based on first data, such as a user's ID/credential data 262 b in FIG. 2 , that a digital certificate is to be issued.
  • the method includes requesting issuance of a digital certificate based on at least the confidential data item of the first data, as discussed above.
  • the digital certificate is received by, in an embodiment, the TSE 100 .
  • the digital certificate is stored at a database, such as TSS 130 and/or DSS 140 .
  • the digital certificate is generated by operating with a one-way function on data associated with the issuer of the digital certificate, the confidential data item, a timestamp, and an indication of whether the first entity (e.g., a third party 260 b in FIG. 2 ) or the user requested the issuance of the digital certificate.
  • FIG. 6 shows a flow chart 600 for a method for provisioning an authentication system including creating a digital certificate according to yet another embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • the method includes determining, based on the first data, that a digital certificate is to be created.
  • a digital certificate is created based on at least the confidential data item.
  • the digital certificate is stored at the database, such as TSS 130 and/or DSS 140 , as discussed above.
  • FIG. 7 Shown in FIG. 7 is a flow chart 700 for a method for provisioning an authentication system including sending an acknowledgement of the provisioning to the user according to still another embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • Blocks 651 and 652 are as described above with respect to FIG. 6 .
  • Block 544 is as described above with respect to FIG. 5 .
  • an identifier of the user e.g., user's ID and/or credential
  • the authentication server such as TSE 100 .
  • acknowledgement message is sent from the authentication server 100 to a data device of the user, such as device 250 in FIG. 2 .
  • the acknowledgement message provides a notification that the authentication system 100 has been provisioned for secure storage of the confidential data item.
  • processing the first data includes comparing the confidential data item against a predetermined list of data items.
  • the confidential data item and the second data are stored in the user's profile at the database, such as TSS 130 and/or DSS 140 .
  • FIG. 8 illustrates a flow chart 800 for a method for provisioning an authentication system including generating additional data using a one-way function according to yet still another embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • a user identifier e.g., user's ID/credential
  • the authentication server such as TSE 100 .
  • third data is generated where the third data is a result of operating on the confidential data item and the user identifier with a one-way function, such as a hash function.
  • the third data is stored in the user's profile at the database, such as TSS 130 and/or DSS 140 .
  • the user's profile includes a data table (or similar indexable data structure) indexed by the user's identifier.
  • the confidential data item and the second data are stored in a first entity's profile at the database.
  • the first entity profile includes a data table indexed by the first entity's identifier, as discussed above.
  • a flow chart 900 is presented for a method for provisioning an authentication system including sending an acknowledgement of the provisioning to the first entity according to a further embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • an acknowledgement message is sent from the authentication server, such as TSE 100 in FIG. 2 , to a data devices of the first entity, such as third party 260 c in FIG. 3 , where the acknowledgement message provides a notification to the third party 260 c that the authentication system 100 has been provisioned for secure storage of the confidential data item.
  • FIG. 10 shows a flow chart 1000 for a method for provisioning an authentication system including sending a first and a second acknowledgement of the provisioning according to yet a further embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • Block 941 is as described above with respect to FIG. 9 .
  • a user identifier such as a user ID/credential, is transmitted from the a data device of the first entity, such as third party 260 c in FIG. 3 , to the authentication server, such as TSE 100 in FIG. 3 .
  • a second acknowledgement message is sent from the authentication server 100 to a data device of the user, such as device 250 in FIG. 2 , where the second acknowledgement message provides a notification to the user that the authentication system 100 has been provisioned for secure storage of the confidential data item.
  • FIG. 11 a functional block diagram 1100 is shown illustrating an ID/credential system illustrating provisioning a third party device 260 b using a user's approved data device 250 with the ID/credential system according to still a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • Third parties 260 a , and 260 b , and user/user's device 250 are as described above with respect to FIG. 2 .
  • the process of provisioning the third party 260 b begins by the user communicating 252 with the third party device 260 b (e.g., POS (point of sale) terminal, computer system, mobile device/software/firmware/hardware, website, apps, etc.) via a communication pathway such as, but not limited to, near-field communication, electronic communication, optical communication, radio communication, etc.
  • the third party device 260 b Upon receiving the communication from the user, the third party device 260 b sends a provisioning request 261 (e.g., by using one or more of the communication pathways mentioned above) to the TSE 100 via the TSDB 110 .
  • the TSDB 110 will then send to the third party device 260 b , via communication 251 to the user's device 250 and then to the third party device 260 b via communication 252 , any data, such as user ID/credentials 263 b discussed above, needed to provision the third party device, as requested by the third party and approved by the user 250 . If the user approves the third party to save the data from the TSDB, the third party device will store the user's ID/credentials 262 b .
  • this provisioning may allow, for example, the user 250 to access products and/or services offered by the third party 260 b without the third party having to access the TSDB 110 for the user's ID/credentials 263 b every time the user attempts to access the third party's products and/or services.
  • the provisioning of the third party device 260 b may be for a predetermined amount of time and/or a predetermined number of access events.
  • the user provisions the third party locker device with a low security token associated with the user so that the user may open and store his possessions in the locker. The user may then later return to the locker and open the locker with the low security token without having to wait for the third party locker device to contact the TSDB 110 to retrieve the user's ID/credentials.
  • the user's driver's license number will initially be stored in the TSE 100 .
  • the user when at the security checkpoint, will pull his driver's license number using his device 250 from the TSE 100 via the TSDB 110 .
  • the user will then store the driver's license number in a database for the security checkpoint for later identification.
  • the security checkpoint may at some point in time, access the TSE 100 to verify/authenticate the user's driver's license number to ensure that it is valid.
  • a functional block diagram 1200 illustrates an ID/credential system showing the user 250 provisioning a third party device 260 b according to yet still a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • Third parties 260 a , and 260 b , and user/user's device 250 are as described above with respect to FIG. 2 .
  • the process of provisioning the third party 260 b begins by the user 250 entering the user's ID/credentials 262 b directly into the third party device 260 b without the use of the user's device.
  • the ID/credentials may be a username/password combination for the user.
  • the third party device may contact 261 b the TSE 100 to verify and/or authenticate the username/password entered by the user. This verification and/or authentication may include sending from the third party device 260 b the user's username/password combination, an identifier for the third party device, and a data request to the TSE 100 , via the TSDB 110 .
  • the TSE 100 will check the authenticity of the user and the third party device and, if authenticated, will operate on the data request.
  • the information pertinent to the data request above will be downloaded 261 a from the TSE 100 to the third party device 260 b which may include the user's public information such as name, address, and telephone number, for example.
  • the TSE 100 will query the user's device (not shown for clarity) to obtain authorization to release the user's non-public information. The user may then either approve or disapprove the release. If approved, the TSE 100 will download 261 e to the third party device 260 b the user's non-public information requested.
  • the user's device not shown for clarity
  • FIG. 13 a functional block diagram 1300 is presented of an ID/credential system illustrating provisioning a third party device according to even a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • the user 250 either using the user's device or without using the user's device, enters 252 user identification data 264 a (e.g., PIN, username/password, site key, access code, etc.) into a third party device 260 a .
  • user identification data 264 a e.g., PIN, username/password, site key, access code, etc.
  • the third party device 260 a connects to the TSE 100 via the TSDB 110 and requests provisioning information so that the user and/or the third party device do not have to access the TSE 100 every time the user wishes to use products and/or services of the third party.
  • the third party device 260 a passes provisioning request 262 a including the user identification data 264 a and a third party ID along with instructions regarding the user information to be provisioned.
  • the TSE 100 verifies/authenticates the user identification data and the third party ID and, if required based on the provisioning request, contacts 251 the user and/or user device 250 for authorization. Once authorization is received, if required, the TSE 100 sends 261 f to the third party device 260 a the data needed to fulfill the provisioning request.
  • the TSE 100 will also send to the third party device 260 a data storage/use procedures for the user to connect to the third party device directly without the need to access the TSE 100 .
  • FIG. 14 shows a flow chart 1400 of a process for provisioning low priority data to a third party database according to yet an even further embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • a provisioning request is transmitted to the authentication server 100 from a user's data device 250 .
  • a confidential data item is retrieved from the authentication server 100 based on the provisioning request.
  • the confidential data item is transmitted from the authentication server 100 to a third party database 260 a based on the provisioning request.
  • FIG. 15 displays a flow chart 1500 of a process for provisioning high priority data to a third party database according to still an even further embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • Blocks 1441 and 1442 are as described above with respect to FIG. 14 .
  • an authentication request is transmitted to the user's data device 250 where the authentication request prompts the user to send an authentication message from the user's data device 250 to the authentication server 100 .
  • the confidential data item is transmitted from the authentication server 100 to a third party database 260 a based on the provisioning request.
  • FIG. 16 depicts a flow chart 1600 of a process for a user provisioning low priority data to a third party database according to yet still an even further embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • a provisioning request is transmitted to the authentication server 100 from a third party's data device 260 a , where the provisioning request includes a user identifier and a third party data device identification.
  • the authentication server 100 verifies the user identifier and the third party data device identification.
  • a confidential data item is retrieved from the authentication server 100 based on the verification of the user identifier, the verification of the third party data device identification, and the provisioning request.
  • the confidential data item is transmitted from the authentication server 100 to a third party database 260 a based on the provisioning request.
  • FIG. 17 illustrates a flow chart 1700 of a process for a user provisioning high priority data to a third party database according to an embodiment of the present subject matter.
  • Blocks 410 , 420 , 430 , and 440 are as described above with respect to FIG. 4 .
  • Blocks 1641 and 1642 are as described above with respect to FIG. 16 .
  • Block 1543 is as described above with respect to FIG. 15 .
  • a confidential data item is retrieved from the authentication server 100 based on the verification of the user identifier, the verification of the third party data device identification, the receipt of the authentication message, and the provisioning request.
  • the confidential data item is transmitted from the authentication server 100 to a third party database 260 a based on the provisioning request.
  • FIG. 18 is a functional block diagram of an ID/credential system illustrating the process of creating an ID/credential and transmitting the ID/credential to a user's data device 250 according to another embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • the user device 250 is as described above with respect to FIG. 2 .
  • Communication between the TSE 100 , via the TSDB 110 , and the user device 250 is via communication pathway 251 , as described above.
  • the TSE 100 can create and/or store for a user the user's ID and/or credentials, as discussed above.
  • the user can then grant access to those third parties that the user authorizes to retrieve a portion or all of the user's data.
  • the user's data may be saved in level sets, i.e., a first group of information may be in a low-level access set, such as the user's publicly-known information. Other information may be in a high-level access set, such as the user's non-publicly-known information such as account numbers, social security number, driver's license number, etc.
  • the user may set up a universal ID/credential (“UID”) to ease access to multiple third party devices.
  • the UID is the public information of private and sensitive ID/credential data saved for the user in the TSE 100 .
  • the UID can be used by any third party that needs to verify the identity of the user.
  • a process for provisioning user data with the TSE 100 includes the user sending a first set of information to the TSE 100 via the TSDB 110 .
  • This first set of information includes actual ID/credential data to be stored, for example, the user's driver's license number. Also included, if applicable, is the UID of the user and a provisioning request informing the TSE 100 of how to handle the actual ID/credential data.
  • the TSDB 110 receives the provisioning request and passes it to the TIS 120 .
  • the TIS 120 determines the type of actual ID/credential data received from the user, determines if it is secure or non-secure (e.g., public) data, and determines what routines need to be run (e.g., store the actual ID/credential data and/or create a token and/or create derivative data).
  • the TIS 120 will also create a table (or similar indexable data structure) in the user's storage space in the TSS 130 and/or DSS 140 where the table will include the actual data, a token for the actual data, and a derivative of the actual data.
  • the table may be indexed by PIN, username/password, user ID/credential, access code, etc.
  • the TIS 120 then sends the table to secure storage (TSS 130 and/or DSS 140 ) for storage in the user's profile.
  • the TIS 120 then sends, via the TSDB 110 , an acknowledgement message to the user that the provisioning request has been completed.
  • FIG. 19 shows a flow chart 1900 for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device according to yet another embodiment of the present subject matter.
  • a first data set is wirelessly conveyed from a user's data device, such as device 250 in FIG. 2 , to an authentication server, such as TSE 100 in FIG. 2 .
  • the first data set includes a user identifier, a confidential data item of the user, and a request to process the confidential data item, as discussed above with respect to FIG. 2 .
  • the first data set further includes a unique transaction identifier corresponding to the request to process the confidential data item.
  • the first data set is processed to determine that a security protocol is associated with the confidential data item and to determine that the request is a storage request, as discussed above with respect to FIG. 2 .
  • a second dataset is generated, where the second data set is a result of operating on the confidential data item with a one-way function, as discussed above with respect to FIG. 2 .
  • the confidential data item and the second data are stored in a user profile at a database, such as TSS 130 and/or DSS 140 .
  • FIG. 20 illustrates a flow chart 2000 for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device and generating additional data using a one-way function according to still another embodiment of the present subject matter.
  • Blocks 1910 , 420 , 430 , and 1940 are as described above with respect to FIG. 19 .
  • a third data set is generated, where the third data set is a result of operating on the confidential data item and the user identifier with a one-way function.
  • the third data set is stored in the user profile at the database TSS 130 and/or DSS 140 .
  • FIG. 21 depicts a flow chart 2100 for a method for provisioning an authentication system including storing a confidential data item in a user's profile of a secure storage device and sending an acknowledgement of the provisioning according to yet still another embodiment of the present subject matter.
  • Blocks 1910 , 420 , 430 , and 1940 are as described above with respect to FIG. 19 .
  • an acknowledgement message from the authentication server to the user's data device is transmitted based on receipt of the user identifier at the authentication server 100 , where the acknowledgement message provides a notification to the user that the authentication system has been provisioned for secure storage of the confidential data item.
  • FIG. 22 a functional block diagram 2200 is presented exemplifying an ID/credential system illustrating storing, in a secure storage device, an ID/credential created by a third party according to a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • Third parties 260 a and 260 b , and user/user's device 250 are as described above with respect to FIG. 2 .
  • FIG. 22 a functional block diagram 2200 is presented exemplifying an ID/credential system illustrating storing, in a secure storage device, an ID/credential created by a third party according to a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • Third parties 260 a and 260 b , and user/user's device 250
  • the third party device 260 b creates user ID/credentials 262 b upon receipt of instructions 252 from the user, either via the user's device 250 or directly from the user into the third party device without use of the user's device.
  • the user then transmits to the TSE 100 , via the TSDB 110 , from the user's device 250 the ID/credentials 263 b .
  • the TSDB 110 transfers the ID/credentials to the TIS 120 which determines the handling protocol for the ID/credentials and, in an embodiment, stores the ID/credentials in the TSS 130 and/or DSS 140 .
  • the user can instruct the TSE to request the ID/credentials directly from the third party device 260 b , via communication channel 261 b .
  • the third party device 260 b must be set up with the correct software/firmware/hardware and/or application to communicate with the TSDB 110 , as discussed above.
  • the TIS determines the handling protocol for the ID/credentials and, in an embodiment, stores the ID/credentials in the TSS 130 and/or DSS 140 .
  • the user will be able to access the ID/credentials from any approved data device, computer, website, application, etc. Additionally, an approved third party that has been granted access by the user may also be able to access the user's ID/credentials 263 b from any approved third party data device, computer, website, application, etc.
  • FIG. 23 a functional block diagram 2300 is depicted for an ID/credential system illustrating a user manually storing in a secure storage device an ID/credential created by a third party according to yet a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • Third parties 260 a and 260 b , and user/user's device 250 are as described above with respect to FIG. 2 .
  • FIG. 23 a functional block diagram 2300 is depicted for an ID/credential system illustrating a user manually storing in a secure storage device an ID/credential created by a third party according to yet a further embodiment of the present subject matter.
  • TSE 100 , TSDB 110 , TIS 120 , TSS 130 , and DSS 140 are as described above with respect to FIG. 2 .
  • the third party device 260 b creates user ID/credentials 262 b upon receipt of instructions 252 from the user, either via the user's device 250 or directly from the user into the third party device without use of the user's device.
  • the user then manually enters the ID/credential data 263 b into the TSE 100 , such as by manually entering the ID/credential data via a website for the TSE 100 .
  • FIG. 24 is a representation of a flow chart 2400 for a method for provisioning an authentication system according to still a further embodiment of the present subject matter.
  • a first data set is provided to an authentication server, such as TSE 100 , where the first data set includes a user identifier associated with a user, a confidential data item of the user, a device identifier associated with a first device, and a request to process the confidential data item.
  • the first data set is processed to determine that a security protocol is associated with the confidential data item and to determine that the request is a storage request.
  • a second data set and a third data set are generated, where the second data set is generated as a result of operating on the confidential data item with a one-way function, which, in an embodiment, is a hash function, and the third data set is generated as a result of operating on the confidential data item and the user identifier with a one-way function, which, in an embodiment, is a hash function.
  • the device identifier is verified to be associated with an account of the user, where the account is stored in a database at the authentication server 100 .
  • the confidential data item, the second data, and the third data are stored in a user profile at the database.
  • providing the first data set to the authentication server includes wirelessly conveying the first data set from the first device to the authentication server 100 .
  • providing the first data set to the authentication server includes receiving the confidential data item via manual input from the user at the first device, and transmitting the confidential data item from the second device to the authentication server 100 .
  • FIG. 25 shows a flow chart 2500 for a method for provisioning an authentication system including displaying a notification of the provisioning according to yet still a further embodiment of the present subject matter.
  • Blocks 2410 , 420 , 1430 , 2440 , and 2450 are as described above with respect to FIG. 24 .
  • a notification is displayed indicating that the authentication system has been provisioned for secure storage of the confidential data item.
  • FIG. 26 presents a flow chart 2600 for a method for provisioning an authentication system including receiving an activation code according to even a further embodiment of the present subject matter.
  • an activation code is received at a first device, such as third party device 260 b in FIG. 23 , via manual entry by a user.
  • a first data set is transmitted from the first device 260 b to an authentication server 100 , where the first data set includes the activation code, a user identifier associated with the user, a confidential data item of the user, a device identifier associated with the first device 260 b , and a request to process the confidential data item.
  • the first data set is processed to determine that a security protocol is associated with the confidential data item and to determine that the request is a storage request, as discussed above.
  • a second data set and a third data set are generated, where the second data set is generated as a result of operating on the confidential data item with a one-way function, such as a hash function, and the third data set is generated as a result of operating on the confidential data item and the user identifier with a one-way function, such as a hash function.
  • the activation code is verified to have been previously issued for the user by an entity.
  • the determined security protocol, the determined storage request, and the verified activation code, the confidential data item, the second data, and the third data are stored in a user profile at the database.
  • FIG. 27 a flow chart 2700 is presented for a method for provisioning an authentication system including receiving an activation code and sending a success message according to yet even a further embodiment of the present subject matter.
  • Blocks 2610 , 2615 , 420 , 2430 , 2640 , and 2650 are as described above with respect to FIG. 26 .
  • a success message is sent to the first device to indicate successful provisioning of the confidential data item.
  • 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.
  • 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.
  • a display device e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor
  • a keyboard and a pointing device e.g., a mouse, trackpad, touchscreen, or a trackball
  • 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.
  • 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.
  • LAN local area network
  • WAN wide area network
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
US14/421,005 2012-08-16 2013-08-13 System and method for electronic credentials Abandoned US20150207789A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/421,005 US20150207789A1 (en) 2012-08-16 2013-08-13 System and method for electronic credentials

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261683954P 2012-08-16 2012-08-16
US201361753561P 2013-01-17 2013-01-17
US201361779237P 2013-03-13 2013-03-13
PCT/US2013/054766 WO2014028514A2 (fr) 2012-08-16 2013-08-13 Système et procédé relatifs à des authentifiants électroniques
US14/421,005 US20150207789A1 (en) 2012-08-16 2013-08-13 System and method for electronic credentials

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/054766 A-371-Of-International WO2014028514A2 (fr) 2012-08-16 2013-08-13 Système et procédé relatifs à des authentifiants électroniques

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/456,906 Continuation US10999268B2 (en) 2012-08-16 2019-06-28 System and method for electronic credentials

Publications (1)

Publication Number Publication Date
US20150207789A1 true US20150207789A1 (en) 2015-07-23

Family

ID=50101453

Family Applications (5)

Application Number Title Priority Date Filing Date
US14/420,996 Active US9386003B2 (en) 2012-08-16 2013-08-13 System and method for secure transactions
US14/421,013 Abandoned US20150235215A1 (en) 2012-08-16 2013-08-13 System and Method for Mobile or Web-Based Payment/Credential Process
US14/421,005 Abandoned US20150207789A1 (en) 2012-08-16 2013-08-13 System and method for electronic credentials
US16/456,906 Active US10999268B2 (en) 2012-08-16 2019-06-28 System and method for electronic credentials
US17/222,510 Abandoned US20210226941A1 (en) 2012-08-16 2021-04-05 System and method for electronic credentials

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US14/420,996 Active US9386003B2 (en) 2012-08-16 2013-08-13 System and method for secure transactions
US14/421,013 Abandoned US20150235215A1 (en) 2012-08-16 2013-08-13 System and Method for Mobile or Web-Based Payment/Credential Process

Family Applications After (2)

Application Number Title Priority Date Filing Date
US16/456,906 Active US10999268B2 (en) 2012-08-16 2019-06-28 System and method for electronic credentials
US17/222,510 Abandoned US20210226941A1 (en) 2012-08-16 2021-04-05 System and method for electronic credentials

Country Status (2)

Country Link
US (5) US9386003B2 (fr)
WO (3) WO2014028516A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10243930B2 (en) 2017-01-11 2019-03-26 Mastercard International Incorporated Systems and methods for secure communication bootstrapping of a device
US10657233B1 (en) * 2016-09-30 2020-05-19 Assa Abloy Ab Extending electronic ID information
US10769262B1 (en) * 2014-01-17 2020-09-08 Microstrategy Incorporated Enabling use of credentials
US20210073205A1 (en) * 2015-10-20 2021-03-11 Sanjay JAYARAM System for managing data
US11615199B1 (en) 2014-12-31 2023-03-28 Idemia Identity & Security USA LLC User authentication for digital identifications
US11720709B1 (en) * 2020-12-04 2023-08-08 Wells Fargo Bank, N.A. Systems and methods for ad hoc synthetic persona creation

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9544143B2 (en) 2010-03-03 2017-01-10 Duo Security, Inc. System and method of notifying mobile devices to complete transactions
US9532222B2 (en) 2010-03-03 2016-12-27 Duo Security, Inc. System and method of notifying mobile devices to complete transactions after additional agent verification
US9467463B2 (en) 2011-09-02 2016-10-11 Duo Security, Inc. System and method for assessing vulnerability of a mobile device
US9524388B2 (en) 2011-10-07 2016-12-20 Duo Security, Inc. System and method for enforcing a policy for an authenticator device
US9672504B2 (en) * 2012-02-16 2017-06-06 Paypal, Inc. Processing payment at a point of sale with limited information
US9338156B2 (en) 2013-02-22 2016-05-10 Duo Security, Inc. System and method for integrating two-factor authentication in a device
US9607156B2 (en) 2013-02-22 2017-03-28 Duo Security, Inc. System and method for patching a device through exploitation
AP2016009010A0 (en) * 2013-07-26 2016-01-31 Visa Int Service Ass Provisioning payment credentials to a consumer
US9092302B2 (en) 2013-09-10 2015-07-28 Duo Security, Inc. System and method for determining component version compatibility across a device ecosystem
US9608814B2 (en) 2013-09-10 2017-03-28 Duo Security, Inc. System and method for centralized key distribution
US9774448B2 (en) 2013-10-30 2017-09-26 Duo Security, Inc. System and methods for opportunistic cryptographic key management on an electronic device
US9602949B2 (en) * 2013-12-11 2017-03-21 Capital One Financial Corporation Systems and methods for populating online applications using third party platforms
US9218468B1 (en) 2013-12-16 2015-12-22 Matthew B. Rappaport Systems and methods for verifying attributes of users of online systems
GB2522929A (en) * 2014-02-11 2015-08-12 Mastercard International Inc Transaction authorisation method and system
US9330512B2 (en) * 2014-04-03 2016-05-03 Panasonic Intellectual Property Management Co., Ltd. Method for managing information
US9762590B2 (en) 2014-04-17 2017-09-12 Duo Security, Inc. System and method for an integrity focused authentication service
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11748736B1 (en) 2014-04-30 2023-09-05 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11663599B1 (en) 2014-04-30 2023-05-30 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US9961059B2 (en) 2014-07-10 2018-05-01 Red Hat Israel, Ltd. Authenticator plugin interface
US9977881B2 (en) * 2014-10-15 2018-05-22 Mastercard International Incorporated Methods, apparatus and systems for securely authenticating a person depending on context
CN111651797B (zh) * 2014-11-20 2023-05-16 创新先进技术有限公司 一种信息展示方法及装置
US10439815B1 (en) * 2014-12-30 2019-10-08 Morphotrust Usa, Llc User data validation for digital identifications
US9979719B2 (en) 2015-01-06 2018-05-22 Duo Security, Inc. System and method for converting one-time passcodes to app-based authentication
US10171476B2 (en) * 2015-01-12 2019-01-01 Sal Khan System and method for protecting the privacy of identity and financial information of the consumer conducting online business
US10853592B2 (en) * 2015-02-13 2020-12-01 Yoti Holding Limited Digital identity system
RU2606556C2 (ru) * 2015-02-20 2017-01-10 Закрытое акционерное общество "Лаборатория Касперского" Способ ввода конфиденциальных данных
US9641341B2 (en) 2015-03-31 2017-05-02 Duo Security, Inc. Method for distributed trust authentication
US10439813B2 (en) 2015-04-02 2019-10-08 Visa International Service Association Authentication and fraud prevention architecture
US11176527B2 (en) * 2015-04-28 2021-11-16 Ncr Corporation Cross-network action approval
US9930060B2 (en) 2015-06-01 2018-03-27 Duo Security, Inc. Method for enforcing endpoint health standards
US9774579B2 (en) 2015-07-27 2017-09-26 Duo Security, Inc. Method for key rotation
US10817593B1 (en) 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
US11171781B2 (en) * 2016-02-15 2021-11-09 Sal Khan System and method which using blockchain protects the privacy of access code and the identity of an individual seeking online access
JP6733238B2 (ja) * 2016-03-18 2020-07-29 富士ゼロックス株式会社 認証装置及び認証プログラム
US10419226B2 (en) 2016-09-12 2019-09-17 InfoSci, LLC Systems and methods for device authentication
US9722803B1 (en) * 2016-09-12 2017-08-01 InfoSci, LLC Systems and methods for device authentication
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
GB201617620D0 (en) * 2016-10-18 2016-11-30 Cybernetica As Composite digital signatures
US11463439B2 (en) 2017-04-21 2022-10-04 Qwerx Inc. Systems and methods for device authentication and protection of communication on a system on chip
CN109274779B (zh) * 2017-07-17 2020-09-25 华为技术有限公司 一种别名管理方法及设备
SE542213C2 (en) * 2017-07-21 2020-03-10 Identitrade Ab Method and system for creating a strong authentication for a user using a portable electronic device
US10318957B2 (en) * 2017-10-23 2019-06-11 Capital One Services, Llc Customer identification verification process
US10412113B2 (en) 2017-12-08 2019-09-10 Duo Security, Inc. Systems and methods for intelligently configuring computer security
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11658962B2 (en) 2018-12-07 2023-05-23 Cisco Technology, Inc. Systems and methods of push-based verification of a transaction
US11551190B1 (en) 2019-06-03 2023-01-10 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US11432149B1 (en) 2019-10-10 2022-08-30 Wells Fargo Bank, N.A. Self-sovereign identification via digital credentials for selected identity attributes
US11151551B2 (en) * 2019-11-04 2021-10-19 Aetna Inc. Systems and methods related to executing transactions in a hybrid cloud environment
US11539523B1 (en) 2020-07-22 2022-12-27 Wells Fargo Bank, N.A. Data creation limits
US11250112B1 (en) * 2021-02-24 2022-02-15 Shawn Joseph Graphical user interface and console management, modeling, and analysis system
US11995621B1 (en) 2021-10-22 2024-05-28 Wells Fargo Bank, N.A. Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083178A1 (en) * 2000-08-11 2002-06-27 Brothers John David West Resource distribution in network environment
US20020156879A1 (en) * 2000-12-22 2002-10-24 Delany Shawn P. Policies for modifying group membership
US6516414B1 (en) * 1999-02-26 2003-02-04 Intel Corporation Secure communication over a link
US20080052514A1 (en) * 2004-11-30 2008-02-28 Masayuki Nakae Information Sharing System, Information Sharing Method, Group Management Program and Compartment Management Program
US20080208743A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Transfer of value between mobile devices in a mobile commerce system
US20100257189A1 (en) * 2009-04-03 2010-10-07 Campbell Janet L Healthcare Record System And Method For Providing Improved Portable Data
US20110072274A1 (en) * 2009-03-31 2011-03-24 Topaz Systems, Inc. Distributed system for multi-function secure verifiable signer authentication
US20110087877A1 (en) * 2009-10-08 2011-04-14 Compriva Communications Privacy Solutions, Inc. System, device and method for securely transferring data across a network
US20130030854A1 (en) * 2011-07-29 2013-01-31 Avaya Inc. Method and system for managing contacts in a contact center
US8666763B2 (en) * 2006-11-01 2014-03-04 Walgreen Co. System and method for a lifestyle management system

Family Cites Families (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US20040243478A1 (en) * 1996-09-04 2004-12-02 Walker Jay S. Purchasing, redemption, and settlement systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network
US7379901B1 (en) 1998-09-11 2008-05-27 Lv Partners, L.P. Accessing a vendor web site using personal account information retrieved from a credit card company web site
US7366702B2 (en) * 1999-07-30 2008-04-29 Ipass Inc. System and method for secure network purchasing
US7376587B1 (en) * 2000-07-11 2008-05-20 Western Union Financial Services, Inc. Method for enabling transfer of funds through a computer network
WO2002001376A1 (fr) * 2000-06-28 2002-01-03 Yozan Inc. Ordinateur hote, dispositif de communication mobile, programme et support d'enregistrement
US7552333B2 (en) * 2000-08-04 2009-06-23 First Data Corporation Trusted authentication digital signature (tads) system
US20030159032A1 (en) 2000-08-16 2003-08-21 Edgardo Gerck Automatically generating unique, one-way compact and mnemonic voter credentials that support privacy and security services
US6938019B1 (en) * 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
AU2002239481A1 (en) 2000-10-30 2002-05-27 Raf Technology, Inc. Verification engine for user authentication
US7000116B2 (en) 2001-03-12 2006-02-14 International Business Machines Corporation Password value based on geographic location
US7996324B2 (en) * 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US7762457B2 (en) * 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US7725404B2 (en) * 2002-02-27 2010-05-25 Imagineer Software, Inc. Secure electronic commerce using mutating identifiers
US8700729B2 (en) 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US20070038512A1 (en) * 2005-08-12 2007-02-15 Venkateshwara Reddy Product and service offering via website intermediary
EP2667345A3 (fr) 2005-10-06 2014-08-27 C-Sam, Inc. Services transactionnels
US8020190B2 (en) * 2005-10-14 2011-09-13 Sdc Software, Inc. Enhanced browser security
US7734632B2 (en) * 2005-10-28 2010-06-08 Disney Enterprises, Inc. System and method for targeted ad delivery
US8234220B2 (en) 2007-02-21 2012-07-31 Weiss Kenneth P Universal secure registry
US7873573B2 (en) * 2006-03-30 2011-01-18 Obopay, Inc. Virtual pooled account for mobile banking
US20070255662A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Authenticating Wireless Person-to-Person Money Transfers
US8645217B2 (en) * 2006-05-18 2014-02-04 Shoperion, Inc. Methods and apparatus for using self-contained transaction components to facilitate online transactions
EP1873704A1 (fr) * 2006-06-30 2008-01-02 MediaKey Ltd. Procédé etsystème déterminant si l'origine d'une demande de paiement est une source de réseau de commerce électronique spécifique
US7873710B2 (en) 2007-02-06 2011-01-18 5O9, Inc. Contextual data communication platform
US7930554B2 (en) * 2007-05-31 2011-04-19 Vasco Data Security,Inc. Remote authentication and transaction signatures
US8170527B2 (en) 2007-09-26 2012-05-01 Visa U.S.A. Inc. Real-time balance on a mobile phone
WO2009070430A2 (fr) * 2007-11-08 2009-06-04 Suridx, Inc. Dispositif et procédés pour fournir des services d'authentification individualisés dynamiques échelonnables à l'aide de téléphones mobiles
CA2708778A1 (fr) 2007-12-10 2009-06-18 Deluxe Digital Studios, Inc. Procede et systeme pour une utilisation dans la coordination de dispositifs multimedias
US20090182674A1 (en) * 2008-01-14 2009-07-16 Amol Patel Facilitating financial transactions with a network device
US20090260064A1 (en) * 2008-04-15 2009-10-15 Problem Resolution Enterprise, Llc Method and process for registering a device to verify transactions
US20100153539A1 (en) * 2008-12-15 2010-06-17 Gregory Thomas Zarroli Algorithm for classification of browser links
US8423462B1 (en) * 2009-05-01 2013-04-16 Amazon Technologies, Inc. Real-time mobile wallet server
US20100312703A1 (en) * 2009-06-03 2010-12-09 Ashish Kulpati System and method for providing authentication for card not present transactions using mobile device
SE0950407A1 (sv) 2009-06-04 2010-10-05 Accumulate Ab Hanteringssystem för transaktionsidentifierare
US10333808B2 (en) * 2009-06-11 2019-06-25 Talari Networks Incorporated Methods and apparatus for providing adaptive private network centralized management system data visualization processes
WO2011032263A1 (fr) * 2009-09-17 2011-03-24 Meir Weis Système de paiement mobile avec authentification en deux points
BR112012007946A2 (pt) * 2009-10-19 2016-03-22 Faber Financial Llc método para realizar transação entre cormeciante e cliente
US8788429B2 (en) * 2009-12-30 2014-07-22 First Data Corporation Secure transaction management
AU2011223674B2 (en) * 2010-03-03 2014-08-28 Visa International Service Association Systems and methods using mobile device in payment transaction
US8380177B2 (en) * 2010-04-09 2013-02-19 Paydiant, Inc. Mobile phone payment processing methods and systems
US8898759B2 (en) * 2010-08-24 2014-11-25 Verizon Patent And Licensing Inc. Application registration, authorization, and verification
WO2012034081A1 (fr) * 2010-09-09 2012-03-15 Boku, Inc. Systèmes et procédés pour traiter des paiements par l'intermédiaire d'un système de communication
GB2546026B (en) * 2010-10-01 2017-08-23 Asio Ltd Data communication system
GB2486002A (en) * 2010-11-30 2012-06-06 Youview Tv Ltd Media Content Provision
US20120150748A1 (en) * 2010-12-14 2012-06-14 Xtreme Mobility Inc. System and method for authenticating transactions through a mobile device
US9596237B2 (en) 2010-12-14 2017-03-14 Salt Technology, Inc. System and method for initiating transactions on a mobile device
CA2724297C (fr) 2010-12-14 2013-11-12 Xtreme Mobility Inc. Methode et systeme d'autentification de transactions au moyen d'un appareil portatif
US20120158589A1 (en) 2010-12-15 2012-06-21 Edward Katzin Social Media Payment Platform Apparatuses, Methods and Systems
US8699994B2 (en) * 2010-12-16 2014-04-15 Boku, Inc. Systems and methods to selectively authenticate via mobile communications
US11004056B2 (en) * 2010-12-30 2021-05-11 Visa International Service Association Mixed mode transaction protocol
US9269104B2 (en) * 2011-01-21 2016-02-23 Paypal, Inc. Automatic detection of mobile payment applications
CN103563325B (zh) 2011-01-27 2017-04-26 安全第一公司 用于保护数据的系统和方法
US20120293465A1 (en) * 2011-05-19 2012-11-22 Ankur Nandu Solution for location based notification of intelligent discovery application to user
US9165294B2 (en) * 2011-08-24 2015-10-20 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US9853959B1 (en) * 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US20130325643A1 (en) * 2012-05-31 2013-12-05 Bank Of America Isolated transaction
US20140068251A1 (en) * 2012-08-31 2014-03-06 Motorola Solutions, Inc. Method and device for dynamically updating and maintaining certificate path data across remote trust domains
US9760886B2 (en) * 2013-05-10 2017-09-12 Visa International Service Association Device provisioning using partial personalization scripts
US10565615B2 (en) * 2014-07-01 2020-02-18 Transform Sr Brands Llc System and method for personalized add-on purchase
US10062073B2 (en) * 2014-08-26 2018-08-28 American Express Travel Related Services Company, Inc. System and method for providing a BLUETOOTH low energy mobile payment system
US9990621B1 (en) * 2015-03-20 2018-06-05 Square, Inc. Merchant application programming interface for splitting bills

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6516414B1 (en) * 1999-02-26 2003-02-04 Intel Corporation Secure communication over a link
US20020083178A1 (en) * 2000-08-11 2002-06-27 Brothers John David West Resource distribution in network environment
US20020156879A1 (en) * 2000-12-22 2002-10-24 Delany Shawn P. Policies for modifying group membership
US20080052514A1 (en) * 2004-11-30 2008-02-28 Masayuki Nakae Information Sharing System, Information Sharing Method, Group Management Program and Compartment Management Program
US8666763B2 (en) * 2006-11-01 2014-03-04 Walgreen Co. System and method for a lifestyle management system
US20080208743A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Transfer of value between mobile devices in a mobile commerce system
US20110072274A1 (en) * 2009-03-31 2011-03-24 Topaz Systems, Inc. Distributed system for multi-function secure verifiable signer authentication
US20100257189A1 (en) * 2009-04-03 2010-10-07 Campbell Janet L Healthcare Record System And Method For Providing Improved Portable Data
US20110087877A1 (en) * 2009-10-08 2011-04-14 Compriva Communications Privacy Solutions, Inc. System, device and method for securely transferring data across a network
US20130030854A1 (en) * 2011-07-29 2013-01-31 Avaya Inc. Method and system for managing contacts in a contact center

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CGI, Public Key Encryption and Digital Signature: How do they work?, 2004, CGI, White Paper, pages 8 - 10 *
CGI, White Paper: Public Key Encryption and Digital Signature: How do they work?, 2004, CGI Group Inc., all pages *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10769262B1 (en) * 2014-01-17 2020-09-08 Microstrategy Incorporated Enabling use of credentials
US11615199B1 (en) 2014-12-31 2023-03-28 Idemia Identity & Security USA LLC User authentication for digital identifications
US20210073205A1 (en) * 2015-10-20 2021-03-11 Sanjay JAYARAM System for managing data
US11829344B2 (en) * 2015-10-20 2023-11-28 Sanjay JAYARAM System for managing data
US10657233B1 (en) * 2016-09-30 2020-05-19 Assa Abloy Ab Extending electronic ID information
US10243930B2 (en) 2017-01-11 2019-03-26 Mastercard International Incorporated Systems and methods for secure communication bootstrapping of a device
US11720709B1 (en) * 2020-12-04 2023-08-08 Wells Fargo Bank, N.A. Systems and methods for ad hoc synthetic persona creation
US20230274030A1 (en) * 2020-12-04 2023-08-31 Wells Fargo Bank, N.A. Systems and methods for ad hoc synthetic persona creation

Also Published As

Publication number Publication date
US20190319944A1 (en) 2019-10-17
WO2014028510A2 (fr) 2014-02-20
WO2014028514A3 (fr) 2014-05-08
WO2014028516A1 (fr) 2014-02-20
US10999268B2 (en) 2021-05-04
WO2014028510A3 (fr) 2014-05-15
US20150235215A1 (en) 2015-08-20
WO2014028514A2 (fr) 2014-02-20
US9386003B2 (en) 2016-07-05
US20150237026A1 (en) 2015-08-20
US20210226941A1 (en) 2021-07-22

Similar Documents

Publication Publication Date Title
US10999268B2 (en) System and method for electronic credentials
US10829088B2 (en) Identity management for implementing vehicle access and operation management
US10685526B2 (en) Architecture for access management
US11763305B1 (en) Distributed ledger for device management
US11706212B2 (en) Method for securing electronic transactions
EP3460690A1 (fr) Utilisation de la gestion d'identités et d'accès pour la fourniture de services
US8079082B2 (en) Verification of software application authenticity
JP2004515840A (ja) アクセス認証エンティティ用の方法および装置
KR102190192B1 (ko) 오픈뱅킹 환경에서의 개방형 인증 중개 서비스 제공 방법, 시스템 및 애플리케이션
KR101719511B1 (ko) 네트워크를 사용하여 게이트에 대한 액세스 허용 여부를 결정하는 방법, 서버 및 컴퓨터 판독 가능한 기록 매체
KR20070029537A (ko) 무선단말기와 연동한 개인별고유코드를 활용한인증시스템과 그 방법
EP4050923A1 (fr) Systèmes et procédés de validation d'accès à l'aide de la gestion d'identité d'un registre réparti
US20210319116A1 (en) Systems and methods of access validation using distributed ledger identity management
WO2016131664A1 (fr) Procédé pour extraire, par un serveur de paiement, un numéro de compte permanent de financement à partir d'un numéro de compte de paiement de jeton
US11860992B1 (en) Authentication and authorization for access to soft and hard assets
US11854011B1 (en) Identity management framework
CN117455489A (zh) 交易授权方法、装置、设备及存储介质

Legal Events

Date Code Title Description
STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: CORT, VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KUMAR, HIMALESH CHERUKUVADA;REEL/FRAME:052088/0135

Effective date: 20200311