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 .
This action is responsive to the Applicant’s amendments filed on 03/19/2026. Claims 1-21 are pending in the application. Claims 1, 8, and 15 have been amended. Claim 21 has been newly added. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/13/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 15-20 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.
Regarding claim 15, the claim recites, “enforcing, by the central processing unit and in the hardware, validity of” in line 20 of the claim. Due to the incomplete limitation, it is unclear what validity is being enforced: instruction pointer transfers of an application, hashes corresponding to transfers of an application, the control flow graph, or some other entity. For purposes of examination, the Examiner assumes “validity of the transfers” was intended.
Any claim not explicitly mentioned above is rejected due to dependency on a rejected claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 6-7, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Tshouva et al. (US 20200159553 A1) hereafter Tshouva in view of Zou et al. (US 20200236143 A1) hereafter Zou, further in view of Chan et al. (US 20120023304 A1) hereafter Chan, further in view of Sultana et al. (US 20180253547 A1) hereafter Sultana, further in view of Pike et al. (US 20160300060 A1) hereafter Pike, further in view of Van De Groenendaal et al. (US 20200349045 A1) hereafter Van, further in view of Vidyadhara et al. (US 11726880 B1) hereafter Vidyadhara.
Regarding claim 1, Tshouva teaches:
determining an observation phase for execution of processes on the computing system, during which valid execution paths associated with an application are observed (Paragraph 57; “Each of the intermediate code file(s) may be analyzed to identify the plurality of routines. Each intermediate code file may be further analyzed to identify one or more valid executions paths” requires the observation of execution behavior of processes or routines in the system. The analysis of intermediate code files represents an observation phase in which execution information is gathered.);
determining telemetry, during the observation phase, representing execution of the valid execution paths of the processes (Paragraph 57; “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine” where the order of execution of routines corresponds to telemetry representing execution of the processes, is determined and therefore corresponds to the claimed limitation.);
generating a control flow directed graph representing execution sequences of the valid execution paths of the application based on the telemetry (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s).” A CFG is always a directed graph, therefore a CFG is always a CFDG. “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine.”, where the execution information corresponds to telemetry representing execution of valid execution paths.);
determining entries representing hash values for sequences of transitions within the control flow directed graph (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” where maintaining multiple rolling hash values representing different execution sequences corresponds to determining a plurality of hash values for the sequences of transitions.);
determining a monitoring phase based at least in part on the control flow directed graph (Paragraph 99; “After the critical routine(s) are defined, the constructor 210 may analyze the CFG created for the intermediate code file(s) to identify all possible execution paths leading to execution of each of the critical routine(s) and mark them as valid. For example, the constructor 210 may create a valid execution dataset, for example, a list, a table, a record and/or the like mapping the identified valid execution path(s) leading to execution of the critical routine(s)” discloses using the CFG to determine and mark execution paths to critical routines which establishes which portions of program execution should be observed/validated. Selection and marking of valid execution paths derived from the CFG defines a phase of monitoring in the form of identifying sequences or conditions to monitor at runtime, where the monitoring is performed by the flow validation code segment as disclosed in Paragraph 32, “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s).”);
monitoring transfers of instruction pointers at the computing system (Paragraph 32; “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s)” monitors runtime execution by maintaining an ordered pattern representing the runtime execution sequence and comparing it to valid execution paths. Each routine transition in the ordered pattern represents a transfer in the instruction pointer as execution proceeds between code locations.);
determining a rolling hash associated with the transfers (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” teaches calculating a rolling hash value that represents the runtime execution sequence which is updated based on the most recently executed changes. Each change in the runtime sequence corresponds to a transfer, thus the rolling hash is determined and associated with each transfer.);
determining a validity of the transfers based at least in part on the rolling hash (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path” teaches that, during runtime, a rolling hash of the observed execution sequence is computed and compared to the stored valid hash values to verify correspondence.);
in response to determining that the transfers are not represented in the control flow directed graph and are invalid transfers, performing a remedial action (Paragraph 65; “in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like.”, the list of predefined actions corresponding to the remedial action. Paragraph 99 further discloses “After the critical routine(s) are defined, the constructor 210 may analyze the CFG created for the intermediate code file(s) to identify all possible execution paths leading to execution of each of the critical routine(s) and mark them as valid. For example, the constructor 210 may create a valid execution dataset, for example, a list, a table, a record and/or the like mapping the identified valid execution path(s) leading to execution of the critical routine(s)”, where if the transfer is invalid, then it is not in the valid execution dataset, and if it is not in the valid execution dataset, then it cannot be represented in the CFG because the valid execution dataset is created based on the CFG.);
in response to the transfers being invalid, performing a remedial action comprising at least one of stopping a process, suspending execution via a VM infrastructure management API, or issuing a termination command via a container management API (Paragraph 65; “However, in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like.”, where preventing a process from executing a critical routine corresponds to stopping a process.).
While Tshouva implies that observation occurs during execution, Tshouva does not explicitly teach that the observation occurs during execution; a hash table; or explicitly terminating a process.
However, Zou teaches:
observing execution at runtime (Paragraph 172; “When testing algorithm 1325, the secured gateway software appliance (installed at data consumer system 1360) may monitor the behavior of data consumer system 1360 by monitoring various activities that occur at data consumer system 1360”);
terminating a process (Paragraph 199; “in response to determining that the set of processing routines exhibited abnormal behavior, the verification environment may terminate the set of processing routines”.).
Tshouva and Zou are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva to incorporate the teachings of Zou and have performed the observation and monitoring at runtime. A person of ordinary skill in the art would have recognized that this would have yielded predictable benefits in validation real execution paths and detecting deviations during actual execution. Further, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have terminated a process as taught by Zou instead of stopping a process as taught by Tshouva. A person of ordinary skill in the art would have recognized process termination as a known method in the art yielding the predictable result of graceful exiting of processes yielding the benefit of freeing relevant resources.
Tshouva in view of Zou does not teach comparing against a hash table.
However, Chan teaches:
comparing against the hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva, Zou, and Chan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou to incorporate the teachings of Chan and incorporate a hash table. A person of ordinary skill in the art would have understood that hash tables are a well-known data structure employed to enable efficient lookup, comparison, and storage of indexed values, and would have been motivated to use a hash table to quickly access and verify execution path data, by comparing the rolling hashes of Tshouva within the hash table of Chan. The use of known hash table matching techniques of Chan to the rolling hashes of Tshouva would have yielded the predictable result of efficiently identifying matching execution path representations while reducing comparison overhead associated with comparison of full execution sequences.
Tshouva in view of Zou, further in view of Chan does not teach that the valid execution paths are valid transfers.
However, Sultana teaches:
valid transfers (Paragraph 12; “Generally, CFI validation is configured to compare a runtime control flow transfer and/or a runtime execution path at indirect or conditional branches, determined at runtime, to a valid control flow transfer and/or valid execution path, determined prior to runtime.”);
Tshouva, Zou, Chan, and Sultana are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan to incorporate the teachings of Sultana and have the control flow graph show valid control flow transfers. A person of ordinary skill in the art would have recognized control flow graphs are used to model permissible execution flow within an application, and the implementation of such would yield the predictable result of a graph that explicitly represents the control transfers between execution states to facilitate analysis of execution behavior for proper execution.
While Tshouva contemplates transfers in the path being invalid (Paragraph 65; “However, in case the validation code segment determines that the runtime execution path is invalid”), Tshouva in view of Zou, further in view of Chan, further in view of Sultana does not teach that a portion of transfers are invalid.
However, Pike teaches:
a portion of the transfers are invalid (Paragraph 114; “if such functions appear on the call stack, control flow integrity can be considered to have failed (e.g., comparing the contents of the stack with the canonical control flow graph ignores the invalid portion of the canonical control flow graph as an ordinary execution path). Matches against the invalid portion of the control flow graph are disallowed.”).
Tshouva, Zou, Chan, Sultana, and Pike are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana to incorporate the teachings of Pike and consider situations when a portion of the control flow transfers are invalid. Given Tshouva contemplates control flow transfers being invalid as a whole, it would be obvious to a person of ordinary skill in the art to apply the teachings of Pike of validity analysis of only a portion of the control flow transfers, whose implementation would yield the predictable result of identifying invalid execution paths with greater granularity.
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike does not teach routing central processing unit (CPU) telemetry from a (CPU) of the computing system to a hardware pipeline, the hardware pipeline comprising at least one of a field-programmable gate array, a graphics processing unit, or an application-specific integrated circuit, wherein the routing is performed without interrupting operation of the application executing on the central processing unit; performing, on the hardware pipeline, analysis of the CPU telemetry; transmitting, from the hardware pipeline to the CPU, an indication that the transfers are invalid.
However, Van teaches:
routing central processing unit (CPU) telemetry from a (CPU) of the computing system to a hardware pipeline, the hardware pipeline comprising at least one of a field-programmable gate array, a graphics processing unit, or an application-specific integrated circuit, wherein the routing is performed without interrupting operation of the application executing on the central processing unit (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”, where Paragraph 88 discusses the use of ASIC, “In some embodiments, some or all of the control logic for implementing the described operations may be implemented in hardware logic (e.g., as microcode in an integrated circuit chip, as a programmable gate array (PGA), as an application-specific integrated circuit (ASIC), etc.)”. Telemetry routing occurring OOB (out of band) by definition means it will not interrupt operation of in-band applications on the processor, corresponding to occurring without interrupting operation of the application executing on the central processing unit.).
Tshouva, Zou, Chan, Sultana, Pike, and Van are considered to be analogous to the claimed invention because they are in the same field of execution paradigms. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Pike to incorporate the teachings of Van and route CPU telemetry from a CPU to a hardware pipeline without interrupting operation of an application executing on a CPU. A person of ordinary skill in the art would have been motivated by the need to collect and process execution information while allowing the application to continue normal execution, thereby reducing the performance impact associated with telemetry collection, representing the known method of offloading telemetry tasks to an alternate processing device, and yielding the predictable result of obtaining execution data without disrupting processing.
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van does not teach performing, on the hardware pipeline, analysis of the telemetry; transmitting, from the hardware pipeline, an indication that the transfers are invalid.
However, Vidyadhara teaches:
performing, on the hardware pipeline, analysis of the telemetry (Col. 10, lines 19-21; “Telemetry server 398 may be configured to analyze telemetry data and other information from information handling system 200 and/or other information handling systems”, the server corresponding to the hardware pipeline as evidenced by Col. 13, line 65 – Col. 14, line 4 describing embodiments “and the like” as being configurable as a FPGA or ASIC.);
transmitting, from the hardware pipeline, the result (Col. 10, lines 22-25; “Telemetry server 398 may be configured to transmit resolution instructions to the information handling system configured to implement the resolution associated with the exception or interrupt.”, the resolution instructions corresponding to the result from the telemetry analysis transmitted from the hardware pipeline.).
Tshouva, Zou, Chan, Sultana, Pike, Van, and Vidyadhara are considered to be analogous to the claimed invention because they are in the same field of execution paradigms. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van to incorporate the teachings of Vidyadhara and have analyzed the CPU telemetry of Van on the system of Vidyadhara, to transmit the result from the system of Vidyadhara back to the CPU of Van, and to have the result be an indication that a portion of the transfers are invalid of Pike. A person of ordinary skill in the art would have recognized that offloading analysis to a separate processing unit followed by feedback of analysis results is a known technique for enabling runtime evaluation of processor activity, yielding the predictable result of providing the CPU with execution information indicating whether transfers are valid or invalid. Further, it would have been obvious to employ the invalid transfer determination of Pike as the analysis result generated from Vidyadhara because identification of control flow transfers is a known form of execution behavior analysis, yielding the predictable result of facilitating detection and evaluation of execution anomalies based on telemetry.
Regarding claim 2, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teach the method of claim 1. Tshouva further teaches:
wherein determining the validity of the transfers comprises:
determining a sequence of multiple transfers (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence”, where each addition to the runtime execution sequence corresponds to a transfer event, therefore determining the runtime execution sequence includes determining a sequence of multiple transfers.);
determining a hash value of the rolling hash associated with the sequence of transfers (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” explicitly discloses a calculation, corresponding to a determination, of a hash value of the rolling hash associated with the sequence of transfers.);
and determining that the sequence of multiple transfers is valid based on the hash value (Paragraph 61; “the flow validation code segment may be configured to apply one or more pattern matching methods, technique and/or algorithms for matching the runtime execution sequence to the ordered patterns of the valid execution path(s). In particular, in case of expressing the valid execution path(s) and the runtime execution sequence using the rolling hash values, the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s)” teaches the validity check based on the hash value corresponding to the expected hash.).
Chan teaches:
a hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Regarding claim 3, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teaches the method of claim 1. Tshouva further teaches:
wherein generating the control flow directed graph is based on observed transfers during the observation phase, wherein the observed transfers during the observation phase are considered valid transfers (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path” teaches identifying valid execution paths composed of transfers between routines. Each execution path corresponds to a sequence of control transfers observed. The created CFG is therefore based on the transfers which are identified as valid execution paths.).
Regarding claim 6, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teach the method of claim 1. Tshouva teaches:
wherein generating the control flow directed graph comprises normalizing the telemetry into a control flow directed graph representation (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path”, where the respective ordered pattern corresponds to a form of normalized telemetry which concatenates unique identifiers of valid execution paths.).
Van teaches:
wherein the telemetry comprises central processing unit (CPU) telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Regarding claim 7, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teaches the method of claim 6. Tshouva teaches:
wherein the monitoring phase is performed using a hardware device of the computing system (Paragraph 47; “For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit”);
wherein determining the validity is based at least in part on identifying an instruction sequence in the telemetry that is not present in the control flow directed graph (Paragraphs 57-60; “On the other hand, in case the runtime execution sequence does not match any of the valid execution path(s) associated with the respective critical routine, the validation code segment may determine that the runtime execution path is invalid and that the processor(s)′ control flow may be compromised”, where the runtime execution sequence not matching any valid execution path corresponds to identifying an instruction sequence in telemetry that is not present in the CFG. The CFG is further disclosed to identify valid execution paths in Paragraph 57, “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s)”).
Van teaches:
CPU telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Regarding claim 21, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teach the method of claim 1. Tshouva teaches:
wherein performing the remedial action includes at least one of stopping a process, suspending execution via a VM infrastructure management API, or issuing a termination command via a container management API (Paragraph 65; “However, in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like.”, where preventing a process from executing a critical routine corresponds to stopping a process.).
While Tshouva teaches a remedial action stopping a process from executing, Tshouva does not explicitly teach terminating a process.
Zou teaches:
terminating a process (Paragraph 199; “in response to determining that the set of processing routines exhibited abnormal behavior, the verification environment may terminate the set of processing routines”.).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara, further in view of Nakaike (US 20150149988 A1), further in view of Mallon et al. (US 20210326413 A1) hereafter Mallon.
Regarding claim 4, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teach the method of claim 1. Tshouva further teaches:
determining one or more sequences of transitions (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence” corresponds to determining one or more sequences of transitions.).
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara does not teach being based at least in part on the one or more sequences being traversed over a threshold number of times during the observation phase.
However, Nakaike teaches:
based at least in part on the one or more sequences being traversed over a number of times during the observation phase (Paragraph 160; “In step 306, the computer (101) obtains execution frequency information by using the control flow graph modified in step 305. In the case where step 305 is not carried out, the computer (101) obtains execution frequency information by using the control flow graph prepared in step 303.”).
Tshouva, Zou, Chan, Sultana, Pike, Van, Vidyadhara, and Nakaike are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara to incorporate the teachings of Nakaike and have the sequences of transitions determined at least in part on one or more of the sequences being traversed over a number of times during the observation phase. A person of ordinary skill in the art would have recognized frequency of execution as a known and predictable indicator of importance, relevance, or abnormality in runtime behavior. Motivation to use traversal frequency to determine sequences of transitions would come from the goal of prioritizing frequently executed paths for validation, yielding expected improvements in performance analysis and system efficiency.
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara, further in view of Nakaike does not teach a threshold.
However, Mallon teaches:
a threshold (Paragraph 15; “For example, in an embodiment the first variable may be selected from a set of variable that have small liveness regions, e.g., that at most a threshold number of blocks. The threshold may be, say, 2, 4, or the like.”).
Tshouva, Zou, Chan, Sultana, Pike, Van, Vidyadhara, Nakaike, and Mallon are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara further in view of Nakaike to incorporate the teachings of Mallon and incorporate a threshold as thresholds are a well-known technique for filtering, triggering, or decision-making, with the expected and predictable improvement of distinguishing significant events or values from normal variation.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara, further in view of Ghose (US 9767284 B2), further in view of Venkatesan et al. (US 20040225996 A1) hereafter Venkatesan.
Regarding claim 5, Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara teaches the method of claim 1. Tshouva teaches:
determining a subset of the set of hash values (Paragraphs 58-59; “The runtime execution sequence may be therefore implemented as a sliding window comprising the unique identifiers of a predefined number of routines most recently executed and hence most recently registered”, where the sliding window comprising the unique identifiers of a predefined number of routines whose runtime execution sequence is “expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)” corresponds to a subset of the set of hash values);
determining the validity based on a subset of the rolling hash associated with the transfers corresponding to a hash value of the subset of the set of hash values (Paragraphs 59-61; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)”. Further, “the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s).”).
Chan teaches:
determining a set of hash values from the hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara does not teach the determination being based on a start position within the control flow directed graph; or based on a number of transitions included within the transfers.
However, Ghose teaches:
based on a start position within the control flow directed graph (Col. 15, lines 56-60; “Each legal flow path within a single execution module may be specified as a segment from an entry point or instruction that can change the flow of control to a next instruction that can change the flow of control, and wherein each segment has a predetermined reference signature.”).
Tshouva, Zou, Chan, Sultana, Pike, Van, Vidyadhara, and Ghose are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara to incorporate the teachings of Ghose and have the set of hash values be determined based on the start position within the CFDG. A person of ordinary skill in the art would have recognized that anchoring computation to a known starting node, such as the entry point of instruction in a graph, would be a predictable method of maintaining consistency and context when representing execution paths, thereby improving accuracy in path validation and comparison.
Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara further in view of Ghose does not teach based on a number of transitions included within the transfers.
However, Venkatesan teaches:
based on a number of transitions included within the transfers (Paragraph 114; “Here is heuristic based upon the above illustration of "random walk": Let R be the undirected graph whose vertices are the nodes of the CFG and which has an edge on a vertex pair if and only if the corresponding vertex pair in the CFG has a (directed) control flow edge, in either direction. Clearly, R is a graph with maximum degree three. It starts at the original node w, and at any node x, takes one of the dx edges with uniform probability. (dx is the degree of x). It aborts when it encounters a procedure boundary (call or branch to another procedure) or when the path length crosses a pre-determined limit”, where the path length corresponds to the applicant’s number of transitions).
Tshouva, Zou, Chan, Sultana, Pike, Van, Vidyadhara, Ghose, and Venkatesan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Sultana, further in view of Pike, further in view of Van, further in view of Vidyadhara further in view of Ghose to incorporate the teachings of Venkatesan and have determined a subset of the set of hash values based on the number of transitions within the transfers. A person of ordinary skill in the art would have recognized that filtering data according to path length or transition count is a known and predictable technique for managing computational complexity and focusing analysis on relevant code segments, yielding the predictable improvement of balancing accuracy and efficiency.
Claims 8-9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen et al. (US 20120266243 A1) hereafter Turkulainen.
Regarding claim 8, Tshouva teaches:
one or more processors (Paragraph 53; “The executable file(s) may be executed by one or more processors of one or more devices, systems and/or platforms collectively designated device herein after.”);
and one or more non-transitory computer-readable media storing computer-executable instructions (Paragraph 86; “The storage 206 used for storing data and/or program code may include one or more non-transitory memory devices”);
determining an observation phase for execution of processes on the computing system (Paragraph 57; “Each of the intermediate code file(s) may be analyzed to identify the plurality of routines. Each intermediate code file may be further analyzed to identify one or more valid executions paths” requires the observation of execution behavior of processes or routines in the system. The analysis of intermediate code files represents an observation phase in which execution information is gathered.);
determining telemetry, during the observation phase, representing execution of the processes (Paragraph 57; “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine” where the order of execution of routines corresponds to telemetry representing execution of the processes, is determined and therefore corresponds to the claimed limitation.);
generating a control flow directed graph representing execution sequences of an application based on the telemetry (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s).” A CFG is always a directed graph, therefore a CFG is always a CFDG. “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine.”, where the execution information corresponds to telemetry representing execution of valid execution paths.);
determining entries representing hash values for sequences of transitions within the control flow directed graph (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” where maintaining multiple rolling hash values representing different execution sequences corresponds to determining a plurality of hash values for the sequences of transitions.);
determining a monitoring phase based at least in part on the control flow directed graph (Paragraph 99; “After the critical routine(s) are defined, the constructor 210 may analyze the CFG created for the intermediate code file(s) to identify all possible execution paths leading to execution of each of the critical routine(s) and mark them as valid. For example, the constructor 210 may create a valid execution dataset, for example, a list, a table, a record and/or the like mapping the identified valid execution path(s) leading to execution of the critical routine(s)” discloses using the CFG to determine and mark execution paths to critical routines which establishes which portions of program execution should be observed/validated. Selection and marking of valid execution paths derived from the CFG defines a phase of monitoring in the form of identifying sequences or conditions to monitor at runtime, where the monitoring is performed by the flow validation code segment as disclosed in Paragraph 32, “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s).”);
monitoring transfers of instruction pointers at the computing system (Paragraph 32; “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s)” monitors runtime execution by maintaining an ordered pattern representing the runtime execution sequence and comparing it to valid execution paths. Each routine transition in the ordered pattern represents a transfer in the instruction pointer as execution proceeds between code locations.);
determining a rolling hash associated with a sequence of the transfers by incrementally computing a hash value over successive instruction pointer transitions in the sequence (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” teaches calculating a rolling hash value that represents the runtime execution sequence which is updated based on the most recently executed changes. Each change in the runtime sequence corresponds to a transfer, thus the rolling hash is determined and associated with each transfer. While the example in Paragraph 59 discloses a path having only one hash, Paragraph 132 contemplates an alternative with each transition having its own hash table lookup, the number of look ups being equal to the number of transitions; “In some instances, the example described herein may use a single hash table lookup for each L transition. In some instances, the number of look ups may be equal to the number [of] transitions”, corresponding to a rolling hash associated with a sequence of transfers, the full path corresponding to the sequence of transfers, by computing a hash value over successive instruction pointer transitions in the sequence. The incremental aspect is satisfied by the usage of a rolling hash. Because a rolling hash processes data in a sliding window, the rolling hash is updated when data enters or leaves the window, meaning the hash is incrementally computed over each successive transition.);
determining a validity of the transfers based at least in part on the rolling hash (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path” teaches that, during runtime, a rolling hash of the observed execution sequence is computed and compared to the stored valid hash values to verify correspondence.);
in response to determining that the transfers are not represented in the control flow directed graph and are invalid transfers, performing a remedial action (Paragraph 65; “in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like.”, the list of predefined actions corresponding to the remedial action. Paragraph 99 further discloses “After the critical routine(s) are defined, the constructor 210 may analyze the CFG created for the intermediate code file(s) to identify all possible execution paths leading to execution of each of the critical routine(s) and mark them as valid. For example, the constructor 210 may create a valid execution dataset, for example, a list, a table, a record and/or the like mapping the identified valid execution path(s) leading to execution of the critical routine(s)”, where if the transfer is invalid, then it is not in the valid execution dataset, and if it is not in the valid execution dataset, then it cannot be represented in the CFG because the valid execution dataset is created based on the CFG.);
While Tshouva implies that observation occurs during execution, Tshouva does not explicitly teach that the observation occurs during execution; or a hash table.
However, Zou teaches:
observing execution at runtime (Paragraph 172; “When testing algorithm 1325, the secured gateway software appliance (installed at data consumer system 1360) may monitor the behavior of data consumer system 1360 by monitoring various activities that occur at data consumer system 1360”);
Tshouva and Zou are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva to incorporate the teachings of Zou and have performed the observation and monitoring at runtime. A person of ordinary skill in the art would have recognized that this would have yielded predictable benefits in validation real execution paths and detecting deviations during actual execution. Further, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have terminated a process as taught by Zou instead of stopping a process as taught by Tshouva.
Tshouva in view of Zou does not teach matching against a hash table.
However, Chan teaches:
matching against a hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva, Zou, and Chan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou to incorporate the teachings of Chan and incorporate a hash table. A person of ordinary skill in the art would have understood that hash tables are a well-known data structure employed to enable efficient lookup, comparison, and storage of indexed values, and would have been motivated to use a hash table to quickly access and verify execution path data, by comparing the rolling hashes of Tshouva within the hash table of Chan. The use of known hash table matching techniques of Chan to the rolling hashes of Tshouva would have yielded the predictable result of efficiently identifying matching execution path representations while reducing comparison overhead associated with comparison of full execution sequences.
Tshouva in view of Zou, further in view of Chan does not teach blocking a function call via a function hooking mechanism or intercepting a system call via an eBPF hook.
However, Turkulainen teaches:
blocking a function call via a function hooking mechanism or intercepting a system call via an eBPF hook (Paragraph 25; “processor may be further configured to interrupt the execution of the program at a point of interest by any one of using a hook to intercept a call to a function, and stopping the execution when the program reaches a breakpoint”, the response causing a function call to be stopped at a breakpoint corresponding to blocking a function call via a function hooking mechanism.).
Tshouva, Zou, Chan, and Turkulainen are considered to be analogous to the claimed invention because they are in the same field of arrangements for execution. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan to incorporate the teachings of Turkulainen and have blocked a function call via a function hooking mechanism. A person of ordinary skill in the art would have recognized function hooking as a known method for monitoring, modifying, filtering, or preventing execution of function calls, the step of hooking contemplated by Tshouva (Paragraph 109; “constructor 210 may adjust the intermediate code file(s) to add the flow validation code segment using one or more code insertion (hooking) methods”). Doing so would have yielded the predictable result of selectively preventing invocation of undesired functions while maintaining control over program execution.
Regarding claim 9, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen teach the system of claim 8. Tshouva further teaches:
wherein determining the validity of the transfers comprises:
determining a sequence of multiple transfers (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence”, where each addition to the runtime execution sequence corresponds to a transfer event, therefore determining the runtime execution sequence includes determining a sequence of multiple transfers.);
determining a hash value of the rolling hash associated with the sequence of transfers (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” explicitly discloses a calculation, corresponding to a determination, of a hash value of the rolling hash associated with the sequence of transfers.);
and determining that the sequence of multiple transfers is valid based on the hash value (Paragraph 61; “the flow validation code segment may be configured to apply one or more pattern matching methods, technique and/or algorithms for matching the runtime execution sequence to the ordered patterns of the valid execution path(s). In particular, in case of expressing the valid execution path(s) and the runtime execution sequence using the rolling hash values, the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s)” teaches the validity check based on the hash value corresponding to the expected hash.).
Chan teaches:
a hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Regarding claim 11, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen teach the system of claim 8. Tshouva further teaches:
wherein generating the control flow directed graph is based on observed transfers during the observation phase, wherein the observed transfers during the observation phase are considered valid transfers (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path” teaches identifying valid execution paths composed of transfers between routines. Each execution path corresponds to a sequence of control transfers observed. The created CFG is therefore based on the transfers which are identified as valid execution paths.).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen, further in view of Nakaike, further in view of Mallon.
Regarding claim 10, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen teach the system of claim 8. Tshouva further teaches:
determining one or more sequences of transitions (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence” corresponds to determining one or more sequences of transitions.).
Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen does not teach being based at least in part on the one or more sequences being traversed over a threshold number of times during the observation phase.
However, Nakaike teaches:
based at least in part on the one or more sequences being traversed over a number of times during the observation phase (Paragraph 160; “In step 306, the computer (101) obtains execution frequency information by using the control flow graph modified in step 305. In the case where step 305 is not carried out, the computer (101) obtains execution frequency information by using the control flow graph prepared in step 303.”).
Tshouva, Zou, Chan, Turkulainen, and Nakaike are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen to incorporate the teachings of Nakaike and have the sequences of transitions determined at least in part on one or more of the sequences being traversed over a number of times during the observation phase. A person of ordinary skill in the art would have recognized frequency of execution as a known and predictable indicator of importance, relevance, or abnormality in runtime behavior. Motivation to use traversal frequency to determine sequences of transitions would come from the goal of prioritizing frequently executed paths for validation, yielding expected improvements in performance analysis and system efficiency.
Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen, further in view of Nakaike does not teach a threshold.
However, Mallon teaches:
a threshold (Paragraph 15; “For example, in an embodiment the first variable may be selected from a set of variable that have small liveness regions, e.g., that at most a threshold number of blocks. The threshold may be, say, 2, 4, or the like.”).
Tshouva, Zou, Chan, Turkulainen, Nakaike, and Mallon are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen, further in view of Nakaike to incorporate the teachings of Mallon and incorporate a threshold as thresholds are a well-known technique for filtering, triggering, or decision-making, with the expected and predictable improvement of distinguishing significant events or values from normal variation.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view Turkulainen, further in view of Ghose, further in view of Venkatesan.
Regarding claim 12, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen teaches the system of claim 8. Tshouva teaches:
determining a subset of the set of hash values (Paragraphs 58-59; “The runtime execution sequence may be therefore implemented as a sliding window comprising the unique identifiers of a predefined number of routines most recently executed and hence most recently registered”, where the sliding window comprising the unique identifiers of a predefined number of routines whose runtime execution sequence is “expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)” corresponds to a subset of the set of hash values);
determining the validity based on a subset of the rolling hash associated with the transfers corresponding to a hash value of the subset of the set of hash values (Paragraphs 59-61; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)”. Further, “the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s).”).
Chan teaches:
determining a set of hash values from the hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva in view of Zou, further in view of Chan, further in view Turkulainen does not teach the determination being based on a start position within the control flow directed graph; or based on a number of transitions included within the transfers.
However, Ghose teaches:
based on a start position within the control flow directed graph (Col. 15, lines 56-60; “Each legal flow path within a single execution module may be specified as a segment from an entry point or instruction that can change the flow of control to a next instruction that can change the flow of control, and wherein each segment has a predetermined reference signature.”).
Tshouva, Zou, Chan, Turkulainen, and Ghose are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view Turkulainen to incorporate the teachings of Ghose and have the set of hash values be determined based on the start position within the CFDG. A person of ordinary skill in the art would have recognized that anchoring computation to a known starting node, such as the entry point of instruction in a graph, would be a predictable method of maintaining consistency and context when representing execution paths, thereby improving accuracy in path validation and comparison.
Tshouva in view of Zou, further in view of Chan, further in view Turkulainen, further in view of Ghose does not teach based on a number of transitions included within the transfers.
However, Venkatesan teaches:
based on a number of transitions included within the transfers (Paragraph 114; “Here is heuristic based upon the above illustration of "random walk": Let R be the undirected graph whose vertices are the nodes of the CFG and which has an edge on a vertex pair if and only if the corresponding vertex pair in the CFG has a (directed) control flow edge, in either direction. Clearly, R is a graph with maximum degree three. It starts at the original node w, and at any node x, takes one of the dx edges with uniform probability. (dx is the degree of x). It aborts when it encounters a procedure boundary (call or branch to another procedure) or when the path length crosses a pre-determined limit”, where the path length corresponds to the applicant’s number of transitions).
Tshouva, Zou, Chan, Turkulainen, Ghose, and Venkatesan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view Turkulainen, further in view of Ghose to incorporate the teachings of Venkatesan and have determined a subset of the set of hash values based on the number of transitions within the transfers. A person of ordinary skill in the art would have recognized that filtering data according to path length or transition count is a known and predictable technique for managing computational complexity and focusing analysis on relevant code segments, yielding the predictable improvement of balancing accuracy and efficiency.
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen, further in view of Van.
Regarding claim 13, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen teach the system of claim 8. Tshouva teaches:
wherein generating the control flow directed graph comprises normalizing the telemetry into a control flow directed graph representation (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path”, where the respective ordered pattern corresponds to a form of normalized telemetry which concatenates unique identifiers of valid execution paths.).
Tshouva in view of Zou further in view of Chan further in view of Turkulainen does not teach wherein the telemetry comprises central processing unit (CPU) telemetry.
However, Van teaches:
wherein the telemetry comprises central processing unit (CPU) telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Tshouva, Zou, Chan, Turkulainen, and Van are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen to incorporate the teachings of Van and have the telemetry comprise CPU telemetry. A person of ordinary skill in the art would have recognized CPU-related metrics as a known type of telemetry collected during program execution and their inclusion would yield the predictable result of providing processor execution context for better analysis of control flow transfers.
Regarding claim 14, Tshouva in view of Zou, further in view of Chan, further in view of Turkulainen, further in view of Van teaches the system of claim 13. Tshouva teaches:
wherein the monitoring phase is performed using a hardware device of the computing system (Paragraph 47; “For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit”);
wherein determining the validity is based at least in part on identifying an instruction sequence in the telemetry that is not present in the control flow directed graph (Paragraphs 57-60; “On the other hand, in case the runtime execution sequence does not match any of the valid execution path(s) associated with the respective critical routine, the validation code segment may determine that the runtime execution path is invalid and that the processor(s)′ control flow may be compromised”, where the runtime execution sequence not matching any valid execution path corresponds to identifying an instruction sequence in telemetry that is not present in the CFG. The CFG is further disclosed to identify valid execution paths in Paragraph 57, “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s)”).
Van teaches:
CPU telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Chan, further in view of Black et al. (US 20130283245 A1) hereafter Black, further in view of Togawa (US 20090222791 A1), further in view of Aditham et al. (US 20190089720 A1) hereafter Aditham.
Regarding claim 15, Tshouva teaches:
one or more non-transitory computer-readable media storing computer-readable instructions (Paragraph 86; “The storage 206 used for storing data and/or program code may include one or more non-transitory memory devices”);
determining an observation phase for execution of processes on the computing system, during which valid execution paths associated with an application are observed (Paragraph 57; “Each of the intermediate code file(s) may be analyzed to identify the plurality of routines. Each intermediate code file may be further analyzed to identify one or more valid executions paths” requires the observation of execution behavior of processes or routines in the system. The analysis of intermediate code files represents an observation phase in which execution information is gathered.);
determining telemetry, during the observation phase, representing execution of the processes (Paragraph 57; “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine” where the order of execution of routines corresponds to telemetry representing execution of the processes, is determined and therefore corresponds to the claimed limitation.);
generating a control flow directed graph representing execution sequences of an application based on the telemetry (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s).” A CFG is always a directed graph, therefore a CFG is always a CFDG. “Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine.”, where the execution information corresponds to telemetry representing execution of valid execution paths.);
determining entries representing hash values for sequences of transitions within the control flow directed graph (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” where maintaining multiple rolling hash values representing different execution sequences corresponds to determining a plurality of hash values for the sequences of transitions.);
determining a monitoring phase based at least in part on the control flow directed graph (Paragraph 99; “After the critical routine(s) are defined, the constructor 210 may analyze the CFG created for the intermediate code file(s) to identify all possible execution paths leading to execution of each of the critical routine(s) and mark them as valid. For example, the constructor 210 may create a valid execution dataset, for example, a list, a table, a record and/or the like mapping the identified valid execution path(s) leading to execution of the critical routine(s)” discloses using the CFG to determine and mark execution paths to critical routines which establishes which portions of program execution should be observed/validated. Selection and marking of valid execution paths derived from the CFG defines a phase of monitoring in the form of identifying sequences or conditions to monitor at runtime, where the monitoring is performed by the flow validation code segment as disclosed in Paragraph 32, “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s).”);
monitoring transfers of instruction pointers at the computing system (Paragraph 32; “The flow validation code segment is configured to verify a match between the ordered pattern of the runtime execution sequence and the ordered pattern of at least one of valid execution path(s)” monitors runtime execution by maintaining an ordered pattern representing the runtime execution sequence and comparing it to valid execution paths. Each routine transition in the ordered pattern represents a transfer in the instruction pointer as execution proceeds between code locations.);
a central processing unit directly in hardware of the computing system (Paragraph 88; “For example, the processor(s) 204 may execute an analysis and construction application (constructor) 210 for adjusting the intermediate code file(s) to apply the control flow runtime verification.”, Paragraph 74 contemplates hardware embodiments, “aspects of the present invention may take the form of an entirely hardware embodiment”.);
determining a rolling hash associated with the transfers (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” teaches calculating a rolling hash value that represents the runtime execution sequence which is updated based on the most recently executed changes. Each change in the runtime sequence corresponds to a transfer, thus the rolling hash is determined and associated with each transfer.);
determining a validity of the transfers based at least in part on the rolling hash (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path” teaches that, during runtime, a rolling hash of the observed execution sequence is computed and compared to the stored valid hash values to verify correspondence. It would have been obvious to a person of ordinary skill in the art to utilize the central processing unit to perform the step of determining transfer validity. A person of ordinary skill in the art would have recognized the use of a processor as an expected hardware component for performing operations in software systems, the implementation of which would yield the predictable result of enabling evaluation and enforcement of transfer validity.);
a sliding window of the control flow graph, and refreshes the sliding window as instructions are executed (Paragraph 58; “The runtime execution sequence may be therefore implemented as a sliding window comprising the unique identifiers of a predefined number of routines most recently executed and hence most recently registered.”, teaching maintaining information of the control flow graph as a sliding window structure. Paragraph 58 further discloses “The registration code segment may therefore be configured to discard the unique identifier of a least recent (oldest) registered routine from the beginning of the windowed runtime execution sequence when registering another routine by appending its unique identifier to the end of the windowed runtime execution sequence.”, which teaches refreshing the information in a sliding window structure during runtime execution.);
upon determining that a transfers is not represented in the control flow directed graph, suspending execution of an offending process while permitting the central processing unit to continue servicing other processes (Paragraph 65; “in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like.”, preventing the processor from executing the critical routine corresponding to suspending execution of an offending process. Allowing the processor to continue servicing other processes occurs through the remedial action only preventing execution of the critical routine and not preventing the processor itself from continuing to service other processes.);
generating a telemetry event comprising at least a subset of control flow sequences preceding the transfer that is invalid (Paragraph 65; “one or more indications and/or alerts of invalid execution” constitutes a telemetry event, which is based on “flow validation code segment may apply one or more pattern matching techniques to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s)”, and “in case the validation code segment determines that the runtime execution path is invalid, the validation code segment may initiate one or more predefined actions directed to prevent and/or indicate of the compromised execution flow. The predefined actions may include for example, crashing execution of the processor(s), halting execution of the processor(s), causing the processor(s) to branch to a predefined address, preventing the processor(s) from executing the critical routine, generating one or more indications and/or alerts of invalid execution and/or the like”. The runtime execution sequence evaluated using a rolling hash over the predefined number of most recent executed routines corresponds to a bounded subset of execution behavior. The rolling window is based on recently executed routines, such as the execution history immediately prior to the validation decision that determines whether execution may proceed or be halted. It would have been obvious to a person of ordinary skill in the art that the rolling execution sequence corresponds to a control flow sequence representative of execution up to the point of invalid transfer determination, which would be an implementation of known runtime state data for diagnostic reporting, yielding the predictable result of improved visibility into execution history leading to the invalid control flow event.).
Tshouva does not teach comparing against a hash table; or generating an instruction.
However, Chan teaches:
comparing against a hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva and Chan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva to incorporate the teachings of Chan and incorporate a hash table. A person of ordinary skill in the art would have understood that hash tables are a well-known data structure employed to enable efficient lookup, comparison, and storage of indexed values, and would have been motivated to use a hash table to quickly access and verify execution path data, by comparing the rolling hashes of Tshouva within the hash table of Chan. The use of known hash table matching techniques of Chan to the rolling hashes of Tshouva would have yielded the predictable result of efficiently identifying matching execution path representations while reducing comparison overhead associated with comparison of full execution sequences.
Tshouva in view of Chan does not teach downloading information at a time of instruction execution, or enforcing validity of the transfers.
However, Black teaches:
downloading information at a time of instruction execution (Paragraph 18; “When a CFG-aware executable image is loaded, the runtime can initialize an appropriate portion of the system-wide or per-process CFG bitmap based on the metadata”, which initializes information, thereby loading information, at a time the executable is loaded. It would have been obvious to a person of ordinary skill in the art to have loaded information at the time of instruction execution rather than solely at load time because Black already uses the CFG information during execution to validate control transfers. Loading information when needed during execution would be a predictable variation for reducing pre-initialization requirements, yielding the predictable result of reduced memory overhead with accessing preloaded CFG data.);
enforcing validity of the transfers (Paragraph 18; “CFG can enforce control flow integrity by adding instrumentation checks when source code is compiled to generate an executable image. A compiler can introduce instrumentation checks prior to certain types of indirect control transfers (such as indirect calls). These checks, which are carried out by the inserted instrumentation, can verify whether or not a target of an indirect control transfer is considered valid just before the control transfer occurs.”).
Tshouva, Chan, and Black are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan to incorporate the teachings of Black and have downloaded information to a CPU at execution time, the information comprising the control flow graph of Tshouva and hash table of Chan, for transfer validity enforcement, using the CPU and hardware of Tshouva. A person of ordinary skill in the art would have recognized that Black teaches that CFG information is used to validate control transfers. Applying the downloading technique of Black to the CFG of Tshouva and hashing of Chan would have yielded the predictable result of providing the control flow integrity information to the CPU of Tshouva when needed for enforcing runtime validation.
Tshouva in view of Chan, further in view of Black does not teach an instruction-based subgraph stored in cache.
However, Togawa teaches:
an instruction-based subgraph stored in cache (Paragraphs 51, 53; “For partitioning of an input CFG, the subgraph detector 108 of the partitioning unit 106 identifies a part comprising a sequence of instructions where there is only one entry node and only one exit node. Such a part is suitable for use as a subroutine of the policy (2) above and is suitably extracted as a cache block. Hereinafter, such a part will be referred to as an "extractable subgraph", and “generates a CFG comprising the extracted node”, corresponding to subgraphs that are portions of a CFG, and is stored in a cache-resident structure.);
Tshouva, Chan, Black, and Togawa are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black to incorporate the teachings of Togawa and have an instruction-based subgraph stored in the cache. A person of ordinary skill in the art would recognize caching instruction-level portions of a CFG to be a known method in the art for improving runtime analysis performance, and the use of cache storage for frequently accessed structures is a standard implementation approach in such systems, the incorporation of which would yield the application of a known method of cache based storage of execution data structures, yielding the predictable result of reduced memory access latency and faster CFG processing, and the use of a subgraph centered around a current instruction represents the application of the known technique of graph localization yielding the predictable result of improving computational efficiency by limiting analysis to relevant portions of the CFG.
Tshouva in view of Chan, further in view of Black, further in view of Togawa does not teach directly reachable nodes from a current instruction plus a predetermined depth of child nodes; or generating an instruction.
However, Aditham teaches:
comprising directly reachable nodes from a current instruction plus a predetermined depth of child nodes (Paragraphs 153-154; “Vertices in a CFG 1802 give the level of detail, such as instruction-level or basic block level that cannot be further divided. Edges in CFG 1802 represent control jumps and are classified into two types—forward and backward.”, where “A CFG 1802 contains all possible control-flow paths of a program.”, which teaches node-to-node reachability within a CFG through control flow paths. Further, “To reduce the complexity of graph algorithms, CFGs 1802 can be reduced to trees or subgraphs before performing any coherence or integrity checks.”, and traversal methods “(1) using the Smith-Waterman algorithm with Levenshtein distance to identify similarity between two graphs represented as strings and the time complexity is O(nm); (2) based on traversal, (a) a preorder traversal of a graph G where each node is processed before its descendants, and (b) a reverse postorder in a DAG gives a topological order of the nodes; (3) building a data structure built using Depth First Search”. The CFG is composed of instruction-level nodes connected by control flow edges. Nodes connected through control flow edges are reachable from other nodes in the CFG, thus corresponding to nodes reachable from a given instruction node through CFG traversal. It further teaches tree representations and traversal for processing descendants of a node. Since Aditham teaches reducing CFG complexity and selecting subgraphs using known algorithms, it would have been obvious to impose a predetermined threshold on subgraph expansion, corresponding to a depth limit, as a routine optimization to control graph size and computational cost, yielding the predictable result of reducing graph complexity and memory consumption, consistent with the design goals of Aditham of reducing CFG algorithm complexity.);
generating an instruction (Paragraphs 84-85, Table 2; “create packet with instructions”);
Tshouva, Chan, Black, Togawa, and Aditham are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa to incorporate the teachings of Aditham and have a structure comprising directly reachable nodes from the current instruction and a predetermined depth of child nodes. A person of ordinary skill in the art would have recognized that CFG traversal and graph-based analysis techniques explore successor nodes using search algorithms to reduce the complexity of full graph analysis. Application of a predetermined depth constraint to reachable nodes represents a known technique for limiting graph expansion, yielding the predictable result of reducing computational overhead while preserving relevant control flow context around a current instruction. Further, it would have been obvious to generate an instruction in response to detecting an invalid control flow condition because runtime control flow validation systems typically respond to invalid execution paths by initiating corrective actions during execution. Inserting or generating a terminating instruction represents the application of a known runtime enforcement mechanism (i.e. trap, halt, abort), which is also contemplated by Tshouva, yielding the predictable result of immediately terminating or redirecting execution upon detection of invalid control flow, thereby improving system integrity.
Regarding claim 16, Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham teach the apparatus of claim 15. Tshouva further teaches:
wherein determining the validity of the transfers comprises:
determining a sequence of multiple transfers (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence”, where each addition to the runtime execution sequence corresponds to a transfer event, therefore determining the runtime execution sequence includes determining a sequence of multiple transfers.);
determining a hash value of the rolling hash associated with the sequence of transfers (Paragraph 59; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s). The rolling hash value of the runtime execution sequence may be calculated and constantly updated for the unique identifiers of the current most recently registered routines” explicitly discloses a calculation, corresponding to a determination, of a hash value of the rolling hash associated with the sequence of transfers.);
and determining that the sequence of multiple transfers is valid based on the hash value (Paragraph 61; “the flow validation code segment may be configured to apply one or more pattern matching methods, technique and/or algorithms for matching the runtime execution sequence to the ordered patterns of the valid execution path(s). In particular, in case of expressing the valid execution path(s) and the runtime execution sequence using the rolling hash values, the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s)” teaches the validity check based on the hash value corresponding to the expected hash.).
Chan teaches:
a hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Nakaike, further in view of Mallon.
Regarding claim 17, Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham teach the apparatus of claim 15. Tshouva further teaches:
determining one or more sequences of transitions (Paragraph 58; “The intermediate code file(s) may be adjusted to include a registration code segment configured to register each of the plurality of routines in a runtime execution sequence upon execution of the respective routine. In particular, the registration code segment may be configured to register the respective routine by appending the unique identifier of the respective routine to the runtime execution sequence” corresponds to determining one or more sequences of transitions.).
Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham does not teach being based at least in part on the one or more sequences being traversed over a threshold number of times during the observation phase.
However, Nakaike teaches:
based at least in part on the one or more sequences being traversed over a number of times during the observation phase (Paragraph 160; “In step 306, the computer (101) obtains execution frequency information by using the control flow graph modified in step 305. In the case where step 305 is not carried out, the computer (101) obtains execution frequency information by using the control flow graph prepared in step 303.”).
Tshouva, Chan, Black, Togawa, Aditham, and Nakaike are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham to incorporate the teachings of Nakaike and have the sequences of transitions determined at least in part on one or more of the sequences being traversed over a number of times during the observation phase. A person of ordinary skill in the art would have recognized frequency of execution as a known and predictable indicator of importance, relevance, or abnormality in runtime behavior. Motivation to use traversal frequency to determine sequences of transitions would come from the goal of prioritizing frequently executed paths for validation, yielding expected improvements in performance analysis and system efficiency.
Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Nakaike does not teach a threshold.
However, Mallon teaches:
a threshold (Paragraph 15; “For example, in an embodiment the first variable may be selected from a set of variable that have small liveness regions, e.g., that at most a threshold number of blocks. The threshold may be, say, 2, 4, or the like.”).
Tshouva, Chan, Black, Togawa, Aditham, Nakaike, and Mallon are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Nakaike to incorporate the teachings of Mallon and incorporate a threshold as thresholds are a well-known technique for filtering, triggering, or decision-making, with the expected and predictable improvement of distinguishing significant events or values from normal variation.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Ghose, further in view of Venkatesan.
Regarding claim 18, Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham teach the apparatus of claim 15. Chan teaches:
determining a set of hash values from the hash table (Paragraph 60; “Level 2 flow control 504 and level 3 flow control 506 may look up message objects by source and message ID or destination and message ID in message object hash table 610 for flow control, as will be further described. Message object hash table 610 may maintain hash values as indexes into each entry”).
Tshouva teaches:
determining a subset of the set of hash values (Paragraphs 58-59; “The runtime execution sequence may be therefore implemented as a sliding window comprising the unique identifiers of a predefined number of routines most recently executed and hence most recently registered”, where the sliding window comprising the unique identifiers of a predefined number of routines whose runtime execution sequence is “expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)” corresponds to a subset of the set of hash values)
determining the validity based on a subset of the rolling hash associated with the transfers corresponding to a hash value of the subset of the set of hash values (Paragraphs 59-61; “Moreover, the runtime execution sequence may be expressed by a rolling hash value calculated for the predefined number of most recently registered routines using the rolling hash function(s) used to calculate the rolling hash value(s) of the valid execution path(s)”. Further, “the flow validation code segment may be configured to match between the rolling hash value calculated for the runtime execution sequence, in particular for the predefined number of most recently executed routines and the hash value(s) calculated for each of the valid execution path(s).”).
Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham does not teach the determination being based on a start position within the control flow directed graph; or based on a number of transitions included within the transfers.
However, Ghose teaches:
based on a start position within the control flow directed graph (Col. 15, lines 56-60; “Each legal flow path within a single execution module may be specified as a segment from an entry point or instruction that can change the flow of control to a next instruction that can change the flow of control, and wherein each segment has a predetermined reference signature.”).
Tshouva, Chan, Black, Togawa, Aditham, and Ghose are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham to incorporate the teachings of Ghose and have the set of hash values be determined based on the start position within the CFDG. A person of ordinary skill in the art would have recognized that anchoring computation to a known starting node, such as the entry point of instruction in a graph, would be a predictable method of maintaining consistency and context when representing execution paths, thereby improving accuracy in path validation and comparison.
Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Ghose does not teach based on a number of transitions included within the transfers.
However, Venkatesan teaches:
based on a number of transitions included within the transfers (Paragraph 114; “Here is heuristic based upon the above illustration of "random walk": Let R be the undirected graph whose vertices are the nodes of the CFG and which has an edge on a vertex pair if and only if the corresponding vertex pair in the CFG has a (directed) control flow edge, in either direction. Clearly, R is a graph with maximum degree three. It starts at the original node w, and at any node x, takes one of the dx edges with uniform probability. (dx is the degree of x). It aborts when it encounters a procedure boundary (call or branch to another procedure) or when the path length crosses a pre-determined limit”, where the path length corresponds to the applicant’s number of transitions).
Tshouva, Chan, Black, Togawa, Aditham, Ghose, and Venkatesan are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Ghose to incorporate the teachings of Venkatesan and have determined a subset of the set of hash values based on the number of transitions within the transfers. A person of ordinary skill in the art would have recognized that filtering data according to path length or transition count is a known and predictable technique for managing computational complexity and focusing analysis on relevant code segments, yielding the predictable improvement of balancing accuracy and efficiency.
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Van.
Regarding claim 19, Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham teach the apparatus of claim 15. Tshouva teaches:
wherein generating the control flow directed graph comprises normalizing the telemetry into a control flow directed graph representation (Paragraph 57; “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path”, where the respective ordered pattern corresponds to a form of normalized telemetry which concatenates unique identifiers of valid execution paths.).
Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham does not teach wherein the telemetry comprises central processing unit (CPU) telemetry.
However, Van teaches:
wherein the telemetry comprises central processing unit (CPU) telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Tshouva, Chan, Black, Togawa, Aditham, and Van are considered to be analogous to the claimed invention because they are in the same field of control flow integrity. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham to incorporate the teachings of Van and have the telemetry comprise CPU telemetry. A person of ordinary skill in the art would have recognized CPU-related metrics as a known type of telemetry collected during program execution and their inclusion would yield the predictable result of providing processor execution context for analysis of control flow transfers.
Regarding claim 20, Tshouva in view of Chan, further in view of Black, further in view of Togawa, further in view of Aditham, further in view of Van teach the apparatus of claim 19. Tshouva teaches:
wherein the monitoring phase is performed using a hardware device of the computing system (Paragraph 47; “For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit”);
wherein determining the validity is based at least in part on identifying an instruction sequence in the telemetry that is not present in the control flow directed graph (Paragraphs 57-60; “On the other hand, in case the runtime execution sequence does not match any of the valid execution path(s) associated with the respective critical routine, the validation code segment may determine that the runtime execution path is invalid and that the processor(s)′ control flow may be compromised”, where the runtime execution sequence not matching any valid execution path corresponds to identifying an instruction sequence in telemetry that is not present in the CFG. The CFG is further disclosed to identify valid execution paths in Paragraph 57, “For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s)”).
Van teaches:
CPU telemetry (Paragraph 111; “(a) at an OOB telemetry manager in a core of a processor, collecting telemetry data for the processor; (b) sending the telemetry data from the OOB telemetry manager to a telemetry push agent in a distributed core perimeter of the processor”. Paragraph 31 further confirms this is CPU telemetry; “As described in greater detail below, telemetry collector 44 collects telemetry data based on settings that telemetry collector 44 obtains from telemetry configuration register 24 via the register fabric in core 20A.”).
Response to Arguments
Applicant's arguments filed 03/19/2026 have been fully considered. Applicant’s arguments are summarized below:
Amendments made to independent claims 1, 8, and 15 render the 35 U.S.C. 101 rejection of claims 1-20 moot.
The prior art of record fails to render the amended subject matter of claims 1, 8, and 15 obvious.
Dependent claims are submitted as allowable for at least the above reasons.
Examiner’s response:
The Examiner agrees that the amendments to independent claims 1, 8, and 15 to clarify the hardware that performs the telemetry routing, analysis, and transmittal integrate the exception into a practical application. Accordingly, the rejections of claims 1-20 under 35 U.S.C. 101 are withdrawn.
The Examiner agrees that the prior art of record does not teach the amended limitations of independent claims 1, 8, and 15. Accordingly, the previous rejections of claims 1, 8, and 15 under 35 U.S.C. 103 are withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Tshouva, Zou, Chan, Sultana, Pike, Van, and Vidyadhara, with regard to claim 1, Tshouva, Zou, Chan, and Turkulainen, with regard to claim 8, and Tshouva, Chan, Black, Togawa, and Aditham, with regard to claim 15, under 35 U.S.C. 103.
Independent claims 1, 8, and 15 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Henriksen et al. (US 9639351 B2) discusses matching and attributing code violations using a graph of the snapshots of the code base utilizing a rolling hash function for a fixed window representing a subset of the sequence.
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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights