Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the claims filed 6/28/2024. Claims 1-20 are pending. Claims 1 (a method), 9 (a machine), and 15 (a non-transitory CRM).
Examiner Comment
In the parent application U.S. App. No. 16/995,924, now U.S. Pat. No. 12,056,239, the claims were directed to detecting thread pattern variations in both “system level thread patterns” and “network level thread patterns”. The process steps performed in detecting said variations are the same. In the present claims, “system level thread patterns” have been removed and the claims are directed solely to “network level thread patterns”; however, the steps of detecting said variations are the same.
Thus, in the presently presented claims, the terms “network level thread patterns” and “system level thread patterns” are viewed as analogous since there is no distinction therebetween.
Response to Arguments
Due to the Terminal Disclaimer filed 1/21/2026 the double patenting rejection has been withdrawn.
Applicant's arguments filed 1/21/2026 have been fully considered but they are not persuasive.
In the remarks filed 1/21/2026, pages 15 and 16, Applicant asserts that the combination of Cochin and Wintergerst (US 2017/0093897 and 2015/0033205, respectively) does not disclose the claim term “network level thread pattern variation”. This argument is not persuasive.
Cochin discloses detecting thread pattern variations (Cochin ¶ 89) where the system of Cochin resides in a network (e.g. Cochin Fig. 4). Thus, Cochin discloses “network level thread pattern variation”. While Applicant’s specification discloses further definitional description of network level thread patterns (as filed ¶ 79), such definitions are not included in the claims as presented and need not be shown by the prior art to anticipate or render obvious the presented claims.
For at least the above reasons, Applicant’s remarks are not persuasive.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 6, 7, 9, 10, 12, 13, 15, 16, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cochin et al., US 2017/0093897 (filed 2015), in view of Wintergerst et al., US 2015/0033205 (published 2015).
As to claims 1, 9, and 15, Cochin discloses a method/machine/CRM comprising:
(“At Step 710, the central device that will be performing the application phenotype processing may begin by loading the “normal” behaviors associated with a particular application (e.g., those behaviors identified by method 600 of FIG. 6)” Cochin ¶ 91)
capturing, by a processor of a first device of a plurality of devices (“the method 700 may be performed by any number of central devices, e.g., a home gateway device, a Windows (or other OS) client device, and/or in the cloud by a network-accessible server.” Cochin ¶ 91, see Figure 1 and ¶ 80, various devices may perform the analysis.), context information for each thread of a plurality of threads executing on the processor, each device of the plurality of devices executing … (“At Step 610, entities of an electronic device to be monitored may be determined. Such entities may include, for example, kernel space, user space, an SSDT, an operating system call dispatcher, system DLLs, user DLLs, processes, I/O ports, heaps, threads, or a system stack.” Cochin ¶ 89)
wherein the context information identifies a stored thread pattern of a plurality of stored thread patterns … (“FIG. 6 is a flowchart illustrating a technique 600 for building application phenotypes, according to one embodiment. At Step 610, entities of an electronic device to be monitored may be determined. Such entities may include, for example, kernel space, user space, an SSDT, an operating system call dispatcher, system DLLs, user DLLs, processes, I/O ports, heaps, threads, or a system stack.” Cochin ¶ 89)
each stored thread pattern comprising information defining one or more known patterns for thread execution based on previous execution of one or more threads; (“at Step 670, one or more behaviors may be associated with the “normal” operations of an application, i.e., an application's phenotype.” Cochin ¶ 89)
comparing, by the processor of the first device, the thread pattern for each thread executing on the processor (“At Step 720, the central device may begin to monitor the live operations taking place on the monitored device (e.g., using the techniques outlined with reference to FIG. 2 and FIG. 6)” Cochin ¶ 91) to the stored thread pattern identified by the captured context information for each thread executing on the processor; (“At Step 750, it may be determined by the central device whether the determined application phenotype from Step 730 contains all normal behaviors for the respective application.” Cochin ¶ 91)
detecting, by the processor of the first device, a network level thread pattern variation for threads (
“As microsteps are discovered “in the wild” by a given end point in the event streams from all the monitored applications, there may end up being a large number of “unknown” microsteps. These unknown microsteps could either by an indication of something malicious, or they could simply indicate that, in the wild, there is software that is doing completely benign—but very ‘different’—behavior. ” Cochin ¶ 81
“Periodically, end points could upload all its microstep detection data, along with metrics, to indicate usefulness of this approach and how the device is performing.” Cochin ¶ 81. See also Cochin ¶ 91, see Figure 1 and ¶ 80, various devices may perform the analysis.) based on the comparing of the thread pattern for each thread of the plurality of threads to the stored thread patterns; (“If, instead, there are monitored behaviors monitored that are not “normal” to the application (or any other trusted application), or, indeed, if there are monitored behaviors that affirmatively match (within a threshold level) the behaviors of a known malware application, the process may proceed to Step 770 to indicate a possible malware process has been identified and then optionally act on the detected malware process at Step 780.” Cochin ¶ 91.
“Such unusual or unexpected patterns of operation may reflect a new, unknown kind of malware.” Cochin ¶ 73. “First, security cloud 410 represents the aforementioned central device for aggregating and parsing the monitored event data from the end points monitored by the malware detection system. Security cloud 410 may comprise a “Big Data” engine 422, which in turn may comprise an event store 426 for storing all of the monitored events and microsteps observed at the monitored end points and event processor 424 for attempting to parse and glean useful information from the captured event data, e.g., the determination of existing microsteps/behaviors/phenotypes and/or the discovery of new microsteps/behaviors/phenotypes in the collected data. Once the Big Data engine 422 has determined or discovered new microsteps/behaviors/phenotypes, they may be stored in microstep patterns database 428 and pushed/pulled to and from end points via API edge 430.” Cochin ¶ 78).
determining, by the processor of the first device, whether the detected network level thread pattern variation (Cochin ¶ 91. Cochin ¶ 79 utilizing the new microsteps of Cochin ¶ 78) indicate presence of malware; and (“the process may proceed to Step 770 to indicate a possible malware process has been identified and then optionally act on the detected malware process at Step 780.” Cochin ¶ 91)
performing, by the processor of the first device, one or more actions based on determining the detected network level thread pattern variation indicates the presence of malware. (“and then optionally act on the detected malware process at Step 780.” Cochin ¶ 91)
(claims 9 and 15 further require)
wherein performing one or more actions based on determining the detected thread pattern variation indicates the presence of malware comprises one or more of:
quarantining a thread having a detected thread pattern variation;
blocking a thread having a detected thread pattern variation from accessing resources;
flagging a thread having a detected thread pattern variation; or
providing thread pattern variation identification information.
(“Upon determining that one or more transitions are indicative of malware, anti-malware module 110 may be configured to take any suitable corrective action. For example, the entities in memory 104 associated with the transitions indicating malware may be quarantined, reported, removed, cleaned, or otherwise handled.” Cochin ¶ 67).
Cochin does not explicitly disclose:
A distributed application
The distributed application
Wintergerst discloses:
A distributed application
The distributed application
(“a particular backend server may be associated with the execution of two or more network applications (and other related components), as well as one or more distributed applications executing across two or more servers” Wintergerst ¶ 51. “FIG. 7 illustrates an exemplary network environment 700 for providing a remote debugging of a cloud application 507, 507a across a wide area network.” Wintergerst ¶ 92. “FIGS. 4A-4B illustrate an exemplary message flow between the debugger and the debuggee using JDWP. In case of a communication channel with a latency of 50-200 ms between the debuggee and the debugger, this may result in high pause times in the debugger. Debugging becomes impossible. The waiting times may thus be extremely high so that an interactive debugging session cannot be performed. For example, in case of 500 threads (typical value), 500 times 10=5000 thread messages may occur.” Wintergerst ¶ 56)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cochin with Wintergerst by providing for monitoring of at least one server hosting a distributed application, as shown in Wintergerst. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cochin with Wintergerst in order to provide the ability to monitor an application executing on more than one terminal, thereby providing the malware detection benefits of Cochin on programs that necessarily execute on multiple computers, i.e. those of Wintergerst.
As to claims 2, 10, 16, Cochin in view of Wintergerst discloses the method/machine/CRM of claims 1, 9, 15 and further discloses:
wherein the context information comprises one or more of:
thread execution time;
time between successive executions of two or more threads;
time between successive executions of the same thread;
file access by the thread; (see Cochin Fig. 2 open file dialog box)
Input/Output (I/O) access by the thread; (see Cochin Fig. 2 open file dialog box)
keyboard tracking by the thread;
network traffic related to the thread; (See Cochin Fig. 2 send encrypted data)
ports used by the thread; (“Such entities may include, for example, kernel space, user space, an SSDT, an operating system call dispatcher, system DLLs, user DLLs, processes, I/O ports, heaps, threads, or a system stack” Cochin ¶ 89)
destination addresses used by the thread;
system Application Program Interface (API) usage by the thread; (“the microstep may also take into consideration whether the sequence of operations were executed in response to an API call made to a particular program or library.” Cochin ¶ 72)
copy of data to other devices performed by the thread;
stack information of the thread upon instantiation of the thread;
stack variables of the thread; or (Cochin ¶ 89)
stack information of the thread upon exit of the thread.
(alternatives not required)
As to claims 4, 12, 18 Cochin in view of Wintergerst discloses the method/machine/CRM of claims 1, 9, 15 and further discloses:
wherein the detected network level thread pattern variation comprises one or more of: a new thread pattern;
a new type of API call; a type of API call associated with malware; a new sequence of API calls; (“individual operations (or sequence of APIs) may be aggregated into microsteps, i.e., a high-level description of the intent of the combined operations.” Cochin ¶ 29. “If, instead, there are monitored behaviors monitored that are not “normal” to the application (or any other trusted application), or, indeed, if there are monitored behaviors that affirmatively match (within a threshold level) the behaviors of a known malware application, the process may proceed to Step 770 to indicate a possible malware process has been identified and then optionally act on the detected malware process at Step 780.” Cochin ¶ 91)
a change in an order of two or more threads; a missing thread; two or more threads previously executing in series now executing in parallel; two or more threads previously executing in parallel now executing in series; a change in an amount of time for a thread to execute; a change in an amount of time between executions of a thread; a change in thread priority for a thread; a thread that does not occur within a defined time period; a missing thread that is spun from an existing thread; a new thread that is spun from an existing thread; a missing thread that was previously identified as needed; a thread that does not occur at a predefined period; a thread that does not occur in response to an event associated with the thread; or a number of thread occurrences that exceeds a predefined threshold.
(alternatives not required)
As to claims 6, 13, 19, Cochin in view of Wintergerst discloses the method/machine/CRM of claims 1, 9, 15 and further discloses:
Detecting the network level thread pattern variation further comprises one or more of: in response to detecting a thread pattern variation on a first device of the plurality of devices, sending information identifying the thread pattern variation from the first device to a second device of the plurality of devices and determining by the second device if a same thread pattern variation is detected on the second device;
comparing the thread pattern for each thread to stored thread patterns for for a distributed application executing across the plurality of devices; or
(alternatives not required)
comparing the thread pattern for a new thread on a first device of the plurality of devices to stored (“The data from the event trimmer 408 may then be sent to the microstep finder 410, e.g., employing the malware-microstep rule logic 108 to see if any known microsteps may be located in the event data.” Cochin ¶ 79) thread patterns for the same thread previously executed on a second device of the plurality of devices. (“First, security cloud 410 represents the aforementioned central device for aggregating and parsing the monitored event data from the end points monitored by the malware detection system. Security cloud 410 may comprise a “Big Data” engine 422, which in turn may comprise an event store 426 for storing all of the monitored events and microsteps observed at the monitored end points and event processor 424 for attempting to parse and glean useful information from the captured event data, e.g., the determination of existing microsteps/behaviors/phenotypes and/or the discovery of new microsteps/behaviors/phenotypes in the collected data. Once the Big Data engine 422 has determined or discovered new microsteps/behaviors/phenotypes, they may be stored in microstep patterns database 428 and pushed/pulled to and from end points via API edge 430.” Cochin ¶ 78).
As to claim 7 Cochin in view of Wintergerst discloses the method of claim 1 and further discloses:
wherein performing one or more actions based on determining the detected thread pattern variation indicates the presence of malware comprises one or more of:
quarantining a thread having a detected thread pattern variation;
blocking a thread having a detected thread pattern variation from accessing resources;
flagging a thread having a detected thread pattern variation; or
providing thread pattern variation identification information.
(“Upon determining that one or more transitions are indicative of malware, anti-malware module 110 may be configured to take any suitable corrective action. For example, the entities in memory 104 associated with the transitions indicating malware may be quarantined, reported, removed, cleaned, or otherwise handled.” Cochin ¶ 67).
Claim(s) 3, 5, 11, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cochin et al., US 2017/0093897 (filed 2015), in view of Wintergerst et al., US 2015/0033205 (published 2015), and Tumblin, US 2019/0213323 (filed 2019-01).
As to claim 3, Cochin in view of Wintergerst discloses the method of claim 1 and further discloses:
wherein comparing the thread pattern for at least one thread executing on the processor to the stored thread pattern identified by the captured context information for the at least one thread comprises comparing a thread pattern from a current execution of the thread to a previous execution of the same thread and wherein the detected network level thread pattern variation comprises one or more of: (“At Step 750, it may be determined by the central device whether the determined application phenotype from Step 730 contains all normal behaviors for the respective application.” Cochin ¶ 91)
Cochin does not disclose:
a change in a size of a stack for the thread;
a change in data in the stack for the thread;
a change in a size of a heap for the thread;
a change in data in the heap for the thread; or
a change in a size of code for the thread.
Tumblin discloses:
a change (“scans may be performed at random intervals that are unknown to the heap spray attacker. Accordingly, the heap spray attack is less able to plan for scans and undermine the heap spray attack countermeasures described herein.” Tumblin ¶ 26) in data in the heap for the thread; or (“at 305 the computer system may detect a heap spray attack in the scanned memory sections by looking at the scanned memory sections to see if the scanned memory sections contain no-ops patterns that are associated with heap spray attacks. No-ops patterns that are associated with heap spray attacks may be pre-configured or stored in a scanning module such as scanning module 129. The pre-configured no-ops patterns may be downloaded from a central server, and may include patterns that are computer architecture (e.g., Intel, ARM) specific. …. no-ops patterns may be generated using machine learning techniques that analyze prior no-ops patterns and behavior of a single computer, across an enterprise or across multiple enterprises.” Tumblin ¶ 27).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cochin in view of Wintergerst with Tumblin by including heap spray attacks as one of the scanned behaviors of Cochin. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cochin in view of Wintergerst with Tumblin in order to detect transfer of control attacks by malware, Tumblin ¶ 4, thereby helping to prevent malicious process execution.
As to claims 5, Cochin in view of Wintergerst and Tumblin discloses the method of claim 3 and further discloses:
wherein determining whether the detected network level thread pattern variation indicates presence of malware further comprises one or more of:
comparing system API usage for a thread having a detected thread pattern variation to previous system API usage for the thread; (“individual operations (or sequence of APIs) may be aggregated into microsteps, i.e., a high-level description of the intent of the combined operations.” Cochin ¶ 29. “If, instead, there are monitored behaviors monitored that are not “normal” to the application (or any other trusted application), or, indeed, if there are monitored behaviors that affirmatively match (within a threshold level) the behaviors of a known malware application, the process may proceed to Step 770 to indicate a possible malware process has been identified and then optionally act on the detected malware process at Step 780.” Cochin ¶ 91)
comparing file access for a thread having a detected thread pattern variation to previous to previous file access for the thread; (see Cochin Fig. 2 open file dialog box)
comparing I/O access for a thread having a detected thread pattern variation to previous I/O access for the thread; (see Cochin Fig. 2 open file dialog box)
comparing network traffic for a thread having a detected thread pattern variation to previous network traffic for the thread; (See Cochin Fig. 2 send encrypted data)
comparing network addresses used by a thread having a detected thread pattern variation to previous network addresses used by the thread;
comparing API usage for a thread having a detected thread pattern variation to previous API usage for the thread; (“individual operations (or sequence of APIs) may be aggregated into microsteps, i.e., a high-level description of the intent of the combined operations.” Cochin ¶ 29)
comparing the context information for threads previously running in series but which are now running in parallel; comparing a file history for a thread having a detected thread pattern variation to a previous file history for the thread; dynamically comparing thread to thread context information for each of the plurality of threads; comparing system level thread patterns of a same application; or determining an importance of a thread having a detected thread pattern variation based on one or more user defined weights for the thread.
(alternatives not required)
As to claims 11 and 17 Cochin in view of Wintergerst and Tumblin discloses the machine/CRM of claims 11 and 17 as discussed above in claims 3 and 5.
Claim(s) 8, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cochin et al., US 2017/0093897 (filed 2015), in view of Wintergerst et al., US 2015/0033205 (published 2015), and Strogov, US 2020/0210580 (filed 2019-01).
As to claims 8, 14, 20, Cochin in view of Wintergerst discloses the method/machine/CRM of claims 1, 9, 15 and further discloses:
further comprising updating the stored thread patterns using machine learning and based on execution of the plurality of threads, (“by executing the solution in a “learning mode” on a clean system for some amount of time, the list of the normal behaviors and their associated microsteps may be gathered and stored locally before locking down the device and enforcing the recorded phenotypes.” Cochin ¶ 44. See also ¶ 4).
Cochin in view of Wintergerst does not disclose what type of Machine Learning is used:
wherein the machine learning comprises one or more of unsupervised machine learning or supervised machine learning.
Strogov discloses a system directed to learning thread behavior (Strogov ¶ 6). Strogov discloses:
wherein the machine learning comprises one or more of unsupervised machine learning or supervised machine learning.
(“the ML engine 104 may include a heuristics database or one or more models trained on previous execution stacks and configured to probabilistically identify user processes and threads that may be malicious based on their execution state. In one aspect, the ML engine 104 may be configured to perform an ensemble learning method for classifying the execution state and behavior of monitored user processes by using a plurality of decision trees (constructed at training time) that output a classification that is the mode of the classes output by the individual trees. In some implementations, the ML engine 104 may be configured to execute a “random forests” algorithm for classifying the execution state and behavior of the monitored user processes, a gradient boosted decision-tree based algorithm (e.g., LightBGM, XGBOOST), or other suitable ensemble learning methods.” Strogov ¶ 32. Supervised learning.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cochin in view of Wintergerst with Strogov by utilizing the machine learning algorithms of Strogov to implement the learning of Cochin. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cochin in view of Wintergerst with Strogov in order to provide the discussed learning algorithm of Cochin ¶ 4, to detect anomalous thread activity, Strogov ¶ 6. Thereby detecting and protecting computers from malicious threads.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Schneider et al., US 12,462,153m discloses behavior modeling using client-hosted neural networks.
Khorrami et al., US 12,450,353, discloses anomaly detection in multi-threaded processes.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached at (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492