DETAILED ACTION
This Office action is in response to the amendment filed on June 19, 2026.
Claims 1-20 are pending.
Claims 1-4, 9-12, and 19 are currently amended.
The objections to the drawings are withdrawn in view of Applicant's amendments to the specification.
The rejection of Claim 6 and 16 under 35 U.S.C. § 112(b) are withdrawn in view of Applicant's arguments.
The rejection of Claims 1-20 under 35 U.S.C. § 101 is maintained for the reasons set forth below.
The rejection of Claims 1, 3, 9, 11, 13, and 19 under 35 U.S.C. § 102(a)(1) over Velur is withdrawn in view of the amendments to independent Claims 1 and 11. New grounds of rejection under 35 U.S.C. § 103 necessitated by Applicant’s amendments are set forth below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments filed on June 19, 2026 with respect to the rejection of Claims 6 and 16 under 35 U.S.C. § 112(b) are persuasive. Accordingly, the rejection of Claims 6 and 16 under 35 U.S.C. § 112(b) is withdrawn.
Applicant’s arguments filed on June 19, 2026 with respect to the rejection of Claims 1 and 11 under 35 U.S.C. § 101 are not persuasive. Applicant argues that amended Claims 1 and 11 no longer recite a mental process because the claims require scanning the computer program each time the computer program is checked into a code repository and blocking the computer program from being checked into the code repository when the severity of a vulnerability exceeds a threshold. Applicant further argues that these limitations provide a technological improvement to the software development process. Applicant’s arguments have been fully considered but are not persuasive. As discussed below, Claim 1 continues to recite mental evaluations including identifying a vulnerability, determining its severity, and evaluating the severity against a threshold, while the additional computer-implemented limitations do not integrate the judicial exception into a practical application or recite a particular technological improvement. See MPEP §§ 2106.04(a)(2)(III), 2106.04(d)(1), and 2106.05(f).
Applicant’s arguments filed on June 19, 2026 with respect to the rejection of Claims 1 and 11 under 35 U.S.C. § 102 are persuasive. Accordingly, the rejection of Claims 1, 3, 9, 11, 13, and 19 under 35 U.S.C. § 102(a)(1) over Velur are withdrawn. New ground of rejection under 35 U.S.C. § 103 necessitated by the amendments are set forth below.
Applicant’s arguments filed on June 19, 2026 with respect to the rejections under 35 U.S.C. § 103 are not persuasive. Applicant argues that the cited references fail to teach “managing the dependency based upon the severity of the vulnerability, including: scanning the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold”. The arguments have been fully considered but are not persuasive with respect to the rejection presently set forth. As discussed below, Kumar teaches vulnerability scanning in response to code being checked in or committed, while Jackson teaches severity-based security policies and blocking components that fail repository policy from being stores in the repository. Therefore, the combined teaches of Velur, Kumar, and Jackson teach the amened limitation for the reasons set forth below.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 1 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 1 is directed to a computer system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites the limitations:
identify a vulnerability associated with a dependency for a computer program as the computer program is being developed;
determine a severity of the vulnerability; and
manage the dependency based upon the severity of the vulnerability, including to:
scan the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
(3) block the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing a dependency for a computer program as the computer program is being developed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a vulnerability associated with the dependency. The limitation (b) in the context of the claim encompasses a human evaluating a vulnerability in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to determine the severity of the vulnerability. And the limitation (c) in the context of the claim encompasses a human judging the severity of a vulnerability in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to manage the dependency based on the severity of the vulnerability. Further, the limitation (d) in the context of the claim encompasses a human observing a computer program each time the computer program is checked into a code repository in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to find vulnerabilities associated with the dependency. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
The additional elements (1) and (2) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The one or more processors and non-transitory computer-readable storage media are used as a tool to perform the identifying, determining, and managing steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
(3) blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
The additional element (3) fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element recites only the idea of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold without details on how this is accomplished. The claim omits any details as to how the blocking of the computer program from being checked into the code repository solves a technical problem, and instead recites only the idea of a solution or outcome. Therefore, the additional element attempts to cover any solution to the identified problem of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold with no restriction on how the blocking is accomplished and no description of the mechanism for accomplishing the blocking, and does not integrate a judicial exception into a practical application because this type of recitation is equivalent to the words “apply it.”
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
The additional elements (1) and (2) amount to no more than mere instructions to apply the judicial exception using generic computer components. The analysis under Step 2A, Prong Two is carried through to Step 2B. The use of a computer or other machinery in its ordinary capacity does not integrate a judicial exception into a practical application or provide significantly more.
Also, the claim recites the additional element:
(3) blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
The additional element (3) does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. The analysis under Step 2A, Prong Two is carried through to Step 2B. Therefore, the additional element attempts to cover any solution to the identified problem of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold with no restriction on how the blocking is accomplished and no description of the mechanism for accomplishing the blocking and does not provide significantly more because this type of recitation is equivalent to the words “apply it.”
══════════════════════════════════════════════
Examiner's Remarks: The specification describes vulnerability detection during software development, however, Claim 1 does not recite a particular technological mechanism that reflects an improvement to computer functionality or another technology. Rather, the claim broadly recites performing vulnerability screening upon a code-repository check-in and blocking the check-in when a severity threshold is exceeded. Thus, the claim recites the desired result of applying the judicial exception in a particular technological environment rather than a particular technological solution. See MPEP §§ 2106.04(d)(1), 2106.05(f), 2106.05(h).
══════════════════════════════════════════════
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components and therefore do not provide an inventive concept. The claim is not patent eligible.
Claims 2-10 are dependent on Claim 1, but do not add any feature or subject matter that would solve the judicial exception deficiencies of Claim 1. Claims 2-10 rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more for at least the reasons stated above.
Claim 2 recites the limitation:
(a) block the dependency or block release of the computer program based upon the severity.
•──────────────•──────────────•
Claim 3 recites the limitation:
(a) generate an alert based upon the severity of the vulnerability.
•──────────────•──────────────•
Claim 4 recites the limitation:
(a) block downloading of the dependency;
(b) block code including the dependency during versioning; and
(c) block release of the computer program including the dependency.
•──────────────•──────────────•
Claim 5 recites the limitation:
(a) wherein the dependency is managed using rules.
•──────────────•──────────────•
Claim 6 recites the limitation:
(a) wherein the dependency is managed by: create a risk score associated with all vulnerabilities for the computer program;
(b) and use the rules to hold the computer program based upon the risk score.
•──────────────•──────────────•
Claim 7 recites the limitation:
(a) wherein the rules are based upon the severity of the vulnerability and a context of the dependency.
•──────────────•──────────────•
Claim 8 recites the limitation:
(a) wherein the rules are stored in a central database.
•──────────────•──────────────•
Claim 9 recites the limitation:
(a) generate a compliance report based upon vulnerabilities identified for the computer system.
•──────────────•──────────────•
Claim 10 recites the limitation:
(a) identify trends associated with the vulnerabilities identified for the computer system.
•──────────────•──────────────•
Claims 3, 5, 6, 7, 9, 10 recite further mental steps which can be practically performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper and thus, fail to make the claim any less abstract (see MPEP § 2106.04(a)(2)(III)).
Claims 2, 4, 8 recite further additional elements that do not integrate the judicial exception into a practical application of the judicial exception because they do not require any particular application of the judicial exception and are, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception (see MPEP § 2106.05(f)) and thus, are not significantly more than the abstract idea.
Thus, Claims 2-10 do not add any steps or additional elements, when considered both individually and as a combination, that would convert Claim 1 into patent-eligible subject matter.
Therefore, Claims 1-10 are not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
Step 1: Claim 11 is directed to a computer system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 11 recites the limitations:
identifying a vulnerability associated with a dependency for a computer program as the computer program is being developed;
determining a severity of the vulnerability; and
managing the dependency based upon the severity of the vulnerability, including:
scanning the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
(3) blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing a dependency for a computer program as the computer program is being developed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a vulnerability associated with the dependency. The limitation (b) in the context of the claim encompasses a human evaluating a vulnerability in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to determine the severity of the vulnerability. And the limitation (c) in the context of the claim encompasses a human judging the severity of a vulnerability in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to manage the dependency based on the severity of the vulnerability. Further, the limitation (d) in the context of the claim encompasses a human observing a computer program each time the computer program is checked into a code repository in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to find vulnerabilities associated with the dependency. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
The additional elements (1) and (2) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The one or more processors and non-transitory computer-readable storage media are used as a tool to perform the identifying, determining, and managing steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
(3) blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
The additional element (3) fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element recites only the idea of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold without details on how this is accomplished. The claim omits any details as to how the blocking of the computer program from being checked into the code repository solves a technical problem, and instead recites only the idea of a solution or outcome. Therefore, the additional element attempts to cover any solution to the identified problem of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold with no restriction on how the blocking is accomplished and no description of the mechanism for accomplishing the blocking, and does not integrate a judicial exception into a practical application because this type of recitation is equivalent to the words “apply it.”
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) one or more processors; and
(2) non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to:
The additional elements (1) and (2) amount to no more than mere instructions to apply the judicial exception using generic computer components. The analysis under Step 2A, Prong Two is carried through to Step 2B. The use of a computer or other machinery in its ordinary capacity does not integrate a judicial exception into a practical application or provide significantly more.
Also, the claim recites the additional element:
(3) blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
The additional element (3) does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. The analysis under Step 2A, Prong Two is carried through to Step 2B. Therefore, the additional element attempts to cover any solution to the identified problem of blocking the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold with no restriction on how the blocking is accomplished and no description of the mechanism for accomplishing the blocking and does not provide significantly more because this type of recitation is equivalent to the words “apply it.”
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components and therefore do not provide an inventive concept. The claim is not patent eligible.
Claims 12-20 are dependent on Claim 11, but do not add any feature or subject matter that would solve the judicial exception deficiencies of Claim 11. Claims 12-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more for at least the reasons stated above.
Claim 12 recites the limitation:
(a) block the dependency or block release of the computer program based upon the severity.
•──────────────•──────────────•
Claim 13 recites the limitation:
(a) generate an alert based upon the severity of the vulnerability.
•──────────────•──────────────•
Claim 14 recites the limitation:
(a) block downloading of the dependency;
(b) block code including the dependency during versioning; and
(c) block release of the computer program including the dependency.
•──────────────•──────────────•
Claim 15 recites the limitation:
(a) wherein the dependency is managed using rules.
•──────────────•──────────────•
Claim 16 recites the limitation:
(a) wherein the dependency is managed by: create a risk score associated with all vulnerabilities for the computer program;
(b) and use the rules to hold the computer program based upon the risk score.
•──────────────•──────────────•
Claim 17 recites the limitation:
(a) wherein the rules are based upon the severity of the vulnerability and a context of the dependency.
•──────────────•──────────────•
Claim 18 recites the limitation:
(a) wherein the rules are stored in a central database.
•──────────────•──────────────•
Claim 19 recites the limitation:
(a) generate a compliance report based upon vulnerabilities identified for the computer system.
•──────────────•──────────────•
Claim 20 recites the limitation:
(a) identify trends associated with the vulnerabilities identified for the computer system.
•──────────────•──────────────•
Claims 13, 15, 16, 17, 19, 20 recite further mental steps which can be practically performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper and thus, fail to make the claim any less abstract (see MPEP § 2106.04(a)(2)(III)).
Claims 12, 14, 18 recite further additional elements that do not integrate the judicial exception into a practical application of the judicial exception because they do not require any particular application of the judicial exception and are, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception (see MPEP § 2106.05(f)) and thus, are not significantly more than the abstract idea.
Thus, Claims 12-20 do not add any steps or additional elements, when considered both individually and as a combination, that would convert Claim 11 into patent-eligible subject matter.
Therefore, Claims 11-20 are not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
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.
Claims 1, 2, 3, 5, 6, 7, 9 and 11, 12, 13, 15, 16, 17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Velur (U.S. Patent No. 11,481,498 B2) in view of Kumar (U.S. Patent Application Publication No. US 2023/0161882 A1) and further in view of Jackson (U.S. Patent No. 10,540,176 B2) .
Regarding Claim 1, Velur teaches:
a computer system for managing software dependencies, comprising: one or more processors; and non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to (Velur, Col. 21, Lines 44-46, A non-transitory computer-readable medium comprising instructions that are executable by a processing device for causing the processing device to):
identify a vulnerability associated with a dependency for a computer program as the computer program is being developed (Velur, Col. 3, Lines 5-6, FIG. 4 illustrates pseudo logic that can be used to aggregate a list of vulnerable third-party libraries); [Examiner Remarks: the specification states that “Such dependencies can include software libraries that are incorporated as part of the software development process” (Paragraph 0010). Thus, one of ordinary skill in the art would readily comprehend that third-party libraries can be reasonably interpreted as the claimed “dependency”.]
determine a severity of the vulnerability (Velur, Col. 4, Lines 64-65, the invention can determine (i) the severity of the vulnerability);
and manage the dependency based upon the severity of the vulnerability (Velur, Col. 7, Lines 40-42, (iii) addressing the vulnerabilities in deployed applications based on the severity of the exposure).
Velur teaches the claimed “vulnerabilities associated with the dependency”, however Velur fails to teach:
scan the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and
However, Kumar teaches:
scan the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and (Kumar, Paragraph [0085], “Although the above description indicated that the scan can occur after the build starts, it should be noted that other scans can occur at other times as well. For instance, a scan can occur in response to code being checked in or committed as well (emphasis added).”)
Velur and Kumar are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Jackson to incorporate the teachings of Kumar to have:
scan the computer program for vulnerabilities associated with the dependency each time the computer program is checked into a code repository; and
The modification would be obvious to one of ordinary skill in the art because doing so would permit vulnerability scanning to be performed in response to code being checked in or committed, thereby identifying vulnerabilities at an earlier stage of the software development process before the code proceeds through subsequent build and deployment operations (Kumar, Paragraph [0085], [0095-0096]).
The combination of Velur and Kumar fails to teach:
block the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
However, Jackson teaches:
block the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold (Col. 5, Lines 53-56, “As an example of a security vulnerability, consider that a software component might have a vulnerability rated a low level but the application blocks only vulnerabilities at a critical level (emphasis added).” Col. 8, Lines 50-58, “However, before possibly serving the component 231 to client A 201 and saving the component in the repository 227, the repository manager 211 will determine the risks of the component using risk data (here represented by security vulnerabilities risk data 219 and software licensing risk data 217) and determine whether the component 231 passes the rules already established in the repository policy 223 (regarding disposition of an inbound component).” Col. 17, Lines 45-49, “In the synchronous mode process 501, the evaluation 503 of the component with the repository policy is performed, and the process 501 determines 505 which action to take (for example, blocking or passing the component), before the standard disposition of the component can occur.” Col. 18, Lines 46-51, “If the component does not pass the repository policy (711.fwdarw.does not pass), then the procedure 701 will take the programmatic steps 715 which are predefined in the repository policy. For example, such programmatic steps may include one or more of the following: block the component from being stored in the repository (emphasis added)”).
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
block the computer program from being checked into the code repository when the severity of the vulnerability exceeds a threshold.
The modification would be obvious to one of ordinary skill in the art because by taking steps at critical junctures appropriate for software development to automatically block, quarantine, limit, or notify of software components that fail pre-defined criteria, and possibly by indicating reasons for failure and/or suggesting acceptable software components, the consumption (inbound flow) and publication (outbound flow) of software components that have risks which have already been deemed unacceptable for the repository or for the application can be reduced and/or prevented, dramatically reducing risky behavior and greatly improving overall software development efficiency (Jackson, Col. 5, Lines 8-20).
Regarding Claim 2, the rejection of Claim 1 is incorporated. The combination of Velur and Kumar fails to teach:
block the dependency or block release of the computer program based upon the severity.
However, Jackson teaches:
block the dependency or block release of the computer program […] (Jackson, Col. 13, Lines 64-65, One common action in the case that a component did not pass is to block the component from being served to users).
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
block the dependency or block release of the computer program […].
The modification would be obvious to one of ordinary skill in the art because by taking steps at critical junctures appropriate for software development to automatically block, quarantine, limit, or notify of software components that fail pre-defined criteria, and possibly by indicating reasons for failure and/or suggesting acceptable software components, the consumption (inbound flow) and publication (outbound flow) of software components that have risks which have already been deemed unacceptable for the repository or for the application can be reduced and/or prevented, dramatically reducing risky behavior and greatly improving overall software development efficiency (Jackson, Col. 5, Lines 8-20).
The combination of Velur and Jackson fails to teach:
[…] based upon the severity.
However, Kumar teaches:
[…] based upon the severity (Kumar, Page 3, Paragraph 55, If a threshold number or type of vulnerabilities are detected during the time while the code build is happening, then the embodiments are able to terminate the code build before it completes).
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
- […] based upon the severity.
The modification would be obvious to one of ordinary skill in the art because by doing so, the new rollout or update will be prevented from being pushed out to client devices, thereby ensuring that a compromised application is not released into the public. That is, because this new update was determined to be highly vulnerable, the embodiments beneficially prevent that update from being pushed out, thereby protecting client devices (and the application) from such vulnerabilities (Kumar, Page 3, Paragraph 0055).
Regarding Claim 3, the rejection of Claim 1 is incorporated. Velur further teaches:
generate an alert based upon the severity of the vulnerability (Velur, Col. 7, Lines 42-43, (iv) causing a remedial action such as a notification to address the vulnerabilities).
Regarding Claim 5, the rejection of Claim 1 is incorporated. Velur teaches “the dependency” but the combination of Velur and Kumar fails to teach:
wherein the dependency is managed using rules.
However, Jackson teaches:
[…] managed using rules (Jackson, Col. 10, Lines 28-31, Such a system and method can act on a set of rules embodied in policies 223, 225A, 225B that are predefined to establish what risks are deemed acceptable and what are not, and what actions to take for risks that do not pass).
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
wherein the dependency is managed using rules.
The modification would be obvious to one of ordinary skill in the art because by taking steps at critical junctures appropriate for software development to automatically block, quarantine, limit, or notify of software components that fail pre-defined criteria, and possibly by indicating reasons for failure and/or suggesting acceptable software components, the consumption (inbound flow) and publication (outbound flow) of software components that have risks which have already been deemed unacceptable for the repository or for the application can be reduced and/or prevented, dramatically reducing risky behavior and greatly improving overall software development efficiency (Jackson, Col. 5, Lines 8-20).
Regarding Claim 6, the rejection of Claim 5 is incorporated. Velur further teaches:
wherein the dependency is managed by: create a risk score associated with all vulnerabilities for the computer program (Velur, Col. 7, Lines 66-67; Col. 8, Lines 1-10, By accumulating the total number of code calls with CVEs for each library, the criticality of the CVE, and the impact to business functionality, a risk score can be assigned to each library and/or API. A risk score can represent the potential chance of a library being susceptible to a hacking attempt or security breach. In block 206, vulnerabilities within the libraries containing CVEs can be fixed and a report can be generated that includes information regarding each library with a CVE and/or a risk score above a threshold value. Based on the risk score of each library in comparison to a threshold value, a remedial action can be performed).
Velur teaches “based upon the risk score,” but the combination of Velur and Kumar fails to teach:
use the rules to hold the computer program […]
However, Jackson teaches:
use the rules to hold the computer program […]. (Jackson, Col. 10, Lines 28-31, Such a system and method can act on a set of rules embodied in policies 223, 225A, 225B that are predefined to establish what risks are deemed acceptable and what are not, and what actions to take for risks that do not pass; Jackson, Col. 13, lines 64-65, One common action in the case that a component did not pass is to block the component from being served to users).
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
use the rules to hold the computer program based upon the risk score.
The modification would be obvious to one of ordinary skill in the art because by taking steps at critical junctures appropriate for software development to automatically block, quarantine, limit, or notify of software components that fail pre-defined criteria, and possibly by indicating reasons for failure and/or suggesting acceptable software components, the consumption (inbound flow) and publication (outbound flow) of software components that have risks which have already been deemed unacceptable for the repository or for the application can be reduced and/or prevented, dramatically reducing risky behavior and greatly improving overall software development efficiency (Jackson, Col. 5, Lines 8-20).
Regarding Claim 7, the rejection of Claim 5 is incorporated. Velur teaches “the dependency” but the combination of Velur and Kumar fails to teach:
wherein the rules are based upon the severity of the vulnerability and a context of the dependency.
However, Jackson teaches:
wherein the rules are based upon the severity of the vulnerability and a context […] (Jackson, Col. 5, Lines 53-64, As an example of a security vulnerability, consider that a software component might have a vulnerability rated a low level but the application blocks only vulnerabilities at a critical level. Also, a policy can include variations such as to disallow components over a certain age, or under a certain age, or to disallow all open source components. As further discussed herein below, various inventive principles and combinations thereof are advantageously employed to allow a user to establish policies that are appropriate for their system, in which a user can allow components with certain kinds of risks, and disallow others).
[Examiner Remarks: the specification states that “The context can examine such aspects as how the computer program is used, where the program is used, and/or by whom the program is used” (Paragraph [0037]). Thus, one of ordinary skill in the art would readily comprehend that “components over a certain age, or under a certain age, or to disallow all open source components” can be reasonably interpreted as the claimed “context”.]
Velur, Kumar, and Jackson are considered to be analogous to the claimed invention because they are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur and Kumar to incorporate the teachings of Jackson to have:
wherein the rules are based upon the severity of the vulnerability and a context of the dependency.
The modification would be obvious to one of ordinary skill in the art because by taking steps at critical junctures appropriate for software development to automatically block, quarantine, limit, or notify of software components that fail pre-defined criteria, and possibly by indicating reasons for failure and/or suggesting acceptable software components, the consumption (inbound flow) and publication (outbound flow) of software components that have risks which have already been deemed unacceptable for the repository or for the application can be reduced and/or prevented, dramatically reducing risky behavior and greatly improving overall software development efficiency (Jackson, Col. 5, Lines 8-20).
Regarding Claim 9, the rejection of Claim 1 is incorporated. Velur further teaches:
generate a compliance report based upon vulnerabilities identified for the computer system (Velur, Col. 8, Lines 4-8, In block 206, vulnerabilities within the libraries containing CVEs can be fixed and a report can be generated that includes information regarding each library with a CVE and/or a risk score above a threshold value).
Claims 11, 12, 13, 15, 16, 17, 19 are method claims corresponding to the computer system claims hereinabove (Claims 1, 2, 3, 5, 6, 7, 9 respectively). Therefore, Claims 11, 12, 13, 15, 16, 17, 19 are rejected for the same reasons set forth in the rejections of Claims 1, 2, 3, 5, 6, 7, 9 respectively.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Velur (U.S. Patent No. 11,481,498 B2) in view of Kumar (U.S. Patent Application Publication No. US 2023/0161882 A1) in view of Jackson (U.S. Patent No. 10,540,176 B2) and further in view of Plunk (U.S. Patent Application Publication No. US 2024/0330474 A1) and Florescu (U.S. Patent No. 10,732,962 B1).
Regarding Claim 4, the rejection of Claim 1 is incorporated. The combination of Velur, Kumar, and Jackson fails to teach:
block downloading of the dependency,
However, Plunk teaches:
block downloading of the dependency (Plunk, Page 1, Paragraph 0011, For example, improvements to the security of resources in a software dependency management system can be realized by utilizing a proxy server to prevent the download or upload of vulnerable installation packages to software dependency management systems when they violate security policies).
Velur, Kumar, Jackson, and Plunk are considered be analogous to the claimed invention because both are in the same field software management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur, Kumar, and Jackson with the teachings of Plunk to:
block downloading of the dependency,
The modification would be obvious to one of ordinary skill in the art because doing so provides mechanisms for enforcing security policies on software dependency installation packages to prevent the installation of vulnerable dependencies in developer, CI, and/or production systems (Plunk, Page 1, Paragraph 0009).
Velur teaches “the dependency,” but the combination of Velur and Plunk fails to teach:
block code including the dependency during versioning; and
block release of the computer program […].
However, Florescu teaches:
block code including the dependency during versioning; and
block release of the computer program […] (Florescu, Col. 19, Lines 60-66; Col 20, Line 1, systems and methods described herein may improve the functionality of computer systems by mitigating (e.g., preventing) the release of harmful software to a customers of a computing resource service provider, thereby causing an improvement in one or more of the following aspects: security (e.g., preventing software that includes security vulnerability from being released); performance (e.g., preventing code with memory leaks or performance issues from being released)).
Velur, Kumar, Jackson, Plunk, and Florescu are considered be analogous to the claimed invention because both are in the same field software management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur, Kumar, Jackson, and Plunk with the teachings of Florescu to:
block code including the dependency during versioning; and
block release of the computer program including the dependency.
The modification would be obvious to one of ordinary skill in the art because doing so provides mechanisms for enforcing security policies on software dependency installation packages to prevent the installation of vulnerable dependencies in developer, CI, and/or production systems (Plunk, Page 1, Paragraph 0009).
Claim 14 is a method claim corresponding to the computer system claim hereinabove (Claim 4). Therefore, Claim 14 is rejected for the same reasons set forth in the rejection of Claim 4.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Velur (U.S. Patent No. 11,481,498 B2) in view of Kumar (U.S. Patent Application Publication No. US 2023/0161882 A1) in view of Jackson (U.S. Patent No. 10,540,176 B2) and further in view of, and further in view of Plate (U.S. Patent Application Publication No. US 2015/0268948 A1).
Regarding Claim 8, the rejection of Claim 5 is incorporated. The combination of Velur, Kumar, and Jackson fails to teach:
wherein the rules are stored in a central database.
However, Plate teaches:
wherein the rules are stored in a central database (Plate, Page 4, Paragraph 0033, In the example of FIG. 1, the conflict resolution manager 120 may include a storage handler 128 configured to cause the at least one processor 110 to access one or more databases (e.g., one or more database 140) and store data and information related to one or more of the constraint definitions 144, the software component dependencies 145, and the algorithm 147 for analyzing the applications and resolving the software component dependencies 145).
Velur, Kumar, Jackson, and Plate are considered to be analogous to the claimed invention because both are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur, Kumar, and Jackson to incorporate the teachings of Plate to have:
wherein the rules are stored in a central database.
The modification would be obvious to one of ordinary skill in the art because there exists a need to improve software dependencies in applications to thereby reduce the impact of buggy and vulnerable software libraries. (Plate, Page 1, Paragraph 0004).
Claim 18 is a method claim corresponding to the computer system claim hereinabove (Claim 8). Therefore, Claim 18 is rejected for the same reasons set forth in the rejection of Claim 8.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Velur (U.S. Patent No. 11,481,498 B2) in view of Kumar (U.S. Patent Application Publication No. US 2023/0161882 A1) in view of Jackson (U.S. Patent No. 10,540,176 B2) and further in view of Ansell (U.S. Patent Application Publication No. US 2022/0269791 A1).
Regarding Claim 10, the rejection of Claim 9 is incorporated. The combination of Velur, Kumar, and Jackson fails to teach:
identify trends associated with the vulnerabilities identified for the computer system.
However, Ansell teaches:
identify trends associated with the vulnerabilities identified for the computer system (Ansell, Page 7, Paragraph 0039, For example, machine learning algorithm 146 may operate on vulnerability information 138 that includes descriptions of potential future vulnerabilities, and/or describes trends in vulnerabilities that have been associated with security breaches, to predict that certain software programs 124 may be vulnerable to security breaches at some point in the future).
Velur, Kumar, Jackson, and Ansell are considered be analogous to the claimed invention because both are in the same field of assessing vulnerabilities and evaluating computer system security. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Velur, Kumar, and Jackson with the teaching of Ansell to have:
identify trends associated with the vulnerabilities identified for the computer system.
The modification would be obvious to one of ordinary skill in the art because doing so proactively identifies potential vulnerabilities before they are taken advantage of for improper purposes (Ansell, Page 1, Paragraph 0003).
Claim 20 is a method claim corresponding to the computer system claim hereinabove (Claim 10). Therefore, Claim 20 is rejected for the same reasons set forth in the rejection of Claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. They are as follows:
Lewandowski (US 2023/0281316 A1) discloses techniques for identifying and resolving security vulnerabilities in a software application build.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD KAMRUZZAMAN whose telephone number is (571) 272-8415. The examiner can normally be reached Monday-Friday 9:00 am - 5: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, Wei Mui can be reached at (571) 272-3708. 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.
/M.K./Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights