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 .
This initial written action is responding to the communication dated on 08/06/25.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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.
Examiner’s Note
Examiner has used European Patent Agency’s machine translation utility to translate Chinese patent application, written in Chinese language. Examiner has cited from this translated version. Zhang reference has paragraph starting with letter “N”. Examiner has only cited numerical paragraph number.
Priority
This 371 application filed on August 06, 2025 claims priority of PCT application PCT/CN2023/132382 filed on November 17, 2023, and foreign application CN202310763341.3 filed on June 26, 2023.
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in China on June 26, 2023. It is noted, however, that applicant has not filed a certified copy of the CN202310763341.3 application as required by 37 CFR 1.55.
Information Disclosure Statement
The following Information Disclosure Statements in the instant application submitted in compliance with the provisions of 37 CFR 1.97, and thus, have been fully considered:
IDS filed on 06 August 2025.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 12-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (CNPGPUB. # CN 110060054A, hereinafter “Liu”), and further in view of Zhang et al. (CNPGPUB. # CN 112600875A, hereinafter “Zhang”).
Referring to Claims 1, 14 and 20:
Regarding Claim 1 Liu teaches,
A blockchain-based transaction management method comprising:
obtaining transaction data; (¶11,Fig. 1, ¶40, “Step 102: The first blockchain node receives the transaction”, i.e. transaction data is obtained)
invoking a privacy contract based on privacy transaction data in the transaction data, and verifying a data execution state of the privacy transaction data through the privacy contract; (¶12, ¶23-¶24, Fig. 1, ¶45, “Step 104: The first blockchain node identifies whether the transaction is a plaintext transaction or a privacy transaction, and whether the account that generated the transaction is a plaintext account or a privacy account”, ¶46-¶47, ¶51-¶53, i.e. a privacy contract is invoked based on the privacy transaction data and data execution state is verified utilizing privacy contract),
,and
Liu does not teach explicitly,
generating a Merkle management tree based at least on the transaction data;
generating a transaction block based on the Merkle management tree and the transaction data, and performing on-chain processing on the transaction block.
However, Zhang teaches,
generating a Merkle management tree based at least on the transaction data; (¶11, “A Merkle tree is constructed based on the key element fields, and the first hash value of the root of the Merkle tree is calculated”, ¶18, “builds a Merkle tree based on the key element fields, and calculates the first hash value of the Merkle tree root”, ¶32-¶34, ¶42, ¶63, ¶66, “A Merkle tree is constructed based on key element information. By utilizing the data structure of the Merkle tree and the properties of the hash function, the complete transaction information is compressed into a fixed-length hash string.”, Fig. 1, ¶72, “Step 102: Construct a Merkle tree based on the key element fields and calculate the first hash value of the Merkle tree root”)
generating a transaction block based on the Merkle management tree and the transaction data, and performing on-chain processing on the transaction block. (¶13, ¶18, “any node simultaneously broadcasts the key element fields and the first hash value in the blockchain network; after all nodes in the blockchain network reach a consensus, the first hash value is updated in the blockchain network, and the master node in the blockchain network stores the transaction information locally”, ¶35-¶36, ¶42, Fig. 1, ¶73, “Step 103: After all nodes in the blockchain network reach a consensus, the first hash value is updated in the blockchain network, and the master node in the blockchain network stores the transaction information locally”).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Zhang with the invention of Liu.
Liu teaches, invoking a privacy contract based on privacy transaction data and verifying data execution state utilizing privacy contract. Zhang teaches, generating a Merkle tree and blockchain transaction block are created and processed according to Merkle tress. Therefore, it would have been obvious to have generating a Merkle tree and blockchain transaction block are created and processed according to Merkle tress of Zhang with invoking a privacy contract based on privacy transaction data and verifying data execution state utilizing privacy contract. Of Liu so considering the characteristics of peer-to-peer distributed electricity exchanges, such as massive volume, high frequency, high default rate, and insufficient terminal computing power, the scale of on-chain data is reduced by using Merkle tree-based storage technology.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 14, it is a computer device claim of above method Claim 1 and therefore Claim 14 is rejected with the same rationale as applied against Claim 1 above.
Regarding Claim 20, it is a non-transitory computer-readable storage medium claim of above method Claim 1 and therefore Claim 20 is rejected with the same rationale as applied against Claim 1 above.
Referring to Claims 2 and 15:
Regarding Claim 2 rejection of Claim 1 is included and for the same motivation Liu teaches,
The method according to claim 1, further comprising: in response to the data execution state being a data executable state, executing a privacy transaction corresponding to the privacy contract. (¶48, ¶51-¶52, i.e. privacy transaction is executed according to a privacy contract).
Regarding Claim 15, rejection of Claim 14 is included and Claim 15 is rejected with the same rationale as applied against Claim 2 above.
Referring to Claims 3 and 16:
Regarding Claim 3 rejection of Claim 1 is included and for the same motivation Liu teaches,
The method according to claim 1, wherein the transaction data further includes regular transaction data other than the privacy transaction data; (¶12,¶45, ¶47, i.e. transaction data includes plaintext (regular transaction) data)
the method further comprising:
obtaining the regular transaction data from the transaction data; (¶24, The first blockchain node executes the plaintext transaction outside the trusted execution environment and stores the obtained plaintext execution result in an external storage space outside the trusted execution environment”, ¶45, ¶47)
[wherein generating the Merkle management tree includes generating the Merkle management tree based on the transaction data] and a regular transaction corresponding to the regular transaction data. (¶24, ¶45, ¶47)
Liu does not teach explicitly,
wherein generating the Merkle management tree includes generating the Merkle management tree based on the transaction data [and a regular transaction corresponding to the regular transaction data].
However, Zhang teaches,
wherein generating the Merkle management tree includes generating the Merkle management tree based on the transaction data (¶11, “A Merkle tree is constructed based on the key element fields, and the first hash value of the root of the Merkle tree is calculated”, ¶18, “builds a Merkle tree based on the key element fields, and calculates the first hash value of the Merkle tree root”, ¶32-¶34, ¶42, ¶63, ¶66, “A Merkle tree is constructed based on key element information. By utilizing the data structure of the Merkle tree and the properties of the hash function, the complete transaction information is compressed into a fixed-length hash string.”, Fig. 1, ¶72, “Step 102: Construct a Merkle tree based on the key element fields and calculate the first hash value of the Merkle tree root”) [and a regular transaction corresponding to the regular transaction data].
Regarding Claim 16, rejection of Claim 14 is included and Claim 15 is rejected with the same rationale as applied against Claim 3 above.
Regarding Claim 12 rejection of Claim 1 is included and for the same motivation Liu teaches,
The method according to claim 1, further comprising:
obtaining privacy transaction information generated by the privacy transaction; (¶47, “all other fields in a privacy transaction are in ciphertext. This allows the first blockchain node to quickly identify the transaction type without decryption, thus enabling differentiated processing between plaintext and privacy transactions”, ¶67)
generating a privacy block based on the privacy transaction information; (¶67-¶68) and
adding the privacy block to a privacy blockchain. (¶68-¶70, ¶72).
Regarding Claim 13 rejection of Claim 1 is included and for the same motivation Liu teaches,
The method according to claim 1, further comprising:
obtaining privacy transaction information generated by the privacy transaction; (¶47, “all other fields in a privacy transaction are in ciphertext. This allows the first blockchain node to quickly identify the transaction type without decryption, thus enabling differentiated processing between plaintext and privacy transactions”, ¶67)
Liu does not teach explicitly,
obtaining a privacy data identifier corresponding to the privacy transaction data in the Merkle management tree; and
storing the privacy data identifier and the privacy transaction information in association.
However, Zhang teaches,
obtaining a privacy data identifier corresponding to the privacy transaction data in the Merkle management tree; (¶32-¶34, ¶42, i.e. key element is interpreted as data identifier) and
storing the privacy data identifier and the privacy transaction information in association. (¶42, “the first hash value is updated in the blockchain network, and the master node in the blockchain network stores the transaction information locally”, i.e. first hash value (data identifier) and transaction information are stored in a blockchain).
Claims: 4-11 and 17-19 Objected
Claims 4-11 and 17-19 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.
Liu discloses, The first blockchain node identifies whether the transaction is a plaintext transaction or a privacy transaction, and whether the account that generated the transaction is a plaintext account or a privacy account; (¶12). After receiving a transaction generation request initiated by a local account, the client identifies whether the local account is a plaintext account or a privacy account, and whether the requested transaction is a plaintext transaction or a privacy transaction. If a privacy account requests to generate a plaintext transaction, the client rejects the transaction generation request; otherwise, the client generates the corresponding transaction in response to the transaction generation request The first blockchain node executes the plaintext transaction outside the trusted execution environment and stores the obtained plaintext execution result in an external storage space outside the trusted execution environment; or, the first blockchain node decrypts the privacy transaction to obtain the corresponding plaintext transaction content; executes the plaintext transaction content in the trusted execution environment and encrypts the obtained plaintext execution result into a ciphertext execution result before storing it in the external storage space. (¶23-¶24). The first blockchain node identifies whether the transaction is a plaintext transaction or a privacy transaction, and whether the account that generated the transaction is a plaintext account or a privacy account. In one embodiment, this specification classifies transactions into plaintext transactions (plaintext type) and privacy transactions (privacy type) based on different privacy protection requirements. Different execution methods can be implemented for different types of transactions, which will be described in detail below. For example, by adding a type field to a transaction, the first blockchain can identify whether the transaction is a plaintext transaction or a privacy transaction. In related technologies, such as the Ethereum network, transactions typically include fields such as to, value, and data. Based on related technologies, this embodiment adds a type field to the transaction, such as a type field, and indicates the type of the transaction based on the value of the type field; for example, when the type field is a first value, it indicates that the transaction is a plaintext transaction, and when the type field is a second value, it indicates that the transaction is a privacy transaction. In one embodiment, all content of a plaintext transaction is in plaintext form, that is, each field of the transaction is in plaintext form, so that the first blockchain node can directly read each field of the plaintext transaction to perform relevant processing; at the same time, the plaintext transaction is packaged into blocks in plaintext form and then recorded in the blockchain in plaintext form. Except for the type field, which is in plaintext, all other fields in a privacy transaction are in ciphertext. This allows the first blockchain node to quickly identify the transaction type without decryption, thus enabling differentiated processing between plaintext and privacy transactions. Furthermore, the ciphertext format ensures that the transaction information can only be decrypted and read by the key holder, preventing leakage. Privacy transactions are also packaged into blocks in ciphertext and recorded in the blockchain in ciphertext. (¶45-¶47). Assuming the aforementioned privacy transaction is generated at a client, the client can first generate the plaintext transaction content, and then encrypt the plaintext transaction content using a key. The encryption can be either symmetric or asymmetric. Accordingly, the first blockchain node can use the corresponding key to decrypt the privacy transaction to obtain the plaintext transaction content. If the client uses symmetric encryption, that is, encrypts the plaintext transaction content with the symmetric key of the symmetric encryption algorithm, then the first blockchain node can decrypt the privacy transaction using the symmetric key of the symmetric encryption algorithm. Symmetric encryption uses encryption algorithms such as DES, 3DES, TDEA, Blowfish, RC5, and IDEA. The symmetric key for the symmetric encryption algorithm may be generated by the party that generates the privacy transaction, or determined through negotiation between the client and the first blockchain node, or obtained by sending it from the key management server. If an asymmetric encryption method is used, that is, the plaintext transaction content is encrypted with the public key of the asymmetric encryption algorithm, then the first blockchain node can decrypt the privacy transaction with the private key of the asymmetric encryption algorithm. Asymmetric encryption algorithms include RSA, Elgamal, Knapsack algorithm, Rabin, D-H,and ECC (Elliptic Curve Cryptography). The key for an asymmetric encryption algorithm can be, for example, a public key and a private key pair generated by the first blockchain node, with the public key being sent to the client in advance, so that the client can encrypt plaintext transaction content using the public key. The key for asymmetric encryption algorithms can also be generated by a key management server. Through remote verification, the key management server sends the private key to the first blockchain node, specifically, it can be passed into the circle of the first blockchain node. The first blockchain node can contain multiple enclaves, and the aforementioned private key can be passed to a secure enclave within these enclaves; for example, the secure enclave can be a QE (Quoting Enclave) enclave, rather than an AE (Application Enclave) enclave. For asymmetric encryption, the public key can be sent to the client by the key management server. Therefore, the client can use the public key to encrypt the plaintext transaction content, and correspondingly, the first blockchain node can use the private key to decrypt the privacy transaction to obtain the plaintext transaction content contained in the privacy transaction. The client can also use a combination of symmetric and asymmetric encryption. For example, the client uses a symmetric encryption algorithm to encrypt plaintext transaction content, that is, it uses the symmetric key of the symmetric encryption algorithm to encrypt the plaintext transaction content, and uses an asymmetric encryption algorithm to encrypt the symmetric key used in the symmetric encryption algorithm. Generally, the public key of an asymmetric encryption algorithm is used to encrypt the symmetric key used in a symmetric encryption algorithm. In this way, after the first blockchain node receives the encrypted transaction, it can first use the private key of the asymmetric encryption algorithm to decrypt it, obtain the symmetric key of the symmetric encryption algorithm, and then use the symmetric key of the symmetric encryption algorithm to decrypt the plaintext transaction content. For example, the key management server can send the private key of the asymmetric encryption algorithm to the circle of the first blockchain node through remote proof, and send the private key of the asymmetric encryption algorithm to the client. Therefore, the client can use the symmetric key of the symmetric encryption algorithm to encrypt the plaintext transaction content, that is, use the symmetric key of the symmetric encryption algorithm to encrypt the plaintext transaction content, and use the public key of the asymmetric encryption algorithm to encrypt the symmetric key used in the symmetric encryption algorithm. Then, the client can send the privacy transaction and the encrypted private key (obtained by encrypting the symmetric key used in the symmetric encryption algorithm with the public key of the asymmetric encryption algorithm) to the first blockchain node. After receiving the privacy transaction and the encrypted private key, the first blockchain node can first use the private key of the asymmetric encryption algorithm to decrypt the encrypted private key to obtain the symmetric key of the symmetric encryption algorithm, and then use the symmetric key of the symmetric encryption algorithm to decrypt the privacy transaction to obtain the plaintext transaction content. The encryption method used here is generally referred to as digital envelope encryption. (¶63-¶67).
Zhang teaches, A Merkle tree is constructed based on the key element fields, and the first hash value of the root of the Merkle tree is calculated. The distributed electricity trading blockchain storage method based on Merkle trees in this application embodiment involves the following steps: During the transaction reporting phase, any node in the blockchain network obtains transaction information, extracts key element fields from the transaction information, builds a Merkle tree based on the key element fields, and calculates the first hash value of the Merkle tree root; any node simultaneously broadcasts the key element fields and the first hash value in the blockchain network; after all nodes in the blockchain network reach a consensus, the first hash value is updated in the blockchain network, and the master node in the blockchain network stores the transaction information locally; any node in the blockchain network obtains actual settlement information, the first hash value, and the transaction information; extracts new key element fields from the actual settlement information, the first hash value, and the transaction information; builds a new Merkle tree based on the new key element fields, and calculates the second hash value of the new Merkle tree root; simultaneously broadcasts the new key element fields and the second hash value in the blockchain network; after all nodes in the blockchain network reach a consensus, the second hash value is updated in the blockchain network, and the master node in the blockchain network stores the actual settlement information locally. Therefore, considering the characteristics of peer-to-peer distributed electricity exchanges, such as massive volume, high frequency, high default rate, and insufficient terminal computing power, the scale of on-chain data is reduced by using Merkle tree-based storage technology. This reduces the complexity of information storage and updating during the matching, settlement, and verification stages of transactions while ensuring security and traceability, thereby improving market efficiency.
This method enables the effective application of blockchain technology to peer-to-peer
distributed electricity trading. (¶18).The first acquisition and extraction module is used to
acquire transaction information from any node of the blockchain network during the
transaction reporting stage, and extract key element fields from the transaction
information. The first module is used to build a Merkle tree based on the key element
fields; The first calculation module is used to calculate the first hash value of the Merkle
tree root; The first broadcast module is used for any node to simultaneously broadcast
the key element field and the first hash value in the blockchain network; The first
storage module is used to update the first hash value to the blockchain network after all
nodes in the blockchain network reach a consensus, and for the master node in the
blockchain network to store the transaction information locally. (¶32-¶36). The
distributed electricity trading blockchain storage device based on Merkle trees in this
application embodiment involves the following steps: During the transaction reporting
phase, any node in the blockchain network obtains transaction information, extracts key
element fields from the transaction information, builds a Merkle tree based on the key
element fields, and calculates the first hash value of the Merkle tree root; any
node simultaneously broadcasts the key element fields and the first hash value in the
blockchain network; after all nodes in the blockchain network reach a consensus, the
first hash value is updated in the blockchain network, and the master node in the
blockchain network stores the transaction information locally; any node in the
blockchain network obtains actual settlement information, the first hash value, and the
transaction information; extracts new key element fields from the actual settlement
information, the first hash value, and the transaction information; builds a new Merkle
tree based on the new key element fields, and calculates the second hash value of the
new Merkle tree root; simultaneously broadcasts the new key element fields and the
second hash value in the blockchain network; after all nodes in the blockchain network
reach a consensus, the second hash value is updated in the blockchain network, and
the master node in the blockchain network stores the actual settlement information
locally. Therefore, considering the characteristics of peer-to-peer distributed electricity
exchanges, such as massive volume, high frequency, high default rate, and insufficient
terminal computing power, the scale of on-chain data is reduced by using Merkle tree-
based storage technology. This reduces the complexity of information storage and
updating during the matching, settlement, and verification stages of transactions while
ensuring security and traceability, thereby improving market efficiency. This method
enables the effective application of blockchain technology to peer-to-peer distributed
electricity trading. (¶42). The Merkle tree in this application is a binary tree data
structure consisting of a set of leaf nodes, a set of intermediate nodes, and a root node.
In this system, a leaf node is a hash value obtained by hashing the basic data. The
hash values of two adjacent leaf nodes are merged into a string, and the hash of this
string is calculated. This string becomes the intermediate node of the next level above
the two leaf nodes. This process continues until the root node is obtained. Therefore,
the special structure of the Merkle tree determines that as long as the data at any leaf
node is tampered with, the hash value of the root node will change. (¶63). More
specifically, based on the characteristics of distributed electricity trading, the
trading cycle is divided into two stages: trading reporting and trading settlement.
For the transaction data generated in both stages, extract the key information and
convert it into string format. A Merkle tree is constructed based on key element
information. By utilizing the data structure of the Merkle tree and the properties of the
hash function, the complete transaction information is compressed into a fixed-length
hash string. The blockchain network only stores the hash string, while the complete
transaction information is stored locally on the master node in the blockchain network.
When other nodes need to obtain the complete transaction information, they only need
to request the data from the master node. By verifying the hash string stored on the
chain, the authenticity of the transaction data can be verified. (¶66). Step 102: Construct
a Merkle tree based on the key element fields and calculate the first hash value of the
Merkle tree root. Any node simultaneously broadcasts the key element fields and the
first hash value in the blockchain network. Step 103: After all nodes in the blockchain
network reach a consensus, the first hash value is updated in the blockchain network,
and the master node in the blockchain network stores the transaction information
locally. (¶72).
However, none of the art(s) teaches recited claim limitations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Pang Dong (WIPO PUB. # WO # 2020/088074) discloses, a privacy transaction method and apparatus based on a blockchain, and an application method and apparatus for privacy transaction. The private transaction method based on a blockchain is applied to a node device of a trusted user and comprises: receiving a first message sent by a blockchain user, the first message comprising first data information which is not protected by privacy and second data information which is protected by privacy, wherein the second data information which is protected by privacy is obtained by converting the first data information which is not protected by privacy; storing the first data information in a local database of the node device of the trusted user; and sending a second transaction to the blockchain, the second transaction comprising the second data information, so that the second transaction is verified and recorded in a distributed database of the blockchain.
Huang Zu-Cheng (CN # 115906169 A) discloses, a private contract access method in block chain and block chain node, wherein the block chain stores the access control information of the private contract, the node of the block chain comprises a trusted execution environment TEE, the method is executed in the TEE, comprising: in the process of executing the first contract invoked in the first transaction, before executing the access operation of the privacy contract included in the first contract, obtaining the access control information; according to the access control information, determining whether the first contract has authority to perform the access operation to the privacy contract, under the condition that the first contract has the authority, executing the access operation.
Moon et al. (KR # 102517001B) discloses, a system for processing a digital signature on a blockchain network comprises: a user terminal which generates and transmits unique address information for the terminal by using a private key; an authentication server which provides authentication services for accessing the blockchain network of the user terminal; and a blockchain node which maps the unique address information transmitted from the user terminal with user account information for using blockchain services, stores the same, and verifies transaction data by using the transaction data transmitted from the user terminal and the unique address information stored in an account information Merkle tree. Therefore, the system can securely create digital signatures.
Fan et al. (CN # 111415252A) discloses, based on a blockchain of privacy transaction processing and device, the method comprises: obtaining privacy transaction data by the first node, the information of the private transaction data and the second node transmitting to the first service corresponding to the first node; the second service to the first service by the information identification of the second node and the second node corresponding to the creating the encrypting channel between the first service and the second service, the said privacy transaction data sent to the second service via the encrypting channel; said second node extracts the privacy transaction data from the second service. The embodiment of the invention can effectively and can prove that achieving private transaction data of locally controllable blockchain network range, reduces the enterprise to blockchain private transaction uncontrollable worry.
LIU et al. (CN # 10659211B) discloses, a blockchain method for privacy protection in intelligent contract, in the intelligent asset trading participation agreement encrypted digital content information of the party, and performing cipher processing; the intelligent contract x by public key encryption using leaf nodes of the Merkle tree structure, Merkle tree, and uses the hash abstract value to replace the original data of the block head. Compared with the existing technology, the blockchain has data privacy protection requirement, comprising digital asset transaction data and the privacy protection function, only the intelligent contract transaction participant can view the transaction information, can be used with any data privacy protection requirement of blockchain application scene.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/DARSHAN I DHRUV/ Primary Examiner, Art Unit 2498
Prosecution Insights