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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/06/2026 has been entered.
Response to Amendment
In the response filed on 01/21/2026. The applicant amended claims1, 5, 8, 9, and 12 are amended. No claims were added.
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. 103 rejection have been considered but are moot because the new ground of rejection set forth below in view of Valencia (US 20160253498.
Claim Objections
Regarding claims 1-12 are objected to because of the following informalities: The phrase “non-executable file” and “input of the on-executable” are recited several times creates ambiguity. For example, in claim 1 line 3 recites “input of non-executable file” at the same time in line 4 the term “input” is deleted and only “the non-executable file” is recited. Appropriate correction is required.
Regarding claims 2, 6, and 10, claims 2, 6, and 10 are objected to because of the following informalities: The phrase “the non-executable file is externally represented by a format of the non-executable file while embedding an executable file which is checked by the reader program”, is making the relationship between the non-executable file, its format and the embedded executable unclear. Also, the phrase “externally represented” is subjective and lacks objective boundaries. Appropriate correction is required.
Regarding claims 3, 7, and 11, claims 3, 7, and 11 are objected to because of the following informalities: The phrase “hooking on a system call requested on an operating system”, is unclear whether the claims intend to recite hooking a system call invoked by a process, hooking a system call requested from the operating system or hooking a system call interface of the operating system. Examiner suggest applicant to amend the claim language to clarify the relationship between the system call and the operating system. Appropriate correction is required.
Regarding claims 4, 8, and 12, claims 4, 8, and 12, are objected to because of the following informalities: The phrase “application programming interface (API) hooking performed during execution of an application related to the non-executable file”, is unclear whether the claim refers to an application that opens or executes the non-executable file, or an application that processes or analyzes the non-executable file or any application that is otherwise associated or related with the non-executable file . Examiner suggest applicant to amend the claim language to clarify what constitutes an application related to the non-executable file and data in a memory at the time of hooking. Appropriate correction is required.
Regarding claim 5, claim 5 is objected to because of the following informalities: claim 5 recites “a processor of a server configured to execute a program of an input file...” and the later refers to “a non-executable file input”. It is unclear whether the claim intends to refer to an execution of a reader program, ana analysis program, or a program embedded in the input file. If it is non executable, calling it program is confusing. Examiner suggest applicant to amend the claim language to clarify the scope of the claim. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-12 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 5 and 9 recite the limitation "the feature information is classified by a machine learning model using a multi label technique wherein the multilabel technique classifies the feature information into attack techniques using a binary vector with multiple dimensions” The phrases “multi label technique” and “binary vector with multiple dimensions” are unclear because the claims does not define the structure or meaning of the vector representation. The claims fails to specify what constitutes the “binary vector with multiple dimensions”, whether the binary vector represents features, attack techniques, classification outputs, or some other information, what dimensions of the vector correspond to. Additionally, the claims do not specify how the multi label technique generates or uses the binary vector or how the vector relates to the classification of attack techniques. The claim fails to clearly define the relationship between multilabel technique, the binary vector, and the attack techniques. These claims further “analysis feature extracted from dumping data stored in a memory immediately before the reader program is executed in a kernel area of the processor”, the phrase “kernel area of the processor” is unclear because it is ambiguous whether the limitation refers to kernel space memory of an operating system, or a hardware defined memory region of the processor or some other memory region. Additionally, the phrase “immediately before the reader program is executed” lacks objective boundaries. The claims does not define the relationship between the memory dumping operation and the execution of the reader program., and what constitutes the extracted analysis feature derived from the dumped memory.
Furthermore, the claims recite “obtaining, by the processor, feature information by selectively combining the two or more analysis features”. The term “selectively combining” is unclear because the claim does not define the criteria or conditions under which the analysis features are selected or combined. The claim does not specify what determines which analysis features are selected, how the selected analysis features are combined or selected, or what constitutes the selection process for combining the analysis features or what distinguishes “selectively combining” from simply combining the features. The claim do not provide objective boundaries for determining when analysis features are “selectively combined”. The claim further recites “a dynamic analysis feature that actually occurs during execution of a reader program”. The phrase “actually occurs “ renders the scope of the claims unclear since it does not define what distinguishes a dynamic analysis feature that “actually occurs” from other dynamic analysis features”. The claim does not provide objective boundaries for determining when a dynamic analysis feature “actually occurs”. Examiner suggest applicant to make these claims scope clear. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
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-12 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas (US 20120079596 A1) in view of Zakorzhevsky (US 9015814 B1) in further view of Valencia (US 20160253498 A1).
Regarding claim 1, Thomas teaches A cyber threat information processing method performed by a processor of a server (Thomas, Embodiments of the present application provide automated malware analysis services to customers and internal research teams…use to analyze threats and mitigate risks..provide an automated system that uses forensic tools in a post-mortem manner to analyze the behavior of malicious code and/or detect malware, [0021] The high-level architecture of embodiments of the present application includes a Database server, which can be a Linux system running MySQL. the malware detection and analysis controller is based on a Linux system that stores the main code for automating each step of the analysis, [0025] comprising:
receiving, by the processor, input of non-executable file, analyzing at least one feature related to a cyber threat of the non-executable file, and generating analysis information, wherein the analysis information includes two or more analysis features (Thomas, A method is provided to receive a file for analysis, store a memory baseline for a system, and copy the file to the system., [0005] FIG. 2, the system receives input(s) (e.g., malicious files) and a set of user preferences. The system performs an initial static analysis on the file or files and then dispatches the file or files to a physical machine, virtual machine, or emulator for dynamic analysis. The analysis engine uses forensic tools and techniques to determine what changed on the file system, registry, and in memory, [0029] a method of detecting and analyzing malware according to an embodiment. The method 300 includes receiving a file (310). The file, which may be one of several files is a potentially malicious file. The file may be any suitable file type that runs on an operating system (e.g., Microsoft Windows) and can include executables (.exe), dynamic link libraries (.dll), kernel drivers (.sys), Adobe Reader files (.pdf), Microsoft Office documents (.doc, .xls, .ppt), [0032]) if the file is an Adobe Reader (.pdf), the system will record data on the PDF tags and attempt to extract any hidden JavaScript or other embedded malicious codes, [0038]) [Examiner interprets that system accepting the Adobe Reader files (.pdf), Microsoft Office documents (.doc, .xls, .ppt) (i.e., non-executable files), analyzing static, format based, dynamic, inspection of files (i.e., two or more analysis features) of a inputted pdf/docs file as receiving, by the processor, input of a non-executable file, analyzing at least one feature related to a cyber threat of the input non-executable file, and generating analysis information, wherein the analysis information includes two or more analysis features]) of:
a static analysis feature extracted from a format of the non-executable file (Thomas, FIG. 2, the system receives input(s) (e.g., malicious files) and a set of user preferences. The system performs an initial static analysis on the file or files and then dispatches the file or files to a physical machine, virtual machine, or emulator for dynamic analysis, [0029] a method of detecting and analyzing malware according to an embodiment. The method 300 includes receiving a file (310). The file, which may be one of several files is a potentially malicious file. The file may be any suitable file type that runs on an operating system (e.g., Microsoft Windows) and can include executables (.exe), dynamic link libraries (.dll), kernel drivers (.sys), Adobe Reader files (.pdf), Microsoft Office documents (.doc, .xls, .ppt), [0032]) if the file is an Adobe Reader (.pdf), the system will record data on the PDF tags and attempt to extract any hidden JavaScript or other embedded malicious codes, [0038]) [Examiner interprets that system accepting the Adobe Reader files (.pdf), Microsoft Office documents (.doc, .xls, .ppt) (i.e., non-executable files), analyzing static, format based inspection of files (i.e., two or more analysis features) of a inputted pdf/docs file as a static analysis feature extracted from a format of the non-executable file];
a dynamic analysis feature that actually occurs during execution of a reader program (Thomas, FIG. 2, the system receives input(s) (e.g., malicious files) and a set of user preferences. The system performs an initial static analysis on the file or files and then dispatches the file or files to a physical machine, virtual machine, or emulator for dynamic analysis, [0029] Post-execution program: This option specifies the path to a program on the analysis station that should execute after the malware, but before the malware detection and analysis system analyzes the system for changes. This option is similar to the reboot option; however, it aims to satisfy the payloads that only activate on start-up of particular programs, such as Internet Explorer. [0211] Usermode API monitor: The API monitor output lists various sources of useful information in studying the exact behavior of an unknown program. It records the following information, without limitation: ID of the process making the API call, Thread ID of the thread making the API call, Name of the process making the call (i.e. cmd.exe), The name of the API call and all relevant parameters and values, The result of calling GetLastError( ) after the API call.., [0230-0239]) [Examiner interprets that system collecting dynamic behavior while file is opened/executed within an application (e.g., a reader/browser) yielding runtime feature as a dynamic analysis feature that actually occurs during execution of a reader program], and
an analysis feature extracted from dumping data stored in a memory immediately before the reader program is executed in a kernel area of the processor (Thomas, Embodiments utilize one or more advanced memory forensics platforms and ancillary software including databases to compute the difference between the baseline memory dump and the "infected" memory dump. By analyzing RAM, malicious behaviors are detected that conventional approaches cannot detect (such as the API hooks mentioned above), thus providing a more comprehensive and accurate report on the malware. …perform in-depth analysis of rootkits running in kernel mode memory (referred to as the rootkit detection component),[0023] The baseline includes the contents of the file system, registry, memory (RAM), and the like. After executing the malware, the system extracts a second information set (also referred to as the "comparison") while the target operating system is powered down. The powering down of the target operating system prevents the malware from "fighting back" against the information gathering process. The system then computes the difference between the baseline and the comparison, [0030]The method additionally includes creating a memory baseline (316). The baseline is created as a memory dump for the computer on which the malware is to be operated before the malware is copied to and executed on the computer (e.g., a virtual machine), [0039]) [Examiner interprets that system using baseline information of memory dump (i.e., pre execution information which satisfies immediately before the reader program) running in kernel mode memory as an analysis feature extracted from dumping data stored in a memory immediately before the reader program is executed in a kernel area of the processor];
obtaining, by the processor, feature information by selectively combining the two or more analysis features (Thomas, FIG. 2, the system receives input(s) (e.g., malicious files) and a set of user preferences. The system performs an initial static analysis on the file or files and then dispatches the file or files to a physical machine, virtual machine, or emulator for dynamic analysis. The analysis engine uses forensic tools and techniques to determine what changed on the file system, registry, and in memory. The analysis engine scans for rootkits (described in more detail below in relation to the rootkit component) and inserts the data in the database. The website allows users to browse and interact with reports, [0029] The baseline includes the contents of the file system, registry, memory (RAM), and the like. After executing the malware, the system extracts a second information set (also referred to as the "comparison") while the target operating system is powered down..The system then computes the difference between the baseline and the comparison, [0030]. Examples of forensic artifacts include time stamps that are associated with files, time stamps that are kept for registry keys, time stamps that are stored in the memory dump (i.e., post-execution memory), time stamps located within files on a file system (e.g., application logs or the like), etc.). Thus, time stamps are gathered from a variety of different sources. Analysis of the file system and comparison with the baseline will include an analysis of the time stamps since files with time stamps after the creation of the baseline (i.e., after the time that the file was transferred to and executed on the machine) are associated with files changed either a direct result of the malware or an indirect result of malware, [0043]) [Examiner interprets that workflow fusing static , dynamic, and memory artifacts into combined feature information (i.e., timelines/difference) as obtaining, by the processor, feature information by selectively combining the two or more analysis features];
detecting, by the processor, whether the non-executable file includes a malicious action based on the feature information (Thomas, the method may determine that the file is infected with malware, [0005] the present application provide an automated system that uses forensic tools in a post-mortem manner to analyze the behavior of malicious code and/or detect malware,…an automated system (with many other integrated components to be described herein) that uses forensic tools in a post-mortem manner to analyze the behavior of malicious code and/or detect malware. Such a system can be referred to as a sandbox, which, as will be evident to one of skill in the art, is a system in which malicious software can be executed in an environment…The product also performs a variety of dynamic and static analysis techniques to determine exactly what the malware does while running and its full range of capabilities, [0021] Embodiments utilize one or more advanced memory forensics platforms and ancillary software including databases to compute the difference between the baseline memory dump and the "infected" memory dump. By analyzing RAM, malicious behaviors are detected that conventional approaches cannot detect (such as the API hooks mentioned above), thus providing a more comprehensive and accurate report on the malware, [0023] The behaviors are highlighted if the malware detection and analysis system detected a particular behavior after running a sample. The behaviors can be based on either the creation of a particular file, the content within the file, some heuristic behavior of the malware, some artifact found in memory after running the malware, or any number of behaviors that the system detects as a result of the malware exhibiting one or more particular behaviors, [0271]) [Examiner interprets system detecting if the file is malicious based on behaviors of file such as the creation of a particular file, the content within the file, some heuristic behavior of the malware, some artifact found in memory after running the malware, or any number of behaviors that the system (i.e., the combined feature information) as detecting, by the processor, whether the non-executable file includes a malicious action based on the feature information], and
providing, by the processor, cyber threat information to a user based on the classified feature information of the non-executable file (Thomas, FIG. 2, the system receives input(s) (e.g., malicious files) and a set of user preferences. The system performs an initial static analysis on the file or files and then dispatches the file or files to a physical machine, virtual machine, or emulator for dynamic analysis. The analysis engine uses forensic tools and techniques to determine what changed on the file system, registry, and in memory. The analysis engine scans for rootkits (described in more detail below in relation to the rootkit component) and inserts the data in the database. The website allows users to browse and interact with reports, [0029] once the malware sample has been submitted, the website will automatically redirect the user to a reports information page, which provides the main GUI for reporting on the results of the analysis for the sample that was submitted. Additionally, malware can be grouped after analysis using various colors as indicators, [0250]) [Examiner interprets that system receiving pdf or docs file (i.e., non-executable file), analyzing the file (i.e., static, dynamic) if it malicious, and reporting the result in GUI to users as providing, by the processor, cyber threat information to a user based on the generated classification information of the non-executable file].
Although, Thomas teaches under BRI a reader program such as internal explorer, see par [0211], Thomas does not explicitly teach:
an analysis feature that actually occurs during execution of a reader program; wherein the feature information is classified by a machine learning model using a multi-label technique, wherein the multi-label technique classifies the feature information into attack techniques using a binary vector with multiple dimensions
However, Zakorzhevsky teaches:
a analysis feature that actually occurs during execution of a reader program (Zakorzhevsky, triggering the signature of the suspicious file includes: opening the suspicious file with a corresponding program; performing actions on the suspicious file related to activities of a user of the suspicious file; and registering system API calls and a memory dump of a process that opened the suspicious file, (See Col 2, lines 15-20) for analysis of a PDF file, a custom virtual machine may be configured to run one or more different versions of Adobe Reader (although other programs for opening PDF files may be used, such as Foxit Reader), (See Col 4, lines 44-48)) [Examiner interprets that system performing analysis of PDF file (i.e., non-executable) where the file is running in reader program such as Adobe Reader as a analysis feature that actually occurs during execution of a reader program].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Thomas to include a concept of a analysis feature that actually occurs during execution of a reader program as taught by Zakorzhevsky for the purpose of opening the suspicious file with a corresponding program; performing actions on the suspicious file related to activities of a user of the suspicious file; and registering system API calls and a memory dump of a process that opened the suspicious file, [Zakorzhevsky :(See Col 2, lines 15-20)] for analysis of a PDF file, a custom virtual machine may be configured to run one or more different versions of Adobe Reader (although other programs for opening PDF files may be used, such as Foxit Reader), [Zakorzhevsky :(See Col 4, lines 44-48)].
Thomas and Zakorzhevsky does not explicitly teach:
the feature information is classified by a machine learning model using a multi-label technique, wherein the multi-label technique classifies the feature information into attack techniques using a binary vector with multiple dimensions
However, Valencia teaches:
the feature information is classified by a machine learning model using a multi-label technique, wherein the multi-label technique classifies the feature information into attack techniques using a binary vector with multiple dimensions (Valencia, using the behavior-based machine learning technique to classify the device behavior as one of benign, suspicious or non-benign may include classifying the device behavior as a suspicious device behavior, and using one of the multi-label classification technique and the meta-classification technique to sub-classify the device behavior into the one or more sub-categories may include sub-classifying the suspicious device behavior into a sub-category selected from a group that includes Adware, Key Logger, Ransomware, Spyware, mRAT, Botnet, Phishing, Trojan, and Short Message Service (SMS) Fraudware. In a further aspect, determining the relative importance of the device behavior based on the sub-classification may include determining a severity of risk posed by the device behavior to the proper functioning of the computing device, [0004] Each behavior vector may encapsulate one or more “behavior features.” Each behavior feature may include an abstract number or symbol that represents all or a portion of an observed behavior, [0036] Phishing is a cyber-attack technique , [0053] In addition to evaluating a condition and outputting an answer and a weight value (e.g., as part of the analysis results) for determining whether a behavior is benign or non-benign, each decision stump in a multi-classification classifier model may output an additional value (e.g., a probability value, etc.) for each of its associated labels. For example, applying a behavior vector to a multi-classification classifier model that includes the classification labels “adware,” “spyware,” “key-logger,” “SMSFraud,” and “ransomware” may cause the device to generate the following output:[0.1, 0.9, 0.9, 0.2, 0.2], [0058] a multi-classification classifier model may include decision stumps (e.g., boosted decision stumps, etc.) that are each associated with one or more labels. Decision stumps are one level decision trees that have exactly one node (and thus one test question or test condition) and a weight value, and thus are well suited for use in a binary classification of data/behaviors. That is, applying a behavior vector to boosted decision stump results in a binary answer (e.g., Yes or No), [0057] The vector data-structure may include series of numbers, each of which signifies a feature or a behavior of the device, [0079]) [Examiner interprets that system using machine learning and multi label classification, outputting multi dimension level vector, using binary decision stumps, and performing threshold-based label assignment as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Thomas and Zakorzhevsky to include a concept of the feature information is classified by a machine learning model using a multi-label technique, wherein the multi-label technique classifies the feature information into attack techniques using a binary vector with multiple dimensions as taught by Valencia for the purpose of using the behavior-based machine learning technique to classify the device behavior as one of benign, suspicious or non-benign may include classifying the device behavior as a suspicious device behavior, and using one of the multi-label classification technique and the meta-classification technique to sub-classify the device behavior into the one or more sub-categories may include sub-classifying the suspicious device behavior into a sub-category selected from a group that includes Adware, Key Logger, Ransomware, Spyware, mRAT, Botnet, Phishing, Trojan, and Short Message Service (SMS) Fraudware, [Valencia: 0004].
Regarding claim 2, Thomas, Zakorzhevsky, and Valencia teaches the cyber threat information processing method according to claim 1, wherein the non-executable file is externally represented by a format of the non-executable file while embedding an executable file which is checked by the reader program (Thomas, the system may perform special tasks per file type using "dynamic pre-processors." As an example, if the file is an Adobe Reader (.pdf), the system will record data on the PDF tags and attempt to extract any hidden JavaScript or other embedded malicious codes, [0038] Table 3 is an example of a file system analysis. This table shows the files that the malware created or deleted. If the user chooses a "deep" scan on the submission page instead of a "quick" scan (which is the default in some embodiments), then it also detects changes to files based on MD5/SHA1 hash. It shows a preview of the file's contents and the file's type, so the user can easily tell if ssv.txt is really an MS-DOS executable and see that Igate.htm probably contains some encoded command and control data. Based on the content type, the user can get extended information, as shown in the next section (for example PE header details for MS-DOS programs or extracted JavaScript from malicious PDF files), [0190])
Although, Thomas teaches under BRI a reader program such as internal explorer, see par [0211], Thomas does not explicitly teach:
an executable file which is checked by the reader program
However, Zakorzhevsky teaches:
an executable file which is checked by the reader program (Zakorzhevsky, popular programs working with PDF (Acrobat Reader itself) continue to have many vulnerabilities, and a document can be structured in such way that, when opened, it becomes possible to utilize vulnerability using exploit and initiate an execution of malicious payload, (See Col 1, lines 41-46) triggering the signature of the suspicious file includes: opening the suspicious file with a corresponding program; performing actions on the suspicious file related to activities of a user of the suspicious file; and registering system API calls and a memory dump of a process that opened the suspicious file, (See Col 2, lines 15-20) for analysis of a PDF file, a custom virtual machine may be configured to run one or more different versions of Adobe Reader (although other programs for opening PDF files may be used, such as Foxit Reader), (See Col 4, lines 44-48)) [Examiner interprets that system performing analysis of PDF file (i.e., non-executable) if the file is malicious by opening a suspicious file, registering system API calls using the reader program such as Acrobat Reader as an executable file which is checked by the reader program] The same motivation applies as claim 1 above.
Regarding claim 3, Thomas, Zakorzhevsky, and Valencia teaches the cyber threat information processing method according to claim 1, wherein: the reader program related to the non-executable file performs hooking on a system call requested on an operating system, and the dynamic analysis feature is generated based on information obtained from data in a memory at a time of the hooking and an execution function and a parameter before the time of the hooking (Thomas, Table 8 is an example of a memory forensics/analysis. Embodiments may include strong memory forensics capabilities. As described may determine new processes, hidden or injected code, loaded kernel modules, network connections, open files, API hooks, active service processes, and the like. Embodiments also include a built-in custom memory scanner that is quick and configurable. Table 8 shows some positive hits in the memory of wuauclt.exe and winlogon.exe, [0193] Table 9 shows which API functions the malware hooked inside the explorer.exe process. It also shows the type of hook (INLINE), the relevant memory addresses, and disassembled instructions, [0194] Usermode API monitor: The API monitor output lists various sources of useful information in studying the exact behavior of an unknown program. It records the following information, without limitation: ID of the process making the API call, Thread ID of the thread making the API call, Name of the process making the call (i.e. cmd.exe), The name of the API call and all relevant parameters and values,The result of calling GetLastError( ) after the API call.., [0230-0239]) [Examiner interprets that system hooking/observing system/API calls, recording function and parameters and corelating with relevant memory during the execution of the related application (i.e., the reader program) as limitation above];
Although, Thomas teaches under BRI a reader program such as internal explorer, see par [0211], Thomas does not explicitly teach:
the reader program related to the non-executable file
However, Zakorzhevsky teaches:
the reader program related to the non-executable file (Zakorzhevsky, popular programs working with PDF (Acrobat Reader itself) continue to have many vulnerabilities, and a document can be structured in such way that, when opened, it becomes possible to utilize vulnerability using exploit and initiate an execution of malicious payload, (See Col 1, lines 41-46) triggering the signature of the suspicious file includes: opening the suspicious file with a corresponding program; performing actions on the suspicious file related to activities of a user of the suspicious file; and registering system API calls and a memory dump of a process that opened the suspicious file, (See Col 2, lines 15-20) for analysis of a PDF file, a custom virtual machine may be configured to run one or more different versions of Adobe Reader (although other programs for opening PDF files may be used, such as Foxit Reader), (See Col 4, lines 44-48)) [Examiner interprets that system placing hooking/registration in the reader process that opened the non-executable as the reader program related to the non-executable file]. The same motivation applies as claim 1 above.
Regarding claim 4, Thomas, Zakorzhevsky, and Valencia teaches the cyber threat information processing method according to claim 1, wherein the analysis feature is generated based on application programming interface (API) hooking performed during execution of an application related to the non-executable file, and the analysis feature includes feature information obtained from data in a memory at a time of the hooking (Thomas, The memory-based rootkits and behaviors include, but are not limited to: Attempts to install hook in user or kernel mode memory (IAT, EAT, Inline), [0143] Table 8 is an example of a memory forensics/analysis. Embodiments may include strong memory forensics capabilities. As described throughout the present specification, some embodiments may determine new processes, hidden or injected code, loaded kernel modules, network connections, open files, API hooks, active service processes, and the like. Embodiments also include a built-in custom memory scanner that is quick and configurable. Table 8 shows some positive hits in the memory of wuauclt.exe and winlogon.exe.., [0193]Table 9 shows which API functions the malware hooked inside the explorer.exe process. It also shows the type of hook (INLINE), the relevant memory addresses, and disassembled instructions, [0194] Monitor API: This option enables usermode API monitoring of the suspect binary. This option provides a detailed trace of API usage at the expense of eliminating the forensic soundness of the analysis station. By enabling the API monitor, the malware detection and analysis system injects DLLs into the suspect binary as it executes, [0211]) [Examiner interprets that system performing API hooking while the application executes, and extracting memory information at the time of hooking such as relevant memory addresses, and disassembled instructions (i.e., the analysis feature) as limitation above].
Although, Thomas teaches under BRI a reader program such as internal explorer, see par [0211], Thomas does not explicitly teach:
an application related to the non-executable file
However, Zakorzhevsky teaches:
an application related to the non-executable file (Zakorzhevsky, popular programs working with PDF (Acrobat Reader itself) continue to have many vulnerabilities, and a document can be structured in such way that, when opened, it becomes possible to utilize vulnerability using exploit and initiate an execution of malicious payload, (See Col 1, lines 41-46) triggering the signature of the suspicious file includes: opening the suspicious file with a corresponding program; performing actions on the suspicious file related to activities of a user of the suspicious file; and registering system API calls and a memory dump of a process that opened the suspicious file, (See Col 2, lines 15-20) for analysis of a PDF file, a custom virtual machine may be configured to run one or more different versions of Adobe Reader (although other programs for opening PDF files may be used, such as Foxit Reader), (See Col 4, lines 44-48)). The same motivation applies as claim 1 above
Regarding claim 5, Claim 5 recite commensurate subject matter as claim 1. Therefore, it is rejected for the same reasons. Except the additional elements:
Thomas further teaches:
a storage device configured to store data (Thomas, database for storage, [0031]);
a processor of a server configured to execute a program of an input file, wherein the processor (Thomas, Database server, which can be a Linux system running MySQL. the malware detection and analysis controller is based on a Linux system that stores the main code for automating each step of the analysis, [0025])
Regarding claim 6-8, Claim 6-8 recite commensurate subject matter as claim 2-4. Therefore, they are rejected for the same reasons
Regarding claim 9, Claim 9 recite commensurate subject matter as claim 1. Therefore, it is rejected for the same reasons. Except the additional elements:
Johns further teaches:
A non-transitory computer-readable storage medium storing a program for processing cybersecurity threat information (Thomas, the system in instructions on a computer-readable medium, perform a method comprising a malware detection and analysis system, [0028])
Regarding claim 10-12, Claim 10-12 recite commensurate subject matter as claim 2-4. Therefore, they are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 9934376 B1: “relates to malware detection and, more specifically, to a micro visor-based malware detection architecture”
US 10586045 B2: “systems and methods for utilizing a combination of virtual environments and actual mobile devices to capture interactions between a mobile application and the operating system of a mobile device to determine whether malware is operating within a mobile device software application”
US 20120158626 A1: “describes techniques for using features extracted from a URL to detect a malicious URL and categorize the malicious URL as one of a phishing URL, a spamming URL, a malware URL or a multi-type attack URL”.
US 10033747 B1: “relates to a threat detection system that is adapted to detect exploit attacks, especially on an interpreter deployed within in kernel mode or user mode”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436