WO2002097685A9

WO2002097685A9 - Methods and systems in a data communication network for delivering and charging for services

Info

Publication number: WO2002097685A9
Application number: PCT/FI2001/000845
Authority: WO
Inventors: Hannu Aronsson; Simo Saeteri; Tero Kivinen; Jussi Elimaeki; Heikki Suonsivu; Patrik Andersin; Toni Willberg
Original assignee: Portalify Oy; Hannu Aronsson; Simo Saeteri; Tero Kivinen; Jussi Elimaeki; Heikki Suonsivu; Patrik Andersin; Toni Willberg
Priority date: 2001-05-31
Filing date: 2001-09-28
Publication date: 2003-03-20
Also published as: WO2002097685A1; FI20011134A0; FI20011134A

Abstract

This invention is concerned with a method for delivering a service in a communication network comprising one or more user terminals to which the services are delivered. A service provider delivers and charges for the services and a bank server administrates the payments made by the users. First, a user sends a request for a service to the service provider and the service provider sends instructions to the user to continue if the conditions for using the service are accepted. Then the user sends a message to the bank server for using the service and the bank server request the user to fulfil the conditions for using the service if they are not already fulfilled. The user performs the operations needed to fulfil the conditions and the bank server directs the user to the service needed. The user uses the service after having received the service.

Description

METHODS AND SYSTEMS IN A DATA COMMUNICATION NETWORK FOR DELIVERING AND CHARGING FOR SERVICES

TECHNICAL FIELD

The invention is concerned with methods and systems in a data communication network for delivering and charging for services.

BACKGROUND ART

An internetwork is a collection of individual networks, connected by computers that function as a single large network. The internet is an example of an internetworked wide area network. This world wide network can be used for communication and information delivery and information retrieval. The open and common internet has grown phenomenally during the last few years and a large number of services for large and small user groups has developed in the internet. The use of these services are either free of charge, supported by third parties, e.g. advertisers, or in alternative, you have to register yourself in advance to be able to use the services. Usually, you are provided with a password that enables you to use the services for which you have been registered.

The interconnected computers exchange information by using different services such as electronic mail and the world wide web www. Each service of the www is identifiable by a Uniform Resource Locator (URL). To view a specific web page, a client computer system specifies the URL for that web page in a request, e.g. in the form of a Hyper Text Transfer Protocol (HTTP) request. The request is forwarded to the web server that holds the web page in question. When that web server receives the request, it sends the web page to the client's computer system. The client's computer system receives the web page using a browser. A browser is a special purpose application program that effects the requesting of web pages and the displaying of web pages. Currently, web pages are typically defined using Hyper Text Markup Language (HTML). HTML defines how a web page is to be displayed. Thus, a browser displays a web page as defined by the HTML document. The HTML document controls the displaying of text, graphics and other features. A HTML document may also contain URLs or other web pages available on that server computer system or other server computer systems.

Many web servers have been developed through which vendors can advertise and sell products and services, that are delivered electronically. When a user has selected the services to be delivered, the server computer system asks the user for information to complete the ordering. The order information may include the client's name, credit card number and address for the order. The server computer system then typically confirms the order by sending a confirming web page to the client's computer system.

There are some known methods for charging of these services. Either you pay for each time you use the service or then you have a monthly amount to pay.

Amazon's US-patent 5,960,411 describes a system where the user can click on a button on a shop website which will complete an order by using a previously given mailing address and payment information. Other user interaction to complete the payments are not required. The patent does not, however, describe any solutions for charging for new users or one-time payments.

The Amazon company sells items at httpJ/www.amazon.com. The Amazon Honor system works as follows: a web page with dynamic images is generated from their server based on user cookies. This system, however, is unsuitable for micropayments, and no payment cancellation alternatives for these payments exist.

There is obviously a need for more flexible charging systems, so that also the charging of new users would be possible. Services should also be able to be delivered in a way making charging of everyone using the services possible. The object of this invention is to develop methods and systems for delivering and charging for services in a flexible way.

Another object is to be able to charge for services in real time in a way that charging for small sums would be profitable.

SUMMARY OF INVENTION

The invention is concerned with a method for delivering a service in a communication network comprising a user terminal to which the services are delivered, a service provider that delivers and charges for the services, and a bank server which administrates the payments made by the users. In the method, the user sends a request for a service to the service provider. The service provider asks the user to continue if the conditions for using the service are accepted. The user then sends a message to the bank server for using the service. The bank server requests the user to fulfil the conditions for using the service if they are not already fulfilled, after which the user performs the operations needed to fulfil the conditions. The bank server can then direct the user to the service needed and the user can use the service after having received it.

Advantageous embodiments of the invention are described in the subclaims.

The communication network can be internet, and the user terminal e.g. a PC, or a mobile wireless device.

The services used are most typically fetching of web pages, images or downloading software from the internet and the conditions to use the service is to pay a certain amount.

The bank server can direct the user to the service needed basically in two ways. Either the bank server is delivering the service to the user terminal, or the bank server informs the user or the user's browser software how to find and use the service, by for example informing the internet address of the web page wanted, called "redirecting" in this text.

In this context the word "bank server" means a payment provider, which can be an actual bank institution, another company (e.g. a telecom or electrical operator who already has a billing relationship with the customer) or a joint operation with a bank and another company.

User registration

The administration of the payments are handled by the bank server. In some embodiments, before the services can be used through this payment method, the user has to register himself to the bank server. The bank server has software with which the user registers himself and with which the accounts of the users are handled. In practice, this can e.g. be done via the bank's web site.

Such a bank web site, can e.g. be constructed so that a registration function can be selected and information asked for can be typed in (such as name, e-mail address, payment information, etc). This operation registers the user's information at the bank and creates an account for the user.

After this, the user is given a password or a pin code with which he can identify himself to the bank later. Optionally, the user can ask for a cookie to be set on his computer so that the bank can recognise him without asking for the password and other identifying information, when a payment is performed.

Cookies are small pieces of data that can be sent from a www server to the client's browser software. After that a cookie has been sent, the browser will send the cookie back to the same www server whenever it requests more information from the same server. A cookie can be set to expire at the end of the user's session (until the user closes the browser) or more permanently, until a certain date, which allows the user (or to be more exact, the user's browser software on a certain computer) to be identified even after a considerable period of time.

Typically, a cookie contains an account number or identification and possibly some information which allows the bank to make sure that the cookie was generated by the bank earlier (such as a cryptographic checksum).

The user can then also transfer money to his "bank account" at the bank server by using any of different available means (e.g. credit card payment, wire transfer, mailing a check, etc).

In some embodiments, the user can set up preferences of how his account will work. The web site with which users register themselves can be built up so that the users can see their own transactions, set configuration options, cancel payments, etc. These will be described more in detail below.

Service provider registration

Also service providers wishing to offer services or content using this payment method have to register themselves and create an account at the bank so that the bank can identify them. The service providers register themselves in the same way as any customer, but in addition to the normal customer information, they can also set up services that the bank knows about and can charge for.

To set up a service that the bank can charge for, the service provider tells the bank what kind of services they want to set up and where the actual pay-for service is located. A service set-up information can include information such as:

• Different access alternatives to the service: e.g. if the payment in question allows for one access to the information or content, for a certain number of accesses, for free access for a given time period (subscription to the service) or for free access wherein the payment is voluntary.

• The price of the service

• A product code for the content or service, which the bank will send to service provider e.g. the seller at each transaction, allowing the seller e.g. to do bookkeeping if they so wish.

• The location of the pay-for content so that the bank knows where to redirect (e.g. automatically make the user's browser go to the address of the paid service) the user after that the payment has been made.

• The address of the seller and any appropriate tax related information so that the bank can deduct applicable taxes when paying the seller.

After that the information has been provided, the bank server will present to the service provider several options that the service provider can choose to use in the cooperation between the bank and the seller:

• A piece of static HTML text can be offered to the seller that the seller can copy and paste into its own web page HTML code. The HTML code thus generated, basically includes a link to the bank, indicating the product code, and the visible content of the HTML code includes an image link to the bank, which the bank can use to generate a "pay this content" button for the user. By means of this option the service provider can sell services without having any own payment software at its own server.

• Necessary encryption keys for a more secure payment option can be offered, which can be used if the seller is willing to add software to their web site which checks each payment transaction using the information provided by the bank.

• Information necessary for a mobile payment solution can be given, which the seller can put on its web site and allow users to pay with a mobile payment solution by using the keyword given by the bank. Using of services

When in the invention the user sends a request for a service to the service provider, the service provider instructs the user to continue if the conditions for using the service are accepted. The service provider can for example inform the price for using of the service and provide the user with a web page in which the user can click on a button on the screen if he wants to continue the service and accepts the conditions (pay the price required).

By clicking on the required button, a message goes to the bank server with e.g. a cookie (a collection of user information) of the user and the bank server can then match the user with a registered one in the register. As was mentioned earlier, the user can also identify himself with a password, pin code etc.

When the user has indicated that he accepts the conditions and is willing to pay the price, this message goes to the bank server. The bank server then requests the user to pay the amount required or deduct the payment from the user's account. The request to pay can be done with a web page so that the user again clicks on a button which results in paying the amount, or it can be accepted automatically if e.g. the amount is less than a set limit. As a result of the paying, the amount in question is credited from the user's bank account e.g. immediately as a real time transaction.

In another version of the method of the invention, the user may use his mobile phone for using of the services.

In that case, when the desired service is a web page, the user first fetches the web page in the first step and thereafter, the service provider sends instructions to the user how to continue if the conditions are accepted. The user then sends a SMS message to the bank to inform the bank server for using of the service. Optionally, the bank can send a message back to the user to inform how to continue but in the preferred embodiment, the user knows from the earlier instructions what sum to pay and that payment is performed by means of the mobile phone. When it is question about a mobile phone, the payments can be performed via telephone numbers and telephone number charging. When the payment has been performed, the method continues as in the first version described. The bank server either tells the user how to find and use the service or it fetches the service for the user. The information back from the bank can for example be a requirement to put a given amount of money to the account or to call to a given number which is time based charged.

The service can e.g. also be used for payment of e.g. parking fees. The service you then get is a parking ticket. The service can also be a normal mobile service or a shopping or bank time. Furthermore, in the web page fetched, there can be a banner saying that by clicking there you donate a given sum for using of the service. For advertising purposes, the user can even be paid for opening of a web page.

As a summary, the advantages of the invention are that the seller (service provider) does not need any software on his web site to sell the content or a service. Optionally, the seller can check the bank-signed check to validate the payment. The invention allows selling and buying with extreme ease of use (one or no clicks, as described) by accepting a reasonable level of security instead of total security, with options for higher security when necessary. Furthermore, in the invention, micropayments can be collected and managed in a controlled manner. One important advantage is also that mobile payments for using of the services can be performed with a minimum amount of user interaction requiring only one mobile phone task.

In the following, the invention is described by means of figures and some examples to perform the method of the invention. The invention is, however, not restricted to the details thereof.

BRIEF DESCRIPTION OF FIGURES

Figure 1 illustrates a first embodiment of the method of the invention. Figure 2 illustrates a second embodiment of the method of the invention.

Figure 3 illustrates an example of the method of the invention.

Figures 4 - 8 illustrate more detailed examples of the method of the invention.

DETAILED DESCRIPTION

The method of the invention is in the following examples described in figures 1 - 8 performed in a telecommunication network comprising a user terminal to which the services are delivered, a service provider that delivers services and a bank server which administrates the payment. These three components are connected to the internet. If the user terminal is a mobile station, it can be connected to the internet through the mobile network, such as GSM via e.g. the WAP protocol, or in another known manner.

In the first embodiment of the method of the invention, it is assumed that the user terminal used by the user is a PC and that the desired service is to make use of a service provided by a web page from internet. To use the service, the user sends a service request in step 1 to the service provider being the owner of the desired web page. As a response to the request, the service provider sends a web page with instructions to the user in step 2 for how to proceed if the conditions to use the service are accepted. The instructions are sent in form of an image, which is served from the bank. The image can e.g. request to click on a button if a price of e.g. two dollars is acceptable. If the user then continues by clicking on the button, a message goes to a bank server with user information of the user in step 3. The bank server has software for the management of users using services of the service provider. The user has to register himself in advance and then the software allows to uptake a new user in the user list. The user however has to have a bank account in the bank handled by the bank server. When the bank server has received the user information sent by the user in step 3, it sends a request to pay for the service to the user in step 4. This request can be forwarded to the user in form of a web page, wherein there can be a button on which the user again can click to perform the payment. The payment performed by the user in step 5 can be set to happen in several ways. It is either a real-time transaction, in which the sum paid immediately is debited from the bank account of the user or it is performed as a credit card payment.

After the payment, the bank server in this example sends a message in step 6 to the service provider to send the service to the user. In step 7, the service provider sends the service content to the user and the user can use the service.

In the embodiment of figure 2, the user terminal has a mobile station with which the services can be used. The method of the invention reminds of the one in figure 1 with some small differences. Steps 1 - 3 are the same as in figure 1. As the user terminal now is a mobile phone, there is no need for the bank server to send a request to pay in form of web page to the user terminal because the user can perform the payment directly by means of the mobile phone. This means that the payment can be performed with a SMS message or a telephone number can be called to and an invoice can be sent to the user. In step 3, the user information was sent by means of a SMS message as well. In step 5 in this example, information of how to find the service is sent in step 5 from the bank server to the mobile station after the payment. In step 6, the mobile station sends a service request to the service provider which send the service content in step 7 back to the mobile station and the user can use the service.

In one embodiment the user specifically gives information about the payment event to the web server.

Some mobile devices allow the bank to bill transactions to the user's phone bill, possibly via a telecom operator. An exceptionally convenient way of paying via mobile devices in the invention can work as e.g. indicated in figure 3.

The user goes to a preliminary web page (step 1) which has instructions for using the system (step 2). The instructions tell the user to send a specific SMS message to a number (or execute some other billable event such as a call to a given number). This message is sent by the user to the bank's web server (just like the payment button link described earlier) (step 3).

When the SMS message arrives at the bank's server, the bank records that the given phone number has paid for a given service (step 4).

The bank server now redirects the user's browser to the real content (step 5 and 6) just like in the payment button case described earlier, with the same security etc. options without user PC interaction.

In another embodiment, which is easier for the user, a billable mobile device message or event is sent and the content appears automatically in your browser. (E.g. figure 4)

The user goes to or is directed to a web page requesting a mobile payment (step 1). The instructions on this page (step 2) tell him to send a given SMS message to a given number (or do the other billable event). For example: "Send a SMS to pay for service 2134 to number 13579 from your GSM phone. The price is $0.50.".

The user then sends the SMS message or calls the given number. The bank checks from the content of the SMS message or event which user paid for the information and proceeds with that information. For each concurrent user, a different codeword or message is generated so that their billing events can easily be distinguished and identified.

This web page with instructions might be a part of a web page with information for how to find the requested service. Technically, this web page is thus not completely sent immediately, only a first half of it (e.g. using the HTTP push specification or just sending the instructions first and keeping the connection open in an unfinished state), including the instructions. The connection is left open waiting for more data. Another possibility is that the payment instruction page or a portion of it is periodically reloaded from the server (with a refresh HTML setting). As long as the bank server has not received the payment, only a half of it is sent. But as soon as the payment by SMS is received from the user, the complete page is sent.

So, when the bank receives the billable event via the telecommunications network, it sends the rest of the web page to the user (if this embodiment alternative mentioned above is used). This can contain the information paid for or it can contain a link or redirect instructions for the user's browser to direct the user to the paid content.

Figure 4 describes an example of the invention in which a mobile station is used for payment of the service used. The user has a web browser in his PC, and sends a request for a service to the service provider in step 1. This request is a request for a web page, which is requested in a usual way by writing the internet address of the web page in e.g. the form www.service.com. In step 2, the service provider sends a web page back to the client's web browser with instructions for using the service offered by the web page in which the conditions for using of the service as well as a description of the content of the service are described. On this web page with instructions, the user can click on a link for getting the content if he accepts to pay for the service which in this case is the condition for using the service. By clicking on the "get content" link, a message is sent from the client's web browser to a bank or a special mobile payment service server in step 3. The address for this link can for example be in the form http://mobile.com/pay?service=book345.

In case the user earlier has made a subscription for the service, he is now redirected to use the content of the required service right away, the next step being then step 6, which will be described below.

If no subscription has taken place earlier, the bank as a result of step 3, generates a unique ID for the user so that the bank later can check if a payment has been made by the user. Different codes are generated for each user for using this service. After this, a web page is generated with instructions for paying, the unique ID also included in the web page. This web page is sent to the client's web browser in step 4 from the bank. This web page can be the first part of the web page required. The instructions in this first part of the page contains a code for the service and instructions for the user for how he can use his mobile phone to pay for the service. The payment can e.g. take place by sending a SMS message or by calling to a number given in the instructions and by referring to the unique ID code.

In step 5, the user then sends the SMS message containing the code of the service and possible other information from his mobile phone. When the user sends the SMS message, it is possible to make a subscription contract for future use of this service as well. In this case, subscription data is stored by the mobile payment server. As a result of step 5, it is recognised which web payment the message is connected to, the ID is checked, and when the payment made with the mobile phone is recorded, the rest of the web page is sent to the client or he is redirected to it in step 6. The message in step 6 from the mobile payment server to the user's web browser either contains the rest of the web page or then there is information of the location where the user can fetch the page.

The rest of the page might have embedded information to the content location (the service provider), e.g. as in the form of javascript like

<SCRIPT LANGUAGE="JAVASCRIPT"> window, location =

"http://service.com/content/book345?paid=5FIM&checksum=21953292..."; </SCRIPT>

In step 7, the user then fetches the rest of the web page from the content location or service provider, who can optionally check said payment info encoded in the content location request.

In step 8, the service provider then finally sends the content of the service to the user's web browser. Figure 5 is an example of the method of the invention with which the service is bought without any user interaction for the payment itself. In this embodiment, the user has registered himself in advance and made a "contract" on a given sum to be used for one or several services. This sum might e.g. be put as real money on the user's account, which in this text is called "hard cash". The sum can also be agreed on for example in such a way that the user has given a credit card number so that he can be charged. Such money is referred to as "soft cash" in this application. The user's account at the bank server can contain amounts tagged with e.g. different levels of reliability (already transferred cash may be "hard cash" as it is already available, money paid with a credit card may be "soft cash", which might have been cancelled before the credit card company actually would transfer the money to the bank). The sellers can choose what level of reliability of payment (i.e. how probably they will get their money) they are willing to accept.

Thus, as in the foregoing examples, the method begins with step 1 , in which the user sends a request for using the service to the service provider. In step 2, the service provider sends in this example a web page (e.g. in HTML language) with image references. In this case, one of these images is a link to a bank server, whereas the other images are normal images which are fetched from the service provider by the browser. The web page contains bank image links of type "zero click payment". In step 3, the user's browser requests a normal image and gets it in step 4. Step 5 is a request for a further normal image which is sent back in step 6. The third image, however, is not directly given to the client for free, because by requesting this bank image, a message then goes from the user to the bank in step 7 with a cookie with user information and a request for payment of the service. The address to send this message can for example be http://bank.com/image?seller=service&type=zeroclick& price=0,01 EUR&check=Z8993. This means that in the message of step 7, there is information of the service content requested, information of the seller, the type of the service requested, the price and cookie information, e.g. bankaccount= 12345 in a HTTP request can be included in the request. Optionally, it also includes a cryptographic checksum to prevent the seller from changing the link, e.g. a MD5 sum of other fields. It has to be noted that steps 3 - 6 are presented for illustrative purposes only, to show how images normally are fetched, which are not charged for.

The bank then recognises the zero click payment image request of step 7 and checks the user settings to see if the payment can be allowed without user interaction.

If a payment has been performed, e.g. a thank you image message is generated and the paid money is transferred from the user's account and recorded.

If a payment is not done, for example a daily limit is exceeded, a usual payment image is generated, which is sent back to the user and the method continues as from step 8 of figure 7.

In step 8, the generated thank you message for the payment is sent to the user.

In figure 6, steps 1 - 4 describes the steps for user registration. In step 1 , a message for requesting for a service is sent from the user browser to a bank server as in figure 4. In step 2, the bank sends a log in or register page to the user with a form to fill in. The user then fills in the form sent in step 2 and sends the filled form in step 3 back to the bank. The bank saves user data and creates a bank account cookie. In step 4, the bank sends a welcome message to the user with the bank account cookie and a header sent along with the web page content. The cookie can for example include information such as the bank account number 12345, the expiration date and the host address e.g. www.bank.com. A cookie is saved by the user in a cookie storage within the user browser.

In figure 7, steps 1 - 6 are as in figure 5. In other words, the html page sent in step 2 can contain reference images and one of them might be a bank image with buying instructions such as figure 7. The bank image might contain information such as <A MREF=http://bank.com/pay?seller=service&product=story35&check=A56183. In step 7 of figure 7, a request is sent from the user browser to the bank with a bank account cookie for payment. The address might e.g. be in the form http://bank.com/image?seller=service&product=story358check=X8993. This case is a normal buying transaction in case of a registered user. If the subscription is still active for e.g. five days, an image is generated with information about how much time of the subscription is remaining, for example the message might say "five days subscription remaining". In other words, the user is identified and the required product is identified and a payment image is generated which is sent back in step 8. This page is displayed on the user's browser with a payment image.

In step 9, a payment request with a bank account cookie is then sent to the bank again with the address http://bank.com/pay?seller=service&product=story35&check=A56183. The user is identified and also the seller's product. The payment is also identified and money is transferred from the user's account to the seller's account. The content location address for the required service is generated and recorded.

If the subscription is active, this content is redirected without billing but in case it is a subscription request, a subscription fee is charged and subscription data for the user is saved.

In step 10, the information of the content location is then sent to the user with the content location address e.g. in the form a header in a HTTP protocol response "Location: http://service.com/content/XYZ58348/story35html?paid=5FIM&check=Z2669."

In step 11, the content location is fetched from the service provider and is sent back from the service provider to the user in step 12.

Figure 8 is a further example of the method of the invention. Steps 1 - 6 are as in the foregoing figure 7. In step 7, an image request is sent to the bank from the user browser without any cookie so the bank has to generate a login or register image as in figure 6. This register image is then sent back to the user in step 8 and the user has to click on a payment image to pay for the service. In step 9, the payment request is sent without any cookie from the user browser to the bank. Then user registration takes place as in figure 6. In step 10, the content location address is then sent from the bank to the user browser with a bank account cookie and in step 11 , the content location request is sent from the user to the service provider and the content is sent back to the user in step 12.

Description of transaction and control alternatives in the connection of using a service in accordance with the invention

When a user wishes to access some service or information on the network, such as internet or a mobile network, he can go to a web page at the sellers web site, wherein there is a description of the service or information.

The user then clicks on a button on the seller's web site resulting in that the bank receives a request for a payment button image. The bank now knows who the seller is, what the product is (from the image link or name) and the bank can identify the user automatically if the user's browser has a cookie that it will send to the bank (and only the bank) when the user requests the payment button image.

The bank then generates a suitable image for a transaction to pay for the service and sends that to the user. The payment button is generated by the bank's server which can identify the user by means of a cookie in the user's browser software which is sent to the bank each time the user requests information from the bank by clicking on the button.

The payment image button generated by the bank can contain the following information, if the user has registered himself in advance:

• The user's name or other identification information.

• The amount of money in the user's account

• The price of the current transaction • The type of the current transaction (e.g. one-time, several times, subscription, ...)

• Graphical elements in order to give the user the feeling and knowledge that the sent payment image button really come from the bank server, who is the only one who has the necessary information to generate the image button.

For example, a static HTML version of the payment image button and link might look like:

<IMG SRC="bank.com/button/seller123/product12345.gif WIDTH=150

HEIGHT=100 BORDER=0>

</A>

If the user wishes to pay for the transaction, he clicks on the payment button on the page and activates a link to the bank's server. The bank's server receives the link that informs who the seller and the product are and the bank can identify the user from the cookie sent by the user's browser earlier.

If no cookie was sent from the user, then a generic payment button without user- specific information is displayed, and when the user clicks on the image, a login or registration screen is presented for him, where he can log in with his existing password and information or register into the system, or pay one single event without registering for continued use.

If the user has configured his account for example to allow automatic payments only up to some specified amount, the amount to be paid is checked by the bank and if the price exceeds this amount, the user is asked to confirm it before proceeding. The user can also set a maximum value to be paid per day or week or month. When this amount has been spent, the bank begins to ask for confirmations. The user can also set security preferences so that a PIN code is required for every payment.

After the bank has identified the user and checked that all information is correct, it will record the transaction, move the money from the user's account to the seller's account if necessary and send a reply to the user's browser that will enable the access to the paid content.

The reply can be a HTTP protocol redirect response which makes the browser automatically go to the specified web address, or it can be a link to a server program on the sellers web site which will handle the secure payment information sent by the bank.

After that the user can use the service either in such a way that the bank server fetches and delivers the service to the user or so that the user's browse-software is informed how to find the web page asked and can then fetch it.

Preferably, at any time, the user can visit the bank's web site directly to see their account information. This information includes a list of all transactions (when, from which computer, which seller, which product, price) they have done.

To provide a good user experience and to comply with postal sales laws in several countries, the user is allowed to cancel any payment they wish without questions asked. The user may be asked to provide some general information about the reason for the cancellations (e.g. reason might be a technical problem, or the content was not good enough, etc).

In this way the users can use the system without any concern, as they can cancel any payments they are not happy with. There would be a time limit (perhaps 2 weeks or a month) after which the transactions can no longer be cancelled, and after which the payment will be made to the sellers.

At the time the button is displayed, the bank knows who the user is, what the service is and can make a transaction right there and indicate this in the payment button, e.g. "$0.01 paid for viewing this web page. The payment entitles you to see this web page for a week". This means that when the payment button is displayed to the user, the transaction has already been made and the user sees e.g. the information "$0.01 paid for viewing the web page" image in the payment button image.

The bank's system may allow the user to set limits within which an automatic shopping alternative function will work (a function without any need to click for payment), e.g. a maximum amount of $0.05 at time or $1 per day. If these limits are achieved, then the system will no longer automatically deduct money from the users account, but will instead display a payment button on which the user can click if he wishes.

This means that web pages can automatically deduct a small optional amount from the user without requiring the user to do anything. This solution will allow micropayments to be used on many web pages without user interaction.

The same options (once, several times, subscription) can be applied to these kind of "zero click shopping services" as for the normal services.

The bank also can keep track of subscriptions. A payment button can indicate for example that, by paying, the user will get one month use of the resource. If the user pays, the bank will record the subscription in it's customer database, and the next time the user goes to that web page, the button will directly indicate e.g. how many days there are left of the subscription to a certain resource. This can be implemented in the bank by storing in the customer database the customer identification, the service identification and a date when the subscription runs out.

The bank can also handle services where one payment entitles the user to a given number of uses, e.g. 10. In this case the bank would record the user identification, service identification and the number of uses left, and the payment button would indicate how many free uses the user has left before having to pay again. There can be different options to pay for a single resource, e.g. for a one-time use, a time-based use e.g. 2 hours, a monthly subscription etc, and the user can select some of different options.

The customer database at the bank could contain e.g. The customer's name and other personal information The user's e-mail address The user's mailing address

The user's age (e.g. if they pay with a credit card, they have to be of a certain age) The amount of money in the customer's account A list of all the transactions the user has done

A list of products and the product related information (e.g. price, type of sale) for each product a seller has registered for.

Statistical information about the user's cancellations and items for sale, for determining estimates or reliability or payment percentages, for example number of cancellations per type of sale, percentage of failed payments to their account, generic credit report information, etc.

This kind of information would be typically stored in several interlinked tables in a relational database at the bank servers.

The bank can also contain software that keeps track of the information in the database. The software can also calculate the amounts to be paid for each seller and divide the users' payments between the bank and the sellers according to the transactions and contracts.

The invention also provides methods for controlling the behaviour of the content sellers (service providers) as well as of the users by collecting information of the sessions.

In one embodiment each user and seller account may be build to contain different kinds of money, e.g. hard cash and soft cash. The different kinds of money can be separated by e.g. currency or reliability of the money. For example, money that the user has wire transferred to the bank can be stored with a higher reliability factor ("hard cash") than money that the user has paid into their account by a credit card which has not yet been paid from the credit card company ("soft cash"), as this money may not actually appear if the customer cancels the payment with their credit card company. After that the credit card payment arrives, the amount would be converted to hard cash.

This information can be used in calculating estimates of how probably the seller will actually get their money. Also, if the seller sells a physical product, they may want to sell only with hard cash which has a high level of guarantee for that they will get their money.

The seller will be paid for the services or content sold during some certain period. This payment could happen each month. The payment can be delayed until the money has actually been paid by the users (as can be in the case of credit card payments). The payment can be paid to the account of the seller or be sent as a check via mail or other suitable means.

If the seller is a taxable entity, then the bank can optionally calculate the appropriate taxes and deduct them from the payment before sending the money to the seller. This will vary in different jurisdictions.

The most popular payment systems currently in use (credit cards) are convenient and easy to use even if not built to be 100% secure. A small percentage of fraud is accepted in the system in order to make it easy and convenient to use for the customers.

A 100% secure system usually means that a system will be inconvenient to use due to the many security checks necessary. It will also require special software for the user and the seller, making it hard to start using the system. In the payment system presented here, small scale fraud or cheating is possible (for example the buyer can cancel his payment after receiving the service or a seller may not provide the information or service paid for), but in the long term the system can limit this to an acceptable level using similar statistical and other known methods currently used by credit card companies.

For example, if there are many complaints about a seller, the bank can pay the seller a smaller amount thus making it more profitable to provide a working and good service that does not generate complaints. Similarly, if a user cancels payments to sellers which have been found good by most other users, then the user can be placed on a watch list or required to pay any transaction as it happens without the chance of cancelling it, making it unprofitable for the user to complain without good cause.

In the credit card business fraud and problems have been successfully limited to a few % of the total turnover. Similar low rate of problems can be achieved in this payment system, while keeping it extremely easy to use.

The system is invisible for the user, they just see a price they have to pay. From this price, the bank's share is deducted and from the rest the seller will get an amount depending on their rating. Typically, a seller would get perhaps 90% of the money the user paid, the rest being used to cover possible problems, the bank infrastructure and the profit.

The system can collect information of content providers that too often do not deliver the service the user has paid for or delivers services that often result in complaints.

When the user pays for the service, the bank server gets a certain profit. Content providers can be controlled e.g. so that in the beginning they only can keep 60 % of the payment and when it appears in the future that the content seller has followed certain rules, i.e. delivered the service paid for, the portion to be kept can be gradually increased. When a new seller starts selling, he will be given a default rating. If the shop gets good reviews from users or no complaints, his rating will be adjusted up higher. If there are complains about the seller or other problems (e.g. server down too often), then the rating can be lowered.

The seller rating can be used to adjust the amount of money the seller will be paid. A good seller may get 95% of the money the user paid. A low-rated seller may get only 50% or even less of the money. This provides a strong incentive for the seller to operate in as good way as they can, to drive up their own income.

In this way, the sellers can be controlled by dynamically changing payment percentages and schedules, based on their reliability and quality of service.

This invention is useful also for other services than for internet web pages. The system can for example be used for collecting money, for buying products and for delivering tickets.

The user interface to the bank describes the way of transferring the money. It can be performed as a net account transfer, a telephone payment, a check payment, a wire transfer or a credit card payment.

As a summary, the invention also allows for cancelling of the payment if the user did not get the service paid for. There can be situations in which the downloading of the web page did not succeed because of bad connection etc. and then the user can cancel the transaction. The controlling system in the invention, however, can control users and their cancelling and make statistics of them. If it appears that the user is suspected to cancel the payment with no reason, he can only use the services in future with no right to cancel the transaction. The controlling system can be made to automatically do that for example by prohibiting the user to cancel if his cancel percentage is over a given threshold value or if the credit information of the user is bad. The system can also collect reasons for the cancelling. The user can e.g. click on certain alternatives to send the information of the reason for the cancelling to the service provider. The reason might for example be a technical error or some other problem in the downloading. It might also be that the user felt that he did not get what was promised or that the quality of the service was bad.

The invention also might use warning systems and different prices for different users etc.

In the payment administration system, the user can also define how much a service is allowed to cost or the maximum amount per day of how much the services can cost him. He might get status information of the amount paid at given times. The service providers can define to which class a user belongs according to desired payment values etc.

There are several alternative methods for performing the charging. They can be performed as one time transaction requests, as subscriptions, as a certain amount of times until a given date or on the basis of the price. The subscription management system used in the invention can also be made to check that the user is an adult. The bank server can be the bank itself or it can be e.g. an operator that is in close cooperation with the bank or a credit company or other financing company.

The content seller (service provider) can sell additional functions, like checking of information and taxes, registration of products, adding content to pages, tell prices and inform what the content of a given URL-addresses is. The content provider can use a ready html page within which it can put its own information. There might be a box in which the html code is introduced. It can have a system that informs what it wants to sell, the price and tell about the content of its service. When the user has paid and ordered the service, the bank can either fetch the content to the user or it can hide the real address from the user. The address can also be encrypted.

Claims

1. Method for delivering a service in a communication network comprising one or more user terminals to which the services are delivered, a service provider that delivers and charges for the services, and a bank server which administrates the payments made by the users, characterized by the following steps in a session in which a) a user sends a request for a service to the service provider, b) the service provider sends instructions to the user to continue if the conditions for using the service are accepted, c) the user sends a message to the bank server for using the service, d) the bank server requests the user to fulfil the conditions for using the service if they are not already fulfilled, e) the user performs the operations needed to fulfil the conditions, f) the bank server directs the user to the service needed, and g) the user uses the service after having received the service.

2. Method of claim ^characterized in that the user terminal is a PC, a mobile phone, a lap top etc.

3. Method of claim 1, c h a r a ct e r i z e d in that the service is intended for collecting money, for giving money, for ordering of web pages, for buying products and/or for delivering tickets.

4. Method of claim ^ characterized in that the bank server is a bank, an operator or another company in co-operation with the bank, a credit company or another financing company.

5. Method of any of claims 1 -4, characterized in that, in that the conditions mentioned in step b) to use the service is to pay a certain amount which is performed in step e).

6. Method of claim 5, c h a r a ct e r i z e d in that in step d), the bank server requests the user to fulfil the conditions by means of web page on which the user can click on a button to pay an amount required with a transaction, a subscription or the like.

7. Method of claim 6, characterized in that the payment can be performed as a one time transaction or as a subscription allowing a certain amount of times of using until a given date.

8. Method of any of claims 5-7, characterized in that the payment can be performed as a net account transfer, a telephone payment, a check payment, a wire transfer or a credit card payment.

9. Method of claim 8, characterized in that in case of a telephone payment, the bank server informs in the message of step d), the telephone number to which the user can call or send a message with his mobile phone or fixed telephone to pay for the service to be charged in connection with the telephone bill.

10. Method of claim 9, c h a r a ct e r i z e d in that as a result of the payment transaction in step d), the amount is debited from the user's bank account as a realtime transaction to the service provider's bank account.

11. Method of claim 10, characterized in that a billable message is sent from a mobile phone to pay for the service.

12. Method of any of claims 5-11, characterized in that the message in step d) includes a unique ID for the service session created by the bank server to be used in connection with the payment of the service.

13. Method of claim 5, characterized in that the user is registered to the bank server before using of the service.

14. Method of claim 13, characterized in that the user gets a cookie with user information as a result of the registration.

15. Method of claim 14, characterized in that the cookie is sent to the bank server in connection with step c).

16. Method of any of claims 13-15, characterized in that steps d) and e) can be omitted if the user fulfils the conditions of step d) in advance by putting a certain amount of money on his account to be used for the service or by a subscription.

17. Method of claim 16, characterized in that steps d) and e) are omitted if a subscription to use the service requested is in force.

18. Method of any of claims 13-15, characterized in that the user can partly fulfil the conditions of step d) in advance by giving a credit card number so that he can be charged for a certain amount of money.

19. Method of any of claims 16-18, characterized in that, as a result of step c) or e), the bank server transfers the sum from the user's bank account automatically after that the user has fulfilled the conditions without any further user interaction.

20. Method of claim 5, characterized in that the user is registered in connection with step c).

21. Method of any of claims 1 -20, characterized in that in step f), the bank server is fetching the service to the user terminal.

22. Method of any of claims 1 -20, characterized in that in step f), the bank server informs the user how to fetch and/or use the service.

23. Method of claim 21 or 22, c h a r a c t e r i z e d in that the information in the messages of step d) and step f) are on the same web page.

24. Method of claim 23, characterized in that the part of said same web page that contains the instructions are sent in step d).

25. Method of claim 23 or 24, c h a r a c t e r i z e d in that the rest of the web page is sent automatically as step f) after that the user has fulfilled the conditions without any further user interaction.

26. Method of any of claims 21 -25, characterized in that the real address of the web page to be fetched in step f) can be hidden from the user.

27. Method of any of claims 6-26, characterized in that the transaction can be cancelled by the user.

28. Method of any of claims 1 -27, ch aracte rized in that information of the sessions are collected.

29. Method of claim 28, characterized in that the collected information includes statistics about users that did not pay for ordered services because of missing money in the bank account.

30. Method of claim 28, c h a r a c t e r i z e d in that the information collected includes the reasons for the cancelling of the transactions.

31. Method of claim 11, characterized in that the user is prohibited to cancel the transaction if his cancel percentage is over a given threshold value or if the credit information is bad.