Systems and Methods for Dynamic Identity Decision Making

Abstract

An example system and method for dynamic identity decision-making includes: receiving, from a third-party server, a request to confirm the identity of a user attempting to conduct a transaction through a third-party website, the third-party website being displayed in a first application window on the user's user device; causing the user device to display a second application window for presenting an identity decision application and at least partially overlapping the first window; evaluating a risk level associated with the transaction based on authentication data retrieved from the user device; and if the risk level exceeds a predetermined threshold, selecting at least one identity verification check for presentation to the user via the second window, determining a result of the at least one identity verification check based on a user response to the at least one identity verification check, and determining an identity decision result based on the result; and presenting the result to the user via the second application window.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Patent Application No. 62 / 661,519, filed Apr. 23, 2018, the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present invention generally relates to authentication and / or identification, and more particularly to systems and methods for making dynamic identity decisions for users attempting to initiate a transaction from a remote device. BACKGROUND ART

[0004] Especially in today's digital age, identity theft is an increasingly worrying problem. For example, many transactions, including commercial transactions, financial transactions, insurance-related transactions, and healthcare-related transactions, can now be completed online with little to no personal interaction between the customer and the agent of the service provider or other transaction entity. For example, a user may be able to open a new bank account and / or a new credit card through a bank's website. As another example, a user may be able to set up an insurance policy (e.g., for auto, home, health, etc.) through an insurance company's website. In yet another example, a user may be able to request his / her credit rating score through a credit rating agency's website. These online transactions are vulnerable to identity theft because service providers typically rely entirely on the information provided by the user to complete the transaction.

[0005] Many service providers and other transaction entities have adopted technologies for authenticating a customer's identity during a transaction, especially when the customer is conducting the transaction from a remote location and / or using a remote device. However, the commercially available technologies for authentication and / or identification can be time-consuming, costly, and cumbersome, at least because these technologies require a significant amount of man-hours to implement and maintain. For example, most existing technologies involve complex programming code that is manually integrated into the existing websites of service providers by software programmers. And whenever a change is made to the programming code, the software programmers manually update the service provider's website accordingly. SUMMARY OF THE INVENTION

[0006] The present invention is defined by the appended claims. This description outlines some aspects of exemplary embodiments and is not intended to limit the claims. Other embodiments will be apparent to those of ordinary skill in the art in view of the technologies described herein, and such embodiments are intended to be within the scope of this application.

[0007] Systems and methods for dynamic identity decision-making are provided herein. An example embodiment includes a method performed in a server, the method comprising: receiving, from a third-party server, a request to confirm the identity of a user attempting to conduct a transaction via a third-party website, the third-party website being displayed in a first application window on the user's user device; causing the user device to display a second application window for presenting an identity decision application, the second application window at least partially overlapping the first application window; evaluating, by a processor, a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold, then: selecting, by the processor, at least one identity verification check for presentation to the user via the second application window, determining, by the processor, a result of the at least one identity verification check based on a user response to the at least one identity verification check, and determining an identity decision result based on the result of the at least one verification check; if the risk level does not exceed the predetermined threshold, then determining the identity decision result based on the risk level associated with the transaction; and presenting the identity decision result to the user via the second application window.

[0008] Another example embodiment includes a server that communicates over a network with a third-party server and a user device, the server comprising: a memory configured to store program code; and a processor in communication with the memory and configured to execute the program code, the program code for: receiving, from the third-party server, a request to confirm the identity of a user attempting to conduct a transaction via a third-party website, the third-party website being displayed in a first application window on the user's user device; causing the user device to display a second application window for presenting an identity decision application, the second application window at least partially overlapping the first application window; evaluating a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold, then: selecting at least one identity verification check for presentation to the user via the second application window, determining a result of the at least one identity verification check based on a user response to the at least one identity verification check, and determining an identity decision result based on the result of the at least one verification check; if the risk level does not exceed the predetermined threshold, then determining the identity decision result based on the risk level associated with the transaction; and presenting the identity decision result to the user via the second application window.

[0009] Yet another example embodiment includes a non-transitory computer-readable medium including computer instructions embodied on the non-transitory computer-readable medium to cause a processor to perform the following operations: receive a request from a third-party server to authenticate the identity of a user attempting to conduct a transaction through a third-party website, the third-party website being displayed in a first application window on the user's user device; cause the user device to display a second application window for presenting an identity decision application, the second application window at least partially overlapping the first application window; evaluate a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold, then: select at least one identity verification check for presentation to the user via the second application window, determine a result of the at least one identity verification check based on a user response to the at least one identity verification check, and determine an identity decision result based on the result of the at least one verification check; if the risk level does not exceed the predetermined threshold, then determine the identity decision result based on the risk level associated with the transaction; and present the identity decision result to the user via the second application window.

[0010] Another embodiment includes a networked computing system including: a third-party server configured to host a third-party website, the third-party server permitting the transaction with the third-party website based on an identity decision result received in connection with a user transaction; a user device configured to display a first application window for presenting the third-party website and a second application window for presenting an identity decision application, the second application window at least partially overlapping the first application window; and an identity decision server configured to host the identity decision application, the identity decision server including a processor configured to execute program code for: receiving a request from the third-party server to authenticate the identity of a user associated with the user transaction; causing the user device to display the second application window immediately after receiving the request; evaluating a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold, then: selecting at least one identity verification check for presentation to the user via the second application window, determining a result of the at least one identity verification check based on a user response to the at least one identity verification check, and determining the identity decision result based on the result of the at least one verification check; if the risk level does not exceed the predetermined threshold, then determining the identity decision result based on the risk level associated with the transaction; and presenting the identity decision result to the user via the second application window. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For a better understanding of the present invention, reference may be made to the embodiments shown in the following diagrams. The components in the diagrams are not necessarily to scale and related elements may be omitted to emphasize and clearly illustrate the novel features described herein. Additionally, the system components may be arranged in various ways known in the art. Further, in the diagrams, like reference numerals designate corresponding parts throughout several views.

[0012] Figure 1 is a block diagram illustrating an exemplary networked computing system for implementing dynamic identity decision-making techniques according to an embodiment;

[0013] Figure 2 is a diagram illustrating an exemplary sequence of interactions between components of the system shown during the implementation of dynamic identity decision-making techniques according to an embodiment Figure 1 among the components shown;

[0014] Figure 3 illustrates an exemplary interface associated with a transaction website according to an embodiment;

[0015] Figures 4 to 10 illustrates an exemplary interface associated with a dynamic identity decision application according to an embodiment;

[0016] Figure 11 is a flowchart illustrating an exemplary process for implementing dynamic identity decision-making according to an embodiment;

[0017] Figure 12 is a flowchart illustrating an exemplary sub-process of the decision-making process shown in Figure 11 according to an embodiment; and

[0018] Figure 13 is a block diagram of an exemplary computing device from Figure 1 the system shown according to an embodiment. Detailed Description

[0019] Although the invention disclosed herein may be embodied in various forms, some exemplary and non-limiting embodiments are shown in the diagrams and will be described hereinafter. It should be understood that this disclosure should be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiments illustrated.

[0020] In this disclosure, the use of the disjunctive is intended to encompass the conjunctive. The use of the definite or indefinite article is not intended to indicate cardinality. Specifically, reference to "the" object or "a" object is also intended to denote one of the possible plurality of such objects.

[0021] In accordance with the principles disclosed herein, systems and methods are provided for performing dynamic identity decision-making for users attempting to transact through a website operated by a transaction entity. According to an embodiment, a graphical user interface related to performing the identity decision may be presented to the user along with the attempted transaction, but the decision technology may be executed or controlled by an entity other than the transaction entity. For example, the identity decision entity may provide a contract to a third-party entity for implementing the dynamic identity decision technology in a manner that requires minimal participation (whether programming, maintenance, or otherwise) from the third-party entity. In some embodiments, the identity decision entity may control the decision process through a dynamic identity decision application that is presented on the user's device immediately upon receiving a request for an identity decision from the transaction entity. The dynamic identity decision application may be presented, for example, within a second application window without closing or leaving the transaction website, where the second application window is at least partially superimposed on or embedded within the initial application window presenting the transaction website.

[0022] According to an embodiment, the identity decision technology disclosed herein may be "dynamic" at several levels, including the ability to select a successor decision technology in real time based on a previously completed decision and the ability to configure decision technology for an individual user on the fly. For example, according to an embodiment, the identity decision technology may include at least two decision stages: an authentication stage and an identification stage. The result of the authentication stage may be used to determine, for example, whether identification is required depending on the transaction risk level evaluated during the authentication stage. In some embodiments, the identification stage includes performing one or more dynamically configured identification checks, the number and / or type of which depend on the risk level of the transaction. As an example, in some embodiments, the types of identification checks include knowledge-based authentication and one-time password authentication. According to an embodiment, the authentication stage may also include dynamically configured decision technologies, such as device verification, user credential verification, and personal identification verification. For example, according to some embodiments, personal identification verification may be utilized only if passive verification and / or credential verification are not successfully completed. Thus, the dynamic decision technology disclosed herein enables a transaction entity to assess a user's identity using a minimal but effective number of decision tools.

[0023] Reference Figure 1, the system diagram illustrates an embodiment of a computer networking system 100 for implementing dynamic identity decisions in accordance with one or more of the principles described herein. System 100 may include modules and components connected via a network (e.g., the Internet), which may facilitate communication through a secure channel. It should be understood that system 100 is merely exemplary and may include fewer or more components and entities, as well as various other combinations of components and entities. Additionally, one or more components of system 100 may be implemented using software executable by one or more computers (e.g., servers, personal computers, computing devices, mobile devices, etc.). An exemplary computer is Figure 13 shown as computing device 1300 and will be discussed in more detail below.

[0024] As Figure 1 shown, system 100 includes user device 102, transaction server 104, and identity decision server 106. These components of environment 100 may be communicatively connected to each other via one or more communication networks (e.g., the Internet). As an example, in some cases, user device 102 may be communicatively coupled to at least one of transaction server 104 or identity decision server 106 via a global network or wide area network (WAN). In other cases, at least two of user device 102, transaction server 104, or identity decision server 106 may be connected via a local area network (LAN).

[0025] As Figure 1 shown, user device 102 may be operated by user 108. User 108 may be any individual or entity desiring to execute a transaction with a transaction entity 110 (discussed in more detail below). For example, the transaction may include opening a new account, accessing an existing account, applying for a new credit card, applying for a loan, requesting insurance coverage (including auto, home, health, life, malpractice, etc.), taking a standardized exam, or any other action between the user and the transaction entity involving goods or services provided by the transaction entity. In some cases, user 108 may be an existing user (e.g., customer, member, etc.) of transaction entity 110 and / or identity decision entity 114 (discussed in more detail below). In other cases, user 108 may be a new user of at least one of transaction entity 110 or identity decision entity 114. In an embodiment, it should be understood that device 102 may be any type of device, e.g., a notebook or desktop computer or any type of portable computing device, including smart phones, tablet devices, personal data assistants (PDAs), etc., including any type of hardware or software components or combinations thereof.

[0026] In an embodiment, the transaction server 104 may be communicatively coupled to a transaction database 112 configured to store existing user or customer information, prior transaction information, and any other information related to performing transactions through the transaction server 104. Although Figure 1 not shown, in some embodiments, the transaction database 112 may be stored in the memory (not shown) of the transaction server 104. The transaction server 104 may be operated by or affiliated with a transaction entity 110.

[0027] In an embodiment, the transaction entity 110 may be any type of business, institution, government agency, or other entity that provides goods or services to the user 108 or otherwise enables a transaction with the user 108. In some cases, the transaction entity 100 may be any type of entity that exchanges confidential, private, personal, or other sensitive information with the user 108 to complete a transaction and desires to confirm the identity of the user requesting the transaction. For example, the transaction entity 110 may include an insurance company that provides one or more types of insurance policies (including, for example, auto, home, accident, life, malpractice, and / or health insurance policies). As another example, the transaction entity 110 may include a financial institution that provides various types of financial accounts and / or services, such as a bank, mortgage company, credit union, investment company, etc. In yet another example, the transaction entity 110 may include a credit reporting agency (e.g., TransUnion, Equifax, Experian, etc.) that can determine a user's credit rating score. In still another example, the transaction entity 110 may include a healthcare institution or any other health-related entity that provides various medical services, sells prescription drugs, and / or other medical products (e.g., a hospital, medical clinic, pharmacy, dental clinic, doctor's office, etc.). In another example, the transaction entity 110 may include a testing facility or educational institution that administers an electronic or paper exam (including, for example, a standardized exam) and requires verification of the identity of the test taker before the exam can begin.

[0028] According to an embodiment, the identity decision server 106 may be operated by or attached to the identity decision entity 114. The identity decision entity 114 may be any company or enterprise that provides an identity decision solution, including a stand-alone software application, programming code for incorporation into an existing application or website, and / or an identity verification or confirmation service. The identity decision server 106 may be communicatively coupled to an identity decision database 116, which is configured to store identity information of multiple users, information related to one or more identity decision techniques (e.g., pre-generated authentication checks, one-time password check formats, knowledge-based questionnaires, verification questionnaires, etc.), or any other information related to implementing dynamic identity decisions using the identity decision server 106. Although Figure 1 not shown in the figure, in some embodiments, the identity decision database 116 may be stored in the memory (not shown) of the identity decision server 106. In some embodiments, the identity decision database 116 may have a distributed architecture consisting of several computing devices communicatively coupled via a network (e.g., using cloud computing techniques).

[0029] The user device 102 may include multiple computer programs, including but not limited to, programs for receiving and processing information electronically transmitted by the transaction server 104 and / or the identity decision server 106 and for electronically transmitting queries to the transaction server 104 and / or the identity decision server 106. For example, the user 108 may interface with the user device 102 to initiate a transaction with the transaction entity 110 through, for example, a transaction website hosted by the transaction server 104 (see, for example, Figure 2 , discussed in more detail below).

[0030] Similarly, the transaction server 104 may include multiple computer programs, including but not limited to, programs stored in the database 112 for receiving and processing queries electronically transmitted from the user device 102. In some example embodiments, the transaction server 104 and / or the database 112 include programming code associated with implementing the transaction website and the user transactions associated therewith, and the user device 102 may communicate with the transaction server 104 to implement various functions of the transaction website.

[0031] Similarly, the identity decision server 106 may include multiple computer programs, including but not limited to programs stored in the database 116 for receiving and processing queries electronically transmitted from the user device 102 and / or the transaction server 104. In some embodiments, the identity decision server 106 may execute a dynamic decision application for implementing the identity decision techniques disclosed herein. The user device 102 and / or the transaction server 104 may interact with the identity decision server 106 to perform various functions of the dynamic decision application (also referred to herein as the "identity decision application").

[0032] In some embodiments, the dynamic decision application may reside on multiple devices (e.g., the identity decision server 106 and / or those interface devices) by, for example, being downloaded via the Internet or other network or being transported on a computer-readable medium and copied into the memory of the various interface devices. For example, the user 108 may interact with the dynamic decision application through a user interface, and the transaction entity 110 may interact with the dynamic decision application through a transaction entity interface. These interfaces may be software programs designed to operate on the respective interface devices and customized to interact with and exchange data with the dynamic decision application. These software programs may include mobile applications executable on smartphones, mobile devices, etc. In some embodiments, the interfaces may reside only on the identity decision server 106. In some embodiments, the interfaces may be standard web browser software programs, such as Internet Explorer, Firefox, Chrome, or Safari. In such embodiments, the user or the transaction entity uses the browser interface to interact with the dynamic decision application. Additionally, according to these embodiments, the dynamic decision application may be implemented as a website hosted by the identity decision server 106 or other computing device. As Figures 4 to 10 shown and described below, in an exemplary embodiment, the dynamic decision application may be implemented in a "pop-up" window that appears on top of or is superimposed on the transaction website without replacing or closing the transaction website hosted by the transaction server 104 (e.g., as Figure 3 seen).

[0033] Figure 2Sequence 200 illustrates the interaction between user device 102, transaction server 104, and identity decision server 106 according to an embodiment. Sequence 200 may be associated with a method for dynamically verifying or assessing the identity of a user (e.g., user 108) attempting to conduct a transaction through a transaction website hosted by transaction server 104. Sequence 200 may be implemented in software, firmware, hardware, or any combination thereof. In an exemplary embodiment, user device 102, transaction server 104, and / or identity decision server 106 may implement the functions depicted and described herein by executing application programs stored on user device 102, transaction server 104, and / or identity decision server 106. In some embodiments, user device 102 may implement relevant portions of Sequence 200 by executing an application program and interfacing with identity decision server 106 and / or transaction server 104. Similarly, identity decision server 106 may implement relevant portions of Sequence 200 by executing an application program and interfacing with user device 102 and / or transaction server 104. In some embodiments, the application program is a dynamic decision application program or a part thereof. In some embodiments, the application program includes at least a portion of a software application associated with implementing the transaction website. In some embodiments, the application program may be a computer program stored on a non-transitory computer-readable medium executable by a processor of one or more of user device 102, transaction server 104, or identity decision server 106.

[0034] Additionally refer to Figures 3 to 10 , and in relevant cases herein, Sequence 200 will be described with reference to the exemplary screen shots shown in Figures 3 to 10 . However, it will be understood that according to the principles disclosed herein, graphical user interfaces with other designs and / or functions may be used in place of or in addition to the illustrated screen shots. User device 102 may include a display screen (not shown, but see, for example, Figure 13 ) for displaying the graphical user interfaces described herein. User device 102 may also include user input devices (e.g., touch screen, keyboard, mouse, trackball, joystick, keypad, etc.) (not shown, but see, for example, Figure 13 ) for providing input to the graphical user interface and otherwise interacting with the transaction website and / or the dynamic decision application program.

[0035] Figure 3FIG. illustrates a screen shot of an exemplary graphical user interface 300 associated with a transaction website hosted by transaction server 104 and / or other computer devices, according to an embodiment. In some embodiments, the transaction website may be implemented by executing a software application residing on transaction server 104 and / or various interface devices (e.g., user device 102). In some embodiments, interface 300 resides only on transaction server 104. In other embodiments, interface 300 may be part of a standard web browser software program (e.g., Internet Explorer, Firefox, Chrome, or Safari). Data associated with exemplary interface 300 may be transmitted to, received from, and / or synchronized with transaction server 104 and / or other computing devices.

[0036] In the illustrated embodiment, the transaction website is affiliated with or operated by the transaction entity "U_Bank". As shown, interface 300 presents information regarding opening a new checking account at U_Bank for a customer (e.g., user 108) accessing the transaction website. Additionally, interface 300 includes a "Open Now" option 302 that invites the customer to initiate an "Open New Account" transaction by selecting option 302. In some embodiments, interface 300 may alternatively or additionally display options related to other types of transactions offered by transaction entity U_Bank (e.g., "Apply for a Loan", "Apply for a Credit Card", "Request a Debit Card", etc.). Further, although in the illustrated example the transaction entity is a financial institution, it will be understood that the transaction website may belong to any type of transaction entity, and the transaction initiated by the user selecting option 302 may be any type of action related to goods and services offered by the transaction entity.

[0037] Referring back Figure 2 , sequence 200 includes receiving (202) at user device 102 a command to initiate or attempt a transaction at the transaction website. As an example, the user may via interface 300 initiate Figure 3The input command (202) is issued in response to the "Open Now" option 302 shown. In response to receiving the command (202) and / or the user selecting option 302, the user device 102 or interface 300 may send a request (204) to initiate or enable a transaction to the transaction server 104. According to some embodiments, after receiving the request (204), the transaction server 104 may automatically contact the identity decision server 106 to request (206) confirmation of the identity of the user attempting the transaction. In other embodiments, the transaction server 104 may first determine whether identity confirmation is required based on preliminary conditions. As an example, the preliminary conditions may include whether the user 108 and / or the user device 102 is recognized by the transaction server 104 as associated with an existing customer account using off-the-shelf or user-provided information (e.g., device identification information, one-time password, username and password, PIN number, security code, etc.). In such instances, failure to meet the preliminary conditions may cause the transaction server 104 to request (206) identity confirmation from the identity decision entity 114.

[0038] In response to receiving the request (206), the identity decision server 106 may initiate an identity decision process for the user, for example, by executing all or a portion of the dynamic decision application described herein. According to an embodiment, the identity decision process may be controlled or conducted by the identity decision server 106 with little or no input from or communication with the transaction server 104. For example, in some embodiments, after receiving the request (206) from the transaction server 104, the identity decision server 106 may communicate directly with the user device 102 during the identity decision process. Once the process is complete, communication with the identity decision server 106 may cease, and the user device 102 may return to communicating directly with the transaction server 104.

[0039] In an embodiment, according to or after an identity decision process, identity decision server 106 may directly provide (208) instructions to user device 102 for displaying on a display of user device 102 one or more graphical user interfaces associated with a dynamic decision application (also referred to herein as an "identity decision interface"). Additionally, the instructions may direct user device 102 to present the identity decision interface within a second application window without closing or leaving the transaction website. In some embodiments, the instructions provided (208) by identity decision server 106 include programming code that, when executed by a processor of user device 102, causes user device 102 to display the identity decision interface. In other embodiments, the instructions provided (208) by identity decision server 106 may cause a portion of the dynamic decision application stored on user device 102 to display the identity decision interface. In either case, the instructions may cause user device 102 to display (209) the identity decision interface to the user, as Figure 2 shown in

[0040] Through the identity decision interface (e.g., second application windows 406, 506, 606, 706, 806, 906, and 1006, discussed below), identity decision server 106 may directly communicate and interact with user device 102 and otherwise control the identity decision process with little or no communication with transaction server 104. In some example embodiments, the identity decision interface may be configured using an application programming interface (API) or a similar protocol that enables the transaction website to interact or exchange information with the dynamic decision application as needed and / or jointly present the identity decision interface to the user with the transaction website.

[0041] According to an embodiment, it is not necessary to change the transaction website itself in order to implement the identity decision techniques disclosed herein. More specifically, the identity decision interface can be operated, changed, or otherwise controlled independently of the transaction website, such that the transaction entity 110 can rely almost entirely on the identity decision entity 114 to fulfill its identity verification needs. For example, a dynamic decision application can be configured such that the identity decision entity 114 is able to make changes to the identity decision interface without changing the underlying transaction website. In some cases, the transaction entity 110 can use a few lines of programming code provided by the identity decision entity 114 to integrate the dynamic decision application into the transaction website. For example, in some embodiments, the identity decision interface can be an HTML document, such as an HTML document embedded as an inline frame (or "iFrame") element into another HTML document associated with the transaction website. In some embodiments, the identity decision application can be seamlessly integrated into the transaction website, but is still controlled by a separate server / entity using one or more techniques, such as those disclosed in U.S. Patent No. 8,359,393, which is incorporated herein by reference in its entirety. In other example embodiments, the identity decision interface can be an HTML document provided in a "pop-up" window that appears (e.g., overlays or superimposes) on top of the transaction website. In either case, changes can be made to the HTML document and uploaded to the identity decision server 106 without affecting the transaction website or requiring additional programming of a portion of the transaction entity 110.

[0042] Figure 4 Illustrates a screen shot of an exemplary graphical user interface 400 according to an embodiment, the exemplary graphical user interface 400 including a first application window 402 for presenting a transaction website hosted by the transaction server 104 and / or other computer devices and a second application window 404 for presenting a dynamic decision application executed by the identity decision server 106, the user device 102, and / or other computer devices. Figures 5 to 10 Illustrates additional screen shots of an example graphical user interface 400 during various stages of an identity decision process according to an embodiment, the example graphical user interface 400 being generated by the dynamic decision application and presented by the identity decision server 106.

[0043] As illustrated, the second application window 404 can be a smaller window that appears (or pops up) on top of the first application window 402 without closing or replacing the first application window 402. For example, as Figure 4As shown, compared to the first application window 402, the second application window 404 may occupy a smaller portion of the interface 400, thus leaving portions of the first application window 402 exposed or visible around the edges of the second application window 404. In some embodiments, the second application window 404 may be implemented using an iFrame nested or embedded within the first application window 402. In such cases, the second application window 404 may be a frame that occupies or is superimposed on a predetermined portion of the first application window 402.

[0044] According to an embodiment, the underlying first application window 402 may be substantially similar in content and / or design to Figure 3 the interface 300 shown. In some embodiments, the first application window 402 may remain unchanged (or frozen) until the identity decision process is complete. In other embodiments, the first application window 402 may display a message related to the identity decision process (e.g., "We appreciate your patience while we confirm your identity") until the identity decision process is complete. In other embodiments, the second application window 404 may occupy the entire interface 400 such that the first application window 402 is no longer visible. In such cases, although hidden by the second application window 404, the first application window 402 may still remain open or active.

[0045] Presenting windows 402 and 404 in at least an overlapping configuration within the interface 400 can help reassure the user that the dynamic decision application is a legitimate extension of or affiliated with the trading website. In some embodiments, to further confirm the relationship, the second application window 404 may include a logo, label, or other signage identifying the affiliation between the second application window 404 and the trading website. For example, in the illustrated embodiment, the second application window 404 may display a U_Bank logo (not shown).

[0046] Referring back to Figure 2 , sequence 200 may include the identity decision server 106 retrieving (210) authentication data from the user device 102 during the authentication phase of the identity decision process. According to an embodiment, the identity decision process may include at least two phases: an authentication phase and an identification phase (to be discussed in more detail below). In some cases, the authentication phase includes several layers for collecting different types of verification data. For example, the authentication phase may include a passive verification layer for "passively" or automatically collecting information from the user device 102, a credential verification layer for collecting login or credential information from the user, a personal verification layer for collecting personal identification information from the user, and other types of verification layers.

[0047] According to an embodiment, the passive authentication layer includes automatically retrieving passive information from the user device 102, for example, without requiring user input or intervention. In some cases, the identity decision server 106 may be configured to automatically request passive information from the user device 102 without notifying the user, and the user device 102 may be configured to automatically provide the passive information immediately upon receiving a request from the server 106.

[0048] In an embodiment, the passive information includes device identification information, environmental parameters, or any other information related to, stored on, or otherwise obtainable by the user device 102 without notifying the user. The device identification information may include a unique or distinctive identification number assigned by the device manufacturer to each smart phone, tablet computer, or other handheld device (e.g., the unique device ID (“UDID”) of an Apple device or the Android device ID of an Android device). In some embodiments, depending on the manufacturer's preference, the device identification number (also referred to herein as “device ID”) may be generated randomly or sequentially. In an embodiment, the device identification information may be stored in the memory of the user device 102 and provided to the identity decision server 106 immediately upon request. The environmental parameters may include location information (e.g., the location of the user device 102 when a command (202) to initiate a transaction is received), time and / or date information (e.g., a timestamp associated with receiving the command (202)), or any other parameter associated with the user and / or the user device 102 at the time of the transaction. In an embodiment, the location information may be collected and provided by a GPS receiver (not shown, but see, for example, Figure 13 ) within the user device 102. The location information may include GPS coordinates, a predefined location name (e.g., home, work, school, etc.), or any other location-related information. In an embodiment, the time and / or date information may be retrieved from the internal clock or calendar function of the user device 102. In some embodiments, the passive information further includes the IP address used by the user device 102 to communicate with the transaction website.

[0049] According to an embodiment, the identity decision server 106 may be configured to determine whether the retrieved passive information indicates suspicious behavior, for example, based on previously retrieved passive information and / or preset parameters. In some cases, the identity decision server 106 may be configured to flag a transaction as "suspicious" if the device ID and / or location information does not match the information previously retrieved in association with the user 108, where the user 108 is an existing customer of the transaction entity 110 and / or the identity decision entity 114. For example, if the current location associated with a given device ID does not match the previously recorded location of the same device ID, the transaction may be considered suspicious. As another example, if the device ID associated with a given user 108 (or username) does not match the previously recorded device ID of the same user 108, the transaction may be considered suspicious. Additionally or alternatively, in some cases, the identity decision server 106 may be configured to flag a transaction as "suspicious" if the timestamp meets certain preselected parameters for identifying late-night and / or very early morning activities (e.g., between 1:00 AM and 5:00 AM), unusually frequent activities (e.g., attempting more than 3 transactions within an hour), etc. In some embodiments, the identity decision server 106 may determine that a transaction fails the passive verification layer if one or more items within the passive information appear suspicious. In other embodiments, specific items of the passive information (e.g., device ID) may be weighted more heavily than other items (e.g., timestamp) when determining whether a transaction meets the passive verification layer.

[0050] According to an embodiment, the credential verification layer includes requesting login or other access credential information from the user 108 through one or more of the identity decision interfaces. The login information may include a username and password associated with an existing account held by the user 108. In some cases, the account is associated with a dynamic decision application or the identity decision entity 114. In other cases, the account is associated with a transaction website and / or the transaction entity 110. In an embodiment, if the login information is incorrect or if the user 108 does not have an existing account (e.g., a new user, a deactivated user, etc.), the user 108 will not pass the credential verification layer. In some embodiments, the dynamic decision application may be configured to allow a preset number of failed login attempts before flagging the user 108 as "suspicious" and / or determining that the user 108 fails the credential verification layer. In some embodiments, one or more of the identity decision interfaces may be configured to display a "Forgot Password" option (not shown) and / or a "Forgot Username" option (not shown) if the user 108 cannot remember their login information. In some cases, the dynamic decision application may be configured to classify a selection of either "Forgot" option as failing the credential verification layer.

[0051] According to an embodiment, the personal verification layer collects personal identification information ("PII") and / or other personal information from a user through one or more of the identity decision interfaces. In some embodiments, PII includes any information that can be used to distinguish or track the identity of an individual (e.g., name, social security number, date and place of birth, mother's maiden name, or biometric records (e.g., fingerprints, "voiceprints", retinal characteristics, facial features, handwriting, etc.)). In some embodiments, PII may further include any other information that relates to or can be used to contact an individual, such as medical information (e.g., blood type, genetic information, etc.), educational information (e.g., school name, graduation date, degree type, grade, etc.), financial information (e.g., bank account number, credit card number, etc.), and employment information (e.g., salary, position, employer name, etc.). Other examples of PII may include mailing address, home address, email address, national identification number, vehicle registration plate number, driver's license number, telephone number, criminal record, race, gender, age, digital identity, etc.

[0052] Referring back Figure 4 , the second application window 404 illustrated presents an exemplary PII interface 406 for requesting a user to provide or enter personal identification information. As an example, the PII interface 406 includes data input fields for first name, last name, address, city, state, zip code, home telephone number, work telephone number, mobile telephone number, email address, social security number ("SSN"), date of birth ("DOB"), and driver's license number. It will be appreciated that the PII interface 406 is not limited to the format or content of the illustrated embodiment, and any combination of personal information may be collected through the PII interface 406.

[0053] In the illustrated embodiment, the PII interface 406 also includes a device field 408 for manually identifying or naming the device used to access the transaction website. As an example, the device field 408 includes user-selectable values for a home computer, work computer, smart phone, and tablet computer. In some cases, the selected device value may be stored in the decision database 116 and used for the passive verification layer during future transactions. In some cases, the device value selected at the device field 408 may be stored in association with the device ID of the device 102 used to access the transaction website. As an example, the next time the user 108 (or someone posing as the user 108) attempts to log in to the transaction website, the identity decision server 106 may retrieve the previously stored device value and compare it with any currently retrieved passive information (e.g., device ID) to determine whether the user device 102 is familiar (and thus, not suspicious) or unfamiliar (and thus, suspicious).

[0054] The PII interface 406 further includes a submission option 410. A user's selection of the submission option 408 can send the information entered into the PII data fields to the identity decision server 106. In some embodiments, this can complete the retrieval (210) interaction of sequence 200. The identity decision server 106 can store the received information in the decision database 116. According to an embodiment, the identity decision server 106 can compare the received information with previously stored PII or other personal information associated with the user to determine whether the user passes or meets the personal authentication layer.

[0055] In the illustrated embodiment, the identity decision server 106 retrieves (210) authentication data including passive information from the user device 102 after displaying (209) an identity decision interface on the user device 102. In other embodiments, the identity decision server 106 can retrieve at least a portion of the passive information before providing (208) an instruction to display the second application window 404 to the user device 102. In such cases, the identity decision server 106 can determine whether to initiate the identity decision process and / or which stage(s) or layer(s) of the identity decision process are needed based on whether one or more items of the passive information retrieved from the user device 102 appear to be suspicious. For example, the identity decision server 106 can first retrieve the device ID of the user device 102 to determine whether the device 102 is recognized, and if the device 102 is recognized, then cause the user device 102 to display a credential verification screen within the second application window 404. If the device 102 is not recognized (e.g., the user 108 is a new user or is using a new device), then the identity decision server 106 can cause the user device 102 to display a different authentication screen within the second application window 404, such as the personal identification interface 406.

[0056] In some cases, at least one of the verification layers needs to be satisfied to pass the authentication phase. In other cases, the result of one layer can determine whether the identity decision process continues to the next layer within the authentication phase. For example, in some embodiments, failing at least one of the passive verification layer or the credential verification layer (e.g., a new user or a suspicious user) can trigger an additional verification layer, such as the personal verification layer. In other example embodiments, regardless of whether the passive verification layer is successful, failing the credential verification layer can automatically trigger or initiate the personal verification layer. In some cases, failing to meet a preselected verification layer among the verification layers can cause the identity decision process to jump directly to the identity authentication phase. For example, failing to submit valid login information in the credential verification layer can cause the identity decision process to continue to the identity authentication phase without completing the personal verification phase.

[0057] According to some embodiments, two or more individual verification layers may be performed or initiated simultaneously or at least during overlapping time periods. For example, in some embodiments, a passive verification layer may be triggered immediately after the initiation authentication phase. At the same time, or when the identity decision server 106 retrieves and analyzes passive information from the user device 102, an identity decision interface associated with the credential verification layer may be displayed on the user device 102 to collect login information. In some embodiments, the identity decision server 106 may analyze the results of these two verification layers to determine whether an additional verification layer (e.g., a personal verification layer) is necessary. For example, the identity decision server 106 may cross-reference the user's login information with the retrieved passive information to determine whether the transaction appears to be suspicious (e.g., based on whether the provided username has previously been associated with the retrieved device ID and / or location).

[0058] Referring back Figure 2 , according to an embodiment, sequence 200 further includes the identity decision server 106 evaluating (212) the risk level of a transaction based on authentication data received or retrieved from the user device 102. As an example, possible transaction risk levels may include high, medium, low, and zero. It will be appreciated that other types of values may be used to represent possible risk levels, including, for example, numbers (e.g., between 1 and 10), percentages (e.g., between 0% and 100%), other qualifiers (e.g., high risk, at risk, slightly at risk, no risk), etc.

[0059] According to an embodiment, the identity decision server 106 can be configured to evaluate (212) or identify the risk level of a transaction based on the result of the authentication phase. In some cases, the risk level can be evaluated based on the overall result of the authentication phase. For example, in some embodiments, if the user 108 passes the authentication phase, the transaction can be considered to have a low risk or no risk at all, and if the user 108 fails the authentication phase, the transaction can be considered to have a high risk. In other cases, the risk level can be evaluated based on the individual results of one or more of the verification layers. In some embodiments, the number of verification layers with a passing grade can determine the risk level assigned to the transaction. For example, if the user 108 passes all three verification layers, the transaction can be considered to have no risk. If the user 108 passes two of the three verification layers, the transaction can be considered to have a low risk. If the user 108 passes one of the three verification layers, the transaction can be considered to have a medium risk. And if the user 108 fails all three verification layers, the transaction can be considered to have a high risk. In other embodiments, the results of one or more of the verification layers can have more or less weight in the risk assessment than the results of other layers. For example, in some cases, the risk assessment can be greatly influenced by the result of the personal verification layer. In an example embodiment, if the user 108 fails the personal verification layer, the transaction can be automatically marked as having a medium risk, and if the user 108 also fails one or more of the other verification layers, the risk level can be rated as high risk.

[0060] According to some embodiments, the identity decision server 106 compares the evaluated risk level with a predetermined threshold to determine whether further identity decisions are needed. In some embodiments, the identity decision server 106 is configured to determine that the user 108 has not met or passed the authentication phase when the evaluated risk level is equal to or exceeds the predetermined threshold. In such cases, the identity decision process proceeds to the identity verification phase. On the other hand, if the evaluated risk level is lower than the predetermined threshold, the identity decision process can be completed, and there may be no need to proceed to the identity verification phase. According to some embodiments, the predetermined threshold can be a risk level selected from a list of possible transaction risk levels. As an example, the predetermined threshold can be at least one of a low risk level or a zero risk level.

[0061] In some embodiments, the authentication data includes two sets of data: initial authentication data and secondary authentication data, and evaluating (212) the risk level of a transaction can include evaluating a preliminary risk level based on the initial authentication data and, if the preliminary risk level so requires, evaluating a secondary risk level based on the secondary authentication data. In such embodiments, one or more of the authentication layers are designated as initial authentication layers and one or more of the remaining authentication layers are designated as secondary authentication layers. The identity decision server 106 can be configured to retrieve an initial set of authentication data according to the initial authentication layers and determine the result of each initial authentication layer based thereon. The identity decision server 106 can be configured to evaluate a preliminary risk level based on the results of one or more of the initial authentication layers and compare the preliminary risk level with a preliminary threshold to determine whether further authentication, such as through one or more secondary authentication layers, is required. According to some embodiments, the identity decision server 106 can be configured to request a secondary set of authentication data according to the secondary authentication layers if the preliminary risk level exceeds the preliminary threshold. The identity decision server 106 can determine or evaluate the secondary risk level of the transaction based on the secondary authentication data or, more specifically, the results of the secondary authentication layers. In such a case, the secondary risk level can represent the total risk level evaluated (212) for the transaction based on the authentication data. In a case where the preliminary risk level does not exceed the preliminary threshold, the preliminary risk level can represent the total risk level evaluated (212) for the transaction.

[0062] In one example embodiment, one or more of the initial authentication layers can include a passive authentication layer and / or a credential authentication layer, and the initial set of authentication data can include passive information and / or login information. And one or more of the secondary authentication layers can include a personal authentication layer, and the secondary set of authentication data can include PII or other personal information. According to an embodiment, the preliminary threshold can be at least one of a low risk level or a zero risk level. In some cases, the preliminary threshold can be a barrier that is higher than a predetermined threshold used to determine whether the authentication phase is satisfied. For example, the preliminary threshold can be a zero risk level and the predetermined threshold can be a low risk level.

[0063] Referring back Figure 2, Sequence 200 further includes: If the risk level of a transaction (also known as the total risk level) exceeds a predetermined threshold, then the identity authentication phase is initiated by selecting (214) at least one authentication check. According to an embodiment, the identity authentication phase includes a number of "checks" for testing the authenticity of the identity provided by user 108. As an example, the identity authentication check may include at least one of a knowledge-based authentication check based on information related to user 108, a one-time password check involving a unique password provided to user 108 through a channel selected by the user, or other types of authentication checks that will be obvious to those skilled in the art. In some embodiments, the type of authentication check selected (214) by the identity decision server 106 may depend on the risk level of the transaction. As an example, the identity authentication phase may be triggered in the presence of any risk associated with the transaction (e.g., a total risk level exceeding a zero risk level), but a one-time password check may be selected (214) for a transaction with a low risk level, a knowledge-based authentication check may be selected (214) for a transaction with a medium risk level, and both types of authentication checks may be selected (214) for a transaction with a high risk.

[0064] As Figure 2 illustrated, in some embodiments, the identity decision server 106 may be configured to generate (216) at least one authentication check selected (214) by the server 106. For example, the identity decision server 106 may generate a random password that will be used in a one-time password check. As another example, the identity decision server 106 may generate a series of questions that will be implemented as a knowledge-based authentication check, and may also generate corresponding answer keys for comparison with the answers provided by the user. According to an embodiment, the number and / or type of questions included in the knowledge-based authentication check may be determined by the transaction entity 110 and / or by the identity decision entity 114. In some embodiments, one or more identity authentication checks may be pre-generated by the identity decision server 106 and / or other computer devices and stored in the decision database 116 until requested for identity authentication. In some cases, only a portion of the pre-generated checks may be presented to user 108 depending on the number and / or type of questions required for the check. In other embodiments, the identity authentication checks may be generated automatically and in real time by the identity decision server 106 and / or other computer devices during the identity decision process.

[0065] As Figure 2As shown, in some embodiments, sequence 200 further includes the identity decision server 106 performing (218) at least one authentication check via the user device 102. In some cases, sequence 200 may also include displaying (220) at least one authentication check on the display of the user device 102 to perform (218) the check on the user 108. Sequence 200 further includes receiving (222) from the user 108 at the user device 102 (e.g., via an input device of the user device 102) a response to the authentication check, and providing (224) the user response from the user device 102 to the identity decision server 106.

[0066] Now referring to Figure 5 , an example knowledge-based authentication interface 506 presented by or within the second application window 404 according to an embodiment is shown. In the illustrated example, the authentication interface 506 presents a knowledge-based authentication check including a plurality of questions 508 and a plurality of selectable answers 510 for each question 508. As Figure 5 shown, the authentication interface 506 further includes a submission option 512 to enable the user 108 to submit or send the selected answer among the selectable answers 510 to the identity decision server 106.

[0067] According to an embodiment, the question 508 and / or the answer 510 can be generated by the identity decision server 106 and / or other computer devices using information about the user 108 collected from one or more data resources (e.g., the identity decision database 116, the transaction database 112, government-operated databases (such as vehicle registration databases), privately-operated databases (such as credit history databases), and / or any other database or data resource including user information). As an example, a knowledge-based authentication check can be generated based on the user's work experience (e.g., company name, employment dates, and other information related to current and / or past employers), financial and / or credit history (e.g., information related to mortgages, loans, bank accounts, investment accounts, credit card accounts, etc.), residential or housing history (e.g., location, dates of residence, and other information related to current and / or past residences), educational history (e.g., majors / minors, degrees, courses, graduation dates, enrollment dates, and other information related to the user's current and / or past educational institutions), vehicle history (e.g., manufacturer, model, year, and other information related to vehicles registered to the user), phone records (e.g., phone numbers of current and / or past landline and / or mobile phones), family history (e.g., names, ages, and other information related to the user's family members), social media history (e.g., information related to activities the user has engaged in using one or more social media accounts), web browsing history, and / or any other information about the user 108. It will be understood that Figure 5 (and Figure 6 ) The questions 508 and answers 510 shown in are merely exemplary, and any of several other types of questions and / or answers may be included in the knowledge-based authentication check.

[0068] In some cases, several of the questions 508 themselves may be pre-generated or "stock" questions that are typically included in a knowledge-based authentication check. However, the answer 510 for each stock question can be "personalized" or generated based on specific information known about the user 108. In such cases, the answer 510 can be generated in real time by the identity decision server 106 and / or other computer devices during the identity decision process. As an example, a knowledge-based authentication check with the same question 508: "Which of the following phone numbers have you previously used?" can be presented to each user 108, but the answer 510 presented by the interface 506 can be phone numbers specifically selected to include the correct answer for the user 108 and several incorrect answers that are (deceptively) similar to the correct answer.

[0069] According to an embodiment, the identity decision server 106 can be configured to perform or present one or more additional authentication checks after the initial authentication check is completed. For example, it can be performed when the user 108 fails to correctly answerFigure 5 providing an additional authentication check in the case of at least one of the problems 508 in the knowledge-based authentication check shown in Figure 7 and 8 . As another example, regardless of whether the user 108 passes the initial authentication check (for example, in the case where the transaction is associated with a high risk), one or more other authentication checks may be combined or an additional authentication check may be provided in addition to one or more other authentication checks. The additional authentication check may be of the same type as or a different type from the initial authentication check. In some embodiments, the type of the additional authentication check may depend on the result of the initial authentication check. For example, if the user 108 passes the initial authentication check, the additional authentication check may be a one-time password check (e.g., as shown in

[0070] Now refer to Figure 6 which shows an example additional authentication interface 606 presented by or within the second application window 404 according to some embodiments. In the illustrated example, the additional authentication interface 606 includes a knowledge-based authentication check that includes a single question 608 and multiple selectable answers 610. The additional authentication interface 606 may also include a submission option 612 to enable the user 108 to submit the selected answer among the selectable answers 610 to the identity decision server 106. In other embodiments, similar to the knowledge-based authentication check shown by the authentication interface 506 in Figure 5 , the additional knowledge-based authentication check may include multiple questions. In still other embodiments, instead of the knowledge-based authentication check, the additional authentication interface 606 may present another type of authentication check, for example, a one-time password check (e.g., as shown in Figure 7 and 8 ). As shown, the interface 606 may also include a second submission option 614 for the case where the user 108 does not meet the expected threshold required to pass the check or otherwise fails to meet a specific requirement to pass (e.g., select the correct answer 610). The second submission option 614 enables the user 108 to continue to have an additional means or opportunity to authenticate themselves if available.

[0071] Now refer to Figure 7 and 8, showing example one-time password interfaces 706 and 806 presented by or within the second application window 404 according to an embodiment. As illustrated, the one-time password interfaces 706 and 806 present different parts of a one-time password authentication check. For example, the one-time password interface 706 may implement (218) the first stage of the authentication check, which is configured to obtain or determine a preferred method for delivering a password associated with the authentication check to the user 108. And the one-time password interface 806 may implement (218) the second stage of the authentication check, which is configured to enable the user 108 to enter the password received via the preferred delivery method.

[0072] As Figure 7 shown, the authentication interface 706 presents multiple selectable delivery options 708 to the user 108 and requests the user 108 to select one of the options 708. The selected delivery option 708 is then sent to the identity decision server 106. The content of each of the delivery options 708 may be selected based on PII and / or other personal information obtained from the user 108 via the PII interface 406, stored in the identity decision database 116 and / or the transaction database 112 (e.g., existing account information), and / or collected from other sources containing information about the user 108 (e.g., credit reporting databases, insurance company databases, etc.). In the illustrated example, the delivery options 708 include delivery to a mobile phone number associated with the user 108 (e.g., via text, SMS, or voice message), delivery to an email address associated with the user 108 (e.g., via an electronic message), or "none of the above". As an example, if the displayed option 708 is inactive, inaccurate, or not the preferred delivery method (e.g., a deactivated phone number or a revoked email address), the user 108 may select the "none of the above" option. Selecting the "none of the above" option may cause the user device 102 to display a new interface (not shown) that displays additional delivery options 708 and / or data input fields for the user 108 to enter a specific email address or phone number.

[0073] After receiving option 708 selected by user 108 via authentication interface 706, identity decision server 106 can immediately generate a one-time password, or in some embodiments, obtain the password from another computer device configured to generate the password. The one-time password can include any combination of letters, numbers, and / or other characters. In some embodiments, the one-time password can be randomly generated such that the password is unique for each one-time password authentication check generated for the identity decision process. According to some embodiments, identity decision server 106 can request a one-time password from another computer device immediately after receiving the selected option in delivery option 708 via the one-time password interface 706, and send the received password to user 108 using the selected delivery option 708. In other embodiments, identity decision server 106 can instruct the other computer device to directly send the one-time password to user 108 using the selected delivery option 708.

[0074] As Figure 8 shown, authentication interface 806 includes a data input field 808 for enabling user 108 to enter the one-time password (also referred to herein as the "confirmation code") received via the selected delivery option 708. Authentication interface 806 further includes a submission option 812 for submitting or sending the entered password to identity decision server 106 for evaluation (e.g., according to Figure 2 the provide (224) interaction shown). Once user 108 selects submission option 812, the one-time password authentication check can be completed. As shown, interface 806 can also include a second submission option 814 for cases where user 108 does not meet the expected threshold required to pass the check or otherwise fails to meet a specific requirement to pass (e.g., enter the correct confirmation code). The second submission option 814 enables user 108 to continue to have additional means or opportunities to authenticate themselves if available.

[0075] As Figure 2As shown, sequence 200 further includes the identity decision server 106 determining (226) the result of at least one authentication check based on responses received from the user device 102 (e.g., via the knowledge-based authentication interface 506, additional authentication interface 606, and / or one-time password interface 806) associated with each check. In some cases, the identity decision server 106 may compare the user responses received from the user device 102 with the answer key for the authentication check to determine whether the user 108 has passed the authentication check. As an example, for a knowledge-based authentication check presented by the interface 506, the answer key may include the correct answer 510 for each of the questions 508. And for a one-time password check presented by the interfaces 706 and 806, the answer key may include the one-time password delivered to the selected delivery option 708. According to some embodiments, the result of at least one authentication check may determine whether an additional authentication check is necessary. For example, if the user 108 does not correctly answer one or more of the questions 508 of the knowledge-based authentication check presented by the interface 506, then the identity decision server 106 may decide to perform an additional authentication check, e.g., an additional Figure 6 knowledge-based authentication check shown in Figure 7 and 8 the one-time password check shown in.

[0076] According to an embodiment, sequence 200 additionally includes the identity decision server 106 determining (228) the overall identity decision result of the identity decision process. In some cases, the identity decision server 106 determines (228) the identity decision result based on the result determined (226) for at least one authentication check. For example, if the user 108 passes at least one authentication check, then the identity decision result may be a "success result", and if the user 108 fails the check, then the identity decision result may be a "failure result". In other cases, if the authentication phase is sufficient to confirm the identity of the user 108, then the identity decision server 106 determines (228) the identity decision result based on the result of the authentication phase. For example, if the user 108 passes the authentication phase, then the identity decision result may be a "success result".

[0077] According to some embodiments, sequence 200 further includes the identity decision server 106 reporting (230) the identity decision result to the transaction server 104. After receiving the identity decision result, the transaction server 104 immediately determines (232) whether to grant the user's transaction based on the received result. Once the determination (232) is made, the transaction server 104 provides (234) (or causes the user device 102 to display) a transaction status screen corresponding to whether the user's transaction is granted. In some cases, in addition to reporting (230) the result to the transaction server 104, the identity decision server 106 also provides (236) the identity decision result to the user device 102. In such cases, the identity decision server 106 may cause the user device 102 to display (238) the identity decision result on the display of the user device 102. In some cases, the display (238) may occur before or simultaneously with the transaction server 104 determining (232) whether to grant the user's transaction based on the identity decision result. And once the determination (232) is made, the displayed (238) result may be replaced by the transaction status screen provided (234) by the transaction server 104. In other cases, sequence 200 may end with the user device 102 displaying (238) the identity decision result instead of the transaction status screen provided by the transaction server 104. And if the result is a successful result, then the user 102 may continue the transaction initiated in the first application window 402, for example, by closing the second application window 404. In such cases, the transaction server 104 may cause the user device 102 to display a new interface (e.g., a transaction status screen) in the first application window 402.

[0078] Now refer to Figure 9 and 10, example decision status interfaces 906 and 1006 presented by or within the second application window 404 are shown according to some embodiments. As illustrated, once the identity decision server 106 has successfully confirmed the identity of the user 108, the decision status interface 906 can be presented to the user 108 via the user device 102. And if the identity decision server 106 is unable to confirm or verify the identity of the user, then the decision status interface 1006 can be presented to the user 108 via the user device 102. In some cases, the transaction server 104 can provide (234) the decision status interfaces 906 and / or 1006 as a transaction status screen immediately after determining (232) whether to permit the user to transact. In other cases, the identity decision server 106 can provide (236) the decision status interfaces 906 and / or 1006 to the user device 102 for displaying (238) the identity decision result thereon. According to some embodiments, the sequence 200 ends immediately after displaying either of the decision status interfaces 906 and 1006. Once the sequence 200 ends, the interaction between the identity decision entity 114 and the user 108 can also end.

[0079] As Figure 9 shown, the decision status interface 906 provides a celebration message 907 notifying the user 108 that the identity decision process has been successfully executed. The interface 906 further provides a confirmation code 908 and a copy code option 910 to enable the user 108 to copy the confirmation code 908 to a temporary storage location of the user device 102. The decision status interface 906 also includes an account access option 912 to enable the user 108 to access an account with the transaction entity 110. According to an embodiment, selecting the account access option 912 can cause the second application window 404 to close and can cause a new interface (not shown) to be presented within the first application window 402. The new interface can be associated with accessing the user's account (e.g., a new or existing account with the transaction entity 110), accessing an application or website (e.g., an application or website associated with the transaction entity 110), or otherwise completing the transaction that the user 108 initially requested (204).

[0080] According to an embodiment, the new interface may require an input of a confirmation code 908 to ensure that the person using the new interface is the same as the user 108 who successfully completed the identity decision process. In some embodiments, the confirmation code 908 may be similar to the one-time password and may be randomly generated by the identity decision server 106, the transaction server 104, and / or other computer devices. In some embodiments, the confirmation code aspect of the decision status interface 906 is presented only in certain predetermined situations (e.g., in the case where the identity authentication phase is not performed because the user 108 has passed the identity verification phase) as the final step of the identity decision process. In other embodiments, the decision status interface 906 may not include the confirmation code aspect at all and may instead include only the celebration message 907 and the access account option 912.

[0081] As Figure 10 shown, the decision status interface 1006 provides an error message 1007 notifying the user 108 that the transaction cannot be processed. Once the user 108 reaches the decision status interface 1006, the identity decision process may end, and the user 108 may not be granted access or permitted to complete the transaction initially requested (204) at the start of the sequence 200.

[0082] In some embodiments, an additional decision sequence (not shown) may be performed after completing the identity decision sequence 200 to complete the transaction with the transaction entity 110. For example, after verifying the identity of the user based on the sequence 200, the transaction entity 110 and the user 108 may enter a decision sequence related to, respectively, via the transaction server 104 and the user device 102: completing a purchase or otherwise obtaining a new product (e.g., a new credit card, a new debit card, etc.), selecting an appropriate product (e.g., an insurance policy, a medical insurance policy, etc.), obtaining sensitive or personal information (e.g., a credit rating report, financial records, insurance records, health records, educational records, etc.), completing an exam (e.g., a standardized test, an entrance exam or qualification exam, a professional exam, etc.), or otherwise conducting business with the transaction entity 110.

[0083] Now referring Figure 11 to Figure 11 FIG.

[0084] In an embodiment, the electronic device may be a server (e.g., identity decision server 106) associated with an identity decision entity (e.g., identity decision entity 114). It should be understood that the functionality of method 1100 may be implemented using an electronic device that executes an application and interfaces with a remote user device (e.g., user device 102) via a network connection (e.g., the Internet). In an embodiment, the application may be a dynamic decision application or a part thereof, and method 1100 may be a dynamic identity decision process. In some embodiments, the application may be a computer program stored on a non-transitory computer-readable medium executable by a processor of the electronic device. In some cases, the electronic device includes a memory for storing program code, the memory being communicatively coupled to the processor.

[0085] In some embodiments, at least a portion of the computer program may be executed by a processor of the remote user device. According to an embodiment, the user device may include a memory for storing a portion of the program code, a display for displaying an application window associated with the application and / or a third-party website, and / or one or more input devices for receiving input from the user or another electronic device. Further, each of the memory, the display, and / or the input device may be communicatively coupled to the processor. In an embodiment, the third-party website may be presented or displayed on the display of the user device in a first application window (e.g., as shown in Figure 3 ).

[0086] Method 1100 may begin at step 1102, where a request to confirm a user's identity is received from a third-party entity (e.g., transaction entity 110). In some embodiments, method 1100 further includes step 1104, where a secure connection is established between the server and at least one of a third-party server or the user device. The secure connection may be established using any of several known techniques for protecting communication between two or more network-connected devices (e.g., digital certificate exchange or key exchange), establishing tokens, etc. At step 1106, after receiving an identity confirmation request from the third-party server, the server may immediately cause the user device to display a second application window (e.g., window 404) for presenting the dynamic decision application. The second application window may be presented on top of or overlapping the first window without completely covering or closing the first application window (e.g., window 402) for presenting the third-party website. According to an embodiment, the second application window may be implemented as a "pop-up" window, an iFrame, or using any other known technique for presenting a second application window without closing the first application window.

[0087] In some embodiments, method 1100 further includes step 1108, which may initiate the authentication phase of the identity decision process. According to some embodiments, the authentication phase includes steps 1108, 1110, and 1112 of method 1100. At step 1108, authentication data is retrieved passively from the user device (e.g., by automatically retrieving information from the user device) or actively (e.g., by requesting the user to provide information via one or more data input interfaces associated with the dynamic decision application). As described herein, for example, the authentication data may include passive information such as device identification information and / or environmental information (e.g., location or timestamp information). As another example, the authentication data may include login information such as the username and password of a user account associated with the dynamic decision application, a transaction website, or other application / website. As yet another example, the authentication data may include personally identifiable information (PII) such as the user's full name, address, social security number, and other known types of personal information.

[0088] According to an embodiment, method 1100 further includes evaluating a risk level associated with a transaction based on, for example, the authentication data retrieved from the user device at step 1108. The risk level of the transaction may be selected from a list including two or more of the following: high risk level, medium risk level, low risk level, or zero risk level. It will be appreciated that other formats for representing the risk level may also be used.

[0089] Now refer to Figure 12 , the flowchart illustrates an example method 1200 for retrieving authentication data from a user device and evaluating a risk level associated with a transaction according to an embodiment. In some embodiments, method 1200 may be considered a sub-process included at or instead of steps 1108 and 1110 in method 1100. For example, method 1200 may represent a part of the authentication phase included in the identity decision process provided by method 1100, and the authentication phase further includes step 1112 of method 1100. In other embodiments, method 1200 may be an independent method for determining the risk level of a user transaction based on the authentication data retrieved from the user device. It should be understood that, as Figure 11 , Figure 12 depicted in the flowchart, the order of the steps may be in any order, and certain steps may be eliminated and / or certain other steps may be added depending on the implementation. In addition, method 1200 may be implemented in software, firmware, hardware, or any combination thereof.

[0090] In the illustrated embodiment, the authentication data includes initial authentication data and secondary authentication data, where the initial authentication data includes at least one of device information or login information, and the secondary authentication data includes personal identification information. At step 1202, the initial authentication data is automatically retrieved from the user device. At step 1204, a preliminary risk level of the user transaction is evaluated based on the initial authentication data. At step 1206, a determination is made as to whether the preliminary risk level exceeds a preliminary threshold. According to an embodiment, the preliminary risk level may be selected from a list including a high risk level, a medium risk level, a low risk level, and a zero risk level. Additionally, in some embodiments, the preliminary threshold may be the zero risk level.

[0091] If the determination at step 1206 is no (e.g., the preliminary risk level does not exceed the preliminary threshold), then method 1200 continues to step 1208. At step 1208, the preliminary risk level is assigned as or used as the total risk level of the transaction. For example, if the preliminary risk level evaluated at step 1204 is zero, then the determination at step 1206 will be "no", and at step 1208, the transaction will be assigned a total risk level of zero. Method 1200 may end after step 1208, and method 1100 may resume from step 1112.

[0092] If the determination at step 1206 is yes (e.g., the preliminary risk level exceeds the preliminary threshold), then method 1200 continues to step 1210. At step 1210, the secondary authentication data is specifically requested from the user, for example, through a verification interface (e.g., interface 406) for obtaining personal identification information displayed in a second application window. At step 1212, the total risk level of the transaction is determined based on the secondary authentication data. In some embodiments, the total risk level is selected from the same list as the preliminary risk level. Once the risk level is evaluated at step 1212, method 1200 may end and method 1100 may resume from step 1112.

[0093] Referring back Figure 11, at step 1112, a determination is made as to whether the risk level evaluated at step 1110 or the total risk level determined by method 1200 exceeds a predetermined threshold. According to an embodiment, the predetermined threshold may be at least one of a low risk level or a zero risk level. If the determination at step 1112 is yes (e.g., the risk level exceeds the predetermined threshold), then method 1100 proceeds to step 1114, where the authentication phase of the identity decision process begins. If the determination at step 1112 is no (e.g., the risk level does not exceed the predetermined threshold), then method 1100 proceeds to step 1124, which is discussed in more detail below. For example, if the predetermined threshold is a low risk level and the risk level determined at step 1110 is a low risk level, then the determination at step 1112 will be no, and method 1100 will proceed to step 1124. As another example, if the risk level is a high risk level, then the determination at step 1112 will be yes, and method 1100 will proceed to step 1114. In an embodiment, once step 1112 is completed, the authentication phase of the identity decision process may end.

[0094] At step 1114, at least one authentication check is selected to be presented to the user through a second application window. In an embodiment, the number and type of authentication checks are selected from a list of authentication checks based on the risk level determined at step 1110 or by method 1200. As described herein, the list of authentication checks may include knowledge-based authentication checks, one-time password checks, or any other type of authentication check. As an example, if the risk level determined at step 1110 is a high risk level, then at least two different authentication checks (e.g., a knowledge-based authentication check and a one-time password check) may be selected at step 1114. As another example, if the risk level is a medium risk level, then a knowledge-based authentication check may be selected at step 1114.

[0095] In some embodiments, method 1100 further includes, at step 1116, generating at least one authentication check based on information stored in a database (e.g., identity decision database 116). In other embodiments, the checks may be pre-generated and retrieved from the database as needed. In some embodiments, method 1100 includes step 1118, where at least one authentication check is provided to the user device for presentation in the second application window. As an example, the authentication check may be presented as a knowledge-based authentication interface (e.g., 506) or a one-time password interface (e.g., interfaces 706 and 806). Method 1100 may also include step 1120, where a user response to at least one authentication check is received from the user device, for example, through the interface provided at 1118.

[0096] At step 1122, a result is determined based on a user response to at least one authentication check. As described herein, the result can be a pass result if the user passes at least one authentication check or a fail result if the user fails the check. In some embodiments, method 1100 further includes, at step 1124, determining an identity decision result based on the result of at least one authentication check or, if the overall risk level of the transaction does not exceed a predetermined threshold at step 1112, based on the overall risk level. If the user passes the check or has an overall risk level that does not exceed the predetermined threshold, the identity decision result can be a success result. Additionally, if the user fails the check, the identity decision result can be a fail result. For example, if the overall risk level is a low risk level and the predetermined threshold is a zero risk level, then at step 1124 the low risk level is used to determine that the identity decision result is a success result. As another example, if the result of at least one authentication check is a fail result, then the identity decision result determined based on it will be a fail result.

[0097] At step 1126, the identity decision result is reported to a third-party server. If the result is a success result, the third-party website permits the user to complete the transaction. And if the result is a fail result, the third-party website blocks the user from completing the transaction. In some cases, the identity decision result can be presented to the user by an identity decision server, for example, through a decision status interface (e.g., interfaces 906 and 1006), via a second application window. In other cases, the third-party server can cause the second application window to close and return the user to the first application window on the third-party website to continue the transaction or report a failure result of the identity decision process. In an embodiment, method 1100 ends immediately after reporting the identity decision result.

[0098] Figure 13FIG. 1300 is a block diagram of a computing device 1300 that houses executable software for facilitating the system 100. One or more examples of the computing device 1300 may be utilized by, or for implementing, any, some, or all of the electronic devices in the networked system 100 (i.e., the user device 102, the transaction server 104, or the identity decision server 106, or any other computer or server associated with the system 100). Thus, the computing device 1300 may represent any computer utilized within or for implementing the system 100 and includes any type of computing device, including one or more dedicated or general-purpose digital computers such as mainframes, personal computers (desktop, laptop, tablet, or otherwise), workstations, minicomputers, computer networks, "virtual networks", "Internet cloud computing facilities", personal digital assistants, smart phones, or other handheld or mobile computing devices. In one embodiment, the computing device 1300 may be configured to exchange information with one or more components of the system 100 in accordance with the principles disclosed herein.

[0099] According to an embodiment, the computing device 1300 includes processing hardware 1302, and the processing hardware 1302 includes a memory 1304. As Figure 13 shown, the computing device 1300 also includes a processor 1306 communicatively coupled to the memory 1304 and an input and / or output (I / O) section 1308 communicatively coupled to the processor 1306. The computing device 1300 may further include an interactive hardware section 1310. The interactive hardware section 1310 is coupled to the I / O section 1308 such that commands or other inputs entered or provided by a user via the interactive hardware section 1310 will be forwarded to the I / O section 1308, the processor section 1306, and then to the memory section 1304.

[0100] As Figure 13 shown, the interactive hardware section 1310 may include one or more input devices 1312 for receiving input from a user or other source (e.g., keyboard, mouse, touch screen, microphone, stylus, radio frequency device reader, etc.), a display device 1314 for displaying content to the user on the computing device 1300, and / or a communication module 1316 including one or more transceivers and / or other devices for communicating with one or more networks (e.g., wide area networks including the Internet, local area networks, GPS networks, cellular networks, Bluetooth networks, etc.).

[0101] The processor 1306 can be a hardware device for executing software, particularly software stored in the memory 1304, some of which may or may not be unique to the system 100. The processor 1306 can be any custom or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computing device 1300, a semiconductor-based microprocessor (in the form of a microchip or chip set), another type of microprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: PA-RISC series microprocessors from Hewlett-Packard Company, 80x86 or Pentium series microprocessors from Intel Corporation, PowerPC microprocessors from IBM, Sparc microprocessors from Sun Microsystems, Inc., or 68xxx series microprocessors from Motorola Corporation. The processor 1306 can also represent a distributed processing architecture, such as, but not limited to, SQL, Smalltalk, APL, KLisp, Snobol, Developer 200, MUMPS / Magic.

[0102] The memory 1304 can include any one or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, hard disk drive, magnetic tape, CDROM, etc.). In addition, the memory 1304 can incorporate electronic, magnetic, optical, and / or other types of storage media. The memory 1304 can have a distributed architecture in which various components are placed far apart from each other but are still accessible by the processor 1306. The memory 1304 can store software containing one or more individual programs, the one or more individual programs including an ordered list of executable instructions for implementing logical functions.

[0103] When the computing device 1300 is in operation, the CPU portion 1306 may be configured to execute software stored in the memory 1304 to transfer data to and from the memory 1304 and generally control the operation of the computer 1300 in accordance with the software. In some embodiments, the memory 1304 includes non-transitory computer-readable media for implementing all or a portion of methods 1100 and 1200 and / or sequence 200. The memory portion 1304 may also be used to implement at least a portion of one or more databases utilized by the system 100. In one embodiment, the memory 1304 stores one or more executable computer programs, such as the dynamic decision application 1318, that may be executed by the computer processor 1306 to perform the principles disclosed herein (e.g., one or more of methods 1100 and 1200 and / or sequence 200). The executable program may be implemented in software, firmware, hardware, or a combination thereof.

[0104] According to some aspects, the memory 1304 also stores at least a portion of the database 1320. In one embodiment, the memory 1304 stores the database 1320 and the dynamic decision application 1318. In another embodiment, the database 1320 and the dynamic decision application 1318 are stored in different memories on different computers or servers. The database 1320 may contain information related to or used by the dynamic decision application 1318 to perform the principles disclosed herein. In this regard, the dynamic decision application 1318 may communicate with the database 1320 and extract information from or store information in the database 1320 as needed. According to some embodiments, the database 1320 may contain Figure 1 all or a portion of the identity decision database 116 and / or the transaction database 112 as shown in. In some embodiments, all or a portion of the database 1320, the identity decision database 116, and / or the transaction database 112 may be stored on a cloud server and may be accessed by the identity decision server 106, the transaction server 104, and / or any other computing device 1300 to perform the dynamic decision techniques disclosed herein.

[0105] Memory 1304 also includes an operating system 1322 for controlling the execution of other computer programs, such as dynamic decision application 1318, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. A non-exhaustive list of examples of suitable commercially available operating systems 1322 is as follows: (a) the Windows operating system available from Microsoft Corporation; (b) the Netware operating system available from Novell, Inc.; (c) the Macintosh operating system available from Apple Computer, Inc.; (d) the UNIX operating system available from many vendors, such as Hewlett-Packard Company, Sun Microsystems, Inc., and AT&T Corporation; (e) the LINUX operating system, which is free software that can be easily obtained on the Internet; (f) the Runtime Vxworks operating system from WindRiver Systems, Inc.; or (g) appliance-based operating systems, such as those implemented in handheld computers or personal digital assistants (PDAs) (e.g., PalmOS available from Palm Computing, Inc., Windows CE available from Microsoft Corporation, iOS available from Apple, Inc.).

[0106] The dynamic decision application 1318 can be a source program, an executable program (object code), a script, or any other entity that includes a set of instructions to be executed. When it is a "source" program, the program needs to be translated by a compiler, assembler, interpreter, etc., which may or may not be included in the memory 1304, in order to operate properly in conjunction with the operating system 1322. In addition, the operating system 1322 can be written in (a) an object-oriented programming language with data and method classes, or (b) a procedural programming language with routines, subroutines, and / or functions, such as, but not limited to, C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java,.Net, HTML, and Ada.

[0107] If the computing device 1300 is a PC, workstation, PDA, etc., the software in the memory 1304 may further include a basic input / output system (BIOS) ( Figure 13 not shown). The BIOS is a set of basic software routines that initialize and test the hardware at startup, start the operating system 1322, and support the transfer of data among hardware devices. The BIOS is stored in the ROM so that the BIOS can be executed when the computing device 1300 is activated.

[0108] When methods 1100 and 1200 are implemented in software, it should be noted that methods 1100 and 1200 can be stored on any computer-readable medium for use by or in conjunction with any computer-related system or method. Although in one preferred embodiment, methods 1100 and 1200 are implemented in a centralized application service provider arrangement. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or component that can contain or store a computer program for use by or in conjunction with a computer-related system or method. Methods 1100 and 1200 can be embodied in any type of computer-readable medium for use by or in conjunction with an instruction execution system, apparatus, or device (such as a computer-based system, a system containing a processor, or other systems that can retrieve and execute instructions from an instruction execution system, apparatus, or device). In the context of this document, a "computer-readable medium" can be any component that can store, transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. For example, a computer-readable medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, propagation medium, or any other device with similar functionality. More specific examples (non-exhaustive list) of computer-readable media will include the following: an electrical connection (electronic) having one or more wires, a portable computer disk (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that a computer-readable medium can even be paper or another suitable medium with a program printed thereon, because the program can be electronically captured via, for example, optical scanning of the paper or other medium, and then compiled, interpreted, or otherwise processed in a suitable manner and then stored in a computer memory.

[0109] In another embodiment, when methods 1100 and 1200 are implemented in hardware, methods 1100 and 1200 can also be implemented using any one or a combination of the following techniques well known in the art: discrete logic circuits having logic gates for performing logical functions on data signals, application-specific integrated circuits (ASICs) having appropriate combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), and so on.

[0110] Any process descriptions or boxes in the figures should be understood to represent code modules, segments, or portions that contain one or more executable instructions for implementing specific logical functions or steps in the process, and alternative implementations are included within the scope of the embodiments described herein. For example, functions may be performed in an order different from that shown or discussed (depending on the functionality involved, including substantially simultaneously or in the reverse order), as will be understood by one of ordinary skill in the art.

[0111] This disclosure is intended to illustrate how to make and use various embodiments in accordance with the present technology, rather than to limit its true, intended, and clear scope and spirit. The foregoing description is not intended to be exhaustive or limited to the precise form disclosed. Modifications and variations are possible in light of the above teachings. The embodiments were chosen and described to provide the best illustration of the principles of the described technology and its practical application, and to enable one of ordinary skill in the art to utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the embodiments as determined by the appended claims when interpreted in accordance with the breadth clearly, legally, and equitably granted, as may be amended during the pendency of this patent application and its full equivalents.

Claims

1. A method, comprising: receiving, by a computing device, from a third-party server, a request to confirm the identity of a user attempting a transaction via a third-party website, the third-party website being displayed in a first application window on the user's user device; causing the user device to display a second application window for an identity decision application, the second application window at least partially overlapping the first application window; determining, via the identity decision application, a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold: selecting an identity verification check from an identity verification checklist, wherein the selected identity verification check is selected from the list based on the type of the selected identity verification check corresponding to the risk level associated with the transaction; causing the user device to display the selected identity verification check via the second application window; determining a result of the selected identity verification check based on a user response to the selected identity verification check received via the second application window; and causing the user device to display a first identity decision result via the second application window based on the result of the selected identity verification check; if the risk level is less than the predetermined threshold: causing the user device to display a second identity decision result based on the risk level associated with the transaction.

2. The method according to claim 1, further comprising sending at least one of the first identity decision result or the second identity decision result to the third-party server.

3. The method according to claim 1, wherein the third-party website permits or blocks the transaction based on at least one of the first identity decision result or the second identity decision result.

4. The method according to claim 1, wherein the risk level associated with the transaction is selected from a list comprising two or more of the following: high risk level, medium risk level, low risk level, or zero risk level, and the predetermined threshold is the lowest risk level in the list.

5. The method according to claim 1, wherein the selected identity verification check is generated based on historical data associated with the user.

6. The method according to claim 1, wherein the identity verification checklist includes at least one of a knowledge-based verification check and a one-time password check.

7. The method according to claim 1, wherein when the risk level is a high risk level, the identity verification check includes at least two different identity verification checks.

8. The method according to claim 7, wherein the at least two different identity verification checks are displayed via the identity decision application.

9. The method according to claim 1, wherein the authentication data includes at least one of passive information, login information, or personal identification information.

10. The method according to claim 9, wherein the login information includes a username and a password associated with the identity decision application, and the login information is received via the identity decision application.

11. The method according to claim 9, wherein the passive information includes device identification information associated with the user device retrieved from the user device.

12. The method according to claim 9, wherein the passive information includes environmental parameters associated with the transaction retrieved from the user device, and the environmental parameters include at least one of a timestamp associated with the start of the transaction or the location of the user device.

13. The method according to claim 9, wherein the personal identification information includes at least one of a full name, an address, or a social security number.

14. The method according to claim 1, wherein the authentication data includes first authentication data and second authentication data, and the determining the risk level associated with the transaction further includes: retrieving the first authentication data from the user device; determining a preliminary risk level of the transaction based on the first authentication data; requesting the second authentication data from the user via the identity decision application based on the preliminary risk level exceeding a preliminary threshold; determining the risk level associated with the transaction based on the second authentication data.

15. The method according to claim 14, wherein the first authentication data includes at least one of device identification information and login information, or the second authentication data includes personal identification information.

16. The method according to claim 14, wherein the preliminary threshold is a zero risk level.

17. A system, comprising: one or more memories; at least one processor, each processor coupled to at least one of the memories and configured to perform the following operations: receiving, from a third-party server, a request to confirm the identity of a user attempting to conduct a transaction through a third-party website, the third-party website being displayed in a first application window on the user's user device; causing the user device to display a second application window for an identity decision application, the second application window at least partially overlapping the first application window; determining, via the identity decision application, a risk level associated with the transaction based on authentication data retrieved from the user device; if the risk level exceeds a predetermined threshold: selecting an identity authentication check from an identity authentication checklist, wherein the selected identity authentication check is selected from the list based on the type of the selected identity authentication check corresponding to the risk level associated with the transaction; causing the user device to display the selected identity authentication check via the second application window; determining a result of the selected identity authentication check based on a user response to the selected identity authentication check received via the second application window; and causing the user device to display a first identity decision result via the second application window based on the result of the selected identity authentication check. If the risk level is less than the predetermined threshold: Cause the user device to display a second identity decision result based on the risk level associated with the transaction.

18. The system according to claim 17, wherein the operation further comprises sending at least one of the first identity decision result or the second identity decision result to the third-party server.

19. The system according to claim 17, wherein the third-party website permits or blocks the transaction based on at least one of the first identity decision result or the second identity decision result.

20. The system according to claim 17, wherein the authentication data comprises first authentication data and second authentication data, and determining the risk level associated with the transaction further comprises: Retrieving the first authentication data from the user device; Determining a preliminary risk level of the transaction based on the first authentication data; Requesting the second authentication data from the user via the identity decision application based on the preliminary risk level exceeding a preliminary threshold; and Determining the risk level associated with the transaction based on the second authentication data.

21. The system according to claim 17, wherein the operation further comprises: Establish a secure connection with at least one of the third-party server or the user device before causing the user device to display the second application window.

22. A non-transitory computer-readable medium having computer instructions stored thereon, which when executed by at least one computing device, cause the at least one computing device to perform the following operations: Receive, from a third-party server, a request to confirm the identity of a user attempting to conduct a transaction through a third-party website, the third-party website being displayed in a first application window on the user's user device; Cause the user device to display a second application window for an identity decision application, the second application window at least partially overlapping the first application window; Evaluate, via the identity decision application, a risk level associated with the transaction based on authentication data retrieved from the user device; If the risk level exceeds a predetermined threshold: Select an identity authentication check from an identity authentication checklist, wherein the selected identity authentication check is selected from the list based on the type of the selected identity authentication check corresponding to the risk level associated with the transaction; Cause the user device to display the selected identity authentication check via the second application window; Determine a result of the selected identity authentication check based on a user response to the selected identity authentication check received via the second application window, and Cause the user device to display a first identity decision result via the second application window based on the result of the selected identity authentication check; If the risk level is less than the predetermined threshold: Cause the user device to display a second identity decision result based on the risk level associated with the transaction.

Images