DETAILED ACTION
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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 8, 9, 15 and 16 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Tsao (US 2018/0060576).
Regarding claims 1, 8 and 15, Tsao teaches A method comprising:
deploying an artificial intelligence (AI) model to an endpoint protection system (see [0030]: “In the example of FIG. 7, the endpoint computer system 300 receives the machine learning model 230 from the backend computer system 200 (see arrow 301).”), the AI model trained on a plurality of executable code files in byte form (see [0017]: “The backend computer system 200 may comprise one or more computers for generating a machine learning model 230 for identifying malicious files (also referred to as “malware”).” And see [0021]: “In the example of FIG. 2, the pre-processor 210 receives a normal file from the samples of known normal files, divides the normal file into a plurality of file sections 211 (i.e., 211-1, 211-2, . . . , 211-n) (see arrow 201), and labels each file section 211 as normal (L:NORM) (see arrow 202). … Similarly, the pre-processor 210 receives a malicious file from the samples of known malicious files, divides the malicious file into a plurality of file sections 212 (i.e., 212-1, 212-2, . . . , 212-n) (see arrow 204), and labels each file section 212 as malicious (L:MAL) (see arrow 205). …FIG. 3 shows an example file section extracted from a malicious PE file, and FIG. 4 shows an example file section extracted from a normal PE file.”
PNG
media_image1.png
588
564
media_image1.png
Greyscale
);
monitoring, by at least one component of the endpoint protection system, a target system for execution of a target executable file (see [0031]: “In the example of FIG. 7, the endpoint computer system 300 receives an unknown file for evaluation.” And see claim 5: “The computer-implemented method of claim 1, wherein the normal files, the malicious files, and the target file are executable files.”);
analyzing, by a processing device using the AI model, the target executable file in byte form of the target executable file (see [0032]: “in the example of FIG. 7, the malware detector 320 divides a target file into a plurality of file sections 321 (i.e., 321-1, 321-2, . . . , 321-n) (see arrow 302). The file sections 321 of the target file are input to the machine learning model 230 (see arrow 303), which classifies each of the file sections 321 as either normal or malicious (see arrow 304).”); and
determining, based on an output of the AI model, a decision variable for the target executable file, the decision variable indicating whether to allow execution of the target executable file (see [0033]: “the malware detector 320 deems the target file to be malicious when at least one file section 321 of the target file is classified by the machine learning model 230 as malicious. In that case, the malware detector 320 may identify the particular section of the target file that is classified by the machine learning model 230 as malicious. The malware detector 320 may deem the target file to be normal if none of the file sections 321 of the target file is classified by the machine learning model 230 as malicious. The malware detector 320 may take a response action against a detected malicious file, such as putting the malicious file in quarantine, blocking the malicious file from being received in the endpoint computer system 300, cleaning the malicious file, alerting a user or administrator, etc.” The Examiner interprets “putting the malicious file in quarantine” as not allow[ing] execution of the target executable file).
Regarding claims 2, 9 and 16, Tsao further teaches training the AI model with the plurality of executable code files in byte form to detect malicious code within target files containing executable code (see [0017]: “The backend computer system 200 may comprise one or more computers for generating a machine learning model 230 for identifying malicious files (also referred to as “malware”).” And see [0021]: “In the example of FIG. 2, the pre-processor 210 receives a normal file from the samples of known normal files, divides the normal file into a plurality of file sections 211 (i.e., 211-1, 211-2, . . . , 211-n) (see arrow 201), and labels each file section 211 as normal (L:NORM) (see arrow 202). … Similarly, the pre-processor 210 receives a malicious file from the samples of known malicious files, divides the malicious file into a plurality of file sections 212 (i.e., 212-1, 212-2, . . . , 212-n) (see arrow 204), and labels each file section 212 as malicious (L:MAL) (see arrow 205). …FIG. 3 shows an example file section extracted from a malicious PE file, and FIG. 4 shows an example file section extracted from a normal PE file.”
PNG
media_image1.png
588
564
media_image1.png
Greyscale
).
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 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Tsao (US 2018/0060576) as applied to claim 2 above, and further in view of Kephart (US 5,675,711).
Regarding claims 3, 10 and 17, Tsao further teaches wherein training the AI model further comprises: inputting the byte segments of each of the plurality of executable code files as training data for the AI model (see [0027] and Fig. 2: “The machine learning module 220 receives file sections 211 of normal files (see arrow 203) and file sections 212 of malicious files (see arrow 206). The machine learning module 220 receives the file sections 211 and 212 as pre-processed training data set for generating a machine learning model 230. More specifically, the machine learning module 220 is trained using the labeled file sections 211 and 212.” And see [0021]: “FIG. 3 shows an example file section extracted from a malicious PE file, and FIG. 4 shows an example file section extracted from a normal PE file.”).
Tsao differs from claims 3, 10 and 17 in that it fails to disclose randomly sampling byte segments of each of the plurality of executable code files in byte form.
In the same field of endeavor (detection of computer viruses using multi-layer neural networks, see Abstract), Kephart teaches randomly sampling byte segments (see col. 10, lines 19-28: “One way to help the classifier determine where to draw this boundary is to introduce input vectors with a small number of non-zero components that are classified as non-viral. This requires an auxiliary set of data. To achieve this, a large number of "pseudo" non-viral boot sectors can be generated by selecting 512-byte segments of executable files in the corpus of training and test sets C.sub.train and C.sub.test. The segments could be selected from some standard part of the file, such as the beginning, end, or entry point, or could be chosen at random.”) of each of the plurality of executable code files (see col. 7, lines 25-31: “The resulting classifier will not only correctly classify the strings in the example set, but will also, with high accuracy and high confidence, correctly classify novel strings not contained in the example set. As an example, the technique can be applied to the task of distinguishing executable data that are infected by computer viruses from uninfected executable data.”) in byte form (see col. 5, lines 16-30: “The invention provides an automated, statistical technique for identifying features present in the labeled set of exemplars that are likely to be relevant to the classification decision. The features are derived from the data strings, and consist of substrings, substrings with wildcards of limited or unlimited length, or logical combinations of the pattern of occurrence of such substrings in a given input string, possibly including some positional information. An example of a relatively complicated feature, in the case where the appropriate unit of data is bytes, is: "the occurrence of the substring `CD 13 EF EB`, or the occurrence of both `BA 80 00` and `FF ?? 00 FF 00` within 20 bytes of one another" (here ?? denotes a one-byte wildcard which matches any byte).”).
Both Tsao and Kephart disclose detection of computer viruses using an artificial intelligence (AI) model trained on a plurality of executable code files in byte form. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let training the AI model taught by Tsao further comprise randomly sampling byte segments of each of the plurality of executable code files in byte form, as taught by Kephart. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tsao (US 2018/0060576) as applied to claim 1 above, and further in view of Saxe (US 9,690,938).
Regarding claims 4, 11 and 18, Tsao fails to teach wherein the target executable file comprises a file type associated with an operating system.
In the same field of endeavor, Saxe discloses wherein the target executable file comprises a file type associated with an operating system (see col. 9, lines 44-61: “Referring back to FIG. 3, an abstract type determination module 112 can use the informational entropy value (e.g., of a file window) and/or a value associated with the combinations of an entropy value (or group or range of entropy values) for a sliding window and a byte value (or group or range of byte values) found within that sliding window for a file, to determine 314 attributes to associate with the file window, and/or the file sample as a whole. For example, the abstract type determination module 112 can determine … that the file originated and/or is intended for use on or was retrieved from a particular operating system and/or environment (e.g., that the file was obtained from and/or intended for use on a device running Windows, iOS, Linux, and/or a similar operating system”).
Both Tsao and Saxe disclose detection of computer viruses using an artificial intelligence (AI) model trained on a plurality of executable code files in byte form. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the target executable file of Tsao comprise a file type associated with an operating system, as taught by Saxe. It would have been obvious because doing so predictably determines whether the target executable file associated with an operating system is a malware.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tsao (US 2018/0060576) as applied to claim 1 above, and further in view of Ducau (US 2020/0364338).
Regarding claims 5, 12 and 19, Tsao fails to teach generating, by the AI model, an embedding based on the target executable file in the byte form, wherein the embedding comprises a plurality of data points for the target executable file.
In the same field of endeavor, Ducau discloses generating, by the AI model, an embedding based on the target executable file in the byte form, wherein the embedding comprises a plurality of data points for the target executable file (see [0049] and Fig. 3: “In model deployment 340, a target binary file 342 is processed by a feature extractor and file features 348 are generated. The features are processed by the trained model 350, and the trained model is then capable of detecting threats and also providing information about the type of threat that has been detected. This model may address an information gap between conventional machine learning and signature-based detection methods by providing a machine-learning based tagging model that generates human-interpretable semantic descriptions of malicious software (e.g., file-infector, coinminer). These descriptions provide potentially more useful and flexible information than malware family names.” And see [0142] and FIG. 7: “In this visualization the small markers represent the embeddings of a random sample of PE files that were only labeled with a single tag, while the large markers correspond to the embeddings of the tags themselves.” Note in Fig. 7, file-infector and crypto-miner are embeddings. Therefore, the Examiner interprets the trained model 350 generating descriptions of malicious software (e.g., file-infector, coinminer, which are embeddings) based on the target binary file 342 taught in [0049] as generating, by the AI model, an embedding based on the target executable file in the byte form, wherein the embedding comprises a plurality of data points for the target executable file).
Both Tsao and Ducau disclose detection of computer viruses using an artificial intelligence (AI) model trained on a plurality of executable code files in byte form. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Tsao by adding the step of generating, by the AI model, an embedding based on the target executable file in the byte form, wherein the embedding comprises a plurality of data points for the target executable file, which is taught by Ducau. It would have been obvious because Ducau explicitly teaches that doing so addresses an information gap between conventional machine learning and signature-based detection methods by providing a machine-learning based tagging model that generates human-interpretable semantic descriptions of malicious software (e.g., file-infector, coinminer) (see Ducau, [0049]).
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tsao (US 2018/0060576), further in view of Ducau (US 2020/0364338), and further in view of Caspi (US 2019/0384911).
Regarding claims 6, 13 and 20, Tsao modified in view of Ducau fails to teach providing the embedding of the AI model as input to another classification model.
However, Caspi discloses providing the malware category (emphasis added to show the difference between the reference and the claim) as input to another classification model (see [0011]: “there is provided a method of training a malware determination system comprising a machine learning algorithm, wherein the malware determination system is configured to identify a category of malware files, the method comprising providing a training set comprising a plurality of malware files, wherein these malware files belong to different categories of malware files, for each of a plurality of said malware files (by e.g. a processing unit), building a data structure representative of features present in said file, based on features present in at least one dictionary, wherein said dictionary stores at least, for each of one or more of category categories C.sub.i out of a plurality of N categories of malware files, with i from 1 to N and N>2, one or more features which are specific to said category C.sub.i with respect to all other N−1 categories C.sub.j, with j different from i.” And see [0018]: “vi. the dictionary is built using at least operations (a) to (c): (a) building at least N first size dictionaries, wherein each first-size dictionary D.sub.Ci is associated with a category C.sub.i of malware files, with i from 1 to N, said building comprising, for each category C.sub.i, extracting features from malware files of a training set belonging to category C.sub.i and storing them into said dictionary D.sub.Ci”. The Examiner building dictionaries in order to train a machine learning algorithm configured to identify a category of malware files, wherein each dictionary is associated with a category of malware files, as providing the malware category as input to another classification model).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Tsao modified in view of Ducau by adding the step of providing the malware category as input to another classification model taught by Caspi. It would have been obvious because doing so predictably achieves the commonly understood benefit of generating a machine learning algorithm configured to identify a category of malware files. Because the malware category is the embedding of the AI model taught by Tsao modified in view of Ducau, Tsao modified in view of Ducau and Caspi as described above would teach providing the embedding of the AI model as input to another classification model, as recited in claim 6.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Tsao (US 2018/0060576) as applied to claim 1 above, and further in view of Wu (CN 111259396 A).
Regarding claims 7 and 14, Tsao fails to teach compressing the AI model for deployment to a sensor on the endpoint of the endpoint protection system; and deploying the AI model, as compressed, to the sensor on the endpoint.
In the same field of endeavor, Wu discloses compressing the AI model for deployment to a sensor on the endpoint of the endpoint protection system; and deploying the AI model, as compressed, to the sensor on the endpoint (see Abstract: “The invention provides a computer virus detection method and system based on a deep learning convolutional neural network, and the detection method comprises the steps: firstly preprocessing virus data, …then, adopting a B2M algorithm to map the detection virus into a binary gray level image, calculating a gray level co-occurrence matrix, with the gray level co-occurrence matrix as input of a deep learning convolutional neural network CNN, and traditional visual features and the deep neural network are integrated; and finally, enabling the convolutional neural network CNN to perform high-accuracy detection and recognition. Besides, a compression algorithm of the deep neural network is designed and applied, the convolutional neural network CNN model is compressed, and the problem that the deep neural network model cannot be applied to embedded equipment due to the fact that a large number of hardware resources need to be consumed due to large parameters for a long time is solved.”).
Both Tsao and Wu disclose detection of computer viruses using an artificial intelligence (AI) model trained on a plurality of executable code files in byte form. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Tsao by adding the steps of compressing the AI model for deployment to a sensor on the endpoint of the endpoint protection system; and deploying the AI model, as compressed, to the sensor on the endpoint; which are taught by Wu. It would have been obvious because Wu teaches that doing so solves the problem that the deep neural network model cannot be applied to embedded equipment due to the fact that a large number of hardware resources need to be consumed due to large parameters (see Wu, Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHIMEI ZHU whose telephone number is (571)270-7990. The examiner can normally be reached 10am-6pm Monday-Friday.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/ZHIMEI ZHU/Examiner, Art Unit 2495
Prosecution Insights