Methods and server systems for improving accuracy of authorization optimizer are described herein. Method performed by server system includes receiving a Non- Sufficient Funds (NSF) error message from an acquirer server. Method includes accessing historical transaction data from a transaction database. The historical transaction data includes transaction related information associated with a plurality of users. Method includes generating a plurality of transaction features associated with the user based on the historical transaction data. Method includes determining via an authorization optimizer model, an optimal time slot from a plurality of time slots for the user based on the plurality of transaction features associated with the user. The optimal time slot indicates an optimal time window for the acquirer server to transmit an upcoming recurring payment request to the payment account of the user. Method includes facilitating transmission of a notification message including the optimal time slot to the acquirer server.
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]
G06N 3/0442 - Recurrent networks, e.g. Hopfield networks characterised by memory or gating, e.g. long short-term memory [LSTM] or gated recurrent units [GRU]
2.
SYSTEMS AND METHODS FOR USE IN REDEMPTION OF TOKENS
Systems and methods are provided for use in redeeming tokens. One example computer-implemented method includes receiving, by a processing network, from a first institution, an authorization request for redemption of a token by a user and checking a data structure escrow address associated with the redemption of the token. The method also includes, in response to the data structure address being indicative of the token, authorizing the redemption, whereby the institution transfers value associated with the token to the user.
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
A method for facilitating permission-based cryptographic transactions across service providers includes: receiving an onboarding request including permission data and an identification value from a first computing system, the identification value being associated with a first blockchain wallet for a blockchain associated with a blockchain network; generating a permission token based on the permission data and an alias, the permission token including verified identity data points; transmitting the generated alias to the first computing system in response to the onboarding request; receiving a token request from a second computing system, the token request including the alias; and transmitting the generated permission token identification value to the second computing system in response to the token request.
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
4.
SYSTEM AND METHOD FOR PROVIDING PUSH PAYMENT TRANSACTION PROCESSING IN A CARD-PRESENT ENVIRONMENT
Systems and methods for providing push payment transaction processing in a card-present environment are provided. The described push payment transactions processing enables a user having any form factor visiting at a merchant location accepting payment cards to perform push payment transactions. Indeed, push payment transactions can be supported from physical point-of-sale ("POS") or originate from POS terminals. During the described push payment transaction processing, a merchant acquirer can receive, from a POS terminal, a push payment transaction request comprising at least a transaction type indicating a push payment transaction, transaction information, authorization data, and sender information. In response to receiving the push payment transaction request, the merchant acquirer can generate an application programming interface (API) request package comprising the push payment transaction request; and communicate the API request package to an intermediary platform connected to a payment network.
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/14 - Payment architectures specially adapted for billing systems
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/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/16 - Payments settled via telecommunication systems
5.
METHOD AND SYSTEM FOR PAYMENT PROCESSING USING DISTRIBUTED DIGITIZED SURROGATES
A method for pre-authorization of a payment transaction with tokenized credentials includes: receiving a first data set signed with a first digital signature and including an acquirer identification value and a second data set; verifying the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; extracting, from the first data set in response to verification of the first digital signature, the second data set including a merchant identification value and a third data set; extracting, from the second data set, the third data set including an issuer identification value and transaction data; identifying an issuing computing system based on the issuer identification value; and transmitting a fourth data set to the issuing computing system, the fourth data set including the first data set and a steward identification value.
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/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
A system is configured to retrieve a set of customer raw transaction data, wherein the transactions are devoid of any target transactions of interest. An impact neural network model is applied to the transaction data using a "notTargef ' variable. The "notTargef ' variable indicates that the target transaction of interest is not included in the transaction data. The model predicts a first result based on the "notTargef' variable. The model is applied to the transaction data using an "isTargef ' variable. The "isTargef ' variable indicates that the target transaction of interest is included in the set of customer raw transaction data. The model predicts a second result based on the "isTargef ' variable. The system determines a difference between the second and first results. The difference is a predicted incremental impact on cardholder behavior. The system presents the predicted incremental impact on cardholder behavior to an issuer associated with the transaction data.
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/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
G06F 17/18 - Complex mathematical operations for evaluating statistical data
G06F 21/72 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
7.
EFFICIENT USER CONTROL OF THEIR DATA STORED IN A CENTRALISED BIOMETRIC DATABASE
There is disclosed a computer implemented method (300) of managing user accounts at a biometric database, the biometric database comprising biometric data of a user. The method comprises the steps of: receiving (301), at the biometric database, a message from a user device to suspend a user's account, the message comprising a cryptographic parameter; suspending (303) the user's account, the step of suspending comprising: encrypting (305), at the biometric database, biometric data of the user associated with the user's account using the cryptographic parameter; storing (307), the encrypted biometric data; and discarding (309), at the biometric database, the cryptographic parameter; and transmitting (311), from the biometric database, a message to the user device indicating that the user's account has been suspended.
G06F 16/22 - Indexing; Data structures therefor; Storage structures
G06F 16/25 - Integrating or interfacing systems involving database management 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
G06F 21/32 - User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
A system is configured to retrieve historical raw transaction data, wherein each transaction is one of a target or non-target transaction. The target transactions are related to a target transaction event. A target transaction identifier is appended to each target transaction. The raw transaction data is stored to a first data table. A first neural network is trained using the first data table to generate a training data classification model. The training data classification model is applied to the first data table. A first similarity score distribution associated with the target transactions and a second similarity score distribution associated with the non-target transactions is determined. A plurality of non-target transactions whose combined similarity score distribution matches the target transactions is selected. The target transactions and the selected plurality of non-target transactions are stored to a second data table and a second neural network is trained using the second data table.
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/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
G06N 3/04 - Architecture, e.g. interconnection topology
A method for facilitating payments across multiple platforms and networks includes: establishing communication channels with each of a plurality of enterprise systems; establishing communication channels with each of a plurality of payment networks; receiving a payment request message via one of the enterprise systems using the associated channel, the payment request message including a payee identifier and payment amount; identifying a computing device based on the payee identifier; transmitting a notification message to the computing device including the payment amount; receiving a response message from the computing device including a network identifier; and processing payment of the payment amount to a payee using one of the payment networks selected based on the network identifier, wherein processing payment of the payment amount includes transmitting one or more data messages to the one of the payment networks using the established communication channel.
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/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/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
G06Q 30/06 - Buying, selling or leasing transactions
10.
SYSTEMS, METHODS, AND NON-TRANSITORY COMPUTER-READABLE MEDIA FOR BIOMETRICALLY CONFIRMING TRUSTED ENGAGEMENT
Systems, methods, and non-transitory computer-readable media for biometrically confirming a trusted engagement between two or more individuals that overcomes an identity challenge from a digital environment. The identity challenge including but not limited to: when two or more individuals met in the digital environment only to meet in person, when two or more parties to a contract want to ensure that the true parties sign an agreement, when one or more individuals wants to provide proof of past interactions, when an individual or an entity wants to minimize a risk of a party to a financial transaction is using stolen identity credentials, when an individual receives a friend request from an unknown individual, when an individual wants to ban interactions with an undesired personal contact, when an individual meets with an imposter during a person-to-person transaction, and when an individual meets a friend that has created a new digital persona.
G06F 21/40 - User authentication by quorum, i.e. whereby two or more security principals are required
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
11.
DATA COMMUNICATION AND CRYPTOGRAPHIC OPERATIONS FOR SECURE WIRELESS INTERACTIONS
There is provided a method of generating a secure result to support authorisation of a rapid wireless interaction between a first computing device and a second computing device, the method being implemented by a third computing device remote from the first and second computing devices. The method comprises: receiving, from the first computing device via a secure communications channel, a request to generate the secure result, the request comprising interaction data relating to the wireless interaction; retrieving, from a data store in secure communication with the third computing device, cryptographic material to be used to generate the secure result; generating, using the retrieved cryptographic material, the secure result by applying the cryptographic material to the interaction data; and transmitting, to the first computing device via the secure communications channel, the secure result, for processing and onward provision by the first computing device to the second computing device for subsequent authorisation of the wireless interaction. A computing device arranged to implement this method is also provided.
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
A method for carrying out a wireless transaction between a first computing device and a second computing device is described - the transaction is for authorisation through a transaction processing system. The first computing device establishes a secure network connection with a third computing device, and then initiates the wireless transaction with the second computing device. The first computing device provides information for performance of a security protocol for the transaction to the third computing device over the secure connection, wherein performance of the security protocol includes determination of a secure result. The first computing device receives a dummy secure result from the third computing device, and it completes the wireless transaction with the second computing device using the dummy secure result. In the meantime, a true secure result for the wireless transaction prepared by the third computing device and provided to the transaction processing system. In authorisation of the wireless transaction the dummy secure result can be used to reconcile the wireless transaction with the true secure result.
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/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/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
The disclosure herein describes receiving and routing a remote procedure call (RPC) message from an external source. A microservice platform receives an RPC message from a source via an RPC interface, wherein the RPC message includes a header structure and a payload structure. The RPC message is validated based on security data in the header structure and the identity of the source is authenticated based on identity data in the header structure. A service interface function is triggered based on routing data in the payload structure and a multi-layer route and one of a plurality of microservices are identified. Payload data of the payload structure is routed through each of the ordered plurality of layers of the multi-layer route to the identified microservice, wherein each of the ordered plurality of layers and the microservice are configured to perform an operation using the payload data.
Systems and methods are provided for managing disputes in biometric- enabled network interactions. One example computer-implemented method includes receiving, at a biometric identity switch (BIS), a dispute notification for a biometric- enabled network interaction involving an account of a user, and retrieving biometric data specific to the biometric-enabled network interaction. The method also includes determining, by the BIS) whether the biometric data is representative of the user and, in response to the biometric data not being representative of the user, requesting, from a biometric service provider, a biometric identifier for an additional user, based on the biometric data. The method then includes receiving, by the BIS, the biometric identifier from the biometric service provider, identifying an interaction history of the additional user, based on the biometric identifier, and determining whether to assign the biometric-enabled network interaction to the additional user, based on the interaction history of the additional user.
Broadly speaking, the present invention provides a technical solution by which virtual cards can be leveraged to become tokens generated by the payment platform and coupled with dynamic cryptography to enhance security, reliability, performances, user experience and reduce latency during the transactional flow. This technical solution advantageously ensures that transactions are simplified for implementation, while being efficient in terms of BIN and PAN usages, and having minimal latency, resulting in simpler integration and faster transactions. Additionally, the present invention requires relatively little change to the configuration of the computing devices that collectively function to enable the transaction to take place (e.g. payment network computing devices, merchant computing devices). Furthermore, the invention can improve the security around use of virtual cards as it enables a dynamic cryptogram to be used rather than a relatively insecure static cryptogram.
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/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
16.
A SYSTEM AND METHOD FOR SECURING INFORMATION IN A NETWORK
A payment management system and method of managing a payment network includes generating a payment token based on a bank account of a user (e.g., a buyer), receiving a dynamic code through a network for a transaction, and validating a request for payment of the transaction using an installment plan based on funds from the bank account. The validating the request for payment of the transaction is performed based on operations which include authenticating the payment token and verifying the dynamic code. In addition, the method includes generating a decision signal indicating a decision for the request when the request for payment is validated and transmitting the decision signal to a merchant system to authorize or decline completion of the transaction.
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
17.
IDENTIFICATION OF FRAUDULENT HEALTHCARE PROVIDERS THROUGH MULTIPRONGED AI MODELING
A system and computer-implemented method for identifying fraudulent healthcare providers receives raw claims data from one or more data sources. The raw claims data includes claims associated with a selected healthcare provider. Each of the claims includes one or more claim lines. A first model is executed on the raw claims data. The first model determines a first score for the healthcare provider. A second model is executed on the raw claims data. The second model determines a second score for the healthcare provider. In addition, a third model is executed on the raw claims data. The third model determines a third score for the healthcare provider. A final provider-level risk score is determined for the healthcare provider based on the first, second, and third scores.
G16H 40/20 - ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
G06Q 10/06 - Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
G16H 50/00 - ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
Techniques for training an entity resolution model are presented. The techniques include receiving a minimum viable data product (MVDP) scope, a product scope, and a data mining scope from a user. A data mining goal is determined based on the MVDP scope, product scope, and data mining scope. One or more proof of concept (PoC) models are defined based on the data mining goal, and one of the PoC models is selected for training. A trained deep learning model is generated by iteratively training the selected PoC model. The trained deep learning model is then tested and validated against a predefined achievable loss metric using a sample labelled dataset for testing.
Techniques for training a classification model to improve the classification of open banking transactions are presented. The techniques include receiving raw training data from a data source. The raw training data includes historical transaction data made up of a plurality of individual transactions. The raw training data is input into the classification model. The raw training data is processed by performing a data preparation operation on the raw training data. The data preparation operation includes removing numerical characters, repeating special characters, and accent words from the textual data of each transaction. Vocabulary training is then performed on the processed training data, including tokenizing the text of each transaction and converting the tokenized text into a transformer model specific format. The classification model is then trained using a transformer model, which uses the tokenized text. The trained classification model is then stored in a database.
Techniques for training an entity resolution model are presented. The techniques include inputting raw training data into the entity resolution model. The training data includes historical transaction data including a plurality of transactions. A label dictionary is generated by performing natural language processing (NLP) on the training data. The NLP includes scanning text of each transaction, extracting one or more entities from the text, and storing the label dictionary in a database. The label dictionary includes the extracted entities. Tagged data is generated from the training data using the label dictionary. Vocabulary training is performed on the training data, including tokenizing the text of each transaction and converting the tokenized text into a transformer model specific format. The entity resolution model is then trained using a transformer model, which uses the tokenized text and the tagged data. The trained entity resolution model is then stored in a database.
A swap check oracle receives a transfer request from a user or smart contract on a first blockchain indicating a first digital asset to be transferred. The swap check oracle verifies the authenticity of the user and/or digital asset and instructs the smart contract to transfer the first digital asset to a custodial blockchain address on the first blockchain. Another swap check oracle performs the same process for a second digital asset from a second user on a second blockchain. A central processing server is notified of the successful transfer of the digital assets to the custodial addresses on both blockchains, verifies the holding of the digital assets by the custodial addresses, and then initiates a release of the digital assets to the new parties on both of the blockchains.
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/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
A method for enabling real-time authorization of a transaction with pooled equity includes: receiving a transaction request message, the transaction request message including at least a public key of a cryptographic key pair and a transacting currency amount; verifying a balance of a cryptographic currency for a first blockchain wallet associated with the cryptographic key pair on a blockchain using at least the public key, where at least a portion of the balance is locked in a currency pool; generating a smart contract, the smart contract configured to initiate a first blockchain transaction on the blockchain for transfer of the transacting currency amount from a second blockchain wallet to a destination address, where the second blockchain wallet is different from the first blockchain wallet; and transmitting the generated smart contract to a node in a blockchain network associated with the blockchain for publishing to the blockchain.
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/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
A system for assessment of a risk score for a non-fungible token transacted on a blockchain wherein the system is configured to generate a provenance score based on the derived ownership history of the specific non-fungible token, generate a smart contract score based on the retrieved smart contract code for the specific non-fungible token, generate a permanence score based on the retrieved smart contract code for the specific non-fungible token, and generate a comprehensive risk score for the specific non-fungible token based on the generated provenance score, smart contract score, and permanence score for the specific non-fungible token.
Following a tokenized consumer-initiated transaction, it is typical for subsequent merchant-initiated transactions to be processed without a cryptogram, causing a real opportunity for fraudulently generated merchant-initiated transactions to be submitted and subsequently processed. The present disclosure provides a method that solves or alleviates this problem. The method comprises: receiving a first transaction request including a payment token, first payment information, a first cryptogram and a next transaction notification identifying a future second transaction; authenticating the first transaction request based at least in part on the first cryptogram; providing an authorization response approval message to authorize the first transaction request; and providing a next transaction cryptogram suitable for use in authenticating a second transaction request.
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
25.
ENROLMENT PROCESS FOR A BIOMETRIC CARD AND METHODS OF USE OF A BIOMETRIC CARD
A method of processing, at a network server, a transaction from a biometric payment card on a payment network, the method comprising: receiving current transaction data from the biometric payment card during a current transaction, the transaction data comprising: a transaction counter value associated with the current transaction; a biometric matching result; n-i biometric matching results corresponding to n-i previous transactions prior to the current transaction; retrieving historical transaction data, and biometric history data relating to n biometric matching results received when the last transaction was approved by the payment network; comparing received current transaction data with historical transaction data to identify potentially fraudulent payment card use.
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/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
A method of generating a content library includes receiving a generate command that indicates a design application file to generate a content library, identifying a set of primitives from the design application file, and generating a content library from the set of primitives. In some cases, the method further includes receiving an import command to import content from a file that is a same format type as the content library and in response to receiving the import command, extracting appropriate values from associated primitives in the file and importing the appropriate values to the design application file. In some cases, the method further includes receiving an export command to export content from the design application file to a different application file of a specified format type and providing the content library in the specified format type.
According to one implementation of the present disclosure, a method for bill presentment is disclosed. At a computing device associated with a consumer, the computing device having one or more processors, memory, and a display, the method includes: receiving, at a network integrator interface on a digital messaging system, authentication or transaction data from the consumer on the computing device; matching, by the network integrator interface, authentication or transaction data of the consumer with billing data of one or more biller systems associated with the consumer; and providing, by the network integrator interface, the billing data to the consumer.
A method for transaction settlement using guarantee tokens includes: receiving a transaction request from a first financial institution including a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party address, an asset network identification, and an asset identification; generating a guarantee token against the digital token; generating an asset request transaction including the guarantee token, the receiving party digital address, the sending party digital address, and the asset identification; transmitting the asset request transaction to the asset network; receiving an asset transaction from the asset network including the asset, the receiving party digital address, and the sending party digital address; generating an asset transfer transaction including the receiving party digital address, the sending party digital address, and the asset identification; and transmitting the asset transaction to the receiving party digital address.
Embodiments provide methods and systems for detecting common points of purchase (CPP) compromised merchants. The method performed by a server system includes accessing historical payment transaction data, associated with fraudulent payment transactions from a transaction database. The method includes defining a base graph based on the historical payment transaction data. During each iteration, the method includes generating a sub-graph based on the base graph and determining blame scores assigned to a set of merchants involved in the sub-graph based on prior fraud probabilities associated with the set of merchants calculated in a previous iteration. During each iteration, the method also includes calculating posterior fraud probabilities at current iteration associated with the set of merchants based on the blame scores and a CPP model. The method, includes determining CPP compromise scores associated with a plurality of merchants based on final posterior fraud probabilities of the plurality of merchants at final iteration.
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 10/06 - Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
G06Q 10/067 - Enterprise or organisation modelling
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
Systems and methods are provided for providing installment options to users for transactions by the users at merchants. One example computer-implemented method includes receiving a request for an installment payment, from a user, via a wallet software development kit (SDK) at a merchant, where the installment payment is for a transaction between the user and the merchant, and then determining eligibility of the merchant for the installment payment based on information in the request and responding to the request with eligible installment types. The method also includes receiving a second request, via an installment SDK at the merchant, for installment options consistent with a selected installment type, determining an installment option for the transaction, and responding to the second request with the installment option. The method then includes, in response to the installment option, creating an installment plan for the installment option and storing the installment plan in memory.
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
31.
SYSTEMS AND METHODS FOR MONITORING DECENTRALIZED DATA STORAGE
Systems and methods are provided for use in monitoring decentralized data structures including identity attributes, through tokenization of the attributes. One example computer-implemented method includes receiving a request associated with a digital identity including multiple attributes and, for each of the attributes in the request, generating a token specific to the attribute, searching for the generated token in a network graph having multiple stored tokens, and identifying one of the multiple stored tokens as a match to the generated token. The computer-implemented method then further includes, for each of the attributes in the request, retrieving additional ones of the multiple stored tokens linked to the identified one of the stored tokens, comparing the retrieved tokens to the generated token, and promoting the request for further action, in response to at least one of the retrieved tokens being inconsistent with the generated token.
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 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
32.
CROSS-NETWORK ASSESSMENT OF TRANSACTIONS FOR PROVIDER REPUTATION
A management system for cross-network assessment of transactions for provider reputation receives a provider string associated with a provider identification and that includes a provider score. The provider identification is extracted from the provider string. In view of the provider identification, a potential merchant identification code is determined from a set of known merchant identification codes. At least one transaction associated with the potential merchant identification code can be identified by analyzing transaction data stored in a structured data resource associated with the management system. In view of the provider score, a transaction score is assigned to each transaction associated with the potential merchant identification code. The transaction score is stored. Merchant statistics are determined by analyzing the at least one transaction. A report is generated in view of the merchant statistics and the transaction score. The report is provided for display via a graphical user interface.
G06Q 20/06 - Private payment circuits, e.g. involving electronic currency used only among participants of a common payment scheme
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/02 - Banking, e.g. interest calculation or account maintenance
33.
METHOD AND SYSTEM OF TRANSACTION DISPUTE RESOLUTION
A smart contract is received for a new blockchain transaction and added to a blockchain. The smart contract includes information on a merchant blockchain wallet, a reserve blockchain wallet for the merchant, a dispute blockchain wallet, and a time period. During the time period, when a dispute is lodged by the consumer, the smart contract causes a new transaction to be added to the blockchain that transfers an amount to cover the disputed transaction from the merchant's reserve wallet to the dispute wallet. The dispute is resolved and the dispute resolution added to the blockchain, which causes the smart contract to add another new transaction to the blockchain that either transfers the amount from the dispute wallet back to the merchant's wallet or from the dispute wallet back to the consumer's wallet.
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
A method for enabling refund of a non-fungible token (NET) includes: receiving a transaction message for a payment transaction; processing the payment transaction using the transaction message, where processing includes identification of a transaction identifier for the payment transaction; transmitting the transaction identifier to a first device; receiving a notification message including the transaction identifier and a token identifier, where the token identifier is associated with the NET; receiving a refund request message from a second device, where the refund request message includes the transaction identifier and/or the token identifier; processing a refund transaction for the payment transaction; and submitting the transaction identifier as input into a smart contract stored in a blockchain associated with the NET for reversal of ownership of the NET.
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
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]
A network management system includes: a memory configured to store instructions; and a parallel processor configured to execute the instructions to: (a) receive a request for a transaction; (b) determine a first authorization decision for the request: (c) determine a second authorization decision for the request; and (d) perform a first procedure when the first authorization decision is different from the second authorization decision. The request corresponds to use of electronic payment for the transaction and wherein the first authorization decision is generated in parallel with generation of the second authorization decision.
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/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
Various implementations described herein may relate to a system and method for providing transaction report data using a user device. In one implementation, a method may include receiving, at a token service provider (TSP), tokenization request data from a user device associated with a user, where the tokenization request data includes payment card data associated with the user. The method may also include generating a digital token based on the tokenization request data. Hie method may further include transmitting the digital token to the user device. The method may additionally include receiving 'transaction report data from the user device, where the transaction report data corresponds to a failed payment transaction performed using the digital token, the user device, and a merchant system. Hie method may also include generating failure data based on the transaction report data, where the failure data comprises alert data, failure report data, or combinations 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
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 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
Systems and methods are provided for use in implementing a common domain to provide recognition of users. One example computer-implemented method includes receiving a recognition token associated with a profile and setting, via a browser accessing a common domain, a cookie in the browser where the cookie includes a recognition token. The method also includes, in response to a request for a service, via a user, through the browser accessing an entity domain associated with an entity, accessing the common domain and accessing, via the browser accessing the common domain, the cookie and submitting the cookie to a common domain server. The method further includes receiving, from the common domain server, a federated ID token associated with the recognition token for the service and retrieving, via the browser, the profile associated with the user based on the federated ID token.
G06F 21/33 - User authentication using certificates
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 16/9535 - Search customisation based on user profiles and personalisation
Systems and methods are provided for imposing self-exclusion preferences for data access. One example computer-implemented method includes, in response to a request by a user to impose a self-exclusion preference on a digital identity of the user, requesting a token for the digital identity. The method also includes receiving and storing the token and a secret associated with the token in a record associated with the user and assigning the self-exclusion preference to the token. The method then includes receiving a request to share an identity attribute of the user's digital identity with a relying party, where the request includes the token, and retrieving the self-exclusion preference assigned to the token. And, in response to validation of the request to share the identity attribute, based on the self-exclusion preference, authorizing a mobile device of the user to share the at least one identity attribute with the relying party.
A method for establishing an immutable record of proof of provenance of a digital receipt using blockchain includes: receiving, by a receiver of a computing device, at least a product identifier for each of one or more products; generating, by a processor of the computing device, a data object comprising a digital receipt including at least the product identifier for each of the one or more products; transmitting, by a transmitter of the computing device, the generated data object to a blockchain node in a blockchain network; receiving, by the receiver of the computing device, a notification message from the blockchain node indicating successful addition of a new blockchain data entry in a blockchain associated with the blockchain network, the new blockchain data entry including at least the generated data object; and transmitting, by the transmitter of the computing device, the generated data object to a user device.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
The disclosure describes systems and methods for authenticating a consumer performing a digital wallet transaction while wealing a face covering. A consumer authentication system includes an electronic circuit device having a wireless transmitter chip associated with a unique identifier (UID). The system receives a transaction request message, and in response, transmits an authentication request message to the consumer. The system then receives an authentication response message from the consumer. The authentication response message includes a biometric sample of a select physical feature of the consumer. The system determines that the biometric sample matches the biometric profile of the consumer above a predetermined lower threshold and then reads a unique identifier (UID) from the electronic circuit device. The system determines whether the read unique identifier (UID) matches the unique identifier (UID) of the new consumer account.
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
41.
METHODS AND SYSTEMS FOR VOICE COMMAND TRANSACTION AUTHENTICATION
The disclosure describes techniques for authenticating a voice command transaction initiated by a consumer at a voice-activated digital assistant. The system determines a proximity score for a consumer device. The proximity score is based on a distance between the consumer device and the digital assistant. The system detects motion indicating presence of a person proximate the digital assistant (based on wireless signal data) and determines a motion score. The system receives voice data from the digital assistant and determines a voice differentiation score. The system determines a rank score for the consumer device based on historical transaction data associated with the device. The system analyzes the proximity score, motion score, voice differentiation score, and rank score using a voice command authentication model. Based on the analysis, the system determines an authentication score for the voice command transaction request.
Provided are systems and methods for managing and implementing single-use payment-enabled tokens. In one example, a method may include distributing, via a server, a payment-enabled token to a payment application on a computing device, the payment-enabled token being mapped to a payment account of the payment application via a tokenization service, detecting use of the payment- enabled token as a payment via the payment application, and in response to the detecting, deactivating the payment-enabled token at the server and storing an identifier of the payment-enabled token and an additional data element of the payment-enabled token that identifies the payment account together within a data structure of the server.
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
43.
SYSTEMS AND METHODS FOR AUTHENTICATING ONLINE USERS AND PROVIDING GRAPHIC VISUALIZATIONS OF AN AUTHENTICATION PROCESS
A computer-implemented method for authenticating an online user includes steps including receiving, from a requestor server in communication with a merchant website, an authentication request message including authentication data collected 'from a user computing device during an online interaction with the merchant website. The steps also include extracting the authentication data from the authentication request message, and applying a risk-based authentication (RBA) engine to the authentication data to obtain RBA result data including a reason code that includes no more than three bytes of data... The steps further include causing the reason code to be embedded hi an authorization request message generated during the online interaction and routed to a decisioning server via a payment network. The authorization request message is formatted according to a set of proprietary communications standards promulgated by the payment network for exchange of data between institutions that are members of the payment network.
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]
44.
METHOD AND SYSTEM OF PROVIDING PROOF OF PROVENANCE OF DIGITAL RECEIPT
A method for generating a digital receipt for a transaction including provenance information for purchased products includes: receiving a data request from a first computing device including a transaction identifier related to a processed payment transaction; identifying transaction details for the processed payment transaction based on the transaction identifier, the transaction details including a product identifier for each of one or more products purchased in the processed payment transaction; transmitting the product identifier for each of the one or more products to a second computing device; receiving provenance data for each of the one or more products from the second computing device; generating a digital receipt for the processed payment transaction, the digital receipt including the received provenance data for each of the one or more products; and transmitting the generated digital receipt to the first computing device.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
45.
COMPUTER-IMPLEMENTED SYSTEMS AND METHODS FOR PAYMENT ROUTING
A system for payment routing according to a likelihood of settlement. The system includes processors and/or transceivers programmed to receive a payment transaction message relating to a putative payment transaction. The payment transaction message contains putative payment transaction data including a customer identification (ID) for an account and a transaction amount. The system generates a scaled score representing the likelihood of settlement of the putative payment transaction on at least one date for each of a plurality of potential payment rails. Based at least in part on the at least one scaled score for each of the plurality of potential payment rails, the system selects a payment rail from the plurality of payment rails. The system initiates, via the selected payment rail, a payment transaction corresponding to the putative payment transaction.
G06Q 20/14 - Payment architectures specially adapted for billing 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
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/10 - Payment architectures specially adapted for home banking systems
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
46.
SYSTEMS AND METHODS FOR PREVENTING FRAUD WITH INTUITIVE, KNOWLEDGE-BASED GEOLOCATION SERVICES
The disclosure herein relates to methods, apparatuses; and systems for improving authentication using geo location data. In some examples, a user may be authenticated by comparing user provided geolocation data with a predetermined geolocation. The- user input may be made on a map interface. In some examples, the user may be authenticated by comparing two geolocations together. A slope of a line intersecting the user inputted geolocation and the pre-defined primary geolocation may be computed. If the calculated slope value corresponds to an initial slope value, then the answer may be deemed valid. In some examples, the authentication system may authenticate the user by comparing three geoIocations together. An angle between two lines may be computed, where each line is formed by intersecting one of two geolocation answers and an intersecting the primary geoIocation. If the computed angle corresponds with a stored secret angle, the answer may be deemed valid.
An internal flow determination method comprising the steps of: receiving, at a classical computer, an input flow vector comprising a plurality of input entries, said input entries being indicative of a monetary amount entering a processing node; receiving, at a classical computer, an output flow vector comprising a plurality of output entries, said output entries being indicative of a monetary amount exiting the processing node; determining, by the classical computer, an objective optimization problem subject to one or more constraints; wherein an objective of the objective optimization problem is to determine: an input flow matrix; and an output flow matrix; determining, by the classical computer, a quadratic unconstrained binary optimization (QUBO) formulation suitable for implementing the objective optimization problem; solving, by a quantum computer, the QUBO formulation, thereby providing a solution representative of the input flow matrix and the output flow matrix; and generating, by the classical computer, a probability matrix indicative of a probability that an internal flow of the processing node connects an input entry to an output entry. The method identifies a connection likelihood between an input fund and an output fund.
A method for processing an offline blockchain transaction includes: generating, by first device, an initiate message; transmitting, by the first device, the initiate message to a second device; receiving, by the first device, a handshake message from the second device including a certificate and a recipient public key; verifying, by the first device, the handshake message including verifying the certificate using a certificate chain; generating, by the first device, a pay message including transfer data, the transfer data including data values for a proposed blockchain transaction; transmitting, by the first device, the generated pay message to the second device; receiving, by the first device, an accept message from the second device including a digital signature of the transfer data; and verifying, by the first device, the digital signature of the transfer data using as least the recipient public key.
A method for facilitating a payment transaction between incompatible and unconnected payment networks includes: receiving, by a receiver of a processing server, a transaction request from a first computing device, the transaction request including at least a first payment network identifier and a second payment network identifier; identifying, by a processor of the processing server, a first network profile associated with a first payment network based on the first payment network identifier and a second network profile associated with a second payment network based on the second payment network identifier; determining, by the processor of the processing server, one or more incremental data values required for the second payment network based on a comparison of the first network pro file with the second network profile; and transmitting, by a transmitter of the processing server, the one or more incremental data values to the first computing device.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
50.
METHOD AND SYSTEM FOR ENABLING TRACEABLE PRIVACY-MAINTAINING MULTI-HOP OFFLINE TRANSACTIONS IN DIGITAL CURRENCIES
A method for processing offline cryptocurrency transfers includes: receiving, by a receiver of a computing device, a first transfer message, wherein the first transfer message is cryptographically signed using a first private key of a first key pair; validating, by a processor of the computing device, the cryptographic signature of the first transfer message using a first public key of the first key pair; storing, in a memory of the computing device, the validated first transfer message; receiving, by an input device of the computing device, a transfer instruction, tire transfer instruction including at least a communication address; and electronically transmitting, by a transmitter of the computing device, the validated first transfer message to an external device based on at least the communication address.
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
A method for enabling the use of blockchain smart contracts as part of a traditional payment transaction includes: receiving, by a receiver of a processing server, a transaction message for a payment transaction, wherein the transaction message is formatted according to one or more standards and includes a plurality of data elements storing transaction data, the transaction data including at least a bank identification value; determining, by a processor of the processing server, a routing plan for the transaction message based on at least the bank identification value; and transmitting, by a transmitter of the processing server, the transaction message to (i) a first computing system using a first communication port of the processing server, and (ii) a second computing system using a second communication port of the processing server, based on the determined routing plan.
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/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/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
52.
FUNDS TRANSFER SERVICE METHODS AND SYSTEMS FOR FACILITATING FUNDS TRANSFERS
A payments transfer service method for facilitating a funds transfer between a sender and a recipient. In an embodiment, a payment processing network receives a funding transaction request message comprising a transaction amount and a Pre-Payment Transaction (Pre-PT) message from an originating institution (01) computer, determines an issuer financial institution (FI) that issued a payment account to the sender and transmits the funding request message and the Pre-PT message to an issuer FI computer of the issuer FI. The method also includes the payment processing network receiving a funding authorization message from the issuer FI computer, transmitting the funding authorization message to the 01 computer, receiving a payment transaction request from one of the 01 computer and a transaction initiator computer, and transmitting the funding authorization message to the RI computer.
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 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
A method of securely storing a data record from a client application in a -data base, wherein the data record comprises a plurality of data fields, the method comprising: receiving the data record from the client application, performing application-level encryption of the data record; receiving an encryption policy associated with, the client application that defines one or more data, fields within the data record that are to be hashed: hashing the or each data field of the data record; and storing the one or more hashed data fields and the encrypted data record in the database as a combined record.
A method for generating a block for a blockchain utilizing an all-or- nothing transform includes: storing, in a memory of a blockchain node in a blockchain network, a blockchain comprised of a plurality of blocks including at least a most recent block; receiving a plurality of blockchain transactions; applying an all-or- nothing transform (AONT) to the plurality of blockchain transactions to generate a plurality of pseudomessage blocks; generating a new block header including at least a timestamp and a hash value associated with the most recent block; generating a new block including at least the generated new block header and the plurality of pseudomessage blocks; and transmitting the generated new block to a plurality of additional blockchain nodes in the blockchain network.
A sub-graph isomorphism determination method comprising the steps of: determining, by the classical computer, a first adjacency matrix of a first graph and a second adjacency matrix of a second graph; wherein the first graph comprises a greater number of vertices than the second graph; determining, by the classical computer, an objective optimization problem subject to one or more constraints; wherein an objective of the objective optimization problem is to determine a partial permutation matrix; determining, by the classical computer, a QUBO matrix suitable for implementing the objective optimization problem; solving, by a quantum computer, a QUBO formulation including the QUBO matrix, thereby providing the partial permutation matrix; applying, by the classical computer, the partial permutation matrix to the first adjacency matrix, thereby producing a partially permuted first adjacency matrix; wherein the partially permuted first adjacency matrix corresponds to a sub-graph of the first graph that is isomorphic with the second graph.
A computer-implemented method is disclosed for constructing an index structure in a real-time payment network, comprising: identifying a first primary account number, PAN, from a first user account belonging to a user; creating a data record in the index structure for the user; adding first user account information to the data record, the first user account information comprising the first PAN; searching the network using the first PAN to identify one or more transactions to and/or from the first user account; identifying one or more accounts associated with the one or more transactions respectively; determining one or more additional user accounts from the one or more accounts, where the one or more additional user accounts belong to the user; and storing information associated with the first user account and the one or more additional user accounts to the data record.
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]
57.
PRE-AUTHENTICATED TOKEN FOR USE IN PAYMENT TRANSACTIONS AND DATA ACCESS
The invention provides techniques for pre-authenticating a token such that the relatively time-consuming process of performing an authentication based on a credential supplied by the user is done at a time other than the time at which the token is being used. The invention also enables the user to tightly control parameters of the pre-authentication such as an amount of funds pre-authorised, a frequency at which an operation relating to the token can be carried out and the type of user data that can be obtained through use of the token.
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/12 - Payment architectures specially adapted for electronic shopping 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
A computer-implemented method is disclosed for constructing an index structure in a real-time payment network, comprising: receiving a first set of transaction information comprising data field entries relating to a user; creating a data record in the index structure for the user, the data record comprising a plurality of data fields for data field entries; inserting the data field entries in the first set of transaction information into the data record; receiving a second set of transaction information comprising data field entries; determining if the second set of transaction information is associated with the user, wherein at least one data field entry in the second set of transaction information is different to a corresponding data field entry in the first set of transaction information; and inserting the data field entries in the second set of transaction information into the data record if the second set of transaction information is determined to be associated with the user.
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 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
A method for facilitating payment across different enterprise ecosystems through the use of a gateway platform includes : receiving, by a receiver of a processing server, a payment request message from a first computing system, wherein data included in the payment request message is formatted according to a first data format; translating, by a processor of the processing server, the data included in the payment request message.into a second data format; transmitting, by a transmitter of the processing server, the translated payment request message to a second computing system; receiving, by the receiver of the processing server, a payment confirmation message; and transmitting, by a transmitter of the processing server, an update message to a third computing system different from the first computing system.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/10 - Payment architectures specially adapted for home banking systems
G06Q 20/14 - Payment architectures specially adapted for billing 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
G06Q 30/02 - Marketing; Price estimation or determination; Fundraising
60.
METHOD AND SYSTEM OF ASSOCIATING CUSTOM CARD DESIGNS WITH NON-FUNGIBLE TOKENS
A method for performing dual verification to combine a non-fungible token (NET) with.a digital pawent instrument includes: receiving a first set of authentication credentials and a second set of 'authentication credentials, the first including a transaction account identifier, and the second set including an NFT identifier and a public key of a cryptographic key pair; performing a first verification process using the first set of authentication credentials based on at least a comparison of the first set of authentication credentials with data associated with a transaction account identified using the transaction account identifier; performing a second verification process using at least die second set of authentication credentials based on validation of a digital signature using the public key, the digital signature being identified using the NTT identifier; and transmitting a result of the first verification process and the second verification process to a computing device.
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
A method for verifying the state of an object through tamper-resistant event sourcing includes: receiving, by a receiver of a processing server, state data for a computing object and an identification value associated with the computing object; applying, by a processor of the processing server, a one-way cryptographic function to the received state data to generate a comparison hash value; identifying, by the processor of the processing server, a published hash value stored in a blockchain with the identification value; and verifying, by the processor of the processing server, a state of the computing object according to the state data based on a match of the generated comparison hash value with the identified published hash value.
G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
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
62.
DECENTRALISED QUBO SOLVER AND CRYPTOCURRENCY GENERATION
A routing optimization computer implemented method is provided, comprising the steps: (a) determining, by the classical computer, a non-convex sub- problem and a convex sub-problem of a constrained, optimization problem, the constrained optimization problem comprising: a binary variable indicative of a vehicle visiting a plurality of nodes; and a continuous variable representative of a time at which the vehicle arrives at each of the plurality of nodes; wherein the continuous variable is fixed for the non-convex sub-problem and the binary variable is fixed for the convex sub-problem; (b) generating, by the classical computer, a smart contract corresponding to the non-convex sub-problem; (c) transmitting, by the classical computer, the smart contract to a distributed ledger; (d) broadcasting, by the distributed ledger, the smart contract to a plurality of solvers; (e) receiving, at the distributed ledger, a first binary solution to the non-convex sub-problem from a first solver; (f) receiving, at the distributed ledger, a further binary solution to the non- convex sub-problem from a second solver; (g) determining, by a decision mechanism of the distributed ledger, a more suitable solution of the first binary solution and the further binary' solution; (h) transmitting, by the distributed ledger to the solver of the more suitable binary solution, a payment associated with the smart contract; (1) transmitting, by the distributed ledger to the classical computer, the more suitable binary solution; (j) determining, by the classical computer, a time solution to the convex sub-problem using the more suitable binary solution as the binary variable; (k) repeating steps (b) to (c), using the time solution as the continuous variable, until a threshold is met; and (1) mapping the binary solution and the time solution to the constrained optimization problem, thereby providing an optimized routing.
A method for facilitating secure private. -transfers in a blockchain includes: receiving an initiate message from a device for a proposed private transfer including a private group identifier, entity identifier, and transfer amount; executing a smart contract using the initiate message as input resulting in transmitting an event message to a central authority system including the -entity identifier and transfer amount; receiving a response message from the central authority- system including an indication of approval or rejection of the proposed private transfer; and executing the smart contract using the response message as input resulting in (i) adding a.private: blockchain transaction for transfer of the transfer amount from a first blockchain wallet associated with the entity identifier to a second blockchain wallet in a private group associated with the private group identifier if the response message includes an indication of approval, or (ii) declining the proposed private transfer.
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
64.
METHOD AND SYSTEM OF MACHINE LEARNING MODEL VALIDATION IN BLOCKCHAIN THROUGH ZERO KNOWLEDGE PROTOCOL
A method for determining the validity of a computational model using a blockchain and zero knowledge principles includes: storing, in a memory of a first computing system, a computational model; receiving, by a receiver of the first computing system, a blockchain data value from one block of a plurality of blocks comprising a blockchain, wherein the blockchain data value includes a data set; receiving, by the receiver of the first computing system, an expected accuracy value; applying, by a processor of the first computing system, the data set to the computational model to generate a result value; and determining, by the processor of the first computing system, a validity measurement for the computational model based on a comparison of the generated result value and the expected accuracy value.
A method of deriving an issuer master key in a transaction system, cryptographic keys within the transaction system being configured within a hierarchical structure with a system level key (SLK) at a top level of the hierarchical structure, the method comprising: receiving, at the transaction system, issuer derivation data associated with an issuer; deriving the issuer master key from the system level key using the received issuer derivation data, the issuer master key being at a lower level within the hierarchical structure than the system level key.
A method of processing information relating to an event marked in a data record associated with an entity is described. The data record comprises a date field and a cryptographic record field. First of all, it is determined whether the date field holds a true date or a dynamically generated date by matching the date field against a true date record. If the date field holds the true date, the data record is processed according to a first processing path for static data for the entity. If the date field holds the dynamically generated date, the data record is processed according to a second processing path for dynamic data generated for the event, hi processing the data record according to the second processing path, the date control is extracted from the date field, and a data record creation date is determined from the date control. An event counter is then obtained from the date field using the data record creation date. The event counter and the data record creation date are used to validate a cryptographic record in the cryptographic record field. A corresponding method of generating a dynamically generated date and an associated cryptographic record is also described, together with computing nodes adapted to perform such methods.
A method for confirming configuration of a new current genesis block in a blockchain configured to enable pruning before the new current genesis block includes: receiving, by a blockchain node in a. blockchain network, a genesis response message from another node in the network, the message including a configuration value and an ordinal value: identifying a plurality of standard blocks in the blockchain added subsequent to an earlier genesis block that includes a number preceding the ordinal value; aggregating smart contract state changes from each of the identified, plurality of standard blocks; and validating the configuration value included in the received genesis response message based on the aggregated small contract state changes. The aggregating of smart contract states can be done by the processor of the blockchain node configuring the new current genesis block, or by another blockchain node.
A computing system for detecting cyber-attack events is described. The computing system executes a roughness profiling engine and a cyber -attack detection model. The roughness profiling engine is configured to.receive a plurality of payment transaction authorization request messages and generate a plurality of groups, each group of the plurality of groups associated with a 'first data field. The roughness profiling engine is also configured to profile the plurality of groups into a plurality of sub-groups, each sub-group of the plurality of sub-groups associated with a Second data field and calculate a respective cumulative metric from the payment transaction authorization request messages associated with one of the plurality of sub- groups. Hie roughness profiling engine is further configured to determine a roughness ratio value, generate a set of feature inputs based on the roughness ratio value, and transmit the set of feature inputs to the cyber-attack detection model.
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
A method for verification of a pruned blockchain transaction includes: receiving, by a receiver of a computing device, a subset of blocks included in a plurality of blocks comprising a blockchain, wherein each block includes one or more blockchain data values; receiving, by the receiver of the computing device, an authentication code; identifying, by a processor of the computing device, a plurality of data chunks in the subset of blocks using the authentication code, where each data chunk of the plurality of data chunks is included in one of the one or more blockchain data values in a block of the subset of blocks; decoding, by the processor of the computing device, a transaction value using at least the identified plurality of data chunks and a fountain code algorithm; and verifying, by the processor of the computing device, the decoded transaction value.
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/00 - Arrangements for secret or secure communications; Network security protocols
70.
SYSTEMS AND METHODS FOR USE IN BIOMETRIC-ENABLED NETWORK INTERACTIONS
Systems and methods are provided for facilitating biometric-enabled network interactions. One example computer-implemented method includes receiving, at a biometric identity switch, from a terminal associated with a party, a request for an enrollment of a biometric of a user for biometric-enabled network interactions, the request including a biometric template of the user, identifying a biometric service provider associated with the biometric template, requesting from the identified service biometric provider, a biometric identifier for the user, based on the biometric template, receiving the biometric identifier from the identified biometric service provider, and then storing the biometric identifier for the user in a user profile, whereby the user is enrolled for biometric-enabled network interactions using the biometric.
There is provided a computer-implemented method for authenticating a chip comprised within a user device in a non-payment transaction setting, wherein the method is performed at the chip, the method comprising: storing chip input data; receiving, from a terminal device, an authentication command comprising an authentication code; computing, upon receipt of the authentication command, a user device cryptographic hash comprising the chip input data and the received authentication code; computing a user device cryptographic signature comprising the user device cryptographic hash; sending, to the terminal device, the chip input data, such that the terminal device can compute a terminal device cryptographic hash of the chip input data and the authentication code; and sending, to the terminal device, the user device cryptographic signature to be verified at the terminal device, such that the user device cryptographic hash can be retrieved from the user device cryptographic signature for comparison with the terminal device cryptographic hash to authenticate the chip in a non-payment transaction setting. There is further provided a corresponding computer-implemented method for authenticating a chip comprised within a user device in a non-payment transaction setting, wherein the method is performed at a terminal device. Further provided are associated computing devices adapted to perform the methods, corresponding computer program products, computer-readable storage media and uses.
A method for aggregated storage of observational data on a blockchain includes: receiving, by a receiver of a processing server, a plurality of data entries, wherein the plurality of data entries includes (i) one or more data entries received from each of a plurality of different external devices, or (ii) multiple data entries received from one external device; canonicalize, by a processor of the processing server, the received plurality of data entries into a single data value; hashing, by the processor of the processing server, the single data value to generate a hashed data value; transmitting, by a transmitter of the processing server, the hashed data value to a blockchain node in a blockchain network; receiving, by the receiver of the processing server, a reference value from the blockchain node; and storing, in a memory of the processing server, the received reference value with the plurality of data entries.
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
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/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
73.
METHOD AND SYSTEM FOR BLOCKCHAIN-BASED TRANSACTIONS FOR THE ATOMIC EXCHANGE OF ASSETS
A method for implementing a cooperative society through a blockchain with participation via computing devices includes: storing, in a blockchain node, a blockchain comprised of a plurality of blocks, each block including a block header and one or more blockchain data values, where at least one of the blockchain data values includes proposal data including at least a proposal identifier; receiving a vote message from each of a plurality of registered computing devices including the proposal identifier and an affirmative or negative vote; determining a proposal result based on a number of affirmative votes being above a predetermined threshold; generating a new block including a new block header and at least one new blockchain data value, the at least one new blockchain data value including the proposal result; and performing one or more actions based on data included in the proposal data.
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
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
74.
SYSTEMS AND METHODS FOR USE IN BIOMETRIC INTERACTIONS
Systems and methods are provided for resolving biometric mismatches in connection with biometric interactions performed based on the biometric mismatches. One example computer-implemented method includes receiving a biometric mismatch alert from a first party for a biometric interaction, where the biometric mismatch alert includes a credential and a reason code, and identifying a biometric provider based on a requestor ID for the biometric interaction. The method also includes transmitting the biometric mismatch alert to the identified biometric provider and determining, based on a response to the biometric mismatch alert and at least one rule, whether to impose an offset on the biometric provider for the biometric interaction. The method then includes compiling and transmitting a reply to the biometric mismatch alert to the first party, wherein the reply indicates the offset being imposed, whereby the first party initiates an offset interaction to recoup an amount of the biometric interaction.
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 40/02 - Banking, e.g. interest calculation or account maintenance
A method for parallel execution of dispatches in a smart contract in a blockchain includes: receiving, by a blockchain node in a blockchain network, a smart contract; identifying dispatches as inputs for the smart contract; separating the dispatches into sets, where each set includes at least one dispatch where each dispatch includes a common reference value associated with an entry in a prior block in the blockchain; determining one valid dispatch in each set based on predetermined criteria; executing the smart contract using the one valid dispatch for each set; a new block for the blockchain including blockchain data entries generated by execution of the smart contract; and transmitting the generated new block to a plurality of additional nodes in the blockchain network.
The present invention relates to a method 10 of authenticating an image. The method 10 comprises: producing 1 a first hash of first data using a hash function; encrypting 2 the first hash; delivering 3 the first data, the hash function and the encrypted first hash; decrypting 4 the encrypted first hash; producing 5 a second hash of the first data using the hash function; determining 6 if the decrypted first hash corresponds to the second hash; and authenticating the image if the decrypted first hash corresponds to the second hash. The first data comprises image data of the image and data relating to the contents of the image. The method 10 may be used to determine if a person is authorised to use payment details to complete a transaction. Also discloses is a system 20 for authenticating an image. The system comprises a first party system 21, a third-party system 22 and a receiving party system 23. The first party system 21 is configured to deliver first data, the first data comprising image data of the image and data relating to the contents of the image. The third-party system 22 is configured to: produce a first hash of the first data using a hash function, and encrypt the first hash. The receiving party system 23 is configured to: decrypt the first hash, produce a second hash of the first data using the hash function, and authenticate the image by verifying the decrypted first hash against the second hash.
G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
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
Briefly, embodiments are directed to a system, method, and article for receiving an authorization request message for a remote commerce transaction with a particular merchant, where the authorization request message comprises a merchant universal payment identifier (MuPi). The MuPi may be extracted from the authorization request message. Validation information may be determined for the MuPi. A message may be transmitted to a payment network to enable authorization of the remote commerce transaction at least partially in response to the determination of the validation information.
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
A community passport. ("CP") platform, provides interoperability between -community and payment services. The CP platfonn may store a digital identity of an enrolled user and share the digital identity across community and payment senice entities. For example, a community or payment senice that enrolls a user that is previously unknown to the CP platfonn may identify the user and establish a digital identity of the user. Tire digital identity may be stored at the CP platfonn for federation to participating services and at a multi-wallet device that is" issued to the user at the time of initial enrollment. After this initial enrollment, the multi-wallet device may be used to identify the user across any other community or payment service entity known to the CP platform. Each community or payment service may issue a credential that is also stored at the multi -wallet device to access that service.
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
79.
SYSTEMS AND METHODS FOR USE IN SECURING BACKUP DATA FILES
Systems and methods are provided for restoring backup data files. One example computer-implemented method includes receiving a restore request including a backup data file having an L1 file, a wrapped L1 key, and an L4 file having an attribute of a user. In response, the method includes unwrapping the L1 key with a private key, decrypting the L1 file via the L1 key, and verifying a sample biometric included in the restore request against a reference biometric from the L1 file. Upon verification of the sample biometric, the method includes decrypting an L2 file of the LI file, verifying a contact attribute from the L2 file with the user, decrypting an L3 file using the contact attribute, wrapping an L4 key from the L3 file with the public key of the restore request, and transmitting the wrapped L4 key to a mobile device of the user.
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 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
80.
SYSTEMS AND METHODS FOR USE IN GENERATING AUDIT LOGS RELATED TO NETWORK PACKETS
Systems and methods are provided for generating audit log entries for data packet transactions. One example computer-implemented method includes, in response to a request to share data about a user with a first party, retrieving data identified in the request and generating a transaction ID for the request where the transaction ID is unique to the request to share the data. The method also includes compiling a data packet including at least the transaction ID and the identified data, and generating a signature value for the data packet. The method then further includes transmitting, by the computing device, the data packet to the first party as a transaction and appending an entry to an audit log, which includes the transaction ID and the signature value, but not the identified data.
G06F 21/55 - Detecting local intrusion or implementing counter-measures
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
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
81.
SYSTEMS AND METHODS FOR USE IN DATA COUPLING AMONG DATA STRUCTURES
Systems and methods are provided for coupling data structures in different domains to provide cross-domain data access. One example computer- implemented method includes receiving, from a requestor, an access request including a case type and an indicator of a domain and determining a restriction associated with the domain. The method also includes compiling a first message key specific to the access request and transmitting the first message key to the requestor. The method further includes receiving an information request including a second message key and a query specific to a person, verifying the second message key based on the first message key, and coupling to a data structure in the domain. The method then includes, in response to verifying the second message key, submitting the query from the information request to the coupled data structure and providing a response to the query, from the data structure, to the requestor.
Systems and methods are provided for extending data files beyond sources of the data files. One example computer-implemented method includes receiving, from a mobile device of a user, selection of an option to extend a data file compiled at a source party, where the option includes a unique identifier for the user and a source identifier, and soliciting, from the mobile device, an image of the user. The method also includes receiving a captured image of the user from the mobile device and retrieving, based on the unique identifier and the source identifier, the data file from the source party. The method then includes, when the captured image matches the data file, storing the data file as a reusable data file, whereby the data file is available to be provided to one or more relying parties, different than the source party, upon consent from the user.
G06F 21/32 - User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
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
Systems and methods are provided for using verifiable credentials. One example computer-implemented method includes receiving, by an identity provider (IDP) computing device, an identity request from a relying party and directing the request to a user of an application at a mobile device associated with the user, where the mobile device includes a verifiable credential. The method also includes receiving, by the IDP computing device, from the mobile device, the verifiable credential, verifying the verifiable credential based on a public key associated with an issuer of the verifiable credential, and transmitting a link and a first authorization of the verifiable credential to the relying party. The method further includes receiving, by the IDP computing device, a request for identity data from the relying party including a second authorization and, in response to the first authorization matching the second authorization, returning the identity data to the relying party.
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
A method for private management of digital assets for multiple participants of a global blockchain includes: receiving, by a receiver of a processing server, a transaction notification for a proposed currency transfer, the transaction notification including at least a sending identifier, a recipient identifier, and a transfer amount; generating, by a processor of the processing server, a transaction data value for the proposed currency transfer, the transaction data value including at least the sending identifier, the recipient identifier, and the transfer amount; applying, by the processor of the processing server, a cryptographic hashing function to the generated transaction data value to generate a hash value; publishing, by the processor of the processing server, the generated transaction data value to a private blockchain; and publishing, by the processor of the processing server, the generated hash value to a public or permissioned blockchain.
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
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
85.
SELF-CUSTODY WALLET COMBINATION PAYMENT CARD FOR PAYMENT CARD NETWORK AND BLOCKCHAIN TRANSACTIONS
A self-custody wallet combination payment card includes an electronic component with storage, a processor, and a near field communications interface. Two programs are stored at the electronic component and, once provisioned, the electronic component stores one or more blockchain addresses and security keys. The two programs can include a payment application which can interface with point of sale terminals (e.g., following EMV specifications) and a crypto application which has the capability to securely store keys and return a signature for blockchain transaction.
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
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/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
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
A method for facilitating benefit disbursements through the use of tokens and blockchain includes: receiving beneficiary information from a first computing system, the beneficiary information including a beneficiary identifier; storing a blockchain data- entry, the blockchain data entry including a disbursement token associated with the beneficiary information and a recipient value generated using a public key of a cryptographic key pair; receiving a redemption message from a second computing system, the redemption message including the disbursement token, a digital signature generated using a private key of the cryptographic key pair, transaction account data, and a redemption amount; validating the digital signature using the public key of the cryptographic key pair; and transmitting a transfer message to the first computing system, the transfer message including the.transaction, account data and the redemption amount.
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/30 - Public key, i.e. encryption algorithm being computationally infeasible to invert and users' encryption keys not requiring secrecy
H04L 9/00 - Arrangements for secret or secure communications; Network security protocols
87.
METHOD AND SYSTEM FOR FACILITATING SUPPLY CHAIN FINANCE SERVICES
A method for facilitating advances in supply chain financing through a centralized platform includes: receiving a commitment message from a first entity system, wherein the commitment message includes at least a first transaction amount and a first payment date; receiving a financing offer from a second entity system, wherein the financing offer includes at least a second transaction amount less than the first transaction amount and a second payment date earlier than the first payment date; determining acceptance of the financing offer based on one or more predetermined criteria; transmitting the acceptance of the financing offer to the second entity system; and transmitting account data for a transaction account associated with the second entity system to the first entity system.
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/14 - Payment architectures specially adapted for billing systems
Computer implemented method for sovereign data storage comprising: authenticating a write request to upload data files to a global database system, determining relevant data types of the data files, determining a relevant regulatory domain associated with the data files out of a plurality of regulatory domains, applying regulatory domain rules associated with the one or more determined relevant regulatory domains to store the data files on one or more storage devices associated with the one or more relevant regulatory domains, assigning meta data information to the data files, the meta data information being based on regulatory domain rules associated with the one or more determined relevant regulatory domain, sending the data files to a storage engine according to the regulatory domain rules for storage of the data files, receiving a search key associated with the stored data files for local storage at the edge node and dispersing the search keys.
H04L 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
The disclosure relates to a deferred real-time payment (RTP) in a. trusted and secure system environment to pay for a deferred fulfillment order. The deferred fulfillment order includes products or services that may be fulfilled in part or in full after authorization of the deferred RTP. To facilitate trust and security, a deferred payment system may digitally sign certificates issued to various entities in the system environment. Devices in the system environment may transmit and receive messages to create and later settle deferred RTPs that are trusted based on authentication of the digitally signed certificates, which mitigate against security threats such as man-in-the-middle attacks in a communication network.
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
A computer implemented image matching method using a quantum computer in communication with a classical computer, comprising the steps of: (a) receiving, by the classical computer, an input data; (b) generating, by the classical computer, an input graph representative of the input data; ( c) augmenting, by the classical computer, the input graph; (d) performing an iteration block, the iteration block comprising: (i) retrieving, from an existing graph database of the classical computer, an existing graph; (ii) augmenting, by the classical computer, the existing graph; (iii) determining, by the classical computer, a first adjacency matrix of the augmented input graph and a second adjacency matrix of the augmented existing graph; (iv) permuting, by the classical computer, the first adjacency matrix according to an accumulated permutation, thereby generating a permuted first adjacency matrix; (v) determining, by the classical computer, a first unitary operator representation of the permuted first adjacency matrix, and a second unitary operator representation of the second adjacency matrix; (vi) generating, by the classical computer, a parametric circuit plan based on: a permutation parameter of a set of permutation parameters; a hyper-parameter of a set of permutation parameters; (vii) implementing, on the quantum computer, a quantum circuit based on: the first unitary operator representation; the second unitary operator representation; and the parametric circuit plan; wherein a parametric circuit portion of the quantum circuit permutes the permuted first adjacency matrix according to a permutation based on the permutation parameter; (viii) executing and measuring, by the quantum computer, a quantum state of the quantum circuit; (ix) determining, by the classical computer, a loss of a loss function based on the quantum state; (x) updating, by the classical computer, the accumulated permutation by applying the permutation to the accumulated permutation; and (xi) selecting, by the classical computer, a new permutation for the iteration block parameter based on the loss; (e) repeating the iteration block using: the new permutation parameter; the permuted first adjacency matrix; and a new existing graph; wherein the iteration block is repeated until a threshold is met; wherein in a first iteration of the iteration block, the accumulated permutation is the identity such that the permuted first adjacency matrix is equal to the first adjacency matrix; wherein the first graph is isomorphic with the second graph when the loss is minimized; and wherein the first data matches the existing data when the first graph is isomorphic with the second graph.
A computer implemented method for optimising, by a classical computer, an objective optimisation problem comprising: receiving the objective optimisation problem, the objective optimisation problem being represented by an L x L objective matrix comprising a plurality of matrix components; receiving a set of frozen variables; determining a set of freezable matrix components corresponding to the set of frozen variables; determining a contribution vector based on the set of freezable matrix components and the set of frozen variables; and determining an equivalent optimisation problem based on the contribution vector and the objective optimisation problem, wherein the equivalent optimisation problem excludes the freezable matrix components such that the equivalent optimisation problem may be solved on a quantum computer using fewer quantum bits than the objective optimisation problem would require. The method therefore preferably provides a means for solving a real world offer allocation optimisation problem on a quantum computer using fewer qubits.
A method of verifying data during a transaction process between the payment device and a terminal is described. The method comprises providing, by the terminal to the payment device, a request to generate cryptogram data for verification. The method further comprises the following steps, performed by the payment device: generating a first digest over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process; generating a cryptogram unique to the 'transaction process, using the first digest and a subset of the plurality of transaction data items; generating, a cryptogram response message containing the cryptogram, the first digest and the subset of transaction data items used to generate the cryptogram; and.transmitting die cryptogram response message to the terminal.. The method forther comprises the following steps, performed by the terminal: generating a second digest 'using a stored plurality of transaction da ta items exchanged between the payment device and the terminal during the: transaction process; comparing the first digest with the second digest; and (i) if the first digest matches the second digest, proceeding with forther authentication and subsequently generating an authorisation request message for provision io an authorisation system; or (ii) if the first digest does not match the second digest, aborting, by 'the terminal, the transaction process.
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
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
A method of performing an interaction over a wireless communication network between a first device and a second device is described. The result of this interaction is for processing by a discrete processing system according to a set of protocols. The interaction itself may be processed by a plurality of kernels on the first device and a plurality of applications on the second device. To establish which kernel and application will be used, the following steps are taken. The first device establishes from the plurality of kernels a plurality of possible applications for processing the interaction at the second device, the first device obtaining from the kernels information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction, and provides a message to the second device identifying the plurality of possible applications and the information needed for all the plurality of possible applications. The second device selects one of the plurality of possible applications at the second device and runs that application using the information provided for that application to produce interaction data for the interaction. The second device then sends the choice of application and the interaction data to the first device. This is then provided to the appropriate kernel at the first device which uses the interaction data to obtain an interaction result for processing by the discrete processing system from said one of the plurality of kernels.
A method of providing a secure service at a computing node for a requesting party external to the computing node is described. The following steps are taken at the computing node. A service request comprising a request to generate a credential is received from a requesting party. The computing node generates the credential and obtains service-related information. A clear message part is created comprising service-identifying information. A checksum is then created from at least a part of the service-identifying information and from at least a part of the credential and the service-related information. The credential, the service-related information and the checksum are then encrypted to form an encrypted message part. A message comprising the clear message part and the encrypted message part is then sent to the requesting party. Methods for providing secure services to validate the credential and to obtain the service-related information are also described, as is computing apparatus adapted to perform all these methods.
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
A method for moderation in a permissioned blockchain using a. hash- oriented scheme includes: storing a blockchain including a most recent block; receiving transaction data values; receiving a -first reference value and a second reference value; generating a first hash value by hashing the first reference value; generating a block proof including the first hash value, a second hash value, a third reference value, and a block value; verifying a block header of the most recent block using the block proof; receiving a. new block value; generating a new block header including the first reference value, the second reference value, a fourth reference value, and the new block value; generating a new block for the blockchain including the new block header and the transaction data values; and transmitting the new block to one or more additional nodes associated with the blockchain.
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/00 - Arrangements for secret or secure communications; Network security protocols
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
Various implementations described herein may refer to' a compliance platform.for' use with identity7 data. In one implementation, a method may include receiving a compliance data package from a user, where the compliance data package includes encrypted evidence data corresponding to digital identity data of the user. The method may also include encrypting the compliance data package using a first cryptographic key. The method may further include generating a. user key shard, a requestor key shard, and a regulator key shard based on the first cryptographic key. The method may include generating an unlock data package that includes the requestor key shard and encrypting the unlock data package using a second cryptographic key. The method may also include transmitting the user key shard, the encrypted unlock data package, and the encrypted compliance data package to the user. The method may' include transmitting the regulator key shard to a regulator.
G06F 21/33 - User authentication using certificates
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/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
G11B 20/00 - Signal processing not specific to the method of recording or reproducing; Circuits therefor
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/00 - Arrangements for secret or secure communications; Network security protocols
There is provided a computer-implemented method for establishing a communication channel for exchanging messages.securely between an initiator device and an endpoint device using an intermediary server, wherein the initiator device is in communication with the..intermediary server via a first session encrypted according to a cryptographic protocol, and the endpoint device is in communication with the intermediary server via. a second session encrypted according to a cryptographic protocol, and wherein the method is performed at tile initiator device. The method comprises sending, to the intermediary server, a request for a handover token (HT) via the first session encrypted according to a cryptographic protocol, wherein the handover token (HT) comprises data that has been generated at the endpoint device arid is configured to be used in setting up the communication channel between the initiator device and the endpoint device; receiving, from the intermediary server, the handover token (HT) via the first session encrypted according to a cryptographic protocol; and establishing, using the handover token (HT), the communication channel between the initiator device and the endpoint device. There is also provided an associated computing device. There is further provided a corresponding server- based method and system.
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
A method of processing, at an authentication server, content data provided during an interaction between a user and a third party platform, the method comprising: receiving, at the authentication server, user verification data and content data from the third party platform; verifying the identity of the user by comparing the received user verification data against verification data stored in a user profile in order to generate a user identity status; analysing received content data against pre¬ existing user data in order to generate a content data notification message; sending, from the authentication server to the third party platform, an authentication message, the authentication message comprising the user identity status and the content data notification message.
G06Q 20/12 - Payment architectures specially adapted for electronic shopping systems
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
G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
99.
SPLIT INTEGRATOR MODEL FOR FACILITATING PURCHASE TRANSACTIONS
Split integrator model methods and systems for conducting a consumer purchase transaction. In an embodiment, a payment system receives a checkout request message comprising checkout request data from a mobile device application running on a consumer mobile device of a consumer, identifies a payload recipient based on the checkout request data, and then transmits a transaction payload to the payload recipient that includes at least a merchant identifier, payment card account details and a purchase transaction amount. The process also includes the payment system receiving a transaction authorization request from the payload recipient, and then transmitting the transaction authorization request for purchase transaction authorization processing to an issuer financial institution (FI) computer.
Various implementations directed to a system and method for product delivery using a fulfillment model are provided, In one implementation, a method may include generating a fulfillment database for fulfillers, where the fulfillment database includes inventory data and location data. The method may also include receiving order data from an originator, where the order data includes delivery data and product data corresponding to a transaction between a customer and the originator, and where the product data includes data corresponding 'to a product purchased by the customer.from the originator. The method may farther include determining, optimal prices for the fulfillers using a pricing model based on the order data and the fulfillment database. The method may additionally include selecting a first fulfiller using a fulfillment model based on the order data, the fulfillment database, and the optimal prices.