DETAILED ACTION
This action is responsive to the application filed on September 19, 2024.
Claims 1-20 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The drawings filed on September 19, 2024 are acceptable for examination purposes.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-6 and 17-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites "wherein, prior to accessing the specification file, the method comprises: obtaining, by the computing system, the specification file from an entity associated with the software project."
There is insufficient antecedent basis for "accessing the specification file" in this claim. Claim 1 does not recite accessing the specification file. Claim 1 recites "based on a specification file … accessing … Common Vulnerability and Exposure (CVE) information" — that is, the specification file is the *basis* for the accessing step, and the object *accessed* is the CVE information, not the specification file. The claim therefore predicates the timing of the obtaining step on an act that is never recited, and it is unclear whether Applicant intends (i) that the specification file be obtained before the recited accessing of CVE information, or (ii) that claim 1's "based on a specification file … accessing" be construed as itself an accessing *of the specification file*, which would conflict with the express language of claim 1.
Claim 17 recites the identical limitation in system form ("wherein, prior to accessing the specification file, the one or more computing devices are to: obtain the specification file …") and is rejected for the same reason with respect to claim 16.
Dependent claims 3-6 and 18-19 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base claim.
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 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-2, 7-8, 15-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (US Pub. No. 2023/0195901, hereinafter Allen) in view of Velur et al. (US Pub. No. 2020/0242254, hereinafter Velur). With respect to claim 1, Allen teaches a method comprising: based on a specification file descriptive of a particular version of each of a plurality of dependent software packages utilized by a software project, accessing, by a computing system comprising one or more computing devices, [[Common Vulnerability and Exposure (CVE)]] information that identifies a first dependent software package of the plurality of dependent software packages as being associated with [[a known CVE;]] (Allen's back-end computing system (104) "includes a repository (106), an upgrade manager (108), and computer processor(s) (110)" (Allen paragraph [0018]). Allen paragraph [0022] states that "The specification file (154) is a file that stores the dependency specification (150). For example, the specification file (154) may be a Maven project object model (POM) file." Each dependency specification "represents a direct dependency of the component C (114C) on another component," and the called component Q (114Q) "may be a library used by component C (114C)" (Allen paragraph [0021]). Each component is labeled with a component ID and a version ID; Allen paragraph [0019] gives the worked example that "the component “jackson-databind: 2.9.10” has a component ID “jackson-databind” (404) and a version ID “2.9.10” (406)." The specification file is therefore descriptive of a particular version of each of the libraries on which the application depends. At Step 202, the upgrade manager "may obtain the application dependency specifications for the application from a dependency specification file stored in the user computing system (e.g., a Maven project object model (POM) file)" (Allen paragraph [0032]). At Step 204, "vulnerable components are identified using the application dependency specifications and a list of known vulnerable components" (Allen paragraph [0033]), where the known vulnerable components (122) is "a list of components in which vulnerabilities (e.g., security vulnerabilities or obsolescence vulnerabilities) have been detected" and "may include entries of the form <component ID, version ID> indicating that a component labeled with the component ID and version ID is known to be vulnerable" (Allen paragraph [0023])). identifying, by the computing system, an updated version of the first dependent software package [[that mitigates the known CVE;]] (At Step 208, "an upgraded version ID for a component is selected for a candidate dependency specification. The upgrade manager may select an upgraded version ID for the candidate dependency specification that removes the dependency of the application on the vulnerable component" (Allen paragraph [0045]). Allen paragraph [0047] elaborates that the upgrade manager "may select the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list)," and may select "as a “minimal upgrade,” a subsequent version ID that is closest to the current version ID and also removes the dependency on the vulnerable component."). responsive to the determination, generating, by the computing system, a specification update for the specification file, wherein the specification update modifies the specification file such that the software project utilizes the updated version of the first dependent software package (At Step 210, "upgrading the candidate dependency specification to the upgraded version ID is verified, using the application dependency graph generated from the application dependency specifications, to remove a dependency on the vulnerable component" (Allen paragraph [0053]). Responsive to that determination, Step 212 recommends an upgrade solution, which "may be stored in an output file (e.g., a patch file) that includes the upgraded version ID corresponding to each candidate dependency specification," and "The output file may be used to assign, in a specification file corresponding to each candidate dependency specification of the upgrade solution, the upgraded version ID to the respective candidate dependency specification" (Allen paragraph [0058]). Allen paragraph [0025] confirms the modification of the file itself: "the upgrade manager (108) may modify the version ID at line 7 of the dependency specification (402) of FIG. 4A to be an upgraded version ID.").
Allen is silent to disclose that the accessed information is Common Vulnerability and Exposure (CVE) information and that the vulnerability with which the first dependent software package is associated is a known CVE; is silent to disclose that the identified updated version is one that mitigates the known CVE; and is silent to disclose making, by the computing system, a determination that the updated version of the first dependent software package is compatible with the software project; however, in an analogous art, Velur teaches:
Common Vulnerability and Exposure (CVE) information identifying a third-party library as being associated with a known CVE (Velur paragraph [0019] defines the term: "The term “common vulnerability and exposure” (“CVE”) may refer to a catalog of known security threats. A CVE can include vulnerabilities and exposures that have been reported within the public domain." Velur paragraph [0042] teaches that each deployed application is mapped to the third-party libraries it uses and that "Mapping the deployed applications to their third-party library dependencies can include dependency version information. This can provide a snapshot of the current status of each third-party library used by each application." Velur paragraph [0047] teaches that "the dependency tree … is analyzed using known vulnerability databases," which "can include lists of all errors caused by known CVEs that have been experienced and reported by various entities using the third-party libraries," and that "Both direct and transitive dependencies of the dependency tree can be analyzed to determine if any known CVE issues are present.").
that mitigates the known CVE (Velur paragraph [0048] teaches that "A NLP engine can be used to determine whether a known CVE has been fixed in a newer version of a library as compared to a current version of a library being implemented in an API." Velur paragraph [0080] confirms that "A newer version of a fixable library can remove or reduce an impact of the vulnerability in a current version of the fixable library."). making, by the computing system, a determination that the updated version of the first dependent software package is compatible with the software project (Velur paragraph [0050] teaches that "a backwards compatibility check is performed between current and new versions of a third-party library. Any new version of the dependency that has a fix or change can checked against the current version of the dependency for backward compatibility changes. This can ensure that updating to a newer version of a third-party library would not break the existing APIs." Velur paragraph [0050] further teaches that "Dependencies that are determined to have no compatibility changes that would result in a break can be freely updated without issue" — an affirmative determination of compatibility. Velur paragraph [0067] teaches that the check is performed "using an API code comparison tool (e.g., APIDIFF tool [2])." It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen — in which vulnerable components are identified from a specification file together with a list of known vulnerable components and are then upgraded to a clean version ID — such that (i) the vulnerability information accessed is Common Vulnerability and Exposure (CVE) information identifying a known CVE, (ii) the identified updated version is one that mitigates the known CVE, and (iii) a determination is made that the updated version is compatible with the software project, each as taught by Velur, for the following reasons. *First*, Allen expressly contemplates that its process is triggered by a published vulnerability announcement. Allen paragraph [0032] states that the upgrade manager "may obtain the application dependency specifications in response to an announcement of a vulnerability in a component included in the application dependency specifications." Velur paragraph [0019] identifies exactly such a public source, defining a CVE as a catalog of security threats "reported within the public domain," and Velur paragraph [0047] teaches the corresponding "known vulnerability databases" containing "lists of all errors caused by known CVEs." Populating Allen's list of known vulnerable components (Allen paragraph [0023]) from Velur's CVE databases is no more than the use of a known, published information source for the very data Allen's Step 204 already requires, yielding the predictable result of identifying vulnerable components. *Second*, Allen selects an upgraded version by inference from the *absence* of that version from a list — Allen paragraph [0047] selects "the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list)." Velur paragraph [0048] teaches making the corresponding determination affirmatively, using an NLP engine to determine "whether a known CVE has been fixed in a newer version of a library as compared to a current version." Substituting Velur's affirmative determination for Allen's absence-based inference is the simple substitution of one known element for another to obtain predictable results, and would improve the reliability of Allen's selection by confirming that the candidate version actually remedies the vulnerability rather than merely not yet having been reported as vulnerable. *Third*, Allen itself recognizes the compatibility problem that Velur solves, but addresses it only by proxy. Allen paragraph [0047] reasons that "a version ID that is close to the current version ID may be less likely to result in a potential incompatibility in the application due to upgrading to a version ID that is not backward compatible with another component of the application." Allen thus *estimates* compatibility from version proximity without ever testing it. Velur paragraph [0050] supplies the missing test and states its purpose in the same terms: the check "can ensure that updating to a newer version of a third-party library would not break the existing APIs." One of ordinary skill would have been motivated to incorporate Velur's compatibility check into Allen's method in order to obtain the benefit Allen already seeks — avoiding an upgrade that breaks the application — with the predictable improvement of confirming compatibility rather than approximating it by version distance. *Fourth*, the references are analogous art. Both are directed to the same field of endeavor — identifying third-party library dependencies of a software application that carry known security vulnerabilities and upgrading those dependencies to non-vulnerable versions — and both are reasonably pertinent to the same problem addressed by Applicant, namely remediating known vulnerabilities in a project's dependencies without breaking the project. With respect to claim 2, Allen teaches wherein, prior to accessing the specification file, the method comprises: obtaining, by the computing system, the specification file from an entity associated with the software project (Allen paragraph [0028] teaches that "The user computing system (102) includes functionality to send the dependency specifications (120A) corresponding to the application (140) to the upgrade manager (108)," and that "The back-end computing system (104) further includes functionality to store the dependency specifications (120A) corresponding to the application (140) in the repository (106)." Allen paragraph [0032] teaches that the upgrade manager "may obtain the application dependency specifications for the application from a dependency specification file stored in the user computing system (e.g., a Maven project object model (POM) file)." The user computing system (102), which hosts the application (140), is an entity associated with the software project, and the obtaining occurs at Step 202 prior to the identification of vulnerable components at Step 204.). With respect to claim 7, Allen teaches wherein the first dependent software package comprises: an Application Programming Interface (API); a module; a software library; a software framework; a plugin; or a third-party application (Allen paragraph [0021] teaches that "the component Q (114Q) may be a library used by component C (114C) of FIG. 1A." As this limitation is recited in the alternative, Allen's disclosure of a software library satisfies it.) With respect to claim 8, Allen is silent to disclose; however, in an analogous art, Velur teaches wherein making the determination that the updated version of the first dependent software package is compatible with the software project comprises performing, by the computing system, one or more automated compatibility determination processes comprising at least one of: a breaking change identification process; a source code compatibility determination process; or a cross-dependency compatibility determination process (This limitation further defines the compatibility determination credited to Velur in claim 1. Velur paragraph [0067] teaches that "backwards compatibility between current and new versions of a third-party library can be determined using an API code comparison tool (e.g., APIDIFF tool [2])" — a source code compatibility determination process. Velur paragraph [0050] teaches that the check is automated and performed by the system: "Block 314 can be performed automatically after identifying the list of vulnerable third-party libraries and microservices as described in block 312." As this limitation is recited in the alternative, Velur's source code compatibility determination process satisfies it.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen such that making the determination that the updated version of the first dependent software package is compatible with the software project comprises performing one or more automated compatibility determination processes, as taught by Velur, for the reasons set forth in the motivation for claim 1 and for the following further reasons. Allen's upgrade process is machine-executed from end to end: the upgrade manager identifies vulnerable components at Step 204 (Allen paragraph [0033]), selects an upgraded version ID at Step 208 (Allen paragraph [0045]), and verifies the upgrade at Step 210 (Allen paragraph [0053]), each without human intervention. Allen paragraph [0051] further demonstrates that a single application may carry multiple vulnerable components simultaneously, each requiring its own compatibility assessment. A compatibility determination performed manually would not keep pace with the automated identification and selection steps that precede it. Velur paragraph [0050] expressly teaches that the compatibility check is automated, and Velur paragraph [0067] teaches the particular form of that automated process. One of ordinary skill in the art would therefore have been motivated to perform Velur's compatibility check as an automated process within Allen's automated upgrade pipeline, which is the use of a known technique to improve a known method ready for improvement, yielding the predictable result of a compatibility determination that operates at the speed and scale of the automated steps surrounding it. With respect to claim 15, Allen is silent to disclose the determining of a threat metric for the known CVE and the identifying of the updated version responsive to that metric exceeding a threshold threat metric; however, in an analogous art, Velur teaches: determining, by the computing system, a threat metric for the known CVE associated with the first dependent software package (Velur paragraph [0055] teaches that "A risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API." Velur paragraph [0056] teaches that "A risk score can be associated with a microservice or API that depends on one or more third-party libraries affected by a CVE.") and responsive to the threat metric being greater than a threshold threat metric, identifying, by the computing system, the updated version of the first dependent software package as a version of the first dependent software package that mitigates the known CVE (Velur paragraph [0056] teaches that "Risk scores that are determined to be greater than a certain threshold level can result in providing recommendations to take some action to alleviate the risk (e.g., update dependency version, provide notification report with causes of high risk score)." Velur paragraph [0061] teaches that "If an affected API impact level is greater than a threshold value where the API may pose a significant security threat, then an analysis as to whether the current version of the API's affected dependency should be updated to the latest version is determined." Velur paragraph [0067] teaches that "A microservice with a dependency that has been attributed a risk score greater than a threshold value as determined in block 318 can be analyzed to determine what course of action should be performed to resolve the risk," and Velur paragraph [0068] teaches the resulting action: "the microservice can be updated to the fixed version of the dependency."). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have further modified the method of Allen in view of Velur to determine a threat metric for the known CVE and to identify the updated version responsive to the threat metric exceeding a threshold threat metric, as taught by Velur, because Allen upgrades every vulnerable component it detects without regard to the actual exposure that component creates, whereas Velur paragraph [0063] recognizes that a vulnerable library may never be exercised at all: "If code for a specific name space is never called, then the value attributed to that code in the database can be zero." One of ordinary skill would have been motivated to apply Velur's risk-score-and-threshold gate to Allen's upgrade process in order to direct upgrade effort to the dependencies that actually pose a security threat and to avoid the cost and incompatibility risk of upgrading dependencies whose vulnerable code is never reached, which is a predictable improvement to Allen's process. With respect to claim 16, Claim 16 recites limitations similar to claim 1, differing only in that the limitations are recited as a computing system comprising: one or more computing devices to: perform the recited acts rather than as method steps. Allen teaches a computing system comprising: one or more computing devices to: (Allen paragraph [0018] teaches that "The back-end computing system (104) includes a repository (106), an upgrade manager (108), and computer processor(s) (110)." The remaining limitations of claim 16 are rejected for the same reasons set forth for claim 1 and on the same motivation set forth for claim 1. With respect to claim 17, Claim 17 recites limitations similar to claim 2 and is rejected for the same reasons set forth for claim 2. With respect to claim 20, Claim 20 recites limitations similar to claim 1, differing only in that the limitations are recited as a non-transitory computer-readable storage medium that includes executable instructions to cause one or more processor devices to: perform the recited acts rather than as method steps. Allen teaches a non-transitory computer-readable storage medium that includes executable instructions to cause one or more processor devices to: perform the recited acts (Allen paragraph [0074] teaches that "Software instructions in the form of computer readable program code to perform embodiments disclosed herein may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium," and that "the software instructions may correspond to computer readable program code that, when executed by a processor(s), is configured to perform one or more embodiments disclosed herein." The remaining limitations of claim 20 are rejected for the same reasons set forth for claim 1 and on the same motivation set forth for claim 1.
Claims 3-6 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (US Pub. No. 2023/0195901, hereinafter Allen) in view of Velur et al. (US Pub. No. 2020/0242254, hereinafter Velur) and further in view of Turner et al. (US Pub. No. 2021/0141640, hereinafter Turner). With respect to claim 3, Allen teaches wherein obtaining the specification file from the entity associated with the software project comprises: accessing, by the computing system, the specification file [[from a code versioning system for the software project]] (As set forth for claim 2, Allen paragraph [0032] teaches that the upgrade manager "may obtain the application dependency specifications for the application from a dependency specification file stored in the user computing system (e.g., a Maven project object model (POM) file)," and Allen paragraph [0028] teaches that the user computing system sends those dependency specifications to the upgrade manager). Allen in view of Velur is silent to disclose; however, in an analogous art, Turner teaches from a code versioning system for the software project (Turner paragraph [0004] teaches that "version control systems, also called source code management (SCM) systems, are used to track and manage computer program source code as the code is written and revised." Turner paragraph [0044] teaches that "The server computer 402 hosts an upstream repository 404 that stores source code 405 for a project or application" — a code versioning system for the software project. Turner paragraph [0005] teaches that the repository "maintains metadata representing a complete history of a project involving the original code, the programmer's changes, and often changes of other programmers," and Turner paragraph [0046] teaches that a user computer "may host a clone repository 422 comprising a copy 425 of source code" which "generally duplicates the source code 405 of the upstream repository 404," thereby teaching the accessing of project files from the code versioning system). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur such that the specification file is accessed from a code versioning system for the software project, as taught by Turner, because Allen does not specify the system that stores or manages the specification file, and Applicant has admitted that such a file is a component of the software project itself. Allen paragraph [0032] teaches that the upgrade manager obtains the application dependency specifications "from a dependency specification file stored in the user computing system (e.g., a Maven project object model (POM) file)," without identifying the system that tracks, manages, or versions that file. Applicant's Admitted Prior Art supplies what one of ordinary skill understood such a file to be. Specification paragraph [0001], appearing under the heading BACKGROUND, states that "Specification files (or “build” files) are critical components in software projects that define how the project should be compiled, packaged, and managed," that they "contain instructions for building the software, including which dependencies need to be included, how the source code should be compiled, and what configurations should be applied during the build process," and that "Common examples of build files include Makefile in C/C++ projects, pom.xml in Java projects using Apache Maven®, package.json in Node.js® projects, and build.gradle in projects using Gradle®." The specification file of Allen — expressly a Maven project object model (POM) file (Allen paragraph [0022]) — is therefore, by Applicant's own admission, a critical component of the software project. Turner paragraph [0004] teaches that "version control systems, also called source code management (SCM) systems, are used to track and manage computer program source code as the code is written and revised." Turner paragraph [0005] teaches that the repository "maintains metadata representing a complete history of a project involving the original code, the programmer's changes, and often changes of other programmers," and that such systems "enable programmers to create, revise, and store computer program source code in the form of text files." Turner paragraph [0044] teaches that the upstream repository 404 "stores source code 405 for a project or application." One of ordinary skill in the art — knowing from Applicant's Admitted Prior Art that the build file is a critical component of the software project that defines how the project is compiled, packaged, and managed, and knowing from Turner that a version control system is the system used to track and manage that project and to maintain its complete history as text files — would have been motivated to maintain Allen's POM file in, and to retrieve it from, the project's code versioning system. This is the use of a known technique (Turner's SCM repository) to improve a known method (Allen's specification-file-based upgrade process) that is ready for improvement, and it yields the predictable result that the upgrade manager operates on the current, version-controlled specification file rather than on an unmanaged local copy, with the further benefit Turner paragraph [0005] identifies of access to "a complete history of a project." Applicant's admission at Specification paragraph [0001] is relied upon solely as evidence of the background knowledge possessed by one of ordinary skill in the art as to the nature of a specification file, and is not relied upon as teaching any limitation of the claim. It is accordingly not included in the statement of the rejection above. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007) (the obviousness analysis "can take account of the inferences and creative steps that a person of ordinary skill in the art would employ"); MPEP 2141.03. With respect to claim 4, Allen in view of Velur is silent to disclose; however, in an analogous art, Turner teaches wherein generating the specification update for the specification file comprises: generating, by the computing system, a pull request descriptive of the specification update for the specification file, the specification update modifying the software project to utilize the updated version of the first dependent software package (Turner paragraph [0054] teaches that "a request to generate a pull request is received" and that "the pull request module 412 generates a pull request descriptor—this descriptor may include information such as a unique identifier for the pull request, a unique identifier of the requester, a unique identifier of the source repository and branch and a unique identifier for the destination repository and branch, and a status indicator of the pull request." Turner paragraph [0054] further teaches that the pull request is generated to submit source code changes for merger into the master branch: "Once Alice is happy with the changes, she may wish to merge these changes with the master source code 405 … Alice submits a pull request to merge the changes she made in her branch with the master branch." In the combination, the change so submitted is the specification update generated by Allen at paragraph [0058]) and sending, by the computing system, the pull request to the code versioning system (Turner paragraph [0054] teaches that "The pull request descriptor may be submitted to the SCM server 410. The SCM server may store the received pull request descriptor in a database, such as database 414." Turner paragraph [0055] teaches that "the SCM server 410 creates a pull request from the pull request descriptor and forwards the pull request to the one or more participants listed in the pull request descriptor," whereupon "the reviewer(s) identified in the request or any user who has read permission for the destination repository can accept/reject/review the pull request."). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur and further in view of Turner such that the specification update is generated as a pull request and sent to the code versioning system, as taught by Turner, because Allen already requires human review and disposition of its upgrade solution but supplies only an ad hoc interface for it. Allen paragraph [0059] states that "The upgrade solution may be presented to a user (e.g., a software developer or information technology administrator) for review. For example, the upgrade solution may be presented to the user via a graphical user interface (GUI) of the user computing system, where the user may approve or reject the upgrade solution." Turner paragraph [0055] teaches the conventional and purpose-built mechanism for precisely that transaction — a pull request that the SCM server "forwards … to the one or more participants," which the reviewer may "accept/reject/review." One of ordinary skill would have been motivated to deliver Allen's upgrade solution through Turner's pull request rather than through a bespoke GUI, because doing so obtains the approve/reject review Allen expressly calls for using the same code versioning system already established in claim 3 as the source of the specification file, and because Turner paragraph [0005] teaches that the SCM system records the resulting change in the project's complete history. This is the use of a known technique to improve a similar method in the same way, with predictable results. With respect to claim 5, Allen teaches wherein the first dependent software package associated with [[the known CVE]] is one of a subset of dependent software packages of the plurality of dependent software packages, wherein the subset of dependent software packages is associated with [[a plurality of known CVEs comprising the known CVE]] (Allen paragraph [0033] teaches that at Step 204 "vulnerable components are identified using the application dependency specifications and a list of known vulnerable components" — plural. Allen paragraph [0051] describes a worked example in which multiple components of a single application are vulnerable at once: dependency graph C (460) "shows that the version ID of the vulnerable component “commons-compress” is upgraded to a clean (e.g., non-vulnerable) version ID." while "the version ID of the vulnerable component “jackson-databind,” although upgraded, is included in the list of known vulnerable components." The vulnerable components so identified are a subset of the components declared in the application's dependency specifications) and wherein generating the specification update for the specification file comprises: generating, by the computing system, a plurality of specification updates for the specification file, wherein each of the plurality of specification updates modifies the specification file such that the software project utilizes an updated version of a corresponding dependent software package of the subset of dependent software packages (Allen paragraph [0058] teaches that "The upgrade solution may further include upgrading one or more additional candidate dependency specifications to upgraded version IDs that were generated during one or more iterations of Step 206, Step 208, and Step 210 above," and that "The upgrade solution may be stored in an output file (e.g., a patch file) that includes the upgraded version ID corresponding to each candidate dependency specification processed during one or more iterations of Step 206, Step 208, and Step 210 above." Each such upgraded version ID is a specification update corresponding to a respective vulnerable component, and "The output file may be used to assign, in a specification file corresponding to each candidate dependency specification of the upgrade solution, the upgraded version ID to the respective candidate dependency specification" (Allen paragraph [0058]). Allen in view of Turner is silent to disclose; however, in an analogous art, Velur teaches the known CVE and a plurality of known CVEs comprising the known CVE (Velur paragraph [0047] teaches that the known vulnerability databases "can include lists of all errors caused by known CVEs that have been experienced and reported by various entities using the third-party libraries," and that "Both direct and transitive dependencies of the dependency tree can be analyzed to determine if any known CVE issues are present." Velur paragraph [0049] teaches that "a list of vulnerable third-party libraries and microservices is generated" and that "The list can include all direct and transitive dependencies that have vulnerabilities." The list so generated is a subset of the project's dependent software packages that is associated with a plurality of known CVEs). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur and further in view of Turner such that the subset of vulnerable dependent software packages is one associated with a plurality of known CVEs comprising the known CVE, as taught by Velur, because Allen already performs the identification of multiple vulnerable components in a single pass but sources that identification from an unspecified list. Allen paragraph [0033] identifies vulnerable components — plural — "using the application dependency specifications and a list of known vulnerable components," and Allen paragraph [0051] confirms that a single application may carry several vulnerable components simultaneously. Velur paragraph [0049] teaches the corresponding operation performed against CVE data, generating "a list of vulnerable third-party libraries and microservices" that "can include all direct and transitive dependencies that have vulnerabilities," and Velur paragraph [0047] teaches that the underlying databases contain "lists of all errors caused by known CVEs." For the same reasons set forth in the motivation for claim 1, populating Allen's list of known vulnerable components from Velur's CVE databases is the use of a known, published information source for the very data Allen's Step 204 requires, and it applies with equal force where several of the project's dependencies are vulnerable at once: the predictable result is the identification of the subset of dependent software packages associated with the plurality of known CVEs, which Allen then upgrades collectively at paragraph [0058]. With respect to claim 6, Allen teaches wherein the method further comprises: aggregating, by the computing system, the plurality of specification updates generated for the subset of dependent software packages associated with [[the plurality of known CVEs]] to obtain an aggregated specification update (Allen paragraph [0058] teaches that the upgrade solution is "stored in an output file (e.g., a patch file) that includes the upgraded version ID corresponding to each candidate dependency specification processed during one or more iterations of Step 206, Step 208, and Step 210 above." The single output/patch file collecting the upgraded version ID for every processed candidate dependency specification is an aggregated specification update.) and applying, by the computing system, the aggregated specification update to the specification file (Allen paragraph [0058] teaches that "The output file may be used to assign, in a specification file corresponding to each candidate dependency specification of the upgrade solution, the upgraded version ID to the respective candidate dependency specification." Allen paragraph [0025] teaches that "The upgrade manager (108) includes functionality to apply the upgrade solution (130) by assigning, in a dependency specification (150J), an upgraded version ID (160J) to a component."). Allen in view of Turner is silent to disclose; however, in an analogous art, Velur teaches the plurality of known CVEs (Velur paragraph [0047] teaches that the known vulnerability databases "can include lists of all errors caused by known CVEs that have been experienced and reported by various entities using the third-party libraries." Velur paragraph [0049] teaches that "a list of vulnerable third-party libraries and microservices is generated," as set forth for claim 5.) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur and further in view of Turner such that the plurality of specification updates aggregated into the aggregated specification update are those generated for the subset of dependent software packages associated with a plurality of known CVEs, as taught by Velur, for the same reasons set forth in the motivation for claim 5. Velur paragraph [0051] independently confirms the desirability of collecting such vulnerable dependencies into a single set, teaching "pseudo logic that can be used to aggregate a list of vulnerable third-party libraries according to some examples," so that one of ordinary skill would have recognized that Allen's single output/patch file (Allen paragraph [0058]) and Velur's aggregated list of CVE-affected libraries operate on the same subset of dependencies to the same end, with predictable results. With respect to claim 18, Claim 18 recites limitations similar to claim 3 and is rejected for the same reasons set forth for claim 3 and on the same motivation set forth for claim 3.
With respect to claim 19, Claim 19 recites limitations similar to claim 4 and is rejected for the same reasons set forth for claim 4 and on the same motivation set forth for claim 4.
Claims 9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (US Pub. No. 2023/0195901, hereinafter Allen) in view of Velur et al. (US Pub. No. 2020/0242254, hereinafter Velur) and further in view of Liu et al. (US Pub. No. 2023/0049741, hereinafter Liu). With respect to claim 9, Allen is silent to disclose; however, in an analogous art, Velur teaches wherein performing the one or more automated compatibility determination processes comprises performing, by the computing system, the breaking change identification process (Velur paragraph [0050] teaches that "the a backwards compatibility tool can be used to determine if updating dependencies can cause a break in an API when updating would be recommended to fix a known CVE" — the identification of changes that break an API. Velur paragraph [0050] further teaches that the process is automated: "Block 314 can be performed automatically after identifying the list of vulnerable third-party libraries and microservices as described in block 312.") It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen such that the automated compatibility determination process performed is the breaking change identification process, as taught by Velur, for the reasons set forth in the motivation for claim 1 and in the motivation for claim 8. Allen in view of Velur is silent to disclose the obtaining of commit history information and the determining, based on that information, that the changes are non-breaking changes that retain the existing dependency; however, in an analogous art, Liu teaches obtaining, by the computing system, commit history information descriptive of one or more changes made to the first dependent software package between the particular version of the first dependent software package and the updated version of the first dependent software package (Liu paragraph [0071] teaches that "The one or more web-based sources 104 may include one or more web-based software hosting sources (e.g. GitHub®), one or more version control system, one or more web-based software metadata storage service, or one or more websites." Liu paragraph [0176] teaches that "a set of second messages may include the one or more changes that may be introduced in the source code of the second version of the software. Each of the set of second messages may be written by a developer or contributor, about one or more changes that the developer or the contributor may have incorporated in the second version of the software. For example, each of the set of second messages may correspond to a commit message on GitHub®." Liu paragraph [0147] teaches that "the system 102 may be configured to retrieve a set of first messages associated with the software, from the one or more web-based sources 104. Specifically, the set of first messages may be associated with one or more changes introduced in the source code of a version of the software." The messages so retrieved are descriptive of the changes made between the first version (v1.0) and the second version (v2.0) of the software (Liu paragraph [0170])) and based on the commit history information, determining, by the computing system, that each of the one or more changes comprises non-breaking changes that retain an existing dependency between the first dependent software package and the software project. Liu paragraph [0157] teaches that "the system 102 may be configured to execute a pattern searching operation (of a set of operations) on each of the one or more messages of the set of first messages … to detect one or more labels in the set of first messages," and that "Such labels may include words, such as “breaking”, “break”, “incompatible”, and “breaking change”." Liu paragraph [0158] teaches the disposition of that search: "it may be determined whether the one or more labels are detected in one or more messages of the set of first messages. In case the one or more labels are detected, the control may be transferred to 1006. Otherwise, the control may be transferred to 1010." Liu paragraph [0161] teaches the further keyword analysis performed at 1010, in which "one or more first keywords" semantically similar to the labels — "compatibility changes”, “stop”, “interrupt”, “conflict” and the like" — are detected. The absence of any breaking-change label or keyword from the messages is the determination that the changes are non-breaking, and Liu paragraph [0032] confirms the purpose of this analysis: "the second decision parameter may be associated with a textual description that may be written by a programmer about the updates in the updated version of the software."). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur to obtain commit history information and determine therefrom that the changes are non-breaking, as taught by Liu, because Velur already performs its compatibility analysis on developer-authored prose about the update, and Liu supplies an additional and more targeted body of such prose. Velur paragraph [0048] teaches that "The release notes and changelogs … can be run through a natural language processing (“NLP”) engine that understands the semantics of software bug-fixes and vulnerabilities," while Liu paragraph [0176] teaches that commit messages are "written by a developer or contributor, about one or more changes that the developer or the contributor may have incorporated in the second version of the software." Liu paragraph [0027] identifies the very problem this addresses: "after the update of the OSS, the APIs may not work in the required manner or may not work at all. This may lead to unavailability of one or more functions in the client application." One of ordinary skill would have been motivated to extend Velur's textual compatibility analysis from release notes and changelogs to the commit messages taught by Liu in order to obtain a more complete record of what changed between versions, since release notes are summaries prepared for publication whereas commit messages accompany each individual change, with the predictable result of detecting breaking changes that a release note omits. With respect to claim 11, Allen is silent to disclose; however, in an analogous art, Velur teaches wherein performing the one or more automated compatibility determination processes comprises performing, by the computing system, the source code compatibility determination process (Velur paragraph [0067] teaches that "backwards compatibility between current and new versions of a third-party library can be determined using an API code comparison tool (e.g., APIDIFF tool [2])," which determines compatibility by comparing the code of the two versions). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen such that the automated compatibility determination process performed is the source code compatibility determination process, as taught by Velur, for the reasons set forth in the motivation for claim 1 and in the motivation for claim 8. Allen in view of Velur is silent to disclose the obtaining of the source code of the particular version and of the updated version and the determining that invocations to invoke invokable functions are retained between them; however, in an analogous art, Liu teaches obtaining, by the computing system, a particular version of source code for the particular version of the first dependent software package (Liu paragraph [0094] teaches that the system "may be configured to determine version information associated with the determined software," where "The version information may specify a current version (or the first version) of the software used in the source code of the software application." Liu paragraph [0169] teaches sorting "each of the one or more versions of the determined software based on a release date associated with each version," and Liu paragraph [0171] teaches that the system "may be configured to parse and analyze information associated with each version of the software to determine changes in the source code of each neighboring version pair of the determined software."). obtaining an updated version of source code for the updated version of the first dependent software package (Liu paragraph [0170] teaches that "the system 102 may be configured to determine changes in the source code between two successive versions of the determined software. For example, the successive versions may include the first version (v1.0) of the software and the second version (v2.0) of the software." Liu paragraph [0173] teaches that "each code chunk may correspond to one or more changes introduced in the source code of the second version of the software with respect to a source code of the first version of the software," and Liu paragraph [0174] teaches that the system "may be configured to store each of the one or more code chunks in the memory of the system 102."). determining, by the computing system, that invocations to invoke invokable functions are retained between the particular version of the source code and the updated version of the source code (Liu paragraph [0180] teaches that the system "may be configured to determine a first change change [sic] associated with a definition of a first function of one or more functions in the second version of the software," determined "with respect to the first version of the software," and explains the significance of the invocation: "the source code of the software application may include an API call code, which when executed, sends an API call to a server that executes the function based on parameters in the API call." Liu paragraph [0181] teaches determining "a second change of the one or more changes in a set of input parameters of the first function," which "may break backward compatibility, if the source code of the software application uses the set of inputs parameters from the first version of the software." Liu paragraph [0182] teaches determining "a third change … in one or more output parameters of the first function." Where no such change is found, Liu outputs the affirmative determination that the invocation is retained: "the system 102 may output that the first function does not break the compatibility with respect to the function definition" (Liu paragraph [0202]); "the system 102 may output that the first function does not break the compatibility in relation to the set of input parameters" (Liu paragraph [0215]); and "the system 102 may output that the first function does not break the compatibility from the perspective of the one or more output parameters" (Liu paragraph [0230])). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur to obtain the source code of both the particular version and the updated version of the dependent software package and to determine therefrom that invocations to invoke invokable functions are retained, as taught by Liu, because Velur already performs a source code comparison for exactly this purpose but does not disclose how the comparison is carried out. Velur paragraph [0067] teaches only that compatibility "can be determined using an API code comparison tool (e.g., APIDIFF tool [2])," naming the tool without teaching its operation. Liu paragraph [0032] supplies that operation, teaching that "A first decision parameter may be associated with the source code in both the versions of the software," and Liu paragraphs [0180]-[0182] teach the specific comparisons — of function definition, input parameters, and output parameters — that determine whether a caller's invocation survives the upgrade. One of ordinary skill seeking to implement the API code comparison that Velur paragraph [0067] requires would have looked to Liu's express teaching of how such a comparison is performed, with the predictable result of determining whether the application's existing API calls remain valid against the updated library.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Allen (US Pub. No. 2023/0195901, hereinafter Allen) in view of Velur et al. (US Pub. No. 2020/0242254, hereinafter Velur) in view of Liu et al. (US Pub. No. 2023/0049741, hereinafter Liu) and further in view of Zhang (US Pub. No. 2022/0066752, hereinafter Zhang). With respect to claim 12, Allen in view of Velur and further in view of Liu is silent to disclose the constructing of an abstract syntax tree representation of each of the two versions of the source code and the comparing of those representations; however, in an analogous art, Zhang teaches constructing, by the computing system, an abstract syntax tree representation of the particular version of the source code (Zhang paragraph [0026] teaches that "source code may be converted into an abstract syntax tree (AST) and/or control flow graph (CFG), either of which may maintain not only the syntax of the code, but also the underlying structure," and that such graphs represent "a source code snippet before (predecessor) and after (successor) the source code snippet is changed." Zhang paragraph [0034] teaches the construction itself: "a predecessor source code snippet 205 and a successor source code snippet 210 may be processed by a “code-to-AST” component 215 to generate, respectively, first AST 220 and second AST 225." The predecessor source code snippet corresponds to the particular version of the source code.) constructing, by the computing system, an abstract syntax tree representation of the updated version of the source code (Zhang paragraph [0034] teaches that the same “code-to-AST” component 215 generates second AST 225 from successor source code snippet 210. The successor source code snippet — the snippet "after (successor) the source code snippet is changed" (Zhang paragraph [0026]) — corresponds to the updated version of the source code.) and comparing, by the computing system, the abstract syntax tree representation of the particular version of the source code and the abstract syntax tree representation of the updated version of the source code [[to determine that the invocations to invoke the invokable functions are retained between the particular version of the source code and the updated version of the source code.]] (Zhang paragraph [0035] teaches that "the first AST 220 and the second AST 225 may be processed by a mapping module 230 to generate an AST mapping 235. The mapping module 230 may generate, as the AST mapping 235, a mapping across the first AST 220 and the second AST 225 using, e.g., a tree-based code differencing algorithm," and that "the AST mapping 235 may be a mapping between pairs of similar nodes in the first AST 220 and the second AST 225." Zhang paragraph [0026] teaches the result of that comparison: "A change graph can be generated based on graphs representing a source code snippet before (predecessor) and after (successor) the source code snippet is changed."). The bracketed portion — [[to determine that the invocations to invoke the invokable functions are retained between the particular version of the source code and the updated version of the source code]] — is taught by Liu as set forth for claim 11 (Liu paragraphs [0180]–[0182], [0202], [0215], [0230]), and remains credited to Liu. It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur and further in view of Liu such that the two versions of the source code are represented as abstract syntax trees and compared as such, as taught by Zhang, because Zhang expressly identifies the deficiency of the textual comparison that Liu employs and expressly teaches the abstract syntax tree as the remedy for it. Liu performs its version comparison textually. Liu paragraph [0157] teaches that its pattern searching operation "may be a string searching operation that may use one or more regular expressions," and Liu paragraph [0177] teaches that "The system 102 may be configured to use one or more regular expressions to detect such changes in the source code." Zhang paragraph [0025] addresses precisely this approach and states its shortcoming: "Although it is possible to perform text comparisons to determine textual changes between different versions of source code, these textual changes may not convey structure relationships embodied in the source code, e.g., between different logical branches, statements, variables, etc." Zhang paragraph [0026] then supplies the solution in the immediately following paragraph: "source code may be converted into an abstract syntax tree (AST) and/or control flow graph (CFG), either of which may maintain not only the syntax of the code, but also the underlying structure." Zhang thus provides an express teaching, suggestion, and motivation in the prior art itself to substitute abstract syntax tree comparison for the textual, regular-expression-based comparison of Liu, and articulates the benefit obtained — preservation of the structural relationships that a text comparison discards. One of ordinary skill in the art seeking to determine whether a caller's function invocations survive a library upgrade (Liu paragraph [0180]) would have been motivated to adopt Zhang's AST representation in order to compare the two versions structurally rather than textually, with the predictable result of more accurately identifying the changes between versions. Zhang paragraph [0025] confirms that this determination is made in the same context as the claimed invention — "knowledge of past changes made to source code, such as during code base migration, update, or maintenance events" — and Zhang is therefore analogous art, being reasonably pertinent to the problem of accurately identifying changes made between two versions of source code.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Allen (US Pub. No. 2023/0195901, hereinafter Allen) in view of Velur et al. (US Pub. No. 2020/0242254, hereinafter Velur) and further in view of Nagaraja et al. (US Pub. No. 2020/0202007, hereinafter Nagaraja). With respect to claim 14, Allen in view of Velur is silent to disclose the performing of the cross-dependency compatibility determination process, the instantiating of a test execution environment using the updated version, and the executing of a unit test suite evaluating compatibility with the other dependent software packages; however, in an analogous art, Nagaraja teaches: wherein performing the one or more automated compatibility determination processes comprises performing, by the computing system, the cross-dependency compatibility determination process (Nagaraja paragraph [0007] teaches a method operating on "a candidate application that uses a plurality of code libraries." Nagaraja paragraph [0052] teaches that "the remediation computer can incorporate the determined library version into the candidate application to form a test application," leaving the application's remaining libraries in place, and Nagaraja paragraph [0054] teaches that "the remediation computer can perform one or more application tests on the test application." Testing the candidate application with the substituted library version against its other libraries is a cross-dependency compatibility determination process.) instantiating, by the computing system, a test execution environment for the software project using the updated version of the first dependent software package (Nagaraja paragraph [0052] teaches that "the remediation computer can incorporate the determined library version into the candidate application to form a test application. This can be done by changing the library version called in the locations identified in step 306." Nagaraja paragraph [0053] teaches that "the remediation computer can build the test application on a certification server. Building the test application on a certification server to may allow it to be tested in a controlled environment." Nagaraja paragraph [0024] teaches that "A test application may be built in a test environment, which may closely resemble a production environment," and Nagaraja paragraph [0035] teaches that the certification server 140 "may support a test environment for building a test application. This allows the application to be tested in such a way that simulates the final deployment in a controlled way.") and executing, by the computing system, a unit test suite configured to evaluate compatibility between the updated version of the first dependent software package and other dependent software packages of the plurality of dependent software packages (Nagaraja paragraph [0054] teaches that "the remediation computer can perform one or more application tests on the test application. Application tests may include functionality testing, regression testing, performance testing, and user interface testing." Nagaraja paragraph [0089] teaches that "Regression tests can be tests that verify that a new version of an application maintains the functionality of previous versions," and Nagaraja paragraph [0056] teaches that "Regression testing may include testing that an application performs all previous functionality. Regression testing may involve testing functionality tests from previous versions of the application." Nagaraja paragraph [0041] teaches that the application testing module 130D-2 "can send testing commands to the certification server 140 for testing of the application" and "may set an error flag to indicate that the application has failed a particular test." Because the test application is the candidate application with only the vulnerable library's version changed (Nagaraja paragraph [0052]) while its remaining libraries are unchanged, the tests executed against it evaluate whether the substituted library version continues to function with the other libraries of the application (Nagaraja paragraph [0007]: "a candidate application that uses a plurality of code libraries")). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to have modified the method of Allen in view of Velur to instantiate a test execution environment using the updated version and to execute a test suite evaluating compatibility with the project's other dependent software packages, as taught by Nagaraja, because Velur already runs test suites to assess the impact of vulnerable dependencies but stops short of testing the upgraded application, and Allen expressly recognizes that an upgrade may fail on account of the *other* components of the application. Velur paragraph [0055] teaches that "Various test suites can be run to determine which code paths and which APIs are affected by the dependency vulnerabilities," thereby establishing that automated testing is already part of the combined method. Allen paragraph [0047] identifies the residual risk that testing would address: "a version ID that is close to the current version ID may be less likely to result in a potential incompatibility in the application due to upgrading to a version ID that is not backward compatible with another component of the application" — an acknowledgment that an upgraded component may be incompatible with the application's other components, which Allen never verifies by execution. Nagaraja paragraph [0053] supplies that verification, teaching that the test application is built on a certification server so that "it to be tested in a controlled environment," and that "If the test application fails to build, the remediation computer can flag any generated errors and repeat from step 310 with the next ranked library version." One of ordinary skill would have been motivated to incorporate Nagaraja's test environment and test suite into the combined method in order to confirm, before the upgrade is applied, the very compatibility that Allen paragraph [0047] merely estimates from version proximity — with the predictable benefit Nagaraja paragraph [0024] identifies: "A test application allows the application to be tested before committing changes to a final product." The references are analogous art, both being directed to remediating vulnerable code libraries in a software application by upgrading them to non-vulnerable versions (Nagaraja paragraph [0007]).
Allowable Subject Matter
Claims 10 and 13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if the rejections under 35 U.S.C. 112(b) set forth above are overcome.
The prior art of record does not teach or reasonably suggest processing, by the computing system, the commit history information with a machine-learned language model to obtain an output indicating that each of the one or more changes comprises the non-breaking changes that retain the existing dependency between the first dependent software package and the software project (claim 10), or processing, by the computing system, the particular version of the source code and the updated version of the source code with a machine-learned language model to obtain an output indicating that the invocations to invoke the invokable functions are retained between the particular version of the source code and the updated version of the source code (claim 13).
Velur paragraph [0048] teaches a natural language processing engine applied to release notes and changelogs, but does not teach or suggest that the engine comprises a machine-learned language model. Liu performs its message and source code analyses by pattern searching using regular expressions (Liu paragraphs [0157], [0177]) rather than with any machine-learned model. Zhang paragraph [0038] applies a machine learning model to align nodes of abstract syntax trees, but that model is "a GNN" — a graph neural network operating on graph nodes — and is neither a language model nor applied to commit history information. Nagaraja paragraph [0090] applies a machine learning algorithm to classify error flags, not to determine whether a change is breaking.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Dorrans et al. (US Pub. No. 2020/0074084) Tools and techniques are described to protect private configuration and operation information while obtaining pertinent data about known vulnerabilities of packages, runtimes, and software components of various kinds. Dependencies between software items may be traversed to get more complete vulnerability information. Version numbers and other telemetry about installed components, and operational events from installed components, may be exported from a system while nonetheless protecting the privacy of system-specific details. Privacy protections may include withholding private information from a repository or other vulnerability list source, using truncated hashes or fingerprints to select an obscuring subset of the available vulnerability list, anonymizing telemetry, aggregating telemetry, and other mechanisms. Vulnerability warnings may be given upon loading a component or launching an application, building a project, selecting a component for deployment, adding a component to a project or workspace, and other events. Updates to components may be performed to remove known vulnerabilities. (see abstract).
Whitmore (US Pub. No. 2024/0039944) an automated method, system, device and/or computer program for performing security analysis of an information system or computing device by modeling attacks and attack surfaces using Knowledge Graphs and Graph Computing systems. A contextual data model and a set of data instances of security knowledge can be accessed. A Knowledge Graph representing a Simulated Neural Network for security attacks can be built and trained. A security analysis tool can receive a description of an attack scenario. The Graph Computing system can analyze an attack scenario using the Security Attack Knowledge Graph. A set of observations about the attack scenario and the attack surface can be generated. The observations can include attack paths, recommendations and action plans on how to detect, prevent or address the attack scenario. The action plans can be invoked and applied to the target information system and its operating environment either manually, or by automation. (see abstract). Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights