Abstract

Disclosed herein are system, method, and computer program product embodiments for a method of automated payment processing. In some embodiments, the method may receive a transaction request from a purchaser to transfer a payment amount from a purchaser account of the purchaser to a supplier account associated with a supplier. The transaction request may be an invoice including a payment amount for the specific transaction and a supplier identification number identifying the supplier. In response to the transaction request, the method debits the payment amount from the purchaser account, identifies the supplier account based on the supplier identification number, and credits the payment amount to the identified supplier account. The purchaser account may be linked to a transaction card used to pay the payment amount. The method allows automated payment processing without transmission of a transaction account number linked to the purchaser account.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for home banking systems

Abstract

A transaction card is described that includes a first print layer, a second print layer, an antenna inlay layer, and a light-emitting element. At least one of the first print layer and the second print layer has a transparent portion through which light transmits. The antenna inlay layer has a loop antenna disposed thereon. The light-emitting element has a two-dimensional form factor and is positioned between the antenna inlay layer and one of the first print layer and the second print layer. The transaction card includes wireless power receiver circuitry that receives a wireless signal via the loop antenna and induces a voltage across terminals of the light-emitting element, causing the light-emitting element to illuminate and emit light through the transparent portion.

IPC Classes  ?

• G06K 19/077 - Constructional details, e.g. mounting of circuits in the carrier
• 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 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  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
• G06Q 50/10 - Services
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• H04W 4/80 - Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

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/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
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• 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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

Disclosed are various embodiments for predicting and customizing round-ups for various types of transaction. First, a computing device can access adjustment criteria for a user profile. The computing device can then generate an event listener configured to monitor events made in association with the user profile. When events are accessible by the event listener, the events are filtered or otherwise analyzed to identify a subset of the events that comply with the adjustment criteria. Individual ones of the events in the subset are adjusted by performing a round-up operation. The round-up operation can include adjusting a transaction amount by a predetermined amount and depositing the predetermined amount into the destination account.

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/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

A transaction card can be manufactured from rigid materials, such as glass, stone, or ceramics. The transaction card can have a first rigid layer having a first external surface and a first internal surface, with a pocket within the first external surface of the first rigid layer. The transaction card can have a second rigid layer having a second external surface and a second internal surface. A binding layer can be located between the first rigid layer and the second rigid layer can affix the first rigid layer to the second internal layer. An integrated circuit chip can be affixed within the pocket of the first rigid layer. A rim can extend from the first external surface of first rigid layer around a first edge of the first rigid layer and a second edge of the second rigid layer and onto the second external surface of the second rigid layer.

IPC Classes  ?

• G06K 19/077 - Constructional details, e.g. mounting of circuits in the carrier
• G06K 19/02 - Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the selection of materials, e.g. to avoid wear during transport through the machine
• B32B 3/08 - Layered products essentially comprising a layer with external or internal discontinuities or unevennesses, or a layer of non-planar form; Layered products essentially having particular features of form characterised by features of form at particular places, e.g. in edge regions characterised by added members at particular parts
• B32B 17/06 - Layered products essentially comprising sheet glass, or fibres of glass, slag or the like comprising glass as the main or only constituent of a layer, next to another layer of a specific substance
• B32B 7/12 - Interconnection of layers using interposed adhesives or interposed materials with bonding properties

Abstract

Disclosed are various embodiments for using custodial systems to maintain ownership of digital assets and facilitate transfers of digital assets between individuals. To facilitate a user taking possession of a digital asset, the custodial system could update an owner identifier for a digital asset in an asset ledger to include a public key of an asset custodian, the public key of the asset custodian indicating that the asset custodian is the owner of the digital asset. The custodial system could then provide a verifiable credential to an identity wallet, the verifiable credential being linked to the digital asset in the digital asset ledger. Subsequently, the custodial system could create an asset record that stores an owner identifier in association with an asset identifier for the digital asset, the owner identifier representing a user of the identity wallet.

IPC Classes  ?

• G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
• G06F 21/10 - Protecting distributed programs or content, e.g. vending or licensing of copyrighted material
• G06F 21/33 - User authentication using certificates
• G06F 21/44 - Program or device authentication
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

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/42 - Confirmation, e.g. check or permission by the legal debtor of payment
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
• G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
• G06F 16/955 - Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]

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  ?

• G06F 21/31 - User authentication
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
• H04L 9/08 - Key distribution
• G06V 30/14 - Image acquisition
• 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 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/082 - Layered products essentially comprising metal comprising metal as the main or only constituent of a layer, next to another layer of a specific substance of synthetic resin comprising acrylic resins
• B32B 15/18 - Layered products essentially comprising metal comprising iron or steel
• B32B 15/20 - Layered products essentially comprising metal comprising aluminium or copper

Abstract

Disclosed are various embodiments for a hosted point-of-sale service that provides the security features of card-present transactions for card-not-present transactions. The various embodiments of the present disclosure can be configured to receive a merchant identifier and a transaction amount for a transaction from a merchant terminal, as well as receive the merchant identifier and encrypted payment account data for the transaction. The encrypted payment account data can then be decrypted. An authorization request for the transaction is then generated based at least in part on the merchant identifier, the transaction amount, and the payment account data. The authorization request is then sent to a payment processor, which can route the authorization request to an authorizing entity via a payment network. An authorization response is received in response from the authorizing entity via the payment processor, and the contents are forwarded on to the merchant terminal.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• 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 architectures, schemes or protocols - Details thereof

Abstract

Disclosed are various embodiments for verifying a consumer's identity during card-not-present (CNP) transactions using biometric data (e.g., fingerprint, retina scan, iris scan, handprint, voice sample, face scan, etc.) of the consumer obtained using a biometric security device. A zero-knowledge proof algorithm is used to verify the identity of a user initiating a transaction without disclosing personal information (e.g., biometric data) of the user to the issuer, merchant, recipient and/or other party, thereby preserving the privacy of the user.

IPC Classes  ?

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

Abstract

Disclosed are various embodiments for providing a privacy-preserving decentralized payment instrument network that allows merchants and transaction account issuers to record transaction-related information in a distributed ledger. In particular, upon receiving authorization from a transaction account issuer to proceed with a transaction, a merchant can securely record transaction data (e.g., transaction confirmation identifier, transaction details, etc.) associated with the transaction in the distributed ledger. Furthermore, upon payment by the issuer to the merchant with regard to the transaction, the issuer can record payment confirmation data on the distributed ledger. The records stored in the distributed ledger can be used to resolve disputes between the parties without third-party intervention or sharing of privacy data.

IPC Classes  ?

• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• H04L 29/08 - Transmission control procedure, e.g. data link level control procedure
• H04L 9/08 - Key distribution

Abstract

Disclosed are various embodiments for using distributed ledgers to assist in securely developing applications. An application component comprising a component file can be received from a validation client. It can then be determined that the application component complies with a security policy. In response to a determination that the application component complies with the security policy, an endorsed application component record can be generated that comprises the component file or a network address at which the component file is obtainable and a signature for the component file generated with an asymmetric key-pair stored in the memory. The endorsed application component record can then be stored in the distributed ledger.

IPC Classes  ?

• H04L 9/08 - Key distribution
• H04L 29/06 - Communication control; Communication processing characterised by a protocol
• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules

Abstract

Disclosed are various embodiments for executing entity-specific cryptographic code in a cryptographic coprocessor. In one embodiment, encrypted code implementing a cryptographic algorithm is received from a service via a network. The cryptographic coprocessor decrypts the encrypted code. The cryptographic coprocessor executes the decrypted code to generate a cryptogram including information encrypted using the cryptographic algorithm. The cryptogram is sent to the service via the network.

IPC Classes  ?

• H04L 9/08 - Key distribution

Abstract

Disclosed are various embodiments for generating training data for machine-learning models. A plurality of original records are analyzed to identify a probability distribution function (PDF), wherein a sample space of the PDF comprises the plurality of original records. A plurality of new records are generated using the PDF. An augmented dataset that includes the plurality of new records is created. Then, a machine-learning model is trained using the augmented dataset.

IPC Classes  ?

• G06N 20/20 - Ensemble learning
• G06N 7/00 - Computing arrangements based on specific mathematical models

Abstract

Disclosed are various embodiments for decentralizing the authentication or verification of data. An identity key can be generated for a data item. A request can then be sent to an authentication service for authentication of the data item, the request comprising the identity key and the data item. A verified claim for the data item can then be received in response. Subsequently, an identity document is generated, the identity document comprising the identity key for the data item and the verified claim. Finally, the identity document can be stored in a distributed ledger.

IPC Classes  ?

• G06F 21/33 - User authentication using certificates
• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
• G06F 21/55 - Detecting local intrusion or implementing counter-measures
• H04L 29/06 - Communication control; Communication processing characterised by a protocol
• H04L 9/08 - Key distribution
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

Abstract

A system for automated supplier invoice reconciliation is disclosed. The system may receive an order confirmation associated with a purchase order (PO) from a supplier system. The system may receive the PO associated with the order confirmation from a buyer system. The system may receive a first invoice associated with the PO and the order confirmation from the supplier system. The system may reconcile between the PO, the first invoice, and the order confirmation to generate a second invoice. The system may pass the second invoice to the buyer system.

IPC Classes  ?

• G06Q 30/06 - Buying, selling or leasing transactions
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

The disclosure includes a transaction card comprising a card body having a slot. A first portion of the slot is formed at a first angle, and a second portion of the slot is formed at a second angle. A card body may be fabricated by positioning the card body at a first angle with respect to a cutter, creating a first portion of a slot at the first angle by at least one of translating the card body across the cutter or translating the cutter across the card body, stopping the translating of the card body, rotating the card body to a second angle to create a second portion of the slot; and creating a third portion of the slot at the third angle by at least one of translating the card body across the cutter or translating the cutter across the card body.

IPC Classes  ?

• G06K 19/077 - Constructional details, e.g. mounting of circuits in the carrier
• G06K 19/04 - Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the shape

Abstract

Systems and methods for processing payment transfers are disclosed. The system may allow senders to remit payments to receivers. The system may receive a payment request. The system may execute a payment risk analysis on the payment request to determine a risk assessment. Based on the risk assessment, the system may invoke a payment processor to complete the payment request. The payment processor may transmit a debit pull to a sender bank. In response to receiving the debit pull the sender bank may debit the payment amount from a sender account from the sender data. The payment processor may transmit a credit push to a receiver bank. In response to receiving the credit push the receiver bank may credit the payment amount to a receiver account from the receiver data.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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
• G06Q 20/10 - Payment 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]
• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance

Abstract

Systems and methods for optimizing user task schedules in a customer relationship management (CRM) platform is disclosed. The system may optimally input tasks into time slots in a user schedule to generate the optimized user task schedule. The system may generate a plurality of user task schedules and calculate a total task win probability for each of the user task schedules. The system may comprise the total task win probabilities and select the user task schedule having the greatest total task win probability. The system may also perform a genetic processing analysis of the user task schedules to further optimize task placement in the user task schedule.

IPC Classes  ?

• G06Q 10/10 - Office automation; Time management
• G06Q 10/06 - Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Abstract

A blockchain-based loyalty point distribution system may be configured to provide decentralized loyalty IDs. The decentralized loyalty IDs may allow distribution of loyalty rewards in response to transaction-based events and non-transaction-based events, including behavioral interactions. The system may include a loyalty partner system that receives a rewards event from a customer. The loyalty partner system may determine a loyalty ID associated with the customer, and write the rewards event to the blockchain. A loyalty provider system may receive notification of the rewards event write and distribute the loyalty reward to the customer. The loyalty provider may instruct the loyalty partner to remit payment for the loyalty reward, and may update customer and loyalty partner balances on the blockchain.

IPC Classes  ?

• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• 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 architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

Abstract

Systems and methods for automated non-billing cycle remittances are disclosed. The system may enable users to remit payment for outstanding transaction account balances without needing an issuer system to generate billing cycle statements. The system may retrieve user enrollment data comprising user data and a remittance trigger. The system may determine a remittance event based on the remittance trigger. The system may process a non-billing cycle remittance based on the user enrollment data. The system may calculate a non-billing cycle reward based on the non-billing cycle remittance.

IPC Classes  ?

• H04M 15/00 - Arrangements for metering, time-control or time-indication

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  ?

• G06F 3/033 - Pointing devices displaced or positioned by the user; Accessories therefor

Abstract

A hybrid identity service system is disclosed. The system may receive a transaction request. The system may generate a first passcode and a second passcode. The system may decrypt a first encrypted private key with the fist passcode to recover a private key. The system may sign the transaction request with the private key and may encrypt the private key with the second passcode to generate a second encrypted private key.

IPC Classes  ?

• H04L 9/08 - Key distribution
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A zero-knowledge proof purchase system and process using blockchain is disclosed. The system may comprise a customer device, a merchant system, an issuer system, and a blockchain network having a zero-knowledge proof (ZKP) smart contract. The system may implement a zero-knowledge proof algorithm having a key generator function, a proof function, and a validate function. Each function may be configured to perform various tasks in the system to support and enable zero-knowledge proof purchases.

IPC Classes  ?

• H04L 9/08 - Key distribution
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
• H04L 9/06 - Arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
• H04L 9/30 - Public key, i.e. encryption algorithm being computationally infeasible to invert and users' encryption keys not requiring secrecy

Abstract

Systems and methods for the maintenance of merchant-stored transaction account data are disclosed. The system may include various merchant systems and issuer systems in communication via a blockchain network. The system provides a process for collaboration between various issuer systems and merchant systems to update and maintain merchant-stored transaction account data in response to changes, cancellations, updates, or the like in various stored transaction account.

IPC Classes  ?

• H04L 29/06 - Communication control; Communication processing characterised by a protocol
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

Abstract

Systems and methods for peer-to-peer secure document exchange are disclosed. The system may allow a document provider to securely transmit a certified document to a document verifier using decentralized storage. The verifier system may generate a session key pair and transmit the session public key to a trusted API provider. The trusted API provider may generate a session nonce. The verifier system may transmit the session nonce to the provider system. The provider system may use the session nonce to retrieve the session public key. The provider system may encrypt a certified document using the session public key and store the encrypted certified document in the decentralized storage. The verifier system may retrieve the encrypted certified document by polling the trusted API provider based on the session nonce. The verifier system may decrypt the encrypted certified document using the session private key.

IPC Classes  ?

• H04L 9/06 - Arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
• H04L 9/18 - Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

Abstract

Systems and methods for the automated building and configuration of integration services are disclosed. The system may store and maintain various integration pattern templates comprising preprogrammed integration services (e.g., web services, APIs, etc.) needing defined operation details to be functional. The system may receive a specification file and a service specific parameter, parse the specification file and the service specific parameter to determine an operation detail, and extract the operation detail from the specification file and the service specific parameter. The system may input the operation detail into the integration pattern template to generate a service configuration file. The service configuration file may be deployed in a service integration platform.

IPC Classes  ?

• G06F 9/44 - Arrangements for executing specific programs

Abstract

Systems and methods for secondary fraud detection during transaction verifications are disclosed. A payment system may transmit a fraud protection notification to a user in response to potential fraud being detected as part of a primary transaction fraud detection process. In response to the user interacting with the fraud protection notification to confirm that the transaction was not fraudulent, the system may capture user device data from the user's device. The system may perform a secondary fraud detection process on the captured user device data to determine whether the verification of the transaction has a risk of being fraudulent.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
• H04W 12/06 - Authentication

Abstract

A blockchain-based multi-merchant loyalty point partnership system may include a blockchain API host that receives a request to create a partnership smart contract for a multi-merchant loyalty point partnership. The request may specify various partnership parameters to include in the partnership smart contract. The blockchain API host may create the partnership smart contract and write the partnership smart contract to a blockchain. One or more qualified merchants may join the partnership smart contract to make the partnership active. In response to a customer completing a plurality of purchases that complete the partnership parameters of the partnership smart contract, the system may issue the customer a purchase reward which may include a loyalty point payout.

IPC Classes  ?

• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising
• H04L 9/06 - Arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system

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/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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 4/80 - Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Abstract

Disclosed are various embodiments for transfers using credit accounts. A request to send a specified amount of funds from a specified credit account to a recipient is received from a first client device. A transaction identifier for the request to send the specified amount of funds to the recipient is requested from the computing device. A first notification is sent to a second client device, wherein the first notification comprises the transaction identifier and the second client device is associated with the recipient. A second notification is received from the second client device that the recipient has accepted the specified amount of funds. A funds transfer is then initiated to the monetary account for the specified amount of funds.

IPC Classes  ?

• G06Q 20/04 - Payment circuits
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• G06Q 20/08 - Payment architectures
• G06Q 20/10 - Payment architectures specially adapted for home banking systems
• G06Q 20/22 - Payment schemes or models
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]

Abstract

A system for system for dynamic card identifier based transactions is disclosed. The system may receive a transaction authentication request. The system may generate a first dynamic card identifier (DCID) in response to the transaction authentication request. The system may authenticate a transaction based on the first DCID. The system may execute the transaction in response to the authenticating. In various embodiments, the system may generate a second DCID in response to executing the transaction.

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

Abstract

Systems and methods for voice-enabled transactions are disclosed. A merchant system may generate a transaction request comprising a transaction amount and a merchant identifier. The merchant system may invoke an audio signal generator to generate an audio transaction signal comprising the transaction request data. A voice assistant may play the audio transaction signal. The user initiating the transaction may use a mobile device to detect and ingest the audio transaction signal. In response to detecting and ingesting the audio transaction signal, the mobile device may interact with a payment network to authorize, process, and complete the transaction request. The payment network may transmit a transaction approval to the merchant system.

IPC Classes  ?

• G06F 17/30 - Information retrieval; Database structures therefor

Abstract

A system for generating product-merchant data links is disclosed. The system may receive a request to generate a product-merchant data linkage. The system may receive a raw data set comprising unlinked records and may sort the raw data set into spend data and non- spend data. The system may generate the product-merchant data linkage based on a matching logic and the spend data. The system may construct a linked data set wherein the unlinked records are linked on the basis of the product-merchant data linkage.

IPC Classes  ?

• G06Q 50/00 - Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism

Abstract

A transaction account based micro-payment system using blockchain is disclosed. The system may receive a micro-payment request including a payment address from a merchant system. The system may invoke an account holder account smart contract and a directory smart contract. The system may write a plurality of micro-payment transaction debits to a transaction account based micro-payment blockchain via a blockchain node. The system may generate a transaction clearance event based on the account holder account smart contract. The system may write a micro-payment transaction clearance credit to the transaction account based micropayment blockchain.

IPC Classes  ?

• G06Q 20/10 - Payment 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 architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 40/00 - Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

Systems and methods for peer-to-peer money transfers are disclosed. The system may allow senders to transmit money transfers to receivers. The system may receive a money transfer request from the sender comprising the designated receiver, a money transfer amount, and a sender transaction account. The system may deduct the money transfer amount from the sender transaction account. The system may generate a receiver transaction account associated with the designated receiver, wherein the receiver transaction account comprises the money transfer amount. The system may provide the receiver access to the receiver transaction account using different channels, including by providing a digital transaction instrument or a physical transaction instrument.

IPC Classes  ?

• G06Q 20/10 - Payment 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 architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 40/00 - Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

