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 communication is in response to the amendments filed on 04/06/2026. Claims 1-20 are currently pending in the application.
Response to Arguments
Applicant’s arguments with respect to claims 1, 8, and 14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over PGPub. No. 20150156079 to Satterlee et al. (hereinafter Satterlee) in view of US. Pat. No. 11088916 to Chandrashekhar et al. (hereinafter Chandrashekhar) and further in view of US. PGPub. No. 20030037044 to Boreham et al. (hereinafter Boreham).
Regarding claim 1, Satterlee discloses a computer system for managing network security policies (¶0009, “This disclosure relates generally to communication networks, and, more particularly, to methods and apparatus to dynamically provide network policies…”), the computer system comprising:
a processor (FIG. 7, “processor 712”); and
a non-transitory memory storing instructions that, when executed by the processor, cause the system to (¶0035, “the example processes of FIGS. 6A and 6B may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information)…”):
automatically derive user role-specific policies (¶0021, “Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites, ability to deny access to particular applications and/or resources of the enterprise network 104, restrictions based on an amount of data flowing towards a user, restrictions based on an amount of data flowing towards a user from specific applications and/or resources of the enterprise network 104, threat detection such as alarms or notifications of abnormal activity on a per user basis (which may be supplemented with contextual information such as device type, device identification, user identification, etc.),…”), (¶0001, “…The pre-configured network elements operate autonomously to statically enforce the network policies. That is, the network elements of such systems are statically configured with the network policies prior to users accessing the network via the network elements.”), based on security intent-based policies, (¶0009, “…The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments, etc. Network policy management systems enforce network policies by configuring network elements (e.g., access points, edge routers, etc.) according to the rules and/or settings of the network policies…”, wherein policies for bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments etc and enforcing the policies is interpreted as security intent-based policy) and user role applicability information (¶0024, “the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118…”)
wherein each security intent-based policy defines one or more user roles applicable across the network by specifying, for each user role, a user role identity and corresponding access rules, (¶0021, “example of FIG. 2, the policy creator 200 implements a user interface accessible to administrators of the example NPP 102. The user interface provided by the example policy creator 200 of FIG. 2 provides the administrators with tools to define rules, settings, and/or terms of the network policies by, for example, selecting from a plurality of options and/or entering information into one or more data entry fields. Further, the example policy creator 200 of FIG. 2 provides the administrators with tools to define circumstances for which one or more network policies are to be selected for enforcement. For example, the tools enable the administrator to designate a certain network policy for enforcement when a particular user accesses the enterprise network 104…”),
and
wherein the user role applicability information specifies which of the user roles defined by the security intent-based policies are applicable at each location across the network (¶0010, “…That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)….,”) and
generate policy configurations from the derived user role-specific policies for each combination of a user role, a network device type, and a location across the network, wherein each policy configuration comprises a tailored set of enforceable rules specific to the combination, (¶0010, “That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)…”), (¶0019, “…The example NPP 102 of FIG. 1 enables dynamic enforcement of network policies based on, for example, an identity of the user 118 accessing the enterprise network 104, an identity of the device being used to access the enterprise network 104, an identity of the resource being accessed, and/or a location from which the user 118 accesses the enterprise network 104. To do so, the example NPP 102 of FIG. 1 includes a policy manager 126, an identifier 128, a network usage tracker 130, and a network element (NE) programmer 132. As described in detail below in connection with FIG. 3, the example policy manager 126 of FIG. 1 enables creation of one or more network policies for the user 118, the user device, the location, and/or the network resource, and makes the one or more network policies available for selection based on, for example, the circumstances defining the context associated with the access of the enterprise network 104. As described in detail below in connection with FIG. 4, the example identifier 128 of FIG. 1 collects information associated with an access of the enterprise network 104 (e.g., an identity of a user accessing the enterprise network 104, an identity of a computing device being used to access the enterprise network 104, an identity of a resource being accessed, and/or a location from which the enterprise network 104 is being accessed) and selects one or more network policies managed by the example policy manager 126 of FIGS. 1 and/or 3 for enforcement during the corresponding session…”) and
distribute the generated policy configurations to corresponding network devices for enforcement (¶0029-¶0030, “…the example push/poll communicator 400 of FIG. 4 informs the network elements of which network session to which the corresponding instructions apply. Because the network elements are to be programmed to enforce the selected network policy with respect to a particular computing device (e.g., of a particular user), the example push/poll communicator 400 of FIG. 4 provides identifying information to the network elements associated with the particular computing device and/or user for which the network policy has been selected. As described above, the example identifier 128 obtains data indicative of an identity of a user and/or computing device being used to access (or attempt to access) the enterprise network 104. The example push/poll communicator 400 of FIG. 4 provides such information (e.g., a device identifier, a network address, etc.) to the network elements, which utilize the identifying information to assign the network policy to a particular port, session, message, etc. associated with the identified computing device and/or user. Thus, the example push/poll communicator 400 of FIG. 4 provides the network elements with identification information and programming instructions such that the receiving network elements can be dynamically program one or more devices and/or applications to enforce the network policy with respect to a particular computing device…”).
However, Satterlee even though discloses traffic prioritization policy for specific users in ¶0021, does not explicitly disclose the following limitation:
automatically derive user role-specific policies based, the global policy order,
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Chandrashekhar discloses automatically derive user role-specific policies based, the
global policy order (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.27, lines 27-40, “… in FIG. 17, there are nodes for site A 1760, site B 1777, and site C 1765 under the global root 1702. Each site has an enforcement point child node, under which specific resources are assigned, such as edge clusters, transport zones, etc. In the example, site A's edge cluster 1751 has incoming references from locale services 1735 attached to router T0 1705 and from locale services 1750 attached to router T1B 1715. The edge cluster 1752 at site B 1777 has an incoming reference from the locale services 1740 attached to router T0 1705. In some embodiments, edge clusters also have children corresponding to edge nodes 1753, which actually execute the services such as firewalls, DHCP, etc.”), (Coln.34, lines 39-67-Coln. 35, lines 1-20, “The match-action table 2300 has multiple flow entries 2305-2315 each specifying different service rules…These service operations include load-balancing, firewall, Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and other
services.”),
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee to include global policy as disclosed by Chandrashekhar and be motivated in doing so in order to provides to the local manager of each site, the portion of the logical network definition identified for the site- Chandrashekhar abstract in parts.
The combination of Satterlee and Chandrashekhar does not explicitly disclose the following limitation:
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Boreham discloses wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies (¶0249-¶0250. “…The cosPriority attribute represents the global priority of a particular template as a numeric decimal value. In this priority scheme zero is the highest possible priority with the lower priorities extending towards infinity. Templates with higher priorities will be favored over and to the exclusion of templates with lower priorities. Templates which do not have a cosPriority attribute are considered to have the lowest priority possible, or no priority…”), (¶0264, “Directory Server can be used to manage extranet user-authentication, create role-based access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own portions of the directory, reducing administrative costs.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee and Chandrashekhar to include user preferences as disclosed by Boreham and be motivated in doing so in order to direct the limited resources to a high-value activity and reduce administrative costs- Boreham ¶0264 in parts.
Regarding claim 8, Satterlee discloses a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to (¶0035, “the example processes of FIGS. 6A and 6B may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information)…”)
automatically derive user role-specific policies (¶0021, “Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites, ability to deny access to particular applications and/or resources of the enterprise network 104, restrictions based on an amount of data flowing towards a user, restrictions based on an amount of data flowing towards a user from specific applications and/or resources of the enterprise network 104, threat detection such as alarms or notifications of abnormal activity on a per user basis (which may be supplemented with contextual information such as device type, device identification, user identification, etc.),…”), (¶0001, “…The pre-configured network elements operate autonomously to statically enforce the network policies. That is, the network elements of such systems are statically configured with the network policies prior to users accessing the network via the network elements.”), based on security intent-based policies, (¶0009, “…The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments, etc. Network policy management systems enforce network policies by configuring network elements (e.g., access points, edge routers, etc.) according to the rules and/or settings of the network policies…”, wherein policies for bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments etc and enforcing the policies is interpreted as security intent-based policy), and user role applicability information (¶0024, “the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118…”)
wherein each security intent-based policy defines one or more user roles applicable across the network by specifying, for each user role, a user role identity and corresponding access rules, (¶0021, “example of FIG. 2, the policy creator 200 implements a user interface accessible to administrators of the example NPP 102. The user interface provided by the example policy creator 200 of FIG. 2 provides the administrators with tools to define rules, settings, and/or terms of the network policies by, for example, selecting from a plurality of options and/or entering information into one or more data entry fields. Further, the example policy creator 200 of FIG. 2 provides the administrators with tools to define circumstances for which one or more network policies are to be selected for enforcement. For example, the tools enable the administrator to designate a certain network policy for enforcement when a particular user accesses the enterprise network 104…”),
and
wherein the user role applicability information specifies which of the user roles defined by the security intent-based policies are applicable at each location across the network (¶0010, “…That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)….,”) and
generate policy configurations from the derived user role-specific policies for each combination of a user role, a network device type, and a location across the network, wherein each policy configuration comprises a tailored set of enforceable rules specific to the combination, (¶0010, “That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)…”), (¶0019, “…The example NPP 102 of FIG. 1 enables dynamic enforcement of network policies based on, for example, an identity of the user 118 accessing the enterprise network 104, an identity of the device being used to access the enterprise network 104, an identity of the resource being accessed, and/or a location from which the user 118 accesses the enterprise network 104. To do so, the example NPP 102 of FIG. 1 includes a policy manager 126, an identifier 128, a network usage tracker 130, and a network element (NE) programmer 132. As described in detail below in connection with FIG. 3, the example policy manager 126 of FIG. 1 enables creation of one or more network policies for the user 118, the user device, the location, and/or the network resource, and makes the one or more network policies available for selection based on, for example, the circumstances defining the context associated with the access of the enterprise network 104. As described in detail below in connection with FIG. 4, the example identifier 128 of FIG. 1 collects information associated with an access of the enterprise network 104 (e.g., an identity of a user accessing the enterprise network 104, an identity of a computing device being used to access the enterprise network 104, an identity of a resource being accessed, and/or a location from which the enterprise network 104 is being accessed) and selects one or more network policies managed by the example policy manager 126 of FIGS. 1 and/or 3 for enforcement during the corresponding session…”) and
distribute the generated policy configurations to corresponding network devices for enforcement (¶0029-¶0030, “…the example push/poll communicator 400 of FIG. 4 informs the network elements of which network session to which the corresponding instructions apply. Because the network elements are to be programmed to enforce the selected network policy with respect to a particular computing device (e.g., of a particular user), the example push/poll communicator 400 of FIG. 4 provides identifying information to the network elements associated with the particular computing device and/or user for which the network policy has been selected. As described above, the example identifier 128 obtains data indicative of an identity of a user and/or computing device being used to access (or attempt to access) the enterprise network 104. The example push/poll communicator 400 of FIG. 4 provides such information (e.g., a device identifier, a network address, etc.) to the network elements, which utilize the identifying information to assign the network policy to a particular port, session, message, etc. associated with the identified computing device and/or user. Thus, the example push/poll communicator 400 of FIG. 4 provides the network elements with identification information and programming instructions such that the receiving network elements can be dynamically program one or more devices and/or applications to enforce the network policy with respect to a particular computing device…”).
However, Satterlee even though discloses traffic prioritization policy for specific users in ¶0021, does not explicitly disclose the following limitation:
automatically derive user role-specific policies based, the global policy order,
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Chandrashekhar discloses automatically derive user role-specific policies based, the
global policy order (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.27, lines 27-40, “… in FIG. 17, there are nodes for site A 1760, site B 1777, and site C 1765 under the global root 1702. Each site has an enforcement point child node, under which specific resources are assigned, such as edge clusters, transport zones, etc. In the example, site A's edge cluster 1751 has incoming references from locale services 1735 attached to router T0 1705 and from locale services 1750 attached to router T1B 1715. The edge cluster 1752 at site B 1777 has an incoming reference from the locale services 1740 attached to router T0 1705. In some embodiments, edge clusters also have children corresponding to edge nodes 1753, which actually execute the services such as firewalls, DHCP, etc.”), (Coln.34, lines 39-67-Coln. 35, lines 1-20, “The match-action table 2300 has multiple flow entries 2305-2315 each specifying different service rules…These service operations include load-balancing, firewall, Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and other
services.”),
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee to include global policy as disclosed by Chandrashekhar and be motivated in doing so in order to provides to the local manager of each site, the portion of the logical network definition identified for the site- Chandrashekhar abstract in parts.
The combination of Satterlee and Chandrashekhar does not explicitly disclose the following limitation:
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Boreham discloses wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies (¶0249-¶0250. “…The cosPriority attribute represents the global priority of a particular template as a numeric decimal value. In this priority scheme zero is the highest possible priority with the lower priorities extending towards infinity. Templates with higher priorities will be favored over and to the exclusion of templates with lower priorities. Templates which do not have a cosPriority attribute are considered to have the lowest priority possible, or no priority…”), (¶0264, “Directory Server can be used to manage extranet user-authentication, create role-based access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own portions of the directory, reducing administrative costs.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee and Chandrashekhar to include user preferences as disclosed by Boreham and be motivated in doing so in order to direct the limited resources to a high-value activity and reduce administrative costs- Boreham ¶0264 in parts.
Regarding claim 14, Satterlee discloses a computer-implemented method (¶0042, “FIG. 7 is a block diagram of an example processor platform 700 capable of executing the instructions of FIGS. 6A and 6B to implement the example NPP 102 of FIGS. 1-5. The processor platform 700 can be, for example, a server, a personal computer, an Internet appliance, or any other type of computing device.”) for managing network security policies (¶0009, “This disclosure relates generally to communication networks, and, more particularly, to methods and apparatus to dynamically provide network policies…”), the computer-implemented method comprising:
automatically deriving user role-specific policies (¶0021, “Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites, ability to deny access to particular applications and/or resources of the enterprise network 104, restrictions based on an amount of data flowing towards a user, restrictions based on an amount of data flowing towards a user from specific applications and/or resources of the enterprise network 104, threat detection such as alarms or notifications of abnormal activity on a per user basis (which may be supplemented with contextual information such as device type, device identification, user identification, etc.),…”), (¶0001, “…The pre-configured network elements operate autonomously to statically enforce the network policies. That is, the network elements of such systems are statically configured with the network policies prior to users accessing the network via the network elements.”), based on security intent-based policies, (¶0009, “…The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments, etc. Network policy management systems enforce network policies by configuring network elements (e.g., access points, edge routers, etc.) according to the rules and/or settings of the network policies…”, wherein policies for bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments etc and enforcing the policies is interpreted as security intent-based policy) and user role applicability information (¶0024, “the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118…”);
wherein each security intent-based policy defines one or more user roles applicable across the network by specifying, for each user role, a user role identity and corresponding access rules, (¶0021, “example of FIG. 2, the policy creator 200 implements a user interface accessible to administrators of the example NPP 102. The user interface provided by the example policy creator 200 of FIG. 2 provides the administrators with tools to define rules, settings, and/or terms of the network policies by, for example, selecting from a plurality of options and/or entering information into one or more data entry fields. Further, the example policy creator 200 of FIG. 2 provides the administrators with tools to define circumstances for which one or more network policies are to be selected for enforcement. For example, the tools enable the administrator to designate a certain network policy for enforcement when a particular user accesses the enterprise network 104…”),
and
wherein the user role applicability information specifies which of the user roles defined by the security intent-based policies are applicable at each location across the network (¶0010, “…That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)….,”) and
generating policy configurations from the derived user role-specific policies for each combination of a user role, a network device type, and a location across the network, wherein each policy configuration comprises a tailored set of enforceable rules specific to the combination, (¶0010, “That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)…”), (¶0019, “…The example NPP 102 of FIG. 1 enables dynamic enforcement of network policies based on, for example, an identity of the user 118 accessing the enterprise network 104, an identity of the device being used to access the enterprise network 104, an identity of the resource being accessed, and/or a location from which the user 118 accesses the enterprise network 104. To do so, the example NPP 102 of FIG. 1 includes a policy manager 126, an identifier 128, a network usage tracker 130, and a network element (NE) programmer 132. As described in detail below in connection with FIG. 3, the example policy manager 126 of FIG. 1 enables creation of one or more network policies for the user 118, the user device, the location, and/or the network resource, and makes the one or more network policies available for selection based on, for example, the circumstances defining the context associated with the access of the enterprise network 104. As described in detail below in connection with FIG. 4, the example identifier 128 of FIG. 1 collects information associated with an access of the enterprise network 104 (e.g., an identity of a user accessing the enterprise network 104, an identity of a computing device being used to access the enterprise network 104, an identity of a resource being accessed, and/or a location from which the enterprise network 104 is being accessed) and selects one or more network policies managed by the example policy manager 126 of FIGS. 1 and/or 3 for enforcement during the corresponding session…”) and
distributing the generated policy configurations to corresponding network devices for enforcement (¶0029-¶0030, “…the example push/poll communicator 400 of FIG. 4 informs the network elements of which network session to which the corresponding instructions apply. Because the network elements are to be programmed to enforce the selected network policy with respect to a particular computing device (e.g., of a particular user), the example push/poll communicator 400 of FIG. 4 provides identifying information to the network elements associated with the particular computing device and/or user for which the network policy has been selected. As described above, the example identifier 128 obtains data indicative of an identity of a user and/or computing device being used to access (or attempt to access) the enterprise network 104. The example push/poll communicator 400 of FIG. 4 provides such information (e.g., a device identifier, a network address, etc.) to the network elements, which utilize the identifying information to assign the network policy to a particular port, session, message, etc. associated with the identified computing device and/or user. Thus, the example push/poll communicator 400 of FIG. 4 provides the network elements with identification information and programming instructions such that the receiving network elements can be dynamically program one or more devices and/or applications to enforce the network policy with respect to a particular computing device…”).
However, Satterlee even though discloses traffic prioritization policy for specific users in ¶0021, does not explicitly disclose the following limitation:
automatically deriving user role-specific policies based, the global policy order,
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Chandrashekhar discloses automatically deriving user role-specific policies based, the
global policy order (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.27, lines 27-40, “… in FIG. 17, there are nodes for site A 1760, site B 1777, and site C 1765 under the global root 1702. Each site has an enforcement point child node, under which specific resources are assigned, such as edge clusters, transport zones, etc. In the example, site A's edge cluster 1751 has incoming references from locale services 1735 attached to router T0 1705 and from locale services 1750 attached to router T1B 1715. The edge cluster 1752 at site B 1777 has an incoming reference from the locale services 1740 attached to router T0 1705. In some embodiments, edge clusters also have children corresponding to edge nodes 1753, which actually execute the services such as firewalls, DHCP, etc.”), (Coln.34, lines 39-67-Coln. 35, lines 1-20, “The match-action table 2300 has multiple flow entries 2305-2315 each specifying different service rules…These service operations include load-balancing, firewall, Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and other
services.”),
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee to include global policy as disclosed by Chandrashekhar and be motivated in doing so in order to provides to the local manager of each site, the portion of the logical network definition identified for the site- Chandrashekhar abstract in parts.
The combination of Satterlee and Chandrashekhar does not explicitly disclose the following limitation:
wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies,
Boreham discloses wherein the global policy order establishes a priority sequence for merging the security intent-based policies and determining the order of rules within the derived user role- specific policies, wherein higher-priority policies in the priority sequence take precedence over lower-priority policies when combining user role-specific sub-policies (¶0249-¶0250. “…The cosPriority attribute represents the global priority of a particular template as a numeric decimal value. In this priority scheme zero is the highest possible priority with the lower priorities extending towards infinity. Templates with higher priorities will be favored over and to the exclusion of templates with lower priorities. Templates which do not have a cosPriority attribute are considered to have the lowest priority possible, or no priority…”), (¶0264, “Directory Server can be used to manage extranet user-authentication, create role-based access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own portions of the directory, reducing administrative costs.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee and Chandrashekhar to include user preferences as disclosed by Boreham and be motivated in doing so in order to direct the limited resources to a high-value activity and reduce administrative costs- Boreham ¶0264 in parts.
Regarding claim 2, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Chandrashekhar further discloses wherein the instructions, when executed by the processor, further cause the system to determine relevant policy configurations for each network device based on type and location (Coln.2, lines 14-27, “…When the primary global manager receives the global desired configuration for the logical network, the global manager stores portions of the global configuration in each queue, based on the relevance of the portions to the configuration of the logical network at the queue's corresponding physical site…”), (Coln.3, lines 17-49, “The local manager at each site uses the relevant portion of the global desired configuration, received from the global manager, to manage the logical network at the site. For example, in some embodiments, the local manager uses the relevant portion to generate and provide configuration data to the control plane of the logical network (e.g., a cluster of controllers at each site). In some embodiments, these controllers identify computing devices at the site which execute physical forwarding elements, and distribute the configuration data to the identified computing devices.”), (Coln.1, lines 37-47, “the global manager executes on a computing device at one of the sites spanned by the logical network, and each local manager also executes on a computing device at its respective site…”), (Coln.48, lines 62-67-Coln.49, lines 1-3, “…This mapping allows the local managers to retrieve from the global manager 420 the relevant policy information applicable to the machine, so that these policies are seamlessly applied before and after migration…”), (Coln.26, lines 20-40, “…The local service nodes also have various types of child nodes in some embodiments, defining various different types of configuration information available at the respective site…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include relevancy policy as disclosed by Chandrashekhar and be motivated in doing so in order to creates mappings between logical addresses (e.g., MAC addresses of logical network endpoints executing on the computing devices) and physical addresses (e.g., IP addresses of tunnel endpoints at the computing devices), and distributes these mappings to each computing device to which they are relevant-Chandrashekhar Coln.3, lines 17-49, in parts.
Regarding claim 3, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Satterlee further discloses automatically deriving user role-specific policies (¶0021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites…”), and
Chandrashekhar further discloses wherein automatically deriving user role-specific policies comprises applying the global policy order to ensure correct rule ordering for various locations across the network (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.33, lines 35-67-Coln.34, lines 1-29, “…The global policy tree 1700 is stored by the primary global manager 420 in its database 710. A replica of the global policy tree 1700 is also stored by the secondary global manager 460 in its database 712. As noted above, in some embodiments the nodes also represent logical network policies that apply to the logical network elements. The logical network policies include forwarding policies, service policies, and security policies, and are applied in some embodiments to govern the behavior of the logical forwarding elements (e.g., by governing the behavior of the physical forwarding elements that implement the logical forwarding elements)...”), (Coln.4, lines1-38, “The local manager uses the service rules to generate configuration data for distribution by controllers, to configure the data plane (i.e., the forwarding elements and the service machines) to enforce the received service rules on data message flows that are associated with groups of logical network endpoints…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include global rule enforcement as disclosed by Chandrashekhar and be motivated in doing so in order to govern the behavior of the logical forwarding elements (e.g., by governing the behavior of the physical forwarding elements that implement the logical forwarding elements)-Chandrashekhar Coln.33, lines 35-46 in parts.
Regarding claim 4, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Satterlee further discloses wherein the instructions, when executed by the processor,
further cause the system to:
automatically determine affected network devices and locations (¶0010, “… That is,
examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)… ”) based on a policy update request (¶0027, “…Therefore, the data obtained by the example identifier 128 of FIG. 3 enables a determination of which of the policies 202 is to be dynamically enforced for the current network session. Although many examples discussed herein refer to selecting one or more network policies in response to an attempted access, policies may additionally or alternatively be set at other times. For example, if a changed circumstance is detected after a session is initiated, a new policy may be invoked and/or an existing policy may be terminated.) and the user role applicability information (¶0024, “… For example, the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118. Further, the example data capturer 300 of FIG. 3 obtains information regarding which of the computing devices 120-124 is being utilized by the user 118 to access the enterprise network 104 in the corresponding session…”), and
Chandrashekhar further discloses wherein the instructions, when executed by the processor, further cause the system to:
automatically determine affected network devices and locations based on a policy update request and the user role applicability information (Coln.17, lines 37-57, “…The desired configuration is received in some embodiments as one or more create, update, or delete (CUD) events received at the global manager 420 as a series of API transactions, with each CUD event affecting one or more logical network elements spanning one or more of the physical sites…”), (Coln.48, lines 62-67-Coln.49, lines 1-3, “…This mapping allows the local managers to retrieve from the global manager 420 the relevant policy information applicable to the machine, so that these policies are seamlessly applied before and after migration…”), (Coln.2, lines 55-65, “FIG. 16 conceptually illustrates a process 1600 performed in some embodiments by a local manager at a physical site, when it receives a CUD event directly from a user client 440, instead of from the global manager 420. This scenario occurs for example when a local administrator of the physical site (who may or may not be the same as the administrator of the global federated logical network as a whole) modifies the logical network's desired configuration as implemented at the local site (e.g. by specifying a series of create, update, or delete events for logical network elements whose span includes the local site).”);
update the relevant policy configurations (Coln.22, lines 21-54, “…If the CUD event is an update event, then the desired configuration of a logical network element referenced by the event is updated within the desired configuration stored in the database 1405…”), (Coln.30, lines 62-67-(Coln.31, lines 1-8, “… the received configuration is a modification to a previously received global configuration, such as a create, update, or delete event to one or more logical network elements.”); and
distribute the updated policy configurations to the affected network devices (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
NOTE: The above motivation also applies to claim 6 and other claims relating to policy update.
Regarding claim 10, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the non-transitory computer-readable medium of claim 8.
Satterlee further discloses wherein the instructions, when executed by the processor, cause the processor to:
automatically determine affected network devices and locations (¶0010, “… That is,
examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)… ”) based on a policy update request (¶0027, “…Therefore, the data obtained by the example identifier 128 of FIG. 3 enables a determination of which of the policies 202 is to be dynamically enforced for the current network session. Although many examples discussed herein refer to selecting one or more network policies in response to an attempted access, policies may additionally or alternatively be set at other times. For example, if a changed circumstance is detected after a session is initiated, a new policy may be invoked and/or an existing policy may be terminated.) and the user role applicability information (¶0024, “… For example, the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118. Further, the example data capturer 300 of FIG. 3 obtains information regarding which of the computing devices 120-124 is being utilized by the user 118 to access the enterprise network 104 in the corresponding session…”),
and
Chandrashekhar further discloses wherein the instructions, when executed by the processor, cause the processor to:
receiving a policy update request (Coln.16, line 65-67-Coln.16, lines 1-6, “The process 1000 begins by receiving at 1005 data describing a desired configuration of the logical network. The received data is in some embodiments one or more create, update, or delete (CUD) events received at the global manager 420 as a series of API transactions, each CUD event affecting one or more logical network elements spanning one or more of the physical sites…”);
automatically determine affected network devices and locations based on a policy update request and the user role applicability information (Coln.17, lines 37-57, “…The desired configuration is received in some embodiments as one or more create, update, or delete (CUD) events received at the global manager 420 as a series of API transactions, with each CUD event affecting one or more logical network elements spanning one or more of the physical sites…”), (Coln.48, lines 62-67-Coln.49, lines 1-3, “…This mapping allows the local managers to retrieve from the global manager 420 the relevant policy information applicable to the machine, so that these policies are seamlessly applied before and after migration…”), (Coln.2, lines 55-65, “FIG. 16 conceptually illustrates a process 1600 performed in some embodiments by a local manager at a physical site, when it receives a CUD event directly from a user client 440, instead of from the global manager 420. This scenario occurs for example when a local administrator of the physical site (who may or may not be the same as the administrator of the global federated logical network as a whole) modifies the logical network's desired configuration as implemented at the local site (e.g. by specifying a series of create, update, or delete events for logical network elements whose span includes the local site).”);
update the relevant policy configurations (Coln.22, lines 21-54, “…If the CUD event is an update event, then the desired configuration of a logical network element referenced by the event is updated within the desired configuration stored in the database 1405…”), (Coln.30, lines 62-67-(Coln.31, lines 1-8, “… the received configuration is a modification to a previously received global configuration, such as a create, update, or delete event to one or more logical network elements.”); and
distribute the updated policy configurations to the affected network devices (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
Regarding claim 18, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer-implemented method of claim 14.
Satterlee further discloses further comprising: automatically determining affected
network devices and locations (¶0010, “… That is, examples disclosed herein dynamically select and enforce a selected one of a plurality of network policies based on the context of a network access (e.g., based on one or more circumstances such as a user identity, a device identity, a type of device, a resource being accessed, and/or a location from which the user is accessing the network)… ”) based on a policy update request (¶0027, “…Therefore, the data obtained by the example identifier 128 of FIG. 3 enables a determination of which of the policies 202 is to be dynamically enforced for the current network session. Although many examples discussed herein refer to selecting one or more network policies in response to an attempted access, policies may additionally or alternatively be set at other times. For example, if a changed circumstance is detected after a session is initiated, a new policy may be invoked and/or an existing policy may be terminated.) and the user role applicability information (¶0024, “… For example, the user 118 of FIG. 1 has a user name that is associated with identifying information (e.g., a full name, a social security number, an employee identification number, a role in the company, etc.) indicative of an identity of the user 118. The authentication device 112 of FIG. 1 may supply the example data capturer 300 with the identifying information to inform the identifier 128 of the identity of the user 118. Further, the example data capturer 300 of FIG. 3 obtains information regarding which of the computing devices 120-124 is being utilized by the user 118 to access the enterprise network 104 in the corresponding session…”), and
Chandrashekhar further discloses further comprising:
automatically determining affected network devices and locations based on a policy update request and the user role applicability information (Coln.17, lines 37-57, “…The desired configuration is received in some embodiments as one or more create, update, or delete (CUD) events received at the global manager 420 as a series of API transactions, with each CUD event affecting one or more logical network elements spanning one or more of the physical sites…”), (Coln.48, lines 62-67-Coln.49, lines 1-3, “…This mapping allows the local managers to retrieve from the global manager 420 the relevant policy information applicable to the machine, so that these policies are seamlessly applied before and after migration…”), (Coln.2, lines 55-65, “FIG. 16 conceptually illustrates a process 1600 performed in some embodiments by a local manager at a physical site, when it receives a CUD event directly from a user client 440, instead of from the global manager 420. This scenario occurs for example when a local administrator of the physical site (who may or may not be the same as the administrator of the global federated logical network as a whole) modifies the logical network's desired configuration as implemented at the local site (e.g. by specifying a series of create, update, or delete events for logical network elements whose span includes the local site).”);
updating the relevant policy configurations (Coln.22, lines 21-54, “…If the CUD event is an update event, then the desired configuration of a logical network element referenced by the event is updated within the desired configuration stored in the database 1405…”), (Coln.30, lines 62-67-(Coln.31, lines 1-8, “… the received configuration is a modification to a previously received global configuration, such as a create, update, or delete event to one or more logical network elements.”); and
distributing the updated policy configurations to the affected network devices (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
Regarding claim 5, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Satterlee further discloses wherein generating policy configurations comprises filtering the derived user role-specific policies to include policies relevant to a specific network device, location, or a combination thereof (¶0021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites…”), (¶0010, “…Example circumstances include an identity of a particular user that is accessing the network, an identity of a particular computing device (e.g., a device having an identifier assigned to the particular user), a type of computing device (e.g., a personal computer, a tablet, a smart phone, a laptop, etc.) being used to access the network, a resource being accessed, and a location from which the network is being accessed. The collection of circumstances defines a context for a network access session and/or a communication session. Examples disclosed herein use any one of the circumstances associated with the access of the network and/or a combination of the circumstances associated with the access of the network to, in real-time or substantially real-time, select the appropriate network policy…”).
Regarding claim 11, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the non-transitory computer-readable medium of claim 8.
Satterlee further discloses wherein generating policy configurations comprises filtering the derived user role-specific policies to include policies relevant to a specific network device, location, or a combination thereof (¶0021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites…”), (¶0010, “…Example circumstances include an identity of a particular user that is accessing the network, an identity of a particular computing device (e.g., a device having an identifier assigned to the particular user), a type of computing device (e.g., a personal computer, a tablet, a smart phone, a laptop, etc.) being used to access the network, a resource being accessed, and a location from which the network is being accessed. The collection of circumstances defines a context for a network access session and/or a communication session. Examples disclosed herein use any one of the circumstances associated with the access of the network and/or a combination of the circumstances associated with the access of the network to, in real-time or substantially real-time, select the appropriate network policy…”).
Regarding claim 17, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer-implemented method of claim 14.
Satterlee further discloses further comprising wherein generating policy configurations comprises filtering the derived user role-specific policies to include policies relevant to a specific network device, location, or a combination thereof (¶0021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites…”), (¶0010, “…Example circumstances include an identity of a particular user that is accessing the network, an identity of a particular computing device (e.g., a device having an identifier assigned to the particular user), a type of computing device (e.g., a personal computer, a tablet, a smart phone, a laptop, etc.) being used to access the network, a resource being accessed, and a location from which the network is being accessed. The collection of circumstances defines a context for a network access session and/or a communication session. Examples disclosed herein use any one of the circumstances associated with the access of the network and/or a combination of the circumstances associated with the access of the network to, in real-time or substantially real-time, select the appropriate network policy…”).
Regarding claim 6, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Chandrashekhar further discloses wherein the instructions, when executed by the processor, further cause the system to: automatically regenerate and redistribute policy configurations based on an updated global policy order (Coln.15, lines 57-64, “…FIG. 9 conceptually illustrates generating an update stream for use by the primary global manager 420, to replicate the desired configuration to the secondary global manager 460. FIG. 10 illustrates a process 1000 performed in some embodiments by a database instance 840 to generate the update stream, with reference to FIG. 9”), (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”), the updated global policy order comprising a modified priority sequence for the security intent-based polices (Coln. 23, lines 35-61, FIG. 16, “…some embodiments prevent overrides of the desired configuration by a local CUD event for security-related configurations. In such cases, the globally-defined desired configuration would have priority. In addition, in some cases the event is an emergency-related event, which is only recognized by the local manager and therefore does override any related global configuration. If the event does not have priority to override the global configuration (e.g., according to the priority rules), then the process continues to 1617, which was defined above.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
Regarding claim 12, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the non-transitory computer-readable medium of claim 8.
Chandrashekhar further discloses wherein the instructions, when executed by the
processor, cause the processor to:
automatically regenerate and redistribute policy configurations based on an updated
global policy order (Coln.15, lines 57-64, “…FIG. 9 conceptually illustrates generating an update stream for use by the primary global manager 420, to replicate the desired configuration to the secondary global manager 460. FIG. 10 illustrates a process 1000 performed in some embodiments by a database instance 840 to generate the update stream, with reference to FIG. 9”), (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”), the updated global policy order comprising a modified priority sequence for the security intent-based polices (Coln. 23, lines 35-61, FIG. 16, “…some embodiments prevent overrides of the desired configuration by a local CUD event for security-related configurations. In such cases, the globally-defined desired configuration would have priority. In addition, in some cases the event is an emergency-related event, which is only recognized by the local manager and therefore does override any related global configuration. If the event does not have priority to override the global configuration (e.g., according to the priority rules), then the process continues to 1617, which was defined above.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
Regarding claim 20, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer-implemented method of claim 14.
Chandrashekhar further discloses further comprising:
automatically regenerate and redistribute policy configurations based on an updated global policy order (Coln.15, lines 57-64, “…FIG. 9 conceptually illustrates generating an update stream for use by the primary global manager 420, to replicate the desired configuration to the secondary global manager 460. FIG. 10 illustrates a process 1000 performed in some embodiments by a database instance 840 to generate the update stream, with reference to FIG. 9”), (Coln.46, lines7-16, “where the attempt to modify the configuration of a logical network element succeeds (e.g., because the update is a networking-related update, not a security-related update), then the local manager in some embodiments sends a notification (not shown in FIG. 31) to the global manager of the update. This is necessary to inform the global manager 420 that the realized state of the logical network element at this physical site will not match the realized state of the element at other sites, due to the site-specific update.”), (Coln.15, lines 17-24, “…Entries in the distributed log provide an ordered, persisted history of updates to the state of different logical network elements and logical network policies, which the manager cluster accesses via application programming interfaces (APIs) provided by the database instances 840-850…”), the updated global policy order comprising a modified priority sequence for the security intent-based polices (Coln. 23, lines 35-61, FIG. 16, “…some embodiments prevent overrides of the desired configuration by a local CUD event for security-related configurations. In such cases, the globally-defined desired configuration would have priority. In addition, in some cases the event is an emergency-related event, which is only recognized by the local manager and therefore does override any related global configuration. If the event does not have priority to override the global configuration (e.g., according to the priority rules), then the process continues to 1617, which was defined above.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include policy updating as disclosed by Chandrashekhar and be motivated in doing so in order to enforce the received updated service rules on data message flows that are associated with groups of logical network endpoints-Chandrashekhar Coln.4, lines 1-13 in parts.
Regarding claim 7, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer system of claim 1.
Satterlee further discloses wherein the security intent-based policies comprise at least one of organizational policies, departmental policies, and location-specific policies or a combination thereof (¶0009, “…Network policy management for enterprise networks (e.g., a network of a company or other type of entity) involves setting and implementing policies that determine how users and/or groups of users associated with a corresponding enterprise are able to utilize the enterprise network and/or network devices accessible via the enterprise network. The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments…”), (¶021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules…”)
Regarding claim 13, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the non-transitory computer-readable medium of claim 8.
Satterlee further discloses wherein the security intent-based policies comprise at least one of organizational policies, departmental policies, and location-specific policies or a combination thereof (¶0009, “…Network policy management for enterprise networks (e.g., a network of a company or other type of entity) involves setting and implementing policies that determine how users and/or groups of users associated with a corresponding enterprise are able to utilize the enterprise network and/or network devices accessible via the enterprise network. The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments…”), (¶021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules…”).
Regarding claim 15, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer-implemented method of claim 14.
Satterlee further discloses wherein the security intent-based policies comprise at least one of organizational policies, departmental policies, and location-specific policies or a combination thereof (¶0009, “…Network policy management for enterprise networks (e.g., a network of a company or other type of entity) involves setting and implementing policies that determine how users and/or groups of users associated with a corresponding enterprise are able to utilize the enterprise network and/or network devices accessible via the enterprise network. The network policies include rules and/or settings that define, for example, bandwidth restrictions and/or guarantees, prioritization, access control, closed user group assignments…”), (¶021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules…”).
Regarding claim 9, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the non-transitory computer-readable medium of claim 8.
Satterlee further discloses wherein automatically deriving user role-specific policies comprises:
breaking down the security intent-based policies into user role-specific sub-policies (¶0037, FIG. 6A, “The example policy manager 200 of FIG. 2 provides an interface to facilitate creation of one or more network policies by, for example, the entity associated with the enterprise network 104 (block 602). For example, the policy manager 200 of FIG. 2 presents options and/or data entry fields to receive information to define particular aspect(s) of the network policies, such as data flow restrictions and/or guarantees, application restrictions, prioritization information, etc. Further, the example policy manager 200 presents options and/or data entry fields to receive information indicative of circumstances for which each network policy is to be selected for enforcement. Example circumstances include a particular user accessing the enterprise network 104, a location from which the enterprise network 104 is being accessed, an identity of a computing device being used to access the enterprise network 104, and a type of computing device being used to access the enterprise network 104. The example policy creator 200 of FIG. 2 uses the received information to generate the network policies and to designate the individual network policies for use in the corresponding circumstances (block 604)…”); and
combining the user role-specific sub-policies (¶0010, “…Examples disclosed herein use
any one of the circumstances associated with the access of the network and/or a combination of the circumstances associated with the access of the network to, in real-time or substantially real-time, select the appropriate network policy…”), (¶0022, “…Additional or alternative combinations of circumstances can be used to designate which one of the policies 202 is to be enforced for a particular network session. In some examples, the one or more of the network policies 202 of FIG. 2 are bound to the user 118 and are enforced against the user 118 wherever and/or however the user 118 accesses the enterprise network 104.”)
Chandrashekhar further discloses combining the user role-specific sub-policies according
to the global policy order (Coln.27, lines 56-63, “… some domains are specific to a single physical site, and are referred to as locations. This type of domain acts as the container for all site-wide and site-specific configuration and policies. In some embodiments, a location domain is automatically created for each physical site in the federated logical network, and cannot be modified by the user.”), (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.27, lines 27-40, “… in FIG. 17, there are nodes for site A 1760, site B 1777, and site C 1765 under the global root 1702. Each site has an enforcement point child node, under which specific resources are assigned, such as edge clusters, transport zones, etc. In the example, site A's edge cluster 1751 has incoming references from locale services 1735 attached to router T0 1705 and from locale services 1750 attached to router T1B 1715. The edge cluster 1752 at site B 1777 has an incoming reference from the locale services 1740 attached to router T0 1705. In some embodiments, edge clusters also have children corresponding to edge nodes 1753, which actually execute the services such as firewalls, DHCP, etc.”), (Coln.34, lines 39-67-Coln. 35, lines 1-20, “The match-action table 2300 has multiple flow entries 2305-2315 each specifying different service rules…These service operations include load-balancing, firewall, Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and other
services.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include combination of role specific policies according to global policy as disclosed by Chandrashekhar and be motivated in doing so in order to have a coherent framework and ensuring consistent application of the policies across diverse roles.
Regarding claim 16, Satterlee in view of Chandrashekhar and further in view of Boreham discloses the computer-implemented method of claim 14.
Satterlee further discloses wherein automatically deriving user role-specific policies comprises:
breaking down the security intent-based policies into user role-specific sub-policies (¶0037, FIG. 6A, “The example policy manager 200 of FIG. 2 provides an interface to facilitate creation of one or more network policies by, for example, the entity associated with the enterprise network 104 (block 602). For example, the policy manager 200 of FIG. 2 presents options and/or data entry fields to receive information to define particular aspect(s) of the network policies, such as data flow restrictions and/or guarantees, application restrictions, prioritization information, etc. Further, the example policy manager 200 presents options and/or data entry fields to receive information indicative of circumstances for which each network policy is to be selected for enforcement. Example circumstances include a particular user accessing the enterprise network 104, a location from which the enterprise network 104 is being accessed, an identity of a computing device being used to access the enterprise network 104, and a type of computing device being used to access the enterprise network 104. The example policy creator 200 of FIG. 2 uses the received information to generate the network policies and to designate the individual network policies for use in the corresponding circumstances (block 604)…”); and
combining the user role-specific sub-policies (¶0010, “…Examples disclosed herein use
any one of the circumstances associated with the access of the network and/or a combination of the circumstances associated with the access of the network to, in real-time or substantially real-time, select the appropriate network policy…”), (¶0022, “…Additional or alternative combinations of circumstances can be used to designate which one of the policies 202 is to be enforced for a particular network session. In some examples, the one or more of the network policies 202 of FIG. 2 are bound to the user 118 and are enforced against the user 118 wherever and/or however the user 118 accesses the enterprise network 104.”), and
Chandrashekhar further discloses combining the user role-specific sub-policies according
to the global policy order (Coln.27, lines 56-63, “… some domains are specific to a single physical site, and are referred to as locations. This type of domain acts as the container for all site-wide and site-specific configuration and policies. In some embodiments, a location domain is automatically created for each physical site in the federated logical network, and cannot be modified by the user.”), (Coln.38, lines 31-51, “The desired configuration of the logical network represents the intentions of the user (e.g., the administrator). The user specifies their intent by specifying the desired configuration, which is why the desired configuration is also referred to as user intent. The global manager 420 is an intent-based policy manager that receives user intent (internally represented as the global policy tree 1700) and communicates that intent to the local managers at each site. The local managers then interpret the received user intent to generate configuration data, and provide the configuration data to the network managers and controllers as described above to implement the desired configuration…”), (Coln.27, lines 27-40, “… in FIG. 17, there are nodes for site A 1760, site B 1777, and site C 1765 under the global root 1702. Each site has an enforcement point child node, under which specific resources are assigned, such as edge clusters, transport zones, etc. In the example, site A's edge cluster 1751 has incoming references from locale services 1735 attached to router T0 1705 and from locale services 1750 attached to router T1B 1715. The edge cluster 1752 at site B 1777 has an incoming reference from the locale services 1740 attached to router T0 1705. In some embodiments, edge clusters also have children corresponding to edge nodes 1753, which actually execute the services such as firewalls, DHCP, etc.”), (Coln.34, lines 39-67-Coln. 35, lines 1-20, “The match-action table 2300 has multiple flow entries 2305-2315 each specifying different service rules…These service operations include load-balancing, firewall, Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and other
services.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Satterlee, Chandrashekhar, and Boreham to include combination of role specific policies according to global policy as disclosed by Chandrashekhar and be motivated in doing so in order to have a coherent framework and ensuring consistent application of the policies across diverse roles.
Regarding claim 19, Satterlee in view of Chandrashekhar and further in view of
Boreham discloses the computer-implemented method of claim 14.
Satterlee further discloses wherein the user role applicability information comprise information associating specific security intent-based policies with network locations, network device types, or a combination thereof (¶0021, “…Example aspects and/or capabilities of the policies created via the example policy creator 200 of FIG. 2 include user-specific rules, location-specific rules, user role-specific rules, user group-specific rules, device-specific rules, device type-specific rules, traffic prioritization for specific users, categorization of application traffic with different class of service (CoS) values, geography based limitations of network access, geography independent network access from enterprise sites, ability to deny access to particular applications and/or resources of the enterprise network 104, restrictions based on an amount of data flowing towards a user, restrictions based on an amount of data flowing towards a user from specific applications and/or resources of the enterprise network 104, threat detection such as alarms or notifications of abnormal activity on a per user basis (which may be supplemented with contextual information such as device type, device identification, user identification, etc.), an ability to prevent threats by, for example, dropping the user access in response to a qualifying threat detection event, an ability to mimic or duplicate traffic flow characteristics of another network element, etc …”), (¶0037, “…Example circumstances include a particular user accessing the enterprise network 104, a location from which the enterprise network 104 is being accessed, an identity of a computing device being used to access the enterprise network 104, and a type of computing device being used to access the enterprise network 104. The example policy creator 200 of FIG. 2 uses the received information to generate the network policies and to designate the individual network policies for use in the corresponding circumstances (block 604)…”).
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 MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights