Methods of performing transactions with a payment card comprising an integrated circuit are disclosed comprising interacting with an integrated circuit on a received payment card and inferring an application corresponding to a card brand and card type of the payment card, or retrieving a map of the integrated circuit to read records on the integrated circuit based on the map, are disclosed. Corresponding devices, such as PIN pads, and computer products are also disclosed.

A device and method for managing personal data. A request for an identifier (ID) token corresponding to a user is received from a virtual wallet. The ID token is generated and transmitted to the virtual wallet, where the ID token is then presented to a third-party entity by a device of the user. A request for the personal data corresponding to the ID token is received from the third-party entity. A trustworthiness score is determined that corresponds to the third-party entity based at least in part on an analysis of entity data corresponding to the third-party entity. The trustworthiness score and received request are transmitted to the virtual wallet and passed on to the user device. An indication of acceptance of the request and encrypted personal data associated with the generated ID token are received from the virtual wallet and transmitted to the third-party entity for processing.

Embodiments of the present specification provide a method, an apparatus, a client terminal, and a server for data processing. The method includes: selecting, based on a data attribute of to-be-processed data, a target coordinating server from a plurality of coordinating servers, the plurality of coordinating servers belonging to a plurality of server clusters respectively; and sending a data processing request to the target coordinating server, such that a server cluster to which the target coordinating server belongs processes the data processing request preferentially, the data processing request directing to the to-be-processed data.

An example operation may include one or more of configuring a blockchain network comprising first and second blockchain nodes, providing, by the first blockchain node, a data reference to the second blockchain node, accessing a document, by the second blockchain node, from the first blockchain node, and providing by the second blockchain node, a proof of receipt for the document to a shared blockchain ledger.

Disclosed are various embodiments for replacing hard-coded certificate pinning with blockchain based certificate pinning. A signing device can obtain a public key from an endpoint device, produce a signature for the public key, and store the public key on a distributed data store, such as a blockchain. A client device can obtain and validate the public keys from the distributed data store and use the public keys to establish a secure connection between the client device and the endpoint device.

The present invention generally relates to a method, system and program product for generating a stable value digital asset tied to a blockchain.

This invention relates generally to distributed ledger technology (including blockchain related technologies), particularly a method and corresponding system for providing a blockchain transaction comprising a redeem script for an output that comprises: i) a plurality of public keys, each associated with a corresponding private key, wherein each public key is uniquely associated with a potential state of at least one data source; and ii) logic arranged to provide a result based on: A) a determination of which of the plurality of associated private key(s) is/are used to sign the unlocking script, so as to provide an interim result: and B) a comparison of a parameter supplied via the unlocking script against the interim result, and further attempting to spend the transaction output more than once, each attempt supplying a different parameter.

A method of digitally signing a message is disclosed. The method comprises distributing first shares of a first secret value among a plurality of participants, wherein the first secret value is a private key accessible by means of a first threshold number of the first shares, and is inaccessible to less than the first threshold number of the first shares; distributing second shares of a second secret value among the participants, wherein the second secret value is an ephemeral key, wherein said ephemeral key is inaccessible to less than said first threshold number of said second shares; and distributing third shares of a third secret value among the participants, wherein each third share is adapted to be applied to a message to generate a respective fourth share of a fourth secret value, wherein the fourth secret value is the message signed with the private key and using the ephemeral key.

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.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.