Systems and methods for transactions using remote EMV payment applications are disclosed. The system may enable EMV transactions to be completed using EMV payment applications stored in a remote server. The remote EMV payment application may directly communicate EMV transaction data to the issuer system to complete transactions. The system may receive a transaction request comprising a payment token and an EMV payment application uniform resource identifier ("URI"). The system may invoke from a payment application server a remote EMV payment application based on the EMV payment application URI, wherein in response to being invoked, the remote EMV payment application is configured to interact with a merchant system kernel to process the transaction request, and wherein in response to processing the transaction request the remote EMV payment application is configured to transmit a transaction authorization request comprising EMV transaction data directly to the issuer system.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A system and method is disclosed for automated remote transactions between a vehicle and a lodging system. The system may enable the vehicle to initiate an automated remote transaction to the lodging system to book an accommodation and complete a remote payment. The lodging system may transmit available accommodations to the vehicle. The vehicle may respond with a booking request comprising an accommodation selection and vehicle identifying data, and the lodging system may communicate the vehicle identifying data to a payment network to authorize the remote transaction. In response to authorizing the remote transaction, the lodging system may complete the booking request with the vehicle.

IPC Classes  ?

• G06Q 10/02 - Reservations, e.g. for tickets, services or events
• 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/42 - Confirmation, e.g. check or permission by the legal debtor of payment

Abstract

A system and method for automated remote payments between a vehicle and a refueling station is disclosed. The system may enable the vehicle to initiate an automated remote payment to the refueling station without needing the user to manually input transaction account information, or to manually prepay for the transaction. The refueling station may detect when the vehicle is in proximity, and the vehicle and the refueling station may open communications to transmit data. The vehicle may transmit vehicle identifying data to the refueling station, and the refueling station may communicate the vehicle identifying data to a payment network to authorize the transaction. In response to authorizing the transaction, the vehicle may proceed with refueling at the refueling station.

IPC Classes  ?

• G06Q 40/00 - Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

A system for instant qualification cross channel offer targeting is disclosed. The system may receive a plurality of personally identifiable information (PII) elements from at least one of a customer device or an affiliate system. The system may determine a credit authorization state in response to the PII element. The system may receive a first request to generate an offer from at least one of the customer device or the affiliate system. The system may generate the offer in response to an offer optimization model, the credit authorization state, and the first request to generate an offer. The system may hash the plurality of PII elements and determine a unique hash based on the plurality of PII elements. The system may associate the unique hash to the offer and store the offer as offer data.

IPC Classes  ?

• G06Q 30/00 - Commerce
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising
• G06Q 40/00 - Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

A system and method for the redemption of reward points for cryptocurrency is disclosed. The system may allow transaction account holders to redeem earned reward points for a selected cryptocurrency. The transaction account holders may establish a blockchain wallet to maintain and track the cryptocurrency. The system may interact with an exchange API of a cryptocurrency exchange platform to purchase the cryptocurrency for a blockchain wallet address associated with the blockchain wallet, or to initiate a transfer of pre-purchased cryptocurrency to the blockchain wallet. The system may provide additional authentication measures to ensure that the transaction is initiated by the transaction account holder and that the transaction account holder understands the potential risks of investing in cryptocurrencies.

IPC Classes  ?

• G06F 3/048 - Interaction techniques based on graphical user interfaces [GUI]
• G06F 16/20 - Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
• G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
• G06Q 20/12 - Payment architectures specially adapted for electronic shopping 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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 30/06 - Buying, selling or leasing transactions

Abstract

A reward points transfer system and process using blockchain is disclosed. Transaction account issuers may write reward transfer messages to the blockchain to initiate a transfer of reward points for a transaction account holders account to one or more rewards partners. Rewards partners may retrieve the reward transfer messages from the blockchain, and write a reward transfer response message to the blockchain to confirm receipt of the reward points transfer and to update the status of the transfer. The transaction account issuers and rewards partners may encrypt the messages and generate hashes based on the messages prior to writing to the blockchain, to ensure that the messages are not tampered with during the transfer process.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A data enrichment environment using blockchain is disclosed. A client may interact with the data enrichment environment to generate an enrichment smart contract and deploy the enrichment smart contract to the blockchain. The enrichment smart contract may comprise data indicating the enrichment inquiry. One or more solvers may interact with the data enrichment environment to submit proposed enrichment solutions based on the enrichment inquiry. One or more observers may interact with the data enrichment environment to review and vote on the proposed enrichment solutions. The data enrichment environment may evaluate the proposed enrichment solutions based on contract conditions.

IPC Classes  ?

• G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity

Abstract

A transaction system and process using a token smart contract is disclosed. The system may receive a transfer notification comprising a user public blockchain address, a merchant public blockchain address, and a transaction amount. The system may retrieve a transaction account identifier and a merchant identifier based on the user public blockchain address and the merchant public blockchain address. The system may adjust a transaction account balance associated with the user identifier based on the transaction amount. The system may credit a merchant account based on the transaction amount.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

Systems and methods for fraud management using a distributed database are disclosed. The system may receive a payment request and generate a payment request hash by cryptographically processing the payment request using a hashing algorithm. The system may invoke a fraud reporting smart contract by passing the payment request hash and a public blockchain address to the fraud reporting smart contract. The system may query a local blockchain database to locate a fraud report matching the payment request hash to determine whether the payment request has been previously reported as fraud. In response to the payment request hash not matching the fraud report, the fraud reporting smart contract is configured to write the payment request hash to the blockchain as a second fraud report.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A system for customer defined limited use authorization. The system may receive an identification credential from at least one of an issuer native app or an issuer web app and receive a customer data. The system may determine a valid customer identity in response to the receiving the identification credentials and the customer data The system may receive a request to generate a token from at least one of the issuer web app or the issuer native app, wherein the request comprises at least one of the identification credential or a parent transaction account, and wherein the request comprises at least one of a customer defined authorization control or a customer defined generation control.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A chat system implementing Al-based support chat profiles may receive and process one or more user chat inputs from a user terminal. The chat system may select a support chat profile based on the processed user chat input. The chat system may generate one or more AI chat responses based on the processed user chat input and the support chat profile. The chat system may determine a confidence level of each AI chat response. The chat system may generate a support response. In response to the confidence level of the AI chat response being greater than a predetermined level, the support response may be generated to comprise the AI chat response.

IPC Classes  ?

• G06F 17/00 - Digital computing or data processing equipment or methods, specially adapted for specific functions

Abstract

A multi-profile chat system may receive a chat request comprising a user identifier and chat data. The system may process the chat data to determine a chat profile request, a request topic, and/or a request sentiment. The system may retrieve a user profile and/or a user chat record based on the user identifier. The system may determine a chat profile based on the chat profile request, the request topic, the request sentiment, the user profile, and/or the user chat record. The system may generate a chat response based on the chat request and the chat profile.

IPC Classes  ?

• H04L 29/02 - Communication control; Communication processing
• H04L 29/06 - Communication control; Communication processing characterised by a protocol
• G06Q 10/10 - Office automation; Time management

Abstract

A user may interact with a first application. A dynamic user interface consistency system may create a user interface blueprint file which stores explicit and inferred user preferences. The user may open a second application. The second application may refer to the user interface blueprint file to generate a user interface according to the user preferences.

IPC Classes  ?

• G06F 15/00 - Digital computers in general; Data processing equipment in general
• G06N 5/04 - Inference or reasoning models
• G06N 99/00 - Subject matter not provided for in other groups of this subclass
• G06Q 30/00 - Commerce
• G06F 12/30 -

Abstract

Systems for issuing authentication challenges based on fraud initiation requests are provided. The system may calculate a fraud risk level based on a fraud initiating request comprising identity-based data. In response to the fraud risk level indicating a risk of fraud, the system may generate an authentication challenge based on an authentication challenge type and an authentication challenge delivery channel. The system may transmit the authentication challenge and receive back an authentication challenge response. The system may verify the authentication challenge response and generate an authentication outcome based on the verification.

IPC Classes  ?

• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
• G06Q 20/10 - Payment 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 architectures, schemes or protocols - Details thereof
• G06F 21/31 - User authentication
• G06F 21/40 - User authentication by quorum, i.e. whereby two or more security principals are required
• G06F 21/42 - User authentication using separate channels for security data
• G06F 21/45 - Structures or tools for the administration of authentication

Abstract

A consuming application may transmit a request for customer incentive data to an API proxy. The request may include a request for an existing data value and a derived data value, as well as security credentials indicating the user has permission to obtain the requested data. The API proxy may transmit the request to a customer incentive system, which may retrieve the existing data value and calculate the derived data value in real-time. The requested data may be returned to the consuming application via the API proxy.

IPC Classes  ?

• G06F 9/54 - Interprogram communication
• G06F 8/20 - Software design
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

A consumer may enter a physical merchant location. A reverse bidding system determines a confidence score that the consumer will make a non-fraudulent purchase of a product. The reverse bidding system performs an online price comparison. The reverse bidding system may transmit an offer to the consumer to purchase the product at the physical merchant location for a discounted price.

IPC Classes  ?

• G06Q 99/00 - Subject matter not provided for in other groups of this subclass

Abstract

A merchant registers a geolocation for a virtual point of sale. A consumer points a consumer device at the geolocation, and an icon representing the virtual point of sale is displayed on the consumer device in augmented reality. The consumer selects the icon to initiate a transaction with a digital wallet on the consumer device.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

Systems for decoupling and updating pinned certificates on a user device are disclosed. A mobile application having a hardcoded pinned certificate may be installed on a user device. The pinned certificate may be decoupled from the mobile application and stored on the user device. In response to the mobile application attempting to establish a secure connection with a server, the system may check whether the decoupled pinned certificate is current by querying a certificate repository. In response to determining that the pinned certificate is out of date, the system may transmit the current certificate to the user device to update the decoupled pinned certificate.

IPC Classes  ?

• H04L 9/28 - Arrangements for secret or secure communications; Network security protocols using particular encryption algorithm
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
• H04W 12/08 - Access security

Abstract

A single sign-on system using blockchain is disclosed. The single sign-on system may interconnect various organization systems over a peer-to-peer network, with each organization system having a blockchain node and an application programming interface (API). The blockchain node invokes and uses a smart contract to write registration credentials to the blockchain during a registration process. During a login process, the blockchain node invokes the smart contract to determine whether login credentials match stored login credentials in the blockchain. In response to matching login credentials, the API may generate a single sign-on token that can be used by a user device to access one or more organization systems connected over the network.

IPC Classes  ?

• H04L 9/06 - Arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
• H04W 12/06 - Authentication

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/00 - Payment architectures, schemes or protocols

Abstract

The method includes receiving a transaction inquiry about a transaction from a consumer system; identifying a transaction identifier associated with the transaction; transmitting the transaction identifier to a merchant system; requesting transaction information associated with the transaction from the merchant system; receiving the transaction information from the merchant system; and/or presenting item details associated with the transaction information to the consumer in response to the receiving the transaction information.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

The method includes receiving a data file comprising a record; identifying a characteristic of the record; appending a characteristic marker to the record reflecting the characteristic; receiving a data request from a user; identifying a clearance identifier associated with the user, wherein the clearance identifier indicates whether the user has clearance to access the record based on the characteristic of the record; retrieving the record in response to the receiving the data request; comparing the characteristic marker of the record with the clearance identifier; and/or determining whether the user has clearance to access the record.

IPC Classes  ?

• G06F 19/00 - Digital computing or data processing equipment or methods, specially adapted for specific applications (specially adapted for specific functions G06F 17/00;data processing systems or methods specially adapted for administrative, commercial, financial, managerial, supervisory or forecasting purposes G06Q;healthcare informatics G16H)

Abstract

Systems, methods, and articles of manufacture for secured account provisioning and payments using near-field communication (NFC) enabled devices are provided. The system may receive an encrypted account provisioning request comprising a provisioning account and a device fingerprint; decrypt the encrypted account provisioning request with a server root key; retrieve a limited use payment credential (LUPC) based on the provisioning account; generate an ENC key, a MAC key, and a DEK key based on the device fingerprint and the server root key; and encrypt the LUPC using the ENC key, the MAC key, and the DEK key to generate an encrypted account payload.

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/38 - Payment architectures, schemes or protocols - Details thereof
• H04W 12/04 - Key management, e.g. using generic bootstrapping architecture [GBA]

Abstract

A blockchain-based loyalty point system may include a blockchain API host that receives a request to transfer an amount of loyalty points from a first customer account to a second customer account. The system may validate the request by performing a cryptographic operation on the request using a public key associated with the first customer account. The system may also propagate a proposal to consensus participants for writing to a blockchain, wherein the proposal comprises the first customer account, the second customer account, and the amount of loyalty points. The system may also receive an exchange request from a loyalty wallet associated with the second customer account, validate the exchange request by performing the cryptographic operation on the exchange request using a public key, and propagate an exchange proposal to the consensus participants for writing to the blockchain.

IPC Classes  ?

• G06F 9/54 - Interprogram communication
• G06F 17/30 - Information retrieval; Database structures therefor
• G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
• 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 architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

A consumer may view a transaction account statement in a GUI. The transaction account issuer may utilize batch processed data and real time data to determine an eligibility for fixed fee payment plans. The consumer may be presented with the option to place a single transaction into a fixed fee payment plan by selecting the transaction. The fixed fee payment plan may comprise a fixed monthly cost. The monthly cost may be calculated to be equal to or less than the amount the consumer would pay if the transaction were subject to the transaction account APR. The transaction account may have a minimum amount due for the fixed fee payment plan and a minimum amount due for the revolving APR balance each month.

IPC Classes  ?

• G06F 3/048 - Interaction techniques based on graphical user interfaces [GUI]
• G06F 17/30 - Information retrieval; Database structures therefor
• G06Q 20/04 - Payment circuits
• G06Q 20/10 - Payment architectures specially adapted for home banking systems
• G06Q 20/22 - Payment schemes or models

Abstract

The systems may include receiving a device identifier to create a received device identifier, the received device identifier being associated with a personal POS terminal on a device associated with a consumer; matching a stored device identifier with the received device identifier; activating the personal POS terminal on the device associated with the stored device identifier; and/or receiving a payment token associated with a transaction account associated with the consumer for a transaction.

IPC Classes  ?

• G06Q 20/20 - Point-of-sale [POS] network systems
• H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
• H04W 12/00 - Security arrangements; Authentication; Protecting privacy or anonymity

Abstract

An authentication system may receive an authentication MAC, an integrity MAC, and data transmitted from a payment application and a payment terminal. A local integrity MAC may be generated using the data as an input to a first cryptographic operation. The system may compare the local integrity MAC to the received integrity MAC to authenticate the received integrity MAC. A local authentication MAC may be generated using a second cryptographic operation and compare the local authentication MAC to the received authentication MAC. The system may authenticate the payment application in response to a successful authentication of at least one of the received authentication MAC or the received integrity MAC.

IPC Classes  ?

• H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
• 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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

The system protects an account through the use of tokens, thereby eliminating the need to expose the primary account identifier during a transaction. If a primary account identifier is compromised, any use of the primary account identifier to facilitate a fraudulent purchase or settlement transaction may be blocked by the system. The system is configured to receive a payment authorization request including a payment account first identifier. The payment account first identifier serves as a search condition for a query, which is executed against a database to retrieve payment account information, if the payment account information exists. The system sends a decline response in response to the payment account first identifier and a primary account identifier from the payment account information being the same, indicating that a primary account is being used.

IPC Classes  ?

• G06Q 20/04 - Payment circuits
• G06Q 20/10 - Payment architectures specially adapted for home banking systems
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

A system may detect an outstanding account of a borrower having an outstanding amount. The system may also display a loan-request interface associated with the outstanding account with the loan-request interface activated in response to the outstanding amount being within the dynamically calculated loan capacity. The system may receive an input via the loan-request interface to request a loan based on the outstanding amount. A request for the loan may be transmitted in response to the input.

IPC Classes  ?

• G06Q 20/10 - Payment architectures specially adapted for home banking systems
• G06Q 20/24 - Credit schemes, i.e. "pay after"
• G06Q 40/02 - Banking, e.g. interest calculation or account maintenance

Abstract

Systems and methods of improving the operation of a test data provisioning network and test data provisioning network devices is disclosed. A data hub layer comprising an interstitial logic boundary at a periphery of a consumption environment and configured to interact with a production environment whereby test data may be provisioned without direct access by a user to the production environment. In this manner, the efficiency and resiliency of the production environment may be enhanced and the test data may be improved, so that the network more properly functions according to approved parameters.

IPC Classes  ?

• G06F 11/36 - Preventing errors by testing or debugging of software

Abstract

A transaction account provider may obtain transaction information from consumer transactions and information from a consumer browsing a transaction account provider website, collectively first-party data. A web server may obtain second-party data from a consumer's use of a merchant website. Additional third-party data may be purchased from a third-party data source. An ad server may use the first-party data, the second-party data, and the third-party data to select a relevant personalized banner ad to be displayed to the consumer.

IPC Classes  ?

• G06F 17/30 - Information retrieval; Database structures therefor
• G06Q 30/00 - Commerce
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

A system receives a source and a metadata layer that describes the source. The source may comprise source records with fields containing source data, and the metadata layer may include metadata comprising at least one of a field data type, a field data length, a field description, or a record length. The processor may further validate the metadata layer against the source and write results to a log. The processor may further be configured for transforming the source records into transformed records for a load ready file. The processor may further balance a number of records in the source against a number of transformed records in the load ready file to generate a transformation failure rate.

IPC Classes  ?

• G06K 9/00 - Methods or arrangements for reading or recognising printed or written characters or for recognising patterns, e.g. fingerprints

Abstract

A system may generate a seed one-time password (OTP). The system may also perform steps including transmitting the seed OTP to a user device, receiving a response OTP from the user device, and calculating an expected response OTP by applying a function to the seed OTP. The system may then compare the response OTP to the expected response OTP and send a result in response to comparing the response OTP to the expected response OTP.

IPC Classes  ?

• H04L 29/06 - Communication control; Communication processing characterised by a protocol

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 30/00 - Commerce

Abstract

A system may receive a transaction request from a user device, and request an in-app cryptogram from a network software development kit (SDK) on the user device. The in-app cryptogram may include an unpredictable number, an application transaction counter (ATC), and a card verification result (CVR), and the ATC may be extracted from a limited use payment credential (LUPC). The system may transmit a token, a token expiry, and a token data block for an assessment by a payment network, with the token data block including the token, the token expiry, the ATC, and/or the in-app cryptogram. The system may further receive a request from the payment network to update the LUPC on the user device, and attest that the user device is secure in response to the request from the payment network to refresh the LUPC on the user device.

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/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• G06Q 20/38 - Payment architectures, schemes or protocols - Details thereof
• G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

A system may be configured to perform operations and/or steps comprising querying, by an issuer server, a network server for an alias associated with a transaction account. The issuer server may receive the alias from the network server. The issuer server may also send the alias to an issuer application. The operations may also comprise validating, by the issuer server, an account validation input entered into the issuer application. The issuer server may send an issuer signature criteria that indicate whether the account validation input is valid. The issuer application may add an alias associated with the account to a digital wallet.

IPC Classes  ?

• G06K 17/00 - Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups , e.g. automatic card files incorporating conveying and reading operations
• G06K 19/00 - Record carriers for use with machines and with at least a part designed to carry digital markings
• G06Q 20/30 - Payment architectures, schemes or protocols characterised by the use of specific devices
• G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
• 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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists

Abstract

A transaction account provider may obtain travel information from a customer transaction. The travel information may include the date and destination of travel. An email service provider may transmit an email to the customer with an offer related to the date and destination of travel. In response to the customer opening the email, the email may be updated with current information regarding the offer.

