Detailed Action
This is a Non-final Office action in response to communications received on 10/6/2023. Claims 3, 6, 8-9, 12, 14, 17, 20 and 22-25 were amended via preliminary amendment. Claims 11, 15-16, 19 and 21 were canceled via preliminary amendment. Claims 1-10, 12-14, 17-18, 20 and 22-25 are pending and are examined.
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 .
Drawings
The drawings, filed 10/6/2023, are acknowledged.
Foreign Priority
The foreign priority date of 4/7/2021 is acknowledged.
Preliminary Amendment
The preliminary amendments, filed 10/6/2023, are acknowledged.
Claim Objections
Claims 18 and 25 are objected to because of the following informalities:
Regarding claim 18, the claim appears to contain two separate periods. The claim should more appropriately be one sentence and terminate with a single period.
Regarding claim 25, the claim recites “the one or more processor perform”, which is grammatically incorrect.
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.
Claim 2 is 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.
Regarding claim 2, the claim recites “wherein the first locking script”, however, there is insufficient antecedent basis for a first locking script.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 14, 17-18, 20, 22 and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Hoshizuki (US 20210201409 A1), in view of Carter (NPL “Universal Classes of Hash Functions”).
Regarding claim 1, Hoshizuki teaches the limitations of claim 1 substantially as follows:
A computer-implemented method of implementing a hash function, HF, using blockchain transactions, wherein the method is performed by a first party and comprises: generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network, (Hoshizuki; Para(s). [0032]: processing using a blockchain as a distributed ledger and processing using a DAG as a distributed ledger can be performed using transactions (i.e., generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network))
wherein the first blockchain transaction comprises a locking script configured to, when executed together with an unlocking script of a second blockchain transaction comprising a target data item, generate a hash result of the target data item, (Hoshizuki; Para(s). [0060] & [0066]: In the case of using P2PK (Pay to Public Key) as a transaction script, ScriptPubKey locking a UTXO includes a public key of a user as a transmission destination being a recipient of the UTXO (i.e., locking script). ScriptSig is a script for unlocking a UTXO owned by the user being the transmission source (i.e., unlocking script))
wherein the locking script comprises a HF script configured to generate the hash result by performing at least the steps of: (Hoshizuki; Para(s). [0093]: In Bitcoins and the blockchain system derived therefrom, the Atomic Swap uses a programming language called Script that describes unlock conditions of an UTXO. The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set (i.e., the locking script comprises a HF script configured to generate the hash result ))
Hoshizuki does not teach the limitations of claim 1 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter.
However, in the same field of endeavor, Carter discloses the limitations of claim 1 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
Carter is combinable with Hoshizuki because all are from the same field of endeavor of hash functions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Hoshizuki to incorporate the universal hash function as in Carter in order to improve uniformity and collision resistance.
Regarding claim 2, Hoshizuki and Carter teach the limitations of claim 1.
Hoshizuki and Carter teach the limitations of claim 2 as follows:
The method of claim 1, wherein the first locking script is configured to output at least the hash result. (Hoshizuki; Para(s). [0093]: In Bitcoins and the blockchain system derived therefrom, the Atomic Swap uses a programming language called Script that describes unlock conditions of an UTXO. The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set (i.e., the first locking script is configured to output at least the hash result))
Regarding claim 3, Hoshizuki and Carter teach the limitations of claim 1.
Hoshizuki and Carter teach the limitations of claim 3 as follows:
The method of claim 1, wherein the locking script comprises an expected hash result, and wherein the locking script is configured to require the target hash result to match the expected hash result in order to be unlocked by the unlocking script. (Hoshizuki; Para(s). [0128]-[0132]: P2PKH method uses OP_EQUALVERIFY to require equality before signature verification (i.e., expected hash result, and wherein the locking script is configured to require the target hash result to match the expected hash result in order to be unlocked by the unlocking script))
Regarding claim 4, Hoshizuki and Carter teach the limitations of claim 3.
Hoshizuki and Carter teach the limitations of claim 4 as follows:
The method of claim 3, wherein the expected hash result is generated by applying the hash function to an expected public key. (Hoshizuki; Para(s). [0125]: obtains a hash value by applying the hash function to the public key of the user B included in ScriptSig of the transaction (i.e., applying the hash function to an expected public key))
Regarding claim 5, Hoshizuki and Carter teach the limitations of claim 4.
Hoshizuki and Carter teach the limitations of claim 5 as follows:
The method of claim 4, wherein the locking script is configured to require the target data item to be the expected public key, and to comprise a signature generated using a private key corresponding to the expected public key. (Hoshizuki; Para(s). [0128]-[0132]: P2PKH method uses OP_EQUALVERIFY to require equality before signature verification, performed in OP_CHECKSIG (i.e., require the target data item to be the expected public key, and to comprise a signature generated using a private key corresponding to the expected public key))
Regarding claim 14, Hoshizuki and Carter teach the limitations of claim 1.
Hoshizuki and Carter teach the limitations of claim 14 as follows:
The method of claim 1,wherein the first parameter is any non-zero number, the second parameter is any number, the third parameter is a positive number, and the fourth parameter is 2^L, wherein L is chosen to define a length of the hash result. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
The same motivation to combine as in claim 1 is applicable to the instant claim.
Regarding claim 17, Hoshizuki and Carter teach the limitations of claim 1.
Hoshizuki and Carter teach the limitations of claim 17 as follows:
The method of claim 1,wherein the hash function is defined as HashUHFP)[aiP+bi mod p] mod n, where al is the first parameter, bi is the second parameter, p is the third parameter, and n is the fourth parameter, and wherein the method comprises: (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
generating a plurality of different respective expected hash results for an expected public key P by applying the hash function HashUHF (P) to the expected public key P for different respective values of one, some or all of: the first parameter, the second parameter, the third parameter, the fourth parameter. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k) These parameters have defined ranges and is clear that each parameter can be freely selected within its respective domain, making it universal (i.e. good collision properties))
The same motivation to combine as in claim 1 is applicable to the instant claim.
Regarding claim 18, Hoshizuki and Carter teach the limitations of claim 17.
Hoshizuki and Carter teach the limitations of claim 18 as follows:
The method of claim 17, wherein the first blockchain transaction comprises a plurality of respective outputs, each respective output comprising a respective locking script configured to, when executed together with a respective unlocking script of a different respective blockchain transaction comprising a respective target public key, generate a respective hash result of the respective target public key, (Hoshizuki; Para(s). [0060] & [0066]: In the case of using P2PK (Pay to Public Key) as a transaction script, ScriptPubKey locking a UTXO includes a public key of a user as a transmission destination being a recipient of the UTXO (i.e., locking script). ScriptSig is a script for unlocking a UTXO owned by the user being the transmission source (i.e., unlocking script))
wherein the respective locking script comprises a respective HF script configured to generate the respective hash result by performing at least the steps of: (Hoshizuki; Para(s). [0093]: In Bitcoins and the blockchain system derived therefrom, the Atomic Swap uses a programming language called Script that describes unlock conditions of an UTXO. The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set (i.e., the locking script comprises a HF script configured to generate the hash result ))
generating a respective first intermediate result based on a multiplication of the target data item by a respective first parameter, generating a respective second intermediate result based on an addition of a respective second parameter to the respective first intermediate result, generating a respective third intermediate result based on a modulo of the respective second intermediate result by a respective third parameter; and generating the respective hash result based on a modulo of the respective third intermediate result by a respective fourth parameter. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
wherein each respective locking script comprises a respective one of the plurality of expected hash results, and wherein the respective locking script is configured to a) require the respective target hash result to match the respective expected hash result, and (Hoshizuki; Para(s). [0128]-[0132]: P2PKH method uses OP_EQUALVERIFY to require equality before signature verification (i.e., expected hash result, and wherein the locking script is configured to require the target hash result to match the expected hash result in order to be unlocked by the unlocking script))
b) require the respective unlocking script to comprise a respective signature generated using the expected public key in order to be unlocked by the unlocking script. (Hoshizuki; Para(s). [0128]-[0132]: P2PKH method uses OP_EQUALVERIFY to require equality before signature verification, performed in OP_CHECKSIG (i.e., require the respective unlocking script to comprise a respective signature generated using the expected public key in order to be unlocked by the unlocking script))
The same motivation to combine as in claim 1 is applicable to the instant claim.
Regarding claim 20, Hoshizuki and Carter teach the limitations of claim 17.
Hoshizuki and Carter teach the limitations of claim 20 as follows:
The method of claim 17, wherein said generating of the plurality of different respective expected hash results for the expected public key P comprises i) generating a respective intermediate hash result by applying the hash function HashUHF (P) to the expected public key P for different respective values of one, some or all of: the first parameter, the second parameter, the third parameter, the fourth parameter; and ii) hashing the respective intermediate hash result with a cryptographic hash function. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k) These parameters have defined ranges and is clear that each parameter can be freely selected within its respective domain, making it universal (i.e. good collision properties))
The same motivation to combine as in claim 1 is applicable to the instant claim.
Regarding claim 22, Hoshizuki and Carter teach the limitations of claim 20.
Hoshizuki and Carter teach the limitations of claim 22 as follows:
The method of claim 20, wherein the cryptographic hash function is one of: RIPEMD160, SHA256, or a combination of RIPEMD160 and SHA256. (Hoshizuki; Para(s). [0093]: The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set)
Regarding claim 24, Hoshizuki teaches the limitations of claim 24 substantially as follows:
Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when run on the processing apparatus, (Hoshizuki; Para(s). [0015]: a first trading apparatus and a second trading apparatus. The first trading apparatus includes a first processor which executes a process described)
the processing apparatus performs a method of implementing a hash function, HF, using blockchain transactions, wherein the method comprises: generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network, (Hoshizuki; Para(s). [0032]: processing using a blockchain as a distributed ledger and processing using a DAG as a distributed ledger can be performed using transactions (i.e., generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network))
wherein the first blockchain transaction comprises a locking script configured to, when executed together with an unlocking script of a second blockchain transaction comprising a target data item, generate a hash result of the target data item, (Hoshizuki; Para(s). [0060] & [0066]: In the case of using P2PK (Pay to Public Key) as a transaction script, ScriptPubKey locking a UTXO includes a public key of a user as a transmission destination being a recipient of the UTXO (i.e., locking script). ScriptSig is a script for unlocking a UTXO owned by the user being the transmission source (i.e., unlocking script))
wherein the locking script comprises a HF script configured to generate the hash result by performing at least the steps of: (Hoshizuki; Para(s). [0093]: In Bitcoins and the blockchain system derived therefrom, the Atomic Swap uses a programming language called Script that describes unlock conditions of an UTXO. The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set (i.e., the locking script comprises a HF script configured to generate the hash result ))
Hoshizuki does not teach the limitations of claim 24 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter.
However, in the same field of endeavor, Carter discloses the limitations of claim 24 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
Carter is combinable with Hoshizuki because all are from the same field of endeavor of hash functions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Hoshizuki to incorporate the universal hash function as in Carter in order to improve uniformity and collision resistance.
Regarding claim 25, Hoshizuki teaches the limitations of claim 25 substantially as follows:
A computer program embodied on non-transitory computer- readable storage media and configured so as, when run on one or more processors, (Hoshizuki; Para(s). [0015]: a first trading apparatus and a second trading apparatus. The first trading apparatus includes a first processor which executes a process described)
the one or more processor perform a method of implementing a hash function, HF, using blockchain transactions, wherein the method comprises: generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network, (Hoshizuki; Para(s). [0032]: processing using a blockchain as a distributed ledger and processing using a DAG as a distributed ledger can be performed using transactions (i.e., generating a first blockchain transaction; and submitting the first blockchain transaction to one or more nodes of a blockchain network))
wherein the first blockchain transaction comprises a locking script configured to, when executed together with an unlocking script of a second blockchain transaction comprising a target data item, generate a hash result of the target data item, (Hoshizuki; Para(s). [0060] & [0066]: In the case of using P2PK (Pay to Public Key) as a transaction script, ScriptPubKey locking a UTXO includes a public key of a user as a transmission destination being a recipient of the UTXO (i.e., locking script). ScriptSig is a script for unlocking a UTXO owned by the user being the transmission source (i.e., unlocking script))
wherein the locking script comprises a HF script configured to generate the hash result by performing at least the steps of: (Hoshizuki; Para(s). [0093]: In Bitcoins and the blockchain system derived therefrom, the Atomic Swap uses a programming language called Script that describes unlock conditions of an UTXO. The Atomic Swap uses a fact that a command for obtaining SHA256 being a one-way hash function and a command for performing a value comparison are included in a Script command set (i.e., the locking script comprises a HF script configured to generate the hash result ))
Hoshizuki does not teach the limitations of claim 25 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter.
However, in the same field of endeavor, Carter discloses the limitations of claim 25 as follows:
generating a first intermediate result based on a multiplication of the target data item by a first parameter, generating a second intermediate result based on an addition of a second parameter to the first intermediate result, generating a third intermediate result based on a modulo of the second intermediate result by a third parameter; and generating the hash result based on a modulo of the third intermediate result by a fourth parameter. (Carter; Page 149: (mx + n) mod p but taking modulo b when b=2^k for some k, this amounts to taking the last k bits (i.e., mod 2^k))
Carter is combinable with Hoshizuki because all are from the same field of endeavor of hash functions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Hoshizuki to incorporate the universal hash function as in Carter in order to improve uniformity and collision resistance.
Claims 6-8 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Hoshizuki (US 20210201409 A1), in view of Carter (NPL), as applied to independent claims, further in view of Cohen (US 20200136971 A1).
Regarding claim 6, Hoshizuki and Carter teach the limitations of claim 4.
Hoshizuki and Carter do not teach the limitations of claim 6 as follows:
The method of claim 4, comprising: storing the expected hash result, or a shortened version thereof, in a look-up table mapped to at least one of: the expected public key, data associated with the first blockchain transaction, and/or data associated with a spending transaction that spends an output of the first blockchain transaction.
However, in the same field of endeavor, Cohen discloses the limitations of claim 6 as follows:
The method of claim 4, comprising: storing the expected hash result, or a shortened version thereof, in a look-up table mapped to at least one of: the expected public key, data associated with the first blockchain transaction, and/or data associated with a spending transaction that spends an output of the first blockchain transaction. (Cohen; Para(s). [0017]: A key h (e.g., 384 bits) is processed using a hash function to generate a hash index (e.g., 20 bits). The hash index is used to look-up a value in a hash memory, a so called key/value pair.)
Cohen is combinable with Hoshizuki and Carter because all are from the same field of endeavor of hash functions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Hoshizuki and Carter to incorporate hash indices as in Cohen in order to improve the functionality of the system by providing a means by which a hash look -up table may be implemented for look-ups.
Regarding claim 7, Hoshizuki and Carter teach the limitations of claim 6.
Hoshizuki and Carter do not teach the limitations of claim 7 as follows:
The method of claim 6, wherein: the data associated with the first blockchain transaction comprises a transaction identifier of the first blockchain transaction and/or the first blockchain transaction itself; and/or the data associated with the spending transaction comprises a transaction identifier of the spending transaction and/or the spending transaction itself. (Cohen; Para(s). [0017] & [0064]: A key h (e.g., 384 bits) is processed using a hash function to generate a hash index (e.g., 20 bits). The hash index is used to look-up a value in a hash memory, a so called key/value pair. the entry includes a pointer to memory or storage from which to retrieve a key-value corresponding to the calculated index)
The same motivation to combine as in claim 6 is applicable to the instant claim.
Regarding claim 8, Hoshizuki and Carter teach the limitations of claim 6.
Hoshizuki and Carter do not teach the limitations of claim 8 as follows:
The method of claim 6, wherein the look-up table comprises a plurality of different hash results or shortened versions thereof, each generated by applying the hash function to a different public key, and wherein each different hash result is mapped to at least one of: the different public key, data associated with a respective blockchain transaction comprising the different hash result, and/or data associated with a respective spending transaction that spends an output of the respective blockchain transaction. (Cohen; Para(s). [0017] & [0064]: A key h (e.g., 384 bits) is processed using a hash function to generate a hash index (e.g., 20 bits). The hash index is used to look-up a value in a hash memory, a so called key/value pair. the entry includes a pointer to memory or storage from which to retrieve a key-value corresponding to the calculated index)
The same motivation to combine as in claim 6 is applicable to the instant claim.
Regarding claim 23, Hoshizuki and Carter teach the limitations of claim 17.
Hoshizuki and Carter do not teach the limitations of claim 23 as follows:
The method of claim 17, comprising: storing the plurality of expected hash results, or a respective shortened version thereof, in a look-up table mapped to at least one of: the expected public key or an index thereof.
However, in the same field of endeavor, Cohen discloses the limitations of claim 23 as follows:
The method of claim 17, comprising: storing the plurality of expected hash results, or a respective shortened version thereof, in a look-up table mapped to at least one of: the expected public key or an index thereof. (Cohen; Para(s). [0017]: A key h (e.g., 384 bits) is processed using a hash function to generate a hash index (e.g., 20 bits). The hash index is used to look-up a value in a hash memory, a so called key/value pair. However, hashing of the lookup key can create collisions between different keys such that multiple different keys map to the same index and entry in a look-up table)
Cohen is combinable with Hoshizuki and Carter because all are from the same field of endeavor of hash functions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Hoshizuki and Carter to incorporate hash indices as in Cohen in order to improve the functionality of the system by providing a means by which a hash look -up table may be implemented for look-ups.
Allowable Subject Matter
Claims 9-10 and 12-13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
As to claim 9, it contains allowable subject matter when the claim is taken as a whole. See the italicized text indicating aspects that in combination with the remainder of the claim differentiate it from prior art.
The method of claim 1, wherein the locking script comprises a public key derivation, PKD, script configured to generate a child public key of a parent public key, wherein the PKD script comprises the HF script, and wherein the unlocking script comprises the parent public key, and wherein the target data item comprises at least a chain code of a parent public key and the parent public key, and wherein the PKD script is configured to generate the child public key based on the parent public key and the hash result.
Furthermore, claims 10 and 12-13 contain allowable subject matter based on the virtue of dependency from claim 9.
Prior Art Considered But Not Relied Upon
Haleem (US 20190208422 A1) which teaches systems and methods for facilitating data transmission using a decentralized consensus network. The system comprising: a verified and decentralized consensus network comprising a plurality of node, wherein at least one of the nodes is configured to: (a) determine a target node from the plurality of nodes to be verified; verify the target node by validating a geographic location of the target node or a time of the target node; and (c) receive a token for verifying and validating the target node.
Hoptroff (US 20210399820 A1) which teaches systems and methods for proving an event. The system comprises a network of one or more beacon nodes and each beacon node is configured to: receive a request over the network for proving a time and location for an event, and the request comprises event data generated by a requesting entity.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BLAKE ISAAC NARRAMORE whose telephone number is (303)297-4357. The examiner can normally be reached on Monday - Friday 0700-1700 MT.
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, Taghi T Arani can be reached on (571) 272-3787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BLAKE I NARRAMORE/Examiner, Art Unit 2438