Abstract

Systems and methods for the calculation of a dynamic trust score are disclosed. The dynamic trust score may indicate a likelihood that the consumer will complete the transaction in a positive manner. The system may calculate the dynamic trust score based on various static and dynamic variables including digital identity data, internal data, third-party data, private data, and/or data from the transaction initiated by the consumer.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 30/018 - Certifying business or products
• G06Q 30/0204 - Market segmentation
• H04L 9/00 - Arrangements for secret or secure communicationsNetwork security protocols
• H04L 9/08 - Key distribution

Abstract

Disclosed are various embodiments for providing non-fungible tokens (NFT) as a mechanism for verifying ownership of payment instruments such as stored value payment instruments. First, a computing device can receive a purchase notification, the purchase notification indicating that a first user has purchased a stored value payment instrument. Then, the computing device can create a non-fungible token (NFT) on a distributed data store in response to receipt of the purchase notification. Next, the computing device can associate a unique identifier of the NFT with the stored value payment instrument. Subsequently, the computing device can receive a first public key associated with the first user. Then, the computing device can update an owner identifier of the NFT with the first public key associated with the first user.

IPC Classes  ?

• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

A system and method for generating product analytics insights for machine learning platforms is disclosed. The system and method can receive a log file including data derived while executing a software program. Software packages and the package sub-modules logged in the log file may be categorized into a plurality of package categories. A notebook in which the software code is written, and identified in the log file, may be categorized into a notebook category. A consumable insight may be generated based on: the categorized software packages and package sub-modules, and the categorized notebook. A natural language summary may be generated describing the consumable insight. The natural language summary may be transmitted for display on a graphical user interface (GUI) in response to a user query.

IPC Classes  ?

• G06Q 30/02 - MarketingPrice estimation or determinationFundraising
• G06F 16/23 - Updating
• G06Q 30/0201 - Market modellingMarket analysisCollecting market data

Abstract

Disclosed are various embodiments for securely conducting online in-application purchases. In one example, among others, a system comprises a client device that is configured to identify a purchase request from a merchant application executed on the client device and generate a security attestation for the purchase request based at least in part on executing a security library installed in the client device, the security attestation being provided to a wallet provider. The client device is configured to determine whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation and transmit a token for an account to the wallet provider based at least in part on the determination of whether the purchase request is authorized.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for securely sharing confidential data between applications. A deep link request can be received from a first computing device, the deep link request identifying a set of data to be shared and a deep link schema. A token that represents the set of data can then be created. Also, a deep link that complies with the deep link schema and includes the token can also be created. The deep link and the token can then be returned to the first computing device. Later, a data request containing the token can be received from a second computing device. The set of data associated with the token can then be return to the second computing device.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• G06F 21/44 - Program or device authentication
• G06F 21/60 - Protecting data

Abstract

Disclosed are various embodiments for using machine learning models to identify appropriate security patterns to follow during the application development process. A computing device can receive a request to identify a collection of security patterns to apply to an application and then identify a plurality of features associated with the application. Next, the computing device can submit the plurality of features to a random forest machine learning model and receive a first set of security patterns in response. Then, the computing device can submit the plurality of features to a k-nearest neighbor (KNN) machine learning model and receive a second set of security patterns in response. Then, the computing device can identify a subset of the security patterns that is included in both the first set of security patterns and the second set of security patterns and return the subset of the security patterns.

IPC Classes  ?

• G06F 21/52 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure
• G06N 20/20 - Ensemble learning

Abstract

Disclosed are various embodiments for using decentralized identity to verify account information for a user requesting a transfer of funds between one or more financial entities (e.g., banks, credit unions, brokerage firms, mortgage companies, etc.). A user having account with a first entity can request that a balance credential be created claiming that the balance of funds within the account meets or exceeds a predefined threshold. The balance credential can be created and saved on a distributed ledger in relation to a decentralized identity identifier (DID) of the user. When a second entity wants to verify the account balance of the user, the verifying entity which can use the DID to access the balance credential on the distributed ledger and validate the accessed credential.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for authenticating a user using non-fungible tokens (NFTs). A trusted token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider. For example, when a client device associated with the user requests access from an access provider to an access-restricted website or other type of access-restricted area (e.g., building, concert venue, network, etc.), the access provider (e.g., website server, building computing device, venue system, etc.) uses the properties of the non-fungible token to verify one's identity and permit access upon verification.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• H04L 9/00 - Arrangements for secret or secure communicationsNetwork security protocols
• H04L 9/08 - Key distribution
• H04L 9/40 - Network security protocols

Abstract

Disclosed are various approaches for relationship and attribute management are described. In some examples, a verifier service performs a verification process using a relationship decentralized identifier (DID) that provides proof of a relationship between the holder and a DID management service. An attribute request is that specifies an attribute is transmitted from the verifier service to the DID management service. The DID management service provides the verifier service with information based on the attribute once the holder provides an authorization response that authorizes usage of the attribute.

IPC Classes  ?

• G06F 21/45 - Structures or tools for the administration of authentication

Abstract

Disclosed are various approaches for facilitating verifier integrations using computer models. An exemplary system of the present disclosure comprises a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive an unstructured claim query for a data document from an entity computing device, wherein the data document is structured in accordance with a data document schema; parse the unstructured claim query to identify attributes that are then converted to a machine-understandable representation of the unstructured claim query; prepare, using a predictive model that is trained to understand data documents that are structured in accordance with the data document schema, a query response to the machine-understandable representation of the unstructured claim query by evaluating contents of the data document; and transmit the query response to the entity computing device.

IPC Classes  ?

• G06F 16/33 - Querying
• G06F 40/205 - Parsing

Abstract

Systems and methods for automated travel itinerary management based on real-time event aggregation are disclosed. The system may aggregate event data, in real-time, from multiple distributed data sources to generate an automated itinerary based on travel-related transactions. The system may update the automated itinerary as additional travel-related transactions are completed. The system may also include travel data from travel systems, concierge systems, and manual input in the automated itinerary.

IPC Classes  ?

• G06Q 10/02 - Reservations, e.g. for tickets, services or events
• G06Q 30/0601 - Electronic shopping [e-shopping]
• G06Q 50/14 - Travel agencies

Abstract

Disclosed are various embodiments for garbage collection for object-based storage systems. A first set of objects stored in a data object store is identified as not meeting criteria for deletion or archiving, the criteria specified in a retention policy. A second set of objects is identified by performing a search of the object data store for data objects belonging to a data structure with the first set of objects. The second set of objects is recorded as not meeting the criteria for deletion or archiving. The second set of data objects are retained, based on the recording, to prevent the data structure from being corrupted.

IPC Classes  ?

• G06F 3/06 - Digital input from, or digital output to, record carriers

Abstract

A computing device (e.g., a server, a cloud-based device, a network device, an item analysis device, etc.) may receive location information indicating a geographic location of a user device and image data captured by the user device of a listing (e.g., a menu, an event ticket, a content source, etc.) for a selectable item. The computing device may determine an entity offering the selectable item based on the location information. An intent indicator for the selectable item may be determined based on the entity and the information for the selectable item. An instruction to the user device may cause modification of the image data to indicate the intent indicator based on the intent indicator satisfying an intent threshold that defines a level at which an intent is classified as a positive intent.

IPC Classes  ?

• G06F 3/0482 - Interaction with lists of selectable items, e.g. menus
• G06F 3/14 - Digital output to display device
• G06F 40/20 - Natural language analysis
• G06F 40/58 - Use of machine translation, e.g. for multi-lingual retrieval, for server-side translation for client devices or for real-time translation
• G06N 5/022 - Knowledge engineeringKnowledge acquisition
• G06Q 40/04 - Trading Exchange, e.g. stocks, commodities, derivatives or currency exchange
• G06V 30/10 - Character recognition
• H04L 67/52 - Network services specially adapted for the location of the user terminal

Abstract

Disclosed are various embodiments for facilitating a multi-ledger framework in a trust over internet protocol (TOIP) environment. A listing of ledgers can be maintained by a ledger registry. Entities in the TOIP environment can retrieve a listing of ledgers and cache the contents of the ledgers so that the contents can be accessed if a particular ledger is inaccessible.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system

Abstract

Disclosed are various embodiments for complete webforms based on decentralized identifiers. A decentralized identifier communication (DIDComm) protocol connection is established with a wallet application. Then, a request is sent to the wallet application for a verifiable credential (VC) that contains at least one value for at least one field in a web application. The VC is then received from the wallet application and verified or validated. Next, at least one field in a form is completed with the at least one value specified by the verifiable credential. The web application is then updated to reflect that the at least one field has been filled with the at least one value.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06F 40/174 - Form fillingMerging
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for automating API provisioning for API consumers and API providers using decentralized identity. In various examples, an application that uses APIs to access a resource needed by the application obtains an API key for authentication based at least in part on communications between a consumer decentralized identifier (DID) agent associated with the consumer entity and a provider DID agent associated with the API provider. The provider DID agent can verify the API consumer and generate an API key that can be used by the API consumer for resources requests using the API associated with the API provider. An API service provider can authenticate the API consumer and provide the resource to the API consumer during a session in which the API consumer is authenticated.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• H04L 9/00 - Arrangements for secret or secure communicationsNetwork security protocols

Abstract

Disclosed herein are aspects for dispersing a non-fungible token in response to a security program. An aspect begins by generating a three-dimensional virtual world. The aspect continues by receiving a request to access a test program as part of a security program in the three-dimensional virtual world. The test program includes a display of a source code and instructions for a user to resolve an associated challenge. The aspect then determines a tier of the user, where the tier indicates progress of the user in resolving challenges corresponding to the security program. The test program is generated based on the tier of the user and is generated on a user device through a perspective of a virtual camera. The aspect continues by receiving a resolution to the challenge. A non-fungible token is then generated based on the resolution, assigned to a digital wallet, and recorded on a blockchain.

IPC Classes  ?

• A63F 13/792 - Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for payment purposes, e.g. monthly subscriptions
• A63F 13/52 - Controlling the output signals based on the game progress involving aspects of the displayed game scene

Abstract

Disclosed are various embodiments for offline decentralized identity-based communications between software applications. In one non-limiting example, a system can include a computing device that is configured to detect a network connection loss to a network and receive, via a local area network, a request for an action to be performed by a client device. The request includes a first digital signature of the client device and is associated with a decentralized identifier. The computing device is configured to generate a mutually signed request that includes a second digital signature executed by the computing device and the first digital signature. The mutually signed request is transmitted to the client device. A network connection to the network is detected. The decentralized identifier is validated using the network. The requested action is performed by the computing device based at least in part on the validation of the decentralized identifier.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system

Abstract

Disclosed are various embodiments for accelerating transactions and managing cashflow by predicting and crediting payment amounts for requests for payments that are satisfied by third party providers (e.g., insurance providers, claim payment providers, etc.). A user who is a registered participant in an accelerated transaction program can submit a claim to a claim payment provider requesting payment or reimbursement of funds associated with an event. While waiting for the claim payment provider to process the claim, trained models can be used to analyze the claim data, user data, claim payment provider data, historical data, and/or other information to (1) predict whether the claim will be approved by the claim payment provider and (2) estimate an amount that will be provided to the medical provider by claim payment provider. The user can be credited for the predicted amount while waiting for the claim to be processed.

IPC Classes  ?

• G06Q 40/08 - Insurance
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment

Abstract

At least some embodiments are directed to a large-scale data standardization system. The system receives a set of documents with records formatted according to a third-party data schema. The system utilizes a first machine learning model to select a document from the set of documents. The system utilizes a machine learning model to select data classification labels formatted according to the third-party data schema. The classification labels are associated with a set of records. The system utilizes a second machine learning model to generate a canonical data structure constructed according to a standardized data schema based on the classification labels and the records associated with the classification labels.

IPC Classes  ?

• G06F 16/215 - Improving data qualityData cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
• G06N 3/04 - Architecture, e.g. interconnection topology
• G06N 3/08 - Learning methods
• G06N 5/01 - Dynamic search techniquesHeuristicsDynamic treesBranch-and-bound
• G06N 5/04 - Inference or reasoning models
• G06N 20/20 - Ensemble learning

Abstract

In various embodiments, a system, method, and computer readable medium of the present disclosure comprises obtaining credential information of a user of the computing device; authenticating the credential information of the user; releasing, in response to authenticating the credential information, a first secret element to a secure element processor of the computing device, wherein the first secret element is associated with a first transaction account; comparing the first secret element with an issuer element associated with the first transaction account; verifying that the user is an authorized user based on the comparison of the first secret element with the issuer element; initiating a payment transaction using first transaction account information with a point of sale terminal; and/or sending an indication that the user has been confirmed as an authorized user to the point of sale terminal to enable authorization of the payment transaction initiated by the computing device.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06F 21/44 - Program or device authentication
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Embodiments for intelligently matching a user to an agent for a communication session are disclosed. In one example, a system that comprises a computing device that is configured to receive a request from a client device to open a data communication session with an agent and determine whether interaction data is stored for the client device from a previous interaction with the computing device. The agent can be identified to participate in the data communication session based at least in part on the determination of whether the interaction data is stored for the client device from the previous interaction. The data communication session can be established between an agent client device of the agent and the client device based at least in part on the agent being identified for participation in the data communication session.

IPC Classes  ?

• H04M 3/523 - Centralised call answering arrangements requiring operator intervention with call distribution or queuing
• G06N 20/00 - Machine learning
• G06Q 10/0631 - Resource planning, allocation, distributing or scheduling for enterprises or organisations
• H04M 3/51 - Centralised call answering arrangements requiring operator intervention

Abstract

Disclosed are various embodiments for using decentralized identity services and generative large language models (LLMs) to facilitate a humanized interactive chatbot session between two entities where information exchanged can be verified for accuracy. An interactive session can be established between a chat wallet service associated with a first user (e.g., a credential holder) and a second user (e.g., inquirer) using decentralized identity services. Inquiries asked by the second user can be directed to the chat wallet service which can obtain a response from a personalized dialog agent. The personalized dialog agent can obtain the answer by executing a language model that has been trained and personalized using information about the first user. The answer to the inquiry can be verified by comparing the answer with a verified credential associated with the first user. The verified response to the inquiry can then be provided to the second user.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• H04L 9/30 - Public key, i.e. encryption algorithm being computationally infeasible to invert and users' encryption keys not requiring secrecy

Abstract

Disclosed are various embodiments for configurable and event driven smart hybrid cloud orchestrators. Various embodiments include a first computing device that can receive a request that includes various configurations to perform one or more actions. The first computing device can generate machine-readable instructions to perform a first action. The first computing device can send a first event to an event hub that includes the machine-readable instructions. The second computing device can receive the first event from the event hub and provision computing resources. The second computing device can then modify the machine-readable instructions based on the computing resources and then execute the machine-readable instructions. The second computing device can send a second event indicating that the first action has completed. The first computing device can receive the second event from the event hub.

IPC Classes  ?

• G06F 3/06 - Digital input from, or digital output to, record carriers

Abstract

Disclosed are various embodiments for inferring a schema for a flat file when a corresponding schema file defining the structure of the data included in the flat file is not available. In some examples, a trained schema inference model can be used to determine the corresponding schema defining the data structure and relationships of the data include the flat file. In other examples, statistical analysis and pattern detection is used to determine the corresponding schema of the flat file. Once a flat file schema is defined, a compliance analysis can be performed to ensure that the data of the flat file conforms with various privacy and compliance regulations. If a compliance issue is detected, the flat file can be flagged for manual review and/or modified to rectify the compliance issue.

IPC Classes  ?

• G06F 16/10 - File systemsFile servers
• G06F 16/11 - File system administration, e.g. details of archiving or snapshots
• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules

Abstract

Disclosed are various embodiments for verifying the presentation of media represented by non-fungible tokens (NFTs). A presentation device can receive a smart contract address and a non-fungible token (NFT) identifier from a client device. The presentation device can then execute a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, wherein the NFT identifier is provided as an argument to the function of the smart contract. Subsequently, the presentation device can validate the owner address for the NFT. Then, in response to validation of the owner address for the NFT, the presentation device can present the media file represented by the NFT.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• G06F 16/951 - IndexingWeb crawling techniques
• H04L 9/00 - Arrangements for secret or secure communicationsNetwork security protocols
• H04L 9/08 - Key distribution

Abstract

Disclosed herein are system, method, and computer program product embodiments for converting queries and scripts used in big data systems. A script conversion system converts a script and its queries from a first big data format to a second big data format. The script conversion system uses a configuration mapping that includes direct and/or indirect function mappings. For the direct mapping, the script conversion system replaces the function with a new function in the second big data format. For the indirect mapping, the script conversion system constructs an equivalent function in the second big data format using information extracted from parsing queries in the first big data format. The script conversion system also formats a converted query using a project mapping and/or generates a conversion report indicating successful or unsuccessful conversions. Scripts may be converted from an on-premises data warehouse system to a cloud-based data warehouse system.

IPC Classes  ?

• G06F 16/14 - Details of searching files based on file metadata
• G06F 16/11 - File system administration, e.g. details of archiving or snapshots
• G06F 16/13 - File access structures, e.g. distributed indices

Abstract

Disclosed are various embodiments for bundling multiple transactions together to split among one or more individuals. A selection of a plurality of transactions presented through a user interface is obtained. Then, a split request is obtained through the user interface, the split request representing a request to split a total cost for the plurality of transactions with one or more individuals. Next, a selection of the one or more individuals is obtained, the selection comprising a respective personal identifier for each of the one or more individuals. Subsequently, a split message is sent to a transaction processing service, the split message comprising a plurality of transaction identifiers representing the plurality of transactions and the respective personal identifier for each of the one or more individuals.

IPC Classes  ?

• G06Q 20/22 - Payment schemes or models
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices

Abstract

At least some embodiments are directed to an entity classification system that receives informational data associated with an entity. The informational data includes sentences associated with the entity. The entity classification system utilizes a first machine learning model to determine a first contextual meaning among words of a sentence associated with the entity based on a first word embedding technique, and determines at least one category associated with the entity based at least in part on the first contextual meaning. The entity classification system utilizes a second machine learning model to determine a second contextual meaning shared by a set of sentences based on a second embedding technique, and determines a subcategory of the category associated with the entity based at least in part on the second contextual meaning. The entity classification system generates an output including the category and subcategory associated with the entity.

IPC Classes  ?

• G06F 40/295 - Named entity recognition
• G06F 18/24 - Classification techniques
• G06N 3/045 - Combinations of networks

Abstract

Disclosed are various embodiments for compliance detection using natural language processing. Various embodiments include a computing device that can transcribe a sound recording of a transcript, where the sound recording can be representative of a telephonic call occurring between an agent and a client. The computing device can determine that the telephonic call included a discussion related to a regulated subject based on an analysis by a natural language processor of the transcript. The computing device can obtain a compliance rule based at least in part on the regulated subject of the telephonic call. The computing device can determine that the compliance rule has been violated using a natural language processor of the transcript. The computing device can also store various information related to the compliance violation.

IPC Classes  ?

• G06F 40/35 - Discourse or dialogue representation
• G06F 40/279 - Recognition of textual entities
• G06Q 30/018 - Certifying business or products

Abstract

A consumer may enroll in an event gamification system. An event listener may detect an event. The event gamification system may determine that the event qualifies for a game in which the consumer is enrolled. The event gamification system may transmit an achievement notification to the consumer as soon as the event occurs. The game may be displayed in a GUI on a consumer device. The consumer may be rewarded for completing the achievements in the game. Also, a server computer receiving a plurality of data sets that represent visually perceptible elements for a plurality of host web pages, wherein each of the plurality of host web pages displays an active link associated with a product on a merchant web page. The server automatically generating composite web page from: i) the particular data set associated with the particular host web page and the particular set of visually perceptible elements and ii) the related electronic content associated with the product from the merchant web page.

IPC Classes  ?

• G06Q 30/0207 - Discounts or incentives, e.g. coupons or rebates
• A63F 13/65 - Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor automatically by game devices or servers from real world data, e.g. measurement in live racing competition
• A63F 13/69 - Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor by enabling or updating specific game elements, e.g. unlocking hidden features, items, levels or versions
• A63F 13/71 - Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
• A63F 13/79 - Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
• G06Q 30/0226 - Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
• G06Q 30/0601 - Electronic shopping [e-shopping]

Abstract

Disclosed are various embodiments for providing blockchain-based threat intelligence. First, a computer determines that a request for a remedial action has been recorded to a blockchain by a smart contract. Then, the computer evaluates the request for the remedial action to determine the remedial action to be performed. Subsequently, the computer causes the remedial action to be performed by a security service.

IPC Classes  ?

• G06F 21/55 - Detecting local intrusion or implementing counter-measures

Abstract

Disclosed are various embodiments for enhancing financial capabilities of transaction accounts. A user could request a modified purchasing power or request to split a transaction between a plurality of transaction accounts. First, the global purchasing capacity is calculated. Next, the risk exposure is calculated based at least in part on a risk profile and the global purchasing capacity. Next, a respective purchasing power of a transaction account is modified. The modification of the respective purchasing power could cause the global purchasing capacity to be recalculated. Next, the user is notified of the modified purchasing power. In some instances, the purchasing power could be modified by splitting the transaction between the plurality of transaction accounts or between a first transaction account and a second transaction account.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems

Abstract

Disclosed are various embodiments for action specific award tracking. An award multiplier is determined based at least in part on action data. Then, a unique action identifier is generated which is associated with the award multiplier. Next, an action is initiated based at least in part on an action request which comprises the unique action identifier. Then, an award is calculated based at least in part on the unique action identifier in an action receipt. Finally, an award can be deducted based at least in part on a unique action identifier in a cancellation request.

IPC Classes  ?

• G06Q 30/0208 - Trade or exchange of goods or services in exchange for incentives or rewards
• G06Q 30/0207 - Discounts or incentives, e.g. coupons or rebates
• G06Q 30/0238 - Discounts or incentives, e.g. coupons or rebates at point-of-sale [POS]

Abstract

Disclosed are approaches for verifying user characteristics in a decentralized and anonymized fashion. A first request is received from a client device to verify a characteristic of a user associated with the client device, the request identifying an attribute service and the request comprising personally identifying information (PII) associated with the user. Then, a second request for one or more attributes of the user is sent to the attribute service, wherein the second request comprises at least a portion of the PII associated with the user of the client device. One or more attributes of the user from the attribute service and anonymized. The anonymized attributes and a prompt are then sent to a verifier service, wherein the prompt causes a large language model associated with the verifier service to verify the characteristic of the user based at least in part on the one or more anonymized attributes.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Systems and methods are described relating to a payment instrument with configurable services, in which the user can adjust the available services. In one example, a system includes a computing device that is configured to display a user interface that is configured to modify a services configuration for a payment instrument. The services configuration indicates a plurality of benefit services that are applied to a respective transaction. A modification of the services configuration is received from the user interface. An updated user interface is displayed that includes a charge for the services configuration based at least in part on the modification of the services configuration. An acceptance of the charge is received from the updated user interface. The services configuration is updated by storing the services configuration in association with the user identifier at a database based at least in part on the acceptance of the charge.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for using machine learning models to identify appropriate security patterns to follow during the application development process. A computing device can receive a request to identify a collection of security patterns to apply to an application and then identify a plurality of features associated with the application. Next, the computing device can submit the plurality of features to a random forest machine learning model and receive a first set of security patterns in response. Then, the computing device can submit the plurality of features to a k-nearest neighbor (KNN) machine learning model and receive a second set of security patterns in response. Then, the computing device can identify a subset of the security patterns that is included in both the first set of security patterns and the second set of security patterns and return the subset of the security patterns.

IPC Classes  ?

• G06F 21/52 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure
• G06N 20/20 - Ensemble learning

Abstract

Disclosed are various embodiments for implementing scheduled transactions within a payment network. A computing device first determines that a trigger has occurred for a scheduled transaction for a first payment network. Then, the computing device identifies a network identifier for the recipient and a participant identifier for a recipient of the scheduled transaction. Next, the computing device determines, based at least in part on the network identifier, that the recipient of the scheduled transaction is associated with a second payment network. Subsequently, the computing device generates a payment request representing the scheduled transaction, the payment request comprising the network identifier for the recipient and the participant identifier for the recipient. Then, the computing device forwards the payment request to a global transaction router of a supernetwork.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for securely sharing confidential data between applications. A deep link request can be received from a first computing device, the deep link request identifying a set of data to be shared and a deep link schema. A token that represents the set of data can then be created. Also, a deep link that complies with the deep link schema and includes the token can also be created. The deep link and the token can then be returned to the first computing device. Later, a data request containing the token can be received from a second computing device. The set of data associated with the token can then be return to the second computing device.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• G06F 21/44 - Program or device authentication
• G06F 21/60 - Protecting data

Abstract

A system for generating graphical relationship maps is disclosed. The system may receive a search request. The system may generate a relationship map data based on linked data elements of at least one of a structured data set, an unstructured data set, and a hybrid data set comprising structured and unstructured data. The system may display a graphical relationship map including an entity type icon based on the relationship map data and the search request.

IPC Classes  ?

• G06F 16/248 - Presentation of query results
• G06F 16/245 - Query processing
• G06F 16/26 - Visual data miningBrowsing structured data
• G06F 40/40 - Processing or translation of natural language

Abstract

Systems and methods of the present disclosure may read source data corresponding to a source variable; apply a first transformation to the source variable to generate a first output variable; record lineage data of the first output variable, wherein the lineage data includes the first transformation, the source variable, and the first output variable; receive a request to generate a second output variable from the source data corresponding to the source variable; determine a second transformation to be applied to the source variable to generate the second output variable; match the second transformation with first transformation using the lineage data; and/or output the first output variable in place of generating the second output variable.

IPC Classes  ?

• G06F 16/11 - File system administration, e.g. details of archiving or snapshots
• G06F 16/2458 - Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries

Abstract

Disclosed are various approaches performing distributed profiling and validation. A query is generated for profile data for data stored in a data warehouse. Then, the query for the profile data is sent to the data warehouse. The profile data is then received from the data warehouse. Later, in response to a request to load the data stored in the data warehouse into a table in a data store, a determination is made as to whether the data stored in the data warehouse complies with a validation rule.

IPC Classes  ?

• G06F 16/2457 - Query processing with adaptation to user needs
• G06F 16/22 - IndexingData structures thereforStorage structures
• G06F 16/2455 - Query execution

Abstract

Disclosed are various embodiments of a wearable computing device which may be embedded in a fob or tag for use in completing financial transactions. In one example, a system comprises a computing device that is configured to retrieve a secure chip identifier (ID) and an alias code from a wearable device using a Bluetooth connection, and the secured chip ID being is retrieved from the secure chip. A selection of a transaction account for linking to the wearable device is identified. The alias code and the transaction account are transmitted to a transaction account issuer for linking the alias code to the transaction account a contactless payment feature on the wearable device based at least in part on the selection of the transaction account.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06F 16/955 - Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
• G06K 19/07 - Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards with integrated circuit chips
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed herein are system, method, and computer program product embodiments for performing a task. For example, the method includes receiving a triggering event from a client device and generating a processing map. The processing map indicates a processing flow between a plurality of processing instances to execute the task associated with the triggering event. The plurality of processing instances belongs to a topography map specifying a network topography including the plurality of processing instances. For each of the plurality of the processing instances, the method further includes identifying the respective processing instance based on the topography map and outputting the processing map and data associated with the triggering event to the respective processing instance to execute the task.

IPC Classes  ?

• G06F 9/48 - Program initiatingProgram switching, e.g. by interrupt

Abstract

Disclosed are various embodiments for modifying transactions. A computer device can determine that a transaction has been authorized for an account, the transaction including an authorization amount and a merchant identifier. Then, the computing determine that the merchant identifier is included in a set of merchant identifiers associated with a transaction modification program. Next, the computing device can determine that the account is included in a set of accounts enrolled with the transaction modification program. Subsequently, in response to the first determination that the merchant identifier is included in the set of merchant identifiers associated with the transaction modification program and the second determination that the account is included in a set of accounts enrolled with the transaction modification program, the computing device can send a notification to an application executing on a client device associated with the account, the notification indicating that the transaction is a modifiable transaction.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment

Abstract

Disclosed are various embodiments for leveraging deep learning-based recurrent neural networks (RNNs) using time-series data to evaluate fraud risk for an incoming transaction associated with a user account. Time-series attributes can be extracted from historical transaction data and the incoming transaction data. The time-series attributes can be defined as an array of sequential events that are inputted into an RNN-based machine-learning framework to predict whether an incoming or otherwise pending transaction is fraudulent given the spending sequence. An RNN-based time-series prediction model can be trained to understand and predict patterns associated with a user's spending history according to the inputted time-series data in order to predict whether the transaction is fraudulent.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06N 3/045 - Combinations of networks
• G06N 3/10 - Interfaces, programming languages or software development kits, e.g. for simulating neural networks

Abstract

Disclosed are various embodiments for a predictive communication system and related methods. One such method comprises training a predictive computer model to determine a ranking of intent insights based on prior servicing interactions with users; determining, from real-time activity data, that an accumulation of account activity data of the user has reached a specified threshold limit; generating, using the predictive computer model, a ranking of a plurality of intent insights associated with the communication; transmitting, to a client device of the user, the ranking of the plurality of intent insights and a user feedback inquiry comprising an accuracy inquiry to confirm whether individual ones of the plurality of intent insights are accurate; and retraining the predictive computer model of the at least one computing device based on the user feedback.

IPC Classes  ?

• H04L 67/50 - Network services
• G06N 5/04 - Inference or reasoning models
• G08B 21/18 - Status alarms
• H04L 51/212 - Monitoring or handling of messages using filtering or selective blocking
• H04L 67/306 - User profiles
• H04L 67/55 - Push-based network services

Abstract

Systems and methods for motion-enabled transactions are disclosed. The system may allow users to complete transactions with merchants via an air sign input. The system may receive a motion-enabled transaction request comprising an air sign input. The system may determine a stored air sign symbol based on the air sign input. The system may retrieve a merchant identifier, a transaction type, and a transaction cost based on the determined stored air sign symbol. The system may transmit a transaction confirmation comprising the merchant identifier, the transaction type, and the transaction cost. In response to the user confirming the transaction confirmation, the system may authorize and process the transaction.

IPC Classes  ?

• G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
• G06F 3/01 - Input arrangements or combined input and output arrangements for interaction between user and computer
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices

Abstract

Systems and methods are described for mobile device transaction credential lending. In one example, a system comprises a computing device that includes a secure element. The secure element includes machine-readable instructions that, when executed by the processor, cause the secure element device to at least receive a request from a wallet application executed on the computing device to generate a sub-payment key, the request comprising a key restriction. The sub-payment key is generated based at least in part on a payment key stored in the secure element and the key restriction and returned to the wallet application.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• H04W 12/04 - Key management, e.g. using generic bootstrapping architecture [GBA]

Abstract

A system, method, and article of manufacture for splitting a shared financial obligation is disclosed. In one example, a system is configured to receive a request to establish a group of members and transmit a list to a first device for selection on a website. A selection of group members is identified and the group of members are generated. A group notification is transmitted to client devices. A first charge to be included to the shared financial obligation is identified. A portion of the shared financial obligation to assign to a second member is determined. A first notification of the portion is transmitted to a second device. A second charge to be included to the shared financial obligation is identified. An updated portion of the shared financial obligation is determined. A second notification of the portion of the shared financial obligation is transmitted to the second device.

IPC Classes  ?

• G06Q 20/22 - Payment schemes or models
• G06Q 20/14 - Payment architectures specially adapted for billing systems

Abstract

Systems and methods for secure mobile checkouts are disclosed. The system may include a secure mobile checkout device configured to scan products available in a merchant store. The device may scan the product to determine a product identifier. The device may transmit the scanned product data to a checkout application to retrieve product data corresponding to the product identifier. In device may initiate a transaction with a payment network to purchase the product, based on the product data provided by the checkout application. The payment network may process the transaction, and may authorize the purchase with the merchant.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

System and methods are described for enabling a first client device to authorize a second client device to use a payment token for contactless payments, in which the payment token is authorized to be used by the second device with restrictions set by the first device. In one embodiment, a system comprises a computing device that includes a secure element. The system also includes machine-readable instructions that, when executed by the processor, cause the computing device to at least receive an indication for generating a sub-payment token and receive a selection of a key restriction for the sub-payment token. An application stored in the secure element is called to generate the sub-payment token based on the key restriction. The sub-payment token is received and comprises a sub-payment key and an application transaction counter range. The sub-payment token is sent through the wireless communication session to a second computing device.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• H04W 12/04 - Key management, e.g. using generic bootstrapping architecture [GBA]

Abstract

A dynamic banner may be displayed in a merchant check out page sourced from a merchant server that may be customized to a particular user and/or merchant. The dynamic banner may be provided by a transaction server and may invite the user to select an offer. In response to the user's interaction with the banner, the characteristics of the merchant check out page may be changed, for example, a product may be discounted, and/or a new transaction account may be issued to the user by the transaction account provider server and used to complete the checkout process. In this manner, the merchant server and the transaction server may interact with a user within a single web page.

IPC Classes  ?

• G06Q 20/12 - Payment architectures specially adapted for electronic shopping systems
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 30/02 - MarketingPrice estimation or determinationFundraising
• G06Q 30/0251 - Targeted advertisements

Abstract

A system, method, and computer readable medium (collectively, the “system”) are provided. The system may include a processor configured to perform operations and/or steps comprising receiving, from a transaction account issuer, a token comprising an alias transaction account data; storing the token in a digital wallet of a computing device; selecting a transaction account to be used as payment for a transaction; and transmitting a wireless signal carrying emulated track data for payment of the transaction, wherein the emulated track data emulates physical transaction card data and includes the alias transaction account data in place of actual transaction account data.

IPC Classes  ?

• G06Q 20/38 - Payment protocolsDetails thereof
• G06K 19/06 - Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• H04L 9/08 - Key distribution
• H04L 9/14 - Arrangements for secret or secure communicationsNetwork security protocols using a plurality of keys or algorithms
• H04L 9/40 - Network security protocols
• H04W 4/80 - Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
• H04W 12/0431 - Key distribution or pre-distributionKey agreement
• H04W 12/0433 - Key management protocols

Abstract

Disclosed are various embodiments for automated document processing. An automatic submission criterion and a submission template for a provider service can be stored in association with a user account. The submission template can specify how to complete submissions for the provider service. A transaction record comprising transaction data can be received in association with the user account. In an instance in which the automatic submission criterion matches the transaction record, a submission to the provider service can be completed and submitted according to the submission template and based at least in part on the transaction data.

IPC Classes  ?

• G06F 40/174 - Form fillingMerging
• G06F 21/44 - Program or device authentication

Abstract

Disclosed are various embodiments for an online purchase autofill plug-in. Various embodiments can access an electronic form from a domain and then scan the electronic form for a plurality of fields. Various embodiments can receive data from an API engine which can correspond to at least one field of the plurality of fields of the electronic form. Various embodiments can then populate the at least one field in the electronic form using the data from the API engine. In at least some embodiments, the data from the API engine can be account information for a user, which can be used to fill out a payment form.

IPC Classes  ?

• G06F 40/174 - Form fillingMerging
• G06F 3/0481 - Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
• G06N 5/048 - Fuzzy inferencing
• G06N 7/02 - Computing arrangements based on specific mathematical models using fuzzy logic
• G06N 20/00 - Machine learning
• G06Q 20/12 - Payment architectures specially adapted for electronic shopping systems

Abstract

Disclosed herein are system, method, and computer program product embodiments for providing predictive revenue distribution using machine learning and a Real-Time Payment (RTP) network. A revenue distribution system may train and apply a machine learning model to merchant transaction records to generate a predicted revenue amount. The revenue distribution system may deposit predicted revenue amounts to provide predictive funding for merchant accounts. For example, this may provide same-day and/or next-day funding. The revenue distribution system may account for differences in predicted revenue amounts and actual transaction amounts by adjusting the deposits of subsequent days. The revenue distribution system may also account for different periods of time, such as several days, a week, or longer. The revenue distribution system may also detect potentially fraudulent transaction amounts and/or may aid in monitoring business performance based on a detected difference between a predicted revenue amount and a provided transaction amount.

IPC Classes  ?

• G06Q 40/12 - Accounting
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems

Abstract

Disclosed are various embodiments for a payment instrument, such as a payment card or a client device, that interfaces with multiple central bank digital currency (CBDC) networks associated with different countries and territories. In one non-limiting example, the system comprises a computing device that is configured to detect a location of a client device being outside of a territorial area for a first CBDC blockchain network and receive an authorization request from a merchant system for a purchase of an item. A token associated with the authorization request is identified and associated with the client device. The computing device determines that the token is authorized for use with a blockchain address for a second CBDC blockchain network for the purchase. A CBDC blockchain transfer is generated and the CBDC blockchain transfer is transmitted to the second CBDC blockchain network.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Systems and methods for automated linkage of enriched transaction data to a record of charge are provided. Electronic enriched transaction data, such as receipt information, provided by merchants, merchant aggregators, or third parties may be automatically associated with the corresponding transaction, and transmitted after the sale, or after authorization of the transaction, without user intervention. The enriched transaction data may be automatically associated with the record of charge at the acquirer or issuer end. Transaction account holders are able to view and/or download the electronic enriched transaction data with the record of charge, without the need for manually initiating emailing or attaching or the electronic enriched transaction data.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

