CN112740249A

CN112740249A - Digital ticketing system and method

Info

Publication number: CN112740249A
Application number: CN201980061311.XA
Authority: CN
Inventors: M·S·班克斯顿; E·C·弗兰德
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2018-09-20
Filing date: 2019-09-20
Publication date: 2021-04-30
Also published as: SG11202102201QA; WO2020061488A1; US20210350369A1

Abstract

Methods and systems are disclosed for enabling an assertion to be provided to a relying entity associated with a discount or digital coupon for an item in a transaction. The assertion may indicate an interaction of a user device with a numeric indicator associated with the item and/or a resource provider that provided the item. The assertion may be associated with the user and later redeemed to apply the discount to the item involved in the transaction. The assertion may indicate an interaction with the numeric indicator at one location of the item and the assertion may be redeemable at another location of the same item, including an online transaction.

Description

Digital ticketing system and method

Cross reference to related applications

This application claims the benefit of U.S. provisional application No. 62/733,868 filed on 9/20/2018, which is incorporated herein by reference.

Background

In some cases, it is difficult to know whether a particular person is using a resource provider's physical store to evaluate goods or services, and simply purchase the goods or services online or otherwise at a different resource provider. While it is possible to track the location of a particular user activity by electronic means or otherwise, this approach is not very desirable due to privacy concerns.

Embodiments of the present invention address these problems and others individually and collectively.

Disclosure of Invention

One embodiment of the present disclosure is directed to a method, comprising: receiving, by a server computer from a target entity computer, a first request to form an assertion of a target entity and a resource provider associated with the target entity computer, the assertion including an identity of the target entity and a location of the resource provider, the first request generated in response to interaction of the target entity computer with a numeric indicator associated with the resource provider; generating, by the server computer based at least in part on the first request, the assertion comprising an identity attribute of the target entity, the identity attribute comprising the identity of the target entity and the interaction of the target entity computer with the digital indicator associated with the resource provider; receiving, by the server computer from a relying entity computer, a second request for the identity attribute associated with the target entity to conduct a transaction associated with a relying entity associated with the relying entity computer and the target entity, the second request comprising: a first identifier of the dependent entity; a second identifier associated with the target entity; and an item identifier of an item associated with the transaction; determining, by the server computer, in response to receiving the second request, a predicate model based at least in part on the first identifier and the second identifier; retrieving, by the server computer, the identity attribute based at least in part on the assertion model and one or more domain restrictions on the assertion; and transmitting, by the server computer, a ticket to the relying entity computer based at least in part on retrieving the identity attribute.

In an embodiment, the instrument is used by the relying entity to complete the transaction. The ticket may include a digital coupon for the item. In an embodiment, the one or more domain restrictions comprise at least one of: the method may further include the steps of disabling the ticket for a particular resource provider, disabling the ticket for the particular resource provider and a particular item, limiting use of the ticket to one or more resource providers specified by an entity, or limiting use of the ticket to a particular time period. In an embodiment, the method further comprises transmitting, by the server computer to a resource provider computer associated with the resource provider, a notification of the usage of the assertion in response to receiving the ticket from the relying computer.

In an embodiment, the notification includes the resource provider, the location of the resource provider, the item identifier, and the identity of the target entity. In an embodiment, the method further comprises transmitting, by the server computer to the relying entity computer, a payment token corresponding to a discount for the item in the transaction in response to receiving the ticket from the relying entity computer. In an embodiment, the second identifier associated with the target entity is maintained by an application of the target entity computer and provided in the second request. In an embodiment, the method further comprises transmitting, by the server computer to the target entity computer, a notification identifying the generation of the assertion by the resource provider. In an embodiment, another entity is prohibited from utilizing the assertion.

Another embodiment of the present disclosure is directed to a computer system, comprising: a processor; and a memory element comprising instructions that, when executed with the processor, cause the system to perform the method described above.

In an embodiment, the digital indicator comprises a Quick Response (QR) code. In an embodiment, the computer system implements a predicate model manager. In an embodiment, the assertion model manager receives the first request and the second request using an Application Programming Interface (API). In an embodiment, the second identifier associated with the target entity comprises the identity of the target entity. In an embodiment, the one or more domain restrictions are specified by the resource provider. In an embodiment, the location of the resource provider comprises a geographic location of the resource provider. In an embodiment, the second identifier associated with the target entity is maintained by an application of the target entity computer and provided in the second request. In an embodiment, the identity attribute is retrieved from a digital identity provider.

Another embodiment of the disclosure relates to a non-transitory computer-readable storage medium having instructions stored thereon, which when executed by a computer system, cause the computer system to perform the method described above.

Drawings

FIG. 1 is a schematic diagram of a system for providing at least one assertion, according to an embodiment;

FIG. 2 is a flow diagram of a method of providing at least one assertion, according to an embodiment;

FIG. 3 is a flow diagram of a method of providing at least one assertion, according to an embodiment;

FIG. 4 is a flow diagram of a method of providing at least one assertion that includes a digital coupon, according to an embodiment; and is

FIG. 5 is a workflow diagram for providing at least one assertion comprising a digital coupon, under an embodiment.

Detailed Description

An "issuer," "portable financial device issuer," "issuer," or "issuer bank" may include one or more entities that provide accounts to customers to conduct transactions (e.g., payment transactions), such as initiating credit and/or debit payments. For example, an issuer may provide a customer with an account identifier, such as a Personal Account Number (PAN), that uniquely identifies one or more accounts associated with the customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument (e.g., a payment card), and/or may be electronic and used for electronic payment. In some embodiments, the issuer may be associated with a Bank Identification Number (BIN) that uniquely identifies the issuer. An "issuer system" may include one or more computer systems, such as servers executing one or more software applications, operated by or on behalf of an issuer. For example, the issuer system may include one or more authorization servers for authorizing transactions.

An "account identifier" may include one or more types of identifiers associated with a user account (e.g., account identifier, PAN, card number, payment card number, account token, etc.). In some embodiments, an issuer may provide a user with an account identifier (e.g., PAN, account token, etc.) that uniquely identifies one or more accounts associated with the user. The account identifier may be embodied on a physical financial instrument (e.g., a portable financial instrument, a payment card, a credit card, a debit card, etc.) and/or may be electronic information communicated to the user so that the user may be used for electronic payment. In some embodiments, the account identifier may be a primary account identifier, wherein the primary account identifier is provided to the user when the account associated with the account identifier is created. In some embodiments, the account identifier may be an account identifier provided to the user after providing the original account identifier to the user (e.g., a supplemental account identifier). The account identifier may be any combination of alphanumeric, character and/or symbol, and the like.

An "account token" may include an identifier that serves as a substitute or replacement identifier for an account identifier of, for example, a PAN. The account token may be used as a substitute or replacement identifier for the original account identifier of, for example, a PAN. The account token may be associated with a PAN or other primary account identifier in one or more data structures (e.g., one or more databases, etc.), such that the account token may be used to conduct transactions without directly using the primary account identifier. In some embodiments, the primary account identifier of, for example, a PAN may be associated with multiple account tokens for different individuals or purposes. In some embodiments, the account token may be associated with a PAN or other account identifier in one or more data structures such that the account token may be used to conduct transactions without directly using, for example, the account identifier of the PAN. In some instances, an account identifier of, for example, a PAN may be associated with multiple account tokens for different uses or different purposes.

A "resource provider" may include one or more entities (e.g., operators of retail businesses) that provide goods and/or services to users (e.g., clients, customers, etc.) and/or access to goods and/or services based on transactions, such as payment transactions. A "resource provider computer" can include one or more computer systems operated by or on behalf of a resource provider, such as a server executing one or more software applications.

A "product" may include one or more goods and/or services offered by a resource provider. An example of a resource provider may include a merchant.

A "transaction service provider" may include an entity that receives a transaction authorization request from a merchant or other entity and, in some cases, provides payment assurance through an agreement between the transaction service provider and the issuer. For example, the transaction service provider may include a payment network, e.g.

Or any other entity that processes the transaction. As used herein, a "transaction service provider system" may include one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction service provider system executing one or more software applications. The transaction service provider system may include one or more processors and, in some embodiments, may be operated by or on behalf of a transaction service provider.

"client" and "client device" may include devices that may communicate with a server computer. As an example, a "client device" may include one or more POS devices and/or POS systems used by a merchant. It should be appreciated that the client device may be any electronic device configured to communicate with one or more networks and initiate or facilitate a transaction, such as, but not limited to, one or more computers, portable computers, tablet computers, cellular telephones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), PDAs, and/or other similar devices.

A "server" may include one or more computing devices, such as processors, storage devices, and/or similar computer components, that communicate with client devices and/or other computing devices over a network, such as the internet or a private network.

An "identifier" may include any information that may be used to identify certain content. In some embodiments, the identifier may be a special value generated randomly or according to a predetermined algorithm, code, or shared secret. For example, a driver's license number or a cryptographic key may be used to identify an individual. In some embodiments, the identifier may be in the form of one or more graphics, tokens, barcodes, Quick Response (QR) codes, or any other information that may be used to uniquely identify an entity. In some embodiments, the identifier may be in the form of an alphanumeric string corresponding to a user name or a resource provider name.

An "identity attribute" may comprise a particular piece of information about an entity (e.g., a person, an organization, a thing, etc.). Examples of identity attributes include name or other unique identifier associated with a person, social security number, age, phone number, and bank account number.

A "digital identity" (DI) may comprise a set of security information about an entity (e.g., a person, an organization, or thing). The DI may include a plurality of identity attributes, and a digital identity identifier identifying the digital identity. For example, the DI of the user Joe Smith may include: identity attributes such as the user's date of birth, social security number, address, and driver's license number; and an identifier, such as Joe _ Smith _1234 used to identify the digital identity of Joe Smith or an identity corresponding to a user, such as Joe Smith. The DI may be made available to another entity in a secure manner. The DI may rely on agreements between stakeholders and security measures such as passwords.

An "assertion" (sometimes referred to as an "assertion value") may include a security fact about an entity. Assertions can protect information while being useful for achieving a particular goal. For example, an assertion may specify certain content about an entity, such as whether the entity should be allowed to purchase alcohol at a particular location. The assertion may be "Jane Doe is sufficiently aged to purchase alcohol in California". The bar may use this assertion to decide to supply alcohol to someone without showing the person's license information to the bar. As another example, the assertion may specify whether the entity has an account that can accept the deposit (e.g., "Jane Doe has a bank account and can accept the deposit"). As another example, an assertion can specify whether an entity has interacted with a numerical indicator associated with a resource provider. The assertion may be that "Jane Doe has scanned a QR code provided by a resource provider using a mobile phone. "

The "assertion type" may be an assertion category, e.g., whether there is at least $ 100 in the entity's bank account. The "assertion" or "assertion value" associated with an assertion type may be a corresponding answer to a particular entity, which may be in the form of "yes" or "no," or may be an affirmative statement (e.g., "Jane Doe has $ 100 or more in its bank account," or "Jane Doe has interacted with a digital indicator provided by the resource provider"). The assertion may be cryptographically protected. The assertion may be digitally signed by an entity of interest and/or a trusted party that provides the security fact.

An "assertion mode" can be a set of assertion types that can be associated with a particular entity. The assertion model may specify one or more assertion types. For example, the assertion model may include two assertion types: whether the entity is sufficiently old to rent a car, and whether the entity has a valid driving license. The assertion model can be customized for a particular situation. Continuing with the previous example, whether the age of the entity is sufficient to rent a car and whether the entity has a valid driver's license may correspond to an assertion model of the context of a potential lessee interacting with the rental car agency. The assertion model may further specify a set of identity attributes. As another example, the assertion model may include a single assertion type, e.g., "do entities interact with a numeric indicator provided by a resource provider? The "assertion model may be used in the context of issuing digital coupons on behalf of an entity for subsequent transactions that are conducted in response to the entity interacting with a digital indicator provided by a resource provider.

"target entities" may include entities corresponding to assertions, DI, and/or identity attributes. For example, the target entity may be Mary Jones. Assertions about Mary Jones may specify whether Mary Jones are of sufficient age to purchase alcohol at a particular location. The relevant identity attribute of Mary Jones may be the exact age (e.g., 35 years) of Mary Jones. To continue the example, an assertion about Mary Jones may be that she interacts with a numeric indicator provided by a resource provider at a particular location. The relevant identity attribute of Mary Jones may be an identifier (e.g., name or other identifier such as Mary _ Jones _ 1234) of Mary Jones. As used herein, a "target entity computer" may refer to one or more computer systems operated by or on behalf of a target entity, such as a mobile computer device executing one or more software applications. The target entity may be referred to as a user and the target entity computer may be referred to as a user device.

A "relying entity" can include an entity that can receive assertions, DI, and/or identity attributes. For example, the relying entity may be a bar requesting an assertion whether the age of the target entity is sufficient to supply him with alcohol. In some embodiments, the relying entity may be a resource provider or a merchant. A "relying entity computer" can include one or more computer systems operated by or on behalf of a relying entity (e.g., a resource provider).

A "ticket" may include an element that allows the holder the right to obtain an item, such as a discount or value. In some embodiments, the instrument may include elements for accessing a digital coupon or prepaid card for use in a payment and settlement process to complete a transaction for a resource provider. The instrument may represent issuing a digital coupon or prepaid card for a particular target entity to complete a transaction with a relying entity, e.g., a resource provider, in response to the target entity interacting with a digital indicator provided by the resource provider (which may be the same or a different resource provider). In an embodiment, the instrument may be transmitted by the relying entity to a payment processing network to receive a monetary payment to complete the transaction.

A "key" may comprise a piece of information used in a cryptographic algorithm to transform input data into another representation. The cryptographic algorithm may be an encryption algorithm that transforms the original data into an alternate representation, or a decryption algorithm that transforms the encrypted information back into the original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), and the like.

Embodiments of the present invention may include systems, methods, and computer program products for providing at least one assertion about an entity, including whether the entity is eligible for any related instruments to complete a transaction with a dependent entity.

Referring now to fig. 1, a schematic diagram of an example system and method 100 for providing at least one assertion is shown, according to an embodiment. The system 100 may include at least one Digital Identity (DI) provider 121. For example, the DI provider may be an issuer, an acquirer, a transaction service provider, a government agency, etc., that is capable of creating and storing DI. DI provider 121 may communicate with at least one entity 111 to create and store DI associated with entity 111 as described herein. The entity 111 can include a user 111a and/or a client device 111b of the entity. As used herein, the term "entity" may include an individual (e.g., client, customer, etc.), a business or other legal organization, a governmental agency, and the like. Additionally or alternatively, the term "entity" can include something (e.g., an object, a piece of equipment, an electronic component, a computer system, etc.). Entity 111 may comprise a target entity.

In some embodiments, DI provider 121 and/or entity 111 may communicate with assertion model manager 131. For example, communication with the assertion model manager 131 can be direct, indirect, over a network such as the Internet, and/or through an Application Programming Interface (API), as described herein. Assertion model manager 131 can maintain and store (e.g., in a database or the like) assertion models to make assertions about entities 111. For example, each assertion model may be standardized and/or canonical such that information from various DI providers 121 about different entities 111 may be organized into assertion sets that are consistent regardless of the DI provider 121 or the source of the information, as described herein. Additionally or alternatively, each assertion model may be based on the domain that is expected to use the assertion model or the type of dependent entity 161 that requests an assertion about the entity, as described herein. In an embodiment, the assertion model manager 131 may be implemented by a server computer.

In some embodiments, the assertion model manager 131 can include and/or communicate with the assertion ledger 141 and/or the event log 151. The assertion ledger 141 and the event log 151 can each be stored in any suitable computer-readable storage medium and/or any suitable combination of computer-readable storage media. For example, the assertion ledger 141 and/or the event log 151 may be stored in a database. Additionally or alternatively, the assertion ledger 141 and/or the event log 151 can be maintained and stored in a distributed ledger, including but not limited to block chains and the like. For purposes of illustration and not limitation, referring to FIG. 1, assertion ledger 141 is depicted as a distributed ledger and event log 151 is depicted as a database.

In some embodiments, the assertion model manager 131 can communicate with the relying entity 161. For example, communication with the assertion model manager 131 can be direct, indirect, over a network such as the Internet, and/or through an API, as described herein. Relying entity 161 can be any entity that requests information (e.g., assertions) about entity 111, as described herein. For example, relying entity 161 can be a resource provider that requests information (e.g., assertions) about entity 111, referred to as a merchant's customer in terms of payment transactions. Additionally or alternatively, relying entity 161 can be an entity (e.g., a government agency or business organization) that requests information (e.g., an assertion) about entity 111 in terms of non-payment interactions (e.g., granting entity 111 access to a secure area or activity venue).

Referring now to fig. 2, a flow diagram of a method 200 for providing at least one assertion is shown, according to an embodiment. The exemplary system 100 of fig. 1 may be discussed with reference to the exemplary method 200 of fig. 2. At 210, a predicate model may be received or retrieved. For example, the assertion model manager 131 may retrieve or obtain data associated with the assertion model from a database. Additionally or alternatively, the assertion model manager 131 can retrieve data associated with the assertion model over a network from an external data store, including, but not limited to, a database, a distributed ledger, a blockchain, and the like. For purposes of illustration and not limitation, an assertion model can be a standardized and/or typical assertion model of an associated domain that can be determined based on the entity 111 to be asserted, the DI provider 121 from which DI data is to be obtained for assertion, and/or the relying entity 161 requesting the assertion. For example, prior to retrieving or receiving an assertion model, assertion model manager 131 can receive data associated with identifiers of entity 111, DI provider 121, and/or dependent entity 161 and determine a relevant domain/assertion model based on the received identifiers. In some embodiments, the identifier may include data associated with a digital signature and/or cryptographic key of entity 111, DI provider 121, and/or relying entity 161.

In some embodiments, the assertion model may include at least one assertion type. For example, a predicate model may include a set of predicate types that are sufficiently considered to be "well formed" for the relevant domain. Additionally or alternatively, the assertion model may include data associated with additional identifications, including but not limited to the name/identifier and current version number of the assertion model, and the date the assertion model was last updated.

For each assertion type of the assertion model, at 220, an identity attribute type corresponding to the assertion type can be determined. For example, the assertion model manager 131 can determine which identity attribute type(s) available from the DI provider 121 correspond to each assertion type in the assertion model. For example, if relying entity 161 is a car rental merchant, one assertion type in the assertion model is whether entity 111 is of sufficient age to rent a car in the country in which relying entity 161 is located, and the identity attribute type available from DI provider 121 is the date of birth of entity 111, and then assertion model manager 131 can determine that the date of birth identity attribute type corresponds to such assertion type. For example, if relying entity 161 is a resource provider or merchant that qualifies for digital coupons on behalf of entity 111, assertion model manager 131 can determine that the identity attribute type of interaction of entity 111 with a digital indicator associated with the resource provider corresponds to such assertion type. In other words, the assertion model may include, for example, "do the target entity interact with the numeric indicator at resource provider a? "is asserted. An assertion associated with this assertion type may be "target entity B interacts with a numeric indicator at resource provider a".

For each assertion type of the assertion model, at 230, a source of identity attribute data corresponding to the identity attribute type can be determined. For example, the assertion model may further include a list of valid information sources for the assertion type contained therein. Additionally or alternatively, a series of valid sources of information associated with one or more assertion models can be maintained and stored, as described herein. For purposes of illustration and not limitation, with reference to the exemplary case of asserting whether the age of entity 111 is sufficient for a car rental as described above, a list of valid sources of birth date information may include government documents (e.g., driver's license, birth certificate, passport, etc.), government databases, business organization records (e.g., of an issuer, transaction service provider, etc.), and the like. Additionally or alternatively, the authentication method used to authenticate the identity attribute type may be included in a range of valid sources and/or communicated by the DI provider 121. For example, the verification method may include checking the document by the DI provider 121, verification by a business organization (e.g., a third party service), and/or verification by a government agency.

For each assertion type of the assertion model, identity attribute data associated with the entity corresponding to the identity attribute type can be obtained at 240. For example, assertion model manager 131 can communicate with DI provider 121 to obtain identity attribute data associated with entity 111 that corresponds to the identity attribute types in the assertion model. DI provider 121 may provide identity attribute data that may include data associated with entity 111 corresponding to an identity attribute type and/or additional data associated with the identity attribute type, including but not limited to a data source, as described herein. For example, referring to the exemplary case of asserting whether the age of the entity 111 is sufficient for a rental car as described above, the identity attribute data associated with the birth date can be a numerical representation of the birth date of the entity 111, a bit or bit string indicating whether the entity is above a particular age threshold (e.g., the minimum age of a rental car) or in a particular age category (e.g., under 18, between 18 and 25, over 25), and so forth. In addition, the identity attribute data may include the source of the date of birth data (e.g., a visual inspection of the driver's license by the DI provider 121). In embodiments, the assertion model manager 131 may retrieve or otherwise obtain identity attributes without communicating with the DI provider 121. In the context of a target entity interacting with a digital indicator at a resource provider, the identity attribute data may be a data representation of the interaction between the computer of the target entity and the digital indicator at the resource provider (e.g., a data file of a QR code picture, a data flag, etc.).

For each assertion type of the assertion model, at 250, an assertion value corresponding to the assertion type can be calculated based on identity attribute data associated with the entity. For example, the assertion model manager 131 may calculate an assertion value based on data provided by the DI provider 121. For example, referring to the exemplary case of asserting whether the age of entity 111 is sufficient to rent a car as described above, the value of an assertion whether the age of entity 111 is sufficient to rent a car may be calculated based on birth date information provided by DI provider 121 using the following algorithm:

{ "OfAgeToRentAutoInUSA": yes, if "current date" - "verified birth date". gtoreq.25 years old, else "No" }

Where "ofagatoerentaoinusa" is an assertion whether the age of entity 111 is sufficient to rent a car in the united states, "yes" is a value if the age of entity 111 is sufficiently large, "no" is a value if the age of entity 111 is not sufficiently large, "current date" is the date on which the calculation was made, and "verified date of birth" is the date of birth of entity 111 provided by DI provider 121 after verifying the source of the data. Additionally or alternatively, an expiration date for the assertion may also be determined, or the expiration date may be omitted if the assertion does not expire, or the expiration data may have a null value, a "none" value, a 0 value, etc. In the context of a target entity interacting with a digital indicator at a resource provider, identity attribute data, such as a data representation of an interaction between a computer of the target entity and the digital indicator at the resource provider (e.g., a data file of a QR code picture, a data flag, etc.), may be used to calculate or determine an assertion value, such as "yes," the target entity interacting with the digital indicator, or "no," the target entity not interacting with the digital indicator. The value may depend on whether there is data representing the interaction.

For each assertion type of the assertion model or for the complete set of assertions, at 260, a strength/confidence score associated with the assertion value can be calculated based on the source of the identity attribute data. For example, a confidence score may be calculated based on a range of valid sources. Additionally or alternatively, the confidence score may be calculated based on a standardized or typical method for calculating the intensity. For example, the confidence score may be based on NIST Special publication 800-63A, digital identity guide: registration and identification Requirements (Digital identification Guidelines: environmental and identification improvements Requirements), department of commerce in the united states (11/15/2017 updated), may be calculated for the techniques described in https:// doi.org/10.6028/nist.sp.800-63a, the entire disclosure of which is hereby incorporated herein.

For each assertion type of the assertion model, at 265, an assertion can be created. Each assertion may include an assertion value and/or additional data associated with the assertion value including, but not limited to, the name of the assertion, the strength/confidence score of the assertion, the expiration date of the assertion, and the like. In addition, the assertion can be added to a set of temporary assertions that are stored when a complete set of assertions corresponding to the assertion model is completed. In an embodiment, an assertion may be generated and associated with an identifier of the entity 111 such that a recall (recall) of the assertion associated with the entity 111 may be mapped by the identifier. In the context of a target entity interacting with a numeric indicator at a resource provider, an assertion "yes, target entity interacting with the numeric indicator" or "no, target entity not interacting with the numeric indicator" may be created.

For each assertion type of the assertion model, at 270, it can be determined whether there are remaining assertion types in the assertion model that have not yet created an assertion. If there is at least one remaining assertion type, then the next assertion type can be selected and the process can repeat beginning at 220.

At 280, assertion data associated with the set of assertions can be transmitted. The set of assertions can include assertions (e.g., assertion values) corresponding to each assertion type of the assertion model. For example, assertion data associated with a set of assertions can be communicated from assertion model manager 131 to dependent entity 161. Additionally or alternatively, the assertion model manager 131 can write assertion data associated with the set of assertions to the assertion ledger 141. For example, the assertion ledger 141 can be a distributed letter that includes a blockchain. Additionally or alternatively, assertion data associated with the set of assertions can be transmitted/written using at least one of the digital signature/cryptographic keys of entity 111 or DI provider 121. For example, assertion data may be written to the distributed ledger using the cryptographic keys of entity 111 and DI provider 121 across all assertions.

At 290, the event log may be updated. For example, assertion model manager 131 can generate events in event log 151, and the events can be associated with the transfer of a set of assertions. Illustratively, the data associated with events in event log 151 can include an event type (e.g., from a series of standardized and/or typical assertion updates), an event value (e.g., associated with an event type in a series of standardized and/or typical assertion updates), an event date/time, an identifier of entity 111 (e.g., a cryptographic key of entity 111), an identifier of DI provider 121 (e.g., a cryptographic key of DI provider 121), an identifier of dependent entity 161 (e.g., a cryptographic key of DI provider 121), an identifier of a third party facilitator or technology provider (if present), and so forth. In an embodiment, entity 111 can provide at least one identity attribute data source 111c to assertion model manager 131. Assertion model manager 131 can verify identity attribute data source 111c and, if valid, create a DI for entity 111 to store at database or event log 151. Additionally or alternatively, the assertion model manager 131 can transmit a ticket to the relying entity 161 that validates identification of the identity attribute queried on behalf of the entity 111 to complete a transaction as described herein.

Referring now to fig. 3, a flow diagram of a method 300 for providing at least one assertion is shown, according to an embodiment. The exemplary system 100 of fig. 1 may be discussed with reference to the exemplary method 300 of fig. 3. Additionally, the method 300 of fig. 3 may be used in conjunction with, concurrent with, before, after, or as an alternative to the method 200 of fig. 2. At 310, a request for an assertion can be received. For example, assertion model manager 131 can receive a request for an assertion from relying entity 161. For example, the request may include first identification data identifying dependent entity 161 (e.g., a cryptographic key of dependent entity 161), second identification data identifying dependent entity 111 (e.g., a cryptographic key of entity 111), entity type data identifying the entity type associated with dependent entity 161 (e.g., a Merchant Category Code (MCC), etc.), and assertion request data associated with at least a subset of the assertion types in the assertion model. Additionally or alternatively, prior to communicating the request for the assertion, dependent entity 161 can present its identifier (e.g., cryptographic key of dependent entity 161) and/or its entity type (e.g., MCC) to assertion model manager 131, and assertion model manager 131 can communicate a set of assertions that permit the dependent entity 161 to request, e.g., based on the entity type of the dependent entity, etc. Such communications for determining the set of assertions that dependent entity 161 is permitted to request may also be recorded in event log 151 (e.g., assertion model manager 131 can update the event log, as described herein). For example, referring to the example of whether the age of entity 111 is sufficient to rent a car of the assertion type as described above, relying entity 161 can be permitted to request information regarding whether the age of entity 111 is sufficient to rent a car, has a valid driver license, has a valid payment token, and so forth. Illustratively, if the relying entity 161 is a bar/restaurant, the relying entity may be permitted to request whether the entity 111 is sufficiently aged to purchase alcohol, has a valid payment token, and so forth.

At 320, it may be determined whether the request is valid. For example, assertion model manager 131 can verify first identification data that identifies dependent entity 161, entity type data that identifies an entity type associated with dependent entity 161, and a subset of assertion types in the assertion model. For example, the assertion model manager 131 can confirm that the entity type matches a predetermined entity type associated with first identification data that identifies the dependent entity 161. Additionally or alternatively, the assertion model manager 131 can validate a subset of assertions that permit a dependent entity 161 to request based on the entity type. Additionally or alternatively, assertion model manager 131 can determine a strength/confidence score associated with the identification data of dependent entity 161. If the request is not valid, the process may end. Additionally or alternatively, a notification may be sent to relying party 161, including information as to why the request was invalid. The assertion model manager 131 can verify the first identification data that identifies the relying entity 161 to confirm that the relying entity 161 is approved to request an assertion for the entity 111.

At 330, if the request from the relying entity is valid, a notification can be transmitted to the entity. In some embodiments, the notification may include data identifying the dependent entity 161, the entity type of the dependent entity 161, a subset of the requested assertion type, a strength/confidence score associated with the dependent entity 161, and the like. At 340, it may be determined whether the entity 111 approves the request. In some embodiments, the entity 111 can transmit an acknowledgement that the assertion model manager 131 is approved to transmit response data associated with a subset of the assertion set to the relying entity 161 upon the request, and the assertion model manager 131 can receive the acknowledgement from the entity 111.

At 380, assertion data associated with the set of assertions can be transmitted. For example, the assertion data may be transmitted similar to that described above at 280 with reference to fig. 2.

At 390, the event log may be updated. For example, the event log may be updated similar to that described above with reference to FIG. 2 at 290. Additionally or alternatively, events generated in the event log may be associated with requests for subsets of assertions, which may be the same events or different events from the events associated with assertion transmission. Upon receiving the subset of assertions, relying entity 161 can determine whether to proceed with the interaction (e.g., payment transaction and/or non-payment interaction).

Fig. 4 is a flow diagram of a method of providing at least one assertion that includes a digital coupon, according to an embodiment. Fig. 4 is best understood in the context of the example system 100 shown in fig. 1, which in some embodiments may be adapted to provide assertions relating to digital coupons provided for items in a transaction. Referring to fig. 4, entity 111 may be referred to as a target entity. The assertion may be based on the target entity being associated with an identity or account of the target entity, the event interacting with a numeric indicator associated with or provided by the resource provider for an item provided by the resource provider using the associated target entity computer. In embodiments, the digital indicator may comprise an object that may be scanned, read, communicated, or otherwise interacted with by the target entity computer. Examples of the digital indicator may include a Quick Response (QR) code, a Near Field Communication (NFC) tag, a bluetooth enabled object, or other suitable electronic data object that may communicate with the target physical computer. The target entity may use the target entity computer to interact with a digital indicator associated with the resource provider and/or the item to generate an assertion associated with the identity or account of the target entity. The assertion may represent an item digital coupon or discount provided by the merchant or relying entity for the item during the payment and clearing process or upon completion of the transaction on behalf of the target entity.

The example system 100 may be adapted for use in contexts involving a relying entity 161 attempting to determine whether an assertion of a digital coupon or discount is associated with an entity 111 initiating a transaction for an item. Traditionally, users may enjoy item discounts with return to a zip. However, this conventional method may not be effective for a user to obtain a discount because the user may not or will not be willing to return a discount to enjoy the discount; and a return zip may be utilized to provide information (e.g., location and time) regarding how to obtain the broken connection for the discount. Furthermore, traditionally, the results or analysis of a rebate campaign has been difficult to obtain and identify the effectiveness of the rebate campaign. However, in embodiments described herein that correspond to a digital coupon assertion, information regarding obtaining and redeeming the digital coupon/assertion may be provided to entities other than the relying entity that requested whether the assertion existed. For example, an entity that provides a digital coupon or discount, such as a merchant, brick and mortar store, or manufacturer, may receive information from the assertion model manager 131 identifying the location where the user obtained the assertion, what kind of item is associated with the assertion, and the location where the user eventually redeemed the assertion. Information associated with the redemption of the assertion (digital coupon or discount) may help the entity determine the effectiveness of the digital discount activity and help identify a particular market or merchant to offer a future digital discount. To further facilitate the sale of the particular item. In embodiments, the example system 100 may be adapted to associate an assertion with an account or identity of a user to obtain a discount or digital coupon for an item associated with the assertion. In an embodiment, when the delegate entity 111 receives a request for a eligibility assertion for a digital coupon, the assertion model manager 131 may generate and transmit a notification or message to the resource provider that generated the digital indicator and digital coupon pair. As described herein, the notification or message to the resource provider may include the identity of the resource provider utilizing the digital coupon, the location of the resource provider, the identity of the entity 111, and/or item information, such as an item SKU corresponding to the item included in the transaction requesting the digital coupon.

In an embodiment, relying entity 161 can request on behalf of entity 111 initiating the item transaction whether an assertion exists for the item and entity 111. Assertions made to the items and entity 111 can include assertions between entity 111 and a particular resource provider. The entity 111 can provide the relying entity 161 with an identification of the entity itself, for example, by interacting with the relying entity 161 using a target entity computer (e.g., a user device) or by communicating with the relying entity 161 using an application of the target entity computer. As described herein, the entity 111 may have previously interacted with a digital indicator associated with the resource provider, such as by scanning a QR code in the resource provider location, such as a QR code at the resource provider's entity store, with the target entity computer. In embodiments, the numerical indicator may be associated with a location of the resource provider, or the numerical indicator may be associated with a particular item provided by the resource provider. The application of the target entity computer may transmit information obtained by the QR code (e.g., a resource provider identifier, item Stock Keeping Unit (SKU), or other item identifier) and information about the device and entity 111 (e.g., the target entity identifier and device information) to the assertion model manager/API 131. According to at least one embodiment, the assertion model manager/API 131 can generate and associate assertions representing interactions of the entity 111 with digital indicators of the identity of the entity 111 stored by the assertion model manager/API 131. In an embodiment, the assertion may be used to generate a discount or digital coupon for a digital prepaid card representing items that may only be redeemed or used by entity 111. In an embodiment, entity 111 is prohibited from transmitting or allowing other entities to use digital coupons that are related to assertions made to entity 111 and maintained by assertion model manager 131.

Relying entity 161 can submit a request for identity attributes on behalf of entity 111 to determine eligibility for digital coupons for items included in transactions conducted between relying entity 161 and entity 111. It should be noted that the relying entity 161 that submits a request for a digital coupon assertion can be a resource provider that provides a digital indicator, or can be a different resource provider that does not provide a digital indicator and therefore does not provide a digital coupon for an item. By utilizing the systems and methods described herein, a resource provider can incentivize entities to interact with provided digital indicators to access digital coupons that can be redeemed at different resource providers that provide the same item. In exchange for the entity interacting with the provided digital indicators, the resource provider providing the digital coupons may receive information that may be used to determine a transition in the marketing plan or the impact of the particular location of the entity store in the geographic location. The resource provider may receive such information when entity 111 performs a transaction for an item associated with the digital indicator and relying entity 161 submits a request for an assertion of the digital coupon on behalf of entity 111. An entity such as entity 111 may conduct transactions more efficiently because further interaction by the entity computer (the target entity computer) may not be required to notify the resource provider or relying entity 161 of its previous interaction with the digital indicator, which qualifies the resource provider or relying entity for a digital coupon or prepaid card for a transaction conducted by entity 111. Further, entity 111 does not have to browse or scroll through multiple user interfaces to locate and utilize assertions of digital coupons or prepaid cards that indicate that entity 111 is eligible for transactions that may be conducted by entity 111. Instead, the relying entity 161 and the assertion model manager 131 can utilize the identifier of the entity 111 to determine that the entity 111 is eligible for the discount and apply the discount to the transaction without further operation of the entity 111.

In an embodiment, the request from the relying entity 161 can include an identifier of the relying entity 161, an identifier of the entity 111, and transaction information, such as an item SKU for the item in the transaction. The request may be provided from the relying entity 161 to the assertion model manager 131, which may use the information in the request to look up or identify any assertions associated with the identity of the entity 111 and the item and/or relying entity 161. In some embodiments, the relying entity 161 can hash or encrypt any information that is then transmitted to the assertion model manager 131. For example, the relying entity 161 can hash or encrypt the identifiers of the relying entity 161 and the entity 111 and send the hashed or encrypted information to the assertion model manager 131. The assertion model manager 131 can take the hashed or encrypted information and compare it to a hash of the identifier archived with the assertion model manager 131, or decrypt the encrypted information using a private key maintained by the assertion model manager 131. The match comparison will indicate that the identifier was identified and can be used to identify any assertions associated with entity 111.

Assertion model manager 131 can archive or maintain several assertions associated with entity 111. For example, an entity may have used a target entity computer to interact with a number of numeric indicators provided by several different resource providers. Each interaction between the target entity computer and the digital indicator may form a new assertion corresponding to a digital coupon that may be redeemed during a transaction for an item provided by the system resource provider. Assertion model manager 131 may have information about whether entity 111 has any assertions associated with itself and the particular resource provider and/or item included in the transaction. The assertion model manager 131 can maintain information identifying whether an assertion (e.g., a prepaid card or a ticket associated with a prepaid card) has been redeemed to the relying entity 161.

Assertion model manager 131 can return an assertion or ticket indicating that there is an assertion for a discount, digital coupon, or prepaid card to relying entity 161. The assertion may serve as proof of a particular preconfigured fact (e.g., a user device associated with the user has previously interacted with a digital indicator associated with an item included in the transaction information). In an embodiment, relying entity 161 can provide the instrument to the payment processing network during the clearing and settlement process to complete a transaction corresponding to a payment request to redeem a prepaid card associated with an assertion between entity 111 of the transaction and a given resource provider providing a numerical indicator as described herein.

In one real-world example, a resource provider may be an entity that attempts to provide discounts or digital coupons to targeted entities attempting to purchase items. For example, the resource provider may be a business that provides a pair of basketball shoes. To provide discounts for basketball shoes, the resource provider may form a pre-established relationship with the assertion model manager 131 to provide digital coupons to designated entities that interact with the digital indicators provided by the resource provider for basketball shoes. Assertion model manager 131 can form an assertion for entity 111 that interacts with a numerical indicator provided by a resource provider, the numerical indicator including an identifier of entity 111 and a resource provider location or a particular item provided by the resource provider indicated by the numerical indicator. Assertion of this interaction may be used to provide a digital coupon when entity 111 provides the identity (identifier) of the entity during a transaction for an item at the resource provider or at a different resource provider (e.g., at the location of relying entity 161, a different relying entity at a different location, or a resource provider at a different location). If an assertion exists, the assertion model manager 131 can provide a ticket to the relying entity 161 that can be redeemed or otherwise provided during clearing and settlement of the token transaction associated with the prepaid card corresponding to the assertion, and that is associated with the entity 111 when interacting with the digital indicator of the item. The split payment process may be initiated by utilizing a token associated with the assertion and any other payment information or payment account provided by the entity 111, wherein the entity 111 pays less than the original price of the item and the token associated with the assertion is paid by the acquirer that generated the assertion and the corresponding numerical indicator.

In embodiments, assertion model manager 131 can use the identifier of entity 111 included in the request to identify an assertion associated with entity 111 to conduct a transaction in which an assertion request is received from relying entity 161. In an embodiment, assertion model manager 131 may contact a financial entity associated with entity 111 (e.g., DI provider 121) and provide an identifier of entity 111 to cause the financial entity (e.g., DI provider 121) to return an assertion associated with interaction of a corresponding target entity computer of entity 111 with a numerical indicator associated with an item and/or resource provider. In an embodiment, the assertion model manager 131 may have previously received assertions from financial entities (e.g., the DI provider 121) regarding the target entity computer's interaction with a digital indicator associated with an item, and the assertion model manager 131 may retrieve or locate those assertions based on an identifier of the entity and transaction information included in the request, such as item information (e.g., item SKU) or an identifier of a relying entity. The assertion may be a set of true/false or/no statements.

In embodiments, assertion model manager 131 may only collect assertions related to entity 111, relying entity 161, and/or items included in a transaction. A particular set of relevant assertions can be defined in advance in an assertion model that can be based on a particular dependent entity 161 or according to one or more domain constraints. In embodiments, a domain restriction may be one or more sets of rules that are associated with a potential assertion in response to an entity interacting with a numerical indicator of an item or resource provider using a target entity computer. For example, a domain restriction may include an assertion that can be used for: a particular item (e.g., a particular item SKU), a particular relying entity (e.g., a white list of white relying entities that can request and receive assertions), or a date limit, which can indicate a time range in which an assertion can be validly redeemed. Thus, the assertion model manager 131 can provide the requested information back to the relying entity 161 without jeopardizing the privacy of the individual and can initiate the preparation of a discount for an item, a digital coupon, or a prepaid card without the entity 111 needing any additional action, such as a return discount. Once relying entity 161 receives confirmation of an assertion associated with entity 111 of an item included in a transaction, a digital coupon or discount may be applied to the item, and entity 111 may purchase the item at a reduced price due to previous interactions with a digital indicator associated with the same item at a previous time and at a location, which may be a different location than the location at which relying entity 161 transacted.

The flow diagram of FIG. 4 may be best understood from the perspective of the assertion model manager 131, as described in the previous example. The assertion model manager 131 may be implemented by a server computer.

In an embodiment, at block 402, assertion generation is initiated by receiving a first request to form an assertion for a target entity and a resource provider in response to interaction of the target entity computer with a numerical indicator associated with the resource provider. The target entity may utilize the target entity computer to interact with a digital indicator associated with the item (e.g., scan a QR code of the item) to transmit information including the target entity identifier, the item interacted with, the resource provider providing the item, and the indication of the interaction to the assertion model manager. If an assertion has not been associated for this item and/or resource provider and the target entity, the assertion model manager can associate the assertion with the target entity identifier. In an embodiment, the identifiers of the target entity and the resource provider, the item information, and any other suitable information included in the numerical designator, and the indication of interaction may be transmitted to the assertion model manager through an application of the target entity computer, such as an application of a mobile device, over a network, such as the internet. The assertion model manager may collect this information, but in some embodiments, this information is not stored in plain text form. For example, some or all of the information may be hashed or encrypted. Additionally, some or all of the collected information may be tokenized.

In some embodiments, a copy of the token representing the assertion may be provided to the individual (e.g., for storage on the individual's user device) to allow the individual to use the token in conducting a transaction for an item associated with the assertion. Thus, an individual can attach the token of a payment account to his identity and conduct a transaction for the item associated with the assertion. More specifically, the token may contain information for redeeming the prepaid card.

In an embodiment, at block 404, the assertion model manager may generate an assertion that includes an identity attribute of the target entity based at least in part on the first request.

In some embodiments, at block 406, a second request for an identity attribute associated with the target entity may be received to conduct a transaction associated with the relying entity. The second request may include a first identifier of the relying entity, a second identifier associated with the target entity, and an item identifier of the transaction item. In embodiments, rather than manually entering information about its identity or identifier to conduct a transaction, the target entity may have provided a saved token (e.g., stored when the user established the assertion) from its target entity computer.

In an embodiment, at block 408, a predicate model may be determined based at least in part on the first identifier and the second identifier in response to receiving the second request. In an embodiment, the assertion model manager determines an assertion model of the dependent entity based on the received identifier of the dependent entity. The assertion model manager can have a variety of pre-configured assertion models, one of which can be associated with the particular dependent entity. Thus, the assertion model manager will use the identity of the dependent entity to look up the appropriate assertion model in order to determine the assertion that the dependent entity is authorized to receive. The assertion model manager can also identify and apply appropriate domain restrictions to identify appropriate assertions as described herein based on identifiers of dependent entities or item information.

In an embodiment, at block 410, the assertion model manager may retrieve an identity attribute based at least in part on the assertion model and one or more domain restrictions on the assertion. If an assertion exists for the target entity and the assertion model manager for the transaction item, the assertion model manager may retrieve an identity attribute that indicates eligibility for the digital coupon for the transaction.

In an embodiment, at block 412, for example, the assertion model manager may provide a ticket indicating that an assertion is present and may be provided by the relying entity to an acquirer or issuer to redeem an associated prepaid card for clearing and settling the transaction as described herein.

FIG. 5 is a workflow diagram for providing at least one assertion comprising a digital coupon, under an embodiment. The workflow of fig. 5 includes the target entity 502 interacting with a numeric indicator 506 provided by a resource provider 508 using a target entity computer 504 to generate an assertion maintained by a server computer 510. In an embodiment, server computer 510 may implement assertion model manager 131 of FIG. 1. Target entity 502 may be entity 111 of fig. 1. According to at least one embodiment, server computer 510 may store the assertion associated with target entity 502 in a database, such as database 512. Communication between the target entity computer 504, the server computer 510, and the relying entity computer 514 may occur via a network 516.

At step S1, target entity 502 may interact (518) with target entity computer 504 with a numeric indicator 506 provided by resource provider 508 to initiate forming an assertion by providing a first request as described herein. For example, the target entity 502 may interact with a numeric indicator 506 provided by a resource provider 508 to receive a discount on a particular brand T-shirt. The target entity computer 504 interacting 518 with the digital indicator 506 may include scanning a QR code provided by the resource provider 508. As described herein, the resource provider 508 may provide a digital coupon or prepaid card for purchasing a particular brand of T-shirt at another retail location or resource provider.

At step S2, target entity computer 504 transmits to server computer 510, in the form of a message, an identifier of target entity 502, an indication of the interaction between target entity computer 504 and numerical indicator 506, and any information included in the numerical indicator, such as item information, resource provider location, and the like, over network 516.

At step S3, server computer 510 may generate an assertion between target entity 502 and resource provider 508 or the item associated with numerical indicator 506, the assertion being mapped or associated with an identifier of target entity 502. The assertions may be stored in database 512.

At step S4, target entity 502 may utilize target entity computer 504 to conduct item transactions with the relying entity through relying entity computer 514. The transaction with the relying entity can be a resource provider other than the resource provider 508 that provides the digital indicator 506 and the digital coupon or prepaid card incentive assertion described herein.

At step S5, the relying entity computer 514 can generate a request (second request) for identity attributes of the target entity 502 for conducting the item transaction. The identity attribute may correspond to an assertion of target entity 502 that is identified by an identifier associated with target entity 502 and represents an interaction between target entity computer 504 and digital indicator 506. In an embodiment, the second request may include a first identifier of the relying entity, a second identifier associated with the target entity 502, and an item identifier associated with the transaction item.

At step S6, the server computer 510 may determine, in response to receiving the second request, an assertion model based at least in part on the first identifier and the second identifier. Server computer 510 may retrieve the identity attribute from database 512 based at least in part on the assertion model and one or more domain restrictions on the assertion.

At step S7, the server computer 510 may transmit a ticket to the relying entity computer 514 over the network 516 based at least in part on retrieving the identity attribute. As described herein, the instrument represents the qualification of a digital coupon or prepaid card for use by the relying entity and associated with the target entity 602 to complete the transaction.

Additional details regarding aspects of the embodiments can be found in united states provisional patent application No. 62/587,143, filed on 11, 16, 2017, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

Although the invention has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments, it is to be understood that such detail is solely for that purpose and that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present invention contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A method, comprising:

receiving, by a server computer from a target entity computer, a first request to form an assertion of a target entity and a resource provider associated with the target entity computer, the assertion including an identity of the target entity and a location of the resource provider, the first request generated in response to interaction of the target entity computer with a numeric indicator associated with the resource provider;

generating, by the server computer based at least in part on the first request, the assertion comprising an identity attribute of the target entity, the identity attribute comprising the identity of the target entity and the interaction of the target entity computer with the digital indicator associated with the resource provider;

receiving, by the server computer from a relying entity computer, a second request for the identity attribute associated with the target entity to conduct a transaction associated with a relying entity associated with the relying entity computer and the target entity, the second request comprising:

a first identifier of the dependent entity;

a second identifier associated with the target entity; and

an item identifier of an item associated with the transaction;

determining, by the server computer, in response to receiving the second request, a predicate model based at least in part on the first identifier and the second identifier;

retrieving, by the server computer, the identity attribute based at least in part on the assertion model and one or more domain restrictions on the assertion; and

transmitting, by the server computer, a ticket to the relying entity computer based at least in part on retrieving the identity attribute.

2. The method of claim 1, wherein the instrument is used by the relying entity to complete the transaction.

3. The method of claim 2, wherein the ticket comprises a digital coupon for the item.

4. The method of claim 1, wherein the one or more domain restrictions comprise at least one of: the method may further include the steps of disabling the ticket for a particular resource provider, disabling the ticket for the particular resource provider and a particular item, limiting use of the ticket to one or more resource providers specified by an entity, or limiting use of the ticket to a particular time period.

5. The method of claim 1, further comprising transmitting, by the server computer to a resource provider computer associated with the resource provider, a notification of use of the assertion in response to receiving the ticket from a relying computer.

6. The method of claim 5, wherein the notification includes the resource provider, the location of the resource provider, the item identifier, and the identity of the target entity.

7. The method of claim 1, further comprising transmitting, by the server computer to the relying entity computer, a payment token corresponding to a discount for the item in the transaction in response to receiving the ticket from the relying entity computer.

8. The method of claim 1, wherein the second identifier associated with the target entity is maintained by an application of the target entity computer and provided in the second request.

9. The method of claim 1, further comprising transmitting, by the server computer to the target entity computer, a notification identifying the generation of the assertion by the resource provider.

10. The method of claim 1, wherein another entity is prohibited from using the assertion.

11. A computer system, comprising:

a processor; and

a memory element comprising instructions that, when executed with the processor, cause the system to at least:

receiving, from a target entity computer, a first request to form an assertion of a target entity and a resource provider associated with the target entity computer, the assertion comprising an identity of the target entity and a location of the resource provider, the first request generated in response to interaction of the target entity computer with a numerical indicator associated with the resource provider;

generating, based at least in part on the first request, the assertion comprising an identity attribute of the target entity, the identity attribute comprising the identity of the target entity and the interaction of the target entity computer with the digital indicator associated with the resource provider;

receiving a second request from a relying entity computer for the identity attribute associated with the target entity to conduct a transaction associated with a relying entity associated with the relying entity computer and the target entity, the second request comprising:

a first identifier of the dependent entity;

a second identifier associated with the target entity; and

an item identifier of an item associated with the transaction;

in response to receiving the second request, determining a predicate model based at least in part on the first identifier and the second identifier;

retrieve the identity attribute based at least in part on the assertion model and one or more domain restrictions on the assertion; and

transmitting a ticket to the relying entity computer based at least in part on retrieving the identity attribute.

12. The computer system of claim 11, wherein the digital indicator comprises a Quick Response (QR) code.

13. The computer system of claim 12, wherein the computer system implements a predicate model manager.

14. The computer system of claim 13, wherein the assertion model manager receives the first request and the second request utilizing an application programming interface.

15. The computer system of claim 11, wherein the second identifier associated with the target entity comprises the identity of the target entity.

16. The computer system of claim 15, wherein the one or more domain restrictions are specified by the resource provider.

17. The computer system of claim 11, wherein the location of the resource provider comprises a geographic location of the resource provider.

18. The computer system of claim 11, wherein the second identifier associated with the target entity is maintained by an application of the target entity computer and provided in the second request.

19. The computer system of claim 11, wherein the identity attribute is retrieved from a digital identity provider.

20. A non-transitory computer-readable storage medium having instructions stored thereon, which when executed by a computer system, cause the computer system to at least:

receiving, from a target entity computer, a first request to form an assertion of a target entity and a resource provider associated with the target entity computer, the assertion comprising an identity of the target entity and a location of the resource provider, the first request generated in response to interaction of the target entity computer with machine-readable code associated with the resource provider;

generating, based at least in part on the first request, the assertion comprising identity attributes of the target entity, the identity attributes comprising the identity of the target entity and the interaction of the target entity computer with the machine-readable code associated with the resource provider;

a first identifier of the dependent entity;

a second identifier associated with the target entity; and

an item identifier of an item associated with the transaction;