DETAILED ACTION
Status of Application
The following is a Final Office Action. In response to Examiner's communication on 08/14/2025, Applicant on 12/15/2025, amended Claims 1, 13, 18. Claims 1-20 are now pending in this application and have been rejected below.
Response to Amendment
Applicants’ amendments render moot the 35 USC 103 rejections set forth in the previous action in view of new and updated grounds for rejection necessitated by Applicants’ amendments. Therefore, these rejections are withdrawn in view of the new grounds for rejection necessitated by Applicants’ amendments, as set forth below.
Response to Arguments – 35 USC § 103
Applicant' s arguments with respect to the rejection of Claims 1-20 under 35 USC 103 have been considered but are moot in light of new grounds of rejections necessitated by applicant’s amendments.
As outlined below, the newly introduced Tapolcai reference discloses newly amended limitations. Therefore, Examiner respectfully notes that rejections have been updated to address the amendments below.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim 18 recites,
“A system including: means for accessing a registered task on a ledger…”,
“means for accepting the registered task”,
“means for performing the registered task”.
“means for facilitating…”.
In accordance with the proper interpretation under 35 U.S.C. 112(f), we look to [71-72] of the specification, “The circuitry may further include or access instructions for execution by the circuitry. The instructions may be embodied as a signal and/or data stream and/or may be stored in a tangible storage medium that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may particularly include a storage medium and instructions stored in or on the medium, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings. The implementations may be distributed as circuitry, e.g., hardware, and/or a combination of hardware and software among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems.” The aforementioned definitions of circuitry and product serve to guide the interpretation of Claim 18.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 13, 18 recite “the solver output including an indication of an injected metering, the injected metering indicating correct execution of at least a first portion of the task code…facilitating…solver penalty reduction based on the indication of the injected metering”.
On Page 4 of the specification, in paragraph [22], it is outlined that metering is used as one of ordinary skill in the art would conventionally understand the term, namely as a gauge of computational effort expended. However, it is never taught that metering can be used to “verify correct execution”, or how one of ordinary skill in the art might use said metering to facilitate “solver penalty reduction”.
In order to satisfy the written description requirement, each claim limitation must be expressly or inherently supported by the disclosure. MPEP 2163 (emphasis added). “The 'written description' requirement implements the principle that a patent must describe the technology that is sought to be patented; the requirement serves both to satisfy the inventor's obligation to disclose the technologic knowledge upon which the patent is based, and to demonstrate that the patentee was in possession of the invention that is claimed.” Capon v. Eshhar, 76 USPQ2d 1078, 1084 (Fed. Cir. 2005). Further, the written description requirement promotes the progress of the useful arts by ensuring that patentees adequately describe their inventions in their patent specifications in exchange for the right to exclude others from practicing the invention for the duration of the patent's term. See MPEP 2163 (emphasis added).
For claims directed toward computer-implemented functions, like the presently claimed invention, “[i]f the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed computer to perform the claimed function, a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made.” MPEP 2161.01 (emphasis added). It is not enough that one skilled in the art could write a program to achieve the claimed function because the written description requirement requires that the specification explains how the inventor intends to achieve the claimed function. Examining Claims for Compliance with 35 USC 112(a) - PowerPoint of Computer Based Training, Slides 20 & 21, (emphasis added) available at http://www.uspto.gov/sites/default/files/documents/uspto_112a_ part1_17aug2015.pptx. The ability of one skilled in the art to make and use the claimed invention does not satisfy the written description requirement if details of how the function is to be performed are not disclosed. Id. at Slide 20.
Claims 2-12, 14-17, and 19 & 20 depend on claims 1, 13, and 18, respectively, and do not cure the aforementioned deficiencies, and thus, these claims are rejected for the reasons set forth above as a result of their dependency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-4, 6-10, 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Teutsch(A scalable verification solution for blockchains, 2017) in view of Gonnaud(US 20210174432 A1) in further view of Tapolcai(US20090182814A1).
Claims 1, 13, 18
As to Claim 1,
Teutsch teaches:
A method including: accessing a registered task on a ledger, the registered task including: a reference to executable task code;
On p. 5, "Smart contracts, introduced in 1994 by Szabo [61] and first realized in the Ethereum [11] cryptocurrency in 2015, are uncensorable programs that live on Ethereum’s blockchain and have their own executable code and internal states, including storage for variable values and ether currency balance...TrueBit itself is an Ethereum smart contract which allows users to call TrueBit contracts for trusted, computationally-intensive applications". It would be apparent to one of ordinary skill in the art that such smart contracts, with executable code, exist on a ledger in Ethereum.
and a designation of a solver token set;
On p. 17-18, "Any Ethereum user who offers a reward through TrueBit for performing a computational task is called a Task Giver. A party which offers a solution for performing these tasks in exchange for a reward is called a Solver". The promised reward is the solver token set.
accepting the registered task by registering a solver token counter-set on the ledger; performing the registered task by: executing the task code to generate a solver output
On p. 20, "TrueBit requires deposits from Solvers and Verifiers in order to thwart Sybil attacks (see Section 5.1) and incentivize correct computations. We set these deposits to be more than the expected jackpot payout for a given task plus the cost of playing a verification game. In particular, the deposits must be large enough to: 1. pay for the (expensive) cost of a verification game, including all rewards and penalties for Solver and Challengers and work done by Judges". The counter-set, a source of funding for the verification game and the solver's stake in the veracity of their computation, is the deposit. On p. 17-18, "Any Ethereum user who offers a reward through TrueBit for performing a computational task is called a Task Giver. A party which offers a solution for performing these tasks in exchange for a reward is called a Solver".
within a timeout window,
In p.24, "the timeOut for accepting bids, performing the computation, and waiting for a challenge. In the protocol below, we do not distinguish between these various timeouts with distinct notation, and we colloquially use “timeOut” to refer to both events and lengths of time. In all cases, timeOut must be long enough to avoid microforks during which Referees temporarily disagree on current parameters...The Solver privately computes task. In case of a timeOut, Solver forfeits his deposit to the jackpot repository and the protocol terminates".
generating a solver commitment by encrypting the solver output; and causing recordation of the solver commitment on the ledger;
On pg. 22, "The Solver establishes property 2. above by committing both a hash of a “correct” solution and a hash of an “incorrect” solution prior to the broadcast of the block hash from item (b)".
and at a time the solver fully executes the task code and responsive to a verifier causing recordation of a verifier commitment for the registered task on the ledger, facilitating comparison of a corresponding verifier output with the solver output by releasing a solver key for the solver commitment.
The commitments of verifiers is outlined on p. 24, "Verifiers who have posted minDeposit can challenge (the hash of) solution until timeOut. Prior to timeOut, the Verifier must broadcast the hash of an even integer to the blockchain in order to commit to a challenge".
The mechanics following a challenge are outlined on pg. 25, "Solver reveals his private random string r on the blockchain, and Referees check it against his commitment from preprocessing step 3. If the hash of the concatenation of r and the block hash following the solution announcement from 3(b) is small (as determined by the forced error rate, see Section 4.1), then a forced error is in effect (see Section 4.4)". Given that mechanics of facilitating this comparison are undisclosed, we understand the private random string to be such a key that enables the system to determine if the verifier output is being compared to a forced error solution. Note that commitment to the blockchain corresponds to an execution attempt on the solver’s part.
Teutsch does not expressly disclose the remaining limitations.
However, Gonnaud teaches:
the timeout window being specified as a number of block addition occurrences allowed for a timing ledger before a timeout occurs;
In [0194], "In an example, the timer is actually run by the blockchain itself. Instead of being based on a clock running on a server, the timer is based on a number of blocks processed by the blockchain (e.g. “the time limit is reached in 10 blocks, approximately 2 mins”)".
Teutsch discloses a system for streamlining the verification of tasks assigned in a blockchain environment. Gonnaud discloses a system meant to streamline the usage of a database in a blockchain environment. Each reference discloses systems meant to enhance the management of tasks in a blockchain environment. Extending the timing functionality as recorded in Gonnaud to the system of Teutsch is applicable as both are pertained with the task of enhancing task management in a blockchain environment.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the time management as taught in Gonnaud and apply that to the architecture as taught in . Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the timekeeping metric through block additions might enable users to accommodate the inherent latency in a decentralized network/variations in node clocks, and alternatively obviate risks pertaining to timestamp manipulation in Ethereum.
Teutsch combined with Gonnaud does not expressly disclose the remaining limitations.
However, Tapolcai teaches:
the solver output including an indication of an injected metering, the injected metering indicating correct execution of at least a first portion of the task code
In [0059], “Another important task of the Progress Agent is to speed up the finishing of solving the MIP problem by intelligently identifying the bottlenecks of computational speed, and possibly re-assigning some sub-problems to relatively fast computers that are part of the peer to peer network. At each level of hierarchy the PA may collect all the statistical data on the status of the calculation and aggregated status information may be sent back to the parents. In such a way the user that initiated the calculation can always keep track of the actual status of the problem (e.g. the number of computers are working on the problem, approximately what percent of the problem has been solved)”. Note that here our injected metering is our tracking of problem status.
at a time the solver fails to fully execute the task code, facilitating solver penalty reduction based on the indication of the injected metering;
Our view of penalty reduction is that we adjust the complexity of the problem to be solved in light of our status tracking, or injected metering, with subsequent reassignment of problem solving. In [0080], “An MIP user may wish to request a time limit for getting back a solution. The present invention may use the time limit for load balancing purposes as well. In the proposed framework, the input of the problem may consist of an MIP (denoted by MIPorig) problem along with a time limit to obtain the solution. The solver may return the best solution found so far within the time limit, and a second MIP problem (denoted by MIPrest), which is the union of the unsolved sub-problems. When a computer receives a problem it may estimate the computational expense of the problem, and decide how many and which active nodes should be sent out so that the rest of the sub-tree may be solved before the end of the time limit. In such a way the problem may spread along the network, and by the end of the time limit the last children may send back either the results or generate an MIP sub-problem that they have not been able to solve. Their parents may collect these MIP and merge them together with their unsolved sub-problems into a single MIP problem which may be sent back to their parents, and so on. Finally the root node may receive the MIPcomp problems that were not solved within the time limit. If the user is not satisfied with the quality of the obtained solution, it has the MIPres problem, and can solve it later at any time to get a better solution on the original problem”.
Claims 13 and 18 are rejected as presenting substantially similar limitations as Claim 1.
Claim 13 additionally recites “machine-readable media other than a transitory signal; and instructions stored on the machine-readable media”.
Claim 18 recites “means for accessing a registered task…”. In accordance with the Broadest Reasonable Interpretation of these claims in light of the specification, we can interpret the above limitation of Claim 13 to be one such means of performing the operations described. In Gonnaud, [0028] addresses these limitations, teaching “According to a second aspect of the invention, there is provided a user system for a blockchain version control system, the blockchain version control system including a smart contract version control system, the user system including a processor system and a database system, wherein…”.
Claims 2, 14
As to Claim 2, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, further including asserting control of the solver token set at a time that: the verifier output matches the solver output; or the verifier output includes an error.
According to the broadest reasonable interpretation of the claim, we understand this assertion of control to analogize to effecting a disbursement of the reward associated with the task by the task giver, to the solver once his solution has been vindicated. In p.25-26, "The Solver collects reward only once he wins all of the challenges, and if this does not happen, then the Task Giver receives a refund on his reward, and tax payments are reimbursed through Solver’s deposit as described below. A. If Solver wins, then Verifier forfeits half of her deposit to the jackpot repository and the other half to the Solver, where the latter suffices to compensate the Solver for playing the verification game (see Section 4.3)".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the timekeeping mechanisms of Gonnaud and apply that to the system as taught in Teutsch. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 14 is rejected as presenting substantially similar limitations as Claim 2.
Claim 3
As to Claim 3, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, further including surrendering the solver token counter-set at a time that: the verifier output differs from the solver output; and the solver output includes an error.
According to the broadest reasonable interpretation of the claim, we understand this assertion of control to analogize to effecting a disbursement of the deposit associated with the task by the solver, when the solver output has been proven incorrect. In page 26., "Otherwise Verifier wins. Solver pays at most half of his deposit to the Verifier(s), according to the distribution scheme in Step 4(b)ii above, pays back the Task Giver’s taxes out of this amount, and forfeits the remaining funds to the jackpot repository (see Section 5.1 and Section 5.2)".
Claim 15 are rejected as presenting substantially similar limitations as Claim 3.
Claim 4
As to Claim 4, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch does not expressly disclose the remaining limitations.
The method of claim 1, where the timing ledger includes the ledger.
In [0194], "In an example, the timer is actually run by the blockchain itself. Instead of being based on a clock running on a server, the timer is based on a number of blocks processed by the blockchain (e.g. “the time limit is reached in 10 blocks, approximately 2 mins”)".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the timekeeping mechanisms of Gonnaud and apply that to the system as taught in Teutsch. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claims 6, 16
As to Claim 6, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, where executing the task code to generate a solver output includes executing a smart contract.
On p. 5, "Smart contracts, introduced in 1994 by Szabo [61] and first realized in the Ethereum [11] cryptocurrency in 2015, are uncensorable programs that live on Ethereum’s blockchain and have their own executable code and internal states, including storage for variable values and ether currency balance...TrueBit itself is an Ethereum smart contract which allows users to call TrueBit contracts for trusted, computationally-intensive applications". It would be apparent to one of ordinary skill in the art that such smart contracts, with executable code, exist on a ledger in Ethereum.
Claim 16 is rejected as presenting substantially similar limitations as Claim 6.
Claim 7, 17
As to Claim 7, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, where encrypting the solver output includes encrypting the solver output using an encryption scheme that allows for verification, using the solver key, that the solver commitment was generated based on the solver output.
The mechanics following a challenge are outlined on pg. 25, "Solver reveals his private random string r on the blockchain, and Referees check it against his commitment from preprocessing step 3. If the hash of the concatenation of r and the block hash following the solution announcement from 3(b) is small (as determined by the forced error rate, see Section 4.1), then a forced error is in effect (see Section 4.4)". We understand the private random string to be such a key that enables the system to determine if the committed solution corresponds to the forced error or is an honest execution of the output.
Claim 17 is rejected as presenting substantially similar limitations as Claim 7.
Claim 8
As to Claim 8, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, where the registered task includes a task assigned by a task giver, where: the task giver designates the solver token set.
On p. 17-18, "Any Ethereum user who offers a reward through TrueBit for performing a computational task is called a Task Giver. A party which offers a solution for performing these tasks in exchange for a reward is called a Solver". The promised reward is exactly the solver token set.
Claim 9, 19
As to Claim 9, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, where the registered task further includes a designation of a verifier token set,
In p.19, "Given that a jackpot repository must exist, we now describe the mechanism for funding it...Any Task Giver that calls a TrueBit contract must pay not only the cost of computational work done by the Solver but also for the work done by the Verifier(s) (excluding unforced errors and bogus challenges), as well as the work done by Referees and Judges. We refer to the latter two costs as the verification tax".
the verifier token set available to the verifier when: the verifier output matches the solver output; or the verifier output differs from the solver output, and the solver output includes an error.
In page 26., "Otherwise Verifier wins. Solver pays at most half of his deposit to the Verifier(s), according to the distribution scheme in Step 4(b)ii above, pays back the Task Giver’s taxes out of this amount, and forfeits the remaining funds to the jackpot repository (see Section 5.1 and Section 5.2)". Citing pg. 25 for 4(b)ii, "If no Verifier challenges Solver’s secondary solution before timeOut, then Verifier wins a fraction the maximum jackpot amount J, scaled for task difficulty", the jackpot being funded by the verification tax that we analogize to the verifier token set as outlined above. Note that this applies to the case of the solver output including an error.
Claim 19 are rejected as presenting substantially similar limitations as Claim 9.
Claims 10, 20
As to Claim 10, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch teaches:
The method of claim 1, further including reasserting control of the solver token counter- set
According to the broadest reasonable interpretation of the claim, we understand this reassertion of control to analogize to effecting a disbursement of the deposit associated with the task by the solver, when the solver output has been proven incorrect. In page 26., "Otherwise Verifier wins. Solver pays at most half of his deposit to the Verifier(s), according to the distribution scheme in Step 4(b)ii above, pays back the Task Giver’s taxes out of this amount, and forfeits the remaining funds to the jackpot repository (see Section 5.1 and Section 5.2)".
and asserting control of the solver token set.
According to the broadest reasonable interpretation of the claim, we understand this assertion of control to analogize to effecting a disbursement of the reward associated with the task by the task giver, to the solver once his solution has been vindicated. In p.25-26, "The Solver collects reward only once he wins all of the challenges, and if this does not happen, then the Task Giver receives a refund on his reward, and tax payments are reimbursed through Solver’s deposit as described below. A. If Solver wins, then Verifier forfeits half of her deposit to the jackpot repository and the other half to the Solver, where the latter suffices to compensate the Solver for playing the verification game (see Section 4.3)".
Claim 20 is rejected as presenting substantially similar limitations as Claim 10.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Teutsch(A scalable verification solution for blockchains, 2017) in view of Gonnaud(US 20210174432 A1) in further view of Tapolcai(US20090182814A1) in further view of Dienes(How Ethereum Layer 2 Scaling Solutions Address Barriers to Enterprises Building on Mainnet, 2020).
Claim 5
As to Claim 5, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch does not expressly disclose the remaining limitations.
Gonnaud teaches:
The method of claim 1, where the timing ledger
In [0194], "In an example, the timer is actually run by the blockchain itself. Instead of being based on a clock running on a server, the timer is based on a number of blocks processed by the blockchain (e.g. “the time limit is reached in 10 blocks, approximately 2 mins”)".
Teutsch combined with Gonnaud does not expressly disclose the remaining limitations.
However, Dienes teaches:
"We construe the ability of Layer 2 blockchain networks to support off-mainnet transactions as a separate ledger, in Dienes, "Certain L2 technologies (such as validium, side chains, and Arbitrum SCSC) are able to keep all L2 data within the L2 instance and off of L1.If multiple companies are writing data to the same shared L2 instance, they will be able to see each other’s data (like a consortium), but if a company has its own instance then the data can be kept private.”.
Teutsch combined with Gonnaud discloses a system for enhancing the verification of issued tasks in a blockchain environment. Dienes discloses a system meant to incorporate a multi-layered approach to performing blockchain operations. Each reference discloses means for streamlining the performance of operations on the blockchain. Extending the multi-layered blockchains as recorded in Dienes to the system of Teutsch combined with Gonnaud is applicable as they are both pertained to the developing improvements to a blockchain environment.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to incorporate the multi-layered architecture as taught in Dienes and apply that to the system as taught in Teutsch combined with Gonnaud. Motivation to do so can be found in the text of Dienes, “Layer 2 is a set of technologies or systems that run on top of Ethereum (Layer 1), inherit security properties from Layer 1, and provide greater transaction processing capacity (throughput), lower transaction fees (operating cost), and faster transaction confirmations than Layer 1”. Performing the timing operations off-ledger would facilitate the syncing of timing operations to transactions performed on a Layer 2 network, which would serve the benefits outlined here.
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Teutsch(A scalable verification solution for blockchains, 2017) in view of Gonnaud(US 20210174432 A1) in further view of Tapolcai(US20090182814A1) in further view of Aguinaga(Part three: creating and signing).
Claim 11
As to Claim 11, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch combined with Gonnaud does not expressly disclose the remaining limitations.
However, Aguinaga teaches:
The method of claim 1, where accepting the registered task includes recording a digitally- signed acceptance to the ledger
Such an architecture is implicit to the Ethereum architecture disclosed in the Teutsch whitepaper. "In addition, blockchain transactions require no verification from any central party. For transactions to be valid, they only need to be signed with a private key using the Digital Signature Algorithm (DSA) corresponding to their blockchain. Ethereum and Bitcoin blockchains use the ECDSA algorithm, whereas other projects like Cardano or Polkadot rely on the EdDSA algorithm. Both rely on Elliptic Curves, yet the latter uses twisted Edwards curves, an improvement on generic digital signatures. Although a transaction can be signed by any private key, transfer transactions will only be executed successfully if the account connected to the private key used to sign the transaction contains enough funds".
Aguinaga discloses the signing mechanism implicit to the Ethereum architecture that the Teutsch whitepaper is built on. Teutsch combined with Gonnaud discloses a system for enhancing the verification of issued tasks in a blockchain environment. Each reference discloses means for interfacing with the blockchain. Extending the signing mechanism as recorded in Aguinaga to the system of Teutsch combined with Gonnaud is applicable as they are disclosed as being inherently performed as part of Ethereum. As recited in the abstract of the Teutsch whitepaper, “The system described herein bypasses this bottleneck and brings scalable computation to Ethereum…In addition to secure outsourced computation, immediate applications include decentralized mining pools whose operator is an Ethereum smart contract.”
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to extending the signing mechanism as recorded in Aguinaga to the system of Teutsch combined with Gonnaud. Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting such a signing mechanism would enable users to verify their transactions without a central governing party. Further evidence for the motivation to combine lies in Ethereum’s actual implementation of such a signing protocol.
Claim 12
As to Claim 12, Teutsch combined with Gonnaud teaches all the limitations of Claim 1 as discussed above.
Teutsch combined with Gonnaud does not expressly disclose the remaining limitations.
However, Aguinaga teaches:
The method of claim 1, further including causing recordation of an attempt to execute the task code, where the recordation of the attempt is signed using a client key specific to a solver.
Such an architecture is implicit to the Ethereum architecture disclosed in the Teutsch whitepaper. "In addition, blockchain transactions require no verification from any central party. For transactions to be valid, they only need to be signed with a private key using the Digital Signature Algorithm (DSA) corresponding to their blockchain. Ethereum and Bitcoin blockchains use the ECDSA algorithm, whereas other projects like Cardano or Polkadot rely on the EdDSA algorithm. Both rely on Elliptic Curves, yet the latter uses twisted Edwards curves, an improvement on generic digital signatures. Although a transaction can be signed by any private key, transfer transactions will only be executed successfully if the account connected to the private key used to sign the transaction contains enough funds.”
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to extend the signing mechanism as recorded in Aguinaga to the system of Teutsch combined with Gonnaud. Motivation to do so comes from the same rationale as outlined above with respect to Claim 11.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE L XIE whose telephone number is (571)272-7102. The examiner can normally be reached M-F 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached at 571-272-6045. 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.
/THEODORE XIE/Examiner, Art Unit 3623
/CHARLES GUILIANO/Primary Examiner, Art Unit 3623