WO2001052071A1

WO2001052071A1 - System and method for managing network access

Info

Publication number: WO2001052071A1
Application number: PCT/US2001/000730
Authority: WO
Inventors: Dory E. Leifer; Allan C. Rubens; David J. Carson; Richard L. M. Herrell; Todd A. Bachmann; Larry J. Blunk; Kimberly C. Jevons
Original assignee: Tut Systems, Inc.
Priority date: 2000-01-13
Filing date: 2001-01-08
Publication date: 2001-07-19
Also published as: WO2001052071A9; EP1250650A1; AU2001226383A1; JP2003519871A; TWI223941B

Abstract

The method and system involve a policy server and a service gateway which send messages to one another via a user's network access application program. In one embodiment, the network access application program is an Internet web browser (2). The service gateway receives a network access request from a user and sends an authorization request message regarding the user to a policy server via the user's network application program (4). In one embodiment, the network access request is an Internet web site access request. The service gateway will then, if the policy server grants access, receive from the user's network access application program an authorization granted message regarding the user that was initiated by the policy server (8). The service gateway will then provide the user access to a network such as the Internet (12). The policy server receives an authorization request message from a user's network access application program that was initiated by the service gateway. The policy server processes payment information received from the user and, assuming that the payment information is sufficient, provides an authorization granted message regarding the user to the service gateway via the user's network access application program.

Description

SYSTEM AND METHOD FOR MANAGING NETWORK ACCESS

Related Application

This application claims the benefit of United States Provisional Application No. 60/177,187 filed January 13, 2000.

Field of the Invention

The invention relates to the field of managing network access. More specifically, the invention relates to a system and method for receiving payment to provide access to a network such as the Internet. Background

The Internet and personal computers have become ubiquitous in modern society. Although the Internet has existed in various forms for many years, the Internet became popular as a mass communication vehicle with the introduction of the world wide web. The world wide web is, from a user's perspective, a way of easily identifying a remote computer, connecting to the remote computer, and viewing information stored on the remote computer.

While using the Internet, hidden from the user are the various communications protocols that make the Internet function. Various committees and ad hoc groups known as working groups coordinate and control the Internet. Working groups under the Internet Engineering Task Force (IETF) determine the rules and protocols for the underlying functionality of the Internet and publish them as requests for comment, commonly referred to as RFCs. RFCs are exclusively available via the Internet at various web sites.

Web sites are specified by a text description or name referred to as a uniform resource locator (URL) that is now encompassed by the term uniform resource identifier (URI). (See Uniform Resource Identifiers (URD: Generic Syntax. RFC 2396, August 1998, Draft Standard, http://www.rfc-editor.org/rfc/rfc2396.txt). Generally, information may be communicated over the Internet via the user datagram protocol (UDP), the transmission control protocol/Internet protocol (TCP IP), and the hypertext transfer protocol (HTTP), which operates over TCP. More information is available from J. Postel, User Datagram Protocol. RFC 768, August 28, 1980, http://www.rfc- editor.org/rfc/rfc768.txt; T. Socolofsky and C. Kale, A TCP/IP Tutorial. RFC 1180, January 1991, http://www.ief.org/rfc/rfcll80.txt; R. Fielding etal, Hypertext Transfer Protocol - HTTP/1.1. RFC 2616, June 1999 (Draft Standard), http://www. ietf. org/rfc/rfc2616. txt.

As use of the world wide web over the Internet has been increasing, the demand for high-speed Internet access has been increasing. Although persons and small businesses may want higher speed Internet access, many are unwilling to pay the costs associated with obtaining a high-speed Internet connection such as, for example, a cable modem, digital subscriber line (DSL), Tl line, etc. A way to provide Internet users in multi-occupant, multi-room or shared buildings such as apartments, office buildings, dorm rooms and the like with high-speed Internet access is to allow multiple users at one location to share access to a high-speed Internet connection. These Internet users may be willing and able to provide payment for access to the Internet, particularly if the costs may be shared with others using the same high-speed access method.

In addition, as computer users are mobile and travel with portable computers and other personal computing devices, users may wish to access network resources, such as Internet web servers, from locations remote from their home or office, such as, for example, hotels. In addition, some locations, such as, for example, hotels, may provide network access for a visiting user's temporary, as needed, on demand use. Such users may wish to access network resources, such as Internet web servers, and the location may provide this network access. These computer users may be willing and able to provide payment for access to the Internet, and the locations may be similarly willing to provide Internet access, so long as they can be compensated for their costs or make a profit.

BRIEF SUMMARY OF THE INVENTION

In various embodiments, the method and system of the present invention allow an owner or operator of a multi-occupant, multi-room building to provide shared high speed access to a network such as the Internet. The method and system involve a policy server n Qf-vr_Λ/ir'f*_' cmfpπrnxr wrsifYi cp*nr1 mpcoαw C tn

αnntlipr IM Q ΠOΛ-T' O α /-*•.- o^pe gateway will then provide the user access to a network such as the Internet. The policy server receives an authorization request message from a user's network access application program that was initiated by the service gateway. The policy server processes payment information received from the user and, assuming that the payment information is sufficient, provides an authorization granted message regarding the user to the service gateway via the user's network access application program.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates the flow of actions taken according to an embodiment of the system and method of the present invention.

Figure 2 illustrates the network architecture of an embodiment of a system and method of the present invention.

Figures 3A and 3B illustrate the flow of actions of a service gateway and a policy server taken according to an embodiment of the system and method of the present invention.

DETAILED DESCRIPTION

A. A System and Method of Managing Access to the Internet

In various embodiments, the method and system of the present invention allow an owner or operator of a multi-occupant, multi-room building to provide shared high speed access to a network such as the Internet. For example, a guest in a hotel room may be provided a high speed connection to the Internet. In another example, a renter in an apartment or office building may be provided similar access. Similarly, in yet another example, a student in a dorm room may be provided similar access.

Figure 1 illustrates the flow of actions taken according to an embodiment of the system and method of the present invention. The user, a guest, renter, etc. may plug in a computer, be it a laptop, desktop, personal computing device, etc., to a line providing direct network access, boot up the computer and start a network access application program such as an Internet web browser, intending to access a web site. In one embodiment, the user issues a network access request by specifying a web site in the web browser, as shown in block 2. Instead of the specified web page of the web site appearing on the user's screen, a web page provided by the hotel, the property management company, etc. appears, instructing the user to agree to be charged for Internet access for a certain time period, for example until checkout time, for a total number of hours, or until a specified date and time. More specifically, in one embodiment, a service gateway at the site of the multi-occupant dwelling intercepts the web site request and redirects the user's web browser to a policy server such that the user's web browser sends an authorization request message to the policy server, as shown in block 4. The policy server then provides a web page to the user requesting payment information and usage information, as shown in block 5. This web pages contains a hidden reference to the policy server such that when the user enters payment information and usage information, the user unknowingly submits the payment information to a policy server, as shown in block 6. It is this policy server, remotely situated on the Internet, that may grant or deny the user access to the Internet. If the user agrees to accept the charges and provides the requested payment and usage information, the policy server authorizes the user to have access to the Internet, as shown in block 8. The policy server then instructs the service gateway that the user is to be given access to the Internet by redirecting the user's web browser to notify the service gateway that the user' is to be granted Internet access, as shown in block 10. In one embodiment, this is achieved by the policy server sending a message to the user's web browser which causes the user's web browser, to unknown to the user, provide an authorization granted message to the service gateway. In this way, the guest's computer is granted access to the Internet by the service gateway for the period of authorization, such as, for example, until check-out, until a specified date and time, and for a specified number of days or hours. The service gateway may then provide confirmation of access to the user via a web page, and, in one embodiment, may provide a default start web page, and, in another embodiment, may redirect the user's web browser to the web site initially requested by the user, as shown in block 12.

B. A Network Architecture of A System and Method of Managing Access to the Internet

Figure 2 illustrates the network architecture of an embodiment of a system and method of the present invention. According to one embodiment of the present invention, the system and method involves a plurality of user computers 40, only three of which are depicted, a hub 48, a policy server 34, and a service gateway 14. In one embodiment, a policy server 34, and a service gateway 14 are attached to the Internet 50. Such attachment is made according to methods known to those skilled in the art, including but not limited to connection by Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), cable modem, Tl line, T3 line, etc. In another environment, wireless communication may also be used. In an alternative embodiment, policy server 34 and service gateway 14 may be connected to one another by any means of computer communication that allows for data to be communicated between them. Such connections include, but are not limited to, leased lines, etc. In one embodiment, multiple policy servers 34 and service gateways 14 may participate in the method of the present invention, particularly when the multi-occupant building is large and/or when the entity that own the dwellings and owns or hires the policy servers owns multiple buildings or owns geographically distant buildings. In addition, multiple hubs 48 or similar devices such as multiplexors, concentrators and the like may be connected to one or more service gateways.

In one embodiment, the method is implemented as software stored in and executed by policy server 34 and service gateway 14. Policy server 34 and service gateway 14 may each be any server computer that can execute software programs and access a communications network such as the Internet. In one embodiment, service gateway 14 comprises processor 15 and memory 16. Processor 15 may be any computer processor, and memory 16 may be any random access memory (RAM) or other readable and writeable memory device.

Processor 15 executes the software that implements the method of the present invention utilizing memory 16, Information, including software that implements the method of the present invention, is read from and written to disk drive 17 which is coupled to disk controller 18. Disk drive 17 may be a hard disk drive, a readable and writeable compact disk (CDRW) drive, a floppy disk drive, a stick or card memory device, a digital audio tape (DAT) reader, etc., or any other machine readable medium local to the processor, as well as remotely connected by a network or any method of communication. The processor may communicate instructions to display controller 20 to display images on display device 22. Display controller 20 may be any display controller, and display device 22 may be any display monitor, including, but not limited to, a cathode ray tube (CRT) display monitor, or thin film transistor (TFT) display screen. A system administrator or other similar person may access payment system server 14 via any computer input device, such as, for example, keyboard 24 and mouse 26 which are coupled to the processor by I/O controller 28.

Service gateway 14 also includes network interface 30. In this embodiment, service gateway 14 communicates with a network, a wide area network, or, in one embodiment, the Internet 50. Network interface 30 may be a digital modem, a cable modem, an Ethernet card, or any other kind of network access device that allows for connection to the Internet 50 via a digital subscriber line (DSL), cable television line, Tl line, T3 line, or any other high speed, dedicated line capable of communicating information over a network. In another environment, wireless communication may also be used. Processor 15, memory 16, disk controller 18, display controller 20, I O controller 28, and network interface 30 may be coupled to one another via and communicate with one another over bus 32. Bus 32 may be any bus that provides for communication of and between components within a computer. Although only one bus is depicted, multiple buses may be used in service gateway 14. In addition, other components and controllers (not depicted) or multiple instances of depicted components and controllers may be included in service gateway 14. In one embodiment, service gateway 14 communicates over the Internet via network interface 30 and receives information from and communicates information to devices connected to the Internet such as policy server 34 and web servers (not shown).

In one embodiment, each of service gateway 14, policy server 34 and user computer 40 include software that allows for communication over the Internet 50. In one embodiment, this includes software that provides for communication via the hyper-text transfer protocol (HTTP), the user datagram protocol (UDP), the transmission connect protocol/internet protocol (TCP/IP), and/or other network communications protocols.

Although only one service gateway 14 is depicted, a system that implements the service gateway of the present invention may be comprised of multiple computers in the form of a local area network (LAN), cluster, grouping, subnetwork, etc. (not shown). This system, in the form of a grouping, cluster, LAN, subnetwork, etc. may be connected to the Internet or other global communications network, in one embodiment, via one or more firewalls or other security devices and systems so that the server is separated from the Internet and other computers for security purposes. This system may be comprised of graphics servers, application servers and other specialized, dedicated servers (not shown).

Although only one policy server 34 is depicted, a system that implements the policy server of the present invention may be comprised of multiple computers in the form of a local area network (LAN), cluster, grouping, subnetwork, etc. (not shown). This system, in the form of a grouping, cluster, LAN, subnetwork, etc. may be connected to the Internet or other global communications network, in one embodiment, via one or more firewalls or other security devices and systems so that the server is separated from the Internet and other computers for security purposes. This system may be comprised of graphics servers, application servers and other specialized, dedicated servers (not shown).

User computer 40 may be any personal computer having components and features similar to service gateway 14. In addition, user computer 40 may be any personal computing device that can execute programs and access a network such as the Internet, including, but not limited to, cellular telephones, personal digital assistants, desktop personal computers, portable computers, computer tablets, computer headsets, laptop computers, computer workstations, etc.

To access service gateway 14, user computer 40 runs a network access application program such as Internet web browsing software, an example of which is Netscape Communicator^® available from Netscape Communications of Mountain View, California, in addition to software that allows for accessing the Internet as described above.

C. The Functioning of A Service Gateway and A Policy Server

Figures 3A and 3B illustrate the flow of actions of a service gateway and a policy server taken according to an embodiment of the system and method of the present invention. Upon powering up, a service gateway sets all ports to an unauthorized state, as shown in block 52. This state signifies that the computing devices attached via ports are not authorized to access the internet. In this way, the service gateway prohibits Internet access by computing devices attached via ports that are in the unauthorized state. In one embodiment, upon power up, the service gateway may consult with its own internal database and place those ports having time remaining or having not reached an agreed- upon expiration date and time in the authorized state. The service gateway may then receive a web site access request from a user over a port, as shown in block 54. This request is, in one embodiment, a URL specifying a web site. If the port on which the web access request is received is in the unauthorized state, the service gateway generates an authorization request message (AR-MSG) and sends a redirection instruction to the user redirecting the user's web browser to send the AR-MSG to a policy server, as shown in block 56. In one embodiment, the redirection instruction is in the form of a URL containing an HTTP redirect to the policy server and also includes as keywords the fields of the AR-MSG. The policy server specified may be determined by the configuration of the service gateway, the specific access port, the current load of various policy servers, or other factors. The policy server receives the AR-MSG, validates the message, and requests payment information and usage information from the user, as shown in block 58. In one embodiment, the policy server provides a web page to the user to request the payment information and usage information. In this embodiment, when the user submits this information via the web page, the payment information and usage information will be sent to the policy server. In one embodiment, the payment information and usage information is transmitted from the user to the policy server in an encrypted format, such as according to secured sockets layer (SSL) encryption and the transport layer security (TLS) protocol provided via the user's web browser. More information on SSL is available from Netscape Communications of Mountain View, California, and additional information concerning TLS is available in E. Rescorla, HTTP Over TLS. RFC 2818, May 2000, http://www.ietf.org/rfc/rfc2818.txt. The policy server then receives the payment information and usage information from the user and processes the AR-MSG, the payment information and the usage information, as shown in block 59.

Based on this processing, the policy server then makes a determination as to whether authorization to access the Internet should be granted, as shown in block 60. The policy server, may make this determination using an internal policy database. The structure of the policy database may be any way of storing, retrieving and maintaining the information needed to process the AR-MSG. In one embodiment, the policy server may communicate with a credit card processing company, financial institution or other similar entity to verify that the payment information is accurate, is not fraudulent and/or that there are sufficient funds or credit available. In various embodiments, this may include the policy server consulting with blacklists maintained internally and/or accessed by communicating with a third party computer.

If the policy server does not grant authorization to the user, the policy server sends an access refused web page to the user, as shown in block 62. No message is sent to the service gateway as the port for the user was initialized as unauthorized to access the Internet. If authorization is granted by the policy server, the policy server generates an authorization granted message (AG-MSG) and, in one embodiment, sends a redirection instruction to the user's web browser to send the AG-MSG to the service gateway, as shown in block 64. This redirection instruction is in the form of a URL that includes as keywords the fields of the AG-MSG. In another embodiment, policy server presents the user with a web page via the user's web browser that has an HTML link that points to the service gateway that contains the AG-MSG. For example, the user may be presented with a web page that states "Click Here To Access the Internet." When the user clicks on or otherwise activates the link associated with this web page, the user's browser sends the AG-MSG to the service gateway. In any of these embodiments, the user is not privy to the sequence of events and actions taken. The service gateway then receives the AG-MSG from the user (unknown to the user), validates the message, and transitions the user's port to the authorized state, as shown in block 66.

After receiving the AG-MSG, the service gateway may provide a welcome web page and may also, after displaying a welcome web page for a short time, provide the web page initially requested by the user, as shown in block 68. The service gateway then provides Internet access to the user, as shown in block 70. In one embodiment, the service gateway may also act as a firewall, preventing unwanted access to the user's computer. The service gateway periodically checks to determine whether the authorization granted to the user has expired, as shown in block 72. If authorization has not expired, the service gateway continues providing Internet access to the user, as shown in block 70. If the authorization for the user has expired, such as, for example, when the user checks out of a hotel room, when a user specified number of hours of use has expired, or when a user specified end date and time has been reached, the service gateway may send an access expired web page to the user and set the user's port to the unauthorized state, so that further access to the Internet by the user will be denied by the service gateway, as shown in block 74.

In one embodiment, the system and method operate completely through the sending of HTTP messages. Although the AR-MSG is initiated by the service gateway and is received by the policy server, and although the AG-MSG is initiated by the policy server and received by the service gateway, there is no direct communication addressed between the policy server and the service gateway. These messages, as discussed above, are both sent via the web browser of a user's computer.

Since all communications may be ferried by the client's browser, every message is both visible and potentially alterable by the user. For example, the user could attempt to gain network access without the involvement of the policy server by passing a fraudulent authorization granting message to the service gateway. To protect against this type of attack, in one embodiment, each message generated and communicated by the policy server and the service gateway may contain a message digest 5 (MD5) digital signature and may incorporate a shared secret. Validation of the message is achieved by checking the signature upon message receipt. Additional information concerning MD5 is available in R. Rivest, The MD5 Message-Digest Algorithm. RFC 1321, April 1992, http://www.ietf.org/rfc/rfcl321.txt. The shared secret is known only by the policy server and the gateway server and is hidden from the user. In this way, the user will not be able to produce fraudulent messages. Similarly, to prevent an unscrupulous user from repeating or replicating a valid message previously properly received, each message may contain a random sequence number which, if repeated, will cause the message to be ignored by the service gateway. Checking the sequence number is part of message validation.

In the service gateway, in one embodiment, each port is designated as being in one of two states, authorized and unauthorized. In the unauthorized state, a computer connected via the port in the unauthorized state is allowed only restricted Internet access. In the authorized state, a computer connected via the port in the unauthorized state is allowed unrestricted Internet access. In one embodiment, each logical port is initialized to the unauthorized state. A port enters the authorized state upon reception of a valid granting message from the policy server. The logical port returns to unauthorized state when authorization expires, when the user is disconnected from the service gateway, when a system operator intervenes, and upon reinitialization.

In one embodiment, either or both the policy server and the service gateway may implement the remote authentication dial in user service (RADIUS) protocol. RADIUS may be used by the service gateway to authenticate and maintain administrative information for each of the ports through which users may be granted Internet access. The service gateway may maintain information regarding each logical port, including state information, expiration information such as time remaining or date and time of expiration, user identifying information, etc. RADIUS may be used by the policy servers to manage information concerning the users for which access has been granted and which service gateways are providing the users with Internet access. In addition, policy servers may use RADIUS for obtaining, processing and maintaining the payment information and usage information. Information regarding RADIUS is available in C. Rigney, et al, Remote Authentication Dial In User Service fRADIUSl RFC 2865, June 2000, http://www. ietf. org/rfc/rfc2865. txt.

D. The Authorization Request Message An AR-MSG is generated by the service gateway on behalf of the user that is requesting Internet access. In one embodiment, the AR-MSG and the URL string that constitutes the AR-MSG may include some or all of the following fields/keywords: a port identifier ("port"), a host identifier ("host"), a mac address ("mac"), an initial URL designation ("origurl"), a sequence number ("seq"), a digital signature ("sig"), and a version number ("ver").

In one embodiment, the AR-MSG in the form of a URL string may include the port through which the user connects to a service gateway, specified as an alphanumeric field in American Standard Code for Information Interchange (ASCII) format. This value may be set to indicate which physical or logical access port through which the user attaches to the service gateway. The port identifier may be designated in any form so long as it is unique to the particular port attached to the service gateway. For example, if a service gateway has logical or physical connections to several access concentrators, and a user is attached to port 5, the following may be encoded: "port=switch3_port5", specifying that it is the fifth port of the third concentrator. In another embodiment, if the port value is unknown it may be omitted from the message entirely.

In one embodiment, a host may be specified as a text name or an IP address comprised of ASCII characters in the URL string comprising an AR-MSG. The host name or IP address specified is the name or address of the service gateway. If the service gateway is multihomed, meaning that it has more than one IP address, the IP address supplied in the host value must be an address reachable by the user. An example of a host identifier in text is '"host'=sg3-mainstreet.hotel.isp.net" and as an IP address is "'host'=192.23.12.3".

In one embodiment, the "mac" field of the URL string comprising an AR-MSG refers to the Institute of Electrical and Electronics Engineers (IEEE) 802 media access control ("MAC") hardware address of the node of the user's network connection. Generally, JJEEE 802 is referred to as the Ethernet networking standard. In other embodiments, other physical node addresses may be used. In another embodiment, if the "mac" address is unknown, it may be omitted from the message. In one embodiment, the original "url" which the user specified before being redirected is placed in a field comprised of ASCII characters that may be named "origurl", such as, for example, "origurl=http ://w w w .uspto . gov" . In one embodiment, the service gateway may provide a 64 bit non-repeating sequence number as a field in the URL string comprising an AR-MSG. The sequence number is set upon system initialization to a random value so as not to repeat sequences from earlier initializations and uses. In one embodiment, the sequence number may be provided in a field designated as "seq" and may be encoded as a 16 octet ASCII hexadecimal value representing an eight octet binary value in hexadecimal, for example, "seq=002d41e4650000219d4e".

In one embodiment, the URL string comprising an AR-MSG may include an MD5 digital signature that is computed using the AR-MSG URL string starting with the first keyword, omitting the signature parameter (i.e., in one embodiment, the keyword "sig" and its parameter), followed by the shared secret. That is, "sig" = MD5 (message+shared secret), where "+" denotes concatenation.

In one embodiment, the service gateway may provide a protocol version value in the URL. In one embodiment, the version may be designated by "ver" followed by a numeric sequence in ASCII decimal, such as, for example, "ver=0".

A summary of the AR-MSG keywords, including a description, encoding and size in one embodiment, is set forth in Table 1.

Table 1. AR-MSG Keywords

In one embodiment, the AR-MSG message prepared by the service gateway and directed to the policy server may be in the form of a URL query and may be formatted as: http://hostname?keywordl=valuel&keyword2=value2&keyword3=value3 ... key wordN=valueN

E. The Authorization Grant Message

In one embodiment, an AG-MSG is generated by the policy server to grant Internet access to the user, and is sent to the user to be ferried to the service gateway. Upon receipt of an AG-MSG, the service gateway transitions the state of the port specified in the message to the authorized state. In one embodiment, the policy server sends an AG-MSG to the service gateway via the user's web browser. In doing so, the policy server communicates a URL string to the user containing information that constitutes an AG- MSG. In this URL string, a destination service gateway is identified as the originator of a corresponding AR-MSG.

In one embodiment, the AG-MSG and the URL string which accomplishes the sending of an AG-MSG may include some or all of the following keywords/fields: a host identifier ("host"), a sequence number ("seq"), a digital signature ("sig"), a version number ("ver"), a time value ("time"), a user identifier ("id"), a maximum data rate parameter also referred to as bandwidth, and a destination URL ("url").

In one embodiment, the service gateway receives the AG-MSG as a URL string from a user that was initiated by a policy server. The service gateway may verify the signature ("sig") field value of the URL string comprising an AR-MSG by, in one embodiment, computing an MD5 hash on the received message starting with the first keyword and appending the appropriate shared secret for the hostname specified in the host field ("host"). That is, MD5 (message+shared secret), where "+" denotes concatenation. In addition to verifying the validity of the signature, the service gateway may also verify a sequence number ("seq") in the URL string comprising an AG-MSG to ensure that it matches the sequence number of an earlier sent AR-MSG. If the sequence number matches, the service gateway sets the logical port parameters as described by the fields specified in the AG-MSG and sets the logical port through which the user connects to the service gateway to the authorized state. In one embodiment, fields of the AR-MSG that are not understood are silently ignored by the service gateway. If a destination "url" is specified in the AG-MSG, the service gateway may direct the user to this destination URL. In this way, the service gateway may provide an opening screen such as a hotel or real estate management company web site of the entity managing the property at which the user is located. In one embodiment, a host may be specified in an AG-MSG as a text name or an IP address comprised of ASCII characters. In one embodiment, the policy server may include its own hostname or IP address. The format is similar to the "host" field in the AR-MSG. In one embodiment, the policy server may echo back the 64 bit non-repeating sequence number ("seq") provided in the AR-MSG.

In one embodiment, the AG-MSG may include an MD5 signature field ("sig") that is computed as in the AR-MSG. In one embodiment, the AG-MSG may include a protocol version value ("ver") in ASCII decimal format.

In one embodiment, the AG-MSG may include a time parameter ("time"). In one embodiment, the time parameter may specify the maximum total number of hours and/or minutes for which the authorization to access the Internet is granted. In other embodiments, the time parameter may specify the date and time when authorized access to the internet expires, such as on February 2, 2000 at 2:00 p.m. In one embodiment, the format of the time parameter is an alphanumeric sequence in ASCII decimal format. For example, "time=60" corresponding to 60 minutes or one hour; and "time=020220001400" corresponding to February 2, 2000 at 2:00 p.m. In these examples, the user's internet access via the specified port will expire after 60 minutes or at the specified date and time.

In one embodiment, the AG-MSG may include a user identifier ("id"). In one embodiment, the user identifier may identify a logical port. In other embodiments, the identifier may be a session identifier, a user name, an JP number of the user's connection, an account number for the user, a room number, etc. The user identifier may be stored by the service gateway and may be presented in management messages or other processing within the service gateway, in other communications with the policy server, in accounting functions, and any other uses. Examples of user identifiers include: "id=joe_smith", "id=5", and "id=1234567". Further, in other embodiments multiple user identifiers may be used to store similar information, such as "idl" for room number, "id2" for user name, "id3" for account number, etc. These identifiers may be ASCII and ASCII decimal in various embodiments.

In one embodiment, the AG-MSG may include a parameter to specify the maximum data rate or bandwidth for both sending and receiving communications from the user. The value may be specified in kilobits per second (Kbps) or megabits per second (Mbps) and may be an ASCII decimal value. An example of the maximum data rate field is "bandwidth=32". In this example, the user's connection is described as having maximum transmit and receive speeds of 32 Kbps. In one embodiment, the bandwidth keyword may be an ASCII string that identifies a traffic shaping profile that may exist on the service gateway. In this embodiment, the shaping profile may contain, for example, transmit and/or receive queue depths, committed rates, discard rates, and other computer communications parameters and information.

In one embodiment, the AG-MSG may include a destination URL designation in a "url" field. The destination URL may be any domain name which provides a web site, such as the web site of a hotel or real estate management company of the entity managing the property at which the user is located. In other embodiments, any other web page may be specified. An example of a "url" field is "url=http://www.somehotel.com".

A summary of the AG-MSG keywords, including a description, encoding and size in one embodiment, is set forth in Table 2.

Table 2. AG-MSG Keywords

In one embodiment, the AG-MSG message prepared by the service gateway and directed to the policy server may be in the form of a URL query and may be formatted as: http://hostname?keywordl=value 1 &keyword2=value2&key word3=*value3 ... kevwordN=valueN F. An Example

The system and method of the present invention may be understood by review of the following example. In this example, a user in a multi-occupant building may plug a computer into a wall socket which is connected to an access concentrator. The concentrator may be connected to a service gateway having IP address 35.42.42.42 with host name somehotel.com. The service gateway may be associated with a policy server having IP address 192.168.254.249 and host name hotelpolicyserver.com. After the user opens a web browser and specifies a web page such as http://www.tutsys.com. The service gateway may intercept the web page specification. If the port at which the request was made is not in the authorized state, the user is denied access to the Internet. However, the service gateway prepares an AR-MSG which is sent to the user as an HTTP redirect message such as:

http://hotelpolicyserver.com/pp/welcome.php3 ?port= 192.168.254.211 - 02007&host=somehotel.com&mac=00a00cll47fl&origurL=www%2etutsys%2ec Om%2f&seq=1828d81492b2c044461fd709f0a5637b&sig=6d39e8d81bfbfcad490e 908ec60d6d7a

The user's browser executes this URL. In response, the policy server provides a web page providing welcome information and requesting payment information and usage information. In one embodiment, this payment information may be an agreement to charge a specific fee to the user's hotel room bill, may prompt the user to enter credit card information, etc. This may be achieved via a web page using popular user interface techniques such as graphics, text, text entry fields, pull down menus, buttons, sliders, and the like. In one embodiment, common gateway interface (CGI) scripts JAVA® applets, and other web page techniques may be incorporated. After providing payment information and usage information, the user must then accept the terms of usage and submit the payment information and the usage information. This may be achieved by clicking on a button in the web page, or by other user interface techniques. By submitting the information a link or web site reference associated with the web page is activated that directs the user's web browser to send the payment information to the policy server.

The policy server then processes the payment information and the usage information. The policy server then either decides to grant or deny Internet access to the user. If access is denied, the policy server communicates a connection refused web page to the user. If access is granted, the policy server generates an AG-MSG in the format of a URL containing an HTTP query and communicates the URL to the user's browser which redirects the user to the service gateway:

http://servicegw.somehotel.com/PublicPort/PP-

Authenticate?id=l+seq=1828d81492b2c044461fd7090a5637b+url=http%3 a%2f%2fwww%2etutsys%2ecom%2f+sig=7863e5a6d77e0e9b5ab472ea7e 71e053

When the user receives this URL, the user's web browser will be directed to the service gateway. In response to receiving the AG-MSG from the user, the service gateway changes the logical port state for the user to authorized, provides the specified "authok.html" web page, and provides the user access to the Internet. In one embodiment, the service gateway may also retrieve the original URL specified by the user when initially attempting to access the Internet by accessing a local database by providing the sequence number, the port number or other unique identifier that may be used for indexing information.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method comprising : receiving a network access request from a user; sending an authorization request message regarding the user to a policy server via a network access application program of the user; receiving from the network access application program an authorization granted message regarding the user initiated by the policy server; and providing the network access application program access to a network responsive to receiving the authorization granted message.

2. The method of Claim 1 wherein the network access application program comprises an Internet web browser and the network comprises the Internet.

3. The method of Claim 1 wherein the network access request comprises an Internet web site access request.

4. The method of Claim 1, wherein sending comprises: redirecting the network access application program to the policy server.

5. The method of Claim 4, wherein redirecting comprises: communicating an hypertext transfer protocol (HTTP) redirect to an

Internet web browser of the user in the form of a uniform resource identifier (URI).

6. The method of Claim 1, wherein sending comprises: computing a digital signature for the authorization request message.

7. The method of Claim 1, wherein the authorization request message comprises some of: a port identifier; a host identifier; a media access control (MAC) address; an original uniform resource locator (URL) designation; a sequence number; a digital signature based on a shared secret; and a version number.

8. The method of Claim 1, wherein the authorization granted message comprises some of: a host identifier; a sequence number; a digital signature based on a shared secret; a version number; a time value; a user identifier; a maximum data rate parameter; and a destination uniform resource locator (URL).

9. The method of Claim 1, further comprising: checking whether a sequence number for the authorization granted message is correct.

10. The method of Claim 1, further comprising: checking whether a digital signature for the authorization granted message is correct.

11. A method comprising: receiving an authorization request message from a network access application program of a user that was initiated by a service gateway; processing a payment information received from the user; and providing an authorization granted message regarding the user to the service gateway via the network access application program.

12. The method of Claim 11 wherein the network access application program comprises an Internet web browser.

13. The method of Claim 11 , further comprising: requesting the payment information from the user; receiving the payment information from the user.

14. The method of Claim 13, wherein requesting comprises: providing a web page to an Internet web browser.

15. The method of Claim 11, further comprising: processing a usage information received from the user.

16. The method of Claim 15, further comprising: requesting the usage information from the user; receiving the usage information from the user.

17. The method of Claim 16, wherein requesting comprises: providing a web page to an Internet web browser.

18. The method of Claim 11 , further comprising: checking whether a digital signature for the authorization requested message is correct.

19. The method of Claim 11, wherein providing comprises: computing a digital signature for the authorization granted message.

20. The method of Claim 11 , wherein providing comprises: redirecting the network access application program to the service gateway.

21. The method of Claim 20, wherein redirecting comprises: communicating an hypertext transfer protocol (HTTP) redirect to an

Internet web browser in the form of a uniform resource identifier (URI).

22. The method of Claim 11, wherein processing comprises: verifying that the payment information is not fraudulent and is not otherwise insufficient; and sending an access refused message to the user if the payment information is insufficient or fraudulent.

23. The method of Claim 22, wherein sending comprises: providing a web page to an Internet web browser of the user.

24. A machine readable medium having stored thereon instructions which when executed by a processor cause the machine to perform operations comprising: receiving a network access request from a user; sending an authorization request message regarding the user to a policy server via a network access application program of the user; receiving from the network access application program an authorization granted message regarding the user initiated by the policy server; and providing the network access application program access to the Internet responsive to receiving.

25. The machine readable medium of Claim 24, wherein sending comprises: redirecting the network access application program to the policy server.

26. The machine readable medium of Claim 25, wherein redirecting comprises: communicating an hypertext transfer protocol (HTTP) redirect to a web browser of the user in the form of a uniform resource identifier (URI).

27. The machine readable medium of Claim 24, wherein the instructions cause the machine to perform operations further comprising: checking whether a sequence number for the authorization granted message is correct.

28. The machine readable medium of Claim 24, wherein the instructions cause the machine to perform operations further comprising: checking whether a digital signature for the authorization granted message is correct.

29. A machine readable medium having stored thereon instructions which when executed by a processor cause the machine to perform operations comprising: receiving an authorization request message from a network access application program of a user that was initiated by a service gateway; processing a payment information received from the user; and providing an authorization granted message regarding the user to the service gateway via the network access application program.

30. The machine readable medium of Claim 29, wherein the instructions cause the machine to perform operations further comprising: processing a usage information received from the user.

31. The machine readable medium of Claim 29, wherein the instructions cause the machine to perform operations further comprising: checking whether a digital signature for the authorization requested message is correct.

32. The machine readable medium of Claim 29, wherein providing comprises: computing a digital signature for the authorization granted message.

33. The machine readable medium of Claim 29, wherein providing comprises: redirecting the network access application program to the service gateway

34. The machine readable medium of Claim 33, wherein redirecting comprises: communicating an hypertext transfer protocol (HTTP) redirect to an Internet web browser of the user in the form of a uniform resource identifier (URI).

35. The machine readable medium of Claim 29, wherein processing comprises: verifying that the payment information is not fraudulent and is not. otherwise insufficient; sending an access refused message to the user if the payment information is insufficient or is fraudulent.

36. A system comprising: a policy server; and a service gateway to receive a network access request from a network access application program, to send an authorization request message regarding a user to the policy server via the network access application program, and to receive from the network access application program an authorization granted message regarding the user initiated by the policy server; wherein the service gateway is to provide the user access to a network responsive to receiving the authorization granted message.

37. The system of Claim 36 wherein the network is the Internet.

38. The system of Claim 36 wherein the network access application program is an Internet web browser.