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 03/13/2026 has been entered.
This office Action is in response to the RCE filed on 03/13/2026. As per instant Amendment, Claims 1, 9, and 17 have been amended; Claims 7 and 15 were previously cancelled. Claims 1, 9, and 17 are independent Claims; Claims 1-6, 8-14, and 16-20 have been examined and are pending. This Office Action is made Non-Final.
Response to Arguments
Applicants’ arguments with respect to claims 1-6, 8-14, and 16-20 have been considered but are moot in view of the new ground(s) of rejection.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 8-11, 13, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatt et al. (“Bhatt,” US 20220171856, published on 06/02/2022) in view of Oliphant et al. (“Oliphant,” US 10,021,124 B2, published on 07/10/2018).
Regarding Claim 1;
Bhatt discloses a method for managing software security, the method comprising:
receiving a software supply chain catalog associated with a software product including information of one or more registered software components (par 0036; analyze a manifest [i.e., software supply chain catalog] of the various software container images to assess the software container images; par 0019; the software container image includes one or more particular versions of a Linux software package or that the intended execution environment for the software container image includes one or more particular versions of Linux, and the one or more second criteria includes a requirement that a particular Linux capability, Linux security facility, or Linux rights flag is enabled during runtime of the software container);
initiating a vulnerability scan to the software product based on one or more scan parameters (par 0046; a determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner; par 0048; if the one or more first criteria are met, the container engine instantiates the software container from the software container image with runtime monitoring);
performing the vulnerability scan to the software product using the software supply chain catalog to identify one or more security vulnerabilities using one or more scanners (par 0036; analyze a manifest of the various software container images to assess the software container images; par 0019; software container image includes one or more particular versions of a Linux software package; par 0046; assessing software containers for vulnerabilities. A determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner);
determining a requirement associated with a first identified security vulnerability of the one or more identified security vulnerabilities (par 0041; the runtime monitor only looks to see if the one or more second criteria for a particular vulnerability is met if the static scan results database indicates that the one or more first criteria for the software vulnerability are met);
determining one or more actions corresponding to the one or more identified security vulnerabilities (par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score); and
performing at least one of the one or more actions corresponding to the one or more identified security vulnerabilities (par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score);
wherein the method is performed using one or more processors (par 0106; the computing device architecture used to implement the static scanner and risk assessment engine on a single computing device or on multiple computing devices. The computing device includes processing circuitry operatively connected to memory).
Bhatt discloses determining one or more actions as recited above, but do not explicitly disclose the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action.
However, in an analogous art, Oliphant discloses multi-path remediation system/method that includes:
the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action (Oliphant: Col 4, lines 55-61; upon a determination by security server that a connection attempt or other attack has occurred against a computer that is vulnerable, security server selects one or more remediation techniques from database that remediate the particular vulnerability; Col 13, lines 59-64; product architect can integrate functionalities listed in the previous section to enable the scanner to access the logic engine and platform, and then have the intelligence to determine if the machine has actual vulnerabilities, remediate them, and verify policy compliance; Col 14, lines 61-64; create a change request in the system, specifying what update/patch is applicable to what system or groups of systems by vulnerability. After approval of the request, they may automatically deploy and install the update/patch).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Oliphant with the method/system of Bhatt to include the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action. One would have been motivated to remediates that particular vulnerability. Each remediation technique has a remediation type are selected from the type group consisting of patch, policy setting, and configuration option (Oliphant: abstract).
Regarding Claim 2;
The combination of Bhatt and Oliphant disclose the meth
PNG
media_image1.png
10
4
media_image1.png
Greyscale
od of claim 1,
Bhatt discloses wherein at least one of the one or more identified security vulnerabilities is associated with one of the one or more registered software components (Bhatt: par 0046; assessing software containers for vulnerabilities. A determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner; par 0048; if the one or more first criteria are met, the container engine instantiates the software container from the software container image with runtime monitoring. The runtime monitoring includes determining whether the software container meets the one or more second criteria required for execution of the software vulnerability; par 0049; Based on whether the one or more first criteria and one or more second criteria are met, a risk score is determined that indicates a magnitude of a risk the software vulnerability poses for the software container. A notification of the risk score is provided).
Regarding Claim 3;
The combination of Bhatt and Oliphant disclose the method of claim 1,
Bhatt discloses wherein the one or more scanners include at least one selected from a group consisting of a scanner of a container image, a scanner integrated with an instance of the software product, and a scanner of one or more software dependencies (Bhatt: par 0036; a static scanner is configured to perform static scanning using the static scan rulesets of the first software vulnerability database to determine whether the software container images or their intended execution environment meet the one or more first criteria for any of the software vulnerabilities. The static scanner use filenames, hash checks, and/or signature checks to identify files, for example, and/or may analyze a manifest of the various software container images to assess the software container images; par 0040; the runtime monitor look for things such as network access, specific port access, Linux capabilities, configured security for web applications, etc.; par 0046; a determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner).
Regarding Claim 5;
The combination of Bhatt and Oliphant disclose the method of claim 1,
Bhatt discloses wherein the requirement is a first requirement, wherein the method further comprises: determining a second requirement associated with a second identified security vulnerability of the one or more identified security vulnerabilities (Bhatt: par 0040; the runtime monitor is configured to monitor runtime behavior of the software containers to determine if any of the software containers meet the one or more second criteria for any of the software vulnerabilities. The runtime monitor look for things such as network access, specific port access, Linux capabilities, configured security for web applications, etc.; par 0041; the runtime monitor only looks to see if the one or more second criteria for a particular vulnerability is met if the static scan results database indicates that the one or more first criteria for the software vulnerability are met; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score); wherein the second requirement is different from the first requirement (Bhatt: par 0019; the one or more first criteria includes a requirement that the software container image includes one or more particular versions of a Linux software package or that the intended execution environment for the software container image includes one or more particular versions of Linux, and the one or more second criteria includes a requirement that a particular Linux capability, Linux security facility, or Linux rights flag is enabled during runtime of the software container).
Regarding Claim 8;
The combination of Bhatt and Oliphant disclose the method of claim 1,
Bhatt discloses receiving information associated with a second version of the software product; adding a first scanner to the one or more scanners based at least in part on the second version of the software product (Bhatt: par 0046; assessing software containers for vulnerabilities. A determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner; par 0048; if the one or more first criteria are met, the container engine instantiates the software container from the software container image with runtime monitoring. The runtime monitoring includes determining whether the software container meets the one or more second criteria required for execution of the software vulnerability; par 0049; Based on whether the one or more first criteria and one or more second criteria are met, a risk score is determined that indicates a magnitude of a risk the software vulnerability poses for the software container. A notification of the risk score is provided).
Regarding Claim 9;
This Claim recites a system that perform the same steps as method of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 10;
This Claim recites a system that perform the same steps as method of Claim 2, and has limitations that are similar to Claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 11;
This Claim recites a system that perform the same steps as method of Claim 3, and has limitations that are similar to Claim 3, thus are rejected with the same rationale applied against claim 3.
Regarding Claim 13;
This Claim recites a system that perform the same steps as method of Claim 5, and has limitations that are similar to Claim 5, thus are rejected with the same rationale applied against claim 5.
Regarding Claim 16;
This Claim recites a system that perform the same steps as method of Claim 8, and has limitations that are similar to Claim 8, thus are rejected with the same rationale applied against claim 8.
Regarding Claim 17;
Bhatt discloses a method for managing software security, the method comprising (abstract: runtime monitoring, a risk score that indicates a magnitude of a risk the software vulnerability poses for the software container is determined, and a notification of the risk score is provided):
receiving a trigger to initiate a vulnerability scan (par 0040; The runtime monitor is configured to monitor runtime behavior of the software containers to determine if any of the software containers meet the one or more second criteria for any of the software vulnerabilities. The runtime monitor look for things such as network access, specific port access, Linux capabilities, configured security for web applications, etc.);
accessing a software supply chain catalog associated with a software product including information of one or more registered software components (par 0036; analyze a manifest [i.e., software supply chain catalog] of the various software container images to assess the software container images; par 0019; the software container image includes one or more particular versions of a Linux software package or that the intended execution environment for the software container image includes one or more particular versions of Linux, and the one or more second criteria includes a requirement that a particular Linux capability, Linux security facility, or Linux rights flag is enabled during runtime of the software container);
initiating the vulnerability scan to the software product based on one or more scan parameters (par 0046; a determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner; par 0048; if the one or more first criteria are met, the container engine instantiates the software container from the software container image with runtime monitoring);
performing the vulnerability scan to the software product using the software supply chain catalog to identify one or more security vulnerabilities using one or more scanners (par 0036; analyze a manifest of the various software container images to assess the software container images; par 0019; software container image includes one or more particular versions of a Linux software package; par 0046; assessing software containers for vulnerabilities. A determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner);
determining a requirement associated with a first identified security vulnerability of the one or more identified security vulnerabilities (par 0041; the runtime monitor only looks to see if the one or more second criteria for a particular vulnerability is met if the static scan results database indicates that the one or more first criteria for the software vulnerability are met);
determining one or more actions corresponding to the one or more identified security vulnerabilities (par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score); and
performing at least one of the one or more actions corresponding to the one or more identified security vulnerabilities (par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score);
wherein the method is performed using one or more processors (par 0106; the computing device architecture used to implement the static scanner and risk assessment engine on a single computing device or on multiple computing devices. The computing device includes processing circuitry operatively connected to memory).
Bhatt discloses determining one or more actions as recited above, but do not explicitly disclose the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action.
However, in an analogous art, Oliphant discloses multi-path remediation system/method that includes:
the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action (Oliphant: Col 4, lines 55-61; upon a determination by security server that a connection attempt or other attack has occurred against a computer that is vulnerable, security server selects one or more remediation techniques from database that remediate the particular vulnerability; Col 13, lines 59-64; product architect can integrate functionalities listed in the previous section to enable the scanner to access the logic engine and platform, and then have the intelligence to determine if the machine has actual vulnerabilities, remediate them, and verify policy compliance; Col 14, lines 61-64; create a change request in the system, specifying what update/patch is applicable to what system or groups of systems by vulnerability. After approval of the request, they may automatically deploy and install the update/patch).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Oliphant with the method/system of Bhatt to include the one or more actions including at least one selected from a group consisting of a recall action, a suppression action, a patch action, and an upgrade action. One would have been motivated to remediates that particular vulnerability. Each remediation technique has a remediation type are selected from the type group consisting of patch, policy setting, and configuration option (Oliphant: abstract).
Regarding Claim 18;
This Claim recites a method that perform the same steps as method of Claim 2, and has limitations that are similar to Claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 19;
The combination of Bhatt and Oliphant disclose the method of claim 17,
Bhatt discloses wherein the trigger includes at least one selected from a group consisting of a new version of the software product becoming available, a new deployment of the software product, a new security vulnerability being discovered, and a time associated with periodic scanning (Bhatt: par 0036; a static scanner is configured to perform static scanning using the static scan rulesets of the first software vulnerability database to determine whether the software container images or their intended execution environment meet the one or more first criteria for any of the software vulnerabilities. The static scanner use filenames, hash checks, and/or signature checks to identify files, for example, and/or may analyze a manifest of the various software container images to assess the software container images; par 0040; the runtime monitor look for things such as network access, specific port access, Linux capabilities, configured security for web applications, etc.; par 0046; a determination is made of whether a software container image or its intended execution environment meets one or more first criteria required for execution of a software vulnerability based on a static scan of the software container image by static scanner).
Claims 4, 12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatt et al. (US 20220171856) in view of Oliphant et al. (“Oliphant,” US 10,021,124 B2, published on 07/10/2018), and further in view Bennett et al. (“Bennett,” US 20100275263, published on 10/28/2010).
Regarding Claim 4;
The combination of Bhatt and Oliphant disclose the method of claim 1, further comprising:
Bhatt discloses looking up an assessment score associated with each security vulnerability of the one or more identified security vulnerabilities (Bhatt: par 0041; the runtime monitor only looks to see if the one or more second criteria for a particular vulnerability is met if the static scan results database indicates that the one or more first criteria for the software vulnerability are met; par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score); wherein the determining a requirement associated with at least one security vulnerability of the one or more identified security vulnerabilities comprises determining the requirement based in part on an assessment associated with the first identified security vulnerability (Bhatt: par 0041; the runtime monitor only looks to see if the one or more second criteria for a particular vulnerability is met if the static scan results database indicates that the one or more first criteria for the software vulnerability are met; par 0042; if the one or more first criteria and one or more second criteria for a particular software vulnerability are met by a software container and its corresponding container image, the risk score assessment engine determines a score that indicates a magnitude of a risk the software vulnerability poses for the software container, and provides a risk score notification based on the risk score).
Bhatt discloses determining the requirement based in part on an assessment associated with the first identified security vulnerability as recited above, but do not explicitly disclose requirement based in part on an assessment score.
However, in an analogous art, Bennett discloses security management software system/method that includes:
requirement based in part on an assessment score (Bennett: par 0125; The what-if scenario can include any number of assets and any number of parameters to be inputted, edited, altered, modified, or changed by the user. Some examples of parameters than can be edited include maturity scores or assessment scores, likelihoods, impacts, classifications, costs, vulnerabilities, risks, regulatory requirements, threats, activities, and the like. The parameters can include information captured by any module of the system, information from sources external to the system, or both).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Bennett with the method/system of Bhatt to include requirement based in part on an assessment score. One would have been motivated to create a what-if scenario by changing one or more baseline security measurements. The system generates interactive, animated graphs that compare the baseline security measurements against the what-if scenario (Bennett: abstract).
Regarding Claim 12;
This Claim recites a system that perform the same steps as method of Claim 4, and has limitations that are similar to Claim 4, thus are rejected with the same rationale applied against claim 4.
Regarding Claim 20;
This Claim recites a method that perform the same steps as method of Claim 4, and has limitations that are similar to Claim 4, thus are rejected with the same rationale applied against claim 4.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatt et al. (US 20220171856) in view of Oliphant et al. (“Oliphant,” US 10,021,124 B2, published on 07/10/2018), and further in view Baker et al. (“Baker,” US 10,735,451, published on 08/04/2020).
Regarding Claim 6;
The combination of Bhatt and Oliphant disclose the method of claim 5,
Bhatt discloses wherein the second requirement is different from the first requirement (Bhatt: par 0019; the one or more first criteria includes a requirement that the software container image includes one or more particular versions of a Linux software package or that the intended execution environment for the software container image includes one or more particular versions of Linux, and the one or more second criteria includes a requirement that a particular Linux capability, Linux security facility, or Linux rights flag is enabled during runtime of the software container).
Bhatt discloses wherein the second requirement is different from the first requirement as recited above, but do not explicitly disclose different from the first requirement in a required time for an action to be taken.
However, in an analogous art, Baker discloses maintaining IT infrastructure security system/method that includes:
different from the first requirement in a required time for an action to be taken (Baker: Col 7, lines 41-53; regulation prescribe a 60 day time period from a particular triggering of a first vulnerability type to remediation, and a PCI regulation may prescribe a 30 day time period for remediation for a second vulnerability type. Thus, if a single system is found to have both types of vulnerabilities, a 30 day maximum remediation timeline may be prescribed such that the earlier deadline is assigned first and the enterprise's IT group that handles the second type of vulnerability may be assigned the remediation instead of or before a different team that is assigned responsibility for the first type of vulnerability).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Baker with the method/system of Bhatt to include different from the first requirement in a required time for an action to be taken. One would have been motivated to detect vulnerabilities, and generating list of remediation tasks for the detected vulnerabilities (Baker: abstract).
Regarding Claim 14;
This Claim recites a system that perform the same steps as method of Claim 6, and has limitations that are similar to Claim 6, thus are rejected with the same rationale applied against claim 6.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAO WANG whose telephone number is (313)446-6644. The examiner can normally be reached on Monday-Friday 7:30-4:30PM EST.
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, Luu Pham can be reached on (571)270-5002. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/C.W./Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights