WO2000077748A1

WO2000077748A1 - Access and payment mechanisms for web services

Info

Publication number: WO2000077748A1
Application number: PCT/US2000/015641
Authority: WO
Inventors: Viswanath Vadlamani
Original assignee: Sun Microsystems, Inc.
Priority date: 1999-06-10
Filing date: 2000-06-07
Publication date: 2000-12-21
Also published as: AU5469100A; EP1192606A1

Abstract

An account for a client to access web services is created upon demand. The client submits payment to create the account. The amount of web services authorized for the account is directly dependent upon the magnitude of the payment. The client may use a number of different payment mechanisms to pay for the account. The account is debited, based upon usage, until the value of the account is below a predetermined threshold. The web services may be Internet services that are provided by an ISP. A preauthorization component may be provided for preauthorizing one time, variable cost access by a client to the web services. The client presents the preauthorization component with a payment mechanism. The preauthorization component authenticates that the payment mechanism is authentic and possesses sufficient payment capability to cover the expenses of the use of the web services by the client. The usage of the web services by the client is monitored and a charge is assessed to the payment mechanism of the client to cover the expenses of the usage of the web services by the client.

Description

ACCESS AND PAYMENT MECHANISMS FOR WEB SERVICES

Technical Field

The present invention relates generally to computer systems and more particularly to the access and payment mechanisms for web services.

Background of the Invention

Internet service providers (ISP's) require a customer to open a customer account prior to gaining access to the Internet services provided by the ISP's. A customer opens such an account by contacting an ISP via a computer connection or a telephone connection, a cable connection or a wireless connection. The customer is required to provide user identification (ID) information and to select a password. The ISP may then transmit certain data and software to be downloaded onto the customer's machine.

ISP's generally provide two types of payment schemes for customers. In the first type of payment scheme, a customer is given an unlimited quantity of access to the

Internet services provided by the ISP. The customer is billed at periodic intervals, such as once a month or once a year. The customer is either sent a bill requesting payment or may be assessed a credit card charge for the costs of Internet access provided by the ISP. In the second type of the payment scheme, a customer is charged on a per usage basis. The ISP monitors usage of the Internet services by the customer and calculates costs based upon the quantity of usage by the customer. These costs are then either billed to the customer or reflected in a credit card charge that is assessed to the customer. For example, the customer may be charged in a current month for the Internet usage in a previous month. Such conventional ISP account and payment schemes do not work well for some customers. For example, these account and payment schemes do not work well for one time customers. A one time customer has to create an account and pay for an entire billing period of service. The account and payment schemes also do not work well for mobile customers. Mobile customers often use a number of different devices at a number of different locations. The multiple devices available to a customer may not have the requisite programs and code to access an ISP from the login site. Moreover, it may be difficult to access certain ISP's from remote locations outside a subscriber area. Summary of the Invention

The present invention provides an approach to providing web services that is well-adapted for a variety of different types of users, including mobile users. The present invention allows a user to create an account on the fly at the time of tendering payment for the account. The account is authorized for a quantity of access to web services commensurate with the payment. Thus, a user may customize the quantity of access to the needs of the user by adjusting the size of the payment. The value of the account is debited based upon usage until no value remains.

The user may have a number of different options for paying for the account. For example, the user may furnish a credit card number so as to pay for the account via credit card. Alternatively, the user may pay for the account using a debit card or bank card. Still further, the user may use a digital cash mechanism to pay for the account. The user may have a smart card that transfers electronic currency tokens to pay for the account.

The present invention also provides a variable cost, one time payment scheme. In particular, a client presents a payment mechanism, such as a credit card, to the provider of web services at the time at which the client wishes to use the web services. The payment mechanism is authenticated, and the client is preauthorized to use up to a maximum amount of web services during the ensuing session of access to the web services. For example, the credit card provided by the client may be authenticated and preauthorization may occur for a maximum charge that may be assessed to cover the cost of the ensuing session. Thus, a client might be preauthorized to consume up to $100.00 of web services during the ensuing session. The client is granted access to the web services, and the usage of the web services by the client are monitored. When the client is done with the session of web services, a charge is assessed to cover the cost associated with the usage of the web services during the session by the client. This charge is applied to the payment mechanism that the client presented. This one time approach provides a convenient mechanism for users to charge for one time access to web services, such as Internet services. The user is charged based upon the extent of usage of the web services and, hence, does not pay an excessive amount for the one time usage of the web services. The provider of the web services is ensured that it will receive payment for the use of the web services as the payment mechanism has already been presented by the user.

In accordance with one aspect of the present invention, a computer network includes a provider of web services. A payment is received from a customer for a fixed quantity of access to the web services provided by the provider. The customer lacks an account with the provider, but an account is created for the customer in response to receiving the payment. The account is allocated the fixed quantity of access to the web services that were paid for by the customer. The customer is permitted to access the web services via the account, and the fixed quantity of access to the web services that is allocated to the account is debited in response to usage by the customer. The web services may be provided as part of the Internet, on an intranet or on an extranet. In accordance with a further aspect of the present invention, a payment is received from a smart card of a customer for a fixed quantity of web services in a computing environment. An account is created for the customer in response to receiving the payment. The account is authorized for the fixed quantity of web services for which payment was received. Web services are then provided to the customer via the account. In accordance with an additional aspect of the present invention, a method is practiced in a computing environment where an Internet service provider provides access to the Internet. The client is prompted for payment for access to the Internet via a web site. The payment is received from the client for a fixed quantity of Internet access. An account is opened for the client in response to receiving the payment. The account is authorized for a fixed quantity of Internet access. The client is provided with a user ID for the account, and a password is established for the account. The client is permitted to access the account if the client provides the user ID and the password. The quantity of Internet access for which the account is authorized is debited based upon usage by the client. In accordance with another aspect of the present invention, a computer system includes a payment module for receiving payments from a client for web services. A computer system also includes a web services provider for providing web services to the clients. A provider creates an account for each client upon receiving payment from the client. Each account is authorized a fixed quantity of web services based upon payment by the client. The computer system additionally includes a usage monitor for debiting the quantity of web services authorized for each account based upon usage of the account by the clients.

In accordance with an aspect of the present invention, a method is practiced in a computing environment that includes a web server for providing web services to a client. The method concerns obtaining payment from the client to cover charges for using the web services. Per this method, information is received from the client regarding a payment mechanism for providing payment to cover the charges for using the web services. The client is granted access to the web services provided by the web server. A cumulative charge to be assessed to the client for a single session of access to the web services is calculated and payment for the cumulative charge is obtained from the payment mechanism. The payment mechanism may be, for example, a credit card, a debit card, a smart card or other digital cash mechanism.

In accordance with another aspect of the present invention, an Internet service provider provides Internet services to a client. Information regarding a credit card account is provided, and the credit card account is preauthorized for a maximum charge. Usage of the Internet services by a client is monitored to calculate the total time used by the client. A charge is then assessed to the credit card account based on the total time used by the client. In accordance with an additional aspect of the present invention, a payment mechanism of a client is preauthorized for a maximum payment for a single session of usage of web services. As the client uses the web services, the charges that have been accrued for using the web services are determined. When the charges that have been accrued reach the maximum amount for which the payment mechanism is preauthorized, access by the client to the web services is terminated. In accordance with a further aspect of the present invention, a computer system in a computing environment includes a web services provider for providing web services to at least one client. The computer system also includes a preauthorization component for preauthorizing use of a payment mechanism to cover expenses associated with a subsequent session of use of the web services. The computer system additionally includes a usage monitor for monitoring usage of the web services during the session and for assessing a charge to the payment mechanism of the client for the expenses.

Brief Description of the Drawings An illustrative embodiment, consistent with the principles of the present invention, will be described below relative to the following drawings.

FIGURE 1 A depicts a computing environment that is suitable for practicing the illustrative embodiment.

FIGURE 1 B depicts a computing environment wherein a client uses multiple client devices at multiple login sites in practicing the illustrative embodiment.

FIGURE 2 depicts a block diagram of components of the client device of Figures lA and lB.

FIGURE 3 depicts a logical diagram of components of the web server of Figures lA and IB. FIGURE 4 depicts the format of a database that holds account information.

FIGURE 5 depicts an example of the front side of a smart card that may be used with the illustrative embodiment.

FIGURE 6 depicts an example of the rear side of a smart card that may be used with the illustrative embodiment. FIGURE 7A is a flow chart depicting steps that may be performed to receive payment to create an account for Internet services.

FIGURE 7B depicts an example of a user interface that may be provided to prompt a client for payment in creating an account.

FIGURE 8 is a flow chart that illustrates the steps that are performed for a client to gain access to Internet services provided by an ISP. FIGURE 9 is a flow chart illustrating the steps that are performed by a client to login to the web server in the illustrative embodiment.

FIGURE 10 is a flow chart illustrating the steps that are performed to monitor client usage of an account. FIGURE 11 depicts a flow chart of the steps that are performed in using the web services in the illustrative embodiment.

FIGURE 12 is a flow chart that illustrates the steps that are performed to preauthorize a payment mechanism.

FIGURES 13A and 13B illustrate examples of web pages that may be presented to obtain payment mechanism information from the client.

FIGURE 14 is a flow chart illustrating the steps that are performed to authenticate a credit card payment mechanism.

FIGURE 15 is a flow chart illustrating the steps that are performed to monitor usage of web services by a client.

Detailed Description of the Invention

The illustrative embodiment, consistent with the principles of the present invention may create accounts upon demand from a client. The accounts enable the clients to gain access to Internet services that are provided by an Internet service provider (ISP). The value of the account (i.e. the extent of Internet access provided by the account) is determined by the magnitude of the payment by the client. The value of each account is debited based upon usage of the account. When the account is below a threshold amount or has negligible value, the account is disabled such that the client assigned the account is no longer able to gain access to the Internet via the account. The client has the ability to customize the quantity of Internet access that the client desires. For example, if the client desires to have one hour of Internet access, the client may pay for one hours of Internet access and open an account that is authorized for one hour of Internet access.

The client may pay for the account in a number of different ways. The client may provide a credit card number so as to pay for the account by charging the payment to the credit card. Alternatively, the client may pay for the account via a digital cash mechanism. Still further, the client may pay for the account using a debit card or bank card. The client may also pay for the account by using a smart card. The smart card may transfer electronic currency tokens to furnish payment for the account. The ISP may provide a user interface for accepting payment from the client. This user interface may take the form of a web page. The web page may request the user to select a form of payment and provide requisite information to insure that the payment is realized. Thus, the illustrative embodiment provides the user with a great deal of flexibility as to payment mechanisms.

The illustrative embodiment provides an approach to Internet access that is well suited for mobile users. First, the mobile users may choose the quantity of access that meets their anticipated needs. Second, the client may access the account from multiple login sites and from multiple machines. The account is debited based upon the usage such that the full value of the account is used by the client as opposed to being wasted. The illustrative embodiment also provides a useful approach for a mobile client. The mobile client need not be concerned about which device the mobile client is using to gain access to the Internet services. Moreover, the mobile client need not be concerned with the location from which the client seeks to gain access to Internet services. The mobile client needs to simply contact a given web site or call a designated ISP telephone number to gain access to the Internet services. The illustrative embodiment also provides a variable cost, one time payment mechanism for covering the cost to a client for accessing web services provided by a web service provider. Although the present invention may be practiced with a wide variety of web services, including intranet services and extranet services, the illustrative embodiment will be discussed below relative to an Internet service provider (ISP) that provides Internet access to a client. The payment mechanism employed in the illustrative embodiment is "variable cost" in that the cost assessed to the client for accessing the Internet services varies depending upon the extent of usage of the Internet services by the client. The payment mechanism is a "one time" mechanism in that the client separately pays for each session of usage of the Internet services. The charge assessed to the client for a session of usage of the Internet services is based upon the quantity of usage by the client; hence, the client does not pay excessive charges for resources the client does not consume.

In the illustrative embodiment, a session of usage of the Internet services begins by the client accessing a web site that requests payment mechanism information from the client. The requested information may include the nature of the payment mechanism that is to be used and particulars regarding the payment mechanism. The payment mechanisms may include, for instance, credit cards, debit cards, smart cards and digital cash mechanisms.

An example is helpful to illustrate what type of information is requested from the client. The client may be requested to identify the type of payment mechanism used (e.g. whether a smart card or a credit is being used). Suppose that the client proposes to use a credit card. The client may then be asked to identify which credit card the client intends to use. In addition, the client may be prompted to provide the credit card number, expiration date and the name that is on the card. The ISP utilizes the payment mechanism information to authenticate that the payment mechanism is valid and can be used to cover the cost of the ensuing session of usage of the Internet services by the client. In addition, the ISP preauthorizes a maximum charge amount for the payment mechanism. Hence, for example, an ISP may preauthorize that a client may use the credit card of the client as a payment mechanism for up to $100.00 of charges during a single session of usage of the Internet services. Once the preauthorization and authentication is complete, the client may be given access to the Internet services provided by the ISP. A monitoring mechanism is employed to monitor usage by the client. This monitoring mechanism tabulates the charges associated with usage of the Internet services on an ongoing basis. Moreover, the monitoring mechanism ensures that the cumulative accmed charges for the client during the current session of usage of the Internet services does not exceed the maximum amount for which the payment mechanism is preauthorized. The monitoring mechanism may terminate access to the Internet services when the maximum amount of charges is reached. In order to help clarify the discussion below, it is helpful to define a few terms.

An "Internet service provider (ISP)" provides Internet access to client. "Web services" are services that are provided by a provider over a network, such as the Internet, an intranet or an extranet, that adopts the TCP/IP protocol suite or another suitable network protocol.

"Internet services" are services provided by an ISP over the Internet. A primary example of Internet services is access to the Internet.

A "web server" is a server that provides web services. The web server is part of a network, such as the Internet, an intranet or an extranet.

An "intranet" is a private network that uses Internet-like software and provides Internet-like services. An "extranet" is a private Internet-like network that provides secure areas for access by selected external parties.

Figure 1A depicts a computing environment 10 that is suitable for practicing the illustrative embodiment. A client uses a client device 12 to contact a web server 14 that is part of a network 16. The client has a payment mechanism 15 for paying for the cost of using the web services provided by the web server 14. As was mentioned above, the payment mechanism may take many forms, including a credit card, a debit card, a bank card, a smart card, a digital cash mechanism or a secured token device that holds electronic currency tokens.

In the illustrative embodiment, it is assumed that the web server 14 is part of the Internet. Nevertheless, those skilled in the art will appreciate that the web server 14 may also be part of an intranet, an extranet or another computer network. The present invention is not limited to being practiced within the Internet but also works with other networks and other networks that employ connectionless protocols.

The client device 12 may be any of a number of different types of devices. For example, the client device 12 may be a desktop computer system, a laptop computer system or even a palmtop computer system. The client device 12 may be a network computer, an intelligent television set, a pager or other device that is able to communicate with the web server 14 and create an appropriate connection. The client device 12 may access the web server 14 by using a dial-up network program or by creating a connection via a web browser. Figure IB depicts an example wherein the client is a mobile client. The client uses different devices 12A, 12B and 12C at different respective sites 13 A, 13B and 13C to communicate with the web server 14 within the IP network 16. The illustrative embodiment accommodates the clients using the different devices 12 A, 12B and 12C. Those skilled in the art will appreciate that the client devices may in general be any devices that can interface with the network. In addition, the illustrative embodiment accommodates the client logging in from the different respective sites 13 A, 13B and 13C. As will be described in more detail below, the client just needs to have a web browser and must be able to provide the user ID and password in order to gain access to the web services provided by the web server 14.

Figure 2 depicts the client device 12 in more detail. In the example depicted in Figure 2, the client device 12 is a computer system. The client device 12 shown in Figure 2 includes a central processing unit (CPU) 17 for executing computer program instructions and overseeing operation of the client device. The client device 12 of Figure 2 includes a video display 19, a keyboard 18 and a mouse 20. The client device may include a smart card reader 21 for facilitating communications between the client device 12 and a smart card, which acts as the payment mechanism 15. The smart card may comply with the ISO-7816 standard or the EMV integrated circuit card specification. The smart card preferably complies with the JavaCard 2.1 specification as defined by Sun Microsystems, Inc. of Palo Alto, California. The JavaCard 2.1 specification requires that the smart card be capable of running programs written in the Java™ programming language. Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. Those skilled in the art will appreciate that the smart card need not run the Java programming language to practice the present invention; rather the smart card may alternatively mn programs written in different programming languages.

The client device 12 may also include a magnetic card reader 23 for reading magnetic cards. Still further, the client device 12 may include a modem 32, such as a conventional data modem, a cable modem or a wireless modem. The client device 12 may have a network adapter for connecting the client device with a local area network. The client device 12 may include primary storage 22 as well as secondary storage 24. The primary storage 22 and secondary storage 24 may be realized using a number of well-known storage devices and computer-readable mediums. The primary storage 22 may hold support for dial-up networking 26 and a web browser 28.

Those skilled in the art appreciate that the depiction of the client device 12 in Figure 2 is intended to be merely illustrative and not limiting of the present invention. Configurations that differ from the configuration depicted in Figure 2 may be utilized. For example, different peripheral devices may be utilized and not all of the components shown in Figure 2 are required to practice the present invention. For example, the client device 12 may lack a network adapter 30, smart card reader 21, magnetic card reader 23, mouse 20 or modem 32. Moreover, the client device 12 may include components such as loud speakers, pointing devices, or a digital scanner, for instance.

Figure 3 depicts the major logical components of the web server 14. The web server 14 may be implemented as a dedicated server computer system or as a shared computer system in which a web server process runs. The web server 14 need not be implemented on a single computer system but rather may be implemented as a distributed system.

The web server 14 includes programs and data that form web server support 40. The web server support 40 includes support for protocols, such as the TCP/IP protocol suite, a markup language, such as HTML, a transfer protocol like HTTP, the Java programming language and other support necessary for the web server 14 to facilitate Internet access. The web server support 40 may furnish a number of HTML documents that are forwarded to clients to provide user interface information.

The web server 14 may also include a payment module 42. The payment module 42 is responsible for obtaining payment mechanism information from the client and for interacting with any third-party authentication mechanisms to ensure that the payment mechanism provided by the client is authentic and preauthorized for a sufficient maximum amount. A time usage monitor 44 is provided in the web server 14 to monitor usage of the Internet services. Creation of Accounts on Demand

The discussion below will first focus on the case where accounts are created on demand for fixed quantity access and then focus on the case where a one-time payment and access mechanism is used. The web server 14 may create a number of different accounts to facilitate users using accounts on the fly. These accounts may be all associated with a fixed quantity of web services, or the accounts may be associated with different quantities of web services. For example, some accounts may be associated with ten dollars worth of services, whereas other accounts may be associated with five dollars of services. Similarly, accounts may be associated with five hours, ten hours and fifteen hours of service.

The quantity of services associated with an account may be expressed as a value of time, monetary value or as a value of another metric. Those skilled in the art will appreciate other methods may be used to quantify amounts of service or web access. The database 42 holds information regarding each account, including the quantity of service associated with the account. Figure 4 shows an example of the database 42. The database 42 includes an entry 50 for each account. An account number or account identifier 52 is associated with each account. The value of this account number 52 is stored within the database 42 for each account. Information regarding the time that has been consumed 54 on the account is also stored in the database. Information regarding the time that is left 56 in the account is also stored within the database 42. For example, as shown in Figure 4, account ABC was originally allocated three hours of Internet access. An hour of the three hours has been consumed and two hours remain. Alternatively, a record of the total time purchased and the time used may be kept in the database 42. As another alternative, a record of the total time purchased and the time remaining may be kept in the database 42.

Each client may be provided with a smart card or other secure token device which has computer components, such as microprocessor and a storage embedded into it. The smart card may comply with the ISO-7816 standard or the EMV integrated circuit card specification. Preferably, the smart card complies with the JavaCard 2.1 specification as defined by Sun Microsystems, Inc. The JavaCard 2.1 specification requires that the secure token device be capable of running programs written in the Java programming language. Those skilled in the art will appreciate that the smart card need not run the Java programming language to practice the present invention.

Figure 5 shows the front side of a smart card 66, and Figure 6 shows the rear side of the smart card. The front side of the smart card 66 includes a number of electrical contact 70 that are used for electrical communications with a microprocessor that is embedded within the smart card. The smart card 66 includes a substrate 68 of a suitable material, such as plastic, that forms the core of the smart card. An embossing area 72 may be provided on the front side to be signed by the holder of the smart card or to hold other textual information. The rear surface of the smart card (see Figure 6) may include a magnetic strip 74 to hold information that is readable by a magnetic strip reader. The smart card may hold electronic currency tokens that are used for payment to obtain an account on behalf of the client that holds the smart card.

Figure 7A depicts the steps that are performed to realize payment in the illustrative embodiment. Initially, a client contacts a payment web site (step 71 in Figure 7A). The client may be provided with a given telephone number, such as a toll free number, that the client may call to gain access to the payment web site. Alternatively, a URL for the site may be made known to the client. The payment web site may be furnished by the web server 14. Specifically, the payment web site may include HTML or XML documents that may be displayed in response to the client contacting the web server 14.

The client is prompted for payment (step 73 in Figure 7A). This may take the form of a web page that requests the selection of payment options and payment information. Figure 7B shows and example of a window 80 that holds the contents of a web page in the client area 82. The client area 82 displays text to 84 that prompts the client to choose a payment option. Based upon which payment option is selected, additional web pages may be displayed to obtain the requisite information to realize payment via the chosen payment option. For example, if the user chooses the credit card option, the user may be requested to enter a credit card number, an expiration date and some personal information. Payment is then received (step 75 in Figure 7A) with respect to a credit card or bank card payment, receiving the payment includes authorizing the credit card, debit card or bank card in assessing the appropriate payment via the mechanisms used for that type of card. If the client chooses to pay via digital cash or smart card, an electronic currency or an electronic transfer of funds must occur in order for payment to be received. With the smart card, this may constitute transfer of electronic currency tokens from the client's smart card over the network to the web server.

In response to receipt of the payment, an account is created for the quantity of services for which payment was received (step 76 in Figure 7A). The account is created on demand or "on the fly." In other words, the account does not pre-exist but rather is created in response to receipt of payment from a client. The fixed quantity of services associated with the account, depends upon the amount paid by the client. The client is provided with a user identification (ID) and an initial password for the account (step 78 in Figure 7A). The user ID and password will be requested from the client when the client seeks to use the account to gain access to Internet services.

Figure 8 provides an overview of the steps that are performed for a client to utilize Internet services in the illustrative embodiment. Initially, the client contacts the web server 14 (step 90 in Figure 8). As mentioned above, this contact may be achieved using dial-up networking software 26 from the client device 12 or by placing a call and using a web browser 28. The client then performs the necessary steps for login (step 92 in Figure 8). Figure 9 provides a flow chart of the steps that are performed during login. The login begins with a web server prompting the client for a user ID (step 100 in Figure 9). The web server may generate web pages that request the user ID. The web page may also request that the client provide a password (see step 106 in Figure 9). Alternatively, a separate web page may prompt the client for the password after the user ID has been received and validated. When the user ID is received (step 102 in Figure 9), the web server 14 performs steps to determine whether the user ID is valid (step 104 in Figure 9). The web server may contain a list of valid user IDs within the database 34 or another storage mechanism. If the user ID is not valid, access to the Internet via the account is denied (step 112 in Figure 9). In contrast, if the user ID is valid (as checked in step 104 in Figure 9), the client prompted for a password (step 106 in Figure 9). The password is received by the web server (step 108 in Figure 9), and the web server performs steps to determine whether the password is valid or not (step 110 in Figure 9). The web server 14 holds a list of the user IDs and associated passwords. It makes certain that the password that is entered and received is that which is stored by the web server. If the password is not valid, the client is denied access to the Internet services via an account (step 112 in Figure 9). If the password is valid, the client is granted access to the Internet services via an account (step 114 in Figure 9). Figure 10 depicts the steps that are performed to monitor usage of the Internet services by a client (see step 96 in Figure 8). As was mentioned above, the web server 14 maintains the database 42 to monitor the time used and the time remaining for a given account. The steps shown in Figure 10 are performed at periodic intervals such as once a minute or once every five minutes. At each interval, the time used for the account is incremented (step 130 in Figure 10). The time left or remaining for the account is decremented for the same quantity. For example, if the steps are performed every five minutes, in step 130 of Figure 10, the time used is incremented by 5 minutes and in step 132 of Figure 10, the time remaining is decremented by 5 minutes. The time usage monitor 44 (see Figure 3) of the web server 14 then checks whether there is any time remaining for the account in step 134, Figure 10. If there is not any time left, the client is advised and services are terminated (step 136 in Figure 10). Otherwise, there is time remaining and the monitoring process continues.

Those skilled in the art will appreciate that the time usage monitor 44 need not wait until no time remains on the account but rather may wait until the account is below a given threshold and give the client warnings. Alternatively, the time usage monitor may actually allow the time to go to slightly negative value and then terminate service at that point. Those skilled in the art will have known a number of different alternatives that may be provided for monitoring such usage. As was mentioned above, the usage need not be monitored purely as a value of time but also may be monitored as a monetary value or as another metric. Eventually, the client completes usage of the services (step 98 in Figure 8). The client may subsequently again use the services provided by the web server 14 if time remains on the given account.

Variable Cost, One Time Access and Payment Mechanism

Figure 11 depicts the steps that are performed for a client to access and use the Internet services provided by an ISP with the variable cost, one time access and payment mechanism of the illustrative embodiment. First, the ISP (i.e. the web server 14 of the ISP) must preauthorize the client (step 150 in Figure 11). Figure 12 depicts the steps that are performed to preauthorize a client. The preauthorization begins with the client calling a phone number that is provided by the ISP for variable cost, one time access to the Internet services provided by the ISP (step 160 in Figure 12). This may be, for example, a toll free number. The ISP then sends a form to the client to request payment information (step 162 in Figure 12). The form may be implemented as one or more HTML documents that are forwarded over an Internet connection from the web server 14 to the client device 12. The web browser 28 on the client device renders the web pages so that they are visible to the client. Figure 7B is an example of an initial web page that may be provided to the client to request payment mechanism information. After selecting a payment option, the client may be presented with additional web pages that obtain further information regarding the selected payment option. Figure 13A shows an example of a web page 176 that may be presented when the user selects the credit card option. This web page includes section 178 that includes text and radio buttons for selecting which variety of credit card the client wishes to use. Figure 13B shows an example of an additional web page 180 that includes sections 182, 184 and 186 in the client area 181. This web page 180 obtains information regarding the client's credit card. Section 182 includes a text box in which the client is requested to enter the credit card account number. Section 184 includes a text box in which the client is requested to enter the expiration date for the credit card and section 186 includes a text box in which the client is requested to enter the client name as it appears on the credit card. The client uses these forms to provide the requested payment mechanism information and to forward the payment mechanism information to the web server 14 of the ISP (step 164 in Figure 12). This payment mechanism information is used in authenticating that the payment mechanism is valid and may be used to cover the charges to be assessed to the client for using the Internet services provided by the ISP (step 166 in Figure 12).

The particulars of authentication may vary with the payment mechanism that is selected by the client. Figure 14 shows an example of the steps that are performed when the payment mechanism is a credit card. The ISP checks whether the credit card number that has been provided by the client is a valid credit card number (step 190 in Figure 14). Only selected account numbers are valid for given credit card types. For example, a MasterCard account may have a predetermined number of digits and may have an acceptable subset of values. Moreover, the credit card number must represent an existing credit card account. If the credit card number is not valid, the payment mechanism is not authenticated, and the client is denied access to the Internet services provided by the ISP (step 200 in Figure 14). If the credit card number is valid, the ISP may check whether the account has expired or if there is a stop or other impediment associated with the account. Account numbers may be associated with accounts that have only a finite lifetime. After the expiration of the defined lifetime, the account may expire. Similarly, accounts may expire because a user has canceled the account or the user has failed to make sufficient payments so as to keep the account alive. Furthermore, stops may be placed on an account where a user is delinquent in payments or if unusual activity has occurred on an account. A stop may also be placed on an account where a user has reported that a credit card is missing or that a theft has occurred. If the account has expired or if the account has a stop on it (step 192 in Figure 14), the client may be denied access to the Internet services provided by the ISP (step 200 in Figure 14).

Where the account has not expired and there is not a stop on the account, the ISP may check whether the name provided by the client matches the records stored by the ISP as the cardholder of record for the account (see step 194 in Figure 14). If the name does not match the records, the client is denied access to the Internet services provided by the ISP (step 200 in Figure 14).

Lastly, the ISP may require that the credit available on the credit card be at least a minimal amount before the client will be preauthorized. Hence, in step 196 of Figure 14, the ISP checks whether the account has sufficient available credit. If the account lacks sufficient available credit, the client will be denied access to the Internet services provided by the ISP (step 200 in Figure 14). If, however, sufficient credit is available, the client is granted access to the Internet services provided by the ISP up to a predetermined maximum amount. The maximum amount may be fixed for all clients or may be based upon the amount of available credit (see step 198 in Figure 14).

Those skilled in the art will appreciate that the ordering of steps 190, 192, 194 and 196 in Figure 14 is merely illustrative and not intended to be limiting of the present invention. Different orderings of these steps may be used in practicing the present invention. If the payment mechanism provided by the client is preauthorized, the client is granted access to the Internet services provided by the ISP and the time usage monitor 44 of the web server 14 is used to monitor usage of the Internet services by the client (step 152 in Figure 11).

Figure 15 is a flow chart illustrating the steps that are performed by the time usage monitor 44 in monitoring usage by the client. The time used during a session by the client is incremented at predetermined time intervals (step 202 in Figure 15). After the time is incremented, a check is made to determine whether the client has reached the preauthorized maximum amount of charges based upon the usage thus far (step 204 in Figure 15). If the client has reached or exceeded the maximum, the client is denied further access to the Internet services provided by the ISP (step 206 in Figure 15).

After the client is "done," a charge is assessed to the client based upon the usage during the session (step 154 in Figure 11). The client may be "done" when the client has reached the maximum preauthorized amount or when the client has chosen to terminate a session. The charge is assessed using the payment mechanism that was preauthorized and presented by the client. While the present invention has been described with reference to an illustrative embodiment thereof, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

Claims

1. In a computer network having a provider of web services, a method comprising the steps of: receiving payment from a customer for a fixed quantity of access to the web services provided by the provider wherein the customer lacks an account with the provider; in response to receiving the payment, creating an account for the customer wherein said account is allocated the fixed quantity of access to the web services; and enabling the customer to access the web services via the account.

2. The method of claim 1 wherein the payment is a credit card payment.

3. The method of claim 1 wherein the payment is a digital cash payment.

4. The method of claim 1 wherein the payment is a debit card payment.

5. The method of claim 1 wherein the web services comprise providing access to the Internet.

6. The method of claim 1 wherein the web services are provided in an intranet.

7. The method of claim 1 wherein the web services are provided in an extranet.

8. The method of claim 1 further comprising the step of disabling access to the web services via the account when the fixed quantity of access has been debited below a threshold amount.

9. The method of claim 1 wherein the provider is a web server and wherein the method is performed by the web server.

10. The method of claim 1 further comprising the step of debiting the fixed quantity of access to the web services allocated to the account in response to usage by the customer.

11. In a computing environment, a method comprising the steps of: receiving payment from a smart card of a customer for a fixed quantity of web services; in response to receiving the payment, creating an account for the customer, said account being authorized for the fixed quantity of web services; and providing web services to the customer via the account.

12. The method of claim 1 1 wherein the web services include providing access to the Internet.

13. The method of claim 11 wherein the payment comprises electronic currency tokens.

14. In a computing environment wherein a Internet service provider (ISP) provides access to the Internet, a method, comprising the steps of: via a web site, prompting a client for payment for access to the Internet; receiving payment from the client, said payment being for a fixed quantity of Internet access; in response to receiving the payment, opening an account for the client wherein said account is authorized for the fixed quantity of Internet access; providing the client with a user identification (ID) for the account; establishing a password for the account; enabling the client to access the account if the client provides the user ID and password; and debiting the quantity of Internet access for which the account is authorized based on usage by the client.

15. The method of claim 14 wherein the method further comprises the step of denying the client further Internet access when the account is debited to a point where the quantity of Internet access for which the account is authorized is below a threshold.

16. The method of claim 14 wherein the fixed quantity of Internet access is a fixed amount of Internet access time.

17. The method of claim 14 wherein the step of prompting the client comprises displaying a web page that requests a choice of payment mechanisms.

18. The method of claim 14 wherein the payment is received from a smart card.

19. The method of claim 14 wherein the payment is a credit card payment.

20. The method of claim 14 wherein the payment is made via digital cash.

21. In a computer network having a provider of web services, a computer readable medium holding computer executable instmctions for performing a method comprising the steps of: receiving payment from a customer for a fixed quantity of access to the web services provided by the provider wherein the customer lacks an account with the provider; in response to receiving the payment, creating an account of the customer wherein said account is allocated the fixed quantity of access to the web services; enabling the customer to access the web services via the account; and debiting the fixed quantity of access to the web services in response to usage by the customer.

22. The computer readable medium of claim 21 wherein the payment is a credit card payment

23. The computer readable medium of claim 21 wherein the payment is a digital cash payment.

24. The computer readable medium of claim 21 wherein the payment is a debit card payment.

25. In a computing environment wherein a Internet service provider (ISP) provides access to the Internet, a computer-readable medium holding computer-executable instructions for performing a method, comprising the steps of: via a web site, prompting a client for payment for access to the Internet; receiving payment from the client, said payment being for a fixed quantity of Internet access; in response to receiving the payment, opening an account for the client wherein said account is authorized for the fixed quantity of Internet access; providing the client with a user identification (ID) for the account; establishing a password for the account; enabling the client to access the account if the client provides the user ID and password; and debiting the quantity of Internet access for which the account is authorized based on usage by the client.

26. A computer-readable medium of claim 25 wherein the method further comprises the step of denying the client further Internet access when the account is debited to a point where the quantity of Internet access for which the account is authorized is below a threshold.

27. In a computing environment having a web server for providing web services to a client, a method of obtaining payment from the client to cover charges for using the web services, comprising: receiving information from the client regarding a payment mechanism for providing payment to cover the charges for using the web services; granting the client access to the web services provided by the web server; calculating a cumulative charge to be assessed to the client for a single session of access to the web services; and obtaining payment from the payment mechanism for the cumulative charge.

28. The method of claim 27 wherein the information received from the client is a credit card number.

29. The method of claim 27 wherein the information received from the client is a debit card number.

30. The method of claim 27 wherein the payment mechanism is a smart card.

31. The method of claim 30 wherein the smart card contains electronic currency tokens.

32. The method of claim 27 wherein the payment mechanism is a digital cash mechanism is a digital cash mechanism.

33. The method of claim 27 wherein the method further comprises authenticating that the payment mechanism is a valid payment mechanism.

34. The method of claim 27 wherein the method further comprises preauthorizing the payment mechanism for a maximum amount for which the client may be charged for accessing the web services during a session of access.

35. The method of claim 27 wherein the web server is an Internet server and wherein the web services are Internet services.

36. The method of claim 27 wherein the web server is an intranet server is an intranet server.

37. The method of claim 27 wherein the web server is an extranet server.

38. In a computing environment having a web server for providing web services to a client, a computer-readable storage medium holding computer-executable instmctions for performing a method of obtaining payment from the client to cover charges for using the web services, comprising: receiving information from the client regarding a payment mechanism for providing payment to cover the charges for using the web services; granting the client access to the web services provided by the web server; calculating a cumulative charge to be assessed to the client for a single session of access to the web services; and obtaining payment from the payment mechanism for the cumulative charge.

39. The computer-readable storage medium of claim 38 wherein the information received from the client is a credit card number.

40. The computer-readable storage medium of claim 38 wherein the information received from the client is a debit card number.

41. The computer-readable medium of claim 38 wherein the payment mechanism is a smart card.

42. The computer-readable medium of claim 38 wherein the smart card contains electronic currency tokens.

43. The computer-readable medium of claim 38 wherein the payment mechanism is a digital cash mechanism is a digital cash mechanism.