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 05/07/2025.
Claims 1-14 are submitted for examination.
Claims 1-14 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.
Priority
This application filed on May 07, 2025 claims priority of Parent application 18/254,365 filed on May 24, 2023 which claims priority of PCT/US2021/060649 filed on November 23, 2021.
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 07 May 2025.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-3 and 5-14 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7, 15-17 and 20-22 of U.S. Patent No. 12,301,709. Although the claims at issue are not identical, they are not patentably distinct from each other. Please refer to comparison table below.
Instant Application 19/201,159
Paent Application 18/254,365, Patent # 12,301,709
MULTIPLE POST-QUANTUM CRYPTOGRAPHY KEY ENCAPSULATIONS WITH AUTHENTICATION AND FORWARD SECRECY
MULTIPLE POST-QUANTUM CRYPTOGRAPHY KEY ENCAPSULATIONS WITH AUTHENTICATION AND FORWARD SECRECY
1
A device for secure communications with a network, the device comprising: a nonvolatile memory configured to store a server static public key, a device static private key, and a corresponding device static public key; a hardware random number generator configured to generate a random number for a device ephemeral private key corresponding to a device ephemeral public key; a network interface configured to: a) send, to the network, a first message comprising (i) a first asymmetric ciphertext, and (ii) a first symmetric ciphertext of a first plaintext, the first plaintext comprising the device ephemeral public key and the device static public key; and b) receive, from the network, a second message comprising a second symmetric ciphertext a third symmetric ciphertext, and a fourth symmetric ciphertext; and a random access memory (RAM) storing computer executable instructions configured to: a) conduct a KEM encapsulation (ENCAPS) function with the server static public key to generate a first shared secret and a first asymmetric ciphertext; b) generate a first symmetric ciphering key using at least the first shared secret; c) encrypt, with the first symmetric ciphering key, the first plaintext into the first symmetric ciphertext; d) decrypt, with the first symmetric ciphering key, the second symmetric ciphertext into a second asymmetric ciphertext;
15
A method for a device to securely communicate with a network, the method performed by the device, the method comprising: a) storing (i) a set of key encapsulation mechanism (KEM) algorithms comprising a first KEM algorithm, (ii) a server static public key, and (iii) a device static public key; b) generating a device ephemeral private key and a corresponding device ephemeral public key for the first KEM algorithm; c) conducting a KEM encapsulation (ENCAPS) function with the server static public key to generate a first shared secret and a first asymmetric ciphertext; d) generating a first symmetric ciphering key using at least the first shared secret; e) encrypting a first plaintext into a first symmetric ciphertext, wherein the first plaintext comprises the device ephemeral public key, the device static public key, an identifier for the first KEM algorithm, and the set of KEM algorithms; f) sending, to the network via a network interface, a first message comprising the first asymmetric ciphertext and the first symmetric ciphertext; g) receiving, from the network, a second message comprising a second symmetric ciphertext, a third symmetric ciphertext, and a fourth symmetric ciphertext;
e) conduct a first KEM decapsulation (DECAPS) function to generate a second shared secret with the second asymmetric ciphertext and the device ephemeral private key; f) generate a second symmetric ciphering key using at least the first shared secret and the second shared secret; g) decrypt, with the second symmetric ciphering key, the third symmetric ciphertext into a third asymmetric ciphertext; h) conduct a second KEM decapsulation (DECAPS) function to generate a third shared secret with the third asymmetric ciphertext and the device static private key; i) generate a third symmetric ciphering key using at least the first shared secret and the second shared secret and the third shared secret; and j) decrypt, with the third symmetric ciphering key, the fourth symmetric ciphertext into a second plaintext.
h) decrypting the second symmetric ciphertext with the first symmetric ciphering key in order to read a second asymmetric ciphertext; i) conducting a first KEM decapsulation (DECAPS) function with the device ephemeral private key and the first KEM algorithm and the second asymmetric ciphertext to generate a second shared secret; j) generating a second symmetric ciphering key using at least the first shared secret and the second shared secret; k) decrypting the third symmetric ciphertext with the second symmetric ciphering key in order to read a third asymmetric ciphertext; l) conducting a second KEM DECAPS function with the device static private key and the third asymmetric ciphertext to generate a third shared secret; m) generating a third symmetric ciphering key using at least the first shared secret and the second shared secret and the third shared secret; and n) decrypting the fourth symmetric ciphertext with the third symmetric ciphering key in order to read a second plaintext.
2
The device of claim 1, wherein the second plaintext comprises a server ephemeral public key.
16
The method of claim 15, wherein the second plaintext includes a server ephemeral public key and an identity for second KEM algorithm, wherein the set of KEM algorithms includes the second KEM algorithm, and wherein the server ephemeral public key supports the second KEM algorithm.
3
The device of claim 2, further comprising the computer executable instructions configured to k) conduct a second KEM ENCAPS function with the server ephemeral pubic key to generate a fourth shared secret and fourth asymmetric ciphertext.
17
The method of claim 15, further comprising conducting a second KEM ENCAPS function with the server ephemeral public key and the second KEM algorithm in order to generate a fourth asymmetric ciphertext and a fourth shared secret.
5
The device of claim 1, wherein the first symmetric ciphering key comprises a first portion and a second portion, wherein, in step c) for the computer executable instructions, the device encrypts with the first portion of the first symmetric ciphering key, and wherein, in step d) for the computer executable instructions, the device decrypts the second symmetric ciphertext with the second portion of the first symmetric ciphering key.
20
The method of claim 15, wherein the first symmetric ciphering key comprises a first portion and a second portion, wherein in step e) the device encrypts with the first portion of the first symmetric ciphering key, and wherein in step h) the device decrypts the second symmetric ciphertext with the second portion of the first symmetric ciphering key.
6
The device of claim 1, further comprising in step f) for the computer executable instructions, generating the second symmetric ciphering key using a HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with at least the first shared secret and the second shared secret.
21
The method of claim 15, further comprising in step j), generating the second symmetric ciphering key using a HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with at least the first shared secret and the second shared secret.
7
The device of claim 6, further comprising generating a message authentication code (MAC) key and an initialization vector with the HKDF.
22
The method of claim 21, further comprising generating a message authentication code (MAC) key and an initialization vector with the HKDF.
8
A server configured to securely communicate with a device, the server comprising: a) at least one processor; b) at least one nonvolatile memory operatively connected to the at least one processor and having stored thereon instructions that, when executed by the at least one processor, cause the server to perform a method of securely communicating with the device, the method comprising: 1. storing in nonvolatile memory a first key encapsulation mechanism (KEM) for a first KEM algorithm, a second key encapsulation mechanism (KEM) for a second KEM algorithm, and a server static private key for the first KEM algorithm; 2. receiving a first message from the device, wherein the first message includes a first asymmetric ciphertext and a first symmetric ciphertext; 3. conducting a first KEM decapsulation (DECAPS) function with the first asymmetric ciphertext, the first KEM algorithm, and the server static private key in order to generate a first shared secret; 4. generating a first symmetric ciphering key using the first shared secret key; 5. decrypting the first symmetric ciphertext using the first symmetric ciphering key, wherein a first plaintext from the first symmetric ciphertext includes a device ephemeral public key and a device static public key;
1
A method for a server to securely communicate with a device, the method performed by the server, the method comprising: a) storing in nonvolatile memory a first key encapsulation mechanism (KEM) for a first KEM algorithm, a second key encapsulation mechanism (KEM) for a second KEM algorithm, and a server static private key for the first KEM algorithm; b) receiving a first message from the device, wherein the first message includes a first asymmetric ciphertext and a first symmetric ciphertext; c) conducting a first KEM decapsulation (DECAPS) function with the first asymmetric ciphertext, the first KEM algorithm, and the server static private key in order to generate a first shared secret; d) generating a first symmetric ciphering key using a first shared secret key; e) decrypting the first symmetric ciphertext using the first symmetric ciphering key, wherein a first plaintext from the first symmetric ciphertext includes a device ephemeral public key and a device static public key;
6. conducting a first KEM encapsulation (ENCAPS) function with the device ephemeral public key in order to generate a second shared secret and a second asymmetric ciphertext; 7. conducting a second KEM ENCAPS function with the device static public key and the second KEM algorithm in order to generate a third shared secret key and a third asymmetric ciphertext; 8. generating a second symmetric ciphering key using at least the second shared secret and the first shared secret key; 9. generating a third symmetric ciphering key using at least the third shared secret and the first shared secret key and the second shared secret key; 10. generating a server ephemeral public key and a server ephemeral private key; 11. encrypting (i) the second asymmetric ciphertext into a second symmetric ciphertext using the first symmetric ciphering key, (ii) the third asymmetric ciphertext into a third symmetric ciphertext using the second symmetric ciphering key, and (iii) at least the server ephemeral public key into a fourth symmetric ciphertext using the third symmetric ciphering key; and 12. sending a second message to the device, wherein the second message includes the second symmetric ciphertext and the third symmetric ciphertext and the fourth symmetric ciphertext.
f) conducting a first KEM encapsulation (ENCAPS) function with the device ephemeral public key in order to generate a second shared secret and a second asymmetric ciphertext; g) conducting a second KEM ENCAPS function with the device static public key and the second KEM algorithm in order to generate a third shared secret key and a third asymmetric ciphertext; h) generating a second symmetric ciphering key using at least the second shared secret and the first shared secret key; i) generating a third symmetric ciphering key using at least a third shared secret and a first shared secret key and a second shared secret key; j) generating a server ephemeral public key and a server ephemeral private key; k) encrypting (i) the second asymmetric ciphertext into a second symmetric ciphertext using the first symmetric ciphering key, (ii) the third asymmetric ciphertext into a third symmetric ciphertext using the second symmetric ciphering key, and (iii) at least the server ephemeral public key into a fourth symmetric ciphertext using the third symmetric ciphering key; and l) sending a second message to the device, wherein the second message includes the second symmetric ciphertext and the third symmetric ciphertext and the fourth symmetric ciphertext.
9
The server of claim 8, wherein the first KEM algorithm and the second KEM algorithm comprise different algorithm types.
2
The method of claim 1, wherein the first KEM algorithm and the second KEM algorithm comprise different algorithm types.
10
The server of claim 8, wherein the first KEM algorithm comprises a first algorithm type for lattice-based cryptography and the second KEM algorithm comprises a second algorithm type for code-based cryptography.
3
The method of claim 2, wherein the first KEM algorithm comprises a first algorithm type for lattice-based cryptography and the second KEM algorithm comprises a second algorithm type for code-based cryptography
11
The server of claim 8, wherein the first KEM algorithm comprises a first algorithm type for code-based cryptography and the second KEM algorithm comprises a second algorithm type for lattice-based cryptography.
4
The method of claim 2, wherein the first KEM algorithm comprises a first algorithm type for code-based cryptography and the second KEM algorithm comprises a second algorithm type for lattice-based cryptography.
12
The server of claim 8, wherein the first symmetric ciphering key comprises a first portion and a second portion, wherein in step 5) the server decrypts with the first portion of the first symmetric ciphering key, and wherein in step 11) the server encrypts the second asymmetric ciphertext with the second portion of the first symmetric ciphering key.
5
The method of claim 1, wherein the first symmetric ciphering key comprises a first portion and a second portion, wherein in step e) the server decrypts with the first portion of the first symmetric ciphering key, and wherein in step k) the server encrypts the second asymmetric ciphertext with the second portion of the first symmetric ciphering key.
13
The server of claim 8, further comprising in step 8), generating the second symmetric ciphering key using a HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with at least the first shared secret and the second shared secret.
6
The method of claim 1, further comprising in step h), generating the second symmetric ciphering key using a HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with at least the first shared secret and the second shared secret.
14
The server of claim 13, further comprising in step 8) generating a message authentication code (MAC) key and an initialization vector with the HKDF.
7
The method of claim 6, further comprising in step h) generating a message authentication code (MAC) key and an initialization vector with the HKDF.
Claims 1-14: Object
Claims 1-14 are objected to as being allowable if the Double Patenting Rejection is overcome. The following is an examiner’s statement of reason for allowance.
The reference Kalach et al. (US PAT. # US 10,218,504) discloses, storing in a nonvolatile memory key exchange mechanism (KEM) (Fig. 2(210A, 210B, CL(7), LN(18-55), CL(9), LN(41-49)). Kalach further discloses a node 102 can be a server node or a client node and generating an asymmetric key pair where a public key corresponds to a private key. (Fig. 1(102, 104), CL(3), LN(21-23), Fig. 2(212B), CL(7), LN(56-57), Fig. 3A (316,318, 320), Fig. 4A (408,416,418,420,410,412,414), CL(8), LN(1-9), CL(10), LN(23-36)). The device transmits, the device ephemeral public key along with KEM parameters. (Fig. 3A(322), CL(10), LN(40-67), The reference further teaches, selecting (i) a second subset of both the first set of KEM parameters and the second set of KEM parameters, and (ii) the server public key for the second subset (CL(12), LN(7-15)). At 328, the node 302B computes a shared secret value based on the image curve E.sub.AB. The shared secret value is "shared" in the sense that the secret value is known (or to be known) by Alice and Bob. In the example shown in FIGS. 3A-3B, the shared secret is the j-invariant j(E.sub.AB) of the image curve E.sub.AB. The j-invariant of an elliptic curve is an element of the underlying finite field F.sub.p.sub.2, and it can be computed, for example, from the coefficients that define the elliptic curve. For example, the j-invariant of a Montgomery curve (By.sup.2=x.sup.3+Ax.sup.2+x) is given by j=256(A.sup.2-3).sup.2/(A.sup.2-A). In this example, the j-invariant j(E.sub.AB) can be represented as a pair of integer values each between 0 and p. In some implementations, the j-invariant can be computed or stored in another manner. In some cases, another value is used as the shared secret, for instance, another value that is based on or related to the j-invariant j(E.sub.AB) of the image curve E.sub.AB. (CL(12), LN(16-31)). Thus teaching generating a first shared secret and deriving a first symmetric key using the first shared secret. The second subset is encrypted with first symmetric ciphertext to generate first symmetric ciphertext. This generated first symmetric ciphertext is transmitted to the device.
The reference by Frank Coulier (US PGPUB. # US 2002/0166048) discloses, the authentication key to be used for mutually authenticating the server and the client is created. First, the client and server exchange some information in step 202. Then, the client and server each use the same shared secret to independently compute a symmetric encryption key in steps 203 and 204. This symmetric encryption key is the authentication key. A shared secret as used herein is generally defined as a secret possessed by the client and the server. In one embodiment, a third party such as a certificate authority may possess the secret. However, a secret known to a third party is still considered secret from the public at large. In one embodiment, the shared secret is not transferred between the server and the client. (¶24, Fig. 2(205)). The client and server are both authenticated. First, the server encrypts server authentication information in step 205. The server constructs this server authentication information so the client may verify its correctness. The server then encrypts the server authentication information with the authentication key generated in the previous step and transmits the encrypted server authentication information to the client in step 206. By successfully decrypting this encrypted server authentication information and verifying its correctness in step 207, the client authenticates the server end of the SSL connection and establishes the trustworthiness of the SSL connection. Next, the client encrypts client authentication information in step 208 with the same authentication key generated in step 203 and sends the encrypted client authentication information to the server in step 209. The server then decrypts the encrypted client authentication information received from the client and verifies its correctness in step 210. By successfully decrypting and verifying the encrypted client authentication information, the server authenticates the client. The client authentication information can include the username and/or part of the information exchanged between client and server earlier on. The authentication key can be used to encrypt any further communication between the server and the client in addition to the encryption already provided by the SSL connection. (Fig. 2(209, 210), ¶25).
The reference by Laila El Almani (US PGPUB. # US 2013/0051551) discloses, the sender uses the first encryption algoritm to encrypt plaintext m with Epk to get ciphertext e, e=E.Encrypt(m), step S1. The sender generates a key k and its encapsulation c using the encapsulation algoritm and Kpk, (c,k)=K.Encapsulate( ) step S2. Then the sender produces a signature on (e,c) using Ssk, s=S.sign(e,c), step S3. Finally, the sender uses the second encryption scheme to encrypt s with the key k, e kd=D.Encrypt(s), step S4. The signcryption of m is formed by (e,c,e_d), step S5. The sender then sends the signcryption (e,c,e_d) to the receiver, step S6. (Fig. 2(S11), ¶56-¶57). StE is illustrated in FIG. 1. A random number r, KEM's encapsulation algorithm and a public key pk are used to obtain a session key k and its encapsulation c. The sender then uses its secret key Ssk to sign a concatenation of the plaintext m and the encapsulation c, thus obtaining signature s. (not illustrated). The DEM encryption algorithm and the session key k are used to encrypt (m,s) and obtain e. The pair (c,e) forms the signcryption of m. To "unsigncrypt" (c,e), the session key k is recovered from its encapsulation c using KEM's decapsulation algorithm and the private key. Then DEM's decryption algorithm and the session key k are used to decrypt e to obtain (m,s). Finally, the validity of the signature s may be verified using the sender's public key. (¶17). The receiver uses Esk to decrypt e to get m, m=E.Decrypt(e), step S7. Then, the receiver retrieves k from c using Ksk, k=K.Decapsulate(c), step S8, and recovers s by decrypting e_d using the key k, s=D.Decrypt(e_d), step S9. Finally, the receiver uses Spk to check that the signature s is valid on (e,c) using S.Verify(s), step S10. (Fig. 2(S8), ¶58).
The reference by Holyfield et al. (US PGPUB. # US 2015/0271146) discloses, the URL used in the previous example is used to access the system using a standard web browser and a browser-based API written in JavaScript. This API is included as part of the web page used to access the package and runs locally within the web browser on the recipient's computer. The browser API re-calculates the decryption key using the server-supplied server secret and the client secret, which is read from the URL fragment identifier in the browser address bar. Once the recipient has re-calculated the encryption key, the data is decrypted and saved locally on the recipient's computer. (¶36).
However, none of the references 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.
Pointcheval et al. (US PGPUB. # US 2021/0083862) discloses, a key agreement system, method, and apparatus are provided. The method includes: generating, by a first device, a private-public key pair, sending a public key in the private-public key pair to a second device, and receiving a ciphertext and a commitment value; obtaining, by the first device, a first result, obtaining an original key based on a private key in the private-public key pair and the ciphertext, determining a second bit string based on some bits in the original key, calculating a second result based on the second bit string and the first result, and sending the second result to the second device; and receiving, by the first device, an opening value, performing authentication on the second device based on the opening value and the commitment value to obtain an authentication result, and generating a session key used to communicate with the second device.
Jacobs et al. (US PGPUB. # US 2020/0235929) discloses, a cryptographic engine is to generate a sealed encrypted message to be transmitted via the network interface, the sealed encrypted message encrypted on behalf of the at least one application processor and includes a signature to enable integrity verification of the sealed encrypted message, the signature generated based on an identity key of the electronic device and data including ciphertext of the encrypted message and a public key of a recipient of the sealed encrypted message.
Harri Hursti (US PGPUB. # US 2014/0195804) discloses, a ciphertext key suitable for use by a first encryption algorithm is generated. Plaintext data is encrypted according to the first encryption algorithm using the first encryption key. The ciphertext key is then encrypted using a second encryption algorithm configured with a recipient key to generate a recipient wrapper. The ciphertext data and the recipient wrapper are then transmitted to a remote computing device via a network.
Pahl et al. (US PAT. # US 8,782,774) discloses, a server establishes a secure session with a client device where a private key used in the handshake when establishing the secure session is stored in a different server. During the handshake procedure, the server receives a premaster secret that has been encrypted using a public key bound with a domain for which the client device is attempting to establish a secure session with. The server transmits the encrypted premaster secret to another server for decryption. The server receives the decrypted premaster secret and continues with the handshake procedure including generating a master secret from the decrypted premaster secret and generating one or more session keys that are used in the secure session for encrypting and decrypting communication between the client device and the server.
GARCIA MORCHON et al. (US PGPUB. # US 2020/0304305) discloses, an electronic network node (110) configured for a cryptographic operation. The network node obtains a shared matrix (A) by selecting integers, polynomials, and/or polynomial-coefficients from a shared pool, the shared pool being shared with the second network node, wherein the selecting is done according to one or more selection functions.
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