Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 102:
Applicant’s arguments, filed 02/23/2026, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Martynenko et al. (US 20130326626 A1, referred to as Martynenko).
DETAILED ACTION
This is a reply to the arguments filed on 02/23/2026, in which, claims 1-20 are pending. Claims 1, 9, and 17 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Drawings
The drawings filed on 06/26/2024 are accepted
Specification
The disclosure filed on 05/09/2022 is accepted
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 08/20/2024 and 10/01/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-20 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Breitenbacher et al. (“HADES-IoT: A Practical and Effective Host-Based Anomaly Detection System for IoT Devices (Extended Version)”, referred to as Breitenbacher) disclosed in the IDS filed 8/20/24 in further view of Martynenko et al. (US 20130326626 A1, referred to as Martynenko).
In reference to claim 1, A method for monitoring a process, the method comprising: receiving a system call associated with a process (Breitenbacher: Section IV A - Section V B Provides for a method that monitors processes by receiving system calls (specifically execve) associated with processes.)
In a modified system call table of an operating system, identifying (i) a modified handler corresponding to the received system call and (ii) an original handler corresponding to the received system call (Breitenbacher: Section V-B Provides for modifying the system call table by saving the original address for execve (the original handler) and replacing it with the address of the intercepting function (the modified handler).)
(i) analyzing validity of the process using the modified handler and the system call and (ii) servicing the system call using the original handler (Breitenbacher: Section V-B Provides for analyzing the validity of a process using the modified handler (intercepting function) by checking if it's in the whitelist. If valid, it then services the call using the original handler by calling "the original execve system call.")
Maintaining or stopping the servicing of the system call based on the analyzing (Breitenbacher: Section V-B Provides for maintaining the system call service (by calling the original execve) when the process is valid, or stopping/terminating the process (by returning an error code) when it's invalid.)
Breitenbacher doesnt explicitly teach the analyzing and servicing step as being in parallel. However, Martynenko discloses:
Wherein the analyzing and servicing step is in parallel (Martynenko: [0035]-[0038] and Fig. 3 Provides for parallel/concurrent operation, a copy of the event is queued for malware analysis while the original event is simultaneously released for normal servicing.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Breitenbacher, which provides a method for monitoring processes by intercepting system calls through a modified system call table and either maintaining or stopping service based on validity analysis, with the teachings of Martynenko, which introduces parallel processing where system call analysis and servicing occur simultaneously through concurrent event queuing. One of ordinary skill in the art would recognize the ability to incorporate Martynenko's parallel processing approach into Breitenbacher's system call monitoring framework to eliminate sequential processing delays. One of ordinary skill in the art would be motivated to make this modification in order to significantly reduce system performance overhead by allowing normal system call servicing to proceed concurrently with security analysis rather than waiting for analysis to complete before servicing.
In reference to claim 2, The method of claim 1 wherein the received system call is: clone, fork, vfork, execve, or execveat (Breitenbacher: Section IV-A - Section V-B Provides for intercepting the execve system call as its primary method of operation. The paper also explicitly describes and discusses fork, vfork, and clone system calls in detail in the preliminaries section, showing knowledge of these system calls in the context of process creation and execution.)
In reference to claim 3, The method of claim 1 further comprising: creating the modified system call table (Breitenbacher: Section V-B Provides for modifying an existing system call table by replacing an entry (execve address) with a new address (intercepting function).)
In reference to claim 4, The method of claim 3 wherein creating the modified system call table comprises: for at least one system call in an original system call table of the operating system, adding an association, in memory, between a respective modified handler and the at least one system call (Breitenbacher: Section V-B Provides for a process of locating the original system call table, saving the original execve address, and then replacing that address with the address of the intercepting function. Creating an association in memory between the modified handler (intercepting function) and the system call (execve).)
In reference to claim 5, The method of claim 1 wherein the system call comprises at least one of: a filename, a command line argument, and a variable value (Breitenbacher: Section V-B Provides that the execve system call includes a parameter specifying the path of the program to be executed, which constitutes both a filename and a command line argument. The paper explicitly states that the intercepting function "reads the parameters passed to the execve system call" including "the path of the program to be executed.")
In reference to claim 6, The method of claim 5 wherein analyzing validity of the process using the modified handler and the system call comprises: determining validity of at least one of: the filename, the command line argument, and the variable value (Breitenbacher: Section V-B - Section V-C Provides for determining the validity of a filename (path) as part of its analysis process. HADES-IoT explicitly reads the path of the program to be executed from the execve system call, computes a hash from this path along with other data, and checks if this hash exists in the whitelist to determine validity.)
In reference to claim 7, The method claim 1 wherein maintaining or stopping servicing of the system call based on the analyzing comprises: responsive to the analyzing determining the process is valid, maintaining servicing of the system call; and responsive to the analyzing determining the process is invalid, implementing a protection action (Breitenbacher: Section V-B Provides for HADES-IoT determines a process is valid (matches the whitelist), it maintains service by calling the original execve system call. When it determines a process is invalid (not in the whitelist), it implements a protection action by returning an error code that terminates the process.)
In reference to claim 8, The method of claim 7 wherein the protection action is terminating the process (Breitenbacher: Section V-B Provides for process termination as its protection action when an invalid process is detected.)
In reference to claim 9, A system comprising: a processor; and a memory with computer code instructions stored thereon, the processor and the memory, with the computer code instructions, being configured to cause the system to: receive a system call associated with a process (Breitenbacher: Section IV A - Section V B Provides for a method that monitors processes by receiving system calls (specifically execve) associated with processes.)
in a modified system call table of an operating system, identify (i) a modified handler corresponding to the received system call and (ii) an original handler corresponding to the received system call (Breitenbacher: Section V-B Provides for modifying the system call table by saving the original address for execve (the original handler) and replacing it with the address of the intercepting function (the modified handler).)
(i) analyze validity of the process using the modified handler and the system call and (ii) service the system call using the original handler (Breitenbacher: Section V-B Provides for analyzing the validity of a process using the modified handler (intercepting function) by checking if it's in the whitelist. If valid, it then services the call using the original handler by calling "the original execve system call.")
maintain or stop the servicing of the system call based on the analyzing (Breitenbacher: Section V-B Provides for maintaining the system call service (by calling the original execve) when the process is valid, or stopping/terminating the process (by returning an error code) when it's invalid.)
Breitenbacher doesnt explicitly teach the analyzing and servicing step as being in parallel. However, Martynenko discloses:
Wherein the analyzing and servicing step is in parallel (Martynenko: [0035]-[0038] and Fig. 3 Provides for parallel/concurrent operation, a copy of the event is queued for malware analysis while the original event is simultaneously released for normal servicing.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Breitenbacher, which provides a method for monitoring processes by intercepting system calls through a modified system call table and either maintaining or stopping service based on validity analysis, with the teachings of Martynenko, which introduces parallel processing where system call analysis and servicing occur simultaneously through concurrent event queuing. One of ordinary skill in the art would recognize the ability to incorporate Martynenko's parallel processing approach into Breitenbacher's system call monitoring framework to eliminate sequential processing delays. One of ordinary skill in the art would be motivated to make this modification in order to significantly reduce system performance overhead by allowing normal system call servicing to proceed concurrently with security analysis rather than waiting for analysis to complete before servicing.
In reference to claim 10, The system of claim 9 wherein the received system call is: clone, fork, vfork, execve, or execveat (Breitenbacher: Section IV-A - Section V-B Provides for intercepting the execve system call as its primary method of operation. The paper also explicitly describes and discusses fork, vfork, and clone system calls in detail in the preliminaries section, showing knowledge of these system calls in the context of process creation and execution.)
In reference to claim 11, The system of claim 9 wherein the processor and the memory, with the computer code instructions, are further configured to cause the system to: create the modified system call table (Breitenbacher: Section V-B Provides for modifying an existing system call table by replacing an entry (execve address) with a new address (intercepting function).)
In reference to claim 12, The system of claim 11 wherein, in creating the modified system call table, the processor and the memory, with the computer code instructions, are configured to cause the system to: for at least one system call in an original system call table of the operating system, add an association, in memory, between a respective modified handler and the at least one system call (Breitenbacher: Section V-B Provides for a process of locating the original system call table, saving the original execve address, and then replacing that address with the address of the intercepting function. Creating an association in memory between the modified handler (intercepting function) and the system call (execve).)
In reference to claim 13, The system of claim 9 wherein the system call comprises at least one of: a filename, a command line argument, and a variable value (Breitenbacher: Section V-B Provides that the execve system call includes a parameter specifying the path of the program to be executed, which constitutes both a filename and a command line argument. The paper explicitly states that the intercepting function "reads the parameters passed to the execve system call" including "the path of the program to be executed.")
In reference to claim 14, The system of claim 13 wherein, in analyzing validity of the process using the modified handler and the system call, the processor and the memory, with the computer code instructions, are configured to cause the system to: determine validity of at least one of: the filename, the command line argument, and the variable value (Breitenbacher: Section V-B - Section V-C Provides for determining the validity of a filename (path) as part of its analysis process. HADES-IoT explicitly reads the path of the program to be executed from the execve system call, computes a hash from this path along with other data, and checks if this hash exists in the whitelist to determine validity.)
In reference to claim 15, The system of claim 9 wherein, in maintaining or stopping servicing of the system call based on the analyzing, the processor and the memory, with the computer code instructions, are configured to cause the system to: responsive to the analyzing determining the process is valid, maintain servicing of the system call; and responsive to the analyzing determining the process is invalid, implement a protection action (Breitenbacher: Section V-B Provides for HADES-IoT determines a process is valid (matches the whitelist), it maintains service by calling the original execve system call. When it determines a process is invalid (not in the whitelist), it implements a protection action by returning an error code that terminates the process.)
In reference to claim 16, The system of claim 15 wherein the protection action is terminating the process (Breitenbacher: Section V-B Provides for process termination as its protection action when an invalid process is detected.)
In reference to claim 17, A computer program product comprising: one or more non-transitory computer readable storage devices and program instructions stored on at least one of the one or more storage devices, the program instructions, when loaded and executed by a processor, cause an apparatus associated with the processor to: receive a system call associated with a process (Breitenbacher: Section IV A - Section V B Provides for a method that monitors processes by receiving system calls (specifically execve) associated with processes.)
in a modified system call table of an operating system, identify (i) a modified handler corresponding to the received system call and (ii) an original handler corresponding to the received system call (Breitenbacher: Section V-B Provides for modifying the system call table by saving the original address for execve (the original handler) and replacing it with the address of the intercepting function (the modified handler).)
(i) analyze validity of the process using the modified handler and the system call and (ii) service the system call using the original handler (Breitenbacher: Section V-B Provides for analyzing the validity of a process using the modified handler (intercepting function) by checking if it's in the whitelist. If valid, it then services the call using the original handler by calling "the original execve system call.")
maintain or stop the servicing of the system call based on the analyzing (Breitenbacher: Section V-B Provides for maintaining the system call service (by calling the original execve) when the process is valid, or stopping/terminating the process (by returning an error code) when it's invalid.)
Breitenbacher doesnt explicitly teach the analyzing and servicing step as being in parallel. However, Martynenko discloses:
Wherein the analyzing and servicing step is in parallel (Martynenko: [0035]-[0038] and Fig. 3 Provides for parallel/concurrent operation, a copy of the event is queued for malware analysis while the original event is simultaneously released for normal servicing.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Breitenbacher, which provides a method for monitoring processes by intercepting system calls through a modified system call table and either maintaining or stopping service based on validity analysis, with the teachings of Martynenko, which introduces parallel processing where system call analysis and servicing occur simultaneously through concurrent event queuing. One of ordinary skill in the art would recognize the ability to incorporate Martynenko's parallel processing approach into Breitenbacher's system call monitoring framework to eliminate sequential processing delays. One of ordinary skill in the art would be motivated to make this modification in order to significantly reduce system performance overhead by allowing normal system call servicing to proceed concurrently with security analysis rather than waiting for analysis to complete before servicing.
In reference to claim 18, The computer program product of claim 17 wherein the program instructions, when loaded and executed by the processor, cause the apparatus associated with the processor to: create the modified system call table by, for at least one system call in an original system call table of the operating system, adding an association, in memory, between a respective modified handler and the at least one system call (Breitenbacher: Section V-B Provides for a process of locating the original system call table, saving the original execve address, and then replacing that address with the address of the intercepting function. Creating an association in memory between the modified handler (intercepting function) and the system call (execve).)
In reference to claim 19, The computer program product of claim 17 wherein, in analyzing validity of the process using the modified handler and the system call, the program instructions, when loaded and executed by the processor, cause the apparatus associated with the processor to:
determine validity of at least one of: the filename, the command line argument, and the variable value (Breitenbacher: Section V-B Provides that the execve system call includes a parameter specifying the path of the program to be executed, which constitutes both a filename and a command line argument. The paper explicitly states that the intercepting function "reads the parameters passed to the execve system call" including "the path of the program to be executed.")
In reference to claim 20, The computer program product of claim 17 wherein, in maintaining or stopping servicing of the system call based on the analyzing, the program instructions, when loaded and executed by the processor, cause the apparatus associated with the processor to:responsive to the analyzing determining the process is valid, maintain servicing of the system call; and responsive to the analyzing determining the process is invalid, implement a protection action (Breitenbacher: Section V-B Provides for HADES-IoT determines a process is valid (matches the whitelist), it maintains service by calling the original execve system call. When it determines a process is invalid (not in the whitelist), it implements a protection action by returning an error code that terminates the process.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights