DETAILED ACTION
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 Arguments
Applicant's arguments filed have been fully considered but they are not persuasive.
35 USC 112 Remarks/Traversal
The Examiner acknowledges the Applicant’s arguments with respect to section A of the remarks filed on December 15, 2025. As the Examiner previously addressed in the Non-Final Office action dated October 17, 2025, there is no description of “processor-level events” and what form of examples it includes. It is a broad term that could mean anything from observed internal physical operational characteristics of the processor to how instructions are processed by the processor when read from memory. The referenced sections of paragraphs 0002, 0013, 0014, and 0015 are vague and general teachings without specific examples of implementation. The Applicant had previously amended the claims in a manner that introduce a narrow representation of “processor-level events” that relies upon a broad disclosure that is absent of teaching how one of ordinary skill how to make use of the instant claim limitations.
The language is additionally used in claims 2, 4-8, and 10-19. The Examiner finds the Applicant’s argument moot, and hereby maintains the current grounds of the rejection under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
The Examiner acknowledges the Applicant’s reliance upon support for outside literature in section B of the remarks filed on December 15, 2025. As per MPEP 2161 I. B. , “The proscription against the introduction of new matter in a patent application (35 U.S.C. 132 and 251) serves to prevent an applicant from adding information that goes beyond the subject matter originally filed. See In re Rasmussen, 650 F.2d 1212, 1214, 211 USPQ 323, 326 (CCPA 1981); see also MPEP 2163.06 through 2163.07 for a more detailed discussion of the written description requirement and its relationship to new matter. The claims as filed in the original specification are part of the disclosure and, therefore, if an application as originally filed contains a claim disclosing material not found in the remainder of the specification, the applicant may amend the specification to include the claimed subject matter. In re Benno, 768 F.2d 1340, 226 USPQ 683 (Fed. Cir. 1985). Thus, the written description requirement prevents an applicant from claiming subject matter that was not adequately described in the specification as filed. New or amended claims which introduce elements or limitations that are not supported by the as-filed disclosure violate the written description requirement. See, e.g., In re Lukach, 442 F.2d 967, 169 USPQ 795 (CCPA 1971) (subgenus range was not supported by generic disclosure and specific example within the subgenus range); In re Smith, 458 F.2d 1389, 1395, 173 USPQ 679, 683 (CCPA 1972) (an adequate description of a genus may not support claims to a subgenus or species within the genus).
While there is no in haec verba requirement, newly added claims or claim limitations must be supported in the specification through express, implicit, or inherent disclosure.”
The Applicant fails to show how the claimed limitations were in possession at the time of filing of the instant application. The Examples provided by the Applicant from the known prior art teachings listed are situations that “could be” applied to the instant application as are known in the art to one of ordinary skill, and are not part of an inherent disclosure as the Applicant is attempting to incorporate. The Applicant fails to implicitly provide a curated disclosure adequately describing “processor level events”. The omission of the limitation from the original disclosure raises an issue regarding whether the inventor had possession of a broader, more generic invention. “The fundamental factual inquiry is whether the specification conveys with reasonable clarity to those skilled in the art that, as of the filing date sought, the inventor was in possession of the invention as now claimed. See, e.g., Vas-Cath, Inc., 935 F.2d at 1563-64, 19 USPQ2d at 1117.” MPEP 2161 I. B. The originally filed disclosure fails to adequately describe the terms “processor-level events”, the Examiner finds the Applicant’s arguments to be unpersuasive.
With respect to the arguments pertaining to the Examiner’s assertion that the term is “broad” misapplies 35 U.S.C. 112 in section C of the remarks, the Examiner disagrees with the Applicant’s arguments that the Examiner’s assertion is not supported by any evidence, and is inconsistent with how the term “processor-level event” is actually used in the art. The burden falls on the Applicant to demonstrate how the claimed limitations was in possession at the time of filing of the instant application. The Examiner recognizes that many various forms exist in the prior art, the Applicant fails to adequately describe specific implementations of “processor-level events” in the originally filed pages 1-10 of the disclosure. The Applicant relies upon a disclosure that lacks specificity and related examples, then argues the amended claim language that is narrower in scope than the originally filed disclosure. The “processor-level events” are not part of an inherent disclosure, raising the question of was the Applicant in possession of the limitations at the time of filing of the instant application, which the Applicant has failed to provide support. The Examiner maintains the current grounds of the rejection.
With respect to claims 2 and 18, the arguments pertaining to “microarchitectural operation of the processor”, the Applicant asserts the “Examiner’s conclusion of therefore both legally incorrect and factually inconsistent with the disclosure.” The Examiner respectfully disagrees, as addressed in the above section, the burden falls on the Applicant to demonstrate how the claimed limitations was in possession at the time of filing of the instant application. The Applicant relies upon a disclosure that lacks specificity and related examples, then argues the amended claim language that is narrower in scope than the originally filed disclosure. The “microarchitectural operation of the processor” are not part of an inherent disclosure, raising the question of was the Applicant in possession of the limitations at the time of filing of the instant application, which the Applicant has failed to provide support. The Examiner maintains the current grounds of the rejection.
With respect to the rejection under 35 U.S.C. 102 (a)(1) as being anticipated by Yamada, the Applicant is correct in summarizing that claims 1, 2, 9, and 10 are rejected under Yamada.
Applicant argues:
“Yamada describes PMU hardware counters; not alerts. Yamada's PMU: collects information from recent instructions executed, maintains heuristics and thresholds generates performance monitoring interrupts (PMIs) when thresholds are exceeded.”
The Examiner notes the Applicant’s statement.
It is then argued:
“But a PMI is not a "local alert" in the meaning of the claim. Per the Specification, a local alert is: generated by a local detector separate from the PMU, produced after processing raw PMU events, a filtered, consumable, higher-level semantic classification of events. Yamada's PMU outputs are: raw hardware events, unfiltered, generated directly by PMU counters, not the output of a local detector. Thus, the Examiner's mapping is incorrect.”
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., argued definition of “local alert” from the specification) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The Examiner finds the teachings of Yamada to be equivalent as mapped in the rejection below, and hereby maintains the current grounds of the rejection. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Applicant argues:
“Additionally, claim 1 requires: "a timing relationship for the processor-level event." This means the alert itself must include information expressing a temporal relationship for that same event (e.g., order, spacing, latency, or timing metadata tied to that specific processor-level event).
In contrast, Yamada's heuristics: are not packaged with the event, do not represent a timing relationship for each event, do not provide per-event timing metadata, are simply counters compared against thresholds.
Yamada never discloses: embedding timing information in the alert, associating timing metadata with each PMU event, providing the alert as a composite of processor-level event + timing relationship. Therefore, a required claim element is missing.””
The Examiner respectfully disagrees, as rejected by the Examiner, the PMU (local detector) gathers information from recent instructions executed by the local processor core (i.e., processor level events executed by the processor core of the data processing system (i.e., processing unit), wherein a heuristic counters (i.e., timing relationship for the recently executed instructions), column 4, lines 43-46 & 55-62 and threshold values (timing relationship, i.e., certain counts reaching a predefined threshold value) to define the conditions which will cause the PMU to generate PMIs due to execution anomalies, column 5, lines 13-15. The events and timing relationship are a composite value, contrary to the Applicant’s assertion. The current grounds of the rejection are hereby maintained. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The arguments continue:
“The Examiner asserts that Yamada's heuristic event handler or lightweight code analysis meets the limitation: "filtering the local alerts to determine processor-level events indicating undesirable behavior." There are two fatal problems with this contention. First, Yamada filters PMU events, not local alerts. As established above, Yamada has no "local alerts" - it therefore cannot filter them. Second, Yamada's filtering is not determining processor-level events indicating undesirable behavior Yamada's filtering: identifies whether a PMI should trigger deeper analysis, does not classify processor events as undesirable, does not transform alerts into higher-level classifications. Filtering in Yamada is merely a threshold gating mechanism. It is neither the claimed filtering nor equivalent to it.
The claim requires: "responsive to the determination that there are processor-level events indicating undesirable behavior ... generating a system alert." Yamada's system alert is only triggered when a PMI occurs, and the execution analysis engine determines a control-flow attack. Therefore, Yamada's system alert is not based on filtered local alerts. Yamada is based on analysis of program execution semantics, not processor-level events per se. Thus, the claimed responsive behavior is not present.
At a high level, Yamada is performing tasks, which are fundamentally different from those claimed. Yamada is directed to a performance monitoring interrupt (PMI)-based anomaly detection framework, in which a PMU periodically samples aggregate instruction-execution behavior and triggers a PMI when heuristics (e.g., instruction count thresholds across a sliding instruction window) indicate a potential anomaly. A PMI is simply a hardware interrupt raised when counter thresholds are met. A PMI is not a processor-level event, nor does it contain event- level information. In fact, PMIs represent secondary, system-level notifications generated after raw microarchitectural events occur, and carry no information about the underlying event type, timing, ordering, or semantics. As such, Yamada never exposes or reports individual processor- level events-such as cache misses, branch mispredictions, or retired instructions-nor does it provide timing relationships for such events. Yamada's PMU merely accumulates low-level microarchitectural activity and signals a PMI interrupt upon threshold violation; therefore, a PMI is a coarse alarm, not an event, and is fundamentally different from the processor-level events required by the claims.”
The Examiner disagrees, the filtering of the events are “local events” since they are of the transaction hardware core, column 7, lines 25-33. Furthermore, it is disclosed wherein the filtering indicates that an anomalous event should be analyzed some more where the event is flagged as suspicious (system alert) to make a further determination if the event reflects a control flow attack, column 8, lines 37-45 & 50-56. The Examiner finds the Applicant’s arguments to be non-persuasive, and maintains the current grounds of the rejection. Yamada has been shown to disclose of “detecting processor-level events, generating local alerts that contain information of a processor-level event, and providing any timing relationships for those events.” The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Examiner notes the Applicant’s comments with respect to known prior art examples with respect to Yamada in view of the claims.
With respect to the rejection under 35 U.S.C. 102 (a)(1) as being anticipated by Shanmugavelayutham (Shan), the Applicant’s summary is noted by the Examiner.
The Applicant argues:
“Shan fails to anticipate:
“(1) "receiving local alerts from a local detector that detects processor-level events from a processing unit, wherein each local alert comprises information of a processor-level event from the processing unit and a timing relationship for the processor-level event"
The Office Action appears to map: Shan's PMU hardware + LBR stack to the claimed "local detector," and Shan's PMU counts / branch statistics to the claimed "local alerts." That mapping does not withstand scrutiny.
First, Shan's PMU and LBR simply collect raw microarchitectural measurements (branch misprediction data, RET counts, last branch records) for later analysis. They are not described as generating a "local alert" or any other higher-level, consumable indication. The PMU counters are configured to count RET instructions or branch anomalies, and the counts are compared to thresholds, but the underlying data are still just aggregate counts and history, not a structured alert that is "received" by another detector.””
The Examiner respectfully disagrees with the Applicant’s position. Shan teaches of hardware PMU, and related registers and LBR stack information collects mis-predicted branch data (interpreted as processor-level events) for analysis occurring in the core (CPU), column 6, lines 10-21 and column 7, lines 37-39. The Examiner has shown how Shan discloses of collecting “processor-level events”, and finds the Applicant’s arguments to be non-persuasive. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
It is then argued:
“Second, claim 1 requires that each local alert "comprises information of a processor-level event ... and a timing relationship for the processor-level event." Even accepting the Examiner's mapping, Shan's PMU counters and branch capture logic never produce a data item that contains both (a) an identified processor-level event and (b) timing metadata for that specific event. Shan's thresholds (e.g., a number of RET instructions per time period or per number of cycles) are configuration parameters used to decide when to examine the accumulated history. They are not timing relationships carried in an alert record and they are never associated with individual events. Shan's branch history and mis-predict counts are aggregated over windows; there is no disclosure of per-event timing, ordering, or inter-event relationships being attached to any alert unit.”
The Examiner disagrees with the Applicant’s position. Shan teaches of receiving hardware PMU, and related registers and LBR stack information collects mis-predicted branch data (processor-level events) for analysis occurring in the core (CPU), column 6, lines 10-21 and column 7, lines 37-39, a PMU counts activity occurring in the core (processor-level event), column 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), column 7, lines 58-67 and column 14, lines 35-39. Shan indeed discloses “comprises information of a processor-level event ... and a timing relationship for the processor-level event”, the grounds of the rejection are hereby maintained by the Examiner. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Applicant argues:
“Third, Shan has no separate "local detector" that produces alerts. All of the cited logic (the PMU counters, LBR stack, and branch capture filter) are part of the same ROP-specific detection pipeline that ultimately leads to a single notification to AV software when a ROP pattern is recognized. There is no intermediate alert stream being generated and passed up; there is only raw PMU data to a heuristic classifier that leads to an ROP notification.
Accordingly, Shan does not disclose "receiving local alerts from a local detector" nor "local alerts" that "comprise information of a processor-level event ... and a timing relationship for the processor-level event," as required by claim 1.”
Shan teaches of hardware PMU, and related registers and LBR stack information collects mis-predicted branch data (interpreted as processor-level events) for analysis occurring in the core (CPU), column 6, lines 10-21 and column 7, lines 37-39. The Examiner has shown how Shan discloses of collecting “processor-level events” are local events received from a local detector, and finds the Applicant’s arguments to be non-persuasive. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Applicant argues:
“(2) "filtering the local alerts to determine processor-level events indicating an undesirable behavior or attack" is not properly anticipated by Shan.
The Office Action equates Shan's "branch capture filtering" and heuristic ROP classification with the claimed step of "filtering the local alerts." However, as explained above, Shan has no "local alerts" to filter; it only has accumulated PMU counts and branch traces. All of Shan's filtering operations are performed directly on the aggregate PMU data and LBR history, not on alert objects that encapsulate individual processor-level events with timing relationships. Shan's branch capture filter is used to limit the captured branches to those of interest in ROP exploits and then classify whether the pattern suggests a ROP attack. It does not "determine processor-level events indicating an undesirable behavior" in the sense of identifying specific processor-level events that themselves indicate an attack. Instead, Shan's filter operates on histories of branches and RET instructions to decide whether the overall pattern looks like a ROP chain.
In other words, Shan's filtering step is a pattern classifier over accumulated traces, not a filter applied to an alert stream to determine which processor-level events indicate malicious behavior. Thus, the limitation "filtering the local alerts to determine processor-level events indicating an undesirable behavior or attack" is not met.”
The Examiner respectfully disagrees. Shan teaches of event select registers may be configured to cause the PMU to count branch (processor-level events) anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), column 7, lines 3-10, the teachings of Shan have been shown to teach “filtering the local alerts to determine processor-level events indicating an undesirable behavior or attack”. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Applicant argues:
“With regard to "responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack, generating a system alert," Shan does describe notifying AV software or raising a ROP detection notification when its heuristic classifier determines a ROP exploit has been detected. Even if, arguendo, this notification were considered a "system alert," the claimed limitation still is not fully met because the prerequisite determination, "that there are processor-level events indicating the undesirable behavior or the attack, is absent.
In Shan, the detection decision is based on: counts of RET instructions, patterns of mis predicted branches, ROP-specific branch sequences recorded in LBR, collectively compared to ROP-specific heuristics. The classifier decides whether the accumulated pattern of execution resembles a ROP chain; it does not identify particular processor-level events as "indicating an undesirable behavior." There is no disclosure that the system decides, for example, "these specific events are malicious" and then generates a system alert in response to that event-level determination. Instead, Shan's decision is pattern-level and exploit-specific, not event-level.
Thus, even if the final AV notification were treated as a "system alert," it is not generated "responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack" as claimed, but rather in response to a higher-level pattern match over accumulated statistics.”
The Examiner finds the Applicant’s arguments to be non-persuasive. Shan discloses upon detection of anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), column 7, lines 3-10, a notification is provided (system alert) to the AV software that an ROP exploit has been detected, column 4, line 65 through column 5, line 2 and column 12, lines 54-58. Contrary to the Applicant’s arguments, Shan disclose of “responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack, generating a system alert”. The Examiner maintains the current grounds of the rejection. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Examiner disagrees with the Applicant “Shan lacks local alerts as claimed, Shan lacks any timing relationship per processor-level event contained in such alerts, Shan's filtering is over aggregated branch history, not over an alert stream, and Shan's notification is pattern-based and ROP-specific, not a response to a determination about specific processor-level events” as argued above, the Examiner finds the Applicant’s arguments to be non-persuasive, and maintains the current grounds of the rejection.
The Applicant then argues: “Shan Lacks A Shared Data Structure and Therefore Does not Anticipate claims 3-5, and 14 (and 15; 17-20, which are dependent on claim 14).
Claim 14 includes "a shared data structure for storing local alerts received over a period of time from at least one local detector that detects processor-level events from a corresponding processing unit, wherein each local alert comprises information of a processor-level event from the processing unit and a timing relationship for the processor-level event:
Claim 3 requires "receiving the local alerts into a shared data structure over a period of time" and claims 4 and 5 impose additional limitations relating to the shared data structure.
Applicant respectfully submits that Shan does not disclose any "shared data structure" as recited in claims 3, 4, 5, and 14. The Office Action excerpts misunderstand what Shan actually teaches. Shan's disclosure relates only to PMU counters, LBR hardware, and threshold-based trigger logic, none of which constitute the claimed "shared data structure" for storing local alerts, nor do they store timing relationships associated with such alerts.”
Shan discloses of a single PMU may be shared among the multiple cores, column 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, column 10, lines 30-38. The “shared structure” of Shan is equivalent to the Applicant’s claimed invention. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Applicant’s arguments below are repeated from above, the Examiner directs the Applicant to the sections addressed previously above:
“Applicant addresses these claims collectively below, as they all hinge on the same missing disclosure. Per the claims, a nature of the shared data structure is such that it: stores multiple local alert objects, over time, potentially from multiple detectors, where each alert contains both event information and a timing relationship, and the shared structure supports subsequent filtering operations. Shan does not disclose any such structure.
PMU counters do not equate to a shared data structure that stores local alerts. The Office Action repeatedly cites passages such as: PMU counts activity occurring in the core, counter is set to threshold values, RET instructions per specified time period, and mis-predicted branch data is collected. These are hardware counters, not data structures.
A PMU counter: holds a single numerical value, has no capacity to store multiple entries, is overwritten continuously, stores no discrete alerts, stores no timing relationship, and cannot serve as a container for subsequent filtering. A hardware register is not a "shared data structure" under any ordinary meaning of that term.
Shan does not produce "local alerts" that are stored anywhere. The claims require storing local alerts. Shan does not generate "alerts." It generates: misprediction counts, RET instruction counts, and LBR stack entries. These are raw PMU microarchitectural signals, not alerts created by a detector. Shan's detection occurs only when a counter crosses a threshold, at which point Shan's heuristic logic is executed. No individual microarchitectural events are converted into local alerts, and no such items are stored in any structure. Thus, Shan does not teach "receiving the local alerts into a shared data structure."
The Office Action cites: a single PMU may be shared among multiple cores. This refers only to hardware resource sharing. It does not disclose: a data structure, storing alerts, storing event/timing pairs, aggregating entries over time, or storing entries from multiple detectors. A PMU shared across cores is still just one set of counters, not a shared structure that stores multiple alert entries.
Shan's PMU counters do not store timing relationships for events. Claim 14 requires: "each local alert comprises... a timing relationship for the processor-level event." Shan never stores timing for any event. PMU counters: increment numerically, do not time-stamp events, do not preserve ordering, do not store temporal intervals, do not retain per-event timing information at all. The Office Action cites RET instructions "per specified time period," but that is a configuration parameter, not a stored timing relationship for a stored alert. This distinction is legally dispositive.”
With respect to the argument:
“Shan performs threshold-triggered analysis, not stored-alert filtering. Claim 5 requires: "... counting a number of local alerts in the shared data structure..." Shan's threshold logic counts events, not alerts, and does not count entries in a data structure. Counting and thresholding in Shan occur inside hardware, not on stored alert objects. Thus, Shan fails to meet the filtering requirement.
Shan has no structure storing multiple alert entries over time. Shan's PMU: contains one counter value, does not store historical sequences of alerts, resets on overflow, does not store accumulated alert objects. The claims require storing multiple local alerts "over a period of time." Shan stores no such accumulation. This alone defeats anticipation.”
The Examiner respectfully disagrees, as set forth above. Shan discloses of a single PMU may be shared among the multiple cores, column 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, column 10, lines 30-38. Shan additionally teaches of PMU counts activity occurring in the core (processor-level event), column 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period, column 7, lines 58-67 and column 14, lines 35-39. The Examiner has correctly applied a broadest reasonable interpretation to the claims rendering them anticipated by the prior art of record.
The Examiner disagrees with the arguments “Shan cannot anticipate claims 3, 4, 5, or 14 (or it's dependents) Because Shan does not disclose: a shared data structure, storing local alerts, each alert including a timing relationship, storing multiple alerts over time, or supporting filtering operations on stored alerts. Hardware PMU counters and LBR registers cannot be construed as the claimed "shared data structure." Accordingly, Shan does not anticipate any of these claims, and the §102 rejection should be withdrawn” as addressed above, and hereby maintains the current grounds of the rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventors, at the time the application was filed, had possession of the claimed invention.
The amended claims now recite of “detecting processor-level events from a processing unit” as recited in claim 1, and in further instances of the claims the identical language of “processor-level” events are recited. After consideration of the Applicant’s originally filed specification, it is absent of the terminology “processor-level events”.
Taken from the background of the invention section, it is recited:
[0002]Central Processing Units (CPUs) with performance monitoring capability such as a performance monitoring unit (PMU) have the capacity to produce detailed information about the operations performed by the CPU. This detailed information is typically tracked in terms of ‘events', which are the result of processor execution. From these PMU events one can infer higher level software behaviors enabling a defender or trusted party of the computing system to detect an attack to the computing system and, potentially, to detect the attack as its happening.
In a further recitations from the Detailed Description section:
[0013] A behavioral system-level detector that filters local alerts to generate system alerts with an increased confidence level over a confidence level of the local alerts is provided. For a processing unit, there can be local detectors (e.g., part of the circuitry of the processing unit or separate circuitry) used to monitor for events that may indicate an attack or even an inefficiency at the processing unit. For example, in the scenario of a processing unit of a CPU core with a PMU, local detectors, can be configured to receive PMU events (directly in an aggregate form or in some form of consumable event) and generate local alerts when undesirable behaviors are encountered. A consumable event refers to an event corresponding to or associated with behaviors of a processing unit or other circuit and is consumable because it is information that is in a format that can be consumed/used by another device, circuit, or system. The particular format of a consumable event can vary. Alternately, a local detector can receive the events directly from the processing unit, e.g., bypassing thePMU, process the events into a consumable event, and generate local alerts when undesirable behaviors are encountered. However, these types of low-level local detectors are inherently noisy, such that many of the local alerts identifying an undesirable behavior are false positives, e.g., the behavior associated with the event is a benign behavior that is mis-predicted as malicious by the local detector. These false positives negatively impact the total performance of the system.
As demonstrated from the Applicant’s specification, there is no description of “processor-level events” and what form of examples it includes. It is a broad term that could mean anything from observed internal physical operational characteristics of the processor to how instructions are processed by the processor when read from memory.
The language is additionally used in claims 2, 4-8, and 10-19.
Claims 2 and 18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventors, at the time the application was filed, had possession of the claimed invention.
It is recited in amended claims 2 and 18: “wherein each of the processor-level events arises from a microarchitectural operation of the processor”
The Applicant’s specification fails to provide any support for the terminology “microarchitectural operation of the processor”. As discussed above pertaining to the “processor-level events”, the instant specification fails to describe “microarchitectural operations of the processor”. The Applicant’s originally filed specification fails to disclose of the term “microarchitectural operations”, nor does it contain any inference to what it constitutes by recitation of examples.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 9, and 10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yamada et al, U.S. Patent 10,984,096.
As per claim 1, it is taught of a method, comprising:
receiving local alerts from a local detector that detects processor-level events from a processing unit (data processing system), wherein each local alert comprises information of a processor-level event from the processing unit and a timing relationship for the processor-level event (PMU (local detector) gathers information from recent instructions executed by the local processor core (i.e., processor level events executed by the processor core of the data processing system (i.e., processing unit), wherein a heuristic counters (i.e., timing relationship for the recently executed instructions), col. 4, lines 43-46 & 55-62 and threshold values (timing relationship, i.e., certain counts reaching a predefined threshold value) to define the conditions which will cause the PMU to generate PMIs due to execution anomalies, col. 5, lines 13-15);
filtering the local alerts to determine processor-level events indicating an undesirable behavior or attack (heuristic event handler using transaction hardware of processor core to facilitate light code analysis, which filters out anomalous events that do not deed to be processed with heavyweight code analysis, col. 7, lines 25-33); and
responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack, generating a system alert (after application of filtering of the processor level events, execution analysis software is invoked, col. 7, lines 36-39 and filtering indicates that an anomalous event should be analyzed some more where the event is flagged as suspicious (system alert) to make a further determination if the event reflects a control flow attack, col. 8, lines 37-45 & 50-56).
As per claim 2, it is disclosed of further comprising ordering the local alerts according to the timing relationship for the respective ones of the processor-level events (PMU gathers information from recent instructions executed by the local processor core (local alerts from processor level events executed by the processor core of the data processing system, wherein a heuristic counters (i.e., timing relationship for the recently executed instructions), col. 4, lines 43-46 & 55-62) wherein each of the processor-level events arises from a microarchitectural operation of the processor (PMU includes instruction event counters, such as return branch mispredict counter, a jump mispredict counter, a return-call counter bias counter, and other types of heuristic counter for instructions recently executed (collectively interpreted as various microarchitecture operations of the processor), col. 4, lines 55-59).
As per claim 9, it is taught the processing unit is a central processing unit (CPU) core (col. 4, lines 43-46).
As per claim 10, it is disclosed wherein the processor-level event is a performance monitoring unit (PMU) event (PMU gathers information from recent instructions executed by the processor core (i.e., processor level events), col. 4, lines 43-46 & 55-62).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 8-15 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Shanmugavelayutham et al, U.S. Patent 10,437,998.
As per claim 1, it is taught of a method, comprising:
receiving local alerts from a local detector that detects processor-level events from a processing unit (hardware PMU, and related registers and LBR stack information collects mis-predicted branch data (processor-level events) for analysis occurring in the core (CPU), col. 6, lines 10-21 and col. 7, lines 37-39), wherein each local alert comprises information of a processor-level event from the processing unit and a timing relationship for the processor-level event (a PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39);
filtering the local alerts to determine processor-level events indicating an undesirable behavior or attack (event select registers may be configured to cause the PMU to count branch (processor-level events) anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10); and
responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack, generating a system alert (upon detection of anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10, a notification is provided (system alert) to the AV software that an ROP exploit has been detected (col. 4, line 65 through col. 5, line 2 and col. 12, lines 54-58).
As per claim 2, it is disclosed of further comprising ordering the local alerts according to the timing relationship for the respective ones of the processor-level events (collected mis-predicted branch data is gathered and fine-tuned (ordered) based upon high ROP detection rates, col. 7, lines 37-46 and is based upon a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39) wherein each of the processor-level events arises from a microarchitectural operation of the processor (ROP detection identifies branch discrepancies, mis-predict, indirect branch mis-predicts, etc (microarchitectural operations of the processor), col. 3, lines 52-55).
As per claim 3, is taught of further comprising, receiving the local alerts into a shared data structure (a single PMU may be shared among the multiple cores, col. 6, lines 38-40) over a period of time (a PMU counts activity occurring in the core (processor-level event) that includes a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39).
As per claim 4, it is disclosed wherein the method receives local alerts from multiple local detectors into the shared data structure, each local detector detecting processor-level events from a corresponding processing unit (a multi-core processor may have its own core PMU or a single PMU may be shared among the multiple cores, col. 6, lines 38-40 and information may be additionally shared about the exploit with a System Information and Event Management system remotely deployed, col. 10, lines 30-38).
As per claim 5, it is taught wherein filtering the local alerts to determine processor-level events indicating the undesirable behavior or the attack comprises:
counting a number of local alerts in the shared data structure during the period of time (hardware PMU, and related registers and LBR stack information collects local mis-predicted branch data (processor-level events) for analysis occurring in the core (CPU), col. 6, lines 10-21 and col. 7, lines 37-39 and PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21);
determining that the number of local alerts are above a threshold in the period of time (PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39); and
responsive to the number of local alerts being above the threshold in the period of time, determining that the processor-level events indicate the undesirable behavior or the attack (upon detection of anomalies (undesirable behavior or attack) using branch capture filtering that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10).
As per claim 8, it is disclosed wherein filtering the ordered local alerts to determine processor-level events indicating the undesirable behavior or the attack comprises:
checking a category of the processor-level event in the information of the processor-level event during the period of time for each local alert in the shared data structure (different types (categories) or branches (processor-level events) are captured by filtering, col. 7, lines 13-16, wherein (PMU counts activity occurring in the core (processor-level event) are based on a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39);
determining a sequence of categories from the ordered local alerts in the shared data structure (for COP exploits, gadgets are chained together (sequence of categories of ordered local alerts), col. 7, lines 16-20, wherein a single PMU may be shared among the multiple cores, col. 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, col. 10, lines 30-38); and
responsive to determining the sequence of categories from the order local alerts, determining that the processor-level events indicate the undesirable behavior or the attack (gadgets are chained together (sequence of categories of ordered local alerts) to detect COP exploits (undesirable behavior or attack), col. 7, lines 16-20, wherein a single PMU may be shared among the multiple cores, col. 6, lines 38-40).
As per claim 9, it is taught the processing unit is a central processing unit (CPU) core (col. 5, lines 49-52).
As per claim 10, it is disclosed wherein the processor-level event is a performance monitoring unit (PMU) event (activity occurring in the core (processor level event) is counted by the PMU, col. 10, lines 10-21).
As per claim 11, it is taught of further comprising obtaining state information of the processing unit (a single PMU may be shared among the multiple cores, col. 6, lines 38-40) and coupled to receive state information of each corresponding processing unit (PMU allows for specification of exact event (state) information to be counted, col. 6, lines 24-28) corresponding to a time of the processor-level event according to the timing relationship for the processor-level event (a PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, counter values may be a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39).
As per claim 12, it is disclosed of further comprising evaluating the state information of the processing unit with respect to the information of the processor-level event from the processing unit over a period of time to determine processor-level events indicating the undesirable behavior or the attack (PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, counter values may be a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39), the evaluating includes:
comparing a behavior described by the information of the processor-level event from the processing unit with a stored training data set of known behaviors (comparisons are made using heuristic hardware (stored training data sets of known behaviors) triggers which allow for system wider monitoring and can detect anomalies on any software footprint, col. 4, lines 5-7, wherein heuristics is known as a rule or piece of information used in or enabling problem-solving or decision-making at a high-level).
As per claim 13, it is taught wherein evaluating the state information of the processing unit with respect to the information of the processor-level event from the processing unit over the period of time to determine processor-level events indicating the undesirable behavior or the attack (PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, counter values may be a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39), utilizes a high-level model implemented with a neural network or deep learning technique (comparisons are made using heuristic hardware (stored training data sets of known behaviors) triggers which allow for system wider monitoring and can detect anomalies on any software footprint, col. 4, lines 5-7, wherein an ROP heuristic detection driver provides information extracted from hardware features to perform execution profiling (interpreted as deep learning techniques), col. 10, lines 21-26).
As per claim 14, it is disclosed of a system-level detector, comprising:
a shared data structure for storing local alerts (a single PMU may be shared among the multiple cores, col. 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, col. 10, lines 30-38) received over a period of time from at least one local detector that detects processor-level events from a corresponding processing unit (hardware PMU, and related registers and LBR stack information collects mis-predicted branch data (processor-level events) for analysis occurring in the core (CPU), col. 6, lines 10-21 and col. 7, lines 37-39), wherein each local alert comprises information of a processor-level event from the processing unit and a timing relationship for the processor-level event (a PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39); and
a system processing unit coupled to the shared data structure to receive the local alerts from the shared data structure (a single PMU may be shared among the multiple cores, col. 6, lines 38-40) and coupled to receive state information of each corresponding processing unit (PMU allows for specification of exact event (state) information to be counted, col. 6, lines 24-28), the system processing unit having instructions to:
receive local alerts from the shared data structure (a PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21),
order the local alerts (collected mis-predicted branch data is gathered and fine-tuned (ordered) based upon high ROP detection rates, col. 7, lines 37-46) according to the timing relationship for the processor-level event (the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39),
filter the ordered local alerts to determine processor-level events indicating an undesirable behavior or attack (event select registers may be configured to cause the PMU to count branch (processor-level events) anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10), and
responsive to the determination that there are processor-level events indicating the undesirable behavior or the attack, generate a system alert (upon detection of anomalies (undesirable behavior or attack) using branch capture filtering, that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10, a notification is provided (system alert) to the AV software that an ROP exploit has been detected (col. 4, line 65 through col. 5, line 2 and col. 12, lines 54-58).
As per claim 15, it is taught wherein the system processing unit further has instructions to:
count a number of local alerts in the shared data structure during the period of time (hardware PMU, and related registers and LBR stack information collects local mis-predicted branch data (processor-level events) for analysis occurring in the core (CPU), col. 6, lines 10-21 and col. 7, lines 37-39 and PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21),
determine that the number of local alerts is above a threshold in the period of time (PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, the counter is set to threshold values, wherein the threshold values may be a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39), and
responsive to the number of local alerts being above the threshold in the period of time, determine that the processor-level events indicate the undesirable behavior or the attack (upon detection of anomalies (undesirable behavior or attack) using branch capture filtering that limits the captured branches to those of interest in ROP exploits (undesirable behavior or attack), col. 7, lines 3-10).
As per claim 17, it is taught wherein the system processing unit further has instructions to:
check a category of the processor-level event in the information of the processor- level event during the period of time for each local alert in the shared data structure (different types (categories) or branches (processor-level events) are captured by filtering, col. 7, lines 13-16, wherein (PMU counts activity occurring in the core (processor-level event) are based on a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39),
determine a sequence of categories from the ordered local alerts in the shared data structure (for COP exploits, gadgets are chained together (sequence of categories of ordered local alerts), col. 7, lines 16-20, wherein a single PMU may be shared among the multiple cores, col. 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, col. 10, lines 30-38), and
responsive to determining the sequence of categories from the ordered local alerts, determine that the processor-level events indicate the undesirable behavior or the attack (gadgets are chained together (sequence of categories of ordered local alerts) to detect COP exploits (undesirable behavior or attack), col. 7, lines 16-20, wherein a single PMU may be shared among the multiple cores, col. 6, lines 38-40).
As per claim 18, it is disclosed wherein the state processing unit further has instructions to obtain, for a particular processing unit, state information corresponding to a time of the processor-level event according to the timing relationship for the processor-level event (collected mis-predicted branch data is gathered and fine-tuned based upon high ROP detection rates, col. 7, lines 37-46 and is based upon a number of executions of RET instructions per specified time period or per a specified number of clock or processing cycles (i.e., timing relationship), col. 7, lines 58-67 and col. 14, lines 35-39), wherein each of the processor-level events arises from a microarchitectural operation of the processor (ROP detection identifies branch discrepancies, mis-predict, indirect branch mis-predicts, etc (microarchitectural operations of the processor), col. 3, lines 52-55).
As per claim 19, it is taught wherein the system-level detector utilizes a high-level model implemented with a neural network or deep learning technique to evaluate the state information of the processing unit with respect to the information of the processor-level event from the processing unit over the period of time to determine processor-level events indicating the undesirable behavior or the attack (comparisons are made using heuristic hardware (stored training data sets of known behaviors) triggers which allow for system wider monitoring and can detect anomalies on any software footprint, col. 4, lines 5-7, wherein an ROP heuristic detection driver provides information extracted from hardware features to perform execution profiling (interpreted as deep learning techniques), col. 10, lines 21-26 and PMU counts activity occurring in the core (processor-level event), col. 6, lines 10-21, counter values may be a number of executions of RET instructions per specified time period, col. 7, lines 58-67 and col. 14, lines 35-39).
As per claim 20, it is disclosed wherein the system-level detector is communicatively coupled to a plurality of local detectors and corresponding processing units (a single PMU may be shared among the multiple cores (processing units), col. 6, lines 38-40 and information may be additionally shared about an exploit with a System Information and Event Management system remotely deployed, col. 10, lines 30-38).
Allowable Subject Matter
Claims 6, 7, and 16 would be allowable if rewritten to overcome the rejections under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), 1st paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Chen, CN 118095028 A is relied upon for disclosing of obtaining probability values corresponding to PMU events, wherein the probability vale can be used for describing the value of the probability that the PMU event is selected as a target event.
Xia, CN 110336821 A is relied upon for disclosing of abnormal probability values based upon collected PMU data that determines if probability thresholds which is indicative of abnormal conditions within the PMU.
Chen and Xia, alone or in combination fail to disclose of how the confidence scores are computed in the instant application’s claims.
As per claim 6, it was not found to be in the prior art of checking a confidence score in the information of the processor-level event during the period of time for each local alert in the shared data structure; counting a number of local alerts that have a confidence score above a threshold during the period of time; determining that the number of local alerts is above the threshold in the period of time; and responsive to the number of local alerts being above the threshold in the period of time, determining that the processor-level events indicate the undesirable behavior or the attack.
As per claim 7, it was not found to be taught in the prior art of checking a confidence score in the information of the processor-level event during the period of time for each local alert in the shared data structure; adding the confidence scores from each local alert in the shared data structure to obtain a total value of confidence scores; determining that the total value of confidence scores is above a threshold in the period of time; and responsive to the total value of confidence scores being above the threshold in the period of time, determining that the processor-level events indicate the undesirable behavior or the attack.
As per claim 16, it was not found to be taught in the prior art of checking a confidence score in the information of the processor-level event during the period of time for each local alert in the shared data structure, counting a number of local alerts that have a confidence score above a threshold during the period of time, and determining that the number of local alerts are above the threshold in the period of time, and responsive to the number of local alerts being above the threshold in the period of time, determine that the processor-level events indicate the undesirable behavior or the attack.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The relevant art made of record and not relied upon is considered pertinent to applicant's disclosure.
Xu et al, US 2023/0368069 is relied upon for disclosing of adaptive feature health monitoring system applies a duration filter to determine whether the potential anomaly condition satisfies a duration threshold for alert generation. The duration filter analyzes the length of time a potential anomaly condition is present. In some embodiments, the duration filter computes a start time interval of the potential anomaly and an end time interval of the potential anomaly. The duration filter determines a duration threshold (e.g., a number of minutes, hours, days, etc.) that an anomaly condition can exist prior to an alert being generated. In other embodiments, the duration filter can be satisfied if a threshold number of anomaly conditions are present within a pre-determined time window (e.g., 5 potential anomalies within 3 days). In some cases, the threshold is satisfied when the number of anomaly conditions is greater than the threshold number. If the duration filter determines that the duration metric is greater than the threshold duration, the filtering operation determines that an that an anomaly condition satisfies condition for alert generation and the flow proceeds to operation. If the duration filter determines that the duration metric is less than the threshold duration, the filtering operation terminates, no alert is generated, and the flow returns to operation. In some embodiments, the duration thresholds may be set by a user input or as a defined portion of the set of historical feature values, see paragraph 0065.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER REVAK whose telephone number is (571)272-3794. The examiner can normally be reached 5:30am - 3:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at 571-270-1138. 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.
/CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407