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 .
Response to Arguments
Applicant's arguments filed 30 January 2026 have been fully considered but they are not persuasive.
Applicant contends that Difranco and Hu do not teach the “selection of a set of network management services,” as recited in claim 1, because none of the references teach selecting services “from a plurality of network management services.” Remarks at 7.
The Examiner respectfully disagrees. Difranco teaches “[t]he provisioning service can allow for lets clients to provision and manage compute hosts, which can be referred to as instances” and “[c]lients can launch instances as needed to meet compute and application requirements.” US 2023/0094159 ¶ 29. Further, “each service instance, service instance 1 505, service instance 2 510, service instance 3 515, service instance 4 520, and service instance 5 525 can be associated with a partition of the plurality of partitions.” Id. ¶ 103.
Here, the Examiner finds that Difranco’s provisioning service that allows clients to provision instances and associating a plurality of instances with a particular partition teaches or at least suggests the recited “selection of a set of network management services,” as recited in claim 1.
Regarding claim 5, Applicant contends that the cited references do not teach “a policy management service” and “a network monitoring service.” Remarks at 7.
The Examiner respectfully disagrees. Hu discloses that “resource allocation is planned globally be all instances of the resource manager 310.” US 2018/0255137 ¶ 56. The specification discloses “a policy management service for defining logical network policies for a logical network spanning the group of datacenters” in paragraph [0215] as “the primary tenant user, through the global manager service, can also define entirely new security domains and/or logical networking constructs that span the entire datacenter group (or subsets of datacenters) underneath the primary tenant configuration.” US 2024/0152378 ¶ 215.
Here, the Examiner finds that person having ordinary skill in the art would have found the recited “a policy management service for defining logical network policies for a logical network spanning the group of datacenters” obvious in view of Hu’s disclosure of “resource allocation is planned globally be all instances of the resource manager 310.”
Further, Hu discloses that “resource agents 302 are configured to continuously stream data to the instances of the resource manager 310 to update profile information,” which the Examiner finds teaches or at least suggest the recited “a network monitoring service for monitoring data flows in the logical network.”
Applicant contends that Difranco merely teaches namespaces and doesn’t disclose “its namespaces are used as separate deployment locations for different network management services.” Remarks at 7.
The Examiner respectfully disagrees. Difranco teaches in Figure 4 and paragraph [0115] that “the partitions, such as partition 1 and partition 2, as well as other partitions not shown in the Figure, can be separated by namespaces.” Further, “each service instance, service instance 1 505, service instance 2 510, service instance 3 515, service instance 4 520, and service instance 5 525 can be associated with a partition of the plurality of partitions.” US 2023/0094159 at ¶ 103.
The Examiner finds a person having ordinary skill in the art would have found “deploying each respective selected network management service as a plurality of microservices in the respective namespace,” as recited in claim 1, obvious in view of Difranco’s disclosure of a plurality of respective service deployed in a plurality of respective partitions, wherein the partitions “can be separated by namespaces.”
Applicant contends that the provisional and non-provisional non-statutory double patenting rejections should be withdrawn because the reference patent and patent application do not teach “selection of a set of network managements services,” “for each respective selected network management service, defining a respective namespace,” and “deploying each respective selected network management service . . . in the respective namespace,” as recited in claim 1.
The Examiner respectfully disagrees. The arguments are merely conclusory and no specific reason is provided why the reference patent and patent application do not teach or at least suggest the respective portions of claim 1. Accordingly, the provisional and non-provisional non-statutory double patenting rejections are not withdrawn.
Claim Rejections - 35 USC § 103
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.
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.
Claim(s) 1-5, 10-15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Difranco (US 2023/0094159) and further in view of Hu (US 2018/0255137).
Regarding claim 1, Difranco: A method for deploying network management services for a group of datacenters, the method comprising:
from a tenant of a network management system deployed in a container cluster of the public cloud, receiving (i) a definition of a group of datacenters for the network management system to manage (¶ 152, “each of the plurality of service instances being associated with a different tenant of the plurality of tenants, and can further provide a mapping table, the mapping table comprising a mapping of each of the service instances to an assigned partition of the plurality of partitions” and ¶ 53, “Such connection services can provide an easy way to create a dedicated, private connection between a client data center or existing network and the cloud infrastructure environment”) and (ii) a selection of a set of network management services from a plurality of network management services offered by the network management system (¶ 38, “The container service can specify the compute resources that the containerized applications require, and the container engine can then provision, via the provisioning service, the required compute resources for use within the cloud infrastructure environment (e.g., in the context of a tenancy)”; ¶ 29; ¶ 103); and
for each respective selected network management service, defining a respective namespace of the container cluster (¶ 110, “each deployment can comprise one or more pods (e.g., for highly-available deployments, each deployment can comprise two or more pods). Each deployment can be appended with, e.g., a sequence number, or each deployment can be placed in separate namespaces (optionally with sequence numbers as well)”); and
deploying each respective selected network management service as a plurality of microservices in the respective namespace (¶ 115, “By separating the partitions by namespace, this simplifies routing if runtime microservices are not collocated”; ¶ 103).
Difranco does not teach as clearly as Hu discloses: a group of datacenters (¶ 35, “As shown in FIG. 1A, the cloud 100 includes a plurality of data centers 110, each data center 110 in the plurality of data centers 110 including one or more resource pools 120”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of a group of datacenters, as taught by Hu, in the same way to the cloud infrastructure environment, as taught by Difranco. Both inventions are in the field of managing cloud resources, and combining them would have predictably resulted in “unified resource management solutions implemented within the cloud architecture,” as indicated by Hu (¶ 1).
Regarding claim 2, Difranco: The method of claim 1, wherein the method is performed by a multi-tenant service operating in a separate namespace of the container cluster (¶ 131, “FIG. 8 shows an exemplary runtime embodiment for dynamically partition multi-tenant namespaces in the context of an integration cloud platform”).
Regarding claim 3, Difranco: The method of claim 2, wherein the tenant is a first tenant, the group of datacenters is a first group of datacenters, and the set of network management services is a second set of network management services, the method further comprising: from a second tenant of the network management system, receiving (i) a definition of a second group of datacenters for the network management system to manage (¶ 152, “each of the plurality of service instances being associated with a different tenant of the plurality of tenants, and can further provide a mapping table, the mapping table comprising a mapping of each of the service instances to an assigned partition of the plurality of partitions”) and (ii) a selection of a second set of network management services from the plurality of network management services offered by the network management system (¶ 103, “each service instance, service instance 1 505, service instance 2 510, service instance 3 515, service instance 4 520, and service instance 5 525 can be associated with a partition of the plurality of partitions”); and for each respective network management service of the second set of network management services, defining a respective namespace of the container cluster (¶ 147, “at step 960, the method can assign each of plurality of partitions a uniquely addressable namespace”); and deploying each respective network management service of the second set of network management services as a plurality of microservices in the respective namespace (¶ 149, “the method can define a deployment within each of the plurality of partitions, each deployment managing at least one pod”).
Regarding claim 4, Difranco: The method of claim 1, wherein the group of datacenters is a first group of datacenters and the set of network management services is a second set of network management services, the method further comprising: from the tenant, receiving (i) a definition of a second group of datacenters for the network management system to manage (¶ 152, “each of the plurality of service instances being associated with a different tenant of the plurality of tenants, and can further provide a mapping table, the mapping table comprising a mapping of each of the service instances to an assigned partition of the plurality of partitions”) and (ii) a selection of a second set of network management services from the plurality of network management services offered by the network management system (¶ 103, “each service instance, service instance 1 505, service instance 2 510, service instance 3 515, service instance 4 520, and service instance 5 525 can be associated with a partition of the plurality of partitions”); for each respective network management service of the second set of network management services, defining a respective namespace of the container cluster (¶ 147, “at step 960, the method can assign each of plurality of partitions a uniquely addressable namespace”); and deploying each respective network management service of the second set of network management services as a plurality of microservices in the respective namespace (¶ 149, “the method can define a deployment within each of the plurality of partitions, each deployment managing at least one pod”).
Regarding claim 5, Hu: The method of claim 1, wherein the plurality of network management services comprises at least (i) a policy management service for defining logical network policies for a logical network spanning the group of datacenters (¶ 56, “The multiple instances of the resource manager 310 may be configured to communicate such that resource allocation is planned globally be all instances of the resource manager 310”; ¶ 215) and (ii) a network monitoring service for monitoring data flows in the logical network (¶ 70, “the resource agents 302 are configured to continuously stream data to the instances of the resource manager 310 to update the profile information”).
Regarding claim 10, Difranco: The method of claim 1, wherein the container cluster is a Kubernetes cluster (¶ 81, “the term “cluster” or “clusters” can refer to a set, or sets, of machines individually referred to as nodes used to run containerized applications managed by Kubernetes”).
Claims 11-15 and 20 recite commensurate subject matter as claims 1-5 and 10. Therefore, they are rejected for the same reasons.
Claim(s) 6-8 and 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Difranco and Hu, as applied above, and further in view of Sosnovich (US 2023/0179573).
Regarding claim 6, Difranco and Hu do not teach; however, Sosnovich discloses: defining firewall rules for data communication between the namespaces (¶ 39, “the firewall rules (i.e., fw-rules), a textual representation of the allowed connectivity that may be inferred from the network policy” and “A goal may be to minimize the number of fw-rules by grouping by pod labels, or namespaces (e.g., representing a group of pods which may have the same namespace), among other things”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of defining firewall rules for data communication between the namespaces, as taught by Sosnovich, in the same way to the namespaces, as taught by Difranco and Hu. Both inventions are in the field of managing namespaces, and combining them would have predictably resulted in “a more secure environment,” as indicated by Sosnovich (¶ 38).
Regarding claim 7, Sosnovich: The method of claim 6, wherein the firewall rules allow communication between the namespaces defined for the set of network management services for the group of datacenters (¶ 28, “a firewall-rule (fw-rule) may be provided in the following format: <src, dst, allowed connections> where src and dst are each a namespace-label expression, a namespace, a pod-label expression, a pod, or an IP-block. As a matter of procedure, src may send packets to dst over protocols and/or ports specified in the allowed connections”).
Regarding claim 8, Sosnovich: The method of claim 6, wherein defining the firewall rules comprises instructing a cluster controller to define the firewall rules (¶ 24, “Whether a given connection is allowed between pods may be decided by a combined behavior of the policies in a cluster.”) and to specify for container cluster network elements to enforce the firewall rules (¶ 24, “Kubernetes® may provide network policies for users to specify which network traffic may be allowed and/or denied between pods in the cluster, and between pods and Internet Protocol (IP) addresses outside the cluster”).
Claims 16-18 recite commensurate subject matter as claims 6-8. Therefore, they are rejected for the same reasons.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Difranco and Hu, as applied above, and further in view of Thakkar (US 2017/0060615).
Regarding claim 9, Difranco and Hu do not teach; however, Thakkar discloses: the group of datacenters comprises at least one virtual datacenter implemented in a public cloud and at least one physical on-premises datacenter (¶ 10, “maintaining virtual appliances in a hybrid cloud computing system which includes an on-premise data center and a public cloud computing system configured to provide a common platform for managing and executing virtual workloads”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the group of datacenters comprises at least one virtual datacenter implemented in a public cloud and at least one physical on-premises datacenter, as taught by Thakkar, in the same way to the group of datacenters, as taught by Difranco and Hu. Both inventions are in the field of managing namespaces, and combining them would have predictably resulted in “a more secure environment,” as indicated by Thakkar (¶ 38).
Claim 19 recites commensurate subject matter as claim 9. Therefore, it is rejected for the same reason.
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-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-21 of copending Application No. 18/231,757 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the reference application teaches or at least suggests each and every limitation of the instant application. See claim correspondence below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Reference Application
1. A computer-implemented method comprising: obtaining, by a source machine, a first network swap instruction, wherein the source machine has a first machine identity: based at least on obtaining the first network swap instruction: transmitting, by the source machine, to a target machine, a second network swap instruction, wherein the target machine has a second machine identity: swapping, by the source machine, its identity from the first machine identity to the second machine identity; and swapping, by the target machine, its identity from the second machine identity to the first machine identity: obtaining, by the source machine or the target machine, an upgrade cancellation instruction; and based on at least obtaining the upgrade cancellation instruction: reverting, by the source machine, its identity to the first machine identity; and reverting, by the target machine, its identity to the second machine identity.
1. A method for monitoring a multi-tenant network management system deployed in a public cloud to manage a plurality of groups of datacenters, the method comprising: for each datacenter group of a plurality of datacenter groups managed by the multi-network management system, wherein each respective datacenter group comprises one or more datacenters of a respective tenant that defines the datacenter group: deploying a set of network management service instances in the cloud specified by the tenant for the datacenter group, each of the network management service instances providing a specified service to the datacenters of the datacenter group; and deploying a metric monitoring service instance in the cloud for the datacenter group, the metric monitoring service instance for collecting and analyzing metrics from services belonging to each of the network management service instances deployed for the datacenter group, wherein the metric monitoring service instance comprises an anomaly detection microservice that analyzes collected flow data to identify anomalous behavior in network traffic and generates alerts based on the anomalous behavior.
3. The method of claim 2, wherein: each respective network management service instance is deployed in a separate respective namespace of the Kubernetes cluster; and each respective metric monitoring service instance is deployed in a respective namespace that is separate from the namespaces of the network management service instances and the other metric monitoring service instances.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-24 of copending Application No. 18/231,851 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the reference application teaches or at least suggests each and every limitation of the instant application. See claim correspondence below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Reference Application
1. A computer-implemented method comprising: obtaining, by a source machine, a first network swap instruction, wherein the source machine has a first machine identity: based at least on obtaining the first network swap instruction: transmitting, by the source machine, to a target machine, a second network swap instruction, wherein the target machine has a second machine identity: swapping, by the source machine, its identity from the first machine identity to the second machine identity; and swapping, by the target machine, its identity from the second machine identity to the first machine identity: obtaining, by the source machine or the target machine, an upgrade cancellation instruction; and based on at least obtaining the upgrade cancellation instruction: reverting, by the source machine, its identity to the first machine identity; and reverting, by the target machine, its identity to the second machine identity.
1. A method for monitoring a system deployed in a cloud, the method comprising: deploying a first health monitoring service that monitors a first set of common services of the system deployed in the cloud by directly communicating with each service in the first set of services to determine whether a respective set of aspects of each respective service are properly operational, the first set of common services accessed by a plurality of tenants of the system; and within each respective tenant-specific service instance of a plurality of tenant-specific service instances deployed in the cloud for the plurality of tenants, deploying a respective health monitoring service that monitors a respective plurality of microservices of the service instance by directly communicating with each microservice of the tenant-specific service instance to determine whether a respective set of aspects of each respective microservice are properly operational.
13. The method of claim 1, wherein: the system is deployed within a Kubernetes cluster in a public cloud; the respective tenant-specific service instances are each deployed in separate respective namespaces of the Kubernetes cluster; and each respective health monitoring service is deployed in the respective namespace of the respective service instance monitored by the respective health monitoring service.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-24 of copending Application No. 18/231,756 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the reference application teaches or at least suggests each and every limitation of the instant application. See claim correspondence below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Reference Application
1. A computer-implemented method comprising: obtaining, by a source machine, a first network swap instruction, wherein the source machine has a first machine identity: based at least on obtaining the first network swap instruction: transmitting, by the source machine, to a target machine, a second network swap instruction, wherein the target machine has a second machine identity: swapping, by the source machine, its identity from the first machine identity to the second machine identity; and swapping, by the target machine, its identity from the second machine identity to the first machine identity: obtaining, by the source machine or the target machine, an upgrade cancellation instruction; and based on at least obtaining the upgrade cancellation instruction: reverting, by the source machine, its identity to the first machine identity; and reverting, by the target machine, its identity to the second machine identity.
1. A method for monitoring a multi-tenant network management system deployed in a cloud to manage a plurality of groups of datacenters, the network management system comprising a plurality of groups of service instances, the method comprising: for each respective group of service instances deployed in the cloud to manage a respective datacenter group: deploying a metrics collection agent within each service instance of the group of service instances to collect metrics from services of the service instance and provide the collected metrics to a metric monitoring service instance of the group of service instances; and deploying a metrics collection manager within the metric monitoring service instance of the group of service instances, the metrics collection manager for configuring each of the metrics collection agents deployed within the service instances of the group of service instances.
2. The method of claim 1, wherein: the network management system is deployed in a Kubernetes cluster in a public cloud; and for a particular group of service instances, each respective service instance is deployed in a different respective namespace.
7. The method of claim 2, wherein: each of the service instances of a group of service instances is deployed as a set of microservices; and each microservice is implemented as one or more Pods in the namespace of the service instance to which the microservice belongs.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-25 of Patent No. US 12,184,521. Although the claims at issue are not identical, they are not patentably distinct from each other because the Patent No. US 12,184,521 teaches or at least suggests each and every limitation of the instant application. See claim correspondence below.
Instant Application
Patent No. US 12,184,521
1. A computer-implemented method comprising: obtaining, by a source machine, a first network swap instruction, wherein the source machine has a first machine identity: based at least on obtaining the first network swap instruction: transmitting, by the source machine, to a target machine, a second network swap instruction, wherein the target machine has a second machine identity: swapping, by the source machine, its identity from the first machine identity to the second machine identity; and swapping, by the target machine, its identity from the second machine identity to the first machine identity: obtaining, by the source machine or the target machine, an upgrade cancellation instruction; and based on at least obtaining the upgrade cancellation instruction: reverting, by the source machine, its identity to the first machine identity; and reverting, by the target machine, its identity to the second machine identity.
1. For a health monitoring service that monitors a system comprising a set of services executing across a set of one or more datacenters, a method comprising: for each of a plurality of services monitored by the health monitoring service: contacting an API exposed by the service to provide health monitoring data for the service; and receiving health monitoring data for the service that provides, for each of a plurality of aspects of the service, (i) a status and (ii) an explanation for the status in a uniform format used by the APIs of each of the services of the plurality of services, wherein at least two different services provide health monitoring data in the uniform format for different pluralities of aspects of the services, the health monitoring data being collected and stored by a common service at a health data store.
5. The method of claim 3, wherein: the system is deployed within a Kubernetes cluster; the services are microservices assigned to a single namespace of the Kubernetes cluster; and the health monitoring service is also assigned to the same namespace.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198