HK1252700B - Methods and systems for identity creation, verification and management - Google Patents

Description

Method and system for creating, verifying and managing identities

Cross Reference to Related Applications

This application claims priority from U.S. provisional patent application No. 62/270,658 filed on 22/12/2015 and U.S. patent application No. 15/283,993 filed on 3/10/2016, each of which is incorporated herein by reference in its entirety.

Background

Identity providers publish identities for personal identification for various purposes. For example, state agencies issue driver licenses or passports to individuals for use by law enforcement personnel in identifying such individuals, accessing nationally provided services and systems, exercising rights, and the like.

Different identity providers use different methods to provide identity. National agencies typically provide identities for citizens of particular jurisdictions based on verifying the citizen's identity. Employers typically provide identities to employees to provide selective access to facilities, benefits, etc., based on employee information. The consumer services company may provide an identity to the consumer based on the consumer information to provide selective access to these services.

Identities can take a variety of forms, from traditional physical representations (such as cards or other files) to digital representations (such as usernames, passwords, etc.). For example, national institutions often provide cards, documents, or other tangible items that are then physically presented by individuals to gain access to a service or system. The computing service company may provide a username, password, etc., that the individual presents via the communication interface to access the service.

Various third parties also rely on identities provided by identity providers to selectively authorize access to their services and systems. For example, hotels, car rental companies, etc. often require individuals to provide valid, nationally issued identities before a rental occurs. Such third parties implement a variety of different processes to verify the validity and qualification of an identity, such as from verifying the mere presence of a physical identity to a more detailed visual inspection, such as including inspecting expected elements, etc.

However, there are a number of problems with providing and using identities. The traditional nature of some existing identity and authorization procedures presents a risk of fraud as the development of technology proves more and more effective in counterfeiting such identities. For example, traditional identification cards, documents, etc., even if they contain anti-counterfeiting measures (such as incorporated logos, holograms, etc.), are increasingly being successfully duplicated by modern technology. Even digital identities are vulnerable to attack by the corresponding digital technology.

The wide variety of identities, identity providers, and third party systems also result in a highly differentiated identity environment. Individuals often need to interact with a large number of identity providers to create a corresponding number of identities, which individuals must then maintain and provide to a number of different third parties in different ways. Likewise, many third parties consider it necessary to accept a variety of different identities and then provide corresponding authentication mechanisms for the various identities. This sporadic identity environment creates inefficiencies in the production and use of identities by individuals and third parties.

Accordingly, there is a need for an apparatus, system, and method of creating, verifying, and maintaining identities with enhanced security and efficiency.

Drawings

In order to be able to understand the features of the present invention, a number of figures are described below. The drawings illustrate only certain embodiments of the invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

Fig. 1 is a schematic diagram depicting an embodiment of a system for providing identity services.

Fig. 2 is a schematic diagram depicting an embodiment of a centralized identity system.

FIG. 3 is a schematic diagram depicting an embodiment of a distributed identity element library.

Figure 4 is a schematic diagram depicting an embodiment of a distributed intelligent contract system node.

Figure 5 is a flow diagram depicting an embodiment of a method of providing identity services.

Fig. 6 is a flow diagram depicting an embodiment of a method of publishing an identity services contract to a blockchain of a distributed identity element library.

FIG. 7 is a schematic diagram depicting an embodiment of an identity services contract.

Fig. 8 is a schematic diagram depicting an embodiment of a blockchain of a distributed identity element library after incorporating a transaction that issues an identity services contract into the blockchain.

FIG. 9 is a flow diagram depicting an embodiment of a method of creating an identity within a centralized identity system.

10A-10C depict embodiments of user interfaces of an identity provider interface module of a centralized identity system.

Fig. 11 is a schematic diagram depicting an embodiment of a blockchain of a distributed identity element library after incorporating a transaction that creates an identity into the blockchain.

FIG. 12 is a flow diagram depicting an embodiment of a method of adding metadata associated with an identity within a centralized identity system.

FIG. 13 is a schematic diagram depicting an embodiment of an architecture of an identity services contract.

FIG. 14 is a schematic diagram depicting another embodiment of an architecture of an identity services contract.

FIG. 15 is a schematic diagram depicting another embodiment of an architecture of an identity services contract.

FIG. 16 is a schematic diagram depicting another embodiment of an architecture of an identity services contract.

FIG. 17 is a flow chart depicting an embodiment of a method of verifying an identity of an individual.

FIG. 18 is a schematic diagram depicting an embodiment of a system for providing identity services in the context of government identity checks.

FIG. 19 is a flow chart depicting another embodiment of a method of verifying the identity of an individual.

FIG. 20 is a schematic diagram depicting an embodiment of a blockchain of a distributed identity element library after incorporating an authenticated transaction into the blockchain.

21A-21C depict embodiments of a user interface of a limited access system interface module of a centralized identity system.

FIG. 22 is a flow chart depicting another embodiment of a method of verifying the identity of an individual.

Figure 23 is an illustration depicting an embodiment of a system for providing identity services in the context of a hotel.

FIG. 24 is a flow diagram depicting an embodiment of a method of reading metadata associated with an identity in a centralized identity system.

FIG. 25 is a schematic diagram depicting an embodiment of a system for providing identity services in the context of a financial transaction environment.

FIG. 26 is a flow diagram depicting an embodiment of providing financial transaction identity services.

Detailed Description

Embodiments of the centralized identity system may create, verify, and manage identities within the identity element repository of the system to improve security. Centralized identity systems may also provide an identity federation approach in which identities and identity services may be used across multiple different identity providers and limited access systems, thereby improving efficiency.

Identities corresponding to identities issued by identity providers may be created within a centralized identity system. An embodiment of a method of creating an identity within a centralized identity system may include receiving identity data from an identity provider and generating one or more transactions to store an identifier representing the identity data in a repository of identity elements. The identifier stored in the repository may comprise a cryptographically encoded representation of at least a portion of the identity data. In an embodiment, the identity element library may comprise a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, and the transaction may be transmitted to at least one node of the distributed system to store the identifier on a blockchain of the distributed system or to invoke an identity data creation function of an identity service contract stored in the blockchain to store the identifier.

Creating an identity within the centralized identity system may also include generating an identity token corresponding to the identity for distribution to individuals for invoking access to the limited-access system. The identity token may include one or more components configured to trigger an authentication process of the centralized identity system or the limited access system. An individual may use an identity user system, such as a mobile device, to store and submit an identity token to a restricted access system.

Metadata may also be stored in association with the identity within the centralized identity system. The metadata may relate to, for example, an identity provided by the individual or an identity provider for the individual. The metadata may be used to provide a verification function, a data storage function, etc. associated with the identity. An embodiment of a method of adding metadata associated with an identity within a centralized identity system may include receiving metadata and an identifier of the identity, and generating one or more transactions to store the metadata in association with the identifier in a repository of identity elements. In embodiments, the transaction may be transmitted to at least one node of the distributed system to store the metadata on a blockchain of the system in association with the identifier or to invoke a metadata function of the identity services contract to store the metadata on the blockchain.

Identities within a centralized identity system may be verified in an improved manner to enhance security and prevent identity fraud. Embodiments of a method of verifying identity may include receiving an identity token provided by an individual, extracting an identifier from the identity token, and generating a transaction to determine whether the identifier is stored in an identity element repository. In embodiments, the transaction may be transmitted to at least one node of the distributed system to determine whether the identifier is present on a blockchain of the system, or may be determined by invoking an identity verification function of an identity service contract stored on the blockchain. A corresponding method of providing access to a limited access system may comprise granting or denying access to the limited access system in dependence on the result of the verification.

A multi-factor authentication process may also be provided to further enhance the security and effectiveness of authentication. Embodiments of multi-factor authentication may include authenticating identities in a centralized identity system and physically authenticating individuals who provide identity tokens. The method may include receiving an identity token from an individual, verifying a corresponding identity within a centralized identity system, determining a physical characteristic of the individual, and verifying the physical characteristic against the individual. In an embodiment, determining the physical characteristic of the person may comprise extracting data related to the person from the identity token. A corresponding method of providing access to a restricted access system may comprise granting or denying access to the restricted access system in dependence on the results of these verifications.

A multi-stage authentication process may also be provided. Embodiments of a multi-stage verification process may include an initial relatively more stringent verification stage followed by a relatively less stringent verification stage. The initial authentication may include embodiments that one or more of authenticate the identity within the centralized identity system or perform multi-factor authentication, etc. Based on the initial authentication, initial access to the restricted access system may be granted or denied. For subsequent verification, a simplified verification may be performed, e.g. a single factor verification only, such as a verification against the physical properties of the individual. Access to the restricted access system may then be granted or denied depending on the results.

In embodiments, identity service contracts may be stored in blockchains of a distributed identity element library to implement one or more identity and metadata creation, verification, and retrieval functions, and the like. Embodiments of a method of issuing identity service contracts within a distributed identity library module may include generating a compiled identity service contract, generating one or more transactions to issue the identity service contract to a blockchain of the distributed identity element library, and distributing the generated transactions to at least one node of the distributed identity element library.

An embodiment of a method of retrieving metadata associated with an identity in a centralized identity system may include invoking a metadata read function of an identity services contract.

Embodiments of the non-transitory machine-readable storage medium may include program instructions that, when executed by a processor, perform embodiments of the method of providing identity services discussed herein.

Embodiments of the centralized identity system may include a processor and a non-transitory machine-readable storage medium having program instructions that, when executed by the processor, perform embodiments of the method of providing identity services discussed herein.

Fig. 1 depicts an embodiment of a system 20 for providing identity services in an improved manner. The system may include a centralized identity system 24, one or more identity provider systems 28, one or more identity user systems 32, and one or more restricted access systems 36.

Centralized identity system 24 may provide identity services to one or more of identity provider system 28, restricted access system 36, or identity user system 32. To provide services such as identity creation, identity management, etc., centralized identity system 24 may receive identity data from identity provider system 28 and generate and store corresponding identities. To provide services such as authentication, data retrieval, etc., centralized identity system 24 may receive a service request from limited access system 36 and provide corresponding data to limited access system 36. To provide services such as identity access, identity management, etc., centralized identity system 24 may store and provide identity data for identity user system 32.

The identity provider system, the limited access system, and the identity user system may interface with a centralized identity system to request, receive, or otherwise participate in identity services, and the like. For example, identity provider system 28 may generate an identity for an individual and provide identity data representing the generated identity to centralized identity system 24. Restricted access system 36 may receive a representation of an identity token from an individual requesting access to restricted access system 36 and submit a request to centralized identity system 24 to verify the corresponding identity. The identity user system 32 may receive an identity token representing the generated identity and submit the identity token to the restricted access system 36 to request access to the system 36.

Centralized identity system 24, identity provider system 28, limited access system 36, and identity user system 32 may each be owned, operated, and/or located by different entities. For example, centralized identity system 24 may be owned, operated, and/or located by a first entity (such as a company that provides federated identity services to one or more of identity providers, individuals, or third parties, etc.). Identity provider system 28 may be owned, operated and/or located by a second entity, such as a government entity, corporation or other entity that provides an identity to an individual. The restricted access system 36 may be owned, operated and/or located by a third entity, such as a company or other entity that provides services, products, etc. to an individual based on verification of the individual's identity. An individual receiving an identity from an identity provider and attempting to use the identity may own, operate and/or locate the identity user system 32.

Fig. 2 depicts an embodiment of a centralized identity system 24. Centralized identity system 24 may include an identity provider interface module 40, an identity user interface module 44, a limited access system interface module 48, an identity creation and modification module 52, an identity access and management module 56, an identity verification and access module 60, and an identity library module 66.

Identity provider interface modules, identity user interface modules, and limited access system interface modules 40, 44, 48 may provide an interface for centralized identity system 24 to receive information from, and provide information to, identity provider systems, identity user systems, and limited access systems 28, 32, 36.

Identity creation and modification module 52 may receive requests from identity provider system 28 regarding the creation or modification of identity data and identity tokens through respective interface modules 40 and run or control the running of corresponding identity data creation and modification functions. The identity access and management module 56 may receive requests from the identity user system 32 relating to accessing or managing identity data through the respective interface module 44 and run or control the running of corresponding identity access and management functions. The authentication and access module 60 may receive requests from the remote access system 36 related to authenticating an identity through the respective interface module 48 and run or control the running of the corresponding authentication function.

The identity library module 66 may provide a data structure to store identity data that may provide secure and reliable authentication and access to the identity data.

In an embodiment, the identity library module 66 may comprise a distributed database, such as a distributed blockchain transaction ledger. In an embodiment, the distributed blockchain transaction ledger may be further configured to execute transactions that include program code, such as configured as a distributed intelligent contract system. Alternatively, the identity library module 66 may include other types of databases, such as distributed databases or non-distributed databases other than a distributed blockchain transaction ledger or a distributed intelligent contract system.

FIG. 3 depicts an embodiment of the identity element library module 66 implemented using a distributed system, such as a distributed blockchain transaction ledger or a distributed intelligent contract system. The distributed identity repository module 66 may include a plurality of distributed system nodes 68. The distributed system nodes 68 may be organized as a peer-to-peer network, wherein each node 68 may be connected to one or more other nodes 68 using a peer-to-peer communication protocol. At least one of the distributed system nodes 68 may also be connected to the identity creation, access and verification modules 52, 56, 60, etc. to provide communication between the distributed identity element repository 66 and these modules 52, 56, 60 to run identity data creation, modification, management, verification and access functions, etc. As a peer-to-peer network, the configuration of connections between various distributed system nodes 68 may change over time according to the operation of a peer-to-peer protocol.

Fig. 4 depicts an embodiment of a distributed system node 68. Distributed system nodes 68 may include a control communication module 72, a distributed system communication module 76, and one or more distributed system modules. The control communication module 72 may be connected to the identity creation, access and verification module 52, 56, 60, receive control commands from the identity creation, access and verification module 52, 56, 60 and return corresponding data to the identity creation, access and verification module 52, 56, 60. The distributed system communication module 76 may be connected to at least one other distributed system node 68 to provide peer-to-peer communication between the nodes 68. The distributed system modules may include one or more of a block storage module 80, a block creation module 92, a compiler module 84, or a virtual machine module 88. The block storage module 80 may store blocks of the blockchain transaction ledger. The block creation module 92 may execute algorithms to incorporate transactions into blocks of the blockchain transaction ledger, also referred to as mining the blocks of the blockchain, such as by performing cryptographic calculations of a selected difficulty, although other algorithms may also be utilized to achieve new block identity consistency. Compiler module 84 may compile program instructions of a program, script (such as a smart contract), etc. to incorporate transactions into a blockchain transaction ledger. The virtual machine module 88 may execute such compilers, scripts, intelligent contracts, and the like.

In an embodiment, distributed system node 68 may be configured to include only a selected subset of the components depicted in fig. 4. For example, for distributed system nodes 68 that are not directly connected to the function modules 52, 56, 60 of the centralized identity system, the control communication module 72 that receives control commands from these modules may be omitted. Distributed system node 68 may also be configured to perform only a subset of functions run by distributed system modules, such as storing only selected one or more of blocks, creating new blocks, compiling program instructions, or performing compiled program instructions, and the like, and in such embodiments, the node may include only a corresponding one or more of block storage module 80, block creation module 92, compiler module 84, or virtual machine module 88.

The components of centralized identity system 24, identity provider system 28, limited access system 36, and identity user system 32 may be implemented as hardware, software, or a combination of hardware and software. The components of centralized identity system 24, identity provider system 28, limited access system 36, and identity user system 32 may also be implemented using server-side modules, client-side modules, local modules, remote modules, or a combination of these modules.

For example, components of centralized identity system 24, such as any individual one, subset, or all of identity provider interface module 40, identity user interface module 44, limited access system interface module 48, identity creation and modification module 52, identity access and management module 56, identity verification and access module 60, and identity component library module 64, may be implemented using a processor and a non-transitory storage medium, where the non-transitory machine-readable storage medium may include program instructions that, when executed by the processor, may perform embodiments of the functions of such components discussed herein, such as embodiments of methods of creating, modifying, accessing, managing, and verifying identities, etc., as discussed herein. In one embodiment, centralized identity system 24 may include an internet or other communication network based application layer supported by a computing architecture having an identity provider interface module, an identity user interface module, and one or more of restricted access system interface modules 40, 44, 48 to provide access for identity providers, identity users, and third parties to access centralized identity system 24.

The components of identity provider system 28, limited access system 36, and identity user system 32 (such as any individual one, subset, or all of such components) may also be implemented using a processor and a non-transitory machine-readable storage medium, where the non-transitory storage medium may include program instructions that, when executed by the processor, may perform embodiments of the functions of such components discussed herein, such as embodiments of the methods of creating, modifying, accessing, managing, and verifying identities, etc., discussed herein. In one embodiment, the identity provider system 28, the limited access system 36, and the identity user system 32 may include computing systems (such as computer terminals, mobile devices, etc.) to access the internet-based or other communication network portal provided by the centralized identity system.

Fig. 5 depicts an embodiment of a method 500 of providing a centralized identity service to one or more of an identity provider, a person, or a third party limited access system with improved security and efficiency. In embodiments, the method may provide for the creation, modification, verification, etc. of identities within an identity element library, with increased security achieved by greatly increasing the difficulty of counterfeiting such identities. Additionally, in embodiments, the method may provide an identity federation method in which multiple different identity providers, third party limited access systems, and the like may all use the same identity and identity service, improving efficiency by reducing duplications and unnecessary differences in such identities and services.

In an embodiment, the method of providing identity services may be performed by an entity (such as a company), such as by implementing and/or operating an embodiment of centralized identity system 24 to provide centralized identity services to one or more of an identity provider, an individual, or a third party.

The method may begin at step 502. At step 504, the identity element library 64 may be prepared. Preparing the identity element library may include initializing a database to contain the identity data. For example, in embodiments where the identity element repository comprises a distributed system (such as a distributed intelligent contract system), preparing the identity element repository may include publishing an identity services contract to a blockchain, such as discussed below with respect to fig. 6.

At step 506, it may be determined whether a request to generate or modify an identity within centralized identity system 24, such as from an identity provider, has been received. If a request to generate or modify an identity is received, the method can continue to step 508, otherwise the method can continue to step 510.

At step 508, one or more identity creation, modification, etc. functions may be invoked to create or modify identities, corresponding identity tokens, etc. as requested. Centralized identity system 24 may generate, modify, manage, verify identities within the centralized identity system associated with identities generated by identity providers for individuals, such as in response to requests from third parties, with increased security. Centralized identity system 24 may also generate, modify, manage identity tokens associated with identities and identity data. The identity token may be distributed to the individual for invoking an identity and authentication process at the limited access system 36. Creating or modifying the identity data may include calling a function for creating or modifying an identifier representing the identity data within a database of the identity element library. In embodiments where the identity element library comprises a distributed system (such as a distributed blockchain ledger or a distributed intelligent contract system), creating or modifying the identity data within the identity element library may comprise storing or modifying an identifier representing the identity data within a data structure on the blockchain, such as by generating a transaction to store or modify an identifier on the blockchain, or invoking an identity data creation or modification function issued to an identity services contract for the blockchain to store or modify an identifier on the blockchain, for example, as discussed below with respect to fig. 9.

At step 510, it may be determined whether a request, such as from an identity provider, has been received to generate or modify metadata associated with an identity within centralized identity system 24. If a request to generate or modify metadata has been received, the method can continue to step 512, otherwise the method can continue to step 514.

At step 512, one or more of the metadata creation or modification functions may be invoked to create or modify metadata associated with the identity upon request. Centralized identity system 24 may generate, modify, manage, access, etc., metadata associated with the identity that may implement functions or services associated with the identity. Creating or modifying metadata may include calling a function for creating or modifying metadata associated with an identity within a database of an identity element library. In embodiments where the identity element library comprises a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, creating or modifying metadata within the identity element library may comprise storing or modifying metadata within a data structure associated with the identity on the blockchain, such as by generating a transaction or by invoking a metadata creation or modification function of the identity service contract, for example, as discussed below with respect to fig. 12.

At step 514, it may be determined whether a request to verify an identity within the centralized identity system has been received, such as from a limited access system. If a request to verify identity has been received, the method may continue to step 516, otherwise the method may continue to step 518.

At step 516, one or more authentication functions may be invoked to authenticate the identity upon request. The individual may submit one or more of the identity token and the individual's own person to a restricted access system operator to invoke their identity. The identity token may contain information that triggers the authentication process. Verifying the identity may include invoking a function for verifying an identifier representing the identity data within a database of the identity element library. In embodiments where the identity element repository comprises a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, verifying the identity may comprise searching for or reading a data structure on the blockchain that contains identifiers representing the identity data, such as by invoking an identity data verification function of an identity services contract, for example, as discussed further below with respect to fig. 17, 19, and 22.

In addition to verifying the identity within the identity element library, verifying the identity may also include verifying a physical characteristic of the individual, such as providing multi-factor identity verification. In embodiments, physical verification may include determining physical characteristics of the individual, such as by extracting data from the identity token, and verifying the determined characteristics against the individual submitting the identity token, such as discussed further below with respect to fig. 17 and 22.

At step 518, it may be determined whether a request to access metadata associated with an identity within centralized identity system 24 has been received, such as a request from an individual, an identity provider, or a limited access system. If a request to access the metadata has been received, the method can continue to step 520, otherwise the method can continue to step 522.

At step 520, one or more metadata access functions may be invoked to access metadata associated with the identity upon request. Accessing metadata may include invoking a function for accessing metadata associated with an identity stored within a database of the identity element repository. In embodiments where the identity element repository comprises a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, accessing metadata within the identity element repository may comprise searching or reading data structures associated with identifiers representing identity data on the blockchain, such as by invoking a metadata access function of an identity services contract, or the like, over the blockchain, for example, as discussed below with respect to fig. 24.

The determinations in steps 506, 510, 514 and 518 may be performed by the centralized identity system 24, such as by monitoring communications from the identity provider system 28, the identity user system 32 and the limited access system 36 through the identity provider interface module, the identity user interface module and the limited access system interface module 40, 44, 48. Additionally, although fig. 5 depicts one possible order of execution of the determinations in steps 506, 510, 514, and 518, in other embodiments, the determinations in steps 506, 510, 514, and 518 may be performed in any other relative order, simultaneously, or as desired, in response to communications from the identity provider system 28, the identity user system 32, and the limited access system 36, by the identity provider interface module, the identity user interface module, and the limited access system interface module 40, 44, 48.

In step 522, it may be determined whether to continue the determinations in steps 506, 510, 514, and 518. If it is determined to continue, the method may return to any of steps 506, 510, 514, and 518, otherwise the method may perform step 524, where the method ends at step 524.

FIG. 6 depicts an embodiment of a method 600 of publishing an identity service contract into a distributed identity library module. In embodiments where the identity element repository comprises a distributed system, such as a distributed intelligent contract system, embodiments of method 600 may be used to implement step 504 of preparing the identity element repository in method 500 of fig. 5.

The method 600 may begin at step 602. At step 604, parameters defining the functionality of the smart contract may be received. The parameters may include an identification of the identity data, an identification of a function to be implemented by the identity services contract, one or more of a portion of the identity services function to be implemented between the identity service and other intelligent contracts, and so on. The parameters may be received at the centralized identity system from an identity provider or an identity provider system. In embodiments where the functionality of the intelligent contract need not be determined (e.g., where it has been determined or otherwise is consistent with a standard set of functionality), step 604 may be omitted.

At step 606, a compiled identity services contract may be generated. The identity service contract may include program instructions for running one or more of the identity service functions discussed herein. The identity service contract may be programmed in a programming or scripting language supported by a distributed identity element repository, such as compiler module 84 of distributed system node 68 of the distributed identity element repository. The identity service contract may then be compiled using a compiler supported by the distributed identity element repository, such as compiler module 84 of distributed intelligent contract system node 68.

Fig. 7 depicts an embodiment of an identity services contract 100. Identity service contract 100 may include one or more program functions to implement the functionality of the identity service contract described herein. For example, identity services contract 100 may include one or more program functions 104 to create or modify identity data associated with an identity, one or more functions 108 to create or modify metadata associated with an identity, one or more functions 112 to verify the state of an identity, one or more functions 116 to retrieve metadata associated with an identity, and so forth. Identity service contract 100 may also define one or more data structures to store data to implement the functionality of the identity service contract. For example, an identity services contract may define one or more data structures 120 to store identity data, one or more data structures 124 to store metadata.

Returning to FIG. 6, at step 608, one or more transactions may be generated to publish the identity service contract to the blockchain of the distributed identity element repository. The distributed identity element repository may contain an ordered list of transactions in the distributed ledger represented by the blockchain, and where the distributed identity element repository implements a distributed intelligent contract system, the transactions may include intelligent contracts issued for execution by successive transactions. To publish the compiled identity service contract, a transaction may be generated that includes the compiled identity service contract. The transaction may be generated by a centralized identity services system 24, such as by identity creation and modification module 52 of centralized identity services system 24, or by a control communication module or distributed system communication module 72, 76 of one of distributed intelligent contract system nodes 68 (e.g., local) that is directly connected to such a module.

At step 610, the generated transaction containing the compiled identity service contract may be transmitted to at least one of the distributed system nodes 68 of the distributed identity element repository 66. The transaction may be sent to at least one node through one of the distributed system nodes 68 (e.g., local) that is directly connected to the identity creation and modification module 52 of the centralized identity system 24. Sending the transaction to at least one distributed system node 68 may trigger the transaction involved in the process by one or more of the distributed system nodes 68 to incorporate a new set of transactions into blocks in a blockchain stored by the nodes of the distributed identity element repository. The process may be performed by the block creation module 92 of at least one distributed system node 68. In an embodiment, the process may include performing an encryption operation of a selected difficulty. Several nodes 68 of the distributed identity element library may compete with each other to create a new block, the first node to successfully execute the process wins the race and creates a new block. The new block may then be transmitted to other nodes 68 of the distributed identity element library, which other nodes 68 may incorporate the block into a chain of blocks stored by the other nodes 68 after validation of the block. Once incorporated into the block, the transaction has been executed, and the contract is issued to the blockchain.

At step 612, an address of a location on the blockchain where the transaction is to be incorporated may be received. Executing a transaction that issues an identity service contract may generate a response piece indicating an address where the identity service contract resides on the blockchain. The address may be received by the centralized identity system, such as by the identity creation and modification module 52 of the centralized identity system 24 or at least one distributed system node 68 directly connected to a module (such as locally) of the centralized identity system 24. The method may end at step 614.

Fig. 8 depicts an embodiment of a blockchain of the distributed identity element library 66 after an identity service contract is issued to the blockchain. A blockchain may include a plurality of ordered blocks. Each block may include a block header and a set of transactions. One or more of the block header or the transaction may be cryptographically encoded. The first block of the plurality of blocks may be referred to as an originating block. In fig. 8, subsequent blocks (such as the nth block) may contain transactions for issuing identity service contracts, but in other embodiments any block may contain the transaction. The transaction may include a copy of the compiled identity service contract. One or more of the transaction or the contained compiled identity service contract may be cryptographically encoded.

Fig. 9 depicts an embodiment of a method 900 of creating an identity within the centralized identity system 24 that corresponds to an identity generated by an identity provider for an individual. In embodiments where the identity element library comprises a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, embodiments of the method 900 may be used to generate the identity within the identity element library implementing step 508 of the method 500 of fig. 5. The method may begin at step 902.

At step 904, identity data associated with an identity generated by an identity provider can be received. In the process of creating an identity by an identity provider, the identity data may have been verified to generate an identity by the identity provider. The identity data may comprise one or more data identifying the individual, such as at least one of: a name of the person, such as the actual name of the person, the user name of the person, etc.; identification numbers for personal identities such as social security numbers, driver's license numbers, passport numbers, etc.; personal addresses such as physical addresses, email addresses, etc.; basic biometric information of the individual, such as age, gender, height, weight, eye color, hair color, etc.; or a representation of a biometric characteristic of the individual, such as a picture of the individual, a representation of a fingerprint, a representation of a facial pattern, a representation of an iris pattern, a representation of a retinal pattern, a representation of voice, a representation of a deoxyribonucleic acid (DNA) pattern, and the like. The centralized identity system may receive identity data from the identity provider system via the identity provider interface module.

Fig. 10A-10C depict an embodiment of a user interface 130 that identity provider interface module 40 provides to identity provider system 28. FIG. 10A depicts an embodiment of the user interface 130 prior to receiving any identity data. The user interface 130 may include a plurality of columns 130 and corresponding identifiers to accept different types of identity data. In FIG. 10A, the user interface may include fields for accepting a first name, a middle name, a last name, a date of birth, a place of birth, an identity release date, an identity expiration date, an identification number, and a personal photograph. Fig. 10B depicts an embodiment of the user interface 130 after entering at least some of the verified identity data.

Returning to FIG. 9, at step 906, one or more transactions may be generated to store an identifier representing the received identity data on the blockchain. In embodiments where the identity element library comprises a distributed intelligent contract system, the transaction may invoke the identity data creation function 104 of the identity service contract. Functions of an identity services contract issued into a blockchain and designed to run may be executed by transacting calls to such functions. To invoke the identity data creation function, a transaction may be generated that includes a request to invoke the function. The call to the identity data creation function may include as an input to the function an identifier representing the identity data. The identifier may comprise an cryptographically encoded version of the received identity data. For example, the identifier may include the received identity data that was cryptographically encoded using one or more cryptographic hash functions, such as one or more of a variant of secure hash algorithm 2 (SHA-2), a variant of secure hash algorithm 3(SHA-3), and so forth. The result of the execution of the function may store an identifier representing the identity data in a data structure on the blockchain, such as in the data structure 120 of the identity service contract on the blockchain.

At step 908, the generated transaction may be transmitted to at least one of the distributed system nodes 68 of the distributed identity element repository. The transaction may be sent to at least one node 68 by one of the distributed system nodes 68 (e.g., local) directly connected to the identity creation and modification module 52 of the centralized identity system 24. As with step 610 of the method 600 of fig. 6, sending the transaction to at least one distributed system node 68 may incorporate the transaction into a block of a blockchain stored by the nodes 66 of the distributed identity element library by one or more of the distributed system nodes 68 triggering the transaction included in the process. Once incorporated into the block, the transaction has been executed, then the identity data creation function is invoked.

At step 910, an address of a location of a transaction on a blockchain may be received. The address may be received by the centralized identity system 24, such as by the identity creation and modification module 52 of the centralized identity system 24 or at least one distributed system node 68 (e.g., local) directly connected to a module of the centralized identity system 24.

At step 912, an identity token corresponding to the created identity may be generated within centralized identity system 24. The identity token may be distributed to individuals for provision to the restricted access system 36 to invoke their identity. The identity token may include one or more components to trigger one or more identity verification functions. For example, the identity token component may include an identifier representing the received identity data stored on the blockchain, which may be used in a verification process to invoke an authentication function such as an identity service contract. The identity token component may also optionally include one or more additional components, such as one or more of the following: the received identity data, a digital signature created using a private key of the identity provider, an indication of the identity provider, or an indication of a specific public key of the identity provider. The digital signature may be used in a subsequent authentication process to verify the integrity of the identity token using the public key of the identity provider. The indication of the identity provider may be used to locate the public key of the identity provider. The indication of the particular public key of the identity provider may be used to locate the key among a plurality of public keys of the identity provider.

The identity token may take various forms. In embodiments, the identity token may take the form of one or more components of the identity token encoded into encoded data, such as a barcode, for example a one-dimensional barcode or a two-dimensional barcode. The method may end at step 614.

10A-10C, FIG. 10C depicts an embodiment of a user interface 130 provided by identity provider interface module 40 to identity provider system 28 when creating identities within centralized identity system 24. The interface 130 may display the verified identity data 138, verified identity data 142, and a representation of the generated identity token 146 stored in the blockchain (which, as shown, may take the form of a two-dimensional barcode encoding the verified identity data, digital signature of the identity provider, and a representation of the identity provider stored in the blockchain).

Fig. 11 depicts an embodiment of a blockchain of a distributed identity element library after incorporating into the blockchain a transaction for invoking an identity data creation function of an identity services contract. The blockchain may include the portion of the blockchain depicted in fig. 8, followed by subsequent portions that lead out subsequent blocks (such as an N + X th block), which may contain transactions that invoke the identity creation function of the identity service contract, although any subsequent block may contain the transaction in other embodiments. The transaction may include a representation of the verified identity data.

FIG. 12 depicts an embodiment of a method 1200 of adding or modifying metadata associated with an identity within a centralized identity system. In embodiments where the identity element library comprises a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, embodiments of method 1200 may be used to implement the addition or modification of metadata associated with identities within the identity element library of step 512 of method 500 of fig. 5. The method may begin at step 1202.

At step 1204, metadata and identifiers of identities within the centralized identity system can be received. The metadata may relate to, for example, the individual or an identity provided by an identity provider for the individual. The metadata associated with the person may include identity data associated with the person. Metadata relating to an identity provided by an identity provider for an individual may include the current state of the identity, such as whether the identity has been revoked, the expiration date of the identity, and so forth. In an embodiment, the metadata may include data not included in the identity data used to generate the identifiers stored in the identity element repository. The identifier may identify an identity of an individual within the centralized identity system. Depending on and according to the context of use of the metadata, the metadata and identifiers may be received from one or more of an identity provider system (such as via an identity provider interface module), an identity user system (such as via an identity user system interface module), or a restricted access system (such as via a restricted access system interface module).

At step 1206, one or more transactions may be generated to store metadata in the blockchain associated with the corresponding identity. In embodiments where the identity element library comprises a distributed intelligent contract system, the transaction may invoke a metadata addition or modification function of the identity services contract. The transaction may include a request to invoke the metadata function 108. The request to invoke the metadata function may include the metadata and an identifier of the identity as inputs to the function. The metadata may be cryptographically encoded. The result of the execution of the function may store a representation of the metadata in a data structure on the blockchain in a data structure associated with the identity, such as data structure 124 of an identity service contract associated with the identity on the blockchain.

At step 1208, the generated transaction may be transmitted to at least one of the distributed system nodes 68 of the distributed identity element repository. The transaction may be sent to at least one node 68 through one of the distributed system nodes 68 that is directly connected to the centralized identity system's identity creation and modification module 52 (e.g., locally). As with the other steps of sending transactions to the nodes, sending transactions may trigger transactions included in the process by one or more of the distributed system nodes 68 to incorporate the transactions into blocks of the blockchain stored by the nodes of the distributed identity element repository. Once incorporated into the block, the transaction has been executed, and a metadata creation or modification function is invoked.

At step 1210, an address of a location of a transaction on a blockchain may be received. The address may be received by a centralized identity system, such as by the identity creation and modification module 52 of the centralized identity system 24 or at least one distributed system node 68 (e.g., local) directly connected to the module. The method may end at step 1212.

In an embodiment, the identity services provided by centralized identity system 24 may be performed by invoking one or more contracts issued to a blockchain of a distributed identity element library. Fig. 13-16 depict embodiments of a contract architecture published to blockchains to implement identity services for a centralized identity system.

Centralized identity system 24 may provide identity services to multiple different identity service providers or different authorized roles within a single identity service provider. Fig. 13 depicts an embodiment of an identity service contract architecture implementing identity services for multiple different identity service providers or different authorized persona IPs 1-IPNs. The architecture may include a plurality of identity service contracts ISCA 1-ISCANs, each of which accepts input only from a different identity provider or authorized role IP1-IPN and provides identity services IS1-ISN only for that identity provider or authorized role.

Fig. 14 depicts another embodiment of an identity service contract architecture implementing identity services for multiple different identity service providers or authorized roles. The architecture may include a single identity service contract ISCB that accepts requests for identity services from multiple different identity providers or authorized role IPs 1-IPNs and provides identity services IS 1-ISNs for each identity provider or authorized role IP 1-IPN. A contract may include one or more authorization or routing functions that identify a requestor of an identity service and provide authorization or routing of the request to create, modify, etc., identities, metadata structures, etc., associated only with the identified requestor. For authorization or routing, the transaction addressed to the identity service contract ISCB may include an indication of the requestor.

Fig. 15 depicts another embodiment of an identity service contract architecture implementing identity services for multiple different identity service providers or authorized roles. The architecture may include an identity service contract ISCC that accepts requests for identity services from multiple different identity providers or authorized roles IP1-IPN, and a separate authorization or routing contract ARCC that identifies requesters of identity services and provides authorization or routing of the requests to create, modify, etc. identities, metadata structures, etc. associated only with the identified requesters. An identity service contract ISCC may generate a transaction addressed to an authorization or routing contract ARCC to request authorization or routing in response to a transaction addressed to an identity service contract requesting identity service.

Fig. 16 depicts another embodiment of an identity service contract architecture implementing identity services for multiple different identity service providers or authorized roles. The architecture may include an authorization or routing contract ARCD and one or more identity service contracts ISCD1-ISCDN, the authorization or routing contract ARCD accepting requests for identity services from a plurality of different identity providers or authorized roles IP1-IPN, identifying requestors of the identity services, and providing authorization or routing of the requests to create, modify, etc., identities, metadata structures, etc., associated with the identified requestors of the respective identity service contracts ISCD1-ISCDN, each identity service contract ISCD1-ISCDN performing identity services for a different respective identity provider or authorized role. In authorizing or routing, the authorization or routing contract ARCD may generate a transaction addressed to the corresponding identity service contract ISCD1-ISCDN in response to the transaction requesting the identity service.

Embodiments of the architecture of fig. 16 may also be configured to include only a single identity service contract to separate authorization functionality from identity service functionality, even for only a single identity provider or authorization role.

A centralized identity system may provide one or more identity verification functions to enable identity verification in an improved manner, thereby enabling enhanced security and preventing identity fraud. In an embodiment, a multi-factor authentication process may be performed, which may include authenticating an identity in a centralized identity system and performing a physical authentication of the individual presenting the identity token.

Fig. 17 depicts an embodiment of a method 1700 of performing authentication of an individual. The method may perform multi-factor authentication, including authentication of identities stored in an identity element repository in a centralized identity system and physical authentication of individuals presenting identity tokens. An embodiment of method 1700 may be used to implement the authentication step 516 of method 500 of fig. 5. The method may begin at step 1702.

Note that embodiments of the identity service method discussed herein may be performed in many different contexts. In one example, authentication may be performed in the context of a hotel consumer attempting to rent a room and/or access a hotel system. Authentication may also be performed in many other scenarios.

At step 1704, the limited access system 36 may receive a representation of an identity token from an individual attempting to invoke an identity to access the limited access system 36. The restricted access system 36 may receive the representation of the identity token in various ways, such as by the restricted access system scanning the identity token displayed by the individual with the identity user system. For example, a hotel consumer may present an identity token to the hotel system in the form of a barcode using a mobile device that displays the barcode.

At step 1706, the identity token and corresponding identity within the centralized identity system may be verified. The identity token may be verified to ensure its integrity. Verifying the identity token may include verifying a digital signature component of the identity token against the identity provider's public key, such as discussed further below with respect to fig. 19. An identity associated with the identity token may be verified to provide a first factor of the multi-factor authentication. Authentication may include determining whether an identifier associated with the identity is stored on the blockchain, such as by searching for the identifier in the blockchain or invoking an identity data verification function of the identity service contract, e.g., as discussed further below with respect to fig. 19.

At step 1708, a physical characteristic of the individual may be determined. In an embodiment, a physical characteristic associated with the individual, such as a representation of biometric identity data of the individual, may be determined from the identity token. For example, the physical characteristic may be determined as data extracted from the identity token. The physical characteristic may include one or more of a photograph of the individual, a representation of the individual's fingerprint, a representation of the individual's facial pattern, a representation of the individual's iris pattern, a representation of the individual's retinal pattern, a representation of the individual's voice, a representation of the individual's deoxyribonucleic acid (DNA) pattern, and the like. In other embodiments, the physical characteristics may be determined from data from the identity token or using other systems.

At step 1710, the determined physical characteristic may be verified against the individual presenting the identity token to invoke the identity. The physical characteristics may be verified against the individual presenting the identity token to provide a second factor of the multi-factor authentication. A variety of methods may be used to verify the physical characteristic against the individual, including one or more of visual comparison by a third party person operating the limited access system, automatic comparison by a biometric feature scan and comparison device, and the like. For example, a biometric feature scanning and comparing device may include: scanning means for scanning a biometric characteristic of an individual corresponding to a physical characteristic; and processing means for comparing the scanned features with the body characteristic.

At step 1712, access to the restricted access system may be granted or denied based on the results of the verification of the extracted data and the verification of the identity. Access may be granted if the result of both verifications is positive, that is, if the result of the authentication indicates that the identity is valid and the result of the physical verification indicates that the individual corresponds to the identity. If either verification is negative, that is, if the result of the identity verification indicates that the identity is invalid, or the result of the physical verification indicates that the individual does not correspond to the identity, access may be denied. The method may end at step 1714.

As described above, embodiments of a method of verifying the identity of an individual may be performed in a variety of contexts. FIG. 18 depicts an exemplary embodiment of the system of FIG. 1 in the context of a government border aisle or identity checkpoint. The system may include an identity centralized system 24, one or more passport or government identity provider systems 28A as an embodiment of identity provider system 28, a traveler or citizen identity user system 32A as an embodiment of identity user system 32, and a border control or identity check system 36A as an embodiment of restricted access system 36.

In other embodiments, authentication may be performed using only a single factor of the multi-factor authentication of fig. 17. For example, an embodiment of a method of performing identity verification may include only verifying an identity within a centralized identity system (such as only steps 1704, 1706 of the steps depicted in fig. 17) and an authorization step similar to step 1712 of the steps depicted in fig. 17, but in which access may be granted if the result of a single verification factor is positive and denied if the result is negative.

Verifying an identity within a centralized identity system may include calling a function to verify an identifier representing an identity within a repository of identity elements. Fig. 19 depicts an embodiment of a method 1900 of verifying an identity of an individual in a library of identity elements stored in a centralized identity system 24. In embodiments where the identity element repository includes a distributed system, such as a distributed blockchain ledger or a distributed intelligent contract system, embodiments of method 1900 may be used to implement the identity verification process of steps 1704 and 1706 of method 1700 of fig. 17. The method may begin at step 1902.

At step 1904, restricted access system 36 can receive an identity token from an individual attempting to invoke an identity to access restricted access system 36.

At step 1906, one or more components of the identity token can be extracted. The extracted components may include one or more of an identifier of the identity, a digital signature of the identity provider, an indication of the identity provider, and the like. In embodiments where the identity token comprises encoded data, the information may be extracted by decoding any encoding of the information in the identity token. For example, if the identity token encodes the contained information as a two-dimensional barcode, the information may be extracted by decoding the barcode.

At step 1908, the digital signature included in the identity token may be verified. The digital signature may be a cryptographic hash of the identity token using a private key, such as the identity provider's private key. Verifying the digital signature may verify the integrity of the identity token. The digital signature may be verified using a public key, such as the public key of the identity provider. In an embodiment, the identity of the identity provider and/or the public key of the identity provider may be determined from one or more extracted components of the identity token.

At step 1910, it may be determined whether the blockchain of the identity element library contains a data structure with the identity identifier, for example, by searching the data structure of the blockchain, invoking the identity verification function 112 of the identity service contract, or generating one or more transactions to invoke the identity verification function of the identity service contract. In an embodiment, the identity verification function may be a public function of an identity service contract that may be accessed and executed without generating a transaction to a blockchain. In such embodiments, the authentication function may be invoked directly. Alternatively, in an embodiment, invoking the authentication function may request a transaction for the blockchain. In such an embodiment, to invoke the identity data verification function, a transaction may be generated that includes a request to invoke the function. The request for the authentication function may include as an input to the function a representation of authenticated identity data for the identity stored on the blockchain, such as authenticated identity data cryptographically encoded using one or more hash functions.

In embodiments where the transaction is generated, at step 1912, the generated transaction may be transmitted to at least one of the distributed system nodes 68 of the distributed identity element repository. The transaction may be sent to at least one node 68 through one of the distributed system nodes 68 that is directly connected to the authentication module 60 (e.g., locally) of the centralized identity system 24. As with the other steps of sending transactions to at least one distributed system node 66, sending a transaction may trigger a transaction included in the process by one or more of the distributed system nodes 66 to incorporate the transaction into a block of the chain of blocks stored by the nodes 66 of the distributed identity repository. Once incorporated into the block, the transaction has been executed, such as resulting in the invocation of an authentication function. In embodiments where it is not necessary to generate a transaction (such as a transaction that may directly call an authentication function), step 1912 may be omitted.

At step 1914, a verification and/or status of the identity in the distributed identity element repository may be received. The result of step 1910 may include whether an identifier representing the identity data input to the function call is present on the blockchain. The function may output an identity invalidation if an identifier representing the identity data is not present on the blockchain. If the identifier does exist on the blockchain, the function may output an indication that the identity is valid. The current state of the identity may also be retrieved, such as by accessing metadata on a blockchain associated with the identity. The method may end at step 1916.

Fig. 20 depicts an embodiment of a blockchain of a distributed identity element library after incorporating a transaction that invokes an identity data verification function of an identity service contract into the blockchain. The blockchain may include the portion of the blockchain depicted in fig. 11, followed by subsequent portions of the boot block (such as the N + Y block), which may contain transactions that call authentication functions, although in other embodiments any subsequent block may contain the transaction.

Fig. 21A-21C depict an embodiment of a user interface 150 provided to the limited access system 36 by the limited access system interface module 48. Fig. 21A depicts an embodiment of the user interface 150 prior to receiving any identity tokens. The user interface 150 may include a plurality of columns 154 and corresponding identifiers to accept different types of data. In fig. 21A, the user interface 150 may include a field for accepting information extracted from the identity token. Fig. 21B depicts an embodiment of the user interface 150 after filling out the information extracted from the identity token. Fig. 21C depicts an embodiment of the user interface 150 after running the authentication function. The user interface 150 may display the verified identity data 158, the validity 161 of the identity, the status 162 of the identity, and the identification 166 of the identity provider.

A multi-stage authentication process may also be provided. Embodiments of a multi-stage verification process may include an initial, relatively more stringent verification stage followed by a relatively less stringent verification stage. Fig. 22 depicts an embodiment of a method 2200 of verifying the identity of an individual attempting to access the restricted access system 36. Method 2200 may provide for multi-stage verification that includes an initial, relatively more rigorous stage (such as embodiments that include multi-factor verification such as discussed above) and a subsequent, second, relatively less rigorous verification that has provided authorization in response to the initial verification (such as being limited to single-factor verification). Embodiments of method 2200 may be used to implement authentication step 516 of method 500 of fig. 5. Method 2200 can begin at step 2202.

At step 2204, restricted access system 36 can receive a representation of an identity token from an individual attempting to invoke an identity to access restricted access system 36. Step 2204 may be performed similarly as discussed above with respect to steps 1704 and 1904 of methods 1700 and 1900 of fig. 17 and 19.

At step 2206, the identity token and corresponding identity within the centralized identity system can be verified. As discussed above, verifying an identity token can ensure its integrity, and verifying an identity within a centralized identity system can provide the first factor of multi-factor authentication. Step 2206 may be performed similarly as discussed above with respect to step 1706 of method 1700 of fig. 17 and method 1900 of fig. 19.

At step 2208, a physical characteristic of the individual may be determined, such as a representation of a biometric characteristic of the individual extracted or otherwise determined from the identity token. Step 2208 may be performed similarly as discussed above with respect to step 1708 of method 1700 of fig. 17.

At step 2210, the identity can be invoked against the identity token presented to verify the physical attributes. As discussed above, the physical characteristics may be verified against the individual presenting the identity token to provide a second factor of the multi-factor authentication. Step 2210 may be performed similarly as discussed above with respect to step 1710 of method 1700 of fig. 17.

In step 2212, initial access to the restricted access system may be granted or denied based on the verification of the extracted representation of the biometric characteristic and the verification of the identity. If the results of both verifications are positive, access may be granted, and if the results of either verification are negative, access may be denied. Step 2212 may be performed similarly as discussed above for step 1712 of method 1700 of fig. 17.

The embodiment of method 2200 of fig. 22 may be performed to provide multi-stage verification in a variety of scenarios. For example, embodiments of the method may be used where an operator of a facility, such as a hotel, convention center, business location, service provider location, employment location, etc., may need or desire initial, more rigorous authentication in a first interaction with an individual, but may later be willing or desired to use less rigorous authentication in subsequent interactions for convenience.

Figure 23 depicts an embodiment of the system of figure 1 configured for the context of a hotel. The system may include an identity centralized system 24, one or more identity provider systems 28, a hotel consumer or hotel consumer system 32B as an embodiment of an identity user system 32, and a hotel system 36B as an embodiment of a restricted access system 36. The embodiment of method 2200 of fig. 22 may provide a multi-stage verification in the context of a system comprising a hotel facility limited access system such as in fig. 23. In this scenario, an initial, more rigorous verification process may be performed in an initial interaction of the hotel consumer with the hotel system, such as during a hotel check-in process by the wine store consumer.

Returning to FIG. 22, at step 2214, it may be determined whether to provide a multi-stage verification process for the person. If it is determined that a multi-stage verification process (also referred to herein as an enhanced verification process) is provided, the method can perform step 2216, otherwise the method can perform step 2224, and the method can end at step 2224. May be determined by a limited access system operator or a component of the limited access system 36. The determination may be based on one or more factors, such as according to one or more of the following: a predetermined configuration (e.g., a commonly used user program, etc.) between the limited access system and the individual that assigns a predetermined category of the individual to either enhanced or non-enhanced authentication (e.g., individuals of certain jurisdictions are assigned to either enhanced or non-enhanced authentication, etc.); whether any problems occurred during the initial verification phase; a level of trust perception associated with the individual, etc.

At step 2216, enhanced authentication of the individual may be implemented for the limited access system 36. Enhanced authentication may be initiated by setting an indication, for example, in a personal profile in the limited access system 36.

At step 2218, following the initial authentication phase, the restricted access system may receive data related to the individual, such as a representation of a biometric characteristic of the individual. The biometric characteristic may be received by the limited access system by a line scan of the biometric characteristic. The biometric characteristic scanning device may comprise scanning means for scanning a biometric characteristic of the individual corresponding to the determined physical characteristic. In one example, a thumb print scanner may scan a thumb print of an individual.

At step 2220, the determined physical characteristic may be verified against the received biometric data. The physical characteristic may be verified against the received biometric data to provide a relatively less rigorous verification following the enhanced verification process. Step 2220 may be performed similarly as discussed above with respect to the corresponding component step 1710 of method 1700 of fig. 17. In one example, the determined thumbprint data can be compared to the scanned thumbprint.

At step 2212, subsequent access to the limited access system 36 may be granted or denied based on the result of the verification of the physical characteristic against the received biometric data. If the verification result is positive, i.e. if the verification result indicates that the person corresponds to the extracted characteristic, access may be granted. If the verification result is negative, i.e. the verification result indicates that the person does not correspond to the extracted characteristic, access may be denied. The method may end at step 1714.

Returning to fig. 23, in embodiments of method 2200 performed in the context of a hotel limited access system, a subsequent less rigorous authentication phase may be performed in subsequent interactions of the hotel consumer with the hotel system, such as when the hotel consumer enters his room at the hotel.

In the embodiment of method 2200 of fig. 22, the subsequent verification stage may be based on, instead of or in addition to the verification of the determined physical characteristic, other data verification, such as verification of a piece of identity data, etc.

Metadata associated with the identity stored in the identity element repository may be retrieved. For example, in an embodiment of the identity verification process, while verifying the validity of the identity, the current state of the identity stored in the metadata may be retrieved, such as whether the identity has been revoked, whether an arrest request is issued for the person, etc.

FIG. 24 depicts an embodiment of a method 2400 of retrieving metadata associated with an identity in a centralized identity system. In embodiments where the identity element library comprises a distributed system, embodiments of method 2400 may be used to implement the retrieving metadata associated with identities within the identity element library of step 520 of method 500 of fig. 5. The method may begin at step 2402.

At step 2404, the restricted access system may receive a representation of an identity token from an individual attempting to invoke an identity to access the restricted access system. Step 2404 may be performed similarly as discussed above for step 1904 of method 1900 of fig. 19.

At step 2406, one or more identity token components can be extracted from the identity token. The extracted information may include an identifier of verified identity data representing an identity stored on the blockchain. Step 2406 may be performed similarly as discussed above for step 1906 of method 1900 of fig. 19.

At step 2408, the digital signature of the identity token may be verified. Step 2408 may be performed similarly as discussed above with respect to step 1908 of method 1900 of fig. 19.

At step 2410, it may be determined whether the blockchain contains a metadata structure associated with the identifier, such as by searching the data structure of the blockchain, invoking the metadata read function 116 of the identity service contract, or generating one or more transactions to invoke the metadata read function of the identity service contract. The metadata read function may be a public function of the identity services contract that may be accessed and executed without generating transactions to the blockchain. In such embodiments, the metadata read function may be invoked directly. Alternatively, calling the metadata read function may request a transaction for the blockchain. In such embodiments, to invoke the metadata read function, a transaction may be generated that includes a request to invoke the function. The request for the metadata read function may include as an input to the function a representation of verified identity data for an identity stored on the blockchain.

In embodiments where the transaction is generated, the generated transaction may be transmitted to at least one of the distributed system nodes 66 of the distributed identity element repository at step 2412. The transaction may be sent to the at least one node 66 via one of the distributed system nodes directly connected to a module (e.g., local) of the centralized identity system 24. As with the other steps of sending transactions to at least one distributed system node 66, sending a transaction may trigger a transaction included in the process by one or more of the distributed system nodes 66 to incorporate the transaction into a block of the chain of blocks stored by the nodes 66 of the distributed identity element repository. Once incorporated into the block, the transaction has been executed, such as by calling a metadata read function. In embodiments where the transaction does not need to be generated (e.g., the metadata read function may be invoked directly), step 2412 may be omitted.

At step 2414, metadata associated with the identity in the distributed identity element library may be received.

Centralized identity system 24 may provide identity services in many other contexts. For example, the centralized identity system 24 may provide identity services to enable financial transaction administration and tracking processes. FIG. 25 depicts an embodiment of the system of FIG. 1 configured for the context of a financial transaction environment. The system may include an identity centralized system 24, one or more identity provider systems 28 (such as a financial administration identity provider system 28C), a financial transaction executor system 32C that is an embodiment of an identity user system 32, and a financial transaction system 36C that is an embodiment of a limited access system 36.

FIG. 26 depicts an embodiment of a method 2600 of tracking financial transactions. Embodiments of the method may be performed in the context of an embodiment of a financial transaction environment, such as an embodiment of the system of figure 25. The method may begin at step 2602.

At step 2604, a financial transaction may be conducted. The financial transactions may include one or more of financial trades (such as stocks, bonds, or other transactions), debt transactions (such as loan transactions), asset transfer transactions, and the like. The financial transaction may be performed by a financial transaction performer using a financial transaction system.

At step 2606, the financial transaction and financial transaction performer identifiers can be extracted from the records of the financial transaction or other data set. For example, the identifier may be extracted from a response piece or log generated in response to the transaction.

At step 2608, a transaction may be generated to invoke a data or metadata creation or modification function of the identity service contract. Transactions may be generated similar to that discussed above for other blockchain transaction generation steps. The transaction may add metadata including the financial transaction identifier to a repository of identity elements associated with the identity identified by the financial transaction performer identifier. The financial transaction performer identifier may include a representation of verified identification data for the financial transaction performer.

At step 2610, a transaction invoking data or metadata creation or modification of an identity services contract may be sent to at least one distributed intelligent contract system node of the distributed identity element repository. The transaction may be sent to at least one node, and the transaction may be similarly incorporated into the blockchain, similar to that discussed above with respect to the other blockchain transaction sending steps.

At step 2612, the address of the location on the blockchain to which the transaction is merged is received. Incorporating transactions into a blockchain may provide a relatively untampered record of financial transactions performed by a financial transaction performer, such as may meet one or more financial regulations.

Other embodiments of the identity system, centralized identity system, and method of providing identity services discussed herein are possible. For example, any features of any embodiment of the identity system, the centralized identity system, and the method of providing identity services described herein may be used in any other embodiment of the identity system, the centralized identity system, and the method of providing identity services. Moreover, embodiments of the identity system, the centralized identity system, and the method of providing identity services may include only any subset of the components or features of the identity system, the centralized identity system, or the method of providing identity services discussed herein.

Claims (16)

1. A method of providing identity services, the method comprising:

receiving, by an identity system, identity data of an individual from an identity provider system at a first interface, the identity provider having provided the individual with an identity, wherein the identity data is verified by the identity provider;

generating, by the identity system, a transaction to store an identifier representing the identity data in a data structure on a blockchain of a distributed system;

sending the transaction to at least one node of the distributed system;

generating, by the identity system, an identity token containing the identifier representing the identity data;

providing, by the identity system, the generated identity token to the user system of the individual at a second interface to the user system;

receiving, by the identity system from a limited access system, data extracted from an identity token, wherein the extracted data comprises an identifier representing identity data;

determining, by the identity system, whether a data structure containing the extracted identifier representing the identity data is stored on a blockchain of the distributed system; and

outputting, by the identity system to the limited-access system based on the determination, an indication of validity of the identity of the individual associated with the identity data.

2. The method of claim 1, wherein the transaction invokes an identity creation function of an identity services contract stored on the blockchain.

3. The method of claim 1, wherein the identity data comprises at least one representation of a biometric characteristic of the individual.

4. The method of claim 3, wherein the representation of the biometric characteristic comprises at least one of: a picture of the individual, a fingerprint of the individual, a facial pattern of the individual, an iris pattern of the individual, a retinal pattern of the individual, a representation of a voice of the individual, or a deoxyribonucleic acid (DNA) pattern of the individual.

5. The method of claim 1, wherein generating the identity token comprises encoding into the identity token at least one of: an identifier representing the identity data, an identification of the identity provider, or a digital signature of the identity provider.

6. The method of claim 1, further comprising:

receiving metadata associated with the individual;

generating a transaction to store the metadata or a representation of the metadata on a blockchain associated with an identifier representing the identity data; and

sending the transaction to at least one node of the distributed system.

7. The method of claim 6, wherein the transaction invokes a metadata creation function of an identity services contract stored on the blockchain.

8. A method of verifying identity, the method comprising:

receiving, by the identity system from the limited-access system, data extracted from the identity token, wherein the extracted data includes an identifier representing the identity data;

determining, by the identity system, whether a data structure containing the extracted identifier representing the identity data is stored on a blockchain of a distributed system; and

outputting, by the identity system to the limited-access system based on the determining, an indication of validity of an identity of the individual associated with the identity data, wherein the indication comprises the identity being valid when the data structure containing the extracted identifier is stored on a distributed ledger and the indication comprises the identity being invalid when the data structure containing the extracted identifier is not stored on a distributed ledger.

9. The method of claim 8, wherein the determining comprises invoking an identity verification function of an identity service contract stored on a blockchain, the invocation comprising the extracted identifier representing the identity data.

10. The method of claim 8, wherein the extracted data further comprises a digital signature of an identity provider extracted from the identity token, and the method further comprises verifying the digital signature using a public key of the identity provider.

11. The method of claim 8, wherein the data extracted from the identity token comprises a representation of a biometric characteristic of the individual, and the method further comprises verifying the extracted representation of the biometric characteristic against a biometric feature of the individual.

12. The method of claim 8, further comprising:

receiving, by the identity system, identity data of a person from an identity provider system for which the identity provider has provided an identity, wherein the identity data is verified by the identity provider;

generating, by the identity system, a transaction to store an identifier representing the identity data in a data structure on a blockchain of the distributed system;

sending the transaction to at least one node of the distributed system;

generating, by the identity system, an identity token containing the identifier representing the identity data; and

providing, by the identity system, the generated identity token to a user system of the individual.

13. A non-transitory machine-readable storage medium having program instructions which, when executed by a processor, perform a method of providing identity services, the method comprising:

receiving, by an identity system, identity data of an individual from an identity provider system at a first interface, the identity provider having provided the individual with an identity, wherein the identity data is verified by the identity provider;

generating, by the identity system, a transaction to store an identifier representing the identity data in a data structure on a blockchain of a distributed system;

sending the transaction to at least one node of the distributed system;

generating, by the identity system, an identity token comprising an identifier representing the identity data; and

providing, by the identity system, the generated identity token to the user system of the individual at a second interface to the user system;

receiving, by the identity system from a limited access system, data extracted from an identity token, wherein the extracted data comprises an identifier representing identity data;

determining, by the identity system, whether a data structure containing the extracted identifier representing the identity data is stored on a blockchain of the distributed system; and

outputting, by the identity system to the limited access system based on the determination, an indication of validity of the identity of the individual associated with the identity data.

14. The non-transitory machine-readable storage medium of claim 13, wherein the transaction invokes an identity creation function of an identity services contract stored on the blockchain.

15. The non-transitory machine-readable storage medium of claim 13, the method further comprising generating an identifier representative of the identity data by performing at least one cryptographic hash function on the identity data.

16. The non-transitory machine-readable storage medium of claim 13, wherein generating the identity token comprises encoding into the identity token at least one of: an identifier representing the identity data, an identification of the identity provider, or a digital signature of the identity provider.