DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending for examination in this application. Claims 1 and 11 are independent claims. This Office Action is FINAL.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 12/03/2025 is in compliance with the provisions of 37 CFR 1.97, 1.98, and MPEP § 609. The IDS has been placed in the application file, and the information referred to therein has been considered as to the merits.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Le et al., (U.S. Patent Publn. Num.: 2016/0366233 A1, cited in IDS), hereinafter Le.
Regarding claim 1, Le teaches:
An apparatus comprising:
a computer system including a plurality of processing devices and one or more memory devices operably coupled to the plurality of processing devices (Le, para [0029], "A deployment unit (DU) 142 is a logical instance of software services deployed for a given customer in the SAAS cloud computing environment. SAAS based cloud computing environment contains large number of computer processors with shared memory space. The deployment unit contains one or more SAAS based services that communicate with one or more entities (host agents, PCSS agents, gateway nodes) deployed inside enterprise customer data center. The SaaS based services include the controller services of PCSS stacks. The data center servers do not access this node directly, but they may see API endpoints or HTTP URLs that are serviced by this node. DU has a deployment agent 116, certificate authority 112 (discussed below), resource manager 114, stat/health agent 120, configuration manager 124, OpenStack controller 148 and a shared database 164. The DU components runs in a public cloud which is a large number of computers with processors and memory components."), the one or more memory devices storing executable code that, when executed by the plurality of processing devices, causes the plurality of processing devices to (Le, para [0022], [0029]):
create, by a first cluster executing on the computer system, a snapshot object for the first cluster including one or more identifiers of one or more components that have changed in the first cluster (Le, Fig. 6, para [0047], "FIG. 6 illustrates the components of an another PCSS called Kubernetes, which is seamlessly managed within the system. Kubernetes PCSS enables workloads to be deployed in components called containers, which can be thought of as lightweight virtual machines. The Kubernetes PCSS allows the creation of one or more Kubernetes clusters on a user's data center hosts. In Kubernetes terminology, a host is called node. A node can take the role of a worker node, a master node, or both. The control plane elements of a Kubernetes PCSS run in a deployment unit 601 and include a User and Authentication Manager 602 and a Node and Cluster Manager 603. The DU also hosts the same DU Shared Services that are common to all PCSS stacks, including the resource manager 604, certificate authority 605, configuration manager 607, and stats/health agent 608." Le, paragraph 0071-0073 and accompanying “>vrish list”, “virsh dumpxml 1” and data structure “instance_uuid” teaches “data structure is used to store the captured information” described in >virsh list and virsh dumpt xml and also the information in the data structure given between paragraphs 0073-0074 that is a snapshot and the >virsh list Id “1 2 3 5 10” for each “instance_uuid” component that changes in the cluster from one snapshot to the next snapshot. Paragraph 0073 teaches that a copy/duplicate of the information in the data structure according to ID (‘instance_uuid’) “describes a …document which is used to store the ‘discovered’ VMs” prior to registering with software platform. Paragraph 0046 teaches upgrading and changing json document “application/agent can be configured dynamically by host agent through its own set of commands. For example, the information about what internet protocol (IP) address to use for accepting peer servers command is one instance where the configuration is updated [i.e changed] based upon user's action on software platform SAAS user interface (UI).” Paragraph 0042 teaches “SAAS platform performs regular updates to the private cloud to fix bugs and include new software features.”), the one or more components being executable components executing in the first cluster (Le, containers/lightweight virtual machines [i.e. components] execute in a cluster, paragraph 0048 “a service called Kubelet (616) which is responsible for obtaining from the master node(s) a list of containers to run. Kubelet interacts with the container engine to try to ensure that the containers specified by the master node(s) are always running.”);
transmit, by the first cluster, to a second cluster executing on the computer system, the snapshot object (Le, Fig. 6, para [0048]-[0049], “The control plane and other DU elements can store their state in shared database 600. The Kubernetes data plane elements comprise a common set of components which are deployed on all nodes, a set of master components which are deployed on master nodes, and a set of worker components which are deployed on worker nodes. The common set includes a container engine 612 (e.g., Docker or Rocket), a distributed database 615 (e.g., Etcd and Consul), and a network manager 613 (e.g., Flannel). The network manager is responsible for creating a container network 614 allowing containers on different nodes to communicate [i.e. transmit]. Each worker node has a service called Kubelet (616) which is responsible for obtaining from the master node(s) a list of containers to run. Kubelet interacts with the container engine to try to ensure that the containers specified by the master node(s) are always running." [i.e. transmit … the snapshot object]). See also Fig. 2, blocks 228, 232, 236 failure or error in component results in restart/reinstall to another component); and
in response to the snapshot object, instantiate by the second cluster, copies of the one or more components on the second cluster such that the second cluster becomes a replica of the first cluster (Le, Fig. 6, para [0049], “The services specific to a master node includes an API server 617, a scheduler 618, and a controller manager 619. Together with other master nodes in the same cluster, they respond to API requests, manage the state of the cluster, and communicate with Kubelets to ensure the right containers are running on the right nodes. The state of the cluster itself is stored in a distributed key-value store managed by the distributed database component of each node in the cluster. To take advantage of Kubernetes, a user interacts with the Kubernetes Node and Cluster Manager to define one or more clusters. When first defined, a cluster is logically empty. The user then installs the host agent on one or more data center hosts. He/she then authorizes the hosts with the Kubernetes role, and specifies which cluster the host/node should be added to. The Node and Cluster Manager can automatically decide whether to make a new node a master or a worker; it can also let the user choose. Once the master/worker role is decided for a host/node, the node and cluster manager coordinates with the resource manager and configuration manager to deploy, install, and configure the correct data plane components to the host/node with the help of the host agent 611 running on each host." Paragraph 0047 teaches “Kubernetes PCSS allows the creation of one or more Kubernetes clusters on a user’s data center hosts.” As user defines one or more clusters, for the second cluster, the host agent has Master Node and Worker Node (see Fig. 6) that is initially duplicate of the first cluster and user “specifies which cluster [i.e. second cluster] the host/node should be added to”, see paragraph 0049.Paragraph 0048 teaches that initial creation of Master Nodes and Worker Nodes has “a common set of components which are deployed on all nodes, a set of master components which are deployed on master nodes, and a set of worker components which are deployed on worker nodes.” So initially, the nodes in a second cluster are replicas of first cluster. Paragraphs 0047-0048 teaches the containers contain the actual workloads to run, containers are lightweight virtual machines that can include multiple nodes. Paragraphs 0071-0074 teaches contents of workloads that are replicated for VM with multiple nodes, see above description and teachings.).
Regarding dependent claim 2, Le teaches wherein the executable code that, when executed by the plurality of processing devices, further causes the plurality of processing devices to (Le, para [0022], [0029]):
add, by the first cluster, segment identifiers of one or more segments of data stored in a storage volume of the first cluster (Examiner under BRI interprets “segment identifier” as taught in paragraph 0052 of applicant’s originally filed specification “UUIDs for all components and segments on the cluster”. Le, see data structure between paragraphs 0073-0074 that teaches instance_uuid that includes segments such as name, admin_password, vcpus …for segments of data such as name:fake instance, ..vcpus:2 ….See also paras [0047], [0048], [0049]. As taught in mappings above by Le, especially paragraph 0046, segment identifiers in the json document may change);
in response to the snapshot object, retrieve, by the second cluster, the one or more segments of data from the first cluster (Le, paras [0047], [0048], [0049]. Fig. 6, para [0049], “The state of the cluster itself is stored in a distributed key-value store managed by the distributed database component of each node in the cluster. …Once the master/worker role is decided for a host/node, the node and cluster manager coordinates with the resource manager and configuration manager to deploy, install, and configure the correct data plane components to the host/node with the help of the host agent 611 running on each host." Paragraph 0047 teaches “Kubernetes PCSS allows the creation of one or more Kubernetes clusters on a user’s data center hosts.” As user defines one or more clusters, for the second cluster, the host agent has Master Node and Worker Node (see Fig. 6) that is initially duplicate of the first cluster and user “specifies which cluster [i.e. second cluster] the host/node should be added to”, see paragraph 0049. Paragraphs 0047-0048 teaches the containers contain the actual workloads to run, containers are lightweight virtual machines that can include multiple nodes. Paragraphs 0071-0074 teaches contents of workloads that are replicated for VM with multiple nodes, see above description and teachings.).
Regarding dependent claim 3, Le teaches wherein the one or more components include one or more logical hosts (Le, para [0029]).
Regarding dependent claim 4, Le teaches wherein the one or more components include one or more application instances (Le, para [0029]).
Regarding dependent claim 5, Le teaches wherein the one or more components include one or more storage volumes (Le, para [0022], "Open source private cloud software, which runs on standard hardware (Linux and/or Windows operating systems), is used to manage cloud computing infrastructure. Private cloud software typically employs multiple layers of software, hence the use of 'stack' to describe the overall collection. A PCSS is typically composed of multiple projects for managing specific infrastructure areas. For example, OpenStack uses the Nova project for managing compute infrastructure, Glance for virtual machine images, Swift for object storage, Cinder for block storage, Neutron for networking, etc. Each project has its own layered elements, and can therefore be viewed as a vertical slice of the PCSS. The elements are generally classified in two areas: control plane and data plane. The control plane elements are usually called controller services, and are responsible for monitoring and managing the data plane elements. The data plane elements manage the physical infrastructure resources (e.g. compute servers, storage arrays, network interfaces), and generally need to be in close physical proximity to those resources, i.e. running on the resources or a local network that can reach the resources. They are generally implemented as software agents. For example, in the nova project, nova-api, nova-conductor and nova-scheduler serve as the SAAS controller services, whereas nova-compute serves as the data plane agent. An embodiment of the invention facilitates the deployment of data plane agents through its own agent, called host agent. A private cloud service is a set of Linux/Windows or any other types of computing, storage and network servers located in a data center managed through a management console. Enterprise customers can use a SaaS management console interface to install a host agent onto each server selected for inclusion in the requisite private cloud environment. Once the agent is installed on each server within the private cloud, an end-user can use a management console to setup a virtual machine instance for each server as well as manage the software upgrade process.").
Regarding dependent claim 6, Le teaches wherein the snapshot object is a second snapshot object and wherein the second snapshot object includes a second sequence number such that the second sequence number is greater than a first sequence number of a first snapshot object created by the first cluster prior to creating the second snapshot object (Le, para [0043], "Once the SAAS platform has been upgraded, SAAS platform sends the new version number for the cloud stack to the host agent. Once the host agent notices the difference in the installed vs desired version number of host agent, host agent upgrades itself. The host agent upgrades the security certificate if a new security certificate is available 812. The SAAS platform receives messages to re-authenticate the host agent 820. The SAAS platform sends further message to upgrade other PCSS components 824. The actual software upgrade is performed using the Linux operating system specific utilities like yum or apt or the corresponding Windows upgrade utility.").
Regarding dependent claim 7, Le teaches wherein the snapshot object is a first snapshot object and wherein the executable code that, when executed by the plurality of processing devices, further causes the plurality of processing devices to restore the first cluster following failure of the first cluster by (Le, para [0022], [0029], [0047], [0048], [0049]. Fig. 8, paragraph [0045] teaches host agent on node that is in cluster failure, then “host agent reports back any errors … and log necessary debugging information to help diagnose these failures. The host agent monitors installed component version for their running state 856. The SAAS platform receives configuration health of the PCSS components 860.” Fig. 5 and described in paragraph [0104] teaches pf9-switcher or pf9-comms failure and restore “provides an alternate control channel and agent for troubleshooting and repairing failed host [agent] upgrades or other loss of communications situations. It exposes functionality equivalent to host agent, thereby allowing the host to be managed even when the host agent stops working.” Paragraph [0108] teaches “sidekick client accepts a command set similar to that of host agent. The commands include: … report system health data, create and send back a support bundle file containing log files and system information, and run specific troubleshooting or repair commands …”):
creating, by the first cluster, a clone snapshot object of the first cluster (Le, paras [0047], [0048], [0049]);
requesting, by the first cluster, the first snapshot object from the second cluster (Le, paras [0047], [0048], [0049]); and
instantiating, by the first cluster, the one or more components in the first cluster using the first snapshot object (Le, paras [0047], [0048], [0049]).
Regarding dependent claim 9, Le teaches wherein the computer system comprises one or more first hosts and one or more second hosts, the first cluster executing on the one or more first hosts and the second cluster executing on the one or more second hosts (Le, paras [0047], [0048], [0049]).
Regarding dependent claim 10, Le teaches wherein the computer system is a cloud computing platform (Le, para [0042], "This section describes the upgrade process. Once the host agent is installed and deployed (as described above), host agent connects back to customer specific SAAS controller. FIG. 8 describes a detail process for upgrading the private cloud stack. SAAS platform performs regular updates to the private cloud to fix bugs and include new software features. These upgrade may need downtime to the private cloud, and is typically communicated to the customers. SAAS platform receives a new version of the PCSS stack 800. The account manager moves to use the new version of the private stack 804. The SAAS platform sends a message to the host agent to update itself 808.").
Regarding claim 11, Le teaches:
A method comprising:
creating, by a first cluster executing on a computer system, a snapshot object for the first cluster including one or more identifiers of one or more components that have changed in the first cluster (Le, Fig. 6, para [0047], "FIG. 6 illustrates the components of an another PCSS called Kubernetes, which is seamlessly managed within the system. Kubernetes PCSS enables workloads to be deployed in components called containers, which can be thought of as lightweight virtual machines. The Kubernetes PCSS allows the creation of one or more Kubernetes clusters on a user's data center hosts. In Kubernetes terminology, a host is called node. A node can take the role of a worker node, a master node, or both. The control plane elements of a Kubernetes PCSS run in a deployment unit 601 and include a User and Authentication Manager 602 and a Node and Cluster Manager 603. The DU also hosts the same DU Shared Services that are common to all PCSS stacks, including the resource manager 604, certificate authority 605, configuration manager 607, and stats/health agent 608." Le, paragraph 0071-0073 and accompanying “>vrish list”, “virsh dumpxml 1” and data structure “instance_uuid” teaches “data structure is used to store the captured information” described in >virsh list and virsh dumpt xml and also the information in the data structure given between paragraphs 0073-0074 that is a snapshot and the >virsh list Id “1 2 3 5 10” for each “instance_uuid” component that changes in the cluster from one snapshot to the next snapshot. Paragraph 0073 teaches that a copy/duplicate of the information in the data structure according to ID (‘instance_uuid’) “describes a …document which is used to store the ‘discovered’ VMs” prior to registering with software platform. Paragraph 0046 teaches upgrading and changing json document “application/agent can be configured dynamically by host agent through its own set of commands. For example, the information about what internet protocol (IP) address to use for accepting peer servers command is one instance where the configuration is updated [i.e changed] based upon user's action on software platform SAAS user interface (UI).” Paragraph 0042 teaches “SAAS platform performs regular updates to the private cloud to fix bugs and include new software features.”), the one or more components being executable components executing in the first cluster (Le, containers/lightweight virtual machines [i.e. components] execute in a cluster, paragraph 0048 “a service called Kubelet (616) which is responsible for obtaining from the master node(s) a list of containers to run. Kubelet interacts with the container engine to try to ensure that the containers specified by the master node(s) are always running.”);
transmitting, by the first cluster, to a second cluster executing on the computer system, the snapshot object (Le, Fig. 6, para [0048]-[0049], “The control plane and other DU elements can store their state in shared database 600. The Kubernetes data plane elements comprise a common set of components which are deployed on all nodes, a set of master components which are deployed on master nodes, and a set of worker components which are deployed on worker nodes. The common set includes a container engine 612 (e.g., Docker or Rocket), a distributed database 615 (e.g., Etcd and Consul), and a network manager 613 (e.g., Flannel). The network manager is responsible for creating a container network 614 allowing containers on different nodes to communicate [i.e. transmit]. Each worker node has a service called Kubelet (616) which is responsible for obtaining from the master node(s) a list of containers to run. Kubelet interacts with the container engine to try to ensure that the containers specified by the master node(s) are always running." [i.e. transmitting … the snapshot object]). See also Fig. 2, blocks 228, 232, 236 failure or error in component results in restart/reinstall to another component); and
in response to the snapshot object, instantiate by the second cluster, copies of the one or more components on the second cluster such that the second cluster becomes a replica of the first cluster (Le, Fig. 6, para [0049], “The services specific to a master node includes an API server 617, a scheduler 618, and a controller manager 619. Together with other master nodes in the same cluster, they respond to API requests, manage the state of the cluster, and communicate with Kubelets to ensure the right containers are running on the right nodes. The state of the cluster itself is stored in a distributed key-value store managed by the distributed database component of each node in the cluster. To take advantage of Kubernetes, a user interacts with the Kubernetes Node and Cluster Manager to define one or more clusters. When first defined, a cluster is logically empty. The user then installs the host agent on one or more data center hosts. He/she then authorizes the hosts with the Kubernetes role, and specifies which cluster the host/node should be added to. The Node and Cluster Manager can automatically decide whether to make a new node a master or a worker; it can also let the user choose. Once the master/worker role is decided for a host/node, the node and cluster manager coordinates with the resource manager and configuration manager to deploy, install, and configure the correct data plane components to the host/node with the help of the host agent 611 running on each host." Paragraph 0047 teaches “Kubernetes PCSS allows the creation of one or more Kubernetes clusters on a user’s data center hosts.” As user defines one or more clusters, for the second cluster, the host agent has Master Node and Worker Node (see Fig. 6) that is initially duplicate of the first cluster and user “specifies which cluster [i.e. second cluster] the host/node should be added to”, see paragraph 0049.Paragraph 0048 teaches that initial creation of Master Nodes and Worker Nodes has “a common set of components which are deployed on all nodes, a set of master components which are deployed on master nodes, and a set of worker components which are deployed on worker nodes.” So initially, the nodes in a second cluster are replicas of first cluster. Paragraphs 0047-0048 teaches the containers contain the actual workloads to run, containers are lightweight virtual machines that can include multiple nodes. Paragraphs 0071-0074 teaches contents of workloads that are replicated for VM with multiple nodes, see above description and teachings.).
Claims 12-17 and 19-20, the method that implements the apparatus of claims 2-7 and 9-10, respectively, are rejected on the same grounds as claims 2-7 and 9-10.
Allowable Subject Matter
Claims 8 and 18 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.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been fully considered but are moot because of the new grounds of rejection given in this office action.
Applicant argues on page 8 that “In particular the "virsh list" of Le is alleged to correspond to "the snapshot object" of claim 1 and the instances represented by “instance_uuid” are alleged to be "the one or more components" of claim 1 …” The Examiner respectfully disagrees with Applicant’s argument as the claim mapping in independent claim 1 indicates the data structure given between paragraphs 0073-0074 corresponds to a snapshot and the >virsh list Id “1 2 3 5 10” for each “instance_uuid” component that changes in the cluster from one snapshot to the next snapshot. Please see updated claim mapping of claim 1. Thus, Applicant’s arguments are not persuasive and the rejections of independent claims 1 and 11 is respectfully maintained.
Applicant argues on page 9 of the Amendment submitted 12/03/2025 “paragraph 48 makes no reference to the virsh list or transmitting of the virsh list, which was previously alleged to correspond to the snapshot object of claim 1.” However, the Examiner as given in claim mapping above interprets snapshot object as the data structure given between paragraph 73-74 and indicates in new grounds of rejection the portions of Le that teach i.e transmit and i.e. transmit .. the snapshot object in the claim mapping for this limitation. Thus, Applicant’s argument is not persuasive and the Examiner respectfully maintains the rejection of claims 1 and 11.
Applicant further argues on pages 9-10:
This paragraph [49] does reference managing the state of the cluster. But there is no reference to "instantiating by the second cluster, copies of the one or more components on the second cluster such that the second cluster becomes a replica of the first cluster." If the "state" is regarded as the snapshot object, there is no reference to replicating the state. There is no reference to replicating the state such that clusters are replicas of one another. There is no reference to copying components referenced by a snapshot object. The state is transmitted to a database 600 (paragraph 48) but the database 600 is not a cluster and does not instantiate components from a snapshot object to replicate another cluster.
In view of the foregoing, Le does not disclose "in response to the snapshot object, instantiate by the second cluster, copies of the one or more components on the second cluster such that the second cluster becomes a replica of the first cluster."
The Examiner respectfully disagrees with the Applicant’s argument and interpretation of the Le prior art reference. The Examiner clearly points out in the claim mapping of this element of claim 1 how the second cluster becomes a replica of the first cluster, please see claim mapping. Thus, Applicant’s argument is not persuasive and the Examiner respectfully maintains the rejection of claims 1 and 11.
Applicant relies on the same arguments for independent claim 11 as for claim 1 and provides no further arguments.
Further, Applicant for claims 2, 6, 7 argues various limitations that are not taught by Le. However, the Examiner shows the teaching of these limitations in the appropriate claim mappings for 2, 6, 7 and thus, these arguments are not persuasive. In particular for claim 6, Applicant argues “version numbers …are not applied to the state and virsh list that were previously alleged to correspond to the snapshot object” but the Examiners claim mapping for snapshot object is clearly given in the claim mapping of claim 1 above and is not virsh list. Applicant on page 11 makes a similar argument for claim 7 relying on the claim mapping of snapshot object being unclear. Thus, Applicant’s argument is not persuasive and the Examiner respectfully maintains the rejection of claims 2, 6, and 7.
Applicant provides no other arguments for the remaining dependent claims and the Examiner respectfully maintains the rejections of these claims as given in the claim mappings above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Inquiry Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INDRANIL CHOWDHURY whose telephone number is (571)272-0446. The examiner can normally be reached Mon.-Fri. 9:30-7:00 CST.
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, Ashish Thomas can be reached at (571) 272-0631. 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.
/INDRANIL CHOWDHURY/Examiner, Art Unit 2114
/MARK D FEATHERSTONE/Supervisory Patent Examiner, Art Unit 2111