Systems and methods for blockchain-enhanced digital identity verification

Abstract

A system and method for identification verification based on consensus data. The method may include detecting a signal representing a data communication request of an application instance associated with a second endpoint device; determining whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network; receiving a signal representing valid identity token data from a node of the decentralized network; and transmitting, to the second endpoint device, response data related to the data communication request of the application instance.

Description

SYSTEMS AND METHODS FOR BLOCKCHAIN-ENHANCED DIGITAL IDENTITY VERIFICATION CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.63 / 775,812, filed on March 21, 2025, entitled “SYSTEMS AND METHODS FOR BLOCKCHAIN-ENHANCED DIGITAL IDENTITY VERIFICATION,” the entirety of which is hereby incorporated by reference.FIELD

[0002] Embodiments of the present disclosure generally relate to systems and methods of digital identity verification, and in particular to systems and methods for block-chain-enhanced digital identity verification.BACKGROUND

[0003] Blockchain technology uses a decentralized ledger spread across a network of computers (e.g., nodes) to record transactions. Each node in a blockchain network comprises a copy of the entire blockchain ledger. By decentralizing the ledger, rather than storing it at a central authority, the ledger is protected from fraud and cyberattacks. A blockchain ledger comprises a plurality of blocks, each of which contains transaction data. Once a block is added to the ledger, it is immutable. This immutability of blocks secures the history of transactions recorded by the decentralized ledger.

[0004] All transaction details are verified and agreed upon by consensus mechanisms (e.g., Proof of Work or Proof of Stake) before being added to the blockchain. These mechanisms ensure that all copies of the distributed ledger are the same across nodes in the blockchain network. Transactions on the blockchain can be further secured by cryptographic techniques, such as public key cryptography.SUMMARY

[0005] The present disclosure provides embodiments of a blockchain-enhanced digital identity verification system configured to combine one or more of endpoint-level user verification operations, decentralized verification operations, digital identity creation operations, behavioral analysis operations, tokenized incentive operations, or wallet-based account management operations. In some embodiments, systems andmethods may be configured to provide a trust layer for digital signal transmissions and interactions. For example, rather than verifying a user identity when the user logs into a service, embodiments of the present disclosure includes system configured to verify user identity and trust across ongoing device interactions, including one or more of communications operations, resource transfer operations, data transfer operations, application protocol interface (API) access operations, or service access operations.

[0006] As will be illustrated in the present disclosure, embodiments of systems include features to manage user identifiers that correspond to a user based on verification operations associated with a blockchain network. Embodiments of the present disclosure include system features associated with how cryptographic user identities are bound to endpoint device software, trust verification operations, endpoint / node device participation operations, and decentralized verification logs presented on a blockchain network.

[0007] In one aspect, the present disclosure provides a system for identity verification based on consensus data. The system may include a first endpoint device. The first endpoint device may include a processor; and a memory coupled to the processor. The memory may store processor-executable instructions that, when executed, configure the processor to: detect a signal representing a data communication request of an application instance associated with a second endpoint device; determine whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network; receive a signal representing valid identity token data from a node of the decentralized network; and transmit, to the second endpoint device, response data related to the data communication request of the application instance.

[0008] In some embodiments, determining whether the destination identifier corresponds to a valid identity token may be determined independent of the application instance associated with the second endpoint device.

[0009] In some embodiments, the signal representing the data communication request may include initiating an inbound or outbound communication channel with the application instance associated with the second endpoint device.

[0010] In some embodiments, the decentralized network may include a plurality ofcomputing nodes for generating consensus data for generating valid identity tokens associated with at least one of the first endpoint device and the second endpoint device.

[0011] In some embodiments, the processor may receive, from a node of the decentralized network, a signal representing invalid identity token data associated with the second endpoint device; and may transmit a signal representing a request for the second endpoint device to seek identity verification based on the consensus data of the decentralized network.

[0012] In some embodiments, the processor may receive a signal associated with a request to derive a subset portion of consensus data to verify a third user identity; transmit, to the decentralized network, the requested subset portion of the consensus data; and receive a signal representing a token coin as a response to the derived subset portion of the consensus data, wherein the token coin represents user value associated with the decentralized network.

[0013] In some embodiments, the processor may receive a signal representing a request for a user identifier associated with the first endpoint device; and may transmit a signal representing the user identifier to the second endpoint device for verification based on consensus data of the decentralized network, wherein verification of the user identifier is based on smart contract data structures defined by one or a combination of identity public key, identity hash, trust score, verification status, device identifier hash, token balance, or revocation or suspension status.

[0014] In some embodiments, the processor may determine that the signal representing the data communication request is generated by a non-human subject user; and may transmit a signal representing an alert signal for display at the first endpoint device.

[0015] In some embodiments, determining that the signal representing the data communication request is generated by a non-human subject user may be based on machine learning models trained based on features including geolocation patterns, transaction frequency, device fingerprint, verified versus unverified communication requests, single sign-on access behavior, or device update patterns.

[0016] In some embodiments, the destination identifier associated with the second endpoint device may include at least one of a public key, blockchain address, device identity hash, application instance identity certificate, server identity token, or a destination trust artifact, and wherein a valid identity token is associated with predefined trust criteria.

[0017] In another aspect, the present disclosure provides a method of identity verification based on consensus data. The method may include detecting a signal representing a data communication request of an application instance associated with a second endpoint device; determining whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network; receiving a signal representing valid identity token data from a node of the decentralized network; and transmitting, to the second endpoint device, response data related to the data communication request of the application instance.

[0018] In some embodiments, determining whether the destination identifier corresponds to a valid identity token may be determined independent of the application instance associated with the second endpoint device.

[0019] In some embodiments, the signal representing the data communication request may include initiating an inbound or outbound communication channel with the application instance associated with the second endpoint device.

[0020] In some embodiments, the decentralized network may include a plurality of computing nodes for generating consensus data for generating valid identity tokens associated with at least one of the first endpoint device and the second endpoint device.

[0021] In some embodiments, the method may include receiving, from a node of the decentralized network, a signal representing invalid identity token data associated with the second endpoint device; and transmitting a signal representing a request for the second endpoint device to seek identity verification based on the consensus data of the decentralized network.

[0022] In some embodiments, the method may include receiving a signal associated with a request to derive a subset portion of consensus data to verify a thirduser identity; transmitting, to the decentralized network, the requested subset portion of the consensus data; and receiving a signal representing a token coin as a response to the derived subset portion of the consensus data, wherein the token coin represents user value associated with the decentralized network.

[0023] In some embodiments, the method may include receiving a signal representing a request for a user identifier associated with the first endpoint device; and transmitting a signal representing the user identifier to the second endpoint device for verification based on consensus data of the decentralized network, wherein verification of the user identifier is based on smart contract data structures defined by one or a combination of identity public key, identity hash, trust score, verification status, device identifier hash, token balance, or revocation or suspension status.

[0024] In some embodiments, the method may include determining that the signal representing the data communication request is generated by a non-human subject user; and transmitting a signal representing an alert signal for display at the first endpoint device.

[0025] In some embodiments, determining that the signal representing the data communication request is generated by a non-human subject user may be based on machine learning models trained based on features including geolocation patterns, transaction frequency, device fingerprint, verified versus unverified communication requests, single sign-on access behavior, or device update patterns.

[0026] In some embodiments, the destination identifier associated with the second endpoint device includes at least one of a public key, blockchain address, device identity hash, application instance identity certificate, server identity token, or a destination trust artifact, and wherein a valid identity token is associated with predefined trust criteria.

[0027] In another aspect, a non-transitory computer-readable medium or media having stored thereon machine interpretable instructions which, when executed by a processor may cause the processor to perform one or more are described.

[0028] In various aspects, corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods are described.

[0029] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0030] Many features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the present disclosure.DESCRIPTION OF THE FIGURES

[0031] In the figures, embodiments are illustrated by way of example. It is to be expressly understood that the description and figures are only for the purpose of illustration and as an aid to understanding.

[0032] Embodiments will now be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0033] FIG. 1 illustrates a system for identity verification based on consensus data, in accordance with embodiments of the present disclosure;

[0034] FIG. 2 illustrates a flowchart of a method for establishing a digital identity, in accordance with embodiments of the present disclosure;

[0035] FIG. 3 illustrates a flowchart illustrating operations of the system of FIG. 1 , in accordance with embodiments of the present disclosure;

[0036] FIG. 4 illustrates a flowchart illustrating operations of the system of FIG. 1 , in accordance with embodiments of the present disclosure;

[0037] FIG. 5 illustrates a flowchart illustrating operations of the system of FIG. 1 , in accordance with embodiments of the present disclosure;

[0038] FIG. 6 illustrates a flowchart illustrating operations of the system of FIG. 1 , in accordance with embodiments of the present disclosure;

[0039] FIG. 7 illustrates a flowchart of a method of consensus-based identity verification, in accordance with embodiments of the present disclosure;

[0040] FIG. 8 illustrates a block diagram of a computing device, in accordance with embodiments of the present disclosure;

[0041] FIG. 9 illustrates an example graphical user interface of a token wallet displayed at a node / computing device, in accordance with embodiments of the present disclosure;

[0042] FIG. 10 illustrates an example graphical user interface of a verification request interface displayed at a node / computing device, in accordance with embodiments of the present disclosure;

[0043] FIG. 11 illustrates an example graphical user interface for retrieving user input for output identity verification and confirmations, in accordance with embodiments of the present disclosure;

[0044] FIG. 12 illustrates an example graphical user interface for display at a node / computing device for managing a plurality of devices associated with a user identity account, in accordance with embodiments of the present disclosure;

[0045] FIG. 13 illustrates an example graphical user interface for display at a node / computing device for managing a user identity account, in accordance with embodiments of the present disclosure;

[0046] FIG. 14 illustrates an example graphical user interface for display at a node / computing device for managing a user identity account corresponding to data structures submitted on the blockchain network, in accordance with embodiments of the present disclosure;

[0047] FIG. 15 illustrates an example graphical user interface for display at a node / computing device for managing verified user identities, in accordance with embodiments of the present disclosure;

[0048] FIG. 16 illustrates an example graphical user interface for display at a node / computing device for managing tokens, in accordance with embodiments of the present disclosure; and

[0049] FIG. 17 illustrates an example graphical user interface for display at a node / computing device for managing the node as an endpoint having a user identity verified via the blockchain network, in accordance with embodiments of the present disclosure.DETAILED DESCRIPTION

[0050] The present disclosure provides embodiments of systems and methods for blockchain-enhanced digital identity verification. An ecosystem may be a closed or secure system based on a user identity is associated with a node / client device as an endpoint. Although the node / client device could be physically compromised if a user leaves it unlocked somewhere, embodiments of the present disclosure may include features such that decentralized logs and verification histories remain accurate and tamper-resistant because they are tied to the decentralized identity network and device bindings. For example, if a device is stolen, the decentralized verification logs continue to tell the story. The user can track the history back to the point of loss, rebuild trust, suspend the account, or shut down affected devices from another device on their network.

[0051] In some examples, blockchain technology may be based on a decentralized ledger spread across a network of computers or nodes to record data transactions. Each node may store a copy of the ledger. Because the ledger is decentralized instead of being stored by a central authority, it may be less prone to fraud and cyberattack operations. A blockchain may include data blocks containing transaction data. Once a data block is added to the chain it becomes effectively immutable, and the history of transactions can be trusted as a tamper-resistant record.

[0052] Consensus mechanisms such as Proof of Work and Proof of Stake are examples of methods used in blockchain systems to ensure that nodes (e.g., client devices associated with the blockchain network) agree on the state of the ledger. Data transactions may further be secured through public key cryptography and digital signatures. Embodiments of the present disclosure include systems and methods that may be configured on such blockchain principles and may include features based on decentralized digital verification as part of a broader digital identity and endpoint security architecture.

[0053] In some examples, digital identity verification systems may be configured as centralized, software application-layer based systems. A user associated with a user device may authenticate after software applications are launched and after network communication protocols may already be established. In some scenarios, unscrupulous users may exploit such system configurations based on phishingoperations, impersonation operations, creation of synthetic identities, creation of fraudulent wallets, creation of face accounts, promulgating malicious uniform resource locators (URLs), providing bot-driven interactions, and conducting social engineering operations, among other example operations. In some scenarios, centralized and software application-layer based systems may store log files and user identification data on a centralized computing platform, providing potentially exploitable sources of data sets by an unscrupulous users.

[0054] Some example user identity systems and platforms may be centralized, may store large volumes of user identity data, may rely on application software-layer logic, and may not allow users to request verification of other network users and systems that the subject user may be interacting with.

[0055] It may be desirable to provide systems and methods for conducting user identification verification at user devices (e.g., endpoints), such that user identification verification may be based on a decentralized identification verification system and architecture. In some embodiments provided in the present disclosure, systems and methods for blockchain-enhanced digital identity verification may be based on a decentralized network to verify whether counterparties, message destination devices, communications, or transactions may be ‘trusted’ prior to proceeding with one or more contemplated downstream operations.

[0056] As will be disclosed based on embodiments described in the present disclosure, systems and methods for blockchain-enhanced digital identity verification may be configured such that digital identity verification should not be limited to login events or centralized database. Instead, embodiments of systems and methods described herein may be based on user device-level and network-level trust architecture such that user identity verification operations are caried out before application execution, before transmission of communication signals, prior to value transfer, and before a user engages with another party online. Thus, embodiments of systems and methods of the present disclosure may be configured to verify digital user identities as well as at least one of verifying users, devices, services, or destination devices of signals.

[0057] Embodiments of the present disclosure may include systems and methods configurable for one or more use case scenarios. For example, systems and methodsprovided in the present disclosure may be implemented for resource transfer transactions, such as financial transfer transactions, among other examples, where a banking application may be configured to initiate a transfer of funds. In the present example, embodiments of systems may be configured to detect signals representing an outbound transaction request, extract a destination wallet user identifier, verify the recipient wallet user identity token on a blockchain network, and either allow and log the transaction operation if the identity is verified, or block and log the transaction operation if the destination is not verified. Such features may reduce fraudulent operations, misdirected transaction payments, or social engineering operations.

[0058] In another example scenario, systems and methods provided in the present disclosure may be configured for subscriber list use cases. A user, via user device, may attempt to subscribe to or receive communications from a service platform. Embodiments of systems may conduct operations to verify whether the list owner or sender is represented by a valid verified identity token. If the source is not verified, the subscription or communication operation may be flagged, limited, or blocked. Such scenarios may benefit from embodiments of the present application for high-trust communities, private groups, or protected subscriber ecosystems.

[0059] In another example scenario, systems and methods provided in the present disclosure may be configured for social media and networking platforms. A user, via a user device, may attempt to message, follow, connect with, or otherwise engage with a user associated with another account. Embodiments of systems may verify whether the counterparty is a verified participant in the network, thereby reducing likelihood of fake profiles, automated software (BOT) networks, impersonation operations, or fraudulent outreach operations.

[0060] In another example scenario, systems and methods provided in the present disclosure may be configured for Internet site visits and uniform resource locator (URL) scenarios. When a user, via a user device, generates a request to access a website or connect to a destination server, embodiments of systems may be configured to verify the destination identity and can generate signals representing messages to warn the user, block access, or reroute if the site is not verified, thereby promoting phishing prevention and secure Internet browsing operations.

[0061] In another example scenario, systems and methods provided in the present disclosure may be configured for enterprise API access operations, such as forwhen a corporate system generates a request to send sensitive data to another server or service endpoint. Embodiments of systems may be configured verify the identity token of the receiving server. If the receiving server identity meets pre-established trust criteria, a data transmission connection may proceed; otherwise the data transmission connection may be denied or blocked, thereby providing machine-to-machine trust based on decentralized verification instead of centralized allowlists alone.

[0062] FIG. 1 illustrates a system 100 for blockchain-enhanced identity verification in accordance with some embodiments described herein. The system 100 may comprise a digital identity platform.

[0063] The system 100 comprises a blockchain infrastructure 102. The blockchain infrastructure 102 is configured to maintain the anonymity of a user. The blockchain infrastructure 102 may be further configured to award or otherwise distribute tokens to users. Such tokens may be distributed or awarded to users after a user participates in a transaction that is added to the blockchain. In some implementations, the tokens may be convertible into cryptocurrency.

[0064] The system 100 may be implemented using a decentralized system in which identity verification does not rely on a central authority. Instead, the blockchain infrastructure 102 could handle authentication. For example, multiple nodes (e.g., hardware devices, devices, clients) 104 across the internet belonging to users may participate in the authentication process. Multiple nodes 104 may be used to implement consensus-based verification, such that multiple nodes 104 validate information. This approach distributes the power of a single node to verify information, reducing the likelihood of fraud and errors.

[0065] The nodes 104 may comprise at least a first client device (e.g., user device) such as a cell phone, tablet, wearable, or computer. The system 100 may be configured to anonymously and securely authenticate online activities of a user of a client device. The system 100 may be configured to authenticate online activities of a user without involvement of any third parties for verification. The system 100 may be implemented as software on a client device that loads underneath the device’s operating system in the device hierarchy. The software may comprise a node thatcommunicates with the internet.

[0066] In some implementations, a user of the system 100 would create a digital identity tied to a unique blockchain address or smart contract. This identity would be associated with verifiable credentials such as biometric data (e.g., fingerprints, facial recognition), government-issued IDs, or behavior patterns. Identity verification is performed using a consensus mechanism in which multiple nodes (e.g., other users, services, etc.) on the blockchain network confirm the authenticity of the data submitted. Smart contracts are self-executing contracts with the terms of the agreement directly written into lines of code. In terms of identity verification, smart contracts would automatically enforce rules for identity validation, update records upon successful verification, and manage token distribution for user activities, all without human intervention.

[0067] In some implementations, multi-factor authentication (MFA) is used to enhance security of the system 100 as the user establishes their digital identity. The system 100 may, for example, require two or more verification methods upon each login attempt by a user. For example, the system 100 may require verification via something that the user knows (e.g., a password or a personal identification number (PIN)), something that the user has (e.g., a smartphone or a hardware token), and something that the user is (e.g., biometric verification).

[0068] In some implementations, each time that a user performs a verifiable action using the system 100, the system 100 may use a smart contract to generate tokens as a form of reward for and record of the activity. For example, the user may be awarded tokens upon logging in to the system 100 or completing a task. The tokens awarded to the user may constitute a reward for the verifiable action taken and may help to create a record of the user activity in the system 100.

[0069] In some implementations, the system 100 may comprise software 108 that can be installed on hardware devices. Installation of software configured to implement the system 100 on hardware effectively turns such hardware devices into endpoints of the security network. The software 108 may be configured to manage keys, handle encryption and decryption processes, and ensure secure communication with the blockchain network 102. The software 108 could also store a local, encrypted version of the user’s digital identity, enabling offline verification and token generation whichsyncs once the device goes online. The software 108 comprising the blockchain verification software may be installed on devices 104 belonging to users prior to the operating system such that every program run on a device 104 must go through the blockchain identity verification protocol.

[0070] By establishing an endpoint on a hardware device 104, the system introduces a physical layer of security to digital interactions, creating a barrier that's much harder for cyber attackers to breach than a digital wallet. The system can leverage hardware-based encryption and secure elements, ensuring that cryptographic keys and sensitive data are stored in a tamper-resistant environment. Further, integration of an endpoint on a hardware device 104 offers protection against a wide range of attacks including software vulnerabilities, malware, and phishing, due to its isolated operation from potentially compromised operating systems. Endpoints can be integrated into the device's 104 architecture, allowing for deeper interaction with the device’s features. Endpoints integrated on hardware devices 104 can perform security functions at a lower level, directly interacting with the hardware, offering more robust protection and seamless user experiences. This integration enables the endpoint to securely manage and verify digital identities and transactions directly on the device, offering a holistic approach to security.

[0071] The endpoint software 108 could further be configured to monitor device behavior in real-time. In some implementations, the endpoint software may be configured to use artificial intelligence (Al) to learn normal user patterns and detect anomalies that might indicate a security threat. The system could be configured to isolate suspicious activities, quarantine potentially malicious software, and ever reverse actions taken by a user if it detects that the actions are part of a cyber-attack.

[0072] The system 100 further comprises an applications cloud 110. The applications cloud 110 may comprise an online location that stores software. A user of hardware 104 may interact with the applications cloud 110 to download software that is available in the applications cloud 110. Upon downloading the available software from the applications cloud 110, a user may begin generating an account (e.g., a digital identity) as described further below. Thus, by downloading software from the applications cloud 110, the user may be guided through the process of setting up their infrastructure to begin using the system 100.

[0073] A user may interface with the applications cloud 110 via the application layer 106. For example, a user may access the application layer 106 via a node (e.g., user hardware) 104. In some implementations, an applications layer 106 of the endpoint may be configured to monitor device behavior in real-time. In some implementations, no logs or information relating to user identity are configured to be stored in the applications layer. Instead, information may be stored in secure local storage of software 108. Accordingly, the system 100 may be configured to operate without relying on cloud storage.

[0074] FIG. 2 illustrates a flowchart 200 of a method for establishing a digital identity in accordance with some embodiments described herein.

[0075] At 202, a user may create an account as part of an onboarding and identity verification step. For example, a user may have to enter at least one or their email or their phone number. A user may have to create a secure password for their account. In some implementations, a user may set up multi-factor authentication (MFA) using at least one of their email, an SMS code, and biometrics. For example, biometrics may comprise a fingerprint. Biometrics may comprise facial recognition data. A user may create an account using, for example, a user device 104 of FIG. 1 .

[0076] The account creation at 202 may further comprise the creation of a blockchain identity. In other words, the account creation at 202 may allow a user to establish a unique digital identity (e.g., a blockchain identity) that they can use to interact with the blockchain. For example, the system may be configured to generate a unique blockchain identity tied to the user’s biometrics and device endpoint. As part of the creation of a blockchain identity, a backup recovery key may be generated. The backup recovery key may be securely stored by the user. The account creation 202 may allow a user to interact with the blockchain infrastructure 102 of FIG. 1 .

[0077] At 204, the system 200 may be configured to perform a plurality of verification steps for the user. For example, the system may be configured to perform community vouching in which existing users and trusted contacts of the system 200 vouch for the authenticity of the new user. In some implementations, the system 200 may be configured to perform external document verification. For example, a user creating an account may need to upload an identification document (e.g., a passport or another government-issued ID) for authentication. The authentication or verificationof the uploaded document may be powered by artificial intelligence. The system 200 may further be configured to perform behavioral analysis of a user to verify the authenticity of a user creating an account. For example, the system 200 may be configured to monitor interaction patterns of a user with the system 200. Based on the monitored interaction patterns, the system 200 may be configured to establish a userspecific activity profile.

[0078] In some implementations, when the user is successfully verified by the system 200, an immutable identity token on the blockchain is created by the system. The immutable identity token serves as evidence of the creation of a digital identity for a user. In certain implementations, a user may earn initial tokens for completing the verification.

[0079] At 206, a user that was verified may establish a wallet account. In some implementations, establishing a wallet account may comprise linking the unique digital blockchain identity established at 202 and verified at 204 to a secure digital wallet. The secure digital wallet may be accessible by an application e.g., via a client device such as a smartphone. The digital wallet may be configured to display any of a user’s account balance, transaction history, referral earnings and charitable contributions.

[0080] The digital wallet established at 206 may further be configured for token management. For example, the digital wallet may be configured to highlight token usage options (e.g., converting tokens to cryptocurrency, donating to charitable wallets, or staking for higher earnings). In further implementations, the digital wallet established at 206 may be configured to generate call-to-action prompts. For example, the digital wallet established at 206 may be configured to encourage users to invite other users to the platform to earn referral bonuses. Further, the digital wallet established at 206 may be configured to educate users on enhancing security through additional verification options.

[0081] After a user establishes a wallet account at 206, a user can initiate a transaction. For example, a user may initiate a payment or a transfer. The user may select an amount of money to be paid or transferred and may also select the recipient of the payment or transfer. The user may further select a purpose for the transaction. Metadata describing the transaction is encrypted and prepared for submission.

[0082] For the transaction to proceed, a user may have to complete multi-layerverification. For example, when a user requests a transaction, the system may prompt the user to confirm their identity. In some implementations, the user may verify their identity using biometrics (e.g., a fingerprint or facial recognition). In certain implementations, the user may use a dynamic personal identification number (PIN) or one-time password (OTP) to verify their identity. In further implementations, a user may use optional behavioral authentication based on keystrokes or activity patterns to verify their identities.

[0083] Once the user has completed multi-layer verification, the requested transaction can proceed to blockchain authorization. At 208, information from the internet gets tunneled through the endpoint to a user device, such as device 104 of FIG. 1 , via the software 108 . The information from the internet serves to create a verifiable log that a user’s identity was associated with a transaction. This information can be stored in secure local storage within the software 108. devices may be tunneled through the endpoint to the wallet established at 206.

[0084] A smart contract of the blockchain verifies the identity of the user and the transaction details. The system is configured such that the transaction is executed only if all parameters of the user identity and transaction details match the authorized identity profile established in 202. The account of the transaction can be published to the blockchain at 210.

[0085] Upon authorization of the transaction by the blockchain, the transaction requested by the user may be completed. In some implementations, a user may earn tokens for completing secure transactions on the blockchain. The system may be configured to generate a notification to confirm the success of a transaction. The system may further be configured to record an immutable entry in a ledger maintained by the blockchain upon the completion of a transaction.

[0086] The system may further be configured to detect digital identity misuse among users. For example, the system may be configured to identify a login attempt or a transaction request from an unrecognized device or location. The system may further be configured to flag behavioral analysis anomalies, including unusual activity patterns or rapid actions that are inconsistent with past behaviors.

[0087] In some implementations, the system is configured to send immediate alerts to a user upon the detection of a suspected digital identity misuse. The system maybe configured to prompt a user for verification upon the detection of a suspected digital identity misuse. For example, the system may be configured to send a notification to a legitimate user (e.g., via email, SMS, or a push notification) if it is suspected that a malicious party is attempting to access the system using their identity. Upon such a detection of a suspected identity misuse, the system may be configured to temporarily lock the session in which the suspected identity misuse was detected. The system may further be configured to request re-authentication from the legitimate user. The user may be able to approve or deny the attempt to use their identity. For example, the system may be configured to prompt the user to verify their current activity. If the user denies the attempt to use their identity (e.g., if the user’s verification of their current activity indicates that the suspected identity misuse is illegitimate), then the system may block the unauthorized attempt and disable compromised tokens. Further, the system may be configured to log the identity misuse for investigation. The system may be configured to send security recommendations to the user whose identity was used in the identity misuse. For example, the system may be configured to send a password reset or biometric re-enrollment to a user if it is determined that an attempt to access the system using the user’s identity was unauthorized.

[0088] In some implementations, upon the detection of a suspected identity digital misuse, the system is further configured to require additional authentication steps from a user. For example, the system may be configured to acquire a live biometric scan of the user. The system may further be configured to pose at least one security question to a user. The system may further comprise an artificial intelligence module that is configured to monitor and log further attempts to access the system using the user’s identity. In some implementations, the system is configured to notify partners (e.g., banks and airlines) to freeze services that are linked to the account of the user.

[0089] The system may provide for recovery and reinforcement of a user’s digital identity upon the detection of a suspected digital identity misuse. For example, the system may be configured so that a user can reinstate their digital identity with updated credentials. The system may also be configured so that a user can reinstate their digital identity with enhanced verification steps. In some implementations, the system is configured to incentivize quick recovery of a compromised digital identity by providing immediate token rewards to a user for verifying and reclaiming their digital identity.

[0090] The system may be configured for integration with at least one external partner (e.g., a bank or an airline). In some implementations, a user can log into a partner’s website using the system as the single sign-on system. The system communicates with the partner’s server via an application programming interface (API) to verify the user’s blockchain identity token. The partner’s server cross-checks with the system’s decentralized ledger to confirm the legitimacy of the user’s identity. Successful authentication of the user’s identity may grant the user access to the services of the partner’s website. Unsuccessful authentication of the user’s identity may trigger additional verification steps or security alerts. Transactions (e.g., payments or reservations) may be directly processed through the system, which may bypass intermediaries and thus reduce fees. A user may earn tokens for each verified transaction.

[0091] In some implementations, the system may be configured to offer referral and growth incentives to a user. For example, the system may be configured to provide tokens to users that refer other users to the system. The number of tokens awarded to a user may scale with the activity level of the referred users. There may be tiered rewards offered to users based on the number of referrals they generate and based on the engagement metrics of the referred users. In some implementations, higher tiers unlock better staking options and larger bonuses. In certain implementations, the system may be configured with partnered referral programs. For example, the system may be used with banks, airlines, and merchants to encourage adoption. Users may be given additional tokens for completing transactions with partners that integrate with the system.

[0092] In some implementations, users may stake tokens to increase rewards and gain higher security rankings. In further implementations, tokens may be pledged to charitable wallets. The system may be configured such that tokens pledged to charitable wallets increase accrual rates, which reinforces philanthropic giving through the system. The system may be configured with a limited token supply. The limited token supply helps to maintain token value. The system may further be configured with deflation mechanisms like token burning for inactive wallets.

[0093] The system may be configured with security and continuous monitoring. For example, the system may employ endpoint monitoring to track device usage, behavior patterns, and geolocation of users. The system may use endpoint monitoring to detectanomalies. The system may further be configured with Al-driven threat detection. The system may use Al to learn patterns and dynamically detect unauthorized attempts. In some implementations, endpoint monitoring may be used to immediately freeze an account and to provide recovery options if an identity misuse is suspected.

[0094] In some embodiments of the present disclosure, systems and methods may be configured based on a combination of cybersecurity operations, blockchain network infrastructure, endpoint device security operations, device-level software operations, digital identity verification operations, and transmission of trusted communication messages.

[0095] In some embodiments, systems may be configured for user identity verification prior to sending or receipt of digital communication messages among a network of user devices. For example, systems may be configured to conduct operations of user identity verification at a software endpoint lawyer of a user device based on decentralized blockchain verification rather than relying solely on centralized, application-layer authentication operations.

[0096] Referring again to FIG. 1 , the system 100 may be configured based on user identity verification operations at a software endpoint execution layer, rather than solely at a software login or application level. In some embodiments, the system 100 may be configured to conduct operations of outbound verification, where a client device or node 104 may be configured to request that a user, digital wallet, server system, service platform, or other destination with which communication messages may be exchanged also be verified.

[0097] In some embodiments, the system 100 may be configured to provide community-based or distributed identity verification, rather than verification based on a single centralized authority. In particular, embodiments of the system 100 of the present disclosure include features associated with a decentralized verification log associated with a blockchain network 102, such that there is no central or dedicated database system entity storing or verifying digital transaction messages among nodes or client device 104.

[0098] In some embodiments, the system 100 may be based on behavioral or Al-supported analysis operations for distinguishing legitimate human-user generated message interactions from unscrupulous or computer-generated messageinteractions.

[0099] In some embodiments, the system 100 may be based on a tokenization platform coupled to verified network participation among a plurality of nodes 104. As will be disclosed herein, embodiments of systems and methods may be configured with features that enhance digital identity wallet features, user identity application operations, and / or blockchain network infrastructure features.

[0100] In some embodiments, the node or client device 104 may be configured at a software terminal level of the device 104 so as to conduct software boot operations alongside startup software when the device 104 is powered on. Unlike an ordinary application that executes operations on top of an operating system and conducts operations based on a graphical user interface and higher-level operating system services, embodiments of the present disclosure include methods to conduct user identity verification operations parallel to, beneath, or adjacent to the software operating system stack.

[0101] In some embodiments, the system 100 may include a software application 108 installed at a node or device 104, thereby configuring the node or device hardware into endpoints of a security network. In some embodiments, the software application 108 may include user identity verification operations that integrate with one or more of the following software stack layers: a bootloader level, firmware level, trusted execution environment (TEE), secure enclave, kernel module, and / or hypervisor or secure execution layer.

[0102] In some embodiments, during device 104 startup operations, the software application 108 may include operations for execution before or alongside operating system operations and registers hooks with process creation handlers, network stack execution, kernel execution control, and other system-level events. Such operations may allow the client device 104 to verify trust before execution or communication rather than reacting after target communication software has already launched. That is, the software application 108 including user identity verification operations is not simply conducting operations that are associated with a single software application, but may be conducting user identity verification operations associated with a broader software application layer of the device 104. As such, the software application 108 may log the user’s activities and interactions with third parties independent of whetherthe application itself has its own login, account system, or application-specific security.

[0103] As will be disclosed herein, embodiments of systems and methods for identity verification may be based on a node or client device 104 (e.g., an endpoint) conducting operations in combination with a decentralized verification blockchain network architecture, such that a trust decisioning layer need not be centralized and need not rely on a third-party security operations center (SOC).

[0104] As described herein, the system 100 may be configured to conduct operations of outbound verification, where a client device or node 104 may be configured to request that a third-party user, digital wallet, server system, service platform, or other destination with which communications messages may be exchanged also be verified.

[0105] In some embodiments, operations of outbound verification may be conducted based on the software application 108 and may include operations to verify identity of users of nodes or client devices 104 in combination with requesting identity verification of a destination party device or server prior to proceeding with data communication messages, transfers, connections, or other data transaction operations.

[0106] As an example, a user of a node or client device 104 may conduct operations to initiate an inbound or outbound interaction with another computing device and may desire to verify the identity of the other computing device (e.g., a counterparty computing device). Embodiments of the software application 108 may include operations to request that a user of the counterparty computing device conduct user identity verification operations, thereby contributing to contributing to a network of verified users and trusted communication networks among nodes or client devices 104.

[0107] In some embodiments, the software application 108 configured with outputbound verification operations may be implemented at the endpoint software layer. When an outbound communication request is generated by an application, the software application 108 may include operations to detect communication requests at the kernel layer, hypervisor layer, secure execution layer, firmware-adjacent layer, or other endpoint execution layer before the network stack transmits communicationmessages.

[0108] In some embodiments, the software application 108 may include operations to determine the destination identifier, which may include a public key, blockchain address, device identity hash, application identity certificate, server identity token, or other destination trust artifact. The endpoint software application 108 may conduct operations to query either a local copy of blockchain state or a remote blockchain node to determine whether the destination possesses a valid identity token meeting predefined trust criteria.

[0109] If the recipient or destination identity is verified, the data communication interaction proceeds. If the destination is not verified, software application 108 may include operations to block the interaction, quarantine the communication, alert the user, or prompt the user to request identity verification from the destination. Accordingly, in some embodiments, verified users of a node or client device 104 may transmit and receive data or communication messages with verified users based on the system 100, thereby providing a digital trust network of nodes at least because users begin selecting verified users over unverified users for transmitting and receiving communication messages.

[0110] As described, some example user identity and endpoint verification platforms may conduct operations at an application level or may conduct operations based on centralized user identity verification monitoring models. In some examples, systems may conduct operations to monitor data transmission locally, send telemetry to a remote service, perform analysis in a remote security operations center or cloud platform, and then generate alerts or actions based on centralized system operations to a client device.

[0111] It may be desirable to provide systems and methods for conducting user identification verification at user devices (e.g., endpoints), such that user identification verification may be based on a decentralized identification verification system and architecture.

[0112] In some embodiments, the system 100 may configure endpoint nodes or client devices 104 may monitor, at the client device 104, communication messages among a network of nodes and conduct operations to verify identity interactions basedon the blockchain infrastructure 102. In some embodiments, the blockchain infrastructure 102 may be configured as a user identity verification layer, rather than a centralized database. Thus, a central monitoring authority is not required for user identity verification. A global database of user behavior is not required for user identity verification. User identity verification operations may be based on decentralized consensus. Further, users of nodes or client devices 104 may maintain communication logs within user accounts or device 104 environments.

[0113] In some embodiments, two or more devices may be associated with a verified user identity (e.g., an account) and the two or more devices may be associated with a shared synchronized log across a user’s device network. In some embodiments, the system 100 may be configured to operate in a fully decentralized mode, a private node mode, or local-device coordination mode.

[0114] Reference is made to FIG. 3, which illustrates a flowchart 300 illustrating operations of the system 100 of FIG. 1 , in accordance with embodiments of the present disclosure. The flow chart 300 may include operations conducted by the blockchain network 102, a node or client device 104, or one or more other computing devices of the system 100.

[0115] In some embodiments, operations of the node or client device 104 may be based on the software application 108. In some embodiments, the software application 108 may provide features of a user identity verification wallet for the node / client device 104 operating as an endpoint.

[0116] At operation 310, the node / client device 104 may receive a signal representing a request to create a user account. The user account may be associated with a user of the node / client device 104 for user identity verification operations.

[0117] At operation 320, the node / client device 104 may conduct operations of a verification process. In some embodiments, the node / client device 104 may conduct operations of a consensus mechanism for identity verification. Consensus-based verification may be based on a plurality of nodes of the blockchain network 102 agreeing that a verification result is achievable and valid. In some embodiments, consensus-based operations may be based at least on: (1 ) the user of the node / client device 104 being verifiable and a legitimate node holder or participant on the blockchain network 102; and (2) a relatively high percentage of other nodes, users, oraccounts agreeing with the verification result.

[0118] As an illustrating example, 99 out of 100 participating verification nodes may be required to agree before a user identity verification is confirmed. The threshold number of participating verification nodes agreeing with a user identity verification may be established based on an implementation, policy, or private-network configuration. That is, user identity verification may be based on a distributed agreement among nodes of the blockchain network 102 rather than unilateral assertion of user identity verification.

[0119] In scenarios where the threshold umber of participating verification nodes may not be met, a signal representing disagreement among the participating verification nodes may be transmitted to the node / client device 104. In such scenarios, the node / client device 104 may conduct operations to: ask a source to verify themselves, terminate the communication with a counter-party device, conduct system checks to determine that no unexpected operations have been conducted, rerequest the identity verification operation, or receive a signal representing a report on the disagreement in the log.

[0120] In some embodiments, during verification during user account initialization, multiple existing node users may participate in verifying a new user identity. The system 100 may be configured to intentionally distribute and randomize assigned node tasks, such as visual confirmation, biometric validation, behavioral validation, or identity document verification operations for verifying a new user identity. That is, no single user of a participating verifying node conducts all verification tasks. The distributed model may reduce risks of collusion or fraudulent vouching at least because the process of collecting and validating the user’s identity is distributed and spread across users associated with a plurality of nodes / client devices 104.

[0121] In some embodiments, verification by an existing node of a new user identity may be weighted according to trust score, prior verification accuracy, activity level, and network reputation. In some embodiments, anti-collusion of verifying the new user identity may be based on weighting in combination with randomization and task separation. If a particular node user is tasked with visual validation of a new user identity, that particular node user may not be tasked with biometric or behavioral review of the new user identity. Accordingly, new identity verification is based on a collectiveoperation of trust processes across the blockchain network 102.

[0122] In some embodiments, user identity verification may be based on behavioral verification that may consider user keystrokes, timing patterns, interaction styles, request cadence, destination trust patterns, or historical usage comparisons. In some embodiments, the node / client device 104 may source or store behavioral verification data and train on the inbound and outbound activity of a user's account and devices rather than just website usage.

[0123] In some embodiments, the node / client device 104 may store data representing a complete record of what the user interacts with across the device lifecycle, not just websites. That includes applications, requests, communications, secure transactions, account patterns, and verification events. In some embodiments, behavioral profiles may be stored as local models, signed local histories, or privacypreserving trust profiles associated with identity tokens. The system 100 may conduct operations to compare current activity to historical tendencies to determine whether activity is typical. In some scenarios, thresholds or confidence levels may trigger alerts. One example is a 95 percent identity confidence threshold. In some embodiments, the node / client device 104 may determine whether the interaction is verified or unverified. The blockchain network 102 may provide agreement or disagreement based on user verification status, thereby providing a threshold model. In some embodiments, the system 100 may implement low, medium, and high thresholds. At this stage the system may not automatically act on all alerts. It may instead inform the user and let the user choose the response. An alert can be any activity that is not a push or pull request by the user that is verifiably trackable.

[0124] As an illustrating example, a browser may include auto-fill text functionality. A browser may have stored many historical interactions, including payment or travel data. If sensitive information such as a credit card number is entered on the wrong site or the wrong form, the node / client device 104 may generate an alert and ask the user: Did you enter your credit number on this site? No? Yes? What do you want to do?

[0125] In some embodiments, the node / client device 104 may conduct operations to determine whether operations are based on human input or computer-implemented input for analyzing the speed and timing of inputs. In some embodiments, the node / client device 104 may include an Al agent as a security analyst, such that operations of the Al agent may retrieve logs and interactions and generate a suggestion on how to decipher unusual events, warn of unusual or unexpected sequence of events, and identify possible unexpected identity verification results.

[0126] In some embodiments, operations of Al agents may include neural network, isolation forest, random forest, or support vector machine operations. In some embodiments, data points or features that operations of the Al agents may analyze may include: typing speed, keystroke timing, login times, device fingerprint, transaction frequency, geolocation patterns, verified versus unverified interactions, push versus pull request patterns, logged-in applications, online applications, user behavior and tendencies, search history and location, SSO and password access behavior, multiple users within a shared account structure, or device update patterns. In some embodiments, Ai models may be trained locally at the node / client device 104 based on user behavioral history and updated continuously over time so that the system 100 may adapt to usage patterns.

[0127] At operation 330, the node / client device 104 may generate or establish a blockchain wallet account associated with the user identity.

[0128] At operation 340, the node / client device 104 may associate communication messages via the node / client device 104 with the user identity associated with the wallet account. As such, the node / client device 104 configured as an endpoint will associate the user identity with data communication messages being transmitted to a counterparty device or from a counterparty device.

[0129] At operation 350, the node / client device 104 may transmit the user identity associated with the wallet account to the blockchain network 102.

[0130] In some embodiments, the system 100 may include smart contracts may store and govern state associated with identity and trust. For example, specific parameters encoded in smart contracts may include one or more of identity public keys, identity hashes, trust scores, verification statuses, device identifier hashes, token balances, relationship to wallet accounts, or revocation / suspension status. In some embodiments, smart contracts may interact with identity verification by validating signatures, checking verification approvals, checking trust scores, and issuing or updating identity tokens when the required verification conditions have been met. Insome embodiments, data structures used may include Merkle trees, identity hash mappings, token ledger mappings, and mapping structures such as: mapping(address => IdentityToken). Once a verification event is validated, the smart contract can record the identity state, update trust metrics, and issue tokens or rewards where appropriate.

[0131] In some embodiments, tokens may be created by verifying other users' transactions and activities on the blockchain network 102. Minting tokens into a cryptocurrency-like unit may be a further step. By analogy, Bitcoin may create a coin through a network process. In embodiments of the present disclosure, the blockchain network 102 may generate tokens through verified trust activity and then may grant a user-specific identity (e.g., termed a Batokey) coin to the user's wallet after a threshold amount of trust work has been accumulated. For example, if ten tokens represent ten verified interactions, then ten tokens may be converted into one BATOKEY coin. In some embodiments, the ratio for generating a BATOKEY coin may be refined over time, akin to the value of fiat currency fluctuating with broader market conditions. Unlike known cryptocurrency implementations, BATOKEY may be associated with a valuable verification service: verification, trust, and secure identity interaction.

[0132] In some embodiments, token quantity may be determined by verification action type and by the volume of confirmed requests. In some embodiments, the blockchain network 102 may be based on Ethereum, Layer-2 Ethereum, or a proprietary blockchain.

[0133] In some embodiments, generated user identity tokens may include identity public keys, identity hashes, trust scores, verification statuses, or device binding data. In some embodiments, at the point of account creation (e.g., operation 330), the node / client device 104 may generate a source key that is associated with the tokens. Generated tokens may be a sequence number or key number, with the key being checked based on verification operations corresponding to operations used for generating the user identity token and based on acceptance of the associated user devices and endpoints into the key’s trust framework.

[0134] In some embodiments, the node / client device 104 generated user identity token may differ from other blockchain identity solutions at least because embodiments of the present disclosure includes features that may be decentralized, may be based on verification rather than mere self-assertion, may be independent ofcentralized identity harvesting, or may be enforced at the endpoint level and on the blockchain network 102. User identity verification may be conducted and maintained through layered quality assurance around behavior, timing, or other human-centric testing.

[0135] In some embodiments, the node / client device 104 may manage unique user identifiers associated with users on the blockchain network 102. For example, the node / client device 104 may associate the cryptographic identity to endpoint software (such as the software application 108 of FIG. 1 ), trust verification, node / client device 104 participation, and user-controlled logs.

[0136] In some embodiments, the system 100 may include operations based on encryption algorithms such as standard public-key cryptographic systems and digital signature methods used in blockchain environments. Key generation, storage, and rotation may occur through secure enclaves, trusted execution environments, or device-level hardware-backed storage. In the present examples, private keys may be stored at a secure local storage associated with the software application 108.

[0137] In embodiments of the present disclosure, the system 100 environment may be a closed or secure system at least because a user is associated with a node / client device 104 as an endpoint. The device itself may still be physically compromised if a user leaves it unlocked somewhere, however, embodiments of the present disclosure may include features such that log and verification history remain accurate and tamper-resistant because they are tied to the identity network and device bindings.

[0138] If a device is stolen, the logs continue to tell the story. The user can track the history back to the point of loss, rebuild trust, suspend the account, or shut down affected devices from another device on their network.

[0139] At operation 360, the system 100 may be configured for user identity verification operations for user wallet accounts across the plurality of nodes / client devices 104 on the blockchain network 102.

[0140] As described in the present disclosure, embodiments of the systems and methods do not merely verify a user’s identity at login with a counterparty system or application. Nodes / client devices 104 may include operations to verify user identities at the endpoints, thereby placing verification at the endpoint execution layer.Accordingly user identity verification may be conducted before application operations are conducted.

[0141] At operation 370, nodes / client devices 104 may conduct operations to verify user identities associated with transmission / receipt of communication messages among node users, resource transfer transactions (e.g., monetary transactions), data transfer transactions, application protocol interface calls, service access, or application execution, among other example ongoing processes.

[0142] As described, embodiments of systems herein may conduct operations to verify both inbound and outbound communications among nodes, thereby allowing users to enforce policies such as only transmitting messages with nodes associated with verified user identities, only sending resource transfers or monetary funds to verified user wallets, only establishing a communication channel (e.g., connecting) to verified counter-party computing device servers, and / or only accessing verified service platforms (e.g., platform as a service services).

[0143] In some embodiments, the nodes / client devices 104 operating as endpoints may be configured with software execution hooks or interception logic at the software endpoint layer. Example hooks may attach to process creation events, network stack operations, system calls, application launch requests, input / output interactions, and identity-sensitive actions such as financial transfers, secure messaging, credential entry, API calls, or browser-driven submissions.

[0144] When an application or process attempts to perform an action, the node / client device 104 configured as an endpoint may conduct operations to intercept the request, extract relevant identity and destination data, and subject that event to user identity verification operations before the action may proceed.

[0145] In some embodiments, the verification operations may include: identity token lookup; device binding checks; trust score evaluation; community verification status; behavioral consistency checks; cryptographic signature validation; or policy enforcement for verified-only communications. Accordingly, embodiments may include a model in which digital actions or communications with a counterparty device may become conditional on trust validation.

[0146] In some embodiments, the node / client device 104 may be configured toconduct offline user identity verification. In some scenarios, the node / client device 104 operating as an endpoint may conduct operations to continue tallying and logging user activity while offline (e.g., not currently in communication with the blockchain network 102), thereby storing an unverified log until the node / client device 104 reconnects to the blockchain network 102. When the node / client device 104 reconnects with the blockchain network 102, log files are checked, sorted, and verified where needed. In some embodiments, data stored locally at the node / client device 104 as an endpoint may include data representing identity tokens; identity public keys; signed or encrypted user history logs; queued verification events; or device-level interaction histories, among other example data types.

[0147] Reference is made to FIG. 4, which illustrates a flowchart 400 illustrating operations of the system 100 of FIG. 1 , in accordance with embodiments of the present disclosure. The flowchart 400 may be based on the flowchart 300 described with reference to FIG. 3 and provides additional disclosure of features of embodiments of the present disclosure. For ease of reference, in FIG. 4, similar reference numerals may be used to reference operations that correspond to the flowchart 300 of FIG. 3.

[0148] At operation 435, the node / client device 104 may integrate one or more devices as an endpoint based on one or more layers, including a bootloader level, firmware level, trusted execution environment (TEE), secure enclave, kernel mode, or hypervisor or secure execution layer, among other examples.

[0149] In some embodiments, the node or client device 104 may be configured at a software terminal level of the device 104 so as to conduct software boot operations alongside startup software when the device 104 is powered on. Unlike an ordinary application that executes operations on top of an operating system and conducts operations based on a graphical user interface and higher-level operating system services, embodiments of the present disclosure include methods to conduct user identity verification operations parallel to, beneath, or adjacent to the software operating system stack.

[0150] In some embodiments, during device 104 startup operations, the software application 108 may include operations for execution before or alongside operating system operations and registers hooks with process creation handlers, network stack execution, kernel execution control, and other system-level events. Such operationsmay allow the client device 104 to verify trust before execution or communication rather than reacting after target communication software has already launched. That is, the software application 108 including user identity verification operations is not simply conducting operations that are associated with a single software application, but may be conducting user identity verification operations associated with a broader software application layer of the device 104. As such, the software application 108 may log the user’s activities and interactions with third parties independent of whether the application itself has its own login, account system, or application-specific security.

[0151] Accordingly, as described herein, at operation 340, the node / client device 104 may associate communication messages via the node / client device 104 with the user identity associated with the wallet account. As such, the node / client device 104 configured as an endpoint will associate the user identity with data communication messages being transmitted to a counterparty device or from a counterparty device. That is, the node / client device 104 may funnel devices through the endpoint device to wallet (e.g., devices that hold user data and user storage).

[0152] At operation 445, the node / client device may conduct operations to test online activity, such as transmit data messages, and may transmit one or more transactions on each device. Operations to test online activity may be based on publishing, at operation 350, live data transmissions of an account to the blockchain network 102.

[0153] In FIG. 4, the flowchart may include at operation 480 operations for tracking tokens corresponding to authentications and other operations of the system 100.

[0154] As described in examples of the present disclosure, tokens may be created by verifying other users' transactions and activities on the blockchain network 102. Minting tokens into a cryptocurrency-like unit may be a further step. By analogy, Bitcoin may create a coin through a network process. In embodiments of the present disclosure, the blockchain network 102 may generate tokens through verified trust activity and then may grant a user-specific identity (e.g., termed a Batokey) coin to the user's wallet after a threshold amount of trust work has been accumulated. For example, if ten tokens represent ten verified interactions, then ten tokens may be converted into one BATOKEY coin. In some embodiments, the ratio for generating a BATOKEY coin may be refined over time, akin to the value of fiat currency fluctuatingwith broader market conditions. Unlike known cryptocurrency implementations, BATOKEY may be associated with a valuable verification service: verification, trust, and secure identity interaction.

[0155] Reference is made to FIG. 5, which illustrates a flowchart 500 showing operations of the system 100 of FIG. 1 , in accordance with embodiments of the present disclosure. The flowchart 500 may be based on the flowcharts described with reference to FIG. 3 and 4 and provides additional disclosure of features of embodiments of the present disclosure. For ease of reference, in FIG. 5, similar reference numerals may be used to reference operations that correspond to the flowchart 300 of FIG. 3 and the flowchart 400 of FIG. 4.

[0156] As described, at operation 330, the node / client device 104 may generate or establish a blockchain wallet account associated with the user identity. The node / client device 104 may conduct operations to test the wallet account associated with the node / client device 104 operating as an endpoint and may conduct operations to test communication messages associated with the blockchain network 102.

[0157] At operation 590, the node / client device 104 may execute operations associated with software execution hooks or interception logic at the software endpoint layer. Example hooks may attach to process creation events, network stack operations, system calls, application launch requests, input / output interactions, and identity-sensitive actions such as financial transfers, secure messaging, credential entry, API calls, or browser-driven submissions.

[0158] As an illustrating example, the node / client device 104 may execute operations of an endpoint layer to read data traffic in and out of an application on the node / client device, such as banking applications, gaming applications, social media platforms, electronic mail, among other applications.

[0159] When an application or process attempts to perform an action, the node / client device 104 configured as an endpoint may conduct operations to intercept the request, extract relevant identity and destination data, and subject that event to user identity verification operations before the action may proceed.

[0160] Reference is made to FIG. 6, which illustrates a flowchart 600 showing operations of the system 100 of FIG. 1 , in accordance with embodiments of the presentdisclosure. The flowchart 600 may be based on the flowcharts described with reference to FIG. 3, FIG. 4, or FIG. 5 and provides additional disclosure of features of embodiments of the present disclosure. For ease of reference, in FIG. 6, similar reference numerals may be used to reference operations that correspond to the flowcharts of FIG. 3, FIG. 4, and / or FIG. 5.

[0161] At operation 645, the node / client device 104 may conduct operations to include additional devices to be associated with a user identity for a wallet account.

[0162] At operation 695, the node / client device 104 may conduct operations of the dashboard application layer 106 for testing or re-testing verified node / client devices and reporting to the dashboard application layer 106 of such results. Accordingly, authentications and data transmission activity associated with a particular user identity may be associated with one or more node / client devices 104 in scenarios where a user may be associated with a plurality of node / client devices 104.

[0163] As illustrated through the description of embodiments of the present disclosure, the system 100 is configured to provide community-based user identity verification and is based on a combination of node / client device 104 (e.g., endpoint) monitoring, blockchain network 102 verification, Al behavioral analysis operations, and / or decentralized user identity consensus operations, among other example operations. Such user identity verification operations may be conducted at a node / client device 104 level, across software applications, and across networks simultaneously.

[0164] Reference is made to FIG. 7, which illustrates a flowchart 700 of a method of consensus-based identity verification, in accordance with embodiments of the present disclosure. The method 700 may include operations conducted by a node / computing device 104 of FIG. 1. The method 700 may include operations conducted by one or more processors and may include operations such as data retrievals, data manipulations, data storage, or other computer-executable operations.

[0165] At operation 702, the node / computing device 104 detects a signal representing a data communication request of an application instance associated with a second endpoint device.

[0166] In some embodiments, the signal representing the data communication request includes initiating an inbound or outbound communication channel with theapplication instance associated with the second end point device.

[0167] In some embodiments, the nodes / client devices 104 operating as endpoints may be configured with software execution hooks or interception logic at the software endpoint layer. Example hooks may attach to process creation events, network stack operations, system calls, application launch requests, input / output interactions, and identity-sensitive actions such as financial transfers, secure messaging, credential entry, API calls, or browser-driven submissions.

[0168] For example, when an application or process attempts to perform an action, the node / client device 104 configured as an endpoint may conduct operations to intercept the request, extract relevant identity and destination data, and subject that event to user identity verification operations before the action may proceed.

[0169] At operation 704, the node / computing device 104 determines whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network.

[0170] In some embodiments, the destination identifier associated with the second endpoint device includes at least one of a public key, blockchain address, device identity hash, application instance identity certificate, server identity token, or a destination trust artifact.

[0171] In some embodiments, the valid identity token is associated with predefined or pre-established trust criteria.

[0172] In some embodiments, the verification operations may include: identity token lookup; device binding checks; trust score evaluation; community verification status; behavioral consistency checks; cryptographic signature validation; or policy enforcement for verified-only communications. Accordingly, embodiments may include a model in which digital actions or communications with a counterparty device may become conditional on trust validation.

[0173] In some embodiments, determining whether the destination identifier corresponds to a valid identity token is determined independent of the application instance associated with the second endpoint device. For example, identity verification may occur before a communication channel associated with the application instanceof the second endpoint device is established.

[0174] In some embodiments, the decentralized network includes a plurality of computing nodes for generating consensus data for generating valid identity tokens associated with at least one of the first endpoint device and the second endpoint device.

[0175] At operation 706, the node / computing device 104 may receive a signal representing valid identity toke data from a node of the decentralized network.

[0176] At operation 708, the node / computing device 104 may transmit, to the second endpoint device, response data related to the data communication request of the application instance.

[0177] In some embodiments, the node / computing device 104 may receive, from a node of the decentralized network, a signal representing invalid identity token data associated with the second endpoint device and may transmit a signal representing a request for the second endpoint device to seek identity verification based on the consensus data of the decentralized network.

[0178] In some embodiments, the node / computing device 104 may receive a signal associated with a request to derive a subset portion of consensus data to verify a third user identity. The node / computing device 104 may transmit, to the decentralized network, the requested subset portion of the consensus data and receive a signal representing a token coin as a response to the derived subset portion of the consensus data. In some embodiments, the token coin may represent user value associated with the decentralized network. In some embodiments, the decentralized network may be a blockchain network. In the present example, the node / computing device 104 may be part of a community-based, distributed identity verification system.

[0179] In some embodiments, the node / computing device 104 receives a signal representing a request for a user identifier associated with the first endpoint device. For example, the node / computing device 104 may receive a request from the second endpoint device to verify the user identity associated with the first endpoint device. The node / computing device 104 may transmit a signal representing the user identifier to the second endpoint device for verification based on consensus data of thecentralized network. Verification of the user identifier may be based on smart contract data structures defined by one or a combination of identity public key, identity hash, trust score, verification status, device identifier hash, token balance, or revocation or suspension status.

[0180] In some embodiments, the node / computing device 104 may determine that the signal representing the data communication request is generated by a non-human subject user and may transmit a signal representing an alert signal for display at the first endpoint device.

[0181] In some embodiments, determining that the signal representing the data communication request is generated by a non-human subject user is based on machine learning models trained based on features including geolocation patterns, transaction frequency, device fingerprint, verified versus unverified communication requests, single sign-on access behavior, or device update patterns.

[0182] Reference is made to FIG. 8, which illustrates a block diagram of a computing device 800, in accordance with embodiments of the present disclosure. The computing device 800 may be configured to conduct operations of a node / client device 104 of FIG. 1. In other examples, the computing device 800 may be coupled with other computing devices to conduct operations of the blockchain network 102 of FIG. 1. In some other examples, the computing device 800 may be coupled with other computing devices to conduct operations of an applications cloud 110 of FIG. 1 .

[0183] The computing device 800 may transmit or receive data messages via a network to or from the blockchain network 102, the applications cloud 110, and / or other computing devices operating as nodes / client devices described with reference to figures of the present disclosure.

[0184] In some embodiments, a network may include a wired or wireless wide area network (WAN), local area network (LAN), a combination thereof, or other networks for carrying telecommunication signals. In some embodiments, network communications may be based on HTTP post requests or TCP connections. Other network communication operations or protocols may be contemplated.

[0185] The computing device 800 includes a processor 802 configured toimplement processor-readable instructions that, when executed, configure the processor 802 to conduct operations described herein. In some examples, the processor 802 may be a microprocessor or microcontroller, a digital signal processing processor, an integrated circuit, a field programmable gate array, a reconfigurable processor, or combinations thereof.

[0186] The computing device 800 includes a communication circuit 804 configured to transmit or receive data messages to or from other computing devices, to access or connect to network resources, or to perform other computing applications by connecting to a network (or multiple networks) capable of carrying data.

[0187] In some embodiments, the network may include the Internet, Ethernet, plain old telephone service line, public switch telephone network, integrated services digital network, digital subscriber line, coaxial cable, fiber optics, satellite, mobile, wireless, SS7 signaling network, fixed line, local area network, wide area network, or other networks, including one or more combination of the networks. In some examples, the communication circuit 804 may include one or more busses, interconnects, wires, circuits, or other types of communication circuits. The communication circuit 804 may provide an interface for communicating data between components of a single device or circuit.

[0188] The computing device 800 includes memory 806. The memory 806 may include one or a combination of computer memory, such as random-access memory, read-only memory, electro-optical memory, magneto-optical memory, erasable programmable read-only memory, and electrically-erasable programmable read-only memory, ferroelectric random-access memory, or the like. In some embodiments, the memory 806 may be storage media, such as hard disk drives, solid state drives, optical drives, or other types of memory. The memory 806 may store an application 812 including processor-readable instructions for conducting one or more operations described herein.

[0189] As an illustrating example, when the computing device 800 is operating as a node / client device 104 of FIG. 1, the application 812 (stored in the memory 806) may be the software application 108 described with reference to FIG. 1 and with reference to other figures of the present disclosure, for conducting operationsassociated with community-based user identity verification.

[0190] The computing device 800 includes data storage 814. In some embodiments, the data storage 814 may be a secure data store. In some embodiments, the data storage 814 may store data structures associated with established wallet accounts. In some embodiments, the data storage 814 may store instructions that when executable configure the processor 802 to conduct operations of community-based user identification verification associated with the system 100 described in the present disclosure. Storage of data structures or processorexecutable instructions based on the data storage 814 may be contemplated.

[0191] FIG. 9 illustrates an example graphical user interface 900 of a token wallet displayed at a node / computing device 104, in accordance with embodiments of the present disclosure.

[0192] FIG. 10 illustrates an example graphical user interface 1000 of a verification request interface displayed at a node / computing device 104, in accordance with embodiments of the present disclosure.

[0193] FIG. 11 illustrates an example graphical user interface 1100 for retrieving user input for output identity verification and confirmations, in accordance with embodiments of the present disclosure.

[0194] FIG. 12 illustrates an example graphical user interface 1200 for display at a node / computing device 104 for managing a plurality of devices associated with a user identity account, in accordance with embodiments of the present disclosure.

[0195] FIG. 13 illustrates an example graphical user interface 1300 for display at a node / computing device 104 for managing a user identity account, in accordance with embodiments of the present disclosure.

[0196] FIG. 14 illustrates an example graphical user interface 1400 for display at a node / computing device 104 for managing a user identity account corresponding to data structures submitted on the blockchain network 102, in accordance with embodiments of the present disclosure.

[0197] FIG. 15 illustrates an example graphical user interface 1500 for display at a node / computing device 104 for managing verified user identities, in accordance withembodiments of the present disclosure.

[0198] FIG. 16 illustrates an example graphical user interface 1600 for display at a node / computing device 104 for managing tokens, in accordance with embodiments of the present disclosure.

[0199] FIG. 17 illustrates an example graphical user interface 1700 for display at a node / computing device 104 for managing the node as an endpoint having a user identity verified via the blockchain network 102, in accordance with embodiments of the present disclosure.

[0200] One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs, field programmable gate arrays (FPGAs) computer hardware, firmware, software, and / or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0201] These computer programs, which can also be referred to as programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and / or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor. Themachine-readable medium can store such machine instructions non-transitorily, such as for example as would a non-transient solid-state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transient manner, such as for example, as would a processor cache or other random access memory associated with one or more physical processor cores.

[0202] To provide for interaction with a user, one or more aspects or features of the subject matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) or a light emitting diode (LED) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. Other possible input devices include touch screens or other touch-sensitive devices such as single or multi-point resistive or capacitive track pads, voice recognition hardware and software, optical scanners, optical pointers, digital image capture devices and associated interpretation software, and the like.

[0203] The term “connected” or "coupled to" may include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements).

[0204] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope. Moreover, the scope of the present disclosure is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[0205] As one of ordinary skill in the art will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, orsteps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

[0206] The description provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.

[0207] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[0208] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[0209] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[0210] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.

[0211] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements.

[0212] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Claims

WHAT IS CLAIMED IS1 . A system for identity verification based on consensus data comprising:a first endpoint device comprising:a processor; anda memory coupled to the processor and storing processor-executable instructions that, when executed, configure the processor to:detect a signal representing a data communication request of an application instance associated with a second endpoint device;determine whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network;receive a signal representing valid identity token data from a node of the decentralized network; andtransmit, to the second endpoint device, response data related to the data communication request of the application instance.

2. The system of claim 1, wherein determining whether the destination identifier corresponds to a valid identity token is determined independent of the application instance associated with the second endpoint device.

3. The system of claim 1 , wherein the signal representing the data communication request includes initiating an inbound or outbound communication channel with the application instance associated with the second endpoint device.

4. The system of claim 1 , further comprising the decentralized network includes a plurality of computing nodes for generating consensus data for generating valid identity tokens associated with at least one of the first endpoint device and the second endpoint device.

5. The system of claim 1, wherein the processor-executable instructions, when executed, configure the processor to:receive, from a node of the decentralized network, a signal representing invalid identity token data associated with the second endpoint device; andtransmit a signal representing a request for the second endpoint device to seek identity verification based on the consensus data of the decentralized network.

6. The system of claim 1, wherein the processor-executable instructions, when executed, configure the processor to:receive a signal associated with a request to derive a subset portion of consensus data to verify a third user identity;transmit, to the decentralized network, the requested subset portion of the consensus data; andreceive a signal representing a token coin as a response to the derived subset portion of the consensus data, wherein the token coin represents user value associated with the decentralized network.

7. The system of claim 1, wherein the processor-executable instructions, when executed, configure the processor to:receive a signal representing a request for a user identifier associated with the first endpoint device; andtransmit a signal representing the user identifier to the second endpoint device for verification based on consensus data of the decentralized network, wherein verification of the user identifier is based on smart contract data structures defined by one or a combination of identity public key, identity hash, trust score, verification status, device identifier hash, token balance, or revocation or suspension status.

8. The system of claim 1, wherein the processor-executable instructions, when executed, configure the processor to:determine that the signal representing the data communication request is generated by a non-human subject user; andtransmit a signal representing an alert signal for display at the first endpoint device.

9. The system of claim 8, wherein determining that the signal representing the data communication request is generated by a non-human subject user is based on machine learning models trained based on features including geolocation patterns,transaction frequency, device fingerprint, verified versus unverified communication requests, single sign-on access behavior, or device update patterns.

10. The system of claim 1, wherein the destination identifier associated with the second endpoint device includes at least one of a public key, blockchain address, device identity hash, application instance identity certificate, server identity token, or a destination trust artifact, and wherein a valid identity token is associated with predefined trust criteria.

11. A method of identity verification based on consensus data comprising:detecting a signal representing a data communication request of an application instance associated with a second endpoint device;determining whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network;receiving a signal representing valid identity token data from a node of the decentralized network; andtransmitting, to the second endpoint device, response data related to the data communication request of the application instance.

12. The method of claim 11 , wherein determining whether the destination identifier corresponds to a valid identity token is determined independent of the application instance associated with the second endpoint device.

13. The method of claim 11, wherein the signal representing the data communication request includes initiating an inbound or outbound communication channel with the application instance associated with the second endpoint device.

14. The method of claim 11 , wherein the decentralized network includes a plurality of computing nodes for generating consensus data for generating valid identity tokens associated with at least one of the first endpoint device and the second endpoint device.

15. The method of claim 11 , comprising:receiving, from a node of the decentralized network, a signal representing invalid identity token data associated with the second endpoint device; andtransmitting a signal representing a request for the second endpoint device to seek identity verification based on the consensus data of the decentralized network.

16. The method of claim 11 , comprising:receiving a signal associated with a request to derive a subset portion of consensus data to verify a third user identity;transmitting, to the decentralized network, the requested subset portion of the consensus data; andreceiving a signal representing a token coin as a response to the derived subset portion of the consensus data, wherein the token coin represents user value associated with the decentralized network.

17. The method of claim 11 , comprising:receiving a signal representing a request for a user identifier associated with the first endpoint device; andtransmitting a signal representing the user identifier to the second endpoint device for verification based on consensus data of the decentralized network, wherein verification of the user identifier is based on smart contract data structures defined by one or a combination of identity public key, identity hash, trust score, verification status, device identifier hash, token balance, or revocation or suspension status.

18. The method of claim 11 , comprising:determining that the signal representing the data communication request is generated by a non-human subject user; andtransmitting a signal representing an alert signal for display at the first endpoint device,wherein determining that the signal representing the data communication request is generated by a non-human subject user is based on machine learning models trained based on features including geolocation patterns, transaction frequency, device fingerprint, verified versus unverified communication requests, single sign-on access behavior, or device update patterns.

19. The method of claim 11 , wherein the destination identifier associated with the second endpoint device includes at least one of a public key, blockchain address,device identity hash, application instance identity certificate, server identity token, or a destination trust artifact, and wherein a valid identity token is associated with predefined trust criteria.

20. A non-transitory computer-readable medium or media having stored thereon machine interpretable instructions which, when executed by a processor, cause the processor to perform a computer-implemented method of identity verification based on consensus data, the method comprising:detecting a signal representing a data communication request of an application instance associated with a second endpoint device;determining whether a destination identifier associated with the second endpoint device corresponds to a valid identity token based on consensus data of a decentralized network;receiving a signal representing valid identity token data from a node of the decentralized network; andtransmitting, to the second endpoint device, response data related to the data communication request of the application instance.

Images