US20170257358A1 - Method and System for Authenticated Login Using Static or Dynamic Codes - Google Patents
Method and System for Authenticated Login Using Static or Dynamic Codes Download PDFInfo
- Publication number
- US20170257358A1 US20170257358A1 US15/449,902 US201715449902A US2017257358A1 US 20170257358 A1 US20170257358 A1 US 20170257358A1 US 201715449902 A US201715449902 A US 201715449902A US 2017257358 A1 US2017257358 A1 US 2017257358A1
- Authority
- US
- United States
- Prior art keywords
- user
- data
- envelope
- login
- web server
- 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.)
- Granted
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
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
- G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- 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
-
- 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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- 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/3236—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 cryptographic hash functions
-
- 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/3247—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 involving digital signatures
-
- 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/3271—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 challenge-response
-
- 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/3297—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 involving time stamps, e.g. generation of time stamps
-
- 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/40—Network security protocols
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
Definitions
- the present embodiments relate to methods, systems, and programs for managing the identify of users and of identifying those users to third parties, and more particularly, performing authentication and login processes using a blockchain to authenticate a user during a login process to access a web page through interactions with multiple user devices.
- the present embodiments relate to solving one or more problems found in the related art, and specifically to provide for login without requiring a user to enter a username and password.
- methods and systems are presented for authenticated login, registration and call center validation.
- Other methods and systems are presented for scanning a dynamic code on a browser screen to authorize user login.
- Still other methods and systems are presented for certified user generated data (e.g., biometrics).
- biometrics e.g., biometrics
- a method for authentication being performed at a web server providing web access is disclosed.
- the method is performed when implementing a login process to a web portal of a web server.
- the method includes sending a login web page to a first device associated with a user.
- the login web page may have been requested by the user.
- the login web page includes a scannable code including an envelope ID and a login challenge.
- the envelope ID is associated with a first envelope of data including a session ID, wherein the envelope ID is generated by an identity manager at the request of the web server.
- the method includes receiving a confirmation login request responding to the login challenge from a second device associated with the user, wherein the confirmation login request includes a second envelope of data including the session ID, a user ID, and a seal of the user ID registering the user ID with the identity manager.
- the method includes verifying the confirmation login request to the login challenge using the session ID from the confirmation login request.
- the method includes verifying the user using the user ID and seal.
- the method includes authorizing user login upon successful verification of the login challenge and user.
- the method includes establishing a communication session having the session ID between the web server and the first device when the login is authorized.
- a method for authentication such as for requesting login access to a web portal of a web server, being performed at a second device of a user that includes scanning a dynamic code on a browser screen that is implemented to enhance a user login process.
- the method includes scanning a first scannable code on a login web page of a web server displayed on a first device associated with the user.
- the scannable code includes an envelope ID and a login challenge, wherein the envelope ID is associated with a first envelope of data generated by the web server, wherein the envelope of data includes a session ID.
- the envelope ID is generated by an identity manager at the request of the web server, and is used to request the first envelope of data from the identity manager.
- the method includes generating a challenge envelope of data including a shared-string generated by the second device, a first digital signature of a hash of the shared-string and a user ID using a private key of the user.
- the method includes sending the challenge envelope of data to the web server over a network.
- the method includes scanning a second scannable code on an updated login web page displayed on the first device.
- the second scannable code includes a challenge response including the shared-string and a second digital signature of a hash of the shared-string using a private key of the web server.
- the method includes verifying the second digital signature using a public key of the web server.
- the method includes generating a confirmation login request responding to the login challenge.
- the confirmation login request includes a second envelope of data including the shared-string, the session ID, the user ID, and a seal of the user ID registering the user ID with the identity manager; added to this second envelope of data is a digital signature of a hash of the data fields included using a private key of the user.
- the method includes sending the confirmation login request to the web server via the identity manager for authentication and login of the user with the web server.
- a method of authentication implementing the certification of user generated data is disclosed.
- the method may be performed by an authenticating entity of a web server, such as when authenticating a user (e.g., to control access to products and/or services).
- the method includes receiving from a device of a user a user envelope of data that includes user data and a unique session ID issued by the server and a first signature of a hash of the user data signed and the session ID by a private key of the user, wherein the user data includes a user ID, newly created biometric data, newly presented original biometric data associated with the newly created biometric data, validating seal associated with the original biometric data including a first transaction number of a first blockchain, and a certifying seal associated with the original biometric data including a second transaction number of a second blockchain.
- the method includes verifying the first signature using the public key of the user.
- the method includes verifying the certification of the original biometric data using the certifying seal and the newly presented original biometric.
- FIG. 1A illustrates a data flow for registering data in a blockchain, such as for registering user identification, in accordance with one embodiment of the present disclosure.
- FIG. 1B illustrates a data flow for certifying the registered data using a blockchain, such as for certifying user identification that is registered with an identity manager, in accordance with one embodiment of the present disclosure.
- FIG. 1C illustrates a data flow for verifying the registered data, and for verifying the certification of the registered data, in accordance with one embodiment of the present disclosure.
- FIG. 2 illustrates the implementation of a blockchain to ensure the integrity of the data embedded within, in accordance with one embodiment of the present disclosure.
- FIG. 3 is a diagram illustrating a system for performing authentication and login onto a web portal of a web server, wherein two devices of the user interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure.
- FIGS. 4A-4B illustrates a data flow for performing authentication and login onto a web portal of a web server as illustrated in FIG. 3 , wherein two devices of the user interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure.
- FIG. 4C illustrates a data flow when exchanging a secure envelope of data between two entities via an identity manager server, such as when performing authentication and login onto a web portal of a web server as illustrated in FIGS. 4A-4B , in accordance with one embodiment of the present disclosure.
- FIG. 4D is a diagram illustrating a process for logging into a website using a QR code, in accordance with one embodiment of the present disclosure.
- FIG. 5 is a diagram illustrating a process including a push notification login, in accordance with one embodiment of the present disclosure.
- FIGS. 6A-6D are diagrams illustrating a process for registering new users to a service provider website, in accordance with one embodiment of the present disclosure.
- FIG. 7A illustrates a data flow for using a dynamic code to implement a challenge code that is passed between devices used when performing authentication and login onto a web portal of a web server as illustrated in FIGS. 4A-4B , in accordance with one embodiment of the present disclosure.
- FIG. 7B illustrates a QR code including a session ID, in accordance with one embodiment of the present disclosure.
- FIG. 7C includes a second bar code including a signed shared-string, in accordance with one embodiment of the present disclosure.
- FIG. 8A is a diagram illustrating a system for performing biometric authentication of a user, in accordance with one embodiment of the present disclosure.
- FIG. 8B illustrates a data flow for using the verification of the certification of user generated data (e.g., biometrics), such as in a method for authenticating the user, to control access to products and/or services, in accordance with one embodiment of the present disclosure.
- user generated data e.g., biometrics
- FIG. 9A is a diagram illustrating a process for registering and validating a user, which in this case is the Traveler, in accordance with one embodiment of the present disclosure.
- FIG. 9B is a diagram illustrating a process for registering and validating the image of the Traveler (e.g., selfie), in accordance with one embodiment of the present disclosure.
- FIGS. 10A-10B are diagrams illustrating the authentication of a Traveler at a transportation service (e.g., airline), in accordance with one embodiment of the present disclosure.
- a transportation service e.g., airline
- FIGS. 11A-11B are diagrams illustrating a method for checking a certification of a Traveler, such as by an Agent of a transportation service, in accordance with one embodiment of the present disclosure
- FIGS. 12A-12B are diagrams illustrating a method for registering an Agent of a transportation service and logging in the Agent, in accordance with one embodiment of the present disclosure.
- FIG. 13 is a diagram illustrating a method for performing third party certification of custom name/value pairs, in accordance with one embodiment of the present disclosure.
- FIG. 14 illustrates components of an example device that can be used to perform aspects of the various embodiments of the present disclosure.
- embodiments of the present disclosure describe systems and methods that provide for authenticated login, registration, and call center validation.
- embodiments of the present invention allow users to login to websites, services and other portals without the use of usernames or passwords.
- embodiments of the present invention allow users to remotely validate themselves such that a remote or local operator, such as those at a call center or a teller, can definitively authenticate a user in order to gain access to their profiles and other information.
- Other embodiments of the present disclosure describe systems and methods that provide for certification of user generated data (e.g., biometrics), which can be used for authenticating a user, and for providing access based on the certification.
- Embodiments of the present invention are based on an identity management platform implementing a technology layer that interacts with a blockchain.
- the blockchain securely holds data used for certifying identity transactions.
- a blockchain is a technology that forms the heart of the cryptocurrency, Bitcoin.
- the blockchain technology can be used by several integrated systems for purposes other than currency transactions, such as for identity management.
- registration e.g., of a user
- a certification process may be processed for certifying the registration and/or validation.
- some form of user identification e.g., a driver's license or passport
- One or more fields are extracted, such as your name, license number, passport number, date of birth (or other data), etc.
- identifying information can be gathered individually. Further, the identifying information can be gathered manually. The data is then processed to produce a hash of the data.
- the hash can be produced of the original data along with a paired random data to prevent brute-force discovery of the hashed data; in this case, to validate the hash, the data and the random data must always be used together.
- the private key that is present on the mobile device can be used to create a digital signature of that hash.
- the signed hash value and optionally the public key of the user are stored to the blockchain; if the public key is not stored on the blockchain, it can be shared through other means when it is necessary to validate the digital signature.
- the various fields are put together in one record to create an ID (e.g., in the form of a seal) for that user.
- the user can then provide the raw data with a public key and a pointer to that record on the blockchain in order to allow verification of the data by a third party.
- this provides a correlation between the data (e.g., the raw data) that the user has on the mobile device and what's on the blockchain. That is, the raw data that is newly presented may be verified using the data on the blockchain.
- a user can be certified by some other trusted party, such as a hank or “know your customer” (KYC) checking company, which then can issue a certification for the user, based on the seal associated with the registration and validation of the user.
- KYC knowledge your customer
- these certifiers can use their own private key to write the records on the blockchain, pointing to record entry of the user that is also on the blockchain.
- This certification may be referred to as the “User ID” (e.g., ShoCard ID issued by ShoCard, Inc.).
- the first step is the registration process where hash signatures of the individual fields are sealed on the blockchain
- the second step is a certification of the sealed registration.
- the platform providing registration and certification also provides for a secure work-around in cases when a bank suspects a credit card transaction could be fraudulent and wants to reject that transaction.
- the bank for example, can send a notification/challenge (e.g., a secure notification), wherein the challenge looks for a response confirming the user, and the challenge also confirms that the user authorizes the current transaction.
- Additional features can include use of a biometrics for access-control (e.g., Touch ID).
- Touch ID e.g., Touch ID
- each time a private key can be accessed to answer those questions.
- by using the private key of the user when responding to questions i.e., to see the data or questions), it is possible to avoid using clear text, which can ultimately be hacked.
- embodiments of the present invention provide for being able to authenticate the user whenever the user does any kind of transaction, such as logging into a website, calling a call center, authenticating a transaction.
- the systems, methods, and technical operations described herein, and based on the identity management platform providing for registration and/or certification of data can be implemented with the confidence of knowing who the user really is, and enabling this verification process in a timely manner.
- the registration and/or validation process may be referred to as “sealing.” Certification of the registration may be referred to as “certifying.”
- sealing is the process of hashing and digitally signing the User ID data and storing it in the blockchain. Once it is sealed in the blockchain, the data becomes a permanent record. The data in the user ID may be changed, but the new data must be resealed in a new blockchain record.
- no readable information is stored in the blockchain, only an indecipherable digital signature of a hash that can only be verified by producing the original data that was hashed and the user's public key. The user data is in control of the user and not available on the blockchain.
- Certification of the registration and/or validation is the process of another party (e.g., third party, bank, airline, etc.) acknowledging the accuracy of the user ID that is registered, and marking that data (e.g., user ID) with a certification that can be recognized, such that the data can be recognized as being accurate when presented in the future, without having to see any other evidence of identity beyond the user ID.
- the raw data e.g., user ID
- the certifier performs decryption and generates a new hash based on the newly presented raw data and then verifies the digital signature of the hash on the blockchain against the newly generated hash and the public key of the user.
- the certifier can create a new record (e.g., certification record) with their own private key(s) that references the user ID that is registered and stored in the blockchain.
- the third party can check the certification to make sure that the user is presenting the same user ID that was previously certified.
- identity verification e.g., verification of a registration and/or certification of data
- commercial applications may include those that require commercial entities to verify the identity of a user. Verifying the identity of a user can be required for achieving any number of functions, such as traveling, making transactions, banking, communication, loan verification, credit verification, purchase verification, and other uses.
- private identity verification can also be facilitated using the methods, apparatus, computer readable media, and systems described herein.
- private identity verification may be useful when a user wishes to prove their identity to another user in a fast and efficient manner.
- the systems and methods described herein write data to the blockchain database, which is non-rewritable and permanently maintains the record without compromise. This enables writing of information to the blockchain in a manner that can be verified by one or more transactions executed by methods of the present inventions.
- the systems and methods described herein may be executed with any number of computer systems.
- the computer systems may include user devices, such as mobile phones, tablets, desktop computers, watch computers, head attached computers, eyeglasses computers, or combinations thereof.
- Server operations may also be performed and communicated between client devices, to facilitate transactions with the blockchain database, server storage, and the like.
- these computer devices can communicate over networks, such as the Internet, local area networks, Bluetooth, Near Field Communication (NFC), or even via exchange of codes such as QR codes.
- the networks enable individual devices to transact with each other, such as by way of sending, receiving, and processing exchanged information.
- the exchanged information can include different types of encrypted data, hashed data, data envelopes, codes, QR codes, PDF417 codes, messages, notifications, and other types of data.
- the messaging and communication functions described herein are provided to enable users to exchange data over communication networks in order to verify identity, or enable or provide access to users to services, goods, or commercial transactions.
- the verification process can be utilized by banks, as well as users of the bank, or third parties that require certified information from the banks regarding those users.
- different travel entities can require identification of users, and the identification can also be verified by themselves or by other third parties that are trusted.
- These operations can be facilitated using the systems, methods, computer readable media, and code that execute the verification processes.
- verification of a user identity e.g., verification of the registration and/or certification of data, such as user ID
- the use of verification is simply facilitated by using the verifying infrastructure, programs code, applications, and combinations thereof, to ensure that verification is secure.
- the verification systems can be embodied in an application, such as those that can be installed on mobile devices (e.g., Apps).
- apps e.g., Apps
- users wishing to have their identity verified can use an application to seal information regarding their identity.
- the data e.g., encrypted data has been stored to the blockchain
- this data e.g., raw data
- the other party may also be utilizing a corresponding App, which enables efficient reading of the data, code, QR code, message, or notification, to validate the identity of the user.
- code plug-ins can be integrated into commercial websites, which may use identity verification for different reasons or functions.
- banks can install plug-in applications, code, or programs that can execute part or all of the verification processing to seal information and/or to certify information regarding identity.
- FIGS. 1A-1C show data flows for the registration and/or validation process as well as the certification of the registered data, for example, as implemented by the identity management platform described herein, in embodiments of the present invention. These processes are performed to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics).
- user generated data e.g., biometrics
- FIG. 1A illustrates a data flow 100 A for registering data in a blockchain, such as for registering user identification, in accordance with one embodiment of the present disclosure.
- a user 5 may generate and/or capture any type of raw data (UGD) and have that data certified by a third party (e.g., certifier).
- UMD raw data
- certifier e.g., certifier
- the data can be any of the following types, but not limited only to these types of data: a simple text string; a date; an enumerated data type; a number; an arbitrary series of data bytes (e.g., a data block), a digital key, biometrics, etc.
- This data can be saved locally on a device associated with the user 5 (e.g., mobile phone operating an identity management application).
- the user 5 would then seal her record by writing this data to a blockchain 50 in operation 115 . This can be done by either inserting a new seal record with the added user generated data, that may overwrite any previous seal (if any), or a new seal that complements any prior seals.
- the value field written to the blockchain is for registration and/or validation of the original, raw data only.
- the user 5 is expected to securely hold onto that data (e.g., through encryption) and only share it when the user chooses to.
- the data is first hashed in operation 110 so the UGD becomes ⁇ hash.UGD>.
- any number of hashing algorithms can be used, such as SHA256.
- the user 5 then signs the ⁇ hash.UGD> with a private key of the user, producing ⁇ signed.hash.UGD> (e.g., using Touch ID).
- a seal 120 is generated that includes a transaction identifier for the blockchain that can be used to access the signed hash value ( ⁇ signed.hash.UGD>) at the appropriate location in the blockchain.
- FIG. 1B illustrates a data flow 100 B for certifying the registered data using a blockchain, such as for verifying raw data that is registered with an identity manager using a blockchain 50 , and for certifying the raw data (e.g., user identification) that is registered, in accordance with one embodiment of the present disclosure.
- the user 5 may then present the UGD (securely maintained by the user or another device storage of her choosing), along with her public-key and a pointer to the seal record 120 on the blockchain to another party.
- the other party is a verifier 30 that performs operations to verify the UGD.
- the other party is a certifier 20 that performs operations to certify the registered UGD.
- Operations 130 and 135 may be performed by the certifier 20 or verifier 30 for purposes of verifying the UGD that was previously registered, though these operations are shown as being performed by the certifier 20 .
- a request to access the registered seal record 120 is made to the public blockchain 50
- the seal record 120 is returned to the certifier.
- operations are performed for verifying the UGD.
- the data stored in the blockchain 50 is extracted, namely the signed hash value ( ⁇ signed.hash.UGD>).
- the newly presented UGD is hashed using the same hash algorithm that was performed when registering the data.
- Verification of the raw data is performed by performing a verification process on input data including the newly generated hash value, the public key of the user, and the ⁇ signed.hash.UGD> stored on the blockchain 50 .
- hash values of the UGD newly generated and based on the ⁇ signed.hash.UGD> may be compared, and is verified when the hash values match.
- the certifier 20 begins the certification process.
- validation of the raw data is performed.
- the raw data is inspected to see if it conforms to public form (e.g., follows the form of a driver's license), and is validated if the raw data as presented conforms with the public form.
- the seal 120 e.g., transaction identifier or txn-ID
- the seal 120 and public key optionally may also be hashed.
- Data may be combined in a certification record that is signed (using the private key of the certifier 20 ) and sealed in a blockchain, wherein the data may include one or more of the seal 120 of the UGD (e.g., seal txn-ID, pointer to the blockchain), the raw UGD, the certification signature (as the raw data of the certification record), public key of certifier, etc.
- the certification record is sealed in the same or different blockchain 50 , and in operation 155 the certification record seal including the pointer to the blockchain where the certification record is stored is returned to the certifier 20 for distribution.
- the certification record seal is provide to the user 5 to offer as certifying proof of the UGD, as is described in FIG. 1C .
- FIG. 1C illustrates a data flow 100 C for verifying the registered data, and for verifying the certification of the registered data, in accordance with one embodiment of the present disclosure.
- the user 5 may present the raw UGD (and other information) to a third party, along with registration and certification record information, so that the third party may verify the UGD using multiple factors (e.g., registration and/or certification).
- data may be combined for presentation, and includes one or more of the raw UGD, public key of the user 5 , seal 120 of the UGD (e.g., seal txn-ID, pointer to the blockchain), the certification signature (as the raw data of the certification record), the certification record seal (e.g., certification seal txn-ID, pointer to blockchain), public key of certifier, etc.
- the third party is verifier 30 .
- verifier 30 obtains the seal record 120 (e.g., using txn-ID for the blockchain) to obtain the data stored in the blockchain 50 (e.g., ⁇ signed.hash.UGD> and public key of user 5 ) to verify the raw data (UGD).
- the data stored in the blockchain 50 is extracted, namely the signed hash value ( ⁇ signed.hash.UGD>).
- the newly presented UGD is hashed using the same hash algorithm that was performed when registering the data.
- Verification of the raw data is performed by performing a verification process on input data including the newly generated hash value, the public key of the user, and the ⁇ signed.hash.UGD> stored on the blockchain 50 .
- hash values of the UGD newly generated and that based on the ⁇ signed.hash.UGD> may be compared, and is verified when the hash values match.
- verifier 30 obtains the certification seal record (e.g., using certification seal txn-ID for the blockchain) to obtain the data stored in the blockchain 50 (same or different blockchain). That is, at operation 190 the certification record is returned to the verifier 30 .
- operations are performed to verify the certification record.
- the data stored in the blockchain 50 is extracted, namely the certification record which may be signed using the private key of the certifier 20 (e.g., signed hash value ( ⁇ signed.certification record>).
- the newly presented certification record can be hashed using the same hash algorithm that was performed when sealing the certification record—however, the method of hashing needs to be known so it can be reproduced.
- Verification of the certification record is performed by performing a verification process on input data including the newly generated hash value, the public key of the certifier 20 , and the ⁇ signed.certification record> stored on the blockchain 50 .
- hash values of the UGD newly generated and hash valued based on the ⁇ signed.hash.UGD> e.g., using the public key
- verification of the raw data, UGD may be performed if not already performed.
- the verification has been performed on the UGD itself and a certification of the UGD.
- the presented UGD is trustworthy after going through a verification of the UGD and the certification record of the UGD.
- FIG. 2 illustrates the implementation of a blockchain to ensure the integrity of the data embedded within, in accordance with one embodiment of the present disclosure.
- the blockchain is used for implementation of processes that are performed to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics) based on the registration, validation, and/or certification of raw data.
- a simplified version of a blockchain is shown in FIG. 2 .
- a block of one or more new transactions is collected into the transaction data part of a block. Copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, which represents the merkle root of a merkle tree.
- the merkle root is stored in the block header.
- Each block also stores the hash of the previous block's header, chaining the blocks together. This ensures a transaction cannot be modified without modifying the block that records it and all prior blocks.
- FIG. 3 is a diagram illustrating a system 300 for performing authentication and login onto a web portal of a web server, wherein two devices of the user 5 interact with the web server 320 for authentication purposes, in accordance with one embodiment of the present disclosure.
- system 300 may be implemented to perform authenticated login, registration, and call center validation.
- system 300 may be configured to allow users to login to websites, services and other portals without the use of usernames or passwords. Further configurations of system 300 allow users to remotely validate themselves such that a remote or local operator, such as those at a call center or a teller, can definitively authenticate a user in order to gain access to their profiles and other information.
- Client device 310 may include a web browser configurable for communication over a network 150 , such as the internet.
- client device 310 may present to user 5 a login page of a web server 320 , wherein the login page may be delivered to the display device 12 associated with a user 5 .
- device 11 of the user 5 may be used in conjunction with client device 310 in order to perform the login process enabling client device 310 to access web server 320 .
- Client device 310 and device 11 can be any type of computing device having at least a memory 1404 and a processor module 1430 that is capable of connecting to the network 150 .
- Some examples of client device 100 include a personal computer (PC), a game console, a home theater device, a general purpose computer, mobile computing device, a tablet, a phone, or any other types of computing devices.
- Web server 320 includes any type of computing device having at least a memory 1404 and a processor module 1430 that is capable of connecting to the network 150 .
- Data store 325 may be controlled and/or accessible by web server 320 .
- Web server 320 may be configured to provide information and/or services over network 150 .
- web server 320 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics).
- Identity manager 330 includes any type of computing device having at least a memory 1404 and a processor module 1430 that is capable of connecting to the network 150 .
- Data store 335 may be controlled and/or accessible by identity manager 330 .
- identity manager 330 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics).
- FIGS. 4A-4B illustrates a data flow 400 for performing authentication and login onto a web portal of a web server 320 as illustrated in FIG. 3 , wherein two devices of the user 5 interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure.
- the data flow 400 of FIGS. 4A-4B may be implemented within the system 300 of FIG. 3 , and may implement portions of the methods described in the data flows 100 A, 100 B, and 100 C of FIGS. 1A-1C .
- parties to the login process include a user 5 , who is associated with a first device 310 and a second device 11 , an identity manager 330 , and a web server 320 , wherein the user 5 is requesting login access to the web server 320 .
- data flow 400 shows the flow of data when logging into a web site using a QR code.
- a user enters a web site and may be presented with one or more forms of authentication paths to login (for example, username/password and a button to login).
- a QR code or other similar graphics that encodes data information (such as a bar code).
- the QR code is referenced and intended to represent any type of code.
- the user uses his/her mobile application designed to comprehend the contents of the QR code and determines that this is an authentication badge for login.
- the application presents the user with a question to determine if the user chooses to login and pass his/her credentials.
- This process may request an additional form of authentication on the mobile device such as a finger thumbprint Id (e.g., touch ID, and/or other biometric identification), or a PIN passcode.
- a finger thumbprint Id e.g., touch ID, and/or other biometric identification
- PIN passcode e.g., PIN passcode
- the user 5 via the first device 310 requests a login web page from the web server 320 over a communication network (e.g., internet).
- a communication network e.g., internet
- the web server 320 Upon receiving the request for login, the web server 320 performs operations as outlined in block 405 . For example, the operations are performed to create a web envelope of data.
- a session ID is generated by web server 320 , which may be generated in response to the request for the login web page, or may be generated in anticipation of a login request (e.g., such as at a login kiosk).
- a factor in the authentication and login process is the use of the session ID, such that the session ID is used throughout the authentication and login process, thereby connecting the devices used in the process.
- the session ID is associated with a communication session that will be established after successful login of the user 5 .
- web data may be generated by the web server 320 to include one or more of the session ID, a timeout for the session ID, URL web address for the web server 320 , etc.
- the web data may optionally include the public key of the web server 320 for convenience of access with the web data, though the public key may be obtained elsewhere as commonly implemented.
- the web data may be hashed using a hash algorithm (e.g., using any number of hashing algorithms can be used, such as SHA256).
- a signature of the web data may be generated, using the private key of the web server 320 . The web data and the signature are combined into an envelope of web data.
- the web server 320 sends a request for an envelope ID to the identity manager 330 .
- the request includes the envelope of web data.
- the identity manager 330 performs operations to include storing the envelope of web data, and generating the envelope ID, which is associated with the envelope of web data. As such, the identity manager 330 is able to access the envelope of web data that is stored based on presentation of the envelope ID.
- the identity manager 330 returns the envelope ID to the web server 320 .
- a login page is generated with information facilitating authenticated login.
- web server 320 generates a scannable code (e.g., QR code), which includes at least one of the envelope ID, URL of the web server 320 , and a login challenge asking whether a login process is further requested.
- QR code e.g., QR code
- the scannable code is included in the login page. Though embodiments are described using a scannable code, other types of codes that are configured to deliver information between devices are also suitable.
- the web server delivers the login web page to the first device 310 of the user 5 .
- the first device 310 of user 5 displays the login web page that includes the scannable code, wherein the scannable code includes at least the envelope ID.
- the envelope ID is associated with a first envelope of data including the session ID, and wherein the envelope ID is generated by an identity manager 330 at the request of the web server 320 .
- various operations are performed, including configuring and/or operating the second device 11 to scan the scannable code.
- the envelope ID can be extracted, and used to access the first envelope of data.
- the scannable code is of a limited size that may not be able to accommodate the size of the first envelope of data, though in some embodiments, the scannable code may be of sufficient size.
- a factor in the authentication and login process includes the use of two devices (first device 310 and second device 11 ) associated with the user 5 .
- the second device 11 requests the first envelope of data from the identity manager 330 , wherein the request includes the envelope ID.
- the identity manager is able to access the envelope of data at operation 427 , and at operation 430 return the first envelope of data to the second device.
- the scannable code is able to include the entire data identified in block 405 , it may not be necessary to create an envelope and an envelope ID—the scannable code in this case would have the entire data.
- the session ID is extracted from the envelope of data, as well as any other data included in the envelope.
- Verification of the data may be performed, such as by verification engine 1442 .
- the verification logic is well known, and includes inputting at least one of the web data, the public key of the web server, and the signature of the web data, wherein the verification logic confirms or denies the verification of the web data. As shown in FIG. 4A , the method proceeds to connector A. The method of FIG.
- 4A may proceed to intervening connector B before returning to connector A when a dynamic code is inserted into the authentication and login process, for example to provide additional security by ensuring the proper devices are participating throughout the entire authentication and login process, as will be further described in FIGS. 7A-7C .
- the method proceeds to block 440 , wherein the second device 11 performs multiple operations after the data within the envelope of data has been verified and can be trusted.
- user data is collected and/or generated to include at least one of the session ID, user identification that may be recognizable by the web server 320 and is registered (e.g., with the identity manager 330 ), a seal of the registered data (e.g., user identification), a seal of a certification record certifying the registered data, the certification record, a login response (e.g., affirmative response to login challenge), public key of the user, etc.
- the user data is hashed ( ⁇ hash.userdata>) using any suitable hash algorithm, such as SHA256.
- the second device 11 is configured to sign the hash value with a private key of the user (e.g., producing ⁇ signed.hash.userdata>).
- the signature process may be authorized by the user for example using Touch ID.
- the user data and the signature may be encrypted using a public key of the web server 320 .
- the resulting user data and signature, or resulting encrypted user data and signature is packaged as a return envelope of data, such as a secure envelope (e.g., when encrypted).
- the user can ensure that the only entity able to read its response to the login request is the intended Web server and that the package being delivered remains unmodified.
- the signature of the user in the package can provide the Web server an assurance that this particular user has indeed composed the entire data and response being sent back. Because the data being signed also includes a unique one-time session ID, the protocol ensures that the users' response cannot be re-used for another login session using the users' credentials.
- the secure envelope of data is delivered from the second device 11 to the web server 320 via the identity manager 330 .
- the envelope is delivered in a confirmation login request that is responding to the login challenge.
- the confirmation login request includes the secure envelope of data.
- the secure envelope is received at the identity manager at operation 447 , such as in the confirmation login request, wherein the envelope is delivered at operation 450 from the identity manager 330 to the web server 320 . Because the envelope is secure, the identity manager 330 is prevented from extracting information from the envelope, and the secure envelope is delivered securely (without exposure) to web server 320 .
- various operations are performed by web server 320 upon receipt of the secure envelope in the form of the confirmation login request.
- a decryption process is performed (e.g., using the private key of the web server 320 ).
- the data in the envelope is known, to include at least one of session ID, a user ID, and a seal of the user ID registering the user ID (e.g., with the identity manager), affirmation of the login challenge, etc.
- a verification of the signature may be performed to determine whether the data is trustworthy (e.g., has not been modified during transmission).
- the verification logic includes inputting at least one of the user data provided in the envelope, the public key of the user, and the signature of the user data, wherein the verification logic confirms or denies the verification of the user data.
- the session ID may be verified as being valid. That is, the confirmation login request may be verified as a response to the login challenge issued by the web server 320 (e.g., as being part of a valid transaction) using the session ID returned with the confirmation login request. Since the web server 320 generates all the session IDs, the present session ID may be cross-checked to determine whether it is a valid session ID, and whether the session ID has not timed out, or to perform any other validation process. As shown, another factor in the authentication and login process includes the verification of the signature to trust the information (e.g., session ID), and to confirm that the user's response is in fact to this particular session ID (versus being re-used from another session).
- the user ID may be verified following the verification logic presented above. Verification of the user ID is another factor in the authentication and login process. Correspondingly, the user is verified based on the user ID that is presented. That is, inputs are provided to the verification logic to include the user ID, the public key of the user, the seal of the user ID (to include the transaction identifier for the blockchain that stores the signed hash value of the user ID), and the signature of the hash value of the user ID. The verification logic confirms or denies the verification of the user ID. Also in block 453 , the certification of the user ID may be verified following verification logic presented above. Verification of the certification of the user ID is another factor in the authentication and login process.
- inputs are provided to the verification logic to include the certification record, the public key of the user, the certification seal of the certification record (to include the transaction identifier of blockchain that stores the signed hash value of the certification record), and the signature of the hash value of the certification record.
- the verification logic confirms or denies the verification of the certification record.
- User login for user 5 is authorized upon successful verification of the login challenge and user.
- the user is authorized for login.
- a communication session is established between the web server 320 and the first device 310 of user 5 .
- FIG. 4C illustrates a data flow 400 C when exchanging a secure envelope of data between two entities via an identity manager server 330 , such as when performing authentication and login of a user 5 onto a web portal of a web server 320 as illustrated in FIGS. 4A-4B , in accordance with one embodiment of the present disclosure. That is, the data flow 400 C may be implemented to deliver a secure envelope of data between the user A (e.g., user 5 ) and user B (e.g., web server 320 ), to include participation by data store server (e.g., identity manager 330 ).
- data store server e.g., identity manager 330
- the secure exchange of data is performed between user 5 and web server 320 using identity manager 330 .
- This process allows for delivery of data when it may not be feasible to exchange large data sets directly between the two entities.
- the two entities may be on a mobile device, or be interacting via an intervening web page. In this case, the two entities cannot exchange data directly without having a communication path.
- the two entities can share data through digital codes, such as a bar-code, a QR code, PDF417 code or any other similar type of displayable codes.
- digital codes such as a bar-code, a QR code, PDF417 code or any other similar type of displayable codes.
- variable sizes of data blocks can be securely exchanged between such two entities by utilizing a server (e.g., identity manager 330 ) in the middle.
- the identity manager 330 stores and directs the message for the two entities, but is unable to ever read any of its content.
- the server in the middle includes a data store, but can be any server (e.g., identity manager 330 ).
- Block 463 illustrates multiple operations performed by user A in preparation of sending the block of data.
- user A places that data in a data block and may add additional identification fields to that block of data such as timestamp, its own seal Id, user B's seal Id, it's public key and if there is a session between the two, a session ID.
- the value of the timestamp and the session ID is to ensure vitality of the data block versus one that may have been created and somehow reused again.
- This data block will be referred to as ⁇ dataBlock>.
- user A uses its own private key to digitally sign the ⁇ dataBlock> that was created.
- the result is ⁇ envelopeSignature>.
- an ⁇ envelopeContent> is created by putting together the ⁇ dataBlock> and the ⁇ envelopeSignature>.
- a ⁇ secureEnvelope> is created by encrypting the ⁇ envelopeContent> with user B's public key.
- the ⁇ secureEnvelope> is sent to Store in operation 467 .
- store creates a unique ⁇ messageId> that is associated with the ⁇ secureEnvelope>, and in operation 473 it returns that identifier to User A.
- User A then relays the ⁇ messageId> in operation 475 and possibly the address of the Store server (if not a well known server service between the two users) to user B.
- This data is rather short and can easily fit in nearly all digital codes such as a bar code, a QR code, PDF417-code, and the like.
- User B receives the data in some form, such as scanning the code from the mobile screen of User A and then sends a message to Store to get the ⁇ secureEnvelope> associated with the ⁇ messageId> in operation 477 .
- store returns the associated ⁇ secureEnvelope>.
- User B can view the ⁇ envelopeContent> by decrypting the ⁇ secureEnvelope> using his private key that no one else is aware of, as shown in block 485 . It may then verify the ⁇ dataBlock> in the envelope content by verifying the ⁇ dataBlock> and the ⁇ envelopeSignature> with the user A's public key that was passed. It may also verify that this is the same public key that was used in user A's SealId.
- the ⁇ secureEnvelope> can be deleted after a successful transmission, as detailed in operation 483 .
- FIGS. 4D, 5, and 6 illustrate different use cases providing for website login, logging in for services without using a password, and new user registration.
- Other use cases are also disclosed below.
- the term “user” refers to an individual who has identifying credentials. The user typically wishes to gain access to particular service or product, as is described throughout this specification.
- the term “service provider” refers to an entity to which a user wishes to gain access.
- the service provider may be a website, a physical building, an employer, a club with membership privileges, an automobile, an airline, or any other service or product.
- the term “man-in-the-middle” refers to a system or individual listening to communication between two parties in either electronic or analog form.
- the man-in-the-middle may be a hacker.
- the term “verifier” refers to a service which is configured to verify some or all of user information associated with a user.
- the term “certifier” refers to a service which is configured to certify the user information (which previously could have been verified and validated).
- the certifier is configured to produce a certification record, which uniquely further identifies data (e.g., user information), and can be used as proof that certain data belonged to a certain user at the time of the certification according to the certifier.
- the term “session ID” refers to a unique identifier that may be used throughout an authentication and login process, thereby connecting the devices used in the process, and wherein the session ID may be associated with a communication session that will be established after successful login of a corresponding user.
- signature refers to a process by which a user is able to digitally sign data using a public/private key pair. The process of signing data may be protected with access control to the App or device. For example, a Touch ID process previously introduced may be used as the user's permission to allow the App to digitally sign data on the user's behalf.
- the capabilities for authentication and login can be provided without providing complete security. This can be the case if (a) the user is within a secure environment where outside or hacker attack is deemed not probable, (b) all communication is done through a secure channel (e.g., secure socket layer—SSL), (c) security violation is not deemed to be a threat or of importance, and/or (d) security is ignored. 3) In another embodiment, each session requiring authentication should be identified by a unique Session-ID that is generated by the service provider. 4) Also in other embodiments, the user must have previously been registered with the service provider. 5) Further, in other embodiments, the service provider does not necessarily need to know the phone number of the device the user utilizes for authentication.
- SSL secure socket layer
- each request may be authenticated in real time, although it can also be done in batch processing or offline (which may experience slower results). 7) Further, in other embodiments, the user may optimally provide an additional factor for authentication such as passcode or Touch ID on their mobile device. This additional factor may not be necessary, as the user may have other forms of security in place that would provide for additional security, or this factor may not be necessary when security is not of concern. 8) In other embodiments, the user is in possession of a private/public key for encryption/decryption and signing. 9) In still other embodiments, the service provider may not necessarily know the current public key of the user until the authentication request is initiated. 10) In other embodiments, the user is able to authenticate each request by being able to utilize its private-key to digitally sign the request. This may be an optional requirement that when performed provides for additional security.
- FIG. 4D is a diagram 400 D illustrating a process for logging into a website using a QR code, in accordance with one embodiment of the present disclosure.
- FIG. 4D illustrates another process for performing authentication and login onto a web portal of a web server 320 as illustrated in FIG. 3 , and performs similar operations as those described in FIGS. 4A-4C . That is, the process outlined in diagram 400 D uses the technologies for registration, validation, and certification of data (e.g., user data) described previously in at least FIGS. 1A-1C , to allow users to login to websites, services, and other portals without the use of a username or password.
- data e.g., user data
- the authentication and login process shown in FIG. 4D may be used to authenticate a user to a website.
- a user enters a web site and may be presented with one or more forms of authentication paths to login (for example, username/password and a button to login).
- On the screen there is a QR code or other similar graphics that encodes data information (such as a bar code).
- the QR code is referenced and intended to represent any type of code.
- the user uses his/her mobile application designed to comprehend the contents of the QR code and determines that this is an authentication badge for login.
- the application presents the user with a question to determine if the user chooses to login and pass his/her credentials.
- This process may request an additional form of authentication on the mobile device such as a finger thumbprint Id (e.g., touch ID, and/or other biometric identification), or a PIN passcode.
- a finger thumbprint Id e.g., touch ID, and/or other biometric identification
- PIN passcode e.g., PIN passcode
- the authentication and login process outlined in FIGS. 4A-4D can be modified and/or applied to a use case wherein login to a physical port is performed using a QR code.
- a user may wish to gain access to a physical portal such as a door that is locked, enter a gym where he/she has an active membership, or enter company premises.
- the user scans a QR code that is electronically generated.
- the message is sent to the server processing authentication.
- the server allows access for the user. If the user is at a physical portal, such a locked door, the server may send an authenticated request to the lock box to have it electronically opened.
- the server may send a message with identifying information such as the person's name that was authenticated, their picture and other information and confirm their authentication so they are allowed access.
- identifying information such as the person's name that was authenticated, their picture and other information and confirm their authentication so they are allowed access.
- other forms of communication such as Bluetooth, NFC and other communication methods may also be used, in other embodiments.
- the authentication and login process outlined in FIGS. 4A-4D can be modified and/or applied to a use case wherein login for access to services is performed using a QR code.
- a service provider may alternatively employ a QR code scanner through a device and read a QR code generated by the user's mobile app that identifies the user. The identity of the user can be authenticated and based on that determine if the user should be granted access. This can be done with a reader at a portal such as a locked door or entrance into a physical facility guarded by an operator.
- FIG. 5 is a diagram illustrating a process including a push notification login for purposes of logging into services using a username, but no password, in accordance with one embodiment of the present disclosure.
- a user can gain access to services mentioned previously by entering a username and then processing a control button that ultimately verifies the user—we can refer to this as a “Verify” button.
- pressing the Verify button causes the browser or portal to send the username entered to its server that then looks up the reference-ID to the user associated with the username.
- a server that is able to send direct or vendor specific push notifications to the user's mobile app requesting authentication.
- the user is prompted with an option to authenticate and login or deny the request. He/she may be challenged with a passcode or a biometric test such as touch ID. If the user agrees, an authentication message is sent back to the server allowing the user to login.
- This system can be used for both web based browser authentication as well as physical world authentication.
- the authentication and login process outlined in FIGS. 4A-4D can be modified and/or applied to a use case where remote or local user based login is performed.
- a user may be required to allow third party access to his/her account. This can be done where the user is local to the third party or remote from the third party.
- a local example is when a user goes to a bank branch and wants to allow the teller to have access to his/her account so he/she can perform a transaction or inquiry.
- a remote example is when a user calls a Call-Center to have the operator on the phone access his/her account to answer a question, perform a transaction or respond to an inquiry.
- the user may use a QR code authentication scheme.
- the user may simply provide a user-name, account number, or other identifying information so that the call center is able to identify the user, and access related identifying information.
- the operator e.g., call center agent
- the operator may then initiate a process to send a Verify request to the user on his/her mobile app (e.g., to device 11 of user 5 ), wherein the request includes a newly generated session ID.
- the user 5 will then receive a request that he/she needs to approve after providing a passcode or biometric authentication (such as Touch ID).
- a message may be displayed on device 11 notifying the user that a login process is requested on behalf of the user by a call center.
- the message is generated by the call center, and includes a newly generated session ID, for example.
- the user may accept or reject the login process described in the notification (e.g., selecting an accept or reject button on the display).
- the process outlined in FIGS. 4A-4B may begin at connector A and starting at block 440 on FIG. 4B .
- a request is sent back to the server connected to the operator's console and after verification of the response, the operator is then authorized to view the user's information based on the rules of their system.
- FIGS. 6A-6D are diagrams illustrating a process for registering new users to a service provider website, in accordance with one embodiment of the present disclosure.
- a user visits Service Provider's website and is presented with a registration form.
- the form has a QR Code or other similar graphics which user can scan with his personal mobile device.
- Verifier is notified of the request. Verifier validates user data against 3rd party services, publicly available information and other sources of data.
- Verifier will produce a verification record which can be used by the Certifier to generate a certification record.
- Service Provider uses this record and user's data to derive information necessary to complete website registration process.
- Certification record is cryptographically signed, encrypted and stored to prevent alteration. It can be used to verify the data at later time.
- the authentication and login process outlined in FIGS. 4A-4C can be modified and/or applied to a use case where a user is securely associated with an existing account or user registration in a system of a service provider.
- a user visits Service Provider's website and logs in using conventional methods, specific to provider's site.
- the user navigates to a special page, for example on his profile or setting page and is presented with a form.
- the form has a QR Code or other similar graphics which user can scan with his personal mobile device.
- the Verifier is notified of the request.
- Verifier validates user data against 3rd party services, publicly available information and other sources of data. Verifier will produce a verification record which can be used by the Certifier to generate a certification record.
- Service Provider uses this record and user's data to derive information necessary to associate this user's identity with an existing account.
- an alternative method providing authorization for user login into a service is to scan a code on the web page screen that contains a specific unique session ID (e.g., using a mobile application facilitating identity management).
- the application can send the necessary credentials to the web server managing the website along with the session ID to allow the user to login without having to enter a username and password on the screen.
- the application is configured to respond with the identity of the user as managed through the use of private/public keys.
- the key is that the user avoids entering a username and password on the login screen and instead, can scan a code enabling the application to allow the scanning device to communicate directly with the service provider during the login process.
- the code on the screen can be in any form, such as a bar code, QR code, PDF417 code, or any other format. These codes can be referenced interchangeably in this application, but ultimately perform the same functions.
- the code may be used for requesting and accessing large amounts of data used during the login process.
- the codes are static and possibly may be copied and used for login by a fraudulent user.
- the code may be copied by a hacker off of a browser that is viewable by the hacker through various techniques. Because the code has a valid session ID, if the hacker presents the static code to a real user (e.g., displayed on a phishing site), the unsuspecting user can possibly scan the code and assume that he/she is interacting the real site (instead of the phishing site). As a result, the user believes that login credentials are being sent to the real server. The hacker is able to pose as the user, such that the real server may authenticate the user associated with the session ID and allow the user session to be logged in. However, the browser session that is logged in exists on the browser of the hacker and not the real user.
- Embodiments of the present invention increases the burden of a hacker through the use of an additional dynamic code, which can be another factor in the authentication and login process described in FIGS. 4A-C .
- an additional dynamic code which can be another factor in the authentication and login process described in FIGS. 4A-C .
- the burden of phishing becomes significantly harder, and a hacker cannot simply copy a static code (e.g., QR code) to fake the user into participating in a fraudulent login process.
- a static code e.g., QR code
- FIG. 7A illustrates a data flow 700 for using a dynamic code to implement a challenge code that is passed between devices used when performing authentication and login onto a web portal of a web server as illustrated in FIGS. 4A-4C , in accordance with one embodiment of the present disclosure.
- data flow 700 is implemented in the data flows of FIGS. 4A-4B through connector B, before returning to connector A, such as when a dynamic code is inserted into the authentication and login process to a website of a web server 320 .
- Data flow 700 may be performed to provide additional security by ensuring the proper devices are participating throughout the entire authentication and login process. As previously introduced, the process outlined in FIGS.
- 4A-4D and 7A-7C assumes that the user is already registered with the service provider (e.g., web server 320 ), and that the service provider maintains at least the following record on the user: a user identification, such as a name or a username (optional), and a public key of the user that matches the private key maintained by the user in his or her identity management application.
- the service provider e.g., web server 320
- the service provider maintains at least the following record on the user: a user identification, such as a name or a username (optional)
- a public key of the user that matches the private key maintained by the user in his or her identity management application.
- the authentication and login process performed before connector B is shown in FIGS. 4A-4B .
- the website login page 750 of FIGS. 7B-7C may or may not display username and password fields 751 and 752 , respectively, for purposes of login.
- the login page 750 would display a code 760 (e.g., QR code) that a user can scan for use by an identity management application, as is shown in FIGS. 7B-7C .
- the QR code 760 contains a session ID and the URL of the web server 320 requiring a response to a login challenge.
- the user scans the QR code 760 to retrieve the referring URL, as well as the session ID.
- the session ID may be digitally signed by the web server 320 to provide that it was generated by the service provider (e.g., web server 320 ) that the user intended to interact with.
- the user can verify the signature using the public key of that service provider.
- the verification step is optional.
- the QR code may contain other information, including codes that indicate that this is a login request or challenge.
- the a first scannable code e.g., QR code 760
- the login webpage 750 is displayed on a first device 310 associated with the user 5 .
- the scannable code includes an envelope ID and a login challenge, wherein the envelope ID is associated with a first envelope of data generated by the web server 320 and includes a session ID.
- the envelope ID is generated by an identity manager 330 at the request of the web server 320 , and wherein the envelope ID is used to request the first envelope of data from the identity manager 330 .
- various operations are performed by the second device 11 after scanning the QR code 760 , receiving back the envelope of data, and performing other operations on that data.
- a unique shared-string is generated. This can be a random string that is created on-the-fly (e.g., a GUID).
- Other challenge data is generated by the device 11 , including at least one of the shared-string, session ID, user ID, etc. generally, the session ID and the shared-string is digitally signed using the private key of the user to prove that the second device 11 generated the request, and passes the data to the referring URL.
- a hash of the challenge data may be digitally signed using a private key of the user to prove the trustworthiness of the challenge data later presented.
- a challenge envelope of data is generated and includes at least one of the shared-string generated by the second device, a first digital signature of a hash of the shared-string using a private key of the user, and a user ID.
- the message sent to the web server 320 may be optionally encrypted with the public key of the web server 320 . That is, the data in the envelope may be optionally encrypted using the public key of the web server 320 .
- the public key is either known to the user during registration, or included in the QR code 760 .
- the challenge data (encrypted or not) in the challenge envelope is delivered to the web server 320 in operation 720 over a network.
- various operations are performed as outlined in block 725 .
- a decryption process is performed using the private key of the web server 320 , if the data in the challenge envelope was encrypted.
- the web server 320 may verify the signature against the data in the challenge envelope (e.g., at least one of the shared-string, session ID, etc.) using the public key of the user 5 .
- the verification logic is well known, and includes inputting at least one of the challenge data provided in the envelope (e.g., session ID, the shared-string), the public key of the user, and the signature of the challenge data (hashed or no hash), wherein the verification logic confirms or denies the verification of the challenge data.
- the public key of the user was passed with the challenge envelope/request, the public key may be used as the user ID.
- the web server 320 can look up the public key in its records (and to identify the user 5 ). If the signature is verified, the web server 320 knows that the user 5 in possession with the private key did indeed sign the session ID (along with the data in the envelope), that was previously generated by the web server 320 . That is, the session ID can be trusted.
- the web server 320 generates a challenge response including the shared-string and a signature of the shared-string. That is, the shared-string created by device 11 of the user 5 is extracted from the challenge envelope, and signed by the web server 320 using its private key.
- the data included in the challenge response may be encrypted using the public key of the user.
- the challenge response is included in a second code 770 generated by the web server 320 .
- the new display code could be another QR code, or even one of a different format, such as a bar code, or PDF417 code, etc., as is shown in FIG. 7C .
- the challenge response is delivered to the first device 310 of user 5 .
- the new code 770 is passed back to the login web page.
- the login webpage is updated to include the new code 770 , wherein the web page can either remove the initial scannable code 760 (e.g., QR code) including the session ID and display the second code 770 , or the webpage can display the second code 770 concurrently with the first code 760 (e.g., adjacent to the first code 760 ).
- the initial scannable code 760 e.g., QR code
- the webpage can display the second code 770 concurrently with the first code 760 (e.g., adjacent to the first code 760 ).
- the dynamically created shared-string is displayed using the proper form (e.g., contained within the second code 770 ), so that the second device 11 of user 5 can scan the second code 770 , and allow the identity management application to confirm that the web server 320 is establishing a session with a device of the user (e.g., first device 310 and/or second device 11 ) during a login process using both user devices, and not trying to establish a session with some other user.
- block 740 includes various operations performed by the second device 11 of user 5 .
- the second scannable code 770 includes a challenge response including at least one of the shared-string and the digital signature of the hash of the shared-string (e.g., signed using the private key of the web server 320 ). After scanning, the data contained in the challenge response is optionally decrypted using the private key of the user, if the data was previously encrypted.
- the shared-string is extracted.
- device 11 is configured to verify the signature of the data in the challenge response (e.g., the shared-string). Verification of the signature is performed to ensure that the web server 320 received the challenge envelope and that the web server has acknowledged by sending the challenge response that is digitally signed.
- the verification logic is well known, and includes inputting at least one of the data provided in the challenge response (e.g., the shared-string), the public key of the web server 320 , and the signature of the data (hashed or no hash) in the challenge response, wherein the verification logic confirms or denies the verification of the response data (e.g., the shared-string).
- verification of the returned shared-string included in the challenge response is performed to ensure the same value for the shared-string is being passed throughout this portion of the login process.
- the shared-string may be included in the user data, previously described in FIGS. 4A-4B . That is, the process returns back to FIGS. 4A-4B through connector A, and now includes the shared-string as another factor for authentication.
- the device 11 sends a request to the web server 320 with an authorization to login.
- Device 11 signs both the session ID and the shared-string along with a confirmation request to login.
- the data in the message is optionally encrypted using the public key of the web server 320 , and sends the confirmation request to the web server 320 .
- a confirmation login request is generated by device 11 which responds to the login challenge, wherein the confirmation login request includes a second envelope of data comprising at a minimum the shared string and optionally the session ID, the user ID, and a seal of the user ID registering the user ID with the identity manager.
- the confirmation login request is delivered to the web server (e.g., via the identity manager) for authentication and login of the user with the web server.
- the web server 320 receives the message (e.g., second envelope of data)
- the data contained therein is optionally decrypted. All the signatures are verified to be authentic from the user 5 (e.g., verified with the public key of the user).
- the user is logged into the web site of the web server 320 , and the web server 320 pushes out a landing page for display by the browser of the user (e.g., on the first device 310 ).
- FIG. 8A is a diagram illustrating a system 800 A for performing biometric authentication of a user 5 , in accordance with one embodiment of the present disclosure.
- Authentication may be performed in conjunction with a login process, previously introduced in FIGS. 3-7 , in some embodiments.
- the biometric authentication process may be performed to control access to services, objects, devices, etc.
- biometric controls such as TouchID are generally used for Access Control to an App, App function or a mobile device.
- TouchID in one embodiment would require a server to trust a mobile device, such as device 11 in FIG. 6A .
- Biometrics authentication described in this method allows the server to biometrically authenticate the user.
- user 5 interacts with authenticating entity 810 for purposes of authenticating the user, such as for controlling access to products and/or services.
- User 5 is associated with device 11 , previously introduced, which is used for interacting with the authenticating entity 810 .
- device 11 is configured for communication with authenticating entity 810 over network 150 (e.g., internet, phone, etc.).
- network 150 e.g., internet, phone, etc.
- device 11 may include a web browser configurable for communication over network 150 .
- Authenticating entity 810 includes any type of computing device having at least a memory 1404 and a processor module 1430 that is capable of connecting to the network 150 .
- Data store 815 may be controlled and/or accessible by entity 810 .
- Authenticating entity 810 may be configured to provide information and/or services over network 150 , such as through a website, and may use the biometric authentication process as part of an authentication and login process providing access to the web server 320 , as previously described in FIGS. 4A-4D and 7 .
- authenticating entity 810 may be configured to control access to products and/or services.
- authenticating entity 810 is configurable to control access to object 820 to user 5 , once the user has been authenticated using biometric data that is registered and/or certified.
- Object 820 may take on any form, including products, services, applications, doors, entryways, etc.
- object 820 may be an automobile that is available for short term leasing (e.g., hours, weeks, months, etc.).
- User 5 has leased the object for a period of time, and the authentication process is performed to provide access to the object 820 once the user 5 has been authenticated using biometrics.
- authenticating entity 810 is configured to implement the identity management technology used to perform registration, validation, and/or certification of raw data, to facilitate the implementation of biometric authentication (e.g., through the verification of the biometric data, and certification of biometric data.
- Identity manager 330 includes any type of computing device having at least a memory 1404 and a processor module 1430 that is capable of connecting to the network 150 .
- Identity manager 330 may be utilized for registration of the user ID associated with user 5 , and more specifically the user generated biometric data.
- Data store 335 may be controlled and/or accessible by identity manager 330 .
- identity manager 330 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and authentication and certification of user generated data (e.g., biometrics).
- FIG. 8B illustrates a data flow 800 B for using the verification of the certification of user generated data (e.g., biometrics), such as in a method for authenticating the user, to control access to products and/or services using a biometric authentication process, in accordance with one embodiment of the present disclosure.
- Data flow 800 B may be implemented within system 800 A of FIG. 8A to perform the biometric authentication process.
- newly captured biometric data is associated with original biometric data, wherein the original biometric data is registered, validated, and/or certified.
- the newly captured biometric data and the original biometric data is used to perform biometric authentication.
- an original image e.g., facial image
- the biometric data may take on any form (e.g., audio, fingerprint, body part imaging, facial image, iris, DNA, etc.).
- the original biometric data (e.g., original image) is registered, validated and/or certified using a blockchain.
- User 5 also has a copy of the original biometric data, as well as corresponding registration and certification information (e.g., seals), such as by storing that information on device 11 .
- the blockchain is not used to store the original biometric data that is registered and certified.
- a central server could maintain the signature.hash(original image), wherein the central server could be the identity manager 330 , or the authenticating entity 810 (e.g., stored on data store 815 ).
- block 820 includes operations performed by device 11 of user 5 .
- the authenticating entity 810 sends the user 5 a unique challenge_string that the user is expected to use in the authentication correspondence.
- biometric data is newly captured by device 11 (e.g., camera capturing a facial image of user 5 ).
- device 11 has a copy of the original biometric data (original image) that was registered and certified (with supporting information on the device 11 ), and the newly captured biometric data (newly captured image), both of which can be delivered to the authenticating entity 820 for purposes of performing biometric authentication.
- user data is collected, to include at least one of the captured biometric data, the original biometric data, the challenge_string, the public key of the user 5 , the registration seal, the certification seal, etc.
- the user data is hashed, and then signed using the private key of the user.
- the user data and the signature of the hashed user data may be packaged in an envelope of data, for example as a request to authenticate.
- the contents within the request package is optionally encrypted using the public key of the authenticating entity 810 .
- the secure envelope is delivered to the authenticating entity 810 in operation 825 .
- Block 830 includes various operations performed by the authenticating entity 810 .
- entity 810 is configured for receiving from device 11 of user 5 a user envelope of data.
- the user envelope includes user data and a signature of a hash of the user data signed by a private key of the user.
- the user data includes at least one of a user ID (e.g., recognizable by the authenticating entity 810 ), newly created biometric data, newly presented original biometric data associated with the newly created biometric data, the unique challenge_string, a registration seal associated with the original biometric data comprising a first transaction number of a first blockchain, and a certifying seal associated with the original biometric data comprising a second transaction number of a second blockchain, wherein the second blockchain may incorporate the first blockchain in one embodiment.
- a user ID e.g., recognizable by the authenticating entity 810
- newly created biometric data newly presented original biometric data associated with the newly created biometric data
- the unique challenge_string e.g., a registration seal associated with the
- the signature of the user data is verified in order to confirm that the data is trustworthy.
- the verification logic is well known, and includes inputting at least one of the user data (e.g., original biometric data), the public key of the user 5 , and the signature of the user data (hashed or no hash), wherein the verification logic confirms or denies the verification of the user data in the envelope.
- This signature of the user data also guarantees that the user data, including the new biometric data, is a fresh response to the exchange between the authenticating entity and the user and it is not an old, reused package of data being sent.
- the user data includes the new biometric data along with the challenge_request among other data units and the fact that the entire user data is digitally signed by user 5 's private key. Since the challenge_request is unique in each exchange, it is not possible to reuse this user data in another exchange with a different challenge_request without first signing it. Therefore, not only does user 5 have to provide newly captured biometric data, it has to be able to sign it in real time in conjunction with the unique challenge_request that changes for every request. This increases the burden for a hacker as they need to both have biometric data to pass on as a new image, but also have the access to the private key of the user to sign the new request (since the old signatures won't work with the new challenge_request).
- the verification logic is well known, and includes inputting at least one of the original biometric data, the public key of the user 5 , and the registration seal (including the transaction identifier pointing to the stored data in the blockchain, for example).
- the certification of the original biometric data is verified.
- the verification logic is well known, and includes inputting at least one of the certification record, the original biometric data, the public key of user 5 , the certification seal (including the transaction identifier pointing to the stored certification data in the blockchain, for example).
- step 1) get challenge_string, original image, and newly captured image
- step 2) get signature.hash(original image) from the blockchain record
- step 4) verifysignature(hash(original image), signature.hash(original image), public_key.signee); and step 5) verify envelope signature with hash(message data including biometric data and challenge_string), 6) if step 4 and 5 was valid, then perform biometric comparison between original and new biometric data (e.g., imagecomparison(original image, newly captured image)).
- a comparison process is performed.
- the newly captured/created biometric data is compared against the newly presented original biometric data (e.g., a copy).
- the user is authenticated when the newly captured/created biometric data and the newly presented original biometric data match.
- additional processes may be performed.
- the previously introduced (e.g., in FIGS. 3-7 ) authentication and login processes may be completed, in conjunction with the biometric authentication process.
- authentication of the user biometric is another factor in the authentication and login process.
- a process for controlling access to object 820 may be performed.
- the object 820 may be unlocked for user 5 if authentication is successful.
- object 820 may remain locked for user 5 is authentication was unsuccessful.
- FIGS. 9A-9B, and 10-12 combined describe processes involved when performing authentication and login for travelers, transportation agents, and transportation services. Use cases are disclosed for the various parties involved.
- FIGS. 9A-9B describe processes performed on the traveler side in a traveler use case.
- the traveler use case is taken from the standpoint of a Traveler who wishes to access various forms of transportation services (e.g., airline, bus, train, etc.).
- the sequence flow for the traveler use case includes: 1) Traveler setting up his/her App; 2) Traveler taking a selfie and publishing it for use; 3) Transportation Agent screening and ultimately certifying the traveler ID & selfie, and further giving the Traveler a travel-token; 4) at a later point, the Traveler can present trip-credentials including, traveler ID, selfie, and travel-token so that the traveler information can be retrieved and verified, and so that a new picture can be taken of purposes of performing face recognition in order to confirm the user/traveler.
- a separate sequence is disclosed for the Transportation Agent as he/she is added to the Transportation Service system in order to be able to login while in the Transportation Service station (e.g., an airport) so that he/she can perform traveler check-in and verification.
- a Transportation Service is an entity such as an airline that provides transportation for persons.
- the concepts described below might well be used in other embodiments by entities that provide transportation for nonpersons (e.g., goods) or services in addition to other services other than transportation.
- FIGS. 10-12 are more focused on processes performed on the Traveler Agent side in a transportation service use case.
- the sequence flow for the Transportation Service use case includes: 1) Transportation Agent newly registers with the Transportation Service portal for the first time; 2) an Admin who operates the Transportation Service portal confirms the Transportation Agent as a valid employee and grants access; 3) the Transportation Agent subsequently logs into the Transportation Service portal to perform his/her duties. This operation may only be done while on the Transportation Service station premises, in one embodiment.
- FIGS. 9A-9B describe processes performed on the traveler side in a traveler use case.
- FIG. 9A is a diagram illustrating a process for registering and validating a user, which in this case is the Traveler 901 , in accordance with one embodiment of the present disclosure.
- the Traveler 901 is assumed to have downloaded a Traveler App 902 providing an interface and functionality for performing the registration, validation, authentication, login, etc.
- the Traveler 901 scans his/her passport or a required form of government ID, and at operation 910 takes a selfie using his/her Traveler App 902 .
- the Traveler App 902 then creates a signed hash of the passport information, and a separate signed hash of the selfie.
- the data given to the hashing algorithm can include the data to be hashed along with a random data string, referred to as a Salt.
- the resulting hash is then digitally signed. This process prevents a hacker from discovering the data through brute force.
- the user must always pair and pass the data (e.g., passport information) with the corresponding Salt values in order for a verifier to validate the signatures.
- this information is sent to the identity-management service server to be sealed.
- the identity-management service server “ShoStore” 992 is accessed through an API 991 called “ShoApi”.
- ShoApi 991 is configured to also provide access to the blockchain database “BC” 980 .
- the term “ShoStore” is also referred to as “ShoCard”) server to be sealed.
- the server forwards the request to the blockchain 980 to be written as a transaction. This becomes the Seal of the Traveler 901 .
- FIG. 9B is a diagram 900 B illustrating a process for registering and validating the image (e.g., selfie) of the Traveler 901 , in accordance with one embodiment of the present disclosure. This is achieved via a delayed-secure-envelope transmission, in one embodiment. Normally, communication between the Traveler 901 (the user of the identification-management service—“ShoStore”) and another user or entity (such as a transportation service—“airline” 933 ) is performed through a secure-envelope transmission.
- the Traveler 901 the user of the identification-management service—“ShoStore”
- another user or entity such as a transportation service—“airline” 933
- the Traveler 901 creates the message that is to be transmitted, and envelopes it securely so it cannot be spoofed by any other third party (e.g., hacker) in any way (including the ShoStore servers 992 ).
- the message is created and enveloped securely, but stored for a delayed use when the Traveler 901 authorizes the transmission to the appropriate party of her choosing, such as the airline 933 .
- the Traveler App 902 To establish delayed-secure-envelope transmission, at operation 940 the Traveler App 902 generates an image-secret-key that is kept on the Traveler App only. The Traveler App 902 also encrypts the Traveler's selfie. This information is encrypted and packaged as a message. At operation 945 , the encrypted message is then stored with the ShoStore server 992 , and an imageId is returned to the Traveler App 902 that references that encrypted message. The Traveler App 902 stores both the image-secret-key for the message and the ShoStore imageId. At this point, the Traveler App 902 is ready to use the image as a form of registered identification with the transportation service 933 .
- FIGS. 10A-10B are diagrams 1000 illustrating the authentication of the Traveler 901 at a transportation service 933 (e.g., airline), in accordance with one embodiment of the present disclosure.
- a transportation service 933 e.g., airline
- the Traveler 901 shows up at the transportation service 933 and is greeted by an Agent 931 .
- the Traveler 901 initiates sharing her ShoStoreId by creating a QRCode on her Traveler App 901 at operation 1005 ⁇ Share ShoCardID>.
- the ShoStoreID is provided by ShoStore 992 , the identity-management service, during the registration process of the Traveler 901 .
- the ShoStoreID may also be referenced as “ShocardID” in the figures and elsewhere in the specification.
- the ShoStoreID may include a transaction ID referencing the location in the blockchain 980 where the user data is stored.
- the Traveler App 902 creates a secure-envelope that includes her passport identity information along with her ShoStoreId, the imageId she received when she created her stored encrypted image, and the image-secret-key used to decrypt the stored image.
- the envelope is secured with a temporary passcode, temp-key, that encrypts the entire message.
- the envelope is sent to the ShoStore 992 at operation 1010 ⁇ create ENVELOP[temperature_key]((Identity+selfie-uniqueID+one-time-key))>.
- the ShoStore 992 returns a QR Id that uniquely identifies this secure-envelope to the Traveler App 902 at operation 1015 ⁇ qrID>.
- the Traveler App 902 then creates a QRCode with two pieces of information in operation 1016 ⁇ create QRCODE(qrId+temporary_key), and Display on Screen>.
- First is the QR ID returned from the ShoStore 992
- second is the temp-key (e.g., public_key of ShoStore 992 ) necessary for the receiver (Traveler App) to decrypt the secure envelope.
- the QRCode is scanned by the Agent 931 at operation 1017 .
- the App 932 temporarily saves the temp_key in the QR code, and uses the “qrId” field to send a getData request to ShoStore 992 at operation 1020 ⁇ getData(qrId>.
- ShoStore 992 returns the secure-envelope that the Traveler 901 had saved, and simultaneously removes that secure-envelope from ShoStore at operation 1023 ⁇ ENVELOP[temperature key]((Identity+Selfie-uniqueID+one-time-key))>.
- the Agent App 932 uses the temp_key retrieved from the QR Scan to decrypt the envelope at operation 1024 .
- the Agent App 932 then makes a request to the ShoStore to retrieve the encrypted selfie-image referred to by the imageId at operation 1025 ⁇ get(selfie-uniqueld)>.
- the encrypted image is returned.
- the Agent App 932 retrieves the Travelers' latest Seal record via ShoApi from the blockchain 980 at operations 1030 , 1033 , 1035 , and 1037 , wherein operation 1030 sends a request to ShoApi 991 for the seal ⁇ Get traveler's last seal>, wherein operation 1033 sends the request to the blockchain 980 ⁇ get seal transaction>, wherein operation 1035 delivers the seal data to ShoApi 991 ⁇ Traveler seal data>, and wherein operation 1037 delivers the traveler seal data back to Agent App 932 ⁇ Traveler seal data>.
- the Traveler 901 can create a QR Code on its App requesting the id information of the Agent and its public key in order to share data.
- the Agent 931 scans the QR Code of the user to identify its ShoCard ID so it can send it messages and notifications. It then creates a Secure Envelope and within it, it embeds its own ShoCard ID and public key.
- the Traveler 901 then creates the secure-envelope described earlier, but encrypts it with the Agent's public key instead of temp_key described above. It then sends the secure_envelope to the Agent 931 .
- the Traveler 901 can exchange data with the Agent's device directly using Bluetooth, NFC, Streaming QR Codes as described in another embodiment, or other means of local transmission of data. In this scenario, the Traveler 901 would still retrieve the Agent's ShoCard ID and public key using local transmission of data and return to it the complete secure_envelope using local transmission of data.
- the Agent 931 has all the digital assets it needs to verify the user—this process is referred to as “screening” the user data, as performed in operation 1038 .
- the Traveler's passport data passed via the QR Scan is compared to the data on the blockchain (e.g., verifies traveler data with seal).
- the selfie-image passed is decrypted (e.g., decrypt selfie with image-secret-key) and made viewable on the Agent's App—the agent does a visual comparison of the selfie and the Traveler.
- the Agent may snap a new image of the user and use systems to perform a biometric comparison of the image taken and the image passed by the Traveler 901 .
- the Agent may now verify the physical documents that the Traveler presents such as physical passport, driver's license, travel itinerary or ticket and other required information (e.g., full name, address, passport number, driver's license number, etc.). This process may also be automated with a self-service kiosk or other non-human devices to validate the Traveler's data.
- the Agent approves the screening using the Agent App 932 at operation 1040 ⁇ Approves screening>.
- This approval becomes a request for a certification message to the transportation-service server, at operation 1041 ⁇ Request is sent to Airline for certification>.
- the request to certify is created and it includes the Agent's ShoStoreId, approval-code, and all the information that was retrieved in the QR Scan from the Traveler 901 .
- this request is placed in a secure-envelope with the Transportation-service server's public key and transmitted to ShoApi 991 , for routing to the Transportation-service server 933 at operation 1045 ⁇ Route Request to airline>.
- the Transportation-service server 933 upon receiving the request at operation 1045 , retrieves the Traveler's last seal from the blockchain via ShoApi 991 at operation 1047 ⁇ Get traveler's last seal>, wherein operation 1050 forwards the request to the blockchain 980 ⁇ get seal transaction>, wherein operation 1053 returns the seal to ShoApi 991 ⁇ Traveler seal data>, wherein operation 1055 returns the seal to the transportation server 933 ⁇ Traveler seal data>.
- the transportation server 933 is configured to verify the identity of the Agent 931 using the Agent's ShoStoreId. In addition, the transportation server 933 is configured to ensure that the Agent has an active logged-in session at the transportation service station. The transportation server 933 then verifies the Travelers' passport data and image-hash against the Seal record ⁇ verifies traveler data against the seal>_ ⁇ verifies hash of passport data>_ ⁇ verifies hash of image data>, etc.
- transportation server 933 sends a certification request to be written to the blockchain for the Traveler 901 at operation 1057 ⁇ certify(shocardId[Traveler], passport data, image data, ShoCardId[Agent]>, at operation 1060 ⁇ write certify transaction> writing certification record data to blockchain 980 , at operation 1063 ⁇ confirmation> confirmation of the blockchain transaction is returned, and at operation 1065 ⁇ confirmation> the confirmation information (e.g., blockchain transactionID, etc.) is delivered to transportation server 933 .
- the certification record specifically identifies the passport fields confirmed and the hashed-image-data.
- This TravelData includes at least one of a Travel-token, Traveler's ShoStoreId (ShoCardId[Traveler]), expiration time for the Traveltoken, imageId of the Traveler (imageId[Traveler]), the ShoCardId of the transportation service (ShoCardId[Airline]), optionally the Agent (ShoCardId[Agent]), and a signature of all of these fields using its own private-key ⁇ signature(all-travel-data)>.
- the Transportation-service server 933 places the TravelData in a secure-envelope encrypted with a new password it creates, namely travel-secret-key at operation 1067 ⁇ create travel-secret-key>.
- This secure-envelope is sent to the ShoStore server as another delayed-secure-envelope at operation 1068 ⁇ ENVELOPE[travel-secret-key](store(TravelData))>, and receives a travelerId in return in operation 1070 ⁇ travelerId>.
- the travelerId along with the travel-secret-key is then passed in a secure-envelope encrypted with the Traveler's public key to the Travelers' App 902 at operation 1073 ⁇ ENVELOP[Traveler](travelerId & travel-secret-key>.
- the Agent 931 through the Agent App 932 is given a confirmation of the travel-token being issued by the Transportation Service Portal in another secure-envelope at operation 1075 ⁇ ENVELOP[Agent](Travel-confirmation)>.
- the Traveler App 902 saves both the travelerId and the travel-secure-key for future presentation.
- This TravelData is the authenticated travel-Token that is presented at future gates of entry.
- FIGS. 11A-11B are diagrams 1100 illustrating a method for checking a certification of a Traveler, such as by an Agent of a transportation service, in accordance with one embodiment of the present disclosure.
- a transportation-service Agent 931 needs to verify the user—the Traveler.
- a gate of entry can be entrance into a lounge, boarding on a plane, going to a travel agent desk for assistance or any other engagement where a transportation-service Agent 931 must validate the identity of the Traveler 901 .
- the Agent 931 may or may not be from the same transportation service that originally checked the user in (Traveler 901 ) and certified her credentials.
- the gate of entry may or may not be in the same transportation-service station or even country that the Traveler 901 originated in. It is also assumed that the Traveler 901 may not have internet or Wi-Fi connectivity in some embodiments. Additionally, the transportation-service Agent does not necessarily have to be a real person and can be substituted with a self-service kiosk equipped with a camera or other similar systems.
- the Traveler 901 is greeted by the Agent 931 and presents her identification and trip information by locally creating a QR Code at operation 1105 ⁇ locally create qrcode(travelId+travel-secret-key+image-secret-key) and display on screen>.
- the QR Code includes the travel-uniqueld, travelPassKey and the image-secret-key used to encrypt the selfie mentioned earlier.
- the Agents App scans the QR Code at operation 1110 ⁇ scan qrcode>.
- the Agent App 932 requests the encrypted-TravelData from the ShoStore server 992 at operation 1113 ⁇ get(travelId)>, and once the data is received at operation 1115 , the Agent App 932 decrypts it using the travelPassKey.
- the Agent App 932 then requests the encrypted-image pointed to by the imageId at operation 1117 ⁇ get(ImageId)>, returned in operation 1120 ⁇ encryption(image)>, and the Agent App 932 decrypts it with the image-secret-key.
- the Traveler App would create a QR Code that requests the id of the Agent and its public key.
- the Agent App would scan the QR Code and respond back using local transmission technology with the requested information and it would also send an optional sessionID string to the Traveler.
- the Traveler would then create a secure_envelope that would include the travel token, Traveler's identification information (e.g., passport data), originally certified selfie-image and pointer to its seal and certification records on the blockchain and the optional sessionID.
- This secure_envelope would be digitally signed by the Traveler's private key and encrypted with the public key of the Agent.
- the secure_envelope is then transmitted to the Agent using local transmission technology.
- the Agent App decrypts the secure_envelope using its private key and begins the validation process of the Travelers' data.
- the Agent App then retrieves the Seal transaction and related Certification records of the Traveler via ShoApi from the blockchain. In that manner, identity of the Transportation service that certified the Traveler 901 can be confirmed.
- the Agent App 932 retrieves the Transportation service's own Seal transaction from the blockchain via the ShoApi 991 .
- the assumption is that the transportation service was previously certified by this Agents' transportation service as well and within the App, it can confirm that, which makes the originating transportation service a trusted and certified transportation service at operation 1135 ⁇ identify airline that certified the Traveler 901 from the data returned with the seal>.
- operation 1123 ⁇ get Airline public_key>
- operation 1125 ⁇ get Traveler Seal transaction> a request to ShoApi 991 is made for the seal
- operation 1127 a request is made for the seal to the blockchain 980 ⁇ get Traveler Seal transaction>
- at operation 1130 the seal is returned to ShoApi 991 ⁇ Traveler Seal transaction>
- at operation 1333 the seal is delivered to Agent App 932 ⁇ Traveler Seal transaction>
- the transportation service seal is requested ⁇ get Airline Seal transaction>
- at operation 1140 the request is delivered to the blockchain ⁇ get Airline Seal transaction>
- at operation 1143 the seal is delivered to ShoApi 991 ⁇ Airline Seal transaction>
- at operation 1144 the seal is delivered to Agent App 932 ⁇ Airline Seal transaction>.
- the Agent App 932 verifies that the travelData was authentically signed by the transportation service at operation 1145 ⁇ agent screens user data, verified tripData with signature, and decrypts selfie with one-time key>.
- the Agent App 932 confirms the travel-token and expiration date, and confirms that the Traveler image-data was certified by the transportation service as well.
- the Agent App 932 then takes a picture of the Traveler using its own camera at operation 1150 ⁇ activate camera>; operation 1153 ⁇ traveler looks at camera>; and operation 1155 ⁇ take picture>.
- the Agent App 932 performs facial recognition comparing the newly taken picture and the certified image it had retrieved at operation 1157 ⁇ face recognition>. If all matches, the Traveler 901 is verified and a green signal is given for the Traveler to proceed at operation 1160 ⁇ Red/Green>, or red if the Traveler 901 is not verified.
- FIGS. 12A-12B are diagrams 1200 illustrating a method for registering an Agent 931 of a transportation service and logging in the Agent, in accordance with one embodiment of the present disclosure.
- the transportation-service Agent 931 has two functions. The Agent checks-in a new Traveler 901 and provides her with a travel-Token. The same or a different Agent later checks the identity of that Traveler 901 and the travel-Token, which is issued to grant permission to proceed through various gates of entry.
- the Agent is referred to with reference number 931 , and in this diagram can be the same agent or two different agents in diagram 1200 .
- the Agent 931 must download the Agent App 932 , have it registered with the transportation service and have a logged in session.
- the Agent 931 first downloads the Agent App 932 at operation 1210 ⁇ downloads App>.
- the Agent 931 scans her Driver's License at operation 1213 ⁇ Scan Driver's License>.
- the Agent App 932 creates a ShoStoreId for that Agent along with a new set of private/public keys for the Agent at operation 1215 ⁇ Create ShoCardId & private keys>.
- the Agent App 932 hashes each field of the Agent's identification and digitally signs it using its private-key.
- the Agent App 932 then sends a request to the ShoApi 991 to Seal the record at operation 1217 ⁇ Seal(hash(license))>.
- ShoApi 991 forwards the request to perform a seal transaction to the blockchain 980 at operation 1220 ⁇ seal transaction>.
- the Agent is able to register with the Transportation Service Portal.
- the Agent App 932 is used to scan the registration-QR code at operation 1230 ⁇ Scan registration QR>, where the portal 1201 creates a new Agent identity at operation 1240 ⁇ new Agent identity created>.
- the Transportation Service Portal 1201 requests the Seal transaction of the Agent from the blockchain through ShoApi and validates the information against the employee record database it has in order to ensure this is a valid Agent of the transportation service. If all is valid a record of this new Agent is created for the transportation service Admin to authorize.
- a Transportation-service Admin 1202 must authorize the Agent registration through the portal at operation 1243 ⁇ authorizes Agent registration>. This process is done through a different interface on the portal visible only to the Admin 1202 .
- a Certify request of the Agent's ShoStoreId is sent to the blockchain via the ShoApi at the following operations: operation 1245 ⁇ Certify(shocardId[Agent])>; operation 1247 ⁇ write certify transaction>; operation 1250 ⁇ confirmation> confirmation certification returned to ShoApi 991 ; operation 1253 ⁇ confirmation> confirmation certification returned to airline portal 1201 .
- the registration process is a one-time event per employee.
- the Agent 932 is able to login to the Transportation Service Portal 1201 .
- the Agent 932 scans a new QR on the login page at operation 1255 ⁇ Scans new QR code to login>.
- the Agent App 932 is given a session ID at operation 1257 ⁇ give sessionId>.
- the Agent App 932 uses the sessionId to send a secure Envelope to the Transportation Service Portal in order to login to the portal at operation 1270 ⁇ ENVELOPE[Airline](login request)>.
- the Transportation Service Portal validates that login request against the Agent's sealed and certified records on the blockchain and ultimately logs the Agent in if everything is validated at operation 1280 ⁇ verify Agent ShoCardId; verify Agent was certified by Airline; if validated then user logged in>.
- Agent 931 is now able to perform Traveler operations until the Transportation Service Portal session expires or the Agent logs out.
- the Transportation Service Portal 1201 has a set of administrative capabilities and reporting. These functions may not be available to the Agents, but only to the administrators of the system (the Admin). When logged in as the Admin, the Transportation Service Portal 1201 may provide the following capabilities: view a list of Agents (logged in or not); create a list of actively logged in Agents; ability to disable an Agent; ability to remove an Agent; ability to approve newly registered Agents; Agent can logout via Agent App. In addition, the Transportation Service Portal 1201 may be configured to provide real-time and historical reports on: agent registrations; agent logins and login session timers; and Travelers' Identity screening and certifications. In one embodiment, the Transportation Service Portal 1201 might be a Ruby on Rails web application.
- each transportation service has its own instance of the Transportation Service Portal 1201 in one embodiment.
- the Transportation Service Portal 1201 might be deployed in the cloud (Heroku/Amazon) and operated by the identity-management service (“ShoStore” also called “ShoCard”) Traveler's App.
- the Traveler App might be an iOS based App designed to run on iPhone 5 or higher model.
- each traveler is to be equipped with a new instance of the Traveler App.
- the Agent App might be an iOS based App, wherein each Agent is to be equipped with a new instance of the Agent App.
- FIG. 13 is a diagram 1300 illustrating a method for performing third party certification of custom name/value pairs, in accordance with one embodiment of the present disclosure.
- the ShoCard user 1301 must first be known to the Certifier 1310 where at a minimum, the ShoCardId of the user has been exchanged.
- the Certifier 1310 may or may not have certified the ShoCardId previously.
- the Certifier 1310 may then write a record to the blockchain 980 using its private-key encapsulating at least one of the following set of data (additional field types may be included as well): ShoCardId being certified; an optional transactionId that would point to a Sealed entry on the blockchain for that user; and a list of Names/Values.
- the data for the transaction being written to the blockchain may or may not fit in a single transaction. If it does not fit, a hash of the entire data is made and the hash is written to the blockchain 980 . The data is then stored on a different device that may or may not be shared. To access the certification record on the blockchain, the data associated with that hash may have to be accessed and verified that it matches the same hash. This process is an indirection that may or may not be necessary to the overall operation depending on the size of the data fields supported by the given blockchain 980 .
- the record being written to the blockchain must be signed with the private-key of the Certifier 1310 . This ensures that no one else is committing this transaction. If the transaction is written to something other than a blockchain, the data must be digitally signed and the digital signature must be submitted along with the data to be written, in one embodiment.
- the second key item is the composition of the Name/Value fields.
- the Name field can be a text string describing the field type, in one embodiment.
- the Value however is a digital signature of the hash of the data associated with that field name. For example, if the name field is “Ranking” and the data associated with the field Ranking is the string “superior”, the following transformation would take place: 1) The string “superior” would be hashed and a data stream would be produced from that hash: ⁇ hashValue>, wherein there are many algorithms that can be used for the hash such as, but not limited to SHA256; and 2) the Certifier then uses its private-key to digitally sign the ⁇ hashValue>, wherein the result is: ⁇ signedHashValue>.
- the Value field would then be ⁇ signedHashValue>.
- JSON JavaScript Object Notation
- the Certifier 1310 must pass the data to the blockchain, but also needs to pass a copy of the certification record being written along with original data to the ShoCard User 1301 .
- the ShoCard user 1301 then has the opportunity to acknowledge the receipt and acceptance of the certification by also writing a copy of the certification record on the blockchain using its own private-key.
- the ShoCardId of the Certifier 1310 must also be written. Additionally, it must keep a copy of the clear-text name/value fields that is passed to it by the Certifier 1310 so it can refer to the data. This clear text data is maintained in the users' local device (e.g., his/her phone).
- the ShoCard User 1301 can share the certification information with another party (herein referred to as Verifier 1315 ). To do so, the ShoCard User 1301 can pass the specific name/value fields in clear text that it intends to share and a reference to its own ShoCardId on the blockchain 980 . It may also pass to the Verifier 1315 the address of the certification record it wrote on the blockchain 980 . The Verifier 1315 can retrieve all transactions associated with the ShoCardId from the blockchain 980 and look for a match to the Certifiers' record. It then reads the fields in the certification record which includes the Certifier's own ShoCardId on the blockchain 980 . This leads to the public key of the Certifier.
- Verifier 1315 can retrieve all transactions associated with the ShoCardId from the blockchain 980 and look for a match to the Certifiers' record. It then reads the fields in the certification record which includes the Certifier's own ShoCardId on the blockchain 980 . This leads to the public
- Verifier 1315 then uses the Certifier's public key, the Value field for the specific Name fields given to it by the ShoCard User 1301 and the ⁇ signedHashValue> for that same exact field in the certification record to verify that the field was signed by the Certifier 1310 . If it is signed by the Certifier 1310 , the Verifier 1315 can be assured that the Value given to it is authentic so long as the Verifier 1315 trusts who the Certifier is. At a minimum, it can tell that the Certifier 1310 was indeed the person or entity that signed this certification for the Value.
- a certification may also include an expiration time in addition to the fields stated above.
- the expiration time is basically a timestamp that indicates when this certification becomes invalid. If the Certifier 1310 then wishes, it can create a new Certification with a new expiration. Removing the expiration means the certification does not expire and would have to be explicitly cancelled.
- the Certifier 1310 may write a new record that points to the prior certification record and identify it as a cancel-certification. It would also notify the ShoCard User 1301 so that it too can be aware of the cancellation. It may also update an older certification in a similar way where it would point to the older certification record and the data passed to the user.
- the linking of the cancel-certification record or an update are done in clear text so that any user can tell if the state of the certification has been modified (i.e., updated or cancelled) by searching other records that may point back to it.
- FIG. 14 illustrates components of an example device that can be used to perform aspects of the various embodiments of the present disclosure.
- FIG. 14 illustrates an exemplary hardware system suitable for implementing a device in accordance with one embodiment.
- This block diagram illustrates a computer system 1400 , such as a personal computer, video game console, personal digital assistant, or other digital device, suitable for practicing an embodiment of the invention.
- Computer system 1400 includes a central processing unit (CPU) 1402 for running software applications and optionally an operating system.
- CPU 1402 may be comprised of one or more homogeneous or heterogeneous processing cores.
- CPU 1402 is one or more general-purpose microprocessors having one or more processing cores. Further embodiments can be implemented using one or more CPUs with microprocessor architectures specifically adapted for highly parallel and computationally intensive applications.
- CPU 1430 may be configured to include a biometric capture engine 1441 configured for capturing biometric data, a verification engine 1442 for performing verification logic (e.g., verifying data that is signed, registered, and/or certified), a scanning engine 1443 configured for scanning codes (e.g., QR code, scan code, PDF417 code, etc.), an encryption/decryption engine 1444 configured for encrypting and decrypting data using a public/private key pair, a hashing engine 1445 configured for hashing data using any one of a number of well known hashing algorithms, a signing engine 1446 configured for creating a digital signature using a private key, a handle generator 1447 configured for generating a session ID or envelope ID, a scan code generator 1448 for generating a
- Memory 1404 stores applications and data for use by the CPU 1402 .
- Storage 1406 provides non-volatile storage and other computer readable media for applications and data and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROM, DVD-ROM, Blu-ray, HD-DVD, or other optical storage devices, as well as signal transmission and storage media.
- User input devices 1408 communicate user inputs from one or more users to the computer system 1400 , examples of which may include keyboards, mice, joysticks, touch pads, touch screens, still or video cameras, and/or microphones.
- Network interface 1410 allows computer system 1400 to communicate with other computer systems via an electronic communications network, and may include wired or wireless communication over local area networks and wide area networks such as the Internet.
- An audio processor 1412 is adapted to generate analog or digital audio output from instructions and/or data provided by the CPU 1402 , memory 1404 , and/or storage 1406 .
- the components of computer system 1400 including CPU 1402 , memory 1404 , data storage 1406 , user input devices 1408 , network interface 1410 , and audio processor 1412 are connected via one or more data buses 1422
- a graphics subsystem 1414 is further connected with data bus 1422 and the components of the computer system 1400 .
- the graphics subsystem 1414 includes a graphics processing unit (GPU) 1416 and graphics memory 1418 .
- Graphics memory 1418 includes a display memory (e.g., a frame buffer) used for storing pixel data for each pixel of an output image.
- Graphics memory 1418 can be integrated in the same device as GPU 1416 , connected as a separate device with GPU 1416 , and/or implemented within memory 1404 .
- Pixel data can be provided to graphics memory 1418 directly from the CPU 1402 .
- CPU 1402 provides the GPU 1416 with data and/or instructions defining the desired output images, from which the GPU 1416 generates the pixel data of one or more output images.
- the data and/or instructions defining the desired output images can be stored in memory 1404 and/or graphics memory 1418 .
- the GPU 1416 includes 3 D rendering capabilities for generating pixel data for output images from instructions and data defining the geometry, lighting, shading, texturing, motion, and/or camera parameters for a scene.
- the GPU 1416 can further include one or more programmable execution units capable of executing shader programs.
- the graphics subsystem 1414 periodically outputs pixel data for an image from graphics memory 1418 to be displayed on display device 1422 .
- Display device 1422 can be any device capable of displaying visual information in response to a signal from the computer system 1400 , including CRT, LCD, plasma, and OLED displays.
- Computer system 1400 can provide the display device 1422 with an analog or digital signal.
- embodiments defined herein may define individual implementations or can define implementations that rely on combinations of one or more of the defined embodiments. Further, embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.
- the invention also relates to a device or an apparatus for performing these operations.
- the apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer.
- various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations
- the disclosure can employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Any of the operations described herein that form part of the disclosure are useful machine operations.
- the disclosure also relates to a device or an apparatus for performing these operations.
- the apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer.
- various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
- One or more embodiments can also be fabricated as computer readable code on a non-transitory computer readable storage medium.
- the non-transitory computer readable storage medium is any non-transitory data storage device that can store data, which can be thereafter be read by a computer system. Examples of the non-transitory computer readable storage medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices.
- the non-transitory computer readable storage medium can include computer readable storage medium distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Bioethics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Computer And Data Communications (AREA)
- Power Engineering (AREA)
Abstract
Description
- This application claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 62/304,144, entitled “An Identity Management Service Using a Blockchain Database,” filed on Mar. 4, 2016; and claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 62/304,934, entitled “An Identity Management Service Using a Blockchain,” filed on Mar. 7, 2016; and claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 62/455,199, entitled “Electronic Identification Verification Methods and Systems,” filed on Feb. 6, 2017, all of which are hereby incorporated by reference in their entireties.
- The present embodiments relate to methods, systems, and programs for managing the identify of users and of identifying those users to third parties, and more particularly, performing authentication and login processes using a blockchain to authenticate a user during a login process to access a web page through interactions with multiple user devices.
- Identity theft causes tens of billions of dollars in losses every year. In an effort to combat identity theft, systems and methods for identifying users to third parties have been developed. In a common two factor application, a user presents a bank card or credit card in addition to the personal identification number (“PIN”) corresponding to the card. In other systems, a user provides a password to identify himself/herself and may be given a Short Message Service (SMS) text message with a unique code that the user must recite for access. In still other systems, a user may be given challenge questions to verify his/her identity. Each of these systems, however, is subject to attack and ultimate defeat from a basic security breach.
- It would be advantageous to have a more secure system and method for managing the identity of users and of identifying users to third parties, such as when performing login or user authentication.
- It is in this context that embodiments arise.
- The present embodiments relate to solving one or more problems found in the related art, and specifically to provide for login without requiring a user to enter a username and password. In particular, methods and systems are presented for authenticated login, registration and call center validation. Other methods and systems are presented for scanning a dynamic code on a browser screen to authorize user login. Still other methods and systems are presented for certified user generated data (e.g., biometrics). It should be appreciated that the present embodiments can be implemented in numerous ways, such as a method, an apparatus, a system, a device, or a computer program on a computer readable medium. Several embodiments are described below.
- In one embodiment, a method for authentication being performed at a web server providing web access is disclosed. For example, the method is performed when implementing a login process to a web portal of a web server. The method includes sending a login web page to a first device associated with a user. The login web page may have been requested by the user. The login web page includes a scannable code including an envelope ID and a login challenge. The envelope ID is associated with a first envelope of data including a session ID, wherein the envelope ID is generated by an identity manager at the request of the web server. The method includes receiving a confirmation login request responding to the login challenge from a second device associated with the user, wherein the confirmation login request includes a second envelope of data including the session ID, a user ID, and a seal of the user ID registering the user ID with the identity manager. The method includes verifying the confirmation login request to the login challenge using the session ID from the confirmation login request. The method includes verifying the user using the user ID and seal. The method includes authorizing user login upon successful verification of the login challenge and user. The method includes establishing a communication session having the session ID between the web server and the first device when the login is authorized.
- In another embodiment, a method for authentication, such as for requesting login access to a web portal of a web server, being performed at a second device of a user that includes scanning a dynamic code on a browser screen that is implemented to enhance a user login process is disclosed. The method includes scanning a first scannable code on a login web page of a web server displayed on a first device associated with the user. The scannable code includes an envelope ID and a login challenge, wherein the envelope ID is associated with a first envelope of data generated by the web server, wherein the envelope of data includes a session ID. The envelope ID is generated by an identity manager at the request of the web server, and is used to request the first envelope of data from the identity manager. The method includes generating a challenge envelope of data including a shared-string generated by the second device, a first digital signature of a hash of the shared-string and a user ID using a private key of the user. The method includes sending the challenge envelope of data to the web server over a network. The method includes scanning a second scannable code on an updated login web page displayed on the first device. The second scannable code includes a challenge response including the shared-string and a second digital signature of a hash of the shared-string using a private key of the web server. The method includes verifying the second digital signature using a public key of the web server. The method includes generating a confirmation login request responding to the login challenge. The confirmation login request includes a second envelope of data including the shared-string, the session ID, the user ID, and a seal of the user ID registering the user ID with the identity manager; added to this second envelope of data is a digital signature of a hash of the data fields included using a private key of the user. The method includes sending the confirmation login request to the web server via the identity manager for authentication and login of the user with the web server.
- In still another embodiment, a method of authentication implementing the certification of user generated data (e.g., biometrics) is disclosed. For example, the method may be performed by an authenticating entity of a web server, such as when authenticating a user (e.g., to control access to products and/or services). The method includes receiving from a device of a user a user envelope of data that includes user data and a unique session ID issued by the server and a first signature of a hash of the user data signed and the session ID by a private key of the user, wherein the user data includes a user ID, newly created biometric data, newly presented original biometric data associated with the newly created biometric data, validating seal associated with the original biometric data including a first transaction number of a first blockchain, and a certifying seal associated with the original biometric data including a second transaction number of a second blockchain. The method includes verifying the first signature using the public key of the user. The method includes verifying the certification of the original biometric data using the certifying seal and the newly presented original biometric.
- Other aspects will become apparent from the following detailed description, taken in conjunction with the accompanying drawings.
- The embodiments may best be understood by reference to the following description taken in conjunction with the accompanying drawings.
-
FIG. 1A illustrates a data flow for registering data in a blockchain, such as for registering user identification, in accordance with one embodiment of the present disclosure. -
FIG. 1B illustrates a data flow for certifying the registered data using a blockchain, such as for certifying user identification that is registered with an identity manager, in accordance with one embodiment of the present disclosure. -
FIG. 1C illustrates a data flow for verifying the registered data, and for verifying the certification of the registered data, in accordance with one embodiment of the present disclosure. -
FIG. 2 illustrates the implementation of a blockchain to ensure the integrity of the data embedded within, in accordance with one embodiment of the present disclosure. -
FIG. 3 is a diagram illustrating a system for performing authentication and login onto a web portal of a web server, wherein two devices of the user interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure. -
FIGS. 4A-4B illustrates a data flow for performing authentication and login onto a web portal of a web server as illustrated inFIG. 3 , wherein two devices of the user interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure. -
FIG. 4C illustrates a data flow when exchanging a secure envelope of data between two entities via an identity manager server, such as when performing authentication and login onto a web portal of a web server as illustrated inFIGS. 4A-4B , in accordance with one embodiment of the present disclosure. -
FIG. 4D is a diagram illustrating a process for logging into a website using a QR code, in accordance with one embodiment of the present disclosure. -
FIG. 5 is a diagram illustrating a process including a push notification login, in accordance with one embodiment of the present disclosure. -
FIGS. 6A-6D are diagrams illustrating a process for registering new users to a service provider website, in accordance with one embodiment of the present disclosure. -
FIG. 7A illustrates a data flow for using a dynamic code to implement a challenge code that is passed between devices used when performing authentication and login onto a web portal of a web server as illustrated inFIGS. 4A-4B , in accordance with one embodiment of the present disclosure. -
FIG. 7B illustrates a QR code including a session ID, in accordance with one embodiment of the present disclosure. -
FIG. 7C includes a second bar code including a signed shared-string, in accordance with one embodiment of the present disclosure. -
FIG. 8A is a diagram illustrating a system for performing biometric authentication of a user, in accordance with one embodiment of the present disclosure. -
FIG. 8B illustrates a data flow for using the verification of the certification of user generated data (e.g., biometrics), such as in a method for authenticating the user, to control access to products and/or services, in accordance with one embodiment of the present disclosure. -
FIG. 9A is a diagram illustrating a process for registering and validating a user, which in this case is the Traveler, in accordance with one embodiment of the present disclosure. -
FIG. 9B is a diagram illustrating a process for registering and validating the image of the Traveler (e.g., selfie), in accordance with one embodiment of the present disclosure. -
FIGS. 10A-10B are diagrams illustrating the authentication of a Traveler at a transportation service (e.g., airline), in accordance with one embodiment of the present disclosure. -
FIGS. 11A-11B are diagrams illustrating a method for checking a certification of a Traveler, such as by an Agent of a transportation service, in accordance with one embodiment of the present disclosure -
FIGS. 12A-12B are diagrams illustrating a method for registering an Agent of a transportation service and logging in the Agent, in accordance with one embodiment of the present disclosure. -
FIG. 13 is a diagram illustrating a method for performing third party certification of custom name/value pairs, in accordance with one embodiment of the present disclosure. -
FIG. 14 illustrates components of an example device that can be used to perform aspects of the various embodiments of the present disclosure. - Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure. Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description.
- Generally speaking, the various embodiments of the present disclosure describe systems and methods that provide for authenticated login, registration, and call center validation. In particular, embodiments of the present invention allow users to login to websites, services and other portals without the use of usernames or passwords. Further, embodiments of the present invention allow users to remotely validate themselves such that a remote or local operator, such as those at a call center or a teller, can definitively authenticate a user in order to gain access to their profiles and other information. Other embodiments of the present disclosure describe systems and methods that provide for certification of user generated data (e.g., biometrics), which can be used for authenticating a user, and for providing access based on the certification.
- With the above general understanding of the various embodiments, example details of the embodiments will now be described with reference to the various drawings. Similarly numbered elements and/or components in one or more figures are intended to generally have the same configuration and/or functionality. It will be apparent, that the present embodiments may be practiced without some or all of these specific details. In other instances, well-known process operations have not been described in detail in order not to unnecessarily obscure the present embodiments.
- Embodiments of the present invention are based on an identity management platform implementing a technology layer that interacts with a blockchain. The blockchain securely holds data used for certifying identity transactions. In a traditional sense, a blockchain is a technology that forms the heart of the cryptocurrency, Bitcoin. In embodiments, the blockchain technology can be used by several integrated systems for purposes other than currency transactions, such as for identity management. There are various implementations of the blockchain beyond what is used in Bitcoin, including but not limited to Ethereum and Hyperledger.
- In one embodiment, registration (e.g., of a user) (also referred to as validation) is implemented with an identity manager using a blockchain. Further, a certification process may be processed for certifying the registration and/or validation. In one embodiment, to register a user, some form of user identification (e.g., a driver's license or passport) is scanned. One or more fields are extracted, such as your name, license number, passport number, date of birth (or other data), etc. Also, that identifying information can be gathered individually. Further, the identifying information can be gathered manually. The data is then processed to produce a hash of the data. Optionally, to further obfuscate the original data, the hash can be produced of the original data along with a paired random data to prevent brute-force discovery of the hashed data; in this case, to validate the hash, the data and the random data must always be used together. In this example, the private key that is present on the mobile device can be used to create a digital signature of that hash. The signed hash value and optionally the public key of the user are stored to the blockchain; if the public key is not stored on the blockchain, it can be shared through other means when it is necessary to validate the digital signature. In one configuration, the various fields are put together in one record to create an ID (e.g., in the form of a seal) for that user.
- The user can then provide the raw data with a public key and a pointer to that record on the blockchain in order to allow verification of the data by a third party. In particular, this provides a correlation between the data (e.g., the raw data) that the user has on the mobile device and what's on the blockchain. That is, the raw data that is newly presented may be verified using the data on the blockchain.
- In still other embodiments, following the registration process, a user can be certified by some other trusted party, such as a hank or “know your customer” (KYC) checking company, which then can issue a certification for the user, based on the seal associated with the registration and validation of the user. By way of example, these certifiers can use their own private key to write the records on the blockchain, pointing to record entry of the user that is also on the blockchain. This certification may be referred to as the “User ID” (e.g., ShoCard ID issued by ShoCard, Inc.). As such, there are generally two steps: the first step is the registration process where hash signatures of the individual fields are sealed on the blockchain, and the second step is a certification of the sealed registration.
- In still other embodiments, the platform providing registration and certification also provides for a secure work-around in cases when a bank suspects a credit card transaction could be fraudulent and wants to reject that transaction. The bank, for example, can send a notification/challenge (e.g., a secure notification), wherein the challenge looks for a response confirming the user, and the challenge also confirms that the user authorizes the current transaction. Additional features can include use of a biometrics for access-control (e.g., Touch ID). In one embodiment, each time a private key can be accessed to answer those questions. In one embodiment, by using the private key of the user when responding to questions (i.e., to see the data or questions), it is possible to avoid using clear text, which can ultimately be hacked.
- Thus, embodiments of the present invention provide for being able to authenticate the user whenever the user does any kind of transaction, such as logging into a website, calling a call center, authenticating a transaction. In particular, the systems, methods, and technical operations described herein, and based on the identity management platform providing for registration and/or certification of data, can be implemented with the confidence of knowing who the user really is, and enabling this verification process in a timely manner.
- The registration and/or validation process may be referred to as “sealing.” Certification of the registration may be referred to as “certifying.” In particular, sealing is the process of hashing and digitally signing the User ID data and storing it in the blockchain. Once it is sealed in the blockchain, the data becomes a permanent record. The data in the user ID may be changed, but the new data must be resealed in a new blockchain record. In one embodiment, no readable information is stored in the blockchain, only an indecipherable digital signature of a hash that can only be verified by producing the original data that was hashed and the user's public key. The user data is in control of the user and not available on the blockchain.
- Certification of the registration and/or validation is the process of another party (e.g., third party, bank, airline, etc.) acknowledging the accuracy of the user ID that is registered, and marking that data (e.g., user ID) with a certification that can be recognized, such that the data can be recognized as being accurate when presented in the future, without having to see any other evidence of identity beyond the user ID. To certify a user ID, the raw data (e.g., user ID) is encrypted and delivered to the certifier. The certifier performs decryption and generates a new hash based on the newly presented raw data and then verifies the digital signature of the hash on the blockchain against the newly generated hash and the public key of the user. If the verification process is a match, this proves that the user has the private key(s) that is used to create both records. If the certifier is satisfied that the user is as they represent, the certifier can create a new record (e.g., certification record) with their own private key(s) that references the user ID that is registered and stored in the blockchain. The certifier can also create a separate signature for each field that it is able to verify (e.g., user name, date of birth, etc.). In this case, each field is ultimately a key=value pair where the value is a digital signature of the hash of the data being certified signed with the private key of the certifier. In the future, when the user presents their user ID to a third party along with the pointer to the certification records, the third party can check the certification to make sure that the user is presenting the same user ID that was previously certified.
- It should be understood that the embodiments and described use cases described herein are only by way of example. Many new use cases can be encompassed and facilitated by the functionality based on the technology and identity management platform implementing registration and/or certification of data. For instance, identity verification (e.g., verification of a registration and/or certification of data) can be integrated into various commercial applications, as well as private applications. Commercial applications may include those that require commercial entities to verify the identity of a user. Verifying the identity of a user can be required for achieving any number of functions, such as traveling, making transactions, banking, communication, loan verification, credit verification, purchase verification, and other uses. In other embodiments, private identity verification can also be facilitated using the methods, apparatus, computer readable media, and systems described herein. For example, private identity verification may be useful when a user wishes to prove their identity to another user in a fast and efficient manner. The systems and methods described herein write data to the blockchain database, which is non-rewritable and permanently maintains the record without compromise. This enables writing of information to the blockchain in a manner that can be verified by one or more transactions executed by methods of the present inventions.
- Additionally, the systems and methods described herein may be executed with any number of computer systems. By way of example, the computer systems may include user devices, such as mobile phones, tablets, desktop computers, watch computers, head attached computers, eyeglasses computers, or combinations thereof. Server operations may also be performed and communicated between client devices, to facilitate transactions with the blockchain database, server storage, and the like. By way of example, these computer devices can communicate over networks, such as the Internet, local area networks, Bluetooth, Near Field Communication (NFC), or even via exchange of codes such as QR codes. The networks enable individual devices to transact with each other, such as by way of sending, receiving, and processing exchanged information. The exchanged information can include different types of encrypted data, hashed data, data envelopes, codes, QR codes, PDF417 codes, messages, notifications, and other types of data.
- In embodiments, the messaging and communication functions described herein are provided to enable users to exchange data over communication networks in order to verify identity, or enable or provide access to users to services, goods, or commercial transactions. In the case of banking operations, the verification process can be utilized by banks, as well as users of the bank, or third parties that require certified information from the banks regarding those users. In the case of travel type verifications, different travel entities can require identification of users, and the identification can also be verified by themselves or by other third parties that are trusted. These operations can be facilitated using the systems, methods, computer readable media, and code that execute the verification processes. Broadly speaking, verification of a user identity (e.g., verification of the registration and/or certification of data, such as user ID) can be useful in any type of industry, or private setting. The use of verification is simply facilitated by using the verifying infrastructure, programs code, applications, and combinations thereof, to ensure that verification is secure.
- In some embodiments, the verification systems can be embodied in an application, such as those that can be installed on mobile devices (e.g., Apps). By way of example, users wishing to have their identity verified can use an application to seal information regarding their identity. Once the data has been sealed (e.g., encrypted data has been stored to the blockchain), this data (e.g., raw data) can be used for later certification by another party. The other party may also be utilizing a corresponding App, which enables efficient reading of the data, code, QR code, message, or notification, to validate the identity of the user.
- In still other embodiments, code plug-ins can be integrated into commercial websites, which may use identity verification for different reasons or functions. For example, banks can install plug-in applications, code, or programs that can execute part or all of the verification processing to seal information and/or to certify information regarding identity. In view of the foregoing, it should be understood that the verifying processes described herein and the various use cases are only by way of example, and additional use cases will be evident to those skilled in the art.
-
FIGS. 1A-1C show data flows for the registration and/or validation process as well as the certification of the registered data, for example, as implemented by the identity management platform described herein, in embodiments of the present invention. These processes are performed to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics). - In particular,
FIG. 1A illustrates adata flow 100A for registering data in a blockchain, such as for registering user identification, in accordance with one embodiment of the present disclosure. Atoperation 105, auser 5 may generate and/or capture any type of raw data (UGD) and have that data certified by a third party (e.g., certifier). There are no limitations as to the type of data generated. For example, the data can be any of the following types, but not limited only to these types of data: a simple text string; a date; an enumerated data type; a number; an arbitrary series of data bytes (e.g., a data block), a digital key, biometrics, etc. For distinction, the data types would have a name associated with them, so they appear in a key:value format (e.g., Name=Value). - This data can be saved locally on a device associated with the user 5 (e.g., mobile phone operating an identity management application). The
user 5 would then seal her record by writing this data to ablockchain 50 inoperation 115. This can be done by either inserting a new seal record with the added user generated data, that may overwrite any previous seal (if any), or a new seal that complements any prior seals. - The value field written to the blockchain is for registration and/or validation of the original, raw data only. The
user 5 is expected to securely hold onto that data (e.g., through encryption) and only share it when the user chooses to. Hence, the data is first hashed inoperation 110 so the UGD becomes <hash.UGD>. In embodiments, any number of hashing algorithms can be used, such as SHA256. In addition, theuser 5 then signs the <hash.UGD> with a private key of the user, producing <signed.hash.UGD> (e.g., using Touch ID). Inoperation 115, the signed hash becomes the value that is then written to the blockchain in the form: Name=<signed.hash.UGD>. More particularly, aseal 120 is generated that includes a transaction identifier for the blockchain that can be used to access the signed hash value (<signed.hash.UGD>) at the appropriate location in the blockchain. -
FIG. 1B illustrates adata flow 100B for certifying the registered data using a blockchain, such as for verifying raw data that is registered with an identity manager using ablockchain 50, and for certifying the raw data (e.g., user identification) that is registered, in accordance with one embodiment of the present disclosure. Once therecord 120 is registered and sealed, atoperation 125 theuser 5 may then present the UGD (securely maintained by the user or another device storage of her choosing), along with her public-key and a pointer to theseal record 120 on the blockchain to another party. In one embodiment, the other party is averifier 30 that performs operations to verify the UGD. In another embodiment, the other party is acertifier 20 that performs operations to certify the registered UGD.Operations certifier 20 orverifier 30 for purposes of verifying the UGD that was previously registered, though these operations are shown as being performed by thecertifier 20. In particular, atoperation 130, a request to access the registeredseal record 120 is made to thepublic blockchain 50, and atoperation 135, theseal record 120 is returned to the certifier. - In
block 140, operations are performed for verifying the UGD. In particular, the data stored in theblockchain 50 is extracted, namely the signed hash value (<signed.hash.UGD>). In addition, the newly presented UGD is hashed using the same hash algorithm that was performed when registering the data. Verification of the raw data (UGD) is performed by performing a verification process on input data including the newly generated hash value, the public key of the user, and the <signed.hash.UGD> stored on theblockchain 50. For purposes of illustration only, in the verification process, hash values of the UGD newly generated and based on the <signed.hash.UGD> (e.g., using the public key), may be compared, and is verified when the hash values match. - In
block 145, thecertifier 20 begins the certification process. In particular, validation of the raw data (UGD) is performed. For example, the raw data is inspected to see if it conforms to public form (e.g., follows the form of a driver's license), and is validated if the raw data as presented conforms with the public form. Then, the seal 120 (e.g., transaction identifier or txn-ID) along with the public key of thecertifier 20, and any other suitable data, is signed using the private key of thecertifier 20 to generate a certification signature. In one embodiment, theseal 120 and public key optionally may also be hashed. Data may be combined in a certification record that is signed (using the private key of the certifier 20) and sealed in a blockchain, wherein the data may include one or more of theseal 120 of the UGD (e.g., seal txn-ID, pointer to the blockchain), the raw UGD, the certification signature (as the raw data of the certification record), public key of certifier, etc. Atoperation 150, the certification record is sealed in the same ordifferent blockchain 50, and inoperation 155 the certification record seal including the pointer to the blockchain where the certification record is stored is returned to thecertifier 20 for distribution. For example, the certification record seal is provide to theuser 5 to offer as certifying proof of the UGD, as is described inFIG. 1C . - In particular,
FIG. 1C illustrates adata flow 100C for verifying the registered data, and for verifying the certification of the registered data, in accordance with one embodiment of the present disclosure. For example, atoperation 165 theuser 5 may present the raw UGD (and other information) to a third party, along with registration and certification record information, so that the third party may verify the UGD using multiple factors (e.g., registration and/or certification). That is, data may be combined for presentation, and includes one or more of the raw UGD, public key of theuser 5, seal 120 of the UGD (e.g., seal txn-ID, pointer to the blockchain), the certification signature (as the raw data of the certification record), the certification record seal (e.g., certification seal txn-ID, pointer to blockchain), public key of certifier, etc. For purposes of illustration, the third party isverifier 30. - At
operations verifier 30 obtains the seal record 120 (e.g., using txn-ID for the blockchain) to obtain the data stored in the blockchain 50 (e.g., <signed.hash.UGD> and public key of user 5) to verify the raw data (UGD). Atblock 180, operations are performed to verify the data. For instance, the data stored in theblockchain 50 is extracted, namely the signed hash value (<signed.hash.UGD>). In addition, the newly presented UGD is hashed using the same hash algorithm that was performed when registering the data. Verification of the raw data (UGD) is performed by performing a verification process on input data including the newly generated hash value, the public key of the user, and the <signed.hash.UGD> stored on theblockchain 50. For purposes of illustration only, in the verification process, hash values of the UGD newly generated and that based on the <signed.hash.UGD> (e.g., using the public key), may be compared, and is verified when the hash values match. - When the hash values match, verification of the certification of the registered raw data (UGD) is performed. In particular, at
operations verifier 30 obtains the certification seal record (e.g., using certification seal txn-ID for the blockchain) to obtain the data stored in the blockchain 50 (same or different blockchain). That is, atoperation 190 the certification record is returned to theverifier 30. Atblock 195, operations are performed to verify the certification record. In particular, the data stored in theblockchain 50 is extracted, namely the certification record which may be signed using the private key of the certifier 20 (e.g., signed hash value (<signed.certification record>). In addition, the newly presented certification record can be hashed using the same hash algorithm that was performed when sealing the certification record—however, the method of hashing needs to be known so it can be reproduced. Verification of the certification record is performed by performing a verification process on input data including the newly generated hash value, the public key of thecertifier 20, and the <signed.certification record> stored on theblockchain 50. For purposes of illustration only, in the verification process, hash values of the UGD newly generated and hash valued based on the <signed.hash.UGD> (e.g., using the public key), may be compared, and is verified when the hash values match. In addition, inblock 195, verification of the raw data, UGD, may be performed if not already performed. In that manner, the verification has been performed on the UGD itself and a certification of the UGD. As such, upon successful verification of the UGD and certification record, atoperation 197 the presented UGD is trustworthy after going through a verification of the UGD and the certification record of the UGD. -
FIG. 2 illustrates the implementation of a blockchain to ensure the integrity of the data embedded within, in accordance with one embodiment of the present disclosure. The blockchain is used for implementation of processes that are performed to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics) based on the registration, validation, and/or certification of raw data. A simplified version of a blockchain is shown inFIG. 2 . A block of one or more new transactions is collected into the transaction data part of a block. Copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, which represents the merkle root of a merkle tree. The merkle root is stored in the block header. Each block also stores the hash of the previous block's header, chaining the blocks together. This ensures a transaction cannot be modified without modifying the block that records it and all prior blocks. -
FIG. 3 is a diagram illustrating asystem 300 for performing authentication and login onto a web portal of a web server, wherein two devices of theuser 5 interact with theweb server 320 for authentication purposes, in accordance with one embodiment of the present disclosure. For example,system 300 may be implemented to perform authenticated login, registration, and call center validation. In particular,system 300 may be configured to allow users to login to websites, services and other portals without the use of usernames or passwords. Further configurations ofsystem 300 allow users to remotely validate themselves such that a remote or local operator, such as those at a call center or a teller, can definitively authenticate a user in order to gain access to their profiles and other information. - In particular,
user 5 is associated with two electronic devices, such asclient device 310 anddevice 11.Client device 310 may include a web browser configurable for communication over anetwork 150, such as the internet. For example,client device 310 may present to user 5 a login page of aweb server 320, wherein the login page may be delivered to thedisplay device 12 associated with auser 5. In addition,device 11 of theuser 5 may be used in conjunction withclient device 310 in order to perform the login process enablingclient device 310 to accessweb server 320.Client device 310 anddevice 11 can be any type of computing device having at least amemory 1404 and aprocessor module 1430 that is capable of connecting to thenetwork 150. Some examples of client device 100 include a personal computer (PC), a game console, a home theater device, a general purpose computer, mobile computing device, a tablet, a phone, or any other types of computing devices. -
Web server 320 includes any type of computing device having at least amemory 1404 and aprocessor module 1430 that is capable of connecting to thenetwork 150.Data store 325 may be controlled and/or accessible byweb server 320.Web server 320 may be configured to provide information and/or services overnetwork 150. In particular,web server 320 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics). -
Identity manager 330 includes any type of computing device having at least amemory 1404 and aprocessor module 1430 that is capable of connecting to thenetwork 150.Data store 335 may be controlled and/or accessible byidentity manager 330. In particular,identity manager 330 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and certification of user generated data (e.g., biometrics). -
FIGS. 4A-4B illustrates adata flow 400 for performing authentication and login onto a web portal of aweb server 320 as illustrated inFIG. 3 , wherein two devices of theuser 5 interacts with the web server for authentication purposes, in accordance with one embodiment of the present disclosure. The data flow 400 ofFIGS. 4A-4B may be implemented within thesystem 300 ofFIG. 3 , and may implement portions of the methods described in the data flows 100A, 100B, and 100C ofFIGS. 1A-1C . As shown, parties to the login process include auser 5, who is associated with afirst device 310 and asecond device 11, anidentity manager 330, and aweb server 320, wherein theuser 5 is requesting login access to theweb server 320. - In general,
data flow 400 shows the flow of data when logging into a web site using a QR code. For example, a user enters a web site and may be presented with one or more forms of authentication paths to login (for example, username/password and a button to login). On the screen, there is a QR code or other similar graphics that encodes data information (such as a bar code). For purposes of illustration, the QR code is referenced and intended to represent any type of code. The user uses his/her mobile application designed to comprehend the contents of the QR code and determines that this is an authentication badge for login. The application presents the user with a question to determine if the user chooses to login and pass his/her credentials. This process may request an additional form of authentication on the mobile device such as a finger thumbprint Id (e.g., touch ID, and/or other biometric identification), or a PIN passcode. Once the user authenticates himself/herself, a message is sent to the server specified in the QR code encoding and the server is able to authenticate the user and allow the user to login on the website. The browser session in this case is connected to the server and receives notifications from the server. These notifications can be done via JavaScript polling, websockets, vendor specific push notifications or other forms of connected communication. The server then provides the browser session with the page that the user would have logged into similar to how the session would have been performed using a normal username/password login. - At
operation 403, theuser 5 via thefirst device 310 requests a login web page from theweb server 320 over a communication network (e.g., internet). Upon receiving the request for login, theweb server 320 performs operations as outlined inblock 405. For example, the operations are performed to create a web envelope of data. In particular, a session ID is generated byweb server 320, which may be generated in response to the request for the login web page, or may be generated in anticipation of a login request (e.g., such as at a login kiosk). As shown, a factor in the authentication and login process is the use of the session ID, such that the session ID is used throughout the authentication and login process, thereby connecting the devices used in the process. The session ID is associated with a communication session that will be established after successful login of theuser 5. In addition, web data may be generated by theweb server 320 to include one or more of the session ID, a timeout for the session ID, URL web address for theweb server 320, etc. Also, the web data may optionally include the public key of theweb server 320 for convenience of access with the web data, though the public key may be obtained elsewhere as commonly implemented. In addition, the web data may be hashed using a hash algorithm (e.g., using any number of hashing algorithms can be used, such as SHA256). Further, a signature of the web data may be generated, using the private key of theweb server 320. The web data and the signature are combined into an envelope of web data. - At
operation 407, theweb server 320 sends a request for an envelope ID to theidentity manager 330. The request includes the envelope of web data. Inblock 410, theidentity manager 330 performs operations to include storing the envelope of web data, and generating the envelope ID, which is associated with the envelope of web data. As such, theidentity manager 330 is able to access the envelope of web data that is stored based on presentation of the envelope ID. Atoperation 413, theidentity manager 330 returns the envelope ID to theweb server 320. - In
block 415, various operations are performed byweb server 320 upon receipt of the envelope ID. Generally, a login page is generated with information facilitating authenticated login. In particular,web server 320 generates a scannable code (e.g., QR code), which includes at least one of the envelope ID, URL of theweb server 320, and a login challenge asking whether a login process is further requested. The scannable code is included in the login page. Though embodiments are described using a scannable code, other types of codes that are configured to deliver information between devices are also suitable. - At
operation 417, the web server delivers the login web page to thefirst device 310 of theuser 5. Atoperation 420, thefirst device 310 ofuser 5 displays the login web page that includes the scannable code, wherein the scannable code includes at least the envelope ID. As previously described, the envelope ID is associated with a first envelope of data including the session ID, and wherein the envelope ID is generated by anidentity manager 330 at the request of theweb server 320. - In
block 423 various operations are performed, including configuring and/or operating thesecond device 11 to scan the scannable code. In that manner, the envelope ID can be extracted, and used to access the first envelope of data. Typically, the scannable code is of a limited size that may not be able to accommodate the size of the first envelope of data, though in some embodiments, the scannable code may be of sufficient size. As shown, a factor in the authentication and login process includes the use of two devices (first device 310 and second device 11) associated with theuser 5. InFIG. 4A , atoperation 425, thesecond device 11 requests the first envelope of data from theidentity manager 330, wherein the request includes the envelope ID. Based on the envelope ID, the identity manager is able to access the envelope of data atoperation 427, and atoperation 430 return the first envelope of data to the second device. However, if the scannable code is able to include the entire data identified inblock 405, it may not be necessary to create an envelope and an envelope ID—the scannable code in this case would have the entire data. - At
block 435 various operations are performed by thesecond device 11 ofuser 5. The session ID is extracted from the envelope of data, as well as any other data included in the envelope. Verification of the data may be performed, such as byverification engine 1442. As previously described, the verification logic is well known, and includes inputting at least one of the web data, the public key of the web server, and the signature of the web data, wherein the verification logic confirms or denies the verification of the web data. As shown inFIG. 4A , the method proceeds to connector A. The method ofFIG. 4A may proceed to intervening connector B before returning to connector A when a dynamic code is inserted into the authentication and login process, for example to provide additional security by ensuring the proper devices are participating throughout the entire authentication and login process, as will be further described inFIGS. 7A-7C . - Continuing with connector A, in
FIG. 4B , the method proceeds to block 440, wherein thesecond device 11 performs multiple operations after the data within the envelope of data has been verified and can be trusted. In particular, user data is collected and/or generated to include at least one of the session ID, user identification that may be recognizable by theweb server 320 and is registered (e.g., with the identity manager 330), a seal of the registered data (e.g., user identification), a seal of a certification record certifying the registered data, the certification record, a login response (e.g., affirmative response to login challenge), public key of the user, etc. - Further, the user data is hashed (<hash.userdata>) using any suitable hash algorithm, such as SHA256. The
second device 11 is configured to sign the hash value with a private key of the user (e.g., producing <signed.hash.userdata>). The signature process may be authorized by the user for example using Touch ID. Optionally, the user data and the signature may be encrypted using a public key of theweb server 320. The resulting user data and signature, or resulting encrypted user data and signature, is packaged as a return envelope of data, such as a secure envelope (e.g., when encrypted). By optionally encrypting the package inblock 440, the user can ensure that the only entity able to read its response to the login request is the intended Web server and that the package being delivered remains unmodified. The signature of the user in the package can provide the Web server an assurance that this particular user has indeed composed the entire data and response being sent back. Because the data being signed also includes a unique one-time session ID, the protocol ensures that the users' response cannot be re-used for another login session using the users' credentials. - At
operation 445, the secure envelope of data is delivered from thesecond device 11 to theweb server 320 via theidentity manager 330. For example, the envelope is delivered in a confirmation login request that is responding to the login challenge. The confirmation login request includes the secure envelope of data. As such, the secure envelope is received at the identity manager atoperation 447, such as in the confirmation login request, wherein the envelope is delivered atoperation 450 from theidentity manager 330 to theweb server 320. Because the envelope is secure, theidentity manager 330 is prevented from extracting information from the envelope, and the secure envelope is delivered securely (without exposure) toweb server 320. - At
block 453 various operations are performed byweb server 320 upon receipt of the secure envelope in the form of the confirmation login request. In particular, if the envelope is optionally encrypted, a decryption process is performed (e.g., using the private key of the web server 320). As such, after decryption the data in the envelope is known, to include at least one of session ID, a user ID, and a seal of the user ID registering the user ID (e.g., with the identity manager), affirmation of the login challenge, etc. A verification of the signature may be performed to determine whether the data is trustworthy (e.g., has not been modified during transmission). As previously described, the verification logic is well known, and includes inputting at least one of the user data provided in the envelope, the public key of the user, and the signature of the user data, wherein the verification logic confirms or denies the verification of the user data. In addition, the session ID may be verified as being valid. That is, the confirmation login request may be verified as a response to the login challenge issued by the web server 320 (e.g., as being part of a valid transaction) using the session ID returned with the confirmation login request. Since theweb server 320 generates all the session IDs, the present session ID may be cross-checked to determine whether it is a valid session ID, and whether the session ID has not timed out, or to perform any other validation process. As shown, another factor in the authentication and login process includes the verification of the signature to trust the information (e.g., session ID), and to confirm that the user's response is in fact to this particular session ID (versus being re-used from another session). - Further in
block 453, the user ID may be verified following the verification logic presented above. Verification of the user ID is another factor in the authentication and login process. Correspondingly, the user is verified based on the user ID that is presented. That is, inputs are provided to the verification logic to include the user ID, the public key of the user, the seal of the user ID (to include the transaction identifier for the blockchain that stores the signed hash value of the user ID), and the signature of the hash value of the user ID. The verification logic confirms or denies the verification of the user ID. Also inblock 453, the certification of the user ID may be verified following verification logic presented above. Verification of the certification of the user ID is another factor in the authentication and login process. For example, inputs are provided to the verification logic to include the certification record, the public key of the user, the certification seal of the certification record (to include the transaction identifier of blockchain that stores the signed hash value of the certification record), and the signature of the hash value of the certification record. The verification logic confirms or denies the verification of the certification record. - User login for
user 5 is authorized upon successful verification of the login challenge and user. In particular, once successful verification of the user ID and/or the verification of the certification of the user ID are achieved, the user is authorized for login. In that manner, atoperation 455, a communication session is established between theweb server 320 and thefirst device 310 ofuser 5. -
FIG. 4C illustrates adata flow 400C when exchanging a secure envelope of data between two entities via anidentity manager server 330, such as when performing authentication and login of auser 5 onto a web portal of aweb server 320 as illustrated inFIGS. 4A-4B , in accordance with one embodiment of the present disclosure. That is, thedata flow 400C may be implemented to deliver a secure envelope of data between the user A (e.g., user 5) and user B (e.g., web server 320), to include participation by data store server (e.g., identity manager 330). - It is possible to provide the secure exchange of data between two entities (e.g., users A and B) by using a server (data store). In the example, of
FIGS. 4A-4B , the secure exchange of data is performed betweenuser 5 andweb server 320 usingidentity manager 330. This process allows for delivery of data when it may not be feasible to exchange large data sets directly between the two entities. For example, the two entities may be on a mobile device, or be interacting via an intervening web page. In this case, the two entities cannot exchange data directly without having a communication path. - The assumption in this exchange is that the two entities already know one another and are aware of each other's seal ID, and ultimately each other public keys associated with the private keys they've used to seal their identification. (See block 460).
- In one embodiment, the two entities can share data through digital codes, such as a bar-code, a QR code, PDF417 code or any other similar type of displayable codes. As such, variable sizes of data blocks (potentially very large data blocks) can be securely exchanged between such two entities by utilizing a server (e.g., identity manager 330) in the middle. In particular, the
identity manager 330 stores and directs the message for the two entities, but is unable to ever read any of its content. The server in the middle includes a data store, but can be any server (e.g., identity manager 330). - In particular, user A intends to send a block of data to
user B. Block 463 illustrates multiple operations performed by user A in preparation of sending the block of data. In particular, user A places that data in a data block and may add additional identification fields to that block of data such as timestamp, its own seal Id, user B's seal Id, it's public key and if there is a session between the two, a session ID. The value of the timestamp and the session ID is to ensure vitality of the data block versus one that may have been created and somehow reused again. This data block will be referred to as <dataBlock>. - Next, as outlined in
block 465, user A uses its own private key to digitally sign the <dataBlock> that was created. The result is <envelopeSignature>. Next, an <envelopeContent> is created by putting together the <dataBlock> and the <envelopeSignature>. Last, a <secureEnvelope> is created by encrypting the <envelopeContent> with user B's public key. - Once a <secureEnvelope> is created by User A, the <secureEnvelope> is sent to Store in
operation 467. Inoperation 470, store creates a unique <messageId> that is associated with the <secureEnvelope>, and inoperation 473 it returns that identifier to User A. User A then relays the <messageId> inoperation 475 and possibly the address of the Store server (if not a well known server service between the two users) to user B. This data is rather short and can easily fit in nearly all digital codes such as a bar code, a QR code, PDF417-code, and the like. - User B receives the data in some form, such as scanning the code from the mobile screen of User A and then sends a message to Store to get the <secureEnvelope> associated with the <messageId> in
operation 477. Inoperation 480, store returns the associated <secureEnvelope>. User B can view the <envelopeContent> by decrypting the <secureEnvelope> using his private key that no one else is aware of, as shown inblock 485. It may then verify the <dataBlock> in the envelope content by verifying the <dataBlock> and the <envelopeSignature> with the user A's public key that was passed. It may also verify that this is the same public key that was used in user A's SealId. - Further, if the protocol requires that the transmission be a onetime process, the <secureEnvelope> can be deleted after a successful transmission, as detailed in
operation 483. For example, it is also possible to delete the envelope if an expiration time is associated with it. - The technologies for registration, validation, and certification of data (e.g., user data) described previously in at least
FIGS. 1A-1C can be used in various additional use cases that may involve authentication and/or login, in embodiments of the present invention. For example,FIGS. 4D, 5, and 6 illustrate different use cases providing for website login, logging in for services without using a password, and new user registration. Other use cases are also disclosed below. - In
FIGS. 4D, 5, and 6 , and throughout parts of this specification, various terms are used with similar functionality and definition, unless otherwise defined, and are summarized below. For instance, the term “user” refers to an individual who has identifying credentials. The user typically wishes to gain access to particular service or product, as is described throughout this specification. The term “service provider” refers to an entity to which a user wishes to gain access. For example, the service provider may be a website, a physical building, an employer, a club with membership privileges, an automobile, an airline, or any other service or product. The term “man-in-the-middle” refers to a system or individual listening to communication between two parties in either electronic or analog form. For example, the man-in-the-middle may be a hacker. The term “verifier” refers to a service which is configured to verify some or all of user information associated with a user. The term “certifier” refers to a service which is configured to certify the user information (which previously could have been verified and validated). The certifier is configured to produce a certification record, which uniquely further identifies data (e.g., user information), and can be used as proof that certain data belonged to a certain user at the time of the certification according to the certifier. The term “session ID” refers to a unique identifier that may be used throughout an authentication and login process, thereby connecting the devices used in the process, and wherein the session ID may be associated with a communication session that will be established after successful login of a corresponding user. The term “signature” refers to a process by which a user is able to digitally sign data using a public/private key pair. The process of signing data may be protected with access control to the App or device. For example, a Touch ID process previously introduced may be used as the user's permission to allow the App to digitally sign data on the user's behalf. - In
FIGS. 4D, 5, and 6 , and for other processes described throughout this specification and/or in other figures of this specification, various requirements are present for providing secure authentication between the users and the service providers, as described below. 1) For example, all communication between a user and a service provider must be secure such that if a man-in-the-middle intercepts (e.g., sniffs) the data exchange, he/she is unable to either successfully alter the request so it appears authentic, replicate the request to allow alternate authentication, or gain information on the user PII (Personally Identifiable Information) or actions being performed by the user, in one embodiment. 2) Also, in another embodiment, it is possible to provide these authentication and/or login services without requiring secure communication between the user and service provider. In this case, the capabilities for authentication and login can be provided without providing complete security. This can be the case if (a) the user is within a secure environment where outside or hacker attack is deemed not probable, (b) all communication is done through a secure channel (e.g., secure socket layer—SSL), (c) security violation is not deemed to be a threat or of importance, and/or (d) security is ignored. 3) In another embodiment, each session requiring authentication should be identified by a unique Session-ID that is generated by the service provider. 4) Also in other embodiments, the user must have previously been registered with the service provider. 5) Further, in other embodiments, the service provider does not necessarily need to know the phone number of the device the user utilizes for authentication. 6) Also, in other embodiments, each request may be authenticated in real time, although it can also be done in batch processing or offline (which may experience slower results). 7) Further, in other embodiments, the user may optimally provide an additional factor for authentication such as passcode or Touch ID on their mobile device. This additional factor may not be necessary, as the user may have other forms of security in place that would provide for additional security, or this factor may not be necessary when security is not of concern. 8) In other embodiments, the user is in possession of a private/public key for encryption/decryption and signing. 9) In still other embodiments, the service provider may not necessarily know the current public key of the user until the authentication request is initiated. 10) In other embodiments, the user is able to authenticate each request by being able to utilize its private-key to digitally sign the request. This may be an optional requirement that when performed provides for additional security. -
FIG. 4D is a diagram 400D illustrating a process for logging into a website using a QR code, in accordance with one embodiment of the present disclosure. In particular,FIG. 4D illustrates another process for performing authentication and login onto a web portal of aweb server 320 as illustrated inFIG. 3 , and performs similar operations as those described inFIGS. 4A-4C . That is, the process outlined in diagram 400D uses the technologies for registration, validation, and certification of data (e.g., user data) described previously in at leastFIGS. 1A-1C , to allow users to login to websites, services, and other portals without the use of a username or password. - The authentication and login process shown in
FIG. 4D may be used to authenticate a user to a website. In embodiments, a user enters a web site and may be presented with one or more forms of authentication paths to login (for example, username/password and a button to login). On the screen, there is a QR code or other similar graphics that encodes data information (such as a bar code). For purposes of illustration, the QR code is referenced and intended to represent any type of code. The user uses his/her mobile application designed to comprehend the contents of the QR code and determines that this is an authentication badge for login. The application presents the user with a question to determine if the user chooses to login and pass his/her credentials. This process may request an additional form of authentication on the mobile device such as a finger thumbprint Id (e.g., touch ID, and/or other biometric identification), or a PIN passcode. Once the user authenticates himself/herself, a message is sent to the server specified in the QR code encoding and the server is able to authenticate the user and allow the user to login on the website. The browser session in this case is connected to the server and receives notifications from the server. These notifications can be done via JavaScript polling, websockets, vendor specific push notifications or other forms of connected communication. The server then provides the browser session with the page that the user would have logged into similar to how the session would have been performed using a normal username/password login. - In one embodiment, the authentication and login process outlined in
FIGS. 4A-4D can be modified and/or applied to a use case wherein login to a physical port is performed using a QR code. In particular, a user may wish to gain access to a physical portal such as a door that is locked, enter a gym where he/she has an active membership, or enter company premises. At a point of entry, the user scans a QR code that is electronically generated. The message is sent to the server processing authentication. Once the user is authenticated, the server allows access for the user. If the user is at a physical portal, such a locked door, the server may send an authenticated request to the lock box to have it electronically opened. If the user is at a physical portal guarded by an operator, such as a gym-club staff member, the server may send a message with identifying information such as the person's name that was authenticated, their picture and other information and confirm their authentication so they are allowed access. Instead of using a QR code to initiate this process, other forms of communication such as Bluetooth, NFC and other communication methods may also be used, in other embodiments. - In another embodiment, the authentication and login process outlined in
FIGS. 4A-4D can be modified and/or applied to a use case wherein login for access to services is performed using a QR code. In particular, for authentication of a user, a service provider may alternatively employ a QR code scanner through a device and read a QR code generated by the user's mobile app that identifies the user. The identity of the user can be authenticated and based on that determine if the user should be granted access. This can be done with a reader at a portal such as a locked door or entrance into a physical facility guarded by an operator. - In another embodiment, the authentication and login process outlined in
FIGS. 4A-4D can be modified and/or applied to a use case where login to services is performed using a username, but no password. For illustration,FIG. 5 is a diagram illustrating a process including a push notification login for purposes of logging into services using a username, but no password, in accordance with one embodiment of the present disclosure. In particular, a user can gain access to services mentioned previously by entering a username and then processing a control button that ultimately verifies the user—we can refer to this as a “Verify” button. In this case, pressing the Verify button causes the browser or portal to send the username entered to its server that then looks up the reference-ID to the user associated with the username. It then sends a request to a server that is able to send direct or vendor specific push notifications to the user's mobile app requesting authentication. The user is prompted with an option to authenticate and login or deny the request. He/she may be challenged with a passcode or a biometric test such as touch ID. If the user agrees, an authentication message is sent back to the server allowing the user to login. This system can be used for both web based browser authentication as well as physical world authentication. - In still another embodiment, the authentication and login process outlined in
FIGS. 4A-4D can be modified and/or applied to a use case where remote or local user based login is performed. In particular, a user may be required to allow third party access to his/her account. This can be done where the user is local to the third party or remote from the third party. A local example is when a user goes to a bank branch and wants to allow the teller to have access to his/her account so he/she can perform a transaction or inquiry. A remote example is when a user calls a Call-Center to have the operator on the phone access his/her account to answer a question, perform a transaction or respond to an inquiry. In the physical case, the user may use a QR code authentication scheme. On the other hand, the user may simply provide a user-name, account number, or other identifying information so that the call center is able to identify the user, and access related identifying information. Also, the operator (e.g., call center agent) may then initiate a process to send a Verify request to the user on his/her mobile app (e.g., todevice 11 of user 5), wherein the request includes a newly generated session ID. As such, theuser 5 will then receive a request that he/she needs to approve after providing a passcode or biometric authentication (such as Touch ID). For example, a message may be displayed ondevice 11 notifying the user that a login process is requested on behalf of the user by a call center. The message is generated by the call center, and includes a newly generated session ID, for example. The user may accept or reject the login process described in the notification (e.g., selecting an accept or reject button on the display). At this point, the process outlined inFIGS. 4A-4B may begin at connector A and starting atblock 440 onFIG. 4B . Upon approval and authentication, a request is sent back to the server connected to the operator's console and after verification of the response, the operator is then authorized to view the user's information based on the rules of their system. - In another embodiment, the authentication and login process outlined in
FIGS. 4A-4C can be modified and/or applied to a use case where new registration is performed for securely registering new users to a website of a service provider. For illustration,FIGS. 6A-6D are diagrams illustrating a process for registering new users to a service provider website, in accordance with one embodiment of the present disclosure. In particular, a user visits Service Provider's website and is presented with a registration form. The form has a QR Code or other similar graphics which user can scan with his personal mobile device. As a result of this action the Verifier is notified of the request. Verifier validates user data against 3rd party services, publicly available information and other sources of data. Verifier will produce a verification record which can be used by the Certifier to generate a certification record. Service Provider uses this record and user's data to derive information necessary to complete website registration process. Certification record is cryptographically signed, encrypted and stored to prevent alteration. It can be used to verify the data at later time. - In another embodiment, the authentication and login process outlined in
FIGS. 4A-4C can be modified and/or applied to a use case where a user is securely associated with an existing account or user registration in a system of a service provider. In particular, a user visits Service Provider's website and logs in using conventional methods, specific to provider's site. The user navigates to a special page, for example on his profile or setting page and is presented with a form. The form has a QR Code or other similar graphics which user can scan with his personal mobile device. As a result of this action the Verifier is notified of the request. Verifier validates user data against 3rd party services, publicly available information and other sources of data. Verifier will produce a verification record which can be used by the Certifier to generate a certification record. Service Provider uses this record and user's data to derive information necessary to associate this user's identity with an existing account. - As previously described in relation to
FIGS. 4A-4B , an alternative method providing authorization for user login into a service (e.g., via a web page) without using a username and password is to scan a code on the web page screen that contains a specific unique session ID (e.g., using a mobile application facilitating identity management). The application can send the necessary credentials to the web server managing the website along with the session ID to allow the user to login without having to enter a username and password on the screen. In particular, the application is configured to respond with the identity of the user as managed through the use of private/public keys. The key is that the user avoids entering a username and password on the login screen and instead, can scan a code enabling the application to allow the scanning device to communicate directly with the service provider during the login process. The code on the screen can be in any form, such as a bar code, QR code, PDF417 code, or any other format. These codes can be referenced interchangeably in this application, but ultimately perform the same functions. - The code may be used for requesting and accessing large amounts of data used during the login process. Though the process can be made secure, especially with the use of secure envelopes of data as previously described, the codes are static and possibly may be copied and used for login by a fraudulent user. For example, the code may be copied by a hacker off of a browser that is viewable by the hacker through various techniques. Because the code has a valid session ID, if the hacker presents the static code to a real user (e.g., displayed on a phishing site), the unsuspecting user can possibly scan the code and assume that he/she is interacting the real site (instead of the phishing site). As a result, the user believes that login credentials are being sent to the real server. The hacker is able to pose as the user, such that the real server may authenticate the user associated with the session ID and allow the user session to be logged in. However, the browser session that is logged in exists on the browser of the hacker and not the real user.
- Embodiments of the present invention increases the burden of a hacker through the use of an additional dynamic code, which can be another factor in the authentication and login process described in
FIGS. 4A-C . As such, the burden of phishing becomes significantly harder, and a hacker cannot simply copy a static code (e.g., QR code) to fake the user into participating in a fraudulent login process. The user experience remains seamless even with additional steps implementing the dynamic code during the authentication and login process, and the user need not enter a username and password. -
FIG. 7A illustrates adata flow 700 for using a dynamic code to implement a challenge code that is passed between devices used when performing authentication and login onto a web portal of a web server as illustrated inFIGS. 4A-4C , in accordance with one embodiment of the present disclosure. For example,data flow 700 is implemented in the data flows ofFIGS. 4A-4B through connector B, before returning to connector A, such as when a dynamic code is inserted into the authentication and login process to a website of aweb server 320.Data flow 700 may be performed to provide additional security by ensuring the proper devices are participating throughout the entire authentication and login process. As previously introduced, the process outlined inFIGS. 4A-4D and 7A-7C assumes that the user is already registered with the service provider (e.g., web server 320), and that the service provider maintains at least the following record on the user: a user identification, such as a name or a username (optional), and a public key of the user that matches the private key maintained by the user in his or her identity management application. - As shown in
FIG. 7A , the authentication and login process performed before connector B is shown inFIGS. 4A-4B . In particular, thewebsite login page 750 ofFIGS. 7B-7C may or may not display username andpassword fields login page 750 would display a code 760 (e.g., QR code) that a user can scan for use by an identity management application, as is shown inFIGS. 7B-7C . For example, theQR code 760 contains a session ID and the URL of theweb server 320 requiring a response to a login challenge. - The user scans the
QR code 760 to retrieve the referring URL, as well as the session ID. The session ID may be digitally signed by theweb server 320 to provide that it was generated by the service provider (e.g., web server 320) that the user intended to interact with. As such, the user can verify the signature using the public key of that service provider. The verification step is optional. Additionally, the QR code may contain other information, including codes that indicate that this is a login request or challenge. In particular, the a first scannable code (e.g., QR code 760) is scanned on alogin web page 750 of aweb server 320, wherein thelogin webpage 750 is displayed on afirst device 310 associated with theuser 5. The scannable code includes an envelope ID and a login challenge, wherein the envelope ID is associated with a first envelope of data generated by theweb server 320 and includes a session ID. The envelope ID is generated by anidentity manager 330 at the request of theweb server 320, and wherein the envelope ID is used to request the first envelope of data from theidentity manager 330. - Beginning with
block 710 ofFIG. 7A , various operations are performed by thesecond device 11 after scanning theQR code 760, receiving back the envelope of data, and performing other operations on that data. In particular, a unique shared-string is generated. This can be a random string that is created on-the-fly (e.g., a GUID). Other challenge data is generated by thedevice 11, including at least one of the shared-string, session ID, user ID, etc. generally, the session ID and the shared-string is digitally signed using the private key of the user to prove that thesecond device 11 generated the request, and passes the data to the referring URL. For example, a hash of the challenge data may be digitally signed using a private key of the user to prove the trustworthiness of the challenge data later presented. A challenge envelope of data is generated and includes at least one of the shared-string generated by the second device, a first digital signature of a hash of the shared-string using a private key of the user, and a user ID. - The message sent to the
web server 320 may be optionally encrypted with the public key of theweb server 320. That is, the data in the envelope may be optionally encrypted using the public key of theweb server 320. The public key is either known to the user during registration, or included in theQR code 760. - The challenge data (encrypted or not) in the challenge envelope is delivered to the
web server 320 inoperation 720 over a network. At theweb server 320, various operations are performed as outlined inblock 725. A decryption process is performed using the private key of theweb server 320, if the data in the challenge envelope was encrypted. - In addition, the
web server 320 may verify the signature against the data in the challenge envelope (e.g., at least one of the shared-string, session ID, etc.) using the public key of theuser 5. As previously described, the verification logic is well known, and includes inputting at least one of the challenge data provided in the envelope (e.g., session ID, the shared-string), the public key of the user, and the signature of the challenge data (hashed or no hash), wherein the verification logic confirms or denies the verification of the challenge data. In one embodiment, if the public key of the user was passed with the challenge envelope/request, the public key may be used as the user ID. Otherwise, another user identification must be passed to theweb server 320, so that the server can look up the public key in its records (and to identify the user 5). If the signature is verified, theweb server 320 knows that theuser 5 in possession with the private key did indeed sign the session ID (along with the data in the envelope), that was previously generated by theweb server 320. That is, the session ID can be trusted. - The
web server 320 generates a challenge response including the shared-string and a signature of the shared-string. That is, the shared-string created bydevice 11 of theuser 5 is extracted from the challenge envelope, and signed by theweb server 320 using its private key. Optionally, the data included in the challenge response may be encrypted using the public key of the user. - The challenge response is included in a
second code 770 generated by theweb server 320. The new display code could be another QR code, or even one of a different format, such as a bar code, or PDF417 code, etc., as is shown inFIG. 7C . Atoperation 730, the challenge response is delivered to thefirst device 310 ofuser 5. In particular, inoperation 735 thenew code 770 is passed back to the login web page. The login webpage is updated to include thenew code 770, wherein the web page can either remove the initial scannable code 760 (e.g., QR code) including the session ID and display thesecond code 770, or the webpage can display thesecond code 770 concurrently with the first code 760 (e.g., adjacent to the first code 760). - Importantly, the dynamically created shared-string is displayed using the proper form (e.g., contained within the second code 770), so that the
second device 11 ofuser 5 can scan thesecond code 770, and allow the identity management application to confirm that theweb server 320 is establishing a session with a device of the user (e.g.,first device 310 and/or second device 11) during a login process using both user devices, and not trying to establish a session with some other user. In particular, block 740 includes various operations performed by thesecond device 11 ofuser 5. The secondscannable code 770 includes a challenge response including at least one of the shared-string and the digital signature of the hash of the shared-string (e.g., signed using the private key of the web server 320). After scanning, the data contained in the challenge response is optionally decrypted using the private key of the user, if the data was previously encrypted. The shared-string is extracted. - In addition,
device 11 is configured to verify the signature of the data in the challenge response (e.g., the shared-string). Verification of the signature is performed to ensure that theweb server 320 received the challenge envelope and that the web server has acknowledged by sending the challenge response that is digitally signed. As previously described, the verification logic is well known, and includes inputting at least one of the data provided in the challenge response (e.g., the shared-string), the public key of theweb server 320, and the signature of the data (hashed or no hash) in the challenge response, wherein the verification logic confirms or denies the verification of the response data (e.g., the shared-string). In addition, verification of the returned shared-string included in the challenge response is performed to ensure the same value for the shared-string is being passed throughout this portion of the login process. - After successful verification of the shared-string and the signature, the shared-string may be included in the user data, previously described in
FIGS. 4A-4B . That is, the process returns back toFIGS. 4A-4B through connector A, and now includes the shared-string as another factor for authentication. In short, returning back to thedata flow 400 through connector A, thedevice 11 sends a request to theweb server 320 with an authorization to login.Device 11 signs both the session ID and the shared-string along with a confirmation request to login. The data in the message is optionally encrypted using the public key of theweb server 320, and sends the confirmation request to theweb server 320. In other words, a confirmation login request is generated bydevice 11 which responds to the login challenge, wherein the confirmation login request includes a second envelope of data comprising at a minimum the shared string and optionally the session ID, the user ID, and a seal of the user ID registering the user ID with the identity manager. The confirmation login request is delivered to the web server (e.g., via the identity manager) for authentication and login of the user with the web server. In response, after theweb server 320 receives the message (e.g., second envelope of data), the data contained therein is optionally decrypted. All the signatures are verified to be authentic from the user 5 (e.g., verified with the public key of the user). After successful verification, the user is logged into the web site of theweb server 320, and theweb server 320 pushes out a landing page for display by the browser of the user (e.g., on the first device 310). -
FIG. 8A is a diagram illustrating asystem 800A for performing biometric authentication of auser 5, in accordance with one embodiment of the present disclosure. Authentication may be performed in conjunction with a login process, previously introduced inFIGS. 3-7 , in some embodiments. In other embodiments, the biometric authentication process may be performed to control access to services, objects, devices, etc. It is important to note that biometric controls such as TouchID are generally used for Access Control to an App, App function or a mobile device. However, as implemented today, the biometrics of the user is not made available such that a server can do a biometric authentication. Using TouchID in one embodiment would require a server to trust a mobile device, such asdevice 11 inFIG. 6A . Biometrics authentication described in this method allows the server to biometrically authenticate the user. - For example,
user 5 interacts with authenticatingentity 810 for purposes of authenticating the user, such as for controlling access to products and/or services.User 5 is associated withdevice 11, previously introduced, which is used for interacting with the authenticatingentity 810. In general,device 11 is configured for communication with authenticatingentity 810 over network 150 (e.g., internet, phone, etc.). For example,device 11 may include a web browser configurable for communication overnetwork 150. -
Authenticating entity 810 includes any type of computing device having at least amemory 1404 and aprocessor module 1430 that is capable of connecting to thenetwork 150.Data store 815 may be controlled and/or accessible byentity 810.Authenticating entity 810 may be configured to provide information and/or services overnetwork 150, such as through a website, and may use the biometric authentication process as part of an authentication and login process providing access to theweb server 320, as previously described inFIGS. 4A-4D and 7 . In other embodiments, authenticatingentity 810 may be configured to control access to products and/or services. For example, authenticatingentity 810 is configurable to control access to object 820 touser 5, once the user has been authenticated using biometric data that is registered and/or certified.Object 820 may take on any form, including products, services, applications, doors, entryways, etc. In one example, object 820 may be an automobile that is available for short term leasing (e.g., hours, weeks, months, etc.).User 5 has leased the object for a period of time, and the authentication process is performed to provide access to theobject 820 once theuser 5 has been authenticated using biometrics. In addition, authenticatingentity 810 is configured to implement the identity management technology used to perform registration, validation, and/or certification of raw data, to facilitate the implementation of biometric authentication (e.g., through the verification of the biometric data, and certification of biometric data. -
Identity manager 330 includes any type of computing device having at least amemory 1404 and aprocessor module 1430 that is capable of connecting to thenetwork 150.Identity manager 330 may be utilized for registration of the user ID associated withuser 5, and more specifically the user generated biometric data.Data store 335 may be controlled and/or accessible byidentity manager 330. As such,identity manager 330 may be used, in part, to implement technology to perform registration, validation, and/or certification of raw data, as will be further described below to facilitate the implementation of authenticated login, registration, call center validation, and authentication and certification of user generated data (e.g., biometrics). -
FIG. 8B illustrates adata flow 800B for using the verification of the certification of user generated data (e.g., biometrics), such as in a method for authenticating the user, to control access to products and/or services using a biometric authentication process, in accordance with one embodiment of the present disclosure. Data flow 800B may be implemented withinsystem 800A ofFIG. 8A to perform the biometric authentication process. - In particular, newly captured biometric data is associated with original biometric data, wherein the original biometric data is registered, validated, and/or certified. The newly captured biometric data and the original biometric data is used to perform biometric authentication. For purposes of illustration, an original image (e.g., facial image) of
user 5 is used for the biometric data, while it is understood that the biometric data may take on any form (e.g., audio, fingerprint, body part imaging, facial image, iris, DNA, etc.). - In one embodiment, the original biometric data (e.g., original image) is registered, validated and/or certified using a blockchain.
User 5 also has a copy of the original biometric data, as well as corresponding registration and certification information (e.g., seals), such as by storing that information ondevice 11. In another embodiment, the blockchain is not used to store the original biometric data that is registered and certified. For example, a central server could maintain the signature.hash(original image), wherein the central server could be theidentity manager 330, or the authenticating entity 810 (e.g., stored on data store 815). - As shown in
FIG. 8B , block 820 includes operations performed bydevice 11 ofuser 5. Atoperation 815, the authenticatingentity 810 sends the user 5 a unique challenge_string that the user is expected to use in the authentication correspondence. In particular, biometric data is newly captured by device 11 (e.g., camera capturing a facial image of user 5). As such,device 11 has a copy of the original biometric data (original image) that was registered and certified (with supporting information on the device 11), and the newly captured biometric data (newly captured image), both of which can be delivered to the authenticatingentity 820 for purposes of performing biometric authentication. In particular, user data is collected, to include at least one of the captured biometric data, the original biometric data, the challenge_string, the public key of theuser 5, the registration seal, the certification seal, etc. The user data is hashed, and then signed using the private key of the user. The user data and the signature of the hashed user data may be packaged in an envelope of data, for example as a request to authenticate. In one embodiment, the contents within the request package is optionally encrypted using the public key of the authenticatingentity 810. The secure envelope is delivered to the authenticatingentity 810 inoperation 825. -
Block 830 includes various operations performed by the authenticatingentity 810. In particular,entity 810 is configured for receiving fromdevice 11 of user 5 a user envelope of data. The user envelope includes user data and a signature of a hash of the user data signed by a private key of the user. The user data includes at least one of a user ID (e.g., recognizable by the authenticating entity 810), newly created biometric data, newly presented original biometric data associated with the newly created biometric data, the unique challenge_string, a registration seal associated with the original biometric data comprising a first transaction number of a first blockchain, and a certifying seal associated with the original biometric data comprising a second transaction number of a second blockchain, wherein the second blockchain may incorporate the first blockchain in one embodiment. - In addition, the signature of the user data is verified in order to confirm that the data is trustworthy. As previously described, the verification logic is well known, and includes inputting at least one of the user data (e.g., original biometric data), the public key of the
user 5, and the signature of the user data (hashed or no hash), wherein the verification logic confirms or denies the verification of the user data in the envelope. This signature of the user data also guarantees that the user data, including the new biometric data, is a fresh response to the exchange between the authenticating entity and the user and it is not an old, reused package of data being sent. This can be established since the user data includes the new biometric data along with the challenge_request among other data units and the fact that the entire user data is digitally signed byuser 5's private key. Since the challenge_request is unique in each exchange, it is not possible to reuse this user data in another exchange with a different challenge_request without first signing it. Therefore, not only doesuser 5 have to provide newly captured biometric data, it has to be able to sign it in real time in conjunction with the unique challenge_request that changes for every request. This increases the burden for a hacker as they need to both have biometric data to pass on as a new image, but also have the access to the private key of the user to sign the new request (since the old signatures won't work with the new challenge_request). - Further, the original biometric data is verified. The verification logic is well known, and includes inputting at least one of the original biometric data, the public key of the
user 5, and the registration seal (including the transaction identifier pointing to the stored data in the blockchain, for example). Also, the certification of the original biometric data is verified. In particular, the verification logic is well known, and includes inputting at least one of the certification record, the original biometric data, the public key ofuser 5, the certification seal (including the transaction identifier pointing to the stored certification data in the blockchain, for example). - In general, the verification process can be summarized in the following steps: step 1) get challenge_string, original image, and newly captured image; step 2) get signature.hash(original image) from the blockchain record; step 3) hash(original image); step 4) verifysignature(hash(original image), signature.hash(original image), public_key.signee); and step 5) verify envelope signature with hash(message data including biometric data and challenge_string), 6) if
step - In particular, once the verification of the registration and certification of the original biometric data is successfully completed, a comparison process is performed. In particular, the newly captured/created biometric data is compared against the newly presented original biometric data (e.g., a copy). The user is authenticated when the newly captured/created biometric data and the newly presented original biometric data match.
- At this point, additional processes may be performed. For example, the previously introduced (e.g., in
FIGS. 3-7 ) authentication and login processes may be completed, in conjunction with the biometric authentication process. In this case, authentication of the user biometric is another factor in the authentication and login process. Also, in another example, a process for controlling access to object 820 may be performed. For example, theobject 820 may be unlocked foruser 5 if authentication is successful. On the other hand, object 820 may remain locked foruser 5 is authentication was unsuccessful. -
FIGS. 9A-9B, and 10-12 combined describe processes involved when performing authentication and login for travelers, transportation agents, and transportation services. Use cases are disclosed for the various parties involved. In particular,FIGS. 9A-9B describe processes performed on the traveler side in a traveler use case. The traveler use case is taken from the standpoint of a Traveler who wishes to access various forms of transportation services (e.g., airline, bus, train, etc.). In general, the sequence flow for the traveler use case includes: 1) Traveler setting up his/her App; 2) Traveler taking a selfie and publishing it for use; 3) Transportation Agent screening and ultimately certifying the traveler ID & selfie, and further giving the Traveler a travel-token; 4) at a later point, the Traveler can present trip-credentials including, traveler ID, selfie, and travel-token so that the traveler information can be retrieved and verified, and so that a new picture can be taken of purposes of performing face recognition in order to confirm the user/traveler. A separate sequence is disclosed for the Transportation Agent as he/she is added to the Transportation Service system in order to be able to login while in the Transportation Service station (e.g., an airport) so that he/she can perform traveler check-in and verification. A Transportation Service is an entity such as an airline that provides transportation for persons. The concepts described below (e.g., in relation to transportation service) might well be used in other embodiments by entities that provide transportation for nonpersons (e.g., goods) or services in addition to other services other than transportation. In particular,FIGS. 10-12 are more focused on processes performed on the Traveler Agent side in a transportation service use case. In general, the sequence flow for the Transportation Service use case includes: 1) Transportation Agent newly registers with the Transportation Service portal for the first time; 2) an Admin who operates the Transportation Service portal confirms the Transportation Agent as a valid employee and grants access; 3) the Transportation Agent subsequently logs into the Transportation Service portal to perform his/her duties. This operation may only be done while on the Transportation Service station premises, in one embodiment. - As previously introduced,
FIGS. 9A-9B describe processes performed on the traveler side in a traveler use case.FIG. 9A is a diagram illustrating a process for registering and validating a user, which in this case is theTraveler 901, in accordance with one embodiment of the present disclosure. TheTraveler 901 is assumed to have downloaded aTraveler App 902 providing an interface and functionality for performing the registration, validation, authentication, login, etc. At this point, atoperation 905 theTraveler 901 scans his/her passport or a required form of government ID, and atoperation 910 takes a selfie using his/herTraveler App 902. TheTraveler App 902 then creates a signed hash of the passport information, and a separate signed hash of the selfie. Optionally, the data given to the hashing algorithm can include the data to be hashed along with a random data string, referred to as a Salt. The resulting hash is then digitally signed. This process prevents a hacker from discovering the data through brute force. In this optional process, the user must always pair and pass the data (e.g., passport information) with the corresponding Salt values in order for a verifier to validate the signatures. - At
operation 915, this information is sent to the identity-management service server to be sealed. The identity-management service server “ShoStore” 992 is accessed through anAPI 991 called “ShoApi”.ShoApi 991 is configured to also provide access to the blockchain database “BC” 980. Throughout this specification, the term “ShoStore” is also referred to as “ShoCard”) server to be sealed. Atoperation 920, the server forwards the request to theblockchain 980 to be written as a transaction. This becomes the Seal of theTraveler 901. - Next, the
Traveler 901 needs to setup her selfie so that it can be retrieved later at her request.FIG. 9B is a diagram 900B illustrating a process for registering and validating the image (e.g., selfie) of theTraveler 901, in accordance with one embodiment of the present disclosure. This is achieved via a delayed-secure-envelope transmission, in one embodiment. Normally, communication between the Traveler 901 (the user of the identification-management service—“ShoStore”) and another user or entity (such as a transportation service—“airline” 933) is performed through a secure-envelope transmission. In this process, theTraveler 901 creates the message that is to be transmitted, and envelopes it securely so it cannot be spoofed by any other third party (e.g., hacker) in any way (including the ShoStore servers 992). In a delayed-secure-envelope transmission, the message is created and enveloped securely, but stored for a delayed use when theTraveler 901 authorizes the transmission to the appropriate party of her choosing, such as theairline 933. - To establish delayed-secure-envelope transmission, at
operation 940 theTraveler App 902 generates an image-secret-key that is kept on the Traveler App only. TheTraveler App 902 also encrypts the Traveler's selfie. This information is encrypted and packaged as a message. Atoperation 945, the encrypted message is then stored with theShoStore server 992, and an imageId is returned to theTraveler App 902 that references that encrypted message. TheTraveler App 902 stores both the image-secret-key for the message and the ShoStore imageId. At this point, theTraveler App 902 is ready to use the image as a form of registered identification with thetransportation service 933. -
FIGS. 10A-10B are diagrams 1000 illustrating the authentication of theTraveler 901 at a transportation service 933 (e.g., airline), in accordance with one embodiment of the present disclosure. For example, theTraveler 901 shows up at thetransportation service 933 and is greeted by anAgent 931. TheTraveler 901 initiates sharing her ShoStoreId by creating a QRCode on herTraveler App 901 atoperation 1005<Share ShoCardID>. The ShoStoreID is provided byShoStore 992, the identity-management service, during the registration process of theTraveler 901. The ShoStoreID may also be referenced as “ShocardID” in the figures and elsewhere in the specification. In addition, the ShoStoreID may include a transaction ID referencing the location in theblockchain 980 where the user data is stored. In order to create this QR Code, theTraveler App 902 creates a secure-envelope that includes her passport identity information along with her ShoStoreId, the imageId she received when she created her stored encrypted image, and the image-secret-key used to decrypt the stored image. The envelope is secured with a temporary passcode, temp-key, that encrypts the entire message. The envelope is sent to theShoStore 992 atoperation 1010 <create ENVELOP[temperature_key]((Identity+selfie-uniqueID+one-time-key))>. TheShoStore 992 returns a QR Id that uniquely identifies this secure-envelope to theTraveler App 902 atoperation 1015 <qrID>. - The
Traveler App 902 then creates a QRCode with two pieces of information inoperation 1016<create QRCODE(qrId+temporary_key), and Display on Screen>. First is the QR ID returned from theShoStore 992, and second is the temp-key (e.g., public_key of ShoStore 992) necessary for the receiver (Traveler App) to decrypt the secure envelope. - Using the
Agent App 932, the QRCode is scanned by theAgent 931 atoperation 1017. TheApp 932 temporarily saves the temp_key in the QR code, and uses the “qrId” field to send a getData request toShoStore 992 atoperation 1020<getData(qrId>.ShoStore 992 returns the secure-envelope that theTraveler 901 had saved, and simultaneously removes that secure-envelope from ShoStore atoperation 1023 <ENVELOP[temperature key]((Identity+Selfie-uniqueID+one-time-key))>. TheAgent App 932 uses the temp_key retrieved from the QR Scan to decrypt the envelope atoperation 1024. TheAgent App 932 then makes a request to the ShoStore to retrieve the encrypted selfie-image referred to by the imageId atoperation 1025 <get(selfie-uniqueld)>. At 1027, the encrypted image is returned. Next, theAgent App 932 retrieves the Travelers' latest Seal record via ShoApi from theblockchain 980 atoperations operation 1030 sends a request toShoApi 991 for the seal <Get traveler's last seal>, whereinoperation 1033 sends the request to theblockchain 980 <get seal transaction>, whereinoperation 1035 delivers the seal data toShoApi 991 <Traveler seal data>, and whereinoperation 1037 delivers the traveler seal data back toAgent App 932 <Traveler seal data>. - Alternatively, if the
Traveler 901 does have network connectivity, it can create a QR Code on its App requesting the id information of the Agent and its public key in order to share data. In this case, theAgent 931 scans the QR Code of the user to identify its ShoCard ID so it can send it messages and notifications. It then creates a Secure Envelope and within it, it embeds its own ShoCard ID and public key. TheTraveler 901 then creates the secure-envelope described earlier, but encrypts it with the Agent's public key instead of temp_key described above. It then sends the secure_envelope to theAgent 931. - As another alternative, if the
Traveler 901 does not have network connectivity, it can exchange data with the Agent's device directly using Bluetooth, NFC, Streaming QR Codes as described in another embodiment, or other means of local transmission of data. In this scenario, theTraveler 901 would still retrieve the Agent's ShoCard ID and public key using local transmission of data and return to it the complete secure_envelope using local transmission of data. - At this point, the
Agent 931 has all the digital assets it needs to verify the user—this process is referred to as “screening” the user data, as performed inoperation 1038. In particular, the Traveler's passport data passed via the QR Scan is compared to the data on the blockchain (e.g., verifies traveler data with seal). Also, the selfie-image passed is decrypted (e.g., decrypt selfie with image-secret-key) and made viewable on the Agent's App—the agent does a visual comparison of the selfie and the Traveler. Alternatively, the Agent may snap a new image of the user and use systems to perform a biometric comparison of the image taken and the image passed by theTraveler 901. The Agent may now verify the physical documents that the Traveler presents such as physical passport, driver's license, travel itinerary or ticket and other required information (e.g., full name, address, passport number, driver's license number, etc.). This process may also be automated with a self-service kiosk or other non-human devices to validate the Traveler's data. - If all checks out and are valid, the Agent approves the screening using the
Agent App 932 atoperation 1040 <Approves screening>. This approval becomes a request for a certification message to the transportation-service server, atoperation 1041 <Request is sent to Airline for certification>. The request to certify, is created and it includes the Agent's ShoStoreId, approval-code, and all the information that was retrieved in the QR Scan from theTraveler 901. Atoperation 1043 <ENVLOP[Airline](Request to Certify Traveler Data)>, this request is placed in a secure-envelope with the Transportation-service server's public key and transmitted toShoApi 991, for routing to the Transportation-service server 933 atoperation 1045 <Route Request to airline>. - The Transportation-
service server 933, upon receiving the request atoperation 1045, retrieves the Traveler's last seal from the blockchain viaShoApi 991 atoperation 1047 <Get traveler's last seal>, whereinoperation 1050 forwards the request to theblockchain 980 <get seal transaction>, whereinoperation 1053 returns the seal toShoApi 991 <Traveler seal data>, whereinoperation 1055 returns the seal to thetransportation server 933 <Traveler seal data>. Thetransportation server 933 is configured to verify the identity of theAgent 931 using the Agent's ShoStoreId. In addition, thetransportation server 933 is configured to ensure that the Agent has an active logged-in session at the transportation service station. Thetransportation server 933 then verifies the Travelers' passport data and image-hash against the Seal record <verifies traveler data against the seal>_<verifies hash of passport data>_<verifies hash of image data>, etc. - If everything matches,
transportation server 933 sends a certification request to be written to the blockchain for theTraveler 901 atoperation 1057 <certify(shocardId[Traveler], passport data, image data, ShoCardId[Agent]>, atoperation 1060 <write certify transaction> writing certification record data to blockchain 980, atoperation 1063 <confirmation> confirmation of the blockchain transaction is returned, and atoperation 1065 <confirmation> the confirmation information (e.g., blockchain transactionID, etc.) is delivered totransportation server 933. The certification record specifically identifies the passport fields confirmed and the hashed-image-data. - Once the Certification is completed, the Transportation-service server creates the Traveler's TravelData at
operation 1066. This TravelData includes at least one of a Travel-token, Traveler's ShoStoreId (ShoCardId[Traveler]), expiration time for the Traveltoken, imageId of the Traveler (imageId[Traveler]), the ShoCardId of the transportation service (ShoCardId[Airline]), optionally the Agent (ShoCardId[Agent]), and a signature of all of these fields using its own private-key <signature(all-travel-data)>. - The Transportation-
service server 933 then places the TravelData in a secure-envelope encrypted with a new password it creates, namely travel-secret-key atoperation 1067 <create travel-secret-key>. This secure-envelope is sent to the ShoStore server as another delayed-secure-envelope atoperation 1068 <ENVELOPE[travel-secret-key](store(TravelData))>, and receives a travelerId in return inoperation 1070 <travelerId>. The travelerId along with the travel-secret-key is then passed in a secure-envelope encrypted with the Traveler's public key to the Travelers'App 902 atoperation 1073 <ENVELOP[Traveler](travelerId & travel-secret-key>. - Lastly, the
Agent 931 through theAgent App 932 is given a confirmation of the travel-token being issued by the Transportation Service Portal in another secure-envelope atoperation 1075 <ENVELOP[Agent](Travel-confirmation)>. TheTraveler App 902 saves both the travelerId and the travel-secure-key for future presentation. This TravelData is the authenticated travel-Token that is presented at future gates of entry. -
FIGS. 11A-11B are diagrams 1100 illustrating a method for checking a certification of a Traveler, such as by an Agent of a transportation service, in accordance with one embodiment of the present disclosure. For example, when theTraveler 901 has reached a gate of entry, a transportation-service Agent 931 needs to verify the user—the Traveler. A gate of entry can be entrance into a lounge, boarding on a plane, going to a travel agent desk for assistance or any other engagement where a transportation-service Agent 931 must validate the identity of theTraveler 901. TheAgent 931 may or may not be from the same transportation service that originally checked the user in (Traveler 901) and certified her credentials. The gate of entry may or may not be in the same transportation-service station or even country that theTraveler 901 originated in. It is also assumed that theTraveler 901 may not have internet or Wi-Fi connectivity in some embodiments. Additionally, the transportation-service Agent does not necessarily have to be a real person and can be substituted with a self-service kiosk equipped with a camera or other similar systems. - The
Traveler 901 is greeted by theAgent 931 and presents her identification and trip information by locally creating a QR Code atoperation 1105 <locally create qrcode(travelId+travel-secret-key+image-secret-key) and display on screen>. The QR Code includes the travel-uniqueld, travelPassKey and the image-secret-key used to encrypt the selfie mentioned earlier. The Agents App scans the QR Code atoperation 1110 <scan qrcode>. TheAgent App 932 then requests the encrypted-TravelData from theShoStore server 992 atoperation 1113 <get(travelId)>, and once the data is received atoperation 1115, theAgent App 932 decrypts it using the travelPassKey. TheAgent App 932 then requests the encrypted-image pointed to by the imageId atoperation 1117 <get(ImageId)>, returned inoperation 1120 <encryption(image)>, and theAgent App 932 decrypts it with the image-secret-key. - Alternatively, if the Traveler App is equipped with other local transmission technology such as Bluetooth, NFC, streaming QR Codes (as described in a separate embodiment) or other similar forms of local transmission, it does not need to save and use the encrypted data that is stored on the ShoStore server as described above. In this scenario, the Traveler App would create a QR Code that requests the id of the Agent and its public key. The Agent App would scan the QR Code and respond back using local transmission technology with the requested information and it would also send an optional sessionID string to the Traveler. The Traveler would then create a secure_envelope that would include the travel token, Traveler's identification information (e.g., passport data), originally certified selfie-image and pointer to its seal and certification records on the blockchain and the optional sessionID. This secure_envelope would be digitally signed by the Traveler's private key and encrypted with the public key of the Agent. The secure_envelope is then transmitted to the Agent using local transmission technology. The Agent App decrypts the secure_envelope using its private key and begins the validation process of the Travelers' data.
- The Agent App then retrieves the Seal transaction and related Certification records of the Traveler via ShoApi from the blockchain. In that manner, identity of the Transportation service that certified the
Traveler 901 can be confirmed. In particular, theAgent App 932 retrieves the Transportation service's own Seal transaction from the blockchain via theShoApi 991. The assumption is that the transportation service was previously certified by this Agents' transportation service as well and within the App, it can confirm that, which makes the originating transportation service a trusted and certified transportation service atoperation 1135 <identify airline that certified theTraveler 901 from the data returned with the seal>. For example, the following operations are performed:operation 1123 <get Airline public_key>;operation 1125 <get Traveler Seal transaction> a request toShoApi 991 is made for the seal; operation 1127 a request is made for the seal to theblockchain 980 <get Traveler Seal transaction>; atoperation 1130 the seal is returned toShoApi 991 <Traveler Seal transaction>; at operation 1333 the seal is delivered toAgent App 932 <Traveler Seal transaction>; atoperation 1137 the transportation service seal is requested <get Airline Seal transaction>; atoperation 1140 the request is delivered to the blockchain <get Airline Seal transaction>; atoperation 1143 the seal is delivered toShoApi 991 <Airline Seal transaction>; atoperation 1144 the seal is delivered toAgent App 932 <Airline Seal transaction>. - At this point, the
Agent App 932 verifies that the travelData was authentically signed by the transportation service atoperation 1145 <agent screens user data, verified tripData with signature, and decrypts selfie with one-time key>. TheAgent App 932 confirms the travel-token and expiration date, and confirms that the Traveler image-data was certified by the transportation service as well. - The
Agent App 932 then takes a picture of the Traveler using its own camera atoperation 1150 <activate camera>;operation 1153 <traveler looks at camera>; andoperation 1155 <take picture>. TheAgent App 932 performs facial recognition comparing the newly taken picture and the certified image it had retrieved atoperation 1157 <face recognition>. If all matches, theTraveler 901 is verified and a green signal is given for the Traveler to proceed atoperation 1160 <Red/Green>, or red if theTraveler 901 is not verified. -
FIGS. 12A-12B are diagrams 1200 illustrating a method for registering anAgent 931 of a transportation service and logging in the Agent, in accordance with one embodiment of the present disclosure. In this use case, the transportation-service Agent 931 has two functions. The Agent checks-in anew Traveler 901 and provides her with a travel-Token. The same or a different Agent later checks the identity of thatTraveler 901 and the travel-Token, which is issued to grant permission to proceed through various gates of entry. For purposes of illustration, the Agent is referred to withreference number 931, and in this diagram can be the same agent or two different agents in diagram 1200. In order to perform these functions, theAgent 931 must download theAgent App 932, have it registered with the transportation service and have a logged in session. - In particular, the
Agent 931 first downloads theAgent App 932 atoperation 1210 <downloads App>. To setup theApp 932, theAgent 931 scans her Driver's License atoperation 1213 <Scan Driver's License>. Then theAgent App 932 creates a ShoStoreId for that Agent along with a new set of private/public keys for the Agent atoperation 1215 <Create ShoCardId & private keys>. TheAgent App 932 hashes each field of the Agent's identification and digitally signs it using its private-key. TheAgent App 932 then sends a request to theShoApi 991 to Seal the record atoperation 1217 <Seal(hash(license))>.ShoApi 991 forwards the request to perform a seal transaction to theblockchain 980 atoperation 1220 <seal transaction>. - At this point, the Agent is able to register with the Transportation Service Portal. To do so, on the Transportation Service Portal's registration page, the
Agent App 932 is used to scan the registration-QR code atoperation 1230 <Scan registration QR>, where the portal 1201 creates a new Agent identity atoperation 1240 <new Agent identity created>. TheTransportation Service Portal 1201 requests the Seal transaction of the Agent from the blockchain through ShoApi and validates the information against the employee record database it has in order to ensure this is a valid Agent of the transportation service. If all is valid a record of this new Agent is created for the transportation service Admin to authorize. - Since this is a
new Agent 931 being added to the system, a Transportation-service Admin 1202 must authorize the Agent registration through the portal atoperation 1243 <authorizes Agent registration>. This process is done through a different interface on the portal visible only to theAdmin 1202. Once theAgent 931 is authorized, a Certify request of the Agent's ShoStoreId is sent to the blockchain via the ShoApi at the following operations:operation 1245 <Certify(shocardId[Agent])>;operation 1247 <write certify transaction>;operation 1250 <confirmation> confirmation certification returned toShoApi 991;operation 1253 <confirmation> confirmation certification returned toairline portal 1201. - The registration process is a one-time event per employee. Now the
Agent 932 is able to login to theTransportation Service Portal 1201. To do so, theAgent 932 scans a new QR on the login page atoperation 1255 <Scans new QR code to login>. TheAgent App 932 is given a session ID atoperation 1257 <give sessionId>. TheAgent App 932 uses the sessionId to send a secure Envelope to the Transportation Service Portal in order to login to the portal atoperation 1270 <ENVELOPE[Airline](login request)>. The Transportation Service Portal validates that login request against the Agent's sealed and certified records on the blockchain and ultimately logs the Agent in if everything is validated atoperation 1280 <verify Agent ShoCardId; verify Agent was certified by Airline; if validated then user logged in>. TheAgent 931 is now able to perform Traveler operations until the Transportation Service Portal session expires or the Agent logs out. - In one embodiment, the
Transportation Service Portal 1201 has a set of administrative capabilities and reporting. These functions may not be available to the Agents, but only to the administrators of the system (the Admin). When logged in as the Admin, theTransportation Service Portal 1201 may provide the following capabilities: view a list of Agents (logged in or not); create a list of actively logged in Agents; ability to disable an Agent; ability to remove an Agent; ability to approve newly registered Agents; Agent can logout via Agent App. In addition, theTransportation Service Portal 1201 may be configured to provide real-time and historical reports on: agent registrations; agent logins and login session timers; and Travelers' Identity screening and certifications. In one embodiment, theTransportation Service Portal 1201 might be a Ruby on Rails web application. Further, each transportation service has its own instance of theTransportation Service Portal 1201 in one embodiment. In another embodiment, theTransportation Service Portal 1201 might be deployed in the cloud (Heroku/Amazon) and operated by the identity-management service (“ShoStore” also called “ShoCard”) Traveler's App. In one embodiment, the Traveler App might be an iOS based App designed to run oniPhone 5 or higher model. In another embodiment, each traveler is to be equipped with a new instance of the Traveler App. Further, the Agent App might be an iOS based App, wherein each Agent is to be equipped with a new instance of the Agent App. -
FIG. 13 is a diagram 1300 illustrating a method for performing third party certification of custom name/value pairs, in accordance with one embodiment of the present disclosure. A third party (herein Certifier) 1310 can provide a certification for aShoCard User 1301 and provide specific “name=value” for that certification. TheShoCard user 1301 must first be known to theCertifier 1310 where at a minimum, the ShoCardId of the user has been exchanged. TheCertifier 1310 may or may not have certified the ShoCardId previously. - The
Certifier 1310 may then write a record to theblockchain 980 using its private-key encapsulating at least one of the following set of data (additional field types may be included as well): ShoCardId being certified; an optional transactionId that would point to a Sealed entry on the blockchain for that user; and a list of Names/Values. - The data for the transaction being written to the blockchain may or may not fit in a single transaction. If it does not fit, a hash of the entire data is made and the hash is written to the
blockchain 980. The data is then stored on a different device that may or may not be shared. To access the certification record on the blockchain, the data associated with that hash may have to be accessed and verified that it matches the same hash. This process is an indirection that may or may not be necessary to the overall operation depending on the size of the data fields supported by the givenblockchain 980. - There are two keys to the certification process. First, the record being written to the blockchain must be signed with the private-key of the
Certifier 1310. This ensures that no one else is committing this transaction. If the transaction is written to something other than a blockchain, the data must be digitally signed and the digital signature must be submitted along with the data to be written, in one embodiment. - The second key item is the composition of the Name/Value fields. The Name field can be a text string describing the field type, in one embodiment. The Value however is a digital signature of the hash of the data associated with that field name. For example, if the name field is “Ranking” and the data associated with the field Ranking is the string “superior”, the following transformation would take place: 1) The string “superior” would be hashed and a data stream would be produced from that hash: <hashValue>, wherein there are many algorithms that can be used for the hash such as, but not limited to SHA256; and 2) the Certifier then uses its private-key to digitally sign the <hashValue>, wherein the result is: <signedHashValue>.
- The Value field would then be <signedHashValue>. The Name/Value fields can be passed in any number of methods, such as a JavaScript Object Notation (JSON) data structure, name=value strings with a separator, or any other structural form that passes the data.
- The
Certifier 1310 must pass the data to the blockchain, but also needs to pass a copy of the certification record being written along with original data to theShoCard User 1301. TheShoCard user 1301 then has the opportunity to acknowledge the receipt and acceptance of the certification by also writing a copy of the certification record on the blockchain using its own private-key. In this case, the ShoCardId of theCertifier 1310 must also be written. Additionally, it must keep a copy of the clear-text name/value fields that is passed to it by theCertifier 1310 so it can refer to the data. This clear text data is maintained in the users' local device (e.g., his/her phone). - At this point, the
ShoCard User 1301 can share the certification information with another party (herein referred to as Verifier 1315). To do so, theShoCard User 1301 can pass the specific name/value fields in clear text that it intends to share and a reference to its own ShoCardId on theblockchain 980. It may also pass to theVerifier 1315 the address of the certification record it wrote on theblockchain 980. TheVerifier 1315 can retrieve all transactions associated with the ShoCardId from theblockchain 980 and look for a match to the Certifiers' record. It then reads the fields in the certification record which includes the Certifier's own ShoCardId on theblockchain 980. This leads to the public key of the Certifier.Verifier 1315 then uses the Certifier's public key, the Value field for the specific Name fields given to it by theShoCard User 1301 and the <signedHashValue> for that same exact field in the certification record to verify that the field was signed by theCertifier 1310. If it is signed by theCertifier 1310, theVerifier 1315 can be assured that the Value given to it is authentic so long as theVerifier 1315 trusts who the Certifier is. At a minimum, it can tell that theCertifier 1310 was indeed the person or entity that signed this certification for the Value. - A certification may also include an expiration time in addition to the fields stated above. The expiration time is basically a timestamp that indicates when this certification becomes invalid. If the
Certifier 1310 then wishes, it can create a new Certification with a new expiration. Removing the expiration means the certification does not expire and would have to be explicitly cancelled. - If the
Certifier 1310 wants to cancel the certification, it may write a new record that points to the prior certification record and identify it as a cancel-certification. It would also notify theShoCard User 1301 so that it too can be aware of the cancellation. It may also update an older certification in a similar way where it would point to the older certification record and the data passed to the user. The linking of the cancel-certification record or an update are done in clear text so that any user can tell if the state of the certification has been modified (i.e., updated or cancelled) by searching other records that may point back to it. -
FIG. 14 illustrates components of an example device that can be used to perform aspects of the various embodiments of the present disclosure. For example,FIG. 14 illustrates an exemplary hardware system suitable for implementing a device in accordance with one embodiment. This block diagram illustrates acomputer system 1400, such as a personal computer, video game console, personal digital assistant, or other digital device, suitable for practicing an embodiment of the invention.Computer system 1400 includes a central processing unit (CPU) 1402 for running software applications and optionally an operating system. CPU 1402 may be comprised of one or more homogeneous or heterogeneous processing cores. - In accordance with various embodiments, CPU 1402 is one or more general-purpose microprocessors having one or more processing cores. Further embodiments can be implemented using one or more CPUs with microprocessor architectures specifically adapted for highly parallel and computationally intensive applications. For example,
CPU 1430 may be configured to include abiometric capture engine 1441 configured for capturing biometric data, averification engine 1442 for performing verification logic (e.g., verifying data that is signed, registered, and/or certified), ascanning engine 1443 configured for scanning codes (e.g., QR code, scan code, PDF417 code, etc.), an encryption/decryption engine 1444 configured for encrypting and decrypting data using a public/private key pair, ahashing engine 1445 configured for hashing data using any one of a number of well known hashing algorithms, asigning engine 1446 configured for creating a digital signature using a private key, ahandle generator 1447 configured for generating a session ID or envelope ID, ascan code generator 1448 for generating a scannable code (e.g., QR code, scan code, PDF417 code, etc.), an a comparator ormatching engine 1449 configured for comparing newly captured biometric data and original biometric data. -
Memory 1404 stores applications and data for use by the CPU 1402.Storage 1406 provides non-volatile storage and other computer readable media for applications and data and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROM, DVD-ROM, Blu-ray, HD-DVD, or other optical storage devices, as well as signal transmission and storage media.User input devices 1408 communicate user inputs from one or more users to thecomputer system 1400, examples of which may include keyboards, mice, joysticks, touch pads, touch screens, still or video cameras, and/or microphones.Network interface 1410 allowscomputer system 1400 to communicate with other computer systems via an electronic communications network, and may include wired or wireless communication over local area networks and wide area networks such as the Internet. Anaudio processor 1412 is adapted to generate analog or digital audio output from instructions and/or data provided by the CPU 1402,memory 1404, and/orstorage 1406. The components ofcomputer system 1400, including CPU 1402,memory 1404,data storage 1406,user input devices 1408,network interface 1410, andaudio processor 1412 are connected via one ormore data buses 1422 - A
graphics subsystem 1414 is further connected withdata bus 1422 and the components of thecomputer system 1400. The graphics subsystem 1414 includes a graphics processing unit (GPU) 1416 andgraphics memory 1418.Graphics memory 1418 includes a display memory (e.g., a frame buffer) used for storing pixel data for each pixel of an output image.Graphics memory 1418 can be integrated in the same device asGPU 1416, connected as a separate device withGPU 1416, and/or implemented withinmemory 1404. Pixel data can be provided tographics memory 1418 directly from the CPU 1402. Alternatively, CPU 1402 provides theGPU 1416 with data and/or instructions defining the desired output images, from which theGPU 1416 generates the pixel data of one or more output images. The data and/or instructions defining the desired output images can be stored inmemory 1404 and/orgraphics memory 1418. In an embodiment, theGPU 1416 includes 3D rendering capabilities for generating pixel data for output images from instructions and data defining the geometry, lighting, shading, texturing, motion, and/or camera parameters for a scene. TheGPU 1416 can further include one or more programmable execution units capable of executing shader programs. - The graphics subsystem 1414 periodically outputs pixel data for an image from
graphics memory 1418 to be displayed ondisplay device 1422.Display device 1422 can be any device capable of displaying visual information in response to a signal from thecomputer system 1400, including CRT, LCD, plasma, and OLED displays.Computer system 1400 can provide thedisplay device 1422 with an analog or digital signal. - Accordingly, embodiments of the present disclosure disclosing authenticated login, registration, call center validation, and biometric authentication of a user have been described. While specific embodiments have been provided to demonstrate the use of registration, validation, and certification of data, these are described by way of example and not by way of limitation. Those skilled in the art having read the present disclosure will realize additional embodiments falling within the spirit and scope of the present disclosure.
- The various embodiments defined herein may define individual implementations or can define implementations that rely on combinations of one or more of the defined embodiments. Further, embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.
- Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations
- With the above embodiments in mind, it should be understood that the disclosure can employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Any of the operations described herein that form part of the disclosure are useful machine operations. The disclosure also relates to a device or an apparatus for performing these operations. The apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
- One or more embodiments can also be fabricated as computer readable code on a non-transitory computer readable storage medium. The non-transitory computer readable storage medium is any non-transitory data storage device that can store data, which can be thereafter be read by a computer system. Examples of the non-transitory computer readable storage medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices. The non-transitory computer readable storage medium can include computer readable storage medium distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
- Although the method operations were described in a specific order, it should be understood that other housekeeping operations may be performed in between operations, or operations may be adjusted so that they occur at slightly different times, or may be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing, as long as the processing of the overlay operations are performed in the desired way.
- Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications can be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the embodiments are not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
Claims (28)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/449,902 US10587609B2 (en) | 2016-03-04 | 2017-03-03 | Method and system for authenticated login using static or dynamic codes |
US16/227,632 US11134075B2 (en) | 2016-03-04 | 2018-12-20 | Method and system for authenticated login using static or dynamic codes |
US17/480,673 US11658961B2 (en) | 2016-03-04 | 2021-09-21 | Method and system for authenticated login using static or dynamic codes |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662304144P | 2016-03-04 | 2016-03-04 | |
US201662304934P | 2016-03-07 | 2016-03-07 | |
US201762455199P | 2017-02-06 | 2017-02-06 | |
US15/449,902 US10587609B2 (en) | 2016-03-04 | 2017-03-03 | Method and system for authenticated login using static or dynamic codes |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/227,632 Continuation US11134075B2 (en) | 2016-03-04 | 2018-12-20 | Method and system for authenticated login using static or dynamic codes |
Publications (2)
Publication Number | Publication Date |
---|---|
US20170257358A1 true US20170257358A1 (en) | 2017-09-07 |
US10587609B2 US10587609B2 (en) | 2020-03-10 |
Family
ID=59722898
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/449,902 Active 2037-10-20 US10587609B2 (en) | 2016-03-04 | 2017-03-03 | Method and system for authenticated login using static or dynamic codes |
US16/227,632 Active 2037-03-29 US11134075B2 (en) | 2016-03-04 | 2018-12-20 | Method and system for authenticated login using static or dynamic codes |
US17/480,673 Active US11658961B2 (en) | 2016-03-04 | 2021-09-21 | Method and system for authenticated login using static or dynamic codes |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/227,632 Active 2037-03-29 US11134075B2 (en) | 2016-03-04 | 2018-12-20 | Method and system for authenticated login using static or dynamic codes |
US17/480,673 Active US11658961B2 (en) | 2016-03-04 | 2021-09-21 | Method and system for authenticated login using static or dynamic codes |
Country Status (3)
Country | Link |
---|---|
US (3) | US10587609B2 (en) |
EP (2) | EP3424179B1 (en) |
WO (1) | WO2017152150A1 (en) |
Cited By (190)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9882918B1 (en) * | 2017-05-15 | 2018-01-30 | Forcepoint, LLC | User behavior profile in a blockchain |
US9994339B2 (en) | 2013-10-07 | 2018-06-12 | Shay C. Colson | 3-D printed packaging |
CN108234457A (en) * | 2017-12-18 | 2018-06-29 | 苏州涞泽信息科技有限公司 | A kind of credible government data based on block chain shares network system and sharing method |
US20180212958A1 (en) * | 2017-01-26 | 2018-07-26 | Teltech Systems, Inc. | Two Factor Authentication Using SMS |
US20180241728A1 (en) * | 2017-02-22 | 2018-08-23 | International Business Machines Corporation | Secure data storage system |
US20180253539A1 (en) * | 2017-03-05 | 2018-09-06 | Ronald H. Minter | Robust system and method of authenticating a client in non-face-to-face online interactions based on a combination of live biometrics, biographical data, blockchain transactions and signed digital certificates. |
US20180288033A1 (en) * | 2017-03-31 | 2018-10-04 | Mastercard International Incorporated | Systems and methods for providing digital identity records to verify identities of users |
CN108712257A (en) * | 2018-04-03 | 2018-10-26 | 阿里巴巴集团控股有限公司 | The authentication method and device, electronic equipment of transregional piece of chain |
US10129269B1 (en) | 2017-05-15 | 2018-11-13 | Forcepoint, LLC | Managing blockchain access to user profile information |
US20180341775A1 (en) * | 2017-05-23 | 2018-11-29 | International Business Machines Corporation | Digital license authentication with secure privacy logging |
CN108959523A (en) * | 2018-06-28 | 2018-12-07 | 北京首汽智行科技有限公司 | A kind of method for playing music and player based on block chain technology |
CN109067521A (en) * | 2018-07-27 | 2018-12-21 | 天津大学 | A kind of public key distribution method based on block chain |
US10182051B1 (en) * | 2016-03-28 | 2019-01-15 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
CN109272310A (en) * | 2018-09-27 | 2019-01-25 | 北京金山安全软件有限公司 | Two-dimensional code generation method and device and electronic equipment |
TWI650991B (en) * | 2018-04-12 | 2019-02-11 | 中華電信股份有限公司 | Non-centralized data certificate and verification system with nfc secure element and method thereof |
US20190068367A1 (en) * | 2017-08-28 | 2019-02-28 | International Business Machines Corporation | Identity verification using biometric data and non-invertible functions via a blockchain |
CN109413102A (en) * | 2018-12-10 | 2019-03-01 | 北京八分量信息科技有限公司 | Accreditation System, method and block chain deposit system based on zero-knowledge proof |
DE102017217342A1 (en) * | 2017-09-28 | 2019-03-28 | Rudolf Bayer | A method for generating a digital identity, digital identity, method for creating an electronic transaction document, and electronic transaction document |
CN109617692A (en) * | 2018-12-13 | 2019-04-12 | 郑州师范学院 | A kind of anonymous login method and system based on block chain |
US10262153B2 (en) | 2017-07-26 | 2019-04-16 | Forcepoint, LLC | Privacy protection during insider threat monitoring |
US20190116051A1 (en) * | 2017-10-13 | 2019-04-18 | Intensity Analytics Corporation | System and method for effort-based user authentication |
US10268817B1 (en) * | 2018-10-05 | 2019-04-23 | Capital One Services, Llc | Methods, mediums, and systems for establishing and using security questions |
US10277398B2 (en) * | 2016-06-17 | 2019-04-30 | Capital One Services, Llc | Blockchain systems and methods for user authentication |
WO2019089654A1 (en) * | 2017-10-30 | 2019-05-09 | Pricewaterhousecoopers Llp | Implementation of continuous real-time validation of distributed data storage systems |
WO2019089013A1 (en) * | 2017-10-31 | 2019-05-09 | Visa International Service Corporation | Cryptographic key generation system and method |
WO2019101225A2 (en) | 2019-02-28 | 2019-05-31 | Alibaba Group Holding Limited | System and method for blockchain-based data management |
US20190190698A1 (en) * | 2017-12-14 | 2019-06-20 | Paypal, Inc. | Blockchain validation system |
CN109951448A (en) * | 2019-01-31 | 2019-06-28 | 中国互联网络信息中心 | Domain name authentic authentication method and device based on block chain |
WO2019133682A1 (en) * | 2017-12-29 | 2019-07-04 | Nanthealth, Inc. | User interface log validation via blockchain system and methods |
CN109981675A (en) * | 2019-04-04 | 2019-07-05 | 西安电子科技大学 | A kind of identity information guard method of digital identification authentication and encryption attribute |
US20190268158A1 (en) * | 2018-02-23 | 2019-08-29 | General Dynamics Information Technology, Inc. | Systems and methods for providing mobile identification of individuals |
CN110211263A (en) * | 2019-05-23 | 2019-09-06 | 烽火通信科技股份有限公司 | A kind of intelligent door method for unlocking and system based on block chain technology |
US20190278798A1 (en) * | 2018-03-06 | 2019-09-12 | Hidenobu Kishi | Terminal device, method, and information processing system |
US10425230B1 (en) * | 2019-03-01 | 2019-09-24 | Capital One Services, Llc | Identity and electronic signature verification in blockchain |
WO2019190872A1 (en) | 2018-03-28 | 2019-10-03 | Konstantinos Bakalis | Systems and methods for using codes and images within a blockchain |
US10447718B2 (en) | 2017-05-15 | 2019-10-15 | Forcepoint Llc | User profile definition and management |
WO2019199460A1 (en) * | 2018-04-13 | 2019-10-17 | Regwez, Inc. | Single-device multi-factor authentication system |
CN110400136A (en) * | 2018-04-27 | 2019-11-01 | 腾讯科技(深圳)有限公司 | Account management method, device, server and storage medium based on block chain |
US10474834B1 (en) | 2019-06-04 | 2019-11-12 | Capital One Services, Llc | Data sharing via distributed ledgers |
CN110445612A (en) * | 2018-05-02 | 2019-11-12 | 万事达卡国际公司 | For the method and system via the enhancing logging on authentication safety of block chain |
WO2019214068A1 (en) * | 2018-05-09 | 2019-11-14 | 深圳壹账通智能科技有限公司 | Method and apparatus for verifying users on blockchain system, terminal device, and storage medium |
US10489578B1 (en) * | 2018-07-25 | 2019-11-26 | Capital One Services, Llc | Authentication using emoji-based passwords |
US10505737B1 (en) * | 2018-06-04 | 2019-12-10 | Syniverse Technologies, Llc | System and method for blockchain-based consent and campaign management |
WO2019241605A1 (en) * | 2018-06-13 | 2019-12-19 | Konstantinos Bakalis | Systems and methods for secure access to property or information using blockchain |
US10515111B2 (en) | 2016-01-19 | 2019-12-24 | Regwez, Inc. | Object stamping user interface |
US10530577B1 (en) * | 2019-02-08 | 2020-01-07 | Talenting, Inc. | Systems and methods for biometric key generation in data access control, data verification, and path selection in block chain-linked workforce data management |
US10554406B1 (en) | 2019-06-04 | 2020-02-04 | Capital One Services, Llc | Authorized data sharing using smart contracts |
CN110771120A (en) * | 2019-02-28 | 2020-02-07 | 阿里巴巴集团控股有限公司 | System and method for blockchain based authentication |
US10567174B2 (en) * | 2018-05-10 | 2020-02-18 | Alibaba Group Holding Limited | Blockchain data processing methods, apparatuses, processing devices, and systems |
WO2020036657A1 (en) | 2018-04-26 | 2020-02-20 | The Assay Depot, Inc. | Decentralized data verification |
US20200059353A1 (en) * | 2018-08-20 | 2020-02-20 | Fujitsu Limited | Data fetching in data exchange networks |
US10587609B2 (en) * | 2016-03-04 | 2020-03-10 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US10623431B2 (en) | 2017-05-15 | 2020-04-14 | Forcepoint Llc | Discerning psychological state from correlated user behavior and contextual information |
US20200117791A1 (en) * | 2018-10-16 | 2020-04-16 | International Business Machines Corporation | Consented authentication |
WO2020076261A1 (en) * | 2018-06-07 | 2020-04-16 | Elektronik Bilgi Guvenligi Anonim Sirketi | A personal identification method comprising e-signature and blockchain layers |
US20200153814A1 (en) * | 2018-11-08 | 2020-05-14 | International Business Machines Corporation | Method for authentication with identity providers |
US20200151713A1 (en) * | 2017-05-26 | 2020-05-14 | nChain Holdings Limited | Script-based blockchain interaction |
US10664877B1 (en) * | 2019-04-08 | 2020-05-26 | Alibaba Group Holding Limited | Product promotion using smart contracts in blockchain networks |
US10676219B2 (en) | 2016-10-01 | 2020-06-09 | Shay C. Colson | Printing packaging in expanded material |
US10685099B2 (en) * | 2019-07-02 | 2020-06-16 | Alibaba Group Holding Limited | System and method for mapping decentralized identifiers to real-world entities |
CN111294323A (en) * | 2018-12-10 | 2020-06-16 | 成都高新信息技术研究院 | Decentralized mobile subscriber identification method and system |
US10700851B2 (en) | 2019-07-02 | 2020-06-30 | Alibaba Group Holding Limited | System and method for implementing a resolver service for decentralized identifiers |
US20200213125A1 (en) * | 2017-07-24 | 2020-07-02 | nChain Holdings Limited | Computer-implemented system and method enabling secure storage of a large blockchain over a plurality of storage nodes |
US20200211305A1 (en) * | 2019-01-02 | 2020-07-02 | International Business Machines Corporation | Authorized access evaluation and remediation system |
US10728042B2 (en) | 2019-07-02 | 2020-07-28 | Alibaba Group Holding Limited | System and method for blockchain-based cross-entity authentication |
US10756885B2 (en) | 2019-07-02 | 2020-08-25 | Alibaba Group Holding Limited | System and method for blockchain-based cross entity authentication |
US20200280558A1 (en) * | 2019-03-01 | 2020-09-03 | Carrier Corporation | Unlocking method and system for air conditioner unit |
US10771239B2 (en) * | 2018-04-18 | 2020-09-08 | International Business Machines Corporation | Biometric threat intelligence processing for blockchains |
US20200296091A1 (en) * | 2018-08-28 | 2020-09-17 | Ofer A. LIDSKY | Systems and methods for user authentication based on a genetic sequence |
WO2020192948A1 (en) * | 2019-03-28 | 2020-10-01 | NEC Laboratories Europe GmbH | Method and distributed ledger system for supporting identity management of travelers in an airport |
CN111771194A (en) * | 2017-12-18 | 2020-10-13 | 北方信托公司 | System and method for generating and maintaining immutable digital conference records within distributed network nodes |
US10805294B1 (en) * | 2019-03-22 | 2020-10-13 | Trace, LLC | Systems and methods for validating device permissions of computing devices to execute code on a decentralized database |
US20200327556A1 (en) * | 2019-04-12 | 2020-10-15 | Salesforce.Com, Inc. | Method to accept certifications with blockchain transactions |
US10819516B2 (en) * | 2017-10-19 | 2020-10-27 | Autnhive Corporation | System and method for generating and depositing keys for multi-point authentication |
US10853496B2 (en) | 2019-04-26 | 2020-12-01 | Forcepoint, LLC | Adaptive trust profile behavioral fingerprint |
US10862927B2 (en) | 2017-05-15 | 2020-12-08 | Forcepoint, LLC | Dividing events into sessions during adaptive trust profile operations |
US10903997B2 (en) | 2017-10-19 | 2021-01-26 | Autnhive Corporation | Generating keys using controlled corruption in computer networks |
US10915643B2 (en) | 2017-05-15 | 2021-02-09 | Forcepoint, LLC | Adaptive trust profile endpoint architecture |
US10917423B2 (en) | 2017-05-15 | 2021-02-09 | Forcepoint, LLC | Intelligently differentiating between different types of states and attributes when using an adaptive trust profile |
US10938569B2 (en) | 2019-07-02 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for verifying verifiable claims |
US10938562B2 (en) | 2019-07-02 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for creating decentralized identifiers |
WO2021040833A1 (en) | 2019-08-30 | 2021-03-04 | Liveramp, Inc. | Connecting web publisher inventory to programmatic exchanges without third-party cookies |
WO2021042086A1 (en) * | 2019-08-30 | 2021-03-04 | Biocube Matrics Pte Limited | A method and a system to locally store and authenticate a data of a user |
US10944565B2 (en) | 2018-10-16 | 2021-03-09 | International Business Machines Corporation | Consented authentication |
US10943087B2 (en) | 2019-06-03 | 2021-03-09 | Advanced New Technologies Co., Ltd | Method and apparatus for processing and generating offline graphic code |
US10958438B2 (en) * | 2018-10-31 | 2021-03-23 | Advanced New Technologies Co., Ltd. | Method, apparatus, and electronic device for blockchain-based recordkeeping |
US20210089673A1 (en) * | 2018-04-02 | 2021-03-25 | Sony Corporation | Information processing apparatus, information processing method, and program |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US10981680B2 (en) | 2013-10-07 | 2021-04-20 | Shay C. Colson | 3-D printed package customization |
US10999296B2 (en) | 2017-05-15 | 2021-05-04 | Forcepoint, LLC | Generating adaptive trust profiles using information derived from similarly situated organizations |
US10999297B2 (en) | 2017-05-15 | 2021-05-04 | Forcepoint, LLC | Using expected behavior of an entity when prepopulating an adaptive trust profile |
US11012233B1 (en) * | 2020-01-22 | 2021-05-18 | Coinplug, Inc. | Method for providing authentication service by using decentralized identity and server using the same |
CN112822172A (en) * | 2020-12-31 | 2021-05-18 | 咪咕文化科技有限公司 | Login verification method and device, electronic equipment and storage medium |
US11018870B2 (en) * | 2017-08-10 | 2021-05-25 | Visa International Service Association | Biometric verification process using certification token |
US11019050B2 (en) * | 2017-06-19 | 2021-05-25 | Advanced New Technologies Co., Ltd. | Authentication method and device, and blockchain-based authentication data processing method and device |
US11025430B2 (en) * | 2018-12-20 | 2021-06-01 | International Business Machines Corporation | File provenance database system |
US11044085B2 (en) * | 2017-05-24 | 2021-06-22 | Canon Kabushiki Kaisha | Method employed in user authentication system and information processing apparatus included in user authentication system |
US20210192012A1 (en) * | 2018-09-07 | 2021-06-24 | Nippon Telegraph And Telephone Corporation | Right holder terminal, user terminal, right holder program, user program, content utilization system, and content utilization method |
US11050550B2 (en) * | 2018-11-27 | 2021-06-29 | Advanced New Technologies Co., Ltd. | Methods and systems for reading data based on plurality of blockchain networks |
US11057220B2 (en) | 2019-04-18 | 2021-07-06 | Advanced New Technologies Co., Ltd. | Signature verification for a blockchain ledger |
US11062106B2 (en) | 2016-03-07 | 2021-07-13 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US11080240B2 (en) * | 2019-09-12 | 2021-08-03 | Vijay Madisetti | Method and system for real-time collaboration and annotation-based action creation and management |
US11080380B2 (en) * | 2016-11-08 | 2021-08-03 | Aware, Inc. | Decentralized biometric identity authentication |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US20210241270A1 (en) * | 2017-12-28 | 2021-08-05 | Acronis International Gmbh | System and method of blockchain transaction verification |
US11100503B2 (en) | 2018-02-07 | 2021-08-24 | Mastercard International Incorporated | Systems and methods for use in managing digital identities |
JP2021523610A (en) * | 2018-05-14 | 2021-09-02 | エヌチェーン ホールディングス リミテッドNchain Holdings Limited | Improved systems and methods for storing, generating and validating tokens used to control access to resources |
WO2021175410A1 (en) * | 2020-03-02 | 2021-09-10 | NEC Laboratories Europe GmbH | Method for supporting sharing of travel history of travelers in airports |
WO2021175409A1 (en) * | 2020-03-02 | 2021-09-10 | NEC Laboratories Europe GmbH | Method for supporting sharing of travel history of travelers in airports |
US11122036B2 (en) | 2017-09-18 | 2021-09-14 | Mastercard International Incorporated | Systems and methods for managing digital identities associated with mobile devices |
US11128456B2 (en) * | 2018-09-19 | 2021-09-21 | Cisco Technology, Inc. | Assured transport of data over a network |
US20210294920A1 (en) * | 2018-07-10 | 2021-09-23 | Netmaster Solutions Ltd | A method and system for managing digital evidence using a blockchain |
US11139960B2 (en) * | 2018-12-20 | 2021-10-05 | International Business Machines Corporation | File redaction database system |
US11146386B2 (en) * | 2020-01-17 | 2021-10-12 | Agile Blockchain Corp. | Method and system for authentication seal deployment in networked immutable transactions |
US11151236B2 (en) * | 2018-12-20 | 2021-10-19 | International Business Machines Corporation | File verification database system |
US11159537B2 (en) * | 2017-11-30 | 2021-10-26 | Bank Of America Corporation | Multicomputer processing for data authentication and event execution using a blockchain approach |
CN113609463A (en) * | 2021-10-08 | 2021-11-05 | 湖南宸瀚信息科技有限责任公司 | Internet of things system based on block chain identity management |
US11170130B1 (en) | 2021-04-08 | 2021-11-09 | Aster Key, LLC | Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification |
WO2021226854A1 (en) * | 2020-05-09 | 2021-11-18 | 杭州安存网络科技有限公司 | Blockchain machine, blockchain data access authentication method, and computer-readable storage medium |
US20210359852A1 (en) * | 2020-05-13 | 2021-11-18 | Ridgeline, Inc. | Auditing for events |
EP3759630A4 (en) * | 2018-03-02 | 2021-11-24 | Blocksafe Technologies, Inc. | Systems and methods for controlling access to a blockchain |
US11188384B2 (en) | 2018-11-07 | 2021-11-30 | Ebay Inc. | Resource trust model for securing component state data for a resource using blockchains |
US11206133B2 (en) | 2017-12-08 | 2021-12-21 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US11240027B2 (en) * | 2019-02-04 | 2022-02-01 | Hewlett Packard Enterprise Development Lp | Synchronizing radius server databases using distributed ledger network |
US20220052852A1 (en) * | 2017-06-02 | 2022-02-17 | Visa International Service Association | Secure biometric authentication using electronic identity |
US11263415B2 (en) | 2016-03-07 | 2022-03-01 | Ping Identity Corporation | Transferring data files using a series of visual codes |
US11297056B1 (en) * | 2018-08-01 | 2022-04-05 | United Services Automobile Association (Usaa) | Systems and methods for electronic enrollment and authentication |
US11292622B2 (en) | 2013-10-07 | 2022-04-05 | Shay C. Colson | 3D printed vehicle packaging |
US11294889B2 (en) | 2019-09-23 | 2022-04-05 | Trace, LLC | Systems and methods for writing updates to and/or reading previously stored updates of assets implemented as smart contracts on a decentralized database |
US11292241B2 (en) | 2016-05-25 | 2022-04-05 | Shay C. Colson | 3-D packaging and shipping based on aggregate data |
US11316698B2 (en) * | 2019-07-17 | 2022-04-26 | Guardtime Sa | Delegated signatures for smart devices |
US11323272B2 (en) | 2017-02-06 | 2022-05-03 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US20220150228A1 (en) * | 2019-03-28 | 2022-05-12 | Bankvault Pty Ltd | Computer systems and methods including html browser authorisation approaches |
US11348104B2 (en) * | 2019-03-14 | 2022-05-31 | Advanced New Technologies Co., Ltd. | Methods and devices for acquiring and recording tracking information on blockchain |
US11356266B2 (en) * | 2020-09-11 | 2022-06-07 | Bank Of America Corporation | User authentication using diverse media inputs and hash-based ledgers |
US11368456B2 (en) * | 2020-09-11 | 2022-06-21 | Bank Of America Corporation | User security profile for multi-media identity verification |
US11368289B1 (en) | 2020-04-06 | 2022-06-21 | Bank Of America Corporation | Video registration and authentication using blockchain |
US11373177B2 (en) * | 2016-10-26 | 2022-06-28 | Coinplug, Inc. | Method for issuing currency and making payment using utxo-based protocol and server using same |
US20220210157A1 (en) * | 2018-03-12 | 2022-06-30 | Prevade, LLC | Cybersecurity Training System and Process |
US11379785B2 (en) | 2019-03-28 | 2022-07-05 | Ebay Inc. | Decentralized shipping network using blockchains |
US11394550B2 (en) * | 2020-07-30 | 2022-07-19 | Dapper Labs Inc. | Systems and methods providing specialized proof of confidential knowledge |
US11405188B2 (en) * | 2019-09-30 | 2022-08-02 | Coinfirm Limited | Method for secure transferring of information through a network between an origin virtual asset service provider and a destination virtual asset service provider |
CN114884736A (en) * | 2022-05-11 | 2022-08-09 | 山东鲁软数字科技有限公司 | Anti-explosion attack safety protection method and device |
US11410480B2 (en) * | 2018-10-31 | 2022-08-09 | Nec Corporation | Information processing apparatus, information processing method, storage medium, and information processing system |
US11425115B2 (en) | 2018-03-27 | 2022-08-23 | Workday, Inc. | Identifying revoked credentials |
US20220278851A1 (en) * | 2017-07-24 | 2022-09-01 | Comcast Cable Communications, Llc | Systems and methods for managing digital rights |
US11438331B1 (en) * | 2019-06-21 | 2022-09-06 | Early Warning Services, Llc | Digital identity sign-in |
US11456879B2 (en) * | 2016-08-24 | 2022-09-27 | Siemens Aktiengesellschaft | Secure processing of an authorization verification request |
US11475453B2 (en) | 2019-12-31 | 2022-10-18 | Capital One Services, Llc | System and techniques for utilizing a smart contracts library |
US11477190B2 (en) * | 2019-05-01 | 2022-10-18 | Salesforce, Inc. | Dynamic user ID |
US11522713B2 (en) * | 2018-03-27 | 2022-12-06 | Workday, Inc. | Digital credentials for secondary factor authentication |
US11528139B2 (en) | 2019-04-08 | 2022-12-13 | Mastercard International Incorporated | Systems and methods relating to identity authentication and validation |
US11531783B2 (en) * | 2018-03-27 | 2022-12-20 | Workday, Inc. | Digital credentials for step-up authentication |
US11538063B2 (en) | 2018-09-12 | 2022-12-27 | Samsung Electronics Co., Ltd. | Online fraud prevention and detection based on distributed system |
US11544367B2 (en) | 2015-05-05 | 2023-01-03 | Ping Identity Corporation | Systems, apparatus and methods for secure electrical communication of biometric personal identification information to validate the identity of an individual |
US11580002B2 (en) | 2018-08-17 | 2023-02-14 | Intensity Analytics Corporation | User effort detection |
US20230065364A1 (en) * | 2021-08-31 | 2023-03-02 | Microsoft Technology Licensing, Llc | Authentication of communication session participants using blockchain |
US11627000B2 (en) | 2018-03-27 | 2023-04-11 | Workday, Inc. | Digital credentials for employee badging |
US11637849B1 (en) | 2017-11-27 | 2023-04-25 | Lacework Inc. | Graph-based query composition |
US11641278B2 (en) | 2018-03-27 | 2023-05-02 | Workday, Inc. | Digital credential authentication |
US20230145040A1 (en) * | 2021-11-09 | 2023-05-11 | Actv8, Inc. | Method and apparatus for using a single qr code to provide varying user experiences |
US20230163955A1 (en) * | 2020-08-21 | 2023-05-25 | Almond Inc. | Encryption method, terminal device, encryption system, and program |
US11683177B2 (en) | 2018-03-27 | 2023-06-20 | Workday, Inc. | Digital credentials for location aware check in |
US11700117B2 (en) | 2018-03-27 | 2023-07-11 | Workday, Inc. | System for credential storage and verification |
US11698979B2 (en) * | 2018-03-27 | 2023-07-11 | Workday, Inc. | Digital credentials for access to sensitive data |
US11716211B2 (en) | 2016-10-01 | 2023-08-01 | James L. Schmeling | 3D-printed packaging with blockchain integration |
US11716320B2 (en) * | 2018-03-27 | 2023-08-01 | Workday, Inc. | Digital credentials for primary factor authentication |
WO2023177480A1 (en) * | 2022-03-15 | 2023-09-21 | Quotient Partners, Llc | Distributed identity management for a decentralized platform |
US11770261B2 (en) * | 2018-03-27 | 2023-09-26 | Workday, Inc. | Digital credentials for user device authentication |
US11770464B1 (en) | 2019-12-23 | 2023-09-26 | Lacework Inc. | Monitoring communications in a containerized environment |
US11792284B1 (en) | 2017-11-27 | 2023-10-17 | Lacework, Inc. | Using data transformations for monitoring a cloud compute environment |
US11792181B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials as guest check-in for physical building access |
US11792180B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials for visitor network access |
US11818259B2 (en) | 2020-05-13 | 2023-11-14 | Ridgeline, Inc. | Query and projection processing for events |
US11831668B1 (en) | 2019-12-23 | 2023-11-28 | Lacework Inc. | Using a logical graph to model activity in a network environment |
US11836720B2 (en) | 2018-03-12 | 2023-12-05 | The Pen | Infinitely scalable cryptocurrency system with fast, secure verification |
FR3136329A1 (en) * | 2022-06-01 | 2023-12-08 | Orange | Method and device for registering a user with a telecommunications operator. |
US11841960B1 (en) * | 2019-11-26 | 2023-12-12 | Gobeep, Inc. | Systems and processes for providing secure client controlled and managed exchange of data between parties |
US11888992B2 (en) | 2019-02-28 | 2024-01-30 | Advanced New Technologies Co., Ltd. | System and method for generating digital marks |
US11909752B1 (en) | 2017-11-27 | 2024-02-20 | Lacework, Inc. | Detecting deviations from typical user behavior |
US11943344B2 (en) | 2020-05-13 | 2024-03-26 | Ridgeline, Inc. | Mutation processing for events |
US11954130B1 (en) | 2019-12-23 | 2024-04-09 | Lacework Inc. | Alerting based on pod communication-based logical graph |
US11972440B1 (en) * | 2020-06-05 | 2024-04-30 | Trace Labs Llc | Systems and methods for providing a decentralized anti-counterfeit solution for supply chain tracking using single-use codes |
US11979422B1 (en) | 2017-11-27 | 2024-05-07 | Lacework, Inc. | Elastic privileges in a secure access service edge |
US11977796B2 (en) * | 2022-03-09 | 2024-05-07 | Fujifilm Corporation | Content provision device, content provision method, program, and recording medium |
USRE49968E1 (en) | 2017-02-06 | 2024-05-14 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US12021888B1 (en) | 2017-11-27 | 2024-06-25 | Lacework, Inc. | Cloud infrastructure entitlement management by a data platform |
US12032634B1 (en) | 2019-12-23 | 2024-07-09 | Lacework Inc. | Graph reclustering based on different clustering criteria |
US12034754B2 (en) | 2017-11-27 | 2024-07-09 | Lacework, Inc. | Using static analysis for vulnerability detection |
US12041166B2 (en) | 2017-10-19 | 2024-07-16 | Autnhive Corporation | Protecting data using controlled corruption in computer networks |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7533808B2 (en) * | 2005-02-09 | 2009-05-19 | Yuh-Shen Song | Privacy protected cooperation network |
JP4900891B2 (en) * | 2005-04-27 | 2012-03-21 | キヤノン株式会社 | Communication apparatus and communication method |
CN108171494A (en) | 2017-11-23 | 2018-06-15 | 阿里巴巴集团控股有限公司 | A kind of data processing method and device |
EP3528468B1 (en) * | 2018-02-20 | 2021-04-07 | Nokia Technologies Oy | Profile information sharing |
CN109257336B (en) * | 2018-08-24 | 2021-03-16 | 维沃移动通信有限公司 | Block chain-based password information processing method and terminal equipment |
US10896032B2 (en) * | 2018-11-02 | 2021-01-19 | Accenture Global Solutions, Limited | System and method for certifying and deploying instruction code |
CN109698825A (en) * | 2018-12-04 | 2019-04-30 | 东软集团股份有限公司 | Auxiliary login method, device, storage medium and the electronic equipment of Web system |
CN109639437B (en) * | 2019-01-09 | 2021-08-17 | 山东浪潮质量链科技有限公司 | Monitoring method, device, equipment and medium based on trusted data source |
TWI688898B (en) * | 2019-06-19 | 2020-03-21 | 中華電信股份有限公司 | Multi-factor dynamic quick response code authentication system and method |
US10846383B2 (en) | 2019-07-01 | 2020-11-24 | Advanced New Technologies Co., Ltd. | Applet-based account security protection method and system |
CN110519261B (en) * | 2019-08-23 | 2021-11-19 | 东莞盟大集团有限公司 | Risk assessment method for cross-chain operation |
ES2923048A1 (en) * | 2021-02-23 | 2022-09-22 | Salazar Dionisio Abenza | Product and object personalization method using QR Code (Machine-translation by Google Translate, not legally binding) |
US20230123311A1 (en) * | 2021-10-15 | 2023-04-20 | Mastercard International Incorporated | Method and system for enabling e-commerce via digital wallets |
US20230142147A1 (en) * | 2021-11-10 | 2023-05-11 | Microsoft Technology Licensing, Llc | Network communication using proof of presence |
IT202100030803A1 (en) * | 2021-12-06 | 2023-06-06 | Antonmarco Catania | Predictive identification and authentication system for images |
US11948149B1 (en) | 2022-09-06 | 2024-04-02 | Capital One Services, Llc | Systems and methods for virtual certification number source verification |
US11924199B1 (en) | 2023-05-10 | 2024-03-05 | Fmr, Llc | Systems and methods for user authentication using an imaged machine-readable identity document |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130173915A1 (en) * | 2011-12-28 | 2013-07-04 | Pitney Bowes Inc. | System and method for secure nework login |
US20130311768A1 (en) * | 2012-05-21 | 2013-11-21 | Klaus S. Fosmark | Secure authentication of a user using a mobile device |
US20140282961A1 (en) * | 2013-03-15 | 2014-09-18 | Aol Inc. | Systems and methods for using imaging to authenticate online users |
US20160300234A1 (en) * | 2015-04-06 | 2016-10-13 | Bitmark, Inc. | System and method for decentralized title recordation and authentication |
US20160330035A1 (en) * | 2015-05-05 | 2016-11-10 | ShoCard, Inc. | User Identification Management System and Method |
US20180176017A1 (en) * | 2015-02-13 | 2018-06-21 | Yoti Ltd | Digital Identity System |
Family Cites Families (238)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5005200A (en) | 1988-02-12 | 1991-04-02 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US20020170966A1 (en) | 1995-07-27 | 2002-11-21 | Hannigan Brett T. | Identification document including embedded data |
US5901229A (en) | 1995-11-06 | 1999-05-04 | Nippon Telegraph And Telephone Corp. | Electronic cash implementing method using a trustee |
US5862325A (en) | 1996-02-29 | 1999-01-19 | Intermind Corporation | Computer-based communication system and method using metadata defining a control structure |
US5923763A (en) | 1996-03-21 | 1999-07-13 | Walker Asset Management Limited Partnership | Method and apparatus for secure document timestamping |
US6327656B2 (en) | 1996-07-03 | 2001-12-04 | Timestamp.Com, Inc. | Apparatus and method for electronic document certification and verification |
US5996076A (en) | 1997-02-19 | 1999-11-30 | Verifone, Inc. | System, method and article of manufacture for secure digital certification of electronic commerce |
KR100486062B1 (en) | 1997-05-09 | 2005-04-29 | 지티이 서비스 코포레이션 | Biometric certificates |
US6985583B1 (en) | 1999-05-04 | 2006-01-10 | Rsa Security Inc. | System and method for authentication seed distribution |
US6785815B1 (en) | 1999-06-08 | 2004-08-31 | Intertrust Technologies Corp. | Methods and systems for encoding and protecting data using digital signature and watermarking techniques |
AU1432901A (en) | 1999-10-18 | 2001-04-30 | Stamps.Com | Cryptographic module for secure processing of value-bearing items |
US6792536B1 (en) | 1999-10-20 | 2004-09-14 | Timecertain Llc | Smart card system and methods for proving dates in digital files |
US7949606B1 (en) | 1999-12-03 | 2011-05-24 | William Sweet | Intellectual property brokerage system and method |
WO2001067705A2 (en) | 2000-03-10 | 2001-09-13 | Herbert Street Technologies Ltd. | A data transfer and management system |
US7716484B1 (en) | 2000-03-10 | 2010-05-11 | Rsa Security Inc. | System and method for increasing the security of encrypted secrets and authentication |
US8447967B1 (en) | 2000-06-29 | 2013-05-21 | Datamotion, Inc. | Controlled message distribution |
US8380630B2 (en) | 2000-07-06 | 2013-02-19 | David Paul Felsher | Information record infrastructure, system and method |
AU2001287164B2 (en) | 2000-08-04 | 2008-06-26 | First Data Corporation | Method and system for using electronic communications for an electronic contact |
US7552333B2 (en) | 2000-08-04 | 2009-06-23 | First Data Corporation | Trusted authentication digital signature (tads) system |
US7043635B1 (en) | 2000-09-15 | 2006-05-09 | Swivel Secure Limited | Embedded synchronous random disposable code identification method and system |
US20020071565A1 (en) | 2000-12-11 | 2002-06-13 | Kurn David Michael | Software process pre-authorization scheme for applications on a computer system |
US20020141593A1 (en) | 2000-12-11 | 2002-10-03 | Kurn David Michael | Multiple cryptographic key linking scheme on a computer system |
JP4185363B2 (en) | 2001-02-22 | 2008-11-26 | ビーイーエイ システムズ, インコーポレイテッド | System and method for message encryption and signing in a transaction processing system |
US7216083B2 (en) | 2001-03-07 | 2007-05-08 | Diebold, Incorporated | Automated transaction machine digital signature system and method |
US20030037261A1 (en) | 2001-03-26 | 2003-02-20 | Ilumin Corporation | Secured content delivery system and method |
US7353204B2 (en) | 2001-04-03 | 2008-04-01 | Zix Corporation | Certified transmission system |
US7257546B2 (en) | 2001-09-04 | 2007-08-14 | Yahoo! Inc. | System and method for correlating user data from a content provider and user data from an advertising provider that is stored on autonomous systems |
US9189788B1 (en) * | 2001-09-21 | 2015-11-17 | Open Invention Network, Llc | System and method for verifying identity |
US20030070075A1 (en) | 2001-10-04 | 2003-04-10 | Frederic Deguillaume | Secure hybrid robust watermarking resistant against tampering and copy-attack |
WO2003038561A2 (en) | 2001-11-01 | 2003-05-08 | First Usa Bank, N.A. | System and method for establishing or modifying an account with user selectable terms |
US7225161B2 (en) | 2001-12-21 | 2007-05-29 | Schlumberger Omnes, Inc. | Method and system for initializing a key management system |
WO2003103217A1 (en) * | 2002-01-20 | 2003-12-11 | Scientific Generics Limited | Biometric authentication system |
US20030172273A1 (en) | 2002-03-05 | 2003-09-11 | Sjoblom Hans | Method for controlling the distribution of data |
US7206934B2 (en) | 2002-09-26 | 2007-04-17 | Sun Microsystems, Inc. | Distributed indexing of identity information in a peer-to-peer network |
US7644290B2 (en) | 2003-03-31 | 2010-01-05 | Power Measurement Ltd. | System and method for seal tamper detection for intelligent electronic devices |
US20090266882A1 (en) * | 2003-06-17 | 2009-10-29 | Sajkowsky James M | Smart passport system for monitoring and recording activity and data relating to persons |
DE10336805A1 (en) | 2003-08-11 | 2005-06-23 | Siemens Ag | Method for transmitting protected information to multiple recipients |
WO2005029746A2 (en) | 2003-09-12 | 2005-03-31 | Rsa Security Inc. | System and method providing disconnected authentication |
US7822988B2 (en) | 2003-10-23 | 2010-10-26 | Microsoft Corporation | Method and system for identity recognition |
US20050114447A1 (en) | 2003-10-24 | 2005-05-26 | Kim Cameron | Method and system for identity exchange and recognition for groups and group members |
JP2005260490A (en) | 2004-03-10 | 2005-09-22 | Murata Mach Ltd | Transmission apparatus |
US8101350B1 (en) | 2004-05-24 | 2012-01-24 | Isis Pharmaceuticals, Inc. | Modulation of exportin 5 expression |
US7373516B2 (en) | 2004-08-19 | 2008-05-13 | International Business Machines Corporation | Systems and methods of securing resources through passwords |
US7575168B2 (en) | 2004-10-01 | 2009-08-18 | Nokia Corporation | Methods, devices and computer program products for generating, displaying and capturing a series of images of visually encoded data |
DE102004052117A1 (en) | 2004-10-26 | 2006-04-27 | Zilch, André, Dr. | Identification documents production method involves obtaining electronic graphic data and electronic text data of customer, and obtaining signature of customer electronically to complete identification document for customer |
US7578436B1 (en) | 2004-11-08 | 2009-08-25 | Pisafe, Inc. | Method and apparatus for providing secure document distribution |
US8359611B2 (en) | 2005-03-08 | 2013-01-22 | International Business Machines Corporation | Searchable television commercials |
US20070016785A1 (en) | 2005-07-14 | 2007-01-18 | Yannick Guay | System and method for digital signature and authentication |
CN100379190C (en) | 2005-07-19 | 2008-04-02 | 北京中星微电子有限公司 | Rate control method based on two-dimension code video transmission |
US20070033150A1 (en) * | 2005-08-08 | 2007-02-08 | Enenia Biometrics, Inc. | Biometric web payment system |
US8903744B2 (en) | 2005-11-18 | 2014-12-02 | Xerox Corporation | System and method for controlling access to personal identification information contained in documents |
FR2895125B1 (en) | 2005-12-21 | 2008-12-12 | Novatec Sa | METHOD OF AUTHENTICATING DOCUMENTS AND DEVICE FOR READING SAID DOCUMENTS FOR RECORDING FOR EVIDENCE |
JP4427513B2 (en) | 2006-01-16 | 2010-03-10 | 株式会社リコー | Card authentication system |
US8249965B2 (en) | 2006-03-30 | 2012-08-21 | Obopay, Inc. | Member-supported mobile payment system |
US7873573B2 (en) | 2006-03-30 | 2011-01-18 | Obopay, Inc. | Virtual pooled account for mobile banking |
KR100798651B1 (en) | 2006-06-16 | 2008-01-28 | 삼성전자주식회사 | Apparatus and method for dynamically changing password |
US8078880B2 (en) | 2006-07-28 | 2011-12-13 | Microsoft Corporation | Portable personal identity information |
US7766241B2 (en) | 2006-09-29 | 2010-08-03 | Konica Minolta Systems Laboratory, Inc. | Barcode for two-way verification of a document |
US7523865B2 (en) | 2006-09-29 | 2009-04-28 | Konica Minolta Systems Laboratory, Inc. | High resolution barcode and document including verification features |
JP4996904B2 (en) | 2006-10-04 | 2012-08-08 | 株式会社日立製作所 | Biometric authentication system, registration terminal, authentication terminal, and authentication server |
US20100020970A1 (en) | 2006-11-13 | 2010-01-28 | Xu Liu | System And Method For Camera Imaging Data Channel |
US7953670B2 (en) * | 2006-12-27 | 2011-05-31 | Colella Brian A | Biometrically secured identification authentication and card reader device |
US8769637B2 (en) | 2007-03-23 | 2014-07-01 | Sap Ag | Iterated password hash systems and methods for preserving password entropy |
US8744076B2 (en) | 2007-04-04 | 2014-06-03 | Oracle International Corporation | Method and apparatus for encrypting data to facilitate resource savings and tamper detection |
US8058972B2 (en) * | 2007-05-09 | 2011-11-15 | University Of North Texas | Methods and devices for enrollment and verification of biometric information in identification documents |
WO2009070430A2 (en) | 2007-11-08 | 2009-06-04 | Suridx, Inc. | Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones |
US7904450B2 (en) | 2008-04-25 | 2011-03-08 | Wilson Kelce S | Public electronic document dating list |
US8732452B2 (en) | 2008-06-23 | 2014-05-20 | Microsoft Corporation | Secure message delivery using a trust broker |
KR101007521B1 (en) | 2008-07-23 | 2011-01-18 | (주)에스알파트너즈 | Document authentication system using electronic signature of licensee and document authentication method thereof |
ATE524897T1 (en) | 2008-09-17 | 2011-09-15 | Gmv Soluciones Globales Internet S A | METHOD AND SYSTEM FOR AUTHENTICATING A USER USING A MOBILE TELEPHONE DEVICE |
US8788830B2 (en) | 2008-10-02 | 2014-07-22 | Ricoh Co., Ltd. | Method and apparatus for logging based identification |
US20110302412A1 (en) | 2008-10-08 | 2011-12-08 | Leiwen Deng | Pseudonymous public keys based authentication |
EP2234028A1 (en) | 2009-02-26 | 2010-09-29 | Research In Motion Limited | System and method of handling encrypted backup data |
US9270420B2 (en) | 2009-04-24 | 2016-02-23 | Samsung Electronics Co., Ltd. | Data communication using 2D bar codes |
US9768965B2 (en) | 2009-05-28 | 2017-09-19 | Adobe Systems Incorporated | Methods and apparatus for validating a digital signature |
US10255419B1 (en) * | 2009-06-03 | 2019-04-09 | James F. Kragh | Identity validation and verification system and associated methods |
US8560353B2 (en) | 2009-06-25 | 2013-10-15 | Victor Smith | Receipt insurance systems and methods |
US8668137B2 (en) | 2009-07-02 | 2014-03-11 | Barcode Graphics Inc. | Barcode systems having multiple viewing angles |
US20120185398A1 (en) | 2009-09-17 | 2012-07-19 | Meir Weis | Mobile payment system with two-point authentication |
NZ624935A (en) | 2009-10-19 | 2016-01-29 | Theranos Inc | Integrated health data capture and analysis system |
US8430301B2 (en) | 2009-11-23 | 2013-04-30 | Konica Minolta Laboratory U.S.A., Inc. | Document authentication using hierarchical barcode stamps to detect alterations of barcode |
DE102009055947A1 (en) | 2009-11-30 | 2011-06-01 | Christoph Busch | Authenticated transmission of data |
US8924302B2 (en) | 2009-12-11 | 2014-12-30 | Eoriginal, Inc. | System and method for electronic transmission, storage, retrieval and remote signing of authenticated electronic original documents |
US8522024B2 (en) | 2009-12-31 | 2013-08-27 | Feitian Technologies Co., Ltd. | Authentication method, system, and device |
US20110231913A1 (en) | 2010-03-17 | 2011-09-22 | State of Oregon acting by and through the State Board of Education on Behalf of Portland State | System and methods of determining computational puzzle difficulty for challenge-response authentication |
EP2553863A1 (en) | 2010-03-29 | 2013-02-06 | Intel Corporation | Methods and apparatuses for administrator-driven profile update |
US8788842B2 (en) | 2010-04-07 | 2014-07-22 | Apple Inc. | System and method for content protection based on a combination of a user PIN and a device specific identifier |
US8601263B1 (en) | 2010-05-18 | 2013-12-03 | Google Inc. | Storing encrypted objects |
US10193689B2 (en) | 2010-05-19 | 2019-01-29 | International Business Machines Corporation | Storing access information in a dispersed storage network |
DE102010030590A1 (en) | 2010-06-28 | 2011-12-29 | Bundesdruckerei Gmbh | Procedure for generating a certificate |
US8832807B1 (en) | 2010-08-05 | 2014-09-09 | Christine E. Kuo | Method and apparatus for asynchronous dynamic password |
US20130173484A1 (en) * | 2010-09-18 | 2013-07-04 | Philip Wesby | System and Method for Encoding and Controlled Authentication |
US8342406B2 (en) | 2010-09-20 | 2013-01-01 | Research In Motion Limited | System and method for data transfer through animated barcodes |
US8756706B2 (en) | 2010-10-12 | 2014-06-17 | Blackberry Limited | Method for securing credentials in a remote repository |
US8381973B2 (en) | 2010-11-22 | 2013-02-26 | International Business Machines Corporation | System and method for providing and verifying a passport |
WO2012125655A1 (en) | 2011-03-14 | 2012-09-20 | Conner Investments, Llc | Bluetooth enabled credit card with a large date storage volume |
US20120308003A1 (en) | 2011-05-31 | 2012-12-06 | Verisign, Inc. | Authentic barcodes using digital signatures |
US9141779B2 (en) * | 2011-05-19 | 2015-09-22 | Microsoft Technology Licensing, Llc | Usable security of online password management with sensor-based authentication |
US9721078B2 (en) * | 2011-06-29 | 2017-08-01 | Alclear Llc | System and method for user enrollment in a secure biometric verification system |
US9355393B2 (en) * | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9240058B1 (en) | 2011-07-12 | 2016-01-19 | A9.Com, Inc. | Dynamic barcode generation for content location |
US8646686B2 (en) | 2011-08-11 | 2014-02-11 | Benton William Bullwinkel | Secure system for creating and validating personal identification cards with operator discretion |
US8874915B1 (en) | 2011-09-28 | 2014-10-28 | Amazon Technologies, Inc. | Optimized encryption key exchange |
US8943320B2 (en) | 2011-10-31 | 2015-01-27 | Novell, Inc. | Techniques for authentication via a mobile device |
KR20130055794A (en) * | 2011-11-21 | 2013-05-29 | 주식회사 케이티 | User device for sharing qr code information, and method of sharing qr code information using user device |
CN102497265B (en) | 2011-11-24 | 2014-03-12 | 飞天诚信科技股份有限公司 | Pulse light signal identification method and apparatus thereof |
EP2786369A4 (en) | 2011-11-30 | 2016-12-07 | Overtone Labs Inc | Drum and drum-set tuner |
US8635448B2 (en) | 2011-12-06 | 2014-01-21 | Cisco Technology, Inc. | Secure prefix authorization with untrusted mapping services |
GB2497580A (en) | 2011-12-16 | 2013-06-19 | Intercede Ltd | Data transmission using a plurality of barcodes displayed in a loop |
US8776194B2 (en) * | 2012-02-01 | 2014-07-08 | Amazon Technologies, Inc. | Authentication management services |
US20130228624A1 (en) | 2012-03-02 | 2013-09-05 | Mastercard International Incorporated | Method and apparatus for transferring and receiving data using multi-frame bar codes |
US10503888B2 (en) * | 2012-03-16 | 2019-12-10 | Traitware, Inc. | Authentication system |
US20160337351A1 (en) * | 2012-03-16 | 2016-11-17 | Acuity Systems, Inc. | Authentication system |
DE13771788T1 (en) * | 2012-04-01 | 2015-12-17 | Authentify, Inc. | Secure authentication in a multiparty system |
US20130262309A1 (en) * | 2012-04-02 | 2013-10-03 | Mpayme Ltd. | Method and System for Secure Mobile Payment |
US9087204B2 (en) * | 2012-04-10 | 2015-07-21 | Sita Information Networking Computing Ireland Limited | Airport security check system and method therefor |
US20130290733A1 (en) | 2012-04-26 | 2013-10-31 | Appsense Limited | Systems and methods for caching security information |
US8925059B2 (en) | 2012-06-08 | 2014-12-30 | Lockheed Martin Corporation | Dynamic trust connection |
US20140006806A1 (en) | 2012-06-23 | 2014-01-02 | Pomian & Corella, Llc | Effective data protection for mobile devices |
US9947005B2 (en) | 2012-06-24 | 2018-04-17 | Amx Llc | Method and apparatus of processing symbology interactions between mobile stations and a control system |
CN103516687B (en) | 2012-06-27 | 2016-08-17 | 中国银联股份有限公司 | Security information interaction system, Apparatus and method for |
US8762712B1 (en) | 2012-07-27 | 2014-06-24 | Trend Micro Incorporated | Methods and system for person-to-person secure file transfer |
US8770484B2 (en) | 2012-09-21 | 2014-07-08 | Alcatel Lucent | Data exchange using streamed barcodes |
US20140093144A1 (en) * | 2012-10-01 | 2014-04-03 | Dannie Gerrit Feekes | More-Secure Hardware Token |
US20150278805A1 (en) * | 2012-10-01 | 2015-10-01 | Acuity Systems, Inc. | Authentication system |
US9876775B2 (en) | 2012-11-09 | 2018-01-23 | Ent Technologies, Inc. | Generalized entity network translation (GENT) |
US10102510B2 (en) | 2012-11-28 | 2018-10-16 | Hoverkey Ltd. | Method and system of conducting a cryptocurrency payment via a mobile device using a contactless token to store and protect a user's secret key |
US20160005032A1 (en) | 2012-11-28 | 2016-01-07 | Hoverkey Ltd. | Method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors |
US9172699B1 (en) * | 2012-11-30 | 2015-10-27 | Microstrategy Incorporated | Associating a device with a user account |
US9069879B2 (en) | 2012-12-27 | 2015-06-30 | Dropbox, Inc. | Globally unique identifiers in an online content management system |
US9412283B2 (en) * | 2012-12-31 | 2016-08-09 | Piyush Bhatnagar | System, design and process for easy to use credentials management for online accounts using out-of-band authentication |
US9741265B2 (en) | 2012-12-31 | 2017-08-22 | Piyush Bhatnagar | System, design and process for secure documents credentials management using out-of-band authentication |
US8869303B2 (en) | 2013-02-16 | 2014-10-21 | Mikhail Fleysher | Method and system for generation of dynamic password |
US20140254796A1 (en) * | 2013-03-08 | 2014-09-11 | The Chinese University Of Hong Kong | Method and apparatus for generating and/or processing 2d barcode |
US9269224B2 (en) | 2013-03-11 | 2016-02-23 | Cfph, Llc | Devices for gaming |
US9059858B1 (en) | 2013-03-11 | 2015-06-16 | Ca, Inc. | User characteristic based digital signature of documents |
WO2014182957A1 (en) * | 2013-05-08 | 2014-11-13 | Acuity Systems, Inc. | Authentication system |
US20140344015A1 (en) | 2013-05-20 | 2014-11-20 | José Antonio Puértolas-Montañés | Systems and methods enabling consumers to control and monetize their personal data |
JP6096893B2 (en) | 2013-05-28 | 2017-03-15 | 株式会社日立製作所 | Biometric signature system, registration terminal and signature generation terminal |
CN103395742B (en) | 2013-08-05 | 2015-05-06 | 四川亚联高科技股份有限公司 | New water carbon ratio control device |
EP3036672A4 (en) | 2013-08-21 | 2017-04-26 | Ascribe GmbH | Method to securely establish, affirm, and transfer ownership of artworks |
US20180082050A1 (en) * | 2013-09-08 | 2018-03-22 | Yona Flink | Method and a system for secure login to a computer, computer network, and computer website using biometrics and a mobile computing wireless electronic communication device |
US9710808B2 (en) | 2013-09-16 | 2017-07-18 | Igor V. SLEPININ | Direct digital cash system and method |
US9646150B2 (en) | 2013-10-01 | 2017-05-09 | Kalman Csaba Toth | Electronic identity and credentialing system |
US9465800B2 (en) | 2013-10-01 | 2016-10-11 | Trunomi Ltd. | Systems and methods for sharing verified identity documents |
US20150104005A1 (en) | 2013-10-10 | 2015-04-16 | Elwha Llc | Methods, systems, and devices for handling captured image data that is received by devices |
US9087205B2 (en) | 2013-10-11 | 2015-07-21 | Sap Se | Shared encrypted storage |
KR101450013B1 (en) | 2013-12-20 | 2014-10-13 | 주식회사 시큐브 | Authentication system and method using Quick Response(QR) code |
US9639710B2 (en) | 2013-12-23 | 2017-05-02 | Symantec Corporation | Device-based PIN authentication process to protect encrypted data |
US9838388B2 (en) * | 2014-08-26 | 2017-12-05 | Veridium Ip Limited | System and method for biometric protocol standards |
US10163105B1 (en) * | 2014-01-24 | 2018-12-25 | Microstrategy Incorporated | Variable biometrics for multi-factor authentication |
US20160012465A1 (en) | 2014-02-08 | 2016-01-14 | Jeffrey A. Sharp | System and method for distributing, receiving, and using funds or credits and apparatus thereof |
US9331856B1 (en) | 2014-02-10 | 2016-05-03 | Symantec Corporation | Systems and methods for validating digital signatures |
WO2015142765A1 (en) | 2014-03-17 | 2015-09-24 | Coinbase, Inc | Bitcoin host computer system |
US9608822B2 (en) | 2014-03-18 | 2017-03-28 | Ecole Polytechnique Federale De Lausanne (Epfl) | Method for generating an HTML document that contains encrypted files and the code necessary for decrypting them when a valid passphrase is provided |
US20150269614A1 (en) | 2014-03-18 | 2015-09-24 | Onename Global, Inc. | Combination Social Media Dashboard, Social Media Website Network and Monetized Advertisement Marketplace |
US9594919B2 (en) | 2014-03-21 | 2017-03-14 | Samunsung Electronics Co., Ltd. | System and method for executing file by using biometric information |
CA2980707A1 (en) | 2014-03-25 | 2015-10-01 | Botanic Technologies, Inc. | Systems and methods for executing cryptographically secure transactions using voice and natural language processing |
US10832310B2 (en) | 2014-03-31 | 2020-11-10 | Monticello Enterprises LLC | System and method for providing a search entity-based payment process |
US9135787B1 (en) | 2014-04-04 | 2015-09-15 | Mark Russell | Bitcoin kiosk/ATM device and system integrating enrollment protocol and method of using the same |
US20150302401A1 (en) | 2014-04-18 | 2015-10-22 | Ebay Inc. | Distributed crypto currency unauthorized transfer monitoring system |
US10340038B2 (en) | 2014-05-13 | 2019-07-02 | Nant Holdings Ip, Llc | Healthcare transaction validation via blockchain, systems and methods |
US9818092B2 (en) | 2014-06-04 | 2017-11-14 | Antti Pennanen | System and method for executing financial transactions |
US20150356523A1 (en) | 2014-06-07 | 2015-12-10 | ChainID LLC | Decentralized identity verification systems and methods |
US9509720B2 (en) | 2014-06-12 | 2016-11-29 | Cisco Technology, Inc. | Techniques for improved run time trustworthiness |
WO2016014969A1 (en) | 2014-07-24 | 2016-01-28 | Marvell Semiconductor, Inc. | Group acknowledgement for multiple user communication in a wireless local area network |
US9608829B2 (en) | 2014-07-25 | 2017-03-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
AU2015311866B2 (en) | 2014-09-03 | 2018-06-07 | Nant Holdings Ip, Llc | Synthetic genomic variant-based secure transaction devices, systems and methods |
US20160098730A1 (en) | 2014-10-01 | 2016-04-07 | The Filing Cabinet, LLC | System and Method for Block-Chain Verification of Goods |
US20160098723A1 (en) | 2014-10-01 | 2016-04-07 | The Filing Cabinet, LLC | System and method for block-chain verification of goods |
US9749297B2 (en) | 2014-11-12 | 2017-08-29 | Yaron Gvili | Manicoding for communication verification |
US20160162897A1 (en) | 2014-12-03 | 2016-06-09 | The Filing Cabinet, LLC | System and method for user authentication using crypto-currency transactions as access tokens |
GB2533340A (en) | 2014-12-17 | 2016-06-22 | Ibm | Network system and method for transferring cryptocurrencies between a user account and a receiving account |
US10110385B1 (en) | 2014-12-22 | 2018-10-23 | Amazon Technologies, Inc. | Duress signatures |
EP3040898A1 (en) | 2014-12-31 | 2016-07-06 | Gemalto Sa | System and method for obfuscating an identifier to protect the identifier from impermissible appropriation |
US20160217436A1 (en) | 2015-01-25 | 2016-07-28 | Dror Samuel Brama | Method, System and Program Product for Tracking and Securing Transactions of Authenticated Items over Block Chain Systems. |
US10257179B1 (en) * | 2015-01-26 | 2019-04-09 | Microstrategy Incorporated | Credential management system and peer detection |
US10853592B2 (en) * | 2015-02-13 | 2020-12-01 | Yoti Holding Limited | Digital identity system |
WO2016145454A1 (en) * | 2015-03-12 | 2016-09-15 | Wiacts, Inc. | Multi-factor user authentication |
US10146923B2 (en) | 2015-03-20 | 2018-12-04 | Aplcomp Oy | Audiovisual associative authentication method, related system and device |
US20160283939A1 (en) | 2015-03-25 | 2016-09-29 | Qualcomm Incorporated | System and method to prevent loss of bitcoins due to address errors |
SI3073670T1 (en) | 2015-03-27 | 2021-07-30 | Black Gold Coin, Inc. | A system and a method for personal identification and verification |
US20180240107A1 (en) | 2015-03-27 | 2018-08-23 | Black Gold Coin, Inc. | Systems and methods for personal identification and verification |
US20160283920A1 (en) | 2015-03-28 | 2016-09-29 | Justin Fisher | Authentication and verification of digital data utilizing blockchain technology |
US9397985B1 (en) | 2015-04-14 | 2016-07-19 | Manifold Technology, Inc. | System and method for providing a cryptographic platform for exchanging information |
CN107851111A (en) | 2015-05-05 | 2018-03-27 | 识卡公司 | Use the identity management services of block chain |
US20170228731A1 (en) | 2016-02-09 | 2017-08-10 | Fmr Llc | Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems |
US20170109735A1 (en) | 2015-07-14 | 2017-04-20 | Fmr Llc | Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems |
US10033702B2 (en) | 2015-08-05 | 2018-07-24 | Intralinks, Inc. | Systems and methods of secure data exchange |
US10419514B2 (en) | 2015-08-14 | 2019-09-17 | Oracle International Corporation | Discovery of federated logins |
US10148437B2 (en) | 2015-09-21 | 2018-12-04 | Oracle International Corporation | Encryption system with key recovery |
US20170103389A1 (en) | 2015-10-07 | 2017-04-13 | Aerius, Inc. | Electronic Payment Validation and Authorization System |
KR101637854B1 (en) | 2015-10-16 | 2016-07-08 | 주식회사 코인플러그 | Certificate issuance system and method based on block chain, certificate authentication system and method based on block chain |
US9948467B2 (en) | 2015-12-21 | 2018-04-17 | Mastercard International Incorporated | Method and system for blockchain variant using digital signatures |
US10079682B2 (en) | 2015-12-22 | 2018-09-18 | Gemalto Sa | Method for managing a trusted identity |
US10475036B2 (en) | 2016-01-08 | 2019-11-12 | Ca, Inc. | Restricting account use by controlled replenishment |
US10341091B2 (en) | 2016-01-15 | 2019-07-02 | Bittium Wireless Oy | Secure memory storage |
US9679276B1 (en) | 2016-01-26 | 2017-06-13 | Stampery, Inc. | Systems and methods for using a block chain to certify the existence, integrity, and/or ownership of a file or communication |
US11354658B2 (en) | 2016-02-11 | 2022-06-07 | Mastercard International Incorporated | Method and system for offline blockchain exchanges |
US20190342096A1 (en) * | 2016-02-11 | 2019-11-07 | Evident ID, Inc. | Online identity and credential verification systems and methods protecting user data |
US10587609B2 (en) * | 2016-03-04 | 2020-03-10 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US10007826B2 (en) | 2016-03-07 | 2018-06-26 | ShoCard, Inc. | Transferring data files using a series of visual codes |
US10509932B2 (en) | 2016-03-07 | 2019-12-17 | ShoCard, Inc. | Large data transfer using visual codes with feedback confirmation |
US20170279788A1 (en) | 2016-03-28 | 2017-09-28 | Internet Brands, Inc. | Secure remote password retrieval |
US20170324711A1 (en) | 2016-05-03 | 2017-11-09 | The Real Mccoy, Llc Inc. | Method for establishing, securing and transferring computer readable information using peer-to-peer public and private key cryptography |
US11030187B1 (en) | 2016-05-18 | 2021-06-08 | Salesforce.Com, Inc. | Distributed database systems and structures |
US10204341B2 (en) | 2016-05-24 | 2019-02-12 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees |
US20170344988A1 (en) | 2016-05-24 | 2017-11-30 | Ubs Ag | System and method for facilitating blockchain-based validation |
US10574692B2 (en) * | 2016-05-30 | 2020-02-25 | Christopher Nathan Tyrwhitt Drake | Mutual authentication security system with detection and mitigation of active man-in-the-middle browser attacks, phishing, and malware and other security improvements |
US11025618B2 (en) | 2016-06-09 | 2021-06-01 | Logmein, Inc. | Mobile device access to a protected account associated with a website |
US10108954B2 (en) | 2016-06-24 | 2018-10-23 | PokitDok, Inc. | System and method for cryptographically verified data driven contracts |
US10700853B2 (en) | 2016-07-12 | 2020-06-30 | International Business Machines Corporation | Token identity and attribute management |
WO2018027059A1 (en) * | 2016-08-03 | 2018-02-08 | KryptCo, Inc. | Systems and methods for delegated cryptography |
US10511589B2 (en) | 2016-09-14 | 2019-12-17 | Oracle International Corporation | Single logout functionality for a multi-tenant identity and data security management cloud service |
US11170346B2 (en) | 2016-09-19 | 2021-11-09 | Sap Se | Decentralized credentials verification network |
WO2018057510A1 (en) | 2016-09-20 | 2018-03-29 | United States Postal Service | Methods and systems for a digital trust architecture |
US20180343120A1 (en) * | 2016-10-26 | 2018-11-29 | Black Gold Coin, Inc. | Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features |
US10484178B2 (en) * | 2016-10-26 | 2019-11-19 | Black Gold Coin, Inc. | Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features |
EP3536002B1 (en) * | 2016-11-08 | 2020-11-18 | Aware, Inc. | Decentralized biometric identity authentication |
US10460126B2 (en) | 2016-11-21 | 2019-10-29 | Adobe Inc. | Providing user control of shared personal information |
FR3061974B1 (en) | 2017-01-18 | 2020-04-24 | Safran Identity and Security | METHOD AND DEVICE FOR VERIFYING THE VALIDITY OF AN ELECTRONIC DOCUMENT |
WO2018145127A1 (en) | 2017-02-06 | 2018-08-09 | ShoCard, Inc. | Electronic identification verification methods and systems with storage of certification records to a side chain |
US10498541B2 (en) | 2017-02-06 | 2019-12-03 | ShocCard, Inc. | Electronic identification verification methods and systems |
US10554654B1 (en) | 2017-05-31 | 2020-02-04 | Wells Fargo Bank, N.A. | Secure access for assisted transactions in an online banking system |
DE102017113529A1 (en) * | 2017-06-12 | 2018-12-13 | Rubean AG | Method and system for checking the authenticity of a trusted user interface |
US11025626B1 (en) | 2017-07-26 | 2021-06-01 | EMC IP Holding Company LLC | Decentralized identities for access to multiple computing resource systems |
US10805085B1 (en) | 2017-08-24 | 2020-10-13 | United Services Automobile Association (Usaa) | PKI-based user authentication for web services using blockchain |
US10642967B2 (en) | 2017-11-28 | 2020-05-05 | American Express Travel Related Services Company, Inc. | Single sign-on solution using blockchain |
EP3721578B1 (en) | 2017-12-08 | 2022-09-07 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US10885220B2 (en) | 2018-01-24 | 2021-01-05 | Zortag Inc. | Secure access to physical and digital assets using authentication key |
KR101893729B1 (en) | 2018-03-28 | 2018-10-04 | 주식회사 마크로젠 | Data sharing method based on multiple block-chains |
EP3791341A1 (en) | 2018-05-11 | 2021-03-17 | Civic Technologies, Inc. | Rewards and penalties of the reward function for the attestation game |
US10855667B2 (en) | 2018-06-01 | 2020-12-01 | Paypal, Inc. | Using keys with targeted access to the blockchain to verify and authenticate identity |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US11134065B2 (en) | 2018-12-06 | 2021-09-28 | Visa International Service Association | Secured extended range application data exchange |
US11128471B2 (en) | 2019-04-25 | 2021-09-21 | Microsoft Technology Licensing, Llc | Accessibility controls in distributed data systems |
US20220029799A1 (en) | 2020-12-18 | 2022-01-27 | Signzy Technologies Private Limited | System and method for creating one or more hashes for biometric authentication in real-time |
-
2017
- 2017-03-03 US US15/449,902 patent/US10587609B2/en active Active
- 2017-03-03 WO PCT/US2017/020829 patent/WO2017152150A1/en active Application Filing
- 2017-03-03 EP EP17760964.1A patent/EP3424179B1/en active Active
- 2017-03-03 EP EP22156663.1A patent/EP4027254A3/en active Pending
-
2018
- 2018-12-20 US US16/227,632 patent/US11134075B2/en active Active
-
2021
- 2021-09-21 US US17/480,673 patent/US11658961B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130173915A1 (en) * | 2011-12-28 | 2013-07-04 | Pitney Bowes Inc. | System and method for secure nework login |
US20130311768A1 (en) * | 2012-05-21 | 2013-11-21 | Klaus S. Fosmark | Secure authentication of a user using a mobile device |
US20140282961A1 (en) * | 2013-03-15 | 2014-09-18 | Aol Inc. | Systems and methods for using imaging to authenticate online users |
US20180176017A1 (en) * | 2015-02-13 | 2018-06-21 | Yoti Ltd | Digital Identity System |
US20160300234A1 (en) * | 2015-04-06 | 2016-10-13 | Bitmark, Inc. | System and method for decentralized title recordation and authentication |
US20160330035A1 (en) * | 2015-05-05 | 2016-11-10 | ShoCard, Inc. | User Identification Management System and Method |
US9876646B2 (en) * | 2015-05-05 | 2018-01-23 | ShoCard, Inc. | User identification management system and method |
Cited By (339)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10981680B2 (en) | 2013-10-07 | 2021-04-20 | Shay C. Colson | 3-D printed package customization |
US9994339B2 (en) | 2013-10-07 | 2018-06-12 | Shay C. Colson | 3-D printed packaging |
US10435185B2 (en) | 2013-10-07 | 2019-10-08 | David A. Divine | 3-D printed packaging |
US11292622B2 (en) | 2013-10-07 | 2022-04-05 | Shay C. Colson | 3D printed vehicle packaging |
US11544367B2 (en) | 2015-05-05 | 2023-01-03 | Ping Identity Corporation | Systems, apparatus and methods for secure electrical communication of biometric personal identification information to validate the identity of an individual |
US10515111B2 (en) | 2016-01-19 | 2019-12-24 | Regwez, Inc. | Object stamping user interface |
US10614119B2 (en) | 2016-01-19 | 2020-04-07 | Regwez, Inc. | Masking restrictive access control for a user on multiple devices |
US10621225B2 (en) | 2016-01-19 | 2020-04-14 | Regwez, Inc. | Hierarchical visual faceted search engine |
US11436274B2 (en) | 2016-01-19 | 2022-09-06 | Regwez, Inc. | Visual access code |
US10747808B2 (en) | 2016-01-19 | 2020-08-18 | Regwez, Inc. | Hybrid in-memory faceted engine |
US11093543B2 (en) | 2016-01-19 | 2021-08-17 | Regwez, Inc. | Masking restrictive access control system |
US10587609B2 (en) * | 2016-03-04 | 2020-03-10 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US20220078178A1 (en) * | 2016-03-04 | 2022-03-10 | Ping Identity Corporation | Method and system for authenticated login using static or dynamic codes |
US11658961B2 (en) * | 2016-03-04 | 2023-05-23 | Ping Identity Corporation | Method and system for authenticated login using static or dynamic codes |
US11134075B2 (en) * | 2016-03-04 | 2021-09-28 | Ping Identity Corporation | Method and system for authenticated login using static or dynamic codes |
US11544487B2 (en) | 2016-03-07 | 2023-01-03 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US11263415B2 (en) | 2016-03-07 | 2022-03-01 | Ping Identity Corporation | Transferring data files using a series of visual codes |
US11062106B2 (en) | 2016-03-07 | 2021-07-13 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US10389713B2 (en) * | 2016-03-28 | 2019-08-20 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
US10182051B1 (en) * | 2016-03-28 | 2019-01-15 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
US11290449B2 (en) | 2016-03-28 | 2022-03-29 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
US10298572B2 (en) * | 2016-03-28 | 2019-05-21 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
US11292241B2 (en) | 2016-05-25 | 2022-04-05 | Shay C. Colson | 3-D packaging and shipping based on aggregate data |
US10277398B2 (en) * | 2016-06-17 | 2019-04-30 | Capital One Services, Llc | Blockchain systems and methods for user authentication |
US11665147B2 (en) * | 2016-06-17 | 2023-05-30 | Capital One Services, Llc | Blockchain systems and methods for user authentication |
US10944563B2 (en) * | 2016-06-17 | 2021-03-09 | Capital One Services, Llc | Blockchain systems and methods for user authentication |
US20210266166A1 (en) * | 2016-06-17 | 2021-08-26 | Capital One Services, LLC. | Blockchain systems and methods for user authentication |
US11456879B2 (en) * | 2016-08-24 | 2022-09-27 | Siemens Aktiengesellschaft | Secure processing of an authorization verification request |
US10676219B2 (en) | 2016-10-01 | 2020-06-09 | Shay C. Colson | Printing packaging in expanded material |
US11716211B2 (en) | 2016-10-01 | 2023-08-01 | James L. Schmeling | 3D-printed packaging with blockchain integration |
US11565837B2 (en) | 2016-10-01 | 2023-01-31 | Shay C. Colson | Apparatus for packaging an item |
US11373177B2 (en) * | 2016-10-26 | 2022-06-28 | Coinplug, Inc. | Method for issuing currency and making payment using utxo-based protocol and server using same |
US11080380B2 (en) * | 2016-11-08 | 2021-08-03 | Aware, Inc. | Decentralized biometric identity authentication |
US20180212958A1 (en) * | 2017-01-26 | 2018-07-26 | Teltech Systems, Inc. | Two Factor Authentication Using SMS |
USRE49968E1 (en) | 2017-02-06 | 2024-05-14 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US11323272B2 (en) | 2017-02-06 | 2022-05-03 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US11799668B2 (en) | 2017-02-06 | 2023-10-24 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US20180241728A1 (en) * | 2017-02-22 | 2018-08-23 | International Business Machines Corporation | Secure data storage system |
US10560476B2 (en) * | 2017-02-22 | 2020-02-11 | International Business Machines Corporation | Secure data storage system |
US20180253539A1 (en) * | 2017-03-05 | 2018-09-06 | Ronald H. Minter | Robust system and method of authenticating a client in non-face-to-face online interactions based on a combination of live biometrics, biographical data, blockchain transactions and signed digital certificates. |
US10810290B2 (en) * | 2017-03-05 | 2020-10-20 | Ronald H Minter | Robust method and an apparatus for authenticating a client in non-face-to-face online interactions based on a combination of live biometrics, biographical data, blockchain transactions and signed digital certificates |
US11522848B2 (en) | 2017-03-31 | 2022-12-06 | Mastercard International Incorporated | Systems and methods for providing digital identity records to verify identities of users |
US20180288033A1 (en) * | 2017-03-31 | 2018-10-04 | Mastercard International Incorporated | Systems and methods for providing digital identity records to verify identities of users |
US10476862B2 (en) * | 2017-03-31 | 2019-11-12 | Mastercard International Incorporated | Systems and methods for providing digital identity records to verify identities of users |
US10834098B2 (en) | 2017-05-15 | 2020-11-10 | Forcepoint, LLC | Using a story when generating inferences using an adaptive trust profile |
US10326776B2 (en) | 2017-05-15 | 2019-06-18 | Forcepoint, LLC | User behavior profile including temporal detail corresponding to user interaction |
US10999296B2 (en) | 2017-05-15 | 2021-05-04 | Forcepoint, LLC | Generating adaptive trust profiles using information derived from similarly situated organizations |
US10999297B2 (en) | 2017-05-15 | 2021-05-04 | Forcepoint, LLC | Using expected behavior of an entity when prepopulating an adaptive trust profile |
US11757902B2 (en) | 2017-05-15 | 2023-09-12 | Forcepoint Llc | Adaptive trust profile reference architecture |
US10798109B2 (en) | 2017-05-15 | 2020-10-06 | Forcepoint Llc | Adaptive trust profile reference architecture |
US10171488B2 (en) | 2017-05-15 | 2019-01-01 | Forcepoint, LLC | User behavior profile |
US10264012B2 (en) | 2017-05-15 | 2019-04-16 | Forcepoint, LLC | User behavior profile |
US10944762B2 (en) | 2017-05-15 | 2021-03-09 | Forcepoint, LLC | Managing blockchain access to user information |
US11025646B2 (en) | 2017-05-15 | 2021-06-01 | Forcepoint, LLC | Risk adaptive protection |
US10834097B2 (en) | 2017-05-15 | 2020-11-10 | Forcepoint, LLC | Adaptive trust profile components |
US10063568B1 (en) | 2017-05-15 | 2018-08-28 | Forcepoint Llc | User behavior profile in a blockchain |
US10943019B2 (en) | 2017-05-15 | 2021-03-09 | Forcepoint, LLC | Adaptive trust profile endpoint |
US10530786B2 (en) | 2017-05-15 | 2020-01-07 | Forcepoint Llc | Managing access to user profile information via a distributed transaction database |
US11082440B2 (en) | 2017-05-15 | 2021-08-03 | Forcepoint Llc | User profile definition and management |
US10542013B2 (en) | 2017-05-15 | 2020-01-21 | Forcepoint Llc | User behavior profile in a blockchain |
US10855692B2 (en) | 2017-05-15 | 2020-12-01 | Forcepoint, LLC | Adaptive trust profile endpoint |
US10129269B1 (en) | 2017-05-15 | 2018-11-13 | Forcepoint, LLC | Managing blockchain access to user profile information |
US9882918B1 (en) * | 2017-05-15 | 2018-01-30 | Forcepoint, LLC | User behavior profile in a blockchain |
US10855693B2 (en) | 2017-05-15 | 2020-12-01 | Forcepoint, LLC | Using an adaptive trust profile to generate inferences |
US11575685B2 (en) | 2017-05-15 | 2023-02-07 | Forcepoint Llc | User behavior profile including temporal detail corresponding to user interaction |
US10915644B2 (en) | 2017-05-15 | 2021-02-09 | Forcepoint, LLC | Collecting data for centralized use in an adaptive trust profile event via an endpoint |
US10917423B2 (en) | 2017-05-15 | 2021-02-09 | Forcepoint, LLC | Intelligently differentiating between different types of states and attributes when using an adaptive trust profile |
US10862927B2 (en) | 2017-05-15 | 2020-12-08 | Forcepoint, LLC | Dividing events into sessions during adaptive trust profile operations |
US10326775B2 (en) | 2017-05-15 | 2019-06-18 | Forcepoint, LLC | Multi-factor authentication using a user behavior profile as a factor |
US10623431B2 (en) | 2017-05-15 | 2020-04-14 | Forcepoint Llc | Discerning psychological state from correlated user behavior and contextual information |
US10915643B2 (en) | 2017-05-15 | 2021-02-09 | Forcepoint, LLC | Adaptive trust profile endpoint architecture |
US10298609B2 (en) | 2017-05-15 | 2019-05-21 | Forcepoint, LLC | User behavior profile environment |
US10447718B2 (en) | 2017-05-15 | 2019-10-15 | Forcepoint Llc | User profile definition and management |
US10645096B2 (en) | 2017-05-15 | 2020-05-05 | Forcepoint Llc | User behavior profile environment |
US10862901B2 (en) | 2017-05-15 | 2020-12-08 | Forcepoint, LLC | User behavior profile including temporal detail corresponding to user interaction |
US11463453B2 (en) | 2017-05-15 | 2022-10-04 | Forcepoint, LLC | Using a story when generating inferences using an adaptive trust profile |
US20180341775A1 (en) * | 2017-05-23 | 2018-11-29 | International Business Machines Corporation | Digital license authentication with secure privacy logging |
US11044085B2 (en) * | 2017-05-24 | 2021-06-22 | Canon Kabushiki Kaisha | Method employed in user authentication system and information processing apparatus included in user authentication system |
US12039528B2 (en) * | 2017-05-26 | 2024-07-16 | Nchain Licensing Ag | Script-based blockchain interaction |
US12033146B2 (en) | 2017-05-26 | 2024-07-09 | Nchain Licensing Ag | Script based blockchain interaction |
US20200151713A1 (en) * | 2017-05-26 | 2020-05-14 | nChain Holdings Limited | Script-based blockchain interaction |
US20220052852A1 (en) * | 2017-06-02 | 2022-02-17 | Visa International Service Association | Secure biometric authentication using electronic identity |
US11019050B2 (en) * | 2017-06-19 | 2021-05-25 | Advanced New Technologies Co., Ltd. | Authentication method and device, and blockchain-based authentication data processing method and device |
US20220278851A1 (en) * | 2017-07-24 | 2022-09-01 | Comcast Cable Communications, Llc | Systems and methods for managing digital rights |
US20200213125A1 (en) * | 2017-07-24 | 2020-07-02 | nChain Holdings Limited | Computer-implemented system and method enabling secure storage of a large blockchain over a plurality of storage nodes |
US10262153B2 (en) | 2017-07-26 | 2019-04-16 | Forcepoint, LLC | Privacy protection during insider threat monitoring |
US10733323B2 (en) | 2017-07-26 | 2020-08-04 | Forcepoint Llc | Privacy protection during insider threat monitoring |
US20210243029A1 (en) * | 2017-08-10 | 2021-08-05 | Visa International Service Association | Biometric verification process using certification token |
US11736296B2 (en) * | 2017-08-10 | 2023-08-22 | Visa International Service Association | Biometric verification process using certification token |
US11018870B2 (en) * | 2017-08-10 | 2021-05-25 | Visa International Service Association | Biometric verification process using certification token |
US10892894B2 (en) | 2017-08-28 | 2021-01-12 | International Business Machines Corporation | Identity verification using biometric data and non-invertible functions via a blockchain |
US20190068367A1 (en) * | 2017-08-28 | 2019-02-28 | International Business Machines Corporation | Identity verification using biometric data and non-invertible functions via a blockchain |
US10637662B2 (en) * | 2017-08-28 | 2020-04-28 | International Business Machines Corporation | Identity verification using biometric data and non-invertible functions via a blockchain |
US11122036B2 (en) | 2017-09-18 | 2021-09-14 | Mastercard International Incorporated | Systems and methods for managing digital identities associated with mobile devices |
DE102017217342B4 (en) | 2017-09-28 | 2019-08-14 | Rudolf Bayer | Method for managing an electronic transaction document |
DE102017217342A1 (en) * | 2017-09-28 | 2019-03-28 | Rudolf Bayer | A method for generating a digital identity, digital identity, method for creating an electronic transaction document, and electronic transaction document |
US20190116051A1 (en) * | 2017-10-13 | 2019-04-18 | Intensity Analytics Corporation | System and method for effort-based user authentication |
US10891616B2 (en) * | 2017-10-13 | 2021-01-12 | Intensity Analytics Corporation | System and method for effort-based user authentication |
US10872336B2 (en) | 2017-10-13 | 2020-12-22 | Intensity Analytics Corporation | System and method for independent user effort-based validation |
US11176553B2 (en) | 2017-10-13 | 2021-11-16 | Intensity Analytics Corporation | Method and system providing peer effort-based validation |
US11336446B2 (en) | 2017-10-19 | 2022-05-17 | Autnhive Corporation | System and method for generating and depositing keys for multi-point authentication |
US11368301B2 (en) | 2017-10-19 | 2022-06-21 | Autnhive Corporation | Generating keys using controlled corruption in computer networks |
US10819516B2 (en) * | 2017-10-19 | 2020-10-27 | Autnhive Corporation | System and method for generating and depositing keys for multi-point authentication |
US12041166B2 (en) | 2017-10-19 | 2024-07-16 | Autnhive Corporation | Protecting data using controlled corruption in computer networks |
US11930111B2 (en) | 2017-10-19 | 2024-03-12 | Autnhive Corporation | System and method for generating and depositing keys for multi-point authentication |
US12047500B2 (en) | 2017-10-19 | 2024-07-23 | Autnhive Corporation | Generating keys using controlled corruption in computer networks |
US11652629B2 (en) | 2017-10-19 | 2023-05-16 | Autnhive Corporation | Generating keys using controlled corruption in computer networks |
US10903997B2 (en) | 2017-10-19 | 2021-01-26 | Autnhive Corporation | Generating keys using controlled corruption in computer networks |
WO2019089654A1 (en) * | 2017-10-30 | 2019-05-09 | Pricewaterhousecoopers Llp | Implementation of continuous real-time validation of distributed data storage systems |
US10915641B2 (en) | 2017-10-30 | 2021-02-09 | Pricewaterhousecoopers Llp | Implementation of continuous real-time validation of distributed data storage systems |
WO2019089013A1 (en) * | 2017-10-31 | 2019-05-09 | Visa International Service Corporation | Cryptographic key generation system and method |
US11387994B2 (en) | 2017-10-31 | 2022-07-12 | Visa International Service Association | Cryptographic key generation system and method |
US11824978B2 (en) | 2017-10-31 | 2023-11-21 | Visa International Service Association | Cryptographic key generation system and method |
US11637849B1 (en) | 2017-11-27 | 2023-04-25 | Lacework Inc. | Graph-based query composition |
US11979422B1 (en) | 2017-11-27 | 2024-05-07 | Lacework, Inc. | Elastic privileges in a secure access service edge |
US12034754B2 (en) | 2017-11-27 | 2024-07-09 | Lacework, Inc. | Using static analysis for vulnerability detection |
US11882141B1 (en) | 2017-11-27 | 2024-01-23 | Lacework Inc. | Graph-based query composition for monitoring an environment |
US11991198B1 (en) | 2017-11-27 | 2024-05-21 | Lacework, Inc. | User-specific data-driven network security |
US11792284B1 (en) | 2017-11-27 | 2023-10-17 | Lacework, Inc. | Using data transformations for monitoring a cloud compute environment |
US11677772B1 (en) | 2017-11-27 | 2023-06-13 | Lacework Inc. | Using graph-based models to identify anomalies in a network environment |
US11689553B1 (en) | 2017-11-27 | 2023-06-27 | Lacework Inc. | User session-based generation of logical graphs and detection of anomalies |
US11909752B1 (en) | 2017-11-27 | 2024-02-20 | Lacework, Inc. | Detecting deviations from typical user behavior |
US12021888B1 (en) | 2017-11-27 | 2024-06-25 | Lacework, Inc. | Cloud infrastructure entitlement management by a data platform |
US12034750B1 (en) | 2017-11-27 | 2024-07-09 | Lacework Inc. | Tracking of user login sessions |
US11159537B2 (en) * | 2017-11-30 | 2021-10-26 | Bank Of America Corporation | Multicomputer processing for data authentication and event execution using a blockchain approach |
US11777726B2 (en) | 2017-12-08 | 2023-10-03 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US11206133B2 (en) | 2017-12-08 | 2021-12-21 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US10972255B2 (en) * | 2017-12-14 | 2021-04-06 | Paypal, Inc. | Blockchain validation system |
US10673620B2 (en) * | 2017-12-14 | 2020-06-02 | Paypal, Inc. | Blockchain validation system |
US11621827B2 (en) | 2017-12-14 | 2023-04-04 | Paypal, Inc. | Blockchain validation system |
US20190190698A1 (en) * | 2017-12-14 | 2019-06-20 | Paypal, Inc. | Blockchain validation system |
DE112018006407B4 (en) | 2017-12-14 | 2024-07-11 | Paypal, Inc. | BLOCKCHAIN VALIDATION SYSTEM |
CN111771194A (en) * | 2017-12-18 | 2020-10-13 | 北方信托公司 | System and method for generating and maintaining immutable digital conference records within distributed network nodes |
CN108234457A (en) * | 2017-12-18 | 2018-06-29 | 苏州涞泽信息科技有限公司 | A kind of credible government data based on block chain shares network system and sharing method |
US20210241270A1 (en) * | 2017-12-28 | 2021-08-05 | Acronis International Gmbh | System and method of blockchain transaction verification |
US11663672B2 (en) | 2017-12-29 | 2023-05-30 | Nanthealth, Inc. | User interface log validation via blockchain system and methods |
WO2019133682A1 (en) * | 2017-12-29 | 2019-07-04 | Nanthealth, Inc. | User interface log validation via blockchain system and methods |
US11100503B2 (en) | 2018-02-07 | 2021-08-24 | Mastercard International Incorporated | Systems and methods for use in managing digital identities |
US11887121B2 (en) | 2018-02-07 | 2024-01-30 | Mastercard International Incorporated | Systems and methods for use in managing digital identities |
US20190268158A1 (en) * | 2018-02-23 | 2019-08-29 | General Dynamics Information Technology, Inc. | Systems and methods for providing mobile identification of individuals |
EP3759630A4 (en) * | 2018-03-02 | 2021-11-24 | Blocksafe Technologies, Inc. | Systems and methods for controlling access to a blockchain |
US11770378B2 (en) | 2018-03-02 | 2023-09-26 | BlockSafe Technologies, Inc. | Systems and methods for controlling access to a blockchain |
US20190278798A1 (en) * | 2018-03-06 | 2019-09-12 | Hidenobu Kishi | Terminal device, method, and information processing system |
US20220210157A1 (en) * | 2018-03-12 | 2022-06-30 | Prevade, LLC | Cybersecurity Training System and Process |
US11836720B2 (en) | 2018-03-12 | 2023-12-05 | The Pen | Infinitely scalable cryptocurrency system with fast, secure verification |
US11716320B2 (en) * | 2018-03-27 | 2023-08-01 | Workday, Inc. | Digital credentials for primary factor authentication |
US11792181B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials as guest check-in for physical building access |
US11522713B2 (en) * | 2018-03-27 | 2022-12-06 | Workday, Inc. | Digital credentials for secondary factor authentication |
US11683177B2 (en) | 2018-03-27 | 2023-06-20 | Workday, Inc. | Digital credentials for location aware check in |
US11700117B2 (en) | 2018-03-27 | 2023-07-11 | Workday, Inc. | System for credential storage and verification |
US11627000B2 (en) | 2018-03-27 | 2023-04-11 | Workday, Inc. | Digital credentials for employee badging |
US11792180B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials for visitor network access |
US11698979B2 (en) * | 2018-03-27 | 2023-07-11 | Workday, Inc. | Digital credentials for access to sensitive data |
US11425115B2 (en) | 2018-03-27 | 2022-08-23 | Workday, Inc. | Identifying revoked credentials |
US11855978B2 (en) | 2018-03-27 | 2023-12-26 | Workday, Inc. | Sharing credentials |
US11531783B2 (en) * | 2018-03-27 | 2022-12-20 | Workday, Inc. | Digital credentials for step-up authentication |
US11770261B2 (en) * | 2018-03-27 | 2023-09-26 | Workday, Inc. | Digital credentials for user device authentication |
US11641278B2 (en) | 2018-03-27 | 2023-05-02 | Workday, Inc. | Digital credential authentication |
US11836743B2 (en) * | 2018-03-28 | 2023-12-05 | Konstantinos Bakalis | Systems and methods for securing communication data and property using blockchain |
WO2019190872A1 (en) | 2018-03-28 | 2019-10-03 | Konstantinos Bakalis | Systems and methods for using codes and images within a blockchain |
EP3776403A4 (en) * | 2018-03-28 | 2023-02-22 | Konstantinos Bakalis | Systems and methods for using codes and images within a blockchain |
US20210209614A1 (en) * | 2018-03-28 | 2021-07-08 | Konstantinos Bakalis | Systems and methods for secure access to property or information using blockchain |
US11257098B2 (en) | 2018-03-28 | 2022-02-22 | Konstantinos Bakalis | Systems and methods for securing communication data and property using blockchain |
US10878429B2 (en) | 2018-03-28 | 2020-12-29 | Konstantinos Bakalis | Systems and methods for using codes and images within a blockchain |
US20220277317A1 (en) * | 2018-03-28 | 2022-09-01 | Konstantinos Bakalis | Systems and methods for securing communication data and property using blockchain |
US20210089673A1 (en) * | 2018-04-02 | 2021-03-25 | Sony Corporation | Information processing apparatus, information processing method, and program |
CN108712257A (en) * | 2018-04-03 | 2018-10-26 | 阿里巴巴集团控股有限公司 | The authentication method and device, electronic equipment of transregional piece of chain |
TWI650991B (en) * | 2018-04-12 | 2019-02-11 | 中華電信股份有限公司 | Non-centralized data certificate and verification system with nfc secure element and method thereof |
WO2019199460A1 (en) * | 2018-04-13 | 2019-10-17 | Regwez, Inc. | Single-device multi-factor authentication system |
US10771239B2 (en) * | 2018-04-18 | 2020-09-08 | International Business Machines Corporation | Biometric threat intelligence processing for blockchains |
WO2020036657A1 (en) | 2018-04-26 | 2020-02-20 | The Assay Depot, Inc. | Decentralized data verification |
EP3785199A4 (en) * | 2018-04-26 | 2022-01-19 | The Assay Depot, Inc. | Decentralized data verification |
CN110400136A (en) * | 2018-04-27 | 2019-11-01 | 腾讯科技(深圳)有限公司 | Account management method, device, server and storage medium based on block chain |
US11233792B2 (en) | 2018-05-02 | 2022-01-25 | Mastercard International Incorporated | Method and system for enhanced login credential security via blockchain |
CN110445612A (en) * | 2018-05-02 | 2019-11-12 | 万事达卡国际公司 | For the method and system via the enhancing logging on authentication safety of block chain |
WO2019214068A1 (en) * | 2018-05-09 | 2019-11-14 | 深圳壹账通智能科技有限公司 | Method and apparatus for verifying users on blockchain system, terminal device, and storage medium |
US10567174B2 (en) * | 2018-05-10 | 2020-02-18 | Alibaba Group Holding Limited | Blockchain data processing methods, apparatuses, processing devices, and systems |
US10693649B2 (en) | 2018-05-10 | 2020-06-23 | Alibaba Group Holding Limited | Blockchain data processing methods, apparatuses, processing devices, and systems |
JP2021523610A (en) * | 2018-05-14 | 2021-09-02 | エヌチェーン ホールディングス リミテッドNchain Holdings Limited | Improved systems and methods for storing, generating and validating tokens used to control access to resources |
JP7414734B2 (en) | 2018-05-14 | 2024-01-16 | エヌチェーン ライセンシング アーゲー | Improved systems and methods for storing, generating and validating tokens used to control access to resources |
US10505737B1 (en) * | 2018-06-04 | 2019-12-10 | Syniverse Technologies, Llc | System and method for blockchain-based consent and campaign management |
WO2020076261A1 (en) * | 2018-06-07 | 2020-04-16 | Elektronik Bilgi Guvenligi Anonim Sirketi | A personal identification method comprising e-signature and blockchain layers |
WO2019241605A1 (en) * | 2018-06-13 | 2019-12-19 | Konstantinos Bakalis | Systems and methods for secure access to property or information using blockchain |
CN108959523A (en) * | 2018-06-28 | 2018-12-07 | 北京首汽智行科技有限公司 | A kind of method for playing music and player based on block chain technology |
US20210294920A1 (en) * | 2018-07-10 | 2021-09-23 | Netmaster Solutions Ltd | A method and system for managing digital evidence using a blockchain |
US11003755B2 (en) * | 2018-07-25 | 2021-05-11 | Capital One Services, Llc | Authentication using emoji-based passwords |
US10489578B1 (en) * | 2018-07-25 | 2019-11-26 | Capital One Services, Llc | Authentication using emoji-based passwords |
CN109067521A (en) * | 2018-07-27 | 2018-12-21 | 天津大学 | A kind of public key distribution method based on block chain |
US11811758B1 (en) | 2018-08-01 | 2023-11-07 | United Services Automobile Association (Usaa) | Systems and methods for electronic enrollment and authentication |
US11611555B1 (en) | 2018-08-01 | 2023-03-21 | United Services Automobile Association (Usaa) | Systems and methods for electronic enrollment and authentication |
US11297056B1 (en) * | 2018-08-01 | 2022-04-05 | United Services Automobile Association (Usaa) | Systems and methods for electronic enrollment and authentication |
US11580002B2 (en) | 2018-08-17 | 2023-02-14 | Intensity Analytics Corporation | User effort detection |
US10951395B2 (en) * | 2018-08-20 | 2021-03-16 | Fujitsu Limited | Data fetching in data exchange networks |
US20200059353A1 (en) * | 2018-08-20 | 2020-02-20 | Fujitsu Limited | Data fetching in data exchange networks |
US20200296091A1 (en) * | 2018-08-28 | 2020-09-17 | Ofer A. LIDSKY | Systems and methods for user authentication based on a genetic sequence |
US11700249B2 (en) * | 2018-08-28 | 2023-07-11 | Ofer A. LIDSKY | Systems and methods for user authentication based on a genetic sequence |
US20210192012A1 (en) * | 2018-09-07 | 2021-06-24 | Nippon Telegraph And Telephone Corporation | Right holder terminal, user terminal, right holder program, user program, content utilization system, and content utilization method |
US11538063B2 (en) | 2018-09-12 | 2022-12-27 | Samsung Electronics Co., Ltd. | Online fraud prevention and detection based on distributed system |
US11128456B2 (en) * | 2018-09-19 | 2021-09-21 | Cisco Technology, Inc. | Assured transport of data over a network |
CN109272310A (en) * | 2018-09-27 | 2019-01-25 | 北京金山安全软件有限公司 | Two-dimensional code generation method and device and electronic equipment |
US10268817B1 (en) * | 2018-10-05 | 2019-04-23 | Capital One Services, Llc | Methods, mediums, and systems for establishing and using security questions |
US20210294890A1 (en) * | 2018-10-05 | 2021-09-23 | Capital One Services, Llc | Methods, mediums, and systems for establishing and using security questions |
US11790077B2 (en) * | 2018-10-05 | 2023-10-17 | Capital One Services, Llc | Methods, mediums, and systems for establishing and using security questions |
US10482236B1 (en) * | 2018-10-05 | 2019-11-19 | Capital One Services, Llc | Methods, mediums, and systems for establishing and using security questions |
US20200117791A1 (en) * | 2018-10-16 | 2020-04-16 | International Business Machines Corporation | Consented authentication |
US10943003B2 (en) * | 2018-10-16 | 2021-03-09 | International Business Machines Corporation | Consented authentication |
US10944565B2 (en) | 2018-10-16 | 2021-03-09 | International Business Machines Corporation | Consented authentication |
US11722301B2 (en) | 2018-10-17 | 2023-08-08 | Ping Identity Corporation | Blockchain ID connect |
US11818265B2 (en) | 2018-10-17 | 2023-11-14 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US11410480B2 (en) * | 2018-10-31 | 2022-08-09 | Nec Corporation | Information processing apparatus, information processing method, storage medium, and information processing system |
US20220292900A1 (en) * | 2018-10-31 | 2022-09-15 | Nec Corporation | Information processing apparatus, information processing method, storage medium, and information processing system |
US11258612B2 (en) | 2018-10-31 | 2022-02-22 | Advanced New Technologies Co., Ltd. | Method, apparatus, and electronic device for blockchain-based recordkeeping |
US10958438B2 (en) * | 2018-10-31 | 2021-03-23 | Advanced New Technologies Co., Ltd. | Method, apparatus, and electronic device for blockchain-based recordkeeping |
US11681551B2 (en) | 2018-11-07 | 2023-06-20 | Ebay Inc. | Resource trust model for securing component state data for a resource using blockchains |
US11188384B2 (en) | 2018-11-07 | 2021-11-30 | Ebay Inc. | Resource trust model for securing component state data for a resource using blockchains |
US20200153814A1 (en) * | 2018-11-08 | 2020-05-14 | International Business Machines Corporation | Method for authentication with identity providers |
US11050550B2 (en) * | 2018-11-27 | 2021-06-29 | Advanced New Technologies Co., Ltd. | Methods and systems for reading data based on plurality of blockchain networks |
CN111294323A (en) * | 2018-12-10 | 2020-06-16 | 成都高新信息技术研究院 | Decentralized mobile subscriber identification method and system |
CN109413102A (en) * | 2018-12-10 | 2019-03-01 | 北京八分量信息科技有限公司 | Accreditation System, method and block chain deposit system based on zero-knowledge proof |
CN109617692A (en) * | 2018-12-13 | 2019-04-12 | 郑州师范学院 | A kind of anonymous login method and system based on block chain |
US11025430B2 (en) * | 2018-12-20 | 2021-06-01 | International Business Machines Corporation | File provenance database system |
US11151236B2 (en) * | 2018-12-20 | 2021-10-19 | International Business Machines Corporation | File verification database system |
US11139960B2 (en) * | 2018-12-20 | 2021-10-05 | International Business Machines Corporation | File redaction database system |
US20200211305A1 (en) * | 2019-01-02 | 2020-07-02 | International Business Machines Corporation | Authorized access evaluation and remediation system |
CN109951448A (en) * | 2019-01-31 | 2019-06-28 | 中国互联网络信息中心 | Domain name authentic authentication method and device based on block chain |
US11240027B2 (en) * | 2019-02-04 | 2022-02-01 | Hewlett Packard Enterprise Development Lp | Synchronizing radius server databases using distributed ledger network |
US10530577B1 (en) * | 2019-02-08 | 2020-01-07 | Talenting, Inc. | Systems and methods for biometric key generation in data access control, data verification, and path selection in block chain-linked workforce data management |
KR20200105998A (en) * | 2019-02-28 | 2020-09-10 | 알리바바 그룹 홀딩 리미티드 | System and method for blockchain-based data management |
US11888992B2 (en) | 2019-02-28 | 2024-01-30 | Advanced New Technologies Co., Ltd. | System and method for generating digital marks |
EP3913890A1 (en) * | 2019-02-28 | 2021-11-24 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based authentication |
WO2019101225A2 (en) | 2019-02-28 | 2019-05-31 | Alibaba Group Holding Limited | System and method for blockchain-based data management |
US11258778B2 (en) * | 2019-02-28 | 2022-02-22 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based data management |
CN110771120A (en) * | 2019-02-28 | 2020-02-07 | 阿里巴巴集团控股有限公司 | System and method for blockchain based authentication |
EP3596906A4 (en) * | 2019-02-28 | 2020-05-06 | Alibaba Group Holding Limited | System and method for blockchain-based authentication |
KR102236341B1 (en) * | 2019-02-28 | 2021-04-06 | 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. | System and method for blockchain-based data management |
EP3602457A4 (en) * | 2019-02-28 | 2020-05-27 | Alibaba Group Holding Limited | System and method for blockchain-based data management |
US10425230B1 (en) * | 2019-03-01 | 2019-09-24 | Capital One Services, Llc | Identity and electronic signature verification in blockchain |
US20200280558A1 (en) * | 2019-03-01 | 2020-09-03 | Carrier Corporation | Unlocking method and system for air conditioner unit |
US11606354B2 (en) * | 2019-03-01 | 2023-03-14 | Carrier Corporation | Unlocking method and system for air conditioner unit |
US11348104B2 (en) * | 2019-03-14 | 2022-05-31 | Advanced New Technologies Co., Ltd. | Methods and devices for acquiring and recording tracking information on blockchain |
US10805294B1 (en) * | 2019-03-22 | 2020-10-13 | Trace, LLC | Systems and methods for validating device permissions of computing devices to execute code on a decentralized database |
US11983290B2 (en) | 2019-03-28 | 2024-05-14 | Nec Corporation | Method and distributed ledger system for supporting identity management of travelers in an airport |
US11748687B2 (en) | 2019-03-28 | 2023-09-05 | Ebay Inc. | Dynamically generating visualization data based on shipping events |
US11379785B2 (en) | 2019-03-28 | 2022-07-05 | Ebay Inc. | Decentralized shipping network using blockchains |
US11449819B2 (en) | 2019-03-28 | 2022-09-20 | Ebay Inc. | Blockchain-based authentication and authorization |
US11651321B2 (en) | 2019-03-28 | 2023-05-16 | Ebay Inc. | Secure shipping interactions using blockchains |
JP2022526505A (en) * | 2019-03-28 | 2022-05-25 | エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー | Methods and distributed ledger systems to support traveler identity verification management at airports |
US11842317B2 (en) | 2019-03-28 | 2023-12-12 | Ebay Inc. | Blockchain-based authentication and authorization |
EP3948631A4 (en) * | 2019-03-28 | 2022-12-21 | BankVault Pty Ltd | Computer systems and methods including html browser authorisation approaches |
US20220150228A1 (en) * | 2019-03-28 | 2022-05-12 | Bankvault Pty Ltd | Computer systems and methods including html browser authorisation approaches |
JP7317137B2 (en) | 2019-03-28 | 2023-07-28 | エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー | Method and Distributed Ledger System for Supporting Identity Verification Management of Travelers in Airports |
US11468390B2 (en) | 2019-03-28 | 2022-10-11 | Ebay Inc. | Secure shipping interactions using blockchains |
WO2020192948A1 (en) * | 2019-03-28 | 2020-10-01 | NEC Laboratories Europe GmbH | Method and distributed ledger system for supporting identity management of travelers in an airport |
CN109981675A (en) * | 2019-04-04 | 2019-07-05 | 西安电子科技大学 | A kind of identity information guard method of digital identification authentication and encryption attribute |
US11528139B2 (en) | 2019-04-08 | 2022-12-13 | Mastercard International Incorporated | Systems and methods relating to identity authentication and validation |
US11924347B2 (en) | 2019-04-08 | 2024-03-05 | Mastercard International Incorporated | Identity authentication and validation |
US10664877B1 (en) * | 2019-04-08 | 2020-05-26 | Alibaba Group Holding Limited | Product promotion using smart contracts in blockchain networks |
US20200327556A1 (en) * | 2019-04-12 | 2020-10-15 | Salesforce.Com, Inc. | Method to accept certifications with blockchain transactions |
US11283622B2 (en) * | 2019-04-18 | 2022-03-22 | Advanced New Technologies Co., Ltd. | Signature verification for a blockchain ledger |
US11057220B2 (en) | 2019-04-18 | 2021-07-06 | Advanced New Technologies Co., Ltd. | Signature verification for a blockchain ledger |
US11070379B2 (en) * | 2019-04-18 | 2021-07-20 | Advanced New Technologies Co., Ltd. | Signature verification for a blockchain ledger |
US11163884B2 (en) | 2019-04-26 | 2021-11-02 | Forcepoint Llc | Privacy and the adaptive trust profile |
US10853496B2 (en) | 2019-04-26 | 2020-12-01 | Forcepoint, LLC | Adaptive trust profile behavioral fingerprint |
US10997295B2 (en) | 2019-04-26 | 2021-05-04 | Forcepoint, LLC | Adaptive trust profile reference architecture |
US11477190B2 (en) * | 2019-05-01 | 2022-10-18 | Salesforce, Inc. | Dynamic user ID |
CN110211263A (en) * | 2019-05-23 | 2019-09-06 | 烽火通信科技股份有限公司 | A kind of intelligent door method for unlocking and system based on block chain technology |
US11176352B2 (en) | 2019-06-03 | 2021-11-16 | Advanced New Technologies Co., Ltd. | Method and apparatus for processing and generating offline graphic code |
US10943087B2 (en) | 2019-06-03 | 2021-03-09 | Advanced New Technologies Co., Ltd | Method and apparatus for processing and generating offline graphic code |
US11196561B2 (en) | 2019-06-04 | 2021-12-07 | Capital One Services, Llc | Authorized data sharing using smart contracts |
US11200334B2 (en) | 2019-06-04 | 2021-12-14 | Capital One Services, Llc | Data sharing via distributed ledgers |
US11829502B2 (en) | 2019-06-04 | 2023-11-28 | Capital One Services, Llc | Data sharing via distributed ledgers |
US10474834B1 (en) | 2019-06-04 | 2019-11-12 | Capital One Services, Llc | Data sharing via distributed ledgers |
US10554406B1 (en) | 2019-06-04 | 2020-02-04 | Capital One Services, Llc | Authorized data sharing using smart contracts |
US11941093B2 (en) * | 2019-06-21 | 2024-03-26 | Early Warning Services, Llc | Digital identity sign-in |
US11900453B2 (en) * | 2019-06-21 | 2024-02-13 | Early Warning Services, Llc | Digital identity sign-in |
US11438331B1 (en) * | 2019-06-21 | 2022-09-06 | Early Warning Services, Llc | Digital identity sign-in |
US10728042B2 (en) | 2019-07-02 | 2020-07-28 | Alibaba Group Holding Limited | System and method for blockchain-based cross-entity authentication |
US10708060B2 (en) | 2019-07-02 | 2020-07-07 | Alibaba Group Holding Limited | System and method for blockchain-based notification |
US11082233B2 (en) | 2019-07-02 | 2021-08-03 | Advanced New Technologies Co., Ltd. | System and method for issuing verifiable claims |
US10938562B2 (en) | 2019-07-02 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for creating decentralized identifiers |
US10938551B2 (en) | 2019-07-02 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for implementing a resolver service for decentralized identifiers |
US10700851B2 (en) | 2019-07-02 | 2020-06-30 | Alibaba Group Holding Limited | System and method for implementing a resolver service for decentralized identifiers |
US10685099B2 (en) * | 2019-07-02 | 2020-06-16 | Alibaba Group Holding Limited | System and method for mapping decentralized identifiers to real-world entities |
US11171789B2 (en) | 2019-07-02 | 2021-11-09 | Advanced New Technologies Co., Ltd. | System and method for implementing a resolver service for decentralized identifiers |
US10938569B2 (en) | 2019-07-02 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for verifying verifiable claims |
US11165576B2 (en) | 2019-07-02 | 2021-11-02 | Advanced New Technologies Co., Ltd. | System and method for creating decentralized identifiers |
US10924284B2 (en) | 2019-07-02 | 2021-02-16 | Advanced New Technologies Co., Ltd. | System and method for decentralized-identifier authentication |
US11025435B2 (en) | 2019-07-02 | 2021-06-01 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based cross-entity authentication |
US11316697B2 (en) | 2019-07-02 | 2022-04-26 | Advanced New Technologies Co., Ltd. | System and method for issuing verifiable claims |
US10917246B2 (en) | 2019-07-02 | 2021-02-09 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based cross-entity authentication |
US11159526B2 (en) | 2019-07-02 | 2021-10-26 | Advanced New Technologies Co., Ltd. | System and method for decentralized-identifier authentication |
US11477032B2 (en) | 2019-07-02 | 2022-10-18 | Advanced New Technologies Co., Ltd. | System and method for decentralized-identifier creation |
US11038883B2 (en) | 2019-07-02 | 2021-06-15 | Advanced New Technologies Co., Ltd. | System and method for decentralized-identifier creation |
US10756885B2 (en) | 2019-07-02 | 2020-08-25 | Alibaba Group Holding Limited | System and method for blockchain-based cross entity authentication |
US11277268B2 (en) | 2019-07-02 | 2022-03-15 | Advanced New Technologies Co., Ltd. | System and method for verifying verifiable claims |
US11316698B2 (en) * | 2019-07-17 | 2022-04-26 | Guardtime Sa | Delegated signatures for smart devices |
US11615174B2 (en) | 2019-08-30 | 2023-03-28 | Biocube Technologies Inc | Method and a system to locally store and authenticate a data of a user |
WO2021040833A1 (en) | 2019-08-30 | 2021-03-04 | Liveramp, Inc. | Connecting web publisher inventory to programmatic exchanges without third-party cookies |
WO2021042086A1 (en) * | 2019-08-30 | 2021-03-04 | Biocube Matrics Pte Limited | A method and a system to locally store and authenticate a data of a user |
US11080240B2 (en) * | 2019-09-12 | 2021-08-03 | Vijay Madisetti | Method and system for real-time collaboration and annotation-based action creation and management |
US11734262B2 (en) | 2019-09-23 | 2023-08-22 | Trace Labs Llc | Systems and methods for writing updates to and/or reading previously stored updates of assets implemented as smart contracts on a decentralized database |
US11294889B2 (en) | 2019-09-23 | 2022-04-05 | Trace, LLC | Systems and methods for writing updates to and/or reading previously stored updates of assets implemented as smart contracts on a decentralized database |
US11405188B2 (en) * | 2019-09-30 | 2022-08-02 | Coinfirm Limited | Method for secure transferring of information through a network between an origin virtual asset service provider and a destination virtual asset service provider |
US11841960B1 (en) * | 2019-11-26 | 2023-12-12 | Gobeep, Inc. | Systems and processes for providing secure client controlled and managed exchange of data between parties |
US12032634B1 (en) | 2019-12-23 | 2024-07-09 | Lacework Inc. | Graph reclustering based on different clustering criteria |
US11831668B1 (en) | 2019-12-23 | 2023-11-28 | Lacework Inc. | Using a logical graph to model activity in a network environment |
US11770464B1 (en) | 2019-12-23 | 2023-09-26 | Lacework Inc. | Monitoring communications in a containerized environment |
US11954130B1 (en) | 2019-12-23 | 2024-04-09 | Lacework Inc. | Alerting based on pod communication-based logical graph |
US11475453B2 (en) | 2019-12-31 | 2022-10-18 | Capital One Services, Llc | System and techniques for utilizing a smart contracts library |
US11146386B2 (en) * | 2020-01-17 | 2021-10-12 | Agile Blockchain Corp. | Method and system for authentication seal deployment in networked immutable transactions |
WO2021150032A1 (en) * | 2020-01-22 | 2021-07-29 | Coinplug, Inc. | Method for providing authentication service by using decentralized identity and server using the same |
US11012233B1 (en) * | 2020-01-22 | 2021-05-18 | Coinplug, Inc. | Method for providing authentication service by using decentralized identity and server using the same |
WO2021175409A1 (en) * | 2020-03-02 | 2021-09-10 | NEC Laboratories Europe GmbH | Method for supporting sharing of travel history of travelers in airports |
WO2021175410A1 (en) * | 2020-03-02 | 2021-09-10 | NEC Laboratories Europe GmbH | Method for supporting sharing of travel history of travelers in airports |
US11368289B1 (en) | 2020-04-06 | 2022-06-21 | Bank Of America Corporation | Video registration and authentication using blockchain |
WO2021226854A1 (en) * | 2020-05-09 | 2021-11-18 | 杭州安存网络科技有限公司 | Blockchain machine, blockchain data access authentication method, and computer-readable storage medium |
US11818259B2 (en) | 2020-05-13 | 2023-11-14 | Ridgeline, Inc. | Query and projection processing for events |
US20210359852A1 (en) * | 2020-05-13 | 2021-11-18 | Ridgeline, Inc. | Auditing for events |
US11943344B2 (en) | 2020-05-13 | 2024-03-26 | Ridgeline, Inc. | Mutation processing for events |
US11949784B2 (en) * | 2020-05-13 | 2024-04-02 | Ridgeline, Inc. | Auditing for events |
US11972440B1 (en) * | 2020-06-05 | 2024-04-30 | Trace Labs Llc | Systems and methods for providing a decentralized anti-counterfeit solution for supply chain tracking using single-use codes |
US20220278844A1 (en) * | 2020-07-30 | 2022-09-01 | Dapper Labs, Inc. | Systems and methods providing specialized proof of confidential knowledge |
US11824990B2 (en) * | 2020-07-30 | 2023-11-21 | Dapper Labs, Inc. | Systems and methods providing specialized proof of confidential knowledge |
US11394550B2 (en) * | 2020-07-30 | 2022-07-19 | Dapper Labs Inc. | Systems and methods providing specialized proof of confidential knowledge |
US20230163955A1 (en) * | 2020-08-21 | 2023-05-25 | Almond Inc. | Encryption method, terminal device, encryption system, and program |
US11368456B2 (en) * | 2020-09-11 | 2022-06-21 | Bank Of America Corporation | User security profile for multi-media identity verification |
US11356266B2 (en) * | 2020-09-11 | 2022-06-07 | Bank Of America Corporation | User authentication using diverse media inputs and hash-based ledgers |
CN112822172A (en) * | 2020-12-31 | 2021-05-18 | 咪咕文化科技有限公司 | Login verification method and device, electronic equipment and storage medium |
US11170130B1 (en) | 2021-04-08 | 2021-11-09 | Aster Key, LLC | Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification |
US11811930B2 (en) * | 2021-08-31 | 2023-11-07 | Microsoft Technology Licensing, Llc | Authentication of communication session participants using blockchain |
US20230065364A1 (en) * | 2021-08-31 | 2023-03-02 | Microsoft Technology Licensing, Llc | Authentication of communication session participants using blockchain |
CN113609463A (en) * | 2021-10-08 | 2021-11-05 | 湖南宸瀚信息科技有限责任公司 | Internet of things system based on block chain identity management |
US20230145040A1 (en) * | 2021-11-09 | 2023-05-11 | Actv8, Inc. | Method and apparatus for using a single qr code to provide varying user experiences |
US11977796B2 (en) * | 2022-03-09 | 2024-05-07 | Fujifilm Corporation | Content provision device, content provision method, program, and recording medium |
WO2023177480A1 (en) * | 2022-03-15 | 2023-09-21 | Quotient Partners, Llc | Distributed identity management for a decentralized platform |
CN114884736A (en) * | 2022-05-11 | 2022-08-09 | 山东鲁软数字科技有限公司 | Anti-explosion attack safety protection method and device |
FR3136329A1 (en) * | 2022-06-01 | 2023-12-08 | Orange | Method and device for registering a user with a telecommunications operator. |
Also Published As
Publication number | Publication date |
---|---|
EP4027254A2 (en) | 2022-07-13 |
US20220078178A1 (en) | 2022-03-10 |
US11658961B2 (en) | 2023-05-23 |
EP3424179B1 (en) | 2022-02-16 |
EP3424179A1 (en) | 2019-01-09 |
EP4027254A3 (en) | 2022-10-05 |
US11134075B2 (en) | 2021-09-28 |
US20190149537A1 (en) | 2019-05-16 |
US10587609B2 (en) | 2020-03-10 |
EP3424179A4 (en) | 2019-11-27 |
WO2017152150A1 (en) | 2017-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11658961B2 (en) | Method and system for authenticated login using static or dynamic codes | |
US11722301B2 (en) | Blockchain ID connect | |
US11799668B2 (en) | Electronic identification verification methods and systems with storage of certification records to a side chain | |
US11777726B2 (en) | Methods and systems for recovering data using dynamic passwords | |
US11082221B2 (en) | Methods and systems for creating and recovering accounts using dynamic passwords | |
US20220255931A1 (en) | Domain unrestricted mobile initiated login | |
US10742634B1 (en) | Methods for single sign-on (SSO) using optical codes | |
US10523441B2 (en) | Authentication of access request of a device and protecting confidential information | |
US7409543B1 (en) | Method and apparatus for using a third party authentication server | |
WO2018145127A1 (en) | Electronic identification verification methods and systems with storage of certification records to a side chain | |
WO2019020051A1 (en) | Method and apparatus for security authentication | |
US10848304B2 (en) | Public-private key pair protected password manager | |
JP2016502377A (en) | How to provide safety using safety calculations | |
WO2019226115A1 (en) | Method and apparatus for user authentication | |
US20240005820A1 (en) | Content encryption and in-place decryption using visually encoded ciphertext | |
US20220417020A1 (en) | Information processing device, information processing method, and non-transitory computer readable storage medium | |
KR102123405B1 (en) | System and method for providing security membership and login hosting service | |
WO2022140469A1 (en) | Domain unrestricted mobile initiated login | |
USRE49968E1 (en) | Electronic identification verification methods and systems with storage of certification records to a side chain | |
TWI704795B (en) | Login authentication method | |
Pinkas | An eID mechanism built along privacy by design principles using secure elements, pseudonyms and attributes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SHOCARD, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EBRAHIMI, ARMIN;KHOT, GAURAV;RESHETNIKOV, VLADIMIR;AND OTHERS;SIGNING DATES FROM 20170307 TO 20170311;REEL/FRAME:041586/0491 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, TEXAS Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:SHOCARD, LLC;REEL/FRAME:052291/0082 Effective date: 20200401 |
|
AS | Assignment |
Owner name: SHOCARD, LLC, COLORADO Free format text: CHANGE OF NAME;ASSIGNOR:SHOCARD, INC.;REEL/FRAME:052435/0009 Effective date: 20200302 |
|
AS | Assignment |
Owner name: PING IDENTITY CORPORATION, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHOCARD, LLC;REEL/FRAME:052889/0793 Effective date: 20200505 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: SECURITY INTEREST;ASSIGNOR:PING IDENTITY CORPORATION;REEL/FRAME:058944/0687 Effective date: 20211123 Owner name: SHOCARD, LLC, COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:058195/0683 Effective date: 20211123 |
|
AS | Assignment |
Owner name: OWL ROCK CAPITAL CORPORATION, AS COLLATERAL AGENT, NEW YORK Free format text: GRANT OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:PING IDENTITY CORPORATION;REEL/FRAME:061703/0988 Effective date: 20221018 |
|
AS | Assignment |
Owner name: PING IDENTITY CORPORATION, COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:061709/0527 Effective date: 20221018 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |