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 .
Response to Arguments
In the remarks filed on 12/23/2025. The applicant amended claims 1, 8, and 15 are amended. No claims were added.
With respect to 35 U.S.C. §102 and 103 rejections:
Applicant's arguments filed on 12/23/2025 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 12-18, with respect to the rejection (s) of independent claims 1, 8, and 15 have been fully considered.
Applicant argues that the combination of Leung and Ramaswamy fails to teach or suggest “capabilities are inferred based on patterns of enforcement related events indicated in the log data” and asserts that Leung merely discloses preconfigured enforcement capabilities while logs are generated only as byproduct of enforcement. Examiner understand applicant’s perspective; however, this argument is not persuasive. Under BRI, the recited “inferring” of capabilities encompasses determining or identifying device capabilities based on observed enforcement related events reflected in log data. Leung discloses security appliances that enforce policies and generate logs corresponding to enforcement related events,[0039], [0043]. Under BRI, such logs inherently reflect the operational behavior of the devices from which POSITA would reasonably determine the capabilities of those device. Further, Ramaswamy discloses analyzing network operation and assigning functional roles to network nodes within an SDN WAN environment (Ramaswamy, Abstract; Figs 1-3) which supports determining device roles and functions based in network behavior. Examiner acknowledge Leung and Ramaswamy does not explicitly teaches “the capabilities are inferred based on patterns of enforcement-related events indicated in the log data” but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1- 4, 8 - 11 and 15 - 19 are rejected under 35 U.S.C. 103 as being unpatentable over Leung (US 20180352004 A1) in view of Ramaswamy (US 20220353182 A1) in further view of Hume (US 20200127893 A1).
Regarding claim 1, Leung teaches a method comprising:
receiving, at a network controller of a network, log data from network devices of the network, the log data indicating events occurring with respect to network traffic at the network devices in the network (Leung, FIG. 1, network traffic is monitored at a firewall 100. network traffic is monitored using a data appliance (e.g., a data appliance that includes security functions, such as a security appliance that includes a firewall), using a gateway (e.g., a gateway that includes security functions, such as a security gateway), using a host (e.g., security software executed on a host device, such as a network server or client computing device, such as a personal computer, laptop, tablet, or smart phone), using in-line monitoring techniques…the network traffic is collected and/or monitored (e.g., some of the network traffic can be monitored using in-line monitoring techniques and/or some of the network traffic can be collected and analyzed for monitoring the network traffic offline, such as in logs of network traffic), [0039] firewall 100 also includes a content-ID engine (not shown), and, in some embodiments, the content-ID engine's identified content is also used by report and enforce policy engine 120, possibly in various combinations with other information, such as application, user, and HIP report (e.g., that matches one or more host information profiles), to enforce various security/firewall policies/rules, [0043]) [Examiner interprets that system monitoring and recoding traffic flows, and events at a firewall/gateway which contains device generated log/events such as user ID app ID, sessions pots signatures to enforce various security/firewall policies/rules as receiving log data from network devices of a network, the log data indicating events occurring with respect to network traffic at the network devices in the network];
determining, based at least in part on the log data, a plurality of data paths associated with the network devices in the network through which a plurality of source endpoints can communicate with a plurality of destination endpoints (Leung, Stateful firewalls can also perform stateful-based packet inspection in which each packet is examined within the context of a series of packets associated with that network transmission's flow of packets/packet flow (e.g., stateful firewalls or third generation firewalls)..it maintains records of all connections passing through the firewall and is able to determine whether a packet is the start of a new connection, a part of an existing connection, or is an invalid packet, [0024] Flow 408 identifies the packets as being part of a new session and creates a new session flow. Subsequent packets will be identified as belonging to the session based on a flow lookup. If applicable, SSL decryption is applied by SSL decrypter 410. Otherwise, processing by SSL decrypter 410 is omitted. application identification module 412 is configured to determine what type of traffic the session involves and to identify a user associated with the traffic flow…policy enforcement using host profile information is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows, [0056]) [Examiner interprets that firewall performing stateful inspection and building per session flows between endpoints (i.e., source and destination) describing actual, live communication routes from log/packet analysis collected in firewall/gateway as limitation above];
receiving role tags indicative of capabilities of the network devices for implementing operations associated with an intent-based security policy to the network traffic in the network and location tags indicative of hierarchical logical network relationships of the network devices in the network (Leung, a HIP report is an XML file that includes information about the client device (e.g., IP address, user name, domain, security software and data file status for current signature updates, operating system (OS) type and version, OS patch level, encryption enabled status, register information, and/or other hardware or software information regarding the client device). For example, certain network access can be limited or restricted based on an application identification, a user name, and a HIP report (e.g., that matches one or more host information profiles), [0030] the host information profile report includes device hardware information, device software information…device location information, in which the device location information includes information for identifying whether the client device is in a trusted zone or an untrusted zone, [0033] different security policies or different security rules are applied based on HIP information as well as based on zone information, such as trusted and untrusted zones. For example, location information, such as whether the client device is inside or outside of the firewall or inside or outside of the enterprise network can be used to determine whether the client device is in a trusted zone or untrusted zone. Also, whether the client device is using inside trusted ports or outside untrusted ports, whether the client device is tunneling into the enterprise network using a secure VPN from home/offsite location into an enterprise computer using a secure enterprise gateway, and/or various other criteria can be used to determine whether or not the client device is operating in a trusted or untrusted zone, [0052]) [Examiner interprets that HIP reports the device’s capabilities and state such as OS patch level , AV presence, encryption enabled, running process (i.e., role tags) and same KHP reports carrying location/zone information such as trusted /untrusted, inside/outside enterprise, remote VPN site (i.e., location tags) defining different access, zones for different devices (i.e., logical relationship) as limitation above];
generating, based at least in part on the log data, the role tags, and the location tags, an inventory of enforcement points at which to apply the intent-based security policy to the network traffic, the inventory of enforcement points comprising groupings of the network devices and indications of the capabilities of the network devices within the groupings based at least in part on the hierarchical logical network relationships of the network devices (Leung, FIG. 2 for policy enforcement using host profile. device 202 includes a firewall 212, as shown. In some embodiments, one or more of the client devices 204A-204C includes a firewall 214 (e.g., host-based firewall), [0045] HIP reports 418 for client devices are received and stored in the management plane 402. ..policy enforcement using host profile information is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows. In some embodiments, decoder 414 can also enforce policies 416 provided by management plane 402, including those applicable based on policy enforcement using host profile information, [0056] client device 602 can connect to one of three enterprise gateways 604A, 604B, or 604C, the portal 606 provides a central configuration repository for the enterprise client devices, [0063] The policies view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action)..a network administrator or security administrator can view/configure rules/policies using HIP profile information and/or other criteria/information (e.g., application and user) using the portal, [0065]) [Examiner interprets that system maintaining in the management plane a concrete set of enforcement location such as enterprise gateways, security appliances, host based firewalls, configured zones (i.e., the enforcement points) and the portal organizing them by groups such as zones, user groups, HIP objects and storing each group’s capabilities using HIP as limitation above]; and
mapping operations required by the intent-based security policy to the capabilities of the network devices based at least in part on the inventory of enforcement points (Leung, firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify or log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, [0021] policy enforcement using host profile information further includes determining the security policy based on a host information profile that matches the host information profile (HIP) report, an identified application, and an identified user name, [0029] report and enforce policies engine 120 determines whether a current HIP report for a client matches one or more host information profiles (e.g., configured by a network or security administrator) to determine whether one or more enforcement rules and/or reporting rules should be applied to client's monitored network traffic flow(s), [0042] The policies view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action), [0065] Fig 12, policy enforcement using host profile information. At 1202, HIP reports are received. At 1204, network traffic is monitored to/from client devices. At 1206, a HIP report for a client device is determined. At 1208, a security policy is enforced for network access based on the HIP report (e.g., matching one or more host information profiles). At 1210, access permission is denied to a corporate resource based on the HIP report (e.g., matching one or more host information profiles), [0071]) [Examiner interprets that enforcing policies by matching HIP profiles of device, apps, and User (i.e., capabilities of the network devices) and applying operation such as allow, deny, monitor, notify at specific enforcement points such as gateway, firewall, host firewall based on HIP information as limitation above].
Although Leung teaches HIP reports the device’s capabilities and state such as OS patch level , AV presence, encryption enabled, running process, Inside/outside trusted/untrusted client devices (i.e., role tags), however, in light of specification, Leung does not explicitly teach receiving role tags may indicate that a network device is configured as a campus edge firewall device, a virtual private network (VPN) termination device, a branch edge device, a data center edge device, a campus internal device, see instant spec [0019]:
receiving role tags indicative of capabilities of the network devices for implementing operations associated with an intent-based security policy to the network traffic in the network and location tags indicative of hierarchical logical network relationships of the network devices in the network; generating, based at least in part on the log data, the role tags, and the location tags, an inventory of enforcement points at which to apply the intent-based security policy to the network traffic, the inventory of enforcement points comprising groupings of the network devices and indications of the capabilities of the network devices within the groupings based at least in part on the hierarchical logical network relationships of the network devices, wherein the capabilities are inferred based on patterns of enforcement-related events indicated in the log data; mapping operations required by the intent-based security policy to the capabilities of the network devices based at least in part on the inventory of enforcement points
However, Ramaswamy teaches:
receiving role tags indicative of capabilities of the network devices for implementing operations associated with an intent-based security policy to the network traffic in the network and location tags indicative of hierarchical logical network relationships of the network devices in the network (Ramaswamy, the edge forwarding nodes associated with the SD-WAN can include an edge forwarding node associated with a branch site of the SD-WAN, a gateway forwarding node for a private datacenter, a multi-tenant gateway forwarding node associated with a public cloud, a multi-tenant gateway forwarding node associated with a SaaS provider cloud, and a hub forwarding node that provides connectivity between spoke edge forwarding nodes in the hub-and-spoke configuration of the SD-WAN, [0015] Examples of roles for SD-WAN devices include SD-WAN edge forwarding nodes, SD-WAN hub forwarding nodes, and SD-WAN gateway forwarding nodes. …an SD-WAN device's role can include a primary function and a secondary function, where the secondary function is either always there, or requested on demand. In some embodiments, these roles are based on context. For example, a controller or controller cluster in some embodiments can associate SD-WAN forwarding nodes with heuristic metrics, such as geolocation, number of paths to a hub, path metrics, etc., [0032] The route records are generated by the controller based on routes identified in a routing graph (e.g., a routing-mesh topology model) generated by the controller that shows connections between forwarding nodes in the SD-WAN, [0006] The conditions and their associated threshold values are defined as policy-based routing (PBR) rules that are distributed to the forwarding nodes by the controller, according to some embodiments. In some embodiments, the forwarding nodes include metric generators for generating metrics to resolve these PBR rules and select alternate routes, [0007]) [Examiner interprets that SD-WAN identifying role labels such as edge-> hub -> gateway-> datacenter (hierarchy) for edge forwarding nodes (i.e., role tags) and creating routing graph for connecting edge forwarding nodes and defining policy-based routing (PBR) rules between nodes for implementing routing or operations as limitation above].
generating, based at least in part on the log data, the role tags, and the location tags, an inventory of enforcement points at which to apply the intent-based security policy to the network traffic, the inventory of enforcement points comprising groupings of the network devices and indications of the capabilities of the network devices within the groupings based at least in part on the hierarchical logical network relationships of the network devices (Ramaswamy, The route records, in some embodiments, are generated by the controller based on routes identified in a routing graph (e.g., a routing-mesh topology model) generated by the controller that shows connections between forwarding nodes in the SD-WAN, [0006] The conditions, in some embodiments, relate to a degraded operating state of hub forwarding nodes (i.e., transit nodes) and are associated with specified threshold values…. The conditions and their associated threshold values are defined as policy-based routing (PBR) rules that are distributed to the forwarding nodes by the controller, [0007] an SD-WAN device's role can include a primary function and a secondary function, where the secondary function is either always there, or requested on demand. In some embodiments, these roles are based on context. For example, a controller or controller cluster in some embodiments can associate SD-WAN forwarding nodes with heuristic metrics, such as geolocation, number of paths to a hub, path metrics, etc., [0032] The controller analyzes the routing graph…and determines that a particular spoke edge should serve as a hub…then instructs the particular spoke edge… to serve as a hub and instructs the group to use it as a hub, [0064-0066] the controller also sends with the route records a list of nodes identified in the routing graph as nodes that can serve as hubs to the forwarding nodes in the SD-WAN, [0067]) [Examiner interprets that controller generating a list of nodes identified in the routing graph as nodes that can serve as hubs in the SD-WAN (i.e., inventory or grouping of devices with stated capabilities such as hub/edge roles) which are derived from metrics/log, roles, locations and topology (i.e., routing graph) as limitation above];
mapping operations required by the intent-based security policy to the capabilities of the network devices based at least in part on the inventory of enforcement points (Ramaswamy, The conditions and their associated threshold values are defined as policy-based routing (PBR) rules that are distributed to the forwarding nodes by the controller, according to some embodiments. In some embodiments, the forwarding nodes include metric generators for generating metrics to resolve these PBR rules and select alternate routes, [0007] the controller cluster 140 also provides service rules to edge forwarding nodes that can serve as hub forwarding nodes, in some embodiments, in order to enable these nodes, or service engines used by these nodes, to perform service operations on the packets that are to be performed by the hub forwarding node., [0044] The edge forwarding node identifies PBR rules …and selects one of the next hops….forwards the packet along the selected next hop, [0055-0056] The controller analyzes the routing graph…and determines that a particular spoke edge should serve as a hub…then instructs the particular spoke edge… to serve as a hub and instructs the group to use it as a hub, [0064-0066]) [Examiner interprets that controller mapping actions (i.e., PBR/service rules as policy operations) to specific nodes with capabilities such as hub roles, service engine once the controller has designated hub (i.e., the inventory of enforcement points) and routing packets through those points according to rules as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Leung to include a concept of receiving role tags indicative of capabilities of the network devices for implementing operations associated with an intent-based security policy to the network traffic in the network and location tags indicative of hierarchical logical network relationships of the network devices in the network; generating, based at least in part on the log data, the role tags, and the location tags, an inventory of enforcement points at which to apply the intent-based security policy to the network traffic, the inventory of enforcement points comprising groupings of the network devices and indications of the capabilities of the network devices within the groupings based at least in part on the hierarchical logical network relationships of the network devices, wherein the capabilities are inferred based on patterns of enforcement-related events indicated in the log data; mapping operations required by the intent-based security policy to the capabilities of the network devices based at least in part on the inventory of enforcement points as taught by Ramaswamy for the purpose of generating by the controller based on routes identified in a routing graph (e.g., a routing-mesh topology model) generated by the controller that shows connections between forwarding nodes in the SD-WAN [Ramaswamy:0006] and facilitating a communications session between another edge forwarding node in the first SD-WAN and an edge forwarding node in a second SD-WAN, [Ramaswamy:0026].
Leung and Ramaswamy does not explicitly teach:
wherein the capabilities are inferred based on patterns of enforcement-related events indicated in the log data
However, Hume teaches:
the capabilities are inferred based on patterns of enforcement-related events indicated in the log data (Hume, A security information and event manager is configured to receive log data from third party devices connected to a network, An access control list is generated for each third party device, by using the inferred information over the predetermined period [0012] techniques for inferring device configurations based on event and flow data collected by a SIEM, [0018] A good portion of this information can be inferred based on the events and flows that are monitored by the SIEM software. This inferred information could be used to, for example, infer device configurations and provide much of the same functionality as the current systems provide..[0019] Once configured, the SIEM gets notified every time that specific device allows/denies/blocks/etc., traffic that it sees, step 104, [0022] The Risk Manager module can then from the received messages infer network topology information, step 106. The inferred information can include, for example: Device Type (via log source configuration, based on the manual/automatic log source configuration stored in the SIEM) … Event type: Deny Source IP and port: 10.1.120.50:500 Destination IP and port: 222.277.277.277:500, [0024-0035] the more information the Risk Manager module receives over time, the more detailed information is obtained about the device's configuration, [0036] The firewall administrator then changes the rule to “DENY from to Port 550-600.” The system detects this configuration change, notifies the SIEM administrator, and starts to adjust the inferred rule from this from “ALLOW from IP-A to IP-B Port 500-600” to “ALLOW from IP-A to IP-B Port 500-549” and “DENY from IP-A to IP-B Port 550-600.” This is done automatically and does not require the SIEM to base the rules on anything by observed behavior of the device, [0041]) [Examiner interprets that system receiving log data from network devices that includes enforcement related events such as allowing, denying, or blocking traffic, analyzing these events overtime, identifying patterns such as repeated events across ports and changes in behavior , the system inferring device configurations an d generating access control rules reflecting the behavior of the devices based on the observed patterns as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Leung and Ramaswamy to include a concept the capabilities are inferred based on patterns of enforcement-related events indicated in the log data as taught by Hume for the purpose of inferring device behavior analyzed allow/deny/block events overtime for automated inference of device configuration and rule behavior without requiring direct access to the devices, [Hume: 0018-0020, 0036, 0041-0043].
Regarding claim 2, Leung, Ramaswamy, and Hume teaches the method of claim 1, wherein the log data is log data received at a first time (Leung, network traffic is monitored using a data appliance (e.g., a data appliance that includes security functions, such as a security appliance that includes a firewall), using a gateway (e.g., a gateway that includes security functions, such as a security gateway), using a host (e.g., security software executed on a host device, such as a network server or client computing device, such as a personal computer, laptop, tablet, or smart phone), using in-line monitoring techniques. The network traffic is collected and/or monitored (e.g., some of the network traffic can be monitored using in-line monitoring techniques and/or some of the network traffic can be collected and analyzed for monitoring the network traffic offline, such as in logs of network traffic), [0039] agents on client devices report new or updated HIP reports to the gateway (e.g., data appliance or security appliance) that it has a new or updated HIP report by sending a HIP check message to the gateway. For example, the HIP check message can be sent to the gateway periodically (e.g., about once per hour) or upon a change to the HIP report information. The gateway can respond to the HIP check message by indicating whether the new or updated HIP report should be sent to the gateway, [0049]) [Examiner interprets that system recording traffic/HIP state periodically (e.g., about once per hour) (i.e., timed receipt of data) as the log data is log data received at a first time], and the method further comprising:
identifying, based at least in part the intent-based security policy, a first event associated with the network traffic that is expected to occur at a first enforcement point of the inventory of enforcement points at a second time that is subsequent to the first time (Leung, HIP reports from client devices can be provided (e.g., pushed, pulled, or collected) periodically, based upon an event, and/or in response to a request. The results of the various traffic monitoring techniques using known protocol decoder engine 112, identified traffic engine 114, and unknown protocol decoder engine 116 described above are provided to report and enforce policies engine 120 (e.g., network/routing policies, security policies, and/or firewall policies). For example, firewall policies can be applied to the monitored network traffic using application identification, user identification, and HIP reports (e.g., matching one or more host information profiles), as described herein with respect to various embodiments. In some embodiments, report and enforce policies engine 120 determines whether a current HIP report for a client matches one or more host information profiles (e.g., configured by a network or security administrator) to determine whether one or more enforcement rules and/or reporting rules should be applied to client's monitored network traffic flow(s), [0042] applying a policy using a HIP profile can report which clients have disabled certain required or recommended remediation software (e.g., the remediation software was uninstalled or is not executing) ..a security policy can be configured to quarantine such client devices, block traffic from such client devices, report such client devices to a network/security administrator, notify the user of the client device of the out of policy configuration of the client device, and/or perform other responsive actions, [0066]) [Examiner interprets that system periodically collecting (e.g., pushed, pulled or scheduled) HIP reports after initial time, and using these reports to identify network events, and to evaluate against security policies as limitation above; periodic collection establishes the “second time subsequent to the first time”];
receiving second log data from the network devices at a third time that is subsequent to the second time, the second log data indicating the events occurring with respect to the network traffic at the network devices in the network (Leung, the network traffic is collected and/or monitored (e.g., some of the network traffic can be monitored using in-line monitoring techniques and/or some of the network traffic can be collected and analyzed for monitoring the network traffic offline, such as in logs of network traffic), [0039] agents on client devices report new or updated HIP reports to the gateway (e.g., data appliance or security appliance) that it has a new or updated HIP report by sending a HIP check message to the gateway. For example, the HIP check message can be sent to the gateway periodically (e.g., about once per hour) or upon a change to the HIP report information. The gateway can respond to the HIP check message by indicating whether the new or updated HIP report should be sent to the gateway, [0049]) [Examiner interprets that agents on client devices sending new or updated HIP reports to a gateway on a periodic basis (i.e., about once per hour); these later HIP reports (i.e. second log data) is generated at a time after the earlier reports thus system’s periodic checking and updating log entries corresponds to limitation above];
determining, based at least in part on the second log data, that the first event is absent from the second log data (Leung, report and enforce policies engine 120 determines whether a current HIP report for a client matches one or more host information profiles (e.g., configured by a network or security administrator) to determine whether one or more enforcement rules and/or reporting rules should be applied to client's monitored network traffic flow(s), [0042] the firewall policy can be enforced based on installed software and configuration of the client device (e.g., a client agent detects installed software packages and patches for HIP reporting, which can be used as client system profiles for policy enforcement). Moreover, this approach protects corporate resources. For example, access permission can be based on HIP reports and host information profiles to prevent corporate confidential information from being accessed by potentially insecure hosts (e.g., users of client devices can be permitted or denied access to corporate resources based on the client device's condition and existing client security state), [0062] applying a policy using a HIP profile can report which clients have disabled certain required or recommended remediation software (e.g., the remediation software was uninstalled or is not executing) ..a security policy can be configured to quarantine such client devices, block traffic from such client devices, report such client devices to a network/security administrator, notify the user of the client device of the out of policy configuration of the client device, and/or perform other responsive actions, [0066]) [Examiner interprets that evaluating HIP reports (i.e., log data) against expected security policies to determine whether required events (i.e. execution of remediation software) are absent and based on detection on potential policy implications triggering responsive actions such as quarantining device, blocking traffic, or notifying an administer as limitation above];and
updating the inventory of enforcement points to replace the first enforcement point with a second enforcement point (Leung, the agent will maintain the secure tunnel connection with the gateway and automatically re-establish the secure tunnel connection, if needed (e.g., which may or may not be with the same previously selected gateway, such as if the previously selected gateway becomes unavailable or too busy). At 1306, the client sends the HIP report for the client to the selected gateway. At 1310, network traffic is monitored to/from the client device at the gateway to which the client device is connected (e.g., using a secure tunnel connection between the client device and the gateway). At 1312, a security policy is enforced at the gateway for network access for the client based on the host information profile report for the client (e.g., matching one or more host information profiles), [0072]) [Examiner interprets that system replacing a first gateway with the second gateway when the initial gateway becomes unavailable or overloaded, then agent automatically reestablishing a secure tunnel connection with the newly selected gateway, which then receives HIP reports from the client and enforcing security policies on the monitored network traffic as updating the inventory of enforcement points to replace the first enforcement point with a second enforcement point].
Regarding claim 3, Leung, Ramaswamy, and Hume teaches the method of claim 1, wherein the logical network relationships indicate, for an individual network device of the network devices in the network, a first physical location of the individual network device, second physical locations encompassing the first physical location, and third physical locations encompassed by the first physical location (Leung, location information, such as whether the client device is inside or outside of the firewall or inside or outside of the enterprise network can be used to determine whether the client device is in a trusted zone or untrusted zone. Also, whether the client device is using inside trusted ports or outside untrusted ports, whether the client device is tunneling into the enterprise network using a secure VPN from home/offsite location into an enterprise computer using a secure enterprise gateway, and/or various other criteria can be used to determine whether or not the client device is operating in a trusted or untrusted zone, [0052] a common architecture for policy enforcement for client devices outside of the secured enterprise network. Client devices can be located and are operating within an enterprise secured network environment 502. Client devices accessing the Internet 506 and various web sites or web services (e.g., Microsoft Office Online®, SalesForce.com®, Apps.gov, Google® search and/or services, Facebook®, Skype®, and various other online resources) available via the Internet do so through the security infrastructure of the enterprise security network, such as through the enterprise firewall/security appliance, [0057] corporate and enterprise users are increasingly working remote (e.g., working from a home office and/or working while traveling). Generally, client devices accessing the Internet when the devices are not accessing the Internet through the enterprise secured environment are not as protected, as they are more open to various types of security threats. As shown at 504, client devices can access the Internet from a hotel, home office, airport, and/or other remote/outside of the enterprise secured environment, [0058] the client device can log into the portal and retrieve the latest configuration. From the configuration, it locates a preferred gateway (e.g., based on geography, work load, user group, device type, and/or other criteria) to connect to and establishes a secure tunnel to the gateway (e.g., using either SSL or IPsec), [0064]) [Examiner interprets that system using location information of client device to define logical network relationships across multiple levels such as a client’s device immediate position (i.e., inside or outside the firewall) as first location, network zones such as trusted vs untrusted zones (i.e., second location) encompassing the first and additional remote access points such as hotel, home office or airport connections (i.e., as third location’s) as limitation above].
Regarding claim 4, Leung, Ramaswamy, and Hume teaches the method of claim 1, wherein the inventory of enforcement points is a first inventory of enforcement points, and the method further comprising:
receiving an indication that a new network device is associated with the network, the indication including a first tag indicating a role associated with the new network device and a second tag indicating a logical network relationship of the new network device in the network; generating a second inventory of enforcement points based at least in part on the new network device; and mapping the role associated with the new network device to the second inventory of the enforcement points (Leung, the HIP agent uses standard techniques to call an API from each hardware/software OS/application vendor (e.g., OPSWAT API for collecting HIP information) that allows for secure querying of hardware/software information of client devices, [0048] agents on client devices report new or updated HIP reports to the gateway (e.g., data appliance or security appliance) that it has a new or updated HIP report by sending a HIP check message to the gateway. For example, the HIP check message can be sent to the gateway periodically (e.g., about once per hour) or upon a change to the HIP report information. The gateway can respond to the HIP check message by indicating whether the new or updated HIP report should be sent to the gateway, [0049] the host information profile report includes device hardware information, device software information…device location information, in which the device location information includes information for identifying whether the client device is in a trusted zone or an untrusted zone, [0033] FIG. 4 is a functional diagram of logical components of a data appliance for policy enforcement using host profile information in accordance with some embodiments. The example shown is a representation of logical components that can be included in data appliance 202. As shown, data appliance 202 includes a management plane 403 and a data plane 404. In some embodiments, the management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling, [0055] client device 602 can connect to one of three enterprise gateways 604A, 604B, or 604C. the portal 606 provides a central configuration repository for the enterprise client devices. In some embodiments, a client device agent executes on the client device (e.g., Global Protect software provided by Palo Alto Networks, Inc., which can be executed on, for example, a Microsoft Windows® OS) to establish and maintain a secure communication technique with a selected gateway (e.g., using SSL or IPsec to establish a secure tunnel between the client device with selected gateway 604A, 604B, or 604C) to force all outbound traffic to be inspected by the selected gateway (e.g., a security appliance or other security gateway device provided by the enterprise secured environment), [0063]) [Examiner interprets that agents on client device generating HIP reports including device hardware, software, and location information which serve as indication of the client device and its role, then system receiving such indications and incorporating them into gateway management functions, and gateway and associated data appliance updating policy enforcement and configuration repositories (i.e., second inventory) as limitation above].
Regarding claim 8 and 15, Claims 8 and 15 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except for the additional elements:
Leung further teaches:
One or more non-transitory computer-readable media storing instructions executable by a processor, wherein the instructions, when executed, cause the processor to perform operations (Leung, a computer program product embodied on a computer readable storage medium…, [0018]) comprising:
Regarding claim 9, Leung, Ramaswamy, and Hume teaches the one or more non-transitory computer-readable media of claim 8, the operations (Leung, a computer program product embodied on a computer readable storage medium…, [0018]) further comprising:
receiving indications of roles associated with the network devices in the network; and mapping the roles associated with the network devices to the inventory of enforcement points wherein generating the logical topology of the network is based at least in part on mapping the roles associated with the network devices to the inventory of enforcement points (Leung, a HIP report is an XML file that includes information about the client device (e.g., IP address, user name, domain, security software and data file status for current signature updates, operating system (OS) type and version, OS patch level, encryption enabled status, register information, and/or other hardware or software information regarding the client device). For example, certain network access can be limited or restricted based on an application identification, a user name, and a HIP report (e.g., that matches one or more host information profiles), [0030] the security device 202 includes a firewall 212, as shown. In some embodiments, one or more of the client devices 204A-204C includes a firewall 214 (e.g., host-based firewall), [0045] HIP reports 418 for client devices are received and stored in the management plane 402. In some embodiments, policy enforcement using host profile information is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows. In some embodiments, decoder 414 can also enforce policies 416 provided by management plane 402, including those applicable based on policy enforcement using host profile information, [0056] The policies view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action), [0065]) [Examiner interprets that system receiving HIP fields such as software/hardware information, encryption status etc., (i.e., roles and capabilities) for each device, enforcement points such as firewall/gateway receiving those HIP reports, and enforcing policies 416 at those enforcement points using management plane (i.e., map roles-> enforcement locations/actions) and generating policy graph (i.e., logical topology) in the portal based on that mapping (i.e., HIP profile in the policy connections) as limitation above].
Although Leung teaches HIP reports the device’s capabilities and state such as OS patch level , AV presence, encryption enabled, running process, Inside/outside trusted/untrusted client devices (i.e., roles and capabilities), however, in light of specification, Leung does not explicitly teach receiving role tags may indicate that a network device is configured as a campus edge firewall device, a virtual private network (VPN) termination device, a branch edge device, a data center edge device, a campus internal device, see instant spec [0019]:
receiving indications of roles associated with the network devices in the network; and mapping the roles associated with the network devices to the inventory of enforcement points wherein generating the logical topology of the network is based at least in part on mapping the roles associated with the network devices to the inventory of enforcement points
However, Ramaswamy teaches:
receiving indications of roles associated with the network devices in the network; and mapping the roles associated with the network devices to the inventory of enforcement points wherein generating the logical topology of the network is based at least in part on mapping the roles associated with the network devices to the inventory of enforcement points (Ramaswamy, the edge forwarding nodes associated with the SD-WAN can include an edge forwarding node associated with a branch site of the SD-WAN, a gateway forwarding node for a private datacenter, a multi-tenant gateway forwarding node associated with a public cloud, a multi-tenant gateway forwarding node associated with a SaaS provider cloud, and a hub forwarding node that provides connectivity between spoke edge forwarding nodes in the hub-and-spoke configuration of the SD-WAN, [0015] Examples of roles for SD-WAN devices include SD-WAN edge forwarding nodes, SD-WAN hub forwarding nodes, and SD-WAN gateway forwarding nodes. …an SD-WAN device's role can include a primary function and a secondary function, where the secondary function is either always there, or requested on demand. In some embodiments, these roles are based on context. For example, a controller or controller cluster in some embodiments can associate SD-WAN forwarding nodes with heuristic metrics, such as geolocation, number of paths to a hub, path metrics, etc., [0032] The route records are generated by the controller based on routes identified in a routing graph (e.g., a routing-mesh topology model) generated by the controller that shows connections between forwarding nodes in the SD-WAN, [0006] The conditions and their associated threshold values are defined as policy-based routing (PBR) rules that are distributed to the forwarding nodes by the controller, according to some embodiments. In some embodiments, the forwarding nodes include metric generators for generating metrics to resolve these PBR rules and select alternate routes, [0007]) [Examiner interprets that SD-WAN identifying role labels such as edge, hub gateway for edge forwarding nodes (i.e., role tags) and creating routing graph for connecting edge forwarding nodes and defining policy-based routing (PBR) rules between nodes for implementing routing or operations as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Leung to include a concept of receiving indications of roles associated with the network devices in the network; and mapping the roles associated with the network devices to the inventory of enforcement points wherein generating the logical topology of the network is based at least in part on mapping the roles associated with the network devices to the inventory of enforcement points as taught by Ramaswamy for the purpose of generating by the controller based on routes identified in a routing graph (e.g., a routing-mesh topology model) generated by the controller that shows connections between forwarding nodes in the SD-WAN [Ramaswamy:0006] and facilitating a communications session between another edge forwarding node in the first SD-WAN and an edge forwarding node in a second SD-WAN, [Ramaswamy:0026].
Regarding claim 10 and 11, Claims 10 and 11 recite commensurate subject matter as claims 2 and 3 respectively. Therefore, they are rejected for the same reasons. Except additional elements:
Leung teaches:
One or more non-transitory computer-readable media storing instructions executable by a processor, wherein the instructions, when executed, cause the processor to perform operations (Leung, a computer program product embodied on a computer readable storage medium…, [0018])
Regarding claim 16, Claim 16 recites commensurate subject matter as claim 9, Therefore, they are rejected for the same reasons.
Regarding claims 17-19, Claims 17-19 recite commensurate subject matter as claims 4, 2, and 3 respectively. Therefore, they are rejected for the same reasons.
Claims 5 -7, 12-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Leung (US 20180352004 A1) in view of Ramaswamy (US 20220353182 A1) in further view of Hume (US 20200127893 A1) in further view of Miriyala (US 20230107891 A1).
Regarding claim 5, Leung, Ramaswamy, and Hume teaches the method of claim 1, further comprising:
generating a first logical topology of the network indicating the data paths, the network devices associated with the inventory of enforcement points, the roles associated with the network devices associated with the inventory of enforcement points, and the logical network relationships of the network devices associated with the inventory of enforcement points; generating a graphical user interface (GUI) configured to display on a computing device, the GUI including the first logical topology of the network (Leung, FIG. 4 is a functional diagram of logical components of a data appliance for policy enforcement using host profile information The example shown is a representation of logical components that can be included in data appliance 202. As shown, data appliance 202 includes a management plane 403 and a data plane 404. In some embodiments, the management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling, [0055] HIP reports 418 for client devices are received and stored in the management plane 402…policy enforcement using host profile information is applied based on the monitored, identified, and decoded session traffic flows…decoder 414 can also enforce policies 416 provided by management plane 402, including those applicable based on policy enforcement using host profile information, [0056] FIG. 7 is a screen shot illustrating a portal for policy enforcement using host profile information. As shown in the enterprise network portal screen shot 702, includes various tabs for different views are provided, such as a dashboard view, a monitor view, a policies view, an objects view (e.g., HIP objects), a network view, a device view, and various other views. The policies’ view is the shown view and selected tab, as shown in FIG. 7. The policies’ view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action). In some embodiments, an enterprise network portal provides a central configuration repository for the enterprise client devices. For example, a network administrator or security administrator can view/configure rules/policies using HIP profile information and/or other criteria/information (e.g., application and user) using the portal, [0065]) [Examiner interprets system generating a logical topology of the network using data appliance components in a management planes and data planes and representing this topology through the portal interface, thus portal providing graphical views such as dashboard, network, and device views (i.e., the display of the logical network topology, enforcement points, and associated roles) as limitation above]; and
Leung and Ramaswamy does not explicitly teach:
generating a graphical user interface (GUI) configured to display on a computing device, the GUI including the first logical topology of the network
However, Miriyala teach:
generating a graphical user interface (GUI) configured to display on a computing device, the GUI including the first logical topology of the network (Miriyala, network controller 24 present UI 60 (e.g., a graphical user interface, which may be denoted as GUI 60) by which to visualize the topology of the network and interactively define a VNR, such as VNR 52A, through various interactions with GUI 60. GUI 60 graphically present the topology of the network that may include various network elements (such as VNs 50A and 50N). A user may interface with GUI 60 to visually configure a VNR 52A to interconnect two or more network elements, [0105]).
Therefore, it would have been obvious to POSITA before the effective filing date to modify the teaching of Leung, Ramaswamy, and Hume to include a concept of generating a graphical user interface (GUI) configured to display on a computing device, the GUI including the first logical topology of the network as taught by Miriyala for the purpose of providing a user interface configured to graphically present a topology of a network that may include various network elements (such as virtual networks) and visually configure a VNR to interconnect two or more network elements [Miriyala:0011].
Regarding claim 6, Leung, Ramaswamy, Hume, and Miriyala further teaches the method of claim 5, wherein the GUI is further configured to receive an input from the computing device, and the method further comprising:
receiving, via the GUI, input data representing the input indicating a connection between at least a first network device of a first grouping of the groupings of the network devices and a second network device of a second grouping of the groupings of the network devices (Leung, FIG. 7 is a screen shot illustrating a portal for policy enforcement using host profile information. As shown in the enterprise network portal screen shot 702, includes various tabs for different views are provided, such as a dashboard view, a monitor view, a policies view, an objects view (e.g., HIP objects), a network view, a device view, and various other views. The policies’ view is the shown view and selected tab, as shown in FIG. 7. The policies’ view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action). In some embodiments, an enterprise network portal provides a central configuration repository for the enterprise client devices. For example, a network administrator or security administrator can view/configure rules/policies using HIP profile information and/or other criteria/information (e.g., application and user) using the portal, [0065]) [Examiner interprets that an enterprise network portal (i.e., GUI) allowing administrators to provide input through the interactive tabs, including network and device views and these inputs configure rules and policies by specifying source and destination device information, thereby representing a connection between a first network device and second network device within the groupings of network devices and GUI receiving input data indicating such connections];
generating, based at least in part on the input data, a second logical topology of the network indicating the data paths, the network devices associated with the inventory of enforcement points, the roles associated with the network devices associated with the inventory of enforcement points, the logical network relationships of the network devices associated with the inventory of enforcement points, and the connection: and causing the GUI to display the second logical topology of the network (Leung, FIG. 4 is a functional diagram of logical components of a data appliance for policy enforcement using host profile information The example shown is a representation of logical components that can be included in data appliance 202. As shown, data appliance 202 includes a management plane 403 and a data plane 404. In some embodiments, the management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling, [0055] HIP reports 418 for client devices are received and stored in the management plane 402…policy enforcement using host profile information is applied based on the monitored, identified, and decoded session traffic flows…decoder 414 can also enforce policies 416 provided by management plane 402, including those applicable based on policy enforcement using host profile information, [0056] FIG. 7 is a screen shot illustrating a portal for policy enforcement using host profile information. As shown in the enterprise network portal screen shot 702, includes various tabs for different views are provided, such as a dashboard view, a monitor view, a policies view, an objects view (e.g., HIP objects), a network view, a device view, and various other views. The policies’ view is the shown view and selected tab, as shown in FIG. 7. The policies’ view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action). In some embodiments, an enterprise network portal provides a central configuration repository for the enterprise client devices. For example, a network administrator or security administrator can view/configure rules/policies using HIP profile information and/or other criteria/information (e.g., application and user) using the portal, [0065]) [Examiner interprets that input data such as HIP reports and host profile information is processed by the data appliance management plane and data planes to generate logical views of the network, including device roles, connections and policy relationships and these views are presented in a GUI through an enterprise network portal which includes tabs such as network views and device views as limitation above].
Regarding claim 7, Leung, Ramaswamy, Hume, and Miriyala further teaches the method of claim 5, further comprising:
receiving indications of physical locations of the network devices in the networks (Leung, the host information profile report includes device location information, in which the device location information includes information for identifying whether the client device is in a trusted zone or an untrusted zone, [0033] different security policies or different security rules are applied based on HIP information as well as based on zone information, such as trusted and untrusted zones. For example, location information, such as whether the client device is inside or outside of the firewall or inside or outside of the enterprise network can be used to determine whether the client device is in a trusted zone or untrusted zone. Also, whether the client device is using inside trusted ports or outside untrusted ports, whether the client device is tunneling into the enterprise network using a secure VPN from home/offsite location into an enterprise computer using a secure enterprise gateway, and/or various other criteria can be used to determine whether or not the client device is operating in a trusted or untrusted zone, [0052] the client device can log into the portal and retrieve the latest configuration. From the configuration, it locates a preferred gateway (e.g., based on geography, work load, user group, device type, and/or other criteria) to connect to and establishes a secure tunnel to the gateway (e.g., using either SSL or IPsec), [0064]) [Examiner interprets that HIP reports including device location information and identifying whether client device resides in a trusted zone or untrusted zone such as being inside or outside of the firewall within or outside of enterprise network or connecting remotely via VPN also system accounting for physical/geographic criteria (e.g., geography, workload or device type) when selecting gateway as receiving indications of physical locations of the network devices in the networks];
determining, based at least in part on the roles associated with the network devices and the physical locations of the network devices, a connection between at least a first network device of a first grouping of the groupings of the network devices and a second network device of a second grouping of the groupings of the network devices (Leung, FIG. 6, client device 602 can connect to one of three enterprise gateways 604A, 604B, or 604C. In some embodiments, an enterprise network portal 606 is provided. In some embodiments, the portal 606 provides a central configuration repository for the enterprise client devices. In some embodiments, a client device agent executes on the client device (e.g., GlobalProtect software provided by Palo Alto Networks, Inc., which can be executed on, for example, a Microsoft Windows® OS) to establish and maintain a secure communication technique with a selected gateway (e.g., using SSL or IPsec to establish a secure tunnel between the client device with selected gateway 604A, 604B, or 604C) to force all outbound traffic to be inspected by the selected gateway (e.g., a security appliance or other security gateway device provided by the enterprise secured environment), [0063] the client device can log into the portal and retrieve the latest configuration. From the configuration, it locates a preferred gateway (e.g., based on geography, work load, user group, device type, and/or other criteria) to connect to and establishes a secure tunnel to the gateway (e.g., using either SSL or IPsec). In some embodiments, distributed gateway deployment for optimized user network access performance is provided. For example, the gateway can be selected based on a shortest response time to a query. After the secure tunnel is established, the client device sends the client's HIP report or HIP check message to the gateway (e.g., periodically, at a specified interval specified in a configuration file, after HIP report information changes, and/or based on various other criteria). In some embodiments, all traffic to/from the client device is routed through the secure gateway. In some embodiments, the client outbound traffic will be forwarded to the gateway for security inspection before it is forwarded/sent to the Internet, thus allowing the gateway to filter out all unwanted traffic from and to the client device. In some embodiments, all traffic from the client is communicated (e.g., securely, using SSL or IPSEC tunnels) to the gateway for policy control and threat scanning, in which the policy control and threat scanning are performed using the HIP report for the client device, [0064]) [Examiner interprets that system establishing a secure tunnel connection between devices in different grouping based on role (client vs enforcement gateway) location/geography and enterprise portal facilitating configuration, and HIP reports from the client further inform the connection as limitation above];
generating, based at least in part on determining the connection, a second logical topology of the network indicating the data paths. the network devices associated with the inventory of enforcement points, the roles associated with the network devices associated with the inventory of enforcement points, the logical network relationships of the network devices associated with the inventory of enforcement points, and the connection: and causing the GUI to display the second logical topology of the network (Leung, FIG. 4 is a functional diagram of logical components of a data appliance for policy enforcement using host profile information The example shown is a representation of logical components that can be included in data appliance 202. As shown, data appliance 202 includes a management plane 403 and a data plane 404. In some embodiments, the management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling, [0055] all traffic from the client is communicated (e.g., securely, using SSL or IPSEC tunnels) to the gateway for policy control and threat scanning, in which the policy control and threat scanning are performed using the HIP report for the client device, [0064] FIG. 7 is a screen shot illustrating a portal for policy enforcement using host profile information. As shown in the enterprise network portal screen shot 702, includes various tabs for different views are provided, such as a dashboard view, a monitor view, a policies view, an objects view (e.g., HIP objects), a network view, a device view, and various other views. The policies view is the shown view and selected tab, as shown in FIG. 7. The policies view shows policy information listed by policy name, including each policy's respective source information (e.g., zone, address, user, and HIP profile) and destination information (e.g., zone, application, service, and action). In some embodiments, an enterprise network portal provides a central configuration repository for the enterprise client devices. For example, a network administrator or security administrator can view/configure rules/policies using HIP profile information and/or other criteria/information (e.g., application and user) using the portal, [0065]) [Examiner interprets that system disclosing the logical network relationship and device connections such as client to gateway paths, roles and enforcement points) which are processed through the data appliance and represented through the management plane and displaying these logical topologies via enterprise network portal (i.e., GUI) providing multiple views such as network views and device views as limitation above].
Leung does not explicitly teach:
Topology update and causing the GUI to display the second logical topology of the network
However, Miriyala teaches:
Topology update and causing the GUI to display the second logical topology of the network (Miriyala, present a user interface, wherein the user interface is configured to: graphically represent a topology of a network supported by the software-defined networking (SDN) architecture system, the network including a first virtual network and a second virtual network; and dynamically generate a graphical element representative of a virtual network router by which to interconnect the first virtual network and the second virtual network, the virtual network router representing a logical abstraction of one or more policies that cause one or more of import and export of routing information between the first virtual network and the second virtual network, [0018] The user interface graphically represents the topology of the network by receive input from a user indicating a type of connectivity for the virtual network router; selecting a graphical icon associated with the type of connectivity for the virtual network router; and dynamically generating the graphical element that includes the graphical icon associated with the type of connectivity for the virtual network router [0395] and input from a user defines a first label associated with the first virtual network and a second label associated with the second virtual network (i.e. enforcement points), and identifies, based on the first label and the second label (roles) , the first virtual network and the second virtual network in order to configure a routing instance corresponding to the virtual network router, in accordance with the one or more policies, to cause the import and the export of the routing information between the first virtual network and the second virtual network (i.e. the logical network relationships of the network devices associated with the inventory of enforcement) , [0399]) [ Examiner interprets that dynamically generating updated topologies based on user input as the system can generate multiple topologies and display it through GUI]. The motivation applies same as claim 5.
Regarding claims 12-14, Claims 12-14 recite commensurate subject matter as claims 5-7. Therefore, they are rejected for the same reasons. Except additional elements:
Leung teaches:
One or more non-transitory computer-readable media (Leung, a computer program product embodied on a computer readable storage medium…, [0018])
Regarding claim 20, Leung, Ramaswamy, Hume, and Miriyala further teaches the method of claim 15, the method further comprising generating a graphical user interface (GUI) configured to display on a computing device, the GUI including the logical topology of the network (Miriyala, network controller 24 present UI 60 (e.g., a graphical user interface, which may be denoted as GUI 60) by which to visualize the topology of the network and interactively define a VNR, such as VNR 52A, through various interactions with GUI 60. GUI 60 graphically present the topology of the network that may include various network elements (such as VNs 50A and 50N). A user may interface with GUI 60 to visually configure a VNR 52A to interconnect two or more network elements, [0105])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10616258 B2: “generally relate to the field of network security techniques. In particular, various embodiments relate to security information and event management (SIEM) based on asset attributes of a network”
US 20200322361 A1: “relates to a technique for automatically inferring temporal relationship data for cybersecurity events”
US 9069930 B1: “directed to the field of security in data processing systems.”
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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436
Prosecution Insights