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 .
This office action is responsive to communications filed 8/12/24. Claims 1-20 have been examined and are pending.
Claim Objections
Claim 20 is objected to because of the following informalities.
Claim 20 recites: “The computer system of claim 17, wherein deactivating the policy enforcement engine from enforcing the policy rule involves …; [emphasis added]” However, claim 19, not claim 17, recites: “deactivating the policy enforcement engine from enforcing the policy rule.” In order to avoid rejection under 35 U.S.C. 112(d) for improper claim dependency, the term “computer system of claim 17” should be – computer system of claim 19 -- .
Appropriate correction is required.
Priority
The current application is a Continuation of US Application No. 17/498477 (US Patent 12,081,438 B2) filed October 11, 2021. The application is entitled to an effective filing date of 10/11/2021
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 and 11 of the current application are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 11, respectively, of US Patent No. 12,081,438 B2. Claims 2-10 and 12-20 of the current application are dependent on claims 1 and 11, respectively, and are therefore rejected accordingly. Although the claims at issue are not identical, they are not patentably distinct from each other as indicated by the following:
Application #18/800289
US Patent No. 12,081,438 B2
Claim 1. A computer-implemented method comprising:
monitoring, by a controller, a network including a set of network devices;
receiving, based on the monitoring, a set of attributes associated with the network;
wherein at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules;
applying a unified policy model to determine, based on the set of attributes, an assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine for providing an optimized policy enforcement,
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and
activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules.
Claim 1. A computer-implemented method comprising:
monitoring, by a controller, a network including a set of network devices;
receiving, based on the monitoring, a set of attributes associated with the network;
creating, based on the set of attributes, a unified policy model […] wherein at least two network devices are equipped with a different API [that] provides a different representation of a similar policy function;
wherein the at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules;
applying the unified policy model to determine, based on the set of attributes, an assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine for providing an optimized policy enforcement,
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and
activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules.
Claim 11 A computer system, comprising:
a processor; a memory coupled to the processor and storing instructions which, when executing by the processor, cause the processor to perform a method, the method comprising:
monitoring, by a controller, a network including a set of network devices;
receiving, based on the monitoring, a set of attributes associated with the network;
wherein at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules;
applying a unified policy model to determine, based on the set of attributes, an assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine for providing an optimized policy enforcement,
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and
activating, by the controller, the selected one or both policy enforcement
engines for enforcing the one or more given policy rules.
Claim 11 A computer system, comprising:
a processor; a memory coupled to the processor and storing instructions which, when executing by the processor, cause the processor to perform a method, the method comprising:
monitoring, by a controller, a network including a set of network devices;
…receiving, based on the monitoring, a set of attributes associated with the network;
creating, based on the set of attributes, a unified policy model […] wherein at least two network devices are equipped with a different API [that] provides a different representation of a similar policy function;
wherein the at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules;
applying the unified policy model to determine, based on the set of attributes, an assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine for providing an optimized policy enforcement,
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and
activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules.
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, 7-8, 11-13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Goldschlag et al (US 2014/0165134 A1) in view of Prasad et al (US 2018/0278478 A1)
Re: Claim 1, Goldschlag teaches: A computer-implemented method comprising:
wherein at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules (Goldschlag: Abstract, [0014]; [0100]);
applying a unified policy model (Goldschlag: [0147]-[0148] ref FIG 9, de-conflicted (‘unified’) policy”) to determine, based on the set of attributes an assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine (Goldschlag: “[0056] policy elements “can be implemented on and across a plurality of devices having differing capabilities … the allocation process allocates policy elements to policy enforcement points differently in accordance with the capabilities of the policy enforcement points present or known to a policy management point” ; [0100] “if both a first and a second file system policy enforcement point are available, the policy management point can allocate a policy element requiring a file system policy enforcement point exclusively to the first policy enforcement point, exclusively to the second policy enforcement point, or to both policy enforcement points”), for providing an optimized policy enforcement (Goldschlag: [0113] “Policy conflict resolution, allocation, and selective distribution can take place at any policy management point, so [that] … enforcement is done in the most efficient manner possible”)
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules. (Goldschlag: [0110] “… device policy and virtual machine operating parameter enforcement methods can be implemented in a first policy enforcement point design, while a second policy enforcement point design can implement application encapsulation, and each type is then deployed according to its capabilities and the requirements of policy enforcement; [0159] ref FIG 10, Policy enforcement point having multiple policy enforcers, where “each policy enforcer carries out actions with respect to a particular type of device component. For example, a first policy enforcer carries out actions with respect to an operating system so as to cause that operating system to behave in a manner that enforces the policy that the policy enforcement point that comprises the first policy enforcer is responsible for enforcing, while a second policy enforcer can carry out actions with respect to a virtual machine (VM)… Each type of policy enforcer, optionally in conjunction with other aspects of a policy enforcement point (10000), is capable of translating policy elements into actions suitable for causing the type of device component it is designed to affect to behave in a manner that enforces policy (10010).)
Goldschlag does not explicitly teach:
(i) monitoring, by a controller, [the] network including [the] set of network devices;
(ii) receiving, based on the monitoring, a set of attributes associated with the network
Prasad teaches:
(i) monitoring, by a controller, [the] network including [the] set of network devices; [and] (ii) receiving, based on the monitoring, a set of attributes associated with the network (Prasad: [0027] ref FIG 1, Each network agent 105 may … observe and collect data and report the collected data to the intent driven network policy platform 110 via the EFEs 115. The network agent 105 may collect policy enforcement related data … [including] data related to the enforcement of network policies”; [0082] ref FIG 6, “The agent enforcer 615 … monitors system metrics and policy enforcement metrics so that the data may periodically be sent to the network policy system 650 for analysis”)
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 teachings of Prasad re: “monitor[ing] system metrics and policy enforcement metrics” for use by a “network policy system” (Prasad:[0027] ref FIG 1, [0082] ref FIG 6) with those of Goldschlag re: policy enforcement assignment since Prasad explicitly teaches doing so in order to “generate platform specific policies from the platform independent network policy based on the implementation characteristics of the network entity, and implement the platform specific policies on the network entity” (Prasad: Abstract) including advantageously “apply[ing] any number of optimizations before applying the network policies to the host network entity” (Prasad:[0026])
Claim 11 does not teach or define any new limitations above claim 1. Therefore similar reasons for rejection apply.
Re: Claim 2, Goldschlag teaches: The computer-implemented method of claim 1, including assignment of policy enforcement engines based on network device attributes (Goldschlag: [0056], [0100])
Goldschlag does not explicitly teach:
the set of attributes includes one or more of network device related attributes: amount of memory available at a respective network device; processing resource capability at the network device; number of policy rules supported by a policy enforcement engine associated with the network device; and latency added to a given network traffic flow.
Prasad teaches:
the set of attributes includes one or more of network device related attributes: amount of memory available at a respective network device; processing resource capability at the network device; number of policy rules supported by a policy enforcement engine associated with the network device (Prasad: “network agent”); (Prasad: [0027] ref FIG 1, Each network agent 105 may further be configured to observe and collect data and report the collected data to the intent driven network policy platform 110 via the EFEs 115. The network agent 105 may collect policy enforcement related data associated with the host entity [including] a number of policies being enforced, a number of rules being enforced … or any other data related to the enforcement of network policies. The network agent 105 may also collect data related to host entity performance such as CPU usage, memory usage…etc”; [0077] ref FIG 6 “The network agent 610 may further be configured to observe and collect data and report the collected data to the network policy system 650 via the EFE modules 655. The network agent 610 may collect policy enforcement related data associated with the host entity such as a number of policies being enforced, a number of rules being enforced … or any other data related to the enforcement of network policies. The network agent 610 may also collect data related to host entity 605 performance such as CPU usage, memory usage, …, etc.)
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 teachings of Prasad re: “monitor[ing] system metrics and policy enforcement metrics”, including memory usage, CPU capability and number of policy rules supported/enforced by a policy enforcement engine associated with the network device (Prasad: “network agent”) for use by a “network policy system” (Prasad:[0027] ref FIG 1, [0082] ref FIG 6) with those of Goldschlag re: policy enforcement assignment since Prasad explicitly teaches doing so in order to “generate platform specific policies from the platform independent network policy based on the implementation characteristics of the network entity, and implement the platform specific policies on the network entity” (Prasad: Abstract) including advantageously “apply[ing] any number of optimizations before applying the network policies to the host network entity” (Prasad:[0026])
Claim 12 does not teach or define any new limitations above claim 2. Therefore similar reasons for rejection apply.
Re: claim 3, Goldschlag teaches: The computer-implemented method of claim 1, wherein the set of attributes incudes one or more of network related attributes: different types of policy enforcement engines along the likely network path (Goldschlag: [0110] “… a plurality of policy enforcement point types can be implemented, each specialized for a sub-set of policy enforcement point methods …. each type is then deployed according to its capabilities and the requirements of policy enforcement) ; and current location (s) of one or more hosts corresponding to one or more virtual machines (Goldschlag: [0109] ref FIG 5, [0110] “… device policy and virtual machine operating parameter enforcement methods can be implemented in a first policy enforcement point …”; [0173] ref FIG 11 policy enforcement points (11030 & 11040) for VMs (11080) )
Claim 13 does not teach or define any new limitations above claim 3. Therefore similar reasons for rejection apply.
Re: Claim 7, Goldschlag teaches: The computer-implemented method of claim 1, wherein applying the unified policy model to determine, based on the set of attributes, the assignment of the one or more given policy rules to the first policy enforcement engine and the second policy enforcement engine for providing the optimized policy enforcement further compris[es]:
determining, based on the set of attributes and the given policy rules, that assigning a first policy rule to a first policy enforcement engine and a second policy rule to the second policy enforcement engine results in optimized policy enforcement (Goldschlag: [0110] “… a plurality of policy enforcement point types can be implemented, each specialized for a sub-set of policy enforcement point methods. The plurality of policy enforcement points may be utilized together to cooperatively enforce the policy, and can be intermixed in order to provide the most effective protections for the compartment wherein the optimized policy enforcement indicates that enforcing the given policy rules by the corresponding policy enforcement engines satisfies one or more performance criteria. (Goldschlag: [0113] Policy conflict resolution, allocation, and selective distribution can take place at any policy management point, so there is no need for device configuration to be known by a policy distribution point, and enforcement is done in the most efficient manner possible.
Re: Claim 8. Goldschlag teaches: The computer-implemented method of claim 7, wherein the performance criteria include one or more of:
enforcing a first policy rule by one policy enforcement engine does not conflict with a second policy rule enforced by another policy enforcement engine (Goldschlag: [0113] Policy conflict resolution, allocation, and selective distribution can take place at any policy management point, so there is no need for device configuration to be known by a policy distribution point, and enforcement is done in the most efficient manner possible; [0117] FIG. 7 policy “de-conflict[ion]”) assignment of the one or more policy rules among the different policy enforcement engines along a network path for a given network traffic flow provides for improved path efficiency ( Goldschlag: [0113] Policy conflict resolution, allocation, and selective distribution can take place at any policy management point, so there is no need for device configuration to be known by a policy distribution point, and enforcement is done in the most efficient manner possible)
Claims 6, 9, 10, 16, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Goldschlag and Prasad in view of Bearden et al (US 6,732,168 B1)
Re: Claim 6 Goldschlag teaches: The computer-implemented method of claim 1, including activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules (Goldschlag: [0147]-[0149] allocation using policy cache; [0200]-[0202] ref. FIG 14)
Goldschlag and Prasad do not explicitly teach:
sending, based on the assignment, one or more commands to the selected one or both policy enforcement engine to add the one or more given policy rules in a policy lookup table associated with a corresponding network device.
Bearden teaches:
sending, based on the assignment, one or more commands to the selected one or both policy enforcement engine to add the one or more given policy rules in a policy lookup table (Bearden : “policy repository” ) associated with a corresponding network device (Bearden :col 7/lines 23-40 ref FIG 15, adding a policy package; col 8 lines 21-32 ref FIG 15 – creation of new policy instance)
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 teachings of Bearden re: commands to the selected policy enforcement engine(s) to add policy rule(s) with those of Goldschlag re: use of policy cache for policy activation (Goldschlag: [0147]-[0149] ref FIG 9) since Bearden simply makes explicit that which is suggested by Goldschlag re: automatically adding new policy rules.
Claim 16 does not teach or define any new limitations above claim 6. Therefore similar reasons for rejection apply.
Re: Claim 9, Goldschlag teaches: The computer-implemented method of claim 1, including use of policy cache for storing policy rules for policy instances (Goldschlag: [0147]-[0149])
Goldschlag and Prasad do not explicitly teach:
in response to determining that enforcing at least one policy rule by a policy enforcement engine does not provide the optimized policy enforcement, deactivating the policy enforcement engine from enforcing the policy rule
Bearden teaches:
in response to determining that enforcing at least one policy rule by a policy enforcement engine does not provide the optimized policy enforcement, deactivating the policy enforcement engine from enforcing the policy rule (Bearden :col 7/lines 41- 53 ref FIG 15, policy deactivation; col 8/lines ref FIG 15 10-17 policy deactivation and unloading)
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 teachings of Bearden re: commands to the selected policy enforcement engine(s) to deactivate policy rule(s) with those of Goldschlag re: policy instances and use of policy cache (Goldschlag: [0147]-[0149] ref FIG 9) since Bearden simply makes explicit that which is suggested by Goldschlag re: deactivating/removing policies and since by “deactivat[ing] and unload[ing] each of the policy component instances … in the proper order … ensure[s] consistency of [policy instance] state” (Bearden: col 8/ lines 15-17)
Claim 19 does not teach or define any new limitations above claim 9. Therefore similar reasons for rejection apply.
Re: Claim 10, Goldschlag teaches: The computer-implemented method of claim 9, including use of policy cache for storing policy rules for policy instances (Goldschlag: [0147]-[0149])
Goldschlag and Prasad do not explicitly teach:
wherein deactivating the policy enforcement engine from enforcing the policy rule involves: sending one or more API commands to the policy enforcement engine to remove the policy rule from a policy lookup table in a corresponding network device
Bearden teaches:
wherein deactivating the policy enforcement engine from enforcing the policy rule involves: sending one or more API commands to the policy enforcement engine to remove the policy rule from a policy lookup table in a corresponding network device (Bearden :col 7/lines 41- 53 ref FIG 15, policy deactivation/removal; col 8/lines ref FIG 15 10-17 policy deactivation and unloading)
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 teachings of Bearden re: commands to the selected policy enforcement engine(s) to deactivate policy rule(s) with those of Goldschlag re: policy instances and use of policy cache (Goldschlag: [0147]-[0149] ref FIG 9) since Bearden simply makes explicit that which is suggested by Goldschlag re: deactivating/removing policies and since by “deactivat[ing] and unload[ing] each of the policy component instances … in the proper order … ensure[s] consistency of [policy instance] state” (Bearden: col 8/ lines 15-17)
Claim 20 does not teach or define any new limitations above claim 10. Therefore similar reasons for rejection apply.
Allowable Subject Matter
Claims 4, 5, 14 and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The prior art of record does not disclose: A computer-implemented method / computer system, including:
monitoring, by a controller, a network including a set of network devices;
receiving, based on the monitoring, a set of attributes associated with the network;
creating, based on the set of attributes, a unified policy model by receiving, at the controller, configuration information from a set of network devices residing in the network, wherein at least two network devices are equipped with a different policy enforcement engine with each policy enforcement engine associated with a different Application Programming Interface (API);
wherein each API provides different representations corresponding to a set of different capabilities of policy enforcement engines associated with the at least two network devices;
wherein the at least two network devices are equipped with a first policy enforcement engine and a second policy enforcement engine, respectively, for enforcing one or more given policy rules;
applying the unified policy model to determine, based on the set of attributes, an assignment of the one or more given policy rules to a first policy enforcement engine and a second policy enforcement engine for providing an optimized policy enforcement,
selecting, based on the assignment, one or both of the first policy enforcement engine and the second policy enforcement engine; and activating, by the controller, the selected one or both policy enforcement engines for enforcing the one or more given policy rules.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure re: “Automatic policy engine selection”
Law (US 2004/0039803 A1) Abstract: A unified policy-based network management method and system for enforcing QoS defined by policy rules at a network node. The network management system employ a Policy Enforcement Agent (PEA) responsible for capturing a policy rule in flight and translating the policy rule to actual policy enforcement action executable at a network node. [0037] – [0038] ref FIG 2, “PEA 208 is used to enforce policy rules or directives within the context of the particular end-user application. The PEA 208 … may reside directly on the managed device…. PEA 208 serves as remote active management component which executes policy decisions to be executed locally at a policy enforcement point (PEP) 212 for a particular network node 211 responsible for providing network services to network subscribers 206a, 206b. The network node 211 is typically a router or a network equipment that locally consolidates and analyzes the network conditions to perform network actions as required by the end-user applications running on a network subscriber 206a or 206b. [0055] PEAs 308a, 308b, 308c may monitor various variables such as CPU usage, memory usage, link utilization or propagation delays at the PSs 304a, 304b to determine network congestion at each PSs 304a, 304b. Such information about the PSs 304a, 304b performance may also be saved into the table in realtime. Based on this information, the PEAs 308a, 308b, 308c assign different weighted parameters to different PSs 304a, 304b to alleviate heavy network traffic at a particular PS 304a, 304b by redirecting network policy activity to PSs 304a, 304b that are less busy….)
Appala et al (US 11374980 B1) Abstract: A plurality of policies to be enforced in a network environment via a plurality of devices are determined. A topology of the plurality of devices within the network environment is also determined. For each policy of the plurality of policies, a device of the plurality of devices is selected as the location at which to enforce the policy of the plurality of policies. Selecting the device for each policy of the plurality of policies includes correlating the policy of the plurality of policies with another of the plurality of policies and correlating the policy of the plurality of policies with the topology. Col 2 /lines 13-34 “… network devices where network policies are implemented or enforced (i.e., “enforcement points”) are determined in order to … optimize the enforcement of policies within the network.; Col 2 lines 51-56; Col 4/lines 47- “In order to optimize the implementation of network policies, policy orchestrator 120 is aware of the network topology of devices 115a-e. … policy orchestrator 120 may store data indicative of the topology of network domain 110 …. policy orchestrator 120 may be aware of the network paths though network domain 110. The data stored at policy orchestrator 120 may also indicate the functionality that each of devices 115a-e are capable of and configured to implement; Col 5/lines 11-18 “The resolution logic of policy orchestrator 120 looks at the network topology and determines the path traversal for the policy flow. Policy orchestrator 120 then determines the set of domains and devices involved in the traversal path, determines the capabilities and resource levels of the devices along the traversal path, and determines which portions of the policy may be enforced at which devices along the traversal path; Col 15/lines 53-58)
Andersen et al US 20070192823 A1(Abstract: Techniques for administering and provisioning policies are provided. Policies are translated to an intermediate format and provisioned to heterogeneous devices in native formats of those devices. Administration and interfaces to define and update the policies may occur in the intermediate format or in the native formats. Policies may be combined across devices and published from one device to another device. Policies may also be associated and administered for policy enforcement points; [0023] – [0024] ref FIG 1, [0027] – [0028] ref FIG 1,.[0030] ref FIG 2)
Saklikar et al US 20210135995 A1 (Abstract: One or more lower-level attributes of a first network policy are translated to one or more higher-level attributes of the first network policy, and one or more lower-level attributes of a second network policy are translated to one or more higher-level attributes of the second network policy. The first network policy controls how first network traffic is handled, and the second network policy controls how second network traffic is handled. The one or more higher-level attributes of the first network policy are compared with the one or more higher-level attributes of the second network policy. Based on the comparing, it is determined whether the first network traffic and the second network traffic are handled in a functionally equivalent manner. If not, the first network policy is dynamically updated to generate an updated first network policy that causes the first network traffic to be handled in the functionally equivalent manner; [0059] – [0067] ref FIG. 3; [0077])
Miriyala al (US 2023/0104129 A1) (Abstract: In an example, a method comprises obtaining, by a policy controller from a first SDN architecture system, flow metadata for packet flows exchanged among workloads of a distributed application deployed to the first SDN architecture system; identifying, using flow metadata for a packet flow of the packet flows, a source endpoint workload and a destination endpoint workload of the packet flow; generating a network policy rule to allow packet flows from the source endpoint workload to the destination endpoint workload of the packet flow; and adding the network policy rule to a configuration repository as configuration data for a second SDN architecture system to cause a deployment system to configure the second SDN architecture system with the network policy rule to allow packet flows from the source endpoint workload to the destination endpoint workload when the distributed application is deployed to the second SDN architecture system; [0009])
Roese et al (US 2006/0048142 A1) Abstract: A system and method for rapidly responding to triggering events or activities in a network system. The system includes a policy enforcement function, a policy manager function, and one or more network devices of the network system. The policy enforcement function includes one or more installed policy sets and/or policy enforcement rule sets suitably responsive to triggering events or activities. Upon detection of a trigger, the policy manager function analyzes the trigger and selects one or more appropriate policy sets and/or policy enforcement rule sets deemed to be responsive to the trigger.[0020]-[0021]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT A SHAW whose telephone number is (571)270-5643. The examiner can normally be reached Mon-Fri 1pm -5pm.
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, Emmanuel Moise can be reached on (571)272-3865. 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.
/ROBERT A SHAW/Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455