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 § 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, 6-7, 17-18, and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), and Degioanni (US 20230259413 A1).
Regarding Claim 1, Dugas teaches a method performed by an edge agent of an observability pipeline system, the edge agent running on a first computer node of the observability pipeline system (
Dugas discloses, “In some aspects, an edge-based data collection system discovers, collects, processes, and forwards data in an observability pipeline system. In some implementations, an edge agent of the observability pipeline system runs on a computer node. The edge agent identifies processes running on the computer node; identifies files on the computer node that the processes have opened for writing; accesses log discovery parameters of the observability pipeline system,” Abstract.), the method comprising:
receivinglog discovery filter configured to identify target logs associated with processes running on computer nodes, the log discovery filter including a filter criteria defining an operating characteristic of target logs associated with the processes (
Dugas discloses, “In some cases, the edge agent, when installed on the computer node, includes stock configurations that can provide users with immediate visibility into the computer node by providing information such as: resource usage metrics (e.g., system wide or by process), container events and metrics (e.g., docker/k8s events and metrics), corresponding log files of the running processes, or other information,” ¶ 0061,
“At 306, log discovery parameters of the observability pipeline system are accessed. In some implementations, the log discovery parameters are configured to define a set of criteria that can be applied to filter the identified files. In some implementations, the log discovery parameters include a file type parameter, a file path parameter, a file name parameter, or other types of parameters, including modification time of a file (e.g., last time a file was modified or accessed etc.), file's owner or group, file's permissions, etc.… In some instances, the log discovery parameters of the observability pipeline system may be stored locally on the computer node or remotely on the leader role of the observability pipeline system which can be accessed by the computer node through the network (e.g., the network 108 in FIG. 1),” ¶ 0063, and
“At 308, a subset of the identified files is selected according to the log discovery parameters. After accessing the log discovery parameters, criteria defined by values of the log discovery parameters are applied to the identified files. In some implementations, the identified files are filtered, and a subset of the identified files is selected according to the log discovery parameters,” ¶ 0064.);
selecting, by operation of the edge agent, one or more matching target logs associated with the processes, of a plurality of logs associated with the processes running on the first computer node, by applying the log discovery filter, the one or more matching target logs having respective operating characteristics that match the filter criteria (
Dugas discloses, “In some aspects of what is described here, log files on a computer node are discovered, data from the log files are extracted, collected, and routed by operation of an edge-based data collection system,” ¶ 0010, and “At 308, a subset of the identified files is selected according to the log discovery parameters. After accessing the log discovery parameters, criteria defined by values of the log discovery parameters are applied to the identified files. In some implementations, the identified files are filtered, and a subset of the identified files is selected according to the log discovery parameters,” ¶ 0064.);
monitoring, by operation of the edge agent, activity of the one or more matching target logs (
Dugas discloses, “The discovered log files may be added to a list which includes log files to be monitored by the observability pipeline system. In some cases, the user interface of the edge-based data collection system may further allow a user to customize how the data are extracted, formatted, or processed. Based on the list of monitored log files, the edge-based data collection system generates observability pipeline input data for further processing in the observability pipeline system,” ¶ 0011.),
and processing, by operation of the edge agent, the activity data to generate output data representing the activity of the one or more matching target logs (
Dugas discloses, “In some implementations, the data extracted from the discovered log files can be formatted to generate observability pipeline input data which can be processed by the data processing engine 134 to generate observability pipeline output data. The observability pipeline output data from the data processing engine 134 can be forwarded to other components (e.g., the leader role 112 or the worker roles 114) of the observability pipeline system 110 through the network 108 as shown in FIG. 1, where one or more sub-processes can be performed, or to data destinations 104 or data storage 106,” ¶ 0023.).
Dugas does not teach a process discovery filter;
that identifying logs equates to identifying processes, wherein the filter criteria defines an operating characteristic of target processes;
receiving, from a leader role running on a second computer node of the observability pipeline system, a process discovery filter configured to identify target processes running on computer nodes;
wherein monitoring the activity includes collecting activity data corresponding to monitored activity of the one or more matching target processes using one or more of the following monitoring sources: monitoring of system calls made by a respective process; monitoring via a system information kernel interface; monitoring using eBPF; and monitoring using function interposition.
However, Shaikh teaches that identifying logs equates to identifying processes, wherein the filter criteria defines an operating characteristic of target processes, so that the log discovery filter is the same as a process discovery filter (
Shaikh discloses, “Further, when there are multiple applications running, then multiple application log files are generated corresponding to each of the applications,” ¶ 0041, and “Referring to the FIG. 4C, in conjunction with the FIG. 4A, the filter window in the above mentioned application server (1000) is provided. Since the specific application log file is uploaded along with other details such as the version of the application, the state name, the citizenship ID of the system (100) from which the specific application log file is uploaded, the login user who uploads the application log file, the date and time of the upload, the other details can be used to filter specific application log file in the application server (1000). At step 404, the user selects the login user option to filter the application log files in the application server (1000), provides the required login user details and select option “apply” at step 406. At step 408, the filtered list of application log files are provided (as indicated in the FIG. 4D,” ¶ 0068.
Here, a log file is created for each application/process. Thus, a log discovery filter is a process discovery filter.).
Dugas and Shaikh are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas to incorporate the teachings of Shaikh and provide that the logs correspond to processes, wherein the filter criteria defines an operating characteristic of target processes. Doing so would help allow for easier detection of errors in a process if the corresponding log file shows the error (Shaikh discloses, “The proposed method helps a developer to easily identify error event failure based on the application log file and the information of the system,” ¶ 0004.).
Dugas in view of Shaikh does not teach receiving, from a leader role running on a second computer node of the observability pipeline system, a process discovery filter;
wherein monitoring the activity includes collecting activity data corresponding to monitored activity of the one or more matching target processes using one or more of the following monitoring sources: monitoring of system calls made by a respective process; monitoring via a system information kernel interface; monitoring using eBPF; and monitoring using function interposition.
However, Bitincka teaches receiving, from a leader role running on a second computer node of the observability pipeline system, a process discovery filter (
Bitincka discloses, “Load balancing processes are performed in an observability pipeline system comprising a plurality of computing resources. In some aspects, the observability pipeline system defines a leader role and worker roles,” Abstract, “Or in some cases, the leader role 112 and each worker role 114 may be deployed on distinct computer nodes. The distinct computer nodes can be, for example, distinct computer devices, virtual machines, containers, processors, or other types of computer nodes,” Col 6, Lines 56-61, and “At 362, the leader role 312 sends the data discovery task to the worker role 314; and at 364, the worker role 314 executes the data discovery task. To execute the data discovery task, the worker role 314 communicates with the data storage 306 to identify a data payload that is stored on the data storage 306 and contains event data that meet the event filter criteria,” Col 16, Lines 29-35.
Here, the leader role runs on a computer node of the observability pipeline system, separate from the worker node that runs on a different computer node of the observability pipeline system. The leader role sends a data discovery task to the worker role in order to identify data that meets filter criteria.
After the combination of Dugas in view of Shaikh, with Bitincka, the leader role sends the process discovery filter from Dugas in view of Shaikh, to the worker role, as specified by Bitincka.).
Dugas in view of Shaikh, and Bitincka are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh to incorporate the teachings of Bitincka and provide receiving, from a leader role running on a second computer node of the observability pipeline system, a process discovery filter configured to identify target processes running on computer nodes. Doing so would help allow for retrieving data from the most relevant processes, which are identified based on the filter (Bitincka discloses, “The example observability pipeline system 110 shown in FIG. 1 includes a leader role 112 and multiple worker role 114. The leader role 112 leads the overall operation of the observability pipeline system 110 by configuring and monitoring the worker roles 114; the worker roles 114 receive event data streams from the data sources 102 and data storage 106, apply observability pipeline processes to the event data, and deliver pipeline output data to the data destinations 104 and data storage 106,” Col 6, Lines 43-51.).
Dugas in view of Shaikh and Bitincka does not teach wherein monitoring the activity includes collecting activity data corresponding to monitored activity of the one or more matching target processes using one or more of the following monitoring sources: monitoring of system calls made by a respective process; monitoring via a system information kernel interface; monitoring using eBPF; and monitoring using function interposition.
However, Degioanni teaches wherein monitoring the activity includes collecting activity data corresponding to monitored activity of the one or more matching target processes using one or more of the following monitoring sources: monitoring of system calls made by a respective process; monitoring via a system information kernel interface; monitoring using eBPF; and monitoring using function interposition (
Degioanni discloses, “Capture components 134 and 144 may be kernel level modules that capture system calls from their respective OS and may include a kernel module and extended Berkeley Packet Filter (eBPF) probe for linking by host applications or containerized applications to monitor, as described further in FIG. 2. The system calls may originate from OS calls generated by programs executing on cluster node 110A, or applications 132, and programs executing on container 140, or applications 142,” ¶ 0034, and
“As shown in FIG. 2, kernel module 220 and eBPF probe 222 may be components of capture component 134 or 144 and may execute in the kernel space of cluster node 110A or container 140. Kernel module 220 may be configured to read system calls of the operating system. After processing through capture control 151 and parsing and filtering component 152, the system calls can be collected into capture files (.scap files, similar to tcpdump .pcap files) that may be analyzed using tools such as analysis tool 136 or 146. The capture files may also be stored in log data store 170, wherein parsing and filtering component 152 may utilize event intake 158 to update index 175 to reference entries in the capture files stored in log data store 170… eBPF probe 222 may be a computer program in eBPF bytecode that performs non-blocking event collection, type-based event packing, and memory mapped buffer handling, e.g. by using a per-CPU ring buffer for storing events. eBPF probe 222 may also read container-specific kernel data structures such as cgroups data and namespaces. The system calls and events are forwarded to capture control 151,” ¶ 0043, and
“GUI 185 may receive from a user or client device 180 one or more criteria for filtering event entries. GUI 185 may then use index 175 to determine a subset of entries that match the one or more criteria for retrieval from log data store 170,” ¶ 0052.
Here, the events collected by the eBPF probe are forwarded to capture control 151, where they are then processed and then saved to capture files that are stored in log data store 170. Log files that match one or more criteria are then retrieved from the log data store.).
Dugas in view of Shaikh and Bitincka, and Degioanni are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh and Bitincka to incorporate the teachings of Degioanni and provide wherein monitoring the activity includes collecting activity data corresponding to monitored activity of the one or more matching target processes using one or more of the following monitoring sources: monitoring of system calls made by a respective process; monitoring via a system information kernel interface; monitoring using eBPF; and monitoring using function interposition. Doing so would help allow for efficiently taking remedial actions if an anomaly in the monitored data is discovered (Degioanni discloses, “Events from external services may be captured in a streaming fashion using plug-ins for each type of service. When the conditions of a policy rule match a captured event, the policy rule may trigger one or more notifications and/or remedial actions,” ¶ 0027.).
Claims 18 and 24 are a computer node claim and a non-transitory computer-readable medium claim (¶ 0105 of Dugas), respectively, corresponding to the method Claim 1. Therefore, Claims 18 and 24 are rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 6, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1, wherein the activity data corresponding to monitored activity includes one or more of the following: resource utilization of a respective target process; file system activity of a respective target process; network activity of a respective target process; application activity of a respective target process; and metadata of a respective target process (
Dugas discloses, “When the observability pipeline input data is processed, resource utilization on the computer node and a duration of processing can be measured and determined,” ¶ 0040.).
Claim 23 is a computer node claim corresponding to the method Claim 6. Therefore, Claim 23 is rejected for the same reasons set forth in the rejection of Claim 6.
Regarding Claim 7, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1, wherein processing the activity data to generate output data includes formatting the activity data and causing it to be stored at a data location of the observability pipeline system (
Dugas discloses, “the data extracted from the discovered log files can be formatted to generate observability pipeline input data which can be processed by the data processing engine 134 to generate observability pipeline output data. The observability pipeline output data from the data processing engine 134 can be forwarded to other components (e.g., the leader role 112 or the worker roles 114) of the observability pipeline system 110 through the network 108 as shown in FIG. 1, where one or more sub-processes can be performed, or to data destinations 104 or data storage 106,” ¶ 0023.).
Regarding Claim 17, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1, comprising displaying, at the second computer node, the output data representing the activity of the one or more matching target processes (
Dugas discloses, “The method includes displaying a list of the identified files on a user interface of the leader role,” ¶ 0103.
Dugas already teaches displaying output data representing identified log files on the second computer node where the leader role resides. After the combination of Dugas with Shaikh, each application/process that is associated with a log file is displayed.).
Dugas and Shaikh are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas to incorporate the teachings of Shaikh and provide comprising displaying, at the second computer node, the output data representing the activity of the one or more matching target processes. Doing so would help allow for easier detection of errors in a process by displaying the errors on the user interface (Shaikh discloses, “The proposed method helps a developer to easily identify error event failure based on the application log file and the information of the system,” ¶ 0004.).
Claims 2 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Cairns (US 20180336075 A1).
Regarding Claim 2, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein: monitoring the activity includes iteratively collecting the activity data corresponding to monitored activity, and processing the activity data to generate the output data representing the activity includes iteratively processing the activity data to generate the output data.
However, Cairns teaches wherein: monitoring the activity includes iteratively collecting the activity data corresponding to monitored activity, and processing the activity data to generate the output data representing the activity includes iteratively processing the activity data to generate the output data (
Cairns discloses, “As noted with respect to FIG. 2, the computing environments described herein may collect data (e.g., as received from network devices, such as sensors, such as network devices 204-209 in FIG. 2, and client devices or other sources) to be processed as part of a data analytics project, and data may be received in real time as part of a streaming analytics environment (e.g., ESP). Data may be collected using a variety of sources as communicated via different kinds of networks or locally, such as on a real-time streaming basis. For example, network devices may receive data periodically from network device sensors as the sensors continuously sense, monitor and track changes in their environments. More specifically, an increasing number of distributed applications develop or produce continuously flowing data from distributed sources by applying queries to the data before distributing the data to geographically distributed recipients. An event stream processing engine (ESPE) may continuously apply the queries to the data as it is received and determines which entities should receive the data… The ESPE may determine or define how input data or event streams from network devices or other publishers (e.g., network devices 204-209 in FIG. 2) are transformed into meaningful output data to be consumed by subscribers, such as for example client devices 230 in FIG. 2,” ¶ 0113.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Cairns are both considered to be analogous to the claimed invention because they are in the same field of computer data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Cairns and provide wherein: monitoring the activity includes iteratively collecting the activity data corresponding to monitored activity, and processing the activity data to generate the output data representing the activity includes iteratively processing the activity data to generate the output data. Doing so would help allow for collecting and processing the data in real-time to improve efficiency (Cairns discloses, “As noted with respect to FIG. 2, the computing environments described herein may collect data (e.g., as received from network devices, such as sensors, such as network devices 204-209 in FIG. 2, and client devices or other sources) to be processed as part of a data analytics project, and data may be received in real time as part of a streaming analytics environment (e.g., ESP),” ¶ 0113.).
Claim 19 is a computer node claim corresponding to the method Claim 2. Therefore, Claim 19 is rejected for the same reasons set forth in the rejection of Claim 2.
Claims 3-4 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Reddy (US 20020091753 A1).
Regarding Claim 3, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the output data is based on activity data collected using at least two of the monitoring sources.
However, Reddy teaches wherein the output data is based on activity data collected using at least two of the monitoring sources (
Reddy discloses, “The system (10) further includes an application management layer (70) within the domain (30) that includes one or more agents (72) that each monitor applications (42) and that generate notifications in response to the occurrence of events associated with the applications (42),” Abstract, and “One or more monitors, perhaps associated with multiple agents 72, may be used to monitor a single corresponding application 42,” ¶ 0019.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Reddy are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Reddy and provide wherein the output data is based on activity data collected using at least two of the monitoring sources. Doing so would help allow for efficiently taking remedial actions based on the data, in order to ensure that the system functions properly (Reddy discloses, “For example, using an agent API, portal 20 may command an agent 72 to start, stop, or modify the operation of an application 42, may instruct an agent 72 to log particular events associated with an application 42, and may configure an agent 72 to operate in any other suitable manner. System manager 72 may also monitor the other components of application management layer 70 to ensure that they are functioning properly,” ¶ 0021.).
Claim 20 is a computer node claim corresponding to the method Claim 3. Therefore, Claim 20 is rejected for the same reasons set forth in the rejection of Claim 3.
Regarding Claim 4, Dugas in view of Shaikh, Bitincka, Degioanni, and Reddy teaches the method of claim 3, wherein the activity data collected using at least two of the monitoring sources corresponds to activity of a single matching target process of the one or more matching target processes (
Reddy discloses, “The system (10) further includes an application management layer (70) within the domain (30) that includes one or more agents (72) that each monitor applications (42) and that generate notifications in response to the occurrence of events associated with the applications (42),” Abstract, and “One or more monitors, perhaps associated with multiple agents 72, may be used to monitor a single corresponding application 42,” ¶ 0019.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Reddy are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Reddy and provide wherein the activity data collected using at least two of the monitoring sources corresponds to activity of a single matching target process of the one or more matching target processes. Doing so would help allow for efficiently taking remedial actions for the target process, based on the data, in order to ensure that the process functions properly (Reddy discloses, “For example, using an agent API, portal 20 may command an agent 72 to start, stop, or modify the operation of an application 42, may instruct an agent 72 to log particular events associated with an application 42, and may configure an agent 72 to operate in any other suitable manner. System manager 72 may also monitor the other components of application management layer 70 to ensure that they are functioning properly,” ¶ 0021.).
Claim 21 is a computer node claim corresponding to the method Claim 4. Therefore, Claim 21 is rejected for the same reasons set forth in the rejection of Claim 4.
Claims 5 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and McKinney (US 20090070457 A1).
Regarding Claim 5, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach comprising receiving, from the leader role running on the second computer node of the observability pipeline system, an indication of the activity to monitor of the one or more matching target processes.
However, McKinney teaches comprising receiving, from the leader role running on the second computer node of the observability pipeline system, an indication of the activity to monitor of the one or more matching target processes (
McKinney discloses, “Each instrumented application has an entry point (e.g., a uniform resource locator, or URL) for monitoring each transaction (e.g., an HTTP request from a browser)… If the application monitoring policy indicates that the transaction should be monitored, then any resource thresholds defined in the policy are checked. If no resource thresholds have been exceeded at the instant that the transaction arrived at the server, then the transaction is not monitored. If a predetermined resource threshold has been exceeded, then the transaction could potentially experience a performance degradation and should be monitored,” ¶ 0006.
Here, there is an indication that a transaction should be monitored based on a set of criteria.
After the combination of Dugas in view of Shaikh, Bitincka, and Degioanni, with McKinney, the leader node from Dugas sends such an indication to a worker node that an application or process should be monitored based on a set of criteria, as specified by McKinney.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and McKinney are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of McKinney and provide comprising receiving, from the leader role running on the second computer node of the observability pipeline system, an indication of the activity to monitor of the one or more matching target processes. Doing so would help allow for efficiently taking remedial actions for a target process to prevent performance issues (McKinney discloses, “If a predetermined resource threshold has been exceeded, then the transaction could potentially experience a performance degradation and should be monitored,” ¶ 0006.).
Claim 22 is a computer node claim corresponding to the method Claim 5. Therefore, Claim 22 is rejected for the same reasons set forth in the rejection of Claim 5.
Claims 8-9 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Kulkarni (US 20240111600 A1).
Regarding Claim 8, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a growth rate of resource usage by a respective target process.
However, Kulkarni teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a growth rate of resource usage by a respective target process (
Kulkarni discloses, “Example factors that can affect the overall performance of microservice systems (e.g., when a demand surge occurs in any of these factors) may include: (i) memory usage surging continuously to the maximum of committed heap, (ii) file descriptor count exceeding per process ulimit settings, (iii) TCP connections exceeding overall system limit(s), (iv) continuous high system CPU usage, (v) the overall number of threads exceeding beyond an expected range, and/or others,” ¶ 0015.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Kulkarni are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Kulkarni and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a growth rate of resource usage by a respective target process. Doing so would help allow for detecting anomalous processes that have higher resource usages so that remedial action can be taken (Kulkarni discloses, “Example factors that can affect the overall performance of microservice systems (e.g., when a demand surge occurs in any of these factors) may include: (i) memory usage surging continuously to the maximum of committed heap, (ii) file descriptor count exceeding per process ulimit settings, (iii) TCP connections exceeding overall system limit(s), (iv) continuous high system CPU usage, (v) the overall number of threads exceeding beyond an expected range, and/or others,” ¶ 0015.).
Regarding Claim 9, Dugas in view of Shaikh, Bitincka, Degioanni, and Kulkarni teaches the method of claim 8, wherein the resource usage includes one or more of the following: central processing unit (CPU) usage by a respective target process, memory usage by a respective target process, and file descriptor usage by a respective target process (
Kulkarni discloses, “In a monolithic server architecture, components invoke one another via function calls (which may utilize a single programming language). Resource requirements (such as memory, file descriptor usage, CPU usage, TCP connections) for such monolithic architectures are statically sized (e.g., since there is usually a relatively small number of services that perform unique sets of sub-operations for different use cases),” ¶ 0002.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Kulkarni are both considered to be analogous to the claimed invention because they are in the same field of computer data monitoring. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Kulkarni and provide wherein the resource usage includes one or more of the following: central processing unit (CPU) usage by a respective target process, memory usage by a respective target process, and file descriptor usage by a respective target process. Doing so would help allow for detecting anomalous processes that have higher resource usages so that remedial action can be taken (Kulkarni discloses, “Example factors that can affect the overall performance of microservice systems (e.g., when a demand surge occurs in any of these factors) may include: (i) memory usage surging continuously to the maximum of committed heap, (ii) file descriptor count exceeding per process ulimit settings, (iii) TCP connections exceeding overall system limit(s), (iv) continuous high system CPU usage, (v) the overall number of threads exceeding beyond an expected range, and/or others,” ¶ 0015.).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Abdelhalim (US 20200334102 A1).
Regarding Claim 10, Dugas in view of Shaikh, Bitincka and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file identified as a binary file that has recently crashed.
However, Abdelhalim teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file identified as a binary file that has recently crashed (
Abdelhalim discloses, “For example, client application crash-versus-OS update associations may in one exemplary embodiment be filtered on dates to limit the analysis to combinations that occur within a similar timeframe and to exclude combinations that occur too far apart. This date-filtering may be utilized to avoid the raw association-rule algorithm blindly linking old updates to recent crashes based on pure correlation. In another exemplary embodiment, OS update culprits may be restricted to OS updates that contain non-driver binaries directly implicated in crash stack traces, e.g., to narrow down culprits to one or more specific non-driver binaries and versions thereof, and their container updates. This may be accomplished in one embodiment by: 1) parsing crash stack traces from client application crashes to locate and retrieve a list of non-driver binaries involved in the client application crash; 2) parsing the contents of OS updates to get information on their payload of non-driver binaries and their versions; and 3) cross-checking modules on the stack with ones changed in an update,” ¶ 0011.
Here, a filter identifies applications/processes from binary files that have recently crashed within a certain timeframe.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Abdelhalim are both considered to be analogous to the claimed invention because they are in the same field of computer data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Abdelhalim and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file identified as a binary file that has recently crashed. Doing so would help allow taking remedial actions in response to the crash, in order to save memory.
Claims 11-13 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Kumar (US 20210240816 A1).
Regarding Claim 11, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file that matches one or more attributes.
However, Kumar teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file that matches one or more attributes (
Kumar discloses, “The terms ‘process,’ ‘executable’ and ‘application’ will, in some contexts, be used interchangeably. For example, a process may be viewed as an executable that is being executed while an application may consist of one or more processes,” ¶ 0015, “Alternatively, security filter 152 could employ the PID to retrieve the name of the process and possibly other information such as the full path of the executable,” ¶ 0021, and “The computer executable instructions may be, for example, binaries…,” ¶ 0042.
Here, target processes, which are executed via executables/binary files, are identified based on the paths of the executables.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Kumar are both considered to be analogous to the claimed invention because they are in the same field of computer data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Kumar and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running a binary file that matches one or more attributes. Doing so would help allow for detecting whether the binary file is benign or malicious based on these attributes so that remedial action can be taken if necessary.
Regarding Claim 12, Dugas in view of Shaikh, Bitincka, Degioanni, and Kumar teaches the method of claim 11, wherein the one or more attributes include one or more of the following:
a path of the binary file,
statistics corresponding to the binary file,
an owner of the binary file,
and a regular expression (regexp) of content of the binary file (
Kumar discloses, “The terms ‘process,’ ‘executable’ and ‘application’ will, in some contexts, be used interchangeably. For example, a process may be viewed as an executable that is being executed while an application may consist of one or more processes,” ¶ 0015, “Alternatively, security filter 152 could employ the PID to retrieve the name of the process and possibly other information such as the full path of the executable,” ¶ 0021, and “The computer executable instructions may be, for example, binaries…,” ¶ 0042.
Here, target processes, which are executed via executables/binary files, are identified based on the paths of the executables.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Kumar are both considered to be analogous to the claimed invention because they are in the same field of computer data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Kumar and provide wherein the one or more attributes include one or more of the following: a path of the binary file, statistics corresponding to the binary file, an owner of the binary file, and a regular expression (regexp) of content of the binary file. Doing so would help allow for detecting whether the binary file is benign or malicious, based on the path of the binary file, so that remedial action can be taken if necessary.
Regarding Claim 13, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a program running outside of a standard installation path.
However, Kumar teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a program running outside of a standard installation path (
Kumar discloses, “To enhance security, security service 151 may send the full path of the executable to security service 151 to allow security service 151 to compare the name and path of the executable to policies 200 to thereby prevent a malicious executable that is named the same as but stored in a different location from an authorized executable from modifying protected artifacts,” ¶ 0031.
Here, the standard installation path is where the disclosed authorized executable must be run. If a program is detected to be running outside of this standard installation path, it may be a malicious executable.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Kumar are both considered to be analogous to the claimed invention because they are in the same field of computer data architecture. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Kumar and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a program running outside of a standard installation path. Doing so would help allow for detecting whether the program is benign or malicious, based on the path of the binary file, so that remedial action can be taken if necessary.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Venkataramani (US 20180276383 A1).
Regarding Claim 14, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running with an elevated privilege level.
However, Venkataramani teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running with an elevated privilege level (
Venkataramani discloses, “At block 406, a determination is made whether an event has been obtained. Once an event is generated, the event may be reported by the process profiling API or the event may be retrieved from the monitored log. At block 408, the event may be parsed to determine what application process the event is related to and to extract privilege level information,” ¶ 0033, and “At block 416, a determination is made whether the privilege level associated with the event is higher than the expected privilege level. For example, the privilege level associated with the application process in the event may be compared to the privilege level for the application process in the data structure. If the privilege level in the event is greater than the privilege level in the data structure, then an unauthorized privilege escalation has occurred and execution proceeds to block 416,” ¶ 0038.
Here, a monitored log is filtered to detect whether the application/process that generated the log runs with an elevated privilege level.
After the combination of Dugas in view of Shaikh, Bitincka, and Degioanni, with Venkataramani, the process discovery filter from Dugas in view of Shaikh, Bitincka, and Degioanni would be able to identify processes that run with an elevated privilege level, as specified by Venkataramani.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Venkataramani are both considered to be analogous to the claimed invention because they are in the same field of computer data architecture. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Venkataramani and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process running with an elevated privilege level. Doing so would help allow for detecting whether the program is either benign or potentially malicious based on the elevated privilege level not being authorized by the root user of the system.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Urias (US 20200042698 A1).
Regarding Claim 15, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a socket listening on a port identified as suspicious.
However, Urias teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a socket listening on a port identified as suspicious (
Urias discloses, “Experiment Method: Several connections from the VM are made, combining both normal applications and malicious applications (as denoted by the experimenters),” ¶ 0161, and “Results: Using the CIRM sockets monitoring feature, the VM making connections and the endpoints (IPs) to which connections are made can be identified. One insight of this disclosure is the binding of the network connection to the requesting application. As can be seen in the CIRM socket log 716 of FIG. 7H, the VM (host process id 0xC27) can be seen making connections to IP 0.33 over port 80, with the process iexplorer.exe (Internet Explorer),” ¶ 00##.
Here, a process/application is associated with a socket that listens on a port. Said process/application can be determined to be suspicious if the port is identified as suspicious.
After the combination of Dugas in view of Shaikh, Bitincka, and Degioanni, with Urias, the process discovery filter from Dugas in view of Shaikh, Bitincka, and Degioanni would be able to identify processes associated with a socket that listens on a suspicious port, as specified by Urias).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Urias are both considered to be analogous to the claimed invention because they are in the same field of computer data communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Urias and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a socket listening on a port identified as suspicious. Doing so would help allow for detecting whether the program is potentially malicious based on the suspicious port.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Dugas (US 20230259438 A1) in view of Shaikh (US 20250077314 A1), Bitincka (US 11748160 B1), Degioanni (US 20230259413 A1), and Shoroff (US 6023744 A).
Regarding Claim 16, Dugas in view of Shaikh, Bitincka, and Degioanni teaches the method of claim 1. Dugas in view of Shaikh, Bitincka, and Degioanni does not teach wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a higher than expected number of open files or sockets.
However, Shoroff teaches wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a higher than expected number of open files or sockets (
Shoroff discloses, “Moreover, most operating systems limit the number of simultaneous open files that an application can have, and there is a performance penalty with a high number of simultaneous open files,” Col 2, Lines 1-5.
Here, a process/application is identified based on whether it has a high number of open files associated with it.
After the combination of Dugas in view of Shaikh, Bitincka, and Degioanni, with Shoroff, the process discovery filter from Dugas in view of Shaikh, Bitincka, and Degioanni would be able to identify processes that have a high number of open files associated with them, as specified by Shoroff.).
Dugas in view of Shaikh, Bitincka, and Degioanni, and Shoroff are both considered to be analogous to the claimed invention because they are in the same field of computer data architecture. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dugas in view of Shaikh, Bitincka, and Degioanni to incorporate the teachings of Shoroff and provide wherein the process discovery filter is configured to identify target processes using a set of criteria based on a respective target process corresponding to a higher than expected number of open files or sockets. Doing so would help allow for performing remedial actions by reducing the number of open files associated with the application in order to improve performance (Shoroff discloses, “Moreover, most operating systems limit the number of simultaneous open files that an application can have, and there is a performance penalty with a high number of simultaneous open files,” Col 2, Lines 1-5.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bajaj (US 20200092180 A1): Methods and Systems for Microservices Observability Automation
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUN whose telephone number is (571)272-6735. The examiner can normally be reached Monday-Friday 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. 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.
/ANDREW NMN SUN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights