DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 103, 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.
Applicant argued in the remark that monitoring the firewall event comprises at least one of a firewall creation event, a firewall deletion event and a firewall update event; performing processing corresponding to the firewall event on the data stored in the OVN database according to the strategy route, and sending changed data in the data stored in the OVN database caused by performing processing corresponding to the firewall event on the data stored in the OVN database to OVN controllers located
on every compute node respectively.
Meng et al US 2021/0243159 discloses monitor the firewall event comprises at least one of a firewall creation event, a firewall deletion event and a firewall update event (0013 monitoring, and configuration services across layers of a network stack implemented on the intermediary device 131 0019 the firewall at the intermediary network device 269 updates the quarantine list of its control plane (i.e., the mapping structure with quarantine flag) and then the quarantine list in its data plane based on remote analysis identifying one or more compromised devices. And 0020 an intrusion detection or endpoint protection agent can identify a compromised device to local firewalls with a file write, database update, etc. At stage C2, the firewall at intermediary network device 267 locally communicates the control plane quarantine list update as update 207A to the firewalls , i.e. firewall eupdate event , at the intermediary network devices 265, 269. The firewalls at the intermediary network devices 265, 269 internally update their respective quarantine lists, wherein the firewall update on the intermediary network device that is being monitoring, as it can be seen in the par 0020 At stage C1, the firewall at the intermediary network device 267 updates the quarantine list of its control plane and then the quarantine list in its data plane based on local security analysis input, the analysis can be seen as the monitoring the firewall updates of quarantine list in the intermediary device, i.e. open virtual network database.). Meng also discloses performing processing corresponding to the firewall event on the data stored in the OVN database according to the strategy route (0013 The control plane 101 encompasses the hardware and program code for implementing routing protocols (e.g., route determination) and 0014 The control plane 101 communicates the quarantine list 115 to the data plane 105 for the data plane 105 to apply and wherein the quarantine list stored in the firewall at the intermediary device, i.e. the OVN. [0015] While the quarantine list 115 identifies devices to quarantine by IP addresses, the control plane 101 maintains a structure 102 that allows the quarantine list 115 to be adapted to the dynamic nature of IP assignments to devices ), and sending changed data in the data stored in the OVN database caused by performing processing corresponding to the firewall event on the data stored in the OVN database to OVN controllers located on every compute node respectively ( 0015 The control plane 102 updates, i.e. changed data the entry in the mapping structure 102 to reflect the currently assigned IP address for the laptop 125. Since the quarantine flag is set to “1” in the entry for the laptop 125, the control plane 101 disconnects the laptop 125 from the network associated with the intermediary network device 131 and expedites communicating the update to the data plane 105, 0016 Each of the intermediary network devices 265, 267, 269, 277, 279 includes control plane program code to maintain a mapping structure that maps transient network addresses to persistent device identifiers and communicate updates to either of the quarantine list or the mapping structure across the intermediary network devices 0026] At block 305, the control plane determines whether the device identifying value(s) is already indicated in a compromise state list. The control plane searches the compromise state list with each persistent device identifying value obtained for the connecting device. If no entry includes a matching persistent device identifying value, then flow continues to block 307. If an entry includes a matching persistent device identifying value, flow continues to block 309. For embodiments that map multiple persistent device identifying values (“persistent identifiers”), the control plane can add the additional persistent identifiers to the compromise state list entry if the entry in the compromise state list has some but not all the persistent device identifying values.
[0027] At block 307, the control plane inserts an entry into the compromise state list with the persistent identifier and the transient identifier. With the entry, the control associates or maps these identifiers together. For instance, the control plane can set the persistent identifier as a primary key or index into the compromise device list and the transient identifier as an associated identifier. The transient identifier is the network address assigned to the device for the current connection/session. The control plane also initializes the compromise flag to a value indicating that the device has not been determined to be compromised (e.g., set to 0). The flow ends after block 307.
[0028] If a match was found, then the control plane determines whether the matching persistent identifier maps to a different network address than the network address currently assigned for the connection, at block 309. After finding the entry in the compromise state list with the matching persistent identifier, the control plane compares the network address mapped to the persistent identifier in the compromise state list with the network address currently assigned to the device. If the network addresses match, then the flow ends.
[0029] If the network addresses do not match, then the control plane updates the entry at block 311. The control plane updates the entry with the currently assigned network address, thus mapping the current transient identifier to the persistent identifier.
[0030] At block 312, the control plane determines whether the device is marked as compromised in the compromise state list. If the device is marked as compromised, then flow continues to block 313. If not, then flow continues to block 315.
[0031] At block 313, the control plane updates a quarantine list in a data plane associated with the control plane. Since the device is flagged as compromised and a security policy has been configured to quarantine traffic of a compromised device, the control plane expeditiously updates the quarantine list with the current network address of the flagged device. The data plane applies the quarantine list to discard or quarantine packets that indicate the current network address in the packet header. The control plane can update the quarantine list or communicate the update to the data plane for the data plane to carry out the update. The update can be performed by overwriting the previous network address with the currently assigned network address; removing the previous network address and inserting the current network address; or outputting all of the transient identifiers in the compromise state list with the compromise flag set and replacing the current data plane quarantine list with this new listing.
[0038] At block 407, the control plane communicates the mapping update to security devices configured to enforce quarantining of compromised devices. The control plane communicates that the persistent device identifier previously associated with the cleared network address is no longer associated with the network address ).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 17 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 17 contains the trademark/trade name Neutron. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe in the above claim and specification and, accordingly, the identification/description is indefinite.
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.
Claim(s) 1, 11,13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shu Yindong CN 112769829A (English translation included ( hearafter Shu)) in view of Chandramouli et al US 12,401,622 in view of Meng et al US 2021/0243159.
As per claim 1. Shu discloses a method for defining a distributed firewall, comprising:
monitoring, by a firewall assembly (0067 SDN architecture includes a control node, and the control node includes an application layer interface), a firewall event in real time, and sending firewall configuration data corresponding to a currently monitored firewall event to an open virtual network (OVN) database ( par 0038 The IP address of the cloud physical machine and the firewall rules of the cloud physical machine are determined, i.e. monitoring, by the application layer interface, i.e. by a firewall assembly ; the IP address of the cloud physical machine and the firewall rules,. i.e. firewall configuration data, of the cloud physical machine are sent to the OVN centralized controller, i.e. OVN northbound database service, par 0039 the OVN centralized controller includes an OVN northbound database service, an OVN northd service, and an OVN southbound database service, the OVN northbound database service includes an OVN northbound database, and the OVN southbound database service includes an OVN southbound database and [n0041] A logical flow table generation unit is configured to generate a first logical flow table according to the IP address of the cloud physical machine by the OVN northd service, and send the first logical flow table to the OVN southbound database service, and store the first logical flow table in the OVN southbound database by the OVN southbound database service, wherein the first logical flow table includes the IP address of the cloud physical machine and the MAC address of the cloud physical machine; and generate a second logical flow table according to the firewall rules of the cloud physical machine by the OVN northd service, and send the second logical flow table to the OVN southbound database service, and store the second logical flow table in the OVN southbound database by the OVN southbound database service, wherein the second logical flow table includes the IP address of the cloud physical machine and the firewall rules of the cloud physical machine);
converting, by the OVN database, the firewall configuration data into a corresponding flow, performing processing corresponding to the firewall event on the data stored in the OVN database according to the strategy flow ( 0044 [n0044] The conversion unit is configured to convert the first logical flow table into the first OpenFlow flow table and convert the second logical flow table into the second OpenFlow flow table by the OVS centralized bridge and 0046 implements traffic screening based on the firewall rules, i.e. firewall configuration data, in the second OpenFlow flow table. 0042, the network node includes an OVN local controller, and the OpenFlow flow table generation unit and Centralized control: An OpenFlow controller communicates with OpenFlow switches to dictate how they should handle traffic. Flow tables: Each OpenFlow switch has one or more flow tables, which are like forwarding tables that contain flow entries. Flow entries: Each entry in a flow table is a rule that includes: A set of matching criteria (e.g., source/destination MAC address, IP address, or port number). A corresponding action (e.g., forward the packet to a specific port, drop the packet, or send it to the controller), and
sending changed data in the data stored in the OVN database caused by performing processing corresponding to the firewall event on the data stored in the OVN database to OVN controllers located on every computer node respectively( par 0051 the firewall rules of the cloud physical machine are determined and a second OpenFlow flow table is generated based on the firewall rules of the cloud physical machine. And 0051 firewalls can be set up for them based on the OpenFlow flow table,);
sending, by the OVN controller, the received data to an open v switch (OVS) daemon module on the compute node that the OVN controller is located ( 0059 the communication protocol between the controller and network devices (such as switches) mostly adopts the Openflow protocol and 0061 the SDN architecture, the commonly used SDN controller is the OVN (Open Virtual Network) controller, i.e. the OVN controller,, and the SDN switch is the OVS (Open vSwitch) switch. And 0069 the application layer interface can create a cloud physical port type of baremetel based on neutron-server (network management component), thereby determining the IP address of the cloud physical machine and the firewall rules of the cloud physical machine, and sending the IP address of the cloud physical machine and the firewall rules of the cloud physical machine to the OVN centralized controller , and storing, by the OVS daemon module, the received data in a memory to realize forwarding a message (0043 A logical flow table sending unit, configured to obtain, by the OVN local controller, the first logical flow table and the second logical flow table from the OVN southbound database, and send the first logical flow table and the second logical flow table to the OVS centralized bridge; and 0074 generating a second OpenFlow flow table based on the firewall rules of the cloud physical machine, the first OpenFlow flow table and the second OpenFlow flow table can be stored , i.e. storing, on the OVS centralized bridge, i.e. by the OVS daemon module. And 0062 forward the flow to the external network through the OVS centralized bridge and 0074 the OVS centralized bridge is bound to a physical network card, the physical network card can be connected to the cloud physical machine, receive data from the cloud physical machine, and forward it to the external network through the OVS centralized bridge. Therefore, in this application, after generating a first OpenFlow flow table based on the IP address of the cloud physical machine and generating a second OpenFlow flow table based on the firewall rules of the cloud physical machine, the first OpenFlow flow table and the second OpenFlow flow table can be stored on the OVS centralized bridge. In this way, it can be ensured that the OVS centralized bridge can determine the IP address of the cloud physical machine based on the first OpenFlow flow table, and then determine the IP address corresponding to the data, and determine the firewall rules of the cloud physical machine based on the second OpenFlow flow table, and determine whether the data is allowed to be sent to the external network based on the firewall rules and Packet processing: When a switch receives a packet, it checks its flow table to find a matching flow entry. If a match is found, the switch performs the associated action. If no match is found (a "table miss"), the switch can forward the packet to the controller to get instructions. The controller can then instruct the switch to add a new flow entry for subsequent packets with similar characteristics, so they don't need to be sent to the controller again).
Shu does not explicitly disclose firewall configuration data into a corresponding strategy route. Monitoring the firewall event comprises at least one of a firewall creation event, a firewall deletion event and a firewall update event
However, Chandramouli discloses firewall configuration data into a corresponding strategy route ( col 5, lines 35-67and col 6, lines 1-3 At block 210, route information for the discovered resources for each respective firewall for specified IVN and/or subnets for specified traffic is determined, by FW route manager 108, for example. In some embodiments, FW route manager 108 may apply the rules from the FW policy to the discovered network resources for each of the respective firewalls for the specified IVN and/or subnets for the specified traffic to determine the route information. And col 14, for one or more of the changes that do not comply with the firewall policy, determining a remediation plan comprising new route information to remediate the non-compliance with the firewall policy; and transmitting, over a network, programmatic API calls to an isolated virtual network (IVN) manager to update the route information with new route information, or transmitting, over the network, a non-compliance alert comprising the remediation plan and col 11, lines 29-41 the system (e.g., the firewall manager 102) may be configured to monitor and enforce routes using policies. The system may only attempt to enforce rules on the newly discovered subnets and traffic endpoints for the accounts and IVNs in the policy's scope. In embodiments, the system may generate and transmit notifications of changes made to those routes, but the system will not revert the changes. For example, to maintain separation of responsibility between the network and security teams, the system may be configured to only alert the security administrator when the route entries are changed outside of the system (outside of the firewall manager)).
Shu and Chandramouli are both considered to be analogous to the claimed invention because they are in the same field of firewall.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shu to incorporate the teachings of Chandramouli and provide a firewall manager, i.e. firewall assembly, may be configured to monitor.
Doing so would aid in enforce routes using policies, thereby increasing the probability of alert comprising the remediation plan.
The combination fails to disclose monitor the firewall event comprises at least one of a firewall creation event, a firewall deletion event and a firewall update event.
However, Meng discloses monitor the firewall event comprises at least one of a firewall creation event, a firewall deletion event and a firewall update event (0013 monitoring, and configuration services across layers of a network stack implemented on the intermediary device 131 0019 the firewall at the intermediary network device 269 updates the quarantine list of its control plane (i.e., the mapping structure with quarantine flag) and then the quarantine list in its data plane based on remote analysis identifying one or more compromised devices. And 0020 an intrusion detection or endpoint protection agent can identify a compromised device to local firewalls with a file write, database update, etc. At stage C2, the firewall at intermediary network device 267 locally communicates the control plane quarantine list update as update 207A to the firewalls , i.e. firewall eupdate event , at the intermediary network devices 265, 269. The firewalls at the intermediary network devices 265, 269 internally update their respective quarantine lists, wherein the firewall update on the intermediary network device that is being monitoring, as it can be seen in the par 0020 At stage C1, the firewall at the intermediary network device 267 updates the quarantine list of its control plane and then the quarantine list in its data plane based on local security analysis input, the analysis can be seen as the monitoring the firewall updates of quarantine list in the intermediary device, i.e. open virtual network database.).
Shu and Chandramouli and Meng are both considered to be analogous to the claimed invention because they are in the same field of firewall.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shu to incorporate the teachings of Chandramouli, teaching of Meng and provide a firewall manager, i.e. firewall assembly, may be configured to monitor.
Doing so would aid in enforce routes using policies, thereby increasing the probability the remediation route plan.
As per claim 11. This system claim is rejected based on the same rational set forth in the claim 1.
As per claim 13. Shu and Chandramouli and Meng disclose the method according to claim 1, the combination discloses a router for the route is a virtual router or a physical router ( Shu discloses [n0061] Currently in the SDN architecture, the commonly used SDN controller is the OVN (Open Virtual Network) controller, and the SDN switch is the OVS (Open vSwitch) switch,Chandramouli discloses col 4, lines 10-25 the configuration monitoring service 120 monitors (continuously, periodically, or on an event-basis,) and records resource configurations and provides for automated evaluation of recorded configurations against desired configurations. In embodiments, configuration monitoring service 120 provides for review of changes in configurations and relationships between resources, supports deeper dives into detailed resource configuration histories, and facilitates determinations of overall compliance against the configurations specified in guidelines. In embodiments, the IVN manager service 130 is a service for launching resources in a logically isolated virtual network that can be defined. IVN manager service 130 provides for control over a virtual networking environment, including selection of an IP address range, creation of subnets, and configuration of route tables and network gateways. IVN manager service 130 can use both IPv4 and IPV6 for most resources in a virtual private cloud).
As per claim 14. Shu and Chandramouli and Meng disclose the method according to claim 1, Shu discloses when the firewall event is a firewall creation event, the strategy route is stored in the OVN database (0091 A storage unit is used to store the first OpenFlow flow table and the second OpenFlow flow table on the OVS centralized bridge after generating a first OpenFlow flow table based on the IP address of the cloud physical machine and generating a second OpenFlow flow table based on the firewall rules of the cloud physical machine ).
As per claim 15. Shu and Chandramouli and Meng disclose the method according to claim 1, Shu discloses when the firewall event is a firewall deletion event, the strategy route is deleted from the OVN database(0095 , the SDN architecture further includes an OVN centralized controller, and the second determining unit is specifically configured to: [n0096] The IP address of the cloud physical machine and the firewall rules of the cloud physical machine are determined by the application layer interface; the IP address of the cloud physical machine and the firewall rules of the cloud physical machine are sent to the OVN centralized controller.).
As per claim 16. Shu and Chandramouli and Meng disclose the method according to claim 1, Shu discloses when the firewall event is a firewall update event, the corresponding data in the OVN database are updated by using the strategy route([n0099] A logical flow table generation unit is configured to generate a first logical flow table according to the IP address of the cloud physical machine by the OVN northd service, and send the first logical flow table to the OVN southbound database service, and store the first logical flow table in the OVN southbound database by the OVN southbound database service, wherein the first logical flow table includes the IP address of the cloud physical machine and the MAC address of the cloud physical machine; and generate a second logical flow table according to the firewall rules of the cloud physical machine by the OVN northd service, and send the second logical flow table to the OVN southbound database service, and store the second logical flow table in the OVN southbound database by the OVN southbound database service, wherein the second logical flow table includes the IP address of the cloud physical machine and the firewall rules of the cloud physical machine.).
As per claim 17. Shu and Chandramouli and Meng disclose the method according to claim 1,Shu discloses Neutron-Fwaas-plugin in a neutron-fwaas plug-in registers a firewall event monitoring mechanism; and a function code of OVN firewall driver handler is added in the Neutron-Fwass plug-in, to monitor the firewall event by the OVN Firewall Driver Hander (0003 cloud platforms built using the SDN architecture implement the DHCP server of each cloud physical machine through the neutron-dhcp-agent namespace method, assign an IP address to each cloud physical machine, and set a hardware firewall on the egress switch of each cloud physical machine to filter the traffic of the cloud physical machine).
As per claim 20, this device claim is rejected based on the same rational set forth in the claim 1.
Allowable Subject Matter
Claims 2-10, 18 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims into all the independent claims.
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 ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights