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 .
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on February 17, 2025. Claims 1-20 are pending, of which claims 1, 19 and 20 are in independent form.
Drawings
The drawings are objected to because figures 1-5, 7-13 and 14A-14D are designated using the word “Figure” rather than the required abbreviation “FIG”. Applicant is required to submit corrected drawing sheets changing for example , “Figure 1” to “FIG. 1”. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because it contains grammatical and technical inconsistencies. Specifically, the phrase “at a verifying nodes…” needs to be changed to “at a verifying node…”.
Further, the abstract defines “ƒ” as a combining q and d, although the preceding expression is “ƒ(r,d)” and q is not defined. A proper correction is required.
The Specification is objected to because paragraph [0236] states “FIG. 14C shows the combination of the r-puzzle proof-of-work with the verification of FIG. 8 . FIG. 14C shows the combination of the r-puzzle proof-of-work with the verification of FIG. 9”. However, the second reference to FIG. 14C should be FIG. 14D. A proper correction is required.
Claim Objections
Claim 1 objected to because of the following informalities: Claim 1 recites “wherein said predetermined condition wherein the first hash is a result of…” contains duplicative and grammatically improper “wherein” language. Appropriate correction is required.
Claim 5 recites “the method of any of claim 4” is grammatically improper because claim 5 refers to only one preceding claim. Appropriate correction is required.
Claim 10 objected to because of the following informalities: Claim 10 recites “the submitted instance of the component of the first cryptographic signature were generated”. Applicant is required to replace “were generated” with “was generated”. 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 4-10, 14-15, 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 4-10, 14 and 17 recite “the first cryptographic signature”. There is insufficient antecedent basis for this limitation in the claims. Claim 1 introduces only “a cryptographic signature”, and does not identify it as a “a first cryptographic signature”. It is unclear whether “the first cryptographic signature” refers to the cryptographic signature introduced in claim 1 or to a different cryptographic signature. Therefore, the examiner interprets “the first cryptographic signature” under its broadest reasonable interpretation consistent with the specification. Appropriate correction is required.
Claim 14 is rejected as being indefinite because the term “the first public key” lacks antecedent basis. Claim 14 depends from claim 10, and claim 10 does not introduce a first public key. Accordingly, it is unclear what public key is intended by “the first public key” and what relationship that key has to the first private key or the first cryptographic signature. Therefore, the examiner interprets “the first public key” under its broadest reasonable interpretation consistent with the specification. Appropriate correction is required.
Claim 15 is rejected as being indefinite because of the term “validating the transaction”. The claim previously identifies both a first transaction and a second transaction. It is therefore unclear whether “the transaction” refers to the first or the second transaction. Accordingly, the metes and bounds of the claim are uncertain. Appropriate correction is required.
Claim 19 is rejected as being indefinite. The phrase “when run on a node of a blockchain network the blockchain performs the steps…:” is unclear because the computer program is run on the node, however, the claim states the blockchain performs the recited steps. Therefore, the metes and bounds of the claim is uncertain whether the recited steps are performed by the node executing the computer program or by the blockchain as a whole. Appropriate correction is required.
Claim 19 recites “the first hash”. There is insufficient antecedent basis for this limitation in the claim. Claim 19 introduces only “a hash”, and does not identify it as a “a first hash”. Therefore, it is unclear whether “the first hash” refers to the hash introduced in claim 19 or to a hash. Therefore, the examiner interprets “the first hash” under its broadest reasonable interpretation consistent with the specification. Appropriate correction is required.
Claim 20 is rejected as being indefinite because the phrase “said verifying that the hash meets the predetermined condition…” lacks clear antecedent basis. The claim previously introduces “a hash value”, but does not introduce a separate element identified as “the hash”. Accordingly, it is unclear whether “the hash” refers to the previously recited hash value or to a different value. Therefore, the examiner interprets “the hash” under its broadest reasonable interpretation consistent with the specification. Appropriate correction is required.
Claim 18 is similarly rejected by virtue of dependency to claim 17.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1- 9, 16-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Salami et al. (US 2017/0345011 A1), hereinafter Salami in view of Chalkias (US 2019/0319798 A1), hereinafter Chalkias.
Regarding claim 1, Salami discloses a computer-implemented method comprising, at a verifying node of a blockchain network (Salami, Para. 0014, receiving the indication of the state transition from the first node at the validation node): obtaining a first transaction which comprises runnable code (Salami, Para. 0030, first and second transactions 100 and 102 take place in order to set up the initial state. As shown in FIG. 1A, the first transaction 100 deploys computer code 104 to the blockchain that contains the computer instructions needed to settle a forward contract between two market participants but does not yet contain the detailed parameters of the agreement); receiving a second transaction which includes information comprising at least a submitted instance of a component of a cryptographic signature (Salami, Para. 0006, processing a mark to market for a mark to market date with the second market participant computer by receiving a contract value of a mark to market at the second blockchain node with a signature), and further comprising a nonce (Salami, Para. 0068, the node ensures that the nonce included in the transaction is the value that is expected for the sending account); running the code from the first transaction (Salami, Fig. 5B), and return a result of true on condition of said verifying that the first hash meets the predetermined condition defined in the code (Salami, Fig. 5B , and Para. 0090, When the other nodes receive the block, they validate the block by checking that the nonce and block hash are correct and then add the block to their own local copy of the blockchain. At that time, the other nodes stop mining their own versions of the block and instead start mining the next block (not shown). Each block has a number, a hash that uniquely identifies the block and a hash that uniquely identifies the parent block).
Salami does not explicitly disclose wherein the code is configured to: verify that a first hash meets a predetermined condition defined in the code, wherein said predetermined condition wherein the first hash is a result of a first hash function applied to a combination of the component and the nonce, and wherein said predetermined condition defines a set of acceptable output values of the first hash function;
However, Chalkias teaches wherein the code is configured to: verify that a first hash meets a predetermined condition defined in the code (Chalkias, Para. 0102, a characteristic may be that the hash is to include a certain pattern such as some number of leading or trailing zeros, a certain pattern of 1s and 0s in the middle of the hash, and so on), wherein said predetermined condition wherein the first hash is a result of a first hash function applied to a combination of the component and the nonce (Chalkias, Para. 0104, To verify the signature, the verifier would generate a hash of the combination of the content and the nonce of the signature), and wherein said predetermined condition defines a set of acceptable output values of the first hash function (Chalkias, Para. 0102, a characteristic may be that the hash is to include a certain pattern such as some number of leading or trailing zeros, a certain pattern of 1s and 0s in the middle of the hash, and so on. Another characteristic may be that the hash has at least a certain number of 1s);
Salami and Chalkias are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction.
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein the code is configured to: verify that a first hash meets a predetermined condition defined in the code (Chalkias, Para. 0102), wherein said predetermined condition wherein the first hash is a result of a first hash function applied to a combination of the component and the nonce (Chalkias, Para. 0104), and wherein said predetermined condition defines a set of acceptable output values of the first hash function (Chalkias, Para. 0102). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 2, the combination of Salami in view of Chalkias teaches the method of claim 1, wherein said combination is a concatenation of the component and the nonce (Chalkias, Figs. 19 and 20, Item 2002, and Para. 0107, The find nonce component 2000 is invoked passing an indication of the message and the pattern and identifies a nonce that results in hash of the message and the nonce that has the pattern). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein said combination is a concatenation of the component and the nonce (Chalkias, Figs. 19 and 20). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 3, the combination of Salami in view of Chalkias teaches the method of claim 1, wherein said predetermined condition comprises one of: a first condition, that the first hash is less than a predetermined upper target value; a second condition, that the first hash is greater than a predetermined lower target value; a third condition, that the first hash is within a predetermined range; a fourth condition, that the first hash has at least a predetermined minimum number of leading zeros; or a fifth condition, that the first hash has a predetermined format (Chalkias, Para. 0102, for example, a characteristic may be that the hash is to include a certain pattern such as some number of leading or trailing zeros, a certain pattern of 1s and 0s in the middle of the hash, and so on. Another characteristic may be that the hash has at least a certain number of 1s); said set of acceptable values being the set of values that satisfies said one of the first, second, third, fourth or fifth conditions (Chalkias, Para. 0102, the BPQS system may publish the specified characteristic as a requirement so that signers will generate hashes of content that satisfy the requirement). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include a fifth condition, that the first hash has a predetermined format (Chalkias, Para. 0102); said set of acceptable values being the set of values that satisfies said one of the first, second, third, fourth or fifth conditions (Chalkias, Para. 0102). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 4, the combination of Salami in view of Chalkias teaches the method of claim 1, further comprising: obtaining a public key wherein the first cryptographic signature signs a message based on a private key corresponding to the public key (Chalkias, Para. 0011, Lamport OTS then generates an OTS public key (OTS verification key), which includes a public key pair for each private key pair) and (Chalkias, Para. 0011, to sign the message, the signer generates an OTS signature that includes one of the two private keys of each private key pair based on the value of the corresponding bit of the message), wherein the message is a part of the second transaction (Chalkias, Para. 0011, the term “message” refers to any electronic data, such as transactions of distributed ledgers, emails, data files, data packets, hash of the electronic data, and so on); and applying a verification function to verify the first cryptographic signature received in the second transaction based on the public key and the message (Chalkias, Para. 0011, to verify the OTS signature of a message, the verifier generates a hash of each of the 256 private keys of the OTS signature, which should correspond to 256 of the public keys, depending on the value of the message. The verifier compares the 256 hashes of the private keys to the 256 public keys of the OTS public key based on the bit value of the message. If they all match, then the signature is verified) and (Chalkias, Paras. 0040-0041), wherein the code is configured to return the result of true on further condition of said verification of the first cryptographic signature (Chalkias, Para. 0041, to verify the signature, the verifier regenerates the OTS public key based on the OTS signature and the message. The verifier also regenerates a Many public key using the regenerated OTS public key and the Many metadata. If the regenerated Many public key matches the published Many public key, then the signature is verified). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include obtaining a public key wherein the first cryptographic signature signs a message based on a private key corresponding to the public key (Chalkias, Para. 0011\), wherein the message is a part of the second transaction (Chalkias, Para. 0011\); and applying a verification function to verify the first cryptographic signature received in the second transaction based on the public key and the message (Chalkias, Para. 0011\) and (Chalkias, Paras. 0040-0041), wherein the code is configured to return the result of true on further condition of said verification of the first cryptographic signature (Chalkias, Para. 0041). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 5, the combination of Salami in view of Chalkias teaches the method of any of claim 4, wherein the code further comprises a reference value corresponding to the component of the first cryptographic signature (Chalkias, Para. 0100, the component generates the root (root[i-1]) for the next prior block as a hash of the concatenation of the value of the fallback OTS public key of the Many metadata for the Many signature of the block (smd.h(FB[i].pub)) and a hash of the OTS public key for the block (h(OTS[i].pub))), wherein the reference value is a reference instance of the component or a transformation of the component (Chalkias, Para. 0100, a hash of the OTS public key for the block (h(OTS[i].pub))); and the code is configured to check that the reference value corresponds to the reference instance of the component received in the second transaction (Chalkias, Para. 0100, if a hash of the regenerated fallback OTS public key (h(FB[i-1].pub)) matches the passed hash of the fallback OTS public key of the prior block (smd.h(FB[i-1].publ), then the component completes indicating that the signature was verified, else the component completes indicating that the signature was not verified), and return the result of true on further condition that the reference value corresponds to the reference instance of the component received in the second transaction based on said check (Chalkias, Para. 0100, if a hash of the regenerated fallback OTS public key (h(FB[i-1].pub)) matches the passed hash of the fallback OTS public key of the prior block (smd.h(FB[i-1].publ), then the component completes indicating that the signature was verified, else the component completes indicating that the signature was not verified). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein the code further comprises a reference value corresponding to the component of the first cryptographic signature (Chalkias, Para. 0100), wherein the reference value is a reference instance of the component or a transformation of the component (Chalkias, Para. 0100); and the code is configured to check that the reference value corresponds to the reference instance of the component received in the second transaction (Chalkias, Para. 0100), and return the result of true on further condition that the reference value corresponds to the reference instance of the component received in the second transaction based on said check (Chalkias, Para. 0100). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 6, the combination of Salami in view of Chalkias teaches the method of claim 5, wherein said reference value is a reference instance of the component of the first cryptographic signature (Chalkias, Para. 0039, the published OTS public key for an OTS key pair can be a hash of the values of the public key pairs of an OTS key pair. Alternatively, the published OTS public key can be simply the values of the public key pairs of an OTS public key or a hash of those values) and (Chalkias, Para. 0040, to verify the Few signature, the verifier regenerates the OTS public key using the OTS signature of the Few signature and the message and regenerates a Few public key using the regenerated OTS public key and the Few metadata. If the regenerated Few public key matches the published Few public key, then the signature is verified). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include the method of claim 5, wherein said reference value is a reference instance of the component of the first cryptographic signature (Chalkias, Para. 0039) and (Chalkias, Para. 0040). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 7, the combination of Salami in view of Chalkias teaches the method of claim 5, wherein said reference value is a transformation of a reference instance of the component of the first cryptographic signature (Chalkias, Para. 0040, the BPQS-Few scheme generates a Few public key that is a hash derived from the OTS public keys of the OTS key pairs), wherein the code is configured to perform said check that the submitted instance corresponds to the reference value by (Chalkias, Para. 0059, to verify the first signature, the verifier first regenerates the OTS public key from the first OTS signature and the first message): performing the same transformation on the submitted instance and comparing to the reference value (Chalkias, Para. 0059, the verifier then regenerates the Few public key as a hash of a concatenation of smd.root[1] and the hash of the regenerated first OTS public key. If the regenerated Few public key matches the published Few public key (root[0]), then the first signature is verified). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein said reference value is a transformation of a reference instance of the component of the first cryptographic signature (Chalkias, Para. 0040), wherein the code is configured to perform said check that the submitted instance corresponds to the reference value by (Chalkias, Para. 0059): performing the same transformation on the submitted instance and comparing to the reference value (Chalkias, Para. 0059). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 8, the combination of Salami in view of Chalkias teaches the method of claim 7, wherein said reference value is a hash value (Chalkias, Paras. 0040-0041, Chalkias, Para. 0040, the Many metadata includes a hash derived from the fallback OTS public key), and wherein the hash value is a hash of the reference instance of the component of the first cryptographic signature (Chalkias, Paras. 0039, the published OTS public key for an OTS key pair can be a hash of the values of the public key pairs of an OTS key pair. Alternatively, the published OTS public key can be simply the values of the public key pairs of an OTS public key or a hash of those values). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein said reference value is a hash value (Chalkias, Paras. 0040-0041), and wherein the hash value is a hash of the reference instance of the component of the first cryptographic signature (Chalkias, Paras. 0039). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 9, the combination of Salami in view of Chalkias teaches the method of claim 4, wherein said obtaining of the public key comprises receiving the public key as part of the information in the second transaction (Chalkias, Para. 0040, to verify the Few signature, the verifier regenerates the OTS public key using the OTS signature of the Few signature and the message and regenerates a Few public key using the regenerated OTS public key and the Few metadata… The term “message” refers to any electronic data, such as transactions of distributed ledgers…) and (Chalkias, para. 0010, when a new transaction, which includes the public key corresponding to the address of the input transaction, is broadcast across the Bitcoin network for insertion into a block of Bitcoin blockchain. A recipient of the new transaction (e.g., a miner) could generate the private key from the public key). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include the method of claim 4, wherein said obtaining of the public key comprises receiving the public key as part of the information in the second transaction (Chalkias, Para. 0040) and Chalkias, para. 0010). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 16, the combination of Salami in view of Chalkias teaches the method of claim 1, wherein the transactions are configured according to an account- based model, and said code is comprised by a smart contract included in the first transaction (Salami, Fig. 5B, and Para. 0091, transactions (i.e. the one shown in FIG. 5B) are sent to the nodes while the nodes are mining new blocks (not shown). Any transactions received while mining will be included in the new block (up to the block's transaction limit), resulting in a change of the block hash and state root). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein the transactions are configured according to an account- based model, and said code is comprised by a smart contract included in the first transaction (Salami, Fig. 5B, and Para. 0091). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Regarding claim 17, the combination of Salami in view of Chalkias teaches the method of claim 1, wherein the first cryptographic signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) signature (Salami, Para. 0037, the service provider computer signs the transaction with an ECDSA signature using a private key controlled only by the service provider and sends the transaction with its signature to the fourth blockchain node).
Regarding claim 19, Salami discloses a computer program embodied on a non-transitory computer-readable storage medium and configured so as when run on a node of a blockchain network the blockchain performs the steps of: obtaining a first transaction which comprises runnable code (Salami, Para. 0030, first and second transactions 100 and 102 take place in order to set up the initial state. As shown in FIG. 1A, the first transaction 100 deploys computer code 104 to the blockchain that contains the computer instructions needed to settle a forward contract between two market participants but does not yet contain the detailed parameters of the agreement); receiving a second transaction which includes information comprising at least a submitted instance of a first component and a second component of a first cryptographic signature (Salami, Para. 0006, processing a mark to market for a mark to market date with the second market participant computer by receiving a contract value of a mark to market at the second blockchain node with a signature), and further comprising a nonce (Salami, Para. 0068, the node ensures that the nonce included in the transaction is the value that is expected for the sending account); running the code from the first transaction (Salami, Fig. 5B), wherein the code is configured to verify that a hash meets a predetermined condition defined in the code (Salami, Fig. 5B , and Para. 0090, When the other nodes receive the block, they validate the block by checking that the nonce and block hash are correct and then add the block to their own local copy of the blockchain. At that time, the other nodes stop mining their own versions of the block and instead start mining the next block (not shown). Each block has a number, a hash that uniquely identifies the block and a hash that uniquely identifies the parent block),
Salami does not explicitly disclose wherein said predetermined condition is that the hash falls within a set of one or more acceptable output values, and to return a result of true on condition of said verifying that the first hash meets the predetermined condition defined in the code, where is the first hash is a hash of a combination of the nonce and the submitted instance of the first component .
However, Chalkias teaches wherein said predetermined condition is that the hash falls within a set of one or more acceptable output values (Chalkias, Para. 0102, a characteristic may be that the hash is to include a certain pattern such as some number of leading or trailing zeros, a certain pattern of 1s and 0s in the middle of the hash, and so on. Another characteristic may be that the hash has at least a certain number of 1s), and to return a result of true on condition of said verifying that the first hash meets the predetermined condition defined in the code (Chalkias, Para. 0102, a characteristic may be that the hash is to include a certain pattern such as some number of leading or trailing zeros, a certain pattern of 1s and 0s in the middle of the hash, and so on), where is the first hash is a hash of a combination of the nonce and the submitted instance of the first component (Chalkias, Para. 0104, To verify the signature, the verifier would generate a hash of the combination of the content and the nonce of the signature).
Salami and Chalkias are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction.
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of Chalkias to include wherein said predetermined condition is that the hash falls within a set of one or more acceptable output values (Chalkias, Para. 0102), and to return a result of true on condition of said verifying that the first hash meets the predetermined condition defined in the code (Chalkias, Para. 0102), where is the first hash is a hash of a combination of the nonce and the submitted instance of the first component (Chalkias, Para. 0104). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Claims 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Salami et al. (US 2017/0345011 A1), hereinafter Salami in view of Chalkias (US 2019/0319798 A1), hereinafter Chalkias, further in view of the article entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Nakamoto, hereinafter Nakamoto and further in view of Bathen et al. (US 2020/0052880 A1), hereinafter Bathen.
Regarding claim 10, the combination of Salami in view of Chalkias does not explicitly teach the method of claim 1, wherein the submitted instance of the component of the first cryptographic signature were generated by a second party using: an ephemeral key given to the second party by a first party or vice versa, and a first private key which is a private key of the second party; and the nonce was also generated by the second party by performing a proof-of-work on computer equipment of the second party.
However, Nakamoto teaches wherein the submitted instance of the component of the first cryptographic signature were generated by a second party using (Nakamoto, Page. 2, each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin): and a first private key which is a private key of the second party (Nakamoto, Page. 2, Fig. 2); and the nonce was also generated by the second party by performing a proof-of-work on computer equipment of the second party (Nakamoto, Page. 3, each node works on finding a difficult proof-of-work for its block) and (Nakamoto, Page. 3, Proof-of-work is essentially one-CPU-one-vote).
Salami, Chalkias and Nakamoto are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami and Chalkias to incorporate the teachings of Nakamoto to include wherein the submitted instance of the component of the first cryptographic signature were generated by a second party using (Nakamoto, Page. 2): an ephemeral key given to the second party by a first party or vice versa (Nakamoto, Page. 6), and a first private key which is a private key of the second party (Nakamoto, Page. 2, Fig. 2); and the nonce was also generated by the second party by performing a proof-of-work on computer equipment of the second party (Nakamoto, Page. 3). Doing so would aid to solve the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes (Nakamoto, Page. 1).
Salami, Chalkias and Nakamoto do not explicitly teach an ephemeral key given to the second party by a first party or vice versa,
However, Bathen teaches an ephemeral key given to the second party by a first party or vice versa (Bathen, Para. 0030, once the interested parties have exchanged new keys (e.g., ephemeral keys). All messages among themselves will be anonymous within the blockchain 120. ‘A’ will then generate either a group key GSK (private/public key pair) 172, and/or an access token, such as a web token (e.g., symmetric key with expiration date properties among other metadata). This token/key pair is then used to encrypt future messages exchanged among the group. The messages are part of the blockchain transactions. The messages may be exchanged by sending the group key with encrypted (GSK and signature A′SK), B PK 174 for user B and encrypted (GSK and signature A′SK), C′PK 176) and (Bathen, Para. 0027, each member device may have been assigned a unique private/public key pair (e.g., 112, 114, 116 and 118). In order of be able to communicate among themselves, the members need to exchange public keys, so that they may encrypt data that can only be decrypted by the intended party with knowledge of those keys),
Salami, Chalkias, Nakamoto and Bathen are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami, Chalkias and Nakamoto to incorporate the teachings of Bathen to include an ephemeral key given to the second party by a first party or vice versa (Bathen, Para. 0030) and (Bathen, Para. 0027). Doing so would aid to create temporary group keys used to encrypt the communications for a certain period of time. Each blockchain participant will have a unique set of keys. The consensus peers can agree on a group key, which will be used to communicate. This is an adhoc way of establishing a common secret among the participants. The group key is different from the individual private keys assigned to the individual blockchain members (Bathen, Para. 0036).
Regarding claim 11, the combination of Salami, Chalkias and Bathen in view of Nakamoto teaches the method of claim 10, wherein said receiving of the second transaction comprises receiving the second transaction from the second party (Nakamoto, Page. 2, each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami, Chalkias and Bathen to incorporate the teachings of Nakamoto to include wherein said receiving of the second transaction comprises receiving the second transaction from the second party (Nakamoto, Page. 2). Doing so would aid to solve the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes (Nakamoto, Page. 1).
Regarding claim 12, the combination of Chalkias, Bathen and Nakamoto in view of Salami teaches the method of claim 10, comprising triggering a service for the first party on condition that the result returned by said code is true (Salami, Para. 0101, the computed variation margin amount to be transferred between the first and second market participants, causing the available balances of the first and second market participants to be updated… the computer code of the function further causes the contract status to be changed to “settled” and causes the initial margin amounts for the first and second market participants to be debited from the on hold balances of the first and second market participants and the same amounts to be credited to the available balances of the first and second market participants because the current date is the same as the settlement date/fixing date of the contract).
Regarding claim 13, the combination of Salami, Chalkias and Bathen in view of Nakamoto teaches the method of claim 10, wherein the information received in the second transaction comprises a further cryptographic signature of the second party signing a part of the second transaction using a further private key of the second party, the further private key corresponding to a further public key (Nakamoto, Fig. 2, Page. 2, we define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami, Chalkias and Bathen to incorporate the teachings of Nakamoto to include wherein the information received in the second transaction comprises a further cryptographic signature of the second party signing a part of the second transaction using a further private key of the second party, the further private key corresponding to a further public key (Nakamoto, Fig. 2, Page. 2). Doing so would aid to solve the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes (Nakamoto, Page. 1).
Regarding claim 14, the combination of Salami, Nakamoto and Bathen in view of Chalkias teaches the method of claim 10, wherein: the information received in the second transaction comprises an additional cryptographic signature having a different value of the component than the first cryptographic signature but using the same (Chalkias, Para. 0060, the OTS metadata also includes the signature number(smd.k), which is 2 for the second signature, the value of node 104 (smd.root[2]), and the hash of the value of node 103 (smd.h(OTS[1].pub)). The second Few signature is then provided for verification of the second signature), first private key as the first cryptographic signature (Chalkias, Para. 0042, the signer then signs the second hash with the initially created fallback OTS private key of the initially created fallback OTS key pair to generate a fallback OTS signature); and the code is configured to verify the additional cryptographic signature using the first public key (Chalkias, Para. 0086, the regenerate public key component 700 regenerates an OTS public key from an OTS signature and a message. If the regenerated OTS public key matches the published OTS public key (or h(OTS public key) if the hash was published), then the signature is verified), and return the result of true on further condition that the additional cryptographic signature is verified (Chalkias, Para. 0086, if the regenerated OTS public key matches the published OTS public key (or h(OTS public key) if the hash was published), then the signature is verified). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami, Nakamoto and Bathen to incorporate the teachings of Chalkias to include the information received in the second transaction comprises an additional cryptographic signature having a different value of the component than the first cryptographic signature but using the same (Chalkias, Para. 0060), first private key as the first cryptographic signature (Chalkias, Para. 0042); and the code is configured to verify the additional cryptographic signature using the first public key (Chalkias, Para. 0086), and return the result of true on further condition that the additional cryptographic signature is verified (Chalkias, Para. 0086). Doing so would aid the notary to verify the signatures of the parties to each transaction to be notarized. This verification process may be a limiting factor on how many transactions can be notarized by a notary. In some embodiments, a BPQS system includes techniques to reduce the time needed when verifying a signature. With one technique, the BPQS system employs a tradeoff between computational resources required at signature generation time and signature verification time (Chalkias, Para. 0102).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Salami et al. (US 2017/0345011 A1), hereinafter Salami in view of Chalkias (US 2019/0319798 A1), hereinafter Chalkias, and further in view of the article entitled “A Secure Incentive Scheme for Vehicular Delay Tolerant Networks Using Cryptocurrency” by Park, hereinafter Park .
Regarding claim 15, the combination of Salami in view of Chalkias does not explicitly teach the method of claim 1, wherein each of the transactions comprises a data structure comprising one or more inputs and one or more outputs, wherein each output comprises a locking script, and each input comprises an unlocking script and a pointer to an output of another transaction; wherein said code is comprised by the locking script of the first transaction, wherein said information received in the second transaction is comprised by the unlocking script in an input of the second transaction, and wherein the pointer in said input of the second transaction points to said output of the first transaction; and the method comprises validating the transaction at least on condition that the code returns said result of true, and in response to said validation, at least one of: including the second transaction in a pool of transactions for mining into one or more blocks by said verifying node, and/or forwarding the second transaction to at least one other of nodes of the blockchain network.
However, Park teaches wherein each of the transactions comprises a data structure comprising one or more inputs and one or more outputs (Park, Sec 2.2, Page 4, and Fig. 2, a transaction (TX) has a unique identifier and consists of a set of inputs and outputs which are key components of the transaction), wherein each output comprises a locking script (Park, Sec 2.2, Page 4, each transaction output can contain a locking script which defines the conditions that must be met to spend the coins associated with the UTXO), and each input comprises an unlocking script and a pointer to an output of another transaction (Park, Sec 2.3, Page 4, to authorize spending the output, the corresponding input specifies an unlocking script of the form: scriptSig:<Signature><PubKey>); wherein said code is comprised by the locking script of the first transaction (Park, section 3.4, and Fig. 6, for guaranteeing the fairness to the source server 𝑅𝑆𝑠 in our incentive scheme, we make use of Multi Sig script and time-lock script in the Bitcoin transactions. Hence, when the source server 𝑅𝑆𝑠 publishes the transaction 𝑇𝑋1, 𝑅𝑆𝑠 can specify the proper recipient for 𝑇𝑋1.𝑜𝑢𝑡 (i.e., V𝑖 for incentive or 𝑅𝑆𝑠 for withdraw) by using multisig and time-lock script as shown in Algorithm 1), wherein said information received in the second transaction is comprised by the unlocking script in an input of the second transaction (Park, Page 8, Hence, if V𝑖 correctly delivers the message requested by 𝑅𝑆𝑠 to the destination point 𝑅𝑆𝑑 and receives a partial signature for 𝑇𝑋2 from 𝑅𝑆𝑑, V𝑖 can spend the coins of 𝑇𝑋1 by completing the unlocking script of 𝑇𝑋2.𝑖𝑛 as shown in Algorithm 2), and wherein the pointer in said input of the second transaction points to said output of the first transaction (Park, Page 7, Fig. 5, V𝑖 checks the validity of 𝑇𝑋1 through the Bitcoin network atransaction𝑇𝑋2 to redeem the coins specified in 𝑇𝑋1.𝑜𝑢𝑡 while moving to the destination); and the method comprises validating the transaction at least on condition that the code returns said result of true (Park, Fig. 7 and Page 9, By combining those scripts of 𝑇𝑋2.𝑖𝑛 and 𝑇𝑋1.𝑜𝑢𝑡, the execution path of the first IF clause is selected by putting TRUE, then it would be evaluated in the script execution stack as the following form), and in response to said validation, at least one of: including the second transaction in a pool of transactions for mining into one or more blocks by said verifying node (Park, Page 4, after validating the transactions pended for a given time period, miners collect the transactions into a single unit called block), and/or forwarding the second transaction to at least one other of nodes of the blockchain network (Park, Page 8, If it holds, V𝑖 completes 2-of-2 MultiSig unlocking script by adding V𝑖 signature for 𝑇𝑋2 and finally publish 𝑇𝑋2 to the Bitcoin network). Salami, Chalkias and Park are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami and Chalkias to incorporate the teachings of Park to include wherein each of the transactions comprises a data structure comprising one or more inputs and one or more outputs (Park, Sec 2.2, Page 4, and Fig. 2), wherein each output comprises a locking script (Park, Sec 2.2, Page 4), and each input comprises an unlocking script and a pointer to an output of another transaction (Park, Sec 2.3, Page 4); wherein said code is comprised by the locking script of the first transaction (Park, section 3.4, and Fig. 6), wherein said information received in the second transaction is comprised by the unlocking script in an input of the second transaction (Park, Page 8), and wherein the pointer in said input of the second transaction points to said output of the first transaction (Park, Page 7, Fig. 5); and the method comprises validating the transaction at least on condition that the code returns said result of true (Park, Fig. 7 and Page 9), and in response to said validation, at least one of: including the second transaction in a pool of transactions for mining into one or more blocks by said verifying node (Park, Page 4), and/or forwarding the second transaction to at least one other of nodes of the blockchain network (Park, Page 8). Doing so would aid to Validate a Bitcoin transaction relying on two types of scripts, a locking script and an unlocking script. For guaranteeing the fairness to the source server 𝑅𝑆𝑠 in the incentive scheme, to make use of MultiSig script and time-lock script in the Bitcoin transactions (Park, Page 8).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Salami et al. (US 2017/0345011 A1), hereinafter Salami in view of Chalkias (US 2019/0319798 A1), hereinafter Chalkias, and further in view of SUSELLA et al. (US 2018 / 0026798 A1), hereinafter SUSELLA.
Regarding claim 18, the combination of Salami in view of Chalkias does not explicitly teach the method of claim 17, wherein the ECDSA signature comprises an r-part and an s-part, and said component comprises the r-part but not the s-part.
However, SUSELLA teaches the method of claim 17, wherein the ECDSA signature comprises an r-part and an s-part, and said component comprises the r-part but not the s-part (SUSELLA, Para. 0063, EdDSA procedure computing the signature component s includes instead computing a function which includes the sum of the modified nonce rc of a hash value H(M,R) calculated by applying the hash function H to said message M and at least to said point R).
Salami, Chalkias and SUSELLA are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami and Chalkias to incorporate the teachings of SUSELLA to include wherein the ECDSA signature comprises an r-part and an s-part, and said component comprises the r-part but not the s-part (SUSELLA, Para. 0063). Doing so would aid to facilitate the prevention of successful HNP attacks. If some bits of the nonce are recovered from the operation of scalar product of the nonce with the second curve point C, r×C, the HNP attack cannot be performed based on this information. Then side channel attacks against r×C are harder than against the product r×B because the point B is known while the second curve point C is secret (SUSELLA, Para. 0068).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Salami et al. (US 2017/0345011 A1), hereinafter Salami in view of SUSELLA et al. (US 2018 / 0026798 A1), hereinafter SUSELLA.
Regarding claim 20, Salami discloses a node of a blockchain network, comprising: memory comprising one or more memory units (Salami, Para. 0030), and processing apparatus comprising one or more processing units (Salami, Para. 0108); wherein the memory stores code arranged to run on the processing apparatus (Salami, Para. 0031, The byte-code comprises instructions for a virtual machine. Respective copies of the virtual machine runs on the first, second, third and fourth blockchain nodes. The computer program is written in a Turing-complete computer programming language and is compiled to byte-code on the service provider computer), wherein the code is configured so as when run on the processing apparatus the processing apparatus performs the steps of: obtaining a first transaction which comprises runnable code (Salami, Para. 0030, first and second transactions 100 and 102 take place in order to set up the initial state. As shown in FIG. 1A, the first transaction 100 deploys computer code 104 to the blockchain that contains the computer instructions needed to settle a forward contract between two market participants but does not yet contain the detailed parameters of the agreement); receiving a second transaction which includes information comprising at least a submitted instance of an r-part and an s-part of a first Elliptic Curve Digital Signature Algorithm (ECDSA) signature(Salami, Para. 0042, the first, second and third blockchain nodes validate the transaction by applying the recovery function of ECDSA to the transaction signature and to the message (a byte-array representation of the complete transaction). The transaction signature includes the recovery bit v which together with the message and r and s components of the signature allow for the public key to be extracted), and further comprising a nonce (Salami, Para. 0068, the node ensures that the nonce included in the transaction is the value that is expected for the sending account); running the code from the first transaction (Salami, Fig. 5B), and return a result of true on condition of said verifying that the hash meets the predetermined condition defined in the code (Salami, Fig. 5B , and Para. 0090, When the other nodes receive the block, they validate the block by checking that the nonce and block hash are correct and then add the block to their own local copy of the blockchain. At that time, the other nodes stop mining their own versions of the block and instead start mining the next block (not shown). Each block has a number, a hash that uniquely identifies the block and a hash that uniquely identifies the parent block).
Salami does not explicitly disclose wherein the code is configured to: apply a hash function to a combination of the nonce and the submitted instance of the r-part, thereby resulting in a hash value, verify that the hash value meets a predetermined condition defined in the code wherein said predetermined condition is that the hash value is a member of a set of one or more acceptable output values,
However, SUSELLA teaches wherein the code is configured to: apply a hash function to a combination of the nonce and the submitted instance of the r-part, thereby resulting in a hash value (SUSELLA, Para. 0019, at 123 it is computed a signature component s=r+H(M, R)a mod l, where H is a hash function, M is the message to be signed, a is the private key, l is the order of the base point B. A hash value H(M,R) is calculated by applying the hash function H to said message M concatenated with the point R), verify that the hash value meets a predetermined condition defined in the code wherein said predetermined condition is that the hash value is a member of a set of one or more acceptable output values (SUSELLA, Para. 0038, calculating a signature component as a function of at least said integer secret nonce, of said point and of a hash value calculated by applying a hash function at least to said message, outputting a signature comprising said signature component),
Salami and SUSELLA are considered to be analogous to the claim invention because they are in the same field of signature verification function for verifying a blockchain transaction. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Salami to incorporate the teachings of SUSELLA to include wherein the ECDSA signature comprises an r-part and an s-part, and said component comprises the r-part but not the s-part (SUSELLA, Para. 0063). Doing so would aid to facilitate the prevention of successful HNP attacks. If some bits of the nonce are recovered from the operation of scalar product of the nonce with the second curve point C, r×C, the HNP attack cannot be performed based on this information. Then side channel attacks against r×C are harder than against the product r×B because the point B is known while the second curve point C is secret (SUSELLA, Para. 0068).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fiske (US 11,824,991 B1) teaches methods and systems are provided for performing a secure transaction. In an embodiment, users register biometric and/or other identifying user information. A private encryption key is generated from the biometric information and/or other user information and/or information obtained from a unpredictable physical process and are stored in a secure area of a device and a public key is transmitted to the blockchain network which acts as a service provider. In some embodiments, the execution and integrity of transactions by using transaction signatures, based on visual images is disclosed. In an embodiment, a blockchain network verifies and executes the transaction.
Savanah et al. (US 2019/0149337 A1) teaches an invention implemented on the Bitcoin platform or an alternative blockchain platform . The transaction includes a locking script which comprises instructions selected so as to implement the functionality of an logic gate such as the XOR gate . When the script is executed ( because a second transaction is attempting to spend the output associated with the locking script ) the inputs will be processed by the conditional instructions to provide an output of TRUE or FALSE . The second trans action is transmitted to the blockchain network for validation and , if determined to be valid , it will be written to the blockchain . Validation of the second transaction can be interpreted as a TRUE output . Thus , the locking script of the first transaction provides the functionality of the desired logic gate . The invention provides numerous advantages and can be used in a wide variety of applications , such as for the implementation.
Tran et al. (US 2017/0232300 A1) teaches an Internet of Thing ( IoT ) device includes a camera coupled to a processor ; and a wireless transceiver coupled to the processor . Blockchain smart contracts can be used with the device to facilitate secure operation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge L. Ortiz-Criado can be reached at (571)272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GITA FARAMARZI/Examiner, Art Unit 2496
Prosecution Insights