CTFR 18/522,697 CTFR 93572 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Summary This action is a responsive to the amendment filed on 2/18/2026. Claims 1-20 are pending and have been examined. Claims 1-20 are rejected. Response to Arguments Rejection of Claims under 35 USC 103 Applicant’s Response: The art of record is not seen to disclose or to suggest the foregoing features of the amended independent claims. For example, the art of record is not seen to disclose or to suggest generation of a reduced graph including only paths which originate at a source node, include at least one node representing code regions changed by applying a software patch to program, and terminate at a sink node. Sun et al. describes generation of a pre-patch Code Property Graph (CPG) 218 and a post-patch CPG 220. The pre-patch CPG 218 is generated based on pre-patch source code 206, which may include only pre-patch functions 212 which have been determined to be "involved" with a software patch. The post-patch CPG 220 is generated based on post-patch source code 208, which may include only post-patch functions 214 which have also been determined to be involved with the software patch. Sun et al., paragraphs [0041]-[0042]. Accordingly, the intermediate complete patchCPG 224 of Sun et al. includes all nodes Vpre and Vpost and all edges Epre and Epost of the pre-patch 218 and post-patch 220 CPGs, respectively. Sun et al. further describes applying a program slicing technique to the intermediate complete patchCPG 224 to generate the patchCPG 228. The program slicing technique may limit the range of context code according to the hop count towards the nodes of deleted/added statements. Sun et al., paragraph [0046]. Nowhere does Sun et al. describe slicing the intermediate complete patchCPG 224 such that resulting patchCPG 228includes only paths which originate at a source node, include at least one node representing code regions changed by applying a software patch to program, and terminate at a sink node. Singh et al. describes identification of source and sink functions for purposes of building an architectural graph. Singh et al. is therefore not seen to remedy the foregoing deficiencies in Sun et al. Withdrawal of the rejection under 35 U.S.C. § 103 is respectfully requested. Examiner’s Response: 07-37 AIA Applicant's arguments filed 2/18/26 have been fully considered but they are not persuasive. The amended limitation states: generating a reduced graph including only the identified plurality of paths, the reduced graph including each of the identified first nodes In other words, create a graph which only includes paths that were changed. Sun et al. (US 20240411886 A1), hereinafter Sun, teaches this amended limitation. At 210, the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214. At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. ¶¶ [0040]-[0042] The post-patch CPG is generated only with paths that were modified by the patch. Thus, teaching a language of the limitation . Information Disclosure Statement 06-52 The information disclosure statement (IDS) submitted on 11/20/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-20-02-aia AIA This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 07-21-aia AIA Claim s 1-6, 9-14, 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. (US 20240411886 A1) and further in view of Singh et al. (US 20120011493 A1) and Najafirad et al. (US 20240354424 A1) . As to claim 1, Sun et al. teaches a system comprising: a memory storing processor-executable program code; and at least one processing unit to execute the processor-executable program code to cause the system to: receive source code files of a software program including source code regions changed by applying a software patch to the program (See ¶ [0038], Teaches that a target software patch may be received. For example, the target software patch may be received from a local or remote database and/or from the software developer for the software associated with the target software patch. At 204, the pre-patch source code 206 and the post-patch source code 208 are retrieved. For example, the pre-patch source code 206 and the post-patch source code 208 may be retrieved based on the received target software patch. Though the target patch contains multiple lines of context code (e.g., three lines ahead and behind the changed code snippet), critical context related to the target software patch and outside the range of the context code may be missed. Accordingly, the computing device may retrieve the files of full source code before and after applying the patch. Thus, we can obtain the source code files of both pre-patch and post-patch versions. To retrieve the related files in pre-patch 206 and post-patch 208 versions, we implement a parser to analyze the target software patch 202. For example, the target software patch 202 may comprise a software identifier that identifies the software to which the target patch is to be applied. For example, each target patch can be uniquely identified by a commit ID (e.g., a 20-byte SHA-1 hash). For example, the computing device may retrieve and/or receive the pre-patch source code 206 and the post-patch source code based on the software identifier. For example, given the commit ID of the target patch, the source code can be rolled back exactly to the point before and after applying the target patch by using, for example, a git reset command.) ; generate an interprocedural data flow graph based on the source code files (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) ; identify first nodes of the interprocedural data flow graph representing the source code regions changed by applying the software patch to the program (See ¶¶ [0040]-[0041], Teaches that the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214.) ; generating a reduced graph including only the identified plurality of paths, the reduced graph including each of the identified first nodes (See ¶¶ [0040]-[0042], Teaches that At 210, the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214. At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214.) . However, it does not expressly teach the details of identify a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at a source node of the graph, including at least one of the identified first nodes, and terminating at a sink node of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths; input the reduced graph to a trained classification model to generate a classification; and present the classification. Singh et al., from analogous art, teaches identify a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at a source node of the graph, including at least one of the identified first nodes, and terminating at a sink node of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into Sun et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . However, it does not expressly teach the details of input the reduced graph to a trained classification model to generate a classification; and present the classification. Najafirad et al., from analogous art, teaches input the reduced graph to a trained classification model to generate a classification; and present the classification (See ¶¶ [0038], [0040] Teaches that Block 104 represents the generation of SVG from the token list. Block 105 represents the training of the multitask GCN model, a main component of an exemplary source code vulnerability detection and classification using Focal Loss. Block 106 represents the trained CNN model which is used for inference for detecting code vulnerabilities. Block 107 and 108 represents the classification and description of the captured vulnerability by block 106. Finally block 109 represents the analysis of the outcome by the GCN model showing the importance of poacher flow edges. FIG. 5 shows an Overall Architecture of an exemplary system. An exemplary classifier is divided into three parts. Initially, the input source code is converted to tokens using block 501. Then RoBERTa in block 503 layer generates embedding for each token/node of the. Then block 502 generates the SVG of the source code. Finally, the GCN layer in block 504, takes the node embedding and adjacency matrix for feature generation. Focal Loss forces the model to learn more about the minority class. The MLP layer in block 505 and 506 decides whether a function is vulnerable by leveraging the Focal Loss Function.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Najafirad et al. into the combination of Sun et al. and Singh et al. in order to detect vulnerability using machine learning in source code (See Najafirad et al. ¶ [0004]) . As to claim 2, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 1 above. Sun et al. further teaches wherein generation of an interprocedural data flow graph based on the source code files comprises: generation of an intraprocedural disconnected graph based on the source code files; insertion of call edges into the intraprocedural disconnected graph to generate a connected graph; and insertion of interprocedural data flow information into the connected graph (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) . As to claim 3, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 2 above. However, it does not expressly teach the details of the at least one processing unit to execute the processor-executable program code to cause the system to: determine and attach value bounds to a plurality of nodes of the interprocedural data flow graph. Singh et al., from analogous art, teaches the at least one processing unit to execute the processor-executable program code to cause the system to: determine and attach value bounds to a plurality of nodes of the interprocedural data flow graph (See ¶¶ [0061]-[0063], Teaches that During a weight assigning step 346, an embodiment assigns weights to code changes 208, to assist production of a list of changes in order of decreasing likely relevance to security vulnerabilities, for example. Weights may be assigned 346 in various ways. For example, some embodiments assign 346, 348 weights using zero or another predetermined threshold 350. Some changes are assigned a weight above the threshold (e.g., changes on a flow between a sink and a source function) while other changes are assigned a weight below the threshold (e.g., changes 208 not on such a flow). Some embodiments assign 346, 352 weights additively. A code change that has multiple characteristics 210 indicating likely relevance receives the sum of the respective weights, while other embodiments assign 346 weights non-additively, e.g., by assigning a change 208 the most recent or the greatest of the weights for characteristics 210 exhibited by the change 208.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 4, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein each of the source nodes represents source function code of the program, and wherein each of the sink nodes represents sink function code of the program. Singh et al., from analogous art, teaches wherein each of the source nodes represents source function code of the program, and wherein each of the sink nodes represents sink function code of the program (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 5, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein identification of the plurality of paths of the graph comprises: determination of a plurality of forward edit paths of the graph, each of which begins at one of the first nodes and terminates at a sink node; determination of a plurality of backward edit paths of the graph, each of which begins at one of the first nodes and terminates at a source node; and combination of the plurality of forward edit paths and the plurality of backward edit paths based on their common first nodes. Singh et al., from analogous art, teaches wherein identification of the plurality of paths of the graph comprises: determination of a plurality of forward edit paths of the graph, each of which begins at one of the first nodes and terminates at a sink node; determination of a plurality of backward edit paths of the graph, each of which begins at one of the first nodes and terminates at a source node; and combination of the plurality of forward edit paths and the plurality of backward edit paths based on their common first nodes (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 6, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 1 above. Sun et al. further teaches wherein the classification model is trained based on labeled reduced graphs (See ¶ [0063], Teaches that The system 400 may be configured to use machine-learning techniques to train, based on an analysis of one or more training datasets 410A-410B by a training module 420, the at least one prediction model 430. The at least one prediction model 430, once trained, may be configured to determine or predict if a target software patch is a security patent or a non-security patch based on an evaluation of a patchCPG generated based on the target software patch. A dataset may be determined or derived from a plurality of software patches, both security software patches and non-security software patches. For example, historical software patches may be used by the training module 420 to train the at least one prediction model 430. Each of the patchCPGs derived from the historical software patches and the identifier of the type of software patch (e.g., a security software patch or a non-security software patch) may be associated with one or more multimodal features of a plurality of multimodal features that are associated with the determination or prediction of whether a software patch is a security software patch or a non-security software patch. The plurality of multimodal features and example software patches and associated identifiers may be used to train the at least one prediction model 430.) . As to claim 9, Sun et al. teaches a method comprising: receiving source code files of a program, the program including source code regions changed by applying a patch to the program (See ¶ [0038], Teaches that a target software patch may be received. For example, the target software patch may be received from a local or remote database and/or from the software developer for the software associated with the target software patch. At 204, the pre-patch source code 206 and the post-patch source code 208 are retrieved. For example, the pre-patch source code 206 and the post-patch source code 208 may be retrieved based on the received target software patch. Though the target patch contains multiple lines of context code (e.g., three lines ahead and behind the changed code snippet), critical context related to the target software patch and outside the range of the context code may be missed. Accordingly, the computing device may retrieve the files of full source code before and after applying the patch. Thus, we can obtain the source code files of both pre-patch and post-patch versions. To retrieve the related files in pre-patch 206 and post-patch 208 versions, we implement a parser to analyze the target software patch 202. For example, the target software patch 202 may comprise a software identifier that identifies the software to which the target patch is to be applied. For example, each target patch can be uniquely identified by a commit ID (e.g., a 20-byte SHA-1 hash). For example, the computing device may retrieve and/or receive the pre-patch source code 206 and the post-patch source code based on the software identifier. For example, given the commit ID of the target patch, the source code can be rolled back exactly to the point before and after applying the target patch by using, for example, a git reset command.) ; generating an interprocedural data flow graph from the source code files (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) ; identifying first nodes of the interprocedural data flow graph representing the source code regions changed by applying the patch to the program (See ¶¶ [0040]-[0041], Teaches that the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214.) ; generating a reduced graph including only the identified plurality of paths, the reduced graph including each of the identified first nodes (See ¶¶ [0040]-[0042], Teaches that At 210, the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214. At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214.) . However, it does not expressly teach the details of identifying a plurality of source nodes of the graph; identifying a plurality of sink nodes of the graph; identifying a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at one of the plurality of source nodes of the graph, including at least one of the identified first nodes, and terminating at one of the plurality of sink nodes of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths; and inputting the reduced graph to a trained classification model to generate a classification. Singh et al., from analogous art, teaches identifying a plurality of source nodes of the graph; identifying a plurality of sink nodes of the graph; identifying a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at one of the plurality of source nodes of the graph, including at least one of the identified first nodes, and terminating at one of the plurality of sink nodes of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into Sun et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . However, it does not expressly teach the details of inputting the reduced graph to a trained classification model to generate a classification. Najafirad et al., from analogous art, teaches inputting the reduced graph to a trained classification model to generate a classification (See ¶¶ [0038], [0040] Teaches that Block 104 represents the generation of SVG from the token list. Block 105 represents the training of the multitask GCN model, a main component of an exemplary source code vulnerability detection and classification using Focal Loss. Block 106 represents the trained CNN model which is used for inference for detecting code vulnerabilities. Block 107 and 108 represents the classification and description of the captured vulnerability by block 106. Finally block 109 represents the analysis of the outcome by the GCN model showing the importance of poacher flow edges. FIG. 5 shows an Overall Architecture of an exemplary system. An exemplary classifier is divided into three parts. Initially, the input source code is converted to tokens using block 501. Then RoBERTa in block 503 layer generates embedding for each token/node of the. Then block 502 generates the SVG of the source code. Finally, the GCN layer in block 504, takes the node embedding and adjacency matrix for feature generation. Focal Loss forces the model to learn more about the minority class. The MLP layer in block 505 and 506 decides whether a function is vulnerable by leveraging the Focal Loss Function.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Najafirad et al. into the combination of Sun et al. and Singh et al. in order to detect vulnerability using machine learning in source code (See Najafirad et al. ¶ [0004]) . As to claim 10, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 9 above. Sun et al. further teaches wherein generating an interprocedural data flow graph from the source code files comprises: generating an intraprocedural disconnected graph based on the source code files; inserting call edges into the intraprocedural disconnected graph to generate a connected graph; and inserting interprocedural data flow information into the connected graph (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) . As to claim 11, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 10 above. However, it does not expressly teach the details of further comprising: determining and attaching value bounds to a plurality of nodes of the interprocedural data flow graph. Singh et al., from analogous art, teaches further comprising: determining and attaching value bounds to a plurality of nodes of the interprocedural data flow graph (See ¶¶ [0061]-[0063], Teaches that During a weight assigning step 346, an embodiment assigns weights to code changes 208, to assist production of a list of changes in order of decreasing likely relevance to security vulnerabilities, for example. Weights may be assigned 346 in various ways. For example, some embodiments assign 346, 348 weights using zero or another predetermined threshold 350. Some changes are assigned a weight above the threshold (e.g., changes on a flow between a sink and a source function) while other changes are assigned a weight below the threshold (e.g., changes 208 not on such a flow). Some embodiments assign 346, 352 weights additively. A code change that has multiple characteristics 210 indicating likely relevance receives the sum of the respective weights, while other embodiments assign 346 weights non-additively, e.g., by assigning a change 208 the most recent or the greatest of the weights for characteristics 210 exhibited by the change 208.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 12, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 9 above. However, it does not expressly teach the details of wherein each of the identified source nodes represents source function code of the program, and wherein each of the identified sink nodes represents sink function code of the program. Singh et al., from analogous art, teaches wherein each of the identified source nodes represents source function code of the program, and wherein each of the identified sink nodes represents sink function code of the program (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 13, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 9 above. However, it does not expressly teach the details of wherein identifying the plurality of paths of the graph comprises: determining a plurality of forward edit paths of the graph, each of which begins at one of the first nodes and terminates at a sink node; determining a plurality of backward edit paths of the graph, each of which begins at one of the first nodes and terminates at a source node; and combining the plurality of forward edit paths and the plurality of backward edit paths based on their common first nodes. Singh et al., from analogous art, teaches wherein identifying the plurality of paths of the graph comprises: determining a plurality of forward edit paths of the graph, each of which begins at one of the first nodes and terminates at a sink node; determining a plurality of backward edit paths of the graph, each of which begins at one of the first nodes and terminates at a source node; and combining the plurality of forward edit paths and the plurality of backward edit paths based on their common first nodes (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . As to claim 14, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 9 above. Sun et al. further teaches wherein the classification model is trained based on labeled reduced graphs (See ¶ [0063], Teaches that The system 400 may be configured to use machine-learning techniques to train, based on an analysis of one or more training datasets 410A-410B by a training module 420, the at least one prediction model 430. The at least one prediction model 430, once trained, may be configured to determine or predict if a target software patch is a security patent or a non-security patch based on an evaluation of a patchCPG generated based on the target software patch. A dataset may be determined or derived from a plurality of software patches, both security software patches and non-security software patches. For example, historical software patches may be used by the training module 420 to train the at least one prediction model 430. Each of the patchCPGs derived from the historical software patches and the identifier of the type of software patch (e.g., a security software patch or a non-security software patch) may be associated with one or more multimodal features of a plurality of multimodal features that are associated with the determination or prediction of whether a software patch is a security software patch or a non-security software patch. The plurality of multimodal features and example software patches and associated identifiers may be used to train the at least one prediction model 430.) . As to claim 17, Sun et al. teaches a non-transitory computer-readable recording medium storing processor-executable code, the code executable by a computing system to: receive source code files of a program, the program including source code regions changed by applying a patch to the program (See ¶ [0038], Teaches that a target software patch may be received. For example, the target software patch may be received from a local or remote database and/or from the software developer for the software associated with the target software patch. At 204, the pre-patch source code 206 and the post-patch source code 208 are retrieved. For example, the pre-patch source code 206 and the post-patch source code 208 may be retrieved based on the received target software patch. Though the target patch contains multiple lines of context code (e.g., three lines ahead and behind the changed code snippet), critical context related to the target software patch and outside the range of the context code may be missed. Accordingly, the computing device may retrieve the files of full source code before and after applying the patch. Thus, we can obtain the source code files of both pre-patch and post-patch versions. To retrieve the related files in pre-patch 206 and post-patch 208 versions, we implement a parser to analyze the target software patch 202. For example, the target software patch 202 may comprise a software identifier that identifies the software to which the target patch is to be applied. For example, each target patch can be uniquely identified by a commit ID (e.g., a 20-byte SHA-1 hash). For example, the computing device may retrieve and/or receive the pre-patch source code 206 and the post-patch source code based on the software identifier. For example, given the commit ID of the target patch, the source code can be rolled back exactly to the point before and after applying the target patch by using, for example, a git reset command.) ; generate an interprocedural data flow graph from the source code files (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) ; identify first nodes of the interprocedural data flow graph representing the source code regions changed by applying the patch to the program (See ¶¶ [0040]-[0041], Teaches that the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214.) ; generating a reduced graph including only the identified plurality of paths, the reduced graph including each of the identified first nodes (See ¶¶ [0040]-[0042], Teaches that At 210, the code in the pre-patch source code 206 and the post-patch source code 208 is analyzed. For example the code is analyzed to determine the functions involved in the patch within the source code 206, 208 and the functions not involved in the patch within the source code 206, 208. There may be multiple code files in each software version of the pre-patch source code 206 and the post-patch source code 208. However, analysis may be limited to the files modified by the target software patch. For example, these files within the target software page may be identified by the header lines starting with −−− and +++ (e.g., Line 3-4 in Listing 3). An analysis may be conducted to determine the functions containing code revisions in the target software patch. Unrevised functions from the source code 206, 208 may be removed instead of retaining all revised functions. For example, all functions within the source code 206, 208 may be determined. The scope (e.g., the line number range between function start and function end) of the determined functions within the source code 206, 208 may further be determined via a parser, such as a Joern parser. For example, the target software patch may contain the scope or range information showing the line numbers of changed code in pre-patch 206 and post-patch 208 source code files, e.g., in Line 5 of Listing 3, Line 3439 is deleted from the unpatched file and Line 3444-3447 arc added to the patched file. The scopes of the pre-patch 206 and post-patch 208 source code may be compared with those line numbers of the code revised by the target software patch. For example, the computing device may determine the pre-patch functions 212 involved in the patch within the pre-patch source code 206 and, at 216, may remove the pre-patch functions not involved in the patch within the pre-patch source code 206 from the pre-patch source code. For example, the computing device may determine the post-patch functions 214 involved in the patch within the post-patch source code 208 and at 216, may remove the post-patch functions not involved in the patch within the post-patch source code 208 from the post-patch source code. After removing functions that do not contain code revisions, what is left is the patch-related functions 212, 214. At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214.) . However, it does not expressly teach the details of identify a plurality of source nodes of the graph; identify a plurality of sink nodes of the graph; identify a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at one of the plurality of source nodes of the graph, including at least one of the identified first nodes, and terminating at one of the plurality of sink nodes of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths; and input the reduced graph to a trained classification model to generate a classification. Singh et al., from analogous art, teaches identify a plurality of source nodes of the graph; identify a plurality of sink nodes of the graph; identify a plurality of paths of the interprocedural data flow graph, each of the identified plurality of paths originating at one of the plurality of source nodes of the graph, including at least one of the identified first nodes, and terminating at one of the plurality of sink nodes of the graph, where each of the identified first nodes is included in at least one of the identified plurality of paths (See ¶¶ [0054]-[0056], Teaches that During a source function identifying step 308, an embodiment identifies one or more source functions 310, such as functions 126 capable of receiving textual input over a network or through a user interface or from a file, for instance. Step 308 may be accomplished in various ways discussed herein, for example. During a sink function recognizing step 312, an embodiment identifies one or more sink functions 314, such as functions 126 capable of manipulating strings or memory, for instance. Step 312 may be accomplished in various ways discussed herein, for example. Note that use of “recognizing” in labeling step 312 promotes convenient reference to this step, just as use of “identifying” promotes convenient reference to step 308. The terms serve as labels, in the sense that one could also have used “recognizing” for step 308 and “identifying” for step 312 and obtained an equivalent document. During a graph constructing step 316, an embodiment constructs at least one architectural graph 214, such as a control flow graph, a data flow graph, or a program dependency graph, for example. Step 316 may assist step 308 and/or step 312 in identifying/recognizing certain functions. Step 316 may also inform weight assigning steps discussed below, by providing information as to the relative location of code changes 208, e.g., whether a change is on a flow between a source function and a sink function. Step 316 may be accomplished using familiar architectural graph construction mechanisms, for example. In particular, data flow analysis may be performed using the Desquirr decompiler plug-in from sourceforge dot net, the BeaEngine disassemble library from beaengine dot org, or the OBJRec plug-in from openrce dot org, for example.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into Sun et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . However, it does not expressly teach the details of input the reduced graph to a trained classification model to generate a classification. Najafirad et al., from analogous art, teaches input the reduced graph to a trained classification model to generate a classification (See ¶¶ [0038], [0040] Teaches that Block 104 represents the generation of SVG from the token list. Block 105 represents the training of the multitask GCN model, a main component of an exemplary source code vulnerability detection and classification using Focal Loss. Block 106 represents the trained CNN model which is used for inference for detecting code vulnerabilities. Block 107 and 108 represents the classification and description of the captured vulnerability by block 106. Finally block 109 represents the analysis of the outcome by the GCN model showing the importance of poacher flow edges. FIG. 5 shows an Overall Architecture of an exemplary system. An exemplary classifier is divided into three parts. Initially, the input source code is converted to tokens using block 501. Then RoBERTa in block 503 layer generates embedding for each token/node of the. Then block 502 generates the SVG of the source code. Finally, the GCN layer in block 504, takes the node embedding and adjacency matrix for feature generation. Focal Loss forces the model to learn more about the minority class. The MLP layer in block 505 and 506 decides whether a function is vulnerable by leveraging the Focal Loss Function.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Najafirad et al. into the combination of Sun et al. and Singh et al. in order to detect vulnerability using machine learning in source code (See Najafirad et al. ¶ [0004]) . As to claim 18, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the medium according to claim 17 above. Sun et al. further teaches wherein generation of an interprocedural data flow graph from the source code files comprises: generation of an intraprocedural disconnected graph based on the source code files; insertion of call edges into the intraprocedural disconnected graph to generate a connected graph; and insertion of interprocedural data flow information into the connected graph (See ¶ [0042], Teaches that At 218, a pre-patch CPG is generated. For example, the pre-patch CPG may be generated based on the pre-patch source code 206, such as pre-patch functions 212 involved in the target software patch. At 220, a post-patch CPG is generated. For example, the post-patch CPG may be generated based on the post-patch source code 208, such as the post-patch functions 214. For example, the Joern parser may be used to generate the pre-patch CPG 218 and the post-patch CPG 220 (e.g., Gpre and Gpost respectively). For example, in each CPG 218, 220, the graph may be described with two sets: (V, E). For example, V is a set of nodes represented with 2-tuple (id, code), where id is a number to identify the node and code is the source code component depicted by this node (e.g., a code token in AST or a statement in CDG/DDG). E may comprise a set of directed edges represented with 3-tuple (id1, id2, type), where id1 and id2 represent the IDs of start and end nodes. type ∈ {AST, CDG, DDG} is the edge type indicating if the edge belongs to the AST or denotes control/data dependency. Therefore, two separate CPGs 218, 220 of the pre-patch 206 and post-patch 208 source code are generated, respectively.) . As to claim 19, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the medium according to claim 18 above. However, it does not expressly teach the details of wherein generation of an interprocedural data flow graph from the source code files comprises: determination and attachment of value bounds to a plurality of nodes of the interprocedural data flow graph. Singh et al., from analogous art, teaches wherein generation of an interprocedural data flow graph from the code files comprises: determination and attachment of value bounds to a plurality of nodes of the interprocedural data flow graph (See ¶¶ [0061]-[0063], Teaches that During a weight assigning step 346, an embodiment assigns weights to code changes 208, to assist production of a list of changes in order of decreasing likely relevance to security vulnerabilities, for example. Weights may be assigned 346 in various ways. For example, some embodiments assign 346, 348 weights using zero or another predetermined threshold 350. Some changes are assigned a weight above the threshold (e.g., changes on a flow between a sink and a source function) while other changes are assigned a weight below the threshold (e.g., changes 208 not on such a flow). Some embodiments assign 346, 352 weights additively. A code change that has multiple characteristics 210 indicating likely relevance receives the sum of the respective weights, while other embodiments assign 346 weights non-additively, e.g., by assigning a change 208 the most recent or the greatest of the weights for characteristics 210 exhibited by the change 208.) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Singh et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See Singh et al. ¶ [0004]) . 07-21-aia AIA Claim s 7-8, 15-16, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. (US 20240411886 A1) and Singh et al. (US 20120011493 A1) and Najafirad et al. (US 20240354424 A1) and further in view of LI et al. (US 20240419806 A1) . As to claim 7, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the system according to claim 6 above. However, it does not expressly teach the details of wherein the labeled reduced graphs comprise: a first labeled reduced graph generated based on a first version of the software program associated with a first patch, and labeled as Clean; and a second labeled reduced graph generated based on a second version of the software program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable. LI et al., from analogous art, teaches wherein the labeled reduced graphs comprise: a first labeled reduced graph generated based on a first version of the software program associated with a first patch, and labeled as Clean; and a second labeled reduced graph generated based on a second version of the software program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable (See ¶¶ [0108]-[0109], Teaches that The present systems and methods were evaluated using two semi-synthetic datasets and two real world datasets. The semi-synthetic datasets are commonly used as a benchmark in the vulnerability detection task, though the practical implications for a method should not solely depend on the synthetic results as they are less complex. The real world datasets are often much larger and can contain less trivial vulnerabilities. The evaluation metrics reported include accuracy, precision, recall, F1 score, and area under the ROC curve (AUC). Each dataset was randomly split into 75% for training and 25% for evaluation. Some metrics are not shown in the baselines due to their absence in the original works. As indicated, four datasets were used for evaluation in total, where two were semisynthetic vulnerabilities and two were real world vulnerabilities and Common Vulnerability Exposures (CVE). The labels for all datasets are binary that splits into vulnerable and non-vulnerable) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LI et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See LI et al. ¶ [0004]) . As to claim 8, the combination of Sun et al. and Singh et al. and Najafirad et al. and LI et al. teaches the system according to claim 7 above. However, it does not expressly teach the details of wherein the labeled reduced graphs comprise: a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean. LI et al., from analogous art, teaches wherein the labeled reduced graphs comprise: a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean (See ¶¶ [0108]-[0109], Teaches that The present systems and methods were evaluated using two semi-synthetic datasets and two real world datasets. The semi-synthetic datasets are commonly used as a benchmark in the vulnerability detection task, though the practical implications for a method should not solely depend on the synthetic results as they are less complex. The real world datasets are often much larger and can contain less trivial vulnerabilities. The evaluation metrics reported include accuracy, precision, recall, F1 score, and area under the ROC curve (AUC). Each dataset was randomly split into 75% for training and 25% for evaluation. Some metrics are not shown in the baselines due to their absence in the original works. As indicated, four datasets were used for evaluation in total, where two were semisynthetic vulnerabilities and two were real world vulnerabilities and Common Vulnerability Exposures (CVE). The labels for all datasets are binary that splits into vulnerable and non-vulnerable) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LI et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. and LI et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See LI et al. ¶ [0004]) . As to claim 15, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the method according to claim 14 above. However, it does not expressly teach the details of wherein the labeled reduced graphs comprise: a first labeled reduced graph generated based on a first version of the program associated with a first patch, and labeled as Clean; and a second labeled reduced graph generated based on a second version of the program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable. LI et al., from analogous art, teaches wherein the labeled reduced graphs comprise: a first labeled reduced graph generated based on a first version of the program associated with a first patch, and labeled as Clean; and a second labeled reduced graph generated based on a second version of the program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable (See ¶¶ [0108]-[0109], Teaches that The present systems and methods were evaluated using two semi-synthetic datasets and two real world datasets. The semi-synthetic datasets are commonly used as a benchmark in the vulnerability detection task, though the practical implications for a method should not solely depend on the synthetic results as they are less complex. The real world datasets are often much larger and can contain less trivial vulnerabilities. The evaluation metrics reported include accuracy, precision, recall, F1 score, and area under the ROC curve (AUC). Each dataset was randomly split into 75% for training and 25% for evaluation. Some metrics are not shown in the baselines due to their absence in the original works. As indicated, four datasets were used for evaluation in total, where two were semisynthetic vulnerabilities and two were real world vulnerabilities and Common Vulnerability Exposures (CVE). The labels for all datasets are binary that splits into vulnerable and non-vulnerable) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LI et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See LI et al. ¶ [0004]) . As to claim 16, the combination of Sun et al. and Singh et al. and Najafirad et al. and LI et al. teaches the method according to claim 15 above. However, it does not expressly teach the details of wherein the labeled reduced graphs comprise: a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean. LI et al., from analogous art, teaches wherein the labeled reduced graphs comprise: a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean (See ¶¶ [0108]-[0109], Teaches that The present systems and methods were evaluated using two semi-synthetic datasets and two real world datasets. The semi-synthetic datasets are commonly used as a benchmark in the vulnerability detection task, though the practical implications for a method should not solely depend on the synthetic results as they are less complex. The real world datasets are often much larger and can contain less trivial vulnerabilities. The evaluation metrics reported include accuracy, precision, recall, F1 score, and area under the ROC curve (AUC). Each dataset was randomly split into 75% for training and 25% for evaluation. Some metrics are not shown in the baselines due to their absence in the original works. As indicated, four datasets were used for evaluation in total, where two were semisynthetic vulnerabilities and two were real world vulnerabilities and Common Vulnerability Exposures (CVE). The labels for all datasets are binary that splits into vulnerable and non-vulnerable) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LI et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. and LI et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See LI et al. ¶ [0004]) . As to claim 20, the combination of Sun et al. and Singh et al. and Najafirad et al. teaches the medium according to claim 17 above. However, it does not expressly teach the details of herein the classification model is trained based on labeled reduced graphs comprising: a first labeled reduced graph generated based on a first version of the program associated with a first patch, and labeled as Clean; a second labeled reduced graph generated based on a second version of the program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable; and a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean. LI et al., from analogous art, teaches herein the classification model is trained based on labeled reduced graphs comprising: a first labeled reduced graph generated based on a first version of the program associated with a first patch, and labeled as Clean; a second labeled reduced graph generated based on a second version of the program associated with a second patch applied to the program prior to the first patch, wherein the second patch and the first patch change at least one common source code region, the second labeled reduced graph labeled as Vulnerable; and a third labeled reduced graph generated based on a third version of the software program associated with a third patch applied to the program prior to the first patch, wherein the third patch and the first patch do not change at least one common source code region, the third labeled reduced graph labeled as Clean (See ¶¶ [0108]-[0109], Teaches that The present systems and methods were evaluated using two semi-synthetic datasets and two real world datasets. The semi-synthetic datasets are commonly used as a benchmark in the vulnerability detection task, though the practical implications for a method should not solely depend on the synthetic results as they are less complex. The real world datasets are often much larger and can contain less trivial vulnerabilities. The evaluation metrics reported include accuracy, precision, recall, F1 score, and area under the ROC curve (AUC). Each dataset was randomly split into 75% for training and 25% for evaluation. Some metrics are not shown in the baselines due to their absence in the original works. As indicated, four datasets were used for evaluation in total, where two were semisynthetic vulnerabilities and two were real world vulnerabilities and Common Vulnerability Exposures (CVE). The labels for all datasets are binary that splits into vulnerable and non-vulnerable) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LI et al. into the combination of Sun et al. and Singh et al. and Najafirad et al. in order to automatically identify source functions, automatically recognize sink functions, and then automatically assign weights to respective patch differences that are located between some identified source function and some recognized sink function (See LI et al. ¶ [0004]) . Conclusion 07-40 AIA 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 James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4:00 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at (571) 272-3951. 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. James Hollister /J.R.H./Examiner, Art Unit 2499 5/27/26 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499 Application/Control Number: 18/522,697 Page 2 Art Unit: 2499 Application/Control Number: 18/522,697 Page 3 Art Unit: 2499 Application/Control Number: 18/522,697 Page 4 Art Unit: 2499 Application/Control Number: 18/522,697 Page 5 Art Unit: 2499 Application/Control Number: 18/522,697 Page 6 Art Unit: 2499 Application/Control Number: 18/522,697 Page 7 Art Unit: 2499 Application/Control Number: 18/522,697 Page 8 Art Unit: 2499 Application/Control Number: 18/522,697 Page 9 Art Unit: 2499 Application/Control Number: 18/522,697 Page 10 Art Unit: 2499 Application/Control Number: 18/522,697 Page 11 Art Unit: 2499 Application/Control Number: 18/522,697 Page 12 Art Unit: 2499 Application/Control Number: 18/522,697 Page 13 Art Unit: 2499 Application/Control Number: 18/522,697 Page 14 Art Unit: 2499 Application/Control Number: 18/522,697 Page 15 Art Unit: 2499 Application/Control Number: 18/522,697 Page 16 Art Unit: 2499 Application/Control Number: 18/522,697 Page 17 Art Unit: 2499 Application/Control Number: 18/522,697 Page 18 Art Unit: 2499 Application/Control Number: 18/522,697 Page 19 Art Unit: 2499 Application/Control Number: 18/522,697 Page 20 Art Unit: 2499 Application/Control Number: 18/522,697 Page 21 Art Unit: 2499 Application/Control Number: 18/522,697 Page 22 Art Unit: 2499 Application/Control Number: 18/522,697 Page 23 Art Unit: 2499 Application/Control Number: 18/522,697 Page 24 Art Unit: 2499 Application/Control Number: 18/522,697 Page 25 Art Unit: 2499 Application/Control Number: 18/522,697 Page 26 Art Unit: 2499 Application/Control Number: 18/522,697 Page 27 Art Unit: 2499 Application/Control Number: 18/522,697 Page 28 Art Unit: 2499 Application/Control Number: 18/522,697 Page 29 Art Unit: 2499 Application/Control Number: 18/522,697 Page 31 Art Unit: 2499 Application/Control Number: 18/522,697 Page 32 Art Unit: 2499 Application/Control Number: 18/522,697 Page 33 Art Unit: 2499 Application/Control Number: 18/522,697 Page 34 Art Unit: 2499 Application/Control Number: 18/522,697 Page 35 Art Unit: 2499 Application/Control Number: 18/522,697 Page 36 Art Unit: 2499 Application/Control Number: 18/522,697 Page 37 Art Unit: 2499 Application/Control Number: 18/522,697 Page 38 Art Unit: 2499 Application/Control Number: 18/522,697 Page 39 Art Unit: 2499 Application/Control Number: 18/522,697 Page 40 Art Unit: 2499 Application/Control Number: 18/522,697 Page 41 Art Unit: 2499 Application/Control Number: 18/522,697 Page 42 Art Unit: 2499 Application/Control Number: 18/522,697 Page 43 Art Unit: 2499 Application/Control Number: 18/522,697 Page 44 Art Unit: 2499 Application/Control Number: 18/522,697 Page 45 Art Unit: 2499 Application/Control Number: 18/522,697 Page 46 Art Unit: 2499 Application/Control Number: 18/522,697 Page 47 Art Unit: 2499 Application/Control Number: 18/522,697 Page 48 Art Unit: 2499 Application/Control Number: 18/522,697 Page 49 Art Unit: 2499 Application/Control Number: 18/522,697 Page 50 Art Unit: 2499 Application/Control Number: 18/522,697 Page 51 Art Unit: 2499 Application/Control Number: 18/522,697 Page 52 Art Unit: 2499 Application/Control Number: 18/522,697 Page 53 Art Unit: 2499 Application/Control Number: 18/522,697 Page 54 Art Unit: 2499
Prosecution Insights