WO2001097104A1

WO2001097104A1 - A method and system for billing for services delivered via a data network

Info

Publication number: WO2001097104A1
Application number: PCT/FI2001/000577
Authority: WO
Inventors: Juhani MÄKELÄ
Original assignee: Swwap Oy
Priority date: 2000-06-16
Filing date: 2001-06-18
Publication date: 2001-12-20
Also published as: EP1312002A1; AU2001269161A1; FI113098B; FI20001446A; FI20001446A0

Abstract

A method (300) for billing for services comprises the steps of receiving (301) a service request, fetching (303) the service from a separate server, modifying the service into a modified service, and delivering (309) the modified service to the origin of the service request. If the requested service is a chargeable service, billing information is stored (302) after the service request is received. Furthermore, it is determined (305) if the service comprises links to further services. If those services are chargeable, prices for them are determined (306). The prices of the further services are included (307) to the service and the links in the service are modified (308) to point to local services, before the service is delivered (309) to a user. A portal system (200) is also presented.

Description

A method and system for billing for services delivered via a data network

The invention relates in general to services delivered via a data network. In particu- lar the invention relates to billing for such services.

A portal is technically a collection of links to a variety of Internet services each having an URL (Uniform Resource Locator) address. A part of the services related to a portal can be provided by the company owning the portal, by typically at least part of the services is provided and maintained by separate partners. The partners may host the services, which they provide, on their own servers. The portal site has a link to the service URL. The users accessing the services provided by a portal are customers of the portal. The portal typically collects charging information and charges the price of the used services from its customers.

In most services, a user gets the actual value-added piece of information he is interested in only after several steps, e.g., after input of search parameters or a number of selections in a menu structure at the partner's site. The point where the user gets the value-added information typically differs from the starting page of the partner's ser- vice. Typically a portal page contains a link to the starting page of the partner, and a user entering the partner's site from a portal enters the starting page.

Figure 1 presents schematically an example of services relating to a portal and how they are delivered to a user. A user downloads to his terminal 101, which may be, for example, a desk-top computer, a laptop computer, a handheld portable device or a portable telephone, a portal page 110 from a portal server 102 hosting the portal. The local copy 110' of the portal page is typically stored at the user's terminal, and as the users chooses one of the URLs on the portal page 110, the terminal 101 typically transmits information about the selected URL 111 to the portal server 102 (ar- row 1 in Figure 1). The portal server 102 typically returns to the terminal 101 the URL of service the link 111 is pointing (arrow 2 in Figure 1). In Figure 1, the URL 111 points to the partner starting page 120, and the terminal 101 downloads the starting page from the partner server 103 (arrow 3 in Figure 1). After this point, the portal server 103 does not know, which pages the user is selecting. For example, the user may select on page 120 an URL 121 pointing to page 130 and on page 130 an URL 131 pointing further to page 140. The information contained in the pages 130 and 140 is typically transmitted to the terminal 101 from the portal server 103 (as arrow 3 in Figure 1 illustrates). One revenue source to a portal is the price that a user pays from using the services linked to a portal. When a user enters to URL that has a price, a transaction occurs and the user is charged for the service. The URLs, for accessing which a user has to pay, are called transaction points. Typically, after the user has entered a partner's site, he is no more inside the portal and the portal cannot track his events. This means URLs inside a partner's site, beyond the starting page (i.e., entry point) of partner's service, cannot be set as transaction points where a user account is charged. Referring to Figure 1, the URL 111 on the portal page 110 can be set as a transaction point, as the portal receives information (arrow 1), when the user selects this URL. The URLs 121 and 131 in the partner's sides cannot be set as transaction points.

If the entry point to the partner's site (for example URL 111 in Figure 1) is used as a transaction point, the user is billed without necessarily having been able to get the service he pays for. In most services, partner's front page is only a menu page with different categories, e.g., in a typical news services they could be "Main headlines", "Sports", and "Foreign". Under these categories are commonly the headlines, and behind each headline there is the actual piece of news the user has been looking for. In order to see the piece of news, in this example user needs to go through various links, and only after the last one he gets the information he is looking for and is willing to pay for. In Figure 1 the piece of information the user is actually looking for may be, for example, page 140. If the URL 111 is used as a transaction point, the user would be charged when he enters the front page 120 - before he has had the opportunity to read any news on pages 130 and 140.

In a system presented in Figure 1, a transaction point, where user account is charged, must be set to the URL 111 that links partner service to the portal. It is not possible to charge separately for each page in the page hierarchy at the partner's site.

An object of the invention is to present a method, a system and software for billing for services, especially for services provided via a portal. Further objects of the invention are to provide a method, system and software, where prices of the services provided via the portal are displayed to the user, where the prices of the services are easily updated and, if necessary, the prices of the services may be user-specific. Objects of the invention are achieved by delivering partner pages to the user via a proxy server controlled by the portal and by adding to partner pages service price information before the pages are delivered to a user.

A method according to the invention is a method for billing for services, comprising the steps of:

- receiving a service request indicating a service,

- fetching a piece of information, which describes the service, from a separate server, - modifying the piece of information, resulting in a modified piece of information and

- delivering the modified piece of information to the origin of the service request, and characterized in that it further comprises the steps of:

- if the service is a chargeable service, storing billing information about the service after the service request is received, and

- determining if the piece of information comprises links to further services, which are chargeable, and

- determining prices for the further services, and in that the step of modifying the piece of information describing the service comprises the substeps of:

- including the prices of the further services to the piece of information describing the service, and

- modifying the links in the piece of information describing the service to point to local services.

The invention relates also to a portal system, which comprises

- means for receiving a service request indicating a service,

- means for fetching a piece of information, which describes the service, from a separate server, - means for modifying the piece of information, resulting in a modified piece of information and

- means for delivering the modified piece of information to the origin of the service request, and which is characterized in that it further comprises

- means for storing information about a set of chargeable services, - means for storing information prices for the chargeable services,

- means for storing billing information about chargeable services, arranged to store said billing information after a service request is received, - means for determining if the piece of information comprises links to further services, which are chargeable, and for determining prices for the further services,

- means for including the prices of the further services to the piece of information describing the service, and - means for modifying the links in the piece of information describing the service to point to local services.

The invention further relates to computer program comprising computer program code means adapted to perform all the steps of a method according to the invention when said program is run on a computer and to a computer program product embodied on a computer readable medium.

The appended dependent claims describe some preferred embodiments of the invention.

In a method according to the invention, after the user enters the partner pages (services) via a portal page, the partner pages (services) are delivered from a partner server to the user via a proxy server. The portal server may act as the proxy server. Each page that user visits at partner's server is fetched, for example, to the portal server. After fetching a page, each link on a page is parsed to point to a local URL, for example to a URL at the portal server. Links on a partner page are manipulated so that they refer to partner's service pages fetched from partner's server to portal server. Therefore each partner page gets a new URL that is local. This is not visible to user. After a page is parsed, it is delivered to the user from the portal server.

A certain set of chargeable pages/services is typically defined. This set comprises the services/pages for which a user is expected to pay. For these chargeable services, prices are defined. The list of chargeable services and their prices can be stored, for example, in a database of pricing system. Each time a user request a certain page from the partner's site, the page is checked and if a link to a chargeable page is found, price information is added to the page. As the portal typically knows the identity of the user, it is possible that the prices of the pages depend on user identity. A certain user or a certain group of users, for example, can be given reductions on the prices. Furthermore, as the prices of the services are typically requested online from a portal pricing system, a method according to the invention allows, for example, that during a campaign the services of a certain partner are priced differently than usually. This can be done without any changes to the partner's services. The page delivered to the user preferably displays the prices of the chargeable services, to which that page contains links. A user sees how much the service costs or, in other words, how much the user's user account is charged when he clicks the link. When the user clicks a link, the page is again fetched from the partner server and delivered to the user via a proxy server. The price of a service is added to the user account when the user clicks a link of a chargeable service. It is alternatively possible to add the price of the service to the user account after the modified page is delivered to the user.

Using a method according to the invention, it is possible to place transactions points (i.e. points where a user account is charged) to any links in the partner pages. This allows a very flexible pricing of the service provided by partners. A user pays only for those pages he is interested in. This contributes to customer friendliness and portal pricing strategy: user needs to pay only when he gets what he wants, and portal can price services in atomic pieces and commit to true service-specific pricing.

Furthermore, a price of the link can be shown to user in connection with the link that charges user account. This contributes to service provider's responsibility to inform on the cost of the service to consumer and service usability: authorities may require that prices are visible, and if only separate pricing information pages to inform consumers exist, it makes the use of a portal cumbersome.

An additional benefit of this system is that it allows partners to maintain their service locally, without having to sacrifice user friendliness and operational features of billing. This simplifies maintenance and administration procedures significantly. It also helps to improve user friendliness and customization of partner's service - the proxy server parser module can use portal customer database information to customize the partner's service without cumbersome data exchange between portal and partner sites.

The invention relates to modifying services so that partner services are delivered via a proxy server (typically the portal server acts as this proxy server) and billing for the delivered services. The invention is not restricted to any specific networks or the protocols used in delivering the service from the proxy server to a user's terminal. As examples of possible networks and protocols, the following are mentioned. If the user terminal is a computer, HTTP (HyperText Transfer Protocol) is typically used for delivering the services from the proxy server to the terminal. If the user terminal is a handheld device communicating with a non-IP (Internet Protocol) network, pro- tocols specific to that network may be applied. An example of this is a portable telephone, wireless cellular network and Wireless Application Protocol.

The invention is described below in more detail with reference to preferred em- bodiments and to the accompanying drawings where

Figure 1 presents schematically an example of a prior-art system comprising a portal server and a partner server,

Figure 2 presents schematically a portal system according to the invention, and

Figure 3 presents a flowchart of a method according to the invention.

Figure 2 presents an example of a portal system according to the invention. In Fig- ure 2, the portal system 200 is a part of the portal server 102, but parts of the portal system 200 can also be in separate hosts that are typically controlled by the portal owner. The portal system 200 comprises Portal Application 201, which is responsible for the functionality provided by the portal service, such as user registration and providing the portal main page and other portal pages to a user. It further comprises a Pricing System 202, a Price Database 203, a Billing System 204 and a Billing Database 205. The Pricing System 202 is used to price URLs, which refer to service provided by partners or locally at the portal. Billing System 204 keeps user account on the transactions made by the user, and the corresponding prices at partner and portal site. The Pricing System 202, the Billing System 204 and the relating data- bases, for example, can reside on separate hosts than the rest of the portal system 200.

Proxy Server Module 206 in a portal system according to the invention is responsible for basic proxy server functionality: receiving service request from users, fetch- ing pages from partners servers, storing the pages locally to the portal server and delivering the pages to the users after the pages have been modified. In addition, a Proxy Server Module 206 is responsible for adding prices to the chargeable services, to which there are links on the pages fetched from a partner's site. A Proxy Server Module 206 is connected to portal Pricing System 202 and Billing Systems 204. In a portal system according to the invention, the Pricing system 202 is able to receive price request from the Proxy Server Module 206 and to response to it, and the Billing System 204 is able to receive billing infoπnation from the Portal Proxy Module The Proxy Server Module 206 typically comprises a Link Parser 207 and a Price Parser 208. The Link Parser 207 is responsible for converting the links on the partner pages to local links, as described above. The Price Parser 208 looks for links pointing to chargeable services, queries typically from the Pricing System 202 the price of a chargeable service, and then adds the price of the service, for example, to the end of the link to the service. The Proxy Server Module 206 may also check, for example, when it receives a service request from a user, if the requested service is chargeable, and insert the price of a service or other event record to the Billing Sys- tern 204. When a user clicks a link pointing to a chargeable service, the service request may include the price of the service, and it is possible that the price indicated in the service request is inserted to the Billing System 204.

A Proxy Server Module 206 according to the invention is typically software, which is located at the portal server. Similarly, the Portal Application 201, the Pricing System 202 and the Billing System 204 are typically also software.

A portal system may be arranged to implement any method according to the invention.

Figure 3 presents a flowchart of a method 300 according to the invention. In this method a service request is received (step 301), and the requested service is fetched from a separate server, if it is not already stored at the local server, in step 303. If the user is expected to pay for the requested service, accounting information can be stored at step 302. It is possible to store the accounting information alternatively at a later stage of the method 300. The requested service is typically a WWW page or other entity indicated using an URL, the service request typically comprises the URL and information describing the service is typically a HTML (Hyper Text Markup Language) document. Alternatively, the service may be a WML (Wireless Markup Language) document. WML documents are typically used, when a user accesses the service using a portable telephone or other handheld device having WAP (Wireless Application Protocol) capabilities. It is alternatively possible to access WML documents using any terminal that has a browser capable of processing WML documents. Furthermore, other XML-based (Extensible Markup Language) lan- guage documents may be used. HTML and WML documents are used here as examples, the invention is not restricted to them or to any other specific markup language. In step 304, it is checked if there are any links pointing to further services in the piece of information describing the requested service. In step 305 it is checked if some of the further services are chargeable, and if they are chargeable, prices for the services are determined in step 306. Typically the prices are requested from a data- base or from a pricing system. In step 307 the prices of the further services are added to the piece of information describing the requested service. The prices can be added, for example, to a HTLM document so that they are presented near the links to the further services. This way the user easily notices the price information. Referring to Figure 1, the prices can be placed so that as a user sees pages 120 and 130 on the display of the terminal 101, the prices are displayed adjacent to the link 121 and 131.

In step 308 the possible links to further services are converted to links pointing to local services, i.e. they are converted to local ULRs. This means that once the user clicks the converted links, the browser in his computer does not fetch the pages directly from the partner server 103. The local ULR indicates that the terminal 101 fetches the service from the portal server 102 acting as a proxy server, which proxy server in turn knows to which external service the local URL is related. The portal proxy server either fetches the external service from a partner server 103 (in which case it processes also that service according to steps 304-308 before delivering it to the user) or, if there is already a local copy of the service, which is stored in the proxy server, it can deliver the local copy to the user.

In step 309 the modified WWW page, for example, is delivered to the user. The prices relating to the links on the page are shown on the page. If user clicks one of these links, the user's terminal sends a service request to the portal proxy server (as discussed in the previous paragraph), and the method is started again from step 301.

The service request received in step 301 may be, for example, a service request indi- eating that a user wishes to enter a partner's site from the portal main page. Once the user has entered a partner's site via a portal, all pages may be delivered to him using method 300. As a user clicks any link on the partner's pages, the method 300 is started from step 301.

In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention. While a portal system 200 and a method 300 according to the invention have been described in detail, it should be apparent that many modifications and variations thereto are possible, all of which fall within the true spirit and scope of the invention as defined by the appended claims.

Claims

1. A method (300) for billing for services, comprising the steps of:

- receiving (301) a service request indicating a service, - fetching (303) a piece of information, which describes the service, from a separate server,

- modifying the piece of information, resulting in a modified piece of information and

- delivering (309) the modified piece of information to the origin of the service re- quest, characterized in that it further comprises the steps of:

- if the service is a chargeable service, storing (302) billing information about the service after the service request is received, and

- determining (305) if the piece of information comprises links to further services, which are chargeable, and

- determining (306) prices for the further services, and in that the step of modifying the piece of information describing the service comprises the substeps of:

- including (307) the prices of the further services to the piece of information de- scribing the service, and

- modifying (308) the links in the piece of information describing the service to point to local services.

2. A method according to claim 1, characterized in that it further comprises the steps of:

- defining a set of chargeable services, and

- defining prices for the chargeable services.

3. A method according to any of the preceding claims, characterized in that the prices for further services are included to the piece of information describing the service for displaying the prices to a user.

4. A method according to any of the preceding claims, characterized in that it further comprises the step of determining a user relating to the service request, and in that the prices determined for the further services are user specific.

5. A method according to any of the preceding claims, characterized in that the prices for the further services are fetched from a local database.

6. A method according to any of the preceding claims, characterized in that it further comprises the steps of:

- determining a user relating to the service request, - determining customization information relating to the user, and

- before delivering the modified piece of information, modifying the piece of information according to the customization information.

7. A method according to any of the preceding claims, characterized in that the cur- rent service is a web page and the links to further services are links to Uniform Resource Locators.

8. A method according to claim 7, characterized in that the piece of information describing the service is a HyperText Markup Language document.

9. A method according to claim 7, characterized in that the piece of information describing the service is a Wireless Markup Language document.

10. A portal system, comprising - means for receiving a service request indicating a service,

- means for fetching a piece of information, which describes the service, from a separate server,

- means for modifying the piece of information, resulting in a modified piece of information and - means for delivering the modified piece of information to the origin of the service request, characterized in that it further comprises

- means (203) for storing information about a set of chargeable services,

- means (203) for storing information about prices for the chargeable services,

- means (205) for storing billing information about chargeable services, arranged to store said billing information after a service request is received,

- means (208) for determining if the piece of information comprises links to further services, which are chargeable, and for determining prices for the further services,

- means (208) for including the prices of the further services to the piece of information describing the service, and - means (207) for modifying the links in the piece of information describing the service to point to local services.

11. A portal system according to claim 10, characterized in that it further comprises

- means (203) for defining a set of chargeable services, and

- means (203) for defining prices for the chargeable services.

12. A computer program comprising computer program code means adapted to perform all the steps of any of the claims 1-9 when said program is run on a computer.

13. A computer program product comprising program code means stored on a com- puter readable medium for performing all the steps of any of the claims 1-9 when said program product is run on a computer.