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 .
DETAILED ACTION
The present office action is responsive to communications received on 10/17/2024.
Status of Claims
Claims 1-20 are pending.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 4-8, 10-12, 14-18 and 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Syvanne et al. (US 20030149766 A1) hereinafter referred to as Syvanne.
With respect to claim 1, Syvanne discloses: A system for managing network filters comprising: a first network including a first network device, the first network comprising at least one processor and memory, the memory operatively coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the first network to perform a method, the method comprising: (Syvanne Fig. 1 system).
providing an interface, the interface configured to receive input from a requester using a second network device of a second network that is external to the first network; (Syvanne ¶44 teaches configuration of network nodes, such as firewall, gateway, and router with rules wherein ¶45 teaches a remote admin on a second device modifying network rule(s) configuration(s) for device such as a firewall when reciting “when a user or administrator wants to, when new or modified configuration is saved or uploaded to the network node or when the network node is started up.” The admin is remote as illustrated in Fig. 1 and explained in more details in Fig. 1 corresponding paragraphs).
receiving, via the interface, a first filter request from the second network device, the first filter request comprising first filter parameters; evaluating the first filter parameters based on one or more filter criteria, the first filter parameters including a target IP address and a source IP address; (Syvanne ¶4 and 49 recite the received admin firewall rules comprise “the access rules of a firewall are expressed as a table or list (rule base) of rules comprising data packet characteristics and related actions. The rule base is a central part of a security policy of a firewall. The data packet characteristics in rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address and service (or protocol) or some other values.” See also Syvanne Figs. 6-7 with corresponding paragraphs in the specs).
and based on determining that the first filter parameters pass the evaluation: sending the first filter parameters to the first network device to cause the first network device to implement the first filter parameters for the target IP address; (Syvanne ¶45 teaches “If all requirements of the validation rule base are fulfilled (step 211), the processing rule base is accepted in step 212, and if the requirements are not fulfilled, the processing rule base is rejected in step 213.” Wherein accepting means the configuration rule is passed onto the network node for enforcement by a firewall or router node for example).
collecting first network information about the first network based on the first filter parameters; and presenting, via the interface, the first network information. (it can be understood from Syvanne ¶48 that a command is “echo” which means that if a rule is validated then echo command is performed which is a command that collects target IP data based on target IP parameter and presents collected information to requestor interface).
With respect to claim 2, Syvanne discloses: The system of claim 1, wherein the one or more filter criteria include a validity of the target IP address and an ownership of the target IP address. (Syvanne ¶4 “rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address [target IP address] and service (or protocol) or some other values [ownership of the target IP address].” Syvanne ¶57 teaches validating the rules based on addresses pointing to service(s)).
With respect to claim 4, Syvanne discloses: The system of claim 1, wherein the source IP address comprises a block of source IP addresses. (Syvanne ¶66 teaches a rule comprises address range(s) [block of source IP addresses])
With respect to claim 5, Syvanne discloses: The system of claim 1, wherein the method further comprises: receiving a second filter request from the requester after determining the first filter parameters pass the evaluation, the second filter request comprising second filter parameters; modifying the first filter parameters based on the second filter parameters to generate modified filter parameters; and sending the modified filter parameters to the first network device. (Syvanne ¶6 and 25 teach admin [requester] updating [receiving a second filter request] an existing firewall rule, the new rule parameters are validated before modifying the rule base).
With respect to claim 6, Syvanne discloses: The system of claim 1, wherein the method further comprises sending a command to the first network device to remove the first filter parameters from the first network. (Syvanne ¶6 and 25 teach admin can modify/update the rules which comprises removing some addresses in the process as taught by Syvanne ¶28).
With respect to claim 7, Syvanne discloses: The system of claim 1, wherein the first network device comprises a router. (Syvanne ¶44-45 “The method of the invention may be used in connection with configuring any network node, which filters data packets on the basis of a rule base. Such network node may be for example a firewall, a security gateway, a VPN gateway or a router … In step 210, a processing rule base, which is part of a configuration of a network node, is validated against requirements of a validation rule base”).
With respect to claim 8, Syvanne discloses: The system of claim 1, wherein the first filter parameters include a command for one or more of blocking, allowing, counting, or rate limiting traffic to the target IP address from the source IP address. (Syvanne Figs. 6-7, and corresponding paragraphs recite at least “allowing” or “discarding” [blocking] actions rules [filters] based on source and destination addresses).
With respect to claim 10, Syvanne discloses: The system of claim 1, wherein the source IP address comprises an IP address of a third network device of the second network. (Syvanne Figs. 6-7 show plurality of source and destination addresses wherein Fig. 1 illustrates that the devices are on different networks).
With respect to claim 11, Syvanne discloses: The system of claim 1, wherein sending the first filter parameters to the first network device comprises sending the first filter parameters to an edge router connecting the second network device to the first network. (Syvanne Fig. 1, additionally Syvanne ¶44-45 “The method of the invention may be used in connection with configuring any network node, which filters data packets on the basis of a rule base. Such network node may be for example a firewall, a security gateway, a VPN gateway or a router … In step 210, a processing rule base, which is part of a configuration of a network node, is validated against requirements of a validation rule base”).
With respect to claim 12, Syvanne discloses: The system of claim 1, wherein the first network comprises a first autonomous system (AS) and the second network comprises a second AS. (it can be understood from Syvanne ¶76 that the validation is performed automatically without admin intervention by the nodes devices’ processors, wherein each node (such as firewalls) operates on its respective network).
With respect to claim 14, Syvanne discloses: A method, comprising: providing an interface, the interface configured to receive, at a first network device of a first network, input from a requester using a second network device of a second network that is external to the first network; (Syvanne ¶44 teaches configuration of network nodes, such as firewall, gateway, and router with rules wherein ¶45 teaches a remote admin on a second device modifying network rule(s) configuration(s) for device such as a firewall when reciting “when a user or administrator wants to, when new or modified configuration is saved or uploaded to the network node or when the network node is started up.” The admin is remote as illustrated in Fig. 1 and explained in more details in Fig. 1 corresponding paragraphs).
receiving, via the interface, a first filter request from the second network device, the first filter request comprising first filter parameters; evaluating the first filter parameters based on one or more filter criteria, the first filter parameters including a target IP address and a source IP address; (Syvanne ¶4 and 49 recite the received admin firewall rules comprise “the access rules of a firewall are expressed as a table or list (rule base) of rules comprising data packet characteristics and related actions. The rule base is a central part of a security policy of a firewall. The data packet characteristics in rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address and service (or protocol) or some other values.” See also Syvanne Figs. 6-7 with corresponding paragraphs in the specs).
and based on determining that the first filter parameters pass the evaluation: sending the first filter parameters to the first network device to cause the first network device to implement the first filter parameters for the target IP address; (Syvanne ¶45 teaches “If all requirements of the validation rule base are fulfilled (step 211), the processing rule base is accepted in step 212, and if the requirements are not fulfilled, the processing rule base is rejected in step 213.” Wherein accepting means the configuration rule is passed onto the network node for enforcement by a firewall or router node for example).
collecting first network information about the first network based on the first filter parameters; and presenting, via the interface, the first network information. (it can be understood from Syvanne ¶48 that a command is “echo” which means that if a rule is validated then echo command is performed which is a command that collects target IP data based on target IP parameter and presents collected information to requestor interface).
With respect to claim 15, Syvanne discloses: The method of claim 14, wherein the one or more filter criteria include a validity of the target IP address and an ownership of the target IP address. (Syvanne ¶4 “rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address [target IP address] and service (or protocol) or some other values [ownership of the target IP address].” Syvanne ¶57 teaches validating the rules based on addresses pointing to service(s)).
With respect to claim 16, Syvanne discloses: The method of claim 14, further comprising: receiving a second filter request from the requester after determining the first filter parameters pass the evaluation, the second filter request comprising second filter parameters; modifying the first filter parameters based on the second filter parameters to generate modified filter parameters; and sending the modified filter parameters to the first network device. (Syvanne ¶6 and 25 teach admin [requester] updating [receiving a second filter request] an existing firewall rule, the new rule parameters are validated before modifying the rule base).
With respect to claim 17, Syvanne discloses: The method of claim 14, wherein the first network comprises a first autonomous system (AS) and the second network comprises a second AS. (it can be understood from Syvanne ¶76 that the validation is performed automatically without admin intervention by the nodes devices’ processors, wherein each node (such as firewalls) operates on its respective network).
With respect to claim 18, Syvanne discloses: A method, comprising: providing an interface, the interface configured to receive, at a first network device of a first network, input from a requester; (Syvanne ¶44 teaches configuration of network nodes, such as firewall, gateway, and router with rules wherein ¶45 teaches a remote admin on a second device modifying network rule(s) configuration(s) for device such as a firewall when reciting “when a user or administrator wants to, when new or modified configuration is saved or uploaded to the network node or when the network node is started up.” The admin is remote as illustrated in Fig. 1 and explained in more details in Fig. 1 corresponding paragraphs).
receiving, via the interface, a first filter, the first filter request comprising first filter parameters; evaluating the first filter parameters based on one or more filter criteria, the first filter parameters including a target IP address and a source IP address; (Syvanne ¶4 and 49 recite the received admin firewall rules comprise “the access rules of a firewall are expressed as a table or list (rule base) of rules comprising data packet characteristics and related actions. The rule base is a central part of a security policy of a firewall. The data packet characteristics in rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address and service (or protocol) or some other values.” See also Syvanne Figs. 6-7 with corresponding paragraphs in the specs).
based on determining that the first filter parameters pass the evaluation, sending the first filter parameters to the first network device to cause the first network device to implement the first filter parameters for the target IP address; (Syvanne ¶45 teaches “If all requirements of the validation rule base are fulfilled (step 211), the processing rule base is accepted in step 212, and if the requirements are not fulfilled, the processing rule base is rejected in step 213.” Wherein accepting means the configuration rule is passed onto the network node for enforcement by a firewall or router node for example).
determining whether to send the first filter parameters to a second network that is external to the first network; upon determining to send the first filter parameters to the second network, sending a second filter request to a network filter request arbiter for the second network; (Syvanne ¶6 and 25 teach admin [requester] updating [receiving a second filter request] an existing firewall rule, the new rule parameters are validated before modifying the rule base which are validated and implemented on a second network as illustrated in Fig. 1 and explained in corresponding paragraphs of Syvanne).
and receiving notification whether the first filter parameters have been implemented at the second network. (it can be understood from Syvanne ¶48 that a command is “echo” which means that if a rule is validated then echo command is performed which is a command that collects target IP data based on target IP parameter and presents collected information to requestor interface).
With respect to claim 20, Syvanne discloses: The method of claim 19, wherein the one or more filter criteria include a validity of the target IP address and an ownership of the target IP address. (Syvanne ¶4 “rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address [target IP address] and service (or protocol) or some other values [ownership of the target IP address].” Syvanne ¶57 teaches validating the rules based on addresses pointing to service(s)).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Syvanne as applied to claims 1-2, 4-8, 10-12, 14-18 and 20 above, and further in view of Thron et al. (US 20070201458 A1) hereinafter referred to as Thron.
With respect to claim 3, Syvanne discloses: The system of claim 1, wherein the one or more filter criteria includes a prefix length of the target IP address and port protocol rules. (¶28 “possible NAT (Network Address Translation) rules are combined into said processing rule base model by changing addresses and/or port numbers of rules in said processing rule base to real addresses and/or port numbers.”)
Syvanne does not explicitly disclose “prefix length”
However, Thron in an analogous art discloses: wherein the one or more filter criteria includes a prefix length of the target IP address (Thron Table 17, underneath ¶91, teaches filter criteria include prefix length of source and target IPs and source and target ports).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Syvanne wherein the one or more filter criteria includes a prefix length of the target IP address as disclosed by Thron to allow for more control over the criteria used in a rule (Thron Table 17, underneath ¶91).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Syvanne as applied to claims 1-2, 4-8, 10-12, 14-18 and 20 above, and further in view of Al Shakh et al. (US 20240168655 A1) hereinafter referred to as Al Shakh.
With respect to claim 9, Syvanne discloses: The system of claim 1,
Syvanne does not explicitly disclose: wherein the first filter parameters include a duration after which to remove the first filter parameters from the first network device.
However, Al Shakh in an analogous art discloses: wherein the first filter parameters include a duration after which to remove the first filter parameters from the first network device. (Al Shakh ¶33 teaches firewall rule with expiration date parameter after which the rule is deleted which means all the parameters are removed).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the network information taught by Syvanne wherein the first filter parameters include a duration after which to remove the first filter parameters from the first network device as taught by Al Shakh to ensure up-to-date filter rules (see Al Shakh ¶33).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Syvanne as applied to claims 1-2, 4-8, 10-12, 14-18 and 20 above, and further in view of Cooper et al. (US 7143439 B2) hereinafter referred to as Cooper.
With respect to claim 13, Syvanne discloses: The system of claim 1, wherein the network information comprises one or more of a status of the first filter parameters, (Syvanne Fig. 7 illustrates status “allow” and “discard” based on the parameters).
a number of requests blocked by the first filter parameters, (Syvanne Fig. 7 illustrates a number of requests that are “discarded” [blocked] based on the rules [filters] corresponding to source/destination parameters).
Syvanne does not explicitly disclose: and a timing of the requests
However, Cooper in an analogous art discloses: and a timing of the requests. (Cooper Fig. 23 illustrates displaying each rule with source IP and port and destination IP and port and date-time and status).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the network information taught by Syvanne to include a timing of the requests as taught by Cooper to display information that might be useful for network admins (see Cooper fig. 23).
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Syvanne as applied to claims 1-2, 4-8, 10-12, 14-18 and 20 above, and further in view of Brandwine (US 9825911 B1) hereinafter referred to as Brandwine.
With respect to claim 19, Syvanne discloses: The method of claim 18,
Syvanne does not explicitly disclose: wherein determining whether to send the first filter parameters to the second network comprises determining whether a threshold amount of traffic for the target IP address from the source IP address has been received at the first network from the second network.
However, Brandwine in an analogous art discloses: wherein determining whether to send the first filter parameters to the second network comprises determining whether a threshold amount of traffic for the target IP address from the source IP address has been received at the first network from the second network. (Brandwine col 13 line 60 to col 14 line 40 teaches if there is a threshold traffic threat between source IP and destination IP the security policies [comprising parameters] are updated in order to control potential security threat).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Syvanne wherein determining whether to send the first filter parameters to the second network comprises determining whether a threshold amount of traffic for the target IP address from the source IP address has been received at the first network from the second network as disclosed by Brandwine to ensure security rules are updated based on a detected potential threat (see Brandwine col 13 line 60 to col 14 line 40).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANY S GADALLA whose telephone number is (571)272-2322. The examiner can normally be reached Mon to Fri 8:00AM - 4:00PM.
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, Carl Colin can be reached at (571) 272-3862. 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.
/HANY S. GADALLA/Primary Examiner, Art Unit 2493