DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 13, 2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on
February 13, 2026. Claims 1, 3, 6, 8, 10, 13, 15, 16, and 19 have been amended. Claims 7, 14, and 20 have been canceled. Accordingly, claims 1-6, 8-13, and 15-19 are pending, of which claims 1, 8 and 15 are in independent form.
Response to Amendment
Applicant’s amendments and arguments regarding claim 1 do not obviate the 35 U.S.C. 112(a) rejection, therefore the examiner maintains the rejection under 35 U.S.C. 112(a).
Applicant’s amendments and arguments regarding claim 1 do not obviate the 35 USC § 101 rejection, therefore the examiner maintains the rejection under 35 USC § 101.
Response to Arguments
In view of the remarks, submitted on February 13, 2026, Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are not persuasive.
Rejection under 35 U.S.C. 112(a)
On pages 9-10 of remarks, Applicant argues that “support for the recited determination can be found, for example in paragraph 57 of the specification”. The examiner disagrees and maintains the 112(a) rejection for the cited limitation “deriving a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol; … determining whether each identified one or more vulnerable functions is a true vulnerability by analyzing the call graph”. The disclosure mentions a call graph can be derived for the software code. The specification fails to describe the derivation of the call graph based on the identified vulnerable functions or the structure and generation of the vulnerability symbol in sufficient detail to demonstrate possession of the claimed invention. Moreover, there is no disclosure as to how the determination of a vulnerability is made by analyzing a call graph and there is no description of what algorithm is used. Applicant’s remarks simply point to a portion of the specification that merely repeats the language found in the claim, where merely repeats the desirable claim functional language of the system. MPEP 2161.01.
A Federal Register notice was also published that emphasizes various issues with regard to Section 112 analysis, specifically as it relates to computer-implemented inventions. The Federal Circuit emphasized that ‘‘[t]he written description requirement is not met if the specification merely describes a ‘desired result.’’ Vasudevan, 782 F.3d at 682 (quoting Ariad, 598 F.3d at 1349). Federal Circuit stated that ‘‘[t]he more telling question is whether the specification shows possession by the inventor of how [the claimed function] is achieved.’’ Vasudevan, 782 F.3d at 683. For instance, the specification must provide a sufficient description of an invention, not an indication of a result that one might achieve.
Therefore, the examiner maintains the rejection under 35 U.S.C. 112(a).
Rejection under 35 USC § 101
On Page 10 of remarks by Applicant, the amendment and arguments regarding the independent claim 1 do not overcome the 101 rejection. It is noted that claim 1 does not integrate the abstract idea into a practical application. The recited “vulnerability and exposure detection system” performs generic computer functions. Data collection, analysis, aggregation, and exposure detection… does not provide a specific technical solution. Therefore, claim 1 is directed to an abstract idea and remains rejected under 35 USC § 101 for being directed to an abstract data analysis process performed on a generic computer without a specific technical improvement.
Rejection under 35 USC § 103
On Pages 8-10 of remarks by applicant, the applicant argues that the cited references fail to teach the amended claim 1 " Applicant specifically traverses each of the rejections under 35 U.S.C. § 103 because a prima facie case of obviousness is not properly established for each, at least considering the inherent problems pointed out with the references and further, that the Examiner's analysis and rationale are not adequate to properly support the combination of the references under § 103".
Applicant’s arguments, with respect to the rejection(s) of claim(s) 1 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bezzi et al. (US 2019/0347424 A1).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6, 8-13, and 15-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “deriving a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol; …”. Given that the limitation of claim 1, for the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol; there is no disclosure as to how a call graph was derived and how each of the vulnerable functions are identified in a call graph by a symbol, (i.e., The instructions can further cause the processor to derive a call graph for the software code based on the identified one or more vulnerable functions. Each of the identified one or more vulnerable functions can be indicated in the call graph by a generated vulnerability symbol., see paragraph [0005]). The specification fails to describe the derivation of the call graph based on the identified vulnerable functions or the structure and generation of the vulnerability symbol in sufficient detail to demonstrate possession of the claimed invention.
Further, claim 1 recites “determining whether each identified one or more vulnerable functions is a vulnerability by analyzing the call graph.”. Regarding the limitation of claim 1, for identified one or more vulnerable functions is a vulnerability by analyzing the call graph, there is no disclosure as to how the determination of a vulnerability is made by analyzing a call graph, (i.e., determining whether each identified one or more vulnerable functions is a true vulnerability can comprise traversing the call graph. The vulnerable function can be determined to be a true vulnerability when the vulnerable function is encountered when traversing the call graph. The instructions can further cause the processor to aggregate a plurality of patches for the software code based on the identified one or more vulnerable functions determined to be true vulnerabilities. see paragraph [0006]).
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
Independent claims 8 and 15 are similarly rejected. Claims 1-7, 9-14 and 16-20 which are dependent to claims 1, 8, and 15 are similarly rejected.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method for auctioning goods or services which is considered a judicial exception because it falls under Certain Methods of Organizing Human Activity such as commercial or legal interactions including sales activities. This judicial exception is not integrated into a practical application as discussed below and the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as discussed below.
This part of the eligibility analysis evaluates whether the claim falls within any statutory category. MPEP 2106.03. In claim(s) 6 the claims recite at least one step or act, including creating, deriving, and constructing. Thus, the claim is to a process, which is one of the statutory categories of invention.
Analysis
Step 1 (Statutory Categories) — 2019 PEG pq. 53
Claims 1-6 are directed to the statutory categories of invention.
Step 2A, Prong 1 (Do the claims recite an abstract idea?) — 2019 PEG pq. 54
For independent claim 1, the claim recites an abstract idea of: enabling one or more restrictions by the user. The steps of: “A method for identifying vulnerable functions in software code, the method comprising: collecting, by a vulnerability and exposure detection system, information identifying one or more known Common Vulnerabilities and Exposures (CVEs); identifying, by the vulnerability and exposure detection system, one or more vulnerable functions in the software code based on a model trained to identify commits containing patches based on relationships between the collected information identifying the one or more known CVEs and portions of the software code containing the one or more vulnerable functions; deriving, by the vulnerability and exposure detection system, a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol; determining, by the vulnerability and exposure detection system, whether each identified one or more vulnerable functions is a vulnerability by traversing the call graph; and aggregating, by the vulnerability and exposure detection system, a plurality of patches for the software code based on the identified one or more vulnerable functions determined to be vulnerabilities.”, when considered collectively as an ordered combination, recite the abstract idea and falls within the “Mental Processes” grouping of abstract ideas.
Claim 1 recites a method for identifying vulnerable functions in software code, indicating steps of:
Collecting information identifying known (CVEs)
Identifying vulnerable functions based on model trained …
Deriving a call graph…
Determining whether functions are vulnerabilities by traversing the call graph; and
Aggregating patches based on the identified vulnerabilities.
These limitations describe analyzing information and detecting relation ships within software vulnerability data, including collecting information, analyzing code changes, determining vulnerability status, and organizing patch information.
Such operations constitute mental processes and data analysis, which fall within the category of abstract idea.
Therefore, the steps are the mental process as recited in the independent claim 1.
Claim 2 depends from claim 1 and recites: “identifying the one or more vulnerable functions in the software code further comprises identifying a patch commit for each identified one or more vulnerable functions”.
These limitations collectively describe collecting, analyzing, and correlating information relating to software vulnerabilities, commits, and patches, which constitutes data analysis and information processing.
Such operations fall within the category of mental process and can be performed by a human reviewing vulnerability database. Accordingly, claim 2 recites an abstract idea.
Claim 3 depends from claim 2 and recites: “identifying the patch commit for each identified one or more vulnerable function comprises analyzing metadata for each identified one or more vulnerable function using the model defining relationships between the collected information identifying the one or more known CVEs and portions of the software code containing the one or more vulnerable functions.”.
These limitations collectively describe collecting, analyzing, and applying and identifying patch commits based on those relationships.
Such operations fall within the category of mental process and can be performed by a human reviewing vulnerability database. Accordingly, claim 3 recites an abstract idea.
Claim 4 depends from claim 1 and recites “wherein identifying the one or more vulnerable functions in the software code further comprises identifying a link to the identified patch commit for each identified one or more vulnerable function”. The additional limitation of claim 4 specifies that the identification process includes “identifying a link”. Such activities constitute data analysis and information correlation, which fall within the category of mental process and can be performed by a human reviewing vulnerability database. Accordingly, claim 3 recites an abstract idea.
Claim 5 depends from claim 1 and recites “identifying the one or more vulnerable functions in the software code further comprises generating a vulnerability symbol for each of the one or more identified vulnerability functions”. The limitation of claim 5 specifies generating a symbol representing the vulnerability associated with each identified vulnerabilities in software code. Such activities constitute data analysis and information correlation, which fall within the category of mental process and can be performed by a human reviewing vulnerability database. Accordingly, claim 3 recites an abstract idea.
Claim 6 depends from claim 1 and recites “the vulnerable function determined to be a vulnerability when the vulnerable function is encountered when traversing the call graph”. The limitation of claim 6 specifies determining a vulnerability when the vulnerable function is encountered when traversing the call graph. Such activities constitute data analysis and information correlation, which fall within the category of mental process and can be performed by a human reviewing vulnerability database. Accordingly, claim 6 recites an abstract idea.
Step 2A, Prong 2 (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - 2019 PEG pq. 54
The claim does not integrate the abstract idea into a practical application.
Although the claim recites a “vulnerability and exposure detection system”, this element merely performs the abstract idea stepes using generic computing functionality.
The claimed steps of:
Collecting information
Identifying functions
Deriving a call graph
Traversing the call graph, and
Aggregating patches
Represent data gathering, analysis, and output generation, which are routine computer functions that merely automate the abstract idea. The claim does not improve the functioning of the computer itself. Therefore, the claim does not integrate the judicial exception into a practical application.
Claim 2 does not integrate the abstract idea into a practical application.
The limitations represent data gathering and correlation of software development, which is part of the abstract idea and does not improve the functioning of computer. Thus, the claim does not integrate the judicial exception into a practical application.
Claim 3 does not integrate the abstract idea into a practical application.
The limitations merely specifies that the analysis of metadata is performed using a model defining relationship between vulnerability information and portions of software code. The recitation of a model does not meaningfully limit the claim because the claim does not specify any particular structure, algorithm or technical improvement associated with the model. Thus, the claim does not integrate the judicial exception into a practical application.
Claim 4 does not integrate the abstract idea into a practical application.
The limitations merely identify a link to patch a commit. The recitation of a link does not meaningfully limit the claim because the claim does not specify any particular structure, algorithm or technical improvement associated with the model. Thus, the claim does not integrate the judicial exception into a practical application.
Claim 5 does not integrate the abstract idea into a practical application.
The limitations merely generate a vulnerability symbol for each of the one or more identified vulnerability functions. The recitation of a vulnerability symbol does not meaningfully limit the claim because the claim does not specify any particular structure, algorithm or technical improvement associated with the model. Thus, the claim does not integrate the judicial exception into a practical application.
Claim 6 does not integrate the abstract idea into a practical application.
The limitations merely determine a vulnerability when the vulnerable function is encountered when traversing the call graph. The recitation of determine … function is encountered when traversing the call graph does not meaningfully limit the claim because the claim does not specify any particular structure, algorithm or technical improvement associated with the model. Thus, the claim does not integrate the judicial exception into a practical application.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - 2019 PEG pq. 56
Claim 1 fails to recite additional elements that amount to significantly more than the abstract idea. The only additional element beyond the abstract idea is a generic computer system performing standard data processing operations.
No elements in the claim adds a specific technological improvement computer functionality. Accordingly, the claim does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Claim 2 does not include additional elements that amount to significantly more than the abstract idea. Identifying the one or more vulnerable functions in the software code ... identifying a patch commit …to determine whether vulnerabilities have been addressed. No elements in the claim adds a specific technological improvement computer functionality. Accordingly, the claim does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Claim 3 does not include additional elements that amount to significantly more than the abstract idea. Claim 3 recites “identifying the patch commit for each identified one or more vulnerable function comprises analyzing metadata … using the model defining relationships between the collected information identifying the one or more known CVEs and portions of the software code containing the one or more vulnerable functions”. The use of a model to analyze metadata and determine relationship between the vulnerability information and the code portions represent routine data analysis techniques performed using generic computing components. Accordingly, claim 3 does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Claim 4 does not include additional elements that amount to significantly more than the abstract idea. Claim 4 recites “identifying the one or more vulnerable functions in the software code further comprises identifying a link to the identified patch commit for each identified one or more vulnerable function”. The use of a link to the identified patch commits for each identified one or more vulnerable function represent routine data analysis techniques performed using generic computing components. Accordingly, claim 4 does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Claim 5 does not include additional elements that amount to significantly more than the abstract idea. Claim 5 recites “generating a vulnerability symbol for each of the one or more identified vulnerability functions”. The generating a vulnerability symbol represent routine data analysis techniques performed using generic computing components. Accordingly, claim 5 does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Claim 6 does not include additional elements that amount to significantly more than the abstract idea. Claim 6 recites “determine a vulnerability when the vulnerable function is encountered when traversing the call graph”. The determine a … when traversing the call graph represent routine data analysis techniques performed using generic computing components. Accordingly, claim 6 does not include an inventive concept sufficient to transform the abstract idea into patent -eligible subject matter.
Therefore, independent claim 1 and dependent claims 2-6 are not patent eligible under 35 U.S.C 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 8-13, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bezzi et al. (US 2019/0347424 A1), hereinafter Bezzi in view of YANG et al. (CN 112434305 A), hereinafter YANG.
In regards to claim 1, Bezzi discloses a method for identifying vulnerable functions in software code, the method comprising (Bezzi, Para. 0063):
collecting, by a vulnerability and exposure detection system, information identifying one or more known Common Vulnerabilities and Exposures (CVEs) (Bezzi, Para. 0118, retrieving a set of code changes to source code from the source code repository) and (Bezzi, Para. 0063, Advanced vulnerability analysis and management technologies (such as Vulas) rely on the availability of reliable information associating a vulnerability (CVE) to the code changes that where committed to the corresponding project repository in order to address that vulnerability. This kind of information is available only occasionally in the NVD, and often its quality is poor (e.g., wrong, incomplete, or inconsistent)); identifying, by the vulnerability and exposure detection system, one or more vulnerable functions in the software code based on a model trained to identify commits containing patches based on relationships between the collected information identifying the one or more known CVEs and portions of the software code containing the one or more vulnerable functions (Bezzi, Para. 0048, the one or more processors trains the security-relevant code detection machine learning model 204 using, for example, a first subset of the labeled training data to generate a trained security-relevant code detection machine learning model. And then in operation 310, the one or more processors tests the trained security-relevant code detection machine learning model using a second subset of the labeled training data. The security-relevant code detection machine learning model 204 may be periodically trained on new data to update the security-relevant code detection machine learning model 204) and (Bezzi, Para. 0020, a set of code changes (e.g., patches) found in the entire history (or in a defined temporal interval) of a given project is considered and each of them is processed in order to extract a set of terms. Then, standard document classification methods are used to train a standard classifier (e.g., using algorithms such as Naive Bayes, Logistic Regression, Support Vector Machines, and the like) to recognize patches that appear to be “security-relevant” based on the terms that they contain) and paragraphs [0043], [0050], [0032] and [0033]; and
Bezzi does not explicitly disclose deriving, by the vulnerability and exposure detection system, a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol;
and determining, by the vulnerability and exposure detection system, whether each identified one or more vulnerable functions is a vulnerability by traversing the call graph;
aggregating, by the vulnerability and exposure detection system, a plurality of patches for the software code based on the identified one or more vulnerable functions determined to be vulnerabilities.
However, YANG teaches deriving, by the vulnerability and exposure detection system (YANG, Page 2, compile and construct the software project to be tested, and obtain its call graph; the call graph is used to traverse the vulnerabilities, and the third-party dependent component vulnerabilities that have an actual impact on the software project to be detected are searched for according to the characteristics of the vulnerabilities), a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol (YANG, Page. 2, use the call graph to traverse the vulnerabilities, and compare features of all vulnerabilities according to the vulnerability characteristics, and find the vulnerabilities in which the vulnerability code is called by the call graph, which is a third-party dependency that has an actual impact on the software project Vulnerabilities in components); and
determining, by the vulnerability and exposure detection system, whether each identified one or more vulnerable functions is a vulnerability by traversing the call graph (YANG, Page. 3, the vulnerability finding module uses the call graph to traverse the vulnerabilities, and finds the third-party dependent component vulnerabilities that have an actual impact on the software project to be detected according to the vulnerability characteristics, including: Use the call graph to traverse the vulnerabilities, and compare features of all vulnerabilities according to the vulnerability characteristics, and find the vulnerabilities in which the vulnerability code is called by the call graph, which is a third-party dependency that has an actual impact on the software project Vulnerabilities in components);
aggregating, by the vulnerability and exposure detection system, a plurality of patches for the software code based on the identified one or more vulnerable functions determined to be vulnerabilities (YANG, Page 2, Obtain vulnerabilities based on the name and version of the third-party dependent component, and obtain patches corresponding to the vulnerabilities based on the vulnerabilities) and (YANG, Page 2, generating a detection report after traversing the vulnerabilities by using the call graph, and searching for third-party dependent component vulnerabilities that have an actual impact on the software project to be detected according to the vulnerability characteristics).
Bezzi and YANG are all considered to be analogous to the claim invention because they are in the same field of identifying one or more known Common Vulnerabilities and Exposures (CVEs) and identifying one or more vulnerable functions in the software code based on relationships between the collected information identifying the one or more known CVEs.
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Bezzi to incorporate the teachings of YANG to include deriving, by the vulnerability and exposure detection system (YANG, Page 2), a call graph for the software code based on the identified one or more vulnerable functions, wherein each of the identified one or more vulnerable functions are indicated in the call graph by a vulnerability symbol (YANG, Page. 2); and determining, by the vulnerability and exposure detection system, whether each identified one or more vulnerable functions is a vulnerability by traversing the call graph (YANG, Page. 3); aggregating, by the vulnerability and exposure detection system, a plurality of patches for the software code based on the identified one or more vulnerable functions determined to be vulnerabilities (YANG, Page 2) and (YANG, Page 2). Doing so would aid to detect whether the vulnerabilities of third-party dependent components have a real impact on the software project, and then accurately locate the vulnerabilities, effectively avoiding third-party dependence. Blind upgrade of components brings about lower project execution efficiency or version compatibility risks, which in turn improves the security and usability of the software (YANG, Page. 4).
In regards to claim 2, the combination of Bezzi in view of YANG teaches the method of claim 1, wherein identifying the one or more vulnerable functions in the software code further comprises identifying a patch commit for each identified one or more vulnerable functions (Bezzi, Para. 0011, systems and methods described herein relate to identifying security-relevant code changes. Example embodiments use machine-learning techniques to extract information directly form source code repositories and to identify code changes (also referred to as “commits” or “code commits” or “fixes”) that are security-relevant. For example, example embodiments examine individual code commits and treat the code changes as ordinary text. The code changes are thus expressed as a document (e.g., made of words) to which text-classification methods may be applied) and (Bezzi, Para. 0052, one or more processors retrieves a set of code changes to source code from a source code repository. In one example, a user may send a request via a computing device (e.g., client device 110) to analyze a specified set of code changes. In another example, the security-relevant code detection system 124 may periodically analyze all code changes made for one or more projects (e.g., open source projects) to determine whether any code changes are security relevan).
In regards to claim 3, the combination of Bezzi in view of YANG teaches the method of claim 2, wherein identifying the patch commit for each identified one or more vulnerable function comprises analyzing metadata for each identified one or more vulnerable function using the model defining relationships between the collected information identifying the one or more known CVEs and portions of the software code containing the one or more vulnerable functions (Bezzi, Para. 0044, while the code changes themselves may be in plain text, they may include more than the “terms” used by the developer to denote variables, functions, classes, objects: they also include extra symbols (+,−), and metadata related to the location where the change happened (e.g., file path, line/column numbers, number of characters modified)) and (Bezzi, Para. 0056, the vector representation of each code change of the set of code changes is input into the trained security-relevant code detection machine learning model. In operation 408, the output from the trained security-relevant code detection machine learning model is received by the one or more processors. The output comprises a prediction representing a probability that each code change of the set of code changes contains security relevant changes. For example, the prediction may be a number between 0 and 1.).
In regards to claim 4, the combination of Bezzi in view of YANG teaches the method of claim 1, wherein identifying the one or more vulnerable functions in the software code further comprises identifying a link to the identified patch commit for each identified one or more vulnerable function (Bezzi, Fig. 6, and Para. 0037, The repository access layer 220 comprises connectors to access one or more different open-source code repositories 222. This enables the access to the source code of patched (“commits”), which constitute the raw data for the classification. It also comprises a commit history cache 224 repository where commits can be temporarily stored to reduce the number of connections to external repository to improve performance, and possibly to avoid the external repository denying access in the presence of too many repeated connections).
In regards to claim 5, the combination of Bezzi in view of YANG discloses the method of claim 1, identifying the one or more vulnerable functions in the software code further comprises generating a vulnerability symbol for each of the one or more identified vulnerability functions (Bezzi, Fig. 6, and Para. 0059, for each of the code changes in the list of code changes 602, the system determines whether or not each code change is security-relevant or not, as described above. This may be done in real-time as a user is scrolling through and viewing the list of code changes 602. The user interface may display an indication 604 of whether or not each code change in the list of code changes 602 is security-relevant or not. In this example, the code changes that are security relevant are indicated by a square and red circle 606, and the code changes that are not security relevant are indicated by a green checkmark 608).
In regards to claim 6, the combination of Bezzi in view of YANG teaches the method of claim 1, wherein the vulnerable function determined to be a vulnerability when the vulnerable function is encountered when traversing the call graph (YANG, Page. 3, the vulnerability finding module uses the call graph to traverse the vulnerabilities, and finds the third-party dependent component vulnerabilities that have an actual impact on the software project to be detected according to the vulnerability characteristics, including: Use the call graph to traverse the vulnerabilities, and compare features of all vulnerabilities according to the vulnerability characteristics, and find the vulnerabilities in which the vulnerability code is called by the call graph, which is a third-party dependency that has an actual impact on the software project Vulnerabilities in components). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Bezzi to incorporate the teachings of YANG to include wherein determining whether each identified one or more vulnerable functions is a true vulnerability comprises traversing the call graph and wherein the vulnerable function determined to be a true vulnerability when the vulnerable function is encountered when traversing the call graph (YANG, Page. 3). Doing so would aid to detect whether the vulnerabilities of third-party dependent components have a real impact on the software project, and then accurately locate the vulnerabilities, effectively avoiding third-party dependence. Blind upgrade of components brings about lower project execution efficiency or version compatibility risks, which in turn improves the security and usability of the software (YANG, Page. 4).
In regards to claim 8, the system claim 8 is similarly analyzed and rejected as the method claim 1.
In regards to claim 9, the system claim 9 is similarly analyzed and rejected as the method claim 2.
In regards to claim 10, the system claim 10 is similarly analyzed and rejected as the method claim 3.
In regards to claim 11, the system claim 11 is similarly analyzed and rejected as the method claim 4.
In regards to claim 12, the system claim 12 is similarly analyzed and rejected as the method claim 5.
In regards to claim 13, the system claim 13 is similarly analyzed and rejected as the method claim 6.
In regards to claim 15, the non-transitory claim 15 is similarly analyzed and rejected as the method claim 1 and system claim 8.
In regards to claim 16, the non-transitory claim 16 is similarly analyzed and rejected as the method claim 3 and system claim 10.
In regards to claim 17, the non-transitory claim 17 is similarly analyzed and rejected as the method claim 4 and system claim 11.
In regards to claim 18, the non-transitory claim 18 is similarly analyzed and rejected as the method claim 5 and system claim 12.
In regards to claim 19, the non-transitory claim 19 is similarly analyzed and rejected as the method claim 13 and system claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6: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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496