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. 19/284,399 is presented for examination by the examiner.
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 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 of this title, 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, 14-17, 21 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/0146001 A1), in view of Devarajan (US 2010/0278052 A1).
Regarding Claim 1
Chien disclose:
A method comprising: recording header information from a packet received from a proxy (Chien ¶[0065]-[0067]: a network communication is transported by packets having header and payload sections; the process obtains contents from the packet payload; and an HTTP request received through an HTTP proxy is evaluated by determining an IP address from a field of the HTTP request header);
determining that the header information includes a first Internet Protocol (IP) address in a source address field and a second IP address of a client device in an X-Forward-For (XFF) field (Chien ¶[0067]: XFF field identifies the IP address of a client connecting through an HTTP proxy, typically different than the source IP address which is that of the proxy server; ¶[0075]: determining the IP address by reading the X-Forwarded-For field of an HTTP request);
determining at least one of a policy and a rule based, at least in part, on the second IP address (Chien ¶[0043]: white list keyed by IP address associated with policies, rules, or properties; ¶[0077]-[0078]: looking up the IP address in the white list and determining whether the associated communication property is satisfied).
Chien does not explicitly disclose determining that the client device belongs to a group of devices controlled by a first policy; applying the first policy to the packet and other network traffic with header information that includes the second IP address of the client device in the XFF field; and logging information about the packet and other network traffic with header information that includes the second IP address in association with indication of the client device. However, Devarajan discloses an administrator applying mobile policy profiles to users/groups of mobile devices (Devarajan ¶[0077]); applying pre-defined policy profiles to multiple mobile devices simultaneously (Devarajan ¶[0085]); a secure Web gateway associating traffic with users/organizations based on a destination IP address, including mapping the destination IP address to a single user (Devarajan ¶[0115]); maintaining and continually updating that association (Devarajan ¶[0116]); and determining the user/organization from the maintained association, applying policy accordingly, and logging traffic based on the determined user and applied policies, with transaction logging providing an integrated view of all user activity (Devarajan: ¶[0118], steps 3402-3408; [0105]).
It would have been obvious to use Chien's XFF derived originating client identification with Devarajan's known group policy, traffic association, and logging techniques so that traffic traversing a proxy could be subjected to the policy associated with the originating client and logged consistently with that client identity, because Chien and Devarajan are analogous art directed to enforcing security policy on network traffic evaluated at an intermediary node.
Regarding Claim 2
Chien as modified discloses the limitations of claim 1. Chien further discloses dynamically generating a list based on incoming IP-address information, wherein subsequent accesses are evaluated using the dynamically generated list (Chien: ¶[0059]), and associating IP addresses with subgroup information, including a sub-organization code specifying a subset of IP addresses within an organization divided into subgroups (Chien: ¶[0060], Table 1). Although Chien does not expressly identify the dynamically generated list as a “dynamic address group,” it would have been obvious to one having ordinary skill in the art to implement the dynamically generated IP address list as a dynamic address group for determining membership of the client device, because Chien expressly teaches both dynamically maintaining IP address membership information and organizing IP addresses into subgroups for policy related processing.
Regarding Claim 3
Chien as modified discloses the limitations of claim 1. Chien further discloses querying a repository using the second IP address to obtain characteristics of the client device (Chien ¶[0073], [0077]-[0078]: accessing a white list and looking up the second IP address therein to retrieve an associated communication property; ¶[0060], Table 1: white list properties associated with an IP address including a sub-organization code specifying a subset of IP addresses within an organization divided into subgroups, a security rating, and geographic location information);
wherein determining that the client device belongs to the group of devices controlled by the first policy is based, at least in part, on the obtained characteristics (Chien ¶[0060], Table 1: sub-organization code used to divide an organization's IP addresses into subgroups; Devarajan ¶[0077]: an administrator applies mobile policy profiles to users/groups of mobile devices; ¶[0085]: pre-defined policy profiles applied to multiple mobile devices simultaneously).
It would have been obvious to one having ordinary skill in the art to use the characteristics obtained from Chien's IP address repository query, including the sub-organization/subgroup information associated with the IP address, to determine which device group and corresponding policy profile of Devarajan applies to the client device because Chien teaches associating network address information with subgroup related characteristics, while Devarajan teaches applying administrator defined policy profiles to groups of mobile devices. The combination would predictably allow the identified client to be assigned to the appropriate policy controlled group based on characteristics already associated with its network address.
Regarding Claim 4
Chien as modified discloses the limitations of claim 3. Chien further discloses determining a geographic location for the client device based on the second IP address, wherein at least a first characteristic of the characteristics of the client device is the geographic location (Chien ¶[0076]: determining a geographic location associated with the network communication by querying a geo-location information service with the IP address and receiving in response an indication of a location such as city, state, country, or postal code associated with the IP address; ¶[0057]: geographic locations may be determined based on the regional Internet registry that has allocated a particular IP address, or from the whois database or commercial or public geo-location services configured to provide fine-grained geographic information including country, state, city, latitude/longitude, or postal code).
Regarding Claim 8
Claim 8 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 9
Claim 9 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 10 Claim 10 is directed to a non-transitory, computer-readable medium corresponding to the method of 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 non-transitory, computer-readable medium corresponding to the method of 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 an apparatus corresponding to the method of claim 1. Claim 14 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to an apparatus corresponding to the method of claim 2. Claim 15 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 16 Claim 16 is directed to an apparatus corresponding to the method of claim 3. Claim 16 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 17 Claim 17 is directed to an apparatus corresponding to the method of claim 4. Claim 17 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 21
Chien as modified discloses the limitations of claim 14. Chien as modified further discloses wherein the instructions to apply the first policy to the packet and other network traffic with header information that includes the second IP address of the client device in the XFF field comprise instructions executable by the processor to cause the apparatus to allow, block, or throttle the packet and the other network traffic with header information that includes the second IP address in the XFF field (Devarajan: ¶[0004]: applying policies to traffic based on a dynamic association, wherein the policies include one or more of allowing, blocking, or cautioning the traffic; ¶[0118], step 3406: applying policies to traffic based on the determined user and associated organization). The rationale for combining Chien and Devarajan is the same as set forth above with respect to claim 1.
Regarding Claim 23
Claim 8 is directed to a method corresponding to the apparatus of claim 22. Claim 23 is similar in scope to claim 22 and is therefore rejected under similar rationale.
Regarding Claim 24 Claim 24 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 21. Claim 24 is similar in scope to claim 21 and is therefore rejected under similar rationale.
Claims 5, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/0146001 A1), in view of Devarajan (US 2010/0278052 A1) as applied to claim 1 above, and in further view of Douglas (US 2007/0168506 A1).
Regarding Claim 5
Chien as modified discloses the limitations of claim 1. Chien as modified does not explicitly disclose determining whether the XFF field includes an IP address or other information, wherein determining at least one of a policy and a rule based on the second IP address is based on determining that the XFF field includes an IP address. However, Douglas discloses an X-Forwarded-For field that may contain IP-address entries as well as non-IP information, expressly illustrating an X-Forwarded-For field containing the value "unknown" positioned between IP-address entries in the field's comma-separated list (Douglas: ¶[0085]-[0101]: the remote IP address of the client is identified from the HTTP remote IP unless there is an X-Forwarded-For header present, in which case the whole value of the header, which may be a comma-separated list of proxies, is passed; ¶[0278]-[0279]: an X-Forwarded-For header may already be present on an incoming request, to which a client remote IP address is appended as part of a comma-separated list, illustrated by the example value "X-Forwarded-For: 128.138.243.150, unknown, 192.52.106.30").
It would have been obvious to one having ordinary skill in the art, when using Chien's XFF field to obtain the client IP address for policy determination, to determine whether the XFF field contains an IP address rather than non-IP information before relying upon the value as the client IP address, because Douglas demonstrates that an XFF field may contain information that is not an IP address, and distinguishing a usable IP-address value from such other information would predictably avoid using a non-address value for Chien's IP-address-based policy determination.
Regarding Claim 12 Claim 12 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 18 Claim 18 is directed to an apparatus corresponding to the method of claim 5. Claim 18 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Claims 6-7, 13, 19-20, 22 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US 2018/0146001 A1), in view of Devarajan (US 2010/0278052 A1) as applied to claim 1 above, and further in view of Danisik (US 2018/0241772 A1).
Regarding Claim 6
Chien as modified discloses the limitations of claim 1. Chien further discloses wherein recording the header information is performed by a firewall (Chien: ¶[0024]: some embodiments implement at least some of the described functions in the context of a router, firewall, or other network device). Chien as modified does not explicitly disclose determining, by the firewall, that the XFF field should be recorded based, at least in part, on configuration of the firewall. However, Danisik discloses predetermining a number (n), according to a network topology, of load balancers through which a message passes in order to reach a server, and reading the Forwarded IP address from the X-Forwarded For field based on this configuration, i.e., in function of this number (n) (Danisik: ¶[0034], [0036]); and, in dependence on the predetermined number (n), conditionally reading and relying on a Forwarded IP address in an X-Forwarded For field, wherein if n is zero, the presence of an X-Forwarded-For header is instead treated as an indication of spoofing rather than relied upon, and wherein if n is greater than zero, the Forwarded IP address is read from the field and relied upon (Danisik: ¶[0079]-[0080], [0083]-[0084], [0088]).
It would have been obvious to one having ordinary skill in the art to configure Chien's firewall to determine, based on a predetermined network topology configuration as taught by Danisik, whether the XFF field should be recorded because Chien and Danisik are analogous art directed to determining a client identifying network address from an X-Forwarded-For field in a network traversing one or more intermediary devices. The motivation to combine would be to avoid recording an XFF-field address that is not trustworthy in the firewall's particular deployment configuration.
Regarding Claim 7
Chien as modified discloses the limitations of claim 6. Chien as modified does not explicitly disclose determining that the firewall is downstream from the proxy, wherein determining that the XFF field should be recorded is based on determining that the firewall is downstream. However, Danisik discloses that the predetermined number (n) of load balancers/proxies represents a network topology position, wherein n greater than zero indicates the server is positioned downstream of at least one such intermediary device, and that the Forwarded IP address is read from the X-Forwarded For field and relied upon specifically under that downstream condition (Danisik: ¶[0034], [0083]-[0084]).
It would have been obvious to one having ordinary skill in the art to configure Chien's firewall to determine that the firewall is positioned downstream from the proxy through which client traffic is received, and to base the determination of claim 6 that the XFF field should be recorded on that downstream positioning, because Danisik teaches downstream positioning relative to an intermediary device as the specific network topology condition upon which reliance on the XFF field is predicated. Same rationale applies here as above in rejecting claim 6.
Regarding Claim 13
Claim 13 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 6. Claim 13 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to an apparatus corresponding to the method of claim 6. Claim 19 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 depends from claim 19 and further recites that the apparatus comprises a firewall. Chien discloses that some embodiments implement at least some of the described functions in the context of a router, firewall, or other network device (Chien: [0024]).
Regarding Claim 22
Claim 22 is directed to an apparatus corresponding to the method of claim 7. Claim 22 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 25
Claim 25 is directed to a non-transitory, computer-readable medium corresponding to the method of claim 7. Claim 25 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Conclusion
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 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
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431
Prosecution Insights