DETAILED ACTION
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 .
Response to Arguments
In response to 35 USC 112, filed 10/27/2025 on pages 8-9 of the remarks, with respect to 35 USC 112 have been fully considered and are persuasive. The 35 USC 112 rejection has been withdrawn.
In response to 35 USC 102, filed 10/27/2025 on pages 9-11 of the remarks, for independent claims 1, 8, 13, and 17 along with their respective dependent claims, applicant argues that Wan fails to teach “obtaining a program adapted for a zero-knowledge proving scheme that was generated based on the subroutine, wherein the program adapted for the zer0-knowledge proving scheme includes logic to verify that the private data corresponds to manipulation detection codes of the private data”.
The examiner does not concede. Wan teaches “obtaining a program adapted for a zero-knowledge proving scheme that was generated based on the subroutine, wherein the program adapted for the zero-knowledge proving scheme includes logic to verify that the private data corresponds to manipulation detection codes of the private data”. Wan recites “DApp can verify R is indeed computed from some x and h is indeed computed by hashing x and m together. Further, DApp checks validity of the signature σa against h to ensure x is truly authentic [Page 87]”. Shows verifying the private data that corresponds to the manipulation detection codes of the private data (hash value).
Applicant emphasize on the claim language “logic to verify”. That DApp performs the verification outside of the zk-DASNARK circuit. The claim does not mention that the verification needs to be done inside of the zero-knowledge proving scheme. The claim discloses that the a program adapted for a zero-knowledge providing scheme. If the program adapted is being done inside the zero-knowledge proving scheme. Applicant should amend the claims indicating that the program is being done inside the zero-knowledge providing scheme.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Wan et al. (“zk-AuthFeed: How to Feed Authenticated Data into Smart Contract with Zero Knowledge”, hereinafter Wan).
Re. claim 1, Wan discloses a method by a network device implementing a first peer of a distributed ledger to provide trusted execution of a smart contract that uses private data accessible to a second peer of the distributed ledger but not accessible to the first peer, the method comprising: receiving a request to execute the smart contract (Wan discloses Du sends a service request to DApp (Smart contract) [Page 86] Fig. 2); beginning execution of the smart contract (Wan discloses a DApp offers a service in the form of smart contract on the blockchain [Page 87]); detecting, during the execution of the smart contract, a subroutine of the smart contract that uses the private data (Wan discloses private data vector of the DApp user. These three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value. The computation result R is required by the DApp to perform certain operations [Page 86]); obtaining a program adapted for a zero-knowledge proving scheme that was generated based on the subroutine, wherein the program adapted for the zero-knowledge proving scheme includes logic to verify that the private data corresponds to manipulation detection codes of the private data (Wan discloses DApp can verify R is indeed computed from some x and h is indeed computed by hashing x and m together. Further, DApp checks validity of the signature σa against h to ensure x is truly authentic [Page 87]); obtaining a verification key that was generated based on the program adapted for the zero-knowledge proving scheme (Wan discloses depend on the computation task required by the DApp, a circuit C is constructed. Zk-Dasnark.KeyGen [Page 87]; generating a partial execution result of the smart contract (Wan discloses vectors are fed into the zk-Dasnark circuit to compute a computation result R. The validators execute the DApp with the computation result R [Page 87]); providing an identifier of the subroutine to the second peer (Wan discloses DU’s identity ID and time T are published on the blockchain, which can be accessed by everyone (for a public blockchain). A DU is identified by a unique ID in zk-AuthFeed, so that the DU is associated with his/her data. This is to prevent a malicious DU using others’ data as his own data [Page 88]); obtaining a zero-knowledge proof of computation of the subroutine and a public input to the program adapted for the zero-knowledge proving scheme, wherein the zero-knowledge proof was generated by the second peer based on a proving key that was generated based on the program adapted for the zero-knowledge proving scheme (Wan discloses DU checks the DApp specification and obtains the public inputs c from the DApp. DU fetches its private data x (extended with r) and auxiliary input a ={ID, T}. Then zk-DASNARK.Prove(pk, x, c, a) is executed to obtain π as well as the computation result R required by the DApp and a hash value h [Page 87]); determining whether the zero-knowledge proof is valid using the zero-knowledge proving scheme based on the public input and the verification key; determining whether the public input is valid (Wan discloses each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R [Page 87]); restoring an execution state of the smart contract using the partial execution result in response to a determination that the zero-knowledge proof and the public input are valid (Wan discloses each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R [Page 87]); applying effects of the subroutine and resuming the execution of the smart contract after the subroutine to generate a full execution result of the smart contract (Wan discloses three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value h. The computation result R is required by the DApp to perform certain operations. The validators execute the DApp with the computation result R [Page 87]); and providing the full execution result to a consensus mechanism of the distributed ledger (Wan discloses Execution of the DApp depends on consensus of validators, so only if majority of validators be accept the proof can the proof accepted by the DApp [Page 87]).
Re. claim 2, Wan discloses the method of claim 1, wherein the zero-knowledge proving scheme is zero- knowledge succinct non-interactive argument of knowledge (ZK-SNARK) and the program adapted for the zero-knowledge proving scheme is an arithmetic circuit (Zero knowledge proof enables someone to prove some knowledge without leaking any information about that knowledge. The state-of-the-art zero knowledge proof technique is Zero Knowledge Succinct Non-interactive Argument of Knowledge, i.e. zk-SNARK [Page 84]. A zk-Snark for F-arithmetic circuit [Page 85]).
Re. claim 3, Wan discloses the method of claim 1, wherein the partial execution result includes a snapshot of a state of a virtual machine (VM) executing the smart contract (Wan discloses smart contract running in Etherum virtual machine [Page 89]).
Re. claim 4, Wan discloses the method of claim 1, wherein the identifier of the subroutine and the proving key is provided to the second peer via a client component and the full execution result is provided to the consensus mechanism of the distributed ledger via the client component (Wan discloses three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value h. The computation result R is required by the DApp to perform certain operations. The validators execute the DApp with the computation result R . zk-Dasnark.keyGen(pp,c) to output a providing key pk and a verification key vk for proof generation and verification [Page 87]. proving key pk provided to the second peer DU and the providing of the result of the full computation is subject to the consensus of the network of validators in fig 2).
Re. claim 5, Wan discloses the method of claim 1, wherein the public input includes values of inputs to the subroutine, public data used in the subroutine, the manipulation detection codes of the private data, and an output of the subroutine (Wan discloses each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R [Page 87]).
Re. claim 6, Wan discloses the method of claim 5, wherein the effects of the subroutine are applied based on modifying the execution state of the smart contract and pending operations of the distributed ledger to reflect execution of the subroutine (Wan discloses three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value h. The computation result R is required by the DApp to perform certain operations. The validators execute the DApp with the computation result R. Each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R [Page 87]).
Re. claim 7, Wan discloses the method of claim 1, further comprising: providing data related to the request to execute the smart contract to the second peer (Wan discloses Execution of the DApp depends on consensus of validators, so only if majority of validators be accept the proof can the proof accepted by the DApp [Page 87]. Smart contracts can be executed on the blockchain [Page 87] Fig. 5).
Re. claim 8, Wan discloses a method by a network device implementing a second peer of a distributed ledger to provide trusted execution of a smart contract that uses private data accessible to the second peer but not accessible to a first peer of the distributed ledger, the method comprising: receiving a request to execute the smart contract, a proving key, and an identifier of a subroutine of the smart contract for which proof of computation is requested, wherein the subroutine uses the private data (Wan discloses Du sends a service request to DApp (Smart contract) [Page 86]. Three vectors as inputs: one is the private data vector of the DApp user, the second one is the public parameter vector used to compute for the DApp and the third one is a public vector of metadata, identity, time information and a random number [Page 87] Fig. 2); beginning execution of the smart contract and detecting, during the execution of the smart contract, the subroutine (Wan discloses a DApp offers a service in the form of smart contract on the blockchain [Page 87]); obtaining a program adapted for a zero-knowledge proving scheme that was generated based on the subroutine, wherein the program adapted for the zero-knowledge proving scheme includes logic to verify that the private data corresponds to manipulation detection codes of the private data (Wan discloses private data vector of the DApp user. These three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value. The computation result R is required by the DApp to perform certain operations [Page 86]. DApp can verify R is indeed computed from some x and h is indeed computed by hashing x and m together. Further, DApp checks validity of the signature σa against h to ensure x is truly authentic [Page 87]); executing the subroutine and generating a zero-knowledge proof of computation of the subroutine using the zero- knowledge proving scheme based on the program adapted for the zero-knowledge proving scheme, a public input to the program adapted for the zero-knowledge proving scheme, a private input to the program adapted for the zero-knowledge proving scheme, and the proving key (Wan discloses DU checks the DApp specification and obtains the public inputs c from the DApp. DU fetches its private data x (extended with r) and auxiliary input a ={ID, T}. Then zk-DASNARK.Prove(pk, x, c, a) is executed to obtain π as well as the computation result R required by the DApp and a hash value h. Each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R [Page 87]); resuming the execution of the smart contract after the subroutine to generate a full execution result of the smart contract (Wan discloses three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value h. The computation result R is required by the DApp to perform certain operations. The validators execute the DApp with the computation result R [Page 87]); providing, to the first peer, the zero-knowledge proof and the public input (Wan discloses obtains the public inputs c from the DApp. Each of them runs the corresponding function of the DApp smart contract, which executes independently zk-DASNARK.Verify(vk, pka, π, c, a,R, h, σa). If the output of the verification function is 0, validators will drop this transaction; otherwise, the validators execute the DApp with the computation result R. Execution of the DApp depends on consensus of validators, so only if majority of validators be accept the proof can the proof accepted by the DApp.); and providing the full execution result to a consensus mechanism of the distributed ledger (Wan discloses Execution of the DApp depends on consensus of validators, so only if majority of validators be accept the proof can the proof accepted by the DApp [Page 87]).
Re. claim 9, rejection of claim 8 is included and claim 9 is rejected with the same rationale as applied in claim 2 above.
Re. claim 10, rejection of claim 8 is included and claim 10 is rejected with the same rationale as applied in claim 5 above.
Re. claim 11, Wan discloses the method of claim 10, wherein the private input includes the private data (Wan discloses three vectors as inputs one is the private data vector [Page 87]).
Re. claim 12, Wan discloses the method of claim 8, wherein the proving key is generated by the first peer and provided to the second peer via a client component, wherein the zero-knowledge proof is provided to the first peer via the client component and the full execution result is provided to the consensus mechanism of the distributed ledger via the client component (Wan discloses three vectors are fed into the zk-Dasnark circuit to compute a computation result R and a hash value h. The computation result R is required by the DApp to perform certain operations. The validators execute the DApp with the computation result R . zk-Dasnark.keyGen(pp,c) to output a providing key pk and a verification key vk for proof generation and verification [Page 87]. proving key pk provided to the second peer DU and the providing of the result of the full computation is subject to the consensus of the network of validators in fig 2).
Re. claim 13, claim 13 is rejected with the same rationale as applied in claim 1 above. Wan further discloses a set of non-transitory machine-readable media having computer code stored therein, which when executed by asset of one or more processors of a network device (Wan discloses PC with Intel core i7 and 8GB RAM running 64bit [Page 89][Page 83]).
Re. claim 14, rejection of claim 13 is included and claim 14 is rejected with the same rationale as applied in claim 2 above.
Re. claim 15, rejection of claim 13 is included and claim 15 is rejected with the same rationale as applied in claim 5 above.
Re. claim 16, rejection of claim 15 is included and claim 16 is rejected with the same rationale as applied in claim 6 above.
Re. claim 17, claim 17 is rejected with the same rationale as applied in claim 8 above. Wan further discloses a set of non-transitory machine-readable media having computer code stored therein, which when executed by asset of one or more processors of a network device (Wan discloses PC with Intel core i7 and 8GB RAM running 64bit [Page 89][Page 83]).
Re. claim 18, rejection of claim 17 is included and claim 18 is rejected with the same rationale as applied in claim 2 above.
Re. claim 19, rejection of claim 17 is included and claim 19 is rejected with the same rationale as applied in claim 5 above.
Re. claim 20, rejection of claim 17 is included and claim 20 is rejected with the same rationale as applied in claim 11 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. “A privacy-protecting Authorization System Based on Blockchain and zk-SNARK” discloses Using the zero-knowledge property of zk-SNARK, the SP can still authorize the users without knowing the identity attribute value of the users. Therefore, the proposed system can better protect the users’ attribute privacy. Finally, we analyze the security of the proposed system, and the results show that it is computationally infeasible for an attacker to attack the system.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496