DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/05/2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 03/05/2026.
a. Claims 1, 7-9, 11, 13, 15, 17-18 are amended
Overall, Claims 1-20 are pending and have been considered below.
Priority
The application claims priority to provisional application 63/583,003, filed on 09/15/2023. The priority is acknowledged.
Claim Objections
Claim 1 objected to because of the following informality: "… computer processing characteristics associated with Appropriate correction is required.
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.
Claims 1-20 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.
Claim 1 recites the limitation “generating a first cryptocurrency transaction record for targeting the set of targeted computer nodes to process the first cryptocurrency transaction based on including the code in the first cryptocurrency transaction record;” The claim recites generating a first cryptocurrency transaction record based on the included code. However, one of skill in the art under broadest reasonable interpretation would be confused as to how the transaction record is being generated based on including the code when the transaction record is in the process of being generated.
Claims 8 and 15 recite similar limitations to claim 1, and thus are rejected based on the same reason.
The remainder of the claims are rejected based on virtue of dependency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1-17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bleznak (US 20220318907 A1), in view of Petersen (US 20210075623 A1), in further view of Choi (US 20240154805 A1), in further view of Pauker (US 20150294308 A1).
Regarding Claims 1, 8, 15. Bleznak discloses:
a non-transitory memory; and [see at least (0007) the system may generate, for a first user device of a plurality of user devices]
one or more hardware processors coupled with the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising: [see at least (0007) the system may generate, for a first user device of a plurality of user devices]
in response to receiving a request for processing a first cryptocurrency transaction associated with a blockchain network comprising a plurality of computer nodes, selecting, from the plurality of computer nodes, a set of targeted computer nodes for processing the first cryptocurrency transaction based on computer processing characteristics associated with the plurality of computer nodes; [see at least (0089) generating the first cogen output file may further comprise selecting user devices for a cohort bloc. For example, the system may select the first user device and the second user device for a first cohort bloc. (0164) the system may select a digital signing process based on the processing power and/or geographic location of the first user device. For example, some devices may suffer from low processing power and/or low connectivity. As such, the system may determine a characteristic of a user device and select a signature scheme based on the characteristic. (The applicant’s specification states “The set of criteria may be associated with attributes of the computer nodes (e.g., a processor type of the computer node, an amount of memory in the computer node, a location of the computer node, etc.), efficiency characteristics associated with processing a cryptocurrency transaction (e.g., a power consumption required for processing a cryptocurrency transaction, a computer memory usage required for processing a cryptocurrency transaction, etc.)” (see para 00028). Thus, Bleznak’s processing power and geographic location read on the broadest reasonable interpretation “computer processing characteristics” consistent with the processor type, amount of memory, or location disclosed at 0028.)]
exchanging corresponding encryption keys and code with the set of targeted computer nodes; [see at least (0041) blockchain operations may include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain, transmitting communications-related nonfungible tokens, performing encryption/decryption, exchanging public/private keys, and/or other operations related to blockchains and blockchain technology. (0044) one or more user devices may include a digital wallet (e.g., digital wallet 204) used to perform blockchain operations. For example, the digital wallet may comprise a repository that allows users to store, manage, and trade their cryptocurrencies and assets, interact with blockchains, and/or conduct blockchain operations using one or more applications.]
Note: The claim limitation above applies to claims 1 and 8. Additionally, The applicant’s specification on [00031] recites, “The computer-based handshake may include the cryptocurrency transaction server generating (or otherwise determining) an indicator (e.g., a code) that can be included in a transaction record for indicating that the transaction record is generated to target the targeted computer nodes. For example, the code may include an identifier associated with the cryptocurrency transaction server (e.g., an address associated with a digital wallet of the cryptocurrency transaction server) and/or an arbitrarily (e.g., randomly) generated code (e.g., an alphanumeric code, an image code, etc.).” One of skill in the art under broadest reasonable interpretation would conclude the term “code” is an identifier. In addition, the Bleznak reference discloses blockchain operation (i.e., trading cryptocurrencies), and one of skill in the art would need the wallet address to trade cryptocurrencies.
generating a first cryptocurrency transaction record for targeting the set of targeted computer nodes to process the first cryptocurrency transaction based on including the code in the first cryptocurrency transaction record; [see at least (0044) one or more user devices may include a digital wallet (e.g., digital wallet 204) used to perform blockchain operations. For example, the digital wallet may comprise a repository that allows users to store, manage, and trade their cryptocurrencies and assets, interact with blockchains, and/or conduct blockchain operations using one or more applications. (0049) The user device that is successful aggregates and records blockchain operations from a mempool (e.g., a collection of all valid blockchain operations waiting to be confirmed by the blockchain network) into the next block]
broadcasting the first cryptocurrency transaction record the blockchain network [see at least (0041) blockchain operations may include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain, transmitting communications-related nonfungible tokens, performing encryption/decryption, exchanging public/private keys, and/or other operations related to blockchains and blockchain technology. (0042) blockchain operations may also comprise actions related to mechanisms that facilitate other blockchain operations (e.g., actions related to metering activities for blockchain operations on a given blockchain network)]
Bleznak discloses processing crypto currency transaction, however, Bleznak does not disclose:
performing a computational handshake with the set of targeted computer nodes, wherein the performing the computational handshake comprises …
subsequent to the performing the computational handshake with the set of targeted computer nodes,
detecting a transaction block that includes the first cryptocurrency transaction record on a blockchain associated with the blockchain network, wherein the transaction block further includes a Coinbase transaction record;
extracting encrypted data corresponding to a Layer Two invoice the Coinbase transaction in the transaction block;
decrypting the encrypted data using a particular encryption key of the corresponding encryption keys;
determining, from the set of targeted computer nodes, a particular targeted computer node that processed the first cryptocurrency transaction on the blockchain based on the particular encryption key used to decrypt the encrypted data; and
transferring a secondary transaction fee to the particular targeted computer node over a Layer Two cryptocurrency computer network based on the Layer Two invoice.
Nonetheless, Petersen discloses validating transaction:
detecting a transaction block that includes the first cryptocurrency transaction record on a blockchain associated with the blockchain network … [(0048) data verification comprises identifying the appropriate block storing the transaction at issue. In some embodiments, a reference to the block that contains the hash is stored and used to identify the appropriate transactions. Given the reference, the block can be located, and the data structures in its data field can be searched to find the hash corresponding to the data that is to be verified]
extracting encrypted data corresponding to a Layer Two invoice from … the transaction block; [(0007) processing the at least one data unit to generate an encrypted data structure and storing the encrypted data structure … retrieving (i.e., extracting) and decrypting the encrypted data structure data to obtain decrypted data for verification;]
decrypting the encrypted data using a particular encryption key of the corresponding encryption keys; [(0007) retrieving and decrypting the encrypted data structure data to obtain decrypted data for verification … a passkey for decrypting the encrypted data structure is secured by asymmetric encryption using a public-private key pair.]
determining, from the set of targeted computer nodes, a particular targeted computer node that processed the first cryptocurrency transaction on the blockchain based on the particular encryption key used to decrypt the encrypted data … [(0007) decrypting the encrypted data structure (i.e., processing) to obtain the at least one data unit using a first private key provided by the user]
transferring a secondary transaction fee to the particular targeted computer node over a Layer Two cryptocurrency computer network based on the Layer Two invoice. [(0045) In order to help ensure legitimacy of the validation process, proof-of-stake causes a validator to lose the stake if it approves fraudulent transactions. Generally, the stake is higher than the amount the validator can gain from transaction fees so as to incentivize validators to reject fraudulent transactions]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Bleznak to include the features of Petersen. One would have been motivated to do so, in order to process cryptocurrency transaction securely. Bleznak discloses processing cryptocurrency transaction. Petersen teaches the functionality of performing a encryption and decryption of data and determination of the validity of data. Because Bleznak, Petersen are implemented in a blockchain environment, and the devices the devices of Bleznak are analogous to the devices of Petersen that performing encryption and decryption and could themselves be programmed to carry out the function as taught by Petersen. Moreover, since the features disclosed by Bleznak as well as Petersen would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Bleznak/Petersen.
The combination of Bleznak in view of Petersen discloses processing transaction, however, the above combination of Bleznak, Petersen does not disclose:
performing a computational handshake with the set of targeted computer nodes, wherein the performing the computational handshake …
subsequent to the performing the computational handshake with the set of targeted computer nodes …
… wherein the transaction block further includes a Coinbase transaction record;
… in the Coinbase transaction record; and
However, Choi discloses performing handshake:
performing a computational handshake with the set of targeted computer nodes, wherein the performing the computational handshake … [see at least (0008) The SSL/TLS handshake protocol may include using asymmetric cryptography to authenticate information associated with the devices and/or negotiate a symmetric key that is used to encrypt data that is exchanged between the devices.]
subsequent to the performing the computational handshake with the set of targeted computer nodes … [see at least (0008) he SSL/TLS handshake protocol may include using asymmetric cryptography to authenticate information associated with the devices and/or negotiate a symmetric key that is used to encrypt data that is exchanged between the devices.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Bleznak, Petersen to include the features of Choi. One would have been motivated to do so, in order to process cryptocurrency transaction securely. Bleznak, Petersen discloses processing cryptocurrency transaction. Choi teaches the functionality of performing a handshake to secure the data. Because the devices of Bleznak, Petersen are analogous to the devices in Choi that perform the handshake and could themselves be programmed to carry out that function as taught by Choi. Moreover, since the features disclosed by Bleznak, Petersen as well as Choi would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Bleznak, Petersen/Choi.
The combination of Bleznak in view of Petersen, in further view of Choi discloses processing transaction, however, the above combination of Bleznak, Petersen, Choi does not disclose:
wherein the transaction block further includes a Coinbase transaction record;
… the Coinbase transaction record …
However, Pauker discloses Coinbase transaction:
wherein the transaction block further includes a Coinbase transaction record; [see at least (0035) Transaction 120 may identify an input 124 (e.g., a source of funds) and a set of outputs (e.g., destinations). The inputs and outputs may, for example, be digital wallets in which currency is stored. The inputs may refer to an output of a previous transaction as a source of funding or may identify that transaction 120 is an originating transaction that creates new currency (sometimes referred to as a coinbase transaction).]
… the Coinbase transaction record … [see at least (0035) Transaction 120 may identify an input 124 (e.g., a source of funds) and a set of outputs (e.g., destinations). The inputs and outputs may, for example, be digital wallets in which currency is stored. The inputs may refer to an output of a previous transaction as a source of funding or may identify that transaction 120 is an originating transaction that creates new currency (sometimes referred to as a coinbase transaction).]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Bleznak, Petersen Choi to include the features of Pauker. One would have been motivated to do so, in order to efficiently mine coin. Bleznak, Petersen, Choi discloses processing cryptocurrency transaction. Pauker teaches the coinbase transaction. Because the devices of Bleznak, Petersen, Choi are analogous to the devices of Pauker that perform coinbase transaction and could themselves be programmed to carry out the function as taught by Pauker. Moreover, since the features disclosed by Bleznak, Petersen, Choi as well as Pauker would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Bleznak, Petersen, Choi/Pauker.
Regarding Claim 2. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 1. Bleznak further discloses:
wherein the computer processing characteristics comprise a blockchain transaction processing efficiency characteristic. [see at least (0076) system 400 may need to be able to generate accounting entries reflecting changes of balances. However, while changes of balances can be tracked by examining blockchain 410, this requires additional processing and computational power. (reads on: additional tasks such as balance tracking require additional power. As stated in claim 1, under the broadest reasonable interpretation, Bleznak’s processing power and geographic location read on the interpretation “efficiency characteristic”. )]
Regarding Claim 3. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 1. Bleznak further discloses:
wherein the first cryptocurrency transaction record comprises a transaction output that indicates an address corresponding to the system. [see at least (0041) blockchain operations may include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain. (0079) Upon deployment of the smart contract, the bytecode is stored on the blockchain and is associated with an address]
Regarding Claim 4. Bleznak, Petersen, Choi discloses the limitations of Claim 1. Bleznak further discloses:
wherein the computer processing characteristics comprise a power consumption efficiency characteristic. [see at least (0076) system 400 may need to be able to generate accounting entries reflecting changes of balances. However, while changes of balances can be tracked by examining blockchain 410, this requires additional processing and computational power. (reads on: The applicant’s specification recites power consumption is an example of an efficiency characteristics (see paragraph 00028). The cited reference recites additional processing require more power which reads on power consumption.)]
Regarding Claim 5. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 1. Bleznak further discloses:
generating the corresponding encryption keys for the set of targeted computer nodes; [see at least (0033) The system may generate one group decryption key ciphertext for each cosigner (e.g., for each user device). The asymmetric algorithm key pair (e.g., a Paillier encryption key pair) may comprise an asymmetric algorithm encryption key and an asymmetric algorithm decryption key]
distributing the corresponding encryption keys to the set of targeted computer nodes. [see at least Fig. 2, (0045) system 200 may use cryptographic systems for conducting blockchain operations based on MPC key systems … system 200 may use the digital signature to prove to every node in the system that it is authorized to conduct the blockchain operations]
Regarding Claim 6. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 1. Bleznak further discloses:
wherein the encrypted data comprises a hashed value, and wherein the operations further comprise: accessing the Layer Two invoice using a lookup table based on the hashed value. [see at least (0122) Each user_id may be mapped to a unique “pool” and “private_key,” as part of the account creation process. The system may receive a signed transaction hash from the digital signing process. The system may send the signed transaction hash to a blockchain node (e.g., using the “eth_sendTransaction” method)]
Regarding Claim 7. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 1. Bleznak further discloses:
determining that the data is decrypted using the particular encryption key, from the plurality of encryption keys, that is associated with the particular targeted computer node. [see at least (0026) The device encryption key pair may be used to generate encryption keys for digital signing policies. The key pairs may also include a device authentication key pair. (0030) the use of any asymmetric algorithm for public key cryptography may be used for key generation, encryption, and/or decryption]
Regarding Claim 9. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
inserting transaction data associated with the first transaction into the first transaction record. [see at least (0049) The user device that is successful aggregates and records blockchain operations from a mempool (e.g., a collection of all valid blockchain operations waiting to be confirmed by the blockchain network) into the next block. (0050) In response to validation of the block, the block is added to blockchain 206, and the blockchain operation is completed.]
Regarding Claim 10. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
receiving, via a user interface provided on a device, one or more user inputs related to the first transaction, wherein the first transaction record is generated based on the one or more user inputs. [see at least Fig. 2, (0038) User device 202 may include a user interface. As referred to herein, a “user interface” may comprise a mechanism for human-computer interaction and communication on a device and may include inputs devices… the user interface may display content related to performing blockchain operations based on an MPC key system and/or a digital signing process using an MPC key system. (0041) “blockchain operations” may comprise any operations including and/or related to blockchains and blockchain technology. For example, blockchain operations may include conducting transactions, querying a distributed ledger]
Regarding Claim 11. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
generating the code based on an identifier associated with the computer system. [see at least (0122) The system may create (i.e., generate) an unsigned transaction out of input parameters, including: “to” address; (i.e., code) Eth “value”; optional gas price, or a slow/standard/fast enum map to current gas prices; optional pre-encoded calldata for contract methods; a user account address (if not passed in). The system may determine the next nonce (e.g., the last known transaction's nonce+1 or number of confirmed transactions+number of pending transactions).]
Regarding Claim 12. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
generating the corresponding encryption keys for the subset of computer nodes; and [see at least (0033) The system may generate one group decryption key ciphertext for each cosigner (e.g., for each user device). The asymmetric algorithm key pair (e.g., a Paillier encryption key pair) may comprise an asymmetric algorithm encryption key and an asymmetric algorithm decryption key]
distributing the corresponding encryption keys to the subset of computer nodes. [see at least Fig. 2, (0045) system 200 may use cryptographic systems for conducting blockchain operations based on MPC key systems … system 200 may use the digital signature to prove to every node in the system that it is authorized to conduct the blockchain operations]
Regarding Claim 13. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
attempting to decrypt the encrypted data using the corresponding of encryption keys associated with the subset of computer nodes. [see at least (0033) The asymmetric algorithm encryption key and the asymmetric algorithm decryption key may be encrypted to generate an asymmetric algorithm decryption key ciphertext.]
Regarding Claim 14. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 8. Bleznak further discloses:
wherein the set of criteria comprises power efficiency characteristics associated with the plurality of computer nodes. [see at least (0076) system 400 may need to be able to generate accounting entries reflecting changes of balances. However, while changes of balances can be tracked by examining blockchain 410, this requires additional processing and computational power. (reads on: The applicant’s specification recites power consumption is an example of an efficiency characteristics (see paragraph 00028). The cited reference recites additional processing require more power which reads on power consumption.)]
Regarding Claim 16. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 15. Bleznak further discloses:
wherein the set of criteria comprises a transaction processing efficiency criterion. [see at least (0076) system 400 may need to be able to generate accounting entries reflecting changes of balances. However, while changes of balances can be tracked by examining blockchain 410, this requires additional processing and computational power. (reads on: The applicant’s specification recites power consumption is an example of an efficiency characteristics (see paragraph 00028). The cited reference recites additional processing require more power which reads on power consumption.)]
Regarding Claim 17. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 15. Bleznak further discloses:
wherein the first transaction record comprises a first transaction output that specifies a recipient digital wallet in the cryptocurrency transaction. [see at least (0041) blockchain operations may include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain. (0079) Upon deployment of the smart contract, the bytecode is stored on the blockchain and is associated with an address]
Regarding Claim 19. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 15. Bleznak further discloses:
wherein the set of criteria comprises a power consumption efficiency criterion. [see at least (0076) system 400 may need to be able to generate accounting entries reflecting changes of balances. However, while changes of balances can be tracked by examining blockchain 410, this requires additional processing and computational power. (reads on: The applicant’s specification recites power consumption is an example of an efficiency characteristics (see paragraph 00028). The cited reference recites additional processing require more power which reads on power consumption.)]
Regarding Claim 20. Bleznak, Petersen, Choi, Pauker discloses the limitations of Claim 15. Bleznak further discloses:
determining that the encrypted data is decrypted using a particular encryption key from the set of encryption keys, wherein the particular computer node is identified based on the particular key. [see at least (0030) The device encryption key pair may be used to generate encryption keys for digital signing policies. The key pairs may also include a device authentication key pair. (reads on: only the specific key can be used to decrypt the data) (0029) the use of any asymmetric algorithm for public key cryptography may be used for key generation, encryption, and/or decryption ]
Claim 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bleznak, in view of Petersen, in further view of Choi, in further view of Pauker, as applied to claim 17 above, in further view of Koh (US 20230169510 A1).
Regarding Claim 18. Bleznak, Petersen discloses the limitations of Claim 17. The combination of Bleznak, Petersen, Choi, Pauker discloses processing transaction, however, the above combination of Bleznak, Petersen, Choi, Pauker does not disclose:
incorporating the code into a second transaction output of the first transaction record.
However, Koh discloses maintaining transaction record:
incorporating the code into a second transaction output of the first transaction record. [see at least (0125) data record can indicate a smart contract associated with the proposed transaction … a smart contract is a computer program or a transaction protocol that is configured to automatically execute, control, and/or record legally relevant events and actions according to the terms of a contract or an agreement (e.g., as a part of the transaction)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Bleznak, Petersen, Choi, Pauker to include the features of Koh. One would have been motivated to do so, in order to process cryptocurrency transaction. Bleznak, Petersen, Choi, Pauker discloses broadcasting and extracting transaction data. Koh teaches distributing and incorporating code to transaction record using smart contract. Because the devices of Bleznak, Petersen, Choi, Pauker are analogous to the devices of Koh that execute program to communicate between nodes and could themselves be programmed to carry out the function as taught by Koh. Moreover, since the elements disclosed by Bleznak, Petersen, Choi, Pauker, as well as Koh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Bleznak, Petersen, Choi, Pauker/Koh.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims objection.
Applicant submits: “Claims 1, 8, and 15 were objected to due to certain informalities. Specifically, the Office Action asserted that the use of different claim terminologies in the different independent claims (e.g., "computer processing characteristics" vs. "a set of criteria") creates confusion. Applicant respectfully disagrees. First, using different terminologies across different independent claims is a well-established claim drafting practice to enable the different independent claims to have varying claim scopes. Second, both of the terms are supported in the Specification and used in different contexts (see, for example, paragraph [0028] of the Specification). Third, while MPEP $608.01 states that "the use of a confusing variety of terms for the same thing should not be permitted," the different claim terms used herein are not intended to cover "the same thing." Accordingly, Applicant respectfully requests reconsideration and withdrawal of the objections to claims 1, 8, and 15.”
Examiner responds: Examiner has carefully considered, but does not find Applicant’s arguments persuasive. Applicant’s specification on [0028] recites “The set of criteria may be associated with attributes of the computer nodes (e.g., a processor type of the computer node, an amount of memory in the computer node, a location of the computer node, etc.), efficiency characteristics associated with processing a cryptocurrency transaction” One of skill in the art under broadest reasonable interpretation would conclude that the computer processing characteristic is part of the set of criteria. However, claim 4 (which depend on claim 1) recites “wherein the computer processing characteristics comprise a power consumption efficiency characteristic.” And claim 14 (which depend on claim 8) recites “wherein the set of criteria comprises power efficiency characteristics associated with the plurality of computer nodes.” Claim 4, recites one of the processing characteristic is an power consumption characteristic, and claim 14 recites set of criteria comprises power efficiency characteristic. One of skill in the art would conclude processing characteristic and set of criteria are the same thing. Thus the objection is proper and has been maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “Applicant respectfully traverses the rejection based on the claims as currently amended for at least the following reasons. Independent claim 1 has been amended based on what was discussed during the Examiner Interview, which the Examiner has indicated would likely overcome the § 103 rejections. As discussed, the cited references, alone or in combination, fail to disclose the limitations of "generating a first cryptocurrency transaction record for targeting the set of targeted computer nodes to process the first cryptocurrency transaction based on including the code in the first cryptocurrency transaction record decrypting the encrypted data using a particular encryption key of the corresponding encryption keys; determining, from the set of targeted computer nodes, a particular targeted computer node that processed the first cryptocurrency transaction on the blockchain based on a particular encryption key used to decrypt the encrypted data transferring, by the computer system, one or more tokens to the particular computer node over a Layer Two computer network corresponding to the blockchain based on the digital invoice" as recited in amended claim 1. Applicant further submits that while Choi, Pauker, and Koh were cited in the Office Action as allegedly disclosing various features from dependent claims, they do not cure the deficiencies of Bleznak and Navon, even assuming that a motivation to combine the references exists (which Applicant does not concede). Accordingly, Applicant respectfully submits that the cited references do not render claim 1 obvious. Independent claims 8 and 15 also include limitations similar to those described above by reference to claim 1. As such, the cited references also do not render claims 8 and 15 obvious for similar reasons discussed above by reference to claim 1. Thus, independent claims 1, 8, and 15 are submitted as patentable over the cited references. Claims 2-7, 9-14, and 16-20 are also patentable by virtue of their dependencies of their respective independent claims. Accordingly, Applicant respectfully requests reconsideration and withdrawal of the rejections under 35 U.S.C. § 103 with respect to claims 1-20. ”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not the previous set of claims. Furthermore, the amended claim 1 recites “code” and the applicant’s specification recites the code is an indicator such as address associated with the wallet (see applicant’s specification [0031]). The combination of Bleznak, Petersen, Choi, Pauker discloses the claim limitations of independent claims 1, 8, 15. And the dependent claim remain rejected based on virtue of dependency and prior art rejection. See the updated rejection. Thus the rejection is proper and has been maintained.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
Klarman; Uri (US 20190082007 A1) SYSTEM AND METHOD FOR REDUCING INFORMATION VOLUME IN A BLOCKCHAIN DISTRIBUTION NETWORK - [0096] The present BDN also employs several discrimination prevention mechanisms to ensure that the BDN propagates all blocks fairly, and is incapable of discriminating against any node, miner, block, transaction, or wallet. Block discrimination can be based on content of the block such as wallets, addresses, sums of the transactions in a block, timestamps, coinbase transactions, or any other attributes. To prevent discrimination based on block content, all blocks are encrypted prior to propagation. The BDN encryption alters the block size, which hides the number of transactions in the block and their total size. A block's encryption key (k.sub.1) is only revealed after the block had been propagated, and is propagated directly over the peer network. The minuscule size of k.sub.1, which can be as small as several bytes, allows it to quickly propagate directly over the peer network, and the BDN is powerless to stop it.
Duchon (US 20200084027 A1) SYSTEMS AND METHODS FOR ENCRYPTION OF DATA ON A BLOCKCHAIN - Methods and systems for encrypting and decrypting data on a blockchain may comprise, upon receiving a request to encrypt data elements of a first data block of a blockchain to only be accessible to a subset of nodes of the blockchain, generating an encryption key configured to encrypt the data elements of the first data block; encrypting the data elements of the first data block using the encryption key; retrieving a public key corresponding to each node within the subset of nodes; encrypting the encryption key using the public key corresponding to each node within the subset of nodes, generating an encrypted encryption key for each node within the subset of nodes; generating a second data block comprising the encrypted encryption key for each node and the encrypted data elements of the first data block; and appending the second data block to the blockchain.
Mutter (US 20220044229 A1) SYSTEMS AND METHODS FOR PEER-TO-PEER TRANSMISSION OF DIGITAL ASSETS - This disclosure relates to transaction systems and particularly to transaction systems of a peer-to-peer nature for digital assets. The asset transfer system may store user, user accounts, and transaction information in associated logic tables within a memory of a server hosting the asset transfer system. Through the use of, but limited to, curl functions, the asset transfer system may communicate with remote servers housing user wallets and user wallet information to perform transactions of digital assets between users. Before verification and proof of work can be established to complete the transfer of digital assets, the asset transfer system may report to the users of a transaction the details of the transaction. Users of the asset transfer system need not know encrypted or random keys to perform such digital asset transactions and may transfer digital assets only by identification of a username stored within the asset transfer system.
Gu (US 20210241282 A1) Blockchain Transaction Processing - [0029] In order to at least partially address one or more of the above problems, as well as other potential problems, an example embodiment of the present disclosure proposes a transaction processing solution. In the solution, a blockchain node of a blockchain for processing the blockchain transaction receives a transaction request indicating at least the transaction initiator, the transaction content and the transaction recipient of the transaction. The blockchain node computes, based on the transaction content, a transaction fee for processing the transaction, and determines whether the transaction initiator is a sponsored user of the transaction recipient. In response to determining that the transaction initiator is a sponsored user of the transaction recipient, the blockchain node determines a payment account from which the transaction fee is deducted. The transaction processing solution as provided in the present disclosure enables ordinary users to use blockchain services conveniently.
Yang (US 20160300222 A1) OFF NETWORK IDENTITY TRACKING IN ANONYMOUS CRYPTOCURRENCY EXCHANGE NETWORKS - [0033] The wallet services can communicate a cryptocurrency exchange network 134 including one or more distributed server nodes (e.g., a computing node 134A, a computing node 134B, etc., collectively as the “cryptocurrency exchange network 134”). The information compliance system 100 can also communicate with the cryptocurrency exchange network 134 via a cryptocurrency exchange interface 132. When one of the user devices 108 initiates a cryptocurrency transaction on a wallet service, the wallet service eventually causes the pending cryptocurrency transaction to publish onto the cryptocurrency exchange network 134. The cryptocurrency exchange network 134 then reaches a consensus of whether to include the pending cryptocurrency transaction in the accepted block chain.
Alness (US 20200220717 A1) PRIVATE KEY DECRYPTION SYSTEM AND METHOD OF USE - A key ceremony application creates bundles for custodians encrypted with their passphrases. Each bundle includes master key share. The master key shares are combined to store an operational master key. The operational master key is used for private key encryption during a checkout process. The operational private key is used for private key decryption for transaction signing in a payment process. The bundles further include TLS keys for authenticated requests to create an API key for a web application to communicate with a service and to unfreeze the system after it has been frozen by an administrator.
Yang (US 20200279261 A1) BLOCKCHAIN-BASED RECONCILIATION SYSTEM, METHOD, AND APPARATUS AND ELECTRONIC DEVICE - [0009] According to a second aspect, a blockchain-based reconciliation method is provided, wherein the method is implemented on a service-provider node, and the method includes: uploading transaction information to a blockchain, wherein the transaction information comprises an identifier of the service-consumer node; the service-consumer node monitors and obtains the transaction information based on the identifier of the service-consumer node; and the service-consumer node updates a ledger of the service-consumer node based on the transaction information if the service-consumer node confirms the transaction information.
Wright (US 20260067203 A1) COMPUTER-IMPLEMENTED METHODS AND SYSTEMS FOR IMPROVED COMMUNICATIONS ACROSS A BLOCKCHAIN NETWORK - The sending resource can include information and packets of data required to determine the validity of a data within a packet of data e.g. output/UTXO. Additionally or alternatively, the sending resource can itself, or via a validator, generate packets of data that validate and/or support the validation of the output/UTXO and/or indicate whether there has been a double-spend. The sending resource can at least one of: validate and/or verifying said UTXO; perform at least part of a Simplified Payment Verification (SPV) process for said UTXO; confirm whether a given blockchain transaction (Tx) is contained within the blockchain block; generate a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path and/or checking whether the hash matches a transaction identifier (TxID) in a header of the blockchain block; and determine a Merkle proof for said UTXO.
Walters (US 20200160340 A1) DISTRIBUTED FRAUD DETECTION SYSTEM WITHIN MESH NETWORKS - [0078] The system bus 608 provides an interface for system components including, but not limited to, an interface between the system memory 606 and the processing unit 604. The system bus 608 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures.
Irani (US 20190305956 A1) INTEGRATING BIOMETRIC DATA ON A BLOCKCHAIN SYSTEM - [0030] In one embodiment, the blockchain system 300 may receive a transaction initiation, including transaction data, from a client 330. The transaction data can include an address of another party to the transaction. In a variety embodiments, the transaction data 322 may include an amount of cryptocurrency to transfer in the transaction, digital identification data, copyright and/or royalty data, real estate data, land data, title data, digital voting data, medical data (e.g., medical recordkeeping data), wills and inheritance data, asset data, logistics data, distributed storage system data, etc. In some embodiments, the client 330 may include biometric data 332 as transaction data 322 (or in addition to transaction data 322) when initiating a transaction. The transaction data 322 from the client 330 can be routed (e.g., by orchestrator 340) through network 305 to one or more nodes 320, authorized validation nodes 350, or other entities. In some embodiments, all nodes 320 in a system are presented with transaction details (e.g., transaction data 322) for validation. The transaction can then be validated after all nodes 320 have validated the transaction or a threshold number of nodes 320 have validated the transaction. In other embodiments, a subset of nodes 320 receive and validate transactions.
James (US 11200569 B1) System, method and program product for making payments using fiat-backed digital assets - [0030] In one embodiment, the blockchain system 300 may receive a transaction initiation, including transaction data, from a client 330. The transaction data can include an address of another party to the transaction. In a variety embodiments, the transaction data 322 may include an amount of cryptocurrency to transfer in the transaction, digital identification data, copyright and/or royalty data, real estate data, land data, title data, digital voting data, medical data (e.g., medical recordkeeping data), wills and inheritance data, asset data, logistics data, distributed storage system data, etc. In some embodiments, the client 330 may include biometric data 332 as transaction data 322 (or in addition to transaction data 322) when initiating a transaction. The transaction data 322 from the client 330 can be routed (e.g., by orchestrator 340) through network 305 to one or more nodes 320, authorized validation nodes 350, or other entities. In some embodiments, all nodes 320 in a system are presented with transaction details (e.g., transaction data 322) for validation. The transaction can then be validated after all nodes 320 have validated the transaction or a threshold number of nodes 320 have validated the transaction. In other embodiments, a subset of nodes 320 receive and validate transactions.
Weight (US 20190220858 A1) MULTI-APPROVAL SYSTEM USING M OF N KEYS TO PERFORM AN ACTION AT A CUSTOMER DEVICE - A computing system that includes at least one processor and at least one memory communicatively coupled to the at least one processor is disclosed. The computing system also includes at least one network interface communicatively coupled to the at least one processor and configured to communicate with at least one vault system, each of the at least one vault system storing a respective one of N private keys or key components associated with a customer. The at least one processor is configured to receive, from each of at least one vault system, a respective private key or key component. The at least one processor is also configured to perform at least one action based on at least M of the N private keys or key components.
Navon (US 20230186290 A1) SOFTWARE ARCHITECTURE FOR EFFICIENT BLOCKCHAIN TRANSACTIONS - The present disclosure provides techniques for efficient blockchain transaction processing. In one embodiment, a computer system broadcasts a first transaction to a blockchain network for addition to a block in a blockchain. The computer system may broadcast a second transaction to the blockchain network for addition to the block in the blockchain, where the second transaction descends from the first transaction and includes a placeholder fee. The computer system monitors and determines that the first transaction has not been confirmed to the block in the blockchain for a duration of time (e.g., stuck in the mempool). In response to determining that the first transaction is stuck, the computer system may transmit a request to replace the placeholder fee with a transaction fee that is sufficiently high to cause the first transaction and the second transaction to be confirmed to a block in the blockchain, thereby unsticking the first transaction.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights