Detailed Action
1. This communication is in response to Amendment filed on March 18, 2026 in which claims 1-20 are pending in the application. Claims 1, 11, and 16 are the independent claims.
Notice of Pre-AIA or AIA Status
2. 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 Amendment
3. This Office Action is in response to the applicant’s remarks and arguments filed on March 18, 2026.
Claims 1, 11, and 16 are amended. Claims 1-20 remain pending in the application. Claims 2-10, 12-15, and 17-20 filed on October 21, 2025 are being considered on the merits along with amended claims 1, 11, and 16.
Response to Arguments
4. Applicant’s arguments, see Remarks and Claims, filed March 18, 2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 112 and 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of 35 U.S.C. 112 and 35 U.S.C. 103.
In the Interview Summary section on page 8 of the Remarks, the Applicant states that the Examiner has agreed to the amendments overcoming the prior art.
The Examiner respectfully agrees with the Applicant regarding the previous rejections being overcome by the Amendments to the claims. Following additional search and review of the claims, new rejections under 35 U.S.C. 112 and 35 U.S.C. 103 have been introduced in this Office Action
In the Claim Rejections - 35 U.S.C. 112 section on pages 8-9, the Attorney states that claim 11 has been amended to overcome the previous rejection and requests withdrawal of the rejection.
The Examiner respectfully agrees with the Attorney that claim 11 overcomes the previous rejection under 35 U.S.C. 112. However, the Examiner has introduced new rejections under 35 U.S.C. 112 following amendment by the Applicant based on the addition of relative terms to the claims. The rejections appear in section 5 of the Office Action below.
In the Claim Rejections – 35 U.S.C. 103 section on pages 9-10, the Attorney states that the amended claims overcome the previous rejections and requests withdrawal of the rejections.
The Examiner respectfully agrees with the Applicant that the claim amendments overcome the previous rejections set forth under 35 U.S.C. 103. However, the Examiner has introduced new rejections under 35 U.S.C. 103 following amendment by the Applicant. The Applicant submitted multiple points regarding the prior art reference Ferrin which is no longer used in the rejection of the independent claims 1, 11, and 16. The independent claims are rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
5. Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “recent block” in independent claims 1, 11, and 16 is a relative term which renders the claim indefinite. The term “recent block” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. There is no clarification as to how recency is determined or what exactly the cut-off for being a “recent block” is.
Additionally, dependent claims 3, 13, and 18 include the term “recent block” which is a relative term which renders the claims indefinite. The term “recent block” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. There is no clarification as to how recency is determined or what exactly the cut-off for being a “recent block” is.
Finally, all dependent claims of independent claims 1, 11, and 16 do not clarify the term “recent block” which is a relative term which renders the claims indefinite. These claims do not fix the indefinite nature of the limitations in independent claims 1, 11, and 16, so these claims are additionally rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter relating to “recent block” which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
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.
6. Claims 1, 4, 6, 8-9, 11, 14, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) – hereinafter “Wright” in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418).
Regarding independent claim 1, Wright discloses:
A computer-implemented method, comprising:
generating a key-value mapping associating a public key with a corresponding transaction state value within a virtual machine environment, the key-value mapping structured according to hierarchical naming rules defining relationships among keys and sub-keys; ([0195] “For example, Alice 103a may store the expected hash result, or a shortened version of the expected hash result (e.g. the first four leading bytes), in a look-up table together with (i.e. mapped to a corresponding expected public key and/or a transaction identifier of the first transaction. In other words, the (shortened) expected hash result is the key of a key-value
pair, where the value is the expected public key and/or transaction identifier. The look-up table may comprise several key-value pairs of this type, for different hash results, public keys and transaction identifiers. Alice 103a may use the (shortened) expected hash value as a look-up to find the corresponding public key and/or transaction identifier.” and [0236] “HASH 160 always produces the same output address for the same public key. An attacker can simply associate the same hashed public key values together if the private-public key pair is reused. Once the unlocking public key is revealed during a transaction the attacker can link all those hashed value to the public key and the mask is redundant. It is therefore recommended that users create a new public key for each transaction. This can be laboursome and requires each new public key to be transmitted to the funding party for each new transaction.” and [0160] “FIG. 7 illustrates an example of a hierarchical deterministic (HD) set of keys, also known as a HD wallet. Here, the master key is generated based on a seed. The child keys in each set of child keys are each generated based on the master key. The grandchild keys in each respective set of grandchild keys are each generated based on a respective set of the child keys. In this example, the master key is the parent key. However, the labels “parent” and “child” may be used to refer to a public key in an n.sup.th level and public key an (n+1).sup.th level, wherein the public key in the (n+1).sup.th level is generated based on the public key in the n.sup.th level.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value mapping between a hash result and public key and/or transaction identifier maps the relationship between each public key and the transaction state since each transaction is recommended to have a new public key. Also, the public keys and their children show examples of hierarchical deterministic set of keys.
constructing, via the client device, a [transaction] comprising a public key, the block hash, and the proof of work request threshold; ([0043] “The input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction 152i is locked. In turn, the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b. The present transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the present transaction 152j.” and [0046] “In addition to validating transactions, blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by “proof-of-work”. At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a “nonce” value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros.” and [0080] “Typically an input of a transaction contains a digital signature corresponding to a public key P.sub.A. In embodiments this is based on the ECDSA using the elliptic curve secp256k1. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the transactions that are constructed include public key, block hash, and proof of work threshold of a fixed length such that it requires a certain predefined number of leading zeros.
validating the [transaction] using encrypted keys mapped in the key-value mapping; and ([0122] “The expected data item may be an expected public key, e.g. Bob's public key PK.sub.B. In this example, the expected hash result may be used as a blockchain address. As well as requiring the expected data item to be an expected public key, the first locking script may require the unlocking script of Tx2 to comprise a signature generating using a private key corresponding to the expected public key. For instance, the first locking script may require the unlocking script to comprise Bob's public key PK.sub.B (which hashes to the expected hash result), and Bob's signature generated using Bob's private key sk.sub.B. This form of locking script is often referred to as a pay-to-public-key-hash (P2PKH) script.” and [0281] “However, Alice could set the q value to be sufficiently high such that an unknown solving party could generate a private-public key pair that satisfied the address system off-line, on average, over the course of days for example. This would ensure that it would not be feasible for a rogue Bitcoin node to generate their own satisfactory private-public key pair in the average mining time for a block (10 minutes). Assuming that there are at least some good miners, the original transaction would be validated and published into the bitcoin network before a bad Bitcoin node could generate a replacement transaction to steal the associated funds.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the transaction is validated based on the private-public key pair that cannot be broken within the time to mine the average block.
generating a new block including one or more validated [transactions] each having block hashes that surpass the pre-selected complexity. ([0039] “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure.” and [0046] “In addition to validating transactions, blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by “proof-of-work”. At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a “nonce” value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the new block is created following consensus between nodes and transactions being validated such that the hash is required to meet a predetermined condition for a difficult calculation that can be checked by other users for its proper level of complexity/correctness.
Wright does not explicitly disclose:
requesting, with a client device, a block hash from a recent block for a transaction, and a pre-selected complexity threshold, the pre-selected complexity threshold defined by computational power required to validate the transaction based on network load, wherein transactions with greater complexity relative to the pre-selected complexity threshold are prioritized for block inclusion;
generating, via the client device, the requested block hash by applying a proof of work request threshold to achieve the pre-selected complexity threshold;
… virtual machine transaction …
However, Bres discloses:
requesting, with a client device, a block hash from a recent block for a transaction, and a pre-selected complexity threshold, the pre-selected complexity threshold defined by computational power required to validate the transaction based on network load, wherein transactions with greater complexity relative to the pre-selected complexity threshold are prioritized for block inclusion; ([0033] “The a fifth entry 450 is included in the data structure 400 when the data structure 400 is not the initial block in the block chain. The fifth entry 450 includes a hash value of a previous block in the block chain. The hash value of the previous block is computed based on the first entry and the second entry of a previous data structure.” and [0035] “The mildly intensive computation can be designed to require a desired amount of time. To determine the desired amount of time, assume that a time to obtain new data 410 in FIG. 1 to add to the block chain is T. … When proof of work time is significantly less than T, an attack can be mounted on the block chain because a malicious processor can falsify information in the last block in the block chain before a new block is added. If the proof of work time is significantly greater than T, a backlog of new data will be created because of a delay in creating a block containing the proof of work value 510 to add to the block chain.” and [0036] “For example, as shown in FIG. 5, the proof of work value 510 can be a value that when hashed with the contents of the data structure 500 produces a hash value that has the required number of zeros 520. The required number of zeros can be 0, 1, 2, 3, 4. The higher the number of zeros required, the higher the computation needed to find the proof of work value 510.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the block hash value 450 certifies the integrity of the block and the proof of work value 510 can be iteratively modified by increasing the required number of zeros (for example, increasing from 0 to 1 required zeros, testing the complexity and finding it does not meet or exceed the pre-selected complexity threshold, then increasing from 1 to 2 required zeros and repeating the process until the pre-selected complexity threshold is reached) which increases the complexity and computation needed to find the proof of work value 510. The proof of work value increases over time to insure the blockchain cannot have previous data edited/attacked to falsify the blockchain’s previously certified results.
generating, via the client device, the requested block hash by applying a proof of work request threshold to achieve the pre-selected complexity threshold; ([0045] “In step 720, the processor can efficiently add a block to the block chain by encrypting the data using the private identification of the authorized user. Next, the processor can compute a hash value of the data and the encrypted data to obtain a hash value. The processor can obtain a prior hash value associated with a preceding block in the block chain. The processor can create a block from the data, the encrypted data, the hash value and the prior hash value. The processor can add the block to the block chain … by performing a mildly intensive proof of work computation.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the processor performs the proof of work computation to add the block to the blockchain network.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add requesting, with a client device, a block hash from a recent block for a transaction, and a pre-selected complexity threshold, the pre-selected complexity threshold defined by computational power required to validate the transaction based on network load, wherein transactions with greater complexity relative to the pre-selected complexity threshold are prioritized for block inclusion and generating, via the client device, the requested block hash by applying a proof of work request threshold to achieve the pre-selected complexity threshold as seen in Bres's invention into Wright's invention because these modifications allow applying a known technique to a known device ready for improvement to yield predictable results such that the proof of work threshold is satisfied by each new transaction being inserted onto the block by verifying the previous block’s hash and complexity threshold is exceeded.
In addition, Ajoy discloses:
… virtual machine transaction … (Col. 2, Line 61 – Col. 3, Line 8 “The system utilizes sandboxed environments on nodes to create a stateful virtual machine to apportion computing and storage resources for the execution of distributed applications. A computing device, for example, a server, personal computer or smart device, may act as a node on the blockchain network. The main blockchain network (mainchain) contain smaller collections of nodes on smaller networks (sidechain) as well as multiple individual nodes. The mainchain is a publicly-accessible blockchain with a consensus algorithm to create trust while, the sidechain are private permissioned blockchains that do not have a consensus algorithm. On the mainchain, the system utilizes consensus logic, for example, proof-of-stake (PoS) to achieve consensus between nodes, validate transactions and create new blocks.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the virtual machine transactions are submitted to the mainchain via proof-of-stake to achieve consensus between nodes, validate transactions, and create new blocks.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add virtual machine transactions as seen in Ajoy's invention into Wright's invention because these modifications allow the simple substitution of one known element for another to obtain predictable results such that VM transactions are being submitted to the blockchain in comparison to other types of transactions.
Regarding claim 4, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein requesting the block hash comprises iteratively modifying the proof of work request threshold until the generated block hash has a complexity that meets or exceeds the pre-selected complexity threshold.
However, Bres discloses:
wherein requesting the block hash comprises iteratively modifying the proof of work request threshold until the generated block hash has a complexity that meets or exceeds the pre-selected complexity threshold. ([0036] “For example, as shown in FIG. 5, the proof of work value 510 can be a value that when hashed with the contents of the data structure 500 produces a hash value that has the required number of zeros 520. The required number of zeros can be 0, 1, 2, 3, 4. The higher the number of zeros required, the higher the computation needed to find the proof of work value 510.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the proof of work value 510 can be iteratively modified by increasing the required number of zeros (for example, increasing from 0 to 1 required zeros, testing the complexity and finding it does not surpass the pre-selected complexity, then increasing from 1 to 2 required zeros and repeating the process until the pre-selected complexity is reached) which increases the complexity and computation needed to find the proof of work value 510.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein requesting the block hash comprises iteratively modifying the proof of work request threshold until the generated block hash has a complexity that meets or exceeds the pre-selected complexity threshold as seen in Bres’s invention into Wright’s invention because these modifications allow combining prior art elements according to known methods to yield predictable results that the complexity threshold is set and continually passed so that there is an increasing work requirement to create new blocks.
Regarding claim 6, Wright discloses the computer implemented method of claim 1, wherein constructing a virtual machine transaction comprises storing the virtual machine transaction and the key-value mapping in a blockchain database, the key-value mapping is used for retrieval of state data for subsequent transaction verification. ([0039] “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure.” and [0195] “For example, Alice 103a may store the expected hash result, or a shortened version of the expected hash result (e.g. the first four leading bytes), in a look-up table together with (i.e. mapped to a corresponding expected public key and/or a transaction identifier of the first transaction. In other words, the (shortened) expected hash result is the key of a key-value pair, where the value is the expected public key and/or transaction identifier. The look-up table may comprise several key-value pairs of this type, for different hash results, public keys and transaction identifiers. Alice 103a may use the (shortened) expected hash value as a look-up to find the corresponding public key and/or transaction identifier.” and [0236] “HASH 160 always produces the same output address for the same public key. An attacker can simply associate the same hashed public key values together if the private-public key pair is reused. Once the unlocking public key is revealed during a transaction the attacker can link all those hashed value to the public key and the mask is redundant. It is therefore recommended that users create a new public key for each transaction. This can be laboursome and requires each new public key to be transmitted to the funding party for each new transaction.” The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value mapping between a hash result and public key and/or transaction identifier maps the relationship between each public key and the transaction state since each transaction is recommended to have a new public key and can be stored in a blockchain database.
Regarding claim 8, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein generating the new block further comprises increasing the pre-selected complexity when a block generation rate surpasses a target rate.
However, Bres discloses:
wherein generating the new block further comprises increasing the pre-selected complexity when a block generation rate surpasses a target rate. ([0037] “To determine the desired amount of time for the proof of work computation, initially, a computation can be performed for various required numbers of zeros 1, 2, 3, 4, and the computational time can be measured. The computational time closest to the expected time T can be selected. As new blocks are added to the block chain, the processor can monitor the time, T, of generating new information to be added to the block chain and the amount of time needed to perform the proof of work computation. As the amount of time significantly drops below, or significantly increases above the time T, the processor can adjust the required number of zeros up or down, respectively, to obtain an amount of time for the proof of work computation approximately corresponding to the expected time T.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the target value is automatically adjusted so that the target time T is reached, so additional zeros are required to increase the proof of work complexity.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein generating the new block further comprises increasing the pre-selected complexity when a block generation rate surpasses a target rate as seen in Bres’s invention into Wright’s invention because these modifications allow combining prior art elements according to known methods to yield predictable results such that the complexity threshold is set and continually passed so that there is an increasing work requirement to create new blocks.
Regarding claim 9, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein generating the new block further comprises reducing the pre-selected complexity when a block generation rate is lower than a target rate.
However, Bres discloses:
wherein generating the new block further comprises reducing the pre-selected complexity when a block generation rate is lower than a target rate. ([0037] “To determine the desired amount of time for the proof of work computation, initially, a computation can be performed for various required numbers of zeros 1, 2, 3, 4, and the computational time can be measured. The computational time closest to the expected time T can be selected. As new blocks are added to the block chain, the processor can monitor the time, T, of generating new information to be added to the block chain and the amount of time needed to perform the proof of work computation. As the amount of time significantly drops below, or significantly increases above the time T, the processor can adjust the required number of zeros up or down, respectively, to obtain an amount of time for the proof of work computation approximately corresponding to the expected time T.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the target value is automatically adjusted so that the target time T is reached, so fewer zeros are required to lower the proof of work complexity.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein generating the new block further comprises reducing the pre-selected complexity when a block generation rate is lower than a target rate as seen in Bres’s invention into Wright’s invention because these modifications allow combining prior art elements according to known methods to yield predictable results such that the complexity threshold is set and lowered if a block hash has expired and not been properly generated.
Regarding independent claim 11, Wright discloses:
A system, comprising:
a memory storing multiple instructions; and
one or more processors configured to execute the instructions to cause the system to perform a process, comprising:
generating a key-value mapping associating a public key with a corresponding transaction state value within a virtual machine environment, the key-value mapping structured according to hierarchical naming rules defining relationships among keys and sub-keys; ([0195] “For example, Alice 103a may store the expected hash result, or a shortened version of the expected hash result (e.g. the first four leading bytes), in a look-up table together with (i.e. mapped to a corresponding expected public key and/or a transaction identifier of the first transaction. In other words, the (shortened) expected hash result is the key of a key-value
pair, where the value is the expected public key and/or transaction identifier. The look-up table may comprise several key-value pairs of this type, for different hash results, public keys and transaction identifiers. Alice 103a may use the (shortened) expected hash value as a look-up to find the corresponding public key and/or transaction identifier.” and [0236] “HASH 160 always produces the same output address for the same public key. An attacker can simply associate the same hashed public key values together if the private-public key pair is reused. Once the unlocking public key is revealed during a transaction the attacker can link all those hashed value to the public key and the mask is redundant. It is therefore recommended that users create a new public key for each transaction. This can be laboursome and requires each new public key to be transmitted to the funding party for each new transaction.” and [0160] “FIG. 7 illustrates an example of a hierarchical deterministic (HD) set of keys, also known as a HD wallet. Here, the master key is generated based on a seed. The child keys in each set of child keys are each generated based on the master key. The grandchild keys in each respective set of grandchild keys are each generated based on a respective set of the child keys. In this example, the master key is the parent key. However, the labels “parent” and “child” may be used to refer to a public key in an n.sup.th level and public key an (n+1).sup.th level, wherein the public key in the (n+1).sup.th level is generated based on the public key in the n.sup.th level.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value mapping between a hash result and public key and/or transaction identifier maps the relationship between each public key and the transaction state since each transaction is recommended to have a new public key. Also, the public keys and their children show examples of hierarchical deterministic set of keys.
constructing, via the client device, a [transaction] comprising a public key, the block hash, and a proof of work request threshold; ([0043] “The input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction 152i is locked. In turn, the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b. The present transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the present transaction 152j.” and [0046] “In addition to validating transactions, blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by “proof-of-work”. At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a “nonce” value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros.” and [0080] “Typically an input of a transaction contains a digital signature corresponding to a public key P.sub.A. In embodiments this is based on the ECDSA using the elliptic curve secp256k1. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the transactions that are constructed include public key, block hash, and proof of work threshold of a fixed length such that it requires a certain predefined number of leading zeros.
validating the [transaction] using encrypted keys mapped in the key-value mapping; ([0122] “The expected data item may be an expected public key, e.g. Bob's public key PK.sub.B. In this example, the expected hash result may be used as a blockchain address. As well as requiring the expected data item to be an expected public key, the first locking script may require the unlocking script of Tx2 to comprise a signature generating using a private key corresponding to the expected public key. For instance, the first locking script may require the unlocking script to comprise Bob's public key PK.sub.B (which hashes to the expected hash result), and Bob's signature generated using Bob's private key sk.sub.B. This form of locking script is often referred to as a pay-to-public-key-hash (P2PKH) script.” and [0281] “However, Alice could set the q value to be sufficiently high such that an unknown solving party could generate a private-public key pair that satisfied the address system off-line, on average, over the course of days for example. This would ensure that it would not be feasible for a rogue Bitcoin node to generate their own satisfactory private-public key pair in the average mining time for a block (10 minutes). Assuming that there are at least some good miners, the original transaction would be validated and published into the bitcoin network before a bad Bitcoin node could generate a replacement transaction to steal the associated funds.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the transaction is validated based on the private-public key pair that cannot be broken within the time to mine the average block.
generating a new block including one or more validated [transactions] each having block hashes that surpass the pre-selected complexity; ([0039] “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure.” and [0046] “In addition to validating transactions, blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by “proof-of-work”. At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a “nonce” value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the new block is created following consensus between nodes and transactions being validated such that the hash is required to meet a predetermined condition for a difficult calculation that can be checked by other users for its proper level of complexity/correctness.
However, Bres discloses:
requesting, with a client device, a block hash from a recent block for a transaction, and a pre-selected complexity threshold, the pre-selected complexity threshold defined by computational power required to validate the transaction based on network load, wherein transactions with greater complexity relative to the pre-selected complexity threshold are prioritized for block inclusion; ([0033] “The a fifth entry 450 is included in the data structure 400 when the data structure 400 is not the initial block in the block chain. The fifth entry 450 includes a hash value of a previous block in the block chain. The hash value of the previous block is computed based on the first entry and the second entry of a previous data structure.” and [0035] “The mildly intensive computation can be designed to require a desired amount of time. To determine the desired amount of time, assume that a time to obtain new data 410 in FIG. 1 to add to the block chain is T. … When proof of work time is significantly less than T, an attack can be mounted on the block chain because a malicious processor can falsify information in the last block in the block chain before a new block is added. If the proof of work time is significantly greater than T, a backlog of new data will be created because of a delay in creating a block containing the proof of work value 510 to add to the block chain.” and [0036] “For example, as shown in FIG. 5, the proof of work value 510 can be a value that when hashed with the contents of the data structure 500 produces a hash value that has the required number of zeros 520. The required number of zeros can be 0, 1, 2, 3, 4. The higher the number of zeros required, the higher the computation needed to find the proof of work value 510.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the block hash value 450 certifies the integrity of the block and the proof of work value 510 can be iteratively modified by increasing the required number of zeros (for example, increasing from 0 to 1 required zeros, testing the complexity and finding it does not meet or exceed the pre-selected complexity threshold, then increasing from 1 to 2 required zeros and repeating the process until the pre-selected complexity threshold is reached) which increases the complexity and computation needed to find the proof of work value 510. The proof of work value increases over time to insure the blockchain cannot have previous data edited/attacked to falsify the blockchain’s previously certified results.
generating, via the client device, the requested block hash by applying a proof of work request threshold to achieve the pre-selected complexity threshold; ([0045] “In step 720, the processor can efficiently add a block to the block chain by encrypting the data using the private identification of the authorized user. Next, the processor can compute a hash value of the data and the encrypted data to obtain a hash value. The processor can obtain a prior hash value associated with a preceding block in the block chain. The processor can create a block from the data, the encrypted data, the hash value and the prior hash value. The processor can add the block to the block chain … by performing a mildly intensive proof of work computation.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the processor performs the proof of work computation to add the block to the blockchain network.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add requesting, with a client device, a block hash from a recent block for a transaction, and a pre-selected complexity threshold, the pre-selected complexity threshold defined by computational power required to validate the transaction based on network load, wherein transactions with greater complexity relative to the pre-selected complexity threshold are prioritized for block inclusion and generating, via the client device, the requested block hash by applying a proof of work request threshold to achieve the pre-selected complexity threshold as seen in Bres's invention into Wright's invention because these modifications allow applying a known technique to a known device ready for improvement to yield predictable results such that the proof of work threshold is satisfied by each new transaction being inserted onto the block by verifying the previous block’s hash and complexity threshold is exceeded.
In addition, Ajoy discloses:
… virtual machine transaction … (Col. 2, Line 61 – Col. 3, Line 8 “The system utilizes sandboxed environments on nodes to create a stateful virtual machine to apportion computing and storage resources for the execution of distributed applications. A computing device, for example, a server, personal computer or smart device, may act as a node on the blockchain network. The main blockchain network (mainchain) contain smaller collections of nodes on smaller networks (sidechain) as well as multiple individual nodes. The mainchain is a publicly-accessible blockchain with a consensus algorithm to create trust while, the sidechain are private permissioned blockchains that do not have a consensus algorithm. On the mainchain, the system utilizes consensus logic, for example, proof-of-stake (PoS) to achieve consensus between nodes, validate transactions and create new blocks.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the virtual machine transactions are submitted to the mainchain via proof-of-stake to achieve consensus between nodes, validate transactions, and create new blocks.
serially processing state transitions in blocks. (Fig. 13 and Col. 12, Lines 25-31 “Blocks hold batches of valid transactions that are hashed and encoded, for example into a Merkle tree. Each block includes the cryptographic hash of the prior block in the blockchain formation 1300, linking the two. The linked blocks form a chain. This iterative process confirms the integrity of the previous block, all the way back to the original start block 1302.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the Merkle tree shows the linked blocks form a chain of serially processed blocks.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add virtual machine transactions and serially processing state transitions in valid blocks as seen in Ajoy’s invention into Wright’s invention because these modifications allow the simple substitution of one known element for another to obtain predictable results such that VM transactions are being submitted to the blockchain in comparison to other types of transactions and combining prior art elements according to known methods to yield predictable results of forming a chain of blocks that were processed serially rather than by a more random method.
Regarding claim 14, it is a system claim having the same limitations as cited in the computer implemented method of claim 4. Claim 14 depends on claim 11 and has an additional limitation in independent claim 11 “serially processing state transitions in valid blocks” that is rejected by Ajoy’s prior art. Thus, claim 14 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
Regarding claim 16, it is a non-transitory computer readable medium claim having the same limitations as cited in the computer implemented method of claim 1. Thus, claim 16 is also rejected under the same rationale as addressed in the rejection of claim 1 above.
Regarding claim 19, it is a non-transitory computer readable medium claim having the same limitations as cited in the computer implemented method of claim 4. Thus, claim 19 is also rejected under the same rationale as addressed in the rejection of claim 4 above.
7. Claims 2-3, 12-13, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) – hereinafter “Wright” in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418) further in view of Ferrin (U.S. Pub. No. 2016/0218879).
Regarding claim 2, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein requesting the block hash comprises selecting a node in a blockchain network to compute the block hash.
However, Ferrin discloses:
wherein requesting the block hash comprises selecting a node in a blockchain network to compute the block hash. ([0033] “The term “signing device” means a hashing device that also holds the private portion of a public/private key pair and uses that information to digitally sign the block. The block signing process sometimes uses other data including but not limited to the block itself and the corresponding public key. This device may or may not perform the measurements and calculations related to the fitness function, and it may return all signed blocks or it may only return selected blocks to the bookkeeping device.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the performing of the measurements and calculations related to the fitness function and return of all/selected signed blocks is the same as selecting a node and computing/returning the block hash.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein requesting the block hash comprises selecting a node in a blockchain network to compute the block hash as seen in Ferrin's invention into Wright's invention because these modifications allow applying a known technique to a known device ready for improvement to yield predictable results such that the block hash calculation can be performed on one of the recently added blocks to ensure the block’s validity.
Regarding claim 3, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein requesting the block hash comprises sampling a pre-selected number of recent blocks to find the block hash for the transaction.
However, Ferrin discloses:
wherein requesting the block hash comprises sampling a pre-selected number of recent blocks to find the block hash for the transaction. (Fig. 1 and [0067] “After “Broadcast Block” Step 114 the process of mining a block is complete. Most bookkeeping devices would then return to “Find Previous Block” Step 102 and calculate a new block. However, that is not required.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the previous block is found and then a new block is calculated.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein requesting the block hash comprises sampling a pre-selected number of recent blocks to find the block hash for the transaction as seen in Ferrin's invention into Wright's invention because these modifications allow applying a known technique to a known device ready for improvement to yield predictable results such that the block hash calculation can be performed on one of the recently added blocks to ensure the block’s validity.
Regarding claim 12, it is a system claim having the same limitations as cited in the computer implemented method of claim 2. Claim 12 depends on claim 11 and has an additional limitation in independent claim 11 “serially processing state transitions in valid blocks” that is rejected by Ajoy’s prior art. Thus, claim 12 is also rejected under the same rationale as addressed in the rejection of claim 2 above.
Regarding claim 13, it is a system claim having the same limitations as cited in the computer implemented method of claim 3. Claim 13 depends on claim 11 and has an additional limitation in independent claim 11 “serially processing state transitions in valid blocks” that is rejected by Ajoy’s prior art. Thus, claim 13 is also rejected under the same rationale as addressed in the rejection of claim 3 above.
Regarding claim 17, it is a non-transitory computer readable medium claim having the same limitations as cited in the computer implemented method of claim 2. Thus, claim 17 is also rejected under the same rationale as addressed in the rejection of claim 2 above.
Regarding claim 18, it is a non-transitory computer readable medium claim having the same limitations as cited in the computer implemented method of claim 3. Thus, claim 18 is also rejected under the same rationale as addressed in the rejection of claim 3 above.
8. Claims 5, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) – hereinafter “Wright” in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418) further in view of Ahlback et al. (U.S. Pub. No. 2020/0076576) – hereinafter “Ahlback”.
Regarding claim 5, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein requesting the block hash comprises modifying the proof of work request threshold when the block hash has expired.
However, Ahlback discloses:
wherein requesting the block hash comprises modifying the proof of work request threshold when the block hash has expired. ([0037] “Generally in the different types of blockchain discussed in the background section, blocks 110 are appended to the blockchain indefinitely in a sequential manner. Currently, there is no option available for deleting the blocks 110 in which the transactions have expired, elapsed or become invalid. Therefore, the amount of data stored in a blockchain increases linearly with time as old transaction data can never be removed from the blockchain.” and [0043] “The method in FIG. 3 comprises the steps of creating a reincarnation block 210 whenever a predefined condition is satisfied and appending it to the blockchain, step 310. The method further comprises determining whether the genesis expiry time 201 has elapsed based on an expiry period, step 320. If the genesis expiry time 201 has elapsed then the method comprises identifying a first reincarnation block 210, wherein the first reincarnation block 210 is occurring first in sequence after the genesis block 200 in the blockchain, step 330. If the first reincarnation block 210 is identified then the method comprises deleting all the blocks 110 preceding the first reincarnation block 210 including the genesis block 200 in the block chain 340. The method may further comprise the step of identifying the first reincarnation block 210 as the genesis block 200 of the blockchain when all the blocks 110 preceding the first reincarnation block 210 including the genesis block 200 have been deleted 351. In FIG. 3, this step is shown in dashed lines so as to indicate that this step is optional.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the predefined condition such as transaction/block hash expiration leads to the changing of the genesis block 200. The changing of the genesis block to the first reincarnation block 210 changes the leading block and thus the proof of work threshold is different since there is a different genesis block.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein requesting the block hash comprises modifying the proof of work request threshold when the block hash has expired as seen in Ahlback’s invention into Wright’s invention because these modifications allow combining prior art elements according to known methods to yield predictable results such that the complexity threshold is set and lowered if a block hash has expired and not been properly generated.
Regarding claim 15, it is a system claim having the same limitations as cited in the computer implemented method of claim 5. Claim 15 depends on claim 11 and has an additional limitation in independent claim 11 “serially processing state transitions in valid blocks” that is rejected by Ajoy’s prior art. Thus, claim 15 is also rejected under the same rationale as addressed in the rejection of claim 5 above. The motivation for combination of the prior art can be found on pages 19-20 of this Office Action.
Regarding claim 20, it is a non-transitory computer readable medium claim having the same limitations as cited in the computer implemented method of claim 5. Thus, claim 20 is also rejected under the same rationale as addressed in the rejection of claim 5 above.
9. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) – hereinafter “Wright” in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418) further in view of Deshpande et al. (U.S. Pub. No. 2019/0378069) – hereinafter “Deshpande”.
Regarding claim 7, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein constructing a virtual machine transaction comprises sorting a transaction list in a blockchain database by a degree of complexity of each virtual machine transaction.
However, Deshpande discloses:
wherein constructing a virtual machine translation comprises sorting a transaction list in a blockchain database by a degree of complexity of each virtual machine transaction. ([0047] “The processing platform used by the miner service to create blocks 420 may sort the transactions multiple times according to heuristics applied to the transactions for optimization determination prior to block creation. The transactions may be forwarded 414 and sorted by nonce 416, and a simulation 418 may be used to determine the entities associated with the transactions, the size of the transactions, the results linked to the transactions for performing the mining effort, etc. The cost per unit size of the transactions may be determined to identify the time and processing requirements, CPU, memory, storage, etc., required to mine the transactions 422. The heuristics selected by the miner may be applied to finalize the sorted order of transactions 424 and to collect the optimal order 426 for block creation based on the selected transactions which will be used to include in next made block(s) 428. The blocks are then forwarded 432 to the blockchain 430 for committance.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the transactions are sorted by nonce which is a degree of complexity and are forwarded to a blockchain.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein constructing a virtual machine transaction comprises sorting a transaction list in a blockchain database by a degree of complexity of each virtual machine transaction as seen in Deshpande’s invention into Wright’s invention because these modifications allow applying a known technique to a known method ready for improvement to yield predictable results such that the most complex virtual machine transaction is easily found to ensure that there is an increased complexity of the following transaction.
10. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Wright et al. (U.S. Pub. No. 2024/0214179) – hereinafter “Wright” in view of Bres (U.S. Pub. No. 2019/0273616) and Ajoy (U.S. Patent No. 10,958,418) further in view of Agrawal et al. (U.S. Pub. No. 2019/0164153) – hereinafter “Agrawal”.
Regarding claim 10, Wright discloses the computer implemented method of claim 1, but does not explicitly disclose:
wherein generating the new block further comprises verifying that a sum of a difference between a complexity of the one or more transactions and the pre-selected complexity surpasses the pre-selected complexity.
However, Agrawal discloses:
wherein generating the new block further comprises verifying that a sum of a difference between a complexity of the one or more transactions and the pre-selected complexity surpasses the pre-selected complexity. ([0096] “FIG. 4 illustrates a diagram depicting the epoch concept, according to some embodiments. Blockchain 400 may include any number of blocks 1 through x. Each block may include one or more transactions. The number of transactions in each block can vary depending on the gas required for each transaction in the block. Transactions requiring more complex proof validation may consume more gas than less complex transactions. Each block has a fixed gas limit that is set by the system, and the sum of the gas required for each transaction in a block may not exceed the limit of the block. Thus, block(1) may include n transactions that do not exceed that limit, and block(2) may include m transactions that do not exceed that limit, where m and n can be different numbers.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the block has a fixed gas limit that is set by the system and the sum of the gas required for each transaction must not exceed the limit of the block. If the sum does exceed the limit of the block, a new block is generated.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein generating the new block further comprises verifying that a sum of a difference between a complexity of the one or more transactions and the pre-selected complexity surpasses the pre-selected complexity as seen in Agrawal’s invention into Wright’s invention because these modifications allow for an “obvious to try” solution with a reasonable expectation of success such that the minimum complexity is met for all transactions such that the increasing/decreasing of complexity does not reach an unexpected/unwanted level.
Conclusion
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Such prior art includes:
- Mitra et al. (U.S. Patent No. 11,171,931) which discloses hash value delivery.
- Petersen (U.S. Pub. No. 2021/0075623) which discloses information regarding the decentralized peer-to-peer network of blockchains and their verification of data integrity between peers.
- Adams III et al. (U.S. Pub. No. 2022/0191034) which discloses client devices performing proof of work algorithms to facilitate transactions.
- Wright et al. (U.S. Pub. No. 2024/0205030) which discloses new blocks being created by a plurality of nodes competing to perform proof of work equations to have their validated pending transactions included in new block of the blockchain.
- Fazzone et al. (U.S. 2020/0084020) which discloses an overhead view of early blockchain technology with proof of work new block validations.
- King (U.S. Pub. No. 2017/0344580) which discloses generating a segmented blockchain based on peer-to-peer block verification via proof of work along with peer-to-peer hash verification.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B TRAINOR whose telephone number is (571)272-3710. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/D.T./ Examiner, Art Unit 2198
/PIERRE VITAL/ Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights