Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
2. NO restrictions warranted at initial time of filing for patent.
Priority
3. Applicant claims domestic priority under 35 USC 119e to provisional application filed on 06/08/2018.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 06/24/2025, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Oath/Declaration
5. Applicant’s Oath was filed on 02/04/2025.
Drawings
6. Applicant’s drawings filed on 02/04/2025 has been inspected and is in compliance with MPEP 608.01.
Specification
7. Applicant’s specification filed on 02/04/2025 has been inspected and is in compliance with MPEP 608.02.
Claim Objections
8. NO objections warranted at initial time of filing for patent.
Remarks
9. Examiner request Applicant review relevant prior art under the conclusion of this office action.
Allowable Subject Matter
10. Claims 29, 30, 39 and 40 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 21-40 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 21, 22, 26-32, and 36-40 of co-assigned Patented Application no. 12248596. Although the claims at issue are not identical, they are not patentably distinct from each other because both the co-assigned Application claims are almost the same in scope.
Instant Claims 21-40
Patent No. ‘596
21. A system comprising: a plurality of storage devices, wherein a quantity of storage devices within any given node of a plurality of nodes does not exceed a predefined threshold; and a processor configured to organize one or more failure-protected data arrangements within the plurality of storage devices.
22. The system of claim 21, wherein the processor is operable to decrypt data as it leaves the system.
23. The system of claim 21, wherein the processor is operable to encrypt data according to a file key.
24. The system of claim 23, wherein the file key is rotated when a file is copied.
25. The system of claim 23, wherein all failure-protected data arrangements, built by a plurality of buckets, are associated with a filesystem key.
26. The system of claim 25, wherein the file key is encrypted by the filesystem key.
27. The system of claim 25, wherein the file key is re-encrypted when the filesystem key is rotated.
28. The system of claim 21, wherein the system comprises a cluster of computing devices, and wherein the cluster of computing devices is associated with a cluster key.
29. The system of claim 28, wherein the processor registers a long-term key with a leader of the cluster when the system joins the cluster of computing devices.
30. The system of claim 29, wherein prior to a transfer of the data, a session key is negotiated using an ephemeral key pair signed with the long-term key.
31. A method comprising: distributing a plurality of storage devices, such that a quantity of storage devices within any given node of a plurality of nodes does not exceed a predefined threshold; and building, via a processor, one or more failure-protected data arrangements within the plurality of storage devices.
32. The method of claim 31, wherein the method comprises decrypting data, via the processor, as it leaves a storage device.
33. The method of claim 31, wherein the processor encrypts the data according to a file key.
34. The method of claim 33, wherein the file key is rotated when a file is copied.
35. The method of claim 33, wherein all failure-protected data arrangements, built by a plurality of buckets in the processor, are associated with a filesystem key.
36. The method of claim 35, wherein the file key is encrypted by the filesystem key.
37. The method of claim 35, wherein the file key is re-encrypted when the filesystem key is rotated.
38. The method of claim 31, wherein a cluster of computing devices is associated with a cluster key.
39. The method of claim 38, wherein the method comprises: registering a long-term key with a leader of the cluster when the computing device joins the cluster of computing devices.
40. The method of claim 39, wherein the method comprises: negotiating a session key, prior to a transfer of the data, using an ephemeral key pair signed with the long-term key
1. A system comprising: a processor operable to configure a plurality of failure-protected stripes in a plurality of storage devices, wherein: the plurality of storage devices are distributed such that at most an allowed number of storage devices are within any particular node of a plurality of nodes, the processor is operable to encrypt data according to a file key, the file key is rotated when a file is copied, and all failure-protected stripes built by a plurality of buckets are associated with a filesystem key.
2. The system of claim 1, wherein the processor is operable to decrypt data as it leaves the system.
3. The system of claim 1, wherein the file key is encrypted by the filesystem key.
4. The system of claim 1, wherein the file key is re-encrypted when the filesystem key is rotated.
5. The system of claim 1, wherein the system comprises a cluster of computing devices, and wherein the cluster of computing devices is associated with a cluster key.
6. The system of claim 5, wherein the processor registers a long-term key with a leader of the cluster when the system joins the cluster of computing devices.
7. The system of claim 6, wherein prior to a transfer of the data, a session key is negotiated using an ephemeral key pair signed with the long-term key.
8. A method comprising: building, via a processor, a plurality of failure-protected stripes in a plurality of storage devices; distributing the plurality of storage devices such that at most an allowed number of storage devices are within any particular node of a plurality of nodes encrypting data, via the processor, according to a file key; rotating the file key when a file is copied; and associating all failure-protected stripes, built by a plurality of buckets, with a filesystem key.
9. The method of claim 8, wherein the method comprises decrypting data, via the processor, as it leaves a storage device.
10. The method of claim 8, wherein the file key is encrypted by the filesystem key.
11. The method of claim 8, wherein the file key is re-encrypted when the filesystem key is rotated.
12. The method of claim 8, wherein a cluster of computing devices is associated with a cluster key.
13. The method of claim 12, wherein the method comprises: registering a long-term key with a leader of the cluster when the computing device joins the cluster of computing devices.
14. The method of claim 13, wherein the method comprises: negotiating a session key, prior to a transfer of the data, using an ephemeral key pair signed with the long-term key.
15. A system comprising: a processor operable to configure a plurality of failure-protected stripes in a plurality of storage devices; and a cluster of computing devices associated with a cluster key, wherein: the plurality of storage devices are distributed such that at most an allowed number of storage devices are within any particular node of a plurality of nodes, and the processor is configured to register a long-term key with a leader of the cluster when the system joins the cluster of computing devices.
16. The system of claim 15, wherein the processor is operable to decrypt data as it leaves the system.
17. The system of claim 15, wherein the processor is operable to encrypt data according to a file key.
18. The system of claim 17, wherein the file key is rotated when a file is copied.
19. The system of claim 17, wherein all failure-protected stripes built by a plurality of buckets are associated with a filesystem key.
20. The system of claim 19, wherein the file key is encrypted by the filesystem key.
21. The system of claim 19, wherein the file key is re-encrypted when the filesystem key is rotated.
22. The system of claim 15, wherein prior to a transfer of the data, a session key is negotiated using an ephemeral key pair signed with the long-term key.
23. A method comprising: building, via a processor, a plurality of failure-protected stripes in a plurality of storage devices; distributing the plurality of storage devices such that at most an allowed number of storage devices are within any particular node of a plurality of nodes; associating a cluster of computing devices with a cluster key; and registering a long-term key with a leader of the cluster when the computing device joins the cluster of computing devices.
24. The method of claim 23, wherein the method comprises decrypting data, via the processor, as it leaves a storage device.
25. The method of claim 23, wherein the processor encrypts the data according to a file key.
26. The method of claim 25, wherein the file key is rotated when a file is copied.
27. The method of claim 25, wherein all failure-protected stripes built by a plurality of buckets in the processor are associated with a filesystem key.
28. The method of claim 27, wherein the file key is encrypted by the filesystem key.
29. The method of claim 27, wherein the file key is re-encrypted when the filesystem key is rotated.
30. The method of claim 23, wherein the method comprises: negotiating a session key, prior to a transfer of the data, using an ephemeral key pair signed with the long-term key.
The instant application claims 21-40 and Patent No. ‘596 are BOTH directed towards a method and system of distributing file system in a failure-protected data arrangements using encrypt/decrypt operations
One of ordinary skill in the art would understand from the teachings found in Patented No. ‘596 would not be significantly different from those found in the Instant application relates to a method and system of distributing file system in a failure-protected data arrangements using encrypt/decrypt operations. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Therefore, it would have been obvious to one of ordinary skill in the art to modifyinstant Application claims 21-40 with the additional limitation of so to obtain Patented App ‘596 claims 1-30 as claimed.
Allowance of application claim 11 would result in an unjustified time-wiseextension of the monopoly granted for the invention defined by co-assigned Application and Patent No. ‘596 claim 1. Therefore, the provisional obviousness-type double patenting is appropriate because the conflicting claims have not in fact been patented. Application claim 1 corresponds to co-assigned Patent No. ‘596 claim 1.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
11. Claims 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent No 9448887 hereinafter Ben.
As per claim 21, Ben discloses:
A system (Fig 3, Col.3 Lines 64- Col. 4 Line 8 “Each VFS front end instance 220.sub.s (s an integer, where 1≦s≦S if at least one front end instance is present on compute node 104.sub.n) provides an interface for routing file system requests to an appropriate VFS back end instance (running on a VFS node), where the file system requests may originate from one or more of the client processes 218, one or more of the VMs and/or containers 216, and/or the OS and/or hypervisor 212.”) comprising:
a plurality of storage devices, wherein a quantity of storage devices within any given node of a plurality of nodes does not exceed a predefined threshold (Col. 7 Line 6-13“ Although D=7 and N=5 in the simple example of FIG. 5C, in an actual implementation D may be much larger than N (e.g., by a multiple of an integer greater than 1 and possibly as high as many orders of magnitude) and the two values may be chosen such that the probability of any two chunk stripes 520 of a single DFRAS residing on the same set of N storage devices 306 (or, more generally, on the same set of N failure domains) is below a desired threshold.”)
and a processor configured to organize one or more failure-protected data arrangements within the plurality of storage devices (Col. 5 Lines 43-52 “As shown in FIG. 5A, the physical storage is organized into a plurality of distributed failure resilient address spaces (DFRASs) 514. In each of which comprises a plurality of chunks 510, which in turn comprises a plurality of blocks 512. The organization of blocks 512 into chunks 510 is only a convenience in some implementations and may not be done in all implementations. Each block 512 stores committed data 514 (which may take on various states, discussed below) and/or metadata 504 that describes committed data 514.”).
As per claim 31, the implementation of the system of claim 21 will execute the system of claim 31. The claim is analyzed with respect to claim 21.
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.
The factual inquiries 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.
12. Claims 22, 23, 32 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No 9448887 hereinafter Ben in view of U.S. Patent No. 10467422 hereinafter Roth.
As per claim 22, Ben discloses:
The system of claim 21, wherein the processor is operable (Col. 3 Lines 19-21)
Ben does not disclose:
to decrypt data as it leaves the system
Roth discloses:
to decrypt data as it leaves the system (Fig. 5, Col. 15 Lines 13-16 “As illustrated in FIG. 5, the data service frontend is configured to receive a GET request from a user and provide plaintext in response.” Col. 15 Lines 31-35 “The cryptographic service can determine whether the authentication proof is sufficient to allow the operation and, if the authentication proof is sufficient, decrypt the envelope key. The decrypted envelope key can be sent back to the data service, which can use the key to decrypt the encrypted plaintext. The data service can then discard the decrypted plaintext key.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Ben to include decrypting data as it leaves the system, as taught by Roth.
The motivation would have been to control cryptographic operations entering and exiting a system.
As per claim 23, Ben discloses:
The system of claim 21, wherein the processor is operable (Col. 3 Lines 19-21)
Ben does not disclose:
to encrypt data according to a file key
Roth discloses:
to encrypt data according to a file key (Col. 14 Lines 44-57 “The cryptography service may generate or otherwise obtain a key, encrypt the obtained key or otherwise obtain the encrypted key (e.g., from memory), and provide the obtained key and the encrypted obtained key in response to the request. The obtained key may be encrypted using a key identified in the request to the cryptography service. The obtained key may be used to encrypt the plaintext and, after encrypting the plaintext, the obtained key may be discarded (e.g., irrevocably removed from memory). In alternate embodiment, a system performing the process 400 may generate or otherwise obtain the key used to perform the one or more cryptographic operations, provide the obtained key to the cryptography service to be encrypted.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Ben to include encrypting data according to a file key, as taught by Roth.
The motivation would have been to control cryptographic operations entering and exiting a system.
As per claim 32, the claim is analyzed with respect to claim 22.
As per claim 33, the claim is analyzed with respect to claim 23.
13. Claims 24-27 and 34-37 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No 9448887 hereinafter Ben in view of Roth, and further in view of U.S. Publication No. 20140019769 hereinafter Pittelko.
As per claim 24, Ben in view of Roth discloses:
The system of claim 23, wherein the file key (Roth Col. 14 Lines 44-57, Though Ben discloses file data, Roth discloses a file key. The motivation would have been to control cryptographic operations entering and exiting a system.)
Ben in view of Roth does not disclose:
file key is rotated when a file is copied
Pittelko discloses:
file key is rotated when a file is copied (para 0007 “In some embodiments, the encryption key is changed each time a snapshot is committed to disk as read-only, such that each snapshot is associated with a corresponding different decryption key identifier. In some embodiments, a snapshot may identify only the write data for a volume between the times when it is committed to disk as read-only and when a previous snapshot was committed to disk as read-only.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Ben in view of Roth to include file key is rotated when a file is copied, as taught by Pittelko.
The motivation would have been to improved encryption and decryption methods utilizing cycling or changing keys which are cognizant of the need or desire to maintain accessibility of historical snapshots or PITCs and their corresponding associations with the cycling or changing encryption/decryption keys (Pittelko paragraph 0006).
As per claim 25, Ben in view of Roth and Pittelko discloses:
The system of claim 23, wherein all failure-protected data arrangements, built by a plurality of buckets (Ben Col. 4 Lines 53-59 “Each VFS back end instance 222.sub.x (x an integer, where 1≦x≦X if at least one back end instance is present on VFS node 120.sub.j) services the file system requests that it receives and carries out tasks to otherwise manage the virtual file system (e.g., load balancing, journaling, maintaining metadata, caching, moving of data between tiers, removing stale data, correcting corrupted data, etc.) ),
are associated with a filesystem key (Roth Fig. 5, element data service backend storage system, Col. 14 Lines 44-57 “The cryptography service may generate or otherwise obtain a key, encrypt the obtained key or otherwise obtain the encrypted key (e.g., from memory), and provide the obtained key and the encrypted obtained key in response to the request. The obtained key may be encrypted using a key identified in the request to the cryptography service. The obtained key may be used to encrypt the plaintext and, after encrypting the plaintext, the obtained key may be discarded (e.g., irrevocably removed from memory). In alternate embodiment, a system performing the process 400 may generate or otherwise obtain the key used to perform the one or more cryptographic operations, provide the obtained key to the cryptography service to be encrypted.” Though Ben discloses buckets/backend instance for file systems and requests, Roth discloses for a backend instance are associated with a filesystem key. The motivation would have been to control cryptographic operations entering and exiting a system.).
As per claim 26, Ben in view of Roth and Pittelko discloses:
The system of claim 25, wherein the file key is encrypted by the filesystem key (Roth Col. 12 Lines 29-46 “In an embodiment, the one or more cryptographic operations can include an operation to generate an envelope key to be used to encrypt the plaintext. The envelope key can be a randomly generated symmetric key or a private key of a key pair. After the envelope key is generated, the cryptographic service can encrypt the envelope key with the master key specified in the API call and cause the encrypted envelope key to be persistently stored (e.g., by storing the encrypted key in a storage service or some other durable storage) or discarded. In addition, the cryptographic service can send a plaintext version of the envelope key as well as and the encrypted envelope key to the data service frontend. The data service can then use the plaintext version of the envelope key to encrypt the plaintext (i.e., the data associated with the encryption request) and cause the envelope key to be stored in persistent storage in association with an identifier for the master key used to encrypt the envelope key.” Though Ben discloses buckets/backend instance for file system and requests, Roth discloses wherein the file key is encrypted by the filesystem key. The motivation would have been to control cryptographic operations entering and exiting a system.).
As per claim 27, Ben in view of Roth and Pittelko discloses:
The system of claim 25, wherein the file key is re-encrypted when the filesystem key is rotated (Fig. 26, Col. 24 Lines 27-40 “If determined 2608 that the counter exceeds the threshold, in an embodiment, the process 2600 includes obtaining 2610 a new key. Obtaining the new key may be performed in any suitable manner. For example, if the process 2600 is performed by a security module, obtaining the new key may include generating the new key or obtaining the new key from another security module, which may be orchestrated by an operator of the cryptography service. Passing keys from one security module to the other may be performed by encrypting the key with a key to which the providing and receiving security modules have access. The security module performing the process 2600 may receive and decrypt the encrypted key. Public-key key exchange techniques may also be used.” Though Ben discloses buckets/backend instance for file system and requests, Roth discloses wherein the file key is re-encrypted when the filesystem key is rotated. The motivation would have been to control cryptographic operations entering and exiting a system.).
As per claim 34, the claim is analyzed with respect to claim 24.
As per claim 35, the claim is analyzed with respect to claim 25.
As per claim 36, the claim is analyzed with respect to claim 26.
As per claim 37, the claim is analyzed with respect to claim 27.
14. Claims 28 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No 9448887 hereinafter Ben in view of Roth, and further in view of U.S. Publication No. 20130054966 hereinafter Clay.
As per claim 28, Ben in view of Roth discloses:
The system of claim 21, wherein the system comprises a cluster of computing devices (Ben Fig. 1)
Ben in view of Roth does not disclose:
wherein the cluster of computing devices is associated with a cluster key
Clay discloses:
wherein the cluster of computing devices is associated with a cluster key (para 0041 “Accordingly, when a third node (e.g., a network-connected device similar to network-connected devices 110 and 120 of FIG. 1A) is to join the cluster formed to comprise network-connected devices 110 and 120 in FIG. 2, such a joining node may perform the mutual authentication and cluster secret sharing processes (e.g., perform processes 203-207 of FIG. 2) with any single node already part of the cluster (e.g., either network-connected device 110 or network-connected device 120) and establish trust and the ability to securely communicate with every node of the cluster (e.g., both network-connected device 110 and network-connected device 120). That is, since every node that has successfully joined the cluster has the cluster secret (e.g., cluster key), any node can communicate with any other node in the cluster. This allows unicast and multicast messages to be used for intra-cluster communication.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Ben in view of Roth to include wherein the cluster of computing devices is associated with a cluster key, as taught by Clay.
The motivation would have been to establish trust and the ability to securely communicate with every node of the cluster (Clay paragraph 0041).
As per claim 38, the claim is analyzed with respect to claim 28.
Conclusion
15. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. U.S. Publication No. 20190007208 discloses on paragraph 0235 “ FIG. 11 shows a method 400 for encrypting data in a distributed storage environment such as the cloud storage system (CSS) 100. At 402, control receives a request at the front end layer 116 to write data. At 404, control compresses the data at the front end layer 116. At 406, control determines whether encryption is enabled. At 408, control encrypts the compressed data at the front end layer 116 if encryption is enabled. Control embeds the encrypted data with encryption information (e.g., seed, key version, etc.) that can be utilized when decrypting the encrypted data. The seed is stored in unencrypted form and is placed in a data header associated with the encrypted data, which is stored in the stream layer 112. At 410, control partitions the compressed or encrypted data at the partition layer 114. At 412, control stores the compressed or encrypted data in extents at the stream layer 112. At 414, control determines whether to perform garbage collection (i.e., defragmentation). At 416, control performs garbage collection (i.e., defragmentation) if necessary.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499
Prosecution Insights