DETAILED ACTION
This communication is responsive to the applicant’s arguments for application number 18/732,889 filed on 03/13/2026. Claims 1,10,11,20,22 have been currently amended. Claims 1,2,4-7,9-12,14-17 and 19-23 are pending examination.
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 arguments
Claim rejections under 35 U.S.C. 112:
Applicants’ amendments regarding claims 1-2,4-7,9-12,14-17 and 19-23 being rejected under 35 U.S.C. 112(b) are fully considered and are persuasive. Hence, the rejection under 35 U.S.C 112(b) are being withdrawn.
Claim rejections under 35 U.S.C 103:
Applicants’ arguments regarding claims 1,2,4-7,9-12,14-17 and 19-23 are considered but are moot because the new ground of rejection does not rely on the reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
A new reference Zaitsev et al. (US 20100132038 A1) has been introduced. Zaitsev discloses monitoring execution of a program in an emulator where the system records and counts repeated execution events using an event counter, corresponding to monitoring counts of operations performed by the process. The program is permitted to continue executing while these events are monitored and the system evaluates the frequency of the events to detect suspicious behavior, effectively establishing trigger conditions based on operation cunts. Zaitsev also distinguishes between programs on a whitelist and those that are not, where non-whitelisted programs undergo further behavioral analysis. When suspicious or unclassifiable behavior is detected, the system halts or terminates program emulation, which corresponds to suspending execution of the process. A second determination procedure involving analyst review then classifies the event as malicious or non-malicious, after which the system either terminates the program or allows it to continue executing.
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.
Claim(s) 1,2,4-6,9-12,14-16,19-23 is/are rejected under 35 U.S.C 103 as being unpatentable over Strogov et al. (US 20190347418 A1) hereinafter referred to as Strogov, in view of Zaitsev et al. (US 20100132038 A1), hereinafter referred to as Zaitsev.
As per claim 1, Strogov discloses a computer implemented method for detecting if a process being executed is suspicious, and determining whether the process should be interrupted, the method comprising:
- defining a first trigger event, wherein the first trigger event relates to a first threshold count of cryptographic operations; (After a predetermined number of operations are performed, collect the operations into event chain, Strogov, para [0049]. This uses a count threshold of operations as the trigger)
- determining whether the process is on a blacklist of processes; and if the process is on the blacklist of processes, then terminating the process; (Adding to a black list and blocking future sessions associated with the user ID, Strogov, para [0008])
- determining that the process has executed the first trigger event; (After a predetermined number of operations are performed, collect the operations into an event chain, Strogov, para [0049]. Reaching the "predetermined number" corresponds to detecting the trigger event occurred, where the threshold being met is an event-chain collection).
- determining whether the process is included in a whitelist of permitted processes; (The file server 102 makes a determination of the session classification 208 based on classification 1 and classification 2, Strogov, para [0049])
- if the process is included in the whitelist, permitting the process to continue executing, and if the process is not included in the whitelist, then: (Add the user and device to a whitelist of trusted users and devices. The file server 102 may add the user or device to a black list 210 based on a dangerous classification, Strogov, para [0049])
- suspending execution of the process; (If the session is classified as dangerous, the session may be forcibly interrupted, Strogov, para [0043]).
- initiating a first determination procedure; (Transmit the event chain to the ML engine and the entropy detector, Strogov, para [0049]. The determination procedure corresponds to running ML classification and entropy detection on collected events)
- receiving an input from the first determination procedure; and (ML engine generates classification 1 and entropy detector generates classification 2, Strogov, para [0049]. The inputs received are the classification outputs from the two analysis components)
- based on a determination from the first determination procedure, either terminating the process or permitting the process to continue executing; and (If dangerous, forcibly interrupted and if safe stops tracking, Strogov, para [0043]).
However, Strogov does not explicitly disclose the limitations:
- monitoring a cryptographic operation counter for the process, the cryptographic operation counter indicating a count of cryptographic operations performed at request of the process;
- after the process has been permitted to continue executing:
- determining that the process has executed a second trigger event, the second trigger event being defined in relation to a second threshold count of cryptographic operations, the second trigger event being different for processes permitted to continue executing based on inclusion in the whitelist compared with processes permitted to continue executing based on the determination from the first determination procedure;
- suspending execution of the process;
- initiating a second determination procedure;
- receiving an input from the second determination procedure; and
- based on a determination from the second determination procedure, either terminating the process or permitting the process to continue executing.
Zaitsev discloses:
- monitoring a cryptographic operation counter for the process, the cryptographic operation counter indicating a count of cryptographic operations performed at request of the process; (The system may remove all duplicate events from the program code and instead display an event counter indicating how many times the given event was repeated by the program, Zaitsev, para [0024]. The system monitors execution events generated by a program during emulation and maintains an event counter showing how many times the event occurs. A cryptographic operation would be one such monitored event. Hence, the event counter corresponds to a cryptographic operation counter since it counts how many times the monitored event occurs during program execution)
- after the process has been permitted to continue executing: (Program emulator 230 may then begin reading program instructions and emulate them using system emulator 225, Zaitsev, para [0018]. The emulator continues executing the program after monitoring begins, and hence the monitored process is permitted to continue executing while events are observed)
- determining that the process has executed a second trigger event, the second trigger event being defined in relation to a second threshold count of cryptographic operations, the second trigger event being different for processes permitted to continue executing based on inclusion in the whitelist compared with processes permitted to continue executing based on the determination from the first determination procedure; (The processing system may also provide various statistical information about the unclassifiable event, such as frequency of occurrence of the unclassifiable event in the program code. All new programs discovered by search engine 205 may be compared with a program whitelist 160 stored in data store 110. The whitelist identifies programs that have previously been classified by the system as non-malicious or legitimate. If the program does not appear in the whitelist is may be passed on to emulation engine 210 to be analyzed, Zaitsev, para [0016] and [0025]. The system evaluates frequency of occurrence of events which involves comparing the number of occurrences to thresholds or statistical expectations. When an event occurs frequently or matches suspicious patterns, it becomes an unclassifiable or suspicious event, acting as a trigger condition tied to an event count. The system distinguishes programs already in the whitelist and those requiring further behavioral analysis. Whitelisted programs bypass additional triggers while non-whitelisted programs are subject to event monitoring and further evaluation which means trigger conditions differ depending on whitelist status)
- suspending execution of the process; (When one or more generated events match one or more malicious events, event analyzer 220 may instruct emulation engine 210 to terminate program emulation, Zaitsev, para [0022])
- initiating a second determination procedure; (If event analyzer 220 cannot conclusively determine whether the generated event is malicious or not, event analyzer 220 may declare the event as unclassifiable, Zaitsev, para [0022]. This corresponds to a determination process)
- receiving an input from the second determination procedure; and (The workstation includes a user input device operable to receive analyst's physiological response indicating whether the presented event is malicious or not, Zaitsev, Abstract. Human analysts review the suspicious event and provide an input decision which is analogous to receiving input from the second determination procedure)
- based on a determination from the second determination procedure, either terminating the process or permitting the process to continue executing (Having reviewed the event-related information the program analyst may classify the event as malicious, non-malicious or unclassifiable, Zaitsev, para [0027]. The analyst’s classification determines the system’s response where malicious programs are stopped, while non-malicious programs are allowed to continue which aligns with termination the process or permitting continued execution based on the second determination).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Strogov and Zaitsev to protect against ransomware attacks (Strogov) and computer malware detection (Zaitsev). 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 Strogov and Zaitsev in order to effectively protect computing system from attacks (See Zaitsev, para [0027]).
As per claim 2, Strogov and Zaitsev disclose the computer implemented method of claim 1 wherein
Furthermore, Strogov discloses:
the first threshold count of cryptographic operations is one (After a predetermined number of operations are performed, the operations are collected into an event chain, Strogov, para [0049]. Because the trigger is defined as a predetermined number of operations, the minimum supported embodiment is one operation, satisfying a threshold count of one).
As per claim 4, Strogov and Zaitsev disclose the computer implemented method of claim 1 wherein
Furthermore, Strogov discloses:
the second trigger event relates to the process exceeding the second threshold count of cryptographic operations (The system continues monitoring operations associated with the session identifier and collects additional event chains when the number of operations exceeds a threshold, Strogov, para [0049]).
As per claim 5, Strogov and Zaitsev discloses the computer implemented method of claim 1 wherein
Furthermore, Strogov discloses:
the second trigger event relates to the process exceeding the second threshold count of cryptographic operations by a specified amount (The ML engine evaluates the size, frequency and entropy characteristics of the event chain to determine malicious behavior, Strogov, para [0042]).
As per claim 6, Strogov and Zaitsev discloses the computer implemented method of claim 1 further including,
Furthermore, Strogov discloses:
after terminating the process, attempting to mitigate modifications made by the process to data stored in a protected data store (If the session is classified as dangerous, the session may be forcibly interrupted and protective actions are taken to preserve system integrity such as choose to block the other IP addresses associated with the other client devices, Strogov, para [0044]).
As per claim 9, Strogov and Zaitsev discloses the computer implemented method of claim 1 further including
Furthermore, Strogov discloses:
assembling the whitelist of permitted processes by allowing a plurality of known processes to execute and creating a record for each of the known processes based on whether the processes perform any trigger events (Entities may be whitelisted based on historical behavior where event chains are collected and classified as good, Strogov, para [0049]. This discloses allowing known entities to execute, observing whether trigger events occur and recording good behavior to add to whitelist).
As per claim 10, Strogov discloses a computer implemented method for detecting if a process is suspicious, and determining whether the process should be interrupted, the method comprising:
- defining a plurality of trigger events; (After a predetermined number of operations are performed, collect the operations into event chain, Strogov, para [0049]. This uses a count threshold of operations as the trigger)
- identifying that the process has been initiated to execute; (Assigning a session identifier to a remote session initiated with the file server, Strogov, para [0006])
- monitoring the execution of the first process; (Monitoring operations on the file server associated with the session identifier, Strogov, para [0017]. The system monitors operations, functioning like an operation counter).
- determining whether the process is on a blacklist of processes; and if the process is on the blacklist of processes, then terminating the process; (Adding to a black list and blocking future sessions associated with the user ID, Strogov, para [0008])
- determining whether the process is included in a whitelist of permitted processes; (The file server 102 makes a determination of the session classification 208 based on classification 1 and classification 2, Strogov, para [0049])
- if the process is included in the whitelist, permitting the process to continue executing, and if the process is not included in the whitelist, then: (Add the user and device to a whitelist of trusted users and devices. The file server 102 may add the user or device to a black list 210 based on a dangerous classification, Strogov, para [0049])
- suspending execution of the process; (If the session is classified as dangerous, the session may be forcibly interrupted, Strogov, para [0043])
- initiating a first determination procedure; (Transmit the event chain to the ML engine and the entropy detector, Strogov, para [0049]. The determination procedure corresponds to running ML classification and entropy detection on collected events).
- receiving an input from the first determination procedure; and (ML engine generates classification 1 and entropy detector generates classification 2, Strogov, para [0049]. The inputs received are the classification outputs from the two analysis components).
- based on a determination from the determination procedure, either terminating the process or permitting the process to continue executing; and
(If dangerous, forcibly interrupted and if safe stops tracking, Strogov, para [0043]).
However, Strogov does not explicitly disclose the limitations:
- determining that the process has executed a first trigger event of the plurality of trigger events; (The system may remove all duplicate events from the program code and instead display an event counter indicating how many times the given event was repeated by the program, Zaitsev, para [0024]. The system monitors execution events generated by a program during emulation and maintains an event counter showing how many times the event occurs. A cryptographic operation would be one such monitored event. Hence, the event counter corresponds to a cryptographic operation counter since it counts how many times the monitored event occurs during program execution)
- after the process has been permitted to continue executing: (Program emulator 230 may then begin reading program instructions and emulate them using system emulator 225, Zaitsev, para [0018]. The emulator continues executing the program after monitoring begins, and hence the monitored process is permitted to continue executing while events are observed)
- determining that the process has executed a second trigger event, the second trigger event being defined in relation to a second threshold count of cryptographic operations that are performed at request of the process, and the second trigger event being different for processes permitted to continue executing based on inclusion in the whitelist compared with processes permitted to continue executing based on the determination from the first determination procedure; (The processing system may also provide various statistical information about the unclassifiable event, such as frequency of occurrence of the unclassifiable event in the program code. All new programs discovered by search engine 205 may be compared with a program whitelist 160 stored in data store 110. The whitelist identifies programs that have previously been classified by the system as non-malicious or legitimate. If the program does not appear in the whitelist is may be passed on to emulation engine 210 to be analyzed, Zaitsev, para [0016] and [0025]. The system evaluates frequency of occurrence of events which involves comparing the number of occurrences to thresholds or statistical expectations. When an event occurs frequently or matches suspicious patterns, it becomes an unclassifiable or suspicious event, acting as a trigger condition tied to an event count. The system distinguishes programs already in the whitelist and those requiring further behavioral analysis. Whitelisted programs bypass additional triggers while non-whitelisted programs are subject to event monitoring and further evaluation which means trigger conditions differ depending on whitelist status)
- suspending execution of the process; (When one or more generated events match one or more malicious events, event analyzer 220 may instruct emulation engine 210 to terminate program emulation, Zaitsev, para [0022])
- initiating a second determination procedure; (If event analyzer 220 cannot conclusively determine whether the generated event is malicious or not, event analyzer 220 may declare the event as unclassifiable, Zaitsev, para [0022]. This corresponds to a determination process)
- receiving an input from the second determination procedure; and (The workstation includes a user input device operable to receive analyst's physiological response indicating whether the presented event is malicious or not, Zaitsev, Abstract. Human analysts review the suspicious event and provide an input decision which is analogous to receiving input from the second determination procedure)
- based on a determination from the second determination procedure, either terminating the process or permitting the process to continue executing (Having reviewed the event-related information the program analyst may classify the event as malicious, non-malicious or unclassifiable, Zaitsev, para [0027]. The analyst’s classification determines the system’s response where malicious programs are stopped, while non-malicious programs are allowed to continue which aligns with termination the process or permitting continued execution based on the second determination).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Strogov and Zaitsev to protect against ransomware attacks (Strogov) and computer malware detection (Zaitsev). 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 Strogov and Zaitsev in order to effectively protect computing system from attacks (See Zaitsev, para [0027])
As per claim 11, Strogov and Zaitsev discloses the computer implemented method of claim 10 wherein
Furthermore, Strogov discloses:
at least one of the plurality of trigger events relates to a first threshold count of cryptographic operations (Determining that encryption of the data is occurring when entropy of the monitored data is growing faster than the predetermined threshold, Strogov, para [0006]).
As per claim 12, Strogov and Zaitsev discloses the computer implemented method of claim 11 wherein
Furthermore, Strogov discloses:
the first threshold count of cryptographic operations is one (After a predetermined number of operations are performed, the operations are collected into an event chain, Strogov, para [0049]. Because the trigger is defined as a predetermined number of operations, the minimum supported embodiment is one operation, satisfying a threshold count of one)
As per claim 14, Strogov and Zaitsev discloses the computer implemented method of claim 10 wherein
Furthermore, Strogov discloses:
the second trigger event relates to the process exceeding the second threshold count of cryptographic operations (The system continues monitoring operations associated with the session identifier and collects additional event chains when the number of operations exceeds a threshold, Strogov, para [0049])
As per claim 15, Strogov and Zaitsev discloses the computer implemented method of claim 10 wherein
Furthermore, Strogov discloses:
the second trigger event relates to the process exceeding the second threshold count of cryptographic operations by a specified amount (The ML engine evaluates the size, frequency and entropy characteristics of the event chain to determine malicious behavior, Strogov, para [0042]).
As per claim 16, Strogov and Zaitsev discloses the computer implemented method of claim 10 further including,
Furthermore, Strogov discloses:
after terminating the process, attempting to mitigate modifications made by the process to data stored in a protected data store (If the session is classified as dangerous, the session may be forcibly interrupted and protective actions are taken to preserve system integrity such as choose to block the other IP addresses associated with the other client devices, Strogov, para [0044]).
As per claim 19, Strogov and Zaitsev discloses the computer implemented method of claim 10 further including
Furthermore, Strogov discloses:
assembling the whitelist of permitted processes by allowing a plurality of known processes to execute and creating a record for each of the known processes based on whether the processes perform any trigger events (The ML engine 120 receives, or collects, various event chains 1 to N as shown in FIG. 3 and are then classified into classification 1, Strogov, para [0051])
As per claim 20, Strogov and Zaitsev discloses the computer implemented method of claim 1 wherein,
Furthermore, Strogov discloses:
after the process is terminated, adding the terminated process to the blacklist of processes (Adding to a black list and blocking future sessions associated with the user ID, Strogov, para [0008])
As per claim 21, Strogov and Zaitsev discloses the computer implemented method of claim 1 further including,
Furthermore, Strogov discloses:
after terminating the process, providing mitigation options to a user and allowing the user to approve or skip a mitigation process to attempt to mitigate modifications made by the process to data stored in a protected data store (If the session is classified as dangerous, the session may be forcibly interrupted and protective actions are taken to preserve system integrity such as choose to block the other IP addresses associated with the other client devices, Strogov, para [0044]).
As per claim 22, Strogov and Zaitsev discloses the computer implemented method of claim 10 wherein,
Furthermore, Strogov discloses:
after the process is terminated, adding the terminated process to the blacklist of processes (Adding to a black list and blocking future sessions associated with the user ID, Strogov, para [0008])
As per claim 23, Strogov and Zaitsev discloses the computer implemented method of claim 10 further including,
Furthermore, Strogov discloses:
after terminating the process, providing mitigation options to a user and allowing the user to approve or skip a mitigation process to attempt to mitigate modifications made by the process to data stored in a protected data store (If the session is classified as dangerous, the session may be forcibly interrupted and protective actions are taken to preserve system integrity such as choose to block the other IP addresses associated with the other client devices, Strogov, para [0044]).
Claim(s) 7 and 17 is/are rejected under 35 U.S.C 103 as being unpatentable over Strogov et al. (US 20190347418 A1) hereinafter referred to as Strogov, in view of Zaitsev et al. (US 20100132038 A1), hereinafter referred to as Zaitsev in further view of Kulaga et al. (US 20200319979 A1), hereinafter referred to as Kulaga.
As per claim 7, Strogov and Zaitsev discloses the computer implemented method of claim 6 wherein
However, Strogov in view of Zaitsev does not explicitly disclose the limitation:
mitigating modifications made by the process includes replacing modified data with previous versions of the data
Kulaga discloses:
mitigating modifications made by the process includes replacing modified data with previous versions of the data (Recover data for the computing device from the clean backup. Identify a clean backup that was created most recently before the malware attack as compared to other backups, Kulaga, para [0006])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Strogov and Zaitsev to protect against ransomware attacks (Strogov) and computer malware detection (Zaitsev) with restoring a clean backup after an attack (Kulaga). 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 Strogov and Zaitsev with Kulaga in order to mitigate damage caused by malicious processes by restoring modified data to a known safe state after the process is terminated, thereby improving system resilience and data integrity (See Kulaga, para [0006])
As per claim 17, Strogov and Zaitsev discloses the computer implemented method of claim 16 wherein
However, Strogov in view of Zaitsev does not explicitly disclose the limitation:
mitigating modifications made by the process includes replacing modified data with previous versions of the data
Kulaga discloses:
mitigating modifications made by the process includes replacing modified data with previous versions of the data (Recover data for the computing device from the clean backup. Identify a clean backup that was created most recently before the malware attack as compared to other backups, Kulaga, para [0006]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Strogov and Zaitsev to protect against ransomware attacks (Strogov) and computer malware detection (Zaitsev) with restoring a clean backup after an attack (Kulaga). 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 Strogov and Zaitsev with Kulaga in order to mitigate damage caused by malicious processes by restoring modified data to a known safe state after the process is terminated, thereby improving system resilience and data integrity (See Kulaga, para [0006])
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 RAGHAVENDER CHOLLETI whose telephone number is (703) 756-1065. The examiner can normally be reached M-Th 7:30AM -4:30PM EST and variable Fridays.
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 on (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/patentcenter 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.
Respectfully Submitted,
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/RUPAL DHARIA/ Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights