Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
2. Claims 1-20 are pending in Instant Application.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
3. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0265346 issued to Hulick et al. (Hulick) in view US 2024/0152625 issued to Bar et al. (Bar).
As per claim 1, Hulick teaches a system comprising: one or more processors; and one or more memories including instructions that are executable by the one or more processors for causing the one or more processors to perform operations (Hulick: ¶ 0078 - one or more computer processors; one or more computer readable storage media; and program instructions stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors) including: executing a first version of a software program during a time window (Hulick: ¶ 0025 - risk history module 110 may organize the obtained data for one or more software applications into a repository (e.g., database 116). The data may be organized for each application and for each version of an application such that the repository can be queried to determine the number of vulnerabilities in each version of an application, the time to remediate each vulnerability, the number of developers assigned to identifying and/or remediating vulnerabilities for each version); while executing the first version of the software program during the time window, generating a software bill of materials (SBOM) for the software program, wherein the SBOM identifies a dependency relied upon by the first version of the software program during the time window (Hulick: ¶ 0026 - SBOM generation module 112 may generate SBOMS for applications that include metadata describing the risk of the applications. An application may have an SBOM that is generated for each version of the application, and each version's SBOM can include risk metadata that is specific for that version of the application. The risk metadata may include any data obtained by risk history module 110, such as the number of vulnerabilities identified and/or remediated, the time required to remediate each vulnerability, the number of developers assigned to identifying and/or remediating vulnerabilities for that version); determining that the dependency has a vulnerability based on a Common Vulnerabilities and Exposures (CVE) record associated with the dependency (Hulick: ¶ 0021 - teaches the data is obtained from a system or systems that track Common Vulnerabilities and Exposures (CVE), which can include publicly-known information security vulnerabilities and exposures; while ¶ 0035 - teaches each repository server 138A-138N may be associated with a particular entity who investigates and/or reports vulnerabilities (e.g., CVEs ), and may store data that is descriptive of vulnerabilities for various applications and versions thereof in database);
Hulick however does not explicitly teach obtaining an updated version of the dependency that lacks the vulnerability; generating a second version of the software program using the updated version of the dependency to mitigate the vulnerability; and deploying the second version of the software program and shutting down the first version of the software program.
Bar however explicitly teaches obtaining an updated version of the dependency that lacks the vulnerability; generating a second version of the software program using the updated version of the dependency to mitigate the vulnerability; and deploying the second version of the software program and shutting down the first version of the software program (Bar: ¶ 0085 - The SBOM data management and analytics services provided on SBOM server 510 may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions; while ¶ 0007, ¶ 0008 - also teaches conceptual representations of an SBOM and version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hulick in view of Bar to teach obtaining an updated version of the dependency that lacks the vulnerability; generating a second version of the software program using the updated version of the dependency to mitigate the vulnerability; and deploying the second version of the software program and shutting down the first version of the software program. One would be motivated to do so as the SBOM data management and analytics services provided on SBOM server may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions and also the conceptual representations of an SBOM show the version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software) (Bar: ¶ 0007, ¶ 0008, ¶ 0085).
As per claim 2, the modified teaching of Hulick teaches the system of claim 1, wherein the time window is a first time window, the SBOM is a first SBOM, the dependency is a first dependency, the vulnerability is a first vulnerability, the CVE record is a first CVE record, and the operations further comprise: executing the second version of the software program during a second time window that is subsequent to the first time window; while executing the second version of the software program during the second time window, generating a second SBOM for the software program during the second time window, wherein the second SBOM identifies a second dependency relied upon by the second version of the software program during the second time window (Hulick: ¶ 0026, ¶ 0027 - teaches continuous integration/continuous deployment systems can be configured to automatically generate SBOMs during the build or deployment process, and software composition analysis platforms may include features for generating and managing SBOMs. In some embodiments, the SBOMs are developed and thus automatically generated by another computing device (e.g., a developer device rather than risk analysis server 102); in such cases, SBOM generation module 112 may obtain the SBOMs and modify the SBOMs to include the risk metadata in order to generate SBOMs that indicate risk in accordance with the embodiments presented herein); determining that the second dependency has a second vulnerability based on a second CVE record associated with the second dependency, the second CVE record being different from the first CVE record (Hulick: ¶ 0035 - each repository server 138A-138N may be associated with a particular entity who investigates and/or reports vulnerabilities (e.g., CVEs ), and may store data that is descriptive of vulnerabilities for various applications and versions thereof in database);
Hulick however does not explicitly teach obtaining an updated version of the second dependency that lacks the second vulnerability; generating a third version of the software program using the updated version of the second dependency to mitigate the second vulnerability; and deploying the third version of the software program and shutting down the second version of the software program.
Bar however explicitly teaches obtaining an updated version of the second dependency that lacks the second vulnerability; generating a third version of the software program using the updated version of the second dependency to mitigate the second vulnerability; and deploying the third version of the software program and shutting down the second version of the software program (Bar: ¶ 0085 - The SBOM data management and analytics services provided on SBOM server 510 may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions; ¶ 0007, ¶ 0008 - also teaches the conceptual representations of an SBOM show the version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hulick in view of Bar to teach obtaining an updated version of the second dependency that lacks the second vulnerability; generating a third version of the software program using the updated version of the second dependency to mitigate the second vulnerability; and deploying the third version of the software program and shutting down the second version of the software program. One would be motivated to do so as the SBOM data management and analytics services provided on SBOM server may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions and also the conceptual representations of an SBOM show the version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software) (Bar: ¶ 0007, ¶ 0008, ¶ 0085).
As per claim 3, the modified teaching of Hulick teaches the system of claim 2, wherein the second SBOM excludes the first dependency (Bar: ¶ 0052 - an SBOM-reporting application may generate and report, return or output SBOM or SBOM data or regarding accessible dependencies in addition to information regarding currently-loaded dependencies and also one or more computers may include one or more SBOM-reporting applications that perform different functions and may have been written in different software languages, originated from different development platforms, or execute in different runtime environments and operating systems (so second SBOM excludes the first dependency)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hulick in view of Bar to teach wherein the second SBOM excludes the first dependency. One would be motivated to do so as an SBOM-reporting application may generate and report, return or output SBOM or SBOM data or regarding accessible dependencies in addition to information regarding currently-loaded dependencies and also one or more computers may include one or more SBOM-reporting applications that perform different functions and may have been written in different software languages, originated from different development platforms, or execute in different runtime environments and operating systems (so second SBOM excludes the first dependency) (Bar: ¶ 0052).
As per claim 4, the modified teaching of Hulick teaches the system of claim 1, wherein the operations comprise: iteratively and sequentially mitigating vulnerabilities in the software program over a series of time windows by, for each respective time window in the series of time windows: executing the software program; generating a respective SBOM for the software program while the software program is executing, wherein the respective SBOM includes a respective dependency relied upon by the software program during the respective time window (Hulick: ¶ 0026, ¶ 0027 - teaches continuous integration/continuous deployment systems can be configured to automatically generate SBOMs during the build or deployment process, and software composition analysis platforms may include features for generating and managing SBOMs. In some embodiments, the SBOMs are developed and thus automatically generated by another computing device (e.g., a developer device rather than risk analysis server 102); in such cases, SBOM generation module 112 may obtain the SBOMs and modify the SBOMs to include the risk metadata in order to generate SBOMs that indicate risk in accordance with the embodiments presented herein), the respective dependency being different from other dependencies relied upon by the software program during previous time windows in the series of time windows; determining that the respective dependency has a respective vulnerability (Hulick: ¶ 0048 - the SBOM may include a listing of all identified components of the application, and can include risk metadata that is descriptive of any identified vulnerabilities in the application, including previous versions of the application. The risk metadata may also include other extracted data regarding risk, such as the severity of vulnerabilities, time spent remediating vulnerabilities);
Hulick however does not explicitly teach obtaining an updated version of the respective dependency that lacks the respective vulnerability; and mitigating the respective vulnerability by rebuilding the software program using the updated version of the respective dependency.
Bar however explicitly teaches obtaining an updated version of the respective dependency that lacks the respective vulnerability; and mitigating the respective vulnerability by rebuilding the software program using the updated version of the respective dependency (Bar: ¶ 0085 - The SBOM data management and analytics services provided on SBOM server 510 may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions; ¶ 0007, ¶ 0008 - also teaches the conceptual representations of an SBOM show the version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hulick in view of Bar to teach obtaining an updated version of the respective dependency that lacks the respective vulnerability; and mitigating the respective vulnerability by rebuilding the software program using the updated version of the respective dependency. One would be motivated to do so as the SBOM data management and analytics services provided on SBOM server may generate and deliver to users pre-formatted and/or configurable reports. Reports may reflect the current inventory of running applications and their libraries and dependencies currently used. A report could for example show that 80% of a certain application are already updated to the latest version in production, while 20% use older versions and also the conceptual representations of an SBOM show the version of the component (meaning the identifier used by the supplier to specify a change in software from a previously identified version (shutting down previous version of software) (Bar: ¶ 0007, ¶ 0008, ¶ 0085).
As per claim 5, the modified teaching of Hulick teaches the system of claim 1, wherein the SBOM lists a plurality of dependencies relied upon by the software program during the time window, the plurality of dependencies including the dependency with the vulnerability (Hulick: ¶ 0048 - the SBOM may include a listing of all identified components of the application, and can include risk metadata that is descriptive of any identified vulnerabilities in the application, including previous versions of the application. The risk metadata may also include other extracted data regarding risk, such as the severity of vulnerabilities, time spent remediating vulnerabilities).
As per claim 6, the modified teaching of Hulick teaches the system of claim 5, wherein the operations further comprise, during the time window and prior to deploying the second version of the software program: determining vulnerabilities in at least two dependencies of the plurality of dependencies based on CVE records associated with the at least two dependencies; obtaining updated versions of the at least two dependencies that lack the vulnerabilities; and generating the second version of the software program using the updated versions of the at least two dependencies to mitigate the vulnerabilities (Hulick: ¶ 0035 - each repository server 138A-138N may be associated with a particular entity who investigates and/or reports vulnerabilities (e.g., CVEs ), and may store data that is descriptive of vulnerabilities for various applications and versions thereof in database 144. Risk analysis server 102 may access the repository servers 138A-138N to obtain data that is used to assess applications for risk, including CVE data for various versions of applications).
As per claim 7, the modified teaching of Hulick teaches the system of claim 1, wherein the operations comprise determining the updated version of the dependency from the CVE record (Hulick: ¶ 0044 - the versions can be grouped according to major releases (e.g., "2.13.x" and "2.12.x") with specific version numbers 402 and vulnerability counts as shown at 404. This data can be provided by a CVE tracker, and can be obtained for analysis).
As per claim 8, the claim resembles claim 1 and is rejected under the same rationale.
As per claim 9, the claim resembles claim 2 and is rejected under the same rationale.
As per claim 10, the claim resembles claim 3 and is rejected under the same rationale.
As per claim 11, the claim resembles claim 4 and is rejected under the same rationale.
As per claim 12, the claim resembles claim 5 and is rejected under the same rationale.
As per claim 13, the claim resembles claim 6 and is rejected under the same rationale.
As per claim 14, the claim resembles claim 7 and is rejected under the same rationale.
As per claim 15, the claim resembles claim 1 and is rejected under the same rationale while Hulick also teaches a non-transitory computer-readable medium comprising program code that is executable by one or more processors for causing the one or more processors to perform operations (Hulick: ¶ 0078 - one or more computer readable storage media; and program instructions stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors).
As per claim 16, the claim resembles claim 2 and is rejected under the same rationale.
As per claim 17, the modified teaching of Hulick teaches the non-transitory computer-readable medium of claim 15, wherein the operation of determining the dependency relied upon by the first version of the software program during the time window involves: generating a software bill of materials (SBOM) for the software program, wherein the SBOM identifies the dependency relied upon by the first version of the software program during the time window (Hulick: ¶ 0026, ¶ 0027 - teaches continuous integration/continuous deployment systems can be configured to automatically generate SBOMs during the build or deployment process, and software composition analysis platforms may include features for generating and managing SBOMs. In some embodiments, the SBOMs are developed and thus automatically generated by another computing device (e.g., a developer device rather than risk analysis server 102); in such cases, SBOM generation module 112 may obtain the SBOMs and modify the SBOMs to include the risk metadata in order to generate SBOMs that indicate risk in accordance with the embodiments presented herein).
As per claim 18, the claim resembles claim 5 and is rejected under the same rationale.
As per claim 19, the claim resembles claim 4 and is rejected under the same rationale.
As per claim 20, the claim resembles claim 6 and is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SM AZIZUR RAHMAN whose telephone number is (571)270-7360. The examiner can normally be reached on M-F Telework;
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SM A RAHMAN/Primary Examiner, Art Unit 2434