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 .
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 12/22/2025 has been entered.
Response to Arguments
Applicant’s arguments, see pages 10 and 11, filed 12/17/2025, with respect to the rejection of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of STUSSI et al (Doc ID US 20240419793 A1) and CARSON (Doc ID US 20190251251 A1).
Regarding the argument directed to claims 1 and 8:
“The applied references fail to disclose and would not have rendered obvious at least "training, by the processor, a first machine learning model … to identify malicious code patterns …; training, by the processor, a second machine learning model … to identify threat protection code patterns …" as recited in independent claim 1.
“The Office Action alleges that Stussi discloses these features. Office Action, p. 4. Specifically, the Office Action alleges that Stussi discloses these features …. However, as recited above, the claimed first and second machine learning models are trained to perform different things. … These specific functions are not described in Stussi, and there is nothing in the Office Action to suggest that the single disclosure of Stussi teaches either of these specific features. …”
Examiner respectfully disagrees. While the two machine learning (ML) models of the instant application are recited as performing “different things,” their function is identical. Each of the models are given training data which is transformed into a format which is then used to identify similar data. The type of input and sought data are functionally irrelevant to the actual claimed function of using trained embeddings to identify similar patterns. Put another way, “malicious code” and “protection code” could be simply swapped with any number of types of code (transaction processing code, network communication code, access control code, etc.) and it would not fundamentally alter the function of the models. This rejection is maintained; however, in the interest of compact prosecution, the rejection is updated with different citations from the prior art to more closely map to the interpretation of the claims argued by Applicant.
Regarding the argument directed to claim 15:
Due to the change in scope of the claim, the previous rejection is withdrawn. However, examiner notes that it is given grounds of rejection with the same prior art of Stussi. Stussi teaches the use of multiple models performing different detections in a continuous integration / continuous development (CI/CD) pipeline. Examiner notes that both “live service” and “development pipelines” are represented in a CI/CD pipeline, where development is ongoing and live service software is continually updated over time.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contain(s) subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding claim(s) 1, 8, and 15:
Claim 1 recites, “… training … a first machine learning model using the training data to generate malicious code embeddings”. Claim(s) 8 and 15 recite(s) similar language. The specification fails to adequately describe this limitation. While ¶ 0040 of the specification discusses the types of embeddings that may be used, it does not provide an algorithm or otherwise describe how these embeddings are generated. This rejection can be overcome by amending the claim(s) such that they recite only that subject matter which is has adequate description in the original disclosure.
These rejections can be overcome by amending the claim(s) such that they recite only that subject matter which is has adequate description in the original disclosure.
It is important to note that in regards to an adequate written description, “It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015)” (MPEP 2161.01). This is equally true of Artificial Intelligence (AI) and Machine Learning (ML) models, where it is not sufficient to simply recite what the model does; the specification must explicitly teach how a function is achieved (i.e. training data used to train the model, how the training data is labeled, how the model is evaluated, etc.). While an applicant does not need to describe the inner workings of the model, they are required to describe how the model is configured to be able to perform claimed functions.
Regarding claims 2-7, 9-14, and 16-20:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(a) because the specification, while being enabling for the use of Large Language Models (LLMs) for code detection, does not reasonably provide enablement for machine learning (ML) models in general. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make or use the invention commensurate in scope with these claims.
Regarding claim(s) 1, 8, and 15:
Claim 1 recites “… training, by the processor, a first machine learning model …”, and “… training, by the processor, a second machine learning model …”. Claim(s) 8 and 15 recite(s) similar subject matter. The scope of this limitation is not enabled by the specification because it encompasses all known forms of ML models, whereas the scope of enablement provided in the specification is limited to LLMs. This rejection can be overcome by amending the claim(s) such that they recite only that subject matter which is enabled in scope by the specification of the original disclosure.
The test of enablement is whether one reasonably skilled in the art could make or use the invention from the disclosures in the patent coupled with information known in the art without undue experimentation; United States v. Telectronics, Inc., 857 F.2d 778, 785, 8 USPQ2d 1217, 1223 (Fed. Cir. 1988). The factors to be considered when determining whether there is sufficient evidence to support a determination that a disclosure does not satisfy the enablement requirement and whether any necessary experimentation is “undue” include, but are not limited to: (a) the breadth of the claims; (b) the nature of the invention; (c) the state of the prior art; (d) the level of one of ordinary skill; (e) the level of predictability in the art; (f) the amount of direction provided by the inventor; (g) the existence of working examples; and (h) the quantity of experimentation needed to make or use the invention based on the content of the disclosure; In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988).
As to (a) the breadth of the claims, the current draft of the claims, through the recitation of simply “machine learning (ML) model,” encompass all forms of ML models. While the specification provides explanations as to the use of Large Language Models (LLMs) and classifiers, it does not provide sufficient support for the use of other models which are encompassed by the overly broad claims. The claims require an undue amount of experimentation in order to apply the invention to other forms of ML models.
As to (b) the nature of the invention, the current state of the art regarding the use of ML models is expansive. So much so that despite a relatively high level of knowledge in the art, it would be unreasonable to expect one of ordinary skill in the art to be able to use any existing ML model to make or use the invention. The resulting amount of needed experimentation would be undue.
As to (c) the state of the prior art and (d) the level of skill in the art, due to the multitudes of possible ML models represented in the prior art, it would be unreasonable to suppose one of ordinary skill in the art would have the skill to practice the invention as claimed, and would require undue experimentation to practice the invention using models other than those provided for in the specification.
As to (e) the level of predictability in the art and (f) the amount of direction provided by the inventor, the computer cryptography arts are generally considered predictable. However, similarly to comments directed to factor (b) above, the sheer number of available ML models available in the art would require a substantial amount of guidance or direction in the claims that teaches exactly how to make or use the invention. Because the specification limits this direction to a very limited number of embodiments, the claims require undue experimentation by one skilled in the art.
As to the (g) existence of working examples, no working examples are provided in the instant application. This does not decrease the undue amount of experimentation that would be required by one of ordinary skill in the art.
As to the (h) quantity of experimentation needed, there is no particular evidence in the record to indicate the quantity of experimentation that one of ordinary skill in the art would need to implement the present invention as claimed. However, analysis of this factor in light of the other factors present suggest the amount of experimentation required to make and use the invention is undue.
The majority of factors for which there is evidence suggest that undue experimentation is required. After weighing all of the factors and all the evidence of record, the totality of the evidence suggests that it would require undue experimentation to make and use the claimed invention within the scope claimed.
Regarding claims 2-7, 9-14, and 16-20:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 8, 10, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over STUSSI et al (Doc ID US 20240419793 A1), and further in view of CARSON (Doc ID US 20190251251 A1).
Regarding claim 1:
Examiner notes that the methods described in the specification and claims regarding calculating the similarity of input code to “malicious code” and “protection code” are functionally identical. That is, the claimed machine learning (ML) models are, in essence, trained to recognize code similar to whatever code on which the models are trained. As such, when it comes to calculating similarity of input code to malicious/protection code, any prior art which can determine the similarity of input code to code which was provided as training data may read on the claims. The prior art mappings below are updated to illustrate the use of multiple models performing different identifications.
STUSSI teaches:
A computer implemented method for software threat analysis, comprising: receiving, by a threat management system comprising at least one processor and memory, source code of an application under test ([0112] "… the processor of malicious software detection system 305 receives a software package including software components.");
storing, in the memory, (i) training data comprising malicious-code features, threat- protection-code features, and vector embeddings derived from threat-intelligence feeds ([0098] "… to train a machine learning model ..., a large dataset of source code and community data is required. The large dataset includes both benign and malicious software packages. … and the community data may include ... online forums, mailing lists, social media platforms, marketplaces etc. ... this data is preprocessed ..., converting the data into a format that can be fed into a machine learning model ..."), and
training, by the processor, a first machine learning model using the training data to generate malicious code embeddings and to identify malicious code patterns within the application under test ([0108] "... the processor of malicious software detection system 305 collects, parses and labels parts of a dataset containing software components as either malicious or benign." and [0109] "... the processor of malicious software detection system 305 creates machine learning models to classify the malicious software components ...");
training, by the processor, a second machine learning model using the training data to generate protection code embeddings and to identify threat protection code patterns within the application under test ([0109] "After collecting and labeling the parts of the dataset containing community behavior as being suspicious or not suspicious at step 1112, … the processor of malicious software detection system 305 creates machine learning models to classify the suspicious community behavior.");
computing, by the processor, a first cosine similarity between a vector embedding of the application under test and malicious code embeddings stored in a malicious code vector database to determine a first likelihood that the application under test includes malicious code ([0112] "… the processor of malicious software detection system 305 identifies one or more software components ... as malicious based on a comparison between the software components ... and each of the collected one or more known malicious software component classifiers ..." and [0132] "… Cosine similarity was used for computing similarities.");
computing, by the processor, a second cosine similarity between a vector embedding of the application under test and protection code embeddings stored in a protection code vector database to determine a second likelihood that the application under test includes threat protection code ([0112] "... the processor of malicious software detection system 305 identifies one or more software components ... as malicious based on a comparison between the software components ... and each of the collected one or more ... suspicious community behavior classifiers. and [0132] "… Cosine similarity was used for computing similarities.");
CARSON teaches the following limitation(s) not taught by STUSSI:
(ii) a plurality of promotion rules defining threshold similarity values and confidence levels for code promotion decisions ([0072] "… The policy may specify which countermeasures or actions to perform depending on the one or more scores calculated by the learning engine.");
applying, by the processor, the plurality of promotion rules to the first likelihood and the second likelihood to determine whether the application under test satisfies a promotion criterion ([0072] "Using the scores indicating the likelihood that the executable contains malware, the rule engine of the malware detection system may perform one or more countermeasures based on a policy."); and
automatically promoting, blocking, or generating a remediation alert for the application under test based on the applied promotion rules, wherein the remediation alert identifies code features recommended to mitigate detected skimming threats ([0072] "… The policy may for example specify automatically blocking an operation of the executable when the one or more scores indicate high likelihood that the executable contains malware.").
Training ML models to calculate similarities in inputted code to code on which it was trained is a known technique in the art, as demonstrated by STUSSI. Further, applying rules to the results of code similarities to include blocking an application determined likely to contain malicious code is a known technique in the art, as demonstrated by CARSON. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the code similarity calculation of STUSSI with the code similarity policy assessment of CARSON with the motivation to perform actions based on a similarity detected between a given code sample and training data.
Regarding claim 3:
The combination of STUSSI and CARSON teaches:
The computer implemented method of claim 1, further comprising crawling one or more threat intelligence feeds to obtain the training data (STUSSI [0098] "… the community data may include ... online forums, mailing lists, social media platforms, marketplaces etc. ... this data is preprocessed ...").
Regarding claims 8 and 10:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1 and 3 above.
Regarding claim 15:
STUSSI teaches:
A non-transitory computer-readable device having instructions stored thereon that, when executed by at least one computing device, cause the at least one computing device to perform operations comprising ([0010] "... one or more processors and a memory … storing therein a set of instructions which … causes the one or more processors to detect malicious software packages …"):
training a first machine learning model using the training data to generate malicious code embeddings and to identify malicious code patterns within the application under test, the first machine learning model being deployed within a live service pipeline ([0108] "... the processor of malicious software detection system 305 collects, parses and labels parts of a dataset containing software components as either malicious or benign." and [0109] "... the processor of malicious software detection system 305 creates machine learning models to classify the malicious software components ...");
training a second machine learning model using the training data to generate threat protection code embeddings and to identify threat protection code patterns within the application under test, the second machine learning model being different from the first machine learning model and deployed at a development pipeline for preventing security threats prior to production ([0058] "... suspicious behavior from the community such as, but not limited to, anomalies in commit and release activities, mismatches between packaged software in registries and source code repositories, etc." and [0109] "After collecting and labeling the parts of the dataset containing community behavior as being suspicious or not suspicious at step 1112, … the processor of malicious software detection system 305 creates machine learning models to classify the suspicious community behavior.");
Examiner notes that STUSSI in a continuous integration / continuous development (CI/CD) environment. Components of software patches being deployed meets the broadest reasonable interpretation of a “live service pipeline.” Similarly, “community behavior,” meets the broadest reasonable interpretation of a “development pipeline.”
The remainder of this claim’s limitations are rejected with the same prior art mapping and justification, mutatis mutandis, as its counterpart claims 1 and 8.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over STUSSI et al (Doc ID US 20240419793 A1) and CARSON (Doc ID US 20190251251 A1) as applied to claims 1, 8, and 15 above, and further in view of HELYAR et al (Doc ID US 20240152624 A1).
Regarding claim 2:
The combination of STUSSI and CARSON teaches:
The non-transitory computer-readable device of claim 15,
HELYAR teaches the following limitation(s) not taught by the combination of STUSSI and CARSON:
wherein the first machine learning model and the second machine learning model are large language models (LLMs (HELYAR [0023] "… solutions described herein leverage large language models to implement an artificial intelligence … code vulnerability detection tool …")).
Utilizing Large Language Models (LLM) in malicious code detection is a known technique in the art, as demonstrated by HELYAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the malicious code similarity detection of STUSSI and CARSON with the LLM of HELYAR with the motivation to make use of the flexibility of an LLM where tokenized inputs used by LLMs can be used to calculate similarities.
Regarding claims 9 and 16:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 2 above.
Claims 4, 5, 11, 12, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over STUSSI et al (Doc ID US 20240419793 A1) and CARSON (Doc ID US 20190251251 A1) as applied to claims 1, 8, and 15 above, and further in view of HINES et al (Doc ID US 20210120013 A1).
Regarding claim 4:
The combination of STUSSI and CARSON teaches:
The computer implemented method of claim 1,
HINES teaches the following limitation(s) not taught by the combination of STUSSI and CARSON:
wherein the training data includes connections to rogue domains, digital skimmer scripts, or indicators of compromised payloads ([0004] "… examples of IPRIDs include … Internet Protocol (IP) addresses, domain names …" and [0305] "... the convolutional neural network 404 is trained using ... at least three of the following aggregate features 308: a count 736 of distinct submissions, a count 740 of distinct final hostnames, a count 744 of submissions of a particular IPRID, ... a count 752 of redirects to a particular IPRID ...").
Examiner notes that the term "rogue domain" is interpreted as a domain taking unauthorized redirects.
Training a machine learning model to recognize DNS based attacks such as redirects to a domain is a known technique in the art, as demonstrated by HINES. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the malicious code similarity detection of STUSSI and CARSON with the training data of HINES with the motivation to provide the model with specific training data to be able to recognize a targeted set of attacks.
Regarding claim 5:
The combination of STUSSI and CARSON teaches:
The computer implemented method of claim 1,
HINES teaches the following limitation(s) not taught by the combination of STUSSI and CARSON:
wherein the training data is stored as a vector database including rogue domain vector embeddings, digital skimmer vector embeddings, or indicators of compromise vector embeddings ([0315] "... training data 304 that is characterized in at least one of the following ways: ... the training data is organized in vector space planes 332 that correspond to data sources, the training data is organized 1410 in vector space planes 332 that correspond to data meanings ...").
Training a machine learning model to recognize DNS based attacks such as redirects to a domain is a known technique in the art, as demonstrated by HINES. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the malicious code similarity detection of STUSSI and CARSON with the training data of HINES with the motivation to provide the model with specific training data to be able to recognize a targeted set of attacks.
Regarding claims 11, 12, 17, and 18:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 4 and 5 above.
Claims 6, 7, 13, 14, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over STUSSI et al (Doc ID US 20240419793 A1) and CARSON (Doc ID US 20190251251 A1) as applied to claims 1, 8, and 15 above, and further in view of DHOKIA et al (Doc ID US 20220247790 A1).
Regarding claim 6:
The combination of STUSSI and CARSON teaches:
The computer implemented method of claim 1,
DHOKIA teaches the following limitation(s) not taught by the combination of STUSSI and CARSON:
wherein the training data includes content security policies, sub-resource integrity hashes, or HTTP security headers ([0056] "… The training data 830 may include one or more of … access policy statistics, model access control policies …").
Training a machine learning model on security policies is a known technique in the art, as demonstrated by DHOKIA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the malicious code similarity detection of STUSSI and CARSON with the training data of DHOKIA with the motivation to provide the model with specific training data to be able to recognize security policies in a system for which it is performing code-scanning.
Regarding claim 7:
The combination of STUSSI and CARSON teaches:
The computer implemented method of claim 1,
DHOKIA teaches the following limitation(s) not taught by the combination of STUSSI and CARSON:
The computer implemented method of claim 1, wherein the training data is stored as a vector database including content security policy vector embeddings, sub-resource integrity hash vector embeddings, or HTTP security header vector embeddings ([0056] "… The training data 830 may include one or more of … access policy statistics, model access control policies …" and [0057] "Selector module 850 selects training vector 860 from the training data 830.").
Training a machine learning model on security policies is a known technique in the art, as demonstrated by DHOKIA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the malicious code similarity detection of STUSSI and CARSON with the training data of DHOKIA with the motivation to provide the model with specific training data to be able to recognize security policies in a system for which it is performing code-scanning.
Regarding claims 13, 14, 19, and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 6 and 7 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, 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 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.
/BB/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights