DETAILED ACTION
This communication is responsive to the application # 18/788,429 filed on July 30, 2024. Claims 1-21 are pending and are directed toward AUTOMATED DETECTION OF KNOWN VULNERABILITIES.
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.
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 of a code of the software (At a step 302, the source code is obtained from a client codebase. the client codebase is a complete or an incomplete body of the source code for a given software program or an application. Olson, [0129]);
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, whether the software component is associated with a known vulnerability (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]), wherein one or more potentially vulnerable software components result (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]);
applying, for at least one potentially vulnerable software component, a machine learning model to a description associated with the known 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. 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 at least one root cause from at least the description and a prompt (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 at least one potentially vulnerable software component as vulnerable or as not vulnerable based on the at least one root cause and the extracted data structure (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 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 15, Olson teaches the method according to claim 1, wherein the prompt includes an instruction to the machine learning model directed to extract one or more root causes from the description (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 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]).
As per claim 19, Olson teaches the method according to claim 17, wherein the evaluating of the at least one potentially vulnerable software component as vulnerable or as not vulnerable based on the at least one root cause and the extracted data structure includes checking whether the function associated with the at least one root cause is contained in the extracted data structure (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]).
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.
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 16, 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
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 Monday-Friday 7:30am - 5:00pm EST.
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