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 .
DETAILED ACTION
This office action is in response to the application filed on 6/26/2024. Claims 1-20 are pending in this application. Claims 1, 14, and 20 are independent claims.
Priority
Applicant’s claim for the benefit of prior-filed applications under 35 U.S.C 119(e) or under 35 U.S.C. 120, 121, 365(c) is acknowledged. The present application claims priority to U.S. Provisional Application No. 63/524,344 filed on June 30th, 2023, and U.S. Provisional Application No. 63/525,438 filed on July 7th, 2023. The earlier filling date of June 30th, 2023, is granted.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 5, 14, 15, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ko (US20020138755A1) in view of Baker et al (US11409864B1).
Regarding claim 1, Ko teaches: A method for dynamic runtime computer code monitoring, the method is performed by a computer processor, the method comprising ([0002] “The present invention relates computer security and intrusion detection systems. More specifically, the present invention relates to a method and an apparatus for automatically generating a valid behavior specification for use in an intrusion detection system.” [0012] “In one embodiment of the present invention, the system additionally monitors an executing program.” [0026] “Intrusion detection system 101 includes storage device 103, rule generator 106 that generates valid behavior specification 108, and run-time monitoring system 110”) Ko discloses a computer-implemented intrusion detection system that includes run-time monitoring and additionally teaches monitoring an executing program. This corresponds to the claimed dynamic runtime computer code monitoring because Ko’s system monitors a program while it is executing, therefore dynamically monitoring the program at runtime.
during execution of a computer code, detecting a plurality of system calls initiated during the execution (See FIG. 2, 202 with the associated text, “retrieve system call generated by executing program” [0031] “For each system call, run- time monitoring system 110 first retrieves the system call (step 202)” “These steps are repeated for all system calls generated by executing program 102.” See FIG. 3, 302 with the associated text, “receive exemplary set of system calls” [0086] “The process starts when the system receives an exemplary set of system calls, including positive examples, E+, and negative examples, E− (step 302).”) Ko discloses that during the execution of a computer program, its run-time monitoring system detects system calls generated by the executing program. Ko further discloses the claimed limitation of detecting a plurality of system calls by describing the detection and retrieval of the system calls generated by the executing program.
during the execution of the computer code (See FIG. 2, 202 with the associated text, “retrieve system call generated by executing program” [0027] “During execution of program 102”) Ko teaches a monitoring system that operates on system calls during the execution of computer code.
analyzing the selected system call, according to at least one predefined rule ([0028] “During a program monitoring process, run- time monitoring system 110 receives an audit trail 104 from an executing program 102 and uses valid behavior specification 108 to determine whether audit trail 104 contains any invalid system calls.”) Ko teaches using valid behavior specification to determine whether system calls in an audit trail are invalid which corresponds to analyzing the selected system call according to at least one predefined rule.
Ko does not teach: selecting at least one of the detected system calls, wherein the selection of the at least one of the detected system calls is performed based on a selection criterion
However, Baker teaches: selecting at least one of the detected system calls, wherein the selection of the at least one of the detected system calls is performed based on a selection criterion ([Col. 3 Lines 47-51] “The tracing manager can further inspect the system call and determine a subsequent operation, including resuming the system call, blocking the system call, logging the system call, communicating a notification (e.g., exception) to a user device originating the compute request, etc.” [Col. 3 Lines 56-59] “The disclosed techniques can be used for performing argument inspection for system calls in user code runtime environments using specifications on which argument is allowed or blocked.” [Col. 3 Lines 63-64] “as well as logging system calls that are selected based on pre-configured filtering criteria.”) Baker teaches utilizing predetermined filtering rules to identify particular system calls from among those being monitored, which allows the system to selectively process calls that meet the specified criteria.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Ko’s teaching of runtime monitoring of system calls with Baker’s teachings of selecting system calls based on criteria to achieve a system that selects particular system calls during execution based on a selection criterion, allowing the system to identify and selectively process relevant system calls.
Regarding claim 2, Ko further teaches: wherein the selected system calls are fewer than the detected system calls. ([0009] “Moreover, the process of selecting a rule for the valid behavior specification involves using an objective function that seeks to maximize the number of positive examples covered by the rule while seeking to minimize the number of possible system calls covered by the rule.”) Ko teaches selecting a rule that minimizes the number of possible system calls covered by the rule. The selected rule applies to only a smaller set of system calls than the full set being considered, representing that the selected system calls can be fewer than the detected system calls.
Regarding claim 3, Ko does not teach: wherein the selection criterion is based at least on system call type
However, Baker teaches: wherein the selection criterion is based at least on system call type ([Col. 3 Lines 40-42] “The user code runtime can be configured with a filtering process with different categories of system call lists” [Col. 3 Lines 63-64] “system calls that are selected based on pre-configured filtering criteria” [Col. 15 Lines 63-65] “In some embodiments, the filtering policies 416 include a plurality of filtering lists, each filtering list associated with a corresponding plurality of system call categories”) Baker teaches selecting system calls based on pre-configured filtering criteria, including criteria corresponding to system call categories. Additionally, Baker teaches multiple filtering lists associated with different system call categories that result in different processing of the corresponding system calls, and the selection criteria is based on at least the type/category of the system call.
Regarding claim 5, Ko does not teach: wherein said selecting is carried out during the execution of the computer code, by determining for each respective one of the detected system calls, before execution of an operating system service responsive to the respective system call, whether the respective system call should be analyzed
However, Baker teaches: wherein said selecting is carried out during the execution of the computer code, by determining for each respective one of the detected system calls, before execution of an operating system service responsive to the respective system call, whether the respective system call should be analyzed ([Col. 20 Lines 57-59] “At operation 706, a system call of the at least one operation is detected based on a notification from an OS manager, the notification identifying the system call.” ([Col. 20 Line 67 – Col. 21 Line 3] “as part of the filtering policies 416, the OS kernel 414 communicates a notification of the system call to the tracing manager 402 for performing tracing and verification functions.” ([Col. 21 Lines 4-11] “At operation 708, a determination is made on whether performing the system call is permitted based on the plurality of filtering policies. For example, after the tracing manager 402 receives the notification identifying the system call from the OS kernel 414, the tracing manager 402 may perform a trace or other verification functions to determine whether the system call may resume or whether it should be blocked.”) Baker teaches detecting a system call and having the tracing manager evaluate the system call based on filtering policies. The tracing manager as taught may perform tracing or verification functions to determine whether the system call can resume or if it should be blocked. This corresponds to the claimed selection based on the detected system call.
Regarding claim 14, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 1. Therefore, claim 14 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 15, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 3. Therefore, claim 15 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Regarding claim 17, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 5. Therefore, claim 17 is also rejected under the same rationale as cited in the rejection of claim 5 above.
Regarding claim 20, it is a system claim having similar limitations cited in the rejection of claim 1. Therefore, claim 20 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Ko (US20020138755A1) in view of Baker et al (US11409864B1) and in further view of Qian et al (US20150334128A1).
Regarding claim 4, Qian teaches: wherein according to the selection criterion, all system calls of a first type are selected and subjected to said analyzing, but only some of a plurality of system calls of a second type are selected and subjected to said analyzing. ([0015] “block 104 selects a subset of system calls to monitor” [0016] “ Block 202 performs lightweight, selective monitoring of syscalls. Since lightweight monitoring monitors only a subset of system calls, certain system calls, such as read and write, may never be captured. [0030] “The monitor 506 may track all system calls or only a subset.”) Qian teaches a system for selecting and analyzing all system calls of one category, while selecting and analyzing only a subset of system calls of another category. This corresponds to the applicant’s teaching because Qian’s first category maps to the claimed first type where all calls are selected and Qian’s second category maps to the claimed second type where only some call are selected.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ko with Qian to result in a more efficient system with reduced processing while still capturing the most relevant calls.
Regarding claim 16, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 4. Therefore, claim 16 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Claims 6-10, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ko (US20020138755A1) in view of Baker et al (US11409864B1) and in further view of Poghosyan et al (US20220283924A1).
Regarding claim 6, Ko does not teach: wherein the predefined criterion is based at least partially on a sampling rate predefined for each respective one of a plurality of system call types.
However, Poghosyan teaches: wherein the predefined criterion is based at least partially on a sampling rate predefined for each respective one of a plurality of system call types. ([0006] “The computer-implemented methods and systems sort the applications according to different trace types and different durations and generate different sampling rates, where each sampling rate corresponds to a different trace type and/or different duration.”) Poghosyan teaches that traces are classified according to trace type, with each trace type corresponding to a respective group of traces. For each trace type, Poghosyan determines a corresponding sampling rate, which then is applied to the traces in that type group.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the specific sampling technique teachings of Poghosyan to the system call types identified and monitored by the teachings of Ko. Doing so would result in a system call type having an associated sampling rate.
Regarding claim 7, Ko does not teach: wherein the selection criterion is based at least partially on a sampling rate predefined for each respective one of a plurality of system call types, and updated dynamically
However, Baker teaches: for each respective one of a plurality of system call types, and updated dynamically ([Col. 19 Lines 1-3] “the list of system calls that need to be blocked immediately may be part of the filtering policies 416 and may be updated dynamically”) Baker teaches that system calls may be updated dynamically once filtered through the set criteria.
Additionally, Poghosyan teaches: wherein the selection criterion is based at least partially on a sampling rate predefined ([0006] “The computer-implemented methods and systems sort the applications according to different trace types and different durations and generate different sampling rates, where each sampling rate corresponds to a different trace type and/or different duration.”) Poghosyan teaches that traces are classified according to trace type, with each trace type corresponding to a respective group of traces. For each trace type, Poghosyan determines a corresponding sampling rate, which then is applied to the traces in that type group.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the specific sampling technique teachings of Poghosyan to the system call types identified and monitored by the teachings of Ko and Baker. Doing so would result in a system call type having an associated sampling rate while updating dynamically.
Regarding claim 8, Ko does not teach: wherein the selection criterion defines a preliminary sampling rate of the detected system calls.
However, Baker teaches: detected system calls ([Col. 20 Lines 57-58] “At operation 706, a system call of the at least one operation is detected”) Baker system calls being detected.
Additionally, Poghosyan teaches: wherein the selection criterion defines a preliminary sampling rate ([0006] “The computer-implemented methods and systems sort the applications according to different trace types and different durations and generate different sampling rates, where each sampling rate corresponds to a different trace type and/or different duration.”) Poghosyan teaches that traces are classified according to trace type, with each trace type corresponding to a respective group of traces. For each trace type, Poghosyan determines a corresponding sampling rate, which then is applied to the traces in that type group.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the specific sampling technique teachings of Poghosyan to the system call types identified and monitored by the teachings of Ko and detecting system calls taught by Baker. Doing so would result in a system call type having an associated sampling rate.
Regarding claim 9, Ko does not teach: wherein the selection criterion defines a preliminary call-type-specific sampling rate for each respective one of a plurality of system call types
However, Baker teaches: wherein the selection criterion defines a preliminary call-type-specific and for each respective one of a plurality of system call types ([Col. 15 Lines 63-66] “In some embodiments, the filtering policies 416 include a plurality of filtering lists, each filtering list associated with a corresponding plurality of system call categories that trigger different processing by the tracing manager”) Baker teaches a plurality of system call types/categories and associates the respective categories with different filtering/processing policies. Baker further detects a system call and determines its applicable category.
Additionally, Poghosyan teaches: sampling rate ([0006] “The computer-implemented methods and systems sort the applications according to different trace types and different durations and generate different sampling rates, where each sampling rate corresponds to a different trace type and/or different duration.”) Poghosyan teaches that traces are classified according to trace type, with each trace type corresponding to a respective group of traces. For each trace type, Poghosyan determines a corresponding sampling rate, which then is applied to the traces in that type group.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the specific sampling technique teachings of Poghosyan to the system call types identified and monitored by the teachings of Ko and Baker. Doing so would result in a system call type having an associated sampling rate.
Regarding claim 10, Ko does not teach: updating the call-type-specific sampling rate according to a result of said analyzing.
However, Baker teaches: updating the call-type-specific and according to a result of said analyzing. ([Col. 3 Lines 30-34] “More specifically, a tracing manager (also referred to as a tracing function or a tracing management function) can be configured to monitor and audit malicious system calls associated with user code runtime for a UDF, as well as report and analyze them retrospectively.” ([Col. 19 Lines 1-3] “the list of system calls that need to be blocked immediately may be part of the filtering policies 416 and may be updated dynamically”) Baker teaches that system calls may be updated dynamically once filtered through the set criteria corresponding to the call type being updated once the system call is detected and analyzed.
Additionally, Poghosyan teaches: sampling rate ([0006] “The computer-implemented methods and systems sort the applications according to different trace types and different durations and generate different sampling rates, where each sampling rate corresponds to a different trace type and/or different duration.”) Poghosyan teaches that traces are classified according to trace type, with each trace type corresponding to a respective group of traces. For each trace type, Poghosyan determines a corresponding sampling rate, which then is applied to the traces in that type group.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the specific sampling technique teachings of Poghosyan to the system call types identified and monitored by the teachings of Ko and Baker. Doing so would result in a system call type having an associated sampling rate while updating dynamically.
Regarding claim 18, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 6. Therefore, claim 18 is also rejected under the same rationale as cited in the rejection of claim 6 above.
Regarding claim 19, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 7. Therefore, claim 19 is also rejected under the same rationale as cited in the rejection of claim 7 above.
Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Ko (US20020138755A1) in view of Baker et al (US11409864B1) and in further view of Weingarten et al (US20200311271A1).
Regarding claim 11, Ko teaches: said analyzing comprises checking whether an action carried out using the selected system call deviates from the predefined rule. ([0027] “During a behavior specification generation process, audit trail 104 is fed through rule generator 106 in order to generate a set of rules that comprise valid behavior specification 108.” [0033] “a valid behavior specification of a program constrains the sequence of operations that can be performed by the program during execution.” [0031] “For each system call, run- time monitoring system 110 first retrieves the system call (step 202), and then determines if the system call is covered by a clause (rule) from within valid behavior specification 108 (step 204).”) Ko teaches evaluating a retrieved system call against the rules in its valid behavior specification to determine whether the system call is permitted by the executed behavior. This corresponds to the claimed teaching of checking system call activity against the predefined rule.
Ko does not teach: wherein the predefined rule relates to a previously learnt behavioral profile of at least a part of the computer code
However, Weingarten teaches: wherein the predefined rule relates to a previously learnt behavioral profile of at least a part of the computer code ([0141] “Following the second operation, a third operation of P1 injecting code (505) in the allocated memory in P2 occurs. According to certain embodiments, the operation of code injection can comprise three actions: memory write, memory execution permissions, and code execution, all of which are monitored.” “A behavior of code injection is determined (506) in accordance with one of the predefined behavioral logics, and accordingly a behavioral score S2 is assigned.”) Weingarten teaches a predefined behavioral logic (rule) based on previously learned behavioral information which is applied to monitored behavior of at least a part of the computer code. Therefore, corresponding to the claimed predefined rule relating to a previously learned behavioral profile.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Ko’s system call monitoring system with Weingarten’s predefined behavioral logic that would provide a broader assessment of runtime computer code behavior. Therefore, improving the ability of the combines system to detect malicious activity.
Regarding claim 12, Ko teaches: wherein the previously learnt behavior profile is determined based on executions of the computer application ([0012] “The system then determines whether the system call is covered by a rule from within the valid behavior specification.” [0024] “FIG. 1 illustrates a computer system 100 that contains an intrusion detection system 101 in accordance with an embodiment of the present invention. Computer system 100 executes a program” [0068] “The set of Horn clauses S is called a “valid behavior specification”. The set of clauses B and P form a logic program which defines the relationships among the attributes in a valid operation of a program.”) Ko teaches generating a valid behavior specification from execution behavior. Ko describes running a program and recording its system calls to produce an exemplary set of system calls and then generating the valid behavior specification from those examples. Additionally, Ko describes using example runs and execution traces to construct the specification. Therefore, Ko teaches a previously learned behavior profile determined from executions of a computer program.
whereby the behavior profile utilized during execution of the computer code is based on executions of a different computer program. ([0012] “The system then determines whether the system call is covered by a rule from within the valid behavior specification.” [0024] “FIG. 1 illustrates a computer system 100 that contains an intrusion detection system 101 in accordance with an embodiment of the present invention. Computer system 100 executes a program”) Ko teaches generating a valid behavior specification from executions of a program and utilizing the specification to monitor an executing program. Therefore, Ko teaches a behavioral profile based on executions of a program that is used during the execution of another program.
Ko does not teach: wherein the part of the computer code is included in a computer application, the computer application is different than the computer code
However, Baker teaches: wherein the part of the computer code is included in a computer application, the computer application is different than the computer code ([Col. 14 Lines 38-40] “In some aspects, user code 418 may be provided as a package e.g., in the form of a JAR (JAVA archive) file which includes code for one or more UDFs.” [Col. 14 Lines 48-50] “In an embodiment, the user code runtime 410 is implemented as a virtual machine, such as a JAVA virtual machine (JVM).”) Baker teaches that a user-defined function includes computer code and is executed by a separate user code runtime. Baker further explains that the user code may be provided as a package containing code. Therefore, Baker teaches that the claimed computer code is part of and executed within a separate computer application/runtime rather than just being the application itself.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Ko’s behavior specification to Baker’s UDF execution and tracing environment because both references address detecting malicious activity. Combining these known techniques would result in the claimed limitation.
Regarding claim 13, Ko teaches: said analyzing comprises checking whether an action carried out using the selected system call deviates from the predefined rule. ([0027] “During a behavior specification generation process, audit trail 104 is fed through rule generator 106 in order to generate a set of rules that comprise valid behavior specification 108.” [0033] “a valid behavior specification of a program constrains the sequence of operations that can be performed by the program during execution.” [0031] “For each system call, run- time monitoring system 110 first retrieves the system call (step 202), and then determines if the system call is covered by a clause (rule) from within valid behavior specification 108 (step 204).”) Ko teaches evaluating a retrieved system call against the rules in its valid behavior specification to determine whether the system call is permitted by the executed behavior. This corresponds to the claimed teaching of checking system call activity against the predefined rule.
Ko does not teach: wherein the predefined rule relates to a previously learnt behavioral profile of a library, the library includes a plurality of functions, wherein the previously learnt behavioral profile of the library is based on behavior of the plurality of functions, wherein the part of the computer code is one of the plurality of functions
However, Weingarten teaches: wherein the predefined rule relates to a previously learnt behavioral profile of a library, the library includes a plurality of functions, wherein the previously learnt behavioral profile of the library is based on behavior of the plurality of functions, wherein the part of the computer code is one of the plurality of functions ([0032] “in accordance with one or more predefined behavioral logics, and determining the presence of at least one behavior of the one or more behaviors upon any of the predefined behavioral logics being met” [0034-0035] “a computer-implemented method wherein each of the at least one behavior is assigned with a respective behavioral score.” “searching if there is a previous stateful model score associated with the previous stateful model” [0039] “a system for detecting malware in real time in a live environment, the system comprising a processor configured to perform at least the following: monitor one or more operations of at least one program concurrently running in the live environment; build at least one stateful model in accordance with the one or more operations” [0086] “In some cases, the in-process operations can be monitored (e.g., by the In-process Monitoring module) by intercepting one or more library calls” [0054] “FIG. 5 is a generalized flowchart of an exemplified sequence of operations being monitored and processed in accordance with certain embodiments of the presently disclosed subject matter.”) Weingarten teaches evaluating monitored program behavior using predefined behavioral logic based on prior behavioral knowledge, including behavior associated with a plurality of functions from imported libraries. Accordingly, Weingarten corresponds to the claimed predefined rule relating to a previously learned behavioral profile of a library and the behavior of the library’s plurality of functions.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Ko’s rule-based system call monitoring with Weingarten’s library/function based behavioral analysis. Doing so would result in a more comprehensive assessment of program behavior, therefore enhancing the applicant’s teaching of dynamically monitoring computer code at runtime.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(US12032661B2) Hardware-assisted System And Method For Detecting And Analyzing System Calls Made To An Operating System Kernel
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tubba Noor whose telephone number is 571-270-0803. The examiner can normally be reached on Monday-Friday from 8:00 AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
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.
/TUBBA NOOR/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights