[go: up one dir, main page]

WO2004006198A1 - Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung - Google Patents

Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung Download PDF

Info

Publication number
WO2004006198A1
WO2004006198A1 PCT/EP2003/006136 EP0306136W WO2004006198A1 WO 2004006198 A1 WO2004006198 A1 WO 2004006198A1 EP 0306136 W EP0306136 W EP 0306136W WO 2004006198 A1 WO2004006198 A1 WO 2004006198A1
Authority
WO
WIPO (PCT)
Prior art keywords
customer
system server
payment amount
payment
amount
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2003/006136
Other languages
English (en)
French (fr)
Inventor
Axel Findling
Matthias Glätzer
Per Vindeby
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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
Priority claimed from DE2002129901 external-priority patent/DE10229901A1/de
Priority claimed from EP02014720A external-priority patent/EP1378876A1/de
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Priority to US10/519,921 priority Critical patent/US20060116938A1/en
Priority to JP2004518523A priority patent/JP2005536786A/ja
Priority to AU2003242676A priority patent/AU2003242676A1/en
Priority to BR0312394-4A priority patent/BR0312394A/pt
Publication of WO2004006198A1 publication Critical patent/WO2004006198A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06—COMPUTING OR CALCULATING; 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Definitions

  • the invention relates to a method for the electronic payment of goods or services according to the preamble of claim 1 and an arrangement suitable for carrying out this method.
  • the Internet In addition to being used as a means of communication and a source of information for hundreds of millions of people, the Internet is becoming increasingly important as a source of shopping. In particular, the trade in software, books and travel is already taking place to a significant extent on the Internet, but increasingly a wide range of other goods and services are being ordered and paid for on the Internet.
  • the payment of the corresponding services on the Internet in the originally established and still mostly widespread way requires the separate entry of the relevant data records at least for each business partner, if not for the individual transaction. This payment method gives the business partner an insight into sensitive personal data and even the possibility of permanent storage.
  • micro-payment processes are required. These are bills of small amounts (typically less than € 5.00), which are usually not cost-effective using existing electronic payment methods, such as Direct debit, can be processed.
  • micro-payment processes often do not consist of a single transaction (such as when shopping in a web shop, in which a "shopping cart” is filled), but of many individual small transactions.
  • more and more services will be billed on the Internet, such as web content, with the costs e.g. depend on the volume of the data transmitted or on the number of pages loaded. Similar to a telephone call, costs / charges are incurred continuously. When charging for content, however, the costs are usually not time-dependent, but dependent on the behavior of the user. In principle, time-based charging is also possible.
  • a user does not have to authorize payment when making a call. It is assumed that as soon as he dials a number on his phone, he automatically agrees that the phone provider may debit his account. This is generally not a problem, since there is a relationship of trust and a correspondingly designed contractual relationship between the user and the telephone service provider.
  • the first-mentioned publication describes how a money sender can transmit an electronic amount of money anonymously to a money recipient using a recipient ID (RID) - in the following, however, we will refer to this as a session ID (SID) (in order to standardize the description).
  • SID session ID
  • the method is shown in simplified form in FIG. 1 and the following brief description:
  • the dealer transmits the amount of money to be paid (1) to the PSP and receives a unique session ID (SID) (2). He sends the SID orally to the customer, for example, at a POS (Point of Halls) (3).
  • the customer establishes a connection to the PSP and transmits the SID (3), whereby he can also be identified on the basis of his MSI ⁇ DN.
  • the PSP returns the associated amount to be paid (5) and the customer confirms the payment with a PIN (6).
  • the SID is communicated to the dealer as a payment confirmation.
  • the older registration mentioned describes the process of the so-called pre-confirm, which means that a customer can pre-confirm a higher (or also lower) amount than the dealer requests. This means that subsequent debits can be made by the retailer without the annoying confirmation from the customer. Since the customer himself specifies the maximum amount, he can very flexibly determine the payment himself. Only when the pre-confirmed amount has been used does he have to confirm the payment again.
  • the dealer wants to debit an amount of $ 1 from the customer via the PSP (1).
  • the PSP checks whether the preconfirm account $ is sufficient. If not, the customer must confirm the amount with a PIN (2,3). In addition, he can confirm a higher amount ($ 2) and the pre-confirm account will be adjusted accordingly.
  • the amount $ 1 is confirmed to the dealer (4).
  • the pre-confirm account is sufficient so that the amount can be confirmed immediately (6). These steps are repeated until the pre-confirm account is no longer sufficient and the user has to confirm again.
  • the above-mentioned method is very strong on real POS, for example shops or vending machines, and Prepaid accounts targeted.
  • the basic principle can be expanded relatively easily with SID to support other scenarios (e.g. web, WAP, SMS).
  • the pre-confirm can also be implemented on the basis of the SID.
  • the method only takes into account the case where the servers are operated by mobile operators.
  • the second method mentioned above still requires certain concretizations regarding the precise implementation.
  • the invention is therefore based on the object of providing a practice-oriented electronic payment method which is tailored particularly to the requirements of micro-payment.
  • the task also includes the provision of a corresponding arrangement.
  • SID session ID
  • the SID enables the customer to allow the dealer to make continuous debits without the customer having to confirm / authorize the payment.
  • the user can set the limit of the maximum direct debit flexibly, depending on the service.
  • the procedure supports a wide variety of access procedures for the customer such as WEB, WAP, SMS and Voice / DTMF. It can be used both on the Internet and at POS (Point of Sales).
  • the connection between dealer and PSP is typically established via standard data lines.
  • the method comprises the following steps; see. 3 and the illustration of preferred exemplary embodiments given in FIGS. 4 to 7 and the corresponding parts of the description further below.
  • the PSP informs the customer of the requested amount (AmountX), the dealer name and the context e.g. via WEB, WAP, SMS or Voice (voice announcement) with.
  • AmountX the requested amount
  • the customer identifies himself, e.g. automatically via his MSISDN, or by entering his ID.
  • the customer can change the requested amount (AmountX) (AmountY), e.g. increase for a pre-confirmation of subsequent payments. He can also confirm / authorize payment (e.g. PIN).
  • 3f) Checking customer profile and liquidity.
  • the PSP can confirm the payment (AmountX) to the customer (e.g. via SMS). 6) The PSP confirms the booking of the amount to the dealer. 7) The dealer sends the goods to the customer.
  • connection-related processes with e.g. WAP and WEB the change of communication relationship from first between customer ⁇ -> dealer to customer ⁇ -> PSP typically takes place on the basis of connection redirect.
  • a debit only consists of steps 2), 3), 4) and 6) and can therefore be processed very efficiently.
  • the confirmation of an amount does not have to be directly related to a purchase.
  • the customer can, for example, confirm a sufficiently large amount for a SID, for example, at Pay parking machines. If the merchant remembers the assignment between customer and SID, steps 3a to 3f can be omitted for all future payments.
  • the customer can be identified, for example, on the basis of the MSISDN of an SMS or an identifier when logging in. It is important that the user identification at the dealer is independent of the user identification at the PSP. There are therefore no dependencies and the dealer does not have to know the customer's user ID at the PSP.
  • a customer can view a list of his valid SIDs at any time at the PSP.
  • the associated data such as the amount still available and the associated merchant, can also be displayed.
  • Selected SIDs (for PSP) can also be deleted, e.g. via WEB, WAP and SMS. After deleting the SID, the dealer cannot make any debits without the customer being involved. In order to make a debit again, the entire process must then be carried out (e.g. request SID and confirm payment).
  • the PSP does not have to keep the real accounts and manage customer and merchant money.
  • the PSP can e.g. Have interfaces to a clearing house, which carries out the clearing and settlement of the accounts.
  • the procedure supports both individual debits and continuous debits.
  • the latter is particularly important for content charging, where the charge is, for example, volume-based ("pay per click") or time-based. det.
  • the customer can be anonymous to the dealer.
  • 1 is a schematic representation to illustrate the sequence of a known electronic payment method
  • FIG. 4 is a block diagram of a first embodiment of the invention
  • 5 shows a block diagram of a further embodiment of the invention
  • Fig. 6 is a block diagram of a third embodiment of the invention.
  • Fig. 7 is a block diagram of another embodiment of the invention.
  • FIG. 4 shows a first booking process for the first-time retrieval of chargeable WAP content by the buyer from a provider.
  • the buyer's WAP-capable terminal for example mobile phone
  • the seller transmits the transaction data, which consists of the seller's identifier, the name and the invoice amount in the amount of € 1 for the WAP content, via a data network 14 to the server 15 of a payment service provider (PSP).
  • PSP payment service provider
  • step S3 Since, after checking the transaction data in step S3, no session ID (SID) assigned to the buyer was determined, a unique SID is now generated on the server 15 of the PSP by step ⁇ 3.1 and transmitted to the server 13 of the provider with S3.2, where it is stored. This is sent in step S3.3 as a parameter in the URL of a WAP redirect to the buyer's mobile phone 11, the SID being automatically transmitted to the server 15 of the PSP in step S3.4 as part of the WAP redirect. Subsequently, in S3.5, the server 15 of the PSP transmits the identifier of the seller, the name and the invoice amount of € 1 of the WAP content to the mobile phone 11 of the buyer. Find in step S3.6 an identification of the buyer based on the known MSISDN of the mobile phone by a WAP-GW query and furthermore an authorization of a credit amount of € 3 with a PIN instead.
  • SID session ID
  • step S4 On the server 15 of the PSP, in step S4, the credit amount is assigned to the transaction account associated with the SID and the invoice amount is posted to the transaction account, and after checking the buyer profile in S5, a booking confirmation is included in S6, which includes the invoice amount of € 1 and the dealer identification, sent to the buyer's cellular phone 11. After the transfer of the booking confirmation from the server 15 of the PSP to the server 13 of the provider in the form of SID and invoice amount for the WAP content in S7, the transfer of the WAP content to the mobile phone 11 of the buyer is released in step S8.
  • FIG. 5 describes a booking process for a chargeable WAP content, as could follow the example from FIG. 4.
  • step S1 a further request is sent from the buyer's mobile telephone 21 to the provider's server 23, which in step S2 contains the transaction data consisting of the seller's identifier, the name and the invoice amount of € 1 for the WAP content and SID , to the server 25 of the PSP.
  • step S2 contains the transaction data consisting of the seller's identifier, the name and the invoice amount of € 1 for the WAP content and SID , to the server 25 of the PSP.
  • step S6 After sending the booking confirmation S7 to the server 23 of the provider, the release for transmitting the WAP content to the mobile phone 21 of the buyer then takes place in step S8.
  • step S1 shows the use of a fee-based service based on SMS, in which a request is made in step S1 from the buyer's mobile telephone 31 via a mobile radio network 32. tion to the server 33 of the seller.
  • step S2 the SID associated with the buyer is determined on the basis of the MSISDN / mobile phone number and transmitted in S3 together with the remaining transaction data (seller identifier, name and invoice amount of € 1) via a data network 34 to the server 35 of the PSP.
  • the invoice amount is posted in S7.
  • step S8 the server 35 of the PSP issues a confirmation of the booking of the invoice amount of 1 € to the mobile phone 31 of the buyer.
  • step S9 the booking confirmation is determined to the seller's server 33, where the seller then transmits the chargeable SMS to the customer in step S10.
  • FIG. 7 shows another example based on SMS, the steps S1 (requesting a chargeable service) to S6 (checking the customer profile) proceeding analogously to FIG. 5.
  • an authorization of the booking is stored in the customer profile, so that in step S7 the transaction 45 is sent from the server 45 of the PSP to the mobile telephone 41 of the buyer.
  • the booking is authorized by transmitting the invoice amount, SID and PIN to the server 45 of the PSP, which is then carried out in S9.
  • the paid SMS is transmitted from the seller to the customer with S11.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur elektronischen Bezahlung mindestens eines Kleinstbetrages für eine Ware oder Dienstleistung durch einen Kunden an einen Händler unter Nutzung eines Daten- und/oder Telekommunikationsnetzes und unter Einschaltung eines Abrechnungssystem-Servers, wobei für den Bezahlvorgang oder die Serie von Bezahlschritten ein eindeutiger Vorgangs-Identifikator generiert und mindestens bei einem ersten Bezahlschritt in einer Bestätigungsanfrage vom Abrechnungssystem-Server, zusammen mit einer Zahlbetragsinformation, an ein Kunden-Endgerät übermittelt wird.

Description

Beschreibung
Verfahren zur elektronischen Bezahlung einer Ware oder Dienstleistung unter Nutzung eines Mobilfunknetzes und Anord- nung zu dessen Durchführung
Die Erfindung betrifft ein Verfahren zur elektronischen Bezahlung einer Ware oder Dienstleistung nach dem Oberbegriff des Anspruchs 1 sowie eine zur Durchführung dieses Verfahrens geeignete Anordnung.
Das Internet gewinnt - neben der Nutzung als Kommunikationsmittel und Informationsquelle für mittlerweile Hunderte von Millionen Menschen - zunehmend an Bedeutung als Einkaufsquel- le. Insbesondere der Handel mit Software, Büchern und Reisen läuft heute bereits zu einem nennenswerten Anteil im Internet ab, zunehmend wird aber auch ein breites Spektrum sonstiger Waren und Dienstleistungen über das Internet bestellt und bezahlt. Die Bezahlung der entsprechenden Leistungen im Inter- net auf die ursprünglich etablierte und heute noch meist verbreitete Weise erfordert die jeweils gesonderte Eingabe der relevanten Datensätze zumindest bei jedem Geschäftspartner, wenn nicht sogar für die einzelne Transaktion. Diese Zahlungsweise gibt damit dem Geschäftspartner Einblick in sen- sible persönliche Daten und sogar die Möglichkeit ihrer dauerhaften Speicherung.
Auch für die Abwicklung sonstiger Zahlungsvorgänge im geschäftlichen wie im privaten Bereich hat das Internet inzwi- sehen erhebliche Bedeutung erlangt. Nahezu alle Banken in den Industrieländern bieten als "Electronic Banking" die elektronische Abwicklung der Kontoführung und von Zahlungsvorgängen an.
Für die verschiedenen Situationen existieren die unterschiedlichsten Anforderungen an elektronischen Bezahlverfahren. Dies umfasst sowohl Bezahlverfahren über das Internet als auch mobile Bezahlverfahren auf Basis von z.B. SMS, WAP und USSD.
Im besonderen werden geeignete Verfahren für das sogenannte Micro-Payment benötigt. Dies sind Abrechnungen kleiner Beträge (typisch kleiner €5,00), die in der Regel nicht kosteneffizient über vorhandene elektronische Bezahlverfahren, wie z.B. Lastschrift, abgewickelt werden können. Außerdem bestehen Micro-Payment-Vorgänge oft nicht aus einer einzelnen Transaktion (wie z.B. beim Einkauf in einem Web-Shop, bei dem ein "Warenkorb" gefüllt wird) , sondern aus vielen einzelnen kleinen Transaktionen. Zukünftig werden immer mehr Dienste im Internet vergebührt, wie Web-Content, wobei die Kosten z.B. vom Volumen der übermittelten Daten abhängen oder von der An- zahl der geladenen Seiten. Ähnlich wie bei einem Telefongespräch fallen also kontinuierlich Kosten/Abbuchungen an. Bei der Vergebührung von Content sind die Kosten allerdings in der Regel nicht zeitabhängig, sondern abhängig vom Verhalten des Benutzers. Eine zeitabhängige Vergebührung ist jedoch im Prinzip auch möglich.
Beim Telefonieren muss ein Benutzer in der Regel eine Bezahlung nicht autorisieren. Es wird davon ausgegangen, dass er sobald er an seinem Telefon eine Nummer gewählt hat, automa- tisch damit einverstanden ist, dass der Telefonanbieter sein Konto belasten darf. Dies ist in der Regel auch kein Problem, da ein Vertrauensverhältnis und auch ein entsprechend gestaltetes Vertragsverhältnis zwischen dem Benutzer und dem Telefondienstanbieter besteht.
Bei e-commerce ist dies aber nicht immer der Fall. Ein Benutzer kann im Internet einen für ihn interessanten zufälligen Dienst, für dessen Benutzung er bezahlen muss, zufällig finden. Da in diesem Fall kein Vertrauensverhältnis existiert, will der Benutzer einer Bezahlung erst zustimmen, d.h. sie entweder bestätigen (z.B. mit OK) oder gar autorisieren (mit einer PIN) . Bei kontinuierlichen Abbuchungen möchte er dies aber nicht bei jeder Abbuchung vornehmen. Einerseits ist dies für den Benutzer umständlich und andererseits bei einigen Diensten wie z.B. Streaming Audio/Video unakzeptabel, da in diesem Fall das Audio/Video für jede Abbuchung möglicherweise unterbrochen werden würde.
Das technische Problem besteht grundsätzlich darin, ein Verfahren zu entwickeln, welches obige Punkte befriedigt:
- Universalität: gleiches Grundprinzip für unterschiedliche Access-Methoden wie z.B. Web, SMS und WAP.
- Unterstützung von kontinuierlichen Abbuchungen, wobei der Benutzer flexibel, dienstspezifisch und unmittelbar bestimmen kann, ob und wann die nächste Bestätigung/Autorisierung er- folgen soll.
- Die Festlegung der nächsten Bestätigung/Autorisierung muss für den Händler geheim bleiben.
- Die Bezahlung muss für den Benutzer gegenüber dem Händler anonym erfolgen können. - Der Ablauf muss möglichst einfach gestaltet sein.
- Der Ablauf muss so gestaltet sein, dass es bzgl. unterschiedlicher Angriffe sicher ist.
Mit diesem grundsätzlichen Problem beschäftigen sich u.a. die europäische Patentanmeldung 00 121 482.4 (veröffentlicht als EP 1 193 658 AI) sowie eine weitere frühere Patentanmeldung (betriebsinternes Zeichen 200201374) des Anmelders.
Die erstgenannte Druckschrift beschreibt, wie ein Geldsender einem Geldempfänger mittels einer Empfänger-ID (RID) einen elektronischen Geldbetrag anonym übermitteln kann - im folgenden wir diese jedoch als Session-ID (SID) bezeichnet (zwecks Vereinheitlichung der Beschreibung) . Hiermit kann der Kunde gegenüber dem PSP (Payment Service Provider) wie auch Händler anonym bleiben. In Fig. 1 und der nachfolgenden Kurzbeschreibung ist das Verfahren vereinfacht dargestellt: Der Händler übermittelt dem PSP den zu bezahlenden Geldbetrag (1) und erhält eine eindeutige Session-ID (SID) (2) zurück. Die SID übermittelt er dem Kunden z.B. mündlich bei einem POS (Point of Säle) (3) . Der Kunde baut eine Verbindung zum PSP auf und übermittelt die SID (3), wodurch er gleichzeitig auch anhand seiner MSIΞDN identifiziert werden kann. Der PSP gibt den zugehörigen zu bezahlenden Betrag zurück (5) und der Kunde bestätigt die Bezahlung mit einer PIN (6) . Die SID wird dem Händler als Zahlungsbestätigung mitgeteilt.
Die genannte ältere Anmeldung beschreibt das Verfahren des sogenannten Pre-confirm, das heißt, ein Kunde kann einen höheren (oder auch geringeren) Betrag vorausbestätigen als der Händler fordert. Somit können nachfolgende Abbuchungen vom Händler ohne die dauernde lästige Bestätigung durch den Kunden erfolgen. Da der Kunde selber den maximalen Betrag vorgibt, kann er die Bezahlung sehr flexibel selbst bestimmen. Erst wenn der vorausbestätigte Betrag aufgebraucht ist, muss er die Bezahlung wieder bestätigen.
Nachfolgend sowie in Fig. 2 wird eine Kurzbeschreibung dieses Verfahrens anhand seiner wesentlichen Schritte gegeben:
Der Händler will über den PSP vom Kunden einen Betrag $1 ab- buchen (1) . Der PSP prüft ob das preconfirm-Konto $ ausreichend ist. Wenn nein, muss der Kunde den Betrag mit einer PIN bestätigen (2,3). Zusätzlich kann er einen höheren Betrag bestätigen ($2) und das Pre-confirm-Konto wird entsprechend angepasst. Der Betrag $1 wird dem Händler bestätigt (4). Bei der nächsten Zahlungsaufforderung (5) reicht das Pre-confirm- Konto aus, so dass der Betrag sofort bestätigt werden kann (6) . Diese Schritte wiederholen sich bis das Pre-confirm-Konto nicht mehr ausreicht und der Benutzer wieder bestätigen muss .
Das oben erstgenannte Verfahren ist sehr stark auf reale POS, beispielsweise Ladengeschäfte oder Verkaufsautomaten, und Prepaid-Konten ausgerichtet. Dabei kann das Grundprinzip mit SID relativ einfach erweitert werden um auch andere Szenarien zu unterstützen (z.B. Web, WAP, SMS) . Weiter kann auf Basis der SID auch das Pre-confirm realisiert werden. Das Verfahren berücksichtig nur den Fall, wo die Server von Mobilfunkbetreibern betrieben werden. Das zweite oben erwähnte Verfahren bedarf hinsichtlich der genauen Realisierung noch bestimmter Konkretisierungen .
Der Erfindung liegt daher die Aufgabe der Bereitstellung eines praxisnah ausgearbeiteten und besonders auf die Erfordernisse des Micro-Payment zugeschnittenen elektronischen Bezahlverfahrens zugrunde. Weiter umfasst die Aufgabe die Bereitstellung einer entsprechenden Anordnung.
Diese Aufgabe wird in ihrem Verfahrensaspekt gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1 und in ihrem Vorrichtungsaspekt durch eine Anordnung mit den Merkmalen des Anspruchs 16.
Die Erfindung löst die oben genannten technischen Probleme aufgrund folgender Prämissen:
- Auf Basis einer Session-ID (SID) wird sichergestellt, dass der Kunde gegenüber dem Händler (Dienstanbieter) anonym bleiben kann (aber nicht muss) .
- Weiter ermöglicht die SID, dass der Kunde dem Händler erlauben kann kontinuierliche Abbuchungen vorzunehmen ohne dass der Kunde die Bezahlung bestätigen/autorisieren muss. - Das Limit der maximalen gesammelten Abbuchung kann vom Benutzer dienstspezifisch und flexibel gesetzt werden.
- Das Verfahren unterstützt die unterschiedlichsten Access- Verfahren für den Kunden wie z.B. WEB, WAP, SMS und Voi- ce/DTMF. Es kann sowohl im Internet wie auch an POS (Point of Sales) eingesetzt werden. Die Anbindung zwischen Händler und PSP wird typischer Weise über Standard-Datenleitungen hergestellt. Das Verfahren umfasst in einer zweckmäßigen Verfahrensführung die nachfolgenden Schritte; vgl. dazu Fig. 3 sowie die in den Figuren 4 bis 7 gegebene Darstellung bevorzugter Ausführungs- beispiele und die entsprechenden Beschreibungsteile weiter unten.
1) Kunde will einen Service von einem Händler benutzen, z.B. WAP-Content abfragen, in einem WEB-Shop oder an einem POS für eine Ware bezahlen. la) Konnte der Händler den Kunden identifizieren und eine dem Kunden zugeordnete SID ermitteln, so kann er diese in Schritt
2) mitgeben.
2) Der Händler sendet eine Abbuchungsanfrage mit einer SID (falls vorhanden), den zu bezahlenden Betrag (BetragX) , die
Händler-ID sowie einen Kontext (was wurde gekauft) an den PSP.
3) Hier gibt es folgende Fallunterscheidungen:
- Wurde bei 2) keine SID mitgegeben, so gibt der PSP eine eindeutige SID an den Händler zurück. Anschließend folgen die Schritte 3a bis 3f.
- Wurde bei 2) eine SID mitgegeben, mit der jedoch keine Ab- buchung möglich war (z.B. weil der Kunde die Bezahlung erst autorisieren muss), so wird die SID oder alternativ eine neue SID zurückgegeben. Anschließend folgen die Schritte 3a bis 3f .
- Wurde bei 2) eine SID übermittelt, bei der eine Abbuchung stattfinden konnte, so wird dem Händler die Abbuchung bestätigt. Anschließend folgt Schritt 4. 3a) Falls bei 3) die Prüfung negativ war (d.h. keine Abbuchung möglich), so teilt der PSP dem Händler eine SID mit. 3b) Der Händler teilt dem Kunden die SID mit. Bei WAP and WEP kann dies als Parameter in einem Redirect vom Kunden zum PSP geschehen, bei SMS kann der Händler dem Kunden eine SMS mit der enthaltene SID zuschicken. An einem POS kann die SID auch mündlich übermittelt werden. 3c) Der Kunde leitet die SID an den PSP weiter. Bei WEB und WAP kann dies automatisch geschehen, d.h., der Kunden muss hierfür keine Eingaben machen (Redirect) . Bei SMS kann er die SMS vom Händler mit der SID an den PSP weiterleiten. Bei Voi- ce/DTMF muss der Kunde i.d.R. den PSP anrufen und die SID via DTMF übermitteln.
3d) Der PSP teilt dem Kunden den geforderten Betrag (BetragX) , den Händlernamen sowie den Kontext z.B. via WEB, WAP, SMS oder Voice (Sprachansage) mit. 3e) Der Kunde identifiziert sich, z.B. automatisch via seiner MSISDN, oder Eingabe seiner Kennung. Darüber hinaus kann der Kunde den geforderten Betrag (BetragX) verändern (BetragY) , z.B. erhöhen für eine Vorausbestätigung nachfolgender Zahlungen. Weiter kann er die Bezahlung bestätigen/autorisieren (z.B. PIN) . 3f) Prüfung auf Kundenprofil und Liquidität.
4) Der PSP führt nun die notwendigen Überprüfungen der Bezahlung durch.
5) Optional kann der PSP dem Kunden die Bezahlung (BetragX) bestätigen (z.B. per SMS). 6) Der PSP bestätigt die Buchung des Betrags an den Händler. 7) Der Händler übermittelt die Ware an den Kunden.
Bei verbindungsbezogenen Abläufen mit z.B. WAP und WEB findet der Wechsel der Kommunikationsbeziehung von zuerst zwischen Kunde<->Händler zu Kunde<->PSP typisch auf Basis Verbindungs- Redirect statt. Damit der Kunde beim Händler den gewünschten Dienst nach der Bezahlung wieder nutzen kann, findet ein Redirect vom PSP zurück zum Händler statt. Diese Redirects sind nur implementierungsspezifisch und somit nicht im Ablauf dar- gestellt.
Nach einer Vorausbestätigung eines ausreichenden Betrags besteht eine Abbuchung nur aus den Schritten 2), 3), 4) und 6) und kann somit sehr effizient abgewickelt werden. Das Voraus- bestätigen eines Betrags muss nicht in unmittelbarem Zusammenhang eines Kaufs stehen. Der Kunde kann z.B. zu einer SID einen ausreichend großen Betrag vorausbestätigen um z.B. bei Parkautomaten zu bezahlen. Wenn sich der Händler die Zuordnung zwischen Kunde und SID merkt, so können für alle zukünftigen Bezahlungen die Schritte 3a bis 3f entfallen. Die Erkennung des Kunden kann z.B. auf Basis der MSISDN einer SMS oder einer Kennung bei einem Login stattfinden. Wichtig dabei ist, dass die Benutzererkennung beim Händler unabhängig von der Benutzerkennung beim PSP ist. Es bestehen somit keine Abhängigkeiten und der Händler muss die Benutzerkennung des Kunden beim PSP nicht kennen.
Ein Kunde hat jederzeit die Möglichkeit, sich beim PSP eine Liste seiner gültigen SIDs anzeigen lassen. Zusätzlich zur SID können auch die zugehörigen Daten, wie der noch verfügbare Betrag und der zugehörige Händler angezeigt werden. Ausge- wählte SIDs (beim PSP) können auch gelöscht werden, z.B. via WEB, WAP und SMS. Nach einem Löschen der SID kann der Händler keine Abbuchungen vornehmen ohne dass der Kunde involviert wird. Um eine Abbuchung wieder vorzunehmen, muss dann der gesamte Ablauf durchgeführt werden (z.B. SID anfordern und Be- Zahlung bestätigen) .
Der PSP muss nicht die wirklichen Konten führen und das Geld des Kunden und Händler verwalten. Der PSP kann z.B. Schnittstellen zu einem Clearing House haben, welches das Clearing und Settlement der Konten durchführt.
Folgende Vorteile hat das Verfahren:
- Das Grundprinzip des Verfahrens ist identisch für die un- terschiedlichen Access-Methoden (z.B. Web WAP, SMS, etc.).
Dies vereinfacht die Realisierung des PaymentSystems, die Benutzung des Verfahrens für Händler und Kunden ohne Einschränkung der Flexibilität.
- Das Verfahren unterstützt sowohl einzelne Abbuchungen wie auch kontinuierliche Abbuchungen. Letzteres ist vor allem wichtig bei Content-Charging, wo die Vergebührung z.B. volumenbasiert ("Pay per Click") oder auch zeitbasiert stattfin- det.
- Kostenkontrolle: Der Kunde kann dienstspezifisch Beträge vorausbestätigen und somit das sonst lästige Bestätigen/Autorisieren der Buchungen vermeiden. - Bei vorausbestätigten Beträgen verläuft die Abbuchung sehr schnell: In einem einfachen Fall muss der Kunde dem Händler nur eine SMS schicken, um z.B. ein Getränk aus einem Getränkeautomaten zu erhalten.
- Hohe Sicherheit: Der Kunde muss dem Händler keine vertrau- liehen bzw. zahlungsrelevanten Daten geben wie z.B. PIN oder
Kontonummer.
- Der Kunde kann gegenüber dem Händler anonym sein.
Weitere Aspekte der Erfindung ergeben sich aus den Unteran- Sprüchen. Es wird ausdrücklich darauf hingewiesen, dass in den abhängigen Verfahrensansprüchen angegebene vorteilhafte Ausgestaltungen des Verfahrens sämtlich auch als Ausgestaltungen der zur Durchführung des Verfahrens geeigneten Anordnung, sei es in hardware- oder softwaremäßiger Realisierung, zu verstehen sind. Nachfolgend wird die Erfindung anhand von Ausführungsbeispielen beschrieben, die anhand von Abbildungen näher erläutert werden. Hierbei zeigen:
Fig. 1 eine schematische Darstellung zur Verdeutlichung des Ablaufes eines bekannten elektronischen Zahlverfahrens,
Fig. 2 eine schematische Darstellung eines elektronischen Bezahlverfahrens, welches Gegenstand einer früheren Patentanmeldung ist,
Fig. 3 ein Blockschaltbild mit Kennzeichnungen von Verfahrensschritten zur zusammenhängenden Verdeutlichung wesentlicher Gedanken der Erfindung,
Fig. 4 ein Blockschaltbild einer ersten Ausführungsform der Erfindung, Fig. 5 ein Blockschaltbild einer weiteren Ausführungsform der Erfindung,
Fig. 6 ein Blockschaltbild einer dritten Ausführungsform der Erfindung und
Fig. 7 ein Blockschaltbild einer weiteren Ausführungsform der Erfindung.
Zu Fig. 1 und 2 wird auf die Erläuterung des Standes der
Technik in der Beschreibungseinleitung hingewiesen; zu Fig. 3 auf die Erläuterung einer zweckmäßigen Verfahrensführung weiter oben.
Fig. 4 stellt einen ersten Buchungsprozess für das erstmalige Abrufen eines kostenpflichtiges WAP-Contents durch den Käufers bei einem Anbieter dar. In Schritt Sl ergeht vom WAP-fähigen Endgerät (z.B. Mobilfunktelefon) 11 des Käufers eine Anfrage über ein GSM-Telekommunikationsnetz 12 an den Server 13 eines Anbieters. Der Verkäufer Übermittel in Schritt S2 die Transaktionsdaten, die aus der Kennung des Verkäufers, der Bezeichnung und des Rechungsbetrages in Höhe von 1 € für das WAP-Contents bestehen, über ein Datennetz 14 an den Server 15 eines Payment Service Providers (PSP) .
Da nach Überprüfung der Transaktionsdaten in Schritt S3 keine dem Käufer zugeordnete Session-ID (SID) ermittelt wurde, wird nun auf dem Server 15 des PSP durch Schritt Ξ3.1 eine eindeutige SID erzeugt und mit S3.2 zum Server 13 des Anbieters übertragen, wo diese gespeichert wird. Diese wird im Schritt S3.3 als Parameter in der URL eines WAP-Redirect an das Mobiltelefon 11 des Käufers gesendet, wobei die SID automatisch im Rahmen des WAP-Redirect in Schritt S3.4 an den Server 15 des PSP übermittelt wird. Nachfolgend wird in S3.5 vom Server 15 des PSP die Kennung des Verkäufers, die Bezeichnung und der Rechungsbetrag von 1 € des WAP-Contents an das Mobilfunktelefon 11 des Käufers übermittelt. In Schritt S3.6 findet eine Identifizierung des Käufers anhand der bekannten MSISDN des Mobilfunktelefons durch eine WAP-GW-Abfrage und weiterhin eine Autorisierung eines Guthabenbetrages von 3 € mit einer PIN statt.
Auf dem Server 15 des PSP wird im Schritt S4 der Guthabenbetrag dem zur SID zugehörigen Transaktionskonto zugeordnet sowie der Rechnungsbetrag auf dem Transaktionskonto verbucht, und nach Überprüfung des Käuferprofils in S5 wird in S6 eine Buchungsbestätigung, der den Rechnungsbetrag von 1 € und die Händlerkennung umfasst, zum Mobilfunktelefon 11 des Käufers gesendet. Nach der Übermittlung der Buchungsbestätigung vom Server 15 des PSP an den Server 13 des Anbieters in Form von SID und Rechnungsbetrag für den WAP-Content in S7, erfolgt in Schritt S8 die Freigabe der Übermittlung des WAP-Contents zum Mobilfunktelefon 11 des Käufers.
Fig. 5 beschreibt einen Buchungsprozess für einen kostenpflichtigen WAP-Content, wie es sich an das Beispiel aus Fig. 4 anschließen könnte. In Schritt Sl ergeht vom Mobilfunktelefon 21 des Käufers eine weitere Anfrage an den Server 23 des Anbieters, der in Schritt S2 die Transaktionsdaten, bestehend aus der Kennung des Verkäufers, der Bezeichnung und des Rechnungsbetrages in Höhe von 1 € für den WAP-Content sowie SID, an den Server 25 des PSP. Nach positiver Überprüfung der
Transaktionsdaten bzw. der SID, des Guthabenbetrags und des Kundenprofils in den Schritten S3 bis S5, wird nun nachfolgend in Schritt S6 die Buchung des Rechnungsbetrages zum Transaktionskonto auf dem Server 25 des PSP vorgenommen. Nach dem Senden der Buchungsbestätigung S7 an den Server 23 des Anbieters erfolgt dann in Schritt S8 die Freigabe zur Übermittlung des WAP-Contents an das Mobilfunktelefon 21 des Käufers .
Fig. 6 stellt die Nutzung eines kostenpflichtigen Dienstes auf Basis von SMS dar, bei dem in Schritt Sl vom Mobilfunktelefon 31 des Käufers über ein Mobilfunknetz 32 eine Anforde- rung an den Server 33 des Verkäufers ergeht. In Schritt S2 wird an Hand der MSISDN/Mobilfunknummer die zum Käufer zugehörige SID ermittelt und in S3 zusammen mit den übrigen Transaktionsdaten (Verkäufer-Kennung, Bezeichnung und Rech- nungsbetrag von 1 €) über ein Datennetz 34 an den Server 35 des PSP übermittelt. Nach positiv verlaufener Überprüfung der Transaktionsdaten bzw. der SID, des Guthabenbetrags und des Kundenprofils in den Schritten S4 bis S6 erfolgt in S7 die Verbuchung des Rechnungsbetrages. Auf Grund einer Anweisung, die im Kundenprofil hinterlegt ist, ergeht im Schritt S8 vom Server 35 des PSP eine Bestätigung der Buchung der Rechnungsbetrages von 1 € zum Mobilfunktelefon 31 des Käufers. In Schritt S9 wird die Buchungsbestätigung an den Server 33 des Verkäufers ermittelt, wo dann mit Schritt S10 der Verkäufer die kostenpflichtige SMS an den Kunden übermittelt.
Fig. 7 stellt ein weiteres Beispiel auf Basis von SMS dar, wobei die Schritte Sl (Anforderung eines kostenpflichtigen Dienstes) bis S6 (Überprüfung des Kundenprofils) analog zur Fig. 5 verlaufen. Beim vorliegenden Fall ist im Kundenprofil eine Autorisierung der Buchung hinterlegt, so dass in Schritt S7 vom Server 45 des PSP die Transaktionsdaten zum Mobilfunktelefon 41 des Käufers gesendet werden. In Schritt S8 wird die Buchung durch Übermittlung des Rechnungsbetrages, SID und PIN an den Server 45 des PSP autorisiert, die dann in S9 vorgenommen wird. Nach Übermittlung der Buchungsbestätigung an den Server 43 des Verkäufers in Schritt S10, erfolgt mit Sll die Übermittlung der kostenpflichtigen SMS vom Verkäufer an den Kunden.
Die Ausführung der Erfindung ist nicht auf die oben dargestellten beispielhaften Beschreibungen beschränkt, sondern umfasst eine Vielzahl von Abwandlungen, die im Rahmen fachgemäßen Handelns liegen.

Claims

Patentansprüche
1. Verfahren zur elektronischen Bezahlung mindestens eines Kleinstbetrages, insbesondere zur Ausführung einer Serie von Bezahlschritten mit jeweils einem Kleinstbetrag, für eine Ware oder Dienstleistung durch einen Kunden an einen Händler unter Nutzung eines Daten- und/oder Telekommunikationsnetzes und unter Einschaltung eines Abrechnungssystem-Servers, wobei
- für den Bezahlvorgang oder die Serie von Bezahlschritten ein eindeutiger Vorgangs-Identifikator generiert und mindestens bei einem ersten Bezahlschritt in einer Bestätigungsanfrage vom Abrechnungssystem-Server, zusammen mit einer Zahlbetragsinformation, an ein Kunden-Endger t übermittelt wird,
- der Kunde durch Übermittlung einer Bestätigungsnachricht von einem Kunden-Endgerät über das Daten- bzw. Telekommunika- tionsnetz an den Abrechnungssystem-Server einen Guthabenbzw. Kredit-Teilbetrag in Höhe des Zahlbetrages in Zuordnung zu dem Vorgangs-Identifikator zur Zahlung freigibt,
- auf dem Abrechnungssystem-Server ein Vergleich eines beim Abrechnungssystem-Server registrierten und von diesem aus elektronisch verwaltbaren Guthaben- bzw. Kredit-Teilbetrages des Kunden mit dem von diesem freigegebenen Zahlbetrag ausgeführt wird und
- im Ansprechen auf die Feststellung eines den freigegebenen Zahlbetrag übersteigenden Guthabenbetrages durch den Abrechnungssystem-Server in Reaktion auf die Bestätigungsnachricht eine Abbuchung des freigegebenen Zahlbetrages oder eines bis zu diesem Zeitpunkt zu zahlenden Teilbetrages hiervon getrig- gert und eine erste Ausführungsnachricht über die erfolgte Abbuchung an ein Händler-Endgerät gesandt wird.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass der Vorgangs-Identifikator in Zuordnung zu einem Kunden-Iden- tifikator durch den Abrechnungssystem-Server erzeugt und vorab, insbesondere in Reaktion auf eine vom Händler-Endgerät aus übermittelte Anforderungsnachricht, an den Händler über- sandt wird.
3. Verfahren nach Anspruch 2, d a d u r c h g e k e n n z e i c h n e t, dass die Übersendung des Vorgangs-Identifikators auf elektronischem Wege in einer Identifikator-Mitteilung vom Abrechnungssystem-Server an das Händler-Endgerät erfolgt.
4. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass ein zweiter Bezahlschritt und etwaige weitere Schritte einer zusammenhängenden Serie von Bezahlschritten jeweils durch
- Übermittlung eines schrittbezogenen Zahlbetrages in Zuordnung zum Vorgangs-Identifikator an den Abrechnungssystem-Ser- ver,
- Prüfung des schrittbezogenen Zahlbetrages in Relation zu einem vom freigegebenen Zahlbetrag verbleibenden Rest-Zahlbetrag ausgeführt und
- eine im Ansprechen auf die Feststellung eines den Rest- Zahlbetrag unterschreitenden schrittbezogenen Zahlbetrages vorgenommene Abbuchung und Absendung einer weiteren Ausführungsnachricht an das Händler-Endgerät ausgeführt wird.
5. Verfahren nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t, dass bei dem zweiten Bezahlschritt oder weiteren Schritten im Ergebnis der Feststellung eines den freigegebenen Rest-Zahlbetrag übersteigenden schrittbezogenen Zahlbetrages durch den Abrechnungssystem-Server an ein Kunden-Endgerät eine Bestäti- gungsanfrage mit dem ursprünglichen oder einem neuen Vorgangs-Identifikator und eine Zahlbetragsinformation mit einem mindestens die Differenz zwischen schrittbezogenem Zahlbetrag und Rest-Zahlbetrag abdeckenden Zahlbetrag gesandt und eine Abbuchung des schrittbezogenen Zahlbetrages erst nach Empfang einer entsprechenden Bestätigungsnachricht vom Kunden-Endgerät getriggert wird.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t, dass der in der Bestätigungsanfrage zur Bestätigung angegebene Zahlbetrag deutlich größer als die Differenz zwischen dem schrittbezogenen Zahlbetrag und dem Rest-Zahlbetrag ist derart, dass im Ansprechen auf eine Bestätigungsnachricht für diesen Zahlbetrag ein neuer Rest-Zahlbetrag für mehrere folgende Bezahlschritte beim Abrechnungssystem-Server freigegeben ist.
7. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass jede Nachricht vom Händler-Endgerät an den Abrechnungssystem- Server einen Händler-Identifikator sowie einen die Ware oder Dienstleistung kennzeichnenden Kontext-Datensatz umfasst.
8. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass der Vorgangs-Identifikator an das Händler-Endgerät per E-Mail oder SMS übermittelt wird.
9. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass dem Kunden der Vorgangs-Identifikator an einem Point-of-Sale außerhalb des Daten- bzw. Telekommunikationsnetzes, insbesondere mündlich oder in einer Beschriftung, mitgeteilt wird.
10. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Bestätigungsanfrage vom Abrechnungssystem-Server an das Kunden-Endgerät über E-Mail, WAP-Push, per SMS oder als synthetische Sprachnachricht übermittelt wird.
11. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Bestätigungsanfrage vom Abrechnungssystem-Server an das Kunden-Endgerät einen Händlernamen und einen die Ware oder Dienstleistung kennzeichnenden Kontext-Datensatz umfasst.
12. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Bestätigungsnachricht vom Kunden-Endgerät an den Abrechnungssystem-Server per E-Mail-Redirect, WAP-Redirect oder SMS-Redirect, insbesondere ohne zusätzliche Eingabe seitens des Kunden, gesandt wird.
13. Verfahren nach einem der Ansprüche 1 bis 11, d a d u r c h g e k e n n z e i c h n e t, dass die Bestätigungsnachricht vom Kunden-Endgerät an den Abrechnungssystem-Server per Sprachnachricht unter nachgeschalteter Spracherkennung oder per DTMF gesandt wird.
14. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Bestätigungsnachricht vom Kunden-Endgerät an den Abrechnungssystem-Server einen automatisch erzeugten oder vom Kun- den eingegebenen Kunden-Identifikator und optional einen Au- thentisierungscode, insbesondere eine PIN oder ein Passwort, umfasst.
15. Verfahren nach einem der vorangehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass der Abrechnungssystem-Server neben der ersten Ausführungsnachricht an das Händler-Endgerät eine zweite Ausführungsnachricht an das Kunden-Endgerät versendet.
16. Anordnung zur Durchführung des Verfahrens nach einem der vorangehenden Ansprüche, mit
- einem Abrechnungssystem-Server eines Abrechnungssystembetreibers,
- einem an ein Daten- und/oder Telekommunikationsnetz ange- schlossenen und über dieses mit dem Abrechnungssystem-Server verbindbaren Kunden-Endgerät und
- einem ebenfalls an das Daten- und/oder Telekommunikations- netz oder ein weiteres Kommunikationsnetz angeschlossenen und über dieses mit dem Abrechnungssystem-Server verbindbaren Händler-Endgerät, wobei der Abrechnungssystem-Server Mittel zur Erzeugung und Absendung einer Bestätigungsanfrage an das Kunden-Endger t, Mittel zum Empfang einer Bestätigungsnachricht vom Kunden- Endgerät und zur Extraktion mindestens des Vorgangs-Identifi- kators und eines freigegebenen Zahlbetrages aus dieser, Speichermittel zur kundenbezogenen Speicherung des Guthabenbetra- ges und zur vorgangsbezogenen Speicherung des freigegebenen Zahlbetrages, Vergleichermittel zum Vergleich des Guthabenbetrages mit dem Zahlbetrag sowie mit den Vergleichermitteln verbundene Steuer- und Sendemittel zur Triggerung der Abbuchung und zum Absenden der Ausführungsnachricht an das Händ- ler-Endgerät aufweist.
17. Anordnung nach Anspruch 16, d a d u r c h g e k e n n z e i c h n e t, dass das Kunden-Endgerät als Mobilfunk-Endgerät ausgebildet ist und das Daten- und/oder Telekommunikationsnetz ein Mobilfunknetz aufweist und dem Abrechnungssystem-Server Mobilfunk-Sen- de-/Empfangsmittel zur bidirektionalen Mobilfunkkommunikation mit dem Kunden-Endgerät zugeordnet sind.
18. Anordnung nach Anspruch 16 oder 17, d a d u r c h g e k e n n z e i c h n e t, dass der Abrechnungssystem-Server Erzeugermittel zur Erzeugung des Vorgangs-Identifikators und mit diesen verbundene Sendemittel zu dessen Übersendung an das Händler-Endgerät aufweist.
19. Anordnung nach einem der Ansprüche 16 bis 18, d a d u r c h g e k e n n z e i c h n e t, dass der Abrechnungssystem-Server weiterhin Berechnungsmittel zur Berechnung des Rest-Zahlbetrages aus einem gespeicherten freigegebenen Zahlbetrag und mindestens einem schrittbezogenen Zahlbetrag und mit den Berechnungsmitteln verbundene Speichermittel zur Speicherung des Rest-Zahlbetrages in Er- setzung des freigegebenen Zahlbetrages als Eingangsdatum für die Vergleichermittel aufweist.
20. Anordnung nach einem der Ansprüche 16 bis 19, d a d u r c h g e k e n n z e i c h n e t, dass der Abrechnungssystem-Server Erkennungs- und Speichermittel zur Extraktion eines Händler-Identifikators und/oder Kunden- Identifikators aus Nachrichten vom Händler-Endgerät bzw. Kunden-Endgerät und zu dessen bzw. deren Speicherung sowie Ad- ressierungsmittel zur Adressierung der Bestätigungsanfrage und/oder Ausführungsnachricht und wahlweise weiterer Nachrichten an das Kunden-Endgerät bzw. Händler-Endgerät anhand des gespeicherten Händler-Identifikators bzw. Kunden-Identi- fikators aufweist.
PCT/EP2003/006136 2002-07-03 2003-06-11 Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung Ceased WO2004006198A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US10/519,921 US20060116938A1 (en) 2002-07-03 2003-06-11 Method for the electronic payment of a merchandise or service by using a mobile radio network, and arrangement for carrying out said method
JP2004518523A JP2005536786A (ja) 2002-07-03 2003-06-11 移動無線網を利用した商品若しくはサービスの電子決済のための方法及び該方法を実施するための装置
AU2003242676A AU2003242676A1 (en) 2002-07-03 2003-06-11 Method for the electronic payment of a merchandise or service by using a mobile radio network, and arrangement for carrying out said method
BR0312394-4A BR0312394A (pt) 2002-07-03 2003-06-11 Processo para o pagamento eletrônico de uma mercadoria ou de prestação de serviços com o aproveitamento de uma rede de rádio móvel assim como de uma disposição para a sua realização

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10229901.3 2002-07-03
DE2002129901 DE10229901A1 (de) 2002-07-03 2002-07-03 Verfahren zur elektronischen Bezahlung einer Ware oder Dienstleistung unter Nutzung eines Mobilfunknetzes und Anordnung zu dessen Durchführung
EP02014720.3 2002-07-03
EP02014720A EP1378876A1 (de) 2002-07-03 2002-07-03 Verfahren zur elektrischen Bezahlung einer Ware oder Dienstleistung unter Nutzung eines Mobilfunknetzes und Anordnung zu dessen Durchführung

Publications (1)

Publication Number Publication Date
WO2004006198A1 true WO2004006198A1 (de) 2004-01-15

Family

ID=30116600

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/006136 Ceased WO2004006198A1 (de) 2002-07-03 2003-06-11 Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung

Country Status (6)

Country Link
US (1) US20060116938A1 (de)
JP (1) JP2005536786A (de)
CN (1) CN1666238A (de)
AU (1) AU2003242676A1 (de)
BR (1) BR0312394A (de)
WO (1) WO2004006198A1 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007304922A (ja) * 2006-05-12 2007-11-22 Bank Of Tokyo-Mitsubishi Ufj Ltd 情報処理装置の制御方法、情報処理装置及びプログラム
US20080208739A1 (en) * 2007-02-27 2008-08-28 Phillips Mark E Transactional services associated with mobile devices
US9652761B2 (en) 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US9990623B2 (en) 2009-03-02 2018-06-05 Boku, Inc. Systems and methods to provide information
US9595028B2 (en) * 2009-06-08 2017-03-14 Boku, Inc. Systems and methods to add funds to an account via a mobile communication device
US9697510B2 (en) 2009-07-23 2017-07-04 Boku, Inc. Systems and methods to facilitate retail transactions
US9519892B2 (en) 2009-08-04 2016-12-13 Boku, Inc. Systems and methods to accelerate transactions
US9830622B1 (en) 2011-04-28 2017-11-28 Boku, Inc. Systems and methods to process donations
US9191217B2 (en) 2011-04-28 2015-11-17 Boku, Inc. Systems and methods to process donations
WO2016024183A2 (en) * 2011-07-18 2016-02-18 Andrew Zhou Systems and methods for messaging, calling, digital multimedia capture and payment transactions
FI20135164L (fi) * 2013-02-22 2014-08-23 Op Palvelut Oy Kommunikointi maksutapahtuman aikana
CN104657857B (zh) * 2013-11-19 2024-10-22 腾讯科技（深圳）有限公司 一种实现支付的方法、相关装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066436A1 (en) * 1998-06-19 1999-12-23 Protx Limited Verified payment system
DE19946537A1 (de) * 1999-09-28 2001-04-05 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Dienstleistungen über Mobilfunk
EP1193658A1 (de) * 2000-09-29 2002-04-03 Siemens Aktiengesellschaft Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010032192A1 (en) * 1999-12-10 2001-10-18 Laxmiprassad Putta Method and apparatus for improved financial instrument processing
US20030187784A1 (en) * 2002-03-27 2003-10-02 Michael Maritzen System and method for mid-stream purchase of products and services

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066436A1 (en) * 1998-06-19 1999-12-23 Protx Limited Verified payment system
DE19946537A1 (de) * 1999-09-28 2001-04-05 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Dienstleistungen über Mobilfunk
EP1193658A1 (de) * 2000-09-29 2002-04-03 Siemens Aktiengesellschaft Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher

Also Published As

Publication number Publication date
BR0312394A (pt) 2005-04-12
CN1666238A (zh) 2005-09-07
US20060116938A1 (en) 2006-06-01
JP2005536786A (ja) 2005-12-02
AU2003242676A1 (en) 2004-01-23

Similar Documents

Publication Publication Date Title
EP1203357B1 (de) Sms-e-commerce
DE69534982T2 (de) Computer-zahlungssystem zum kaufen von informationsprodukten mittels elektronischem transfer auf dem internet
EP0986275B1 (de) Verfahren zum Kaufen von Waren oder Dienstleistungen mit einem Mobiltelefon
DE69618157T2 (de) On-line-Einkaufssystem und Verfahren zum Begleichen der Rechnung
EP1309957B1 (de) Verfahren und anordnung zur übertragung eines elektronischen geldbetrages aus einem guthabenspeicher
EP1446778A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
DE19946539B4 (de) Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
EP1180756A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
WO2000045350A1 (de) Verfahren, system und mobilstation zur durchführung von bargeldlosen finanztransaktionen
WO2004006198A1 (de) Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung
EP1180751A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
EP1347620B1 (de) Abrechnung einer kostenpflichtigen Nutzung von im Internet bereitgestellten Daten durch ein Mobilfunkendgerät
EP1269438A1 (de) Elektronisches zahlungsverfahren und anordnung zu dessen durchführung
EP1249996B1 (de) Verfahren zum Abrechnen von Leistungen in einem Kommunikationsnetz
EP1213689B1 (de) Verfahren zur automatischen Abwicklung von Zahlungsvorgängen im Electronic Commerce sowie zugehörige Vorrichtung
DE60000576T2 (de) Verfahren zum einführen von handelsdienstleistungen
EP1180748A1 (de) Verfahren und Anordnung zur Übertagung eines elektronischen Geldbetrages aus einem Guthabenspeicher per WAP
EP1309951B1 (de) Verfahren und anordnung zur übertragung eines elektronischen geldbetrages aus einem guthabenspeicher
EP1081919B1 (de) Verfahren zur Autorisierung in Datenübertragungssystemen zur Bezahlung von über das Internet angebotenen Waren und/oder Dienstleistungen
EP1193658A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
DE10229901A1 (de) Verfahren zur elektronischen Bezahlung einer Ware oder Dienstleistung unter Nutzung eines Mobilfunknetzes und Anordnung zu dessen Durchführung
EP1480398B1 (de) Verfahren und Anordnung zur Etablierung eines kostenpflichtigen E-Mail-Dienstes
EP1310928A1 (de) Verfahren zum Ermöglichen und Durchführen einer Geldzahlung unter Nutzung eines Kommunikationsnetzes
EP1378876A1 (de) Verfahren zur elektrischen Bezahlung einer Ware oder Dienstleistung unter Nutzung eines Mobilfunknetzes und Anordnung zu dessen Durchführung
WO2001081875A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EC 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 MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

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

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

Ref document number: 20038155427

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2004518523

Country of ref document: JP

122 Ep: pct application non-entry in european phase
ENP Entry into the national phase

Ref document number: 2006116938

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10519921

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10519921

Country of ref document: US