Identity linkage systems and methods for fraud detection

Description

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 63/136,591 filed on Jan. 12, 2021 and titled “IDENTITY LINKAGE SYSTEMS AND METHODS FOR FRAUD DETECTION” The entire content of the above-referenced application is hereby expressly incorporated herein by reference in its entirety for all purposes.

LIMITED COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document includes material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights whatsoever.

FIELD OF EMBODIMENTS

The disclosure relates to providing online fraud detection to identity fraudulent or potentially fraudulent transactions.

SUMMARY OF EMBODIMENTS

Various systems, methods, and devices are disclosed for providing an identity linkage system to link a consumer's identity attributes and payment methods with stored consumer identity data. The systems, methods, and devices of the disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

Many identity attribute verification methods use data sources based on non-authoritative sources such as marketing databases. However, such data sources can be noisy, and verification methods using such data sources can return high false positives. Verification methods that exclude the inter-relationships between consumer identity attributes and payment methods may not adequately prevent fraudsters from using stolen identities and credit cards.

By directly linking a consumer's identity attributes and payment methods (for example, credit card numbers) with stored consumer identity data, the systems and methods described herein can provide improved online fraud detection, identity proofing, and authentication. Tying (or linking or correlating) an account number (for example, credit card number) to verified identity attributes like name, address, and/or phone number can prevent fraudsters from using stolen cards online, while ensuring legitimate customers are served without worrying about friction and declines.

In one embodiment, a system for online transaction fraud detection is disclosed. The system may include: one or more processors; a network communications interface; a memory; and computer code stored in the memory, wherein the computer code, when retrieved from the memory and executed by the one or more processors causes the one or more processors to: access a first set of payment instrument data associated with an online transaction in an active session and an account delivered via a first application programming interface of a client system; access a second set of identity attribute data associated with the online transaction in the active session and an identity; determine a client identifier associated with the online transaction in progress; apply client-specific parameters associated with the client identifier; using the client-specific parameters resolve the account automatically resolve the account using the client-specific parameters and the first set of payment instrument data to generate a resolved account; automatically resolve the identity using the client-specific parameters and the second set of identity attribute data to generate a resolved identity; select a match process based on the client-specific parameters and the payment instrument data; execute the selected match process to generate an encrypted data package storing a response code score based on the resolved account and the resolved identity, where the response code score is based on historical account data and historical identity data; and deploy the encrypted data package for automated delivery to a second application programming interface of the client system while the online transaction is still in the active session.

In another embodiment, a computer-implemented method of online transaction fraud detection is disclosed. The computer-implemented method may include, as implemented by one or more computing devices configured with specific executable instructions to at least: access a first set of payment instrument data associated with an online transaction in an active session and an account delivered via a first application programming interface of a client system; access a second set of identity attribute data associated with the online transaction in the active session and an identity; determine a client identifier associated with the online transaction in progress; apply client-specific parameters associated with the client identifier; using the client-specific parameters resolve the account automatically resolve the account using the client-specific parameters and the first set of payment instrument data to generate a resolved account; automatically resolve the identity using the client-specific parameters and the second set of identity attribute data to generate a resolved identity; select a match process based on the client-specific parameters and the payment instrument data; execute the selected match process to generate an encrypted data package storing a response code score based on the resolved account and the resolved identity, where the response code score is based on historical account data and historical identity data; and deploy the encrypted data package for automated delivery to a second application programming interface of the client system while the online transaction is still in the active session.

In a further embodiment, a non-transitory computer storage medium storing computer-executable instructions is disclosed. The non-transitory computer storage medium may store computer-executable instructions that, when executed by a processor, cause the processor to at least: access a first set of payment instrument data associated with an online transaction in an active session and an account delivered via a first application programming interface of a client system; access a second set of identity attribute data associated with the online transaction in the active session and an identity; determine a client identifier associated with the online transaction in progress; apply client-specific parameters associated with the client identifier; using the client-specific parameters resolve the account automatically resolve the account using the client-specific parameters and the first set of payment instrument data to generate a resolved account; automatically resolve the identity using the client-specific parameters and the second set of identity attribute data to generate a resolved identity; select a match process based on the client-specific parameters and the payment instrument data; execute the selected match process to generate an encrypted data package storing a response code score based on the resolved account and the resolved identity, where the response code score is based on historical account data and historical identity data; and deploy the encrypted data package for automated delivery to a second application programming interface of the client system while the online transaction is still in the active session.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings. The accompanying drawings, which are incorporated in, and constitute a part of, this specification, illustrate embodiments of the disclosure.

Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate embodiments of the subject matter described herein and not to limit the scope thereof. Specific embodiments will be described with reference to the following drawings.

FIG. 1 is an overall system diagram illustrating an embodiment of an identity linkage environment when processing a transaction using an identity linkage system.

FIG. 2A is an embodiment of a system diagram illustrating a transaction using an identity linkage system in conjunction with a merchant system.

FIG. 2B is an embodiment of a system diagram illustrating a transaction using an identity linkage system in conjunction with a fraud service provider system.

FIG. 2C is an embodiment of a system diagram illustrating a transaction using an identity linkage system in conjunction with a payment gateway system.

FIG. 2D is an embodiment of a system diagram illustrating a transaction using an identity linkage system in conjunction with a processor/acquirer system.

FIG. 3A illustrates an embodiment of an identity linkage system and system subcomponents.

FIG. 3B illustrates an embodiment of a linkage system of an identity linkage system.

FIG. 4 illustrates an embodiment of a high-level workflow of an identity linkage system.

FIG. 5 illustrates an embodiment of an inquiry proxy which may be used by an identity linkage system.

FIG. 6 illustrates an embodiment of a relationship proxy which may be used by an identity linkage system.

FIG. 7 illustrates an embodiment of a process for generating a match score for an online transaction.

FIG. 8 illustrates an embodiment of a process for generating a response code package for an online transaction.

FIG. 9 illustrates an embodiment of a client user interface for providing user interface elements to allow a client user to submit configuration parameters or criteria for an identity linkage system.

FIG. 10 is a block diagram depicting an embodiment of a computer hardware system configured to run software for implementing one or more embodiments disclosed herein.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the disclosure will now be described with reference to the accompanying figures. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of embodiments of the disclosure. Furthermore, embodiments of the disclosure may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments of the disclosure herein described. For purposes of this disclosure, certain aspects, advantages, and novel features of various embodiments are described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment. Thus, for example, those skilled in the art will recognize that one embodiment may be carried out in a manner that achieves one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.

Merchants who evaluate each element of a transaction separately for risk decisioning-consumer identity, payment instrument validity, and the transaction behavior-often do not have a holistic and integrated view of the overall risk. The fact that a given payment instrument is valid may not tell the complete story on the identity attached to it. For example, the fact that a given payment instrument is valid may not indicate whether there are any anomalous activities (for example, fraudulent activities that would normally make a merchant pause before processing an online purchase) associated with a consumer using the valid payment instrument. Similarly, the fact that an online purchase is made by a legitimate consumer may not inform the merchant whether the legitimate consumer is authorized to use the payment instrument in a transaction. Together, using a combination of consumer identity information, payment instrument information, and transaction data can improve the likelihood of detecting fraudulent, or potentially fraudulent transactions.

Existing card authentication measures often suffer from high false positives, friction, and lack of card issuer support. Card networks provided by companies like Visa and MasterCard do not possess consumer personally identifiable information (PII), but can connect transactions to credit cards. Card networks can verify a card's validity, but cannot verify a user. On the other hand, issuing banks possess consumer PII and transactional data on consumers. However, issuing banks cannot link consumer PII to cards, and do not share consumer PII with card networks (or other card issuers) so they cannot link cards and PII at scale. On the other hand, by implementing a system that allows access to both consumer PII and credit account information (for example, link between credit card number and consumer transactional data), embodiments of the system described herein can provide a system that directly links a consumer with the consumer's credit cards (for example, regardless of card network).

Further, because not all transactions involve credit cards, merchants who accept transactions by other payment methods, such as by debit card or via direct deposit accounts have limited option to verify that the consumer behind the transaction (for example, the information presented) owns or is authorized to transact with the payment method presented. Merchants have further difficulty evaluating these alternate payment transactions because debit card data is not widely available and direct deposit data is hard to obtain.

Embodiments of the system can provide an augmented payment instrument authentication process by adding the ability of verifying the linkage of the payment instrument with the consumer identity authorized to use the payment instrument. This system may also search for attribute linkages across the system's network of credit and identity inquiries to understand risk holistically.

In some embodiments, a merchant can query the system with a payment instrument number in the buy flow, the name of the customer, and, optionally, some or all of the shipping address and/or phone number through an application programming interface (API) call or other electronic communication channel. The system may, in real-time, match the payment instrument number to a corresponding identity and validate additional inputs, such as address and phone number against card issuer data. The card issuer data may be provided to the system on a periodic basis, such as for example, every month, biweekly, daily, or hourly. The system can then analyze the identity connected to the payment account (for example, credit card number), and automatically generate a risk assessment based on the identity and credit inquiries associated with the identity, or its attributes.

In some embodiments, an identity linkage system can verify the link between a payment instrument and a set of consumer identity attributes and, in real-time, create a new and differentiated asset to assess risk on a consumer-initiated online transaction involving use of a payment instrument (such as a credit card, debit card, and/or the like). The identity linkage system can receive consumer identity information and payment instrument information to generate accurate linkages (or profiles) associating the consumer identity information and the payment instrument information. After linkages are generated, they can be compared to incoming transaction data associated with online transactions to determine whether an online transaction may be fraudulent. The assessment may then be used by the various systems to approve, block, or flag for additional review an online transaction.

In some embodiments, the system is referred to as an identity linkage system and can, for example, reduce fraud losses from chargebacks and stolen credit cards, reduce friction in consumer onboarding and payment, improve decline rates at moment of transacting, reduce cart abandonment, and allow for refunds and/or credit disbursements to be funded to the correct consumer account or credit card.

In some embodiments, where data for specific payment methods (such as debit cards and direct deposit accounts) may be unavailable or difficult to access, the identity linkage system can assess risk for these types of transactions by providing proxy check on the identity as it relates to the payment method. In some embodiments, an inquiry proxy can be used, which may involve a method for determining payment risk and identity risk in payments by utilizing identity proofing inquiries in account openings as a proxy to determine the risk of a payment transaction by determining the correlation between successful and unsuccessful identity proofing events and payment transactions for a specific consumer identity. In some embodiments, a relationship proxy can be used, which may involve a method for determining payment risk and identity risk in payments by comparing known account relationships (for example, known to a credit bureau) to information provided during payment provisioning to determine the risk of a payment transaction by determining a correlation between successful and unsuccessful identity proofing events and payment transactions for a specific consumer identity.

In some embodiments, the identity linkage system can be used for various on-line or e-commerce fraud use cases including account opening, account take over, or chargebacks. In some embodiments, the system may only require a limited set of information, such as a first and last name, of a consumer for linking credit card to consumer identity. Additionally, the system may request other information such as, but not limited to, address, phone number, email address, and/or date of birth. It is also recognized that in some embodiments, portions of those data elements may be used in a variety of combinations, such as, for example, first initial with last name, street name with city and state, last name with zip code along with month and date of birth. Compared to existing credit account verification methods, the system may not post any inquiry on a consumer's credit report. As such, the system may be utilized for higher volumes and real-time on-line and e-commerce transactions.

Identity Linkage System Environment

FIG. 1 is an overall system diagram illustrating an embodiment of an identity linkage environment 100 for processing a transaction using an identity linkage system. The environment 100 can include consumer devices 104, issuing bank systems 116, and card network systems 114 in communication with a network 101 and an identity linkage system 102 in communication over network 101 with client systems, such as merchant systems 106, fraud service provider systems 108, payment gateway systems 110, and process/acquirer systems 112. While multiple systems are included in FIG. 1, it is recognized that in other embodiments there may only be a single system. Embodiments of the identity linkage system 102 will be further described with reference to FIGS. 3A and 3B.

The consumer device 104 may be a personal computer, a laptop computer, a smart phone, a tablet, and/or the like, that can be used to access a merchant system 106 over network 101, such as for online shopping. The merchant system 106 may be any system used by a merchant involved in online commerce conducting online transactions with consumer(s). The fraud service provider system 108 may be any system used by a fraud service provider that provides online fraud solutions. The payment gateway system 110 may be any payment gateway system that provides payment gateway services to merchants. The processor/acquirer system 112 may be any processor/acquirer system that provides payment processing services to merchants. The card network system 114 may be any system provided by a card issuer (such as companies like Visa, Mastercard, American Express, and Discover) that can verify card validity and connect transactions to credit cards. The issuing bank system 116 may be any financial or banking system that provides cards and credit limits to consumers or business and manage features of credit cards, including, for example, terms and benefits.

While FIG. 1 shows an example number of systems in communication with network 101, it is recognized that in some embodiments, multiple consumer devices 104, issuing bank systems 116, and card network systems 114 may be in communication with network 101 and the identity linkage system 102 may be in communication over network 101 with multiple client systems, such a multiple merchant systems 106, fraud service provider systems 108, payment gateway systems 110, and process/acquirer systems 112. Further, “multiple” can include, for example, tens, hundreds, thousands, or millions, of systems in communication with the identity linkage system 102.

The client systems (for example, client systems 106, 108, 110, and 112) can each include a transaction database and client parameters. The transaction databases can include transaction data associated with transactions conducted by a consumer or a set of consumers, such consumer devices 104. For example, the transactions data can represent transactions (for example, online transactions) conducted by consumer devices 104 with merchant systems 106.

Some examples of the transaction data associated with a transaction can include, but are not limited to, payment methods (for example, credit cards, debit cards, and Automated Clearing House (ACH) payments), payment term length (for example, one-time payment, 2 months, 3 months, 6 months, 12 months, 24 months, 60 months, and so forth), amount of credit history (for example, less than 5 years, greater than 5 years and less than 10 years, greater than 10 years, and so forth), device information (for example, device brand, IP address, operating system, user agent, and so forth), product type (for example, electronics, clothes, cars, books, and so forth), purchase dollar amount (for example, exact amount, less than $25, greater than $25 and less than $50, greater than $50 and less than $100, greater than $100 and less than $500, and so forth), Internet service provider (for example, Cox Communications, Charter Communications, AT&T Internet Services, and so forth), consumer credit history, and so forth. The system may utilize historical transaction data and historical fraud determinations and/or truth-marked data indicating whether or not a specific transaction was fraudulent or not.

In some embodiments, the transaction data may be collected by the client systems and stored in the corresponding transaction databases. It is recognized that the database may be stored in whole or in part on site in a client facility or in one or more cloud storage locations controlled or managed by the client. In some embodiments, the transaction data may be collected at different stages of corresponding transactions (for example, during log-in, before purchase, after purchase, and so forth). The transaction data may be stored individually or in batches.

The network 101 can comprise one or more networks, including, for example, a local area network (LAN), wide area network (WAN), and/or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication links. The network 101 can facilitate communication between the client systems 106, 108, 110, and 112 and the identity linkage system 102. The client systems 106, 108, 110, and 112 can transmit (for example, wirelessly) or make electronically available consumer transaction information stored in the corresponding transaction databases to the identity linkage system 102 via the network 101. Additionally, the client systems 106, 108, 110, and 112 can transmit (for example, wirelessly) or make electronically available client parameters stored in the corresponding transaction databases to the identity linkage system 102 via the network 101. In some embodiments, the identity linkage system 102 includes a user interface portal that allows the client parameters to be submitted and stored in the identity linkage system 102. Embodiments of the user interface portal will be discussed further with reference to FIG. 9. In some embodiments, the network 101 can be associated with (for example, operated by) the one or more of the clients 106, 108, 110, and 112 or the identity linkage system 102 (for an entity associated with the identity linkage system 102).

Embodiments of data flow and example transactions is described below for the different client systems 106, 108, 110, and 112 with reference to FIGS. 2A, 2B, 2C, and 2D.

Merchant Client System

FIG. 2A is an embodiment of a system diagram illustrating a transaction using the identity linkage system 102 where the merchant system 106 is the client system that receives the fraud analysis. A merchant using merchant system 106 may be any type of merchant who is involved in online commerce conducting online or e-commerce transactions with consumer(s). The identity linkage system 102 may be used by merchants whose merchant systems 106 include in-house fraud tools that can ingest the identity linkage system match codes, scores, and/or signals. In some embodiments, the identity linkage system 102 is configured to directly communicate with the in-house fraud tools and may provide merchants with up-front decisioning and intelligence before finalizing or approving an online or e-commerce transaction.

With continued reference to FIG. 2A, the process begins at block A after a consumer, using consumer device 104, accesses the merchant system 106 such as by a merchant app or via the merchant's website over network 101. The consumers, whether legitimate or not, may conduct online transactions with the merchant system 106 using a payment instrument, for example, a credit card or debit card. It is recognized that the authorized users of payment instruments may be individuals who have the credit/debit card account or persons who are authorized to use the credit/debit card account of other persons or of entities, such as an employee with authority to use the company credit card or an authorized user or joint owner of a credit card account. The use of the term “consumer” is meant to apply to any person using the payment instrument.

At block B, the consumer device 104 initiates an online transaction with the merchant system 106 through network 101. The consumer device 104 may provide some consumer PII along with payment instrument information (for example, credit card number, debit card number, routing number, direct deposit account number, and/or the like). The online transaction may be transmitted from the merchant app or website to the merchant system 106 via an API call or other electronic communication channel. The merchant system 106 may then wish to verify whether the payment instrument information provided by the consumer device 104 is valid (for example, whether the payment instrument information received has been previously associated with the consumer using consumer device 104). Since some merchants (such as ride hailing providers) assume a certain amount of risk upfront before receiving payment, it is important to some of those merchants to be able to confirm that the payment instrument information received is valid prior to providing the service. Additionally, for electronic commerce transactions where changes are made to an account, merchants may want to verify that the payment instrument is tied to a consumer before finalizing a transaction on the website. Further, for guest checkout, where very limited information and fraud signals are detected from a consumer, it can be important to verify the payer's identity and the payer's linkage to the instrument before transacting.

At block C, the merchant system 106 may provide the consumer PII and the payment instrument information from the consumer device 104 to the identity linkage system 102 through network 101, such as, via an API call or other electronic communication channel.

At block D, the identity linkage system 102 ingests the data, performs analytics, and generates a response package. The identity linkage system 102 may use existing linkages (or profiles) between consumer identity information and payment instrument information to determine whether the information provided by the consumer device 104 to the merchant system 106 is potentially fraudulent. Embodiment of this identity linkage system 102 analytics and response package generation will be described further with reference to FIGS. 3A, 3B.

At block E, the identity linkage system 102 sends or makes available a response package to the merchant system 106, such as, via an API call or other electronic communication channel. In some embodiments, the response package is fed directly into an in-house fraud tool executing within or in conjunction with the merchant system 106. Based on the response package, the merchant system 106 can make an informed decision, in real-time, to accept or decline the transaction. Embodiments of the response package and decisioning process will be described further with reference to FIGS. 7 and 8.

Fraud Service Provider Client System

FIG. 2B is an embodiment of a system diagram illustrating a transaction using the identity linkage system 102 where fraud service providers using fraud service providers system 108 is the client system that receives the fraud analysis. A fraud service provider using fraud service provider system 108 may be any of type of service provider that provides various fraud services and includes, for example, behavioral biometrics, device identification verification, identity verification, historical transaction monitoring, account take over, account opening, and/or the like. The identity linkage system 102 may be used by fraud service providers to improve fraud capabilities with preventive signals before transactions are processed in order to provide a value-add to existing e-commerce fraud solutions. In some embodiments, the identity linkage system 102 is configured to directly communicate with existing e-commerce fraud solutions and may provide fraud service providers with decisioning and intelligence that the fraud service providers may then deliver to the corresponding merchants. Further, the identity linkage system 102 may benefit merchants using merchant systems 106 that do not include in-house fraud tools that can ingest the identity linkage system, but instead rely on fraud service provider systems 108 for decisioning and intelligence before finalizing or approving an online or e-commerce transaction.

With continued reference to FIG. 2B, the process begins at block A after a consumer, using consumer device 104, accesses the merchant system 106 such as by a merchant app or via the merchant's website over network 101.

At block B, the consumer device 104 initiates an online transaction with the merchant system 106 through network 101. The consumer device 104 may provide some consumer PII along with payment instrument information (for example, credit card number, debit card number, routing number, direct deposit account number, and/or the like). The online transaction may be transmitted from the merchant app or website to the merchant system 106 via an API call or other electronic communication channel.

At block C, the merchant system 106 may provide the consumer PII and the payment instrument information from the consumer device 104 to the fraud service provider system 108 through network 101, such as, via an API call or other electronic communication channel.

At block D, the fraud service provider system 108 sends the consumer PII and the payment instrument information from the merchant system 106 to the identity linkage system 102 through network 101, such as, via an API call or other electronic communication channel.

At block E, the identity linkage system 102 ingests the data, performs analytics, and generates a response package.

At block F, the identity linkage system 102 sends or makes available a response package to the fraud service provider system 108 through network 101, such as, via an API call or other electronic communication channel. In some embodiments, the response package is fed directly into existing e-commerce fraud solutions executing within or in conjunction with the fraud service provider system 108. Based on the response package, the fraud service provider system 108 can make an informed decision as to whether the transaction appears fraudulent. A fraud service provider system 108 may provide further analysis and/or regression on the response package provided by the identity linkage system 102.

At block G, the fraud service provider system 108 sends a respond package to the merchant system 106 through network 101, such as, via an API call or other electronic communication channel. The response package sent to the merchant system 106 may be the same as or different from the response package sent to the fraud service provider system 108 from the identity linkage system 102. For example, for some merchant systems 106, a response package may be a simple indicator of whether the transaction meets a predetermined threshold of reliability determined by the fraud service provider system 108. For other merchants, a more complex response package may be provided by the fraud service provider system 108. Based on the response package, the merchant system 106 can make an informed decision, in real-time, to accept, decline, or further review the transaction.

Payment Gateway Client System

FIG. 2C is an embodiment of a system diagram illustrating a transaction using the identity linkage system 102 where a payment gateway using payment gateway system 110 is the client system that receives the fraud analysis. A payment gateway provider using payment gateway provider system 110 may be any of type of service provider that authorizes and/or directs payments for processing. Like fraud service providers, a payment gateway system 110 can use the identity linkage system 102 to provide merchants using the payment gateway system 110 with increased confidence in processing transactions. In some embodiments, the identity linkage system 102 is configured to directly communicate with existing fraud solutions within the payment gateway system 110 and may provide payment gateway providers with decisioning and intelligence that the payment gateway providers may then deliver to the corresponding merchants. An additional benefit may also be reduced costs up-front for the payment gateway providers. Further, the identity linkage system 102 may benefit merchants using merchant systems 106 that do not include in-house fraud tools that can ingest the identity linkage system and rely on payment gateway systems 110 for decisioning and intelligence before finalizing or approving an online or e-commerce transaction.

With continued reference to FIG. 2C, the process begins at block A after a consumer, using consumer device 104, accesses the merchant system 106 such as by a merchant app or via the merchant's website over network 101.

At block B, the consumer device 104 initiates an online transaction with the merchant system 106 through network 101. The consumer device 104 may provide some consumer PII along with payment instrument information (for example, credit card number, debit card number, routing number, direct deposit account number, and/or the like). The online transaction may be transmitted from the merchant app or website to the merchant system 106 via an API call or other electronic communication channel.

At block C, the merchant system 106 may provide the consumer PII and the payment instrument information from the consumer device 104 to the payment gateway system 110 through network 101, such as, via an API call or other electronic communication channel.

At block D, the payment gateway system 110 sends the consumer PII and the payment instrument information from the merchant system 106 to the identity linkage system 102 through network 101, such as, via an API call or other electronic communication channel.

At block E, the identity linkage system 102 ingests the data, performs analytics, and generates a response package.

At block F, the identity linkage system 102 sends or makes available a response package to the payment gateway system 110 through network 101, such as, via an API call or other electronic communication channel. In some embodiments, the response package is fed directly into existing fraud solutions executing within or in conjunction with the payment gateway system 110. Based on the response package, the payment gateway system 110 can make an informed decision as to whether the transaction appears fraudulent. A payment gateway system 110 may provide further analysis and/or regression on the response package provided by the identity linkage system 102.

At block G, the payment gateway system 110 sends a respond package to the merchant system 106 through network 101, such as, via an API call or other electronic communication channel. The response package sent to the merchant system 106 may be the same as or different from the response package sent to the payment gateway system 110 from the identity linkage system 102. For example, for some merchant systems 106, a response package may be a simple indicator of whether the transaction meets a predetermined threshold of reliability determined by the payment gateway system 110. For other merchants, a more complex response package may be provided by the payment gateway system 110. Based on the response package, the merchant system 106 can make an informed decision, in real-time to accept, decline, or further review the transaction.

Payment Processor/Acquirer Client System

FIG. 2D is an embodiment of a system diagram illustrating a transaction using the identity linkage system 102 where a payment processor/acquirer using processor/acquirer system 112 is the client system that receives the fraud analysis. A payment processor/acquirer using payment processor/acquirer system 112 may be any of type of service provider that authorizes and/or directs payments for processing. A payment processor/acquirer can use the identity linkage system 102 to provide additional information and eliminate additional steps for more informed decision making. In some embodiments, the identity linkage system 102 is configured to directly communicate with existing fraud solutions within the payment processor/acquirer system 112 and may provide payment processors/acquirers with decisioning and intelligence that the payment processors may then deliver to the corresponding merchants. Further, the identity linkage system 102 may benefit merchants using merchant systems 106 that do not include in-house fraud tools that can ingest the identity linkage system and rely on processor/acquirer systems 112 for decisioning and intelligence before finalizing or approving an online or e-commerce transaction.

With continued reference to FIG. 2D, the process begins at block A after a consumer, using consumer device 104, accesses the merchant system 106 such as by a merchant app or via the merchant's website over network 101.

At block B, the consumer device 104 initiates an online transaction with the merchant system 106 through network 101. The consumer device 104 may provide some consumer PII along with payment instrument information (for example, credit card number). The online transaction may be transmitted from the merchant app or website to the merchant system 106 via an API call or other electronic communication channel.

At block C, the merchant system 106 may provide the consumer PII and the payment instrument information from the consumer device 104 to the payment gateway system 110 through network 101, such as, via an API call or other electronic communication channel.

At block D, the merchant system 106 may provide the consumer PII and the payment instrument information from the consumer device 104 to the processor/acquirer system 112 through network 101, such as, via an API call or other electronic communication channel.

At block E, the processor/acquirer system 112 sends the consumer PII and the payment instrument information from the merchant system 106 to the identity linkage system 102 through network 101.

At block F, the identity linkage system 102 ingests the data, performs analytics, and generates a response package.

At block G, the identity linkage system 102 sends or makes available a response package to the processor/acquirer system 112 through network 101.

At block H, the processor/acquirer system 112 sends a response package to the payment gateway system 110 through network 101, such as, via an API call or other electronic communication channel. In some embodiments, the response package is fed directly into existing fraud solutions executing within or in conjunction with the payment processor/acquirer system 112. Based on the response package, the payment processor/acquirer system 112 can make an informed decision as to whether the transaction appears fraudulent. A payment processor/acquirer system 112 may provide further analysis and/or regression on the response package provided by the identity linkage system 102.

At block I, the payment processor/acquirer system 112 sends a response package to the merchant system 106 and/or the payment gateway system 110, through network 101. The response package sent to the merchant system 106 or the payment gateway system 110 may be the same as or different from the response package sent to the payment processor/acquirer system 112 from the identity linkage system 102. For example, for some merchant systems 106 or the payment gateway systems 110, a response package may be a simple indicator of whether the transaction meets a predetermined threshold of reliability determined by the payment processor/acquirer system 112. For other merchants or payment gateway providers, a more complex response package may be provided by the payment processor/acquirer system 112. Based on the response package, the merchant system 106 or the payment gateway system 110 can make an informed decision, in real-time, to accept, decline, or further review the transaction.

Identity Linkage System

FIG. 3A illustrates an embodiment of the identity linkage system 102 and system subcomponents. Identity linkage system 102 may include one of more of the following subsystems: web server 310, linkage system 320, and match system 330. Web server 310 may include further subsystems such as, for example, a web request processing system, a routing system, and/or the like. Linkage system 320 may include further subsystems such as, for example, a routing system and a single identity linkage server or different identity linkage servers, such as, based on the payment method (for example, credit card, ACH, or debit card payment). Match system 330 may include a single match system or further subsystems such as, for example, different match systems (match system A, B, . . . . N) for different payment methods, clients, client types, and/or the like.

With reference to the example transaction processes described in FIGS. 2A, 2B, 2C, and 2D, after a client system (for example, merchant system 106, fraud service provider system 108, payment gateway system 110, or processor/acquirer system 112) sends a request to the identity linkage system 102 over network 101 (for example through an API call or other electronic communication channel), the routing system may forward the request to the appropriate server on the network. Depending on which type of client is sending the request, a different processing system may be used. For example, the routing system may direct the request to a different server for each type of client such that each client is directed to the correct web request processing system for their client type. The request may also be directed to a different server in linkage system 320 depending on the payment method. Additionally, based on the request, a different match system from match system 330 may be used. The match system may be selected based on payment method, client type, and/or specific client. In some embodiments, the identify linkage system is configured to handle requests from merchant systems 106, fraud service provider systems 108, payment gateway systems 110, and processor/acquirer systems 112, but in other embodiments, the identify linkage system is configured to handle requests from a subset of those systems.

With reference to FIG. 1 and the transaction processes described in FIGS. 2A, 2B, 2C, and 2D, the identity linkage system 102 can communicate with card network system(s) 114 and issuing bank system(s) 116. After the identity linkage system 102 receives a request, the client system may provide the consumer PII and the payment instrument information from the consumer device 104 to the identity linkage system 102 through network 101. The identity linkage system 102 may then perform analytics. For example, the identity linkage system 102 may receive a first set of data from the client system (for example, client systems 106, 108, 110, and 112). The first set of data can include, for example, transaction information, credit card number, expiration date, name of a consumer, billing address, and/or the like associated with a given payment instrument. The identity linkage system 102 may also access a second set of data on file with an entity, such as, for example, a credit bureau or credit reporting agency. The second set of data may have been received by the entity storing the information periodically provided by reporting entities for credit bureau operations, such as reporting information from creditors. The second set of data can include, for example, consumer PII, such as consumer name, billing address, and/or the like, payment instrument information associated with a corresponding issuing bank (for example, Chase bank or Bank of America) and/or card network (for example, Visa, Mastercard), transaction data associated with a corresponding issuing bank and/or card network and its payment instruments, and the like. After the identity linkage system 102 receives the first set of data and accesses the second set of data, it can generate a linkage between the first set of data and the second set of data. For example, the linkage between the first set of data and the second set of data may provide a set of payment instruments and associated transaction data (for example, purchase data, billing address, shipping address, associated phone number, and the like) for a given consumer. In some embodiments, the linkage may be represented as a score where the value of the score relative to other potential scores indicates the strength of the linkage. In some embodiments, identity linkage system 102 may provide a confidence level that indicates the confidence of the linkage or linkage score. It is recognized that communication may include indirect communications via one or more other systems.

In some embodiments, the identity linkage system may rely on an exact match of consumer's payment method for one or more of the data elements (for example an exact credit card number match. In other embodiments, the identity linkage system may rely on a fuzzy match and confidence levels for some data elements (for example, home address). For example, the identity linkage system 102 may compare the full 16-digit credit card number and consumer identity attributes including consumer full name, address, and phone number. If there is no match for all of the consumer identity attributes, the identity linkage system 102 may determine that there is no match between the credit card and the consumer identity. On the other hand, if there is match for all of the consumer identity attributes, the identity linkage system 102 may determine that there is a match between the credit card and the consumer identity (that is, the credit card belong to the consumer). In some cases, there may be a no match for one of the attributes (for example, phone number), a partial match for one of the attributes (for example, address), and an exact match for one of the attributes (for example, full name). The identity linkage system 102 may then determine a match code or a score that, for example, indicates a likelihood of match between the credit card and the consumer. In some embodiments, the rules, fuzzy matching, and/or confidence levels may be different for different merchants and/or requests, as described further herein. Some parameters may be adjusted for certain transactions (perhaps transaction involving more expensive services or goods) to request stronger matches and confidence levels generally or for a specific purchase (if the services/goods are above a specific threshold). In some embodiments, the client systems (for example, client systems 106, 108, 110, and 112) may set parameters for the type of linkage, matching, scoring, and so forth that should be used for the analysis. The parameters may also be configured to apply in certain timeframes (for example, from 1-4 am Pacific or 3 weeks prior to December 25^th).

In some embodiments, merchants may not store all 16 digits of a consumer's credit card number or other received information. As such, the identity linkage system 102 may ingest and utilize partial credit card numbers (for example, first 6 digits or last 4 digits), partial birthdate information, or other truncated or partial data elements, to conduct matching between the credit card numbers and consumer PII.

In some embodiments, the identity linkage system 102 can include preventive mechanisms such as real-time flags on compromised cards and identity elements as well as ongoing monitoring. For example, during account opening or checkout process, online merchants may wish to reduce third party fraud by ensuring information and credit card provided by purchasers are not stolen or compromised. The identity linkage system 102 may initiate a scan of the dark web to search for compromised credit cards, debit cards, email, or other identity information. Additionally or optionally, the identity linkage system 102 may provide insights into how many times or how long ago this information (for example, comprised credit card number) has been seen in the dark web. In some embodiments, the identity linkage system 102 may send data packages to the client systems 106, 108, 110, and 112, may generate alerts or send notifications based on certain triggers, or may generate instructions to block a transaction (for example, if a client has configured the parameters to do so).

In some embodiments, linkages to multiple identity elements can increase the likelihood of successfully matching payment methods to consumer information, resulting in reduced fraud rates and false positives (for example, approving purchases based on fraudulent payment method number). Moreover, the identity linkage system 102 may utilize passive checking identity connections that can enable accurate risk decisions leading to increased transactional approval and consumer retention.

Linkage System

FIG. 3B illustrates an embodiment of the linkage system 320 of the identity linkage system 102. In some embodiments, the linkage system 320 may include a user interface 321, a response code package generator 322, a rules engine, 323, a database 324, and a network interface security system 325.

The user interface 321 may be implemented as a system that allows client parameters to be stored, response requests to be submitted, and different match services to be selected from the identity linkage system 102. Embodiments of the user interface 321 will be described further with reference to FIG. 9. The response code package generator 322 may be implemented as a system that enables the linkage system 320 to generate different response code packages as defined herein, where the identity linkage system 102 provides different clients with different response code packages. Embodiments of the response code package generator 322 will be described further with reference to FIGS. 7 and 8.

The rules engine 323 may be implemented as a system that stores and implements production and reaction rule capabilities and may be used in conjunction with other elements of the linkage system 320 and identity linkage system 102. The rules engine 323 may be configured to enable the registration, definition, classification, and management of the rules for the identity linkage system 102. For example, the rules engine 323 may operate in conjunction with other elements of the identity linkage system 102 to define and enable specific response code packages to be generated for different clients, client types, payment methods, and/or the like. In some embodiments, the rules engine 323 may be used to define the level of confidence associated with the different matches and partial matches, such as, at the data element level or at the transaction level. For example, some merchants may have rules requiring stronger matches and confidence levels generally or for a specific purchase. In some embodiments, the rules engine 323 may be configured to select and execute which parameters are evaluated for a specific merchant, merchant type, client, client type, payment method, and/or the like.

The database 324 may comprise one database or multiple databases. For example, there may be a separate database corresponding to each client or data from multiple clients may be stored using virtual partitions or access privileges to prevent the sharing of data among clients. The database 324 may be controlled by a database management system. The database 324 may be configured to store client data associated with the response code package generator 322, rules engine 323, and/or other elements of the identity linkage system 102. The database 324 may store permanently or temporally consumer PII along with payment instrument information provided by the clients to the identity linkage system 102, and the database 324 may also store sets of data from the card network system(s) 114 and sets of data from the issuing banks 116. The data stored can include, but is not limited to, full or partial credit card numbers, debit card numbers, and ACH routing numbers, demand deposit account numbers, registered identification numbers, payment instrument transaction data and expiration dates, consumer: names, billing addresses, shipping addresses, phone numbers, emails, dates of birth, full or partial social security numbers, driver's license numbers, and/or the like. In some embodiments, the data stored can include credit card numbers, debit card numbers, and/or ACH routing numbers that are hashed and encrypted for security and privacy preservation.

The network interface security system 325 may be implemented as a system that protects the network and data of the identity linkage system 102 from being breached or threatened. The network interface security system 325 may comprise a set of rules and configuration that is designed to protect the confidentiality and data of the identity linkage system 102. In some embodiments, the network interface security system 325 may include antivirus and antimalware software, firewall protection, and/or the like. In some embodiments, the network interface security system 325 may use mutual authentication of services using client certificate and/or message level encryption and digital signatures using elliptical curves. In some embodiments, the network interface security system 325 may use a standards-based approach to security using JavaScript object signing and encryption. In some embodiments, the network interface security system 325 may be deployed on premise and/or in the cloud and include multiple availability zones. In some embodiments, the network interface security system 325 may operate 24/7 and include automated deployments. In some embodiments, in the network interface security system 325, payment instrument numbers may be hashed prior to matching and then dropped for security protection.

High Level Workflow

FIG. 4 illustrates an embodiment of a high-level workflow of the identity linkage system 102. FIG. 4 shows various embodiment in which different client systems may utilize the identity linkage system 102 based on different consumer actions.

As illustrated in FIG. 4, a consumer 410 (such as, via a consumer device 104) can take a number of actions or electronic requests wherein a client 430 may want to conduct fraud checks using the identity linkage system 102 to increase the client's confidence in the consumer action. For example, a consumer 410 may initiate an electronic request to open an account 422 with a client 430, where a client may be for example, merchant system 106, fraud service provider system 108, payment gateway system 110, or processor/acquirer system 112. The account opening process 422 may involve the consumer 410 providing the client 430 with consumer PII and a payment method by sending data to the client's system. Another action may be the submission of an electronic payment 424, such as an online purchase with a merchant system or a payment to a merchant account. As discussed herein, this process also involves a consumer 410 providing the client 430 with consumer PII and a payment method by sending data to the client's system. As another example, a consumer action may be consumer 410 making an update 426 to the consumer's electronic information stored in a client 430's system. For example, a consumer 410 may have an account with client 430 and may send an electronic request to update their consumer PII or payment methods or provide additional payment methods to the client 430's system. With all of these consumer 410 actions, a client 430 may benefit by using identity linkage system 102 to confirm or increase their confidence that the actions taken were not fraudulent.

After a consumer 410 has taken an action with respect to client 430, the client 430 then has received at the client's system at least some consumer PII and a payment or account information. The client 430 may then send this information from the client's system to the identity linkage system 102, such as over network 101. As shown in FIG. 4, the client sends the information to a subsystem linkage system 440 of the identity linkage system 102. Linkage system 440 resolves the account and identity data, where embodiments are discussed with reference to FIG. 7 below. The resolved information is then sent to match system 450. As discussed with reference to embodiments of FIG. 8 below, match system 450 conducts a search and match process(es) 460 and generates response code package at 470. The response code package is then sent back to the linkage system 440 and a match score is generated for the specific action. Based on the match score, a response package is sent to client 430. The processes of generating match scores and response packages are discussed below with reference to FIGS. 7 and 8.

Inquiry Proxy and Relationship Proxy

As described above in FIGS. 2A, 2B, 2C, and 2D, at block B, after the consumer device 104 initiates an online transaction with the merchant system 106, the consumer may provide some consumer PII along with payment instrument information. The payment instrument can be a credit card, a debit card, a link to the consumer's direct deposit accounts, or other options. At this specific block there may be limited options for the merchant to verify that the consumer behind the transaction (for example, the information presented) owns/is authorized to transact with the payment method presented. Because not all transactions involve a credit card, the identity linkage system 102 may be used to verify the linkage between a credit card and an identity, as well as the linkage to other payment instruments including debit cards and direct deposit accounts. Because debit card data is not widely available and direct deposit data is hard to get, an embodiment of the identity linkage system 102 includes alternative ways on assessing risk for these types of transactions by providing “proxy” checks on the identity as it relates to debit cards and direct deposit accounts.

In some embodiments, one or both payment to identity proxies may be used by the identity linkage system 102. The first proxy check illustrated is an inquiry proxy, which is a method for determining payment risk and identity risk in payments by utilizing identity proofing inquiries in account opening as a proxy to determine the risk of a payment transaction by determining the correlation between successful and unsuccessful identity proofing events and payment transactions for a specific consumer identity. Embodiments of an inquiry proxy will be described further with reference to FIG. 5. The second proxy check illustrated is a relationship proxy, which is a method for determining payment risk and identity risk in payments by comparing account relationships known to an entity, such as a credit bureau, to information provided during payment provisioning to determine the risk of a payment transaction by understanding the correlation between successful and unsuccessful identity proofing events and payment transactions for a specific consumer identity. Embodiments of a relationship proxy will be described further with reference to FIG. 6.

Inquiry Proxy

FIG. 5 illustrates an embodiment of the inquiry proxy 500 which may be used by the identity linkage system 102. The inquiry proxy 500 relies on some stored historical knowledge of a consumer's prior financial actions. During the lifetime of a consumer, the consumer may open different bank accounts and credit instruments within the financial services ecosystem in a country, such as, the United States of America (US). As part of that account opening process, a bank or financial institution may perform a Know Your Customer (KYC) procedure and other checks to verify a consumer's identity. Banks and financial institutions may use a variety of products to facilitate the account opening process, and the usage of these products for identity verification leaves behind inquiry traces indicating the attempt (successful or not) by a consumer to open an account at one of these institutions. The identity linkage system 102 can access historical records of these inquiries or attempts as a proxy relationship between the bank and the consumer and extract insights on this that can be useful for de-risking online transactions.

With continued reference to FIG. 5, after the consumer device 104 initiates an online transaction with a merchant system 106, the consumer provides some identity attributes at 506 and payment information at 502. The identity attributes 506 may include consumer PII and may include some or all of: a consumer first name, last name, billing address, shipping address, phone number, email address, date of birth, social security number, and/or driver's license number. The payment information 502 may include some or all of a credit card number, debit card number, registered identification number, demand deposit account number, or other payment method information. For example, a first consumer may be online shopping and visit first merchant's website www.firstmerchant.com to purchase a first product. The first consumer wants to pay via debit card and inputs a card with the number 4247-20XX-XX11-1111 along with some of the consumer's PII. As shown in the embodiment of FIG. 2A, all or some of this information as well as additional information may be sent to the identity linkage system 102 by a merchant system 106. For example, the first merchant system 106 gathers the first consumer's information along with payment details and calls the identity linkage system 102, such as, via REST API, to verify if there is a linkage between the first consumer's payment method and the first consumer. In some embodiments, the online transaction may be initiated via an API request from an online payment provisioning touchpoint with the consumer's device.

Next at 504, the identity linkage system 102 resolves the account, which may include identifying the payment method issuer, bank, entity, country, type of instrument and/or the like. For example, the first six digits of the first consumer's card number (BIN number) can be used to identify the issuing bank, the type of card, the network scheme, and the issuing country (among other data points). For the first consumer, the identity linkage system 102 could determine from the BIN number (424720) that the card presented is a Visa traditional (not prepaid) debit card, issued by Wells Fargo Bank, in the US. Separate from 504, at 508, the identity linkage system 102 resolves the consumer identity using the provided consumer PII. For example, the first consumer may have opened an account with Wells Fargo Bank, five years ago. An identification product was used and indicates that a successful ID check was performed for first consumer after the KYC process executed. Using the identity data presented by the first consumer at the time the consumer provisioned the debit card (usually including, for example, a name and billing address), the identity linkage system 102 can resolve the first consumer's identity on the consumers on file with an entity storing the identity information, such as, for example, a credit bureau. It is recognized that 504 and 508 may be executed in parallel such that some or all of the processing time overlaps.

Next, at 510, the identity linkage system 102 performs an analysis of identity and/or verification inquiries. The analysis may include comparing the resolved account with other account inquiries related to a consumer through previous identity proofing inquiries. For example, the identity linkage system 102 may determine whether the consumer has applied for an account (for example, credit card accounts, debit card accounts, direct deposits accounts, and/or the like) in the past with the issuer/bank from the resolved account at 504. For example, after the first consumer has been identified, the identity linkage system 102 proceeds to take the card data-specifically the issuer name and match it against information on file to identify if this identity performed inquiries with this bank in the past.

Next, at 512, the identity linkage system 102 determines a score of flags, such as a measure of how confident the system is that the consumer and payment method are related, how risky the transaction is, and/or the like. Based on the score of flags, a response will be generated. For example, there may be an API response that sends a confidence score or code that indicates how close the relationship is between the consumer in question and the payment method used. For example, the identity linkage system 102 may provide a response package to the first merchant's system with a confirmation that the first consumer has a relationship with Wells Fargo which can be used as a proxy to indicate that the debit card could be tied to the first consumer and increase trust on this transaction. Additionally, the identity linkage system 102 may perform checks against the identity velocity and consistency and determine whether the first consumer's identity has been compromised.

Relationship Proxy

FIG. 6 illustrates an embodiment of the relationship proxy 600 which may be used by the identity linkage system 102. The relationship proxy 600 relies on some stored historical knowledge of a consumer's prior financial actions. During the lifetime of a consumer, the consumer may open different bank accounts and credit instruments within the financial services ecosystem in a country, such as the US. Credit related transactions are reported to entities, such as, credit reporting agencies and used to provide consumers and creditors with information on credit scores and credit worthiness. The identity linkage system 102 can view this information as a proxy relationship between the bank and the consumer and extract insights on this that can be useful for de-risking online payment transactions.

With continued reference to FIG. 6, after the consumer device 104 initiates an online transaction with a merchant system 106, the consumer provides some identity attributes at 606 and payment information at 602. The identity attributes 606 may be consumer PII and may include some or all of: a consumer first name, last name, billing address, shipping address, phone number, email address, date of birth, social security number, and/or driver's license number. The payment information 602 may include some or all of a credit card number, debit card number, registered identification number, demand deposit account number, or other payment method information. For example, a second consumer may be online shopping and visit second merchant's website www.secondmerchant.com to purchase a second product. The second consumer chooses to pay via direct deposit and enters his routing number (RTN or ABA) and direct deposit account (DDA) numbers RTN #322271627 and DDA #345XXXXXX along with some of the consumer's PII. The routing number is a nine-digit code that identifies banks in the U.S. As shown in FIG. 2A all or some of this information as well as additional information may be sent to the identity linkage system 102 by a merchant system 106. For example, the second merchant system 106 gathers the second consumer's information alongside payment details and calls the identity linkage system 102, such as, via REST API, to verify if there is a linkage between the second consumer's payment method and the second consumer. In some embodiments, the online transaction may be initiated via an API request from an online payment provisioning touchpoint with the consumer's device.

Next at 604, the identity linkage system 102 resolves the account, which may include identifying the payment method issuer, bank, entity, country, type of instrument and/or the like. For example, the second consumer's RTN number can be used to identify which bank the account is related to, among other data points. For the second consumer, the identity linkage system 102 could determine from the RTN number (322271627) that the account presented is a JPMorgan Chase account.

Separate from 604, at 608, the identity linkage system 102 resolves the consumer identity using the provided consumer PII. For example, the second consumer may have applied for a credit card with Chase Bank, one year ago. This credit relationship was reported to an entity, such as a credit bureau, and appears on the second consumer's credit report. Using the identity data presented by the second consumer at the time the consumer provisioned the account number (usually including, for example, beneficiary name and address), the identity linkage system 102 can resolve the second consumer's identity on the consumers on file with an entity storing the identity information, such as, for example, a credit bureau. It is recognized that 604 and 608 may be executed in parallel such that some or all of the processing time overlaps.

Next, at 610, the identity linkage system 102 performs an analysis of the consumer's profile. The analysis may include comparing the resolved account with other accounts on the consumer's file and determining if the relationship exists, the potential standing, and the longevity of the relationship. For example, the identity linkage system 102 may determine whether the consumer (for example, the resolved identity) has a relationship with the issuer or bank in questions from the debit, credit, bank, or entity determined from the resolved account at 604. For example, after the second consumer has been identified, the identity linkage system 102 proceeds to take RTN data-specifically the bank name and match it against information on file to identify if this identity has a relationship with the bank on the account.

Next, at 612, the identity linkage system 102 determines a score of flags, such as a measure of how confident the system is that the consumer and payment method are related, how risky the transaction is, and/or the like. Based on the score of flags, a response will be generated. For example, there may be an API response that sends a confidence score or code that indicates how close the relationship is between the consumer in question and the payment method used. For example, the identity linkage system 102 may provide a response package to the second merchant's system with a confirmation that the second consumer has a relationship with JPMorgan Chase which can be used by the second merchant as a proxy to indicate that the RTN/DDA could be tied to the second consumer and increase trust on this transaction. Additionally, the identity linkage system 102 may perform checks against the identity velocity and consistency and determine whether the second consumer's identity has been compromised.

Score Generation Process

FIG. 7 illustrates an embodiment of a process 700 for generating a match score for an online transaction.

At block 702, the identity linkage system 102 can receive transaction data associated with an online transaction. The transaction data may be provided by a client system such as, for example, a merchant conducting business in online commerce, such as, via an API call or other electronic communication channel. The transaction data can include, but is not limited to, consumer PII and payment instrument information. The transaction data may also include merchant data or identifiers.

At block 704, the linkage system 320 can use the transaction data to resolve the account data, such as in block 504 in FIG. 5 and block 604 in FIG. 6, and the linkage system 320 can resolve the identity data, such as block 508 in FIG. 5 and block 608 in FIG. 6.

At block 706, the linkage system 320 can determine the payment type from the transaction data. For example, the linkage system 320 may determine that the online transaction was initiated with a credit card.

At block 708, simultaneously in whole or in part with block 706, the linkage system 320 can determine the client and/or client type. For example, the linkage system 320 may determine that a specific client (such as first merchant) is providing the transaction data. Additionally, the linkage system 320 may determine the client type (such as determining that first merchant is a merchant system 106).

At block 710, simultaneously in whole or in part with blocks 708 and 706, the linkage system 320 can determine the transaction type. For example, whether the online transaction was a credit transaction.

At block 712, the linkage system 320 calls match service(s), such as match system 330, with the resolved parameter(s). The call may be an API call or other electronic communication channel. Embodiments of the match service(s) process will be described further with reference to FIG. 8.

At block 714, the linkage system 320 receives response code package(s) from match service(s).

At block 716, the linkage system 320 generates a match score for the online transaction based on a review of the received response package from match service(s), as discussed in FIG. 8. In some embodiments, the match score can be an alphanumerical value or graphical indicator. For example, the match score can be between 0 and 999 or between A and Z, where higher score indicates lower likelihood of fraud, and lower score indicates higher likelihood of fraud. As another example, the match score may be coded as a red, yellow, or green icon or graphic. However, it is recognized that the scoring can be made using a variety of indicators.

At block 718, the linkage system 320 generates a response package that includes an encrypted data package storing a score or indicator of score for secured transmission to the client system. In some embodiments, the linkage system 320 may also include a recommended action, or some execute other instructions such as, for example, to block transmission, report a fraudulent event, contact authorities, and so forth. The communication may be over an API, via system alert, a text message, and/or the like.

Response Code Package Generation Process

FIG. 8 illustrates an embodiment of a process 800 for generating a response code package for the online transaction.

At block 802, the match service(s) system, such as match system 330 can receive transaction data (resolved account and identity data) associated with an online transaction from the linkage system 320, as discussed with reference to block 712 of FIG. 7, such as, via an API call or other electronic communication channel.

At block 804, match system 330 can determine a match score for each of profile based on a review of the received data and data stored in an associated identity or consumer database, such as database 342 in linkage system 320. In some embodiments, the match score is determined based at least in part on the comparison between corresponding attributes or data elements of the initial list of profiles and the consumer identity information. Such corresponding attributes can include, but are not limited to, consumer PII, such as name, address, phone number, and/or the like. For example, match system 330 may review the transaction data along with data stored in an identity database (such as database 342 in linkage system 320) to generate a match score for the online transaction. In some embodiments the identity database may be a credit bureau database, a marketing database, a database comprised of data received from issuing banks, a database comprised of data received from card networks, a database comprised of data received from merchants, other data sets, and/or a combination of data sets.

In some embodiments, the match score can be generated based at least in part on comparisons between the profiles generated or stored by the identity linkage system 102 (that associate payment instrument information and consumer identity information) and attributes of the transaction data. For example, match system 330 can compare attributes (such as name, address, and phone number) of the transaction data to that of the profiles generated or stored by the identity linkage system 102. In some embodiments, the match score can be a numerical value. For example, the match score can be between 0 and 999 or between A and Z, where higher score indicates lower likelihood of fraud, and lower score indicates higher likelihood of fraud. As another example, the match score may be coded as a red, yellow, or green icon or graphic. However, it is recognized that the scoring can be made using a variety of indicators.

At block 806, match system, 330 can, based at least in part on the match scores, identify a profile with the best match score(s). The best match score(s) may be the highest match score(s) among the match scores for the initial list of profiles.

At block 808, the match system 330 can compare attributes of the profile with the best match score(s) with that of the transaction data.

At block 810, match system 330 can, based at least in part on the comparison between the attributes of the profile with the best match score(s) with that of the transaction data, generate a response code package(s) for the online transaction. In some embodiments, the response code package(s) can include an encrypted data package storing an indication of a likelihood of fraud for the online transaction. Additionally or optionally, the response code package(s) can include a recommended action (for example, deny transaction, request additional authenticating information, allow transaction, and the like) to the merchant.

At block 812, match system 330 can transmit the response code package(s) to the linkage system 320, such as, via an API call or other electronic communication channel.

Additional Identity Linkage Features

In some embodiments, the identity linkage system 102 can provide flags for compromised payment instruments and/or consumer identity information. For example, a merchant may receive payment instrument information (for example, credit card number and expiration date) and consumer PII (for example, consumer name, billing address, and shipping address). The identity linkage system 102 may receive the payment instrument information and the consumer identity information from the merchant and compare them with information that can be found in the dark web. For example, the identity linkage system 102 may scan the dark web to see if the payment instrument information received from the merchant (for example, credit card number and expiration date) can be found in the dark web. If so, the identity linkage system 102 may generate and send an alert or an electronic notification to the merchant's system or other client system indicating that the payment instrument information have been found on the dark web. In some examples, the alert may include a fraud score indicating the degree of likelihood that an online purchase associated with the payment instrument information is fraudulent. In other examples, the alert may include a recommended action or instruction (for example, to deny the online transaction) for the merchant or client.

In some embodiments, the identity linkage system 102 can reduce friendly fraud. For example, the identity linkage system 102 can determine, for example, if a shipping address of a potentially fraudulent transaction is related to someone in the household or someone a consumer knows. For example, if Person A uses a credit card information of Person B to purchase a good and have the good delivered to Person A's address, the identity linkage system 102 may recommend a merchant or client to approve (or not deny) Person A's purchase if (1) Person A and Person B are members of the same household, or (2) Person A is someone who Person B knows. In some embodiments, the identity linkage system 102 may use a persistent or consistent identifier that may be assigned to a household. In other embodiments, the identity linkage system 102 may use social web data collection or obtain data via APIs to determine whether a given person is related to (or an acquaintance of) another person. Alternatively or optionally, the identity linkage system 102 may use other third party sources to determine relationship of between a shipping address of an online purchase to a purported buyer (for example, a person whose payment instrument is being used to make an online purchase).

In some embodiments, historical data on verified (or fraudulent) linkages between payment instruments and consumer identity information for multiple merchants or service providers may consolidated to generate a consortium of identity inquiries. The identity linkage system 102 may use the consortium of identity inquiries to determine, for example, whether a certain combination of payment instrument information and consumer identity information have been seen before in potentially fraudulent (or verifiable) transactions. Additionally or optionally, the identity linkage system 102 may use historical data to determine a consortium score for an identity inquiry. For example, the consortium score for a given identity inquiry may be calculated based at least in part on historical transaction data associated with, for example, a combination of a certain payment instrument information (for example, credit card number) and consumer identity information (for example, a full name of a consumer) from more than one source. By comparing transaction data of a given identity inquiry to historical transaction data with similar or same payment instrument information and consumer identity information, the identity linkage system 102 may determine whether the given identity inquiry is normal or abnormal.

In some embodiments, the identity linkage system 102 may utilize real-time APIs and batch processes to target a wide range of uses including, but not limited to, protecting user account opening, account management functions (for example, identify and prevent account take over), order checkout (for example, assist good customers quickly sign-up and checkout by increasing trust while spotting potential fraud), disbursements and deposits (for example, verifying credit card account ownership or authorization before accepting or releasing funds) and other trust driven interactions in a business's payments flow such as consumer disbursements.

In some embodiments, the identity linkage system 102 may generate linkages between a given payment instrument and multiple identity elements. Such linkages may increase may allow users (for example, merchants) to have higher confidence is identity and payment instrument verification, which can result in reduced fraud rates and false positives.

Additionally, passive verification of identity to payment instrument linkage may enable accurate risk decisions that can lead to increased transaction approvals and customer retention for merchants and service providers.

Client User Interface

FIG. 9 illustrates an embodiment of a client user interface 900 for providing user interface elements to allow a client user to submit configuration parameters or criteria for the identity linkage system 102. Clients may include any clients identified herein, such as merchant system 106, fraud service provider system 108, payment gateway system 110, and/or process/acquirer system 112. In the example interface depicted, client users may, using the checkboxes 902, enable or disable one or more parameters or criteria 904. In some embodiments, clients may wish to adjust the relative importance of one or more parameters or criteria by adjusting one or more weights 906. In some embodiments, clients may wish to perform additional parameter customizations which may, for example, be accomplished by clicking the buttons 908 or other user interface elements which may cause the system to show additional configuration options to the user. In some embodiments, parameters may be, for example, specific parameters of interest such as which consumer PII the identity linkage system 102 can use to evaluate the transaction. For example, clients may wish to prioritize some elements of consumer PII while deprioritizing other elements of consumer PII. Client users may also wish to not include specific consumer PII in the data that is sent to the identity linkage system 102. In some embodiments, the client user may designate that the configuration parameters or criteria may apply to all of the consumers associated with the client system, whereas in other embodiments, the client user may designate different configuration parameters or criteria for different consumers, for different products, for different time periods, for different methods by which a consumer device 104 accesses the merchant system 106 (such as via app or website), for different procedure criteria, and/or the like.

In some embodiments, the client user interface 900 may also include a response checkbox 910 or other user interface element which can enable a client user to select whether they receive a response package from the identity linkage system 102 as well as how the response package will be configured. In some embodiments, client users may wish to perform response customization, which may, for example, be accomplished by clicking the button 908 or other user interface element which may cause the system to show additional response configuration options to the client user. For example, the client user may be able to select whether they receive an identity score, a simple response indicator, such as a yes/no, red/green and/or the like indicator, a more expansive report, and so forth.

In some embodiments, the client user may be able to choose which linkage system to use by clicking the drop-down menu 912 or other user interface element. For example, the client user may choose a credit card linkage system for a credit card payment by clicking checkbox 914, a debit card linkage system for a debit card payment by clicking checkbox 916, an ACH linkage system for an ACH payment by clicking checkbox 918, and/or the like. In some embodiments, the linkage system will be automatically selected based on the data send to the identity linkage system.

The identity linkage system 102 may store the parameters in a data store of the identity linkage system 102, such as the database 324. It is recognized that different clients may have different parameters. In addition, as noted above, a single client user may have different parameters for different consumers, for different products, for different methods by which a consumer device 104 accesses the merchant system 106 (such as via app or website), for different procedure criteria, and/or the like. It is also recognized that a variety of data input mechanisms may be used including graphical user interface elements as well as voice command features.

Computer Systems

FIG. 10 is a block diagram depicting an embodiment of a computer hardware system configured to run software for implementing one or more embodiments disclosed herein.

In some embodiments, the systems, processes, and methods described herein are implemented using a computing system, such as the one illustrated in FIG. 10. The example computer system 1002 is in communication with one or more computing systems 1020 and/or one or more data sources 1022 via one or more networks 1018. While FIG. 10 illustrates an embodiment of a computing system 1002, it is recognized that the functionality provided for in the components and modules of computer system 1002 may be combined into fewer components and modules, or further separated into additional components and modules.

The computer system 1002 can comprise a programming module 1014 that carries out the functions, methods, acts, and/or processes described herein. The programming module 1014 is executed on the computer system 1002 by a central processing unit 1006 discussed further below.

In general, the word “module,” as used herein, refers to logic embodied in hardware or firmware or to a collection of software instructions, having entry and exit points. Modules are written in a program language, such as JAVA, C or C++, Python, or the like. Software modules may be compiled or linked into an executable program, installed in a dynamic link library, or may be written in an interpreted language such as BASIC, PERL, LUA, or Python. Software modules may be called from other modules or from themselves, and/or may be invoked in response to detected events or interruptions. Modules implemented in hardware include connected logic units such as gates and flip-flops, and/or may include programmable units, such as programmable gate arrays or processors.

Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage. The modules are executed by one or more computing systems and may be stored on or within any suitable computer readable medium or implemented in-whole or in-part within special designed hardware or firmware. Not all calculations, analysis, and/or optimization require the use of computer systems, though any of the above-described methods, calculations, processes, or analyses may be facilitated through the use of computers. Further, in some embodiments, process blocks described herein may be altered, rearranged, combined, and/or omitted.

The computer system 1002 includes one or more processing units (CPU) 1006, which may comprise a microprocessor. The computer system 1002 further includes a physical memory 1010, such as random-access memory (RAM) for temporary storage of information, a read only memory (ROM) for permanent storage of information, and a mass storage device 1004, such as a backing store, hard drive, rotating magnetic disks, solid state disks (SSD), flash memory, phase-change memory (PCM), 3D XPoint memory, diskette, or optical media storage device. Alternatively, the mass storage device may be implemented in an array of servers. Typically, the components of the computer system 1002 are connected to the computer using a standards-based bus system. The bus system can be implemented using various protocols, such as Peripheral Component Interconnect (PCI), Micro Channel, SCSI, Industrial Standard Architecture (ISA) and Extended ISA (EISA) architectures.

The computer system 1002 includes one or more input/output (I/O) devices and interfaces 1012, such as a keyboard, mouse, touch pad, and printer. The I/O devices and interfaces 1012 can include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs as application software data, and multi-media presentations, for example. The I/O devices and interfaces 1012 can also provide a communications interface to various external devices. The computer system 1002 may comprise one or more multi-media devices 1008, such as speakers, video cards, graphics accelerators, and microphones, for example.

The computer system 1002 may run on a variety of computing devices, such as a server, a Windows server, a Structure Query Language server, a Unix Server, a personal computer, a laptop computer, a smart phone, a personal digital assistant, a tablet, and so forth. Servers may include a variety of servers such as database servers (for example, Oracle, DB2, Informix, Microsoft SQL Server, MySQL, or Ingres), application servers, data loader servers, or web servers. In addition, the servers may run a variety of software for data visualization, distributed file systems, distributed processing, web portals, enterprise workflow, form management, and so forth. In other embodiments, the computer system 1002 may run on a cluster computer system, a mainframe computer system and/or other computing system suitable for controlling and/or communicating with large databases, performing high volume transaction processing, and generating reports from large databases. The computing system 1002 is generally controlled and coordinated by an operating system software, such as Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, Windows 11, Windows Server, Unix, Linux (and its variants such as Debian, Linux Mint, Fedora, and Red Hat), SunOS, Solaris, Blackberry OS, z/OS, iOS, macOS, or other operating systems, including proprietary operating systems. Operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and provide a user interface, such as a graphical user interface (GUI), among other things.

The computer system 1002 illustrated in FIG. 10 is coupled to a network 1018, such as a LAN, WAN, or the Internet via a communication link 1016 (wired, wireless, or a combination thereof). Network 1018 communicates with various computing devices and/or other electronic devices. Network 1018 is communicating with one or more computing systems 1020 and one or more data sources 1022. The programming module 1014 may access or may be accessed by computing systems 1020 and/or data sources 1022 through a web-enabled user access point. Connections may be a direct physical connection, a virtual connection, and other connection type. The web-enabled user access point may comprise a browser module that uses text, graphics, audio, video, and other media to present data and to allow interaction with data via the network 1018.

Access to the programming module 1014 of the computer system 1002 by computing systems 1020 and/or by data sources 1022 may be through a web-enabled user access point such as the computing systems' 1020 or data source's 1022 personal computer, cellular phone, smartphone, laptop, tablet computer, e-reader device, audio player, or another device capable of connecting to the network 1018. Such a device may have a browser module that is implemented as a module that uses text, graphics, audio, video, and other media to present data and to allow interaction with data via the network 1018.

The output module may be implemented as a combination of an all-points addressable display such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, or other types and/or combinations of displays. The output module may be implemented to communicate with input devices 1012 and they also include software with the appropriate interfaces which allow a user to access data through the use of stylized screen elements, such as menus, windows, dialogue boxes, tool bars, and controls (for example, radio buttons, check boxes, sliding scales, and so forth). Furthermore, the output module may communicate with a set of input and output devices to receive signals from the user.

The input device(s) may comprise a keyboard, roller ball, pen and stylus, mouse, trackball, voice recognition system, or pre-designated switches or buttons. The output device(s) may comprise a speaker, a display screen, a printer, or a voice synthesizer. In addition, a touch screen may act as a hybrid input/output device. In another embodiment, a user may interact with the system more directly such as through a system terminal connected to the score generator without communications over the Internet, a WAN, or LAN, or similar network.

In some embodiments, the system 1002 may comprise a physical or logical connection established between a remote microprocessor and a mainframe host computer for the express purpose of uploading, downloading, or viewing interactive data and databases on-line in real time. The remote microprocessor may be operated by an entity operating the computer system 1002, including the client server systems or the main server system, an/or may be operated by one or more of the data sources 1022 and/or one or more of the computing systems 1020. In some embodiments, terminal emulation software may be used on the microprocessor for participating in the micro-mainframe link.

In some embodiments, computing systems 1020 who are internal to an entity operating the computer system 1002 may access the programming module 1014 internally as an application or process run by the CPU 1006.

In some embodiments, one or more features of the systems, methods, and devices described herein can utilize a URL and/or cookies, for example for storing and/or transmitting data or user information. A Uniform Resource Locator (URL) can include a web address and/or a reference to a web resource that is stored on a database and/or a server. The URL can specify the location of the resource on a computer and/or a computer network. The URL can include a mechanism to retrieve the network resource. The source of the network resource can receive a URL, identify the location of the web resource, and transmit the web resource back to the requestor. A URL can be converted to an IP address, and a Domain Name System (DNS) can look up the URL and its corresponding IP address. URLs can be references to web pages, file transfers, emails, database accesses, and other applications. The URLs can include a sequence of characters that identify a path, domain name, a file extension, a host name, a query, a fragment, scheme, a protocol identifier, a port number, a username, a password, a flag, an object, a resource name and/or the like. The systems disclosed herein can generate, receive, transmit, apply, parse, serialize, render, and/or perform an action on a URL.

A cookie, also referred to as an HTTP cookie, a web cookie, an internet cookie, and a browser cookie, can include data sent from a website and/or stored on a user's computer. This data can be stored by a user's web browser while the user is browsing. The cookies can include useful information for websites to remember prior browsing information, such as a shopping cart on an online store, clicking of buttons, login information, and/or records of web pages or network resources visited in the past. Cookies can also include information that the user enters, such as names, addresses, passwords, credit card information, etc. Cookies can also perform computer functions. For example, authentication cookies can be used by applications (for example, a web browser) to identify whether the user is already logged in (for example, to a web site). The cookie data can be encrypted to provide security for the consumer. Tracking cookies can be used to compile historical browsing histories of individuals. Systems disclosed herein can generate and use cookies to access data of an individual. Systems can also generate and use JSON web tokens to store authenticity information, HTTP authentication as authentication protocols, IP addresses to track session or identity information, URLs, and the like.

The computing system 1002 may include one or more internal and/or external data sources (for example, data sources 1022). In some embodiments, one or more of the data repositories and the data sources described above may be implemented using a relational database, such as Sybase, Oracle, CodeBase, DB2, PostgreSQL, and Microsoft® SQL Server as well as other types of databases such as, for example, a NoSQL database (for example, Couchbase, Cassandra, or MongoDB), a flat file database, an entity-relationship database, an object-oriented database (for example, InterSystems Caché), a cloud-based database (for example, Amazon RDS, Azure SQL, Microsoft Cosmos DB, Azure Database for MySQL, Azure Database for MariaDB, Azure Cache for Redis, Azure Managed Instance for Apache Cassandra, Google Bare Metal Solution for Oracle on Google Cloud, Google Cloud SQL, Google Cloud Spanner, Google Cloud Big Table, Google Firestore, Google Firebase Realtime Database, Google Memorystore, Google MogoDB Atlas, Amazon Aurora, Amazon DynamoDB, Amazon Redshift, Amazon ElastiCache, Amazon MemoryDB for Redis, Amazon DocumentDB, Amazon Keyspaces, Amazon EKS, Amazon Neptune, Amazon Timestream, or Amazon QLDB), a non-relational database, or a record-based database.

The computer system 1002 may also access one or more databases 1022. The databases 1022 may be stored in a database or data repository. The computer system 1002 may access the one or more databases 1022 through a network 1018 or may directly access the database or data repository through I/O devices and interfaces 1012. The data repository storing the one or more databases 1022 may reside within the computer system 1002.

Additional Embodiments

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The code modules may be stored on any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical disc, and/or the like. The systems and modules may also be transmitted as generated data signals (for example, as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (for example, as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The results of the disclosed processes and process steps may be stored, persistently or otherwise, in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage.

The various features and processes described above may be used independently of one another or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.

Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, generating, obtaining, looking up (for example, looking up in a table, a database, or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (for example, receiving information), accessing (for example, accessing data in a memory) and the like via a hardware element without user intervention. Also, “determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.

As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.

As used herein, the term “message” encompasses a wide variety of formats for communicating (for example, transmitting or receiving) information. A message may include a machine-readable aggregation of information such as an XML document, fixed field message, comma separated message, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

As used herein “receive” or “receiving” may include specific algorithms for obtaining information. For example, receiving may include transmitting a request message for the information. The request message may be transmitted via a network as described above. The request message may be transmitted according to one or more well-defined, machine-readable standards which are known in the art. The request message may be stateful in which case the requesting device and the device to which the request was transmitted maintain a state between requests. The request message may be a stateless request in which case the state information for the request is contained within the messages exchanged between the requesting device and the device serving the request. One example of such state information includes a unique token that can be generated by either the requesting or serving device and included in messages exchanged. For example, the response message may include the state information to indicate what request message caused the serving device to transmit the response message.

As used herein “generate” or “generating” may include specific algorithms for creating information based on or using other input information. Generating may include retrieving the input information such as from memory or as provided input parameters to the hardware performing the generating. After obtained, the generating may include combining the input information. The combination may be performed through specific circuitry configured to provide an output indicating the result of the generating. The combination may be dynamically performed such as through dynamic selection of execution paths based on, for example, the input information, device operational characteristics (for example, hardware resources available, power level, power source, memory levels, network connectivity, bandwidth, and the like). Generating may also include storing the generated information in a memory location. The memory location may be identified as part of the request message that initiates the generating. In some implementations, the generating may return location information identifying where the generated information can be accessed. The location information may include a memory location, network locate, file system location, or the like.

As used herein, “activate” or “activating” may refer to causing or triggering a mechanical, electronic, or electro-mechanical state change to a device. Activation of a device may cause the device, or a feature associated therewith, to change from a first state to a second state. In some implementations, activation may include changing a characteristic from a first state to a second state such as, for example, changing the viewing state of a lens of stereoscopic viewing glasses. Activating may include generating a control message indicating the desired state change and providing the control message to the device to cause the device to change state.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, and partially or fully automated via, software code modules executed by one or more general purpose computers. For example, the methods described herein may be performed by the computing system and/or any other suitable computing device. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer readable medium. A tangible computer readable medium is a data storage device that can store data that is readable by a computer system. Examples of computer readable mediums include read-only memory, random-access memory, other volatile or non-volatile memory devices, CD-ROMs, magnetic tape, flash drives, and optical data storage devices.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the systems and methods should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the systems and methods with which that terminology is associated.