DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s arguments and amendment dated March 2, 2026. Claims 1, 3, 11, and 13 are currently amended and claims 1, 3-11, and 13-20 remain pending in the application and have been fully considered by Examiner.
In view of the amendments, the 35 USC 112(a) rejections of claims 1-20 are withdrawn.
In view of the amendments, the 35 USC 112(d) rejections of claims 2 and 12 are withdrawn.
In view of the amendments, the objection to claim 11 is withdrawn.
Applicant's arguments with respect to the prior art rejections have been considered but are moot and/or not persuasive, as detailed below in the Prior Art Argument - Rejections section.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Claims 6-7 and 16-17 are 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.
With respect to claim 6, line 2 recites “configuration details of a production environment.” It is unclear if this means “a production environment”, as recited on lines 4-5 of claim 1, “configuration details of the production environment”, as recited on line 11 of claim 1, “the configuration details”, as recited on lines 12-13 of claim 1, and/or “the production environment”, as recited on lines 8-9 and 13-14 of claim 1, which renders the scope of the claim indefinite. For purposes of compact prosecution only, and consistent with Applicant’s specification1, Examiner has interpreted claim 6 as reciting “the configuration details of the production environment.”
With respect to claim 16, line 2 recites “configuration details of a production environment.” It is unclear if this means “a production environment,” as recited on lines 3-4 of claim 11, “configuration details of the production environment”, as recited on line 6 of claim 11, “the configuration details”, as recited on lines 7-8 of claim 11, and/or “the production environment”, as recited on lines 8-9 of claim 11, which renders the scope of the claim indefinite. For purposes of compact prosecution only, and consistent with Applicant’s specification2, Examiner has interpreted claim 16 as reciting “the configuration details of the production environment.”
With respect to claims 7 and 17, each inherits the 35 USC 112(b) deficiency of its respective parent claim (see the rejections of claims 6 and 7 above). Furthermore, to the extent that claims 7 and 17 also recite “the production environment,” this is indefinite because it is unclear whether this is the same as “a production environment,” as recited in claims 6 and 16 respectively or “a production environment,” as recited in claims 1 and 11 respectively. Similarly, “the configuration details” is also indefinite because it is unclear whether this is the same as “configuration details” as recited in claims 6 and 16 respectively or “configuration details” as recited in claims 1 and 11 respectively (see the 35 USC 112(b) rejections of claims 6 and 16 above regarding the indefiniteness of “configuration details of a production environment” in claims 6 and 16).
As noted above, Examiner has interpreted claims 6 and 16 consistent with Applicant’ specification to mean “the configuration details of the production environment”, which renders the scope of claims 6-7 and 16-17 definite for purposes of compact prosecution only.
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.
Claims 1, 3-4, 6, and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Chawla et al. (US 20100082316, hereinafter Chawla), in view of Talmor et al. (US 9553845, hereinafter Talmor), Chewe, “Hybrid Cloud Infrastructure Security: Security Automation Approaches for Hybrid IT” (hereinafter Chewe), and Musani et al. (US 20180113728, hereinafter Musani).
With respect to claim 1, Chawla discloses An apparatus (e.g., Figs. 2-3 and associated text, e.g., [0007], Embodiments of the present invention are directed to a … system … to facilitate testing policy changes associated with a production network.) comprising:
a processor (e.g., Fig. 2 and associated text, e.g., [0024], the computing device 200 includes a central processing unit (CPU) 202.);
a memory coupled with the processor (e.g., Figs. 1-3 and associated text, e.g., [0026] Storage 208 can include such technologies as a floppy drive, hard drive, tape drive, Flash drive, optical drive, read only memory (ROM), random access memory (RAM), and the like.), the memory storing instructions for validating network security policy updates prior to deploying the updates to a production environment (e.g., Figs. 1-3 and associated text, e.g., [0020], network virtualization and testing environment (hereinafter "environment") to test policy changes prior to implementation of the policies in a production network … Policies … can include security policies; [0026], Applications 210, such as the environment 100, can be resident in the storage 208.), the instructions executable by the processor to cause the apparatus to:
i) identify a security policy update from a (e.g., Figs. 1, 3, and 7 along with associated text, e.g., [0040], desired policy changes are identified (step 700); [0042], the policy change can be to the customer security policy that would be implemented in the security appliance.), the identified security policy update being a candidate for deployment to the production environment having a plurality of attributes (e.g., Figs. 1, 5, and 7 and associated text, e.g., [0043], If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750); [0031], The virtual network can be formed by virtualization of the physical elements in the gateway 400. Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications … network performance and test data.);
ii) identify the identified security policy update (e.g., [0040], desired policy changes are identified (step 700); [0042], the policy change can be to the customer security policy.) and configuration details of the production environment (e.g., Figs. 1 and 4-7 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications.);
iii) generate a test environment based onand the configuration details (e.g., Figs. 4-5 and associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications [configuration details]; [0033], develop a virtual representation of the production network such that inputs to the virtual network [test environment] are processed by virtual elements (e.g., software models) that provide a virtual model of the production network (step 520). In the virtual network, software modules replace physical network elements of the production network. … The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.), the test environment corresponding to the production environment that is associated with the security policy update (e.g., Figs. 4-5 and associated text, e.g., [0007], testing policy changes associated with a production network; [0025], deploying policy changes in a virtualized network [test environment] to test the policy changes prior to deployment in a production network [the production environment that is associated with the security policy update] modeled by the virtualized network; [0033], In the virtual network [test environment], software modules replace physical network elements of the production network. … The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.);
iv) following deployment of the identified security policy update to the test environment (e.g., Fig. 7 and associated text, e.g., [0042], Desired changes to the current customer policy set can be deployed in the virtual network [test environment]. For example, the policy change can be to the customer security policy that would be implemented in the security appliance; [0043], Desired policy changes are deployed in the virtual network (step 725).), perform a validation to check for security exceptions or availability exceptions using the test environment (e.g., Fig. 7 and associated text, e.g., [0030], security appliance 410b is a firewall that applies security policies … For example, the security appliance 410b can control the exclusion or inclusion of incoming and outgoing information; [0043], verify the policy changes (step 740) … If the testing produces unexplained results or unexpected behavior [check for security exception] (step 745), the process repeats from step 725.); and
v) validation results based on a result of the check (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750). If the testing produces unexplained results or unexpected behavior (step 745), the process repeats from step 725.).
Although Chawla discloses validating network security policy updates and validation results (see above), it does not appear to disclose the following, which is taught in analogous art, Talmor: incrementally (e.g., Figs. 3, particularly the depicted loop, and fig. 5 along with associated text, col. 5:57-59, the staged firewall policy is a new policy and/or a modified version of the enforced firewall policy to be deployed; col. 7:37-38, In step 308 … determines whether the staged firewall policy is valid; col. 8:23-24, repeat steps 302-308 in an attempt to validate the modified staged firewall policy.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Chawla with the invention of Talmor, such that policy updates are validated incrementally, so that “firewall administrators can more effectively validate and test firewall policies to mitigate disruption in user experience and more quickly debug user issues,” as suggested by Talmor (see col. 10:43-46).
Chawla does not appear to disclose the following, which is taught in analogous are Chewe: security as code repository (e.g., p. 23, Fig. 14 and § 3.3 Security Architecture with Security as Code (SaC); p. 43, Figure 31 and last para., The security definition of an environment generally includes … security policies etcetera. What is required is a code description of where and what is the desired security state … This information is scriptable in code and can then be stored into a version control system.) … defined by an infrastructure as code repository (e.g., p., 20, last para., Applying security as code is efficient when applied on infrastructure described in code; p. 31, IaC should be used in network construction (artifacts, secrets, and configuration). They should be saved in source-code repositories; p. 32, Figure 31, Step 2 Describe Infrastructure as Code; p. 44, Fig. 4 and last para., test environment is created automatically using IaC such as Terraform or Cloud Formation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the technique of Chewe, such that SaC and IaC are used, because “Implementing security as code can [sic] is one of the best approaches for an enterprise scale deployment security orchestration,” and “applying security as code is efficient when applied on infrastructure described in code,” as suggested by Chewe (see p. 23, § 3.3 Security Architecture with Security as Code (SaC); see p. 20, last para.).
Although Chawla discloses the identified security policy update, the production environment having a plurality of attributes, and generating a test environment (see above), it does not appear to disclose the following, which is taught in analogous art, Musani: attributes of the plurality of attributes that correspond to (e.g., Figs. 1 and 3 and associated text, e.g., [0037], perform an inventory-downsize operation (313) based on the system inventory [plurality of attributes] collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322 [identifying attributes]. For example … the upgrade simulator 112 may determine that only the OS and virtualization software applications may be related [identifying attributes of the plurality of attributes that correspond to] to a …upgrade.) … the identified attributes (e.g., Figs. 1 and 3-4 and associated text, e.g., [0024], construct the simulated system 130 based on the downsized inventory [generate a test environment based on the identified attributes].) … a subset of (e.g., Figs. 1 and 3-4 and associated text, e.g., [0050], configure a simulated system having a downsized inventory … the downsized inventory may include a subset of the production system's hardware configuration, software configuration; [0037], the upgrade simulator 112 may perform an inventory-downsize operation (313) based on the system inventory collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322. For example … the upgrade simulator 112 may determine that only the OS and virtualization software applications may be related to a …upgrade; see also [0039].).
Although Chawla discloses validation results (see above), it does not appear to disclose the following, which is further taught in Musani: output (e.g., Figs. 1 and 3-4 along with associated text, e.g., [0056], generate upgrade reports, and inform the administrator.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Musani, such that (1) a virtual test environment simulates only a minimum subset of a production environment related to an update being validated and (2) results are reported to an administrator, because it would provide a more efficient use of resources than simply mirroring the entire production environment, which would be needlessly wasteful, and it would allow a human administrator to use their experience and judgment to determine what action to take in response to the validation results.
With respect to claim 3, Musani further teaches wherein the identified attributes are identified from the plurality of attributes (e.g., Figs. 1 and 3 and associated text, e.g., [0037], perform an inventory-downsize operation (313) based on the system inventory [plurality of attributes] collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322 [identified attributes].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Musani for the same reasons set forth above.
With respect to claim 4, Chawla in view of Talmor, Chewe, and Musani, as applied to claim 1 above, discloses wherein the instructions further cause the apparatus to … the steps i) through v) (see the rejection of claim 1 above) and Talmor further teaches repeat … for a next security policy update (e.g., Figs. 3, particularly the depicted loop, and fig. 5 along with associated text, col. 5:57-59, the staged firewall policy is a new policy and/or a modified version of the enforced firewall policy to be deployed; col. 7:37-38, In step 308 … determines whether the staged firewall policy is valid; col. 8:8-24, In step 312 … modifies the staged firewall policy … Additionally, a new staged firewall policy can also be provided … subsequent to modifying the staged firewall policy … repeat steps 302-308 in an attempt to validate the modified staged firewall policy.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Chawla with the inventions of Talmor, Chewe, and Musani for the same reasons set forth above with respect to claim 1 and also because “Over time, there is generally a need to update or modify a deployed firewall policy,” and thus future policy updates will require validation (see Talmor at col. 1:36-37.).
With respect to claim 6, Chawla also discloses wherein the instructions further cause the apparatus to identify configuration details of a production environment (please note the 35 USC 112(b) rejection and interpretation above; e.g., Figs. 1-3 and 5 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications.) and Chewe further teaches using the infrastructure as code repository (e.g., p., 20, last para., Applying security as code is efficient when applied on infrastructure described in code; p. 31, IaC should be used in network construction (artifacts, secrets, and configuration). They should be saved in source-code repositories; p. 44, Fig. 4 and last para., test environment is created automatically using IaC such as Terraform or Cloud Formation.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Chewe for the same reason set forth above.
With respect to claim 8, Chawla also discloses wherein the instructions further cause the apparatus to: deploy the security policy update to the test environment (e.g., Fig. 7 and associated text, e.g., [0042], Desired changes to the current customer policy set can be deployed in the virtual network. For example, the policy change can be to the customer security policy that would be implemented in the security appliance; [0043], Desired policy changes are deployed in the virtual network (step 725).).
With respect to claim 9, Chawla also discloses wherein the instructions further cause the apparatus to determine whether to deploy the security policy update to the production environment based on results of the check (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750).).
With respect to claim 10, Chawla also discloses wherein the security policy update is deployed (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750).) and Chewe further teaches using a continuous deployment (CD) pipeline (e.g., Fig. 30 and associated text on p. 42, e.g., Figure 30 illustrates a model infrastructure orchestration that can be adapted for delivering security as code across infrastructure elements in an enterprise environment using common DevOps tools such as Visual studio Code, it and CI/CD pipelines; Fig. 34 and text on p. 46, Security as Code therefore also becomes a continuous deliverable process which can be aided by DevOps automation workflows for security compliance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Chewe for the same reason set forth above.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Talmor, Chewe, and Musani, as applied to claim 1 above, and further in view of Scheib et al. (US 20160359697, hereinafter Scheib).
With respect to claim 5, Chawla also discloses wherein the test environment includes one or more having configuration details that correspond to configuration details of one or more corresponding of the production environment (e.g., Figs. 1 and 4-5 along with associated text, e.g., [0025], deploying policy changes in a virtualized network [test environment] to test the policy changes; [0033], The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.).
Although Chawla discloses a test environment having configuration details that correspond to configuration details of a production environment (see above), it does not appear to disclose the following, which is taught in analogous art, Scheib: functional domains … functional domains (e.g., Fig. 1 and associated text, e.g., [0022], Within each context 106 are objects called endpoint groups (EPGs) [functional domains] … The EPGs 108 can be a collection of similar endpoints representing an application tier or set of services; [0023], The EPGs 108 are collections of one or more endpoints that provide a logical grouping for objects that require similar policy; [0112], the network may apply … changes to EPGs to a simulated network environment that mirrors the actual network.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Scheib, such that a simulated test environment and a production environment includes EPGs, because “The EPGs 108 can act as a single policy enforcement point for a group of network elements. This can simplify configuration of the policies 110 and ensure their consistency,” as suggested by Scheib (see [0024]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Talmor, Chewe, and Musani, as applied to claim 6 above, and further in view of Albano et al. (US 20130325433, hereinafter Albano).
With respect to claim 7, Chawla also discloses wherein the configuration details are physical information about the production environment (e.g., Figs. 1-3 and 5 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications.).
Although Chawla discloses the configuration details and physical information about the production environment (see above), it does not appear to disclose the following, which is taught in analogous art, Albano: based on a repository containing (e.g., Figs. 3-5 and associated text, e.g., [0058], an associated database 410 which stores data about the managed infrastructure; [0030], an automated discovery run against the real managed infrastructure (servers, networking, storage, etc), and the discovered data is stored in a database, where most other components use this data; [0012], populates the infrastructure management software with metadata from an infrastructure database sufficient to allow the infrastructure management software to simulate the infrastructure.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Albano, such that configuration information details are populated from a database storing physical information about a production environment in order to construct a simulated test environment, because “The data population helps to simulate the managed infrastructure for IaaS software, thereby resulting in the following: (i) eliminating the need and cost of investment required for managed infrastructure; (ii) eliminating the time to do a setup for managed infrastructure; (iii) lowering runtime costs; and (iv) helping run tests for end-to-end integration,” as suggested by Albano (see [0059]).
Claims 11, 13, 16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Chewe and Musani.
With respect to claim 11, Chawla discloses A method (e.g., [0007], Embodiments of the present invention are directed to a method … to facilitate testing policy changes associated with a production network.), comprising:
i) identifying a security policy update from a (e.g., Figs. 1, 3, and 7 along with associated text, e.g., [0028], databases 360 can store information, such as desired policy changes; [0040], desired policy changes are identified (step 700); [0042], the policy change can be to the customer security policy that would be implemented in the security appliance.), the identified security policy update being a candidate for deployment to a production environment having a plurality of attributes (e.g., Figs. 1, 5, and 7 and associated text, e.g., [0043], If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750); [0031], The virtual network can be formed by virtualization of the physical elements in the gateway 400. Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications … network performance and test data.);
ii) identifying the identified security policy update (e.g., [0040], desired policy changes are identified (step 700); [0042], the policy change can be to the customer security policy.) and configuration details of the production environment (e.g., Figs. 1 and 4-7 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications.);
iii) generating a test environment based onand the configuration details (e.g., Figs. 4-5 and associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications [configuration details]; [0033], develop a virtual representation of the production network such that inputs to the virtual network [test environment] are processed by virtual elements (e.g., software models) that provide a virtual model of the production network (step 520). In the virtual network, software modules replace physical network elements of the production network. … The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.), the test environment corresponding to the production environment that is associated with the security policy update (e.g., Figs. 4-5 and associated text, e.g., [0007], testing policy changes associated with a production network; [0025], deploying policy changes in a virtualized network [test environment] to test the policy changes prior to deployment in a production network [the production environment that is associated with the security policy update] modeled by the virtualized network; [0033], In the virtual network [test environment], software modules replace physical network elements of the production network. … The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.);
iv) following deployment of the identified security policy update to the test environment (e.g., Fig. 7 and associated text, e.g., [0042], Desired changes to the current customer policy set can be deployed in the virtual network [test environment]. For example, the policy change can be to the customer security policy that would be implemented in the security appliance; [0043], Desired policy changes are deployed in the virtual network (step 725).), performing a validation to check for security exceptions or availability exceptions using the test environment (e.g., Fig. 7 and associated text, e.g., [0030], security appliance 410b is a firewall that applies security policies … For example, the security appliance 410b can control the exclusion or inclusion of incoming and outgoing information; [0043], verify the policy changes (step 740) … If the testing produces unexplained results or unexpected behavior [check for security exception] (step 745), the process repeats from step 725.); and
vi) validation results based on a result of the check (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750). If the testing produces unexplained results or unexpected behavior (step 745), the process repeats from step 725.).
Chawla as modified does not appear to disclose the following, which is taught in analogous are Chewe: security as code repository (e.g., p. 23, Fig. 14 and § 3.3 Security Architecture with Security as Code (SaC); p. 43, Figure 31 and last para., The security definition of an environment generally includes … security policies etcetera. What is required is a code description of where and what is the desired security state … This information is scriptable in code and can then be stored into a version control system.) … defined by an infrastructure as code repository (e.g., p., 20, last para., Applying security as code is efficient when applied on infrastructure described in code; p. 31, IaC should be used in network construction (artifacts, secrets, and configuration). They should be saved in source-code repositories; p. 32, Figure 31, Step 2 Describe Infrastructure as Code; p. 44, Fig. 4 and last para., test environment is created automatically using IaC such as Terraform or Cloud Formation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Chawla with the invention of Chewe, such that SaC and IaC are used, because “Implementing security as code can is one of the best approaches for an enterprise scale deployment security orchestration,” and “applying security as code is efficient when applied on infrastructure described in code,” as suggested by Chewe (see p. 23, § 3.3 Security Architecture with Security as Code (SaC); see p. 20, last para.).
Although Chawla discloses the identified security policy update, the production environment having a plurality of attributes, and generating a test environment (see above), it does not appear to disclose the following, which is taught in analogous art, Musani: attributes of the plurality of attributes that correspond to (e.g., Figs. 1 and 3 and associated text, e.g., [0037], perform an inventory-downsize operation (313) based on the system inventory [plurality of attributes] collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322 [identifying attributes]. For example … the upgrade simulator 112 may determine that only the OS and virtualization software applications may be related [identifying attributes of the plurality of attributes that correspond to] to a …upgrade.) … the identified attributes (e.g., Figs. 1 and 3-4 and associated text, e.g., [0024], construct the simulated system 130 based on the downsized inventory [generate a test environment based on the identified attributes].) … a subset of (e.g., Figs. 1 and 3-4 and associated text, e.g., [0050], configure a simulated system having a downsized inventory … the downsized inventory may include a subset of the production system's hardware configuration, software configuration; [0037], the upgrade simulator 112 may perform an inventory-downsize operation (313) based on the system inventory collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322. For example … the upgrade simulator 112 may determine that only the OS and virtualization software applications may be related to a …upgrade; see also [0039].).
Although Chawla discloses validation results (see above), it does not appear to disclose the following, which is further taught in Musani: outputting (e.g., Figs. 1 and 3-4 along with associated text, e.g., [0056], generate upgrade reports, and inform the administrator.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Musani, such that (1) a virtual test environment simulates only a minimum subset of a production environment related to an update being validated and (2) results are reported to an administrator, because it would provide a more efficient use of resources than simply mirroring the entire production environment, which would be needlessly wasteful, and it would allow a human administrator to use their experience and judgment to determine what action to take in response to the validation results.
With respect to claim 13, Musani further teaches wherein the identified attributes are identified from the plurality of attributes (e.g., Figs. 1 and 3 and associated text, e.g., [0037], perform an inventory-downsize operation (313) based on the system inventory [plurality of attributes] collected from the production system 120; [0038] the upgrade simulator 112 may determine a minimum set of OS and software applications for the downsized inventory 322 [identified attributes].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Musani for the same reasons set forth above.
With respect to claim 16, Chawla also discloses identifying configuration details of a production environment (please note the 35 USC 112(b) rejection and interpretation above; e.g., Figs. 1-3 and 5 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications … software (S/W) specifications.) and Chewe further teaches using the infrastructure as code repository (e.g., p., 20, last para., Applying security as code is efficient when applied on infrastructure described in code; p. 31, IaC should be used in network construction (artifacts, secrets, and configuration). They should be saved in source-code repositories; p. 44, Fig. 4 and last para., test environment is created automatically using IaC such as Terraform or Cloud Formation.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Chewe for the same reason set forth above.
With respect to claim 18, Chawla also discloses deploying the security policy update to the test environment (e.g., Fig. 7 and associated text, e.g., [0042], Desired changes to the current customer policy set can be deployed in the virtual network. For example, the policy change can be to the customer security policy that would be implemented in the security appliance; [0043], Desired policy changes are deployed in the virtual network (step 725).).
With respect to claim 19, Chawla also discloses determining whether to deploy the security policy update to the production environment based on results of the check (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750).).
With respect to claim 20, Chawla also discloses wherein the security policy update is deployed (e.g., Fig. 7 and associated text, e.g., [0043], verify the policy changes (step 740) … If the changed policy set produces the expected results and behavior (step 745), the policy changes can be deployed in the production system (step 750).) and Chewe further teaches using a continuous deployment (CD) pipeline (e.g., Fig. 30 and associated text on p. 42, e.g., Figure 30 illustrates a model infrastructure orchestration that can be adapted for delivering security as code across infrastructure elements in an enterprise environment using common DevOps tools such as Visual studio Code, it and CI/CD pipelines; Fig. 34 and text on p. 46, Security as Code therefore also becomes a continuous deliverable process which can be aided by DevOps automation workflows for security compliance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Chewe for the same reason set forth above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Chewe and Musani, as applied to claim 11 above, and further in view of Talmor.
With respect to claim 14, Chawla in view Chewe and Musani, as applied to claim 1 above, discloses the steps i) through v) (see the rejections of claims 1 and 11 above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Chawla with the inventions of Chewe and Musani for the same reason set forth above.
Chawla in view of Chewe and Musani does not appear to disclose the following, which is taught in analogous art, Talmor: repeating … for a next security policy update (e.g., Figs. 3, particularly the depicted loop, and fig. 5 along with associated text, col. 5:57-59, the staged firewall policy is a new policy and/or a modified version of the enforced firewall policy to be deployed; col. 7:37-38, In step 308 … determines whether the staged firewall policy is valid; col. 8:8-24, In step 312 … modifies the staged firewall policy … Additionally, a new staged firewall policy can also be provided … subsequent to modifying the staged firewall policy … repeat steps 302-308 in an attempt to validate the modified staged firewall policy.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Talmor, such that the process for validating a policy update is repeated for additional policy updates, so that “firewall administrators can more effectively validate and test firewall policies to mitigate disruption in user experience and more quickly debug user issues,” as suggested by Talmor (see col. 10:43-46) and also because “Over time, there is generally a need to update or modify a deployed firewall policy,” and thus future policy updates will require validation (see Talmor at col. 1:36-37).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Chewe and Musani, as applied to claim 11 above, and further in view of Scheib.
With respect to claim 15, Chawla also discloses wherein the test environment includes one or more having configuration details that correspond to configuration details of one or more corresponding of the production environment (e.g., Figs. 1 and 4-5 along with associated text, e.g., [0025], deploying policy changes in a virtualized network [test environment] to test the policy changes; [0033], The virtual network can be used to accurately simulate the production network and can precisely clone a logical functionality of the production network.).
Although Chawla discloses a test environment having configuration details that correspond to configuration details of a production environment (see above), it does not appear to disclose the following, which is taught in analogous art, Scheib: functional domains … functional domains (e.g., Fig. 1 and associated text, e.g., [0022], Within each context 106 are objects called endpoint groups (EPGs) [functional domains] … The EPGs 108 can be a collection of similar endpoints representing an application tier or set of services; [0023], The EPGs 108 are collections of one or more endpoints that provide a logical grouping for objects that require similar policy; [0112], the network may apply … changes to EPGs to a simulated network environment that mirrors the actual network.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Scheib, such that a simulated test environment and a production environment includes EPGs, because “The EPGs 108 can act as a single policy enforcement point for a group of network elements. This can simplify configuration of the policies 110 and ensure their consistency,” as suggested by Scheib (see [0024]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Chawla in view of Chewe and Musani, as applied to claim 16 above, and further in view of Albano.
With respect to claim 17, Chawla also discloses wherein the configuration details are physical information about the production environment (e.g., Figs. 1-3 and 5 along with associated text, e.g., [0031], Information about the network elements of the production network can be gathered (step 500). Such information can include hardware (H/W) specifications.).
Although Chawla discloses the configuration details and physical information about the production environment (see above), it does not appear to disclose the following, which is taught in analogous art, Albano: based on a repository containing (e.g., Figs. 3-5 and associated text, e.g., [0058], an associated database 410 which stores data about the managed infrastructure; [0030], an automated discovery run against the real managed infrastructure (servers, networking, storage, etc), and the discovered data is stored in a database, where most other components use this data; [0012], populates the infrastructure management software with metadata from an infrastructure database sufficient to allow the infrastructure management software to simulate the infrastructure.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chawla with the invention of Albano, such that configuration information details are populated from a database storing physical information about a production environment in order to construct a simulated test environment, because “The data population helps to simulate the managed infrastructure for IaaS software, thereby resulting in the following: (i) eliminating the need and cost of investment required for managed infrastructure; (ii) eliminating the time to do a setup for managed infrastructure; (iii) lowering runtime costs; and (iv) helping run tests for end-to-end integration,” as suggested by Albano (see [0059]).
Prior Art Arguments – Rejections
Applicant’s arguments with respect to the prior art rejections have been fully considered by Examiner, but they are moot and/or not persuasive, as follows:
With respect to claim 1, Applicant asserts that “The applied references fail to disclose and would not have rendered obvious at least ‘ii) identify attributes of the plurality of attributes that correspond to the identified security policy update and configuration details of the production environment; iii) generate a test environment based on the identified attributes and the configuration details, the test environment corresponding to a subset of the production environment that is associated with the security policy update’” because “there is nothing in Chawla to disclose or otherwise suggest that this virtual network is ‘a subset of the production environment that is associated with the security policy update’” and “the remaining references appear to be silent with respect to these features”3 (emphasis added). While this is a newly added limitation necessitating a new ground of rejection, Examiner nonetheless respectfully disagrees with Applicant because the previously cited Chawla and Musani references, in combination, disclose “the test environment corresponding to a subset of the production environment that is associated with the security policy update”.
Specifically, and as can be seen in detail in the Claim Rejections - 35 USC § 103 section above, Chawla discloses testing security policy changes associated with a production network in a virtual network that simulates the production network4, i.e., “the test environment corresponding tothe production environment, this is taught by Musani. Specifically, Musani teaches generating a simulated system using virtual components corresponding to only the minimum subset of the production system's configuration that is related to the upgrade being evaluated5, i.e., “corresponding to a subset of the production environment”, as claimed. Thus, Chawla and Musani, in combination, disclose “the test environment corresponding to a subset of the production environment that is associated with the security policy update”. Applicant’s argument is therefore unpersuasive.
With respect to all other claims, Applicant references the argument made with respect to claim 16, which is unpersuasive for the reasons set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Akasaka et al. “Reproducible Software Vulnerability Testing with IaC” teaches using IaC to automate the process of provisioning environments.
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 STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 Applicant’s specification consistently refers to only a singular production environment. For example, in connection with Fig. 3, paragraph [0060] recites “In block 302, the validation module may identify attributes and configuration details of a production environment using an infrastructure as code repository” (emphasis added) and [0063] recites “The validation results may be usable by the validation module or some other entity to determine whether to deploy 307 the security policy update to the production environment.” (Emphasis added)
2 Id.
3 See Remarks at pp. 8-9.
4 See Chawla, e.g., Figs. 4-7 and associated text, e.g., [0007], [0025], [0031], [0033], and [0054].
5 See Musani at [0037-39] and [0050].
6 See Remarks at p. 9.
Prosecution Insights