Conceptio › Archive › Google Patents

Google Patents open access

Universally trusted bridges for heterogenous blockchain networks — Paypal, Inc. (US12676756B2)

Paypal, Inc. · Google Patents

Google Patents · Patents

en google-patents intellectual-property michael-jim-tien-chan patent paypal

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

ABSTRACT

Abstract

Different communication and software protocols may be used by different blockchain networks. Cross-chain communication is provided via a software bridge configured to enable specific operations. An event request may be sent from a first blockchain network to a second blockchain network. The event request may be processed using a first protocol of the first network to provide a first output. An offer of equivalent processing provided by the second network may be verified by: processing the event request using a second protocol of the second network to provide a second output, and confirming that the second output matches the offer of equivalent processing. A processing equivalence of the event request may be established between the first network and the second network based on the first output of the event request processed using the first protocol and the second output of the event request processed using the second protocol.

Description

CROSS REFERENCE TO RELATED APPLICATION

The present invention is a Continuation of U.S. patent application Ser. No. 17/412,132, filed Aug. 25, 2021, the disclosure of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to blockchain technology, and hardware and software related thereto. More specifically, the present disclosure relates to systems and methods for implementing blockchain bridges that allow exchanges between different types of blockchains in a variety of blockchain network environments, according to various embodiments.

BACKGROUND

Blockchains may have different formats that present interoperability problems. One type of blockchain may use different types of operations (e.g. encryption, transaction commitment, etc.) than another type of blockchain. This means that various blockchains cannot readily exchange information with each other, and thus, enabling a cross-chain transaction presents various difficulties.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide further understanding and are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the principles of the disclosed embodiments. In the drawings:

FIG. 1 illustrates an example computing architecture for facilitating one or more blockchain based transactions.

FIG. 2 illustrates an example blockchain network.

FIG. 3 illustrates an example blockchain.

FIG. 4 is a diagram of an example transaction message.

FIG. 5 shows an example transaction broadcast the blockchain network.

FIG. 6 A is a flow diagram showing steps of an example method for performing a blockchain based transaction.

FIG. 6 B is a flow diagram showing steps of an example method for performing a blockchain based transaction.

FIG. 7 A shows an example of a privately broadcasted blockchain.

FIG. 7 B shows an example of blockchain misuse.

FIG. 8 illustrates an example of a blockchain enabled in-store purchase system.

FIG. 9 illustrates an example of communications for an IoT blockchain enabled device system.

FIG. 10 illustrates an example system.

FIG. 11 illustrates an example computing device.

FIG. 12 is a flow diagram showing steps of an example method for generating a blockchain bridge for heterogeneous blockchain networks for use in data exchange between the heterogenous blockchain networks.

FIG. 13 illustrates an example of a two-way polling service bridge established between a first blockchain network and a second blockchain network.

FIG. 14 illustrates examples of two-way polling service bridges established between blockchain networks.

FIG. 15 illustrates example events that trigger atomic blockchains for microservices.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference is made to the accompanying drawings identified above and which form a part hereof, and in which is shown by way of illustration of various embodiments in which aspects described herein may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope described herein. Various aspects are capable of other embodiments and of being practiced or being carried out in various different ways.

Blockchain bridges enable interoperability between different blockchain networks, such as Bitcoin, Ethereum, etc., and between parent blockchains and child blockchains (e.g., sidechains), which may operate under different protocols, consensus rules, cryptographic suites, etc. Interoperability between blockchain networks may include the transfer/exchange of tokens, data, and smart contract instructions between the blockchain networks. For example, blockchain bridges may allow users to deploy digital assets hosted on one blockchain network to decentralized applications (dApps) on another blockchain network, conduct fast, low-cost transactions of tokens hosted on otherwise less scalable blockchains, execute dApps across more than one blockchain network, and so forth.

However, to perform a cross-chain transaction, two or more blockchain networks involved in the transaction need to reach an agreement with regard to how the transaction will be processed on their respective blockchain networks. While third-party bridge solutions and single-side bridge solutions exist, these solutions are black/gray box as their internal mechanisms are proprietary for their developer, and often cause at least one side of a cross-chain transaction to have questions or concerns regarding the trustworthiness of the particular bridge. Currently, there is no trusted bridge for two or more blockchain networks with disparate network protocols or for when two states with regulatory oversight on the blockchain networks cannot trust each other. Thus, there is a need in the art for blockchain bridges that are co-built as a membrane of trust where participating networks may build and co-sign an offer-and-agreed upon premise for mapping respective network protocols to a single equivalent that can be used as a platform to conduct cross-chain transactions that may be represented on each of the participating networks.

In its broadest sense, blockchain refers to a framework that supports a trusted ledger that is stored, maintained, and updated in a distributed manner in a peer-to-peer network. For example, in a cryptocurrency application, such as Bitcoin or Ethereum, Ripple, Dash, Litecoin, Dogecoin, zCash, Tether, Bitcoin Cash, Cardano, Stellar, EOS, NEO, NEM, Bitshares, Decred, Augur, Komodo, PIVX, Waves, Steem, Monero, Golem, Stratis, Bytecoin, Ardor, or in digital currency exchanges, such as Coinbase, Kraken, CEX.IO, Shapeshift, Poloniex, Bitstamp, Coinmama, Bisq, LocalBitcoins, Gemini and others, the distributed ledger represents each transaction where units of the cryptocurrency are transferred between entities. For example, using a digital currency exchange, a user may buy any value of digital currency or exchange any holdings in digital currencies into worldwide currency or other digital currencies. Each transaction can be verified by the distributed ledger and only verified transactions are added to the ledger. The ledger, along with many aspects of blockchain, may be referred to as âdecentralizedâ in that a central authority is typically not present. Because of this, the accuracy and integrity of the ledger cannot be attacked at a single, central location. Modifying the ledger at all, or a majority of, locations where it is stored is made difficult so as to protect the integrity of the ledger. This is due in large part because individuals associated with the nodes that make up the peer-to-peer network have a vested interest in the accuracy of the ledger.

Though maintaining cryptocurrency transactions in the distributed ledger may be the most recognizable use of blockchain technology today, the ledger may be used in a variety of different fields. Indeed, blockchain technology is applicable to any application where data of any type may be accessed where the accuracy of the data is assured. For example, a supply chain may be maintained in a blockchain ledger, where the transfer of each component from party to party, and location to location, may be recorded in the ledger for later retrieval. Doing so allows for easier identification of a source for a defective part and where other such defective parts have been delivered. Similarly, food items may be tracked in like manner from farm to grocery store to purchaser.

Implementations of the present disclosure will now be described in detail with reference to the accompanying Figures.

It is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning. The use of âincludingâ and âcomprisingâ and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof.

Computing Architecture

As discussed above, the distributed ledger in a blockchain framework is stored, maintained, and updated in a peer-to-peer network. In one example the distributed ledger maintains a number of blockchain transactions. FIG. 1 shows an example system 100 for facilitating a blockchain transaction. The system 100 includes a first client device 120 , a second client device 125 , a first server 150 , and an Internet of Things (IOT) device 155 interconnected via a network 140 . The first client device 120 , the second client device 125 , the first server 150 may be a computing device 605 described in more detail with reference to FIG. 6 . The IoT device 155 may comprise any of a variety of devices including vehicles, home appliances, embedded electronics, software, sensors, actuators, thermostats, light bulbs, door locks, refrigerators, RFID implants, RFID tags, pacemakers, wearable devices, smart home devices, cameras, trackers, pumps, POS devices, and stationary and mobile communication devices along with connectivity hardware configured to connect and exchange data. The network 140 may be any of a variety of available networks, such as the Internet, and represents a worldwide collection of networks and gateways to support communications between devices connected to the network 140 . The system 100 may also comprise one or more distributed or peer-to-peer (P2P) networks, such as a first, second, and third blockchain network 130 a - c (generally referred to as blockchain networks 130 ). As shown in FIG. 1 , the network 140 may comprise the first and second blockchain networks 130 a and 130 b . The third blockchain network 130 c may be associated with a private blockchain as described below with reference to FIG. 2 , and is thus, shown separately from the first and second blockchain networks 130 a and 103 b . Each blockchain network 130 may comprise a plurality of interconnected devices (or nodes) as described in more detail with reference to FIG. 2 . As discussed above, a ledger, or blockchain, is a distributed database for maintaining a growing list of records comprising any type of information. A blockchain, as described in more detail with reference to FIG. 3 , may be stored at least at multiple nodes (or devices) of the one or more blockchain networks 130 .

In one example, a blockchain based transaction may generally involve a transfer of data or value between entities, such as the first user 110 of the first client device 120 and the second user 115 of the second client device 125 in FIG. 1 . The server 150 may include one or more applications, for example, a transaction application configured to facilitate the transaction between the entities by utilizing a blockchain associated with one of the blockchain networks 130 . As an example, the first user 110 may request or initiate a transaction with the second user 115 via a user application executing on the first client device 120 . The transaction may be related to a transfer of value or data from the first user 110 to the second user 115 . The first client device 120 may send a request of the transaction to the server 150 . The server 150 may send the requested transaction to one of the blockchain networks 130 to be validated and approved as discussed below.

Blockchain Network

FIG. 2 shows an example blockchain network 200 comprising a plurality of interconnected nodes or devices 205 a - h (generally referred to as nodes 205 ). Each of the nodes 205 may comprise a computing device 605 described in more detail with reference to FIG. 6 . Although FIG. 2 shows a single device 205 , each of the nodes 205 may comprise a plurality of devices (e.g., a pool). The blockchain network 200 may be associated with a blockchain 220 . Some or all of the nodes 205 may replicate and save an identical copy of the blockchain 220 . For example, FIG. 3 shows that the nodes 205 b - e and 205 g - h store copies of the blockchain 220 . The nodes 205 b - e and 205 g - h may independently update their respective copies of the blockchain 220 as discussed below.

Blockchain Node Types

Blockchain nodes, for example, the nodes 205 , may be full nodes or lightweight nodes. Full nodes, such as the nodes 205 b - e and 205 g - h , may act as a server in the blockchain network 200 by storing a copy of the entire blockchain 220 and ensuring that transactions posted to the blockchain 220 are valid. The full nodes 205 b - e and 205 g - h may publish new blocks on the blockchain 220 . Lightweight nodes, such as the nodes 205 a and 205 f , may have fewer computing resources than full nodes. For example, IoT devices often act as lightweight nodes. The lightweight nodes may communicate with other nodes 205 , provide the full nodes 205 b - e and 205 g - h with information, and query the status of a block of the blockchain 220 stored by the full nodes 205 b - e and 205 g - h . In this example, however, as shown in FIG. 2 , the lightweight nodes 205 a and 205 f may not store a copy of the blockchain 220 and thus, may not publish new blocks on the blockchain 220 .

Blockchain Network Types

CROSS REFERENCE TO RELATED APPLICATION

The present invention is a Continuation of U.S. patent application Ser. No. 17/412,132, filed Aug. 25, 2021, the disclosure of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

BACKGROUND

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example computing architecture for facilitating one or more blockchain based transactions.

FIG. 2 illustrates an example blockchain network.

FIG. 3 illustrates an example blockchain.

FIG. 4 is a diagram of an example transaction message.

FIG. 5 shows an example transaction broadcast the blockchain network.

FIG. 6 A is a flow diagram showing steps of an example method for performing a blockchain based transaction.

FIG. 6 B is a flow diagram showing steps of an example method for performing a blockchain based transaction.

FIG. 7 A shows an example of a privately broadcasted blockchain.

FIG. 7 B shows an example of blockchain misuse.

FIG. 8 illustrates an example of a blockchain enabled in-store purchase system.

FIG. 9 illustrates an example of communications for an IoT blockchain enabled device system.

FIG. 10 illustrates an example system.

FIG. 11 illustrates an example computing device.

FIG. 13 illustrates an example of a two-way polling service bridge established between a first blockchain network and a second blockchain network.

FIG. 14 illustrates examples of two-way polling service bridges established between blockchain networks.

FIG. 15 illustrates example events that trigger atomic blockchains for microservices.

DETAILED DESCRIPTION

Implementations of the present disclosure will now be described in detail with reference to the accompanying Figures.

Computing Architecture

Blockchain Network

Blockchain Node Types

Blockchain Network Types

The blockchain network 200 and its associated blockchain 220 may be public (permissionless), federated or consortium, or private. If the blockchain network 200 is public, then any entity may read and write to the associated blockchain 220 . However, the blockchain network 200 and its associated blockchain 220 may be federated or consortium if controlled by a single entity or organization. Further, any of the nodes 205 with access to the Internet may be restricted from participating in the verification of transactions on the blockchain 220 . The blockchain network 200 and its associated blockchain 220 may be private (permissioned) if access to the blockchain network 200 and the blockchain 220 is restricted to specific authorized entities, for example organizations or groups of individuals. Moreover, read permissions for the blockchain 220 may be public or restricted while write permissions may be restricted to a controlling or authorized entity.

Blockchain

