Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q2220/00—Business processing using cryptography

Definitions

• the present invention generally relates to the field of blockchain validation.
• the process often referred to as a consensus process, validates the integrity of new transactions, the electronic blocks that the new transactions may be consolidated into before being added to a blockchain, and further validates the integrity of the resulting updated blockchain.
• the present invention relates to systems implemented within blockchain environments where the transacting parties“trust” each other, where trust may be one or more of (a) knowledge of the other parties, (b) trust in available recourse should the transaction not be completed as intended, or (c) ability to verify the accuracy and
• protocol-based validation of transactions operates to verify new transactions prior to being appended to an electronic blockchain.
• An objective of cryptocurrency protocols such as Bitcoin is to maintain a live transaction ledger capable of defending against double-spend attacks from a malicious Byzantine Generals attack by actors who may wish to deviate from the accepted protocol.
• Bitcoin In order to support the anonymity (more accurately, pseudonymity) of transacting parties while avoiding the hegemony of having an“owner” of the ledger, Bitcoin employs a decentralized validation process wherein consensus of the Bitcoin transaction ledger is secured by a network of miners. These miners are incentivized to participate in the consensus process through a schedule of rewards for providing consensus confirmation relating to blocks to be appended to the blockchain.
• the work of the miners, or the mining includes a proof-of-work calculation that is designed to be so difficult and resource complex, as to make it costly for any one miner— or attacker— to create multiple accounts to attempt to gain control of, or divert the blockchain.
• miners are rewarded approximately $1,500,000 each day to secure the blockchain. It has been noted that a significant portion of that money is spent solely on electricity to power the necessary processing of the proof-of-work calculations.
• proof-of-work based consensus protocols are slow, requiring up to an hour to reasonably confirm a payment to prevent double-spending. See Jae Kwon, “Tendermint: Consensus Without Mining,” Draft V0.6,
• End-user or consumer marketplaces that use blockchain technology e.g., many crypto-currencies
• blockchain technology e.g., many crypto-currencies
• This decentralization or distributed market is an incentive to many customers. Indeed, many such markets are intentionally designed to support anonymous, untrusted participants.
• permissionless miners is used by Bitcoin and was the original approach envisioned to ensure the integrity of transaction blocks added to the blockchain log or ledger.
• the approach also allows certain blocks to be rolled back. This“undoing” of certain blocks of the blockchain provides an additional level of assurance to the integrity of the overall blockchain, in case collusion is discovered in a validated block. But it further delays final validation of a transaction.
• enterprise marketplaces In comparison to an open currency, decentralized-type market like Bitcoin, enterprise marketplaces (e.g., financial market clearing systems) are typically centralized. They serve both anonymous and identified, but untrusting, participants. Because of their centralization, they can be served by a more cost-efficient permissioned ledger system. In such a permissioned system, a central authority vets and assigns the system validators, but the validation process remains distributed among these validators who still must achieve consensus to approve a transaction block. Rather than paying large rewards, these identified and vetted validators can be paid simple salaries. In addition, because the central authority has a higher level of trust in its permissioned agents, the validation process can be shortened and the chance or need for roll-back reduced.
• the described systems and methods provide applications in which transactions are conducted among participants who are known and trusted by each other (or, in the absence of a sufficient level of trust, the participants have sufficient recourse to rectify misrepresentation or misconduct by one or more parties).
• the disclosed systems and methods create an efficient automated, protocol-based system that assembles blocks to be added to the blockchain by following a computer-readable protocol to validate transactions, without requiring the intervention of numerous agents to arrive at a consensus.
• the incentives offered to consensus participants differ between the models.
• the permissionless system offers a high reward to justify the cost of competing to win the reward.
• the permissioned systems typically pay a fixed salary to known, vetted agents.
• The‘771 patent discloses methods and systems for securely storing and retrieving one or more blocks for a blockchain using a modified Galois Fields on a cloud or peer-to-peer communications network. More particularly, the‘771 patent appears to focus on the use of Galois Fields to enhance security for storing and retrieving electronic data on a cloud communications network. The‘771 patent does not appear to disclose or suggest a method for automated, protocol -based validation of the integrity of transactions prior to appending records of the transactions to a block or directly to a parent blockchain.
• The‘801 application teaches a computer system that communicates with a distributed blockchain computing system that includes multiple computing nodes.
• An apparent core element and step of the‘801 application methodology is the monitoring process and generation of transactions dependent upon determining when two separate transactions are validated to form a recorded exchange of transactions (e.g., one transaction from A to B and another from B to A). If one of the parties fails to submit a transaction or the submitted transaction fails, then the computer system may generate a new blockchain transaction that revokes the other one of the two related transactions.
• The‘801 application accordingly appears to depend on a matching of separate transaction records. This creates several problems. First, each complete transaction requires a minimum of two component transactions. This requires additional processing time as well as causing the blockchain to grow larger and at a faster pace. Second, when an initial transaction needs to be nullified, the completed transaction requires the processing of, at least, four component transactions - further exacerbating the drain on both performance and scalability. Finally, the Fay et al. process does not provide a method or system for automatic, protocol -based validation of a completed transaction. By way of example, in Fay et al. where an initial transaction component may need to be reversed or undone, the process could not be handled automatically because it is impossible to have a protocol -based process anticipate all potential revisions.
• the present invention overcomes the disadvantages of the prior art and fulfills the needs described above by providing systems and methods for validating the integrity of transactions before the recordation of the validated transactions into an electronic blockchain.
• a preferred embodiment of the invention is a protocol-based method for validating the integrity of electronic records of transactions before said records are added to an electronic block in an electronic blockchain, the protocol comprising the steps of (a) obtaining a first confirmation from at least one first party to transfer an asset as part of a transaction that each said first party agrees with at least one term of said transaction; (b) obtaining a second confirmation from at least one second party to receive an asset as part of said transaction that each said second party has verified each said first party’s respective agreement with at least one term of said transaction; (c) creating a validated electronic record of said transaction based upon receipt of said first and second confirmations; (d) adding said validated electronic record to a block of electronic transactions; and (e) adding said block of electronic transactions to said blockchain.
• a further preferred embodiment of the invention is a method for validating the integrity of electronic records within a block before said block is added to an electronic blockchain using a protocol-based set of instructions, comprising the steps of (a) validating that all electronic recordations included in a block, where said electronic recordations relate to at least one condition of at least one underlying transaction, have been confirmed by at least one transferring party and at least one receiving party to said at least one underlying transaction; and (b) adding said validated block to said electronic blockchain.
• a still further preferred embodiment of the invention is a computerized system computerized system for validating the integrity of electronic records of transactions before said records are added to an electronic block in an electronic blockchain, said system comprising (a) at least one computer server; (b) a plurality of terminals, each of said plurality of terminals being associated with a first and second plurality of parties each associated with a transaction; and (c) machine readable instructions stored on said at least one computer server, and said machine readable instructions when executed manages a blockchain data structure associated with said transaction and causes said at least one computer server to execute the steps of:
• Fig. 1 is an overview system diagram showing the key participants and elements relevant to an exemplary embodiment of the inventive system for validating transactions to be maintained on an electronic blockchain.
• Fig. 2 is another system block diagram of an exemplary embodiment of the primary system elements and the communication flow within the inventive system.
• Fig. 3 is a system flowchart illustration of an exemplary embodiment of certain steps of the inventive methodology providing an example overview of the process flow.
• Fig. 4 is another system flowchart illustration of an exemplary embodiment of certain steps of the inventive methodology including registration of the transferors and transferee.
• FIG. 1 An embodiment of the inventive methodologies and systems is illustrated in Fig. 1, showing relevant participants of a transferor (or seller) 70, a transferee (or recipient or buyer) 90, each with a computer terminal or computer input/output device, with each such device in communicative connection with a blockchain server 30
• the term “seller” or“transferor” may include an entity exchanging an asset for cash or some other form of compensation, or may merely be transferring custody of an asset (such as legal evidence) to another entity.
• the term“buyer” or“transferee” or“recipient” may include an entity purchasing an asset for cash or some other form of compensation, or may be receiving temporary or final custody of an asset (such as legal evidence) from another entity, including as an intermediary, such as a shipper or courier service.
• the term“asset” is intended to broadly cover any product, material, device component, package, and / or physical or electronic document or file, including virtual assets such as data, electronic files, intangible assets (such as domain names, various intellectual property, trademarks, or copyrights), or even crypto-currencies.
• the term“blockchain” is used herein to refer to any technology that allows for the creation of a non-repudiatable transaction record or ledger that is resistant to falsification.
• a core or primary element of the innovative system is the use of a protocol-implemented methodology to verify (or confirm) aspects of a transaction between a transferor and recipient.
• the methodology at its core entails (a) verification by a transferor of an asset about a term relating to the transaction, (b) verification by a recipient of an asset of the transferor verified term, (c) validation of the completed transaction based upon the parties’ verifications prior to appending a record of the transaction to the blockchain.
• the disclosed process and underlying technology serves to create a non-repudiatable, and verifiable, electronic log of the transaction. The electronic log is confirmed / affirmed through use of secure identifiers provided to and maintained by each of the system users.
• the secure identifiers are used by each of the several asset custody holders whenever the custody holders create, transfer, or receive an asset. Such secure identifiers are also used by any other parties who may witness the transaction.
• a blockchain is an electronic ledger of transactions.
• the blockchain or ledger“grows” as “completed” blocks, which correspond to new transactions (e.g., changes of custody or ownership) are added to the blockchain.
• the new transactions are grouped into blocks and the new blocks are then added or appended to the blockchain only after each new block undergoes a validation process.
• the new block validations are undertaken by a consensus process that requires multiple agents, typically unrelated to the transaction, to reach a consensus on the accuracy of the transactions and blocks before they are added to the blockchain, which again may be a parent blockchain.
• the block validation process is an automated, protocol-based process, thereby greatly reducing operating cost of the distributed ledger, and increasing the performance of the system (i.e., the number of transactions that can be processed in a given amount of time is greatly increased, and time required before a transaction can be validated may be substantially reduced).
• Fig. 2 shows the basic functional components of an exemplary embodiment of the system 100 in a sales transaction of an asset.
• the seller e.g., a manufacturer
• seeks to sell some of its products to a buyer e.g., one of its regular distributors.
• buyer e.g., one of its regular distributors
• each of the transacting parties is known to the other.
• the transferor uses terminal 10 to authenticate his identity through an authentication service 15 trusted by the transferee.
• Terminal 10 may be, by way of example a desktop computer, tablet computer, mobile phone, or any other similar type of computer input-output device.
• the authentication service 15 may be part of the offering of the blockchain provider or it may merely be an independent service accepted by both the transferee and the blockchain provider.
• the authentication service 15 then provides authentication to the blockchain server 30, which then affords the transferor access to the blockchain server 30.
• the transferee similarly, uses his terminal 20 to authenticate his identity through an authentication service 25.
• the transferee’s authentication service 25 may be the same service as the transferor, or transferee’s authentication service may be a different service that is accepted by the transferor and the blockchain provider.
• the authentication service for the transferee 25 provides its authentication to the blockchain server 30, thereby affording the transferee access to the blockchain server 30.
• the transferor uploads a digitally signed transaction 18 (such as an invoice or bill of lading) to the blockchain server 30.
• the digital transaction 18 would include a listing of the products included in the transaction. Also included in the digital transaction 18 data is, at least, the name of the transferee(s) or the recipient of the products listed on the invoice.
• the blockchain server 30 then alerts the transferee that a transaction is awaiting validation.
• the digital transaction 18 is not necessarily transmitted to the transferee, but he or she is alerted to the recording of a transaction that the transferee can access by logging into the blockchain server 30 and view same digital transaction 18. In some embodiments, as illustrated in Fig.
• the blockchain server 30 may consist of separate servers 30a, 30b, 30c, (1) to manage the transaction prior to adding it to a block, (2) to validate the transaction, (3) to add the validated transaction to a block, (4) to validate the block prior to appending it to the blockchain, and/or (5) add the validated block to the blockchain.
• the transferee reviews the identified and alerted transaction on the blockchain server 30. If the transferee agrees that the product(s) received match the products included in the digital transaction 18 specified by the transferor, the transferee then digitally uploads or signs a digital transaction 28 on the blockchain server 30. Upon the uploading or signing of the digital transaction 28 by the transferee, the transaction has been validated. More specifically, because both the transferee and transferor know each other, and/or have a sufficient level of trust of each other, upon receipt and recordation of confirmation that the products shipped are the same as the products received, as evidenced by the digital signatures of both transferor and transferee, there is no need for further independent validation or confirmation of the transaction. Accordingly, the transaction can then be added to a block to be appended to the blockchain 35, or the transaction may be directly appended to the blockchain 35.
• the blockchain server 30 and the blockchain 35 may be replicated to allow for multiple copies of the blockchain server 30, 30a, 30b, 30c and multiple copies of the blockchain 35, 35a, 35b, 35c to allow for processing of each transaction concurrently in parallel.
• a redundant system architecture eliminates the problem that either component (the blockchain server 30 or blockchain 35) would be a single point of failure.
• an automated, protocol-based consensus algorithm would be implemented within each blockchain server 30 to compare results of the calculations, and to discard any calculations, or vote out any blockchain servers 30 that differ from the majority of the remaining blockchain servers 30.
• the comparison and voting process is automated, protocol -based and does not require the intervention of separate or independent agents.
• multiple independent blockchain servers could be implemented to handle distinct asset transactions, such as one blockchain for wine and another for handbags.
• Fig. 3 depicts an exemplary embodiment of the process flow as disclosed above relating to Fig. 2. More particularly, the transferor authenticates 115 his identity to the system through the authentication server 15. The transferor then defines the contents of the transaction 116 and digitally signs the transaction 18 and uploads it to the blockchain server 118 to indicate that the transaction document 18 (e.g., an invoice) accurately reflects the products and/or services being provided to the transferee. The transferee also authenticates his identity to the system l25.to the blockchain server 30 either through a separate authentication service 25, or the same
• each of the transferors if there are multiple transferors of elements of an asset to be transferred, registers 135 with the system, and likewise the transferee registers 145 with the system. Registration 135, 145 can occur using distinct registration services 12 or an agreed upon single registration service 12, as shown in Fig. 1,
• the blockchain server 30 then alerts the transferee of a transaction awaiting his approval 132, and the transferee reviews and verifies 227 the transaction 18 details (e.g., comparing items received to items invoiced) on the blockchain server 30. If all is in order, the transferee appends 228 his digital signature to the transaction 28 on the blockchain server 30. Having received concurrence from both parties that the transaction is approved as specified, the blockchain server 30 is then able to add the transaction to a block 332, and then appends 335 the new block to the blockchain 35.
• the transferee disputes the accuracy of the invoice 18.
• the transferee specifies the discrepancies with the transaction on the blockchain server 30.
• the blockchain server 30 provides an alert to the transferor that the identified discrepancies require review by at least the transferor.
• the transferor has several options.
• the transferor can modify the prior transaction 18 to address the discrepancies noted by the transferee and alerted by the blockchain server 30, and sign a new transaction l8a.
• the original transaction 18 that was proffered by the transferor, but not approved by the transferee may be, but need not be, recorded in a data structure that may be within or part of the subject blockchain.
• the transferor can negotiate the discrepancies with the transferee. If there is a negotiation between the transferor and transferee, and the transferee accepts the original transaction 18, then the transferee merely digitally signs the transaction 28. If, however the original transaction 18 is changed in any way, the transferor must sign the revised transaction l8a and obtain the transferee's signature before the recorded transaction l8a may be added to a new block.
• the blockchain server 30 may or may not keep track of, and record the history of negotiated or revised transactions before they are added to a block. For certain uses, a record or all negotiations and/or revised transaction information may need to be retained and recorded within the blockchain.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Business, Economics & Management (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Theoretical Computer Science (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Human Resources & Organizations (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Finance (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (5)

Applications Claiming Priority (1)

Publications (1)

Family

ID=68983801

Family Applications (1)

Country Status (4)

Cited By (1)

Families Citing this family (1)

Citations (2)

Family Cites Families (7)

• 2018
  • 2018-06-22 EP EP18923478.4A patent/EP3811581A4/en active Pending
  • 2018-06-22 CN CN201880094976.6A patent/CN112400298B/zh active Active
  • 2018-06-22 WO PCT/US2018/038957 patent/WO2019245577A1/en active Application Filing
  • 2018-06-22 JP JP2020565955A patent/JP7179300B2/ja active Active
• 2022
  • 2022-11-08 JP JP2022178851A patent/JP2023015223A/ja active Pending

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events