DETAILED ACTION
This action is responsive to the application filed on September 27, 2024.
Claims 1-20 are pending and presented for 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.
Priority
Acknowledgment is made of applicant’s claim for the benefit of a prior-filed provisional application under 35 U.S.C. 119(e), U.S. Provisional Application No. 63/586,570, filed September 29, 2023. Accordingly, the effective filing date of claims 1-20 is September 29, 2023.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated October 29, 2025 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Drawings
The drawings are objected to because of the following informalities:
FIG. 2 is inconsistent with itself and with the specification. In project policy 204, rule 204b reads “Dynamic Analysis Scan = No runtime failures from Mayhem fuzzing.” In release policy 206, however, the entry labeled 204b reads “Static Analysis Scan = No buffer overflow weaknesses,” which duplicates rule 202c. The specification states that release policy 206 specifies rules 202a, 204a, 202c, 204b (spec paragraph [0051]); the entry labeled 204b in release policy 206 should therefore recite the dynamic analysis rule of project policy 204.
In FIG. 2, rules 202b and 204a recite “vulnerabilities” (e.g., “SCA Scan = No medium, high, or critical vulnerabilities”), whereas paragraph [0050] of the specification quotes the same rules as reciting “weaknesses” (“SCA Scan = No medium, high, or critical weaknesses”; “SCA Scan = No high or critical weaknesses or medium weaknesses that are reported weaponized by CTI”). The drawing and the specification must recite the same rule text; applicant may correct either FIG. 2 or paragraph [0050].
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The specification is objected to because of the following informalities:
Paragraph [0021] recites “Organizations to provide software bill of materials (SBOMs) which is a complete inventory of software components,” which lacks a verb and has a singular verb for a plural subject. Suggested: -- Organizations are required to provide software bills of materials (SBOMs), each of which is a complete inventory of software components --.
Paragraph [0034] recites “the number of test passed.” Suggested: -- the number of tests passed --.
Paragraph [0040] recites “build monitoring module 104 can send provide provenance bundle 110,” which contains two verbs. Suggested: -- build monitoring module 104 can send or otherwise provide provenance bundle 110 --. The same paragraph recites “there is no medium, high, or critical weaknesses” (twice) and “there is a medium, high, or critical weaknesses.” Suggested: -- there are no medium, high, or critical weaknesses -- and -- there is a medium, high, or critical weakness --.
Paragraphs [0041] and [0046] recite “recommendation rational.” Suggested: -- recommendation rationale --, consistent with the remainder of the specification and claims 4 and 13.
Paragraph [0049] recites “The types of policies and the number of policies cascaded in Fig. 2 is merely illustrative.” Suggested: -- are merely illustrative --.
Paragraph [0051] recites “release policy specifies rules 202a, 204a, 202c, 204b” without the reference numeral. Suggested: -- release policy 206 specifies rules 202a, 204a, 202c, 204b --.
The use of the term Mayhem (paragraph [0050] and FIG. 2), which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM, or ® following the term. Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Appropriate correction is required.
Claim Objections
Claims 5 and 10-20 are objected to because of the following informalities:
Claim 5 (and similar for claim 14) recites “wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts regarding actors and actions taken by the actors.”. The actions” lacks antecedent basis because no actions are recited earlier in the claim. Please remove “the” as indicated by strikethrough. Appropriate correction is required.
Claim 10 recites the limitations “one or more non-transitory machine-readable [[mediums]] media configured to store instructions;” in lines 2-3 and “one or more processors configured to execute the instructions stored on the one or more non-transitory machine-readable [[mediums]] media, wherein execution of the instructions causes the one or more processors to carry out a process comprising:” in lines 4-7. The plural of “medium” in this context is “media” (compare claim 19, reciting “medium”). Please replace “mediums” with -- media -- as indicated in bold. Appropriate correction is required.
Claim 19 recites the limitation “providing the recommendation regarding releasability of the software build to [[another]] a computing device.” in lines 14-15. Claim 19 does not previously recite a computing device (the process is carried out by “one or more processors”), so “another computing device” has no first computing device to which it refers. Please replace “another” with -- a -- as indicated in bold. Appropriate correction is required.
Claims 11-18, which depend from claim 10, and claim 20, which depends from claim 19, do not overcome the deficiency of their respective base claims and, therefore, are objected to for the same reasons as their base claims. Claim 14 is additionally objected to for the reason set forth above with respect to claim 5.
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, 4-5, 10, 13-14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bean et al. (US Pub. No. 2024/0168739, hereinafter Bean) in view of Mirantes et al. (US Pub. No. 2021/0232388, hereinafter Mirantes).
With respect to claim 1, Bean teaches a method comprising: (Bean, paragraph [0072]: “Example 1 is a method comprising”) generating a provenance bundle based on a monitoring of the workflow (Bean, paragraph [0034]: “trusted attestor 215 monitors the build process of container image 230 and generates an attestation log describing evidence of the build process”; see also Bean, paragraph [0077]: “generating the attestation log based on observing the build pipeline building the container image”. The attestation log is a collection of evidence documenting how the container image was built, and it is generated based on the trusted attestor’s monitoring (observing) of the build process. Under the broadest reasonable interpretation, the attestation log is a provenance bundle generated based on a monitoring of the workflow. Applicant describes the provenance bundle as containing “information (e.g., artifacts) about events that occur during building of the software” (spec paragraph [0026]); Bean’s attestation log likewise contains the information corresponding to each task used to build the image (Bean, paragraph [0054]: “the signed attestation log 235 includes information corresponding to tasks 210 utilized by the untrusted build pipeline 205 to build the container image 230”).) executing a decision engine to evaluate the provenance bundle based on one or more predetermined policies to thereby generate a recommendation regarding releasability of the software build (Bean, paragraph [0036]: “Gate 250 (e.g., an evaluator utility) performs attestation signature verification 255, policy requirements verification 260, and other policy checks 265”; Bean, paragraph [0037]: “policy requirements verification 260, which compares the digest information 280 with the evidence in signed attestation log 235 to determine whether container image 230 meets the build requirements. Container image 230 is then considered releasable if signed attestation log 235 identifies pipeline tasks/steps that meet each of the build requirements described in policies 275”; see also Bean, paragraph [0051]: “reports the output of the evaluator utility, which includes pass/fail status, violations (e.g., ‘task C not completed’), and warnings”. Gate 250 is the decision engine; it executes policy requirements verification 260 to evaluate the signed attestation log (the provenance bundle) against policies 275 (the predetermined policies) and determines whether the container image is releasable, reporting a pass/fail status. That releasable-or-not determination is the recommendation regarding releasability of the software build. The policies are predetermined, being established by the software factory before the build and downloaded for the evaluation (Bean, paragraph [0013]: “a software factory that is predetermined and policy-based”; Bean, paragraph [0049]: “processing logic downloads the policies”), and the evaluation is performed by processing device 115 of computing device 110 (Bean, paragraph [0063]). The gate result is advisory, identifying corrective action for the build pipeline (Bean, paragraph [0060]: “gate results 710 include solutions to correct issues, such as which tasks to add/remove in the build pipeline 205”).) and providing the recommendation regarding releasability of the software build to another computing device (Bean, paragraph [0037]: “trusted release pipeline 240 generates a report and provides the report to untrusted build pipeline 205 of the tasks that have not been met”; Bean, paragraph [0060]: “sends gate result 710 to untrusted build pipeline 205, which informs the user of untrusted build pipeline 205 of the build requirements that are not met”; Bean, paragraph [0024]: “computing device 110 may be operated by a first company/corporation and one or more computing devices 150 may be operated by a second company/corporation”. The report is sent to the user of the untrusted build pipeline (Bean, paragraph [0051]: “processing logic sends the report to the user for the user to iteratively modify the untrusted build pipeline 205”), who customizes that pipeline from a user device separate from computing device 110 that performs the evaluation (Bean, paragraph [0021]: “the build pipeline is an unlocked build pipeline and customizable by a user device”); Bean’s computing devices 110 and 150 are distinct devices that may be operated by different entities (Bean, paragraph [0024]). Providing the report (gate result) to the user device is providing the recommendation regarding releasability of the software build to another computing device.)
Bean is silent to disclose receiving, by a computing device, a request for a software build; and responsive to receipt of the request for the software build, by the computing device: retrieving source code for the software build; retrieving a software build file for the software build, the software build file defining a build pipeline; and executing a workflow to implement the software build file; however, in an analogous art, Mirantes teaches:
receiving, by a computing device, a request for a software build; and responsive to receipt of the request for the software build, by the computing device: (Mirantes, paragraph [0030]: “This commit may launch an automated lint, build or testing operation that validates the application code whenever changes are checked into the repository”; Mirantes, paragraph [0038]: “When users commit the application code in the version management system, execution of the pipeline may be triggered”. A developer’s commit triggers an automated build operation on Mirantes’s computer system; receipt of the commit-triggered build trigger is receiving, by a computing device, a request for a software build. Mirantes also teaches an express request: “a first stage of the pipeline may be triggered by invoking a web service and providing configuration file 202 to the web service” (Mirantes, paragraph [0038]). The pipeline stages that follow are performed by computer system 102 in response to that commit or request (Mirantes, paragraph [0016]: “Computer system 102 may include configuration file subsystem 112, gate mapping file subsystem 114, pipeline execution subsystem 116, state machine subsystem 118”); the subsequent steps are therefore performed responsive to receipt of the request for the software build, by the computing device.)
retrieving source code for the software build; (Mirantes, paragraph [0038]: “The version management system stores the application code in a repository (e.g., database 132)”, and “a first stage of the pipeline may include compiling the application code”. The application code (source code) is stored in the repository, and the first pipeline stage compiles that code, which necessarily entails retrieving the source code from the repository for the software build. See also Mirantes, paragraph [0030]: “they commit their changes to a source control repository (e.g., database 132 or development subsystem 122)”; Mirantes, paragraph [0024]: “linting is a process that analyzes source code”.)
retrieving a software build file for the software build, the software build file defining a build pipeline (Mirantes, paragraph [0006]: “a system obtains a configuration file having a set of attribute values that is descriptive of an application”; Mirantes, paragraph [0049]: “configuration file 202 associated with application 208 is obtained”; Mirantes, paragraph [0021]: “System 100 may determine the gates to be invoked for the application based on a configuration file associated with the application”; Mirantes, paragraph [0034]: “The configuration file may also include other parameters such as a name of the software routine to be invoked, location (e.g., URL) of the software routine”; Mirantes, paragraph [0028]: “the actions ‘risk check,’ ‘lint,’ ‘build,’ ‘test,’ and ‘deploy’ are to be performed”. Configuration file 202 is specific to the application being built and is obtained (retrieved) when the pipeline is triggered; processed with the gate mapping file, it determines which pipeline actions (lint, build, test, deploy) are invoked, and it may itself name the software routines to be invoked. Configuration file 202 is therefore a software build file for the software build that defines a build pipeline.)
executing a workflow to implement the software build file (Mirantes, paragraph [0029]: “invoke the selected gates 206, which causes a set of software routines to be executed for performing the corresponding actions”; Mirantes, paragraph [0031]: “the state machine subsystem 118 invokes the selected gates … from the CI/CD pipeline 305b causing a set of software routines corresponding to the lint, build, unit test, or deploy to be executed”. Mirantes, paragraph [0052]: “the selected set of gates 206 are invoked to cause a set of software routines corresponding to the selected set of gates 206 execute on one or more portions of the application code”. Invoking the gates determined from configuration file 202 causes the corresponding lint/build/test/deploy software routines to execute, which is executing a workflow to implement the software build file.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the supply-chain release-evaluation system of Bean to receive a software-build request upon a source-code commit, retrieve the source code from the repository, retrieve a configuration file defining the build pipeline, and execute the pipeline workflow to implement that file, as taught by Mirantes, in order to provide a customizable, automated build front end that triggers the build on commit and defines the build pipeline through a configuration/gate-mapping file, thereby eliminating the need for users to develop complex pipeline code and enabling the pipeline to be reused across different applications (Mirantes, [0004], [0008]). Bean contemplates building the container image with an untrusted build pipeline that is customizable by a user device (Bean, [0021], [0034]) but does not detail how the build is requested, how source is obtained, or how the pipeline is defined and executed; Mirantes supplies those conventional front-end steps, and the combination unites prior-art elements according to known methods to yield the predictable result of an end-to-end, policy-gated CI/CD release pipeline. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007); MPEP § 2143(I)(A). With respect to claim 4, Bean teaches wherein the recommendation includes a recommendation rationale (Bean, paragraph [0051]: “reports the output of the evaluator utility, which includes pass/fail status, violations (e.g., ‘task C not completed’), and warnings”; see also Bean, paragraph [0037] (report of the tasks that have not been met); Bean, paragraph [0060]: “gate results 710 include solutions to correct issues”. The evaluator’s identification of the specific violations and unmet build requirements is the reason for the recommendation and is therefore a recommendation rationale.) With respect to claim 5, Bean teaches wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts regarding actors and the actions taken by the actors (Bean, paragraph [0058]: “collects information during the building of the container image 230 that corresponds to the executed tasks”; Bean, paragraph [0043]: “provide verifiable proof of executed tasks”; Bean, paragraph [0041]: “Cryptographically signing is a mechanism to express identity”. Applicant identifies the actors as, e.g., “developers, build machines/systems/infrastructure” (spec paragraph [0039]). Bean’s trusted attestor records each TaskRun as it executes (Bean, paragraph [0043]: “watches for TaskRuns, creates a copy of the TaskRuns as they appear, and cryptographically signs them”), where each task “specifies one or more steps that execute container images and each container image performs a specific piece of build work” (Bean, paragraph [0043]), and the signature identifying each task is passed to the attestor as evidence (Bean, paragraph [0042]: “the signatures are passed to trusted attestor 215 as evidence of the build process”). The signed TaskRun records thus identify the build components that performed the work (the actors, i.e., build systems) and the steps they executed (the actions), and are an artifact regarding actors and the actions taken by the actors.)
With respect to claim 10, claim 10 recites limitations similar to claim 1 and is rejected for the same reasons set forth for claim 1. Claim 10 differs only in reciting A computing device comprising: one or more non-transitory machine-readable mediums configured to store instructions; and one or more processors configured to execute the instructions stored on the one or more non-transitory machine-readable mediums, wherein execution of the instructions causes the one or more processors to carry out a process comprising:, which Bean teaches (Bean, paragraph [0023]: “processing device 115 (e.g., processors, central processing units (CPUs)), memory 120”; Bean, paragraph [0079]: “a memory; and a processing device operatively coupled to the memory”; Bean, paragraph [0086]: “a non-transitory computer readable medium, having instructions stored thereon which, when executed by a processing device, cause the processing device to”). Computing device 110 includes processing device 115 and memory 120, and the instructions stored on the non-transitory medium are executed by the processing device to carry out the process
With respect to claim 13, claim 13 recites limitations similar to claim 4 and is rejected for the same reasons set forth for claim 4. (Bean, paragraphs [0037], [0051], [0060]).
With respect to claim 14, claim 14 recites limitations similar to claim 5 and is rejected for the same reasons set forth for claim 5.
With respect to claim 19, claim 19 recites limitations similar to claim 1 and is rejected for the same reasons set forth for claim 1. Claim 19 differs only in reciting a non-transitory machine-readable medium encoding instructions that when executed by one or more processors cause a process to be carried out, the process including:, which Bean teaches (Bean, paragraph [0070]: “a machine-readable storage medium 928, on which is stored one or more sets of supply chain gate release instructions 925”; Bean, paragraph [0086]: “a non-transitory computer readable medium, having instructions stored thereon which, when executed by a processing device, cause the processing device to”).
Claims 2-3, 11-12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bean et al. (US Pub. No. 2024/0168739, hereinafter Bean) in view of Mirantes et al. (US Pub. No. 2021/0232388, hereinafter Mirantes) and further in view of Bellis et al. (US Pub. No. 2020/0401704, hereinafter Bellis). With respect to claim 2, Bean teaches wherein the executing the decision engine includes evaluating [[cyber threat intelligence]] (Bean, paragraph [0036]: “Gate 250 (e.g., an evaluator utility) performs attestation signature verification 255, policy requirements verification 260, and other policy checks 265”, i.e., a decision engine whose execution evaluates inputs in rendering the releasability determination.)
Bean in view of Mirantes is silent to disclose cyber threat intelligence; however, in an analogous art, Bellis teaches cyber threat intelligence (Bellis, paragraph [0036]: “One or more machine learning computers may be used to generate a prediction of whether an exploit will be developed for a particular vulnerability and/or a prediction of whether an exploit to be developed for a particular vulnerability will be used in an attack”; Bellis, paragraph [0041]: “which of the second plurality of vulnerabilities is predicted to have exploits developed for them … and/or which of the second plurality of vulnerabilities is predicted to be attacked”; Bellis, paragraph [0100]: “Score adjustment logic 218 modifies risk scores for software vulnerabilities based on output data 214”; Bellis, paragraph [0101]: “If the exploit is predicted to be used in an attack, the risk score may be increased”; Bellis, paragraph [0047]: “developed exploit feature 118 may indicate whether or not a particular software vulnerability has an exploit that was included in an information security tool, such as METASPLOIT”; Bellis, paragraph [0055]: “the attack feature may indicate whether or not an exploit developed for a particular software vulnerability was used in a successful attack”. Applicant’s specification describes cyber threat intelligence as intelligence regarding weaknesses with respect to the software build and its dependencies, which can include reports of weaponized weaknesses, i.e., weaknesses that have been exploited or attacked (spec paragraph [0044]). Bellis tracks whether each software vulnerability already has an exploit and whether that exploit has been used in a successful attack (i.e., is weaponized), predicts the same for newly published vulnerabilities, and evaluates that intelligence via score adjustment logic 218 to adjust the vulnerabilities’ risk scores; Bellis thus supplies the cyber threat intelligence evaluated by the decision engine of the base combination.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the decision engine of Bean, as modified by Mirantes, to evaluate the cyber threat intelligence of Bellis, in order to account for whether the weaknesses associated with the software build have been or are predicted to be weaponized (exploited or used in an attack) when determining releasability, thereby avoiding release of software exposed to actively-exploited weaknesses and enabling remediation even before exploits are developed (Bellis, paragraph [0007]: “waiting for exploits to be developed and for attacks to occur exposes computing assets to a significant amount of risk”; Bellis, paragraph [0058]). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G).
With respect to claim 3, Bean in view of Mirantes is silent to disclose wherein the cyber threat intelligence is determined using a machine learning (ML) model; however, in an analogous art, Bellis teaches wherein the cyber threat intelligence is determined using a machine learning (ML) model (Bellis, paragraph [0082]: “machine learning is used to generate one or more prediction models that are used to predict whether an exploit will be developed for a particular vulnerability and/or whether an exploit to be developed for a particular vulnerability will be used in an attack”; Bellis, [0085]: “Examples of machine learning algorithms include random forest, decision tree learning, association rule learning, artificial neural network, support vector machines, and/or Bayesian networks”; Bellis, paragraph [0086]: “machine learning computer(s) 200 comprise modeling logic 206 and prediction logic 208”. The cyber threat intelligence credited above — the exploit and attack predictions — is generated by Bellis’s machine learning prediction models; the cyber threat intelligence is therefore determined using a machine learning (ML) model.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to determine the cyber threat intelligence evaluated by the decision engine of Bean, as modified by Mirantes, using the machine learning prediction models of Bellis, in order to identify weaknesses likely to be weaponized before an exploit or attack is observed and to “produce reliable, repeatable decisions and results as well as to uncover hidden insights through learning from historical relationships and trends in the data” (Bellis, paragraph [0084]; see also Bellis, paragraph [0058]). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G). With respect to claim 11, claim 11 recites limitations similar to claim 2 and is rejected for the same reasons set forth for claim 2. (Bean, paragraph [0036]; Bellis, paragraphs [0036], [0041], [0047], [0055], [0100]-[0101]).
With respect to claim 12, claim 12 recites limitations similar to claim 3 and is rejected for the same reasons set forth for claim 3. (Bellis, paragraphs [0082], [0084]-[0086]).
With respect to claim 20, claim 20 recites limitations similar to claim 2 and is rejected for the same reasons set forth for claim 2. (Bean, paragraph [0036]; Bellis, paragraphs [0036], [0041], [0047], [0055], [0100]-[0101]).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bean et al. (US Pub. No. 2024/0168739, hereinafter Bean) in view of Mirantes et al. (US Pub. No. 2021/0232388, hereinafter Mirantes) and further in view of Yu et al. (US Pub. No. 2020/0026512, hereinafter Yu). With respect to claim 6, Bean teaches wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts [[regarding software license risk]] (Bean, paragraph [0034]: “generates an attestation log describing evidence of the build process”; Bean, paragraph [0059]: “generates an attestation log … based on the collected information”. Each item of evidence the attestor records in the attestation log during the build, e.g., the task digests and task signatures (Bean, paragraph [0058]: “collects information during the building of the container image 230 that corresponds to the executed tasks, such as task signatures through annotations or digest information”), is information about the build and therefore an artifact about the software build; applicant likewise describes the provenance bundle as containing “information (e.g., artifacts) about events that occur during building of the software” (spec paragraph [0026])).
Bean in view of Mirantes is silent to disclose regarding software license risk; however, in an analogous art, Yu teaches regarding software license risk (Yu, paragraph [0007]: “matching the detected open-source license with the planning condition to determine a first conflict … and generating a first risk assessment report based on the first conflict”; Yu, paragraph [0033]: “analyze any pre-existing legal risks, generate a risk assessment report”; Yu, paragraph [0058]: “there is an agreement conflict, and the risk level is high”; Yu, paragraph [0064]: “determining a risk level corresponding to the first conflict”. Applicant defines software license risk as license restrictions for a particular dependency that affect the ability to legally use the software (spec paragraph [0030]). Yu detects the open-source licenses governing the software, matches them against the project’s planning conditions and against one another to determine conflicts, assigns a risk level, and generates a risk assessment report; that report is an artifact regarding software license risk.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include, among the artifacts of Bean’s provenance bundle as modified by Mirantes, the software license risk assessment report of Yu, in order to surface license conflicts and pre-existing legal risks presented by the software’s open-source dependencies so that the releasability determination accounts for license and legal risk before the software is released (Yu, paragraphs [0004], [0006]). The report provides “support and reference to the user for better tracking the software development and making a reasonable decision about the open-source software” (Yu, paragraph [0022]). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G).
With respect to claim 15, claim 15 recites limitations similar to claim 6 and is rejected for the same reasons set forth for claim 6. (Bean, paragraphs [0034], [0058]-[0059]; Yu, paragraphs [0007], [0022], [0033], [0058], [0064]).
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bean et al. (US Pub. No. 2024/0168739, hereinafter Bean) in view of Mirantes et al. (US Pub. No. 2021/0232388, hereinafter Mirantes) and further in view of Beard (US Pub. No. 2020/0201620, hereinafter Beard). With respect to claim 7, Bean teaches wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts [[regarding known weaknesses in software dependencies]] (Bean, paragraph [0034]: “generates an attestation log describing evidence of the build process”; Bean, paragraph [0059]: “generates an attestation log … based on the collected information”. Each item of evidence the attestor records in the attestation log during the build, e.g., the task digests and task signatures (Bean, paragraph [0058]: “collects information during the building of the container image 230 that corresponds to the executed tasks, such as task signatures through annotations or digest information”), is information about the build and therefore an artifact about the software build; applicant likewise describes the provenance bundle as containing “information (e.g., artifacts) about events that occur during building of the software” (spec paragraph [0026])).
Bean in view of Mirantes is silent to disclose regarding known weaknesses in software dependencies; however in an analogous art, Beard teaches regarding known weaknesses in software dependencies (Beard, paragraph [0021]: “a list of installed software … at least one library, library version(s)”; Beard, paragraph [0027]: “validate at least one update in the device specific SBOM based on a vulnerability database”; Beard, paragraph [0040]: “The vulnerability database may comprise at least one vulnerability identification … at least one vulnerability score”; Beard, paragraph [0037]: “The SBOM score may be based on a device specific SBOM and/or a vulnerability database”. Beard’s SBOM is a list of the installed software components, including libraries and their versions (i.e., the software dependencies), and Beard validates that SBOM against a vulnerability database comprising vulnerability identifications and scores, producing an SBOM score. Identifying the vulnerabilities of the dependencies in this manner yields an artifact regarding known weaknesses in software dependencies.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include, among the artifacts of Bean’s provenance bundle as modified by Mirantes, an artifact regarding known weaknesses in software dependencies as taught by Beard, in order to flag vulnerable third-party components before release and thereby improve the security and integrity of the released software (Beard, paragraph [0018]: “The software and/or hardware may be validated to provide security to the medical device”; Beard, paragraph [0027]). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G).
With respect to claim 16, claim 16 recites limitations similar to claim 7 and is rejected for the same reasons set forth for claim 7 (Bean, paragraphs [0034], [0058]-[0059]; Beard, paragraphs [0021], [0027], [0037], [0040]).
Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bean et al. (US Pub. No. 2024/0168739, hereinafter Bean) in view of Mirantes et al. (US Pub. No. 2021/0232388, hereinafter Mirantes) and further in view of Rangnau et al. (“Continuous Security Testing: A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines”, hereinafter Rangnau – IDS 10/29/2025).
With respect to claim 8, Bean teaches wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts [[regarding software test results]] (Bean, paragraph [0034]: “generates an attestation log describing evidence of the build process”; Bean, paragraph [0059]: “generates an attestation log … based on the collected information”. Each item of evidence the attestor records in the attestation log during the build, e.g., the task digests and task signatures (Bean, paragraph [0058]: “collects information during the building of the container image 230 that corresponds to the executed tasks, such as task signatures through annotations or digest information”), is information about the build and therefore an artifact about the software build; applicant likewise describes the provenance bundle as containing “information (e.g., artifacts) about events that occur during building of the software” (spec paragraph [0026])).
Bean in view of Mirantes is silent to disclose regarding software test results; however, in an analogous art, Rangnau teaches regarding software test results (Rangnau reports the results of the security tests run in the CI/CD pipeline — Rangnau, section IV-A, Requirement R.7 (“provide clear test results in case of a pipeline failure”) — and exports those results as pipeline artifacts — Rangnau, section IV-B (“exported as GitLab CI artifacts”); see also Rangnau, section IV-C: “The results for every test for each CI job can be downloaded from the GitLab CI interface”. Including such test-results artifacts in the provenance bundle yields an artifact regarding software test results.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include, among the artifacts of Bean’s provenance bundle as modified by Mirantes, an artifact regarding software test results as taught by Rangnau, in order to provide a verifiable, auditable record of the testing performed during the build so that non-compliant builds are caught before release (Rangnau, section IV-A, R.7: “Clear reporting helps developers to quickly locate and fix the issues”). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G). With respect to claim 9, Bean teaches wherein the provenance bundle includes one or more artifacts about the software build, one of the one or more artifacts [[regarding weaknesses in custom software included in the software build]] (Bean, paragraph [0034]: “generates an attestation log describing evidence of the build process”; Bean, paragraph [0059]: “generates an attestation log … based on the collected information”. Each item of evidence the attestor records in the attestation log during the build, e.g., the task digests and task signatures (Bean, paragraph [0058]: “collects information during the building of the container image 230 that corresponds to the executed tasks, such as task signatures through annotations or digest information”), is information about the build and therefore an artifact about the software build; applicant likewise describes the provenance bundle as containing “information (e.g., artifacts) about events that occur during building of the software” (spec paragraph [0026])).
Bean in view of Mirantes is silent to disclose regarding weaknesses in custom software included in the software build; however, in an analogous art, Rangnau teaches regarding weaknesses in custom software included in the software build (Rangnau runs dynamic security tests against each new version of the application built from developers’ commits (Rangnau, section IV-B: “Unit tests are executed following the build of a new version in order to verify its implementation. From R.4 it follows that security tests should be run in addition to this.”; Rangnau, section IV-A, R.4: “Every commit to the remote repository should trigger a pipeline process”), i.e., against newly developed code, which applicant identifies as custom software (spec paragraph [0036]), and reports the weaknesses found — Rangnau, section IV-C (“the active scan detected 15 vulnerabilities”), including a high-risk weakness “vulnerable against a SQLi attack” in the application under test (Rangnau, section IV-C; Table I). Rangnau uses the WebGoat application as the target only because developing a purpose-built vulnerable application was out of scope of the case study (Rangnau, section IV-B: “Since it is out of scope of this study to develop such an application with specific vulnerabilities, OWASP WebGoat was chosen as a target application”); the pipeline itself is directed to testing the application under development. An artifact reporting those findings is an artifact regarding weaknesses in custom software included in the software build.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include, among the artifacts of Bean’s provenance bundle as modified by Mirantes, an artifact regarding weaknesses in custom software included in the software build as taught by Rangnau, in order to detect vulnerabilities in the application’s own code before release and thereby reduce the risk of releasing exploitable software (Rangnau, section V: “The evaluation of the results stops the pipeline and thereby prevent the undesired deployment of security flaws to a production system”). See KSR, 550 U.S. at 418; MPEP § 2143(I)(G).
With respect to claim 17, claim 17 recites limitations similar to claim 8 and is rejected for the same reasons set forth for claim 8. (Bean, paragraphs [0034], [0058]-[0059]; Rangnau, sections IV-A (R.7), IV-B, IV-C).
With respect to claim 18, claim 18 recites limitations similar to claim 9 and is rejected for the same reasons set forth for claim 9. (Bean, paragraphs [0034], [0058]-[0059]; Rangnau, sections IV-A (R.4), IV-B, IV-C, Table I).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kumar (US Pub. No. 2023/0161882) Techniques for dynamically controlling whether a code build of an application finishes to completion or is terminated prior to completion are disclosed. An application is determined to be entering a development state in which a code build of the application is to occur. After the code build for the application has started, the code build is prevented from completing by a scanning tool. While the code build is being prevented from completing, the scanning tool performs a scan of the application. Based on a result of the scan, the code build is terminated prior to completion. (see abstract).
Shih et al. (US Pat. No. 11,238,163) A method for implementing an object based vulnerability model includes identifying each component in an information system and annotating such component in a database; decomposing each component into major functional objects and annotating each object in a database; identifying actions an attacker could take to modify a behavior of the functional objects in the information system and annotating such actions in a database; capturing a trust score and a trustworthiness score for each object and annotating the trust score and the trustworthiness score in the database; assessing each action on the structure, state, and inputs of each functional object to determine if an interaction exists and annotating the interaction existence in the database; and applying preventive and reactive countermeasures accordingly. (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 571-272-6799. 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