As discussed above, a blockchain 220 may be associated with a blockchain network 200 . FIG. 3 shows an example blockchain 300 . The blockchain 300 may comprise a plurality of blocks 305 a , 305 b , and 305 c (generally referred to as blocks 305 ). The blockchain 300 comprises a first block (not shown), sometimes referred to as the genesis block. Each of the blocks 305 may comprise a record of one or a plurality of submitted and validated transactions. The blocks 305 of the blockchain 300 may be linked together and cryptographically secured. In some cases, the post-quantum cryptographic algorithms that dynamically vary over time may be utilized to mitigate ability of quantum computing to break present cryptographic schemes. Examples of the various types of data fields stored in a blockchain block are provided below. A copy of the blockchain 300 may be stored locally, in the cloud, on grid, for example by the nodes 205 b - e and 205 g - h , as a file or in a database.

Blocks

Each of the blocks 305 may comprise one or more data fields. The organization of the blocks 305 within the blockchain 300 and the corresponding data fields may be implementation specific. As an example, the blocks 305 may comprise a respective header 320 a , 320 b , and 320 c (generally referred to as headers 320 ) and block data 375 a , 375 b , and 375 c (generally referred to as block data 375 ). The headers 320 may comprise metadata associated with their respective blocks 305 . For example, the headers 320 may comprise a respective block number 325 a , 325 b , and 325 c . As shown in FIG. 3 , the block number 325 a of the block 305 a is Nâ1, the block number 325 b of the block 305 b is N, and the block number 325 c of the block 305 c is N+1. The headers 320 of the blocks 305 may include a data field comprising a block size (not shown).

The blocks 305 may be linked together and cryptographically secured. For example, the header 320 b of the block N (block 305 b ) includes a data field (previous block hash 330 b ) comprising a hash representation of the previous block Nâ1's header 320 a . The hashing algorithm utilized for generating the hash representation may be, for example, a secure hashing algorithm 256 (SHA-256) which results in an output of a fixed length. In this example, the hashing algorithm is a one-way hash function, where it is computationally difficult to determine the input to the hash function based on the output of the hash function. Additionally, the header 320 c of the block N+1 (block 305 c ) includes a data field (previous block hash 330 c ) comprising a hash representation of block N's (block 305 b ) header 320 b.

The headers 320 of the blocks 305 may also include data fields comprising a hash representation of the block data, such as the block data hash 370 a - c . The block data hash 370 a - c may be generated, for example, by a Merkle tree and by storing the hash or by using a hash that is based on all of the block data. The headers 320 of the blocks 305 may comprise a respective nonce 360 a , 360 b , and 360 c . In some implementations, the value of the nonce 360 a - c is an arbitrary string that is concatenated with (or appended to) the hash of the block. The headers 320 may comprise other data, such as a difficulty target.

The blocks 305 may comprise a respective block data 375 a , 375 b , and 375 c (generally referred to as block data 375 ). The block data 375 may comprise a record of validated transactions that have also been integrated into the blockchain 200 via a consensus model (described below). As discussed above, the block data 375 may include a variety of different types of data in addition to validated transactions. Block data 375 may include any data, such as text, audio, video, image, or file, that may be represented digitally and stored electronically.

Blockchain Transaction

In one example, a blockchain based transaction may generally involve a transfer of data or value or an interaction between entities and described in more detail below. Referring back to FIG. 1 , the server 150 may include one or more applications, for example, a transaction application configured to facilitate a blockchain transaction between entities. The entities may include users, devices, etc. The first user 110 may request or initiate a transaction with the second user 115 via a user application executing on the first client device 120 . The transaction may be related to a transfer of value or data from the first user 110 to the second user 115 . The value or data may represent money, a contract, property, records, rights, status, supply, demand, alarm, trigger, or any other asset that may be represented in digital form. The transaction may represent an interaction between the first user 110 and the second user 115 .

FIG. 4 is a diagram of a flow 400 that generates a transaction 465 by the transaction application. The transaction 465 may include a public key 415 , a blockchain address 430 associated with the first user 110 , a digital signature 455 , and transaction output information 460 . The transaction application may derive a public key 415 from a private key 405 of the first user 110 by applying a cryptographic hash function 410 to the private key 405 . The cryptographic hash function 410 may be based on AES, SHA-2, SHA-3, RSA, ECDSA, ECDH (elliptic curve cryptography), or DSA (finite field cryptography), although other cryptographic models may be utilized. More information about cryptographic algorithms may be found in Federal Information Processing Standards Publication (FIPS PUB 180 - 3 ), Secure Hash Standard. The transaction application may derive an address or identifier for the first user 110 , such as the blockchain address 430 , by applying a hash function 420 to the public key 415 . Briefly, a hash function is a function that may be used for mapping arbitrary size data to fixed size data. The value may also be referred to as a digest, a hash value, a hash code, or a hash. In order to indicate that the first user 110 is the originator of the transaction 465 , the transaction application may generate the digital signature 455 for the transaction data 435 using the private key 405 of the first user 110 . The transaction data 435 may include information about the assets to be transferred and a reference to the sources of the assets, such as previous transactions in which the assets were transferred to the first user 110 or an identification of events that originated the assets. Generating the digital signature 455 may include applying a hash function 440 to the transaction data 435 resulting in hashed transaction data 445 . The hashed transaction data 445 and the transaction data 435 may be encrypted (via an encryption function 450 ) using the private key 405 of the first user 110 resulting in the digital signature 455 . The transaction output information 460 may include asset information 450 and an address or identifier for the second user 450 , such as the blockchain address 450 . The transaction 465 may be sent from the first client device 125 to the server 150 .

The specific type of cryptographic algorithm being utilized may vary dynamically based on various factors, such as a length of time, privacy concerns, etc. For example, the type of cryptographic algorithm being utilized may be changed yearly, weekly, daily, etc. The type of algorithms may also change based on varying levels of privacy. For example, an owner of content may implement a higher level of protection or privacy by utilizing a stronger algorithm.

Blockchain Addresses

A blockchain network may utilize blockchain addresses to indicate an entity using the blockchain or start and end points in the transaction. For example, a blockchain address for the first user 110 , shown in FIG. 4 as the blockchain address of sender 430 , may include an alphanumeric string of characters derived from the public key 415 of the first user 110 based on applying a cryptographic hash function 420 to the public key 415 . The methods used for deriving the addresses may vary and may be specific to the implementation of the blockchain network. In some examples, a blockchain address may be converted into a QR code representation, barcode, token, or other visual representations or graphical depictions to enable the address to be optically scanned by a mobile device, wearables, sensors, cameras, etc. In addition to an address or QR code, there are many ways of identifying individuals, objects, etc. represented in a blockchain. For example, an individual may be identified through biometric information such as a fingerprint, retinal scan, voice, facial id, temperature, heart rate, gestures/movements unique to a person etc., and through other types of identification information such as account numbers, home address, social security number, formal name, etc.

Broadcasting Transaction

The server 150 may receive transactions from users of the blockchain network 130 . The transactions may be submitted to the server 150 via desktop applications, smartphone applications, digital wallet applications, web services, or other software applications. The server 150 may send or broadcast the transactions to the blockchain network 130 . FIG. 5 shows an example transaction 502 broadcast by the server 150 to the blockchain network 130 . The transaction 502 may be broadcast to multiple nodes 205 of the blockchain network 130 . Typically, once the transaction 502 is broadcast or submitted to the blockchain network 130 , it may be received by one or more of the nodes 205 . Once the transaction 502 is received by the one or more nodes 205 of the blockchain network 130 , it may be propagated by the receiving nodes 205 to other nodes 205 of the blockchain network 130 .

A blockchain network may operate according to a set of rules. The rules may specify conditions under which a node may accept a transaction, a type of transaction that a node may accept, a type of compensation that a node receives for accepting and processing a transaction, etc. For example, a node may accept a transaction based on a transaction history, reputation, computational resources, relationships with service providers, etc. The rules may specify conditions for broadcasting a transaction to a node. For example, a transaction may be broadcast to one or more specific nodes based on criteria related to the node's geography, history, reputation, market conditions, docket/delay, technology platform. The rules may be dynamically modified or updated (e.g. turned on or off) to address issues such as latency, scalability and security conditions. A transaction may be broadcast to a subset of nodes as a form of compensation to entities associated with those nodes (e.g., through receipt of compensation for adding a block of one or more transactions to a blockchain).

Transaction ValidationâUser Authentication and Transaction Data Integrity

Not all the full nodes 205 may receive the broadcasted transaction 502 at the same time, due to issues such as latency. Additionally, not all of the full nodes 205 that receive the broadcasted transaction 502 may choose to validate the transaction 502 . A node 205 may choose to validate specific transactions, for example, based on transaction fees associated with the transaction 502 . The transaction 502 may include a blockchain address 505 for the sender, a public key 510 , a digital signature 515 , and transaction output information 520 . The node 205 may verify whether the transaction 502 is legal or conforms to a pre-defined set of rules. The node 205 may also validate the transaction 502 based on establishing user authenticity and transaction data integrity. User authenticity may be established by determining whether the sender indicated by the transaction 502 is in fact the actual originator of the transaction 502 . User authenticity may be proven via cryptography, for example, asymmetric-key cryptography using a pair of keys, such as a public key and a private key. Additional factors may be considered when establishing user authenticity, such as user reputation, market conditions, history, transaction speed, etc. Data integrity of the transaction 502 may be established by determining whether the data associated with the transaction 502 was modified in any way. Referring back to FIG. 4 , when the transaction application creates the transaction 465 , it may indicate that the first user 110 is the originator of the transaction 465 by including the digital signature 455 .

The node 205 may decrypt the digital signature 515 using the public key 510 . A result of the decryption may include hashed transaction data 540 and transaction data 530 . The node 205 may generate hashed transaction data 550 based on applying a hash function 545 to the transaction data 530 . The node 205 may perform a comparison 565 between the first hashed transaction data 540 and the second hashed transaction data 550 . If the result 570 of the comparison 565 indicates a match, then the data integrity of the transaction 502 may be established and node 205 may indicate that the transaction 502 has been successfully validated. Otherwise, the data of the transaction 502 may have been modified in some manner and the node 205 may indicate that the transaction 502 has not been successfully validated.

Each full node 205 may build its own block and add validated transactions to that block. Thus, the blocks of different full nodes 205 may comprise different validated transactions. As an example, a full node 205 a may create a first block comprising transactions âA,â âB,â and âC.â Another full node 205 b may create a second block comprising transactions âC,â âD,â and âE.â Both blocks may include valid transactions. However, only one block may get added to the blockchain, otherwise the transactions that the blocks may have in common, such as transaction âCâ may be recorded twice leading to issues such as double-spending when a transaction is executed twice. One problem that may be seen with the above example is that transactions âC,â âD,â and âEâ may be overly delayed in being added to the blockchain. This may be addressed a number of different ways as discussed below.

Securing Keys

Private keys, public keys, and addresses may be managed and secured using software, such as a digital wallet. Private keys may also be stored and secured using hardware. The digital wallet may also enable the user to conduct transactions and manage the balance. The digital wallet may be stored or maintained online or offline, and in software or hardware or both hardware and software. Without the public/private keys, a user has no way to prove ownership of assets. Additionally, anyone with access a user's public/private keys may access the user's assets. While the assets may be recorded on the blockchain, the user may not be able to access them without the private key.

Tokens

A token may refer to an entry in the blockchain that belongs to a blockchain address. The entry may comprise information indicating ownership of an asset. The token may represent money, a contract, property, records, access rights, status, supply, demand, alarm, trigger, reputation, ticket, or any other asset that may be represented in digital form. For example, a token may refer to an entry related to cryptocurrency that is used for a specific purpose or may represent ownership of a real-world asset, such as Fiat currency or real-estate. Token contracts refer to cryptographic tokens that represent a set of rules that are encoded in a smart contract. The person that owns the private key corresponding to the blockchain address may access the tokens at the address. Thus, the blockchain address may represent an identity of the person that owns the tokens. Only the owner of the blockchain address may send the token to another person. The tokens may be accessible to the owner via the owner's wallet. The owner of a token may send or transfer the token to a user via a blockchain transaction. For example, the owner may sign the transaction corresponding to the transfer of the token with the private key. When the token is received by the user, the token may be recorded in the blockchain at the blockchain address of the user.

Establishing User Identity

While a digital signature may provide a link between a transaction and an owner of assets being transferred, it may not provide a link to the real identity of the owner. In some cases, the real identity of the owner of the public key corresponding to the digital signature may need to be established. The real identity of an owner of a public key may be verified, for example, based on biometric data, passwords, personal information, etc. Biometric data may comprise any physically identifying information such as fingerprints, face and eye images, voice sample, DNA, human movement, gestures, gait, expressions, heart rate characteristics, temperature, etc.

Publishing and Validating a Block

As discussed above, full nodes 205 may each build their own blocks that include different transactions. A node may build a block by adding validated transactions to the block until the block reaches a certain size that may be specified by the blockchain rules. However, only one of the blocks may be added to the blockchain. The block to be added to the blockchain and the ordering of the blocks may be determined based on a consensus model. In a proof of work model, both nodes may compete to add their respective block to the blockchain by solving a complex mathematical puzzle. For example, such a puzzle may include determining a nonce, as discussed above, such that a hash (using a predetermined hashing algorithm) of the block to be added to the blockchain (including the nonce) has a value that meets a range limitation. If both nodes solve the puzzle at the same time, then a âforkâ may be created. When a full node 205 solves the puzzle, it may publish its block to be validated by the validation nodes 205 of the blockchain network 130 .

In a proof of work consensus model, a node validates a transaction, for example, by running a check or search through the current ledger stored in the blockchain. The node will create a new block for the blockchain that will include the data for one or more validated transactions (see, e.g., block 375 of FIG. 3 ). In a blockchain implementation such as Bitcoin, the size of a block is constrained. Referring back to FIG. 3 , in this example, the block will include a Previous Block Hash 330 representing a hash of what is currently the last block in the blockchain. The block may also include a hash 370 of its own transaction data (e.g., a so-called Merkle hash). According to a particular algorithm, all or selected data from the block may be hashed to create a final hash value. According to an embodiment of the proof of work model, the node will seek to modify the data of the block so that the final hash value is less than a preset value. This is achieved through addition of a data value referred to as a nonce 360 . Because final hash values cannot be predicted based on its input, it is not possible to estimate an appropriate value for the nonce 360 that will result in a final hash value that is less than the pre-set value. Accordingly, in this embodiment, a computationally-intensive operation is needed at the node to determine an appropriate nonce value through a âbrute forceâ trial-and-error method. Once a successful nonce value is determined, the completed block is published to the blockchain network for validation. If validated by a majority of the nodes in the block chain network, the completed block is added to the blockchain at each participating node. When a node's block is not added to the blockchain, the block is discarded and the node proceeds to build a new block. The transactions that were in the discarded block may be returned to a queue and wait to be added to a next block. When a transaction is discarded or returned to the queue, the assets associated with the discarded transaction are not lost, since a record of the assets will exist in the blockchain. However, when a transaction is returned to the queue it causes a delay in completing the transaction. Reducing the time to complete a transaction may be important. A set of blockchain rules, or renumeration/compensation for a node to process the returned transaction may determine how a returned transaction is to be treated going forward. When a transaction is put into a pool then it can have a priority level but then a rule may indicate that the transaction priority level must exceed a threshold level. The priority level of a returned or discarded transaction may be increased. Another way to reduce the time to complete a transaction is to have the system, service provider, participant in the transaction, or merchant pay additional incentive for nodes to process a returned transaction. As an example, a service provider may identify a network of preferred miners based on geography or based on a volume discount perspective. The time to complete a transaction may be optimized by routing a returned transaction to specific preferred nodes. A transaction may be associated with an address that limits which of the preferred nodes will get to process the transaction if it is returned due to its inclusion in a discarded block. A value may be associated with the transaction so that it goes to preferred miners in a specific geographic location. Additionally, returned transactions may be processed based on pre-set rules. For example, a rule may indicate a commitment to process a specific number of returned transactions to receive additional incentive or compensation.

Blockchain Confirmations

After a block comprising a transaction is added to a blockchain, a blockchain confirmation may be generated for the transaction. The blockchain confirmation may be a number of blocks added to the blockchain after the block that includes the transaction. For example, when a transaction is broadcast to the blockchain, there will be no blockchain confirmations associated with the transaction. If the transaction is not validated, then the block comprising the transaction will not be added to the blockchain and the transaction will continue to have no blockchain confirmations associated with it. However, if a block comprising the transaction is validated, then each of the transactions in the block will have a blockchain confirmation associated with the transaction. Thus, a transaction in a block will have one blockchain confirmation associated with it when the block is validated. When the block is added to the blockchain, each of the transactions in the block will have two blockchain confirmations associated with it. As additional validated blocks are added to the blockchain, the number of blockchain confirmations associated with the block will increase. Thus, the number of blockchain confirmations associated with a transaction may indicate a difficulty of overwriting or reversing the transaction A higher valued transaction may require a larger number of blockchain confirmations before the transaction is executed.

Consensus Models

As discussed above, a blockchain network may determine which of the full nodes 205 publishes a next block to the blockchain. In a permissionless blockchain network, the nodes 205 may compete to determine which one publishes the next block. A node 205 may be selected to publish its block as the next block in the blockchain based on consensus model. For example, the selected or winning node 205 may receive a reward, such as a transaction fee, for publishing its block, for example. Various consensus models may be used, for example, a proof of work model, a proof of stake model, a delegated proof of stake model, a round robin model, proof of authority or proof of identity model, and proof of elapsed time model.

In a proof of work model, a node may publish the next block by being the first to solve a computationally intensive mathematical problem (e.g, the mathematical puzzle described above). The solution serves as âproofâ that the node expended an appropriate amount of effort in order to publish the block. The solution may be validated by the full nodes before the block is accepted. The proof of work model, however, may be vulnerable to a 51% attack described below. The proof of stake model is generally less computationally intensive than the proof of work model. Unlike the proof of work model which is open to any node having the computational resources for solving the mathematical problem, the proof of stake model is open to any node that has a stake in the system. The stake may be an amount of cryptocurrency that the blockchain network node (user) may have invested into the system. The likelihood of a node publishing the next block may be proportional to its stake. Since this model utilizes fewer resources, the blockchain may forego a reward as incentive for publishing the next block. The round robin model is generally used by permissioned blockchain networks. Using this model, nodes may take turns to publish new blocks. In the proof of elapsed time model, each publishing node requests a wait time from a secure hardware within their computer system. The publishing node may become idle for the duration of the wait time and then creates and publishes a block to the blockchain network. As an example, in cases where there is a need for speed and/or scalability (e.g. in the context of a corporate environment), a hybrid blockchain network may switch to be between completely or partially permissioned and permissionless. The network may switch based on various factors, such as latency, security, market conditions, etc.

Forks

As discussed above, consensus models may be utilized for determining an order of events on a blockchain, such as which node gets to add the next block and which node's transaction gets verified first. When there is a conflict related to the ordering of events, the result may be a fork in the blockchain. A fork may cause two versions of the blockchain to exist simultaneously. Consensus methods generally resolve conflicts related to the ordering of events and thus, prevent forks from occurring. In some cases, a fork may be unavoidable. For example, with a proof of work consensus model, only one of the nodes competing to solve a puzzle may win by solving its puzzle first. The winning node's block is then validated by the network. If the winning node's block is successfully validated by the network, then it will be the next block added to the blockchain. However, it may be the case that two nodes may end up solving their respective puzzles at the same time. In such a scenario, the blocks of both winning nodes may be broadcast to the network. Since different nodes may receive notifications of a different winning node, the nodes that receive notification of the first node as the winning node may add the first node's block to their copy of the blockchain. Nodes that receive notification of the second node as the winning node may add the second node's block to their copy of the blockchain. This results in two versions of the blockchain or a fork. This type of fork may be resolved by the longest chain rule of the proof of work consensus model. According to the longest chain rule, if two versions of the blockchain exist, then the network the chain with a larger number of blocks may be considered to be the valid blockchain. The other version of the blockchain may be considered as invalid and discarded or orphaned. Since the blocks created by different nodes may include different transactions, a fork may result in a transaction being included in one version of the blockchain and not the other. The transactions that are in a block of a discarded blockchain may be returned to a queue and wait to be added to a next block.

In some cases, forks may result from changes related to the blockchain implementation, for example, changes to the blockchain protocols and/or software. Forks may be more disruptive for permissionless and globally distributed blockchain networks than for private blockchain networks due to their impact on a larger number of users. A change or update to the blockchain implementation that is backwards compatible may result in a soft fork. When there is a soft fork, some nodes may execute the update blockchain implementation while other nodes may not. However, nodes that do not update to the new blockchain implementation may continue to transact with updated nodes.

A change to the blockchain implementation that is not backwards compatible may result in a hard fork. While hard forks are generally intentional, they may also be caused by unintentional software bugs/errors. In such a case, all publishing nodes in the network may need to update to the new blockchain implementation. While publishing nodes that do not update to the new blockchain implementation may continue to publish blocks according to the previous blockchain implementation, these publishing nodes may reject blocks created based on the new blockchain implementation and continue to accept blocks created based on the previous blockchain implementation. Therefore, nodes on different hard fork versions of the blockchain may not be able to interact with one another. If all nodes move to the new blockchain implementation, then the previous version may be discarded or abandoned. However, it may not be practical or feasible to update all nodes in the network to a new blockchain implementation, for example, if the update invalidates specialized hardware utilized by some nodes.

Blockchain Based Applications

The following sections describe various blockchain based systems and uses for trusted blockchain bridges according to various embodiments, although use of trusted blockchain bridges is not limited to such systems and uses.

Cryptocurrency

Cryptocurrency is a medium of exchange that may be created and stored electronically in a blockchain, such as the blockchain 130 a in FIG. 1 . Bitcoin is one example of cryptocurrency, however there are several other cryptocurrencies. Various encryption techniques may be used for creating the units of cryptocurrency and verifying transactions. As an example, the first user 110 may own 10 units of a cryptocurrency. The blockchain 130 a may include a record indicating that the first user 110 owns the 10 units of cryptocurrency. The first user 110 may initiate a transfer of the 10 units of cryptocurrency to the second user 115 via a wallet application executing on the first client device 120 . The wallet application may store and manage a private key of the first user 110 . Examples of the wallet device include a personal computer, a laptop computer, a smartphone, a personal data assistant (PDA), etc.

FIG. 6 A is a flow diagram showing steps of an example method 600 for performing a blockchain transaction between entities, such as the first user 110 of the first client device 120 and the second user 115 of the second client device 125 in FIG. 1 . The steps of the method 600 may be performed by any of the computing devices shown in FIG. 1 . Alternatively or additionally, some or all of the steps of the method 600 may be performed by one or more other computing devices. Steps of the method 600 may be modified, omitted, and/or performed in other orders, and/or other steps added.

At step 605 , the wallet application may generate transaction data for transferring the 10 units of cryptocurrency from the first user 110 to the second user 120 . The wallet application may generate a public key for the transaction using the private key of the first user 110 . In order to indicate that the first user 110 is the originator of the transaction, a digital signature may also be generated for the transaction using the private key of the first user 110 . As discussed with reference to FIG. 4 , the transaction data may include information, such as a blockchain address of the sender 430 , the digital signature 455 , transaction output information 460 , and the public key of the sender 415 . The transaction data may be sent to the server 150 from the first client device 125 .

The server 150 may receive the transaction data from the first client device 125 . At step 610 , the server 150 may broadcast the transaction to the blockchain network 130 a . The transaction may be received by one or more nodes 205 of the blockchain network 130 a . At step 615 , upon receiving the transaction, a node 205 may choose to validate the transaction, for example, based on transaction fees associated with the transaction. If the transaction is not selected for validation by any of the nodes 205 , then the transaction may be placed in a queue and wait to be selected by a node 205 .

At step 620 , each of the nodes 205 that selected the transaction may validate the transaction. Validating the transaction may include determining whether the transaction is legal or conforms to a pre-defined set of rules for that transaction, establishing user authenticity, and establishing transaction data integrity. At step 625 , if the transaction is successfully validated by a node 205 , the validated transaction is added to a block being constructed by that node 205 . As discussed above, since different nodes 205 may choose to validate different transactions, different nodes 205 may build or assemble a block comprising different validated transactions. Thus, the transaction associated with the first user 110 transferring 10 units of cryptocurrency to the second user 115 may be included in some blocks and not others.

At step 635 , the blockchain network 130 a may wait for a block to be published. Validated transactions may be added to the block being assembled by a node 205 until it reaches a minimum size specified by the blockchain. If the blockchain network 130 a utilizes a proof of work consensus model, then the nodes 205 may compete for the right to add their respective blocks to the blockchain by solving a complex mathematical puzzle. The node 205 that solves its puzzle first wins the right to publish its block. As compensation, the winning node may be awarded a transaction fee associated with the transaction (e.g., from the wallet of the first user 110 ). Alternatively, or in addition, the winning node may be awarded compensation as an amount of cryptocurrency added to an account associated with the winning node from the blockchain network (e.g., ânewâ units of cryptocurrency entering circulation). This latter method of compensation and releasing new units of cryptocurrency into circulation is sometimes referred to as âmining.â At step 640 , if a block has not been published, then the process 600 returns to step 635 and waits for a block to be published. However, at step 640 , if a block has been published, then the process 600 proceeds to step 645 .

At step 645 , the published block is broadcast to the blockchain network 130 a for validation. At step 650 , if the block is validated by a majority of the nodes 205 , then at step 655 , the validated block is added to the blockchain 220 . However, at step 650 , if the block is not validated by a majority of the

CLAIMS

Claims ( 20 )

The invention claimed is:

1 . A system, comprising:

a non-transitory memory; and one or more hardware processors coupled with the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising:

transmitting a transaction request from a first blockchain network to a second blockchain network, wherein the transaction request is associated with a transaction for exchanging a first digital item associated with the first blockchain network with a second digital item associated with the second blockchain network;

processing, by a computer node associated with the first blockchain network, the transaction using a first protocol of the first blockchain network;

processing, by the computer node, the transaction using a second protocol of the second blockchain network;

verifying, by the computer node, an equivalent processing provided by the second blockchain network based on an output from the processing the transaction using the second protocol; and

establishing a bridge between the first blockchain network and the second blockchain network based on the verifying.

2 . The system of claim 1 , wherein the second protocol is different from the first protocol.

3 . The system of claim 1 , wherein the operations further comprise:

providing, within the first blockchain network, a first sandbox environment that enables a second computer node of the second blockchain network to process the transaction using the first protocol.

4 . The system of claim 3 , wherein the processing the transaction using the second protocol is performed within a second sandbox environment associated with the second blockchain network.

5 . The system of claim 1 , wherein the first digital item comprises a first token in a first cryptocurrency associated with the first blockchain network, and wherein the second digital item comprises a second token in a second cryptocurrency associated with the second blockchain network.

6 . The system of claim 1 , wherein the operations further comprise:

digitally signing a bridge agreement between the first blockchain network and the second blockchain network using an encryption key associated with the first blockchain network; and broadcasting the bridge agreement to a plurality of computer nodes within the first blockchain network.

7 . The system of claim 1 , wherein the operations further comprise:

conducting a cross-network transaction between the first blockchain network and the second blockchain network via the bridge.

8 . A method, comprising:

receiving a first transaction request from a user device, wherein the first transaction request is associated with a first transaction that involves a first digital item associated with a first blockchain network with a second digital item associated with a second blockchain network; and processing, by a computer node associated with the first blockchain network, the first transaction via a bridge established between the first blockchain network and the second blockchain network, wherein the bridge is established based on verifying an equivalent processing provided by the second blockchain network using a first output generated by processing a second transaction using a first protocol associated with the first blockchain network and a second output generated by processing the second transaction using a second protocol associated with the second blockchain network.

9 . The method of claim 8 , wherein the processing the second transaction using the second protocol associated with the second blockchain network is performed within a sandbox environment within the second blockchain network.

10 . The method of claim 8 , wherein the bridge is one of a plurality of bridges established between the first blockchain network and the second blockchain network.

11 . The method of claim 10 , further comprising:

determining a transaction type associated with the first transaction; and selecting, from the plurality of bridges, the bridge for processing the first transaction based on the transaction type.

12 . The method of claim 8 , wherein the first digital item comprises a first token in a first cryptocurrency associated with the first blockchain network, and wherein the second digital item comprises a second token in a second cryptocurrency associated with the second blockchain network.

13 . The method of claim 8 , further comprising:

14 . The method of claim 8 , wherein the bridge is a two-way polling service bridge.

15 . A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine associated with a first blockchain network to perform operations comprising:

transmitting a transaction request from a first blockchain network to a second blockchain network, wherein the transaction request is associated with a transaction that involves a first digital item associated with the first blockchain network with a second digital item associated with the second blockchain network; processing the transaction using a first protocol of the first blockchain network; processing the transaction using a second protocol of the second blockchain network; verifying an equivalent processing provided by the second blockchain network based on an output from the processing the transaction using the second protocol; and establishing a bridge between the first blockchain network and the second blockchain network based on the verifying.

16 . The non-transitory machine-readable medium of claim 15 , wherein the second protocol is different from the first protocol.

17 . The non-transitory machine-readable medium of claim 15 , wherein the operations further comprise:

providing, within the first blockchain network, a first sandbox environment that enables a computer node of the second blockchain network to process the transaction using the first protocol.

18 . The non-transitory machine-readable medium of claim 17 , wherein the processing the transaction using the second protocol is performed within a second sandbox environment associated with the second blockchain network.

19 . The non-transitory machine-readable medium of claim 15 , wherein the first digital item comprises a first token in a first cryptocurrency associated with the first blockchain network, and wherein the second digital item comprises a second token in a second cryptocurrency associated with the second blockchain network.

20 . The non-transitory machine-readable medium of claim 15 , wherein the operations further comprise:

conducting a cross-network transaction between the first blockchain network and the second blockchain network via the bridge.

US18/401,113

2021-08-25

2023-12-29

Universally trusted bridges for heterogenous blockchain networks

Active

2042-04-18

US12676756B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US18/401,113

US12676756B2

( en )

2021-08-25

2023-12-29

Universally trusted bridges for heterogenous blockchain networks

Applications Claiming Priority (2)

Application Number

Priority Date

Filing Date

Title

US17/412,132

US11888991B2

( en )

2021-08-25

Universally trusted bridges for heterogenous blockchain networks

US18/401,113

US12676756B2

( en )

2021-08-25

2023-12-29

Universally trusted bridges for heterogenous blockchain networks

Related Parent Applications (1)

Application Number

Title

Priority Date

Filing Date

US17/412,132

Continuation

US11888991B2

( en )

2021-08-25

Universally trusted bridges for heterogenous blockchain networks

Publications (2)

Publication Number

Publication Date

US20240205019A1

US20240205019A1 ( en )

2024-06-20

US12676756B2

true

US12676756B2 ( en )

2026-07-07

Family

ID=85385751

Family Applications (2)

Application Number

Title

Priority Date

Filing Date

US17/412,132

Active

2042-07-21

US11888991B2

( en )

2021-08-25

Universally trusted bridges for heterogenous blockchain networks

US18/401,113

Active

2042-04-18

US12676756B2

( en )

2021-08-25

2023-12-29

Universally trusted bridges for heterogenous blockchain networks

Family Applications Before (1)

Application Number

Title

Priority Date

Filing Date

US17/412,132

Active

2042-07-21

US11888991B2

( en )

2021-08-25

Universally trusted bridges for heterogenous blockchain networks

Country Status (1)

Country

Link

( 2 )

US11888991B2

( en )

Families Citing this family (17)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

WO2021039453A1

( en )

2019-08-29

2021-03-04

Control method, server, and program

US12587397B2

( en )

2021-04-20

2026-03-24

Angel Time Co., Ltd.

Multi dimension blockchain

US11888991B2

( en )

2021-08-25

2024-01-30

Paypal, Inc.

Universally trusted bridges for heterogenous blockchain networks

WO2022220862A1

( en )

2021-09-14

2022-10-20

Futurewei Technologies, Inc.

System and methods of verifiable smart contract as a service

CN115834590A

( en )

2021-09-15

2023-03-21

åä¸ºææ¯æéå¬å¸

Block chain system

CN113810185B

( en )

2021-09-17

2022-09-27

åä¸ç§æå¤§å¦

Anti-trapdoor leakage on-chain data restoration system and method

KR102610011B1

( en )

2021-10-21

2023-12-04

ê³ ë ¤ëíêµ ì°ííë ¥ë¨

Method for reducing smart contract fee of dapp, recording medium and compute server for performing the method

CN116126480B

( en )

2021-11-15

2026-07-21

è¾è®¯ç§æï¼æ·±å³ï¼æéå¬å¸

Cross-region block chain processing method and device for transaction, intelligent equipment, medium and product

US12627514B2

( en )

2021-11-29

2026-05-12

Kishore Swaminathan

Event-locked messages with provable attestation

US20230206216A1

( en )

2021-12-23

2023-06-29

Pangee, Inc.

Blockchain bridge systems, methods, and storage media for trading non- fungible token

WO2023168970A1

( en )

2022-03-10

2023-09-14

åä¸ºäºè®¡ç®ææ¯æéå¬å¸

Method for managing blockchain network, and related device

US12219076B2

( en )

2022-06-15

2025-02-04

Coinbase, Inc.

Systems and methods for mitigating network congestion on blockchain networks by supporting blockchain operations through off-chain interactions

US12556416B2

( en )

2023-10-27

2026-02-17

Jinan University

Method and system for atomic, consistent and accountable cross-chain rewriting

US12475442B2

( en )

2023-12-01

2025-11-18

Halliday International, Inc.

Blockchain interoperability system

WO2025122312A1

( en )

2023-12-08

2025-06-12

Ava Labs, Inc.

Cross-chain transaction signing

US20250371527A1

( en )

2024-05-31

2025-12-04

Bank Of America Corporation

Intelligent system and method to derive a normalized consent protocol for heterogeneous distributed ledger leveraging neuro-symbolic artificial intelligence (ai)

CN119558974B

( en )

2024-11-29

2025-08-26

ä¸å¤®è´¢ç»å¤§å¦

A blockchain asset cyclic cross-chain exchange method based on chameleon hashing

Citations (10)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20190238316A1

( en )

2018-01-31

2019-08-01

Salesforce.Com, Inc.

Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment

US20190245697A1

( en )

2018-02-05

2019-08-08

Nokia Technologies Oy

Securing blockchain access through a gateway

US20200065763A1

( en )

2018-08-22

2020-02-27

Equinix, Inc.

Smart contract interpreter

US20200364212A1

( en )

2019-05-17

2020-11-19

Samsung Sds Co., Ltd.

System and method of supporting reflection of transactions between blockchain networks

US20200402025A1

( en )

2019-06-21

2020-12-24

Skychain Co., Ltd.

Escrowing system for cross-blockchain third-party settlement and method thereof

US20210160252A1

( en )

2018-11-16

2021-05-27

Advanced New Technologies Co., Ltd.

Cross-blockchain interaction systems

US20210157875A1

( en )

2018-10-26

2021-05-27

Advanced New Technologies Co., Ltd.

Blockchain-based cross-chain data access method and apparatus

US20210272075A1

( en )

2020-02-28

2021-09-02

nChain Holdings Limited

Methods and devices for controlling a mining pool for multiple blockchain networks

US20220147999A1

( en )

2019-07-26

2022-05-12

Huawei Technologies Co., Ltd.

Cross-chain transaction method and apparatus

US11888991B2

( en )

2021-08-25

2024-01-30

Paypal, Inc.

Universally trusted bridges for heterogenous blockchain networks

2021

2021-08-25

US17/412,132

patent/US11888991B2/en

active

Active

2023

2023-12-29

US18/401,113

patent/US12676756B2/en

active

Active

Patent Citations (10)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20190238316A1

( en )

2018-01-31

2019-08-01

Salesforce.Com, Inc.

Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment

US20190245697A1

( en )

2018-02-05

2019-08-08

Nokia Technologies Oy

Securing blockchain access through a gateway

US20200065763A1

( en )

2018-08-22

2020-02-27

Equinix, Inc.

Smart contract interpreter

US20210157875A1

( en )

2018-10-26

2021-05-27

Advanced New Technologies Co., Ltd.

Blockchain-based cross-chain data access method and apparatus

US20210160252A1

( en )

2018-11-16

2021-05-27

Advanced New Technologies Co., Ltd.

Cross-blockchain interaction systems

US20200364212A1

( en )

2019-05-17

2020-11-19

Samsung Sds Co., Ltd.

System and method of supporting reflection of transactions between blockchain networks

US20200402025A1

( en )

2019-06-21

2020-12-24

Skychain Co., Ltd.

Escrowing system for cross-blockchain third-party settlement and method thereof

US20220147999A1

( en )

2019-07-26

2022-05-12

Huawei Technologies Co., Ltd.

Cross-chain transaction method and apparatus

US20210272075A1

( en )

2020-02-28

2021-09-02

nChain Holdings Limited

Methods and devices for controlling a mining pool for multiple blockchain networks

US11888991B2

( en )

2021-08-25

2024-01-30

Paypal, Inc.

Universally trusted bridges for heterogenous blockchain networks

Also Published As

Publication number

Publication date

US20240205019A1

( en )

2024-06-20

US11888991B2

( en )

2024-01-30

US20230073337A1

( en )

2023-03-09

Legal Events

Date

Code

Title

Description

2023-12-29

FEPP

Fee payment procedure

Free format text : ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

2024-03-05

Assignment

Owner name : PAYPAL, INC., CALIFORNIA

Free format text : ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHAN, MICHAEL JIM TIEN;GUNDAVELLI, SURYATEJ;BACVANSKI, VLADIMIR;AND OTHERS;SIGNING DATES FROM 20210820 TO 20210825;REEL/FRAME:066655/0548

2024-03-14

STPP

Information on status: patent application and granting procedure in general

Free format text : DOCKETED NEW CASE - READY FOR EXAMINATION

2025-10-18

STPP

Information on status: patent application and granting procedure in general

Free format text : NON FINAL ACTION COUNTED, NOT YET MAILED

2025-10-21

STPP

Information on status: patent application and granting procedure in general

Free format text : NON FINAL ACTION MAILED

2026-01-06

STPP

Information on status: patent application and granting procedure in general

Free format text : RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

2026-01-18

STPP

Information on status: patent application and granting procedure in general

Free format text : RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

2026-03-10

STPP

Information on status: patent application and granting procedure in general

Free format text : ALLOWED -- NOTICE OF ALLOWANCE NOT YET MAILED

2026-03-11

STPP

Information on status: patent application and granting procedure in general

Free format text : NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

2026-06-10

STPP

Information on status: patent application and granting procedure in general

Free format text : PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED

Free format text : PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

2026-06-24

STCF

Information on status: patent grant

Free format text : PATENTED CASE

Universally trusted bridges for heterogenous blockchain networks — Paypal, Inc. (US12676756B2)

Analyze & explore related research in Conceptio

Related documents