Detailed Action
Claims 1-14 are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 4-11, and 14 are currently amended.
Response to Remarks
35 U.S.C. § 112
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 101
Applicant argues “As amended, claim 1 recites, inter alia, a validation component operative to coordinate the operations necessary to perform a blockchain block validation (i.e., a cryptographical process) across a number of different validating resources (i.e., a separate physical computing resource) to provide for a distributed and computationally optimized validation process. This is not necessarily a straightforward process and, as such, the claim sets forth explicit actions that must be taken to allow the claimed distributed validation to occur - "allocating respective subsets of the blockchain transactions to a plurality of validating resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree," and "using the plurality of validating resources to validate their respective subsets of blockchain transactions." These are not abstract requirements and represent practical steps and represent a practical application of a method for distributed blockchain block validation. As such, the steps enable the distributed system to operate allowing for substantial system performance and resilience improvements. As described by the present specification, these specific steps enable "many transactions to be processed simultaneously, with the only limit being the amount of hardware available to form the distributed validation node rather than the amount of available processing speed being the bottleneck, as per traditional techniques. This enables blockchain processing systems to scale horizontally without the need to alter the underlying protocol of the blockchain network." Specification, paragraph [0201] - a significant technological improvement. Amended claim 1 further recites at least one mining component operative to facilitate or enable distributed mining of a blockchain block or calculation of a Proof-of-Work (PoW) calculation. Again, the distributed operation can provide significant computer system improvement by increasing system resilience and performance. In this particular case, the distributed mining operation is performed at least in part by "sending, from a first resource to a second resource, a request to generate a PoW calculation for the blockchain block, the request comprising a Merkle proof for verification that a control transaction (TXo) is included in the plurality of transactions." This presents a step requiring computational operations to construct the request that cannot be performed by the human mind and so represents a practical application of the method”. (Applicant Arguments, 2025-10-24). However, the amendments to claim 1 do not overcome rejection as they merely add further data handling and work-distribution details within the same abstract idea, rather than reciting a specific technological improvement to computer functionality or a non-conventional architecture. Indeed, claim 1’s added limitations simply refine which data is sent where and under what condition PoW is performed, but they do not recite any new data structure, cryptographic algorithm, or improvement to the operation of the computer itself, only a more detailed description of how conventional blockchain data structures are used to coordinate validation and mining. Accordingly, this contention is unpersuasive.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “claim 1 describes a computer-implemented system for distributing blockchain- related operations across a plurality of processing resources. Consequently, the invention provides a solution for distributing blockchain operations and functionalities such as Proof-of- work (PoW) calculations, transactions validation, mining and UTXO management across a plurality of dedicated, specialised processing resources. By contrast, Li discloses a system in which a requesting party who lacks extensive
processing capabilities outsources a processor-intensive tasks e.g. an ML task to the system. The system uses a smart contract on a blockchain to "algorithmically select a set of providers e.g. available computing devices for the requested task - [0015]. The system then records performance of the task and the requester's payment for it on the blockchain and also verifies that the result of the computational task return by the set of selected computing devices is correct - [0020]. However, the tasks that the requester asks the system to perform are not blockchain- related operations such as mining, PoW calculation, blockchain transaction validation etc as per claim 1. In short, Li simply does not disclose a solution for distributed performance of blockchain functionalities using a plurality of communicating components.” (Applicant Arguments, 2025-10-24).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Li and Miller) still teach the currently amended independent claims, as shown at least in paragraphs 16, 66, and 191 of Li, paragraphs 160-161, and 163 of Miller, and as further outlined in paragraph 25 of this action. Indeed, Li teaches using a blockchain or smart-contract layer to assign portions of a larger computational task to multiple provider devices and validate their partial results, while Miller teaches organizing a block of transactions as a Merkle tree and using Merkle-dervied subsets (e.g. paths) to prove inclusion of specific transactions. The allocation of respective subset of blockchain transactions corresponding to Merkle subtrees/inner nodes to a plurality of validating resources and having those resources validate their respective subsets is a straightforward application of Li’s distributed processing to Miller’s Merkle-structured transaction data. Further, Li’s pattern of first resource outsourcing intensive computation to a second resource combined with Miller’s use of Merkle proofs to verify that a given transaction is included in a block teaches the sending, from a first resource to a second resource, a request to perform a PoW calculation for a block that includes a Merkle proof confirming that a designated control transaction is among the blocks transactions. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-13:
Step 1
Claims 1-13 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of authorizing a conditional exchange of value between parties based on verified intent. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A computer-implemented system for distributing blockchain-related operations across a plurality of processing resources, the system comprising:
a plurality of components that are in communication with one another and comprising:
i) at least one validation component operative to facilitate or enable distributed validation of a blockchain block comprising a plurality of transactions and a root of a Merkle tree for the blockchain block by:
a) allocating respective subsets of the blockchain transactions to a plurality of validating resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and b) using the plurality of validating resources to validate their respective subsets of blockchain transactions
ii) at least one mining component operative to facilitate or enable distributed mining of a blockchain block or calculation of a Proof-of-Work (PoW) calculation by
a) sending, from a first resource to a second resource, a request to generate a PoW calculation for the blockchain block, the request comprising a Merkle proof for verification that a control transaction (TXo) is included in the plurality of transactions;
iii) at least one allocation component operative to allocate blockchain-related or implemented tasks to at least one processing resource in the plurality of processing resources by: using a portion of data derived from a blockchain to identify or allocate a processing or storage resource, wherein the portion of data is derived from data that comprises an unspent transaction output (UTXO) or a transaction (Tx) containing an unspent transaction output; or
iv) at least one record storage component comprising a record of at least a portion of a blockchain transaction, the record comprising transaction data for determining whether the at least a portion of a transaction (Tx) is included in a Merkle path of a blockchain block.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 2-13 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one validation component is operative to:
validate at least a portion of a blockchain block that comprises a plurality of blockchain transactions and a root of a Merkle tree for the block;
and preferably:
allocate respective subsets of the blockchain transactions to a plurality of validating (processing) resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and
use the plurality of validating resources to validate their respective subsets of blockchain transactions.
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one validation component is operative to:
download at least part of a blockchain block that comprises a plurality of blockchain transactions and a root of a Merkle tree for the block;
preferably wherein the validation component is arranged to perform the download by:
allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and
using one, some or all of the plurality of processing resources to download their respective subset of blockchain transactions.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one validation component is operative to:
generate, store or maintain a first UTXO repository for recording, searching or processing a plurality of unspent transaction outputs (UTXOs), each associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block;
wherein:
the plurality of blockchain transactions provides or is represented by a portion of a Merkle tree for the blockchain block.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the system or at least one validation component is operative to:
i) validate or verify at least one blockchain transaction; or
ii) perform a Simplified Payment Verification process; or
iii) confirm whether a given blockchain transaction is contained within the blockchain block; or
iii) generate a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path or checking whether the hash matches a transaction identifier in a header of the blockchain block.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the system or at least one validation component comprises at least one validating resource which is, or comprises, at least one of:
a virtual machine, a server, a GPU-based computing resource, a thread, or a multiprocessor system.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one allocation component is operative to:
i) use a portion of data derived from a blockchain to identify or allocate a processing or storage resource;
preferably wherein the portion of data comprises or is derived from an unspent transaction output (UTXO) or a blockchain transaction (Tx) containing an unspent transaction; or
ii) use/provide, generate, store or maintain a first UTXO resource arranged to a) record, search or process a plurality of unspent transaction outputs (UTXOs), each associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block; or b) use a portion of data derived from a blockchain to identify or allocate said resource, wherein said data from which the portion of data is derived comprises an unspent transaction output (UTXO) or a transaction (Tx) containing a UTXO; or
iii) receive or process an unspent transaction output (UTXO) for inclusion in a transaction; or use the portion of data derived from the unspent output to identify an allocated resource, wherein said allocated resource holds validation data for the UTXO; or request the validation data from the allocated resource.
Claim 8 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one allocation component is further operative to:
store or process at least a portion of the unspent output or the transaction (Tx): in the allocated resource; or by the allocated resource; or in association with the allocated resource.
Claim 9 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one mining component is operative to:
send, from a first resource to a second resource, a request to generate a Proof-Of-Work (PoW) for a blockchain block containing a plurality of transactions, the request comprising a Merkle proof for verification that a control transaction (TX0) is included in the plurality of transactions; or
receive, at the second resource from the first resource, a request to generate a Proof-Of-Work (PoW) for a blockchain block containing a plurality of transactions, the request comprising a Merkle proof for verification that a control transaction (TX0) is included in the plurality of transactions.
Claim 10 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein: the control transaction (TX0) comprises control data for controlling, allowing or prohibiting the performance of the requested Proof-of-Work generation; preferably wherein the control data comprises:
i) at least one output that specifies a predetermined address for a destination of a blockchain transfer;
preferably wherein the address is associated with the second resource, or a party associated with or authorised by the second resource; or
ii) at least one pre-determined signature; or
iii) at least one secret value or secret portion of data.
Claim 11 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein: the first resource is a PoW requesting resource, a blockchain validation resource or a blockchain mining resource; or
the second resource is a Proof-of-Work Provider; or
the second resource comprises at least one ASIC or hash machine or specialized cryptocurrency mining resource.
Claim 12 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one record storage component comprises:
at least one record, the at least one record comprising:
i) a blockchain transaction (TX0) comprising at least one data item (D); and
ii) at least one further blockchain transaction (TX1) necessary for confirming that the blockchain transaction (TX1) is included in the Merkle path of a blockchain block (B).
Claim 13 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein: the record further comprises: a Merkle path from the transaction (TX0) to a root of a Merkle tree for the blockchain block (B); and
preferably wherein the Merkle path comprises at least the minimum blockchain transactions necessary to establish or verify that the blockchain transaction (TX0) is included in the blockchain block (B).
Claim 14:
Step 1
Claim 14 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 14 recites (i.e., sets forth or describes) an abstract idea of authorizing a conditional exchange of value between parties based on verified intent. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. The claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A computer program embodied on non-transitory computer-readable storage media and arranged or configured so as, when run on one or more processors, the one or more processors implement some or all of a functionality of a system for distributing blockchain-related operations across a plurality of processing resources, the system comprising a plurality of components that are in communication with one another and comprising:
i) at least one validation component operative to facilitate or enable distributed validation a blockchain block comprising a plurality of transactions and a root of a Merkle tree for the blockchain block by:
allocating respective subsets of the blockchain transactions to a plurality of validating resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and
using the plurality of validating resources to validate their respective subsets of blockchain transactions;
ii) at least one mining component operative to facilitate or enable distributed mining of a blockchain block or calculation of a Proof-of-Work calculation by sending, from a first resource to a second resource, a request to generate a PoW calculation for the blockchain block, the request comprising a Merkle proof for verification that a control transaction (TXo) is included in the plurality of transactions; or
iii) at least one allocation component operative to allocate blockchain-related or implemented tasks to at least one processing resource in the plurality of processing resources by:
using a portion of data derived from a blockchain to identify or allocate a processing or storage resource, wherein the portion of data is derived from data that comprises an unspent transaction output (UTXO) or a transaction (Tx) containing an unspent transaction output; or
iv) at least one record storage component comprising a record of at least a portion of a blockchain transaction, the record comprising transaction data for determining whether the at least a portion of a transaction (Tx) is included in a Merkle path of a blockchain block.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 14 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 14, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US20200076884A1) (hereinafter “Li”) in view of Miller et al. (US20170132621A1) (hereinafter “Miller”).
As per Claim 1 and 14, Li teaches:
A computer-implemented system for distributing blockchain-related operations across a plurality of processing resources, the system comprising: a plurality of components that are in communication with one another and comprising: i) at least one validation component operative to facilitate or enable distributed validation of a blockchain block comprising a plurality of transactions and a root of a . . . for the blockchain block by: or (“In some embodiments a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020); “The selected computing devices for the requested task perform computing portions, as indicated by arrow 122, and the results 124, which are generated in the distributed computing layer 114 are communicated to the blockchain layer 112. The results 124, subject to successful validation, are communicated to the client device 102, as results 126. Following successful results validation, payment 128 is sent to the provider computing devices, which performed the computing task.” (Para. 0066); “Once the computing job, e.g., ML job, is completed, results, i.e. weights of a neural network, are fed back, e.g., as results 124, to the blockchain layer, e.g., blockchain layer 112, which will perform validation. If the results are verified to be true, the deposit token from the client will be released to the selected providers, which perfumed the computing task, e.g., as payment 224, and the computing results, e.g., ML results, will be returned to the client, e.g., as return results 224 to client 102.” (Para. 0074))
a) allocating respective subsets of the blockchain transactions to a plurality of validating resources, wherein . . .; “The smart contract component of the blockchain, in response to a task request, algorithmically selects a set of providers, e.g., available computing devices, for the requested task.” (Para. 0016); “The selected computing devices for the requested task perform computing portions, as indicated by arrow 122, and the results 124, which are generated in the distributed computing layer 114 are communicated to the blockchain layer 112.” (Para. 0066); “a component 1143 configured to operate the first device to work on a portion of the requested computing task and to generate a first computing result portion, and a component 1144 configured to operate the first device to broadcast a blockchain update, e.g., a blockchain synchronization signal, to provide the first computing result portion to other devices implementing the blockchain.” (Para. 0191))
iii) at least one allocation component operative to allocate blockchain-related or implemented tasks to at least one processing resource in the plurality of processing resources by: (“executing a resource allocation component (smart contract portion) of a blockchain to select multiple devices in the computing network to service the requested computing task, said resource allocation component outputting selected node information (e.g., node IDs, blockchain Account ID or other information identifying the selected compute nodes) to a networking component (networking smart contract), said first device being one of the selected devices; and operating the networking component to generate a set of network topology information for the selected devices and to control the first device to use information in the generated set of network topology information to establish a communications connection with a third device (another compute node), said third device being one of the plurality of devices selected to service the requested computing task; operating the first device to work on a portion of the requested computing task and to generate a first computing result portion; and operating the first device to provide computing results to the second device (requesting device).” (Para. 0023); “the smart contract is viewed as including the four sub-smart contracts. In some embodiments, the four sub-smart contracts are referred to as four smart contracts, e.g., a resource allocation contract, a networking contract, a security contract, and a validation contract.” (Para. 0082); “Resource Allocation will now be described. The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.” (Para. 0086))
using a portion of data derived from a blockchain to identify or allocate a processing or storage resource, wherein the portion of data is derived from data that comprises . . . ; or iv) at least one record storage component comprising a record of at least a portion of a blockchain transaction, the record comprising transaction data for determining whether the at least a portion of a transaction (Tx) is included in . . . of a blockchain block. (“in accordance with one feature of some embodiments of the present invention, is that the process of computation of a snapshot of the status of system shall be taken regularly and stored in one or more devices.” (para. 0093), “. . . Node B or Node C or both obtains the results from the distributed computing component. Then Node B or Node C or both uploads the result to the verification smart contract on the blockchain. Then, each of the blockchain nodes, behaving as judges, runs the verification smart contract to determine the results true or not. Here “blockchain nodes” can be the accounts who are not selected for this computing task, for example, Node D. Remark that if the computation results itself is a big file (e.g. Gbytes), a distributed file system (e.g. InterPlanetary File System) can be used to store the result and only the hash of the results is uploaded to the verification component. To do verification, algorithms will read and process the results in the storage system using the provided hash” (Para. 0145); “Assembly of components 1100 further includes a component 1135 configured to replace node IDs, e.g. blockchain account IDs, of devices of the selected set of devices, in one ormer stored lists including mappings between node IDs and physical IDs, e.g. in Kademlia k-buckets, with the determined first group identifier, e.g. index, a component configured to send a search request, e.g., a Find Node request signal including said determined group identifier, e.g., index, and a component 1139 configured to receive a response signal including a physical identifier of the third device in response to said search request signal.” (Para. 0190); “the smart contract feeds back the rate to the client device which submitted the task request to the blockchain and awaits a message from the client indicating acceptance of the service charge. If the client indicates acceptance of the communicate rate the task, the client sends a deposit or authorizes a deposit to be charged and confirmations to the smart contract that the rate has been accepted. . . The smart contract component of the blockchain, in response to acceptance of the rate and thus the service offer, computes computing device configuration parameters and sends the relevant parameters to the devices which have been selected for implementing the computing task, e.g., a distributed computing task.” (Para. 0017-0018); “a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020).
Li does not disclose:
“each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and b) using the plurality of validating resources to validate their respective subsets of blockchain transactions” (claim 1).
However, as per Claim 1, Miller in the analogous art of secured digital transactions, teaches: “each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and b) using the plurality of validating resources to validate their respective subsets of blockchain transactions”. “the autonomous transacting device implements a simple payment verification process in order to verify that the actual cryptocurrency value required for the autonomous device to execute the addendum has been transferred. The simple payment verification process, in such embodiments, is used to allow a device to operate without storing the full blockchain. Accordingly, the autonomous transacting device downloads only the block headers and do not download the transactions included in each block.” (Para. 0160-0161); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path.” (Para. 0163); “a slightly different method for verification is required that sometimes relies on peers to provide to provide partial views of relevant parts of the blockchain on demand.” (Para. 0161)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li, using a blockchain or smart contract layer to assign portions of a larger computational task to multiple provider devices and validate their partial results, with the technique of Miller, representing a block of blockchain transactions as a Merkle Tree and using Merkle-derived subsets to prove inclusion of transactions, to include allocating respective subsets of the blockchain transactions, to a plurality of validating resources and using those resources to validate their respective subsets of blockchain transactions. Therefore, the incentives of scaling blockchain validation and reducing the per-node workload provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Li does not disclose:
“a) sending, from a first resource to a second resource, a request to generate a PoW calculation for the blockchain block, the request comprising a Merkle proof for verification that a control transaction (TXo) is included in the plurality of transactions” (claim 1).
However, as per Claim 1, Miller in the analogous art of secured digital transactions, teaches: “a) sending, from a first resource to a second resource, a request to generate a PoW calculation for the blockchain block, the request comprising a Merkle proof for verification that a control transaction (TXo) is included in the plurality of transactions”. “the autonomous transacting device implements a simple payment verification process in order to verify that the actual cryptocurrency value required for the autonomous device to execute the addendum has been transferred.” (Para. 0160); “the autonomous transacting device downloads only the block headers and do not download the transactions included in each block. Thus, the resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. With this limited blockchain information, the autonomous transacting device, in some embodiments, cannot construct a full picture of all the cryptocurrency available for spending by the party making the transaction request because the device does not know about all the transactions on the network. Accordingly, since the autonomous device only has a limited amount of blockchain information for verifying the exchange of the cryptocurrency value, a slightly different method for verification is required that sometimes relies on peers to provide to provide partial views of relevant parts of the blockchain on demand.” (Para. 0161); “Specifically, using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks. The fact that other nodes on the blockchain network accepted the transaction block and did the necessary work to produce subsequent blocks on top of the transaction block is proof, by proxy, that the transaction was not a double-spend.” (Para. 0163)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li, in which a first resource outsources intensive computation to a second resource by sending a request for remote execution, with the technique of Miller, using a Merkle Path and related block data as a compact proof that a given transaction in included in a block that has undergone proof-of-work calculation for a blockchain block. Therefore, the incentives of improving trust and enforceability in outsourced mining arrangements provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Li does not disclose:
“ii) at least one mining component operative to facilitate or enable distributed mining of a blockchain block or calculation of a Proof-of-Work calculation; or” and “a Merkle path” (claim 1).
However, as per Claim 1, Miller in the analogous art of secured digital transactions, teaches: “ii) at least one mining component operative to facilitate or enable distributed mining of a blockchain block or calculation of a Proof-of-Work calculation; or” and “a Merkle path”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a mining component with POW and Merkle tree functionality. Therefore, the incentives of providing increased transaction security within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Li does not disclose:
“an unspent transaction output (UTXO) or a transaction (Tx) containing an unspent transaction output” (claim 1).
However, as per Claim 1, Miller in the analogous art of secured digital transactions, teaches: “an unspent transaction output (UTXO) or a transaction (Tx) containing an unspent transaction output”. (See Miller’s “. . .unspent funds” which can be individually addressed, such that “. . . if either party stops cooperating for any reason including malfunction or intentional non-cooperation, then the funds at that point remain frozen until cooperation begins again or the party seeking to have the funds released from escrow is able to prove that at least some of the microtransactions have been completed . . .”; Miller further discusses this addressing of “unspent funds”, noting “As mentioned above, in addition to locking the funds in the escrow, the parties provide all of the shared secrets generated at step 710 for each of the microtransactions into the cryptographic escrow. Accordingly, with all of the generated shared secrets stored in the cryptographic escrow at the block chain, the block chain can be used as a third party to verify completion of all or a portion of the microtransactions based on the number of shared secret pairs that have been exchanged to form the sidechain”. (Para. 0180-0181).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include at least some tokenized unspent funds in an authentication process. Therefore, the incentives of providing increased authentication security provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Li teaches:
The system of claim 1, wherein the at least one validation component is operative to: validate at least a portion of a blockchain block that comprises a plurality of blockchain transactions and a root of a . . . for the block; and preferably: allocate respective subsets of the blockchain transactions to a plurality of validating (processing) resources, wherein each respective subset provides a respective portion of the . . . and is represented by a respective inner node of the . . .; and use the plurality of validating resources to validate their respective subsets of blockchain transactions. (“In some embodiments a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020); “The selected computing devices for the requested task perform computing portions, as indicated by arrow 122, and the results 124, which are generated in the distributed computing layer 114 are communicated to the blockchain layer 112. The results 124, subject to successful validation, are communicated to the client device 102, as results 126. Following successful results validation, payment 128 is sent to the provider computing devices, which performed the computing task.” (Para. 0066); “Once the computing job, e.g., ML job, is completed, results, i.e. weights of a neural network, are fed back, e.g., as results 124, to the blockchain layer, e.g., blockchain layer 112, which will perform validation. If the results are verified to be true, the deposit token from the client will be released to the selected providers, which perfumed the computing task, e.g., as payment 224, and the computing results, e.g., ML results, will be returned to the client, e.g., as return results 224 to client 102.” (Para. 0074); (“executing a resource allocation component (smart contract portion) of a blockchain to select multiple devices in the computing network to service the requested computing task, said resource allocation component outputting selected node information (e.g., node IDs, blockchain Account ID or other information identifying the selected compute nodes) to a networking component (networking smart contract), said first device being one of the selected devices; and operating the networking component to generate a set of network topology information for the selected devices and to control the first device to use information in the generated set of network topology information to establish a communications connection with a third device (another compute node), said third device being one of the plurality of devices selected to service the requested computing task; operating the first device to work on a portion of the requested computing task and to generate a first computing result portion; and operating the first device to provide computing results to the second device (requesting device).” (Para. 0023); “the smart contract is viewed as including the four sub-smart contracts. In some embodiments, the four sub-smart contracts are referred to as four smart contracts, e.g., a resource allocation contract, a networking contract, a security contract, and a validation contract.” (Para. 0082); “Resource Allocation will now be described. The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.” (Para. 0086); (“, the smart contract feeds back the rate to the client device which submitted the task request to the blockchain and awaits a message from the client indicating acceptance of the service charge. If the client indicates acceptance of the communicate rate the task, the client sends a deposit or authorizes a deposit to be charged and confirmations to the smart contract that the rate has been accepted. . . The smart contract component of the blockchain, in response to acceptance of the rate and thus the service offer, computes computing device configuration parameters and sends the relevant parameters to the devices which have been selected for implementing the computing task, e.g., a distributed computing task.” (Para. 0017-0018); “a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020).
Li does not disclose:
“a Merkle tree” (claim 2).
However, as per Claim 2, Miller in the analogous art of secured digital transactions, teaches: “a Merkle tree”. (See “a full blockchain node will construct a fully verified chain of thousands of blocks and transaction reaching down the blockchain (e.g., back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transaction) and link that chain to the transaction of interest” (Para. 0162); “Before any decentralized interaction between parties (e.g., devices) can happen, there must first be a means or method to ensure both the identity and the discoverability of a party. Identity of a party (e.g., an endpoint or node) focuses specifically on the verifiability that a party is who they say they are.” (Para. 0023); “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include Merkle tree functionality within the resource allocation steps. Therefore, the incentives of providing more efficient resource allocation within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner
As per Claim 3, Li teaches:
The system of claim 1, wherein the at least one validation component is operative to: download at least part of a blockchain block that comprises a plurality of blockchain transactions and a root of a . . . for the block; preferably wherein the validation component is arranged to perform the download by: allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the . . . and is represented by a respective inner node of the . . .; and using one, some or all of the plurality of processing resources to download their respective subset of blockchain transactions. (“In step 704 the new arrival node synchronizes to the network. The new arrival node has decided to join the blockchain based distributed computing network and the new arrival node conducts synchronization by downloading blockchain. Step 704 includes step 706 in which the new arrival node downloads a blockchain or portion of a blockchain, e.g., a whole blockchain or partial blockchain and each of the smart contracts running on the blockchain. Operation proceeds from step 704 to step 708.” (Para. 0122); (“In step 714 the new arrival node receives a service request for a computing task, e.g., a machine learning (ML) training task. For example, the received service request is a service request from node A 504 which is a service request for a computing task through the blockchain, e.g. a machine learning task, This request is an input signal to the resource allocation smart contract. The request information communicated in the received request reflects the needed (estimated) computational load, For example, in machine learning training task in some embodiments, the request includes the sizes of the neural network, dataset, and the format of the data, e.g., images, voices, etc. Operation proceeds from step 714 to step 716.” (Para. 0124); (“In step 904 the first device downloads a blockchain. In some embodiments, the blockchain includes one or more smart contracts.” (Para. 0163); “Assembly of components 1100 includes a component 1104 configured to download a blockchain, a component 1106 configured to create a first computing device account including first computing device account information about the first computing device, a component 1108 configured to send a blockchain update to one or more other devices, said blockchain update including first device account information, and a component 1110 configured to receive a blockchain based computing task request from a second device. Assembly of components 1100 further includes a component 1112 configured to execute a resource allocation component of the blockchain to select multiple devices in the computing network to service the requested computing task, said resource allocation component outputting selected node information to a networking component, said first device being one of the selected devices.” (Para. 0186-187).
Li does not disclose:
“a Merkle tree” (claim 3).
However, as per Claim 3, Miller in the analogous art of secured digital transactions, teaches: “a Merkle tree”. (See “a full blockchain node will construct a fully verified chain of thousands of blocks and transaction reaching down the blockchain (e.g., back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transaction) and link that chain to the transaction of interest” (Para. 0162); “Before any decentralized interaction between parties (e.g., devices) can happen, there must first be a means or method to ensure both the identity and the discoverability of a party. Identity of a party (e.g., an endpoint or node) focuses specifically on the verifiability that a party is who they say they are.” (Para. 0023); “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include Merkle tree functionality within the resource allocation steps. Therefore, the incentives of providing more efficient resource allocation within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner
As per Claim 4, Li teaches:
The system of claim 1, wherein the at least one validation component is operative to: generate, store or maintain a first . . . repository for recording, searching or processing a plurality of . . . outputs . . ., each associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block; wherein: the plurality of blockchain transactions provides or is represented by a portion of a . . . for the blockchain block. (“a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020); (“First of all, each of the accounts in S agree on an identical (pre-assigned) index for a P2P protocol. Then one or more account finds other peers (e.g. IP address) in the P2P network by searching the preassigned index. Since each of the accounts in set S have an identical index, no account can be linked up to any particular physical node in discovery. By doing so, however, each of the physical IDs for blockchain accounts in S can be collected. Finally, one or more account inputs the collection of physical IDs to the topology generation component.” (Para. 00133); (“A node initiates a FIND_NODE request (a physical signaling) by querying to the n nodes in its own bucket that are the closest ones (i.e., ranking based on the distance) to the desired node ID. When these recipient nodes receive the request, they will look in their buckets and return the k closest nodes to the desired node ID that they know (a return signal to the requester). The requester will update a results list with the results (node ID's) he receives, keeping the k best ones (the k nodes that are closer to the searched node ID) that respond to queries. . . Because every node has a better knowledge of his own surroundings than any other node has, the received results will be other nodes that are every time closer and closer to the searched node ID.” (Para. 0138)).
Li does not disclose:
“an unspent transaction outputs (UTXOs)” (claim 4).
However, as per Claim 4, Miller in the analogous art of secured digital transactions, teaches: “an unspent transaction outputs (UTXOs)”. (See Miller’s “. . .unspent funds”, which can be individually addressed, such that “. . . if either party stops cooperating for any reason including malfunction or intentional non-cooperation, then the funds at that point remain frozen until cooperation begins again or the party seeking to have the funds released from escrow is able to prove that at least some of the microtransactions have been completed . . .”; Miller further discusses this addressing of “unspent funds”, noting “As mentioned above, in addition to locking the funds in the escrow, the parties provide all of the shared secrets generated at step 710 for each of the microtransactions into the cryptographic escrow. Accordingly, with all of the generated shared secrets stored in the cryptographic escrow at the block chain, the block chain can be used as a third party to verify completion of all or a portion of the microtransactions based on the number of shared secret pairs that have been exchanged to form the sidechain”. (Para. 0180-0181).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include at least some tokenized unspent funds in an authentication process. Therefore, the incentives of providing increased authentication security provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Li does not disclose:
“a Merkle tree” (claim 4).
However, as per Claim 4, Miller in the analogous art of secured digital transactions, teaches: “a Merkle tree”. (See “a full blockchain node will construct a fully verified chain of thousands of blocks and transaction reaching down the blockchain (e.g., back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transaction) and link that chain to the transaction of interest” (Para. 0162); “Before any decentralized interaction between parties (e.g., devices) can happen, there must first be a means or method to ensure both the identity and the discoverability of a party. Identity of a party (e.g., an endpoint or node) focuses specifically on the verifiability that a party is who they say they are.” (Para. 0023); “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include Merkle tree functionality within the validation and searching steps. Therefore, the incentives of providing more efficient resource allocation within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner
As per Claim 5, Li teaches:
The system of claim 1, wherein the system or at least one validation component is operative to: i) validate or verify at least one blockchain transaction; or ii) perform a Simplified Payment Verification process; or iii) confirm whether a given blockchain transaction is contained within the blockchain block; or iii) generate a hash of at least one of the blockchain transactions, using the hash to construct a . . . or checking whether the hash matches a transaction identifier in a header of the blockchain block. (“node B, receives and verifies the computing results. Step 748 includes step 750, 752 and 754. In step 750 the new arrival node, e.g., node B, receives computing results from other nodes, e.g., node C, on the distributed computing layer. Operation proceeds from step 750 to step 752. In step 752 the new arrival node passes this result to the verification smart contract on the blockchain layer. In step 754 the new arrival node, e.g., node B, behaves as a judge, along with other nodes, and runs the verification smart contract to determine whether or not the results are true.” (Para. 0144); (“With regard to the example of FIG. 5, Node B or Node C or both obtains the results from the distributed computing component. Then Node B or Node C or both uploads the result to the verification smart contract on the blockchain. Then, each of the blockchain nodes, behaving as judges, runs the verification smart contract to determine the results true or not. Here “blockchain nodes” can be the accounts who are not selected for this computing task, for example, Node D. Remark that if the computation results itself is a big file (e.g. Gbytes), a distributed file system (e.g. InterPlanetary File System) can be used to store the result and only the hash of the results is uploaded to the verification component. To do verification, algorithms will read and process the results in the storage system using the provided hash. Once the results are verified, Node A (the client) will retrieve the results either from the verification smart contract or the storage system using hash.” (Para. 00145); (“The validation contract validates the results obtained from the distributed computing platform. Once the agent server 303 reports the solution to the blockchain layer 112, verifiers, e.g., nodes which perform verifications operations to confirm results, will call the validation smart contract to check the solver's solution. The solution can be, and sometimes is, an intermediate solution in the process of parameter exchange between the agent server 303 and each provider (306, 308, . . . , 310). A verifier can be one or more nodes in the network.” (Para. 0092)).
Li does not disclose:
“a Merkle path” (claim 5).
However, as per Claim 5, Miller in the analogous art of secured digital transactions, teaches: “a Merkle path”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a validation component with Merkle tree functionality. Therefore, the incentives of providing increased transaction security within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 6, Li teaches:
The system of claim 1, wherein the system or at least one validation component comprises at least one validating resource which is, or comprises, at least one of: a virtual machine, a server, a GPU-based computing resource, a thread, or a multiprocessor system. (“a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented.” (Para. 0020); (“Computing device 1000 includes one or more processors (processor 1 1002, . . . , processor M 1003), wireless interface 1004, network interface 1006, e.g., a wired or optical interface, I/O interface 1008, memory 1010, and an assembly of hardware components 1013, e.g., assembly of circuits, coupled together via a bus 1015 over which the various elements may interchange data and information.” (Para. 0180); (“In some embodiments, the processor or processors, e.g., CPUs, of one or more devices, e.g., communications nodes such as controllers are configured to perform the steps of the methods described as being performed by the communications nodes, e.g., controllers. The configuration of the processor may be achieved by using one or more components, e.g., software components, to control processor configuration or by including hardware in the processor, e.g., hardware components, to perform the recited steps or control processor configuration.” (Para. 0276)).
As per Claim 7, Li teaches:
The system of claim 1, wherein the at least one allocation component is operative to: i) use a portion of data derived from a blockchain to identify or allocate a processing or storage resource; preferably wherein the portion of data comprises or is derived from . . .; or ii) use/provide, generate, store or maintain a first . . . resource arranged to a) record, search or process a plurality of . . ., each associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of a blockchain block; or b) use a portion of data derived from a blockchain to identify or allocate said resource, wherein said data from which the portion of data is derived comprises an . . .; or iii) receive or process . . . for inclusion in a transaction; or use the portion of data derived from the . . . to identify an allocated resource, wherein said allocated resource holds validation data for the . . .; or request the validation data from the allocated resource. (“receiving a blockchain based computing task request from a second device (requesting device); executing a resource allocation component (smart contract portion) of a blockchain to select multiple devices in the computing network to service the requested computing task, said resource allocation component outputting selected node information (e.g., node IDs, blockchain Account ID or other information identifying the selected compute nodes) to a networking component (networking smart contract), said first device being one of the selected devices.” (Para. 0023); (“The functionality of networking component, e.g., networking smart contract, is two-fold: 1) physical address identification for the selected blockchain accounts; 2) topology generation which optimizes a network topology formed by the selected nodes.” (Para. 0129); (“The selected computing devices for the requested task perform computing portions. . . and the results 124, which are generated in the distributed computing layer 114 are communicated to the blockchain layer 112. The results 124, subject to successful validation, are communicated to the client device 102, as results 126. Following successful results validation, payment 128 is sent to the provider computing devices, which performed the computing task.” (Para. 0066)).
Li does not disclose:
“an unspent transaction output (UTXO) or a blockchain transaction (Tx) containing an unspent transaction” and “unspent output” (claim 7).
However, as per Claim 7, Miller in the analogous art of secured digital transactions, teaches: “an unspent transaction output (UTXO) or a blockchain transaction (Tx) containing an unspent transaction” and “unspent output”. (See Miller’s “. . .unspent funds”, which can be individually addressed, such that “. . . if either party stops cooperating for any reason including malfunction or intentional non-cooperation, then the funds at that point remain frozen until cooperation begins again or the party seeking to have the funds released from escrow is able to prove that at least some of the microtransactions have been completed . . .”; Miller further discusses this addressing of “unspent funds”, noting “As mentioned above, in addition to locking the funds in the escrow, the parties provide all of the shared secrets generated at step 710 for each of the microtransactions into the cryptographic escrow. Accordingly, with all of the generated shared secrets stored in the cryptographic escrow at the block chain, the block chain can be used as a third party to verify completion of all or a portion of the microtransactions based on the number of shared secret pairs that have been exchanged to form the sidechain”. (Para. 0180-0181).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include at least some tokenized unspent funds in an authentication process. Therefore, the incentives of providing increased authentication security provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 8, Li teaches:
The system of claim 7, wherein the at least one allocation component is further operative to: store or process at least a portion of the . . . or the transaction (Tx): in the allocated resource; or by the allocated resource; or in association with the allocated resource. (“The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.” (Para. 0086); (“In step 716 the new arrival node writes the received service request into the resource allocation smart contract. Like each of the other nodes in the network, once the new arrival node, e.g. node B 506, receives the request, the new arrival node writes it into the resource allocation smart contract.” (Para. 0125); (“After running the resource allocation smart contract, every node in the blockchain network knows the selected blockchain accounts (i.e. Node ID in the triple) who will provide the computing service. Then every node will update their Kademlia list by temporarily replacing these node IDs with an identical preassigned ID. Then these nodes in set S follows the Kademlia's iterative node searching (locating) algorithm to find these preassigned IDs in the network, i.e. other peers (their IP address) in set S.” (Para. 0134)).
Li does not disclose:
“unspent output” (claim 8).
However, as per Claim 8, Miller in the analogous art of secured digital transactions, teaches: “unspent output”. (See Miller’s “. . .unspent funds”, which can be individually addressed, such that “. . . if either party stops cooperating for any reason including malfunction or intentional non-cooperation, then the funds at that point remain frozen until cooperation begins again or the party seeking to have the funds released from escrow is able to prove that at least some of the microtransactions have been completed . . .”; Miller further discusses this addressing of “unspent funds”, noting “As mentioned above, in addition to locking the funds in the escrow, the parties provide all of the shared secrets generated at step 710 for each of the microtransactions into the cryptographic escrow. Accordingly, with all of the generated shared secrets stored in the cryptographic escrow at the block chain, the block chain can be used as a third party to verify completion of all or a portion of the microtransactions based on the number of shared secret pairs that have been exchanged to form the sidechain”. (Para. 0180-0181).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include at least some tokenized unspent funds in an authentication process. Therefore, the incentives of providing increased authentication security provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 9, Li teaches:
The system of claim 8, “wherein the at least one . . . is operative to: send, from a first resource to a second resource, a request to generate a . . . for a blockchain block containing a plurality of transactions, the request comprising a . . . for verification that a control transaction (TX0) is included in the plurality of transactions; or receive, at the second resource from the first resource, a request to generate a . . . for a blockchain block containing a plurality of transactions, the request comprising a . . . for verification that a control transaction (TX0) is included in the plurality of transactions”. (“The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.”. (Para. 0086); “Assume that there exist three or more providers, e.g., computing devices which provide computing services, in the network. The resource allocation contract component selects three computing machines for the task. According to the machines' capabilities, the equations can be partitioned as follows with each partition (A_i, b_i) stored in one machine”. (Para. 0097); “a computing task is part of a transaction which is documented in the public register”. (Para. 0013); “Consider that each of the nodes (506, 508, 510) are potential computing provider devices, have downloaded a blockchain including a smart contract including multiple smart sub-contracts, and that node B 506, nodes C 508 and nodes D 510 may, and sometimes do participate in distributed computing.” (Para. 0103).
Li does not disclose:
“mining component” (claim 9).
However, as per Claim 9, Miller in the analogous art of secured digital transactions, teaches: “mining component”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a mining component which allows for differing computing resources to handle the mining (e.g. Proof-of-Work) tasks. Therefore, the incentives of providing improved efficiency and task control provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 10, Li teaches:
The system of claim 9, wherein: the control transaction (TX0) comprises control data for controlling, allowing or prohibiting the performance of the requested . . . generation; preferably wherein the control data comprises: i) at least one output that specifies a predetermined address for a destination of a blockchain transfer; preferably wherein the address is associated with the second resource, or a party associated with or authorised by the second resource; or ii) at least one pre-determined signature; or iii) at least one secret value or secret portion of data. (“The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.”. (Para. 0086); “the existing node determines the network topology of the selected operation nodes. Step 826 includes step 828, 830, 832 and 834. In step 828 the existing node runs a networking smart contract to determine the network topology of selected nodes. Operation proceeds from step 828 to step 830, in which the existing node broadcasts a connection signal including information for a node to connect to another node, e.g., domain name, IP address, alias, etc. Operation proceeds from step 830 to step 832. In step 832 the existing node receives a response signal to establish a link with another node. Operation proceeds from step 826 to step 836, in which the existing node establishes a topological network, e.g., in a network layer peer to peer fashion. Operation proceeds from step 826 to step 836. In step 836 the existing node generates secret keys for message exchanges in the network. Step 836 includes step 838 in which the existing node runs a security contract to generate secret keys for secure message passing in the network. Step 838 includes step 840 in which the existing node generates a set of pairs of keys for the existing node. Operation proceeds from step 836 to step 842.” (Para. 0155-156); “Assume that there exist three or more providers, e.g., computing devices which provide computing services, in the network. The resource allocation contract component selects three computing machines for the task. According to the machines' capabilities, the equations can be partitioned as follows with each partition (A_i, b_i) stored in one machine”. (Para. 0097); “a computing task is part of a transaction which is documented in the public register”. (Para. 0013); “Consider that each of the nodes (506, 508, 510) are potential computing provider devices, have downloaded a blockchain including a smart contract including multiple smart sub-contracts, and that node B 506, nodes C 508 and nodes D 510 may, and sometimes do participate in distributed computing.” (Para. 0103).
Li does not disclose:
“Proof-of-Work” (claim 10).
However, as per Claim 10, Miller in the analogous art of secured digital transactions, teaches: “Proof-of-Work”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a mining component with POW and Merkle tree functionality. Therefore, the incentives of providing increased transaction security within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 11, Li teaches:
The system of claim 9, wherein: the first resource is a . . . requesting resource, a blockchain validation resource or a blockchain . . .; or the second resource is a . . . Provider; or the second resource comprises at least one ASIC or hash machine or specialized cryptocurrency . . .. (“the first device receives a blockchain based computing task request from a second device, e.g., a requesting device. In one embodiment, the second device is node A 504 of FIG. 5. Operation proceeds from step 910 to step 912. In step 912 the first device executes a resource allocation component, e.g., a smart contract portion, of the blockchain to select multiples devices in the computing network to service the requested computing task, said resource allocation component outputting selected node information, e.g., node IDs, blockchain account ID or other information identifying the selected compute nodes, to a networking component, e.g., a networking smart contract, said first device being one of the selected devices. In one exemplary embodiment, the selected multiple devices to service the request are device B 506 and device C 508 of FIG. 5.” (Para. 0166-167); (“The resource allocation contract: processes the computing task request and provider's information, selects a set of providers to perform a computing task, and estimates a service rate for the client. In some embodiments, the provider's information includes computing capability (GPU, CPU, etc.), connectivity capability (turn-on duration, bandwidth), and storage capability (memory size, buffer size, etc.) In some embodiments, an optimization method is used to select the set of providers.” (Para. 0086); (“the new arrival node performs node registration, e.g., the new arrival node registers itself to the blockchain. Step 708 includes step 710 and step 712. In step 710 the new node creates and account, said account including account information, said account information being an input to a resource allocation smart contract.” (Para. 0123)); (“node B, receives and verifies the computing results. Step 748 includes step 750, 752 and 754. In step 750 the new arrival node, e.g., node B, receives computing results from other nodes, e.g., node C, on the distributed computing layer. Operation proceeds from step 750 to step 752. In step 752 the new arrival node passes this result to the verification smart contract on the blockchain layer. In step 754 the new arrival node, e.g., node B, behaves as a judge, along with other nodes, and runs the verification smart contract to determine whether or not the results are true.” (Para. 0144); (“With regard to the example of FIG. 5, Node B or Node C or both obtains the results from the distributed computing component. Then Node B or Node C or both uploads the result to the verification smart contract on the blockchain. Then, each of the blockchain nodes, behaving as judges, runs the verification smart contract to determine the results true or not. Here “blockchain nodes” can be the accounts who are not selected for this computing task, for example, Node D. Remark that if the computation results itself is a big file (e.g. Gbytes), a distributed file system (e.g. InterPlanetary File System) can be used to store the result and only the hash of the results is uploaded to the verification component. To do verification, algorithms will read and process the results in the storage system using the provided hash. Once the results are verified, Node A (the client) will retrieve the results either from the verification smart contract or the storage system using hash.” (Para. 00145); (“The validation contract validates the results obtained from the distributed computing platform. Once the agent server 303 reports the solution to the blockchain layer 112, verifiers, e.g., nodes which perform verifications operations to confirm results, will call the validation smart contract to check the solver's solution. The solution can be, and sometimes is, an intermediate solution in the process of parameter exchange between the agent server 303 and each provider (306, 308, . . . , 310). A verifier can be one or more nodes in the network.” (Para. 0092)).
Li does not disclose:
“mining resource” and “Proof-of-Work” (claim 11).
However, as per Claim 11, Miller in the analogous art of secured digital transactions, teaches: “Proof-of-Work”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a mining component with POW and Merkle tree functionality. Therefore, the incentives of providing increased transaction security within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 12, Li teaches:
The system of claim 1, wherein the at least one record storage component comprises: at least one record, the at least one record comprising: i) a blockchain transaction (TX0) comprising at least one data item (D); and ii) at least one further blockchain transaction (TX1) necessary for confirming that the blockchain transaction (TX1) is included in the . . . of a blockchain block (B). (“a distributed approach to performing computational tasks is described which take advantage of a blockchain, e.g., a public register in which transactions between users belonging are stored in a secure, verifiable and permanent way. In various embodiments a computing task is part of a transaction which is documented in the public register” (Para. 0013); “This task request includes in some embodiments task information on the task to be performed or processing requirements, e.g., the ML model size, dataset size, data format, etc., such that the smart contract component of the blockchain can use the task information to select providers from the network which are suitable for the task.” (Para. 0015); “, the smart contract feeds back the rate to the client device which submitted the task request to the blockchain and awaits a message from the client indicating acceptance of the service charge. If the client indicates acceptance of the communicate rate the task, the client sends a deposit or authorizes a deposit to be charged and confirmations to the smart contract that the rate has been accepted. . . The smart contract component of the blockchain, in response to acceptance of the rate and thus the service offer, computes computing device configuration parameters and sends the relevant parameters to the devices which have been selected for implementing the computing task, e.g., a distributed computing task.” (Para. 0017-0018); “a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020); (“in accordance with one feature of some embodiments of the present invention, is that the process of computation of a snapshot of the status of system shall be taken regularly and stored in one or more devices.” (para. 0093), “. . . Node B or Node C or both obtains the results from the distributed computing component. Then Node B or Node C or both uploads the result to the verification smart contract on the blockchain. Then, each of the blockchain nodes, behaving as judges, runs the verification smart contract to determine the results true or not. Here “blockchain nodes” can be the accounts who are not selected for this computing task, for example, Node D. Remark that if the computation results itself is a big file (e.g. Gbytes), a distributed file system (e.g. InterPlanetary File System) can be used to store the result and only the hash of the results is uploaded to the verification component. To do verification, algorithms will read and process the results in the storage system using the provided hash” (Para. 0145); “Assembly of components 1100 further includes a component 1135 configured to replace node IDs, e.g. blockchain account IDs, of devices of the selected set of devices, in one ormer stored lists including mappings between node IDs and physical IDs, e.g. in Kademlia k-buckets, with the determined first group identifier, e.g. index, a component configured to send a search request, e.g., a Find Node request signal including said determined group identifier, e.g., index, and a component 1139 configured to receive a response signal including a physical identifier of the third device in response to said search request signal.” (Para. 0190); “the smart contract feeds back the rate to the client device which submitted the task request to the blockchain and awaits a message from the client indicating acceptance of the service charge. If the client indicates acceptance of the communicate rate the task, the client sends a deposit or authorizes a deposit to be charged and confirmations to the smart contract that the rate has been accepted. . . The smart contract component of the blockchain, in response to acceptance of the rate and thus the service offer, computes computing device configuration parameters and sends the relevant parameters to the devices which have been selected for implementing the computing task, e.g., a distributed computing task.” (Para. 0017-0018); “a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020).
Li does not disclose:
“merkle path” (claim 12).
However, as per Claim 12, Miller in the analogous art of secured digital transactions, teaches: “merkle path””. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a storage system for data which includes Merkle path-associated transactions. Therefore, the incentives of providing increased transaction security and speed of cryptographic verification within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 13, Li teaches:
The system of claim 12, wherein: the record further comprises: a . . . from the transaction (TX0) to a root of a . . . for the blockchain block (B); and preferably wherein the . . . comprises at least the minimum blockchain transactions necessary to establish or verify that the blockchain transaction (TX0) is included in the blockchain block (B). (“, the smart contract feeds back the rate to the client device which submitted the task request to the blockchain and awaits a message from the client indicating acceptance of the service charge. If the client indicates acceptance of the communicate rate the task, the client sends a deposit or authorizes a deposit to be charged and confirmations to the smart contract that the rate has been accepted. . . The smart contract component of the blockchain, in response to acceptance of the rate and thus the service offer, computes computing device configuration parameters and sends the relevant parameters to the devices which have been selected for implementing the computing task, e.g., a distributed computing task.” (Para. 0017-0018); “a validation component in the blockchain performs result validation. If the results are verified to be true, e.g., the result of the requested computation, the computing results are provided by the blockchain to the client device which requested that the computing task be implemented. In addition, in the case where the blockchain received a deposit or deposit authorization, the deposit or any other authorized service charge will be charged to the requesting client, e.g., the bitcoin deposit or a portion thereof will be released to the device or devices who provided the service or a portion of the service fee maybe provided to a device which participated in the results verification.” (Para. 0020).
Li does not disclose:
“merkle path” and “merkle tree” (claim 13).
However, as per Claim 13, Miller in the analogous art of secured digital transactions, teaches: “merkle path” and “merkle tree”. (See “using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks. At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.” (Para. 0164-165); “The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.” (Para. 0155); “using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks.” (Para. 0163).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Li with the technique of Miller to include a storage system for data which includes Merkle path-associated transactions. Therefore, the incentives of providing increased transaction security and speed of cryptographic verification within the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20210226769A1 (Snow), discussing “FIG. 20 illustrates the blockchain network server 28 communicating with the miner system 22 via the communications network 26. The blockchain network server 28 and the miner system 22 operate in the blockchain environment 20. The blockchain network server 28 has a hardware processing component 190 (e.g., “P”) that executes a server-side blockchain software application 192 stored in a local memory device 194. The blockchain network server 28 has a network interface to the communications network 26, thus allowing two-way, bidirectional communication with the miner system 22. The server-side blockchain software application 192 includes instructions, code, or programs that cause the blockchain network server 28 to perform operations, such as sending the inputs 24 (such as the blockchain transactions 32) or the proof-of-work (“PoW”) target scheme 34 via the communications network 26 to the network address (e.g., Internet protocol address) associated with or assigned to the miner system 22. The inputs 24 may be any electronic data 30 that is shared among miners participating in the blockchain environment 20.” (Para. 0064)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697