DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 Oct. 09, 2019 has been entered.
Status of Claims
This office action is in response to the claim amendments filed on March 04, 2026.
Claims 1-6, 8-19, and 21-22 are pending.
Claims 7 and 20 have been canceled.
Claims 1-6, 8-19, and 21-22 have been examined.
Examiner Request
Filed original copies of documents (i.e. claims, Specification and Applicant Arguments/Remarks Made in an Amendment) are not illegible enough for use of machine transaction (i.e. OCR (Optical Character Recognition)) for searching and citation in the office action. Examiner respectfully request copy of abstract, drawing and future claim amendment in OCR compliant format if possible.
Response to Arguments
With respect to Claim Rejections - 35 USC § 101
Regarding claims 1-6, 8-19, and 21-22. The Applicant’s arguments with respect to 35 USC 101 rejection are persuasive. Additionally, Applicant’s amendments to the claim have overcome this ground of rejection. Accordingly, this ground of rejection is withdrawn.
With respect to Claim Rejections - 35 USC § 103
Applicant’s arguments with respect to claims 1-6, 8-19, and 21-22 have been considered but are moot in view of new grounds of rejection initiated by applicant’s amendment to the claims.
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-6 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 pre-AIA the applicant regards as the invention.
Claim 1 recites, the limitations “receiving a message directed to the smart contract that the transaction in the transaction request has been mined on the block of the second blockchain network” claim further recites “querying, via an oracle, the block containing the transaction from the first blockchain network”. However, claim further recites, “determining, via the smart contract, that a hash of the transaction on the block matches the hash in the message”. It is unclear to a person of ordinary skill in the art, whether “the transaction” in the “determining, via the smart contract…” step is referring to the “the transaction” in the “receiving a message directed to the smart contract that the transaction…” or the “the transaction” in the “querying, via an oracle, the block containing the transaction…” step. Appropriate correction is required.
Claim 1 recites the limitation “querying, via an oracle, the block containing the transaction from the first blockchain network”. There is insufficient antecedent basis for the phrase “the transaction” in this claim.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 nonobviousness.
Claims 1, 2 and 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Ram et al. (US 10841372 B1, “Ram”) in view of David Matthew Thompson (US 20200097950 A1, “Thompson”), and further in view of Kaplan et al (US 11496327 B1, “Kaplan”).
Regarding claim 1: Ram discloses: A verification system comprising:
a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the verification system to perform operations comprising (see Fig. 1 and related text):
generating (e.g., define) a smart contract (Ram [Col. 2, Line 62 – Col. 3, Line 5]: The customer node can define a smart contract that identifies the processing task (or subtasks) and includes a staked payment token for release upon successful completion of the processing task. The smart contract can be submitted to a distributed ledger. Miner nodes participating in the distributed network can each complete one or more subtasks associated with the processing task. When the processing task (or subtasks) are complete, the smart contract can automatically award a portion of the staked payment token to wallets associated with miners who participated in completing the processing task);
deploying (e.g., submitted) the smart contract to a first blockchain network (Ram [Col. 2, Line 62 – Col. 3, Line 5]: The customer node can define a smart contract that identifies the processing task (or subtasks) and includes a staked payment token for release upon successful completion of the processing task. The smart contract can be submitted to a distributed ledger. Miner nodes participating in the distributed network can each complete one or more subtasks associated with the processing task. When the processing task (or subtasks) are complete, the smart contract can automatically award a portion of the staked payment token to wallets associated with miners who participated in completing the processing task);
broadcasting a transaction request, wherein the transaction request includes an on-chain transaction to be mined on a block of a blockchain network (Ram [Col. 8, Lines 28-30]: At 320, the mining node can receive an indication of a processing task. For example, a master node can select the miner node and assign a task to the mining node), (see abstract and Fig. 3);
receiving a message directed to the smart contract that the transaction in the transaction request has been mined on the [block] of the blockchain network (Ram [Col. 8, Lines 38-43]: At 330, the miner node can be operable to execute the processing task to completion. A cryptographic proof that the processing task was completed can be defined at 340. For example, the miner node can compute a cryptographic hash, such as a zk-POW, zero-knowledge, non-interactive POW, and/or zk-SNARKs value. The output of the cryptographic processing task can be sent to a recipient node; [Col. 2, Lines 20-26]: Embodiments described herein also relate to smart contracts such that users with a need for computing resources can stake a payment token such that miners are incentivized to solve a computational problem and are automatically awarded payment upon completion of the computational problem or a subtask associated with the computational problem), (see abstract, Col. 8, Lines 38-59 and Figs. 3 and 5);
querying, via an oracle, the block containing the transaction from the blockchain network (Ram Col. 2, Lines 47-49]: The master node can further identify a recipient node to which an output of the processing request is to be sent), (see Col. 9, Line 60 – Col. 10, Line 21);
Examiner’s Note: with respect to “querying, via an oracle”. This limitation does not limit the functionality of the claimed system because this limitation is outside the scope of the claimed system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed system. Therefore, this limitation has limited patentable weight since step of querying, via an oracle is not positively tied with any structure element of the claimed system. And with respect to the claims 8 and 16, this limitation is not positively recited functional step and hence receive limited patentable weight.
determining, via the smart contract, that a hash of the transaction on the block matches the hash in the message (Ram [Col. 7, Lines 34-39]: The miner nodes' 221-225 cryptographic proof of work can be compared to a similarly computed cryptographic hash generated by the customer node 210. If the cryptographic hash generated by the customer node 210 matches a cryptographic proof-of-work generated by a miner node 221-225, the customer node 210 can send a signal to a node containing an instance of the smart contract to cause a portion of the payment token staked by the customer node 210 to be released to a wallet associated with the miner node that generated the valid proof-of-work), (see Col. 9, Lines 40-45 and Fig. 4);
Examiner’s Note: with respect to “determining, via the smart contract”. This limitation does not limit the functionality of the claimed system because this limitation is outside the scope of the claimed system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed system. Therefore, this limitation has limited patentable weight since step of determining, via the smart contract is not positively tied with any structure element of the claimed system. And with respect to the claims 8 and 16, this limitation is not positively recited functional step and hence receive limited patentable weight.
determining, via the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger] (Ram [Col. 2, Lines 45-47]: The master node can access a distributed hash table stored on a distributed ledger that identifies miner nodes that are offering processing capability; [Col. 4, Lines 27-35]: For example, reputation information of various miner nodes can be encoded into the distributed ledger using a Merkle tree structure, in which each miner node 120 is identified by a public key, username, and/or decentralized identify hashed into distributed ledger), (see Col. 9, Lines 46-48); and
Examiner’s Note: with respect to “determining, via the smart contract”. This limitation does not limit the functionality of the claimed system because this limitation is outside the scope of the claimed system. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed system. Therefore, this limitation has limited patentable weight since step of determining, via the smart contract is not positively tied with any structure element of the claimed system. And with respect to the claims 8 and 16, this limitation is not positively recited functional step and hence receive limited patentable weight.
releasing an incentive to the miner of the block (Ram [Col. 9, Lines 6-11]: At 360, a wallet associated with the miner node can be awarded a payment token. The payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task).
As indicated above, Ram discloses, determining, via the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger].
Ram does not specifically disclose; however, Thompson discloses: keys stored on the smart contract (Thompson [0056]: The smart contract component 370 can determine whether each of the other transactions is digitally-signed with a private key of a set of known private keys. More specifically, the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request), (see paragraphs [0056]-[0058] and [0066]).
Ram doesn’t explicitly disclose; However, Thompson discloses: wherein the list of incentivized keys is a list of public keys of green miners that use an energy mix to mine blocks to the blockchain network that includes at least renewable energy (Thompson [0021]: In various industries, computing devices can be coupled to electric, mechanical, or electro-mechanical devices that generate measured or measurable amounts of real-world assets. By way of a non-limiting example, the renewable energy sector is one industry that utilizes such devices. A renewable energy generator can generate electricity from a renewable energy source, such as the sun, wind, or running water, among other things. Renewable energy generators can include meters, that are adapted to measure real world assets (i.e., amounts of electricity) being generated by a renewable energy generator harnessing a renewable energy source.), (see also paragraphs [0023], [0047] and [0056]-[0059] and Fig. 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ram with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) on a smart contract to improve blockchain consensus-based transaction authorization framework.
Ram doesn’t explicitly disclose; However, Kaplan discloses:
receiving a message directed to the smart contract that the transaction in the transaction request has been mined on the block of the second blockchain network, wherein the second blockchain network is different from the first blockchain network (Kaplan [Col. 4, Lines 23-41]: the remote warden systems can be configured to receive an encrypted transaction from the bridge to confirm asset operations were performed on the first blockchain network and the second blockchain network, and the bridge program further can be configured to validate that the asset operations were successfully performed on the first blockchain network and the second blockchain network in response to receiving the confirmation from at least a threshold of the remote warden systems. Sometimes, the threshold can include at least a majority of the remote warden systems. Sometimes, the asset operations can include the native assets being transferred to a wallet associated with the bridge on the first blockchain network. In yet some implementations, the bridge program further can be configured to only mint the synthetic assets in response to at least the threshold of the remote warden systems confirming that the natives assets have been transferred to the wallet associated with the bridged in the first blockchain network; [Col. 13, Lines 25-36]: a user can initiate transferring of token 126A from the user's wallet 116 to a bridge wallet 118 on the first blockchain 104A (step A). The token 126A can be a token, cryptocurrency, or other digital asset of the first blockchain 104A. Transferring the token 126A can include transferring a quantity of the token 126A into the bridge wallet 118. When the token 126A is transferred into the bridge wallet 118, the user is beginning a transaction to transfer their token 126A from the first blockchain 104A for use on the second blockchain 104B. In other words, the user is beginning a transaction to mint a token on the second blockchain 104B);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Thompson with Kaplan to include well-known functions of blockchain such as implement multiple blockchain networks to improve blockchain consensus-based transaction authorization framework.
Regarding claim 2: Ram, Thompson and Kaplan, discloses the limitations of claim 1 above.
Ram further discloses: The verification system of claim 1, wherein the transaction request further comprises an unspent transaction output directed to a verification system public key, wherein the unspent transaction output is based on a […] threshold (Ram [Col. 4, Lines 27-35]: For example, reputation information of various miner nodes can be encoded into the distributed ledger using a Merkle tree structure, in which each miner node 120 is identified by a public key, username, and/or decentralized identify hashed into distributed ledger. Master nodes 130 can automatically receive a payment token (e.g., a portion of the payment token staked by the customer node 110) in response to assigning subtasks to available miner nodes 120).
Examiner’s Note: claim 2 recites “wherein the unspent transaction output is based on a spoofing threshold” this is nonfunctional descriptive material as it only describes data values, while the data values are not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. See MPEP 2111.05.
Ram does not explicitly disclose usage of a spoofing threshold. However, as indicated above, this limitation difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01).
Regarding claim 4: Ram, Thompson and Kaplan, discloses the limitations of claim 1 above.
Ram doesn’t explicitly disclose; However, Thompson discloses: The verification system of claim 3, wherein the operations further comprise:
determining whether the digital signature in the message is valid. (Thompson [0063]: In some aspects, the generated transaction can include additional information provided by the privileged entity approving the transaction, such as metadata to be included into a digital token generated based on a determined consensus of the privileged entities. Based on the transaction being generated, the transaction signing component 670 can employ a private key associated with the privileged client 230B, to digitally sign the transaction, indicating that it is verifiably generated by the privileged entity or privileged client 230B thereof), (see paragraphs [0028]-[0029] and [0051] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Kaplan with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 5: Ram, Thompson and Kaplan, discloses the limitations of claim 1 above.
Ram further discloses: The verification system of claim 3, wherein the operations further comprise:
verifying that at least one transaction on the block is directed to a verification system public key (see Col. 4, Lines 27-35).
Alternatively, Thompson discloses: verifying that at least one transaction on the block is directed to a verification system public key (see paragraphs [0023], [0047] and [0056]-[0058]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Kaplan with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 6: Ram, Thompson and Kaplan, discloses the limitations of claim 1 above.
As indicated above Ram discloses, the payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task.).
Ram doesn’t explicitly disclose; However, Thompson discloses:
determining that the block has a number of confirmations above a confirmation threshold (Thompson [0027]: While any node can generate a transaction to be added to the blockchain, the consensus module requires that the record be added to the blockchain only based on a determination that a consensus (e.g., greater than 50%) of the nodes 110A-110F has collectively validated the transaction; [0030]: the blockchain includes validated transactions that are grouped into a cryptographically chained series of blocks, whereby each block includes a subset of these transactions. Any node 110A-110F can perform the process of block generation, which can be implemented in a variety of ways based on a consensus algorithm implemented within its consensus module including, but not limited to, proof of work, proof of stake, proof of authority, practical Byzantine Fault Tolerance, or Federated Byzantine Agreements. As the aforementioned processes for block generation are generally known in the art, additional detail for these processes are not described herein.) (see paragraphs [0023], [0025], [0027] and [0030]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Kaplan with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Ram et al. (US 10841372 B1, “Ram”) in view of David Matthew Thompson (US 20200097950 A1, “Thompson”) in view of Kaplan et al (US 11496327 B1, “Kaplan”), and further in view of SUBRA GIRISH (US 20210176041 A1, “GIRISH”).
Regarding claim 3: Ram, Thompson and Kaplan, discloses the limitations of claim 1 above.
Ram further discloses: The verification system of claim 1, wherein the message includes one or more of a public key of the miner, […], the hash of the transaction on the block and […] (see Col. 7, Lines 34-39).
Ram does not explicitly disclose; however, Thompson discloses: the message includes one or more of a public key of the miner, [….] and a digital signature (Thompson [0056]: the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request), (see paragraphs [0056]-[0058] and [0066]); [0063]: In some aspects, the generated transaction can include additional information provided by the privileged entity approving the transaction, such as metadata to be included into a digital token generated based on a determined consensus of the privileged entities. Based on the transaction being generated, the transaction signing component 670 can employ a private key associated with the privileged client 230B, to digitally sign the transaction, indicating that it is verifiably generated by the privileged entity or privileged client 230B thereof), (see paragraphs [0028]-[0029] and [0051] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Kaplan with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Ram does not explicitly disclose; however, GIRISH discloses: the message includes a block number of the mined block (see paragraph [0074] and Fig. 7).
Alternatively, GIRISH further discloses, the message includes a block number of the mined block and the hash of the transaction on the block (see paragraph [0074] and Fig. 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, Kaplan and Thompson with GIRISH to include well-known functions of blockchain such as including additional data variables to a transaction message to improve blockchain consensus-based transaction authorization framework.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over unpatentable over Ram et al. (US 10841372 B1, “Ram”) in view of COUGHLAN et al. (US 20220405747 A1, “COUGHLAN”).
Regarding claim 8: Ram discloses: A method comprising:
broadcasting a transaction request, wherein the transaction request includes an on-chain transaction to be mined on a block of a blockchain network and an unspent transaction output directed to a verification system public key (Ram [Col. 8, Lines 28-30]: At 320, the mining node can receive an indication of a processing task. For example, a master node can select the miner node and assign a task to the mining node; [Col. 8, Lines 11-13]: In some instances, the indication of processing capacity can include and/or be accompanied by a staked payment token. Similarly stated, the miner node can commit a value of cryptocurrency to escrow as security against malfeasance. In some instances the smart contract requesting the processing task can make it a precondition for miner nodes to stake a payment token before they can be selected for completing the processing task and/or subtasks associated with the processing task), (see abstract and Fig. 3);
receiving a message directed to a smart contract that the transaction in the transaction request has been mined, by a miner, on the block of the blockchain network (Ram [Col. 8, Lines 38-43]: At 330, the miner node can be operable to execute the processing task to completion. A cryptographic proof that the processing task was completed can be defined at 340. For example, the miner node can compute a cryptographic hash, such as a zk-POW, zero-knowledge, non-interactive POW, and/or zk-SNARKs value. The output of the cryptographic processing task can be sent to a recipient node; [Col. 2, Lines 20-26]: Embodiments described herein also relate to smart contracts such that users with a need for computing resources can stake a payment token such that miners are incentivized to solve a computational problem and are automatically awarded payment upon completion of the computational problem or a subtask associated with the computational problem), (see abstract, Col. 8, Lines 38-59 and Figs. 3 and 5), […];
querying, via an oracle, the block containing the transaction from the blockchain network (Ram Col. 2, Lines 47-49]: The master node can further identify a recipient node to which an output of the processing request is to be sent), (see Col. 9, Line 60 – Col. 10, Line 21);
determining, via the smart contract, that a hash of the transaction on the block matches the hash in the message (Ram [Col. 7, Lines 34-39]: The miner nodes' 221-225 cryptographic proof of work can be compared to a similarly computed cryptographic hash generated by the customer node 210. If the cryptographic hash generated by the customer node 210 matches a cryptographic proof-of-work generated by a miner node 221-225, the customer node 210 can send a signal to a node containing an instance of the smart contract to cause a portion of the payment token staked by the customer node 210 to be released to a wallet associated with the miner node that generated the valid proof-of-work), (see Col. 9, Lines 40-45 and Fig. 4);
determining, via the smart contract, that the mined block contains the unspent transaction output directed to the verification system public key (Ram [Col. 9, Lines 6-24]: At 360, a wallet associated with the miner node can be awarded a payment token. The payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task. In some instances, a master node, a customer node, and/or a recipient node can send a signal to a node storing an instance of a smart contract to cause the smart contract to perform an action, such as releasing payment to the miner node, that was contingent upon receiving the output of the processing task and/or verifying the proof of work generated by the miner node. In addition or alternatively, the payment token staked by the customer node can be divided amongst all miner nodes that performed subtasks associated with the processing task commissioned by the customer node (e.g., in proportion to their contribution to the processing task, in proportion to their stake, in proportion to their reputation, etc.)); and
based on the determining that the mined block contains the unspent transaction output, releasing an incentive to a miner of the block (Ram [Col. 9, Lines 6-11]: At 360, a wallet associated with the miner node can be awarded a payment token. The payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task).
Ram does not specifically disclose; however, COUGHLAN, discloses, wherein the miner detects the unspent transaction output directed to the verification system public key and in response to detecting the unspent transaction output mines the transaction in the block (COUGHLAN [0110]: tep 110 depicts the step of sending a request to one or more miners among the plurality of miners for generating a blockchain transaction corresponding to the given transaction in step 108. In this step, the payment processor in some embodiments converts the HTTPS POST request in the previous step to an RPC request for submission to the miners. This may be done with the request RPC createRawTransaction(Tx), where Tx includes data associated with the given transaction, given as a JSON object as discussed in step 108. The RPC createRawTransaction(Tx) is an RPC call to create a transaction spending given inputs and creating new outputs, where outputs can be addresses or data. The RPC request may be sent to the plurality of miners, or to the miners that meet or satisfy the selected fee quote from the client in step 108. As mentioned above, miners that have provided current fee quotes at or below the selected fee quote are considered to satisfy the requirement of the selected fee quote, as they can mine the transaction at their respective current quoted fee. In response, a miner that satisfies the selected fee quote creates a blockchain transaction corresponding to the given transaction. In some embodiments, a hex-encoded raw transaction corresponding to the given transaction is returned to the payment processor; [0088]: In step 108 a second request is received from the client, the second request being a request to submit a given transaction pertaining to a selected fee quote among the obtained fee quotes. The given transaction in some embodiments is based on a digital asset payment that is made to the client by a customer in response to a payment request from the client. For instance, this may satoshis or other types of digital asset payment in return for a cup of coffee if the client is a merchant terminal in a coffee shop. In this step, the client requests via the payment service API implemented by the payment processor that this digital asset payment is written into the blockchain.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ram with COUGHLAN to include well-known functions of blockchain such as adding additional functionalities of miner/validators node to improve blockchain consensus-based transaction authorization framework.
Regarding claim 9: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram further discloses: The method of claim 8, wherein the transaction request further comprises an unspent transaction output directed to a verification system public key, wherein the unspent transaction output is based on a […] threshold (Ram [Col. 4, Lines 27-35]: For example, reputation information of various miner nodes can be encoded into the distributed ledger using a Merkle tree structure, in which each miner node 120 is identified by a public key, username, and/or decentralized identify hashed into distributed ledger. Master nodes 130 can automatically receive a payment token (e.g., a portion of the payment token staked by the customer node 110) in response to assigning subtasks to available miner nodes 120).
Examiner’s Note: claim 9 recites “wherein the unspent transaction output is based on a spoofing threshold” this is nonfunctional descriptive material as it only describes data values, while the data values are not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. See MPEP 2111.05.
Ram does not explicitly disclose usage of a spoofing threshold. However, as indicated above, this limitation difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01).
Claim 10-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ram et al. (US 10841372 B1, “Ram”) in view of COUGHLAN et al. (US 20220405747 A1, “COUGHLAN”), in view of David Matthew Thompson (US 20200097950 A1, “Thompson”), and further in view of SUBRA GIRISH (US 20210176041 A1, “GIRISH”).
Regarding claim 10: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram further discloses: The method of claim 8, wherein the message includes one or more of a public key of the miner, […], the hash of the transaction on the block and […] (see Col. 7, Lines 34-39).
Ram does not explicitly disclose; however, Thompson discloses: the message includes one or more of a public key of the miner, [….] and a digital signature (Thompson [0056]: the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request), (see paragraphs [0056]-[0058] and [0066]); [0063]: In some aspects, the generated transaction can include additional information provided by the privileged entity approving the transaction, such as metadata to be included into a digital token generated based on a determined consensus of the privileged entities. Based on the transaction being generated, the transaction signing component 670 can employ a private key associated with the privileged client 230B, to digitally sign the transaction, indicating that it is verifiably generated by the privileged entity or privileged client 230B thereof), (see paragraphs [0028]-[0029] and [0051] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ram and COUGHLAN with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Ram does not explicitly disclose; however, GIRISH discloses: the message includes a block number of the mined block (see paragraph [0074] and Fig. 7).
Alternatively, GIRISH further discloses, the message includes a block number of the mined block and the hash of the transaction on the block (see paragraph [0074] and Fig. 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, COUGHLAN and Thompson with GIRISH to include well-known functions of blockchain such as including additional data variables to a transaction message to improve blockchain consensus-based transaction authorization framework.
Regarding claim 11: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram further discloses: The method of claim 10, wherein the hash of the block is signed using the one or more of the public key of the miner, […] (see Col 4, Lines 28-35 and Col. 7, Lines 34-43.
Ram doesn’t explicitly disclose; However, Thompson discloses: wherein the one or more of the public key is a green key (see also paragraphs [0023], [0047] and [0056]-[0059] and Fig. 4).
Alternatively, Thompson further discloses: wherein the hash of the block is signed using the one or more of the public key of the miner (see paragraphs [0006], [0031]-[0032] and [0046]-[0047]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination Ram, COUGHLAN and GIRISH with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 12: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram doesn’t explicitly disclose; However, Thompson discloses: The method of claim 10, further comprising:
determining whether the digital signature in the message is valid (Thompson [0063]: In some aspects, the generated transaction can include additional information provided by the privileged entity approving the transaction, such as metadata to be included into a digital token generated based on a determined consensus of the privileged entities. Based on the transaction being generated, the transaction signing component 670 can employ a private key associated with the privileged client 230B, to digitally sign the transaction, indicating that it is verifiably generated by the privileged entity or privileged client 230B thereof), (see paragraphs [0028]-[0029] and [0051] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination Ram, COUGHLAN and GIRISH with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 13: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram further discloses: The method of claim 10, wherein the operations further comprise:
verifying that at least one transaction on the block is directed to a verification system public key (see Col. 4, Lines 27-35).
Alternatively, Thompson discloses: verifying that at least one transaction on the block is directed to a verification system public key (see paragraphs [0023], [0047] and [0056]-[0058]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, COUGHLAN and GIRISH with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 14: Ram and COUGHLAN, discloses the limitations of claim 8 above.
As indicated above Ram discloses, the payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task.).
Ram doesn’t explicitly disclose; However, Thompson discloses:
determining that the block has a number of confirmations above a confirmation threshold (Thompson [0027]: While any node can generate a transaction to be added to the blockchain, the consensus module requires that the record be added to the blockchain only based on a determination that a consensus (e.g., greater than 50%) of the nodes 110A-110F has collectively validated the transaction; [0030]: the blockchain includes validated transactions that are grouped into a cryptographically chained series of blocks, whereby each block includes a subset of these transactions. Any node 110A-110F can perform the process of block generation, which can be implemented in a variety of ways based on a consensus algorithm implemented within its consensus module including, but not limited to, proof of work, proof of stake, proof of authority, practical Byzantine Fault Tolerance, or Federated Byzantine Agreements. As the aforementioned processes for block generation are generally known in the art, additional detail for these processes are not described herein.) (see paragraphs [0023], [0025], [0027] and [0030]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, COUGHLAN and GIRISH with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 15: Ram and COUGHLAN, discloses the limitations of claim 8 above.
Ram further discloses: The method of claim 10, the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger] (Ram [Col. 2, Lines 45-47]: The master node can access a distributed hash table stored on a distributed ledger that identifies miner nodes that are offering processing capability; [Col. 4, Lines 27-35]: For example, reputation information of various miner nodes can be encoded into the distributed ledger using a Merkle tree structure, in which each miner node 120 is identified by a public key, username, and/or decentralized identify hashed into distributed ledger), (see Col. 9, Lines 46-48);.
As indicated above, Ram discloses, determining, via the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger].
Ram does not specifically disclose; however, Thompson discloses: keys stored on the smart contract (Thompson [0056]: The smart contract component 370 can determine whether each of the other transactions is digitally-signed with a private key of a set of known private keys. More specifically, the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request), (see paragraphs [0056]-[0058] and [0066]).
Ram doesn’t explicitly disclose; However, Thompson discloses: wherein the list of incentivized keys is a list of public keys of green miners that use an energy mix to mine blocks to the blockchain network that includes at least renewable energy (Thompson [0021]: In various industries, computing devices can be coupled to electric, mechanical, or electro-mechanical devices that generate measured or measurable amounts of real-world assets. By way of a non-limiting example, the renewable energy sector is one industry that utilizes such devices. A renewable energy generator can generate electricity from a renewable energy source, such as the sun, wind, or running water, among other things. Renewable energy generators can include meters, that are adapted to measure real world assets (i.e., amounts of electricity) being generated by a renewable energy generator harnessing a renewable energy source.), (see also paragraphs [0023], [0047] and [0056]-[0059] and Fig. 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, COUGHLAN and GIRISH with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Claims 16-19 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Ram et al. (US 10841372 B1, “Ram”) in view of David Matthew Thompson (US 20200097950 A1, “Thompson”) in view of SUBRA GIRISH (US 20210176041 A1, “GIRISH”) further in view of LEONARD et al. (US 20180300741 A1, “LEONARD”).
Regarding claim 16: A non-transitory computer readable medium having instructions stored thereon, that when executed by a processor cause the processor to perform operations, the operations comprising:
receiving a message directed to a smart contract that a transaction has been mined on a block of a blockchain network by a miner, (Ram [Col. 8, Lines 38-43]: At 330, the miner node can be operable to execute the processing task to completion. A cryptographic proof that the processing task was completed can be defined at 340. For example, the miner node can compute a cryptographic hash, such as a zk-POW, zero-knowledge, non-interactive POW, and/or zk-SNARKs value. The output of the cryptographic processing task can be sent to a recipient node; [Col. 2, Lines 20-26]: Embodiments described herein also relate to smart contracts such that users with a need for computing resources can stake a payment token such that miners are incentivized to solve a computational problem and are automatically awarded payment upon completion of the computational problem or a subtask associated with the computational problem), (see abstract, Col. 8, Lines 38-59 and Figs. 3 and 5), wherein the message includes a public key of the miner, […], a hash of the block, and […] (see Col. 4, Lines 28-35; Col. 7, Lines 34-39 and claim 18);
querying, via an application programming interface, the block containing the transaction from the blockchain network for a hash of the block (Ram Col. 2, Lines 47-49]: The master node can further identify a recipient node to which an output of the processing request is to be sent), (see Col. 9, Line 60 – Col. 10, Line 21);
determining, via the smart contract, that the hash of the block containing the transaction matches the hash of the block in the message (Ram [Col. 7, Lines 34-39]: The miner nodes' 221-225 cryptographic proof of work can be compared to a similarly computed cryptographic hash generated by the customer node 210. If the cryptographic hash generated by the customer node 210 matches a cryptographic proof-of-work generated by a miner node 221-225, the customer node 210 can send a signal to a node containing an instance of the smart contract to cause a portion of the payment token staked by the customer node 210 to be released to a wallet associated with the miner node that generated the valid proof-of-work), (see Col. 9, Lines 40-45 and Fig. 4);
determining, via the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger] (Ram [Col. 2, Lines 45-47]: The master node can access a distributed hash table stored on a distributed ledger that identifies miner nodes that are offering processing capability; [Col. 4, Lines 27-35]: For example, reputation information of various miner nodes can be encoded into the distributed ledger using a Merkle tree structure, in which each miner node 120 is identified by a public key, username, and/or decentralized identify hashed into distributed ledger), (see Col. 9, Lines 46-48);
determining, via the smart contract, that the […] the message is valid by verifying that the [task completed] using the public key of the miner (Ram [Col. 8, Lines 38-55]: At 330, the miner node can be operable to execute the processing task to completion. A cryptographic proof that the processing task was completed can be defined at 340. For example, the miner node can compute a cryptographic hash, such as a zk-POW, zero-knowledge, non-interactive POW, and/or zk-SNARKs value. The output of the cryptographic processing task can be sent to a recipient node, at 350. In some instances, the recipient node can be the customer node (e.g., when the computing task is training a machine learning model). In other instances, the recipient node can be a node other than customer node (e.g., when the computing task is streaming video). In some instances, the immediate recipient can be another node of the distributed network that within a route to the recipient node. Similarly stated, the miner node may not be directly coupled to the recipient node, but may pass the result of the computing task to the recipient node via one or more intermediate nodes of the distributed network. In some instances, the recipient node can be a master node, such that the master node can combine or coordinate outputs of multiple subtasks completed by multiple miner nodes before passing an output of the overall processing task to the ultimate recipient node), (see Col. 2, Lines 27-55); and
releasing an incentive to the miner of the block (Ram [Col. 9, Lines 6-11]: At 360, a wallet associated with the miner node can be awarded a payment token. The payment token can be automatically awarded by a smart contract (e.g., defined by a customer node) upon completion of the assigned processing task and/or production of a proof of work demonstrating the faithful (accurate) completion of the processing task).
As indicated above, Ram discloses, determining, via the smart contract, that a [identifier / public key] of a miner matches a list of incentivized keys (e.g., hash table) stored on the [distributed ledger].
Ram does not specifically disclose; however, Thompson discloses: keys stored on the smart contract (Thompson [0056]: The smart contract component 370 can determine whether each of the other transactions is digitally-signed with a private key of a set of known private keys. More specifically, the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request), (see paragraphs [0056]-[0058] and [0066]).
Ram doesn’t explicitly disclose; However, Thompson discloses: wherein the list of incentivized keys is a list of public keys of green miners that use an energy mix to mine blocks to the blockchain network that includes at least renewable energy (Thompson [0021]: In various industries, computing devices can be coupled to electric, mechanical, or electro-mechanical devices that generate measured or measurable amounts of real-world assets. By way of a non-limiting example, the renewable energy sector is one industry that utilizes such devices. A renewable energy generator can generate electricity from a renewable energy source, such as the sun, wind, or running water, among other things. Renewable energy generators can include meters, that are adapted to measure real world assets (i.e., amounts of electricity) being generated by a renewable energy generator harnessing a renewable energy source.), (see also paragraphs [0023], [0047] and [0056]-[0059] and Fig. 4).
Ram does not explicitly disclose; however, Thompson discloses: the message includes one or more of a public key of the miner, [….] and a digital signature (Thompson [0056]: the smart contract component 370 can employ the validating component 350 to determine that one of a set of known public keys, stored in the token generation smart contract, is associated with a transaction approving or denying the request; [0063]: In some aspects, the generated transaction can include additional information provided by the privileged entity approving the transaction, such as metadata to be included into a digital token generated based on a determined consensus of the privileged entities. Based on the transaction being generated, the transaction signing component 670 can employ a private key associated with the privileged client 230B, to digitally sign the transaction, indicating that it is verifiably generated by the privileged entity or privileged client 230B thereof), (see paragraphs [0028]-[0029] and [0051] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ram with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Ram does not explicitly disclose; however, GIRISH discloses: the message includes a block number of the mined block (see paragraph [0074] and Fig. 7).
Alternatively, GIRISH further discloses, the message includes a block number of the mined block and the hash of the transaction on the block (see paragraph [0074] and Fig. 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram and Thompson with GIRISH to include well-known functions of blockchain such as including additional data variables to a transaction message to improve blockchain consensus-based transaction authorization framework.
Ram doesn’t explicitly disclose, validating a digital signature.
However, LEONARD discloses:
determining, via the smart contract, that the digital signature in the message is valid by verifying that the digital signature was signed using the public key of the miner (LEONARD [0092]: A smart contract can have computer code to automatically verify the signatures and if they do not match the transaction they can be automatically rejected; [0106]: A user 702 logs into an online platform such as a social network or search engine 706 to access the user application 708. The user 702 can also log in directly to the user application 708. The user 702 uses user application 708 to create or update a user profile managed as a smart contract 712. The user 702 uses user application 708 to set up bid preferences that identify the user, product and a bid request. When user 702 places a bid then a smart contract 712 is used to define the bid parameters are scope. The user application 708 signs the bid transaction with the user key pair and smart contracts 712 will verify the transaction signature. The block chain network 714 propagates the bid event to merchants 704 by way of merchant application 710. Smart contracts 71 to include merchant contracts to listen to bid events and automate the notification to merchants 704).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, Thompson and GIRISH with LEONARD to include well-known functions of blockchain such as including cryptograph features of digital signatures to validate a transaction to improve blockchain consensus-based transaction authorization framework.
Regarding claim 17: Ram, Thompson, GIRISH and LEONARD, discloses the limitations of claim 16 above.
Ram further discloses: The non-transitory computer readable medium of claim 16, further comprising:
broadcasting a transaction request, wherein the transaction request includes the transaction mined on the block of the blockchain network (see abstract, Col. 8, Lines 28-30 and Fig. 3) and
an unspent transaction output directed to a verification system public key (see Col. 4, Lines 27-35).
Regarding claim 18: Ram, Thompson, GIRISH and LEONARD, discloses the limitations of claim 16 above.
Ram doesn’t explicitly disclose; However, Thompson discloses: the miner is a green miner using green energy or a mix of green energy to mine the block (Thompson [0021]: In various industries, computing devices can be coupled to electric, mechanical, or electro-mechanical devices that generate measured or measurable amounts of real-world assets. By way of a non-limiting example, the renewable energy sector is one industry that utilizes such devices. A renewable energy generator can generate electricity from a renewable energy source, such as the sun, wind, or running water, among other things. Renewable energy generators can include meters, that are adapted to measure real world assets (i.e., amounts of electricity) being generated by a renewable energy generator harnessing a renewable energy source.), (see also paragraphs [0023], [0047] and [0056]-[0059] and Fig. 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, GIRISH and LEONARD with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Regarding claim 19: Ram, Thompson, GIRISH and LEONARD, discloses the limitations of claim 16 above ve.
Ram does not explicitly disclose; however, GIRISH discloses: The non-transitory computer readable medium of claim 18, wherein the operations further comprise:
determining that the block having the block number includes the transaction on the blockchain network (see paragraphs [0048], [0063] and [0074]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, Thompson and LEONARD with GIRISH to include well-known functions of blockchain such as including additional data variables to a transaction message to improve blockchain consensus-based transaction authorization framework.
Regarding claim 21: Ram, Thompson, GIRISH and LEONARD, discloses the limitations of claim 16 above.
Ram further discloses: The non-transitory computer readable medium of claim 16, wherein the operations further comprise:
verifying that at least one transaction on the block is directed to a verification system public key (Col. 4, Lines 16-35).
Regarding claim 22: Ram, Thompson, GIRISH and LEONARD, discloses the limitations of claim 16 above.
Ram does not explicitly disclose; however, Thompson discloses: The non-transitory computer readable medium of claim 16, wherein the operations further comprise:
determining that the block has a number of confirmations above a confirmation threshold (Thompson [0027]: a consensus module (not shown) that is independently included and operated by any number of nodes 110A-110F. While any node can generate a transaction to be added to the blockchain, the consensus module requires that the record be added to the blockchain only based on a determination that a consensus (e.g., greater than 50%) of the nodes 110A-110F has collectively validated the transaction. In this regard, while each node 110A-110F can independently store a copy of the blockchain, a transaction can only be added to the blockchain when a consensus to add the transaction has been reached by the nodes 110A-110F of the distributed ledger network 100.) (see paragraphs [0027]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ram, GIRISH and LEONARD with Thompson to include well-known functions of blockchain such as storing data (e.g., keys) a smart contract to improve blockchain consensus-based transaction authorization framework.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure are the following:
KULKARNI et al. (US 20220084013 A1) discloses, a digital asset system comprises a user information system, a transaction machine instructions generator to produce machine instructions of a blockchain transaction, a signing module, a blockchain communications system that sends system-signed messages to a blockchain system, and a transaction mediating system that receives user input comprising a transaction data structure representing the blockchain transaction. The transaction mediating system can send machine instructions to other elements of the system in response to user input and machine instructions of the blockchain transaction for execution on a blockchain system. The signature module can generate a system-signed message with a digital signature associated with the digital asset system, (a) machine instructions of a transaction for execution on a blockchain system received from the transaction instructions generator or (b) a user-signed machine instructions of a transaction for execution on a blockchain system received from the transaction mediating system.
Gujar et al. (US 20230274262 A1) discloses, a system for better utilization of power consumption of a computing network in at least one blockchain system by validating digital currency transactions with minimal computing resources. The system is configured to (i) communicate at least one problem with a difficulty calculation specification using a centralized server, (ii) create a problem mempool to broadcast the at least one problem with the difficulty calculation specification, (iii) create a transaction mempool to enable the at least one miner to select the at least one transaction, (iv) validate a solution that corresponds to the at least one problem, (v) verify a block associated with the selected problem with a validated solution as proof of work and (vi) determine a problem fee for the at least one miner for the solved problem when the block associated is verified.
RULE et al. (US 20210390549 A1) discloses, methods build blockchains and verify assets for smart contracts. A system includes a memory, a blockchain, a set of nodes, a set of verifiers, a set of miners, and a consensus protocol. The memory can have a block data structure representing a transaction for an asset having an identifier and at least one verifiable characteristic. The consensus protocol can include rules for: receiving the stake at risk from the verifiers, providing the reputational score to the verifiers, verifying the verifiable characteristic of the asset by the verifiers, cryptographic verification by the miners, adding the new block to the blockchain by the miners, providing the reward to the miners, and distributing the copy of the blockchain to each node.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F.
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, Neha Patel can be reached on (571) 270-1492. 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.
/JAHED ALI/
Examiner, Art Unit 3699
Prosecution Insights