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 .
DETAILED ACTION
This Office Action is in response to the communication and claim amendment
filed on 02/27/2026. Claims 12-13, 20, and 23 were canceled; claims 2-11, 15-19, 21-22
have been amended. Claims 1-10 and 24 have been examined and are pending.
Election/Restrictions
Applicant's election with traverse of Group I (claims 1-11 and 24) in the reply filed on February 27, 2026 is acknowledged. Claims 14-19 and 21-22 (Group II) are withdrawn from consideration.
Correction of record: The Office Action mailed December 29, 2025 inadvertently omitted claim 22 from Group II. The corrected Group II consists of claims 14-19, 21, and 22.
Applicant's traversal is not persuasive. Under PCT Rule 13.2, the common feature between Groups I and II — "wherein the challenge solution π is a non-interactive zero-knowledge proof proving knowledge of a secret witness w" — is not a special technical feature because it is taught by Karanjai et al. (ACMPUB 27, December 6, 2021, Algorithm 1, lines 10-12). The Examiner notes that Applicant's argument regarding the locking/unlocking script architecture relates to the §103 analysis and does not affect the Unity of Invention analysis, which concerns only whether the common technical feature shared between groups qualifies as a Special Technical Feature.
The requirement is still deemed proper and therefore the restriction is made FINAL.
Drawings
The drawings were received on 10/23/2024. These drawings are reviewed and accepted by the Examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on01/15/2025 are being considered by the examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 2206040.4 filed on Apr. 26, 2022.
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-3, 6, 8, 9-10, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Alfred J. Menezes et al. (“Alfred,” Handbook of APLLIED CRPTOGRAPHY, 1996, pages 414-417) in view of Amos Fiat and Adi Shamir (“Fiat-Shamir,” How to Prove Yourself: Practical Solution to Identification and Signature Problems, 1987, pages 186-194), and Pieter Wullie et al. (“ BIP-340,” 2020-01-19, pages 1-16), further in view of Kalabic et al. (“Kalabic,” US 2021/0374843).
Regarding claim 1, Alfred teaches a computer-implemented method for generating a challenge blockchain transaction, the method comprising:
compute, based on the challenge solution [[it provided in the first locking script]] and one of the target statement and a candidate statement [[provided in the first unlocking script]], a candidate commitment value A* (Alfred: page 415, step 4 (d): “B computes z = β^y · v^e (mod p), and accepts A's identity provided z = x”. Mapping:
"challenge solution π" (i.e. A's transmitted values (commitment x in Step 1, response y in Step 4) , "target statement" (i.e. The public group elements β and v), "candidate commitment value A*" (i.e. The recomputed value z ). Under BRI, Alfred teaches verifier B computing `z = β^y · v^e (mod p)` using:
- A's response y (corresponds to the response component of challenge solution)
- The public statement element v (corresponds to component target statement)
- The challenge e (corresponds to challenge component of challenge solution)
The notation difference between Alfred 's multiplicative notation in Z_p* group and the patent's additive notation on elliptic curves is foundational POSITA knowledge. Multiplicative on cyclic group `β^y` translates to additive on EC as `y·β` (or `yG` when β is the generator). This translation is standard cryptographic knowledge well within POSITA skill”.
Alfred does not explicitly disclose
compute, using the candidate commitment value A* and one of the target statement and the candidate statement, a candidate hash value;
verify, based on the candidate hash value, the challenge solution π;
However, in an analogous art, Fiat-Shamir discloses
compute, using the candidate commitment value A* and one of the target statement and the candidate statement, a candidate hash value (Fiat-Shamir: page 187, Section 2.2: "a pseudo random function f which maps arbitrary strings to the range [0, n)"; page 191, Verification Step 3:”B verifies that the first kt bits of f(m, z_1, ..., z_t) are e_ij."; page 188, Remark 2: "A can hash z_i by sending B only the first 128 bits of f(z_i) in step 3.l Mapping: "candidate commitment value A*" (i.e. z_i values (reconstructed commitments)), "target statement / candidate statement" (i.e. m (message/public data input to f), "candidate hash value" (i.e. Output of function f ). Under BRI,
Fiat-Shamir teaches computing `f(m, z_1, ..., z_t)` using:
- A function f (described as "pseudo random function" on page 187)
- The commitment values z_i (correspond to candidate commitment A*)
- The message m (corresponds to statement)
Under BRI, the patent's "candidate hash value" reads on the output of any function applied to commitment and statement data. A pseudo random function with deterministic output from input data is functionally equivalent to a cryptographic hash function. Fiat-Shamir's own page 188 Remark 2 explicitly uses "hash" as a verb describing this function ("A can hash z_i").
verify, based on the candidate hash value, the challenge solution π (Fiat-Shamir: page 191, Verification Step 3, "B verifies that the first kt bits of f(m, z_1, ..., z_t) are e_ij.". Mapping. "candidate hash value" (i.e. Output of f(m, z_1, ..., z_t), "challenge solution π" (i.e. The (e_ij, y_i) proof package), "verify based on" (i.e. "verifies that... are" (comparison operation)). Under BRI, Fiat-Shamir's verification step uses the recomputed function output `f(m, z_1, ..., z_t)` and compares it against the received e_ij values. Under BRI, "verify based on the candidate hash value" reads on this comparison operation that uses the computed hash value as input to the verification decision.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Fiat-Shamir with the method and system of Alfred to include compute, using the candidate commitment value A* and one of the target statement and the candidate statement, a candidate hash value; verify, based on the candidate hash value, the challenge solution π;. One would have been motivated to use Fiat-Shamir transformation because simpler and faster hash/pseudo-random functions can be used in practice without compromising security (Fiat-Shamir: page 187, section 2.2).
Alfred and Fiat-Shamir do not explicitly disclose verify that the challenge solution it is provided in the proof blockchain transaction.
However, in an analogous art, BIP-340 discloses verify that the challenge solution π it is provided in the proof blockchain transaction (BIP-340 page 10, Input section: "Input: The public key pk: a 32-byte array; The message m: a byte array; A signature sig: a 64-byte array."; page 10, Verification):
"Let r = int(sig[0:32]); fail if r ≥ p. Let s = int(sig[32:64]); fail if s ≥ n.
Mapping: "challenge solution π" (i.e. The signature sig ), "verify... is provided" (i.e sig required as input; algorithm extracts and validates components), "in the proof blockchain transaction" (i.e. Bitcoin transaction context (BIP-340 is Bitcoin specification) ). Under BRI, BIP-340's verification algorithm requires the signature sig as input. The algorithm extracts r from sig[0:32] and s from sig[32:64], failing if these components are out of valid range. Under BRI, the patent's "verify that π is provided" reads on BIP-340's requirement that sig be provided as a structured input for verification to proceed.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of BIP-340 with the method and system of Alfred and Fiat-Shamir to include verify that the challenge solution it is provided in the proof blockchain transaction. One would have been motivated to use BIP-340's Schnorr signature scheme because it provides provable security under standard cryptographic assumptions (ECDLP) (BIP-340: page 2, motivation).
Alfred, Fiat-Shamir, and BIP do not explicitly disclose generating a first locking script of the challenge blockchain transaction comprising a target statement and a verification script for verifying a challenge solution it provided in a first unlocking script of a proof blockchain transaction, wherein the challenge solution it is a non- interactive zero-knowledge proof proving knowledge of a secret witness w, wherein the first locking script, when executed with the first unlocking script; causing the challenge blockchain transaction to be made available to one or more nodes of a blockchain.
However, in an analogous art, Kalabic discloses generating a first locking script of the challenge blockchain transaction comprising a target statement and a verification script for verifying a challenge solution it provided in a first unlocking script of a proof blockchain transaction (Kalabic: par. 0064, "The transaction output data structure 150 also includes a locking script 156 specifying conditions that need to be met in order for the amount to be spent. The locking script 156 and the unlocking script 148 may be executed together to validate the UTXO defined by the transaction input 140 and transaction output 150."; par. [0063]), "These unlocking scripts are used to specify a cryptographic puzzle, which may be needed to be solved in order to spend the UTXO associated with the transaction input data structure 140." wherein the challenge solution it is a non-interactive zero-knowledge proof proving knowledge of a secret witness w (Kabalic: par. 0063; Kabalic provides the blockchain context for the cryptographic puzzle in combination with Fiat-Shamir: page 190, Section 3, "To turn this identification scheme into a signature scheme, we replace B's role by the function f and obtain the following protocol."; page 186, Abstract, "In this paper we describe simple identification and signature schemes which enable any user to prove his identity..." Mapping: "non-interactive" (i.e. "we replace B's role by the function f" (eliminates interaction), "zero-knowledge proof" (i.e. Identification scheme with ZK property; signature inherits), "proving knowledge" (i.e. "prove his identity" ), "of a secret witness w" (i.e. A's private values (secrets)). Under BRI: Fiat-Shamir explicitly teaches converting an interactive identification scheme (a proof of knowledge of a secret) into a non-interactive scheme by replacing the verifier's role with a function. The resulting non-interactive scheme proves knowledge of the same secret without interaction), wherein the first locking script, when executed with the first unlocking script (Kalabic pars. 0006, 0063, 0064), is configured to: causing the challenge blockchain transaction to be made available to one or more nodes of a blockchain (Kalabic: par. [0068], "Debt-credit transactions are broadcast to the network like credit transactions and are added to the memory pool by the blockchain protocol."; paragraph [0082], "In a distributed ledger system, all nodes carry out the process of verifying transaction... If a transaction or block is valid, it may forward this to other nodes in the network. This is known as propagating blocks/transactions throughout the blockchain network."; par. [0073]), "the newly generated debt transactions are broadcast to other nodes and added to the debt pool."
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kalabic with the method and system of Alfred, Fiat-Shamir, and BIP-340 to include generating a first locking script of the challenge blockchain transaction comprising a target statement and a verification script for verifying a challenge solution it provided in a first unlocking script of a proof blockchain transaction, wherein the challenge solution it is a non- interactive zero-knowledge proof proving knowledge of a secret witness w, wherein the first locking script, when executed with the first unlocking script; causing the challenge blockchain transaction to be made available to one or more nodes of a blockchain. One would have been motivated to use Kalabic's locking/unlocking script architecture because it provides a standard mechanism for cryptographic puzzles where spending requires solving a verification condition (Kalabic: par. 0063).
Regarding claim 2, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 1. Kalabic teaches the locking/unlocking script architecture where the two scripts are executed together for validation (Kalabic: par. 0064, "The locking script 156 and the unlocking script 148 may be executed together to validate the UTXO defined by the transaction input 140 and transaction output 150."). While the combination does not explicitly recite comparing a candidate statement with a target statement, configuring the locking script to perform such a comparison within Kalabic's architecture is an obvious design choice — a routine variation of the known locking/unlocking script validation framework. Motivation: A POSITA would be motivated to add this comparison as a routine pre-verification check within Kalabic's locking/unlocking script architecture. KSR (550 U.S. 398, 416-421).
Regarding claim 3, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 1. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches wherein the challenge solution it comprises a target challenge value e and a target answer value z (Fiat-Shamir: Page 191, Section 3.1, Signature Generation, “A computes... y_i = r_i · Π s_j (mod n) for i = 1, ..., t and sends I, m, the e_ij matrix and all the y_i to B.". Under BRI, The prover A sends a proof package containing two types of values to verifier B:1. e_ij matrix — the challenge values2. y_i values — the response/answer values;Alfred: Page 415, Protocol 10.36 (Schnorr Identification Protocol)"A chooses r, 1 ≤ r ≤ q-1, and sends x = β^r mod p to B."From Step 2 (page 415): "B sends to A a (random) challenge e, 1 ≤ e ≤ 2^t."From Step 4 (page 415):"A computes and sends to B the response y = ae + r mod q."Under BRI, The Schnorr identification protocol has TWO communicated values that constitute the proof:1. Challenge e (Step 2)2. Response y (Step 4);BIP-340: Page 4, Design Section (Schnorr Signature Variants),"Two formulations exist, depending on whether the signer reveals e or R:1. Signatures are pairs (e, s) that satisfy e = hash(s⋅G - e⋅P || m)...2. Signatures are pairs (R, s) that satisfy s⋅G = R + hash(R || m)⋅P." Under BRI, BIP-340 explicitly recognizes two formulations of Schnorr signatures:1. (e, s) form — challenge + response2. (R, s) form — commitment + response).
Regarding claim 6, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 1. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches, wherein the candidate statement and the target statement comprise an elliptical curve point generator G and a public key PK associate with the witness (BIP-340 page 6, Specification - Notation:⋅G)." Teaches: the public key derived from the secret key by scalar multiplication with G. Under BRI, BIP-340's sk (secret key) corresponds to the patent's w (witness), and PK = wG is associated with the witness through this derivation; BIP-340 page 10, Verification Input:
Regarding claim 8, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 1. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches, wherein the first locking script is further configured to verify a context information portion of the first locking script, wherein the context information portion is for proving integrity of the proof blockchain transaction (Kalabic: par. 0064, "The locking script 156 and the unlocking script 148 may be executed together to validate the UTXO defined by the transaction input 140 and transaction output 150." BIP-340 page 5, Design — Key Prefixing: "signed transactions indirectly commit to the public keys already, i.e., m contains a commitment to pk.").
Regarding claim 9, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 3. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches wherein the candidate hash value is a candidate challenge value e*, wherein the step of verifying the challenge solution π comprises comparing the candidate challenge value e* and the target challenge value e (Fiat-Shamir: page 191, Section 3.1 Verification; "Verification: 1. B computes the v_j as f(I, j). 2. B computes z_i = y_i² · Π v_j (mod n) for i = 1, ..., t. 3. B verifies that the first kt bits of f(m, z_1, ..., z_t) are e_ij.". Teaches: The verifier recomputes the function output `f(m, z_1, ..., z_t)` and compares it against the stored challenge values `e_ij`. Under BRI:- The recomputed value (first kt bits of f) corresponds to "candidate challenge value e*"- The stored values e_ij correspond to "target challenge value e"- "B verifies that...are" corresponds to "comparing";BIP-340 page 4, Design Section: "Two formulations exist, depending on whether the signer reveals e or R: 1. Signatures are pairs (e, s) that satisfy e = hash(s⋅G - e⋅P || m)." Teaches: The (e, s) Schnorr signature form where verification requires the recomputed hash to equal the stored e value. Under BRI, this is the same compare-recomputed-to-stored-challenge operation).
Regarding claim 10, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 8. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches wherein the candidate hash value is a candidate challenge value e*, wherein the step of verifying the challenge solution π comprises comparing the candidate challenge value e* and the target challenge value e, wherein the candidate challenge value e* is computed using the context information portion, one of the target statement and the candidate statement, and the candidate commitment A* (BIP-340 page 10, Verification Algorithm: "Let e = int(hash_BIP0340/challenge(bytes(r) || bytes(P) || m)) mod n.". BIP-340 explicitly teaches computing the challenge value e by hashing three inputs: bytes(r) — the commitment value (corresponds to candidate commitment A*); bytes(P) — the public key (corresponds to the statement); and m — the message (corresponds to the context information portion). Under BRI, this is the same computation as the patent's e* = hash(context information, statement, A*), with only variable renaming; Fiat-Shamir: 191, Verification Step 3, "B verifies that the first kt bits of f(m, z_1, ..., z_t) are e_ij.". Under BRI, Fiat-Shamir teaches the recompute-and-compare verification mechanism (same as Claim 9). The verifier recomputes the hash value and compares it to the stored challenge value.. A POSITA would be motivated to compute the candidate challenge value using context information, statement, and commitment because BIP-340 teaches this exact computation: "Let e = int(hash_BIP0340/challenge(bytes(r) || bytes(P) || m)) mod n" (BIP-340 page 10). KSR (550 U.S. 398, 416-421).
Regarding claim 24, claim 24 is directed to a non-transitory computer-readable medium storing computer program code that is configured so as, when run on one or more processors (Kalabic: pars. 0097-0098, fig. 9), the one or more processors associated with the method claimed in claim 1; claim 30 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Claims 4, 5, 7, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Alfred J. Menezes et al. (“Alfred,” Handbook of APLLIED CRPTOGRAPHY, 1996, pages 414-417) in view of Amos Fiat and Adi Shamir (“Fiat-Shamir,” How to Prove Yourself: Practical Solution to Identification and Signature Problems, 1987, pages 186-194), further in view of Pieter et al. Wullie (“ BIP-340,” 2020-01-19, pages 1-16), Kalabic et al. (“Kalabic,” US 2021/0374843), further in view of Ueli Maurer (“Maurer,” Unifying Zero-Knowledge Proof of Knowledge, 2009, page 272-286).
Regarding claim 4, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 1. The combination further discloses Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches wherein the non-interactive zero-knowledge proof but does not explicitly disclose “wherein the non-interactive zero-knowledge proof wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ.
However, in an analogous art, Maurer discloses wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ. (Maurer: page 279, Section 5.1, "One-Way Group Homomorphisms":"A function f : G → H is a homomorphism if f(x ⋆ y) = f(x) ⊗ f(y). We will consider the case where f is (believed to be) a one-way function, such that it is infeasible to compute x from f(x) for a randomly chosen x."; page 280, Section 5.2 (Main Protocol Figure 3): "Main protocol: Proof of knowledge, for a given value z, of a value x such that z = [x], where x → [x] is a (one-way) group homomorphism"; page 282, Section 6.1: "The Schnorr protocol is the special case where (G, ⋆) = (Z_q, +)... The (one-way) group homomorphism is defined by G → H : x → [x] = h^x."
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maurer with the method and system of Alfred, Fiat-Shamir, BIP-340, and Kalabic to include wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ. One would have been motivated to prove knowledge of a preimage of a group homomorphism is the abstraction of a large class of protocols (Maurer 2009 page 285, Section 7 Conclusions).
Regarding claim 5, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim 3. Kalabic teaches wherein the non-interactive zero-knowledge proof but does not explicitly teach “wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ, wherein the candidate commitment A* is defined a A* = φ (z) – e * φ (w), where z is the target answer value, e is the target challenge value, and w is the secret witness
However, in an analogous art, Maurer discloses “wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ, wherein the candidate commitment A* is defined as: A* = φ (z) – e * φ (w), where z is the target answer value, e is the target challenge value, and w is the secret witness.” (page 279, Section 5.1, "One-Way Group Homomorphisms":"A function f : G → H is a homomorphism if f(x ⋆ y) = f(x) ⊗ f(y). We will consider the case where f is (believed to be) a one-way function, such that it is infeasible to compute x from f(x) for a randomly chosen x."; page 280, Section 5.2 (Main Protocol Figure 3): "Main protocol: Proof of knowledge, for a given value z, of a value x such that z = [x], where x → [x] is a (one-way) group homomorphism"; page 282, Section 6.1: "The Schnorr protocol is the special case where (G, ⋆) = (Z_q, +)... The (one-way) group homomorphism is defined by G → H : x → [x] = h^x."
Goal to prove that Maurer teaches A* = φ (z) – e * φ (w) ;
(Please see details below)
[r] = t ⊗ z^c is the same as A* = φ (z) – e . φ (w)
SYMBOL-BY-SYMBOL Definitions
Maurer
Application
Meaning
[·], pg. 271, section 5.1
Φ
One-way homeomorphism function
r defined as “the value Peggy sends”, pg. 274, section 2.1
Z
Target answer value
r (response)
z (answer)
Target answer value
c (challenge value), pg. 274
E
Target challenge value
x (witness), pgs. 273-274
W
Secret witness
t (first message), pg. 289, fig. 3 (t := [k])
A*
Candidate commitment value
Step 1: Start with Maurer’s Verifier Check equation
Maurer 2009, page 280, Figure 3.
check [r] ?= t ⊗ z^c
The verifier (Vic) checks whether `[r]` equals `t ⊗ z^c`.
- [r] = f(r) = homomorphism applied to response r (page 279)
- t = the first protocol value (page 280, Figure 3)
⊗ = group operation in group H (page 279)
- z = f(x) = homomorphism applied to witness x (page 279)
- c = challenge value (page 274)
Step 2: Understand z^c Notation
What `z^c` means: z combined with itself c times using the ⊗ operation. (page 279):"We consider two groups (G, ⋆) and (H, ⊗), where we intentionally use special symbols for the group operations, avoiding the addition and multiplication symbols '+' and '·'."*
Interpretation under BRI:
- Maurer's ^ notation denotes repeated application of the ⊗ operation- This is standard mathematical notation for "iteration of a group operation"- In a multiplicative group (where ⊗ is ·): z^c = standard exponentiation- In an additive group (where ⊗ is +): z^c = scalar multiplication c · z (z added c times)
⊗ can be either + or · depending on group choice (page 279)BRI bridge: The translation `z^c` ↔ `c · z` between multiplicative and additive forms is standard cryptographic knowledge well within POSITA skill.
Step 3: Rearrange Maurer's Check Equation to Isolate t
Starting equation (Maurer page 280):
[r] = t ⊗ z^c
Goal: Solve for t.
Step 3a — Apply inverse of `z^c:
In group theory, every group element has an inverse. The inverse of `z^c` under ⊗ is denoted `z^(-c)`.
Apply `z^(-c)` to both sides of the equation:
`[r] ⊗ z^(-c) = t ⊗ z^c ⊗ z^(-c)`
Step 3b — Simplify right side:
By group properties, `z^c ⊗ z^(-c) = identity element`.
So: `t ⊗ z^c ⊗ z^(-c) = t ⊗ identity = t`
Step 3c — Result:
`t = [r] ⊗ z^(-c)`
Note that: This rearrangement uses basic group theory - valid in any group (multiplicative or additive).
Step 4: Translate to Additive Group Notation (Elliptic Curve Context).
Maurer page 279 explicitly states that ⊗ can be either + or ·. The application’s φ operates in the EC additive group (per claim 7 and the spec.).
Translation rules (standard cryptographic)
Multiplicative Group
Additive Group
a . b
a + b
a^n (a multiplied n times)
n . a (a added n times)
a^(-n) (inverse of a^n)
-n . a (additive inverse)
a . b^(-1)
a + (-b) = a - b
Applying to our formula** `t = [r] ⊗ z^(-c)`:Replace ⊗ with + (we're in additive group):`t = [r] + z^(-c)`Replace `z^(-c)` with `-c · z` (additive inverse):`t = [r] + (-c · z)`Simplify (adding a negative = subtraction):`t = [r] - c · z`
Result: `t = [r] - c · z` in additive notation.Note that The multiplicative ↔ additive translation is standard cryptographic knowledge well within POSITA skill. The same operation expressed in different notation systems.
Step 5: Substitute z = [x]
Maurer 2009 page 279, "it is meaningful for a prover Peggy to prove that she knows an x such that for a given value z we have z = f(x)."
And the notation simplification:
"To simplify the notation we write [x] instead of f(x)."
So: `z = [x]`
Substitute into our formula:
`t = [r] - c · z`
Replace z with [x]:
`t = [r] - c · [x]`
Result: `t = [r] - c · [x]` after substitution.
Step 6: Replace [.] Notation with φ Notation
Maurer 2009 page 279 establishes `[x] = f(x)`. The application uses φ instead of f.Equivalence: Maurer's `[·]` notation = Maurer's `f(·)` = application's `φ(·)`.All three notations refer to the same one-way homomorphism function.Substitute φ for [·]
`t = [r] - c · [x]`becomes:`t = φ(r) - c · φ(x)`Result: `t = φ(r) - c · φ(x)` in φ notation.
Step 7: Variable Rename to the Application’s terminology
Maurer variable
Application variable
Maurer Source
t (first protocol value)
A*(Candidate commitment)
pg. 280, fig. 3
r (response)
z (target answer value)
pg. 270
c (challenge)
e (target challenge value)
pg 274
x (witness)
w (secret witness)
pg. 273-274
φ (homomorphism)
φ (homomorphism)
same notation
Apply variable rename:
`t = φ(r) - c · φ(x)`
becomes:`A* = φ(z) - e · φ(w)` `A* = φ(z) - e · φ(w)` — EXACT match to Claim 5's formula.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maurer with the method and system of Alfred, Fiat-Shamir, BIP-340, and Kalabic to include zero-knowledge proof is defined by a one-way homomorphism function φ, wherein the candidate commitment A* is defined as: A* = φ (z) – e * φ (w), where z is the target answer value, e is the target challenge value, and w is the secret witness. One would have been motivated to prove knowledge of a preimage of a group homomorphism is the abstraction of a large class of protocols (Maurer 2009 page 285, Section 7 Conclusions).
Regarding claim 7, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches claim 5. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches, wherein the candidate statement and the target statement comprise an elliptical curve point generator G and a public key PK associate with the witness, wherein the function φ is defined as: φ (x) = Gx wherein the public key is defined as: PK= φ (w) = wG wherein the candidate commitment is computed as: A*= zG - ePK. ( BIP-340 page 6, Specification - Notation: "G is the base point of the curve secp256k1" Teaches: the elliptic curve point generator G. BIP-340 page 6, PubKey Algorithm: "The algorithm PubKey(sk) is defined as: Let d' = int(sk). Fail if d' = 0 or d' ≥ n. Return bytes(d'⋅G)." Teaches: the public key derived from secret as scalar multiplication with G. Under BRI, BIP-340's d' (secret key) corresponds to the patent's w (witness), and the public key is derived as PK = wG.; BIP-340 page 10, Verification Algorithm:
"Let R = s⋅G - e⋅P."
Teaches: the commitment recomputation formula. Under BRI, BIP-340's R = A*, s = z, P = PK. Variable rename yields the patent's formula: A* = zG - ePK.; Maurer page 282, Section 6.1 "Schnorr and GQ as Special Cases":
"The Schnorr protocol is the special case where (G, ⋆) = (Z_q, +)... The (one-way) group homomorphism is defined by G → H : x → [x] = h^x.
Teaches: the Schnorr identification protocol's one-way homomorphism. In additive elliptic curve notation, Maurer's [x] = h^x corresponds to the patent's φ(x) = xG. This translation between multiplicative and additive group notation is standard cryptographic knowledge well within POSITA skill.
Regarding claim 11, the combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic teaches the computer-implemented method of claim e. The combination of Alfred, Fiat-Shamir, BIP-340, and Kalabic further teaches wherein the non-interactive zero-knowledge proof is defined by a one-way homomorphism function φ, wherein the candidate commitment A* is defined as: A* = φ (z) – e * φ (w)where z is the target answer value, e is the target challenge value, and w is the secret witness; wherein the candidate statement and the target statement comprise an elliptical curve point generator G and a public key PK associate with the witness, wherein the function Phi is defined as:
φ (x) = Gx
wherein the public key is defined as: PK = φ (w) = wG
wherein the candidate commitment is computed as: A*= zG - ePK;
wherein the candidate statement and the target statement further comprise at least one additional public key, each public key PKi being associated with a corresponding secret witness wi, and wherein the challenge solution comprises a target challenge value ei and a target answer value zi corresponding to each witness wi, wherein a respective candidate commitment A*i is computed for each witness wi using: A*I = ziG - eiPKi ((a) The homomorphism φ and formula A* = φ(z) − e·φ(w)* (See rejection of claim 5 for full mapping with Maurer, page 279-281);
(b) The EC instantiation φ(x) = Gx, PK = wG, A* = zG − ePK* (See rejection of claim 7 for full mapping with BIP-340 page 6 and page 10)
(c) NEW: Multi-witness extension A*i = zi·G − ei·PKi** Maurer, page 282, Section 6.2 Proof of Knowledge of Several Values:
"Let G_i → H_i : x → [x]^(i) for i = 1, ..., n be (possibly distinct) group homomorphisms... Therefore the main protocol proves in one stroke the knowledge of x_1, ..., x_n such that for given z_1 ∈ H_1, ..., z_k ∈ H_n we have z_1 = [x_1]^(1), ..., z_n = [x_n]^(n)."
Maurer 2009 Section 6.2 explicitly teaches extending the single-witness proof of knowledge protocol to multiple witnesses (x_1, ..., x_n) using parallel application of the same homomorphism framework. Under BRI, the patent's multi-witness formula A*i = zi·G − ei·PKi (for i = 1, ..., r) reads on Maurer's multi-witness extension applied to the EC instantiation taught by BIP-340 (R = s·G - e·P, BIP-340 page 10).
Mere duplication of essential parts: The multi-witness formula A*i = zi·G − ei·PKi is the single-witness formula A* = zG − ePK (claim 7, BIP-340 page 10) repeated for each witness wi. Mere duplication of essential parts of a known formula without producing new and unexpected results is not patentable. See In re Harza, 274 F.2d 669 (CCPA 1960).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
May 22, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights