Dependent party risk adjustment indicator system and method

Abstract

A method is provided, comprising: a user device receiving a request from an identity service to approve the transmission of user identity credentials to a dependent party; a user of the user device requesting a one-time transaction identifier based on a request prompt; the user device requesting the one-time transaction identifier from the identity service based on first input from the user; in response to the request for the one-time transaction identifier, the user device receiving the one-time transaction identifier from the identity server and displaying the one-time transaction identifier on a first user device screen; the user entering the one-time transaction identifier on a second user device screen, and the user device transmitting the one-time transaction identifier to the identity service; and in response to receiving at least one input of the one-time transaction identifier, the dependent party determining whether to approve or reject the transaction.

Description

[0001] This application is a divisional application of Chinese patent application No. 202011215169.0, filed on November 4, 2020, entitled “Dependent Risk Adjustment Indicator System and Method”. Technical Field

[0002] This disclosure relates to systems and methods for using risk assessment identifiers to convey identity trust and identity information. Background Technology

[0003] The transaction system requires user verification. Verification can take the form of proof of identity provided by the user. Such proof can take the form of government identification credentials or documents (e.g., social security number, driver's license, or passport) that the user sends to the system.

[0004] Risk assessments are typically conducted to determine the potential risk a transaction user poses to one party in the transaction (hereinafter referred to as the "party" or "dependent party"). For example, a payment system can use a user's transaction history as input to a risk model to estimate the probability that the user is likely to complete or default on a payment. Similarly, banks and lending institutions can use a user's credit history as a factor in their decision to grant or deny new loans. Payment systems can use user device information to identify users who have visited the site over a period of time and to detect attempts to impersonate users. In such cases, the risk assessed is related to the transaction to be performed. It does not necessarily indicate the potential risk a user may pose to one or more types of transactions that may be conducted. Summary of the Invention

[0005] Therefore, and generally speaking, this 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 dependent party risk adjustment indicator (DPIA) that can be associated with the transmitted information by a dependent party risk adjustment indicator system. While a unique transaction identifier can be generated for each transaction that a user can use to initiate or conduct at least one transaction, the risk presented to the dependent party by the user may change as at least one transaction is conducted. The DPIA system can determine a dependent party risk adjustment indicator that can be used by the party issuing the requesting account or conducting at least one transaction to determine their transaction risk before issuing the account or conducting at least one transaction, and can be used by the dependent party to support a decision to approve or reject issuing an account or initiating or conducting a transaction with the user.

[0006] In some non-limiting expressions, embodiments, or aspects, the present invention provides a dependent party risk adjustment indicator generation system, comprising: at least one computing device programmed or configured to: receive from at least one user at least one account or transaction request for transacting with at least one dependent party; receive from at least one user at least one identity document; 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 accessed data; generate at least one dependent 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 dependent party risk adjustment indicator to at least one dependent party of the transaction.

[0007] In some non-limiting expressions, embodiments, or aspects, at least one computing device of the dependent 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 the following: 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 the following: 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 one identity document provided by at least one user that matches at least a portion of at least one stored identity document 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 an addition to or concatenated with a one-time transaction identifier, including at least one of the following: numbers, alphanumeric characters, symbols, minus signs, plus signs, equal signs, or any combination thereof.

[0009] In some non-limiting expressions, embodiments, or aspects, at least one one-time transaction identifier and at least one risk signal are both numbers, which are combined to determine or generate a dependent-party risk adjustment indicator using at least one of the following: multiplication, division, addition, nonlinear expression, result normalized relative to a predefined scale, hash number, encrypted number, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, data associated with at least one dependent-party risk adjustment indicator is stored in at least one of the following in the storage device of at least one computing device: on a blockchain, in a relational database, hierarchical database, object-oriented database, graph database, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one identity document includes at least one of the following: at least one device identifier, device fingerprint, telephone number, location identifier, home, business, mailing address, assertion profile, at least one known or unknown assertion about the user, government identifier, social security number, driver's license, authorized photograph, passport, government-issued identity card or tag, or any combination thereof.

[0010] In some non-limiting expressions, embodiments, or aspects, at least one risk signal includes the 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, disclosure event reference identifiers, disclosure event history records, 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 dependent party risk adjustment indicator generation system is programmed or configured to generate a dependent party risk adjustment indicator by combining at least one one-time transaction identifier and a risk signal associated with the risk posed to at least one dependent party by at least one user for at least one transaction to be performed.

[0011] In some non-limiting expressions, embodiments, or aspects, the present invention provides a method for generating a dependent party risk adjustment indicator, comprising: receiving, by at least one computing device, at least one account or transaction request from at least one user to conduct at least one transaction with at least one party; receiving, by at least one computing device, at least one identity document 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 dependent party risk adjustment indicator 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 dependent party risk adjustment indicator to at least one dependent party of the transaction.

[0012] In some non-limiting expressions, embodiments, or aspects, the method further includes: generating a dependent party risk adjustment indicator by at least one computing device by combining at least one one-time transaction identifier and at least one risk signal associated with at least one user for at least one transaction to be performed, thereby posing a risk to the dependent party. In some non-limiting expressions, embodiments, or aspects, the at least one risk signal is based on at least one of the following: 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 one identity document provided by at least one user matching at least a portion of at least one stored identity document 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 an addition to or concatenated with the one-time transaction identifier, including at least one of the following: numbers, alphanumeric characters, symbols, minus signs, plus signs, equal signs, or any combination thereof.

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

[0014] In some non-limiting expressions, embodiments, or aspects, at least one form of identification includes at least one of the following: at least one device identifier, device fingerprint, telephone number, location identifier, home, business, mailing address, assertion profile, at least one known or unknown assertion about the user, government identifier, social security number, driver's license, authorized photograph, passport, government-issued identity card or tag, or any combination thereof. In some non-limiting expressions, embodiments, or aspects, at least one risk signal includes the output of at least one risk model that calculates the risk of at least one transaction using at least one of the following: 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 dependent party risk adjustment indicator generation system, comprising: at least one computing device programmed or configured to: receive from at least one user at least one account or transaction request for transacting with at least one dependent party; receive from the at least one user at least one identity document; 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 accessed data; generate at least one dependent 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 dependent party risk adjustment indicator to the at least one dependent party of the transaction.

[0017] Clause 2: The Dependency Risk Adjustment Indicator Generation System according to Clause 1, wherein the at least one computing device of the Dependency 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: A dependent risk adjustment indicator generation system as described in Clause 1 or 2, wherein the at least one transaction includes at least one of the following: requesting an account, conducting a transaction, or any combination thereof.

[0019] Clause 4: A dependent risk adjustment indicator generation system according to any one of Clauses 1 to 3, wherein the at least one risk indicator is based on at least one of the following: 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 the at least one user, at least one identity document provided by the at least one user that matches at least a portion of at least one stored identity document previously received from the at least one user, or any combination thereof.

[0020] Clause 5: A dependent risk adjustment indicator generation system pursuant to any one of Clauses 1 to 4, wherein the at least one risk signal is transmitted as an addition to or in series with a one-time transaction identifier, or at least one of the following: numbers, alphanumeric characters, symbols, minus signs, plus signs, equal signs, or any combination thereof.

[0021] Clause 6: A dependent risk adjustment indicator generation 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 are both numbers, which are combined to determine or generate the dependent risk adjustment indicator using at least one of the following: multiplication, division, addition, nonlinear expression, result of normalization relative to a predefined scale, hash number, encrypted number, or any combination thereof.

[0022] Clause 7: A dependent party risk adjustment indicator generation system according to any one of Clauses 1 to 6, wherein data associated with the at least one dependent 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 dependent party risk adjustment indicator generation system pursuant to any one of Clauses 1 to 7, wherein the at least one identity document comprises at least one of the following: at least one device identifier, device fingerprint, telephone number, location identifier, home, business, mailing address, assertion profile, at least one known or unknown assertion about the user, government identifier, social security number, driver's license, authorized photograph, passport, government-issued identity card or tag, or any combination thereof.

[0024] Clause 9: A dependent party risk adjustment indicator generation system pursuant to any one of Clauses 1 to 8, wherein the at least one risk 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, data from at least one risk source, credit bureau, government agency or department, or any combination thereof.

[0025] Clause 10: A dependent party risk adjustment indicator generation system according to any one of Clauses 1 to 9, wherein the at least one computing device of the dependent party risk adjustment indicator generation system is programmed or configured to generate a dependent party risk adjustment indicator by combining the at least one one-time transaction identifier and a risk signal associated with the at least one user for the at least one transaction to be performed on the at least one dependent party.

[0026] Clause 11: A method for generating a dependent party risk adjustment indicator, comprising: receiving, by at least one computing device, at least one account or transaction request from at least one user for conducting at least one transaction with at least one party; receiving, by at least one computing device, at least one identity document 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 dependent party risk adjustment indicator 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, the at least one dependent party risk adjustment indicator to the at least one dependent party of the transaction.

[0027] Clause 12: The method for generating a dependent party risk adjustment indicator according to Clause 11 further includes: generating a dependent 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 to the dependent party caused by the at least one user for the at least one transaction to be performed.

[0028] Clause 13: The method for generating a dependent risk adjustment indicator according to Clause 11 or 12, wherein the at least one risk indicator is based on at least one of the following: 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 the at least one user, at least one identity document provided by the at least one user that matches at least a portion of at least one stored identity document previously received from the at least one user, or any combination thereof.

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

[0030] Clause 15: A method for generating a dependent-side 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 are both numbers, which are combined to determine or generate at least one dependent-side risk adjustment indicator using at least one of the following: multiplication, division, addition, nonlinear expression, result of normalization relative to a predefined scale, hash number, encrypted number, or any combination thereof.

[0031] Clause 16: A method for generating a dependent party risk adjustment indicator according to any one of Clauses 11 to 15, wherein data associated with the at least one dependent party risk adjustment indicator is stored in the 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: The method for generating a dependent risk adjustment indicator according to any one of Clauses 11 to 16, wherein the at least one identity document includes at least one of the following: at least one device identifier, device fingerprint, telephone number, location identifier, home, business, mailing address, assertion profile, at least one known or unknown assertion about the user, government identifier, social security number, driver's license, authorized photograph, passport, government-issued identity card or tag, or any combination thereof.

[0033] Clause 18: A method for generating a dependent party risk adjustment indicator according to any one of Clauses 11 to 17, wherein the at least one risk 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, 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 subject matter, as well as the operational methods and functions of the associated structural elements and combinations of parts, and the economics of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein like reference numerals denote corresponding parts in the figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be a definition of limitation on the disclosed subject matter. Unless the context clearly specifies otherwise, the singular forms “a” and “described” as used in this specification and claims include plural indicators. Attached Figure Description

[0035] The diagrams incorporated herein illustrate one or more non-limiting expressions, embodiments, or aspects of a dependent-party risk adjustment indicator system apparatus, system, and method, which help to explain different aspects of one or more expressions of the dependent-party risk adjustment indicator system apparatus, system, and method. Therefore, the descriptions and diagrams are not to be construed as limiting any aspect of any expression, embodiment, or aspect of the apparatus, system, and method of a one-time risk adjustment identity system. In the figures:

[0036] Figure 1These are non-limiting expressions, embodiments, or aspects of system elements based on the principles of this disclosure.

[0037] Figure 2 These are non-limiting expressions, embodiments, or aspects of processing based on the principles of this disclosure.

[0038] Figure 3 The process steps, embodiments, or aspects are expressed in accordance with the principles of this disclosure.

[0039] Figure 4 The process steps, embodiments, or aspects are expressed in accordance with the principles of this disclosure.

[0040] Figures 5A-5E These are non-limiting expressions, embodiments, or aspects of database structures based on the principles of this disclosure.

[0041] Figure 6 These are non-limiting expressions, embodiments, or aspects of user interactions based on the principles of this disclosure.

[0042] Figure 7 These are non-limiting expressions, embodiments, or aspects of user interfaces based on the principles of this disclosure. Detailed Implementation

[0043] For descriptive purposes, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and their derivatives are to be used in relation to the expressions of this disclosure as they are oriented in the accompanying drawings. However, it should be understood that, unless expressly stated to the contrary, the expressions, embodiments, or aspects of this disclosure may take various alternative variations, computing device and storage device configurations, within or in different ways and sequences of steps. It should also be understood that the device, computing device, and storage device configurations and processes shown in the accompanying drawings and described in the following description are merely exemplary expressions, embodiments, or aspects of this disclosure. Therefore, specific dimensions, configurations, and other physical characteristics relating to the expressions, embodiments, or aspects disclosed herein should not be considered limiting.

[0044] The terms "aspects," "components," "elements," "elements," "structures," "actions," "steps," "functions," and "instructions" used herein should not be construed as critical or essential unless explicitly stated otherwise. Furthermore, as used herein, the article "a" is intended to include one or more items and is interchangeable with "one or more" and "at least one." Additionally, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and is interchangeable with "one or more" or "at least one." Where only one item is desired, the term "a" or similar language is used. Furthermore, as used herein, the terms "having" and similar expressions are intended to be open-ended terms. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on."

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

[0046] As used herein, the term “identifier” refers to a unique identifier associated with an individual that can be verified to confirm the individual during identity checks.

[0047] As used herein, the term “transaction” refers to an interaction between a user and a dependent party, where such interaction involves making payments, providing access to restricted events or areas, generating legally binding contracts or agreements, or establishing any other type of arrangement, wherein the party wishes to understand the risks associated with conducting a transaction that requires a user’s trust 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, is immutable, and can always be used.

[0049] As used herein, the term "assertion" refers to a statement of fact about a user that is true / false or / not true, or a combination thereof. For example, an assertion may indicate that a 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," "yes," "false," or "no," or words with such meanings, which may be combined when there is more than one assertion, or may include assertion files related to a user's request or conduct of a transaction, or any combination thereof.

[0050] As used in this article, the term "assertive profile" refers to a user's digital representation or profile consisting of information about the user and user activities, without publicly available information that can uniquely identify a particular user.

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

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

[0053] As used herein, the term "processor" refers to an entity capable of issuing a one-time risk-adjusted identifier. Examples may include at least one of the following: a publisher, 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 an independent party unrelated to the specific transaction in progress, including, but not limited to, third-party processors or parties whose business or services include creating one-time verified risk-adjusted identifiers. The latter may include, but is not limited to, government agencies, private or public for-profit or non-profit companies.

[0054] As used herein, the term "identity service" refers to an entity capable of verifying or providing identity information of an individual or object. Examples may include, but are not limited to, banks, employers, government agencies or departments (which may include, but are not limited to, motor vehicle departments, tax services, or registration services), or insurance providers.

[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 contain the same pattern based on a predetermined threshold. If the result is equal to or exceeds the threshold, the pattern is determined to be a “match” or a “partial match.” Software for matching or partial matching may include, but is not limited to, speech recognition, optical character matching, alphanumeric pattern matching programs, or any combination thereof.

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

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

[0058] According to some non-limiting expressions, embodiments, or aspects, Figure 1 A system 100 is depicted for at least one processor used to generate and transmit at least one one-time transaction identifier associated with a user. Example component system 100 may be at least partially implemented in 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. System 100 only illustrates 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 among components may vary depending on the arrangement.

[0059] When stored in storage accessible to a computer device, software instructions make the computing device a specialized computing device customized to perform the operations specified in the software instructions. The terms "software," "software instructions," "computer program," "computer-executable instructions," and "computer device-executable instructions" are broadly interpreted to encompass any machine-readable information, whether human-readable or not, used to instruct a computing device to perform specific operations, and include, but are not limited to, application software, desktop computer applications, scripts, binary numbers, operating systems, device drivers, bootloaders, shells, utilities, system software, JavaScript, web pages, web applications, plug-ins, embedded software, microcode, compilers, debuggers, interpreters, virtual machines, linkers, and text editors.

[0060] While the functionality and operation of one or more example embodiments may be fully implemented using software instructions, in some non-limiting expressions, embodiments, or aspects, hardwired computing devices or programmable circuit systems (e.g., ASICs, FPGAs, etc.) may be used in place of or in combination with software instructions to perform functions.

[0061] Users 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 dependent party, register at least one of their identity information, 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, perform (or any combination thereof) at least one transaction.

[0062] User device 110 may include, but is not limited to, mobile phones, tablets, laptops, desktop computers, wearable devices, or any other device owned by the user capable of communicating with system 100. The user may use an input device or interface associated with user device 110 to register their identity information. The input device or interface may include, but is not limited to, a physical or numeric keypad, a touch panel, a voice input or recognition system, a cursor control device, or a functionally equivalent input device or interface, wherein 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, one-time passwords, credential-based authentication, content-based authentication, multi-factor authentication, two-factor authentication, challenge-response authentication, encryption processes, or any combination thereof.

[0063] System 100 may include one or more computing devices, one or more storage devices, and one or more components for communication within and between said 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 programs required by 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-generation, next-generation, or similar networks), based on the IEEE 802.11x standard. Local area network (LAN), based on Special Interest Criterion (SIT) Wide area network (WAN) based on the IEEE 802.16 standard set (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 prior 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 random access memory (RAM) or other dynamic storage device for storing information and software instructions executed by a computing device; read-only memory (ROM) or other static storage device for storing static information and software instructions for a computing device; or a mass storage device for storing information and software instructions on a fixed or removable medium, wherein the 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] Storage devices may use any one or more storage media, including but not limited to any non-transient media that stores data, software instructions, or both and enables a computing device to operate in a particular manner. Such storage media may include non-volatile media, volatile media, or both. Non-volatile media may include, but are not limited to, non-volatile random access memory (NVRAM), flash memory, optical discs, magnetic disks, or solid-state drives. Volatile media may include, but are not limited to, dynamic memory that acts as main memory. Common forms of storage media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAM, flash memory, and / or any other memory chips or cassettes.

[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, the one or more example embodiments are not necessarily limited to any particular computing environment or computing device configuration. Rather, the one or more example embodiments can be implemented in any type of system architecture or processing environment that a person skilled in the art would understand, based on this disclosure, to be capable of supporting the features and functionality of the one or more example embodiments presented herein.

[0067] Representative identification may include, but is not limited to, a user’s photograph, an image of or information derived from a government-issued identity document or document (including but not limited to Social Security number, driver’s license, passport or tax identification number), biometrics, a secret code known only between the user and the party (including but not limited to passwords, PINs or ciphers), 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] 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 verification storage device 130, at least one user transaction storage device 135, and at least one identifier storage device 160. It should be understood that, depending on the design of system 100, the computing devices may be one or more different devices or the same devices, and the storage devices may be one or more different devices or the same devices.

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

[0070] Transaction storage device 135 stores a user's transaction history. The user's transaction history may include a series of at least one historical transaction record, at least one possible index associated with the user's history, including numbers, user device information, event logs, measures 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 the 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 provides information about the nature and level of risk associated with the transaction, a breach event reference ID that identifies a specific breach event related to the transaction, or both.

[0071] A risk score can indicate the degree of risk a user poses to a party due to a requested account or because the user wants to conduct and / or transact with that party. The degree of risk can be represented by the results of at least one risk model. Results can come from at least one risk model associated with the user's payment, previously reached agreements, valid or invalid assertions, or any combination thereof. The risk models used can include, but are not limited to, models based on Bayesian statistics or statistical regression, decision trees, random forests, regularized logistic regression, machine learning-based artificial intelligence models, or any combination thereof, which can be used to determine fraud, credit card, or other financial, transaction, or contractual risks. Other risk-related information that can be used alone or incorporated into an appropriate model can include, but is not limited to, at least one breach event reference identifier, data specifying a breach event, or data from several other risk sources, including, but not limited to, credit bureaus, government agencies, financial institutions, or any combination thereof, which the party may have access to.

[0072] The risk engine computing device 140 can use a user's transaction history and at least one risk score, or risk condition code, or a disclosure event reference ID or device information associated with the user, or any combination thereof, in combination with at least one decision rule, or any combination thereof, to determine and output the degree of risk that a user may pose to a party if that party accepts the user's transaction request. The degree of risk can be represented by risk semaphores, which may include numbers (e.g., from 1 to 100), scores expressed as percentages, qualifiers (e.g., high, medium, low), symbols (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 combinations thereof.

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

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

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

[0076] If both the one-time transaction identifier and the risk level signal are numerical, their combination can also be represented as the result of at least one mathematical equation, which includes at least one of the following: a multiplication, division, addition, or nonlinear expression of two numbers, which may or may not be normalized relative to some predefined scale, may be hashed or otherwise encrypted, or any combination thereof.

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

[0078] The previously described computing and storage devices 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 dependent party. The dependent party may proceed with an account or transaction using the indicated level of risk by: requiring the user to respond to and correctly answer interrogation questions using user device 110 before agreeing to continue the account or transaction, or refusing to publish the account or conduct the transaction. Interrogation questions may include, but are not limited to, answers to passwords or personal questions, or any combination thereof, wherein the password, answer, or any combination thereof may have been submitted by the user and stored... Figure 1 At least one of the storage devices in the system 100 shown.

[0079] According to some non-limiting expressions, embodiments, or aspects, Figure 2 This illustrates the process required to create a dependency risk adjustment indicator. User 210 can provide at least one identity document 220 to use... Figure 1 The user device 110 shown requests an account or initiates transaction processing.

[0080] Identity verification 220 can be input to at least one risk assessment process 230. The risk assessment process can be conducted by... Figure 1 At least one computing device is shown as hosting the event, which can be programmed or configured by software and algorithms to request and receive user-stored identity verification 280 and user transaction and device history information 285 (hereinafter collectively referred to as transaction history 285). The stored identity verification 280 and transaction history 285 can be stored in... Figure 1In at least one storage device shown.

[0081] Based on the received identity document 220, the risk assessment process 230 can determine whether the identity document 220 provided by the user at least partially matches at least one stored identity document 280. If the identity document 220 does not at least partially match, the risk assessment process 230 can be programmed or configured to reject the user's request for an account or to initiate a transaction. However, if the identity document 220 at least partially matches at least one identity document 280, the risk assessment process 230 can be further programmed or configured to require a challenge decision 235 regarding whether the user 210 needs to respond to a challenge request. If the decision 235 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 includes software and an algorithm for generating a one-time transaction identifier in response to content transmitted to user 210.

[0082] The result of the inquiry decision 235 may be to make an inquiry request. In response, the risk assessment process 230 may be programmed or configured to generate at least one inquiry question 237 and transmit it to the user device 110, which the user 210 must respond to. The user 210 may submit an inquiry response 240 using the user device 110, which may be transmitted to an inquiry response processing 250. The inquiry response processing 250 may include software and algorithms hosted on a computing device of at least one system 100. The inquiry response processing may involve accessing at least one storage device of the system 100, searching for at least one user-stored inquiry response, and, in response to finding at least one user-stored inquiry response, attempting to at least partially match the at least one stored inquiry response with at least one response 240 provided by the user 210 in response to receiving at least one inquiry question 237. The result of the inquiry response processing 250 may be used as the basis for at least one acceptance decision 260. In response to a challenge response processing 250 that receives at least a partial match, acceptance decision 260 may instruct a 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 may be generated and transmitted to user device 110. If the challenge response 240 does not receive at least a partial match, acceptance decision 260 may instruct a risk assessment process 230 to reject the account request or transaction, and in response, a rejection response may be transmitted to user device 110.

[0083] In addition to determining whether user 210 is at least partially matched and providing its output to the challenge decision risk decision 235, if at least one party publishes an account or transacts with user 210, the risk assessment process 230 may output at least one risk signal to said party indicating the level of risk represented by user 210. The risk signal may be based on user transaction history 285 that can be stored in at least one storage device of system 100.

[0084] The risk assessment process 230 can execute instructions to search for user transaction history information 285 in the storage device of at least one system 100. If found, the transaction history information 285 can be transmitted to the risk assessment process 230, and in response, the transaction history information can be used to generate at least one risk signal. As described above, the risk signal can be a rating (e.g., from 1 to 100), a rating 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 possible combinations thereof.

[0085] In addition to sending a one-time transaction identifier to user 210, the one-time transaction identifier generation process 270 may also combine a generated risk signal with the generated one-time transaction identifier to generate a dependent-side risk adjustment indicator. If the risk signal includes a symbol or qualifier or a mathematically determined score, the combination may include adding the risk signal to or concatenating it with the one-time transaction identifier, or any combination thereof. If both the one-time transaction identifier and the risk signal are numeric, the combination may include performing mathematical operations using both. Examples may include, but are not limited to, using one as a 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 nonlinear equation, or any combination thereof. Once determined, the resulting dependent-side risk adjustment indicator may be compared to a standardized score (if numeric), interpreted according to the 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 dependent party risk adjustment indicator can be hashed or otherwise encrypted and transmitted to the dependent party of the transaction. In response, the dependent party can use the dependent party risk adjustment indicator to authorize or deny account or transaction requests based on decision logic, criteria, or any combination thereof that can be used by programming or configuration of at least one of the transaction party's computer devices.

[0087] Hashable or otherwise encrypted risk adjustment indicators can also be transmitted to and stored in the storage device of system 100. As described above, the storage space for the dependent risk adjustment indicators can be consistent with the data structure of the storage device. The storage device database can be, but is not limited to, relational, blockchain or distributed ledger, object-oriented, hierarchical or graph databases, or any combination thereof. As mentioned above, the following... Figures 5A-5E The discussion further describes non-restrictive expressions, embodiments, or aspects of these types of database structures.

[0088] As mentioned above, users may only receive a one-time transaction identifier without any associated risk indication. That is, the risk adjustment associated with the one-time transaction identifier, which includes a dependent party risk adjustment indicator, can only be transmitted to and known to the dependent party with whom the user's requested transaction may take place. Users may not receive or be informed of the risk level determination or how said risk level determination is and / or represented to the dependent party.

[0089] According to some non-limiting expressions, embodiments, or aspects, Figure 3This describes the steps that at least one user can take when requesting an account or transaction using at least one device 110, which is programmed or configured to generate a request or transmit the request to at least one processor system 100. In step 310, at least one user can request the creation of an account as one, but not the only, instance. In response to the request, at least one dependent party with whom a transaction can take place can generate and transmit a request from transaction processor 120 for authentication of at least one user from the user. The request can be received by at least one user through at least one user's device 110. At least one user can transmit at least one authentication in step 320 (if the user has at least one authentication); or, in response to an authentication provider, the provider can transmit it to processor system 100, to at least one user device 110, or, in response, at least one user can transmit the authentication to processor system 100, or any combination thereof. If the transmitted at least one authentication is at least partially matched by processor system 100, then using user device 110, at least one user can generate a request and transmit it to processor system 100, requesting it to generate at least one one-time transaction identifier in step 350. Processor system 100 may be programmed or configured to receive a request, and in response, the processor system may determine at least one one-time transaction identifier and transmit it to device 110 of at least one user, which may be programmed or configured to receive the at least one one-time transaction identifier at step 360. If the dependent party does not at least partially match the user's identity verification, processor system 100 may be programmed or configured to transmit the identity verification to at least one party, which may optionally communicate with processor system 100 and request it to generate at least one challenge question and transmit it to at least one user, and in response, processor system may be programmed and configured to generate at least one challenge question and transmit it to at least one user, and at least one user device 110 of the at least one user may be programmed or configured to receive the at least one challenge question at step 330. If the challenge question is received, at least one user may use at least one user device 110 to input at least one challenge response and transmit it to processor system 100 at step 340, and in response, processor system 100 may be programmed or configured to transmit at least one challenge response 340 to at least one party. If at least one party approves at least one challenge response 340 and transmits it to processor system 100, processor system 100 may be programmed or configured to transmit the approval of at least one party to at least one user device 110 of at least one user.In response to receiving approval from at least one party, at least one user can request at least one one-time identifier using at least one user device 110 in step 350. The at least one user device is programmed or configured to generate the request and transmit it to the processor system 100. In response to receiving at least one request for at least one one-time transaction identifier, the processor system 100 can be programmed or configured to generate at least one one-time transaction identifier and transmit it to at least one user. The user can receive the one-time transaction identifier on at least one user device 110 in step 360. Once the user receives the one-time transaction identifier in step 360, the user can input the at least one one-time transaction identifier into at least one user device 110 in 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 can be programmed or configured to provide the one-time transaction identifier to at least one party to continue any further steps required for the transaction.

[0090] According to some non-limiting expressions, embodiments, or aspects, Figure 4 This describes the steps that can be taken when at least one processor system 100 receives a transaction request from at least one user. In step 410, the at least one processor system can be programmed or configured to receive at least one transaction request from at least one user. In response to receiving at least one request, the processor system 100 can be programmed or configured in step 420 to generate a request for at least one identity document from at least one user and transmit the request on at least one user device 110. If the processor system 100 is not at least one dependent party, but operates on behalf of at least one dependent party, the at least one processor system 100 can also be programmed or configured to transmit the request to at least one dependent party of the transaction, which can, in response to receiving the request, transmit the request back to the at least one processor 100 that requested at least one identity document from at least one user. In response, the processor can generate at least one request and transmit it to the user on at least one user device 110.

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

[0092] If at least one processor system 100 fails to match the identity credentials of at least one user with the identity credentials of at least one user stored in the processor system 100, then at least one processor system 100 may be programmed or configured to optionally generate at least one challenge in step 430 and transmit the challenge to the user. At least one processor system 100 may also be programmed or configured to send a determination in step 430 that the received at least one identity credentials do not at least partially match the stored identity credentials of at least one user to a dependent party. In response, at least one party may communicate with at least one processor system 100 during its determination process and instruct it to generate at least one challenge request and transmit the challenge request to at least one user on at least one user device 110.

[0093] Upon receiving at least one challenge, at least one user can input at least one challenge response into at least one user device 110, which can be programmed or configured to transmit 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 in 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, in step 440, at least one processor system 100 may be programmed or configured to generate at least one one-time transaction identifier in steps 450 and 460 respectively and transmit it to at least one user on at least one user device 110.

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

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

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

[0098] According to some non-limiting expressions, embodiments, or aspects, Figures 5A-5E Describe a data structure that can be used by the dependent party to store at least one dependent party risk adjustment indicator and associated information for the user. Figures 5A-5E The records described herein may store user information from at least one identity document provided by user 210 to the other party, as well as transaction history on which at least one dependent party risk adjustment indicator is based for the dependent party to accept, refuse, initiate, conduct (or any combination thereof) transactions with user 210. For example, if it is possible to use such Figure 5A The blockchain structure shown allows storing at least one dependent party risk adjustment indicator as at least one block of the blockchain, where user identity verification, transaction history, transaction information (which may include, but is not limited to, transaction type, amount, time, and location), and the transacting parties are also represented in the blockchain block. This is analogous to a relational element in a relational database, such as... Figure 5B The relationship elements shown, at least one dependent risk adjustment indicator, can be stored together with indicators pointing to a user, at least one identity document of the user, transaction history, and the trader, wherein each can be stored separately in the same or different storage devices of system 100. If stored in a hierarchical database, object database, or graph database, a transaction may include at least one dependent risk adjustment indicator of the user, identity document, transaction history, and data items that the trader can aggregate or link to, such as... Figure 5C , 5D These are depicted separately in 5E. Please note that... Figures 5A-5E The illustrative databases shown can be used in various combinations and as a centralized or distributed database structure within one or more system storage devices, and they do not preclude the use of other structures, or any combination thereof, that may become available, be developed or enhanced in the future.

[0099] According to some non-limiting expressions, embodiments, or aspects, Figure 6 This illustrates certain interactions that at least one user can perform using at least one user device (in this case, a mobile phone) with at least one processor or at least one dependent party communicating with at least one processor, or any combination thereof. On at least one screen 610 of at least one user device, the user can enter at least one request to initiate or conduct a transaction and request at least one one-time transaction identifier. The at least one processor or party can then send a message to the at least one user requesting at least one authentication document, which can be displayed on at least one screen 620. If at least one authentication document is available on the at least one user's mobile device, the at least one user can send a message authorizing the sending of the specified at least one authentication document by entering information on at least one screen 630, for example, by checking a checkbox on screen 630 to specify at least one authentication document or by at least one user approving the sending of an assertion-based authentication document as an assertion file to the at least one processor or party, and by leaving an unchecked checkbox on screen 630 for at least one authentication document that may not be authorized to be sent to the at least one processor or party. If at least one authentication document is not stored on the at least one user's phone but is stored on the processor or dependent party, the at least one user can use at least one screen 630 to authorize which information can be authorized by said party or transmitted by the processor to said party, or any combination thereof.

[0100] If at least one processor or party can store the user and processor or party in at least one of its storage devices (e.g., based on at least one authorized identity certificate sent or already sent by the user), Figure 1At least one identity verification in the processor system storage device 130 or 160 of the processor shown at least partially matches, and at least one processor or party can 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. In response, at least one user can enter this code into a text field on at least one screen 650 and send it back to the processor or party to confirm their identity. After receiving at least one one-time transaction identifier from at least one user, the processor or party can approve or reject at least one transaction based on at least one dependent party risk adjustment indicator, which can be generated, transmitted to, and used by a dependent party (not shown), but is not sent to at least one user.

[0101] Figure 7 This is a non-limiting illustration showing that at least one user can 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 transfer of at least one identity document to at least one dependent party (in this case, a hospital). The at least one identity service can then send at least one instruction presented on at least one user device screen 715, said instruction for the user to request at least one one-time transaction identifier. In response to at least one user following the instruction presented on screen 715, the identity server can 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 at least one user enters the at least one one-time transaction identifier on at least one screen 730, the user's device can transmit it to at least one identity service, causing it to be displayed on at least one user device screen 740, said display indicating that the service is retrieving information that may require authorization and transfer to at least one dependent party.

[0102] If the required risk information is available, at least one identity service can transmit specific identity verification information that can be authorized and transmitted to at least one dependent party. The available information can be presented on at least one user device, such as at least one screen 750. At least one transmission of the available proof-of-concept information can be transmitted to at least one user's device in various ways, including but not limited to sending push notifications 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 that can be transmitted to at least one requesting party, and at least one user may or may not confirm permission to transmit the user identification information to the requesting party. Options may allow the user to select which information can be shared with at least one requesting party, such as address, bank number, or assertions associated with such information, or any combination thereof. For example, screen 750 illustrates information that the user can authorize to be transmitted to the requesting party, or information that can be used as the basis for an assertion profile to be transmitted to at least one requesting party.

[0104] As shown in at least one screen 750, a user can check a checkbox to indicate that he or she authorizes at least one identity service to transmit information to at least one dependent party, and the checkbox can be left unchecked for information that the user has not authorized to be sent to the dependent party.

[0105] In some non-limiting expressions, embodiments, or aspects, the user updates old information within the application before a response can be sent to the dependent party. In some non-limiting expressions, embodiments, or aspects, the required data may be specific to the requested account type 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 transmit the name of at least one dependent party and at least one identity document required to conduct or perform a transaction to at least one user, who may, in response, authorize which at least one identity document 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 user's identity information, which can be used as one aspect of user identity or to enable an identity service or dependent party to use the user's identity verification 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 authentication request to at least one identity service may have previously been vetted by at least one identity service. In response, the identity service may provide at least one user with at least one cryptographic token to verify themselves when making at least one authentication request. They can use these tokens to prevent fraudsters from attempting to deceive the dependent party, because the fraudster may not have access to the token and cannot 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; it's worth noting that while some steps can be reordered, Figure 3 and Figure 4 The steps described in the text are still relevant. For example, they can be interchanged. Figure 3 Steps 320 and 350 reflect the possibility that a user can request a one-time transaction identifier before providing or accessing proof of identity to or by at least one processor system 100 or party, or any combination thereof. Similarly, if a code can be provided to at least one user before receiving or accessing proof of identity of at least one user, then... Figure 4 Steps 450, 460, and 470 can be performed after step 410.

[0110] Although the disclosed subject matter has been described in detail for illustrative purposes based on embodiments or aspects currently considered to be most practical and preferred, it should be understood that such details are for the purposes described only, and 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 currently disclosed subject matter is intended to contemplate, as far as possible, that one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method, comprising: The user device receives a request from at least one identity service to approve the transmission of at least one user identity certificate to at least one dependent party; The user device prompts its user to request at least one one-time transaction identifier based on the request. The user device requests 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 from the user on the user device. In response to a request for the at least one one-time transaction identifier, the user device receives the at least one one-time transaction identifier from the identity server; The at least one one-time transaction identifier is displayed on the screen of the first user device by the user device; The user device receives a second input from the user on a second user device screen that is different from the screen of the first user device, the second input including at least one one-time transaction identifier; The user device transmits the one-time transaction identifier, which is entered by the user on the screen of the second user device, to the at least one identity service; as well as In response to receiving the at least one input one-time transaction identifier, the at least one dependent party determines whether to approve or reject 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 according to claim 1 further includes: Generate at least one risk signal symbol associated with the user.

3. The computer-implemented method according to claim 2 further includes: At least one dependent risk adjustment indicator is generated based on the one-time transaction identifier and the at least one risk signal associated with the user; as well as The risk adjustment indicator of the at least one dependent party is transmitted to the at least one dependent party.

4. The computer-implemented method according to claim 3, wherein, The decision to approve or reject the transaction is made in part based on the risk adjustment indicator received by the dependent party from the at least one dependent party.

5. The computer-implemented method according to claim 1, further comprising: The at least one user identity certificate is displayed, wherein the at least one user identity certificate is associated with a corresponding checkbox among a plurality of corresponding checkboxes.

6. The computer-implemented method according to claim 5, further comprising: Receive a third input from the user, the third input including selection of at least one 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 checkbox, wherein the check mark indicates that the user authorizes the at least one identity service to send at least one corresponding user identity certificate to the at least one dependent party.

7. The computer-implemented method according to claim 5, wherein, The at least one user authentication 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, said at least one processor of the user device being programmed or configured to: Receive a request from at least one identity service to approve the transmission of at least one user identity certificate to at least one dependent party; Based on the request, the user of the user device is prompted to request at least one one-time transaction identifier; Based on the user's first input on the user device, request the at least one one-time transaction identifier from at least one identity server associated with the at least one identity service; In response to a request for the at least one one-time transaction identifier, the at least one one-time transaction identifier is received from the identity server; The at least one one-time transaction identifier is displayed on the screen of the first user device. Receive the user’s second input on a second user device screen that is different from the first user device screen, the second input including at least one one-time transaction identifier; A one-time transaction identifier, input by the user on the screen of the second user device, is transmitted to the at least one identity service; as well as At least one processor of the at least one dependent party is programmed or configured to: In response to receiving the at least one input one-time transaction identifier, a determination is made, at least in part, based on the at least one one-time transaction identifier and the at least one input one-time transaction identifier, to approve or reject the transaction.

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

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

11. The system according to claim 10, wherein, When determining whether to approve or reject the transaction, the at least one processor of the dependent party is programmed or configured to: Receive the at least one dependent party risk adjustment indicator, wherein the determination of whether to approve or reject the transaction is based in part on the at least one dependent 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 identity certificate is displayed, wherein the at least one user identity certificate is associated with a corresponding checkbox among a plurality of corresponding checkboxes.

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

14. The system according to claim 12, wherein, The at least one user authentication 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, said at least one non-transitory computer-readable medium comprising one or more instructions, said one or more instructions causing said at least one processor, when executed by said at least one processor, to: Receive a request from at least one identity service to approve the transmission of at least one user identity certificate to at least one dependent party; Based on the request prompting user device, the user requests at least one one-time transaction identifier; Based on the user's first input on the user device, request the at least one one-time transaction identifier from at least one identity server associated with the at least one identity service; In response to a request for the at least one one-time transaction identifier, the at least one one-time transaction identifier is received from the identity server; The at least one one-time transaction identifier is displayed on the screen of the first user device. Receive the user’s second input on a second user device screen that is different from the first user device screen, the second input including at least one one-time transaction identifier; A one-time transaction identifier, input by the user on the screen of the second user device, is transmitted 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, at least in part, based on the at least one one-time transaction identifier and the at least one input one-time transaction identifier, to approve or reject the transaction.

16. The computer program product according to claim 15, wherein, The one or more instructions cause the at least one processor to: Generate at least one risk signal symbol associated with the user.

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

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

19. The computer program product according to claim 15, wherein, The one or more instructions cause the at least one processor to display the at least one user identity certificate, wherein the at least one user identity certificate is associated with a corresponding checkbox among a plurality of corresponding checkboxes.

20. The computer program product according to claim 19, wherein, The one or more instructions cause the at least one processor to: Receive a third input from the user, the third input including selection of at least one of the plurality of corresponding checkboxes; and In response to receiving the third input, a check mark is displayed in at least one selected checkbox, wherein the check mark indicates that the user authorizes the at least one identity service to send at least one corresponding user identity certificate to the at least one dependent party, wherein the at least one user identity certificate is a biometric input, a personal identification number, a password, or any combination thereof.

Images