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 .
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.
Claims 1, 3, 7-8, 10, 14-15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Schutt et al. (US 2023/0208880) and further in view of Kairali et al. (US 2024/0126530 A1).
As per claim 1, Schutt et al. teaches the invention as claimed including, “A method comprising:
in response to a first version of an application being certified as compliant with a set of policies, generating a first software bill of materials (SBOM) associated with the first version of the application;
monitoring the first version of the application during execution for updates to the first version of the application;
in response to determining that the first version of the application has been updated to a second version of the application, generating a second SBOM corresponding to the second version of the application;
comparing, by a processing device, the first SBOM and the second SBOM to determine whether the second version of the application is compliant with the set of policies; and”
Schutt et al. teaches automatically analyzing software packages to apply security policies, to identify the degree of different between compared packages, and to perform other operations. A first software bill of materials is processed to extract a plurality of components of the software package, wherein the first software bill of materials indicates a first hierarchy of components based on relationships between components. The first hierarchy is compared to a second hierarchy, the second hierarchy corresponding to a second software bill of materials to determine a degree of difference between the first and the second hierarchy. The degree of difference is compared to one or more threshold values. A security policy is applied with respect to the software package according to a comparison of the degree of difference (0010). Also see 0002 Two SBOMs for two versions of the same software package, such as during a software update (where one version is of a previous release) (0014). The magnitude of difference between software packages can be ascertained, which can be used to enforce fully-automated security policies that selectively grant or deny software packages access to systems (0017). Once a software package is configured as trustworthy (certified), the software package may be permitted to execute in a computing environment, may be included in a software update, may be approved to access a computer network (0018). Also see 0025-0027 and 0032. An updated software package can be compared to a previous version to determine the degree of difference between two versions. If the degree of difference is below a threshold value, then the updated version may be executed, installed, permitted to access a network and the like (0028).
“in response to determining that the second version of the application is not compliant with the set of policies, performing one or more mitigation actions.
The degree of difference is compared to one or more threshold values. A security policy is applied with respect to the software package according to a comparison of the degree of difference (0010). The magnitude of difference between software packages can be ascertained, which can be used to enforce fully-automated security policies that selectively grant or deny software packages access to systems (0017). Also see 0032 and 0052.
Schutt et al. teaches if a software package is confirmed as trustworthy, the software package may be permitted to execute in a computing environment (0018). Schutt et al. further teaches storage that includes SBOMs (0033). However, Schutt et al. does not explicitly appear to teach, “in response to a first version of an application being certified as compliant with a set of policies, generating a first software bill of materials (SBOM) associated with the first version of the application;”
Kairali et al. teaches the system can monitor the environment and identify the software programs currently running within the environment as well as the components of the software programs. An agent may scan the software programs and/or files to identify the components required for each of the software programs. The agent feeds the information into a security and compliance center (SCC). The SCC constructs (generates) a software bill of materials (SBOM) for each of the software programs in the environment (0071).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Schutt et al. with Kairali et al. since both teach the use of a SBOM for an application. Schutt et al. teaches if a software package is confirmed as trustworthy, the software package may be permitted to execute in a computing environment (0018). Therefore, any software executing in an environment has been certified as compliant with policies. Karirali et al. teaches monitoring an environment as to identify component required for each of the software programs (0071). Therefore, if a new component is added and executed in the environment it must be trusted as taught by Schutt et al. and the agent of Kairali et al. would be scanning the environment to find the trusted software and it would identify the component of the software program and construct/generate a software bill of material (SBOM). This would allow Schutt et al. to monitor all software and updates executing in a environment in order to generate SBOMs and make sure they are trusted and meet policies.
Schutt et al. teaches analyzing software packages to identify whether any updates or changes to the packages are substantial (0013). Analysis is performed in response to the update package becoming available (0032). However, Schutt et al. does not explicitly appear to teach, “monitoring the first version of the application during execution for updates to the first version of the application;” and
“in response to determining that the first version of the application has been updated to a second version of the application, generating a second SBOM corresponding to the second version of the application;
Kairali et al. teaches the system can monitor the environment and identify the software programs currently running within the environment as well as the components of the software programs. An agent may scan the software programs and/or files to identify the components required for each of the software programs. The agent feeds the information into a security and compliance center (SCC). The SCC constructs (generates) a software bill of materials (SBOM) for each of the software programs in the environment (0071). Kairali et al. teaches the SCC may collect data from the agent, each time an update or change is detected within the environment, the agent may collect data of the update and send it to the SCC. A differential may be a message which identifies just the components of the software program that were updated and not all components. Any changes in the SBOM will be sent to the SCC (0078).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Schutt et al. with Kairali et al. because both teach the use of SBOMs different to determine if a software application is following policies. Schutt et al. teaches analyzing software packages to see if a update is substantial and that the analysis in response to the update package becoming available (0013 and 0032). The hierarchy components in SMOBs are compared to determine a difference and use to enforce security polices. Kairali et al. teaches, monitoring an environment to identify software components and build a SMOB for a software program (0071) along with when an update is detected, collecting data of the update and sending it to the SCC (0078). Therefore, Kairali et al. will allow Schutte et al. to monitor for an update and collect data regarding the update and send it to a SCC and generate a SMOB for the update. This will improve Schutt et al. by not only determine if a update package being available, by also monitoring for a update and change to a software application and generating a SMOB for the updated application and use it to determine compliance. Kairali et al. further teaches if a software program is not fully in compliance the central service, it may identify a software update and install the software update to the software programming running in the environment (0071), therefore allowing Schutt et al. to fix security policies of a newly updated software program running in an environment.
As per claim 3 (Amended), Schutt et al. further teaches, “The method of claim 1, wherein the one or more mitigation actions are performed based on:
an importance score of the application; an
importance score of one or more components of the second version of the application that are determined to not comply with the set of policies based on the comparison; and
changes to a dependency structure of a component of the second version of the application relative to the first version of the application.”
Each identified difference between hierarchy 200 and hierarchy 250 may contribute to an overall score that represents the degree of difference between the hierarchies. In some embodiments, different types of differences can be weighted; for example, the removal of component in hierarchy may be weighted more or less heavily than the change in dependencies of components (0040). Weights may be applied to different types of differences so that insertions, deletions, substitutions, changes in dependencies, and/or an other differences can be weighted differently. Known trusted components can be omitted while known bad components can be weighted or flagged to cause the comparison to indicate the presence of the bad components (0049-0052).
As per claim 7 (Amended), Schutt et al. further teaches, “The method of claim1, wherein each of the first and second SBOM comprises a list of components and dependencies used in a respective version of the application.”
The first software bill of materials indicates a first hierarchy of components based on relationships between components(0010).
As per claims 8, 10, 14-15 and 17, they contain similar limitations to claim 1-3 and 7. Therefore, they are rejected for the same reasons.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Schutt et al. (US 2023/0208880) and Kairali et al. (US 2024/0126530 A1) as applied to claims 1, 8 and 15 above, further in view of Shi (US 2023/0017989 A1).
As per claim 4 (Amended), Schutt et al. teaches, if a modified software package is substantially different from the previously-approved version the modified software may be denied access by security policy module, flagged for manual inspection, and the like. However, Schutt et al. does not explicitly appear to teach, “The method of claim 1, wherein a first mitigation action of the one or more mitigation actions comprises:
migrating the second version of the application to a container; and
determining if the second version of the application can execute in a manner that is sufficiently compatible with the set of policies, wherein the first version of the application executes while it is determined if the second version of the application can execute in a manner that is sufficiently compatible with the set of policies.”
Shi et al. teaches intercepting a software update package and installing the software update in a software update sandbox instead of the intended recipient. Once the software update is installed, all behaviors of the software update are monitored and analyzed to verify that no malicious behavior of the component in the software update package (0009). The examiner states that it would be inherent that the first version to be updated would still be running, since the update package has been intercepted and has not updated the first version yet.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Schutt et al. with Shi et al. because both teach ways of verifying compliance of an update. Schutt et al. teaches dues to a substantial degree of difference the software package is run with a limited set of permissions. Shi et al. teaches installing an update in a sandbox to monitor and analyze its behavior. This will allow Shi et al. to verify any malicious behavior prior to apply the update to production. The use of the known technique taught in Shi et al. will allow Schutt et al. to improve its update verification in a similar was as Shi et al.
As per claims 11 and 18, they contain similar limitations to claim 4. Therefore, they are rejected for similar reasons.
Claims 5-6, 12-13 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Schutt et al. (US 2023/0208880) and Kairali et al. (US 2024/0126530 A1) as applied to claims 1, 8, and 15 above and further in view of Lum et al. (US 11,170,105 B2).
As per claim 5 (Amended), Schutt et al. further teaches, “The method of claim 1, wherein a second mitigation action of the one or more mitigation actions comprises:
executing the second version of the application with a limited set of permissions and access rights; and”
If the degree of difference is substantial, then the software package under scrutiny may be denied access to a system, or may be provided with a limited set of permissions (0052).
However, Schutt et al. does not explicitly appear to teach, “while the second version of the application executes with the limited set of permissions and access rights, determining if the second version of the application can execute in a manner that is sufficiently compatible with the set of policies.”
Lum et al. teaches, installing a update and running the software. If execution of the software update leads to anomalous behavior that does not match the information in the behavior profile, then the host terminates the software update and performs a rollback (column 9, lines 40-56).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Schutt et al. with Lum et al. because both teach ways of verifying compliance of an update. Schutt et al. teaches dues to a substantial degree of difference the software package is run with a limited set of permissions. Lum et al. teaches monitoring the execution of a installed update to verify if it executes in a behavior that matches a behavior profile. Combining prior art elements according to known methods to yield predictable results of allowing Schutt et al. to make sure its software package running with a limited set of permissions is functioning correctly.
As per claim 6, Lum et al. further teaches, “The method of claim 5, wherein in response to determining that the second version of the application cannot execute in a manner that is sufficiently compatible with the set of policies based on the second mitigation action, performing a third mitigation action comprising: stopping execution of the second version of the application; and rolling the application back to the first version of the application.”
Lum et al. teaches, installing a update and running the software. If execution of the software update leads to anomalous behavior that does not match the information in the behavior profile, then the host terminates the software update and performs a rollback (column 9, lines 40-56).
As per claim 12-13 and 19-20, they contain similar limitations to claims 5-6 and are therefore rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 7/23/2026 have been fully considered but they are not persuasive.
Regarding Rejections under 35 U.S.C. 101
The rejections have been overcome by the amendments.
Regarding Rejections under 35 U.S.C. 102
Applicant argues “Schutt is silent on “monitoring the first version of the application during execution for updates to the first version of the application”. Examiner states that this argument is moot due to it being a newly added limitation. Please see the above rejection for this new limitation.
Applicant further argues, “In addition, Schutt is also silent on "comparing, by a processing device, the first SBOM and the second SBOM to determine whether the second version of the application is compliant with the set of policies," as recited in claim 1. "Schutt discloses that a "first software bill of materials for a software package is processed to extract a plurality of components of the software package, wherein the first software bill of materials indicates a first hierarchy of components based on relationships between components. The first hierarchy is compared to a second hierarchy, the second hierarchy corresponding to a second software bill of materials, to determine a degree of difference between the first hierarchy and the second hierarchy." Schutt, paragraph [0010]. Schutt discloses comparing the first hierarchy and the second hierarchy to determine a degree of difference between the first hierarchy and the second hierarchy, not "comparing, by a processing device, the first SBOM and the second SBOM to determine whether the second version of the application is compliant with the set of policies," as recited in claim 1. Applicant respectfully submits that comparing hierarchies indicated by an SBOM is not the same as "comparing, by a processing device, the first SBOM and the second SBOM," as recited in claim 1.
In addition, Schutt discloses that the "first hierarchy is compared to a second hierarchy, the second hierarchy corresponding to a second software bill of materials, to determine a degree of difference between the first hierarchy and the second hierarchy. The degree of difference is compared to one or more threshold values. A security policy is applied with respect to the software package according to a comparison of the degree of difference to the one or more threshold values." Id. Schutt discloses comparing the first hierarchy and the second hierarchy to determine a degree of difference between the first hierarchy and the second hierarchy, wherein a security policy is applied with respect to the software package according to a comparison of the degree of difference to one or more threshold values. However, comparing a difference between hierarchies and implementing a security policy based on a comparison of the difference to threshold values is not the same as determining "whether the second version of the application is compliant with the set of policies," as recited in claim 1. Therefore, Schutt is silent on the above-recited feature of claim 1.”
The examiner disagrees. First as claimed “comparing, by a processing device, the first SBOM and the second SBOM to determine whether the second version of the application is compliant with the set of policies”. This claimed limitation does not state how the comparison is performed or even how it is used to determine whether the second version of the application is compliant with the set of policies. As the applicant stated above and in the prior rejection each software bill of materials indicates a hierarchy of components and the hierarchy of component of each version is compared with one another. The examiner states that since the SBOM indicates the hierarchy of component, the hierarchy of components is part of the SBOM and comparing them is equivalent to comparing the SBOM. This is done to find different/changed components within the SBOM. See (0010 and 0017). This meets the claimed limitation under its broadest reasonable interpretation. Further paragraph 0010 states that a security policy is applied with respect to the software package to a comparison of the degree of difference. The magnitude of difference between software packages can be ascertained, which can be used to enforce fully-automated security policies that selectively grand or deny software packages access to the system (0017). Therefore, based on this comparison security policies can be checked to make sure the software is compliant. For these reasons the current rejection stands.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
