DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1-20 are pending and have been examined.
Claim Rejections - 35 USC § 103
3. 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.
4. 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.
5. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. 9,900,324 B2 (hereinafter “Barua”), and further in view of U.S. Pat. No. 7,490,352 B2 (hereinafter “Kramer”).
As per claim 1:
Barua discloses:
A method comprising:
receiving, by a computer system, a target suspect file that has multiple execution paths (col. 2 lines 31-51: software is examined that has multiple execution paths);
interpreting, by the computer system, code of the target suspect file to determine each of the execution paths (col. 2 lines 31-51: The behavior of the malware (code) is exposed along all of its execution paths, col. 5 lines 33-53, malware (code) is allowed to execute, conditional branches are identified, and the code is modified to force all paths not previously executed to execute);
interpreting, by the computer system, the code of the target suspect file to determine that a first execution path of the multiple execution paths is dependent on a conditional test (col. 5 lines 33-53, malware (code) is allowed to execute, conditional branches are identified);
interpreting, by the computer system, the code of the target suspect file to determine whether an action that the target suspect file would perform upon being executed in the first execution path of the multiple execution paths would exhibit malicious behavior (col. 9 line 8-22: conditionally executed path may try to access an external server and is identified as potentially malicious behavior); and
Barua does not disclose:
denying, by the computer system in response to determining that the action would exhibit malicious behavior, entry of the target suspect file into a computing environment.
However, in an analogous art, Kramer teaches:
denying, by the computer system in response to determining that the action would exhibit malicious behavior, entry of the target suspect file into a computing environment (col. 4 lines 37-45, trust verifier marks detected malware as “untrusted” and then causes the OS to not install it and not load it into memory for execution).
It would have been obvious, to a person having ordinary skill in the art before the effective filing date of the invention, to modify Barua’s malware analysis system to deny execution/installation of software identified as malicious in the manner taught by Kramer’s trust verification facility, which marks detected malware as untrusted and prevents its installation and loading for execution. Applying Kramer’s known technique of integrating malware checks into the operating system’s execution/installation path to Barua’s malware detection results is a combination of prior art elements according to known methods to yield the predictable result of preventing identified malware from entering or executing in the protected computing environment (see MPEP 2143).
As per claim 2:
The combination of Barua in view of Kramer teaches:
the method of claim 1, wherein: the interpreting functions are performed without executing the code of the target suspect file (Barua, col. 3 line 54 through col. 4 line 7: Static analysis techniques are discussed, col. 7 lines 53-61: static analysis may be performed in an embodiment).
As per claim 3:
The combination of Barua in view of Kramer teaches:
the method of claim 1, wherein: the interpreting functions are performed by analyzing the code of the target suspect file (Barua, col. 5 lines 33-60, malware (code) is allowed to execute, conditional branches are identified and the code execution is analyzed, col. 9 lines 40-67).
As for claim 4,
The combination of Barua in view of Kramer teaches:
the method of claim 1. Kramer teaches somewhat more explicitly than does Barua the features:
granting, by the computer system in response to determining that no action that the target suspect file would perform upon being executed in any of the execution paths would exhibit malicious behavior, entry of the target suspect file into the computing environment (fig. 2 elem. 206, col. 6 lines 18-23: if after analysis an executable file is deemed to not comprise malware, but is not from a trusted source, a system admin. is permitted to approve loading). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated this feature into the invention of Barua. It would have been desirable to do so since this would allow for loading of only executable code that is deemed to be safe and therefore enhance the effectiveness of Barua’s system.
As per claim 5:
The combination of Barua in view of Kramer teaches:
the method of claim 1, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that a set of actions that the target suspect file would perform upon being executed would be a potential environment check; and bypassing, by the computer system, the potential environment check (Barua, col. 6 line 60 through col 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute).
As per claim 6:
The combination of Barua in view of Kramer teaches:
the method of claim 5, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that a first action of the set of actions would be a read instruction of data that would be indicative of a particular characteristic or feature of the computing environment; and interpreting, by the computer system, the code of the target suspect file to determine that a second action of the set of actions would be a conditional test that would use the data that would have been read; wherein: the read instruction and the conditional test are the potential environment check (Barua, col. 6 line 60 through col 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute).
As per claim 7:
The combination of Barua in view of Kramer teaches:
the method of claim 6, further comprising: obtaining, by the computer system, the data by emulating the read instruction (Barua, col. 6 line 60 through col. 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute, analysis is performed by executing the malware code in a sandbox, reading on emulating the read instruction).
As per claim 8:
The combination of Barua in view of Kramer teaches:
the method of claim 1, further comprising: interpreting, by the computer system, a first instruction that the target suspect file would perform upon being executed as part of a reconnaissance stage of a multi-stage attack (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and execute at a later time when installed in a real system, reading on a multi-stage attack).
As per claim 9:
The combination of Barua in view of Kramer teaches:
the method of claim 8, further comprising: interpreting, by the computer system, a second instruction that the target suspect file would perform upon being executed as part of an attack stage of a multi-stage attack (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and execute at a later time when installed in a real system, reading on a multi-stage attack).
As per claim 10:
Barua discloses:
a method comprising:
receiving, by a computer system, a target suspect file; interpreting, by the computer system, code of the target suspect file to determine that a set of actions that the target suspect file would perform upon being executed would be a detection-avoidance technique (col. 2 lines 31-51: software is examined that has multiple execution paths, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and execute at a later time when installed in a real system),
bypassing, by the computer system, the detection-avoidance technique; interpreting, by the computer system, the code of the target suspect file to determine each action that the target suspect file could potentially perform regardless of the detection-avoidance technique (col. 2 lines 31-51: The behavior of the malware (code) is exposed along all of its execution paths, col. 5 lines 33-53, malware (code) is allowed to execute, conditional branches are identified, and the code is modified to force all paths not previously executed to execute, col. 6 line 60 through col 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute),
determining, by the computer system, whether an action that the target suspect file could perform upon being executed would exhibit malicious behavior (col. 6 line 60 through col 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute, potential malware behavior is identified),
Barua does not disclose:
denying, by the computer system in response to determining that the action would exhibit malicious behavior, entry of the target suspect file into a computing environment.
However, in an analogous art, Kramer teaches:
denying, by the computer system in response to determining that the action would exhibit malicious behavior, entry of the target suspect file into a computing environment (col. 4 lines 37-45, trust verifier marks detected malware as “untrusted” and then causes the OS to not install it and not load it into memory for execution).
It would have been obvious, to a person having ordinary skill in the art before the effective filing date of the invention, to modify Barua’s malware analysis system to deny execution/installation of software identified as malicious in the manner taught by Kramer’s trust verification facility, which marks detected malware as untrusted and prevents its installation and loading for execution. Applying Kramer’s known technique of integrating malware checks into the operating system’s execution/installation path to Barua’s malware detection results is a combination of prior art elements according to known methods to yield the predictable result of preventing identified malware from entering or executing in the protected computing environment (see MPEP 2143).
As per claim 11:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that the detection-avoidance technique is a potential environment check (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection).
As per claim 12:
The combination of Barua in view of Kramer teaches:
the method of claim 11, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that a first action of the set of actions would be a read instruction of data that would be indicative of a particular characteristic or feature of the computing environment (Barua, col. 6 line 60 through col. 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute),
and interpreting, by the computer system, the code of the target suspect file to determine that a second action of the set of actions would be a conditional test that would use the data that would have been read; wherein: the read instruction and the conditional test are the potential environment check. (Barua, col. 6 line 60 through col. 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute, analysis is performed by executing the malware code in a sandbox, reading on emulating the read instruction and the malware’s conditional use of the environmental variable).
As per claim 13:
The combination of Barua in view of Kramer teaches:
the method of claim 12, further comprising: obtaining, by the computer system, the data by emulating the read instruction (Barua, col. 6 line 60 through col. 7 line 16: taint analysis is performed on conditional branches of the malware code which read an environmental variable in order to execute, analysis is performed by executing the malware code in a sandbox by determination of the read variable).
As per claim 14:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising: interpreting, by the computer system, a first instruction that the target suspect file would perform upon being executed as part of a reconnaissance stage of a multi-stage attack (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and execute at a later time when installed in a real system, reading on a multi-stage attack).
As per claim 15:
The combination of Barua in view of Kramer teaches:
the method of claim 14, further comprising: interpreting, by the computer system, a second instruction that the target suspect file would perform upon being executed as part of an attack stage of a multi-stage attack (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and execute at a later time when installed in a real system, reading on a second instruction).
As per claim 16:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that the detection-avoidance technique is a sleep-delay technique with a sleep instruction that would cause the target suspect file not to be executed for a period of time; and emulating, by the computer system, the sleep instruction to complete it immediately (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and to “sleep” and then execute at a later time when installed in a real system).
As per claim 17:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that the detection-avoidance technique includes an instruction repeated in a loop; and exiting, by the computer system, the loop after detecting a predetermined number of the instruction (Barua, col. 7 lines 16-20, claim 6).
As per claim18:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising:
interpreting, by the computer system, the code of the target suspect file to determine that the code of the target suspect file includes multiple execution paths; and interpreting, by the computer system, the code of the target suspect file to determine an action that the target suspect file could perform upon being executed for an execution path of the multiple execution paths that is dependent on a conditional test (Barua, col. 2 lines 31-51: The behavior of the malware (code) is exposed along all of its execution paths, col. 5 lines 33-53, malware (code) is allowed to execute, conditional branches are identified col. 5 lines 33-53, malware (code) is allowed to execute, conditional branches are identified and the code is modified to force all paths not previously executed to execute).
As per claim 19:
The combination of Barua in view of Kramer teaches:
the method of claim 10, further comprising: interpreting, by the computer system, the code of the target suspect file to determine that the detection-avoidance technique includes a first execution path that the target suspect file would perform in response to an environment check producing a first result interpreting, by the computer system, the code of the target suspect file to determine that code of the first execution path would exhibit non-malicious behavior; interpreting, by the computer system, the code of the target suspect file to determine that the detection-avoidance technique includes a second execution path that the target suspect file would perform in response to the environment check producing a second result; and interpreting, by the computer system, the code of the target suspect file to determine that code of the second execution path would exhibit the malicious behavior (Barua, col. 2 line 52 through col. 3 line 12: the system is designed to detect malware code that attempts to detect if it is being run in a sandbox. Such malware is written so as to delay executing for a period of time in those circumstances where it is in a virtual or sandbox environment in order to evade detection and to “sleep” and then execute at a later time when installed in a real system. This reads on malware code that exhibits a first execution path not exhibiting the malicious behavior and a second execution path exhibiting the malicious behavior).
As per claim 20:
The combination of Barua in view of Kramer teaches:
the method of claim 10, wherein: the interpreting functions are performed without executing the code of the target suspect file (Barua, col. 3 line 54 through col. 4 line 7: Static analysis techniques are discussed, col. 7 lines 53-61: static analysis may be performed in an embodiment).
Conclusion
6. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kolbitsch et al., US 9,361,459: Discusses similar techniques to the instant invention: allowing malware to execute in a sandbox, identifying conditional branches, forcing all branches to execute, and identifying malware using those techniques. (see esp. col. 1 lines 35-44, col. 1 line 45 through col 2 line 5, col. 4 line 7 through col. 5 line 30).
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul E. Callahan whose telephone number is (571) 272-3869. The examiner presently works a part-time schedule and can normally be reached from 9am to 5pm on the first Monday and Tuesday and the second Thursday and Friday of the USPTO bi-week schedule.
The examiner’s email address is: Paul.Callahan1@USPTO.GOV
If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Alexander Lagor, can be reached on (571) 270-5143. The fax phone number for the organization where this application or proceeding is assigned is: (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/PAUL E CALLAHAN/ Examiner, Art Unit 2437