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 .
This office action is responsive to a response filed on November 17th, 2025. In this office action:
Claims 1-20 are pending.
Claims 1-20 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on August 21st, 2025:
Claim 11 was objected to because of an informality.
Claims 1-20 were rejected on the ground of the non-provisional nonstatutory double patenting.
Claims 1-20 were rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
Claims 1-20 were rejected under 35 U.S.C. 112(b), second paragraph, as being indefinite.
Claims 1-2, 10-11, and 19 were rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Shi et al. (Pub. No. US 2018/0324144), hereinafter Shi.
Claims 3-8 and 12-17 were rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (Pub. No. US 2018/0324144), hereinafter Shi; in view of Howard et al. (Pub. No. US 2009/0249484), hereinafter Howard.
Claims 9, 18, and 20 were rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (Pub. No. US 2018/0324144), hereinafter Shi; in view of Kanabar et al. (Pub. No. US 2015/0131519), hereinafter Kanabar.
Response to Amendment
The amendments filed on November 17th, 2025 have been entered.
Claims 1-8, 10-17 and 19 have been amended.
The previously raised claim objection is withdrawn for claim 11 in light of the amendments.
The previously raised Double Patenting rejection is withdrawn. Applicant has filed a Terminal Disclaimed on November 17th, 2025.
The previously raised 35 U.S.C. 112(a) rejection is withdrawn for claims 1-20 in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection is withdrawn for claims 1-20 in light of the amendments.
Response to Arguments
Applicant Arguments/Remarks, filed on November 17th, 2025, have been fully considered by the Examiner, and are moot in view of new grounds of rejection, as presented in this Office Action.
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, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-2, 4-5, 8, 10-11, 13-14, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Setia et al. (Pub. No. US 2013/0111024), hereinafter Setia; in view of Marcy et al. (Pub. No. US 2016/0285841), hereinafter Marcy.
Claim 1. Setia discloses [a] computer-implemented method implemented via one or more processors of a controller of a visitor-based communication service (See Fig. 5; “Processor”), the method comprising:
obtaining an identification of one or more uniform resource identifier (URI) textual characteristics that correspond to an increased likelihood of a Hypertext Transfer Protocol (HTTP) request from an electronic device being a captivity probe transmitted by the electronic device to detect network captivity (See Parag. [0035-0036]; AP 320 would keep a whitelist 370, which initially includes only the statically configured domain name (e.g., "domain1.com") corresponding to captive portal 330. [W]hen a first user, user A 352 (electronic device), sends request 361 to AP 320, requesting to access an external website that is not included in wall garden 340 ... AP 320 dynamically analyzes and processes response 363 to generate an updated whitelist 375. Specifically, AP 320 scans the source code of response 363 received from captive portal 330 for any tags that indicate a hyperlink. The tags could be associated with any text, image, icon, object, web control, etc. Subsequently, AP 320 extracts the portion of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL ... During this operation, only unique web domain names will be inserted, and sub domains and/or web pages are truncated from the URL ... AP 320 will insert additional domain names such as "domain1.com" and "domain2.com" to the updated whitelist. See Parag. [0032]; dynamically build a whitelist corresponding to a wall garden associated with the captive portal. The whitelist would typically include the web domain corresponding to captive portal web page 200, e.g., http://www.captive_portal_website.com as illustrated in FIG. 2. In addition, the system can insert the web domains corresponding to the extracted URLs into the whitelist. See Parag. [0037-0038]; “authentication,” “HTTP request.” See also Parag. [0004] [0014-0016] [0019] [0024-0033] [0038]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication. As taught by Setia, the AP builds and dynamically updates a whitelist to include unique domain names (e.g., "domain1.com") by extracting portions of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL, where the whitelist would include web domains that are likely to be associated with HTTP requests from users to determine if a network requires authentication);
obtaining, via a client electronic device, an HTTP request comprising a URI (See also Parag. [0038]; user A 352 does not possess sufficient credential to satisfy the authentication requirement of captive portal web page 200, but decides that he/she would rather like to visit http://www.domain1.com/subdomain/main.html. Thus, user A 352 sends out a new request 365. See also Parag. [0019]);
determining whether the obtained HTTP request comprises a captivity probe based at least in part on at least one of:
a determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe, or a determination of whether the URI is included in either a first stored URI list or a second stored URI list, the first stored URI list corresponding to URIs identified as corresponding to captivity probes, and the second stored URI list corresponding to URIs identified as not corresponding to captivity probes (See Parag. [0038]; AP 320 receives new request 365 from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375 (a first stored URI list). See also Parag. [0019]); and
handling, based at least in part on determining whether the obtained HTTP request comprises the captivity probe, the obtained HTTP request, wherein handling the obtained HTTP request comprises one of:
directing one or more response messages to the client electronic device to cause the client electronic device to be redirected in the visitor-based communication service (See Parag. [0021]; If, however, the Internet website that wireless client attempts to access is not within walled garden or a whitelist, access point will redirect the request to captive portal server. Captive portal server will then reply with captive portal web page. See Parag. [0035-0037]; AP 320 determines that the requested external website does not exist in whitelist 370, and therefore redirects request 362 to statically configured captive portal 330. Captive portal 330 receives redirected request and sends a response ... AP 320 relays response back to user A 352 at wireless station 310. Response may require user A 352's authentication and/or payment, or which may display a user policy that requires user A 352 to consent. See also Parag. [0004] [0056]), or
allowing the obtained HTTP request to proceed to a destination indicated by the URI (See Parag. [0038]; Because whitelist 375 has been updated to include both "domain1.com" and "domain2.com", AP 320 will determine that the requested page in request 365 is within the wall garden. Therefore, AP 320 will allow user A 352's request and pass through request 366 to wall garden 340. See also Parag. [0019-0020]).
Setia doesn’t explicitly disclose the HTTP request from the electronic device is automatically transmitted by the electronic device to detect network captivity.
However, Marcy discloses a Hypertext Transfer Protocol (HTTP) request from an electronic device automatically transmitted by the electronic device to detect network captivity (See Parag. [0015]; The content streaming device may first establish a connection with the wireless network, which will be assumed to be a Wi-Fi network for explanatory purposes. For example, a user may select the network from a listing of wireless networks available for connection or the content streaming device may automatically establish the connection. The content streaming device may then generate an HTTP GET request for a particular web page that contains a known sequence of characters. The HTTP GET request may be received by a wireless router associated with the Wi-Fi network. The wireless router may determine that the content streaming device has not been authenticated on the network and may redirect the HTTP request to a host server hosting a captive portal page ... See also Parag. [0018]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the HTTP request from the electronic device being a captivity probe transmitted by the electronic device to detect network captivity, taught by Setia, to be automatically transmitted by the electronic device, as taught by Marcy. This would be convenient in implementing a secure network requiring a user device to be authenticated prior to permitting the user device to access the Internet (Marcy, Parag. [0006] [0014]).
Claim 2. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia further discloses wherein handling the obtained HTTP request is based at least in part on the determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe (See Parag. [0035-0036]; AP 320 would keep a whitelist 370, which initially includes only the statically configured domain name[s] corresponding to captive portal 330 ... See Parag. [0038]; AP 320 receives new request 365 (i.e., HTTP request) from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375. See also Parag. [0019]. Examiner’s interpretation: The Examiner reasonably interprets the checking performed by the AP by comparing the extracted domain name (e.g., "domain1.com") requested with domain names in the walled garden or a whitelist associated with captive portal server to be equivalent to “determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics”), and wherein handling the obtained HTTP comprises directing the one or more response messages to the client electronic device to cause the client electronic device to be redirected in the visitor-based communication service, in response to determining that the URI does not exhibit the one or more URI textual characteristics (See Parag. [0021]; If, however, the Internet website that wireless client attempts to access is not within walled garden or a whitelist, access point will redirect the request to captive portal server. Captive portal server will then reply with captive portal web page. See Parag. [0035-0037]; ... when a first user, user A 352, sends request to AP 320, requesting to access an external website that is not included in wall garden 340. After AP 320 receives the request, AP 320 checks whitelist 370 to determine whether the requested external website exists in whitelist 370 at that time. In this case, AP 320 determines that the requested external website does not exist in whitelist 370, and therefore redirects request to statically configured captive portal 330. Captive portal 330 receives redirected request and sends a response ... AP 320 relays response back to user A 352 at wireless station 310. Response may require user A 352's authentication and/or payment, or which may display a user policy that requires user A 352 to consent. See Parag. [0004] [0056]. Examiner’s interpretation: The Examiner reasonably interprets “determining that the URI does not exhibit the one or more URI textual characteristics” as determining that the requested website (extracted domain name (e.g., "domain1.com")) does not exist in whitelist as it doesn’t match URIs in the walled garden or a whitelist).
Claim 4. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia further discloses wherein handling the obtained HTTP request is based at least in part on the determination of whether the URI is included in either the first stored URI list or the second stored URI list (See Parag. [0038]; AP 320 receives new request 365 from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375 (the first stored URI list)).
Claim 5. Setia in view of Marcy discloses [t]he computer-implemented method of claim 4,
Setia further discloses wherein handling the obtained HTTP request comprises allowing the obtained HTTP request to proceed to the destination, in response to determining that the obtained HTTP request comprises a captivity probe based at least in part on the URI being included in the first stored URI list (See Parag. [0038]; AP 320 compares the extracted domain name to the updated whitelist 375 (the first stored URI list). Because whitelist 375 has been updated to include both "domain1.com" and "domain2.com", AP 320 will determine that the requested page in request 365 is within the wall garden. Therefore, AP 320 will allow user A 352's request and pass through request 366 to wall garden 340. See also Parag. [0019-0020]).
Claim 8. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia further discloses wherein the one or more URI textual characteristics comprise at least one of an indicator of a static URI or a URI character count of less than or equal to a predefined threshold (See Parag. [0032]; The whitelist would typically include the web domain corresponding to captive portal web page 200, e.g., http://www.captive_portal_website.com as illustrated in FIG. 2. In addition, the system can insert the web domains corresponding to the extracted URLs into the whitelist. In some embodiments, the disclosed system will also automatically remove redundant domain names, and only insert unique web domains. In some embodiments, the URLs are analyzed and processed to obtain only the web domain name by removing any sub domain names and/or web file names. For example, the sub domain name ("subdomain") and the web file name ("main.html") from the URLs in "Link 3" 250 and "Link 4" 260 will be removed to obtain the domain name ("domain1.com") correspond to both "Link 3" 250 and "Link 4" 260. Note that, in some websites, the sub domain names may be in a format like http://subdomain.domain1.com. When analyzing and processing such URLs, the subdomain portion of the URL will be removed to obtain the domain name ("domain1.com"). See also Parag. [0036] [0038]. Examiner’s interpretation: The Examiner interpreted the claim as “wherein the one or more URI textual characteristics comprise an indicator of a static URI.” The Examiner interpreted a static URI as a permanent and unchanging URI, meaning it consistently points to the same resource over time without relying on variable parameters or dynamic content generation. In addition, according to Applicant specification, in Parag. [0026], “Static URLs, unlike dynamic URLs, do not contain a query string, do not contain PHP, and do not contain special characters (“?” and “=”),” which is consistent with the teachings of Setia disclosing URLs are analyzed and processed to obtain only the web domain name by removing any sub domain names and/or web file names to obtain a unique domain name ("domain1.com"), as described above).
Claim 10. Setia discloses [o]ne or more non-transitory computer readable media storing instructions that, when executed via one or more processors of a controller of a visitor-based communication service (See Parag. [0050] and Fig. 5; a processor 530 capable of processing computing instructions, and a memory 540 capable of storing instructions), cause the controller to:
obtain an identification of one or more uniform resource identifier (URI) textual characteristics that correspond to an increased likelihood of a Hypertext Transfer Protocol (HTTP) request from an electronic device being a captivity probe transmitted by the electronic device to detect network captivity (See Parag. [0035-0036]; AP 320 would keep a whitelist 370, which initially includes only the statically configured domain name (e.g., "domain1.com") corresponding to captive portal 330. when a first user, user A 352 (electronic device), sends request 361 to AP 320, requesting to access an external website that is not included in wall garden 340 ... AP 320 dynamically analyzes and processes response 363 to generate an updated whitelist 375. Specifically, AP 320 scans the source code of response 363 received from captive portal 330 for any tags that indicate a hyperlink. The tags could be associated with any text, image, icon, object, web control, etc. Subsequently, AP 320 extracts the portion of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL ... During this operation, only unique web domain names will be inserted, and sub domains and/or web pages are truncated from the URL ... AP 320 will insert additional domain names such as "domain1.com" and "domain2.com" to the updated whitelist. See Parag. [0032]; dynamically build a whitelist corresponding to a wall garden associated with the captive portal. The whitelist would typically include the web domain corresponding to captive portal web page 200, e.g., http://www.captive_portal_website.com as illustrated in FIG. 2. In addition, the system can insert the web domains corresponding to the extracted URLs into the whitelist. See Parag. [0037-0038]; “authentication,” “HTTP request.” See also Parag. [0004] [0014-0016] [0019] [0024-0033] [0038]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication. As taught by Setia, the AP builds and dynamically updates a whitelist to include unique domain names (e.g., "domain1.com") by extracting portions of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL, where the whitelist would include web domains that are likely to be associated with HTTP requests from users to determine if a network requires authentication);
obtain, via a client electronic device, an HTTP request comprising a URI (See also Parag. [0038]; user A 352 does not possess sufficient credential to satisfy the authentication requirement of captive portal web page 200, but decides that he/she would rather like to visit http://www.domain1.com/subdomain/main.html. Thus, user A 352 sends out a new request 365. See also Parag. [0019]);
determine whether the obtained HTTP request comprises a captivity probe based at least in part on at least one of:
a determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe, or a determination of whether the URI is included in either a first stored URI list or a second stored URI list, the first stored URI list corresponding to URIs identified as corresponding to captivity probes, and the second stored URI list corresponding to URIs identified as not corresponding to captivity probes (See Parag. [0038]; AP 320 receives new request 365 from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375 (a first stored URI list). See also Parag. [0019]); and
handle, based at least in part on determining whether the obtained HTTP request comprises the captivity probe, the obtained HTTP request, wherein the instructions to handle the obtained HTTP request comprise instructions to either:
direct one or more response messages to the client electronic device to cause the client electronic device to be redirected in the visitor-based communication service (See Parag. [0021]; If, however, the Internet website that wireless client attempts to access is not within walled garden or a whitelist, access point will redirect the request to captive portal server. Captive portal server will then reply with captive portal web page. See Parag. [0035-0037]; AP 320 determines that the requested external website does not exist in whitelist 370, and therefore redirects request 362 to statically configured captive portal 330. Captive portal 330 receives redirected request and sends a response ... AP 320 relays response back to user A 352 at wireless station 310. Response may require user A 352's authentication and/or payment, or which may display a user policy that requires user A 352 to consent. See also Parag. [0004] [0056]), or
allow the obtained HTTP request to proceed to a destination indicated by the URI (See Parag. [0038]; Because whitelist 375 has been updated to include both "domain1.com" and "domain2.com", AP 320 will determine that the requested page in request 365 is within the wall garden. Therefore, AP 320 will allow user A 352's request and pass through request 366 to wall garden 340. See also Parag. [0019-0020]).
Setia doesn’t explicitly disclose the HTTP request from the electronic device is automatically transmitted by the electronic device to detect network captivity.
However, Marcy discloses a Hypertext Transfer Protocol (HTTP) request from an electronic device automatically transmitted by the electronic device to detect network captivity (See Parag. [0015]; The content streaming device may first establish a connection with the wireless network, which will be assumed to be a Wi-Fi network for explanatory purposes. For example, a user may select the network from a listing of wireless networks available for connection or the content streaming device may automatically establish the connection. The content streaming device may then generate an HTTP GET request for a particular web page that contains a known sequence of characters. The HTTP GET request may be received by a wireless router associated with the Wi-Fi network. The wireless router may determine that the content streaming device has not been authenticated on the network and may redirect the HTTP request to a host server hosting a captive portal page ... See also Parag. [0018]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the HTTP request from the electronic device being a captivity probe transmitted by the electronic device to detect network captivity, taught by Setia, to be automatically transmitted by the electronic device, as taught by Marcy. This would be convenient in implementing a secure network requiring a user device to be authenticated prior to permitting the user device to access the Internet (Marcy, Parag. [0006] [0014]).
Claim 11 is taught by Setia in view of Marcy as described for claim 2.
Claim 13 is taught by Setia in view of Marcy as described for claim 4.
Claim 14 is taught by Setia in view of Marcy as described for claim 5.
Claim 17 is taught by Setia in view of Marcy as described for claim 8.
Claim 19. Setia discloses [a] controller device of a visitor-based communication service, the controller device comprising:
one or more processors; and one or more memories storing instructions that, when executed via the one or more processors (See Parag. [0050] and Fig. 5; a processor 530 capable of processing computing instructions, and a memory 540 capable of storing instructions), cause the controller device to:
obtain an identification of one or more uniform resource identifier (URI) textual characteristics that correspond to an increased likelihood of a Hypertext Transfer Protocol (HTTP) request from an electronic device being a captivity probe transmitted by the electronic device to detect network captivity (See Parag. [0035-0036]; AP 320 would keep a whitelist 370, which initially includes only the statically configured domain name (e.g., "domain1.com") corresponding to captive portal 330. [W]hen a first user, user A 352 (electronic device), sends request 361 to AP 320, requesting to access an external website that is not included in wall garden 340 ... AP 320 dynamically analyzes and processes response 363 to generate an updated whitelist 375. Specifically, AP 320 scans the source code of response 363 received from captive portal 330 for any tags that indicate a hyperlink. The tags could be associated with any text, image, icon, object, web control, etc. Subsequently, AP 320 extracts the portion of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL ... During this operation, only unique web domain names will be inserted, and sub domains and/or web pages are truncated from the URL ... AP 320 will insert additional domain names such as "domain1.com" and "domain2.com" to the updated whitelist. See Parag. [0032]; dynamically build a whitelist corresponding to a wall garden associated with the captive portal. The whitelist would typically include the web domain corresponding to captive portal web page 200, e.g., http://www.captive_portal_website.com as illustrated in FIG. 2. In addition, the system can insert the web domains corresponding to the extracted URLs into the whitelist. See Parag. [0037-0038]; “authentication,” “HTTP request.” See also Parag. [0004] [0014-0016] [0019] [0024-0033] [0038]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication. As taught by Setia, the AP builds and dynamically updates a whitelist to include unique domain names (e.g., "domain1.com") by extracting portions of the tag that includes the URL, and identifies the web domain corresponding to the extracted URL, where the whitelist would include web domains that are likely to be associated with HTTP requests from users to determine if a network requires authentication);
obtain, via a client electronic device, an HTTP request comprising a URI (See also Parag. [0038]; user A 352 does not possess sufficient credential to satisfy the authentication requirement of captive portal web page 200, but decides that he/she would rather like to visit http://www.domain1.com/subdomain/main.html. Thus, user A 352 sends out a new request 365. See also Parag. [0019]);
determine whether the obtained HTTP request comprises a captivity probe based at least in part on at least one of:
a determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe, or a determination of whether the URI is included in either a first stored URI list or a second stored URI list, the first stored URI list corresponding to URIs identified as corresponding to captivity probes, and the second stored URI list corresponding to URIs identified as not corresponding to captivity probes (See Parag. [0038]; AP 320 receives new request 365 from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375 (a first stored URI list). See also Parag. [0019]); and
handle, based at least in part on determining whether the obtained HTTP request comprises the captivity probe, the obtained HTTP request, wherein the instructions to handle the obtained HTTP request comprise instructions to either:
direct one or more response messages to the client electronic device to cause the client electronic device to be redirected in the visitor-based communication service (See Parag. [0021]; If, however, the Internet website that wireless client attempts to access is not within walled garden or a whitelist, access point will redirect the request to captive portal server. Captive portal server will then reply with captive portal web page. See Parag. [0035-0037]; AP 320 determines that the requested external website does not exist in whitelist 370, and therefore redirects request 362 to statically configured captive portal 330. Captive portal 330 receives redirected request and sends a response ... AP 320 relays response back to user A 352 at wireless station 310. Response may require user A 352's authentication and/or payment, or which may display a user policy that requires user A 352 to consent. See also Parag. [0004] [0056]), or
allow the obtained HTTP request to proceed to a destination indicated by the URI (See Parag. [0038]; Because whitelist 375 has been updated to include both "domain1.com" and "domain2.com", AP 320 will determine that the requested page in request 365 is within the wall garden. Therefore, AP 320 will allow user A 352's request and pass through request 366 to wall garden 340. See also Parag. [0019-0020]).
Setia doesn’t explicitly disclose the HTTP request from the electronic device is automatically transmitted by the electronic device to detect network captivity.
However, Marcy discloses a Hypertext Transfer Protocol (HTTP) request from an electronic device automatically transmitted by the electronic device to detect network captivity (See Parag. [0015]; The content streaming device may first establish a connection with the wireless network, which will be assumed to be a Wi-Fi network for explanatory purposes. For example, a user may select the network from a listing of wireless networks available for connection or the content streaming device may automatically establish the connection. The content streaming device may then generate an HTTP GET request for a particular web page that contains a known sequence of characters. The HTTP GET request may be received by a wireless router associated with the Wi-Fi network. The wireless router may determine that the content streaming device has not been authenticated on the network and may redirect the HTTP request to a host server hosting a captive portal page ... See also Parag. [0018]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the HTTP request from the electronic device being a captivity probe transmitted by the electronic device to detect network captivity, taught by Setia, to be automatically transmitted by the electronic device, as taught by Marcy. This would be convenient in implementing a secure network requiring a user device to be authenticated prior to permitting the user device to access the Internet (Marcy, Parag. [0006] [0014]).
Claims 3, 6-7, 12, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Setia et al. (Pub. No. US 2013/0111024), hereinafter Setia; in view of Marcy et al. (Pub. No. US 2016/0285841), hereinafter Marcy; and further in view of Howard et al. (Pub. No. US 2009/0249484), hereinafter Howard.
Claim 3. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia further discloses wherein determining whether the obtained HTTP request comprises a captivity probe is based at least in part on the determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe (See Parag. [0035-0036]; AP 320 would keep a whitelist 370, which initially includes only the statically configured domain name[s] corresponding to captive portal 330 ... See Parag. [0038]; AP 320 receives new request 365 (i.e., HTTP request) from user A 352. AP 320 will then extract the domain name (i.e., "domain1.com" in this example) corresponding to the website or web page that user A 352 requested to visit in request 365. Next, AP 320 compares the extracted domain name to the updated whitelist 375. See also Parag. [0019]. Examiner’s interpretation: The Examiner reasonably interprets the checking performed by the AP by comparing the extracted domain name (e.g., "domain1.com") requested with domain names in the walled garden or a whitelist associated with captive portal server. Therefore, the determination performed by the AP is interpreted to be equivalent to “determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics”), but Setia in view of Marcy doesn’t explicitly disclose the determination is in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list.
However, Howard discloses wherein determining whether the obtained HTTP request comprises a captivity probe is based at least in part on the determination, in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list, of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe (See Parag. [0106-0111]; a client in the client facility 144 may request access to a computing resource (e.g., request for a URI) ... restrictions in the policy management facility 112 are reviewed in relation to the client request. In an example, the restrictions in the policy management facility 112 may include a list of URIs. At step three 204, it is decided whether the client request for access to a URI http://abcd.com should be allowed or denied based on the restrictions in the policy management facility 112; if the URI http://abcd.com is in the list of restricted URIs with respect to a client request, the client request may be denied. In another embodiment, the network access rules facility 124 may be used to provide the client in the client facility 144 with access to the requested URI ... if the URI http://abcd.com is not in the list of restricted URIs with respect to a client request, the process flow proceeds to step four 208 and step five 210. At step four 208, contextual information related to the client request is stored; the administration facility 134 may extract the contextual information (i.e., extracted from a URI included in the client request, See Parag. [0007]) and store it in the policy management facility 112 ... the scanning facility may utilize the stored contextual information to scan the retrieved content, to make an informed decision about granting the client in the client facility 144 access to the requested URI. See Parag. [0080]; [N]etwork access rules facility 124 may include databases such as a block list, a black list, an allowed list, a white list, an unacceptable network site database, an acceptable network site database, a network site reputation database, or the like of network access locations (i.e., a plurality of lists) ... the network access rules facility 124 may incorporate rule evaluation; the rule evaluation may parse network access requests and apply the parsed information to network access rules. The network access rule facility 124 may have a generic set of rules that may be in support of an enterprise facility's 102 network access policies ... Rule evaluation may include regular expression rule evaluation, or other rule evaluation method for interpreting the network access request and comparing the interpretation to the established rules for network access ... See Parag. [0070]; a policy database may be a block list, a black list, an allowed list, a white list, or the like that may provide a list of enterprise facility 102 external network locations/applications that may or may not be accessed by the client facility 144 ... See Parag. [0093]; rules for determining access to enterprise facility 102 computing resources, including authentication, levels of access. See also Parag. [0004] [0079] [0100] ... Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining whether the obtained HTTP request comprises a captivity probe is based at least in part on the determination of whether the URI of the obtained HTTP request exhibits the one or more URI textual characteristics corresponding to the increased likelihood of the obtained HTTP request being a captivity probe, taught by Setia in view of Marcy, to be in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list, as taught by Howard. This would be convenient to provide an improved method and system to detect restricted content associated with retrieved content (Howard, Parag. [0006]).
Claim 6. Setia in view of Marcy discloses [t]he computer-implemented method of claim 4,
Setia further discloses wherein handling the obtained HTTP request comprises directing the one or more response messages to the client electronic device to cause the client electronic device to be redirected in the visitor-based communication service, in response to determining that the obtained HTTP request does not comprise a captivity probe (See Parag. [0021]; If, however, the Internet website that wireless client attempts to access is not within walled garden or a whitelist (determining that the obtained HTTP request does not comprise a captivity probe), access point will redirect the request to captive portal server. Captive portal server will then reply with captive portal web page. See Parag. [0035-0037]; AP 320 determines that the requested external website does not exist in whitelist 370, and therefore redirects request 362 to statically configured captive portal 330. Captive portal 330 receives redirected request and sends a response ... AP 320 relays response back to user A 352 at wireless station 310. Response may require user A 352's authentication and/or payment, or which may display a user policy that requires user A 352 to consent. See also Parag. [0004] [0056]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication).
Setia in view of Marcy doesn’t explicitly disclose determining that the obtained HTTP request does not comprise a captivity probe [is] based at least in part on the URI being included in the second stored URI list.
However, Howard discloses determining that the obtained HTTP request does not comprise a captivity probe based at least in part on the URI being included in the second stored URI list (See Parag. [0106-0111]; a client in the client facility 144 may request access to a computing resource (e.g., request for a URI) ... restrictions in the policy management facility 112 are reviewed in relation to the client request. In an example, the restrictions in the policy management facility 112 may include a list of URIs. At step three 204, it is decided whether the client request for access to a URI http://abcd.com should be allowed or denied based on the restrictions in the policy management facility 112; if the URI http://abcd.com is in the list of restricted URIs with respect to a client request, the client request may be denied ... The network access rules facility 124 may have a generic set of rules that may be in support of an enterprise facility's 102 network access policies, such as denying access to certain types of URIs. See Parag. [0070]; a policy database may be a block list, a black list, an allowed list, a white list, or the like that may provide a list of enterprise facility 102 external network locations/applications that may or may not be accessed by the client facility 144 ... See Parag. [0093]; rules for determining access to enterprise facility 102 computing resources, including authentication, levels of access. See also Parag. [0004] [0079-0080] [0100]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining that the obtained HTTP request does not comprise a captivity probe, taught by Setia in view of Marcy, to be based at least in part on the URI being included in the second stored URI list, as taught by Howard. This would be convenient to provide an improved method and system to detect restricted content associated with retrieved content (Howard, Parag. [0006]).
Claim 7. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia in view of Marcy doesn’t explicitly disclose wherein handling the obtained HTTP request comprises allowing the obtained HTTP request to proceed to the destination, in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list, and determining that the URI exhibits the one or more URI textual characteristics.
However, Howard discloses wherein handling the obtained HTTP request comprises allowing the obtained HTTP request to proceed to the destination, in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list, and determining that the URI exhibits the one or more URI textual characteristics (See Parag. [0106-0111]; a client in the client facility 144 may request access to a computing resource (e.g., request for a URI) ... restrictions in the policy management facility 112 are reviewed in relation to the client request. In an example, the restrictions in the policy management facility 112 may include a list of URIs. At step three 204, it is decided whether the client request for access to a URI http://abcd.com should be allowed or denied based on the restrictions in the policy management facility 112; ... if the URI http://abcd.com is not in the list of restricted URIs with respect to a client request, the process flow proceeds to step four 208 and step five 210. At step four 208, contextual information related to the client request is stored; the administration facility 134 may extract the contextual information (i.e., extracted from a URI included in the client request, See Parag. [0007]) and store it in the policy management facility 112 ... the scanning facility may utilize the stored contextual information to scan the retrieved content, to make an informed decision about granting (allowing the obtained HTTP request to proceed to the destination) the client in the client facility 144 access to the requested URI (determining that the URI exhibits the one or more URI textual characteristics) ... See Parag. [0080]; [N]etwork access rules facility 124 may include databases such as a block list, a black list, an allowed list, a white list, an unacceptable network site database, an acceptable network site database, a network site reputation database, or the like of network access locations (i.e., a plurality of lists) ... the network access rules facility 124 may incorporate rule evaluation; the rule evaluation may parse network access requests and apply the parsed information to network access rules. The network access rule facility 124 may have a generic set of rules that may be in support of an enterprise facility's 102 network access policies ... Rule evaluation may include regular expression rule evaluation, or other rule evaluation method for interpreting the network access request and comparing the interpretation to the established rules for network access ... See Parag. [0093]; rules for determining access to enterprise facility 102 computing resources, including authentication, levels of access. See also Parag. [0004] [0100]. Examiner’s interpretation: The Examiner interprets the claimed captivity probe as equivalent to using HTTP probes to specific URIs to determine if a network requires authentication).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify handling the obtained HTTP request, taught by Setia in view of Marcy, to comprise allowing the obtained HTTP request to proceed to the destination, in response to determining that the URI is neither included in the first stored URI list nor included in the second stored URI list, and determining that the URI exhibits the one or more URI textual characteristics, as taught by Howard. This would be convenient to provide an improved method and system to detect restricted content associated with retrieved content (Howard, Parag. [0006]).
Claim 12 is taught by Setia in view of Marcy and Howard as described for claim 3.
Claim 15 is taught by Setia in view of Marcy and Howard as described for claim 6.
Claim 16 is taught by Setia in view of Marcy and Howard as described for claim 7.
Claims 9, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Setia et al. (Pub. No. US 2013/0111024), hereinafter Setia; in view of Marcy et al. (Pub. No. US 2016/0285841), hereinafter Marcy; and further in view of Walsh et al. (Pub. No. US 2014/0053243), hereinafter Walsh.
Claim 9. Setia in view of Marcy discloses [t]he computer-implemented method of claim 1,
Setia in view of Marcy doesn’t explicitly disclose wherein the visitor-based communication service provides communication services to client electronic devices in a cabin of an aircraft.
However, Walsh discloses wherein the visitor-based communication service provides communication services to client electronic devices in a cabin of an aircraft (See Parag. [0011]; In a Restricted Local Area Network environment, such as a captive portal, it is often necessary to access a resource from a special Web site on the Internet in order to activate or use a service that is offered in the Restricted Local Area Network. The captive portal environment exists where there is only a single available communication service that is available to the user. An example of a captive portal environment is on board an aircraft in flight, where the passengers have no access to any communication services, other than the aircraft resident wireless Local Area Network. See also Parag. [0018]; aircraft cabin with the plurality of passenger wireless communications devices 121-124).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the visitor-based communication service, taught by Setia in view of Marcy, to provides communication services to client electronic devices in a cabin of an aircraft, as taught by Walsh. This would be convenient to provide reliable, effective, cost-efficient way of delivering temporary captive portal Internet access to a selected Web site to only retrieve an application for use exclusively in the Restricted Local Area Network (Walsh, Parag. [0005]), and for Providing Temporary Internet Access [f]rom a Restricted Local Area Network Environment (termed "Restricted LAN Internet Access System" herein) which functions to grant the user a temporary Internet session so they can download a prerequisite application from a selected Web site to only make use of the application to access a service resident on the Restricted LAN, such as In-Flight Entertainment Content on the aircraft (Walsh, Parag. [0006]).
Claim 18 is taught by Setia in view of Marcy and Walsh as described for claim 9.
Claim 20 is taught by Setia in view of Marcy and Walsh as described for claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Toksvig et al. (Pub. No. US 2015/0012640) – Related art in the area of scaling for elastic query service system, (Abstract; In one embodiment, a method includes detecting interception of data sent by the computing device to a first network resource through a communication network. The first network resource corresponds to a particular domain of the communication network. The method also includes determining whether the communication network is administered by the particular domain; and automatically generating a request to access the communication network that identifies a second network resource based at least in part on the determination. The second network resource is configured to authenticate a user to the particular domain of the communication network. The method also includes sending the request to the second network resource to access the communication network.).
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 ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. 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 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.
/Abdelbasst Talioua/Examiner, Art Unit 2445