Patent ID: 12199978

DETAILED DESCRIPTION OF THE EMBODIMENTS

FIG.1is a block diagram illustrating an example system100for establishing and confirming a trusted engagement between two or more individuals, in accordance with various aspects of the present disclosure. In the example ofFIG.1, the system100includes an identity server104, a first user device130, a second user device140, and a network160.

The identity server104may be owned by, or operated by or on behalf of, an administrator. The identity server104includes an electronic processor106, a communication interface108, and a memory110. The electronic processor106is communicatively coupled to the communication interface108and the memory110. The electronic processor106is a microprocessor or another suitable processing device. The communication interface108may be implemented as one or both of a wired network interface and a wireless network interface. The memory110is one or more of volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, FLASH, magnetic media, optical media, et cetera). In some examples, the memory110is also a non-transitory computer-readable medium. Although shown within the identity server104, memory110may be, at least in part, implemented as network storage that is external to the identity server104and accessed via the communication interface108. For example, all or part of memory110may be housed on the “cloud.”

The identity engine112may be stored within a transitory or non-transitory portion of the memory110. The identity engine112includes machine readable instructions that are executed by the electronic processor106to perform the functionality of the identity server104as described below with respect toFIGS.3-5and7-10B.

The memory110may include a database114for storing information about individuals. The database114may be an RDF database, i.e., employ the Resource Description Framework. Alternatively, the database114may be another suitable database with features similar to the features of the Resource Description Framework, and various non-SQL databases, knowledge graphs, etc. The database114may include a plurality of records (also referred to herein as a “data pod” or “data store”). Each record may be associated with and contain personal information about one individual. For example, in the illustrated embodiment, record116may be associated with the individual associated with the first user device130, and other N records may be respectively associated with one of N other individuals (not expressly shown inFIG.1).

The first user device130may be web-compatible mobile computer, such as a laptop, a tablet, a smart phone, or other suitable computing device. Alternately, or in addition, the first user device130may be a desktop computer. The first user device130includes an electronic processor in communication with memory. In an embodiment, the electronic processor of the first user device130is also in communication with a biometric scanner via a communication interface. In another embodiment, the biometric scanner may be part of the first user device130. The electronic processor is a microprocessor or another suitable processing device, the memory is one or more of volatile memory and non-volatile memory, and the biometric scanner is one or more biometric scanning devices (e.g., a device that scans fingerprints, facial features, irises, handwriting, etc.) now known or subsequently developed. The communication interface may be a wireless or wired network interface.

An application, which contains software instructions implemented by the electronic processor of the first user device130to perform the functions of the first user device130as described herein, is stored within a transitory or a non-transitory portion of the memory. The application may have a graphical user interface that facilitates interaction between a first individual and the first user device130.

The first user device130may communicate with the identity server104over the network160. The network160is preferably (but not necessarily) a wireless network, such as a wireless personal area network, local area network, or other suitable network. In some examples, the second user device140may directly communicate with the identity server104. In other examples, the second user device140may indirectly communicate over network160.

In an embodiment, the memory of the first user device130may include a database and software. The database of the first user device130may include information about an individual associated with the second user device140and other individuals, as set forth herein. The software of the first user device130may facilitate interaction between the first user device130and individuals associated with other devices (e.g., the individual associated with the second user device140) and allow for the first user device130to perform the operations as described in greater detail below.

The second user device140may be web-compatible mobile computer, such as a laptop, a tablet, a smart phone, or other suitable computing device. Alternately, or in addition, the second user device140may be a desktop computer. The second user device140includes an electronic processor in communication with memory. In an embodiment, the electronic processor of the second user device140is also in communication with a biometric scanner via a communication interface. In another embodiment, the biometric scanner may be part of the second user device140. The electronic processor is a microprocessor or another suitable processing device, the memory is one or more of volatile memory and non-volatile memory, and the biometric scanner is one or more biometric scanning devices (e.g., a device that scans fingerprints, facial features, irises, handwriting, etc.) now known or subsequently developed. The communication interface may be a wireless or wired network interface.

An application, which contains software instructions implemented by the electronic processor of the second user device140to perform the functions of the second user device140as described herein, is stored within a transitory or a non-transitory portion of the memory. The application may have a graphical user interface that facilitates interaction between a second individual and the second user device140, the second individual being different from the first individual.

The second user device140may communicate with the identity server104over the network160. The network160is preferably (but not necessarily) a wireless network, such as a wireless personal area network, local area network, or other suitable network. In some examples, the second user device140may directly communicate with the identity server104. In other examples, the second user device140may indirectly communicate over network160.

In an embodiment, the memory of the second user device140may include a database and software. The database of the second user device140may include information about an individual associated with the first user device130and other individuals, as set forth herein. The software of the second user device140may facilitate interaction between the second user device140and individuals associated with other devices (e.g., the individual associated with the first user device130) and allow for the second user device140to perform the operations as described in greater detail below.

The identity server104may likewise communicate with partner devices other than the first user device130and the second user device140. The term “individual”, as used herein, encompasses a person (or other entity) that seeks to interact with another individual (e.g., another person, organization, or entity) or individuals (e.g., other persons, organizations, entities, or a combination thereof). The workings of the identity server104, the first user device130, and the second user device140will now be described in additional detail with respect toFIGS.3-5and7-10B.

FIG.2is a diagram illustrating an example of an identity challenge200. InFIG.2, a first user202(User “A”) interacts with a second user204(User “B”) in a digital environment. In the digital environment, several questions arise between the first user202(also referred to as “a first individual”) and the second user204(also referred to as a “second individual”), which is referred to as the identity challenge200. A first question may be “How do I know I have interacted with you before?” A second question may be “Do we have an existing, trusted engagement/relationship, either one to one (1:1) or one to many (1:N)?” A third question may be “How do I know that you are the same person (online or in-person)?” A fourth question may be “Should I “accept” or “reject” your request for interaction?”

The identity challenge200may occur in many different situations. In a first example, the identity challenge200may occur when two or more individuals met in the digital environment only to meet in person. In a second example, the identity challenge200may occur when two or more parties to a financial or legal contract and the two or more parties want to ensure that the true parties sign an agreement. In a third example, the identity challenge200may occur when one or more individuals wants to provide proof of past or existing interactions. In a fourth example, the identity challenge200may occur when an individual or entity wants to minimize a risk of a party to a financial transaction is using stolen identity credentials. Lastly, the identity challenge200is not limited to these four examples and other examples of the identity challenge200may also exist and are solved by the present disclosure.

FIG.3is a flow diagram illustrating an example300of establishing a trusted engagement with a similar identifier type, in accordance with various aspects of the present disclosure. The example300includes three different sections, the first user section302, the server section304, and the second user section306, where the server section304is performed by an identity server, for example, the identity server104ofFIG.1.

To establish the trusted engagement, at operation1, a first user308in the first user section302and a second user310(in parallel or subsequently) challenge each other via an identity server (e.g., the identity server104) in the server section304with their respective decentralized identifiers (“DID”). At operation2, the identity server responds with an identity challenge to the first user308and the second user310. At operation3, the first user308and the second user310respond to the identity challenge with an answer to the identity server.

At operation4, the identity server confirms the respective answers from the first user308and the second user310are successful answers and derives a relationship-specific key from the respective DIDs of the first user308and the second user310. In some examples, the relationship-specific key may be a SHA-512 of the DID of the first user308and the DID of the second user310. In other examples, the relationship-specific key may be a Diffie-Hellman key exchange. In yet other examples, the relationship-specific key may be an app and user key.

At operation5, the identity server sends the relationship-specific key to a first biometric device (e.g., a first user device with a camera and operated by the first user308) and a second biometric device (e.g., a second user device with a camera and operated by the second user310). At operation6, the first biometric device and the second biometric device capture biometrics from the first user308and the second user310, respectively, create respective identity tokens using the relationship-specific key that was sent in operation5, and send their respective identity tokens to the identity server. The respective identity tokens are indicative of a unique 1:1 relationship or a 1:N relationship if three or more parties are involved. Additionally, in some examples, the biometrics captured by the biometric device may be palm biometrics, facial biometrics, fingerprint biometrics, or other suitable biometrics.

At operation7, the identity server exchanges the identity tokens between the first user308and the second user310. For example, when the first biometric device and the second biometric device are the first user device130and the second user device140, respectively, then the identity server sends the identity token of the first user308to the second user device140and the identity token of the second user310to the first user device130.

Additionally, in some examples, the identity server also updates a first data pod associated with the first user308to store both the relationship-specific token “R” and the identity token of the second user310and updates a second data pod associated with the second user310to store both the relationship-specific token “R” and the identity token of the first user308. The first data pod and the second data pod may be located on a local device (e.g., the first user device130and the second user device140) or on a cloud device (e.g., on the identity server104or other suitable third-party cloud device).

As illustrated inFIG.3, the trusted engagement is first established by the exchange of identity tokens at operation7.FIG.4is a flow diagram illustrating an example of confirming a trusted engagement400with a similar identifier type, in accordance with various aspects of the present disclosure. Like the example300, the second example400also includes three different sections, the first user section402, the server section404, and the second user section406, where the server section404is performed by an identity server, for example, the identity server104ofFIG.1.

To confirm the trusted engagement, at operation1, a first user408in the first user section402and a second user410(in parallel or subsequently) challenge each other via an identity server (e.g., the identity server104) in the server section404with their respective decentralized identifiers (“DID”). At operation2, the identity server responds with an identity challenge to the first user408and the second user410. At operation3, the first user408and the second user410respond to the identity challenge with an answer to the identity server that proves ownership of their respective decentralized identifiers.

At operation4, the identity server confirms the respective answers from the first user408and the second user410are successful answers and derives a relationship-specific key from the respective DIDs of the first user408and the second user410. In some examples, the relationship-specific key may be a SHA-512 of the DID of the first user408and the DID of the second user410. In other examples, the relationship-specific key may be a Diffie-Hellman key exchange. In yet other examples, the relationship-specific key may be an app and user key.

At operation5, the identity server sends the relationship-specific key to a first biometric device (e.g., the first user device130with a camera and operated by the first user408) and a second biometric device (e.g., the second user device140with a camera and operated by the second user410). At operation6, the first biometric device and the second biometric device capture biometrics from the first user408and the second user410, respectively, create respective identity tokens using the relationship-specific key that was sent in operation5, and send their respective identity tokens to the identity server as well as any other identity tokens of trusted partners that are stored in a local or cloud data pod. The respective identity tokens are indicative of a unique 1:1 relationship or a 1:N relationship if three or more parties are involved. Additionally, in some examples, the biometrics captured by the biometric device may be palm biometrics, facial biometrics, fingerprint biometrics, or other suitable biometrics.

At operation7, the identity server receives the identity tokens from the first user408and the second user410and performs a probabilistic identity token verification for both the first user408and the second user410using some or all of the tokens received from the first user408and the second user410. A trusted engagement is confirmed when one or more of the identity tokens from the first user408has a 1:1 match with one or more of the identity tokens from the second user410.

FIG.5is a block diagram illustrating a process500that is an extension of the example400ofFIG.4, in accordance with various aspects of the present disclosure. In the example ofFIG.5, the process500is described in a sequential flow, however, some of the process500may also be performed in a parallel manner.

The process500starts when a first user (e.g., the first user408) attempts to verify a relationship with a second user (e.g., the second user410) with an identity server (e.g., the identity server104) (at block502). The process500includes the identity server requesting and receiving a unique identifier (e.g., decentralized identifier or “DID”) from the first user and the second user (at block504).

After receiving the unique identifier from both the first user and the second user, the process500includes the identity server generating a unique relationship-specific key for the first user and the second user as well as a shared relationship identifier (r-ID) (at block506). The process500includes the identity server receiving biometrics from the second user (at block508).

The process500includes the identity server tokenizing a biometric template of the second user with the unique relationship-specific key (at block510). The process500includes creating new identity tokens for the second user from the tokenization of the biometric template of the second user (at block512).

The process500includes the identity server retrieves a previous identity token for the second user from the personal data store of the first user using the r-ID as a reference point (at block514). The process500includes the identity server comparing “new” and “stored” identity tokens for the second user (at block516). The process500includes the identity server performing a probabilistic similarity score for a 1:1 verification from the comparison of the “new” and “stored” identity tokens for the second user (at block518).

The process500includes the identity server determining whether the second user is actually the second user from a previous interaction based on the probabilistic similarity score (at decision block520). When the identity server determines that the second user is not actually the second user from the previous interaction (“NO” at decision block520), the identity server ends the process500(at block522). When the identity server determines that the second user is actually the second user from the previous interaction (“YES” at decision block520), the identity server determines that there is a successful verification that the second user is interacting with the requesting party, i.e., the first user (at block524).

Additionally, after successful verification of the second user, the process500may also include the second user verifying the identity of the first user (at section526). For example, the process500may include the identity server performing the operations described at blocks508-518with respect to the first user instead of the second user (at block528).

The process500also includes the identity server determining whether the first user is actually the first user from a previous interaction based on the probabilistic similarity score (at decision block530). When the identity server determines that the first user is not actually the first user from the previous interaction (“NO” at decision block530), the identity server ends the process500(at block522). When the identity server determines that the first user is actually the first user from the previous interaction (“YES” at decision block530), the identity server determines that there is a successful verification that the first user has previously interacted with the requesting party, i.e., the second user (at block532).

FIG.6is a diagram illustrating a second example of an identity challenge600. Unlike the identity challenge200ofFIG.2, the identity challenge600has different unique identifiers. As illustrated inFIG.6, the first user602has a first decentralized identifier (DID:id) and the second user604has a second decentralized identifier (DID:ion) that is different from the first decentralized identifier.

Additionally, while the same questions may be asked by individuals in either of the identity challenge200or the identity challenge600, the identity challenge600may occur in situations that are different from the situations of the identity challenge200. In a first example, the identity challenge600may occur when an individual receives a friend request from an unknown individual (unknown based on available information). In a second example, the identity challenge600may occur when an individual wants to ban or avoid interactions with an undesired personal contact. In a third example, the identity challenge600may occur when an individual meets with an imposter during a person-to-person transaction. In a fourth example, the identity challenge600may occur when an individual meets a friend that has lost access to his/her digital persona and has created a new digital persona. Lastly, the identity challenge600is not limited to these five examples and other examples of the identity challenge600may also exist and are solved by the present disclosure.

FIG.7is a flow diagram illustrating an example700of establishing a trusted engagement with different identifier types, in accordance with various aspects of the present disclosure. The example700includes three different sections, the first user section702, the server section704, and the second user section706, where the server section704is performed by an identity server, for example, the identity server104ofFIG.1.

To establish the trusted engagement, at operation1, a first user708in the first user section702and a second user710(in parallel or subsequently) challenge each other via an identity server (e.g., the identity server104) in the server section704with their respective decentralized identifiers (e.g., DID:id for the first user708and DID:ion for the second user710). At operation2, the identity server responds with an identity challenge to the first user708and the second user710. At operation3, the first user708and the second user710respond to the identity challenge with an answer to the identity server that proves ownership of their respective decentralized identifiers.

At operation4, the identity server confirms the respective answers from the first user708and the second user710are successful answers and respective independent secret keys for the first user and the second user are created by or provided to a trusted custodian. At operation5, the identity server sends a first key of the respective independent secret keys to a first biometric device (e.g., a first user device with a camera and operated by the first user708) and sends a second key of the respective independent secret keys to a second biometric device (e.g., a second user device with a camera and operated by the second user710).

At operation6, the first biometric device and the second biometric device capture biometrics from the first user708and the second user710, respectively, create respective identity tokens using the respective independent secret keys that were sent in operation5, and send their respective identity tokens to the identity server. The respective identity tokens are indicative of a unique 1:1 relationship or a 1:N relationship if three or more parties are involved. Additionally, in some examples, the biometrics captured by the biometric device may be palm biometrics, facial biometrics, fingerprint biometrics, or other suitable biometrics.

At operation7, the identity server exchanges the identity tokens between the first user708and the second user710. For example, when the first biometric device and the second biometric device are the first user device130and the second user device140, respectively, then the identity server sends the identity token of the first user708to the second user device140and the identity token of the second user710to the first user device130.

In some examples, the identity server updates a first data pod associated with the first user708to store the first independent secret key, personally identifiable information of the first user708, and the identity token of the second user710. Additionally, in these examples, the identity server also updates a second data pod associated with the second user710to store the second independent secret key, personally identifiable information of the second user710, and the identity token of the first user708. The first data pod and the second data pod may be located on a local device (e.g., the first user device130and the second user device140) or on a cloud device (e.g., on the identity server104or other suitable third-party cloud device).

As illustrated inFIG.7, the trusted engagement is first established by the exchange of identity tokens at operation7.FIG.8is a flow diagram illustrating an example800of confirming a trusted engagement with different identifier types, in accordance with various aspects of the present disclosure. Like the example700, the example800also includes three different sections, the first user section802, the server section804, and the second user section806, where the server section804is performed by an identity server, for example, the identity server104ofFIG.1.

To confirm the trusted engagement, at operation1, a first user808in the first user section802challenges the identity of the second user810with an identity server (e.g., the identity server104) in the server section804with their respective decentralized identifiers (DID:id for the first user808and DID:ion for the second user810). At operation2, the identity server responds with an identity challenge to the first user808. At operation3, the first user808responds to the identity challenge with an answer to the identity server that proves ownership of the decentralized identifier of the first user808.

At operation4, the identity server requests a secret key from the personal data pod of the second user810. The second user810may change the secret key based on need, context, digital domain, etc.

At operation5, in some examples, the identity server receives the secret key from the second user810or other trusted custodian, where the other trusted custodian created the secret key. At operation6, the identity server confirms the answer from the first user808is a successful answer and the independent secret key is received from the second user810or the trusted custodian. In other examples, the independent secret key is created by the identity server.

At operation7, the identity server sends the independent secret key to a first biometric device (e.g., a first user device with a camera and operated by the first user808). At operation8, the first biometric device captures biometrics from the first user808, creates an identity token using the independent secret key that was sent in operation5, and sends the identity token to the identity server as well as any other identity tokens of trusted partners that are stored in a local device or cloud data pod. In some examples, the biometrics captured by the biometric device may be palm biometrics, facial biometrics, fingerprint biometrics, or other suitable biometrics.

Additionally, at operation8, the second user810provides any identity tokens of trusted partners that are stored in a local device or cloud data pod. The respective identity tokens are indicative of a unique 1:1 relationship or a 1:N relationship if three or more parties are involved.

At operation9, the identity server receives the identity tokens from the first user808and the second user810and performs a probabilistic identity token verification for both the first user808and the second user810using some or all of the tokens received from the first user808and the second user810. A trusted engagement is confirmed when one or more of the identity tokens from the first user808has a 1:N match with the identity tokens from the second user810.

FIG.9is a block diagram illustrating a process900that is an extension of the example800ofFIG.8, in accordance with various aspects of the present disclosure. In the example ofFIG.9, the process900is described in a sequential flow, however, some of the process900may also be performed in parallel.

The process900starts when a second user (e.g., the second user810) receives a request from an unknown person (e.g., the first user808) via an identity server (e.g., the identity server104) (at block902). The process900includes the identity server verifying the requesting party's claim to a unique identifier presented (at block904).

After verifying the requesting party's claim to the unique identifier presented, the process900includes the identity server requesting consent from the first user for biometric identification (at block906). For example, the individual associated with the first user device130consents to biometric capture by the first user device130. The process900includes the identity server capturing biometrics for the unknown person (e.g., the first user808) (at block908).

The process900includes the identity server tokenizing a biometric template of the second user with a unique key that belongs to the unknown person (e.g., the first user808) (at block910). For example, the identity server104may create a biometric token from the biometric capture of the individual and the unique key with the biometric token creator. The biometric token creator creates a biometric token with a tokenization algorithm.

The process900includes the identity server creating new identity tokens for the second user from the tokenization of the biometric template of the second user (at block912). For example, the identity server104may create an identity token from the biometric token with the identity token creator. The identity token creator creates an identity token with a second tokenization algorithm.

The process900includes the identity server retrieves previous identity tokens for all relevant parties from the personal data store of the first user (at block914). The process900includes the identity server comparing a “new” identity token to multiple “stored” identity tokens for the unknown person (at block916). The process900includes the identity server performing a probabilistic similarity score for a 1:N verification from the comparison of the “new” identity token to the multiple “stored” identity tokens for the unknown person (at block918).

The process900includes the identity server determining whether any of the identity tokens match based on the probabilistic similarity score for the 1:N verification (at decision block920). When the identity server determines that none of the identity tokens match based on the probabilistic similarity score for the 1:N verification (“NO” at decision block920), the identity server determines the request by the unknown person is a new request (at block922). When the identity server determines that one or more of the identity tokens match based on the probabilistic similarity score for the 1:N verification (“YES” at decision block920), the identity server retrieves the personally identifiable information (“PII”) corresponding to the matched identity token from the personal data store of the second user (e.g., the second user810) (at block924).

Lastly, the identity server connects the second user (e.g., the second user810) to the known user (e.g., the first user808) based on the retrieval of the PII associated with the known user (at block926). In some examples, the identity server may also output some or all of the PII associated with the known user to the second user (e.g., the second user810) confirming the trusted engagement.

FIGS.10A and10Bare flow diagrams illustrating an example process1000for biometrically confirming a trusted engagement between two or more individuals, in accordance with various aspects of the present disclosure.FIGS.10A and10Bare described with respect toFIG.1.

In the example ofFIG.10A, the example process1000includes receiving, with a server, a request from a first user to confirm a trusted engagement with a second user (at block1002).

The example process1000includes requesting, with the server, a unique identifier from the first individual (at block1004). For example, the identity server104requests a unique identifier from a first individual associated with the first user device130.

The example process1000includes confirming, with the server, the first individual owns the unique identifier (at block1006). For example, the identity server104confirms the first individual owns the unique identifier based on an answer from the first individual via the first user device130.

The example process1000includes determining, with the server, a unique key associated with the first individual in response to confirming the first individual owns the unique identifier (at block1008). For example, the identity server104determines a unique key associated with the first individual in response to confirming the first individual owns the unique identifier.

The example process1000includes requesting, with the server, consent from the second user to perform a biometric capture on biometrics of the second user (at block1010). For example, the identity server104requests consent from a second user via the second user device140to perform a biometric capture on biometrics of the second user.

The example process1000includes receiving, with the server, the biometrics of the second user (at block1012). For example, the identity server104receives the biometrics of the second user via the second user device140.

The example process1000includes tokenizing, with the server, a biometric template based on the biometrics of the second user with the unique key associated with the first individual (at block1014). For example, the identity server104tokenizes a biometric template based on the biometrics of the second user with the unique key associated with the first individual.

The example process1000includes generating, with the server, one or more new identity tokens from the tokenization of the biometric template of the second user (at block1016). For example, the identity server104generates one or more new identity tokens from the tokenization of the biometric template of the second user.

Referring now toFIG.10B, the example process1000includes retrieving, with the server, one or more stored identity tokens from a personal data store of the first individual (at block1018). For example, the identity server104retrieves one or more stored identity tokens from the record116of the first individual.

The example process1000includes comparing, with the server, the one or more new identity tokens to the one or more stored identity tokens (at block1020). For example, the identity server104compares the one or more new identity tokens to the one or more stored identity tokens.

The example process1000includes performing, with the server, a probabilistic score based on the comparison of the one or more new identity tokens to the one or more stored identity tokens (at block1022). For example, the identity server104performs a probabilistic score based on the comparison of the one or more new identity tokens to the one or more stored identity tokens.

The example process1000includes determining, with the server, whether any of the one or more new identity tokens match the one or more stored identity tokens based on the probabilistic score (at block1024). For example, the identity server104determines whether any of the one or more new identity tokens match the one or more stored identity tokens based on the probabilistic score.

The example process1000also includes confirming, with the server, the trusted engagement with the first individual and the second user in response to determining that the any of the one or more new identity tokens match the one or more stored identity tokens based on the probabilistic score (at block1026). For example, the identity server104confirms the trusted engagement with the first individual and the second user in response to determining that the any of the one or more new identity tokens match the one or more stored identity tokens based on the probabilistic score.

Additionally, in some examples, the example process1000may further include confirming, with the server, no trusted engagement with the first individual and the second user in response to determining that none of the one or more new identity tokens match the one or more stored identity tokens based on the probabilistic score (at block1028).

In some examples, the example process1000may further include requesting a second unique identifier from the second user, the second unique identifier and the unique identifier being the same type; and confirming the second user owns the second unique identifier. In these examples, determining the unique key associated with the first individual in response to confirming the first individual owns the unique identifier further includes determining a relationship-specific unique key based on the unique identifier and the second unique identifier in response to confirming the first individual owns the unique identifier and confirming the second user owns the second unique identifier, and tokenizing the biometric template of the second user with the unique key associated with the first individual further includes tokenizing the biometric template of the second user with the relationship-specific unique key.

In some examples, the example process1000may further include sending the relationship-specific unique key to the personal data store of the first individual, and sending the relationship-specific unique key to a second personal data store of the second user. In these examples, the personal data store may be located in one of a first local memory or a first cloud storage, and the second personal data store may be located in one of a second local memory or a second cloud storage.

In some examples, retrieving the one or more stored identity tokens from the personal data store of the first individual may further includes retrieving one stored identity token from the personal data store of the first individual using the relationship-specific unique key as a reference point, and performing the probabilistic score based on the comparison of the one or more new identity tokens to the one or more stored identity tokens may further include performing the probabilistic score based on a comparison of one new identity token to the one stored identity token that is retrieved.

In some examples, the example process1000may further include requesting a second unique identifier from the second user, the second unique identifier being a different type from the unique identifier; and confirming the second user owns the second unique identifier. In these examples, determining the unique key associated with the first individual in response to confirming the first individual owns the unique identifier further includes determining an independent secret key associated with the first individual in response to confirming the first individual owns the unique identifier and confirming the second user owns the second unique identifier, and tokenizing the biometric template of the second user with the unique key associated with the first individual further includes tokenizing the biometric template of the second user with the independent secret key.

In some examples, retrieving the one or more stored identity tokens from the personal data store of the first individual may further include retrieving a plurality of identity tokens from the personal data store of the first individual, and performing the probabilistic score based on the comparison of the one or more new identity tokens to the one or more stored identity tokens may further include performing the probabilistic score based on the comparison of the one or more new identity tokens to the plurality of identity tokens that are retrieved.

Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the spirit and scope of the present disclosure. Embodiments of the present disclosure have been described with the intent to be illustrative rather than restrictive. Alternative embodiments will become apparent to those skilled in the art that do not depart from its scope. A skilled artisan may develop alternative means of implementing the aforementioned improvements without departing from the scope of the present disclosure. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings is to be interpreted as illustrative and not in a limiting sense.