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 . The application has been examined. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/24/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
Examiner notes that claims 13-16 directed to "A computer program product…comprising one or more computer readable storage media" relies on the special definition provided by the Specification that explicitly excludes transmission media (“A computer-readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se”, Specification, ¶[0122]). Thus, in light of this special definition, the claims are eligible.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 5-7, 10-11, 13, and 16-17 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by Singhal (2023/0208704).
Regarding claim 1, Singhal discloses a method for dynamically changing an endpoint of a singleton service, said endpoint being a network address of a pod that provides the singleton service (Singhal discloses that the IP addresses of pods for communication are dynamically allocated at pod bring up) (Singhal, para. 12), said method comprising:
determining that a first pod of multiple pods is unavailable (Singhal discloses that the controller identifies (determines) the failure based on the heartbeat failure of the pod/container crashes (unavailable)) (Singhal, para. 34; Fig. 3);
ascertaining that the singleton service's endpoint is a network address of the first pod (Singhal discloses that the controller detects a crash with the singleton microservice, it changes the label of the standby pod to “active”, which redirects traffic to the standby pod; the IP will be redirected from IP B to IP A) (Singhal, para. 33); and
in response to said ascertaining, selecting a second pod of the multiple pods as a next provider of the singleton service and replacing the singleton service's endpoint with the network address of the second pod (Singhal discloses that the controller initiates label change for existing similar pod labeled as standby to active (selecting the second pod); the singleton micro-service selector label criteria match, and newly labelled active pod become the singleton micro-service (replacing with the network address of the second pod)) (Singhal, para. 34; Fig. 3).
Regarding claim 5, Singhal discloses the method of claim 1, wherein said selecting the second pod comprises:
determining that the second pod is an available pod having a highest priority of all available pods of the multiple pods (Singhal discloses that the singleton microservice selector label criteria (priority) may match, and newly labeled active pod(s) may become part of or directed to the singleton microservice) (Singhal, para. 34).
Regarding claim 6, Singhal discloses the method of claim 1, wherein said selecting the second pod comprises:
randomly selecting the second pod from all available pods of the multiple pods in accordance with a uniform probability density function (Singhal discloses that the controller defines (selects) the service using a service spec selector (uniform probability density function), such that if the selector is set to “active,” the pod is added to the service) (Singhal, para. 31).
Regarding claim 7, Singhal discloses the method of claim 1, wherein said selecting the second pod comprises:
randomly selecting the second pod from all available pods of the multiple pods in accordance with a weighted probability density function (Singhal discloses that the controller defines (selects) the service using a service spec selector (uniform probability density function), such that if the selector is set to “active,” the pod is added to the service) (Singhal, para. 31) in which a weight of each pod is proportional to a priority of each pod (Singhal discloses that the singleton microservice selector label criteria (priority) may match, and newly labelled (weighted) active pod(s) may become part of or directed to the singleton microservice) (Singhal, para. 34).
Regarding claim 10, Singhal discloses the method of claim 1, wherein after said replacing the singleton service's endpoint with the network address of the second pod, the first pod becomes available, and wherein the method further comprises:
in response to a determination that the first pod has a higher priority (Singhal discloses that the label or selector that are attached, added, modified, and/or deleted from the target object at various times, where the label may be hierarchal (priority)) (Singhal, para. 32) than the second pod and has a higher priority than any other pod of the multiple pods, then selecting the first pod as the next provider of the singleton service and replacing the singleton service's endpoint with the network address of the first pod (Singhal discloses that the controller initiates label change for existing similar pod labeled as standby to active (selecting the second pod); the singleton micro-service selector label criteria match, and newly labelled active pod become the singleton micro-service (replacing with the network address of the second pod)) (Singhal, para. 34; Fig. 3); or
in response to a determination that the second pod has a higher priority than the first pod and has a higher priority than any other available pod of the multiple pods, then not changing the singleton service's endpoint.
Regarding claim 11, Singhal discloses the method of claim 1, wherein the multiple pods include a newly created pod and in response, the method further comprises:
determining that the newly created pod has a higher priority than any other available pod of the multiple pods (Singhal discloses that the singleton microservice selector label criteria (priority) may match, and newly labeled active pod(s) may become part of or directed to the singleton microservice) (Singhal, para. 34) and in response, selecting the newly created pod as the next provider of the singleton service and replacing the singleton service's endpoint with the network address of the newly created pod (Singhal discloses that the controller initiates label change for existing similar pod labeled as standby to active (selecting the second pod); the singleton micro-service selector label criteria match, and newly labelled active pod become the singleton micro-service (replacing with the network address of the second pod)) (Singhal, para. 34; Fig. 3).
Regarding claim 13, Singhal discloses a computer program product (Singhal, para. 44), comprising one or more computer readable storage media (Singhal, para. 44) storing computer readable program instructions, said program instructions executable by one or more processors (Singhal, para. 44) of a computer system to cause the computer system to perform operations for dynamically changing an endpoint of a singleton service (Singhal discloses that the IP addresses of pods for communication are dynamically allocated at pod bring up) (Singhal, para. 12), said operations comprising:
determining that a first pod of multiple pods is unavailable (Singhal discloses that the controller identifies (determines) the failure based on the heartbeat failure of the pod/container crashes (unavailable)) (Singhal, para. 34; Fig. 3);
ascertaining that the singleton service's endpoint is a network address of the first pod (Singhal discloses that the controller detects a crash with the singleton microservice, it changes the label of the standby pod to “active”, which redirects traffic to the standby pod; the IP will be redirected from IP B to IP A) (Singhal, para. 33); and
in response to said ascertaining, selecting a second pod of the multiple pods as a next provider of the singleton service and replacing the singleton service's endpoint with the network address of the second pod (Singhal discloses that the controller initiates label change for existing similar pod labeled as standby to active (selecting the second pod); the singleton micro-service selector label criteria match, and newly labelled active pod become the singleton micro-service (replacing with the network address of the second pod)) (Singhal, para. 34; Fig. 3).
Regarding claim 16, Singhal discloses the computer program product of claim 13, wherein said selecting the second pod comprises: determining that the second pod is an available pod having a highest priority of all available pods of the multiple pods (Singhal discloses that the singleton microservice selector label criteria (priority) may match, and newly labelled active pod(s) may become part of or directed to the singleton microservice) (Singhal, para. 34).
Regarding claim 17, Singhal discloses a computer system, comprising one or more processors (Singhal, para. 44), one or more memories (Singhal, para. 44), one or more computer readable storage media (Singhal, para. 44), and computer readable program instructions stored on the one or more computer readable storage media for execution by the one or more processors via the one or more memories to cause the computer system to perform operations for dynamically changing an endpoint of a singleton service (Singhal discloses that the IP addresses of pods for communication are dynamically allocated at pod bring up) (Singhal, para. 12), said operations comprising:
determining that a first pod of multiple pods is unavailable (Singhal discloses that the controller identifies (determines) the failure based on the heartbeat failure of the pod/container crashes (unavailable)) (Singhal, para. 34; Fig. 3);
ascertaining that the singleton service's endpoint is a network address of the first pod (Singhal discloses that the controller detects a crash with the singleton microservice, it changes the label of the standby pod to “active”, which redirects traffic to the standby pod; the IP will be redirected from IP B to IP A) (Singhal, para. 33); and
in response to said ascertaining, selecting a second pod of the multiple pods as a next provider of the singleton service and replacing the singleton service's endpoint with the network address of the second pod (Singhal discloses that the controller initiates label change for existing similar pod labeled as standby to active (selecting the second pod); the singleton micro-service selector label criteria match, and newly labelled active pod become the singleton micro-service (replacing with the network address of the second pod)) (Singhal, para. 34; Fig. 3).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
Claims 2-4, 12, 14-15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (2023/0208704) as applied to claims 1, 13, and 17 above, and further in view of Inspur Cloud Information Technology Co Ltd (CN112256401A, hereinafter Inspur).
Regarding claim 2, Singhal discloses the method of claim 1, wherein a heartbeat is sent periodically, to each other pod in accordance with a heartbeat interval and is received by each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Singhal discloses that the control task would identify if the heartbeat is not received from the configurable times from some active pod(s)/container(s)/task(s), the control task will declare the specific pod/container/task as dead and update the status of the pod/container/task in the register and advertise internally to all the required pods in the given deployment/namespace) (Singhal, para. 38).
Singhal does not explicitly disclose wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises: determining, from the received heartbeats, that the first pod is unavailable.
In analogous art, Inspur teaches wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting (Inspur discloses that the master node synchronizes the command of the configuration information modification to the nodes in the log form; the sidecar of the node analyzes the command and updates the configuration file with the heartbeat information) (Inspur, p. 4), wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Inspur discloses that the sidecar obtains and screens the IP address of the pod node of each node of the Prometheus cluster and the identification label of the pod node) (Inspur, p. 2).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to the heartbeat is sent periodically and determining that the first pod is unavailable and to combine with Singhal in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 3, Singhal and Inspur discloses the method of claim 2, wherein the sidecar in one pod of the multiple pods determines from the received heartbeats that the first pod is unavailable (Inspur discloses that the sidecar obtains and screens the IP address of the pod node of each node of the Prometheus cluster and the identification label of the pod node) (Inspur, p. 2), wherein the sidecar in the one pod performs both said selecting the second pod as the next provider of the singleton service and said replacing the singleton service's endpoint with the network address of the second pod (Inspur discloses that the node crashes, the sidecar enters in a candidate state, and updates the local configuration files and heartbeat information to the nodes with the latest index numbers) (Inspur, p. 6).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to the determining that the first pod is unavailable and selects a second pod and to combine with Singhal and Inspur in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 4, Singhal and Inspur discloses the method of claim 2, wherein each pod sends each pod's received heartbeat to a control plane, and the control plane determines from the received heartbeats that the first pod is unavailable, wherein the control plane performs both said selecting the second pod as the next provider of the singleton service and said replacing the singleton service's endpoint with the network address of the second pod (Singhal discloses that the internal controller (control plane) keeps tracks of the health of the pods and microservices in a given namespace) (Singhal, para. 24).
Regarding claim 12, Singhal discloses the method of claim 1, but does not explicitly disclose wherein the singleton service's endpoint is not initially in a persistent store, and wherein the method comprises initially starting up each pod of the multiple pods which comprises: determining, by a sidecar in each pod, whether the singleton service's endpoint is in the persistent store; in response to the sidecar in one pod determining that the singleton service's endpoint is not in the persistent store, the sidecar in the one pod writing the network address of the one pod in the persistent store as the singleton service's endpoint; or in response to the sidecar in one pod determining that the singleton service's endpoint is in the persistent store, the sidecar in the one pod not writing the network address of the one pod in the persistent store as the singleton service's endpoint.
In analogous art, Inspur teaches wherein the singleton service's endpoint is not initially in a persistent store, and wherein the method comprises initially starting up each pod of the multiple pods which comprises:
determining, by a sidecar in each pod, whether the singleton service's endpoint is in the persistent store (Inspur discloses that the master node synchronizes the command of the configuration information modification to the nodes in the log form; the sidecar of the node analyzes the command and updates the configuration file with the heartbeat information; the rebuilt pod node uses data from the persistent storage/volume to be updated) (Inspur, p. 4-5);
in response to the sidecar in one pod determining that the singleton service's endpoint is not in the persistent store, the sidecar in the one pod writing the network address of the one pod in the persistent store as the singleton service's endpoint (Inspur discloses that the node is of a master role, the sidecar on the system can modify or update the configuration modification command and persists the update operation in a log file) (Inspur, p. 5-6); or
in response to the sidecar in one pod determining that the singleton service's endpoint is in the persistent store, the sidecar in the one pod not writing the network address of the one pod in the persistent store as the singleton service's endpoint.
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to determining whether the singleton service’s endpoint is not in the persistent store and to writing the network address of the pod in the persistent store and to combine with Singhal in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 14, Singhal discloses the computer program product of claim 13, wherein a heartbeat is sent periodically, to each other pod in accordance with a heartbeat interval and is received by each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Singhal discloses that the control task would identify if the heartbeat is not received from the configurable times from some active pod(s)/container(s)/task(s), the control task will declare the specific pod/container/task as dead and update the status of the pod/container/task in the register and advertise internally to all the required pods in the given deployment/namespace) (Singhal, para. 38).
Singhal does not explicitly disclose wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable.
In analogous art, Inspur teaches wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting (Inspur discloses that the master node synchronizes the command of the configuration information modification to the nodes in the log form; the sidecar of the node analyzes the command and updates the configuration file with the heartbeat information) (Inspur, p. 4), wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Inspur discloses that the sidecar obtains and screens the IP address of the pod node of each node of the Prometheus cluster and the identification label of the pod node) (Inspur, p. 2).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to the heartbeat is sent periodically and determining that the first pod is unavailable and to combine with Singhal in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 15, Singhal and Inspur disclose the computer program product of claim 14, wherein the sidecar in one pod of the multiple pods determines from the received heartbeats that the first pod is unavailable (Inspur discloses that the sidecar obtains and screens the IP address of the pod node of each node of the Prometheus cluster and the identification label of the pod node) (Inspur, p. 2), wherein the sidecar in the one pod performs both said selecting the second pod as the next provider of the singleton service and said replacing the singleton service's endpoint with the network address of the second pod (Inspur discloses that the node crashes, the sidecar enters in a candidate state, and updates the local configuration files and heartbeat information to the nodes with the latest index numbers) (Inspur, p. 6).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to the determining that the first pod is unavailable and selects a second pod and to combine with Singhal and Inspur in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 18, Singhal discloses the computer system of claim 17, wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Singhal discloses that the control task would identify if the heartbeat is not received from the configurable times from some active pod(s)/container(s)/task(s), the control task will declare the specific pod/container/task as dead and update the status of the pod/container/task in the register and advertise internally to all the required pods in the given deployment/namespace) (Singhal, para. 38).
Singhal does not explicitly disclose wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting, wherein said determining that the first pod is unavailable comprises: determining, from the received heartbeats, that the first pod is unavailable.
In analogous art, Inspur teaches wherein a heartbeat is sent periodically, by a sidecar in each pod, to the sidecar in each other pod in accordance with a heartbeat interval and is received by the sidecar in each other pod in accordance with a timeout setting (Inspur discloses that the master node synchronizes the command of the configuration information modification to the nodes in the log form; the sidecar of the node analyzes the command and updates the configuration file with the heartbeat information) (Inspur, p. 4), wherein said determining that the first pod is unavailable comprises:
determining, from the received heartbeats, that the first pod is unavailable (Inspur discloses that the sidecar obtains and screens the IP address of the pod node of each node of the Prometheus cluster and the identification label of the pod node) (Inspur, p. 2).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to the heartbeat is sent periodically and determining that the first pod is unavailable and to combine with Singhal in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Regarding claim 20, Singhal discloses the computer system of claim 17, but does not explicitly disclose wherein the singleton service's endpoint is not initially in the persistent store, and wherein the operations comprise initially starting up each pod of the multiple pods which comprises: determining, by the sidecar in each pod, whether the singleton service's endpoint is in the persistent store; in response to the sidecar in one pod determining that the singleton service's endpoint is not in the persistent store, the sidecar in the one pod writing the network address of the one pod in the persistent store as the singleton service's endpoint; or in response to the sidecar in one pod determining that the singleton service's endpoint is in the persistent store, the sidecar in the one pod not writing the network address of the one pod in the persistent store as the singleton service's endpoint.
In analogous art, Inspur teaches wherein the singleton service's endpoint is not initially in the persistent store, and wherein the operations comprise initially starting up each pod of the multiple pods which comprises:
determining, by the sidecar in each pod, whether the singleton service's endpoint is in the persistent store (Inspur discloses that the master node synchronizes the command of the configuration information modification to the nodes in the log form; the sidecar of the node analyzes the command and updates the configuration file with the heartbeat information; the rebuilt pod node uses data from the persistent storage/volume to be updated) (Inspur, p. 4-5);
in response to the sidecar in one pod determining that the singleton service's endpoint is not in the persistent store, the sidecar in the one pod writing the network address of the one pod in the persistent store as the singleton service's endpoint (Inspur discloses that the node is of a master role, the sidecar on the system can modify or update the configuration modification command and persists the update operation in a log file) (Inspur, p. 5-6); or
in response to the sidecar in one pod determining that the singleton service's endpoint is in the persistent store, the sidecar in the one pod not writing the network address of the one pod in the persistent store as the singleton service's endpoint.
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Inspur related to determining whether the singleton service’s endpoint is not in the persistent store and to writing the network address of the pod in the persistent store and to combine with Singhal in order to enhance the efficiency of avoiding the risk of monitoring data acquisition loss of a single node (Inspur, p. 3).
Claims 8-9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (2023/0208704) as applied to claims 1 and 17 above, and further in view of Torres et al. (2025/0247312, hereinafter Torres).
Regarding claim 8, Singhal discloses the method of claim 1, but does not explicitly disclose wherein the method further comprises: determining that the singleton service's endpoint in a persistent store has changed and in response, performing a hot reload that obtains the changed singleton service's endpoint from the persistent store and connects the changed singleton service's endpoint to the singleton service.
In analogous art, Torres teaches determining that the singleton service's endpoint in a persistent store has changed and in response, performing a hot reload that obtains the changed singleton service's endpoint from the persistent store and connects the changed singleton service's endpoint to the singleton service (Torres discloses that the results from the complier are sent to a Kubernetes configmap and the configmap is updated (performing a hot reload) and sent to all the pods, which allows the pods to incorporate the compiler results and use the new image in the repository (persistent store)) (Torres, para. 26).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Torres related to determining that the endpoint has changed and in response perform a hot reload and connects the changed endpoint to the singleton service and to combine with Singhal in order to increase the efficiency of performing aggregations upon the performance indicators records over various aggregated timeframes (Torres, para. 20).
Regarding claim 9, Singhal and Torres discloses the method of claim 8, wherein ConfigMap is used as the persistent store, wherein the ConfigMap is mapped into a running pod of the multiple pods using either a ConfigMap volume or a projected volume, and wherein the running pod determines that the singleton service's endpoint in the persistent store has changed during a restart in which a container inside the running pod is stopped and started again (Torres discloses that the results from the complier are sent to a Kubernetes configmap and the configmap is updated (performing a hot reload) and sent to all the pods, which allows the pods to incorporate the compiler results and use the new image in the repository (persistent store)) (Torres, para. 26).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Torres related to the configmap that is mapped into a running pod and determines that the endpoint has changed and to combine with Singhal and Torres in order to increase the efficiency of performing aggregations upon the performance indicators records over various aggregated timeframes (Torres, para. 20).
Regarding claim 19, Singhal discloses the computer system of claim 17, but does not explicitly disclose wherein the operations further comprise: determining that the singleton service's endpoint in a persistent store has changed and in response, performing a hot reload that obtains the changed singleton service's endpoint from the persistent store and connects the changed singleton service's endpoint to the singleton service.
In analogous art, Torres teaches determining that the singleton service's endpoint in a persistent store has changed and in response, performing a hot reload that obtains the changed singleton service's endpoint from the persistent store and connects the changed singleton service's endpoint to the singleton service (Torres discloses that the results from the complier are sent to a Kubernetes configmap and the configmap is updated (performing a hot reload) and sent to all the pods, which allows the pods to incorporate the compiler results and use the new image in the repository (persistent store)) (Torres, para. 26).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Torres related to determining that the endpoint has changed and in response perform a hot reload and connects the changed endpoint to the singleton service and to combine with Singhal in order to increase the efficiency of performing aggregations upon the performance indicators records over various aggregated timeframes (Torres, para. 20).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW WOO whose telephone number is (571)270-7521. The examiner can normally be reached Telework 9:00AM-6:00PM | IFP M-F 9:00AM-6:00PM.
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, Umar Cheema can be reached at 571-270-3037. 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.
/A.W./Examiner, Art Unit 2458
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights