DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 02/05/2026
Claims 1-7, 10-16, and 19-20 are currently amended
Claim 8 has been cancelled
Claims 1-7 and 9-21 are pending
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 .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 02/05/2026. Claims 1-7 and 9-21 remain pending in the application. The rejections under 35 USC 112(b) have been withdrawn in view of the amendments. However, additional rejections under 35 USC 112(b) arise herein in view of the amendments. Some outstanding claim objections have been withdrawn, some outstanding claim objections are upheld, and additional claim objections arise herein in view of the amendments.
Response to Arguments
Applicant’s arguments filed 02/05/2026, with respect to the rejections of independent claims 1, 10, and 19 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied combination of Ruggerio and Goldstein, in addition to a newly applied reference from Boyapelle et al. (US 20220035909 A1), hereinafter Boyapelle. Examiner respectfully submits that Boyapelle is sufficient to teach the newly added limitations “a computer-implemented method (CIM),comprising: in response to a closed system being initiated, receiving information associated with performance metrics of the closed system; evaluating the received information and determining whether a plurality of programs currently running on the closed system are permitted to run on the closed system; in response to determining one or more of the plurality of programs are unpermitted programs that are not permitted to run on the closed system, sending one or more instructions to the closed system that cause the one or more unpermitted programs to be terminated; in response to determining one or more of the plurality of programs are permitted programs that are permitted to run on the closed system, determining … ”.
Claim Objections
Claims 1, 10 and 19 are objected to because of the following informalities:
In Claim 1, the limitation “cause the one or more unpermitted programs to be terminated” should read: “cause one or more of the unpermitted programs to be terminated” for clarity and consistency with the antecedent basis for the unpermitted programs
In Claim 1, the limitation “determining a number of processes and threads for the respective permitted programs” should read: “determining a number of processes and threads for each of the permitted programs” for clarity and consistency with the antecedent basis for the permitted programs
In Claim 1, the limitation “determining CPU overhead …” should read: “determining central processing unit (CPU) overhead …” for clarity
In Claim 1, the limitation “determining CPU overhead consumed by the respective permitted programs” should read: “determining CPU overhead consumed by each of the permitted programs” for clarity and consistency with the antecedent basis for the permitted programs
In Claim 1, the limitation “for the permitted programs, determining whether the respective CPU overheads are in a second predetermined range” should read: “determining whether the CPU overhead corresponding to each of the permitted programs is in a second predetermined range”, or the like, for clarity and consistency with the antecedent basis for the CPU overhead and the permitted programs
In Claim 1, the limitation “determining current amounts of memory consumed by the respective permitted programs” should read: “determining current amounts of memory consumed by each of the permitted programs” for clarity and consistency with the antecedent basis for the permitted programs
In Claim 1, the limitation “for the permitted programs, determining whether the respective amounts of consumed memory are in a third predetermined range” should read: “determining whether the current amount of memory consumed by each of the permitted programs is in a third predetermined range”, or the like, for clarity and consistency with the antecedent basis for the current amount(s) of memory and the permitted programs
Independent Claims 10 and 19 include similar limitations and are objected to for at least the same reasons as Claim 1
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 and 9-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Recited throughout claim 1, the limitation(s) “a/the number of processes and threads for the program”, is not clear, because it is not clear whether the number is to be interpreted as a single number or at least 2 numbers, i.e., a number for processes and a separate number for threads. The amended claims include both limitations “the respective number of processes and threads that are in the first predetermined range” and “a respective number of processes and threads that is outside the first predetermined range”. It is not clear whether a single combined number of processes and threads should be compared against a single predetermined range, or if separate numbers of processes and threads should be compared against respective predetermined ranges. Therefore, the limitations create confusion regarding the scope of the “number of processes and threads” and their corresponding predetermined range or ranges, and the scope of the claim is unclear. For examination purposes, the numbers will be interpreted as separate numbers evaluated based on separate predetermined ranges.
In claim 1, the limitation “at least one of the permitted programs … has a combined CPU usage that is outside the second predetermined range” is unclear because it is unclear how the combined CPU usage relates to the CPU overheads determined for each of the permitted programs. Thus, the scope of the claim is unclear. For examination purposes, the limitation will be interpreted as “at least one of the permitted programs … has a CPU overhead consumption that is outside the second predetermined range”. This interpretation also represents Examiner’s suggestion for compliance with 35 USC 112(b).
Corresponding independent Claims 10 and 19 include similar limitations and are rejected for at least the same reasons as Claim 1.
Claims 2-7, 9, 11-18, and 20-21 are also rejected due to their respective dependence on Claims 1, 10, and 19
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.
Claim(s) 1-2, 10-11, 16, 19, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Boyapelle et al. (US 20220035909 A1), hereinafter Boyapelle, in view of Ruggerio (US 20110167491 A1), hereinafter Ruggerio, and Goldstein et al. (Goldstein, Y. (2020, November 9). Generate process metrics to analyze historical trends in resource consumption. Datadog. https://www.datadoghq.com/blog/process-distribution-metrics/#longer-retention-of-process-data-for-historical-analysis), hereinafter Goldstein.
Regarding Claim 1:
Boyapelle teaches a computer-implemented method (CIM), comprising: in response to a closed system being initiated (Boyapelle – Paragraph [0046]: During boot of IHS 100, Root-of-Trust (RoT) 206 is established between trust anchor 207 (e.g., a Trusted Platform Module or “TPM”), EC 120 (comprising network 209 and storage 210) executing EC firmware 210, and EFI service 211. Particularly, RoT 206 is created when trust anchor 207 establishes a trusted relationship with UEFI service 211 in the BIOS and then with PSRM agent 201. As part of the booting process, EC 120 verifies the integrity of EFI service 211, which in turn verifies the integrity of PSRM agent 201A in kernel space 202A, for example, sometimes before the OS completely boots), receiving information associated with performance metrics of the closed system; evaluating the received information (Boyapelle – Paragraph [0047]: In some cases, EC firmware 210 may be configured to receive data collected by sensors 112, and to pass that sensor data as context information on to PSRM agent 201; and Paragraph [0049]: PSRM agent 201 may also communicate with an energy estimation engine or the like (e.g., the MICROSOFT's E3 engine), which is configured to provide energy usage data broken down by applications, services, tasks, and/or hardware in an IHS. In some cases, PSRM agent 201 may use the energy estimation engine to determine, for example, whether any of applications 203 are being executed in the foreground or in the background (e.g., minimized, hidden, etc.) of the IHS's graphical user interface (GUI); and Paragraph [0050]: PSRM agent 201 may also communicate with a data collection engine (e.g., DELL's DATA VAULT) configured to collect information about an IHS's health, performance, and environment. In some cases, PSRM agent 201 may use the data collection engine to receive and maintain a database or table that includes information related to IHS hardware utilization (e.g., by application, by thread, by hardware resource, etc.), power source (e.g., AC-plus-DC, AC-only, or DC-only), etc.) and determining whether a plurality of programs currently running on the closed system are permitted to run on the closed system (Boyapelle – Paragraph [0051]: In operation, PSRM agent 201 may further monitor applications 203 executing on IHS 100 … For each of applications 203, PSRM agent 201 may use the gathered data to characterize the application's workload with various settings, memory usage, responsiveness, etc.; and Paragraph [0054]: Applications 203 and services 204 are be monitored by PSRM agent 201 and, based on their resource utilization, PSRM policies can be enforced, and malware 205 may be detected. For example, a third-party text editor accessing a webcam can be detected and mitigation actions can be subsequently taken; and Paragraph [0055]: method 300 may be executed, at least in part, by operation of PSRM agent 201. As noted above, PSRM agent 201 may monitor applications 203 and processes 204 executing on IHS 100, gather data from sensors 112 for a predetermined period of time, and use context information data to select and/or enforce a PSRM policy; and Paragraph [0056]: a PSRM policy may include a list one or more applications, one or more resources (e.g., hardware resources) associated with each application, and a restriction (e.g., allowed or forbidden, throttled, etc.) associated with each resource); in response to determining one or more of the plurality of programs are unpermitted programs that are not permitted to run on the closed system, sending one or more instructions to the closed system that cause the one or more unpermitted programs to be terminated (Boyapelle – Paragraph [0057]: At block 304, method 300 determines whether the restrictions outlined in the selected PSRM policy are being respected by applications 203. If so, block 307 concludes that the policy is being successfully enforced and block 308 evaluates the policy again after a fixed time interval. Otherwise, block 305 sends a notification to a management engine (e.g., ME 212) and/or block 306 initiates operations to stop and/or uninstalled the offending application); in response to determining one or more of the plurality of programs are permitted programs that are permitted to run on the closed system, determining … (Boyapelle – Paragraph [0057]: At block 304, method 300 determines whether the restrictions outlined in the selected PSRM policy are being respected by applications 203. If so, block 307 concludes that the policy is being successfully enforced and block 308 evaluates the policy again after a fixed time interval).
Boyapelle does not expressly teach determining a number of [processes and] threads for the respective permitted programs; for the permitted programs, determining whether the respective number of [processes and] threads are in a first predetermined range; determining CPU overhead consumed by the respective permitted programs; for the permitted programs, determining whether the respective CPU overheads are in a second predetermined range; determining current amounts of memory consumed by the respective permitted programs; for the permitted programs, determining whether the respective amounts of consumed memory are in a third predetermined range; and issuing a security alert in response to determining that at least one of the permitted programs include a respective number of [processes and] threads that is outside the first predetermined range, and has a combined CPU usage that is outside the second predetermined range, and consumes a current amount of memory that is outside the third predetermined range.
However, Ruggerio teaches determining a number of [processes and] threads for the respective permitted programs (Ruggerio – Paragraph [0015]: the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization); and Paragraph [0027]: the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process. For example and without limitation, the execution statistics may indicate a process name (either explicitly or via derivation from the execution statistics) that is not registered in the list of valid processes from the valid execution parameters database, thereby defining an invalid process); for the permitted programs, determining whether the respective number of [processes and] threads are in a first predetermined range (Ruggerio – Paragraph [0027]: the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process. For example and without limitation, the execution statistics may indicate a process name (either explicitly or via derivation from the execution statistics) that is not registered in the list of valid processes from the valid execution parameters database, thereby defining an invalid process; and Figure 2: example list of processes and corresponding execution parameters for detecting an invalid process; and Paragraph [0033]: The term "computer process" as used herein is generally defined as an execution of instructions by the computing platform to perform a particular task or application program, or portion thereof. Each application has at least one process, most typically having a process name that corresponds to the application (e.g., Microsoft Outlook has a process named outlook.exe). Each process may consist of one or more "threads" defining separate parts of the process which may be run concurrently; Examiner’s Comment: Ruggerio’s processes are interpreted to represent the claimed programs, and they are evaluated based at least on a determination of a number of threads for the program being within a threshold difference from a known valid number of threads); determining CPU overhead consumed by the respective permitted programs; for the permitted programs, determining whether the respective CPU overheads are in a second predetermined range (Ruggerio – Paragraph [0015]: the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization); and Paragraph [0027]: the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process. For example and without limitation, the execution statistics may indicate a process name (either explicitly or via derivation from the execution statistics) that is not registered in the list of valid processes from the valid execution parameters database, thereby defining an invalid process; and Figure 2: example list of processes and corresponding execution parameters for detecting an invalid process); determining current amounts of memory consumed by the respective permitted programs; for the permitted programs, determining whether the respective amounts of consumed memory are in a third predetermined range (Ruggerio – Paragraph [0015]: the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization); and Paragraph [0027]: the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process. For example and without limitation, the execution statistics may indicate a process name (either explicitly or via derivation from the execution statistics) that is not registered in the list of valid processes from the valid execution parameters database, thereby defining an invalid process; and Figure 2: example list of processes and corresponding execution parameters for detecting an invalid process); and issuing a security alert in response to determining that at least one of the permitted programs include a respective number of [processes and] threads that is outside the first predetermined range, and has a combined CPU usage that is outside the second predetermined range, and consumes a current amount of memory that is outside the third predetermined range (Ruggerio – Paragraph [0027]: At step 308, the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process; and Paragraph [0028]: If an invalid process (i.e., process name) is detected, determined at step 310, the security process monitor activates an alarm and/or generates a record of the event at step 314 to provide indicia of the invalid process to an operator/user. The indicia of the invalid process may include, for example and without limitation, the process name(s) and/or parameters that are identified or suspected to be invalid by the security process monitor).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, further incorporating Ruggerio to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ruggerio’s application monitoring metrics and permissible ranges into Boyapelle’s method for enforcing policies for applications executing in a monitored system. Ruggerio’s addition provides more performance-based measures for determining application validity and alert functionality in response to detecting invalid processes based on the performance measures.
The combination of Boyapelle and Ruggerio does not expressly teach a number of processes and threads.
However, Goldstein teaches a number of processes and threads (Goldstein – P. 3: As you explore your processes in the Live Process view, you can create a process metric by clicking on the Create Metric button. Filter and group your processes using any tags or attributes that exist in your environment (e.g., host, availability zone, service), and select a metric to track (e.g., thread count, normalized CPU percentage, RSS memory); and P. 9: In Datadog, you can build sophisticated alerts to notify you of any potential process-related issues. Live Process monitors already allow you to set threshold-based alerts on the count of processes running a certain command or on a certain subset of your infrast(ruct)ure. Distribution metrics extend this functionality by providing anomaly-based alerting for any process metric).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle and Ruggerio, further incorporating Goldstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Goldstein’s teaching to include process count thresholds per application/program/service for anomaly detection into Boyapelle and Ruggerio’s method for monitoring programs running in a closed system. Goldstein’s addition of process counts provides another metric for identifying abnormal behavior exhibited by a program or service within a monitored system.
Regarding Claim 2:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 1.
Ruggerio further teaches wherein the method is repeated periodically in an iterative fashion (Ruggerio – Paragraph [0030]: Until such time as there are no further comparisons to be made, determined at step 316, the process returns to step 308 to continue evaluating the execution statistics against the valid execution parameters. As will be appreciated, the evaluation may be performed continuously or at periodic intervals depending on the implementation).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 10:
Claim 10 is a computer program product claim with limitations corresponding to those of the method Claim 1. Therefore, Claim 10 is rejected with the same combination and rationale as that of the rejection of Claim 1.
Ruggerio further teaches the additional limitations a computer program product (CPP), comprising: a set of one or more computer-readable storage media; and program instructions, collectively stored in the set of one or more storage media, for causing a processor set to perform the following computer operations (Ruggerio – Paragraph [0032]: For example, the term "computing platform" as used herein is generally defined as any platform or combination of platforms, including but not limited to embedded IP platforms, that is operable to execute one or more computer processes and that is subject to potential security intrusions. As is well understood in the art, a computing platform includes respective processors and memory (not shown) for executing programming instructions residing in software code to effect certain transactions).
Regarding Claim 11:
Claim 11 is a computer program product claim with limitations corresponding to those of the method Claim 2. Therefore, Claim 11 is rejected with the same combination and rationale as that of the rejection of Claim 2.
Regarding Claim 16:
The combination of Boyapelle, Ruggerio, and Goldstein teaches The CPP of claim 10,.
Goldstein further teaches wherein the program instructions are for causing the processor set to further perform the following computer operations: in response to determining that the combined CPU usage of at least one of the permitted programs is in a fourth predetermined range, issuing a performance alert (Goldstein – P. 9: In Datadog, you can build sophisticated alerts to notify you of any potential process-related issues. Live Process monitors already allow you to set threshold-based alerts on the count of processes running a certain command or on a certain subset of your infrast(ruct)ure. Distribution metrics extend this functionality by providing anomaly-based alerting for any process metric. For instance, you can apply anomaly detection to the 99th percentile CPU usage of Kubernetes clusters to be automatically notified when they deviate from normal levels).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 19:
Claim 19 is a computer system claim with limitations corresponding to those of the method Claim 1 and Computer program product Claim 10. Therefore, Claim 19 is rejected with the same combination and rationale as those of the rejections of Claim 1 and Claim 10.
Ruggerio further teaches the additional limitations a computer system (CS), comprising: a processor set; a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more storage media, for causing the processor set to perform the following computer operations (Ruggerio – Paragraph [0032]: For example, the term "computing platform" as used herein is generally defined as any platform or combination of platforms, including but not limited to embedded IP platforms, that is operable to execute one or more computer processes and that is subject to potential security intrusions. As is well understood in the art, a computing platform includes respective processors and memory (not shown) for executing programming instructions residing in software code to effect certain transactions).
Regarding Claim 21:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 1.
Ruggerio further teaches further comprising: evaluating the permitted programs in light of the respective determinations made with the first predetermined range, the second predetermined range, and the third predetermined range; and generating an indication of how the closed system is operating (Ruggerio – Paragraph [0028]: If an invalid process (i.e., process name) is detected, determined at step 310, the security process monitor activates an alarm and/or generates a record of the event at step 314 to provide indicia of the invalid process to an operator/user. The indicia of the invalid process may include, for example and without limitation, the process name(s) and/or parameters that are identified or suspected to be invalid by the security process monitor; and Paragraph [0029]: If an invalid process is not detected but an invalid parameter is detected, determined at step 312, the security process monitor activates an alarm or generates a record at step 314 to provide indicia of the invalid parameter(s) to an operator/user. The indicia of invalid parameter(s) may include, for example and without limitation, indicia of excessive memory usage (indicative of a "memory leak") associated with an otherwise valid process).
The motivation to combine the arts is the same as that of Claim 1.
Claim(s) 3 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Boyapelle in view of Ruggerio, Goldstein, and Avritzer et al. (US 20100241905 A1), hereinafter Avritzer.
Regarding Claim 3:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 2.
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach wherein a period is between about 5 seconds and about 50 seconds.
However, Avritzer teaches wherein a period is between about 5 seconds and about 50 seconds (Avritzer – Paragraph [0024]: An exemplary, non-limiting performance signature may monitor one or more of: the percentage of CPU utilization; the number of active threads; memory swap percentage; working set size; percentage of memory utilization; the number of TCP resets; and the transmitted number of bytes per second. If a bucket for monitoring a component of the performance signature overflows, an algorithm according to an embodiment of the invention signals a detection of a soft-fault or a security intrusion, and triggers a software rejuvenation event. A software rejuvenation event is a pre-emptive restart of a running application or system to prevent future failures; and Paragraph [0025]: The monitoring infrastructure for a software system, for example, the Windows Management Instrumentation API, can periodically capture the performance signature. Exemplary, non-limiting periods are typically in the range of about 5 to about 10 seconds).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Avritzer to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Avritzer’s more particularly defined periodic system for application performance signature evaluation into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. Avritzer’s 5-10 second intervals for system/application evaluation would provide near-constant monitoring for abnormal behavior, thus enhancing the security of the system.
Regarding Claim 12:
Claim 12 is a computer program product claim with limitations corresponding to those of the method Claim 3. Therefore, Claim 12 is rejected with the same combination and rationale as that of the rejection of Claim 3.
Claim(s) 4-6, 9, 13-15, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Boyapelle in view of Ruggerio, Goldstein, and Obrecht et al. (US 9098333 B1), hereinafter Obrecht.
Regarding Claim 4:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 1.
Ruggerio further teaches further comprising: in response to determining that a given permitted program includes: a respective number of processes and threads that is in the first predetermined range, and a combined CPU usage that is above a first predetermined threshold (Ruggerio – Paragraph [0026]: In one embodiment, the security process monitor begins its operation by retrieving execution statistics, including system process information … from the system process monitor 104; and Paragraph [0027]: At step 308, the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process; and Paragraph [0015]: For example and without limitation, the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization)).
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach determining a priority of the given permitted program; and in response to determining the given permitted program has a low priority, ending the given permitted program.
However, Obrecht teaches determining a priority of the given permitted program (Obrecht – Col. 11, Line 3-11: In one embodiment, module 320 determines a first score for each analyzed process. This score may be considered to reflect a correspondence between the nature of the process and the objectives/goals of the entity implementing resource usage policy 340. In other words, policy 340, as will be described below, includes certain information describing what types of process attributes are valued/not valued for a particular environment or for a particular user/system); and in response to determining the given permitted program has a low priority, ending the given permitted program (Obrecht – Col. 11, Line 35-42: Corrective action module 330, in one embodiment, is executable to implement corrective actions determined by module 320. In various embodiments, module 330 causes various actions to be taken by making API calls to an operating system on client system 230. These calls may instruct the operating system to terminate a particular process, lower or raise a priority of a process, adjust memory allocated to a process, idle or awaken a process, etc.).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Obrecht to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Obrecht’s policies and rules for applications of certain priority levels to have corresponding appropriate/expected levels of processor usage into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. This combination would allow the system to identify whether certain applications consuming high processing power may be doing so by necessity, and would also facilitate identification and termination of low-priority applications over-consuming system resources.
Regarding Claim 5:
The combination of Boyapelle, Ruggerio, Goldstein, and Obrecht teaches the CIM of claim 4.
Obrecht further teaches further comprising: in response to determining the given permitted program has a high priority, intentionally reducing the priority of the given permitted program (Obrecht – Col. 11, Line 35-42: Corrective action module 330, in one embodiment, is executable to implement corrective actions determined by module 320. In various embodiments, module 330 causes various actions to be taken by making API calls to an operating system on client system 230. These calls may instruct the operating system to terminate a particular process, lower or raise a priority of a process, adjust memory allocated to a process, idle or awaken a process, etc.).
The motivation to combine the arts is the same as that of Claim 4.
Regarding Claim 6:
The combination of Boyapelle, Ruggerio, Goldstein, and Obrecht teaches the CIM of claim 4.
Ruggerio further teaches further comprising: in response to determining that an amount of memory consumed by the given permitted program is outside a third predetermined range, issuing a security alert (Ruggerio – Paragraph [0027]: At step 308, the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process; and Paragraph [0015]: For example and without limitation, the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization); and Paragraph [0028]: If an invalid process (i.e., process name) is detected, determined at step 310, the security process monitor activates an alarm and/or generates a record of the event at step 314 to provide indicia of the invalid process to an operator/user. The indicia of the invalid process may include, for example and without limitation, the process name(s) and/or parameters that are identified or suspected to be invalid by the security process monitor).
The motivation to combine the arts is the same as that of Claim 4.
Regarding Claim 9:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 1.
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach wherein the closed system is a closed storage system having hybrid flash and hard disk storage.
However, Obrecht teaches wherein the closed system is a closed storage system having hybrid flash and hard disk storage (Obrecht – Col. 56, Line 54-61: System memory 2620 is usable by processor subsystem 2680, and may include main memory 140. System memory 2620 may be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Obrecht to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Obrecht’s particular computing environment in which to apply the program evaluations into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. This addition provides context to optimize the method’s applicability in a system.
Regarding Claim 13:
Claim 13 is a computer program product claim with limitations corresponding to those of the method Claim 4. Therefore, Claim 13 is rejected with the same combination and rationale as that of the rejection of Claim 4.
Regarding Claim 14:
Claim 14 is a computer program product claim with limitations corresponding to those of the method Claim 5. Therefore, Claim 14 is rejected with the same combination and rationale as that of the rejection of Claim 5.
Regarding Claim 15:
Claim 15 is a computer program product claim with limitations corresponding to those of the method Claim 6. Therefore, Claim 15 is rejected with the same combination and rationale as that of the rejection of Claim 6.
Regarding Claim 18:
Claim 18 is a computer program product claim with limitations corresponding to those of the method Claim 9. Therefore, Claim 18 is rejected with the same combination and rationale as that of the rejection of Claim 9.
Regarding Claim 20:
The combination of Ruggerio and Goldstein teaches the CS of claim 19.
Ruggerio further teaches wherein the program instructions are for causing the processor set to further perform the following computer operations: in response to determining that a given permitted program includes: a respective number of processes and threads that are in the first predetermined range, and a combined CPU usage that is above a first predetermined threshold (Ruggerio – Paragraph [0026]: In one embodiment, the security process monitor begins its operation by retrieving execution statistics, including system process information … from the system process monitor 104; and Paragraph [0027]: At step 308, the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process; and Paragraph [0015]: For example and without limitation, the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization)); and in response to determining that an amount of memory consumed by the given permitted program is outside a third predetermined range, issue a security alert (Ruggerio – Paragraph [0027]: At step 308, the security process monitor compares the execution statistics to the corresponding valid execution parameters obtained from the valid execution parameters database to detect abnormalities (i.e., differences from the valid execution parameters) that may be indicative of a possible security intrusion or malfunction of a valid process; and Paragraph [0015]: For example and without limitation, the system process monitor 104 may compile system process information including names of one or more processes that are being executed and for each process, the memory usage, number of threads and processor utilization (e.g., CPU utilization); and Paragraph [0028]: If an invalid process (i.e., process name) is detected, determined at step 310, the security process monitor activates an alarm and/or generates a record of the event at step 314 to provide indicia of the invalid process to an operator/user. The indicia of the invalid process may include, for example and without limitation, the process name(s) and/or parameters that are identified or suspected to be invalid by the security process monitor).
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach determine a priority of the given permitted program; in response to determining the given permitted program has a low priority, end the given permitted program; in response to determining the given permitted program has a high priority, intentionally reduce the priority of the given permitted program.
However, Obrecht teaches determine a priority of the given permitted program (Obrecht – Col. 11, Line 3-11: In one embodiment, module 320 determines a first score for each analyzed process. This score may be considered to reflect a correspondence between the nature of the process and the objectives/goals of the entity implementing resource usage policy 340. In other words, policy 340, as will be described below, includes certain information describing what types of process attributes are valued/not valued for a particular environment or for a particular user/system); in response to determining the given permitted program has a low priority, end the given permitted program (Obrecht – Col. 11, Line 35-42: Corrective action module 330, in one embodiment, is executable to implement corrective actions determined by module 320. In various embodiments, module 330 causes various actions to be taken by making API calls to an operating system on client system 230. These calls may instruct the operating system to terminate a particular process, lower or raise a priority of a process, adjust memory allocated to a process, idle or awaken a process, etc.); in response to determining the given permitted program has a high priority, intentionally reduce the priority of the given permitted program (Obrecht – Col. 11, Line 35-42: Corrective action module 330, in one embodiment, is executable to implement corrective actions determined by module 320. In various embodiments, module 330 causes various actions to be taken by making API calls to an operating system on client system 230. These calls may instruct the operating system to terminate a particular process, lower or raise a priority of a process, adjust memory allocated to a process, idle or awaken a process, etc.).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Obrecht to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Obrecht’s policies and rules for applications of certain priority levels to have corresponding appropriate/expected levels of processor usage into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. This combination would enhance the system by allowing the system to identify whether certain applications consuming high processing power are doing so by necessity, and would also facilitate identification and termination of low-priority applications determined to be over-consuming system resources.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Boyapelle in view of Ruggerio, Goldstein and Kapoor et al. (US 11017300 B1), hereinafter Kapoor.
Regarding Claim 7:
The combination of Boyapelle, Ruggerio, and Goldstein teaches the CIM of claim 1.
Goldstein further teaches further comprising: in response to determining that the combined CPU usage of at least one of the programs is in a fourth predetermined range, issuing a performance alert (Goldstein – P. 9: In Datadog, you can build sophisticated alerts to notify you of any potential process-related issues. Live Process monitors already allow you to set threshold-based alerts on the count of processes running a certain command or on a certain subset of your infrast(ruct)ure. Distribution metrics extend this functionality by providing anomaly-based alerting for any process metric. For instance, you can apply anomaly detection to the 99th percentile CPU usage of Kubernetes clusters to be automatically notified when they deviate from normal levels).
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach wherein the fourth predetermined range begins at 100% of nominal CPU usage and extends upwards.
However, Kapoor teaches wherein the fourth predetermined range begins at 100% of nominal CPU usage and extends upwards (Col. 8, Line 27-54: The auto-generated incident obtaining module 206 further automatically obtains a second auto-generated incident, from the machine data (MD) analysis system 116 or the application performance management (APM) system 114, generated for the configuration item (CI), based on any specified search criteria which is a Boolean expression on key metrics of the APM system 114 or the MD system 116 being met, or detection of a deviation in the value of the key metrics of the APM system 114 or the MD system 116 from a specified threshold value … the deviation in the value of key measures or key metrics includes … a decrease in performance or an increase in CPU or memory utilization from a normal level; Examiner’s Comment: “an increase in CPU (or memory) utilization from a normal level” is interpreted to represent a range which begins at 100% of a nominal level).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Kapoor to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kapoor’s teaching to identify normal levels of application resource usage and use deviations from the normal levels to detect anomalies into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. This addition would enhance the system by providing dynamic application performance evaluation criteria for identifying abnormal and/or suspicious application behavior.
Regarding Claim 17:
The combination of Boyapelle, Ruggerio, and Goldstein teaches The CPP of claim 16.
The combination of Boyapelle, Ruggerio, and Goldstein does not expressly teach wherein the fourth predetermined range begins at 100% of nominal CPU usage and extends upwards.
However, Kapoor teaches wherein the fourth predetermined range begins at 100% of nominal CPU usage and extends upwards (Col. 8, Line 27-54: The auto-generated incident obtaining module 206 further automatically obtains a second auto-generated incident, from the machine data (MD) analysis system 116 or the application performance management (APM) system 114, generated for the configuration item (CI), based on any specified search criteria which is a Boolean expression on key metrics of the APM system 114 or the MD system 116 being met, or detection of a deviation in the value of the key metrics of the APM system 114 or the MD system 116 from a specified threshold value … the deviation in the value of key measures or key metrics includes … a decrease in performance or an increase in CPU or memory utilization from a normal level; Examiner’s Comment: “an increase in CPU (or memory) utilization from a normal level” is interpreted to represent a range which begins at 100% of a nominal level).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Boyapelle, Ruggerio, and Goldstein, further incorporating Kapoor to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kapoor’s teaching to identify normal levels of application resource usage and use deviations from the normal levels to detect anomalies into Boyapelle, Ruggerio, and Goldstein’s method for monitoring programs running in a closed system. This addition would enhance the system by providing dynamic application performance evaluation criteria for identifying abnormal and/or suspicious application behavior.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hooks (US 20170061126 A1) teaches techniques for detecting process anomalies/risks based on observed performance metrics
Butler et al. (US 9197656 B2) teaches a process for initiating a protected mode of operation of a device which includes identifying a collection of legitimate applications and terminating any applications not included in the collection
Ogale et al. (US 11182472 B2) teaches methods for process monitoring including observations of operating parameters against expected operations
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights