DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/17/2026 has been entered.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Plunk (US 2024/0330474 A1).
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment to claim 8 is considered to have overcome the applied rejection. As such, the rejection has been withdrawn,
Applicant’s amendment to claim 9 is considered to have overcome the applied rejection. However, the amended claim is now considered indefinite regarding “deny or allow the container download request based on the determined risk” as below. As such, claim 9 remains rejected under 35 USC 112(b).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a container downloader configured to download the container, a container executor configured to execute the test run, a container monitor configured to monitor the components during the test run, and an SBOM generator configured to generate the active SBOM and the potential SBOM” in claims 14-15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For instance, FIG. 2 and the corresponding descriptions of elements 202, 203, 204, and 205.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 9 is 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 9 recites “deny or allow the container download request based on the determined risk,” which renders it indefinite because parent claim 1 also recites “allowing or denying the container download request to the machine based on the access determination.” Thus, there are two separate determinations for allowing or denying the container download request, and it is not clear whether they override each other or are meant in combination. Additionally, the two limitations use “deny or allow” and “allowing or denying,” where it is not clear if these refer to the same allow/deny action or two separate actions.
Claim 20 is 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 20 recites “wherein the container is considered exposed to high-risk when any components listed in the active SBOM are vulnerable, and wherein risk from vulnerable components listed only in the potential SBOM is considered lower than risk from vulnerable components listed in the active SBOM,” which renders it indefinite because it is not clear whether the consideration is part of the claim scope. For instance, the entity performing the consideration is not specified, and the “is considered” may refer to general knowledge beyond the scope of the claim. Additionally, “is considered” is in past tense and may refer to a consideration that took place before the scope of the claim.
Claim 21 is 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 21 recites “wherein the SBOM proxy location intercepts, downloads, executes, monitors, and generates the active SBOM,” which renders it indefinite because the steps of intercepting, downloading, executing, and monitoring performed by the SBOM proxy (as recited in parent claim 1) are not modifying the active SBOM. Intercepting the active SBOM, downloading the active SBOM, executing the active SBOM, and monitoring the active SBOM are not steps taken by the SBOM proxy.
For the purpose of applying prior art, this claim has been interpreted such that the SBOM proxy performs the intercepting, downloading, executing, and monitoring steps recited in the parent 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.
Claim(s) 1, 8-9, 11-14, and 16-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Plunk (US 2024/0330474 A1) in view of Bar (US 2024/0152625 A1).
Regarding claim 1, Plunk discloses: A method, comprising:
intercepting a container download request from a machine via a web proxy (proxy server 120 in, e.g., FIG. 1 of Plunk);
Refer to at least [0017]-[0021] and [0030] of Plunk with respect to the proxy server intercepting a request for a software dependency installation by a client to a software dependency server, where the software dependency can be for OCI/Docker images.
downloading the container at a Software Bill of Materials (SBOM) proxy location outside of the machine;
Refer to at least [0025] and [0030] of Plunk with respect to the proxy server obtaining the installation package and parsing the image; e.g., “when the proxy server 120 receives a software dependency installation package in the form of an OCI/Docker image request.”
generating, at the SBOM proxy location, an [SBOM];
Refer to at least [0025] and [0030] of Plunk with respect to the proxy server scanning the obtained software dependency installation / image to obtain a software bill of materials; e.g., “the proxy server 120 scans them by parsing the image that the client is requesting, breaking the image down into a software bill of materials.”
transmitting the [SBOM] to a management server (e.g., vulnerability database server(s) in FIG. 1 and [0023] of Plunk);
Refer to at least [0023], [0030], and [0049] of Plunk with respect to the proxy server querying the vulnerability database; e.g., “proxy server 120 then queries the vulnerability management database 140 for each dependency within the image.”
receiving an access determination from the management server based on the [SBOM}; and
Refer to at least [0023]-[0024], and [0049] of Plunk with respect to the proxy server obtaining risk score information in response to the query.
allowing or denying the container download request to the machine based on the access determination, wherein the container is prevented from reaching the machine until the access determination is received.
Refer to at least the abstract, [0019], [0024], [0028]-[0029], and [0052] of Plunk with respect to the proxy server enforcing policies based on the risk score information to either grant or deny the download, where the client is prevented from doing so until the enforcement action.
Plunk does not disclose the specifics of the proxy server SBOM generation including: executing, at the SBOM proxy location, a test run of the container for a period of time to identify components that are read or executed versus components that are installed but not read or executed during the test run; the generated SBOM further comprising an active SBOM comprising packages whose components were actually read or executed during the test run and a potential SBOM comprising packages installed in the container but whose components were not read or executed during the test run / the active SBOM and the potential SBOM. However, Plunk in view of Bar discloses: executing, at the SBOM proxy (the proxy server in Plunk already performs the SBOM scanning) location, a test run of the container for a period of time to identify components that are read or executed versus components that are installed but not read or executed during the test run;
Refer to at least [0012], [0028], and [0041] of Bar with respect to runtime execution and dynamic SBOM; at least [0034]-[0038] of Bar with respect to hidden dependencies (e.g., a specific library routine is never actually loaded).
the generated SBOM further comprising an active SBOM comprising packages whose components were actually read or executed during the test run and a potential SBOM comprising packages installed in the container but whose components were not read or executed during the test run / the active SBOM and the potential SBOM.
Refer to at last 450 in FIG. 4, [0036]-[0037], and [0040] of Bar with respect to generating SBOM information including loaded/active dependencies and static SBOM dependencies; to at least 440 in FIG. 4, [0028]-[0029], and [0040] of Bar with reporting to an SBOM server; [0082]-[0086] of Bar with respect to data management and analytics at the SBOM server.
The teachings of Plunk and Bar both concern scanning potentially exploitable software dependencies and generating a software bill of materials for a server, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Plunk’s proxy server SBOM generation to further implement obtaining dynamic SBOM data and determining loaded, accessible, and hidden dependencies for at least the reasons discussed in [0015]-[0016] and [0035] of Bar (e.g., empowering focusing remedial efforts on components that are actually used).
Regarding claim 8, it is rejected for substantially the same reasons as claims 1 and 2 above (i.e., Plunk concerning intercepting download requests).
Regarding claim 9, Plunk-Bar discloses: The method of claim 1, wherein the management server is configured to in response to receiving the active SBOM and the potential SBOM: retrieve vulnerability information for the packages in the active SBOM and the potential SBOM; determine risk based on a first risk assessment of vulnerabilities of the active SBOM and a second risk assessment of the potential SBOM; and deny or allow the container download request based on the determined risk.
Refer to at least [0023] and [0049]-[0051] of Plunk with respect to risk score analysis from the queried database information; [0050]-[0052] of Plunk with respect to policy enforcement based on a risk threshold determination.
Refer to at least [0082]-[0086] of Bar with respect to SBOM data analytics at the SBOM server based on the received data.
This claim would have been obvious for substantially the same reasons as claim 1 above (i.e., obviousness rationale for implementing and analyzing a more comprehensive SBOM).
Regarding claim 11, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations to Bar and dynamic SBOM).
Regarding independent claim 12, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding independent claim 13, it is substantially similar to elements of independent claim 1 and dependent claims 9 and 20. As such, it is rejected under the same analysis.
Regarding claim 14, Plunk-Bar discloses: The method of claim 1, wherein the SBOM proxy location comprises an SBOM proxy that includes a container downloader configured to download the container, a container executor configured to execute the test run, a container monitor configured to monitor the components during the test run, and an SBOM generator configured to generate the active SBOM and the potential SBOM.
Refer to at least FIG. 1 and [0030] of Plunk with respect to the proxy server, which is configured to intercept, download, and generate a software bill of materials for a download request.
Refer to at least [0012], [0028], and [0041] of Bar with respect to runtime execution and dynamic SBOM; at last 450 in FIG. 4, [0036]-[0037], and [0040] of Bar with respect to generating SBOM information including loaded/active dependencies and static SBOM dependencies.
This claim would have been obvious for substantially the same reasons as claim 1 above (i.e., obviousness rationale for modifying the proxy server of Plunk to perform more comprehensive scanning).
Regarding claim 16, Plunk-Bar discloses: The method of claim 1, wherein the access determination is based on matching the active SBOM and the potential SBOM with a vulnerability database at the management server.
Refer to at least [0023] and [0049]-[0051] of Plunk with respect to risk score analysis from the queried database information.
Refer to at least [0082]-[0086] of Bar with respect to SBOM data analytics at the SBOM server based on the received data.
This claim would have been obvious for substantially the same reasons as claim 1 above (i.e., obviousness rationale for implementing and analyzing a more comprehensive SBOM).
Regarding claim 17, it is rejected for substantially the same reason as claim 16 above.
Regarding claim 18, Plunk-Bar discloses: The method of claim 17, wherein the container download request is denied when the integrated risk exceeds a threshold.
Refer to at least [0050]-[0052] of Plunk with respect to policy enforcement based on a risk threshold determination.
Regarding claim 19, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations to Plunk—e.g., the abstract and [0020] of Plunk).
Regarding claim 20, Plunk-Bar discloses: The method of claim 1, wherein the container is considered exposed to high-risk when any components listed in the active SBOM are vulnerable, and wherein risk from vulnerable components listed only in the potential SBOM is considered lower than risk from vulnerable components listed in the active SBOM.
Refer to at least [0035] of Bar with respect to components that are actually used being considered more necessary to address since they are more risk to leave without remediation.
This claim would have been obvious for substantially the same reasons as claim 1 above (i.e., obviousness rationale for implementing and analyzing a more comprehensive SBOM).
Regarding claim 21, it is rejected for substantially the same reasons as claim 1 above (e.g., FIG. 1 of Plunk concerning the proxy server, client device, vulnerability database, and software dependency server).
Claim(s) 3-6, 10, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Plunk-Bar as applied to claims 1, 8-9, 11-14, and 16-21 above, and further in view of Pagnozzi (US 11,507,672 B1).
Regarding claim 3, Plunk-Bar does not specify: wherein generating the active SBOM comprises: for each of the components that are read or executed during the test run, determining if a file path of the each of the components is included in a package manager; and for a determination that the file path is included, including packages in the file path in the active SBOM. However, Plunk-Bar in view of Pagnozzi discloses: wherein generating the active SBOM comprises: for each of the components that are read or executed during the test run, determining if a file path of the each of the components is included in a package manager; and for a determination that the file path is included, including packages in the file path in the active SBOM.
Refer to at least Col. 6, Ll. 43-65 and Col. 10, Ll. 25-48 of Pagnozzi with respect to context metadata including file paths in mapping data used for identifying dependencies; to at least Col. 10, Ll. 29-36 of Pagnozzi with respect to context metadata at any level of granularity of asset management.
The teachings of Pagnozzi likewise concern analyzing applications for potential security problems (e.g., vulnerabilities), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Plunk-Bar to further implement additional ways of identifying dependencies because all of the claimed elements were known in the prior art (e.g., ways of identifying dependencies as in FIG. 1 of Bar) and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions (adding additional checks), and the combination would have yielded predictable results to one of ordinary skill in the art at the time (identifying dependencies via the additional checks).
Regarding claim 4, Plunk-Bar-Pagnozzi discloses: The method of claim 3, , wherein generating the active SBOM further comprises: upon determining that the file path is not included in the package manager, checking a metafile of the container to obtain a description that points to the packages associated with the each of the components, and including the packages associated with the each of monitored components found from the description.
Refer to at least [0038] of Bar with respect to SBOM metadata (e.g., the static SBOM) having dependency information.
This claim would have been obvious for substantially the same reasons as claim 1 above.
Regarding claim 5, it is rejected for substantially the same reasons as claim 4 above (i.e., [0038] of Bar).
Regarding claim 6, Plunk-Bar-Pagnozzi discloses: The method of claim 3, wherein generating the active SBOM further comprises: upon determining that the file path is not included in the package manager, checking a file path of the each of the component to find the packages associated with the each of monitored component; and including the found packages in the generated packages.
Refer to at least Col. 5, Ll. 63-Col. 6, Ll. 1, Col. 7, Ll. 2-8, and Col. 10, Ll. 25-28 of Pagnozzi with respect to using either existing SBOM data or system call argument data to identify dependencies.
This claim would have been obvious for substantially the same reasons as claim 3 above.
Regarding claim 10, Plunk-Bar-Pagnozzi discloses: The method of claim 1, wherein the management server is configured to: obtain updated vulnerability information for the packages in the active SBOM and the potential SBOM;
Refer to at least the abstract of Pagnozzi with respect to obtaining updated vulnerability information in real time based on continued monitoring.
select ones of the packages to monitor based on the updated vulnerability information;
Refer to at least the abstract and Col. 11, Ll. 14-59 of Pagnozzi with respect to prioritizing vulnerabilities.
and read usage status of the monitored packages from logs in a target database for selected components, the logs in the target database provided by the machine during execution of the container.
Refer to at least Col. 13, Ll. 3-50 of Pagnozzi with respect to a GUI and recording the updated vulnerabilities for a user to, e.g., select mitigation actions.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Plunk-Bar to further implement an interface for receiving, logging, and responding to updated vulnerability information because it allows for real-time responses to vulnerabilities as they are detected and reported, thereby increasing security from zero days and other extremely critical vulnerabilities (i.e., there is less time for vulnerabilities to be exploited because they can be addressed more immediately by an analyst).
Regarding claim 15, it is rejected for substantially the same reasons as claim 3 above.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Plunk-Bar as applied to claims 1, 8-9, 11-14, and 16-21 above, and further in view of Desai (US 2024/0289264 A1).
Plunk-Bar does not specify: determining conditions for the test run, the determining the conditions comprising: executing the container without any options; for the execution of the container without any options having no errors, returning the conditions as executing the container without any options; for the execution of the container without any options failing due to errors: generating dummy options for the container based on analysis of the errors; reexecuting the container with the dummy options; reiterating the generating of the dummy options and the reexecution of the container with the dummy options until the container executes with the dummy options without any errors; and returning the dummy options as the conditions for the test run of the container. However, Plunk-Bar in view of Desai discloses: determining conditions for the test run, the determining the conditions comprising: executing the container without any options;
Refer to at least 806-814 in FIG. 8 and [0107]-[0110] of Desai with respect to running test cases for a mock server configured to imitate any number of different microservices and/or other resources.
for the execution of the container without any options having no errors, returning the conditions as executing the container without any options;
Refer to at least [0108] and [0111] of Desai with respect to either error-free test runs and revising test cases to test new test cases.
for the execution of the container without any options failing due to errors: generating dummy options for the container based on analysis of the errors; reexecuting the container with the dummy options; reiterating the generating of the dummy options and the reexecution of the container with the dummy options until the container executes with the dummy options without any errors; and returning the dummy options as the conditions for the test run of the container.
Refer to at least 816-824 in FIG. 8 and [0111]-[0115] of Desai with respect to revising test cases and additional testing as necessary to address the emergence of new errors. Component testing for an individual microservice may be revised and updated as necessary or useful to facilitate proper function of the microservice in an enterprise application.
The teachings of Desai likewise concern testing containers and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Plunk-Bar to further implement iterative testing and test case generation for at least the purpose of making sure the dynamic SBOM properly uncovers hidden and runtime dependencies (i.e., that the execution proceeds correctly), where many multiple applications may need to be tested (e.g., [0088] of Desai).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights