DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Claims 1-20 are rejected in the Instant Application.
Allowable Subject Matter
Claims 7, 8, 15, 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 8/8/24, 8/27/24 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Rejections - 35 USC § 103
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 9-14, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kabra et al. (US10033759B1) hereinafter Kabra in view of Eskin et al. (US20040205474A1) hereinafter Eskin.
Regarding claims 1, 11, 19. Kabra teaches a method (claim 11: see computerized method) comprising:
obtaining a system call stream from executing an instrumented program comprising an instrumented portion, wherein the instrumented portion comprises instrumentation to add (Col 3 lines 20-30 see virtual machine operating in guest mode, to intercept (from call stream) a particular system call (sometimes referred to as a “hooked syscall”) within a guest operating system (OS) kernel (hereinafter “guest kernel”) and provide control to a hypervisor operating in host mode. According to one embodiment of the disclosure, the hooked syscall may be intercepted by inserting a breakpoint (add) (e.g., a single byte instruction such as a HALT instruction));
monitoring the system call stream for a start delimiter defined by instrumentation in the instrumented program (Col 8 lines 40-50 see The guest agent 320 is adapted to monitor what processes are running in the guest user mode and provide information for selecting the “hooked” [start delimiter] syscalls, namely the syscalls that are to be intercepted and monitored by the hypervisor.);
extracting a system call trace starting at the start delimiter (Col 3 lines 55-60 see exploit detection logic analyzes metadata (trace), inclusive of at least some of the context information associated with the hooked syscall [delimiter]) ;
processing the system call trace through an attack model to obtain an attack probability (Col 10 lines 30-35 see in response to receipt of the trap during run-time, the hypervisor 370 subsequently diverts control flow to exploit detection logic 345 within the guest kernel 335. The exploit detection logic 345 is configured to analyze metadata or other context information associated with the hooked syscall);
generating an alert identifying the attack and the instrumented portion (Col 15 lines 40-45 see context analyzer logic 600 identifies that the object 315 is associated with a malicious attack and information is sent to the guest agent 320 that reports (though a formatted message) that the object 315 includes a potential exploit).
Kabra does not explicitly teach detecting an attack based on a comparison of the attack probability with an attack detection threshold
Eskin however in the same field of computer networking teaches detecting an attack based on a comparison of the attack probability with an attack detection threshold (¶0018 see predictive probability is below a predetermined threshold, the sequence of system calls is identified as an intrusion)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the intrusion detection of Kabra and the teachings of Eskin for detecting an attack based on attack probability to combine the teachings such that Kabra utilizes the teachings of Eskin for detecting intrusions. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will provide a technique which is not limited to a fixed window size for analyzing sequential behavior and which provides the ability to detect intrusions in the operation of the computer system (Eskin ¶0012).
Further regarding claim 11: Kabra further teaches a system comprising: at least one processor; and instructions executing on the at least one processor to cause the at least one processor to perform operations (Kabra Col 4 lines 15-25 see circuitry may include, but are not limited or restricted to a hardware processor (e.g., microprocessor with one or more processor cores, a digital signal processor, a programmable gate array, a microcontroller, an application specific integrated circuit “ASIC”, etc.), a semiconductor memory, or combinatorial elements)
Further regarding claim 19: Kabra further teaches a non-transitory computer readable storage medium comprising computer readable program code for causing a computing system to perform operations (Kabra Col 4 lines 33-36 see software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium)
Regarding claims 2, 12, 20. The already combined references teach the method of claim 1, wherein detecting an attack is performed in real time while the instrumented program is executing (Kabra Col 3 lines 20-30 see during run-time (e.g., a guest “execute” cycle) of a virtual machine operating in guest mode, to intercept a particular system call (sometimes referred to as a “hooked syscall”) within a guest operating system (OS) kernel).
Regarding claim 3. The already combined references teach the method of claim 1, further comprising:
receiving a plurality of system call streams by a kernel executing in kernel space (Kabra Col 8 lines 38-50 see guest agent 320 is adapted to monitor what processes are running in the guest user mode and provide information for selecting the “hooked” syscalls, namely the syscalls that are to be intercepted and monitored by the hypervisor. Additionally, the guest agent 320 is adapted to receive from the guest OS kernel 335 information associated with detected events that suggest a malicious attack);
adding, by a probe executing in the kernel space, the plurality of system calls as the system call stream to a buffer (Kabra Col 10 lines 50-60 see the guest agent 320 includes one or more ring buffers 325 (e.g., queue, FIFO, buffer, shared memory, and/or registers) to record the metadata used for syscall selection as well as information associated with certain characteristics determined by the exploit detection logic); and
obtaining, by a monitor executing in user space, the system call stream from the buffer (Kabra Col 10 lines 50-60 see guest agent 320 includes one or more ring buffers 325 (e.g., queue, FIFO, buffer, shared memory, and/or registers) to record the metadata used for syscall selection as well as information associated with certain characteristics determined by the exploit detection logic 345 that signify the object is an exploit or includes malware), wherein the system call stream is obtained by an attack detector from the monitor (Kabra the guest agent 320 includes one or more ring buffers 325 (e.g., queue, FIFO, buffer, shared memory, and/or registers) to record the metadata used for syscall selection as well as information associated with certain characteristics determined by the exploit detection logic 345 that signify the object is an exploit or includes malware).
Regarding claim 4. The already combined references teach the method of claim 1, further comprising:
Kabra does not explicitly teach training the attack model with a plurality of training traces; and testing the attack model with a plurality of test traces.
Eskin however in the same field of computer networking teaches training the attack model with a plurality of training traces (¶0018 see probabilistic detection model is trained from a plurality of predetermined, or training, sequences of system calls to calculate the optimal number of previous system calls analyzed); and testing the attack model with a plurality of test traces (¶0068 see Traces from each program in each data set were separated into a disjoint training and testing portion. The training set contained approximately ⅔ of the traces and the test set contained the remaining traces. Training and testing were performed on different sets of data in order to simulate how the method may work in practice, i.e., testing a model against data that has not been observed when building the model.)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the intrusion detection of Kabra and the teachings of Eskin for testing models to combine the teachings such that Kabra utilizes the teachings of Eskin for detecting intrusions. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will provide a technique which is not limited to a fixed window size for analyzing sequential behavior and which provides the ability to detect intrusions in the operation of the computer system (Eskin ¶0012).
Regarding claims 5, 13. The already combined references teach the method of claim 1, wherein processing the system call trace through the attack model comprises:
Kabra does not explicitly teach traversing a plurality of system call nodes in the attack model according to an order defined by a plurality of system calls in the system call trace to obtain a probability series for the system call trace; and determining the attack probability from the probability series
Eskin however in the same field of computer networking teaches traversing a plurality of system call nodes in the attack model according to an order defined by a plurality of system calls in the system call trace to obtain a probability series for the system call trace (¶0039 see goal of the system call modeling method is to be able to determine whether a short subsequence of system calls corresponds to a normal execution path or to an exploit execution path. Theoretically given access to the program's call graph that was labeled with normal and exploit paths..¶0049 see sparse prediction tree is a rooted tree where each node is either a leaf node or contains one branch labeled with *n for n≧0 that forks into a branch for each element in Σ (each system call). Each leaf node of the tree is associated with a probability distribution over the system calls, Σ. FIG. 5 illustrates a typical SMT 100. Root node 202 is illustrated in the FIG., along with leaf nodes 204 a-204 g, and branch nodes 206 a-206 b are intermediate to the root node 202 and the leaf nodes 204 a-204 g);; and determining the attack probability from the probability series (¶0039 see goal of the system call modeling method is to be able to determine whether a short subsequence of system calls corresponds to a normal execution path or to an exploit execution path)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the intrusion detection of Kabra and the teachings of Eskin for traversing a plurality of nodes to combine the teachings such that Kabra utilizes the teachings of Eskin for detecting intrusions. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will provide a technique which is not limited to a fixed window size for analyzing sequential behavior and which provides the ability to detect intrusions in the operation of the computer system (Eskin ¶0012).
Regarding claims 6, 14. The already combined references teach the method of claim 5, further comprising:
Kabra does not explicitly teach calculating a set of sliding window probabilities from the probability series; and calculating a minimum probability of the set of sliding window probabilities, wherein the minimum probability is the attack probability
Eskin however in the same field of computer networking teaches calculating a set of sliding window probabilities from the probability series (¶0036 see stage of training a predictive model (step 12) includes determining an optimal window size. According to the exemplary embodiment, the window sizing is variable and context dependent. The motivation for a context dependency of the window size is derived from the underlying mechanism of how a process executes. As is known in the art, a system call trace is a sequence of all of the system calls that a process of a given program makes during its lifetime. The system calls in the trace depend on the execution path of the process ¶0007 see basic units of the modeling technique are short contiguous subsequences obtained with a sliding window); and calculating a minimum probability of the set of sliding window probabilities, wherein the minimum probability is the attack probability (¶0009 see short continuous subsequences are extracted with a sliding window, which refers to the number of system calls being analyzed. Traditionally, system call modeling methods employ a fixed window size, i.e., a fixed number of system calls are analyzed ¶0035 see evaluating new sequence of system calls to determine whether or not they correspond to anomalies, e.g., intrusions or exploits, the predictive probability is determined for each subsequence at step 14. If the sequence probability is below a predetermined threshold (step 16), then the sequence of system calls being evaluated is unlikely to have originated from a normal process and the process trace is declared an exploit or attack (step 18). If the sequence probability is above the threshold, the sequence of system calls is considered normal operation (step 20)).
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the intrusion detection of Kabra and the teachings of Eskin for calculating a set of sliding window probabilities to combine the teachings such that Kabra utilizes the teachings of Eskin for detecting intrusions. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will provide a technique which is not limited to a fixed window size for analyzing sequential behavior and which provides the ability to detect intrusions in the operation of the computer system (Eskin ¶0012).
Regarding claims 9, 17. The already combined references teach the method of claim 1, wherein the system call trace only identifies system calls (Kabra Col 1 lines 40-48 see guest software application accesses an Application Programming Interface (API), which invokes a system call function (sometimes referred to as a “syscall”) operating within the guest kernel).
Regarding claims 10, 18. The already combined references teach the method of claim 1, wherein extracting the system call trace comprises extracting a system call metadata of system calls between the start delimiter and an end delimiter and having a same thread identifier as the start delimiter (Kabra Col 3 lines 46-60 see enabling the exploit detection logic to access the metadata that may include some or all of the context. The context is the original state of the application prior to the trap and is preserved during re-direction to the exploit detection logic. Some of the context may be accessed dependent on the exploit detection intelligence. The exploit detection logic analyzes metadata, inclusive of at least some of the context information associated with the hooked syscall).
Conclusion
References are cited not only for their quoted language but for all that they teach.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Atta Khan whose telephone number is 571-270-7364. The examiner can normally be reached on M-F 09:00-6:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ATTA KHAN/
Examiner, Art Unit 2449
Prosecution Insights