WO2003071464A1

WO2003071464A1 - Electronic micro payment system

Info

Publication number: WO2003071464A1
Application number: PCT/SE2003/000261
Authority: WO
Inventors: Maw-Tsong Lin
Original assignee: Tds Todos Data System Ab
Priority date: 2002-02-19
Filing date: 2003-02-18
Publication date: 2003-08-28
Also published as: SE0200490L; SE0200490D0; AU2003217091A1

Abstract

A method and system is disclosed for electronic payments for effecting purchase transactions through a communication network system, and especially so called micro-payments. The system involves a user, service provider and a fund manager, all being connected through the communication network. The method comprises: providing a user account by the fund manager dedicated to the user, transferring a user authentication token from the user to the fund manager; authenticating the user based on said authentication token, and in case of adequate authentication reserving a maximum purchase amount of the funds currently available on the user account for the service provider; effecting a purchase between the user and the service provider; and upon effected purchase transferring an amount for the purchase from said user account to the service provider, said amount being less or equal to the maximum purchase amount.

Description

ELECTRONIC MICRO PAYMENT SYSTEM

Field of the invention

The present invention relates to a method and system for electronic payments for effecting purchase transactions through a communication network system. The system involves a user, a service provider and a fund manager, all being connected through a communication network. The invention especially relates to purchases of small values, so called micro-payments.

Background of the invention

There has for a long time been a great demand on payment systems and methods through electronic communication systems, especially since the Internet was introduced. Particularly, there is a need for a method making it feasible with payments of quite small amounts, such as charges for accessing the information on certain web-pages or for downloading an music file. The solutions in the market are often too complicated and not cost efficient enough to make a break through in the market. Especially, what is still needed is a method of charging for accesses to information that is both sufficiently secure and fast and efficient to use.

For example, US 6 157 917 discloses a micro-payment method, where dynamic cookie-like objects are used. The objects are refilled or bought at an "issuer", and could then be used as an electronic wallet when accessing charged web-pages. However, this method is still relatively complicated to use, and the user has little or none control of the payments being made, which makes the system somewhat insecure.

WO 01/80100 discloses a relatively complex payment system where a continuous connection with the bank is required. This method is to complex to be used for micro- payments, where the need for security is less but the need for simplicity is greater.

WO 98/22915 discloses a method for payment of digital transactions, and particularly micro-payments. In this method, a set of tokens are stored in a payment server, and issued to a user upon payment. The tokens could thereafter be used for payment, whereby the tokens are "paid" to a service provider. However, this method is also relatively complicated to use, especially for the user, and with a low degree of control and security.

Accordingly, there is a need for an easier and/or more secure and user controllable electronic payment method, and especially for micro-payments.

Summary of the invention

It is therefore an object of the present invention to provide method and a system for electronic payment for effecting purchase transactions through a communication network system. This object is achieved with the invention as defined in the appended claims .

According to the invention, an electronic payment method for effecting purchase transactions through a communication network system is provided, said system involving a user, a service provider and a fund manager, all being connected through a communication network. The method comprises: providing a user account by the fund manager dedicated to the user; transferring a user authentication token from the user to the fund manager; authenticating the user based on said authentication token, and in case of adequate authentication reserving a maximum purchase amount of the funds currently available on the user account for the service provider; effecting a purchase between the user and the service provider; and upon effected purchase transferring an amount for the purchase from said user account to the service provider, said amount being less or equal to the maximum purchase amount .

The term authenticate is in this application used to indicate verification of a user identification and/or authorization for certain actions. The authentication could be based on a combination of user identification information, such as a user name, and an authentication token, such as a one time code. However, in case the user identification information is deducible in any other way, the authentication could be based solely on an authentication token. The method of the invention provides an easy- implemented and easy- aintain system, and offers the infrastructure for cost efficient and secure micro payment in the Internet . Particularly, the method makes it possible to reduce the financial risk to which user is exposed to a very low level, since at each purchase, the only possible loss is the remainder of the reserved Pmax amount. Further, the risk for the fund manager and the service provider could also be kept very low. At the same time, the system is very easy to use, both for the user, the service provider and the fund manager, requiring only a minimum of information flowing between the interacting parties. Still further, the method and system could be easily implemented, since already existing banking systems, authentication systems, information infrastructures and the like could be used to a large extent. The method of the invention could also be made very flexible and dynamic, and could thereby be adapted to suite a large variety of different customers, different type of services to be purchased, different purchase situations, etc. The user account is preferably dedicated to electronic payments. Hereby, the risks could be limited even further.

It is also preferred that the user account has a maximum total amount value indicating the maximum total amount allowed to be held by the account. This also reduces the risk exposure for the interacting parties.

In an advantageous embodiment, one or both of the maximum total amount value and the maximum purchase amount of the user account is user definable. Hereby, the flexibility of the system is greatly enhanced.

The transfer of the user authentication token from the user to the fund manager could be made through the service provider or directly to the fund manager. It is further preferred that, along with the user authentication token, user information data is transferred from the user to the fund manager to be used in the authentication.

Still further, it is preferred that service provider information is transferred from the service provider to the fund manager for identification of the service provider. Particularly, this renders it possible to transfer the amount for the purchase from said user account to a service provider account automatically. The purchase could comprise download of or access to data held by the service provider.

It is also possible that the purchase comprises at least two different purchase activities. These at least two different purchase activities could be timely separated.

In a preferred embodiment, the method further comprises presenting information regarding the purchase from at least one of the service provider and the fund manager to the user. This information could relate to at least one of the total balance of the user account, the amount reserved for the service provider, the size of the consumed and unconsumed part of the reserved amount and amounts that have been transferred to the service provider.

Still further, the method preferably comprises providing a possibility for the user to stop any further purchase at any time. This increases the controllability from the users point of view, and reduces the risks even further .

In an advantageous embodiment, the fund manager provides at least one further user account dedicated to the user, said further account not being usable for said purchase payment. Hereby, the risks are diminished even further, at the same time as transfer of money between the accounts could be made very simple. In case different accounts for the user are administered by the same fund manager, different authentication tokens are preferably usable for the different accounts, in order to reduce the risk exposure for the user.

According to still another preferred embodiment, the method further comprises transferring a further user authentication token from the user to the fund manager; and authenticating the user based on said further authentication token, and in case of adequate authentication reserving a further maximum purchase amount of the funds currently available on the user account for the service provider; wherein the step of transferring amount for the purchase from said user account to the service provider relates to all reserved maximum purchase amounts. Hereby, the Pmax amount is no restriction of the maximum amount the user could use for purchases from the service provider, and at the same time the risks are kept at a low level and there is a large degree of controllability for the user.

According to another aspect of the invention, it relates to a corresponding system for effecting purchase transactions. The system involves at least one user unit, at least one service provider unit and at least one fund manager unit, all units being connected through a communication network. The system comprises: an account database at the fund manager holding at least one user account dedicated to the at least one user; means for authentication of the user based on an authentication token input through the user unit; means for reserving a maximum purchase amount of the funds currently available on the user account for the service provider in case of adequate authentication of the user; means for effecting a purchase between the user and the service provider through the network; and means for transferring an amount for the purchase upon effected purchase from said user account to the service provider, said amount being less or equal to the maximum purchase amount .

The same advantages and features as discussed above with relation to the method also relates to the system.

Further scope of the applicability of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.

Brief description of the drawings

For exemplifying purposes, the invention will be described in closer detail in the following with reference to embodiments thereof illustrated in the attached drawings, wherein:

Fig 1 is a schematic system overview of a system according to an embodiment of the invention; Fig 2 is a schematic illustration of a user interface window according to an embodiment of the invention;

Fig 3 is a schematic flow chart illustrating an electronic payment method according to a first embodiment of the invention;

Fig 4 is a schematic flow chart illustrating an electronic payment method according to a second embodiment of the invention; and Fig 5 is a schematic flow chart illustrating an electronic payment method according to a third embodiment of the invention.

Description of preferred embodiments The invention will now be described more thoroughly by way of example.

With reference to fig 1, the invention generally relates to digital and electronic payment and purchase transactions in a digital communication system. The system comprises at least one user unit or input device

11-13, and preferably several input devices. The input device could be any device which provides a digital network interface for the user, such as a general purpose computer, a cellular telephone or the like. Further, the system comprises at least one service provider (on-line service provider, OSP) 21-23 for providing service over the communication network. The service provider could e.g. provide services such as access to certain information or to restricted web-pages, access to files for download, such as programs, music files, on-line games and the like, access to search operations, etc. The access granted to the user could either be a certain data amount, such as access to a file or a web-page, or be related to a certain time period during which access is possible. E.g. access to on-line games may be granted during a certain number of minutes, during a round of a game, or the like. Further, the system comprises one or several fund managers 31-33. The fund managers comprises a fund administration part for administering user accounts etc, and an authentication manager for authenticating users through the communication system. The fund manager could be arranged as a server on the network, and could either comprise an integrated unit or comprise several interconnected units. Further, each fund manager has access to at least one account or fund database 41-44. The fund managers could typically be administered by banks as a part of an ordinary Internet banking service. The fund manager or the payment clearing center, could administer accounts for hundreds or thousands of end users . The general setup of the service provider and the fund manager are known per se and will not be further discussed in this application. For example, the authentication part of the fund manager could be arranged as is described in WO 01/02325 of the same applicant, said document hereby incorporated by reference.

The system further comprises a digital network 5 connecting the input devices, the service providers and the fund managers. The digital network could be both wired or wireless, or a combination of the two. For example, the network could be a wide area network (WAN) , such as the Internet .

The payment method according to embodiments of the invention will now be described in more detail. In a first embodiment, as illustrated in fig 3, the user first connects to an on-line service provider OSP through the communication network, and requests a service to be purchased, step SI. Preferably, all services that could be provided by the service provider are clearly presented, e.g. on a web-page, and together with the prices for each service. Before the purchase is effectuated, the OSP prompts the user to indicate or select a fund manager to administrate and effectuate the payment, step S2. The fund manager could be indicated by entry of information making it possible for the OSP to identify the fund manager, such as a name, a specific code, a network address or the like. It is also possible for the OSP to present a list of possible fund managers, whereby the user could select one of the listed alternatives. The fund manager selected in this way should be a fund manager administering funds for the user on at least one account which is accessible for electronic purchase payment .

The OSP will thereafter, or simultaneously, ask for user identification information and an authentication token from the user. The format of the used identification and authentication token is determined by the type of authentication process used by the fund manager, and information about the required information and format of the information could preferably be forwarded to the OSP before the user entry.

The identification information could be an identification code, a password, or any other type of information making it possible to identifiy the user. The authentication token could be aby type of information making it possible to authenticate the user. Preferably, the authentication token comprises a one time code (OTC) . Such OTCs could be provided to the user by means of a sequence of codes to be used one time each, and perhaps in a pre-determined order. However, preferably the OTCs are generated by means of an OTC generation unit, in which a new code is generated each time it is used, based on personalizing information provided by the user, such as a personal PIN-code. However, many alternative types of personalizing information could be used as well . Such an OTC generation unit could be a specifically developed device with entering means such as a keyboard, a display, a processor for generating the code, etc. Alternatively, the device could comprise a reader for so called smart cards or integrated circuit card (ICC), i.e. cards provided with a chip. The reader is capable of reading out information from the card, and together the arrangement generates, e.g. as a response to a signal from the reader, a onetime identification code that could be used by the user to authenticate himself when making transactions via a digital network. The OTC generation unit is preferably portable and not connected to the communication network. The OTCs are preferably non-recurring strings of characters .

It is further preferred that the OTC generation unit calculates the OTC based on synchronization data, such as a sequence number or a time value, said synchronization data being automatically incremented and/or updated each time an OTC is generated, at regular time intervals, or any other regularly occurring event . The user ID and authentication token, OTC, received from the user is then transferred from the service provider to the fund manager, step S4. Preferably, additional information, such as information for identification of the service provider. The information is preferably arranged in a data package of a predetermined format .

Based on the received data, the fund manager tries to authenticate the user, step S5. The authentication could e.g. be made in the way described in the previously discussed WO 01/02325 of the same applicant, both other authentication methods are feasible as well.

If the authentication is erroneous or fails due to any other reasons, step S6, the authentication request is denied, step S7, and the service provider is notified accordingly. This could lead to a termination of the transaction between the user and the service provider, or a denial to access the requested information. However, it is also possible with one or several retrials.

If authentication is granted, step S6, the purchase and payment process is allowed to proceed. The first step is then to reserve a predetermined amount, in the following denominated "maximum purchase amount", Pmax, of the funds currently available on the user account for the service provider, step S8. The service provider is preferably notified accordingly, e.g. by sending an acceptance acknowledgement to the service provider, step S9. The amount being reserved, i.e. Pmax, is further preferably communicated to the service provider, especially if Pmax is allowed to vary from user to user, as is discussed in more detail below. The purchase is then effected between the user and the service provider, step S10, and the Pmax amount is charged accordingly. Accordingly, several purchases could be effected as long as there still remains something of the reserved Pmax amount . Accordingly, it is regularly checked whether Pmax is used up, step Sll. For example, this could be tested immediately before or after every new purchase activity. Thus, the user could in this way e.g. access several different web-pages which are subject to a charge and which are administered by the same service provider, without having to repeat the authentication process and the like.

When it is decided by the service provider that Pmax is used up, step Sll, it is decided whether the user wants to continue the purchase, step S12. This could be decided by prompting the user to reply to a question, or the like. If the user wants to continue, the user once again transfers an authentication token, such as an OTC, to the OSP, step S14, and the OSP forwards it to the fund manager, step S15. The user identification could this time be omitted, if it is stored by the service provider and/or the fund manager, and the user is recognized as the same user as last time. The fund manager thereafter authenticates the user based on the newly supplied authentication token, and the process is repeated from step S5.

If, in step S12, the user decides to end the purchase activity, the service provider notifies the fund manager accordingly and identifies the amount charged, and the fund manager transfers the charged amount for the purchase from said user account to the service provider, step S13. However, the amount being transferred could not be larger than the maximum purchase amount being reserved previously. The reserved amount is normally Pmax, but in case several authentication tokens have been supplied, the reserved amount could be Pmax * n, where n is the number of successful authentications since the purchase began or since the last fund transfer.

Thus, the risk exposed to the user is limited, since the user only runs the risk of loosing the reserved amount but nothing more .

The electronic money transfer could be electronically transferred to an account held by the service provider. This account could be identified by means of service provider information provided by the OSP. The OSP account could either be administered by the same fund manager, or by any other fund manager connected to the network. However, the money may also be transferred in many other ways, such as by cheques or the like .

The purchase and payment process is then ended, step S16.

The account administered by the fund manager and used for the payment as discussed above is preferably dedicated to such payments. However, the fund manager may also administer other, traditional accounts for the user, whereby funds could easily be transferred from one account to another. By having a dedicated micro-payment account, the user is exposed to a much smaller risk, since the balance on the account could be kept low. To this end, the accounts are preferably also totally separated, having different authentication tokens assigned to them, etc. However, the same authentication token generation means, such as a smart card, could preferably be used for generation of all the different types of authentication tokens. The different types of accounts could be held in the same or different account databases connected to the fund manager. The maximum purchase amount, Pmax, which is the maximum amount that could be reserved based on one authentication, is a parameter assigned to the account. This parameter could either be predetermined by the fund manager, but is preferably user definable. Hereby, the risk for the users of loosing money could be limited, and the users could themselves define the risk they are willing to be exposed to.

Further, a parameter indicating the maximum total amount value of the account is preferably assigned as a parameter to the account. This amount indicates the maximum total amount allowed to be held by the account. This parameter could also either be predetermined by the fund manager, or be user definable. Hereby, the risk for the users of loosing money could be further limited, and the users could even themselves define the risk they are willing to be exposed to.

The parameters related to the account could be controlled over the network as well, and authentication for these measures may be performed in various ways, as is known in the art. In a preferred embodiment, the same

OTC generation device could be used both for payments and for administrative access to the user account. However, in that case, it is preferred that different OTC generation processes are used, in order to keep the OTCs for the different purposes totally separated. Hereby, the security for the user is increased. Preferably, the user is presented with status information regarding the purchase and/or payment at least some times during the process . Most preferably, such information is presented continuously, e.g. in a special information window on the user screen. An example of such an information window 201 is illustrated in fig 2. The presented information could be provided by the service provider or the fund manager, or possibly both. The presented information could comprise information regarding the reserved amount, i.e. Pmax, and the part currently having been charged, and the part being left, respectively. This information could be presented in figures, or be graphically illustrated in different ways. In the illustrated embodiment, this information is presented as a separate window 202, which illustrates the total amount of Pmax, and "bricks" 203, illustrating the parts of Pmax having been used. Additionally, the percentage 204 of Pmax being left or being used could be presented in direct numbers. Further, the balance 205 left on the user account could be presented. However, any other information useful for the user during the purchase process could be presented as well.

Further, it is preferably provided a possibility for the user to stop the purchase at any time. This could be arranged by means of a stop button 206 on the information window 201. By pressing the stop button, the purchase is directly arrested, and the part of Pmax that have already been charged is transferred from the user account to the service provider as is discussed in the foregoing. However, other ways of effecting a user controllable stop functionality of the purchase and payment process are of course possible.

An alternative embodiment will now be discussed with reference to fig 4. Unless otherwise mentioned, the same aspects and features as discussed above with reference to the first embodiment also relates to this embodiment. In this embodiment, the user first connects to the fund manager, step SI'. Thereafter, the user selects a service provider for a purchase, step S2 ' . The selection of a service provider could preferably be made through the fund manager. For example, the fund manager could administer a web page with access links to different selected service providers. In this embodiment, much information could be transferred directly from the user to the fund manager, and some information, such as the identity of the selected service provider, could be derived automatically, without the necessity of additional user entries. Even the entries of further OTCs could be made directly to the fund manager, step S14 ' .

Still another embodiment will now be discussed with reference to fig 5. Unless otherwise mentioned, the same aspects and features as discussed above with reference to the first and second embodiment also relates to this embodiment. In this embodiment, the user connects to the service provider, step SI", and to the fund manager, step S2", in any order and separately. Thereafter, the user communicates directly with both the service provider and the fund manager, and only acknowledgements and the like need to be communicated between the service provider and the fund manager.

With respect to all aspects of the invention, computer software implementation is obviously preferred. The software of the authentication manager and service provider may be present in more or less traditional computers, and the software at user side may be within smart cards or other portable units having processing- and storage means .

The invention has now been described by way of preferred embodiments. However, many different modifications and alternatives are possible. For example, the OTCs may be generated in different ways than by calculations based on sequence numbers. Several such ways of obtaining OTCs would be available for someone skilled in the art .

Claims

1. An electronic payment method for effecting purchase transactions through a communication network system, said system involving a user, a service provider and a fund manager, all being connected through a communication network, the method comprising: providing a user account by the fund manager dedicated to the user; transferring a user authentication token from the user to the fund manager; authenticating the user based on said authentication token, and in case of adequate authentication reserving a maximum purchase amount of the funds currently available on the user account for the service provider; effecting a purchase between the user and the service provider; and upon effected purchase transferring an amount for the purchase from said user account to the service provider, said amount being less or equal to the maximum purchase amount.

2. The electronic payment method of claim 1, wherein the user authentication token comprises a one time code.

3. The electronic payment method of claim 1 or 2 , wherein the user account is dedicated to electronic payments .

4. The electronic payment method of any one of the preceding claims, wherein the user account has a maximum total amount value indicating the maximum total amount allowed to be held by the account.

5. The electronic payment method of claim 4 , wherein the maximum total amount value is user definable.

6. The electronic payment method of any one of the preceding claims, wherein the maximum purchase amount of the user account is user definable.

7. The electronic payment method of any one of the preceding claims, wherein the transfer of the user authentication token from the user to the fund manager is made through the service provider.

8. The electronic payment method of any one of the preceding claims, wherein, along with the user authentication token, user information data is transferred from the user to the fund manager to be used in the authentication.

9. The electronic payment method of any one of the preceding claims, wherein service provider information is further transferred from the service provider to the fund manager for identification of the service provider.

10. The electronic payment method of claim 9, wherein the amount for the purchase from said user account is transferred to a service provider account, identifiable by means of said service provider information.

11. The electronic payment method of any one of the preceding claims, wherein the purchase comprises download of or access to data held by the service provider.

12. The electronic payment method of any one of the preceding claims, wherein the purchase comprises at least two different purchase activities.

13. The electronic payment method of claim 12, wherein the at least two different purchase activities are timely separated.

14. The electronic payment method of any one of the preceding claims, further comprising presentation of information regarding the purchase from at least one of the service provider and the fund manager to the user.

15. The electronic payment method of claim 14, wherein the presented information relates to at least one of the total balance of the user account, the amount reserved for the service provider, the size of the consumed and unconsumed part of the reserved amount and amounts that have been transferred to the service provider.

16. The electronic payment method of any one of the preceding claims, the method further comprising providing a possibility for the user to stop any further purchase at any time .

17. The electronic payment method of any one of the preceding claims, the method further comprising providing at least one further user account by the fund manager dedicated to the user, said further account not being usable for said purchase payment .

18. The electronic payment method of claim 17, wherein different authentication tokens are usable for the different accounts.

19. The electronic payment method of any one of the preceding claims, wherein after the reservation of the maximum purchase amount at the fund manager, the method further comprising notification of this to the service provider.

20. The electronic payment method of any one of the preceding claims, further comprising transferring a further user authentication token from the user to the fund manager; and authenticating the user based on said further authentication token, and in case of adequate authentication reserving a further maximum purchase amount of the funds currently available on the user account for the service provider; wherein the step of transferring amount for the purchase from said user account to the service provider relates to all reserved maximum purchase amounts.

21. An electronic payment system for effecting purchase transactions, said system involving at least one user unit, at least one service provider unit and at least one fund manager unit, all units being connected through a communication network, the system comprising: an account database at the fund manager holding at least one user account dedicated to the at least one user; means for authentication of the user based on an authentication token input through the user unit; means for reserving a maximum purchase amount of the funds currently available on the user account for the service provider in case of adequate authentication of the user; means for effecting a purchase between the user and the service provider through the network; and means for transferring an amount for the purchase upon effected purchase from said user account to the service provider, said amount being less or equal to the maximum purchase amount .