WO1999057662A2 - Charging in a computer network - Google Patents

Charging in a computer network Download PDF

Info

Publication number
WO1999057662A2
WO1999057662A2 PCT/SE1999/000706 SE9900706W WO9957662A2 WO 1999057662 A2 WO1999057662 A2 WO 1999057662A2 SE 9900706 W SE9900706 W SE 9900706W WO 9957662 A2 WO9957662 A2 WO 9957662A2
Authority
WO
WIPO (PCT)
Prior art keywords
information
apphcation
transaction server
cost
customer
Prior art date
Application number
PCT/SE1999/000706
Other languages
French (fr)
Other versions
WO1999057662A3 (en
Inventor
Kent Bogestam
Original Assignee
Ehpt Sweden Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ehpt Sweden Ab filed Critical Ehpt Sweden Ab
Priority to IL13917999A priority Critical patent/IL139179A0/en
Priority to KR1020007012008A priority patent/KR20010043117A/en
Priority to AU44024/99A priority patent/AU4402499A/en
Priority to CA002329769A priority patent/CA2329769A1/en
Priority to EP99927025A priority patent/EP1073983A2/en
Priority to JP2000547566A priority patent/JP2002513973A/en
Priority to BR9910076-2A priority patent/BR9910076A/en
Publication of WO1999057662A2 publication Critical patent/WO1999057662A2/en
Publication of WO1999057662A3 publication Critical patent/WO1999057662A3/en
Priority to IS5682A priority patent/IS5682A/en
Priority to NO20005468A priority patent/NO20005468L/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/88—Provision for limiting connection, or expenditure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/127—Shopping or accessing services according to a time-limitation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/51—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for resellers, retailers or service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/68—Payment of value-added services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0116—Provision for limiting expenditure, e.g. limit on call expenses or account
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0176—Billing arrangements using internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0196—Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/54—Resellers-retail or service providers billing, e.g. agreements with telephone service operator, activation, charging/recharging of accounts

Definitions

  • the present invention relates to a method and a device for making payments in a data network and in particular for making payments through an internet Protocol
  • IP IP based network
  • the Internet such as the Internet
  • a credit card enables its owner to make purchases and pay for them later, when an invoice is received.
  • the cost per transaction is relatively high using such cards. Therefore, such cards are not suitable for transactions involving small amounts of monev.
  • a cash card For small amounts of money, a cash card may be used. An amount of money is stored in the card which may then be used to pay for small purchases. Since this card is equal to the amount of money stored in it it is only feasible for small amounts of money. Often, there is a limit to the amount of money that can be stored in the card at any given time. Losing the card means losing the corresponding amount of money, and no interest is given on the money stored in the card. Also, when the card is empty, it has to be reloaded with money in type of terminal which is only available in certain places. The cash card also cannot handle user-specific information such as discounts to which a user mav be entitled.
  • a charging method in a data network through which goods and/or services can be purchased comprising the following steps:
  • transaction server in the network, said transaction server being adapted to receive and store information related to the use of each application program
  • the object is also achieved in a device for enabling charging in a data network said data network comprising at least one application program the use of which incurs costs for the user, said device comprising
  • This method and device allow a connection to be setup for a period of time during which billing information may be transmitted several times at regular or irregular intervals. In this way, the cost associated with the initial establishment of the connection, user authentication etc. does not occur every time a cost is to be registered. This enables the registration of low costs without high surcharges being added. At the same time, very high costs can also be registered.
  • One charging unit may be transmitted for each time unit, the duration of a time unit being individually selectable for each type of service or item, or a number of charging units may be transmitted at one time for one particular service or item. In this way the use of any program may be charged. It is also easy to change the price of using a program.
  • a contract may be specified for each transaction, said contract specifying parame- ters pertaining to the transaction, including identification of the buyer, seller and type of service or item being purchased, and price, and storing said contract in or in connection to the transaction server.
  • the contract may also comprise a maximum price for the session, defined by the user.
  • the cost for each session is calculated in terms of a valid currency and information about the cost is transferred to a billing unit.
  • FIG. 1 is a schematic overview of the invention
  • FIG. 2 is a more detailed representation of the units comprised in the invention.
  • Figure 3 shows the signalling that takes place between the user and the components of the system
  • Figure 5 is a flow charts of the steps taken to provide a service in the network.
  • FIG. 1 is a schematic overview of the components of a system comprising a transaction server 1 according to the invention.
  • the transaction server 1 is used to moni- tor the use of the services and/or the purchases made.
  • a first 3 and a second 5 application are connected through a first 7 and a second 9 application program interface (API), respectively.
  • the applications 3,5 may be connected either directly to the transaction server 1 through the API, such as the first application 3, or through a data network 11.
  • the Internet may be used as the data networks 11.
  • a database 13 is found in or in connection to the transaction server for storing user data and other information.
  • the transaction server 1 is also connected to one or more charging units 15 handling the actual payments from clients.
  • a number of customer terminals 17, 18 are also connected to the data network 11.
  • Terminals 19 may also be connected directly to one or more applications 5.
  • the customer terminals 17, 18, 19 may be private terminals found in people's homes such as personal computers or public terminals.
  • a security unit 21 for handling the security of the transactions is also found in or in connection to the transaction server.
  • Any type of application 3, 5 may be connected to the transaction server 1. as will be discussed in more detail below.
  • a customer can, for example order goods from a catalogue, make a call through the Internet telephony network, or retrieve informa- tion or programs from the Internet 11.
  • the public teiminals may be used, for example, for making payments in a shop, a gas station or the like. The charging for these different types of applications will be described in more detail below.
  • the transaction server 1 and the units it comprises will be described in more detail in connection with Fisure 2.
  • the charging principle according to the invention involves a charge unit called a tick.
  • the charge unit, or tick may be chosen independently for each application as an appropriate value for the apphcation.
  • the appli- cation program 3, 5 sends a number of ticks through the API 7, 9 to the transaction server 1.
  • one tick may be sent for each time unit.
  • the duration of the time unit may vary, for example at different times or for the type of call made. Typically, a shorter time unit will be used for long distance calls than for local calls so that the ticks will be sent more often for long dis- tance calls.
  • ticks may be sent at one time. For example, if a customer orders an item from a catalogue, the value of the tick may be 10 pence. If the price of the item is 10 pounds, 100 ticks will then be sent from the apphcation to the transaction server. To pay for power or water consumption, a number of ticks may be sent for each unit (watt, or volume of water).
  • One or more ticks may be sent to the transaction server when a customer starts an application, for example, if the customer is to pay for each time the application is used, or when the customer stops using an apphcation.
  • the transaction server 1, or the database 13 holds information about the value of a tick for each apphcation.
  • the transaction server 1 or the database 13 may also hold other user information, for example if a customer is entitled to a discount when using a particular apphcation.
  • FIG. 2 shows the units of the system according to a first embodiment of the system in more detail.
  • a transaction server 101 comprising a transaction manager, a database 105, and one or more servers 107 connected to an Internet service provider 109.
  • the Internet service provider 109 provides the transaction service to content providers (not shown). Of course, the service provider 109 may also be a content provider.
  • the server 107 handles communication with the In- temet service provider 109, mcluding retrieval of service programs, updating of the billing system, or protocol translation services.
  • the transaction manager 103 stores the logic as possible, to make the handling of the apphcation programs easier. For example, to keep the applications small and easy to manage, the charging information is placed in the transaction manager 103 instead of in the apphcation program itself.
  • the transaction manager 103 also establishes the communication with the other units.
  • the database 105 is used to store information about charging, vendors, customers, etc. Each service has an entry in the database specifying the price of the service in terms of ticks, and the value of a tick for the service concerned. Customer information comprised in the database 105 may include, for example, information about any discounts to which the customer is entitled, and a maximum amount that the customer is allowed to spend.
  • the transaction server 101 also comprises a payment manager 113.
  • the payment manager 113 takes care of the communication with units handling the payment from the customers, represented by a billing unit 115 in Figure 2.
  • a billing unit 115 in Figure 2.
  • Several such billing units 115 of different kinds, such as banks and/or a credit card companies may be included.
  • the transaction manager 103 is also connected to a first 117 and a second 119 ap- plication programs through a first 121 and a second 123 API, respectively.
  • the connection may be direct or through a data network.
  • the procedure for providing an apphcation program to the network will be discussed below.
  • the API can be linked to any application that requires charging. The API should not interfere with what is being charged or how much, but simply register ticks, as described above.
  • the API may also be adapted to send a receipt back to the content providers that their service is being used.
  • a web browser 127 is available to the customers of the system for ordering services and goods provided through the Internet.
  • the browser 127 may be connected to the billing unit 115, so that the browser can initiate advance payment if required.
  • the billing unit 115, the payment manager 113, the transaction manager 103 and the Internet service provider 109 are connected to one or more certification authority 129.
  • the certification authority 129 issues user identities and can therefore verify a particular user identity when required.
  • FIG 3 is an overview of the signalling that takes place between the customer and the units of the system according to a first embodiment of the invention.
  • the customer and each of the units are represented by horizontal lines, between which arrows are drawn to represent the signalling.
  • the units are: the apphcation APPL.
  • the APL an authentication module AUTH, the transaction server TS and the database DB.
  • the authentication module may be implemented as part of the API, but are shown here as a separate set of functions. In this way any available product for handling authentication functions may be used.
  • the authentication module, and other security functions will be described in more detail below.
  • S31 A customer first initiates the start of an application. If an item is to be ordered, or a call is to be made, through the Internet, this is done, according to a preferred embodiment, by opening an appropriate Internet site, or page, and ordering a service in the way known in the art. If a payment is to be made, for example, in a store or at a gas station, this is done by the customer identifying himself/herself and beginning the purchase .
  • S32 A signal is sent from the application to the API, comprising start information such as the application identity, information about the customer and a request for information about the cost per tick.
  • S33 The API sets up a session to the transaction server, for example according to the Secure Socket Layer (SSL) protocol.
  • SSL Secure Socket Layer
  • S34 The transaction server requests information from the database, for example, information about the customer and about cost per tick the apphcation.
  • S35 The database returns the requested information to the transaction server.
  • S36 The transaction server returns status information about the session, including, for example, the cost per tick and a customer contract, which will be described in more detail below.
  • S37 The API requests an authentication of the customer.
  • S38 The authentication module initiates a dialogue with the customer, mcluding a prompt for identification. The identification may be carried out in any way known in the ar as discussed in connection with the security functions. Other information regarding the transaction may also be entered, such as type of service or goods desired, maximum cost, and so on.
  • S39 The user enters the above mentioned information, which is transferred to the authentication module.
  • S40 The authentication module returns the signed user contract and a certificate verifying that the customer has been accepted, to the APL
  • S41 The API sends the signed user contract and the certificate to the transaction server.
  • S42 The transaction server starts a session and sends information to the database for a given customer and application.
  • S43 The transaction server verifies the status of the signed customer contract and the certificate and transmits a notification of acceptance to the API.
  • the application starts. This may imply, for example, that a program or a document is downloaded to the customer, that an order for an object from a catalogue is registered.
  • S45 The apphcation transmits ticks to the API when required. The first tick may be transmitted when the application starts, or at a later stage.
  • S46 The API forwards the ticks to the transaction server.
  • S45-S47 may be repeated an arbitrary number of times.
  • S49 A message, possibly with one or more ticks is transmitted from the API to the transaction server.
  • S50 The stop, and the final ticks, are also registered in the database.
  • a number of ticks may be sent in one burst at the end of the transaction.
  • a number of ticks may be sent for each litre of gas.
  • a corifirmation is sent from the program manager to the API and from the .API to the apphcation.
  • the user contract specifies the data that is to be valid for the transaction.
  • the user identity and the apphcation are specified.
  • the cost is specified, for example, m terms of the cost of one tick and the time interval between the ticks, the cost per time period or the total cost.
  • the user may also be allowed to specify a maximum cost.
  • the user contract may be stored with the user and is always stored in or in connection to the transaction server. Other data, such as the method of identification of the user may be specified as well. In this way, any transaction can be verified at a later stage if necessary.
  • Figure 4 shows the signalling that takes place according to a second embodiment of the invention, in which all ticks are transmitted at one time to the database. For ex- ample, when a web server is involved in the session, this may be more secure than having a connection for a longer period of time. The authentication and the negotiation of the contract may be carried out in the same way as in Figure 3 and are therefore not shown in Figure 4.
  • the apphcation sends a signal to the APL comprising information about the customer, about the apphcation and about the number of ticks to be transmitted.
  • S63 The API forwards the apphcation and customer information to the transaction server.
  • S64 The transaction server returns status information about the session.
  • S65 The API sends a signed user contract, if applicable, customer data and a number of ticks to the transaction server.
  • S66 The transaction server stores information about the new session in the database.
  • S67 The transaction server sends application and customer information to the database.
  • S68 The transaction server stores the appropriate number of ticks in the database.
  • the transaction server sends status information to the .API.
  • the user authentication may be carried out in a number of different ways, using passwords, smart cards, soft cards, voice recognition or in any other way known in the art.
  • the security functions may be implemented as an integral part of the API, but it may also be desirable to add the authentication functions as a separate package. In this way each content provider can choose authentication functions that fit the application in question. Of course the security functions may be omitted altogether, for example in a network to which the access is limited.
  • information transmitted between the user and the apphcation, and be- tween the units is encrypted. This may be done using an appropriate prior art encryption method in dependence of the required security level.
  • a common method for encryption of the information between the customer and the application is to use a private encryption key, specific to the customer, in combination with a public encryption key.
  • the charging data When the charging data has been stored in the database, they may be transferred to one of the billing units, which will make sure payment is received from the customer. This may be carried out in any way known in the art. For example, a customer may have an account to which money is paid in advance, or the customer may be invoiced at fixed time intervals or when the amount to be charged reaches a certain limit.
  • Figure 5 is a flow chart of the steps needed to provide an apphcation in the system.
  • Step S I The apphcation program is designed. The design of the application program is dependent of the type of application, as will be discussed below.
  • Step S2 The API is retrieved and linked to the application.
  • Step S3 The cost for using the application is specified and stored in the database. The cost is specified in terms of a cost for each tick and a number of ticks per time unit or item.
  • Step S4 The program is made available in the network. This may mean, for example, storing it on a web server or delivering the program to customers for installation on their computers.
  • the design of the application program and of the API will depend on the type of apphcation. If goods are to be ordered from a catalogue, information about the items and their price should be provided to the customer, preferably in a web page, which should also enable the customer to submit information to the transaction server through the API. This information should include customer identification, identifi- cation of the items to be purchased. Alternatively, the information about the items may be provided in a printed catalogue, in which case the web site need only comprise functions for sub ⁇ titting identification and specification of the desired items.
  • the consumption must be measured in some known way, and information about this transmitted to the transaction server.
  • the information may be transmitted as a number of ticks when a certain amount has been consumed or at certain time intervals.

Abstract

A charging method for goods and services provided by application programs through a data network is suggested, comprising the following steps: specifying the cost for using each application program in terms of charging units; providing a transaction server adapted to receive and store information related to the use of each application program; providing an application program interface between each application program and the transaction server, adapted to transfer information regarding the cost of each application, in terms of charging units, from the application program to the transaction server. A device for carrying out the method is disclosed, comprising means for receiving and storing information about the cost to be registered for a customer for using an application, said information being received in the form of charging units; means for calculating the cost of said session in terms of a valid currency.

Description

Method and Device in a Computer Network
Technical Field
The present invention relates to a method and a device for making payments in a data network and in particular for making payments through an internet Protocol
(IP) based network such as the Internet.
Description of Related Art
Credit cards and other types of pay cards are being used to an increasing degree.
A credit card enables its owner to make purchases and pay for them later, when an invoice is received. The cost per transaction is relatively high using such cards. Therefore, such cards are not suitable for transactions involving small amounts of monev.
For small amounts of money, a cash card may be used. An amount of money is stored in the card which may then be used to pay for small purchases. Since this card is equal to the amount of money stored in it it is only feasible for small amounts of money. Often, there is a limit to the amount of money that can be stored in the card at any given time. Losing the card means losing the corresponding amount of money, and no interest is given on the money stored in the card. Also, when the card is empty, it has to be reloaded with money in type of terminal which is only available in certain places. The cash card also cannot handle user-specific information such as discounts to which a user mav be entitled.
This means that a person using these services must use a number of different cards, and pay in a number of different ways for different services. Summary of the Invention
It is an object of the present invention to provide a method and an apparatus that will allow all kinds of transactions involving payment.
This is achieved according to the invention by a charging method in a data network through which goods and/or services can be purchased, said method comprising the following steps:
- providing a application program for each application, said application programs being located in nodes in the network; - specifying the cost for using each application program in terms of charging units:
- providing a transaction server in the network, said transaction server being adapted to receive and store information related to the use of each application program;
- providing an application program interface between each application program and the transaction server, said application program interface being adapted to transfer information regarding the cost of each application, in terms of charging units, from the application program to the transaction server.
The object is also achieved in a device for enabling charging in a data network said data network comprising at least one application program the use of which incurs costs for the user, said device comprising
- memory means holding information about customers, and cost of using said application program;
- means for receiving and storing information about the cost to be registered for a customer for a session in which the customer uses an application, said information being received in the form of charging units;
- means for storing said information.
- means for calculating the cost of said session in terms of a valid currency. This method and device allow a connection to be setup for a period of time during which billing information may be transmitted several times at regular or irregular intervals. In this way, the cost associated with the initial establishment of the connection, user authentication etc. does not occur every time a cost is to be registered. This enables the registration of low costs without high surcharges being added. At the same time, very high costs can also be registered.
One charging unit may be transmitted for each time unit, the duration of a time unit being individually selectable for each type of service or item, or a number of charging units may be transmitted at one time for one particular service or item. In this way the use of any program may be charged. It is also easy to change the price of using a program.
A contract may be specified for each transaction, said contract specifying parame- ters pertaining to the transaction, including identification of the buyer, seller and type of service or item being purchased, and price, and storing said contract in or in connection to the transaction server. The contract may also comprise a maximum price for the session, defined by the user.
The cost for each session is calculated in terms of a valid currency and information about the cost is transferred to a billing unit.
Brief Description of the Drawings
In the following the invention will be described in more detail with reference to the drawings, in which:
Figure 1 is a schematic overview of the invention;
Figure 2 is a more detailed representation of the units comprised in the invention;
Figure 3 shows the signalling that takes place between the user and the components of the system; Figure 5 is a flow charts of the steps taken to provide a service in the network. Detailed Description of Embodiments
Figure 1 is a schematic overview of the components of a system comprising a transaction server 1 according to the invention. The transaction server 1 is used to moni- tor the use of the services and/or the purchases made. To the transaction server 1 a first 3 and a second 5 application are connected through a first 7 and a second 9 application program interface (API), respectively. The applications 3,5 may be connected either directly to the transaction server 1 through the API, such as the first application 3, or through a data network 11. In a preferred embodiment, the Internet may be used as the data networks 11. A database 13 is found in or in connection to the transaction server for storing user data and other information. The transaction server 1 is also connected to one or more charging units 15 handling the actual payments from clients. A number of customer terminals 17, 18 are also connected to the data network 11. Terminals 19 may also be connected directly to one or more applications 5. The customer terminals 17, 18, 19 may be private terminals found in people's homes such as personal computers or public terminals. A security unit 21 for handling the security of the transactions is also found in or in connection to the transaction server.
Any type of application 3, 5 may be connected to the transaction server 1. as will be discussed in more detail below.
From his/her private terminal 17 a customer can, for example order goods from a catalogue, make a call through the Internet telephony network, or retrieve informa- tion or programs from the Internet 11. The public teiminals may be used, for example, for making payments in a shop, a gas station or the like. The charging for these different types of applications will be described in more detail below.
The transaction server 1 and the units it comprises will be described in more detail in connection with Fisure 2. The charging principle according to the invention involves a charge unit called a tick. The charge unit, or tick, may be chosen independently for each application as an appropriate value for the apphcation. When a customer uses a service, the appli- cation program 3, 5 sends a number of ticks through the API 7, 9 to the transaction server 1. For some services, for example telephony, one tick may be sent for each time unit. The duration of the time unit may vary, for example at different times or for the type of call made. Typically, a shorter time unit will be used for long distance calls than for local calls so that the ticks will be sent more often for long dis- tance calls. For other applications a number of ticks may be sent at one time. For example, if a customer orders an item from a catalogue, the value of the tick may be 10 pence. If the price of the item is 10 pounds, 100 ticks will then be sent from the apphcation to the transaction server. To pay for power or water consumption, a number of ticks may be sent for each unit (watt, or volume of water).
One or more ticks may be sent to the transaction server when a customer starts an application, for example, if the customer is to pay for each time the application is used, or when the customer stops using an apphcation.
The transaction server 1, or the database 13 holds information about the value of a tick for each apphcation. The transaction server 1 or the database 13 may also hold other user information, for example if a customer is entitled to a discount when using a particular apphcation.
Figure 2 shows the units of the system according to a first embodiment of the system in more detail. As before, a transaction server 101 is provided, comprising a transaction manager, a database 105, and one or more servers 107 connected to an Internet service provider 109. The Internet service provider 109 provides the transaction service to content providers (not shown). Of course, the service provider 109 may also be a content provider. The server 107 handles communication with the In- temet service provider 109, mcluding retrieval of service programs, updating of the billing system, or protocol translation services.
According to a preferred embodiment as much of the logic as possible is stored in the transaction manager 103, to make the handling of the apphcation programs easier. For example, to keep the applications small and easy to manage, the charging information is placed in the transaction manager 103 instead of in the apphcation program itself. The transaction manager 103 also establishes the communication with the other units.
The database 105 is used to store information about charging, vendors, customers, etc. Each service has an entry in the database specifying the price of the service in terms of ticks, and the value of a tick for the service concerned. Customer information comprised in the database 105 may include, for example, information about any discounts to which the customer is entitled, and a maximum amount that the customer is allowed to spend.
The transaction server 101 also comprises a payment manager 113. The payment manager 113 takes care of the communication with units handling the payment from the customers, represented by a billing unit 115 in Figure 2. Several such billing units 115 of different kinds, such as banks and/or a credit card companies may be included.
The transaction manager 103 is also connected to a first 117 and a second 119 ap- plication programs through a first 121 and a second 123 API, respectively. As shown in Figure 1, the connection may be direct or through a data network. The procedure for providing an apphcation program to the network will be discussed below. The API can be linked to any application that requires charging. The API should not interfere with what is being charged or how much, but simply register ticks, as described above. The API may also be adapted to send a receipt back to the content providers that their service is being used.
A web browser 127 is available to the customers of the system for ordering services and goods provided through the Internet. The browser 127 may be connected to the billing unit 115, so that the browser can initiate advance payment if required.
The billing unit 115, the payment manager 113, the transaction manager 103 and the Internet service provider 109 are connected to one or more certification authority 129. The certification authority 129 issues user identities and can therefore verify a particular user identity when required.
Figure 3 is an overview of the signalling that takes place between the customer and the units of the system according to a first embodiment of the invention. The customer and each of the units are represented by horizontal lines, between which arrows are drawn to represent the signalling. The units are: the apphcation APPL. the APL an authentication module AUTH, the transaction server TS and the database DB. The authentication module may be implemented as part of the API, but are shown here as a separate set of functions. In this way any available product for handling authentication functions may be used. The authentication module, and other security functions will be described in more detail below.
S31: A customer first initiates the start of an application. If an item is to be ordered, or a call is to be made, through the Internet, this is done, according to a preferred embodiment, by opening an appropriate Internet site, or page, and ordering a service in the way known in the art. If a payment is to be made, for example, in a store or at a gas station, this is done by the customer identifying himself/herself and beginning the purchase . S32: A signal is sent from the application to the API, comprising start information such as the application identity, information about the customer and a request for information about the cost per tick. S33: The API sets up a session to the transaction server, for example according to the Secure Socket Layer (SSL) protocol.
S34: The transaction server requests information from the database, for example, information about the customer and about cost per tick the apphcation. S35: The database returns the requested information to the transaction server. S36: The transaction server returns status information about the session, including, for example, the cost per tick and a customer contract, which will be described in more detail below. S37: The API requests an authentication of the customer. S38: The authentication module initiates a dialogue with the customer, mcluding a prompt for identification. The identification may be carried out in any way known in the ar as discussed in connection with the security functions. Other information regarding the transaction may also be entered, such as type of service or goods desired, maximum cost, and so on. S39: The user enters the above mentioned information, which is transferred to the authentication module. S40: The authentication module returns the signed user contract and a certificate verifying that the customer has been accepted, to the APL S41: The API sends the signed user contract and the certificate to the transaction server. S42: The transaction server starts a session and sends information to the database for a given customer and application.
S43: The transaction server verifies the status of the signed customer contract and the certificate and transmits a notification of acceptance to the API. S44: The PI forwards the notification of acceptance to the apphcation.
The application starts. This may imply, for example, that a program or a document is downloaded to the customer, that an order for an object from a catalogue is registered. S45: The apphcation transmits ticks to the API when required. The first tick may be transmitted when the application starts, or at a later stage. S46: The API forwards the ticks to the transaction server.
S47: The transaction server inserts ticks for the session in question in the database.
This may be done once or several times at regular or irregular intervals. S45-S47 may be repeated an arbitrary number of times.
S48: When the application is ended, a stop signal is sent from the apphcation to the API.
S49: A message, possibly with one or more ticks is transmitted from the API to the transaction server. S50: The stop, and the final ticks, are also registered in the database. S51: The transaction server verifies to the API that the session has ended. S52: The API verifies to the apphcation that the session has ended.
For some applications, for example when making a payment in a store, a number of ticks, corresponding to the amount to be paid, may be sent in one burst at the end of the transaction. For other applications, for example when tanking, a number of ticks may be sent for each litre of gas.
A corifirmation is sent from the program manager to the API and from the .API to the apphcation.
In the above only signals relevant for illustrating the inventive idea have been included. Of course, other signals such as synchronization signals, may have to be transmitted at certain stages.
The user contract specifies the data that is to be valid for the transaction. The user identity and the apphcation are specified. The cost is specified, for example, m terms of the cost of one tick and the time interval between the ticks, the cost per time period or the total cost. The user may also be allowed to specify a maximum cost. The user contract may be stored with the user and is always stored in or in connection to the transaction server. Other data, such as the method of identification of the user may be specified as well. In this way, any transaction can be verified at a later stage if necessary.
Figure 4 shows the signalling that takes place according to a second embodiment of the invention, in which all ticks are transmitted at one time to the database. For ex- ample, when a web server is involved in the session, this may be more secure than having a connection for a longer period of time. The authentication and the negotiation of the contract may be carried out in the same way as in Figure 3 and are therefore not shown in Figure 4.
S62: The apphcation sends a signal to the APL comprising information about the customer, about the apphcation and about the number of ticks to be transmitted.
S63 : The API forwards the apphcation and customer information to the transaction server. S64: The transaction server returns status information about the session.
S65: The API sends a signed user contract, if applicable, customer data and a number of ticks to the transaction server.
S66: The transaction server stores information about the new session in the database. S67: The transaction server sends application and customer information to the database.
S68: The transaction server stores the appropriate number of ticks in the database.
S69: The transaction server ends the session in the database.
S70: The transaction server sends status information to the .API. As mentioned above, the user authentication may be carried out in a number of different ways, using passwords, smart cards, soft cards, voice recognition or in any other way known in the art. The security functions may be implemented as an integral part of the API, but it may also be desirable to add the authentication functions as a separate package. In this way each content provider can choose authentication functions that fit the application in question. Of course the security functions may be omitted altogether, for example in a network to which the access is limited.
For security, information transmitted between the user and the apphcation, and be- tween the units, is encrypted. This may be done using an appropriate prior art encryption method in dependence of the required security level. A common method for encryption of the information between the customer and the application is to use a private encryption key, specific to the customer, in combination with a public encryption key.
When the charging data has been stored in the database, they may be transferred to one of the billing units, which will make sure payment is received from the customer. This may be carried out in any way known in the art. For example, a customer may have an account to which money is paid in advance, or the customer may be invoiced at fixed time intervals or when the amount to be charged reaches a certain limit.
Figure 5 is a flow chart of the steps needed to provide an apphcation in the system.
Step S I: The apphcation program is designed. The design of the application program is dependent of the type of application, as will be discussed below. Step S2: The API is retrieved and linked to the application. Step S3 : The cost for using the application is specified and stored in the database. The cost is specified in terms of a cost for each tick and a number of ticks per time unit or item. Step S4: The program is made available in the network. This may mean, for example, storing it on a web server or delivering the program to customers for installation on their computers.
The design of the application program and of the API will depend on the type of apphcation. If goods are to be ordered from a catalogue, information about the items and their price should be provided to the customer, preferably in a web page, which should also enable the customer to submit information to the transaction server through the API. This information should include customer identification, identifi- cation of the items to be purchased. Alternatively, the information about the items may be provided in a printed catalogue, in which case the web site need only comprise functions for subπtitting identification and specification of the desired items.
It is also possible, according to the invention to include payment for, for example electric power or water consumption. In this case, the consumption must be measured in some known way, and information about this transmitted to the transaction server. The information may be transmitted as a number of ticks when a certain amount has been consumed or at certain time intervals.

Claims

Claims
1. A charging method in a data network through which goods and/or services can be purchased said method comprising the following steps: - providing an apphcation program (3, 5) for each apphcation, said application programs being located in nodes in the network;
- specifying the cost for using each apphcation program in terms of charging units;
- providing a transaction server (1; 101) in the network, said transaction server being adapted to receive and store information related to the use of each applica- tion program (3, 5);
- providing an apphcation program interface (7, 9) between each apphcation program (3, 5) and the transaction server (1; 101), said apphcation program interface (7,9 )being adapted to transfer information regarding the cost of each apphcation, in terms of charging units, from the apphcation program to the transaction server.
2. A method according to claim 1, characterized by transnhtting one charging unit for each time unit the duration of a time unit being individually selectable for each type of service or item
3. A method according to claim 1 or 2, characterized by transrmtting a number of charging units for one particular service or item.
4. A method according to anv one of claims 1-3, characterized bv transrnittins the value of a charging unit from the transaction server to the application at the start of a session.
5. A method according to any one of the preceding claims, characterized by specifying a contract for each transaction said contract specifying parameters pertaining to the transaction, including identification of the buyer, seller and type of service or item being purchased, and price, and storing said contract in or in connection to the transaction server.
6. A method according to any one of the preceding claims, characterized by allow- ing a customer to specify a maximum price for the use of an apphcation.
7. A method according to claim 6, characterized by including said maximum price in the contract.
8. A method according to any one of the preceding claims, characterized by the steps of
- calculating the cost for each session in terms of a valid currency;
- transferring information about the cost to a billing unit (127).
9. A device (1; 101) for enabling charging in a data network said data network comprising at least one application program (3, 5) the use of which incurs costs for the user, said device comprising
- memory means ('13; 105) holding information about customers, and cost of using said apphcation program (3, 5); - means (103) for receiving and storing information about the cost to be registered for a customer for a session in which the customer uses an apphcation. said information being received in the form of charging units;
- storage means (13; 105) for storing said information.
- means (103) for calculating the cost of said session in terms of a valid currency
10. A device according to claim 9. characterized in that it comprises means (103) for negotiating a contract with a customer and storing the resulting contract in a database.
11. A device according to claim 9 or 10, characterized in that it comprises storage means (13; 105) for storing customer-specific information and means for adjusting the price according to this information, e.g. give discounts.
12. A data network characterized in that it comprises:
- at least one device (1; 101) according to any one of the claims 9-11;
- an API (7, 9) for transferring information between an application program (5, 7) and said device (1; 101).
PCT/SE1999/000706 1998-04-30 1999-04-29 Charging in a computer network WO1999057662A2 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
IL13917999A IL139179A0 (en) 1998-04-30 1999-04-29 Method and device in a computer network
KR1020007012008A KR20010043117A (en) 1998-04-30 1999-04-29 Method and device in a computer network
AU44024/99A AU4402499A (en) 1998-04-30 1999-04-29 Method and device in a computer network
CA002329769A CA2329769A1 (en) 1998-04-30 1999-04-29 Method and device in a computer network
EP99927025A EP1073983A2 (en) 1998-04-30 1999-04-29 Method and device in a computer network
JP2000547566A JP2002513973A (en) 1998-04-30 1999-04-29 Computer network method and apparatus
BR9910076-2A BR9910076A (en) 1998-04-30 1999-04-29 Method and device on a computer network
IS5682A IS5682A (en) 1998-04-30 2000-10-25 Method and tools on computer networks
NO20005468A NO20005468L (en) 1998-04-30 2000-10-30 Charging for services in computer networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9801525A SE514332C2 (en) 1998-04-30 1998-04-30 Procedure and apparatus for payment in a computer network
SE9801525-8 1998-04-30

Publications (2)

Publication Number Publication Date
WO1999057662A2 true WO1999057662A2 (en) 1999-11-11
WO1999057662A3 WO1999057662A3 (en) 1999-12-29

Family

ID=20411153

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE1999/000706 WO1999057662A2 (en) 1998-04-30 1999-04-29 Charging in a computer network

Country Status (13)

Country Link
EP (1) EP1073983A2 (en)
JP (1) JP2002513973A (en)
KR (1) KR20010043117A (en)
CN (1) CN1315021A (en)
AU (1) AU4402499A (en)
BR (1) BR9910076A (en)
CA (1) CA2329769A1 (en)
IL (1) IL139179A0 (en)
IS (1) IS5682A (en)
NO (1) NO20005468L (en)
SE (1) SE514332C2 (en)
WO (1) WO1999057662A2 (en)
ZA (1) ZA200005846B (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1308911A2 (en) * 2001-11-01 2003-05-07 Pioneer Corporation Charging server and charging method
US6615137B2 (en) 2001-06-26 2003-09-02 Medius, Inc. Method and apparatus for transferring information between vehicles
US6629033B2 (en) 2001-04-24 2003-09-30 Medius, Inc. Open communication system for real-time multiprocessor applications
WO2003100688A1 (en) * 2002-05-24 2003-12-04 Medius, Inc. Method and apparatus for monitoring packet based communications in a mobile environment
US6771208B2 (en) 2002-04-24 2004-08-03 Medius, Inc. Multi-sensor system
US6778073B2 (en) 2001-06-26 2004-08-17 Medius, Inc. Method and apparatus for managing audio devices
US6792351B2 (en) 2001-06-26 2004-09-14 Medius, Inc. Method and apparatus for multi-vehicle communication
US7146260B2 (en) 2001-04-24 2006-12-05 Medius, Inc. Method and apparatus for dynamic configuration of multiprocessor system
US7178049B2 (en) 2002-04-24 2007-02-13 Medius, Inc. Method for multi-tasking multiple Java virtual machines in a secure environment
US9358924B1 (en) 2009-05-08 2016-06-07 Eagle Harbor Holdings, Llc System and method for modeling advanced automotive safety systems
US10298735B2 (en) 2001-04-24 2019-05-21 Northwater Intellectual Property Fund L.P. 2 Method and apparatus for dynamic configuration of a multiprocessor health data system
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
US7337650B1 (en) 2004-11-09 2008-03-04 Medius Inc. System and method for aligning sensors on a vehicle

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995034857A1 (en) * 1994-06-14 1995-12-21 Smith James P Apparatus and method for controlling the registration, paid licensing and metered usage of software products
EP0708547A2 (en) * 1994-09-22 1996-04-24 AT&T Corp. Cellular telephone as an authenticated transaction controller
US5592376A (en) * 1994-06-17 1997-01-07 Commonweal Incorporated Currency and barter exchange debit card and system
WO1997030543A1 (en) * 1996-02-19 1997-08-21 Telecom Finland Oy Method to arrange a payment service in a telecommunications network
WO1997040615A2 (en) * 1996-04-22 1997-10-30 At & T Corp. Method for billing for transactions over the internet

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995034857A1 (en) * 1994-06-14 1995-12-21 Smith James P Apparatus and method for controlling the registration, paid licensing and metered usage of software products
US5592376A (en) * 1994-06-17 1997-01-07 Commonweal Incorporated Currency and barter exchange debit card and system
EP0708547A2 (en) * 1994-09-22 1996-04-24 AT&T Corp. Cellular telephone as an authenticated transaction controller
WO1997030543A1 (en) * 1996-02-19 1997-08-21 Telecom Finland Oy Method to arrange a payment service in a telecommunications network
WO1997040615A2 (en) * 1996-04-22 1997-10-30 At & T Corp. Method for billing for transactions over the internet

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US10298735B2 (en) 2001-04-24 2019-05-21 Northwater Intellectual Property Fund L.P. 2 Method and apparatus for dynamic configuration of a multiprocessor health data system
US8583292B2 (en) 2001-04-24 2013-11-12 Eagle Harbor Holdings, Llc System and method for restricting access to vehicle software systems
US11042385B2 (en) 2001-04-24 2021-06-22 Micropairing Technologies Llc. Method and system for dynamic configuration of multiprocessor system
US9811354B2 (en) 2001-04-24 2017-11-07 Eagle Harbor Holdings, Llc Home audio system for operating different types of audio sources
US10387166B2 (en) 2001-04-24 2019-08-20 Northwater Intellectual Property Fund L.P. 2 Dynamic configuration of a multiprocessor system
US9697015B2 (en) 2001-04-24 2017-07-04 Eagle Harbor Holdings, Llc Vehicle audio application management system using logic circuitry
US6629033B2 (en) 2001-04-24 2003-09-30 Medius, Inc. Open communication system for real-time multiprocessor applications
US9652257B2 (en) 2001-04-24 2017-05-16 Eagle Harbor Holdings, Llc Vehicle safety system
US9645832B2 (en) 2001-04-24 2017-05-09 Dan A. Preston Dynamic configuration of a home multiprocessor system
US10102013B2 (en) 2001-04-24 2018-10-16 Northwater Intellectual Property Fund, L.P. 2 Method and system for dynamic configuration of multiprocessor system
US7146260B2 (en) 2001-04-24 2006-12-05 Medius, Inc. Method and apparatus for dynamic configuration of multiprocessor system
US6615137B2 (en) 2001-06-26 2003-09-02 Medius, Inc. Method and apparatus for transferring information between vehicles
US6792351B2 (en) 2001-06-26 2004-09-14 Medius, Inc. Method and apparatus for multi-vehicle communication
US6778073B2 (en) 2001-06-26 2004-08-17 Medius, Inc. Method and apparatus for managing audio devices
EP1308911A2 (en) * 2001-11-01 2003-05-07 Pioneer Corporation Charging server and charging method
EP1308911A3 (en) * 2001-11-01 2004-06-02 Pioneer Corporation Charging server and charging method
US6771208B2 (en) 2002-04-24 2004-08-03 Medius, Inc. Multi-sensor system
US8020028B1 (en) 2002-04-24 2011-09-13 Eagle Harbor Holdings Application management system for mobile devices
US7178049B2 (en) 2002-04-24 2007-02-13 Medius, Inc. Method for multi-tasking multiple Java virtual machines in a secure environment
WO2003100688A1 (en) * 2002-05-24 2003-12-04 Medius, Inc. Method and apparatus for monitoring packet based communications in a mobile environment
US9358924B1 (en) 2009-05-08 2016-06-07 Eagle Harbor Holdings, Llc System and method for modeling advanced automotive safety systems

Also Published As

Publication number Publication date
CN1315021A (en) 2001-09-26
CA2329769A1 (en) 1999-11-11
JP2002513973A (en) 2002-05-14
SE514332C2 (en) 2001-02-12
EP1073983A2 (en) 2001-02-07
AU4402499A (en) 1999-11-23
KR20010043117A (en) 2001-05-25
SE9801525D0 (en) 1998-04-30
NO20005468L (en) 2000-12-27
BR9910076A (en) 2000-12-26
IS5682A (en) 2000-10-25
SE9801525L (en) 1999-10-31
WO1999057662A3 (en) 1999-12-29
NO20005468D0 (en) 2000-10-30
ZA200005846B (en) 2002-04-19
IL139179A0 (en) 2001-11-25

Similar Documents

Publication Publication Date Title
US20190347701A1 (en) Secure transaction protocol
USRE45241E1 (en) Parallel data network billing and collection system
JP4339514B2 (en) data communication
KR100506913B1 (en) Electronic payment system using anonymous representative payment means and method thereof
US7596530B1 (en) Method for internet payments for content
US20090198620A1 (en) Mobile commerce receipt system
US20020120587A1 (en) System and method for performing secure user account purchases
US6823318B1 (en) Secure purchases over a computer network
EP1073983A2 (en) Method and device in a computer network
AU2001266614A1 (en) Secure transaction protocol
WO2002017181A1 (en) Electronic payment methods
JP2001266043A (en) Internet accounting system
WO2002035487A2 (en) Remote payment method and system
HU220734B1 (en) Service widening unit and system for facilitating the ordering and paying of services by means of a communication network
CA2426376C (en) Method and system for facilitating a trusted on-line transaction between businesses and networked consumers
US7054835B2 (en) Electronic commerce providing system having orderer authenticating function
KR100367181B1 (en) A method for publishing, delivering and using a point exchange ticket in the computer network
KR100671542B1 (en) System and Method for prepaid card service management function
KR20010114061A (en) Settlement method for transactions between remote agents through escrow and thereof system
MXPA00010491A (en) Method and device in a computer network
JP2003132294A (en) Vicarious fee collecting system, vicarious collecting server, mobile terminal and vicarious fee collecting method
JP2002109265A (en) Net shopping system
KR20020000988A (en) Secure sanction transaction and payment system and method thereof via mobile phone
ITRM20000263A1 (en) SYSTEM AND MEDOTO FOR THE MANAGEMENT OF ELECTRONIC COMMENCIO TRANSACTIONS ON THE INTERNET.
KR20050012326A (en) System and Method for contents supply service management function using prepaid card

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99808204.X

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2000/05846

Country of ref document: ZA

Ref document number: 200005846

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 139179

Country of ref document: IL

ENP Entry into the national phase

Ref document number: 2329769

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: PA/a/2000/010491

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 1020007012008

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 1999927025

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: IN/PCT/2000/00626/MU

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 44024/99

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 1999927025

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1020007012008

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1999927025

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1020007012008

Country of ref document: KR