Patent Application 16097546 - IMPLEMENTING LOGIC GATE FUNCTIONALITY USING A

Title: IMPLEMENTING LOGIC GATE FUNCTIONALITY USING A BLOCKCHAIN
Application Information

Invention Title: IMPLEMENTING LOGIC GATE FUNCTIONALITY USING A BLOCKCHAIN
Application Number: 16097546
Submission Date: 2025-05-14T00:00:00.000Z
Effective Filing Date: 2018-10-29T00:00:00.000Z
Filing Date: 2018-10-29T00:00:00.000Z
National Class: 713
National Sub-Class: 168000
Examiner Employee Number: 90576
Art Unit: 2496
Tech Center: 2400
Rejection Summary

102 Rejections: 0
103 Rejections: 1
Cited Patents

The following patents were cited in the rejection:
Office Action Text



    
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 . In communications filed on 01/29/ 2025. Claims 1-3, 10, 12-15, and 18 are amended. Claims 6, 8-9, 11, and 24-27 are cancelled. Claims 1-5, 7, 10, and 12-23 are pending in this examination.
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.

Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered. 

Double Patenting
With regard to the rejection of Claims 1-5, and 7, 10, and 12-23 on the basis of non-statutory Double Patenting over claims 1 - 16 of patent application 16, 097, 516 and claims 1 - 19 of patent 16, 097, 218, Examiner will maintain the Double Patenting rejection is held in obeyance.

Claim Rejections - 35 USC § 112   

The following is a quotation of 35 U.S.C. 112(b):
(b)  CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.


The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.


Claims 1– 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA  the applicant regards as the invention.
The claims 1, and 18 recite “determining a first rule defining how the first input evaluates to a first value and a second rule defining how a second input evaluates to a second value, the first value and the second value each being TRUE or FALSE”, which renders the claim indefinite. The term is not definite by the claim, as if the first input correspond to the result of first locking script and the second input corresponds to the second unlocking script, or these two inputs, inputted at the first transaction at the unlocking script?  and it is explained in the specification of  how the first rule and second rule make the determination at the first locking script if the first value and second value is TRUE or FALSE? Is there any determination algorithm or threshold?
Claims 2-5, 7, 10, and 12-17, and 19-23 do not cure the deficiency of claims 1, and 18 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claims 1, and 18.

Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a)  IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.

The following is a quotation of the first paragraph of pre-AIA  35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.


Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. 
 The independent claims 1, and 18 contain ““determining a first rule defining how the first input evaluates to a first value and a second rule defining how a second input evaluates to a second value, the first value and the second value each being TRUE or FALSE” which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA  the inventor(s), at the time the application was filed, had possession of the claimed invention. 
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims.  See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 2-5, 7, 10, and 12-17, and 19-23 do not cure the deficiency of claims 1, and 18 and are rejected under 35 USC 112(a), for their dependency upon claims 1, and 18.

Response to Arguments


Applicant's arguments filed 01/29/2025 have been fully considered but they are not persuasive:

Applicant contends on pages 8-9 of remarks filed on 01/29/2025 that Claim 1 has been amended to recite that executing the first locking script includes determining a first rule defining how the first input evaluates to a first value and a second rule defining how a second input evaluates to a second value, the first value and the second value each being TRUE or FALSE, and determining, based on the first value and the second value, an output by emulating the functionality of a logic gate using the first value and the second value as inputs to the logic gate, the output corresponding to a TRUE result or a FALSE result. Applicant respectfully submits hat Antonopoulos fails to teach amended claim 1 to one or ordinary skill in the art.


Examiner respectfully disagree with applicant argument on pages 8-9 of remarks filed on 01/29/2025 for claims 1.

Mastering discloses: executing the first locking script includes determining a first rule defining how the first input evaluates to a first value and a second rule defining how a second input evaluates to a second value, the first value and the second value each being TRUE or FALSE, and determining, based on the first value and the second value, an output [ see FIG. 2-6, Aggregating transaction and corresponding text for more detail], and  [ (Page 38, Section "Bitcoin Transactions": "In bitcoin terms, "spending" is signing a transaction that transfers value from a previous transaction over to a new owner identified by a bitcoin address. Transactions move value from transaction inputs to transaction outputs. An input is where the coin value is coming from, usually a previous transaction's output. A transaction output assigns a new owner to the value by associating it with a key. The destination key is called an encumbrance. It imposes a requirement for a signature for the funds to be redeemed in future transactions. Outputs from one transaction can be used as inputs in a new transaction], and [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock)], and [ Page 124, third paragraph, In the current implementation the scripts are executed separately with the stack transferred between the two executions, as described below. First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed without errors (e.g., it has no “dangling” operator’s leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO. If any result other than “TRUE” remains after execution of the combined script, the input is invalid as it has failed to satisfy the spending conditions placed on the UTXO. Note that the UTXO is permanently recorded in the blockchain, and therefore is invariable and is unaffected by failed attempts to spend it by reference in a new transaction. Only a valid transaction that correctly satisfies the conditions of the UTXO results in the UTXO being marked as “spent” and removed from the set of available (unspent) UTXO], and [Page 125, 4th paragraph, Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL (Boolean operator) pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal (equated to invalid transaction). Bitcoin transaction scripts usually contain a conditional operator, so that they can produce the result TRUE that signifies a valid transaction], and [see FIG.5-2 and corresponding text pages 125-126, , The scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. Operators push or pop one or
more parameters from the stack, act on them, and may push a result onto the stack. For
example, OP_ADD will pop two items from the stack, add them and push the resulting
sum onto the stack. Conditional operators evaluate a condition producing a boolean result of TRUE or FALSE. For example, OP_EQUAL pops two items from the stack and pushes TRUE
(TRUE is represented by the number 1) if they are equal or FALSE (represented by zero)
if they are not equal. Bitcoin transaction scripts usually contain a conditional operator,
so that they can produce the result TRUE that signifies a valid transaction], and [ Page 127, Third paragraph, while most locking scripts refer to a bitcoin address or public key, thereby requiring proof of ownership to spend the funds, the script does not have to be that complex. Any combination of locking and unlocking scripts that results in a TRUE value is valid. The simple arithmetic we used as an example of the scripting language above is also a valid locking script that can be used to lock a transaction output…As we saw in the step-by-step example above, when this script is executed, the result is OP_TRUE, making the transaction valid. Not only is this a valid transaction output locking script, but the resulting UTXO could be spent by anyone with the arithmetic skills to know that the number 2 satisfies the scrip], and [ see Appendix, table C-1: OP_0 or OP_FALSE: an empty array is pushed on to the stack].
Examiner comment: Drego also in various paragraphs of his application indicates that the operations of verifying and recording transactions of cryptocurrencies such as transactions in the bitcoin cryptocurrency are sometimes referred to as mining (mining circuitry used to mine digital currency, e.g., Bitcoin, by implementing different type of logic gates), because completion of each mining operation typically rewards the miner with newly created cryptocurrency (e.g., bitcoins). Verified transactions (implementing locking and unlocking scripts) and newly created bitcoins are recorded in the public ledger. The public ledger serves as an official history of transactions. As indicates in the links below from Internet (in conclusion section), that bitcoin transaction uses the locking and unlocking scripts. 

Drego discloses emulating the functionality of a logic gate using the first value and the second value as inputs to the logic gate [Claim 16. An electronic device that forms a node in a peer-to-peer network of nodes that support transactions in a digital currency, the electronic device comprising: hashing circuitry configured to generate a hash output by performing a plurality of sequential rounds of a Secure Hash Algorithm 256 (SHA-256) cryptographic hashing algorithm based at least on an initial hash value and a plurality of message words; and a comparison circuit that directly receives the hash output from the hashing circuitry, wherein the comparison circuit includes a plurality of logic gates that is used to compare a portion of the hash output to a predetermined value], and  [Abstract, Cryptographic hashing circuitry such as mining circuitry used to mine digital currency may be formed on an integrated circuit. The hashing circuitry may include sequential rounds of register and logic circuitry that perform operations of a cryptographic protocol. A final hash output from the hashing circuitry may be checked using a difficulty comparison circuit to determine whether the hash output satisfies predetermined difficulty criteria. The difficulty comparison circuit may be configured as a hardwired comparison circuit having logic gates for checking only a subset of bits in the hash output]], and [¶97, Logic gate 650 may assert output Y when a match is identified (e.g., in response to determining that H.sub.F[31:0] is indeed equal to (32'b0-H.sub.k[31:0])) and may otherwise deassert output Y (e.g., in response to determining that H.sub.F[31:0] is not equal to (32'b0-H.sub.k[31:0]) Logic gate 650 may assert output Y when a match is identified (e.g., in response to determining that H.sub.F[31:0] is indeed equal to (32'b0-H.sub.k[31:0])) and may otherwise deassert output Y (e.g., in response to determining that H.sub.F[31:0] is not equal to (32'b0-H.sub.k[31:0])( equated to emulate the functionality of a logic gate based on first and second rule).  The example of FIG. 16 in which hardwired comparison circuit 600 is implemented using a logic AND gate is merely illustrative and does not serve to limit the scope of the present invention.  If desired, hardwired comparison circuit 600 may be implemented using logic OR gates, logic NAND gates, logic NOR gates, logic XOR gates, logic XNOR gates, logic inverters, a combination of different types of logic gates, or other suitable types of logic gates with at least some inverting inputs.], and [¶116,  At step 806, bit checking circuitry 702 (e.g., circuitry 702 in FIG. 19) may receive the output signals from each of the logic comparison gates and may issue a found signal when all of the output signals for each of the enabled groups are valid. In such scenarios, the mining circuitry (mining circuitry used to mine digital currency, e.g., Bitcoin) may pass the current hash output (or some other version of the current hash output) as a candidate solution to a host controller for full verification].

Examiner Note: Examiner maintains the rejection.


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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains.  Patentability shall not be negated by the manner in which the invention was made.


The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7, and 10-23 are rejected under 35 U.S.C. 103 as being unpatentable over NPL publication of “Mastering Bitcoin” authored by Andreas Antonopoulos hereafter referred to as Mastering and further in view of US Patent No. (US2016/0330031) issued to Drego. 
Regarding claim 1, Antonopoulos discloses identifying a first blockchain transaction and a second blockchain transaction of a blockchain, a first locking script and a first unlocking script corresponding to the first blockchain transaction, and a second locking script and a second unlocking script corresponding to the second blockchain transaction [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock), Bitcoin’s transaction validation engine relies on two types of scripts to validate trans‐ actions — a locking script and an unlocking script. A locking script is an encumbrance placed on an output, and it specifies the conditions that must be met to spend the output in the future. Historically, the locking script was called a scriptPubKey, because it usually contained a public key or bitcoin address. In this book we refer to it as a “locking script” to acknowledge the much broader range of possibilities of this scripting technology. In most bitcoin applications, what we refer to as a locking script will appear in the source code as “scriptPubKey”. An unlocking script is a script that “solves”, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input and most of the time they contain a digital signature produced by the user’s wallet from their private key. Historically, the unlocking script is called scriptSig, because it usually contained a digital signature.]; and
processing the second unlocking script using an output of the first blockchain transaction; executing, as a result of the processing, the first locking script and the second unlocking script, wherein: executing the second unlocking script results in a first input and a second input.
Antonopoulos discloses: [ (Page 38, Section "Bitcoin Transactions": "In bitcoin terms, "spending" is signing a transaction that transfers value from a previous transaction over to a new owner identified by a bitcoin address. Transactions move value from transaction inputs to transaction outputs. An input is where the coin value is coming from, usually a previous transaction's output. A transaction output assigns a new owner to the value by associating it with a key. The destination key is called an encumbrance. It imposes a requirement for a signature for the funds to be redeemed in future transactions. Outputs from one transaction can be used as inputs in a new transaction], [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock), Bitcoin’s transaction validation engine relies on two types of scripts to validate trans‐ actions — a locking script and an unlocking script. A locking script is an encumbrance placed on an output, and it specifies the conditions that must be met to spend the output in the future. Historically, the locking script was called a scriptPubKey, because it usually contained a public key or bitcoin address. In this book we refer to it as a “locking script” to acknowledge the much broader range of possibilities of this scripting technology. In most bitcoin applications, what we refer to as a locking script will appear in the source code as “scriptPubKey”. An unlocking script is a script that “solves”, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input and most of the time they contain a digital signature produced by the user’s wallet from their private key. Historically, the unlocking script is called scriptSig, because it usually contained a digital signature.], and [Pages 25-26, Adding transaction to the ledger, transmitting the transaction, how to propagate, view and verify transaction]. 
[ Page 124, third paragraph, In the current implementation the scripts are executed separately
with the stack transferred between the two executions, as described below.
First, the unlocking script is executed, using the stack execution engine. If the unlocking
script executed without errors (e.g., it has no “dangling” operator’s leftover), the main
stack (not the alternate stack) is copied and the locking script is executed. If the result
of executing the locking script with the stack data copied from the unlocking script is
“TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the
locking script and therefore the input is a valid authorization to spend the UTXO. If
any result other than “TRUE” remains after execution of the combined script, the input
is invalid as it has failed to satisfy the spending conditions placed on the UTXO. Note
that the UTXO is permanently recorded in the blockchain, and therefore is invariable
and is unaffected by failed attempts to spend it by reference in a new transaction. Only
a valid transaction that correctly satisfies the conditions of the UTXO results in the
UTXO being marked as “spent” and removed from the set of available (unspent) UTXO], and 
[Page 125, 4th paragraph, Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL (Boolean operator) pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal (equated to invalid transaction). Bitcoin transaction scripts usually contain a conditional operator, so that they can produce the result TRUE that signifies a valid transaction], and [see FIG.5-2 and corresponding text pages 125-126, Page 127, Third paragraph, while most locking scripts refer to a bitcoin address or public key, thereby requiring proof of ownership to spend the funds, the script does not have to be that complex. Any combination of locking and unlocking scripts that results in a TRUE value is valid. The simple arithmetic we used as an example of the scripting language above is also a valid locking script that can be used to lock a transaction output…As we saw in the step-by-step example above, when this script is executed, the result is OP_TRUE, making the transaction valid. Not only is this a valid transaction output locking script, but the resulting UTXO could be spent by anyone with the arithmetic skills to know that the number 2 satisfies the scrip], and [ see Appendix, table C-1: OP_0 or OP_FALSE: an empty array is pushed on to the stack].
Examiner Note: Drego also discloses this limitation as: [¶3, The Bitcoin protocol defines a system in which the creation and distribution of the bitcoin cryptocurrency is governed by consensus among a peer-to-peer network. The network maintains a public ledger in which new transactions are verified and recorded by members of the network via cryptography. The operations of verifying and recording transactions of cryptocurrencies such as transactions in the bitcoin cryptocurrency are sometimes referred to as mining, because completion of each mining operation typically rewards the miner with newly created cryptocurrency (e.g., bitcoins). Verified transactions and newly created bitcoins are recorded in the public ledger. The public ledger serves as an official history of transactions. The amount of cryptocurrency owned by any entity may be determined from the public ledger], and [see FIGS 4 corresponding text for more details, ¶¶43-47, transaction 130 that transfers currency from a source wallet to a destination wallet… The set of outputs 126 identifies one or more destination wallets (further transaction) and a respective amount to transfer from the source wallet to each destination wallet. In the example of FIG. 4, the transaction includes one destination wallet and a corresponding amount to be transferred from the source wallet to the destination wallet]; and
executing the first locking script includes determining a first rule defining how the first input evaluates to a first value and a second rule defining how a second input evaluates to a second value the first value and the second value each being TRUE or FALSE; determining, based on the first value and the second value, an output; and transmitting, based on the output corresponding to the TRUE result, the further transaction to a blockchain network for validation [ see FIG. 2-6, Aggregating transaction and corresponding text for more detail] , and [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock)], and [ Page 124, third paragraph, In the current implementation the scripts are executed separately with the stack transferred between the two executions, as described below. First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed without errors (e.g., it has no “dangling” operator’s leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO. If any result other than “TRUE” remains after execution of the combined script, the input is invalid as it has failed to satisfy the spending conditions placed on the UTXO. Note that the UTXO is permanently recorded in the blockchain, and therefore is invariable and is unaffected by failed attempts to spend it by reference in a new transaction. Only a valid transaction that correctly satisfies the conditions of the UTXO results in the UTXO being marked as “spent” and removed from the set of available (unspent) UTXO], and [Page 125, 4th paragraph, Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL (Boolean operator) pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal (equated to invalid transaction). Bitcoin transaction scripts usually contain a conditional operator, so that they can produce the result TRUE that signifies a valid transaction], and [see FIG.5-2 and corresponding text pages 125-126, , The scripting language executes the script by processing each item from left to right.
Numbers (data constants) are pushed onto the stack. Operators push or pop one or
more parameters from the stack, act on them, and may push a result onto the stack. For
example, OP_ADD will pop two items from the stack, add them and push the resulting
sum onto the stack. Conditional operators evaluate a condition producing a boolean result of TRUE or FALSE. For example, OP_EQUAL pops two items from the stack and pushes TRUE
(TRUE is represented by the number 1) if they are equal or FALSE (represented by zero)
if they are not equal. Bitcoin transaction scripts usually contain a conditional operator,
so that they can produce the result TRUE that signifies a valid transaction], and [ Page 127, Third paragraph, while most locking scripts refer to a bitcoin address or public key, thereby requiring proof of ownership to spend the funds, the script does not have to be that complex. Any combination of locking and unlocking scripts that results in a TRUE value is valid. The simple arithmetic we used as an example of the scripting language above is also a valid locking script that can be used to lock a transaction output…As we saw in the step-by-step example above, when this script is executed, the result is OP_TRUE, making the transaction valid. Not only is this a valid transaction output locking script, but the resulting UTXO could be spent by anyone with the arithmetic skills to know that the number 2 satisfies the scrip], and [ see Appendix, table C-1: OP_0 or OP_FALSE: an empty array is pushed on to the stack].
Examiner comment: Drego also in various paragraphs of his application indicates that the operations of verifying and recording transactions of cryptocurrencies such as transactions in the bitcoin cryptocurrency are sometimes referred to as mining (mining circuitry used to mine digital currency, e.g., Bitcoin, by implementing different type of logic gates), because completion of each mining operation typically rewards the miner with newly created cryptocurrency (e.g., bitcoins). Verified transactions (implementing locking and unlocking scripts) and newly created bitcoins are recorded in the public ledger. The public ledger serves as an official history of transactions. As indicates in the links below from Internet(in conclusion section), that bitcoin transaction uses the locking and unlocking scripts. 
Mastering does not explicitly disclose, however, Drego discloses by emulating the functionality of a logic gate using the first value and the second value as inputs to the logic gate, the output corresponding to a TRUE result or a FALSE [Claim 16. An electronic device that forms a node in a peer-to-peer network of nodes that support transactions in a digital currency, the electronic device comprising: hashing circuitry configured to generate a hash output by performing a plurality of sequential rounds of a Secure Hash Algorithm 256 (SHA-256) cryptographic hashing algorithm based at least on an initial hash value and a plurality of message words; and a comparison circuit that directly receives the hash output from the hashing circuitry, wherein the comparison circuit includes a plurality of logic gates that is used to compare a portion of the hash output to a predetermined value], and [Abstract, Cryptographic hashing circuitry such as mining circuitry used to mine digital currency may be formed on an integrated circuit. The hashing circuitry may include sequential rounds of register and logic circuitry that perform operations of a cryptographic protocol. A final hash output from the hashing circuitry may be checked using a difficulty comparison circuit to determine whether the hash output satisfies predetermined difficulty criteria. The difficulty comparison circuit may be configured as a hardwired comparison circuit having logic gates for checking only a subset of bits in the hash output]], and [¶97, Logic gate 650 may assert output Y when a match is identified (e.g., in response to determining that H.sub.F[31:0] is indeed equal to (32'b0-H.sub.k[31:0])) and may otherwise deassert output Y (e.g., in response to determining that H.sub.F[31:0] is not equal to (32'b0-H.sub.k[31:0])( equated to emulate the functionality of a logic gate based on first and second rule) .  The example of FIG. 16 in which hardwired comparison circuit 600 is implemented using a logic AND gate is merely illustrative and does not serve to limit the scope of the present invention.  If desired, hardwired comparison circuit 600 may be implemented using logic OR gates, logic NAND gates, logic NOR gates, logic XOR gates, logic XNOR gates, logic inverters, a combination of different types of logic gates, or other suitable types of logic gates with at least some inverting inputs.], and [¶116,  At step 806, bit checking circuitry 702 (e.g., circuitry 702 in FIG. 19) may receive the output signals from each of the logic comparison gates and may issue a found signal when all of the output signals for each of the enabled groups are valid. In such scenarios, the mining circuitry (mining circuitry used to mine digital currency, e.g., Bitcoin) may pass the current hash output (or some other version of the current hash output) as a candidate solution to a host controller for full verification].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mastering with the teaching of Drego Drego to indicates that the operations of verifying and recording transactions of cryptocurrencies such as transactions in the bitcoin cryptocurrency are sometimes referred to as mining (mining circuitry used to mine digital currency, e.g. Bitcoin,by implementing different type of logic gates), because completion of each mining operation typically rewards the miner with newly created cryptocurrency (e.g., bitcoins). Verified transactions (implementing locking and unlocking scripts) and newly created bitcoins are recorded in the public ledger. The public ledger serves as an official history of transactions. As indicates in the links below from Internet, that bitcoin transaction uses the locking and unlocking scripts.
Regarding claims 2, and 19, Mastering does not explicitly disclose, however, Drego discloses  the  logic gate comprises  an OR gate, NAND gate, NOR gate, a NOT gate, an XNOR gate, an IMPLY gate, or a Converse implication gate  [¶97, Logic gate 650 may assert output Y when a match is identified (e.g., in response to determining that H.sub.F[31:0] is indeed equal to (32'b0-H.sub.k[31:0])) and may otherwise deassert output Y (e.g., in response to determining that H.sub.F[31:0] is not equal to (32'b0-H.sub.k[31:0]).  The example of FIG. 16 in which hardwired comparison circuit 600 is implemented using a logic AND gate is merely illustrative and does not serve to limit the scope of the present invention.  If desired, hardwired comparison circuit 600 may be implemented using logic OR gates, logic NAND gates, logic NOR gates, logic XOR gates, logic XNOR gates, logic inverters, a combination of different types of logic gates, or other suitable types of logic gates with at least some inverting inputs.], and [Claim 16. An electronic device that forms a node in a peer-to-peer network of nodes that support transactions in a digital currency, the electronic device comprising: hashing circuitry configured to generate a hash output by performing a plurality of sequential rounds of a Secure Hash Algorithm 256 (SHA-256) cryptographic hashing algorithm based at least on an initial hash value and a plurality of message words; and a comparison circuit that directly receives the hash output from the hashing circuitry, wherein the comparison circuit includes a plurality of logic gates that is used to compare a portion of the hash output to a predetermined value].
Regarding claim 3, Mastering does not explicitly disclose, however, Drego discloses wherein the first value or the second value corresponds to at least one Boolean input is derived or generated by testing or evaluating to a blockchain puzzle [¶66, During mining operations, a device collects a set of transactions that have not already been recorded in block chain 200.  The mining circuitry may identify the last (most recently recorded) block in block chain 200.  The mining circuitry may subsequently generate a new block 150 from the set of transactions such that the new block includes an identifier 164 that identifies the last block of block chain 200 and solves the cryptographic puzzle of the cryptocurrency protocol used by the block chain].
Examiner Note: Mastering also discloses this limitation as: [Page 27, 3rd paragraph, The Puzzle used in bitcoin].
Regarding claim 4, Mastering discloses wherein the first locking script or second locking script comprises a hash of a script comprising the at least one instruction [Page 134, see section pay to script has (P2SH) section, A P2SH transaction locks the output to this hash instead of the longer script, using the locking script: OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL].
	Examiner Note: Drego discloses this limitation as: [¶7, the hashing circuitry may include sequential rounds of register and logic circuitry that perform rounds of operations of a cryptographic protocol such as the Secure Hash Algorithm 256 (SHA-256) cryptographic algorithm based on an initial hash value and multiple message words to generate a corresponding hash output].
Regarding claim 5, Mastering discloses wherein the first locking script or second locking script is a P2SH locking script as known in the Bitcoin protocol, or a functionally equivalent locking script in another blockchain protocol [Page 134, see section pay to script has (P2SH) section, A P2SH transaction locks the output to this hash instead of the longer script, using the locking script: OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL].
Regarding claim 7, Mastering discloses wherein executing the second unlocking script is performed within a script in a blockchain transaction [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock)], and [Page 125, 4th paragraph, Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal. Bitcoin transaction scripts usually contain a conditional].
Regarding claim 10, Mastering discloses providing a computing resource arranged to influence the behaviour of a device or process based upon: detection of the second transaction within the blockchain or blockchain network; and/or the validity of the second transaction [Page 123, Script Construction (Lock + Unlock), Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions— a locking script and an unlocking script…].
Regarding claim 11, Mastering discloses Interpreting the detecting of the further transaction within the blockchain or blockchain network as the TRUE output of a logic gate [ Page 124, 3rd paragraph, First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed without errors (e.g it has no “dangling” operator’s leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO].
Regarding claim 12 Mastering discloses wherein validation of the second transaction within a blockchain network is dependent upon the execution of the unlocking script [Page 124, 3rd paragraph, First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed without errors (e.g it has no “dangling” operator’s leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO], and [Page 123, Script Construction (Lock + Unlock), Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions— a locking script and an unlocking script…].
Regarding claim 13, Mastering discloses controlling a device or process based upon the validity of the second transaction, wherein the validity is determined or established by a computer-based control agent, or by monitoring the blockchain network to determine if it has been validated by a network node, and/or by monitoring the state of the blockchain to determine whether the  second transaction has been written to the blockchain [page xvii, 5th paragraph, a grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to find a proof-of-work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus], and [page xviii, 9th paragraph, in simple terms, a transfer of bitcoins from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the bitcoin network, collected by miners and included into blocks, made permanent on the blockchain], and [ Page 123, Script Construction (Lock + Unlock), Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions— a locking script and an unlocking script…].
Regarding claim 14, Matering discloses wherein the first input and /or second input comprises a numeric value, a constant value, a result of a hash function, a cryptographic key, a blockchain puzzle, and/or a Bitcoin other blockchain-related address [ Page 117, Transaction inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is
recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking scrip…].
Examiner Note: Drego also discloses this limitation as: [see FIGS 3-4, and corresponding text for more detail, item# 124, previous transaction identifier (E.G.H (TX previous].
Regarding claim 15, Mastering discloses wherein the first and/or second transaction is generated and/or transmitted to a blockchain network by an automated process executing on a computing-based resource [Page 155, 3rd paragraph, as with real life, the bitcoin application can use several strategies to satisfy the purchase amount: combining several smaller units, finding exact change, or using a single unit larger than the transaction value and making change. All of this complex assembly of spendable UTXO is done by the user’s wallet automatically and is invisible to users].
  Examiner Note:  Drego discloses this limitation as: [¶52, in performing mining operations to verify and record a set of transactions, mining circuitry may generate a block to be recorded in the global ledger as shown in FIG. 6.  Block 150 of FIG. 6 may include block header 152, coinbase transaction TX0 (e.g., a coinbase transaction 140), and a set of transactions 156 to be recorded], and [¶66].
Regarding claim 16, Mastering discloses wherein the first rule or second rule: comprises a Boolean condition or operator ¶page 123, Script construction (Lock+ unlock)], and [Page 125, 4th paragraph, Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL (Boolean operator) pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal. Bitcoin transaction scripts usually contain a conditional].
is written and/or executed using a stack-based programming language [Page 125, 2rd paragraph, Bitcoin’s scripting language is called a stack-based language because it uses a data structure called a stack. A stack is a very simple data structure, which can be visualized as a stack of cards. A stack allows two operations: push and pop. Push adds an item on top of the stack. Pop removes the top item from the stack.
Regarding claim 17, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 18, the subject matter of independent claim 18 contains the corresponding features as the method of claim 1 expressed respectively in analogous terms and additionally the features disclosed in 18:, Mastering discloses receive a plurality of input signals, determine at least one Boolean input based at least in part on the received plurality of input signals   [Page125, last 3 paragraphs, the scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. Operators push or pop one or more parameters from the stack, act on them, and may push a result onto the stack. For example, OP_ADD will pop two items from the stack, add them and push the resulting sum onto the stack. Conditional operators evaluate a condition producing a Boolean result of TRUE or FALSE. For example, OP_EQUAL (equated Boolean operator) pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal. Bitcoin transaction scripts usually contain a conditional operator, so that they can produce the result TRUE that signifies a valid transaction. In the following example, the script 2 3 OP_ADD 5 OP_EQUAL demonstrates the arith‐ metic addition operator OP_ADD, adding two numbers and putting the result on the stack, followed by the conditional operator OP_EQUAL which checks the resulting sum, the OP_ prefix is omitted in the step-by-step example]; and
 and execute a locking script and an unlocking script of respective blockchain transactions to provide a first output when one, and only one, 
[Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script], and [¶page 123, Script construction (Lock+ unlock)]; and
input signal enables the generation of a hash value which is equal to a stored data item [Page117, Transaction Inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script].
Examiner Note: Drego discloses this limitation as: [¶97, Logic gate 650 may assert output Y when a match is identified (e.g., in response to determining that H.sub.F [31:0] is indeed equal to (32'b0-H.sub.k [31:0])) and may otherwise deassert output Y (e.g., in response to determining that H.sub.F [31:0] is not equal to (32'b0-H.sub.k [31:0])].
Wherein the system is configured to monitor search the blockchain or blockchain network to determine the presence or absence of the further transaction which comprises the unlocking script 
Mastering (Antonopoulos) in his application discloses this limitation as: [ Page 15, we will examine bitcoin from a high-level by tracking a single transaction through the bitcoin system and watch as it becomes “trusted” and accepted by the bitcoin mechanism of distributed consensus and is finally recorded on the blockchain, the distributed ledger of all transactions. Each example below is based upon an actual transaction made on the bitcoin network, simulating the interactions between the users (Joe, Alice and Bob) by sending funds from one wallet to another. While tracking a transaction through the bitcoin network and blockchain, we will use a blockchain explorer site to visualize each step. A blockchain explorer is a web application that operates as a bitcoin search engine, in that it allows you to search for addresses, transactions and blocks and see the relationships and flows between them.], and [ page 243, BLOCKCHAIN WATCHING. monitor:  Monitor an address; watchtx,:  Watch transactions from the network searching for a certain hash], and [ Page 13see blockchain.info website webpage, search box, listing all the transaction to and from an address], and [Page, 113, Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is connected and a success message will be returned synchronously to the originator. If the transaction is invalid, the node will reject it and synchronously return a rejection message to the originator], and [Pages 25-26, Adding transaction to the ledger, transmitting the transaction, how to propagate, view and verify transaction].
Examiner Note: Drego also discloses this limitation as: [¶3, The Bitcoin protocol defines a system in which the creation and distribution of the bitcoin cryptocurrency is governed by consensus among a peer-to-peer network. The network maintains a public ledger in which new transactions are verified and recorded by members of the network via cryptography. The operations of verifying and recording transactions of cryptocurrencies such as transactions in the bitcoin cryptocurrency are sometimes referred to as mining, because completion of each mining operation typically rewards the miner with newly created cryptocurrency (e.g., bitcoins). Verified transactions and newly created bitcoins are recorded in the public ledger. The public ledger serves as an official history of transactions. The amount of cryptocurrency owned by any entity may be determined from the public ledger], and [see FIGS 4 corresponding text for more details, ¶¶43-47, transaction 130 that transfers currency from a source wallet to a destination wallet… The set of outputs 126 identifies one or more destination wallets (further transaction) and a respective amount to transfer from the source wallet to each destination wallet. In the example of FIG. 4, the transaction includes one destination wallet and a corresponding amount to be transferred from the source wallet to the destination wallet].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mastering with the teaching of Drego in order to implement  a bit comparison circuitry which include multiple logic gates each of which asserts an output signal when the subset of bits in the hash output matches with a predetermined value and deasserts the output signal when the subset of bits in the hash output differs from the predetermined value[ Drego, ¶9].
Regarding claim 20, Mastering does not explicitly disclose, however, Drego discloses   wherein the system is further operative to: derive a hash value for each of the inputs; compare the hash value derived for each of the inputs with a stored hash value; return a first value for each input in which the derived hash value is identical to a stored hash value; return a second value for each input in which the derived hash value is not identical to a stored hash value; and determine the quantity of first values and issue the first output based on the determination [¶7, The hashing circuitry may include sequential rounds of register and logic circuitry that perform rounds of operations of a cryptographic protocol such as the Secure Hash Algorithm 256 (SHA-256) cryptographic algorithm based on an initial hash value and multiple message words to generate a corresponding hash output], and [¶8, In accordance with an embodiment, bit comparison circuitry may be used to check a subset of bits in the hash output to identify a candidate solution.  In response to identifying the candidate solution, a host controller may then be used to verify the candidate solution by determining whether the hash output satisfies predetermined difficulty criteria.  The host controller may be shared among a plurality of cryptographic hashing circuitries that generate hash outputs for different search spaces in parallel.  Operated in this way, the bit comparison circuitry may identify candidate solutions with partial certainty, whereas the host controller may verify the validity of the candidate solutions with full certainty], and [¶9, 1n accordance with another embodiment, the bit comparison circuitry may include multiple logic gates each of which asserts an output signal when the subset of bits in the hash output matches with a predetermined value and deasserts the output signal when the subset of bits in the hash output differs from the predetermined value.  At least one of the logic gates has an inverting input for implementing the desired hardwired comparison scheme].
Regarding claim 21, Mastering discloses wherein, responsive to the control system providing a first output, the stored data item is regenerated [Page 19, Transactions move value from transaction inputs to transaction outputs.An input is where the coin value is coming from, usually a previous transaction’s output. A transaction output assigns a new owner to the value by associating it with a key. The destination key is called an encumbrance. It imposes a requirement for a signature for the funds to be redeemed in future transactions. Outputs from one transaction can be used as inputs in a new transaction, thus creating a chain of ownership as the value is moved from address to address], and [see FIGS 2-5, 2-6, and 2-7 and corresponding text]
	Examiner Note: Drego discloses this limitation as: [¶61, Merkle tree 180 includes leaf nodes 182 that are each generated by computing the hash of a respective transaction (e.g., using the SHA function).  For example, hash value H0 is computed from the (double) hash of transaction TX0 (e.g., a coinbase transaction), whereas hash values H1, H2, H3, H4, H5, H6, and H7 are computed from transactions TX1, TX2, TX3, TX4, TX5, TX6, and TX7, respectively].
Regarding claim 22, Mastering discloses wherein the stored data item is regenerated in a random or pseudo-random manner [Page, 136, Transaction inputs, in simple terms, transaction inputs are pointers to UTXO. They point to a specific UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script].
Examiner Note: Drego discloses this limitation as: [¶7, The hashing circuitry may include sequential rounds of register and logic circuitry that perform rounds of operations of a cryptographic protocol such as the Secure Hash Algorithm 256 (SHA-256) cryptographic algorithm based on an initial hash value and multiple message words to generate a corresponding 
hash output], and [see FIG. 7, ¶58, Hash functions used by the cryptographic puzzle may operate in sequential steps (sometimes referred to herein as stages) on block header 152…].
Regarding claim 23, Mastering discloses wherein a public key-private key pair is generated for each stored data item [ see Page 61, key comes in pair, private and public key], and [ Page 63, 1st paragraph, A bitcoin wallet contains a collection of key pairs, each consisting of a private key and a public key…].
Examiner Note: Drego discloses this limitation as: [¶42, Digital wallets may be formed using any desired data structure and may sometimes be referred to as digital accounts.  Wallets may be identified using encryption schemes such as public-key cryptography in which a public-private key pair is assigned to each wallet.  The public key of a wallet may serve to publicly identify the wallet (e.g., a public address to which funds may be directed), whereas the private key may be used by the owner of the wallet to sign transactions (e.g., thereby verifying the authenticity of the transactions). 
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. 
Locking and unlocking scripts - Foundations of Blockchain [Book] (oreilly.com)
Locking and unlocking scripts
transaction input - What is Bitcoin locking and unlocking script? - Bitcoin Stack Exchange
What is Bitcoin locking and unlocking script?
NPL ( https://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockcha-in-as-tcpip. Attaching Semantic Metadata to Cryptocurrency Transactions (Definition 4 (Lock Script). A lock script is a Boolean function that takes a finite number of arguments as input. We call the Pre-Image of True in the lock script a combination.).   
Lerner, US pat.2016/0085955 (read the entire application, Boolean Circuit].     
Kapoor (US9063978) [ Apparatuses, Methods and Systems for A Financial Transaction Tagger].
Kote (US20170109748[ ¶35, the system provider device(s) 502, third party device(s) 514, payee device(s) 508, and/or payer device(s) 510 may monitor that crypto currency public ledger and, specifically, the confirmed transactions in the valid blocks that are added to the crypto currency public ledger and agreed with by a majority of the distributed network of devices].
Sriram (US2016/0269182) [ ¶27, The block chain keeps track of all confirmed logistic transactions that occur within the logistics platform maintained by the provenance management system].
Brahma (US2016/0217436) [ Method, System and Program Product for Tracking and Securing Transactions of Authenticated Items Over Block Chain Systems].
EP3125489A1[ Abstract, the blockchain is monitored to identify profile transactions. The identified profile transactions are compared with the transaction creation profile to detect deviation from the transaction creation profile corresponding to malicious event occurring with respect to the blockchain].
Sjelvgren(US2011/0218891)[ ¶40, …The transaction monitor/ledger updater 44 monitors or receives notifications regarding certain usages of a prepaid mobile station such as mobile station 30, and enters appropriate information reflecting such usage(s) into the prepaid account ledger 42 for the mobile station 30].                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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 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.





/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496