Abstract:
The invention relates to a method allowing a client to electronically pay at least a minimal amount for a merchandise or service to a retailer by using a data network and/or telecommunication network with the aid of an accounting system server. An unambiguous process identifier is generated for the payment process or the series of payment steps and is transmitted at least during a first payment step in a confirmation request from the accounting system server to a client terminal along with information on the amount to be paid.

Description:
CLAIM FOR PRIORITY  
       [0001]     This application is a national stage of PCT/EP2003/006136, published in the German language on Jan. 15, 2004, which claims the benefits of priority to European Application No. 02014720.3, filed on Jul. 3, 2002 and German Application No. DE 102 29 901.3, filed on Jul. 3, 2002. 
     
    
     TECHNICAL FIELD OF THE INVENTION  
       [0002]     The invention relates to a method for the electronic payment of goods or services and a suitable arrangement for implementing the method.  
       BACKGROUND OF THE INVENTION  
       [0003]     As well as being used as a communication tool and information source by hundreds of millions of people at present, the internet is also becoming an increasingly important purchasing source. A significant proportion of trade in software, books and travel currently operates via the internet, but a wide range of other goods and services are also ordered and paid for via the internet. Payment for corresponding services using the internet in the originally established and still most widely used fashion requires that the relevant data records are input separately at least for every business partner if not for each individual transaction. This payment method thereby allows the business partner to access sensitive personal data and even allows them to store it in the long term.  
         [0004]     In the meantime, the internet has also become a significant tool for handling other payment processes, both business and private. Almost all banks in industrialized countries offer electronic banking for the electronic handling of account management and payment processes.  
         [0005]     The requirements for electronic payment methods differ tremendously for the different situations. This applies both to internet payment methods and to mobile payment methods based for example on SMS, WAP and USSD.  
         [0006]     Suitable methods are required, in particular, for so-called micro-payment. These are invoices for small amounts (typically less than EUR 5.00), which cannot generally be processed in a cost-effective manner using existing electronic payment methods, e.g. direct debit. Also micro-payment processes often comprise a plurality of individual small transactions rather than a single transaction (e.g. filling a shopping basket when shopping online). In the future, an increasing number of services on the internet will be charged for, e.g. web content, whereby the costs are a function for example of the volume of data transferred or the number of downloaded pages. Costs/charges are therefore continuously incurred as with a telephone call. When charging for content the costs are generally not a function of time but a function of user behavior. Time-based charges are however also possible in principle.  
         [0007]     When making a telephone call, users do not generally have to authorize payment. It is assumed that as soon as a user dials a number on their telephone, they agree automatically to the telephone provider charging it to their account. This is generally not a problem, as a relationship of trust and also a correspondingly structured contractual relationship exists between the user and the telephone service provider.  
         [0008]     This is not, however, always the case with e-commerce. Users can come across an arbitrary service of interest to them, the use of which has to be paid for, by chance on the internet. Since, in this case, there is no relationship of trust, the user first has to agree to a payment. In other words said user either confirms it (e.g. with OK) or authorizes it (with a PIN). Users do not, however, want to do this for each one of a series of charges. For one thing this is a lengthy process for the user and for another it is unacceptable for some services, such as streaming audio/video, as the audio/video might possibly have to be interrupted for each charge.  
         [0009]     The technical problem essentially involves developing a method which satisfies the above points: 
        Universality: same basic principle for different access methods, e.g. web, SMS and WAP.     Supports continuous charging, whereby the user can determine in a flexible, service-specific and direct fashion whether and when the next confirmation/authorization should take place.     Stipulation of the next confirmation/authorization must remain confidential as far as the retailer is concerned.     It must be possible for the user to make payments anonymously in respect of the retailer.     The operation must be organized as simply as possible.     The operation must be organized so that it is secure in respect of various attacks.        
 
         [0016]     European patent application 00 121 482.4 (published as EP 1 193 658 A1) deals with this basic problem.  
         [0017]     The publication describes how a money sender can transmit an electronic amount of money anonymously to a money recipient using a recipient ID (RID)—which is hereafter referred to as a session ID (SID) (for consistency of description). This allows the customer to remain anonymous in respect of the PSP (Payment Service Provider) and the retailer. The method is shown in a simplified fashion in  FIG. 1  and the brief description which follows:  
         [0018]     The retailer transmits the amount of money to be paid ( 1 ) to the PSP and receives a unique session ID (SID) ( 2 ) back. The retailer transmits the SID to the customer, e.g. verbally at a POS (point of sale) ( 3 ). The customer sets up a connection to the PSP and transmits the SID ( 3 ), as a result of which the customer can also be identified at the same time from their MSISDN. The PSP sends back the associated amount to be paid ( 5 ) and the customer confirms payment with a PIN ( 6 ). The retailer is notified of the SID as confirmation of payment.  
         [0019]     In a so-called pre-confirm method, i.e. a customer can confirm in advance a larger (or even smaller) amount than the retailer requires. This means that the retailer can make subsequent charges without the customer having to provide repeated and inconvenient confirmation. As customers themselves specify the maximum amount, they can determine the payment in a very flexible manner. They only have to confirm the payment again when the previously confirmed amount has been used up.  
         [0020]     A brief description of this method is given below and in  FIG. 2  with reference to its essential steps:  
         [0021]     The retailer wishes to charge an amount of $ 1  to the customer via the PSP ( 1 ). The PSP verifies that the pre-confirm account $ is adequate. If not the customer must confirm the amount with a PIN ( 2 ,  3 ). The customer can also confirm a larger amount ($2) and the pre-confirm account is adjusted accordingly. The amount $1 is confirmed to the retailer ( 4 ). When payment is next requested ( 5 ), the pre-confirm account is adequate so the amount can be confirmed immediately ( 6 ). These steps are repeated until the pre-confirm account is no longer adequate and the user must confirm again.  
         [0022]     The above-mentioned first method is very significantly oriented towards real POS, e.g. shops or vending machines, and prepaid accounts. The basic principle can thereby be extended with SID in a relatively simple manner to support other scenarios (e.g. web, WAP, SMS). Also pre-confirm can be set up on the basis of SID. The method only takes into account the situation where servers are operated by mobile radio operators. The second method mentioned above needs to be set out more specifically with regard to how it is actually set up.  
       SUMMARY OF THE INVENTION  
       [0023]     The invention provides an electronic payment method and corresponding arrangement, which has been worked out in practice and is particularly tailored to the requirements of micro-payment.  
         [0024]     The invention resolves the above-mentioned technical problems based on the following premises: 
        It is ensured on the basis of a session ID (SID) that the customer can (but does not have to) remain anonymous in respect of the retailer (service provider).     The SID also enables the customer to allow the retailer to make continuous charges without the customer having to confirm/authorize the payment.     The limit of the maximum total charge can be set by the customer in a flexible and service-specific manner.     The method supports a very wide range of access methods for the customer, e.g. WEB, WAP, SMS and voice/DTMF. It can be used both on the internet and at POS (points of sale). The interface between the retailer and PSP is typically provided via standard data lines.        
 
         [0029]     The method comprises the following steps in an expedient implementation; see also  FIG. 3  and the diagrams of exemplary embodiments in FIGS.  4  to  7  and the corresponding sections of the description below.  
         [0030]      1 ) Customer wants to use a retailer&#39;s service, e.g. to request WAP content, pay for goods in a web shop or at a POS.  
         [0031]      1   a ) If the retailer was able to identify the customer and determine an SID assigned to the customer, the retailer can provide this in step  2 ).  
         [0032]      2 ) The retailer sends a charge request with an SID (if available), the amount to be paid (AmountX), the retailer ID and a context (what was bought) to the PSP.  
         [0033]      3 ) The following distinctions are made here: 
        If no SID was provided at  2 ), the PSP sends a unique SID back to the retailer. Steps  3   a  to  3   f  then follow.     If an SID was provided at  2 ), with which no charge could be made (e.g. because the customer has to authorize payment first), the SID or alternatively a new SID is returned. Steps  3   a  to  3   f  then follow.     If an SID was provided at  2 ), with which a charge could be made, the charge is confirmed to the retailer. Step  4  then follows.          
         [0037]      3   a ) If the verification was negative at  3 ) (i.e. no charge possible), the PSP notifies the retailer of an SID.  
         [0038]      3   b ) The retailer notifies the customer of the SID. In the case of WAP and WEP this can be achieved as a parameter in a redirect from the customer to the PSP, in the case of SMS the retailer can send the customer an SMS containing the SID. At a POS the SID can also be communicated verbally.  
         [0039]      3   c ) The customer forwards the SID to the PSP. In the case of WEB and WAP this can be done automatically, i.e. no input is required from the customer (redirect). In the case of SMS the customer can forward the SMS from the retailer containing the SID to the PSP. In the case of voice/DTMF the customer generally has to call the PSP and communicate the SID via DTMF.  
         [0040]      3   d ) The PSP notifies the customer of the required amount (Amount X), the retailer name and context (e.g. via WEB, WAP, SMS or voice).  
         [0041]      3   e ) The customer identifies themselves, e.g. automatically via their MSISDN or by inputting their ID. The customer can also change (AmountY) the required amount (AmountX), e.g. increase it for advance confirmation of subsequent payments. The customer can also confirm/authorize the payment (e.g. PIN).  
         [0042]      3   f ) Verification of customer profile and liquidity.  
         [0043]      4 ) The PSP carries out the necessary verifications of the payment.  
         [0044]      5 ) As an option the PSP can confirm the payment (AmountX) to the customer (e.g. by SMS).  
         [0045]      6 ) The PSP confirms the posting of the amount to the retailer.  
         [0046]      7 ) The retailer sends the goods to the customer.  
         [0047]     In the case of connection-related operations with WAP and WEB, for example, the communication relationship switches from customer⇄retailer first to customer⇄PSP typically on the basis of connection redirect. So that the customer can use the required service from the retailer again after payment, a redirect takes place from the PSP back to the retailer. These redirects are implementation-specific and are therefore not shown in the sequence.  
         [0048]     After advance confirmation of an adequate amount a charge comprises steps  2 ),  3 ),  4 ) and  6 ) and can therefore be processed very efficiently. The advance confirmation of an amount does not have to be directly related to a purchase. The customer can for example confirm an adequate amount for an SID in advance, for example to pay at parking meters. If the retailer records the assignment between customer and SID, steps  3   a  to  3   f  can be omitted for future payments. Identification of the customer can for example be based on the MSISDN of an SMS or an ID at login. It is important here that the user ID for the retailer is independent of the user ID for the PSP. There are therefore no dependencies and the retailer does not have to know the user ID of the customer for the PSP.  
         [0049]     A customer has the option of having a list of their valid SIDs displayed for the PSP. As well as the SID, associated data such as the amount still available and the associated retailer can be displayed. Selected SIDs (at the PSP) can also be deleted, e.g. via WEB, WAP and SMS. After deletion of the SID the retailer cannot make any further charges without involving the customer. The entire operation then has to be carried out before a charge can be made again (e.g. request SID and confirm payment).  
         [0050]     The PSP does not have to manage the actual accounts and administer the money of the customer and retailer. The PSP can for example have interfaces with a clearing house, which deals with the clearing and settlement of the accounts.  
         [0051]     The method has the following advantages: 
        The basic principle of the method is identical for the different access methods (e.g. web, WAP, SMS, etc.). This simplifies the setting up of the payment system, the use of the method for retailers and customers without restricting flexibility.     The method supports both individual charges and continuous charging. The latter is primarily of importance for content charging, where charging is for example volume-based (pay per click) or even time-based.     Cost control: The customer can confirm amounts in advance in a service-specific manner and thereby avoid inconvenient posting confirmation/authorization.     With amounts confirmed in advance charges can be implemented very quickly. In a simple instance the customer has to send the retailer an SMS to obtain a drink from a vending machine, for example.     High level of security: The customer does not have to give the retailer any confidential or payment-related data, e.g. PIN or account number.     The customer can remain anonymous in respect of the retailer.        
 
         [0058]     It should be noted specifically that advantageous embodiments of the method specified in the dependent method claims should also all be understood as embodiments of the suitable arrangement for implementing said method, whether in hardware or software form. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0059]     The invention is described below with reference to exemplary embodiments, which are examined in more detail with reference to diagrams, in which:  
         [0060]      FIG. 1  shows the sequence of a known electronic payment method.  
         [0061]      FIG. 2  shows an electronic payment method which is the subject of a prior patent application.  
         [0062]      FIG. 3  shows a block diagram with method steps marked for associated clarification of essential aspects the invention.  
         [0063]      FIG. 4  shows a block diagram of a first embodiment of the invention.  
         [0064]      FIG. 5  shows a block diagram of a second embodiment of the invention.  
         [0065]      FIG. 6  shows a block diagram of a third embodiment of the invention.  
         [0066]      FIG. 7  shows a block diagram of a fourth embodiment of the invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0067]     With regard to  FIGS. 1 and 2  reference should be made to the explanation of the prior art in the introductory part of the specification; with regard to  FIG. 3  to the explanation of an expedient implementation above.  
         [0068]      FIG. 4  shows a first posting process for the first retrieval of a chargeable WAP content by the purchaser from a provider. In S 1 , a request is sent from the WAP-capable terminal (e.g. mobile telephone)  11  of the purchaser via a GSM telecommunication network  12  to the server  13  of a provider. In S 2 , the vendor transmits the transaction data, which comprises the ID of the vendor, the designation and invoice total of EUR  1  for the WAP content, via a data network  14  to the server  15  of a Payment Service Provider (PSP).  
         [0069]     As after verification of the transaction data in S 3  no session ID (SID) assigned to the purchaser was determined, a unique SID is now generated on the server  15  of the PSP by S 3 . 1  and transmitted in S 3 . 2  to the server  13  of the provider, where it is stored. This is sent in S 3 . 3  as a parameter in the URL of a WAP redirect to the mobile telephone  11  of the purchaser, whereby the SID is automatically transmitted to the server  15  of the PSP in S 3 . 4  in the context of the WAP redirect. Then in S 3 . 5  the ID of the vendor, the designation and invoice total of EUR  1  for the WAP content are sent from the server  15  of the PSP to the mobile telephone  11  of the purchaser. In S 3 . 6  the purchaser is identified from the known MSISDN of the mobile telephone by means of a WAP-GW request and authorization of a credit of EUR  3  is also effected with a PIN.  
         [0070]     In S 4  the credit amount is assigned to the transaction account associated with the SID on the server  15  of the PSP and the invoice total is posted to the transaction account and, after verification of the purchaser profile in S 5 , in S 6  a posting conformation, including the invoice total of EUR  1  and the retailer ID, is sent to the mobile telephone  11  of the purchaser. After transmission of the posting confirmation from the server  15  of the PSP to the server  13  of the provider in the form of SID and invoice total for the WAP content in S 7 , in S 8  release is given for transmission of the WAP content to the mobile telephone  11  of the purchaser.  
         [0071]      FIG. 5  describes a posting process for a chargeable WAP content, as might follow the example in  FIG. 4 . In step S 1  a further request is sent from the mobile telephone  21  of the purchaser to the server  23  of the provider, who in S 2  transmits the transaction data, comprising the vendor ID, the designation and invoice total of EUR  1  for the WAP content and SID to the server  25  of the PSP. After positive verification of the transaction data or SID, the credit amount and the customer profile in S 3  to S 5 , in S 6  the invoice total is posted to the transaction account on the server  25  of the PSP. When the posting confirmation has been sent S 7  to the server  23  of the provider, in S 8  release is given for transmission of the WAP content to the mobile telephone  21  of the purchaser.  FIG. 6  shows the use of a chargeable service based on SMS, whereby in S 1  a request is sent from the mobile telephone  31  of the purchaser via a mobile radio network  32  to the server  33  of the vendor. In S 2 , the MSISDN/mobile telephone number is used to determine the SID assigned to the purchaser and in S 3  the SID is transmitted along with the other transaction data (vendor ID, designation and invoice total of EUR  1 ) via a data network  34  to the server  35  of the PSP. After positive verification of the transaction data or SID, the credit amount and customer profile in S 4  to S 6 , in S 7  the invoice total is posted. Based on an instruction lodged in the customer profile, in S 8  confirmation of the posting of the invoice total of EUR  1  is sent from the server  35  of the PSP to the mobile telephone  31  of the purchaser. In S 9 , the posting confirmation is sent to the server  33  of the vendor and then in S 10  the vendor transmits the chargeable SMS to the customer.  
         [0072]      FIG. 7  shows a further example based on SMS, whereby S 1  (request for a chargeable service) to S 6  (verification of customer profile) operate in the same way as  FIG. 5 . In the present case, a posting authorization is lodged in the customer profile so that in S 7  the transaction data is sent from the server  45  of the PSP to the mobile telephone  41  of the purchaser. In S 8 , the posting is authorized by transmission of the invoice total, SID and PIN to the server  45  of the PSP and the posting is then carried out in S 9 . After transmission of the posting confirmation to the server  43  of the vendor in S 10 , in S 11  the chargeable SMS is transmitted from the vendor to the customer. The embodiment of the invention is not restricted to the descriptions given as examples above but includes a plurality of modifications which are within the scope of action by persons skilled in the art.