Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the application 18/771,814 filed on 03/27/2024.
Claims 1-20 have been examined and are pending in this application.
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, 5-8, 12-15 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/146001 A1) in view of Danisik (US 2018/0241772 A1).
Regarding Claim 1
Chien teaches:
A method comprising:
for each of a plurality of packets received by a firewall,
updating an entry in a database of network traffic data to indicate a first Internet Protocol (IP) address from a source address field in a hypertext transfer protocol (HTTP) header of the packet (Chien ¶40–42, 46–47, 65–67: teaches receiving packets at a device operating as a firewall and obtaining the source IP address from HTTP packet headers. Chien’s authorization module uses these IP addresses to access and maintain a database (whitelist) that stores IP address associations, and explicitly discloses that new IP addresses “would be added to the whitelist” when encountered. Because Chien’s system adds source IPs to the whitelist database upon processing traffic, it directly teaches updating database entries based on source IPs obtained from packet headers.);
determining whether the packet indicates a second IP address in a X-Forward-For (XFF) field in the HTTP header (Chien ¶67, 75: teach determining whether an HTTP packet contains a second IP address in an X-Forwarded-For (XFF) header field by explicitly stating that the system reads an IP address from the XFF field of an HTTP request when evaluating network communications.);
Chien discloses an inline firewall that receives HTTP packets and updates a whitelist database using the source client IP from the HTTP header. However, Chien does not teach updating the database with a second IP extracted from the X-Forwarded-For (XFF) field when upstream network devices modify source addresses, nor enforcing security determinations based at least in part on IPs stored as originating from the XFF chain.
However, in an analogous art Danisik teaches a XFF system/method that includes:
based on the firewall being inline or downstream from a network device that modifies source addresses in HTTP headers and the packet indicating the second IP address in the XFF field in the HTTP header of the packet, updating the entry in the database to also indicate the second IP address and the second IP address being in the XFF field (Danisik ¶60–64, 69–72: teach receiving an HTTP message at a downstream security component after the message has passed through load balancers that modify or append source addresses, extracting a second IP address from the X-Forwarded-For (XFF) header based on the network topology, storing that forwarded IP address in a data store for comparison against the expected public IP, and using that XFF-derived IP to determine whether the communication is spoofed.); and
enforcing security on network traffic traversing the firewall based, at least in part, on IP addresses indicated in the database as being in the XFF field (Danisik ¶60–64, 69–72 and Claim 4: teach an Auto Configuration Server positioned downstream from load balancers that modify or append source addresses to HTTP messages by inserting additional entries in the XFF header, retrieving the forwarded IP address from the XFF field and storing/using that XFF-derived IP internally via its determiner, data store (MEM), and comparator, and enforcing a security determination (e.g., spoof vs. legitimate) based on comparing the XFF-indicated IP with the expected public IP, thereby applying security actions based at least in part on IP addresses indicated in the database as originating from the XFF field.).
Given the teachings of Danisik, a person of ordinary skill in the art would have found it obvious to modify the teachings of Chien by enabling the downstream firewall to enforce security based on IP addresses extracted from the XFF header rather than relying solely on the source IP observed at the firewall. Chien teaches evaluating HTTP communications using IP information but does not disclose handling situations where upstream devices modify source addresses. Danisik, however, teaches a downstream security component receiving traffic that has passed through load balancers that append or rewrite source addresses, retrieving the forwarded IP from the XFF field, updating a data store with that XFF-derived IP, and enforcing spoof-detection decisions based on the comparison between the public IP and the XFF IP (Danisik ¶60–64, 69–72; Claim 4). Thus, it would have been obvious to incorporate Danisik’s XFF-based extraction and database update mechanisms into Chien’s system so the firewall could correctly identify true client IPs and enforce security even when upstream devices modify HTTP source addresses.
Regarding Claim 5
Chien teaches:
The method of claim 1 further comprising, for each of the plurality of packets received by the firewall, updating the database to indicate at least one of a network address indicated in a destination field of the HTTP header, packet size, port number, and protocol (Chien ¶60–63: teaches maintaining a whitelist/database that stores detailed per-connection and per-packet attributes such as IP address, port number, direction, payload type, category code, upload/download, and additional communication metadata, meaning the system updates a data structure with packet-level fields every time inbound or outbound network communication occurs. This corresponds to updating a database for each packet with destination IP, port, protocol, and related attributes).
Regarding Claim 6
Chien teaches:
The method of claim 1 further comprising updating the database to indicate a number of packets received with a same network address in the source address field in HTTP headers (Chien ¶92–93: teaches maintaining state for each source IP address by tracking how many packets have been received from that source, including enforcing verification rules every defined number of packets (e.g., every 100 packets), thereby causing the system to update an internal database or state record with the growing count of packets associated with the same source address. This corresponds to updating a database to indicate a number of packets received with a same network address in the source address field of HTTP headers.).
Regarding Claim 7
Chien teaches:
The method of claim 1, wherein enforcing security comprises at least one of identifying a policy or rule based on the second IP address (Chien ¶34–35, 60–63: teach enforcing security by identifying a security rule based on the IP address because Chien stores each IP address in a whitelist database with associated communication rules (e.g., allowable payload type, port, direction, security rating) and then applies those rules to allow, block, or warn on network traffic from that IP. This corresponds to selecting and enforcing a policy based on the second IP address.), logging and analyzing traffic characteristics and behaviors of network traffic by IP addresses indicated in the database as being in the XFF field of HTTP headers, and correlating the IP addresses in the database indicated as being in the XFF field with user accounts and then processing network traffic accordingly.
Regarding Claim 8
Claim 8 is directed to a program instruction corresponding to the method in claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 12
Claim 12 is directed to a program instruction corresponding to the method in claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a program instruction corresponding to the method in claim 6. Claim 13 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a program instruction corresponding to the 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 a system corresponding to the method in claim 1. Claim 15 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 19
The apparatus of claim 15, wherein the network device is a load balancer, application gateway, proxy, web server, or edge router (Chien ¶24: teaches that embodiments may be implemented on router, firewall, or other network devices, and explicitly includes server devices of “online service” or “questionable network node” w\which operate as proxy or gateway servers within the evaluated network paths. Thus, Chien also satisfies the requirement that the network device be a proxy or web server.).
Regarding Claim 20
Claim 20 is directed to a system corresponding to the method in claim 7. Claim 20 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Claims 2, 4, 9, 11, 16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/146001 A1) and Danisik (US 2018/0241772 A1) as applied to claims 1, 8 and 15 above, and in further view of Kumar (US 10,771,506 B1).
Regarding Claim 2
Chien and Danisik can be combined to disclose an inline firewall that receives HTTP packets and updates a whitelist database using the source client IP from the HTTP header and enforcing security determinations based at least in part on IPs stored as originating from the XFF chain. However, Chien and Danisik are silent on determining the location of the firewall within the network as inline or downstream with respect to a network device. In an analogous art, Kumar (Col. 2, L. 54 – Col. 3, L. 8; Claim 8) teaches receiving network topology and device capability information to select an enforcement device, including firewalls, based on their position in the network such as at the perimeter, internal to the network, or nearest to the affected client. These placements correspond to inline or downstream positions relative to other devices. A person of ordinary skill in the art would have been motivated to incorporate Kumar’s topology-aware device selection techniques into the Chien and Danisik system to enable accurate identification of firewall placement for applying security policies, yielding predictable results.
Regarding Claim 4
Chien and Danisik can be combined to disclose an inline firewall that receives HTTP packets and updates a whitelist database using the source client IP from the HTTP header and enforcing security determinations based at least in part on IPs stored as originating from the XFF chain. However, Chien and Danisik are silent in explicitly teaching that determining the location of the firewall within the network comprises analyzing a schematic or topology of the network. On the other hand, Kumar (Col. 8, L. 19 – Col. 9, L. 21) teaches receiving and analyzing network topology information, including device location, communication links, and neighbor relationships, derived from topology discovery systems such as NAC or EMS. Specifically, Kumar discloses that the topology information includes physical or logical device placement relative to other nodes in the network. This corresponds to determining firewall location by analyzing a network schematic or topology. Thus, this approach could have been implemented in the system of Chien and Danisik to support automated enforcement point identification based on topology context. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Regarding Claim 9
Claim 9 is directed to a program instruction corresponding to the method in claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a program instruction corresponding to the method in claim 4. Claim 11 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to a system corresponding to the method in claim 2. Claim 16 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to a system corresponding to the method in claim 4. Claim 18 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/146001 A1), Danisik (US 2018/0241772 A1) and Kumar (US 10,771,506 B1) as applied to claims 2, 9 and 16 above, and in further view of Lyon (US 20060075491 A1).
Regarding Claim 3
Chien, Danisik, and Kumar can be combined to disclose an inline firewall that receives HTTP packets and updates a whitelist database using the source client IP from the HTTP header and enforcing security determinations based at least in part on IPs stored as originating from the XFF chain along with determining the location of the firewall as inline or downstream, but do not teach determining that the first IP address is indicated in a source field in HTTP headers of a number of packets that exceeds a threshold. On the other hand, Lyon (¶50–51) teaches reading the source IP address from each packet and counting how many packets are received from that source. Lyon discloses comparing the count to a predefined threshold to detect events such as attacks, which corresponds to identifying when the same source IP appears in the headers of a number of packets exceeding a threshold. It would have been obvious to a person of ordinary skill in the art to incorporate Lyon’s threshold-based source IP counting mechanism into the firewall determination system of Chien, Danisik, and Kumar to enhance detection capabilities using common network traffic analysis techniques, producing predictable results.
Regarding Claim 10
Claim 10 is directed to a program instruction corresponding to the method in claim 3. Claim 10 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to a system corresponding to the method in claim 3. Claim 17 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is 571-272-1531. The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be reached on 571-272-2092.
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 https://ppair-my.uspto.gov/pair/PrivatePair. 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