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 .
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on
July 13, 2026. 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
The arguments filed on July 13, 2026, have been considered.
Applicant’s arguments regarding claims 1-6, 8-13, and 15-19, do not obviate the rejection. Therefore, the rejection under 35 USC § 112(a) is maintained.
Applicant’s arguments regarding claims 1-6, 8-13, and 15-19, do not obviate the rejection. Therefore, the rejection under 35 USC § 101 is maintained.
Response to Arguments
In view of the remarks, submitted on July 13, 2026, Applicant’s arguments with respect to claim(s) 1-6, 8-13, and 15-19 have been considered but are not persuasive.
Rejection under 35 U.S.C. 112(a)
On page 7 of remarks, Applicant argues that “a call graph is a frequently used and well understood term of art. For example, the Applicant notes: https://en.wikipedia.org/wiki/Call graph. As such, one of ordinary skill in the art would fully understand and know how to derive and traverse a call graph”. Applicant’s arguments have been fully considered but are not persuasive. Paragraphs [0049], [0053], and [0057] use the terms “call graph”, “vulnerability symbol” and “traversing”. However, merely reciting these terms does not demonstrate possession of the claimed combination “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; …”. The cited paragraphs do not adequately describe how the identified vulnerable functions are used to derive the call graph or how traversal of the symbol marked graph distinguishes a vulnerability from a function that is merely present in the software code. 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.
Applicant’s contention that a “call graph” is a well-known term of the art does not cure these deficiencies. The rejection is not based on the absence of a general definition of a call graph. Rather, the deficiency concerns the claimed use of identified vulnerable functions and vulnerability symbols in deriving and traversing the call graph to determine whether each identified function constitutes an actual vulnerability. Accordingly, the specification does not provide sufficient descriptive detail regarding the operative technique that produces that outcome. Therefore, the rejection of claims 1-6, 8-13, and 15-19 under 35 U.S.C. 112(a) is maintained.
Rejection under 35 USC § 101
On Pages 7-14 of remarks by Applicant, the amendment and arguments regarding the independent claim 1 do not overcome the 101 rejection. Applicant correctly notes that the statement on page 7 concerning “auctioning goods or services” and sales activities is unrelated to the pending claims. That characterization is withdrawn as an error. Nevertheless, the rejection is maintained on the independently stated basis that the claim recites abstract information collection, evaluation, correction and organization within the mental process grouping.
Further, a streamlined eligibility analysis is inappropriate because claims 1-6 expressly recite collecting, analyzing, correlating, evaluating and organizing vulnerability related information. Accordingly, the claims must be evaluated under the full eligibility analysis.
Moreover, reciting the abstract analysis as an ordered series of steps does not establish eligibility. Collecting CVE information, identifying relationships between CVEs and code, marking functions, traversing a call graph to evaluate vulnerability status, and aggregating patches collectively describe the analysis and organization information.
Applicant argues that “Because the claims were directed to a specific process, the court found they were patent eligible and did not preempt all future development in automatically animating characters”. Although preemption underlies the judicial exceptions, the absence of complete preemption does not establish eligibility where the claims otherwise recite an abstract idea without integrating into a practical application.
Regarding Step 2A, Prong One, Applicant’s argument that imitations can only be performed by a device is not persuasive. At the level of generality claimed, a person can review CVE and patch information, identify relationship between commits and code functions, diagram calling relationships, mark suspected functions, trace the diagram, determine whether a function is called, and organize corresponding patches. These activities constitute observation, evaluation, and information correlation within the mental process grouping.
The recitation of a “model trained to identify commits”, a “call graph”, and “vulnerability symbols” does not remove the underlying information analysis from the abstract idea grouping. Claim 1 does not recite the particular architecture, training algorithm, call graph construction algorithm or traversal algorithm used to perform the analysis. It is noted that claim 1 does not recite comparable technological rules governing model training, call graph construction or graph traversal. Merely placing the claimed information analysis steps in particular order does not provide the type of specific technological improvement present in McRO.
Regarding Step 2A, Prong Two, the claimed “vulnerability and exposure detection system” merely performs the recited information collection and analysis using generic computing functionality. Applying the abstract analysis to the field of software security itself does not impose a meaningful limit or improve computer operation. The claims do not effect a concrete change to the software or computer.
The specification identifies the objective of accurately identifying functions that represent true vulnerabilities. However, stating a technical field is not sufficient. The claims must recite the particular technical manner by which the improvement is achieved.
Regarding Step 2B, the elements beyond the abstract analysis amount only to generic computer implementation. The vulnerability and exposure detection system performs ordinary functions of receiving, processing, analyzing, and organizing data. Neither the individual limitations nor their ordered combination recites an unconventional computer architecture or other inventive concept sufficient to transform the abstract idea into patent- eligible subject matter.
Regarding “Diamond v. Diehr” and “BASCOM Global Internet Servs. v. AT&T Mobility LLC”, Diehr and BASCOM do not establish that every order combination of known computer operations is eligible. Unlike BASCOM, the present claims do not recite a particular nonconventional arrangement of computer components. Claims 1-6, 8-13, and 15-19 use generic computing functionality to perform the abstract vulnerability information analysis.
Accordingly, the erroneous references to “auctioning goods or services”, “certain methods of organizing human activity” and a “gaming device” are withdrawn. Applicant’s remaining arguments do not overcome the determination that claims 1-6 recite a mental process that is neither integrated into a practical application nor supplemented by additional elements amounting to significantly more. Therefore, the rejection under 35 USC § 101 is maintained.
Rejection under 35 USC § 103
On Pages 14-16 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". The Examiner respectfully disagrees. It is noted that every claim limitation must be taught by the prior art and that an articulated reason for combining the references is required. The rejection satisfies these requirements because Bezzi supplies the CVE related, parch -commit, source code and trained model teachings, while Yang supplies the call graph-based determination of whether a known vulnerability affects the analyzed software. The rejection does not rely on either reference individually to disclose the entire claimed method.
Applicant’s assertion that Bezzi does not collect or use CVE information is inconsistent with Bezzi in paragraph [0063]. Bezzi expressly discuss “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”.
Further, Bezzi explains that detailed security-fix information may identify “which lines of code and which methods need to be updated”. Paragraph [0044] teaches that code changes contain terms denoting “variables, functions, classes, objects” together with metadata identifying the file path and location of the change. Accordingly, Bezzi reasonably suggests identifying portions or functions of the software code associated with a security-relevant patch commit. Bezzi does not teach away from using CVEs. Paragraphs [0063]-[0064] criticize the inconsistency of CVE information in the NVD, However, Bezzi does not discourage establishing CVE-to-patch relationship. To the contrary, paragraph [0063] expressly identifies establishing a correspondence between each CVE and its corresponding code changes as a use of Bezzi’s embodiment. Thus, recognizing deficiencies in existing CVE data supplies a reason to improve the correlation process, not teaching away.
Under the broadest reasonable interpretation, Yang’s extracted vulnerability characteristics including the vulnerability code information, file name and location provide textual identifiers by which the vulnerable code is presented, located and compared during the call-graph traversal. This is consistent with specification of the instant application in paragraph [0049], which broadly defines a vulnerability symbol as “any graphical or textual indicator” used to uniquely identify vulnerable functionality. Yang teaches indicating vulnerable functions in the call graph using vulnerability related textual information.
Bezzi teaches identifying security-relevant patch commits, analyzing commit metadata, accessing corresponding source code repositories, and visually indicating security-relevant changes, while Yang teaches determining that a vulnerability is present when its vulnerability code is encountered during traversal. Accordingly, the combination of Bezzi in view of Yang teaches the limitations of claim 1.
Thus, the rejection of claims 1-6, 8-13, and 15-19 under 35 USC § 103 is maintained.
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.
Claim 8 includes all the limitations of claim 1. Therefore, claim 8 recites the same abstract idea of claim 1. Claim 8 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 9 is dependent on claims 8 includes all the limitations of claim 8. Therefore, claim 9 recites the same abstract idea of claim 8. Claim 9 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 10 is dependent on claim 9 includes all the limitations of claim 9. Therefore, claim 10 recites the same abstract idea of claim 9. Claim 10 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 11 is dependent on claim 8 includes all the limitations of claim 8. Therefore, claim 11 recites the same abstract idea of claim 8. Claim 11 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 12 is dependent on claim 8 includes all the limitations of claim 8. Therefore, claim 12 recites the same abstract idea of claim 8. Claim 12 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 13 is dependent on claim 8 includes all the limitations of claim 8. Therefore, claim 13 recites the same abstract idea of claim 8. Claim 13 recites the additional limitations “one or more processors” and “a non-transitory computer readable storage medium” “a set of computer-executable instructions”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 15 includes all the limitations of claim 1. Therefore, claim 15 recites the same abstract idea of claim 1. Claim 15 recites the additional limitations “A non-transitory, computer-readable medium”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 16 is dependent on claim 15 includes all the limitations of claim 15. Therefore, claim 16 recites the same abstract idea of claim 15. Claim 16 recites the additional limitations “A non-transitory, computer-readable medium”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 17 is dependent on claim 15 includes all the limitations of claim 15. Therefore, claim 17 recites the same abstract idea of claim 15. Claim 17 recites the additional limitations “A non-transitory, computer-readable medium”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 18 is dependent on claim 15 includes all the limitations of claim 15. Therefore, claim 18 recites the same abstract idea of claim 15. Claim 18 recites the additional limitations “A non-transitory, computer-readable medium”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Claim 19 is dependent on claim 15 includes all the limitations of claim 15. Therefore, claim 19 recites the same abstract idea of claim 15. Claim 19 recites the additional limitations “A non-transitory, computer-readable medium”, which in Step 2A, Prong 2, the limitations are merely elaborating on the abstract idea, by further specifying an additional limitation at a high-level of generality, therefore, does not amount to significantly more than the abstract idea.
Therefore, independent claim 1, 8, and 15 and dependent claims 2-6, 9-13, and 16-19 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 relevant).
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 PTOL-892.
THIS ACTION IS MADE FINAL. 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 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
Prosecution Insights