DETAILED ACTION
Status of Claims
This action is in reply to the application filed on 10/12/2023.
Claims 1-20 are currently pending and have been examined.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without integration into a practical application and without significantly more because the recited steps/operations fall within the “Mental Processes” grouping of abstract ideas.
Independent claims:
Step 1:
Regarding the independent claims, claims 1, 9 and 15 fall respectively under the “machine”, “process”, and “manufacture” statutory categories of patentable subject matter.
Step 2A, Prong One:
Claims 1, 9, and 15 are each directed to managing the state of an agent, the limitations of which encompass processes practically performed mentally or with pen and paper. The USPTO 2019 Revised Patent Subject Matter Eligibility Guidance, (Jan. 7, 2019) ("Guidance") explains that "mental processes" include acts that people can perform in their minds or using pen and paper, even if the claim recites that a generic computer component performs the acts. ("If a claim, under its broadest reasonable interpretation, covers performance in the mind but for the recitation of generic computer components, then it is still in the mental processes category unless the claim cannot practically be performed in the mind.").
Here, claim 1 recites receive an event notification indicating a state change of the virtual computing instance (VCI for brevity)…in response to receiving the event notification, determine the agent that is likely to affect due to the state change of the VCI based on mapping information and the identifier of the VCI; and manage a state of the agent based on the state change of the VCI; in view of Applicant’s Specification (AppSpec)1 the determination of the “agent that is likely to affect” refers to reading stored mapping information to find what agent ID is associated with the received VCI ID, and “manage the state” refers to updating stored agent state information to reflect the state change information of the VCI, which constitutes a mental process, involving observation and evaluation that can be practically performed in the human mind and/or with pen and paper. Claims 9 and 15 recite limitations essentially identical to those discussed above and are subject to the same analysis. Claim 15 additionally recites determine whether the virtual computing instance is powered-on, powered-off, or deleted based on the received event; the determination is made by reading what type of event is specified in received notification, which constitutes a mental process, involving observation and evaluation, and the three listed types of VCI events are simply exemplary pieces of information that do not preclude the step from being practically performed in the human mind.
Thus, consistent with the Guidance and case law, Examiner concludes claims 1, 9 and 15 are each directed to a mental process (i.e., concepts performed in the human mind, such as, an observation, evaluation, judgment, and opinion), which is an abstract idea. See e.g. Digitech Image Techs., LLC v. Elecs. For Imaging, Inc., 758 F.3d 1344, 1351 (2014) (concluding claims reciting receiving two data sets, and combining those data sets into a single data set is "an ineligible abstract process of gathering and combining data"); Electric Power Group, LLC v. Alstom S.A., (Fed. Cir. 2016) (concluding claims directed to "collecting information, analyzing it, and displaying certain results of the collection and analysis" were abstract); SAP Am., Inc. v. InvestPic, LLC, (Fed. Cir. 2018) (concluding claims were directed to the abstract idea of "selecting certain information, analyzing it using mathematical techniques, and reporting or displaying the results of the analysis").
Additional Elements Analysis (Step 2A, Prong Two and 2B):
The claims do not recite additional elements sufficient to integrate the judicial exception into a practical application; nor do the additional elements inventive concept that amounts to significantly more than the judicial exception as shown in the analysis below. Claims 1, 9 and 15 each additionally recite: store/generate mapping information that associates the identifier of the virtual computing instance with an identifier of the agent; and the notification is received from infrastructure management component residing in the data center. Claim 1 additionally recites management node comprising: a storage device…a processor communicatively coupled to the storage device; memory coupled to the processor; claim 9 additionally recites receiving, from an agent running in a virtual computing instance, monitored data of the virtual computing instance and Claim 15 additionally recites: A non-transitory computer-readable storage medium storing instructions.
Step 2A, Prong Two:
The recited management node comprising: a storage device…a processor communicatively coupled to the storage device; memory coupled to the processor; and non-transitory computer-readable storage medium storing instructions amounts to no more than mere instructions to apply the exception using a generic computer component which does not integrate the judicial exception into a practical application; “claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983” (MPEP § 2106.05(f); “The courts have also identified limitations that did not integrate a judicial exception into a practical application…Merely reciting the words "apply it" with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea” (MPEP § 2106.04(d). Regarding the additional limitations reciting receive an event notification infrastructure management component residing in the data center and receiving, from an agent running in a virtual computing instance, monitored data, even applying the interpretation that the receiving is performed by transmitting data over a network (implied by AppSpec FIG. 1), the limitation(s) still does not add any meaningful limitations to the noted abstract idea sufficient to integrate the judicial exception into a practical application because it merely represents using generic computer components to implement the abstract idea of exchanging information using a computer, or at most, constitutes the insignificant extra-solution activity as further discussed below. The recitation describing the source of the information as infrastructure management component residing in the data center and agent running in a virtual computing instance only serves to characterize the technological environment where the determining and managing is performed, and “limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)).
Step 2B:
The generic recitation of receive an event notification/monitoring data is extra-solution activity to the judicial exception recognized by the courts as a as well‐understood, routine, and conventional computer function and accordingly does not amount to significantly more than the judicial exception. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner…Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)” MPEP 2106.05(d)(II). The recited
Dependent Claims:
None of the dependent claims resolve the eligibility issues described above.
Claim 2 recites further steps of receiving and storing information and recites the additional step of generating mapping information that associates the identifier of the virtual computing instance with the identifier of the agent merely describes reorganizing the received information which constitutes a mental process that can be practically performed in the human mind and/or with pen and paper (e.g. making a mental or written note that ‘AgentX is monitoring VM1’ and is thus similarly ineligible. See e.g. Digitech Image Techs., LLC v. Elecs. For Imaging, Inc., 758 F.3d 1344, 1351 (2014) (concluding claims reciting receiving two data sets, and combining those data sets into a single data set is "an ineligible abstract process of gathering and combining data").
Claims 3, 4, 10, 11, and 16-18 each further describe the content of the information in the received notification and in the update when managing the state of the agent (e.g. claims 3/4: when the state change indicates that the virtual computing instance is powered-off/deleted…update the state of the agent to indicate that the virtual computing instance is powered-off/deleted) which does not amount to significantly more than the judicial exception above nor preclude the managing the state of the agent from being practically performed entirely in the human mind or with a pen and paper for the reasons described for the independent claims. The claims also each recite an additional ‘determine’ step (e.g. claims 3/4: when the state change indicates that the virtual computing instance is powered-off/deleted, determine a cause of a failure to receive the monitored data from the agent is due to the virtual computing instance being powered-off/deleted) that merely describes a conclusion/inference that can be made entirely through mental thought, which constitutes an abstract idea (“[A] method that can be performed by human thought alone is merely an abstract idea and is not patent-eligible under § 101.” CyberSource Corp. v. Retail Decisions, Inc., (Fed. Cir. 2011)).
Claims 6 and 13 further describe the content of the information in the notification which does not amount to significantly more than the judicial exception for the reasons described for the independent claims above.
Claims 5, 7, 8, 12, 14, 19, and 20 further describe the sources of the received information which only serves to further characterize the technological environment which does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception for the reasons described for the independent claims above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 6, 7, 9, 13-15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Zada et al. (US 2015/0154039 A1) in view of Doherty et al. (US 2016/0162317 A1).
Claim 1:
Zada discloses the limitations as shown in the rejections below:
A management node (monitoring server) comprising: a storage device to…a processor communicatively coupled to the storage device; memory coupled to the processor, wherein the memory comprises an agent management module (FIG. 1, 8; ¶0027-0028, 0043, 0097-0098).
store mapping information associating an identifier of a virtual computing instance deployed in a data center with an identifier of an agent that runs in the virtual computing instance (FIG. 10-12; ¶0035, 0043, 0051-0053, 0069-0072, 0085).
receive an event notification indicating a state change (e.g. new/created, suspended) of the virtual computing instance from an infrastructure management component residing in the data center, the event notification comprising the identifier of the virtual computing instance (¶0051, 0067-0070).
Zada does not specifically disclose in response to receiving the event notification, determine the agent that is likely to affect due to the state change of the virtual computing instance based on mapping information and the identifier of the virtual computing instance; and manage a state of the agent based on the state change of the virtual computing instance
Doherty, however, discloses (¶0025-0026) an analogous system for monitoring VMs (virtual computing instance) using monitoring programs installed thereon. Doherty further discloses receive an event notification (hypervisor activity) indicating a state change (e.g. executing, paused, stopped,…) of the virtual computing instance from an infrastructure management component (hypervisor) residing in the data center, the event notification comprising the identifier of the virtual computing instance; and in response to receiving the event notification, determine the agent that is likely to affect due to the state change of the virtual computing instance based on mapping information (list of monitored systems) and the identifier of the virtual computing instance; and manage a state of the agent based on the state change of the virtual computing instance (store updated status information) (¶0025, 0027-0029, 0078, 0046, 0072-0078, 0082), “detected hypervisor activity is associated with a change in status of a currently running VM server or a change in the configuration of the currently running VM server. Changes in status (e.g., state) of a VM server include pausing, stopping, starting, resetting, resuming, suspending, resizing, or decommissioning (e.g., deleting) of one or more instances” (¶0027)…the one or more lists of monitored systems have a section identifying the VM server instance by the status associated with the instance (e.g., executing, paused, stopped, backing-up, decommissioned, etc.) (¶0078).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada to employ Doherty’s dynamic template based monitoring to allow the monitoring configuration to be tailored to the VM’s current context and optimize cost vs. performance benefit (Doherty ¶0014-0015, 0020, 0025, 0040, 0048).
Claim 2:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada further discloses wherein the agent management module is to: receive, from the agent running in the virtual computing instance, monitored data of the virtual computing instance deployed in the data center, the monitored data comprising the identifier of the virtual computing instance; generating mapping information that associates the identifier of the virtual computing instance with the identifier of the agent; and store the mapping information in the storage device (Zada FIG. 10-12; ¶0043, 0046, 0051-0053, 0069-0072, 0085).
Claim 6:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Doherty further discloses wherein the state change of the virtual computing instance comprises a change in state for the virtual computing instance from a powered-off state to a powered-on state, from a powered-on state to a powered-off state, or the virtual computing instance being deleted/terminated from the data center (Doherty ¶0025, 0027-0029, 0078, 0046, 0072-0078, 0082)
Claim 7:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada further discloses wherein the virtual computing instance is a virtual machine (VM) executing on a host in the data center. (FIG. 1, 12; ¶0020-0022).
Claim 9:
Zada discloses the limitations as shown in the rejections below:
receiving, from an agent running in a virtual computing instance, monitored data of the virtual computing instance deployed in a data center, the monitored data comprising an identifier of the virtual computing instance; generating mapping information that associates the identifier of the virtual computing instance with an identifier of the agent (FIG. 10-12; ¶0035, 0043, 0046, 0051-0053, 0069-0072, 0085).
receiving an event notification indicating a state change (e.g. new/created, suspended) of the virtual computing instance from an infrastructure management component residing in the data center, the event notification comprising the identifier of the virtual computing instance (¶0051, 0067-0070).
Zada does not specifically disclose in response to receiving the event notification, determining the agent that is likely to affect due to the state change of the virtual computing instance based on mapping information and the identifier of the virtual computing instance; and managing a state of the agent based on the state change of the virtual computing instance
Doherty, however, discloses (¶0025-0026) an analogous system for monitoring VMs (virtual computing instance) using monitoring programs installed thereon. Doherty further discloses receive an event notification (hypervisor activity) indicating a state change (e.g. executing, paused, stopped,…) of the virtual computing instance from an infrastructure management component (hypervisor) residing in the data center, the event notification comprising the identifier of the virtual computing instance; and in response to receiving the event notification, determining the agent that is likely to affect due to the state change of the virtual computing instance based on mapping information (list of monitored systems) and the identifier of the virtual computing instance; and managing a state of the agent based on the state change of the virtual computing instance (store updated status information) (¶0025, 0027-0029, 0078, 0046, 0072-0078, 0082), “detected hypervisor activity is associated with a change in status of a currently running VM server or a change in the configuration of the currently running VM server. Changes in status (e.g., state) of a VM server include pausing, stopping, starting, resetting, resuming, suspending, resizing, or decommissioning (e.g., deleting) of one or more instances” (¶0027)…the one or more lists of monitored systems have a section identifying the VM server instance by the status associated with the instance (e.g., executing, paused, stopped, backing-up, decommissioned, etc.) (¶0078).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada to employ Doherty’s dynamic template based monitoring to allow the monitoring configuration to be tailored to the VM’s current context and optimize cost vs. performance benefit (Doherty ¶0014-0015, 0020, 0025, 0040, 0048).
Claim 13:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Doherty further discloses wherein the state change of the virtual computing instance comprises a change in state for the virtual computing instance from a powered-off state to a powered-on state, from a powered-on state to a powered-off state, or the virtual computing instance being deleted/terminated from the data center (Doherty ¶0025, 0027-0029, 0078, 0046, 0072-0078, 0082)
Claim 14:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada further discloses wherein the virtual computing instance comprises one of a virtual machine and a container executing on a host in the data center (FIG. 1, 12; ¶0020-0022).
Claim 15:
Zada discloses the limitations as shown in the rejections below:
A non-transitory computer-readable storage medium storing instructions executable by a processor of a management node (monitoring server) (FIG. 1, 8; ¶0027-0028, 0043, 0097-0098).
receive, from an agent running in a virtual computing instance, monitored data of the virtual computing instance deployed in a data center, the monitored data comprising an identifier of the virtual computing instance; generate mapping information that associates the identifier of the virtual computing instance with an identifier of the agent (FIG. 10-12; ¶0035, 0043, 0046, 0051-0053, 0069-0072, 0085).
receive an event notification indicating a state change (e.g. new/created, suspended) of the virtual computing instance from an infrastructure management component residing in the data center, the event notification comprising the identifier of the virtual computing instance (¶0051, 0067-0070).
Zada does not specifically disclose determine whether the virtual computing instance is powered-on, powered-off, or deleted based on the received event; in response to determining that the virtual computing instance is powered-on, powered-off, or deleted, identify the agent that is likely be affected due to the state change based on the mapping information; and manage a state of the agent based on the state change.
Doherty, however, discloses (¶0025-0026) an analogous system for monitoring VMs (virtual computing instance) using monitoring programs installed thereon. Doherty further discloses receive an event notification (hypervisor activity) indicating a state change (e.g. executing, paused, stopped,…) of the virtual computing instance from an infrastructure management component (hypervisor) residing in the data center; determine whether the virtual computing instance is powered-on, powered-off, or deleted based on the received event; in response to determining that the virtual computing instance is powered-on, powered-off, or deleted, identify the agent that is likely be affected due to the state change of the virtual computing instance based on mapping information (list of monitored systems) and the identifier of the virtual computing instance; and manage a state of the agent based on the state change of the virtual computing instance (store updated status information) (¶0025, 0027-0029, 0078, 0046, 0072-0078, 0082), “detected hypervisor activity is associated with a change in status of a currently running VM server or a change in the configuration of the currently running VM server. Changes in status (e.g., state) of a VM server include pausing, stopping, starting, resetting, resuming, suspending, resizing, or decommissioning (e.g., deleting) of one or more instances” (¶0027)…the one or more lists of monitored systems have a section identifying the VM server instance by the status associated with the instance (e.g., executing, paused, stopped, backing-up, decommissioned, etc.) (¶0078).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada to employ Doherty’s dynamic template based monitoring to allow the monitoring configuration to be tailored to the VM’s current context and optimize cost vs. performance benefit (Doherty ¶0014-0015, 0020, 0025, 0040, 0048).
Claim 18:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada further discloses wherein instructions to manage the state of the agent comprise instructions to: in response to determining that the virtual computing instance is powered-on, determine that the monitored data received from the agent is due to the virtual computing instance being powered-on (new, resumed) in the data center; and update the state of the agent to active to enable monitoring of the virtual computing instance (Zada FIG. 10-12; ¶0035, 0043, 0051-0053, 0069-0072, 0085). See also Doherty ¶0029-0034.
Claim 20:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada further discloses wherein the virtual computing instance comprises one of a virtual machine and a container executing on a host in the data center (FIG. 1, 12; ¶0020-0022).
Claims 3, 4, 10, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zada in view of Doherty in view of Sanakkayala et al. (US 2018/0095855 A1).
Claims 3, 10, and 16:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Doherty further discloses one of the exemplary detected VM status change events includes indicates that the virtual computing instance is powered-off (paused/suspended), but the combination of Zada/Doherty does not specifically disclose determine a cause of a failure to receive monitored data from the agent is due to the virtual computing instance being powered-off in the data center.
Sanakkayala, however, discloses (FIG. 3-4; ¶0294-0295, 0301-0303, 0431-0432) analogous methods for monitoring VMs. Sanakkayala discloses (¶0450-0452, 0458-0461) the monitoring includes receiving VM power state information indicating a state change of the virtual computing instance from an infrastructure management component (hypervisor) residing in the data center, which is used to confirm/determine a cause of a failure to receive monitored data (heartbeat timeout) from the agent (monitoring target) is due to the virtual computing instance being powered-off (suspended) in the data center; and update the state of the agent to indicate that the virtual computing instance is powered-off (suspended for maintenance)
“If the packet loss percentage exceeds this threshold, the ping monitoring logic assumes that the target VM is not reachable and the Manage Packets Thread confirms the given VM's status by illustratively querying the VM data center and/or the VM's host/server (e.g., 401) to check the VM's power state. If the VM power state is confirmed to be offline then the target VM is considered to be down. The Manage Packets Thread updates this down state to the worker monitor node (¶0452)…analyzes response(s) received from the VM infrastructure to determine whether the given VM is currently suspended for maintenance” (¶0460).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada/Doherty VM monitoring to employ Sanakkayala’s techniques of identifying and confirming VM failures to allow quick discovery of failed VMs while preventing premature or erroneous failover operations (Sanakkayala ¶0004-0008, 0416).
Claims 4, 11, and 17:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Doherty further discloses (¶0027) one of the exemplary detected VM status change events includes indicates that the virtual computing instance is deleted, but the combination of Zada/Doherty does not specifically disclose determine a cause of a failure to receive monitored data from the agent is due to the virtual computing instance being deleted n the data center.
Sanakkayala, however, discloses (FIG. 3-4; ¶0294-0295, 0301-0303, 0431-0432) analogous methods for monitoring VMs. Sanakkayala discloses (¶0451-0452, 0458-0460) the monitoring includes receiving VM power state information indicating a state change of the virtual computing instance from an infrastructure management component (hypervisor) residing in the data center, which is used to confirm/determine a cause of a failure to receive monitored data (heartbeat timeout) from the agent (monitoring target) is due to the virtual computing instance being deleted (dead, non-operational) in the data center; and update the state of the agent to indicate that the virtual computing instance is powered-off
“If the packet loss percentage exceeds this threshold, the ping monitoring logic assumes that the target VM is not reachable and the Manage Packets Thread confirms the given VM's status by illustratively querying the VM data center and/or the VM's host/server (e.g., 401) to check the VM's power state. If the VM power state is confirmed to be offline then the target VM is considered to be down. The Manage Packets Thread updates this down state to the worker monitor node (¶0452)…If the given VM is reported down (offline, dead, non-operational), the Back End Logic classifies the VM as failed” (¶0460).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada/Doherty’s VM monitoring to employ Sanakkayala’s techniques of identifying and confirming VM failures to allow quick discovery of failed VMs while preventing premature or erroneous failover operations (Sanakkayala ¶0004-0008, 0416).
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zada in view of Doherty in further view of Lefurgy et al. (US 2021/0342175 A1).
Claims 5, 12, and 19:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. Zada discloses newly started VMs are identified by issuing queries/requests to the hypervisor, not using publish-subscribe, and the combination of Zada/Doherty does not specifically disclose the limitations of claims 5, 12 and 19.
However, publish-subscribe is an old and well-known communication pattern in the computing arts including specifically in the context of monitoring VM state events as evidenced by Lefurgy disclosing (¶0066-0068) a virtual server monitor configured to receive the event notification indicating the state change of the virtual computing instance including receive the event notification from the infrastructure management component using a publish-subscribe mechanism, in which the management node subscribes to the event notification published by the infrastructure management component:
“The event service can be implemented using…publish/subscribe services that allow software components to send real-time messages to each other by publishing and subscribing to channels of messages typically organized by topic. For example, there could be an event channel for posting and receiving messages related to virtual server events…resource provisioning 81 in FIG. 2 publishes create request event 312 to the event service when it begins to provision a virtual server on physical hardware…As part of the process to start running the virtual server, the hypervisor (or host OS, or agent running on the host) publishes a run event, such as run event 314, to the event service...virtual server monitor 304 subscribes to virtual server events 310 including create request event 312 and run event 314 from the event service” (¶0066-0068)
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada/Doherty to employ publish-subscribe based messaging as taught by Lefurgy in order to reduce the amount of query/request traffic occupying the network.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Zada in view of Doherty in further view of Nanduri et al. (US 12,363,148 B1).
Claim 8:
The combination of Zada/Doherty discloses the limitations as shown in the rejections above. As shown above in each of Zada and Doherty the virtual computing instance is a VM and Zada/Doherty does not disclose wherein the virtual computing instance is a container executing on a host in the data center.
Nanduri (col. 6, li. 33-52; col. 14, li. 40-58) discloses an analogous system for agent-based monitoring of computing assets wherein “an agent may include a self-contained binary and/or other type of code or application that can be run on any appropriate platforms, including within containers and/or other virtual compute assets. Agents 38 may monitor the nodes on which they execute for a variety of different activities” ((col. 6).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zada/Doherty to employ containers instead of VMs as taught by Nanduri as it represents the simple substitution of one known type of virtualized software instance for another equivalent alternative.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
The following are directed to monitoring/tracking the health and status of distributed VMs and/or monitoring agents: US 20200065127 A1; US 20220147381 A1; US 20240248788 A1; US 20150161008 A1; “Management of Cloud Infrastructures through Agents”.
US 20160041881 A1 is directed to subscription-based notification of VM status changes.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
03/30/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
1 E.g. “When the state change indicates that virtual computing instance 104A is powered-off…agent management module 120 may update the state of agent 106A to indicate that virtual computing instance 104A is powered-off.” (¶0033).