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 instant application having Application No.18/648,096 is presented for examination by
the examiner. Claims 1, 8 and 15 are amended. Claims 1-20 have been examined.
Response to Arguments
3. Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are
moot because the new ground of rejection does not rely on any reference applied in the prior
rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 4, 7-8, 10-11, 14-15 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Redekop (US20180019968A1), in further view of Ellard (US20150358279A1).
Regarding Claim 1
Redekop discloses:
A method of a firewall for preventing data exfiltration, comprising:
receiving, at the firewall on egress node of a network, a network request from a client device within the network (Redekop ¶34, 43, 54: Teaches a router acting as an egress gateway that receives IP packets from client devices on a local network and filters them before they are sent to the backhaul network, corresponding to receiving a network request at an egress node from a client device.), the network request including a first domain name and a first IP address (Redekop ¶48, 57, 60: Teaches use of SDTTL tuples and user-defined pairs of domain names and IP addresses for DNS handling and enforcement, confirming that both the domain name and corresponding IP address are captured and associated in the resolution path.);
in response to receiving the network request, resolving a second IP address based on the first domain name (Redekop ¶48, 53, 57: Teaches that upon receiving a DNS request containing a domain name, the router forwards the query to an upstream DNS resolver (if not locally cached) and receives a resolved IP address, which is then associated with the domain name and stored in the SDTTL tuple.);
Redekop does not explicitly teach inserting the second IP address into the network request in place of the first IP address by modifying a destination field of the network request prior to forwarding the network request. On the other hand, Ellard discloses inserting the second IP address into the network request in place of the first IP address by modifying a destination field of the network request prior to forwarding the network request (Ellard ¶¶28-29: teaches that a gateway disposed on the egress boundary of a protected network receives an outbound packet from a client device and replaces the destination address of the packet with an actual external address derived from a prior DNS resolution mapping before forwarding the packet; FIG. 7 ¶¶60-64: teaches receiving outbound traffic, determining the local destination address is mapped to an external address, replacing the local destination address with the external address, and transmitting the outbound traffic with the destination address translated to the actual external address).
Given the teachings of Ellard, it would have been obvious to one having ordinary skill in the art to modify the teachings of Redekop to insert the DNS-resolved second IP address into the destination field of the network request prior to forwarding, because Ellard teaches that inline destination address rewriting at an egress gateway is a known and effective technique for enforcing network security policy and preventing unauthorized communications (Ellard ¶42). The motivation to combine would be to actively correct and enforce the destination of outbound packets rather than merely permitting or blocking them, thereby enhancing Redekop's existing DNS-based egress filtering system.
Regarding Claim 3
Redekop discloses:
The method of claim 1, further comprising:
blocking the network request based on a comparison of the first IP address to the second IP address (Redekop ¶46, 48, 56, 90: Teaches blocking a network request based on a comparison between the destination IP address in the packet (first IP) and the IP address resolved via a prior DNS query (second IP). The router stores source-destination-TTL tuples derived from DNS responses, and if the destination IP in a packet does not match a stored tuple, the packet is blocked.).
Regarding Claim 4
Redekop discloses:
The method of claim 1, further comprising:
blocking the network request based on the second IP address (Redekop ¶46, 48, 56, 90: Teaches blocking a network request based on the second IP address, where the packet filter only permits traffic to IPs previously resolved via DNS. If a network request targets an IP address not found in the validated tuples derived from DNS (i.e., the second IP), the request is blocked.).
Regarding Claim 7
Redekop discloses:
The method of claim 1, further comprising:
sending the network request to the second IP address (Redekop ¶48, 54, 57: Teaches that after validating a DNS resolution, the router stores the resolved IP (second IP) in a tuple and permits the outbound request to that IP. The packet is then sent to the destination endpoint identified by the second IP address if it matches a valid rule.).
Regarding Claim 8
Claim 8 is directed to a computing device corresponding to the processor-implemented method in claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 10
Claim 10 is directed to a computing device corresponding to the processor-implemented method in claim 3. Claim 10 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a computing device corresponding to the processor-implemented method in claim 4. Claim 11 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a computing device corresponding to the processor-implemented method in claim 7. Claim 14 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to an executable instruction corresponding to the processor-implemented method in claim 1. Claim 15 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to an executable instruction corresponding to the processor-implemented method in claim 3. Claim 17 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to an executable instruction corresponding to the processor-implemented method in claim 4. Claim 18 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 2, 6, 9, 13, 16, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Redekop (US20180019968A1), in view of Ellard (US20150358279A1) as applied to claim 1 above, and in further view of James (US20230283591A1).
Regarding Claim 2
Redekop and Ellard teach a firewall on an egress node that receives a network request containing a domain name and a first IP address, resolves a second IP address based on the domain name, and inserts that second IP address into the network request by replacing the destination field prior to forwarding. However, they do not disclose the following limitation “after inserting the second IP address into the network request, processing the network request based on the second IP address and the first domain name”.
In an analogous art, James discloses a DNS response system/method that includes:
The method of claim 1, further comprising:
after inserting the second IP address into the network request, processing the network request based on the second IP address and the first domain name (James ¶31, 33: Teaches that after substituting the original IP address for the FQDN with an alternative IP address, the firewall provides the modified response to the client, which then initiates a connection using the second IP address while still associating the communication with the original domain name.).
Given the teachings of James, a person of ordinary skill in the art would have recognized the desirability of modifying the teachings of Redekop and Ellard by processing a network request using a substituted IP address while retaining the original domain association. James teaches that after replacing the original IP address for a FQDN with an alternative IP, the firewall provides the modified response and the client initiates a connection using the new IP while still associated with the same domain name (James ¶31, 33), making it obvious to process the request based on the second IP and first domain name.
Regarding Claim 6
James further discloses a DNS response system/method that includes:
The method of claim 1, further comprising:
obtaining a second domain name based on a reverse lookup of the first IP address at the firewall (James ¶33–34, 37–39: Teaches that the DNS security service and firewall analyze posture information associated with the IP address returned for a FQDN and update traffic rules based on that analysis, effectively re-associating the IP address with the corresponding domain and adjusting DNS behavior at the firewall. This maps to obtaining a second domain name based on a reverse lookup of the first IP address at the firewall.).
Given the teachings of James, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Redekop and Ellard by performing reverse domain association at the firewall to enhance DNS-based security analysis and rule enforcement. James teaches that a firewall cooperates with a DNS security service to evaluate posture information associated with the IP address returned for a FQDN and updates traffic rules based on that information (James ¶33–34, 37–39), which would have made it obvious to implement a system that obtains a second domain name based on a reverse lookup of the first IP address at the firewall to maintain accurate domain-to-IP associations and improve threat detection and response accuracy.
Regarding Claim 9
Claim 9 is directed to a computing device corresponding to the processor-implemented method in claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a computing device corresponding to the processor-implemented method in claim 6. Claim 13 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to an executable instruction corresponding to the processor-implemented method in claim 2. Claim 16 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 is directed to an executable instruction corresponding to the processor-implemented method in claim 6. Claim 20 is similar in scope to claim 6 and is therefore rejected under similar
Claims 5, 12 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Redekop (US20180019968A1), in view of Ellard (US20150358279A1) as applied to claim 1 above, and in further view Jung (US 20180367619 A1).
Regarding Claim 5
Redekop and Ellard teach a firewall on an egress node that receives a network request containing a domain name and a first IP address, resolves a second IP address based on the domain name, and inserts that second IP address into the network request by replacing the destination field prior to forwarding. However, they do not disclose the following limitation “determining a service associated with the network request; and modifying the network request based on a comparison of a port identified in the network request to a conventional port associated with the service”.
In an analogous art, Jung discloses a port identification system/method that includes:
The method of claim 1, further comprising:
determining a service associated with the network request; and
modifying the network request based on a comparison of a port identified in the network request to a conventional port associated with the service (Jung ¶160–¶161, ¶167, ¶169: Teaches that the proxy identifies an HTTP request on port 80, recognizes HTTPS as the conventional service port (443), and modifies the request by redirecting or reconnecting through port 443.).
Given the teachings of Jung, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Redekop and Ellard by comparing the requested port and the conventional port associated with the service. Jung teaches that a proxy device receiving an HTTP request on port 80 may identify the service type and redirect or reconnect the request through port 443 for HTTPS (Jung ¶160–161, 167, 169), which would have made it obvious to implement a system that determines the intended service and adjusts or redirects the network request to use the proper conventional port, thereby improving connection security and protocol compliance.
Regarding Claim 12
Claim 12 is directed to a computing device corresponding to the processor-implemented method in claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to an executable instruction corresponding to the processor-implemented method in claim 5. Claim 19 is similar in scope to claim 5 and is therefore rejected under similar rationale.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights