User id codes for online verification

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. Provisional Application No. 62/670,664, titled “USER ID CODES FOR ONLINE VERIFICATION,” and filed on May 11, 2018, the contents of which are hereby incorporated herein by reference in its entirety for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to systems and methods for managing the identity of users and identifying users to third parties using user ID codes in an online verification platform.

BACKGROUND

Banks and financial institutions have long been required to verify the identity of a customer and to verify the authenticity of information provided by that customer when the customer seeks access to a new product or service, for example when opening a new account or applying for a loan. This trend has quickly spilled over into other sectors, particularly considering the rise in e-commerce and our increasingly digital lives. The result of this trend is that digitized personal information is constantly increasing, as are security breaches and data theft.

The ability to store and share information digitally offers many benefits, and the digitization of data has increasingly grown. However, alongside the advantages of cost and convenience, a new set of concerns has developed. The ability to copy and share data has raised questions about the security and privacy of personal data. There have been many high-profile hacks, leaks, and theft of personal information, as well as cases where unencrypted data has simply been lost or left vulnerable to theft. In 2016 alone, 15.4 million adults in the U.S. were victims of identity fraud, an increase of 16% over 2015, and victims suffered losses amounting to $16 billion. Personal identifiable information (PII) was the most common form of data stolen, accounting for almost 43% of data breaches, and the services industry was most affected by data breaches, accounting for almost double the occurrence of the finance, insurance, and real estate sectors combined.

Inefficiencies in the identify verification industry have both financial and social costs. Without proof of identity, an individual may be unable to exercise a range of legal rights, including the ability to vote, access health care, and receive social welfare. Lack of identity documentation and the high costs of obtaining it means that many individuals globally are wholly or partially denied access to banking facilities. In low-income countries, new births often go unregistered because parents struggle to acquire the necessary documentation to have verified and recorded reliably by the relevant authorities. Individuals or companies may misrepresent their identity or their relationship to one another, which can cause investors, consumers, and the general public to be misled into believe a false assertion, which may cause them personal, reputational, and financial harm.

Identify verification processes are often intrusive or time-consuming to individuals, and they come at a significant cost to those required to carry them out as a matter of law and to avoid commercial and reputational losses due to fraud. It may cost a financial institution such as a bank $15 or more to on-board a single customer and verify their identity and personal information. This process gets repeated every time the same consumer tries to access another product or service, despite the process being similar, if not identical, for most organizations. The time it takes to initially validate information has a detrimental impact on customer relations and invariably also impacts customer acquisition and conversion rates for the sales of products where verification of consumer identity or information is required. Consumers are forced to fill in lengthy application forms and provide extensive personal information, and institutions are being forced to collect sensitive data that they arguably don't need to transact with a customer.

The same overhead and inefficiencies are present in other sectors where highly sensitive data may need to be verified, including in background checks for employment. The sharing economy, which relies heavily on trust and on the verification of identity and personal information, grew an average of 32.4% per annum from 2014 to 2016 and now includes 27 million adults in the U.S., demonstrating the growth and scale driving demand for identify verification services beyond the financial sector.

In the online world today, there are many situations where companies or individuals claim a relationship to another person or entity on websites and a third-party user has no way to know the authenticity of that relationship. This may take the form of “Mr. Jones is an advisor to our business”, “Ms. Smith has endorsed our product”, etc. There is significant value to the company to be able to demonstrate the claimed relationship is genuine. There is significant value to the individual with whom the relationship is claimed as it protects their own reputation from misuse. There is significant value to a third party visiting the web site as they may make decisions based upon the claimed relationship, endorsement or recommendation presented to them.

In an effort to combat identity theft, systems and methods for identifying users to third parties have been developed. In a common two factor application, a user presents a bank card or credit card in addition to the personal identification number (“PIN”) corresponding to the card. In other systems, a user provides a password to identify himself/herself and may be given a Short Message Service (SMS) test message or a phone call with a unique code that the user must recite for access. In still other systems, a user may be given challenge questions to verify his/her identity. Each of these systems, however, is subject to attack and ultimate defeat from a basic security breach.

An identity verification system manages trusted digital identities and enables the use of those trusted digital identities to facilitate interactions between people in society. Digital identities include a collection of attributes and their values which can be used to identify the entities of a system and allow those entities to make identity claims. Identity management includes many aspects including creation of an identity, validation of an identity, storage of the identity, maintenance and updates to the identity, and protection of the identity from theft and unauthorized use. Use of identities allow a person or a computer to recognize other entities involved in an interaction and based on that to determine a role, scope of access, scope of authorization, and scope of actions that an entity can perform.

There have been various other ways to perform certifications on online systems. Security certifications have been used to issue badges, only rendering these badges on specific domains. These badges cannot be used for individuals. LinkedIn profile integrations are possible to verify an individual in an online system however these are not secure and are easy to fake.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:

<figref idref="DRAWINGS">FIG. 1</figref> shows a digital identity verification system from the viewpoints of a validator and requester that individuals can use to have a fingerprint of their digital identity authenticated and stored on a blockchain and on their device, according to some implementations;

<figref idref="DRAWINGS">FIG. 2</figref> shows a simplified diagram illustrating how a user, validator, requester, attestation blockchain, and marketplace blockchain interact in the token economy system for identify verification services, according to some implementations;

<figref idref="DRAWINGS">FIG. 3</figref> shows a simplified block diagram of a system for attestations to be shared between service providers, according to some implementations;

<figref idref="DRAWINGS">FIG. 4A</figref> shows a method performed by a service provider A acting as a validator in the system for attestations, according to some implementations;

<figref idref="DRAWINGS">FIG. 4B</figref> shows a method performed by a service provider B acting as a requester in the system for attestations, according to some implementations;

<figref idref="DRAWINGS">FIG. 4C</figref> shows a method performed by a user in the system for attestations, according to some implementations;

<figref idref="DRAWINGS">FIG. 5</figref> shows an illustration of the system's goals, according to some implementations;

<figref idref="DRAWINGS">FIG. 6A</figref> shows an extensive form of the interaction between requester and validator, according to some implementations;

<figref idref="DRAWINGS">FIG. 6B</figref> shows an extensive form of the interaction between requester and validator, according to some implementations;

<figref idref="DRAWINGS">FIG. 7</figref> illustrates sample levels of different validators, according to some implementations;

<figref idref="DRAWINGS">FIG. 8</figref> illustrates the penalty for a flag as the level varies for different values of a system constant (a), according to some implementations;

<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example stake of a validator with a penalty of 100 tokens per flag who performs 10,000 attestations, according to some implementations;

<figref idref="DRAWINGS">FIG. 10A</figref> is a block diagram depicting an embodiment of a network environment comprising an online identity verification system;

<figref idref="DRAWINGS">FIG. 10B</figref> is a block diagram depicting a cloud computing environment comprising users in communication with verifiers, digital wallet provider clients, third-party cosigners, validators, and one or more centralized or distributed ledger(s) via a cloud-based identity verification system, according to some implementations;

<figref idref="DRAWINGS">FIGS. 10C and 10D</figref> are block diagrams depicting embodiments of computing devices useful in connection with the methods and systems described herein;

<figref idref="DRAWINGS">FIG. 11</figref> depicts an implementation of some of the architecture of an identity verification platform used to generate ID codes for online verification;

<figref idref="DRAWINGS">FIG. 12</figref> depicts a method in an identity verification platform used to generate user ID codes for online verification, according to some implementations;

<figref idref="DRAWINGS">FIG. 13</figref> depicts a method for creating and exporting a verified individual's badge on an entity's website, according to some implementations;

<figref idref="DRAWINGS">FIG. 14</figref> depicts a method for registering a company with an online verification system, according to some implementations;

<figref idref="DRAWINGS">FIG. 15</figref> depicts some of the functions of an example of a system for online verification, according to some implementations;

<figref idref="DRAWINGS">FIG. 16</figref> illustrates an example of a user interface to sign in or register to use ID codes using an identity verification system application, according to some implementations;

<figref idref="DRAWINGS">FIG. 17</figref> illustrates an example of a QR code that a user can scan in order to download an identity verification system application, according to some implementations;

<figref idref="DRAWINGS">FIG. 18</figref> illustrates an interface for a user to enter profile information using an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 19</figref> illustrates an interface for a user to upload a photo using for a profile using an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 20</figref> illustrates an interface for a user to register an entity using an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 21</figref> illustrates an interface for a user to register one or more entity domains to be associated with the entity using an identification verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 22</figref> illustrates an interface for a user to upload a logo of an entity to be associated with the entity using an identification verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 23</figref> illustrates an interface to provide verification to a user that an entity registration process is complete and entity verification is pending, using an identification verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 24</figref> illustrates an interface showing a user's personal connections in an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 25</figref> illustrates an interface for user settings in an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 26</figref> illustrates an entity dashboard in an identity verification platform that is operable to enable a user to invite new connections to the entity, according to some implementations;

<figref idref="DRAWINGS">FIG. 27</figref> illustrates an entity dashboard in an identity verification platform illustrating connections of an entity, according to some implementations;

<figref idref="DRAWINGS">FIG. 28</figref> illustrates an entity dashboard in an identification verification platform illustrating settings of an entity, according to some implementations;

<figref idref="DRAWINGS">FIG. 29</figref> illustrates an interface for inviting new connections in an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 30</figref> illustrates an indication displayed to a user on an entity dashboard indicated that invitations are queued until the entity is verified, according to some implementations;

<figref idref="DRAWINGS">FIG. 31</figref> illustrates an indication displayed to a user on an entity dashboard when an invitation is sent, according to some implementations;

<figref idref="DRAWINGS">FIG. 32</figref> illustrates a public profile for an individual in an identity verification platform, according to some implementations;

<figref idref="DRAWINGS">FIG. 33</figref> illustrates a public profile for an entity in an identity verification platform, according to some implementations; and

<figref idref="DRAWINGS">FIG. 34</figref> illustrates an administrative portal for an identity verification platform, according to some implementations.

DETAILED DESCRIPTION

For purposes of reading the description of the various embodiments below, the following descriptions of the sections of the specifications and their respective contents may be helpful:

Section A describes a network environment and computing environment which may be useful for enabling an identity management marketplace.

Section B describes a network environment and computing environment which may be useful for practicing embodiments described herein.

Section C describes embodiments of systems and methods useful increasing for generating ID codes for online verification.

Prior to discussing specific implementations, it may be helpful to briefly discuss some concepts and systems utilized by the disclosed systems and methods.

Blockchain

Most identity management systems are in large, centralized databases or server repositories that are centrally managed. Such a centralized database or server represents a single point of trust, and a single point of failure. All participants in a system that relies on such a centralized database must place a high level of trust in the correct operation and accuracy of the data stored in the centralized database. Additionally, malicious actors have a centralized point to focus an attack on, and a security breach or leak would have significant scale and impact. Centralized security services typically require users' sensitive and secret data, including secret keys and passwords, to be stored in repositories. Even when hashed or encrypted for security, most people do not have strong passwords, and existing breaches can be used to discover hashed passwords and keys.

Typical identity management systems that centrally store a user's explicit identifying attributes and their sensitive security credentials cannot provide privacy and anonymity of users or of user's data or of user's transactions. There is nothing to stop an identity management system from collecting personal and transaction data and sharing this data in unauthorized ways and without user consent, for example to consumer intelligence and consumer behavior analytics companies.

A blockchain, which is a peer-to-peer network also known as a distributed ledger, offers a compelling solution to the problem of combining accessibility with privacy and security. Records can be held securely and yet openly authenticated, referenced and documented so that data can be trusted as reliable. A blockchain represents an archive of data and transactions that are performed in a data processing system.

A blockchain enables peer-to-peer online transaction of information with overall consensus without the need for a trusted intermediary. This was achieved by contriving a system in which it is difficult (from the standpoint of computational resources) to add transactions to the blockchain, but easy for anyone to check whether transactions are valid. The difficulty means that there is a cost involved in attempting to process transactions, and rewards for doing so legitimately in the form of new currency or transaction fees. Fraudulent transactions are quickly identified and discarded from the blockchain. Attempting to add a fraudulent transaction is costly, entails foregoing the financial incentives for acting honestly, and is highly unlikely to succeed because no single party in the overall network has more than a small proportion of the overall ‘authority’ to validate transactions. In practice, it is simpler and more profitable to act honestly. Because the blockchain is maintained by a large network of participants, no one actor can easily gain enough influence to submit a fraudulent transaction or successfully alter recorded data (although possible in theory with enough resources, it would be prohibitively expensive in practice, particularly for larger blockchain implementations). Any change that a party attempts to make to the blockchain is recognized and rejected by the majority. Everything that takes place on the blockchain is visible to anyone. It is possible to see everything that has ever been recorded on the blockchain.

Blockchain addresses are strings of random characters that cannot intrinsically be associated with a specific individual. While it is easy for the owner to prove they control an address if they wish, and it is often possible to build up a picture of transaction relationships due to the transparent nature of the blockchain, the address itself does not contain the owner's PII. This enables a high degree of privacy when required.

Blockchain is promising for identity management because the data stored in a distributed ledger are all public and therefore not vulnerable to theft. Data integrity is protected and therefore not vulnerable to illegal or accidental modifications, and the data is time-stamped so that its provenance can be validated. Data is sequenced in a cryptographic time chain so illegal insertions of false data is impossible. These ledgers operate without the need for a trusted third-party and without the need to trust any component of the system overall. The blockchain is policed by every member of the network and its integrity checked and agreed by the network on an ongoing basis. Because of this immutability, a transaction that has been accepted into the network cannot be reversed. With no trusted intermediary to act on behalf of the user or control the movement of their funds, blockchain transactions are immune to chargebacks and are like paying in physical cash, but online.

Bitcoin

Bitcoin is a peer-to-peer currency that was launched in January of 2009 as blockchain's first application. Bitcoin's innovation was solving the so-called ‘double-spend’ problem in online financial transfers: the issue that data is readily copied, and that it is therefore impossible to prevent the same funds from being sent to more than one recipient unless there is a trusted intermediary to keep accounts. This centralized model was used by all banks and payment processor who dealt with electronic funds transfers. Such a centralized approach always involves trust, because there must be an authority whose job it is to organize the transfer of money from one account to another. In the physical world, money is handed over directly from one person to another person. Online, however, there must be intermediaries. Rather than transferring funds from their account directly to the recipient, the user instructs the intermediary to move funds on the user's behalf.

This centralized system has a number of potential drawbacks. The trusted intermediary may prove untrustworthy, they have control over the user's funds, and they can ultimately block or reverse transactions. The centralized nature of online banking and other online money transfer protocols leaves users vulnerable to intervention by these trusted intermediaries and comes with security risks, because there is always a single point of failure. Centralized databases can be hacked, and their administrators compromised or coerced by a range of actors.

The bitcoin blockchain was designed for peer-to-peer online transfers of value, effectively acting as digital cash. It achieves this not by moving money from one address to another, but by maintaining and updating the ledger to reflect how much money is registered to each address. The same approach to recording data transparently, securely and immutably by consensus of the entire network can be extended to many other applications (since the financial value in the bitcoin network is simply information about who owns what). For example, messages can be stored on the blockchain, either encrypted or in plain text. Additionally, secondary tokens representing assets, such as shares in a business, securities, commodities, and other currencies, can be secured on the blockchain.

Smart Contract Platforms

It is also possible to create a system that takes a similar approach to the execution of computer code. Software has historically been run on a single computer or centralized server, just as online money transfers have historically been centralized. Smart contracts are code that is executed on the blockchain, called decentralized applications, or ‘dApps’. Once uploaded to the blockchain, these are stored immutably and run when the required conditions are met.

Smart contracts are also known as self-executing contracts, blockchain contracts, or digital contracts, are stored and replicated on a distributed ledger and supervised by the network of computers that run the distributed ledger. In this format, contracts are converted to computer code that can execute a function when invoked. A smart contract between parties is written as code into the blockchain. The parties involved are anonymous, but the contract is in the public ledger. A triggering event takes place and the contract executes itself according to the coded terms. In contrast to the Bitcoin blockchain, which is designed to execute the specific function of transferring value in BTC, a smart contract platform is a general purpose blockchain. Examples of general purpose blockchains which can support smart contract platforms include ETHEREUM, provided by Ethereum Foundation of Zug, Switzerland, ROOTSTOCK (RSK) provided by Rootstock Cloud ERP of San Ramon, Calif., EOS provided by EOS of Livonia, Mich., NEO provided by NEO of Shanghai, Conn., and DFINITY provided by DFINITY of Palo Alto, Calif. Blockchains requires that transaction fees are paid in the native currency of the blockchain, for example bitcoin (‘BTC’) for the Bitcoin blockchain, and ether (‘ETH’) for the Ethereum blockchain. Fees for executing transactions on the Ethereum blockchain are related to computational complexity, bandwidth, and storage needs (in a system known as “gas”). Gas units each have a price that can be specified in a transaction. Smart contract platforms allow for the creation of separate tokens that are distinct from the native currency. As noted previously, these tokens are digital assets, cryptographically secured upon the blockchain, which can represent whatever the issuer wants and is prepared to back (if necessary), and which can play whatever role in the system that its rule-set determines. These tokens can be transferred on a peer-to-peer basis for a transaction fee, just like native currency (e.g. ETH). They can be incorporated into smart contracts as an integral part of the system.

The identify verification industry has grown in response to the changing cultural, societal, and regulatory landscape concerning personal data, and a number of service providers now offer easy API access to multiple sources of consumer data for identify verification purposes. This largely ad hoc approach has resulted in an outdated, costly, and inefficient system. Accordingly, there is a need for a transformative solution that allows individuals and organizations to easily, securely, and cost effectively obtain proof that identity verification information has been authenticated by a trusted institution without organizations sharing any PII between them, leveraging blockchain and smart contracts technology.

Game Theory

In game theory, a non-cooperative game is a game with competition between individual players and in which only self-enforcing alliances are possible due to the absence of external means to enforce cooperative behavior. Non-cooperative game theory focuses on predicting which coalitions will form, the joint actions that groups take and the resulting collective payoffs. A Nash equilibrium is a solution concept of a non-cooperative game involving two or more players in which each player is assumed to know the equilibrium strategies of the other players, and no player has anything to gain by changing only their own strategy. If each player has chosen a strategy and no player can benefit by changing strategies while the other players keep theirs unchanged, then the current set of strategy choices and the corresponding payoffs constitute a Nash equilibrium. The Nash equilibrium provides a way of predicting what will happen if two parties are making decisions at the same time, and if the outcome depends of the decisions of each other.

A. Computing and Network Environment for Identity Management Marketplace

In a general overview <figref idref="DRAWINGS">FIG. 1</figref> is an illustration of an identity validation system <b>100</b>, including user <b>102</b><i>a</i>, requester <b>116</b>, validator <b>100</b>, and attestation blockchain <b>114</b>.

Referring to <figref idref="DRAWINGS">FIG. 1</figref> in more detail, any member of the system can be an incentivizing party to introduce new users to the system. For example, in step <b>120</b>, user <b>102</b><i>a </i>may introduce new user <b>102</b><i>b </i>to the system. Introduction to new users may happen on an incentivization mechanism with tokens that other participants collectively provide to accelerate the overall adoption of the system. Validator <b>100</b> may be, an individual, a group of individuals, an entity or service provider that is trusted to validate a user's PII. Examples of validators <b>100</b> include but are not limited to financial institutions such as s banks, a government entities, other companies such as utility providers, and verification providers, such as biometrics, network solutions, and device identification providers. User <b>102</b><i>a</i>'s PII may include elements such as name, phone number, e-mail address, address (street, city, country, post code), SSN or FEIN or other government identification number, date of birth, advisory board, number of employees, and any other information that is personal or tied to a specific user.

In some embodiments, user's PII may be structured in a hierarchy. In some embodiments, the structure of user <b>102</b><i>a </i>PII may follow a defined model. In some embodiments, the structure of user <b>102</b><i>a </i>PII may follow an industry standard for a container or framework for personal data. In some embodiments, the negotiation of the interchangeable structure of user <b>102</b><i>a </i>PII and the attestation may be dynamic between participants in the system.

In an embodiment, the probability of a portion of the PII in an attestation is achieved by organizing the PII into a Merkle tree, also known as a hash tree. Hash trees allow efficient and secure verification of the contents of large data structures. In some embodiments, a cryptographic hash function such as SHA-2 (National Security Agency, United States) is used for the hashing. The main difference between a hash tree and a hash list is that one branch of the hash tree can be verified independent of the rest of the tree. This is advantageous in an identity verification application since the data structure containing the PII can be split up into smaller data blocks containing a subset of the PII, so that a user <b>102</b><i>a </i>may share only the PII that the requester <b>116</b> has asked for, without sharing PII that is not needed or was not requested. In addition, if user <b>102</b><i>a </i>wants to update only a portion of their PII, they can revoke and change only this portion of the PII, while not having to revoke and have re-attested the entirety of the PII that is stored. For example, if user <b>102</b><i>a </i>moves and has a new physical address, but their other PII has stayed the same, validator <b>100</b> may be used to authenticate the new physical address and then revoke the node of the existing attestation that contained user <b>102</b><i>a</i>'s previous physical address. A new node is then added with the attested new physical address.

In some examples, for example when implemented on the bitcoin blockchain, each node in the hash tree represents an element of the user PII (for example, name) and contains a hash of its content and a hash of the hashes of its child nodes (for example, first name and last name). The resulting ‘root hash’ (also known as the Merkle root) can be used as a fingerprint for the PII being attested to. In step <b>110</b>, validator <b>100</b> writes the attestation on the attestation blockchain <b>114</b> in the form of a root hash which is signed by validator <b>100</b> using the validator's private key. Validator <b>100</b> records an attestation of user <b>102</b><i>a </i>PII by creating a derived address (an ‘attestation address’) where small amounts of cryptocurrency (e.g. “dust”, or a smallest allowed non-zero value) can be spent. The root hash is converted to a valid bitcoin blockchain address using the additive property of elliptic curve cryptography (‘ECC’):

&lt;br /&gt;<i>k</i>_priv<i>+h=k</i>_attest

Where k_privis the private key of the validator, h is the root hash, and ‘+’ represents addition in the ECC sense. This blockchain address makes it unfeasible to determine the user <b>102</b><i>a </i>and validator <b>100</b> associated with the blockchain address, which is essential to protecting the privacy of the participants. If user <b>102</b><i>a </i>does not wish to reveal all of the underlying PII that was attested to, portions of the hash tree can selectively be revealed, with only hashes provided for any elements user <b>102</b><i>a </i>prefers not to reveal.

Using smart contract platform, the system would store the signed root hash at a discoverable location. Revocation status may in this case also not be represented by unspent currency, but rather modeled as a parameter of the attestation. A participant in the system may reproduce the hash by creating it from the original PII information or from partial information of the original PII if the user <b>102</b><i>a </i>provides intermediate hashes of the Merkle tree. This allows user <b>102</b><i>a </i>to share PII information with another participant in the system and prove that it is the same data that was previously attested to by validator <b>100</b>. Should validator <b>100</b> or user <b>102</b><i>a </i>wish to revoke an attestation for any reason, this revocation is reflected in an associated blockchain transaction, but the details of the attestation can never otherwise be changed.

In step <b>106</b>, validator <b>100</b> sends the attestation of the user <b>102</b><i>a</i>'s PII to user <b>102</b><i>a </i>to store on the user's device. The transmission of the PII from the user <b>102</b><i>a </i>to the validator <b>104</b>, and the transmission of the attestation of the PII from the validator <b>100</b> to user in step <b>106</b> may be secured using end to end encryption or transport encryption as is known in the art. In some embodiments, user <b>102</b><i>a </i>stores the PII on their device. The PII may be encrypted locally on the device before it is stored, for example using biometric data or locks such that only the user may be able to access the plain text PII. The attestation of the PII from validator <b>100</b> may be stored on the user's device. Metadata or other information about validator <b>100</b> may additionally be stored on the user's device. In some embodiments, information such as name, address, identification number (SSN or FEIN for example) and contact details of validator <b>100</b> are stored on the user's device <b>306</b>. In some embodiment, a trust level or reputation of the validator <b>100</b> is stored on the user's device <b>306</b>. The specific attestation that validator <b>100</b> issued and metadata to it are also stored on the user's device, ad user sends this information to the requester when the requester presents PII.

These properties of a validator <b>100</b> may be validated against the attestation blockchain <b>114</b> in order for a third party to determine its authenticity. In some embodiments, the identify verification system operator or a government entity may attest the information that the user <b>102</b><i>a </i>claims about the validator <b>100</b>. The attestation and its metadata which includes the public key of the validator <b>100</b> may also be stored on the user's device <b>306</b> as the user <b>102</b><i>a </i>has to provide this information to the requester <b>116</b> to be able to validate PII against the attestation blockchain <b>114</b>.

User <b>102</b><i>a </i>may try to initiate an interaction with requester <b>116</b>. For example, requester <b>116</b> may be a car rental agency and user <b>102</b><i>a </i>may request to rent a car. To proceed with the interaction, in step <b>118</b>, requester <b>116</b> may request PII from user <b>102</b><i>a</i>. Requester may request the user's first and last name, date of birth, credit card number, credit card expiry date, credit card security number, and billing address for the user's credit card. In some examples, requester <b>116</b> may request additional information, such an accident history of user <b>102</b><i>a</i>, or insurance claim information for user <b>102</b><i>a</i>. In some embodiments, requester <b>116</b> may provide to user <b>102</b><i>a </i>a list of validators that requester <b>116</b> trusts.

In some examples, user <b>102</b><i>a </i>has the data that requester <b>116</b> requires in attested form, from a validator <b>100</b> that requester <b>116</b> trusts. In step <b>108</b>, user <b>102</b><i>a </i>may supply the requested PII in readable form to requester <b>116</b>, along with information about validator <b>100</b> that authenticated the data. In some examples, the information about validator <b>100</b> includes the validator's public key. In some examples, information about validator <b>100</b> includes information about the hashing algorithm used by validator <b>100</b>. In some examples, user <b>102</b><i>a </i>uses end to end encryption when sending PII to the requester <b>116</b> to make sure that the PII is not visible to other parties if it were to be intercepted. In some examples, user <b>102</b><i>a </i>sends the PII in attestation form created by the validator <b>100</b> to requester <b>116</b>.

In step <b>112</b>, requester <b>116</b> may use the requested PII from user <b>102</b><i>a </i>and the information about validator <b>100</b> to check the data authenticity, ownership, and validity of the PII on attestation blockchain <b>114</b>. In some examples, requester <b>116</b> uses the information about validator <b>100</b> to create a hash of the plain text PII sent from user <b>102</b><i>a </i>using the same technique, hashing algorithm, and public key that validator <b>100</b> used to create the attestation on attestation blockchain <b>114</b>. In some examples, requester <b>116</b> creates the attest key using the hashed user PII and the validator's public key, and this attest key is an address on attestation blockchain <b>114</b> If requester <b>116</b> is able to find the transaction for user <b>102</b><i>a </i>at this address on blockchain <b>114</b>, then requester <b>116</b> can be certain that the plain text PII sent to them by user <b>102</b><i>a </i>has been attested to and can be trusted, and requester <b>116</b> may proceed with the transaction that user <b>102</b><i>a </i>initiated.

In a general overview, <figref idref="DRAWINGS">FIG. 2</figref> is an illustration of the token economy system including user <b>102</b><i>a</i>, requester <b>116</b>, validator <b>100</b>, attestation blockchain <b>114</b>, and marketplace blockchain <b>250</b>.

Describing <figref idref="DRAWINGS">FIG. 2</figref> in more detail, the token economy system ensures that users remain in control over their PII, as the user must give consent before any identify verification transaction between validator <b>100</b> and requester <b>116</b> can be completed. In some embodiments, in step <b>204</b>, user <b>102</b><i>a </i>approaches requester <b>116</b> to use a service or purchase a good. Other interactions between user <b>102</b><i>a </i>and requester <b>116</b> such as voting, and trading of securities are also supported. In step <b>208</b>, requester <b>116</b> sends user <b>102</b><i>a </i>a list of requirements. In some embodiments, requester <b>116</b> sends user <b>102</b><i>a </i>a list of validators <b>110</b> acceptable to requester <b>116</b>, and the user PII that is required. If user <b>102</b><i>a </i>has the required PII attested to by a validator <b>100</b> that requester <b>116</b> has indicated is acceptable, the requester <b>116</b> and validator <b>110</b> mutually agree a price for the attested PII. Once the price has been agreed, requester <b>116</b> places tokens into an escrow smart contract within the marketplace blockchain <b>250</b>, then in step <b>210</b>, user <b>102</b><i>a </i>sends the PII to requester <b>116</b> in readable form and sends the attestation and associated metadata (e.g. the validator's public key and other metadata about validator <b>100</b>) that is required for requester <b>116</b> to be able to verify the attestation independently from the plain text PII.

In some embodiments, user <b>102</b><i>a </i>does not have a suitable attestation. In one example, some of user <b>102</b><i>a</i>′ a PII that requester <b>116</b> has required has been attested to by a trusted validator, but some of the user PII that requester <b>116</b> has required has not been attested to by a trusted validator. In some examples, all of the user PII that requester <b>116</b> has required has been attested to, but none of the user PII has been attested to by a validator that requester <b>116</b> accepts. In some examples, none of the user PII that requester <b>116</b> has required has been attested to by any validator. In these and other cases where user <b>102</b><i>a </i>does not have a suitable attestation of the PII that requester <b>116</b> has required, user <b>102</b><i>a </i>will be asked to approach a validator that is accepted by requester <b>116</b> with the required and unverified PII. In step <b>212</b>, user <b>102</b><i>a </i>sends unverified PII to validator <b>100</b>, where validator <b>100</b> is a trusted validator for requester <b>116</b>. Once validator <b>100</b> is satisfied with the authenticity of the PII, it will attest to the accuracy and provenance of this information. This attestation, which in some embodiments may be referred to as a fingerprint of the PII, is recorded onto the attestation blockchain <b>114</b> in step <b>218</b>. In step <b>206</b>, validator <b>100</b> sends verified PII attestation and associated metadata to user <b>102</b><i>a </i>for storage on the user's device <b>306</b>. In some embodiments, the original PII, the attestation, and metadata is stored on the user's mobile device <b>306</b> in an encrypted form. Encryption on the mobile device is an independent layer of security that protects against compromise if user's device is lost or stolen. In some embodiments, stored on the user's device are the encrypted raw PII plus the attestation of the PII and the metadata of the attestation, such that the user is able to issues this information to requester <b>116</b> if required.

Requester <b>116</b> takes user <b>102</b><i>a </i>PII and the information about validator <b>100</b> and recreates the hash of the user's PII. Requester <b>116</b> is not able to reproduce an attestation, but he is able to reproduce the hash of the PII and verify this against the attestation. In step <b>220</b>, requester <b>116</b> inspects the attestation and the attestation blockchain <b>114</b> to see if the attestation is found on the attestation blockchain <b>114</b> at the attest address that requester <b>116</b> created from the user PII. If requester <b>116</b> finds the attestations on the attestation blockchain <b>114</b> at the attest address and it has not been revoked, then the PII from user <b>102</b><i>a </i>is verified, and the requester provides the user with the desired service. When this happens, the smart contract running on a marketplace blockchain <b>250</b> causes the tokens from requester <b>116</b> that are held in escrow to be released. In some embodiments the smart contract running on the marketplace blockchain <b>250</b> causes the tokens from requester <b>116</b> that are held in escrow to be released to be released to the validator <b>100</b> irrespective of whether the requester provides the user with the desired service. In some embodiments, the user <b>102</b><i>a </i>releases the tokens held in escrow as soon as he successfully transmitted the PII, the attestation, and the metadata to the requester. In some embodiments, some tokens are released to the validator <b>100</b>, the user <b>102</b><i>a</i>, or the system operator. In some embodiments, all of the tokens in escrow may be released to either of validator <b>100</b> or user <b>102</b><i>a. </i>

<figref idref="DRAWINGS">FIG. 3</figref> shows a simplified block diagram of a system <b>300</b> for attestations to be shared between identify verification service providers. In a general overview, in some examples, system <b>300</b> includes one or more users <b>102</b><i>a</i>. User <b>102</b><i>a </i>may have a device <b>306</b>. In some examples, system <b>300</b> includes one or more service providers <b>302</b> and <b>304</b>. In some examples, system <b>300</b> includes an attestation <b>308</b> which may be stored on the attestation blockchain <b>114</b>. In some embodiments, system <b>300</b> may utilize a marketplace blockchain <b>250</b>. One or more smart contracts <b>310</b> may be stored on the marketplace blockchain <b>250</b>. In some embodiments, system <b>300</b> may include a token contract <b>314</b> and in some embodiments, system <b>300</b> may include a pricing contract <b>312</b>. A token contract may indicate who owns how many tokens. An escrow contract may encode the transaction of tokens between a requester <b>116</b> and other system participants, such as a user and a validator. A pricing contract may contain the listing price that a validator asks for a one-time transmission of certain PII between user and requester. In some embodiments, an ontology contract may define what kind of predefined PII are traded in the system. In some examples, an identity verification registry may define what validators are registered in the system as well as a fingerprint of their associated metadata, public key, etc.

Referring to <figref idref="DRAWINGS">FIG. 3</figref> in more detail, service provider A <b>302</b> and service provider B <b>304</b> may take on different roles in system <b>300</b>. The roles that service provide A <b>302</b> and service provider B <b>304</b> may take on are the same, and in the detailed discussion of these roles, the term service provider will be used generally to refer to any service provider in system <b>300</b>, including service provider A <b>302</b> and service provider B <b>304</b>. Service provider in system <b>300</b> may take on the role of a user in the system. When acting as a requester <b>116</b> in the system, service provider may desire to have some information about the service provider attested to by a validator <b>100</b> in system <b>300</b>, for example so that a different service provider in system <b>300</b> may be able to verify aspects of the identity of the service provider. When acting as a validator <b>100</b> in the system, service provider may be trusted by a user and/or a requester <b>116</b> to validate the authenticity and provenance of PII. When acting as a requester <b>116</b> in system <b>300</b>, a service provider may have a requirement to verify PII from a user <b>120</b><i>a </i>in system <b>300</b> and may make a request to the user for PII and may make a request to a trusted validator in the system to use an existing attestation of the PII to verify the user <b>102</b><i>a</i>. System <b>300</b> may have any number of service providers, and any of the service providers in system <b>300</b> make take on any of the roles described. At different times, service provider A may act like a user <b>102</b><i>a</i>, a validator <b>100</b>, or a requester <b>116</b>.

In some examples, user <b>102</b><i>a </i>in system <b>300</b> may have control over the user's device <b>306</b>. In some embodiments, user device <b>306</b> may be a personal computer or a laptop computer. In some embodiments, user device <b>306</b> may be a portable computing device such as a tablet or a smartphone. User device <b>306</b> may be a shared device on which user <b>102</b><i>a </i>has a user profile which is accessible to user <b>102</b><i>a </i>by entering a password or pin or other code which is private and known only to user <b>102</b><i>a</i>. In some examples, user device <b>306</b> may be a smart watch which may have direct connectivity to a network or may have connectivity to a network through a separate device controlled by user <b>102</b><i>a</i>, such as a smartphone. User device <b>306</b> may be a connected car. In general, user device <b>306</b> may be any connected device for which all or a partition of the device is solely under control of the user <b>102</b><i>a</i>. In some embodiments, an identity verification application, or any other application, may execute on user device <b>306</b>, the identify verification application configured to execute instructions that enable functionality of system <b>300</b>.

Attestation <b>308</b> represents a hash of PII of user <b>102</b><i>a </i>that is signed by the validator <b>100</b> and recorded on the attestation blockchain <b>114</b>. Attestation <b>308</b> is created by a validator <b>100</b> that has checked and verified that authenticity and provenance of the PII, and once assured of its accuracy has created an attestation <b>308</b>. In some examples, the attestation <b>308</b> may include supporting metadata. The supporting metadata may include the verification level of the validator, and the supporting metadata may include details related to the validator's process of verification. In some examples, the supporting metadata may reference any applicable standards that have been used to structure, organize, or encode the user PII in the attestation <b>308</b>.

In some embodiments, smart contract <b>310</b> is used to capture details of an agreement between a validator <b>100</b> and a requester <b>116</b>. In some examples, service provider A <b>302</b> is a validator <b>100</b> and may have previously attested to the PII that is required from service provider B <b>304</b> which is a requester <b>116</b>, and service provider B <b>304</b> trusts service provider A as a trusted validator. In some examples, service provider B <b>304</b> acting as requester offers a price to service provider A <b>302</b> acting as validator for its attestation of the user's PII. In some examples, the price offered is represented in tokens that are used in system <b>300</b>. The agreement between service provider B <b>304</b> acting as requester and service provider A <b>302</b> acting as validator may be captured in smart contract <b>310</b>. Service provider A <b>302</b> acting as validator interacts with smart contract <b>310</b> and service provider B <b>304</b> acting as requester interacts with smart contract <b>310</b>. In some examples, smart contract <b>310</b> may include details of escrow, where the agreed price in tokens is placed pending the completion of the agreement between user <b>102</b><i>a </i>and service provider B <b>304</b> acting as requester. In some examples, smart contract <b>310</b> is an application, module, or other software component or code that is stored on the marketplace blockchain <b>250</b> and configured to execute when one or more actions take place in system <b>300</b>. In some examples, smart contract <b>310</b> may be an application, service daemon, routine, or other executable logic. Smart contract <b>310</b> may be executed on an operating system or on a virtual machine or may be run in any other appropriate environment. In some embodiments, smart contract <b>310</b>, when executed, causes a graphical user interface to be displayed on user device <b>306</b>. In other embodiments, smart contract <b>310</b> allows for input through a non-graphical user interface, such as a user interface that accepts text or vocal input without displaying an interactive image. A graphical user interface may be displayed on a screen of user device <b>306</b>, or a monitor connected to a desktop or laptop computer or on any other display. User <b>102</b><i>a </i>may interact with e.g. the graphical user interface on the device by typing, clicking a mouse, tapping, speaking, or any other method of interacting with a user interface. The graphical user interface on the device may be a web-based user interface provided by a web browser (e.g. Google Chrome (Google, Mountain View, Calif.), Microsoft Internet Explorer (Microsoft, Redmond, Wash.), or Mozilla Firefox (Mozilla Foundation of Mountain View, Calif.), or may be any other type of interface.

System <b>300</b> may include a token contract <b>314</b> and a pricing contract <b>312</b> as part of the marketplace blockchain <b>250</b>. A token contract <b>314</b> is a distributed ledger on a smart contract platform that tracks the ownership of every token. A pricing contract <b>312</b> contains the listing price that a validator <b>100</b> requests for a one-time transmission of PII between the user <b>102</b><i>a </i>and requester <b>116</b>. In some embodiments, other contracts include an escrow contract which encodes the transaction of tokens between the requester <b>116</b> and the validator <b>100</b> or user <b>102</b><i>a</i>, an ontology contract which defines what kind of predefined PII are traded in the system, and an IDV registry which defines what validators are registered in the system as well as a fingerprint of their associated metadata e.g. public key.

In general overview, <figref idref="DRAWINGS">FIG. 4A</figref> illustrates a method that may be performed by service provider A <b>302</b> acting as a validator in system <b>300</b>. In a general overview of <figref idref="DRAWINGS">FIG. 4A</figref>, in step <b>400</b>, service provider A <b>302</b> verifies user <b>102</b><i>a</i>'s PII using its existing verification method. In step <b>402</b>, service provider A <b>302</b> calculates hashes of the user's PII and records a signed attestation to that PII on the attestation blockchain <b>114</b>. In step <b>404</b>, service provider A <b>302</b> agrees a price for the attestation of the user's PII with service provider B <b>304</b>. Following transmission of PII between user and requester <b>116</b>, in step <b>406</b> tokens are released from escrow to service provider A.

Referring to <figref idref="DRAWINGS">FIG. 4A</figref> in more detail, in some embodiments, no prior attestation for PII exists. Service provider A <b>302</b> verifies the user's PII using its verification methods. Once verified, service provider A <b>302</b> calculates the hashes of that PII and records an attestation to that PII on the attestation blockchain <b>114</b>. In some embodiments, the attestation may also include supporting metadata, such as its verification level, details related to service provider A's <b>302</b> process of verification, or any applicable industry standards. In some embodiments, when implemented on a bitcoin blockchain, the blockchain transaction details of this attestation are then provided to the user <b>102</b><i>a </i>from service provider A <b>302</b>, and the user <b>102</b><i>a </i>stores metadata to the attestation on their device and optionally in a cloud-based or remote storage. Metadata to the attestation may reference the transaction details on the blockchain <b>114</b>.

In a general overview of <figref idref="DRAWINGS">FIG. 4B</figref>, in step <b>430</b>, service provider B <b>304</b> requests access to all or certain portions of PII from the user <b>102</b><i>a</i>, including the rules/requirements around what data service provider B <b>304</b> is willing to accept. <figref idref="DRAWINGS">FIG. 4B</figref> illustrates a method that may be performed by service provider B <b>304</b> acting as a requester in system <b>300</b>. In step <b>432</b>, service provider B <b>304</b> and user <b>102</b><i>a </i>agree on a mutually acceptable validator, service provider A <b>302</b>, that has previously attested to the data and the rules/requirements around the data. In step <b>434</b>, service provider B <b>304</b> places tokens in escrow according to a smart contract <b>310</b> between service provider B <b>304</b> and service provider A <b>302</b>. In step <b>436</b>, service provider B <b>304</b> receives PII from user <b>102</b><i>a </i>in addition to information about service provider A <b>302</b>. In step <b>438</b>, service provider B <b>304</b> creates a hash of the user PII, validates signature by the validator <b>100</b>, verifies that the attestation has not been revoked by the validator <b>100</b>, and compares the hash to a transaction on the marketplace blockchain <b>250</b>. In step <b>440</b>, if service provider B <b>304</b> is satisfied with the resulting hashes, service provider B <b>304</b> provides the good or service to user <b>102</b><i>a. </i>

Referring to <figref idref="DRAWINGS">FIG. 4B</figref> in more detail, in step <b>430</b>, the identify verification application may determine whether these requirements are met with the PII that was previously attested to by service provider A <b>302</b>. In step <b>438</b>, the hash created by service provider B <b>304</b> may be compared to a transaction on the marketplace blockchain <b>250</b>, confirming the authenticity of the requested data. In some embodiments, if service provider B <b>304</b> is satisfied with the resulting hashes, service provider B <b>304</b> can then purchase the attestation from service provider A <b>302</b> and the amount of tokens corresponding to the price of that attestation are released from escrow to service provider A. In some embodiments, the tokens are placed into escrow via the smart contract <b>310</b> before the user transmits the PII and service provider B is able to validate. If a validation is not successful, service provider B may be able to refund the tokens back to its account.

In a general overview, <figref idref="DRAWINGS">FIG. 4C</figref> illustrates a method that may be performed by user <b>102</b><i>a </i>in system <b>300</b>. In step <b>450</b>, user <b>102</b><i>a </i>requests service provider A <b>302</b> to validate user PII. In step <b>452</b>, user <b>102</b><i>a </i>requests a good or service from service provider B <b>304</b>. In step <b>454</b>, user <b>102</b><i>a </i>receives a request for PII and rules or requirements relates to the attestation of the PII from service provider B <b>304</b>. In step <b>456</b>, user <b>102</b><i>a </i>agrees with service provider B <b>304</b> that service provider A <b>302</b> is a mutually acceptable validator that has previously attested to the user's PII according to the rules/requirements related to the PII. In step <b>458</b>, after the user verifies that an escrow payment exists, the user <b>102</b><i>a </i>sends service provider B <b>304</b> the requested PII and information about service provider A <b>302</b> which may trigger the release of tokens from escrow. In step <b>460</b>, user <b>102</b><i>a </i>receives the good or service from service provider B <b>304</b>.

Referring to <figref idref="DRAWINGS">FIG. 4C</figref> in more detail, a user <b>102</b><i>a </i>may apply for a product or service from service provider A <b>302</b> and send the required PII from the identity verification application on the user's device <b>306</b>. In some embodiments, t\in step <b>458</b>, the user may send service provider B <b>304</b> the requested PII and the necessary information (e.g. required attestation metadata) in order for the requester <b>116</b> to reconstruct the Merkle root and compare and validate it against the attestation blockchain <b>114</b>. In some embodiments, once service provider B <b>304</b> has paid the tokens into escrow, the user <b>102</b><i>a</i>, through their identity verification application, can send service provider B <b>304</b> the encrypted PII with the necessary information to validate against the blockchain attestation. The requester <b>116</b> then reconstructs the Merkle tree hash from the provided attestation and compares it to the attestation on the blockchain. In step <b>460</b>, the user may receive the goods and services before the tokens are released from escrow. In some embodiments, the tokens may be shared between the user <b>102</b><i>a </i>and service provider A <b>302</b> at a ratio defined by the smart contract <b>310</b>. In some embodiments, requester puts up a certain price in the escrow contract. The system support takes a fee, the validator fee, etc. The user will only hand out the information once they see that the initial payment was escrowed. The user will only release this information once they have verified from their end that the requester has received the data.

In general overview, <figref idref="DRAWINGS">FIG. 5</figref> shows an illustration of the system goals. In one embodiment, incentives are built into the system through a combination of decisions, flags, penalties and rewards in a repeated interaction between the validator and the requester. The validator is incentivized to maintain their self-defined accuracy or level. This is achieved by requiring that the validator pays a penalty to the network if they are flagged to indicate a belief that they have attested erroneously. No independent party validates that the attestation was actually correct, therefore the penalty is linked to the flagging process of a requires. The validator will pay this penalty out of a stake of tokens. The validator must maintain a minimum stake defined by smart contracts <b>310</b> or smart rules of tokens to use the network.

Referring to <figref idref="DRAWINGS">FIG. 5</figref> in more detail, the requester is rewarded when the validator accepts the statement of the requester. A “correct” flag means, the validator accepts the statement of the requester. No independent party can verify the actual status of the attestation of flag. It's just assumed that the attestation was incorrect when the flag gets accepted, but it not incentivized to falsely report correct attestation. At the Nash equilibrium of the game, whereby no participant in the game can gain an advantage by unilaterally changing their strategy if the other participants maintain their strategies, exists in the system when the validator attest a correct attestation and the requester accepts the correct attestation. In <figref idref="DRAWINGS">FIG. 5</figref>, R represents the requester, and V represents the validator. ‘+’ represents a reward for behavior in the system, and ‘-’ represents a penalty for behavior in the system. The purpose of the incentives is to achieve equilibrium states, where correct validations that are accepted by requesters lead to rewards to both parties, while incorrectly validated PII correctly rejected yields requester rewards, increasing the overall system reliability.

<figref idref="DRAWINGS">FIG. 6A</figref> shows an extensive form of the interaction between requester <b>116</b> and validator <b>100</b>. To create a decentralized identity management system that exhibits a high level of accuracy, the system makes use of embedded incentives that reward accuracy, and penalties that discourage acting falsely. The accuracy of the system is critical. If the system becomes unreliable or unpredictable, then requesters may avoid using it. The problem is how to decide on whether the information provided by either the requester <b>116</b> or the validator <b>100</b> is correct or incorrect. In the identity system, there is a second decision to be made by the validator. In the identity system, the user is removed from the design of incentives in the system, because it is assumed that validators treat all user's PII submissions as false, which is why they set out to verify them in the first place. It is the role of the validator alone to ensure the accuracy of their attestations of User PII. This reduces the system to a two-player game comprising a validator and a requester. In this system, the validator provides the requester with an attestation, where the attestation is either correct or incorrect. The requester reviews the attestation and has two options—either to accept or reject it. The requester must be adequately incentivized to reject an incorrect attestation and to accept a correct attestation. In both cases, the outcome is (R (reward); Pe (penalty)). There is no information available regarding whether the validator has provided an incorrect or correct attestation, other than if the requester rejects it. This has the effect that R can never be greater than the utility of a correct attestation (‘CA’). The requester should never be rewarded for rejecting an incorrect attestation (i.e. R&lt;CA).

In general overview, <figref idref="DRAWINGS">FIG. 6B</figref> shows an extensive form of the interaction between requester <b>116</b> and validator <b>100</b> operating in an outcome space. The requester <b>116</b> reviews the validator's <b>100</b> attestation and has two options, to either flag the attestation as incorrect or to accept the attestation. If the validator <b>100</b> provides an incorrect attestation <b>604</b>, and the requester <b>116</b> accepts this attestation <b>608</b>, the outcome for both the validator and requester is an incorrect attestation <b>612</b>. If the validator <b>100</b> provides a correct attestation <b>602</b> and the requester <b>116</b> accepts the attestation <b>608</b>, the outcome for both the requester and validator is a correct attestation <b>614</b>. If the requester <b>116</b> flags the attestation as incorrect <b>620</b>, then the validator <b>100</b> can either accept <b>626</b> or reject the flag <b>622</b>. The ‘correct flag’ (CF) is the actual reward for a correct flag and the ‘incorrect flag’ (IF) is the actual reward for an incorrect flag. If the validator <b>100</b> provides an incorrect attestation <b>604</b> and the requester <b>116</b> flags this attestation <b>620</b>, the validator <b>100</b> accepts this flag <b>626</b>. The outcome for the requester <b>116</b> and validator <b>100</b> are a ‘correct flag’ (CF) and a penalty respectively <b>628</b>. If the validator <b>100</b> provides a correct attestation <b>602</b> and the requester <b>116</b> flags the attestation <b>620</b>, the validator <b>100</b> rejects the flag <b>622</b>. The outcome for the requester <b>116</b> and validator <b>100</b> are an ‘incorrect flag’ (IF) and a penalty respectively <b>628</b>.

Referring to <figref idref="DRAWINGS">FIG. 6B</figref> in more detail, the penalty is kept the same regardless of whether a validator <b>100</b> accepts or rejects a flag. Assuming the primary non-financial motivation of the validator <b>100</b> would be to make its own system more robust, this would incentivize honesty through accepting a flag if it is indeed an incorrect attestation, since it costs the validator <b>100</b> the same regardless. The validator <b>100</b> may only accept correct flags and only reject incorrect flags. Since the penalty is the same regardless of whether the validator <b>100</b> accepts or rejects a flag, the validator <b>100</b> could potentially reject correct flags to discourage requesters <b>116</b>.

The four game outcomes can be reduced into a simplified normal form. An attestation game is a sequential game with two actors, a requester and a validator operating in an outcome space {Correct Attestation; Correct Attestation (CA;CA) <b>614</b>, Incorrect Attestation; Incorrect Attestation (IA; IA) <b>612</b>, Correct Flag; Penalty (CF; Pe) <b>628</b>, Incorrect Flag; Penalty (IF; Pe) <b>624</b>}. A Fee is given by the requester to the validator for the game to be initiated and CF is the actual reward for a correct flag and IF is the actual reward for an incorrect flag.

The following constraints (Proposition <b>1</b>) produce an exclusive Nash equilibrium of (CA; CA):

&lt;br /&gt;CA&gt;IF&gt;IA|CA,IF,IA∈<img file="US2019349371A1_D0001.tif" />

&lt;br /&gt;CF&gt;IA|CF,IA∈<img file="US2019349371A1_D0002.tif" />

1. (CA; CA): The requester and validator would remain here. Because CA&gt;IF and CA&gt;IA, this scenario produces more utility for both. Therefore (CA; CA) is a Nash equilibrium. &lt;br /&gt; 2. (IF; Pe): The requester would want to move to (CA; CA) to maximize utility given the validator's action and the validator is indifferent given the requester's action. Therefore, this is not a Nash equilibrium. &lt;br /&gt; 3. (IA; IA): The requester would want to move to (CA; CA) since CA&gt;IA and so would the validator. Therefore, this is not a Nash equilibrium. &lt;br /&gt; 4. (CF; Pe): The requester would want to remain since CF&gt;IA and the validator is indifferent, it cannot be guaranteed he would not want to move to (IF; Pe). Therefore, this is not a Nash equilibrium. &lt;br /&gt; This demonstrates that (CA; CA) is the only Nash equilibrium.

If CF, IF&lt;IA, there is no incentive for the requester to flag the attestation. In a repeated game, if the expected reward from flagging is larger than CA then the requester should flag all attestations. With the addition of additional qualitative constraints: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0107">1. CF, IF≤|Pe|, since the reward is paid out from the penalty Pe.</li><li id="ul0002-0002" num="0108">2. IA&gt;Pe, since this is additional discouragement for the validator to provide an incorrect attestation, as the cost of a penalty is greater than the cost of the incorrect attestation being accepted.</li><li id="ul0002-0003" num="0109">3. Fee&lt;|Pe| to ensure that the penalty a validator faces is always larger than the Fee it charges, disincentivizing it from providing incorrect attestations while still making a profit. &lt;br /&gt; We assume IA&lt;0 since the legal consequences of accepting invalid user data (reputationally and/or financially due to a fine) would outweigh any short-term convenience </li></ul></li></ul>

An attestation game is well-posed if the constraints in Proposition <b>1</b> and the qualitative constraints are both satisfied. In other words:

&lt;br /&gt;CA&gt;IF&gt;0&gt;IA&gt;Pe

&lt;br /&gt;CF&gt;IA and CF,IF,Fee≤|Pe|

Given always rational actors in a well-posed attestation game and P (IA) the probability of a validator providing a correct attestation, P (CA)=1−P (IA) the probability of a validator providing an incorrect attestation. Then P (CF):=P ((CF; Pe))=P (IA) and P (IF):=P ((IF; Pe))=P (CA).

Assuming that the validator provides an incorrect attestation, then the requester's choices are to accept it, for a utility gain of IA or to flag it for a utility gain of CF. Since CF&gt;IA and the requester is always rational, the requester will always choose to flag. Therefore P (CF)=1, so P (CF)=P (CF) P (IA)=P (IA). A similar argument holds for P (IF)=P (CA).

The Reward function Re is a discrete random variable over {(CF; Pe); (IF; Pe)}. With Re ((CF; Pe))=CF and Re ((IF; Pe))=IF. Its probability mass function is given by

&lt;br /&gt;<i>P</i>(CF)=<i>P</i>(IA) if Re=CF

&lt;br /&gt;<i>P</i>(IF)=<i>P</i>(CA) if Re=IF

Define R as the expected value of Re, that is

&lt;br /&gt;<i>R:=E</i>[Re]=<i>P</i>(CF)CF+<i>P</i>(IF)IF

A reward function Re (with E [Re]=R) is well-posed if:

&lt;br /&gt;IA&lt;<i>R</i>&lt;CA and <i>R</i>&lt;|Pe|

IF and CF are chosen in such a way that Re is well-posed. The required network incentives are created through a proof-of-stake mechanism making use of the token.

P is the probability of a correct attestation (P(CA)) and

<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><mi>Level</mi><mo>=</mo><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>P</mi></mrow></mfrac></mrow></math></maths>

This P is determined by the validator and can also be considered as the validator's accuracy.

In some embodiments, different confidence levels of accuracy are required for different applications. For example, confidence levels greater than 99.9% may be required for critical use cases. Lower confidence levels may be acceptable for less critical use cases. In some examples, it is more costly for a validator to authenticate user PII to a higher confidence level. The system many include many validators that are able to provide different levels of accuracy, with associated adjustments in prices per attestation. In some embodiments, the system includes penalties for validators that create attestations that are not truthful, creating strong incentives for validators to be accurate and truthful.

In general overview, <figref idref="DRAWINGS">FIG. 7</figref> illustrates sample levels of different validators. Requesters must be confident that validators will maintain a level of accuracy required for their use cases. The identity system of this disclosure is a decentralized system, and the enforcement of accuracy cannot be achieved through a central authority and must instead rely on rewards and penalties. The incentives required to drive the system towards accuracy are created using a branch of game theory called backward induction. In backward induction, the end goal is decided and then a game is designed to attempt to reach this goal.

Rewards and Penalties

In general overview, <figref idref="DRAWINGS">FIG. 8</figref> illustrates the penalty for a flag as the level varies for different values of a system constant (a).

It is proposed that a penalty Pe satisfies the conditions for a well-posed attestation game and subsequently the rewards for a correct flag (CF) and incorrect flag (IF) which produce a well-posed reward function Re.

<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mrow><mrow><mi>Pe</mi><mo>=</mo><mrow><mo>-</mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow></mrow><mo>,</mo><mrow><mi>a</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>ϵ</mi><mo></mo><mrow><mo>[</mo><mrow><mn>0</mn><mo>,</mo><mn>1</mn></mrow><mo>]</mo></mrow></mrow></mrow></mrow></math></maths>

a is a configurable parameter that can be adjusted if observations indicate penalties are too high or too low. Fee&lt;|Pe|, in other words the above Pe is valid for a well-posed attestation game. It is noted that

<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mrow><mrow><mn>0</mn><mo>≤</mo><mi>aP</mi><mo>≤</mo><mn>1</mn></mrow><mo>⇒</mo><mrow><mn>0</mn><mo>≤</mo><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow><mo>≤</mo><mn>1</mn></mrow><mo>⇒</mo><mrow><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac><mo>.</mo></mrow></mrow></math></maths>

So

<maths id="MATH-US-00004" num="00004"><math overflow="scroll"><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>=</mo><mrow><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac><mo>≥</mo><mi>Fee</mi></mrow></mrow></math></maths>

In the rewards CF and IF the process introduces a weighting factor to include a dependence on the flagging history of the requester. Should a requester have a high ratio of previously accepted flags, it should produce a higher reward. This incentivizes the requester to only submit flags if they are likely to be accepted (i.e. incorrect attestations).

AF is defined as the ratio of accepted flags to the total flags in its history. Clearly 0≤AF≤1. w is defined as w∈[0,1] as the weight parameter to indicate how much AF should be weighed in the rewards. w is configurable based upon the behavior of the system.

The reward for setting a correct flag CF is defined as

<maths id="MATH-US-00005" num="00005"><math overflow="scroll"><mrow><mi>CF</mi><mo>=</mo><mrow><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow><mo>·</mo><mfrac><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mn>2</mn></mfrac></mrow></mrow></math></maths>

and the reward for an incorrect flag IF is

<maths id="MATH-US-00006" num="00006"><math overflow="scroll"><mrow><mi>IF</mi><mo>=</mo><mrow><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow><mo>·</mo><mfrac><mrow><mo></mo><mi>Fee</mi><mo></mo></mrow><mn>2</mn></mfrac></mrow></mrow></math></maths>

By definition CF, IF≤|Pe| and therefore are valid for a well-posed attestation game. For future purposes express CA=Fee+S where S&gt;0 is any savings gained by using the system. We can see 0&lt;IF&lt;Fee&lt;CA as required. Now Re can be defined and the formula for R=E (Re):

<maths id="MATH-US-00007" num="00007"><math overflow="scroll"><mrow><mi>R</mi><mo>=</mo><mrow><mrow><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow><mo>·</mo><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mfrac><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mn>2</mn></mfrac></mrow><mo>+</mo><mrow><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow><mo>·</mo><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mfrac><mrow><mo></mo><mi>Fee</mi><mo></mo></mrow><mn>2</mn></mfrac></mrow></mrow></mrow></math></maths>

This formula can be simplified to

<maths id="MATH-US-00008" num="00008"><math overflow="scroll"><mrow><mi>R</mi><mo>=</mo><mrow><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>·</mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mfrac><mrow><mo></mo><mi>Fee</mi><mo></mo></mrow><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow></mrow></mrow></mrow></math></maths>

R, as defined, can be shown to be well posed:

&lt;br /&gt;→0≤<i>P</i>(CA),<i>P</i>(IA)≤1

as they are probabilities, and also

<maths id="MATH-US-00009" num="00009"><math overflow="scroll"><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>=</mo><mrow><mrow><mrow><mn>1</mn><mo>-</mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo>-&gt;</mo><mrow><mrow><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>≤</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>since</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>0</mn></mrow></mrow><mo>≤</mo><mi>AF</mi><mo>≤</mo><mn>1</mn></mrow><mo>-&gt;</mo><mrow><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>≤</mo><mrow><mi>w</mi><mo>+</mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mrow><mo>=</mo><mrow><mrow><mrow><mrow><mn>1</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>since</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>0</mn></mrow><mo>≤</mo><mi>AF</mi><mo>≤</mo><mrow><mn>1</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>by</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>definition</mi></mrow></mrow><mo>-&gt;</mo><mrow><mrow><mi>aP</mi><mo>≤</mo><mn>1</mn></mrow><mo>-&gt;</mo><mrow><mrow><mrow><mn>1</mn><mo>-</mo><mi>P</mi></mrow><mo>≤</mo><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mrow><mo>-&gt;</mo><mrow><mrow><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac><mo>≤</mo><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>P</mi></mrow></mfrac></mrow><mo>-&gt;</mo><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>P</mi></mrow></mfrac></mrow></mrow></mrow></mrow><mo>=</mo><mfrac><mn>1</mn><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow></mfrac></mrow></mrow></mrow></math></maths>

For R to be well posed it needs to satisfy the constraints previously stated:

<maths id="MATH-US-00010" num="00010"><math overflow="scroll"><mrow><mi>IA</mi><mo>&lt;</mo><mi>R</mi><mo>&lt;</mo><mrow><mi>CA</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>and</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>R</mi></mrow><mo>&lt;</mo><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow></mrow></math></maths><maths id="MATH-US-00010-2" num="00010.2"><math overflow="scroll"><mrow><mi>R</mi><mo>=</mo><mrow><mrow><mrow><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo></mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>·</mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>≤</mo><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>≤</mo><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mo>[</mo><mrow><mi>Fee</mi><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>≤</mo><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mn>2</mn><mo>·</mo><mi>Fee</mi></mrow></mrow></mrow><mo>=</mo><mrow><mrow><mi>Fee</mi><mo>&lt;</mo><mrow><mi>Fee</mi><mo>+</mo><mi>S</mi></mrow></mrow><mo>=</mo><mi>CA</mi></mrow></mrow></mrow></math></maths>

Thus, the constraint R&lt;CA is satisfied. Additionally, since IA&lt;0, then:

<maths id="MATH-US-00011" num="00011"><math overflow="scroll"><mrow><mi>R</mi><mo>=</mo><mrow><mrow><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><mrow><mo>[</mo><mrow><mi>w</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>w</mi></mrow><mo>)</mo></mrow><mo>·</mo><mi>AF</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>×</mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow><mo>]</mo></mrow></mrow><mo>≥</mo><mn>0</mn><mo>≥</mo><mi>IA</mi></mrow></mrow></math></maths>

The final requirement is that R&lt;|Pe|:

<maths id="MATH-US-00012" num="00012"><math overflow="scroll"><mrow><mrow><mi>R</mi><mo>≤</mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo>·</mo><mi>Fee</mi></mrow></mrow><mo>]</mo></mrow><mo>≤</mo><mrow><mo>[</mo><mrow><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow><mo>+</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow></mrow><mo>]</mo></mrow><mo>≤</mo><mrow><mrow><mo>[</mo><mrow><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>IA</mi><mo>)</mo></mrow></mrow><mo>+</mo><mrow><mi>P</mi><mo></mo><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow></mrow></mrow><mo>]</mo></mrow><mo></mo><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>aP</mi></mrow></mfrac></mrow></mrow><mo>=</mo><mrow><mfrac><mi>Fee</mi><mrow><mn>1</mn><mo>-</mo><mi>Ap</mi></mrow></mfrac><mo>=</mo><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow></mrow></mrow></math></maths>

The parameter a adjusts the penalty and <figref idref="DRAWINGS">FIG. 8</figref> illustrates how it influences this.

The reward scales with how many previous flags have been accepted. Therefore the requester is also incentivized to be honest when flagging in a repeated game scenario. Even when a requester has had all its previous flags rejected, it is still incentivized to flag an incorrect attestation as there is a non-zero minimum reward (dictated by the weight parameter w). This is a feedback mechanism i.e. if a requester has a high ratio of accepted flags (due to having a high rate of previously accepted flags), and decides (for whatever reason, even though it will always be lower than CA as shown above) to flag correct attestations, it will be rejected, and future rewards will be lower.

Since |Pe|&gt;R in all scenarios, there will be excess incentive amounts |Pe|−R. It is currently proposed that these incentive amounts are locked away separately (not using a centralized solution). In the instance a validator accepts a flag, these incentive amounts will be used to pay out all previous requesters who accepted that attestation or will be distributed to all validators.

In a repeated game, which this is, it can then be shown that regardless of the discount factor (the discount of future game utility), the correct behavior is incentivized.

With a well-posed R in a repeated game with discount factor β&lt;1, accepting correct attestations (honest) is more profitable than always flagging (dishonest). Proof:

The infinite geometric series identity holds as β&lt;1 for convergence:

<maths id="MATH-US-00013" num="00013"><math overflow="scroll"><mrow><mrow><mi>Honest</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>total</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>payout</mi><mo></mo><mstyle><mtext>:</mtext></mstyle><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>0</mn></mrow><mi>∞</mi></munderover><mo></mo><mrow><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow><mo></mo><msup><mrow><mo>(</mo><mi>β</mi><mo>)</mo></mrow><mi>k</mi></msup></mrow></mrow></mrow><mo>=</mo><mfrac><mi>CA</mi><mrow><mn>1</mn><mo>-</mo><mi>β</mi></mrow></mfrac></mrow></math></maths><maths id="MATH-US-00013-2" num="00013.2"><math overflow="scroll"><mrow><mrow><mi>Dishonest</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>total</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>payout</mi><mo></mo><mstyle><mtext>:</mtext></mstyle><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>0</mn></mrow><mi>∞</mi></munderover><mo></mo><mrow><mrow><mo>(</mo><mi>CA</mi><mo>)</mo></mrow><mo></mo><msup><mrow><mo>(</mo><mi>β</mi><mo>)</mo></mrow><mi>k</mi></msup></mrow></mrow></mrow><mo>=</mo><mfrac><mi>R</mi><mrow><mn>1</mn><mo>-</mo><mi>β</mi></mrow></mfrac></mrow></math></maths>

Staking Mechanism

In general overview, <figref idref="DRAWINGS">FIG. 9</figref> illustrates the minimum required stake as more IDs are validated for a particular set of values. Specifically, the required stake of a validator with a penalty of 100 tokens per flag who performs 10,000 attestations.

Referring to <figref idref="DRAWINGS">FIG. 9</figref> in more detail, in order to ensure the right incentives are maintained, a staking mechanism is required. The staking mechanism requires a validator <b>100</b> to hold a defined minimum amount of tokens in order to be an active participant in the system. To ensure that validators have a stake and can pay, they must maintain a minimum stake that secures them against expected claims. This ensures that CA:CA is the Nash equilibrium in the repeated game.

The expected claims are:

<maths id="MATH-US-00014" num="00014"><math overflow="scroll"><mrow><mi>EC</mi><mo>=</mo><mfrac><msub><mi>Total</mi><mi>ID</mi></msub><msub><mi>Level</mi><mi>average</mi></msub></mfrac></mrow></math></maths>

Where Total_IDis the number of IDs that the validator has provided to requesters and Level_averageis the average level of a validator's IDs.

A stake function Stake_min: R→R is feasible if: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0134">1. Stake_min(0)≥b·|Pe|, to cover a base amount of flagged attestations b (configurable by the network and related to EC when it is a new validator).</li><li id="ul0003-0002" num="0135">2. lim_x→∞stake_min(x)=|Pe|·Claim_max+0 (b), where Claim_max€R represents the maximum amount of claims expected for a validator to reach.</li><li id="ul0003-0003" num="0136">3.</li></ul>

<maths id="MATH-US-00015" num="00015"><math overflow="scroll"><mrow><mrow><mrow><mfrac><msub><mi>dStake</mi><mrow><mi>m</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>i</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>n</mi></mrow></msub><mi>dx</mi></mfrac><mo>&gt;</mo><mrow><mn>0</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>and</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mfrac><mrow><msup><mi>d</mi><mn>2</mn></msup><mo></mo><msub><mi>Stake</mi><mrow><mi>m</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>i</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>n</mi></mrow></msub></mrow><mi>dx</mi></mfrac></mrow><mo>&lt;</mo><mrow><mn>0</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>for</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>x</mi><mo></mo><mo></mo><mn>0</mn></mrow></mrow><mo>,</mo><mi>∞</mi></mrow><mo>)</mo></mrow></math></maths>

In other words, the minimum stake grows with diminishing additional costs to the validator. The current stake of a validator must always be greater than or equal to Stake_min(total_ID). C

The minimum stake (Stake_min(total_ID)) should be:

<maths id="MATH-US-00016" num="00016"><math overflow="scroll"><mrow><msub><mi>Stake</mi><mrow><mi>m</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>i</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>n</mi></mrow></msub><mo>=</mo><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo></mo><mrow><mo>(</mo><mrow><mi>b</mi><mo>+</mo><mfrac><mrow><msub><mi>Claim</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub><mo>·</mo><msub><mi>Total</mi><mi>ID</mi></msub></mrow><mrow><mi>growth</mi><mo>+</mo><msub><mi>Total</mi><mi>ID</mi></msub></mrow></mfrac></mrow><mo>)</mo></mrow></mrow></mrow></math></maths>

Where growth €(1, 00) modulates how quickly the required stake grows as a function of the total number of attestations of the validator. Proof;

<maths id="MATH-US-00017" num="00017"><math overflow="scroll"><mrow><mrow><msub><mi>Stake</mi><mrow><mi>m</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>i</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>n</mi></mrow></msub><mo></mo><mrow><mo>(</mo><mn>0</mn><mo>)</mo></mrow></mrow><mo>=</mo><mrow><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>·</mo><mi>b</mi></mrow><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>trivially</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>as</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>required</mi></mrow></mrow></math></maths><maths id="MATH-US-00017-2" num="00017.2"><math overflow="scroll"><mrow><mrow><mi>Let</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>x</mi></mrow><mo>=</mo><mrow><mrow><msub><mi>Total</mi><mi>ID</mi></msub><mo>·</mo><mi>Then</mi></mrow><mo></mo><mstyle><mtext>:</mtext></mstyle></mrow></mrow></math></maths><maths id="MATH-US-00017-3" num="00017.3"><math overflow="scroll"><mrow><mrow><munder><mi>lim</mi><mrow><mi>x</mi><mo>-&gt;</mo><mi>∞</mi></mrow></munder><mo></mo><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>·</mo><mi>b</mi><mo>·</mo><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>·</mo><mfrac><msub><mi>Claim</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub><mrow><mfrac><mi>growth</mi><mi>x</mi></mfrac><mo>+</mo><mn>1</mn></mrow></mfrac></mrow></mrow><mo>=</mo><mrow><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>·</mo><mi>b</mi></mrow><mo>+</mo><mrow><mrow><mo></mo><mi>Pe</mi><mo></mo></mrow><mo>·</mo><msub><mi>Claim</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub></mrow></mrow></mrow></math></maths>

The stake, through including Pe as a variable, is linearly dependent on fee. This ensures that the stake (and the penalty itself) adjusts to changes in the value of the toke in the system since inflation or deflation of a token may be accompanied by a fee adjustment by a validator. This stake ensures that there is sufficient protection for requesters. If the validator decides to leave the system, the stake decays over time using an exponential function, where more tokens are available to be withdrawn over time in an exponential manner.

The withdrawal stake percentage is defined as 100e^t-F, where t is the time in minutes since the withdrawal was requested, up to 5 years and F is five years in minutes. At 5 years, 100% of the stake will be withdrawn. After say one year, only 1.83% can be extracted by the validator. Both requesters and validators can also choose to use other parties e.g. requesters can decide which validator to use and validators can decide which requesters to accept.

B. Computing and Network Environment of the Current Disclosure

Prior to discussing specific embodiments of the present solution, it may be helpful to describe aspects of the operating environment as well as associated system components (e.g. hardware elements) in connection with the methods and systems described herein. Referring to <figref idref="DRAWINGS">FIG. 10A</figref>, an embodiment of a network environment is depicted. In a brief overview, the network environment includes one or more user(s) <b>1002</b><i>a</i>-<b>1002</b><i>n </i>(also generally referred to as local user machines(s) <b>1002</b>, user client(s) <b>1002</b>, user client node(s) <b>1002</b>, user client machine(s) <b>1002</b>, user client computer(s) <b>1002</b>, user client device(s) <b>1002</b>, user endpoint(s) <b>1002</b>, or user endpoint node(s) <b>1002</b>) in communication with one or more verifier(s) <b>1003</b><i>a</i>-<b>1003</b><i>n </i>(also generally referred to as local verifier machines(s) <b>1003</b>, verifier client(s) <b>1003</b>, verifier client node(s) <b>1003</b>, verifier client machine(s) <b>1003</b>, verifier client computer(s) <b>1003</b>, verifier client device(s) <b>1003</b>, verifier endpoint(s) <b>1003</b>, or verifier endpoint node(s) <b>1003</b>), and one or more third-party cosigner(s) <b>1005</b><i>a</i>-<b>1005</b><i>n </i>(also generally referred to as local third-party cosigner machines(s) <b>1005</b>, third-party cosigner client(s) <b>1005</b>, third-party cosigner client node(s) <b>1005</b>, third-party cosigner client machine(s) <b>1005</b>, third-party cosigner client computer(s) <b>1005</b>, third-party cosigner client device(s) <b>1005</b>, third-party cosigner endpoint(s) <b>1005</b>, or third-party cosigner endpoint node(s) <b>1005</b>).

The one or more user(s) <b>1002</b><i>a</i>-<b>1002</b><i>n </i>may be in communication with one or more validator(s) <b>1003</b><i>a</i>-<b>1003</b><i>n </i>(also generally referred to as local validator machines(s) <b>1003</b>, validator client(s) <b>1003</b>, validator client node(s) <b>1003</b>, validator client machine(s) <b>1003</b>, validator client computer(s) <b>1003</b>, validator client device(s) <b>1003</b>, validator endpoint(s) <b>1003</b>, or validator endpoint node(s) <b>1003</b>, and one or more centralized or distributed ledger(s) <b>1006</b><i>a</i>-<b>1006</b><i>n </i>(also generally blockchain(s) <b>1006</b>, centralized or distributed ledger node(s) <b>1006</b>, blockchain node(s) <b>1006</b>, centralized or distributed ledger machine(s) <b>1006</b>, or blockchain machine(s) <b>1006</b>, via one or more networks <b>1004</b>. User client(s) <b>1002</b><i>a</i>-<b>1002</b><i>n</i>, verifier client(s) <b>1003</b><i>a</i>-<b>1003</b><i>n</i>, validator client(s) <b>1007</b><i>a</i>-<b>1007</b><i>n</i>, and third-party cosigner client(s) <b>1005</b><i>a</i>-<b>1005</b><i>n </i>may interact with one or more attestor client(s) <b>1001</b><i>a</i>-<b>1001</b><i>n </i>(also generally referred to as local attestor machines(s) <b>1001</b>, attestor client(s) <b>1001</b>, attestor client node(s) <b>1001</b>, attestor client machine(s) <b>1001</b>, attestor client computer(s) <b>1001</b>, attestor client device(s) <b>1001</b>, attestor endpoint(s) <b>1001</b>, or attestor endpoint node(s) <b>1001</b>).

In some embodiments, a user client <b>1002</b> interfaces with digital wallet provider client <b>1007</b>. In some embodiments, a user client <b>1002</b> has the capacity to function as both a client node seeking verify the identity of a third-party using ID codes. In some embodiments, the user client <b>1002</b> has a validated identity profile that can be verified by a third-party using ID codes. In examples, a validator client <b>1007</b> may be operable to validate the identity of one or more users <b>1002</b>. In embodiments, a validator client <b>1007</b> may be operable to validate an organization, a user, a company, a site, an object, a person, a group of people, and/or the relationship between any of a user, an organization, a company, a site, an object, a person, and a group of people and any other user, organization, company, site, object, person, and group of people. In some embodiments, a verifier client <b>1003</b> may wish to verify the identity of a user, a company, a site, an object, a person, a group of people, and/or the relationship between any of a user, an organization, a company, a site, an object, a person, and a group of people and any other user, organization, company, site, object, person, and group of people, through the use of ID codes.

In some embodiments, one or more third-party cosigner(s) <b>1005</b><i>a</i>-<b>1005</b><i>n</i>, may wish to cosign a validated identity of a user <b>1002</b>. In examples, third-party cosigner(s) <b>1005</b> may digitally sign a record that is recorded on centralized or distributed ledger(s) <b>1006</b>.

Although <figref idref="DRAWINGS">FIG. 10A</figref> shows a network <b>1004</b> between user clients <b>1002</b>, verifier clients <b>1003</b>, third-party cosigner clients <b>1005</b>, attestor clients <b>1001</b>, validator clients <b>1007</b>, digital wallet provider clients <b>1009</b>, and centralized or distributed ledgers <b>1006</b>, the user clients <b>1002</b>, verifier clients <b>1003</b>, third-party cosigner clients <b>1005</b>, attestor clients <b>1001</b>, validator clients <b>1007</b>, digital wallet provider clients <b>1009</b>, and centralized or distributed ledgers <b>1006</b> may be on the same network <b>1004</b>. In some embodiments, there are multiple networks <b>1004</b> between the user clients <b>1002</b>, verifier clients <b>1003</b>, third-party cosigner clients <b>1005</b>, attestor clients <b>1001</b>, validator clients <b>1007</b>, digital wallet provider clients <b>1009</b>, and centralized or distributed ledgers <b>1006</b>. In one of these embodiments, a network <b>1004</b>′ (not shown) may be a private network and a network <b>1004</b> may be a public network. In another of these embodiments, a network <b>1004</b> may be a private network and a network <b>1004</b>′ may be a public network. In still another of these embodiments, networks <b>1004</b> and <b>1004</b>′ may both be private networks.

The network <b>1004</b> may be connected via wired or wireless links. Wired links may include Digital Subscriber Line (DSL), coaxial cable lines, or optical fiber lines. Wireless links may include Bluetooth®, Bluetooth Low Energy (BLE), ANT/ANT+, ZigBee, Z-Wave, Thread, Wi-Fi®, Worldwide Interoperability for Microwave Access (WiMAX®), mobile WiMAX®, WiMAX®-Advanced, NFC, SigFox, LoRa, Random Phase Multiple Access (RPMA), Weightless-N/P/W, an infrared channel or a satellite band. The wireless links may also include any cellular network standards to communicate among mobile devices, including standards that qualify as 1G, 2G, 3G, 4G, or 5G. The network standards may qualify as one or more generations of mobile telecommunication standards by fulfilling a specification or standards such as the specifications maintained by the International Telecommunication Union. The 3G standards, for example, may correspond to the International Mobile Telecommuniations-2000 (IMT-2000) specification, and the 4G standards may correspond to the International Mobile Telecommunication Advanced (IMT-Advanced) specification. Examples of cellular network standards include AMPS, GSM, GPRS, UMTS, CDMA2000, CDMA-1×RTT, CDMA-EVDO, LTE, LTE-Advanced, LTE-M1, and Narrowband IoT (NB-IoT). Wireless standards may use various channel access methods, e.g. FDMA, TDMA, CDMA, or SDMA. In some embodiments, different types of data may be transmitted via different links and standards. In other embodiments, the same types of data may be transmitted via different links and standards.

The network <b>1004</b> may be any type and/or form of network. The geographical scope of the network may vary widely and the network <b>1004</b> can be a body area network (BAN), a personal area network (PAN), a local-area network (LAN), e.g. Intranet, a metropolitan area network (MAN), a wide area network (WAN), or the Internet. The topology of the network <b>1004</b> may be of any form and may include, e.g., any of the following: point-to-point, bus, star, ring, mesh, or tree. The network <b>1004</b> may be an overlay network which is virtual and sits on top of one or more layers of other networks <b>1004</b>′. The network <b>1004</b> may be of any such network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein. The network <b>1004</b> may utilize different techniques and layers or stacks of protocols, including, e.g., the Ethernet protocol, the internet protocol suite (TCP/IP), the ATM (Asynchronous Transfer Mode) technique, the SONET (Synchronous Optical Networking) protocol, or the SDH (Synchronous Digital Hierarchy) protocol. The TCP/IP internet protocol suite may include application layer, transport layer, internet layer (including, e.g., IPv4 and IPv6), or the link layer. The network <b>1004</b> may be a type of broadcast network, a telecommunications network, a data communication network, or a computer network.

In some embodiments, the system may include multiple, logically-grouped servers providing the centralized or distributed ledgers <b>1006</b>. In one of these embodiments, the logical group of servers may be referred to as a server farm or a machine farm. In another of these embodiments, the servers providing the centralized or distributed ledgers <b>1006</b> may be geographically dispersed. In other embodiments, a machine farm may be administered as a single entity. In still other embodiments, the machine farm includes a plurality of machine farms. The servers providing the centralized or distributed ledgers <b>1006</b> within each machine farm can be heterogeneous—one or more of the servers or machines can operate according to one type of operating system platform (e.g., Windows, manufactured by Microsoft Corp. of Redmond, Wash.), while one or more of the other servers can operate according to another type of operating system platform (e.g., Unix, Linux, or Mac OSX).

In one embodiment, servers providing the centralized or distributed ledgers <b>1006</b> in the machine farm may be stored in high-density rack systems, along with associated storage systems, and located in an enterprise data center. In this embodiment, consolidating the servers providing the centralized or distributed ledgers <b>1006</b> in this way may improve system manageability, data security, the physical security of the system, and system performance by locating servers and high-performance storage systems on localized high-performance networks. Centralizing the servers and storage systems and coupling them with advanced system management tools allows more efficient use of server resources.

The servers <b>1006</b> of each machine farm providing the centralized or distributed ledgers <b>1006</b> do not need to be physically proximate to another server in the same machine farm. Thus, the group of servers logically grouped as a machine farm may be interconnected using a wide-area network (WAN) connection or a metropolitan-area network (MAN) connection. For example, a machine farm may include servers physically located in different continents or different regions of a continent, country, state, city, campus, or room. Data transmission speeds between servers in the machine farm can be increased if the servers are connected using a local-area network (LAN) connection or some form of direct connection. Additionally, a heterogeneous machine farm may include one or more servers operating according to a type of operating system, while one or more other servers execute one or more types of hypervisors rather than operating systems. In these embodiments, hypervisors may be used to emulate virtual hardware, partition physical hardware, virtualize physical hardware, and execute virtual machines that provide access to computing environments, allowing multiple operating systems to run concurrently on a host computer. Native hypervisors may run directly on the host computer. Hypervisors may include VMware ESX/ESXi, manufactured by VMWare, Inc., of Palo Alta, Calif.; the Xen hypervisor, an open source product whose development is overseen by Citrix Systems, Inc. of Fort Lauderdale, Fla.; the HYPER-V hypervisors provided by Microsoft, or others. Hosted hypervisors may run within an operating system on a second software level. Examples of hosted hypervisors may include VMWare Workstation and VirtualBox, manufactured by Oracle Corporation of Redwood City, Calif.

Management of the machine farm may be de-centralized. For example, one or more servers may comprise components, subsystems and modules to support one or more management services for the machine farm providing the centralized or distributed ledgers <b>1006</b>. In one of these embodiments, one or more servers provide functionality for management of dynamic data, including techniques for handling failover, data replication, and increasing the robustness of the machine farm. Each server may communicate with a persistent store and, in some embodiments, with a dynamic store.

Server providing the centralized or distributed ledgers <b>1006</b> may be a file server, application server, web server, proxy server, appliance, network appliance, gateway, gateway server, virtualization server, deployment server, SSL VPN server, or firewall. In one embodiment, a plurality of servers may be in the path between any two communicating servers.

Referring to <figref idref="DRAWINGS">FIG. 10B</figref>, a cloud computing environment is depicted. A cloud computing environment may provide user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, and validator client <b>1007</b> with one or more resources provided by a network environment. The cloud computing environment may include one or more user clients <b>1002</b><i>a</i>-<b>1002</b><i>n</i>, one or more verifier clients <b>1003</b><i>a</i>-<b>1003</b><i>n</i>, one or more digital wallet provider clients <b>1009</b><i>a</i>-<b>1009</b><i>n</i>, one or more third-party cosigner clients <b>1005</b><i>a</i>-<b>1005</b><i>n</i>, and one or more validator clients <b>1007</b><i>a</i>-<b>1007</b><i>n </i>in communication with the cloud <b>1008</b> over one or more networks <b>1004</b>. User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may include, e.g., thick clients, thin clients, and zero clients. A thick client may provide at least some functionality even when disconnected from the cloud <b>1008</b> or servers providing the centralized or distributed ledgers <b>1006</b>. A thin client or zero client may depend on the connection to the cloud <b>1008</b> or servers providing the centralized or distributed ledgers <b>1006</b> to provide functionality. A zero client may depend on the cloud <b>1008</b> or other networks <b>1004</b> or servers providing the centralized or distributed ledgers <b>1006</b> to retrieve operating system data for the user client device <b>1002</b>, verifier client device <b>1003</b>, digital wallet provider client device <b>1009</b>, third-party cosigner client device <b>1005</b>, and validator client device <b>1007</b>. The cloud <b>1008</b> may include back end platforms, e.g., servers, storage, server farms or data centers.

The cloud <b>1008</b> may be public, private, or hybrid. Public clouds may include public servers that are maintained by third parties to the user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, and validator client <b>1007</b>, or the owners of the user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, and validator client <b>1007</b>. The servers may be located off-site in remote geographical locations as disclosed above or otherwise. Public clouds may be connected to servers over a public network. Private clouds may include private servers that are physically maintained by a user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, and validator client <b>1007</b>, or owners of a user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, and validator client <b>1007</b>. Private clouds may be connected to the servers over a private network <b>1004</b>. Hybrid clouds may include both the private and public networks <b>1004</b> and servers.

The cloud <b>1008</b> may also include a cloud-based delivery, e.g. Software as a Service (SaaS) <b>1010</b>, Platform as a Service (PaaS) <b>1012</b>, and Infrastructure as a Service (IaaS) <b>1014</b>. IaaS may refer to a user renting the user of infrastructure resources that are needed during a specified time period. IaaS provides may offer storage, networking, servers or virtualization resources from large pools, allowing the users to quickly scale up by accessing more resources as needed. Examples of IaaS include Amazon Web Services (AWS) provided by Amazon, Inc. of Seattle, Wash., Rackspace Cloud provided by Rackspace Inc. of San Antonio, Tex., Google Compute Engine provided by Google Inc. of Mountain View, Calif., or RightScale provided by RightScale, Inc. of Santa Barbara, Calif. PaaS providers may offer functionality provided by IaaS, including, e.g., storage, networking, servers or virtualization, as well as additional resources, e.g., the operating system, middleware, or runtime resources. Examples of PaaS include Windows Azure provided by Microsoft Corporation of Redmond, Wash., Google App Engine provided by Google Inc., and Heroku provided by Heroku, Inc. of San Francisco Calif. SaaS providers may offer the resources that PaaS provides, including storage, networking, servers, virtualization, operating system, middleware, or runtime resources. In some embodiments, SaaS providers may offer additional resources including, e.g., data and application resources. Examples of SaaS include Google Apps provided by Google Inc., Salesforce provided by Salesforce.com Inc. of San Francisco, Calif., or Office365 provided by Microsoft Corporation. Examples of SaaS may also include storage providers, e.g. Dropbox provided by Dropbox Inc. of San Francisco, Calif., Microsoft OneDrive provided by Microsoft Corporation, Google Drive provided by Google Inc., or Apple iCloud provided by Apple Inc. of Cupertino, Calif.

User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may access IaaS resources with one or more IaaS standards, including, e.g., Amazon Elastic Compute Cloud (EC2), Open Cloud Computing Interface (OCCI), Cloud Infrastructure Management Interface (CIMI), or OpenStack standards. Some IaaS standards may allow clients access to resources over HTTP and may use Representational State Transfer (REST) protocol or Simple Object Access Protocol (SOAP). User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may access PaaS resources with different PaaS interfaces. Some PaaS interfaces use HTTP packages, standard Java APIs, JavaMail API, Java Data Objects (JDO), Java Persistence API (JPA), Python APIs, web integration APIs for different programming languages including, e.g., Rack for Ruby, WSGI for Python, or PSGI for Perl, or other APIs that may be built on REST, HTTP, XML, or other protocols. User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may access SaaS resources through the use of web-based user interfaces, provided by a web browser (e.g. Google Chrome, Microsoft Internet Explorer, or Mozilla Firefox provided by Mozilla Foundation of Mountain View, Calif.). User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may also access SaaS resources through smartphone or tablet applications, including e.g., Salesforce Sales Cloud, or Google Drive App. User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, and validator clients <b>1007</b> may also access SaaS resources through the client operating system, including e.g. Windows file system for Dropbox.

In some embodiments, access to IaaS, PaaS, or SaaS resources may be authenticated. For example, a server or authentication server may authenticate a user via security certificates, HTTPS, or API keys. API keys may include various encryption standards such as, e.g., Advanced Encryption Standard (AES). Data resources may be sent over Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

User clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, validator clients <b>1007</b>, and centralized or distributed ledgers <b>1006</b> may be deployed as and/or executed on any type and form of computing device, e.g., a computer, network device or appliance capable of communicating on any type and form of network and performing the operations described herein.

<figref idref="DRAWINGS">FIGS. 10C and 1D</figref> depict block diagrams of a computing device <b>10000</b> useful for practicing an embodiment of attestor clients <b>1001</b>, user clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, or validator clients <b>1007</b>. As shown in <figref idref="DRAWINGS">FIGS. 10C and 1D</figref>, each computing device <b>1000</b> includes a central processing unit <b>1021</b>, and a main memory unit <b>1022</b>. As shown in <figref idref="DRAWINGS">FIG. 10C</figref>, a computing device <b>10000</b> may include a storage device <b>1028</b>, an installation device <b>1016</b>, a network interface <b>1018</b>, and I/O controller <b>1023</b>, display devices <b>1024</b><i>a</i>-<b>1024</b><i>n</i>, a keyboard <b>1026</b> and a pointing device <b>1027</b>, e.g., a mouse. The storage device <b>1028</b> may include, without limitation, an operating system <b>1029</b>, software <b>1031</b>, and a software of a simulated phishing attack system <b>1020</b>. As shown in <figref idref="DRAWINGS">FIG. 1D</figref>, each computing device <b>10000</b> may also include additional optional elements, e.g., a memory port <b>1031</b>, a bridge <b>1070</b>, one or more input/output devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>(generally referred to using reference numeral <b>1030</b>), and a cache memory <b>1040</b> in communication with the central processing unit <b>1021</b>.

The central processing unit <b>1021</b> is any logic circuity that responds to and processes instructions fetched from the main memory unit <b>1022</b>. In many embodiments, the central processing unit <b>1021</b> is provided by a microprocessor unit, e.g.: those manufactured by Intel Corporation of Mountain View, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; the ARM processor and TEGRA system on a chip (SoC) manufactured by Nvidia of Santa Clara, Calif.; the POWER7 processor, those manufactured by International Business Machines of White Plains, N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale, Calif. The computing device <b>10000</b> may be based on any of these processors, or any other processor capable of operating as described herein. The central processing unit <b>1021</b> may utilize instruction level parallelism, thread level parallelism, different levels of cache, and multi-core processors. A multi-core processor may include two or more processing units on a single computing component. Examples of multi-core processors include the AMD PHENOM IIX2, INTER CORE i5 and INTEL CORE i7.

Main memory unit <b>1022</b> may include on or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor <b>1021</b>. Main memory unit <b>1022</b> may be volatile and faster than storage <b>1028</b> memory. Main memory units <b>1022</b> may be Dynamic Random-Access Memory (DRAM) or any variants, including static Random-Access Memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Single Data Rate Synchronous DRAM (SDR SDRAM), Double Data Rate SDRAM (DDR SDRAM), Direct Rambus DRAM (DRDRAM), or Extreme Data Rate DRAM (XDR DRAM). In some embodiments, the main memory <b>1022</b> or the storage <b>1028</b> may be non-volatile; e.g., non-volatile read access memory (NVRAM), flash memory non-volatile static RAM (nvSRAM), Ferroelectric RANI (FeRAM), Magnetoresistive RANI (MRAM), Phase-change memory (PRAM), conductive-bridging RAM (CBRAM), Silicon-Oxide-Nitride-Oxide-Silicon (SONOS), Resistive RAM (RRAM), Racetrack, Nano-RAM (NRAM), or Millipede memory. The main memory <b>1022</b> may be based on any of the above described memory chips, or any other available memory chips capable of operating as described herein. In the embodiment shown in <figref idref="DRAWINGS">FIG. 10C</figref>, the processor <b>1021</b> communicates with main memory <b>1022</b> via a system bus <b>1050</b> (described in more detail below). <figref idref="DRAWINGS">FIG. 1D</figref> depicts an embodiment of a computing device <b>1000</b> in which the processor communicates directly with main memory <b>1022</b> via a memory port <b>1031</b>. For example, in <figref idref="DRAWINGS">FIG. 1D</figref> the main memory <b>1022</b> may be DRDRAM.

<figref idref="DRAWINGS">FIG. 1D</figref> depicts and embodiment in which the main processor <b>1021</b> communicates directly with cache memory <b>1040</b> via a secondary bus, sometimes referred to as a backside bus. In other embodiments, the main processor <b>1021</b> communicates with cache memory <b>1040</b> using the system bus <b>1050</b>. Cache memory <b>1040</b> typically has a faster response time than main memory <b>1022</b> and is typically provided by SRAM, BSRAM, or EDRAM. In the embodiment shown in <figref idref="DRAWINGS">FIG. 1D</figref>, the processor <b>1021</b> communicates with various I/O devices <b>1030</b> via a local system bus <b>1050</b>. Various buses may be used to connect the central processing unit <b>1021</b> to any of the I/O devices <b>1030</b>, including a PCI bus, a PCI-X bus, or a PCI-Express bus, or a NuBus. For embodiments in which the I/O device is a video display <b>1024</b>, the processor <b>1021</b> may use an Advanced Graphic Port (AGP) to communicate with the display <b>1024</b> or the I/O controller <b>1023</b> for the display <b>1024</b>. <figref idref="DRAWINGS">FIG. 1D</figref> depicts and embodiment of a computer <b>1000</b> in which the main processor <b>1021</b> communicates directly with I/O device <b>1030</b><i>b </i>or other processors <b>1021</b>′ via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communications technology.

<figref idref="DRAWINGS">FIG. 1D</figref> also depicts an embodiment in which local busses and direct communication are mixed: the processor <b>1021</b> communicates with I/O device <b>1030</b><i>a </i>using a local interconnect bus while communicating with I/O device <b>1030</b><i>b </i>directly.

A wide variety of I/O devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>may be present in the computing device <b>10000</b>. Input devices may include keyboards, mice, trackpads, trackballs, touchpads, touch mice, multi-touch touchpads and touch mice, microphones, multi-array microphones, drawing tablets, cameras, single-lens reflex cameras (SLR), digital SLR (DSLR), CMOS sensors, accelerometers, infrared optical sensors, pressure sensors, magnetometer sensors, angular rate sensors, depth sensors, proximity sensors, ambient light sensors, gyroscopic sensors, or other sensors. Output devices may include video displays, graphical displays, speakers, headphones, inkjet printers, laser printers, and 3D printers.

Devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>may include a combination of multiple input or output devices, including, e.g., Microsoft KINECT, Nintendo Wiimote for the WII, Nintendo WII U GAMEPAD, or Apple iPhone. Some devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>allow gesture recognition inputs through combining some of the inputs and outputs. Some devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>provide for facial recognition which may be utilized as an input for different purposes including authentication and other commands. Some devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>provide for voice recognition and inputs, including, e.g., Microsoft KINECT, SIRI for iPhone by Apple, Google Now or Google Voice Search, and Alexa by Amazon.

Additional devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>have both input and output capabilities, including, e.g., haptic feedback devices, touchscreen displays, or multi-touch displays. Touchscreen, multi-touch displays, touchpads, touch mice, or other touch sensing devices may use different technologies to sense touch, including, e.g., capacitive, surface capacitive, projected capacitive touch (PCT), in cell capacitive, resistive, infrared, waveguide, dispersive signal touch (DST), in-cell optical, surface acoustic wave (SAW), bending wave touch (BWT), or force-based sensing technologies. Some multi-touch devices may allow two or more contact points with the surface, allowing advanced functionality including, e.g., pinch, spread, rotate, scroll, or other gestures. Some touchscreen devices, including, e.g., Microsoft PIXELSENSE or Multi-Touch Collaboration Wall, may have larger surfaces, such as on a table-top or on a wall, and may also interact with other electronic devices. Some I/O devices <b>1030</b><i>a</i>-<b>1030</b><i>n</i>, display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>or group of devices may be augmented reality devices. The I/O devices may be controlled by an I/O controller <b>1023</b> as shown in <figref idref="DRAWINGS">FIG. 10C</figref>. The I/O controller may control one or more I/O devices, such as, e.g., a keyboard <b>126</b> and a pointing device <b>1027</b>, e.g., a mouse or optical pen. Furthermore, an I/O device may also provide storage and/or an installation medium <b>1016</b> for the computing device <b>1000</b>. In still other embodiments, the computing device <b>1000</b> may provide USB connections (not shown) to receive handheld USB storage devices. In further embodiments, a I/O device <b>1030</b> may be a bridge between the system bus <b>1050</b> and an external communication bus, e.g. a USB bus, a SCSI bus, a FireWire bus, an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channel bus, or a Thunderbolt bus.

In some embodiments, display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>may be connected to I/O controller <b>1023</b>. Display devices may include, e.g., liquid crystal displays (LCD), thin film transistor LCD (TFT-LCD), blue phase LCD, electronic papers (e-ink) displays, flexile displays, light emitting diode displays (LED), digital light processing (DLP) displays, liquid crystal on silicon (LCOS) displays, organic light-emitting diode (OLED) displays, active-matrix organic light-emitting diode (AMOLED) displays, liquid crystal laser displays, time-multiplexed optical shutter (TMOS) displays, or 3D displays. Examples of 3D displays may use, e.g. stereoscopy, polarization filters, active shutters, or auto stereoscopy. Display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>may also be a head-mounted display (HMD). In some embodiments, display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>or the corresponding I/O controllers <b>1023</b> may be controlled through or have hardware support for OPENGL or DIRECTX API or other graphics libraries.

In some embodiments, the computing device <b>1000</b> may include or connect to multiple display devices <b>1024</b><i>a</i>-<b>1024</b><i>n</i>, which each may be of the same or different type and/or form. As such, any of the I/O devices <b>1030</b><i>a</i>-<b>1030</b><i>n </i>and/or the I/O controller <b>1023</b> may include any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of multiple display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>by the computing device <b>1000</b>. For example, the computing device <b>1000</b> may include any type and/or form of video adapter, video card, driver, and/or library to interface, communicate, connect or otherwise use the display devices <b>1024</b><i>a</i>-<b>1024</b><i>n</i>. In one embodiment, a video adapter may include multiple connectors to interface to multiple display devices <b>1024</b><i>a</i>-<b>1024</b><i>n</i>. In other embodiments, the computing device <b>1000</b> may include multiple video adapters, with each video adapter connected to one or more of the display devices <b>1024</b><i>a</i>-<b>1024</b><i>n</i>. In some embodiments, any portion of the operating system of the computing device <b>1000</b> may be configured for using multiple displays <b>1024</b><i>a</i>-<b>1024</b><i>n</i>. In other embodiments, one or more of the display devices <b>1024</b><i>a</i>-<b>1024</b><i>n </i>may be provided by one or more other computing devices <b>1000</b><i>a </i>or <b>100</b><i>b </i>connected to the computing device <b>1000</b>, via the network <b>1004</b>. In some embodiments software may be designed and constructed to use another computer's display device as a second display device <b>1024</b><i>a </i>for the computing device <b>1000</b>. For example, in one embodiment, an Apple iPad may connect to a computing device <b>1000</b> and use the display of the device <b>100</b> as an additional display screen that may be used as an extended desktop. One ordinarily skilled in the art will recognize and appreciate the various ways and embodiments that a computing device <b>1000</b> may be configured to have multiple display devices <b>1024</b><i>a</i>-<b>1024</b><i>n. </i>

Referring again to <figref idref="DRAWINGS">FIG. 10C</figref>, the computing device <b>1000</b> may comprise a storage device <b>1028</b> (e.g. one or more hard disk drives or redundant arrays of independent disks) for storing an operating system or other related software, and for storing application software programs such as any program related to the software <b>120</b>. Examples of storage device <b>1028</b> include, e.g., hard disk drive (HDD); optical drive including CD drive, DVD drive, or BLU-RAY drive; solid-state drive (SSD); USB flash drive; or any other device suitable for storing data. Some storage devices may include multiple volatile and non-volatile memories, including, e.g., solid state hybrid drives that combine hard disks with solid state cache. Some storage device <b>1028</b> may be non-volatile, mutable, or read-only. Some storage device <b>1028</b> may be internal and connect to the computing device <b>1000</b> via a bus <b>1050</b>. Some storage device <b>1028</b> may be external and connect to the computing device <b>1000</b> via a I/O device <b>1030</b> that provides an external bus. Some storage device <b>1028</b> may connect to the computing device <b>1000</b> via the network interface <b>1018</b> over a network <b>1004</b>, including, e.g., the Remote Disk for MACBOOK AIR by Apple. Some client devices <b>100</b> may not require a non-volatile storage device <b>1028</b> and may be thin clients or zero equipment clients <b>1002</b> and/or operator clients <b>1003</b>. Some storage device <b>1028</b> may also be used as an installation device <b>1016</b> and may be suitable for installing software and programs. Additionally, the operating system and the software can be run from a bootable medium, for example, a bootable CD, e.g. KNOPPIX, a bootable CD for GNU/Linux that is available as a GNU/Linux distribution from knoppix.net.

Client device <b>1000</b> may also install software or application from an application distribution platform. Examples of application distribution platforms include the App Store for iOS provided by Apple, Inc., the Mac App Store provided by Apple, Inc., GOOGLE PLAY for Android OS provided by Google Inc., Chrome Webstore for CHROME OS provided by Google Inc., and Amazon Appstore for Android OS and KINDLE FIRE provided by Amazon.com, Inc. An application distribution platform may facilitate installation of software on attestor clients <b>1001</b>, user clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, or validator clients. An application distribution platform may include a repository of applications on a server or a cloud <b>1008</b>, which attestor clients <b>1001</b>, user clients <b>1002</b>, verifier clients <b>1003</b>, digital wallet provider clients <b>1009</b>, third-party cosigner clients <b>1005</b>, or validator clients <b>1007</b> may access over a network <b>1004</b>. An application distribution platform may include application developed and provided by various developers. A user of an attestor client <b>1001</b>, user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, or validator client <b>1007</b> may select, purchase and/or download an application via the application distribution platform.

Furthermore, the computing device <b>1000</b> may include a network interface <b>1018</b> to interface to the network <b>1004</b> through a variety of connections including, but not limited to, standard telephone lines LAN or WAN links (e.g., 802.11, T1, T3, Gigabit Ethernet, InfiniBand), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET, ADSL, VDSL, BPON, GPON, fiber optical including FiOS), wireless connections, or some combination of any or all of the above. Connections can be established using a variety of communication protocols (e.g., TCP/IP, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), IEEE 802.11a/b/g/n/ac CDMA, GSM, WiMAX and direct asynchronous connections). In one embodiment, the computing device <b>1000</b> communicates with other computing devices <b>1000</b>′ via any type and/or form of gateway or tunneling protocol e.g. Secure Socket Layer (SSL) or Transport Layer Security (TLS), or the Citrix Gateway Protocol manufactured by Citrix Systems, Inc. The network interface <b>1018</b> may comprise a built-in network adapter, network interface card, PCMCIA network card, EXPRESSCARD network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device <b>1000</b> to any type of network capable of communication and performing the operations described herein.

A computing device <b>1000</b> of the sort depicted in <figref idref="DRAWINGS">FIGS. 10B and 10C</figref> may operate under the control of an operating system, which controls scheduling of tasks and access to system resources. The computing device <b>1000</b> can be running any operating system such as any of the versions of the MICROSOFT WINDOWS operating systems, the different releases of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein. Typical operating systems include, but are not limited to: WINDOWS 2000, WINDOWS Server 2012, WINDOWS CE, WINDOWS Phone, WINDOWS XP, WINDOWS VISTA, and WINDOWS 7, WINDOWS RT, WINDOWS 8 and WINDOW 10, all of which are manufactured by Microsoft Corporation of Redmond, Wash.; MAC OS and iOS, manufactured by Apple, Inc.; and Linux, a freely-available operating system, e.g. Linux Mint distribution (“distro”) or Ubuntu, distributed by Canonical Ltd. of London, United Kingdom; or Unix or other Unix-like derivative operating systems; and Android, designed by Google Inc., among others. Some operating systems, including, e.g., the CHROME OS by Google Inc., may be used on zero clients or thin clients, including, e.g., CHROMEBOOKS.

The computing device <b>1000</b> can be any workstation, telephone, desktop computer, laptop or notebook computer, netbook, ULTRABOOK, tablet, server, handheld computer, mobile telephone, smartphone or other portable telecommunications device, media playing device, a gaming system, mobile computing device, or any other type and/or form of computing, telecommunications or media device that is capable of communication. The computing device <b>1000</b> has sufficient processor power and memory capacity to perform the operations described herein. In some embodiments, the computing device <b>1000</b> may have different processors, operating systems, and input devices consistent with the device. The Samsung GALAXY smartphones, e.g., operate under the control of Android operating system developed by Google, Inc. GALAXY smartphones receive input via a touch interface.

In some embodiments, the computing device <b>1000</b> is a gaming system. For example, the computing device <b>1000</b> may comprise a PLAYSTATION 3, or PERSONAL PLAYSTATION PORTABLE (PSP), or a PLAYSTATION VITA device manufactured by the Sony Corporation of Tokyo, Japan, or a NINTENDO DS, NINTENDO 3DS, NINTENDO WII, or a NINTENDO WII U device manufactured by Nintendo Co., Ltd., of Kyoto, Japan, or an XBOX 360 device manufactured by Microsoft Corporation.

In some embodiments, the computing device <b>1000</b> is a digital audio player such as the Apple IPOD, IPOD Touch, and IPOD NANO lines of devices, manufactured by Apple Computer of Cupertino, Calif. Some digital audio players may have other functionality, including, e.g., a gaming system or any functionality made available by an application from a digital application distribution platform. For example, the IPOD Touch may access the Apple App Store. In some embodiments, the computing device <b>1000</b> is a portable media player or digital audio player supporting file formats including, but not limited to, MP3, WAV, M4A/AAC, WMA Protected AAC, AIFF, Audible audiobook, Apple Lossless audio file formats and .mov, .m4v, and .mp4 MPEG-4 (H.264/MPEG-4 AVC) video file formats.

In some embodiments, the computing device <b>1000</b> is a tablet e.g. the IPAD line of devices by Apple; GALAXY TAB family of devices by Samsung; or KINDLE FIRE, by Amazon.com, Inc. of Seattle, Wash. In other embodiments, the computing device <b>1000</b> is an eBook reader, e.g. the KINDLE family of devices by Amazon.com, or NOOK family of devices by Barnes &amp; Noble, Inc. of New York City, N.Y.

In some embodiments, attestor client <b>1001</b>, user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, or validator client <b>1007</b> includes a combination of devices, e.g. a smartphone combined with a digital audio player or portable media player. For example, one of these embodiments is a smartphone, e.g. the iPhone family of smartphones manufactured by Apple, Inc.; a Samsung GALAXY family of smartphones manufactured by Samsung, Inc; or a Motorola DROID family of smartphones. In yet another embodiment, attestor client <b>1001</b>, user client <b>1002</b>, verifier client <b>1003</b>, digital wallet provider client <b>1009</b>, third-party cosigner client <b>1005</b>, or validator client <b>1007</b> is a laptop or desktop computer equipped with a web browser and a microphone and speaker system, e.g. a telephony headset. In these embodiments, attestor client devices <b>1001</b><i>a</i>-<b>1001</b><i>n</i>, user client devices <b>1002</b><i>a</i>-<b>1002</b><i>n</i>, verifier client devices <b>1003</b><i>a</i>-<b>1003</b><i>n</i>, digital wallet provider client devices <b>1009</b><i>a</i>-<b>1009</b><i>n</i>, third-party cosigner client devices <b>1005</b><i>a</i>-<b>1005</b><i>n</i>, or validator client devices <b>1007</b><i>a</i>-<b>1007</b><i>n </i>are web-enabled and can receive and initiate phone calls. In some embodiments, a laptop or desktop computer is also equipped with a webcam or other video capture device that enables video chat and video call.

In some embodiments, the status of one or more machines <b>1001</b>, <b>1002</b>, <b>1003</b>, <b>1005</b>, <b>1007</b> and/or <b>1009</b> in the network <b>1004</b> is monitored, generally as part of network management. In one of these embodiments, the status of a machine may include an identification of load information (e.g., the number of processes on the machine, CPU and memory utilization), of port information (e.g., the number of available communication ports and the port addresses), or of session status (e.g., the duration and type of processes, and whether a process is active or idle). In another of these embodiments, this information may be identified by a plurality of metrics, and the plurality of metrics can be applied at least in part towards decisions in load distribution, network traffic management, and network failure recovery as well as any aspects of operations of the present solution described herein. Aspects of the operating environments and components described above will become apparent in the context of the systems and methods disclosed herein.

In a general overview, <figref idref="DRAWINGS">FIG. 11</figref> shows a digital identity platform <b>2000</b> that individuals may use to verify the legitimacy of a company and/or organization and/or entity and verify a users' relationship with the company and/or organization and/or entity. In examples, digital identity platform <b>2000</b> may include company/organization <b>2020</b>. Company/organization <b>2020</b> includes one or more users <b>1002</b>, which can be employees or representatives of company/organization <b>2020</b>, such a user will hereafter be identified as “employee user <b>1002</b>” to differentiate them from other users in digital identity platform <b>2000</b>. In embodiments, company/organization <b>2020</b> may desire to form a relationship with one or more users <b>2025</b>, which can be advisors, associates, or other users with a relationship with company/organization <b>2020</b> who are not employee users <b>1002</b>, such a user will hereafter be identified as “connection user <b>2025</b>” to differentiate them from other users in digital identity platform <b>2000</b>. Digital identity platform <b>2000</b> may include one or more verifiers <b>1003</b>, which can be any third-party individual wishing to verify a relationship between a connection user <b>2025</b> and a company/organization <b>2020</b>. Digital identity platform <b>2000</b> may include one or more centralized or distributed ledgers <b>1006</b>, each centralized or distributed ledger comprising a plurality of records <b>2010</b><i>a</i>-<b>2010</b><i>n</i>. Digital identity platform <b>2000</b> may include attestor <b>1001</b>, and validator <b>1007</b>. In examples, digital identity platform <b>2000</b> includes ID codes platform <b>2005</b>.

Referring to <figref idref="DRAWINGS">FIG. 11</figref> in more detail, in some embodiments, digital identity platform <b>2000</b> includes one or more attestor <b>1001</b>. Attestor <b>1001</b> may include, without limitation, a company, person, computer-implemented algorithm, decentralized computing system, a client-server application, a desktop application, or a mobile application. In embodiments, an attestor is accessed in digital identity platform <b>2000</b> through an attestor console available on a client or device. In examples, Attestor <b>1001</b> is configured to confirm, authenticate, and attest to information from an individual, a company/organization <b>2020</b>, or any other entity and to create a record <b>2010</b> on centralized or distributed ledger <b>1006</b>. In some embodiments, attestor <b>1001</b> may have a private and a public encryption key. In some embodiments, attestor <b>1001</b> may be integrated with or coupled to memory <b>1022</b>. In some embodiments, memory <b>1022</b> may include any type and form of storage, such as a database or file system. Memory <b>1022</b> may store data such as parameters and scripts corresponding to the choices made by attestor <b>1001</b>, e.g. as described above for authenticating and certifying information. Attestor <b>1001</b> may comprise a program, service, task, script, library, application or any type and form of executable instructions or code executable on one or more processors. Attestor <b>1001</b> may be combined or separated into one or more modules, applications, programs, services, tasks, scripts, libraries, applications, or executable code.

In examples, digital identity platform <b>2000</b> includes validator <b>1007</b>. Validator <b>1007</b> may include without limitation an identity validation service provider, a biometric device, any entity who knows an individual or an entity personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like. In some examples, a validator may include without limitation someone or something that confirms the validity, accuracy, ownership, or other proprietary aspect of information or property belonging to an entity. In some embodiments, validator <b>1007</b> may be integrated with or coupled to memory <b>1022</b>. In some embodiments, memory <b>1022</b> may include any type and form of storage, such as a database or file system. Memory <b>1022</b> may store data such as parameters and scripts corresponding to the choices made by a validator <b>1007</b>, e.g., as described above for confirming the validity, accuracy, ownership, or other propriety aspect of information. Validator <b>1007</b> may comprise a program, service, task, script, library, application or any type and form of executable instructions or code executable on one or more processors. Validator <b>1007</b> may be combined or separated into one or more modules, applications, programs, services, tasks, scripts, libraries, applications, or executable code.

Digital identity platform <b>2000</b> may include company/organization <b>2020</b>. In embodiments, company/organization <b>2020</b> may be any individual, company, organization, group, team, group of individuals or entity with which any other any individual, company, organization, group, team, group of individuals or entity may have an association with. In some embodiments, company/organization <b>2020</b> has one or more associated domains, for example www.company.com, on which company/organization <b>2020</b> displays information. In some embodiments, company/organization may have one or more other virtual representations on the internet, for example company/organization <b>2020</b> may have a LinkedIn page (LinkedIn Corporation, Sunnyvale Calif.), or a twitter feed (Twitter Inc., San Francisco, Calif.), which may be used to verify the legitimacy of company/organization <b>2020</b>. Company/organization <b>2020</b> may be a corporation, a limited liability company, a partnership, a group, a non-profit organization, a school, and institution, a college or university, a firm, or any other person or collection of people with a common purpose. Company/organization <b>2020</b> may have a physical location and address or may be virtual.

In some embodiments, company/organization <b>220</b> has individuals that are associated with company/organization <b>2020</b>, for example employee <b>1002</b>. Employee <b>1002</b> may be a member of company/organization <b>2020</b>, a contractor for company/organization <b>2020</b>, a representative of company/organization <b>2020</b>, a principal or owner of company/organization <b>2020</b> or any other individual that is qualified, entitled, appointed, or agreed to represent aspects of company/organization <b>2020</b>. Employee <b>1002</b> may also refer to a device of an employee or associated with an employee, such as a mobile device, laptop computer, portable computer, desktop computer, etc. or any other such device.

Digital identity platform <b>2000</b> may include connection client <b>2025</b> (also generally referred to as local connection machines(s) <b>2025</b>, connection client(s) <b>2025</b>, connection client node(s) <b>2025</b>, connection client machine(s) <b>2025</b>, connection client computer(s) <b>2025</b>, connection client device(s) <b>2025</b>, connection endpoint(s) <b>2025</b>, or connection endpoint node(s) <b>2025</b>. In examples, connection <b>2025</b> may wish, or been invited to, establish a relationship with company/organization <b>2020</b>. In some embodiments, connection <b>2025</b> may be known as an expert in a field that is relevant to company/organization <b>2020</b>, such that it would benefit company/organization <b>2020</b> to publicize the relationship between connection <b>2025</b> and company/organization <b>2020</b>. In embodiments, it may benefit connection <b>2025</b> to be publicly associated with company/organization <b>2020</b>. In embodiments, connection <b>2025</b> and company/organization agree that there is a relationship between connection <b>2025</b> and company/organization <b>2020</b>. In some embodiments, connection <b>2025</b> is known to attestor <b>1001</b> and has had information previously attested to and certified on a centralized or distributed ledger by attestor <b>1001</b>. In examples, connection <b>2025</b> is not known to attestor <b>101</b>.

Digital identity platform <b>2000</b> may include centralized or distributed ledger <b>1006</b>, together with one or more records <b>2010</b><i>a</i>-<b>2010</b><i>n</i>. A digital ledger is a record of associations, for example between people and information or people and things. A centralized ledger or centralized database is a system where data is stored in a master database with a single point of control. A gatekeeper party acts on behalf of people to modify the state of the ledger. In a distributed ledger, any party on the network <b>1004</b> has access to the ledger. The distributed ledger is replicated among many different nodes in network <b>1004</b>, and a consensus algorithm ensures that each node's copy of the ledger is identical to every other node's copy. In some embodiments, attestor <b>1001</b> must use cryptographic signatures to create records <b>2010</b> on a centralized or distributed ledger <b>1006</b>.

In some embodiments, an attestation address is the address at which a record from attestor <b>1001</b> can be found on centralized or distributed ledger <b>1006</b>. In examples, for a single signature record, a hash function, for example the P2PKH algorithm, maybe be applied to an input to create an attestation address. In examples, an attestation address may be a multisig attestation address, wherein an input is signed with public keys of all cosigners according to an “M of N” multisig redeem script cryptographic signing protocol. Potential cosigners can include, but are not limited to, digital wallet provider client <b>1009</b>, attestor <b>1001</b>, user client <b>1002</b>, and third-party cosigner client <b>1005</b>. Multi-signature records at an attestation address may be revoked if M-of-N cosigners sign a transaction “spending” the record from the attestation address. In implementations, a multisig attestation address comprises two or more public keys and is created using the Pay To Script Hash (P2SH) protocol.

In some embodiments, digital identity platform <b>2000</b> includes verifier <b>1003</b>. Verifier <b>1003</b> may be any individual, business, advisor, connection, associate, company, organization, or any other entity that wishes to verify a relationship between connection <b>2025</b> and company/organization <b>2020</b>. In some examples, verifier <b>1003</b> wishes to ascertain, for example for an individual displayed on a website of a company/organization <b>2020</b> and purported to have a relationship with the company/organization <b>2020</b>, whether the individual is a genuine individual, and/or whether the individual truthfully holds the purported relationship with the company/organization <b>2020</b>.

Digital identity platform <b>2000</b> includes ID codes platform <b>2005</b>. In some examples, verifier <b>1003</b> will traverse to ID codes platform <b>2005</b> if they interact with an ID codes badge associated with connection <b>2025</b> on a website of company/organization <b>2020</b>. In embodiments, ID codes platform <b>2005</b> is configured to display information about connection <b>2025</b>, for example LinkedIn profile of connection <b>2025</b> and/or twitter account of connection <b>2025</b>. In some examples, for a connection <b>2025</b>, ID codes platform <b>2005</b> is configured to display information on one or more connections of connection <b>2025</b>, which may, in some embodiments, include a role for the connection and/or a URL for the connection. In embodiments, ID codes platform <b>2005</b> is configured to display one or more verified connections of company/organization <b>2020</b>. In embodiments, one or more verified connections of company/organization <b>220</b> are organized by relationship between connections <b>225</b> and company/organization <b>2020</b>.

ID codes platform <b>2005</b> may comprise a program, service, task, script, library, application or any type and form of executable instructions or code executable on one or more processors. ID Codes platform <b>2005</b> may be combined or separated into one or more modules, applications, programs, services, tasks, scripts, libraries, applications, or executable code. In some embodiments, ID codes platform <b>2005</b> may be integrated with or coupled to memory <b>1022</b>. In some embodiments, the memory may include any type and form of storage, such as a database or file system. Memory <b>1022</b> may store data such as parameters and scripts corresponding to the choices ID codes platform <b>2005</b>.

In a general overview, <figref idref="DRAWINGS">FIG. 12</figref> depicts a method in an identity verification platform used to generate user ID codes for online verification. In some embodiments, the system receives a request for registration of an entity from a company representative, who is a user of the system (step <b>1210</b>). In embodiments, the system verifies the identity of the user and the relationship between the user and the identity (step <b>1220</b>). In examples, the system may verify that the entity is legitimate (step <b>1230</b>). The system may receive from the use an invitation for a relationship between the entity and an individual (step <b>1240</b>). In embodiments, the system may transmit to the individual a request for approval of the relationship between the entity and the individual (step <b>1250</b>). The system may receive approval of the relationship from the individual (step <b>1260</b>). In some embodiments, the system transmits confirmation of the relationship to the user (step <b>1270</b>). The system may create a custom badge representing the relationship between the individual and the entity in step <b>1280</b>.

Referring to <figref idref="DRAWINGS">FIG. 12</figref> in more detail, in step <b>1210</b>, a company representative (also known as user <b>1002</b>) sends a request to identity verification platform <b>2000</b> to register the company/organization <b>2020</b> (also known as the entity). In examples, user <b>1002</b> must first sign on to an identity verification system to send the request to register company/organization <b>2020</b>. User <b>1002</b> may be presented with a user interface, such as the user interface shown in <figref idref="DRAWINGS">FIG. 16</figref>, in order to sign in to the identity verification platform <b>2000</b>. In some embodiments, user <b>1002</b> is not registered with the identity verification system, and to proceed to use identity verification platform <b>2000</b>, user <b>1002</b> must interact with the user interface in order to register with the identify verification system. In some embodiments, user <b>1002</b> may be presented with a QR code, for example a QR code similar to that shown in <figref idref="DRAWINGS">FIG. 17</figref>, which user <b>1002</b> can scan with their phone in order to be directed to a website to register with the identity verification system, or in order to be prompted to install an application e.g. on a mobile device, required to register user <b>1002</b> with the identity verification system. In some embodiments, when user <b>1002</b> chooses to register with the identity verification system, user <b>1002</b> will be taken to an interface where user <b>1002</b> can input personal information required for the identity verification system to verify the user. In some embodiments, if user <b>1002</b> is registered with the identity verification system, user <b>1002</b> is prompted by identity verification platform <b>2000</b> to complete their profile information to be storage and used by identity verification platform <b>2000</b>. In some examples, user <b>1002</b> may be presented with a graphical user interface requesting the profile information requested by identity verification platform <b>2000</b>. In some embodiments, <figref idref="DRAWINGS">FIG. 18</figref> is an illustrative example of a graphical user interface that may be presented to user <b>1002</b> to create a personal profile in identity verification platform <b>2000</b>.

In step <b>1220</b>, identity verification platform <b>2000</b> verifies the identity of user <b>1002</b> that sent the request to identity verification platform <b>2000</b> to register the company/organization <b>2020</b>. In some embodiments, identity verification platform <b>2000</b> may request that user <b>1002</b> sign into the identity verification system, and if user <b>1002</b> has a valid log in to the identity verification system, identity verification platform <b>2000</b> ascertains that user <b>1002</b> has been previously verified by the identity verification system. In step <b>1220</b>, once identity verification platform <b>2000</b> has verified user <b>1002</b>, identity verification platform <b>2000</b> additionally verifies the relationship between user <b>1002</b> and company/organization <b>2020</b>. In some embodiments, identity verification platform <b>2000</b> searches one or more databases, social media networks, registers, lists, or other sources of information to verify the relationship between user <b>1002</b> and company/organization <b>2020</b>. For example, identity verification platform <b>2000</b> may search on LinkedIn (LinkedIn Corporation, Palo Alta, Calif.) to see if user <b>1002</b> list company/organization <b>2020</b> as their current employer. In some examples, identity verification platform <b>2020</b> may search the company/organization <b>2020</b>'s website to determine if user <b>1002</b> is listed as an employee or team member of the company on that website.

In step <b>1230</b>, identity verification platform <b>2000</b> verifies that company/organization <b>2020</b> is a legitimate company. In some embodiments, information which may be used to verify the legitimacy of company/organization <b>2020</b> may be available from trusted sources such as Bloomberg, Inc. (Bloomberg, New York City, N.Y.), GlobeData (The Globe Program, Boulder, Colo.), ICD Research (ICD Research Limited, London, UK), MarketLine (MarketLine, Manchester, UK) PrivCo (PrivCo, New York City, N.Y.), SGA (SGA, Boston, Mass.), ExecutiveTracker (Executive Trackers LLC, Los Gatos, Calif.), Timetric (Trimeric, London, UK), and World Market Intelligence (World Market Intelligence Limited, London, UK). In some embodiments, identity verification platform <b>2000</b> may verify that a company or organization is legitimate via a certificate exchange with a trusted authority that identifies the company or organization as legitimate. In some embodiments, identity verification platform <b>2000</b> may verify that a company or organization is legitimate based on the presence of a record in a distributed or centralized ledger corresponding to the company or organization, and, in some implementations, that the record is associated with a non-zero currency value. In some embodiments, once identity verification platform <b>2000</b> verifies that company/organization <b>2020</b> is legitimate, identity verification platform <b>2000</b> creates a record of the company in a database or storage.

In step <b>1240</b>, user <b>1002</b> creates a request to invite connection <b>2025</b> to have a given relationship to or with company/organization <b>2020</b>. In embodiments, user <b>1002</b> may create a request to invite existing or new employees to be team members of company/organization <b>2020</b>. In some examples, user <b>1002</b> may create a request to invite connections <b>2025</b> to be advisors of company/organization <b>2020</b>. In some embodiments, user <b>1002</b> may be presented with a graphical user interface, for example as shown in <figref idref="DRAWINGS">FIG. 29</figref>, that may be used to invite a new connection. User <b>1002</b> may upload a photo of the new connection, for example from a file from a device of user <b>1002</b> or from a cloud storage In examples, user <b>1002</b> may invite connection <b>2025</b> using the email address of connection <b>2025</b>. User <b>1002</b> may, as part of the invitation to connection <b>2025</b>, specify the relationship of connection <b>2025</b> with company/organization <b>2020</b>. In some examples, user <b>1002</b> may interact with a selection on a graphical user interface in order to cause identity verification platform <b>2000</b> to receive a request to invite connection <b>2025</b>. For example, user <b>1002</b> may click with an “invite” button on a graphical user interface on user <b>1002</b>'s device.

In step <b>1250</b>, responsive to receiving a request from user <b>1002</b> to invite connection <b>2025</b> to company/organization <b>2020</b>, identity verification platform <b>2020</b> may transmit to connection <b>2025</b>, a request for approval of the relationship between the company/organization <b>2020</b> and connection <b>2025</b>. In some embodiments, identity verification platform <b>2000</b> sends a message to connection <b>2025</b> using the email address for connection <b>2025</b> that was provided by user <b>1002</b>. In some examples, identity verification platform <b>2000</b> raises an alert or causes a notification to be sent from an application on connection <b>2025</b><i>s </i>device, for example on an identity verification system application on the device of connection <b>2025</b>. In embodiments, connection <b>2025</b> has already registered with the identity verification system and has an authenticated profile with the identity verification system. Connection <b>2025</b> may then be prompted by a message, such as an email message, a text message, or an in-app message, to log into the identity verification system to view the invitation. In examples, connection <b>2025</b> has not registered with the identity verification system. Connection <b>2025</b> may then be prompted with a message, such as an email message or a text message, to download the application for the identity verification system of the device of connection <b>2025</b> or may be presented with a link that connection <b>2025</b> can click on to traverse to a website of the identity verification system in order to register with the identity verification system and have their identity verified. In some embodiments, connection <b>2025</b> may only see the invitation from user <b>1002</b> once connection <b>2025</b> has been fully authenticated by the identity verification system.

In step <b>1260</b>, connection <b>2025</b> may review the invitation from user <b>1002</b>. In examples, connection <b>2025</b> may sign in to the identity verification system and see the invitation as a message or alert in identity verification system. In examples, when connection <b>2025</b> opens or selects the message or alert in the identity verification system, connection <b>2025</b> traverses to a website for identity verification platform <b>2000</b>. In some examples, when connection <b>20205</b> opens or selects the message or alert in the identity verification system, an application for identity verification platform <b>2000</b> opens on connection <b>2025</b>'s device, and connection <b>2025</b> may view the invitation from user <b>1002</b> in the application. Connection <b>2025</b> may be able to select or open the invitation to view parameters and/or details of the invitation. In some examples, connection <b>2025</b> may be presented with the details of the relationship to the company/organization (for example, team member, advisor, employee, etc.), and the name of the user <b>1002</b> that invited connection <b>2025</b> to have a relationship with company/organization <b>2020</b>. In embodiments, connection <b>2025</b> may approve or reject the relationship invitation from user <b>1002</b> with company/organization <b>2020</b>. In embodiments, when connection <b>2025</b> approves or rejects the relationship invitation from user <b>1002</b>, a message representing the approval or rejection is sent to identity verification platform <b>2000</b>.

In step <b>1270</b>, responsive to receiving the approval or rejection of the relationship with company/organization <b>2020</b> from connection <b>2025</b>, identity verification platform <b>2000</b> transmits confirmation of the relationship of connection <b>2025</b> with company/organization <b>2020</b> to user <b>1002</b>. In some embodiments, the confirmation is sent to user <b>1002</b> via the identity verification platform <b>2000</b> console and/or dashboard for the company/organization. In examples, identity verification platform <b>2000</b> may send a message to user <b>1002</b>, for examples, and email message, a text message, or a message that triggers a notification on a device of user <b>1002</b>, requesting that the user log on to identity verification platform <b>2000</b>. In some embodiments, message to user <b>1002</b> may have a link that user <b>1002</b> may click on to be directed to the web dashboard for company/organization <b>2020</b> on identity verification platform <b>2000</b>.

In step <b>1280</b>, identity verification platform <b>2000</b> creates a custom badge representing the approved relationship between connection <b>2025</b> and company/organization <b>2020</b>. In some embodiments, the badge may be rendered on a company/organization <b>2020</b> webpage, dashboard, or console on identity verification platform <b>2000</b>. In some embodiments, <figref idref="DRAWINGS">FIG. 27</figref> shows an illustration of badges for connections for company/organization <b>2020</b> rendered on identity verification platform <b>2020</b>. In some examples, user <b>1002</b> of company/organization <b>2020</b> may export a badge of connection <b>2025</b>, for example by clicking on the badge for connection <b>2025</b>. In embodiments, the rendered badge on identity verification platform <b>2020</b> shows a picture for connection <b>2025</b>, the name of connection <b>2025</b>, the relationship between connection <b>2025</b> and company/organization <b>2020</b>, the email address for connection <b>2025</b>, and optionally any other profile information for connection <b>2025</b>, for example a link to connection <b>2025</b>'s LinkedIn profile, or twitter feed, or any other social network feed for connection <b>2025</b>. In embodiments, connections <b>2025</b> of company/organization <b>2020</b> may be organized on different pages according to the type of connection. For example, connections that are advisors to company/organization <b>2020</b> may be shown on one page, and connections that are team members of company/organization <b>2020</b> may be shown on a second page, and all connections of company/organization <b>2020</b> may be shown on a third page.

In a general overview, <figref idref="DRAWINGS">FIG. 13</figref> depicts a method for creating and exporting a verified individual's badge on a company/organization <b>2020</b>'s website. User <b>1002</b> may send an invitation for a relationship between company/organization <b>2020</b> and connection <b>2025</b> (step <b>1310</b>). User <b>1002</b> may receive an approval notification of the relationship between company/organization <b>2020</b> and connection <b>2025</b> (step <b>1320</b>). In step <b>1330</b>, user <b>1002</b> may export code for connection <b>2025</b> from the badge for connection <b>2025</b>. User <b>1002</b> may import the code exported from the badge for connection <b>2025</b> to a website of company/organization <b>2020</b> (step <b>1340</b>). In step <b>1350</b>, connection <b>2025</b>'s badge representing the relationship between connection <b>2025</b> and company/organization <b>2020</b> may render on a website of company/organization <b>2020</b>.

Referring to <figref idref="DRAWINGS">FIG. 13</figref> in more detail, in step <b>1330</b>, user <b>1002</b> may export code for connection <b>2025</b> from the badge for connection <b>2025</b>, for example by clicking on the badge of connection <b>2025</b> on a dashboard or company console of identity verification platform <b>2000</b>. In some examples, clicking on the badge of connection <b>2025</b> causes the download of code to a device of user <b>1002</b>. In some examples, the downloaded code for the badge may include an html object tag, and Iframe, a flash object, or java code. User <b>1002</b> may import the exported code from the badge for connection <b>2025</b> to a website of company/organization <b>2020</b> (step <b>1340</b>). In some examples, user <b>1002</b> may associate the exported badge code with a picture, a name, a biography, a description, and/or any other identification of connection <b>2025</b> on the website of company/organization. In step <b>1350</b>, connection <b>2025</b>'s badge representing the relationship between connection <b>2025</b> and company/organization <b>2020</b> may render on a website of company/organization <b>2020</b>. In some embodiments, connection <b>2025</b>'s badge will only render if the domain of the website that the code has been imported to matches the one or more domains that user <b>1002</b> registered as being associated with company/organization <b>2020</b>, and which identity verification platform <b>2000</b> verified as being associated with company/organization <b>2020</b>.

<figref idref="DRAWINGS">FIG. 14</figref> depicts a method for registering a company with an identity verification platform. Identity management platform <b>2000</b> receives a request from user <b>1002</b> to register company/organization <b>2020</b> and ascertains that user <b>1002</b> does not have an account with the identity verification system. Identity verification platform <b>2000</b> prompts user <b>1002</b> to register with the identity verification system (step <b>1410</b>). In some examples, identity verification platform <b>2000</b> presents a QR code to user <b>1002</b> (step <b>1420</b>), for example a QR code as illustrated in <figref idref="DRAWINGS">FIG. 17</figref>. In step <b>1430</b>, user <b>1002</b> submits profile information to identity verification platform <b>2000</b>, for example using a graphical user interface such as is illustrated in <figref idref="DRAWINGS">FIG. 18</figref>. In some embodiments, user <b>1002</b> submits their profile information to the identity verification system instead of the identity verification platform <b>2000</b>. In some examples, user <b>1002</b> uploads a photo to identity verification platform <b>2000</b>, for example using a graphical user interface such as is illustrated in <figref idref="DRAWINGS">FIG. 19</figref>. (step <b>1440</b>). In some embodiments, user <b>1002</b> submits their photo to the identity verification system instead of the identity verification platform <b>2000</b>. The identity verification platform <b>2000</b> receives a request from user <b>1002</b> to register company/organization <b>2020</b> (step <b>1450</b>), for example using a graphical user interface such as is illustrated in <figref idref="DRAWINGS">FIG. 20</figref> and in <figref idref="DRAWINGS">FIG. 21</figref> and receives company details from user <b>1002</b> (step <b>1460</b>). In some embodiments, user <b>1002</b> enters one or more of the name of company/organization <b>2020</b>, an email address of company/organization <b>2020</b>, a subdomain for a company profile URL that is based on the identity verification platform URL, and a phone number for company/organization <b>2020</b>. Once the identity verification system has authenticated the user (step <b>1470</b>), then the identity verification platform <b>2000</b> proceeds to verify and register the company/organization <b>2020</b> (step <b>1480</b>).

In general overview, <figref idref="DRAWINGS">FIG. 15</figref> illustrates an online verification system. In step <b>1505</b>, a company representative (for example, user <b>1002</b>) makes a request to register the company (for example, company/organization <b>2020</b>) on identity verification platform <b>2000</b> dashboard. The request may be transmitted by a first device to a second device (e.g. from a mobile device, laptop computer, desktop computer, or other such device of the company representative, to a server or other device hosting identity verification platform <b>2000</b>). In step <b>1510</b>, identity verification platform <b>2000</b> verifies the identity of the company representative and verifies the relationship of the company representative to the company. The identity verification platform <b>2000</b> verifies that the company is a legitimate business in step <b>1520</b>. As discussed above, verification of the identity of the representative, the relationship, and the legitimacy of the business may be performed via a certificate exchange with a trusted authority, identifying a record in a distributed or centralized ledger corresponding to the representative and/or business, via a web search for a social media profile or other profile associated with the representative or business, or by other such means. If the company is not a legitimate business the approval is blocked in step <b>1515</b>. In step <b>1525</b>, the company is approved, the company representative is approved, and the relationship between the company representative and the company is approved, and the company representative is authorized to do ID codes for the company. In step <b>1530</b>, the company representative invites individuals with specified relationships to the company to be connections of the company. Upon receiving the invitation, the individual signs in to the identity verification platform and views the company's invitation in step <b>1540</b> and approves the relationship in step <b>1545</b>. In step <b>1550</b>, the company receives the approval notification. In some embodiments, invites with the claimed relationship between the company and individual are sent via email to specific individuals. In other embodiments, invites may be provided via push notifications to mobile devices, via a web page visited by the individuals, or any other such method. In examples, claimed relationships include but are not limited to advisor, investor, employee etc. In some embodiments, the individual creates their own biography in identity verification platform <b>2000</b> with such as their verified legal name.

In step <b>1555</b>, identity verification platform <b>2000</b> generates customized code in the form of a badge for the individual. The company exports code from the individual's badge on the company dashboard of identity verification platform <b>2000</b> in step <b>1560</b>. In step <b>1565</b>, the company imports the code for the individual's badge on its website to enable verification that the claimed relationship to the individual is genuine. When a company attempts to render a badge, the identity verification platform verifies that the domain matches what was approved in step <b>1570</b>. The badge can only be rendered on the web site within the domain or domains belonging to the company. In some embodiments, the identity verification platform is responsible for maintaining a list of domains that each badge is authorized to be rendered on. In step <b>1575</b>, if the domain matches what was approved, the ID Codes verification badge for the individual is rendered on the company website. In step <b>1580</b>, the third-party end user can click on the verification badge on the company website and in step <b>1585</b> the end user is traversed to an ID codes page on a different domain which verifies the relationship between the individual and the company. In examples, the ID codes page on the different domain is only valid for a short period of times, for example for 5 minutes, 10 minutes, 15 minutes, 30 minutes, 60 minutes, 2 hours, 12 hours, 24 hours, or any other time limited period, after which the page expires and cannot be viewed without the third-party end user again clicking on the ID codes verification badge for the individual on the company website. In some embodiments, the third-party user can see the individual's verified bio showing the company relationship. In step <b>1590</b>, if the domain doesn't match what was approved, the badge fails to render.

Either the individual in step <b>1595</b> or the company in step <b>1596</b> may revoke the relationship at any time and as a consequence the badge will no longer render as shown in step <b>1590</b>. All participants are notified if the relationship is revoked.

In some examples, JavaScript or other executable code that may be rendered by a web browser can be used for badge code. In some examples, an identity verification platform can automate various mechanisms to verify if a company is legitimate.

A system according to the current disclosure is particularly useful for an ICO or initial currency offering. In an ICO, the people that are behind the company offering the ICO are very important to the credibility of the offer. When a prospectus is produced for such an IPO, typically the board members or other high-profile members of the group putting the ICO together are displayed on the company's website that is doing the ICO. Just the association of important people with the ICO may encourage people to buy in, raising a significant amount of money for the company.

In some instances, companies may falsely represent that important people are associated with the ICO when they are not and have not agreed to be associated with the ICO. The company can put the people's pictures up on the website, and the general public has no way to know if this person's involvement is true or not.

The present disclosure can be used to verify that the person is associated with the company, or with the ICO, or more generally with any offering that is done online.

In some embodiments a company may register with an identity verification system. A validator will verify information about the company and attest to information about the company. The company may also invite people into the company, in whatever capacity the person would be related to the company. For example, the company may invite a person as a board member, or as an advisor, or as an auditor, or as a CEO. The validator will verify all the of the people that are invited to the company, both individually in their own right, and also in their association with the company. The validator will then be able to attest that the person is who they say they are, and also that they perform the function in the company that they were invited to.

Once the validator has attested to this information, the company is issued an ID code or badge for that individual. The company may display the ID code of badge on their website. In some embodiments, the ID code or badge may only be displayed on their web site, or on a website associated with the company. In some embodiments, the validator has additionally validated the domains or URLs that are associated with the company, and the badge will only work on those URLs.

In some examples, the company may put a picture of the individual on the website and the picture may appear with a check mark beside it, or a badge icon, or any other representation, visual or audio, that indicates to a viewer of the website that that person has been authenticated by a validator. In some embodiments, a viewer of the web site may click on the picture or click on the indication of validation, and the viewer may be taken to a webpage where they can read all the essential information about the individual. In some examples, the viewer can click on the indication of validation and be taken to the validator's website to view the information on the individual and to view the individual's association with the company that the validator has attested to. In some embodiments, the website viewer may be directed to another website where the ID codes are accessible, for example a website such as IDcodes.com.

<figref idref="DRAWINGS">FIG. 22</figref> illustrates an example of a graphical user interface via which user <b>1002</b> may upload a logo of company/organization <b>2020</b>, to become part of the profile for company/organization <b>2020</b>.

<figref idref="DRAWINGS">FIG. 23</figref> illustrates an example of a graphical user interface that user <b>1002</b> may see after information for company/organization <b>2020</b> has been entered into identity verification platform <b>2000</b>, indicating that user <b>1002</b> may start inviting connections while identity verification platform <b>2000</b> verifies the company/organization information.

<figref idref="DRAWINGS">FIG. 24</figref> is an illustration of an example of a graphical user interface displaying a dashboard for a user of identity verification platform <b>2000</b>. In some embodiments, a user's dashboard displays the user's name, role of job title, and user's handle. The user may view their connections via the user dashboard. In some examples, the user may get, send, or share a link to their information verification platform <b>2000</b> profile.

<figref idref="DRAWINGS">FIG. 25</figref> is an illustration of an example of a graphical user interface displaying a dashboard for a user of identity verification platform <b>2000</b>, showing settings of the user.

In some embodiments, a user may change their photo or remove their photo. In some embodiments, the user may export their data. In some examples, the user may delete their account. If a user deletes their account, all connections between that user and any other user will be automatically removed, and any badges inserted on websites of company/organizations <b>2020</b> will no longer render.

<figref idref="DRAWINGS">FIG. 26</figref> is an illustration of an example of a graphical user interface displaying a dashboard for a company/organization <b>2020</b> of identity verification platform <b>2000</b>, showing an invitation page where the user <b>1002</b> for company/organization <b>2020</b> may invite new connections. User <b>1002</b> that had their relationship with company/organization <b>2020</b> verified by identity verification platform <b>200</b> may be highlighted on the dashboard, for example identifying user <b>1002</b> as a company contact and giving their name, email address, phone number, links to their social media accounts, and links to their badge with the identity verification platform <b>2000</b>. In some embodiments, the logo of company/organization <b>2020</b> is displayed on the page, along with the verified domain of company/organization, and the ID codes badge for company/organization.

<figref idref="DRAWINGS">FIG. 27</figref> is an illustration of an example of a graphical user interface displaying a dashboard for a company/organization <b>2020</b> of identity verification platform <b>2000</b>, showing connections for company/organization <b>2020</b>. In some embodiments, company/organization <b>2020</b> may display names and/or images of employees or people that have an association with company/organization <b>2020</b> on one or more domains associated with company/organization <b>2020</b>. In some examples, company/organization <b>2020</b> displays names and/or images of individuals in leadership positions with company/organization <b>2020</b>. In some examples, company/organization <b>2020</b> displays names and/or images of individuals in advisory roles with company/organization <b>2020</b>.

<figref idref="DRAWINGS">FIG. 28</figref> is an illustration of an example of a graphical user interface displaying a dashboard for a company/organization <b>2020</b> of identity verification platform <b>2000</b>, showing settings for company/organization <b>2020</b>. In some embodiments, a company representative user <b>1002</b> may change the company photo or remove the company photo. In some embodiments, if the company is still under review by the identity verification platform <b>2000</b>, and indication of this will be displayed with the information for the company/organization <b>2020</b>.

<figref idref="DRAWINGS">FIG. 30</figref> illustrates an indication displayed to a user <b>1002</b> on a dashboard for company/organization <b>2020</b> indicating that invitations are queued until company/organization <b>2020</b> is verified. <figref idref="DRAWINGS">FIG. 31</figref> illustrates an indication displayed to a user on an entity dashboard when an invitation is sent, highlighting the email address to which the invitation was sent.

<figref idref="DRAWINGS">FIG. 32</figref> illustrates a public profile for connection <b>2025</b> in an identity verification platform <b>2000</b>, indicating the role of the connection <b>2025</b> and the verified associations of the connection <b>2025</b>. <figref idref="DRAWINGS">FIG. 33</figref> illustrates a public profile for company/organization <b>2020</b> in an identity verification platform <b>2000</b> and shows the connection <b>2025</b> of the company/organization <b>2020</b> and their relationships with company/organization <b>2020</b>.

<figref idref="DRAWINGS">FIG. 34</figref> illustrates an administrative portal for an identity verification platform <b>2000</b>, which allows and administrator of the identity management platform <b>2000</b> to view all users of the platform.

Accordingly, in one aspect, the present disclosure is directed to a method of establishing a chain of relationships. The method includes receiving, by an identity verification platform from a device of a first user, a first request for registration comprising an identification of the first user, identification of an entity, and a relationship between the first user and the entity. The method also includes verifying, by the identity verification platform responsive to receipt of the first request, the identity of the first user and the relationship between the first user and the entity. The method also includes verifying, by the identity verification platform, that the entity is legitimate. The method also includes receiving, by the identity verification platform from the first user, a first invitation for a relationship between a first individual and the entity. The method also includes transmitting to a device of the first individual, by the identity verification platform responsive to receiving the invitation for the relationship from the device of the first user, a second request for approval of the relationship between the first individual and the entity. The method also includes receiving, by the identity verification platform from the device of the first individual, approval of the relationship between the first individual and the entity. The method also includes transmitting, by the identity verification platform to the device of the first user, confirmation of the relationship between the first individual and the entity. The method also includes creating, by the identity verification platform, a custom badge for display on the entity's website, the custom badge representing the relationship between the first individual and the entity and valid for one or more domains associated with the verified entity. The method also includes receiving, by the identity verification platform, an identification of a selection by an end user of the custom badge. The method also includes, responsive to receiving the identification of the selection, rendering, by the identity verification platform, on a domain controlled by the identity verification platform, a verification that the relationship between the first individual and the entity is valid.

In some implementations, the method includes verifying the identity of the first user and the relationship between the first user and the entity by verifying the existence of a record in a centralized or distributed ledger at an address corresponding to the entity. In some implementations, the method includes generating a transaction for recordation in a centralized or distributed ledger at an address based on the entity and the first individual, the presence of the first transaction in the centralized or distributed ledger indicating that the relationship between the first individual and the entity is legitimate. In a further implementation, the method includes generating the transaction by adding a non-zero value to a record in the centralized or distributed ledger at the address based on the entity and the first individual.

In some implementations, the method includes verifying the relationship between the first user and the entity by receiving a confirmation of the relationship between the first user and the entity via a communication channel separate from a communication channel via which the first request was received. In some implementations, the method includes rendering the verification that the relationship between the first individual and the entity is valid responsive to determining that validity of the relationship has not been revoked. In a further implementation, the method includes determining that validity of the relationship has not been revoked responsive to identifying a record in a centralized or distributed ledger at an address based on the entity and the first individual having a non-zero value.

In another aspect, the present disclosure is directed to a system for establishing a chain of relationships. The system includes a device, in communication with a device of a first user and a device of a first individual, comprising a network interface and a processor executing an identity verification platform. The network interface is configured to receive, from the device of the first user, a first request for registration comprising an identification of the first user, identification of an entity, and a relationship between the first user and the entity. The identity verification platform is configured to: verify, responsive to receipt of the first request, the identity of the first user and the relationship between the first user and the entity and verify that the entity is legitimate. The network interface is further configured to: receive, from the device of the first user, a first invitation for a relationship between the first individual and the entity; transmit to the device of the first individual, responsive to receiving the invitation for the relationship from the device of the first user, a second request for approval of the relationship between the first individual and the entity; receive, from the device of the first individual, approval of the relationship between the first individual and the entity; and transmit, to the device of the first user, confirmation of the relationship between the first individual and the entity. The identity verification platform is further configured to create a custom badge for display on the entity's website, the custom badge representing the relationship between the first individual and the entity and valid for one or more domains associated with the verified entity; and responsive to receiving an identification of a selection by an end user of the custom badge, the event, render, on a domain controlled by the identity verification platform, a verification that the relationship between the first individual and the entity is valid.

In some implementations, the identity verification platform is further configured to verify the identity of the first user and the relationship between the first user and the entity responsive to the existence of a record in a centralized or distributed ledger at an address corresponding to the entity. In some implementations, the identity verification platform is further configured to generate a transaction for recordation in a centralized or distributed ledger at an address based on the entity and the first individual, the presence of the first transaction in the centralized or distributed ledger indicating that the relationship between the first individual and the entity is legitimate. In a further implementation, the identity verification platform is further configured to add a non-zero value to a record in the centralized or distributed ledger at the address based on the entity and the first individual. In some implementations, the identity verification platform is further configured to receive a confirmation of the relationship between the first user and the entity via a communication channel separate from a communication channel via which the first request was received. In some implementations, the identity verification platform is further configured to render the verification that the relationship between the first individual and the entity is valid responsive to determining that validity of the relationship has not been revoked. In a further implementation, the identity verification platform is further configured to determine that validity of the relationship has not been revoked responsive to identifying a record in a centralized or distributed ledger at an address based on the entity and the first individual having a non-zero value.

In another aspect, the present application is directed to a method for verification of a chain of trust via a distributed or centralized ledger. The method includes receiving a request, by a validation system from a first device, for a validation badge, the request identifying a user and an entity. The method also includes retrieving, by the validation system, a record in a centralized or distributed ledger at an address corresponding to the user and entity. The method also includes determining, by the validation system, that a relationship between the user and the entity is existent based on the retrieved record in the centralized or distributed ledger. The method also includes transmitting, by the validation system to the first device, the requested validation badge, responsive to the determination that the relationship is existent, an application of the first device rendering the validation badge for display.

In some implementations, the method includes retrieving a parent record at an address corresponding to the entity; identifying, in the parent record, a second address corresponding to the user and the entity; and retrieving the record in the centralized or distributed ledger at the second address.

In some implementations, the method includes determining that the relationship between the user and the entity is existent responsive to identifying the presence of a non-zero value stored with the retrieved record in the centralized or distributed ledger.

In some implementations, the validation badge comprises executable code that, upon interaction with the validation badge, causes the application of the first device to transmit a second request for information about the relationship between the user and the entity from the validation system. In a further implementation, the method includes receiving the second request, by the validation system from the first device, the second request comprising an identification of a domain; determining, by the validation system, that the domain is associated with the entity; and transmitting a response to the second request comprising the information about the relationship between the user and the entity, by the validation system to the first device, responsive to the determination that the domain is associated with the entity. In a still further implementation, the method includes receiving the second request, by the validation system from the first device, the second request comprising an identification of a domain; determining, by the validation system, that the domain is not associated with the entity; and transmitting a response to the second request comprising an indication that the validation badge is invalid, by the validation system to the first device, responsive to the determination that the domain is not associated with the entity.

The systems described above may provide multiple ones of any or each of those components and these components may be provided on either a standalone machine or, in some embodiments, on multiple machines in a distributed system. The systems and methods described above may be implemented as a method, apparatus or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. In addition, the systems and methods described above may be provided as one or more computer-readable programs embodied on or in one or more articles of manufacture. The term “article of manufacture” as used herein is intended to encompass code or logic accessible from and embedded in one or more computer-readable devices, firmware, programmable logic, memory devices (e.g., EEPROMs, ROMs, PROMS, RAMS, SRAMs, etc.), hardware (e.g., integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.), electronic devices, a computer readable non-volatile storage unit (e.g., CD-ROM, floppy disk, hard disk drive, etc.). The article of manufacture may be accessible from a file server providing access to the computer-readable programs via a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. The article of manufacture may be a flash memory card or a magnetic tape. The article of manufacture includes hardware logic as well as software or programmable code embedded in a computer readable medium that is executed by a processor. In general, the computer-readable programs may be implemented in any programming language, such as LISP, PERL, C, C++, C#, PROLOG, or in any byte code language such as JAVA. The software programs may be stored on or in one or more articles of manufacture as object code.

While various embodiments of the methods and systems have been described, these embodiments are illustrative and in no way limit the scope of the described methods or systems. Those having skill in the relevant art can effect changes to form and details of the described methods and systems without departing from the broadest scope of the described methods and systems. Thus, the scope of the methods and systems described herein should not be limited by any of the illustrative embodiments and should be defined in accordance with the accompanying claims and their equivalents.