IPC Classes  ?

• G06F 15/16 - Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• G06F 17/30 - Information retrieval; Database structures therefor
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

During token and PAN provisioning, instead of just having one token per one PAN for a single use case (PAN), between 1 and N tokens per a single PAN are provisioned. During provisioning a decision engine will supply additional details that are applied to each token. This additional information is stored in a token virtual vault that houses the mapping between PAN and token. Then, during a transaction, the decision engine chooses which token to give to the merchant to process business as usual. When the token comes into the network, additional information associated with that individual token may be identified. This information may be conveyed to a transaction account Issuer in substantially real time on and/or appended to the transactional message.

IPC Classes  ?

• G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes

Abstract

The system may receive an individual transaction record of a purchase at a merchant location. The individual transaction record may be collected at a point of sale. The individual transaction record may also include at least one of a first purchase time, a first purchase location, a first purchase amount, a first merchant category, or a first purchase item. The system may further predict a future purchase based on the individual transaction record and transmit an offer based on the future purchase.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

A connectivity contextual services ecosystem management system may comprise a connectivity contextual services connectivity system, one or more user devices, and one or more merchant devices. The connectivity contextual services connectivity system may deliver different connectivity contextual services to a user device and/or a merchant device in response to a context environment, in order to provide a user with a customized experience, such as allowing that user to enter into conversations with merchants, view inventory of merchants, and search for merchants with relevant products without entering a physical store.

IPC Classes  ?

• G06F 17/30 - Information retrieval; Database structures therefor

Abstract

A BLUETOOTH low energy mobile payments system may comprise a BLE beacon that is deployed at a merchant location. The BLE beacon may be associated with a specific merchant terminal. The BLE beacon may be configured to broadcast a unique beacon ID that is detectable by a user device. The user device may be configured to communicate the beacon ID to a payment system. In response to receiving the beacon ID, the user device may initiate a payment between a user and a merchant, via a user device and a merchant terminal.

IPC Classes  ?

• G06K 9/20 - Image acquisition

Abstract

The system integrates transaction account issuers, merchants, and consumers. A transaction account issuer may provide one or more APIs to merchants. The transaction account issuer may provide a sandbox environment for merchants to test applications with the APIs. The transaction account issuer may provide documentation to assist the merchants in integrating with the transaction account issuer. The transaction account issuer may notify the merchants of any changes to the documentation.

IPC Classes  ?

• G06F 11/36 - Preventing errors by testing or debugging of software

Abstract

In various embodiments, the systems, methods and computer-readable mediums (collectively "system") discussed herein may be configured to enable a single mobile application to receive dynamically customized content. The criteria and/or preferences that influence the dynamically customized content may be defined by a user and/or may be automatically detected by a user device. The criteria and/or preferences may be associated with the mobile application and/or a mobile device operating the mobile application. The criteria and/or preferences may be provided as part of a request for content to a content distribution system.

IPC Classes  ?

• H04M 3/00 - Automatic or semi-automatic exchanges
• H04M 3/42 - Systems providing special services or facilities to subscribers
• G06F 15/16 - Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

The system comprises approving a credit application during a single http session, transmitting an encoded secure token to a web-client participating in the http session, receiving from the mobile communications device the secure token, and transmitting the transaction account data to the mobile communications device, in response to the receiving the secure token. The system may further comprise the mobile communications device decoding the secure token.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A system, method and computer program product for granting access and/or an authorization are disclosed. For instance, a computer-implemented method may include receiving a first sequence of plurality of biometric data elements. The sequence of plurality of biometric data elements may comprise a biometric passphrase. The method may include registering the biometric passphrase to a known user and/or a transaction account. The method may include receiving a transaction request comprising a second sequence of plurality of biometric data elements. The method may include comparing the second sequence of plurality of biometric data elements to the biometric passphrase to resulting in a confidence factor of the comparison. The comparison may include comparing the sequencing of the second sequence of plurality of biometric data elements and the characteristics of each biometric data element of the second sequence of plurality of biometric data elements to the biometric passphrase.

IPC Classes  ?

• G06F 7/04 - Identity comparison, i.e. for like or unlike values
• G06F 21/32 - User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
• G06K 9/62 - Methods or arrangements for recognition using electronic means

Abstract

The present disclosure includes a method comprising encrypting sensitive data, generating a token comprising a data identifier, tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault. Tokenizing may comprise mapping the encrypted sensitive data to the token. The method may further comprise storing the token to a cloud application, wherein the cloud application comprises a software application that functions within a cloud computing environment.

IPC Classes  ?

• G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity

Abstract

A comprehensive platform for merchandising intellectual property (IP), conducting IP transactions and searching IP related data is disclosed. A user may create a deal room for conducting an IP transaction. The deal room may include assets, documents, and other information relevant to the IP transaction. A duplication button may allow the user to create a new deal room with information from the original deal room. The user may be prompted to select which documents and information should be transferred to the new deal room.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

A system and method are disclosed herein leveraging financial networks standards with mobile device data and SIM card chip knowledge to authenticate a device. For instance, a party to a transaction may utilize these elements of information, not traditionally associated with wireless transactions, to achieve a lower probability of fraud and/or a higher confidence associated with the transaction.

IPC Classes  ?

• H04M 1/66 - Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling

Abstract

The present disclosure includes a system for expense management. The method may include authenticating a user to a user account, retrieving a unique id (GUID) associated with the user, receiving (from a user device associated with the user) a digital copy of a receipt, and associating the digital copy of the receipt with the GUID. The method may further comprise requesting a record of charge (ROC) associated with the GUID, receiving a record of charge (ROC) associated with a GUID, and/or matching, by the computer-based system, the image of the receipt to the ROC based upon the GUID and information acquired from the digital copy of the receipt.

IPC Classes  ?

• G06Q 40/00 - Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

A system, method and/or computer program product for enrolling in and/or issuing a transaction account with enhanced capabilities and improved functionality is disclosed herein. This new type of transaction account, a reserve transaction account, is disclosed herein. Similar to credit and/or charge transaction accounts, the reserve transaction account avails its users the ability to purchase now and pay for the purchase at a later date. This is in contrast to a debit transaction account where payment for the purchase is effective almost immediately. Similar to credit and/or charge transaction accounts, the reserve transaction account is associated with a line of credit. Similar to credit and/or charge transaction accounts for authorization and settlement, the reserve transaction account follows a dual messaging protocol for authorization of transactions.

IPC Classes  ?

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

Abstract

The systems and methods provide an offer to a user that may be accepted by the user through an action by the user. The action may be, for example, a broadcast through a social media channel. The parameters of the offer may define that the broadcast comprise an offer identifier and may require that a user take subsequent action to fulfill the offer. The systems and methods may also be configured to monitor one or more broadcast channels, identify the source of a broadcast, identify transaction accounts associated with the source, evaluate transaction data associated with the transaction account, and provide benefits to the source and/or the transaction account.

IPC Classes  ?

• G06Q 30/02 - Marketing; Price estimation or determination; Fundraising

Abstract

A comprehensive platform for merchandising intellectual property (IP), conducting IP transactions and searching IP related data is disclosed. A standardized data collection method enables IP assets to be characterized, rated and valuated in a consistent manner. Project management, workflow and data security functionality enable consistent, efficient and secure interactions between the IP Marketplace participants throughout the IP transaction process. Business rules, workflows, valuation models and rating methods may be user defined or based upon marketplace, industry or technology standards. Data associations are tags are established to relate IP content to vertical silos of data, such as an industry silo, A search engine enables customized search of a the vertical silos.

IPC Classes  ?

• G06Q 50/10 - Services
• G06Q 10/00 - Administration; Management

Abstract

The present disclosure includes a system, method, and article of manufacture for targeting ad impressions. A list of customer records may be transmitted to a service provider system that identifies a matched customer and installs a cookie on a web client associated with the matched customer. The system may further receive a campaign request from a merchant and transmit the campaign request to the service provider system which may add a flag to the cookie based on the campaign request as well as instruct a media buyer system to bid on an ad impression for the matched customer based on the flag. The system may further receive an expenditure associated with the matched customer who received the ad impression and compare the expenditure to an expenditure associated with a customer who did not receive targeted ad impression but fits parameters associated with the campaign request.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

A comprehensive platform for merchandising intellectual property (IP) and conducting IP transactions is disclosed. A standardized data collection method enables IP assets to be characterized, rated and valuated in a consistent manner. Project management, workflow and data security functionality enable consistent, efficient and secure interactions between the IP Marketplace participants throughout the IP transaction process. Business rules, workflows, valuation models and rating methods may be user defined or based upon marketplace, industry or technology standards.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

A comprehensive platform for merchandising intellectual property (IP) and conducting IP transactions is disclosed. A standardized data collection method enables IP assets to be characterized, rated and valuated in a consistent manner. Project management, workflow and data security functionality enable consistent, efficient and secure interactions between the IP Marketplace participants throughout the IP transaction process. Business rules, workflows, valuation models and rating methods may be user defined or based upon marketplace, industry or technology standards.

IPC Classes  ?

• G06F 17/30 - Information retrieval; Database structures therefor

Abstract

A product level discount is managed during a transaction by receiving a transaction identifier associated with a transaction, where the transaction identifier comprises a transaction value, a customer account identifier, a merchant identifier, and a product identifier. A product identifier is assessed to determine whether the transaction qualifies for a rebate credit in accordance with a predetermined offer. A rebate credit value is based on the transaction information and the predetermined offer, and qualification may be determined based on at least one of the customer account identifier and the merchant identifier. The product identifier could be a SKU code, which may be the basis for qualifying for the rebate credit. A merchant associated with the merchant identifier, which is part of the transaction, does not need to be informed of the application of the rebate credit to the customer account, which occurs after completion of the transaction.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

A system, method, and article of manufacture for generating a digital pass is disclosed, The method may comprise retrieving a plurality of identity attributes, and grouping a subset of identity attributes in the plurality of identity attributes to generate at least one digital pass. The method may further comprise grouping a subset of static identity attributes and a subset of dynamic identity attributes to generate a digital pass.

IPC Classes  ?

• G06Q 20/00 - Payment architectures, schemes or protocols

Abstract

A system for providing state awareness across communication channels and statefully transitioning a user between a source channel and a destination channel is disclosed. The method may comprise storing a unique identifier associated with the user and data associated with the user, retrieving the data associated with the user based upon the user identifier and in response to the user entering the destination channel that is different from the source channel, and populating the data associated with the user in the destination channel. The destination channel may comprise a display of a customer service representative, and the populating may occur automatically. Furthermore, the method may comprise placing a call to a telephone number associated with the user in response to at least one of: the user answering a requisite number of questions in the source channel and the user requesting a transition to a voice destination channel.

IPC Classes  ?

• H04M 3/523 - Centralised call answering arrangements requiring operator intervention with call distribution or queuing
• G06F 15/16 - Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• H04L 12/28 - Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Abstract

A regression testing system comprises an automatic test tool configured to capture a first web screen shot and a second web screen shot of a webpage. where the webpage has undergone an update or edit. The regression testing system also comprises a visual comparator configured to identify similar areas in the first web screen shot and the second web screen shot. The visual comparator receives, and compares characteristics of, the web screen shots. Furthermore, the regression testing system generates a report, with marked different characteristics between the first and second web screen shots. The regression testing system identifies similar areas in the first and second web screen shots shot even if the similar areas are at different locations within the web screen shots. The comparison performed by the visual comparator includes performing a pixel comparison combined with a marking algorithm to group differences in smaller, related but separate areas.

IPC Classes  ?

• G06F 17/00 - Digital computing or data processing equipment or methods, specially adapted for specific functions

Abstract

A system and method provide rewards or loyalty incentives to transaction account customers. The system includes a computing platform comprising application programming interfaces that enable users to define marketing programs. The system thus enables an efficient, automated and extensible platform for creating, managing and executing rewards and other marketing related programs.

IPC Classes  ?

• G06Q 30/00 - Commerce

Abstract

Methods, systems, and computer program products are provided for mobile customer support. A customer service request is received at a mobile device from a user associated with the mobile device to access a customer service feature of an application associated with the mobile device. In response to the request, a user context is determined by at least one of saving a state of the application, storing data associated with the application or accessing user activity associated with the application. A communication request comprising the user context is sent to a customer service center ("CSC") associated with the customer service feature. Communication between the CSC and the user is enabled, wherein the CSC accesses the user context and uses the user context during the communication.

IPC Classes  ?

• G06Q 10/00 - Administration; Management

Abstract

A comprehensive platform for merchandising intellectual property (IP) and conducting IP transactions is disclosed. A standardized data collection method enables IP assets to be characterized, rated and valuated in a consistent manner. Project management, workflow and data security functionality enable consistent, efficient and secure interactions between the IP Marketplace participants throughout the IP transaction process. Business rules, workflows, valuation models and rating methods may be user defined or based upon marketplace, industry or technology standards.

IPC Classes  ?

• G06Q 10/00 - Administration; Management