DETAILED ACTION
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 .
2. In view of the Appeal Brief conference decision on February 04, 2026, PROSECUTION IS HEREBY REOPENED. New Grounds of rejection are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/AMY NG/Supervisory Patent Examiner, Art Unit 2164
Response to Amendment
3. This Office Action is issued in response to the Appeal Brief Conference decision on June 19, 2026.
4. Claims 21-40 are pending of which claims 21, 31, and 36 are in independent form.5. Claims 1-20 are cancelled by the applicant.
Response to Arguments
6. Applicant's arguments filed on April 06, 2026 have been fully considered but they are not persuasive. 7. Applicant argues that claims 36-40 expressly recites a “machine readable storage medium that stores program code” and therefore cannot reasonably be interpreted as propagating signal. Applicant further argues that the rejection improperly reads the “storage medium” limitation out of the claim and is inconsistent with In re Nuijten. Examiner has carefully considered the argument but respectfully disagrees.
The claims recite "a machine readable storage medium." Under the broadest reasonable interpretation, this language does not expressly exclude transitory embodiments, such as propagating signals, absent an express definition or disclaimer in the specification limiting the claimed medium to non-transitory storage media. See In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007).
The originally filed specification (paragraph [0059]) states: "The machine-readable medium can include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards or other type of media/machine-readable medium suitable for storing electronic instructions."
Although the specification lists examples of physical storage media, it does not expressly define the term "machine readable storage medium" as being limited to non-transitory media, nor does it expressly disclaim propagating signals or other transitory embodiments. The open-ended language "include, but is not limited to" and "other type of media/machine-readable medium" does not provide an explicit definition restricting the claim to statutory storage media.
Additionally, during prosecution, Applicant previously amended the claims to recite "a machine readable storage medium, and not a transitory electromagnetic wave," thereby expressly excluding transitory embodiments. Applicant later removed that limiting language and returned to the broader recitation of "a machine readable storage medium." The claims presently under examination therefore no longer contain an express exclusion of transitory subject matter.
Accordingly, under the broadest reasonable interpretation, the present claims are reasonably interpreted as encompassing transitory embodiments, which do not fall within one of the four statutory categories of 35 U.S.C. § 101. See In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007).
Applicant may overcome this rejection by amending the claims to recite, for example, "a non-transitory computer-readable storage medium" or other equivalent language that expressly limits the claimed article to statutory subject matter.
Claim Rejections - 35 USC § 101
8. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
9. Claims 36-40 are rejected under 35 U.S.C. §101 because the claimed invention directed to non-statutory subject matter.
10. Claims 36–40 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter (a signal per se). The claims recite “a machine readable storage medium,” which, under the broadest reasonable interpretation, encompasses both non-transitory and transitory forms, including carrier waves and other propagating signals, absent an express definition to the contrary. Here, the originally filed specification at paragraph [0055] states the machine-readable medium “can include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards or other type of media/machine-readable medium suitable for storing electronic instructions.” The open-ended “not limited to … or other type of media” language does not explicitly exclude transitory embodiments. Accordingly, the claims are reasonably interpreted to cover transitory signals, which are not a manufacture or any other statutory category under § 101 (see Nuijten). Applicant may overcome this rejection by amending “machine readable storage medium” to “non-transitory computer-readable storage medium”.
Claim Rejections - 35 USC § 103
11. 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 (i.e., changing from AIA to pre-AIA ) 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.
10. 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.
12. 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.
13. Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Shaw et al. US 10,423,573 B1 (hereinafter Shaw), Regni et al. US 10,261,960 B2 (hereinafter Regni), further in view of Zukowski et al. US 10,437,780 B2 (hereinafter Zukowski), further in view of Wang et al. US 9,503,542 B1 (hereinafter Wang).
Regarding claim 21, Shaw discloses a data storage system, comprising: an object storage cloud service (Shaw [col. 1, lines 15–17] e.g., “edge appliances … securely transmit all files … to a preferred private or public cloud object store, while locally caching only active files.” Object store as cloud service) ; and [assign individual object identifiers (IDs) to individual storage units of a sparse file system] to store the individual storage units distributed across multiple separate storage resources (Shaw [col. 2, line 51 – col. 3, line 13] e.g., “the object-based data store … may comprise a ‘cloud’ of one or more storage service providers … a first portion of the VFS resides in a first SSP, while a second portion resides in a second SSP.”). However, Shaw, does not explicitly teach assigning individual object identifiers (IDs) to storage unit of a sparse file system, a database cloud service for maintaining metadata associated with the storage units, or a distributed database layer that maps storage request to object identifiers. Regina discloses the database cloud service and the execution engine cloud service and their couplings: assign individual object identifiers (IDs) to individual storage units of a sparse file system (Regni [col. 6, lines 22-31] e.g., “Remaining ring locations correspond to the respective key space IDs or “object IDs” for the data objects that are stored on the storage nodes. Thus, the object ID for a stored data object essentially defines its storage location on the ring.”. Each stored object receives an Object ID, and the Object ID identifies the stored object and its storage location. See also [col. 4, lines 9-15] e.g., “… the new architecture includes an object or key value store (KVS) 201, a distributed database management system (DDS) 202”. Showing an object-based storage architecture. Regni teaches assigning individual object identifiers to storage units of a spars file system by storing spars file stipes as individual KVS object and maintaining mapping tables that associate logical page locations with Object IDs. See also [col. 16, lines 49-61] e.g., “database's hierarchy 1003 contain mappings that correlate an offset identifying a particular stripe of the sparse file to a particular object ID (that is, each object in KVS 1004 corresponds to a different stripe)” Regina also teaches sparse files); a database cloud service coupled over a first network to the object storage cloud service (Regina [col. 4, lines 9-15] e.g. “FIG. 2 shows an embodiment of a new and versatile storage architecture 200. As observed in FIG. 2, the new architecture includes an object or key value store (KVS) 201, a distributed database management system (DDS) 202 (implemented with separate DDS instances 202_1 through 202_N) and a connectors node system (CNS) 203 (implemented with separate CNS instances 203_1 through 203_N).” [Figure 2] Figure 2 illustrates an architecture including a Connector Node System (CNS), a Distributed Database System (DDS), and a Key Value Store (KVS). The CNS interfaces with the DDS and KVS to process storage requests, the DDS and KVS to process storage requests, the DDS manages mapping and metadata information, and the KVS stores the data object. See also [col. 4, lines 43-46] e.g., “The DDS 202 therefore is added as a database management layer above the KVS 201”), the database cloud service to: store metadata for the storage units of the [sparse file system] (Regina [col. 10, lines 50-62] e.g., “The head object 511 contains a mapping table 512 and the object ID 513 for the object 514 within KVS 501 that contains the root page 515 for the distributed consistent database. As will be made more apparent in the following discussion, the mapping table 512 is a data structure that correlates the PAGE ID of the intermediate and leaf node pages of the distributed consistent database's hierarchy to its corresponding KVS object ID”, see also [col. 4, lines 21-28] e.g., “Each object is assigned its own unique (e.g., random) identifier…” Because the mapping table stores those identifiers), search the metadata to identify a particular storage unit that meets data search criteria of a user request (Regina [col. 4, lines 43-58] e.g., “The file directory interface 206 essentially acts as a translation layer that converts an access specified in the form of a directory into an object ID for the KVS 201. Likewise the block storage interface 207 acts as a translation layer that converts an access specified in the form of an offset (or other type of block specific access) into an object ID …”. User request, directory interface, search mapping information, object ID, retrieve object. This is exactly search metadata); and an execution engine cloud service coupled to the object storage cloud service over a second network and to the database cloud service over a third network (Regina [col. 4, lines 9-15] e.g. “FIG. 2 shows an embodiment of a new and versatile storage architecture 200. As observed in FIG. 2, the new architecture includes an object or key value store (KVS) 201, a distributed database management system (DDS) 202 (implemented with separate DDS instances 202_1 through 202_N) and a connectors node system (CNS) 203 (implemented with separate CNS instances 203_1 through 203_N)”. CNS interfaces with users, DDS, KVS, therefore user -> CNS -> DDS -> KVS. Regina discloses a storage architecture including a Key Value Store (KVS), a Distributed Database System (DDS), and a Connector Node System (CNS). The DDS functions as a database layer above the KVS, maintaining mapping information between logical storage locations and object identifiers, while the CNS interfaces with the DDS and KVS to process storage requests); and receive the user request (Regni [col. 10, lines 21-29] e.g., “… a request 510 is received that identifies a particular distributed consistent database and an action to be performed …”. Receive the user request) to access data of the sparse file system, wherein in response to the user request, the execution engine cloud service is to access the database cloud service (Regni [col. 10, lines 21-29] e.g., “The request 510 may be generated externally from DDS 502 (e.g., in the case where the distributed consistent database is exposed for direct use) or internally within DDS 502”. This shows request -> DDS -> processing. This supports execution layer -> database layer) to update metadata for the storage unit (Regni [col. 7, lines 64-67] e.g., “As part of the process of modifying the data object with a PUT command, the version number of the data item's meta-data is incremented commensurate with the writing of the new data”. The claimed “update metadata” correspond with “increment metadata version” It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the distributed database management architecture of Regina into the distributed cloud object storage system of Shwa because Regni teaches managing metadata, object identifiers, and sparse-file mappings through a distributed database layer positioned above an object storage system. Integrating Regni’s distributed database management system with Shaw’s distributed cloud object storage would have predictably improved the organization, identification, and retrieval of distributed storage units while preserving Shaw’s cloud-based object storage architecture. Such a combination merely applies known distributed storge management techniques to improve metadata management, object identification, and sparse-file storage without changing the principle of operation Shaw. The proposed combination does not explicitly teach perform computations based on data of the sparse file systems and cache recently-accessed storage units of the sparse file system. However Zukowski discloses: the execution engine cloud service to: perform computations based on data of the sparse file system (Zukowski [col. 11] e.g., “Execution platform 112 provides multiple computing resources that execute various data storage and data retrieval operations … includes multiple virtual cache recently-accessed storage units of the sparse file system (Zukowski [col. 11, lines 8–9, 56–60] e.g., “Each virtual warehouse includes multiple execution nodes that each include a cache … The caches … store, in the local execution node, data that was retrieved from one or more data storage devices in storage platform 114.”). It would have been obvious to one of the ordinary skill in the art before the effective filing data to incorporate the execution platform of Zukowski into the combined teachings of Shaw and Regni because Zukowski teaches a distributed execution platform including multiple computing resources and execution nodes that perform data storage and retrieval operations while maintaining local caches of recently accessed data. Incorporating Zurkowski’s execution platform into the combined distributed storage architecture would have predictably improved computational efficiency by separating storage management from data processing while reducing repeated access to remote storage through local caching. Such a modification represents the predictable use of known cloud computing techniques to improve scalability execution performance, and resource utilization. However, the combination of Shaw, and Zukowski does not explicitly teach determining whether a requested unit is cached and, upon a miss, retrieving the requested unit from a cloud storage location. Wang discloses these missing features: determine if the requested storage unit is cached at the execution engine cloud service, and access the object storage cloud service to access the requested storage unit if the requested storage unit is not cached at the execution engine cloud service (Wang [col. 2, lines 34–44] e.g., “It can be determined whether cloud objects in the set of cloud objects are stored within a local cache. In response to determining at least one cloud object … is not stored within the local cache, the at least one cloud object can be retrieved from a cloud storage location and … stored in the local cache.”). It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate Wang’s cache management techniques into the combined teachings of Shaw, Regni, and Zukowski because Wang expressly teaches determining whether requested cloud objects are present in a local cache and, upon determining that the requested cloud object is not cached, retrieving the cloud object from cloud storage and storing it in the local cache. Incorporating Wang’s cache lookup and cache-miss retrieval mechanism into the combined cloud storage architecture would have periodically reduced storage access latency, minimized repeated remote object retrievals, and improved overall system performance while preserving the operation of the distributed cloud storage system.
Claims 31 and 36 incorporate substantively all the limitations of claim 21 in a method (Show [col. 19, lines 56-57]] e.g., “…a method or process…”) and a machine readable storage medium (Shaw [col. 20, lines 2-3] e.g., “A computer-readable medium having instructions stored thereon to perform…”) and rejected under the same rationale.
Regarding claim 22, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the first network, the second network, and the third network are different networks (Zukowski [col. 5, lines 26–41] e.g., “the communication links … between resource manager 102 … metadata 110, and execution platform 112 are implemented via one or more data communication networks … [and] between execution platform 112 and data storage devices … via one or more data communication networks … a combination of two or more … networks (or sub-networks).”). Regarding claim 23, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein at least one of the first network, the second network, and the third networks is the Internet (Shaw [col. 5, lines 61-64] e.g., “ communication is through the highly scalable, fault-tolerant cloud, and over standard Internet connections (with no special requirements)”. One network is the internet).
Regarding claim 24, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the storage units comprise stripes of data (Wang [Abstract] e.g., “Files tiered to cloud storage can be stored in chunks where each chunk is stored as a distinct cloud object … The mapping … includes … cloud storage account, object identifier …”. ).
Regarding claim 25, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the storage units comprise files (Shaw [col. 4, lines 17-19] e.g., “The local file system stores local user files (the data) in their native form in cache 208”).
Regarding claim 26, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the execution engine cloud service is to implement cache coherency to maintain cached storage unit coherent with the object storage cloud service (Shaw [col. 9, lines 10-12] e.g., “Before the lock is downgraded, the current data can be sent to the cloud so that it's available for the next locker”).
Regarding claim 27, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the execution engine cloud service is to map a filepath specified in the user request into at least one object ID to pass to the object storage cloud service to access the storage unit (Shaw [col. 5, lines 63-67] e.g., “Mapping between a stub file and a set of cloud objects models the link between a local file (e.g., a file location, offset, range) and a set of cloud objects where individual cloud objects can be defined by at least an account, a container, and an object identifier…”).
Regarding claim 28, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the execution engine cloud service is to present application programming interfaces (APIs) to different types of file systems that are part of the sparse file system (Shaw [col. 4, lines 23-44] e.g., “FIG. 3 …different types of local file system…NTFS …MacFS …EXT3 or XFS…each platform may be controlled…one or more external storage service providers may be used as an external object repository”).
Regarding claim 29, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the execution engine cloud service is to generate virtual machines (VMs) and execute the VMs for user operation (Shaw [col. 3, lines 29-31] e.g., “…the interface is implemented as a virtual machine or appliance (e.g., via VMware®, or the like)”).
Regarding claim 30, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the data storage system of claim 21, wherein the execution engine cloud service is to perform one or more of: mirror individual storage units within the sparse file system (Show [col. 16, lines 24-34] e.g., “…a collection of one or more files…may be organized into a…“push class”) and propagated from a source filer to one or many target filers that share the same volume (in the multi-site embodiment as described above), see also ); lock individual storage units within the sparse file system (Shaw [col. 6, lines 33-40] e.g., “Global locking is achieved…providing a centralized lock manager in the cloud, allowing for individual file snapshot, synchronization, merge cycles to ensure that current data is always available upon lock grant”), see also (Shaw [col. 7, lines 9-30] e.g., “SMB/CIFS lock requests are intercepted….NFS lock requests are passed…to handle the lock request using a common protocol”, see also [col. 7, lines 31-37] e.g., “The lock daemon …can perform …(c) acquiring locks; (d) lock peeking; (e) lock re-acquiring; (f) lock releasing”); or take snapshots of individual storage units within the sparse file system. These passages show the execution-side service (the filer/interface and its components)).
Regarding claim 32, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the method of claim 31, wherein the storage units comprise stripes of data or wherein the storage units comprise files (Wang [Abstract] e.g., “Files tiered to cloud storage can be stored in chunks where each chunk is stored as a distinct cloud object … The mapping … includes … cloud storage account, object identifier…”).
Regarding claim 33, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the method of claim 31, wherein accessing the object storage cloud service comprises the execution engine cloud service mapping a filepath specified in the user request into at least one object ID to pass to the object storage cloud service to access the storage unit (Shaw [col. 5, lines 63-67] e.g., “Mapping between a stub file and a set of cloud objects models the link between a local file (e.g., a file location, offset, range) and a set of cloud objects where individual cloud objects can be defined by at least an account, a container, and an object identifier…”).
Regarding claim 34, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the method of claim 31, wherein performing computations based on the data of the sparse file system comprises the execution engine cloud service generating virtual machines (VMs) and executing the VMs for user operation (Shaw [col. 3, lines 29-31] e.g., “…the interface is implemented as a virtual machine or appliance (e.g., via VMware®, or the like)”).
Regarding claim 35, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the method of claim 31, further comprising the execution engine cloud service performing one or more of: mirroring individual storage units within the sparse file system (Show [col. 16, lines 24-30] e.g., “…a collection of one or more files…may be organized into a…“push class”) and propagated from a source filer to one or many target filers that share the same volume (in the multi-site embodiment as described above), see also ); locking individual storage units within the sparse file system (Show [col. 16, lines 24-30 ] e.g., “…a collection of one or more files…may be organized into a…“push class”) and propagated from a source filer to one or many target filers that share the same volume (in the multi-site embodiment as described above), see also ); or taking snapshots of individual storage units within the sparse file system (Shaw [col. 6, lines 33-40] e.g., “Global locking is achieved…providing a centralized lock manager in the cloud, allowing for individual file snapshot, synchronization, merge cycles to ensure that current data is always available upon lock grant”), see also (Shaw [col. 7, lines 9-30] e.g., “SMB/CIFS lock requests are intercepted….NFS lock requests are passed…to handle the lock request using a common protocol”, see also [col. 7, lines 31-37] e.g., “The lock daemon …can perform …(c) acquiring locks; (d) lock peeking; (e) lock re-acquiring; (f) lock releasing”); or take snapshots of individual storage units within the sparse file system. These passages show the execution-side service (the filer/interface and its components)).
Regarding claim 37, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the machine readable storage medium of claim 36, wherein the storage units comprise stripes of data or wherein the storage units comprise files (Shaw [col. 4, lines 17-19] e.g., “The local file system stores local user files (the data) in their native form in cache 208”).
Regarding claim 38, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the machine readable storage medium of claim 36, wherein accessing the object storage cloud service comprises the execution engine cloud service mapping a filepath specified in the user request into at least one object ID to pass to the object storage cloud service to access the storage unit (Shaw [col. 5, lines 63-67] e.g., “Mapping between a stub file and a set of cloud objects models the link between a local file (e.g., a file location, offset, range) and a set of cloud objects where individual cloud objects can be defined by at least an account, a container, and an object identifier…”).
Regarding claim 39, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the machine readable storage medium of claim 36, wherein performing computations based on the data of the sparse file system comprises the execution engine cloud service generating virtual machines (VMs) and executing the VMs for user operation (Shaw [col. 3, lines 29-31] e.g., “…the interface is implemented as a virtual machine or appliance (e.g., via VMware®, or the like)”).
Regarding claim 40, the proposed combination of Shaw, Regni, Zukowski, and Wang discloses the machine readable storage medium of claim 36, wherein the method further comprises the execution engine cloud service performing one or more of: mirroring individual storage units within the sparse file system (Show [col. 16, lines 24-34 ] e.g., “…a collection of one or more files…may be organized into a…“push class”) and propagated from a source filer to one or many target filers that share the same volume (in the multi-site embodiment as described above), see also ); locking individual storage units within the sparse file system (Shaw [col. 6, lines 33-40] e.g., “Global locking is achieved…providing a centralized lock manager in the cloud, allowing for individual file snapshot, synchronization, merge cycles to ensure that current data is always available upon lock grant”), see also (Shaw [col. 7, lines 9-30] e.g., “SMB/CIFS lock requests are intercepted….NFS lock requests are passed…to handle the lock request using a common protocol”, see also [col. 7, lines 31-37] e.g., “The lock daemon …can perform …(c) acquiring locks; (d) lock peeking; (e) lock re-acquiring; (f) lock releasing”); or take snapshots of individual storage units within the sparse file system. These passages show the execution-side service (the filer/interface and its components)).
Conclusion
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Flex.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156 /AMY NG/Supervisory Patent Examiner, Art Unit 2164
Prosecution Insights