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 103:
Applicant’s arguments, filed 03/12/2026, in view of the amended claims, 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 Kane et al. (US 9411953 B1, referred to as Kane.) in further view of Vasilenko et al. (US 20170147819 A1, referred to as Vasilenko.)
DETAILED ACTION
This is a reply to the application filed on 03/12/2026, in which, claims 1, 2-11 and 13-20 are pending. Claims 1, and 10 are independent. Claims 2 and 12 are canceled.
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.
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-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kane et al. (US 9411953 B1, referred to as Kane.) in further view of Vasilenko et al. (US 20170147819 A1, referred to as Vasilenko.)
In reference to claim 1, A method of threat detection in a computer or computer network (Kane: Col. 1, lines 6-9 and Col. 8, lines 17-18 Provides for a method of threat/malware detection performed on a client computer.)
providing a analyzed environment with an initial thread and/or an initial process to be analyzed for malware the initial thread or the initial process having been previously created on a computer, on an application, or on a file (Kane: Col, 3 Lines 33-64 Provides for an analyzed environment containing initial processes/threads created from files on a computer.)
Monitoring, in the sandbox environment, attempts of the initial thread or the initial process to create remote threads in the sandbox environment (Kane:Col, 3 Lines 33-64 and Col. 5, lines 1-7 Provides for kernel-level monitoring of thread creation events (including remote thread injection) by initial processes.)
Detecting the monitored process creating a new thread in a process and creating a pair of processes and threads for the new thread and the second process and adding this pair to the list of monitored threads (Kane:Col. 5, lines 2-18 and Col. 6, lines 38-65 Provides for detecting thread-creation events and recording a pair/tuple of (creating process, created thread) into a maintained database/mapping.)
From the monitoring, identifying newly created remote thread(s) created by the initial thread or the initial process, the newly created remote thread(s) being created to another application or another process (Kane: Col. 3, lines 1-3; Col. 2, line 64 - Col. 3, lines 3 and Fig. 1 Provides for the precise scenario of identifying remote threads created by one process (BAD.EXE / initial process) into the address space of another process (LEGITIMATE.EXE).)
Assigning a thread identification to each identified newly created remote thread (Kane: Col, 5 lines 1 - 18 Provides for assignment of a unique thread identifier (TID) to each created thread.)
Using the thread identification(s), adding the identified newly created remote thread(s) to a list of monitored threads (Kane: Col. 5, lines 7-19 and Col. 8, lines 21-26 Provides for using the thread ID as the indexing key to enter the thread into a maintained mapping/database.)
monitoring the remote threads on the list of the monitored threads to observe malicious activity (Kane: Col. 5, lines 18-32; Col. 5, lines 42-58 and Col. 6, lines 60-65 Provides for analyzing the listed/enumerated threads (including injected remote threads) to detect malicious indicators.)
Based on an observation of malicious activity activity by the monitored remote threads, identifying the initial thread of the initial process as malicious or suspicious and proving a malware analysis result of the initial thread as malicious or suspicious based (Kane: Col. 6, lines 4-19 and Col. 7, lines 26-35 Provides for using the malicious-activity observation in the injected (remote) thread to trace back and identify the original/initial process and file as malicious.)
taking an action for protecting the computer, the application, or the file, on which the initial thread or the initial process was created on, from the initial thread or the initial process identified as being malicious or suspicious (Kane: Col. 6, lines 20-31 and Col. 4, lines 1-7 Provides for explicit protective actions (quarantine, deletion, blocking, reporting) taken against the identified malicious file/process on the computer.)
Kane does not explicitly teach that the analyzed environment is a sandbox environment, However Vasilenko discloses:
Wherein the analzyed environment is a sandbox environment (Vasilenko: [0004] and [0042]-[0049] Provides for explicit protective actions (blocking execution of the malicious event on the target, isolating the infected system from the network, and alerting administrators).)
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 Kane, which provides a method for detecting malware through monitoring thread creation, tracking remote thread injection, and identifying malicious processes based on their thread behavior, with the teachings of Vasilenko, which introduces using a sandbox environment as the isolated execution space for malware analysis. One of ordinary skill in the art would recognize the ability to incorporate Vasilenko's sandbox isolation into Kane's thread monitoring system to provide safer malware analysis. One of ordinary skill in the art would be motivated to make this modification in order to protect production systems by containing potentially malicious processes within an isolated sandbox environment.
In reference to claim 3, The method of claim 1, wherein the method further comprises monitoring process identifications and thread identifications, and/or following file input-output, registry input-output, thread creations and/or process creations made on behalf of the monitored threads and/or the created pairs (Vasilenko: [0024], [0035]-[0041] and [0061]-[0064] Provides for monitoring/following all of the enumerated behaviors (file I/O (file creation/modification/access), registry I/O (modification to OS registry), and thread/process creation (execution of a program within a pre-existing process, injection of a thread from one process into another)).)
In reference to claim 4, The method according to claim 1, wherein the monitoring starts from a thread or process and comprises following succeeding process and/or thread creations (Kane: Col. 3, lines 37-42; Col. 5, lines 1-19 and Col. 6, lines 39-55 Provides for continuous, background, kernel-hooked monitoring that begins with processes/threads on the client and follows each succeeding thread-creation event as it occurs.)
In reference to claim 5, The method according to claim 1, wherein if another application performs an activity not from the process identification and thread identification pair, that process and/or thread is determined to belong to the other application and is ignored (Vasilenko: [0041]-[0046] Provides for the general concept of ignoring/filtering out activity attributed to known/whitelisted applications or activity confined to an application's own file-type/directory scope.)
In reference to claim 6, The method according to claim 1, wherein the threads are identified with a thread identification information and/or processes are identified with a process identification information (Kane: Col. 5, lines 1-2; Col. 5, lines 15-19 and Col. 8, lines 42-47 Provides for OS-assigned unique identifiers for both threads (TIDs) and processes (PIDs) used throughout Kane's tracking and lookup operations.)
In reference to claim 7, The method according to claim 1, wherein if the monitored application creates a new worker thread, the new worker thread is added to the list of monitored threads (Kane: Col. 3, lines 37-42; Col. 5, lines 1-19 and Col. 6, lines 39-55 Provides for detecting each thread creation event by a monitored process and adding the newly created thread (along with its creator) into the maintained mapping/database.)
In reference to claim 8, The method according to claim 1, wherein the sandbox environment is an environment which permits an application to run in an environment in which access to local host is restricted and/or the changes to the system are reversable (Vasilenko: [0031]-[0047] and [0063] Provides for a hypervisor-based sandbox (shadow sandbox/shadow platform) that is a controlled, isolated VM testbed where the risk event is executed and evaluated separately from the protected host.)
In reference to claim 9, The method according to claim 1, wherein a malware file or application is a file or an application which writes an executable payload into memory of another application or shared memory and schedules a thread to run under the other application (Kane: Col. 1, lines 33-38; Col. 2, lines 55-67 to Col. 3, lines 1-3 and Fig. 1 Provides for a malware file (BAD.EXE) that writes/unpacks an executable payload (unpacked malicious code 104) into the memory of another application (LEGITIMATE.EXE's address space) and schedules a remote thread (thread 108) to run under the other application.)
In reference to claim 10, An arrangement for threat detection in a computer or computer network, wherein the arrangement comprises at least one computer, wherein the computer is configured: to provide a thread and/or process to be analyzed for malware to a sandbox environment (Kane: Col. 1, lines 6-9 and Col. 8, lines 17-18 Provides for a method of threat/malware detection performed on a client computer.)
To provide an analyzed environment with an initial thread and/or an initial process to be analyzed for malware the initial thread or the initial process having been previously created on a computer, on an application, or on a file (Kane: Col, 3 Lines 33-64 Provides for an analyzed environment containing initial processes/threads created from files on a computer.)
To monitor, in the sandbox environment, attempts of the initial thread or the initial process to create remote threads in the sandbox environment (Kane:Col, 3 Lines 33-64 and Col. 5, lines 1-7 Provides for kernel-level monitoring of thread creation events (including remote thread injection) by initial processes.)
To detect the monitored process creating a new thread in a process and creating a pair of processes and threads for the new thread and the second process and adding this pair to the list of monitored threads (Kane:Col. 5, lines 2-18 and Col. 6, lines 38-65 Provides for detecting thread-creation events and recording a pair/tuple of (creating process, created thread) into a maintained database/mapping.)
From the monitoring, identifying newly created remote thread(s) created by the initial thread or the initial process, the newly created remote thread(s) being created to another application or another process (Kane: Col. 3, lines 1-3; Col. 2, line 64 - Col. 3, lines 3 and Fig. 1 Provides for the precise scenario of identifying remote threads created by one process (BAD.EXE / initial process) into the address space of another process (LEGITIMATE.EXE).)
To assign a thread identification to each identified newly created remote thread (Kane: Col, 5 lines 1 - 18 Provides for assignment of a unique thread identifier (TID) to each created thread.)
To use the thread identification(s), adding the identified newly created remote thread(s) to a list of monitored threads (Kane: Col. 5, lines 7-19 and Col. 8, lines 21-26 Provides for using the thread ID as the indexing key to enter the thread into a maintained mapping/database.)
To monitor the remote threads on the list of the monitored threads to observe malicious activity (Kane: Col. 5, lines 18-32; Col. 5, lines 42-58 and Col. 6, lines 60-65 Provides for analyzing the listed/enumerated threads (including injected remote threads) to detect malicious indicators.)
Based on an observation of malicious activity activity by the monitored remote threads, identifying the initial thread of the initial process as malicious or suspicious and proving a malware analysis result of the initial thread as malicious or suspicious based (Kane: Col. 6, lines 4-19 and Col. 7, lines 26-35 Provides for using the malicious-activity observation in the injected (remote) thread to trace back and identify the original/initial process and file as malicious.)
To take an action for protecting the computer, the application, or the file, on which the initial thread or the initial process was created on, from the initial thread or the initial process identified as being malicious or suspicious (Kane: Col. 6, lines 20-31 and Col. 4, lines 1-7 Provides for explicit protective actions (quarantine, deletion, blocking, reporting) taken against the identified malicious file/process on the computer.)
Kane does not explicitly teach that the analyzed environment is a sandbox environment, However Vasilenko discloses:
Wherein the analzyed environment is a sandbox environment (Vasilenko: [0004] and [0042]-[0049] Provides for explicit protective actions (blocking execution of the malicious event on the target, isolating the infected system from the network, and alerting administrators).)
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 Kane, which provides a method for detecting malware through monitoring thread creation, tracking remote thread injection, and identifying malicious processes based on their thread behavior, with the teachings of Vasilenko, which introduces using a sandbox environment as the isolated execution space for malware analysis. One of ordinary skill in the art would recognize the ability to incorporate Vasilenko's sandbox isolation into Kane's thread monitoring system to provide safer malware analysis. One of ordinary skill in the art would be motivated to make this modification in order to protect production systems by containing potentially malicious processes within an isolated sandbox environment.
In reference to claim 11, An arrangement for threat detection in a computer or computer network, wherein the arrangement comprises at least one computer, wherein the computer is configured: to provide a thread and/or process to be analyzed for malware to a sandbox environment (Kane: Col. 1, lines 6-9 and Col. 8, lines 17-18 Provides for a method of threat/malware detection performed on a client computer.)
To provide an analyzed environment with an initial thread and/or an initial process to be analyzed for malware the initial thread or the initial process having been previously created on a computer, on an application, or on a file (Kane: Col, 3 Lines 33-64 Provides for an analyzed environment containing initial processes/threads created from files on a computer.)
To monitor, in the sandbox environment, attempts of the initial thread or the initial process to create remote threads in the sandbox environment (Kane:Col, 3 Lines 33-64 and Col. 5, lines 1-7 Provides for kernel-level monitoring of thread creation events (including remote thread injection) by initial processes.)
To detect the monitored process creating a new thread in a process and creating a pair of processes and threads for the new thread and the second process and adding this pair to the list of monitored threads (Kane:Col. 5, lines 2-18 and Col. 6, lines 38-65 Provides for detecting thread-creation events and recording a pair/tuple of (creating process, created thread) into a maintained database/mapping.)
From the monitoring, identifying newly created remote thread(s) created by the initial thread or the initial process, the newly created remote thread(s) being created to another application or another process (Kane: Col. 3, lines 1-3; Col. 2, line 64 - Col. 3, lines 3 and Fig. 1 Provides for the precise scenario of identifying remote threads created by one process (BAD.EXE / initial process) into the address space of another process (LEGITIMATE.EXE).)
To assign a thread identification to each identified newly created remote thread (Kane: Col, 5 lines 1 - 18 Provides for assignment of a unique thread identifier (TID) to each created thread.)
To use the thread identification(s), adding the identified newly created remote thread(s) to a list of monitored threads (Kane: Col. 5, lines 7-19 and Col. 8, lines 21-26 Provides for using the thread ID as the indexing key to enter the thread into a maintained mapping/database.)
To monitor the remote threads on the list of the monitored threads to observe malicious activity (Kane: Col. 5, lines 18-32; Col. 5, lines 42-58 and Col. 6, lines 60-65 Provides for analyzing the listed/enumerated threads (including injected remote threads) to detect malicious indicators.)
Based on an observation of malicious activity activity by the monitored remote threads, identifying the initial thread of the initial process as malicious or suspicious and proving a malware analysis result of the initial thread as malicious or suspicious based (Kane: Col. 6, lines 4-19 and Col. 7, lines 26-35 Provides for using the malicious-activity observation in the injected (remote) thread to trace back and identify the original/initial process and file as malicious.)
To take an action for protecting the computer, the application, or the file, on which the initial thread or the initial process was created on, from the initial thread or the initial process identified as being malicious or suspicious wherein the arrangement is configured to carry out a method according to claim 1 (Kane: Col. 6, lines 20-31 and Col. 4, lines 1-7 Provides for explicit protective actions (quarantine, deletion, blocking, reporting) taken against the identified malicious file/process on the computer.)
Kane does not explicitly teach that the analyzed environment is a sandbox environment, However Vasilenko discloses:
Wherein the analzyed environment is a sandbox environment (Vasilenko: [0004] and [0042]-[0049] Provides for explicit protective actions (blocking execution of the malicious event on the target, isolating the infected system from the network, and alerting administrators).)
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 Kane, which provides a method for detecting malware through monitoring thread creation, tracking remote thread injection, and identifying malicious processes based on their thread behavior, with the teachings of Vasilenko, which introduces using a sandbox environment as the isolated execution space for malware analysis. One of ordinary skill in the art would recognize the ability to incorporate Vasilenko's sandbox isolation into Kane's thread monitoring system to provide safer malware analysis. One of ordinary skill in the art would be motivated to make this modification in order to protect production systems by containing potentially malicious processes within an isolated sandbox environment.
In reference to claim 13, A computer-readable medium on which is stored a computer program that, when executed by a computer, causes the computer to carry out the method of claim 1 (Kane: Col. 3, lines 37-42; Col. 5, lines 1-19 and Col. 6, lines 39-55 Provides for continuous, background, kernel-hooked monitoring that begins with processes/threads on the client and follows each succeeding thread-creation event as it occurs.)
In reference to claim 14, The method according to claim 2, wherein the monitoring starts from a thread or process and comprises following succeeding process and/or thread creations (Kane: Col. 3, lines 37-42; Col. 5, lines 1-19 and Col. 6, lines 39-55 Provides for continuous, background, kernel-hooked monitoring that begins with processes/threads on the client and follows each succeeding thread-creation event as it occurs.)
In reference to claim 15, The method according to claim 3, wherein the monitoring starts from a thread or process and comprises following succeeding process and/or thread creations (Kane: Col. 3, lines 37-42; Col. 5, lines 1-19 and Col. 6, lines 39-55 Provides for continuous, background, kernel-hooked monitoring that begins with processes/threads on the client and follows each succeeding thread-creation event as it occurs.)
In reference to claim 16, The method according to claim 2, wherein if another application performs an activity not from the process identification and thread identification pair, that process and/or thread is determined to belong to the other application and is ignored (Vasilenko: [0041]-[0046] Provides for the general concept of ignoring/filtering out activity attributed to known/whitelisted applications or activity confined to an application's own file-type/directory scope.)
In reference to claim 17, The method according to claim 3, wherein if another application performs an activity not from the process identification and thread identification pair, that process and/or thread is determined to belong to the other application and is ignored (Vasilenko: [0041]-[0046] Provides for the general concept of ignoring/filtering out activity attributed to known/whitelisted applications or activity confined to an application's own file-type/directory scope.)
In reference to claim 18, The method according to claim 4, wherein if another application performs an activity not from the process identification and thread identification pair, that process and/or thread is determined to belong to the other application and is ignored (Vasilenko: [0041]-[0046] Provides for the general concept of ignoring/filtering out activity attributed to known/whitelisted applications or activity confined to an application's own file-type/directory scope.)
In reference to claim 19, The method according to claim 2, wherein the threads are identified with a thread identification information and/or processes are identified with a process identification information (Kane: Col. 5, lines 1-2; Col. 5, lines 15-19 and Col. 8, lines 42-47 Provides for OS-assigned unique identifiers for both threads (TIDs) and processes (PIDs) used throughout Kane's tracking and lookup operations.)
In reference to claim 20, The method according to claim 3, wherein the threads are identified with a thread identification information and/or processes are identified with a process identification information (Kane: Col. 5, lines 1-2; Col. 5, lines 15-19 and Col. 8, lines 42-47 Provides for OS-assigned unique identifiers for both threads (TIDs) and processes (PIDs) used throughout Kane's tracking and lookup operations.)
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