A method comprising creating, by a computer-based system for shifting financial responsibility for a transaction from a merchant to a transaction account issuer, a digital wallet associated with a transaction account holder, wherein the digital wallet comprises one or more attributes associated with the transaction account holder, confirming, by the computer-based system, the attribute in response to a transaction request, and/or determining, by the computer-based system, whether to shift financial responsibility for the transaction from the merchant to the transaction account issuer.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes

Abstract

Disclosed are various embodiments for conducting central bank digital currency (CBDC) transactions. A user CBDC wallet can be stored in a wallet application corresponding to a wholesale wallet, which can allow users to conduct transactions that might otherwise be impractical using the user wallet. Multiple funding sources can be accommodated by the wallet application.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/22 - Payment schemes or models
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

A system may deliver personalized content to a user. The system may create a user persona based on demographic information and stored clickstream data of the user. The system may learn which functionalities the user typically uses on a webpage, and the system may create a personalized version of the webpage for the user.

IPC Classes  ?

• G06F 16/9535 - Search customisation based on user profiles and personalisation
• G06F 16/955 - Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
• G06F 40/106 - Display of layout of documentsPreviewing
• G06F 40/134 - Hyperlinking

Abstract

Disclosed are various embodiments for a point of sale application for a mobile device. In some embodiments, a system comprises a mobile device that is configured to receive a command from a service system to activate a personal point of sale (POS) application. The personal POS application is executed based at least in part on the command. A payment token is generated based at least in part on payment information. A cryptogram is generated for securing the payment token. The cryptogram is transmitted to the service system.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are examples of transaction cards incorporating aluminum or aluminum alloys. The aluminum can be extracted or recycled from a retired aircraft. Other materials can also be incorporated into the transaction card to provide sufficient weight and rigidity to the transaction card. Stainless-steel can be incorporated into the construction of the card in combination with aluminum to provide a desired user experience.

IPC Classes  ?

• G06K 19/077 - Constructional details, e.g. mounting of circuits in the carrier
• B32B 15/20 - Layered products essentially comprising metal comprising aluminium or copper
• B32B 27/30 - Layered products essentially comprising synthetic resin comprising vinyl resinLayered products essentially comprising synthetic resin comprising acrylic resin
• B32B 43/00 - Operations specially adapted for layered products and not otherwise provided for, e.g. repairingApparatus therefor
• G06K 19/07 - Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards with integrated circuit chips

Abstract

Disclosed are various embodiments for metaverse authentication using NFTs. An authentication setup request for an NFT can be received from an owner of the NFT. Then, a unique authentication credential for the NFT can be requested from an NFT smart contract. In response, URL of an edge wallet associated with an owner of the unique authentication credential is received. Then, a request can be sent to the URI of the edge wallet for the unique authentication credential. In response, a signed challenge is received from the edge wallet and a public key is retrieved from the NFT. A signature of the signed challenge is determined to be valid based at least in part on the public key, and access to an asset or resource is configured based at least in part on the signature of the signed challenge being valid.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• H04L 9/08 - Key distribution
• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system

Abstract

A method is provided comprising receiving, at a first node, transactional data associated with a consumer (wherein the first node comprises a processor and a tangible, non-transitory memory), receiving, at the first node, a credit approval request associated with the consumer, wherein the credit approval request is associated with a proposed transaction, determining, by the first node, whether the transactional data conforms with the proposed transaction, and at least one of approving and denying the credit approval request in response to the determination.

IPC Classes  ?

• G06Q 40/03 - CreditLoansProcessing thereof
• G06Q 20/12 - Payment architectures specially adapted for electronic shopping systems
• G06Q 20/24 - Credit schemes, i.e. "pay after"
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
• G06Q 50/00 - Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism

Abstract

Systems and methods for transaction authorizations using a distributed database are disclosed. The system may allow registered transaction account holders and merchants to interact and complete transactions according to workflows enforced by smart contracts. The system may include an issuer system that receives a transaction authorization request comprising a merchant ID, a transaction account number, a transaction amount, and a transaction ID. The issuer system may retrieve a merchant public key and a smart contract based on the merchant ID, and a user public key based on the transaction account number. The issuer system may invoke the smart contract by passing the user public key and the transaction ID to the smart contract. The system may propagate transaction data (e.g., the merchant ID, the transaction account number, the payment amount, a transaction status, etc.) to a blockchain network for writing to a blockchain according to the invoked smart contract.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06F 16/23 - Updating
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof
• H04L 9/00 - Arrangements for secret or secure communicationsNetwork security protocols
• H04L 9/30 - Public key, i.e. encryption algorithm being computationally infeasible to invert and users' encryption keys not requiring secrecy
• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
• H04L 9/40 - Network security protocols

Abstract

Disclosed are various embodiments for a predictive communication system. In one embodiment, a communication is received from a user, and a profile associated with the user is identified. Real-time activity data associated with the profile and obtained from one or more internal channels via a messaging bus is accessed. A redeemable value accumulation in the activity data is determined to have reached a specified threshold. An intent prediction alert associated with the communication is determined according to one or more of a plurality of intent prediction rules based at least in part on the redeemable value accumulation reaching the threshold, where the intent prediction alert includes a predicted reason for the communication.

IPC Classes  ?

• H04L 67/50 - Network services
• G06N 5/04 - Inference or reasoning models
• G08B 21/18 - Status alarms
• H04L 51/212 - Monitoring or handling of messages using filtering or selective blocking
• H04L 67/306 - User profiles
• H04L 67/55 - Push-based network services

Abstract

Disclosed are various approaches for onboarding payment networks to participate in a supernetwork that facilitates payments between different payment networks. In particular, a participant registry that stores the registration information of registered payment networks can be managed. The registration information can include a network identifier, protocol data, routing logic, interface configuration data, and additional information that may need to be required to translate and facilitate communication and payment transactions between different registered payment networks

IPC Classes  ?

• G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/14 - Payment architectures specially adapted for billing systems
• G06Q 20/16 - Payments settled via telecommunication systems

Abstract

Disclosed are various embodiments of methods and systems for central bank digital currency (CBDC) facilitated micropayments. In at least some embodiments, a system can receive an authorization request for a purchase, the authorization request can include a total transaction amount. The system can identify a payment token associated with the authorization request and obtain a plurality of payee wallet addresses. The system can then receive a transaction amount for each of the plurality of payee wallet addresses, such that a sum of the transaction amounts for the plurality of payee wallet addresses is equal to the total transaction amount. The system can then generate a CBDC transfer for each of the plurality of payee wallet addresses using a private key based at least in part on an authorization for the payment token to use a blockchain address, each CBDC blockchain transfer comprising a digital signature and transmit each of the CBDC blockchain transfers for the purchase to a CBDC blockchain network.

IPC Classes  ?

• G06Q 20/22 - Payment schemes or models
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for determining availability of payment entities existing on various payment networks. In one non-limiting example, a computing device is configured to transmit a query to a first network hub for a status of a participant system. The participant system is connected to the first network hub. The computing device is configured to determine a participant status for the participant system based at least in part on a query response from the first network hub. A participant status cache is updated based at least in part on the participant status. The participant status is propagated to a second network hub connected to the first supernetwork instance. The participant status is propagated to a second supernetwork instance connected to the first supernetwork instance.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for optimal routing of payments. A global transaction router hosted by a supernetwork instance can receive a payment request, where the payment request specifies an identifier for a recipient institution. The global transaction router can identify a plurality of routes from the global transaction router to a plurality of respective destination network hubs associated with the recipient institution. The global transaction router can calculate a score for individual routes of the plurality of routes, where the score is based on a plurality of routing factors. The routing factors can be weighted based at least in part on routing preferences included with the payment request. The global transaction router can select one of the plurality of routes based on the score and cause the payment request to be provided to a destination network hub on the one of the plurality of routes.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/08 - Payment architectures

Abstract

Disclosed are various embodiments for facilitating payments between members of separate payment networks. At least one embodiment can send a payment request to a network hub connected to a supernetwork instance and linked to a first payment network, the payment request specifying an identifier for a recipient institution and an amount of the payment request. Then the embodiment can receive a payment response to the payment request indicating that the payment request is being forwarded to a global transaction router of the supernetwork instance, wherein the response to the payment request comprises at least a supernetwork tracking identifier. The embodiment can then send a tracking request to a transaction tracker service of the supernetwork instance, the tracking request comprising the supernetwork tracking identifier. Then the embodiment can receive a tracking response to the tracking request, the tracking response comprising various tracking information.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]

Abstract

Disclosed herein are system, method, and computer program product embodiments for providing a virtual card token to facilitate Real-Time Payment (RTP) network transactions. An account management system may facilitate RTP transactions with consumer bank accounts using the virtual card token. After providing the virtual card token to a user device, the user device may present the virtual card token to a merchant system to conduct a transaction. The virtual card token may operate with existing merchant systems and/or point-of-sale (POS) terminals. The merchant system may provide the virtual card token to the account management system for transaction approval. The account management system may select and retrieve funding from a particular bank account based on user-defined parameters. Upon retrieving funding from the particular bank account via the RTP network, the account management system may approve the transaction and/or provide payment to the merchant system.

IPC Classes  ?

• G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for augmented intelligent machine for systematic attribution of data security. A set of global regulations is received by the system. Next, at least one decision rule for mapping one or more data elements is output based at least in part on the set of dynamic global regulations. A data input is received from at least one data source. Next, the data input is parsed to determine at least one sensitive data elements. Then, a confidentiality level of at least one sensitive data element is determined. The ingesting table is joined with a drive mapping data set. Finally, at least one security policy is applied to a type of data input based at least in part on the drive mapping data set or the confidentiality level.

IPC Classes  ?

• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
• G06F 21/31 - User authentication

Abstract

Disclosed are various embodiments for converting cryptocurrency to central bank digital currency for transactions. In one example, among others, a system comprises a computing device and machine-readable instructions stored in the memory. The instructions cause the computing device to identify a cryptocurrency request for a pending transaction of an item, in which the pending transaction comprises a token. The instructions cause the computing device to determine a device identifier associated with the token and determine a cryptocurrency amount for the item. A user interface on a client device is activated in order to request an acceptance of the cryptocurrency amount. A withdrawal instruction is transmitted to a cryptocurrency exchange for the cryptocurrency amount on behalf of a user. In this non-limiting example, a blockchain transfer of a transaction price for the item with a central bank digital currency blockchain network is transmitted.

IPC Classes  ?

• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/20 - Point-of-sale [POS] network systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment

Abstract

A transaction card is described that includes a first layer, a second layer, a loop antenna, an inductive illumination antenna, and a light-emitting element. At least a one of the first layer and the second layer has a transparent planar portion through which light transmits. The loop antenna is inset between the first layer and the second layer. The light-emitting element has a first terminal and a second terminal. The inductive illumination antenna is inset between the first layer and the second layer and positioned proximate to the loop antenna such that, when the transaction card is positioned in a magnetic field, the inductive illumination antenna is induced with a current from the loop antenna. The inductive illumination antenna is connected to the first terminal and the second terminal.

IPC Classes  ?

• G06K 19/07 - Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards with integrated circuit chips
• G06K 19/077 - Constructional details, e.g. mounting of circuits in the carrier

Abstract

Disclosed are various embodiments for implementing scheduled transactions within a payment network. A computing device first determines that a trigger has occurred for a scheduled transaction for a first payment network. Then, the computing device identifies a network identifier for the recipient and a participant identifier for a recipient of the scheduled transaction. Next, the computing device determines, based at least in part on the network identifier, that the recipient of the scheduled transaction is associated with a second payment network. Subsequently, the computing device generates a payment request representing the scheduled transaction, the payment request comprising the network identifier for the recipient and the participant identifier for the recipient. Then, the computing device forwards the payment request to a global transaction router of a supernetwork.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for automated schema lifecycle management. A first revision of the schema is identified from one or more revision(s). Then, the revision is evaluated to determine a state identifier or a classification. Next, a second revision of the schema is identified, wherein the second revision of the schema contains at least one of a second state or a second classification of the second revision of the schema. Then, a determination of compatibility between the first revision of the schema and the second revision of the schema is made based at least in part on one or more compatibility rules. Finally, an automated action is performed based at least in part on the second revision of the schema being compatible with the first revision of the schema.

IPC Classes  ?

• G06F 16/21 - Design, administration or maintenance of databases

Abstract

Disclosed are various embodiments for providing multirail payment accounts. First, a payment instruction specifying at least a recipient of the payment and an amount of the payment can be received. Then, one or more payment policies applicable to the payment instruction can be identified. Next, the payment instruction can be funded according to the one or more payment policies. Subsequently, a payment request can be generated based at least in part on the payment instruction. Then, the payment request can be sent to a network hub.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/22 - Payment schemes or models

Abstract

Disclosed are various embodiments for self-healing data clusters. One or more candidates are determined from the candidate pool to be evaluated with the new record. A unique pair combination is generated for each one of the candidates of the candidate pool and the new record. Next, candidate data for the one or more candidates is identified from the existing record based at least in part on one or more matching rules. A weight is assigned to one or more matching rules. Then, the candidate data of the one or more candidates and the new record is evaluated for a data linkage. A distance is calculated between each of the unique pair combinations. Finally, the candidates of the existing record and the new record are clustered into groups.

IPC Classes  ?

• G06F 16/906 - ClusteringClassification

Abstract

Disclosed are various approaches for onboarding payment networks to participate in a supernetwork that facilitates payments between different payment networks. In particular, a participant registry that stores the registration information of registered payment networks can be managed. The registration information can include a network identifier, protocol data, routing logic, interface configuration data, and additional information that may need to be required to translate and facilitate communication and payment transactions between different registered payment networks.

IPC Classes  ?

• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

A dynamic banner may be displayed in a merchant check out page sourced from a merchant server that may be customized to a particular user and/or merchant. The dynamic banner may be provided by a transaction account provider server and may invite the user to select an offer. In response to the user's interaction with the offer, the characteristics of the merchant check out page may be changed, for example, a product may be discounted, and/or a new transaction account may be issued to the user by the transaction account provider server and used to complete the checkout process via cross document messaging and cross domain scripting. In this manner, the merchant server and the transaction account provider server may interact with a user within a single web page.

IPC Classes  ?

• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/12 - Payment architectures specially adapted for electronic shopping systems
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 30/02 - MarketingPrice estimation or determinationFundraising
• G06Q 30/0251 - Targeted advertisements

Abstract

Disclosed are various approaches for securing communications channels. Security-related sensor data representing a security characteristic of a network component is retrieved from a trust mediator. Then, a risk level associated with a transfer is computed, the risk level being based at least in part on the transfer and the security-related sensor data. Next, the risk level for modifying security safeguards in the network component to maintain a security level for the transfer is transmitted to the trust mediator. Subsequently, the transfer can be authorized based at least in part on a determination that a user trust score is greater than or equal to the risk level.

IPC Classes  ?

• H04L 9/40 - Network security protocols

Abstract

Disclosed herein are aspects for splitting a transaction. An example aspect begins by receiving transaction information specifying a transaction. The aspect continues by receiving split request information corresponding to the transaction. The split request information specifies how to split the transaction with one or more other parties. Next, the aspect sends, by a first user device, a split request to a second user device based on the split request information. The split request comprises input fields for each of the respective one or more other parties. These input fields include respective payer account identifier and actual payment amount fields. The aspect continues by receiving, based on an input from a user interface of the second user device, the payer account identifier and the actual payment amount. Lastly, the aspect sends a payment request to a payer account corresponding to the payer account identifier for the actual payment amount.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed herein are aspects for splitting a recurring charge. An example method aspect begins by receiving transaction information specifying a transaction. The method continues by determining whether the transaction is recurring. When the transaction is determined to be recurring, the method creates a split protocol for the transaction based on an input from a user interface of a first user device. The split protocol specifies how to split the transaction with one or more other parties. The method then continues with several operations for each of the respective one or more other parties. Based on the split protocol, the method generates a split request specifying a portion of the transaction the respective other party should pay. The method then sends the split request to a second user device corresponding to the respective other party. The method can repeat the generating and sending steps for subsequent recurrences of the transaction.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards

Abstract

Disclosed are various embodiments for executing entity-specific cryptographic code in a cryptographic coprocessor. In one embodiment, an exemplary method comprises transmitting, from an entity service to a client device, a key identifier and encrypted code that implements a cryptographic algorithm, wherein the encrypted code further includes an encryption key, wherein the key identifier identifies a particular root key that is associated with the entity service and is stored with a cryptographic coprocessor of the client device; receiving, by the entity service from the client device, a cryptogram that includes information encrypted using the cryptographic algorithm and the encryption key; and decrypting, by the entity service, the cryptogram using the encryption key.

IPC Classes  ?

• G06F 21/72 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
• G06F 21/60 - Protecting data
• H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system

Abstract

A system for making payments is disclosed. The system performs steps to at least receive a barcode with embedded information linking to a payee account capable of receiving a payment. Based on receiving the barcode a prompt for display on a browser of the user device can be generated, where the prompt requests identification of a financial institution connected to a user of the user device. The prompt can be transmitted to the user device. Identifying information identifying the financial institution can be received in response to the prompt. The financial institution can be accessed based on the response to the prompt. Based on accessing the user financial institution a request for the payment from the user financial institution to the payee account can be made.

IPC Classes  ?

• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for facilitating payments between members of separate payment networks. A first instance of a supernetwork can receive a payment request from a source network hub connected to the first supernetwork instance and linked to a first payment network, the first payment request specifying an identifier for a recipient institution and an amount of the payment request. The first instance of the supernetwork can then query a participant status cache to identify a destination network hub linked to a second payment network associated with the recipient institution. Next, the first instance of the supernetwork can query a participant registry to identify a second supernetwork instance connected to the destination network hub. Finally, the first instance of the supernetwork can forward the payment request to a second global transaction router hosted by a second supernetwork instance connected to the destination network hub.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems

Abstract

Disclosed herein are method, computer program product, and system embodiments for real-time loyalty rewards redemption. A user may earn rewards in a rewards system that have an equivalent value to a digital asset such as a cryptocurrency asset (e.g., Bitcoin, Ethereum, etc.), crypto tokens (e.g., ERC-20, Dogecoin, etc.), and/or the like. A user device (e.g., mobile device, smart device, etc.) may request to redeem the rewards value in the form of the digital asset, initiating transfer of the digital asset from an asset management system to a digital wallet of the user device. The transfer of the digital asset from the asset management system to the digital wallet of the user device happens in real-time. After the digital asset is transferred to the user device, it may be exchanged for monetary value via a third party redemption service or used as payment.

IPC Classes  ?

• G06Q 30/0226 - Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed herein are system, apparatus, article of manufacture, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for allowing an account holder to authorize an entity to issue pull requests for funds to be transferred using real time payment rails. A first account representing a store of central bank digital currency (CBDC) of a first user may be linked with a second account representing a store of central bank digital currency (CBDC) of a second user. A request may be received, from one of the first and second user, to transfer CBDC from the first account to the second account. From another of the first and second user, an authorization may be received to transfer the CBDC. In response to the authorization, an entry may be written to a blockchain ledger effecting the requested transfer of the CBDC from the first account to the second account.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance

Abstract

Disclosed are various embodiments for facilitating payments between members of separate payment networks. A first instance of a supernetwork can receive a payment request from a source network hub connected to the first supernetwork instance and linked to a first payment network, the first payment request specifying an identifier for a recipient institution and an amount of the payment request. The first instance of the supernetwork can then query a participant status cache to identify a destination network hub linked to a second payment network associated with the recipient institution. Next, the first instance of the supernetwork can query a participant registry to identify a second supernetwork instance connected to the destination network hub. Finally, the first instance of the supernetwork can forward the payment request to a second global transaction router hosted by a second supernetwork instance connected to the destination network hub.

IPC Classes  ?

• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06Q 20/16 - Payments settled via telecommunication systems
• G06Q 20/14 - Payment architectures specially adapted for billing systems
• G06Q 20/38 - Payment protocolsDetails thereof

Abstract

Disclosed are various embodiments for providing automated non-billing cycle remittances in order to load-balance batch processing jobs. An eligible user is identified for registration. Then, a registration request is sent to the user. Next, user registration data is received in response to the registration request, the user registration data specifying an event trigger. Then, it is determined that the processing event trigger has occurred. Subsequently, the processing event is executed in response to the processing event trigger occurring.

IPC Classes  ?

• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
• G06F 9/48 - Program initiatingProgram switching, e.g. by interrupt

Abstract

Disclosed herein are system, method, and computer program product embodiments for direct device-to-device asset transfer. A first user device (e.g., mobile device, smart device, etc.) may send a second user device (e.g., mobile device, smart device, etc.), via a first communication protocol, a portion of allocation information that allocates transaction item to a user of the second user device based on an indication that the second user device is in proximity to the first user device. The first user device may receive an asset from an account associated with the second user device via a second communication protocol based on an indication that the portion of the allocation information that allocates the item associated with the transaction to the user of the second user device is confirmed by the second user device. A value of the asset may correspond to a value indicated by the portion of the allocation information.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
• G06Q 20/22 - Payment schemes or models
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for analyzing machine learning models. A selection is obtained of a first tuple comprising a first feature vector and a first result generated by a machine learning model and a second tuple comprising a second feature vector and a second result generated by the machine learning model. Then, a plurality of emulated feature vectors are generated. Next, a plurality of emulated results are generated. Subsequently, a plurality of emulated decision instances are generated. Next, a decision tree is built based at least in part on the first tuple, the second tuple, and the plurality of emulated decision instances. Finally, an importance of each feature on the decision tree is computed.

IPC Classes  ?

• G06N 20/00 - Machine learning

Abstract

Disclosed are various embodiments for allowing selectable currency within an account. In at least some embodiments, a system can receive a first request to exchange central bank digital currencies (CBDCs) within a collateral account from a first CBDC denomination to a second CBDC denomination. The system can then obtain, from a market application, an exchange rate that can be used to calculate an exchange between the first CBDC denomination and the second CBDC denomination. The system can identify a first amount of the first CBDC denomination within the collateral account and calculate a second amount of the second CBDC denomination. The system can obtain the second amount of the second CBDC denomination and credit the second amount of the second CBDC denomination to the collateral account. The system can also debit the first amount of the first CBDC denomination from the collateral account.

IPC Classes  ?

• G06Q 40/04 - Trading Exchange, e.g. stocks, commodities, derivatives or currency exchange
• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 20/38 - Payment protocolsDetails thereof
• G06Q 40/06 - Asset managementFinancial planning or analysis