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 .
DETAILED ACTION
1. This initial office action is based on the application filed on 07/15/2024, which claims 1-20 have been presented for examination.
Status of Claim
2. Claims 1-20 are pending in the application and have been examined below, of which, claims 1, 8 and 15 are presented in independent form.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 07/15/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner Notes
4. Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
9. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis specific to Claims 1, 8 and 15 is being presented below.
Claims 1, 8 and 15:
Step 1 Analysis:
Claims 1-7 of the instant application is direct to process.
Claims 8-14 of the instant application is direct to apparatus.
Claims 15-20 of the instant application is direct to product.
Thus, they are statutory categories.
Step 2 Analysis:
Claims 1, 8 and 15 recite:
(a) receiving, by a processor set, a patch for fixing one or more bugs in the application;
(b) analyzing, by the processor set, the patch to identify security rules violated by the one or more bugs using a large language model;
(c) identifying, by the processor set, code contexts associated with code segments in the patch, wherein the code segments are responsible for the one or more bugs in the application;
(d) identifying, by the processor set, a number of target code segments in the application that are potentially affected by the one or more bugs; and
(e) generating, by the processor set, a prompt for the large language model for each target code segment in the number of target code segments to detect other bugs in the application, wherein the prompt is generated based on security rules, the code contexts, and the number of target code segments in the application.
Step 2A -- Prong 1:
The claims 1, 8 and 15 recite the limitations of:
(b) analyzing, by the processor set, the patch to identify security rules violated by the one or more bugs using a large language model;
(c) identifying, by the processor set, code contexts associated with code segments in the patch, wherein the code segments are responsible for the one or more bugs in the application;
(d) identifying, by the processor set, a number of target code segments in the application that are potentially affected by the one or more bugs;
Limitations (b)-(d) are limitations that, as drafted, are processes that, under its broadest reasonable interpretations, covers performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “analyzing” and “identifying” can be performed in the human mind through observation, evaluation, judgement, opinion with the aid of pen and paper. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A -- Prong 2:
The claim 1 recites the additional limitation of “a processor set”. The limitation of “a processor set” is recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Claim 8 recites the additional limitations of “A system”; “a processor set”; “a set of one or more computer-readable storage medium”. The limitations of “A system”; “a processor set”; “a set of one or more computer-readable storage medium” are recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Claim 15 recites the additional limitations of “a set of one or more computer-readable storage medium”, “a processor set”. The limitations of “a set of one or more computer-readable storage medium”, “a processor set” are recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Additionally, limitation (a) perform as well-understood, routine and conventional activity and limitation (e) are merely insignificant extra solution activity of gathering data and outputting data. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
As explained with respect to Step 2A Prong Two, the additional elements in the claim are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The same analysis applies here in 2B, i.e., simply adding extra-solution activity or well-understood, routine and conventional activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B since the courts have identified functions such as gathering, displaying, updating, transmitting/receiving and storing/uploading data as well- understood, routine, conventional activity. See MPEP 2106.05(d) and See MPEP 2106.05(g) . Therefore, claims are ineligible.
Dependent claims
Additionally, claims 2, 9 and 16 recite “inputting, by the processor set, the prompt for the number of target code segments to the large language model to identify other bugs associated with the number of target code segments in the application” as drafted, is a process that, under its broadest reasonable interpretations, covers performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “identifying” can be performed in the human mind through observation, evaluation, judgment, opinion with the aid of pen and paper. As such, this limitation falls within the “Mental Processes” grouping of abstract idea. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 2, 9 and 16 are ineligible.
Additionally, claims 3, 10 and 17 recite “identifying, by the processor set, code contexts associated with code segments in the patch comprises: identifying, by the processor set, caller functions for the code segments responsible for the one or more bugs; and generating, by the processor set, the code contexts associated with the code segments by expanding the caller functions”. The limitations “identifying, by the processor set, code contexts associated with code segments in the patch comprises: identifying, by the processor set, caller functions for the code segments responsible for the one or more bugs” as drafted, is a process that, under its broadest reasonable interpretations, covers performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “identifying” can be performed in the human mind through observation, evaluation, judgment, opinion with the aid of pen and paper. As such, this limitation falls within the “Mental Processes” grouping of abstract idea. The addition limitation “generating, by the processor set, the code contexts associated with the code segments by expanding the caller functions” is merely insignificant extra solution activity of comparation/judgment data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 3, 10 and 17 are ineligible.
Additionally, claims 4, 11 and 18 recite “identifying, by the processor set, the number of target code segments in the application that are potentially affected by the one or more bugs comprises: identifying, by the processor set, a set of caller functions in the application, wherein the set of caller functions are caller functions for the code segments responsible for the one or more bugs; identifying, by the processor set, a number of program instructions and a number of variables associated with each caller function in the set of caller functions; and generating, by the processor set, the number of target code segments based on the set of caller functions, the number of program instructions, and the number of variables.” The limitations “identifying, by the processor set, the number of target code segments in the application that are potentially affected by the one or more bugs comprises: identifying, by the processor set, a set of caller functions in the application, wherein the set of caller functions are caller functions for the code segments responsible for the one or more bugs; identifying, by the processor set, a number of program instructions and a number of variables associated with each caller function in the set of caller functions” as drafted, is a process that, under its broadest reasonable interpretations, covers performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “identifying” can be performed in the human mind through observation, evaluation, judgment, opinion with the aid of pen and paper. As such, this limitation falls within the “Mental Processes” grouping of abstract idea. The addition limitation “generating, by the processor set, the number of target code segments based on the set of caller functions, the number of program instructions, and the number of variables” is merely insignificant extra solution activity of gathering data and outputting data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 4, 11 and 18 are ineligible.
Additionally, claims 5, 12 and 19 recite “wherein the set of caller functions in the application is identified using a call graph for the code segments responsible for the one or more bugs” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 5, 12 and 19 are ineligible.
Additionally, claims 6, 13 and 20 recite “wherein the number of program instructions and the number of variables associated with each caller function in the set of caller functions are identified based on control flow analysis” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 6, 13 and 20 are ineligible.
Additionally, claims 7 and 14 recite “wherein the security rules violated by the one or more bugs are identified based on description and changes in program instructions for application from content of the patch” which performs as well-understood, routine and conventional activity. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 7 and 14 are ineligible.
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.
10. Claim(s) 1-2, 7-9 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rudenko et al. (US Pub. No. 2025/0004915 A1 – herein after Rudenko) in view of Qiushi Wu (Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison, 2020 – IDS filed on 07/15/2024 – herein after Wu).
Regarding claim 1.
Rudenko discloses
A computer implemented method for detecting bugs in an application (a scanner performs a static application security testing scan of files of an application and outputs weakness identifiers and/or descriptors of detected flaws and locations of the flaws – See paragraph [0105]), the computer implemented method comprising:
receiving, by a processor set, a patch for fixing one or more bugs in the application (selects a modification as a patch to apply to the program code. Filtering removes syntactically incorrect code modifications – See paragraphs [0030-0036]. The LLM 101 has been fine-tuned to generate a predicted token sequence that will be used as a code modification. Thus, the responses are referred to as code modifications or patches of a flawed code fragment indicated in a prompt. In this illustration, the LLM 101 outputs 5 modifications for a single prompt, but space limitations prevent the depiction of 23 example modifications from 5 prompts – See paragraphs [0024-0030]);
analyzing, by the processor set, the patch [[to identify]] security rules violated by the one or more bugs using a large language model (at least a subset of weakness type identifiers may each be associated with a rule for additional analysis to inform reference code selection. As an example, a rule can be defined that requires data flow analysis (e.g., sink to source tracing) for a flaw indicated as a XSS type of vulnerability – See paragraphs [0105-0107]);
identifying, by the processor set, code contexts associated with code segments in the patch (A reference code pair is a pair of code units or code fragments that correspond to each other: a first code fragment that includes contextual code and flawed code (“flawed reference code”) and a second code fragment that is a patched version of the first code fragment and includes the same contextual code (“patched reference code”). The contextual code included in the fragments of the reference code pair may be a line or a few lines of program code prior to and possibly subsequent to the flawed code and patched code. Contextual code is not limited to a line granularity and can be code preceding and/or subsequent to the flaw/patch on a same line– See paragraphs [0024-0029]. The pipeline arranges the code body that includes contextual code for the flawed code fragment, the flawed code fragment – See paragraph [0117]),
wherein the code segments are responsible for the one or more bugs in the application (the result of the data flow analysis may resolve to a specified set of reference code pairs or determine that a different code fragment should be modified, in which case the different code fragment (e.g., code fragment corresponding to a flaw source) would replace the current flawed code fragment or be added as another flawed code fragment to indicate in a different prompt. In addition to data flow analysis, embodiments can perform other analysis for flaw localization that adjusts (e.g., augments or decreases the flawed code fragment) or replaces the flawed code fragment. Other filtering can also be applied to the reference code pairs yielded based on programming language and weakness type (e.g., keyword based filtering) – See paragraphs [0105-0107]);
identifying, by the processor set, a number of target code segments in the application (flaw code fragments – see paragraph [0029]) that are potentially affected by the one or more bugs (The markers facilitate the LLM learning to constrain a generated response to be a modification of the to-modify code fragment and learning context from the code body proximate to (e.g., surrounding or preceding) the to-modify fragment – See paragraph [0019]);
generating, by the processor set, a prompt for the large language model (a prompt generator, the code fix model, and a refiner – See paragraph [0019-0020]) for each target code segment in the number of target code segments to detect other bugs in the application (In FIG. 1, markers <vul> and </vul> are used to mark the flawed code fragment 118 and constrain modification to the code fragment 118. These are the same as those in the indication 104 for simplicity of the illustration. The markers for delineating a flawed code fragment in a prompt for the LLM 101 are likely developed independently from the indicators employed by the scanner 103 to indicate location of a detected flaw. Moreover, implementations can use other markers that will be treated as special tokens by the LLM 101. In other words, markers are chosen to avoid conflict/overload with program code tokens – See paragraph [0029]. The responses are referred to as code modifications or patches of a flawed code fragment indicated in a prompt. In this illustration, the LLM 101 outputs 5 modifications for a single prompt, but space limitations prevent the depiction of 23 example modifications from 5 prompts. Responses 123 for the code modifications 113 – See paragraphs [0029-0030]), wherein the prompt is generated based on security rules (a rule can be defined that requires data flow analysis (e.g., sink to source tracing) for a flaw indicated as a XSS type of vulnerability. The result of the data flow analysis may resolve to a specified set of reference code pairs or determine that a different code fragment should be modified, in which case the different code fragment (e.g., code fragment corresponding to a flaw source) would replace the current flawed code fragment or be added as another flawed code fragment to indicate in a different prompt – See paragraph [0107]. The LLM 101 has learned to constrain modification to the flawed code fragment 118. In LLM terms, the LLM 101 has learned to predict a token sequence that continues from the context code or a token sequence that does not change the context code (i.e., constrained to generating a response that is a modification of the code within flaw markers). In FIG. 1, markers <vul> and </vul> are used to mark the flawed code fragment 118 and constrain modification to the code fragment 118), the code contexts (the prompt generator 105 retrieves one or more reference code pairs based on the indicated weakness type, CWE-79. A repository 107 hosts one or more pairs of reference code pairs per weakness type. A reference code pair is a pair of code units or code fragments that correspond to each other: a first code fragment that includes contextual code and flawed code (“flawed reference code”) and a second code fragment that is a patched version of the first code fragment and includes the same contextual code (“patched reference code”) – See paragraph [0024]), and the number of target code segments in the application (the pipeline arranges the code body that includes contextual code for the flawed code fragment, the flawed code fragment, and the reference code pair with markers indicating the parts to form the prompt – See paragraph [0117]).
Rudenko does not disclose
…identify security rules violated…
Wu discloses
the patch to identify security rules violated (security-rule violations (e.g., out-of-bound access) can be modeled as constraints that can be automatically solved. SID incorporates rule comparison, using under-constrained symbolic execution of a patch to determine the security impacts of an un-applied patch – See page 1, left column. Collecting constraints – See Fig. 2).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Wu’s teaching into Rudenko’s invention because incorporating Wu’s teaching would enhance Rudenko to enable to define security impacts based on the security-rule violating operations as suggested by Wu (page 4, left column).
Regarding claim 2, the computer implemented method of claim 1, further comprising:
Rudenko discloses
inputting, by the processor set, the prompt for the number of target code segments to the large language model to identify other bugs associated with the number of target code segments in the application (the prompt generator 105 retrieves one or more reference code pairs based on the indicated weakness type, CWE-79. A repository 107 hosts one or more pairs of reference code pairs per weakness type. A reference code pair is a pair of code units or code fragments that correspond to each other: a first code fragment that includes contextual code and flawed code (“flawed reference code”) and a second code fragment that is a patched version of the first code fragment and includes the same contextual code (“patched reference code”) -- See paragraphs [0021-0024] and See Fig.1).
Regarding claim 7, the computer implemented method of claim 1,
Wu discloses
wherein the security rules violated by the one or more bugs are identified based on description (the patch description (comments), the patch code, and the involved source code – See page 10) and changes in program instructions for application from content of the patch (pointer usage in an incorrect order can introduce use-after-free vulnerabilities, and the corresponding patches just change the pointer reference order – See page 12).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Wu’s teaching into Rudenko’s invention because incorporating Wu’s teaching would enhance Rudenko to enable to extract the patch code and variables involved in the patch as suggested by Wu (page 9, left column).
Regarding claim 8.
A computer system comprising:
a processor set;
a set of one or more computer-readable storage media; and program instructions, collectively stored in the set of one or more storage media, for causing the processor set to perform the following computer operations:
Regarding claim 8, recites limitations as rejected claim 1 above.
Regarding claim 9, recites limitations as rejected claim 2 above.
Regarding claim 14, recites limitations as rejected claim 7 above.
Regarding claim 15.
A computer program product for detecting bugs in an application, the computer program product comprising: a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more storage media, cause a processor set to perform the following computer operations:
Regarding claim 15, recites limitations as rejected claim 1 above.
Regarding claim 16, recites limitations as rejected claim 2 above.
11. Claim(s) 3-5, 10-12 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rudenko and Wu as applied to claims 1, 8 and 15 respectively above, and further in view of Chen et al. (CN 117851101 A – IDS filed on 07/15/2024 – herein after Chen).
Regarding claim 3, the computer implemented method of claim 1,
Rudenko discloses
wherein identifying, by the processor set, code contexts associated with code segments in the patch comprises (generates abstract syntactic structure representations of code fragments in files. For instance, the trainer can use a parser(s) to create abstract syntax trees (ASTs). If multiple programming languages are represented in the files, then the trainer may use a different parser for each language – See paragraphs [0052-0053]):
identifying, by the processor set, caller functions for the code segments responsible for the one or more bugs (The pre-processing can include decomposing the prompt into the parts, generating structural representations, generating abstract and/or detailed change signatures, and pairing the different parts to then calculate values of similarity metrics for generating feature values and populating the matrix. The pre-processor 851 can include the functionality for calculating edit distances and ratios of edit distances or include calls to externally defined functions – See paragraph [0135]); and
Rudenko does not disclose
generating, by the processor set, the code contexts associated with the code segments by expanding the caller functions.
Chen discloses
generating, by the processor set, the code contexts associated with the code segments by expanding the caller functions (generating the function-level call relational graph. Extracting the code layer structure information in the code file, extracting the calling relation among different types, functions and variables by analyzing the cross function and the dependency relation among the cross files – See page 4. .
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Chen’s teaching into Rudenko’s and Wu’s inventions because incorporating Chen’s teaching would enhance Rudenko and Wu to enable to extract the calling relation among different types, functions and variables by analyzing the cross function and the dependency relation among the cross files as suggested by Chen (page 4).
Regarding claim 4, the computer implemented method of claim 1,
Rudenko discloses
wherein identifying, by the processor set, the number of target code segments in the application that are potentially affected by the one or more bugs comprises (Potentially vulnerable prompts 340 are combined with corresponding potentially vulnerable pieces of code 350 to form potentially vulnerable complete code segments 360. In some configurations, each potentially vulnerable prompt 340 is combined with the potentially vulnerable code snippet 350 it produced. if there are N potentially vulnerable prompts 340, N potentially vulnerable complete code segments 360 will be generated --See paragraph [0033]):
Rudenko does not disclose
identifying, by the processor set, a set of caller functions in the application, wherein the set of caller functions are caller functions for the code segments responsible for the one or more bugs (the function f0 where 1 is located, further obtaining the set of codes of the calling f0 in the code warehouse – See page 3) ;
identifying, by the processor set, a number of program instructions and a number of variables associated with each caller function in the set of caller functions; and
generating, by the processor set, the number of target code segments based on the set of caller functions, the number of program instructions, and the number of variables.
Chen discloses
identifying, by the processor set, a set of caller functions in the application, wherein the set of caller functions are caller functions for the code segments responsible for the one or more bugs (the application of the current large language model on the code defect restoration only stays at the function level, that is, a code segment with defect is input and then the restored code segment is given. The context extractor finds the code 1 of the position of the code defect from the code warehouse according to the structure information of the node in the function level calling relational graph. Searching the function f0 where the code 1 is located, obtaining the set Pf0 of the code for calling the function f0 in the code warehouse – See pages 2-3);
identifying, by the processor set, a number of program instructions and a number of variables associated with each caller function in the set of caller functions (sorting all the information found in the steps b) and c) into uniform format and transmitting to the next module, specifically comprising code defect 1, function set F = (f0, f1, f2, ..., fn), variable set X =(x1, x2, ..., xn), variable definition set and a set of called information of the function wherein the information in Px and Pf is in one-to-one correspondence with the elements in the set of X and F, for example, and representing the called information of the nth function fn in the storage library – See pages 6-7); and
generating, by the processor set, the number of target code segments based on the set of caller functions, the number of program instructions, and the number of variables (obtaining the functions (f1, f2, ...) except f0 in the calling function set F in the context information, respectively inputting them into the large language model, and generating the abstract and function signature of each function by the model. wherein the function signature part comprises the name of the function, the parameter list and the type of each parameter, the return value list and the type of each return value – See page 8).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Chen’s teaching into Rudenko’s and Wu’s inventions because incorporating Chen’s teaching would enhance Rudenko and Wu to enable to generating the abstract and function signature of each function by the model as suggested by Chen (page 8).
Regarding claim 5, the computer implemented method of claim 4,
Chen discloses
wherein the set of caller functions in the application is identified using a call graph for the code segments responsible for the one or more bugs (automatically searching the context information related to the code defect in the code warehouse range according to the location information of the code defect input by the user and the function-level calling relational graph – See page 3).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Chen’s teaching into Rudenko’s and Wu’s inventions because incorporating Chen’s teaching would enhance Rudenko and Wu to enable to automatically search and filter cross-function and cross-file context, and generating prompt input large language model as suggested by Chen (page 2).
Regarding claim 10, recites limitations as rejected claim 3 above.
Regarding claim 11, recites limitations as rejected claim 4 above.
Regarding claim 12, recites limitations as rejected claim 5 above.
Regarding claim 17, recites limitations as rejected claim 3 above.
Regarding claim 18, recites limitations as rejected claim 4 above.
Regarding claim 19, recites limitations as rejected claim 5 above.
13. Claim(s) 6, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rudenko and Wu and Chen as applied to claims 1, 8 and 15 respectively above, and further in view of Giesen et al. (US Pub. No. 2024/0020109 A1 – herein after Giesen).
Regarding claim 6, the computer implemented method of claim 4,
Giesen discloses
wherein the number of program instructions and the number of variables associated with each caller function in the set of caller functions are identified based on control flow analysis (the code property graph may include a combined representation of a data flow graph, a control flow graph and/or a dominator tree. Thus, the code property graph may merge three graph representations of code into a joint data structure. The contains-call-analysis may comprise analyzing sub expressions of every statement in the code property graph to find function calls and assigning a call label to each statement having a function call. Thus, suitable information for being applied and used efficiently in the vulnerability detection phase can be collected – See paragraphs [0033-0036]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Giesen’s teaching into Rudenko’s and Wu’s and Chen’s inventions because incorporating Giesen’s teaching would enhance Rudenko and Wu and Chen to enable to analyze sub expressions of every statement in the code property graph to find function calls and assigning a call label to each statement having a function call as suggested by Giesen (paragraphs [0033-0036]).
Regarding claim 13, recites limitations as rejected claim 6 above.
Regarding claim 20, recites limitations as rejected claim 6 above.
Conclusion
14. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Seck et al. (US pub. No. 2025/0156531 A1) discloses generates suggestions to replace the known and/or novel vulnerable software libraries. In response to detecting a user choosing a first replacement library in place of a first vulnerable library, the system replaces the first vulnerable library with the first replacement library – See Abstract and specification for more details.
Li et al. (US Pub. No. 2024/0053978 A1) discloses selecting a corresponding vulnerability patching mode based on different vulnerability types of the vulnerability information, and acquiring an eBPF patch bytecode file (first patch) and an eBPF patch code configuration file from a server according to the vulnerability patching mode; compiling the eBPF patch bytecode based on the eBPF patch bytecode and the eBPF patch code configuration file to generate a patch binary code file (second patch) and configuration information of the patch binary code; and adopting three approaches to trigger the patch binary code to patch the vulnerability information based on the configuration information and the vulnerability patching mode – See Abstract and specification for more details.
Bu et al. (US Pub. No. 2025/0291933 A1) discloses providing the text prompt to a generative machine learning model; receiving, from the generative machine learning model, a set of outputs including a first output identifying a first remediation strategy and a second output identifying a second remediation strategy; determining that the first output satisfies the output constraint; determining that the second output fails to satisfy the output constraint; determining, based on the first output, a final output; and providing the final output using an output interface – See Abstract and specification for more details.
Garg et al. (US Patent No. 12,242,372 B2) discloses a performance bug given a prompt including a code transformation instruction. The code transformation instruction guides the model on how to predict the repair code when the model has not been fine-tuned for the repair code task – See Abstract and specification for more details.
Narayan et al. (US Pub. No. 2026/0003954 A1) discloses detecting a call flow associated with the code sample, (iii) determining whether to inject a software development kit (SDK) to the code sample based at least in part on the call flow, and (iv) in response to determining to inject the SDK to the code sample: (a) automatically injecting the SDK to the code sample to obtain an SDK-injected code sample, and (b) providing the SDK-injected code sample – See Abstract and specification for more details.
Sumedrea et al. (US Pub. No. 2025/0139251 A1) discloses identifies a vulnerability corresponding to an initial source code. Then, the approach generates a prompt comprising the initial source code and the vulnerability. The approach inputs the prompt into an artificial intelligence model (AIM) that is trained to determine whether the initial source code comprises the vulnerability. In turn, the approach removes, using the AIM, the vulnerability from the initial source code to produce a refactored source code in response to determining that the initial source code comprises the vulnerability – See Abstract and specification for more details.
Ou et al. (US pub. No. 2025/0245349 A1) discloses each of the plurality of code locations corresponds to at least one of the plurality of detected vulnerabilities. One or more false positive vulnerabilities in the plurality of detected vulnerabilities are identified. A plurality of augmented prompts is generated, based on the one or more false positive vulnerabilities. The plurality of augmented prompts is outputted to a database of prompts for use in future code analyses, without necessarily having to retrain the AI model – See Abstract and specification for more details.
Florian Tambon (Bugs in Large Language Models Generated Code: An Empirical Study, 2024) discloses generate code in different programming languages based on provided prompts, fulfilling a long-lasting dream in Software Engineering (SE), i.e., automatic code generation. Similar to human-written code, LLM-generated code is prone to bugs, and these bugs have not yet been thoroughly examined by the community. Given the increasing adoption of LLM based code generation tools (e.g., GitHub Copilot) in SE activities, it is critical to understand the characteristics of bugs contained in code generated by LLMs – See Abstract and specification for more details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Hyung S. Sough can be reached at 571-272-6799. 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192
Prosecution Insights