Blockchain Interoperability Innovation Insights from Patents
•
0 likes•499 views
Patents are a good information resource for obtaining the state of the art of blockchain interoperability technology innovation insights. I. Blockchain Interoperability Technology Innovation Status Patents that specifically describe the major blockchain interoperability technologies are a good indicator of the blockchain interoperability innovations in a specific innovation entity. To find blockchain interoperability technology innovation status, patent applications in the USPTO as of June 15, 2020 that specifically describe the major blockchain interoperability technologies are searched and reviewed. 28 published patent applications that are related to the key blockchain interoperability technology innovation are selected for detail analysis. II. Blockchain Interoperability Technology Innovation Details Patent information can provide many valuable insights that can be exploited for developing and implementing new technologies. Patents can also be exploited to identify new product/service development opportunities. Interoperability Smart Contract / US20200099533 (Accenture) Transferring Digital Asset Using Sidechain / US20160330034 (Blockstream Corp)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Blockchain Interoperability Innovation Insights from Patents
Similar to Blockchain Interoperability Innovation Insights from Patents (20)
More from Alex G. Lee, Ph.D. Esq. CLP
More from Alex G. Lee, Ph.D. Esq. CLP (20)
Recently uploaded
Recently uploaded (20)
Blockchain Interoperability Innovation Insights from Patents
- 1. 1 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ Blockchain Interoperability Innovation Insights from Patents Alex G. Lee1 Patents are a good information resource for obtaining the state of the art of blockchain interoperability technology innovation insights. I. Blockchain Interoperability Technology Innovation Status Patents that specifically describe the major blockchain interoperability technologies are a good indicator of the blockchain interoperability innovations in a specific innovation entity. To find blockchain interoperability technology innovation status, patent applications in the USPTO as of June 15, 2020 that specifically describe the major blockchain interoperability technologies are searched and reviewed. 28 published patent applications that are related to the key blockchain interoperability technology innovation are selected for detail analysis. Following figure shows blockchain interoperability patent application landscape with respect to the innovation entity. As shown in the figure, the key blockchain interoperability innovation entities are Alibaba Group, Accenture, IBM, JPMorgan Chase Bank, Blockstream Co., Intel, Salesforce, Paypal, and Infineon Technology. 1 Alex G. Lee, Ph.D Esq., is a CTO and patent attorney at TechIPm, LLC.
- 3. 3 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ Following figure shows blockchain interoperability patent application landscape with respect to the key technology innovation field. As shown in the figure, Cross-Chain Transaction is the most innovated blockchain interoperability technology followed by Cross-Chain Blockchain Domain Name, Interoperability Node, Cross-Chain Data Operation/Access, Oracle (Blockchain-Nonblockchain Interoperability), Interoperability Smart Contract, Smart Contract Reusability , Cross-Chain Cryptocurrency Swap, Distributed Ledger Gateway, and Interoperable Relay- Chain.
- 5. © A e t y i ©2020 TechIPm, A patent coun evolution of t technology in year) and the interoperabilit LLC All Rights Re nting for grow echnology inn nnovation grow publication d ty technology 0 2 4 6 8 10 12 14 16 18 NumberofPatentApplications eserved http://ww wth in patentin novation. Foll wth trends. Si date by around y innovation a 2015 ww.techipm.com ng over a perio lowing patent ince there is u d two years, th activity is in e 2017 2018 Priority Year / od of times ca t application a usually a time he patent appl arly stage and 2018 2019 r an be a good m activity chart lag between t lication activi d is expected t Interop measuring too shows blockc the initial app ty chart indic to be in rapid perability Patent Appl ol for monitor chain interope plication date ates that block growth stage lications 5 ring the erability (priority kchain e soon.
- 6. 6 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ II. Blockchain Interoperability Technology Innovation Details Patent information can provide many valuable insights that can be exploited for developing and implementing new technologies. Patents can also be exploited to identify new product/service development opportunities. Interoperability Smart Contract / US20200099533 (Accenture) Blockchain interoperability enables multiple distributed ledger networks (DLNs) to provide data sharing, transferring, and synchronization between the DLNs. Following figure illustrates an example of the interoperable blockchain system 100. The system includes blockchain participants 102 that participate in a DLN 104. The blockchain participants 102 include full or partial nodes of the DLN 104. The DLN includes the participants of the DLN that access the blockchain 106. The blockchain 106 includes datablocks 107 that are linked cryptographically. The blockchain participants 102 includes a data furnisher 108 that furnishes particular information stored in the blockchain 106 to the receivers external to the DLN 104. The data receiver 110 includes a non-participant of the DLT network 104 or a participant of a separate DLN. Unlike the data furnisher 108, the data receiver 110 cannot have access to the blockchain 106 for the DLN 104. The data receiver 110 receives the token data stored in the blockchain 106 from the blockchain participants 102, such as the data furnisher 108. The blockchain participants 102 further include a membership service provider 112. The membership service provider 112 provides access to the identities and cryptological information associated with the blockchain participants 102 of the DLN 104. The membership service provider 112 includes a membership service repository 114. The membership service repository 114 includes a database that stores the identities and cryptological
- 7. 7 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ information associated with participants and non-participants of the DLN 104. The identities information includes IP addresses, MAC addresses, host names, user names, and/or any other information that identifies a participant or non-participant of the DLN 104. The cryptological information includes any information that is used to ensure the authenticity of a digital signature such as a public key that corresponds to a private key that is applied to generate a digital signature. The data furnisher 108 and the data receiver 110 communicate with the membership service provider 112 to receive the public key of the data furnisher 108. The data receiver 110 submits a message or query to the membership service provider 112. After receiving the public key, the data receiver 110 verifies the truth of token data shared by or exported from the DLN 104. For example, the data receiver 110 receives authorization information from the data furnisher 108. The authorization information includes a digital signature corresponding to the token data. The digital signature includes a certification that the data furnisher 108 and data receiver 110 consents to a particular action, such as exporting token data. The signer of the digital signature can be confirmed based on the public key that is paired with the private key used to sign the signature. Sharing /exporting information to/with the data receiver 110 present technical challenges: Ability for the data receiver 110 to verify that the token data is valid and authorized for sharing/export; Preventing double spend between the blockchain participants 102 of the DLN 104 and non-participants; and Ensuring synchronization of the token data between participants of the DLN 104 and non-participants of the DLN 104.
- 9. 9 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ In the following figure the data furnisher 108 has access to the furnisher blockchain 210 and the data receiver 110 has access to the receiver blockchain 212. The data furnisher 108 exports token data to the data receiver 110. The exportation of token data involves token data on the furnisher blockchain 210 and committing the token data to the receiver blockchain 212. Before the token data is locked on the furnisher blockchain 210 (adding the data block to the blockchain) and committed to the receiver blockchain 212, various preconditions, authorizations, and data manipulation can occur. The data furnisher 108 includes a furnisher synchronization controller (FSC) 302. The FSC 302 coordinates transfer and exportation of token data to a remote blockchain. For example, the FSC 302 communicates token data stored on the furnisher blockchain 210 to the data receiver 110 for storage on the receiver blockchain 212. The FSC 302 can determine when a successful transfer is completed and lock the token data on the furnisher blockchain 210. The FSC 302 accesses an interoperability smart contract 304 to determine the criteria, conditions, and parameters that dictate exportation of token data between DLNs. The interoperability smart contract 304 includes an authorization to transfer data stored on the furnisher blockchain 210 according to a protocol for asynchronous communication between the furnisher DLN 202, the receiver DLN 204, and/or other DLNs. The interoperability smart contract 304 includes terms, conditions, logic, and other information that the data furnisher 108 and the data receiver 110 agree to. The interoperability smart contract 304 also includes identifiers corresponding to the token data in the furnisher blockchain 210 (data furnisher and data receiver 110 that consent to the export). Additionally, the interoperability smart contract 304 includes a cryptologic committal 306. The cryptologic committal 306 includes commit logic configured to cause the data receiver 110 to commit the data to the receiver blockchain 212.
- 10. 10 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ In general, token data can be considered committed when the token data is appended to the receiver blockchain 212. The commit record identifies the participants, DLNs, token data, and any other information that records the transfer event.
- 11. 11 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ The interoperability smart contract 304 further includes a transfer logic 308. The transfer logic 308 includes logic configured to cause the data receiver 110 to receive, generate, and append the token data to the receiver blockchain 212. For example, the transfer logic 308 can include instructions to require or validate information received by the data receiver 110. The transfer logic 108 determines whether, according to predetermined rules, valid token data is received by the data receiver. The transfer logic 308 also causes the data receiver 110 to re- create the token data in a manner that is compliant with the receiver DLN. The data furnisher 108 recreates the token data based on the transfer logic prior to sending the data to the data receiver. The transfer logic 308 appends the token data to the receiver blockchain 212 for compliance with the receiver DLT. The FSC 302 receives a pre-commit acknowledgement 310. The pre-commit acknowledgement 310 includes a verification that the token data was successfully received and generated by the data receiver 110. The pre-commit acknowledgement 310 indicates that the token data was successfully appended to the receiver blockchain 212. The pre-commit acknowledgement 310 can include digital signatures signed by the data receiver 110. For example, the data receiver 110 can be identified in the interoperability smart contract 304. The digital signatures can verify that the data is properly re-generated and added to the receiver blockchain 212 in compliance with the receiver DLN and the criteria of the interoperability smart contract 304. To synchronize the locking and committal of the token data transferred between DLNs, the FSC 302 encrypts the interoperability smart contract 304 such that the data receiver 110 is initially receives the interoperability smart contract 304 without the ability to perform the commit according to the committal logic. Additionally, the FSC 302 encrypts information that the interoperability smart contract 304 accesses to perform the
- 12. 12 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ committal. For example, the FSC 302 encrypts the cryptological committal, other portions of the interoperability smart contract 304, or information provided to the interoperability smart contract 304 based on a hash function and a committal key 312. In response to receipt of the pre-commit acknowledgement 310, the FSC 302 communicates the comital key to the data receiver 110. The data receiver 110 decrypts the interoperability smart contract 304, or other authorization provided to the interoperability smart contract 304, and performs the committal according the committal logic. Following figure illustrates the flow diagram for example logic of the system 100. The FSC 302 obtains the interoperability smart contract 304 (402). The interoperability smart contract 304 includes the cryptologic committal 306. The interoperability smart contract 304 includes commit logic configured to cause the data receiver 110 to commit the token data to the receiver blockchain 212. The commit logic and the interoperability smart contract 304 can be encrypted based on a predetermined committal key 312. The FSC 302 appends the interoperability smart contract 304 to the furnisher blockchain 210 (404). For example, the FSC 302 can add a datablock to the furnisher blockchain 210 that includes the interoperability smart contract 304. The datablock further includes a hash of a previous datablock stored on the blockchain. The FSC 302 sends the interoperability smart contract 304 to the data receiver (406). For example, the FSC 302 can send the interoperability smart contract 304 to the data receiver 110 and another participant of the receiver DLN 204. The FSC 302 sends the token data with the interoperability smart contract 304. Alternatively, the transfer logic 308 of the interoperability smart contract 304 includes instructions configured to regenerate the token data.
- 13. 13 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ The FSC 302 receives the pre-commit acknowledgment of the interoperability smart contract 304 (408). In response to the pre-commit acknowledgement, the FSC 302 locks the data on the furnisher blockchain 210 (410). The FSC 302 sends the committal key 312 to the data receiver 110, or some other participant of the receiver DLN (412). The data receiver 110 can unencrypt the cryptological committal and perform the committal in response to receipt of the committal key 312.
- 14. 14 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ Transferring Digital Asset Using Sidechain / US20160330034 (Blockstream Corp) A sidechain is a separate blockchain that is attached to its parent blockchain using a two-way peg, which enables interchangeability of digital assets between the parent blockchain and the sidechain. Plasma and Polkadot for Ethereum and RSK for Bitcoin are some good examples of the sidechain. Transfers using the pegged sidechains are atomic; the transfer either happens entirely, or not at all. Another benefit of using pegged sidechains is avoidance of failure modes that result in loss or permit fraudulent creation of assets. Assets are transferred to the pegged sidechains by providing proofs of possession in the transferring transactions themselves, avoiding the need for nodes to track the sending chain. On a high level, when moving assets from one blockchain to another, a transaction is created on the first blockchain locking the assets. A transaction is also created on the second blockchain whose inputs include a cryptographic proof that the lock transaction on the first blockchain was done correctly. These inputs are tagged with an asset type, e.g. the genesis hash of the asset's originating blockchain. A simplified payment verification (SPV) proof is an example of a proof of possession used to transfer assets to a pegged sidechain. A SPV proof can be a DMMS showing that an action occurred on a Bitcoin-like proof-of- work blockchain. "Proof-of-work" refers to how the rules of a chain, which can be part of a blockchain's definition, define how work in that chain is measured. To verify a SPV proof for a particular chain, a verifier must know and understand the chain's rules about how work is generated. Nodes in the network continually performs work to create blocks in a chain. The SPV proof can include (a) a list of blockheaders demonstrating proof-of-work, and (b) a cryptographic proof that an output was created in one of the blocks in the list. Such SPV proofs allow verifiers to
- 15. 15 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ check that some amount of work has been committed to the existence of an output. Such a proof can be invalidated by another proof demonstrating the existence of a chain with more work which does not include the block which created the output, thereby exposing fraudulent transfers. Following figure shows a flow diagram 100 for a symmetric two-way pegged transfer from a parent chain 110 to a sidechain 120. In flow 100, a processor sends a parent chain asset to an output of the parent chain at step 125. The SPV proof associated with the parent chain asset can be generated for the output. The SPV proof includes a threshold level of work, and the generating can take place over a predetermined period of time (confirmation period). The confirmation period of a transfer between chains is a duration for which a coin is locked on the parent chain before it can be transferred to the sidechain. This confirmation period allows for sufficient work to be created such that a denial of service attack in the next waiting period becomes more difficult. The generated sidechain asset is held for a predetermined contest period at step 130, during which the transfer is invalidated if a reorganization proof associated with the parent chain asset is detected in the parent chain. The contest period is a duration in which a newly-transferred coin cannot be spent on the sidechain. The predetermined contest period prevents double-spending in the parent chain by transferring previously-locked coins during a reorganization. If at any point during this delay, a new proof (known as a "reorganization proof") is published containing a chain with more aggregate work which does not include the block in which the lock output was created, the conversion is retroactively invalidated. If no reorganization proof is detected, the sidechain asset can
- 17. 17 ©2020 TechIPm, LLC All Rights Reserved http://www.techipm.com/ To redeem the sidechain asset in the parent chain, the sidechain asset is sent to an output of the sidechain at step 140. A SPV proof associated with the sidechain asset can be generated. A parent chain validator server validates the SPV proof associated with the sidechain asset at step 145. The parent chain asset associated with the sidechain asset also can be held for a second predetermined contest period at step 145, during which a release of the parent chain asset is denied at step 155 if a reorganization proof 150 associated with the sidechain asset is detected in the sidechain. The parent chain asset can be released if no reorganization proof 150 associated with the sidechain asset is detected. In the event of a failure of validation of the second SPV proof, after the reorganization proof 150 is received a second SPV proof 170 associated with the sidechain asset can be received and validated by the parent chain 110 during a third predetermined contest period at step 160. The parent chain asset can be released if no reorganization proof associated with the sidechain asset is detected during the third predetermined contest period, after which the parent chain asset is free to be transferred within the parent chain at step 165.