DETAILED ACTION
Claims 1-20 provisionally rejected under non-statutory double patenting.
Claims 1-20 rejected under 35 USC § 103.
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 .
Double Patenting
Claims 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/195394 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims recite similar limitations as directed to a monitoring buffer limit with the obvious variation of a ‘test mode.’
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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, 9-10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Van Os, U.S. PG-Publication No. 2023/0259382 A1, in view of Baltar et al., U.S. PG-Publication No. 2017/0353543 A1, further in view of Larsen et al., U.S. PG-Publication No. 2013/0111273 A1.
Claim 1
Van Os discloses a system comprising: a first endpoint; and a second endpoint executing a remote collector, wherein the remote collector is to monitor the first endpoint and send monitored information to a monitoring application. Van Os discloses a “monitoring system for monitoring applications or processes within containers.” Van Os, ¶ 25. Figure 1 illustrates a “computing architecture for monitoring a clustered application.” Id. at ¶ 37. Computer 112 comprises a monitoring server 180 and agent processor 130 that “may discover and monitor application instances that are hosted by … separate computer 111” (computer 111 → first endpoint; computer 112 → second endpoint). Monitoring server 180 functions “by periodically gathering statistics.” Id. at ¶¶ 44-45. (monitoring server 180 → remote collector). Monitoring server 180 “may combine telemetry data 191-192 … to generate telemetry data 193 that monitoring server 180 provides to agent processor 130,” and “the agent processor 130 may transmit the telemetry data to a user interface” (agent processor 130 → monitoring application). Id. at ¶ 50.
Van Os discloses the remote collector comprising: an installation unit to: install the monitoring agent with configuration data … the configuration data specifying a configuration for the monitoring agent to monitor an [application] executing in the first endpoint, A backend device 130 contains “a repository of available and reusable monitoring configurations that can be used to configure monitoring server 180 for monitoring respective applications or application instances.” Backend device 130 may “identify the application type and determine a subset of available monitoring configurations specific to the application type.” Agent processor 130 “generated merged monitoring configuration 170 by merging multiple monitoring configurations 150” and monitoring server 180 “is configured according to merged monitoring configuration 170 that may identify … which metrics to collect from which application instances.” (monitoring server is configured with configuration data → install the monitoring agent with configuration data). Id. at ¶¶ 47-49.
Van Os discloses enable the monitoring agent to monitor the [application] based on the
configuration data. Monitoring server 180 “periodically polls application instances 121-122 that respectively respond by providing telemetry data 191-192 that may contain metrics and configuration details.” The telemetry data 191-192 is filtered (“discarding unwanted or duplicate data”) to generate telemetry data 193 that is provided to agent processor 130 for further transmission to a user interface. Id. at ¶ 50. The monitoring configurations “can contain a configuration used to match the application type,” and a “configuration used to perform further metric filtering within the application type.” Id. at ¶ 67.
Van Os does not expressly disclose the remote collector comprising: an installation unit to: install the monitoring agent with configuration data on the first endpoint; the remote collector comprising: a buffer limit configuration unit to: receive a request to install a monitoring agent on the first endpoint, the request comprising an operating system type; and determine a first predefined buffer limit corresponding to the operating system type; the configuration data specifying the first predefined buffer limit as a buffer limit for the monitoring agent; and monitoring the operating system based on the configuration data with the buffer limit.
Baltar discloses the remote collector comprising: an installation unit to: install the monitoring agent with configuration data on the first endpoint. Baltar discloses a method for “determining an initial workload configuration corresponding to a workload and requesting a new custom monitoring agent and a new custom monitoring profile corresponding to the initial workload configuration and determining updated monitor tuning information corresponding to the workload” (workload → first endpoint). Baltar, ¶ 3. A workload is “a computing device … configured to provide a service,” and “may be any virtualized computing environment that can be provisioned from server 110 (e.g., a virtual machine, a container, a physical server, a cloud instance, etc.).” Id. at ¶¶ 15, 22.
Baltar discloses a configuration unit to: receive a request to install a monitoring agent on the first endpoint, the request comprising an operating system type; and determine a first configuration corresponding to the operating system type. Baltar illustrates an exemplary computing environment 100 comprising workloads 130A and 130B and “monitoring agents 132 “for managing the monitoring activities for the workload on which they reside.” A generic agent 132A can “gather configuration details corresponding to workload 130A (e.g., type of workload, operating system, number of CPU’s, disk space, applications installed, etc.) and request, from system management module 170, a new (replacement) monitoring agent that includes monitors and a monitoring profile corresponding to the gathered configuration details.” The generic agents 132A initiates an operation to uninstall the current agent and “deploy the new agent 132A” including “monitors and a custom monitoring profile corresponding to the configuration of workload 130A” (custom monitoring profile corresponding to configuration → first configuration corresponding to operating system). Id. at ¶¶ 21-25.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications of Van Os to incorporate configuring a monitor agent based on an operating system type taught by Baltar. One of ordinary skill in the art would be motivated to integrate configuring a monitor agent based on an operating system type into Van Os, with a reasonable expectation of success, in order to improve performance efficiency using “a single custom monitoring profile” to “eliminate clutter and confusion that may be experienced with the presence of multiple agents and profiles.” See Baltar, ¶ 29.
Van Os-Baltar dose not expressly disclose a buffer limit configuration unit to: determine a first predefined buffer limit corresponding to the operating system type; configuration data specifying the first predefined buffer limit as a buffer limit for the monitoring agent; and monitoring the operating system based on the configuration data with the buffer limit.
Larsen discloses a buffer limit configuration unit to: determine a first predefined buffer limit corresponding to the operating system type; configuration data specifying the first predefined buffer limit as a buffer limit for the monitoring agent. Larsen discloses a “method for providing virtual machine diagnostic information” using a “flight recorder” that is “integrated into the core of the virtual machine itself” for providing “information for profiling, and for root cause analysis of problems with the system or with software applications running thereon.” Larsen, ¶¶ 13-14. In one embodiment “virtualization/OS events can be provided as input to the flight recorder from the operating system, or from other processes such as information from the virtualization layer used to run the virtual machine,” wherein the “flight recorder engine produces an output that includes diagnostic information … which can be later analyzed by the user.” Id. at ¶¶ 18-20. The flight recorder operates by “continuously saving information to a circular buffer,” wherein event data is stored into a virtual machine global buffer. Id. at ¶¶ 21-23. The “global buffer acts as a circular buffer, with its oldest flight recorded data being dropped when the buffer becomes full.” Id. at ¶ 33. Further, “aspects of the flight recorder may be configurable at virtual machine startup, while others may be (re)configurable at later times.” The “configurable aspects include buffer size” (configurable buffer size → predefined buffer limit). Id. at ¶ 34.
Larsen discloses monitoring the operating system based on the configuration data with the buffer limit. Larsen discloses using a “mission control client, which provides a tools suite that the user can use to monitor, manage, profile and eliminate memory leaks in their applications, without introducing the performance overhead normally associated with these types of tools.” Id. at ¶ 37. Monitored events include “virtualization/OS events” including “information such as scheduling decisions by the operating system.” Id. at ¶ 18.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications of Van Os-Baltar to incorporate a monitoring buffer limit as taught by Larsen. One of ordinary skill in the art would be motivated to integrate a monitoring buffer limit into Van-Os, with a reasonable expectation of success, in order to “improve performance” by “limiting the amount of data to just that information relevant to the current profiling run.” Larsen, ¶ 31.
Claim 9
Van Os discloses wherein each of the first endpoint and the second endpoint comprises a virtual machine, a container, or a physical computing system. Van Os discloses a “monitoring system for monitoring applications or processes within containers.” Van Os, ¶ 25. Figure 1 illustrates a “computing architecture for monitoring a clustered application.” Id. at ¶ 37.
Claim 10
Claim 10 is rejected utilizing the aforementioned rationale for Claims 1 and 2; the claim is directed to a medium storing instructions executed by the system. Examiner notes claim 10 is broader in scope as it is silent as to “operating system type” features as recited in claim 1 and contains limitations directed to “application category” features as recited in claim 2.
Claim 16
Claim 16 is rejected utilizing the aforementioned rationale for Claims 1 and 2; the claim is directed to a method performed by the system.
Claims 2, 4, 11, 12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Van Os, U.S. PG-Publication No. 2023/0259382 A1, in view of Baltar et al., U.S. PG-Publication No. 2017/0353543 A1, further in view of Larsen et al., U.S. PG-Publication No. 2013/0111273 A1, further in view of Loimuneva et al., U.S. PG-Publication No. 2014/0006881 A1.
Claim 2
Van Os discloses wherein the buffer limit configuration unit is to: receive a request to monitor an application running in the first endpoint; in response to receiving the request, determine a category of the application; update the configuration data in the first endpoint to: add a configuration for the monitoring agent to monitor the application running in the first endpoint; and enable the monitoring agent to monitor the operating system and the application based on the updated configuration data. Van Os discloses that an agent processor “cooperates with a backend device that may have a repository of available monitoring configurations … that can be used to match an application instance to an available monitoring configuration” using “field names and field values in a deployment configuration to identify an application type and retrieve available monitoring configurations for the application type” (application type → category of the application). The backend device “may select and send the retrieved monitoring configuration to the agent processor that may receive and merge them into a optimized monitoring configuration that the monitoring server can use” (merge monitoring configurations → add a configuration for the monitoring agent). Van Os, ¶ 29. Figure 3A illustrates an exemplary method embodiment. At 302, agent processor is “configured to receive monitoring configurations, including those specific to the application type. At 303, agent processor is “configured to merge multiple monitoring configurations … specific to an application type, into a merged monitoring configuration for the application. At 304, the agent processor is “configured to provide the merged monitoring configuration for the application to the monitoring server,” that “configures itself to monitor metrics and status of instances of the application according to the merged monitoring configuration.” Id. at ¶¶ 69-70; FIG. 3A.
Van Os-Baltar-Larsen does not expressly disclose determine a second predefined buffer limit associated with the category of the application; and update the buffer limit of the monitoring agent to add the second predefined buffer limit to the first predefined buffer limit.
Loimuneva discloses determine a second predefined buffer limit associated with the category of the application; and update the buffer limit of the monitoring agent to add the second predefined buffer limit to the first predefined buffer limit. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications using a buffer of Van Os-Baltar-Larsen to incorporate a buffer size based on application type as taught by Loimuneva. One of ordinary skill in the art would be motivated to integrate a monitoring buffer limit into Van Os-Baltar-Larsen, with a reasonable expectation of success, in order to improve resource usage efficiency by “limiting the amount of buffer storage space required,” because “continual storing of data to a log file may require significant use of both=processor resources and storage resources.” See Loimuneva, ¶¶ 3, 13.
Claim 4
Baltar discloses wherein the installation unit is to: install a service discovery agent on the first endpoint, wherein the service discovery agent is to discover a plurality of applications running in the first endpoint and send a list of the discovered applications to the remote collector; and install a configuration agent on the first endpoint, wherein the configuration agent is to receive command from a configuration master of the remote collector and execute the command to update the configuration data. Baltar illustrates an exemplary computing environment 100 comprising workloads 130A and 130B and “monitoring agents 132 “for managing the monitoring activities for the workload on which they reside.” A generic agent 132A can “gather configuration details corresponding to workload 130A (e.g., type of workload, operating system, number of CPU’s, disk space, applications installed, etc.) and request, from system management module 170, a new (replacement) monitoring agent that includes monitors and a monitoring profile corresponding to the gathered configuration details” (generic agent → service discovery agent). The generic agents 132A initiates an operation to uninstall the current agent and “deploy the new agent 132A” including “monitors and a custom monitoring profile corresponding to the configuration of workload 130A” (custom monitoring profile corresponding to configuration → first configuration corresponding to operating system). Baltar, ¶¶ 21-25.
Baltar does not expressly disclose the configuration data including the buffer limit for enabling monitoring of an application or disabling monitoring of the application.
Loimuneva discloses the configuration data including the buffer limit for enabling monitoring of an application or disabling monitoring of the application. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications using a buffer of Van Os-Baltar-Larsen to incorporate a buffer size based on application type as taught by Loimuneva. One of ordinary skill in the art would be motivated to integrate a monitoring buffer limit into Van-Os-Larsen, with a reasonable expectation of success, in order to improve resource usage efficiency by “limiting the amount of buffer storage space required,” because “continual storing of data to a log file may require significant use of both processor resources and storage resources.” See Loimuneva, ¶¶ 3, 13.
Claims 11 and 12
Claims 11 and 12 are rejected utilizing the aforementioned rationale for Claims 2 and 4; the claims are directed to a medium storing instructions executed by the system.
Claim 17
Claim 17 is rejected utilizing the aforementioned rationale for Claim 2; the claim is directed to a method performed by the system.
Claims 3, 5-8, 13-15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Van Os, U.S. PG-Publication No. 2023/0259382 A1, in view of Baltar et al., U.S. PG-Publication No. 2017/0353543 A1, further in view of Larsen et al., U.S. PG-Publication No. 2013/0111273 A1, further in view of Loimuneva et al., U.S. PG-Publication No. 2014/0006881 A1, further in view of Kohlar et al., U.S. PG-Publication No. 2021/0314424 A1.
Claim 3
Kohlar discloses wherein the buffer limit configuration unit is to: receive a request to disable monitoring of the application; in response to receiving the request to disable monitoring of the application, determine the category of the application; reupdate the configuration data in the first endpoint to: remove the configuration for the monitoring agent to disable monitoring of the application; and enable the monitoring agent to monitor the operating system based on the reupdated configuration data. Kohlar discloses methods “to automatically manage configuration data of monitoring agents in a computing environment,” such as a “virtual computing environment.” Kohlar, ¶ 13. Monitoring agents running in endpoints “may periodically run and collect the performance metrics of the applications running therein.” Id. at ¶ 16. The method provides an “application monitoring server having an agent monitoring unit to manage configuration data lifecycle of monitoring agents,” wherein “the agent monitoring unit may determine an application to be monitored,” the “configuration data may specify a configuration for the monitoring agent installed on the endpoint to monitor the application,” and the agent monitoring unit may “instruct the monitoring agent to monitor the application according to the configuration data in the configuration file.” The “enabling and disabling monitoring of the application and updating the configuration data of the application can be done using the configuration data.” Id. at ¶¶ 20-21.
The agent monitoring unit 108 “may determine an application (e.g., A1) to be monitored” running in endpoint 104A, and bundle configuration data within a marker that specifies “a configuration … to monitor application A1. Id. at ¶¶ 29-30. Agent monitoring unit 108 “may disable monitoring of application A1 by deleting the configuration data within the marker.” Thus, “agent monitoring unit 108 may provide a start instruction to monitoring agent 106A to enable monitoring of application A1, a stop instruction to monitoring agent 106A to disable monitoring of application A1, or the like” (i.e., receiving the request to disable monitoring of the application). Id. at ¶ 39. Figure 2A illustrates user interface 200A “to receive input data 202 associated with application A1 … to be monitored.” The installed monitoring agent 106A (may discover the services (e.g., applications) running on endpoint 104A,” and obtain specific information from the user for monitoring the application. Id. at ¶¶ 43-44; See Also ¶ 55 (managing configuration data includes “enabling the monitoring of the application, disabling the monitoring of the application, and/or updating the configuration data in the configuration file”); ¶ 68 (at 402 “an endpoint for which monitoring needs to be enabled/disabled may be determined … in response to receiving a request”). Further, FIG. 2A illustrates a user interface control for activating and/or deactivating monitoring of a given application instance.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications using a buffer of Van Os-Baltar-Larsen-Loimuneva to incorporate a user interface for enabling and disabling monitoring an application as taught by Kohlar. One of ordinary skill in the art would be motivated to integrate a user interface for enabling and disabling monitoring an application into Van-Os-Baltar-Larsen-Loimuneva, with a reasonable expectation of success, in order to improve user experience in cases “where multiple applications are running along with multiple instances of each application” making it “tedious to manually configure each application across the data centers.” See Kohlar, ¶¶ 18-19.
Loimuneva discloses determine the second predefined buffer limit associated with the category of the application and update the buffer limit of the monitoring agent to deduct the second predefined buffer limit from the updated buffer limit. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
Claim 5
Kohlar discloses wherein the buffer limit configuration unit is to: render the list of the discovered applications on a user interface of the monitoring application; and receive, via the user interface of the monitoring application, a request to enable monitoring of the application from the list of discovered applications. The agent monitoring unit 108 “may determine an application (e.g., A1) to be monitored” running in endpoint 104A, and bundle configuration data within a marker that specifies “a configuration … to monitor application A1. Kohlar, ¶¶ 29-30. Agent monitoring unit 108 “may disable monitoring of application A1 by deleting the configuration data within the marker.” Thus, “agent monitoring unit 108 may provide a start instruction to monitoring agent 106A to enable monitoring of application A1, a stop instruction to monitoring agent 106A to disable monitoring of application A1, or the like” (i.e., receiving the request to disable monitoring of the application). Id. at ¶ 39. Figure 2A illustrates user interface 200A “to receive input data 202 associated with application A1 … to be monitored.” The installed monitoring agent 106A (may discover the services (e.g., applications) running on endpoint 104A,” and obtain specific information from the user for monitoring the application. Each application “may require different input data from the user which can be specified through the configuration data.” Id. at ¶¶ 43-44. The user may input monitoring configuration data required for each application via a list user interface.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of monitoring programmatic container applications using a buffer of Van Os-Baltar-Larsen-Loimuneva to incorporate a user interface for enabling and disabling monitoring an application as taught by Kohlar. One of ordinary skill in the art would be motivated to integrate a user interface for enabling and disabling monitoring an application into Van-Os-Baltar-Larsen-Loimuneva, with a reasonable expectation of success, in order to improve user experience in cases “where multiple applications are running along with multiple instances of each application” making it “tedious to manually configure each application across the data centers.” See Kohlar, ¶¶ 18-19.
Loimuneva discloses in response to receiving the request, determine a category of the application; determine a second predefined buffer limit associated with the category of the application; and send a first command including the second predefined buffer limit to the configuration agent to enable monitoring of the application. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
Claim 6
Kohlar discloses wherein the configuration agent is to execute the first command to:
update the configuration data to: add an input plugin configuration to a configuration file of the monitoring agent for monitoring the application; and restart the monitoring agent to enable the monitoring agent to monitor the operating system and the application based on the updated configuration data. Kohlar discloses that “enabling and disabling monitoring of the application and updating the configuration data of the application can be done using the configuration data within the marker.” Kohlar, ¶¶ 20-21. Agent monitoring unit 108 “may bundle the configuration data between a start marker and an end marker” to “distinguish the configuration data of the application from configuration data of other applications that are being monitored. (application configuration data → input plugin configuration). Id. at ¶ 31. Agent monitoring unit 108 “may disable monitoring of application A1 by deleting the configuration data within the marker” and “may provide a start instruction to monitoring agent 106A to enable monitoring of application A1, a stop instruction to monitoring agent 106A to disable monitoring of application A1, or the like” (start/stop instruction → restart instruction based on updated configuration data). Id. at ¶ 39.
Loimuneva discloses update the buffer limit to add the second predefined buffer limit to the first predefined buffer limit. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
Claim 7
Kohlar discloses wherein the buffer limit configuration unit is to: receive, via the user interface of the monitoring application, a request to disable monitoring of the application; in response to receiving the request, determine the category of the application. The agent monitoring unit 108 “may determine an application (e.g., A1) to be monitored” running in endpoint 104A, and bundle configuration data within a marker that specifies “a configuration … to monitor application A1. Kohlar, ¶¶ 29-30. Agent monitoring unit 108 “may disable monitoring of application A1 by deleting the configuration data within the marker.” Thus, “agent monitoring unit 108 may provide a start instruction to monitoring agent 106A to enable monitoring of application A1, a stop instruction to monitoring agent 106A to disable monitoring of application A1, or the like” (i.e., receiving the request to disable monitoring of the application). Id. at ¶ 39. Figure 2A illustrates user interface 200A “to receive input data 202 associated with application A1 … to be monitored.” The installed monitoring agent 106A (may discover the services (e.g., applications) running on endpoint 104A,” and obtain specific information from the user for monitoring the application. Id. at ¶¶ 43-44; See Also ¶ 55 (managing configuration data includes “enabling the monitoring of the application, disabling the monitoring of the application, and/or updating the configuration data in the configuration file”); ¶ 68 (at 402 “an endpoint for which monitoring needs to be enabled/disabled may be determined … in response to receiving a request”). Further, FIG. 2A illustrates a user interface control for activating and/or deactivating monitoring of a given application instance.
Loimuneva discloses determine the second predefined buffer limit associated with the category of the application; and send a second command including the second predefined buffer limit to the configuration agent to disable monitoring of the application. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
Claim 8
Kohlar discloses wherein the configuration agent is to execute the second command to:
reupdate the configuration data to: remove the input plugin configuration from the configuration file of the monitoring agent to disable the monitoring of the application; and restart the monitoring agent to enable the monitoring agent to monitor the first endpoint based on the reupdated configuration data. Kohlar discloses that “enabling and disabling monitoring of the application and updating the configuration data of the application can be done using the configuration data within the marker.” Kohlar, ¶¶ 20-21. Agent monitoring unit 108 “may bundle the configuration data between a start marker and an end marker” to “distinguish the configuration data of the application from configuration data of other applications that are being monitored. (application configuration data → input plugin configuration). Id. at ¶ 31. Agent monitoring unit 108 “may disable monitoring of application A1 by deleting the configuration data within the marker” and “may provide a start instruction to monitoring agent 106A to enable monitoring of application A1, a stop instruction to monitoring agent 106A to disable monitoring of application A1, or the like” (start/stop instruction → restart instruction based on updated configuration data). Id. at ¶ 39.
Loimuneva discloses update the buffer limit to deduct the second predefined buffer limit from the updated buffer limit. Loimuneva discloses method “for managing events associated with the operation of computer applications,” wherein the activity data “is stored in a buffer” and “is useful in troubleshooting.” The application activity data “is overwritten on a regular basis, thereby limiting the amount of buffer storage space required.” Loimuneva, ¶ 13. The method comprises a “user interface module 312” wherein “users may define event analysis parameters, buffer management procedures, error handling procedures and the like.” The method implements a “cyclic buffer 314” to store “information related to various application activity, application data, application status, and events.” Id. at ¶ 34. When determining the size of the cyclic buffer 400, “a user or developer may consider various factors, such as … the amount of activity associated with the operation of the application, the number of users accessing the application … and the like” (i.e., buffer limit associated with the category of the application). Id. at ¶ 36. In other embodiments, “the size of the cyclic buffer 400 is determined by the minimum number of log lines needed to sufficiently determine what the application was doing prior to the triggering event” (i.e., buffer limit associated with the category of the application). The initial size of the cycle buffer 400 may be “reduced in size … based on analysis of actual errors and the amount of log data needed to determine the cause of those errors.” Further, the size of the cyclic buffer 400 “can be adjusted ‘on the fly’ without restarting or otherwise interfering with the operation of the application being monitored” (i.e., update the buffer limit of the monitoring agent). Id. at ¶ 37. In one embodiment, the method determines “a buffer size for a particular applications,” whereas “alternate implementations may utilize a single buffer for multiple applications using a similar procedure.” Id. at ¶ 40.
Claims 13-15
Claims 13-15 are rejected utilizing the aforementioned rationale for Claims 5, 6, and 7+8; the claims are directed to a medium storing instructions executed by the system.
Claims 18-20
Claims 18-20 are rejected utilizing the aforementioned rationale for Claims 5, 6, and 7+8; the claims are directed to a method performed by the system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3172. The examiner can normally be reached M-F 10-6 ET.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 February 6, 2026