Detailed Action
This Final Office Action is in response to amendment filed on 10/08/2025. Claims
1, 2, and 13 have been amended. No claim has been cancelled. Claims 1 – 20 remain pending in the application.
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 .
Response to Amendment
The amended filed 10/08/2025 has been entered. See above on lines 1-3
of the office action.
The claim rejection 35 U.S.C § 102 to claims 2 and 10 has been withdrawn in view of the received amendment.
Response to Arguments
Remarks regarding rejections under 35 U.S.C § 103 filed 09/23/2025 Applicant’s amendment to Independent Claims 1, 2, and 13 and arguments are carefully considered and are persuasive. However, upon further consideration, arguments are moot in view of new found prior art.
With respect to applicant’s argument to the remaining dependent claims 3 -12, and 14 – 20 on pages 13, and 14 of the remark, the applicant is relying on the newly added amendments of the independent claims1, 2, and 13. Please see examiner’s response above and the detail of the rejection below.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in further view of Zhu et al. (CN-117521072-A hereafter Zhu).
Regarding claim 2 Wareus disclose a method for detecting vulnerabilities in software in real time, comprising (Wareus see par.0044: “methods for accurately identifying functions in software code that represent true vulnerabilities, i.e., a vulnerability that can actually arise during execution of the software code.”.):
receiving a training dataset, comprising first source code, first runtime data flow associated with transformations and passage of data during an execution of the first source code, and a first set of sample vulnerable libraries associated with the first source code (see Wareus par.0046: “ The vulnerability and exposure detection system 305 can then relate known vulnerabilities to the software source code 310 (first source code). This can be done, for example, using one or more trained models 325 (Training dataset) which define, for example, relationships between information from the vulnerability data sources 320 (first set of sample vulnerable libraries) to portions of software code.”, Par.0049: “Using the identified patch commits, the vulnerability and exposure detection system 305 can, through analysis of the changed files in those particular commits, label the changed functions/methods/classes of the source code 310 as the vulnerable functionality with a vulnerability symbol. These symbols can comprise any graphical and/or textual indicator made to be uniquely identified, which can be a different process for each programming language, but can comprise constructing a call graph 340 (first runtime dataflow) such as an abstract syntax tree for those changed files, and appending the namespace to the corresponding functions/methods/classes that match a call graph representation of that particular language.”, Par.0044: “A call graph can be derived for the software code based on the identified one or more vulnerable functions. Each of the identified one or more vulnerable functions can be indicated in the call graph by a vulnerability symbol. A determination can be made as to whether each identified one or more vulnerable functions is a true vulnerability by analyzing the call graph. A function can be determined to be a true vulnerability when the vulnerable function, represented by a vulnerability symbol in the call graph, is encountered when traversing the call graph.”);
using the training dataset, training a vulnerability detection model to detect vulnerable software libraries in the first source code (see Wareus par.0051-52: “identifying vulnerable functions in software code can comprise collecting 405 information identifying one or more known CVEs from any of a number of possible sources as described above. One or more vulnerable functions in the software code can then be identified 410 based on relationships between the collected information identifying the one or more known CVEs and the functions in the software code. Additional details of an exemplary process for identifying 410 vulnerable functions.”, par.0056: “identifying the one or more vulnerable functions in the software code can be based on a trained model and can comprise identifying 505 a patch commit for each identified one or more vulnerable functions. In some cases, identifying 505 the patch commit for each identified one or more vulnerable function can further comprise analyzing 510 metadata for each identified one or more vulnerable function using a trained model.”);
Wareus appear to be silence however Sumedrea teaches
receiving second source code being tested in a development environment (see Sumedrea par.0043: “Training input prompt generator 140 receives new refactoring techniques descriptions 360”, new training source code 365,(second source code.);
generating a set of replacement libraries to replace the set of known vulnerable software libraries and the set of novel vulnerable software libraries (see Sumedrea par.0036: “Security code analysis copilot AIM 190 produces candidate samples 260, which may be various options to refactor initial source code 210. Security code analysis copilot AIM 190 produces multiple candidate samples 260 to increases the probability that the refactored source code is executable”, par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”); and
for each vulnerable library in the set of novel vulnerable software libraries and the set of known vulnerable software libraries, in response to detecting a replacement library in the set of replacement libraries (see Sumedrea par.0047: “the vulnerability is identified by a vulnerability scanner. The vulnerability scanner determines one or more properties of the initial source code, and identifies, based on the one or more properties, the vulnerability from a plurality of vulnerabilities included in a global vulnerability database”, par.0051: “processing logic detects a zero-day vulnerability corresponding to the initial source code, wherein the AIM has not been trained to determine whether the initial source code comprises the zero-day vulnerability but is able to detect the zero-day vulnerability due to its similarities with other vulnerabilities. Processing logic determines one or more zero-day refactoring operations
corresponding to the zero-day vulnerability, and generates a new prompt comprising the initial source code,”), replacing the vulnerable library with an associated replacement library (see Sumedrea par.0050: “the AIM produces a plurality of refactored candidate samples. Processing logic tests at least a portion of code included in each of the plurality of refactored candidate samples to produce one or more test results.”, par.0051: “In response to inputting the new prompt into the AIM, processing logic determines, by the AIM, that the initial source code comprises the zero-day vulnerability. Processing logic then uses the AIM to remove the zero-day vulnerability from the initial source code to produce a new refactored source code.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus teaching “A determination 420 can then be made as to whether each identified vulnerable function is a true vulnerability by analyzing the call graph. Additional details of an exemplary process for determining whether a vulnerability is a true vulnerability”, (see Wareus par.0021) with Sumedrea teaching “the approach evaluates the initial source code by the AIM prior to generating the prompt. The approach identifies, by the AIM in response to evaluating the initial source code, a plurality of potential vulnerabilities that correspond to the initial source code. The approach generates a new prompt comprising the initial source code and the plurality of potential vulnerabilities. In response to inputting the new prompt into the AIM, the approach determines, using the AIM, that the initial source code comprises a first vulnerability from the plurality of potential vulnerabilities. The approach removes, using the AIM, the first vulnerability from the initial source code to produce a new refactored source code.”, (see Sumedrea par.0021).
Wareus in view of Sumedrea appear silence however Zhu teaches
collecting, through the development environment, the second source code and second runtime data flow associated with transformations and passage of data during an execution of the second source code (see Zhu par.10: “collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes;”);
processing the second source code and the second runtime data flow using the vulnerability detection model to identify a set of novel vulnerable software libraries and a set of known vulnerable software libraries in the second source code, wherein the set of novel vulnerable software libraries is not in the first set of sample vulnerable libraries, and wherein the set of known vulnerable software libraries is in the first set of sample vulnerable libraries and used in training the vulnerability detection model (see Zhu par. 52-57: “step S1: collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes; step S2: preprocessing the assembly code, and slicing the assembly code into a plurality of code segments by taking a function as an element unit; step S3: converting the code segments into feature vectors; step S4: constructing a vulnerability detection model, and training the vulnerability detection model by utilizing the feature vector until the model converges; step S5: and performing vulnerability detection on the binary file to be detected by using the trained vulnerability detection model. It can be appreciated that in the vulnerability detection method of the binary file of the present embodiment, sample data in a vulnerability database is collected first and compiled into a source file thereof to obtain a binary file required for training a neural network, and then the binary file is decompiled into assembly code to facilitate analysis and processing of the binary file.”, par. 85: “The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea teaching described above with Zhu teaching “the vulnerability detection method of binary file of the present invention has at least the following advantages: … The feature extraction method provided by the invention can be better combined with the corresponding fusion neural network, and higher accuracy and efficiency can be obtained compared with other neural network training methods. In addition, compared with other classification methods, the method provided by the invention can more accurately identify the specific vulnerability type. The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”, (see Zhu par. 85).
Regarding claim 10 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Sumedrea further teaches further comprising:
and
generating suggestions to replace the set of vulnerable software functions. (See Sumedrea par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”).
Wareus in view of Sumedrea appear to be silence however Zhu teaches
processing the second source code and the second runtime data flow using the vulnerability detection model to identify a set of vulnerable software functions in the second source code (see Zhu par. 52-57: “step S1: collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes; step S2: preprocessing the assembly code, and slicing the assembly code into a plurality of code segments by taking a function as an element unit; step S3: converting the code segments into feature vectors; step S4: constructing a vulnerability detection model, and training the vulnerability detection model by utilizing the feature vector until the model converges; step S5: and performing vulnerability detection on the binary file to be detected by using the trained vulnerability detection model. It can be appreciated that in the vulnerability detection method of the binary file of the present embodiment, sample data in a vulnerability database is collected first and compiled into a source file thereof to obtain a binary file required for training a neural network, and then the binary file is decompiled into assembly code to facilitate analysis and processing of the binary file.”, par. 85: “The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea teaching “the AIM produces a plurality of refactored candidate samples. Processing logic tests at least a portion of code included in each of the plurality of refactored candidate samples to produce one or more test results. Processing logic then constructs the refactored source code based on the one or more test results.”, (see Sumedrea par.0050), with Zhu teaching “the vulnerability detection method of binary file of the present invention has at least the following advantages: … The feature extraction method provided by the invention can be better combined with the corresponding fusion neural network, and higher accuracy and efficiency can be obtained compared with other neural network training methods. In addition, compared with other classification methods, the method provided by the invention can more accurately identify the specific vulnerability type. The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”, (see Zhu par. 85).
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in view of Baset et al. (US-10296745-B2 hereafter Baset), in further view of Ganz et al. (US-20240184892-A1 hereafter Ganz).
Regarding claim 1 Sumedrea discloses a system for detecting vulnerabilities in software in real time, comprising (Sumedrea see par.0016: “The approach identifies a vulnerability corresponding to an initial source code and generates a prompt comprising the initial source code and the vulnerability.”, par.0023: “System 100 uses AIM trainer system 160 to iteratively train AIM 170 to perform a range of predefined
tasks for refactoring source code from a security perspective”):
one or more processors(Sumedrea see par.0045: “Method 400 may be performed by processing logic that may include hardware ( e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof.”); and
one or more non-transitory, computer-readable media comprising instructions that, when executed by the one or more processors, cause operations comprising (see Sumedrea par.0062: “This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.”):
receiving second source code being tested in a development environment (see Sumedrea par.0043: “Training input prompt generator 140 receives new refactoring techniques descriptions 360”, new training source code 365,(second source code.”);
generating a first set of replacement libraries to replace the set of known
vulnerable software libraries based on the first set of sample replacement libraries (see Sumedrea par.0036: “Security code analysis copilot AIM 190 produces candidate samples 260, which may be various options to refactor initial source code 210. Security code analysis copilot AIM 190 produces multiple candidate samples 260 to increases the probability that the refactored source code is executable”, par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”.);
for each vulnerable library in the set of novel vulnerable software libraries and the set of known vulnerable software libraries, in response to detecting a replacement library in the first set of replacement libraries or the second set of replacement libraries (see Sumedrea par.0047: “the vulnerability is identified by a vulnerability scanner. The vulnerability scanner determines one or more properties of the initial source code, and identifies, based on the one or more properties, the vulnerability from a plurality of vulnerabilities included in a global vulnerability database”, par.0051: “processing logic detects a zero-day vulnerability corresponding to the initial source code, wherein the AIM has not been trained to determine whether the initial source code comprises the zero-day vulnerability but is able to detect the zero-day vulnerability due to its similarities with other vulnerabilities. Processing logic determines one or more zero-day refactoring operations corresponding to the zero-day vulnerability, and generates a new prompt comprising the initial source code,”), replacing the vulnerable library with an associated replacement library (see Sumedrea par.0050: “the AIM produces a plurality of refactored candidate samples. Processing logic tests at least a portion of code included in each of the plurality of refactored candidate samples to produce one or more test results.”, par.0051: “In response to inputting the new prompt into the AIM, processing logic determines, by the AIM, that the initial source code comprises the zero-day vulnerability. Processing logic then uses the AIM to remove the zero-day vulnerability from the initial source code to produce a new refactored source code.”).
Sumedrea appear to be silence however Wareus teaches
receiving a training dataset, comprising first source code, first runtime data flow associated with transformations and passage of data during an execution of the first source code, a first set of sample vulnerable libraries associated with the first source code, and a first set of sample replacement libraries associated with the first set of sample vulnerable libraries, (see Wareus par.0046: “ The vulnerability and exposure detection system 305 can then relate known vulnerabilities to the software source code 310 (first source code). This can be done, for example, using one or more trained models 325 (Training dataset) which define, for example, relationships between information from the vulnerability data sources 320 (first set of sample vulnerable libraries) to portions of software code.”, Par.0049: “Using the identified patch commits, the vulnerability and exposure detection system 305 can, through analysis of the changed files in those particular commits, label the changed functions/methods/classes of the source code 310 as the vulnerable functionality with a vulnerability symbol. These symbols can comprise any graphical and/or textual indicator made to be uniquely identified, which can be a different process for each programming language, but can comprise constructing a call graph 340 (first runtime dataflow) such as an abstract syntax tree for those changed files, and appending the namespace to the corresponding functions/methods/classes that match a call graph representation of that particular language.”, Par.0044: “A call graph can be derived for the software code based on the identified one or more vulnerable functions. Each of the identified one or more vulnerable functions can be indicated in the call graph by a vulnerability symbol. A determination can be made as to whether each identified one or more vulnerable functions is a true vulnerability by analyzing the call graph. A function can be determined to be a true vulnerability when the vulnerable function, represented by a vulnerability symbol in the call graph, is encountered when traversing the call graph.”); wherein a vulnerable library includes code that when executed on a computer system poses a security risk for the computer system (see Wareus par.0051-52: “identifying vulnerable functions in software code can comprise collecting 405 information identifying one or more known CVEs from any of a number of possible sources as described above. One or more vulnerable functions in the software code can then be identified 410 based on relationships between the collected information identifying the one or more known CVEs and the functions in the software code. Additional details of an exemplary process for identifying 410 vulnerable functions.”);
using the training dataset, training a vulnerability detection model to detect
vulnerable software libraries in the first source code (see Wareus par.0051-52: “identifying vulnerable functions in software code can comprise collecting 405 information identifying one or more known CVEs from any of a number of possible sources as described above. One or more vulnerable functions in the software code can then be identified 410 based on relationships between the collected information identifying the one or more known CVEs and the functions in the software code. Additional details of an exemplary process for identifying 410 vulnerable functions.”, par.0056: “identifying the one or more vulnerable functions in the software code can be based on a trained model and can comprise identifying 505 a patch commit for each identified one or more vulnerable functions. In some cases, identifying 505 the patch commit for each identified one or more vulnerable function can further comprise analyzing 510 metadata for each identified one or more vulnerable function using a trained model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea teaching “the approach evaluates the initial source code by the AIM prior to generating the prompt. The approach identifies, by the AIM in response to evaluating the initial source code, a plurality of potential vulnerabilities that correspond to the initial source code. The approach generates a new prompt comprising the initial source code and the plurality of potential vulnerabilities. In response to inputting the new prompt into the AIM, the approach determines, using the AIM, that the initial source code comprises a first vulnerability from the plurality of potential vulnerabilities. The approach removes, using the AIM, the first vulnerability from the initial source code to produce a new refactored source code.”, (see Sumedrea par.0021) with Wareus teaching “A determination 420 can then be made as to whether each identified vulnerable function is a true vulnerability by analyzing the call graph. Additional details of an exemplary process for determining whether a vulnerability is a true vulnerability”, (see Wareus par.0021).
Sumedrea and Wareus do not explicitly teach however Zhu teaches
collecting, through the development environment, the second source code and second runtime data flow associated with transformations and passage of data during an execution with the second source code (see Zhu par.10: “collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes;”);
processing the second source code and the second runtime data flow using the vulnerability detection model to identify a set of novel vulnerable software libraries and a set of known vulnerable software libraries in the second source code, wherein the set of novel vulnerable software libraries is not in the first set of sample vulnerable libraries (see Zhu par. 52-57: “step S1: collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes; step S2: preprocessing the assembly code, and slicing the assembly code into a plurality of code segments by taking a function as an element unit; step S3: converting the code segments into feature vectors; step S4: constructing a vulnerability detection model, and training the vulnerability detection model by utilizing the feature vector until the model converges; step S5: and performing vulnerability detection on the binary file to be detected by using the trained vulnerability detection model. It can be appreciated that in the vulnerability detection method of the binary file of the present embodiment, sample data in a vulnerability database is collected first and compiled into a source file thereof to obtain a binary file required for training a neural network, and then the binary file is decompiled into assembly code to facilitate analysis and processing of the binary file.”, par. 85: “The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Wareus teaching described above with Zhu teaching “the vulnerability detection method of binary file of the present invention has at least the following advantages: … The feature extraction method provided by the invention can be better combined with the corresponding fusion neural network, and higher accuracy and efficiency can be obtained compared with other neural network training methods. In addition, compared with other classification methods, the method provided by the invention can more accurately identify the specific vulnerability type. The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”, (see Zhu par. 85).
Sumedrea in view of Wareus, and Zhu do not explicitly teach however Baset teaches
generating confidence scores associated with the set of novel vulnerable software libraries, wherein the confidence scores are indicative of a likelihood of a software library being vulnerable (see Baset Col 6 lines 54-67 and Col.7 1-10: “The library vulnerability engine 103 of the VFS 116 can then store that library signature for further processing in the app/library database 114 in the form of a library index table 320. In some embodiments, library signatures may be created with hierarchical subsets of features that may provide additional utility in identifying use within an application. For example, in an object oriented programming language, it may be desirable to generate specific signatures for each object, such as a class or function, which could be included within a software application. In another example, some libraries exist in multiple version with slight variations in their signature between versions. It may be helpful to be able to identify a feature set that represents the library regardless of the version, as well as variations on the signature that correspond to a specific version of the library. It is often the case that a vulnerability exists in one version of a library but not the other. Accordingly, the version of the library may be relevant to assessing the risk of an application into which the library is included. Each library and version thereof includes a vulnerability risk score. The score may be alpha-numeric (e.g., 0 to 10, A to”).”, Col.8 lines30-42: “vulnerability engine 103 may use a combination of feature count (i.e., number of occurrences of a feature in the feature set) and feature uniqueness (i.e., a statistical quantification of the likelihood of the feature appearing randomly, in other known libraries, and/or in a sample of application programs written in that language regardless of library use) to calculate confidence scores associated with the set of features found in the code of the target software application compared to the set of features in the library signature. The library vulnerability engine 103 of the VFS 116 can then store that application signature for further processing in the app/library database 114 in the form of an application index table 520.”.);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Wareus, and Zhu teaching described above with Baset teaching “vulnerability engine 103 may use a combination of feature count (i.e., number of occurrences of a feature in the feature set) and feature uniqueness (i.e., a statistical quantification of the likelihood of the feature appearing randomly, in other known libraries, and/or in a sample of application programs written in that language regardless of library use) to calculate
confidence scores associated with the set of features found in the code of the target software application compared to the set of features in the library signature.”, (see Baset Col.8 lines:30-38).
Sumedrea in view of Wareus, Zhu, and Baset appear to silence however Ganz teaches
receiving user input in association with at least a portion of the set of novel vulnerable software libraries, the user input being indicative of a second set of replacement libraries for at least a portion of the set of novel vulnerable software libraries (see Ganz par.0067-69: “in operation 720, identifies one or more target locations corresponding to the vulnerability in the source code. For example, the source code may be tested for each identified vulnerability and the lines of source code that cause the vulnerability may be identified (e.g., the lines of source code of the location 430 of FIG. 4). The identification of the lines of source code that cause the vulnerability may be based on heuristics or by application of a trained machine-learning model to the source code A subset of the target locations at which the vulnerability exists is empirically determined by using guided fuzzing to provide input to the source code targeting the target locations (operation 730). The fuzzing module 250 provides a range of inputs to the source code and actual instances of the vulnerabilities (e.g., memory buffer overrun) are observed. Thus, the predictions made by the explanation module 230 in operation 720 may be confirmed, rejected, or modified based on actual execution of the source code in question. For example, guided fuzzing (also known as greybox fuzzing) may be used. Guided fuzzing uses program instrumentation to trace the code coverage reached by each input fed to a target location. The fuzzing module 250 may use this information to make informed decisions about which inputs to mutate to maximize coverage. In operation 740, the testing server 130 indicates on a user interface the subset of the target locations at which the vulnerability was empirically determined to exist. For example, a user interface may be provided that shows the source code 400 of FIG. 4 with the lines of code that were confirmed to contain vulnerabilities in operation 730 highlighted. The lines of code identified by explanation methods in operation 720 that were not confirmed may not be highlighted. Thus, the attention of a software developer is efficiently directed to the lines of code that cause the vulnerabilities.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Wareus, Zhu, and Baset teaching described above along with Ganz teaching “results generated by explanation methods are improved. The refined set of lines of code may be presented on a display device to a software developer, who is enabled to more efficiently find and correct problems in source code.”, (see Ganz par.0070).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Guttridge et al. (US-20250077204-A1 hereafter Guttridge)
Regarding claim 3 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Wareus further teaches further comprising:
receiving a first registry of known vulnerabilities associated with the first source code and the first runtime data flow (see Wareus par.0052: “identifying vulnerable functions in software code can comprise collecting 405 information identifying one or more known CVEs from any of a number of possible sources as described above…One or more vulnerable functions in the software code can then be identified 410 based on relationships between the collected information identifying the one or more known CVEs and the functions in the software code. Additional details of an exemplary process for identifying 410 vulnerable functions. A call graph for the software code can be derived 415 based on the identified one or more vulnerable functions. Each of the identified one or more vulnerable functions can be indicated or marked in the call graph by a vulnerability symbol.”); and
Wareus in view of Sumedrea, and Zhu appear to be silence however Guttridge teaches using the first registry of known vulnerabilities, updating the vulnerability detection model (see Guttridge par.0035: “the GenAI model 322 and the user feedback of the predicted redundancies and the predicted interdependencies. The responses may include indications of whether the output of the GenAI model 322 is correct or not. This data may be captured and stored within a runtime log 325 or other data store within the live environment and can be subsequently used to retrain the GenAI model 322.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2, with Wareus teaching “identifying vulnerable functions in software code, such as open-source software code, can comprise collecting information identifying one or more known Common Vulnerabilities and Exposures (CVEs) and identifying one or more vulnerable functions in the software code based on relationships between the collected information identifying the one or more known CVEs and the one or more vulnerable functions in the software code.”, (see Wareus par.0044) with Guttridge teaching “the GenAI model 124 may compare source code (programs) stored within a code repository 131 and make recommendations for optimizing the storage of the software libraries within the code repository 131. As another example, the GenAI model 124 may compare sets of software libraries within a library repository 132 and make recommendations for optimizing the storage of the software libraries within the library repository 132.”, (see Guttridge par.0024).
Claims 4, 5, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Nagaraja et al. (US-20220222353-A1 hereafter Nagaraja).
Regarding claim 4 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Sumedrea further discloses wherein identifying the set of novel vulnerable software libraries (see Sumedrea par.0043: “Training input prompt generator 140 receives new refactoring techniques descriptions 360(Second runtime data flow), new training source code 365 (second source code), new vulnerability 370, and distinguishing context 375 to generate new training prompt 380. AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370 (novel vulnerable software libraries)... New training source code 365 includes samples that include new vulnerability 370.”), further comprises:
Wareus in view of Sumedrea, and Zhu appears to be silence however Nagaraja teaches wherein identifying the set of novel vulnerable software libraries further comprises:
receiving a first output vector from the vulnerability detection model, comprising a first set of vulnerable software libraries (see Nagaraja par.0046-47: “the remediation computer 130 can receive information about known library vulnerabilities that may be present in the candidate application. The remediation computer 130 may retrieve this information from the license database server 120 and security risk database server 150. The information may be in the form of a list of vulnerable libraries and the risks associated with them. the remediation computer 130 can determine if one or more libraries in the plurality of libraries is vulnerable based upon the information received in step 302. This can be done by examining a list of libraries called when the candidate application is run and comparing the list of called libraries to the list of known vulnerable libraries.”), wherein each vulnerable software library is associated with a degree of severity and a category of vulnerability. (See Nagaraja par.0050: “may be industry standard scores such as those in the Common Vulnerability Scoring System (CVSS) 3.0. Additionally, or alternatively, the scores may be custom, nonstandard scores. For example, the library version may have a score of 1 for license risk, because there is only a small licensing risk, and a score of 10 for security risk, because there are several high-level security risks. The library version may also have a score of 1 because it was created by a trusted development community, and a score of 5 because it is not updated frequently.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2, with Sumedrea teaching “the approach evaluates the initial source code by the AIM prior to generating the prompt. The approach identifies, by the AIM in response to evaluating the initial source code, a plurality of potential vulnerabilities that correspond to the initial source code. The approach generates a new prompt comprising the initial source code and the plurality of potential vulnerabilities. In response to inputting the new prompt into the AIM, the
approach determines, using the AIM, that the initial source code comprises a first vulnerability from the plurality of potential vulnerabilities. The approach removes, using the AIM, the first vulnerability from the initial source code to produce a new refactored source code.”, (see Sumedrea par.0021) with Nagaraja teaching “determining a library
version that minimizes risk. Library version risk can depend on a risk score and a change score. The risk score can quantify the potential risk of a library version. A library
version with a high risk score can have many security and/or license risks that may make the candidate application more vulnerable. A library version with a low risk score can have few security and/or license risks that may make the candidate application more secure. The change score can quantify operational risks. A library version with a low change score may have fewer operational risks to negatively affect functionality
of the application. A library version with a high change score might have many operational risks and therefore result in more remediation over time.”, (see Nagaraja par.0070).
Regarding claim 5 Wareus in view of Sumedrea, Zhu, and Nagaraja disclose the method of claim 4, Nagaraja further disclose further comprising:
using associated categories of vulnerability, displaying the first set of vulnerable software libraries in the development environment (see Nagaraja par.0095-0104: “A user interface test can test how the user interface of an application changes as an application is updated…. The remediation computer may recommend a manual code change. The remediation computer may recommend a change to the library version with the lowest risk score, change score, and/or remediation score. Recommending a manual code change may involve presenting a message to a developer with the library version being recommended and an error report.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, Zhu, and Nagaraja teaching of claim 4 with Nagaraja teaching “remediation computer may recommend a change to the library version with the lowest risk score, change score, and/or remediation score. Recommending a manual code change may involve presenting a message to a developer with the library version being recommended and an error report.”, (see Nagaraja par.0104).
Regarding claim 12 Wareus in view of Sumedrea, Zhu, and Nagaraja disclose the method of claim 4, Nagaraja further comprising:
using associated degrees of severity, determine that a first subset of vulnerable software libraries exceed a threshold severity (see Nagaraja par.0060-0061: “In step 316, the remediation computer may use the intermediate remediation scores to determine a remediation score for the application tests. For example, intermediate remediation scores of 10, 30, 0, and 0 as in the example above may result in a remediation score of 40…. A score above the threshold may indicate that manual changes are needed to incorporate the library version. For example, the threshold may be 20, and thus a library version with a remediation score of 40 likely cannot be incorporated automatically.”); and
transmitting a notification to a deployment system indicating that the first subset of vulnerable software libraries is ineligible for deployment (see Nagaraja par.0063: “if the remediation score is above the predetermined threshold, the remediation computer may generate a notification that the determined library version is not acceptable.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, Zhu, and Nagaraja teaching of claim 4 with Nagaraja teaching “If after all versions of the vulnerable library have been tested none have been automatically incorporated, the remediation computer may recommend a manual code change. The remediation computer may recommend a change to the library version with the lowest risk score, change score, and/or remediation score. Recommending a manual code change may involve presenting a message to a developer with the library version being recommended and an error report.”, (see Nagaraja par.104).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in view of Nagaraja et al. (US-20220222353-A1 hereafter Nagaraja), in further view of Alam et al. (US-20190324744-A1 hereafter Alam).
Regarding claim 6 Wareus in view of Sumedrea, Zhu, and Nagaraja disclose the method of claim 4, Wareus in view of Sumedrea, Zhu, and Nagaraja appear to be silence however Alam teaches ranking the first set of vulnerable software libraries using associated degrees of severity (see Alam par.0024: “The risk identifier 114 detects a vulnerability metric based on an attack surface of a portion of the recommended software component. The risk identifier 114 includes an example vulnerability classifier 112 to perform risk scoring of the recommended software components. The example ranking determiner 108 outputs one or more recommended software components based on the ranking metrics. Once the recommendation system 100 has provided the output of recommended software components, the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”); and
displaying the first set of vulnerable software libraries in the development environment using the ranked first set of vulnerable software libraries (see Alam par.0024: “the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”, par.0038: “a ranking A (allows the system 100) to provide a sorted display (e.g., a list) of the software components under consideration.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, Zhu, and Nagaraja teaching of claim 4 with Alam teaching “The current state vector generator 118 generates a representation of a current state of a function. Once the instruction predictor 104 has generated the recommended software components (e.g., code that is used to create a code base or application), these components are ranked based on one or more ranking metrics (e.g., a complexity cost determination, a risk/vulnerability determination, etc.).”, (see Alam par.0023).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Ganz et al. (US-20240184892-A1 hereafter Ganz).
Regarding claim 7 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Wareus in view of Sumedrea, and Zhu appear to be silence however Ganz teaches further comprising:
retrieving a first set of outcomes associated with the first source code and the first runtime data flow (see Ganz par.0055-56: “Unlabeled test data 530 (e.g., source code) is provided to the model 520 and the model 520 determines whether the input contains vulnerabilities. The unlabeled test data 530 is also provided to one or more explanation methods 540. Each explanation method 540 identifies locations in the source code that are predicted to contain vulnerabilities (e.g., by generating a map that attributes numerical relevance scores to locations in the source code)… The identified vulnerabilities generated by the machine-learning model 520 may be paired with the corresponding source code and used by the one or more explanation methods 540 as part of the location-identification process. The identified locations are treated as targets and directed fuzzing 550 is performed on the targets. The directed fuzzing 550 provides a range of input to test the performance of the targets and detect vulnerabilities in the source code experimentally (e.g., by determining if any input causes a crash, erroneous functioning, access of unallocated memory, a core dump, or any suitable combination thereof).”);
using the first set of outcomes and the training dataset, generating a labeled training dataset (see Ganz 0072-74: “vulnerability detection module 220, using a machine-learning model, generates a probability of a vulnerability existing in source code for a PUT. For example, the source code 400 of FIG. 4 may be provided as input to the trained neural network 320 generate a vector of vulnerability probabilities, with each entry in the vector indicating a probability of a different vulnerability. The fuzzing module 250, in operation 820, uses random fuzzing to provide input to the source code to empirically measure whether the vulnerability exists in the source code. For example, one or more explanation models may be used to identify locations in the source code that are likely to cause the vulnerability. The PUT is executed with random inputs that are directed to the identified locations and any crashes of the PUT are detected. In various examples, different thresholds are used to determine if the vulnerability exists. For example, if any of the inputs cause the PUT to crash, the vulnerability may be considered to have been empirically verified. based on the empirical measurement and the source code, the testing server 130 trains the machine-learning model. For example, a vector indicating which vulnerabilities were determined to exist in operation 820 may be provided as the label for the source code.”); and
using the labeled training dataset, updating the vulnerability detection model (see Ganz par.0075: “The labeled source code may be used to train the machine learning model. In some example embodiments, line numbers for locations identified by an explanation method are used as part of the training of the machine-learning model. Accordingly, by use of the method 800, unlabeled source code is labeled and used to enhance the training of a machine-learning model for detecting vulnerabilities in source code. The methods 700 and 800 may be combined to use directed fuzzing both for providing feedback to explanation methods and to enhance training of a machine learning model for detecting vulnerabilities.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2 with Ganz teaching “The machine-learning model 520 is trained using labeled training data 510. For example, the labeled training data 510 may comprise labeled source code that indicates whether each
source code contains a vulnerability or not.”, (see Ganz par.0054).
Regarding claim 8 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Wareus in view of Sumedrea, and Zhu appear to be silence however Ganz teaches receiving a first set of vulnerability estimates associated with one or more vulnerable software libraries (see Ganz par.0058-0061: “a predetermined number of the identified locations are tested using the directed fuzzing 550. For example, the potential interesting code regions may be sorted by relevance and the top 1, top 3, top 5, or top 10 potential interesting code regions may be tested. debugger may be used to execute a PUT with the generated seeds from the Fuzzer and with the relevant lines set as breakpoint. Using this approach, if the identified vulnerability exists, the directed fuzzing 550 will reproduce the crash and provide additional information about the execution trace of the crash and, in particular, which of the given breakpoints were reached before. If a target line triggers a breakpoint during the reproduction of a crash, that line can be considered to be associated with the vulnerability. The more breakpoints that are hit during the reproduction of the crash (Mcount), the more relevant is the overall explanation provided by the corresponding explanation method 540. Additionally or alternatively, the average time that elapses from the breakpoint hits to the crash site may be measured (Md,s,). If the lines from an explanation method 540 are closer to the crash site, they should be more relevant to the vulnerability.”);
using the first set of vulnerability estimates and the training dataset, generating a labeled training dataset (see Ganz par.0061: “Both and give numerical quantities Mcount Md,st from which a (weighted) average A can be formed that measures how well the hypothetical vulnerability in the code x can be reproduced. If A is above a threshold T then x will be labeled as malicious (y=1) else as benign (y=0).”); and
using the labeled training dataset, updating the vulnerability detection model (see Ganz par.0062: “The results of the directed fuzzing 550 (y) are provided as feedback to the machine-learning model 520… the feedback to the machine-learning model 520 would indicate that the detection of the vulnerability was in error. Accordingly, the machine-learning model 520 can be trained on the elements of the unlabeled test data 530, further improving the accuracy of the machine-learning model 520.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2 with Ganz teaching “the software application
210 may display a user interface that enables a user to provide feedback from the output provided by the model 224. As just an example, a machine learning model, such as a GenAI model, may predict that two pieces of source code from two different code bases are interdependent. Here, a user may input a confirmation based on a predicted interdependence between the two pieces of source code to indicate whether or not the predicted interdependence is correct. This information may be added to the results of
execution and stored within a runtime log 225. The runtime log 225 may include an identifier of the input, an identifier of the output, an identifier of the model used, and feedback from the recipient. This information may be used to subsequently
re-train the model.”, (see Ganz par.0031).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Alam et al. (US-20190324744-A1 hereafter Alam).
Regarding claim 9 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Sumedrea further teaches wherein generating suggestions to replace the set of known vulnerable software libraries comprises:
and
generating suggestions to replace each vulnerable library in the set of known vulnerable software libraries with associated replacement libraries (see Sumedrea par.0036: “Security code analysis copilot AIM 190 produces candidate samples 260, which may be various options to refactor initial source code 210. Security code analysis copilot AIM 190 produces multiple candidate samples 260 to increases the probability that the refactored source code is executable”, par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”.).
Wareus in view of Sumedrea, and Zhu appears to be silence however Alam teaches retrieving a set of safe libraries (see Alam par.0024: “Once the recommendation system 100 has provided the output of recommended software components, the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”);
using a library similarity machine learning model, determining a set of replacement libraries associated with the set of known vulnerable software libraries, wherein each vulnerable software library in the set of known vulnerable software libraries is associated with one or more replacement libraries (see Alam par.0029: “The example recommendation system 100 receives, retrieves and/or otherwise obtains a text in natural language describing the intended actions ( e.g., with respect to processing of input arguments) for desired functions at a high-level (e.g., natural language input as distinguished from code). This first input is the functional description, desc (block 202). In some examples, inputs (e.g., retrieved from data storage 160 or input by a user) specify the expected input arguments, arg (block 204) of the new function. The arguments are specified by their data types and access patterns. Additionally, in some examples, a list of return data types, ret, is provided or retrieved (block 206). At block 208, the recommendation system 100 takes these function specifications (blocks 202, 204, and 206) as input to generate recommendations for
instructions using existing functions and libraries (block212)”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2, with Sumedrea teaching “the approach evaluates the initial source code by the AIM prior to generating the prompt. The approach identifies, by the AIM in response to evaluating the initial source code, a plurality of potential vulnerabilities that correspond to the initial source code. The approach generates a new prompt comprising the initial source code and the plurality of potential vulnerabilities. In response to inputting the new prompt into the AIM, the
approach determines, using the AIM, that the initial source code comprises a first vulnerability from the plurality of potential vulnerabilities. The approach removes, using the AIM, the first vulnerability from the initial source code to produce a new refactored source code.”, (see Sumedrea par.0021) with Alam teaching “The example recommender 116 passes these instructions through a syntax validation phase (check syntax) (block 210) using the example syntax checker 110 to ensure the inference system is recommending only legal instructions by checking for syntax errors in each statement according to data set type.”, (see Alam par.0029).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Wareus et al. (US-20240241963-A1 hereafter Wareus), in view of Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view Kadam et al. (US-20190079734-A1 hereafter Kadam).
Regarding claim 11 Wareus in view of Sumedrea, and Zhu discloses the method of claim 2, Wareus in view of Sumedrea, and Zhu appears to be silence on however, Kadam teaches further comprising:
receiving a first set of compliance requirements, wherein each requirement in the first set of compliance requirements relates to permissible software libraries for the second source code (see Kadam par.0014-0015: “the library suggestion engine 113 may evaluate the input source code files 13 !using the library issue identification rules 135 to identify libraries 132-133 having specified performance limitations, such as security vulnerabilities, license limitations, compliance policy constraints, or unsupported or outdated versions, by applying natural language processing (NLP) techniques to reduce the processing burden for identifying source code libraries which have the specified performance limitations…In addition to identifying libraries with security vulnerabilities, the library suggestion engine 113 may be provided with a library license risk module 114 which uses licensing issue rules 137 to access a database or list of licenses which are identified as suitable (or not suitable) for an organization or product.”.); and
using the first set of compliance requirements, generating an expanded set of vulnerable software libraries, wherein the expanded set of vulnerable software libraries comprises the set of novel vulnerable software libraries, the set of known vulnerable software libraries and software libraries that contradict the first set of compliance requirements (see Kadam par.0016: “The library suggestion engine 113 may also be provided with a library policy risk module 114 which uses a compliance policy violation issue rules 137 to access a database or list of compliance policy requirements which can prevent or force use of specified libraries or library versions. In selected embodiments, the library policy risk module 114 may provide a categorized list of libraries for an organization or product, including a blacklist policy list of libraries or library versions that may not be used, and a recommended policy list which enforces usage of only certain approved libraries or library versions from a category of libraries that offer similar functionality. The library suggestion engine 113 may also be provided with a library status
risk module 114 which categorizes libraries based on specified status metrics, such as a library (version) age metric (e.g., release date), library (version) popularity metric, and/ or current support status metric.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wareus in view of Sumedrea, and Zhu teaching of claim 2 with Kadam teaching “the alternative, the library issue evaluation process (block 210) may identify a library having specified compliance policy issues (step 213) by accessing a database or list of compliance policy requirements which can prevent or force use of specified libraries or library versions. In selected embodiments, the library policy risk list accessed at step 213 may be separated into different categories, including a blacklist policy list of libraries or library versions that may not be used, and a recommended policy list which enforces usage of only certain approved libraries or library versions from a category of libraries that offer similar functionality.”, (see Kadam par.0027).
Claims 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Baset et al. (US-10296745-B2 hereafter Baset).
Regarding claim 13 Sumedrea discloses One or more non-transitory, computer-readable media comprising instructions that, when executed by one or more processors, cause operations comprising (see Sumedrea par.0062: “This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.”):
receiving a vulnerability detection model trained to detect vulnerable software libraries in source code (see Sumedrea par. par.0053: “Computer system 500 includes processing device 510 and memory 515. Memory 515 stores instructions 520 that are executed by processing device 510. Instructions 520, when executed by processing device 510, cause processing device 510 to identify a vulnerability 530 corresponding to an initial source code 540. Processing device generates a prompt 550 comprising the initial source code 540 and the vulnerability 530 and inputs prompt 550 into AIM 560 (detection model), which is trained to determine whether the initial source code comprises the vulnerability.”);
receiving first source code being tested in a development environment (see Sumedrea par.0053: “Instructions 520, when executed by processing device 510 (development environment), cause processing device 510 to identify a vulnerability 530 corresponding to an initial source code 540 (first source code). Processing device generates a prompt 550 comprising the initial source code 540 and the vulnerability 530 and inputs prompt 550 into AIM 560, which is trained to determine whether the initial source code comprises the vulnerability.”);
generating a first set of replacement libraries to replace the set of known vulnerable software libraries (see Sumedrea par.0036: “Security code analysis copilot AIM 190 produces candidate samples 260, which may be various options to refactor initial source code 210. Security code analysis copilot AIM 190 produces multiple candidate samples 260 to increases the probability that the refactored source code is executable.”);
for each vulnerable library in the set of novel vulnerable software libraries and the set of known vulnerable software libraries, in response to detecting a replacement library in the first set of replacement libraries or the second set of replacement libraries, (see Sumedrea par.0047: “the vulnerability is identified by a vulnerability scanner. The vulnerability scanner determines one or more properties of the initial source code, and identifies, based on the one or more properties, the vulnerability from a plurality of vulnerabilities included in a global vulnerability database”, par.0051: “processing logic detects a zero-day vulnerability corresponding to the initial source code, wherein the AIM has not been trained to determine whether the initial source code comprises the zero-day vulnerability but is able to detect the zero-day vulnerability due to its similarities with other vulnerabilities. Processing logic determines one or more zero-day refactoring operations corresponding to the zero-day vulnerability, and generates a new prompt comprising the initial source code,”. replacing the vulnerable library with an associated replacement library (see Sumedrea par.0050: “the AIM produces a plurality of refactored candidate samples. Processing logic tests at least a portion of code included in each of the plurality of refactored candidate samples to produce one or more test results.”, par.0051: “In response to inputting the new prompt into the AIM, processing logic determines, by the AIM, that the initial source code comprises the zero-day vulnerability. Processing logic then uses the AIM to remove the zero-day vulnerability from the initial source code to produce a new refactored source code.”).
Sumedrea appears to be silence however Zhu teaches
collecting, through the development environment, the first source code and first runtime data flow associated with transformations and passage of data during an execution of the first source code (see Zhu par.10: “collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes;”. Examiner interpret that the collecting, through the development environment, the first source code and first runtime data flow is a similar process perform to a second source code and second runtime on execution.);
processing the first source code and the first runtime data flow using the vulnerability detection model to identify a set of novel vulnerable software libraries and a set of known vulnerable software libraries in the first source code wherein the set of novel vulnerable software libraries is not in used in training the vulnerability detection model, and wherein the set of known vulnerable software libraries is used in training the vulnerability detection model (see Zhu par. 52-57: “step S1: collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes; step S2: preprocessing the assembly code, and slicing the assembly code into a plurality of code segments by taking a function as an element unit; step S3: converting the code segments into feature vectors; step S4: constructing a vulnerability detection model, and training the vulnerability detection model by utilizing the feature vector until the model converges; step S5: and performing vulnerability detection on the binary file to be detected by using the trained vulnerability detection model. It can be appreciated that in the vulnerability detection method of the binary file of the present embodiment, sample data in a vulnerability database is collected first and compiled into a source file thereof to obtain a binary file required for training a neural network, and then the binary file is decompiled into assembly code to facilitate analysis and processing of the binary file.”, par. 85: “The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea teaching “the approach evaluates the initial source code by the AIM prior to generating the prompt. The approach identifies, by the AIM in response to evaluating the initial source code, a plurality of potential vulnerabilities that correspond to the initial source code. The approach generates a new prompt comprising the initial source code and the plurality of potential vulnerabilities. In response to inputting the new prompt into the AIM, the approach determines, using the AIM, that the initial source code comprises a first vulnerability from the plurality of potential vulnerabilities. The approach removes, using the AIM, the first vulnerability from the initial source code to produce a new refactored source code.”, (see Sumedrea par.0021) with Zhu teaching “the vulnerability detection method of binary file of the present invention has at least the following advantages: … The feature extraction method provided by the invention can be better combined with the corresponding fusion neural network, and higher accuracy and efficiency can be obtained compared with other neural network training methods. In addition, compared with other classification methods, the method provided by the invention can more accurately identify the specific vulnerability type. The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”, (see Zhu par. 85).
Sumedrea in view of Zhu appears to be silence however Baset teaches generating confidence scores associated with the set of novel vulnerable software libraries, wherein the confidence scores are indicative of a likelihood of a software library being vulnerable (see Baset Col 6 lines 54-67 and Col.7 1-10: “The library vulnerability engine 103 of theVFS 116 can then store that library signature for further processing in the app/library database 114 in the form of a library index table 320. In some embodiments, library signatures may be created with hierarchical subsets of features that may provide additional utility in identifying use within an application. For example, in an object oriented programming language, it may be desirable to generate specific signatures for each object, such as a class or function, which could be included within a software application. In another example, some libraries exist in multiple version with slight variations in their signature between versions. It may be helpful to be able to identify a feature set that represents the library regardless of the version, as well as variations on the signature that correspond to a specific version of the library. It is often the case that a vulnerability exists in one version of a library but not the other. Accordingly, the version of the library may be relevant to assessing the risk of an application into which the library is included. Each library and version thereof includes a vulnerability risk score. The score may be alpha-numeric (e.g., 0 to 10, A to”).”, Col.8 lines30-42: “vulnerability engine 103 may use a combination of feature count (i.e., number of occurrences of a feature in the feature set) and feature uniqueness (i.e., a statistical quantification of the likelihood of the feature appearing randomly, in other known libraries, and/or in a sample of application programs written in that language regardless of library use) to calculate confidence scores associated with the set of features found in the code of the target software application compared to the set of features in the library signature. The library vulnerability engine 103 of the VFS 116 can then store that application signature for further processing in the app/library database 114 in the form of an application index table 520.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu teaching described above with Baset teaching “vulnerability engine 103 may use a combination of feature count (i.e., number of occurrences of a feature in the feature set) and feature uniqueness (i.e., a statistical quantification of the likelihood of the feature appearing randomly, in other known libraries, and/or in a sample of application programs written in that language regardless of library use) to calculate
confidence scores associated with the set of features found in the code of the target software application compared to the set of features in the library signature.”, (see Baset Col.8 lines:30-38).
Regarding claim 20 Sumedrea in view of Zhu, and Baset disclose the one or more non-transitory, computer-readable media of claim 13, Sumedrea further teaches further comprising:
and
generating suggestions to replace the set of vulnerable software functions. (See Sumedrea par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”)
Sumedrea appear to be silence however Zhu teaches
processing the first source code and the first runtime data flow using the vulnerability detection model to identify a set of vulnerable software functions in the first source code (see Zhu par. 52-57: “step S1: collecting sample data in a vulnerability database, compiling a source file of the sample data to obtain a binary file, and decompiling the binary file to obtain assembly codes; step S2: preprocessing the assembly code, and slicing the assembly code into a plurality of code segments by taking a function as an element unit; step S3: converting the code segments into feature vectors; step S4: constructing a vulnerability detection model, and training the vulnerability detection model by utilizing the feature vector until the model converges; step S5: and performing vulnerability detection on the binary file to be detected by using the trained vulnerability detection model. It can be appreciated that in the vulnerability detection method of the binary file of the present embodiment, sample data in a vulnerability database is collected first and compiled into a source file thereof to obtain a binary file required for training a neural network, and then the binary file is decompiled into assembly code to facilitate analysis and processing of the binary file.”, par. 85: “The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea teaching “the AIM produces a plurality of refactored candidate samples. Processing logic tests at least a portion of code included in each of the plurality of refactored candidate samples to produce one or more test results. Processing logic then constructs the refactored source code based on the one or more test results.”, (see Sumedrea par.0050), with Zhu teaching “the vulnerability detection method of binary file of the present invention has at least the following advantages: … The feature extraction method provided by the invention can be better combined with the corresponding fusion neural network, and higher accuracy and efficiency can be obtained compared with other neural network training methods. In addition, compared with other classification methods, the method provided by the invention can more accurately identify the specific vulnerability type. The vulnerability detection model has good iteration characteristics, and after a new binary vulnerability is found, the model can adapt to the new binary vulnerability by only adding a new training sample to retrain the model without modifying the model.”, (see Zhu par. 85).
Claims 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Baset et al. (US-10296745-B2 hereafter Baset), in further view of Nagaraja et al. (US-20220222353-A1 hereafter Nagaraja).
Regarding Claim 14 Sumedrea in view of Zhu, and Baset disclose the one or more non-transitory, computer-readable media of claim 13, Sumedrea in view of Zhu, and Baset appear to be silence however Nagaraja discloses wherein identify a set of vulnerable software libraries further comprises:
receiving a first output vector from the vulnerability detection model, comprising a first set of vulnerable software libraries (see Nagaraja par.0046-47: “the remediation computer 130 can receive information about known library vulnerabilities that may be present in the candidate application. The remediation computer 130 may retrieve this information from the license database server 120 and security risk database server 150. The information may be in the form of a list of vulnerable libraries and the risks associated with them. the remediation computer 130 can determine if one or more libraries in the plurality of libraries is vulnerable based upon the information received in step 302. This can be done by examining a list of libraries called when the candidate application is run and comparing the list of called libraries to the list of known vulnerable libraries.”), wherein each vulnerable software library is associated with a degree of severity and a category of vulnerability. (See Nagaraja par.0050: “may be industry standard scores such as those in the Common Vulnerability Scoring System (CVSS) 3.0. Additionally, or alternatively, the scores may be custom, nonstandard scores. For example, the library version may have a score of 1 for license risk, because there is only a small licensing risk, and a score of 10 for security risk, because there are several high-level security risks. The library version may also have a score of 1 because it was created by a trusted development community, and a score of 5 because it is not updated frequently.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, and Baset teaching of the computer readable media claim 13 with Nagaraja teaching “determining a library version that minimizes risk. Library version risk can depend on a risk score and a change score. The risk score can quantify the potential risk of a library version. A library version with a high risk score can have many security and/or license risks that may make the candidate application more vulnerable. A library version with a low risk score can have few security and/or license risks that may make the candidate application more secure. The change score can quantify operational risks. A library version with a low change score may have fewer operational risks to negatively affect functionality of the application. A library version with a high change score might have many operational risks and therefore result in more remediation over time.”, (see Nagaraja par.0070).
Regarding claim 15 Sumedrea in view of Zhu, Baset and Nagaraja disclose the one or more non-transitory, computer-readable media of claim 14, Nagaraja further teaches further comprising:
using associated categories of vulnerability, displaying the first set of vulnerable software libraries in the development environment. (See Nagaraja par.0095-0104: “A user interface test can test how the user interface of an application changes as an application is updated…. The remediation computer may recommend a manual code change. The remediation computer may recommend a change to the library version with the lowest risk score, change score, and/or remediation score. Recommending a manual code change may involve presenting a message to a developer with the library version being recommended and an error report.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, Baset and Nagaraja teaching of the computer readable media claim 14 with Nagaraja teaching “remediation computer may recommend a change to the library version with the lowest risk score, change score, and/or remediation score. Recommending a manual code change may involve presenting a message to a developer with the library version being recommended and an error report.”, (see Nagaraja par.0104).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in view of Baset et al. (US-10296745-B2 hereafter Baset), in further view of Nagaraja et al. (US-20220222353-A1 hereafter Nagaraja), in further view of Alam et al. (US-20190324744-A1 hereafter Alam).
Regarding claim 16 Sumedrea in view of Zhu, Baset and Nagaraja disclose the one or more non-transitory, computer-readable media of claim 14, Sumedrea in view of Zhu, Baset and Nagaraja appear to silence however Alam teaches further comprising:
ranking the first set of vulnerable software libraries using associated degrees of severity (see Alam par.0024: “The risk identifier 114 detects a vulnerability metric based on an attack surface of a portion of the recommended software component. The risk identifier 114 includes an example vulnerability classifier 112 to perform risk scoring of the recommended software components. The example ranking determiner 108 outputs one or more recommended software components based on the ranking metrics. Once the recommendation system 100 has provided the output of recommended software components, the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”); and
displaying the first set of vulnerable software libraries in the development environment using the ranked first set of vulnerable software libraries (see Alam par.0024: “the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”, par.0038: “a ranking A (allows the system 100) to provide a sorted display (e.g., a list) of the software components under consideration.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, Baset and Nagaraja teaching of the computer readable media claim 14 with Alam teaching “The current state vector generator 118 generates a representation of a current state of a function. Once the instruction predictor 104 has generated the recommended software components (e.g., code that is used to create a code base or application), these components are ranked based on one or more ranking metrics (e.g., a complexity cost determination, a risk/vulnerability determination, etc.).”, (see Alam par.0023).
Claims 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in view of Baset et al. (US-10296745-B2 hereafter Baset), in further view of Ganz et al. (US-20240184892-A1 hereafter Ganz).
Regarding claim 17 Sumedrea in view of Zhu, and Baset disclose the one or more non-transitory, computer-readable media of claim 13, Sumedrea in view of Zhu, and Baset appear to be silence however Ganz teaches retrieving a first set of outcomes associated with the set of novel vulnerable software libraries (see Ganz par.0055-56: “Unlabeled test data 530 (e.g., source code) is provided to the model 520 and the model 520 determines whether the input contains vulnerabilities. The unlabeled test data 530 is also provided to one or more explanation methods 540. Each explanation method 540 identifies locations in the source code that are predicted to contain vulnerabilities (e.g., by generating a map that attributes numerical relevance scores to locations in the source code)… The identified vulnerabilities generated by the machine-learning model 520 may be paired with the corresponding source code and used by the one or more explanation methods 540 as part of the location-identification process. The identified locations are treated as targets and directed fuzzing 550 is performed on the targets. The directed fuzzing 550 provides a range of input to test the performance of the targets and detect vulnerabilities in the source code experimentally (e.g., by determining if any input causes a crash, erroneous functioning, access of unallocated memory, a core dump, or any suitable combination thereof).”);
using the first set of outcomes and the confidence scores, generating a labeled training dataset (see Ganz 0072-74: “vulnerability detection module 220, using a machine-learning model, generates a probability of a vulnerability existing in source code for a PUT. For example, the source code 400 of FIG. 4 may be provided as input to the trained neural network 320 generate a vector of vulnerability probabilities, with each entry in the vector indicating a probability of a different vulnerability. The fuzzing module 250, in operation 820, uses random fuzzing to provide input to the source code to empirically measure whether the vulnerability exists in the source code. For example, one or more explanation models may be used to identify locations in the source code that are likely to cause the vulnerability. The PUT is executed with random inputs that are directed to the identified locations and any crashes of the PUT are detected. In various examples, different thresholds are used to determine if the vulnerability exists. For example, if any of the inputs cause the PUT to crash, the vulnerability may be considered to have been empirically verified. based on the empirical measurement and the source code, the testing server 130 trains the machine-learning model. For example, a vector indicating which vulnerabilities were determined to exist in operation 820 may be provided as the label for the source code.”); and
using the labeled training dataset, updating the vulnerability detection model. (see Ganz par.0075: “The labeled source code may be used to train the machine learning model. In some example embodiments, line numbers for locations identified by an explanation method are used as part of the training of the machine-learning model. Accordingly, by use of the method 800, unlabeled source code is labeled and used to enhance the training of a machine-learning model for detecting vulnerabilities in source code. The methods 700 and 800 may be combined to use directed fuzzing both for providing feedback to explanation methods and to enhance training of a machine learning model for detecting vulnerabilities.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, and Baset teaching of the computer readable media claim 13 with Ganz teaching “The machine-learning model 520 is trained using labeled training data 510. For example, the labeled training data 510 may comprise labeled source code that indicates whether each source code contains a vulnerability or not.”, (see Ganz par.0054).
Regarding claim 18 Sumedrea in view of Zhu, and Baset disclose the one or more non-transitory, computer-readable media of claim 13, Sumedrea in view of Zhu, and Baset appear to be silence however Ganz teaches receiving a first set of vulnerability estimates associated with one or more vulnerable software libraries (see Ganz par.0058-0061: “a predetermined number of the identified locations are tested using the directed fuzzing 550. For example, the potential interesting code regions may be sorted by relevance and the top 1, top 3, top 5, or top 10 potential interesting code regions may be tested. debugger may be used to execute a PUT with the generated seeds from the Fuzzer and with the relevant lines set as breakpoint. Using this approach, if the identified vulnerability exists, the directed fuzzing 550 will reproduce the crash and provide additional information about the execution trace of the crash and, in particular, which of the given breakpoints were reached before. If a target line triggers a breakpoint during the reproduction of a crash, that line can be considered to be associated with the vulnerability. The more breakpoints that are hit during the reproduction of the crash (Mcount), the more relevant is the overall explanation provided by the corresponding explanation method 540. Additionally or alternatively, the average time that elapses from the breakpoint hits to the crash site may be measured (Md,s,). If the lines from an explanation method 540 are closer to the crash site, they should be more relevant to the vulnerability.”);
using the first set of vulnerability estimates and the confidence scores, generating a labeled training dataset (see Ganz par.0061: “Both and give numerical quantities Mcount Md,st from which a (weighted) average A can be formed that measures how well the hypothetical vulnerability in the code x can be reproduced. If A is above a threshold T then x will be labeled as malicious (y=1) else as benign (y=0).”); and
using the labeled training dataset, updating the vulnerability detection model (see Ganz par.0062: “The results of the directed fuzzing 550 (y) are provided as feedback to the machine-learning model 520… the feedback to the machine-learning model 520 would indicate that the detection of the vulnerability was in error. Accordingly, the machine-learning model 520 can be trained on the elements of the unlabeled test data 530, further improving the accuracy of the machine-learning model 520.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, and Baset teaching of the computer readable media claim 13 with Ganz teaching “the software application 210 may display a user interface that enables a user to provide feedback from the output provided by the model 224. As just an example, a machine learning model, such as a GenAI model, may predict that two pieces of source code from two different code bases are interdependent. Here, a user may input a confirmation based on a predicted interdependence between the two pieces of source code to indicate whether or not the predicted interdependence is correct. This information may be added to the results of execution and stored within a runtime log 225. The runtime log 225 may include an identifier of the input, an identifier of the output, an identifier of the model used, and feedback from the recipient. This information may be used to subsequently re-train the model.”, (see Ganz par.0031).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Sumedrea et al. (US-20250139251-A1 hereafter Sumedrea), in view of Zhu et al. (CN-117521072-A hereafter Zhu), in further view of Baset et al. (US-10296745-B2 hereafter Baset), in further view of Alam et al. (US-20190324744-A1 hereafter Alam).
Regarding claim 19 Sumedrea in view of Zhu, and Baset disclose the one or more non-transitory, computer-readable media of claim 13, Sumedrea further teaches wherein generating suggestions to replace the set of known vulnerable software libraries comprises (see Sumedrea par.0036: ““Security code analysis copilot AIM 190 produces candidate samples 260, which may be various options to refactor initial source code 210. Security code analysis copilot AIM 190 produces multiple candidate samples 260 to increases the probability that the refactored source code is executable”, par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”.): and
generating suggestions to replace each vulnerable library in the set of known vulnerable software libraries with associated replacement libraries. (See Sumedrea par.0043: “AIM trainer system 160 fine tunes security code analysis copilot AIM 190 using new training prompt 380, which is now trained to detect and refactor initial source code that includes new vulnerability 370.”)
Sumedrea in view of Zhu, and Baset appear to be silence however Alam teaches retrieving a set of safe libraries (see Alam par.0024: “Once the recommendation system 100 has provided the output of recommended software components, the example recommender 116 invokes an example syntax checker 110 to confirm that the recommended functions or libraries are valid prior to presenting them to the user and allowing the user to select or reject recommended software components to be used in a new function state.”);
using a library similarity machine learning model, determine a set of replacement libraries associated with the set of known vulnerable software libraries, wherein each vulnerable software library in the set of known vulnerable software libraries is associated with one or more replacement libraries (see Alam par.0029: “The example recommendation system 100 receives, retrieves and/or otherwise obtains a text in natural language describing the intended actions ( e.g., with respect to processing of input arguments) for desired functions at a high-level (e.g., natural language input as distinguished from code). This first input is the functional description, desc (block 202). In some examples, inputs (e.g., retrieved from data storage 160 or input by a user) specify the expected input arguments, arg (block 204) of the new function. The arguments are specified by their data types and access patterns. Additionally, in some examples, a list of return data types, ret, is provided or retrieved (block 206). At block 208, the recommendation system 100 takes these function specifications (blocks 202, 204, and 206) as input to generate recommendations for
instructions using existing functions and libraries (block212)”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Sumedrea in view of Zhu, and Baset teaching of the computer readable media claim 13 with Alam teaching “The example recommender 116 passes these instructions through a syntax validation phase (check syntax) (block 210) using the example syntax checker 110 to ensure the inference system is recommending only legal instructions by checking for syntax errors in each statement according to data set type.”, (see Alam par.0029).
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Castrejon et al. (US 20230333835 A1) processing device is further configured to determine one or more recommended code updates based on the one or more identified potential vulnerabilities. In some embodiments, the code update is a revised version of at least a portion of a code within the software library that includes at least one of the one or more potential vulnerabilities. The code update may be at least partially automatically created. For example, based on the potential vulnerability, the system may generate the code update. In such an example, the user may be able to accept, decline, or revise the code update before deployment. The system may generate multiple recommended code updates to be used, in which the user may select the code update to deploy.
Khazan et al. (US 20050108562 A1) include an application executable 102, one or more libraries, such as dynamic link libraries (DLLs) 114, a malicious code (MC) detection system 110, the list of targets and invocation locations 106, a list of target functions whose invocations are to be identified by static analysis 111, and a list of target functions whose invocations are to be monitored by dynamic analysis 112. The MC detection system 110 includes a static analyzer 104 and a dynamic analyzer 108. The application executable 102 may be characterized as a binary file or machine executable program as may be produced, for example, by compiling and linking. the static analyzer 104 may analyze some or all libraries that may include routines or functions which are directly or indirectly invoked from the application executable 102. In other words, the application may include an external call to a function in a first library. This function may invoke another function in a different library. The static analyzer 104 may be used to perform static analysis on both of these libraries.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30AM - 5:00Pm.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497 /MALCOLM CRIBBS/Primary Examiner, Art Unit 2497
Prosecution Insights