Patent Description:
Wireless networks allow for the transfer of data between network devices. Wireless access points and corresponding wireless networks may be configured to provide access to other networks connected thereto, such as the Internet.

International Patent Application No. <CIT> is directed towards automatic configuration of a client terminal in a public hot spot.

The scope of protection of the present invention is defined by the appended claims.

Deployment and use of wireless local area networks ("WLANs" or "wireless networks") continues to grow as demands for data access increase. Some wireless networks may be configured to provide "hotspots" or areas within the range of one or more wireless access points within which connectivity to another network, such as the Internet, is available. Different hotspots may be available free of charge to the user, for a fee, or sponsored by advertisements. Access to the wireless networks in a hotspot and subsequent access to other networks such as the Internet may be subject to a user's acceptance of terms of use. These terms of use, also known as "terms and conditions," set forth an agreement between two or more entities. For example, the agreement may be between an end user and a company providing the wireless network. These terms of use may delineate appropriate use, fees, monitoring policies, usage limits, and so forth.

Some entities provide hotspots at many locations. Similarly, a given hotspot may be serviced by several different wireless networks. Traditional systems have required users to accept the terms of use each time they connect to a wireless network at a location. This is especially true of WLANs that provide free access such as in airports, museums and other public places. In some situations, these traditional systems may erroneously make a connection appear usable for access to another network, such as the Internet, when it is not. For example, a user may be shown as being connected to an access point in the hotspot, but may not have seen a presentation of terms of use. Even though appearing to be connected, traffic to an Internet-based email server will fail. As a result, user dissatisfaction and support costs may increase, as well as traffic on other networks such as wireless wide area networks ("WWANs") may increase due to an inability to successfully or easily take advantage of connectivity provided at hotspots. This situation, in turn, may result in higher costs for the users as data is transferred on the more expensive WWANs.

Described herein are systems and methods for providing secure automatic connection to wireless networks. Once a user accepts the terms of use, the system provides for automatic connectivity until such time as the terms of use have been modified. The following system may, in some implementations, be incorporated into or used in conjunction with the technical standard IEEE <NUM>. 11u-<NUM> published February <NUM>, <NUM> and promulgated by the Institute of Electrical and Electronics Engineers ("IEEE") of New York, New York, USA, or features available in products certified by the WiFi Alliance of Austin, Texas, USA such as those compliant with the "Hotspot <NUM>" standard.

<FIG> illustrates a system <NUM> to provide secure automatic connection to a wireless access point. One or more users <NUM>(<NUM>), <NUM>(<NUM>),. , <NUM>(U) are shown here. As used herein, letters enclosed by parenthesis such as "(U)" indicate an integer having a value greater than zero. Each of these users <NUM> may have one or more user devices <NUM>(<NUM>), <NUM>(<NUM>),. , <NUM>(D). The user devices <NUM> may include smartphones, laptops, desktops, tablet computers, game consoles, and so forth. The user devices <NUM> comprise one or more processors <NUM>, one or more memories <NUM>, one or more displays <NUM>, one or more input/output ("I/O") interfaces <NUM>, and one or more communication interfaces <NUM>.

The one or more processors <NUM> may each comprise one or more cores configured to access and execute at least in part instructions stored in the one or more memories <NUM>. The one or more memories <NUM> comprise one or more computer-readable storage media ("CRSM"). The one or more memories <NUM> may include, but are not limited to, random access memory ("RAM"), flash RAM, magnetic media, optical media, and so forth. The one or more memories <NUM> may be volatile in that information is retained while providing power or non-volatile in that information is retained without providing power.

The display <NUM> is configured to present visual information to the user <NUM>. The display <NUM> may comprise a liquid crystal display, plasma display, cathode ray tube, light emitting diode, and so forth.

The one or more I/O interfaces <NUM> may also be provided in the user device <NUM>. These I/O interfaces <NUM> allow for devices, such as keyboards, joysticks, touch sensors, cameras, microphones, speakers, external memories, and so forth, to be coupled to the user device <NUM>.

The one or more communication interfaces <NUM> provide for the transfer of data between the user device <NUM> and another device. The communication interfaces <NUM> may include, but are not limited to, a wireless local area network ("WLAN") interface <NUM>, a wireless wide area network ("WWAN") interface <NUM>, a wireless personal area interface ("WPAN"), (and so forth. In some implementations, the WLAN interface <NUM> may comply with at least a portion of the IEEE <NUM>. 11u standard. In some implementations, the WWAN interface <NUM> may be configured to couple to a mobile telecommunication cellular network. The communication interfaces <NUM> may utilize acoustic, radio frequency, optical, electrical, magnetic, or other signals to exchange data between the user device <NUM> and another device such as an access point.

The one or more memories <NUM> may store instructions for execution by the processor <NUM> to perform certain functions, actions, or operations. These instructions may include an operating system <NUM> configured to manage hardware resources such as the I/O interfaces <NUM> and to provide various services to applications executing on the processor <NUM>. The one or more memories <NUM> may also store a datastore <NUM> containing information about the operating system, configuration files, files indicative of acceptance to terms of service such as cookies, information about wireless networks, and so forth.

One or more applications <NUM> are stored in the one or more memories <NUM>. One or more of the applications <NUM> may be configured to scan for, identify, and connect to wireless networks; present terms of use; receive user input; and so forth. The application <NUM> may provide or utilize a user interface presented with the display <NUM> or another output device coupled to the I/O interface <NUM>.

The WLAN interface <NUM> of the user device <NUM> communicates using a wireless connection with one or more access points <NUM>(<NUM>), <NUM>(<NUM>),. , <NUM>(A). The access points may comprise one or more processors, memories, communication interfaces, antennas, and so forth. The one or more access points <NUM> provide one or more hotspots <NUM>(<NUM>), <NUM>(<NUM>),. , <NUM>(H). Each hotspot <NUM> is an area defined by a distance within which bidirectional communication between the user device <NUM> and one or more of the access points <NUM> may occur. The boundaries of the hotspot <NUM> may be defined by a radiation pattern of the antennas, shielding, and so forth. For example, a hotspot <NUM> may be provided within a coffee shop such that the user devices <NUM> inside the coffee shop or immediately adjacent may establish a wireless connection with the access point <NUM>.

In this illustration, access points <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(A) are shown. Each of these access points <NUM> are configured to communicatively couple to the user devices <NUM> which are proximate thereto, defining hotspots <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(H), respectively. In some implementations a single location may be served by wireless networks. For example, in an airport terminal several access points <NUM> operated by different entities may provide coverage to the same physical area. In another implementation, several different wireless networks may be supported from one access point <NUM>. For example, those different entities may collocate and use common access points to provide coverage.

The wireless networks established by one or more access points <NUM> are communicatively coupled to another, or to a second network <NUM>. For example, the access points <NUM> may be connected to a router coupled to the Internet. The network <NUM> may comprise a hardwired network, another wireless network, or a combination thereof. The network <NUM> may comprise a plurality of interconnected computer networks. For example, the network <NUM> may comprise the Internet, or a network coupled to the Internet. In another implementation, the network <NUM> may comprise a private network or a virtual private network. In some implementations, the network <NUM> may exchange data using transmission control protocol ("TCP"), internet protocol ("IP"), or a combination of TCP and IP.

Communicatively coupled to the network <NUM> are various devices and servers. These may include an access network query protocol ("ANQP") server <NUM>, a terms of use ("ToU") server <NUM>, an authentication, authorization, and administration ("AAA") server <NUM>, and so forth. For ease of illustration and not by way of limitation, these three devices may be referred to as access control devices <NUM>. The network <NUM> may also be coupled to other network resources <NUM> including, but not limited to, cloud resources, servers, input/output devices, and so forth. For example, the network resources <NUM> may include a virtual private networking ("VPN") server, email service provider, corporate portal, and so forth.

The ANQP server <NUM> is configured to respond to and participate in access network query protocol requests. This may include a query and response protocol which provides the user device <NUM> with information about the wireless network available at the hotspot <NUM>. This information may include, but is not limited to, the domain name of an operator of the hotspot, roaming partners, authentication methods supported, and so forth. Operation of the ANQP server <NUM> is discussed below in more detail with regard to <FIG>. In some implementations, the ANQP server <NUM> may be co-located with the access point <NUM> as well and other embodiments are also possible.

The ToU server <NUM> is configured to maintain terms of use information associated with the wireless networks at the hotspots <NUM>. This information may include documents such as service level agreements, terms and conditions, end user license agreements, geographic areas associated with the documents, expiration dates, implementation dates, and so forth. The ToU server <NUM> is configured to maintain version number information associated with the documents. This version number allows distinction between different iterations of the terms of use, for example when new terms of use supersede old terms of use. In one implementation, the ToU server <NUM> may provide version control of the terms of use. In another implementation, version control may be provided by another server. The ToU server <NUM> may provide the terms of use information in various formats including, but not limited to, hypertext markup language ("HTML"), extensible markup language ("XML"), plain text, and so forth. The ToU server <NUM> is configured to receive and respond to requests for terms of use information. The ToU server <NUM> may also be configured to generate files indicative of the user's <NUM> acceptance of the terms of use. In one implementation, this file may comprise a cookie which is provided to the user device <NUM>. In another implementation, the ToU server <NUM> may maintain a datastore indicating which user devices <NUM>, users <NUM>, or combinations thereof have accepted terms of use. The ToU server <NUM> may also be configured to provide a signal or data to the access point <NUM>, or another access control device such as a router, so that the user device <NUM> associated with the acceptance of the terms of use is transitioned from limited access to non-limited access. Operation of the ToU server <NUM> is discussed below in more detail with regard to <FIG>.

The AAA server <NUM> is configured to provide services such as authentication, authorization, administration, or a combination thereof to the user devices <NUM>. The AAA server <NUM> may be configured to provide authentication of the identity of the user device <NUM> or the user <NUM> associated therewith. The AAA server <NUM> may determine what level of access is permitted, what actions are authorized, and so forth. The AAA server <NUM> may also maintain usage and accounting records such as duration of the use of the hotspot <NUM> and billing associated with use of the hotspot. In one implementation, the AAA server <NUM> may support a robust security network ("RSN") transaction to establish a wireless encrypted connection between the user device <NUM> and the access point <NUM>. The RSNtransaction may be compliant with the IEEE <NUM>. 11i standard or Wi-Fi Protected Access II protocol ("WPA2"). Operation of the AAA server <NUM> is discussed below in more detail with regard to <FIG>.

The access control devices <NUM> are configured to manage access by the user devices <NUM> to the access points <NUM>, the network <NUM>, and in some implementations the network resources <NUM>. This access may be limited or non-limited. Limited access as used herein describes when communications are permitted between the user device <NUM> via the access point <NUM> and one or more of the access control devices <NUM>, but disallowed for the network resources <NUM>. Thus, when the user device <NUM> is subject to limited access, it is unable to access the network resources <NUM> but may still communicate with the access control devices <NUM>. In one implementation, limited access may be enforced with access control lists, port blocking, and so forth.

Non-limited access as used herein describes when communications between the user device <NUM> and the network resources <NUM> via the access points <NUM> are permitted. In some implementations, non-limited access may be subject to traffic shaping, content filtering, and so forth. For example, the user device <NUM>, which has been permitted non-limited access, may be able to establish a VPN connection with a corporate server and browse a news website, but may blocked from accessing an offshore gambling website by content filtering software.

As described herein, the servers or other devices may include, but are not limited to, processors, memories, communication interfaces, I/O devices, and so forth. It is understood that in some implementations, various functions may be combined or distributed in various ways. For example, the access point <NUM> may provide the functions described with regard to the ANQP server <NUM>, the ToU server <NUM>, the AAA server <NUM>, and so forth. The servers described herein may comprise physical servers, virtual server instances executing on a physical server, or a combination thereof.

Also, in some implementations, the access control devices <NUM> may be accessible to the access points <NUM> by way of a local or wide area network separate from the network <NUM>. For example, the access control devices <NUM> may be disposed inside or behind a firewall which, in turn, provides connectivity to the network <NUM>. In this example, the access points <NUM> and the access control devices <NUM> couple to a private network, which, in turn, couples to the network <NUM>. As described, access to the network <NUM>, and subsequently the network resources <NUM> coupled thereto, may be conditional upon acceptance of terms of use associated with the wireless network.

<FIG> illustrates a message exchange diagram <NUM> for connection to a wireless network and acceptance of terms of use associated therewith, in accordance with an embodiment of the disclosure. In this diagram, time increases along the direction of arrow <NUM>, down the page. Represented are the user <NUM>, the user device <NUM>, the access point <NUM>, the ANQP server <NUM>, the ToU server <NUM>, and the AAA server <NUM>.

At <NUM>, the user device <NUM> scans for wireless networks. This scan may include listening on one or more pre-determined channels or frequencies. In some implementations, the scan may include transmitting a signal configured to elicit a response from one or more access points <NUM>. The scan may be initiated by the user <NUM>, by a process executing on the processor <NUM> of the user device <NUM>, and so forth. For example, the user <NUM> may initiate a web browsing session on the user device <NUM>, which, in turn, attempts to connect to the Internet. Information is acquired about the wireless networks which are in range. This information may include service set identifier ("SSID"), homogenous extended service set identifier ("HESSID"), access point media access control ("MAC") address, and so forth.

At <NUM>, the information from the scan is processed to determine networks for which connection credentials have been previously acquired. As shown here, no SSID has been identified for which connection credentials are available on the user device <NUM>.

At <NUM>, at least partly in response to this lack of identified networks, the user <NUM> may be presented with a list of the wireless networks detected by the scan. The user <NUM> may select one of the wireless networks detected by the scan to attempt a connection to. In some implementations, the list of wireless networks may include information provided by the IEEE <NUM>. 11u internetworking Information Element ("IE") Access Network type field. This field may be used to indicate wireless networks which are available at no charge, available for a fee, and so forth.

At <NUM>, the user device <NUM> checks the IE Additional Steps Required for Access ("ASRA") field. Entries in this field are used to indicate that additional steps are called for to establish a connection. For example, that terms of use are required.

At <NUM>, the user device <NUM> associates itself with the wireless network by communicating at least with the access point <NUM>. Where the RSN is enabled, at <NUM>, an access network query protocol message exchange may take place between the user device <NUM> and the ANQP server <NUM>. For example, the user device <NUM> may send an ANQP message containing an "Anonymous Network Access Identifier" and "Network Authentication Type" requests. The ANQP server <NUM> returns to the user device <NUM> responses for both requests including an "Anonymous NAI Element" and a "Network Authentication Type. " If the "Network Authentication Type" query response indicates that acceptance of the terms of use is required for non-limited access to the network resources <NUM>, connection information such as an internet protocol ("IP") address, uniform resource locator ("URL"), and so forth may be returned. For example, the response may include the URL of the ToU server <NUM>.

At <NUM>, the user device <NUM> engages in RSN authentication using the anonymous authentication information acquired during <NUM>. This transaction may take place between the user device <NUM> and the AAA server <NUM>. Once the RSN authentication is configured, subsequent communications between the user device <NUM> and the access point <NUM> are encrypted. This encryption aids in protecting the privacy of data transmitted over the air. In other implementations, previously stored encryption credentials may be used to establish the encrypted connection between the user device <NUM> and the access point <NUM>.

At <NUM>, the user device <NUM> provides information to the ToU server <NUM> identifying the user device <NUM>. As described above, the user device <NUM> may determine or retrieve the address of the ToU server <NUM> using information provided by the ANQP transaction <NUM>. In one implementation, the user device <NUM> may initiate a hypertext transfer protocol secure ("HTTPS") POST message to the ToU server <NUM> using the URL drawn from the Network Authentication Type ANQP message concatenated with a session identification ("ID"). This session ID number may be used by the ToU server <NUM> to correlate various sessions as originating from the same user device <NUM>.

In one implementation, the format of the URL string posted to the ToU server <NUM> may be as follows:
https://touserver. com&sessionID=ODYzOTY3MTMx.

In this sample URL string, "https : //touserver. com" is an example URL of the ToU server <NUM>, "&sessionID=" is the exact string to append to the URL specifying the session ID parameter, and "ODYzOTY3MTMx" is the base64 encoded string of a <NUM>-bit random number (session ID value) generated by the user device <NUM>.

In some implementations, the user device <NUM> may be configured to maintain the HTTP User Agent field in an HTTP header to reflect the browser application used to render the terms of use to the user <NUM>. With this information, the ToU server <NUM> may then interpret the HTTP User Agent field to determine the display capability of the user device <NUM> and provide the terms of use in a format suited to a user interface.

At <NUM>, the ToU server <NUM> returns the terms of use data to the user device <NUM>. This information may include documents such as service level agreements, terms and conditions, end user license agreements, geographic areas associated with the documents, expiration dates, implementation dates, and so forth. These documents may be provided as one or more files including, but not limited to, content types such as "text/html," "application/xml," and "application/xhtml+xml. " In some implementations, this may include contact information associated with the user <NUM>.

At <NUM>, the user device <NUM> requests preparation of a file indicative of user acceptance, such as an opaque cookie, from the ToU server <NUM>. In some implementations, this transaction may use asynchronous Simple Object Access Protocol ("SOAP") messages over HTTPS which may include the session ID. In some implementations, the user device <NUM> may begin polling the ToU server <NUM> until a response is received by the ToU server <NUM>, such as from the user, or a timeout limit is reached. The following operation, at <NUM>, may be configured to run concurrently with the operation at <NUM>.

At <NUM>, the user device <NUM> presents the terms of use to the user <NUM>. For example, the terms of use may be presented on the display <NUM>, played using speakers coupled to the I/O interface <NUM>, and so forth. The user <NUM> may indicate acceptance of the terms of use with an input device such as a touch screen, button, and so forth coupled to the I/O interface <NUM>. In some implementations, the user <NUM> may also enter information such as a username, password, contact information, and so forth.

At <NUM>, the user device <NUM> provides the ToU server <NUM> with an indication of acceptance to the terms of use. In one implementation, this may comprise an HTTPS POST transaction between the user device <NUM> and the ToU server <NUM> which contains the user's acceptance, session ID, and so forth.

At <NUM>, the ToU server <NUM> acknowledges the user's acceptance of the terms of use, and updates data stored therein which is associated with the user device <NUM>. At least partly in response to the receipt of the user's acceptance, the ToU server <NUM> is configured to enable non-limited access by the user device <NUM> to the network resources <NUM> via the wireless network. In some implementations, the ToU server <NUM> may communicate with the access point <NUM>, routers, firewalls, or other network devices to enable the non-limited access. In some implementations, based at least in part on a particular version of the terms of use agreed to, some intermediate level of access may be provided to the network resources <NUM>. For example, a terms of use which invokes stricter content filtering at a firewall may be made available to minors.

The ToU server <NUM> may then generate a cookie or other file indicative of acceptance of the terms of use. This file may include a version number of the terms of use, user information, and metadata. In some implementations, the metadata may comprise a digital signature, configured to render the file tamper-resistant. In one implementation, the file may comprise an opaque cookie. An opaque cookie is one in which the information present therein is not meaningful to applications executing on the user device <NUM>. This lack of meaning may result from the application not being configured to interpret the information in the cookie, because the cookie is encrypted, or a combination thereof.

At <NUM>, the ToU server <NUM> returns the file indicative of acceptance, such as a cookie, to the user device <NUM>. At <NUM>, the user device <NUM> may be configured to prompt the user <NUM> to select whether to automatically connect to this wireless network in the future. Automatic connection is described in more detail below with regard to <FIG>.

At <NUM>, the user device <NUM> stores the file indicative of acceptance in the memory108. This file may be associated with identifying information associated with the wireless network. For example, the file may be associated with the SSID, HESSID, and so forth of the hotspot <NUM>.

As depicted in this illustration, the user device <NUM> was subject to limited access <NUM> to the ToU server <NUM> until the ToU server <NUM> indicated otherwise. As shown here, following the user's acceptance of the terms of use, the ToU server <NUM> permitted the user device <NUM> to transition to non-limited access <NUM>. As described above, the non-limited access <NUM> permits the user device <NUM> access to at least part of the network resources <NUM>.

<FIG> illustrates a message exchange diagram <NUM> for connection to a wireless network using previously accepted terms of use. For example, as set forth above, the user <NUM> may have previously agreed to a version of the terms of use which are in effect. In another implementation, the user may have agreed to the terms of use in another transaction or using another interface. For example, the user <NUM> may purchase from an entity a new user device <NUM>, such as a smartphone, and agree to terms of use associated with that phone. These terms of use may include terms of use for providing wireless access via hotspots <NUM> provided by or affiliated with the entity. As a result, in this implementation, the user <NUM> may have accepted the terms of use for the hotspot <NUM> prior to an attempted connection to the wireless network of the hotspot <NUM>.

In this diagram, time increases along the direction of arrow <NUM>, down the page. Represented are the user <NUM>, the user device <NUM>, the access point <NUM>, the ANQP server <NUM>, the ToU server <NUM>, and the AAA server <NUM>.

As above, at <NUM>, the user device <NUM> scans for wireless networks. At <NUM>, an autoconnect hotspot network is identified. The autoconnect network is identified as being a wireless network for which the user has accepted the terms of use and has configured for automatic connection in the future.

As above, at <NUM>, the user device <NUM> associates with the access point <NUM>. Also as above, where RSN is enabled, at <NUM> the ANQP exchange take place between the user device <NUM> and the ANQP server <NUM>. At <NUM>, the user device <NUM> engages in RSN authentication using the anonymous authentication information acquired during <NUM>. This transaction may take place between the user device <NUM> and the AAA server <NUM>.

At <NUM>, the user device <NUM> sends a copy of the file indicative of acceptance to the ToU server <NUM>. For example, the user device <NUM> may retrieve from the memory <NUM> a copy of a cookie stored as part of a previous acceptance to terms of use associated with the wireless network. The user device <NUM> may determine the address of the ToU server <NUM> from the ANQP exchange as described above, retrieve it from the memory <NUM>, determine it from contents of the cookie, and so forth.

At <NUM>, the ToU server <NUM> analyzes the information in the file indicative of acceptance to determine whether the acceptance is still valid. This may include a comparison to a previously issued file, retrieving information from a datastore, retrieving a version number from the received file and comparing with a current version number, and so forth. In this illustration, the ToU server <NUM> has indicated that the file indicative of acceptance remains valid, and provides a response to the user device <NUM>.

At <NUM>, as described above, the access point <NUM> or other device coupled to the wireless network is configured to allow non-limited access <NUM> to the user device <NUM>. As illustrated here, the user device <NUM> was able to automatically establish a secured connection with a wireless network which requires acceptance of terms of use. Thus, the user <NUM> experiences seamless connectivity with the user device <NUM> when in the hotspot <NUM>.

<FIG> illustrates a message exchange diagram <NUM> for connection to a wireless network when the terms of use have changed. As described above, the terms of use may change. These changes may result from expansion into new geographic areas, changes in the law, addition of new services, and so forth. The ToU server <NUM> is configured to maintain, or communicate with another server configured to maintain, version control over the terms of use. In one implementation, each change to the terms of use may result in an increment to a version number associated with the terms of use. These changes may include the addition or removal of text, formatting changes, and so forth.

As above, at <NUM>, the user device <NUM> scans for wireless networks. At <NUM>, an autoconnect network is identified. The autoconnect network is identified as being a wireless network for which the user has accepted the terms of use and has configured for automatic connection in the future.

As above, at <NUM>, the user device <NUM> associates with the access point <NUM>. Also as above, where RSN is enabled, at <NUM>, the ANQP exchange may take place between the user device <NUM> and the ANQP server <NUM>. At <NUM>, the user device <NUM> engages in RSN authentication using the anonymous authentication information acquired during <NUM>. This transaction may take place between the user device <NUM> and the AAA server <NUM>.

At <NUM>, the user device <NUM> sends a copy of the file indicative of acceptance to the ToU server <NUM>. For example, the user device <NUM> may retrieve from the memory <NUM> a copy of a cookie stored as part of a previous acceptance to the terms of use associated with the wireless network. The user device <NUM> may determine the address of the ToU server <NUM> from the ANQP exchange as described above, retrieve it from the memory <NUM>, determine it from contents of the cookie, and so forth. The retrieved cookie is associated with the particular version of the terms of use in effect at the time of acceptance. In some implementations, the user device <NUM> may send a request for access rather than a file indicative of acceptance. For example, the information associated with previous acceptance may be stored on the ToU server <NUM>.

At <NUM>, the ToU server <NUM> has inspected the file indicative of acceptance, or retrieved data associated with acceptance, and determined that the acceptance is no longer valid or has otherwise failed. The acceptance may be no longer valid due to a change in the version of the terms of use, an expiration date specified in the terms of use, and so forth. The ToU server <NUM> returns data indicating this failure to the user device <NUM>.

Upon receiving the data indicating failure to agree to the terms of use, at <NUM>, the user device <NUM> may provide session ID information and request from the ToU server <NUM> information about currently required terms of use. The ToU server <NUM> may respond at <NUM> with the ToU data. As described above, at <NUM>, the currently required terms of use are presented to the user <NUM>. Acceptance <NUM> from the user <NUM> may be given and received by the ToU server <NUM>, which proceeds to allow access at <NUM>.

As also described above, the ToU server <NUM>, at least partly in response to the acceptance, may provide the user device <NUM> with an updated file indicative of acceptance at <NUM>. At <NUM>, the user <NUM> may be presented with the option to autoconnect in the future to this network. Once approved, at <NUM>, the updated file indicative of the response is stored in the memory <NUM>. As described above, in some implementations, data indicative of acceptance may be stored at the ToU server <NUM> or elsewhere.

<FIG> illustrates a block diagram of the contents associated with a request <NUM> for a file indicative of acceptance. The request <NUM> may be sent as one or more files. The user device <NUM> may provide the request <NUM> to the ToU server <NUM> or another device. This file may be sent as part of the transaction <NUM> described above.

The request <NUM> may include a version number <NUM>, session ID <NUM>, and other information <NUM>. The version number <NUM> may indicate a particular set of terms of use. In some implementations, the version number <NUM> may be provided as part of a subscription provisioning protocol ("SPP"). The SPP may be configured to administer and provide version numbers associated with changes to the terms of use. In one implementation, the SPP version number may be chosen by a subscription server based at least in part on a "supportedSPPVVersions" element of a "sppPostDevData" message.

The session ID <NUM> may be generated by the user device <NUM>. As described above, the session ID <NUM> allows the ToU server <NUM> to associate a particular transaction with a particular user device <NUM>. The user device <NUM> may be configured to utilize this session ID during HTTP connections to provide for this association. Other information <NUM> may be included, such as an expected duration of access, maximum fee authorized, listing of services access is being requested for, and so forth.

In some implementations, the other information <NUM> may include a tcCookie value as described below. This may be used to identify a particular response. The tcCookie may comprise a base64 encoded string.

<FIG> illustrates a block diagram of the contents of a response <NUM> for a file indicative of acceptance. The response <NUM> may be sent as one or more files. The user device <NUM> may receive from the ToU server <NUM>, or another device, this file indicative of acceptance by the user <NUM> of the terms of use associated with the wireless network. This file may be received as part of the transaction <NUM> described above.

The response <NUM> may include a version number <NUM>, a status <NUM>, the session identification <NUM>, a tcCookie <NUM>, and other information <NUM>. The version number <NUM> may indicate a particular set of terms of use which are in effect at the time connectivity is requested. As described above, in some implementations, the version number <NUM> may be provided as part of an SPP transaction.

The status <NUM> may be used to indicate a status associated with providing the response <NUM>. The session identification <NUM> in the response <NUM> is that described above with regard to <FIG>, and provides a common point of reference which may be used to associate the user device <NUM> with the acceptance of the terms of use.

The tcCookie <NUM> may also be included in the response <NUM>. This may be a string generated by the ToU server <NUM>. In some implementations, this value may be based at least in part on the session identification <NUM>. The tcCookie <NUM> may be configured so that it is opaque to the user device <NUM>.

Other information <NUM> may also be included in the response <NUM> such as error codes associated with the response, the duration access that is granted. and so forth. For example, when the response <NUM> indicates non-acceptance of the terms and conditions, the error code may indicate this condition.

<FIG> is a flow diagram of an illustrative process <NUM> of automatically connecting to a wireless network, in accordance with an embodiment of the disclosure. This process may be implemented by the user device <NUM> in some implementations.

Block <NUM> connects to a wireless network coupled to second network. The second network may comprise a plurality of interconnected computer networks. For example, the WLAN interface <NUM> in the user device <NUM> may wirelessly connect to the access point <NUM>(<NUM>) of the hotspot <NUM>(<NUM>). The access point <NUM>(<NUM>), in turn, is coupled to the network <NUM> which provides access to the access control devices <NUM> and the network resources <NUM>. As described above, the connection may involve an ANQP transaction, RSN transaction, and so forth.

Block <NUM> determines whether the current terms of use associated with the wireless network have been previously accepted. The terms of use comprise an agreement between two or more entities, such as the user and an operator of the wireless network. The terms of use are previously accepted when they have been agreed to by the user <NUM>, an authorized delegate of the user <NUM>, a parent, a guardian, a supervisor, or received from the user device <NUM> associated with the user <NUM>. As described above, this may include acceptance using the user device <NUM>, or acceptance via another avenue, such as purchase of a smartphone.

When block <NUM> determines the current terms of use have been previously accepted, the process may proceed to block <NUM>. Block <NUM> transfers data to one or more devices coupled to the second network via a non-limited access connection between the wireless network and the second network. The non-limited access connection provides the non-limited access described above. For example, where the first network comprises the wireless network and the second network comprises the Internet, the user device <NUM> may now access the network resources <NUM> via the Internet.

Returning to block <NUM>, when the current terms of use associated with the wireless network are not accepted, the process proceeds to block <NUM>. The terms of use may not be accepted due to the user <NUM> not having accepted the terms of use before, from a previous declining use of the terms of use, due to changes to the terms of use, and so forth.

Block <NUM> receives, via a limited access connection between the wireless network and the second network, the terms of use of the wireless network from one or more access control devices coupled to the second network. For example, the user device <NUM> may receive the terms of use data from the ToU server <NUM>. In other implementations, the terms of use may be stored in other devices, such as being cached at the access point <NUM>.

Because of the limited access connection, the user device <NUM> at this point is unable to connect to the network resources <NUM>. As described above, the limited access connection is configured to allow passage of data traffic to the one or more access control devices <NUM> and to prevent passage of data traffic to other devices, such as the network resources <NUM>. As also described above, the one or more access control devices <NUM> may comprise one or more of an access point <NUM>, an ANQP server <NUM>, a ToU server <NUM>, and one or more AAA servers <NUM>.

Block <NUM> presents at least a portion of the terms of use. The terms of use may be presented to the user <NUM>, an authorized delegate of the user <NUM>, a parent, a guardian, a supervisor, and so forth.

Block <NUM> receives acceptance of the terms of use as presented. For example, the user <NUM> may use one or more input devices of the user device <NUM>, such as a keyboard, touch screen, voice input, and so forth, to indicate acceptance of the terms of use. When the user <NUM> does not indicate acceptance, such as through no response or with a negative response, the limited access may be continued. In another implementation, failure to accept may result in discontinuation of the limited access.

Block <NUM> sends data indicative of the acceptance via the limited access connection to the one or more access control devices <NUM> coupled to the second network. For example, the user device <NUM> may send acceptance as described above with regard to acceptance at block <NUM>. Following this, the user device <NUM> may be granted non-limited access, and the process proceeds to block <NUM>.

In some implementations, after completion of block <NUM>, a file indicative of acceptance, such as a cookie, may be received from the one or more access control devices <NUM> via the limited access connection. This file may then be stored in the memory <NUM> of the user device <NUM>.

The operations and processes described and shown above may be carried out or performed in any suitable order as desired in various implementations. Additionally, in certain implementations, at least a portion of the operations may be carried out in parallel. Furthermore, in certain implementations, less than or more than the operations described may be performed.

Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some implementations.

These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable storage media or memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, certain implementations may provide for a computer program product, comprising a computer-readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.

Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, can be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions.

Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and/or operations. Thus, such conditional language is not generally intended to imply that features, elements, and/or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or operations are included or are to be performed in any particular implementation.

Claim 1:
A user device (<NUM>) comprising:
at least one memory (<NUM>) that stores computer-executable instructions; and
at least one processor (<NUM>) configured to access the at least one memory (<NUM>), wherein the at least one processor (<NUM>) is configured to execute the computer-executable instructions (<NUM>) to:
connect the user device (<NUM>) to a wireless network coupled to a second network (<NUM>), the connection of the device to the wireless network being via an access point (<NUM>) and a corresponding hotspot (<NUM>) and wherein the connection comprises performing a scan for wireless networks and performing an access network query protocol, ANQP, exchange;
when current terms of use associated with the wireless network are previously accepted by a user of the device:
transfer data (<NUM>) from the user device (<NUM>) to one or more devices coupled to the second network via a non-limited access connection between the wireless network and the second network;
when current terms of use associated with the hotspot (<NUM>) of the wireless network are unaccepted:
receive (<NUM>) at the user device (<NUM>), via a limited access connection between the wireless network and the second network (<NUM>), the current terms of use of the wireless network from one or more access control devices (<NUM>(<NUM>), <NUM>(<NUM>), ...<NUM>(A)) coupled to the second network (<NUM>) wherein the limited access connection is configured to allow passage of data traffic to the one or more access control devices (<NUM>) and to prevent passage of data traffic to other devices of the second network;
present (<NUM>) at least a portion of the current terms of use to a user; upon receiving acceptance of the current terms of use by a user at the user device (<NUM>);
send data indicative of the acceptance via the limited access connection from the user device (<NUM>) to the one or more access control devices (<NUM>)) coupled to the second network (<NUM>); and
transfer data from the user device (<NUM>) to one or more devices connected to the wireless network and coupled to the second network (<NUM>) via a non-limited access connection or an intermediate level access connection between the wireless network and the second network (<NUM>), wherein the intermediate level access connection is based at least in part on the current terms of use accepted.