DIGITAL TRUST SYSTEM, COMPUTER-READABLE MEDIUM, COMPUTERIZED METHOD
Patent Information
- Application Number
- BR112019017075
- Authority / Receiving Office
- BR · BR
- Patent Type
- Patents
- Current Assignee / Owner
- Publication Date
- 2026-09-08
Smart Images

Figure 00000071_0000 
Figure 00000072_0000 
Figure 00000073_0000
Abstract
Description
1 / 61 “PARTNERSHIP SYSTEM, COMPUTER-READABLE MEDIA AND COMPUTERIZED METHOD” Priority Claim
[001] This application claims priority to US patent application 62 / 460,611 filed on February 17, 2017, the entire content of which is incorporated herein by reference. Field of Invention
[002]
[0001] The present invention relates to computer systems and computer-implemented methods for identity authentication for use by financial institutions based on device profile and biometrics to enable a mobile device to be used as a proxy for user authentication with high credential confidence.
[003] Consumers and businesses have adopted the use of online digital interaction channels in financial, commercial, and transaction-related activities. As a result, accurate and secure authentication and the protection of their personal personally identifiable information (PII) is a critical responsibility for all financial institutions and retailers. However, current digital authentication methods have significant weaknesses and pose security threats that put individuals, businesses, and government entities at risk.
[004] In addition to the risks of interception of this information, banks, financial institutions, and other entities have encountered resistance during the user authentication process via mobile phones and other computing devices, which is one of the main causes of transaction or process abandonment. Furthermore, since no holistic view of the consumer's specific activity is available, losses due to fraud can occur between different institutions without the sharing of information or transactional context. In addition, increased risks and costs are Petition 870250100007, dated 10 / 31 / 2025, page 17 / 98 2 / 61 associated with redundant and / or manual data capture, including captures associated with multiple records and logins for different websites, applications, and other online entry points.
[005] For consumers, resistance during the authentication process can be inconvenient and frustrating. Users may feel apprehensive about repeatedly sharing personal information across multiple websites and applications. Furthermore, fatigue arises from managing multiple passwords as the basis for authentication across different systems. Alternatively, using the same password across multiple systems increases the chance that a single interception could result in catastrophic access to account information by offenders. Description of the Invention
[006] The present invention involves computer-implemented systems, software, and methods for identity authentication across multiple financial institutions using a single trusted mobile device as a proxy for user login, while allowing a high level of trust in authentication processes based on the trusted mobile device and an assessment of existing institutional knowledge regarding the user and predictive analysis to verify the need for authentications and identity for additional checks and authorizations. In one example, system operations include identifying a request to trust a specific user, the specific user associated with a first trust relationship with a first entity, the first entity associated with the digital ID network.A set of personally identifiable information (PII) associated with the specific user is obtained through the first entity, and an identity verification (IDV) and fraud risk assessment analysis of the user is performed based on the obtained PII set. In response to satisfy the IDV fraud risk assessment analysis, the following instructions are given. Petition 870250100007, dated 10 / 31 / 2025, page 18 / 98 3 / 61 transmitted to the specific user to verify the identity of the specific user through a trusted mobile application installed on a mobile device associated with the specific user. In response to the verification of the specific user's identity through the trusted mobile application installed on the mobile device, the mobile device is linked to the specific user within the digital ID network, where the mobile device is associated with a unique set of device information, and the unique set of device information is incorporated into a generated digital ID associated with the specific user, where the generated digital ID is available for use by a plurality of entities registered in the digital ID network for authentication of the specific user.
[007] In some embodiments, the generated digital ID associated with the specific user comprises a unique key created to associate the specific user's PII, where the mobile device was associated with the specific user and activities associated with the user.
[008] In some embodiments, in response to satisfying IDV and fraud risk assessment analysis, a unique code associated with the specific user is generated, and the transmission of instructions to the specific user to verify the identity of the specific user through the trusted mobile application may include transmitting the generated unique code to a first-entity interface with instructions for the specific user, where the identity of the specific user is verified through the trusted mobile application by verifying the unique code transmitted with instructions for the specific user.In these cases, generating the unique code may include generating an image that encodes the unique code associated with the specific user, and transmitting the unique code to the first entity's interface may include transmitting the generated image to the first entity's interface, where instructions are given to the specific user to verify the identity of that specific user through the... Petition 870250100007, dated 10 / 31 / 2025, page 19 / 98 4 / 61 The trusted mobile application includes instructions for capturing the image transmitted through the trusted mobile application. Verifying the identity of the specific user may include confirming that the image captured by the trusted mobile application matches the generated image that encodes the unique code associated with the specific user.
[009] In some embodiments, the first trust relationship between the first entity and the specific user is based on a predefined record and authentication of the specific user by the first entity.
[010] In some embodiments, the specific user fraud risk assessment includes at least one of the following: knowledge-based authentication, cross-channel comparison, out-of-band authentication, known fraud exchange assessment, PII usage speed analysis, transaction speed analysis for the specific user, transaction data analysis, biometric analysis, comparison of the specific user's PII against a set of known PII associated with a fraud risk, and device reputation analysis.
[011] In some embodiments, each entity in the plurality of entities is associated with a set of entity-specific authentication rules, each set of entity-specific authentication rules identifies a set of transactions for a specific entity and identifies a level of authentication required by users associated with the transactions. In these cases, at least some of the transactions for a specific entity require at least one additional first authentication operation for users associated with those transactions, wherein at least one additional first authentication operation comprises an initial authentication request to be transmitted from the digital trust system to a specific mobile device previously linked to the digital ID. Petition 870250100007, dated 10 / 31 / 2025, page 20 / 98 5 / 61 associated with the specific transaction. The digital trust system is still configured to transmit the first authentication request to the trusted mobile application installed on the specific mobile device, where the first authentication request is presented through the trusted mobile application.
[012] In some of these embodiments, the first additional authentication request may comprise a request for biometric input from the user associated with the digital ID via the trusted mobile application. Alternatively or additionally, the first additional authentication request comprises a request for a response via user input to an authentication challenge.
[013] In some embodiments, where the first authentication request is required, operations may still include receiving a response to the first authentication request transmitted from the trusted mobile application installed on the specific mobile device and validating the received response. In response to a valid response to the first authentication request, the transaction may be authorized, although transaction authorization may be denied in response to an invalid response to the first authentication request. In some embodiments, a fraud detection assessment is performed on each requested transaction associated with the digital ID, where the fraud detection assessment is performed for each user transaction request when associated with the digital ID.
[014] In these cases, in response to a potential fraud detection based on the fraud detection assessment, at least one additional second authentication request may be made, wherein at least one additional second authentication request comprises a second authentication request to be transmitted from the digital trust system to a specific mobile device previously linked to the digital ID. Petition 870250100007, dated 10 / 31 / 2025, page 21 / 98 6 / 61 associated with the specific transaction, where the digital trust system is configured to transmit the second authentication request to the trusted mobile application installed on the specific mobile device, the second authentication request is presented through the trusted mobile application. At least one additional second authentication request associated with the detection of potential fraud can be made without a determination that at least one additional first authentication request is required.
[015] Although generally described as computer-implemented software embedded in tangible media that processes and transforms the respective data, some or all aspects may be computer-implemented methods or even included in the respective systems or other devices to perform this described functionality. Details of these and other aspects and embodiments of the present invention are presented in the accompanying Figures and in the description below. Other features, objects and advantages of the invention will be evident from the description and figures, and from the claims. Brief Description of the Figures
[016] Figure 1 is a block diagram illustrating an example system for implementing a digital ID network across a plurality of consumers and clients.
[017] Figure 2 is an example diagram of a simplified system for providing a digital ID network.
[018] Figure 3 is a flowchart of an example registration operation from the perspective of the partnership system.
[019] Figure 4 is a flowchart of an example operation to perform additional authentication operations between the partner system and a trusted mobile application from the perspective of the system. Petition 870250100007, dated 10 / 31 / 2025, page 22 / 98 7 / 61 parceria. Description of Embodiments of the Invention
[020] The present invention describes systems and methods for identity authentication across multiple authentication entities, for example, financial institutions using a single trusted mobile device as a proxy for user login. Specifically, a combination of layer-based and analytics-based authentication technology is used to enhance the user experience during digital transactions, while also ensuring that appropriate levels of authentication are received for important or potentially fraudulent activities.
[021] In the present description, several parties may be involved in the authentication process. For the purposes of this description, the phrases “consumer”, “client”, and “partnership” may be used, with each acting as a separate party to the process: • The “consumer” may be a user or customer of a bank, financial institution, or other entity whose mobile device may be digitally linked to personally identifiable information (PII) associated with the user; • The “client” can be a bank or financial institution, as well as any other company, business, or individual that uses a partnership system to manage and authenticate users / clients associated with activities that occur in association with the client. For example, the “client” could be a bank, a store with a digital storefront, a web-based shopping site, or any other suitable system that requires validation and authentication of users accessing the system; • The “partnership” represents a back-end system capable of authenticating individual users and their mobile devices in order to authenticate specific users in a centralized and uniform manner, particularly Petition 870250100007, dated 10 / 31 / 2025, page 23 / 98 8 / 61 based on linked mobile devices.
[022] The solutions described in this application provide clients (e.g., banks and other authenticating entities) with a more precise level of fraud risk on a set of universal and shared information about a specific user and their mobile device. Furthermore, authentication techniques can be defined and applied based on the type of transaction to be performed, thus allowing clients the ability to request additional or more specific information from consumers in situations where the action being performed or requested by the consumer is determined to require additional authentication to allow a higher level of trust and / or identity assurance, or when a greater possibility of potential fraud is present and, moreover, trust is useful.Additional authentication factors may include, for example, one-time pass codes, biometric entry and verification, push notifications, and other suitable factors. Advanced analytics and network insights (e.g., consumer information from one or more additional or alternative sources) can be used as additional verification and fraud detection input or consideration information, providing an additional layer of analytics and input for the system's authentication operations.
[023] Similarly, consumers are associated with a complete application (one-stop application) and a shared digital identity that can be used across multiple entities to securely interact with the consumer's credentials and PII, reducing the number and extent of information sharing required to authenticate the consumer, while also speeding up specific transactions that were previously slowed down by manual login techniques. In many cases and scenarios, consumers may no longer need to share or provide Petition 870250100007, dated 10 / 31 / 2025, page 24 / 98 9 / 61 your PII with individual entities after initial registration, reducing potential weaknesses in identity protection.
[024] The present invention provides a universal consumer digital ID, which can be used as a secure digital credential of the consumer's identity. Instead of being based solely on something the consumer knows (e.g., knowledge-based authentications and ID / password combinations), the digital ID represents a virtual connection between the consumer and their device. In one example, the digital ID represents a combination of several authentication techniques that may encompass three common authentication techniques: (1) what you know, (2) what you have, and (3) what you are. Once the digital ID is connected to the specific consumer, the digital ID can be passively verified and confirmed through participating businesses and government entities that also know and interact with the consumer linked to the digital ID.This combination of clients (e.g., these companies and government entities) associated with the partnership system that provides the digital ID can be cited as a digital network ID, where interconnectivity and corroboration of perception between the parties allows for highly accurate and passive trust elevation.
[025] In some events, such as those identified as low-risk (e.g., by the customer), consumers may be able to access specific participating systems using their mobile device alone without interactions, unlike current systems. However, when a high-risk situation is detected in association with a digital ID exchange, or when a high-risk or high-importance transaction requires additional guarantees and / or greater security before authorization, the digital ID and the consumer linked to their mobile device may allow companies or government entities to securely interact with the consumer through the digital channel via a dedicated trusted mobile application. Petition 870250100007, dated 10 / 31 / 2025, page 25 / 98 10 / 61 Using a dedicated trusted mobile application, the client and / or partner system can request and receive additional information or data (e.g., a knowledge-based question, biometric data entry, etc.) that can be used to perform additional authentication operations. The ability to conditionally invoke this interaction through a secure and protected channel based on the type of transaction or interaction attempt, or based on the particularities of the transactions or interactions themselves, including those based on customized or specific rules by clients associated with the system, complements the robust risk assessment behind the scenes, based on the comprehensive and shared insight provided by information across multiple participating entities.
[026] In addition to providing customers with significant benefits, digital ID and support procedures can enable consumers to manage, monitor and control the use of their digital ID and enable the digital ID to be universally accepted and used by participating entities with whom they choose to share it.
[027] The advantages of the process and system described are numerous. Existing online authentication is enhanced by simplifying the online user experience through digitally linked mobile devices that are used to assist in verifying and authenticating the consumer to any participating system associated with the digital ID network. Furthermore, based on the type of transaction to be performed, the specifications of the specific transaction to be performed, and / or other potential fraud predictors, enhanced security levels and additional authentications can be triggered and provided through a digital channel to a single location (i.e., the trusted mobile application), where the consumer can securely provide additional information to meet the elevated security requirement. Digital ID allows the identity of the subject (i.e., the consumer) to be actively and Petition 870250100007, dated 10 / 31 / 2025, page 26 / 98 11 / 61 passively becomes part of the authentication process, so that the feedback loop of the security framework allows for faster and more accurate detection of suspicious activity and fraud. Furthermore, the digital ecosystem allows participating entities to trust the provided digital ID as a true proxy for the consumer (and their identity) with whom the entities are interacting, providing an enhanced level of trust in each transaction conducted in conjunction with the digital ID.
[028] Although authentication capabilities exist that link the device and send notifications, the primary use of these techniques is by individual customers in isolation. The current solution uses the network of participating customer consortia and information collected in the partnership system, as well as additional data from available third parties, when available, to create a highly informed and federated identity network that is reinforced by shared information and understanding between entities. The network allows the use of signals, insights, and feedback mechanisms from past and present actions, as well as an analysis of similar consumers, to more accurately detect fraud and / or conditions that require more authentication interactions.
[029] In order to take advantage of the federated digital ID network, consumers may be directed to register on the network by one or more client websites or applications when a consumer is not previously registered. Specifically, client websites or applications may offer links to a registration interface for the back-end partner system, allowing the consumer to register and be associated with a trusted digital ID. The signup / registration process may be used in conjunction with the user's mobile device (e.g., a phone, tablet, etc.) to complete the registration process.
[030] First, the consumer can select the option Petition 870250100007, dated 10 / 31 / 2025, page 27 / 98 12 / 61 to register with the partnership system. To do this, a trusted mobile application (e.g., different from the consumer's browser and a client's mobile application or website) provided or associated with the partnership system may be made available to the user, so that the user can download and install the trusted mobile application. The consumer may enter a set of personally identifiable information (PII) in a registration area of the client's website or application, where this information is then passed back to the partnership system and associated with the consumer.
[031] In response to receiving the consumer's PII, the partner system may perform a secure set of ID checks (“IDV”) upon the user's PII, including accessing and leveraging various industry-standard PII confirmations and assessments. Simultaneously, or around this, or in conjunction with the verification, a set of fraud risk assessments may be performed for the consumer, where fraud risk assessment operations may identify and store information within the partner system about the relative risk and / or fraud associated with the consumer.In some embodiments, consumers determined to be associated with factors indicating potential and / or significant fraud risks, including but not limited to consumers using tethered mobile devices that are not located near the actual device used to access the banking website / application, multiple consumers associated with the same government ID or using a common device, a single consumer identity being used across multiple banking websites simultaneously, or those whose identity cannot be verified through normal means, may not be permitted to create a digital ID as described in this application. Fraud risk assessments that may cause a consumer to be disqualified may include an unusual volume of interactions across the network for a specific PII or device. Petition 870250100007, dated 10 / 31 / 2025, page 28 / 98 13 / 61 mobile, an unusual combination of previous interactions (e.g., address change combined with a new device registration), a high volume of rejected transactions, previous data associated with the provided PII identified as a relatively high risk, a low volume or knowledge set of PII information, a device signature mismatch (e.g., primary and secondary channel signature mismatches), and sets of mismatches of provided PII information compared to carrier PII information, as well as any other appropriate assessment and / or determination.
[032] Once the consumer passes the initial IDV and risk criteria checks, the partner system can generate a unique code and send the unique code and / or a representation of the unique code (e.g., a QR code (or “Quick Response”)) to the client’s website or mobile application (when appropriate), where the underlying unique code is specifically associated with the consumer performing the registration process. The representation of the unique code can uniquely encode information used to verify the consumer and the consumer’s mobile device. The purpose of the unique code representation, such as a QR code, is to bridge trust between channels in an out-of-band manner. The trust of the primary channel (e.g., an online banking session where the device user has already logged in) is inferred or transferred to the consumer’s mobile device via the unique code.In some embodiments, the unique code may be provided without encoding (e.g., as a string of characters). To complete the linking of the mobile device to the consumer, the consumer may be asked to take a photo of the representation of the unique code (e.g., the QR code) or the exact unique code (e.g., when the unique code is provided directly without encoding) via the downloaded trusted mobile application. The photo can be taken as... Petition 870250100007, dated 10 / 31 / 2025, page 29 / 98 14 / 61 A screenshot (if captured on or by the mobile device), a photo taken of a desktop system by the mobile device (and stored in the device's photo library), or any other suitable method. The photo of the unique code can then be presented by the trusted mobile application to the partner system and verified / authenticated. Other methods for entering the unique code, except through the use of the device's camera, may be used alternatively. Once the photo or entry of or associated with the unique code is captured, the trusted mobile application is used to link the consumer's PII and other information with a set of mobile device-specific information to create the consumer's digital ID for use in future systems.
[033] In general, a digital ID can take the form of an alphanumeric code (or other suitable identifier) that represents a specific consumer record or consumer profile that combines a specific consumer PII (e.g., name, address, date of birth, and / or social security number (SSN), etc.) with a phone number, email address, biometric pattern of the consumer's fingerprint or iris, and / or other unique identifier (e.g., a unique username), etc., and device data (e.g., IP address and other identifiers and / or data associated with and / or related to the device, etc.). In some embodiments, the digital ID may be a combination of these values, a unique identifier that links, includes, or is associated with the set of information.Once registered, the digital ID can be considered or treated as a primary digital ID used by the partner system to uniquely identify the specific consumer, in combination with the consumer's device in interactions with the trusted mobile device and throughout the trusted network. In addition to the primary digital ID, each customer may have a unique, customer-specific digital ID generated by them, where customer-specific digital IDs are used by various partners. Petition 870250100007, dated 10 / 31 / 2025, page 30 / 98 15 / 61 Client systems interact with the partner system, avoiding potential problems that can arise when one or more clients are compromised. In other words, the digital ID represents a unique identifier or key created to restrict individual consumer PII, device, and activities collectively, allowing consumers to be identified without the actual PII being transferred. The client retains control over decisions and execution related to the use of the client-specific digital ID and the information and accounts associated with that digital ID. For example, how the client configures or implements the solution is managed by the client, allowing clients to configure the solution as they see fit for internal operations.Additional participating entities associated with the partnership system may also use a link to the main digital ID, in the form of an entity-specific digital ID, in some realizations, provided by the partnership system, for future transactions by registering with the partnership system and sharing customer-specific account information as linked to the main digital ID.
[034] The partnership system and the trusted mobile application use data about the consumer's interaction with a specific digital interface of the client's systems (e.g., mobile applications, websites, other suitable entry points), combined with data about the registered mobile device (e.g., geographic location, installed software, etc.) to authenticate the consumer. In addition to this authentication, further analysis of the consumer may occur within the partnership system to assess the type of transaction the consumer is undertaking in connection with (1) one or more evaluation rules, which may be configured or selected by the client, and / or (2) indicators of potential fraud. Depending on the type of transaction and the results of the further analysis, the partnership system may determine whether additional degrees of resistance or Petition 870250100007, dated 10 / 31 / 2025, page 31 / 98 16 / 61 interactions are required by the consumer before authorizing the requested transaction based on specific customer evaluation rules and potential fraud indicators.
[035] In general, the solution can allow customers to implement context-based adaptive authentication. Typically, security is placed at the website entrance or at a location before allowing access to the data being protected. After successfully authorizing access (e.g., after using obtained credentials or otherwise overcoming security measures), potentially malicious users may be free to operate and interact with the compromised system and / or data. With the present solution, adaptive authentication is provided to require varying levels of security as needed or based on context. Several example transactional experiences are provided in this document, although any number of experiences may be considered and included in the present invention; • A consumer attempts to log in to a client's website. In response to the login attempt, the partner system sends a message to the consumer (via the trusted mobile application) to verify if he or she is attempting to log in to the account on the client's website. The consumer can select "yes" or "no" in response before the login is accepted and authorized; • A consumer logs into a client website on a desktop computer or system different from their mobile device. The partner system evaluates the digital information on the website and the mobile device's location information (and any other relevant information) to determine if the mobile device is physically near the consumer. If so, the partner system allows and approves a consumer login without further consumer interaction; Petition 870250100007, dated 10 / 31 / 2025, page 32 / 98 17 / 61 • A consumer logs into a client's website and initiates a transaction, where the customer is associated with a security / elevated authorization rule defined by the client for transactions over the specific amount. The partner system identifies the transaction and applies the rule defined by the client, forcing a request to the consumer's mobile device to obtain additional authentication, such as a biometric data request (e.g., a fingerprint or voice analysis) or an ID authentication questionnaire. If the additional ID authentication request is approved, the transaction request is authorized by the partner system, and the transaction can then be approved and completed on the website and systems subject to normal approval; • A fraudster gains possession of the consumer's mobile device and the code to unlock the device. While in possession, the criminal attempts to log into the customer's website using the consumer's mobile device while outside a traditional location associated with previous logins, as monitored or known by the partner system. The partner system evaluates the incoming request and website information associated with the login and determines that the login request originates outside the consumer's usual location interaction area (e.g., outside the consumer's country of residence, outside a city typically associated with the consumer's location, etc.). In response, the partner system may send a message to the consumer via the trusted mobile application requesting authorization for the login.Because the consumer is not the one requesting the login, the partner system may require additional authentication through the trusted mobile application, such as a password, question / answer challenge, or biometric information, where the fraudster would not be able to provide the additional requirements to authenticate the consumer. Petition 870250100007, dated 10 / 31 / 2025, page 33 / 98 18 / 61 success.
[036] While these are four examples of potential scenarios, it is noted that the types of activities associated with high security and authentication requests with the partner system can be actively managed, so that any particular interaction with the client's systems may be associated with relatively higher and / or lower levels of authentication, as identified by the client and / or the partner system. Additionally, in situations where the partner system identifies a potential fraudulent attempt outside the defined authentication requirements and regardless of the specific activity, additional authorization interactions may be generated or initiated by the partner system to stop potentially fraudulent access to any specific data, regardless of whether the specific activity or interaction is associated with a high or low level of authentication-related action.
[037] The system described, therefore, uses a combination of authentication methodologies and technologies, including analysis and modeling of individual and cohort-based considerations to bring a holistic view of the consumer. This holistic understanding of the consumer, from data about the device, the interface with client systems, and activity in relation to the consumer's current and historical activities across the digital ID network, among others, provides a unique and innovative solution for companies, government organizations, and other entities.
[038] Returning to the illustrated implementation, Figure 1 is a block diagram illustrating an example system (100) for implementing a digital ID network through a plurality of consumers (also referred to as “users”) and clients. As illustrated in Figure 1, the system (100) is a client-server and client-device system capable of sharing and communicating information through a set of devices (e.g., a Petition 870250100007, dated 10 / 31 / 2025, page 34 / 98 19 / 61 or more mobile devices (101), one or more clients (130) and a partner system (160) through the network (120)). In the present illustration, one or more partner systems (160) may provide the digital ID network, where one or more clients (e.g., businesses and / or government entities) conduct transactions with one or more consumers or users associated with specific mobile devices (101). Although components are shown individually, in some implementations, the functionality of two or more components, systems, or servers may be provided by a single component, system, or server. The partner system (160) provides consensus-based authentication, where multiple relatively small data points can represent a larger picture rather than relying solely on knowledge factors.Furthermore, data points can extend across different partners in the network of participants associated with the partnership system (160), including information related to an unusual volume of interactions across the network for a given set of PII and / or device (e.g., an address change combined with a new device registration), a high volume of rejected transactions associated with one or more systems associated with the partnership system (160), a set of previously identified data that identifies the PII as a high potential risk, a relatively low volume of knowledge associated with PII information, or a device signature mismatch (e.g., failure to match primary and secondary signatures), among others.
[039] As used in the present invention, the term “computer” is intended to encompass any suitable processing device. For example, both the client system (130) and the partner system (160) can be any computer or processing device such as, for example, one or more servers, blade servers, personal computers for Petition 870250100007, dated 10 / 31 / 2025, page 35 / 98 20 / 61 general purpose (PC), Mac®, workstations, UNIX-based workstations, or any other suitable devices. Furthermore, although Figure 1 illustrates a single partnership system (160), the partnership system (160) can be implemented with two or more systems, as well as computers, except servers, including a server group. In other words, the present invention contemplates computers, except general purpose computers, as well as computers without conventional operating systems. Similarly, the mobile device (101) can be any system that can be linked to the user associated with it, and may include a mobile device, a tablet, a smartwatch, or any other suitable mobile computing device specifically associated and linked to the specific user registered on the digital ID network. In some embodiments, non-mobile devices, if suitable, can be associated and linked to a specific digital ID.Furthermore, although not shown, one or more additional systems may also be used by the user to access specific client systems (130). In such cases, interactions between the user and the client systems (130) may be performed by other computers, including desktop computers, other mobile devices, and any other suitable computer. The partner system (160) may analyze the presented digital ID and determine if and how additional interactions with the mobile device (101) may be necessary to fully authenticate the user. In general, each illustrated component may be adapted to run any suitable operating system, including Linux, UNIX, Windows, Mac OS®, Java™, Android™, Windows Phone OS, or iOS™, among others. In some embodiments, two or more separate partner systems (160) may also be provided.
[040] In general, the mobile device (101) is used as a specific device linked to a specific user, whose digital ID is used Petition 870250100007, dated 10 / 31 / 2025, page 36 / 98 21 / 61 within the digital ID network provided by the partnership system (160). The mobile device (101) comprises an operable electronic computing device for receiving, transmitting, processing and storing any appropriate data associated with the environment (100) of Figure 1. In particular, the mobile device (101) may run one or more general mobile applications (104), a trusted mobile application (105) used to verify and authenticate the user's identity through the mobile device (101), and any other appropriate components and / or operations.
[041] As illustrated, the mobile device (101) includes an interface (102), a processor (103), a mobile application (104), a trusted mobile application (105), a GUI (108), one or more input devices (109), a location module (112), a camera (118), and memory (113). The interface (102) is used by the mobile device (101) to communicate with other systems in a distributed environment, including within the environment (100), connected to the network (120), for example, client system(s) (130), the partner system (160), and other mobile devices (101), as well as other communicable systems coupled to the network (120). Generally, the interface (102) comprises logic encoded in software and / or hardware in a suitable and operable combination to communicate with the network (120).More specifically, the interface (102) may comprise software that supports one or more communication protocols associated with communications such that the network (120) or the interface hardware is operable to communicate physical signals within and outside the illustrated environment (100). Furthermore, the interface (102) may allow the mobile device (101) to communicate with the partner system (160) or a client system (130) to perform operations related to the present invention.
[042] The network (120) facilitates wireless or wired communications between the components of the environment (100) (for example, between the mobile device Petition 870250100007, dated 10 / 31 / 2025, page 37 / 98 22 / 61 (101) and the partnership system (160), between the mobile device (101) and the client system(s) (130), and between the client systems (130) and the partnership system (160)), as well as with any other local or remote computer, such as additional mobile devices, clients, servers or other communicable devices coupled to the network (120), including those not illustrated in Figure 1. In the illustrated environment, the network (120) is represented as a single network, but it may comprise more than one network without departing from the scope of this invention, provided that at least a portion of the network (120) can facilitate communication between senders and receivers. In some embodiments, one or more of the illustrated components (e.g., the partnership system (160) itself and / or one or more of the client systems (130)) may be included within the network (120) as one or more cloud-based services or operations.The network (120) may be the whole or a portion of a protected enterprise or network, while in other cases, at least a portion of the network (120) may represent an Internet connection. In some embodiments, a portion of the network (120) may be a virtual private network (VPN). Furthermore, all or a portion of the network (120) may comprise both a wired and a wireless connection. Examples of wireless connections may include 802.11a / b / g / n / ac, 802.20, WiMax, LTE, and / or any other appropriate wireless connection. In other words, the network (120) encompasses any internal or external network, networks, subnetwork, or combination thereof, operable to facilitate communications between the various computing components within and outside the illustrated environment (100). The network (120) can communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data and other suitable information between network addresses.The network (120) may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs) and wide area networks (WANs), in whole or in part. Petition 870250100007, dated 10 / 31 / 2025, page 38 / 98 23 / 61 of the Internet and / or any other communication system or systems in one or more locations.
[043] As illustrated in Figure 1, the mobile device (101) includes a processor (103). Although illustrated as a single processor (103) in Figure 1, two or more processors may be used according to specific needs, desires, or specific implementations of the environment (100). Each processor (103) may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other suitable component. Generally, the processor (103) executes instructions and manipulates data to perform the operations of the mobile device (101).Specifically, the processor (103) executes the algorithms and operations described in the illustrated figures, including the operations that perform the functionality associated with the mobile device (101) in general, as well as the various software modules (e.g., the mobile application (104) and the trusted mobile application (105)), including the functionality to send communications and receive transmissions from client systems (130) and partner systems (160), as well as to other mobile devices and systems.
[044] Regardless of the specific implementation, “software” includes computer-readable instructions, firmware, wired and / or programmed hardware, or any combination thereof in a tangible medium (transient or non-transient, as appropriate) operable when executed to perform processes and operations described in this application. In reality, each software component may be wholly or partially written or described in any appropriate computer language including C, C++, JavaScript, Java™, Visual Basic, assembler, Perl®, any suitable version of 4GL, as well as others.
[045] The mobile device (101) runs a mobile application (104) Petition 870250100007, dated 10 / 31 / 2025, page 39 / 98 24 / 61 operable to perform any functionality suitable for the mobile device (101). In some embodiments, several mobile applications (104) may be included and run on the mobile device (101), such as running mobile applications on mobile OS systems. In some embodiments, one or more of the mobile applications (104) may be operable to interact with one or more of the client systems (130). In some embodiments, these applications may be developed and provided by the client associated with the client system (130) (e.g., a dedicated mobile application, such as those downloaded or obtained from an app store), while in others, the applications (104) may be or be associated with a general mobile browser capable of mobile browsing, where specific interactions with the client systems (130) may be optional, if directed to a website or system associated with the client system (130).In some embodiments, interactions with client systems (130) may be performed by another system associated with the user, but not linked to the user's digital ID. In such cases, the partner system (160) may connect to the mobile device (101) via the trusted mobile application (105) to access and obtain information about the user and the mobile device (101), where and when needed.
[046] The trusted mobile application (105) represents a mobile application or combination of applications dedicated to providing a secure link between the user and the mobile device (101), where the user's digital ID, as described in this application, is linked to the mobile device (101) during a registration process executed by the registration module (106). The registration process can be initiated based on a user interaction with a specific client application (133), where an option to register a new digital ID can be presented through one of the mobile applications (104), or through a separate channel (e.g., through another Petition 870250100007, dated 10 / 31 / 2025, page 40 / 98 25 / 61 device or other application except through the trusted mobile application (105)). During registration (as described in an implementation example in Figure 3), the user can, through the client system (130), provide personally identifiable information (PII), which identifies the user (e.g., name, address, date of birth, social security number (SSN), driver's license number, etc.) to the partner system (160). The partner system (160) can, through its various components and functionalities described below, evaluate and validate the user's PII to verify the user's identity.At the same time, the partnership system (160) may assess potential fraudulent risks associated with the user based on the initial information provided and / or any prior information about the identified user (e.g., existing industry or government databases and reports such as credit agencies, criminal databases, etc.). If the user is approved as meeting or exceeding the risk requirements of the partnership system (160), the partnership system (160) may generate and provide, through the client system (130) (or through any other suitable method), a unique code (e.g., a QR code) or other token or identifier that can be associated with the user, including, but not limited to, mobile phone holder data, for the user to capture through the trusted mobile application (105).The unique code (or a suitable representation thereof) may be captured, for example, by a camera (118) integral with or associated with the mobile device (101) as accessed through the functionality of the trusted mobile application. Alternatively, the trusted mobile application (105) may be able to access a camera roll or photo library of captured images to identify and upload the unique code (or a suitable representation of the unique code as provided) back to the partner system (160). In embodiments employing non-visual unique codes (such as a token or identifier), the... Petition 870250100007, dated 10 / 31 / 2025, page 41 / 98 26 / 61 unique code can be captured and responded to through recognition and / or decryption mechanisms as appropriate. In response to confirmation that the unique code (or representation thereof) is captured by the trusted mobile application (105), the partner system (160) can view the mobile device (101) as a trusted device and, through a key management application (170) of the partner system (160), a private key (115) specific to the authorized user digital ID can be generated and stored on the mobile device (101). A corresponding client-specific digital ID or other unique identifier can be provided for each client that interacts with or has an account associated with the user, so that any client interaction with the partner system (160) can link the client-specific identifier to the main digital ID.The customer's specific digital ID can then be used in any customer system (130) associated with the partner system (160), where the partner system (160) can evaluate transaction requests using the secure evaluation system described in this application, using the link to the primary digital ID for the specific user / consumer.
[047] The trusted mobile application (105) as illustrated, also includes an authentication module (107). The authentication module (107) can be used, for example, in association with transaction attempts on client systems (130) including the digital ID network to provide mobile device details and information to the partner system (160) during or in association with the transaction request, to present additional authentication / challenge requests to users via the mobile device (101) in response to high security transactions (as predefined by client systems (130)) or in response to determinations of potential fraud associated with specific transactions by the partner system (160) and to provide responsive inputs for authentication / challenge requests. Petition 870250100007, dated 10 / 31 / 2025, page 42 / 98 27 / 61 additional presented through the trusted mobile application (105). In some embodiments, additional authentication requests / challenges may be presented to users via GUI (108).
[048] The mobile device GUI (108) (101) interfaces with at least a portion of the environment (100) for any suitable purpose, including generating a visual representation of a mobile application (104) and / or the trusted mobile application (105). In particular, the GUI (108) can be used to view and navigate various screens, for example, web pages, located both internally and externally to the environment (100), as well as to view and navigate through information accessed by any of the mobile applications (104) and / or trusted mobile application (105), this information stored or associated with one or both of the system(s) (130) and the partner system (160), among others. Generally, the GUI (108) provides the user with an efficient and user-friendly presentation of data provided or communicated within the system.The GUI (108) may comprise a plurality of customizable frames or views that have interactive fields, drop-down lists, and user-operated buttons. For example, the GUI (108) may provide interactive elements that allow a user to view or interact with information related to process operations associated with the trusted mobile application (105) and its authentication processes. The GUI (108), for example, may be where the user is provided with authentication questions / challenges and is capable of providing feedback (e.g., answers) to the partner system (160). In some embodiments, the GUI (108) may be associated with one or more input devices (109), including a biometric reader (110) (e.g., a fingerprint scanner, facial recognition, voice recognition / commands, etc.) or a touch screen / keyboard (111) (as well as other buttons, inputs, etc.).) to enable responsive feedback and interactions for questions. Petition 870250100007, dated 10 / 31 / 2025, page 43 / 98 28 / 61 authentication provided. Additionally, the GUI (108) can present information associated with one or more of the mobile applications (104) for viewing and interaction with one or more of the client's systems (130). In general, the GUI (108) is often configurable, supports a combination of tables and graphs (bar, line, pie, status displays, etc.) and is capable of creating real-time portals and presentations, where tabs are delineated by the main characteristics (e.g., site or micro-site). Therefore, the GUI (108) encompasses any suitable graphical user interface, such as a combination of a generic web browser, intelligent engine, and command-line interface (CLI), which processes the information on the platform and efficiently presents the results visually to the user. Additionally, the GUI (108) can also allow the consumer to manage their own security preferences through the trusted mobile application (105).For example, a consumer could block or otherwise protect items associated with their digital wallet while on military deployment or traveling for an extended period, so that any transaction attempt associated with the consumer's digital ID might be rejected or otherwise require additional authentication.
[049] A location module (112) may be included within the mobile device (101), and may be used to identify a specific location where the mobile device (101) is currently and has been historically located. The specific current location of the mobile device (101) may be provided to the partner system (160) (e.g., via the transaction request passed from the client system (130) or via the trusted mobile application (105)). If the current location of the mobile device (101) is different from the location where the request was received (e.g., via a channel distant from the mobile device (101)), the partner system (160) may detect an occurrence of fraud in Petition 870250100007, dated 10 / 31 / 2025, page 44 / 98 29 / 61 potential, and may initiate procedures to perform additional authorization operations, including sending a confirmation or other challenge to the mobile device (101) via the trusted mobile application (105). Additionally, if both the transaction request and the mobile device (101) are identified as originating from and located in a location different from that normally associated with the user (e.g., outside the country, a certain distance from all previous locations, etc.), one or more fraud alerts may be identified by the partner system (160). The location module (112) may be used to identify a specific physical location of the mobile device (101) or a logical or relative location of the mobile device (101) (e.g., based on nearby wireless networks detected, connections to one or more computers or systems, check-ins or other location-based information, etc.).
[050] The memory (113) of the mobile device (101) may represent a single memory or multiple memories. The memory (113) may include any memory or database module and may take the form of volatile or non-volatile memory, including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable location or remote memory component. The memory (113) may store various objects or data, including financial data, user information, administrative settings, password information, caches, applications, backup data, business storage repositories and / or dynamic information, and any other appropriate information associated with the mobile device (101), including any parameters, variables, algorithms, instructions, rules, restrictions, or references thereto.Additionally, memory (113) can store any other appropriate data, such as VPN applications, firmware logs and policies, firewall policies, a security or access log, printouts or others. Petition 870250100007, dated 10 / 31 / 2025, page 45 / 98 30 / 61 report files, as well as others. For example, the memory (113) may store one or more private keys in a private key repository (114) located in the memory (113), as well as a set of personally identifiable information (PII) (116), and a set of device-specific information (117). Storing the private key (114) may include private keys associated with one or more client systems (130), as well as a private key (115) that corresponds to the digital ID generated and provided by the partner system (160). The PII (116) may be stored on the mobile device (101) or may also be provided by the user in response to particular requests for the PII (116). In some embodiments, the PII (116) may represent a link to which the mobile device-specific PII (101) is associated, so that no PII is stored on the device except that which the consumer has stored on it.The device-specific information set (117) can be used to provide a digital fingerprint or identity of the mobile device (101) (e.g., based on installed software, system information, etc.) which can be used in part to identify the mobile device (101). This information can be shared by the trusted mobile application (105) to the partner system (160) on registration and, in some embodiments, in response to specific requests for additional authentication information to validate / authenticate the mobile device (101).
[051] As illustrated, Figure 1 includes one or more client systems (130). Each client system (130) can be associated with the digital ID network and can accept authorizations based on the digital IDs provided by mobile devices (101). Clients may include, for example, but not limited to, banks, financial institutions, online merchants, government systems, health insurance companies, and medical practices, among others. Client systems (130) can register with the partner system (160) to employ and accept digital IDs as substitutes or alternatives to Petition 870250100007, dated 10 / 31 / 2025, page 46 / 98 31 / 61 traditional login information for users. Initially, each client system (130) may have an existing trust relationship with specific users (e.g., those associated with mobile devices (101) before the digital ID is generated. In such cases, users may also be provided with the option to perform the registration options described in this application to link the consumer's mobile device (101) to the trusted digital ID and mobile application (105). Each client system (130) may provide at least one specific client application (133) or (website) that can be accessed and interacted with by users, where the specific client applications (133) can be accessed based on possession of the digital ID used across the digital ID network.
[052] Each client system (130) includes an interface (131), a processor (132), and memory (140), each of which may be similar to or different from the interface (102), processor (103), and memory (113), respectively, described in the mobile device (101). The interface (131) provides the client system (130) with communications to the components and systems of the environment (100), including the ability to communicate with the mobile device (101), the partner system (160), and any other systems or computers through the network (120). In general, the processor (132) executes instructions and manipulates data to perform the operations of the client system (130). Specifically, the processor (132) executes the algorithms and operations described in the illustrated figures, including the operations that perform the functionality associated with the client application (133). The memory (140) may be similar to or different from the memory (113).
[053] As illustrated, the client system (130) is used to receive, manage and interact with multiple users through any number of interactions, including via mobile devices (101) (e.g., mobile application (104)) or any other suitable computing system. The Petition 870250100007, dated 10 / 31 / 2025, page 47 / 98 32 / 61 The client application (133) can access and provide operations associated with confidential consumer records (142) stored in a consumer database (141) (in memory (140), which may be similar to or different from memory (113) and, in some embodiments, may be at least partially located remotely from the client system (130)), where the consumer records (142) may include, for example, business and government information, including financial, health, business, government or other related information, where the operations of the consumer application (133) are such that security concerns and procedures may be advantageous to use. Additionally, the client application (133) may be associated with various websites, and may be used to access or publish message boards, online email programs, online productivity software, as well as any other software, applications or systems.The consumer database (141) may store information relevant to information related to the specific client application, as well as include consumer data and information history (145). Furthermore, the client application (133) may be associated with transaction systems and other business systems, such as enterprise software systems, including customer relationship management systems, vendor systems, purchasing systems, human resources systems, and supply chain systems, among others. Consumer records (142) may be associated with an internal ID (143) previously used to introduce the trust relationship, which may be associated with a specific username / password combination, as well as other identifiers used within the client system (130).By generating the digital ID, consumer records (142) can be updated to include a partnership ID (144), which can allow the client system (130) to match with the partnership system (160) relating to specific users / consumers, allowing access. Petition 870250100007, dated 10 / 31 / 2025, page 48 / 98 33 / 61 fast and analysis of specific users and transactions. The partner ID (144) can be a unique key and / or globally unique identifier (GUID) that is used to link the client system’s internal IDs (143) to the digital ID used by the partner system (160) and received from users when the digital ID is provided for authentication of specific transactions, including logins and other operations.
[054] In some embodiments, some or all of the consumer data and history (145) may be shared with the partner system (160). As multiple client systems (130) store information associated with specific users, a better holistic view of these users can be provided if this information is shared and available to all systems. By sharing at least some of the consumer data and history (145) from multiple client systems (130), the partner system can provide better fraud tracking and detection.
[055] The memory (140) may also include a set of logical partnership rules (146). The logical partnership rules (146) may define client-specific settings and selections / subscriptions of potential authentication operations to be performed by the digital ID network for interaction with the client application (133) and consumers attempting transactions with the client system (130). For example, the logical partnership rules (146) may include a set of action authentication rules (147), which are defined by administrators in the client system (130) and coordinated with the partnership system (160), where these rules (147) define specific transactions or operations that may require an additional layer or level of user authentication, such as through the trusted mobile application (105).In some embodiments, the specific types of additional user authentication required can be specified in the action authentication rules (147), so that the client system (130) can determine and request it. Petition 870250100007, dated 10 / 31 / 2025, page 49 / 98 34 / 61 specific authorization through the partnership system (160). In some embodiments, the available additional authorization requests may be based on techniques available in the partnership system (160) and / or on specific techniques for which the client system (130) is subscribed or authorized to use. For example, a client may choose to use biometric data-based authentication for specific transactions, while electing not to provide a question and answer challenge. These may be cases where the transaction type is subject to higher levels of fraud, and where biometric authentication steps provide more secure confirmation of the identity of the user / consumer associated with the transaction.
[056] In some embodiments, action authentication rules (147) may provide information and / or internal rules on how, upon receiving a score or assessment from the partner system (160), specific transactions will be handled. Scores received from the partner system (160) may be relative or absolute, and may be interpreted by the client system (130) according to the rules (147), whether the transaction should be allowed or denied based on the results, whether additional authentication is required, and any other appropriate analyses or rules, including specific wording or notifications to be provided to the user / client.In some embodiments, the score required to authorize a particular type of transaction may differ between transaction types, based on user / consumer information, or based on other contexts and / or information, both specific to a particular consumer, and generally based on recent interactions with a plurality of consumers. These variations may be included in the action authentication rules (147) and may be used to vary the requirements for specific transactions. In some embodiments, the partnership system (160) may determine that a potentially fraudulent activity is occurring outside the defined rules (147) of the. Petition 870250100007, dated 10 / 31 / 2025, page 50 / 98 35 / 61 client application (133) (for example, based on mobile device location (101), based on recent and / or previous fraudulent activity on another client system (130), or based on other criteria), so that further assessment is required. Rules (147) may define when fraud assessment results may trigger further verification or the process may be triggered automatically by the partner system (160).
[057] As illustrated, the logical partnership rules (146) may also include one or more request templates (148), where the request templates (148) are used to define how the information associated with a particular transaction is provided to the partnership system (160). For example, for each request type, a different request template (148) may be available and used to identify the relevant user / consumer information to be provided. The request template (148) may be populated at runtime with the user / consumer partnership ID (144) for reference (160) by the partnership system (160) and, in some embodiments, the request template (148) may further identify a specific type of additional analysis and / or authentication to be performed.In other cases, the type of analysis and / or additional authentication may be determined by the partner system (160) based on selections from the client system (130) previously shared. As such, the logical partner rules (146) may be stored in their entirety in the client system (130), or at least some of the rules (146) may be located in the partner system (160) when appropriate. In either case, the client may call and define the appropriate rules to ensure that the client authentication level is satisfied for each type of transaction and / or context.
[058] Returning to the client application (133), the application can be used to perform any relevant operation and associated functionality. Petition 870250100007, dated 10 / 31 / 2025, page 51 / 98 36 / 61 to the client system (130). The client application (133) as illustrated includes a consumer interface (134) and a partner interface. The consumer interface (134) provides the interface for interactions with the user / consumer through any suitable channel, including through the mobile application (104) of the mobile device (101) or through another system (e.g., as a functionality of a website or through a dedicated application or app). The consumer interface (134) may include or be associated with a registration support module (135), where the opportunity to register with the partner system (160) may be presented and assistance with registration provided.The registration support module (135) can manage the passing of information to and from the user (e.g., through any channel information that occurs) and present information back to the user / consumer as needed, including the unique code generated by the partner system (160). The registration support module (135) can provide a link or access to the trusted mobile application (105), or it can assist in sending a link to the mobile device (101) to download the application (105) via text, email, or any other method where the initial interaction does not occur through the mobile device (101). If the user / consumer is already registered, the consumer interface (134) can match credentials provided by the user / consumer to a particular client-specific ID as a login or transaction authentication technique.Whenever the customer wants to perform risk-based authentication with the customer, the consumer can pass their digital ID to the partner system (160). The customer-specific ID (which is different from the digital ID managed by the partner system (160)) can be used to access internal operations and data at the customer level and with the customer system (130). The customer-specific ID can be provided to the partner system (160) where authentication is required and / or when appropriate. Petition 870250100007, dated 10 / 31 / 2025, page 52 / 98 37 / 61 storing the internal digital ID in the partner system (160) and not providing it to the client mitigates the risk of compromising the entire keyset if a single client is compromised.
[059] The client application (133) also includes a partnership interface (136) to interact with and take advantage of the partnership system operations (160). The partnership interface (136) may allow the client application (133) (and other client applications) to interact with the digital ID network through communications with the partnership system (160), and may be used to interpret the logical partnership rules (146), prepare and send requests to the partnership system (160) in accordance with those requests, and subsequently interpret communications from the partnership system (160) to react to ID verification and fraud detection results, as appropriate. The partnership interface (136) may include a registration module (137) to communicate with the partnership system (160) when registering a new user / consumer.The partnership interface (136) may also include a client management module (138), where the management module (138) allows administrators in the client system (130) to modify client-specific logical partnership rules (146), subscribe to specific verification techniques, and otherwise manage available interactions and parameters of the partnership system (160). The partnership interface (136) includes an authentication interface (139) that may handle the sending and receiving of authentication information received by the client system (130) from the user / consumer to the partnership system (160) to provide digital ID network authentication operations.
[060] In general, the illustrated modules of the client systems (130), the partnership system (160) or the mobile device (101) can be combined into a single application or module, in some embodiments. As noted, some of the software and stored information may be Petition 870250100007, dated 10 / 31 / 2025, page 53 / 98 38 / 61 located or available remotely from the systems illustrated and described, including cloud-based systems.
[061] The partnership system (160) performs operations associated with specific transactions with holistic access received from one or more client systems (130) associated with specific users, verifying user identity, assessing any potential fraudulent activity, and providing additional levels of security and confirmation requests where specifically chosen by individual client systems (130) or where a potential set of fraudulent activities is identified. Although illustrated as a single system, the partnership system (160) may comprise multiple systems, functions, modules, and software, where appropriate.
[062] As illustrated, the partnership system (160) includes an interface (161), a processor (162), a consumer interface application (163), a client interface application (171), a client-specific analysis module (173), a third-party system interface (178), and memory (179). The interface (161), processor (162), and memory (179) may be similar to or different from the interfaces (102), (131), processors (103), (132), and memories (113), (140) described for the mobile device (101) and client systems (130), respectively. In general, the processor (162) executes instructions and manipulates data to perform the operations of the partnership system (160), including the execution of algorithms and the operations described in the illustrated figures.
[063] The client system’s consumer interface application (160) is used to interact with the consumer through registration (via mobile device (101) and / or any additional channels where the registration process was initiated, for example, via a connection to the website on a desktop computer) and membership interactions to authentication operations. As illustrated, the partnership system (160) includes a registration module (164), an authentication module (168) and a Petition 870250100007, dated 10 / 31 / 2025, page 54 / 98 39 / 61 digital wallet management module (169).
[064] The registration module (164) may allow the user / consumer to perform the necessary registration operations as described in this application. In some embodiments, interactions with the client system (130) may initiate interactions between the registration module (164) and the consumer. In some embodiments, operations performed before installing the trusted mobile application (105) may be performed through the client system (130) with which the registration process was initiated or through a web-based interface with the partner system (160) (not illustrated). A unique identifier generator (165) may generate unique identifiers (e.g., QR codes) that can be used to identify specific users in the registration process who have been initially authenticated during the registration process.The registration authentication module (166) can obtain or access obtained PII provided by the consumer (e.g., through the client system (130)) and perform (1) an identity verification process and (2) an initial fraud assessment process. The identity verification process can be managed by the registration module (164), for example, by accessing one or more public or private databases or other third-party systems (190) to confirm the user / consumer's identity. During, before, or after the identity verification process, the registration authentication module (166) can perform the initial fraud assessment process associated with the user / consumer to filter against identity elements associated with fraud.In some realizations, module (166) may check to determine if the provided (and potentially verified) identity has been associated with prior fraudulent activity or if the identity or PII information has been associated with one or more cybersecurity breaches in the public or private sector. Credit agency checks may be initiated in some realizations to determine if fraudulent activity has been previously reported. Petition 870250100007, dated 10 / 31 / 2025, p. 55 / 98 40 / 61 associated with PII. Alternative and other methods may be used to determine whether the identity or person is a potential fraud risk, including matching user / consumer-associated PII to known high-risk PII, partner PII, support PII, and other available sources. The velocity of PII-related information (e.g., transactional velocity and / or behavioral velocity) may also be assessed and considered. Other data sources may also be leveraged in the initial analysis, as appropriate. In some embodiments, the registration authentication module (166) may access the consumer analytics module (175) to perform initial ID verification and fraud assessment operations.
[065] Once the identity is verified and the potential fraud risk associated with the identity is determined to be within acceptable limits by system requirements, the unique identifier can be generated and / or associated with their identity. As described, the unique identifier can be provided to the user / consumer through the channel through which the registration process was initiated, and instructions can be provided to the user / consumer to download the trusted mobile application (105) and subsequently capture an image of the unique identifier (and / or an encoded version of the unique identifier) through the application (105). The captured image can be provided to the partner system (160) from the trusted mobile application (105) in a second communication channel that is different from the channel through which the registration process is initiated.After verifying that the captured image matches the uniquely generated identifier or that the captured image includes the encoded uniquely generated identifier, the mobile device (101) can be considered registered. In some embodiments, a private key (e.g., private key (115)) can be generated for the mobile device (101). Additionally, the unique digital ID can be considered registered and made available for use in systems. Petition 870250100007, dated 10 / 31 / 2025, page 56 / 98 41 / 61 clients associated with partnerships (130). An identity linking module (167) can perform and / or manage the association of the specific user / consumer to the mobile device (101). A key management application (170) of the partnership system (160) can generate a GUID, i.e., the partnership ID (144), for use by the client system (130) associated with the registration. As additional client systems (130) associated with the partnership system (160) are used or interact with the user registered in the system, additional unique keys can be generated and provided to the other systems (130) by the key management application (170).Partnership IDs (144) are different in each client system (130), if a given partnership ID (144) is exposed or lost, the partnership system (160) can simply generate a new partnership ID (144) that corresponds to the specific system (130) that needs a new GUID without requiring the registration process to be performed again. As authentication and validation requests are provided by the client systems (130), the GUID that corresponds to the user of those systems (130) can be included in the request and identified in the partnership system (160).
[066] The authentication module (168) can manage authentication operations performed after initial registration, and can manage the sharing and verification of additional authorization operations between the partner system (160) and the mobile device (101). The authentication module (168) can communicate with the trusted mobile application (105) in a secure manner, providing the additional authentication requests to the mobile device (101) and receiving the responses in return.
[067] The digital wallet management module (169) can allow users / consumers registered with the partner system (160) to manage their digital wallets, review associated client systems (130) where their digital ID can be used, update information about themselves as users / consumers, and perform any number of activities. Petition 870250100007, dated 10 / 31 / 2025, page 57 / 98 42 / 61 account management. The ability to monitor and manage information associated with themselves can allow significant freedom and protection to the user, including information about potential fraudulent transaction attempts identified by the partner system (160), including with which client systems (130) these attempts occurred, as well as information in the possession of potential attackers, among other data.
[068] The client interface application (171) is used by the partner system (160) to interact with the client systems (130) during registration, to perform authentication and fraud monitoring, and to allow administrators and authorized users to update and manage client-specific rules and operating parameters. In some embodiments, communications from the client systems (130) may be received in the client interface application (171), which may include or be associated with one or more application programming interfaces (APIs) and / or other endpoints to which communications may be provided by the client systems (130). In some embodiments, the received communications may be represented as requests (based on request templates (148)), where the client system (130) is identified along with the unique partner ID (144) associated with that specific client system (130).In some embodiments, the specific authentications to be performed are identified in the requests, while in other cases, the client interface application (171) may use one or more client-specific authentication rules (186) stored in memory to perform the analysis. In some embodiments, a combination of stored client rules and stored partnership rules may be used. When a request is received from a client system (130), the client interface application (171) may provide the request to the client-specific analysis module (173). When a client system (130) requests to interact. Petition 870250100007, dated 10 / 31 / 2025, page 58 / 98 43 / 61 with your client system account (130), the client management interface (172) can be run by the partner system (160) to determine how to operate for the specific client, including the ability to update / review which authentication techniques will be used when, or to modify parameters of specific operations to be performed.
[069] The client-specific analysis module (173) may be a separate module from the client interface application (171), or a portion thereof. The client-specific analysis module (173) may manage the evaluation of specific analysis requests received from a client-specific system (130), where the module (173) interprets the request, its content, and all associated metadata to determine how to process the request. The determination of the analysis type (174) of the module (173) uses information and context about the request to determine the type of analysis to be performed on the transaction provided by the client system (130). In one example, the analysis request may include an explicit indication of the type of transaction to be analyzed and information about which authentication techniques will be applied.In other cases, the request may include implicit information related to the transaction request, so that the determination of the type of analysis (174) may need to determine the type of transaction request to be performed. In some embodiments, the request may include the specific authentication techniques to be applied to the transaction request, while in others, the determined type of transaction may be cross-referenced to one or more of the client-specific authentication rules (186) to determine the type of additional authentication that may be required / desired by the client system (130).
[070] The consumer analysis module (175) can perform specific consumer analysis as needed or requested by the client system (130). In some embodiments, one or more operations of Petition 870250100007, dated 10 / 31 / 2025, page 59 / 98 44 / 61 ID verification may still be performed or information about the request may be evaluated. A scoring module (176) may generate a relative and / or absolute score for the user and the request, where specific thresholds (relative or absolute) may determine if problems are identified and if additional verification and authentication may be required. A fraud assessment mechanism (177) may compare the transaction request and associated information with an ongoing analysis of consumer records, along with information associated with the transaction request, including information obtained about the mobile device itself (101).For example, the fraud assessment mechanism (177), in response to receiving a transaction request associated with a specific user / consumer, can obtain information about the state of the mobile device (101), both from the trusted mobile application (105) and from information included in the transaction request. The fraud assessment mechanism (177) can compare known and / or recent information associated with the user / consumer to identify if any potential fraudulent behavior can be identified. In some embodiments, each transaction request can have a fraud detection assessment performed on it, while in others, only some of the transaction requests can be assessed for fraud (for example, when a particular client-specific authentication rule (186) calls for such an assessment).The fraud assessment mechanism (177) may be based on the results of an assessment in a set of fraud assessment rules and standards (185), which define a set of flags or patterns of potentially fraudulent behavior. The fraud assessment rules and standards (185) may define examples of changes or transitions in transactions based on the user / consumer's history, in a specific set of transaction information that may be fraudulent. Petition 870250100007, dated 10 / 31 / 2025, page 60 / 98 45 / 61 potential, in a comparison of mobile device location (101) compared to an expected or normal location, as well as any other appropriate standards and / or rules. By comparing the consumer request, the device information associated with the mobile device (101) (e.g., absolute location, IP address, etc.) sending the request, the transaction speed of previous and recent transaction requests, specific transaction data and other transaction parts and associated information, the fraud assessment mechanism (177) can assist in determining potential fraud cases. As noted, when multiple client systems (130) are included in the digital ID network and obtain consistent and maintained information about specific users / consumers, historical transaction data (184) (which may be stored in memory (179)) can be used to assist in the assessment.Additionally, the rules and standards for evaluating fraud (185) may be updated based on fraudulent behavior determined from users, except for the current user / consumer, where determinations of fraudulent behavior in relation to other accounts may be used to identify new fraudulent behavior in the current user / consumer.
[071] A number of determinations made by the partnership system (160) may rely on information stored outside, remotely, or external to the partnership system (160). In such cases, a third-party system interface (178) may be used to contact and obtain information from one or more third-party systems (190). Third-party systems (190) may be any systems outside the partnership system (160) that store information relating to accounts and consumer data (191), specific trends on fraudulent behavior, including additional and alternative fraud assessment rules and standards, as well as other information relevant to the partnership system's assessment of PII information for Petition 870250100007, dated 10 / 31 / 2025, page 61 / 98 46 / 61 users / consumers and transaction data associated with specific transaction requests.
[072] As illustrated, the partner system memory (179) (160) includes a set of ID verification options and rules (180), where these rules (180) can be used in the initial consumer assessment at registration, as well as when additional authentication is needed during transaction requests. The rules (180) can define how these requests are presented to users, how responses to these requests are interpreted, and which requests should be asked or analyzed in specific situations. Examples of ID verification rules (180) may include some or all of the following without limitation: knowledge-based authentication (e.g., a question and answer combination), cross-channel comparison (e.g., when two different channels, such as a primary channel for clients that have their own GUI and a secondary channel represented by a trusted application on a linked device,so that signatures associated with the two different channels are compared, for example, to certify an absolute or relative IP location of one channel compared to the IP location of the other channel), out-of-band authentication (e.g., which can send an SMS or email verification message independent of communication with the user's digital banking device), a known fraud exchange assessment (e.g., a known fraud exchange with known fraud on a government ID), a PII speed analysis (e.g., an out-of-the-ordinary use-of-the-box analysis for PII information), a transaction speed analysis for a specific user (or compared to a normal user), transaction data analysis, a biometric analysis (e.g., fingerprint analysis, voice analysis, facial recognition, etc.), device-associated PII based on carrier adherence (e.g., Petition 870250100007, dated 10 / 31 / 2025, page 62 / 98 47 / 61 accessing data sources associated with the existing carrier to corroborate the PII provided by the customer), suspected or known IDs or other PII (e.g., based on the fraud analysis systems or infrastructures maintained), and device reputation (e.g., when the device has been previously associated with one or more high-risk transactions or the device duration has been associated with the user), as well as various other appropriate identification verification rules. The customer’s specific rules (186) may define which of these techniques will be used in transaction analysis.
[073] As illustrated, a consumer-specific dataset (181) can also be maintained by the partnership system (160). Specifically, the consumer-specific dataset (181) can store a customer key table (182), where the digital IDs (183) of specific consumers are maintained and where the consumer-specific GUIDs associated with these digital IDs are maintained after their generation and provision to the corresponding customer system (130). In addition, historical transaction data (184) associated with consumers can be maintained and applied in future fraud assessments, when appropriate. In some embodiments, the historical transaction data (184) can be explored and / or analyzed to determine risks across all customers and for all consumers.The history of information can, for example, be anonymized and used to assess fraudulent patterns, which can then be incorporated into the rules and standards for assessing fraud (185) for future fraudulent assessments.
[074] Although portions of the software elements illustrated in Figure 1 are shown as individual modules that implement various features and functionalities through various objects, methods, or other processes, the software may instead include a number of submodules, third-party services, components, libraries, and others, as appropriate. Petition 870250100007, dated 10 / 31 / 2025, page 63 / 98 48 / 61 Conversely, the characteristics and functionalities of various components can be combined into individual components as appropriate.
[075] Figure 2 is an example diagram of a simplified system (200) for providing a digital ID network. The illustration represents an example of a set of components that perform operations similar to those described in Figure 1, particularly with regard to banking and online activity.
[076] Banking activity platform (202), mobile application (204) and online merchant platform represent three components of the external digital ID network to the backend partnership system (201), as illustrated in Figure 1. The banking platforms (202) represent a set of banking solutions and operations associated with a plurality of banking systems, where the banking platforms (202) are associated with and perform standard banking operations for users registered on those banking platforms (202). The solution in the present invention allows a single primary digital ID to be used across the plurality of banking activity platforms (202) as described in the present application, where each of the specific clients (e.g., banking activity platform (202), online merchant platform (206)) is associated with a secondary digital ID associated with the individual primary digital ID for a specific consumer.For example, a bank-specific secondary digital ID may be used by a specific banking activity platform, while another merchant-specific secondary digital ID may be used by a specific merchant (206). The mobile application (204) represents the trusted mobile application (e.g., trusted mobile application (105)) used as the hub for consumer linking operations and additional authentications performed by the system (200). The online merchant platform (206) represents, similarly to banking activity platforms (202), one or more merchant platforms that integrate. Petition 870250100007, dated 10 / 31 / 2025, page 64 / 98 49 / 61 the digital ID network and which allow transactions to be carried out through the use of individual digital IDs, while providing enhanced security and authentication techniques.
[077] Component information (202, 204, 206) enters the system through an API integration gateway 210, where requests and responses are received and other interactions are sent from the partner system (201). The integration gateway (210) may have the capability to mediate and manage trust interactions between banking activity platforms (202) and online merchant platforms (206) with the backend systems used by the partner system (201), including each of the individual components used in ID verification and fraud analysis processes.
[078] A set of mobile services (212) is associated with the partnership system (201): the mobile ID verification module (214) and the device linking module (216). The mobile verification module (214) has the capability and functionality to verify the identity of a specific consumer, based on the PII as provided in the registration. The mobile verification module (214) can verify the PII based on one or more internal and / or external databases, including those maintained by the partner system's management system or affiliate (201). The device linking module (216) can establish and provide a physical link (e.g., a key) associated with the device, where the link is shared between a particular user and their associated mobile device, as described in this application, for authentication through the partnership system (201).Once the link is established, the mobile device and information associated with it can be used in the evaluation of specific transactions. In addition, a secure channel between the partner system (201) and the mobile application (204) installed on the mobile device can be used to request additional information and / or. Petition 870250100007, dated 10 / 31 / 2025, pp. 65 / 98 50 / 61 data points for higher levels of authentication.
[079] Fraud services (218) can perform analyses of specific transactions in view of specific transaction data, recent and related transactions performed by the specific consumer associated with a transaction and / or a similarly or related consumer, information about a channel in which the operation was requested, compared to information associated with the mobile device, as well as others. An ID scoring module (220) uses linking and keying technology through high-quality data sources to evaluate and approve digital ID across systems, allowing conflict-free risk-based authentication when available, and prompting for additional authentication when potential problems or fraud are identified.The speed analysis module (222) detects suspicious and potentially fraudulent activity through financial institutions that may be indicative of fraud, including an analysis related to the number of transaction attempts, compared to normal user activity or compared to other users and consumers. Fraud-related pattern analysis can be used on the entirety of consumer interactions with banking and merchant activity platforms as available to assess transaction frequency and / or transaction quantity associated with the digital ID. The activity tracking module (224) leverages real-time activity and device signature information (e.g., which may include specific characteristics about the device itself, including OS versions, jailbreak status, specific installed applications, hardware information, etc.).) to detect suspicious behavior, including information about the mobile device's location relative to a location where the transaction is requested. In some embodiments, this may be based on a comparison of IP addresses, absolute and / or relative locations between the location of the... Petition 870250100007, dated 10 / 31 / 2025, pp. 66 / 98 51 / 61 transaction and device location, as well as the location of other recent purchases and / or activities related to the location of a requested transaction. Alternatively, a current location associated with the transaction attempt can be compared to a normal and / or expected device location, so that unexpected locations can be provided with further examination and analysis. The behavior analysis module (226) can allow the machine and / or self-learning algorithms to study the normal or habitual characteristics of a specific consumer or group of consumers, and compare certain activities in real time to these expected characteristics to determine if potential fraudulent activity is occurring based on the timing, size, location, among other characteristics, of specific transactions.
[080] The scoring service (228) performs actions to determine whether additional authorization is required by the client’s systems (e.g., online banking platforms (202) or merchant platforms (206)), based on predefined requirements and / or whether the identification of fraud or potential problems with ID checks requires further consideration. The rules mechanism (230) can provide a workflow capability for the partner system (201), where information about the data source can be fed into the client’s specific rules to determine analysis results and identify next steps, including requesting additional information or checks from the mobile application (204) before further transactions are approved.
[081] Data feed (208) represents a data feed that provides data from a financial institution to the digital ID network and partnership system (201) on a predetermined and / or ongoing schedule. The information received can be used for updating Petition 870250100007, dated 10 / 31 / 2025, pp. 67 / 98 52 / 61 of the partner system assessments (201) and its components, to update specific rules, and to maintain the current system (201). The data ingestion module (234) of the data services (232) can receive and update new data for the digital ID network, while the digital ID marketplace (236) provides an on-demand view of identity information associated with one or more consumers. The digital ID marketplace (236) can be used to create digital IDs for new registrations, including a “system of registration,” which can include activity information, device-specific information, consumer-associated PII information, historical transaction data, and other information. Existing data sources can be leveraged in building the already existing digital ID marketplace (236), so that existing consumer information can be incorporated into their digital ID to provide immediate advanced analytics and analytics upon registration.
[082] Figure 3 is a flowchart of an example registration operation from the perspective of the partnership system, such as partnership system (160). For clarity of presentation, the following description generally describes method (300) in the context of system (100) illustrated in Figure 1. However, it will be understood that method (300) can be performed, for example, by any other suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware as appropriate.
[083] In (305), a request is identified to register a user with the digital ID network, where the request is provided from a first client system within the plurality of client systems included in the digital ID network. Furthermore, the specific user associated with the registration request may already have an existing trust relationship with the first client system.
[084] In (310), a set of personal information is obtained Petition 870250100007, dated 10 / 31 / 2025, pp. 68 / 98 53 / 61 identifiables associated with the specific user. PII may be passed from the first entity, although in other cases, the information may be provided directly by the specific user. In (315), an ID verification and fraud risk assessment analysis is performed for the specific user based on the PII obtained.
[085] In (320), a determination is made as to whether the analysis is satisfied. In some realizations, ID verification satisfaction and fraud risk assessment may be based on an absolute or relative score being generated by the partner system based on available information. Once the score is generated, satisfaction may then be based on a determination of whether that score exceeds a threshold value. In some realizations, the generated score may be a confidence-based score or a combination of scores, where the relative confidence of the ID verification represents a first score and the fraud risk assessment provides a second score. In these cases, if both scores or a combination of scores exceeds a minimum threshold value, then the registration process continues in (330). Other assessments and appropriate criteria for satisfaction may be used in other cases.However, if the analysis is not satisfied, method (300) changes to (325) where the registration request with the digital ID network is rejected because the system is unable to verify the specific user's PII ID or because a certain potential for fraud based on the analysis is too high for inclusion in the federated network.
[086] In (330), a unique digital ID is generated for the specific user for use within the digital ID network, the digital ID exclusively representing the specific user for the partnership system. Additionally, a second unique digital ID specific to the client is generated, where the second digital ID is used by the client in reference to the specific user during Petition 870250100007, dated 10 / 31 / 2025, pp. 69 / 98 54 / 61 interactions between the client and the partner system, ensuring that the client system and / or the user's specific client information are compromised, the specific user's primary digital ID that is used throughout the digital network and by the partner system would not be compromised. In some embodiments, the client through which registration occurs may initially be provided with a second, or secondary, digital ID specifically associated with the client interactions and used in interactions with the partner system. In other cases, the secondary digital ID may be generated later, as (350) below.
[087] In (335), an image is generated that represents the specific user’s unique digital ID, and the generated image is transmitted to the first presentation of the entity or interface associated with interactions with the specific user. The transmission may include instructions for the specific user to capture a photo or submit the image through a trusted mobile application associated with the digital ID network and the partner system. In some embodiments, the image may have the alphanumeric digital ID (or the native digital ID format without alteration). In other cases, the digital ID may be encoded in an image (e.g., in a QR code) and used as a substitute for the digital ID itself. Still in other cases, the digital ID may be encoded without image and other encoded presentations and may be used in a different way to authenticate the user on the user’s mobile phone or other device.
[088] In (340), a determination is made as if a photo of the generated image were received through the trusted mobile application running on the mobile device associated with the specific user. If no photo is received, or if the photo does not match the generated image, method (300) changes to (325), where the request is rejected. If, instead, the photo is received and is compatible or otherwise matches the generated image and / or Petition 870250100007, dated 10 / 31 / 2025, p. 70 / 98 55 / 61 to the encoded unique identifier, the mobile device on which the trusted mobile application is installed and running can be confirmed and linked to the specific user's unique digital ID in (345), where the mobile device and the trusted mobile application can be used for future ID checks and fraud detection procedures for interactions within the digital ID network involving the specific user's unique digital ID. Furthermore, the unique digital ID can be submitted through interfaces and applications associated with different client systems beyond the first client system, where these client systems are registered with the digital ID network.
[089] In addition to linking the mobile device to the unique digital ID, in (350), the partner system can generate a first unique identifier (e.g., a GUID) for use by the first client system when interacting with the specific user, where the first unique identifier is different from the digital ID. The first unique identifier can be used by the first client system to identify the specific user associated with the digital ID, thus avoiding sharing the digital ID across system boundaries when not necessary. Each client system with a relationship to the specific user can receive or generate a new unique identifier that can be used instead of the other PII with the partner system for future transactions, limiting potential interception vectors to digital ID information within the partner system associated with the user.
[090] Figure 4 is a flowchart of an example operation to perform additional authentication operations between the partner system and a trusted mobile application from the perspective of the partner system, such as the partner system (160). For clarity of presentation, the following description generally describes method (400) in the context of system (100) illustrated in Figure 1. However, it will be understood that method (400) can be performed, for example, by any other suitable system, Petition 870250100007, dated 10 / 31 / 2025, page 71 / 98 56 / 61 environment, software and hardware, or a combination of systems, environments, software and hardware as appropriate.
[091] In (405), information associated with a request to perform a specific transaction associated with a digital ID is received from a client system. The information received may include a specific user ID associated with the request, the type of transaction to be performed, and, in some embodiments, the client's specific risk assessment strategy. In other cases, the client's specific risk assessment rules may be stored in the partner system and may be tied to specific types of transactions being requested. Transactions may include logins to the client system, standard transactions (e.g., account balance reviews, account information updates, purchases exceeding a predefined limit, etc.), relatively higher risk transactions (e.g., a funds transfer, a loan application, purchases exceeding a predefined limit, etc.).), or other types of transactions. Depending on the type of transaction, different risk assessment strategies may be implemented. In addition, one or more different fraud risk analyses may be performed based on available information associated with the specific user, recent transactions associated with the user, and other relevant information, including information associated with the mobile device linked to and associated with the specific user's digital ID (e.g., a mobile device location relative to the transaction location).
[092] In (410), the risk assessment strategy is carried out based on the information received. In some embodiments, the risk assessment strategy may require an additional authentication operation to be carried out. In other cases, the fraud assessment based on the information received may trigger a requirement for information of Petition 870250100007, dated 10 / 31 / 2025, pp. 72 / 98 57 / 61 Additional authentication before authorization of the requested transaction. In some embodiments, the risk assessment strategy is implicitly determined from the information received, or from a connection to the type of transaction identified in the information received. In some embodiments, the information received may be assessed for fraud without explicit or implicit notice, such as by comparing the information received (and other available information about the specific user and / or mobile device) to one or more fraud-related patterns or rules.
[093] In (415), a determination is made whether additional authentication operations are required based on the risk assessment strategy and / or fraud risk analysis. If not, the process can continue in (420), where a conflict-free authentication of the transaction request can be performed and passed back to the client system associated with the transaction without requiring additional information or further user interactions to authenticate the transaction. If, however, an additional authentication operation is determined to be necessary, method (400) continues in (425), where a secure channel is established with the trusted mobile application of the mobile device linked to the specific user's digital ID. The secure channel can be based on encrypted or otherwise protected communications between the partner system and the trusted mobile application. Any suitable method of creating the secure channel can be used.
[094] In (430), the additional authentication operations required by the risk assessment strategy and / or fraud risk analysis are performed by preparing and sending real-time requests to the user via the trusted mobile application. Real-time requests may include any suitable format, including a request for the user's biometric data (e.g., a fingerprint, a voice recognition process, a facial recognition process, etc.), a Petition 870250100007, dated 10 / 31 / 2025, pp. 73 / 98 58 / 61 requesting an answer to a question with a correct answer known to the user and unlikely to be known by an attacker or imposter (for example, the amount of a current car payment or a previous address), sending a push notification that requires a second authentication factor from the mobile device, as well as other types of authentication interactions and operations.
[095] In (435), a determination is made as if a response has been received from the user for the authentication operation requested through the trusted mobile application. In some embodiments, the time for a response may be limited to a certain time limit (e.g., five (5) minutes from the initial request) before the transaction is rejected. If no response has been received, in (440) an indication of the failure of the authentication operation may be provided to the client system. If a response has been received, the method (400) continues in (445), where a determination is made as if the received response satisfied the requirements of the additional authentication operation to authorize the transaction. If the response does not satisfy the additional authentication operation, the method (400) returns to (440) and indicates to the client system that the additional authentication operation has failed.Failure to satisfy the additional authentication operation may be based on an explicit indication from the trusted mobile application that the user was not associated with the original transaction request, a failure in the biometric response, a failure in the response to a knowledge-based question, or another similar response that failed based on an evaluation of the response to the authentication operation. If, however, the response satisfies the evaluation of the additional authentication operation by validating the user's identification and / or confirming that the transaction request was not fraudulent, the results of the success of the additional authentication operation may be sent to the client system in (450), where these results may result in a. Petition 870250100007, dated 10 / 31 / 2025, pp. 74 / 98 59 / 61 authorization of the pending transaction in the client's system.
[096] The preceding figures and accompanying description illustrate example systems, processes, and techniques implementable by computer. Although the illustrated systems and processes contemplate the use, implementation, or execution of any technique suitable for performing these and other tasks, it will be understood that these systems and processes are for illustrative purposes only and that the described or similar techniques may be performed at any appropriate time, including simultaneously, individually, or in combination, or performed by alternative components or systems. Furthermore, many of the operations in these processes may occur simultaneously, at the same time, and / or in a different order than shown. In addition, the illustrated systems may use processes with additional operations, fewer operations, and / or different operations, provided that the methods remain appropriate.
[097] Several alternative and additional potential features can be considered with the illustrations and descriptions in the present application. In other words, although this invention has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be evident to those skilled in the art.
[098] In some embodiments, the trust associated with a specific device and its underlying consumer can be used to approve consumer actions in addition to customer-related actions. Whenever a customer considers a transaction to carry high risk and / or liability, the customer may wish to perform a trust elevation to mitigate the risk. Examples of these may include address changes, money transfer operations, and others. Throughout the trust and partnership network, the network itself can leverage trust to introduce trust network members to customers (e.g., vendors of Petition 870250100007, dated 10 / 31 / 2025, pp. 75 / 98 60 / 61 banking services, retail providers), with the purpose of authenticating not only these members, but also providing trusted user information through the digital trust network to ensure that users do not need to manually re-enter this information where it could possibly be intercepted. In other cases, the forms used to register with other clients may be pre-filled, or this information may be passed without the need for specific submissions through the UI by the consumer. In this aspect, too, the use of the trust relationship can allow non-repudiation to be considered as a user authentication factor for other clients associated with the digital trust network.
[099] In general, the consumer's digital trust relationship with the device, and between the consumer / device and the digital trust network, allows for a plurality of actions to be taken within the system. One feature is digital ID registration, where consumers already associated with the digital trust network can authorize, through the trusted mobile application, website integration, device application integration, and mobile hub application integration based on the trusted device relationship. Furthermore, additional security can be provided to client systems, allowing these clients to provide consumers with conflict-free access and logins to websites, mobile applications, and mobile hub applications, when appropriate and when the trusted mobile application is used or associated with interactions, thus providing the necessary information to confirm the trust relationship.
[100] In addition, the trust relationship can allow specific customers to leverage the capabilities of digital trust networks and trusted mobile applications by mitigating risk in high-risk transactions as defined by the customer. Specifically, context-based approval and / or authentication enhancement can be used to Petition 870250100007, dated 10 / 31 / 2025, pp. 76 / 98 61 / 61 requires manual or interactive confirmation, determinations, and / or authentications for transactions and operations that may involve additional risk. For example, payment approvals made through websites, mobile applications, and / or other channels may be associated with additional security interactions or requests, which may be sent or distributed through the trusted mobile application. Because the user / consumer is trusted to be associated with the mobile device and the trusted mobile application, authentications or authorizations for transactions may be performed through distributed messages or interactions that interact with the trusted mobile application.
[101] In other cases, the consumer may be able to perform device management operations through the trusted mobile application, as well as interact with customer support functionality and capabilities. Using the trusted mobile application, consumers may be able to perform customer support activities for device management, including deregistering the device, suspending the device, or searching for digital IDs associated with the partner system. Additionally, UIs and interactions may become available for the consumer to search transactions performed across the digital trust network on demand, allowing the consumer to determine and confirm that the activity performed using the trusted digital identity conforms to the user's known activities.
[102] Consequently, the above description of exemplary embodiments does not define or restrict this invention. Other changes, substitutions and alterations are also possible without departing from the scope of this invention. Petition 870250100007, dated 10 / 31 / 2025, pp. 77 / 98
Claims
1 / 9 Claims 1. SYSTEM (100, 200), comprising a partnership system (160) that manages a digital identity network, the partnership system (160) comprising: at least one processor (103); and a non-transient, computer-readable means of storing instructions, executable by at least one processor (103), the instructions instructing at least one processor (103) to: identify (305) a request to register a specific user with a digital identity network, wherein the request is provided by a first client system (130) within a plurality of client systems in the digital identity network, wherein the specific user is associated with a first trust relationship with the first client system (130); characterized by obtaining (310) a set of personally identifiable information (PII) associated with the specific user through the first client system (130);perform (315) an identity verification (IDV) and fraud risk assessment analysis of the specific user based on the set of personally identifiable information obtained; and in response to satisfying (320) the identity verification and fraud risk assessment analysis: generate (330) a first unique digital identity for the specific user for use within the digital identity network, where the first unique digital identity exclusively represents the specific user for the partnership system (160);transmit a generated image (335) representing the first unique digital identity to an interface of the first client system (130) associated with interactions with the specific user, wherein the transmitted image Petition 870250100007, of 10 / 31 / 2025, p. 78 / 98 2 / 9 includes instructions for the specific user to capture a photo or send the image (340) to verify the identity of the specific user through a trusted mobile application (105) installed on a mobile device (101) associated with the specific user, wherein the trusted mobile application (105) is associated with the digital identification network and the partnership system (160);and in response to verification of the specific user's identity through the trusted mobile application (105) installed on the mobile device (101) verifying whether the photo or image matches the specific user's first unique digital identity, link (345) the specific user's mobile device (101) to the specific user's first unique digital identity within the digital identity network, wherein the mobile device (101) is associated with a unique set of device information and the unique set of device information is incorporated into the first generated digital identity associated with the specific user, wherein the first generated digital identity is available to be used by the plurality of client systems registered on the digital identity network for authentication of the specific user.
2. SYSTEM (100, 200), according to claim 1, characterized in that the first trust relationship between the first client system (130) and the specific user is based on a predefined record and authentication of the specific user by the first client system (130).
3. SYSTEM (100, 200), according to claim 1, characterized by the specific user's fraud risk assessment including at least one of knowledge-based authentication, cross-channel comparison, out-of-band authentication, known fraud exchange assessment, speed analysis of the use of personally identifiable information, transaction speed analysis for the specific user, transaction data analysis, biometric analysis, comparison of the specific user's personally identifiable information against a set of known personally identifiable information associated with a fraud risk, and device reputation analysis.
4. SYSTEM (100, 200), according to claim 1, characterized in that each client system (130) of the plurality of client systems is associated with a specific set of entity-specific authentication rules (147), wherein each specific set of entity-specific authentication rules (147) identifies a set of transactions for a specific client system (130) and identifies an authentication level required by users associated with the transactions.
5. SYSTEM (100, 200), according to claim 4, characterized in that at least some of the transactions for a specific client system (130) require at least one additional first authentication operation for users associated with the transactions, wherein the at least one additional first authentication operation comprises a first authentication request to be transmitted from the partner system (160) to a specific mobile device (101) previously linked to the digital identity associated with the specific transaction, the partner system (160) further configured to transmit the first authentication request to the trusted mobile application (105) installed on the specific mobile device, wherein the first authentication request is submitted through the trusted mobile application (105).
6. SYSTEM (100, 200), according to claim 5, characterized in that the first additional authentication request comprises a request for biometric input of the user associated with the digital identity through the trusted mobile application (105).
7. SYSTEM (100, 200), according to claim 5, characterized by the first additional authentication request comprising a request for a response through user input to an authentication challenge Petition 870250100007, of 10 / 31 / 2025, page 80 / 98 4 / 9.
8. SYSTEM (100, 200), according to claim 5, characterized by the instructions instructing at least one processor (103) to: receive a response to the first authentication request transmitted from the trusted mobile application (105) installed on the specific mobile device; validate the received response; in response to a valid response to the first authentication request, authorize the transaction; and in response to an invalid response to the first authentication request, deny authorization of the transaction.
9. SYSTEM (100, 200), according to claim 5, characterized by performing a fraud detection assessment on each requested transaction associated with the first digital identity, wherein the fraud detection assessment is performed for each user transaction request when associated with the first digital identity.
10. SYSTEM (100, 200), according to claim 9, characterized by responding to potential fraud detection based on fraud detection assessment, performing at least one second additional authentication request, wherein at least one second additional authentication request comprises a second authentication request to be transmitted from the partner system (160) to a specific mobile device (101) previously linked to the digital identity associated with the specific transaction, the partner system (160) further configured to transmit the second authentication request to the trusted mobile application (105) installed on the specific mobile device, wherein the second authentication request is submitted through the trusted mobile application (105). Petition 870250100007, dated 10 / 31 / 2025, pp. 81 / 98 5 / 9 11. SYSTEM (100, 200), according to claim 10, characterized in that at least one second additional authentication request associated with the detection of potential fraud is made without a determination that the first additional authentication request is necessary.
12. SYSTEM (100, 200), according to claim 1, characterized in that the instructions instruct at least one processor (103) to: generate a second unique digital identity, in addition to the first unique digital identity, for use by the first client system (130) to reference the specific user during interactions between the first client system (130) and the partner system (160).
13. Non-transient computer-readable medium that stores computer-readable instructions executable by a computer, which when executed are configured to: identify (305) a request to register a specific user with a digital identity network, wherein the request is provided by a first client system (130) within a plurality of client systems in the digital identity network, wherein the specific user is associated with a first trust relationship with a first client system (130); characterized by obtaining (310) a set of personally identifiable information (PII) associated with the specific user through the first client system (130); perform (315) an identity verification (IDV) and fraud risk assessment analysis of the specific user based on the set of personally identifiable information obtained;and in response to satisfying (320) identity verification and fraud risk assessment analysis: generate (330) a first unique digital identity for the specific user Petition 870250100007, of 10 / 31 / 2025, page 82 / 98 6 / 9 for use within the digital identity network, where the first unique digital identity exclusively represents the specific user for a partnership system (160);transmit a generated image (335) representing the first unique digital identity to an interface of the first client system (130) associated with interactions with the specific user, wherein the transmitted image includes instructions for the specific user to capture a photo or send the image (340) to verify the identity of the specific user through a trusted mobile application (105) installed on a mobile device (101) associated with the specific user, wherein the trusted mobile application (105) is associated with the digital identification network and the partnership system (160);and in response to verification of the specific user's identity through the trusted mobile application (105) installed on the mobile device (101) verifying whether the photo or image matches the specific user's first unique digital identity, link (345) the specific user's mobile device (101) to the specific user's first unique digital identity within the digital identity network, wherein the mobile device (101) is associated with a unique set of device information and the unique set of device information is incorporated into the first generated digital identity associated with the specific user, wherein the first generated digital identity is available to be used by the plurality of client systems registered on the digital identity network for authentication of the specific user.
14. COMPUTER-READABLE MEDIUM, according to claim 13, characterized in that the instructions, when executed, are configured to: generate a second unique digital identity, in addition to the first unique digital identity, for use by the client's first system (130) to reference the specific user during interactions between the client's first system (130) and the partner system (160).
15. COMPUTERIZED METHOD (300, 400), performed by one or more processors (103), characterized in that the method (300, 400) comprises: identifying (305) a request to register a specific user with a digital identity network, wherein the request is provided by a first client system (130) within a plurality of client systems in the digital identity network, wherein the specific user is associated with a first trust relationship with the first client system (130); obtaining (310) a set of personally identifiable information (PII) associated with the specific user through the first client system (130); performing (315) an identity verification (IDV) and fraud risk assessment analysis of the specific user based on the set of personally identifiable information obtained;and in response to satisfying (320) identity verification and fraud risk assessment analysis: generate (330) a first unique digital identity for the specific user for use within the digital identity network, wherein the first unique digital identity exclusively represents the specific user for a partnership system (160);transmit a generated image (335) representing the first unique digital identity to an interface of the first client system (130) associated with interactions with the specific user, wherein the transmitted image includes instructions for the specific user to capture a photo or send the image (340) to verify the identity of the specific user through a trusted mobile application (105) installed on a mobile device (101) associated with the specific user, wherein the trusted mobile application (105) Petition 870250100007, of 10 / 31 / 2025, p. 84 / 98 8 / 9 is associated with the digital identification network and the partnership system (160);and in response to verification of the specific user's identity through the trusted mobile application (105) installed on the mobile device (101) verifying whether the photo or image matches the specific user's first unique digital identity, link (345) the specific user's mobile device (101) to the specific user's first unique digital identity within the digital identity network, wherein the mobile device (101) is associated with a unique set of device information and the unique set of device information is incorporated into the first generated digital identity associated with the specific user, wherein the first generated digital identity is available to be used by the plurality of client systems registered on the digital identity network for authentication of the specific user.
16. METHOD (300, 400), according to claim 15, characterized in that each client system (130) of the plurality of client systems is associated with a client system-specific authentication rule set (147), each client system-specific authentication rule set (147) identifies a set of transactions for a specific client system (130) and identifies a level of authentication required by users associated with the transactions, wherein at least some of the transactions for a specific client system (130) require at least one additional first authentication operation for users associated with the transactions, wherein at least one additional first authentication operation comprises a first authentication request to be transmitted from the partner system (160) to a specific mobile device (101) previously linked to the digital identity associated with the specific transaction,the trust system is still configured to transmit the first authentication request to the trust mobile application (105) installed on the specific mobile device, where the first Petition 870250100007 request, dated 10 / 31 / 2025, page 85 / 98 9 / 9 authentication is submitted through the trust mobile application (105)., 17. METHOD (300, 400), according to claim 16, characterized in that the first additional authentication request comprises a request for biometric input from the user associated with the digital identity through the trusted mobile application (105) or a request for a response through user input to an authentication challenge.
18. METHOD (300, 400), according to claim 16, characterized in that method (300, 400) further comprises: receiving (435) a response to the first authentication request transmitted from the trusted mobile application (105) installed on the specific mobile device (101); validating (445) the received response; in response (450) to a valid response to the first authentication request, authorizing the transaction; and in response (440) to an invalid response to the first authentication request, denying authorization of the transaction. Petition 870250100007, dated 10 / 31 / 2025, pp. 86 / 98