DETAILED ACTION
Response to Amendment
This action is in response to amendment filed April 06, 2026 for the application # 18/788,429 filed on July 30, 2024. Claims 1-14, 16-18, and 20-23 are pending and are directed toward AUTOMATED DETECTION OF KNOWN VULNERABILITIES.
Any claim objection/rejection not repeated below is withdrawn due to Applicant's amendment.
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 . 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 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.
Response to Arguments
Applicant’s arguments with regards to claims 1-14, 16-18, and 20-23 have been fully considered, but they are not persuasive in regards to claims 1-14, 16-18, and 20-21, and moot in regards to new claims 22, and 23 because of new grounds of rejection.
“in simple terms” argument – Applicant argues that stated in simple terms, the claims do not use machine learning to ask, "Does this source code statistically look vulnerable?" (REMARKS, page 8).
Response: Contrary to the Applicant assertion, this is exactly what is claimed. See “automated detection of known vulnerabilities in a static test of software” (Claim 1).
“semantic bridge” argument – Applicant argues that the claims recite a specific technical use of the machine-learning model as a semantic bridge between two fundamentally different technical domains: (i) unstructured, human-readable vulnerability descriptions retrieved from a vulnerability database, and (ii) a structured, machine-readable representation of software, namely the control-flow representation of the code. (REMARKS, page 8).
Response: no “semantic bridge” limitation was claimed or disclosed in Specification.
“achieves a reduction” argument – Applicant argues that as described in the specification, this approach achieves a reduction of false positives to approximately 3-10% (see, e.g., par. 5), which constitutes a substantial and unexpected improvement over conventional techniques. This improvement further supports the non-obviousness of the claimed subject matter. (REMARKS, page 8).
Response: no specific rate of false positives is currently claimed (Claim 1).
“external vulnerability databases” argument – Applicant argues that Olson does not describe applying the machine-learning model to descriptions of vulnerabilities retrieved from external vulnerability databases. (REMARKS, page 9).
Response: Examiner points Applicant attention that this functionality was explicitly disclosed by Olson [0086]: “The software component analysis tool optionally links an open source library and libraries with known security vulnerabilities into a common vulnerabilities and exposures (CVEs) database. The software component analysis tool scans the source code to find libraries used by the customers. The libraries contain known vulnerabilities to detect the third security vulnerability with low signal-noise ratio.”
For all other “Olson also does not disclose” assertions Examiner points Applicant attention to citations of prior art used in instant Office action. In view of provided references, the Applicant’s arguments seems to be as logically incoherent. For example, it is known that any software code is a control-flow data structure.
Therefore, Examiner maintains rejections.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 22 and 23 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Both claims 22 and 23 are construed in alternative to the independent Claim 1 Examiner suggestion to replace “comprises” with “further comprises”. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
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.
Claims 1, 3-17, and 19-21 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Olson et al. (US 2021/0056211, Pub. Date: Feb. 25, 2021), hereinafter referred to as Olson.
As per claim 1, Olson teaches a computer-implemented method for automated detection of known vulnerabilities in a static test of software (a method for automatically detecting a security vulnerability in a source code using a machine learning model. Olson, [0001]), the method comprising the following steps:
extracting a data structure comprising a control-flow representation of a code of the software (generating a call graph by integrating the abstract syntax tree (AST) with a control and a dataflow of the source code, wherein the call graph represents calling relationships between subroutines in a computer program. Olson, [0092]);
identifying one or more software components on which the software depends based on the code, and/or the extracted data structure, and/or a software bill of materials of the software (Optionally, in the method, the library analysis is performed using a software component analysis tool. Olson, [0030]);
evaluating, for at least one identified software component (Optionally, the method comprises detecting a second security vulnerability before compilation of the source code by performing a static analysis on a vectorized call graph. Olson, [0017]), whether the respective software component is associated with any of known vulnerabilities by consulting a predefined database of vulnerabilities of software components (The software component analysis tool optionally links an open source library and libraries with known security vulnerabilities into a common vulnerabilities and exposures (CVEs) database. The software component analysis tool scans the source code to find libraries used by the customers. The libraries contain known vulnerabilities to detect the third security vulnerability with low signal-noise ratio. Olson, [0086]), thereby identifying one or more potentially vulnerable software components (Optionally, the method comprises detecting a third security vulnerability during the compilation of the source code by performing a library analysis on the vectorized call graph. Olson, [0018]);
and, for each of at least one potentially vulnerable software components: applying a machine learning model to a description of a respective one or more of the known vulnerabilities, the description being retrieved from the database, (Optionally, the method comprises performing, using the machine learning model, a post-analysis on the first security vulnerability, the second security vulnerability, and the third security vulnerability to predict a final security vulnerability. Optionally, the method comprises performing, using the machine learning model, a post-analysis on the first security vulnerability, the second security vulnerability, and the third security vulnerability to predict a final security vulnerability. Olson, [0019]), wherein the machine learning model is trained and configured to determine from the description at least one root cause of respective known vulnerability indicative of a program element responsible for the respective known vulnerability (training the machine learning model on a labeled source code to predict a presence or an absence of the first security vulnerability. Olson, [0015]), see also the method comprises processing the first input on the final security vulnerability, wherein the first input comprises a feedback associated with the final security vulnerability. Olson, [0025]); and
evaluating the respective potentially vulnerable software component as vulnerable or as not vulnerable by determining, from the control-flow representation of the code, whether the determined at least one root cause is present in the software (using a machine learning (ML) model to perform a ML based analysis on an abstract syntax tree (AST) for detecting a first security vulnerability over a static source code, Olson, [0015]).
As per claim 3, Olson teaches the method according to claim 1, wherein the method is carried out in an electronic programming environment (The present disclosure also provides a computer program product comprising instructions to cause the system to carry out the above-described method. Olson, [0050]).
As per claim 4, Olson teaches the method according to claim 1, further comprising: outputting at least one software component evaluated as vulnerable via a user interface (Optionally, the method comprises providing the final security vulnerability to a user on a user device. Olson, [0027]).
As per claim 5, Olson teaches the method according to claim 1, wherein the code includes a source code (obtaining the source code from a client codebase, wherein the client codebase is a complete or an incomplete body of the source code for a given software program or an application, Olson, [0010]).
As per claim 6, Olson teaches the method according to claim 1, wherein the code includes compiled binary code (Optionally, in the system, the one or more processors is configured to detect a third security vulnerability during the compilation of the source code by performing a library analysis on the vectorized call graph. Olson, [0041]).
As per claim 7, Olson teaches the method according to claim 1, wherein the data structure includes an abstract syntax tree (using a machine learning (ML) model to perform a ML based analysis on an abstract syntax tree (AST) for detecting a first security vulnerability over a static source code, Olson, [0011]).
As per claim 8, Olson teaches the method according to claim 1, wherein the data structure includes a control flow graph (Optionally, the method comprises generating a call graph by integrating the abstract syntax tree (AST) with a control and a dataflow of the source code, wherein the call graph represents calling relationships between subroutines in a computer program. Olson, [0022]).
As per claim 9, Olson teaches the method according to claim 1, wherein extracting the data structure of the code includes generating an abstract syntax tree of the code and generating a control flow graph from the abstract syntax tree (Optionally, the method comprises generating a call graph by integrating the abstract syntax tree (AST) with a control and a dataflow of the source code, wherein the call graph represents calling relationships between subroutines in a computer program. Olson, [0022]).
As per claim 10, Olson teaches the method according to claim 1, wherein each of the external software component includes a software package and/or a function and/or a library (the source code comprises at least one of a method, a class, a package or variable names along with comments and string literals. Olson, [0029], see also The library analysis is performed using a software component analysis tool. Olson, [0084]).
As per claim 11, Olson teaches the method according to claim 1, wherein the evaluating, for at least one identified software component, whether the software component is associated with a known vulnerability, is based on a comparison of identifiers and/or metadata (The machine learning (ML) model optionally manages integration with client codebases and securely stores the source code and associated metadata. Olson, [0074]).
As per claim 12, Olson teaches the method according to claim 11, wherein each identifier includes a unique name of a software package and/or a function and/or a library (Every aspect of the source code (e.g. a method, a class, a package, and a variable name along with comments and string literals) is infused with names and language that are meant to confer meaning and intention to programmers. Olson, [0079]).
As per claim 13, Olson teaches the method according to claim 11, wherein the metadata includes a version number and/or a type of use and/or a configuration and/or a build option (For each of these components, the SCA optionally identifies any open security common vulnerabilities and exposures (CVEs), licenses, and out-of-date library versions. Olson, [0085]).
As per claim 14, Olson teaches the method according to claim 1, wherein the machine learning model includes a foundation model (The machine learning model is optionally trained in two phases. In first phase, the machine learning model is optionally pre-trained on a large corpus of unlabeled source code along with a task of predicting the next sub-token in a random initial subsequence of a training example. Olson, [0078]).
As per claim 16, Olson teaches the method according to claim 14, wherein the machine learning model includes a large language model (LLM) (the machine learning model is optionally pre-trained on a large corpus of unlabeled source code, Olson, [0078]).
As per claim 17, Olson teaches the method according to claim 1, wherein the at least one root cause is a function, and wherein the function is contained in the description (The first/pre-training phase is unsupervised which allows the machine learning model to learn a deep, distributed representation of function-level ASTs along with a learned embedding of AST tokens. Olson, [0078]).
Claims 20 and 21 have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of anticipation as used above.
As per claim 22, Olson teaches the method according to claim 1, wherein applying the machine learning model to the description of the respective one or more of the known vulnerabilities comprises generating a prompt and inputting the prompt together with the description to the machine learning model, the prompt being interpretable by the machine learning model as an instruction to determine from the description the at least one root cause of the respective known vulnerability (For example, the machine learning model utilizes the advantages of the natural language aspects of the source code that are invisible to static analysis tools. Every aspect of the source code (e.g. a method, a class, a package, and a variable name along with comments and string literals) is infused with names and language that are meant to confer meaning and intention to programmers. The natural language aspects are optionally leveraged to develop an intelligent static analysis tool. By analyzing and learning a statistical model of the natural language aspects of the source code, the machine learning model is able to generalize to patterns and APIs not seen during training or not known/built-in to the static analysis tool. The machine learning model optionally uses these features and the natural language aspects to detect and assign more emphasis to examples that are similar to true vulnerabilities, in the same way, which human intuition does. Olson, [0079]).
As per claim 23, Olson teaches the method according to claim 1, wherein the determining of the at least one root cause of the respective known vulnerability comprises extracting from the description an identifier of a function, method, or other program element constituting the root cause of the respective known vulnerability (The software component analysis tool optionally links an open source library and libraries with known security vulnerabilities into a common vulnerabilities and exposures (CVEs) database. The software component analysis tool scans the source code to find libraries used by the customers. The libraries contain known vulnerabilities to detect the third security vulnerability with low signal-noise ratio. Olson, [0080]).
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 2 is rejected under 35 U.S.C. 103 as being unpatentable over Olson et al. (US 2021/0056211, Pub. Date: Feb. 25, 2021), in view of (ISO 26262-6, 2018, 15 pages), hereinafter referred to as Olson and ISO.
As per claim 2, Olson teaches the method according to claim 1, but does not teach vehicle, ISO however teaches wherein the software is configured to control and/or regulate and/or monitor a computing unit of a vehicle (This document is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production road vehicles, ISO, page 1 and This document describes a framework for functional safety to assist the development of safety related E/E systems. This framework is intended to be used to integrate functional safety activities into a company-specific development framework. Some requirements have a clear technical focus to implement functional safety into a product; others address the development process and can therefore be seen as process requirements in order to demonstrate the capability of an organization with respect to functional safety. ISO, page 1).
Olson in view of ISO are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Olson in view of ISO. This would have been desirable because This document addresses possible hazards caused by malfunctioning behaviour of safety-related E/E systems, including interaction of these systems. (ISO, page 1).
Claims 18 is rejected under 35 U.S.C. 103 as being unpatentable over Olson et al. (US 2021/0056211, Pub. Date: Feb. 25, 2021), in view of ZHANG et al. (US 2024/0256423, Filed: Jan. 26, 2023), hereinafter referred to as Olson and ZHANG.
As per claim 18, Olson teaches the method according claim 22, and further teachers input to ML, which is a prompt by definition, to extract malicious code, however does not explicitly teach wherein the prompt includes a linguistic instruction, ZHANG however teaches that the wherein the prompt includes a linguistic instruction to the large language model (LLM) directed to extract one or more root causes from the description (generating 1006 a multimodal prompt which includes at least two of the following: a chunk 920 or other portion of the syntactically correct version of the source code, a natural language description 706 of a task to be accomplished by any improved version of the source code, or a test case 704 to be satisfied by the improved version of the source code; submitting 1008 the multimodal prompt to a large language machine learning model trained on source codes (LLMC) 208; obtaining 1010 candidate versions of the improved version of the source code from the LLMC; selecting 1012 a valid candidate version of the improved version of the source code from among the candidate versions; and outputting 1014 the selected valid candidate version. ZHANG, [0054]).
Olson in view of ZHANG are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Olson in view of ZHANG. This would have been desirable because the process is suitable for improving programs written by students in at least one of the following ways: an instructor-provided alternative to the selected valid candidate version is included 1110 in a prompt to the LLMC; an instructor-provided natural language description of the task to be accomplished by any improved version of the source code is included 1110 in a prompt to the LLMC; or an instructor-provided edge test case is included 1110 in a prompt to the LLMC (ZHANG, [0066]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLEG KORSAK whose telephone number is (571)270-1938. The examiner can normally be reached on 5:00 AM- 4:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached on (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/OLEG KORSAK/Primary Examiner, Art Unit 2492
Prosecution Insights