Dependent risk adjustment indicator system and method

Abstract

A method is provided that includes receiving, by a user device, a request from an identity service to approve transmission of a user identity certificate to a relying party. A user of the user device is prompted to request the one-time transaction identifier based on the request. Based on a first input from a user, a user device requests a one-time transaction identifier from an identity service. In response to a request for a one-time transaction identifier, the user device receives the one-time transaction identifier from the identity server and displays the one-time transaction identifier on the first user device screen. The user enters a one-time transaction identifier on a second user device screen, and the user device transmits the one-time transaction identifier to the identity service. In response to receiving the at least one input one-time transaction identifier, the relying party determines whether to approve or deny the transaction.

Description

[0001] This application is a divisional application based on the Chinese patent application with application number 202011215169.0, application date November 4, 2020, and invention name “Relying Party Risk Adjustment Indicator System and Method”. Technical Field

[0002] The present disclosure relates to systems and methods for communicating identity trust and identity information using risk assessment identifiers. Background Art

[0003] The transaction system requires user authentication. Authentication may take the form of the user providing proof of identity. Such proof may take the form of a government identification credential or document (e.g., a social security number, driver's license, or passport) that the user sends to the system.

[0004] Risk assessments are often performed to determine the potential risk that a transacting user poses to a party conducting a transaction (hereinafter referred to as a "party" or "relying party"). For example, a payment system may use a user's transaction history as an input to a risk model to estimate the probability that the user is likely to complete a payment or default on a payment. Similarly, banks and lending institutions may use a user's credit history as a factor in their decisions to grant or not grant new loans. Payment systems may use user device information to identify returning users over a period of time and to detect attempts to impersonate a user. In such cases, the assessed risk is relevant to the transaction to be conducted. It does not necessarily indicate the potential risk that a user may pose to one or more classes of transactions that may be conducted. Summary of the invention

[0005] Thus and generally, the present disclosure provides illustrative non-limiting expressions, embodiments, or aspects of improved devices, systems, and methods that address the transmission of user information and the creation of at least one relying party risk adjustment indicator that can be associated with the transmitted information by a relying party risk adjustment indicator system. While a unique transaction identifier can be generated for each transaction that a user can use to conduct or perform at least one transaction, the risk that a user presents to a relying party regarding the user may vary as the at least one transaction is conducted. The relying party risk adjustment indicator system can determine a relying party risk adjustment indicator that can be used by a party issuing a requesting account or conducting at least one transaction to determine their transaction risk prior to issuing the account or conducting at least one transaction, and can be used by a relying party to support a decision to approve or deny issuing an account or conducting or performing a transaction with a user.

[0006] In some non-limiting expressions, embodiments or aspects, the present invention provides a relying party risk adjustment indicator generation system, comprising: at least one computing device, which is programmed or configured to: receive at least one account or transaction request for conducting transactions with at least one relying party from at least one user; receive at least one identity proof from at least one user; generate at least one one-time transaction identifier; access data associated with at least one user; generate at least one risk signal associated with at least one user based on the access data; generate at least one relying party risk adjustment indicator including at least one risk signal and at least one one-time transaction identifier; transmit at least one one-time transaction identifier to at least one user; and transmit at least one relying party risk adjustment indicator to at least one relying party of the transaction.

[0007] In some non-limiting expressions, embodiments, or aspects, at least one computing device of the relying party risk adjustment indicator generation system is programmed or configured to: receive at least one one-time transaction identifier from at least one user; and authenticate at least one user and proceed with at least one transaction. In some non-limiting expressions, embodiments, or aspects, at least one transaction includes at least one of: requesting an account, conducting a transaction, or any combination thereof.

[0008] In some non-limiting expressions, embodiments, or aspects, at least one risk signal is based on at least one of: at least one device fingerprint, at least one location, at least one transaction history, at least one risk score from at least one risk model, at least one assertion profile associated with at least one user, at least a partial match of at least one identification provided by at least one user with at least one stored identification previously received from at least one user, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one risk signal is transmitted as at least one of: a number, an alphanumeric number, a symbol, a minus sign, a plus sign, an equal sign, or any combination thereof, added to or concatenated with a one-time transaction identifier.

[0009] In some non-limiting expressions, embodiments, or aspects, at least one one-time transaction identifier and at least one risk signaler are both numbers that are combined to determine or generate a relying party risk adjustment indicator using at least one of: multiplication, division, addition, a non-linear expression, a result normalized relative to a predefined ratio, a hashed number, an encrypted number, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, data associated with at least one relying party risk adjustment indicator is stored in at least one of the storage devices of at least one computing device in at least one of: on a blockchain, in a relational database, a hierarchical database, an object-oriented database, a graph database, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one identity proof includes at least one of: at least one device identifier, a device fingerprint, a phone number, a location identifier, a home, business, mailing address, an assertion profile, at least one known or unknown assertion about a user, a government identifier, a social security number, a driver's license, a authorization photo, a passport, a government-provided identification card or tag, or any combination thereof.

[0010] In some non-limiting expressions, embodiments, or aspects, at least one risk signal includes an output of at least one risk model that calculates the risk of at least one transaction using at least one of the following: payments, agreements, assertions, compromise event reference identifiers, compromise event history records of at least one user, data from at least one risk source, credit bureau, government agency or department, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one computing device of the relying party risk adjustment indicator generation system is programmed or configured to generate a relying party risk adjustment indicator by combining at least one one-time transaction identifier and a risk signal associated with the risk posed by at least one user to at least one relying party for at least one transaction to be conducted.

[0011] In some non-limiting expressions, embodiments or aspects, the present invention provides a method for generating a relying party risk adjustment indicator, comprising: receiving, by at least one computing device, at least one account or transaction request for conducting at least one transaction with at least one party from at least one user; receiving, by at least one computing device, at least one identity certificate from at least one user; generating, by at least one computing device, at least one one-time transaction identifier; accessing, by at least one computing device, data associated with at least one user; generating, by at least one computing device, at least one risk signal associated with the data; generating, by at least one computing device, at least one relying party risk adjustment identifier including at least one risk signal and at least one one-time transaction identifier; transmitting, by at least one computing device, at least one one-time transaction identifier to at least one user; and transmitting, by at least one computing device, at least one relying party risk adjustment indicator to at least one relying party of the transaction.

[0012] In some non-limiting expressions, embodiments, or aspects, the method further includes: generating, by at least one computing device, a relying party risk adjustment indicator by combining at least one one-time transaction identifier and at least one risk signal associated with the risk posed by at least one user to the relying party for at least one transaction to be conducted. In some non-limiting expressions, embodiments, or aspects, the at least one risk signal is based on at least one of: at least one device fingerprint, location, at least one transaction history, at least one risk score from at least one risk model, at least one assertion profile associated with at least one user, at least a partial match of at least one identity provided by at least one user to at least one stored identity previously received from at least one user, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, the at least one risk signal is transmitted as at least one of: a number, an alphanumeric number, a symbol, a minus sign, a plus sign, an equal sign, or any combination thereof, added to or concatenated with the one-time transaction identifier.

[0013] In some non-limiting expressions, embodiments, or aspects, at least one one-time transaction identifier and at least one risk signaler are both numbers that are combined to determine or generate at least one relying party risk adjustment indicator using at least one of: multiplication, division, addition, a non-linear expression, a result normalized relative to a predefined ratio, a hashed number, an encrypted number, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, data associated with at least one relying party risk adjustment indicator is stored in a storage device of at least one computing device in at least one of: on a blockchain, in a relational database, a hierarchical database, an object-oriented database, a graph database, or any combination thereof.

[0014] In some non-limiting expressions, embodiments, or aspects, at least one identity proof comprises at least one of: at least one device identifier, device fingerprint, phone number, location identifier, home, business, mailing address, assertion profile, at least one known or unknown assertion about a user, government identifier, social security number, driver's license, authorization photo, passport, government-provided identification card or tag, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one risk signal comprises an output of at least one risk model that calculates the risk of at least one transaction using at least one of: at least one user's payment, agreement, assertion, breach event reference identifier, breach event history, data from at least one risk source, credit bureau, government agency or department, or any combination thereof.

[0015] Other non-limiting expressions, embodiments or aspects are set forth in the following numbered clauses.

[0016] Clause 1: A relying party risk adjustment indicator generation system, comprising: at least one computing device, which is programmed or configured to: receive at least one account or transaction request for conducting a transaction with at least one relying party from at least one user; receive at least one identity certificate from the at least one user; generate at least one one-time transaction identifier; access data associated with the at least one user; generate at least one risk signal associated with the at least one user based on the access data; generate at least one relying party risk adjustment indicator including the at least one risk signal and the at least one one-time transaction identifier; transmit the at least one one-time transaction identifier to the at least one user; and transmit at least one relying party risk-adjusted indicator to the at least one relying party of the transaction.

[0017] Clause 2: A relying party risk adjustment indicator generation system according to clause 1, wherein the at least one computing device of the relying party risk adjustment indicator generation system is programmed or configured to: receive the at least one one-time transaction identifier from the at least one user; and authenticate the at least one user and proceed with at least one transaction.

[0018] Clause 3: The relying party risk adjustment indicator generation system of clause 1 or 2, wherein the at least one transaction comprises at least one of: requesting an account, conducting a transaction, or any combination thereof.

[0019] Clause 4: A relying party risk adjustment indicator generating system according to any of clauses 1 to 3, wherein the at least one risk signal indicator is based on at least one of: at least one device fingerprint, at least one location, at least one transaction history record, at least one risk score from at least one risk model, at least one assertion profile associated with the at least one user, at least a partial match of the at least one identity proof provided by the at least one user with at least one stored identity proof previously received from the at least one user, or any combination thereof.

[0020] Clause 5: A relying party risk adjustment indicator generating system according to any one of clauses 1 to 4, wherein the at least one risk signal is transmitted as at least one of the following added to or concatenated with a one-time transaction identifier: a number, an alphanumeric number, a symbol, a minus sign, a plus sign, an equal sign, or any combination thereof.

[0021] Clause 6: A relying party risk adjustment indicator generating system according to any one of clauses 1 to 5, wherein the at least one one-time transaction identifier and the at least one risk signal symbol are both numbers that are combined to determine or generate the relying party risk adjustment indicator using at least one of the following: multiplication, division, addition, a non-linear expression, a result normalized relative to a predefined ratio, a hashed number, an encrypted number, or any combination thereof.

[0022] Clause 7: A system for generating a relying party risk adjustment indicator according to any one of clauses 1 to 6, wherein data associated with the at least one relying party risk adjustment indicator is stored in at least one of the storage devices of the at least one computing device in at least one of the following: on a blockchain, in a relational database, a hierarchical database, an object-oriented database, a graph database, or any combination thereof.

[0023] Clause 8: A relying party risk adjustment indicator generating system as described in any of clauses 1 to 7, wherein the at least one identity proof comprises at least one of: at least one device identifier, a device fingerprint, a telephone number, a location identifier, a home, business, mailing address, an assertion profile, at least one known or unknown assertion about the user, a government identifier, a social security number, a driver's license, an authorization photo, a passport, a government-provided identification card or label, or any combination thereof.

[0024] Clause 9: A system for generating a relying party risk adjustment indicator according to any one of clauses 1 to 8, wherein the at least one risk signal indicator comprises the output of at least one risk model that calculates the risk of the at least one transaction using at least one of the following: payments, agreements, assertions, breach event reference identifiers, breach event history records of at least one user, data from at least one risk source, credit bureau, government agency or department, or any combination thereof.

[0025] Clause 10: A relying party risk adjustment indicator generating system according to any one of clauses 1 to 9, wherein the at least one computing device of the relying party risk adjustment indicator generating system is programmed or configured to generate a relying party risk adjustment indicator by combining the at least one one-time transaction identifier and a risk signal symbol associated with the risk posed by the at least one user to the at least one relying party with respect to the at least one transaction to be conducted.

[0026] Clause 11: A method for generating a relying party risk adjustment indicator, comprising: receiving, by at least one computing device, at least one account or transaction request for conducting at least one transaction with at least one party from at least one user; receiving, by at least one computing device, at least one identity certificate from the at least one user; generating, by at least one computing device, at least one one-time transaction identifier; accessing, by at least one computing device, data associated with the at least one user; generating, by at least one computing device, at least one risk signal associated with the data; generating, by at least one computing device, at least one relying party risk adjustment identifier including the at least one risk signal and the at least one one-time transaction identifier; transmitting, by at least one computing device, the at least one one-time transaction identifier to the at least one user; and transmitting, by at least one computing device, at least one relying party risk adjustment indicator to the at least one relying party of the transaction.

[0027] Clause 12: The method for generating a relying party risk adjustment indicator according to Clause 11 further comprises: generating a relying party risk adjustment indicator by at least one computing device by combining the at least one one-time transaction identifier and at least one risk signal associated with the risk posed to the relying party by the at least one user for the at least one transaction to be conducted.

[0028] Clause 13: A method for generating a relying party risk adjustment indicator according to clause 11 or 12, wherein the at least one risk signal indicator is based on at least one of the following: at least one device fingerprint, location, at least one transaction history record, at least one risk score from at least one risk model, at least one assertion profile associated with the at least one user, at least a partial match between the at least one identity proof provided by the at least one user and at least one stored identity proof previously received from the at least one user, or any combination thereof.

[0029] Clause 14: A method for generating a relying party risk adjustment indicator according to any one of clauses 11 to 13, wherein the at least one risk signal is transmitted as at least one of the following added to or concatenated with a one-time transaction identifier: a number, an alphanumeric number, a symbol, a minus sign, a plus sign, an equal sign, or any combination thereof.

[0030] Clause 15: A method for generating a relying party risk adjustment indicator according to any one of clauses 11 to 14, wherein the at least one one-time transaction identifier and the at least one risk signal symbol are both numbers, which are combined to determine or generate at least one relying party risk adjustment indicator using at least one of the following: multiplication, division, addition, non-linear expression, a result normalized relative to a predefined ratio, a hashed number, an encrypted number, or any combination thereof.

[0031] Clause 16: A method for generating a relying party risk adjustment indicator according to any one of clauses 11 to 15, wherein data associated with the at least one relying party risk adjustment indicator is stored in a storage device of the at least one computing device in at least one of the following: on a blockchain, in a relational database, a hierarchical database, an object-oriented database, a graph database, or any combination thereof.

[0032] Clause 17: A method for generating a relying party risk adjustment indicator according to any of clauses 11 to 16, wherein the at least one identity proof includes at least one of the following: at least one device identifier, a device fingerprint, a telephone number, a location identifier, a home, business, mailing address, an assertion profile, at least one known or unknown assertion about the user, a government identifier, a social security number, a driver's license, an authorization photo, a passport, a government-provided identification card or label, or any combination thereof.

[0033] Clause 18: A method for generating a relying party risk adjustment indicator according to any one of clauses 11 to 17, wherein the at least one risk signal comprises the output of at least one risk model that calculates the risk of the at least one transaction using at least one of the following: payments, agreements, assertions, breach event reference identifiers, breach event history records of at least one user, data from at least one risk source, credit bureau, government agency or department, or any combination thereof.

[0034] These and other features and characteristics of the presently disclosed subject matter, as well as methods of operation and function of the related structural elements and combinations of parts and economies of manufacturing will become more apparent after considering the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals indicate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for illustration and description purposes only and are not intended as definitions of the limitations of the disclosed subject matter. As used in this specification and claims, the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The drawings incorporated herein illustrate one or more non-limiting expressions, embodiments, or aspects of the relying party risk adjustment indicator system apparatus, system, and method, which help explain different aspects of one or more expressions of the relying party risk adjustment indicator system apparatus, system, and method. Thus, the description and drawings are not to be considered as limiting any aspect of any expression, embodiment, or aspect of the apparatus, system, and method of the one-time risk adjustment identity system. In the drawings:

[0036] Figure 1are non-limiting expressions, embodiments, or aspects of system elements according to the principles of the present disclosure.

[0037] Figure 2 are non-limiting expressions, embodiments, or aspects of processes according to the principles of the present disclosure.

[0038] Figure 3 are non-limiting representations, embodiments, or aspects of process steps in accordance with the principles of the present disclosure.

[0039] Figure 4 are non-limiting representations, embodiments, or aspects of process steps in accordance with the principles of the present disclosure.

[0040] Figures 5A-5E are non-limiting expressions, embodiments or aspects of database structures according to the principles of the present disclosure.

[0041] Figure 6 are non-limiting expressions, embodiments, or aspects of user interaction according to the principles of the present disclosure.

[0042] Figure 7 are non-limiting expressions, embodiments, or aspects of user interfaces according to the principles of the present disclosure. DETAILED DESCRIPTION

[0043] For the purpose of description below, the terms "end", "upper", "lower", "right", "left", "vertical", "horizontal", "top", "bottom", "lateral", "longitudinal" and their derivatives shall relate to the expressions of the present disclosure as they are oriented in the accompanying drawings. However, it should be understood that unless expressly indicated to the contrary, the expressions, embodiments or aspects of the present disclosure may take various alternative variations, computing devices and storage device configurations within or among different parties and step sequences. It should also be understood that the devices, computing devices and storage device configurations and processes shown in the drawings and described in the following description are merely exemplary expressions, embodiments or aspects of the present disclosure. Therefore, specific dimensions, configurations and other physical characteristics related to the expressions, embodiments or aspects disclosed herein should not be considered limiting.

[0044] The aspects, components, elements, structures, actions, steps, functions, instructions, etc. used herein should not be understood as critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on".

[0045] As used herein, the terms "communication" and "communication" may refer to the reception, acceptance, transmission, delivery, provision, etc. of information (e.g., data, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, etc.) that is wired and / or wireless in nature. In addition, even if the transmitted information can be modified, processed, relayed and / or routed between the first unit and the second unit, the two units can also communicate with each other. For example, even if the first unit passively receives information and does not actively transmit the information to the second unit, the first unit can communicate with the second unit. As another example, if at least one intermediate unit (e.g., a third unit located between the first unit and the second unit) processes the information received from the first unit and transmits the processed information to the second unit, then the first unit can communicate with the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet, etc.) including data. It will be appreciated that many other arrangements are possible.

[0046] As used herein, the term "identifier" refers to a unique identifier associated with an individual that can be verified to confirm the individual when checking identity.

[0047] As used herein, the term "transaction" refers to an interaction between a user and a relying party where the interaction involves making a payment, providing access to a restricted event or area, generating a legally binding contract or agreement, or establishing any other type of arrangement where the parties wish to understand the risks associated with conducting a transaction that requires a user fiduciary relationship.

[0048] As used herein, the term "one-time transaction identifier" refers to an identifier that is valid for a predetermined period of time, or an identifier that can only be used once, or an identifier that is issued once, remains unchanged, and is always used.

[0049] As used herein, the term "assertion" refers to a factual true / false or yes / no statement about a user, or a combination thereof. For example, an assertion may indicate that the user is over a certain age, is a mortgage holder, and / or has held a bank account for a predetermined period of time. In each case, the assertion indicator may be "true" or "yes" or "false" or "no" or words having such meanings, which words may be combined when there is more than one assertion, or may include an assertion profile of the user requesting or conducting a transaction, or any combination thereof.

[0050] As used herein, the term "assertion profile" refers to a digital representation or profile of a user formed from information about the user and the user's activities without disclosing information that could uniquely identify a specific user.

[0051] As used herein, the term "user" may refer to an individual, a public or private company, or a government agency. The individual, public or private company, or government agency may be collectively referred to as "them" in the following disclosure and the appended claims.

[0052] As used herein, the term "party or relying party" refers to an individual, private or public company or entity (e.g., issuer, processor, or merchant), or government agency that uses a risk-adjusted transaction identifier to decide whether to conduct a transaction with a user. In some cases, the party is referred to as a "relying party," for example, relying on a risk-adjusted identifier to determine whether a user is a party with which it may wish to conduct a transaction.

[0053] As used herein, the term "processor" refers to an entity that is capable of issuing a one-time verified risk-adjusted identifier. Examples may include at least one of the following: an issuer, a smart contract processor, a payment processor, an acquiring processor, or a government processor. A processor may be the same party as the party conducting the transaction or a separate party not associated with the specific transaction being conducted, including but not limited to a third-party processor or a party whose business or service includes the creation of a one-time verified risk-adjusted identifier. The latter may include but are not limited to a government agency, a private or public for-profit or non-profit company.

[0054] As used herein, the term "identity service" refers to an entity that can verify or provide identity information for an individual or object. Examples may include, but are not limited to, a bank, an employer, a government agency or department (which may include, but is not limited to, a motor vehicle department, a tax service, or a registration service), or an insurance provider.

[0055] As used herein, the terms "match" and "partial match" refer to software or algorithms that can compare two acoustic, optical, and / or alphanumeric patterns to determine whether the two patterns include the same pattern based on a predetermined threshold. If the result equals or exceeds the threshold, the pattern is determined to be a "match" or a "partial match." Matching or partial matching software can include, but is not limited to, voice recognition, optical character matching, alphanumeric pattern matching programs, or any combination thereof.

[0056] As used herein, the term "identity" may include, but is not limited to, at least one device identifier (e.g., a device fingerprint or phone number), a location identifier (e.g., a home or business or other mailing address), an assertion profile (including which assertions about the user are known or unknown), a government identifier (e.g., a Social Security number or driver's license), an authorization photograph (e.g., from a passport, driver's license, or government-provided identification card or tag), or any combination thereof.

[0057] As used herein, the term "relying party risk adjustment indicator" refers to at least one indicator that a user may pose a risk to a relying party with respect to an account requested or a transaction conducted. The indicator may be generated using a one-time transaction identifier and a risk signal, which itself may be generated based on risk data available to the identity service.

[0058] According to some non-limiting expressions, embodiments or aspects, Figure 1 A system 100 of at least one processor for generating and transmitting to a user at least one one-time transaction identifier associated with a user is depicted. Example Components The system 100 may be implemented at least in part by hardware at one or more computing devices, which may include, but are not limited to, one or more hardware computing devices that execute software instructions stored in one or more storage devices to perform the functions described herein. Alternatively, one or more virtual machine instances in a shared computing device, such as, but not limited to, a cloud computing center, may be used. The system 100 illustrates only one of many possible arrangements of components configured to perform the programming described herein. Other arrangements may include fewer or different components, and the division of work between components may differ depending on the arrangement.

[0059] When stored in a storage device accessible to a computing device, the software instructions make the computing device a special-purpose computing device customized to perform the operations specified in the software instructions. The terms "software", "software instructions", "computer program", "computer executable instructions", and "computing device executable instructions" are interpreted broadly to cover any machine-readable information, whether human-readable or not, for instructing a computing device to perform specific operations, and include but are not limited to application software, desktop computer applications, scripts, binaries, operating systems, device drivers, boot loaders, shells, utilities, system software, JAVASCRIPT, web pages, network applications, plug-ins, embedded software, microcode, compilers, debuggers, interpreters, virtual machines, linkers, and text editors.

[0060] Although the functions and operations of one or more example embodiments may be fully implemented using software instructions, in accordance with the requirements of the current particular implementation, in some non-limiting expressions, embodiments or aspects, hard-wired or programmable circuit systems (e.g., ASICs, FPGAs, etc.) of a computing device may be used instead of or in combination with software instructions to perform the functions.

[0061] A user may use at least one user device 110 to request an account or conduct at least one transaction with at least one party, initiate at least one transaction with at least one relying party, register at least one of their identities, or any combination thereof, wherein at least one system 100 uses strong authentication, which is used by at least one party to conduct, initiate, accept, conduct (or any combination thereof) at least one transaction.

[0062] The user device 110 may include, but is not limited to, a mobile phone, a tablet computer, a laptop computer, a desktop computer, a wearable device, or any other device owned by a user that is capable of communicating with the system 100. The user may register his or her identity information using an input device or interface associated with the user device 110. The input device or interface may include, but is not limited to, a physical or numeric keyboard, a touch panel, a voice input or recognition system, a cursor control device, or a functionally equivalent input device or interface, the cursor control device may include, but is not limited to, a trackball, a mouse, or a touchpad. Strong authentication may include, but is not limited to, a one-time password, credential-based authentication, content-based authentication, multi-factor authentication, two-factor authentication, challenge-response authentication, an encryption process, or any combination thereof.

[0063] The system 100 may include one or more computing devices, one or more storage devices, and one or more components for communicating among and between the devices. The computing device may be a general-purpose microprocessor, a system on a chip, a mainframe computer, a cloud-based server, or any hardware capable of executing the programs required by the system 100. The computing device may also communicate with another computing device or at least one storage device using a coupled wired or optical bus, a wireless channel capable of communicating with at least one computer or storage device, or any combination thereof. The wireless channel may include, but is not limited to, wireless data networks and protocols (e.g., third generation (3G), fourth generation (4G), fifth generation (5G), long term evolution (LTE), and other previous, next generation, or similar networks), based on the IEEE 802.11x standard Local Area Network (LAN) network, based on Special Interest Standard (SIT) A Wide Area Network (WAN) network based on the IEEE 802.16 set of standards (Wi-Max), broadband B-ISDN, TCP / IP (which may include at least, but is not limited to, Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), Neighbor Discovery Protocol (NDP), ICMPv6, and IGMPv6 and an integrated IPSec security layer), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), Code Division Multiple Access (CDMA) protocol, Global System for Mobile Communications (GSM) protocol, or any such previous or future network that can provide access to a network that may include, but is not limited to, the Internet, a private network, or another device.

[0064] The storage device may be a random access memory (RAM) or other dynamic storage device for storing information and software instructions executed by the computing device; a read-only memory (ROM) or other static storage device for storing static information and software instructions for the computing device; or a mass storage device for storing information and software instructions on fixed or removable media, which mass storage device may include, but is not limited to, magnetic, optical, solid-state, magneto-optical, flash memory, or any other available mass storage technology.

[0065] The storage device can use any one or more storage media, including but not limited to any non-transient medium that stores data, software instructions or both and enables the computing device to run in a particular manner. Such storage media can include non-volatile media, volatile media or both. Non-volatile media can include but not limited to non-volatile random access memory (NVRAM), flash memory, optical disk, disk or solid state hard disk. Volatile media can include but not limited to dynamic memory that acts as main memory. Common forms of storage media include, for example, floppy disk, floppy disk, hard disk, solid state hard disk, magnetic tape, or any other magnetic data storage medium, CD-ROM, any other optical data storage medium, any physical medium with hole pattern, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, flash memory, and / or any other memory chip or cassette.

[0066] The computer hardware and software described above are presented to illustrate the underlying computer components that can be used to implement one or more example embodiments. However, one or more example embodiments are not necessarily limited to any particular computing environment or computing device configuration. Instead, one or more example embodiments can be implemented in any type of system architecture or processing environment that a person skilled in the art understands from this disclosure to be capable of supporting the features and functions of one or more example embodiments presented herein.

[0067] Representative identification may include, but is not limited to, a photograph of the user, an image of or information obtained from a government-provided identification credential or document (including, but not limited to, a social security number, driver's license, passport, or tax identification number), a biometric, a secret code known only between the user and the party (including, but not limited to, a password, PIN, or passcode), at least one assertion that may include an assertion profile, one or more know-your-customer data authorized by the user for identification or assertion purposes, or any combination thereof.

[0068] The system 100 may include at least one transaction computing device 120, at least one risk engine computing device 140, at least one identity computing device 150, at least one user identity certification storage device 130, at least one user transaction storage device 135, and at least one identifier storage device 160. It should be recognized that, depending on the design of the system 100, the computing device may be one or more different devices or the same device, and the storage device may be one or more different devices or the same device.

[0069] The identity proof provided by the user may be received by transaction computing device 120, and in response, the identity proof may be sent to identity computing device 150 to at least partially match at least one previously stored user identity proof accessible by identity computing device 150 from user identity proof storage device 130. The at least partial match result may then be sent to risk engine computing device 140, where the at least partial match result may be evaluated in conjunction with other risk-related information associated with the user that may be requested and received from transaction storage device 135.

[0070] The transaction storage device 135 stores the transaction history of the user. The transaction history of the user may include a series of at least one historical transaction record, at least one possible index associated with the user's history, which includes a number, user device information, an event log, a measure of user acceptance and rejection, at least one risk score associated with at least one previous transaction or index, or any combination thereof. The at least one risk score may be an output of at least one fraud model that estimates or predicts the likelihood that one or more past transactions will be considered fraudulent. Associated with the at least one risk score may be at least one risk condition code that may provide information about the nature and level of risk associated with the transaction, a compromise event reference ID that may identify a specific compromise event related to the transaction, or both.

[0071] The risk score may indicate the degree of risk that a user poses to a party because of the requested account or because the user wants to conduct and / or carry out a transaction with the party. The degree of risk may be represented by the results of at least one risk model. The results may come from at least one risk model associated with a user payment, a previously reached agreement, a valid or invalid assertion, or any combination thereof. The risk models used may include, but are not limited to, those models that may be based on Bayesian statistics or statistical regression, decision trees, random forests, regularized logistic regression, artificial intelligence models based on machine learning, or any combination thereof, which may be used to determine fraud, credit card or other financial, transactional or contractual risks. Other risk-related information that may be used alone or incorporated into an appropriate model may include, but are not limited to, at least one breach reference identifier, a specified breach, or data from some other risk source, including, but not limited to, a credit bureau, a government agency, a financial institution, or any combination thereof that the party may have access to.

[0072] The risk engine computing device 140 may use the user's transaction history and at least one risk score, or a risk condition code, or a compromise event reference ID or device information associated with the user, or any combination thereof, at least one decision rule used in combination with such data, or any combination thereof, to determine and output the degree of risk that the user may pose to the party if the party accepts the user's transaction request. The degree of risk may be represented by a risk signal symbol, which may include a number (e.g., from 1 to 100), a score expressed as a percentage, a qualifier (e.g., high, medium, low), a symbol (e.g., a plus sign for acceptable risk, a minus sign for unacceptable risk, or an equal sign for uncertain or medium risk), and any possible combination thereof.

[0073] The risk signal symbol output by the risk engine calculation device 140 can be sent to the one-time transaction identifier calculation device 150 to create a one-time transaction identifier for the user to use for at least one transaction. The one-time transaction identifier can be a one-time alphanumeric identifier that can be sent to the user's device 110 and simultaneously sent to the identifier storage device 160 and stored therein.

[0074] At least one one-time transaction identifier may be combined with a risk signal associated with at least one user requesting a transaction generated by risk engine computing device 140 to generate at least one relying party risk adjustment indicator, which will be referred to as a relying party risk adjustment indicator hereinafter. The relying party risk adjustment indicator may be a one-time use for a given transaction for which the relying party risk adjustment indicator is generated; it may also be saved and reused. The use or reuse of the indicator may depend on the use criteria or decision logic used by the relying party.

[0075] At least one one-time risk adjustment indicator may be stored in the identifier storage device 160 in any number of ways that may be specified for the storage device according to the data structure of the storage device. The storage device database may include, but is not limited to, a relational, blockchain or distributed ledger, object-oriented, hierarchical or graph database, or any combination thereof. Consider the following illustrative non-limiting example, in which the relying party risk adjustment indicator may be represented as a relational element in a relational database with a pointer associated with a user, such as a block on a blockchain; or in a graph structure, in which the one-time transaction identifier and the risk signal may be added or concatenated data elements or both, which may include at least one new data element that may subsequently be hashed or otherwise encrypted. hereinafter in Figures 5A-5E Non-limiting exemplary representations, embodiments, or aspects of these types of database structures are further described in the discussion of .

[0076] If the one-time transaction identifier and the risk level signal symbol are both digital, their combination may also be expressed as the result of at least one mathematical equation, comprising at least one of: multiplication, division, addition or a non-linear expression of two numbers, which may or may not subsequently be normalized relative to some predefined ratio, may be hashed or otherwise encrypted, or any combination thereof.

[0077] However, it should be noted that the relying party risk adjustment indicator may be stored in the identifier storage device 160, and the user may only receive the one-time transaction identifier without any risk indication associated therewith. That is, the risk adjustment associated with the one-time transaction identifier combined with at least one associated risk signaling symbol may generate a relying party risk adjustment indicator, which may only be transmitted to or known by the relying party from which the user may request an account or with which the user may conduct a transaction. The user may not receive or be informed of the risk level determination or how the risk level determination is represented to or to the relying party.

[0078] The computing and storage devices described hereinabove may be owned, managed, and maintained by one party or by an independent service provider, or on behalf of some combination thereof. If a service provider is involved, the service provider may transmit one or more results of its processing to the relying party. The relying party may use the indicated risk level to proceed with the account or transaction by requiring the user to respond to and correctly answer challenge questions using the user device 110 before agreeing to proceed with the account or transaction, or refusing to release the account or conduct the transaction. Challenge questions may include, but are not limited to, asking for answers to passwords or personal questions, or any combination thereof, where the passwords, answers, or any combination thereof may have been submitted by the user and stored in the Figure 1 In at least one of the storage devices of the system 100 shown.

[0079] According to some non-limiting expressions, embodiments or aspects, Figure 2 The process required to create a relying party risk adjustment indicator is shown. A user 210 can provide at least one identity certificate 220 to use Figure 1 A user device 110 is shown requesting an account or initiating a transaction.

[0080] The identity proof 220 may be an input to at least one risk assessment process 230. The risk assessment process may be performed by Figure 1 The at least one computing device shown is hosted and can be programmed or configured with software and algorithms to request and receive a user's stored identification 280 and user transaction and device history information 285 (hereinafter collectively referred to as transaction history 285). The stored identification 280 and transaction history 285 can be stored in Figure 1In at least one storage device shown.

[0081] Based on the received identity proof 220, the risk assessment process 230 may determine whether the identity proof 220 provided by the user at least partially matches at least one stored identity proof 280. If the identity proof 220 does not at least partially match, the risk assessment process 230 may be programmed or configured to deny the user's request to access the account or initiate a transaction. However, if based on the identity proof 220 at least partially matching at least one identity proof 280, the risk assessment process 230 may be further programmed or configured to require a challenge decision 235 to be made regarding whether the user 210 needs to respond to the challenge request. If the decision 235 made does not require a challenge response, the risk assessment process 230 may include software or an algorithm programmed or configured to instruct at least one one-time transaction identifier generation process 270 to generate at least one one-time transaction identifier. The one-time transaction identifier generation process 270 may be hosted on Figure 1 The at least one computing device shown is configured to generate a one-time transaction identifier in response to content transmitted to the user 210.

[0082] The result of the challenge decision 235 may be that a challenge request will be made, in response to which the risk assessment process 230 may be programmed or configured to generate and transmit to the user device 110 at least one challenge question 237 to which the user 210 must respond. The user 210 may submit a challenge response 240 using the user device 110, which may be transmitted to a challenge response process 250. The challenge response process 250 may include software and algorithms hosted on at least one computing device of the system 100. The challenge response process may involve accessing at least one storage device of the system 100, searching for at least one user stored challenge response, and in response to finding at least one user stored challenge response, attempting to at least partially match the at least one stored challenge response with at least one response 240 provided by the user 210 in response to receiving the at least one challenge question 237. The result of the challenge response process 250 may be used as a basis for at least one acceptance decision 260. In response to the challenge response process 250 obtaining at least a partial match, the acceptance decision 260 can instruct the one-time transaction identifier generation process 270 to generate at least one one-time transaction identifier, and in response, at least one one-time transaction identifier can be generated and transmitted to the user device 110. If the challenge response 240 does not obtain at least a partial match, the acceptance decision 260 can instruct the risk assessment process 230 to deny the account request or transaction, and in response, a denial response can be transmitted to the user device 110.

[0083] In addition to determining whether user 210 is at least partially matched and providing its output to challenge decision risk decision 235, risk assessment process 230 can output at least one risk signal symbol of the degree of risk represented by user 210 to at least one party if the party posts an account or conducts a transaction with user 210. The risk signal symbol can be based on the user's transaction history record 285 that can be stored in at least one storage device of system 100.

[0084] The risk assessment process 230 may execute instructions to search for user transaction history information 285 in a storage device of at least one system 100. If found, the transaction history information 285 may be transmitted to the risk assessment process 230, and in response, the transaction history information may be used to generate at least one risk signal. As described above, the risk signal may be a score (e.g., from 1 to 100), a score expressed as a percentage, a qualifier (e.g., high, medium, low), a sign (e.g., a plus sign for acceptable risk, a minus sign for unacceptable risk, or an equal sign for uncertain or medium risk), and possible combinations thereof.

[0085] In addition to sending the one-time transaction identifier to the user 210, the one-time transaction identifier generation process 270 may also combine the generated risk signal symbol with the generated one-time transaction identifier to generate a relying party risk adjustment indicator. If the risk signal symbol includes a symbol or a qualifier or a mathematically determined score, the combination may include adding the risk signal symbol to the one-time transaction identifier or concatenating it with it, or any combination thereof. If the one-time transaction identifier and the risk signal symbol are both digital, the combination may include performing a mathematical operation using both. Examples may include, but are not limited to, raising one to the power of the other, using one as a numerator and the other as a denominator, using one as a multiplicand and the other as a multiplier, combining them in a defined non-linear equation, or any combination thereof. Once determined, the generated relying party risk adjustment indicator may be compared to a standardized score (if digital), interpreted according to decision logic in the software and algorithms used by the processor when evaluating or authorizing the transaction, or any combination thereof.

[0086] Once determined, the relying party risk adjustment indicator may be hashed or otherwise encrypted and transmitted to the relying party of the transaction, which in response may use the relying party risk adjustment indicator to authorize or deny an account or transaction request based on decision logic, criteria, or any combination thereof that may be used by programming or configuration of at least one computer device of the transaction party.

[0087] The hashed or otherwise encrypted risk adjustment indicator may also be transmitted to and stored in a storage device of system 100. As described above, the storage space for the relying party risk adjustment indicator may be consistent with the data structure of the storage device. The storage device database may include, but is not limited to, a relational, blockchain or distributed ledger, object-oriented, hierarchical or graph database, or any combination thereof. As mentioned above, below in Figures 5A-5E Non-limiting expressions, embodiments, or aspects of these types of database structures are further described in the discussion of .

[0088] As mentioned above, the user may only receive a one-time transaction identifier without any risk indication associated therewith. That is, the risk adjustment associated with the one-time transaction identifier, which in combination includes the relying party risk adjustment indicator, may only be transmitted to and known by the relying party with whom the transaction requested by the user may be conducted. The user may not receive or be informed of the risk level determination or how the risk level determination is made and / or represented to the relying party.

[0089] According to some non-limiting expressions, embodiments or aspects, Figure 3100. Steps that may be taken by at least one user when requesting an account or transaction using at least one device 110 that is programmed or configured to generate or transmit a request to at least one processor system 100. At step 310, at least one user may request that an account be created as one but not only one instance. In response to the request, at least one relying party with which a transaction may be conducted may generate and transmit a request from the transaction processor 120 for at least one user's identity from the user. The request may be received by the at least one user via the at least one user's device 110. The at least one user may transmit at step 320 at least one identity (if the user has at least one identity); or by communicating with at least one identity provider, in response to which the provider may transmit it to the processor system 100, to at least one user device 110, in response to which the at least one user may transmit the identity to the processor system 100, or any combination thereof. If the transmitted at least one identity is at least partially matched by the processor system 100, then using the user device 110, the at least one user may generate and transmit a request to the processor system 100 to generate at least one one-time transaction identifier at step 350. The processor system 100 may be programmed or configured to receive the request, in response to which the processor system may determine at least one one-time transaction identifier and transmit it to the at least one user's device 110, which may be programmed or configured to receive the at least one one-time transaction identifier at step 360. If the relying party does not at least partially match the user's identity proof, the processor system 100 may be programmed or configured to transmit the identity proof to the at least one party, in response to which the party may choose to communicate with the processor system 100 and request it to generate at least one challenge question and transmit it to the at least one user, in response to which the processor system may be programmed and configured to generate at least one challenge question and transmit it to the at least one user, whose at least one user device 110 may be programmed or configured to receive the at least one challenge question at step 330. If the challenge question is received, the at least one user may enter at least one challenge response using the at least one user device 110 and transmit it to the processor system 100 at step 340, in response to which the processor system 100 may be programmed or configured to transmit the at least one challenge response 340 to the at least one party. If the at least one party approves the at least one challenge response 340 and transmits it to the processor system 100, the processor system 100 may be programmed or configured to transmit the at least one party's approval to at least one user device 110 of at least one user.In response to receiving the approval of the at least one party, at least one user may request at least one one-time identifier using at least one user device 110 at step 350, the at least one user device being programmed or configured to generate the request and transmit the request to the processor system 100. In response to receiving at least one request for at least one one-time transaction identifier, the programming or configuration of the processor system 100 may generate at least one one-time transaction identifier and transmit it to the at least one user. The user may receive the one-time transaction identifier at at least one user device 110 at step 360. Once the user receives the one-time transaction identifier at step 360, the user may input the at least one one-time transaction identifier into at least one user device 110 at step 370 and transmit the one-time transaction identifier to the processor system 100 using the programming and configuration of the user device, in response, the processor system 100 may be programmed or configured to provide the one-time transaction identifier to the at least one party to proceed with any further steps required for the transaction.

[0090] According to some non-limiting expressions, embodiments or aspects, Figure 4 4. Steps that may be taken when at least one processor system 100 receives a transaction request from at least one user are represented. At step 410, at least one processor system may be programmed or configured to receive at least one transaction request from at least one user. In response to receiving the at least one request, processor system 100 may be programmed or configured to generate a request for at least one identity verification from at least one user and transmit the request on at least one user device 110 at step 420. If processor system 100 is not at least one relying party, but is operating on behalf of at least one relying party, at least one processor system 100 may also be programmed or configured to transmit the request to at least one relying party of the transaction, which party may transmit the request back to at least one processor 100 requesting at least one identity verification of at least one user in response to receiving the request, which processor may generate at least one request and transmit it to the user on at least one user device 110 in response.

[0091] If the at least one processing system 100 is programmed or configured to receive and does receive at least one identification of at least one user, then the processor system 100 may be programmed or configured to process the received at least one identification and determine whether it at least partially matches the at least one identification of the user stored in the processor system 100 at step 425. If the at least one processor system 100 determines that there is at least a partial match, then it may be programmed or configured to accept the identification and, in response, may be programmed or configured to generate at least one one-time transaction identifier at step 450 and then transmit at least one one-time transaction identifier to the user at step 460, who may receive the one-time transaction identifier at at least one user device 110.

[0092] If the at least one processor system 100 does not match the at least one user's identification with the at least one user's identification stored in the processor system 100, the at least one processor system 100 may be programmed or configured to optionally generate at least one challenge and transmit the challenge to the user at step 430. The at least one processor system 100 may also be programmed or configured to transmit a determination that the received at least one identification does not at least partially match the stored identification of the at least one user to the relying party at step 430, and in response, the at least one party may communicate with the at least one processor system 100 in its determination and instruct it to generate at least one challenge request and transmit the challenge request to the at least one user on the at least one user device 110.

[0093] After receiving the at least one challenge, at least one user may input at least one challenge response into at least one user device 110 , which may be programmed or configured to communicate the challenge response to at least one processor system 100 .

[0094] At least one processor system 100 may be programmed or configured to receive at least one challenge response at step 440 to determine whether it at least partially matches at least one challenge response stored in at least one storage device of the processor system. If at least a partial match is determined to exist, at step 440, at least one processor system 100 may be programmed or configured to generate at least one one-time transaction identifier and transmit it to at least one user on at least one user device 110 at steps 450 and 460, respectively.

[0095] Each time at least one user receives at least one one-time transaction identifier, the user may input it into at least one user device 110, wherein the at least one user device 110 may be programmed to transmit the one-time transaction identifier to at least one processor system 100. The processor system 100 may be programmed or configured to receive at least one one-time transaction identifier at step 470, wherein the one-time transaction identifier may be used to determine whether a transaction request of at least one user may be approved or denied. Such a determination may be made using the output of steps 480 and 490.

[0096] At steps 480 and 490, processor system 100 may be programmed or configured to respectively determine and transmit at least one relying party risk adjustment indicator to at least one relying party of the transaction, and in further response, at least one relying party of the transaction may determine to proceed with at least one transaction or to deny at least one transaction.

[0097] It should be noted that, unless otherwise indicated, at least one processor system 100 may be a relying party of a transaction, or a system of at least one other relying party that is accessed by and in communication with at least one party of a transaction.

[0098] According to some non-limiting expressions, embodiments or aspects, Figures 5A-5E A data structure is depicted that may be used by a relying party to store at least one relying party risk adjustment indicator of a user and associated information. Figures 5A-5E The records depicted in can store user information from at least one identity certificate provided by user 210 to a party, and a transaction history record based on which a risk adjustment is made for at least one relying party risk adjustment indicator that a relying party can accept, reject, initiate, conduct (or any combination thereof) a transaction with user 210. For example, if a transaction such as Figure 5A The blockchain structure shown in the figure can store at least one relying party risk adjustment indicator as at least one block of the blockchain, where the user's identity, transaction history, transaction information (which may include but is not limited to transaction type, amount, time and location) and transaction parties are also represented in the block of the blockchain. Figure 5B As shown in the relationship element, at least one relying party risk adjustment indicator can be stored together with an indicator pointing to the user, at least one identity proof of the user, a transaction history, and a transaction party, each of which can be stored separately in the same or different storage devices of the system 100. If stored in a hierarchical database, an object database, or a graph database, a transaction can include at least one relying party risk adjustment indicator of the user, the identity proof, the transaction history, and data items that the transaction party can be aggregated or linked to, such as Figure 5C , 5D and 5E, respectively. Note that Figures 5A-5E The exemplary databases shown may be used in various combinations and as centralized or distributed database structures within one or more system storage devices, and they are not meant to exclude the use of other structures that may be available, become available, developed or enhanced in the future, or any combination thereof.

[0099] According to some non-limiting expressions, embodiments or aspects, Figure 6 Certain interactions that at least one user may perform using at least one user device, in this case a mobile phone, with at least one processor or at least one relying party in communication with at least one processor, or any combination thereof, are shown. On at least one screen 610 of the at least one user device, the user may enter at least one request to conduct or carry out a transaction and request at least one one-time transaction identifier. The at least one processor or party may then send a message to the at least one user requesting at least one identity, which may be displayed on at least one screen 620. If at least one identity is available on the at least one user's mobile device, the at least one user may send a message authorizing the sending of the specified at least one identity by entering on at least one screen 630, for example, by making a check mark in a checkbox on screen 630 to specify at least one identity or at least one user approves the assertion-based identity to be sent to the at least one processor or party as an assertion profile, and by leaving an unchecked checkbox on screen 630 for at least one identity that may not be authorized to be sent to the at least one processor or party. If the at least one identity is not stored on the at least one user's phone, but is stored on the processor or relying party, the at least one user may use at least one screen 630 to authorize which information may be authorized by the party or transmitted by the processor to the party, or any combination thereof.

[0100] If at least one processor or party can store the user and the processor or party in at least one of its storage devices (e.g. Figure 160) of the processor system storage device 130 or 160 of the processor shown, the at least one processor or party may send a one-time transaction identifier (in this case a code in a message sent to and displayed on at least one screen 640) to the user, and in response, the at least one user may enter this code into a text field on at least one screen 650 and transmit it back to the processor or party to confirm their identity. Upon receiving the at least one one-time transaction identifier from the at least one user, the processor or party may approve or deny the at least one transaction based on at least one relying party risk adjustment indicator, which may be generated for, transmitted to, and used by a relying party (not shown), but not sent to the at least one user.

[0101] Figure 7 is a non-limiting illustration showing that at least one user may receive a request from at least one identity service (in this case, a bank) on at least one user device screen 710 to approve the user's transmission of at least one identity proof to at least one relying party (in this case, a hospital). The at least one identity service may then send at least one instruction presented on at least one user device screen 715, wherein the instruction is for the user to request at least one one-time transaction identifier. In response to the at least one user following the instruction presented on screen 715, the identity server may transmit the at least one one-time transaction identifier as a code to the user device, which displays the one-time transaction identifier on at least one screen 720. If the at least one user enters the at least one one-time transaction identifier on at least one screen 730, the user's device may transmit it to the at least one identity service for display on at least one user device screen 740, which may indicate that the service is acquiring information that may need to be authorized and transmitted to at least one relying party.

[0102] If the required risk information is available, the at least one identity service can transmit specific identity proof information that can be authorized and transmitted to the at least one relying party. The available information can be presented on at least one user device, such as at least one screen 750. The at least one transmission of the available proof of concept information can be transmitted to the at least one user's device in various ways, including but not limited to transmitting a push notification to the user's mobile application.

[0103] As an example, at least one user device screen 750 may display at least one user identification information available for transmission to at least one requesting relying party, and for which at least one user may or may not confirm permission for transmission to the relying party. Options may allow the user to select which information may be shared with at least one relying party, such as an address, bank number, or assertions related to such information, or any combination thereof. For example, screen 750 illustrates information that a user may authorize to be transmitted to a relying party, or information that may be used as the basis for an assertion profile to be transmitted to at least one relying party.

[0104] As shown in at least one screen 750, the user may place a check mark in a check box to indicate that he or she authorizes at least one identity service to transmit information to at least one relying party, and may uncheck the check box for information that the user does not authorize to be sent to a relying party.

[0105] In some non-limiting expressions, embodiments, or aspects, the user updates old information within the application before a response can be transmitted to the relying party. In some non-limiting expressions, embodiments, or aspects, the required data can be specific to the type of account required or the transaction to be conducted. In this sense, the required information can be considered dynamic.

[0106] In some non-limiting expressions, embodiments, or aspects, at least one identity service may communicate to at least one user the name of at least one relying party and at least one identity credential required to conduct or perform a transaction, and in response, the user may authorize which at least one identity credential may and may not be provided to at least one requesting party (not shown).

[0107] In some non-limiting expressions, embodiments, or aspects, at least one piece of identity information of a user that can be used as an aspect of a user's identity or can be used to enable an identity service or a relying party to use the user's identity information may include: the user's biometrics (which may include but are not limited to fingerprints, voice recognition, facial recognition, iris recognition, etc.), PIN, password, or any combination thereof.

[0108] In some non-limiting expressions, embodiments, or aspects, at least one user making at least one identity verification request to at least one identity service may have been previously vetted by at least one identity service, and in response, the identity service may provide at least one cryptographic token to at least one user to authenticate themselves when making at least one identity verification request. They may use these tokens to thwart attempts by fraudsters to defraud relying parties because the fraudsters may not have access to the tokens and may not be able to grant a one-time code to the identity service using at least one valid token.

[0109] and Figure 6 and Figure 7 The same applies, but it is worth noting that although some steps can be reordered, Figure 3 and Figure 4 The steps depicted in are still relevant. For example, you can swap Figure 3 Steps 320 and 350 in the example above may reflect that a user may request a one-time transaction identifier before providing the identity proof to or accessed by at least one processor system 100 or party, or any combination thereof. Similarly, if a code may be provided to at least one user before receiving or accessing the identity proof of at least one user, then Figure 4 Steps 450 , 460 , and 470 in the method may be performed after step 410 .

[0110] Although the disclosed subject matter has been described in detail for illustrative purposes based on what are currently considered to be the most practical and preferred embodiments or aspects, it should be understood that such details are only for that purpose and that the disclosed subject matter is not limited to the disclosed embodiments or aspects, but rather is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the presently disclosed subject matter contemplates that one or more features of any embodiment can be combined with one or more features of any other embodiment to the extent possible.

Claims

1. A computer-implemented method comprising: receiving, by a user device, a request from at least one identity service to approve transmission of at least one user identity credential to at least one relying party; prompting, by the user device, a user of the user device to request at least one one-time transaction identifier based on the request; requesting, by the user device, the at least one one-time transaction identifier from at least one identity server associated with the at least one identity service based on a first input by the user on the user device; receiving, by the user device from the identity server, the at least one one-time transaction identifier in response to the request for the at least one one-time transaction identifier; displaying, by the user device, the at least one one-time transaction identifier on a first user device screen; receiving, by the user device, a second input by the user on a second user device screen different from the first user device screen, the second input comprising at least one entered one-time transaction identifier; transmitting, by the user device, the at least one input one-time transaction identifier entered by the user on the second user device screen to the at least one identity service; as well as In response to receiving the at least one input one-time transaction identifier, a determination is made by the at least one relying party whether to approve or deny the transaction based at least in part on the at least one one-time transaction identifier and the at least one input one-time transaction identifier.

2. The computer-implemented method of claim 1 , further comprising: At least one risk signal associated with the user is generated.

3. The computer-implemented method of claim 2, further comprising: generating at least one relying party risk adjustment indicator based on the one-time transaction identifier and the at least one risk signal associated with the user; as well as The at least one relying party risk adjustment indicator is communicated to the at least one relying party.

4. The computer-implemented method of claim 3, wherein: A determination is made whether to approve or deny the transaction based in part on receipt by the relying party of the at least one relying party risk adjustment indicator.

5. The computer-implemented method of claim 1 , further comprising: The at least one user identification is displayed, wherein the at least one user identification is associated with a corresponding check box of a plurality of corresponding check boxes.

6. The computer-implemented method of claim 5, further comprising: receiving a third input from a user, the third input comprising a selection of at least one check box of the plurality of corresponding check boxes; as well as In response to receiving the third input, a check mark is displayed in at least one selected check box, wherein the check mark indicates that the user authorizes the at least one identity service to send the corresponding at least one user identity credential to the at least one relying party.

7. The computer-implemented method of claim 5, wherein: The at least one user identification is a biometric input, a personal identification number, a password, or any combination thereof.

8. A system comprising at least one processor of a user device, the at least one processor of the user device being programmed or configured to: receiving a request from at least one identity service to approve transmission of at least one user identity credential to at least one relying party; prompting a user of the user device to request at least one one-time transaction identifier based on the request; requesting the at least one one-time transaction identifier from at least one identity server associated with the at least one identity service based on a first input by the user on the user device; receiving, in response to the request for the at least one one-time transaction identifier, the at least one one-time transaction identifier from the identity server; displaying the at least one one-time transaction identifier on a screen of a first user device; receiving a second input from the user on a second user device screen different from the first user device screen, the second input comprising at least one entered one-time transaction identifier; transmitting the at least one input one-time transaction identifier entered by the user on the second user device screen to the at least one identity service; as well as The at least one processor of the at least one relying party is programmed or configured to: In response to receiving the at least one input one-time transaction identifier, a determination is made whether to approve or deny the transaction based at least in part on the at least one one-time transaction identifier and the at least one input one-time transaction identifier.

9. The system according to claim 8, wherein: The at least one processor of the user device is programmed or configured to: At least one risk signal associated with the user is generated.

10. The system according to claim 9, wherein: The at least one processor of the user device is programmed or configured to: generating at least one relying party risk adjustment indicator based on the one-time transaction identifier and the at least one risk signal associated with the user; as well as The at least one relying party risk adjustment indicator is communicated to the at least one relying party.

11. The system according to claim 10, wherein: When determining whether to approve or deny the transaction, the at least one processor of the relying party is programmed or configured to: The at least one relying party risk adjustment indicator is received, wherein a determination is made whether to approve or deny the transaction based in part on the at least one relying party risk adjustment indicator.

12. The system according to claim 8, wherein: The at least one processor of the user device is programmed or configured to: The at least one user identification is displayed, wherein the at least one user identification is associated with a corresponding check box in a plurality of corresponding check boxes.

13. The system according to claim 12, wherein: The at least one processor of the user device is programmed or configured to: receiving a third input from a user, the third input comprising a selection of at least one check box of the plurality of corresponding check boxes; and In response to receiving the third input, a check mark is displayed in at least one selected check box, wherein the check mark indicates that the user authorizes the at least one identity service to send the corresponding at least one user identity credential to the at least one relying party.

14. The system according to claim 12, wherein: The at least one user identification is a biometric input, a personal identification number, a password, or any combination thereof.

15. A computer program product comprising at least one non-transitory computer readable medium, the at least one non-transitory computer readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: receiving a request from at least one identity service to approve transmission of at least one user identity credential to at least one relying party; prompting a user of the user device to request at least one one-time transaction identifier based on the request; requesting the at least one one-time transaction identifier from at least one identity server associated with the at least one identity service based on a first input by the user on the user device; receiving, in response to the request for the at least one one-time transaction identifier, the at least one one-time transaction identifier from the identity server; displaying the at least one one-time transaction identifier on a screen of a first user device; receiving a second input from the user on a second user device screen different from the first user device screen, the second input comprising at least one entered one-time transaction identifier; transmitting the at least one input one-time transaction identifier entered by the user on the second user device screen to the at least one identity service; as well as In response to receiving the at least one input one-time transaction identifier, a determination is made whether to approve or deny the transaction based at least in part on the at least one one-time transaction identifier and the at least one input one-time transaction identifier.

16. The computer program product of claim 15, wherein: The one or more instructions cause the at least one processor to: At least one risk signal associated with the user is generated.

17. The computer program product of claim 16, wherein: The one or more instructions cause the at least one processor to: generating at least one relying party risk adjustment indicator based on the one-time transaction identifier and the at least one risk signal associated with the user; as well as The at least one relying party risk adjustment indicator is communicated to the at least one relying party.

18. The computer program product of claim 17, wherein: When determining whether to approve or deny the transaction, the one or more instructions further cause the at least one processor to: receive the at least one relying party risk adjustment indicator, wherein whether to approve or deny the transaction is determined based in part on the at least one relying party risk adjustment indicator.

19. The computer program product of claim 15, wherein: The one or more instructions cause the at least one processor to display the at least one user identification, wherein the at least one user identification is associated with a corresponding check box of a plurality of corresponding check boxes.

20. The computer program product of claim 19, wherein: The one or more instructions cause the at least one processor to: receiving a third input from a user, the third input comprising a selection of at least one check box of the plurality of corresponding check boxes; and In response to receiving the third input, displaying a check mark in at least one selected check box, wherein the check mark indicates that the user authorizes the at least one identity service to send a corresponding at least one user identity proof to the at least one relying party, wherein the at least one user identity proof is a biometric input, a personal identification number, a password, or any combination thereof.

Images